ThoughtWorks
  • 联系我们
  • Español
  • Português
  • Deutsch
  • English
概况
  • 工匠精神和科技思维

    采用现代的软件开发方法,更快地交付价值

    智能驱动的决策机制

    利用数据资产解锁新价值来源

  • 低摩擦的运营模式

    提升组织的变革响应力

    企业级平台战略

    创建与经营战略发展同步的灵活的技术平台

  • 客户洞察和数字化产品能力

    快速设计、交付及演进优质产品和卓越体验

    合作伙伴

    利用我们可靠的合作商网络来扩大我们为客户提供的成果

概况
  • 汽车企业
  • 清洁技术,能源与公用事业
  • 金融和保险企业
  • 医疗企业
  • 媒体和出版业
  • 非盈利性组织
  • 公共服务机构
  • 零售业和电商
  • 旅游业和运输业
概况

特色

  • 技术

    深入探索企业技术与卓越工程管理

  • 商业

    及时了解数字领导者的最新业务和行业见解

  • 文化

    分享职业发展心得,以及我们对社会公正和包容性的见解

数字出版物和工具

  • 技术雷达

    对前沿技术提供意见和指引

  • 视野

    服务数字读者的出版物

  • 数字化流畅度模型

    可以将应对不确定性所需的数字能力进行优先级划分的模型

  • 解码器

    业务主管的A-Z技术指南

所有洞见

  • 文章

    助力商业的专业洞见

  • 博客

    ThoughtWorks 全球员工的洞见及观点

  • 书籍

    浏览更多我们的书籍

  • 播客

    分析商业和技术最新趋势的精彩对话

概况
  • 申请流程

    面试准备

  • 毕业生和变换职业者

    正确开启技术生涯

  • 搜索工作

    在您所在的区域寻找正在招聘的岗位

  • 保持联系

    订阅我们的月度新闻简报

概况
  • 会议与活动
  • 多元与包容
  • 新闻
  • 开源
  • 领导层
  • 社会影响力
  • Español
  • Português
  • Deutsch
  • English
ThoughtWorks菜单
  • 关闭   ✕
  • 产品及服务
  • 合作伙伴
  • 洞见
  • 加入我们
  • 关于我们
  • 联系我们
  • 返回
  • 关闭   ✕
  • 概况
  • 工匠精神和科技思维

    采用现代的软件开发方法,更快地交付价值

  • 客户洞察和数字化产品能力

    快速设计、交付及演进优质产品和卓越体验

  • 低摩擦的运营模式

    提升组织的变革响应力

  • 智能驱动的决策机制

    利用数据资产解锁新价值来源

  • 合作伙伴

    利用我们可靠的合作商网络来扩大我们为客户提供的成果

  • 企业级平台战略

    创建与经营战略发展同步的灵活的技术平台

  • 返回
  • 关闭   ✕
  • 概况
  • 汽车企业
  • 清洁技术,能源与公用事业
  • 金融和保险企业
  • 医疗企业
  • 媒体和出版业
  • 非盈利性组织
  • 公共服务机构
  • 零售业和电商
  • 旅游业和运输业
  • 返回
  • 关闭   ✕
  • 概况
  • 特色

  • 技术

    深入探索企业技术与卓越工程管理

  • 商业

    及时了解数字领导者的最新业务和行业见解

  • 文化

    分享职业发展心得,以及我们对社会公正和包容性的见解

  • 数字出版物和工具

  • 技术雷达

    对前沿技术提供意见和指引

  • 视野

    服务数字读者的出版物

  • 数字化流畅度模型

    可以将应对不确定性所需的数字能力进行优先级划分的模型

  • 解码器

    业务主管的A-Z技术指南

  • 所有洞见

  • 文章

    助力商业的专业洞见

  • 博客

    ThoughtWorks 全球员工的洞见及观点

  • 书籍

    浏览更多我们的书籍

  • 播客

    分析商业和技术最新趋势的精彩对话

  • 返回
  • 关闭   ✕
  • 概况
  • 申请流程

    面试准备

  • 毕业生和变换职业者

    正确开启技术生涯

  • 搜索工作

    在您所在的区域寻找正在招聘的岗位

  • 保持联系

    订阅我们的月度新闻简报

  • 返回
  • 关闭   ✕
  • 概况
  • 会议与活动
  • 多元与包容
  • 新闻
  • 开源
  • 领导层
  • 社会影响力
博客
选择主题
查看所有话题关闭
技术 
敏捷项目管理 云 持续交付 数据科学与工程 捍卫网络自由 演进式架构 体验设计 物联网 语言、工具与框架 遗留资产现代化 Machine Learning & Artificial Intelligence 微服务 平台 安全 软件测试 技术策略 
商业 
金融服务 全球医疗 创新 零售行业 转型 
招聘 
职业心得 多元与融合 社会改变 
博客

话题

选择主题
  • 技术
    技术
  • 技术 概观
  • 敏捷项目管理
  • 云
  • 持续交付
  • 数据科学与工程
  • 捍卫网络自由
  • 演进式架构
  • 体验设计
  • 物联网
  • 语言、工具与框架
  • 遗留资产现代化
  • Machine Learning & Artificial Intelligence
  • 微服务
  • 平台
  • 安全
  • 软件测试
  • 技术策略
  • 商业
    商业
  • 商业 概观
  • 金融服务
  • 全球医疗
  • 创新
  • 零售行业
  • 转型
  • 招聘
    招聘
  • 招聘 概观
  • 职业心得
  • 多元与融合
  • 社会改变
持续交付技术

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.

  • 产品及服务
  • 合作伙伴
  • 洞见
  • 加入我们
  • 关于我们
  • 联系我们

WeChat

×
QR code to ThoughtWorks China WeChat subscription account

媒体与第三方机构垂询 | 政策声明 | Modern Slavery statement ThoughtWorks| 辅助功能 | © 2021 ThoughtWorks, Inc.