As ferramentas de gerenciamento de configuração são apropriadas para uso como ferramentas de implantação?

Na parte de trás da minha resposta à pergunta: Como o DevOps pode ajudar a melhorar os procedimentos de Custódia de Software? Tensibai fez a pergunta:

O que exigiria Capistrano em cima de marionetes ou chef?

Minha resposta foi postar um link para o artigo de Noah Gibbs "Precisamos de Capistrano e Chef?" . Pessoalmente, ainda subscrevo a opinião de Noah de que é mais apropriado:

• use uma ferramenta de implantação especializada, como o Capistrano, para implantações.
• use uma ferramenta especializada em gerenciamento de configuração, como o Chef, para gerenciamento de configuração.

A abordagem fundamental que cada tipo de ferramenta usa para concluir sua tarefa é muito diferente:

• Ferramentas de gerenciamento de configuração - são sobre como criar e manter o estado desejado de um sistema, elas são inerentemente idempotentes por natureza. Exemplos de ferramentas de gerenciamento de configuração são Chef , Puppet , Ansible , PowerShell DSC , Salt Stack .

• Ferramentas de implantação - são sobre o fornecimento de versões de software em um ambiente de hospedagem, fornecem funcionalidade para manter várias versões do software em várias máquinas e gerenciar qual versão é "atual", elas são inerentemente imperativas por natureza. Exemplos de ferramentas de implantação são Capistrano , Octopus Deploy , Deployer e Command.io .

Acredito que as Ferramentas de Gerenciamento de Configuração podem fazer o trabalho das ferramentas de implantação e, no caso da Infraestrutura Imutável, elas são a ferramenta mais apropriada para o trabalho, pois as versões de software no destino não precisam ser mantidas.

Pergunta: As ferramentas de gerenciamento de configuração, como Chef, Ansible e Puppet, amadureceram a ponto de serem capazes de cumprir os modelos idempotente e imperativo?

Nesse contexto, o conselho típico deve ser imediatamente aplicável: use a ferramenta certa para o trabalho.

Mas também não é possível ignorar hoje em dia a tendência quase virulenta das ferramentas de software de estender a funcionalidade para campos mais ou menos relacionados e de fato se tornarem conjuntos de ferramentas por vários motivos: recursos interessantes para ter, expandir a base de clientes, acumular mais receita etc.

Por exemplo, muitas ferramentas de gerenciamento de arquivos incluem recursos de visualização de imagens e muitas ferramentas de processamento de imagem incluem recursos de gerenciamento de arquivos. Você pode mover arquivos e visualizar imagens com qualquer uma das ferramentas, geralmente igualmente bem.

Por esse motivo, é bem possível que partes inteiras do processo de desenvolvimento de software sejam cobertas / sobrepostas por várias ferramentas (conjuntos), mesmo que seu principal recurso / capacidade seja diferente.

Portanto, ele realmente se resume à funcionalidade exata que você deseja obter em seu processo específico e em que medida uma ferramenta ou outra faz o trabalho em seu contexto . Subjetividade / preferências / conveniência incluídas.

Tornar esta pergunta principalmente baseada em opiniões;)

As ferramentas de gerenciamento de configuração são usadas para colocar um sistema em um estado conhecido. As ferramentas de implantação implantam novos arquivos e dados do programa em um sistema. No final do dia, os dois tipos de ferramentas fazem uma combinação de:

• Determine o estado atual do sistema.
• Transfira arquivos para o sistema.
• Adicione ou altere dados persistentes (por exemplo, arquivos de configuração, dados do banco de dados, configurações do registro)
• Inicie ou reinicie os programas.

As ferramentas de gerenciamento de configuração possuem linguagens declarativas que especificam o estado do sistema. As ferramentas de implantação possuem linguagens imperativas que instruem o sistema a fazer as coisas. Uma pessoa do DevOps precisa fazer as duas coisas.

Usando a ferramenta de implantação Capistrano, é desajeitado usar seu idioma para informar ao sistema para garantir que o servidor da web esteja ativo. Você precisa emitir um comando para reiniciar o servidor da Web e outro para verificar se o servidor está ativo. É um erro levar o servidor da web a um estado conhecido.

Usando a ferramenta de gerenciamento de configuração Ansible, é desajeitado reiniciar um servidor da web. O idioma permite que o servidor da Web seja "ativado", mas se você deseja especificamente que seja reiniciado, defina seu estado como "reiniciado". Mas não há uma maneira fácil de verificar se o servidor web foi reiniciado. Este é um problema no Ansible para permitir operações pontuais.

Algumas pessoas preferem fazer os dois tipos de trabalhos com uma única ferramenta e trabalhar em torno das arestas. Outras pessoas preferem ter duas ferramentas para fazer quase a mesma coisa, mas sem arestas. Para responder à pergunta, "adequação" é uma questão de gosto. Esta resposta explica o porquê.

TL; DR : Basta usar o Ansbile, é uma ferramenta de configuração e implantação :)

Existem vários tipos de implantação:

• Baseado em aplicativo (arquivos, pacotes de arquivos)

• Baseado em contêiner (inclui VMs, Habitat, LXC, Docker)

• Baseado em funções (Micro serviços / Lambdas / Funções)

Presumo que, neste caso, falamos apenas sobre atualizações de aplicativos no (s) servidor (es).

Para implantação, você precisa que duas coisas aconteçam:

1. Arquivos ou pacotes corretos precisam passar para o servidor.
2. Os estados de configuração e serviço precisam mudar.

Agora para (1) você pode usar várias estratégias:

• Repositórios de Artefatos / Sincronização
• Repositórios de Pacotes / Gerenciadores de Pacotes
• Sistema de controle de versão / Atualização + Compilação (opcional)
• Protocolos de transferência de arquivos (scp, rsync, ftp)
• Ferramentas de implantação

Para o (2) você pode usar:

• Ferramentas de gerenciamento de configuração
• Ferramentas de implantação

Portanto, embora as Ferramentas de Implantação sejam uma maneira de implantar tudo em um, elas nem sempre são a melhor estratégia. Às vezes, você deseja usar a combinação dessas maneiras de implantação. Você provavelmente já usa gerenciadores de pacotes pelo menos em seus servidores. Você provavelmente executa ferramentas de configuração de qualquer maneira. O problema com algumas das ferramentas de configuração era uma orquestração adequada entre vários servidores, mas agora até o Chef e o Puppet podem fazer isso muito bem. Ansible sempre foi bom nisso.

Por experiência pessoal , usei todas as combinações, mas atualmente usamos o Capistrano para implantação e a Sincronização Ansible para gerenciamento de configurações e VCS e repositórios de pacotes para transferências de arquivos, mas há problemas com o Capistrano e estamos planejando nos afastar dele para unifique no Ansible para gerenciamento de implantação, manutenção e configuração.

A implantação de aplicativos é uma coisa difícil de definir, pois possui muitos subproblemas. Os sistemas de gerenciamento de configuração são excelentes na modelagem de tarefas convergentes e que trabalham com "qual é o estado desejado do sistema". No contexto da implantação de aplicativos, isso é ótimo para coisas como implantar bits em uma máquina, gerenciar arquivos de configuração e configurar serviços do sistema. O que é extremamente ruim é o que é inerentemente processual, principalmente as migrações de banco de dados e o serviço reiniciado. Normalmente, tento colocar a lógica convergente no Chef e permitir que uma ferramenta processual externa (geralmente Fabric no meu caso) lide com os poucos bits restantes, além de sequenciar as convergências reais.

Então, basicamente, você deve usar os dois para as peças em que eles são melhores.

Para software e código de implantação em um servidor existente ou dentro de um contêiner do Docker, a resposta é relativamente simples - Não, você não precisa dos dois, mas pode querer os dois se outra ferramenta ou utilitário agregar valor e for a ferramenta certa para o trabalho , no entanto, as coisas ficam mais complicadas quando você está implantando servidores e sistemas operacionais.

Um valor agregado de uma mentalidade de DevOps é tratar a infraestrutura como código e frequentemente implantar ou destruir máquinas virtuais ou mesmo bare metal em um ambiente altamente elástico. Seu sistema de gerenciamento de configuração não pode facilmente iniciar e executar o kickstart do servidor para você e não pode gerenciar repositórios, pacotes e atualizações / correções durante e após implantações ou, em alguns casos, licenciamento e direitos.

Para o Amazon Web Services, isso é bastante fácil de gerenciar por APIs, mas para aqueles que precisam gerenciar nossos próprios datacenters, essa não é uma opção. Por esse motivo, o projeto Foreman (e a Red Hat que renomeia isso ) consideraram necessário agrupar Katello , Candlepin e um gerente de configuração como Ansible, Foreman ou Puppet ao implantar o Cenário Katello .

Portanto, embora você possa se safar do uso de ferramentas de gerenciamento de configuração para implantações de código de software no lado Dev da casa, no lado Ops, há vários casos em que a resposta é um retumbante "não, as ferramentas de gerenciamento de configuração não são apropriado para usar como ferramentas de implantação "Isso exigiria uma séria reinvenção da roda e é impraticável. Em vez disso, você deve usar suas ferramentas de gerenciamento de configuração para iniciar implantações em outra ferramenta.