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 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 distintos sistemas en los que se basa.

Relaciones entre los componentes de Cloud Deploy

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

  • Tu sistema de CI

    Cloud Deploy es compatible con la mayoría de las herramientas de CI, siempre que un resultado de tu proceso de CI pueda ser una llamada 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 para implementarlos en el entorno de ejecución de destino.

  • Skaffold

    Cloud Deploy usa Skaffold a través de Cloud Build para renderizar e implementar tus manifiestos y, así, 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's operations suite y Registros de auditoría de Cloud.

    Google Cloud's operations suite recopila y pone a disposición los datos de registro para Cloud Deploy.

    Consulta también el Registro de auditoría.

  • Pub/Sub

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

    Consulta Suscríbete a las notificaciones de Cloud Deploy para obtener más información.

  • Entorno de ejecución de destino

    Cloud Deploy usa skaffold apply, a través de Cloud Build, para implementar tus aplicaciones en el entorno de ejecución de destino (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:

Relaciones entre los recursos de Cloud Deploy

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

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

  • Cada versión incluye la instancia de canalización, es decir, 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 producir cero o más lanzamientos y puede hacer referencia a cero o más artefactos.

    Cada lanzamiento incluye al menos una fase, que representa un conjunto de operaciones (trabajos) en un lanzamiento que se agrupan lógicamente, 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 objetivos múltiples, que se usan para la implementación en paralelo, crean lanzamientos de controladores, que crean lanzamientos secundarios que corresponden a destinos secundarios.

  • Cada lanzamiento está asociado con un objetivo.

    En el caso de la implementación en paralelo , cada destino 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 entorno de ejecución para la aplicación.

  • Un destino se puede asociar 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 estas tienen uno o más trabajos y una o más ejecuciones de trabajos.

Recursos para el lanzamiento

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 mensaje secundario 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.

Cómo encajan juntos para entregar tu versión

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

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

    El proceso de CI llama a Cloud Deploy mediante 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 del lanzamiento.

      Esta instancia de canalización no se modifica para esta versión, incluso si se cambia la configuración de la canalización de entrega. 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 del lanzamiento. En la mayoría de los casos, esta será la versión predeterminada de Skaffold, pero, como puedes especificar otras versiones, esa información se almacenará.

    2. Llama a Cloud Build, que obtiene la fuente de procesamiento de Skaffold desde 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 único manifiesto efectivo.

    4. Llama a skaffold render para renderizar el manifiesto con las imágenes o los artefactos de compilación proporcionados.

      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.

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

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

    5. Crea e implementa de forma automática un lanzamiento en el primer destino mediante una llamada a skaffold apply.

      Esto solo es así cuando se invoca Cloud Deploy desde la CLI para crear una versión.

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

    6. 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.

  3. Cuando llegue 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 objetivo requiere aprobación, puedes aprobarlo o rechazarlo a través de la CLI o mediante Console.

    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 se aplica no solo a las promociones, sino también a las reversiones y las reimplementaciones.

  4. 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.

  5. Durante la operación de Cloud Deploy, el servicio escribe registros y registros de auditoría de la plataforma en Google Cloud's operations suite 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?