Déploiements sécurisés avec Config Sync

Ce document explique aux opérateurs de cluster et aux administrateurs de la plate-forme comment déployer en toute sécurité les modifications dans plusieurs environnements à l'aide de Config Sync. Cette approche peut vous aider à éviter les erreurs qui affectent tous vos environnements simultanément.

Config Sync vous permet de gérer des clusters uniques, des clusters mutualisés et des configurations Kubernetes multiclusters à l'aide de fichiers stockés dans un dépôt Git.

Les configurations peuvent représenter plusieurs éléments, y compris les suivants :

• Les objets GKE standards, tels que des ressources NetworkPolicies, DaemonSets ou RoleBindings.
• Les ressources Google Cloud, telles que des instances Compute Engine ou des bases de données Cloud SQL, via Config Connector.
• Des contraintes sur la configuration elle-même, via Policy Controller.

Config Sync est particulièrement adapté au déploiement des configurations, des stratégies et des charges de travail nécessaires à l'exécution de la plate-forme que vous créez sur l'édition Enterprise Google Kubernetes Engine (GKE) (par exemple, agents de sécurité, agents de surveillance et gestionnaires de certificats).

Bien que vous puissiez déployer des applications visibles par l'utilisateurs avec Config Sync, nous vous déconseillons d'associer leur cycle de vie des versions au cycle de vie des versions d'administration des charges de travail administratives mentionnées précédemment. Nous vous recommandons plutôt d'utiliser un outil dédié au déploiement d'applications, tel qu'un outil de déploiement continu, afin que les équipes puissent gérer leur calendrier de mise en ligne.

Config Sync est un produit puissant qui peut gérer de nombreux éléments. Vous devez donc disposer de garde-fous pour éviter les erreurs ayant un impact majeur. Ce document décrit plusieurs méthodes permettant de créer des garde-fous. La première section aborde les déploiements par étapes, et la deuxième section traite des tests et des validations. La troisième section montre comment surveiller vos déploiements.

Remarque : Ce tutoriel utilise un dépôt Git pour expliquer comment mettre en œuvre des déploiements. Les images OCI et les charts Helm sont également compatibles.

Mettre en œuvre des déploiements par étapes avec Config Sync

Dans un environnement multicluster, ce qui est courant pour les utilisateurs de GKE Enterprise, nous déconseillons d'appliquer une modification de configuration sur tous les clusters en même temps. Un déploiement par étapes, cluster par cluster, est beaucoup plus sécurisé, car cela réduit l'impact potentiel de toute erreur.

Il existe plusieurs façons de mettre en œuvre des déploiements par étapes avec Config Sync :

• Utilisez des commits ou des tags Git pour appliquer manuellement les modifications que vous souhaitez aux clusters.
• Utilisez les branches Git pour appliquer automatiquement les modifications lorsque celles-ci sont fusionnées. Vous pouvez utiliser différentes branches pour différents groupes de clusters.
• Utilisez les objets ClusterSelector et NamespaceSelector pour appliquer de manière sélective des modifications aux sous-groupes de clusters ou d'espaces de noms.

Toutes les méthodes de déploiement par étapes présentent des avantages et des inconvénients. Le tableau suivant indique les méthodes que vous pouvez utiliser en même temps :

Compatibilité	Commits ou tags Git	Branches Git	Sélecteurs de clusters	Sélecteurs d'espace de noms
Commits ou tags Git		Incompatible	Compatible	Compatible
Branches Git	Incompatible		Compatible	Compatible
Sélecteurs de clusters	Compatible	Compatible		Compatible
Sélecteurs d'espace de noms	Compatible	Compatible	Compatible

L'arbre de décision suivant peut vous aider à décider quand utiliser l'une des méthodes de déploiement par étapes.

Remarque : Config Sync vous permet de synchroniser les configurations de plusieurs dépôts : un dépôt pour les configurations à l'échelle d'un cluster et un dépôt facultatif par espace de noms. Bien que l'utilisation des sélecteurs d'espace de noms soit différente lorsque vous utilisez plusieurs dépôts, vous pouvez toujours appliquer toutes les autres méthodes décrites dans cette section aux dépôts à partir desquels vous synchronisez les configurations.

Utiliser des commits ou des tags Git

Par rapport aux autres méthodes de déploiement par étapes, l'utilisation de commits ou de tags Git offre le plus de contrôle et est la plus sûre. Vous pouvez utiliser la page Config Sync dans la console Google Cloud pour mettre à jour plusieurs clusters en même temps. Utilisez cette méthode si vous souhaitez appliquer les modifications à vos clusters une par une et contrôler exactement quand cela se produit.

Dans cette méthode, vous "épinglez" chaque cluster à une version spécifique (un commit ou un tag) de votre dépôt. Cette méthode est similaire à l'utilisation du commit Git en tant que tag d'image de conteneur. Pour mettre en œuvre cette méthode, spécifiez le commit, le tag ou le hachage dans le champ spec.git.revision de la ressource personnalisée RootSync ou RepoSync.

Si vous gérez vos ressources personnalisées RootSync ou RepoSync avec un outil tel que Kustomize, vous pouvez réduire le nombre de tâches manuelles nécessaires pour les déploiements. Avec cet outil, il vous suffit de modifier le paramètre revision au même endroit, puis d'appliquer de manière sélective la nouvelle ressource personnalisée RootSync ou RepoSync dans vos clusters dans l'ordre et au rythme de votre choix.

En outre, vous pouvez utiliser la console Google Cloud pour mettre à jour le paramètre revision dans plusieurs clusters appartenant au même parc en même temps. Toutefois, si vous disposez d'un système automatisé pour mettre à jour vos configurations, nous vous déconseillons d'utiliser la console Google Cloud pour apporter des modifications de configuration.

Par exemple, la définition RootSync suivante configure Config Sync de sorte qu'il utilise le tag 1.2.3 :

apiVersion: configsync.gke.io/v1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-sync-system
spec:
  sourceType: git
  sourceFormat: unstructured
  git:
    repo: [e-mail]:gke/config-sync.git
    revision: 1.2.3
    auth: ssh

Si vous appliquez cette configuration à votre cluster, Config Sync utilise le tag 1.2.3 du dépôt example.com:gke/config-sync.git.

Pour mettre à jour un cluster, remplacez le champ spec.git.revision par la nouvelle valeur du cluster. Cela vous permet de définir quels clusters sont mis à jour et à quel moment. Si vous devez annuler une modification, redéfinissez le champ spec.git.revision sur sa valeur correspondante.

Le schéma suivant illustre le processus de déploiement de cette méthode. Commencez par valider les modifications apportées au dépôt Config Sync, puis mettez à jour les définitions RootSync sur tous les clusters :

Nous vous recommandons d'effectuer les actions suivantes :

• Utilisez des ID de commit Git plutôt que des tags. En raison du fonctionnement de Git, vous avez la garantie qu'ils ne changeront jamais. Par exemple, un git push --force ne peut pas modifier le commit utilisé par Config Sync. Cette approche est utile à des fins d'audit et pour savoir quel commit vous utilisez dans les journaux. De plus, contrairement aux tags, il n'y a pas d'étape supplémentaire de validation des ID.
• Si vous préférez utiliser des tags Git plutôt que des ID de commit Git, vous pouvez protéger vos tags si vous utilisez une solution Git compatible avec la protection.
• Si vous souhaitez mettre à jour plusieurs clusters en même temps, vous pouvez le faire dans la console Google Cloud. Pour que vous puissiez mettre à jour plusieurs clusters simultanément, ils doivent faire partie du même parc (et se trouver dans le même projet).

Utiliser des branches Git

Si vous souhaitez appliquer les modifications aux clusters dès qu'ils sont fusionnés dans votre dépôt Git, configurez Config Sync pour qu'il utilise les branches Git au lieu des commits ou des tags. Dans cette méthode, vous créez plusieurs branches de longue durée dans votre dépôt Git et configurez Config Sync dans différents clusters pour lire sa configuration à partir de différentes branches.

Par exemple, un modèle simple comporte deux branches :

• Une branche staging pour les clusters qui ne sont pas de production.
• Une branche main pour les clusters de production.

Avertissement : Si vous gérez un grand nombre de clusters et d'environnements, vous aurez peut-être besoin d'un grand nombre de branches. Ce processus peut rapidement devenir fastidieux. C'est pourquoi nous vous recommandons d'utiliser des commits Git sur des branches.

Pour les clusters qui ne sont pas de production, créez l'objet RootSync ou RepoSync avec le champ spec.git.branch défini sur staging. Pour les clusters de production, créez l'objet RootSync ou RepoSync en définissant le paramètre spec.git.branch sur main.

Par exemple, la définition RootSync suivante configure Config Sync de sorte qu'il utilise la branche main :

apiVersion: configsync.gke.io/v1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-sync-system
spec:
  git:
    repo: [e-mail]:gke/config-sync.git
    branch: main
    auth: ssh

Le schéma suivant illustre le processus de déploiement de cette méthode :

Vous pouvez adapter ce modèle à des besoins spécifiques, en utilisant plus de deux branches ou en utilisant des branches mappées vers d'autres environnements. Si vous devez effectuer un rollback d'une modification, utilisez la commande git revert pour créer un commit sur la même branche qui rétablit les modifications à partir du commit précédent.

Nous vous recommandons d'effectuer les actions suivantes :

• Lorsque vous travaillez avec plusieurs clusters, utilisez au moins deux branches Git pour distinguer les clusters de production des clusters qui ne sont pas de production.
• La plupart des solutions Git vous permettent d'utiliser la fonctionnalité des branches protégées pour éviter les suppressions ou les modifications non vérifiées de ces branches. Pour en savoir plus, consultez la documentation sur GitHub, GitLab et Bitbucket.

Utiliser des objets ClusterSelector et NamespaceSelector

Les branches Git sont un bon moyen d'effectuer un déploiement par étapes de modifications sur plusieurs clusters qui auront à terme toutes les mêmes stratégies. Toutefois, si vous souhaitez déployer une modification uniquement sur un sous-ensemble de clusters ou d'espaces de noms, utilisez les objets ClusterSelector et NamespaceSelector. Ces objets ont un objectif similaire : ils ne vous permettent d'appliquer des objets qu'aux clusters ou aux espaces de noms possédant des libellés spécifiques.

Exemple :

• À l'aide des objets ClusterSelector, vous pouvez appliquer différentes stratégies aux clusters, en fonction du pays dans lequel ils se trouvent, pour différents taux de conformité.
• En utilisant des objets NamespaceSelector, vous pouvez appliquer différentes stratégies aux espaces de noms utilisés par une équipe interne et par un prestataire externe.

Les objets ClusterSelector et NamespaceSelector vous permettent également de mettre en œuvre des méthodologies de test et de publication avancées, telles que :

• Les versions Canary de stratégies, où vous déployez une nouvelle stratégie sur un petit sous-ensemble de clusters et d'espaces de noms pendant une longue période pour étudier l'impact de la stratégie.
• Les tests A/B, dans lesquels vous déployez différentes versions de la même stratégie sur différents clusters afin d'étudier la différence de l'impact des versions de stratégies, puis choisissez la plus performante à déployer partout.

Par exemple, imaginons une organisation avec plusieurs clusters de production. L'équipe chargée de la plate-forme a déjà créé deux catégories de clusters de production, appelées canary-prod et prod, à l'aide des objets Cluster et ClusterSelector (voir Utiliser les objets ClusterSelector).

L'équipe chargée de la plate-forme souhaite déployer une stratégie avec Policy Controller pour appliquer la présence d'un libellé d'équipe sur les espaces de noms afin d'identifier l'équipe à laquelle chaque espace de noms appartient. Elle a déjà déployé une version de cette stratégie en simulation et elle souhaite désormais l'appliquer sur un petit nombre de clusters. À l'aide des objets ClusterSelector, elle crée deux ressources K8sRequiredLabels différentes, qui sont appliquées à différents clusters.

• La ressource K8sRequiredLabels est appliquée aux clusters de type prod, avec un paramètre enforcementAction défini sur dryrun :

  apiVersion: constraints.gatekeeper.sh/v1beta1
  kind: K8sRequiredLabels
  metadata:
    name: ns-must-have-team
    annotations:
      configmanagement.gke.io/cluster-selector: prod
  Spec:
    enforcementAction: dryrun
    match:
      kinds:
        - apiGroups: [""]
          kinds: ["Namespace"]
    parameters:
      labels:
        - key: "team"
  

• La ressource K8sRequiredLabels est appliquée aux clusters de type canary-prod, sans le paramètre enforcementAction, ce qui signifie que la stratégie est effectivement appliquée :

  apiVersion: constraints.gatekeeper.sh/v1beta1
  kind: K8sRequiredLabels
  metadata:
    name: ns-must-have-team
    annotations:
      configmanagement.gke.io/cluster-selector: canary-prod
  spec:
    match:
      kinds:
        - apiGroups: [""]
      kinds: ["Namespace"]
    parameters:
      labels:
        - key: "team"
  

L'annotation configmanagement.gke.io/cluster-selector permet à l'équipe d'appliquer la stratégie uniquement dans des clusters de type canary-prod, empêchant ainsi les effets secondaires non désirés sur l'ensemble du parc de production. Pour plus d'informations sur la fonctionnalité de simulation de Policy Controller, consultez la section Créer des contraintes.

Nous vous recommandons d'effectuer les actions suivantes :

• Utilisez les objets ClusterSelector et NamespaceSelector si vous devez appliquer une modification de configuration à un sous-ensemble de clusters ou d'espaces de noms indéfiniment ou pendant une longue période.
• Si vous déployez une modification à l'aide de sélecteurs, soyez très prudent. Si vous utilisez des commits Git, toute erreur n'affecte qu'un cluster à la fois, car vous déployez cluster par cluster. Toutefois, si vous utilisez des branches Git, toute erreur peut affecter tous les clusters utilisant cette branche. Si vous utilisez des sélecteurs, l'erreur peut affecter tous les clusters simultanément.

Mettre en œuvre des avis, des tests et des validations

L'un des avantages de Config Sync est qu'il gère tout de manière déclarative : les ressources Kubernetes, les ressources cloud et les stratégies. Cela signifie que les fichiers d'un système de gestion de contrôle source représentent les ressources (fichiers Git, dans le cas de Config Sync). Cette caractéristique vous permet de mettre en œuvre des workflows de développement que vous utilisez déjà pour le code source d'une application : les avis et les tests automatisés.

Mettre en œuvre des avis

Étant donné que Config Sync est basé sur Git, vous pouvez utiliser votre solution Git préférée pour héberger le dépôt Config Sync. Votre solution Git dispose probablement d'une fonctionnalité de revue de code, que vous pouvez utiliser pour examiner les modifications apportées au dépôt Config Sync.

Les bonnes pratiques pour examiner les modifications apportées au dépôt sont les mêmes que pour un examen normal du code, comme suit :

• Entraînez-vous au développement à branche unique.
• Travaillez par petits lots.
• Assurez-vous que l'examen du code est effectué de manière synchrone ou au moins rapidement.
• La personne qui examine et approuve la modification ne doit pas être la personne à l'origine de la modification.

En raison du caractère sensible du code de base de Config Sync, nous vous recommandons également, si possible avec votre solution Git, d'effectuer les configurations suivantes :

• Protégez les branches utilisées directement par les clusters. Consultez la documentation de GitHub, GitLab et Bitbucket. GitLab vous permet également de protéger les tags.
• Une fois les branches protégées, vous pouvez affiner les approbations nécessaires à la fusion d'une modification :
  • Sur GitHub, activez les avis requis.
  • Pour GitLab, faites appel à des propriétaires de code pour déléguer des autorisations d'approbation au niveau d'un fichier ou d'un répertoire. Vous pouvez utiliser les approbations de demandes de fusion pour demander à des utilisateurs appartenant à différentes équipes d'approuver une demande avant sa fusion.
  • Sur Bitbucket, combinez des examinateurs par défaut et des vérifications de fusion par défaut. Vous pouvez éventuellement utiliser un plug-in "Propriétaires de code" pour le serveur Bitbucket disponible sur Atlassian Marketplace afin de contrôler qui peut approuver les modifications pour les sous-sections du dépôt.

En utilisant ces différentes fonctionnalités, vous pouvez appliquer des approbations à chaque requête de modification adressée à votre codebase. Par exemple, vous pouvez vérifier que chaque modification est approuvée au moins par un membre de l'équipe chargée de la plate-forme (qui gère le parc de clusters), et par un membre de l'équipe de sécurité (chargé de définir et mettre en œuvre des stratégies de sécurité).

Nous vous recommandons d'effectuer les actions suivantes :

• Appliquez les avis de pairs sur votre dépôt et protégez les branches Git utilisées par vos clusters.

Mettre en œuvre des tests automatisés

Une bonne pratique courante lorsque vous travaillez sur un codebase consiste à mettre en œuvre l'intégration continue. Cela signifie que vous configurez les tests automatisés à exécuter lorsqu'une demande de modification est créée ou mise à jour. Les tests automatisés peuvent détecter de nombreuses erreurs avant qu'un utilisateur n'examine la demande de modification. Cela permet de renforcer la boucle de rétroaction pour le développeur. Vous pouvez mettre en œuvre la même idée en utilisant les mêmes outils pour le dépôt Config Sync.

Par exemple, pour commencer, vous devez exécuter la commande nomos vet automatiquement en cas de nouvelles modifications. Cette commande valide la syntaxe de votre dépôt Config Sync. Vous pouvez mettre en œuvre ce test à l'aide de Cloud Build en suivant le tutoriel Valider les configurations. Vous pouvez intégrer Cloud Build aux options suivantes :

• Bitbucket, avec des déclencheurs de compilation.
• GitHub, à l'aide de l'application GitHub Google Cloud Build. Les déclencheurs de compilation sont également disponibles pour GitHub, mais l'application GitHub est la méthode d'intégration recommandée.

Comme vous pouvez le voir dans le tutoriel Valider les configurations, le test est effectué à l'aide d'une image de conteneur. Vous pouvez donc mettre en œuvre le test dans toute solution d'intégration continue qui exécute des conteneurs, et pas uniquement Cloud Build.

Pour renforcer encore la boucle de rétroaction, vous pouvez demander aux utilisateurs d'exécuter la commande nomos vet en tant que hook de pré-commit Git. Premièrement, certains utilisateurs peuvent ne pas avoir accès aux clusters Kubernetes gérés par Config Sync et risquent de ne pas pouvoir exécuter la validation complète depuis leur poste de travail. Exécutez la commande nomos vet --clusters "" pour limiter la validation aux vérifications sémantiques et syntaxiques.

Nous vous recommandons d'effectuer les actions suivantes :

• Mettre en œuvre des tests dans un pipeline d'intégration continue.
• Exécutez au moins la commande nomos vet sur toutes les modifications suggérées.

Suivre les déploiements

Même si vous mettez en œuvre toutes les mesures couvertes dans ce document, des erreurs peuvent toujours se produire. Voici deux types courants d'erreurs :

• Erreurs qui ne posent aucun problème à Config Sync lui-même, mais empêchent vos charges de travail de fonctionner correctement, comme une stratégie NetworkPolicy trop restrictive qui empêche les composants de votre charge de travail de communiquer.
• Erreurs empêchant Config Sync d'appliquer les modifications à un cluster, telles qu'un fichier manifeste Kubernetes non valide ou un objet refusé par un contrôleur d'admission. Les méthodes expliquées précédemment devraient détecter la plupart de ces erreurs.

La détection des erreurs décrites dans le premier point précédent est presque impossible au niveau de Config Sync, car cela nécessite de comprendre l'état de chacune de vos charges de travail. Pour cette raison, il est préférable de détecter ces erreurs par votre système de surveillance existant, qui vous avertit lorsqu'une application présente un dysfonctionnement.

La détection des erreurs décrites dans le deuxième point précédent, qui doit être atténué si vous avez mis en œuvre tous les garde-fous, nécessite une configuration spécifique. Par défaut, Config Sync écrit les erreurs dans ses journaux (que vous trouverez par défaut, dans Cloud Logging). Les erreurs sont également affichées sur la page de la console Google Cloud de Config Sync. Ni les journaux, ni la console ne suffisent généralement à détecter les erreurs, car vous ne les utilisez probablement pas toujours. Le moyen le plus simple d'automatiser la détection des erreurs consiste à exécuter la commande nomos status, qui indique si une erreur se produit dans un cluster.

Vous pouvez également configurer une solution plus avancée avec des alertes automatiques pour les erreurs. Config Sync expose les métriques au format Prometheus. Pour en savoir plus, consultez la section Surveiller Config Sync.

Une fois les métriques Config Sync dans votre système de surveillance, créez une alerte pour vous avertir lorsque la métrique gkeconfig_monitor_errors est supérieure à 0. Pour plus d'informations, consultez la section Gérer les règles d'alerte pour Cloud Monitoring ou les règles d'alerte pour Prometheus.

Résumé des mécanismes de déploiement sécurisé avec Config Sync

Le tableau suivant récapitule les différents mécanismes décrits précédemment dans ce document. Aucun de ces mécanismes n'est exclusif. Vous pouvez choisir de les utiliser tous ou une partie, à des fins différentes.

Mécanisme	Points forts	Points faibles	Exemple d'utilisation
ID de commit et tags Git	Utilisez des ID ou des tags de commit Git spécifiques pour contrôler avec précision les modifications de cluster appliquées.	N'utilisez pas d'ID de commit ni de tags Git pour les différences à long terme entre les clusters. Utilisez des sélecteurs de cluster.	Tous vos clusters sont configurés pour appliquer le commit Git 12345. Apportez une modification avec un nouveau commit, abcdef, que vous souhaitez tester. Vous devez modifier la configuration d'un seul cluster pour qu'il utilise ce nouveau commit pour valider la modification.
Branches Git	Utilisez plusieurs branches Git lorsque vous souhaitez déployer la même modification dans plusieurs environnements, l'un après l'autre.	N'utilisez pas plusieurs branches Git pour des différences de longue durée entre les clusters. Les branches seront très diversifiées et seront difficiles à fusionner.	Commencez par fusionner la modification dans la branche de préproduction, où elle sera récupérée par les clusters de préproduction. Fusionnez ensuite la modification dans la branche principale, où elle sera récupérée par les clusters de production.
Sélecteurs de clusters et sélecteurs d'espace de noms	Utilisez des sélecteurs pour les différences de longue durée entre les clusters et les espaces de noms.	N'utilisez pas de sélecteurs pour un déploiement par étapes dans plusieurs environnements. Si vous souhaitez d'abord tester une modification au cours de la préproduction, puis la déployer en production, utilisez des branches Git distinctes.	Si les équipes de développement d'applications ont besoin d'un accès complet aux clusters de développement, mais à un accès en lecture seule aux clusters de production, utilisez l'objet ClusterSelector pour n'appliquer les stratégies RBAC appropriées qu'aux clusters appropriés.
Avis des pairs	Utilisez des examens par des pairs pour vous assurer que les équipes concernées approuvent les modifications.	Les évaluateurs manuels ne détectent pas toutes les erreurs, en particulier les éléments tels que les erreurs de syntaxe.	Votre organisation exige que l'équipe responsable de la sécurité examine les modifications de configuration qui affectent plusieurs systèmes. Demandez à un membre de l'équipe de sécurité d'examiner les modifications.
Tests automatisés dans le pipeline d'intégration continue	Servez-vous de tests automatisés pour détecter les erreurs dans les modifications suggérées.	Les tests automatisés ne peuvent pas remplacer complètement un examinateur manuel. Utilisez les deux.	L'exécution d'une commande nomos vet sur toutes les modifications suggérées confirme que le dépôt est une configuration Config Sync valide.
Surveiller les erreurs de synchronisation	Assurez-vous que Config Sync applique réellement les modifications à vos clusters.	Les erreurs de synchronisation ne se produisent que si Config Sync tente d'appliquer un dépôt non valide ou si le serveur d'API Kubernetes rejette certains des objets.	Un utilisateur contourne tous vos tests et examens, et valide une modification non valide dans le dépôt Config Sync. Cette modification ne peut pas être appliquée à vos clusters. Si vous surveillez les erreurs de synchronisation, vous recevrez une alerte en cas d'erreur.

Exemple de stratégie de déploiement

Cette section utilise les concepts présentés dans la suite de cet article pour vous aider à créer une stratégie de déploiement de bout en bout sur tous les clusters de votre organisation. Dans cette stratégie, nous partons du principe que vous disposez d'un parc distinct pour le développement, la préproduction et la production (comme indiqué dans l'exemple Parc 1 : Méthode 1).

Avertissement : Cette stratégie de déploiement est complexe. Il est judicieux de la mettre en œuvre uniquement si vous disposez d'une infrastructure complexe avec au moins deux parcs, et au moins trois clusters par parc. Si vous disposez d'un grand nombre de parcs, mais d'un seul cluster dans chacun d'entre eux, vous pouvez adapter cette stratégie en ayant des "parcs Canary" au lieu de "clusters Canary".

Dans ce scénario, vous configurez chaque cluster à synchroniser avec votre dépôt Git à l'aide d'un commit Git spécifique. Le déploiement d'une modification dans un parc donné est un processus en quatre étapes :

1. Mettez à jour un cluster unique (le "Canary") dans le parc pour utiliser d'abord le nouveau commit.
2. Vérifiez que tout fonctionne comme prévu en exécutant des tests et en surveillant le déploiement.
3. Mettez à jour le reste des clusters du parc.
4. Confirmez à nouveau que tout fonctionne comme prévu.

Pour déployer une modification sur l'ensemble de vos clusters, répétez cette procédure pour chaque parc. Vous pouvez appliquer cette méthode de manière technique avec n'importe quel commit Git, depuis n'importe quelle branche. Toutefois, nous vous suggérons d'adopter le processus suivant pour identifier les problèmes tôt dans le processus de vérification :

1. Lorsqu'un utilisateur ouvre une demande de modification dans le dépôt Git de Config Sync, déployez cette modification dans l'un des clusters de développement.
2. Si la demande de modification est acceptée et fusionnée dans votre branche principale, exécutez le déploiement complet sur tous les parcs comme décrit précédemment.

Bien que certaines modifications puissent ne cibler qu'un parc spécifique, nous vous recommandons de déployer toutes les modifications dans tous les parcs à terme. Cette stratégie élimine le problème de suivi du parc à synchroniser avec le commit dédié. Portez une attention particulière aux modifications qui ciblent uniquement le parc de production, car des tests appropriés n'auraient pas été possibles dans les parcs précédents. Par exemple, cela signifie que vous devez attendre plus longtemps pour que les problèmes surviennent entre le déploiement sur les clusters Canary et le reste des clusters.

Pour résumer, un déploiement de bout en bout ressemble à ceci :

1. Quelqu'un ouvre une demande de modification.
2. Des tests et des validations automatisés sont exécutés, et une vérification manuelle est réalisée.
3. Vous déclenchez une tâche manuellement pour déployer la modification sur le cluster Canary dans le parc de développement. Des tests automatisés de bout en bout s'exécutent dans ce cluster.
4. Si tout fonctionne correctement, fusionnez la demande de modification sur la branche principale.
5. La fusion déclenche une tâche automatisée pour déployer le nouveau commit de conseil d'application de la branche principale dans le cluster Canary du parc de développement. Des tests automatisés de bout en bout sont exécutés dans ce cluster (pour détecter les incompatibilités potentielles entre deux demandes de modification qui ont été créées et fusionnées approximativement à la même heure).
6. Les tâches suivantes sont exécutées l'une après l'autre (vous les déclenchez manuellement ou après une heure prédéfinie pour permettre la création de rapports utilisateur sur des régressions) :
   1. Déployez sur tous les clusters du parc de développement.
   2. Exécutez des tests et des validations sur les clusters du parc de développement.
   3. Déployez sur le cluster Canary du parc de préproduction.
   4. Exécutez des tests et des validations sur le cluster Canary du parc de préproduction.
   5. Déployez sur tous les clusters du parc de préproduction.
   6. Exécutez des tests et des validations sur les clusters du parc de préproduction.
   7. Déployez sur le cluster Canary du parc de production.
   8. Exécutez des tests et des validations sur le cluster Canary du parc de production.
   9. Déployez sur tous les clusters du parc de production.
   10. Exécutez des tests et des validations sur les clusters du parc de production.

Étapes suivantes

• Découvrez comment surveiller Config Sync.
• Obtenez des informations sur les parcs.
• Découvrez comment valider votre application par rapport aux stratégies de votre entreprise dans un pipeline d'intégration continue.