Definir uma análise personalizada

O Cloud Deploy oferece suporte a jobs de análise que usam alertas gerados pelo Google Cloud Observability com base em métricas e outros dados também do Google Cloud Observability. No entanto, também é possível estender o Cloud Deploy para usar outros provedores de métricas. Este documento descreve como configurar e usar um job de análise e os requisitos para um contêiner personalizado que inclui a lógica para analisar métricas do provedor de sua escolha.

Antes de começar

  1. Faça login na sua Conta do Google.

    Se você ainda não tiver uma, inscreva-se agora.

  2. Instale a Google Cloud CLI.

  3. Ao usar um provedor de identidade (IdP) externo, primeiro faça login na CLI gcloud com sua identidade federada.

  4. Para inicializar a CLI gcloud, execute o seguinte comando:

    gcloud init
  5. Verifique se você tem as permissões necessárias para concluir este guia.

  6. Verifique se o faturamento está ativado para o Google Cloud projeto.

  7. Ative as APIs Compute Engine e Cloud Deploy:

    Funções necessárias para ativar APIs

    Para ativar as APIs, é necessário ter a permissão serviceusage.services.enable. Se você criou o projeto, provavelmente já tem essa permissão pela função Proprietário (roles/owner). Caso contrário, você pode receber essa permissão pela função Administrador de uso do serviço (roles/serviceusage.serviceUsageAdmin). Saiba como conceder funções.

    gcloud services enable clouddeploy.googleapis.com  compute.googleapis.com
  8. Instale a Google Cloud CLI.

  9. Ao usar um provedor de identidade (IdP) externo, primeiro faça login na CLI gcloud com sua identidade federada.

  10. Para inicializar a CLI gcloud, execute o seguinte comando:

    gcloud init
  11. Verifique se você tem as permissões necessárias para concluir este guia.

  12. Verifique se o faturamento está ativado para o Google Cloud projeto.

  13. Ative as APIs Compute Engine e Cloud Deploy:

    Funções necessárias para ativar APIs

    Para ativar as APIs, é necessário ter a permissão serviceusage.services.enable. Se você criou o projeto, provavelmente já tem essa permissão pela função Proprietário (roles/owner). Caso contrário, você pode receber essa permissão pela função Administrador de uso do serviço (roles/serviceusage.serviceUsageAdmin). Saiba como conceder funções.

    gcloud services enable clouddeploy.googleapis.com  compute.googleapis.com

Funções exigidas

Para receber as permissões necessárias para criar e usar jobs de análise, peça ao administrador para conceder a você as seguintes funções do IAM na conta do seu projeto:

Para mais informações sobre a concessão de papéis, consulte Gerenciar o acesso a projetos, pastas e organizações.

Também é possível conseguir as permissões necessárias com papéis personalizados ou outros papéis predefinidos.

Para garantir que a conta de serviço do Cloud Deploy tenha as permissões necessárias para criar e usar jobs de análise, peça ao administrador para conceder as seguintes funções do IAM à conta de serviço do Cloud Deploy no seu projeto:

Para mais informações sobre a concessão de papéis, consulte Gerenciar o acesso a projetos, pastas e organizações.

O administrador também pode conceder à conta de serviço do Cloud Deploy as permissões necessárias por meio de papéis personalizados ou de outros papéis predefinidos.

Configurar um job de análise personalizado

Um job de análise personalizado é igual a um job de análise que usa alertas do Google Cloud Observability, mas o job personalizado usa uma ou mais tarefas que referenciam contêineres personalizados e os comandos a serem executados nesses contêineres para processar dados do provedor de métricas.

Esta seção descreve como configurar um job de análise do Cloud Deploy que usa um provedor não deGoogle Cloud monitoramento.

A seção analysis pode ser usada diretamente em uma configuração de estratégia de implantação (strategy.standard.analysis, para uma estratégia padrão). Se você quiser configurar a análise por fase, use um canário personalizado (strategy.canary.customCanaryDepolyment.phaseConfigs.phaseId.analysis).

strategy:
  standard:
    analysis:
      duration: DURATION
      customChecks:
      - id: CHECK_ID
        frequency: FREQUENCY
        task:
          type: container
          image: IMAGE_NAME
          command: COMMAND
          args: [ARGS]
          env:
            [VAR_NAME: VALUE]

Em que:

  • DURATION

    É o tempo, em segundos, para executar o job de análise. Depois que a duração expira, o job é concluído. Se a análise falhar (o contêiner retorna um código de saída diferente de zero), o job será concluído (FAILED) antes que a duração expire.

  • CHECK_ID

    É um ID para a verificação individual. Esse ID precisa ser exclusivo nesse job de análise.

  • FREQUENCY

    É a frequência, em segundos, para executar a verificação individual.

  • IMAGE_NAME

    É o caminho e o nome que identificam a imagem do contêiner.

  • COMMAND

    É o comando a ser executado nesse contêiner, por exemplo, um script de shell (/bin/bash).

  • ARGS

    É uma lista de argumentos para esse comando. Essa é uma lista separada por vírgulas. Se o COMMAND_TO_RUN for "/bin/sh", um dos argumentos aqui será -c, e outro argumento será o comando inteiro que você quer executar no shell que está invocando.

  • VAR_NAME

    É o nome de uma variável de ambiente a ser transmitida ao contêiner. Você usa variáveis de ambiente para configurar o comportamento do contêiner. Ou seja, as variáveis e os valores delas informam ao contêiner o que monitorar especificamente no provedor de métricas.

    É possível usar parâmetros do sistema como variáveis de ambiente aqui.

  • VALUE

    É o valor de cada variável de ambiente. O Cloud Deploy não faz nada com essas variáveis de ambiente, exceto transmiti-las, com os valores delas, ao contêiner. Cabe ao contêiner usar os valores na lógica de análise.

Cada verificação em uma definição de análise personalizada inclui uma tarefa que referencia um contêiner, o comando ou comandos a serem executados nesse contêiner e todas as variáveis de ambiente aplicáveis a serem transmitidas a esse contêiner.

O contêiner personalizado

Para a análise personalizada, o contêiner fornecido é responsável por analisar a telemetria, os registros ou outros dados do provedor de métricas que você usa. O job de análise do Cloud Deploy aguarda o código de retorno do contêiner.

O que o contêiner personalizado precisa fazer

O contêiner personalizado é responsável por ingerir dados do provedor de métricas, determinar se as métricas, os registros ou outros dados indicam um aplicativo funcionando corretamente e retornar os resultados ao Cloud Deploy.

O que o contêiner personalizado precisa retornar

O Cloud Deploy não exige nada do contêiner personalizado, exceto que ele retorne um código de saída zero ou diferente de zero. Se o contêiner retornar um código de saída diferente de zero, a análise falhará.

O contêiner pode gravar resultados em um arquivo chamado results.json (em formato JSON), localizado no bucket do Cloud Storage fornecido pelo Cloud Deploy. O arquivo vai conter os metadados, na forma de pares de chave-valor. Isso não é obrigatório.

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 seu hook de implantação, verificar job, ou destino personalizado renderizar ou implantar.

  • 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 está 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. É possível encontrar esses detalhes do serviço do Cloud Run no Google Cloud console. Os URLs são gerados pelo Cloud Run depois que o serviço ou serviços do Cloud Run são implantados. Portanto, essa variável de ambiente só está disponível em hooks de pós-implantação 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 do 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. Para destinos personalizados, isso não será 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 do destino.

  • CLOUD_DEPLOY_PROJECT

    O Google Cloud número do projeto 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 dos 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, verificar o job ou renderização ou implantação personalizada.

A seguir