Docker

Présentation¶

Docker est une plateforme open source de conteneurisation d’applications, publiée en 2013 par Solomon Hykes chez dotCloud (devenu Docker Inc.). Elle permet d’empaqueter une application avec l’ensemble de ses dépendances — bibliothèques, configuration, variables d’environnement — dans une unité portable appelée conteneur, exécutable de façon identique sur n’importe quel environnement.

Le principe fondamental : build once, run anywhere. L’image Docker décrit une fois l’environnement d’exécution ; le conteneur en est l’instance active.

VM vs conteneurs¶

Les machines virtuelles et les conteneurs répondent au même besoin d’isolation, mais avec des approches radicalement différentes.

La différence fondamentale : la VM embarque un OS invité complet au-dessus d’un hyperviseur. Le conteneur partage le kernel de l’OS hôte — seuls les binaires et bibliothèques propres à l’application sont isolés.

Principe de fonctionnement¶

Docker repose sur trois mécanismes Linux :

• Namespaces : isolent la vue du système pour chaque conteneur — processus (PID), réseau, montages, utilisateurs. Chaque conteneur croit être seul sur la machine

• Cgroups (Control Groups) : limitent les ressources allouées — CPU, mémoire, I/O réseau et disque

• Overlay filesystem (OverlayFS) : gestion des images en couches superposées. Chaque instruction Dockerfile crée une couche en lecture seule ; le conteneur ajoute une couche d’écriture au-dessus

Les couches de l’image de base sont partagées entre tous les conteneurs qui en dérivent — une seule copie sur le disque, quelle que soit la quantité d’images construites dessus.

L’écosystème Docker¶

• Docker Engine : cœur du système — daemon (dockerd), CLI (docker) et API REST

• Docker Hub : registry public hébergeant 100 000+ images officielles et communautaires (hub.docker.com)

• Docker Compose : outil de définition et d’orchestration d’applications multi-conteneurs via un fichier YAML

• Docker Swarm : mode cluster natif — répartition de charge, haute disponibilité, rolling updates

• Volumes : persistance des données indépendante du cycle de vie des conteneurs

• Réseaux : isolation et communication contrôlées entre conteneurs (bridge, overlay, macvlan)

Cas d’utilisation¶

Packaging d’application L’image Docker embarque le code, les dépendances et la configuration dans une unité immuable. L’environnement est identique en développement, en test et en production — les divergences de type “ça marche sur ma machine” disparaissent.

Déploiement rapide Une stack complète (web + base de données + cache) se déploie en quelques secondes avec docker-compose up. La même commande reproduit l’environnement à l’identique sur n’importe quel hôte.

Coexistence de versions Plusieurs versions d’un même runtime (Node 18, 20, 22 ; Python 3.10, 3.12 ; Java 11, 21) coexistent sur un même serveur sans conflit, chacune dans son conteneur isolé.

Microservices Chaque service (authentification, paiement, catalogue…) est packagé dans son propre conteneur, déployé et scalé indépendamment. Docker Swarm ou Kubernetes orchestrent leur cycle de vie.

CI/CD Les pipelines de build utilisent des conteneurs éphémères comme environnements d’exécution — chaque build repart d’une image propre, sans résidu du build précédent.

Environnements de développement Bases de données, brokers de messages, outils de monitoring s’instancient localement en une commande, sans installation native sur le poste.

Solutions alternatives¶

Docker n’est pas la seule solution de conteneurisation. Le standard OCI (Open Container Initiative) définit des spécifications interopérables — toutes les solutions ci-dessous sont compatibles avec les images Docker.

Podman mérite une attention particulière pour les environnements d’entreprise : il fonctionne sans daemon root (rootless), ce qui réduit la surface d’attaque. Sa CLI est compatible avec Docker — la plupart des commandes docker s’exécutent en substituant podman.

Docker Hub¶

hub.docker.com est le registry public officiel de Docker. Il héberge :

• Images officielles : maintenues par Docker Inc. ou les éditeurs — nginx, postgres, python, node, mariadb… Auditées, documentées, mises à jour régulièrement

• Images certifiées : fournies par des éditeurs tiers (Red Hat, Bitnami…)

• Images communautaires : publiées par n’importe quel utilisateur

Toute image est identifiée par NOM:TAG (ex. nginx:alpine, python:3.12, mariadb:10.11). Le tag latest pointe vers la version la plus récente mais est à éviter en production (non déterministe).

Il est possible de déployer un registry privé auto-hébergé (registry:2) pour distribuer des images internes sans les exposer publiquement.

Microservices et Docker¶

L’architecture microservices découpe une application monolithique en services autonomes, chacun responsable d’une fonction métier précise.

Chaque service :

• tourne dans son propre conteneur avec le runtime adapté à son langage

• dispose de sa propre base de données (pas de schéma partagé)

• se déploie et se scale indépendamment des autres

• communique via API REST ou messagerie asynchrone

Docker Swarm ou Kubernetes orchestrent l’ensemble : déploiement, mise à l’échelle automatique, redémarrage en cas d’échec, mise à jour sans interruption.

Docker et Kubernetes¶

Docker et Kubernetes sont complémentaires, pas concurrents. Docker construit et fait tourner les conteneurs ; Kubernetes les orchestre à grande échelle.

Docker opère à l’échelle d’un hôte unique : il crée les images, démarre les conteneurs, gère les volumes et les réseaux locaux. Docker Compose orchestre plusieurs conteneurs sur ce même hôte. Docker Swarm étend cette orchestration à un cluster de quelques nœuds, avec une complexité de mise en œuvre faible.

Kubernetes opère à l’échelle d’un cluster de nœuds : il prend en entrée des images Docker (ou OCI) et se charge de les scheduler sur les bons nœuds, de les redémarrer en cas d’échec, de les exposer via des services réseau, de les scaler automatiquement selon la charge. Kubernetes utilise containerd ou CRI-O comme runtime bas niveau — Docker Engine lui-même repose sur containerd.

Quand choisir Docker Swarm plutôt que Kubernetes ?

• Équipe petite, sans compétence Kubernetes

• Application avec pic de charge modéré et prévisible

• Infrastructure sur site sans plateforme cloud managée

• Délai de mise en production court

Quand choisir Kubernetes ?

• Centaines de conteneurs à orchestrer

• Autoscaling réactif requis (pics de charge imprévisibles)

• Multi-cloud ou hybride cloud/on-premise

• Exigences de haute disponibilité (SLA 99,9%+)

• Équipe DevOps dédiée

Exercices¶

Les corrections sont disponibles sous chaque énoncé (menu déroulant).