3.1. Créer, démarrer et interagir avec des containers

Comme expliqué au chapitre précédent, un container est créé au départ d’une image.  Lors de la création du container, le système rajoute par dessus l’image une couche accessible en écriture et alloue des ressources systèmes dédiées au container, dans un environnement isolé.  Ensuite, le container est lancé sur base de la commande de démarrage renseignée dans l’image.  

Pour créer un container au départ d’une image, on utilise la commande docker run, en indiquant le nom de l’image (si cette image n’existe pas sur l’hôte, elle sera automatiquement téléchargée depuis le registre Docker Hub) : 

docker run <nom-image>

Mentionnons déjà deux paramètres intéressants pour cette commande : 

  • -d : Permet de lancer le container en mode daemon, ce qui permet de récupérer le prompt de la console après son démarrage. Ce paramètre est utile lorsqu’on lance un container de service, qui va tourner en arrière-plan et ne nécessitera pas d’interaction
  • –name : Permet d’assigner un nom personnalisé au container, pour l’identifier et le  référencer plus facilement par la suite.  

Si l’on souhaite interagir avec un container, pour vérifier ou débugger sa configuration, il est intéressant de le lancer alors sur base d’une autre commande que celle prévue par défaut, par exemple /bin/bash pour obtenir un shell sur le container. Dans ce cas, on ajoutera les options -i et -t pour pouvoir interagir avec le conteneur : 

docker run -it  --name mon-container <nom_image> /bin/bash

Pour consulter tous les containers actifs sur l’hôte, Docker propose la commande docker ps (alias docker container ls).  Cette commande vous donne un certain nombre d’informations précieuses, comme l’identifiant du container, son nom (soit généré automatiquement, soit spécifié par l’utilisateur), et des informations concernant les ports, réseaux, volumes associés au container.  L’option “-a” peut s’avérer utile pour étendre l’affichage aux containers arrêtés : cela permet parfois de retrouver la trace d’un container qui devrait tourner mais qui s’est crashé.  

Il est également possible de démarrer ou arrêter l’exécution d’un container déjà créé en utilisant les commandes docker start <nom/id> et docker stop <nom/id>

Si on souhaite ouvrir un shell sur un container démarré en arrière plan (mode daemon), on peut utiliser la commande suivante : 

docker exec -it <nom container> /bin/bash

Enfin, pour obtenir des informations au sujet d’un container, les commandes ‘docker (container) inspect <nom/id>’ et ‘docker logs <nom/id>’ sont des utilitaires indispensables.  Ils permettent de récupérer, pour le premier, toutes les informations systèmes liées à un container (dont par exemple l’adresse IP), et pour le second, tous les logs qui ont été générés par l’exécution de la commande de démarrage sur le stdout et le stderr du processus correspondant.

Illustration

Dans notre exemple, nous allons commencer par lancer un container nginx simple que nous appellerons “web”.  Le service web sera, sans surprise, à l’écoute sur son port 80.

Container à l'écoute sur le port web

Dans un premier temps, nous allons le lancer en arrière-plan, avec la commande suivante :

docker run -d --name web nginx

Cette commande va juste démarrer le container, qui va exécuter le serveur web, mais sans que ce dernier ne soit réellement accessible ou utilisable.  Nous verrons plus loin comment améliorer ça.

Création d'un container nginx

Le screencast ci-dessus montre l’exécution de la création du container avec l’application nginx.  On constate que l’image nginx n’était pas disponible localement : Docker s’est chargé de la télécharger, couche par couche, puis de démarrer le container.  

Après avoir exécuté la commande ‘docker ps’ (alias ‘docker container ls’), on constate que le container de nom web, basé sur l’image nginx, tourne et est à l’écoute sur son port 80.  Cependant, au stade actuel, ce port n’est pas joignable par des clients situés hors de l’hôte : le container tourne dans son environnement isolé. Seul l’hôte sera en mesure d’accéder au serveur web.