---
title: Récapitulatif
description: Toutes les notions du cours Docker en une page.
---

| Notion | En une phrase |
| --- | --- |
| Docker | Empaquette l'application et son environnement dans une image reproductible. |
| Engine / Desktop | Engine est le daemon Linux ; Desktop le fait tourner dans une VM Linux sur Mac et Windows. |
| Conteneur / VM | Une VM possède un noyau invité ; un conteneur partage le noyau de l'hôte. |
| Image | Template figé en lecture seule, composé de couches, existant ou construit par un Dockerfile. |
| Cycle | Code + Dockerfile → build → image → run → conteneur. |
| Compose | Décrit et orchestre une stack multi-services dans un YAML déclaratif. |
| Volume | Stockage persistant découplé du conteneur et géré par Docker. |
| Réseau | Réseau bridge privé où les services se joignent par leur nom. |
| Mapping de ports | Publie un port du conteneur vers l'hôte ; le reste demeure interne. |
| Serveur | Accès par clé, compte non-root, ports minimaux, correctifs et sauvegardes testées. |
| CI | Vérifie chaque changement avant qu'il atteigne la branche principale. |
| CD | Publie une image versionnée puis déploie la même image dans un environnement protégé. |
| Déploiement | Pull d'un tag immuable, remplacement des conteneurs, contrôles de santé et rollback. |
| Testcontainers | Infrastructure réelle, isolée et jetable, démarrée par les tests. |

## Les commandes essentielles

```bash
# Construire une image
docker build -t mon-app:1.0.0 .

# Lancer un conteneur
docker run --rm mon-app:1.0.0

# Démarrer une stack Compose
docker compose up -d --build

# Voir les conteneurs
docker compose ps

# Suivre les journaux
docker compose logs --follow

# Arrêter la stack sans supprimer les volumes
docker compose down

# Récupérer et lancer les images de production
docker compose pull
docker compose up -d --no-build
```

## Les règles à retenir

1. Épingle les versions des images au lieu de dépendre de `latest`.
2. Ordonne le Dockerfile du plus stable au plus volatil.
3. Utilise un `.dockerignore` pour garder un contexte de build propre.
4. Sépare le builder et le runtime avec un build multi-stage.
5. Stocke les données persistantes dans des volumes sauvegardés.
6. Utilise les noms de services, pas `localhost`, entre conteneurs.
7. Ne publie que les ports réellement nécessaires.
8. Sécurise le serveur et teste les sauvegardes avant le premier déploiement.
9. Construis l'image dans la CI et exécute cette même image en production.
10. Versionne chaque image et conserve le tag précédent pour le rollback.
11. Déploie avec une clé dédiée et des permissions limitées.
12. Préfère une infrastructure de test réelle et isolée lorsque l'intégration compte.

<Callout title="Fin du cours" type="success">
  Reviens au [cas pratique](/docs/cas-pratique/react-nest-postgresql) pour la stack applicative, puis suis le [flux CI/CD complet](/docs/ci-cd/flux-complet) pour aller jusqu'à la production.
</Callout>