Executar hooks antes e depois da implementação

Este documento descreve como executar programas ou operações arbitrárias antes e/ou depois da implementação.

Pode configurar o Cloud Deploy e o Skaffold para executar ações para realizar ações de pré-implementação ou ações de pós-implementação, ou ambas. Estes programas, executados desta forma, são denominados "hooks". Os hooks de pré-implementação e pós-implementação são executados como tarefas de pré-implementação e pós-implementação na implementação.

Pode configurar cada gancho para ser executado num ambiente de execução do Cloud Deploy especificado, mas se estiver a implementar no Google Kubernetes Engine, pode configurá-lo opcionalmente para ser executado no cluster do GKE onde está a implementar a sua aplicação.

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

Como funcionam os hooks de implementação?

Seguem-se os passos para configurar hooks de implementação e o processo do Skaffold e do Cloud Deploy para executar esses hooks:

  1. Configura o skaffold.yaml usado para uma determinada versão de forma a incluir customActions que identificam a imagem ou as imagens do contentor a usar para executar os comandos, e o comando ou o script específico a executar em cada contentor.

  2. Configura os hooks numa ou mais fases da progressão do pipeline de entrega, cada uma das quais faz referência a um dos customActions que configurou em skaffold.yaml.

  3. Antes de o trabalho de implementação da implementação ser executado, o Skaffold executa todos os comandos configurados em skaffold.yaml que são referenciados numa secção predeploy na progressão do pipeline.

    O comando predeploy é sempre executado como a primeira tarefa na fase.

  4. Após a execução da tarefa de implementação da implementação, o Cloud Deploy executa quaisquer comandos configurados em skaffold.yaml que sejam referenciados numa secção postdeploy na progressão do pipeline.

Os hooks de implementação são executados no ambiente de execução do Cloud Deploy predefinido ou num ambiente de execução alternativo especificado. Para implementações no GKE e GKE Enterprise, pode, opcionalmente, executar os hooks no mesmo cluster onde a aplicação está a ser implementada.

Usar hooks de implementação com uma implementação de teste

Quando configura hooks de implementação para uma implementação canary, existem vários aspetos a ter em conta:

  • Na fase do pipeline de entrega, a configuração do gancho (predeploy e postdeploy) encontra-se em strategy.canary.canaryDeployment ou strategy.canary.customCanaryDeployment.phaseConfigs, em vez de em strategy.standard.

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

Configure ações no Skaffold

No ficheiro skaffold.yaml, a secção customActions usa uma ou mais secções customActions, configuradas da seguinte forma:

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

Nesta customerActions quadra:

  • ACTION_NAME

    É um nome para esta ação. Pode escolher qualquer nome, mas tem de ser exclusivo neste skaffold.yaml. Este é o nome que vai ser referenciado a partir das ações pré e pós-implementação definidas na fase do pipeline de fornecimento.

  • CONTAINER_NAME

    É um nome para o contentor específico. Este nome pode ser qualquer nome que pretenda, mas tem de ser exclusivo neste skaffold.yaml.

  • IMAGE

    É o nome da imagem de contentor na qual o seu comando vai ser executado.

  • COMMANDS_TO_RUN

    É uma lista de pontos de entrada a executar nesse contentor. "/bin/sh" é um comando típico a especificar aqui para invocar uma shell, e incluiria o comando a executar nessa shell nos argumentos.

  • LIST_OF_ARGS

    É uma lista de argumentos a fornecer ao comando. Esta é uma lista separada por vírgulas, com cada argumento entre aspas. Se o seu COMMAND_TO_RUN for "/bin/sh", um dos argumentos aqui seria "-c" e outro argumento seria o comando completo que quer executar no shell que está a invocar.

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

Configure a conduta para referenciar as ações

Para terminar a configuração dos hooks de implementação, configure o pipeline de entrega para referenciar as ações personalizadas que definiu no seu ficheiro skaffold.yaml. As ações de pré-implementação e pós-implementação são configuradas numa ou mais fases específicas na progressão do pipeline.

Veja como configurar hooks pré e pós-implementação num estágio do pipeline quando usar uma estratégia de implementação standard:

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

Neste YAML:

  • PREDEPLOY_ACTION

    É igual ao ACTION_NAME que usou no seu skaffold.yaml para definir a ação personalizada que quer executar antes da implementação.

  • POSTDEPLOY_ACTION

    É o mesmo que o ACTION_NAME que usou no seu skaffold.yaml para definir a ação personalizada que quer executar após a implementação.

Pode especificar mais do que uma ação para predeploy e postdeploy, separadas por vírgulas. Quando são especificadas mais do que uma ação, estas são executadas em série, na ordem em que são especificadas. A tarefa (pré-implementação ou pós-implementação) falha na primeira ação que falha e as restantes ações não são executadas.

Por predefinição, se estiver a executar mais do que um contentor em paralelo e uma tarefa falhar, ambos os contentores são parados. Pode configurar este comportamento através da estratégia de falha da ação personalizada do Skaffold.

Execute os hooks no cluster da aplicação

Por predefinição, os hooks de implementação são executados no ambiente de execução do Cloud Deploy. Também pode configurar o Skaffold para executar essas ações personalizadas no mesmo cluster onde a sua aplicação está a ser executada. Quando configura ações personalizadas no skaffold.yaml e as ativa numa fase do pipeline, a ação é executada automaticamente no cluster desse destino.

Esta capacidade está disponível apenas para implementações no GKE e no GKE Enterprise, e não para o Cloud Run. As implementações no Cloud Run só podem executar hooks no ambiente de execução do Cloud Deploy.

Para executar o seu comando no cluster, inclua uma secção executionMode.kubernetesCluster no ficheiro de configuração skaffold.yaml, dentro da secção 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: {}

Segue-se um exemplo de uma secção customActions que inclui executionMode para invocar o contentor de hooks no cluster da aplicação:

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

A secção executionMode é opcional e, se a omitir, o Skaffold executa o contentor de ações personalizadas no ambiente de execução do Cloud Deploy.

Variáveis de ambiente disponíveis

O Cloud Deploy fornece e preenche as seguintes variáveis de ambiente no ambiente de execução, que pode usar para os seus hooks:

  • ANTHOS_MEMBERSHIP

    Para alvos do tipo ANTHOS, o nome do recurso totalmente especificado da associação do Anthos.

  • CLOUD_RUN_LOCATION

    Para alvos do tipo RUN, a região na qual o serviço do Cloud Run está implementado.

  • CLOUD_RUN_PROJECT

    Para alvos do tipo RUN, o projeto no qual o serviço do Cloud Run foi criado.

  • CLOUD_RUN_SERVICE

    Para alvos do tipo RUN, o nome do serviço do Cloud Run implementado.

  • CLOUD_RUN_SERVICE_URLS

    Para alvos do tipo RUN, o URL ou os URLs (lista separada por vírgulas) que os utilizadores finais vão usar para aceder ao seu serviço. Pode encontrá-los nos detalhes do serviço do Cloud Run para o seu serviço, naGoogle Cloud consola.

  • CLOUD_RUN_REVISION

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

  • GKE_CLUSTER

    Para alvos 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 tempo de execução específico do alvo. GKE, ANTHOS ou RUN. Para alvos personalizados, esta opção não é definida.

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

  • CLOUD_DEPLOY_PROJECT

    O Google Cloud número do projeto do projeto que contém os recursos do Cloud Deploy.

  • CLOUD_DEPLOY_PROJECT_ID

    O Google Cloud ID do projeto.

  • CLOUD_DEPLOY_RELEASE

    O ID da versão na qual os hooks vão ser executados.

  • CLOUD_DEPLOY_ROLLOUT

    O ID da implementação que contém as tarefas dos hooks.

  • CLOUD_DEPLOY_JOB_RUN

    O ID da execução do trabalho que representa a execução atual do trabalho.

  • CLOUD_DEPLOY_PHASE

    A fase na implementação que contém a tarefa para os hooks.

Implemente parâmetros como variáveis de ambiente

Além das variáveis de ambiente indicadas nesta secção, o Cloud Deploy pode transmitir aos seus contentores personalizados quaisquer parâmetros de implementação que tenha definido.

Saiba mais.

O que se segue?