Arquitectura del servicio de Google Cloud Deploy

Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

En este documento, se describen las relaciones entre Google 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 Google Cloud Deploy y los sistemas independientes en los que se basa.

Relaciones entre los componentes de Cloud Deploy

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

  • Tu sistema de CI

    Google 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 Google Cloud Deploy para crear una versión.

  • Cloud Build

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

  • Skaffold

    Google Cloud Deploy usa Skaffold a través de Cloud Build para renderizar e implementar los manifiestos, por lo que implementa tu aplicación.

  • Cloud Storage

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

  • Google Cloud's operations suite y Cloud Audit Logs.

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

    Consulta también Registro de auditoría.

  • Pub/Sub

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

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

  • Entorno de ejecución de destino

    Google Cloud Deploy usa skaffold apply, a través de Cloud Build, para implementar tus aplicaciones en tu entorno de ejecución de destino (GKE o Anthos).

Recursos de Google Cloud Deploy

En el siguiente diagrama, se muestran los recursos que Google Cloud Deploy usa 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 actualizaciones y puede hacer referencia a uno o más objetivos.

  • Cada versión incluye la instancia de canalización, una “instantánea” de la canalización de entrega y los objetivos, 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 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 durante 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.

  • Cada lanzamiento está asociado con un objetivo.

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

  • Un objetivo 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 las fases tienen uno o más trabajos y una o más ejecuciones de trabajo.

Recursos del lanzamiento

Como se muestra en este diagrama, el 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.

  • Empleos

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

  • Ejecuciones de trabajos

    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 Google Cloud Deploy interactúa con los componentes enumerados 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 Google Cloud Deploy.

    Tu proceso de CI llama a Google 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 imágenes.

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

  2. Cuando se crea una versión nueva, Google 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 en 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 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, esa información se almacena.

    2. Llama a Cloud Build, que obtiene la fuente de procesamiento de Skaffold desde Cloud Storage.

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

    3. Llama a skaffold diagnose (mediante la versión de Skaffold almacenada en el momento de la creación de la versión) para generar un solo manifiesto eficaz.

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

      Google Cloud Deploy sustituye los nombres de imágenes en spec.templates.spec.containers.image por las rutas de imagen completas (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.

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

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

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

      Esto solo ocurre cuando se invoca a Google 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 canalización de entrega config y si la verificación se especifica en la configuración de Skaffold.

  3. Cuando llegue el momento de ascender la versión al siguiente destino, Cloud Build recuperará el manifiesto específico del destino desde Cloud Storage. Luego, Cloud Build invoca a skaffold apply para aplicar el manifiesto procesado en el entorno de ejecución de destino especificado.

    Si el destino requiere aprobación, puedes aprobar o rechazar a través de la CLI o mediante Console.

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

    Google Cloud Deploy usa la versión de Skaffold y la instancia de canalización asociada 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. En todas las operaciones de Google 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 Google Cloud Deploy en sistemas externos.

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