CI/CD moderne avec GKE : un framework de livraison de logiciels

Ce document décrit un framework permettant d'implémenter des processus CI/CD (intégration continue/livraison continue) modernes sur une plate-forme de livraison de logiciels multi-équipes utilisant Google Kubernetes Engine.

Vous pouvez ensuite effectuer une itération sur la plate-forme afin d'améliorer les performances de développement et d'exploitation, y compris le processus de lancement, la fiabilité de la plate-forme et le temps de récupération en cas d'échec.

Ce document fait partie d'une série :

Ce document est destiné aux architectes d'entreprise et aux développeurs d'applications, ainsi qu'aux équipes chargées de la sécurité informatique, des DevOps et de l'ingénierie en fiabilité des sites (SRE). Une certaine expérience des outils et des processus de déploiement automatisés est utile pour comprendre les concepts présentés dans ce document.

Un cas de CI/CD moderne

Les processus CI/CD représentent une approche de développement de logiciels qui vous permet d'automatiser les phases de développement, de test et de déploiement du logiciel grâce à un certain nombre d'outils et de processus reproductibles.

Outre l'automatisation de la CI/CD, Kubernetes et les conteneurs ont permis aux entreprises d'obtenir des améliorations sans précédent en termes de rapidité de développement et de déploiement. Toutefois, même si l'adoption de Kubernetes et des conteneurs augmente, de nombreuses organisations ne profitent pas pleinement des avantages en termes de vitesse de publication, de stabilité et d'efficacité opérationnelle, car leurs pratiques CI/CD ne tirent pas pleinement parti des avantages Kubernetes et ne résolvent pas les problèmes d'opérations et de sécurité.

Une approche de CI/CD réellement moderne doit inclure bien plus que l'automatisation. Pour tirer pleinement parti des améliorations au niveau de la vitesse et de la sécurité, ainsi que de la puissance de Kubernetes et des conteneurs, vous devez optimiser l'intégration de vos applications, vos pratiques CI/CD et vos processus opérationnels.

En tirant parti de l'infrastructure cohérente proposée par la plate-forme GKE, des méthodes CI/CD uniformes et des bonnes pratiques de mise en œuvre, votre organisation peut bénéficier des avantages suivants pour le développement et les opérations :

  • Réduction du délai d'intégration des modifications.

    • Laissez les équipes chargées des opérations et de la sécurité créer et mettre à jour les bonnes pratiques pour le provisionnement des applications et des règles sur l'ensemble de la plate-forme.

    • Simplifiez l'intégration des applications en mettant à la disposition des équipes des projets de démarrage entièrement fonctionnels et déployables intégrés aux bonnes pratiques de votre organisation.

  • Réduction du temps nécessaire à la restauration du service.

    • Gérez l'ensemble de la configuration de manière déclarative à l'aide de GitOps pour réaliser des audits, des rollbacks et des examens simplifiés.

    • Standardisez les méthodologies de déploiement et de surveillance dans toute l'organisation afin de réduire le temps nécessaire à l'identification des facteurs déterminants liés à un problème ayant une incidence sur le service.

  • Augmentation de la fréquence de déploiement.

    • Assurez-vous que les développeurs d'applications peuvent effectuer des itérations indépendamment dans leurs propres bacs à sable de développement (ou zones de destination) sans interférer les uns avec les autres.

    • Utilisez GitOps pour le déploiement, l'amélioration de la gestion des versions et le suivi des modifications.

    • Mettez en œuvre des garde-fous pour que les équipes de service soient autorisées à déployer fréquemment.

    • Créez un processus de déploiement progressif pour un déploiement constant dans des environnements de préproduction, ce qui permet aux développeurs de déployer des modifications en production en toute confiance.

Pour découvrir comment ces avantages et concepts sont réalisés avec GKE et CI/CD, consultez les autres documents de cette série :

Évaluer l'état de préparation pour une approche moderne

Avant de mettre en œuvre des outils et des processus CI/CD modernes avec GKE, vous devez déterminer si votre organisation et vos équipes sont prêtes à adopter une nouvelle plate-forme.

Caractéristiques de l'organisation

L'adoption d'une plate-forme moderne nécessite l'assistance suivante de la direction de votre entreprise et de vos équipes techniques :

  • Sponsor au niveau de l'équipe dirigeante. L'adoption d'une plate-forme de livraison de logiciels représente généralement un effort considérable réalisé par plusieurs équipes pluridisciplinaires. Le processus entraîne généralement des modifications des rôles et des responsabilités, ainsi que des pratiques de développement logiciel. Pour réussir à adopter ces outils et techniques, vous avez besoin d'être épaulé par un ou plusieurs membres de l'équipe dirigeante. Les sponsors les plus efficaces sont les personnes qui considèrent ces modifications comme un processus continu d'amélioration et qui souhaitent donner de l'autonomie à leurs équipes plutôt que de les gérer.

  • Alignement des stratégies techniques et commerciales. Nous vous recommandons d'aligner vos équipes commerciales et techniques sur les quatre mesures de livraison de logiciels définies par DevOps Research and Assessment (DORA) : le délai de livraison des modifications, la fréquence de déploiement, le délai de restauration du service et le taux d'échec liés aux modifications. L'alignement de ces mesures permet à vos équipes commerciales et techniques de créer un objectif commun, qui leur permet de calculer ensemble le retour sur investissement, d'ajuster le taux de variation et de modifier le niveau d'investissement.

  • Ressources. Pour réussir, les équipes qui développent des pratiques CI/CD modernes et créent des chaînes d'outils ont besoin des ressources nécessaires : temps, employés et infrastructures. Ces équipes ont besoin de temps pour tester et sélectionner les meilleurs processus et outils. Dans l'idéal, ces équipes représentent de nombreuses fonctions dans le processus de livraison de logiciels et peuvent exploiter d'autres ressources au sein de l'entreprise. Enfin, les équipes doivent pouvoir provisionner l'infrastructure, y compris des ressources cloud et des outils logiciels.

  • Volonté d'adopter de nouveaux outils. Les outils et techniques CI/CD modernes sont souvent liés à de nouveaux outils et processus. Les équipes doivent tester ces processus et outils et être disposées à les adopter. Une boucle de rétroaction est nécessaire pour que les équipes en charge de la plate-forme puissent écouter l'opinion des équipes en charge des applications, des opérations et de la sécurité qui utilisent la plate-forme.

  • Préparation culturelle. Pour réussir à déployer et à adopter un système CI/CD moderne avec GKE, l'organisation et les équipes techniques qui développent le système doivent être prêtes à modifier la manière dont elles fonctionnent et collaborent. Par exemple, les équipes chargées du développement et des opérations doivent être disposés à accepter davantage de responsabilités au niveau de la sécurité, et les équipes chargées de la sécurité et des opérations doivent être disposées à simplifier les processus d'approbation des modifications.

Compétences techniques

L'adoption d'une approche CI/CD moderne exige également que vos équipes soient techniquement préparées comme suit :

  • Expérience des conteneurs. Les équipes qui adoptent des approches CI/CD modernes ont besoin d'une certaine expérience des conteneurs. Dans l'idéal, cette expérience inclut des techniques de développement permettant de créer des images de conteneurs et de combiner des conteneurs pour créer des systèmes plus volumineux.

  • Stratégie d'intégration continue. Les équipes doivent avoir une certaine expérience des outils CI (tels que Jenkins, TeamCity, Bamboo et CircleCI), ainsi que savoir effectuer certaines tâches d'intégration continue et des tests automatisés. Nous recommandons aux organisations de planifier l'amélioration de ces processus.

  • Automatisation des déploiements. Les équipes doivent avoir une certaine expérience de l'automatisation des déploiements. Les outils de déploiement automatisé incluent des scripts shell de base, Terraform, Chef ou Puppet. Il est essentiel de connaître les principes de base des outils et des processus de déploiement automatisé pour simplifier et automatiser les déploiements.

  • Architectures basées sur les services. Bien qu'il ne s'agisse pas d'une condition préalable à l'adoption des processus CI/CD modernes, l'adoption d'architectures modulaires et basées sur les services doit être un objectif à long terme des organisations qui souhaitent adopter les techniques et les outils CI/CD modernes avec GKE. Il a été démontré que les architectures basées sur les services améliorent la vélocité et la fiabilité.

  • Contrôle moderne de la source. Les outils de contrôle moderne de la source tels que Git permettent aux équipes d'établir des workflows tels que le développement à branche unique, les branches de fonctionnalités et les demandes de fusion.

Concevoir une CI/CD moderne avec GKE

Cette section décrit une plate-forme de livraison de logiciels et ses composants. Pour améliorer la performance de la livraison de logiciels, vous devez implémenter la CI/CD et les autres bonnes pratiques techniques qui permettent aux équipes de lancer les applications rapidement et de fonctionner efficacement.

Cette section traite également de l'infrastructure nécessaire au traitement du cycle de livraison des logiciels et à la gestion cohérente de cette infrastructure avec GKE. Enfin, cette section fournit un exemple de workflow de livraison de logiciels et montre comment les dépôts de démarrage simplifient l'intégration et la mise en œuvre des bonnes pratiques. Les considérations de conception suivantes sont examinées :

  • Plate-forme de livraison de logiciels. Le framework et les fonctionnalités techniques qui constituent les bases d'un processus de lancement d'applications ultra-rapide et fiable.

  • Infrastructure de plate-forme. Les composants d'infrastructure et les considérations en matière de gestion dont vous avez besoin pour créer la plate-forme et exécuter vos applications.

  • Workflow de livraison de logiciels. La façon dont les équipes collaborent pour créer, tester et déployer du code plus efficacement.

  • Dépôts de code. Des dépôts qui exécutent plusieurs fonctions, y compris stocker la logique métier réelle, la configuration spécifique à l'application et le code permettant de créer l'infrastructure. Il peut s'agir également de dépôts de démarrage qui facilitent l'adoption des bonnes pratiques et contribuent à maintenir la cohérence entre les processus automatisés.

  • Zones de destination de l'application. Entité logique permettant aux développeurs de déployer et d'effectuer une itération de manière autonome sur leurs applications à l'aide des garde-fous que vous mettez en place.

  • Modèle d'exploitation. Outils, processus et méthodes techniques permettant de gérer l'infrastructure et les applications qui composent la plate-forme.

  • Gouvernance. Processus et considérations dont vous avez besoin pour entretenir et gérer la plate-forme de livraison de logiciels.

Plates-formes de livraison de logiciels

Une plate-forme de livraison de logiciels unifie les outils et simplifie les processus nécessaires à la création, la livraison, le déploiement et l'exploitation d'applications.

La responsabilité de la maintenance de la configuration, de la stabilité, du temps d'activité et de l'évolutivité d'une application varie selon les équipes chargées de l'exploitation, de la sécurité et du développement. Cependant, tous les composants et les équipes doivent collaborer pour accélérer le lancement des applications. Bien que ce document décrit les méthodes visant à améliorer la gestion du contrôle du code source et l'observabilité des applications, il se concentre principalement sur l'intégration continue (CI), la livraison continue (CD) et la gestion de la configuration.

Pour créer une plate-forme de livraison de logiciels complète, vous avez besoin de chaque composant du schéma suivant :

La gestion de la plate-forme peut être partagée ou effectuée par des équipes spéciales.

Chacun de ces composants fournit des fonctionnalités au système et aux applications s'exécutant sur la plate-forme :

  • Surveillance de l'infrastructure. Niveau de base nécessaire pour la surveillance lors du provisionnement afin de vérifier le bon fonctionnement des clusters Google Kubernetes Engine (GKE), des instances de machine virtuelle (VM) et des autres infrastructures requises pour le bon fonctionnement des applications.

  • Orchestration de conteneurs. Plate-forme qui coordonne le déploiement et l'exploitation des applications basées sur des conteneurs. Kubernetes, GKE ou GKE Enterprise sont des exemples de plates-formes d'orchestration de conteneurs.

  • Container Registry. Stockage et contrôle d'accès pour les images de conteneur.

  • Intégration continue (CI). Processus d'attribution de tâches automatisées sur une application avant le déploiement. Les tâches CI incluent généralement la création, l'empaquetage et les tests. Les types de tâches varient en fonction de l'application et de l'organisation.

  • Livraison continue (CD). Processus de déploiement hautement automatisés et appliqués à une fréquence élevée. Les méthodologies incluent les approbations manuelles, les déploiements Canary, les déploiements bleu-vert ou les déploiements progressifs.

  • Règles. Les règles de sécurité et d'infrastructure définies par les équipes chargées des opérations et de la sécurité, et appliquées et promues en permanence par la plate-forme.

  • Gestion du code source. Par exemple un espace de stockage sur lequel le contrôle des versions est appliqué pour le code, les fichiers de configuration et les définitions de règles. Dans un système CI/CD moderne, la gestion du code source est généralement Git.

  • Gestion de la configuration. Système utilisé pour le stockage et l'application de la configuration des applications pour différents environnements.

  • Observabilité de l'application. La journalisation, la surveillance, les alertes et le traçage au niveau de l'application que les équipes chargées du développement, de l'exploitation et de la sécurité utilisent pour résoudre des problèmes et vérifier le bon fonctionnement des applications.

Infrastructure de plate-forme

Pour créer une plate-forme de livraison de logiciels évolutive, vous avez besoin de clusters Kubernetes pour le développement, les environnements de préproduction, ainsi que plusieurs clusters de production. Les clusters peuvent servir à des fonctions différentes :

  • Développement. Dans ces clusters, les développeurs effectuent des déploiements ad hoc de leurs applications à des fins de test et d'expérimentation.

  • Environnement d'application.

    • Préproduction. Pour chaque environnement de préproduction de votre workflow, vous devez disposer d'un cluster Kubernetes pour héberger vos applications. Ces clusters doivent ressembler aux clusters de production afin que vous puissiez réduire ou éliminer les différences entre les environnements et, par conséquent, améliorer les taux de réussite du déploiement.

    • Production Ces clusters exécutent vos charges de travail de production. Vous devez utiliser plusieurs clusters répartis géographiquement. Cela améliore la fiabilité contre les défaillances d'infrastructure et simplifie les problèmes d'opérations du jour 2, tels que les mises à niveau et le scaling des clusters.

Le schéma suivant illustre l'architecture générale : Trois clusters couvrent deux régions Google Cloud.

Dans cette architecture, vous gérez les clusters pour chaque environnement via Config Sync. Une configuration de cluster cohérente est essentielle, car elle permet aux équipes chargées du développement, de l'exploitation et de la sécurité de savoir que les environnements de préproduction et de production fonctionnent de manière semblable. Vous pouvez utiliser Config Sync pour stocker et appliquer des configurations courantes dans votre parc de clusters. Une fois la configuration du cluster normalisée, contrôlable et évolutive, vous pouvez vous concentrer sur le workflow de livraison de logiciels, ainsi que sur l'intégration et le déploiement d'applications.

Vous gérez vos déploiements sur des clusters de développement, de préproduction et de production via les pipelines CI/CD de l'application. La gestion du contrôle du code source sert de point de coordination pour le code et la configuration de l'application. Les pipelines CI/CD et les images de conteneur d'une application sont isolés dans l'environnement de cette application. Vous initialisez les dépôts d'applications et de configuration à l'aide de dépôts de démarrage et d'outils automatisés. Par exemple, vous pouvez utiliser Cloud Build pour exécuter Terraform afin d'intégrer et d'initialiser automatiquement de nouvelles applications.

Vous déployez des applications dans leurs zones de destination sur chaque cluster, de sorte que les applications sont isolées au niveau du réseau et de l'identité. Pour initialiser les zones de destination d'une application dans plusieurs environnements à l'aide de Config Sync, vous devez employer Cloud Service Mesh ou Multi Cluster Ingress pour que les clusters de production apparaissent comme un cluster unique en créant un réseau maillé couvrant de nombreux clusters.

Workflow de livraison de logiciels

Le système CI/CD est un composant essentiel de la plate-forme de livraison de logiciels. Lorsque les créateurs de plate-forme commencent à définir le processus CI/CD, ils doivent s'assurer que chaque composant produit ou consomme des artefacts conformes à une interface standardisée. L'utilisation d'une interface standardisée simplifie le remplacement des composants lorsqu'une mise en œuvre plus adaptée est disponible sur le marché.

Lorsque vous créez une plate-forme pour des applications en conteneur, vous pouvez utiliser les trois interfaces normalisées entre les composants : les dépôts Git, les images Docker et les fichiers manifestes Kubernetes. Ces interfaces vous permettent de créer un pipeline CI/CD réutilisable et flexible avec un workflow de développement, de compilation et de publication, comme le montre le schéma suivant :

Les étapes du workflow incluent les étapes "commit", "generate", "output", "store" et "apply".

Ce workflow fonctionne comme suit :

  1. Les développeurs valident leur code d'application dans les dépôts de code.

  2. Le système CI teste le code, crée un artefact d'image Docker et stocke l'artefact dans un registre.

  3. Une fois que l'artefact est prêt pour le déploiement, une référence à cet artefact est ajoutée à la configuration de l'application.

  4. Cette configuration de l'application est affichée dans un format lisible par Kubernetes et stockée dans un dépôt de code. Les mises à jour de ce dépôt déclenchent un pipeline de déploiement qui déploie les artefacts dans un environnement de développement intégré.

  5. Une fois les tests dans l'environnement de développement intégré terminés, les opérateurs font la promotion du déploiement dans l'environnement de préproduction.

  6. Après s'être assuré que l'application fonctionne comme prévu dans l'environnement de préproduction, les opérateurs obtiennent les approbations dans le pipeline de déploiement et font la promotion de la version dans l'environnement de production.

  7. Lorsque les opérateurs modifient les configurations de base, ces modifications sont appliquées à l'ensemble de l'organisation. Lorsque les opérateurs approuvent les modifications apportées à leurs dépôts, les mises à jour de la configuration des applications (et les déploiements ultérieurs) peuvent être déclenchées automatiquement. Les modifications effectuées par les opérateurs peuvent également être récupérées lors du prochain déploiement réalisé par les développeurs.

  8. En parallèle, les ingénieurs chargés de la sécurité peuvent mettre en œuvre et modifier les règles qui définissent ce qui peut être déployé en effectuant des commits sur ces règles dans leur dépôt de règles.

À l'aide d'une méthodologie GitOps, vous pouvez exiger une approche déclarative pour toute modification des applications et des clusters. Avec cette approche, toutes les modifications sont soumises à une vérification et à un examen avant de pouvoir être appliquées. Dans ce modèle déclaratif, vous stockez vos fichiers de configuration dans un dépôt Git, ce qui vous permet de gérer un journal des modifications, d'effectuer un rollback des déploiements ayant échoué et de connaître l'impact potentiel des modifications proposées.

Dans l'architecture de référence, vous utilisez kustomize pour contrôler les configurations d'application dans votre organisation. L'outil kustomize permet aux opérateurs de créer des bases appelées configurations d'application que vos équipes de développement peuvent ajuster sans avoir à ajouter ni à modifier du code dans la base. En définissant des configurations de base, les équipes en charge de la plate-forme peuvent créer et effectuer des itérations sur les bonnes pratiques pour l'organisation. Les opérateurs et les développeurs peuvent effectuer des itérations sur leurs déploiements indépendamment ; les développeurs peuvent appliquer les bonnes pratiques définies par les opérateurs. Lorsque les opérateurs doivent mettre en œuvre une nouvelle bonne pratique pour l'organisation, ils effectuent la modification dans la base. Cette modification est automatiquement intégrée lors du prochain déploiement effectué par le développeur.

Dépôts de code

Les dépôts de code source se trouvent au cœur du système CI/CD. Les opérateurs, les développeurs et les ingénieurs en charge de la sécurité disposent de leurs propres dépôts pour propager les modifications sur la plate-forme. L'utilisation d'un dépôt Git comme base pour toutes les modifications du système offre plusieurs avantages :

  • Possibilité de réaliser des audits. Les commits contiennent des informations sur la date, l'objet et l'utilisateur qui a modifié le système.

  • Processus de rollback simplifié. La fonctionnalité d'annulation de Git vous permet de revenir à un état précédent du système.

  • Gestion des versions. Vous pouvez ajouter des tags aux commits Git pour indiquer une version de l'état du système.

  • Transactions. Vous devez explicitement résoudre les conflits d'état et les examiner avant de pouvoir intégrer les modifications dans l'état.

Le schéma suivant montre comment différentes équipes interagissent avec un dépôt centralisé pour toutes les modifications :

Les dépôts les incluent pour respecter les bonnes pratiques, ainsi que pour la configuration des applications et de la plate-forme.

Les sections suivantes expliquent comment les opérateurs, les développeurs et les ingénieurs en charge de la sécurité utilisent le dépôt Git dans un système CI/CD moderne.

Dépôts d'opérateurs

Les dépôts gérés par des opérateurs contiennent les bonnes pratiques CI/CD et la configuration des applications qui aideront vos équipes à intégrer des applications tout en adoptant les bonnes pratiques organisationnelles dès le début. Lorsque les opérateurs gèrent les dépôts, les développeurs peuvent utiliser toutes les mises à jour des bonnes pratiques organisationnelles avec une interruption minimale de leur workflow.

Les opérateurs peuvent encoder les bonnes pratiques de leur organisation dans deux dépôts. C'est dans le premier dépôt que les opérateurs gèrent les bonnes pratiques du pipeline CI/CD partagé. Dans ce dépôt, les opérateurs fournissent aux développeurs une bibliothèque de tâches prédéfinies qu'ils peuvent utiliser pour développer leurs pipelines. Les dépôts d'applications des développeurs héritent automatiquement de ces tâches et de leur logique. Il n'est pas nécessaire de les copier manuellement. Voici des exemples de tâches que vous pouvez standardiser dans l'ensemble de l'organisation :

  • Création et stockage d'artefacts

  • Méthodes de test pour divers langages

  • Procédure de déploiement

  • Vérifications des règles

  • Analyses de sécurité

Le deuxième dépôt géré par les opérateurs stocke les bonnes pratiques en matière de configuration d'une application. Dans le contexte de GKE, les bonnes pratiques consistent à disposer d'un moyen de gérer les fichiers manifestes déclaratifs dans le modèle de ressource Kubernetes. Ces fichiers manifestes décrivent l'état souhaité de l'application. Les opérateurs peuvent créer des configurations de base pour différents types d'applications, en offrant aux développeurs un chemin simplifié pour déployer leurs applications conformément aux bonnes pratiques organisationnelles.

Dépôts d'applications

Les dépôts d'applications stockent la logique métier de l'application et toute configuration spécialisée nécessaire pour que l'application fonctionne correctement.

À mesure que les opérateurs créent et maintiennent les bonnes pratiques de manière codifiée, les développeurs peuvent les appliquer. Pour ce faire, les développeurs font référence aux tâches CI/CD et aux bases d'applications créées par les opérateurs dans leurs propres dépôts. Une fois que les développeurs ont apporté leurs modifications, les opérateurs peuvent personnaliser davantage le déploiement de l'application en ajoutant des configurations spécifiques à l'environnement, telles que des URL de base de données ou des libellés et des annotations de ressources.

Voici quelques exemples d'artefacts que vous pouvez stocker dans les dépôts d'applications :

  • Code source de l'application

  • Un fichier Dockerfile qui décrit comment créer et exécuter l'application

  • Définition du pipeline CI/CD

  • Extensions ou modifications des bases de configuration d'application créées par des opérateurs

Dépôts d'Infrastructure as Code

Les dépôts Infrastructure as Code stockent le code afin de créer l'infrastructure requise pour exécuter les applications. L'infrastructure peut inclure des plates-formes de mise en réseau et d'orchestration de conteneurs, telles que GKE. En règle générale, les administrateurs d'infrastructure sont propriétaires de ces dépôts. Les opérateurs peuvent les mettre à jour pour mettre en œuvre les bonnes pratiques.

Voici quelques exemples d'artefacts que vous pouvez stocker dans les dépôts d'applications :

  • Code de langage déclaratif (Terraform, Pulumi) représentant les objets d'infrastructure.

  • Des scripts shell ou Python qui complètent les définitions d'API déclaratives.

  • Extensions ou modifications des modèles d'infrastructure de base créés par l'équipe chargée de l'infrastructure.

Dépôts de configuration et de règles

Assurer une plate-forme cohérente et sécurisée pour la sécurité est une priorité absolue pour les opérateurs et les ingénieurs en sécurité.

Configuration

La configuration centralisée vous permet de propager les modifications de configuration dans l'ensemble du système. Voici des éléments de configuration courants que vous pouvez gérer de manière centralisée :

  • Espaces de noms Kubernetes

  • Quotas

  • Contrôles d'accès basés sur les rôles

  • Règles de réseau

Vous devez appliquer ce type de configuration de façon cohérente dans tous vos clusters de sorte que les équipes dédiées aux applications n'utilisent pas l'infrastructure de manière abusive. L'utilisation d'un dépôt Git pour stocker la configuration peut améliorer des processus tels que l'audit et le déploiement de la configuration via des méthodes telles que GitOps. Des outils tels que Config Sync peuvent simplifier le processus d'application uniforme de configurations au sein de votre infrastructure.

Règle

Étant donné que les développeurs peuvent étendre les configurations de base créées par les opérateurs, vous avez besoin d'un moyen de limiter les ressources créées dans les clusters qui constituent la plate-forme. Dans certains cas, vous pouvez créer une règle permettant aux développeurs de créer des ressources uniquement si ces ressources répondent à des exigences spécifiques. Par exemple, vous pouvez créer des objets de service Kubernetes qui ne peuvent pas être configurés pour l'équilibrage de charge externe.

Dans l'architecture de référence associée, vous utilisez Policy Controller pour appliquer des règles.

Dépôts de démarrage

Les dépôts de démarrage facilitent l'adoption des bonnes pratiques de CI/CD, d'infrastructure et de développement sur la plate-forme. Les dépôts de démarrage peuvent réduire considérablement les coûts associés à l'adoption des bonnes pratiques. Les bonnes pratiques, en retour, aident à accroître la vitesse des fonctionnalités, la fiabilité et la productivité des équipes. L'architecture de référence associée contient plusieurs dépôts de démarrage pour l'intégration continue, la livraison continue, les configurations Kubernetes, Go, Java et les applications de démarrage et l'infrastructure Python

Intégration continue

Les organisations disposent généralement d'un ensemble standard de tâches qui sont attribuées aux applications lors de l'intégration continue. Par exemple, dans la mise en œuvre de référence, l'ensemble de base des phases d'intégration continue inclut la compilation du code et la création d'une image de conteneur. Comme ces étapes sont définies dans le dépôt de démarrage, elles sont appliquées de manière uniforme sur la plate-forme. Les équipes individuelles dédiées aux applications peuvent ajouter des étapes supplémentaires.

Livraison continue

Comme pour l'intégration continue, le processus de livraison continue comporte généralement un ensemble standard d'étapes pour le déploiement d'applications dans les environnements de développement, de préproduction et de production. Indépendamment des méthodologies de déploiement utilisées, le dépôt de démarrage permet aux équipes en charge de la plate-forme d'appliquer ces méthodologies de manière uniforme sur l'ensemble des applications et des environnements. Dans la mise en œuvre de référence, le processus de déploiement inclut des déploiements de développement, de préproduction, un déploiement de production sur plusieurs clusters et des approbations manuelles pour le déploiement de production à l'aide de Cloud Deploy.

Configuration de l'application

Pour garantir l'efficacité d'une plate-forme de livraison de logiciels, vous avez besoin d'une méthode uniforme et cohérente pour appliquer la configuration de l'application. En utilisant des outils tels que kustomize et les dépôts de démarrage pour les configurations Kubernetes, les plates-formes peuvent fournir une base cohérente pour la configuration de l'application. Par exemple, dans la mise en œuvre de référence, la configuration de base kustomize initialise les dépôts de l'environnement de l'application avec un ensemble de configurations de base connu. Les équipes individuelles dédiées aux applications peuvent ensuite adapter les configurations selon leurs besoins.

Applications de démarrage

Les applications de démarrage peuvent vous aider à réduire les frais associés à l'adoption des bonnes pratiques, par exemple, les bonnes pratiques liées à l'observabilité et aux conteneurs.

  • Observabilité. Pour gérer efficacement une application et garantir la fiabilité, les applications doivent tenir compte de la journalisation, des métriques et du traçage. Les applications de démarrage aident les équipes à créer des frameworks et des stratégies favorisant l'observabilité.

  • Bonnes pratiques en matière de conteneurs. Lorsque vous créez des applications conteneurisées, vous devez créer des images de conteneurs réduites et nettes. Les bonnes pratiques en matière de conteneurs incluent l'empaquetage d'une seule application dans une image, la suppression des outils inutiles de l'image et la tentative active de produire de petites images à partir d'images de base minimales.

L'architecture de référence fournit une application Go de base, une application Java de base et une application Python de base comme point de départ. Vous devez ajouter des applications de démarrage adaptées aux langages, aux piles technologiques et aux types d'applications développées par vos équipes.

Dépôts de démarrage d'infrastructure

Les dépôts de démarrage de l'infrastructure sont fournis avec le code prédéfini requis pour créer différents composants d'infrastructure. Ces dépôts utilisent des modèles et des modules standards, comme déterminé par l'équipe chargée de l'infrastructure.

Par exemple, dans la mise en œuvre de référence, le modèle de plate-forme contient le code de démarrage permettant de créer un projet Google Cloud, un cloud privé virtuel et un cluster GKE. Ce modèle est généralement utilisé par les équipes chargées de l'infrastructure pour gérer l'infrastructure utilisée par plusieurs équipes applications comme ressource partagée. De même, le infra-template contient le code d'infrastructure de démarrage de base qu'une application peut nécessiter, par exemple, une base de données Cloud Storage ou Spanner. Ce modèle est généralement utilisé par les équipes applications pour gérer l'infrastructure de leurs applications.

Dépôts de modèles partagés

Les dépôts de modèles partagés fournissent des modèles de tâches standards que tous les membres d'une organisation peuvent réutiliser. Par exemple, les modules Infrastructure as Code tels que les modules Terraform, qui peuvent être utilisés pour créer des ressources d'infrastructure telles que les réseaux et les ressources de calcul.

Zones de destination de l'application

Lorsque vous utilisez le processus CI/CD partagé, la configuration partagée de l'application, ainsi qu'une configuration et des règles cohérentes entre les clusters, vous pouvez associer ces capacités pour créer des zones de destination d'application.

Une zone de destination est une entité logique verrouillée qui permet aux développeurs de déployer leurs applications et d'y effectuer une itération. Les zones de destination d'application utilisent les garde-fous que vous mettez en place pour permettre aux développeurs d'opérer de manière autonome. Pour chaque application, vous créez un espace de noms Kubernetes dans chaque cluster de chaque environnement (par exemple, pour la production, le développement ou la préproduction). Cette cohérence permet aux opérateurs de déboguer et de maintenir les environnements au fil du temps.

Le schéma suivant illustre le concept des zones de destination :

Le cluster GKE comprend trois espaces de noms pour différents environnements et charges de travail.

Modèle d'exploitation

Lorsque vous exploitez une plate-forme de livraison de logiciels avec une approche CI/CD moderne, il est important de maintenir les environnements, l'infrastructure et les processus cohérents et à jour. Par conséquent, vous devez planifier et choisir soigneusement le modèle d'exploitation pour la plate-forme. Vous pouvez choisir parmi plusieurs modèles, tels que des clusters en tant que service, des plans ou une infrastructure mutualisée.

Il est important de maintenir une infrastructure cohérente, de limiter la prolifération et de permettre aux équipes de se concentrer sur la diffusion des applications ; nous vous recommandons ainsi de déployer une infrastructure mutualisée. Le déploiement d'applications sur une infrastructure mutualisée évite aux équipes dédiées aux applications de gérer l'infrastructure, et permet aux équipes chargées de l'exploitation et de la sécurité de se concentrer sur la cohérence de l'infrastructure.

Considérations sur l'infrastructure mutualisée

Lorsque vous créez une plate-forme de livraison de logiciels mutualisées, plusieurs éléments sont à votre disposition :

  • Isolation de la charge de travail. Le concept de zones de destination d'application est de fournir un framework permettant d'isoler les charges de travail. Les zones de destination sont une combinaison d'espaces de noms, de règles de réseau et de RBAC. Toutes ces règles doivent être gérées et appliquées de manière centralisée via Config Sync.

  • Surveillance de l'utilisation par locataire. Pour connaître la répartition des coûts sur les espaces de noms et les libellés individuels d'un cluster, vous pouvez utiliser la mesure de l'utilisation de GKE. La mesure de l'utilisation de GKE permet de suivre les informations relatives aux demandes de ressources et à leur utilisation par les charges de travail de votre cluster. Vous pouvez filtrer davantage ces données par espaces de noms et libellés. Lorsque vous activez la mesure de l'utilisation de GKE sur le cluster mutualisé, les enregistrements d'utilisation des ressources sont écrits dans une table BigQuery. Vous pouvez exporter des métriques spécifiques aux locataires vers des ensembles de données BigQuery dans le projet locataire correspondant que les auditeurs peuvent ensuite analyser pour déterminer les répartitions des coûts.

  • Quotas de ressources. Pour vous assurer que tous les locataires partageant un cluster ont un accès équitable aux ressources du cluster, appliquez des quotas au niveau des ressources. Créez un quota de ressources pour chaque espace de noms en fonction du nombre de pods déployés par chaque locataire, ainsi que de la quantité de mémoire et de processeurs requise par chaque pod.

  • Plusieurs clusters pour chaque environnement. Pour améliorer la fiabilité des applications et des plates-formes, vous devez utiliser plusieurs clusters pour chaque environnement de préproduction et de production. Si plusieurs clusters sont disponibles, vous pouvez déployer des applications individuellement sur des clusters pour obtenir des niveaux supplémentaires de validation Canary. En outre, la présence de plusieurs clusters simplifie les problèmes liés au cycle de vie de la gestion et des mises à niveau des clusters.

  • Journalisation et surveillance spécifiques au locataire. Pour examiner les opérations au niveau de leurs applications, les locataires doivent pouvoir accéder aux journaux et aux métriques. Dans un environnement mutualisé, la journalisation et la surveillance doivent être spécifiques à l'application. Pour les métriques et la surveillance, vous pouvez utiliser Google Cloud Managed Service pour Prometheus et Grafana pour chaque espace de noms. Pour les journaux, vous devez créer un récepteur afin d'exporter les entrées de journal vers les ensembles de données BigQuery, puis les filtrer par espace de noms du locataire. Les locataires peuvent ensuite accéder aux données exportées dans BigQuery.

Pour plus d'informations sur une infrastructure mutualisée, consultez la section Bonnes pratiques pour l'infrastructure mutualisée d'entreprise.

Limites de l'isolation

Une plate-forme de livraison de logiciels est conçue et utilisée par plusieurs équipes. Il est donc important de disposer de limites d'isolation appropriées entre différents composants de la plate-forme. Les limites d'isolation permettent de créer une plate-forme robuste en fournissant les caractéristiques suivantes :

  • Déclarer des responsabilités Chaque équipe gère les ressources dans ses limites d'isolation sans se soucier du reste. Par exemple, l'équipe chargée de l'infrastructure n'est responsable que de la maintenance des clusters GKE. Les opérateurs ou les développeurs sont uniquement chargés de gérer les pipelines CI/CD et le code d'application.

  • Contrôle d'accès précis Si les ressources sont séparées par des limites d'isolation, utilisez un contrôle d'accès précis pour limiter l'accès.

  • Réduction des zones affectées Vous pouvez modifier indépendamment un composant sans affecter les autres composants.

  • Réduction des erreurs manuelles Comme le contrôle d'accès est précis, vous pouvez éviter les erreurs manuelles, telles que les déploiements accidentels sur un cluster de production à partir d'un environnement de développement.

Ces limites d'isolation peuvent exister entre différentes applications, infrastructures et applications, ou même entre les différents environnements d'une application.

Gouvernance

L'objectif principal des plates-formes de livraison de logiciels et des systèmes CI/CD modernes est d'améliorer l'efficacité du processus global de livraison de logiciels. En ce qui concerne la gestion de la plate-forme, vous devez prendre en considération deux éléments principaux : l'intégration d'applications, qui relève généralement de la catégorie de gouvernance, ainsi que le développement et la maintenance continus de la plate-forme (c'est-à-dire, gérer la plate-forme comme un produit).

Intégration et gestion des applications

L'adoption d'outils et de méthodologies CI/CD modernes a pour objectif de simplifier le processus de lancement et l'intégration de nouveaux services. L'intégration de nouvelles applications doit être un processus simple que vous pouvez effectuer avec une intervention minimale des équipes chargées des opérations et de la sécurité. Cela ne signifie pas que les équipes chargées des opérations et de la sécurité ne sont pas impliquées, mais que leur intervention initiale du point de vue du déploiement et de la sécurité est automatiquement gérée via le processus de provisionnement. Une fois qu'elles sont intégrées, les équipes chargées des opérations et de la sécurité sont naturellement incluses dans le processus de lancement à l'aide de demandes de fusion, de mises à jour des règles et de l'application des bonnes pratiques.

Il est recommandé de créer une automatisation pour intégrer une nouvelle application. Cela peut inclure la création de dépôts de code, de pipelines CI/CD, de zones de destination et de toute infrastructure requise pour l'application. L'automatisation dissocie les dépendances complexes des équipes de développement des autres équipes de l'organisation et permet aux développeurs de disposer d'une autonomie en libre-service d'une application. Cela permet aux développeurs de commencer très rapidement l'itération du code de l'application. Cela permet de ne pas perdre de temps à effectuer d'autres tâches que l'écriture du code. L'automatisation devrait permettre aux développeurs d'exécuter l'application dans un environnement de développement. Pour étendre l'application à des environnements supérieurs, d'autres équipes doivent être impliquées et le processus d'examen doit être suivi.

Dans l'architecture de référence associée, cette automatisation est appelée "Application Factory".

Plate-forme en tant que produit

Le workflow CI/CD est un produit logiciel, à l'exception des utilisateurs du produit qui sont des équipes chargées du développement, des opérations et de la sécurité. Dans cette optique, la plate-forme nécessite les mêmes rôles et processus de développement logiciel, tels que les responsables produit, l'équipe marketing (marketing direct), les boucles de rétroaction des utilisateurs et les cycles de développement des fonctionnalités.

Déployer la CI/CD avec GKE

Lorsque vous commencez à déployer un processus CI/CD moderne avec GKE dans l'organisation, il est essentiel de choisir les meilleures applications pilotes. Les équipes chargées du développement, des opérations et de la sécurité doivent également tenir compte d'autres facteurs au fur et à mesure qu'ils progressent, ce qui est traité dans cette section.

Sélectionner une application pilote

Choisir quelles applications à migrer en premier vers la plate-forme peut s'avérer difficile. Des applications pilotes pertinentes incluent des services qui traitent les données ou les requêtes, mais ne stockent pas de données, par exemple des couches de mise en cache, des interfaces Web ou des applications de traitement basées sur des événements. En règle générale, ces applications sont plus résilientes aux petits volumes de temps d'arrêt et d'erreurs de déploiement pouvant survenir chaque fois que vous utilisez de nouvelles techniques de déploiement et de gestion de la configuration. À mesure que les équipes acquièrent davantage d'expérience avec les processus CI/CD, et commencent à bénéficier des avantages en termes de fiabilité et de rapidité, vous pouvez commencer à migrer les principaux services vers la plate-forme de livraison de logiciels.

Considérations pour les développeurs

Lorsque vous utilisez un processus de développement CI/CD moderne, des fonctionnalités, des modifications et des déploiements peuvent se produire de manière plus fréquente et plus asynchrone. Les équipes chargées du développement doivent comprendre la façon dont les modifications affectent les systèmes en aval ou dépendants et comment ces modifications sont testées. Les processus de communication entre les équipes chargées du développement, des opérations et de la sécurité doivent être fluides. Il est judicieux d'investir dans de meilleures pratiques de gestion des versions pour les applications et pour les contrats de données via lesquels les différents services communiquent. En plus d'améliorer les méthodes de communication et la gestion des versions, la mise en œuvre de fonctionnalités en plusieurs étapes, et via des branches et des indicateurs de fonctionnalités peut améliorer les tests et le lancement des fonctionnalités.

Considérations pour les opérateurs

Avec une plate-forme de livraison de logiciels, les équipes chargées des opérations doivent fonctionner de la même manière que les équipes de développement. Au lieu de créer des fonctionnalités et des outils externes, ces équipes créent des outils et des processus internes qui facilitent le développement, le déploiement et l'exploitation d'applications externes. Les outils de plate-forme sont utilisés par leur propre équipe, ainsi que par les équipes chargées du développement et de la sécurité. Les opérateurs doivent créer des outils permettant de déployer de nouvelles versions d'applications et de les restaurer en cas d'erreur de l'application ou de défaillance du déploiement. Les opérateurs doivent également mettre l'accent sur la création de systèmes de surveillance et d'alerte pour détecter de manière proactive les échecs et déclencher des alertes en conséquence.

Considérations pour l'équipe de sécurité

Les équipes chargées de la sécurité doivent s'efforcer de rendre la sécurité une responsabilité partagée entre elles-mêmes, et les équipes chargées des opérations et du développement. Ce modèle est couramment appelé "Shifting Left" (déplacement à gauche) au niveau de la sécurité : la sécurité des informations (InfoSec) est intégrée dès le début du cycle de développement, les développeurs utilisent des outils pré-approuvés, et les tests de sécurité sont automatisés. Outre ces techniques, vous pouvez définir et appliquer des règles de sécurité de façon automatisée avec le contrôleur de règles. En utilisant plusieurs techniques et outils, vous pouvez appliquer la sécurité de manière plus proactive.

Étape suivante