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.
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 Deploy llama a Cloud Build para renderizar tus manifiestos y desplegar en el tiempo de ejecución de destino.
-
Cloud Deploy usa Skaffold a través de Cloud Build para renderizar y desplegar tus manifiestos, y así desplegar tu aplicación.
-
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.
-
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:
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.
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.
Cómo se combinan para lanzar tu versión
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.
Cuando se crea una versión, Cloud Deploy hace lo siguiente:
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.
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.
Llama a
skaffold diagnose
(con la versión de Skaffold almacenada al crear la versión) para generar un manifiesto eficaz único.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 enspec.templates.spec.containers.image
por las rutas de imagen completas (incluidos los resúmenes o las etiquetas) proporcionadas en el comandogcloud 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.
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:
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.
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.
Llama a
skaffold verify
siverify
estrue
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.Llama a los ganchos posteriores a la implementación, si se ha especificado alguno, después de
verify
, si se ha especificado unverify
. De lo contrario, los ganchos posteriores a la implementación se llaman después dedeploy
.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.
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.
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.
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.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
Más información sobre cómo integrar Cloud Deploy con otros sistemas
Consulta información importante sobre el ciclo de vida de las versiones de Skaffold.
Consulta información sobre los entornos de ejecución de Cloud Deploy.
Prueba la guía de perfiles de Skaffold de Cloud Deploy.
Descubre cómo combinar herramientas de CI/CD para desarrollar y ofrecer software de forma eficaz en GKE. Google Cloud