Usar uma estratégia de implantação canário

Este documento descreve como configurar e usar uma estratégia de implantação canário.

O que é uma implantação canário?

Uma implantação canário é um lançamento progressivo de um aplicativo que divide o tráfego entre uma versão já implantada e uma nova, lançando-a para um subconjunto de usuários antes do lançamento completo.

Tipos de segmentação compatíveis

A implantação canário no Cloud Deploy dá suporte a todos os tipos de destino, incluindo o seguinte:

O Canary também funciona com vários alvos.

Por que usar uma estratégia de implantação canário?

Uma implantação canário oferece a chance de lançar parcialmente seu aplicativo. Em Dessa forma, é possível garantir que a nova versão do aplicativo seja confiável antes entregá-lo a todos os usuários.

Se você estiver fazendo implantações no GKE ou no GKE Enterprise, exemplo, você implantaria a nova versão do seu aplicativo em uma de pods. A versão antiga continuaria a funcionar, mas com mais tráfego que está sendo enviado para os novos pods.

Se você estiver implantando no Cloud Run, o Cloud Run divide o tráfego entre a revisão antiga e a nova, de acordo com a e porcentagens que você configurar.

Tipos de canário

O Cloud Deploy permite configurar os seguintes tipos de implantação canário:

  • Automatizado

    Com uma implantação canário automatizada, você configura o Cloud Deploy com uma série de porcentagens que expressam uma implantação progressiva. Cloud Deploy realiza operações adicionais em seu nome, para distribuir o tráfego porcentagens entre a versão antiga e a nova.

  • Personalizado e automatizado

    Para um teste canário personalizado-automatizado, você pode fornecer o seguinte:

    • O nome da fase
    • A meta percentual
    • O perfil do Skaffold a ser usado para a fase
    • Se é necessário incluir ou não um job de verificação
    • Incluir ou não um job de pré ou pós-implantação ou ambos

    Mas não é preciso fornecer informações de balanceamento de tráfego. Cloud Deploy cria o os recursos necessários.

  • Personalizado

    Com um canário personalizado, você configura cada fase canário separadamente. incluindo o seguinte:

    • O nome da fase
    • A meta percentual
    • O perfil do Skaffold a ser usado para a fase
    • Se é necessário incluir ou não um job de verificação
    • Incluir ou não um job de pré ou pós-implantação ou ambos

    Além disso, para um canário totalmente personalizado, você fornece toda a configuração de balanceamento de tráfego, conforme descrito aqui.

Fases de uma implantação canário

Quando você cria uma versão para uma implantação canário, o lançamento é criado com uma fase para cada incremento canário, mais uma fase stable final para 100%.

Por exemplo, se você configurar um canário para incrementos de 25%, 50% e 75%, o lançamento terá as seguintes fases:

  • canary-25
  • canary-50
  • canary-75
  • stable

Leia mais sobre fases de lançamento, jobs e execuções de jobs em Gerenciar lançamentos

O que acontece durante um teste canário automatizado ou personalizado

Para dar suporte à implantação canário, o Cloud Deploy inclui recursos de processamento ao renderizar o manifesto do Kubernetes ou Configuração do serviço do Cloud Run:

GKE/Enterprise

Confira como o Cloud Deploy executa uma implantação canário no GKE e no GKE Enterprise baseados na rede:

  1. Você fornece o nome do recurso de implantação e do recurso de serviço.

  2. O Cloud Deploy cria outro recurso de implantação, o nome da implantação atual mais -canary.

  3. O Cloud Deploy modifica o serviço para ajustar o seletor e selecionar os pods na implantação atual e nos pods canários.

    O Cloud Deploy calcula o número de pods a serem usados para o canário com base no cálculo descrito aqui. Esse cálculo é diferente se você ativa ou desativa o overprovisionamento de pods.

    Se estivermos pulando para a fase stable, o Cloud Deploy vai adicionar os rótulos a serem usados para corresponder aos pods, para que eles fiquem disponíveis para execuções canário subsequentes.

    O Cloud Deploy cria uma implantação que inclui as porcentagem de pods específica de fase, atualizando-o para cada fase. Isso é é feito calculando o número de pods como uma porcentagem do de pods. Isso pode resultar em uma divisão de tráfego imprecisa. Se você precisar de uma divisão de tráfego exata, use a API Gateway.

    Além disso, os Secrets e ConfigMaps também são copiados e renomeados com -canary.

  4. Durante a fase stable, a implantação -canary é reduzida para zero, e a implantação original é substituída pela nova.

    O Cloud Deploy não modifica a implantação original até a fase stable.

O Cloud Deploy provisiona pods para alcançar o canário solicitado o mais próximo possível. Isso se baseia no número de pods, e não no tráfego para os pods. Se você quiser que o canário seja baseado no tráfego, use a API Gateway.

Para o canário baseado em rede do GKE, é possível ativar ou desativar o provisionamento excessivo de pods. As seções a seguir descrevem como o Cloud Deploy calcula número de pods a serem provisionados para a implantação canário em cada fase canário.

Provisionamento de pods com superprovisionamento ativado

Como ativar o superprovisionamento (disablePodOverprovisioning: false) permite que o Cloud Deploy crie pods adicionais suficientes para executar o porcentagem canário que você quer, com base no número de pods que executam seu implantação atual. A fórmula a seguir mostra como O Cloud Deploy calcula o número de pods a serem provisionados para o implantação canário para cada fase canário, quando o provisionamento excessivo de pods ativado:

math.Ceil( percentage * ReplicaCountOfDeploymentOnCluster / (100-percentage))

Com esta fórmula, a contagem atual de réplicas (o número de pods que você já têm, antes deste canário) é multiplicado pela porcentagem de canários para o e o resultado é dividido por (100 menos a porcentagem).

Por exemplo, se você tiver 4 pods e a fase canário for 50%, e o número de pods canário será 4. O resultado de 100-percentage é usado como uma porcentagem: 100-50=50, tratado como .50.

O superprovisionamento de pods é o comportamento padrão.

Provisionamento de pods com superprovisionamento desativado

É possível desativar o superprovisionamento (disablePodOverprovisioning: true). para garantir que o Cloud Deploy não aumente a contagem de réplicas.

A fórmula a seguir mostra como o Cloud Deploy calcula o pod para a implantação canário em cada fase canário, quando o pod o superprovisionamento está desativado:

math.Ceil( (ReplicaCountOfDeploymentOnCluster + ReplicaCountOfCanaryDeploymentOnCluster) * percentage)

Nessa fórmula, ReplicaCountOfCanaryDeploymentOnCluster só existe se já houver uma fase de canário. Se esta for a primeira fase de canário, não haverá ReplicaCountOfCanaryDeploymentOnCluster.

Se você começar com quatro pods, esse número será multiplicado pela porcentagem do canário (por exemplo, 50% ou .5) para gerar 2. A implantação original agora está com 2 pods, e 2 novos são criados para a implantação canário. Se você tem um estágio canário 75%, tem 2 (implantação original) +2 (primeiro estágio canário), *.75, para receber 3 pods canário e 1 pod que executa o implantação original.

Gateway GKE/Enterprise

Veja como o Cloud Deploy executa uma implantação canário em GKE e GKE Enterprise usando a API Gateway:

  1. Além das referências à implantação e ao serviço, você fornece uma recurso HTTPRoute, com uma regra backendRefs que faz referência ao serviço.

  2. O Cloud Deploy cria uma nova implantação com o nome da implantação original mais -canary e um novo serviço com o nome do serviço original mais -canary.

    Além disso, segredos, ConfigMaps e escalonadores automáticos de pods horizontais também são copiados e renomeados com -canary.

  3. Para cada fase canário, o Cloud Deploy modifica o HTTPRoute para atualizar a ponderação entre os pods da implantação original e o pods da implantação canário, com base na porcentagem dessa fase.

    Como pode haver um atraso na propagação de mudanças para recursos HTTPRoute, é possível incluir a propriedade routeUpdateWaitTime na configuração para que o sistema aguarde um período especificado para essa propagação.

  4. Durante a fase stable, a implantação -canary é reduzida para zero, e a implantação original é atualizada para usar o Implantação.

    Além disso, o HTTPRoute foi revertido para o original que você forneceu.

    O Cloud Deploy não modifica a implantação original nem Serviço até a fase stable.

Cloud Run

Confira como o Cloud Deploy executa uma implantação canário para o Cloud Run:

  • Para uma implantação canário no Cloud Run, não forneça um traffic estrofe no YAML de serviço.

  • Ao criar um novo lançamento para canário, o Cloud Deploy divide o tráfego entre a revisão anterior que foi implantada pelo Cloud Deploy e uma nova revisão.

Se você quiser saber as diferenças entre as fases de uma implantação canário, confira as mudanças no manifesto renderizado por fase disponível no Release Inspector. Você pode fazer isso antes mesmo lançamento foi iniciado. Além disso, se você estiver usando implantação paralela, você também poderá inspecionar manifesto renderizado.

Configurar uma implantação canário

Esta seção descreve como configurar o pipeline de entrega e os destinos para uma implantação canário.

As instruções aqui incluem apenas o que é específico para a configuração canário. O documento Implantar seu aplicativo tem as instruções gerais para configurar e executar o pipeline de implantação.

Verifique se você tem as permissões necessárias

Além das outras permissões de gerenciamento de identidade e acesso necessárias para usar o Cloud Deploy, você precisa das seguintes permissões para realizar outras ações que podem ser necessárias para uma implantação canário:

  • clouddeploy.rollouts.advance
  • clouddeploy.rollouts.ignoreJob
  • clouddeploy.rollouts.cancel
  • clouddeploy.rollouts.retryJob
  • clouddeploy.jobRuns.get
  • clouddeploy.jobRuns.list
  • clouddeploy.jobRuns.terminate

Consulte Papéis e permissões do IAM para mais informações sobre quais papéis disponíveis incluem essas permissões.

Prepare o skaffold.yaml

Assim como em uma implantação padrão, o canário precisa de um arquivo skaffold.yaml, que define como os manifestos e as definições de serviço são renderizados e implantados.

O skaffold.yaml criado para uma implantação canário não tem além do que é necessário para os padrões implantação do Google Workspace.

Preparar a definição de serviço ou manifesto

Assim como em uma implantação padrão, seu canário precisa de um manifesto do Kubernetes ou de um Definição do serviço do Cloud Run.

GKE e GKE Enterprise

Para o canário, seu manifesto precisa ter o seguinte:

  • Uma implantação e um serviço.

  • O serviço precisa definir um seletor, e esse seletor precisa selecionar os pods da implantação especificada. O padrão é app.

  • Se você estiver usando um canário baseado na API de gateway, o manifesto também precisará ter uma HTTPRoute.

Cloud Run

Para o canário no Cloud Run, o arquivo de definição de serviço normal do Cloud Run é suficiente, mas sem uma estrofe traffic. O Cloud Deploy gerencia a divisão do tráfego entre a última revisão bem-sucedida e a nova revisão.

Configurar um canário automático

As instruções a seguir são para o Cloud Run e alvos de rede baseados em serviço do GKE e do GKE Enterprise. Se você estiver usando a API Kubernetes Gateway com o GKE ou o GKE Enterprise, consulte esta documentação.

Configure o canário automatizado na definição do pipeline de entrega:

GKE e GKE Enterprise

No estágio do pipeline, inclua uma propriedade strategy, conforme mostrado abaixo:

serialPipeline:
  stages:
  - targetId: prod
    profiles: []
    strategy:
      canary:
        runtimeConfig:
          kubernetes:
            serviceNetworking:
              service: "SERVICE_NAME"
              deployment: "DEPLOYMENT_NAME"
              podSelectorLabel: "LABEL"
        canaryDeployment:
          percentages: [PERCENTAGES]
          verify: true|false
          predeploy:
            actions: "PREDEPLOY_ACTION"
          postdeploy:
            actions: "POSTDEPLOY_ACTION"

Nesta configuração...

  • SERVICE_NAME é o nome do serviço do Kubernetes; definido no manifesto.

  • DEPLOYMENT_NAME é o nome da implantação do Kubernetes, definido no manifesto.

  • LABEL é um rótulo do seletor de pods. Ele precisa corresponder ao seletor de identificador no serviço do Kubernetes definido no manifesto. Isso é opcional. O padrão é app.

  • PERCENTAGES é uma lista separada por vírgulas de valores de porcentagem que representam os incrementos de canário, por exemplo, [5, 25, 50].

    Além disso, isso não inclui 100, porque 100% da implantação está assumed no canário e é processada pelo stable.

  • É possível ativar a verificação de implantação (verify: true). Se você fizer isso, um job verify será ativado em cada fase.

  • PREDEPLOY_ACTION

    É o mesmo que o ACTION_NAME usado no skaffold.yaml para definir a ação personalizada que você quer executar antes da implantação.

  • POSTDEPLOY_ACTION

    É igual ao ACTION_NAME que você usou no seu skaffold.yaml para definir a ação personalizada que você quer executar depois implantação.

Cloud Run

No estágio do pipeline, inclua uma propriedade strategy, conforme mostrado abaixo:

serialPipeline:
  stages:
  - targetId: prod
    profiles: []
    strategy:
      canary:
        runtimeConfig:
          cloudRun:
            automaticTrafficControl: true
        canaryDeployment:
          percentages: [PERCENTAGES]
          verify: true|false
          predeploy:
            actions: "PREDEPLOY_ACTION"
          postdeploy:
            actions: "POSTDEPLOY_ACTION"

Nesta configuração...

  • PERCENTAGES é uma lista separada por vírgulas de valores de porcentagem que representam os incrementos de canário, por exemplo, [25, 50, 75]. Observe que isso não inclui 100, porque a implantação de 100% é presumenda no canário e é processada pela fase stable.

  • É possível ativar a verificação da implantação. (verify: true). Se você fizer isso, um job verify será adicionado a cada fase canário.

  • PREDEPLOY_ACTION

    É igual ao ACTION_NAME que você usou no seu skaffold.yaml para definir a ação personalizada que você quer executar antes implantação.

  • POSTDEPLOY_ACTION

    É igual ao ACTION_NAME que você usou no seu skaffold.yaml para definir a ação personalizada que você quer executar depois implantação.

Configurar um canário personalizado

É possível configurar seu canário manualmente em vez de depender totalmente do automatizada fornecida pelo Cloud Deploy. Com canário personalizado especifique o seguinte na definição do pipeline de entrega:

  • Nomes das fases de lançamento

    Em um canário totalmente automatizado, o Cloud Deploy nomeia as fases para você (canary-25, canary-75, stable, por exemplo). No entanto, com um canário personalizado, é possível dar a cada fase qualquer nome, desde que ele seja exclusivo entre todas as fases desse estágio do canário e respeite as restrições de nome de recurso. Mas o nome da fase final (100%) precisa ser stable.

  • Metas percentuais para cada fase

    Especifique as porcentagens separadamente, por fase.

  • Perfis do Skaffold a serem usados para a fase

    É possível usar um perfil do Skaffold separado para cada fase, ou o mesmo perfil, ou qualquer combinação. E cada perfil pode usar um manifesto diferente do Kubernetes ou do serviço do Cloud Run. Também é possível usar mais de um perfil para uma determinada fase. O Cloud Deploy combina esses recursos.

  • Se há um job de verificação para a fase

    Se você ativar a verificação, será preciso configure o skaffold.yaml para verificação também.

  • Se há jobs de pré ou pós-implantação para a fase

    Se você estiver ativando jobs de pré-implantação ou pós-implantação, será necessário configurar o skaffold.yaml para esses jobs.

Todos os tipos de destino são compatíveis com o canário personalizado.

Elementos personalizados de configuração canário

O YAML a seguir mostra a configuração das fases do canário totalmente personalizado implantação:

strategy:
  canary:
    # Custom configuration for each canary phase
    customCanaryDeployment:
      phaseConfigs:
      - phaseId: "PHASE1_NAME"
        percentage: PERCENTAGE1
        profiles: [ "PROFILE_NAME" ]
        verify: true | false
        predeploy:
          actions: "PREDEPLOY_ACTION"
        postdeploy:
          actions: "POSTDEPLOY_ACTION"
      - …
      - phaseId: "stable"
        percentage: 100
        profiles: [ "LAST_PROFILE_NAME" ]
        verify: true|false
        predeploy:
          actions: "PREDEPLOY_ACTION"
        postdeploy:
          actions: "POSTDEPLOY_ACTION"

Neste YAML

  • PHASE1_NAME

    É o nome da fase. Cada nome de fase precisa ser exclusivo.

  • [ "PROFILE_NAME" ]

    É o nome do perfil a ser usado para a fase. Você pode usar o mesmo perfil para cada fase, um diferente para cada uma ou qualquer combinação. Também é possível especifique mais de um perfil. O Cloud Deploy usa todos os perfis especificados, além do perfil ou manifesto usado pela fase geral.

  • stable

    A fase final precisa ser nomeada como stable.

  • PERCENTAGE1

    É a porcentagem a ser implantada na primeira fase. Cada fase precisa ter um valor de porcentagem exclusivo, e esse valor precisa ser uma porcentagem inteira (não 10.5, por exemplo), e as fases precisam estar em ordem crescente.

  • verify: true|false

    Informa ao Cloud Deploy se é necessário incluir um job de verificação para a fase. Para cada fase usar a verificação, o Skaffold usa o mesmo perfil de verificação especificado para renderizar e implantar essa fase.

  • PREDEPLOY_ACTION

    É igual ao ACTION_NAME que você usou no seu skaffold.yaml para definir a ação personalizada que você quer executar antes da implantação.

  • POSTDEPLOY_ACTION

    É igual ao ACTION_NAME que você usou no seu skaffold.yaml para definir a ação personalizada que você quer executar após a implantação.

A porcentagem da última fase precisa ser 100. As fases são executadas de acordo com a ordem em que você as configura nesta estrofe ​customCanaryDeployment. No entanto, se os valores de porcentagem não estiverem em ordem crescente, o comando para registrar o pipeline de entrega vai falhar com um erro.

A configuração de um canário personalizado não inclui um runtimeConfig estrofe. Se você incluir runtimeConfig, ele será considerado um canário automatizado personalizado.

Configurar um teste canário automático personalizado

Um canário automatizado personalizado é semelhante a um canário personalizado, porque você especifica as fases de canário separadas, com nomes de fases personalizados, valores de porcentagem, perfis do Skaffold, jobs de verificação e jobs de pré-implantação e pós-implantação. No entanto, com um canário personalizado, você não fornece o configurações que definem a distribuição de tráfego. O Cloud Deploy faz isso mas você ainda fornece Perfis do Skaffold que será usado em cada etapa.

Para configurar um canário personalizado automatizado, inclua uma estrofe runtimeConfig, conforme mostrado aqui, e inclua a estrofe customCanaryDeployment, conforme mostrado aqui.

Configurar uma implantação canário usando a malha de serviço da API Gateway do Kubernetes

Embora seja possível usar uma implantação canário do Cloud Deploy para implantar seu aplicativo em uma rede baseada em serviços do Kubernetes, uma alternativa é usar a malha de serviço da API Gateway do Kubernetes. Esta seção mostra como fazer isso.

É possível usar a API Gateway com o Istio ou qualquer implementação com suporte.

  1. Configure os recursos da API Gateway:

    Estes são apenas exemplos.

  2. No manifesto do Kubernetes, fornecido ao Cloud Deploy quando você criou a versão, inclua o seguinte:

    • Um HTTPRoute que faz referência ao recurso de gateway

    • Uma implantação

    • Um serviço

  3. Configure o pipeline de entrega e o destino da implantação canário para:

    • A configuração para o destino é a mesma para qualquer destino.

    • A configuração do pipeline de entrega, na sequência de progressão para o destino específico, inclui uma estrofe gatewayServiceMesh para fazer referência à sua configuração HTTPRoute da API Gateway do Kubernetes, bem como à sua implantação e ao serviço.

      strategy:
 canary:
   runtimeConfig:
     kubernetes:
       gatewayServiceMesh:
         httpRoute: "ROUTE"
         service: "SERVICE"
         deployment: "DEPLOYMENT"
         routeUpdateWaitTime: "WAIT_TIME"
         podSelectorLabel: "LABEL"
   canaryDeployment:
     percentages:
     - 50

      Em que…

      • ROUTE é a configuração de httpRoute que define o roteamento comportamento que você quer.

      • SERVICE é a configuração do serviço, que O Cloud Deploy exige que as implantações canário GKE e GKE Enterprise.

      • DEPLOYMENT é a configuração de implantação, que o Cloud Deploy exige para implantações canário no GKE e no GKE Enterprise.

      • WAIT_TIME é o tempo que o Cloud Deploy leva para esperar que as mudanças no recurso HTTPRoute sejam concluídas para evitar solicitações perdidas. Por exemplo: routeUpdateWaitTime: 60s.

        Se você estiver executando o canário usando a API Gateway sem o Istio e a API Gateway estiver conectada a um balanceador de carga do Google Cloud, uma pequena quantidade de tráfego poderá ser perdida quando a instância do canário for reduzida. Você pode defina essa configuração se observar esse comportamento.

      • LABEL é um rótulo do seletor de pods. Ele precisa corresponder ao seletor de identificador no serviço e na implantação do Kubernetes definidos no manifesto. Isso é opcional. O padrão é app.

Usar a implantação paralela com uma estratégia de implantação canário

É possível executar uma implantação canário usando a implantação paralela. Isso significa que o destino que você está implantando progressivamente pode abranger dois ou mais destinos filhos. Por exemplo, é possível implantar progressivamente em clusters em locais ao mesmo tempo.

Qual é a diferença entre um canário paralelo e um canário de destino único?

  • Assim como na implantação canário de destino único, se você estiver implantando para destinos do GKE, precisará de uma configuração de implantação do Kubernetes e uma configuração de serviço do Kubernetes no manifesto.

  • Assim como na implantação de canário de destino único, a configuração do pipeline de entrega precisa incluir uma estrofe strategy.canary dentro da definição de estágio para o estágio aplicável.

  • Além disso, é necessário configurar um destino múltiplo e configurar os destinos filhos a que o destino múltiplo faz referência.

  • Quando você cria uma versão, um lançamento do controlador e os lançamentos filhos são criados.

    Os dois tipos de lançamento (controlador e filho) têm fases separadas para todas as porcentagens de canário configuradas e uma fase stable para o canário 100%.

  • Não é possível avançar um lançamento filho.

    Só é possível avançar os lançamentos de controladores. Quando você avança o lançamento do controlador para a próxima fase, os lançamentos filhos também são avançados pelo Cloud Deploy.

  • Não é possível tentar de novo jobs com falha no lançamento do controlador.

    Só é possível executar um job novamente em lançamentos filhos.

  • Não é possível ignorar jobs com falha no lançamento do controlador.

    Só é possível ignorar jobs com falha em lançamentos filhos.

  • É possível cancelar o lançamento de um controlador, mas não é possível cancelar lançamentos filhos.

  • Você pode encerrar execuções de jobs somente em um lançamento filho, não em um lançamento do controlador.

O que fazer se um lançamento paralelo falhar no canário

Quando um lançamento filho falha, o lançamento do controlador pode fazer a transição para diferentes estados, dependendo do que acontece com os lançamentos filhos:

  • Se um ou mais lançamentos filhos falharem, mas pelo menos um lançamento filho ainda estiver IN_PROGRESS, o lançamento do controlador vai permanecer IN_PROGRESS.

  • Se um ou mais lançamentos filhos falharem, mas pelo menos um lançamento filho tiver sucesso, o lançamento do controlador será HALTED se houver mais fases após a atual.

    Se esta for a fase stable, o lançamento do controlador será FAILED.

    HALTED oferece a você a chance de ignorar, tentar de novo jobs com falha no lançamento filho com falha ou cancelar o lançamento do controle e impedir outras ações nos lançamentos filhos.

  • Se o lançamento do controlador estiver em um estado HALTED devido a um lançamento filho com falha e você ignorar o job com falha no lançamento filho, o lançamento do controlador será revertido para um estado IN_PROGRESS.

Executar o canário configurado

Para executar a implantação canário:

  1. Registre o pipeline de entrega e os destinos configurados.

    gcloud deploy apply --file=PIPELINE

    O pipeline de envio inclui a configuração canário automática ou personalizada para o ambiente de execução escolhido.

    Esse comando pressupõe que os destinos são definidos no mesmo arquivo ou já foram registrados. Caso contrário, registre suas metas também.

  2. Criar uma versão:

    gcloud deploy releases create RELEASE_NAME \
                              --delivery-pipeline=PIPELINE_NAME \
                              --region=REGION

    O pipeline de entrega identificado por PIPELINE_NAME contém a configuração canário personalizada ou automática descrita neste documento.

  3. Avançar o canário:

    CLI da gcloud 

    gcloud deploy rollouts advance ROLLOUT_NAME \
                            --release=RELEASE_NAME \
                            --delivery-pipeline=PIPELINE_NAME \
                            --region=REGION

    Em que:

    ROLLOUT_NAME é o nome do lançamento atual. que você está avançando para a próxima fase.

    RELEASE_NAME é o nome da versão que deste lançamento faz parte.

    PIPELINE_NAME é o nome do pipeline de entrega que você está usando para gerenciar a implantação dessa versão.

    REGION é o nome da região em que o versão foi criada, por exemplo us-central1. Obrigatório.

    Consulte a referência do SDK Google Cloud para mais informações sobre o comando gcloud deploy rollouts advance.

    Console do Google Cloud

    1. Abra a página "Pipelines de entrega".

    2. Clique no pipeline mostrado na lista de pipelines de entrega.

      A página de detalhes do pipeline de entrega mostra uma representação gráfica do progresso do pipeline de entrega.

    3. Na guia Lançamentos, em Detalhes do pipeline de entrega, clique no nome do lançamento.

      A página de detalhes da implementação é mostrada para essa implementação.

      detalhes do lançamento no console do Google Cloud

      Observe que, neste exemplo, o lançamento tem uma fase canary-50 e uma stable. O lançamento pode ter mais fases ou fases diferentes.

    4. Clique em Avançar o lançamento.

      O lançamento avança para a próxima fase.

Fases ignoradas

Se você implantar um canário e o aplicativo ainda não tiver sido implantado nesse ambiente de execução, o Cloud Deploy vai pular a fase de canário e executar a fase estável. Consulte Pular fases na primeira vez para descobrir por que isso acontece.

A seguir