DOCKER

Le paquet cadeau de tes applications

Conteneurisation, isolation, portabilité
Ce qu'un dev doit comprendre avant le premier docker run

Cégep de Matane / Cégep de Rimouski

Docker, c'est un paquet cadeau

Tu emballes ton app avec TOUT ce qu'il lui faut, et tu l'envoies n'importe où

Une image Docker
  • Code de l'application
  • Runtime / interpréteur (PHP, Node, Python...)
  • Bibliothèques système (libssl, libcurl...)
  • Outils CLI nécessaires
  • Fichiers de config (php.ini, nginx.conf...)
  • Variables d'environnement
L'idée clé : « Ça marche sur ma machine » devient « ça marche partout », parce que tu emballes la machine avec le code.

Trois façons de faire rouler un logiciel

Installation native vs VM (VirtualBox) vs Conteneur Docker

Critère Installation native VM VirtualBox Conteneur Docker
IsolationAucune - partage tout l'OSTotale - OS invité completProcessus isolés (namespaces, cgroups)
RessourcesLégères (juste l'app)Lourdes (RAM/CPU réservés, plusieurs Go disque)Légères (~quelques Mo à Go, partage le kernel)
DémarrageInstantané (déjà installé)Lent (boot d'un OS, 30s à plusieurs min)Quasi instantané (~1 seconde)
PortabilitéFaible - refaire l'install partoutBonne mais fichiers .ova énormesExcellente - image légère, registry centralisé
ReproductibilitéAléatoire (dépend de l'état du système)Bonne (snapshot complet)Parfaite (Dockerfile = recette versionnée)
Cas typiqueApp de bureau personnelleTester un autre OS, isolation forteMicroservices, dev/prod cohérents, CI/CD

Note technique : la VM virtualise tout le matériel et fait tourner un OS complet par-dessus. Docker ne virtualise rien - il isole des processus en utilisant le kernel de l'hôte. C'est la raison fondamentale de la différence de poids.

Installation native : ton app s'éparpille partout

Versus Docker : tout reste dans la boîte

Installation native

Système d'exploitation
/usr/bin/monapp /etc/monapp/conf /var/lib/monapp /usr/lib/libssl.so ~/.monapp/cache /var/log/monapp /etc/systemd/... /usr/share/doc Registre Windows PATH modifié

Désinstaller proprement = mission impossible

Avec Docker

Système d'exploitation (hôte)
Tout est ici

docker rm = tout disparaît, zéro résidu

Pourquoi c'est si léger ? Le partage du kernel

Comparaison architecturale : VM vs Docker

Machine virtuelle

App 1 Bins/Libs OS invité 1 + Kernel Hyperviseur (VirtualBox) OS hôte + Kernel Matériel (CPU, RAM, disque)

Chaque app = un OS complet

Docker

PHPBins/Libs PHP
NodeBins/Libs Node
NginxBins/Libs Nginx
Matériel (CPU, RAM, disque) OS hôte + Kernel (PARTAGÉ) Docker Engine

Trois apps, un seul kernel partagé

Utiliser un Docker existant

Docker Hub : la bibliothèque mondiale d'images prêtes à l'emploi

Docker Hub hub.docker.com Des milliers d'images publiques
docker pull
➞
Image locale (le « plan » figé)
docker run
➞
Conteneur (qui tourne!)
Les 4 commandes que tu utilises tous les jours 
$ docker pull nginx:alpine
  Télécharge l'image nginx (variante Alpine, ultra légère) depuis le Hub

$ docker run -d -p 8080:80 --name alpes nginx:alpine
  Lance le conteneur en arrière-plan, mappe le port 8080 hôte → 80 conteneur

$ docker ps
  Liste les conteneurs en cours d'exécution

$ docker exec -it alpes sh
  Ouvre un shell DANS le conteneur (utile pour fouiller, déboguer)

Vocabulaire à retenir : image = recette/plan figé. conteneur = instance vivante de l'image. Tu peux lancer 50 conteneurs depuis la même image.

Faire son propre Docker : le Dockerfile

Une recette texte → une image personnalisée

Le principe

  1. Tu pars d'une image de base (Alpine, Ubuntu, Node...)
  2. Tu écris une suite d'instructions dans un fichier nommé Dockerfile
  3. Tu fais docker build → Docker exécute chaque instruction dans l'ordre et empile des couches (layers)
  4. Résultat : une nouvelle image, à toi, prête à lancer ou à publier
Dockerfile (exemple PHP+Apache) 
# On part d'une image officielle PHP+Apache
FROM php:8.3-apache

# Installer extensions PHP nécessaires
RUN docker-php-ext-install pdo pdo_mysql

# Copier le code source dans l'image
COPY ./src/ /var/www/html/

# Variables d'env
ENV APP_ENV=production

# Port que le conteneur écoute
EXPOSE 80

# Commande lancée au démarrage
CMD ["apache2-foreground"]

$ docker build -t mon_php_app .

Astuce : Docker met chaque instruction en cache. Si tu changes seulement ton code, il ne réinstalle pas les extensions PHP - il réutilise les couches précédentes. Mets donc les choses qui changent souvent en BAS du Dockerfile.

Copier et personnaliser une image existante

Trois techniques selon ton besoin

1. Étendre avec FROM Le cas normal : Dockerfile 
FROM nginx:alpine
COPY ./mon-site/
  /usr/share/nginx/html/
COPY nginx.conf
  /etc/nginx/nginx.conf

→ Tu hérites de tout ce que l'image officielle a fait, tu rajoutes ta couche par-dessus.

2. Modifier un conteneur vivant Pour expérimenter, puis figer 
$ docker run -it ubuntu bash
# apt install python3 vim ...
# exit
$ docker commit <id> mon_image

→ Pratique pour bricoler, mais pas reproductible. Pour la prod : Dockerfile.

3. Récupérer un Dockerfile Pour étudier ou forker

Sur Docker Hub, chaque image officielle a un lien GitHub vers son Dockerfile.

$ git clone <repo>
$ # tu modifies
$ docker build -t ma_version .

Les images de base à connaître

Celles qu'on retrouve partout, pour tes cours et tes projets

alpine ~5 Mo

Linux ultra-minimaliste (musl libc, BusyBox). Base de prédilection pour des images très légères. Gestionnaire de paquets : apk.

FROM alpine:3.19
ubuntu / debian ~30-80 Mo

Distribution Linux classique. Plus gros qu'Alpine mais glibc + plus de paquets disponibles. Quand t'as besoin d'outils standards.

FROM ubuntu:24.04
nginx ~25 Mo (alpine)

Serveur web et reverse proxy haute performance. Idéal pour servir du statique ou faire du load balancing devant des apps.

FROM nginx:alpine
httpd (apache) ~145 Mo

Le serveur web Apache HTTPD. Pour servir du statique ou comme base de PHP. Variante php:apache combine les deux.

FROM httpd:2.4-alpine
php Multiples variantes

Plusieurs déclinaisons : php:cli (juste l'interpréteur), php:fpm (pour Nginx), php:apache (avec mod_php intégré). Variante -alpine = légère.

FROM php:8.3-apache
node ~50 Mo (alpine)

Runtime JavaScript V8. Pour apps Express, Next.js, build front-end. Variante node:lts-alpine = stable et compacte.

FROM node:20-alpine
python ~50 Mo (slim)

Interpréteur Python avec pip. Variantes -slim et -alpine pour réduire la taille. Très utilisé pour scripts, data, ML.

FROM python:3.12-slim
mysql / postgres ~200-400 Mo

Bases de données prêtes à l'emploi. Configurées via variables d'env (MYSQL_ROOT_PASSWORD, POSTGRES_DB...). Volumes pour persister.

FROM postgres:16-alpine

Pattern fréquent : stack web LAMP/LEMN = nginx (ou apache) + php-fpm + mysql/postgres + ton code, orchestré avec docker compose. C'est le squelette de 80% des projets web.

Les images de base à connaître

Celles qu'on retrouve partout, pour tes cours et tes projets

alpine ~5 Mo

Linux ultra-minimaliste (musl libc, BusyBox). Base de prédilection pour des images très légères. Gestionnaire de paquets : apk.

FROM alpine:3.19
ubuntu / debian ~30-80 Mo

Distribution Linux classique. Plus gros qu'Alpine mais glibc + plus de paquets disponibles. Quand t'as besoin d'outils standards.

FROM ubuntu:24.04
nginx ~25 Mo (alpine)

Serveur web et reverse proxy haute performance. Idéal pour servir du statique ou faire du load balancing devant des apps.

FROM nginx:alpine
httpd (apache) ~145 Mo

/usr/local/apache2/htdocs/

FROM httpd:2.4-alpine
php Multiples variantes

/var/www/html

FROM php:8.3-apache
node ~50 Mo (alpine)

Runtime JavaScript V8. Pour apps Express, Next.js, build front-end. Variante node:lts-alpine = stable et compacte.

FROM node:20-alpine
python ~50 Mo (slim)

Interpréteur Python avec pip. Variantes -slim et -alpine pour réduire la taille. Très utilisé pour scripts, data, ML.

FROM python:3.12-slim
mysql / postgres ~200-400 Mo

Bases de données prêtes à l'emploi. Configurées via variables d'env (MYSQL_ROOT_PASSWORD, POSTGRES_DB...). Volumes pour persister.

FROM postgres:16-alpine

Pattern fréquent : stack web LAMP/LEMN = nginx (ou apache) + php-fpm + mysql/postgres + ton code, orchestré avec docker compose. C'est le squelette de 80% des projets web.

Ce qu'il faut retenir

Métaphore

Docker = paquet cadeau. Tu emballes ton app + son environnement complet, tu envoies, ça marche partout pareil.

vs VM, vs Native

Plus léger qu'une VM (partage le kernel hôte), plus propre qu'une install native (zéro éparpillement, suppression nette).

Image vs Conteneur

Image = recette figée. Conteneur = instance vivante. Une image → autant de conteneurs que tu veux.

Utiliser

docker pull, docker run. Docker Hub = bibliothèque mondiale d'images officielles à télécharger gratuitement.

Fabriquer

Dockerfile = recette texte. FROM (base) + RUN (installer) + COPY (ton code) + CMD (lancer). docker build pour construire.

Bases à connaître

Alpine (mini), Ubuntu/Debian (complet), Nginx, Apache, PHP, Node, Python, MySQL, Postgres. Tu vas les croiser partout.

Prochaine étape : docker compose pour orchestrer plusieurs conteneurs ensemble.