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. Ces systèmes sont d'autres services Google Cloud et outils tiers.

Vue générale

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 le montre ce diagramme, Cloud Deploy interagit avec les systèmes suivants :

  • Votre système d'intégration continue

    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 dans l'environnement d'exécution cible.

  • Skaffold

    Cloud Deploy utilise Skaffold via Cloud Build pour afficher et déployer vos fichiers manifestes, et donc 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 journaux d'audit Cloud

    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 l'intégrer à des systèmes externes de workflow, de test et autres systèmes associés.

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

  • Durée 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 utilisées par Cloud Deploy pour distribuer vos applications, ainsi que les relations entre ces ressources :

Relations entre les ressources Cloud Deploy

Comme le montre ce schéma, 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 cibles multiples et leurs cibles enfants associées.

  • Le pipeline de déploiement 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, qui est un "instantané" du pipeline de diffusion et des cibles tels qu'ils ont été configurés lors de la création de la version.

  • Chaque version peut générer zéro ou plusieurs déploiements et peut faire référence à zéro ou plusieurs artefacts.

    Chaque déploiement inclut au moins une phase, qui représente un ensemble d'opérations (jobs) dans un déploiement qui sont regroupées de manière logique, par exemple un déploiement ou un déploiement et une vérification.

    Chaque phase comprend un ou plusieurs jobs, qui représentent ce qui doit être fait lors du déploiement (déployer ou valider). Chaque job peut inclure une ou plusieurs exécutions de job, qui sont des instances de jobs (par exemple, une tentative de déploiement). Une exécution de job est une ressource enfant du déploiement.

    Les cibles multiples, utilisées pour le déploiement parallèle, créent des déploiements de contrôleur, qui créent des déploiements enfants correspondant aux 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 livraison.

  • Un artefact est un résultat de votre processus CI (par exemple, une image de conteneur) qui est déployé dans un environnement d'exécution cible dans le cadre d'un déploiement.

De plus, un déploiement comporte une ou plusieurs phases, et les phases comportent un ou plusieurs jobs et une ou plusieurs exécutions de job.

Ressources de déploiement

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

  • Phases

    Une phase contient un ou plusieurs jobs (par exemple, "déployer" ou "déployer et valider"). Chaque déploiement comporte une ou plusieurs phases. Une phase est un sous-message d'un déploiement.

  • Jobs

    Opération spécifique à effectuer sur un déploiement, par exemple "deploy" (déployer) ou "verify" (valider). Un job est un sous-message dans un déploiement.

  • JobRuns

    Instance d'un job, par exemple une tentative de validation. Chaque job 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 zéro ou plusieurs ressources AutomationRun. Les AutomationRuns sont des instances de règles d'automatisation exécutées, par exemple une promotion automatisée d'une cible à une autre. Les ressources Automation et AutomationRun sont des ressources enfants homologues sous un pipeline de livraison.

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

    4. Appelle 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 environnement.

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

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

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

    2. Appelle l'opération deploy.

      Si vous utilisez des cibles intégrées, Cloud Deploy crée et déploie automatiquement un déploiement progressif 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 progressif 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 personnalisées, le déploiement vers la première cible est automatique uniquement lorsque la version est créée à l'aide de la ligne de commande.

      Le processus de déploiement vers 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 livraison et si la vérification est spécifiée dans la configuration Skaffold.

    4. Appelle 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 dernier job de la phase de déploiement final.

  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 depuis Cloud Storage. Cloud Build appelle ensuite skaffold apply pour appliquer le fichier manifeste rendu à l'environnement d'exécution cible spécifié.

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

    Cloud Deploy génère également 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 dans 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 diverses opérations dans le pipeline de diffusion. Elles peuvent être exécutées à 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.

Tout au long de ces étapes, le contrôle du flux et l'accès aux ressources sont limités à l'aide d'Identity and Access Management.

Étapes suivantes