↑↓ ou Espace pour naviguer
theo@cloud-s2:~/CM2 — bash 1/14
theo @ cloud-s2 docker run --rm -it cours/cm2

Introduction à Docker

Pulling from cours/cm2 ... Done

Conteneurisation & DevOps · Cloud S2

14 sections

theo @ cloud-s2
Theo Rey · Site Reliability Engineer · contact@reyth.dev
theo@cloud-s2:~/CM2 — cat agenda.md 2/14

# programme du cours $ Au programme

01
Déploiement traditionnelMonolithes & serveurs dédiés
02
Machines VirtuellesHyperviseur, isolation complète
03
Le modèle ContainerDocker Engine, namespaces Linux
04
Avantages des containersPortabilité, isolation, rapidité
05
Images DockerRegistry, layers, tags
06
Dockerfile & ComposeCréer et orchestrer ses images
08
En productionComment faire ça à l'échelle
09
LLMs & DockerSavoir ce qu'on fait avec l'IA
10
Pour aller plus loinRessources & références
theo@cloud-s2:~/CM2 — git log --oneline "avant docker" 3/14

# déploiement classique $ Ce que vous avez l'habitude

Application monolithique déployée directement sur un serveur physique. Tout partage le même OS. Un crash peut tout impacter.

Problèmes
"Works on my machine" · Conflits de dépendances · Scaling difficile · Déploiements risqués
App Layer
App A
App B
App C
Runtime / Libs Python 3.9 · Node 16 · Java 11
Système d'exploitation Ubuntu 22.04
Matériel physique CPU · RAM · Disque
theo@cloud-s2:~/CM2 — man virtualbox 4/14

# ce que vous avez vu la semaine dernière $ Les Machines Virtuelles

App A
Libs
OS invité
App B
Libs
OS invité
Hyperviseur (VMware, VirtualBox, KVM)
OS hôte
Matériel physique
✓ Avantages
Isolation complète · Sécurité forte · OS différents possible
✗ Inconvénients
Lent à démarrer (minutes) · Lourd en ressources · OS complet dupliqué par VM
→ Chaque VM inclut un OS complet : des Go de RAM gaspillés
theo@cloud-s2:~/CM2 — docker ps 5/14

# la révolution de la conteneurisation $ Le modèle des Containers

Container
App A + Libs
Container
App B + Libs
Container
App C + Libs
Docker Engine (containerd + runc)
OS hôte (kernel Linux partagé)
Matériel physique
Clé de compréhension
Les containers partagent le kernel Linux de l'hôte — pas besoin d'OS complet. Seulement les libs nécessaires sont incluses.
Démarrage
millisecondes
🪶
Poids
quelques Mo
📦
Portabilité
any OS
🔒
Isolation
namespaces
theo@cloud-s2:~/CM2 — docker --help | grep why 6/14

# pourquoi utiliser Docker ? $ Les Avantages

📦
Portabilité
Build once, run anywhere. Fonctionne en dev, CI, prod — identique.
Rapidité
Démarrage en millisecondes, pas en minutes comme les VMs.
🔒
Isolation
Chaque container a ses propres libs, ports, filesystem. Pas de conflits.
📈
Scalabilité
Répliquer un container en secondes. Scaling horizontal trivial.
🔄
Reproductibilité
Infrastructure as Code. Chaque build est identique et traçable.
🌐
Écosystème
Docker Hub : des milliers d'images prêtes. Nginx, Postgres, Redis...
theo@cloud-s2:~/CM2 — docker image ls 7/14

# les images = templates de containers $ Les Images Docker

Une image est un système de fichiers en couches (layers) — chaque instruction Dockerfile crée une couche.
Les couches sont partagées entre images — stockage optimisé sur le disque.
Hébergées sur un Registry : Docker Hub, GHCR, ECR...
Identifiées par image:tag — ex: nginx:1.25, node:20-alpine
🏃 Container (R/W) éphémère
📝 Code applicatif COPY ./app
📦 Dépendances RUN pip install
🐍 Runtime (Python) FROM python:3.11
🐧 OS Base (Alpine) base layer
theo@cloud-s2:~/myapp — cat Dockerfile 8/14

# définir son image avec un Dockerfile $ Créer ses Images

FROM Image de base — l'OS + runtime
RUN Exécuter une commande (crée une layer)
COPY Copier des fichiers dans l'image
CMD Commande par défaut au démarrage
docker build -t monapp:v1 .
docker run -p 8080:80 monapp:v1
docker push monapp:v1
Dockerfile
1 FROM python:3.11-alpine
2 WORKDIR /app
   # dépendances d'abord (cache Docker)
3 COPY requirements.txt .
4 RUN pip install -r requirements.txt
   # code applicatif
5 COPY . .
6 EXPOSE 5000
7 CMD ["python", "app.py"]
theo@cloud-s2:~/myapp — docker compose up -d 9/14

# orchestrer plusieurs containers localement $ Docker Compose

📄
Un seul fichier YAML
Toute la stack : app, BDD, cache, proxy...
🔗
Réseau automatique
Services accessibles par leur nom : db, web
📦
Volumes persistants
Données conservées entre les restarts
docker compose up -d — démarrer
docker compose down — arrêter
docker compose logs -f — suivre
docker-compose.yml
 1 services:
 2   web:
 3     image: gitea/gitea:latest
 4     ports: ["3000:3000"]
 5     depends_on: [db]
 6   db:
 7     image: postgres:15-alpine
 8     volumes: [pgdata:/var/lib/postgresql]
 9     environment:
10       - POSTGRES_PASSWORD=pass
11 volumes:
12   pgdata:
theo@cloud-s2:~/CM2 — kubectl get pods --all-namespaces 10/14

# de local à production $ En Production

✏️ Code
🔧 Build
docker build
🧪 Test
CI/CD
📤 Push
Registry
🚀 Deploy
docker run
🐳 Docker seul
docker run · docker-compose up
Adapté pour un seul serveur, dev, petites apps. Simple à opérer.
☸️ Kubernetes (Orchestration)
Gère des centaines de containers sur plusieurs serveurs. Auto-scaling, self-healing, rolling updates.
📋 Docker Swarm
L'orchestrateur natif Docker. Plus simple que K8s, intégré dans Docker Engine. Bon intermédiaire.
☁️ Managed (Cloud)
ECS (AWS), Cloud Run (GCP), Azure ACI. Abstraction totale de l'infrastructure.
theo@cloud-s2:~/CM2 — man llm-usage 11/14

# l'IA comme outil, pas comme béquille $ LLMs & Docker

Le LLM est un excellent exécutant
Il génère du code syntaxiquement correct, applique des patterns connus, et produit ce qu'on lui demande — exactement ce qu'on lui demande.
Ce qu'il ne fait pas
Comprendre pourquoi vous avez ce problème · Savoir si sa solution est sécurisée · Anticiper les conséquences en production
Sans les bases : vous ne savez pas ce que vous pouvez demander, et vous ne savez pas si le résultat est bon ou non.
⚠ Exemple 1 — Résoudre le mauvais problème
Conflit de version → LLM télécharge un binaire non signé depuis GitHub. Build réussi. Image vulnérable.
✦ Exemple 2 — Savoir ce qu'on veut demander
Prompt vague → résultat médiocre (1.2 Go, root). Prompt précis → multi-stage build, 180 Mo, non-privilégié.
C'est l'étudiant qui doit être l'architecte.
theo@cloud-s2:~/myapp — docker build . # ça passe... vraiment ? 12/14

# quand le LLM résout le symptôme, pas la cause $ Piège n°1 — La fausse solution

Prompt étudiant
"Mon build échoue parce que libpq-dev est trop vieux, comment je corrige mon Dockerfile ?"
 1 FROM python:3.9-slim
 2 RUN apt-get update && apt-get install -y \
 3     curl gnupg gcc \
 4  && curl -fsSL github.com/jrg94/
 5     libpq-backport/.../amd64.deb
 6     -o libpq-dev.deb
 7  && dpkg -i libpq-dev.deb
Build réussi. Tests passent. Image vulnérable.
Binaire non signé · mainteneur inconnu · sans checksum
Ce qu'un étudiant avec les bases aurait fait
1. Les images slim suivent les releases Debian — les nouvelles embarquent des packages plus récents
2. Package trop vieux → "mon image de base est peut-être obsolète"
3. Tout RUN curl ... .deb && dpkg -i est un signal d'alarme
 1 # Debian Bookworm → libpq 15 inclus
 2 FROM python:3.11-slim  # un mot changé
theo@cloud-s2:~/myapp — docker images # 1.2G → 180M 13/14

# savoir ce qu'on veut pour obtenir ce qu'on mérite $ Piège n°2 — "Améliore mon Dockerfile"

Dockerfile de départ — fonctionne, mais…
 1 FROM node:20
 2 WORKDIR /app
 3 COPY . .
 4 RUN npm install && npm run build
 5 EXPOSE 3000
 6 CMD ["node", "dist/index.js"]
  → 1.2 Go · tourne en root
Prompt sans connaissances
"Améliore mon Dockerfile"
 1 FROM node:20
 2 WORKDIR /app
 3 # Copy package files first for better caching
 4 COPY package*.json ./
 5 RUN npm install
 6 COPY . . && RUN npm run build
 7 CMD ["node", "dist/index.js"]
  → toujours 1.2 Go · toujours root
Quelques commentaires, une ligne bougée. Le LLM a fait ce qu'on lui a demandé.
Prompt avec les bases
"Multi-stage build : stage builder qui compile, stage final node:20-alpine avec dépendances de prod uniquement et utilisateur non-privilégié"
 1 FROM node:20 AS builder
 2 COPY package*.json ./ && RUN npm ci
 3 RUN npm run build
 4 ─────────────────────────────
 5 FROM node:20-alpine
 6 COPY --from=builder /app/dist ./dist
 7 RUN npm ci --omit=dev
 8 RUN adduser -S appuser && USER appuser
1.2 Go → 180 Mo · non-privilégié · production-ready
Le LLM est un excellent exécutant — c'est vous l'architecte.
theo@cloud-s2:~/CM2 — cat RESSOURCES.md 14/14

# pour aller plus loin $ Ressources

🐳
docker.com/get-started Documentation officielle & tutoriels interactifs
officiel
📦
hub.docker.com Registry public — des milliers d'images prêtes
registry
📖
openlegacy.com Architecture monolithique vs microservices
article
⚖️
weave.works — Containers vs VMs Guide pratique pour choisir entre containers et VMs
guide
Theo Rey Site Reliability Engineer contact@reyth.dev
Prochaine étape → TP : Introduction à Docker