Vitualização de Ambientes - Provisionando com o Ansible - Parte 3
Chegamos finalmente a última parte da série de artigos sobre ambientes virtualizados, e agora vamos conhecer sobre uma ferramenta que forma um casamento perfeito com o Vagrant, e que será de total importância para a automação dos ambientes que serão utilizados para o desenvolvimento, o Ansible. Anteriormente, entendemos no artigo Virtualização de Ambientes - Uma introdução ao conceito e Vagrant, os conceitos por trás dessa abordagem para uma equipe de TI e seus benefícios, e no artigo Virtualização de Ambientes – Vagrant em ação, conhecemos uma ferramenta apropriada para implementar tais conceitos, o Vagrant.
Por que o Vagrant pode formar um casamento ideal com o Ansible?
O Oásis!
Uma andorinha só não faz verão.
Esse ditado teoricamente "não-popular", pois sua primeira menção está no livro Ética a Nicômano, de Aristóteles (384-322 a.C.). Mas que convém totalmente com o sentido desse artigo, nesse caso, a nossa andorinha (o Vagrant) sozinha, tem pouca utilidade, pois ao longo do tempo, se tornará extremamente complicada de se manter ou fazer alterações de ambiente sem uma ferramenta especifica para isso. O Vagrant por si só, instala e gerencia uma máquina virtual, mas o que vai estar instalado dentro de nossas máquinas virtuais? Conseguimos instalar tudo de forma automatizada? É possível atualizar um software e replicar de forma automática para todos?
A resposta é simples e direta, sim!
Porém, precisamos de uma ferramenta para isso, provisionar e configurar as maquinas de forma que não seja necessária nenhuma intervenção manual para o seu total funcionamento, já que o Vagrant não se responsabiliza por fazer isso, por esse motivo iremos conhecer o Ansible e alcançar o Oásis em meio a esse deserto.
Ansible
O Ansible é frequentemente descrito como uma ferramenta de gerenciamento de configuração, e é tipicamente mencionado na mesma categoria que o Chef, Fantoche e Salt. Quando falamos de gestão de configuração, estamos falando sobre a escrita de algum tipo de descrição do estado que nossas maquinas devem estar, e em seguida, utilizar alguma ferramenta para garantir que as maquinas estarão configuradas de tal forma nesse estado: os pacotes necessários instalados, arquivos de configuração no lugar correto, permissões configuradas, garantir que os serviços estejam em execução, e etc. Como outras ferramentas de gerenciamento de configuração, Ansible expõe uma linguagem específica de domínio (DSL) que deve ser usada para descrever o estado de suas maquinas.
Como funciona o Ansible?
Vamos ver um exemplo simples, para entendermos de maneira básica, como o Ansible funciona. Um usuário está usando Ansible para configurar sua máquina virtual baseados no Ubuntu para executar o nginx. O usuário escreveu um script Ansible chamado playbook.yml. No Ansible, um script é chamado de playbook. Um playbook descreve o que deve ser instalado e uma lista ordenada de tarefas a serem executadas. Neste caso, vamos ter as seguintes tarefas:
- Instalar nginx
- Gerar um arquivo de configuração nginx
- Copiar o certificado de segurança
- Iniciar o serviço nginx
Para chamar esse playbook, vamos utilizar o comando ansible-playbook:
$ ansible-playbook playbook.yml
O Ansible fará conexões SSH na maquina virtual. Neste exemplo, a primeira tarefa é instalar o pacote apt nginx (uma vez que o Ubuntu usa o gerenciador de pacotes apt), então a tarefa no playbook será algo parecido com isto:
Ansible irá:
- Gerar um script Python que instala o pacote nginx;
- Copiar o script para a maquina virtual;
- Executar o script na maquina virtual;
- Esperar até o termino da execução do script.
O Ansible, então, irá passar para a próxima tarefa na lista, e passar por esses mesmos quatro passos. É importante notar que:
- Ansible executa cada tarefa em paralelo (se houver necessidade);
- Ansible aguarda uma task terminar completamente até começar a próxima;
- Ansible executa as tarefas na ordem que for especificada no playbook.
O que faz o Ansible tão bom, além de automatizar?
- Não é necessário instalar nada no host para rodar o Ansible
Para gerenciar um servidor ou maquina virtual com o Ansible, é necessário ter SSH e Python 2.5 ou superior instalado, ou Python 2.4 com a biblioteca simplejson instalado. Não há nenhuma necessidade de reinstalar um agente ou qualquer outro software no host.
- Sintaxe simples de ler e escrever
A sintaxe de um playbook com o Ansible é construída em cima do YAML, que é uma linguagem de formato de dados que foi projetada para ser fácil para os seres humanos entenderem, tanto para ler quanto para escrever. De certa forma, YAML é para o JSON o que o Markdown é para o HTML.
É interessante notar que os playbooks funcionam como uma documentação executável. É como o arquivo README que descreve os comandos que você deve digitar para rodar seu software, exceto que as instruções nunca ficam desatualizadas, pois elas são o código que é executado diretamente.
- Camada fina de abstração
Algumas ferramentas de gerenciamento de configuração fornecem uma camada de abstração para que você possa usar os mesmos scripts de gerenciamento de configuração para gerenciar servidores que executam sistemas operacionais diferentes. Por exemplo, em vez de ter que lidar com um gerenciador de pacotes específico, como yum ou apt, a ferramenta de gerenciamento de configuração expõe uma abstração.
Ansible não é assim. Você tem que usar o módulo apt para instalar pacotes em sistemas apt-base e o módulo yum para instalar os pacotes em sistemas baseados no yum.
Embora isso possa soar como uma desvantagem, na prática, faz com que seja mais fácil trabalhar com o Ansible. O Ansible não exige que eu aprenda um novo conjunto de abstrações que escondem as diferenças entre sistemas operacionais. Isso faz com que a curva de aprendizado seja menor; há menos para conhecer para que você comece a escrever playbooks.
Se você realmente quiser, você pode escrever seus playbooks e tomar medidas diferentes, dependendo do sistema operacional do host. Mas é bom evitar quando possível, e ao invés disso, se concentrar em escrever playbooks que são projetados para ser executado em um sistema operacional específico, como o Ubuntu.
A unidade primária de reutilização na comunidade Ansible é o módulo para um software. Como o escopo de um módulo é pequeno e pode ser focado em um sistema operacional específico, é mais simples de implementar módulos compartilháveis bem definidos. O projeto Ansible é muito aberto a aceita módulos feitos pela comunidade.
Playbooks não tem como foco serem reutilizados em diferentes contextos. Vamos discutir um pouco sobre roles, que é uma maneira de criar uma coleção de playbooks e assim se tornarão mais reutilizáveis, como o Ansible Galaxy, que é um repositório on-line desses roles.
Existem mais features, mas no contexto desse artigo, não vale a pena mencionar para não extender muito o assunto.
E na prática, cada organização configura seus hosts de maneira diferente, e uma melhor prática é escrever seus próprios playbooks, ao invés de tentar reutilizar playbooks genéricos. Eu acredito que o valor primário de olhar para playbooks de outras pessoas é para servir como exemplo para ver como as coisas são feitas.
Roles/Papéis
No Ansible, o role é o principal mecanismo para desmembrar um playbook em vários arquivos. Isso simplifica a escrita playbooks complexos, e também os torna mais fáceis de reutilizar. Pense em um papel como algo que você atribui a um ou mais hosts. Por exemplo, você poderia atribuir uma função de banco de dados para os anfitriões que atuarão como servidores de banco de dados.
Um papel Ansible tem um nome, como "database". Para acessar os arquivos associados ao banco de dados, basta ir no diretório roles/database, que contém os seguintes arquivos e diretórios.
roles/database/tasks/main.yml
Tasks
roles/database/files/
Arquivos que iram para os hosts
roles/database/templates/
Arquivos de template Jinja2
roles/database/handlers/main.yml
Handlers
roles/database/vars/main.yml
Variáveis que não devem ser sobrescritas
roles/database/defaults/main.yml
Variáveis default que podem ser sobrescritas
roles/database/meta/main.yml
Meta informação sobre o role
Cada arquivo desses é opcional; Se o seu role não ter nenhum Handler, por exemplo, não há necessidade de ter um arquivo vazio handlers/main.yml.
Quando usamos roles, temos uma seção somente para ele em nosso playbook. A seção de roles no playbook espera uma lista de roles que serão configurados e instalados. No nosso exemplo, nossa lista contém dois roles, mongodb e node, como podemos ver a seguir:
Para montarmos o nosso ambiente com o Stack MEAN, precisamos instalar apenas o Node/NPM e o MongoDB, o Express deve ser instalado via NPM no package.json do projeto, o Angular pode ser instalado via NPM, ou então instalado via Bower.
Vale a pena olharmos para atual configuração do Vagrantfile, e verificarmos como está agora:
Agora é possível analisar que na linha 16, existe a configuração para o provisionamento da maquina virtual, dizemos ao Vagrant que quem irá cuidar disso é o próprio Ansible, e passamos o caminho de onde está o playbook, de forma natural, ao inicializar o Vagrant vai fazer o provisionamento da maquina. Existe também a possibilidade de haver alguma alteração no playbook, ou em algum role, para refletir essa mudança para a maquina virtual, basta rodar o seguinte comando:
$ vagrant provision
E a maquina vai ser provisionada novamente.
O projeto está no github, e pode ser acessado a qualquer momento. Sugestões podem vir através de pull request. Projeto Vagrant & Ansible.
Conclusão
Chegamos ao final dessa série de artigos, que no final, visa agregar valor a qualquer equipe de TI e fomentar o assunto. Agregar valor ao entregar um ambiente de desenvolvimento de forma extremamente rápida para qualquer novo membro em uma equipe, ou até mesmo emular um ambiente em alguma máquina diferente, as possibilidades são ilimitadas. Fomentar o assunto, pois é valido entender o sentido real do Vagrant e enxergar o seu valor, que pode ser muito grande se empregado de maneira correta, e também a intenção é estender o desejo do leitor pelo Ansible, uma ferramenta fantástica de provisionamento e configuração de maquinas, tanto virtuais como físicas, é possível com um playbook configurar centenas de maquinas de uma única vez, cuidar de um cluster interno, em cloud e etc.
Tratamos nessa série de artigos, da nossa infraestrutura para o desenvolvimento como código, um dos princípios básicos do Devops, trate a infraestrutura da sua equipe da mesma forma, e será possível diminuir o tempo de configuração e maximizar a produtividade do seu time de TI.