Passare i parametri al deployment

Con Cloud Deploy, puoi trasmettere i parametri per la release. Questi valori vengono forniti al manifest o ai manifest prima che questi manifest vengano applicati ai rispettivi target. Questa sostituzione viene eseguita dopo il rendering dei manifest, come passaggio finale dell'operazione di rendering di Cloud Deploy. I valori vengono forniti per tutti i manifest identificati nel tuo file skaffold.yaml che contengono i segnaposto corrispondenti.

Devi solo includere i segnaposto nel file manifest e impostarne i valori nella pipeline di distribuzione di Cloud Deploy o nella configurazione di destinazione oppure quando crei una release.

Questo articolo descrive come farlo.

Perché utilizzare i parametri di deployment?

Un uso tipico di questo approccio è l'applicazione di valori diversi ai manifest per destinazioni diverse in un deployment parallelo. Tuttavia, puoi utilizzare i parametri di deployment per qualsiasi cosa che richieda la sostituzione di coppie chiave-valore post-rendering nel tuo manifest.

Come funziona

I passaggi seguenti descrivono la procedura generale per configurare i parametri di deployment e fornire i valori:

  1. Puoi configurare la parametrizzazione del deployment, come descritto qui.

    È incluso quanto segue:

    • Aggiungi i segnaposto al file manifest.

    • Aggiungi i valori per i segnaposto.

      Esistono tre modi per farlo, descritti qui.

  2. Quando crei una release, viene eseguito il rendering del file manifest.

    Se inizi con un manifest basato su modelli, ora i valori vengono applicati alle variabili del modello. Se inizi con un manifest non elaborato, questo rimane invariato. Questo rendering viene eseguito da Skaffold.

    Tuttavia, nel file manifest possono essere presenti altre variabili per le quali i valori non vengono applicati al momento del rendering. Questi sono i parametri di deployment descritti in questo documento.

    Al momento della creazione della release, tutti i parametri di deployment vengono compilati in un dizionario, che viene utilizzato per sostituire i valori prima dell'applicazione dei file manifest.

  3. Dopo il rendering, Cloud Deploy sostituisce i valori per i parametri di deployment.

    Questi sono i valori configurati nel primo passaggio.

    Il processo di rendering applicava valori ai modelli manifest, sostituendo alcuni valori e aggiungendo etichette specifiche per Cloud Deploy. I valori di questi parametri di deployment vengono sostituiti dopo il rendering. Le differenze tra i modelli manifest e i parametri di deployment sono descritte qui.

  4. Il manifest viene applicato al runtime di destinazione per eseguire il deployment dell'applicazione.

    Sono inclusi i valori sostituiti al momento del rendering e i valori per eventuali parametri di deployment

Diversi modi per trasmettere i valori

Puoi fornire i parametri e i valori di questi parametri in tre modi:

  • Nella definizione della pipeline di distribuzione

    Fornisci il parametro e il relativo valore nella definizione di una fase dell'avanzamento della pipeline di distribuzione. Il parametro viene passato alla destinazione rappresentata da quella fase. Se questa fase fa riferimento a un multi-target, i valori impostati qui vengono utilizzati per tutti i target secondari.

    Questo metodo consente di sostituire un valore per tutte le release all'interno di una determinata pipeline per tutte le destinazioni interessate. I parametri definiti per una fase identificano un'etichetta e il target corrispondente a quella fase deve avere un'etichetta corrispondente.

  • Nella definizione del target

    Puoi configurare il parametro e il suo valore nella definizione del target stesso. Questo metodo consente di sostituire un valore per quel target per tutte le release.

  • Nella riga di comando, quando crei una release

    Puoi includere il parametro e il relativo valore utilizzando il flag --deploy-parameters nel comando gcloud deploy releases create.

    Questo metodo consente di sostituire un valore al momento della creazione della release, applicandolo ai manifest di tutte le destinazioni interessate.

La configurazione di questi modelli è spiegata in modo più dettagliato qui.

Posso utilizzare più di uno di questi metodi?

Sì, puoi includere i parametri di deployment nella fase della pipeline, nella configurazione della destinazione e nella riga di comando. Tutti i parametri vengono accettati e aggiunti al dizionario. Tuttavia, se un parametro specifico viene passato in più di una posizione, ma con valori diversi, il comando gcloud deploy releases create non riesce e restituisce un errore.

Esegui il deployment dei parametri con target personalizzati

Puoi utilizzare qualsiasi parametro di deployment come variabili di ambiente nei target personalizzati. A questo scopo, utilizza la syntax specificata per i target personalizzati.

Qual è la differenza rispetto ai modelli manifest

I parametri di deployment, come descritto in questo articolo, si distinguono dai segnaposto in un manifest basato su modelli dalla syntax. Tuttavia, se ti stai chiedendo perché dovresti avere bisogno dei parametri di deployment anziché utilizzare semplicemente le tecniche standard per i manifest basati su modelli, la seguente tabella mostra i diversi scopi:

Tecnica Ora di sostituzione Applicabile a
Modello manifest Fase di rendering Release specifica; target specifico
Sulla riga di comando Post-rendering Release specifica; tutti i target
Pipeline di distribuzione Post-rendering Tutte le uscite; target specifici (per etichetta)
In linea con l'obiettivo Post-rendering Tutte le release; target specifico

Questo documento riguarda solo i parametri di deployment (su riga di comando, pipeline e target), non sui manifest basati su modelli.

Limitazioni

  • Per ogni tipo di parametro, puoi creare un massimo di 25 parametri.

  • Un target secondario può inoltre ereditare fino a 25 parametri dal suo multi-target padre, fino a un massimo di 100 parametri sui target, inclusi quelli impostati nella fase della pipeline.

  • Il nome della chiave può contenere massimo 63 caratteri e la seguente espressione regolare:

    ^[a-zA-Z0-9]([-A-Za-z0-9_.]{0,61}[a-zA-Z0-9])?$
    

    Un'eccezione è quando utilizzi un parametro di deployment come variabile di ambiente in un target personalizzato, devi utilizzare una barra tra la parola chiave customTarget e il nome della variabile (customTarget/VAR_NAME). Consulta Input e output obbligatori per la sintassi supportata.

  • Il prefisso CLOUD_DEPLOY_ è riservato e non può essere utilizzato per il nome di una chiave.

  • Non possono essere applicate allo stesso target due chiavi con lo stesso nome.

  • Il valore può essere vuoto, ma può contenere al massimo 512 caratteri.

  • I segnaposto dei parametri di deployment non possono essere utilizzati per i valori di configurazione di Helm, ma devono essere trasmessi per convenzione.

Configura parametri di deployment

Questa sezione descrive come configurare i valori dei parametri di deployment che verranno applicati al tuo manifest Kubernetes, al tuo servizio Cloud Run o al tuo modello Helm.

Oltre a configurare queste coppie chiave-valore, devi aggiungere il segnaposto o i segnaposto al tuo manifest, come descritto in questa sezione.

Aggiungere segnaposto al file manifest

Nel manifest Kubernetes (per GKE) o nel servizio YAML (per Cloud Run), aggiungi segnaposto per tutti i valori che vuoi sostituire dopo il rendering.

Sintassi

Per le release che non utilizzano il renderer Helm con Skaffold, utilizza la seguente sintassi per i segnaposto:

[PROPERTY]: [DEFAULT_VALUE] # from-param: ${VAR_NAME}

In questa riga...

  • PROPERTY:

    È la proprietà di configurazione nel manifest Kubernetes o nel servizio YAML del servizio Cloud Run.

  • DEFAULT_VALUE

    È un valore da utilizzare se non vengono forniti valori per questa proprietà nella riga di comando o nella pipeline o nella configurazione di destinazione.

  • # from-param:

    Utilizza un carattere di commento per impostare l'istruzione deploy-parameters di Cloud Deploy e from-param: indica a Cloud Deploy che segue un segnaposto deploy-parameters.

  • ${VAR_NAME}

    È il segnaposto da sostituire. Deve corrispondere alla chiave di una coppia chiave-valore fornita nella pipeline di distribuzione o nella configurazione di destinazione oppure al momento della creazione della release.

Parametri per i valori dei grafici Helm

Se stai eseguendo il rendering di un grafico Helm che accetta valori di configurazione e vuoi impostare questi valori utilizzando i parametri di deployment, i parametri di deployment devono avere nomi corrispondenti ai valori delle configurazioni Helm che vuoi impostare. Tutti i parametri di deployment vengono passati a Helm come argomenti --set al momento del rendering, senza modificare skaffold.yaml.

Ad esempio, se skaffold.yaml installa un grafico Helm che richiede un parametro di configurazione webserver.port per specificare su quale porta verrà avviato il server web e vuoi impostarlo in modo dinamico a partire da un parametro di deployment, devi creare un parametro di deployment con il nome webserver.port con il valore che preferisci per la porta del server web.

Pertanto, se non fai riferimento solo ai modelli Helm in skaffold.yaml, ma ne crei anche tu, puoi utilizzare la sintassi delle variabili Helm standard di {{ .Values.VAR_NAME }} nei tuoi modelli Helm.

Ad esempio, se abbiamo configurato un parametro di deployment webserver.port, potremmo utilizzarlo in questo modo:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: webserver
spec:
  replicas: 3
  selector:
    matchLabels:
      app: webserver
  template:
    metadata:
      labels:
        app: webserver
    spec:
      containers:
      - name: webserver
        image: gcr.io/example/webserver:latest
        ports:
        - containerPort: {{ .Values.webserver.port }} # replaced by deploy parameter `webserver.port`.
          name: web
        env:
        - name: WEBSERVER_PORT
          value: {{ .Values.webserver.port }} # replaced by deploy parameter `webserver.port`.

Aggiungi un parametro alla fase della pipeline

Puoi aggiungere coppie chiave-valore a una fase dell'avanzamento della pipeline di distribuzione. Questo è utile per i deployment paralleli, per distinguere tra le destinazioni figlio.

  1. Aggiungi i segnaposto al manifest Kubernetes o al servizio Cloud Run, come descritto qui.

    Ecco un esempio:

    apiVersion: apps/v1
    kind: Deployment
    metadata:
     name: nginx-deployment
     labels:
       app: nginx
    spec:
     replicas: 1 # from-param: ${deploy_replicas}
     selector:
       matchLabels:
         app: nginx
     template:
       metadata:
         labels:
           app: nginx
       spec:
         containers:
         - name: nginx
           image: nginx:1.14.2
           ports:
           - containerPort: 80
    
  2. Configura la pipeline di distribuzione in modo da includere deployParameters per la fase applicabile della pipeline.

    Il seguente YAML è la configurazione per una fase della pipeline il cui target è un multi-target, che in questo caso ha due destinazioni figlio:

    serialPipeline:
     stages:
       - targetId: dev
         profiles: []
       - targetId: prod  # multi-target
         profiles: []
         deployParameters:
           - values:
               deploy_replicas: 1
               log_level: "NOTICE"
             matchTargetLabels: # optional, applies to all resources if unspecified; AND'd
               my-app: "post-render-config-1"
           - values:
               deploy_replicas: 2
               log_level: "WARNING"
             matchTargetLabels: # optional, applies to all resources if unspecified; AND'd
               my-app: "post-render-config-2"
    

    In questa configurazione della pipeline di distribuzione, la stanza deployParameters include due elementi values, ognuno dei quali ha quanto segue:

    • Il nome della variabile, che è lo stesso nome della variabile impostata nel file manifest

    • Un valore per la variabile

    • Una o più etichette (facoltative) da abbinare a etichette specifiche del target

      Se non specifichi un'etichetta, in una stanza matchTargetLabels, quel valore viene utilizzato per tutte le destinazioni nella fase.

  3. Se hai incluso matchTargetLabels, devi anche includere le etichette nelle destinazioni per farle corrispondere. In questo modo, identifica il valore da assegnare a un determinato target secondario.

    Il target deve corrispondere a tutte le etichette impostate nella stanza values.

    Se ometti matchTargetLabels, il valore values impostato nella pipeline viene applicato a tutti i target figlio. Tuttavia, se imposti più di un valore per lo stesso parametro, la release non riuscirà.

Dopo il rendering di ogni manifest, Cloud Deploy aggiunge il valore per ogni variabile nel manifest sottoposto a rendering.

Aggiungi un parametro alla configurazione di destinazione

Puoi aggiungere coppie chiave-valore a un target. Se utilizzi parametri di deployment per distinguere tra più destinazioni figlio, configurali sulle destinazioni figlio, non su più target.

  1. Configura il manifest Kubernetes o la definizione del servizio Cloud Run utilizzando un parametro al posto del valore da impostare al momento del deployment.

    Ecco un esempio:

    apiVersion: apps/v1
    kind: Deployment
    metadata:
     name: nginx-deployment
     labels:
       app: nginx
    spec:
     selector:
       matchLabels:
         app: nginx
     template:
       metadata:
         labels:
           app: nginx
       spec:
         containers:
         - name: nginx
           image: nginx:1.14.2
           env:
           - name: envvar1
             value: example1 # from-param: ${application_env1}
           - name: envvar2
             value: example2 # from-param: ${application_env2}
    

    In questo file manifest, il parametro envvar1 è impostato sul valore predefinito example1 e envvar2 il valore predefinito è example2.

  2. Configura i tuoi target in modo da includere deployParameters.

    Per ogni parametro che includi, devi identificare quanto segue:

    • Il nome della chiave, che corrisponde alla chiave (variabile) impostata nel manifest.

    • Un valore per quella chiave. Se non specifichi un valore, viene utilizzato il valore predefinito impostato nel manifest.

    Il seguente YAML è la configurazione di due destinazioni. Ogni destinazione include l'impostazione di un valore per la stanza deployParameters. Ogni target include anche un'etichetta, da abbinare ai parametri di deployment configurati in una fase della pipeline.

    apiVersion: deploy.cloud.google.com/v1beta1
    kind: Target
    metadata:
      name: prod1
      labels:
        my-app: "post-render-config-1"
    description: development cluster
    deployParameters:
      application_env1: "newValue1"
    ---
    
    apiVersion: deploy.cloud.google.com/v1beta1
    kind: target
    metadata:
      name: prod2
      labels:
        my-app: "post-render-config-2"
    description: development cluster
    deployParameters:
      application_env1: "newValue2"
    

Quando la release viene creata, ma dopo il rendering dei manifest, Cloud Deploy aggiunge questi valori ai manifest sottoposti a rendering se includono le chiavi associate.

Trasmettere un parametro al momento della creazione della release

Per trasmettere parametri e valori alla release:

  1. Configura il manifest Kubernetes o la definizione del servizio Cloud Run utilizzando un parametro al posto del valore da impostare al momento del deployment.

    Ecco un esempio:

    apiVersion: apps/v1
    kind: Deployment
    metadata:
     name: nginx-deployment
     labels:
       app: nginx
    spec:
     selector:
       matchLabels:
         app: nginx
     template:
       metadata:
         labels:
           app: nginx
       annotations:
         commit: defaultShaValue # from-param: ${git-sha}
       spec:
         containers:
         - name: nginx
           image: nginx:1.14.2
    

    In questo esempio, la SHA di commit è impostata come variabile denominata ${git-sha}. Un valore viene trasmesso al momento della creazione della release, utilizzando l'opzione --deploy-parameters=, come mostrato nel passaggio successivo.

    La sintassi per questa variabile è $ più il nome della variabile tra parentesi graffe. In questo esempio, è ${git-sha}.

  2. Quando crei una release, includi l'opzione --deploy-parameters nel comando gcloud deploy releases create.

    --deploy-parameters utilizza un elenco separato da virgole di coppie chiave/valore, in cui la chiave è il segnaposto che hai aggiunto al manifest.

    Il comando sarà simile a questo:

    gcloud deploy releases create test-release-001 \
    --project=my-example-project \
    --region=us-central1 \
    --delivery-pipeline=my-params-demo-app-1 \
    --images=my-app-image=gcr.io/google-containers/nginx@sha256:f49a843c290594dcf4d193535d1f4ba8af7d56cea2cf79d1e9554f077f1e7aaa \
    --deploy-parameters="git-sha=f787cac"
    
    

Quando viene creata la release, ma dopo il rendering del manifest, Cloud Deploy fornisce i valori ai manifest sottoposti a rendering se includono le chiavi associate.

Visualizzare tutti i parametri per una release

Puoi visualizzare i parametri impostati per una determinata release. Vengono visualizzati in una tabella nella pagina Dettagli release e nella riga di comando (gcloud deploy releases describe).

  1. Nella pagina principale di Cloud Deploy, fai clic sulla pipeline di distribuzione che include la release che vuoi visualizzare.

  2. Nella pagina Dettagli sulla release, seleziona la scheda Artefatti.

Tutti i parametri di deployment impostati per questa release vengono mostrati in una tabella, con il nome e il valore della variabile in una colonna e il target o i target interessati nell'altra colonna.

di deployment dei parametri e dei valori mostrati nella console Google Cloud

Passaggi successivi