WHITEPAPER

INTEGRAÇÃO E ENTREGA
CONTÍNUAS
COM O ANSIBLE

INTRODUÇÃO
O Ansible é uma linguagem open source de automação muito poderosa. Os recursos
de implantação e orquestração dessa solução a tornam única em comparação a outras
ferramentas de gerenciamento. Em muitos aspectos, o objetivo dessa solução é oferecer mais
ganhos de produtividade em uma ampla variedade de oportunidades de automação. Além de
substituir, de modo imediato e mais produtivo, muitos recursos básicos de outras soluções de
automação, o Ansible também busca superar outros desafios de TI mais complexos.

Um desses desafios é capacitar a integração e a implantação contínuas (CI/CD) sem nenhum

tempo de inatividade. Muitas vezes, para atingir esse objetivo com êxito, as organizações se
veem obrigadas a criar extensos códigos personalizados, trabalhar com vários pacotes de
software e desenvolver muitas soluções de integração internamente. O Ansible oferece todos
esses recursos em um único pacote, projetado desde o início para orquestrar exatamente
esses tipos de cenários.

POR QUE VIABILIZAR A CI/CD?

Ao longo da última década, a análise de software e as práticas de TI nos ensinaram que ciclos
de lançamento mais longos ("projetos em cascata") têm uma sobrecarga significativamente
maior do que os ciclos de lançamento mais curtos e com maior frequência ("iterativos" ou
"ágeis"). No início do ciclo de lançamento, há uma equipe de garantia de qualidade preparada
e na espera para testar o produto. Durante essa fase, não há necessidade de implantação.
No fim desse ciclo, a equipe de garantia de qualidade e a de TI trabalham a todo vapor.
No entanto, as tarefas de desenvolvimento são divididas entre a correção de bugs e o
planejamento para o próximo grande lançamento. As mudanças de contexto são frequentes.

O mais preocupante é o fato de que ciclos de lançamento mais longos significam um tempo
maior entre a descoberta e a correção de bugs. O que é inconveniente, principalmente para
as propriedades da web com grande volume de tráfego, nas quais um único contratempo
pode afetar milhões de usuários. Para resolver esse problema, o setor de desenvolvimento
de softwares está adotando com rapidez uma abordagem de lançamento antecipado e
constante ("release early, release often"), baseado no modelo de desenvolvimento ágil de
WHITEPAPER
CI/CD com Ansible

software. Disponibilizar soluções de forma antecipada e constante significa que os membros

das equipes não precisam pular de um modo de operação para outro. Também significa
que as alterações podem ser realizadas, aprovadas e implantadas em muito menos tempo.
Várias outras abordagens, como a engenharia de automação de garantia de qualidade
(QA) e o desenvolvimento guiado por testes (TDD), aumentam a eficácia dessas técnicas.
É lógico concluir que, se adotar a abordagem de "lançamento antecipado e constante" é
um avanço, então, capacitar a CI/CD é alcançar a plenitude. Embora a agilidade seja uma
escala progressiva, uma organização pode obter resultados impressionantes ao seguir essa
direção. Para isso, a automação é essencial. Portanto, há um foco enorme nas tecnologias que
viabilizam um rápido retorno, com intervenção humana somente quando necessário.

Neste documento, destacaremos por que o Ansible e o Ansible Tower by Red Hat são as
ferramentas ideais para conectar sistemas computacionais e possibilitar os processos
mencionados.

O objetivo de todos POR QUE TEMPO DE INATIVIDADE ZERO?

os processos de Períodos de inatividade e interrupção resultam em perda de receita ou insatisfação do cliente.
No caso dos grandes aplicativos web, com usuários em todos os fusos horários do mundo,
automação deve
a interrupção da atividade deve ser reservada somente para os processos de upgrade mais
ser possibilitar as urgentes e complicados. Obviamente, isso não se aplica às atualizações da versão do aplicativo.
atualizações sem Mesmo no caso de aplicativos internos de organizações de grande porte (por exemplo, um
afetar a capacidade sistema contábil ou de intranet), a interrupção de um sistema crítico pode gerar impactos
consideráveis na produtividade. O objetivo de todos os processos de automação deve ser
operacional.
possibilitar as atualizações sem afetar a capacidade operacional.

Tempo de inatividade zero é um objetivo alcançável. No entanto, para que seja possível
gerenciá-lo, é necessário ter o respaldo da ferramenta certa, uma plataforma de orquestração
em várias camadas e etapas, como o Ansible.

OUTROS SISTEMAS DE BUILD

Antes de alcançar a entrega contínua (CD), o primeiro passo é implementar a integração
contínua (CI). Em termos práticos, os sistemas de CI são sistemas de build que monitoram
as mudanças em vários repositórios de controle de código-fonte, executam todos os testes
aplicáveis e empacotam (e testam, de preferência) de maneira automática a versão mais
recente do aplicativo a partir de cada mudança no controle do código-fonte, como o Jenkins
(jenkins.io).

O principal passo em direção à CD é quando o sistema de build pode invocar o Ansible após
uma compilação bem-sucedida. Além disso, os usuários que também executam testes de
unidade ou de integração no código como resultado do build, já estarão um passo à frente
no processo. O Jenkins pode usar o Tower para implantar o artefato compilado em vários
ambientes. No entanto, ter um ambiente de QA/homologação nos moldes do ambiente de
produção acelera o processo e aumenta significativamente a previsibilidade durante o ciclo
de vida. Assim, é possível referenciar os dados retornados pelo Ansible e correlacioná-los
diretamente às tarefas do Tower nos sistemas de build.

Na verdade, como explicaremos mais adiante, é possível usar o Tower em um ambiente de

homologação para realizar testes antes da implantação em produção.

2
WHITEPAPER
CI/CD com Ansible

Com recursos ATUALIZAÇÕES CONTÍNUAS E APLICATIVOS DE VÁRIAS CAMADAS

exclusivos de O requisito imprescindível em um sistema de CD é habilidade de orquestrar atualizações
contínuas nas várias camadas da arquitetura de um aplicativo. Com recursos exclusivos de
orquestração em orquestração em várias camadas e etapas combinados à arquitetura baseada em push, o
várias camadas e Ansible permite uma execução extremamente rápida das cargas de trabalho complexas. Assim
etapas combinados que uma camada é atualizada, começa a atualização da próxima. Dessa forma, os dados são
à arquitetura facilmente compartilhados entre as camadas.

baseada em push, Um dos recursos principais do Ansible que permite essa orquestração é a habilidade de definir
o Ansible permite "plays", que selecionam um grupo de alta granularidade de hosts e atribuem algumas tarefas
uma execução (ou "funções") a serem executadas. Normalmente, as tarefas são declarações de que um
extremamente recurso específico esteja em um estado determinado. Por exemplo, um pacote que deve ser
instalado em uma versão específica ou um repositório de controle de código-fonte que deve
rápida das cargas de ser retirado de uma determinada versão.
trabalho complexas.
Na maioria das topologias de aplicativos web, é necessário atualizar algumas camadas
específicas em uma sequência rígida. Por exemplo, algumas vezes, é necessário migrar o
esquema de banco de dados e liberar os servidores de cache antes de atualizar os servidores
de aplicativo.

Acima de tudo, é essencial não ter que gerenciar simultaneamente os aplicativos e a

configuração de todos os sistemas no ambiente de produção.

Ao reiniciar os serviços, alguns não ficam disponíveis imediatamente. A substituição da

versão de um aplicativo talvez não tenha efeito instantâneo. É importante ser capaz de retirar
máquinas de um pool com balanceamento de cargas antes da atualização. Também é crítico
ter a capacidade de automatizar as ações de colocar e retirar máquinas do pool.

O Ansible permite que você controle a extensão da janela de atualização contínua por meio
da palavra-chave "serial". Além disso, a maneira como o Ansible realiza atualizações contínuas
é inteligente o suficiente para que se um lote falhar, a atualização pare e o restante da
infraestrutura seja mantida on-line.

IMPLANTAÇÃO CONTÍNUA DO GERENCIAMENTO DE CONTEÚDO

Além de fazer a entrega contínua de serviços em produção, também é possível implantar
ininterruptamente o próprio conteúdo do playbook do Ansible. Dessa forma, os
administradores de sistemas e os desenvolvedores podem enviar os códigos do playbook do
Ansible para um repositório central, executar alguns testes no ambiente de homologação e,
após a aprovação, aplicar automaticamente essas configurações ao ambiente de produção.
Isso permite aplicar o mesmo processo usado na implantação de software ao gerenciamento
da configuração, o que gera muitos dos mesmos benefícios.

Como as mudanças no software ou na configuração são uma das principais causas de

interrupção não intencional, é útil implantar tanto os testes automatizados quanto a
análise humana. Isso pode ser associado a um sistema de revisão de código, como o Gerrit
(gerritcodereview.com), para exigir a aprovação de vários usuários antes de aplicar as
mudanças.

3
WHITEPAPER
CI/CD com Ansible

ATUALIZAÇÕES CONTÍNUAS TAL COMO APLICADO AO BALANCEAMENTO

DE CARGAS E AO MONITORAMENTO
O Ansible trabalha em conjunto com outras ferramentas, como balanceadores de carga,
durante a execução de uma atualização contínua. No meio de qualquer "loop de host" do
playbook, é possível dizer "fazer tal ação no sistema X em nome do host Y".

Isso inclui tanto a comunicação com balanceadores de carga de todos os tipos quanto a
sinalização de janelas de interrupção de determinados hosts, para desativar os alertas de
monitoramento dos hosts que estão sendo atualizados. O uso de expressões simples, como
"desativar monitoramento", "remover do pool", "atualizar camada" e "ativar o monitoramento",
permite sempre realizar atualizações sem tempo de inatividade ou enviar alertas falsos
automatizados, sem a necessidade de intervenção manual.

TESTES DE HOMOLOGAÇÃO INTEGRADOS COM O ANSIBLE

Com o uso do Tower com várias fontes de inventário, é possível testar um playbook do Ansible
em um ambiente de homologação e exigir a execução bem-sucedida de uma atualização
antes da implementação na produção. Embora opcional, essa é a configuração ideal para
a modelagem de cenários de atualização no ambiente de produção (talvez, em uma escala
menor) antes de atualizar os sistemas no mundo real. Basta usar o parâmetro “-i” em um
playbook do Ansible para especificar em qual fonte de inventário ele deve ser executado, e
usar o mesmo playbook nos ambientes de homologação e de produção.

CONTROLE DE VERSÃO BASEADO NA IMPLANTAÇÃO

Muitas organizações preferem incluir os aplicativos em pacotes de sistema operacional (RPM,
debs etc.). No entanto, em muitos casos, principalmente no caso de aplicativos web dinâmicos,
isso não é necessário. Por esse motivo, o Ansible contém inúmeros módulos para implantar
diretamente a partir do controle de versão. Um playbook pode solicitar a retirada de um
determinado repositório em uma tag ou versão. Depois, o sistema garantirá que isso aconteça
em vários servidores. O Ansible pode relatar eventos de mudanças para ativar ações de
acompanhamento adicionais quando é necessário mudar a versão do software. Dessa forma,
os serviços associados não são reiniciados desnecessariamente.

INTEGRAÇÕES COM FERRAMENTAS DE MONITORAMENTO

Como o Ansible é um sistema de orquestração, também é possível realizar integrações com
ferramentas de monitoramento de APM. Por exemplo, vamos supor que, durante o teste ou
a implantação de uma integração, é necessário instalar/atualizar o agente de um sistema
de APM no aplicativo. O Ansible pode ter uma função que cuida da instalação do agente no
stack do aplicativo. Assim que o agente estiver on-line, o Ansible poderá definir os alertas
(caso ainda não existam) no stack de monitoramento. Assim, o monitoramento pode retornar
imediatamente os dados às equipes interessadas na implantação, informando-as se o
aplicativo está sendo executado sem problemas.

Se ocorrer algum problema com o aplicativo no ambiente de produção após o upgrade,

o Ansible pode ser invocado pela ferramenta de monitoramento para reverter a um build
anterior e funcional do aplicativo. Obviamente, isso pode ser feito somente se for possível
reverter o build do aplicativo.

4
WHITEPAPER
CI/CD com Ansible

RETORNOS DE CHAMADA E CONECTABILIDADE

Em uma cultura de CI/CD, muitas vezes pode ser útil enviar alertas quando os eventos ocorrem.
O Ansible inclui vários recursos para fazer isso, incluindo um módulo de e-mail integrado.
Além disso, o recurso de retorno de chamada permite a conexão de notificações com sistemas
arbitrários, incluindo transmissões de chat (IRC, Campfire etc), registro personalizado ou mídias
sociais internas.

MODELO DE RECURSO DE ESTADO DESEJADO APLICADO À IMPLANTAÇÃO

Uma das principais funções que tornam o Ansible interessante para a implantação de
software é o uso do modelo de recurso baseado em estado, popularizado nas ferramentas
de gerenciamento de configuração, no processo de atualização do software. Embora,
tradicionalmente, algumas ferramentas open source precisem do complemento de scripts e
software de implantação adicionais, esse não é o caso do Ansible.

Isso deve-se à habilidade do Ansible de controlar com precisão a ordem dos eventos entre
camadas diferentes dos sistemas, delegar ações a outros sistemas e mesclar diretivas de
modelo de recurso ("o estado do pacote X deve ser Y") em oposição aos padrões de comando
tradicionais ("executar script.sh”) no mesmo processo.

O Ansible também permite executar comandos para o teste de várias condições e, depois,
tomar decisões condicionais com base nos resultados dos comandos. Ao combinar a
configuração e a implantação em uma única cadeia de ferramentas, é possível reduzir a
sobrecarga na gestão de ferramentas diferentes, além de propiciar uma unificação mais
satisfatória entre o sistema operacional e a política de aplicativos.

Ao combinar a TESTES INCORPORADOS À IMPLANTAÇÃO

configuração e a Grandes poderes trazem muitas responsabilidades. Um dos perigos de configurar um
sistema de CD automatizado é o risco de propagar para todos os sistemas uma configuração
implantação em
errada feita em um deles. Para evitar isso, o Ansible permite adicionar testes diretamente
uma única cadeia nos playbooks que podem cancelar uma atualização contínua se algo der errado. É possível
de ferramentas, é implantar testes arbitrários, com o módulo de "comando" ou "script", ou até mesmo escritos
possível reduzir a como módulos nativos do Ansible, para verificar diversas condições. Isso pode incluir o estado
funcional do serviço.
sobrecarga na gestão
de ferramentas O uso do módulo de "falha" pode cancelar a execução do host em qualquer momento.
diferentes, além Portanto, é fácil descobrir os erros logo no início de uma janela de atualização contínua. Por
de propiciar uma exemplo, suponhamos que uma diferença entre o ambiente de homologação e de produção
resultou em um erro de configuração que apareceria somente na implantação em produção.
unificação mais
Nesse caso, é possível escrever playbooks do Ansible para interromper o processo de
satisfatória entre o atualização na primeira etapa da janela de atualização contínua. Se houvesse 100 servidores
sistema operacional e a janela de atualização fosse 10, essa janela pararia e permitiria a intervenção. Depois da
e a política de correção, basta executar novamente o playbook para continuar a atualização.

aplicativos.
No caso de uma falha, o Ansible interrompe a operação e configura apenas parte do sistema.
Ele chama a atenção para o erro, para que você possa gerenciá-lo, e produz resumos sobre
quais hosts no ciclo de atualização tiveram problemas e quantas mudanças foram executadas
em cada plataforma.

5
WHITEPAPER
CI/CD com Ansible

TESTES DE CONFORMIDADE
Em muitos ambientes, as mudanças de configuração são aplicadas somente quando realmente
necessárias. Antes de "apertar o botão", é necessário que um indivíduo entenda e concorde
com essas mudanças. Nesses casos, ainda assim é possível aproveitar um sistema de CD com
algumas limitações.

Nesse tipo de situação, o Ansible contém um modo de simulação por meio de uma sinalização
“--check” que reportará quais mudanças seriam realizadas na execução de um processo de
playbook. Como isso ignoraria as execuções reais do comando e não levaria em conta possíveis
scripts com falha, trata-se apenas de uma orientação. No entanto, essa é uma ferramenta
muito útil.

Mesmo ao realizar implantações contínuas quando novas compilações são disponibilizadas,

é possível executar verificações de conformidade com mais frequência para reportar as
alterações no ambiente de produção por intervenção humana e a necessidade de fazer
correções por meio de outra execução do playbook. Essa pode ser uma maneira fácil de
detectar quando há a necessidade de fazer uma mudança no software, de corrigir uma
permissão e assim por diante.

O Ansible contém um IMPLANTAÇÃO NO PILOTO AUTOMÁTICO

modo de simulação O Ansible possui inúmeras ferramentas e recursos que o tornam uma solução de CI/CD ideal.
Dentre eles estão a habilidade de orquestrar com precisão processos em várias camadas e
por meio de uma etapas, sem qualquer tempo de inatividade nos fluxos de trabalho de atualizações contínuas. É
sinalização “--check” a arquitetura exclusiva do Ansible que torna isso possível. E ao combiná-la com o sistema que
que reportará não requer agentes (o que aumenta a segurança e reduz a necessidade de gerenciamento), é
quais mudanças fácil estabelecer representações simples e legíveis do que antes era um conjunto de processos
de TI complexos e realizados manualmente. Acabou-se o tempo em que era necessário
seriam realizadas trancar uma equipe de operações em uma sala de reuniões para realizar uma combinação de
na execução etapas manuais e automatizadas. O Ansible coloca a implantação completamente no piloto
do processo de automático.
playbook.
"Completamente no piloto automático" significa cumprir verdadeiramente com a promessa
de oferecer processos ágeis: disponibilização mais rápida de mudanças, com menos erros e
menor número de mudanças de conceito dispendiosas. Eliminar as janelas de interrupção
e, principalmente, os erros das mudanças manuais é altamente crítico para qualquer serviço
básico de TI interna ou propriedade web com tráfego intenso.

Por meio dos recursos da arquitetura do Ansible e a habilidade de se integrar estreitamente

a sistemas de CI, como o Jenkins, é possível automatizar a configuração, assim como todos os
aspectos dos processos de TI. É por esse motivo que consideramos o Ansible uma plataforma
de orquestração, em vez de classificá-lo apenas como uma ferramenta de gerenciamento de
configuração ou de implantação de software.

EXEMPLOS E INFORMAÇÕES ADICIONAIS

É possível encontrar exemplos básicos de conteúdo do Ansible em:
github.com/ansible/ansible-examples

Experimente o Ansible Tower agora:

ansible.com/tower

6
 SOBRE O ANSIBLE
O Ansible, um projeto criado pela comunidade open source e patrocinado pela Red Hat, é
a maneira mais simples de automatizar a TI. O Ansible é a única linguagem de automação
que pode ser usada por todas as equipes de TI, dos administradores de sistemas e rede aos
desenvolvedores e gerentes. O Ansible by Red Hat oferece soluções prontas para empresas a
fim de automatizar todo o ciclo de vida dos aplicativos, incluindo servidores, clouds, containers
e outros. O Ansible Tower by Red Hat é uma oferta comercial que auxilia as equipes a gerenciar
implantações complexas com várias camadas ao adicionar recursos de controle, conhecimento
e delegação nos ambientes onde o Ansible é implantado.

PRONTO PARA AUTOMATIZAR? ansible.com · info@ansible.com

Copyright © 2017 Red Hat, Inc. Red Hat, o logotipo Shadowman e Ansible são marcas registradas
da Red Hat, Inc. ou suas subsidiárias, nos Estados Unidos da América e em outros países.