Ansible é uma ferramenta poderosa para automação em TI e pode ser utilizada em um processo CI/CD durante a fase de implantação da aplicação. Jenkins é uma ferramenta amplamente conhecida para implementação de CI/CD.

Scripts shell são comumente utilizados para provisionamento de ambientes ou para implantar aplicações ao longo do pipeline. Embora funcione, ao longo do tempo esse processo pode ficar mais complicado ao realizar a manutenção e a reutilização desses scripts.

O propósito de se utilizar Ansible no pipeline CI/CD é reutilizar roles e playbooks Ansible para provisionamento, mantendo o Jenkins apenas como um orquestrador de processos, ao invés de um executor de scripts shell.

Para entender melhor esse cenário, criamos um laboratório exemplo utilizando ferramentas open source:

• Vagrant e libvirt responsáveis por sustentar o ambiente;
• SonarSource para trazer análise de qualidade para o processo de CI/CD;
• Maven para criar e implantar o projeto Java;
• GIT para gestão e controle de código fonte;
• Nexus como um repositório para artefatos binários;
• Jenkins para orquestração do fluxo do pipeline CI/CD;
• E finalmente, Ansible para configuração e inicialização de toda infraestrutura para o laboratório e provisionamento da aplicação.

A imagem abaixo ilustra a arquitetura geral do nosso laboratório. Ela possui alguns elementos de ALM (Application Lifecycle Management – Gestão do Ciclo de Vida da Aplicação) para emular um cenário de mundo real e aplicar nosso pipeline CI/CD.

Para construir essa infraestrutura, nós montamos um Ansible playbook utilizando roles da comunidade Ansible Galaxy. Se você é novo em Ansible, veja esse artigo sobre como começar.

O ambiente para as máquinas virtuais nesse laboratório foram gerenciadas pelo Vagrant com libvirt. Detalhes sobre como isso foi feito pode ser visto no projeto Vagrant ALM no GitHub.

Vamos explorar o pipeline CI/CD construído para este laboratório. Observe a figura abaixo:

Os detalhes de implementação deste pipeline podem ser vistos nesse repositório.

O processo começa buscando o código fonte da aplicação no Github. A próxima coisa a ser feita, é atualizar a versão do projeto de acordo com o número de compilação (por exemplo, minha-app-1.0.0-123). Deste modo, nós temos a identificação desse build durante o desenvolvimento. Mais tarde, pode ser utilizado como métrica e controle de processo. Depois que a versão do projeto for atualizada, o Jenkins começa a construir a aplicação utilizando o Maven.

Depois que a compilação é realizada com sucesso, o pipeline passa a executar os testes de unidade. Se nada der errado durante os testes, o pipeline inicia o teste de integração. Neste caso, o framework de testes utilizado cria toda a infraestrutura necessária para os testes: um banco de dados em memória com dados gerados dinamicamente e um pequeno web server para implantar a aplicação.

A saída dos testes de unidade e integração é um relatório de cobertura de testes, o qual vai ser um dos artefatos utilizados pelo SonarSource para gerar métricas de qualidade. O outro artefato é o código fonte de aplicação. Se o critério de qualidade definido no SonarSource não for cumprido, o pipeline vai falhar.

Se tudo correr bem, o pipeline para sua execução e aguarda pela aprovação. O servidor Jenkins provê uma interface para que alguém com as permissões corretas possa realizar a aprovação. A Figura 3 ilustra este processo.

Depois da aprovação, o pipeline continua a executar o fluxo e passa para a próxima etapa que consiste no upload do artefato compilado para o repositório Nexus. Assim, temos um novo snapshot da aplicação pronto para ser implantado.

Agora é hora do Ansible brilhar. O fluxo de pipeline apenas define os parâmetros necessários, como a URL do artefato compilado e o host de destino, para executar o Ansible playbook em seguida. O Playbook é utilizado para automatizar todas as configurações do host.

Neste exemplo, o utilizamos para instalar o Java e preparar o ambiente para receber a aplicação Spring Boot como serviço do sistema operacional. O Playbook instalará a aplicação como serviço e irá efetuar requisições consecutivas na sua porta HTTP até receber uma resposta válida para garantir que a implantação fora bem-sucedida.

Após a execução do Ansible Playbook, o último passo poderia ser o envio de uma notificação a cada stakeholder sobre os resultados da nova implantação via e-mail ou Slack, por exemplo.

Vimos como o Ansible pode ter um papel importante no pipeline de CI/CD. Pode-se dizer que ele nasceu para fazer isso. Dessa forma, o pipeline de CI/CD não irá se preocupar em como implantar um aplicativo ou se a máquina foi provisionada adequadamente; ele apenas delega para o Ansible a implantação do aplicativo.

Um dos benefícios do Ansible é a capacidade de compartilhar e reutilizar as roles criadas entre outros projetos e aplicativos.

Em nosso laboratório, reutilizamos várias roles da comunidade. Com isso, foi possível aproveitar o poder da comunidade em manter a base de código cada vez melhor ao longo do tempo. Na sua empresa, você poderia configurar um repositório para roles do Ansible em que as equipes de desenvolvimento e operações possam contribuir para criar uma base de código melhor, aumentando a qualidade dos processos internos. É disso que se trata o DevOps!