Accéder aux conteneurs avec exec

Introduction

Dans ce laboratoire, vous apprendrez à entrer dans un conteneur Docker en cours d’exécution. Il s’agit d’une compétence essentielle pour le débogage : même si les conteneurs sont conçus pour être éphémères, vous devez souvent examiner un environnement actif pour comprendre ce qui s’y passe.

Pour examiner des fichiers, vérifier les processus en cours ou résoudre des problèmes à l’intérieur d’un conteneur, vous avez souvent besoin d’un shell de commande dans l’environnement de ce conteneur. La commande docker exec vous permet de démarrer une commande supplémentaire dans un conteneur déjà en cours d’exécution, sans le reconstruire ni le redémarrer.

Le mot « supplémentaire » est important. docker exec ne remplace pas le processus principal du conteneur. La commande démarre un autre processus dans les mêmes espaces de noms que le conteneur, tandis que le service d’origine continue de fonctionner.

Vous allez suivre les étapes suivantes :

Démarrer un conteneur Nginx en arrière-plan.
Utiliser docker exec pour démarrer un shell Bash interactif dans le conteneur.
Exécuter des commandes dans le conteneur pour identifier son système d’exploitation.
Quitter le conteneur et revenir au terminal de votre machine hôte.

Démarrer un conteneur en arrière-plan

Dans cette étape, vous allez démarrer un nouveau conteneur Docker à partir de l’image Nginx. Vous l’exécuterez en mode « détaché » afin qu’il fonctionne en arrière-plan, et vous lui attribuerez un nom précis pour pouvoir le référencer plus facilement par la suite.

Exécutez la commande suivante dans votre terminal :

docker run -d --name web1 nginx

Décomposition de la commande :

docker run : commande qui crée et démarre un conteneur.
-d : exécute le conteneur en mode détaché (en arrière-plan).
--name web1 : attribue le nom web1 au conteneur.
nginx : image à utiliser.

Vérifiez que le conteneur est en cours d’exécution :

docker ps

Vous devez voir web1 dans la liste des conteneurs actifs.

Le conteneur doit être en cours d’exécution, car docker exec fonctionne en entrant dans le contexte d’un conteneur existant et actif. Cette commande ne peut pas démarrer un shell dans un conteneur qui est déjà arrêté.

Entrer dans le conteneur

Maintenant que le conteneur est en cours d’exécution, vous allez utiliser la commande docker exec pour démarrer une session shell à l’intérieur. Cela revient à vous « connecter » au conteneur, comme lorsque vous vous connectez en SSH à un serveur distant.

Exécutez la commande suivante :

docker exec -it web1 bash

Décomposition de la commande :

docker exec : exécute une commande dans un conteneur existant.
-it : cette combinaison est indispensable pour les sessions interactives.
- -i (interactif) : maintient le flux d’entrée ouvert.
- -t (TTY) : alloue un pseudo-terminal qui se comporte comme une véritable invite de commande.
web1 : nom du conteneur cible.
bash : commande à exécuter dans le conteneur. Ici, elle démarre le shell Bash.

Ainsi, docker exec signifie essentiellement « exécuter cette commande dans le conteneur ». Un shell n’est qu’un cas d’utilisation courant ; la commande pourrait tout aussi bien être ls, cat ou un outil de débogage.

Observez le changement :

Après avoir exécuté cette commande, votre invite de commande change. Elle ressemble à ceci : root@<container-id>:/#.

Cela indique que vous exécutez maintenant des commandes à l’intérieur du conteneur, isolé de votre machine hôte.

Cette isolation comprend généralement la vue du système de fichiers, l’espace de noms des processus et le contexte réseau. Vous utilisez toujours le même noyau, mais vous observez désormais l’environnement limité du conteneur plutôt que l’environnement complet de la machine hôte.

Examiner l’environnement du conteneur

Vous êtes maintenant à l’intérieur du conteneur. Le système de fichiers que vous voyez appartient au conteneur, et non à votre environnement LabEx. Vous pouvez le vérifier en consultant les informations du système d’exploitation.

Exécutez la commande suivante dans le shell du conteneur :

cat /etc/os-release

La sortie décrit la distribution Linux utilisée par l’image Nginx, généralement Debian.

Exemple de sortie :

PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
...

Cela confirme que le conteneur possède son propre environnement de système d’exploitation isolé, distinct de celui de la machine hôte.

Plus précisément, il possède son propre système de fichiers de l’espace utilisateur et son propre environnement de processus. Il n’utilise pas un noyau distinct, mais il peut néanmoins donner l’impression, depuis l’intérieur, d’être un petit système Linux indépendant.

Quitter le conteneur et revenir à l’hôte

Lorsque vous avez terminé le débogage ou l’examen du conteneur, vous devez quitter la session shell pour revenir à votre machine hôte.

Saisissez la commande suivante dans le conteneur :

exit

Après avoir appuyé sur Entrée, votre invite de commande doit revenir à l’invite utilisateur standard de LabEx.

Que s’est-il passé ?

Vous avez fermé le processus Bash à l’intérieur du conteneur. Cependant, le conteneur lui-même (web1) continue de fonctionner en arrière-plan, car le processus principal (Nginx) est toujours actif.

Il s’agit de l’enseignement essentiel concernant le cycle de vie avec docker exec : la fermeture de votre shell interactif n’arrête pas le conteneur, sauf si ce shell était le processus principal qui définissait la durée de vie du conteneur.

Vous pouvez le confirmer en exécutant :

docker ps

web1 figure toujours dans la liste.

Pour nettoyer votre environnement, vous pouvez arrêter et supprimer le conteneur :

docker rm -f web1

Résumé

Dans ce laboratoire, vous avez appris à accéder à un conteneur en cours d’exécution avec docker exec -it. Vous avez pratiqué les opérations suivantes :

Démarrer un conteneur en arrière-plan.
Entrer dans le conteneur à l’aide d’un shell Bash interactif.
Vérifier l’environnement à l’intérieur du conteneur.
Quitter le conteneur en toute sécurité tout en laissant le service fonctionner.

Il s’agit d’une compétence fondamentale pour travailler avec Docker. Elle vous permet de résoudre les problèmes des applications et d’examiner directement les environnements des conteneurs.