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 schéma suivant illustre les relations entre Cloud Deploy et les systèmes distincts sur lesquels il repose.

Relations entre les composants Cloud Deploy

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

  • Votre système CI

    Cloud Deploy est compatible avec la plupart des outils d'intégration continue, à condition que l'une des sorties de votre processus d'intégration continue puisse être un appel à l'API Cloud Deploy ou à la CLI 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, déployant ainsi votre application.

  • Cloud Storage

    Cloud Deploy stocke la source du rendu et les fichiers manifestes affichés dans un bucket Cloud Storage.

  • Observabilité Google Cloud et Cloud Audit Logs :

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

    Consultez également la page Journaux d'audit.

  • Pub/Sub

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

    Pour en savoir plus, consultez la section 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 illustre les ressources utilisées par Cloud Deploy pour fournir 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 ne produire aucune version ou plus et faire référence à une ou plusieurs cibles, y compris des cibles multicibles et leurs cibles enfants associées.

  • Le pipeline de livraison 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, c'est-à-dire un "instantané" du pipeline de livraison 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, un ou plusieurs déploiements, et peut faire référence à zéro ou plusieurs artefacts.

    Chaque déploiement comprend au moins une phase, qui représente un ensemble d'opérations (tâches) d'un déploiement 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 de tâche, qui sont des instances de tâches, comme une tentative de déploiement. Une tâche exécutée est une ressource enfant du déploiement.

    Les cibles multiples, utilisées pour le déploiement parallèle, créent des déploiements du contrôleur, qui créent des déploiements enfants correspondant à des cibles enfants.

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

    Pour un déploiement en 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 de l'application.

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

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

En outre, un déploiement comporte une ou plusieurs phases, lesquelles comportent une ou plusieurs tâches et une ou plusieurs exécutions de tâche.

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, déployer, ou déployer et vérifier). 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 déployer ou vérifier. Une tâche est un sous-message d'un déploiement.

  • JobRuns

    Instance d'une tâche, par exemple une tentative de validation. Chaque job peut comporter zéro ou plusieurs exécutions de job. Le 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 automatique d'une cible à une autre. Les ressources Automation et AutomationRun sont des ressources pairs-enfants 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 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 livraison 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 ou les références de compilation à des images.

    Pour en savoir plus sur l'intégration de votre système CI, consultez la page 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. Consultez la section Instances de pipeline par version pour plus d'informations.

      De plus, la version Skaffold est stockée dans le cadre de la version. Dans la plupart des cas, il s'agira de la version par défaut de Skaffold, 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. Appel à 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. 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 de l'image (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 alternatif.

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

    1. Appelle des 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 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 sur 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 sur 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 sur la première cible est le même que pour les promotions, comme décrit à l'étape suivante.

    3. Elle appelle skaffold verify, si verify est défini sur 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 des hooks de 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 constituent la dernière tâche de la phase de déploiement finale.

  4. Au moment de promouvoir la version sur 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 affiché à 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.

    En outre, 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, et effectue cette étape dans l'environnement d'exécution par défaut ou personnalisé.

    Ce processus est valable non seulement pour les promotions, mais également pour les rollbacks et les 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).

    Cette intégration et d'autres sont décrites plus en détail dans la section Intégrer Cloud Deploy à des systèmes externes.

  6. Vous pouvez spécifier une automatisation pour effectuer automatiquement diverses operations dans le pipeline de livraison. Celles-ci peuvent être exécutées au moment qui leur est attribué. 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 les journaux d'observabilité Google Cloud et Cloud Audit Logs.

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

Étapes suivantes