Práticas recomendadas para lidar com dependências entre funções Ansible

Question

Atualmente, estou dando os primeiros passos com ansible, então isso pode ser uma questão básica.

Eu estou tentando configurar um servidor com ansible que hospeda algumas páginas da Web e expõe vários outros serviços também. Para cada um desses, eu, opcionalmente, quero poder

• Registre um subdomínio com o servidor de nomes que é um dos serviços
• Use Vamos criptografar para emitir um certificado para o serviço
• Portas sme abertas no meu firewall

Atualmente, também tenho funções para configurar o servidor de nomes, criptografar e firewall. Quais são as melhores práticas para se comunicar entre os papéis? Deve, por exemplo a função webserver sabe o comando exato como criar um certificado para si mesmo, ou existe uma maneira de abstrair isso para uma chamada de notificação? Cada função do serviço deve poder gravar no meu arquivo de configuração do firewall, ou isso deveria ser um privilégio da função do firewall de alguma forma?

Talvez eu seja demais na mentalidade de um programador, mas gosto de coisas como "separação de interesses" e gostaria de mudar, por exemplo. meu software de firewall sem ter que mudar todos os outros papéis também.

    

Answer 1

Não é possível fornecer uma resposta exata à sua pergunta por razões óbvias, mas deixe-me pelo menos apontar alguns bits, alguns deles serão facilmente compreensíveis do ponto de vista de um programador:

1. Mantenha dados e lógica separados. ansible fornece os meios para tornar isso uma tarefa fácil, mas você precisa criar suas funções de maneira funcional, ou seja, tornar suas funções configuráveis por meio de dados.

2. Escreva seus papéis para que eles façam uma coisa só, mas façam bem. Isso melhora a reutilização de suas funções e facilita a manutenção no futuro.

3. Ao definir os dados que guiarão o comportamento de suas funções, não crie estruturas de dados complicadas. ansible tem muitos iteradores que você pode usar e até fornece a capacidade de escrever os seus, mas se você precisar de algo mais complicado que with_subelements , é hora de repensar suas estruturas de dados.

4. Use tags. Você pode definir ações usando uma combinação de grupos e tags.

5. Use register s para capturar o resultado de suas ações e usá-las em ações subsequentes para controlar o fluxo usando as instruções when . Não complique as condições, no entanto.

6. set_facts e assert podem ajudar a coletar dados sobre o status do sistema de destino.

7. Idempotência. Mantenha suas ações idempotentes para que você elimine a necessidade de construir muita lógica em suas ações. Pense em termos de staus de destino (estado desejado) e não em termos de linguagem procedural.