Arquitectura del servicio de Cloud Deploy

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

La vista de alto nivel

En el siguiente diagrama, se muestran las relaciones entre Cloud Deploy y los sistemas separados de los que depende.

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 de Cloud Deploy o a la CLI para crear una versión.

• Cloud Build

  Cloud Deploy llama a Cloud Build para renderizar tus manifiestos y realizar la implementación 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 Cloud Audit Logs.

  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 realizar integraciones con flujos de trabajo externos, pruebas y otros sistemas relacionados.

  Para obtener más información, consulta Cómo suscribirse a las notificaciones de Cloud Deploy.

• 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 de destino (GKE, Cloud Run o un destino personalizado).

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 entrega también puede hacer referencia a una o más automatizaciones, que automatizan acciones en los 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 (trabajos) 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 uno o más trabajos, que representan lo que se debe hacer en el lanzamiento, ya sea implementar o verificar. Cada trabajo puede incluir una o más ejecuciones de trabajo, que son instancias de trabajos, por ejemplo, un intento de implementación. Una ejecución de trabajo es un recurso secundario del lanzamiento.

  Los destinos múltiples, que se usan para la implementación paralela, crean lanzamientos de controlador, que crean lanzamientos secundarios, que corresponden a destinos secundarios.

• Cada lanzamiento está asociado con un destino.

  Para la implementación paralela , cada destino secundario está asociado con un lanzamiento secundario.

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

• Un destino puede estar asociado con 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 uno o más trabajos (por ejemplo, implementar o implementar y verificar). Cada lanzamiento tiene una o más fases. Una fase es un submensaje en un lanzamiento.

• Trabajos

  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

  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 automatizada de un destino a otro. Los recursos de Automation y AutomationRun son recursos secundarios del mismo nivel 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 permanece sin cambios para esta versión, incluso si se cambia la configuración de la canalización de entrega. Para obtener más información, consulta Instancias de canalización por versión.

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

   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 predeterminado o alternativo de Cloud Storage.

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

   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 substitutes 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 render operación definida para su tipo de destino personalizado.

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

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

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

   1. Llama a los hooks previos a la implementación, si se especifica alguno.

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

   2. Llama a la operación deploy.

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

      Nota: skaffold apply incluye la verificación de estado de Skaffold health check, que espera las implementaciones para estabilizar.

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

      Para los destinos integrados y los destinos 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 para 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 .

   4. Llama a los hooks posteriores a la implementación, si se especifica alguno, después de verify, si se especifica un verify. De lo contrario, se llama 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 el último trabajo en la fase final del lanzamiento.

4. Cuando es el momento de promover la versión al siguiente destino, Cloud Build recupera el manifiesto específico del destino de 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 aprobar o rechazar a través de la CLI o con 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 que están asociadas con esta versión, y realiza este paso en el entorno de ejecución predeterminado o personalizado.

   Este proceso no solo es válido 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 Integra Cloud Deploy en sistemas externos.

6. Puedes especificar una automatización para realizar automáticamente varias operaciones dentro de la canalización de entrega. Estas se pueden ejecutar en el momento designado. Un automationRun representa una ejecución de regla de automatización.

7. Durante la operación de Cloud Deploy, el servicio escribe registros de plataforma y registros de auditoría en Google Cloud Observability 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 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 la versión de la herramienta.

• 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 Google Cloud herramientas de CI/CD para desarrollar y entregar software de manera eficaz a GKE.