Desplegar en varios destinos al mismo tiempo

Con Cloud Deploy, puedes implementar en un destino configurado para representar varios destinos, y tu aplicación se implementa en esos destinos en paralelo (simultáneamente). El objetivo que identificas como una fase de tu canal se denomina objetivo múltiple, y los objetivos que lo componen se denominan objetivos secundarios.

Puedes usar la implementación paralela con cualquier tipo de destino que admita Cloud Deploy.

Por qué usar el despliegue paralelo

Puedes usar la implementación paralela, por ejemplo, para desplegar tu aplicación en varios destinos de producción. En este caso, no es necesario que implementes en cada destino sucesivamente, ya que no hay ninguna progresión (por ejemplo, de desarrollo a preproducción y a producción).

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

Recursos de Cloud Deploy usados para el despliegue paralelo

El despliegue paralelo utiliza los siguientes recursos especializados de Cloud Deploy:

  • multiobjetivo

    Un multitarget es un target que se configura con la propiedad multiTarget en el nivel superior del archivo YAML de configuración del target y, en lugar de hacer referencia al clúster o al servicio de tiempo de ejecución, hace referencia a uno o varios targets mediante multiTarget.targetIds.

  • Objetivos secundarios

    Un objetivo secundario es cualquier objetivo al que haga referencia un objetivo múltiple como multiTarget.targetIds.

  • Lanzamientos controlados

    Un lanzamiento de 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 hacer y lo que no con un lanzamiento secundario.

Configurar el despliegue paralelo

La configuración de la implementación paralela consiste en definir un elemento de destino múltiple y el número de elementos de destino secundarios que necesites (hasta el límite). Las definiciones de los objetivos son las mismas que las de todos los objetivos, excepto en los siguientes casos:

  • Los anuncios multiobjetivo incluyen la propiedad multiTarget.
  • Los elementos secundarios no incluyen la propiedad multiTarget, pero se hace referencia a ellos desde el elemento de destino múltiple mediante la propiedad multiTarget.targetIds.
  • Puedes configurar la segmentación múltiple para la aprobación, pero no los objetivos secundarios, que no pueden incluir requireApproval:true.

Los elementos de destino múltiples y los elementos de destino secundarios pueden incluir configuraciones de entorno de ejecución personalizadas. Si un elemento secundario de destino no especifica un entorno de ejecución, hereda el definido en la definición de varios destinos o el predeterminado. Para obtener más información, consulta Entornos de ejecución e implementación paralela.

Configurar el multiobjetivo

Un multitarget es un único target identificado como una fase de tu canal de distribución, pero que apunta a uno o varios targets secundarios.

La configuración multiobjetivo incluye la propiedad multiTarget. Una multitarget no puede tener las propiedades gke, run ni anthosCluster. La configuración de un multitarget es la misma independientemente del tiempo de ejecución en el que se implemente.

En el archivo YAML de tu flujo de procesamiento de entrega o en un archivo YAML independiente, crea la definición básica del destino, incluido 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 archivo YAML...

  • TARGET_NAME es el nombre de este multitarget, que se usa en la propiedad stages.targetId de la definición del flujo de procesamiento de entrega.

  • CHILD_TARGET1, CHILD_TARGET2,...CHILD_TARGETn son los nombres de los elementos de destino secundarios a los que se implementa este elemento de destino múltiple. Cada nombre corresponde a la propiedad name de la definición de destino secundario.

La presencia de la propiedad multiTarget.targetIds hace que este destino sea un destino múltiple.

Configurar los objetivos secundarios

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

En el archivo YAML de tu flujo de procesamiento de entrega o en otro archivo YAML, 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 archivo YAML...

  • CHILD_TARGET1 es el nombre de este elemento secundario de destino. El nombre corresponde a uno de los miembros de la lista de objetivos de la propiedad multiTarget.targetIds de la definición de varios objetivos.

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

Este destino se configura igual que un destino estándar de GKE. Lo único que hace que sea un elemento de destino secundario es que la propiedad multiTarget.targetIds del elemento de destino múltiple haga 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 archivo YAML...

  • CHILD_TARGET1 es el nombre de este elemento secundario de destino. El nombre corresponde a uno de los miembros de la lista de objetivos de la propiedad multiTarget.targetIds de la definición de varios objetivos.

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

Este destino se configura igual que un destino estándar de Cloud Run. Lo único que hace que sea un elemento de destino secundario es que se hace referencia a él mediante la propiedad multiTarget.targetIds en el elemento de destino múltiple.

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 archivo YAML...

Segmentación personalizada 

apiVersion: deploy.cloud.google.com/v1
kind: Target
metadata:
 name: CHILD_TARGET1
description: TARGET_DESCRIPTION
customTarget:
  customTargetType: CUSTOM_TARGET_TYPE_NAME

En este archivo YAML...

Transferir parámetros de implementación a los destinos

Puede diferenciar entre los elementos secundarios de destino incluyendo parámetros en el manifiesto y valores en la definición de la canalización de entrega. Esos valores se pueden aplicar por separado a los manifiestos correspondientes, en función de la coincidencia de etiquetas en los elementos de destino correspondientes.

Por ejemplo, puede que quieras un número de réplicas diferente para cada elemento secundario. Para ello, debe incluir los parámetros y los valores en la progresión de la canalización de entrega, así como etiquetas en los elementos secundarios de destino para que coincidan con cada par de parámetro y valor.

Más información sobre los parámetros de implementación

Crear la versión

Una vez que hayas configurado los objetivos multiobjetivo y los objetivos secundarios, crea el flujo de procesamiento de entrega y los recursos de destino y, a continuación, crea una versión, como de costumbre.

El ciclo de vida de la canalización de entrega es el mismo que el de cualquier canalización y destino de Cloud Deploy, excepto que, cuando llega a la fase con el multiobjetivo, Cloud Deploy crea un lanzamiento de controlador para el multiobjetivo y un lanzamiento secundario para desplegar la aplicación en cada destino secundario.

Los mensajes de Pub/Sub en respuesta a las operaciones de Cloud Deploy distinguen entre los lanzamientos de la controladora y los lanzamientos secundarios.

Limitaciones

  • Un multitarget no puede tener más de 100 elementos secundarios.

  • Todos los elementos secundarios de un elemento de destino múltiple deben tener el mismo tiempo de ejecución de destino (por ejemplo, todos deben ser GKE o GKE Enterprise).

  • En un flujo de procesamiento de entrega, un destino secundario solo puede tener un destino principal.

  • Un elemento de segmentación múltiple no puede no tener elementos secundarios y no puede hacer referencia a sí mismo ni a otro elemento de segmentación múltiple como elemento secundario.

  • No puedes usar un elemento secundario de segmentación más de una vez en una misma cadena de publicación, pero sí puedes reutilizarlo en cadenas diferentes.

  • Si los elementos secundarios son segmentaciones personalizadas, todos deben hacer referencia al mismo CustomTargetType.

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

    Cuando implementas una compilación en varios destinos, todas las implementaciones secundarias se implementan al mismo tiempo, hasta alcanzar el límite de simultaneidad de Cloud Build. Si tiene más de ese límite de destinos secundarios, los trabajos de implementación de algunos destinos no se ejecutarán hasta que finalicen otros, lo que significa que Cloud Deploy no se implementará en todos los destinos secundarios al mismo tiempo en este caso.

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

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

Entornos de ejecución y despliegue paralelo

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

  • Si el elemento de destino múltiple tiene un entorno de ejecución no predeterminado, todos los elementos de destino secundarios que usen el entorno de ejecución predeterminado heredarán el no predeterminado del elemento de destino múltiple.

  • Si el elemento de destino múltiple usa el entorno de ejecución predeterminado, cualquier elemento de destino secundario que esté configurado con un entorno de ejecución no predeterminado usará ese entorno no predeterminado.

Estas reglas facilitan la propagación de entornos de ejecución a los elementos de destino secundarios desde un elemento de destino múltiple, por lo que no tienes que definir ni cambiar el entorno de ejecución de cada elemento de destino secundario, pero puedes personalizar el entorno de ejecución de uno o varios elementos de destino secundarios si lo necesitas.

Consulta Usar entornos de ejecución de Cloud Deploy para obtener más información sobre los entornos de ejecución en Cloud Deploy.

Revertir un despliegue paralelo

Si necesitas restaurar una implementación de varios destinos paralelos, consulta la sección Restaurar un destino.

Aprobaciones para la implementación paralela

Al igual que con cualquier otro objetivo, 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 multitarget. La aprobación o el rechazo afectan a todos los destinos secundarios a la vez.

Ver el despliegue paralelo en la consola de Google Cloud

Puedes ver los detalles de tus segmentaciones múltiples, segmentaciones secundarias, lanzamiento de la versión del controlador y lanzamientos de la versión secundarios en la Google Cloud consola.

Cuando ve la lista de destinos de una determinada canalización de entrega, en Detalles de la canalización de entrega, se muestra el destino múltiple, pero no los destinos secundarios. Sin embargo, cuando veas los detalles de la versión, podrás ver el lanzamiento del controlador y los lanzamientos secundarios. También puede ver las implementaciones de controladores y secundarias en la pestaña Implementaciones de la página de detalles de la canalización de distribución.

En el inspector de lanzamientos, puede ver y comparar los manifiestos renderizados de los lanzamientos secundarios.

Usar el despliegue paralelo con una estrategia de despliegue

Puedes implementar en paralelo cuando uses una estrategia de implementación canary. Para obtener más información, consulta Usar la implementación paralela con una estrategia de implementación canary.

Siguientes pasos