📍 Article principal du cluster : AWS DevOps Engineer Professional DOP-C02 — guide complet 2026
Ce tutoriel fait partie du cluster certification AWS DOP-C02. Pour la vue d’ensemble, lisez d’abord le pilier.
Introduction
Le domaine 1 « SDLC Automation » pèse 22 % de l’examen DOP-C02 — la plus grosse part du syllabus. Ce tutoriel construit un pipeline CI/CD AWS complet end-to-end : CodeCommit pour le source, CodeBuild pour la compilation et les tests, CodeDeploy pour le déploiement blue/green sur ECS Fargate, et CodePipeline pour orchestrer le tout. À la fin, vous aurez un pipeline production-grade avec rollback automatique basé sur CloudWatch Alarms et notifications Slack via SNS.
Prérequis
- Compte AWS avec accès admin (ou équivalent IAM permissions)
- AWS CLI v2 configuré et région par défaut définie
- Une application Node.js minimaliste avec Dockerfile prête
- 50 minutes
Étape 1 — Préparer le repository CodeCommit
CodeCommit est le service git managé d’AWS. On commence par créer un repo et y pusher un projet Node.js minimal avec Dockerfile et buildspec.yml.
aws codecommit create-repository --repository-name dop-c02-app --repository-description "DOP-C02 prep app"
REPO_URL=$(aws codecommit get-repository --repository-name dop-c02-app --query 'repositoryMetadata.cloneUrlHttp' --output text)
mkdir -p /tmp/dop-app && cd /tmp/dop-app
cat > package.json <<'EOF'
{"name":"dop-app","version":"1.0.0","main":"index.js","scripts":{"start":"node index.js","test":"echo OK"}}
EOF
cat > index.js <<'EOF'
const http = require('http');
http.createServer((req, res) => { res.end('DOP-C02 v1\n'); }).listen(8080);
EOF
cat > Dockerfile <<'EOF'
FROM node:22-alpine
WORKDIR /app
COPY package.json index.js ./
EXPOSE 8080
CMD ["npm","start"]
EOF
git init && git add . && git commit -m "init"
git remote add origin $REPO_URL
git push -u origin main
Le push initialise le repo CodeCommit avec votre code. À chaque commit ultérieur, CodePipeline déclenchera le pipeline. C’est le pattern standard AWS native — alternative valide : GitHub avec CodePipeline source GitHub action V2.
Étape 2 — Créer le repository ECR pour l’image Docker
ECR (Elastic Container Registry) stocke les images Docker buildées. Chaque commit produit une nouvelle image taggée avec le SHA git.
aws ecr create-repository --repository-name dop-c02-app --image-scanning-configuration scanOnPush=true
ECR_URI=$(aws ecr describe-repositories --repository-names dop-c02-app --query 'repositories[0].repositoryUri' --output text)
echo "ECR URI: $ECR_URI"
Le `scanOnPush=true` active le scan automatique des CVE à chaque image poussée. C’est testé indirectement en domaine 6 (Security and Compliance) — toute supply chain DOP-C02 doit scanner les images.
Étape 3 — Définir le buildspec CodeBuild
CodeBuild exécute les phases définies dans `buildspec.yml`. Le pattern classique : login ECR, build Docker, tag avec SHA, push vers ECR, génération d’imagedefinitions.json pour CodeDeploy.
version: 0.2
phases:
pre_build:
commands:
- aws ecr get-login-password --region $AWS_DEFAULT_REGION | docker login --username AWS --password-stdin $ECR_URI
- COMMIT_HASH=$(echo $CODEBUILD_RESOLVED_SOURCE_VERSION | cut -c 1-7)
- IMAGE_TAG=${COMMIT_HASH}
build:
commands:
- docker build -t $ECR_URI:$IMAGE_TAG .
- docker tag $ECR_URI:$IMAGE_TAG $ECR_URI:latest
post_build:
commands:
- docker push $ECR_URI:$IMAGE_TAG
- docker push $ECR_URI:latest
- printf '[{"name":"web","imageUri":"%s"}]' $ECR_URI:$IMAGE_TAG > imagedefinitions.json
artifacts:
files: imagedefinitions.json
Commit ce fichier `buildspec.yml` à la racine du repo CodeCommit. CodeBuild le détectera automatiquement quand le pipeline le déclenchera. Le fichier `imagedefinitions.json` est ce que CodeDeploy lit pour mettre à jour la TaskDefinition ECS avec la nouvelle image.
Étape 4 — Créer le projet CodeBuild via CLI
Le projet CodeBuild référence le buildspec, le runtime Docker, et la role IAM. La role doit avoir permissions ECR (push) + CloudWatch Logs.
cat > /tmp/codebuild-role-trust.json <<'EOF'
{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"codebuild.amazonaws.com"},"Action":"sts:AssumeRole"}]}
EOF
aws iam create-role --role-name DopC02CodeBuildRole --assume-role-policy-document file:///tmp/codebuild-role-trust.json
aws iam attach-role-policy --role-name DopC02CodeBuildRole --policy-arn arn:aws:iam::aws:policy/AWSCodeBuildAdminAccess
aws iam attach-role-policy --role-name DopC02CodeBuildRole --policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryPowerUser
aws iam attach-role-policy --role-name DopC02CodeBuildRole --policy-arn arn:aws:iam::aws:policy/CloudWatchLogsFullAccess
ACCT=$(aws sts get-caller-identity --query Account --output text)
aws codebuild create-project \
--name dop-c02-build \
--source type=CODECOMMIT,location=https://git-codecommit.${AWS_DEFAULT_REGION}.amazonaws.com/v1/repos/dop-c02-app \
--artifacts type=NO_ARTIFACTS \
--environment type=LINUX_CONTAINER,image=aws/codebuild/standard:7.0,computeType=BUILD_GENERAL1_SMALL,privilegedMode=true,environmentVariables="[{name=ECR_URI,value=$ECR_URI}]" \
--service-role arn:aws:iam::$ACCT:role/DopC02CodeBuildRole
Le `privilegedMode=true` est essentiel pour pouvoir builder des images Docker dans CodeBuild — sans ça, le démon Docker n’est pas disponible. C’est un piège classique d’examen.
Étape 5 — Créer le cluster ECS Fargate cible
L’application sera déployée sur ECS Fargate pour profiter du serverless conteneur. Cluster, Service, TaskDefinition à créer.
aws ecs create-cluster --cluster-name dop-c02-cluster
cat > /tmp/taskdef.json <<EOF
{
"family": "dop-c02-task",
"networkMode": "awsvpc",
"requiresCompatibilities": ["FARGATE"],
"cpu": "256",
"memory": "512",
"executionRoleArn": "arn:aws:iam::$ACCT:role/ecsTaskExecutionRole",
"containerDefinitions": [{
"name": "web",
"image": "$ECR_URI:latest",
"essential": true,
"portMappings": [{"containerPort": 8080, "protocol": "tcp"}],
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-group": "/ecs/dop-c02-task",
"awslogs-region": "$AWS_DEFAULT_REGION",
"awslogs-stream-prefix": "web"
}
}
}]
}
EOF
aws ecs register-task-definition --cli-input-json file:///tmp/taskdef.json
aws logs create-log-group --log-group-name /ecs/dop-c02-task
Si la role `ecsTaskExecutionRole` n’existe pas, créez-la d’abord — c’est la role par défaut pour ECS qui permet à Fargate de pull les images ECR et écrire dans CloudWatch Logs.
Étape 6 — Pipeline CodePipeline avec stages Source/Build/Deploy
Maintenant on assemble : CodeCommit → CodeBuild → CodeDeploy/ECS. Le pipeline a 3 stages avec actions standard.
cat > /tmp/pipeline-role-trust.json <<'EOF'
{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"codepipeline.amazonaws.com"},"Action":"sts:AssumeRole"}]}
EOF
aws iam create-role --role-name DopC02PipelineRole --assume-role-policy-document file:///tmp/pipeline-role-trust.json
aws iam attach-role-policy --role-name DopC02PipelineRole --policy-arn arn:aws:iam::aws:policy/AWSCodePipeline_FullAccess
aws iam attach-role-policy --role-name DopC02PipelineRole --policy-arn arn:aws:iam::aws:policy/AmazonECS_FullAccess
aws iam attach-role-policy --role-name DopC02PipelineRole --policy-arn arn:aws:iam::aws:policy/AWSCodeBuildAdminAccess
aws s3 mb s3://dop-c02-pipeline-artifacts-$ACCT
Le bucket S3 stocke les artefacts inter-stages (le build output, les imagedefinitions.json). C’est obligatoire pour tout pipeline CodePipeline.
Étape 7 — Définir le pipeline JSON et le créer
La création du pipeline se fait via un JSON descriptif. Trois stages : Source, Build, Deploy.
cat > /tmp/pipeline.json <<EOF
{
"pipeline": {
"name": "dop-c02-pipeline",
"roleArn": "arn:aws:iam::$ACCT:role/DopC02PipelineRole",
"artifactStore": {
"type": "S3",
"location": "dop-c02-pipeline-artifacts-$ACCT"
},
"stages": [
{
"name": "Source",
"actions": [{
"name": "Source",
"actionTypeId": {"category":"Source","owner":"AWS","provider":"CodeCommit","version":"1"},
"configuration": {"RepositoryName":"dop-c02-app","BranchName":"main"},
"outputArtifacts": [{"name":"SourceArtifact"}]
}]
},
{
"name": "Build",
"actions": [{
"name": "Build",
"actionTypeId": {"category":"Build","owner":"AWS","provider":"CodeBuild","version":"1"},
"configuration": {"ProjectName":"dop-c02-build"},
"inputArtifacts": [{"name":"SourceArtifact"}],
"outputArtifacts": [{"name":"BuildArtifact"}]
}]
},
{
"name": "Deploy",
"actions": [{
"name": "Deploy",
"actionTypeId": {"category":"Deploy","owner":"AWS","provider":"ECS","version":"1"},
"configuration": {"ClusterName":"dop-c02-cluster","ServiceName":"dop-c02-service","FileName":"imagedefinitions.json"},
"inputArtifacts": [{"name":"BuildArtifact"}]
}]
}
],
"version": 1
}
}
EOF
aws codepipeline create-pipeline --cli-input-json file:///tmp/pipeline.json
aws codepipeline get-pipeline-state --name dop-c02-pipeline
Une fois créé, CodePipeline détecte le commit le plus récent du repo et lance immédiatement la première exécution. Surveillez via la console ou `get-pipeline-state` jusqu’à ce que les 3 stages passent en `Succeeded`.
Étape 8 — Stratégie de déploiement blue/green avec CodeDeploy
Le déploiement direct ECS de l’étape précédente est en mode rolling. Pour un blue/green, on bascule sur CodeDeploy qui gère deux TargetGroups derrière un Application Load Balancer.
version: 0.0
Resources:
- TargetService:
Type: AWS::ECS::Service
Properties:
TaskDefinition: arn:aws:ecs:REGION:ACCOUNT:task-definition/dop-c02-task:LATEST
LoadBalancerInfo:
ContainerName: web
ContainerPort: 8080
PlatformVersion: LATEST
Hooks:
- BeforeAllowTraffic: arn:aws:lambda:REGION:ACCOUNT:function:pre-traffic-test
- AfterAllowTraffic: arn:aws:lambda:REGION:ACCOUNT:function:post-traffic-test
Ce fichier `appspec.yml` définit le déploiement blue/green avec hooks Lambda pour tests pré/post bascule. Pendant 5-30 minutes (configurable), le trafic peut être progressivement basculé du target group bleu vers le vert. Si une CloudWatch Alarm se déclenche, rollback automatique.
Comprendre les 3 stratégies de déploiement testées par DOP-C02
Trois stratégies à connaître par cœur. Rolling update remplace progressivement les instances en place — temps de bascule progressif, économie de capacité, mais une période où les deux versions coexistent. Default sur ECS et Auto Scaling. Blue/green déploie une nouvelle version (verte) en parallèle de l’ancienne (bleue), bascule le trafic d’un coup ou progressivement, peut rollback en quelques secondes en re-pointant le LB. Demande 2x la capacité pendant la bascule. Canary est une variante de blue/green qui bascule progressivement (10 %, 50 %, 100 %) avec validation entre chaque étape — idéal pour valider une feature flag ou A/B test.
L’examen DOP-C02 teste votre capacité à choisir la bonne stratégie selon le contexte. Question type : « Une équipe doit déployer une nouvelle version d’une API critique sans downtime, avec rollback rapide en cas d’erreur ». Réponse : blue/green avec CodeDeploy et CloudWatch Alarms.
Erreurs fréquentes
| Erreur | Cause | Solution |
|---|---|---|
| CodeBuild échoue avec « Cannot connect to Docker daemon » | privilegedMode pas activé | Vérifier `privilegedMode: true` dans le projet CodeBuild |
| imagedefinitions.json non trouvé | Bug dans buildspec post_build | Vérifier que le fichier est listé dans `artifacts.files` |
| ECS Service ne se met pas à jour | Permission manquante sur la role pipeline | Ajouter AmazonECS_FullAccess à la role pipeline |
| Blue/green rollback ne fonctionne pas | CloudWatch Alarm mal configurée | Tester l’alarm manuellement avant le déploiement (set-alarm-state) |
| Pipeline lent (build > 10 min) | computeType trop petit | Passer à `BUILD_GENERAL1_MEDIUM` ou activer cache Docker layers |
Adaptation au contexte ouest-africain
Pour les startups dakaroises et abidjanaises qui veulent moderniser leur SDLC, le combo CodePipeline + ECS Fargate est extrêmement rentable : 0,04 USD/heure pour Fargate task minimal, gratuit pour CodePipeline (1 pipeline gratuit/mois en Free Tier puis 1 USD/pipeline actif/mois), CodeBuild facturé à la minute (0,005 USD/min). Une stack complète CI/CD pour 5 microservices coûte environ 30-60 USD/mois — très en-dessous du coût d’un Jenkins self-hosted équivalent en termes de maintenance.
Tutoriels frères
- Infrastructure as Code avec CloudFormation et AWS CDK (à venir)
- EventBridge et Lambda — automation réactive et runbooks (à venir)
Pour aller plus loin
- 🔝 Retour au pilier : AWS DOP-C02 — guide complet 2026
- Documentation CodePipeline : docs.aws.amazon.com/codepipeline
- Documentation CodeBuild : docs.aws.amazon.com/codebuild
- Documentation CodeDeploy ECS : docs.aws.amazon.com/codedeploy
FAQ
CodePipeline ou GitHub Actions pour AWS ?
Les deux sont valides. CodePipeline est natif AWS et tombera à l’examen DOP-C02. GitHub Actions est aussi testé via les actions AWS officielles. En production, choisir selon l’écosystème existant — CodePipeline si tout est AWS, GitHub Actions si le code est sur GitHub.
Pourquoi pas Jenkins ?
Jenkins est valide mais demande une instance dédiée à maintenir. Pour DOP-C02, AWS privilégie les services managés. À l’examen, attendez-vous à des questions favorisant CodePipeline + CodeBuild plutôt que Jenkins.
Mots-clés secondaires : codepipeline tutoriel, codebuild buildspec, codedeploy ecs blue green, dop-c02 sdlc, ci cd aws, ecr docker push