Infraestrutura como Código (IaC)

Automatizando o provisionamento de servidores com o Ansible

Nilton Junior
Venturus

--

Ansible é uma ferramenta que permite gerenciar ambientes complexos como clouds, máquinas virtuais e uma infinidade de servidores simultaneamente.

Antes do conceito de Infraestrutura como Código (IaC) preparar e entregar um servidor provisionado contemplando todas as customizações necessárias no sistema operacional, atualizações de pacotes, instalação e configuração de aplicações, era uma tarefa árdua, despadronizada e muito suscetível a falhas humanas. Impulsionada pela necessidade de atender cada vez mais rápido o mercado de tecnologia por meio das práticas da cultura DevOps, a automatização de tarefas repetitivas através de ferramentas modernas de orquestração e gerenciamento de configuração, como o Ansible, tornaram possível a entrega de uma infraestrutura ágil, aprimorando o controle, a segurança e a qualidade na disponibilização de ambientes de desenvolvimento, testes ou produção.

O Ansible, assim como outras ferramentas bastante populares (Chef, Puppet, SaltStack), é uma ferramenta que permite gerenciar ambientes complexos como clouds, máquinas virtuais e uma infinidade de servidores simultaneamente. Suas principais vantagens são:

Curva de aprendizado baixa: A linguagem utilizada para escrever as tarefas a serem executadas é simples e objetiva. Trata-se de uma linguagem de marcação (na verdade serialização) chamada YAML, bem amigável. As rotinas escritas podem ser facilmente compreendidas por profissionais do suporte, desenvolvedores ou gerentes de TI.

Dispensabilidade de agentes: Ao contrário de seus concorrentes, o Ansible não precisa de um agente instalado na máquina destino. A comunicação se dá através do protocolo SSH. Para isto, o mais comum é a utilização de troca de chaves entre a máquina que irá disparar as ações e a que receberá, mas também é possível informar a senha durante a execução.

Execução ordenada: A execução das tarefas ocorrerá na ordem em que forem escritas. Parece algo meio óbvio, mas em algumas ferramentas, como o Puppet, há a necessidade de criar relações entre os passos que serão executados.

Idempotência: Esta propriedade da ferramenta garante que seus módulos não executem uma ação que não causaria efeito no sistema. Em outras palavras, se algo já foi executado ou encontra-se no estado desejado, não precisará ser executado novamente.

Replicação: A partir do momento em que dispomos do código para o provisionamento de um ambiente, temos controle do que está instalado nele e podemos recriá-lo quando quisermos ou mesmo criar réplicas, executando o comando novamente.

Controle de versão: Este código de provisionamento terá um padrão de escrita, uma sintaxe e, consequentemente, seguirá melhores práticas. Poderá ser armazenado em um repositório Git, por exemplo, no qual será preservado seu histórico e versões anteriores. Isto permitirá um acompanhamento da evolução de suas mudanças, bem como a reutilização e compartilhamento do código, uma vez que o conhecimento da infraestrutura estará em um repositório e não mais restrito apenas ao administrador de sistemas que configurava o ambiente manualmente.

Extensível: O Ansible possui um repositório chamado Ansible Galaxy onde é possível encontrar módulos para os mais diversos fins. É provável que neste repositório você encontre rotinas escritas pela comunidade para grande parte dos serviços que se queira automatizar. O conteúdo disponível também poderá servir como inspiração para criar suas próprias rotinas.

Excelente documentação: Os módulos, sobretudo os já incorporados ao “core”, são muito bem documentados, contendo o detalhamento de cada parâmetro e exemplos de utilização. A documentação encontra-se disponível através do link: http://docs.ansible.com.

Instalação

A instalação do Ansible é bem simples, bastando a execução de um único comando conforme exemplos abaixo:

Mac: brew install ansible
Ubuntu: apt-get install ansible

Terminologia

Playbook: Arquivo com as diretrizes de provisionamento que serão executadas nos hosts remotos.

Role: Cada playbook possui uma ou mais “roles”, que são as informações de provisionamento. Uma “role” pode ser organizada com os diretórios defaults, files, handlers, meta, tasks, templates e vars. Descreverei mais detalhadamente a finalidade de cada um deles posteriormente.

Task: Uma task é o principal componente de uma role. São as ações propriamente ditas que serão executadas para provisionar os hosts desejados.

Module: Os módulos atuam como facilitadores para escrever as tasks.

Inventory: Arquivo de inventário no qual são declarados quais hosts serão gerenciados pelo Ansible.

Layout de Diretórios

Existem muitas formas de organizar o conteúdo de um playbook. Esta organização é flexível, podendo ser ajustada de acordo com sua necessidade. Segue um bom exemplo de organização:

.
├── group_vars
│…..└── vars
├── inventories
│…..└── servers
├── production.yml
└── roles
…….└── role
…….…….├── defaults
.………….│…..└── main.yml
…………..├── files
.……….…│…..└── file
…………..├── handlers
………….│…..└── main.yml
…………..├── meta
…………..│…..└── main.yml
…………..├── tasks
…………..│…..└── main.yml
…………..├── templates
…………..│…..└── template.j2
…………. └── vars
………………..└── main.yml

group_vars: Diretório contendo arquivo onde são definidas variáveis globais compartilhadas com todos os playbooks.

inventories: Diretório contendo grupos de hosts que serão referenciados na execução do playbook. Pode ter qualquer nome.

production.yml: Playbook contendo informações como qual o grupo de hosts sofrerá as ações e quais roles serão executadas.

roles: Diretório onde serão armazenadas as roles.

role: Diretório de uma das roles. Pode ter qualquer nome.

defaults: Diretório contendo arquivo onde são definidas variáveis padrões para funções sem prioridade.

files: Arquivos estáticos que pretende-se transferir para os hosts remotos durante a execução das tarefas.

handlers: Diretório contendo tarefas que respondem a eventos. De modo geral, os handlers são utilizado para a manipulação de serviços (iniciar, reiniciar, parar…)

meta: Diretório contendo arquivo que serve para preencher os dados de informação sobre sua role dentro da base do Ansible Galaxy.

tasks: Diretório contendo os arquivos com as tarefas que serão executadas. No arquivo “main.yml” é possível haver “includes” para outros arquivos de tarefas.

templates: Arquivos que serão modificados em tempo de execução de acordo com as variáveis definidas nos mesmos. Após a transferência, teremos no host remoto o arquivo com as devidas substituições das variáveis por seus valores.

vars: Diretório contendo arquivo onde são definidas variáveis compartilhadas apenas dentro da role.

Execução

Abaixo, um exemplo de execução de um playbook com os parâmetros básicos:

ansible-playbook production.yml -i production

Conclusão

A primeira vista, pode parecer que automatizar o provisionamento de ambientes dá muito trabalho. Entretanto, nos dias atuais, um administrador de sistemas precisa gerenciar cada vez mais servidores. O avanço e a popularização de tecnologias como a virtualização ou a computação em nuvem, impulsionaram esta crescente. Para se ter uma ideia, estima-se que um único administrador de sistemas da Google gerencie cerca de 5000 servidores. Tarefa que é impossível de se realizar sem automação. O mercado de tecnologia espera por soluções rápidas e confiáveis, no entanto, configurar e administrar manualmente um servidor claramente vai contra isto.

--

--