Ce guide décrit un ensemble de bonnes pratiques pour l'intégration continue et la livraison continue (CI/CD) dans Google Kubernetes Engine (GKE). Ces pratiques couvrent un large éventail de sujets, du contrôle du code source aux stratégies de déploiement. Ces bonnes pratiques sont spécifiques à GKE et les bonnes pratiques CI/CD générales restent applicables. Pour en savoir plus, consultez les pages Technologies DevOps : l'intégration continue et Technologies DevOps : livraison continue.
Intégration continue
L'intégration continue (CI) est une pratique adoptée par les développeurs, qui consiste à intégrer toutes les modifications de code dans une branche principale aussi souvent que possible. Elle permet d'identifier plus rapidement les défaillances en exposant les problèmes le plus tôt possible dans le processus. Les pipelines CI sont généralement déclenchés par les développeurs qui soumettent leurs modifications de code. Le pipeline implique des étapes de validation de ces modifications, telles que l'analyse lint, les tests et la compilation. Un pipeline CI génère généralement un artefact que vous pouvez déployer à un stade ultérieur du processus de déploiement.
Créer des pipelines qui permettent une itération rapide
Le délai entre le moment où un développeur apporte une modification au code et celui où vous disposez d'une version opérationnelle de l'application doit être aussi court que possible. Cela est particulièrement important lors du développement sur les branches de fonctionnalités qui impliquent une itération rapide par les développeurs. Idéalement, vos pipelines CI devraient s'exécuter en moins de 10 minutes. Si cela n'est pas possible, créez deux types de pipelines CI :
Pipelines rapides : ces pipelines s'exécutent généralement en 10 minutes ou moins. Ces pipelines sont destinés aux branches de fonctionnalités et ne sont pas censés être complets. Les pipelines rapides peuvent potentiellement générer des artefacts instables.
Pipelines complets : l'exécution de ces pipelines peut prendre plus de 10 minutes, et implique des tests et des contrôles plus poussés. Les pipelines complets s'exécutent sur les demandes de fusion ou d'extraction, et les commits sont réalisés sur la branche principale.
Tester vos images de conteneurs
Dans le cadre de vos pipelines CI, assurez-vous d'exécuter tous les tests requis sur votre code et de créer des artefacts. Ces tests doivent inclure des tests unitaires, fonctionnels, d'intégration, de charge ou de performance.
Il est également important de tester la structure de vos images de conteneurs créées. Le test de la structure permet de garantir que toutes les commandes s'exécutent comme prévu dans votre conteneur. Les tests vous permettent également de vérifier que des fichiers spécifiques se trouvent au bon endroit et disposent du contenu correct.
Pour tester vos images de conteneurs, vous pouvez utiliser le framework de Test de structure de conteneur.
Mettre en œuvre la sécurité le plus tôt possible dans les pipelines
Veillez à mettre en place des contrôles de sécurité et à maintenir un équilibre le plus tôt possible dans le cycle de vie du développement. En identifiant les risques de sécurité avant de créer des artefacts ou d'effectuer le déploiement, vous pouvez réduire le temps passé et les frais dépensés pour remédier à ces risques.
Pour faciliter la détection précoce, vous pouvez mettre en œuvre les mesures de sécurité suivantes dans vos pipelines :
Demandez à des experts du domaine d'examiner le code intégré à votre dépôt de production.
Mettez en œuvre l'analyse lint et l'analyse de code statique le plus tôt possible dans votre pipeline. Ces analyses vous aident à identifier les problèmes (comme ne pas échapper les entrées ou accepter des données d'entrée brutes pour les requêtes SQL) ou les failles de votre code.
Procédez à une analyse des failles sur l'image de conteneur que vous avez créée.
Empêchez le déploiement des images contenant des failles sur vos clusters grâce à l'autorisation binaire. L'autorisation binaire nécessite un abonnement GKE Enterprise. Afin de renforcer votre confiance quant aux images produites, l'autorisation binaire vous permet également de demander des attestations auprès de différents systèmes ou entités. Par exemple, ces attestations peuvent inclure les éléments suivants :
- Analyse de failles réussie
- Tests de contrôle qualité réussis
- Validation du propriétaire du produit
Livraison continue
La livraison continue (CD) vous permet de publier du code à tout moment. Elle s'applique sur l'artefact produit par les pipelines CI. Les pipelines CD peuvent s'exécuter bien plus longtemps que les pipelines CI, en particulier si vous utilisez des stratégies de déploiement plus élaborées telles que les déploiements bleu-vert.
Utiliser la méthodologie GitOps
GitOps permet de stocker l'infrastructure déclarative dans des dépôts Git et propose des outils CI/CD permettant de déployer cette infrastructure dans votre environnement. Lorsque vous utilisez une méthodologie GitOps, vous vous assurez que toutes les modifications apportées à vos applications et clusters sont stockées dans des dépôts sources et restent accessibles.
Les méthodologies GitOps présentent les avantages suivants :
- Vous pouvez examiner les modifications avant leur déploiement via des demandes de fusion ou d'extraction.
- Vous disposez d'un emplacement unique que vous pouvez utiliser pour vous référer à l'état de vos applications et de vos clusters à tout moment.
- Les instantanés de vos clusters et de vos applications facilitent la récupération en cas de défaillances.
Pour en savoir plus sur la méthodologie GitOps et les différents modèles que vous pouvez utiliser dans vos dépôts sources, consultez la section Concepts GitOps.
Certains outils couramment utilisés pour l'infrastructure déclarative sont Terraform (développé par Hashicorp) et Config Connector (développé par Google Cloud). Pour vous entraîner à gérer l'infrastructure avec GitOps et d'autres outils, suivez le tutoriel Gérer une Infrastructure as Code avec Terraform, Cloud Build et GitOps. Pour apprendre à gérer des applications avec GitOps, essayez la livraison continue de type GitOps avec Cloud Build.
Privilégier la promotion à la recréation d'images de conteneurs
Les images de conteneurs ne doivent pas être recréées lorsqu'elles franchissent les différentes étapes d'un pipeline CI/CD. Le fait de les recréer peut introduire des différences mineures entre les branches de code. Ces différences peuvent entraîner l'échec de votre application en production ou l'ajout accidentel de code non testé dans l'image de conteneur en production. Pour vous assurer que l'image de conteneur que vous avez testée est bien celle que vous déployez, il est préférable de la créer une seule fois et de la promouvoir ensuite dans vos environnements. Ce conseil suppose que votre configuration spécifique à l'environnement est séparée des packages.
Envisager d'utiliser des modèles de déploiement et de test plus avancés
GKE vous offre la flexibilité nécessaire pour déployer et tester vos applications selon plusieurs modèles. Le modèle de déploiement que vous choisissez dépend principalement de vos objectifs commerciaux. Par exemple, vous devrez peut-être déployer des modifications sans temps d'arrêt, ou déployer des modifications dans un environnement ou auprès d'un sous-ensemble d'utilisateurs avant leur disponibilité générale.
Voici quelques-uns des différents modèles de déploiement disponibles :
Recréation de déploiement : vous réduisez complètement la version de l'application existante avant de la faire évoluer vers la nouvelle version.
Déploiement par mise à jour progressive : vous mettez à jour un sous-ensemble d'instances d'application en cours d'exécution au lieu de mettre à jour toutes les instances d'application en cours d'exécution simultanément. Vous mettez ensuite progressivement à jour davantage d'instances d'application en cours d'exécution jusqu'à ce qu'elles soient toutes mises à jour.
Déploiement bleu-vert : vous déployez un ensemble d'instances parallèle supplémentaire sur vos instances de production existantes avec une version mise à niveau de votre application. Le trafic passe sur les nouvelles instances lorsque vous êtes prêt à effectuer le déploiement.
Séparer les clusters de différents environnements
La séparation des environnements est un aspect important à prendre en compte pour toute cible de déploiement. Dans l'idéal, vous devez disposer de clusters distincts pour chacun des environnements suivants :
Environnement de développement : les développeurs déploient les applications à des fins de test et d'expérimentation dans cet environnement. Ces déploiements nécessitent une intégration avec d'autres parties de l'application ou du système (par exemple, une base de données). Les clusters de cet environnement ont généralement moins de portes, et les développeurs ont plus de contrôle sur leur configuration.
Environnements de préproduction ou de contrôle qualité : ces environnements doivent ressembler le plus possible à l'environnement de production. Ils permettent d'effectuer des tests à grande échelle des modifications, tels que des tests d'intégration, de charge, de performance ou de régression.
Environnement de production : vos charges de travail de production, ainsi que vos applications et services destinés aux utilisateurs s'exécutent dans cet environnement.
Pour en savoir plus sur ces environnements, consultez la section "Environnements" de la page "Kubernetes et les défis de la livraison continue de logiciels".
Maintenir des environnements de préproduction le plus près possible de la production
Idéalement, les clusters de préproduction sont identiques aux clusters de production. Cependant, pour des raisons de coûts, les clusters de préproduction peuvent être des instances dupliquées réduites. Conserver des clusters similaires permet de s'assurer que tous les tests sont effectués dans des conditions identiques ou similaires à celles de l'environnement de production. La similarité entre les clusters de préproduction et les clusters de production réduit également les risques de défaillances inattendues dues à des différences entre les environnements lors du déploiement en production.
L'infrastructure déclarative et GitOps vous permettent d'obtenir une similarité plus élevée entre vos environnements, car vous pouvez plus facilement dupliquer la configuration de votre cluster sous-jacent. Pour vous assurer que vos environnements présentent des conditions similaires pour les règles et les configurations, vous pouvez également utiliser des outils tels que Config Sync.
Se préparer à gérer les défaillances en production
Aucun test ne peut garantir le comportement approprié de votre application en production. Les défaillances peuvent êtres dues à des cas spéciaux (par exemple, des données n'ont pas été prises en compte ou des modèles d'accès par vos utilisateurs n'ont pas été testés). Il est important de surveiller votre application en production, et de mettre en place des mécanismes de rollback et de déploiement automatisés afin de corriger rapidement les bugs ou les pannes. L'utilisation de stratégies de déploiement plus robustes vous permet de réduire l'impact des problèmes et de toucher moins d'utilisateurs finaux lorsque des problèmes surviennent en production.
Checklist
Le tableau suivant récapitule les tâches que nous vous recommandons d'effectuer lorsque vous utilisez un pipeline CI/CD dans GKE :
| Domaine | Tasks |
|---|---|
| Intégration continue | |
| Livraison continue |
Étape suivante
- Découvrez les bonnes pratiques pour l'architecture mutualisée d'entreprise.
- Découvrez l'intégration et la livraison continues sur Google Cloud.