Corredor de CI no mesmo servidor do GitLab?

Estou configurando um servidor GitLab na minha empresa e agora estou adicionando o GitLab CI a ele.

Antes de iniciar esta tarefa, gostaria de entender se há alguma desvantagem em executar meus corredores no mesmo servidor usado pelo GitLab e pelo GitLab CI.

Eu li que existem preocupações com a segurança, mas a usamos apenas internamente, então não acho que isso possa ser um problema.

Estou esquecendo de algo?

git continuous-integration gitlab

— Fez Vrasta
fonte

Respostas:

Imagine as seguintes situações:

Um desenvolvedor interno quer prejudicar a empresa (porque considera ser mal pago, porque seu chefe dorme com sua esposa; o motivo não importa). Ele faz um teste de unidade que, quando executado, em vez de testar o aplicativo, pesquisa o repositório GitLab e apaga. Na próxima confirmação, surpresa, todo o código-fonte do projeto é perdido (mas você faz backups e os testou, certo?)
Ou o mesmo desenvolvedor percebe que os backups do repositório estão configurados na mesma máquina. Ele altera essa configuração através de um teste de unidade, para que o backup contenha agora um repositório diferente e aguarde um mês - o tempo em que os backups são mantidos. Agora que todos os backups estão corrompidos, ele pode confirmar seu teste de unidade, que apaga o código fonte do servidor.
Ou um estagiário quer vender o código fonte para a concorrência. Você configurou cuidadosamente o acesso, limitando-o apenas ao que ele precisa para seu trabalho. Ao mesmo tempo, ele tem acesso ilimitado ao próprio repositório através dos testes de unidade, podendo fazer o dump completo.

A menos que os testes de unidade sejam executados em um contexto de permissões limitadas e não possam acessar nada além dos diretórios e arquivos necessários para os testes, misturar o servidor de CI com o servidor que mantém seu repositório é realmente perigoso.

Outra questão é que o servidor de controle de versão deve ser rápido. O servidor de CI instalado na mesma máquina pode atrasar as confirmações.

— Arseni Mourzenko
fonte

Somos 3 desenvolvedores ... se alguém de nós quiser prejudicar a empresa, ele pode fazer isso de milhares de maneiras = (... Então, o único problema seria o desempenho lento, mas se eu usar uma boa máquina, não devo ter grandes). ? problemas, certo Thanks!

— Fez Vrasta

ps: e o chroot? Não pode ser usado para tornar o processo seguro?

— Fez Vrasta

@FezVrasta: se a segurança não é uma preocupação no seu caso, nem os desempenhos, o único benefício de ter máquinas separadas que vejo é a escalabilidade futura. Mas, francamente, fazer alterações antes que os problemas de escalabilidade apareçam é semelhante à otimização prematura.

— Arseni Mourzenko

@FezVrasta: "e o chroot? Não pode ser usado para tornar o processo seguro?" - Eu não tenho habilidades suficientes em segurança Unix para responder a essa pergunta.

— Arseni Mourzenko

Dado que não existe um servidor “onisciente” central para o git, isso não é ruim, como seria com outros sistemas de controle de código-fonte.

Desde que exista um syk automático do servidor git fora do local para outro servidor git (que é testado), eu não me preocuparia com essa configuração em uma pequena empresa.

Idealmente, eu gostaria que os desenvolvedores enviassem suas alterações para o servidor git do servidor de offset e, em seguida, o servidor de CI para extrair as cobranças do servidor de offset - dessa forma, o servidor externo é testado quando todas as entradas são feitas.

Se os desenvolvedores sempre faziam o pull do servidor no local para economizar tempo, isso não é problema.

— Ian
fonte

se eu precisar de 2 servidores ... por que não apenas executar corredores no segundo servidor?

— Fez Vrasta

@FezVrasta, o " servidor externo " pode ser qualquer um que lhe venda hospedagem git, não precisa ser um servidor que você possui. Além disso, como é pela Internet, fazer um puxão será lento.

— Ian

Eu sou a criação de isso para a minha empresa, usamos nossos próprios servidores ...

— Fez Vrasta