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