teach/virli
1
0
Fork 0
Code Issues Pull requests Releases Activity

Update tuto2

Browse source
This commit is contained in:
nemunaire 2021-09-23 02:55:18 +02:00
commit 2c5317f4f9
35 changed files with 3587 additions and 471 deletions
Download patch file Download diff file Expand all files Collapse all files

76
tutorial/dockerfiles/dockerfile.md
View file

@ -1,12 +1,12 @@
\newpage
Ma première image ... par `Dockerfile`
======================================
--------------------------------------
Pour construire une image, nous ne sommes pas obligés de passer par une série
de *commits*. Docker dispose d'un mécanisme permettant d'automatiser la
construction de nouvelles images. Nous pouvons arriver au même résultat que ce
que l'on a réussi à faire précédemment en utilisant le `Dockerfile` suivant :
que l'on a réussi à faire précédemment en utilisant le `Dockerfile` suivant :
<div lang="en-US">
```dockerfile
@ -17,7 +17,7 @@ RUN apt-get install -y nano
```
</div>
La syntaxe d'un `Dockerfile` est simple : le premier mot de chaque ligne est
La syntaxe d'un `Dockerfile` est simple : le premier mot de chaque ligne est
l'intitulé d'une instruction (que l'on écrit généralement en majuscule), elle
est suivie de ses arguments.
@ -27,7 +27,7 @@ le conteneur, dans le but de le construire.
Pour lancer la construction de la nouvelle image, créons un nouveau dossier ne
contenant que votre fichier `Dockerfile`, plaçons-nous ensuite dedans, puis
lançons la commande `build` :
lançons la commande `build` :
<div lang="en-US">
```bash
@ -36,7 +36,7 @@ docker image build --tag=my_editor .
</div>
Une fois la construction de l'image terminée, nous pouvons la lancer et
constater l'existence de notre éditeur favori :
constater l'existence de notre éditeur favori :
<div lang="en-US">
```bash
@ -46,13 +46,13 @@ docker container run -it my_editor /bin/bash
</div>
## `RUN` dans le `Dockerfile`
### `RUN` dans le `Dockerfile`
Dans un `Dockerfile`, chaque ligne est exécutée indépendamment des autres et
correspondra à une nouvelle couche de notre image. Exactement comme on a
réalisé le script dans la partie précédente.
Cela signifie que l'exemple suivant **ne fonctionne pas** :
Cela signifie que l'exemple suivant **ne fonctionne pas** :
<div lang="en-US">
```dockerfile
@ -63,11 +63,11 @@ RUN mysql -u root -p toor virli < /db.sql
</div>
Cet exemple ne fonctionne pas car le serveur MySQL est bien lancé dans le
premier `RUN`{.dockerfile}, mais il se trouve brûtalement arrêté dès lors que
premier `RUN`{.dockerfile}, mais il se trouve brutalement arrêté dès lors que
la commande `service` se termine. En fait, à chaque instruction, Docker réalise
automatiquement l'équivalent un `docker run` suivi d'un `commit`. Et vous
pouvez constater par vous-même que, en créant l'image `tinysql` à partir d'un
simple `apt install mysql` :
simple `apt install mysql` :
<div lang="en-US">
```bash
@ -78,7 +78,7 @@ docker container run tinysql service mysqld start
rend la main directement, sans laisser de `mysqld` dans l'arborescence de
processus.
Pour avoir le résultat escompté, il faut exécuter les commandes ensemble :
Pour avoir le résultat escompté, il faut exécuter les commandes ensemble :
<div lang="en-US">
```dockerfile
@ -95,9 +95,9 @@ run`. Seul la commande fournie par l'utilisateur ou la commande par défaut de
l'image sera exécutée au lancement d'un conteneur.
## Exposer des ports
### Exposer des ports
Construisons maintenant un conteneur avec un service web :
Construisons maintenant un conteneur avec un service web :
<div lang="en-US">
```dockerfile
@ -114,10 +114,10 @@ L'instruction `EXPOSE`{.dockerfile} sera traitée plus tard par le client Docker
(équivalent à l'argument `--expose`). Il s'agit d'une métadonnée qui sera
attachée à l'image (et à toutes ses images filles).
En précisant tous les ports qu'exposent une image dans ses métadonnées, ces
ports seront automatiquement exposés en utilisant l'option `-P` du `run` : cela
En précisant tous les ports qu'expose une image dans ses métadonnées, ces
ports seront automatiquement exposés en utilisant l'option `-P` du `run` : cela
assigne une redirection de port aléatoire sur la machine hôte vers votre
conteneur :
conteneur :
<div lang="en-US">
```
@ -132,13 +132,15 @@ Dans un autre terminal, lancer un `docker container ls` et consulter la colonne
Rendez-vous ensuite dans votre navigateur sur <http://localhost:49153/>.
**À vous de jouer :** utilisez l'instruction `COPY`{.dockerfile} pour afficher votre propre
#### À vous de jouer {-}
Utilisez l'instruction `COPY`{.dockerfile} pour afficher votre propre
`index.html` remplaçant celui installé de base par `nginx`. Si vous manquez
d'inspiration, utilisez [cette page de compte à
rebours](https://virli.nemunai.re/countdown.html).
## Les caches
### Les caches
Nous avons vu que chaque instruction de notre `Dockerfile` est exécutée dans un
conteneur, qui génère une image intermédiaire. Cette image intermédiaire sert
@ -164,19 +166,19 @@ Les couches du cache peuvent être partagées entre plusieurs conteneur, c'est
ainsi que vous pouvez partager facilement une plus grosse partie du système de
fichiers (rappelez-vous le principe d'union FS).
Pour profiter du cache, on va placer de préférences les étapes les plus
Pour profiter du cache, on va placer de préférence les étapes les plus
génériques (qui seraient les plus susceptibles d'apparaître dans d'autres
images), en haut du `Dockerfile`.
## Métadonnées pures
### Métadonnées pures
L'instruction `LABEL`{.dockerfile} permet d'ajouter une métadonnée à une image,
sous forme de clef/valeur.
Une métadonnée
[courante](https://github.com/nginxinc/docker-nginx/blob/master/mainline/stretch/Dockerfile#L3)
est d'indiquer le nom du mainteneur de l'image :
est d'indiquer le nom du mainteneur de l'image :
<div lang="en-US">
```dockerfile
@ -194,10 +196,10 @@ On le place dès le début, car comme c'est une information qui n'est pas amener
à changer, elle sera toujours retrouvée en cache.
## Commande par défaut
### Commande par défaut
Vous pouvez placer dans un `Dockerfile` une instruction `CMD`{.dockerfile} qui
sera exécutée si aucune commande n'est passée lors du `run`, par exemple :
sera exécutée si aucune commande n'est passée lors du `run`, par exemple :
<div lang="en-US">
```dockerfile
@ -218,7 +220,7 @@ retirez cette option pour voir ce qui ne va pas, ou utilisez la commande
`docker container logs`.
## Construire son application au moment de la construction du conteneur ?
### Construire son application au moment de la construction du conteneur ?
Comment faire lorsque l'on a besoin de compiler une application avant de
l'intégrer dans le conteneur ?
@ -230,14 +232,14 @@ versions de ces outils existent, laquelle choisir ? ... Ok c'est trop
compliqué.
D'un autre côté, si l'on fait cela dans un conteneur, celui-ci contiendra dans
ses couches des données inutiles à l'exécution : les sources, les produits
ses couches des données inutiles à l'exécution : les sources, les produits
intermédiaires de compilation, le compilateur, n'ont rien à faire dans les
couches de notre image.
Le meilleur des deux mondes se trouve dans les *Multi-stage builds* : au sein
Le meilleur des deux mondes se trouve dans les *Multi-stage builds* : au sein
du même `Dockerfile`, on va réaliser les opérations de préparation dans un ou
plusieurs conteneurs, avant d'agréger le contenu compilé au sein du conteneur
final :
final :
<div lang="en-US">
```dockerfile
@ -252,7 +254,7 @@ CMD ["/hello"]
```
</div>
Dans cet exemple, deux conteneurs distincts sont créés : le premier à partir de
Dans cet exemple, deux conteneurs distincts sont créés : le premier à partir de
l'image `gcc`, il contient tout le nécessaire pour compiler notre
`hello.c`. Mais l'image finale (le dernier `FROM`{.dockerfile} de notre
`Dockerfile`) est l'image vide, dans laquelle nous recopions simplement le
@ -261,12 +263,12 @@ produit de notre compilation.
L'image ainsi générée est minime, car elle ne contient rien d'autre que le
strict nécessaire pour s'exécuter.
### Étapes nommées
#### Étapes nommées\
Nous avons utilisé `--from=0` pour désigner la première image de notre
`Dockerfile`. Lorsque l'on réalise des montages plus complexe, on peut vouloir
`Dockerfile`. Lorsque l'on réalise des montages plus complexes, on peut vouloir
donner des noms à chaque image, plutôt que de devoir jongler avec les
numéros. Dans ce cas, on indiquera :
numéros. Dans ce cas, on indiquera :
<div lang="en-US">
```dockerfile
@ -281,9 +283,9 @@ CMD ["/hello"]
```
</div>
Par défaut la dernière étape du `Dockerfile` est retenu comme étant l'image que
Par défaut la dernière étape du `Dockerfile` est retenue comme étant l'image que
l'on souhaite `tagger`, mais il est possible de préciser quelle image
spécifiquement on souhaite construire avec l'option `--target` :
spécifiquement on souhaite construire avec l'option `--target` :
<div lang="en-US">
```
@ -297,13 +299,13 @@ sélectionnera ainsi avec l'option `--target` l'un ou l'autre en fonction de
l'environnement dans lequel on souhaite se déployer.
## D'autres instructions ?
### D'autres instructions ?
Consultez <https://docs.docker.com/engine/reference/builder/> pour la liste
complète des instructions reconnues.
## Exercice {-}
### 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
@ -312,14 +314,14 @@ utilisé la semaine dernière.
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ôts de sources de `youp0m` à :
<https://gitea.nemunai.re/nemunaire/youp0m.git>
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.13
FROM golang:1.16
COPY . /go/src/git.nemunai.re/youp0m
WORKDIR /go/src/git.nemunai.re/youp0m
RUN go build -tags dev -v