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 realizar implementaciones en el entorno de ejecución objetivo.

  • Skaffold

    Google Cloud Deploy usa Skaffold a través de Cloud Build para renderizar e implementar tus manifiestos y, así, implementar tu aplicación.

  • Cloud Storage

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

  • Google Cloud's operations suite y los registros de auditoría de Cloud.

    Google Cloud's operations suite recopila y pone a disposición los datos de registro 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 integrarlo en flujos de trabajo externos, pruebas y otros sistemas relacionados.

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

  • Tiempo de ejecución objetivo

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

Recursos de Google Cloud Deploy

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

  • Cada actualización incluye la instancia de canalización, una instantánea de la canalización de entrega y los objetivos 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 manera 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 trabajos, 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 se asocia con un destino.

  • 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 trabajos.

Recursos del 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, como 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.

    El 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 las 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.

    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 único manifiesto efectivo.

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

      Google Cloud Deploy sustituye los nombres de imágenes en spec.templates.spec.containers.image por las rutas de imágenes 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 predeterminado o alternativo de Cloud Storage.

      Google Cloud Deploy realiza estas acciones con 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 configuración de la canalización de entrega y si la verificación se especifica en la configuración de Skaffold.

  3. Cuando llega el momento de ascender 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 aprobarla o rechazarla 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 un flujo de trabajo de aprobación de forma automática.

    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 detalles en Integra Google Cloud Deploy en sistemas externos.

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