Aventuras com o Ansible: lições aprendidas com implantações reais

O Ansible é uma eficiente ferramenta de automação da TI. E como a maioria das ferramentas avançadas, leva tempo para dominá-la. E você precisa aprender a fazer isso bem e com segurança no seu ambiente.

Por usar o Ansible para automatizar a implantação e o gerenciamento de aplicações corporativas, eu já aprendi algumas lições que considero as melhores práticas para automatizar com o Ansible. E gostaria de compartilhar essas lições para ajudar outras pessoas. Essa é, afinal de contas, a filosofia open source. Leia este guia para iniciantes do Ansible se você estiver dando os primeiros passos com a ferramenta.

Trabalho com software corporativo há muito tempo, desde bem antes do Ansible existir. Lembro de quando a implantação trimestral no ambiente de produção acontecia de madrugada com um grupo de pessoas que ficava à disposição para fazer o lançamento funcionar. As implantações eram caras, complexas, inconsistentes e frustrantes em tantos sentidos.

E é necessário muito trabalho técnico e cultural para mudar isso e aprender a automatizar a implantação de software com rapidez e regularidade. Vou falar dos aspectos culturais em outro post. Agora, quero falar sobre algumas práticas que aprendi com o Ansible para aproveitar ao máximo suas funcionalidades e comunidade.

Padrões

Há três pontos importantes quando falamos de automação:

1. padrões,

2. padrões e...

3. isso mesmo, padrões.

Pode ser fácil e divertido escrever um playbook pequeno para realizar uma tarefa administrativa específica. No entanto, quando você desenvolve centenas de playbooks/funções para a implantação automatizada de um stack de software completo em vários ambientes, precisará de uma grande quantidade de elementos de configuração, e isso é bem complicado. Além disso, o número de playbooks e funções só aumentará se você não reutilizar as funções e desenvolver padrões. Este tutorial sobre playbooks do Ansible vai ajudar você a dar os primeiros passos no caminho para o sucesso.

Desde o começo, busque modos de padronizar seus playbooks, funções e outras práticas com o Ansible para que a equipe possa reaproveitar o máximo possível e entender como as coisas funcionam.

Uma galáxia muito, muito distante

O Ansible Galaxy, o repositório centralizado de funções da comunidade do Ansible, está aqui para ajudar você. Ele foi projetado para ser reutilizado por outros usuários do Ansible. Sempre confira o Ansible Galaxy para ver se alguém já solucionou um problema que você está enfrentando.

Porém... Siga com cuidado. O conteúdo do Galaxy pode ser reutilizado, mas você deve examiná-lo e entendê-lo antes de integrá-lo ao seu ambiente. É capaz de você prejudicar bastante seu ambiente em um curto espaço de tempo se usar uma função que faça algo inesperado.

Crie um inventário sólido

O Ansible consegue trabalhar simultaneamente as máquinas na sua infraestrutura ao confiar no inventário para enumerar diferentes grupos de sistemas e definir os grupos por carga de trabalho ou outra característica. O Ansible também consegue trabalhar com um sistema de inventário dinâmico para ambientes em que o número de hosts varia com a demanda.

O inventário do Ansible pode se tornar muito complicado, com rapidez, quando se lida com aplicações corporativas com uma grande quantidade de informações de configuração.

Por exemplo, tínhamos um grande número de arquivos XML com informações de configuração no nosso software middleware. Criamos modelos Jinja e transferimos os elementos de configuração dos arquivos XML para o inventário do Ansible. Os arquivos foram gerados com facilidade e enviados para os servidores de destino. E para lidar com os vários ambientes, nós resolvemos usar um plug-in do Vars personalizado em Python para carregar apenas dados de configuração específicos para a estrutura customizada de pastas do inventário.

Ei, cara, vamos manipular.

Manipuladores são um conjunto de tarefas que são executadas quando notificadas. Mas isso só acontece se elas forem realmente notificadas e somente uma vez por playbook. Por exemplo, você pode configurar um playbook com manipuladores que são acionados por eventos específicos, como a reinicialização de um serviço ou aplicação. Usar manipuladores em uma função do Ansible que gerencie um determinado serviço é ótimo para criar tarefas claras e compreensíveis no arquivo "handlers/main.yml" que podem ser acionadas por mudanças no serviço.

Quando comecei a trabalhar com o Ansible, não havia manipuladores, então eu posso falar com experiência sobre como era a vida sem essa funcionalidade. Sério, não deixe de usá-la!

Idempotência: aprenda, viva, ame

A idempotência é um estilo de vida para a automação da TI. Você precisa compreendê-la e, em seguida, utilizá-la sempre que escrever códigos de automação. E o que é isso? Para citar o glossário do Ansible, uma operação "é idempotente se o resultado da sua execução é sempre o mesmo sem que haja qualquer intervenção".

A conclusão é que você pode executar seus playbooks várias vezes e o resultado final deveria ser o mesmo: os servidores de destino estarão no "estado desejado". Se o playbook falha em um pequeno conjunto de servidores, é possível solucionar o problema e executar o playbook novamente. Como o playbook é idempotente, os servidores de destino precisam estar no "estado desejado" e nenhuma outra mudança ocorrerá.

O que há em um nome?

Sempre, sempre, sempre nomeie suas tarefas. Parece bobo dizer isso, e é quase como se eu estivesse pedindo a você para adicionar comentários ao seu código, mas é muito importante escrever um nome legível para a sua tarefa para que os outros possam saber o que ela deveria estar fazendo. Siga algumas regras simples:

1. Não escreva comentários de programação tradicionais, como "#isso é um comentário", nos playbooks do Ansible. Lembre que o Ansible não é uma linguagem de programação, é uma ferramenta de automação.

2. Em vez disso, use "Name" para descrever o playbook ou a tarefa com explicações legíveis. Descreva suas intenções, mas evite ser muito técnico.

O maior benefício de usar a propriedade "Name" em cada playbook ou tarefa é que a informação é exibida durante a execução dos playbooks. Isso ajuda a diagnosticá-los. Os comentários, no entanto, não são exibidos na saída da execução.

Na minha experiência, playbooks/funções/tarefas são escritos por muitas pessoas na empresa, começando com as equipes de desenvolvimento e operações, e normalmente precisamos saber quais são as intenções para cada tarefa.

Variáveis: nome e precedência

Tome cuidado ao nomear suas variáveis no inventário, playbooks e funções do Ansible. Lembre, o Ansible atribui cada variável a um host específico, também conhecido como Variáveis de host. Cuidado ao usar nomes genéricos para suas variáveis, como "java_path: /my/path". Há a possibilidade de que outra aplicação no mesmo host use Java e tenha um caminho diferente. Muitas vezes, há várias aplicações no mesmo host, mas elas usam diferentes versões do Java que estão armazenados em diversos caminhos.

Escolha nomes diferentes para as variáveis, coloque prefixos personalizados em variáveis com o nome da empresa e torne-os legíveis. Por exemplo, a empresa ABC criou variáveis de inventário personalizadas para uma aplicação chamada AppOne que usa a versão 1.8 do Java.

abc_appone_java_path: "/opt/appone/java" abc_appone_java_version: "1.1"

Não copie e cole

Vou explicar um pouco mais. Faça o que é certo e crie funções que possam ser reutilizadas, em vez de copiar e colar códigos de um playbook para o outro. Desse modo, você pode editar a função uma única vez e as dependências utilizarão a última versão automaticamente, em vez de buscarem diretivas desatualizadas ou serem prejudicadas por algum comportamento inesperado ao executar um playbook meses depois.

Ame seu ambiente

Use o IDE que preferir com o Ansible. Afinal, é uma simples sintaxe YAML. No entanto, você deve ter um IDE que possa ajudar você a fazer o seu trabalho. Estas são algumas funcionalidades que eu considero essenciais para um IDE ao criar playbooks e funções do Ansible:

• Destaque de sintaxe YAML e compatibilidade com lint

• Destaque de sintaxe Python e compatibilidade com lint. O Ansible foi escrito em Python, e acredite quando digo que você terá que analisar o código-fonte algumas vezes

• Sistema de controle de versão integrado

• Integração com JIRA. Você pode gerenciar as alterações em vários tickets ao mesmo tempo

• Localizar e substituir com eficiência. Algumas vezes você precisará alterar, remover ou realocar variáveis do Ansible de diversas fontes, e terá que localizar todas as referências

• Compatibilidade com a linguagem Ruby, caso você queira editar arquivos do Vagrant

• Compatibilidade com a linguagem Groovy, se você quiser codificar suas tarefas do Jenkins

Ao adotar essas práticas, você estará um passo a frente e evitará os erros que eu cometi quando usei o Ansible na automação e implantação de software corporativo. Você estará livre para errar de um jeito só seu! Para mais informações sobre as práticas recomendadas para o Ansible, consulte a seção de práticas recomendadas da documentação do Ansible, faça o download da checklist de automação corporativa e fique de olho no Blog da Red Hat e no Blog do Ansible.