Implementa en varios destinos al mismo tiempo

Con Cloud Deploy, puedes implementar en un destino que está configurado para representar varios destinos, y tu aplicación se implementa en esos destinos en paralelo (de forma simultánea). El destino que identificas como etapa en tu canalización es llamado múltiples objetivos, y los destinos que comprenden varios destinos se denominan destinos secundarios.

Puedes usar la implementación paralela con cualquier tipo de destino que Cloud Deploy admite, incluidos Google Kubernetes Engine, Cloud Run y GKE Enterprise.

¿Por qué implementar en paralelo?

Puedes usar la implementación en paralelo, por ejemplo, para implementar tu aplicación en varios destinos de producción. En este caso, no es necesario que implementes objetivo en sucesión, porque no hay progresión (por ejemplo, de dev a de etapa de pruebas a producción).

Esta implementación paralela puede ser parte de una canalización de entrega normal progresión:
dev -> staging -> prod [prod1, prod2, prod3, prod4, ...]

Recursos de Cloud Deploy que se usan para implementaciones en paralelo

La implementación en paralelo usa la siguiente infraestructura especializada recursos:

  • varios destinos

    Un destino múltiple es aquel que se configura con la propiedad multiTarget. en el nivel superior del YAML de configuración de destino y, en lugar de hacer referencia al de entorno de ejecución o servicio, hace referencia a uno o más destinos, con multiTarget.targetIds

  • Destinos secundarios

    Un destino secundario es cualquier destino al que hace referencia un destino múltiple como multiTarget.targetIds. El elemento secundario también debe hacer referencia a un tipo de destino compatible (Google Kubernetes Engine, GKE Enterprise o Cloud Run).

  • Lanzamientos de controladores

    Un lanzamiento del controlador es un lanzamiento que corresponde al multiobjetivo.

    Consulta Limitaciones para obtener más información sobre lo que puedes hacer y lo que no con un lanzamiento de controlador.

  • Lanzamientos secundarios

    Consulta Limitaciones para obtener más información sobre lo que puedes y no puedes hacer con un lanzamiento secundario.

Configura la implementación en paralelo

Configurar una implementación paralela consiste en definir un destino múltiple y la cantidad de destinos secundarios que necesitas (hasta el límite). Objetivo son las mismas que las de todos los destinos, excepto por los siguientes:

  • Los múltiples destinos incluyen la propiedad multiTarget.
  • Los destinos secundarios no incluyen la propiedad multiTarget, pero se hace referencia a ellos del destino múltiple con la propiedad multiTarget.targetIds.
  • Puedes configurar los destinos múltiples para su aprobación, pero no los destinos secundarios. que no pueden incluir requireApproval:true.

Los destinos múltiples y secundarios pueden incluir entorno de ejecución parámetros de configuración. Si un destino secundario no especifica un entorno de ejecución, hereda el que se define en la definición de varios destinos o el predeterminado. Consulta Implementación en paralelo y entornos de ejecución para obtener más información.

Configura la segmentación multiobjetivo

Un destino múltiple es un solo destino identificado como una etapa en tu canalización de entrega, pero que apunta a uno o más destinos secundarios.

La configuración de varios objetivos incluye la propiedad multiTarget. Un segmento multiobjetivo no puede tener las propiedades gke, run ni anthosCluster. La configuración de un destino múltiple es la misma, independientemente del entorno de ejecución la implementación.

En el archivo YAML de tu canalización de entrega o en un archivo YAML independiente, crea la definición de destino básica, incluida multiTarget:

apiVersion: deploy.cloud.google.com/v1
kind: Target
metadata:
 name: TARGET_NAME
description: TARGET_DESCRIPTION
multiTarget:
 targetIds: [ CHILD_TARGET1, CHILD_TARGET2, CHILD_TARGETn ]

En este YAML…

  • TARGET_NAME es el nombre de este multiobjetivo, que se usa en la definición de la canalización de entrega, la propiedad stages.targetId.

  • CHILD_TARGET1, CHILD_TARGET2,...CHILD_TARGETn son las los nombres de los destinos secundarios en los que se implementan estos destinos múltiples. Cada nombre corresponde a la propiedad name en la definición del destino secundario.

La presencia de la propiedad multiTarget.targetIds hace que este objetivo sea multiobjetivo.

Configura los destinos secundarios

Para cada objetivo identificado como secundario en tu configuración de varios destinos, configura otro objetivo como secundario:

En el archivo YAML de la canalización de entrega o en un archivo YAML independiente, crea la definición de destino básica:

GKE 

apiVersion: deploy.cloud.google.com/v1
kind: Target
metadata:
 name: CHILD_TARGET1
description: TARGET_DESCRIPTION
gke:
 cluster: projects/PROJECT_ID/locations/REGION/clusters/CLUSTER_NAME

En este YAML...

  • CHILD_TARGET1 es el nombre de este destino secundario. El nombre corresponde a un miembro de la lista de destinos en la propiedad multiTarget.targetIds en la definición de varios objetivos.

  • El valor de la propiedad gke.cluster es el nombre del recurso del clúster. al que hace referencia este destino, incluido el ID del proyecto, la región y el clúster de la fuente de datos.

Este destino se configura de la misma manera que un destino estándar de GKE. Lo único que hace que este sea un destino secundario es que la propiedad multiTarget.targetIds en el destino múltiple hace referencia a él.

Cloud Run

apiVersion: deploy.cloud.google.com/v1
kind: Target
metadata:
 name: CHILD_TARGET1
description: TARGET_DESCRIPTION
run:
 location: projects/PROJECT_ID/locations/REGION

En este YAML...

  • CHILD_TARGET1 es el nombre de este destino secundario. El nombre corresponde a un miembro de la lista de destinos en la propiedad multiTarget.targetIds en la definición de varios destinos.

  • El valor de la propiedad run.location es el nombre del recurso del servicio de Cloud Run al que hace referencia este objetivo, incluido el ID del proyecto y la región.

Este destino se configura de la misma manera que un destino estándar de Cloud Run. Lo único que hace de este un destino secundario es que se hace referencia por la propiedad multiTarget.targetIds en varios destinos.

GKE Enterprise 

apiVersion: deploy.cloud.google.com/v1
kind: Target
metadata:
 name: CHILD_TARGET1
description: TARGET_DESCRIPTION
anthosCluster:
 membership: projects/PROJECT_ID/locations/global/memberships/MEMBERSHIP_NAME

En este YAML…

Este objetivo se configura de la misma manera que un objetivo estándar de GKE Enterprise. Lo único que hace de este un destino secundario es que se hace referencia por la propiedad multiTarget.targetIds en varios destinos.

Pasa parámetros de implementación a los destinos

Puedes diferenciar entre los objetivos secundarios si incluyes parámetros en tu manifiesto y valores en la definición de tu canalización de publicación. Esos valores pueden ser se aplican por separado al manifiestos separados, según la coincidencia de etiquetas en los destinos correspondientes.

Por ejemplo, es posible que desees una cantidad diferente de réplicas para cada objetivo secundario. Para ello, debes incluir los parámetros y los valores en la progresión de la canalización de publicación, junto con las etiquetas en los objetivos secundarios para que coincidan con cada par de valores del parámetro.

Obtén más información sobre los parámetros de implementación.

Crea la versión

Con los destinos múltiples y secundarios configurados, crea la canalización de entrega y los recursos de destino y, luego, crea una versión como de costumbre.

El ciclo de vida de la canalización de entrega es el mismo que y destinos de Cloud Deploy, excepto que cuando llega a de destino con múltiples destinos, Cloud Deploy crea un controlador para el destino múltiple y un lanzamiento secundario para implementar la aplicación para cada destino secundario.

Mensajes de Pub/Sub en respuesta a operaciones de Cloud Deploy para distinguir entre lanzamientos de controladores y lanzamientos secundarios.

Limitaciones

  • Un destino múltiple no puede tener más de 100 destinos secundarios.

  • Todos los destinos secundarios de un único destino múltiple deben tener el mismo entorno de ejecución. (por ejemplo, todos GKE o GKE Enterprise).

  • Dentro de una canalización de entrega, un destino secundario solo puede tener un destino múltiple superior.

  • Un destino múltiple no puede no tener destinos secundarios, ni puede hacer referencia a sí mismo ni a otro destino múltiple como destinos secundarios.

  • No puedes usar un destino secundario más de una vez en una sola canalización de entrega, pero puedes volver a usarlo en una canalización diferente.

  • Los grupos predeterminados tienen de simultaneidad, pero los grupos privados no.

    Cuando realizas una implementación en varios destinos, todos los lanzamientos secundarios se implementan al mismo tiempo, hasta el límite de simultaneidad de Cloud Build. Si tienes más destinos secundarios que ese límite, las tareas de implementación de algunos destinos no se ejecutarán hasta que finalicen otros, lo que significa que, en este caso, Cloud Deploy no se implementará en todos los destinos secundarios al mismo tiempo.

    Además, si los destinos incluyen trabajos de verificación, es posible que uno o más de esos trabajos de verificación comiencen antes de que la aplicación se haya implementado en todos los destinos secundarios.

    Si necesitas implementar de forma simultánea en más destinos que el límite especificado en la documentación de Cloud Build, tienes dos opciones:

Entornos de ejecución y la implementación en paralelo

Cada destino se puede configurar para usar un entorno de ejecución no predeterminado.

  • Si el destino múltiple tiene un entorno de ejecución no predeterminado, todos los destinos secundarios que usan el entorno de ejecución predeterminado heredan el no predeterminado del destino múltiple.

  • Si el destino múltiple usa el entorno de ejecución predeterminado, cualquier destino secundario configurada con un entorno de ejecución no predeterminado, usa ese no predeterminada.

Estas reglas facilitan la propagación de entornos de ejecución a destinos secundarios desde un destino múltiple, por lo que no tienes que definir ni cambiar el entorno de ejecución para cada destino secundario, y aún puedes personalizar el entorno de ejecución para uno o más destinos secundarios si lo necesitas.

Consulta Cómo usar los entornos de ejecución de Google Cloud Deploy para obtener más información sobre los entornos de ejecución en Cloud Deploy.

Revierte una implementación paralela

Si necesitas revertir un objeto Deployment desde múltiples destinos paralelos, Revierte el destino múltiple, como se describe en Revierte un objetivo.

Aprobaciones para la implementación en paralelo

Al igual que con cualquier destino, puedes configurar tu implementación paralela para que requiera aprobaciones. Sin embargo, con la implementación paralela, solo puedes configurar la aprobación en el con varios destinos. La aprobación o el rechazo afectan a todos los objetivos secundarios en conjunto.

Ver la implementación paralela en la consola de Google Cloud

Puedes ver los detalles de tus destinos múltiples, los destinos secundarios, el lanzamiento del controlador y los lanzamientos secundarios en la consola de Google Cloud.

Cuando veas la lista de destinos para una canalización de entrega determinada, en la sección Publicación En los detalles de la canalización, se muestran los destinos múltiples, pero no los destinos secundarios. Sin embargo, cuando ves los detalles de la versión, puedes ver el lanzamiento del controlador y los lanzamientos secundarios. También puedes ver los lanzamientos del controlador y de los elementos secundarios en la pestaña Lanzamientos de la página de detalles de la canalización de entrega.

En el inspector de versiones, puedes ver y comparar manifiestos renderizados para lanzamientos secundarios.

Usa la implementación paralela con una estrategia de implementación

Puedes implementar en paralelo cuando usas un estrategia de implementación de versiones canary. Consulta Cómo usar la implementación en paralelo con una estrategia de implementación Canary para obtener más información.

¿Qué sigue?