verifique sua implantação

Neste documento, descrevemos como verificar uma implantação do Cloud Deploy.

É possível configurar o Cloud Deploy para verificar se um aplicativo implantado em qualquer destino está funcionando corretamente. A verificação é feita usando suas próprias imagens de teste, e você configura o Cloud Deploy para executar esses testes depois que a implantação termina.

Como funciona a verificação de implantação?

  1. Você configura um ou mais destinos no pipeline de entrega para verificação da implantação definindo tarefas a serem executadas.

  2. Depois que um aplicativo é implantado, o Cloud Deploy executa as tarefas de verificação no ambiente de execução do Cloud Deploy.

    O sucesso ou a falha dos testes executados indica o sucesso ou a falha da verificação:

    • O sucesso da verificação é determinado pelo código de saída gerado pelo contêiner.

      0 indica sucesso. Um código de saída diferente de zero indica falha. Para gerar o resultado de verificação esperado, verifique se o contêiner sai com o código de saída apropriado. Se mais de um contêiner for executado como parte da verificação, todos precisarão ser bem-sucedidos para que a verificação seja bem-sucedida.

    • Se a verificação falhar, o lançamento também vai falhar.

    • Se uma implantação falhar durante a verificação, inspecione o lançamento para saber o motivo:

      Detalhes no console Google Cloud para lançamento, incluindo o status da verificação

  3. Você pode ignorar ou tentar de novo uma verificação com falha.

    Também é possível encerrar um job de verificação em andamento.

Componentes usados para verificação

O recurso rollout inclui os seguintes objetos, que oferecem suporte à verificação de implantação:

  • Fase

    A coleção de operações (jobs) em um lançamento que são agrupadas logicamente, por exemplo, uma implantação ou uma implantação e verificação.

  • Job

    A operação específica a ser realizada em um lançamento, como implantação ou verificação.

  • Execução do job

    Um filho do recurso de lançamento, a execução de job é uma instância de um job, por exemplo, uma tentativa de implantação.

Para mais informações sobre os recursos do Cloud Deploy, consulte Arquitetura de serviço do Cloud Deploy.

Configurar o Cloud Deploy para verificação de implantação

Para ativar a verificação de implantação em um destino do Cloud Deploy, adicione uma estrofe verify a um ou mais destinos em uma progressão de pipeline de entrega, conforme mostrado neste exemplo:

apiVersion: deploy.cloud.google.com/v1
kind: DeliveryPipeline
metadata:
 name: my-demo-app
description: main application pipeline
serialPipeline:
 stages:
 - targetId: dev
   profiles: []
   strategy:
     standard:
       verify:
         tasks:
         - type: container
           image: "VERIFY_IMAGE"
           command: [COMMANDS_TO_RUN]
           args: [LIST_OF_ARGS]
           env: {VERIFY_TASK_ENV_MAP}

Neste YAML:

  • VERIFY_IMAGE

    É o nome da imagem que você quer executar para o job de verificação. Por exemplo, us-central1-docker.pkg.dev/gcp-project-id-12345/my-repository/my-app:v1.2 para uma imagem do Artifact Registry.

  • COMMANDS_TO_RUN

    É uma lista de pontos de entrada a serem executados nesse contêiner. "/bin/sh" é um comando típico para especificar aqui e invocar um shell.

  • LIST_OF_ARGS

    É uma lista de argumentos a serem fornecidos ao comando. Essa é uma lista separada por vírgulas, com cada argumento entre aspas. Se o COMMAND_TO_RUN for "/bin/sh", um dos argumentos aqui será "-c", e outro será todo o comando que você quer executar no shell que está invocando.

    Veja um exemplo:

    command: ["/bin/sh"]
    args: ["-c", `echo "This command ran!"`]
    
  • VERIFY_TASK_ENV_MAP

    É um mapa de variáveis de ambiente transmitidas para o contêiner no formato KEY:VAL.

A operação de verificação é executada no próprio ambiente de execução. Esse ambiente de execução pode ser configurado para VERIFY da mesma forma que para RENDER e DEPLOY.

Executar a verificação no cluster de aplicativos

Por padrão, a verificação de implantação é executada no ambiente de execução do Cloud Deploy. Também é possível configurar o Skaffold para executar a verificação no mesmo cluster em que o aplicativo está sendo executado.

Para executar os contêineres de verificação no cluster, configure-os na seção verify do skaffold.yaml. Para cada contêiner definido, você também precisa definir executionMode.kubernetesCluster.

verify:
- name:
  container:
    name:
    image:
    command:
    args:
  executionMode:
    kubernetesCluster:

Confira a seguir um exemplo de cláusula de verificação que inclui executionMode para invocar o contêiner de verificação no cluster de aplicativos:

verify:
- name: integration-test-container
  container:
    name: integration-test-container
    image: integration-test-container
  executionMode:
    kubernetesCluster: {}

Além disso, defina a estrofe verify como true na configuração do pipeline de entrega.

Confira a seguir um exemplo de definição de pipeline de entrega em que o destino dev tem a verificação ativada.

apiVersion: deploy.cloud.google.com/v1
kind: DeliveryPipeline
metadata:
 name: my-demo-app
description: main application pipeline
serialPipeline:
 stages:
 - targetId: dev
   profiles: []
   strategy:
     standard:
       verify: true

Essa capacidade está disponível apenas para implantações no GKE, não no Cloud Run. As implantações no Cloud Run só podem executar a verificação no ambiente de execução do Cloud Deploy.

Para implantações paralelas, a verificação é configurada no multi-destino, e os contêineres de verificação são executados em cada destino filho.

Você também pode incluir as propriedades jobManifestPath e overrides, em kubernetesCluster, para apontar para um manifesto do seu contêiner de verificação e quaisquer valores que você queira substituir. (overrides usa JSON inline do Kubernetes com os valores que você quer substituir.) Saiba mais.

A estrofe executionMode é opcional. Se você omitir, o Skaffold vai executar os contêineres de verificação no ambiente de execução do Cloud Deploy.

Tentar a verificação novamente

Quando um job de verificação falha, é possível tentar de novo a verificação, criando uma nova execução de job:

gcloud deploy rollouts retry-job ROLLOUT_NAME \
             --job-id=JOB_ID \
             --phase-id=PHASE_ID \
             --delivery-pipeline=PIPELINE_NAME \
             --release=RELEASE_NAME \
             --region=REGION

Ao tentar novamente, o estado do lançamento muda de FAILED para IN_PROGRESS.

Só é possível repetir uma verificação para um lançamento cujo job de verificação falhou.

Variáveis de ambiente disponíveis

O Cloud Deploy também fornece e preenche as seguintes variáveis de ambiente no ambiente de execução. É possível usar essas variáveis de ambiente como parte do hook de implantação, do job de verificação, ou da renderização ou implantação de destino personalizado.

  • ANTHOS_MEMBERSHIP

    Para destinos do tipo ANTHOS, o nome do recurso totalmente especificado da associação do Anthos.

  • CLOUD_RUN_LOCATION

    Para destinos do tipo RUN, a região em que o serviço do Cloud Run é implantado.

  • CLOUD_RUN_PROJECT

    Para destinos do tipo RUN, o projeto em que o serviço do Cloud Run foi criado.

  • CLOUD_RUN_SERVICE

    Para destinos do tipo RUN, o nome do serviço do Cloud Run implantado.

  • CLOUD_RUN_SERVICE_URLS

    Para destinos do tipo RUN, o URL ou URLs (lista separada por vírgulas) que os usuários finais vão usar para acessar seu serviço. Você pode encontrar essas informações nos detalhes do serviço do Cloud Run no consoleGoogle Cloud . Os URLs são gerados pelo Cloud Run depois que o serviço ou os serviços do Cloud Run são implantados com sucesso. Portanto, essa variável de ambiente só está disponível em hooks postdeploy e jobs de verificação.

  • CLOUD_RUN_REVISION

    Para destinos do tipo RUN, a revisão específica do serviço do Cloud Run.

  • GKE_CLUSTER

    Para destinos do tipo GKE, o nome totalmente especificado do recurso do cluster do Google Kubernetes Engine, por exemplo, projects/p/locations/us-central1/clusters/dev.

  • TARGET_TYPE

    O tipo de tempo de execução específico do destino. GKE, ANTHOS ou RUN. Para metas personalizadas, esse campo não é definido.

  • CLOUD_DEPLOY_LOCATION

    A região que contém os recursos do Cloud Deploy.

  • CLOUD_DEPLOY_DELIVERY_PIPELINE

    O ID do pipeline de entrega.

  • CLOUD_DEPLOY_TARGET

    O ID da meta.

  • CLOUD_DEPLOY_PROJECT

    O número do projeto Google Cloud que contém os recursos do Cloud Deploy.

  • CLOUD_DEPLOY_PROJECT_ID

    O ID do projeto Google Cloud .

  • CLOUD_DEPLOY_RELEASE

    O ID da versão em que os hooks serão executados.

  • CLOUD_DEPLOY_ROLLOUT

    O ID do lançamento que contém os jobs para os hooks.

  • CLOUD_DEPLOY_JOB_RUN

    O ID da execução do job que representa a execução atual do job.

  • CLOUD_DEPLOY_PHASE

    A fase no lançamento que contém o job para o hook de implantação, o job de verificação ou a renderização ou implantação personalizada.

A seguir