Abordagem de Função de Aplicação Múltipla Ansible

Question

Apenas para um pouco de experiência, trabalhei com o Puppet por 3 anos e entendi que a arquitetura é muito boa. Nossa empresa está refatorando todo o nosso produto baseando sua arquitetura em microsserviços e está começando a usar a Integração / Implantação Contínua. Eu usei essa oportunidade para mudar nosso gerenciamento de configuração para Ansible, para que eu possa usar apenas uma ferramenta para implantação e configuração / orquestração.

Nossa arquitetura será totalmente baseada na AWS, com ambientes Live, Staging e 3 Integration / QA. Cada microsserviço terá seu próprio processo de implementação separado e os envs de Integration / QA manterão todos os aplicativos em uma única instância, enquanto o Live / Staging terá várias instâncias e, em alguns casos, conjuntos diferentes de instâncias por microsserviço.

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

O que estou tendo dúvidas agora é sobre como abordar a criação de funções para esses vários aplicativos. Eu acho esse tópico muito difícil de "google", já que a maioria das postagens que eu encontro são tutoriais simples ou exemplos de implantação de aplicativos únicos.

O que estou considerando agora é:

1. Ter funções separadas para cada "serviço" de que preciso, como nginx, java, logstash, etc, com cada arquivo de configuração de aplicativo dentro dele. Dessa forma, mantenho a reutilização de papéis e evito repetir-me quando dois ou mais aplicativos usam um arquivo de configuração bastante semelhante que pode ser diferente por variáveis. Também terei uma função de implantação com todas as tarefas de implantação. Esta é a abordagem que costumo tomar quando se trabalha com o Puppet, mas pode dispersar a configuração, por vezes, tornando "difícil" encontrar e adicionar alguns casos quando uma alteração na configuração de uma aplicação pode impactar outra (principalmente devido a modelos únicos que servem mais de um app).

2. Tenha uma função para o microsserviço. É mais fácil trabalhar com isso, já que todas as configurações e variáveis estão no mesmo papel, mas vou ter 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 Ansible / multi aplicativo implanta.

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 cada serviço do sistema que seu aplicativo precisa, um play e um role para cada aplicativo / microservice e variáveis de grupo e / ou host e variáveis de função e padrões que definem o que fazer.

Eu implanto um monte de aplicativos baseados em PHP, de modo que se parece muito com isso:

Eu terei uma peça app_microservice.yml :

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

Então, vou ter uma função roles/app_microservice , que implanta o código. Quando executo essa peça, os pré-requisitos nginx, mariadb e php-fpm serão instalados e configurados primeiro, se ainda não tiverem sido.

Além de chamar roles , uma reprodução também pode ser executada arbitrariamente em tasks . Sinta-se à vontade para misturá-los e combiná-los se algo for simples o suficiente para que não seja necessário um papel completo.

Esta jogada também vai para all.yml , juntamente com todas as outras reproduções, para que eu possa ocasionalmente fazer ansible-playbook all.yml . Lembre-se de que o ansible não garante a idempotência como o fantoche tenta, então isso é algo que você deve tomar cuidado.

- include: app_microservice.yml

Eu uso variáveis group para definir coisas que são comuns a um grupo (embora existam algumas poucas que não caberão nas variáveis role ou padrões ), variáveis de all do grupo para material global e variáveis host para qualquer coisa que seja exclusiva de um host.

Por exemplo, eu dou uma senha de root do MySQL para todos os hosts, mas tenho cifras e protocolos SSL definidos em group_vars/all/main.yml para que, se precisarem ser alterados, haja uma fonte de verdade para eles.