← Retour aux tutoriels

Bonnes pratiques DevOps : CI/CD, IaC et observabilité

devopsci-cdinfrastructure-as-codeterraformkubernetesdevsecopsobservabilitesre

Bonnes pratiques DevOps : CI/CD, IaC et observabilité

Ce tutoriel propose une vue complète et pratique des bonnes pratiques DevOps autour de trois piliers : CI/CD, Infrastructure as Code (IaC) et observabilité. L’objectif est de fournir des explications approfondies, des choix d’outillage réalistes et des commandes concrètes pour construire une chaîne de livraison fiable, reproductible et exploitable en production.


1) Principes DevOps : ce qu’on cherche à optimiser

Avant les outils, il faut clarifier les objectifs :

Ces objectifs se traduisent en pratiques :


2) CI/CD : construire une chaîne fiable

2.1 CI vs CD : définitions utiles

Bonnes pratiques clés :


2.2 Exemple d’application : API Node.js containerisée

Structure minimale

mkdir -p demo-devops && cd demo-devops
npm init -y
npm install express
cat > index.js <<'EOF'
const express = require("express");
const app = express();

app.get("/health", (req, res) => res.json({ status: "ok" }));
app.get("/", (req, res) => res.send("Hello DevOps"));

const port = process.env.PORT || 3000;
app.listen(port, () => console.log(`Listening on ${port}`));
EOF
node index.js
curl -s http://localhost:3000/health

Dockerfile (artefact immuable : image)

cat > Dockerfile <<'EOF'
FROM node:20-alpine

WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev

COPY index.js ./
ENV PORT=3000
EXPOSE 3000

USER node
CMD ["node", "index.js"]
EOF

docker build -t demo-devops:local .
docker run --rm -p 3000:3000 demo-devops:local
curl -s http://localhost:3000/health

Pourquoi c’est important :


2.3 Versioning et traçabilité

Adoptez des conventions :

Commandes utiles :

git init
git add .
git commit -m "init: API demo"
git tag v0.1.0
git describe --tags --always

Pour une image Docker :

GIT_SHA=$(git rev-parse --short HEAD)
docker build -t registry.example.com/demo-devops:${GIT_SHA} .

2.4 Qualité : tests, lint, SAST, dépendances

Même si l’exemple est minimal, une chaîne CI sérieuse inclut :

Exemples de commandes (Node) :

npm install --save-dev eslint
npx eslint --init
npx eslint .

npm audit --audit-level=high

Scan d’image Docker avec Trivy :

brew install trivy  # macOS
# ou sur Linux : voir doc officielle, ou via package manager

trivy image demo-devops:local

Bonnes pratiques :


2.5 Construire un pipeline CI/CD (exemple GitHub Actions)

Même si GitHub Actions utilise un fichier YAML, l’intérêt ici est de comprendre les étapes et de pouvoir les exécuter localement. Voici les commandes typiques que votre CI doit exécuter :

  1. Installer dépendances :
npm ci
  1. Lint + tests :
npx eslint .
npm test
  1. Build image :
docker build -t registry.example.com/demo-devops:${GIT_SHA} .
  1. Scan image :
trivy image --exit-code 1 --severity CRITICAL,HIGH registry.example.com/demo-devops:${GIT_SHA}
  1. Push registry :
docker login registry.example.com
docker push registry.example.com/demo-devops:${GIT_SHA}
  1. Déploiement (ex : Kubernetes) :
kubectl set image deployment/demo-devops api=registry.example.com/demo-devops:${GIT_SHA}
kubectl rollout status deployment/demo-devops

Points de contrôle à ajouter :


2.6 Stratégies de déploiement et rollback

Rolling update (par défaut Kubernetes)

Commandes :

kubectl rollout status deployment/demo-devops
kubectl rollout history deployment/demo-devops
kubectl rollout undo deployment/demo-devops

Blue/Green

Canary

Bonnes pratiques :


3) Infrastructure as Code (IaC) : reproductibilité et maîtrise du changement

3.1 Pourquoi l’IaC est non négociable

Sans IaC, l’infrastructure devient :

Avec IaC :

Deux grandes familles :

En pratique : Terraform pour provisionner, Ansible pour configurer (selon contexte), et Kubernetes manifests/Helm pour déployer les workloads.


3.2 Terraform : workflow sain

Installation et vérification

terraform version

Workflow standard

  1. Initialiser :
terraform init
  1. Formater :
terraform fmt -recursive
  1. Valider :
terraform validate
  1. Planifier :
terraform plan -out tfplan
  1. Appliquer :
terraform apply tfplan
  1. Détruire (en sandbox uniquement) :
terraform destroy

Bonnes pratiques :


3.3 Exemple IaC concret : AWS S3 + verrouillage d’état (concepts)

Même si vous adaptez au cloud, voici les commandes et concepts essentiels.

Créer un bucket S3 et une table DynamoDB (exemple AWS CLI) :

aws s3api create-bucket --bucket mon-tf-state-123456 --region eu-west-1 \
  --create-bucket-configuration LocationConstraint=eu-west-1

aws dynamodb create-table \
  --table-name terraform-locks \
  --attribute-definitions AttributeName=LockID,AttributeType=S \
  --key-schema AttributeName=LockID,KeyType=HASH \
  --billing-mode PAY_PER_REQUEST

Pourquoi :


3.4 Gestion des secrets : règles strictes

Exemple : lire un secret depuis Vault (illustratif) :

vault login
vault kv get -field=password secret/db

Exemple Kubernetes : créer un secret à partir d’un fichier (à éviter si le fichier traîne)

kubectl create secret generic db-credentials \
  --from-literal=username='app' \
  --from-literal=password='supersecret'

Bonnes pratiques :


3.5 GitOps : déployer via Git comme source de vérité

GitOps = l’état désiré est dans Git, et un contrôleur (Argo CD / Flux) applique et réconcilie.

Avantages :

Commandes utiles côté Kubernetes :

kubectl get ns
kubectl get deployments -A
kubectl diff -f k8s/
kubectl apply -f k8s/

Même si vous utilisez Argo CD, vous gardez ces commandes pour diagnostiquer.


4) Observabilité : logs, métriques, traces (et alertes utiles)

4.1 Observabilité vs monitoring

Les trois signaux :

  1. Métriques : séries temporelles (latence, CPU, taux d’erreur)
  2. Logs : événements textuels/structurés
  3. Traces : parcours d’une requête à travers services (latence par composant)

Objectif : réduire le temps de diagnostic et éviter les “war rooms” interminables.


4.2 Métriques : RED, USE, SLI/SLO

Méthodes

SLI/SLO (fiabilité pilotée)

Exemple : SLO 99.9% => budget d’erreur 0.1% sur 30 jours. Si vous le consommez trop vite, vous ralentissez les releases et investissez dans la fiabilité.


4.3 Logs : structurés, corrélables, exploitables

Bonnes pratiques :

Exemple (Docker) : consulter logs d’un conteneur

docker logs -f <container_id>

Sur Kubernetes :

kubectl logs -f deploy/demo-devops
kubectl logs -f deploy/demo-devops --previous

4.4 Traces : OpenTelemetry comme standard

OpenTelemetry (OTel) est devenu le standard de facto pour instrumenter et exporter traces/métriques/logs.

Concepts :

Même sans instrumenter tout de suite, commencez par :


4.5 Prometheus : métriques et alerting (commandes)

Prometheus scrappe des endpoints /metrics. Vous pouvez tester localement avec curl (si votre app expose des métriques) :

curl -s http://localhost:3000/metrics | head

Interroger Prometheus via son API HTTP (exemple) :

curl -G 'http://prometheus:9090/api/v1/query' --data-urlencode 'query=up'

Lister des cibles :

curl -s 'http://prometheus:9090/api/v1/targets' | head

Bonnes pratiques alerting :


4.6 Grafana : dashboards utiles (ce qu’il faut afficher)

Dashboards recommandés :

Le piège : dashboards trop complexes. Préférez 5–10 graphes essentiels + drill-down.


4.7 Alertes : philosophie et exemples concrets

Une alerte utile doit répondre :

Commandes de diagnostic typiques (Kubernetes) :

kubectl get pods -n prod
kubectl describe pod <pod> -n prod
kubectl top pods -n prod
kubectl get events -n prod --sort-by=.metadata.creationTimestamp | tail -n 30
kubectl exec -it deploy/demo-devops -n prod -- sh

Réseau / DNS :

kubectl exec -it deploy/demo-devops -n prod -- nslookup kubernetes.default
kubectl exec -it deploy/demo-devops -n prod -- wget -qO- http://service-backend:8080/health

5) Sécurité intégrée (DevSecOps) : contrôles continus

5.1 Chaîne de confiance : signature et provenance

Objectifs :

Outils :

Exemple : générer une SBOM avec Syft

brew install syft
syft demo-devops:local -o cyclonedx-json > sbom.json

Signer une image avec cosign (conceptuel, nécessite config) :

cosign sign registry.example.com/demo-devops:${GIT_SHA}
cosign verify registry.example.com/demo-devops:${GIT_SHA}

5.2 Politiques : “policy as code”

But : empêcher des déploiements non conformes (ex : conteneur root, pas de limites CPU, image latest).

Sur Kubernetes, vous pouvez utiliser :

Exemples de contrôles à imposer :


6) Standardiser : templates, conventions, “golden paths”

Une organisation DevOps performante propose des chemins standards :

6.1 Exemple de Makefile pour unifier les commandes

cat > Makefile <<'EOF'
APP=demo-devops
IMAGE=$(APP):local

.PHONY: install lint test build run scan

install:
	npm ci

lint:
	npx eslint .

test:
	npm test

build:
	docker build -t $(IMAGE) .

run:
	docker run --rm -p 3000:3000 $(IMAGE)

scan:
	trivy image $(IMAGE)
EOF

make install
make build
make scan

Pourquoi :


7) Exploitation : runbooks, postmortems, gestion d’incident

7.1 Runbooks

Un runbook doit contenir :

Exemple de commandes “first response” :

kubectl get deploy -n prod
kubectl get pods -n prod
kubectl logs -n prod deploy/demo-devops --tail=200
kubectl rollout status -n prod deploy/demo-devops

7.2 Postmortems sans blâme

Après incident :

Bonnes pratiques :


8) Architecture de référence (pragmatique)

Voici une architecture réaliste pour une équipe :

Le plus important : cohérence et adoption. Mieux vaut une stack simple, bien utilisée, qu’une stack “parfaite” ignorée.


9) Checklist finale : à appliquer dès maintenant

CI/CD

IaC

Observabilité


10) Aller plus loin (progression recommandée)

  1. Stabiliser la CI (tests, lint, build image, scan).
  2. Standardiser le packaging (Dockerfile, tags, registry).
  3. Automatiser le déploiement en staging, puis prod avec garde-fous.
  4. Passer l’infra en IaC (Terraform) + remote state.
  5. Mettre en place observabilité “minimum viable” (métriques + logs + alertes).
  6. Ajouter traces distribuées et SLO/error budgets.
  7. Renforcer la supply chain (SBOM, signature, policy as code).

En appliquant ces pratiques, vous construisez une chaîne DevOps qui ne se contente pas de “déployer”, mais qui garantit la qualité, réduit le risque, et améliore la capacité à diagnostiquer et à restaurer rapidement le service. L’efficacité vient de l’alignement entre automatisation (CI/CD), reproductibilité (IaC) et feedback (observabilité), le tout renforcé par la sécurité et des processus d’exploitation matures.