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 pré e pós-implantação jobs no o lançamento.

É possível configurar cada hook para ser executado em um Cloud Deploy especificado ambiente de execução, mas se você implantado no Google Kubernetes Engine, é possível configurá-lo para execução no Cluster do GKE em que você está implantando o aplicativo.

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

Como funcionam os hooks de implantação?

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 em determinada versão para incluir customActions que identificam a imagem ou as imagens do contêiner a serem usadas para executar o hooks e o comando ou script específico a ser executado em cada contêiner.

  2. Você configura hooks em um ou mais estágios no pipeline de entrega progressão, cada uma fazendo 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 é executado, o Cloud Deploy executa 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

Quando você configura hooks de implantação para uma implantação canário, há várias algumas coisas que você precisa saber:

  • Na etapa do pipeline de entrega, a configuração do gancho (predeploy e postdeploy) está abaixo de strategy.canary.canaryDeployment ou strategy.canary.customCanaryDeployment.phaseConfigs, em vez de menos 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 toma uma ou mais customActions estrofes, configuradas da seguinte forma:

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 esta 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 o que você quiser, mas precisa ser exclusivo nesse 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 preço normal a ser especificado aqui, invocar um shell, e você incluiria o comando no shell do args.

  • LIST_OF_ARGS

    É uma lista de argumentos para fornecer ao comando. É um intervalo 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 fazer referência às ações

Para concluir a configuração dos hooks de implantação, faça o seguinte: configure o pipeline de entrega para fazer referência às 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.

Veja a seguir como configurar hooks de pré e pós-implantação em um 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 que você usou no seu skaffold.yaml para definir a ação personalizada que você quer executar antes da implantação.

  • POSTDEPLOY_ACTION

    É o mesmo que o ACTION_NAME que você usou no seu 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 foram especificadas. O job (pré-implantação ou pós-implantação) falha no primeiro que falhe, e as demais não serão executadas.

Por padrão, se você estiver executando mais de um contêiner em paralelo e um job falhar, os dois contêineres serão interrompidos. Você pode configurar esse comportamento usando o Estratégia de falha na ação personalizada do Skaffold.

Executar os ganchos no cluster do aplicativo

Por padrão, os hooks de implantação são executados no ambiente de execução. Você também pode configure o Skaffold para executar essas ações personalizadas no mesmo cluster em que aplicativo está em execução. Quando você configurar ações personalizadas no skaffold.yaml e ativá-los em um estágio do pipeline, a ação será 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 um executionMode.kubernetesCluster estrofe no seu arquivo de configuração skaffold.yaml, dentro da customActions estrofe da 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: {}

Este é um exemplo de estrofe de customActions que inclui executionMode para invocar o contêiner de ganchos no cluster do aplicativo:

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 de recurso totalmente especificado do Anthos assinatura.

  • CLOUD_RUN_LOCATION

    Para destinos do tipo RUN, a região a que o serviço Cloud Run está implantados.

  • CLOUD_RUN_PROJECT

    Para destinos do tipo RUN, o projeto em que o Cloud Run serviço foi criado.

  • CLOUD_RUN_SERVICE

    O nome do serviço do Cloud Run para destinos do tipo RUN. implantados.

  • 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. Você pode encontrá-los na Detalhes do serviço do Cloud Run para seu serviço, no console do Google Cloud.

  • CLOUD_RUN_REVISION

    Para destinos do tipo RUN, a revisão específica do Cloud Run serviço.

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

  • CLOUD_DEPLOY_PHASE

    A fase do lançamento que contém o job para os ganchos.

Implantar parâmetros como variáveis de ambiente

Além das variáveis de ambiente listadas nesta seção, O Cloud Deploy pode transmitir para seus contêineres personalizados Implantar parâmetros que você definiu.

Saiba mais.

A seguir