Convenções para iniciar / parar comandos em playbooks Ansible

Question

Sou um novo usuário Ansible e estou curtindo até agora. Estou usando o Ansible para definir e aplicar configurações de servidor da web. Eu estou usando playbooks. Digamos que eu tenha uma função para instalar e configurar o Nginx, as tarefas são definidas em roles/nginx/tasks/main.yml e referenciadas em ./site.yml , para que sejam sempre executadas quando eu provisionar novos servidores. Algo como este exemplo: link . Isso está funcionando muito bem, mas de vez em quando eu quero explicitamente parar, iniciar ou reiniciar o Nginx. Eu sei como conseguir isso usando Ansible, mas minha pergunta é em torno de convenções ou práticas comuns. Eu deveria ...

Criar iniciar, parar e reiniciar tarefas dentro da pasta da função Nginx? E se sim, como devo declarar e invocá-los. É claro que eu não deveria simplesmente adicioná-los ao main.yml ou eles serão invocados sempre que eu provisionar um novo servidor. Devo criar roles/nginx/tasks/start.yml , roles/nginx/tasks/stop.yml etc e invocá-los como ansible-playbook -i staging nginx/roles/stop.yml .

Ou não devo declará-las em um playbook, mas sim executá-las usando ansible , como ansible webservers -i staging -a "nginx stop" -s .

C. Quaisquer outras sugestões sobre a melhor maneira de conseguir isso.

Muito obrigado (:

    

Answer 1

Se for uma ação ad hoc, seu ambiente é pequeno e não muito complexo, todos os envolvidos são informados, você quer voltar ao normal em dois minutos e não se importa se a próxima execução ansiosa mudasse isso ( por exemplo, o serviço interrompido é reiniciado, porque a definição do estado do serviço em seu ansioso playbook diz que sim, então vá em frente com B. Esteja ciente de que você muda o estado do sistema divergindo do que sua descrição em ansible diz…

Se você quiser deixar as coisas mais claras, a solução A é um bom ponto de partida. Você pode criar as definições apropriadas para nginx parado, iniciado, etc., mas no geral é como B, só que as tarefas são definidas em alguns arquivos.

Quanto ao C, você pode desenvolver um pouco mais: tornar o estado dependente de uma variável. Desta forma, você pode tornar explícito o estado desejado em sua configuração ansible. Por que uma variável e não alterar o estado na definição de serviço? Em cenários mais complexos (digamos, iniciar / interromper vários serviços juntos), isso ajuda você a manter as coisas claras e simples. Se você tiver vários ambientes (armazenamento temporário, produção, etc.), isso facilita manter as definições inalteradas enquanto altera o estado em apenas um ambiente.

Tornar as coisas explícitas oferece algumas vantagens:

• está documentado para os outros (e para o seu futuro) ver

• executar ansible independentemente da sua tarefa não irá interferir (dado que todos têm o estado atual)

• se você executar ansible automaticamente - acionado a partir do controle de versão -, você poderá usar isso para alterar o estado e também a alteração de volta

Answer 2

Manter todas as tarefas sobre uma coisa em uma função não é obrigatório. Além disso, se você chegar dentro de um papel para um subconjunto de suas tarefas, parecerá uma brecha feia de abstração. Eu sei, eu fiz isso.

Por exemplo, um manual de atualização da Web poderia, com suas próprias tarefas, copiar o conteúdo para a raiz da web e reiniciar o nginx, se necessário.

O que é particularmente poderoso é descrever o estado inteiro em um dos manuais. Chame a função nginx e, em post_tasks, copie também o conteúdo para este site específico. Seu site estará lá, instalando o nginx se necessário. Esse nginx foi reiniciado foi simplesmente um efeito colateral quando a tarefa do manipulador foi chamada.