Improve and update docker-basis

tutorial/docker-basis/first.md

@@ -62,6 +62,7 @@ principaux registres :
 
 - <https://hub.docker.com/>
 - <https://quay.io/>
+- <https://ghcr.io/> (GitHub Container Registry)
 
 ::::: {.warning}
 
@@ -155,7 +156,7 @@ registre tiers :
 
 <div lang="en-US">
 ```bash
-docker container un registry.nemunai.ie/hello-world
+docker container run registry.nemunai.re/hello-world
 ```
 </div>
 
@@ -164,9 +165,9 @@ nécessaire de récupérer l'image. Elle est ensuite exécutée. Vous devriez do
 obtenir un résultat en deux parties, similaire à la sortie suivante :
 
 <div lang="en-US">
-```bash
+```
 Unable to find image 'registry.nemunai.re/hello-world:latest' locally
-latest: Pulling from library/hello-world
+latest: Pulling from hello-world
 2db29710123e: Already exists
 Digest: sha256:7d246653d0511db2a6b2e0436cfd0e52ac8c066000264b3ce63331ac66dca625
 Status: Downloaded newer image for registry.nemunai.re/hello-world:latest

tutorial/docker-basis/installation.md

@@ -80,6 +80,12 @@ car la licence est gratuite pour un usage éducatif ou personnel.
 Notez que cela ne concerne pas le projet ou le binaire Docker : ceux-ci restent
 libres. Seules les applications Docker Desktop sont concernées.
 
+Si vous souhaitez des alternatives libres, vous pouvez considérer :
+
+- **Rancher Desktop** : <https://rancherdesktop.io/>
+- **Podman Desktop** : <https://podman-desktop.io/>
+- **Colima** (macOS uniquement) : <https://github.com/abiosoft/colima>
+
 :::::
 
 [^DockerSubscription]: <https://www.docker.com/blog/updating-product-subscriptions/>
@@ -175,4 +181,12 @@ Cette action n'est pas anodine d'un point de vue de la sécurité :
 
 <https://docs.docker.com/engine/security/#docker-daemon-attack-surface>
 
+Les membres du groupe `docker` peuvent obtenir les privilèges root sur la
+machine. Pour un environnement plus sécurisé, considérez :
+
+- **Docker en mode rootless** : permet d'exécuter le daemon Docker sans
+  privilèges root
+- **Podman** : alternative à Docker fonctionnant sans daemon et sans privilèges
+  root par défaut
+
 :::::

tutorial/docker-basis/linking.md

@@ -88,3 +88,21 @@ docker network connect NETWORK CONTAINER
 Lorsque plusieurs conteneurs ont rejoint un réseau utilisateur, ils peuvent
 mutuellement se découvrir grâce à un système de résolution de nom basé sur leur
 nom de conteneur.
+
+::::: {.question}
+
+#### Et l'option `--link` ? {-}
+
+Vous trouverez peut-être dans d'anciens tutoriels l'utilisation de l'option
+`--link` pour connecter des conteneurs. Cette option est **dépréciée** depuis
+Docker 1.13 et ne devrait plus être utilisée.
+
+Les réseaux utilisateurs (`user-defined bridge networks`) sont la méthode
+recommandée pour faire communiquer des conteneurs, car ils offrent :
+
+- Une meilleure isolation réseau
+- La découverte automatique des noms (DNS intégré)
+- La possibilité de connecter/déconnecter dynamiquement des conteneurs
+- Plus de flexibilité et de sécurité
+
+:::::

tutorial/docker-basis/secrets.md

@@ -3,4 +3,113 @@
 Garder des secrets
 ==================
 
-TODO
+Lorsque nous déployons des applications conteneurisées, celles-ci ont souvent
+besoin d'informations sensibles : mots de passe de base de données, clefs API,
+certificats, tokens d'authentification, etc. La gestion de ces secrets est
+cruciale pour la sécurité de nos applications.
+
+
+## Ce qu'il ne faut pas faire
+
+Avant de voir les bonnes pratiques, commençons par les erreurs courantes à
+éviter absolument :
+
+::::: {.warning}
+
+**Ne jamais inclure de secrets dans une image Docker !**
+
+Lorsque vous construisez une image avec un `Dockerfile`, tout ce qui est copié
+dans l'image y reste, même si vous le supprimez dans une couche ultérieure. Les
+images peuvent être inspectées, et les secrets peuvent être extraits de
+l'historique des couches.
+
+:::::
+
+::::: {.warning}
+
+**Ne jamais passer de secrets via la ligne de commande !**
+
+Les arguments de la ligne de commande sont visibles via `ps`, `docker inspect`,
+et sont souvent enregistrés dans l'historique du shell.
+
+<div lang="en-US">
+```bash
+# MAUVAIS EXEMPLE - À NE PAS FAIRE
+docker container run -e DB_PASSWORD=monmotdepasse myapp
+```
+</div>
+
+:::::
+
+
+## Variables d'environnement avec fichiers
+
+Pour éviter que les secrets n'apparaissent dans l'historique de commandes ou
+dans les processus, Docker permet de charger les variables d'environnement
+depuis un fichier :
+
+<div lang="en-US">
+```bash
+docker container run --env-file secrets.env myapp
+```
+</div>
+
+Le fichier `secrets.env` contiendrait :
+
+<div lang="en-US">
+```
+DB_PASSWORD=monmotdepasse
+API_KEY=ma_clef_secrete
+```
+</div>
+
+::::: {.warning}
+
+Pensez à ajouter ce fichier dans votre `.gitignore` ou `.dockerignore` pour éviter qu'il se retrouve accidentellement dans la nature !
+
+:::::
+
+
+## Montage de fichiers secrets
+
+Une approche plus sécurisée consiste à monter les secrets comme fichiers en
+lecture seule dans le conteneur :
+
+<div lang="en-US">
+```bash
+docker container run \
+  --mount type=bind,source=$HOME/.secrets/db_password,target=/run/secrets/db_password,readonly \
+  myapp
+```
+</div>
+
+L'application peut ensuite lire le secret depuis `/run/secrets/db_password`.
+Cette approche présente plusieurs avantages :
+
+- Les secrets ne sont pas visibles via `docker inspect`
+- Les secrets peuvent avoir des permissions restrictives sur l'hôte
+- Les applications peuvent être conçues pour lire les secrets depuis des
+  fichiers, ce qui est compatible avec les systèmes d'orchestration
+
+
+## Docker Secrets (Docker Swarm)
+
+Docker propose un système de gestion de secrets natif, mais celui-ci n'est
+disponible qu'en mode Swarm.
+
+<div lang="en-US">
+```bash
+# Création d'un secret (nécessite Swarm mode)
+echo "monmotdepasse" | docker secret create db_password -
+
+# Utilisation dans un service
+docker service create --secret db_password myapp
+```
+</div>
+
+Dans ce mode, les secrets sont :
+
+- Chiffrés pendant le transit et au repos
+- Montés dans `/run/secrets/` sous forme de fichiers temporaires en RAM
+- Distribués uniquement aux conteneurs qui en ont besoin
+- Gérés de manière centralisée

tutorial/docker-basis/volumes.md

@@ -41,6 +41,31 @@ exemple : <http://10.42.12.23/dQw4w9WgXcQ.mp4>
 
 :::::
 
+::::: {.question}
+
+Pour activer le listing de répertoires avec nginx, il faudrait créer un fichier
+de configuration personnalisé avec la directive `autoindex on;` et le monter
+dans le conteneur via un volume supplémentaire.
+
+:::::
+
+::::: {.question}
+
+#### Syntaxes `-v` et `--mount` {-}
+
+Vous remarquerez dans cette partie l'utilisation de deux syntaxes différentes
+pour monter des volumes :
+
+- **`-v` ou `--volume`** : syntaxe courte et concise
+  (ex: `-v ~/Downloads:/usr/share/nginx/html:ro`)
+- **`--mount`** : syntaxe explicite avec des paires clé-valeur
+  (ex: `--mount type=bind,source=...,target=...,readonly`)
+
+La syntaxe `--mount` est recommandée pour sa clarté, mais `-v` reste très
+utilisée car plus courte. Les deux sont équivalentes en fonctionnalité.
+
+:::::
+
 ## Les volumes
 
 Les volumes sont des espaces créés via Docker (il s'agit d'objets Docker). Ils

tutorial/docker-basis/what.md

@@ -67,13 +67,13 @@ défaut.
 ### Les plugins Docker
 
 L'architecture de Docker est devenue très modulable. Le projet est parti dans
-de nombreuses directions, chacun voulant tirer la couverture vers soit, et
+de nombreuses directions, chacun voulant tirer la couverture vers soi, et
 l'équipe maintenant le projet a parfois eu du mal à arbitrer les bonnes choses
 à ajouter ou non au projet.
 
-Afin de palier aux besoins complémentaires, parfois accessoires, parfois
+Afin de pallier aux besoins complémentaires, parfois accessoires, parfois
 salvateurs, un système de plugins a été intégré. Il permet d'appeler d'autres
-programmes comme s'il s'agissait de composant de Docker.
+programmes comme s'il s'agissait de composants de Docker.
 
 Certains plugins ajoutent des options à la ligne de commande (`docker-compose`,
 `docker-scan`, `docker-buildx` ...). D'autres ajoutent des typologies de