O Chef é uma ferramenta apropriada para usar na implantação de aplicativos? [fechadas]

5

Usamos o Chef para o gerenciamento de configuração (certificando-se de que um "Nó do banco de dados" tenha a versão correta do banco de dados correto; que um "servidor de aplicativos" tenha a versão correta do Java e env vars nele etc.) . bem como a implantação ( chef-client --once ) de nossos aplicativos nos nós apropriados do servidor de aplicativos.

Para mim, pessoalmente, sinto que a implantação pertence ao domínio do servidor de IC. Tudo além do aplicativo (o container, o sistema operacional, as ferramentas do sistema, a configuração do sistema, etc.) pertence ao gerenciamento de configuração e, portanto, é melhor gerenciado por ferramentas como Chef, Puppet, etc.

Atualmente, nossas construções de CI produzem um artefato (um JAR executável com um contêiner do Tomcat incorporado) e, em seguida, executa o Chef-Client em todos os nós nos quais o JAR precisa ser implantado. O Chef-Client está configurado para extrair o JAR do servidor de CI. Isso me parece hacky e estou tentando pesquisar uma solução melhor e mais convincente.

Então eu pergunto:

  • A implantação pertence ao servidor de IC ou à ferramenta CM? Por quê?
  • Se pertencer ao servidor de IC, que mecanismos (SSH, SCP, etc.) o servidor de IC deve usar para realmente executar a implantação? Nós usamos Bamboo, mas poderíamos facilmente falar sobre Jenkins, Hudson, etc.
  • Existe uma diferença entre implantar (colocar o aplicativo no nó) e executar . A execução também pertence ao servidor de IC, à ferramenta CM ou a algum outro processo? Em outras palavras, o que deve realmente parar a versão "antiga" do aplicativo, substituí-la pela "nova" versão e, em seguida, iniciar a nova versão? Isso é um candidato para algo como Run Deck?
por herpylderp 01.08.2014 / 21:27
fonte

2 respostas

4

Eu suspeito que as respostas serão em grande parte baseadas em opiniões, e reflitam a atmosfera política das empresas para as quais as pessoas trabalham, mas aqui vai ...

Eu diria que tudo começa com "por quê?" Por que nós construímos aplicativos? Para cumprir metas de negócios. Por que construímos infraestrutura? Para executar aplicativos que atendam às metas de negócios. Então parece que há uma hierarquia natural aqui. Os servidores de IC criam aplicativos e os testam em algo . Ferramentas CM constroem servidores. Portanto, uma cadeia de DevOps configurada corretamente provavelmente usa os servidores de IC para invocar ferramentas de CM para garantir que o local em que estão prestes a ser implantadas esteja configurado corretamente. Então, depois que os testes forem aprovados, esses mesmos servidores de CI invocam ferramentas de implantação (se necessário) para enviar código para os servidores de produção que poderiam ser criados com scripts CM em um momento, se necessário. Em outras palavras, os scripts se tornam a definição do que está lá - nenhuma alteração é feita nos servidores que não são roteirizados primeiro. Quanto a saltar o aplicativo existente, isso vai depender da configuração da sua infraestrutura. Se você puder colocar um servidor de aplicativos sem problemas (sem afetar os usuários), implante novo código, execute um teste de fumaça e coloque tudo de volta online em um script rotativo em um farm de servidores. recursos de entrega que não afetam os usuários finais.

    
por 01.08.2014 / 21:49
fonte
0

Minha opinião é que a Implantação pertence ao servidor de IC. Uma ferramenta CM como o chef é construir sua infraestrutura no estado desejado. Mas a implantação é mais do que isso. Suponha que você tenha que implantar um sistema que inclua um aplicativo Web de front-end para vários servidores de carga balanceada, alguns scripts de mudança de banco de dados e alguns serviços de back-end para outro conjunto de servidores. Existem dependências e ordem envolvidas na implantação. por exemplo. DB muda antes de serviços de back-end para todos os servidores e antes do aplicativo web front-end. Pode haver ações a serem tomadas se houver erro em qualquer etapa. O Chef, como entendo, não consegue lidar com esse tipo de cenário, ao passo que qualquer ferramenta competente de CI seria.
O outro problema é que muitas vezes a infraestrutura é compartilhada entre vários aplicativos e é corrigida / atualizada em uma cadência diferente para os aplicativos, e, na verdade, um aplicativo não deve atualizar a infraestrutura, pois ela não é proprietária dela. Esse é outro motivo para manter o CI e o CM separados.

    
por 02.08.2014 / 10:00
fonte