Le plan de l'application d'entreprise est déployé via une série de systèmes et de pipelines automatisés. Chaque pipeline déploie un aspect particulier du plan. Les pipelines fournissent un mécanisme contrôlable, auditable et reproductible pour la création du plan. Le schéma suivant illustre l'interaction des différents pipelines, dépôts et personas.
Le plan utilise les pipelines suivants:
- Le pipeline d'infrastructure de base (qui fait partie du plan de base de l'entreprise) déploie la fabrique d'applications, le pipeline d'infrastructure mutualisée et le pipeline de niveau d'accès au parc.
- Le pipeline d'infrastructure mutualisée déploie les clusters GKE, ainsi que les autres services gérés sur lesquels repose le plan de l'application d'entreprise.
- Le pipeline de niveau d'accès au parc configure les niveaux d'accès au parc, les espaces de noms, ainsi que les rôles et les liaisons RBAC.
- L'usine d'applications fournit un mécanisme permettant de déployer de nouveaux pipelines d'applications via un processus modélisé.
- Le pipeline CI/CD d'application fournit un pipeline CI/CD pour déployer des services dans des clusters GKE.
- Config Sync déploie et gère des configurations Kubernetes supplémentaires, y compris les contraintes Policy Controller.
Dépôts, contributeurs de dépôts et approbateurs des modifications de dépôt
Les pipelines de plan sont déclenchés par le biais des modifications apportées aux dépôts Git. Le tableau suivant décrit les dépôts utilisés dans le plan, qui contribuent au dépôt, qui approuve les modifications apportées au dépôt, quel pipeline utilise le dépôt et décrit ce que contient le dépôt.
| Dépôt | Contributeur du dépôt | Validateur des modifications de dépôt | Pipeline | Description |
|---|---|---|---|---|
|
Développeur de la plate-forme de développement |
Administrateur de la plate-forme pour les développeurs |
Pipeline d'infrastructure de base |
Dépôt contenant le code permettant de déployer le pipeline d'infrastructure mutualisée, l'application et le pipeline du niveau d'accès au parc |
|
Développeur de la plate-forme de développement |
Administrateur de la plate-forme pour les développeurs |
Infrastructure mutualisée |
Les modules Terraform utilisés par les équipes de plate-forme de développement lors de la création de l'infrastructure |
|
Développeur de la plate-forme de développement |
Administrateur de la plate-forme pour les développeurs |
Niveaux d'accès au parc |
Dépôt qui définit les niveaux d'accès et les espaces de noms de l'équipe du parc dans le parc. |
|
Développeur de la plate-forme de développement |
Administrateur de la plate-forme pour les développeurs |
Usine d'applications |
Le code qui définit le dépôt d'application et fait référence aux modules du dépôt |
|
Développeur d'applications |
Opérateur d'application |
Usine d'applications |
Code de base placé dans le dépôt |
|
Développeur de la plate-forme de développement |
Administrateur de la plate-forme pour les développeurs |
Usine d'applications Infrastructure mutualisée |
Les modules Terraform qui définissent l'application et l'infrastructure |
|
Développeur d'applications |
Opérateur d'application |
CI/CD des applications |
Le code de l'application déployé dans les clusters GKE |
|
Développeur de la plate-forme de développement |
Administrateur de la plate-forme pour les développeurs |
Config Sync |
Les stratégies utilisées par les clusters GKE pour gérer leurs configurations |
Les pipelines automatisés permettent de renforcer la sécurité, l'auditabilité, la traçabilité, la reproductibilité, la contrôlabilité et la conformité dans le processus de déploiement. En utilisant différents systèmes avec des autorisations différentes et en plaçant différentes personnes dans différents groupes d'exploitation, vous créez une séparation des responsabilités et suivez le principe du moindre privilège.
Pipeline d'infrastructure de base
Le pipeline d'infrastructure de base est décrit dans le plan de base de l'entreprise et est utilisé comme point d'entrée générique pour d'autres déploiements de ressources. Le tableau suivant décrit les composants créés par le pipeline.
| Composant | Description |
|---|---|
Crée l'infrastructure partagée utilisée par tous les locataires de la plate-forme de développement. |
|
Crée des espaces de noms et des liaisons de rôle RBAC. |
|
Crée les pipelines d'application CI/CD utilisés pour déployer les services. |
Pipeline d'infrastructure mutualisée
Le pipeline d'infrastructure mutualisée déploie des parcs, des clusters GKE et des ressources partagées associées. Le schéma suivant montre les composants du pipeline d'infrastructure mutualisée.
Le tableau suivant décrit les composants créés par le pipeline d'infrastructure mutualisée.
| Composant | Description |
|---|---|
Clusters GKE |
Fournit l'hébergement pour les services de l'application conteneurisée. |
Policy Controller |
Fournit des règles qui contribuent à garantir la bonne configuration des clusters et services GKE. |
Config Sync |
Applique les règles Policy Controller aux clusters et assure l'application cohérente des règles. |
Crée la clé de chiffrement basée sur la clé de chiffrement gérée par le client (CMEK) pour GKE, AlloyDB pour PostgreSQL et Secret Manager. |
|
Secret Secret Manager |
Fournit un magasin de secrets pour la paire de clés RSA utilisée pour l'authentification des utilisateurs avec les jetons Web JSON (JWT). |
Il fournit la stratégie utilisée par le pare-feu d'application Web Google Cloud Armor. |
Pipeline de niveaux d'accès au parc
Le pipeline de niveau d'accès au parc est chargé de configurer les espaces de noms et les liaisons RBAC dans les clusters GKE du parc. Le tableau suivant décrit les composants créés par le pipeline de niveau d'accès au parc.
| Composant | Description |
|---|---|
Définit les clusters logiques au sein du cluster physique. |
|
Définit l'autorisation dont dispose un compte de service Kubernetes au niveau du cluster ou de l'espace de noms. |
Usine d'applications
L'usine d'applications est déployée par le pipeline d'infrastructure de base et permet de créer une infrastructure pour chaque nouvelle application. Cette infrastructure inclut un projet Google Cloud qui contient le pipeline CI/CD de l'application.
À mesure que les organisations d'ingénieurs évoluent, l'équipe applications peut intégrer de nouvelles applications à l'aide de l'usine d'applications. Le scaling permet la croissance en ajoutant des pipelines d'application CI/CD distincts et en prenant en charge l'infrastructure pour le déploiement de nouvelles applications au sein de l'architecture mutualisée. Le schéma suivant illustre l'usine d'applications.
L'usine d'applications comprend les composants suivants:
- Dépôt de fabrique d'applications: dépôt Git qui stocke la définition d'application déclarative.
- Pipelines pour créer des applications: pipelines qui nécessitent que Cloud Build effectue les opérations suivantes :
- Créer une définition d'application déclarative et stockez-la dans le catalogue d'applications.
- Appliquez la définition de l'application déclarative pour créer les ressources de l'application.
- Dépôt de modèles d'application de démarrage: modèles permettant de créer une application simple (par exemple, un microservice Python, Golang ou Java).
- Modules partagés: modules Terraform créés avec des pratiques standards et utilisés à plusieurs fins, y compris l'intégration et le déploiement d'applications.
Le tableau suivant répertorie les composants créés par l'usine d'applications pour chaque application.
| Composant | Description |
|---|---|
Dépôt du code source de l'application |
Contient le code source et la configuration associée utilisés pour créer et déployer une application spécifique. |
Pipeline CI/CD d'application |
Un pipeline basé sur Cloud Build qui permet de se connecter au dépôt de code source et fournit un pipeline CI/CD pour déployer des services d'application. |
Pipeline CI/CD d'application
Le pipeline CI/CD de l'application permet de créer et de déployer de manière automatisée des applications basées sur des conteneurs. Le pipeline se compose des étapes Intégration continue (CI) et Déploiement continu (CD). L'architecture du pipeline est basée sur le plan CI/CD sécurisé.
Le pipeline CI/CD de l'application utilise des images de conteneurs immuables dans tous vos environnements. Les images de conteneurs immuables permettent de garantir que la même image est déployée dans tous les environnements et n'est pas modifiée pendant l'exécution du conteneur. Pour mettre à jour le code de l'application ou appliquer un correctif, vous devez créer une image et la redéployer. L'utilisation d'images de conteneurs immuables nécessite d'externaliser votre configuration de conteneur afin que les informations de configuration soient lues pendant l'exécution.
Pour atteindre les clusters GKE via un chemin de réseau privé et gérer l'authentification kubeconfig, le pipeline CI/CD de l'application interagit avec les clusters GKE via la passerelle Connect. Le pipeline utilise également des pools privés pour l'environnement CI/CD.
Chaque dépôt de code source d'application inclut des configurations Kubernetes. Ces configurations permettent aux applications de s'exécuter correctement en tant que services Kubernetes sur GKE. Le tableau suivant décrit les types de configurations Kubernetes appliqués par le pipeline CI/CD de l'application.
| Composant | Description |
|---|---|
Définit un ensemble de pods mis à l'échelle (conteneurs). |
|
Rend un déploiement accessible sur le réseau du cluster. |
|
Définit un service comme faisant partie du maillage de services. |
|
Définit comment les pairs du maillage de services doivent atteindre un service virtuel. Utilisé dans le plan pour configurer l'équilibrage de charge de la zone pour le trafic est-ouest. |
|
Définit le contrôle des accès entre les charges de travail du maillage de services. |
|
Définit une identité utilisée par un service Kubernetes. Workload Identity Federation for GKE définit le compte de service Google Cloud utilisé pour accéder aux ressources Google Cloud. |
|
Permet au trafic entrant externe d'atteindre un service. La passerelle n'est requise que par les déploiements qui reçoivent du trafic externe. |
|
Configurez SSL, Google Cloud Armor, l'affinité de session et le drainage de connexion pour les déploiements qui reçoivent du trafic externe. GCPBackendPolicy n'est utilisé que par les déploiements qui reçoivent du trafic externe. |
|
Configure la collecte de métriques Prometheus exportées par une application. |
Intégration continue
Le schéma suivant illustre le processus d'intégration continue.
Le processus est le suivant:
- Un développeur procède au commit du code de l'application dans le dépôt source de l'application. Cette opération déclenche Cloud Build pour lancer le pipeline d'intégration.
- Cloud Build crée une image de conteneur, la transfère vers Artifact Registry et crée un condensé de l'image.
- Cloud Build effectue des tests automatisés pour l'application. Selon le langage de l'application, différents packages de test peuvent être exécutés.
- Cloud Build effectue les analyses suivantes sur l'image de conteneur :
- Cloud Build analyse le conteneur à l'aide du framework de test de structure de conteneur. Ce framework effectue des tests de commande, des tests d'existence de fichiers, des tests de contenu de fichiers et des tests de métadonnées.
- Cloud Build utilise l'analyse des failles pour identifier les failles de l'image de conteneur sur une base de données de failles gérée par Google Cloud.
- Cloud Build approuve l'image pour continuer dans le pipeline une fois les résultats de l'analyse réussies.
- L'autorisation binaire signe l'image. L'autorisation binaire est un service Google Cloud qui sécurise la chaîne d'approvisionnement logicielle pour les applications basées sur des conteneurs en utilisant des stratégies, des règles, des notes, des attestations, des certificateurs et des signataires. Au moment du déploiement, l'outil d'application de la stratégie d'autorisation binaire garantit la provenance du conteneur avant de l'autoriser au déploiement.
- Cloud Build crée une version dans Cloud Deploy pour lancer le processus de déploiement.
Pour afficher les informations de sécurité d'une compilation, accédez au panneau des insights sur la sécurité. Ces insights incluent les failles détectées à l'aide d'Artifact Analysis, ainsi que le niveau de sécurité de la compilation indiqué par les consignes SLSA.
Déploiement continu
Le schéma suivant illustre le processus de déploiement continu.
Le processus est le suivant:
- À la fin du processus de compilation, le pipeline CI/CD d'application crée une version Cloud Deploy pour lancer les nouvelles images de conteneurs progressivement dans chaque environnement.
- Cloud Deploy lance un déploiement dans le premier environnement du pipeline de déploiement, qui est généralement le développement. Chaque étape de déploiement est configurée pour nécessiter une approbation manuelle.
- Les pipelines Cloud Deploy utilisent un déploiement séquentiel pour déployer des images sur chaque cluster d'un environnement dans l'ordre.
- À la fin de chaque étape de déploiement, Cloud Deploy verifies les fonctionnalités des conteneurs déployés. Ces étapes peuvent être configurées dans la configuration Skaffold des applications.
Déployer une nouvelle application
Le schéma suivant montre comment l'usine d'applications et le pipeline CI/CD d'applications interagissent pour créer et déployer une nouvelle application.
Le processus de définition d'une nouvelle application est le suivant:
- Un opérateur d'application définit une nouvelle application au sein de son locataire en exécutant un déclencheur Cloud Build pour générer la définition de l'application.
- Le déclencheur ajoute une nouvelle entrée pour l'application dans Terraform et valide la modification dans le dépôt de l'usine d'applications.
- La modification validée déclenche la création de dépôts et de projets spécifiques à l'application.
- Cloud Build effectue les opérations suivantes :
- Crée deux dépôts Git pour héberger le code source et l'IaC de l'application.
- Transfère les fichiers manifestes Kubernetes pour les règles de réseau et la fédération d'identité de charge de travail pour GKE vers le dépôt de gestion de la configuration.
- Il crée le projet CI/CD de l'application et le déclencheur IaC Cloud Build.
- Le déclencheur IaC Cloud Build de l'application crée le pipeline CI/CD de l'application et le dépôt Artifact Registry dans le projet CI/CD de l'application.
- Config Sync déploie les règles de réseau et les configurations Workload Identity Federation for GKE sur les clusters GKE mutualisés.
- Le pipeline de création du niveau d'accès au parc crée le niveau d'accès et l'espace de noms du parc pour l'application sur des clusters GKE mutualisés.
- Le pipeline CI/CD de l'application effectue le déploiement initial de l'application sur les clusters GKE.
- L'équipe de développement utilise éventuellement le déclencheur IaC Cloud Build pour déployer des projets et des ressources supplémentaires (par exemple, des bases de données et d'autres services gérés) sur des projets à locataire unique dédiés, un pour chaque environnement.
Gestion de la configuration et des règles de GKE Enterprise
Dans le plan, les administrateurs de plate-forme de développeur utilisent Config Sync pour créer des configurations au niveau du cluster dans chaque environnement. Config Sync se connecte à un dépôt Git qui sert de source fiable pour l'état choisi de la configuration du cluster. Config Sync surveille en permanence l'état réel de la configuration au sein des clusters et corrige les écarts en appliquant des mises à jour pour garantir le respect de l'état choisi, malgré les modifications manuelles. Les configurations sont appliquées aux environnements (développement, hors production et production) à l'aide d'une stratégie d'embranchement sur le dépôt.
Dans ce plan, Config Sync applique les contraintes Policy Controller. Ces configurations définissent les contrôles de sécurité et de conformité définis par les administrateurs de plate-forme de développeur de l'organisation. Ce plan s'appuie sur d'autres pipelines pour appliquer d'autres configurations: les pipelines CI/CD d'application appliquent la configuration spécifique à l'application, et le pipeline de niveaux d'accès au parc crée des espaces de noms et des liaisons de rôles associées.
Étapes suivantes
- Découvrez l'architecture de l'application Cymbal Bank (document suivant de cette série).