Architecture du service Cloud Deploy

Ce document décrit les relations entre Cloud Deploy et les systèmes externes avec lesquels il fonctionne pour déployer vos applications. Il s'agit d'autres services Google Cloud et d'outils tiers.

Vue d'ensemble

Le diagramme suivant illustre les relations entre Cloud Deploy et les systèmes distincts sur lesquels il s'appuie.

Relations entre les composants Cloud Deploy

Comme illustré dans ce diagramme, Cloud Deploy interagit avec les systèmes suivants:

  • Votre système CI

    Cloud Deploy est compatible avec la plupart des outils de CI, à condition qu'une sortie du processus CI puisse être un appel à l'API ou à la CLI de Cloud Deploy pour créer une version.

  • Cloud Build

    Cloud Deploy appelle Cloud Build pour afficher vos fichiers manifestes et les déployer sur l'environnement d'exécution cible.

  • Skaffold

    Cloud Deploy utilise Skaffold via Cloud Build pour afficher et déployer vos fichiers manifestes, et ainsi déployer votre application.

  • Cloud Storage

    Cloud Deploy stocke la source de rendu et les fichiers manifestes rendus dans un bucket Cloud Storage.

  • Google Cloud Observability et Cloud Audit Logs

    Google Cloud Observability collecte et met à disposition les données de journalisation pour Cloud Deploy.

    Consultez également Journaux d'audit.

  • Pub/Sub

    Cloud Deploy publie des messages dans plusieurs sujets Pub/Sub. Vous pouvez utiliser ce service pour intégrer des workflows, des tests et d'autres systèmes externes.

    Pour en savoir plus, consultez S'abonner aux notifications Cloud Deploy.

  • Environnement d'exécution cible

    Cloud Deploy utilise skaffold apply, via Cloud Build, pour déployer vos applications sur votre environnement d'exécution cible (GKE ou GKE Enterprise).

Ressources Cloud Deploy

Le schéma suivant montre les ressources que Cloud Deploy utilise pour diffuser vos applications, ainsi que les relations entre ces ressources:

Relations entre les ressources Cloud Deploy

Comme le montre ce diagramme, les relations entre les ressources sont les suivantes:

  • Le pipeline de livraison peut générer zéro ou plusieurs versions et peut référencer une ou plusieurs cibles, y compris des multicibles et leurs cibles enfants associées.

  • Le pipeline de diffusion peut également faire référence à une ou plusieurs automatisations, qui automatisent les actions sur les ressources Cloud Deploy.

  • Chaque version inclut l'instance de pipeline, un "instantané" du pipeline de diffusion et des cibles tels qu'ils étaient configurés lors de la création de la version.

  • Chaque version peut générer zéro ou plusieurs déploiements, et peut référencer zéro ou plusieurs artefacts.

    Chaque déploiement comprend au moins une phase, qui représente un ensemble d'opérations (tâches) dans un déploiement qui sont regroupées de manière logique, par exemple un déploiement ou un déploiement et une validation.

    Chaque phase comprend une ou plusieurs tâches, qui représentent ce qui doit être effectué lors du déploiement (déploiement ou validation). Chaque tâche peut inclure une ou plusieurs exécutions de tâches, qui sont des instances de tâches, par exemple une tentative de déploiement. Une exécution de tâche est une ressource enfant du déploiement.

    Les multicibles, utilisées pour le déploiement parallèle, créent des déploiements de contrôleurs, qui créent des déploiements enfants, qui correspondent à des cibles enfants.

  • Chaque déploiement est associé à une cible.

    Pour le déploiement parallèle , chaque cible enfant est associée à un déploiement enfant.

  • Chaque cible est associée à un cluster GKE ou Anthos, ou à une autre destination d'exécution pour l'application.

  • Une cible peut être associée à un ou plusieurs pipelines de diffusion.

  • Un artefact est toute sortie de votre processus CI (par exemple, une image de conteneur) déployée sur un environnement d'exécution cible lors d'un déploiement.

De plus, un déploiement comporte une ou plusieurs phases, et les phases comportent une ou plusieurs tâches et une ou plusieurs exécutions de tâches.

Ressources de déploiement

Comme le montre ce schéma, un déploiement comprend les éléments suivants:

  • Phases

    Une phase contient une ou plusieurs tâches (par exemple, le déploiement ou le déploiement et la validation). Chaque déploiement comporte une ou plusieurs phases. Une phase est un sous-message dans un déploiement.

  • Tâches

    Opération spécifique à effectuer lors d'un déploiement, par exemple le déploiement ou la validation. Une tâche est un sous-message dans un déploiement.

  • JobRuns

    Instance d'une tâche, par exemple une tentative de validation. Chaque tâche peut avoir zéro ou plusieurs JobRuns. JobRun est une ressource enfant d'un déploiement.

Les automatisations contiennent des règles d'automatisation, qui peuvent être référencées par une ou plusieurs ressources AutomationRun. Les AutomationRuns sont des instances de règles d'automatisation exécutées, par exemple une promotion automatique d'une cible à une autre. Les ressources Automation et AutomationRun sont des ressources enfants homologues sous un pipeline de diffusion.

Ressources d'automatisation

Comment ils s'intègrent pour diffuser votre version

Cette section décrit comment Cloud Deploy interagit avec les composants listés dans ce document pour automatiser la diffusion de votre application en tant que version.

  1. Votre système CI appelle un pipeline de diffusion Cloud Deploy.

    Votre processus de CI appelle Cloud Deploy à l'aide de la CLI ou de l'API pour créer une version, en transmettant les artefacts de compilation ou les références aux images.

    Pour en savoir plus sur l'intégration de votre système CI, consultez la section Intégrer Cloud Deploy à d'autres systèmes.

  2. Lorsqu'une version est créée, Cloud Deploy effectue les opérations suivantes:

    1. Stocke une instance du pipeline de diffusion dans le cadre de la version.

      Cette instance de pipeline reste inchangée pour cette version, même si la configuration du pipeline de livraison est modifiée. Pour en savoir plus, consultez la section Instances de pipeline par version.

      De plus, la version Skaffold est stockée dans le cadre de la version. Dans la plupart des cas, il s'agit de la version Skaffold par défaut, mais comme vous pouvez spécifier d'autres versions, ces informations sont stockées.

    2. Appelle Cloud Build, qui obtient la source de rendu Skaffold à partir de Cloud Storage.

      Cloud Deploy stocke la source de rendu dans le bucket Cloud Storage par défaut ou alternatif.

    3. Appels skaffold diagnose (à l'aide de la version Skaffold stockée lors de la création de la version) pour générer un seul fichier manifeste efficace.

    4. Appele l'opération render.

      Si vous utilisez des cibles intégrées, Cloud Deploy appelle skaffold render pour afficher le fichier manifeste à l'aide des images ou des artefacts de compilation fournis. Cloud Deploy remplace les noms d'image dans spec.templates.spec.containers.image par les chemins d'accès complets des images (y compris les condensés ou les tags) fournis dans la commande gcloud deploy releases create ou dans un fichier d'artefacts de compilation référencé par cette commande.

      Si vous utilisez une cible personnalisée, Cloud Deploy appelle l'opération render définie pour son type de cible personnalisée.

      Cloud Deploy stocke le fichier manifeste rendu dans le bucket Cloud Storage par défaut ou alternatif.

      Cloud Deploy effectue ces actions à l'aide de l'environnement d'exécution par défaut ou d'un autre.

  3. Lorsqu'un déploiement est créé (automatiquement après la création de la version ou à la demande plus tard), Cloud Deploy effectue les opérations suivantes:

    1. Appele les hooks de prédéploiement, le cas échéant.

      Si vous utilisez une stratégie de déploiement canari, les hooks de prédéploiement sont appelés au début de la première phase.

    2. Appele l'opération deploy.

      Si vous utilisez des cibles intégrées, Cloud Deploy crée et déploie automatiquement un déploiement sur la première cible en appelant skaffold apply. Si vous utilisez une cible intégrée, le premier déploiement est créé automatiquement lors de la création de la version.

      Si vous utilisez une cible personnalisée, Cloud Deploy crée automatiquement un déploiement vers la première cible, en appelant l'opération deploy définie pour son type de cible personnalisée.

      Pour les cibles intégrées et les cibles personnalisées, le déploiement vers la première cible n'est automatique que lorsque la version est créée à l'aide de la ligne de commande.

      Le processus de déploiement sur la première cible est le même que pour les promotions, comme décrit à l'étape suivante.

    3. Appels skaffold verify, si verify est true pour la cible dans la configuration du pipeline de diffusion et si la vérification est spécifiée dans la configuration Skaffold.

    4. Appele les hooks post-déploiement, le cas échéant, après verify, si un verify est spécifié. Sinon, les hooks post-déploiement sont appelés après deploy.

      Si vous utilisez une stratégie de déploiement Canary, les hooks post-déploiement sont exécutés en tant que dernière tâche de la phase de déploiement finale.

  4. Lorsque le moment est venu de promouvoir la version vers la cible suivante, Cloud Build récupère le fichier manifeste spécifique à la cible à partir de Cloud Storage. Cloud Build appelle ensuite skaffold apply pour appliquer le fichier manifeste généré à l'environnement d'exécution cible spécifié.

    Si la cible nécessite une approbation, vous pouvez l'approuver ou la refuser via la CLI ou la console.

    De plus, Cloud Deploy génère un message Pub/Sub auquel vous pouvez vous abonner pour lancer automatiquement un workflow d'approbation.

    Cloud Deploy utilise la version Skaffold et l'instance de pipeline associées à cette version. Il effectue cette étape dans l'environnement d'exécution par défaut ou personnalisé.

    Ce processus s'applique non seulement aux promotions, mais aussi aux rollbacks et aux redéploiements.

  5. Tout au long des opérations Cloud Deploy, le service publie des notifications sur plusieurs sujets Pub/Sub (par exemple, lorsqu'un déploiement nécessite une approbation).

    Ce processus et d'autres intégrations sont décrits plus en détail sur la page Intégrer Cloud Deploy à des systèmes externes.

  6. Vous pouvez spécifier une automatisation pour effectuer automatiquement différentes opérations dans le pipeline de diffusion. Ils peuvent être exécutés à l'heure prévue. Un automationRun représente l'exécution d'une règle d'automatisation.

  7. Tout au long de l'opération Cloud Deploy, le service écrit les journaux de plate-forme et les journaux d'audit dans Google Cloud Observability et Cloud Audit Logs.

À chaque étape, le contrôle des flux et l'accès aux ressources sont limités à l'aide d'Identity and Access Management.

Étape suivante