Docker de zéro : comprendre et utiliser les conteneurs

Un projet qui « marche sur ma machine » mais plante sur le serveur du collègue, une API Node qui réclame une version précise de PostgreSQL, un déploiement qui prend une demi-journée parce qu’il faut réinstaller la moitié du système : ces frustrations ont un nom commun, et Docker est la réponse que toute l’industrie a adoptée. Conteneuriser, c’est emballer une application avec son environnement — système, dépendances, configuration — dans une unité qui se lance à l’identique partout, du portable du développeur au VPS de production.

Ce guide pose les fondations. Il explique ce qu’est réellement un conteneur, en quoi il diffère d’une machine virtuelle, comment une image se construit et se partage, et comment on assemble plusieurs conteneurs pour faire tourner une vraie application. Il ne prétend pas tout traiter d’un bloc : chaque grande brique est creusée dans un tutoriel pas-à-pas dédié, que vous suivrez dans l’ordre. À la fin du parcours, vous aurez conteneurisé une petite API, l’aurez branchée à une base de données, l’aurez publiée sur un registre, puis déployée sur un serveur.

Sommaire

• Ce que ce parcours vous permettra de faire
• Le parcours d’apprentissage
• Pourquoi Docker s’est imposé
• Les concepts fondamentaux
• Vue d’ensemble pratique
• Les tutoriels du parcours
• Aller plus loin : le niveau avancé
• Réalités du terrain en Afrique de l’Ouest
• Erreurs fréquentes à éviter
• Ressources et références
• Questions fréquentes

🎯 Ce que ce parcours vous permettra de faire

L’objectif n’est pas de « comprendre Docker » en théorie, mais d’être capable de produire des résultats concrets. Au terme du parcours, vous saurez :

• distinguer une image d’un conteneur et lancer n’importe quel logiciel populaire (base de données, serveur web, cache) sans rien installer sur votre système ;
• écrire un Dockerfile qui transforme votre propre application en image réutilisable ;
• orchestrer plusieurs conteneurs ensemble — une API et sa base de données, par exemple — avec un seul fichier compose.yaml et une seule commande ;
• faire persister des données et faire communiquer des conteneurs entre eux grâce aux volumes et aux réseaux ;
• publier votre image sur un registre comme Docker Hub et réduire sa taille pour des déploiements rapides ;
• mettre une application conteneurisée en production sur un serveur, avec redémarrage automatique et contrôle de santé.

🗺️ Le parcours d’apprentissage

Les six tutoriels qui composent ce parcours construisent un seul et même projet, brique après brique. Ce fil rouge est volontairement modeste : « Garde », une petite API REST qui renvoie la liste des pharmacies de garde d’un quartier. C’est assez simple pour ne pas vous noyer dans la logique métier, et assez complet pour avoir besoin d’une base de données, d’un réseau interne et d’un déploiement réel — exactement ce que Docker sert à gérer.

Suivez les étapes dans cet ordre, chacune s’appuyant sur la précédente :

1. Images et conteneurs — vous lancez vos premiers conteneurs à partir d’images publiques et vous comprenez le modèle mental de base.
2. Écrire un Dockerfile — vous transformez le code de l’API « Garde » en votre propre image.
3. Docker Compose — vous faites tourner l’API et PostgreSQL ensemble avec un seul fichier déclaratif.
4. Volumes et réseaux — vous rendez les données de la base durables et vous maîtrisez la communication entre conteneurs.
5. Registre et optimisation — vous publiez l’image et vous la rendez plus légère.
6. Docker en production — vous déployez le tout sur un serveur, proprement.

Pourquoi Docker s’est imposé

Avant les conteneurs, deux mondes coexistaient mal. D’un côté, installer une application directement sur une machine : rapide, mais chaque serveur devenait un assemblage unique de versions et de réglages, impossible à reproduire fidèlement. De l’autre, les machines virtuelles : isolées et reproductibles, mais lourdes — chaque VM embarque un système d’exploitation complet, démarre en dizaines de secondes et consomme plusieurs giga-octets de mémoire rien que pour exister.

Docker, lancé publiquement en 2013, a popularisé une troisième voie. Un conteneur partage le noyau du système hôte au lieu d’embarquer son propre OS. Le résultat tient en trois mots : léger, rapide, portable. Un conteneur démarre en une fraction de seconde, pèse souvent quelques dizaines de méga-octets, et se comporte de façon identique sur le portable d’un développeur à Cotonou, sur le serveur d’intégration continue, et sur le VPS de production. C’est cette reproductibilité qui a fait basculer l’industrie : aujourd’hui, conteneuriser n’est plus une option exotique mais le standard de fait pour livrer du logiciel.

La technologie ne s’est pas figée. Le projet a été standardisé sous l’égide de l’Open Container Initiative (OCI), si bien qu’« image Docker » désigne en réalité un format ouvert que d’autres outils savent lire et produire. Docker reste l’implémentation la plus répandue et la porte d’entrée naturelle ; c’est par elle que ce parcours commence.

Un exemple concret fixe les idées. Imaginez une équipe de trois personnes qui développe l’API « Garde ». Sans Docker, l’un travaille sous Windows, l’autre sous macOS, le serveur tourne sous Linux ; chacun installe Node et PostgreSQL « à sa façon », avec des versions légèrement différentes. Un bug apparaît en production mais reste introuvable en local — la fameuse phrase « pourtant ça marche chez moi ». Avec Docker, les trois lancent exactement la même image, bâtie à partir du même Dockerfile : même version de Node, même PostgreSQL, même configuration. L’environnement cesse d’être une variable cachée. C’est ce déplacement — du « j’installe et j’espère » au « je décris et je reproduis » — qui explique l’adoption massive de la conteneurisation.

L’écosystème : qui fait quoi

Les débutants se perdent souvent dans les noms. Clarifions une fois pour toutes les pièces que vous croiserez :

• Docker Engine — le cœur, qui s’exécute en arrière-plan. Il comprend un daemon (le service dockerd qui gère réellement les images et conteneurs) et une API.
• La CLI docker — l’outil en ligne de commande que vous tapez. C’est elle qui envoie vos ordres au daemon.
• Docker Desktop — l’application de bureau pour Windows et macOS, qui embarque le moteur, l’interface graphique et les outils. Sur un serveur Linux, on n’en a pas besoin : on installe directement le moteur.
• Docker Compose — l’outil qui décrit et lance plusieurs conteneurs ensemble à partir d’un fichier compose.yaml. Désormais intégré comme sous-commande (docker compose).
• BuildKit — le moteur de construction moderne, activé par défaut, qui rend les builds plus rapides et plus malins (cache, étapes parallèles).

Retenez la mécanique : vous tapez une commande dans la CLI, elle parle au daemon, le daemon agit sur les images et les conteneurs. Tout le reste n’est que confort autour de ce trio.

Les concepts fondamentaux

Quatre notions suffisent à tout comprendre. Les maîtriser maintenant, même de façon conceptuelle, rendra chaque tutoriel beaucoup plus clair.

L’image : un modèle figé, en lecture seule

Une image est un paquet immuable qui contient un système de fichiers minimal, votre application et ses dépendances, plus quelques métadonnées (la commande à lancer au démarrage, par exemple). On ne la modifie pas : on la construit une fois, on la versionne avec un tag (comme postgres:17), et on la distribue. Pensez-y comme à un moule.

Le conteneur : une instance vivante de l’image

Lancer une image produit un conteneur : un processus isolé, avec sa propre vue du système de fichiers, du réseau et des processus. C’est l’objet qui s’exécute. À partir d’une même image, on peut démarrer dix conteneurs identiques. Quand un conteneur s’arrête, ce qu’il a écrit dans son système de fichiers disparaît — sauf si on a prévu un volume, ce que vous apprendrez à faire.

Le registre : l’entrepôt d’images

Un registre stocke et distribue les images. Docker Hub est le registre public par défaut ; on y trouve les images officielles de PostgreSQL, Node.js, nginx et des milliers d’autres. Vous y publierez aussi vos propres images, exactement comme on pousse du code sur un dépôt Git.

Le Dockerfile : la recette de construction

Un Dockerfile est un fichier texte qui décrit, instruction par instruction, comment bâtir une image : de quelle image partir, quels fichiers copier, quelles commandes exécuter, quel processus lancer. C’est la pièce qui transforme « du code source » en « image reproductible ».

Le cycle de vie d’un conteneur

Comprendre les états par lesquels passe un conteneur évite bien des confusions. À sa création, le conteneur existe mais ne tourne pas encore (created). Une fois démarré, il est running : son processus principal s’exécute. On peut le mettre en pause, l’arrêter (stopped ou exited) — il existe toujours, avec son système de fichiers intact, prêt à être relancé. Enfin, on le supprime (removed) : il disparaît pour de bon. Un point crucial pour les débutants : un conteneur arrêté n’est pas supprimé. Il occupe encore de la place et garde ses modifications. C’est pourquoi on accumule parfois des dizaines de conteneurs morts qu’un simple docker ps -a révèle, et qu’on nettoie ensuite. Autre règle d’or : un conteneur vit tant que son processus principal vit. Si ce processus se termine, le conteneur s’arrête. C’est la source d’erreur n°1 des débutants — un conteneur qui « ne reste pas allumé » parce que sa commande de démarrage rend la main aussitôt.

L’anatomie d’une image : les couches

Une image n’est pas un bloc monolithique : elle est faite de couches empilées, chacune correspondant à une instruction du Dockerfile. Copier des fichiers crée une couche ; installer des dépendances en crée une autre. Ces couches sont en lecture seule et — détail qui change tout — mises en cache et partagées. Si deux images partent de node:24, elles réutilisent la même couche de base sans la dupliquer sur le disque. Lors d’un build, Docker réutilise les couches inchangées au lieu de tout refaire : voilà pourquoi l’ordre des instructions dans un Dockerfile a un impact direct sur la vitesse. Placer ce qui change rarement (les dépendances) avant ce qui change souvent (votre code) permet de ne reconstruire que le strict nécessaire. Ce mécanisme de cache de couches est aussi ce qui économise votre bande passante : on ne retélécharge que les couches absentes du cache local.

Vue d’ensemble pratique

Voici comment ces pièces s’enchaînent dans la vraie vie, et le tutoriel qui creuse chaque étape.

1. Récupérer et lancer des images existantes. Avant d’écrire quoi que ce soit, on apprend à tirer (docker pull) et exécuter (docker run) des images publiques, à lister ses conteneurs et à les arrêter. C’est l’objet du premier tutoriel, images et conteneurs : le modèle mental de Docker.

2. Construire sa propre image. On écrit un Dockerfile pour l’API « Garde » et on la construit avec docker build. Tout est détaillé dans écrire son premier Dockerfile pas-à-pas.

3. Assembler plusieurs services. Une vraie application, c’est rarement un seul conteneur. On déclare l’API et sa base PostgreSQL dans un fichier compose.yaml et on lance le tout d’une commande, comme l’explique débuter avec Docker Compose.

4. Persister et connecter. Les données d’une base doivent survivre au redémarrage d’un conteneur, et l’API doit pouvoir joindre la base par son nom. Les volumes et les réseaux, traités dans volumes et réseaux Docker, règlent ces deux questions.

5. Publier et alléger. Une image de 1,2 Go se déploie lentement sur une connexion modeste. On apprend à la pousser sur un registre et à la réduire dans publier et optimiser ses images Docker.

6. Mettre en ligne. Enfin, on déploie « Garde » sur un serveur avec une politique de redémarrage, des variables d’environnement et un contrôle de santé, dans déployer Docker en production sur un VPS.

Les tutoriels du parcours

Chaque tutoriel ci-dessous construit une brique du projet « Garde ». Prenez-les dans l’ordre la première fois ; revenez-y ensuite comme à des fiches de référence.

• Images et conteneurs : le modèle mental de Docker — lancer des conteneurs, comprendre images, tags et cycle de vie.
• Écrire son premier Dockerfile — emballer l’API « Garde » dans une image maison.
• Débuter avec Docker Compose — faire tourner API + PostgreSQL d’une seule commande.
• Volumes et réseaux Docker — rendre les données durables et faire dialoguer les conteneurs.
• Publier et optimiser ses images — Docker Hub, .dockerignore et images légères.
• Déployer Docker en production sur un VPS — redémarrage, santé, exposition derrière un proxy.

Aller plus loin : le niveau avancé

Une fois ces fondations acquises, plusieurs sujets pointus prolongent naturellement le parcours. Ils supposent que vous êtes déjà à l’aise avec les conteneurs, et c’est pourquoi ils ne figurent pas dans la progression débutante :

• les builds multi-étapes pour des images de production minuscules ;
• Docker rootless et le durcissement sécurité des conteneurs ;
• Docker Compose en production dans ses usages plus poussés ;
• le comparatif Docker contre Podman, pour situer les alternatives sans daemon.

Et pour la suite logique au-delà d’un seul serveur, l’orchestration de conteneurs à grande échelle se découvre avec Kubernetes via kind.

Docker du développement à la production

La vraie valeur de la conteneurisation se révèle quand on suit une fonctionnalité tout au long de sa vie. Sur votre poste, vous développez « Garde » dans un conteneur identique à celui qui tournera en ligne ; le « ça marche chez moi » perd son sens, puisque « chez moi » et « en production » sont la même image. Quand vous poussez votre code, un système d’intégration continue construit l’image, lance les tests dans un conteneur, puis publie l’image validée sur un registre. Le serveur de production n’a alors qu’à tirer cette image précise et la lancer. Aucune étape ne réinstalle quoi que ce soit à la main : on promeut un artefact unique et figé, de la machine du développeur jusqu’au serveur. Cette continuité est exactement ce que les six tutoriels reconstituent, à votre échelle, avec un seul projet. Vous n’apprenez pas des commandes isolées : vous montez une chaîne de bout en bout.

Réalités du terrain en Afrique de l’Ouest

Docker prend tout son sens dans un contexte où le matériel et la bande passante coûtent cher. Quelques points méritent qu’on s’y arrête.

La bande passante est une ressource rare. Tirer une image de plusieurs centaines de méga-octets sur une connexion ADSL d’Abidjan ou une 4G partagée à Bamako peut prendre de longues minutes — et se payer en forfait data. C’est l’argument décisif pour des images légères : une base alpine de 5 Mo plutôt qu’une ubuntu de 70 Mo change concrètement le quotidien. Le tutoriel sur l’optimisation y revient en détail.

Le cache local est votre ami. Docker conserve les couches d’images déjà téléchargées. Construire intelligemment ses Dockerfile pour réutiliser ce cache évite de retélécharger les dépendances à chaque build — un gain de temps et de data considérable quand on itère.

Les VPS abordables suffisent. On n’a pas besoin d’un cloud hors de prix pour héberger une application conteneurisée. Un petit VPS à quelques milliers de francs CFA par mois, avec 1 à 2 Go de mémoire, fait tourner sans peine l’API « Garde » et sa base. La conteneurisation rend d’ailleurs la migration d’un hébergeur à l’autre quasi indolore : on déplace des images, pas une installation artisanale.

Les coupures électriques imposent la résilience. Une politique de redémarrage automatique (restart: unless-stopped) garantit que vos conteneurs repartent seuls après une coupure suivie d’un retour du courant, sans intervention manuelle. C’est traité dans le tutoriel de mise en production.

Erreurs fréquentes à éviter

Ressources et références

• Documentation officielle Docker — la référence à jour pour chaque commande et fichier.
• Guide « Get started » de Docker — le parcours d’introduction officiel.
• Docker Hub — le registre public des images officielles.
• Référence du Dockerfile — toutes les instructions et leur syntaxe exacte.
• Documentation Docker Compose — spécification du fichier compose.yaml.
• Open Container Initiative — les standards ouverts derrière les images et l’exécution.

Questions fréquentes

Docker est-il gratuit ?
Le moteur Docker (Docker Engine) est open source et gratuit. Docker Desktop, l’application de bureau pour Windows et macOS, est gratuite pour un usage personnel, l’éducation et les petites entreprises ; les grandes organisations relèvent d’un abonnement payant. Sur un serveur Linux, on installe directement Docker Engine, sans Docker Desktop.

Faut-il connaître Linux pour utiliser Docker ?
Quelques bases aident — naviguer dans un terminal, comprendre les chemins de fichiers, les permissions. Mais on peut démarrer avec très peu : les tutoriels de ce parcours expliquent chaque commande. Si les permissions Linux vous intimident, la lecture de chmod, chown et sudo expliqués pas-à-pas lèvera l’essentiel des blocages.

Quelle différence entre Docker et une machine virtuelle ?
Une VM virtualise tout un ordinateur, noyau du système d’exploitation compris : elle est isolée mais lourde et lente à démarrer. Un conteneur partage le noyau de l’hôte et n’isole que l’espace utilisateur : il est beaucoup plus léger et démarre quasi instantanément. On utilise souvent les deux ensemble — des conteneurs à l’intérieur de VM.

Docker fonctionne-t-il sous Windows ?
Oui, via Docker Desktop, qui s’appuie sur WSL 2 (le sous-système Linux de Windows). Les conteneurs restent des conteneurs Linux ; les commandes sont identiques à celles d’un serveur. Pour de la production, on cible toutefois quasi toujours un hôte Linux.

Dois-je apprendre Kubernetes juste après ?
Pas immédiatement. Kubernetes orchestre des conteneurs sur de nombreuses machines ; c’est un sujet vaste, utile quand on dépasse un seul serveur ou qu’on a besoin de mise à l’échelle automatique. Maîtrisez d’abord Docker et Compose : une grande partie des projets n’a jamais besoin d’aller plus loin.

Combien de mémoire faut-il pour commencer ?
Pour suivre ce parcours, une machine avec 4 Go de RAM suffit largement. L’API « Garde » et sa base PostgreSQL tiennent dans quelques centaines de méga-octets. En production, un VPS de 1 à 2 Go convient pour ce type de petite application.

Que deviennent mes données quand un conteneur est supprimé ?
Tout ce qui a été écrit dans le système de fichiers du conteneur disparaît avec lui. C’est voulu : un conteneur est jetable. Pour conserver des données — le contenu d’une base, par exemple — on utilise un volume, un espace de stockage géré par Docker qui survit à la suppression du conteneur. C’est l’objet du tutoriel sur les volumes et réseaux, et une étape incontournable dès qu’une base de données entre en jeu.

Docker et Docker Compose, est-ce la même chose ?
Non, mais ils vont de pair. Docker gère un conteneur à la fois via la commande docker. Docker Compose, invoqué par docker compose, lit un fichier compose.yaml qui décrit plusieurs conteneurs et leurs relations, puis les démarre ou les arrête ensemble. Dès qu’une application a plus d’un service — typiquement une API et sa base — Compose remplace avantageusement une série de longues commandes docker run.