Executar ganchos antes e depois da implantação

Este documento descreve como executar programas ou operações arbitrárias antes e/ou após a implantação.

É possível configurar o Cloud Deploy e o Skaffold para executar ações para realizar ações de pré-implantação ou ações pós-implantação ou ambas. Esses programas, executados dessa forma, são chamados "ganchos". 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 do Cloud Deploy especificado, mas, se você estiver implantando no Google Kubernetes Engine, poderá configurar o hook para ser executado no cluster do GKE em que você está implantando o aplicativo.

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

Como os hooks de implantação funcionam?

Veja a seguir as etapas para configurar hooks de implantação e as Processo do Skaffold e do Cloud Deploy para executar esses hooks:

  1. Você configura o skaffold.yaml usado para uma determinada versão para incluir customActions que identificam a imagem ou as imagens do contêiner a serem usadas para executar os hooks e o comando ou script específico a ser executado em cada contêiner.

  2. Você configura os hooks em um ou mais estágios da progressão do pipeline de envio, cada um deles faz referência a um dos customActions configurados em skaffold.yaml.

  3. Antes da execução do job de implantação do lançamento, o Skaffold executa todos os comandos configurados em skaffold.yaml, que são referenciadas em uma estrofe predeploy no pipeline. progressão.

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

  4. Depois que o job de implantação do lançamento for executado, o Cloud Deploy vai executar comandos configurados em skaffold.yaml que são referenciados em um postdeploy. estrofe na progressão do pipeline.

Os hooks de implantação são executados na execução padrão do Cloud Deploy ou em um ambiente de execução alternativo especificado. Para implantações ao GKE e ao GKE Enterprise, é possível executar os ganchos no mesmo cluster onde o aplicativo está sendo implantado.

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

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

  • No estágio do 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 canário automatizado, os hooks predeploy são executados antes da implantação em somente na primeira fase, e os hooks postdeploy são executados após a implantação apenas a última fase (estável).

Configurar ações no Skaffold

No arquivo skaffold.yaml, a estrofe customActions usa uma ou mais estrofes customActions, configuradas da seguinte maneira:

customActions
- name: ACTION_NAME
  containers:
  - name: CONTAINER_NAME
    image: IMAGE
    command: [COMMANDS_TO_RUN]
    args: [LIST_OF_ARGS]

Nesta estrofe de customerActions:

  • ACTION_NAME

    É um nome para essa ação. Esse nome pode ser o que você quiser, mas deve ser exclusivo nesse skaffold.yaml. Esse é o nome que será referenciado das ações pré e pós-implantação definido na etapa do pipeline de entrega.

  • CONTAINER_NAME

    É um nome para o contêiner específico. Esse nome pode ser qualquer coisa, mas precisa ser exclusivo neste skaffold.yaml.

  • IMAGE

    É o nome da imagem do contêiner em que seu comando será executado.

  • COMMANDS_TO_RUN

    É uma lista de pontos de entrada a serem executados nesse contêiner. "/bin/sh" é um comando típico para especificar aqui, para invocar um shell. Inclua o comando a ser executado nesse shell nos argumentos.

  • LIST_OF_ARGS

    É uma lista de argumentos para fornecer ao comando. Essa é uma lista separada por vírgulas, com cada argumento entre aspas. Se o COMMAND_TO_RUN for "/bin/sh", um dos argumentos aqui seria "-c" e outro seria todo o comando que você quer executar no shell invocando.

    Veja um exemplo:

    command: ["/bin/sh"]
args: ["-c", `echo "This command ran!"`]

Para saber mais sobre as ações personalizadas do Skaffold, consulte a documentação do Skaffold.

Configurar o pipeline para referenciar as ações

Para configurar os hooks de implantação, configure o pipeline de entrega para referenciar as ações personalizadas definidas no arquivo skaffold.yaml. As ações pré e pós-implantação são configuradas em uma ou etapas mais específicas no pipeline progressão.

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

serialPipeline:
  stages:
  - targetId: hooks-staging
    profiles: []
    strategy:
      standard:
        predeploy:
          actions: ["PREDEPLOY-ACTION"]
        postdeploy:
          actions: ["POSTDEPLOY-ACTION"]

Neste yaml:

  • PREDEPLOY_ACTION

    É o mesmo que o ACTION_NAME usado no skaffold.yaml para definir a ação personalizada que você quer executar antes da implantação.

  • POSTDEPLOY_ACTION

    É o mesmo que o ACTION_NAME usado no skaffold.yaml para definir a ação personalizada que você quer executar após a implantação.

É possível especificar mais de uma ação para predeploy e postdeploy, separadas por vírgulas. Quando mais de uma ação é especificada, 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 ação que falha, e as demais ações não são executadas.

Por padrão, se você estiver executando mais de um contêiner em paralelo e um job falhar, ambos os contêineres serão interrompidos. É possível configurar esse comportamento usando a estratégia de falha de ação personalizada do Skaffold.

Executar os hooks no cluster de aplicativos

Por padrão, os hooks de implantação são executados no ambiente de execução. Também é possível configurar o Skaffold para executar essas ações personalizadas no mesmo cluster em que o aplicativo está sendo executado. Quando você configura ações personalizadas em skaffold.yaml e as ativa em um estágio do pipeline, a ação é executada automaticamente no cluster do destino.

Esse recurso está disponível para implantações no GKE e Apenas no GKE Enterprise, não para o Cloud Run. Implantações para O Cloud Run só pode executar hooks no bucket ou ambiente de execução.

Para executar o hook no cluster, inclua uma estrofe executionMode.kubernetesCluster no arquivo de configuração skaffold.yaml, dentro da estrofe customActions para a ação personalizada específica:

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 gancho 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 e, se você omiti-la, o Skaffold executa a contêiner de ações personalizadas no ambiente de execução do Cloud Deploy.

Variáveis de ambiente disponíveis

O Cloud Deploy fornece e preenche o seguinte ambiente variáveis no ambiente de execução que você pode usar para os ganchos:

  • 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, 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. No caso de segmentações personalizadas, 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 projeto do Google Cloud que contém os recursos do Cloud Deploy.

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

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

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.

A seguir