diff --git a/tutorial/1/Makefile b/tutorial/1/Makefile
index 657c127..8228e9b 100644
--- a/tutorial/1/Makefile
+++ b/tutorial/1/Makefile
@@ -6,6 +6,8 @@ SOURCES = tutorial.md \
../docker-basis/volumes.md \
../docker-basis/ex-flask-volume.md \
../docker-basis/linking.md \
+ ../docker-basis/ex-flask-s3.md \
+ ../docker-basis/debug.md \
SOURCES_COURSE = tutorial.md \
../containers/overview.md \
diff --git a/tutorial/docker-basis/cleaning.md b/tutorial/docker-basis/cleaning.md
index 0372bbe..9026067 100644
--- a/tutorial/docker-basis/cleaning.md
+++ b/tutorial/docker-basis/cleaning.md
@@ -44,13 +44,21 @@ docker container rm cranky_jones dreamy_gates
-### Images
+### Images et autres objets
-Les vieilles images qui n'ont plus de références sur elle (ni tag, ni conteneur
-lié) sont automatiquement supprimées. Vous n'avez généralement pas à vous
-occuper de faire du nettoyage dans les images. Néanmoins, vous pouvez les gérer
-de la même manière que les conteneurs, avec les sous-commandes `docker image`.
+De la même manière que pour les conteneurs, nous pouvons lister tous les autres
+objets avec la sous-commande `ls` :
+
+```bash
+docker image ls
+docker volume ls
+docker [object] ls
+```
+
+
+Et les supprimer avec la sous-commande `rm` suivie du nom ou de l'identifiant
+de l'objet (pour les images, il faut aussi préciser le tag en plus du nom).
### `prune`
diff --git a/tutorial/docker-basis/debug.md b/tutorial/docker-basis/debug.md
new file mode 100644
index 0000000..9ea7d11
--- /dev/null
+++ b/tutorial/docker-basis/debug.md
@@ -0,0 +1,81 @@
+\newpage
+
+Intervenir durant l'exécution
+=============================
+
+Lorsque nous lançons un conteneur, il arrive que son comportement nous
+échappe : une imprécision dans la documentation, un cas particulier, une erreur
+de configuration, ... Lorsque le conteneur est en cours d'exécution, il y a
+plusieurs manières de contrôler ce qu'il se passe.
+
+
+docker logs
+-----------
+
+La première étape consiste bien souvent à regarder ce que le conteneur affiche
+sur ses sorties standard et d'erreur. Lorsqu'il est lancé en monde *daemon*, il
+convient d'utiliser la commande :
+
+
+```bash
+docker container logs 0a1b2c3d4e
+```
+
+
+Cela affichera l'intégralité des journaux depuis la création du conteneur.
+
+En ajoutant l'option `--follow` lorsque le conteneur est actif, cela laissera
+la commande active `logs` pour afficher en direct les nouvelles lignes
+inscrites sur les sorties du conteneur.
+
+
+Entrer dans un conteneur en cours d'exécution
+---------------------------------------------
+
+Dans certaines circonstances, les journaux ne sont pas suffisants pour déboguer
+correctement l'exécution d'un conteneur.
+
+En réalisant les exercices, vous serez sans doute confronté à des comportements
+étranges, que vous ne pourriez comprendre qu'en ayant la main sur le conteneur,
+à travers un shell.
+
+Lorsqu'un conteneur est actif, vous pouvez y lancer un nouveau processus,
+notamment un shell par exemple :
+
+
+```bash
+docker container exec -it mycloud /bin/bash
+(inctnr)# hostname
+0a1b2c3d4e5f
+(inctnr)# ping mysql_cntr_name
+...
+```
+
+
+On peut aussi imaginer lancer régulièrement une commande par ce biais : pour
+déclencher une sauvegarde d'un conteneur serveur de base de données ou pour
+exécuter une tâche périodique.
+
+::::: {.question}
+
+Il n'est pas possible d'`exec` dans un conteneur éteint. Aussi, si la commande
+initiale du conteneur se termine, tous les `exec` seront instantanément tués.
+
+:::::
+
+
+docker top
+----------
+
+Si plusieurs processus doivent s'exécuter dans un conteneur, un bon moyen de
+savoir s'ils sont tous actifs est d'utiliser :
+
+
+```bash
+docker container top cntr_name
+```
+
+
+Cela liste tous les processus rattaché au conteneur nommé : à la fois les
+processus démarrés par le `run`, mais également les éventuels processus
+rattachés par `exec`.
diff --git a/tutorial/docker-basis/ex-flask.md b/tutorial/docker-basis/ex-flask.md
index 1ad9b13..6333dbc 100644
--- a/tutorial/docker-basis/ex-flask.md
+++ b/tutorial/docker-basis/ex-flask.md
@@ -77,16 +77,22 @@ docker container run -d -p 8080:8080 registry.nemunai.re/youp0m
```
+::::: {.question}
+
+#### Où est la sortie standard ? {-}
+
À partir de l'identifiant renvoyé par cette commande (que l'on peut également
obtenir avec un `docker container ls`), nous pouvons consulter les logs du
service (en fait, les sorties standard et d'erreur) :
```bash
-docker container logs 0123456789abcdef
+docker container logs 0a1b2c3d4e
```
+:::::
+
### Une autre instance ?
diff --git a/tutorial/docker-basis/first.md b/tutorial/docker-basis/first.md
index d4eb722..8b5a4d6 100644
--- a/tutorial/docker-basis/first.md
+++ b/tutorial/docker-basis/first.md
@@ -217,6 +217,8 @@ docker image ls
```
+Nous utiliserons plus tard les autres objets dont Docker dispose.
+
### *Image ID*, nom, tag
@@ -282,8 +284,8 @@ transféré dans le conteneur.
Pour nous en convaincre, nous pouvons tenter d'exécuter un programme qui n'est
pas présent sur notre machine, mais bien uniquement dans le conteneur. Si vous
-n'utilisez pas [Alpine Linux](https://www.alpinelinux.org), vous pourriez
-tenter d'utiliser son gestionnaire de paquet `apk`, via :
+n'utilisez pas [Alpine Linux](https://www.alpinelinux.org) comme distribution
+hôte, vous pourriez tenter d'utiliser son gestionnaire de paquet `apk`, via :
```bash
@@ -291,6 +293,9 @@ docker container run alpine /sbin/apk stats
```
+Vous n'avez a priori pas le binaire `/sbin/apk` sur votre système. C'est bien
+celui du conteneur qui a été exécuté.
+
### Programme par défaut
@@ -422,11 +427,27 @@ CONTAINER ID IMAGE COMMAND CREATED STATUS NAMES
```
+::::: {.question}
+
+#### Avez-vous remarqué que le `CONTAINER ID` correspond au nom d'hôte du conteneur ? {-}
+
+À la création du conteneur, Docker génère un identifiant unique qu'il attribue
+au conteneur. Au passage, les premiers chiffres sont utilisés pour définir le
+nom d'hôte du conteneur.
+
+:::::
+
+Chaque ligne représente un conteneur en cours d'exécution. Pour toutes les
+commandes qui permettent d'interagir avec un conteneur, il est possible
+d'utiliser indifféremment l'identifiant du conteneur (long ou court) ou bien le
+nom qu'il lui a été attribué (soit automatiquement par Docker, dans ce cas le
+nom ressemblera à un adjectif suivi du nom d'une personnalité de l'informatique
+connue, soit par vous, via l'option `--name` du `run`).
### Sortir d'un conteneur
Pour mettre fin à l'exécution d'un conteneur, il convient de terminer le
-premier processus lancé dans celui-ci.
+premier processus lancé dans celui-ci (le processus au PID 1).
Si vous faites face à une invite de commande, le classique `exit` ou `^D`
mettra fin au *shell*, qui était le premier processus lancé de notre conteneur,
diff --git a/tutorial/docker-basis/volumes.md b/tutorial/docker-basis/volumes.md
index 9e09ca5..bd7f7e2 100644
--- a/tutorial/docker-basis/volumes.md
+++ b/tutorial/docker-basis/volumes.md
@@ -3,29 +3,25 @@
Stockage de données applicatives
================================
-Le concept principal de Docker est de concevoir des conteneurs applicatifs : on
-va préférer assigner un unique rôle à un conteneur (donc généralement on ne va
-lancer qu'une seule application par conteneur) et concevoir un service complet
-en créant un groupe de conteneurs, partageant des données entre eux par des
-volumes.
+Il est généralement toujours possible d'écrire dans le système de fichier de
+notre conteneur. (Cela n'affecte pas l'image, chaque conteneur est démarré à
+partir de l'image originale.) Cependant, il n'est pas recommandé de chercher à
+stocker des données ainsi. En effet, il n'est pas aisé de récupérer ces données
+une fois l'exécution du conteneur terminée ; les données peuvent même être
+détruite si on a lancé le conteneur avec l'option `--rm`.
-Il est possible d'utiliser la dernière couche en lecture/écriture pour inscrire
-des données. Il n'est cependant pas recommandé de stocker des données de cette
-manière, car elles ne vont pas persister une fois que le conteneur aura terminé
-son exécution ; elles seront alors plus compliquées à retrouver manuellement.
-
-Docker met à notre disposition plusieurs mécanismes pour que les données de nos
-applications persistent et soient prêtes à migrer plus facilement vers une
-solution plus apte à la décentralisation.
+Docker met donc à notre disposition plusieurs mécanismes pour que les données
+de nos applications persistent et soient prêtes à être migrées d'un conteneur à
+l'autre.
## Partage avec la machine hôte
-Il est possible de monter un répertoire de la machine hôte dans un
+Il est possible de partager un répertoire de la machine hôte avec un
conteneur. L'intérêt reste plutôt limité à des fins de facilité ou de test, par
-exemple si vous voulez partager des fichiers avec votre voisin, en passant par
-le protocole HTTP, mais sans se casser la tête à installer et configurer un
-serveur web :
+exemple si vous voulez partager des fichiers en passant par le protocole HTTP,
+mais sans se casser la tête à installer et configurer un serveur web, vous
+pourriez utiliser :
```bash
@@ -33,14 +29,17 @@ docker run --rm -p 80:80 -v ~/Downloads:/usr/share/nginx/html:ro -d nginx
```
-Une fois cette commande lancée, votre voisin pourra accéder à votre dossier
-Downloads en renseignant l'IP de votre machine dans son navigateur favori !
+Une fois le conteneur lancé, vous pourrez accéder à votre dossier *Downloads*
+en renseignant l'IP de votre machine dans un navigateur !
+
+::::: {.warning}
Par défaut, `nginx` ne va pas permettre de lister le contenu du répertoire (et
va afficher une page 404, car il cherche un fichier `index.html` dans votre
répertoire). Vous pouvez par contre accéder à un fichier directement, par
exemple :
+:::::
## Les volumes
@@ -77,9 +76,12 @@ docker container run --name mydb -e MYSQL_ROOT_PASSWORD=my-secret-pw \
```
-Lorsque le volume est vide, si des données sont présentes à l'endroit du point
-de montage, celles-ci sont recopiées dans le volume.
+::::: {.question}
+Lorsque le volume est vide, si des données sont présentes dans l'image à
+l'endroit du point de montage, celles-ci sont recopiées dans le volume.
+
+:::::
## Volumes temporaires