As abordagens tradicionais de “big bang” para o desenvolvimento de software são incompatíveis com os requisitos de alta flexibilidade, agilidade e implantação contínua das plataformas de software de nuvem e DevOps atuais.
Não basta preparar uma lista de verificação das etapas manuais a serem executadas durante a implantação da versão de produção. Se fizer isso, você não é realmente ágil, nem é um DevOps adequado.
últimas postagens
Implantação azul-verde: uma visão geral
A implantação Blue-Green é uma abordagem para implantação de software que reduz o tempo de inatividade e o risco de novas versões de software criando dois ambientes idênticos: ativo (azul) e inativo (verde).
O ambiente ativo é onde a versão atual do software está sendo executada e os usuários estão gerando tráfego de produção. O ambiente inativo é onde a nova versão do software é implantada e testada.
Assim que a nova versão estiver testada e pronta, o tráfego é trocado do ambiente ativo para o ambiente inativo, tornando-o o novo ambiente ativo. Você pode repetir esse processo conforme necessário.
Fonte: docs.aws.amazon.com
Contexto DevOps
A implantação Blue-Green se encaixa bem com a mentalidade e os processos de DevOps porque oferece suporte à entrega e implantação contínuas de software, minimizando o tempo de inatividade para usuários de produção e eliminando o risco de uma falha na versão de produção.
Ter dois ambientes idênticos possibilita testar e implantar novas versões de software sem afetar o ambiente de produção atual. Isso significa lançamentos mais rápidos e frequentes, que é um aspecto fundamental do DevOps.
Além disso, a capacidade de alternar o tráfego entre ambientes rapidamente é uma pré-condição principal para uma reversão rápida em caso de problemas, o que também é importante em um ambiente DevOps.
Princípios-chave da implantação azul-verde
#1. Dois ambientes idênticos
A implantação Blue-Green requer a criação de dois ambientes idênticos. Isso significa idênticos do ponto de vista de dados e processos. Um está ativo (azul) e o outro está inativo (verde).
O ambiente azul é onde os usuários de produção executam seus processos diários. O ambiente verde está sempre sincronizado com o azul, mas os testadores executam seus casos de teste lá. Mesmo que esse ambiente não seja a produção, você executa os testes em condições do mundo real, pois é um ambiente semelhante à produção.
#2. Interruptor de Tráfego
Uma vez testada e pronta a nova versão do software, o tráfego é trocado do ambiente ativo para o ambiente inativo, tornando-o o novo ambiente ativo.
A troca é instantânea. Toda a implantação agora é coisa do passado. Não há janela de tempo de inatividade. Os usuários não precisam fazer nada para alcançar o novo ambiente. Eles são redirecionados automaticamente e todos ao mesmo tempo.
Fonte: aws.amazon.com
#3. Reversão rápida
A capacidade de alternar o tráfego entre ambientes rapidamente também significa reversão rápida em caso de problemas. Isso garante um tempo de inatividade mínimo e o aplicativo permanece altamente disponível.
Se algo der errado com o ambiente verde, todos os usuários voltarão instantaneamente para o ambiente azul original estável sem qualquer confusão.
#4. Teste automatizado
O teste automatizado é um aspecto fundamental da implantação Blue-Green. Ele garante que a nova versão do software seja totalmente testada antes de ser implantada no ambiente ativo.
Se você não tem uma quantidade significativa de testes automatizados em seus sistemas (incluindo testes de unidade, testes funcionais e testes de regressão, pelo menos), provavelmente não faz muito sentido pensar em implementar a implantação Blue-Green.
A falta de testes automatizados irá atrasá-lo drasticamente. O tempo necessário para testar o novo ambiente (verde) será tão longo que, quando você conseguir mudar para o ambiente verde, ele já estará “velho demais” do ponto de vista do ciclo de vida de desenvolvimento de software.
#5. Entrega Contínua
A implantação Blue-Green faz parte de um pipeline de entrega contínua, o que, em última análise, significa lançamentos de software mais rápidos e frequentes em produção.
Você pode fazer a troca assim que estiver pronto para testar a nova versão do software no ambiente verde. Como a implantação já foi feita e você só precisa fazer a troca de tráfego em si, é tão rápido que você pode fazer isso todos os dias. Supondo que você seja rápido também nas atividades de teste, obviamente.
Ciclo de vida típico
A plataforma que executa a implantação Blue-Green tem seu próprio ciclo de vida específico de etapas e processos a serem executados. Isto é o que geralmente consiste em:
Implementação de pipelines de CI/CD
Implementar a implantação Blue-Green em um pipeline DevOps CI/CD deve ser um processo natural.
Um forte pré-requisito é que você já tenha esses dois ambientes idênticos em vigor. Como este será um processo automatizado, você pode usar a infraestrutura como uma ferramenta de código como AWS CloudFormation ou mesmo independente da nuvem Terraforma scripts para criar/recriar/atualizar os ambientes para você em pipelines automatizados.
Depois de fazer isso, é uma etapa relativamente fácil para criar um processo de implantação totalmente automatizado. Basta reutilizar os pipelines já existentes para a criação do ambiente azul e verde. No entanto, desta vez você precisa incluir no pipeline também processos de teste.
O processo de troca de tráfego que você pode automatizar com ferramentas como Balanceador de carga elástico da AWS ou NGINXGenericName. Isso envolve atualizar o balanceador de carga ou as configurações de DNS para direcionar o tráfego para o ambiente verde assim que a nova versão do software estiver testada e pronta.
A próxima peça do quebra-cabeça é o monitoramento. Para isso, utilize ferramentas como AWS CloudWatch, Nnova relíquiaou datadog.
Por fim, reutilize os pipelines existentes até mesmo para desativar o antigo ambiente azul. Depende de você executar primeiro a destruição de todos os serviços e componentes antes de recriá-los do zero ou, alternativamente, pode apenas atualizar os scripts para cada serviço na cadeia. Normalmente, destruir e recriar é uma opção mais segura, pois com a atualização, você tem muito mais casos a considerar.
Práticas recomendadas de implantação azul-verde
Curioso sobre como fazer o melhor uso da implantação Blue-Green? Aqui estão algumas das dicas provenientes da prática.
Tenha uma sólida estratégia de migração de banco de dados
Ao implantar uma nova versão do software, é importante garantir que o esquema do banco de dados seja atualizado corretamente. Use uma estratégia de migração de banco de dados como Flyway ou Liquibase para gerenciar mudanças no esquema do banco de dados.
Use uma ferramenta de análise Canary
Embora a implantação Canary seja uma abordagem alternativa, você ainda pode usar algumas de suas técnicas para aperfeiçoar sua implantação Blue-Green.
Use uma ferramenta de análise canário, como Kayenta ou Spinnaker para analisar o desempenho da nova versão do software em um ambiente do mundo real. Isso envolve comparar o desempenho da nova versão do software com o desempenho da versão antiga do software.
Use uma estrutura de alternância de recursos, como Togglz para habilitar ou desabilitar recursos na nova versão do software. Isso permite um lançamento gradual de novos recursos e permite uma reversão rápida, se necessário.
Use um balanceador de carga com verificações de integridade
Use um balanceador de carga como AWS Elastic Load Balancer ou NGINX com verificações de integridade para garantir que o tráfego seja direcionado apenas para instâncias íntegras. Isso garante que o aplicativo permaneça altamente disponível e que o tempo de inatividade seja minimizado.
Use um plano de reversão com reversão automatizada
Tenha um plano de reversão em caso de problemas e automatize o processo de reversão usando uma ferramenta como AWS CodeDeploy ou Octopus Deploy. Isso garante que o tempo de inatividade seja minimizado e que o aplicativo permaneça altamente disponível.
Isso se aplica principalmente ao ambiente verde sempre que você descobrir algum problema significativo com a nova versão.
Você não precisa de um plano de reversão para o ambiente azul, pois este permanece intocado pelo switch e você pode retornar a esse ambiente estável sempre que necessário e instantaneamente.
Desafios com a implantação azul-verde
A implementação da implantação Blue-Green pode apresentar alguns desafios para as equipes de desenvolvimento. Aqui estão alguns desafios típicos:
Diferença entre implantação azul-verde e canário
Embora a diferença para os processos de implantação tradicionais seja bastante óbvia (não há dois ambientes paralelos em execução com diferentes versões de software nos processos de implantação tradicionais), a diferença para a implantação do Canary pode ser um pouco mais interessante.
A implantação azul-verde significa dois ambientes (azul e verde). Mas, ao mesmo tempo, os dois ambientes estão em constante sincronia em termos de dados. Uma vez que a nova versão é testada e considerada pronta, o tráfego é trocado do ambiente ativo para o ambiente inativo, tornando-o o novo ambiente ativo. Você não perde tempo implantando novo código e não há tempo de inatividade de produção envolvido. Todos os usuários de produção trabalham o tempo todo no ambiente ativo no momento e nem percebem a mudança.
A implantação canário envolve a implantação de uma nova versão do software para um pequeno subconjunto de usuários, enquanto a maioria dos usuários ou servidores continua a usar a versão atual. Esta é uma implantação gradual em vez de uma troca completa. Os testadores são, neste caso, usuários diretos de produção, embora apenas um subconjunto definido deles. Este grupo está testando ativamente a nova versão com processos de produção e, quando finalmente estável, a nova versão se espalhará para o resto dos usuários.
Então qual é o melhor?
A resposta de um consultor “depende” é a que mais se encaixa aqui, por mais maldosa que possa soar.
Se a prioridade do seu sistema é alta disponibilidade acima de tudo, então a implantação Blue-Green deve ser sua escolha.
Se sua forte preferência for um feedback mais rápido e uma implementação mais controlada (embora mais lenta) da nova versão do sistema, a implantação do Canary terá vantagens sobre o Blue-Green.
O importante é que ambos sejam ágeis o suficiente para se considerarem bons o suficiente para a criação séria de sistemas DevOps.
Estudos de caso
A Netflix usa a implantação Blue-Green para implantar novas versões de seu serviço de streaming. Ao usar a implantação Blue-Green, a Netflix pode implantar novas versões de seu serviço sem afetar a experiência do usuário. Na verdade, a Netflix também usa a implantação do Canary em paralelo para outros casos, portanto, não é irreal combinar diferentes abordagens para a implantação do DevOps sob o mesmo teto.
Além disso, a Amazon e a Etsy usam a implantação Blue-Green para implantar novas versões de sua plataforma de comércio eletrônico.
Outro caso é o LinkedIn, que usa implantação Blue-Green para implantar novas versões de sua plataforma de rede social.
Por último, mas não menos importante, a IBM usa a implantação Blue-Green para implantar novas versões de sua plataforma de nuvem.
Essas empresas implementaram com sucesso a implantação Blue-Green em suas infraestruturas de plataforma e servem como um bom exemplo para outras.
Palavras Finais
Como o Canary, a implantação Blue-Green se esforça para a melhor otimização de seus processos e metodologias ágeis já existentes para entregar novos softwares sem problemas, de forma que ninguém perceba. Este é o objetivo final de tais abordagens. Você entrega constantemente e com muita frequência, mas ninguém sabe disso, ninguém percebe e, no final, ninguém se importa.
Pode ser um pouco frustrante para a equipe de desenvolvimento que não haja fofocas na empresa sobre seus últimos lançamentos. Mas se você me perguntar, este é exatamente o melhor serviço que você pode oferecer. Ninguém fala sobre isso, mas todo mundo usa no dia a dia.
A seguir, confira as perguntas e respostas frequentes das entrevistas de DevOps.