Abordagem de múltiplas funções de aplicativo Ansible

Question

Só para ter uma ideia, trabalho com o Puppet há 3 anos e entendo muito bem sua arquitetura. Nossa empresa está refatorando todo o nosso produto baseando sua arquitetura em microsserviços e começando a usar Integração/Implantação Contínua. Aproveitei esta oportunidade para mudar nosso gerenciamento de configuração para Ansible para poder usar apenas uma ferramenta para implantação e configuração/orquestração.

Nossa arquitetura será totalmente baseada em AWS, com ambientes Live, Staging e 3 ambientes de Integração/QA. Cada microsserviço terá seu próprio processo de implantação separado e os ambientes de integração/QA manterão todos os aplicativos em uma única instância, enquanto o Live/Staging terá múltiplas instâncias e, em alguns casos, diferentes pools de instâncias por microsserviço.

Meu objetivo é ter um único "repositório" de configuração/implantação do Ansible para todos os ambientes, utilizando variáveis ​​para parametrizar os templates através dos ambientes. Dessa forma saberemos que temos um processo consistente de configuração e implantação durante todo o nosso ciclo de desenvolvimento.

O que estou tendo dúvidas agora é sobre como abordo a criação de funções para essas múltiplas aplicações. Também acho esse tópico muito difícil de "google", já que a maioria das postagens que encontro são tutoriais simples ou exemplos de implantação de aplicativo único.

O que estou considerando agora é:

1. Separei funções para cada "serviço" necessário, como nginx, java, logstash, etc, com cada arquivo de configuração do aplicativo dentro dele. Dessa forma, mantenho a capacidade de reutilização das funções e evito me repetir quando dois ou mais aplicativos usam um arquivo de configuração bastante semelhante que pode ser diferenciado por meio de variáveis. Também terei uma função de implantação com todas as tarefas de implantação nela. Esta é a abordagem que normalmente adoto quando trabalho com o Puppet, mas às vezes pode dispersar a configuração, tornando "difícil" encontrar e adicionar alguns casos em que uma alteração na configuração de um aplicativo pode impactar outro (principalmente devido a modelos únicos servindo mais de um aplicativo).

2. Tenha uma função para microsserviço. Isso é mais fácil de trabalhar, pois todas as configurações e variáveis ​​estão na mesma função, mas terei que repetir tarefas e configurações para cada microsserviço, e isso me faz estremecer um pouco.

O motivo desta pergunta é medir como as pessoas que enfrentam o mesmo problema lidam com isso, já que parece quase impossível encontrar respostas razoáveis ​​sobre isso através de uma pesquisa no Google e não tenho amigos/conhecidos que trabalhem com implantações de aplicativos Ansible/multi.

Desculpe se não fui claro o suficiente/confuso e obrigado por todos os insights que você pode me dar.

Answer 1

O que eu faria é ter papéis para cadaserviço do sistemaque sua aplicação precisa, umjogare umpapelpara cada aplicativo/microsserviço, evariáveis ​​de grupo e/ou hostevariáveis ​​de função e padrõesque definem o que fazer.

Eu implanto muitos aplicativos baseados em PHP, então é muito parecido com isto:

Vou fazer uma peça app_microservice.yml:

---
- hosts: app_microservice_servers
  roles:
    - nginx
    - mariadb
    - php-fpm
    - app_microservice

Então eu vou ter umpapel roles/app_microserviceque implanta o código. Quando eu executar esta peça, os pré-requisitos nginx, mariadb e php-fpm serão instalados e configurados primeiro, caso ainda não tenham sido.

Além de pagar roles, uma jogada também pode ser arbitrária tasks. Sinta-se à vontade para misturá-los e combiná-los se algo for simples o suficiente para que uma função completa não seja necessária.

Esta peça também acompanha all.ymltodas as outras peças, para que eu possa fazê-lo ocasionalmente ansible-playbook all.yml. Lembre-se de que o ansible não garante idempotência como o fantoche tenta fazer, então é algo com que você deve ter cuidado.

- include: app_microservice.yml

eu usogrupovariáveis ​​​​para definir coisas que são comuns a um grupo (embora existam poucas delas que não cabem nopapelvariáveis ​​​​ou padrões), allvariáveis ​​​​de grupo para coisas globais ehospedarvariáveis ​​para qualquer coisa que seja exclusiva de um host.

Por exemplo, eu forneço uma senha root exclusiva do MySQL para cada host, mas tenho cifras e protocolos SSL definidos para group_vars/all/main.ymlque, se precisarem ser alterados, haja uma fonte de verdade para eles.