Master
ThoughtWorks
Menu
Close
  • What we do
    • Go to overview
    • Customer Experience, Product and Design
    • Data Strategy, Engineering and Analytics
    • Digital Transformation and Operations
    • Enterprise Modernization, Platforms and Cloud
  • Who we work with
    • Go to overview
    • Automotive
    • Healthcare
    • Public Sector
    • Cleantech, Energy and Utilities
    • Media and Publishing
    • Retail and E-commerce
    • Financial Services and Insurance
    • Not-for-profit
    • Travel and Transport
  • Insights
    • Go to overview
    • Featured

      • Technology

        An in-depth exploration of enterprise technology and engineering excellence

      • Business

        Keep up to date with the latest business and industry insights for digital leaders

      • Culture

        The place for career-building content and tips, and our view on social justice and inclusivity

    • Digital Publications and Tools

      • Technology Radar

        An opinionated guide to technology frontiers

      • Perspectives

        A publication for digital leaders

      • Digital Fluency Model

        A model for prioritizing the digital capabilities needed to navigate uncertainty

      • Decoder

        The business execs' A-Z guide to technology

    • All Insights

      • Articles

        Expert insights to help your business grow

      • Blogs

        Personal perspectives from ThoughtWorkers around the globe

      • Books

        Explore our extensive library

      • Podcasts

        Captivating conversations on the latest in business and tech

  • Careers
    • Go to overview
    • Application process

      What to expect as you interview with us

    • Grads and career changers

      Start your tech career on the right foot

    • Search jobs

      Find open positions in your region

    • Stay connected

      Sign up for our monthly newsletter

  • About
    • Go to overview
    • Our Purpose
    • Awards and Recognition
    • Diversity and Inclusion
    • Our Leaders
    • Partnerships
    • News
    • Conferences and Events
  • Contact
Global | English
  • United States United States
    English
  • China China
    中文 | English
  • India India
    English
  • Canada Canada
    English
  • Singapore Singapore
    English
  • United Kingdom United Kingdom
    English
  • Australia Australia
    English
  • Germany Germany
    English | Deutsch
  • Brazil Brazil
    English | Português
  • Spain Spain
    English | Español
  • Global Global
    English
Blogs
Select a topic
View all topicsClose
Technology 
Agile Project Management Cloud Continuous Delivery  Data Science & Engineering Defending the Free Internet Evolutionary Architecture Experience Design IoT Languages, Tools & Frameworks Legacy Modernization Machine Learning & Artificial Intelligence Microservices Platforms Security Software Testing Technology Strategy 
Business 
Financial Services Global Health Innovation Retail  Transformation 
Careers 
Career Hacks Diversity & Inclusion Social Change 
Blogs

Topics

Choose a topic
  • Technology
    Technology
  • Technology Overview
  • Agile Project Management
  • Cloud
  • Continuous Delivery
  • Data Science & Engineering
  • Defending the Free Internet
  • Evolutionary Architecture
  • Experience Design
  • IoT
  • Languages, Tools & Frameworks
  • Legacy Modernization
  • Machine Learning & Artificial Intelligence
  • Microservices
  • Platforms
  • Security
  • Software Testing
  • Technology Strategy
  • Business
    Business
  • Business Overview
  • Financial Services
  • Global Health
  • Innovation
  • Retail
  • Transformation
  • Careers
    Careers
  • Careers Overview
  • Career Hacks
  • Diversity & Inclusion
  • Social Change
Continuous Delivery Technology

Implementando Implantações Azul-Verde com Amazon Web Services (AWS)

Danilo Sato Danilo Sato

Published: Feb 24, 2014

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.

Master
Privacy policy | Modern Slavery statement | Accessibility
Connect with us
×

WeChat

QR code to ThoughtWorks China WeChat subscription account
© 2021 ThoughtWorks, Inc.