diff --git a/slides/2-docker advanced.odp b/slides/2-docker advanced.odp
index 3cfb67a..b824726 100644
Binary files a/slides/2-docker advanced.odp and b/slides/2-docker advanced.odp differ
diff --git a/tutorial/2/Makefile b/tutorial/2/Makefile
index 1868738..f0f05f6 100644
--- a/tutorial/2/Makefile
+++ b/tutorial/2/Makefile
@@ -2,24 +2,28 @@ include ../pandoc-opts.mk
SOURCES = tutorial.md \
../docker-advanced/security.md \
- ../dockerfiles/what.md ../dockerfiles/interactive.md ../dockerfiles/dockerfile.md ../dockerfiles/goodpractices.md ../dockerfiles/others.md ../dockerfiles/entrypoint.md \
+ ../dockerfiles/what.md ../dockerfiles/interactive.md ../dockerfiles/dockerfile.md ../dockerfiles/dockerfile-ex.md ../dockerfiles/goodpractices.md ../dockerfiles/buildx.md ../dockerfiles/buildx-ex.md ../dockerfiles/others.md ../dockerfiles/entrypoint.md \
../docker-internals/vulnerability-scan.md ../docker-internals/clair-tiny.md ../docker-internals/vulnerability-scan-ex.md
-SOURCES_PROJECT = tutorial.md \
- ../docker-advanced/what.md ../docker-advanced/setup.md ../docker-advanced/manual.md ../new-page.md ../docker-advanced/compose.md \
- rendu.md
+SOURCES_TUTO = tutorial.md \
+ ../header-tp.md \
+ ../dockerfiles/dockerfile-ex.md ../dockerfiles/goodpractices.md ../dockerfiles/buildx.md ../dockerfiles/buildx-ex.md \
+ rendu.md
SOURCES_CLAIR = tutorial-clair.md \
../docker-internals/clair.md
-all: tutorial-2.pdf tutorial-2-clair.pdf
+all: 2-course.pdf 2-tutorial.pdf 2-tutorial-clair.pdf
-tutorial-2.pdf: ${SOURCES}
+2-course.pdf: ${SOURCES}
pandoc ${PANDOCOPTS} -o $@ $+
-tutorial-2-clair.pdf: ${SOURCES_CLAIR}
+2-tutorial.pdf: ${SOURCES_TUTO}
+ pandoc ${PANDOCOPTS} -o $@ $+
+
+2-tutorial-clair.pdf: ${SOURCES_CLAIR}
pandoc ${PANDOCOPTS} -o $@ $+
clean::
- rm tutorial-2.pdf
+ rm 2-course.pdf 2-tutorial.pdf 2-tutorial-clair.pdf
diff --git a/tutorial/2/image-inheritance.png b/tutorial/2/image-inheritance.png
new file mode 120000
index 0000000..615129b
--- /dev/null
+++ b/tutorial/2/image-inheritance.png
@@ -0,0 +1 @@
+../dockerfiles/image-inheritance.png
\ No newline at end of file
diff --git a/tutorial/2/rendu.md b/tutorial/2/rendu.md
index 46cf6dc..7c455f0 100644
--- a/tutorial/2/rendu.md
+++ b/tutorial/2/rendu.md
@@ -22,9 +22,9 @@ Voici une arborescence type (vous pourriez avoir des fichiers supplémentaires)
```
./
-./youp0m/ # 1.2.7 + 1.3
+./youp0m/
./youp0m/Dockerfile
-./youp0m/entrypoint.sh # 2.2.2
+./youp0m/entrypoint.sh
./youp0m/.dockerignore
./youp0m/...
./ctr-updater/
diff --git a/tutorial/docker-internals/vulnerability-scan.md b/tutorial/docker-internals/vulnerability-scan.md
index 425ae4d..f224578 100644
--- a/tutorial/docker-internals/vulnerability-scan.md
+++ b/tutorial/docker-internals/vulnerability-scan.md
@@ -48,7 +48,7 @@ que vous avez précédemment téléchargées. Pensez donc régulièrement à app
```
-42sh$ docker pull IMAGE
+42sh$ docker image pull IMAGE
```
@@ -233,8 +233,8 @@ analyses. Préférez lancer `trivy` avec les options suivantes :
```
-42sh$ docker run --rm -v /tmp/trivy-cache:/tmp/trivy/ aquasec/trivy \
- --cache-dir /tmp/trivy IMAGE
+42sh$ docker run --rm -v /tmp/trivy-cache:/root/.cache/ aquasec/trivy \
+ image IMAGE
```
diff --git a/tutorial/dockerfiles/buildx-ex.md b/tutorial/dockerfiles/buildx-ex.md
new file mode 100644
index 0000000..4f9e972
--- /dev/null
+++ b/tutorial/dockerfiles/buildx-ex.md
@@ -0,0 +1,7 @@
+::::: {.exercice}
+
+Faites en sorte que le `Dockerfile` que vous avez créé pour `youp0m` indique un
+*frontend* BuildKit à utiliser, tout en restant compatible avec la syntaxe du
+`docker build` classique.
+
+:::::
diff --git a/tutorial/dockerfiles/buildx.md b/tutorial/dockerfiles/buildx.md
new file mode 100644
index 0000000..0f6c35c
--- /dev/null
+++ b/tutorial/dockerfiles/buildx.md
@@ -0,0 +1,61 @@
+`buildx`
+--------
+
+Docker `buildx` est un plugin qui apporte
+[BuildKit](https://github.com/moby/buildkit). Tout en étant compatible avec la
+syntaxe des `Dockerfile` existant, BuildKit apporte une gestion concurrente des
+nœuds de construction : très utile lorsque l'on construit une image pour
+plusieurs architectures.
+
+
+### Installation Windows et MacOS {-}
+
+Avec Docker Desktop, le plugin est déjà installé, vous n'avez aucune action
+supplémentaire à effectuer, vous pouvez commencer à l'utiliser.
+
+### Installation Linux {-}
+
+En fonction de la méthode d'installation que vous avez suivie, vous avez
+peut-être déjà le plugin installé. Si vous n'avez pas d'erreur en exécutant
+`docker buildx`, mais que vous voyez l'aide de la commande, c'est bon. Sinon,
+vous pouvez l'installer comme ceci :
+
+
+```
+V="v0.9.1"
+mkdir -p ~/.docker/cli-plugins
+curl -L -s -S -o ~/.docker/cli-plugins/docker-buildx \
+ https://github.com/docker/buildx/releases/download/$V/buildx-$V.linux-amd64
+chmod +x ~/.docker/cli-plugins/docker-buildx
+```
+
+
+### Utilisation
+
+Nous pouvons réutiliser le `Dockerfile` que vous avez écrit pour `youp0m`, en
+remplaçant simplement la ligne de `docker build` par celle-ci :
+
+
+```
+docker buildx build .
+```
+
+
+::::: {.more}
+
+Nous ne rentrerons pas plus dans les détails de cette nouvelle commande, mais
+sachez qu'on la retrouve particulièrement fréquemment dans les *GitHub
+Actions* :\
+
+
+:::::
+
+### `docker/dockerfile:1.4`
+
+La version habituelle de la syntaxe des `Dockerfile` est la version 1.1. En
+utilisant BuildKit, nous pouvons dès à présent passer à la version 1.4.
+
+Il n'y a pas d'ajouts marquant pour nous à ce stade, c'est pourquoi nous ne
+détaillerons pas plus les nouveaux cas d'usage. Néanmoins, vous pouvez voir les
+ajouts par rapport à la syntaxe usuelle sur cette page :\
+.
diff --git a/tutorial/dockerfiles/dockerfile-ex.md b/tutorial/dockerfiles/dockerfile-ex.md
new file mode 100644
index 0000000..675d825
--- /dev/null
+++ b/tutorial/dockerfiles/dockerfile-ex.md
@@ -0,0 +1,50 @@
+::::: {.exercice}
+
+Pour mettre en application tout ce que nous venons de voir, réalisons le
+`Dockerfile` du service web [`youp0m`](https://you.p0m.fr/) que nous avons
+déjà utilisé précédemment.
+
+Pour réaliser ce genre de contribution, on ajoute généralement un `Dockerfile`
+à la racine du dépôt.
+
+Vous pouvez cloner le dépôt de sources de `youp0m` à :\
+
+
+Pour compiler le projet, vous pouvez utiliser dans votre `Dockerfile`
+des instructions similaires à cela :
+
+
+```dockerfile
+FROM golang:1.18
+COPY . /go/src/git.nemunai.re/youp0m
+WORKDIR /go/src/git.nemunai.re/youp0m
+RUN go build -tags dev -v
+```
+
+
+::::: {.question}
+
+#### Que faire des ressources statiques HTML/CSS/JS ? {-}
+
+L'exemple ci-dessus compile uniquement le code Go. À l'exécution, le
+binaire s'attendra à trouver un dossier `static/` dans le dossier
+courant. Ce dossier peut être changé en ajoutant l'option `-static
+NEWPATH` aux paramètres de lancement.
+
+:::::
+
+Remarquez la puissance de Docker : vous n'avez sans doute pas de compilateur Go
+installé sur votre machine, et pourtant, en quelques minutes et à partir du
+seul code source de l'application et d'un `Dockerfile`, vous avez pu compiler sur
+votre poste le binaire attendu. WOW, non ?
+
+À vous de compléter le `Dockerfile` afin de reproduire le comportement
+de l'image `registry.nemunai.re/youp0m` que nous avions utilisé :
+
+
+```
+docker container run -d -P youp0m
+```
+
+
+:::::
diff --git a/tutorial/dockerfiles/dockerfile.md b/tutorial/dockerfiles/dockerfile.md
index 1c03c42..f75d86e 100644
--- a/tutorial/dockerfiles/dockerfile.md
+++ b/tutorial/dockerfiles/dockerfile.md
@@ -462,34 +462,3 @@ Nous avons fait le tour des principales instructions et de leurs différents
usages *classiques*. Il existe quelques autres instructions que nous n'avons
pas présentées ici, pour aller plus loin, consultez la référence sur :\
-
-
-::::: {.exercice}
-
-Pour mettre en application tout ce que nous venons de voir, réalisons le
-`Dockerfile` du service web [`youp0m`](https://you.p0m.fr/) que nous avons
-déjà utilisé précédemment.
-
-Pour réaliser ce genre de contribution, on ajoute généralement un `Dockerfile`
-à la racine du dépôt.
-
-Vous pouvez cloner le dépôt de sources de `youp0m` à :\
-
-
-Pour compiler le projet, vous pouvez utiliser dans votre `Dockerfile`
-
-
-```dockerfile
-FROM golang:1.18
-COPY . /go/src/git.nemunai.re/youp0m
-WORKDIR /go/src/git.nemunai.re/youp0m
-RUN go build -tags dev -v
-```
-
-
-Remarquez la puissance de Docker : vous n'avez sans doute pas de compilateur Go
-installé sur votre machine, et pourtant, en quelques minutes et à partir du
-seul code source de l'application et d'un `Dockerfile`, vous avez pu compiler sur
-votre poste le binaire attendu. WOW, non ?
-
-:::::
diff --git a/tutorial/dockerfiles/entrypoint.md b/tutorial/dockerfiles/entrypoint.md
index 3e104cf..973505d 100644
--- a/tutorial/dockerfiles/entrypoint.md
+++ b/tutorial/dockerfiles/entrypoint.md
@@ -5,16 +5,16 @@ Le point d'entrée du conteneur
Le point d'entrée ou l'*entrypoint* correspond à la ligne de commande qui sera
exécutée au lancement du conteneur. Deux paramètres de notre `Dockerfile`
-permettent de changer cette ligne de commande : `CMD`{.dockerfile} et
+permettent d'agir sur cette ligne de commande : `CMD`{.dockerfile} et
`ENTRYPOINT`{.dockerfile}.
- **`CMD`{.dockerfile}** est la commande par défaut : lorsqu'au moment de
`run`, aucun paramètre n'est passé après le nom de l'image, le contenu du
dernier `CMD`{.dockerfile} rencontré sera utilisé.
-- `ENTRYPOINT`{.dockerfile}, s'il est défini, sera réellement exécuté, qu'il y
- ait ou non des arguments pour remplacer la ligne de commande. Lorsque des
- arguments sont passés ou qu'un `CMD`{.dockerfile}, ceux-ci sont passés en
+- **`ENTRYPOINT`{.dockerfile}**, s'il est défini, sera réellement exécuté,
+ qu'il y ait ou non des arguments pour remplacer la ligne de commande. Lorsque
+ des arguments sont passés ou qu'un `CMD`{.dockerfile}, ceux-ci sont passés en
argument de l'`ENTRYPOINT`{.dockerfile}.
Par exemple, avec le `Dockerfile` suivant, construisant l'image `sample-echo` :
diff --git a/tutorial/dockerfiles/goodpractices.md b/tutorial/dockerfiles/goodpractices.md
index 3efd6ff..616db0a 100644
--- a/tutorial/dockerfiles/goodpractices.md
+++ b/tutorial/dockerfiles/goodpractices.md
@@ -1,9 +1,13 @@
Les bonnes pratiques
--------------------
+::::: {.exercice}
+
Pour chaque bonne pratique ci-dessous, vérifiez que vous la respectez
bien, faites les modifications nécessaires dans votre `Dockerfile`.
+:::::
+
### Utilisez le fichier `.dockerignore`
Dans la plupart des cas, vos `Dockerfile` seront dans des dossiers contenant
diff --git a/tutorial/dockerfiles/others.md b/tutorial/dockerfiles/others.md
index 680e5f2..3924e7e 100644
--- a/tutorial/dockerfiles/others.md
+++ b/tutorial/dockerfiles/others.md
@@ -3,62 +3,10 @@ D'autres méthodes pour créer des images
Les images utilisées par Docker pour lancer les conteneurs répondent avant tout
aux spécifications OCI. Le format étant standard, il est normal que d'autres
-outils puissent utiliser, mais aussi créer des images. Nous allons voir dans
-cette partie l'avenir des `Dockerfile` ou simplement d'autres outils plus
-spécifiques.
-
-### `buildx`
-
-Docker `buildx` est un plugin qui apporte
-[BuildKit](https://github.com/moby/buildkit). Tout en étant compatible avec la
-syntaxe des `Dockerfile` existant, BuildKit apporte une gestion concurrente des
-nœuds de construction : très utile lorsque l'on construit une image pour
-plusieurs architectures.
+outils puissent utiliser, mais aussi créer des images.
-#### Installation Windows et MacOS {-}
-
-Avec Docker Desktop, le plugin est déjà installé, vous n'avez aucune action
-supplémentaire à effectuer, vous pouvez commencer à l'utiliser.
-
-#### Installation Linux {-}
-
-En fonction de la méthode d'installation que vous avez suivie, vous avez
-peut-être déjà le plugin installé. Si vous n'avez pas d'erreur en exécutant
-`docker buildx`, mais que vous voyez l'aide de la commande, c'est bon. Sinon,
-vous pouvez l'installer comme ceci :
-
-
-```
-V="v0.9.1"
-mkdir -p ~/.docker/cli-plugins
-curl -L -s -S -o ~/.docker/cli-plugins/docker-buildx \
- https://github.com/docker/buildx/releases/download/$V/buildx-$V.linux-amd64
-chmod +x ~/.docker/cli-plugins/docker-buildx
-```
-
-
-#### Utilisation
-
-Nous pouvons réutiliser le `Dockerfile` que vous avez écrit pour `youp0m`, en
-remplaçant simplement la ligne de `docker build` par celle-ci :
-
-
-```
-docker buildx build .
-```
-
-
-::::: {.more}
-
-Nous ne rentrerons pas plus dans les détails de cette nouvelle commande, mais
-sachez qu'on la retrouve particulièrement fréquemment dans les *GitHub
-Actions* :\
-
-
-:::::
-
-#### Changer la syntaxe de nos `Dockerfile`
+### Changer la syntaxe de nos `Dockerfile`
Parfois on peut se sentir un peu frustré par la syntaxe des `Dockerfile` ou par
son manque d'évolutivité. Avec BuildKit, il est possible de préciser un parseur
@@ -105,22 +53,6 @@ notamment :
`Dockerfile`, et autres scripts de CI et de tests.
-#### `docker/dockerfile:1.4`
-
-La version habituelle de la syntaxe des `Dockerfile` est la version 1.1. En
-utilisant BuildKit, nous pouvons dès à présent passer à la version 1.4.
-
-Les ajouts par rapport à la syntaxe usuelle sont répertoriés sur cette page :\
-.
-
-::::: {.exercice}
-
-Faites en sorte que le `Dockerfile` que vous avez créé pour `youp0m` indique un
-*frontend* BuildKit à utiliser, tout en restant compatible avec la syntaxe du
-`docker build` classique.
-
-:::::
-
### Des images sans Docker
Il est aussi possible de se passer complètement de Docker. La plupart des