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.

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 admite la mayoría de las herramientas de CI, siempre que un resultado del 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, luego, 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.

  • Observabilidad de Google Cloud y Registros de auditoría de Cloud.

    La observabilidad de Google Cloud recopila y pone a disposición datos de registro para 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 la integración en flujos de trabajo externos, pruebas y otros sistemas relacionados.

    Consulta Cómo suscribirte 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:

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 versiones y puede hacer referencia a uno o más destinos, incluidos los objetivos 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 un conjunto de operaciones (trabajos) agrupados 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 de implementación o 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. La ejecución de un trabajo es un recurso secundario del lanzamiento.

    Los objetivos múltiples, que se usan para la implementación en paralelo, crean lanzamientos del controlador, que crean lanzamientos secundarios que corresponden a los destinos secundarios.

  • Cada lanzamiento se asocia a 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 a otro destino del entorno de ejecución de la aplicación.

  • Un destino se puede asociar con una o más canalizaciones de entrega.

  • Un artefacto es cualquier resultado del 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, una implementación 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 mensaje secundario de un lanzamiento.

  • Trabajos

    La operación específica que se realizará en un lanzamiento, como implementar o verificar. Un trabajo es un mensaje secundario de 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. Las 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 de intercambio de tráfico dentro de una canalización de entrega.

Recursos de automatización

Cómo encajan juntos para entregar tu versión

En esta sección, se describe cómo Cloud Deploy interactúa con los componentes enumerados 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.

    El proceso de CI llama a Cloud Deploy con la CLI o la API para crear una versión nueva y pasa 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 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, debido a que puedes especificar otras versiones, esa información se almacena.

    2. Se 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 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 sustituye los nombres de imágenes en spec.templates.spec.containers.image por las rutas de acceso 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.

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

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

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

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

    2. Llama a la operación deploy.

      Si usas destinos integrados, Cloud Deploy crea e implementa automáticamente un lanzamiento en el primer destino mediante una llamada a skaffold apply. Si usas un destino 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 destino y llama a la operación deploy definida para su tipo de destino personalizado.

      Para los destinos integrados y personalizados, el lanzamiento al primer destino es automático solo cuando la versión se crea mediante 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 especifica en la configuración de Skaffold.

    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 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 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 aprobarlo o rechazarlo 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 un flujo de trabajo de aprobación de forma automática.

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

  5. A través de 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 en más detalle en Integra Cloud Deploy en sistemas externos.

  6. Puedes especificar una automatización para realizar varias operations dentro de la canalización de entrega de forma automática. Estas se pueden ejecutar en el momento designado. Un objeto automationRun representa la ejecución de una 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 los registros de observabilidad de Google Cloud y 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?