Arquitectura de servicio de Cloud Deploy

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

Vista general

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

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 una de las salidas 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 desplegar en el tiempo de ejecución de destino.

  • Skaffold

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

  • Cloud Storage

    Cloud Deploy almacena el origen de renderizado y los manifiestos renderizados en un segmento de Cloud Storage.

  • Google Cloud Observability y registros de auditoría de Cloud.

    Google Cloud Observability recoge y pone a disposición 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 integrarlo con flujos de trabajo, pruebas y otros sistemas relacionados externos.

    Consulta más información en el artículo Recibir notificaciones de Cloud Deploy.

  • Tiempo de ejecución objetivo

    Cloud Deploy usa skaffold apply, a través de Cloud Build, para desplegar tus aplicaciones en el tiempo 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 ellos:

Relaciones entre los recursos de Cloud Deploy

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

  • La pipeline de entrega puede generar cero o más lanzamientos y puede hacer referencia a uno o varios objetivos, incluidos los objetivos múltiples y sus objetivos secundarios asociados.

  • La canalización de entrega también puede hacer referencia a una o varias automatizaciones, que automatizan acciones en recursos de Cloud Deploy.

  • Cada versión incluye la instancia de la 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 lanzamiento 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) de 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 varios trabajos, que representan lo que se debe hacer en la implementación: desplegar o verificar. Cada trabajo puede incluir una o varias ejecuciones de trabajo, que son instancias de trabajos. Por ejemplo, un intento de implementación. Un trabajo es un recurso secundario del lanzamiento.

    Las multiobjetivos, que se usan para el despliegue paralelo, crean despliegues de controladores, que a su vez crean despliegues secundarios, que corresponden a los objetivos secundarios.

  • Cada lanzamiento se asocia a un objetivo.

    En la implementación paralela , cada destino secundario se asocia a una implementación secundaria.

  • Cada destino se asocia a un clúster de GKE o Anthos, u otro destino de tiempo de ejecución de la aplicación.

  • Un destino puede asociarse a una o varias cadenas de suministro.

  • Un artefacto es cualquier resultado del proceso de integración continua (por ejemplo, una imagen de contenedor) que se despliega en un entorno de ejecución de destino como parte de un lanzamiento.

Además, un lanzamiento tiene una o varias fases, y las fases tienen una o varias tareas y una o varias ejecuciones de tareas.

Recursos de lanzamiento

Como se muestra en este diagrama, un lanzamiento incluye lo siguiente:

  • Fases

    Una fase contiene una o varias tareas (por ejemplo, implementar o implementar y verificar). Cada lanzamiento tiene una o varias fases. Una fase es un submensaje de un lanzamiento.

  • Empleo

    La operación específica que se va a realizar en un lanzamiento, por ejemplo, deploy o verify. Un trabajo es un submensaje 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 AutomationRun. AutomationRuns son instancias de reglas de automatización ejecutadas. Por ejemplo, una promoción automatizada de un destino a otro. Los recursos Automation y AutomationRun son recursos del mismo nivel que los recursos secundarios de un canal de distribución.

Recursos de automatización

Cómo se combinan para lanzar tu versión

En esta sección se describe cómo interactúa Cloud Deploy con los componentes que se indican en este documento para automatizar el lanzamiento de tu aplicación.

  1. Tu sistema de integración continua invoca un flujo de procesamiento de entrega de Cloud Deploy.

    Tu proceso de integración continua llama a Cloud Deploy mediante la CLI o la API para crear una versión, pasando los artefactos de compilación o las referencias a las imágenes.

    Para obtener más información sobre cómo integrar tu sistema de CI, consulta el artículo Integrar Cloud Deploy con otros sistemas.

  2. Cuando se crea una versión, 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 cambia en esta versión, aunque se modifique la configuración de la canalización de entrega. Para obtener más información, consulta Instancias de flujo de procesamiento por versión.

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

    2. Llama a Cloud Build, que obtiene el origen de renderización de Skaffold de Cloud Storage.

      Cloud Deploy almacena el origen de la renderización en el segmento de Cloud Storage predeterminado o alternativo.

    3. Llama a skaffold diagnose (con la versión de Skaffold almacenada al crear la versión) para generar un manifiesto eficaz único.

    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 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 imagen completas (incluidos los resúmenes o las etiquetas) proporcionadas 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 segmento de Cloud Storage predeterminado o alternativo.

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

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

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

      Si usas una estrategia de implementación canaria, los hooks de pre-implementación se llaman al inicio de la primera fase.

    2. Llama a la operación deploy.

      Si usas destinos integrados, Cloud Deploy crea y despliega automáticamente un lanzamiento en el primer destino llamando a skaffold apply. Si usas un objetivo integrado, la primera publicación se crea automáticamente al crear la versión.

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

      En el caso de los elementos de destino integrados y personalizados, el lanzamiento al primer elemento de 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 objetivo es el mismo que el de las promociones, como se describe en el paso siguiente.

    3. Llama a skaffold verify si verify es true para el destino en la configuración de la canalización de distribución y si la verificación se especifica en la configuración de Skaffold.

    4. Llama a los ganchos posteriores a la implementación, si se ha especificado alguno, después de verify, si se ha especificado un verify. De lo contrario, los ganchos posteriores a la implementación se llaman después de deploy.

      Si usas una estrategia de implementación canary, los hooks posteriores a la implementación se ejecutan como el último trabajo en la fase de lanzamiento final.

  4. Cuando llega el momento de promocionar la versión al siguiente destino, Cloud Build obtiene el manifiesto específico del destino de Cloud Storage. A continuación, Cloud Build invoca 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 la solicitud a través de la CLI o de 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 la canalización asociadas a esta versión, y lleva a cabo este paso en el entorno de ejecución predeterminado o personalizado.

    Este proceso no solo se aplica a las promociones, sino también a las reversiones y a las nuevas implementaciones.

  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 el artículo sobre integrar Cloud Deploy con sistemas externos.

  6. Puedes especificar una automatización para realizar automáticamente varias operaciones en el flujo de procesamiento de entrega. Se pueden ejecutar a la hora designada. Un objeto automationRun representa la ejecución de una regla de automatización.

  7. Durante el funcionamiento de Cloud Deploy, el servicio escribe registros de plataforma y registros de auditoría en Google Cloud Observability y Cloud Audit Logs.

En todos estos pasos, el control del flujo y el acceso a los recursos se restringen mediante Gestión de Identidades y Accesos.

Siguientes pasos