Executar hooks antes e depois da implantação

Neste documento, descrevemos como executar programas ou operações arbitrárias antes ou depois da implantação.

É possível configurar o Cloud Deploy para executar ações de pré-implantação ou pós-implantação, ou ambas. Esses programas, executados dessa forma, são chamados de "hooks". Os hooks de pré e pós-implantação são executados como jobs de pré e pós-implantação no lançamento.

É possível configurar cada hook para ser executado em um ambiente de execução especificado do Cloud Deploy, mas, se você estiver implantando no Google Kubernetes Engine, poderá configurar opcionalmente para execução no cluster do GKE em que o aplicativo está sendo implantado.

Os hooks de implantação são considerados idempotentes. Se uma determinada ação for executada mais de uma vez, não haverá efeito adicional.

Como os hooks de implantação funcionam?

A seguir, descrevemos como os hooks de implantação são executados no Cloud Deploy e como configurá-los:

  1. Você configura hooks em uma ou mais etapas na progressão do pipeline de entrega.

  2. Antes da execução do job de implantação do lançamento, o Cloud Deploy executa todas as tarefas configuradas em uma definição de predeploy na progressão do pipeline.

    O hook predeploy sempre é executado como o primeiro job na fase.

  3. Depois que o job de implantação do lançamento for executado, o Cloud Deploy vai executar todas as tarefas configuradas em uma definição postdeploy na progressão do pipeline.

Os hooks de implantação são executados no ambiente de execução do Cloud Deploy.

Como usar hooks de implantação com uma implantação canário

Ao configurar hooks de implantação para uma implantação canário, há várias coisas a saber:

  • Na etapa de pipeline de entrega, a configuração do hook (predeploy e postdeploy) está em strategy.canary.canaryDeployment ou strategy.canary.customCanaryDeployment.phaseConfigs, em vez de strategy.standard.

  • Para um canary automatizado, os hooks predeploy são executados antes da implantação apenas na primeira fase, e os hooks postdeploy são executados após a implantação apenas na última fase (estável).

Configurar o pipeline para executar hooks

Você configura hooks de pré e pós-implantação em uma ou mais etapas específicas na progressão do pipeline.

Veja como configurar hooks pré e pós-implantação em um estágio de pipeline ao usar uma estratégia de implantação standard:

serialPipeline:
  stages:
  - targetId: hooks-staging
    profiles: []
    strategy:
      standard:
        predeploy:
          tasks: [TASKS]
        postdeploy:
          tasks: [TASKS]

Neste YAML:

  • TASKS

    É uma lista de uma ou mais tarefas que você quer executar como parte dos hooks de pré-implantação ou pós-implantação. Quando você especifica mais de uma tarefa, elas são executadas em série, na ordem em que são especificadas. O job (pré-implantação ou pós-implantação) falha na primeira tarefa que falha, e as tarefas restantes não são executadas.

Executar os hooks no cluster de aplicativos

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

Para executar hooks no cluster de aplicativos, configure-os como customActions no skaffold.yaml e faça referência a eles usando actions na estrofe predeploy ou postdeploy na configuração da etapa do pipeline de entrega:

serialPipeline:
  stages:
  - targetId: hooks-staging
    profiles: []
    strategy:
      standard:
        predeploy:
          actions: ["my-predeploy-action"]
        postdeploy:
          actions: ["my-postdeploy-action"]

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 hooks no ambiente de execução do Cloud Deploy.

Para configurar o hook para ser executado no cluster, inclua uma stanza executionMode.kubernetesCluster no arquivo de configuração skaffold.yaml, dentro da stanza customActions para cada ação que você quer executar no cluster:

customActions:
- name: ACTION_NAME
  containers:
  - name: CONTAINER_NAME
    image: IMAGE
    command: [COMMANDS_TO_RUN]
    args: [LIST_OF_ARGS]
  executionMode:
    kubernetesCluster: {}

Confira a seguir um exemplo de estrofe customActions que inclui executionMode para invocar o contêiner de hook no cluster de aplicativos:

customActions:
- name: predeploy-action
  containers:
  - name: predeploy-echo
    image: ubuntu
    command: ["/bin/sh"]
    args: ["-c", 'echo "this is a predeploy action"' ]
  executionMode:
    kubernetesCluster: {}

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

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

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.

A seguir