Architecture du service Google Cloud Deploy

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Ce document décrit les relations entre Google Cloud Deploy et les systèmes externes avec lesquels il fonctionne afin de déployer vos applications. Ces systèmes sont d'autres services Google Cloud et des outils tiers.

Vue d'ensemble

Le schéma suivant illustre les relations entre Google Cloud Deploy et les systèmes distincts sur lesquels il repose.

Relations entre les composants Cloud Deploy

Comme le montre ce schéma, Google Cloud Deploy interagit avec les systèmes suivants:

  • Votre système CI

    Google 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 Google Cloud Deploy pour créer une version.

  • Cloud Build

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

  • Skaffold

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

  • Cloud Storage

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

  • Suite Google Cloud Operations et Cloud Audit Logging

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

    Consultez également Journaux d'audit.

  • Pub/Sub

    Google Cloud Deploy publie des messages dans plusieurs sujets Pub/Sub. Ce service permet d'intégrer des processus externes, des tests et d'autres systèmes associés.

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

  • Environnement d'exécution cible

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

Ressources Google Cloud Deploy

Le schéma suivant montre les ressources que Google Cloud Deploy utilise pour diffuser 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 plusieurs versions et faire référence à une ou plusieurs cibles.

  • Chaque version inclut l'instance de pipeline, c'est-à-dire un instantané du pipeline de livraison et des cibles telles qu'elles ont été configurées lors de la création de la version.

  • Chaque version peut générer zéro, un ou plusieurs déploiements, ainsi que des artefacts zéro ou plusieurs.

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

    Chaque phase comprend une ou plusieurs tâches représentant ce qui doit être fait lors du déploiement : déploiement ou vérification. Chaque tâche peut inclure une ou plusieurs exécutions, c'est-à-dire 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.

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

  • 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 tout résultat de votre processus CI (par exemple, une image de conteneur) déployé dans un environnement d'exécution cible dans le cadre d'un déploiement.

En outre, un déploiement comporte une ou plusieurs phases, et une ou plusieurs tâches sont exécutées, et une ou plusieurs exécutions de tâches sont exécutées.

Ressources pour le déploiement

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

  • Phases

    Une phase contient une ou plusieurs tâches (déploiement, validation et validation, par exemple). 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 le déploiement ou la validation. Une tâche est un sous-message d'un déploiement.

  • Exécutions de tâche

    Instance d'une tâche, par exemple une tentative de validation. Chaque tâche peut n'en avoir aucune ou plus. Le JobRun est une ressource enfant d'un déploiement.

Comment ils s'intègrent pour diffuser votre version

Cette section décrit comment Google Cloud Deploy interagit avec les composants répertorié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 Google Cloud Deploy.

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

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

  2. Lorsqu'une version est créée, Google 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 page Instances de pipeline par version.

      De plus, la version Skaffold est stockée dans le cadre de la version.

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

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

    3. Appel de 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 skaffold render pour afficher le fichier manifeste à l'aide des images fournies ou des artefacts de build.

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

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

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

    5. Crée et déploie automatiquement un déploiement sur la première cible, en appelant skaffold apply.

      Cela n'est vrai que lorsque Google Cloud Deploy est appelé à partir de la CLI pour créer une version.

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

    6. Il appelle skaffold verify si verify est défini sur true pour la cible dans la configuration du pipeline de livraison et si la validation est spécifiée dans la configuration Skaffold.

  3. Lorsque le moment est venu de promouvoir la version sur la cible suivante, Cloud Build récupère le fichier manifeste spécifique à la cible à partir de Cloud Storage. Ensuite, Cloud Build invoque 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 via la CLI ou à l'aide de la console.

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

    Google 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 est vrai non seulement pour les promotions, mais aussi pour les rollbacks et les redéploiements.

  4. Tout au long des opérations Google Cloud Deploy, le service publie des notifications dans plusieurs sujets Pub/Sub (par exemple, lorsqu'un déploiement exige une approbation).

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

  5. Tout au long de l'opération Google Cloud Deploy, le service écrit les journaux de plate-forme et les journaux d'audit dans la suite Google Cloud Operations et les journaux d'audit Cloud.

Lors de toutes ces étapes, le contrôle de flux et l'accès aux ressources sont limités à l'aide de Identity and Access Management.

Étapes suivantes