Uma técnica importante para reduzir o risco de suas implantações (ou deploys) é conhecida como Blue-Green Deployments(Implantações Azul-Verde). Se chamarmos o ambiente de produção atual de “azul”, a técnica consiste em introduzir um ambiente paralelo “verde” com a nova versão do software e, uma vez que tudo é testado e está pronto para começar a operar, você simplesmente redireciona todo o tráfego de usuários do ambiente “azul” para o ambiente “verde”. Num ambiente de computação em nuvem, assim que for confirmado que o ambiente ocioso não é mais necessário, é comum descarta-lo, uma prática conhecida como servidores imutáveis.
Se você estiver utilizando Amazon Web Services (AWS) como seu provedor de nuvem, existem algumas opções para implementar as implantações azul-verde dependendo da arquitetura do seu sistema. Visto que esta técnica depende de uma única troca de “azul” para “verde”, a sua escolha vai depender de como você está servindo conteúdo no front-end da sua infraestrutura.
Instância EC2 Única com Elastic IP
No cenário mais simples, todo o seu tráfego público está sendo servido a partir de uma única instância EC2. Toda nova instância no AWS recebe dois endereços – um IP privado, que não é acessível a partir da Internet, e um IP público que é. No entanto, se você desligar a sua instância ou se ocorrer alguma falha, esses endereços IP são liberados e você não poderá recuperá-los.
Um Elastic IP é um endereço IP estático alocado à sua conta AWS que você pode atribuir como o IP público para qualquer instância EC2 que você possui. Você também pode reatribuí-lo a outra instância fazendo uma simples chamada de API.
No nosso caso, Elastic IP’s são a maneira mais simples de implementar a troca azul-verde: suba uma nova instância EC2, configure-a, faça deploy da nova versão do seu sistema, teste-o e, quando ele estiver pronto para produção, simplesmente reatribua o Elastic IP da instância antiga para a nova. A mudança será transparente para os seus usuários e o tráfego será redirecionado quase que imediatamente para a nova instância.
Múltiplas Instâncias EC2 por trás de um ELB
Se você estiver servindo conteúdo através de um balanceador de carga, então a mesma técnica não funcionaria pois você não pode associar um Elastic IP a um ELB. Neste cenário, o ambiente azul atual é um grupo de instâncias EC2 e o balanceador de carga encaminhará requisições para qualquer instância saudável no grupo. Para realizar a troca azul-verde usando o mesmo balanceador de carga você precisa substituir o grupo todo por um novo conjunto de instâncias EC2 contendo a nova versão do software. Há duas maneiras de fazer isso: automatizando uma série de chamadas de API ou utilizando grupos de AutoScaling.
Cada serviço AWS expõe uma API e um cliente de linha de comando que você pode usar para controlar a sua infraestrutura. A API do ELB permite registrar e desregistrar instâncias EC2, o que irá adicioná-las ou removê-las do grupo. Realizar a troca azul-verde com chamadas API exigirá que você registre as novas instâncias “verdes” e ao mesmo tempo desregistre as instâncias “azuis”. Você pode até mesmo realizar essas chamadas em paralelo para ter uma troca mais rápida. No entanto, a troca não será imediata porque há um atraso entre registrar uma instância a um ELB e o ELB começar a encaminhar requisições para ela. Isso acontece pois o ELB só encaminha requisições para instâncias saudáveis e ele precisa executar algumas verificações (health checks) antes de considerar as novas instâncias como saudáveis.
A outra opção é utilizar o serviço AWS conhecido como AutoScaling. Ele permite que você defina regras automáticas para gerenciar a escalabilidade da sua infraestrutura, seja aumentando ou diminuindo o número de instâncias EC2 em sua frota. Para usá-lo, primeiro você precisa definir uma configuração de lançamento (launch configuration) que especifique como criar novas instâncias – qual AMI utilizar, o tipo de instância, grupo de segurança, script de inicialização (user data), etc. Então você pode usar essa configuração de lançamento para criar um grupo de AutoScaling definindo o número de instâncias que você deseja ter em seu grupo. O AutoScaling irá então subir o número desejado de instâncias e continuará monitorando o grupo continuamente. Se uma instância falhar ele irá subir uma nova instância para substituí-la; se um limite for ultrapassado, ele irá aumentar ou diminuir o tamanho da sua frota com base na demanda.
Os grupos de AutoScaling também podem ser associados a um ELB e ele cuidará de registrar e desregistrar instâncias EC2 no balanceador de carga toda vez que um evento de escalabilidade ocorrer. No entanto, a associação só pode ser feita quando o grupo é criado pela primeira vez e não depois que ele estiver sendo executado. Podemos usar esse recurso para implementar a troca azul-verde, mas isso exigirá alguns passos não intuitivos, detalhados aqui:
- Criar a configuração de lançamento para a nova versão “verde” do seu software.
- Criar um novo grupo de AutoScaling “verde” usando a configuração de lançamento a partir do passo 1 e associá-lo ao mesmo ELB que está servindo as instâncias “azuis”. Aguardar até que as novas instâncias se registrem e se tornarem saudáveis.
- Atualizar o grupo “azul” e definir o número desejado de instâncias para zero. Aguardar até que as instâncias antigas sejam encerradas.
- Remover o grupo de AutoScaling “azul” e sua configuração de lançamento.
Este procedimento manterá o mesmo ELB funcionando enquanto as instâncias EC2 e o grupo de AutoScaling atrás dele são substituídos. A principal desvantagem dessa abordagem é o atraso. Você precisa esperar até que as novas instâncias subam, até o grupo de AutoScaling registrá-las no ELB, até o ELB considera-las saudáveis e, por fim, até que as antigas instâncias sejam encerradas. Enquanto a troca está acontecendo, há um período de tempo em que o ELB encaminha requisições tanto para instâncias “verdes” quanto para “azuis”, o que pode causar um efeito indesejável para seus usuários. Por este motivo eu provavelmente não usaria essa abordagem para realizar implantações azul-verde com ELB’s e em vez disso consideraria a próxima opção – o redirecionamento usando DNS.
Redirecionamento de DNS utilizando Route53
Ao invés de expor endereços de IP ou longos hostnames dos ELB’s aos seus usuários, você pode ter um nome de domínio para todos as seus URL’s públicas. Fora do AWS, você pode realizar a troca azul-verde alterando registros CNAME no DNS. No AWS, você pode usar o Route53 para alcançar o mesmo resultado. Com o Route53, você cria uma zona de hospedagem (hosted zone) e define conjuntos de registro de recursos (resource record sets) para dizer ao Sistema de Nome de Domínio (DNS) como direcionar tráfego para o seu domínio.
Você pode usar o Route53 para realizar a troca azul-verde introduzindo um novo ambiente “verde” - que pode ser uma única instância EC2 ou um novo ELB – e simplesmente atualizando o conjunto de registro de recursos para apontar seu domínio/subdomínio para a nova instância ou para o novo ELB.
Embora o Route53 suporte essa prática comum de gerenciar registros DNS, há uma alternativa melhor. O Route53 tem uma extensão para DNS específica ao AWS que se integra melhor a outros serviços AWS e também é mais barato – o conjunto de registro de alias de recursos (alias resource record sets). Eles funcionam praticamente da mesma maneira, porém ao invés de apontar para qualquer endereço IP ou registro DNS, eles apontam para um recurso AWS específico: uma distribuição CloudFront, um ELB, um bucket S3 servindo um site estático, ou outro conjunto de registro de recursos Route53 na mesma zona de hospedagem.
Finalmente, outra forma de realizar a troca azul-verde com o Route53 é utilizando o Weighted Round-Robin. Isso funciona tanto para conjuntos de registro de recursos normais quanto para conjuntos de registro de alias de recursos. Você precisa associar várias respostas para o mesmo domínio/subdomínio e atribuir um peso entre 0 e 255 para cada registro. Ao processar uma consulta DNS, o Route53 irá selecionar uma resposta usando uma probabilidade calculada com base nesses pesos. Para realizar a troca azul-verde você precisa ter um registro existente para o atual ambiente “azul” com peso 255 e um novo registro para o ambiente “verde” com peso 0. Em seguida, basta trocar esses pesos para redirecionar o tráfego de azul para verde.
A única desvantagem dessa abordagem é que a propagação de mudanças no DNS pode demorar algum tempo, por isso você não teria controle sobre quando o usuário final perceberá isso. Os benefícios são que você expõe seus usuários a URL’s mais fáceis de serem memorizadas, a mudança acontece quase imediatamente, você pode testar o novo ambiente “verde” antes de promovê-lo e, com o weighted round-robin, você ganha a flexibilidade adicional de fazer deploys do tipocanary automaticamente.
Troca de ambiente com Elastic Beanstalk
O último cenário é quando você está implantando seu aplicativo web no Elastic Beanstalk, a oferta de plataforma como serviço (PaaS) da Amazon que suporta Java, .Net, Python, Ruby, NodeJS e PHP. O Elastic Beanstalk expõe o conceito de um ambiente que permite que você rode várias versões do seu aplicativo lado a lado, bem como a capacidade de realizardeploys com tempo inoperacional zero. A troca azul-verde simplesmente consiste em criar um novo ambiente “verde” e seguir as etapas na documentação para realizar a troca.
Conclusão
A Implantação Azul-Verde é uma técnica importante para implementar Entrega Contínua. Ela reduz o risco permitindo a realização de testes antes do lançamento de uma nova versão para produção. Ao mesmo tempo, ela permite implantações com tempo inoperacional quase zero e um mecanismo de reversão rápida caso algo dê errado. É uma técnica poderosa para fazer deploy de software, especialmente quando você estiver utilizando computação em nuvem na sua infraestrutura. Os provedores de nuvem, tal como o AWS, permitem que você crie novos ambientes facilmente através de uma simples chamada de API e oferecem várias opções para implementar as implantações Azul-Verde.
Aviso: As afirmações e opiniões expressas neste artigo são de responsabilidade de quem o assina, e não necessariamente refletem as posições da Thoughtworks.