Estamos nos deparando com uma discussão interessante e caindo em dois campos. Estou interessado em quaisquer problemas específicos com ideias ou dicas que possamos estar perdendo. Na verdade, qualquer coisa que possa nos ajudar a tomar uma decisão ou apontar coisas que não estamos contabilizando. Eu sei que isso contorna um pouco a regra da "sem opinião", mas espero que ainda seja uma pergunta aceitável. Desculpe pela extensão também, há algumas nuances.
1) Um lado (o meu - não sou imparcial) considera o modelo de servidor imutável muito interessante para sistemas em nuvem. Para isso, criamos um protótipo da migração de todos os componentes de nossa infraestrutura para o Docker. Nossos aplicativos personalizados são construídos via Jenkins diretamente em imagens Docker que são implantadas em um Docker Registry local. Em seguida, criamos um grande conjunto de funções Ansible e um manual que é capaz de acessar um servidor vazio, instalar o Docker e depois dizer ao Docker para instalar todos os contêineres conforme necessário. Depois de alguns minutos, todo o aplicativo e toda a infraestrutura de suporte estão conectados e funcionando - registro, monitoramento, criação/preenchimento de banco de dados, etc. A máquina finalizada é um ambiente de controle de qualidade ou desenvolvimento independente com uma cópia exata do aplicativo. Nosso plano para expandir isso seria criar novos Playbooks para construir novos servidores AWS a partir de uma AMI confiável de base (provavelmente uma imagem muito simples), fazer implantações contínuas do aplicativo de produção para lidar com o gerenciamento de configuração e lançamentos e geralmente nunca mais editar servidores - apenas faça-os novamente. Não estou preocupado em fazer com que o que descrevi funcione na prática - apenas se for um modelo razoável.
2) O outro campo quer usar o Puppet para lidar com o gerenciamento de configuração, o Ansible para implantar nossos aplicativos personalizados que são tarballs gerados a partir do nosso processo de construção, o Foreman para lidar com o acionamento e o gerenciamento do processo como um todo e o Katello para fazer alguma parte da base gerenciamento de imagens. Os lançamentos envolveriam a alteração da configuração do Puppet conforme necessário e o Ansible implantando componentes atualizados com alguma coordenação do Foreman. Os servidores seriam construídos razoavelmente rápido se precisássemos de novos, mas a intenção não é torná-los descartáveis como parte do processo padrão. Este é mais próximo do modelo de servidor Phoenix, embora tenha uma vida longa.
Então, minha pergunta realmente se resume a esta: o modelo de servidor imutável com as ferramentas que descrevi acima é realmente tão realista quanto parece? Adoro a ideia de que nosso processo de teste pode ser literalmente construir um clone inteiro dos aplicativos ao vivo, deixar o controle de qualidade martelá-lo e, em seguida, apenas inverter o armazenamento do banco de dados e algumas configurações de DNS para torná-lo ativo.
Ou o modelo de servidor imutável falha na prática? Temos muita experiência com ambientes AWS e em nuvem, então essa não é realmente a preocupação - é mais uma questão de como obter um aplicativo razoavelmente sofisticado implantado de maneira confiável no futuro. Isto é de particular interesse porque lançamos com bastante frequência.
Temos o Ansible fazendo a maioria das coisas necessárias, exceto criar servidores EC2 para nós, e isso não é difícil. Estou tendo problemas para entender por que você realmente PRECISA do Puppet/Foreman/Katello neste modelo. O Docker é muito mais limpo e simples do que scripts de implantação personalizados em qualquer ferramenta que eu saiba. O Ansible parece muito mais simples de usar do que o Puppet quando você para de se preocupar em configurá-los in-situ e simplesmente os constrói novamente com a nova configuração. Sou fã do princípio do KISS - principalmente na automação, onde a Lei de Murphy é galopante. Quanto menos maquinaria, melhor IMO.
Quaisquer pensamentos/comentários ou sugestões sobre a abordagem serão muito apreciados!
Responder1
Em nossa empresa, implementamos com sucesso o Puppet na infraestrutura legada do cliente. Também estamos usando contêineres Docker para executar um serviço dedicado (que na verdade é um aplicativo antigo cortado e distorcido para caber em contêineres).
Não fiquei satisfeito com os contêineres na primeira vez que comecei a trabalhar com eles (sim... um aplicativo de 30kb se torna uma imagem pesada de 200MB), mas quando tive que recriar todo o ambiente após um pequeno desastre, mudei de ideia. Acho que o Docker foi inventado exatamente para isso: implantações rápidas e frequentes, sem preocupações com a configuração do servidor. Se você projetar os contêineres corretamente, poderá alternar entre provedores de nuvem, laptops de desenvolvedores e datacenters de colocation com facilidade. Porque tudo que você precisa é de uma caixa Linux vanilla com daemon Docker.
- No cenário 1) você tem tudo em um só lugar (quero dizer porque com o Docker você terá código E configuração no mesmo repositório) fácil de gerenciar, ler e implantar.
- No cenário 2) você precisa armazenar partes de configuração para 3 ferramentas diferentes (!) Em um repositório e o código do aplicativo no outro, o que torna as coisas mais complicadas
Eu também estava usando o Puppet em meu projeto anterior e minha experiência até agora é que o servidor imutável é alcançável com o Docker do que com o Puppet ou Chef. Acredito que as ferramentas de gerenciamento de configuração são mais úteis para provedores de nuvem do que para equipes de desenvolvimento.
Responder2
Aqui estão meus 2 centavos de euro.
As 2 opções que você propõe são opções válidas para alcançar (algum tipo de) imutabilidade.
Acho que você deveria escolher aquele com o qual se sente mais confortável.
No entanto, pelo que você escreve, parece que ainda não há consenso.
Talvez uma terceira opção seja necessária então? ;)
No entanto, como tal, a imutabilidade não é um objetivo, mas um meio de garantir outras propriedades (sem desvio de configuração, melhor estabilidade, ...).
Eu indicaria claramente meus objetivos, colocaria algumas métricas para validá-los e faria alguns testes usando as 2 opções. Você teria então alguns números para selecionar aquele que está mais alinhado com o seu negócio.
Boa sorte!