Quiz hebdo · Semaine 2
conteneur, image, cycle de vie, journaux, ports, volumes
9 questions + 3 supplément
Cliquez Voir la solution sur chaque diapositive
Question 1 / 9 vue d'ensemble - drag & drop
8 commandes - 8 rôles. Glissez chaque commande sur sa description :
Le cycle de vie complet : pull télécharge le moule, run fabrique et lance une pièce, ps et logs observent, stop / start mettent en pause et relancent, rm jette la pièce. Le moule, lui, se liste avec images et se jette avec rmi (au supplément !).
Question 2 / 9 concept
Le conteneur est un processus isolé : espaces de noms pour qu'il ne voie que son petit monde, limites de ressources pour qu'il ne mange pas tout. Mais il réutilise le noyau de l'hôte : c'est ce qui le rend si léger et si rapide à démarrer, comparé à une machine virtuelle.
Question 3 / 9 concept
La machine virtuelle simule une machine entière, noyau compris : lourde à démarrer, gourmande en mémoire. Le conteneur voyage sans noyau : il emprunte celui de l'hôte. Résultat : des dizaines de conteneurs là où on logerait deux ou trois machines virtuelles.
Question 4 / 9 image vs conteneur
docker run, ça donne quoi ?L'image est le moule en lecture seule, le conteneur est la pièce qui en sort. Un moule, autant de pièces qu'on veut : docker ps montrera trois conteneurs nginx, chacun avec son nom aléatoire, tous nés de la même image. C'est exactement le principe qui permettra de multiplier les serveurs au module 2.
Question 5 / 9 diagnostic - à vous de taper
vitrine (image nginx). Ce matin, le site ne répond plus. Premier réflexe : observer avant de toucher.
NAME
docker ps - lister les conteneurs
SYNOPSIS
docker ps [OPTIONS]
OPTIONS
-a, --all
montrer aussi les conteneurs arrêtés
(par défaut : seulement ceux en marche)
COLONNES
CONTAINER ID, IMAGE, STATUS (Up 2 minutes,
Exited (1) 3 hours ago...), PORTS, NAMES
EXEMPLES
docker ps
docker ps -a
NAME
docker logs - afficher la sortie d'un conteneur
SYNOPSIS
docker logs [OPTIONS] CONTENEUR
OPTIONS
-f, --follow
suivre la sortie en temps réel (comme tail -f)
--tail NOMBRE
afficher seulement les dernières lignes
CE QUE VOIT logs
Tout ce que le processus principal du conteneur écrit
sur stdout et stderr depuis son démarrage.
EXEMPLES
docker logs vitrine
docker logs -f vitrine
# a) Le conteneur tourne-t-il ? -a montre aussi les morts docker ps -a # b) Qu'a-t-il dit avant de se taire ? docker logs vitrine
Dans la colonne STATUS de docker ps -a : Up 2 minutes veut dire vivant, Exited (1) 3 hours ago veut dire mort avec un code d'erreur. Ensuite docker logs raconte pourquoi. Observer d'abord, agir ensuite : le réflexe de tout le cours.
Question 6 / 9 docker run - à vous de taper
nginx : en arrière-plan, avec le nom vitrine, et le port 8080 de l'hôte branché sur le 80 du conteneur.
NAME
docker run - créer et lancer un conteneur à partir d'une image
SYNOPSIS
docker run [OPTIONS] IMAGE
OPTIONS
-d, --detach
en arrière-plan : rend la main au terminal
--name NOM
nommer le conteneur (sinon : nom aléatoire
du genre quirky_einstein)
-p PORT_HOTE:PORT_CONTENEUR
publier un port : les requêtes qui entrent par
PORT_HOTE sont redirigées vers PORT_CONTENEUR
NOTE
Si l'image n'est pas sur la machine, docker run la
télécharge d'abord depuis Docker Hub (pull automatique).
EXEMPLES
docker run -d --name vitrine -p 8080:80 nginx
docker run -d --name vitrine -p 8080:80 nginx
-d : en arrière-plan, le terminal reste à vous ;--name vitrine : fini les noms aléatoires, les commandes suivantes diront simplement vitrine ;-p 8080:80 : l'ordre est hôte:conteneur ;nginx : l'image, toujours en dernier.Bonus : si l'image nginx n'était pas sur la machine, docker run l'aurait téléchargée tout seul depuis Docker Hub avant de lancer. C'est le grand service qu'il rend par rapport au conteneur monté à la main de la semaine 1.
Question 7 / 9 redirection de ports
À quel port l'utilisateur de la machine hôte visite-t-il le site ?
L'ordre de -p est hôte:conteneur. La requête entre par le 8080 de l'hôte et Docker la redirige vers le 80 du conteneur, où nginx écoute. Le 80 du conteneur n'est pas visible directement de l'extérieur : c'est justement ça, l'isolation.
Question 8 / 9 l'adresse selon votre instance - drag & drop
docker run -p 8080:80 nginx a été lancé sur trois instances différentes. Glissez chaque adresse sur l'instance où elle est la bonne.
3 adresses - 3 instances :
La règle : l'adresse IP de la machine où Docker tourne, suivie du port externe choisi avec -p. localhost n'est vrai que si Docker tourne sur votre poste ; dans VirtualBox c'est l'adresse IP de la machine virtuelle, sur un VPS c'est son adresse publique (et le port doit être ouvert dans le pare-feu).
Question 9 / 9 volumes
docker rm. Que deviennent les données écrites dans son volume ?
Le volume est une malle rangée chez l'hôte : le conteneur peut mourir, la malle reste, et le prochain conteneur peut la reprendre. Sans volume, tout ce qui a été écrit dans le conteneur part avec lui. Règle d'or : le conteneur est jetable, les données ne le sont pas.
Supplément 1 / 3 nettoyage - à vous de taper
vitrine, le supprimer, puis supprimer l'image nginx pour libérer le disque.
NAME
docker stop - arrêter proprement un conteneur
DESCRIPTION
Envoie SIGTERM au processus principal (arrêt poli),
puis SIGKILL s'il ne s'est pas arrêté après 10 secondes.
Le conteneur arrêté existe toujours : visible avec
docker ps -a, relançable avec docker start.
docker rm CONTENEUR
supprime un conteneur arrêté (l'instance)
docker rmi IMAGE
supprime une image (le moule)
ERREUR si un conteneur, même arrêté, l'utilise encore :
il faut d'abord docker rm ce conteneur
# a) Arrêt poli : SIGTERM, puis SIGKILL après 10 s docker stop vitrine # b) Jeter la pièce docker rm vitrine # c) Jeter le moule docker rmi nginx
L'ordre est obligatoire : rmi refuse de supprimer une image tant qu'un conteneur, même arrêté, s'en sert encore. On jette les pièces avant de jeter le moule.
Supplément 2 / 3 vocabulaire - drag & drop
5 mots - 5 définitions :
Cinq mots qui reviendront toute la session : l'image (le moule), le conteneur (la pièce), le volume (la malle), Docker Hub (la bibliothèque) et les journaux (la boîte noire). Si vous savez raconter cette phrase à quelqu'un d'autre, la semaine 2 est gagnée.
Supplément 3 / 3 le scénario de la session
docker rm du conteneur compromis puis docker run d'un neuf. Pourquoi ça redonne un serveur sain ?
Le pirate a modifié la pièce, pas le moule : relancer depuis l'image redonne un serveur identique au premier jour, pendant que les données vivent en sécurité dans les volumes. La nuance qui compte : redéployer efface l'intrusion, pas la faille. Si on ne corrige pas ce qui a laissé entrer le pirate (extension à jour, bonnes permissions), il reviendra par la même porte.
Bilan
R pour recommencer.