Esegui gli hook prima e dopo il deployment

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

Puoi configurare Cloud Deploy e Skaffold per eseguire azioni per eseguire azioni di pre-deployment e/o post-deployment. 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 ha alcun effetto aggiuntivo.

Come funzionano i hook di deployment?

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

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

  2. Configura gli hook in uno o più passaggi della progressione della pipeline di distribuzione, ognuno dei quali fa riferimento a uno dei customActions configurati in skaffold.yaml.

  3. Prima dell'esecuzione del job di deployment dell'implementazione, Skaffold esegue tutti i comandi configurati in skaffold.yaml a cui viene fatto riferimento in una stanza predeploy nell'avanzamento della pipeline.

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

  4. Dopo l'esecuzione del job di deployment dell'implementazione, Cloud Deploy esegue tutti i comandi configurati in skaffold.yaml a cui viene fatto riferimento in una stanza 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 su GKE e GKE Enterprise, facoltativamente puoi eseguire gli hook nello 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, devi tenere presente diverse cose:

  • Nella fase della pipeline di importazione, 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 automatico, 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 stanza customActions accetta una o più stanze customActions, configurate come segue:

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

In questa stanza customerActions:

  • ACTION_NAME

    È un nome per questa azione. Questo nome può essere qualsiasi, ma deve essere univoco all'interno di questo skaffold.yaml. È il nome a cui farà riferimento le azioni pre- 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 contatto da eseguire nel contenitore. "/bin/sh" è un comando tipico da specificare qui per richiamare una shell e dovrai 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 con virgole, con ogni argomento tra virgolette. Se COMMAND_TO_RUN è "/bin/sh", uno degli argomenti qui sarà "-c" e un altro argomento sarà l'intero comando che vuoi eseguire nella shell che stai invocando.

    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 importazione in modo che faccia riferimento alle azioni personalizzate che hai definito nel file skaffold.yaml. Le azioni pre- e post-deployment vengono configurate in uno o più passaggi specifici della progressione della pipeline.

Di seguito è descritto come configurare gli hook pre- e post-deployment in una fase della pipeline quando si utilizza 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 da eseguire prima del deployment.

  • POSTDEPLOY_ACTION

    È uguale a ACTION_NAME che hai utilizzato in skaffold.yaml per definire l'azione personalizzata da eseguire dopo il deployment.

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

Per impostazione predefinita, se esegui più di un 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 Skaffold.

Esegui gli hook sul cluster di applicazioni

Per impostazione predefinita, gli hook di deployment vengono eseguiti nell'ambiente di esecuzione Cloud Deploy. Puoi anche configurare Skaffold in modo da eseguire queste azioni personalizzate nello 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 del target.

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

Per eseguire l'hook sul cluster, includi una stanza executionMode.kubernetesCluster nel file di configurazione skaffold.yaml, all'interno della stanza 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 stanza customActions che include executionMode per richiamare il contenitore di hook nel cluster di applicazioni:

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

La stanza executionMode è facoltativa e, se la ometti, Skaffold esegue il container dell'azione personalizzata 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 i tuoi hook:

  • ANTHOS_MEMBERSHIP

    Per i target di tipo ANTHOS, il nome della risorsa completamente specificato dell'appartenenza ad Anthos.

  • CLOUD_RUN_LOCATION

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

  • CLOUD_RUN_PROJECT

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

  • CLOUD_RUN_SERVICE

    Per i target 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 (elencati separati 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 console Google Cloud.

  • CLOUD_RUN_REVISION

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

  • GKE_CLUSTER

    Per i target 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 importazione.

  • CLOUD_DEPLOY_TARGET

    L'ID del target.

  • CLOUD_DEPLOY_PROJECT

    Il progetto Google Cloud contenente le risorse Cloud Deploy.

  • CLOUD_DEPLOY_RELEASE

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

  • CLOUD_DEPLOY_ROLLOUT

    L'ID dell'implementazione 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 nell'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 container personalizzati tutti i parametri di deployment che hai impostato.

Scopri di più.

Passaggi successivi