verifique sua implantação

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

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

Por padrão, a verificação de implantação é executada no ambiente de execução do Cloud Deploy, mas também é possível configurá-la para execução no mesmo cluster em que o aplicativo está sendo executado.

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

  1. Você configura o Skaffold para verificação.

    Essa configuração identifica as imagens do contêiner a serem usadas para executar testes e os comandos específicos (script, por exemplo) a serem executados a partir deles imagem do contêiner.

  2. Você configura uma ou mais segmentações na sua entrega pipeline para verificação da implantação.

    Essa configuração ativa a verificação das cargas de trabalho implantadas nessa ferramenta alvo.

  3. Depois que um lançamento é implantado (skaffold apply), o Cloud Deploy executa o comando skaffold verify no ambiente de execução do Cloud Deploy.

    Para implantações no Google Kubernetes Engine e no GKE Enterprise, é possível executar o contêiner de verificação no mesmo cluster em que o contêiner do aplicativo está em execução.

  4. O Skaffold invoca os testes especificados na estrofe verify do seu skaffold.yaml para ser executado no aplicativo implantado.

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

    • A conclusão da verificação é determinada pelo código de saída do contêiner executado.

      0 indica sucesso. Um código de saída diferente de zero indica falha. Para gerar o resultado da verificação desejado, confirme se o contêiner sai com o código de saída adequado. Se mais de um contêiner for executado como parte da verificação, todos eles precisam ter sucesso para que a verificação seja bem-sucedida.

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

    • Se uma implantação falhar durante a verificação, você poderá conferir isso inspecionando o lançamento:

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

  6. Você pode ignorar ou tente novamente verificar se houve falha.

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

Componentes usados para verificação

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

  • Fase

    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

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

Para saber mais sobre os recursos do Cloud Deploy, consulte Cloud Deploy arquitetura de serviços

Notificações geradas pela verificação de implantação

O Cloud Deploy gera e publica mensagens do Pub/Sub para os seguintes eventos:

  • Criar, atualizar e excluir execução de jobs

    Essas notificações são publicadas no tópico clouddeploy-resources. contêm os seguintes atributos:

    • Resource
    • ResourceType (JobRun)
    • Action (Create, Update e Delete)
    • ProjectNumber
    • Location
    • TargetId
    • DeliveryPipelineId
    • ReleaseId
    • RolloutId
    • JobRunId

Veja a seguir um exemplo de mensagem do Pub/Sub para uma execução de job criar, publicada no tópico clouddeploy-resources:

{
    "ackId": "UAYWLF1GSFE3GQhoUQ5PXiM_NSAoRRAGAE8CKF15MFcrQVh9Dz4NGXJ9YXRiWRIJBkUHeF9cEQ1iXE5EB0nq0KDVV1dKXxYGAExQeVhbHQVoWVh0Bnn7h5nK-8HjYwk9OqKarPdtO4PY2fNHZiI9XhJLLD5-My5FQV5AEkw4G0RJUytDCypYEU4EISE-MD5FU0Q",
    "message": {
      "attributes": {
        "Action": "Create",
        "DeliveryPipelineId": "dv-pipeline",
        "JobRunId": "634f8c6f-30c3-49ca-af80-68dc24d4cc5d",
        "Location": "us-central1",
        "ProjectNumber": "253401481285",
        "ReleaseId": "test-release-100",
        "Resource": "projects/253401481285/locations/us-central1/deliveryPipelines/dv-pipeline/releases/test-release-100/rollouts/test-release-100-to-dev-0001/jobRuns/634f8c6f-30c3-49ca-af80-68dc24d4cc5d",
        "ResourceType": "JobRun",
        "RolloutId": "test-release-100-to-dev-0001"
      },
      "messageId": "5572937706805411",
      "publishTime": "2022-09-07T14:00:46.040Z"
    }
  },

  • A execução do job é iniciada, bem-sucedida e com falha

    Essas notificações são publicadas no tópico clouddeploy-operations e contêm os seguintes atributos:

    • Resource
    • ResourceType (JobRun)
    • Action (Start, Succeed e Failure)
    • ProjectNumber
    • Location
    • TargetId
    • DeliveryPipelineId
    • ReleaseId
    • RolloutId
    • JobRunId
    • PhaseId
    • JobId
    • JobType (Deploy ou Verify)

Veja a seguir um exemplo de mensagem do Pub/Sub para um job com falha executado, publicado no tópico clouddeploy-operations:

{
    "ackId": "RFAGFixdRkhRNxkIaFEOT14jPzUgKEUUBAgUBXx9cEFPdVhec2hRDRlyfWB9aVsbCAUXU3cJURsHaE5tdR-6xcvaS0NVb18UAgRFWndfXhMEblhfcy-fkK3HwvT9U0AvOemNgdZpe6jHiulvZiM9XxJLLD5-My5FQV5AEkw4G0RJUytDCypYEU4EISE-MD5FUw",
    "message": {
      "attributes": {
        "Action": "Failure",
        "DeliveryPipelineId": "dv-pipeline",
        "JobId": "verify",
        "JobRunId": "b389224a-c259-4a00-ab75-c22e48bc3136",
        "JobType": "Verify",
        "Location": "us-central1",
        "PhaseId": "stable",
        "ProjectNumber": "253401481285",
        "ReleaseId": "test-release-101",
        "Resource": "projects/253401481285/locations/us-central1/deliveryPipelines/dv-pipeline/releases/test-release-101/rollouts/test-release-101-to-dev-0001/jobRuns/b389224a-c259-4a00-ab75-c22e48bc3136",
        "ResourceType": "JobRun",
        "RolloutId": "test-release-101-to-dev-0001",
        "TargetId": "dev"
      },
      "messageId": "5573609905896436",
      "publishTime": "2022-09-07T15:35:37.906Z"
    }
  },

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

A ativação da verificação de implantação para um destino do Cloud Deploy consiste de adicionar uma propriedade do verify: true para um determinado destino (ou destinos) em uma progressão do pipeline de entrega, como mostrado no 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: true
 - targetId: prod
   profiles: []
   strategy:
     standard:
       verify: false

Nesta configuração, a verificação de implantação é ativada no destino dev, mas não no destino prod. verify: false é equivalente a omitir a propriedade verify ou toda a estrofe strategy.

A operação de verificação é realizada 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.

Configurar o Skaffold para a verificação de implantação

Ativar a verificação de implantação para um destino requer uma estrofe verify no arquivo de configuração skaffold.yaml da implantação. Essa configuração pode ser para um perfil específico do Skaffold, se você estiver usando perfis separados por destino.

A estrofe de verify identifica um contêiner a ser executado para fazer a verificação. como um teste de integração.

Veja a seguir um exemplo de skaffold.yaml que inclui uma estrofe verify:

apiVersion: skaffold/v4beta7
kind: Config
build:
  artifacts:
    - image: integration-test
      context: integration-test
manifests:
  rawYaml:
  - kubernetes.yaml
deploy:
  kubectl: {}
verify:
- name: verify-integration-test
  container:
    name: integration-test
    image: integration-test
    command: ["./test-systems.sh"]
- name: verify-endpoint-test
  container:
    name: alpine
    image: alpine
    command: ["/bin/sh"]
    args: ["-c", "wget #ENDPOINT_URL"]

Este exemplo simples mostra uma sala verify identificando um contêiner para usar e um script de teste para executar nesse contêiner. O #ENDPOINT_URL neste exemplo é apenas um marcador de posição para o URL dos seus aplicativos e não é uma variável de ambiente disponível do Cloud Deploy.

Executar o contêiner de verificação no cluster de aplicativos

Por padrão, a verificação de implantação é executada no ambiente de execução do Cloud Deploy. Você também pode configure o Skaffold para executar o contêiner de verificação no mesmo cluster em que o aplicativo está em execução. Quando você configura a verificação no cluster em skaffold.yaml e ativa a verificação em um destino, a verificação é executada automaticamente no cluster desse destino.

Essa capacidade está disponível apenas para implantações no GKE e no GKE Enterprise, 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.

A verificação no cluster exige Skaffold versão 2.3 ou mais recente.

Para executar o contêiner de verificação no cluster, inclua um estrofe de executionMode.kubernetesCluster na configuração de skaffold.yaml , dentro da estrofe verify do contêiner de verificação específico:

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

Este é um exemplo de estrofe de verificação que inclui executionMode para invoque o contêiner de verificação no cluster do aplicativo:

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

A estrofe executionMode é opcional e, se você omiti-la, o Skaffold executa a contêiner de verificação no ambiente de execução do Cloud Deploy.

Tentar novamente a verificação

Quando um job de verificação falha, você pode repetir 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

Tentar a verificação novamente muda o estado do lançamento de FAILED para IN_PROGRESS.

Só é possível repetir a verificação para um lançamento com falha no job de verificação.

Variáveis de ambiente disponíveis

O Cloud Deploy fornece e preenche as seguintes variáveis de ambiente no ambiente de execução VERIFY, que podem ser usadas nos testes:

  • ANTHOS_MEMBERSHIP

    Para destinos do tipo ANTHOS, o nome de recurso totalmente especificado do Anthos assinatura.

  • CLOUD_RUN_LOCATION

    Para destinos do tipo RUN, a região a que o serviço Cloud Run está implantados.

  • CLOUD_RUN_PROJECT

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

  • CLOUD_RUN_SERVICE

    Para destinos do tipo RUN, o nome totalmente especificado do recurso implantado Serviço do Cloud Run, por exemplo, projects/p/locations/us-central1/services/dev.

  • CLOUD_RUN_SERVICE_URLS

    Para destinos do tipo RUN, os URLs (lista separada por vírgulas) que terminam que os usuários usarão para acessar seu serviço. Eles estão disponíveis nos detalhes do serviço do Cloud Run no console do Google Cloud.

  • CLOUD_RUN_REVISION

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

  • GKE_CLUSTER

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

  • TARGET_TYPE

    O tipo de ambiente de execução específico do destino. GKE, ANTHOS ou RUN.

  • CLOUD_DEPLOY_LOCATION

    A região em que o ambiente de execução está em execução.

  • CLOUD_DEPLOY_DELIVERY_PIPELINE

    O pipeline de entrega de IDs em que o ambiente de execução está executando.

  • CLOUD_DEPLOY_TARGET

    O ID do destino em que o ambiente de execução está sendo executado.

  • CLOUD_DEPLOY_PROJECT

    O número do projeto do Google Cloud em que o ambiente de execução está sendo executado.

  • CLOUD_DEPLOY_RELEASE

    O ID da versão em que a verificação será executada.

  • CLOUD_DEPLOY_ROLLOUT

    O ID do lançamento que contém os jobs a serem verificados.

  • CLOUD_DEPLOY_JOB_RUN

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

  • CLOUD_DEPLOY_PHASE

    A fase no lançamento que contém o job a ser verificado.

Implantar parâmetros como variáveis de ambiente

Além das variáveis de ambiente listadas nesta seção, o Cloud Deploy pode transmitir aos contêineres personalizados todos os parâmetros de implantação definidos.

Saiba mais.