Amazon DOP-C02: Pipelines CI/CD et stratégies de déploiement — Guide d'étude

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

Fait partie du AWS DevOps Engineer Professional DOP-C02 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Amazon, ou passez des tests chronométrés sur ExamRoll.io.

Vue d’ensemble

Un système CI/CD robuste sur AWS relie la gestion de code source, le build, les tests, la gouvernance des artefacts, l’orchestration des déploiements et les stratégies de publication sécurisées à travers plusieurs comptes et régions. Les services gérés principaux — CodeCommit, CodeArtifact, CodeBuild, CodePipeline et CodeDeploy — éliminent la maintenance des serveurs, s’intègrent étroitement avec IAM et KMS, et fournissent un support de premier ordre pour les déploiements bleu/vert, canary, progressifs (rolling) et sur place (in-place) vers EC2/Auto Scaling, ECS et Lambda. Des pipelines efficaces reposent également sur des déclencheurs précis (webhooks, EventBridge, planifications), une gestion disciplinée des artefacts, la mise en cache des builds pour la vitesse, et une répartition du trafic affirmée (opinionated) avec des alarmes de santé pour une restauration automatique. Pour les entreprises, les patterns inter-comptes et inter-régions sont obligatoires, nécessitant la prise de rôle, des magasins d’artefacts régionaux et des politiques de chiffrement cohérentes.

Orchestration avec les outils de développement AWS

Utilisez CodeCommit comme un service Git privé et hautement disponible. Il s’intègre avec EventBridge pour les événements de dépôt et de pull request, prend en charge les modèles de règles d’approbation et utilise IAM pour une autorisation granulaire. Pour les Git tiers (GitHub/Bitbucket), configurez les actions de source de CodePipeline avec des webhooks pour des déclencheurs quasi temps réel.

CodeArtifact centralise la gestion de paquets pour plusieurs écosystèmes (npm, Maven, PyPI, NuGet). Il prend en charge les connexions en amont (upstream) vers des registres publics avec mise en cache, un chiffrement KMS par dépôt, et des jetons d’authentification à portée limitée qui expirent automatiquement. Intégrez-le dans CodeBuild en invoquant aws codeartifact login durant la phase pre_build pour configurer les gestionnaires de paquets sans intégrer de secrets à longue durée de vie.

CodeBuild fournit des builds conteneurisés et éphémères sans avoir à gérer de workers. Capacités clés :

• Isolation de l’environnement et support VPC pour les dépendances privées. Activez le mode privilégié pour les builds Docker et activez la mise en cache locale des couches Docker pour accélérer la création d’images.
• Variables d’environnement provenant de trois sources : texte clair, SSM Parameter Store et Secrets Manager (sécurisé par défaut, pas de secrets codés en dur). Vous pouvez également passer des variables depuis CodePipeline.
• Mise en cache pour réduire les temps de build :
  • Mise en cache locale : cache de la source, cache des couches Docker et répertoires personnalisés sur l’hôte de build.
  • Mise en cache S3 : ensembles de dépendances réutilisables partagés entre les builds.
• Gestion des artefacts : spécifiez primary et secondaryArtifacts pour publier plusieurs sorties (par ex., le bundle de l’application et le modèle CloudFormation). Chiffrez les artefacts avec des clés KMS et évitez les ACLs publiques.
• Rapports : envoyez les journaux vers CloudWatch Logs/S3. Utilisez les rapports pour les résultats de test et les badges CodeBuild pour les retours sur les PR.

CodePipeline est l’orchestrateur. Définissez des étapes (source, build, test, déploiement, approbation) avec des actions qui peuvent s’exécuter en parallèle ou en séquence. Meilleures pratiques :

• Déclencheurs :
  • Webhooks pour les sources GitHub/Bitbucket.
  • Règles EventBridge pour les changements de branche dans CodeCommit ; vérifiez l’existence de la règle lorsque les pipelines ne démarrent pas.
  • Pipelines planifiés via des règles de planification EventBridge qui appellent StartPipelineExecution.
• Magasins d’artefacts : un compartiment S3 par région utilisée par le pipeline ; utilisez une clé KMS gérée par le client. Pour les actions inter-régions, ajoutez des magasins d’artefacts régionaux.
• Approbations manuelles avec SNS ou EventBridge pour intégrer des chats/webhooks pour des notifications quasi temps réel.
• IAM granulaire : un rôle de service de pipeline avec le moindre privilège ; des rôles par action sont pris (assumed) pour les opérations inter-comptes.

CodeDeploy est le moteur de déploiement prenant en charge les cibles EC2/sur site, ECS et Lambda. Il gère les hooks de cycle de vie, la répartition du trafic, les vérifications de santé et la restauration automatique via des alarmes CloudWatch. Assurez-vous que les instances EC2 exécutent l’agent CodeDeploy, disposent d’un profil d’instance et d’une connectivité sortante vers les points de terminaison CodeDeploy (ou une sortie via NAT). Les événements ignorés et les déploiements sans effet (no-op) indiquent souvent des problèmes d’agent, de permission ou de connectivité.

Stratégies de déploiement et cycle de vie de CodeDeploy

Choisissez la stratégie en fonction du risque, de la capacité et de la plateforme :

• In-place (sur place) (EC2/sur site) : Met à jour l’application sur les instances existantes. À combiner avec les configurations de déploiement OneAtATime, HalfAtATime ou AllAtOnce. Attachez un ELB pour drainer et réenregistrer les instances.
• Déploiement progressif (Rolling) (ECS) : Remplace les tâches par lots sur le même service. Déploiement progressif natif d’ECS ou géré via CodeDeploy en mode bleu/vert avec basculement contrôlé.
• Bleu/vert :
  • EC2/Auto Scaling : Provisionne un ASG vert, valide, puis bascule le trafic du bleu vers le vert. Termine ou conserve éventuellement l’environnement bleu.
  • ECS : Crée un jeu de tâches de remplacement derrière un second groupe cible ; valide, puis change les écouteurs (listeners).
  • Lambda : Bascule le trafic d’un alias vers une nouvelle version de fonction et surveille.
• Canary : Bascule d’abord un petit pourcentage (par ex., 10 %), observe pendant une période, puis termine.
• Linéaire (Linear) : Augmente le trafic par étapes égales (par ex., 10 % toutes les 5 minutes).

Le fichier appspec.yml de CodeDeploy définit ce qu’il faut installer et quand exécuter les scripts :

• Pour EC2/Sur site (YAML) :
  • files : où placer les fichiers.
  • permissions : mises à jour de la propriété/du mode des fichiers sans scripts personnalisés.
  • hooks (communs) : ApplicationStop, BeforeInstall, Install, AfterInstall, ApplicationStart, ValidateService.
  • Hooks de contrôle du trafic (lors de l’utilisation d’un load balancer) : BeforeBlockTraffic, AfterBlockTraffic, BeforeAllowTraffic, AfterAllowTraffic.
  • Utilisez des variables d’environnement prédéfinies (par ex., DEPLOYMENT_GROUP_NAME, DEPLOYMENT_ID, LIFECYCLE_EVENT) pour modifier le comportement de manière dynamique sans révisions distinctes, comme l’activation/désactivation des niveaux de log Apache par groupe de déploiement.
• Pour ECS :
  • resources : TargetService avec TaskDefinition et LoadBalancerInfo.
  • hooks : BeforeInstall, AfterInstall, AfterAllowTestTraffic, BeforeAllowTraffic, AfterAllowTraffic.
  • AfterAllowTestTraffic est idéal pour les tests de fumée (smoke tests)/d’intégration sur le jeu de tâches vert avec un écouteur de test.
• Pour Lambda :
  • resources définit la fonction, la version et l’alias à basculer.
  • hooks : BeforeAllowTraffic et AfterAllowTraffic.

Basculement de trafic et restauration (rollback) :

• Configurez les configurations de déploiement :
  • Lambda/ECS : Canary10Percent15Minutes, Canary10Percent5Minutes, Linear10PercentEvery1Minute, AllAtOnce, ou personnalisées.
  • EC2 Bleu/Vert : Redirection du trafic de type tout-en-un (all-at-once), canary ou linéaire via les écouteurs/groupes cibles du load balancer.
• Ajoutez des alarmes CloudWatch au groupe de déploiement pour une restauration automatique en cas d’erreurs, de codes 5xx ou de métriques personnalisées. Pour ECS, les alarmes peuvent surveiller les codes 5xx du groupe cible ou les métriques du service ; pour Lambda, surveillez les métriques Errors/Throttles de la fonction avec les dimensions d’alias/version.
• Utilisez les hooks de cycle de vie (par ex., AfterAllowTestTraffic) pour exécuter la validation via Lambda ou SSM ; une sortie non nulle provoque une restauration (rollback).

Bleu/Vert et basculement de trafic pour EC2, ECS et Lambda

EC2/Auto Scaling :

• Le déploiement bleu/vert avec CodeDeploy provisionne un nouvel Auto Scaling group pour l’environnement vert, l’associe à un groupe cible distinct, puis bascule les écouteurs de l’ALB. Vous pouvez choisir de terminer automatiquement l’environnement bleu ou de le conserver pour une restauration rapide.
• Pour les déploiements in-place sur EC2, combinez avec un ELB pour désenregistrer/réenregistrer gracieusement les instances et protéger la disponibilité. La configuration de déploiement dicte la taille des lots et le rythme.

ECS :

• CodeDeploy s’intègre aux services ECS en utilisant deux groupes cibles derrière un ALB. Un jeu de tâches de remplacement (vert) est créé avec la nouvelle définition de tâche.
• Le trafic de test est dirigé vers le groupe cible vert via un écouteur de test dédié ; le trafic de production reste sur le bleu jusqu’à la promotion.
• Les basculements de type canary ou linéaire déplacent progressivement le trafic vers l’environnement vert tout en surveillant les alarmes CloudWatch. Utilisez AfterAllowTestTraffic pour exécuter la validation (par exemple, une fonction Lambda appelant des vérifications synthétiques) avant le basculement en production.

Lambda :

• CodeDeploy met à jour un alias de fonction vers une nouvelle version avec un routage pondéré. Les modèles canary et linéaire déplacent progressivement le pourcentage de trafic. Les alarmes CloudWatch sur l’alias déclenchent la restauration automatique.
• Avec AWS SAM ou CDK, définissez AutoPublishAlias et DeploymentPreference dans les modèles pour encoder la politique canary/linéaire et les alarmes par fonction.

Routage pondéré au-delà de CodeDeploy :

• Pour l’équilibrage multi-régions ou multi-stacks, les enregistrements pondérés de Route 53 avec des bilans de santé (health checks) permettent une répartition régionale du trafic (par exemple, 1 % vers une région secondaire) et un basculement (failover). Cela complète mais ne remplace pas le basculement de trafic par service de CodeDeploy.

Livraison multi-comptes et multi-régions

Les pipelines d’entreprise résident généralement dans un « compte d’outillage » centralisé, déployant sur des comptes dev/test/prod dans plusieurs régions :

• Inter-comptes :
  • Dans les actions CodePipeline, spécifiez un RoleArn dans le compte cible qui approuve le principal du rôle du pipeline. Utilisez des autorisations de moindre privilège par action (CloudFormation, CodeDeploy, ECS, Lambda).
  • Pour CodeBuild qui doit accéder aux ressources du compte cible, faites en sorte que la compilation assume un rôle (STS) ou utilisez un rôle d’action par compte, et non un large AdministratorAccess.
  • Pour CodeDeploy sur EC2, le compte cible gère l’application/le groupe de déploiement et le rôle de service ; le pipeline assume un rôle pour appeler CreateDeployment.
• Inter-régions :
  • Ajoutez un magasin d’artefacts par région dans la configuration du pipeline (un bucket S3 avec une clé KMS régionale). Mettez à jour les politiques de bucket pour autoriser le rôle du pipeline et les rôles par action à lire/écrire.
  • Créez des artefacts spécifiques à la région lorsque cela est nécessaire (par exemple, en empaquetant le code Lambda avec aws cloudformation package ciblant un bucket S3 local à la région).
  • Les actions de déploiement CloudFormation dans une région distante doivent référencer le magasin d’artefacts de la région et peuvent spécifier un rôle d’exécution de pile dans le compte cible pour le moindre privilège.

Sécurité, artefacts et gouvernance :

• Gardez les buckets d’artefacts privés ; évitez les ACL publiques telles que authenticated-read. Appuyez-vous sur des politiques de bucket limitées aux rôles de pipeline et d’action, avec le chiffrement KMS.
• Standardisez les buildspecs pour pousser les artefacts de manière prévisible (par ex., bundle d’application pour EC2/CodeDeploy, taskdef.json et appspec pour ECS, modèles empaquetés pour Lambda).
• Favorisez l’immuabilité avec le pré-baking d’AMI pour EC2 afin que l’agent CodeDeploy et l’environnement d’exécution de base soient cohérents ; cela réduit la dérive et le temps de déploiement.
• Utilisez les règles EventBridge pour répliquer les événements de pipeline dans les notifications, les opérations de chat (ChatOps) ou la billetterie, et pour orchestrer les portes manuelles.

Scénario de problème pratique

Spotify a besoin de versions plus sûres pour des centaines de microservices avec un substrat de calcul mixte (ECS sur Fargate, services basés sur EC2 et Lambda). Ils exigent des déploiements canary et blue/green avec des tests automatisés avant le trafic de production, une gouvernance des artefacts et une promotion multi-régions tout en gardant la production dans un compte séparé.

1. Établir les dépôts et les paquets

• Utilisez CodeCommit pour les dépôts privés et l’automatisation des PR/tests pilotée par EventBridge. CodeArtifact héberge les dépendances npm, Maven et PyPI avec des upstreams et un chiffrement KMS pour standardiser les contrôles de la chaîne d’approvisionnement. Pourquoi : Intégration centrale IAM/KMS et aucun webhook externe nécessaire pour les dépôts critiques ; CodeArtifact fournit des paquets mis en cache et sélectionnés.

2. Compiler et tester

• Créez des projets CodeBuild par service avec intégration VPC, mise en cache locale (couche Docker et source) et des variables d’environnement provenant de Secrets Manager/Parameter Store. Créez des images et poussez-les vers ECR ; générez des artefacts secondaires (taskdef.json/appspec.yaml ou des modèles CloudFormation empaquetés). Pourquoi : Compilations éphémères et isolées, gestion robuste des secrets, cycles plus rapides grâce à la mise en cache, et sorties multiples prenant en charge à la fois l’empaquetage pour les conteneurs et le serverless.

3. Orchestrer les pipelines

• Créez un CodePipeline centralisé dans un compte d’outillage avec les étapes : Source, Build, Unit Tests, Deploy-to-Staging, Automated Tests, Manual Approval, Deploy-to-Prod. Les déclencheurs proviennent d’EventBridge sur les mises à jour de CodeCommit ; une règle EventBridge planifiée chaque nuit lance les tests d’intégration. Pourquoi : Flux de travail orienté (opinionated), auditable avec des portes et des exécutions pilotées à la fois par des événements et par une planification.

4. Déploiements blue/green et canary

• Les services ECS utilisent CodeDeploy blue/green avec deux groupes cibles et un basculement de trafic canary ; la validation s’exécute dans AfterAllowTestTraffic via une Lambda qui exécute des tests de contrat et des vérifications synthétiques. Les services EC2 utilisent CodeDeploy en place (in-place) avec OneAtATime ou des échanges d’ASG blue/green lorsque la capacité le permet. Les fonctions Lambda se déploient avec CodeDeploy en utilisant Canary10Percent15Minutes et des alarmes CloudWatch sur les Errors et les 5xx d’API Gateway. Pourquoi : Des contrôles de trafic de premier ordre par environnement d’exécution et une restauration automatique en cas de déclenchement d’alarme minimisent l’impact sur le client.

5. Promotion inter-comptes et inter-régions

• Le pipeline assume des rôles par environnement dans les comptes dev/test/prod. Pour us-east-1 et eu-west-1, configurez des magasins d’artefacts régionaux et des clés KMS régionales ; CodeBuild produit des modèles empaquetés spécifiques à la région et télécharge les artefacts dans des buckets locaux à la région. Les actions CloudFormation dans chaque compte/région utilisent des rôles d’exécution de pile ; les actions CodeDeploy ciblent des applications/groupes de déploiement spécifiques à l’environnement. Pourquoi : Isolation forte de la production, moindre privilège via l’assumption de rôle, et chiffrement conforme avec une faible charge opérationnelle.

6. Gouvernance et sécurité des artefacts

• Imposez des buckets d’artefacts S3 privés avec des politiques restrictives et supprimez toutes les ACL publiques. Signez les images de conteneur et les modèles ; stockez les SBOM en tant qu’artefacts de compilation. Utilisez les clés de condition IAM pour limiter les actions de production aux pipelines du compte d’outillage. Pourquoi : Empêche la fuite de données, améliore la provenance et s’aligne sur les meilleures pratiques de la chaîne d’approvisionnement.

7. Observabilité et notifications

• Attachez des alarmes CloudWatch à tous les groupes de déploiement ; les règles EventBridge transfèrent les événements d’exécution et d’approbation de CodePipeline à un sujet SNS et à une Lambda qui publie sur Slack. Pourquoi : Retour d’information plus rapide, restaurations automatiques et approbations humaines (human-in-the-loop) là où c’est nécessaire.

Cette conception unifie des environnements d’exécution hétérogènes sous une seule chaîne d’outils gérée, fournit des stratégies de déploiement sûres avec une vérification automatisée, réduit la maintenance en éliminant l’infrastructure CI/CD auto-hébergée, et s’adapte mondialement avec une séparation claire des tâches.

Tous les domaines · Infrastructure en tant que code et gestion de la configuration →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →

Parcourir Amazon →