Compreender Estratégias de Implantação

As arquiteturas descritas neste artigo ilustram como criar e implantar um aplicativo moderno com estratégias de implantação Blue-Green e Canary. As estratégias de implantação são modelos e práticas que permitem modificar ou atualizar aplicativos. As estratégias de implantação permitem que as equipes do DevOps definam como os aplicativos são implantados no ambiente de produção.

A escolha entre diferentes estratégias de implantação permite que os administradores façam o equilíbrio certo entre o risco de implantar uma nova versão, o impacto da nova versão em seus usuários e a sobrecarga de infraestrutura necessária para implementar a estratégia. Queremos dar aos nossos clientes mais opções para fazer a troca certa, dadas as necessidades de seus aplicativos.

Sobre implantações do Blue-Green

Com uma estratégia de implantação Blue-Green, as equipes DevOps querem lançar uma nova versão de seu aplicativo usando dois ambientes idênticos em que um deles está ativo em um determinado momento. A versão atual do aplicativo é provisionada no ambiente ativo, enquanto a nova versão é implantada no ambiente stand-by.

A implantação no ambiente stand-by não afeta o ambiente ativo ou o tráfego do usuário. O pipeline de release DevOps pode executar testes de validação na nova versão e, uma vez aprovado, ele é promovido à produção, simplesmente alternando o tráfego do usuário para o ambiente stand-by. Esse processo será repetido para cada nova versão do aplicativo.

A principal vantagem dessa estratégia é que ela oferece tempo de inatividade quase zero e recursos de reversão instantânea. No caso de quaisquer problemas com a nova versão, o tráfego pode reverter instantaneamente para a versão estável anterior. E o ambiente stand-by está disponível para depurar o que deu errado na release do aplicativo.

Este diagrama ilustra uma arquitetura de implantação azul-verde:

Descrição da ilustração blue-green-deployment.png

Compreender os Componentes de Implantação Blue-Green

A arquitetura anterior tem os seguintes componentes.

• Região

  Região OCI é uma área geográfica localizada que contém um ou mais datacenters, denominados domínios de disponibilidade. As regiões são independentes das outras regiões, e grandes distâncias podem se separar (em países ou até mesmo continentes). A arquitetura usa uma única região.

• Projeto do DevOps

  Um agrupamento lógico de recursos do DevOps necessários para implementar um workflow CI/CD. Os recursos do DevOps podem ser artefatos, pipelines de build, pipelines de implantação, conexões externas, triggers e ambientes. Os projetos DevOps facilitam a ativação de logs, monitoramento e notificações em todos os seus recursos DevOps.

• Pipeline de build

  Um pipeline de build obtém um ID de commit dos seus repositórios de código de origem e usa esse código de origem para executar suas instruções de build. Os pipelines de build definem um conjunto de estágios para o processo de criação - criando, testando e compilando artefatos de software, entregando artefatos a repositórios do OCI e, opcionalmente, acionando uma implantação. Você define o fluxo e as instruções de sua execução de criação no arquivo de especificação de criação.

• Estágios de construção

  Os estágios são ações individuais que ocorrem durante uma execução de um pipeline. Os diversos estágios de build mencionados aqui são: Estágios de Build Gerenciados: Um estágio de build gerenciado para criar e testar o código-fonte. Estágio de Entregar Artefatos: Um estágio para enviar as saídas do estágio de criação para vários repositórios. Como imagens de contêiner para repositório de contêiner e manifesto de implantação para registro de artefato. Chamar Implantação: Um estágio para chamar um pipeline de implantação quando os estágios de build forem concluídos, juntamente com o parsing das variáveis exportadas do estágio de build gerenciado para os estágios do pipeline de implantação.

• Repositório de código

  Repositórios Git privados hospedados pelo serviço do DevOps. Você pode armazenar, gerenciar, desenvolver código-fonte com nossos Repositórios de Código DevOps. Pipeline de implantação Uma sequência de etapas para entregar e implantar um conjunto de artefatos em um ambiente de destino. O fluxo e a lógica da sua release do software podem ser controlados pela definição de estágios que podem ser executados em série ou paralelo.

• Estágios de implantação

  Os estágios são ações individuais que ocorrem durante uma execução de um pipeline. Os vários estágios de construção mencionados aqui são:

  • Implantação do Grupo de Instâncias Azul/Verde ou Implantação do Grupo de Instâncias Azul/Verde: Preparação para implantar o código atualizado em ambientes de destino.
  • Validação de Implantação: Estágio opcional para validar as implantações (Funções de Via)
  • Controle: Aprovação: Estágio de controle para aprovar a implantação para o ambiente de produção de destino.
  • Turno de Tráfego do OKE Azul/Verde ou Turno de Tráfego do Grupo de Instâncias Azul/Verde: Etapa final na qual o tráfego de produção será alternado para o ambiente implantado mais recente.

• DevOps artefato

  Um artefato DevOps é uma referência ou ponteiro para qualquer arquivo, binário, pacote, manifesto ou imagem que compõe seu aplicativo. Ao criar um artefato, informe o Oracle DevOps do local de origem do artefato real. O DevOps suporta os repositórios OCI Container Image Registry e OCI Artifact Registry.

• Repositório de artefatos

  O Repositório de Artefatos cria repositórios para agrupar artefatos semelhantes. Quando o repositório for criado, você poderá fazer upload de artefatos para ele. Esses artefatos são um conjunto de arquivos de texto, binários e manifestos de implantação fornecidos para o ambiente de implantação de destino. Cada artefato tem um nome, que é feito de seu caminho: versão. O caminho é uma string para organizar os artefatos.

• Serviços de registro e notificação do OCI

  O serviço OCI Logging armazena logs relacionados à implantação. A saída de runtime da implantação e os resultados finais da implantação são mostrados como entradas de log. O serviço OCI Notifications oferece visibilidade sobre o estado mais recente do projeto de implantação e seus recursos e toma as medidas necessárias. Por exemplo, você é notificado quando um evento importante, como um estágio em um pipeline de implantação aguardando aprovação. Quando você receber a mensagem de notificação, poderá ir para pipelines de implantação DevOps e aprovar o estágio.

• Ambientes de implantação

  Um ambiente é uma coleção de recursos de computação de um cliente em que artefatos são implantados. Os ambientes podem ser uma instância de função, de VM (máquina virtual) ou bare metal do Compute ou um cluster OKE. A implantação Blue Green só está disponível com máquinas virtuais de cluster e Computação do OKE.

Compreender os Prós e Contras das Implementações Blue-Green

Ao implantar um aplicativo moderno, há prós e contras para usar uma estratégia Blue-Green.

As vantagens das implantações do Blue-Green são:

• As implantações Blue Green permitem implantações rápidas e sem riscos.
• Eles permitem um mecanismo de rollback simples e eficaz.
• Eles são uma maneira eficaz de orquestrar testes de software A/B.
• Tempo de inatividade zero ou quase zero, pois a produção é sempre servida por meio de um dos ambientes ativos (por trás de um balanceador de carga).

Os lotes de implantações do Blue-Green são:

• A manutenção do ambiente de uma implantação azul-verde requer um custo intenso para ambientes e recursos idênticos.
• Você precisa monitorar de perto os dois ambientes para gerenciar a release entre dois ambientes idênticos.
• O gerenciamento de dependências de banco de dados entre implantações é complicado.

Sobre Implantações Canárias

Com uma estratégia de implantação Canária, a versão do aplicativo acontece incrementalmente a um subconjunto de usuários. Inicialmente, a nova versão é implantada em um ambiente canário sem tráfego do usuário. O pipeline de release DevOps pode executar testes de validação na nova versão e, uma vez pronto, rotear somente um subconjunto de usuários para o ambiente canário.

Essa técnica permite que a equipe DevOps avalie a nova versão do aplicativo em relação ao tráfego real do usuário. Eles podem comparar as duas versões do aplicativo lado a lado antes de implantar a nova versão em uma base de usuário maior. Ele também oferece mitigação de risco, pois a nova versão só está ativada para um pequeno subconjunto de usuários - esses usuários podem alternar facilmente para a versão anterior em caso de problemas.

O diagrama a seguir ilustra uma estratégia de implantação do Canário:

Descrição da ilustração canary-deployment.png

Compreender Componentes de Implantação Canários

A arquitetura anterior tem os seguintes componentes.

• Região

  Uma região do OCI é uma área geográfica localizada que contém um ou mais datacenters, denominados domínios de disponibilidade. As regiões são independentes das outras regiões, e grandes distâncias podem se separar (em países ou até mesmo continentes). A arquitetura usa uma única região.

• Projeto do DevOps

  Um agrupamento lógico de recursos do DevOps necessários para implementar um workflow CI/CD. Os recursos do DevOps podem ser artefatos, pipelines de build, pipelines de implantação, conexões externas, triggers e ambientes. Os projetos DevOps facilitam a ativação de logs, monitoramento e notificações em todos os seus recursos DevOps.

• Pipeline de build

  Um pipeline de build obtém um ID de commit dos seus repositórios de código de origem e usa esse código de origem para executar suas instruções de build. Os pipelines de build definem um conjunto de estágios para o processo de criação - criando, testando e compilando artefatos de software, entregando artefatos a repositórios do OCI e, opcionalmente, acionando uma implantação. Você define o fluxo e as instruções de sua execução de criação no arquivo de especificação de criação.

• Estágios de construção

  Os estágios são ações individuais que ocorrem durante uma execução de um pipeline. Os diversos estágios de construção mencionados aqui são:

  • Estágios de Build Gerenciados: Um estágio de build gerenciado para criar e testar o código-fonte.
  • Estágio Entregar Artefatos: Um estágio para enviar as saídas do estágio de criação para vários repositórios. Como imagens de contêiner para repositório de contêiner e manifesto de implantação para registro de artefato.
  • Chamar Implantação: Um estágio para chamar um pipeline de implantação quando os estágios de build forem concluídos, juntamente com o parsing das variáveis exportadas do estágio de build gerenciado para os estágios do pipeline de implantação.

• Repositório de código

  Repositórios Git privados hospedados pelo serviço do DevOps. Você pode armazenar, gerenciar, desenvolver código-fonte com nossos Repositórios de Código DevOps.

• Pipeline de implantação

  Uma sequência de etapas para entregar e implantar um conjunto de artefatos em um ambiente de destino. O fluxo e a lógica da sua release do software podem ser controlados pela definição de estágios que podem ser executados em série ou paralelo.

• Estágios de implantação

  Os estágios são ações individuais que ocorrem durante uma execução de um pipeline. Os vários estágios de construção mencionados aqui são:

  • Implantação do OKE Canário ou Implantação do Grupo de Instâncias Canárias: Preparação para implantar o código atualizado em ambientes canários de destino.
  • Validação de Implantação: Estágio opcional para validar as implantações (Funções de Via)
  • Turno de Tráfego OKE Canário ou Turno de Tráfego do Grupo de Instâncias Canárias: Estágio para alternar o tráfego para o ambiente canário com base no limite de rampa (% do tráfego para turno).
  • Controle: Aprovação: Estágio de controle para aprovar a implantação para o ambiente de produção de destino.
  • Produção do Grupo de Instâncias de Implantação Canária ou OKE - Implantar Produção: Etapa final na qual o tráfego de produção será alternado para o ambiente implantado mais recente.

• DevOps artefato

  Um artefato DevOps é uma referência ou ponteiro para qualquer arquivo, binário, pacote, manifesto ou imagem que compõe seu aplicativo. Ao criar um artefato, informe o Oracle DevOps do local de origem do artefato real. O DevOps suporta os repositórios OCI Container Image Registry e OCI Artifact Registry.

• Repositório de artefatos

  O Repositório de Artefatos cria repositórios para agrupar artefatos semelhantes. Quando o repositório for criado, você poderá fazer upload de artefatos para ele. Esses artefatos são um conjunto de arquivos de texto, binários e manifestos de implantação fornecidos para o ambiente de implantação de destino. Cada artefato tem um nome, que é feito de seu caminho: versão. O caminho é uma string para organizar os artefatos.

• Serviços de registro e notificação da OCI

  O serviço OCI Logging armazena logs relacionados à implantação. A saída de runtime da implantação e os resultados finais da implantação são mostrados como entradas de log. O serviço OCI Notifications oferece visibilidade sobre o estado mais recente do projeto de implantação e seus recursos e toma as medidas necessárias. Por exemplo, você é notificado quando um evento importante, como um estágio em um pipeline de implantação aguardando aprovação. Quando você receber a mensagem de notificação, poderá ir para pipelines de implantação DevOps e aprovar o estágio.

• Ambientes de implantação

  Um ambiente é uma coleção de recursos de computação de um cliente em que artefatos são implantados. Os ambientes podem ser uma instância de função, de VM (máquina virtual) ou bare metal do Compute ou um cluster OKE. A implantação Blue Green só está disponível com máquinas virtuais de cluster e Computação do OKE.

Compreender os Prós e Contras das Implantações Canárias

Há prós e contras para usar uma estratégia Canary ao implantar um aplicativo moderno.

Os prós das implantações Canárias são:

• Ele permite testar duas versões de aplicativos lado a lado com usuários reais.
• Não há tempo de inatividade para a nova versão.
• A reversão para uma versão anterior é muito fácil e fornece o menor risco.

Os consensos de implantações Canárias são:

• O teste e a validação de uma nova versão podem ser complexos em escala.
• Extrair o feedback do teste do usuário para uma nova versão é uma tarefa demorada.