Esegui gli hook prima e dopo il deployment

Questo documento descrive come eseguire programmi o operazioni arbitrari prima o dopo il deployment.

Puoi configurare Cloud Deploy e Skaffold per eseguire azioni per eseguire azioni di pre-deployment o post-deployment o entrambe. Questi programmi, eseguiti in questo modo, sono chiamati "hook". Gli hook pre-deployment e post-deployment vengono eseguiti come job pre-deployment e post-deployment durante l'implementazione.

Puoi configurare ogni hook in modo che venga eseguito in un ambiente di esecuzione Cloud Deploy specificato, ma se esegui il deployment in Google Kubernetes Engine, puoi facoltativamente configurarlo in modo che venga eseguito nel cluster GKE in cui esegui il deployment dell'applicazione.

Si presume che gli hook di deployment siano idempotenti. Se una determinata azione viene eseguita più di una volta, non si verifica alcun effetto aggiuntivo.

Come funzionano gli hook di deployment?

Di seguito sono descritti i passaggi per configurare gli hook di deployment e la procedura di Skaffold e Cloud Deploy per eseguire questi hook:

  1. Configura skaffold.yaml utilizzato per una determinata release in modo che includa customActions che identificano l'immagine o le immagini container da utilizzare per eseguire gli hook e il comando o lo script specifico da eseguire su ogni container.

  2. Configuri gli hook in una o più fasi della progressione della pipeline di distribuzione, ognuna delle quali fa riferimento a uno dei customActions che hai configurato in skaffold.yaml.

  3. Prima dell'esecuzione del job di deployment del rollout, Skaffold esegue tutti i comandi configurati in skaffold.yaml a cui viene fatto riferimento in una sezione predeploy nella progressione della pipeline.

    L'hook predeploy viene sempre eseguito come primo job nella fase.

  4. Dopo l'esecuzione del job di deployment del rollout, Cloud Deploy esegue tutti i comandi configurati in skaffold.yaml a cui viene fatto riferimento in una sezione postdeploy nella progressione della pipeline.

Gli hook di deployment vengono eseguiti nell'ambiente di esecuzione Cloud Deploy predefinito o in un ambiente di esecuzione alternativo specificato. Per i deployment in GKE, puoi facoltativamente eseguire gli hook sullo stesso cluster in cui viene eseguito il deployment dell'applicazione.

Utilizzo degli hook di deployment con un deployment canary

Quando configuri gli hook di deployment per un deployment canary, ci sono diverse cose da sapere:

  • Nella fase della pipeline di distribuzione, la configurazione dell'hook (predeploy e postdeploy) si trova in strategy.canary.canaryDeployment o strategy.canary.customCanaryDeployment.phaseConfigs, anziché in strategy.standard.

  • Per un canary automatizzato, gli hook predeploy vengono eseguiti prima del deployment solo nella prima fase, mentre gli hook postdeploy vengono eseguiti dopo il deployment solo nell'ultima fase (stabile).

Configurare le azioni in Skaffold

Nel file skaffold.yaml, la sezione customActions accetta una o più sezioni customActions, configurate nel seguente modo:

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

In questa strofa di customerActions:

  • ACTION_NAME

    È un nome per questa azione. Puoi scegliere il nome che preferisci, ma deve essere univoco all'interno di questo skaffold.yaml. Questo è il nome a cui verrà fatto riferimento dalle azioni pre-deployment e post-deployment definite nella fase della pipeline di distribuzione.

  • CONTAINER_NAME

    È un nome per il contenitore specifico. Puoi scegliere il nome che preferisci, ma deve essere univoco all'interno di questo skaffold.yaml.

  • IMAGE

    È il nome dell'immagine container in cui verrà eseguito il comando.

  • COMMANDS_TO_RUN

    È un elenco di punti di ingresso da eseguire sul container. "/bin/sh" è un comando tipico da specificare qui per richiamare una shell e includere il comando da eseguire in quella shell negli argomenti.

  • LIST_OF_ARGS

    È un elenco di argomenti da fornire al comando. Si tratta di un elenco separato da virgole, con ogni argomento tra virgolette. Se il tuo COMMAND_TO_RUN è "/bin/sh", uno degli argomenti qui sarebbe "-c" e un altro argomento sarebbe l'intero comando che vuoi eseguire nella shell che stai richiamando.

    Ecco un esempio:

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

Per scoprire di più sulle azioni personalizzate di Skaffold, consulta la documentazione di Skaffold.

Configura la pipeline in modo che faccia riferimento alle azioni

Per completare la configurazione degli hook di deployment, configura la pipeline di distribuzione in modo che faccia riferimento alle azioni personalizzate che hai definito nel file skaffold.yaml. Le azioni pre-deployment e post-deployment vengono configurate in una o più fasi specifiche della progressione della pipeline.

Di seguito viene illustrato come configurare gli hook pre-deployment e post-deployment in una fase della pipeline quando utilizzi una strategia di deployment standard:

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

In questo file YAML:

  • PREDEPLOY_ACTION

    È uguale a ACTION_NAME che hai utilizzato in skaffold.yaml per definire l'azione personalizzata che vuoi eseguire prima del deployment.

  • POSTDEPLOY_ACTION

    È uguale a ACTION_NAME che hai utilizzato in skaffold.yaml per definire l'azione personalizzata che vuoi eseguire dopo l'implementazione.

Puoi specificare più di un'azione per predeploy e postdeploy, separate da virgole. Quando vengono specificate più azioni, queste vengono eseguite in sequenza, nell'ordine in cui sono specificate. Il job (pre-deployment o post-deployment) ha esito negativo alla prima azione che non va a buon fine e le azioni rimanenti non vengono eseguite.

Per impostazione predefinita, se esegui più container in parallelo e un job non va a buon fine, entrambi i container vengono arrestati. Puoi configurare questo comportamento utilizzando la strategia di errore dell'azione personalizzata di Skaffold.

Esegui gli hook sul cluster di applicazioni

Per impostazione predefinita, gli hook di deployment vengono eseguiti nell'ambiente di esecuzione di Cloud Deploy. Puoi anche configurare Skaffold per eseguire queste azioni personalizzate sullo stesso cluster in cui è in esecuzione la tua applicazione. Quando configuri azioni personalizzate in skaffold.yaml e le attivi in una fase della pipeline, l'azione viene eseguita automaticamente nel cluster della destinazione.

Questa funzionalità è disponibile solo per i deployment su GKE, non per Cloud Run. I deployment su Cloud Run possono eseguire hook solo nell'ambiente di esecuzione di Cloud Deploy.

Per eseguire l'hook sul cluster, includi una sezione executionMode.kubernetesCluster nel file di configurazione skaffold.yaml, all'interno della sezione customActions per l'azione personalizzata specifica:

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

Di seguito è riportato un esempio di sezione customActions che include executionMode per richiamare il container hook sul cluster dell'applicazione:

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

La sezione executionMode è facoltativa e, se la ometti, Skaffold esegue il container di azioni personalizzate nell'ambiente di esecuzione di Cloud Deploy.

Variabili di ambiente disponibili

Cloud Deploy fornisce e compila le seguenti variabili di ambiente nell'ambiente di esecuzione, che puoi utilizzare per gli hook:

  • ANTHOS_MEMBERSHIP

    Per i target di tipo ANTHOS, il nome della risorsa completamente specificato dell'appartenenza ai cluster GKE collegati.

  • CLOUD_RUN_LOCATION

    Per i target di tipo RUN, la regione in cui viene eseguito il deployment del servizio Cloud Run.

  • CLOUD_RUN_PROJECT

    Per le destinazioni di tipo RUN, il progetto in cui è stato creato il servizio Cloud Run.

  • CLOUD_RUN_SERVICE

    Per le destinazioni di tipo RUN, il nome del servizio Cloud Run di cui è stato eseguito il deployment.

  • CLOUD_RUN_SERVICE_URLS

    Per i target di tipo RUN, l'URL o gli URL (elenco separato da virgole) che gli utenti finali utilizzeranno per accedere al tuo servizio. Puoi trovarli nei dettagli del servizio Cloud Run per il tuo servizio, nella consoleGoogle Cloud .

  • CLOUD_RUN_REVISION

    Per i target di tipo RUN, la revisione specifica del servizio Cloud Run.

  • GKE_CLUSTER

    Per le destinazioni di tipo GKE, il nome della risorsa completamente specificato del cluster Google Kubernetes Engine, ad esempio projects/p/locations/us-central1/clusters/dev.

  • TARGET_TYPE

    Il tipo di runtime specifico della destinazione. GKE, ANTHOS o RUN. Per i target personalizzati, questo valore non verrà impostato.

  • CLOUD_DEPLOY_LOCATION

    La regione contenente le risorse Cloud Deploy.

  • CLOUD_DEPLOY_DELIVERY_PIPELINE

    L'ID della pipeline di distribuzione.

  • CLOUD_DEPLOY_TARGET

    L'ID del target.

  • CLOUD_DEPLOY_PROJECT

    Il numero di progetto Google Cloud per il progetto contenente le risorse Cloud Deploy.

  • CLOUD_DEPLOY_PROJECT_ID

    L'ID progetto Google Cloud per il progetto.

  • CLOUD_DEPLOY_RELEASE

    L'ID della release in cui verranno eseguiti gli hook.

  • CLOUD_DEPLOY_ROLLOUT

    L'ID del rollout che contiene i job per gli hook.

  • CLOUD_DEPLOY_JOB_RUN

    L'ID dell'esecuzione del job che rappresenta l'esecuzione corrente del job.

  • CLOUD_DEPLOY_PHASE

    La fase dell'implementazione che contiene il job per gli hook.

Esegui il deployment dei parametri come variabili di ambiente

Oltre alle variabili di ambiente elencate in questa sezione, Cloud Deploy può passare ai tuoi container personalizzati qualsiasi parametro di deployment che hai impostato.

Scopri di più.

Passaggi successivi