May 7th, 2014Implementando Implantações Azul-Verde com Amazon Web Services (AWS)

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:

  1. Criar a configuração de lançamento para a nova versão “verde” do seu software.
  2. 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.
  3. Atualizar o grupo “azul” e definir o número desejado de instâncias para zero. Aguardar até que as instâncias antigas sejam encerradas.
  4. 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.

Post to Twitter

Tags: , , , , , , , , , , , , No Comments »

May 6th, 2014Implementing Blue-Green Deployments with AWS

An important technique for reducing the risk of deployments is known as Blue-Green Deployments. If we call the current live production environment “blue”, the technique consists of bringing up a parallel “green” environment with the new version of the software and once everything is tested and ready to go live, you simply switch all user traffic to the “green” environment, leaving the “blue” environment idle. When deploying to the cloud, it is common to then discard the idle environment if there is no need for rollbacks, especially when using immutable servers.

If you are using Amazon Web Services (AWS) as your cloud provider, there are a few options to implement blue-green deployments depending on your system’s architecture. Since this technique relies on performing a single switch from “blue” to “green”, your choice will depend on how you are serving content in your infrastructure’s front-end.

Single EC2 instance with Elastic IP

In the simplest scenario, all your public traffic is being served from a single EC2 instance. Every instance in AWS is assigned two IP addresses at launch – a private IP that is not reachable from the Internet, and a public IP that is. However, if you terminate your instance or if any failure occurs, those IP addresses are released and you will not be able to get them back.

An Elastic IP is a static IP address allocated to your AWS account that you can assign as the public IP for any EC2 instance you own. You can also reassign it to another instance on demand, by making a simple API call.

In our case, Elastic IPs are the simplest way to implement the blue-green switch – launch a new EC2 instance, configure it, deploy the new version of your system, test it, and when it is ready for production, simply reassign the Elastic IP from the old instance to the new one. The switch will be transparent to your users and traffic will be redirected almost immediately to the new instance.

Multiple EC2 instances behind an ELB

If you are serving content through a load balancer, then the same technique would not work because you cannot associate Elastic IPs to ELBs. In this scenario, the current blue environment is a pool of EC2 instances and the load balancer will route requests to any healthy instance in the pool. To perform the blue-green switch behind the same load balancer you need to replace the entire pool with a new set of EC2 instances containing the new version of the software. There are two ways to do this – automating a series of API calls or using AutoScaling groups.

Every AWS service has an API and a command-line client that you can use to control your infrastructure. The ELB API allows you to register and de-register EC2 instances, which will either add or remove them from the pool. Performing the blue-green switch with API calls will require you to register the new “green” instances while de-registering the “blue” instances. You can even perform these calls in parallel to switch faster. However, the switch will not be immediate because there is a delay between registering an instance to an ELB and the ELB starting to route requests to it. This is because the ELB only routes requests to healthy instances and it has to perform a few health checks before considering the new instances as healthy.

The other option is to use the AWS service known as AutoScaling. This allows you to define automatic rules for triggering scaling events; either increasing or decreasing the number of EC2 instances in your fleet. To use it, you first need to define a launch configuration that specifies how to create new instances – which AMI to use, the instance type, security group, user data script, etc. Then you can use this launch configuration to create an auto-scaling group defining the number of instances you want to have in your group. AutoScaling will then launch the desired number of instances and continuously monitor the group. If an instance becomes unhealthy or if a threshold is crossed, it will add instances to the group to replace the unhealthy ones or to scale up/down based on demand.

AutoScaling groups can also be associated with an ELB and it will take care of registering and de-registering EC2 instances to the load balancer any time an automatic scaling event occurs. However the association can only be done when the group is first created and not after it is running. We can use this feature to implement the blue-green switch, but it will require a few non-intuitive steps, detailed here:

  1. Create the launch configuration for the new “green” version of your software.
  2. Create a new “green” AutoScaling group using the launch configuration from step 1 and associate it with the same ELB that is serving the “blue” instances. Wait for the new instances to become healthy and get registered.
  3. Update the “blue” group and set the desired number of instances to zero. Wait for the old instances to be terminated.
  4. Delete the “blue” AutoScaling group and launch configuration.

This procedure will maintain the same ELB while replacing the EC2 instances and AutoScaling group behind it. The main drawback to this approach is the delay. You have to wait for the new instances to launch, for the AutoScaling group to consider them healthy, for the ELB to consider them healthy, and then for the old instances to terminate. While the switch is happening there is a period of time when the ELB is routing requests to both “green” and “blue” instances which could have an undesirable effect for your users. Because of that reason, I would probably not use this approach when doing blue-green deployments with ELBs and instead consider the next option – DNS redirection.

DNS redirection using Route53

Instead of exposing Elastic IP addresses or long ELB hostnames to your users, you can have a domain name for all your public-facing URLs. Outside of AWS, you could perform the blue-green switch by changing CNAME records in DNS. In AWS, you can use Route53 to achieve the same result. With Route53, you create a hosted zone and define resource record sets to tell the Domain Name System how traffic is routed for that domain.

You can use Route53 to perform the blue-green switch by bringing up a new “green” environment – it could be a single EC2 instance, or an entire new ELB – then you simply update the resource record set to point the domain/subdomain to the new instance or the new ELB.

Even though Route53 supports this common DNS approach, there is a better alternative. Route53 has an AWS-specific extension to DNS that integrates better with other AWS services, and is cheaper too – alias resource record sets. They work pretty much the same way, but instead of pointing to any IP address or DNS record, they point to a specific AWS resource: a CloudFront distribution, an ELB, an S3 bucket serving a static website, or another Route53 resource record set in the same hosted zone.

Finally, another way to perform the blue-green switch with Route53 is using Weighted Round-Robin. This works for both regular resource record sets as well as alias resource record sets. You have to associate multiple answers for the same domain/sub-domain and assign a weight between 0-255 to each entry. When processing a DNS query, Route53 will select one answer using a probability calculated based on those weights. To perform the blue-green switch you need to have an existing entry for the current “blue” environment with weight 255 and a new entry for the “green” environment with weight 0. Then, simply swap those weights to redirect traffic from blue to green.

The only disadvantage of this approach is that propagating DNS changes can take some time, so you would have no control over when the user will perceive it. The benefits are that you expose human-friendly URLs to your users, the switch happens with near zero-downtime, you can test the new “green” environment before promoting it, and with weighted round-robin you get the added flexibility of doing canary releases for free.

Environment swap with Elastic Beanstalk

The last scenario is when you are deploying your web application to Elastic Beanstalk, Amazon’s platform-as-a-service offering that supports Java, .Net, Python, Ruby, NodeJS and PHP. Elastic Beanstalk has a built-in concept of an environment that allows you to run multiple versions of your application, as well as the ability to perform zero-downtime releases. Therefore, the blue-green switch simply consists of creating a new “green” environment and following the steps in the documentation to perform the swap.

Conclusion

Blue-Green deployment is an important technique to enable Continuous Delivery. It reduces risk by allowing testing prior to the release of a new version to production, while at the same time enabling near zero-downtime deployments, and a fast rollback mechanism should something go wrong. It is a powerful technique to manage software releases especially when you are using cloud infrastructure. Cloud providers such as AWS enable you to easily create new environments on-demand and provide different options to implement Blue-Green deployments.

Post to Twitter

Tags: , , , , , , , , , , , 1 Comment »
© 2007-2009 Danilo Sato | Powered by Wordpress
XHTML CSS RSS

Page optimized by WP Minify WordPress Plugin