| name | ci-cd-docker-kubernetes |
| description | Optimiser les workflows DevOps avec Docker (multi-stage builds, compose), Kubernetes (pods, services, deployments) et concevoir des pipelines CI/CD. |
| version | 1.0.0 |
| author | EVA |
| license | Privée EVA St-Étienne |
| platforms | ["linux","macos","windows"] |
| metadata | {"EVA":{"tags":["docker","docker-compose","kubernetes","k8s","ci-cd","github-actions","devops","deployment"],"related_skills":["os-linux-admin","os-virtualization-hypervisors"]}} |
DevOps : Conteneurisation (Docker) et Orchestration (Kubernetes / CI-CD)
Vue d'ensemble
Le DevOps unifie le développement logiciel (Dev) et l'administration des infrastructures (Ops). Cette compétence fournit les règles et modèles de référence pour concevoir des Dockerfiles sécurisés et légers, orchestrer des environnements locaux via Docker Compose, déployer des applications résilientes sur Kubernetes (k8s) et automatiser l'intégration et le déploiement continus (CI/CD) via GitHub Actions.
Quand l'utiliser
À utiliser lorsque l'utilisateur demande de :
- Conteneuriser une application en écrivant un
Dockerfile.
- Configurer un environnement multi-conteneurs local (
docker-compose.yml) avec bases de données et services.
- Créer ou corriger des manifestes Kubernetes (Deployments, Services, ConfigMaps).
- Configurer un pipeline CI/CD pour builder, tester et déployer du code automatiquement.
Ne pas utiliser pour :
- L'administration système OS pure (utilisez plutôt
os-linux-admin ou os-windows-admin).
- L'automatisation industrielle SCADA sans conteneurs.
1. Optimisation de Dockerfiles (Multi-stage Build)
L'utilisation du multi-stage build permet de diviser la taille de l'image finale par 10 et d'exclure les outils de compilation du runtime, limitant la surface d'attaque.
# --- ÉTAPE 1 : Compilation et Dépendances ---
FROM python:3.11-slim AS builder
WORKDIR /app
RUN apt-get update && apt-get install -y --no-install-recommends \
build-essential \
&& rm -rf /var/lib/apt/lists/*
COPY requirements.txt .
RUN pip install --no-cache-dir --user -r requirements.txt
# --- ÉTAPE 2 : Image Finale de Production (Légère) ---
FROM python:3.11-slim AS runner
WORKDIR /app
# Récupération des dépendances compilées
COPY --from=builder /root/.local /root/.local
COPY . .
ENV PATH=/root/.local/bin:$PATH
# Sécurité : Exécuter l'application sous un utilisateur non-root
RUN useradd -u 10001 appuser && chown -R appuser:appuser /app
USER appuser
EXPOSE 8000
CMD ["python", "main.py"]
2. Déploiement Local avec Docker Compose
Docker Compose simplifie la gestion de plusieurs conteneurs interconnectés. Voici une configuration robuste pour une application et sa base de données PostgreSQL :
version: '3.8'
services:
web:
build:
context: .
target: runner
ports:
- "8000:8000"
environment:
- DATABASE_URL=postgresql://app_user:secure_password@db:5432/app_db
depends_on:
db:
condition: service_healthy
restart: unless-stopped
db:
image: postgres:15-alpine
environment:
- POSTGRES_USER=app_user
- POSTGRES_PASSWORD=secure_password
- POSTGRES_DB=app_db
volumes:
- postgres_data:/var/lib/postgresql/data
healthcheck:
test: ["CMD-SHELL", "pg_isready -U app_user -d app_db"]
interval: 5s
timeout: 5s
retries: 5
restart: unless-stopped
volumes:
postgres_data:
3. Déploiement Kubernetes de Référence
Le manifeste suivant montre comment déployer une application sur un cluster Kubernetes de manière résiliente avec des sondes de disponibilité (Probes) et des limites de ressources :
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app-deployment
labels:
app: my-app
spec:
replicas: 3
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: web
image: registry.EVA.com/my-app:1.0.0
ports:
- containerPort: 8000
resources:
limits:
cpu: "500m"
memory: "512Mi"
requests:
cpu: "250m"
memory: "256Mi"
livenessProbe:
httpGet:
path: /healthz
port: 8000
initialDelaySeconds: 15
periodSeconds: 20
4. Pipeline CI/CD GitHub Actions
Ce fichier .github/workflows/ci.yml automatise la validation du code à chaque commit :
name: CI Pipeline
on:
push:
branches: [ main, develop ]
pull_request:
branches: [ main ]
jobs:
build-and-test:
runs-on: ubuntu-latest
steps:
- name: Checkout Code
uses: actions/checkout@v4
- name: Set up Python
uses: actions/setup-python@v5
with:
python-version: '3.11'
cache: 'pip'
- name: Install Dependencies
run: |
python -m pip install --upgrade pip
pip install -r requirements-dev.txt
- name: Run Linter (Ruff)
run: ruff check .
- name: Run Tests (pytest)
run: pytest
Pièges Courants (Common Pitfalls) (Pièges Courants)
-
Exécution des conteneurs en tant que root :
- Erreur : Ne pas définir d'instruction
USER dans le Dockerfile. En cas d'intrusion dans le conteneur, l'attaquant obtient des privilèges root sur la machine hôte.
- Correction : Toujours créer un utilisateur système non privilégié et basculer sur lui (
USER 10001).
-
Absence de limites de ressources dans Kubernetes :
- Erreur : Déployer des pods sans définir
resources.limits. Un pod ayant une fuite de mémoire peut consommer toute la RAM du nœud physique et crash les autres pods co-localisés.
- Correction : Toujours définir des limites et des requêtes CPU/Mémoire réalistes.
-
Utilisation du tag latest en production :
- Erreur : Déployer avec
image: my-app:latest. Les nouveaux builds écrasent le tag sans changer le manifeste de déploiement, rendant impossible le retour arrière (rollback) automatique ou le suivi de version.
- Correction : Utiliser des tags précis basés sur le hash de commit git ou la version sémantique (ex:
1.2.3).
Liste de vérification (Checklist)
