Pasa parámetros a tu implementación

Con Cloud Deploy, puedes pasar parámetros para tu versión, y esos valores se proporcionan al manifiesto o a los manifiestos antes de que estos se apliquen a sus respectivos destinos. Esta sustitución se realiza después de que los manifiestos se procesen, como el paso final en la operación de renderización de Cloud Deploy. Los valores se proporcionan a todos los manifiestos identificados en tu archivo skaffold.yaml que contengan los marcadores de posición correspondientes.

Lo único que debes hacer es incluir marcadores de posición en tu manifiesto y establecer los valores para esos marcadores en tu canalización de entrega de Cloud Deploy o configuración de destino, o cuando creas una versión.

En este artículo, se describe cómo lograrlo.

¿Por qué usar parámetros de implementación?

Un uso típico de esto sería aplicar diferentes valores a los manifiestos para distintos objetivos en una implementación en paralelo. Sin embargo, puedes usar parámetros de implementación para cualquier cosa que requiera la sustitución de pares clave-valor posterior a la renderización en tu manifiesto.

Cómo funciona

En los siguientes pasos, se describe el proceso general para configurar parámetros de implementación y proporcionar valores:

  1. Configura la parametrización de implementación como se describe aquí.

    Estos son algunos de ellos:

    • Agrega los marcadores de posición a tu manifiesto.

    • Agrega valores para esos marcadores de posición.

      Existen tres maneras de hacerlo, que se describen aquí.

  2. Cuando creas una versión, tu manifiesto se renderiza.

    Si comienzas con un manifiesto con plantilla, los valores se aplican ahora para las variables de plantilla. Si comienzas con un manifiesto sin procesar, no se modifica. Esta renderización se realiza con Skaffold.

    Sin embargo, puedes tener variables adicionales en tu manifiesto para las que no se apliquen valores en el tiempo de renderización. Estos son los parámetros de implementación que se describen en este documento.

    Cuando se crea la versión, todos los parámetros de implementación se compilan en un diccionario, que se usa para sustituir valores antes de que se apliquen los manifiestos.

  3. Después del procesamiento, Cloud Deploy sustituye los valores por los parámetros de implementación.

    Estos son los valores que configuraste en el primer paso.

    El proceso de renderización ya aplicó valores a las plantillas de manifiesto, reemplazando algunos valores y agregando etiquetas específicas de Cloud Deploy. Sin embargo, los valores de estos parámetros de implementación se sustituyen después del procesamiento. Las diferencias entre las plantillas de manifiesto y los parámetros de implementación se describen aquí.

  4. El manifiesto se aplica al entorno de ejecución de destino para implementar tu aplicación.

    Esto incluye los valores sustituidos en el momento de la renderización y los valores de cualquier parámetro de implementación.

Diferentes maneras de pasar valores

Puedes proporcionar parámetros y valores para esos parámetros de tres maneras:

  • En la definición de la canalización de entrega

    Tú proporcionas el parámetro y su valor en la definición de una etapa en el progreso de la canalización de entrega. El parámetro se pasa al objetivo representado por esa etapa. Si esa etapa hace referencia a un destino múltiple, los valores establecidos aquí se usan para todos los destinos secundarios.

    Este método te permite reemplazar un valor para todas las versiones dentro de una canalización determinada en todos los destinos afectados. Los parámetros definidos para una etapa identifican una etiqueta, y el destino correspondiente de esa etapa debe tener una etiqueta coincidente.

  • En la definición del destino

    Tú configuras el parámetro y su valor en la definición del objetivo en sí. Este método te permite reemplazar un valor para ese destino en todas las versiones.

  • En la línea de comandos, cuando crees una versión

    Puedes incluir el parámetro y su valor con la marca --deploy-parameters en el comando gcloud deploy releases create.

    Este método te permite reemplazar un valor en el momento de la creación de la versión y aplicar ese valor a los manifiestos de todos los destinos afectados.

La configuración de estos se explica con más detalle aquí.

¿Puedo usar más de uno de estos métodos?

Sí, puedes incluir parámetros de implementación en la etapa de canalización, en la configuración de destino y en la línea de comandos. El resultado es que se aceptan todos los parámetros y se agregan al diccionario. Sin embargo, si se pasa un parámetro específico en más de un lugar, pero con valores diferentes, el comando gcloud deploy releases create falla y muestra un error.

Implementa parámetros con destinos personalizados

Puedes usar cualquier parámetro de implementación como variables de entorno en destinos personalizados. Cuando lo hagas, usa la syntax especificada para los destinos personalizados.

¿En qué se diferencia de las plantillas de manifiesto?

Los parámetros de implementación, como se describe en este artículo, se distinguen de los marcadores de posición en un manifiesto con plantilla por la syntax. Sin embargo, si te preguntas por qué necesitarías implementar parámetros en lugar de usar solo las técnicas estándar para manifiestos con plantillas, la siguiente tabla muestra los diferentes propósitos:

Técnica Hora de sustitución Se aplica a
Plantilla de manifiesto Fase de renderización Versión específica; objetivo específico
En la línea de comandos Renderización posterior Versión específica; todos los destinos
Canalización durante la entrega Renderización posterior Todas las versiones; objetivos específicos (por etiqueta)
Según el objetivo Renderización posterior Todas las versiones; objetivo específico

En este documento, se describen solo los parámetros de implementación (en la línea de comandos, la canalización y el destino), no los manifiestos con plantillas.

Limitaciones

  • Para cada tipo de parámetro, puedes crear un máximo de 25 parámetros.

  • Además, un destino secundario puede heredar hasta 25 parámetros de su objetivo múltiple superior, hasta un máximo de 100 parámetros en los destinos, incluidos los configurados en la etapa de canalización.

  • El nombre de la clave está limitado a un máximo de 63 caracteres y la siguiente expresión regular:

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

    Una excepción a esto es cuando usas un parámetro de implementación como una variable de entorno en un destino personalizado, debes usar una barra entre la palabra clave customTarget y el nombre de la variable (customTarget/VAR_NAME). Consulta Entradas y salidas obligatorias para conocer la sintaxis compatible.

  • El prefijo CLOUD_DEPLOY_ está reservado y no se puede usar para un nombre de clave.

  • No puedes tener dos claves con el mismo nombre aplicadas al mismo destino.

  • El valor puede estar vacío, pero tiene un máximo de 512 caracteres.

  • Los marcadores de posición de los parámetros de implementación no se pueden usar para los valores de configuración de Helm, pero deben pasarse por convención.

Configura los parámetros de implementación

En esta sección, se describe cómo configurar los valores de los parámetros de implementación que se aplicarán a tu manifiesto de Kubernetes, al servicio de Cloud Run o a la plantilla de Helm.

Además de configurar esos pares clave-valor, debes agregar los marcadores de posición a tu manifiesto, como se describe en esta sección.

Cómo agregar marcadores de posición a tu manifiesto

En el manifiesto de Kubernetes (para GKE) o en el YAML del servicio (para Cloud Run), agrega marcadores de posición para cualquier valor que desees sustituir después del procesamiento.

Sintaxis

En las versiones que no usan el procesador Helm con Skaffold, usa la siguiente sintaxis para los marcadores de posición:

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

En esta línea...

  • PROPERTY:

    Es la propiedad de configuración en tu manifiesto de Kubernetes o YAML del servicio de Cloud Run.

  • DEFAULT_VALUE

    Es un valor que se debe usar si no se proporcionan valores para esta propiedad en la línea de comandos, en la canalización o la configuración de destino.

  • # from-param:

    Usa un carácter de comentario para activar la directiva deploy-parameters de Cloud Deploy y from-param: le indica a Cloud Deploy que sigue un marcador de posición deploy-parameters.

  • ${VAR_NAME}

    Es el marcador de posición que se sustituirá. Debe coincidir con la clave de un par clave-valor proporcionado en la canalización de entrega o la configuración de destino, o cuando se crea la versión.

Parámetros para los valores del gráfico de Helm

Si renderizas un gráfico de Helm que acepta valores de configuración y deseas establecer esos valores usando parámetros de implementación, estos deben tener nombres que coincidan con los valores de configuración de Helm que quieres establecer. Todos los parámetros de implementación se pasan a Helm como argumentos --set en el momento del procesamiento, sin necesidad de modificar tu skaffold.yaml.

Por ejemplo, si tu skaffold.yaml instala un gráfico de Helm que toma un parámetro de configuración de webserver.port para especificar en qué puerto se iniciará el servidor web y deseas establecerlo de forma dinámica a partir de un parámetro de implementación, deberás crear un parámetro de implementación con el nombre webserver.port con el valor que deseas para el puerto del servidor web.

Por lo tanto, si no solo haces referencia a plantillas de Helm en tu skaffold.yaml, sino que también las creas, puedes usar la sintaxis estándar de la variable de Helm de {{ .Values.VAR_NAME }} en tus plantillas de Helm.

Por ejemplo, si tenemos un parámetro de implementación de webserver.port configurado, podríamos usarlo de la siguiente manera:

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`.

Agrega un parámetro a la etapa de canalización

Puedes agregar pares clave-valor a una etapa del progreso de la canalización de entrega. Esto es útil para las implementaciones en paralelo, para distinguir entre destinos secundarios.

  1. Agrega los marcadores de posición a tu manifiesto de Kubernetes o servicio de Cloud Run, como se describe aquí.

    Por ejemplo:

    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 tu canalización de entrega de modo que incluya deployParameters para la etapa de canalización aplicable.

    El siguiente YAML es la configuración de una etapa de canalización cuyo destino es un destino múltiple, que en este caso tiene dos destinos secundarios:

    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"

    En esta configuración de canalización de entrega, la estrofa deployParameters incluye dos values, cada una de las cuales tiene lo siguiente:

    • El nombre de la variable, que es el mismo nombre de la variable que configuraste en el manifiesto

    • Un valor para esa variable

    • Una o más etiquetas (opcional) que deben coincidir con las etiquetas específicas del destino

      Si no especificas una etiqueta, en una estrofa matchTargetLabels, ese valor se usa para todos los destinos de la etapa.

  3. Si incluiste matchTargetLabels, también debes incluir etiquetas en los destinos para que coincidan. De esta manera, puedes identificar qué valor asignar a qué objetivo secundario.

    El destino debe coincidir con todas las etiquetas establecidas en la estrofa values.

    Si omites matchTargetLabels, el values que configuraste en la canalización se aplicará a todos los destinos secundarios. Sin embargo, si configuras más de un valor para el mismo parámetro, la actualización fallará.

Después de procesar cada manifiesto, Cloud Deploy agrega el valor de cada variable en el manifiesto renderizado.

Agrega un parámetro a la configuración de destino

Puedes agregar pares clave-valor a un destino. Si usas parámetros de implementación para distinguir entre varios destinos secundarios, configúralos en esos destinos secundarios, no en los destinos múltiples.

  1. Configura el manifiesto de Kubernetes o la definición del servicio de Cloud Run mediante un parámetro en lugar del valor que deseas configurar en el momento de la implementación.

    Por ejemplo:

    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}

    En este manifiesto, el parámetro envvar1 se establece en un valor predeterminado de example1, y envvar2 se establece en un valor predeterminado de example2.

  2. Configura tus objetivos para incluir deployParameters.

    Para cada parámetro que incluyas, identificas lo siguiente:

    • El nombre de la clave, que es el mismo nombre que la clave (variable) que estableciste en el manifiesto.

    • Un valor para esa clave. Si no proporcionas un valor, se usará el valor predeterminado establecido en el manifiesto.

    El siguiente YAML es la configuración para dos destinos. Cada objetivo incluye una estrofa deployParameters que establece un valor. Cada destino también incluye una etiqueta, que debe coincidir con los parámetros de implementación configurados en una etapa de canalización.

    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"

Cuando se crea la versión, pero después de que se renderizan los manifiestos, Cloud Deploy agrega estos valores a los manifiestos renderizados si incluyen las claves asociadas.

Pasa un parámetro durante la creación de la versión

Sigue estos pasos para pasar parámetros y valores a la versión:

  1. Configura el manifiesto de Kubernetes o la definición del servicio de Cloud Run con un parámetro en lugar del valor que deseas configurar en el momento de la implementación.

    Por ejemplo:

    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

    En este ejemplo, el SHA de confirmación se establece como una variable llamada ${git-sha}. Con la opción --deploy-parameters=, se pasa un valor para esto durante la creación de la versión, como se ve en el siguiente paso.

    La sintaxis de esta variable es $ más el nombre de la variable entre llaves. En este ejemplo, es ${git-sha}.

  2. Cuando crees una versión, incluye la opción --deploy-parameters en el comando gcloud deploy releases create.

    --deploy-parameters toma una lista separada por comas de pares clave-valor, en los que la clave es el marcador de posición que agregaste al manifiesto.

    El comando será similar a este:

    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"

Cuando se crea la versión, pero después del procesamiento del manifiesto, Cloud Deploy proporciona los valores a los manifiestos renderizados si incluyen las claves asociadas.

Cómo ver todos los parámetros de una versión

Puedes ver los parámetros que se establecieron para una versión determinada. Se muestran en una tabla de la página Detalles de la versión y en la línea de comandos (gcloud deploy releases describe).

  1. En la página principal de Cloud Deploy, haz clic en la canalización de entrega que incluye la versión que deseas ver.

  2. En la página Detalles de la versión, selecciona la pestaña Artefactos.

Todos los parámetros de implementación que se configuraron para esta versión se muestran en una tabla, con el nombre y el valor de la variable en una columna, y los objetivos afectados en la otra.

Implementar parámetros y valores que se muestran en la consola de Google Cloud

¿Qué sigue?