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 \
|
||||
../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
|
||||
|
|
|
|||
|
|
@ -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">
|
||||
```
|
||||
./
|
||||
./youp0m/ # 1.2.7 + 1.3
|
||||
./youp0m/
|
||||
./youp0m/Dockerfile
|
||||
./youp0m/entrypoint.sh # 2.2.2
|
||||
./youp0m/entrypoint.sh
|
||||
./youp0m/.dockerignore
|
||||
./youp0m/...
|
||||
./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">
|
||||
```
|
||||
42sh$ docker pull IMAGE
|
||||
42sh$ docker image pull IMAGE
|
||||
```
|
||||
</div>
|
||||
|
||||
|
|
@ -233,8 +233,8 @@ analyses. Préférez lancer `trivy` avec les options suivantes :
|
|||
|
||||
<div lang="en-US">
|
||||
```
|
||||
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
|
||||
```
|
||||
</div>
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
:::::
|
||||
|
|
@ -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>.
|
||||
|
|
@ -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
|
||||
pas présentées ici, pour aller plus loin, consultez la référence sur :\
|
||||
<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
|
||||
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` :
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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 :
|
||||
|
||||
<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`
|
||||
### 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 :\
|
||||
<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
|
||||
|
||||
Il est aussi possible de se passer complètement de Docker. La plupart des
|
||||
|
|
|
|||
Loading…
Reference in New Issue