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