Déployer le plan

Vous disposez déjà d'un pipeline CI/CD.

Vous pouvez utiliser l'architecture du parc et du cluster du plan même lorsque différents produits sont utilisés pour la compilation et le déploiement d'applications. Nous vous recommandons d'au moins dupliquer les images dans deux régions.

Leur structure organisationnelle existante ne correspond pas au plan d'entreprise de base.

Il est recommandé d'avoir au moins deux environnements pour des déploiements séquentiels plus sécurisés. Vous n'avez pas besoin de déployer des environnements dans des VPC ou des dossiers partagés distincts. Toutefois, ne déployez pas de charges de travail appartenant à différents environnements dans le même cluster.

N'utilisez pas l'IaC.

Si le processus de déploiement de votre application actuel n'utilise pas l'IaC, vous pouvez évaluer votre aptitude à l'aide du modèle de maturité Terraform sur Google Cloud. Importez des ressources existantes dans un autre projet Terraform organisé de manière similaire à ce modèle, avec la séparation des pipelines multi-tenants et par locataire. Pour créer des clusters, vous pouvez utiliser des modules Terraform pour Google Cloud.

Les clusters sont répartis sur plusieurs projets dans le même environnement.

Vous pouvez regrouper des clusters issus de plusieurs projets dans un parc. Vérifiez que vos espaces de noms ont une signification unique au sein d'un même parc. Avant d'ajouter des clusters à un parc, demandez aux équipes de déplacer leurs applications vers un espace de noms portant un nom unique (par exemple, pas default).

Vous pouvez ensuite regrouper des espaces de noms en portées.

Les clusters se trouvent dans une seule région.

Vous n'avez pas besoin d'utiliser plusieurs régions en production et hors production pour adopter le modèle.

Il existe différents ensembles d'environnements.

Vous pouvez modifier le modèle pour qu'il prenne en charge plus ou moins de trois environnements.

La création de clusters est déléguée aux équipes des développeurs ou des opérateurs d'applications.

Pour obtenir la plate-forme de développement la plus sécurisée et la plus cohérente, vous pouvez essayer de transférer la propriété des clusters des équipes d'applications à l'équipe de la plate-forme de développement. Si ce n'est pas possible, vous pouvez toujours adopter de nombreuses pratiques du modèle. Par exemple, vous pouvez ajouter les clusters appartenant à différentes équipes d'applications à un parc. Toutefois, lorsque vous combinez des clusters avec une propriété indépendante, n'utilisez pas la fédération d'identité de charge de travail pour GKE ou Cloud Service Mesh, car ils ne permettent pas de contrôler suffisamment qui peut valider quelles identités de charge de travail. Utilisez plutôt une règle d'administration personnalisée pour empêcher les équipes d'activer ces fonctionnalités sur les clusters GKE.

Lorsque les clusters sont regroupés dans un parc, vous pouvez toujours auditer et appliquer des règles. Vous pouvez utiliser une règle d'administration personnalisée pour exiger que des clusters soient créés dans un parc qui correspond au dossier d'environnement dans lequel se trouve le projet du cluster. Vous pouvez utiliser la configuration par défaut du parc pour exiger que les nouveaux clusters utilisent le contrôle des règles.

Toutes les applications s'exécutent dans le même ensemble de cinq clusters.

Le plan utilise un ensemble de cinq clusters (deux en production, deux hors production et un en développement). Vous pouvez modifier le modèle pour créer des ensembles supplémentaires de cinq clusters.

Attribuez des applications à des ensembles de cinq clusters. Ne liez pas les portées ou les espaces de noms de parc d'une application aux clusters des autres ensembles. Vous pouvez séparer les applications en différents ensembles de cluster pour effectuer des activités telles que :

• Regrouper quelques applications ayant des problématiques réglementaires particulières (par exemple, PCI-DSS)
• Isoler les applications qui nécessitent un traitement spécial lors des mises à niveau du cluster (par exemple, les applications avec état utilisant des volumes persistants)
• Isoler les applications avec des profils de sécurité risqués (par exemple, traitement de contenu fourni par l'utilisateur dans un langage non sécurisé)
• Isoler les applications qui nécessitent des GPU, une sensibilité aux coûts et une sensibilité aux performances
• Si vous approchez la limite de clusters GKE du nombre de nœuds (15 000), vous pouvez créer un ensemble de clusters.
• Utilisez un autre VPC partagé pour les applications qui doivent s'exécuter dans un périmètre VPC Service Controls. Créez un ensemble de clusters dans le périmètre et un ensemble de clusters en dehors du périmètre.

Évitez de créer des ensembles de clusters pour chaque application ou locataire, car cette pratique peut entraîner l'une des situations suivantes :

• Applications qui n'utilisent pas correctement la taille minimale du cluster (3 VM x 2 régions), même avec les plus petits types d'instances disponibles
• Opportunités manquées de réduction des coûts liés au bin packing d'autres applications
• Planification des croissances de capacité fastidieuse et incertaine, car la planification est appliquée à chaque application individuellement. Les prédictions de capacité sont plus précises lorsqu'elles sont effectuées de manière globale pour un large ensemble d'applications.
• Retards de création de clusters pour les nouveaux locataires ou applications, ce qui réduit la satisfaction des locataires concernant la plate-forme. Par exemple, dans certaines organisations, les allocations d'adresses IP requises peuvent prendre du temps et nécessiter des approbations supplémentaires.
• Atteindre la limite de cluster privé dans un réseau VPC.

Les environnements de production et hors production comportent des clusters dans deux régions.

Pour réduire la latence pour les utilisateurs finaux dans plusieurs régions, vous pouvez déployer les charges de travail de production et hors production dans plus de deux régions (par exemple, trois régions pour la production, trois régions hors production et une région de développement). Cette stratégie de déploiement augmente les coûts et les frais généraux liés à la maintenance de ressources dans des régions supplémentaires.

Si toutes les applications ont des exigences de disponibilité inférieures, vous pouvez déployer des charges de travail de production et hors production dans une seule région (un environnement de production, un environnement hors production et un environnement de développement). Cette stratégie permet de réduire les coûts, mais ne garantit pas le même niveau de disponibilité qu'une architecture birégionale ou multirégionale.

Si les applications ont des exigences de disponibilité différentes, vous pouvez créer différents ensembles de clusters pour différentes applications (par exemple, cluster-set-1 avec deux environnements de production, deux environnements hors production, un environnement de développement et cluster-set-2 avec un environnement de production, un environnement hors production et un environnement de développement.

La topologie en étoile correspond mieux à vos exigences que le VPC partagé.

Vous pouvez déployer le plan dans une configuration hub-and-spoke, où chaque environnement (développement, production et hors production) est hébergé dans son propre spoke. La topologie en étoile peut renforcer la ségrégation des environnements. Pour en savoir plus, consultez la section Topologie de réseau en hub et spoke.

Chaque application dispose d'un dépôt Git distinct.

Certaines organisations utilisent un seul dépôt Git (un monorepo) pour l'ensemble du code source au lieu de plusieurs dépôts. Si vous utilisez un monorepo, vous pouvez modifier le composant Fabrique d'applications du plan pour assurer la compatibilité avec votre dépôt. Effectuer les actions suivantes :

• Au lieu de créer un dépôt pour chaque nouvelle application, créez un sous-répertoire dans le dépôt existant.
• Au lieu d'accorder des autorisations de propriétaire sur le nouveau dépôt au groupe de développeurs de l'application, accordez une autorisation d'écriture sur le dépôt existant et faites du groupe de développeurs de l'application un examinateur obligatoire pour les modifications apportées au nouveau sous-répertoire. Utilisez la fonctionnalité CODEOWNERS et la protection des branches.