Agora que temos um sistema de monitoramento configurado para executar verificações e enviar alertas sobre eventuais problemas na infraestrutura da loja virtual, podemos simular um cenário de falha de um dos servidores. Essa também é uma boa maneira de testar se o sistema de monitoramento está funcionando corretamente.
Vamos imaginar que nosso servidor de banco de dados tenha sofrido um problema de hardware e parou de funcionar. Para isto, basta sair da máquina virtual de monitoramento executando o comando logoutou simplesmente digitandoCTRL-De pedir para o Vagrant destruir a máquina virtual do banco de dados:
vagrant@monitor$ logout
Connection to 127.0.0.1 closed. $ vagrant destroy db
db: Are you sure you want to destroy the ’db’ VM? [y/N] y ==> db: Forcing shutdown of VM...
==> db: Destroying VM and associated drives...
Dentro de alguns minutos, o sistema de monitoramento irá detectar que o servidor está indisponível e enviará um alerta. A partir deste momento, usuá- rios não conseguem mais acessar a loja virtual para efetuar compras. Sendo o engenheiro responsável pela operação em produção, você recebe a notificação e responde prontamente para confirmar a falha e agora você precisa restituir o serviço.
Olhando o console do Nagios, você verá algo parecido com a figura3.6. O host do banco de dados e todos os seus serviços estão vermelhos, porém a verificação do serviço HTTP no servidor web também falha, indicando que o problema do banco de dados está afetando a loja virtual.
3.6. Um problema atinge produção, e agora? Casa do Código
Figura 3.6: Verificações falhando quando um problema atinge produção
Para que tudo volte ao normal, você precisará reinstalar o servidor de banco de dados. No entanto, fizemos isto de forma manual no capítulo2. Re- petir todos aqueles passos manualmente levará muito tempo e, em momentos de crise como este, tempo é um recurso escasso. Será que não existe uma ma- neira melhor de instalar e configurar esses servidores?
Capítulo 4
Infraestrutura como código
Administradores de sistema aprendem o poder da linha de comando desde cedo e passam boa parte do dia no terminal controlando a infraestrutura da sua empresa. É comum dizer que eles estão alterando a configuração do sis- tema. Seja instalando novos servidores, instalando novo software, fazendo upgrade de software existente, editando arquivos de configuração, reiniciando processos, lendo arquivos de log, efetuando e restaurando backups, criando novas contas de usuário, gerenciando permissões, ajudando desenvolvedores a investigar algum problema ou escrevendo scripts para automatizar tarefas repetíveis.
Cada uma dessas tarefas altera ligeiramente o estado do servidor e pode potencialmente causar problemas se a mudança não for executada correta- mente. É por isso que muitos administradores de sistema não dão acesso aos servidores de produção para desenvolvedores: para evitar mudanças indese- jáveis e pela falta de confiança. No entanto, em muitas empresas, essas tarefas
4.1. Provisionamento, configuração ou deploy? Casa do Código
são executadas manualmente nos servidores de produção pelos próprios ad- ministradores de sistema e eles também podem cometer erros.
Um dos principais princípios de DevOps é investir em automação. Auto- mação permite executar tarefas mais rapidamente e diminui a possibilidade de erros humanos. Um processo automatizado é mais confiável e pode ser auditorado com mais facilidade. Conforme o número de servidores que pre- cisam ser administrados aumenta, processos automatizados se tornam essen- ciais. Alguns administradores de sistema escrevem seus próprios scripts para automatizar as tarefas mais comuns. O problema é que cada um escreve sua própria versão dos scripts e fica difícil reutilizá-los em outras situações. Por outro lado, desenvolvedores são bons em escrever código modularizado e reu- tilizável.
Com o avanço da cultura DevOps e o aumento da colaboração entre ad- ministradores de sistema e desenvolvedores, diversas ferramentas têm evo- luído para tentar padronizar o gerenciamento automatizado de infraestru- tura. Tais ferramentas permitem tratar infraestrutura da mesma forma que tratamos código: usando controle de versões, realizando testes, empacotando e distribuindo módulos comuns e, obviamente, executando as mudanças de configuração no servidor.
Essa prática é conhecida como infraestrutura como código e nos permi- tirá resolver o problema que encontramos no final do capítulo3. Em vez de reinstalar tudo manualmente, vamos usar uma ferramenta de gerenciamento de configurações para automatizar o processo de provisionamento, configu- ração e deploy da loja virtual.
4.1
Provisionamento, configuração ou deploy?
Ao comprar um laptop ou um celular novo, você só precisa ligá-lo e ele já está pronto para uso. Em vez de mandar as peças individuais e um manual de como montar sua máquina, o fabricante já fez todo o trabalho necessário para que você usufrua seu novo aparelho sem maiores problemas. Como usuário, você só precisa instalar programas e restaurar seus arquivos para considerar a máquina sua. Esse processo de preparação para o usuário final é conhecido como provisionamento.
Casa do Código Capítulo 4. Infraestrutura como código
O termo provisionamento é comumente usado por empresas de teleco- municações e por equipes de operações para se referir às etapas de preparação iniciais de configuração de um novo recurso: provisionar um aparelho celu- lar, provisionar acesso à internet, provisionar um servidor, provisionar uma nova conta de usuário, e assim por diante. Provisionar um aparelho celular envolve, entre outras coisas: alocar uma nova linha, configurar os equipa- mentos de rede que permitem completar ligações, configurar serviços extra como SMS ou e-mail e, por fim, associar tudo isso com o chip que está no seu celular.
No caso de servidores, o processo de provisionamento varia de empresa para empresa dependendo da infraestrutura e da divisão de responsabilida- des entre as equipes. Se a empresa possui infraestrutura própria, o processo de provisionamento envolve a compra e instalação física do novo servidor no seu data center. Se a empresa possui uma infraestrutura virtualizada, o pro- cesso de provisionamento só precisa alocar uma nova máquina virtual para o servidor. Da mesma forma, se a equipe de operações considerar a equipe de desenvolvimento como “usuário final”, o processo de provisionamento acaba quando o servidor está acessível na rede, mesmo se a aplicação em si ainda não estiver rodando. Se considerarmos os verdadeiros usuários como “usuá- rios finais”, então o processo de provisionamento só acaba quando o servidor e a aplicação estiverem rodando e acessíveis na rede.
Para evitar maior confusão e manter integridade no decorrer do livro, vale a pena olhar para o processo de ponta a ponta e definir uma terminolo- gia adequada. Imaginando o cenário mais longo de uma empresa que possui infraestrutura própria porém não tem servidores sobrando para uso, as etapas necessárias para colocar uma nova aplicação no ar seriam:
1) Compra de hardware: em empresas grandes essa etapa inicia um processo de aquisição, que envolve diversas justificações e aprovações pois investir dinheiro em hardware influi na contabilidade e no planejamento finan- ceiro da empresa.
2) Instalação física do hardware: essa etapa envolve montar o novo servidor num rack no data center, assim como instalação de cabos de força, de rede etc.
4.1. Provisionamento, configuração ou deploy? Casa do Código
3) Instalação e configuração do sistema operacional: uma vez que o ser- vidor é ligado, é preciso instalar um sistema operacional e configurar os items básicos de hardware como: interfaces de rede, armazenamento (disco, partições, volumes em rede), autenticação e autorização de usuá- rios, senha de root, repositório de pacotes etc.
4) Instalação e configuração de serviços comuns: além das configurações base do sistema operacional, muitos servidores precisam configurar ser- viços de infraestrutura básicos como: DNS, NTP, SSH, coleta e rotação de logs, backups, firewall, impressão etc.
5) Instalação e configuração da aplicação: por fim, é preciso instalar e confi- gurar tudo que fará este servidor ser diferente dos outros: componentes de middleware, a aplicação em si, assim como configurações do middleware e da aplicação.
No decorrer do livro, usaremos o termo provisionamento para se referir ao processo que envolve as etapas 1 - 4, ou seja, todas as atividades necessárias para que o servidor possa ser usado e independente da razão pela qual ele foi requisitado. Usaremos o termo deploy, ou o equivalente em português implantação, quando nos referirmos à etapa 5. Apesar do deploy precisar de um servidor provisionado, o ciclo de vida do servidor é diferente da aplicação. O mesmo servidor pode ser usado por várias aplicações e cada aplicação pode efetuar deploy dezenas ou até centenas de vezes, enquanto o provisionamento de novos servidores acontece com menos frequência.
No pior caso, o processo de provisionamento pode demorar semanas ou até meses dependendo da empresa. Por esse motivo, é comum ver equipes de desenvolvimento definindo com bastante antecedência os requisitos de hard- ware para seus ambientes de produção e iniciando esse processo com a equipe de operações nas etapas iniciais do projeto, para evitar atrasos quando a apli- cação estiver pronta para ir ao ar. Alguma colaboração pode acontecer no começo do processo, porém a maior parte do tempo as duas equipes traba- lham em paralelo sem saber o que a outra está fazendo.
Pior ainda, muitas dessas decisões arquiteturais cruciais sobre a quanti- dade de servidores, configurações de hardware ou escolha do sistema ope- racional são tomadas no começo do projeto, no momento em que se tem a 64
Casa do Código Capítulo 4. Infraestrutura como código
menor quantidade de informação e conhecimento sobre as reais necessida- des do sistema.
Um dos aspectos mais importantes da cultura DevOps é reconhecer esse conflito de objetivos e criar um ambiente de colaboração entre as equipes de desenvolvimento e de operações. O compartilhamento de práticas e ferra- mentas permite que a arquitetura se adapte e evolua conforme as equipes aprendem mais sobre o sistema rodando no mundo real: em produção. Esta visão holística também ajuda a encontrar soluções que simplifiquem o pro- cesso de compra e provisionamento, removendo etapas ou utilizando auto- mação para fazer com que elas aconteçam mais rápido.
Um bom exemplo dessa simplificação do processo é o uso de tecnologias como virtualização de hardware e computação em nuvem – também conhe- cida pelo termo em inglês cloud computing ou simplesmente cloud. Provedo- res de serviço cloud de ponta permitem que você tenha um novo servidor no ar em questão de minutos através de um simples clique de botão ou chamada de API!