Déployer le plan

Last reviewed 2024-04-19 UTC

Cette section décrit le processus que vous pouvez utiliser pour déployer le plan, ses conventions de nommage et les alternatives aux recommandations de plans.

Conclusion

Pour mettre en œuvre l'architecture décrite dans ce document, suivez la procédure décrite dans cette section.

Déployer le plan dans une nouvelle organisation

Pour déployer le plan dans une nouvelle organisation Google Cloud, procédez comme suit :

  1. Créez votre infrastructure de base à l'aide du plan de base de l'entreprise. Effectuer les actions suivantes :

    1. Créez une structure organisationnelle, y compris des dossiers pour séparer les environnements.
    2. Configurez les autorisations IAM de base pour accorder l'accès aux administrateurs de la plate-forme de développement.
    3. Créez le réseau VPC.
    4. Déployer le pipeline d'infrastructure de base.

    Si vous n'utilisez pas le plan de base de l'entreprise, consultez Déployer le plan sans le plan de base de l'entreprise.

  2. L'administrateur de plate-forme de développeur utilise le pipeline d'infrastructure de base pour créer le pipeline d'infrastructure mutualisée, le pipeline de fabrique d'applications et le pipeline de champ d'application de parc.

  3. L'administrateur de la plate-forme de développement utilise le pipeline d'infrastructure mutualisée pour déployer des clusters GKE et une infrastructure partagée.

  4. Les opérateurs d'applications utilisent la fabrique d'applications pour intégrer de nouvelles applications. Les opérateurs ajoutent une ou plusieurs entrées au dépôt d'usine d'applications, ce qui déclenche la création de ressources spécifiques à l'application.

  5. Les développeurs d'applications utilisent le pipeline CI/CD d'application dans leur infrastructure spécifique à l'application pour déployer des applications sur l'infrastructure mutualisée.

Déployer le plan sans le plan de base de l'entreprise

Si vous ne déployez pas le plan d'application d'entreprise sur le plan de base d'entreprise, procédez comme suit :

  1. Créez les ressources suivantes :
    • Hiérarchie d'organisation avec les dossiers development, nonproduction et production
    • Un réseau VPC partagé dans chaque dossier
    • Un schéma d'adresses IP qui prend en compte les plages d'adresses IP requises pour vos clusters GKE
    • Un mécanisme DNS pour vos clusters GKE
    • Des stratégies de pare-feu alignées sur votre stratégie de sécurité
    • Un mécanisme permettant d'accéder aux API Google Cloud via des adresses IP privées
    • Un mécanisme de connectivité avec votre environnement sur site
    • Une journalisation centralisée pour la sécurité et l'audit
    • Security Command Center pour la surveillance des menaces
    • Des stratégies organisationnelles alignées sur votre stratégie de sécurité
    • Un pipeline pouvant être utilisé pour déployer la fabrique d'applications, le pipeline d'infrastructure mutualisée et le pipeline à l'échelle du parc.
  2. Après avoir déployé les ressources, passez à l'étape 2 de la section Déployer le plan dans une nouvelle organisation.

Intégrer le plan dans votre déploiement GKE existant

Ce plan nécessite de déployer d'abord la plate-forme de développeur, puis de déployer des applications sur la plate-forme de développeur. Le tableau suivant explique comment utiliser le plan si des applications conteneurisées sont déjà en cours d'exécution sur Google Cloud.

Utilisation existante Stratégie de migration

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 au minimum de mettre en miroir les images dans deux régions.

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

Nous vous recommandons d'utiliser au moins deux environnements pour des déploiements séquentiels plus sûrs. Vous n'avez pas besoin de déployer des environnements dans des VPC partagés ou des dossiers distincts. Toutefois, ne déployez pas de charges de travail appartenant à des environnements différents 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 projet Terraform différent, organisé de la même manière que ce plan, avec la séparation des pipelines mutualisés 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 au sein du même environnement.

Vous pouvez regrouper des clusters de plusieurs projets dans un parc. Vérifiez que vos espaces de noms ont des significations uniques dans 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 les espaces de noms en champs d'application.

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

Différents ensembles d'environnements existent.

Vous pouvez modifier le plan de façon à ce qu'il soit compatible avec 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 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 applications vers l'équipe chargée de la plate-forme de développement. Si cela n'est pas possible, vous pouvez adopter de nombreuses pratiques liées aux plans. Par exemple, vous pouvez ajouter les clusters appartenant à différentes équipes de développement à un parc. Toutefois, lorsque vous combinez des clusters avec une propriété indépendante, n'utilisez pas Workload Identity ou Anthos 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 des 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 la création de clusters dans un parc correspondant 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.

Alternatives aux recommandations par défaut

Cette section décrit des alternatives aux recommandations par défaut incluses dans ce guide.

Zone de décision Autres solutions possibles

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 plan pour créer des ensembles supplémentaires de cinq clusters.

Attribuez des applications à des ensembles de cinq clusters. N'associez pas les champs d'application 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 cluster défini dans le périmètre et un cluster défini 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 possèdent 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 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 protège 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 répond mieux à vos exigences qu'un VPC partagé.

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

Chaque application possède 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 au groupe de développeurs d'applications des autorisations de propriétaire sur le nouveau dépôt, accordez une autorisation en écriture sur le dépôt existant et définissez le groupe de développeurs d'applications comme réviseur requis pour les modifications apportées au nouveau sous-répertoire. Utilisez la fonctionnalité CODEOWNERS et la protection des branches.

Étapes suivantes