Por que Ansible e não outras Ferramentas de Gerência de Configuração?

Automação para Sysadmins

Introdução:

Todo dia é a mesma rotina para um Sysadmin à moda antiga: Criar e Alterar VMs manualmente, customizar o S.O, liberar o sistema operacional com os últimos pacotes atualizados, ajustar as configurações em ambientes já provisionados, criar rotinas com shell script (na maioria das vezes sem possibilidade de reuso), atualizações de aplicações de forma manual (copiar arquivos, reiniciar instâncias, checar o estado dos serviços): todos sujeitos a falhas humanas, prejudicando a padronização do ambiente.

Tudo isso gera atrasos, desmotivação (com trabalhos repetitivos) e baixa produtividade e dificulta a escalabilidade dos serviços. Em ambientes administrados por um desses Sysadmins, a cultura DepOps está na maturidade zero e a Infraestrutura como código (Infra as Code) ainda não faz parte da rotina de trabalho.

Para tentar resolver esses problemas é necessário entrar no mundo da automação, utilizando ferramentas modernas de gerência de configuração, provisionamento e orquestração.

Automação de Infraestrutura:

Todas as ferramentas disponíveis (Ansible, Puppet, Saltstack, Chef, CFEngine) permitem a automação de infraestrutura, automação cloud, gerenciamento de conformidade e segurança, fluxo automático para integração e deploy contínuo (CI/CD). Qual ferramenta escolher para iniciar a automação do ambiente?

A difícil tarefa de prospectar uma dessas ferramentas afasta o Sysadmin de evoluir tecnicamente e propor melhorias no ambiente administrado. Eles trabalham à moda antiga e são conservadores e avessos à mudanças, onde “não se mexe em time que está ganhando”. Os Sysadmins precisam se atualizar em relação a automação e os estudos iniciais os levarão para diversas ferramentas que, teoricamente, fazem a mesma coisa. Isso pode tornar o trabalho um pouco traumático e desmotivador para quem está começando.

Qual a melhor ferramenta para quem está com maturidade zero em automação?

A resposta rápida para todas essas perguntas: Ansible

Mas porque Ansible e não outra ferramenta nestes casos?

1) Tudo-em-um: Simplificando a automação

O Ansible pode ser considerado um “tudo-em-um” (All-in-one): Todas etapas da automação podem ser feitas com Ansible. Isso deve se ao fato que o Ansible foi desenvolvido em Python e, além de herdar a característica da linguagem de propósito geral, já usufrui dos milhares de pacotes existentes da comunidade Python para criar seus próprios módulos.

O Ansible possui atualmente mais de 1300 módulos em diversas áreas da infraestrutura: Web, Banco de Dados, Rede, Nuvem, Cluster, Monitoramento, Windows, Storages e outros.

Sabemos que outras ferramentas trabalham melhor em alguma etapa, mas em um ambiente com maturidade zero de automação, o Ansible pode ajudar uma equipe a alcançar mais rapidamente uma maturidade mínima de automação.

Gerência de Configuração: Código, ciclo de vida e mudanças podem ser feitas através do inventário, playbooks e roles no Ansible. É possível gerenciar estados desejados e idempotência nativamente nas tarefas que serão executadas.

Orquestração: Motor simplificado e poderoso de orquestração. O Ansible se integra com quase todas as áreas da infraestrutura, desde o provisionamento de VMs até liberação de regras no firewall. Também foca nas áreas onde outras ferramentas deixam lacunas tais como parada zero, atualizações contínuas para aplicações multi-camadas em toda a infraestrutura.

Provisionamento: O Ansible possui módulos para containers (Docker), Virtualização (VMware, AWS, OpenStack, Azure, Ovirt) e podem facilmente se integrar com outras tarefas das etapas anteriores.

2) Baixa Curva de Aprendizado:

O Ansible tem um aprendizado muito rápido, sendo fácil a instalação e configuração inicial. Em menos de 30 minutos é possível instalar, configurar e executar comandos Ad-hoc para ’n’ servidores para resolver um problema específico: Ajustes de horário de verão, sincronização de hora, troca de senha de root, atualizar servidores, restartar serviços, etc.

A sintaxe e o fluxo de trabalho são de simples de compreensão, facilitando o aprendizado de novos usuários. Os arquivos utilizam um padrão YAML (YAML Ain’t Markup Language), um padrão de linguagem declarativa de dados amigável, que é amplamente utilizado por outras ferramentas e de fácil entendimento, além de utilizar a linguagem Python para estender as funcionalidades do Ansible com módulos customizados.

3) Infraestrutura Mutável

Sabemos que o modelo antigo de infraestrutura leva um tempo para convergir para ambiente totalmente automatizado (Infra as Code). Os ambientes administrados por Sysadmins são constantemente modificados (Infra mutável) e qualquer mudança é onerosa, gera desgastes e muitas intervenções manuais. O Ansible se adapta bem para ambientes mistos, convivendo sem problemas com ambientes parcialmente ou majoritariamente automatizados. A transição de um modelo para outro será menos traumática com Ansible.

4) Sem Agentes: Somente um “Ansible Control”

Ansible não necessita de agentes instalados nas pontas. A única necessidade é um servidor com Ansible instalado (Ansible Control) com acesso aos servidores a serem administrados (hosts) através dos protocolos SSH (para ambientes Linux) ou WINRM (Acesso remoto Windows) . As Playbooks empurram (push) as configurações desejadas nos hosts definidos no inventário e podem inclusive ser executadas Ad-hoc (via linha de comando sem a necessidade de definições em arquivos). O modelo sem agente efetua ajustes e comunicação mais rapidamente do que no modelo cliente-servidor.

O único requisito nos hosts Linux é ter o Python instalado. Hoje sabemos que o Python já vem instalado nativamente na maioria das distribuições Linux.

5) Automatize agora:

A partir do momento que você consegue dar um ‘ping’ (módulo de teste) nos hosts através do Ansible, você está apto para iniciar a automação do ambiente.

Inicie por partes ou pedaços, seguindo as boas práticas, dando prioridade para tarefas que agregam valor ao negócio e resolvem um grande problema ou retenção das demandas, ganhando tempo e mais produtividade.

Conclusão:

Equipes de Sysadmins que trabalham à moda antiga (tudo manual e com ferramentas improdutivas) precisam urgentemente aderir a automação de infraestrutura. Será um trabalho árduo de convencimento e engajamento, mas resultará em grandes ganhos para a equipe e a organização com a escolha do Ansible.

A escolha do Ansible pode ajudar a equipe resolver rapidamente seus “calcanhares de aquiles”, além de aumentar a produtividade e promover, por “tabela”, a colaboração e satisfação com o trabalho.

Vá direto neste caminho e seja feliz: Automatize o parte pesada, chata e repetitiva com o Ansible e tenha tempo para se tornar mais criativo.

Extra: Ansible é considerado Gerência de Configuração ou não?

Existem diversas discussões na internet sobre se o Ansible é considerado uma ferramenta de Gerência de Configuração. A parte teórica da gerência de configuração se baseia na escola de GCONF apresentado por Mark Burgess, criador do CFEngine, onde o mesmo diz que os princípios do GCONF são Idempotência e estado desejado.

Idempotência é a característica de verificar o estado atual do que será modificado. Se já estiver no estado desejado, nenhuma ação será realizada. O Ansible na versão 2.3 possui mais de 1300 módulos que, na maior parte, seguem o princípio da idempotência. Nos casos em que o Ansible não possui um módulo nativo, há disponível um conjunto de “módulos de comando” (shell, raw, telnet, command, script), que precisam de um tratamento para que se tornem idempotentes, através de atributos “args” ou diretivas apropriadas (when, when_changed, when_failed etc).

Quanto ao item convergência, o criador do Ansible, Michael DeHaan, afirmou no grupo de discussão do Ansible:

“Esta coisa de estado desejado de vez em quando é escrita de forma errada como ‘Convergência’… Convergência tipicamente significa rodar o processo 4 ou 5 vezes até conseguir chegar no estado desejado. Isso é terrível se você quer dar somente um apenas um salto… A indústria está um pouco atormentada com a ideia de que coisas simples devem ser falada em termos complexos e o Ansible não é bem assim. O nosso objetivo é simples — falado em inglês claro: Get Stuff done (faça acontecer)”, em tradução livre.

Logo, não seja induzido ao erro de imaginar que o Ansible não pode ser utilizado como uma ferramenta de Gerência de Configuração. Versione o seu código, utilize uma ferramenta de gerência de jobs (Rundeck, Jenkins, Tower, AWX ou o próprio Ansible-pull), mude o fluxo de mudanças (para utilizar Infra como código) e mantenha o seu ambiente em conformidade, atualizado e no estado desejado.