Acerca de las segmentaciones personalizadas

En este documento, se describe cómo funcionan los destinos personalizados en Cloud Deploy.

Cloud Deploy incluye compatibilidad integrada para varios entornos de ejecución como destinos. Sin embargo, la lista de tipos de destino compatibles es finita. Con los destinos personalizados, puedes implementar en otros sistemas además de los tiempos de ejecución compatibles.

Un destino personalizado es un destino que representa un entorno de salida arbitrario además de un entorno de ejecución que admite Cloud Deploy.

En la página Cómo crear un objetivo personalizado, se describe el proceso para definir un tipo de objetivo personalizado y, luego, implementarlo como objetivo en una canalización de entrega.

¿Qué se incluye en un objetivo personalizado?

Cada segmentación personalizada consta de los siguientes componentes:

  • Acciones personalizadas, definidas en skaffold.yaml

    Son similares a la forma en que defines los hooks de implementación. En el archivo skaffold.yaml, defines customActions, en el que cada acción personalizada identifica una imagen de contenedor para usar y los comandos que se ejecutarán en ese contenedor.

    De esta manera, el objetivo personalizado es simplemente una acción o un conjunto de acciones definidas por el usuario.

    Para cualquier tipo de destino personalizado, debes configurar una acción de renderización personalizada y una acción de implementación personalizada. Estas acciones consumen valores proporcionados por Cloud Deploy y deben cumplir con un conjunto de resultados obligatorios.

    La acción de renderización personalizada es opcional, pero debes crear una, a menos que tu objetivo personalizado funcione correctamente si lo renderiza skaffold render, que es la opción predeterminada de Cloud Deploy.

  • Una definición de tipo de segmentación personalizada

    CustomTargetType es un recurso de Cloud Deploy que identifica las acciones personalizadas (definidas por separado en tu skaffold.yaml) que los destinos de este tipo usan para las actividades de renderización de lanzamientos y de implementación de lanzamientos.

  • Una definición de objetivo

    La definición de un objetivo personalizado es la misma que la de cualquier tipo de objetivo, excepto que incluye la propiedad customTarget, cuyo valor es el nombre de CustomTargetType.

Con esos componentes, puedes usar el objetivo como lo harías con cualquier otro, haciendo referencia a él desde la progresión de tu canalización de lanzamiento y aprovechando todas las funciones de Cloud Deploy, como promociones y aprobaciones, y reversiones.

Ejemplo

En la guía de inicio rápido Define y usa un tipo de destino personalizado, se crea un tipo de destino personalizado que incluye comandos simples para ejecutar en una imagen de contenedor: un comando para la renderización y otro para la implementación. En este caso, los comandos solo agregan texto a los archivos de salida necesarios para la renderización y la implementación.

Para ver más ejemplos, consulta Ejemplos de segmentación personalizada.

Entradas y salidas requeridas

Cualquier tipo de destino personalizado definido para Cloud Deploy debe satisfacer los requisitos de entrada y salida, tanto para la renderización como para la implementación. En esta sección, se enumeran las entradas y salidas requeridas y cómo se proporcionan.

Cloud Deploy proporciona las entradas necesarias, tanto para la renderización como para la implementación, como variables de entorno. En las siguientes secciones, se enumeran estas entradas, así como los resultados que deben mostrar tus acciones de renderización e implementación personalizadas.

Cómo implementar parámetros como variables de entorno

Además de las variables de entorno que se enumeran en esta sección, Cloud Deploy puede pasar a tus contenedores personalizados cualquier parámetro de implementación que hayas establecido.

Obtén más información.

Entradas para renderizar acciones

Para las acciones de renderización personalizadas, Cloud Deploy proporciona las siguientes entradas requeridas como variables de entorno. En el caso de los lanzamientos de varias fases (implementaciones Canary), Cloud Deploy proporciona estas variables para cada fase.

  • CLOUD_DEPLOY_PROJECT

    Es el proyecto de Google Cloud en el que se crea el tipo de objetivo personalizado.

  • CLOUD_DEPLOY_LOCATION

    La región de Google Cloud para el tipo de segmentación personalizada.

  • CLOUD_DEPLOY_DELIVERY_PIPELINE

    Es el nombre de la canalización de entrega de Cloud Deploy que hace referencia al tipo de segmentación personalizada.

  • CLOUD_DEPLOY_RELEASE

    Es el nombre de la versión para la que se invoca la operación de renderización.

  • CLOUD_DEPLOY_TARGET

    Es el nombre del destino de Cloud Deploy que usa el tipo de destino personalizado.

  • CLOUD_DEPLOY_PHASE

    La fase de lanzamiento a la que corresponde la renderización.

  • CLOUD_DEPLOY_REQUEST_TYPE

    Para la acción de renderización personalizada, siempre es RENDER.

  • CLOUD_DEPLOY_FEATURES

    Es una lista separada por comas de las funciones de Cloud Deploy que debe admitir el contenedor personalizado. Esta variable se propaga en función de las funciones configuradas en tu canalización de publicación.

    Si tu implementación no admite las funciones de esta lista, te recomendamos que falle durante la renderización.

    En el caso de las implementaciones estándar, esta opción está vacía. Para las implementaciones Canary, el valor es CANARY. Si el valor que proporciona Cloud Deploy es CANARY, se invoca tu acción de renderización para cada fase del canario. El porcentaje Canary para cada fase se proporciona en la variable de entorno CLOUD_DEPLOY_PERCENTAGE_DEPLOY.

  • CLOUD_DEPLOY_PERCENTAGE_DEPLOY

    Es el porcentaje de implementación asociado con esta operación de renderización. Si la variable de entorno CLOUD_DEPLOY_FEATURES está configurada en CANARY, se llama a tu acción de renderización personalizada para cada fase, y esta variable se establece en el porcentaje Canary para cada fase. Para las implementaciones estándar y las implementaciones Canary que alcanzaron la fase stable, este es 100.

  • CLOUD_DEPLOY_STORAGE_TYPE

    El proveedor de almacenamiento Siempre GCS.

  • CLOUD_DEPLOY_INPUT_GCS_PATH

    Es la ruta de Cloud Storage del archivo de renderización que se escribió cuando se creó la versión.

  • CLOUD_DEPLOY_OUTPUT_GCS_PATH

    Es la ruta de Cloud Storage en la que se espera que el contenedor de renderización personalizado suba los artefactos que se usarán para la implementación. Ten en cuenta que la acción de renderización debe subir un archivo llamado results.json que contenga los resultados de esta operación de renderización. Para obtener más información, consulta Resultados de la acción de renderización.

Resultados de la acción de renderización

Tu acción de renderización personalizada debe proporcionar la información que se describe en esta sección. La información se debe incluir en el archivo de resultados, llamado results.json, que se encuentra en el bucket de Cloud Storage que proporciona Cloud Deploy.

  • Archivos de configuración renderizados

  • Un archivo results.json que contenga la siguiente información:

    • Es una indicación del estado de éxito o falla de la acción personalizada.

      Los valores válidos son SUCCEEDED y FAILED.

    • (Opcional) Cualquier mensaje de error que genere la acción personalizada.

    • La ruta de acceso de Cloud Storage para los archivos de configuración renderizados.

      La ruta de acceso de todos los archivos de configuración renderizados es el URI completo. Puedes propagarla en parte con el valor de CLOUD_DEPLOY_OUTPUT_GCS_PATH que proporciona Cloud Deploy.

      Debes proporcionar el archivo de configuración renderizado, incluso si está vacío. El contenido del archivo puede ser cualquier cosa, en cualquier formato, siempre que tu acción de implementación personalizada pueda consumirlo. Recomendamos que este archivo sea legible por humanos, de modo que tú y otros usuarios de tu organización puedan verlo en el inspector de lanzamientos.

    • (Opcional) Un mapa de los metadatos que quieras incluir

      Tu segmentación personalizada crea estos metadatos. Estos metadatos se almacenan en la versión, en el campo custom_metadata.

Si necesitas examinar el archivo results.json, por ejemplo, para depurar, puedes encontrar el URI de Cloud Storage en los registros de Cloud Build.

Ejemplo de archivo de resultados de renderización

El siguiente es un resultado de archivo results.json de muestra de una acción de renderización personalizada:

{
  "resultStatus": "SUCCEEDED",
  "manifestFile": "gs://bucket/my-pipeline/release-001/rollout-a/01234/custom-output/manifest.yaml",
  "failureMessage": "",
  "metadata": {
    "key1": "val",
    "key2": "val"
  }
}

Entradas para implementar acciones

En el caso de las acciones de implementación personalizadas, Cloud Deploy proporciona las siguientes entradas obligatorias, como variables de entorno:

  • CLOUD_DEPLOY_PROJECT

    Es el proyecto de Google Cloud en el que se crea el objetivo personalizado.

  • CLOUD_DEPLOY_LOCATION

    La región de Google Cloud para el tipo de segmentación personalizada.

  • CLOUD_DEPLOY_DELIVERY_PIPELINE

    Es el nombre de la canalización de publicación de Cloud Deploy que hace referencia al objetivo que usa el tipo de segmentación personalizado.

  • CLOUD_DEPLOY_RELEASE

    Es el nombre de la versión para la que se invoca la operación de implementación.

  • CLOUD_DEPLOY_ROLLOUT

    Es el nombre del lanzamiento de Cloud Deploy para el que se realiza esta implementación.

  • CLOUD_DEPLOY_TARGET

    Es el nombre del destino de Cloud Deploy que usa el tipo de destino personalizado.

  • CLOUD_DEPLOY_PHASE

    La fase de lanzamiento a la que corresponde la implementación.

  • CLOUD_DEPLOY_REQUEST_TYPE

    Para la acción de implementación personalizada, siempre es DEPLOY.

  • CLOUD_DEPLOY_FEATURES

    Es una lista separada por comas de las funciones de Cloud Deploy que debe admitir el contenedor personalizado. Esta variable se propaga en función de las funciones configuradas en tu canalización de publicación.

    Si tu implementación no admite las funciones de esta lista, te recomendamos que falle durante la renderización.

    En el caso de las implementaciones estándar, esta opción está vacía. Para las implementaciones Canary, el valor es CANARY. Si el valor que proporciona Cloud Deploy es CANARY, se invoca tu acción de renderización para cada fase del canario. El porcentaje Canary para cada fase se proporciona en la variable de entorno CLOUD_DEPLOY_PERCENTAGE_DEPLOY.

  • CLOUD_DEPLOY_PERCENTAGE_DEPLOY

    Es el porcentaje de implementación asociado con esta operación de implementación. Si la variable de entorno CLOUD_DEPLOY_FEATURES se establece en CANARY, se llama a tu acción de implementación personalizada para cada fase, y esta variable se establece en el porcentaje Canary para cada fase. La acción de implementación debe ejecutarse para cada fase.

  • CLOUD_DEPLOY_STORAGE_TYPE

    El proveedor de almacenamiento Siempre GCS.

  • CLOUD_DEPLOY_INPUT_GCS_PATH

    La ruta de Cloud Storage en la que el renderizador personalizado escribió los archivos de configuración renderizados

  • CLOUD_DEPLOY_SKAFFOLD_GCS_PATH

    Es la ruta de acceso de Cloud Storage a la configuración renderizada de Skaffold.

  • CLOUD_DEPLOY_MANIFEST_GCS_PATH

    La ruta de Cloud Storage al archivo de manifiesto renderizado.

  • CLOUD_DEPLOY_OUTPUT_GCS_PATH

    Es la ruta de acceso al directorio de Cloud Storage en el que se espera que el contenedor de implementación personalizado suba artefactos de implementación. Para obtener más información, consulta Resultados de la acción de implementación.

Resultados de la acción de implementación

Tu acción de implementación personalizada debe escribir un archivo de salida results.json. Este archivo debe estar ubicado en el bucket de Cloud Storage que proporciona Cloud Deploy (CLOUD_DEPLOY_OUTPUT_GCS_PATH).

El archivo debe incluir lo siguiente:

  • Es una indicación del estado de éxito o falla de la acción de implementación personalizada.

    Los siguientes son los estados válidos:

    • SUCCEEDED

    • FAILED

    • SKIPPED (para implementaciones de versiones canary en las que se omiten las fases de canary para ir directamente a stable).

  • (Opcional) Una lista de archivos de artefactos de implementación, en forma de rutas de acceso de Cloud Storage

    La ruta es el URI completo. La propagas en parte con el valor de CLOUD_DEPLOY_OUTPUT_GCS_PATH que proporciona Cloud Deploy.

    Los archivos que se enumeran aquí se propagan en los recursos de ejecución de trabajos como artefactos de implementación.

  • Un mensaje de error (opcional) si la acción de implementación personalizada no se realiza correctamente (muestra un estado FAILED)

    Este mensaje se usa para propagar el failure_message en la ejecución de trabajo para esta acción de implementación.

  • Un mensaje de omisión (opcional) para proporcionar información adicional si la acción muestra un estado SKIPPED

  • (Opcional) Un mapa de los metadatos que quieras incluir

    Tu segmentación personalizada crea estos metadatos. Estos metadatos se almacenan en la ejecución de trabajo y en el lanzamiento, en el campo custom_metadata.

Si necesitas examinar el archivo results.json, por ejemplo, para depurar, puedes encontrar el URI de Cloud Storage en los registros de renderización de lanzamientos de Cloud Build.

Ejemplo de archivo de resultados de implementación

El siguiente es un resultado de archivo results.json de muestra de una acción de implementación personalizada:

{
  "resultStatus": "SUCCEEDED",
  "artifactFiles": [
    "gs://bucket/my-pipeline/release-001/rollout-a/01234/custom-output/file1.yaml",
    "gs://bucket/my-pipeline/release-001/rollout-a/01234/custom-output/file2.yaml"
  ],
  "failureMessage": "",
  "skipMessage": "",
  "metadata": {
    "key1": "val",
    "key2": "val"
  }
}

Más información sobre las acciones personalizadas

A continuación, se incluyen algunos aspectos que debes tener en cuenta cuando configures y uses tipos de segmentación personalizados.

Cómo ejecutar las acciones personalizadas

Tus acciones de renderización e implementación personalizadas se ejecutan en el entorno de ejecución de Cloud Deploy. No puedes configurar tus acciones personalizadas para que se ejecuten en un clúster de Google Kubernetes Engine.

Cómo usar parámetros de configuración remotos y reutilizables de Skaffold

Como se describe en este documento, debes configurar tu acción personalizada en el archivo skaffold.yaml que se proporciona cuando se crea la versión. Sin embargo, también puedes almacenar configuraciones de Skaffold en un repositorio de Git o en un bucket de Cloud Storage, y hacer referencia a ellas desde tu definición de tipo de destino personalizado. Esto te permite usar acciones personalizadas definidas y almacenadas en una sola ubicación compartida, en lugar de incluirlas con el archivo skaffold.yaml de cada versión.

Objetivos y estrategias de implementación personalizados

Los destinos personalizados son totalmente compatibles con las implementaciones estándares.

Cloud Deploy admite implementaciones de versiones canary, siempre que el renderizador y el implementador personalizados admitan la función canary.

Debes usar la configuración canary personalizada. No se admiten canarios automáticos ni personalizados.

Destinos personalizados y parámetros de implementación

Puedes usar los parámetros de implementación con objetivos personalizados. Puedes configurarlos en la etapa de la canalización de publicación, en el objetivo que usa un tipo de objetivo personalizado o en la versión.

Los parámetros de implementación se pasan a tus contenedores de renderización y de implementación personalizados, como variables de entorno, además de los que ya se proporcionaron.

Ejemplos de segmentación personalizada

El repositorio cloud-deploy-samples contiene un conjunto de implementaciones de destinos personalizados de muestra. Los siguientes ejemplos están disponibles:

  • GitOps

  • Vertex AI

  • Terraform

  • Infrastructure Manager

  • Helm

Cada ejemplo incluye una guía de inicio rápido.

Estos ejemplos no son productos de Google Cloud compatibles y no están cubiertos por un contrato de asistencia de Google Cloud. Para informar errores o solicitar funciones en un producto de Google Cloud, comunícate con el equipo de asistencia de Google Cloud.

¿Qué sigue?