Corredor de CI no mesmo servidor do GitLab?

12

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?

Fez Vrasta
fonte

Respostas:

11

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
8
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
4
@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
0

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
1
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
1
Eu sou a criação de isso para a minha empresa, usamos nossos próprios servidores ...
Fez Vrasta