Modelo de servidor imutável com Docker / Ansible vs. Ansible, Puppet e Foreman na AWS?

9

Estamos nos deparando com um argumento interessante e estamos caindo em dois campos. Estou interessado em qualquer problema em particular com idéias ou pegadinhas que possam estar faltando. Realmente, qualquer coisa que possa nos ajudar a tomar uma decisão ou apontar coisas que não estamos representando. Eu sei que isso contorna a regra da "não opinião" um pouco de perto, mas espero que ainda seja uma pergunta aceitável. Desculpe pela duração também, há um pouco de nuance.

1) Um lado (o meu - não estou sem viés) acha o modelo de servidor imutável muito interessante para sistemas em nuvem. Para esse fim, criamos um protótipo para mover todos os componentes da nossa infraestrutura para o Docker. Nossos aplicativos personalizados são criados via Jenkins diretamente em imagens Docker que são implantadas em um Registro Docker 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, em seguida, informar ao Docker para instalar todos os contêineres conforme necessário. Depois de alguns minutos, todo o aplicativo e toda a sua infraestrutura de suporte estão conectados e funcionando - criação de log, monitoramento, criação / preenchimento do banco de dados etc. A máquina finalizada é um ambiente de controle de qualidade ou dev com uma cópia exata do aplicação. Nosso plano para expandir isso seria criar novos Playbooks para criar novos servidores da AWS a partir de uma base confiável AMI (provavelmente uma imagem muito simples), fazer implantações contínuas do aplicativo de produção para lidar com o gerenciamento de configurações e liberações e geralmente nunca editar servidores novamente apenas faça-os de novo. Não estou preocupado em conseguir o que descrevi trabalhando 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, Ansible para implementar nossos aplicativos personalizados que são gerados a partir do nosso processo de construção, Foreman para lidar com o acionamento e gerenciamento do processo como um todo e Katello para fazer alguns quantidade de gerenciamento de imagem de base. Os lançamentos envolveriam a configuração de alteração do Puppet, conforme necessário, e o Ansible, que implementaria os componentes atualizados com alguma quantidade de coordenação do Foreman. Os servidores seriam construídos razoavelmente rapidamente se precisássemos de novos, mas a intenção não é torná-los descartáveis como parte do processo padrão. Isso está mais próximo do modelo do servidor Phoenix, embora com uma vida longa.

Então, minha pergunta realmente se resume a isso: o modelo de servidor imutável com as ferramentas descritas acima é realmente tão realista quanto parece? Eu adoro a ideia de que o nosso processo de preparo pode literalmente construir um clone inteiro dos aplicativos ao vivo, deixar que o controle de qualidade o faça 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 uma boa experiência com AWS e ambientes em nuvem, o que não é realmente uma preocupação - mais uma questão de como obter um aplicativo razoavelmente sofisticado implementado de forma confiável no futuro. Isso é de particular interesse, já que lançamos com bastante frequência.

Temos o Ansible fazendo a maioria das coisas necessárias, exceto na verdade a criação de servidores EC2 para nós e isso não é difícil. Eu estou tendo dificuldade em entender por que você realmente PRECISA Puppet / Foreman / Katello neste modelo em tudo. 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 no local e simplesmente construí-los novamente com a nova configuração. Eu sou fã do diretor do KISS - particularmente em automação onde a Lei de Murphy é desenfreada. Quanto menos maquinaria, melhor o IMO.

Quaisquer pensamentos / comentários ou sugestões sobre a abordagem seriam muito apreciados!

    
por Doctor John Wick 14.05.2016 / 19:58

2 respostas

1

Em nossa empresa, implementamos com sucesso o Puppet na infra-estrutura legada do cliente. Também estamos usando contêineres do Docker para executar um serviço dedicado (que, na verdade, é um aplicativo antigo aparado e torcido para caber em contêineres). Eu não estava feliz com os recipientes na primeira vez que eu comecei a trabalhar com eles (sim ... 30kb app se torna 200MB imagem pesada), mas quando eu tive que recriar todo o ambiente após um pequeno desastre eu mudei de idéia. 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 com o daemon do 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 as peças de configuração para três ferramentas diferentes (!) em um repo e 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 é possível, em vez do Docker do que do Puppet ou do Chef. Acredito que as ferramentas do Configuration Management são mais úteis para Cloud Providers do que para a equipe de desenvolvimento.

    
por 19.05.2016 / 09:23
0

Aqui estão os meus 2 cêntimos de euro.

As 2 opções que você propõe são opções válidas para alcançar (algum tipo de) imutabilidade.
Eu acho que você deve escolher o que você está mais confortável com. No entanto, pelo que você escreve parece não haver consenso ainda.
Talvez uma terceira opção seja necessária então? ;)

No entanto, como tal imutabilidade não é um objetivo, mas um meio de garantir outras propriedades (sem desvio de configuração, melhor estabilidade, ...). Eu declararia claramente meus objetivos, colocaria algumas métricas para validá-los e faria alguns testes usando as duas opções. Você teria alguns números para selecionar o que está mais alinhado ao seu negócio.

Boa sorte!

    
por 15.05.2016 / 16:54