Tuto 2 done
This commit is contained in:
parent
3601652dd3
commit
14870bd330
Binary file not shown.
@ -2,24 +2,28 @@ include ../pandoc-opts.mk
|
|||||||
|
|
||||||
SOURCES = tutorial.md \
|
SOURCES = tutorial.md \
|
||||||
../docker-advanced/security.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
|
../docker-internals/vulnerability-scan.md ../docker-internals/clair-tiny.md ../docker-internals/vulnerability-scan-ex.md
|
||||||
|
|
||||||
SOURCES_PROJECT = tutorial.md \
|
SOURCES_TUTO = tutorial.md \
|
||||||
../docker-advanced/what.md ../docker-advanced/setup.md ../docker-advanced/manual.md ../new-page.md ../docker-advanced/compose.md \
|
../header-tp.md \
|
||||||
|
../dockerfiles/dockerfile-ex.md ../dockerfiles/goodpractices.md ../dockerfiles/buildx.md ../dockerfiles/buildx-ex.md \
|
||||||
rendu.md
|
rendu.md
|
||||||
|
|
||||||
SOURCES_CLAIR = tutorial-clair.md \
|
SOURCES_CLAIR = tutorial-clair.md \
|
||||||
../docker-internals/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 $@ $+
|
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 $@ $+
|
pandoc ${PANDOCOPTS} -o $@ $+
|
||||||
|
|
||||||
clean::
|
clean::
|
||||||
rm tutorial-2.pdf
|
rm 2-course.pdf 2-tutorial.pdf 2-tutorial-clair.pdf
|
||||||
|
1
tutorial/2/image-inheritance.png
Symbolic link
1
tutorial/2/image-inheritance.png
Symbolic link
@ -0,0 +1 @@
|
|||||||
|
../dockerfiles/image-inheritance.png
|
@ -22,9 +22,9 @@ Voici une arborescence type (vous pourriez avoir des fichiers supplémentaires)
|
|||||||
<div lang="en-US">
|
<div lang="en-US">
|
||||||
```
|
```
|
||||||
./
|
./
|
||||||
./youp0m/ # 1.2.7 + 1.3
|
./youp0m/
|
||||||
./youp0m/Dockerfile
|
./youp0m/Dockerfile
|
||||||
./youp0m/entrypoint.sh # 2.2.2
|
./youp0m/entrypoint.sh
|
||||||
./youp0m/.dockerignore
|
./youp0m/.dockerignore
|
||||||
./youp0m/...
|
./youp0m/...
|
||||||
./ctr-updater/
|
./ctr-updater/
|
||||||
|
@ -48,7 +48,7 @@ que vous avez précédemment téléchargées. Pensez donc régulièrement à app
|
|||||||
|
|
||||||
<div lang="en-US">
|
<div lang="en-US">
|
||||||
```
|
```
|
||||||
42sh$ docker pull IMAGE
|
42sh$ docker image pull IMAGE
|
||||||
```
|
```
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
@ -233,8 +233,8 @@ analyses. Préférez lancer `trivy` avec les options suivantes :
|
|||||||
|
|
||||||
<div lang="en-US">
|
<div lang="en-US">
|
||||||
```
|
```
|
||||||
42sh$ docker run --rm -v /tmp/trivy-cache:/tmp/trivy/ aquasec/trivy \
|
42sh$ docker run --rm -v /tmp/trivy-cache:/root/.cache/ aquasec/trivy \
|
||||||
--cache-dir /tmp/trivy IMAGE
|
image IMAGE
|
||||||
```
|
```
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
|
7
tutorial/dockerfiles/buildx-ex.md
Normal file
7
tutorial/dockerfiles/buildx-ex.md
Normal file
@ -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.
|
||||||
|
|
||||||
|
:::::
|
61
tutorial/dockerfiles/buildx.md
Normal file
61
tutorial/dockerfiles/buildx.md
Normal file
@ -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 :
|
||||||
|
|
||||||
|
<div lang="en-US">
|
||||||
|
```
|
||||||
|
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
|
||||||
|
```
|
||||||
|
</div>
|
||||||
|
|
||||||
|
### 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 :
|
||||||
|
|
||||||
|
<div lang="en-US">
|
||||||
|
```
|
||||||
|
docker buildx build .
|
||||||
|
```
|
||||||
|
</div>
|
||||||
|
|
||||||
|
::::: {.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* :\
|
||||||
|
<https://github.com/marketplace/actions/docker-setup-buildx>
|
||||||
|
|
||||||
|
:::::
|
||||||
|
|
||||||
|
### `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 :\
|
||||||
|
<https://hub.docker.com/r/docker/dockerfile>.
|
50
tutorial/dockerfiles/dockerfile-ex.md
Normal file
50
tutorial/dockerfiles/dockerfile-ex.md
Normal file
@ -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` à :\
|
||||||
|
<https://git.nemunai.re/nemunaire/youp0m.git>
|
||||||
|
|
||||||
|
Pour compiler le projet, vous pouvez utiliser dans votre `Dockerfile`
|
||||||
|
des instructions similaires à cela :
|
||||||
|
|
||||||
|
<div lang="en-US">
|
||||||
|
```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
|
||||||
|
```
|
||||||
|
</div>
|
||||||
|
|
||||||
|
::::: {.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é :
|
||||||
|
|
||||||
|
<div lang="en-US">
|
||||||
|
```
|
||||||
|
docker container run -d -P youp0m
|
||||||
|
```
|
||||||
|
</div>
|
||||||
|
|
||||||
|
:::::
|
@ -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
|
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 :\
|
pas présentées ici, pour aller plus loin, consultez la référence sur :\
|
||||||
<https://docs.docker.com/engine/reference/builder/>
|
<https://docs.docker.com/engine/reference/builder/>
|
||||||
|
|
||||||
|
|
||||||
::::: {.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` à :\
|
|
||||||
<https://git.nemunai.re/nemunaire/youp0m.git>
|
|
||||||
|
|
||||||
Pour compiler le projet, vous pouvez utiliser dans votre `Dockerfile`
|
|
||||||
|
|
||||||
<div lang="en-US">
|
|
||||||
```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
|
|
||||||
```
|
|
||||||
</div>
|
|
||||||
|
|
||||||
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 ?
|
|
||||||
|
|
||||||
:::::
|
|
||||||
|
@ -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
|
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`
|
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}.
|
`ENTRYPOINT`{.dockerfile}.
|
||||||
|
|
||||||
- **`CMD`{.dockerfile}** est la commande par défaut : lorsqu'au moment de
|
- **`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
|
`run`, aucun paramètre n'est passé après le nom de l'image, le contenu du
|
||||||
dernier `CMD`{.dockerfile} rencontré sera utilisé.
|
dernier `CMD`{.dockerfile} rencontré sera utilisé.
|
||||||
|
|
||||||
- `ENTRYPOINT`{.dockerfile}, s'il est défini, sera réellement exécuté, qu'il y
|
- **`ENTRYPOINT`{.dockerfile}**, s'il est défini, sera réellement exécuté,
|
||||||
ait ou non des arguments pour remplacer la ligne de commande. Lorsque des
|
qu'il y ait ou non des arguments pour remplacer la ligne de commande. Lorsque
|
||||||
arguments sont passés ou qu'un `CMD`{.dockerfile}, ceux-ci sont passés en
|
des arguments sont passés ou qu'un `CMD`{.dockerfile}, ceux-ci sont passés en
|
||||||
argument de l'`ENTRYPOINT`{.dockerfile}.
|
argument de l'`ENTRYPOINT`{.dockerfile}.
|
||||||
|
|
||||||
Par exemple, avec le `Dockerfile` suivant, construisant l'image `sample-echo` :
|
Par exemple, avec le `Dockerfile` suivant, construisant l'image `sample-echo` :
|
||||||
|
@ -1,9 +1,13 @@
|
|||||||
Les bonnes pratiques
|
Les bonnes pratiques
|
||||||
--------------------
|
--------------------
|
||||||
|
|
||||||
|
::::: {.exercice}
|
||||||
|
|
||||||
Pour chaque bonne pratique ci-dessous, vérifiez que vous la respectez
|
Pour chaque bonne pratique ci-dessous, vérifiez que vous la respectez
|
||||||
bien, faites les modifications nécessaires dans votre `Dockerfile`.
|
bien, faites les modifications nécessaires dans votre `Dockerfile`.
|
||||||
|
|
||||||
|
:::::
|
||||||
|
|
||||||
### Utilisez le fichier `.dockerignore`
|
### Utilisez le fichier `.dockerignore`
|
||||||
|
|
||||||
Dans la plupart des cas, vos `Dockerfile` seront dans des dossiers contenant
|
Dans la plupart des cas, vos `Dockerfile` seront dans des dossiers contenant
|
||||||
|
@ -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
|
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
|
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
|
outils puissent utiliser, mais aussi créer des images.
|
||||||
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.
|
|
||||||
|
|
||||||
|
|
||||||
#### Installation Windows et MacOS {-}
|
### Changer la syntaxe de nos `Dockerfile`
|
||||||
|
|
||||||
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 :
|
|
||||||
|
|
||||||
<div lang="en-US">
|
|
||||||
```
|
|
||||||
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
|
|
||||||
```
|
|
||||||
</div>
|
|
||||||
|
|
||||||
#### 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 :
|
|
||||||
|
|
||||||
<div lang="en-US">
|
|
||||||
```
|
|
||||||
docker buildx build .
|
|
||||||
```
|
|
||||||
</div>
|
|
||||||
|
|
||||||
::::: {.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* :\
|
|
||||||
<https://github.com/marketplace/actions/docker-setup-buildx>
|
|
||||||
|
|
||||||
:::::
|
|
||||||
|
|
||||||
#### Changer la syntaxe de nos `Dockerfile`
|
|
||||||
|
|
||||||
Parfois on peut se sentir un peu frustré par la syntaxe des `Dockerfile` ou par
|
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
|
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.
|
`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 :\
|
|
||||||
<https://hub.docker.com/r/docker/dockerfile>.
|
|
||||||
|
|
||||||
::::: {.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
|
### Des images sans Docker
|
||||||
|
|
||||||
Il est aussi possible de se passer complètement de Docker. La plupart des
|
Il est aussi possible de se passer complètement de Docker. La plupart des
|
||||||
|
Loading…
Reference in New Issue
Block a user