Idempotência no Ansible

Muito se argumenta sobre o Ansible ser ou não idempotente.

Minha opinião sobre isso vai um pouco além do “é” ou “não é”, mas mantenho um embasamento muito simples.

O que é idempotência ?

Idempotencia: “the property of certain operations in mathematics and computer science that can be applied multiple times without changing the result beyond the initial application”.

Até aí ok. As tasks do Ansible são idempotentes (não me venha falar sobre execução de comandos porque daí em nenhuma ferramenta isso é idempotente por natureza).

Porém há outro conceito importante: convergência.

Convergência seria a capacidade do sistema executar apenas as tarefas necessárias para se chegar ao estado desejado.

Opa… aqui já começa a polêmica.

Recomendo essa breve leitura sobre idempotencia e convergencia. https://stackoverflow.com/questions/30615588/difference-between-convergence-and-idempotence-in-chef

Estado desejado

Na minha opinião, o Ansible não trabalha com estado final desejado. E não é que ele não consiga, é que ele não se propôe à isso ! Muito da beleza do Ansible vem do seu não comprometimento com o estado final.

Exemplo: o time de infraestrutura possui roles e playbooks para tunning dos servidores. Os devs possuem roles para instalar e configurar suas aplicações (para flamewar sobre dev poder orquestrar os servidores, fale com a parede mais próxima). Dois times diferentes executando coisas em grupos de máquinas.

O nome disso é orquestração, nada tem a ver com descrever um estado final desejado. Afinal, uma task dos devs pode desfazer um tunning de uma task do pessoal de infra, e pro Ansible tá de boa.

Mesmo que você só use o Ansible à partir de uma control machine que apenas você controle, você ainda é capaz de, num mesmo playbook, dizer que um serviço tem que estar parado e depois dizer que tem que estar ativo e o Ansible fará as duas tasks como se elas não fossem conflitantes. Ou seja, qual o estado final do serviço ? Ele simplesmente não contesta isso.

Ansible não se preocupa com estado final, e isso é ótimo !

Voltando à convergência, então, não há preocupação com esse conceito em ferramentas de orquestração já que é um conceito que só existe quando se fala em descrever um estado final desejado.

Teoria da promessa

Tio Mark Burgues, criador do cfengine, descreveu um modelo que se aplica à ferramentas de gerência de configuração e que, dentre outras coisas, compara modelos baseados em “obrigação”, no qual um ponto entra e força um estado contra outro de “promessa”, no qual o alvo obtem informações sobre seu estado desejado e que, pra isso, precisa de um agente. O ansible não adota o modelo da teoria da promessa.

Recomendo a leitura de um overview da teoria da promessa aqui:

http://www.linuxjournal.com/content/promise-theory—what-it

Mais informações: https://en.wikipedia.org/wiki/Promise_theory

Conclusão

Você pode rodar o Ansible frequentemente, mas também pode rodar Puppet sem um servidor central.

A questão não é o quanto você pode martelar parafusos. Um alicate consegue bater/martelar, aparafusar, cortar e abrir cerveja, mas não é a ferramenta correta para absolutamente nada.

Não force a barra, use mais ferramentas.

Tambem recomendo essa (não tão resumida) leitura sobre idempotência e convergência comparando ferramentas de gerência de configuração (Chef, CfEngine e Puppet): http://chester.id.au/2012/06/27/a-not-sobrief-aside-on-reigning-in-chaos/

 

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s