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 conclusão da implantação.

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 ser executada no mesmo cluster em que o aplicativo está sendo executado.

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

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

    Essa configuração identifica a imagem (ou imagens) de contêiner a ser usada para executar testes e os comandos específicos (script, por exemplo) a serem executados dessa imagem de contêiner.

    É possível especificar mais de uma imagem de contêiner. Se você especificar vários contêineres, eles serão executados em paralelo, não em sequência.

  2. Você configura um ou mais destinos no pipeline de entrega para verificação da implantação.

    Essa configuração ativa a verificação de cargas de trabalho implantadas nesse destino.

  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 (ou contêineres) de verificação no mesmo cluster em que o contêiner de aplicativo está sendo executado.

  4. O Skaffold invoca o teste ou os testes especificados na estrofe verify do seu skaffold.yaml para executar no aplicativo implantado.

  5. 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 do contêiner executado.

      0 indica sucesso. Um código de saída diferente de zero indica falha. Para gerar o resultado de verificação pretendido, 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 eles 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

  6. 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

    O conjunto 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.

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

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

  • Criação, atualização e exclusão de execuções de jobs

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

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

Confira a seguir um exemplo de mensagem do Pub/Sub para uma criação de execução de job, 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"
    }
  },

  • Início, sucesso e falha da execução do job

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

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

Confira a seguir um exemplo de mensagem do Pub/Sub para uma execução de job com falha, publicada 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 verificação de implantação

Para ativar a verificação de implantação em um destino do Cloud Deploy, adicione uma propriedade verify: true 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: true
 - targetId: prod
   profiles: []
   strategy:
     standard:
       verify: false

Nessa configuração, a verificação de implantação está 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 é 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.

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

Para ativar a verificação de implantação em um destino, é necessário um trecho 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.

Essa seção verify identifica um ou mais contêineres a serem executados para fazer a verificação, por exemplo, testes de integração. Se você especificar vários contêineres, eles serão executados em paralelo, não em sequência.

Confira 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 mostra uma estância verify que identifica um contêiner para uso e um script de teste para execução nele. #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.

Execute o contêiner ou os contêineres 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. Também é possível configurar o Skaffold para executar o contêiner ou os contêineres de verificação no mesmo cluster em que o aplicativo está sendo executado. 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.

Para executar os contêineres de verificação no cluster, inclua uma cláusula executionMode.kubernetesCluster no arquivo de configuração skaffold.yaml dentro da cláusula verify para o contêiner de verificação específico:

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: {}

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, 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 fornece e preenche as seguintes variáveis de ambiente no VERIFY ambiente de execução, que podem ser usadas nos testes:

  • 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 completo do recurso do serviço implantado do Cloud Run, por exemplo, projects/p/locations/us-central1/services/dev.

  • 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 .

  • 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 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á sendo executado.

  • CLOUD_DEPLOY_DELIVERY_PIPELINE

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

  • 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 Google Cloud em que o ambiente de execução está sendo executado.

  • CLOUD_DEPLOY_PROJECT_ID

    O ID do projeto Google Cloud que contém os recursos do Cloud Deploy.

  • 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 para verificação.

  • 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 verificação.

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 seus contêineres personalizados todos os parâmetros de implantação definidos.

Saiba mais.