2 Installation Docker et environnement de travail

2.1 Pourquoi préparer un environnement Docker ?

Avant de travailler avec des conteneurs, il faut comprendre où s’exécutent les applications et quel composant les pilote.
Docker ne remplace pas le système d’exploitation : il s’appuie sur ses mécanismes pour créer et gérer des conteneurs.

Trois éléments doivent être distingués :

1. Le système hôte fournit le noyau Linux et les ressources matérielles.
2. Docker Engine crée, démarre et administre les conteneurs.
3. Le client Docker transmet les demandes à Docker Engine.

2.2 Docker Engine : les composants installés

Sur Ubuntu, l’installation courante de Docker repose sur plusieurs composants complémentaires :

• Docker daemon ( dockerd ) : service qui gère images, conteneurs, réseaux et volumes.
• Docker CLI ( docker ) : interface en ligne de commande utilisée par l’administrateur.
• containerd : composant d’exécution qui participe à la gestion du cycle de vie des conteneurs.
• Docker Compose Plugin : extension qui permet de décrire et piloter une application composée de plusieurs services.

Visuellement :

Le daemon s’exécute généralement en arrière-plan sous forme de service système.
La CLI et Compose dialoguent avec le moteur Docker ; ils ne constituent pas deux moteurs supplémentaires.

2.3 Ubuntu : installation et gestion du service

Pour un environnement de formation, Ubuntu constitue une base Linux cohérente avec les mécanismes de conteneurisation étudiés au chapitre 1.

Les étapes de l’installation

1. Préparer Ubuntu et disposer des droits d’administration nécessaires.
2. Configurer une source de paquets adaptée pour installer Docker Engine et le plugin Compose.
3. Installer les composants du moteur et de ses outils.
4. Contrôler le service et vérifier que le client peut communiquer avec le daemon.

Comprendre systemd

Sur une distribution Ubuntu utilisant systemd , Docker est généralement géré par une unité de service nommée docker.service .
Les notions de démarrage, d’arrêt, de redémarrage et d’activation au démarrage sont celles des services Linux classiques.

2.4 Droits d’accès : pourquoi le socket Docker est important

2.4.1 Le besoin : autoriser le client à piloter le moteur

Quand tu saisis docker container ls, le client Docker ne gère pas lui-même les conteneurs.
Il transmet sa demande au daemon Docker, généralement par le socket Unix /var/run/docker.sock sur Ubuntu.

Le problème : ce socket donne accès à des opérations puissantes : créer des conteneurs, monter des répertoires de l’hôte et agir sur les ressources du système.
Il faut donc déterminer qui a le droit de communiquer avec le daemon, et pas seulement qui peut exécuter la commande docker.

2.4.2 Deux façons courantes de donner cet accès

1. Avec sudo : sudo docker container ls utilise les privilèges d’administration pour accéder au moteur.
2. Avec le groupe docker : docker container ls fonctionne sans sudo si l’utilisateur dispose des autorisations nécessaires sur le socket.

Objectif à retenir : comprendre pourquoi une commande Docker peut échouer avec « permission denied », même lorsque Docker est installé et démarré.
Il s’agit alors souvent d’un problème de droits sur le socket, pas d’un problème de conteneur.

2.4.3 Pourquoi existe-t-il un mode rootless ?

Dans une installation classique, le daemon Docker s’exécute généralement avec les privilèges root.
Une personne autorisée à piloter ce daemon peut donc indirectement obtenir des droits très élevés sur l’hôte.

Le mode rootless répond à ce risque : le daemon et les conteneurs sont exécutés sans privilèges root sur l’hôte, en s’appuyant notamment sur les espaces de noms utilisateurs Linux (user namespaces).

Objectif : limiter l’impact d’une compromission du moteur ou d’un conteneur sur le système hôte.
Cela ne rend pas les conteneurs automatiquement sûrs et introduit des contraintes possibles sur le réseau, le stockage ou certaines fonctionnalités.

2.5 Comprendre le contexte Docker

Un même client docker peut piloter plusieurs moteurs : celui de ta machine, un moteur distant accessible en SSH ou celui de Docker Desktop.

Exemples :

• Un moteur Docker local sur Ubuntu.
• Un moteur Docker accessible sur une autre machine, via SSH.
• Un moteur fourni par Docker Desktop dans un environnement Windows.

Un contexte Docker enregistre les paramètres de connexion à l’un de ces moteurs.

2.5.1 Exemple de contextes disponibles

Voici un exemple fictif mais représentatif de la sortie de docker context ls sur une machine où plusieurs connexions ont été configurées.

Cela pourrait donner :

$ docker context ls
NAME                DESCRIPTION                      DOCKER ENDPOINT
default *           Configuration locale            unix:///var/run/docker.sock
serveur-recette     Serveur distant via SSH          ssh://devops@recette.example.net
desktop-linux       Docker Desktop                   npipe:////./pipe/dockerDesktopLinuxEngine

L’astérisque * indique le contexte actif.
Dans cet exemple, default est sélectionné et le client tente d’utiliser le socket local.

$ docker context show
default

Attention : les contextes réellement présents, leurs noms et leurs endpoints dépendent du système et de la configuration.
Sous Windows, l’endpoint de Docker Desktop peut être différent ; depuis Ubuntu sous WSL 2, il peut apparaître comme un socket Unix.

2.5.2 Choisir explicitement un moteur

# Sélectionner le contexte local
$ docker context use default

# Sélectionner un contexte distant déjà configuré
$ docker context use serveur-recette

# Utiliser un contexte pour une seule commande, sans changer le contexte actif
$ docker --context serveur-recette container ls

2.6 Bonus — Windows : WSL 2 et Docker Desktop

2.6.1 Référence — Docker Engine sur Ubuntu Linux

Sur une installation Ubuntu classique, le client contacte le moteur local par le socket Unix :

# Terminal Ubuntu : moteur Docker Engine local
$ docker context use default
$ docker context show
default
$ docker info --format '{{.Name}} | {{.OperatingSystem}}'
ubuntu-lab | Ubuntu 24.04 LTS

La dernière ligne est un exemple de résultat : le nom et la version dépendent de ta machine.

2.6.2 Bonus — Ubuntu sous WSL 2 : utiliser son propre Docker Engine

Dans PowerShell, ouvre d’abord Ubuntu :

# PowerShell Windows
PS> wsl -d Ubuntu

Puis, dans le terminal Ubuntu WSL 2, si Docker Engine y a été installé et si Docker Desktop n’intercepte pas le socket :

# Terminal Ubuntu WSL 2 : vérifier le moteur local
$ sudo systemctl status docker
$ docker context use default
$ docker context show
default
$ docker info --format '{{.Name}} | {{.OperatingSystem}}'
ubuntu-wsl | Ubuntu 24.04 LTS

Point crucial : default ne prouve pas à lui seul que le daemon appartient à Ubuntu.
Il faut vérifier quel processus écoute sur /var/run/docker.sock et si Docker Desktop est intégré à cette distribution.

# Vérifier où pointe le socket Docker
$ ls -l /var/run/docker.sock
$ readlink -f /var/run/docker.sock

# Vérifier que le daemon local est actif
$ systemctl is-active docker
$ pgrep -a dockerd

# Vérifier le moteur effectivement interrogé par la CLI
$ docker context show
$ docker info --format '{{.Name}} | {{.DockerRootDir}}'

# Vérifier si un endpoint explicite contourne le contexte
$ printenv DOCKER_HOST DOCKER_CONTEXT

Sur un moteur Ubuntu installé localement, dockerd doit être visible dans la distribution et le service docker doit être actif.
Un socket redirigé vers un chemin partagé par Docker Desktop, ou l’absence de daemon local alors que docker info répond, indique qu’il faut examiner l’intégration Docker Desktop.

2.6.3 Bonus — Docker Desktop : utiliser son moteur

Depuis PowerShell Windows, avec Docker Desktop démarré :

# PowerShell Windows : contexte Docker Desktop
PS> docker context ls
PS> docker context use desktop-linux
PS> docker context show
desktop-linux
PS> docker info --format '{{.Name}} | {{.OperatingSystem}}'
docker-desktop | Docker Desktop

Les résultats affichés sont illustratifs.
Le contexte desktop-linux doit exister ; sinon, consulte docker context ls pour connaître son nom réel.

2.7 Vérifier et diagnostiquer son environnement Docker

Installer la commande docker ne suffit pas : il faut aussi que le daemon fonctionne, que le client puisse le joindre et que l’utilisateur dispose des droits nécessaires.

2.7.1 Les vérifications essentielles

# Identifier le contexte sélectionné
$ docker context show

# Vérifier la connexion au moteur
$ docker version

# Vérifier que le daemon répond
$ docker info

# Vérifier que Compose est disponible
$ docker compose version

# Vérifier la capacité à exécuter un conteneur
$ docker run --rm hello-world

La commande docker version affiche notamment les informations Client et Server lorsque le moteur est accessible.
hello-world valide un premier lancement ; l’image peut être téléchargée si elle n’est pas présente localement.

2.7.2 Si cela ne fonctionne pas : par où commencer ?

Méthode de diagnostic : vérifier d’abord le contexte, puis la connexion au daemon, les permissions et enfin la capacité à lancer un conteneur.
Cela évite d’attribuer à l’application un problème qui vient en réalité de l’environnement Docker.

2.8 Ce qu’il faut retenir