8. Clients Docker

8.1 Pourquoi plusieurs clients Docker ?

Pour piloter Docker, l’utilisateur passe par un client. Ce client transmet des demandes au moteur Docker et présente les réponses reçues.

Une même opération peut être exprimée de plusieurs façons :

• Une commande dans un terminal.
• Une action dans une interface graphique.
• Un appel de méthode dans un programme.

Ces façons de travailler répondent à des besoins différents :

• Observer l’état d’une application.
• Comprendre un problème de fonctionnement.
• Administrer des ressources.
• Automatiser des décisions répétitives.

Les trois solutions que nous allons étudier

Pour piloter Docker, nous pouvons choisir des outils adaptés à notre façon de travailler.

1. Docker Desktop associe une interface graphique à un environnement Docker intégré pour le poste de développement.
2. Portainer fournit une interface web pour administrer des environnements conteneurisés.
3. Le SDK Docker pour Python permet à un programme de communiquer avec le moteur.

8.2 Client, API et daemon : retrouver la frontière

Du client à l’exécution du conteneur

Pour récapituler :

1. Un client formule des demandes.
2. Le daemon Docker les reçoit par son API, gère les objets et coordonne leur exécution.
3. Le conteneur tourne sur la machine du moteur ciblé, même si le client est lancé ailleurs.

Comprendre les différences d’affichage entre clients

Plusieurs clients peuvent observer les mêmes objets s’ils se connectent au même daemon.

Des listes différentes peuvent s’expliquer par plusieurs causes :

• Les clients ciblent des moteurs différents.
• Les filtres affichés diffèrent.
• Les autorisations limitent la vue de certains comptes.

Identifier le moteur ciblé et les ressources concernées

1. Comprendre une demande et sa réponse

L’API est le contrat de communication entre le client et le moteur.

→ Elle définit les opérations accessibles et la structure des informations échangées.

Pour afficher des conteneurs, le client réalise plusieurs étapes :

• Il demande une liste au moteur.
• Il reçoit des données structurées.
• Il choisit la façon de les présenter.

→ Les deux présentations peuvent donc provenir de la même réponse du moteur.

• La CLI peut produire un tableau dans le terminal.
• Une interface graphique peut afficher des cartes ou des lignes interactives.

2. Bind mount : le dossier source se trouve sur l’hôte Docker

Un bind mount utilise un dossier de l’hôte qui exécute le moteur Docker.

Prenons un serveur Docker sur lequel le dossier /srv/site contient les fichiers d’un site web.

Depuis son poste, un utilisateur ouvre une session SSH sur ce serveur :

ssh utilisateur@serveur-docker

Dans cette session SSH, il saisit la commande suivante pour démarrer un conteneur NGINX avec ce dossier monté en lecture seule :

docker run -d --name site-web \
  --mount type=bind,src=/srv/site,dst=/usr/share/nginx/html,readonly \
  nginx

→ /srv/site désigne donc le dossier du serveur Docker. Son contenu est accessible dans le conteneur à l’emplacement /usr/share/nginx/html. Le montage ne transfère aucun fichier du poste utilisateur.

8.3 Docker Desktop : un environnement de développement intégré

Docker Desktop associe une interface graphique à un environnement Docker destiné au poste de développement.

Desktop convient à un poste où l’on développe et observe des applications conteneurisées.

Il regroupe notamment :

• Des outils de ligne de commande.
• Docker Compose.
• Un moteur Docker intégré.

Il existe sur plusieurs systèmes :

• Windows.
• macOS.
• Linux.

Il ne se réduit pas à une fenêtre posée sur n’importe quel Engine déjà installé.

Ce que l’interface rend visible

L’interface permet d’explorer les objets Docker :

• Les images.
• Les conteneurs.
• Les volumes.

Elle donne aussi accès à des informations sur le fonctionnement :

• Les journaux.
• Les paramètres d’exécution.

Une image disponible n’est pas encore un conteneur actif.

Un volume peut exister après la disparition d’un conteneur.

Où s’exécutent les conteneurs Linux ?

Pour les conteneurs Linux, Docker Desktop utilise un environnement Linux virtualisé.

• Sous Windows, WSL 2 est un backend courant.
• Sous macOS, une machine virtuelle Linux fournit le noyau nécessaire.
• Docker Desktop pour Linux utilise lui aussi une VM.

Cette frontière influence plusieurs aspects du fonctionnement :

• Les chemins de fichiers.
• Les ressources allouées.
• Les échanges de fichiers avec le poste.

Sur un poste Linux, Docker Engine installé directement sur l’hôte et le moteur de Docker Desktop peuvent coexister comme des environnements distincts. → Une image présente dans l’un n’apparaît pas automatiquement dans l’autre. → Le contexte actif de la CLI devient alors un repère essentiel.

Deux moteurs, deux listes de conteneurs

Voici deux sorties fictives pour un poste Linux où Docker Engine et Docker Desktop coexistent. La même commande docker ps liste les conteneurs en cours d’exécution du moteur sélectionné ; l’option --context rend ici cette cible explicite.

Docker Engine installé directement sur le poste Linux

$ docker --context default ps
CONTAINER ID   IMAGE          COMMAND                  CREATED         STATUS         PORTS                  NAMES
8f2c7a9d103b   nginx:alpine   "/docker-entrypoint.…"   2 hours ago     Up 2 hours     0.0.0.0:8080->80/tcp   site-engine

Moteur de Docker Desktop, dans son environnement Linux virtualisé

$ docker --context desktop-linux ps
CONTAINER ID   IMAGE          COMMAND                  CREATED         STATUS         PORTS                  NAMES
4d6e1b8a209c   nginx:alpine   "/docker-entrypoint.…"   30 minutes ago  Up 30 minutes  0.0.0.0:8081->80/tcp   site-desktop

→ site-engine et site-desktop appartiennent ici à deux moteurs distincts. Changer de contexte change le moteur interrogé, sans déplacer les conteneurs.

PowerShell 7.6.6
PS C:\Windows\System32> wsl --list --verbose
  NAME              STATE           VERSION
* Ubuntu            Running         2
  docker-desktop    Running         2

PowerShell 7.6.6
PS C:\Windows\System32> docker context show
desktop-linux

PS C:\Windows\System32> docker ps
CONTAINER ID   IMAGE          COMMAND                  CREATED          STATUS          PORTS                  NAMES
4d6e1b8a209c   nginx:alpine   "/docker-entrypoint.…"   30 minutes ago   Up 30 minutes   0.0.0.0:8081->80/tcp   site-desktop

8.4 Portainer : administrer depuis une interface web

Portainer est une application d’administration accessible dans un navigateur. Portainer Community Edition peut être exécuté dans un conteneur. Le navigateur communique avec Portainer Server ; celui-ci rejoint les environnements administrés par une connexion configurée, directement ou par un agent selon l’architecture retenue.

Observer et agir

Portainer donne une vue des objets Docker.

Selon les droits et les fonctions disponibles, il permet de gérer :

• Les conteneurs.
• Les images.
• Les réseaux.
• Les volumes.
• Les applications décrites en stacks.

Il facilite l’exploration et l’administration visuelle.

La compréhension des objets Docker reste nécessaire pour interpréter les actions proposées par l’interface.

8.5 Le SDK Python : piloter Docker depuis un programme

Le SDK Docker pour Python fournit des objets et des méthodes qui traduisent les intentions du programme en appels à l’API Docker. Il convient à une logique conditionnelle, à un inventaire ou à l’intégration dans un outil interne. Il n’exécute pas lui-même les conteneurs.

Lire un exemple d’inventaire

Cet extrait illustre la relation entre le programme et le moteur.

import docker

client = docker.from_env()
try:
    for conteneur in client.containers.list():
        print(conteneur.name, conteneur.status)
finally:
    client.close()

• docker.from_env() construit un client à partir des paramètres d’environnement et des mécanismes de sélection pris en charge par la version du SDK.
• containers.list() demande les conteneurs actifs ; l’option all=True élargit la liste aux conteneurs arrêtés.
• Les noms et états proviennent du moteur rejoint. Un programme lancé localement peut donc inventorier un moteur distant.
• close() libère les connexions du client ; il n’arrête pas les conteneurs.

8.6 Choisir le bon outil

Ces outils peuvent se compléter dans une même organisation :

• La configuration versionnée décrit l’application.
• Une interface aide à observer son état.
• Un programme peut produire un inventaire.

Une modification manuelle d’un objet géré par Compose peut créer un écart avec la configuration enregistrée.

La reproductibilité suppose que les changements souhaités soient conservés dans la référence du déploiement.

8.7 Scénario de lecture : une application, plusieurs vues

Une application WordPress s’appuie sur NGINX en entrée et sur MariaDB pour ses données.

Son fichier Compose décrit les services et leurs relations.

Le moteur transforme cette description en ressources exécutables.

1. Observer le même déploiement

• La CLI affiche les conteneurs du moteur ciblé.
• Portainer présente ces mêmes ressources dans une interface web lorsqu’il rejoint ce moteur.
• Le SDK Python peut lire leurs attributs pour produire un inventaire.

Le fait que trois clients les observent ne crée pas trois applications.

2. Comprendre une divergence de vue

Portainer montre trois conteneurs alors que la CLI n’en montre aucun.

Cette différence ne signifie pas immédiatement qu’une interface est défaillante.

• La CLI peut cibler un autre moteur.
• L’interface peut être filtrée sur un projet ou un état.
• Le compte connecté peut ne voir qu’un sous-ensemble de ressources.

L’identification du moteur précède donc l’interprétation de la liste affichée.

3. Comprendre une action partagée

Si Portainer arrête le conteneur WordPress, une CLI connectée au même moteur voit ensuite ce conteneur arrêté.

L’action touche la ressource commune, pas une représentation privée réservée à Portainer.

Si le fichier Compose conserve une configuration différente de celle appliquée manuellement, le prochain déploiement peut rétablir l’intention enregistrée dans ce fichier.

8.8 Ce qu’il faut retenir

• Un client demande ; le moteur ciblé crée et exécute les objets.
• Docker Desktop est un environnement intégré ; Portainer est une console web d’administration ; le SDK Python est une bibliothèque de programmation.
• Deux interfaces ne montrent les mêmes objets que si elles rejoignent le même moteur et appliquent une vue comparable.
• Le SDK ne fournit pas automatiquement une automatisation idempotente.
• Les droits du socket ou de l’API restent déterminants quel que soit le client.

Questions de mémorisation

• Un conteneur demandé par un client distant s’exécute où ?
• Pourquoi sauvegarder Portainer ne suffit-il pas pour sauvegarder MariaDB ?
• Une interface graphique rend-elle l’API moins privilégiée ?

8.9 Documentation de référence

• Docker Desktop
• Docker Desktop pour Linux
• Portainer : gestion des environnements Docker
• Portainer CE sur Docker Linux
• SDK Python : client
• SDK Python : conteneurs