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

tutorials: improve theme + use pandoc 2

Browse source
This commit is contained in:
nemunaire 2018-11-16 02:38:41 +01:00
parent de21be218a
commit d25af4fdb2
65 changed files with 1281 additions and 1292 deletions
Download patch file Download diff file Expand all files Collapse all files

155
tutorial/dockerfiles/dockerfile.md
View file

@ -9,11 +9,11 @@ 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 :
<div lang="en-US">
```
FROM ubuntu:latest
```dockerfile
FROM ubuntu:latest
RUN apt-get update
RUN apt-get install -y nano
RUN apt-get update
RUN apt-get install -y nano
```
</div>
@ -21,17 +21,17 @@ 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.
Dans notre exemple, nous utilisons `FROM` qui indique une image de départ à
utiliser ; `RUN` est une commande qui sera exécutée dans le conteneur, dans le
but de le construire.
Dans notre exemple, nous utilisons `FROM`{.dockerfile} qui indique une image de
départ à utiliser ; `RUN`{.dockerfile} est une commande qui sera exécutée dans
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` :
<div lang="en-US">
```
docker image build --tag=my_editor .
```bash
docker image build --tag=my_editor .
```
</div>
@ -39,8 +39,8 @@ Une fois la construction de l'image terminée, nous pouvons la lancer et
constater l'existence de notre éditeur favori :
<div lang="en-US">
```
docker container run -it my_editor /bin/bash
```bash
docker container run -it my_editor /bin/bash
```
</div>
@ -53,23 +53,23 @@ correspondra à une nouvelle couche de notre image.
Cela signifie que l'exemple suivant **ne fonctionne pas** :
<div lang="en-US">
```
COPY db.sql /db.sql
RUN service mysqld start
RUN mysql -u root -p toor virli < /db.sql
```dockerfile
COPY db.sql /db.sql
RUN service mysqld start
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`, mais il se trouve brûtalement arrêté dès lors que la commande
`service` se termine. En fait, à chaque instruction, Docker réalise
premier `RUN`{.dockerfile}, mais il se trouve brûtalement arrêté dès lors que
la commande `service` se termine. En fait, à chaque instruction, Docker réalise
automatiquement un `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` :
<div lang="en-US">
```
docker container run tinysql service mysqld start
```bash
docker container run tinysql service mysqld start
```
</div>
@ -79,16 +79,16 @@ processus.
Pour avoir le résultat escompté, il faut exécuter les commandes ensemble :
<div lang="en-US">
```
COPY db.sql /db.sql
RUN service mysqld start && mysql -u root -p toor virli < /db.sql
```dockerfile
COPY db.sql /db.sql
RUN service mysqld start && mysql -u root -p toor virli < /db.sql
```
</div>
Après le `RUN`, MySQL sera de nouveau tué.
Après le `RUN`{.dockerfile}, MySQL sera de nouveau tué.
En aucun cas, une commande exécutée par un `RUN` se retrouvera en cours
d'exécution lorsque l'on invoquera un conteneur par `docker container
En aucun cas, une commande exécutée par un `RUN`{.dockerfile} se retrouvera en
cours d'exécution lorsque l'on invoquera un conteneur par `docker container
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.
@ -98,17 +98,17 @@ l'image sera exécutée au lancement d'un conteneur.
Construisons maintenant un conteneur avec un service web :
<div lang="en-US">
```
FROM my_editor
```dockerfile
FROM my_editor
RUN apt-get update
RUN apt-get install -y nginx
RUN apt-get update
RUN apt-get install -y nginx
EXPOSE 80
EXPOSE 80
```
</div>
L'instruction `EXPOSE` sera traitée plus tard par le client Docker (équivalent
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).
@ -119,9 +119,9 @@ conteneur :
<div lang="en-US">
```
42sh$ docker image build --tag=my_webserver .
42sh$ docker container run -it -P my_webserver /bin/bash
(cntnr)# service nginx start
42sh$ docker image build --tag=my_webserver .
42sh$ docker container run -it -P my_webserver /bin/bash
(cntnr)# service nginx start
```
</div>
@ -130,7 +130,7 @@ 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` 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).
@ -169,22 +169,22 @@ images), en haut du `Dockerfile`.
## Métadonnées pures
L'instruction LABEL permet d'ajouter une métadonnée à une image, sous forme de
clef/valeur.
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 :
<div lang="en-US">
```
LABEL maintainer="Pierre-Olivier Mercier <nemunaire@nemunai.re>"
```dockerfile
LABEL maintainer="Pierre-Olivier Mercier <nemunaire@nemunai.re>"
```
</div>
Dans notre `Dockerfile`, indiquez juste après l'image de base, vos noms,
prénoms et mails de contact avec l'instruction `LABEL maintainer`, pour
indiquer que c'est vous qui maintenez cette image, si des utilisateurs ont
prénoms et mails de contact avec l'instruction `LABEL maintainer`{.dockerfile},
pour indiquer que c'est vous qui maintenez cette image, si des utilisateurs ont
besoin de vous avertir pour le mettre à jour ou s'ils rencontrent des
difficultés par exemple.
@ -194,19 +194,19 @@ On le place dès le début, car comme c'est une information qui n'est pas amener
## Commande par défaut
Vous pouvez placer dans un `Dockerfile` une instruction `CMD` qui sera exécutée
si aucune commande n'est passée lors du `run`, par exemple :
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 :
<div lang="en-US">
```
CMD nginx -g "daemon off;"
```dockerfile
CMD nginx -g "daemon off;"
```
</div>
<div lang="en-US">
```
42sh$ docker image build --tag=my_nginx .
42sh$ docker container run -d -P my_nginx
```bash
42sh$ docker image build --tag=my_nginx .
42sh$ docker container run -d -P my_nginx
```
</div>
@ -238,23 +238,23 @@ plusieurs conteneurs, avant d'agréger le contenu compilé au sein du conteneur
final :
<div lang="en-US">
```
FROM gcc:4.9
COPY . /usr/src/myapp
WORKDIR /usr/src/myapp
RUN gcc -static -static-libgcc -o hello hello.c
```dockerfile
FROM gcc:4.9
COPY . /usr/src/myapp
WORKDIR /usr/src/myapp
RUN gcc -static -static-libgcc -o hello hello.c
FROM scratch
COPY --from=0 /usr/src/myapp/hello /hello
CMD ["/hello"]
FROM scratch
COPY --from=0 /usr/src/myapp/hello /hello
CMD ["/hello"]
```
</div>
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` de notre `Dockerfile`) est
l'image vide, dans laquelle nous recopions simplement le produit de notre
compilation.
`hello.c`. Mais l'image finale (le dernier `FROM`{.dockerfile} de notre
`Dockerfile`) est l'image vide, dans laquelle nous recopions simplement le
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.
@ -267,15 +267,15 @@ donner des noms à chaque image, plutôt que de devoir jongler avec les
numéros. Dans ce cas, on indiquera :
<div lang="en-US">
```
FROM gcc:4.9 as builder
COPY . /usr/src/myapp
WORKDIR /usr/src/myapp
RUN gcc -static -static-libgcc -o hello hello.c
```dockerfile
FROM gcc:4.9 as builder
COPY . /usr/src/myapp
WORKDIR /usr/src/myapp
RUN gcc -static -static-libgcc -o hello hello.c
FROM scratch
COPY --from=builder /usr/src/myapp/hello /hello
CMD ["/hello"]
FROM scratch
COPY --from=builder /usr/src/myapp/hello /hello
CMD ["/hello"]
```
</div>
@ -285,7 +285,7 @@ spécifiquement on souhaite construire avec l'option `--target` :
<div lang="en-US">
```
42sh$ docker build --target builder -t hello-builder .
42sh$ docker build --target builder -t hello-builder .
```
</div>
@ -301,7 +301,7 @@ 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
@ -311,20 +311,15 @@ 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` à :
<div lang="en-US">
```
https://git.nemunai.re/youp0m.git
```
</div>
<https://git.nemunai.re/youp0m.git>
Pour compiler le projet, vous pouvez utiliser dans votre `Dockerfile`
<div lang="en-US">
```go
FROM golang:1.11
COPY . /go/src/git.nemunai.re/youp0m
WORKDIR /go/src/git.nemunai.re/youp0m
RUN go build -v
```dockerfile
FROM golang:1.11
COPY . /go/src/git.nemunai.re/youp0m
WORKDIR /go/src/git.nemunai.re/youp0m
RUN go build -v
```
</div>