Aventuras com o Ansible: desafios, soluções e... Subversion?

No ambiente de TI atual, as aplicações corporativas podem ser complexas, escaláveis, distribuídas, baseadas em componentes e, muitas vezes, são muito importantes. Elas podem ser implantadas em diversas plataformas em nuvens privadas, públicas ou híbridas. Podem acessar dados confidenciais, estar sujeitas a diretrizes de regulamentação e a políticas de segurança rigorosas e, ainda assim, serem bastante intuitivas. Resumindo, as aplicações são muito complexas. Neste post, veremos um pouco mais sobre como essas considerações estão relacionadas ao uso de ferramentas de automação como o Ansible.

No meu post anterior, Aventuras com o Ansible: lições aprendidas com implantações reais, falei sobre considerações práticas para usar o Ansible em seu ambiente com sucesso. No post de hoje, vou falar mais sobre as melhores práticas que reuni a partir da minha experiência no setor com implantações reais.

Ao projetar e desenvolver aplicações corporativas, é necessário atender a diversos requisitos. Além disso, as decisões de desenvolvimento que precisam ser tomadas para atender a um requisito podem afetar outros requisitos. E nem sempre é fácil entender ou prever isso. E se não solucionamos todos os requisitos, o projeto pode não ter solução. Estas são algumas das aplicações corporativas que são encontradas atualmente:

• Sistemas de faturamento automatizados (ABS)

• Processamento de pagamento

• Sistemas de marketing por e-mail

• Sistemas de gerenciamento de conteúdo (CMS)

• Call center e atendimento ao cliente

• Gerenciamento do relacionamento com o cliente (CRM)

• Sistema de gestão empresarial (ERP)

• Business Intelligence

• Planejamento de continuidade dos negócios (BCP)

• Gestão de RH

• Integração de aplicações corporativas (EAI)

• Sistemas de colaboração e mensageria

Como essas aplicações são realmente complexas de usar, os líderes das organizações disseram que esses são alguns dos motivos pelos quais eles não quiseram automatizar tais aplicações. Foi isto que me disseram:

• Não dá para automatizar!

• Não foi projetada para ser automatizada.

• É muito difícil e muito caro automatizar.

• Já foi automatizada com scripts de shell e outras ferramentas e truques.

• Ela não afeta nossas operações atuais.

• Nosso profissional de TI lida com os problemas da solução corporativa.

Talvez essas pessoas também pensem que o desafio da automação não é só técnico. Para falar a verdade, a automação não depende só da tecnologia, é preciso pensar de modo diferente. Ela demanda uma mudança na cultura.

Uma vez fui à Alemanha para ajudar um cliente. Eu tive a oportunidade de liderar uma equipe com o objetivo de automatizar as implantações do stack de software da organização em dez ambientes diferentes usando o Ansible, o Jenkins e o Vagrant. Eles implantavam em ambientes de produção a cada três meses e sofriam com longos períodos de inatividade, problemas inesperados durante a implantação e muito mais. No mundo de TI atual, não faz mais sentido ter dez especialistas, no local, sofrendo com a pressão e a complexidade de entregar um lançamento à meia-noite.

Eles queriam uma solução automatizada. Queriam reduzir os custos, aumentar a confiabilidade, padronizar os ambientes, eliminar as tarefas manuais repetitivas e permitir que as equipes passassem mais tempo aprimorando os sistemas do que gerenciando-os, entre outros objetivos.

No geral, o projeto foi bem-sucedido. Mesmo assim, não foi um caminho fácil. Veja o que aconteceu...

Os problemas

Vamos ver alguns dos problemas que eles tinham...

Implantações manuais

Implantávamos manualmente, o que gerava alguns desafios:

• As implantações em ambientes de produção aconteciam a cada três meses e levavam até oito horas para serem concluídas. Elas eram feitas de madrugada e exigiam o trabalho de cinco a dez "heróis" diferentes.

• Cada profissional tinha seu próprio script personalizado para realizar algumas das tarefas necessárias para que cada lançamento funcionasse em cada ambiente.

• Era um grande desafio organizacional, e cada implantação tinha seus próprios problemas.

Implantações complexas

• Confiabilidade: às vezes, as aplicações não eram iniciadas (por causa de sequências de encerramento incorretas). Cada um tinha seu próprio truque para reiniciá-las. Algumas aplicações não foram configuradas do mesmo jeito em todos os ambientes, prejudicando ainda mais a confiabilidade.

• Interação humana: muitas vezes a interação humana era necessária para executar uma ação no site e uma implantação ocorrer adequadamente.

Ambientes inconsistentes (também conhecido como o "fator humano")

Naquele momento, nossos ambientes eram inconsistentes. As implantações eram feitas manualmente e sempre dávamos um jeito de que elas fossem bem-sucedidas. Algumas pessoas tinham scripts especiais, pastas diferentes nos servidores de destino etc. Isso resultava em erros na produção que não haviam ocorrido em outros ambientes. E quando seu ambiente de produção fica inativo por mais tempo do que o esperado, você tem um problema caro e difícil de lidar.

Esse era essencialmente o "fator humano".

Metodologia de cascata

Antes da automação, nossa abordagem era usar técnicas de cascata. Raramente implantávamos em nosso ambiente de produção.

Isso mudou por causa das metodologias Ágil, e as equipes de Scrum foram desenvolvidas. Em seguida, criamos a equipe de automação, como parte do Departamento de operações, para incentivar a automação das implantações e reduzir suas inconsistências e complexidades manuais. Levou dois anos para completarmos o processo de passar da metodologia de cascata para Ágil. Mesmo assim, ele ainda pode ser melhorado. Ele continua a crescer e mudar, e isso que é interessante na abordagem Ágil.

A solução

Implementamos de formas melhores.

Precisávamos de software de automação, metodologias Ágil, equipes de Scrum dos departamentos de operações e desenvolvimento, uma equipe de automação responsável por entregar ferramentas automatizadas e um processo diário para mudar a cultura da empresa para criarmos uma solução sofisticada e reduzirmos a dificuldade das implantações.

Precisamos de muito tempo e muito trabalho de todos os envolvidos.

Esta é uma visão geral de algumas das ferramentas que usamos para automatizar todo o nosso ambiente:

Nexus

Antes de qualquer outra coisa, você precisa de um repositório central para seus artefatos. É possível que a equipe de desenvolvimento já esteja usando um para armazenar os artefatos binários que ela cria.

Jenkins

O Jenkins é a sua ferramenta de automação de pipeline de CI/CD. A equipe de desenvolvimento provavelmente já usa o Jenkins ou algo parecido para compilações automatizadas. No entanto, decidimos criar uma instância separada do Jenkins para automatizar a implantação porque queríamos gerenciar o firewall de modo diferente.

Pipelines foram criados para orquestrar as fases do processo de implantação: preparação, encerramento, implantação e inicialização. Criamos nossos pipelines usando o código Groovy (classes orientadas a objetos, funções etc.) para desenvolver padrões (códigos reutilizáveis) e porque se o Jenkins tivesse algum problema ou se a implantação desse errado poderíamos recriar tudo rapidamente com esse código.

Lembre: automatize também as ferramentas de automação. Por isso automatizamos a instalação do Jenkins. Além disso, nós instalamos uma versão reduzida do Jenkins em nosso nó de controle para testar os pipelines localmente antes de implantar o código do Groovy ou do Ansible. Ela foi instalada com as mesmas versões do plug-in do Jenkins que estavam em execução em nosso cluster de produção do Jenkins.

Ansible

O Ansible era a parte central de tudo que estávamos fazendo.

Transferimos todas as nossas configurações para o inventário do Ansible usando uma estrutura de inventários de várias etapas (gerenciando Des1, Des2, Des3, Test1, Test2, Test3 etc…), variáveis compartilhadas e group_vars. Levamos bastante tempo para migrar a configuração da aplicação que, originalmente, estava nos artefatos que a equipe de desenvolvimento criou com a instância do Jenkins. As credenciais foram armazenadas com o Ansible Vault.

As implantações do software foram divididas em quatro fases: preparação, encerramento, implantação e inicialização. Como consequência, desenvolvemos nossas funções do Ansible com o ponto de entrada tasks/main.yml responsável pelo gerenciamento dessas fases usando tags. Veja um exemplo abaixo. Isso permitiu que executássemos um pipeline do Jenkins para executar todas as funções do Ansible. As funções ficaram encarregadas da fase prepare (preparação), que é responsável por enviar o novo artefato aos servidores de destino, mas não afeta os serviços em execução. Assim, reduzimos a duração da preparação, já que ela não exige tempo de inatividade.

--- - name: Prepare artifact  import_tasks: prepare.yml  tags: prepare - name: Shutdown services  import_tasks: shutdown.yml  tags: shutdown … 

Vagrant

Usamos o Vagrant e o VirtualBox para provisionar um nó de controle de instalação reduzida similar ao servidor do Jenkins de onde nossos playbooks do Ansible foram executados. Isso foi importante porque precisávamos achar um jeito de testar e depurar problemas de automação.

A caixa do Vagrant local foi provisionada com versões do Ansible e do Jenkins, plug-ins do Jenkins, pacotes de sistema operacional e nomes de volume iguais aos do nó mestre do Jenkins principal. Tudo isso foi reduzido para usar 1 GB de memória e 1 vCPU, mas foi o suficiente para os testes. Além disso, o Vagrant foi configurado com caixas que simularam nosso stack de produção. Assim, conseguimos executar nossos playbooks a partir do nó de controle para provisionar e implantar um ou mais hosts de destino, como servidores web e de aplicação etc.

Subversion

O Subversion era nosso sistema de controle de versão (VCS) na empresa. No início, pensamos em mudar isso, mas o Subversion era usado em toda a organização. Teria sido uma mudança grande e disruptiva. Se somente nossa equipe usasse o Git, criaríamos um novo silo e adicionaríamos mais uma camada ao stack. Acredito que devemos sempre facilitar as coisas. E nunca tivemos um problemas que justificasse a troca do Subversion para o Git. Precisamos saber quando devemos mudar e quando devemos manter uma tecnologia, mesmo que não seja a ferramenta do momento.

JIRA

O que seria da metodologia Ágil e das equipes de Scrum sem o Jira? Planejar, rastrear e lançar software com o software de rastreamento da Atlassian, que é muito útil. Um dos maiores desafios da transformação da automação era definir Histórias de usuário (User stories) no JIRA e entender o conceito de Produto mínimo viável (MVP).

Desafios

Não há mudanças sem desafios, e os nossos surgiram em todas as áreas possíveis.

Técnicos

Naquele momento, as aplicações dependiam do Internet Explorer e usavam a tecnologia ActiveX. Para solucionar essa questão, usamos o PhantomJS para automatizá-las com um "headless browser".

Políticos

Tanto o departamento de desenvolvimento quanto o de operações queriam usar a abordagem DevOps, mas era difícil alinhar as prioridades de cada um deles em relação ao que o DevOps tinha a oferecer. Os dois departamentos tinham líderes diferentes com objetivos distintos.

Pessoais

Alguns dos colaboradores da equipe não tinham interesse na automação. Pelo menos no início. Eles diziam "já está tudo automatizado". É importante que sua empresa defina o que é automação. Muitas pessoas veem a automação como ainda mais uma linguagem que precisam aprender. Com muita paciência, fomos "plantando sementes". Mostramos vários casos de sucesso e, por fim, conseguimos convencê-los a fazer a automação com o Ansible.

Resultados

O que alcançamos? Esse foi um incrível caso de sucesso que precisava ser compartilhado (por isso o post no blog). Saímos de automação zero para uma equipe bem-sucedida que agora implanta a cada duas semana no ambiente de produção, com um único pipeline que quase não precisa de interação humana ou de conhecimento especializado para operar.

Alguns dos bons resultados que tivemos incluem um procedimento padrão para preparação, inicialização, implantação e encerramento em dez ambientes. Até o momento, a automação foi confiável e não encontrou problemas na inicialização. E o tempo necessário para a implantação foi reduzido de duas horas para 20 minutos.

Ao automatizar o pipeline, eliminamos a necessidade de operação manual para implantações, e os erros também foram eliminados. Mesmo com uma documentação robusta e uma equipe de TI experiente, há muitas chances de algo dar errado quando precisamos que pessoas usem comandos e operações manualmente. Se houver um erro ou alguma etapa for ignorada, as coisas poderão dar errado em um piscar de olhos.

Lições aprendidas

Os resultados falam por si. No entanto, também aprendemos algumas coisas no caminho.

Entenda que nem todos são a favor da automação, pelo menos, não no começo. Você terá que usar algo que não está no Ansible ou em qualquer outra ferramenta de automação, seja paciente. Você precisará ter paciência, muita mesmo, para entrar em um grande projeto de automação.

Comece aos poucos. Automatize alguma coisa que você possa mostrar como um caso de sucesso. Talvez você queira solucionar um problema, mas não precisa começar pelo maior deles sem antes ganhar alguma experiência em automação. Uma falha logo no início pode atrasar você e fazer com que as pessoas alimentem a ideia de que não é possível automatizar seu ambiente.

Como muitas outras coisas na TI, 80% dos problemas que você vai enfrentar serão bem simples de resolver. São os 20% restantes que vão desafiar você durante a automação, como casos fora dos parâmetros, exceções e outras situações incomuns que podem surgir. Eles costumam ser desafiadores, mas não impossíveis.

Para administradores de sistemas e colaboradores da equipe de operações experientes, a tentação de usar SSH em um host para corrigir um problema é forte. Resista a essa vontade! O objetivo é conseguir sistemas consistentes, previsíveis, padronizados e confiáveis. Então descubra como alterar (ou criar) playbooks do Ansible para que você não precise usar SSH na caixa. Corrija a origem do problema, não os sinais.

Por último, você ainda não acabou seu trabalho até automatizar a automação. Você precisa instalar e fazer upgrade, de forma automática, do Ansible, do Jenkins, dos plug-ins do Jenkins e assim por diante. Não instale-os manualmente ou você só criará o mesmo problema que estava tentando resolver com o Ansible nos hosts de destino. Você terá ambientes inconsistentes e não confiáveis para suas ferramentas de automação. Não é uma boa base!

Conclusão

Durante minha carreira, eu sempre automatizei tudo o que pude. Odiava ter que fazer a mesma coisa duas vezes manualmente. O problema é que eu estava usando as ferramentas erradas.

Automatizar o software que eu estava instalando, configurando, implantando e aplicando patches por dez anos foi uma experiência incrível que mostrou todos os recursos de gerenciamento de configuração, CI/CD, pipelines, idempotência etc. E o Ansible foi a base para isso tudo.

Então, não tenha mais medo. Automatize as aplicações corporativas. Comece hoje mesmo! Para mais informações sobre como os serviços da Red Hat podem ajudar a aprimorar sua empresa automatizada, confira nossas ofertas de consultoria.