Arquitectura del servicio de Cloud Deploy

En este documento, se describen las relaciones entre Cloud Deploy y los sistemas externos con los que funciona para implementar tus aplicaciones. Estos sistemas son otros servicios de Google Cloud y herramientas de terceros.

La vista de alto nivel

En el siguiente diagrama, se muestran las relaciones entre Cloud Deploy y los sistemas independientes en los que se basa.

Como se muestra en este diagrama, Cloud Deploy interactúa con los siguientes sistemas:

• Tu sistema de CI

  Cloud Deploy admite la mayoría de las herramientas de CI, siempre que un resultado de tu proceso de CI pueda llamarse a la API o la CLI de Cloud Deploy para crear una versión.

• Cloud Build

  Cloud Deploy llama a Cloud Build para renderizar tus manifiestos y, luego, implementarlos en el entorno de ejecución de destino.

• Skaffold

  Cloud Deploy usa Skaffold a través de Cloud Build para renderizar y, luego, implementar tus manifiestos, lo que permite implementar tu aplicación.

• Cloud Storage

  Cloud Deploy almacena la fuente de renderización y los manifiestos renderizados en un bucket de Cloud Storage.

• Google Cloud Observability y los Registros de auditoría de Cloud.

  Google Cloud Observability recopila y pone a disposición los datos de registro de Cloud Deploy.

  Consulta también Registros de auditoría.

• Pub/Sub

  Cloud Deploy publica mensajes en varios temas de Pub/Sub. Puedes usar este servicio para integrar flujos de trabajo, pruebas y otros sistemas relacionados externos.

  Consulta Cómo suscribirse a las notificaciones de Cloud Deploy para obtener más información.

• Entorno de ejecución objetivo

  Cloud Deploy usa skaffold apply, a través de Cloud Build, para implementar tus aplicaciones en el entorno de ejecución objetivo (GKE o GKE Enterprise).

Recursos de Cloud Deploy

En el siguiente diagrama, se muestran los recursos que usa Cloud Deploy para entregar tus aplicaciones y las relaciones entre esos recursos:

Como se muestra en este diagrama, las relaciones entre los recursos son las siguientes:

• La canalización de entrega puede generar cero o más versiones, y puede hacer referencia a uno o más destinos, incluidos los destinos múltiples y sus destinos secundarios asociados.

• La canalización de publicación también puede hacer referencia a uno o más automatizaciones, que automatizan las acciones en recursos de Cloud Deploy.

• Cada versión incluye la instancia de canalización, una “instantánea” de la canalización de entrega y los destinos tal como se configuraron cuando se creó la versión.

• Cada versión puede generar cero o más lanzamientos y puede hacer referencia a cero o más artefactos.

  Cada lanzamiento incluye al menos una fase, que representa una colección de operaciones (tareas) en un lanzamiento que se agrupan de forma lógica, por ejemplo, una implementación o una implementación y verificación.

  Cada fase incluye una o más tareas, que representan lo que se debe hacer en el lanzamiento, ya sea la implementación o la verificación. Cada trabajo puede incluir una o más ejecuciones de trabajos, que son instancias de trabajos, por ejemplo, un intento de implementación. Una ejecución de trabajo es un recurso secundario del lanzamiento.

  Los objetivos múltiples, que se usan para la implementación en paralelo, crean lanzamientos de controladores, que crean lanzamientos secundarios, que corresponden a objetivos secundarios.

• Cada lanzamiento está asociado a un objetivo.

  En el caso de la implementación en paralelo , cada objetivo secundario está asociado con un lanzamiento secundario.

• Cada destino está asociado con un clúster de GKE o Anthos, o bien con otro destino de tiempo de ejecución para la aplicación.

• Un objetivo se puede asociar a una o más canalizaciones de entrega.

• Un artefacto es cualquier resultado de tu proceso de CI (por ejemplo, una imagen de contenedor) que se implementa en un entorno de ejecución de destino como parte de un lanzamiento.

Además, un lanzamiento tiene una o más fases, y las fases tienen uno o más trabajos y una o más ejecuciones de trabajo.

Como se muestra en este diagrama, un lanzamiento incluye lo siguiente:

• Fases

  Una fase contiene una o más tareas (por ejemplo, implementar o implementar y verificar). Cada lanzamiento tiene una o más fases. Una fase es un submensaje en un lanzamiento.

• Trabajos

  Es la operación específica que se realizará en un lanzamiento, por ejemplo, implementar o verificar. Un trabajo es un submensaje en un lanzamiento.

• JobRuns

  Es una instancia de un trabajo, por ejemplo, un intento de verificación. Cada trabajo puede tener cero o más JobRuns. JobRun es un recurso secundario de un lanzamiento.

Las automatizaciones contienen reglas de automatización, a las que pueden hacer referencia cero o más recursos de AutomationRun. AutomationRuns son instancias de reglas de automatización ejecutadas, por ejemplo, una promoción automática de un destino a otro. Los recursos de Automation y AutomationRun son recursos secundarios de pares debajo de una canalización de entrega.

Cómo encajan juntos para entregar tu versión

En esta sección, se describe cómo Cloud Deploy interactúa con los componentes que se enumeran en este documento para automatizar la entrega de tu aplicación como una versión.

1. Tu sistema de CI invoca una canalización de entrega de Cloud Deploy.

   Tu proceso de CI llama a Cloud Deploy con la CLI o la API para crear una versión nueva y pasar los artefactos de compilación o las referencias a las imágenes.

   Para obtener más información sobre la integración de tu sistema de CI, consulta Integra Cloud Deploy en otros sistemas.

2. Cuando se crea una versión nueva, Cloud Deploy hace lo siguiente:

   1. Almacena una instancia de la canalización de entrega como parte de la versión.

      Esta instancia de canalización no se modifica para esta versión, incluso si se cambia la configuración de la canalización de publicación. Consulta Instancias de canalización por versión para obtener más información.

      Además, la versión de Skaffold se almacena como parte de la versión. En la mayoría de los casos, esta será la versión predeterminada de Skaffold, pero como puedes especificar otras versiones, se almacena esa información.

   2. Llama a Cloud Build, que obtiene la fuente de renderización de Skaffold de Cloud Storage.

      Cloud Deploy almacena la fuente de renderización en el bucket de Cloud Storage predeterminado o alternativo.

   3. Llama a skaffold diagnose (con la versión de Skaffold almacenada cuando se crea la versión) para generar un solo manifiesto eficaz.

   4. Llama a la operación render.

      Si usas destinos integrados, Cloud Deploy llama a skaffold render para renderizar el manifiesto con las imágenes proporcionadas o los artefactos de compilación. Cloud Deploy sustituye los nombres de las imágenes en spec.templates.spec.containers.image por las rutas de acceso completas de las imágenes (incluidos los resúmenes o las etiquetas) que se proporcionan en el comando gcloud deploy releases create o en un archivo de artefactos de compilación al que hace referencia ese comando.

      Si usas un destino personalizado, Cloud Deploy llama a la operación render definida para su tipo de destino personalizado.

      Cloud Deploy almacena el manifiesto renderizado en el bucket de Cloud Storage predeterminado o alternativo.

      Cloud Deploy realiza estas acciones con el entorno de ejecución predeterminado o uno alternativo.

3. Cuando se crea un lanzamiento (automáticamente después de la creación de la versión o más adelante a pedido), Cloud Deploy hace lo siguiente:

   1. Llama a los hooks de preaprovisionamiento, si se especifican.

      Si usas una estrategia de implementación canary, se llamará a los hooks de preimplementación al comienzo de la primera fase.

   2. Llama a la operación deploy.

      Si usas destinos integrados, Cloud Deploy crea e implementa automáticamente una implementación en el primer destino llamando a skaffold apply. Si usas un objetivo integrado, el primer lanzamiento se crea automáticamente cuando se crea la versión.

      Si usas un destino personalizado, Cloud Deploy crea automáticamente un lanzamiento en el primer objetivo y llama a la operación deploy definida para su tipo de destino personalizado.

      En el caso de los destinos integrados y personalizados, el lanzamiento al primer destino es automático solo cuando la versión se crea con la línea de comandos.

      El proceso de implementación en el primer destino es el mismo que el de las promociones, como se describe en el siguiente paso.

   3. Llama a skaffold verify si verify es true para el destino en la configuración de la canalización de entrega y si la verificación se especifica en la configuración de Skaffold.

   4. Llama a los hooks posteriores a la implementación, si se especifican, después de verify, si se especifica un verify. De lo contrario, se llamará a los hooks posteriores a la implementación después de deploy.

      Si usas una estrategia de implementación de versiones canary, los hooks posteriores a la implementación se realizan como la última tarea en la fase de lanzamiento final.

4. Cuando llegue el momento de promover la versión al siguiente destino, Cloud Build recupera el manifiesto específico del destino desde Cloud Storage. Luego, Cloud Build invoca a skaffold apply para aplicar el manifiesto renderizado al entorno de ejecución de destino especificado.

   Si el destino requiere aprobación, puedes aprobarlo o rechazarlo a través de la CLI o la consola.

   Además, Cloud Deploy genera un mensaje de Pub/Sub al que puedes suscribirte para iniciar automáticamente un flujo de trabajo de aprobación.

   Cloud Deploy usa la versión de Skaffold y la instancia de canalización asociadas con esta versión, y realiza este paso en el entorno de ejecución predeterminado o personalizado.

   Este proceso es válido no solo para las promociones, sino también para las reversiones y las reimplementaciones.

5. Durante las operaciones de Cloud Deploy, el servicio publica notificaciones en varios temas de Pub/Sub (por ejemplo, cuando un lanzamiento requiere aprobación).

   Esta y otras integraciones se describen con más detalle en Cómo integrar Cloud Deploy con sistemas externos.

6. Puedes especificar una automatización para realizar automáticamente varias operaciones dentro de la canalización de publicación. Se pueden ejecutar a la hora designada. Un elemento automationRun representa una ejecución de regla de automatización.

7. Durante la operación de Cloud Deploy, el servicio escribe registros de la plataforma y registros de auditoría en Observabilidad de Google Cloud y Registros de auditoría de Cloud.

A través de todos estos pasos, el control de flujo y el acceso a los recursos están restringidos mediante la Identity and Access Management.

¿Qué sigue?

• Obtén más información para integrar Cloud Deploy en otros sistemas.

• Consulta información importante sobre el ciclo de vida de las versiones de Skaffold.

• Obtén información sobre los entornos de ejecución de Cloud Deploy.

• Prueba la explicación de los perfiles de Skaffold para Cloud Deploy.

• Aprende a combinar las herramientas de CI/CD de Google Cloud para desarrollar y entregar software de forma eficaz a GKE.