i've had enough

content/06_docker_basics.md

@@ -179,3 +179,120 @@ Démarrez le container `zorglub` avec la commande `start -ia` (_attach_ + _inter
 
 - Le fichier `/ex03/fantasio` existe-t-il toujours ?
     - Oui, le fichier existe toujours.
+
+## Exercice 3
+
+Exécutez un container basé sur l'image Alpine 3.17 en spécifiant de le détruire
+une fois terminé.
+
+```bash
+docker run -it --rm alpine:3.17
+```
+
+Vérifiez que vous utilisez la bonne distribution en inspectant le contenu du
+fichier `/etc/os-release`.
+
+```bash
+cat /etc/os-release
+```
+
+```bash
+NAME="Alpine Linux"
+ID=alpine
+VERSION_ID=3.17.7
+PRETTY_NAME="Alpine Linux v3.17"
+HOME_URL="https://alpinelinux.org/"
+BUG_REPORT_URL="https://gitlab.alpinelinux.org/alpine/aports/-/issues"
+```
+
+Dans ce container, exécutez la commande `top`. Inspéctez ensuite le processus
+`top` à l'intérieur du container et sur la machine hôte (via `ps aux`).
+
+- Selon votre observation, est-ce qu'un processus appartenant à `root` dans le
+container appartient également à root en dehors du container ?
+    - Cela dépend si le daemon `dockerd` s'exécute en tant que `root` ou non.
+    S'il l'est, alors le processus `root` dans le container le sera aussi en
+    dehors. (_weird ngl, gotta verify that_).
+    - Non, ce processus n'appartient pas à `root` en dehors du container.
+
+Pour rappel, `root` possède le **UID** 0.
+
+- Pourquoi est-il dangereux qu'un processus UID 0 dans le container soit également
+UID 0 sur la machine hôte ?
+    - Cela impliquerait que ce processus aurait tous les droits sur la machine hôte.
+
+- Quelle différence remarquez-vous lorsque vous exécutez la commande `ps aux`
+dans le container et sur la machine hôte ?
+    - En ce qui concerne le container, on ne voit que les processus `/bin/sh`
+    et `ps aux` s'exécuter à l'inverse de la machine hôte où un nombre bien plus
+    conséquent de processus s'exécutent.
+
+- À votre avis, quelle est la raison de cette différence ?
+    - J'imagine que le processus du container est complètement isolé de son
+    environnement "parent" pour des mesures de sécurité d'où le fait qu'on n'ait
+    pas accès aux processus s'exécutant sur la machine hôte.
+
+À l'intérieur du container, terminez `top`, puis installez et exécutez le programme
+`asciiquarium`. Pour info, Alpine utilise le _package manager_ `apk`. Les
+équivalents Alpine de `apt-get update` et `apt-get install` sont `apk update`
+et `apk add`. Vous pouvez lister tous les paquets disponibles avec `apk list`.
+
+- Quel est le PID de ce processus dans le container ? Quel est le PID de ce même
+processus sur la machine hôte et pourquoi est-il différent à votre avis ?
+    - Dans le container, le PID du processus est 22. Du côté de la mâchine hôte,
+    le PID est 16125. Je suppose que la raison pour laquelle ces deux valeurs
+    sont différentes est que le container exécute un OS à part entière d'où le
+    fait que de son point de vue, il est le seul _responsable_ de ce processus.
+    (_prolly bs_).
+
+Vous allez maintenant investiguer empiriquement le comportement des containers.
+
+- Quel est le processus portant le PID 1 dans le container ? Quel est le processus
+portant le même numéro de PID sur la machine hôte ?
+    - Dans le container, c'est le processus `/bin/sh` qui porte le PID 1 (cela
+    est facilement visualisable grâce à `top`). Dans le cas de la machine hôte,
+    en exécutant la commande `pstree -p | head`, on s'aperçoit que le PID 1
+    correspond au processus `systemd`.
+
+- Pour généraliser, quel est le processus portant le PID 1 dans le container
+(c-à-d, quel que soit le container exécuté) ? Vous pouvez déduire empiriquement
+en exécutant d'autres containers avec des programmes différents.
+    - En ayant essayé avec l'image `isrkhn/pandoc`, je m'aperçois que le processus
+    portant le PID 1 dans le container est `/bin/sh` (ou le shell de base).
+
+Comparé le résultat de la commande `uname -rv` dans le container et sur la
+machine hôte.
+
+- Que remarquez-vous et que pouvez-vous en conclure ?
+    - Dans le cas deux cas, le résultat de cette commande est `5.15.0-105-generic #115-Ubuntu SMP Mon Apr 15 09:52:04 UTC 2024`.
+    On peut en conclure que le container est "conscient" de l'OS parent et que
+    celui-ci sera le même pour lui (_maybe ?_).
+
+Similairement à ci-dessus, comparez le contenu du répertoire `/dev/`.
+
+- Que remarquez-vous ? À votre avis, quelle est la raison de cette différence ?
+    - Dans le cas du container la liste est très petite comparé à la machine hôte.
+    Une des choses manquantes en particulier sont les partitions de disque (p.ex.:
+    `/dev/sda`, `/dev/sdb`). La raison de cette différence est que le container
+    n'est "qu'un processus" par rapport à l'OS complète s'exécutant sur la
+    machine hôte.
+
+- Est-il possible de donner à un container accès à un ou plusieurs périphériques
+de la machine hôte ? Comment ? Trouvez un moyen permettant de vérifier votre méthode.
+    - Oui, il est possible de donner accès au container à un périphérique de
+    la machine hôte à l'aide du paramètre `device`. Ci-dessous vous pouvez voir
+    un exemple où on met à disposition du container, le device `/dev/sda` de
+    la machine hôte. On retrouve par la suite ce device, lorsqu'on inspecte
+    le retour de `ls -ltr /dev` dans le container.
+    ```bash
+    docker run --device=/dev/sda:/dev/host-sda -it --rm alpine:3.17
+    ```
+
+    ```bash
+    brw-rw----    1 root     disk        8,   0 Apr 20 16:10 host-sda
+    ```
+
+Exécutez la commande `mount` sur la machine hôte et dans le container.
+
+- Quelles différences remarquez-vous, notamment en ce qui concerne le système
+de fichiers racine (`rootfs`) ?