tutorials: improve theme + use pandoc 2
This commit is contained in:
parent
de21be218a
commit
d25af4fdb2
65 changed files with 1281 additions and 1292 deletions
|
|
@ -1,19 +1,6 @@
|
|||
include ../pandoc-opts.mk
|
||||
|
||||
SOURCES = tutorial.md interactive.md dockerfile.md goodpractices.md entrypoint.md rendu.md
|
||||
PANDOCOPTS = --latex-engine=xelatex \
|
||||
--standalone \
|
||||
--normalize \
|
||||
--number-sections \
|
||||
--smart \
|
||||
-M lang=fr-FR \
|
||||
-M fontsize=12pt \
|
||||
-M papersize=a4paper \
|
||||
-M mainfont="Linux Libertine O" \
|
||||
-M monofont="FantasqueSansMono-Regular" \
|
||||
-M sansfont="Linux Biolinum O" \
|
||||
-M colorlinks=true \
|
||||
-M linkcolor="black" \
|
||||
-M urlcolor="[rgb]{0.2,0.6,0.4}" \
|
||||
--include-in-header=../header.tex
|
||||
|
||||
|
||||
all: tutorial.pdf
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
|
|
|||
|
|
@ -9,8 +9,8 @@ Afin de faire bénéficier à nos utilisateurs d'une immersion parfaite, nous
|
|||
allons faire en sorte que notre image permette d'être utilisée ainsi :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
42sh$ docker run -d -p 80:80 youp0m -bind :80
|
||||
```bash
|
||||
docker run -d -p 80:80 youp0m -bind :80
|
||||
```
|
||||
</div>
|
||||
|
||||
|
|
@ -19,16 +19,17 @@ Plutôt que de laisser l'utilisateur se débrouiller avec le chemin interne dans
|
|||
lequel il va trouver le bon binaire :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
42sh$ docker run -d -p 80:80 youp0m /srv/youp0m -bind :80
|
||||
```bash
|
||||
docker run -d -p 80:80 youp0m /srv/youp0m -bind :80
|
||||
```
|
||||
</div>
|
||||
|
||||
Essayez les deux commandes, si vous avez utilisé l'instruction `CMD` dans votre
|
||||
`Dockerfile` jusqu'à présent, vous devez vous trouver dans le deuxième cas.
|
||||
Essayez les deux commandes, si vous avez utilisé l'instruction
|
||||
`CMD`{.dockerfile} dans votre `Dockerfile` jusqu'à présent, vous devez vous
|
||||
trouver dans le deuxième cas.
|
||||
|
||||
Pour améliorer la situation, définissez
|
||||
l'[`ENTRYPOINT`](https://docs.docker.com/engine/reference/builder/#entrypoint)
|
||||
l'[`ENTRYPOINT`{.dockerfile}](https://docs.docker.com/engine/reference/builder/#entrypoint)
|
||||
de votre image sur le binaire `/srv/youp0m`.
|
||||
|
||||
|
||||
|
|
@ -43,26 +44,27 @@ Notre but, dans cette partie, sera de créer un utilisateur administrateur
|
|||
(pouvant passer le contrôle d'accès <http://localhost:8080/admin/>) :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
42sh$ docker run -i --rm -p 8080:8080 -e YOUP0M_PASSWORD=admin youp0m
|
||||
```bash
|
||||
docker run -i --rm -p 8080:8080 -e YOUP0M_PASSWORD=admin youp0m
|
||||
```
|
||||
</div>
|
||||
|
||||
### Bases du script
|
||||
|
||||
Notre script d'`ENTRYPOINT` sera appelé avec en argument, ceux passés par
|
||||
l'utilisateur après le nom de l'image, ou, à défaut, le contenu de `CMD`.
|
||||
Notre script d'`ENTRYPOINT`{.dockerfile} sera appelé avec en argument, ceux
|
||||
passés par l'utilisateur après le nom de l'image, ou, à défaut, le contenu de
|
||||
`CMD`.
|
||||
|
||||
C'est donc l'`ENTRYPOINT` qui est responsable de la bonne utilisation de
|
||||
ceux-ci, de leur modification, ...
|
||||
C'est donc l'`ENTRYPOINT`{.dockerfile} qui est responsable de la bonne
|
||||
utilisation de ceux-ci, de leur modification, ...
|
||||
|
||||
À la fin d'un script d'`ENTRYPOINT`, afin de garder comme premier processus du
|
||||
conteneur le programme qui nous intéresse, on réalise un `execve(2)`, sans
|
||||
`fork(2)` :
|
||||
À la fin d'un script d'`ENTRYPOINT`{.dockerfile}, afin de garder comme premier
|
||||
processus du conteneur le programme qui nous intéresse, on réalise un
|
||||
`execve(2)`, sans `fork(2)` :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
exec /srv/youp0m $@
|
||||
```bash
|
||||
exec /srv/youp0m $@
|
||||
```
|
||||
</div>
|
||||
|
||||
|
|
@ -70,8 +72,8 @@ Dans cet exemple : `exec` est la commande interne à notre shell pour lui
|
|||
indiquer de remplacer son fil d'exécution par cette commande (sans `exec`, il
|
||||
va `fork(2)` avant). `$@` est ici pour transmettre tel quel la liste des
|
||||
arguments passés au script (il s'agit de ceux donnés par l'utilisateur, sur la
|
||||
ligne de commande du `run`, ou du contenu de `CMD` si l'utilisateur n'a rien
|
||||
précisé).
|
||||
ligne de commande du `run`, ou du contenu de `CMD`{.dockerfile} si
|
||||
l'utilisateur n'a rien précisé).
|
||||
|
||||
|
||||
### Format du fichier `htpasswd`
|
||||
|
|
@ -80,12 +82,12 @@ Le format attendu est celui d'un fichier `htpasswd` typique d'Apache. Vous
|
|||
pourriez obtenir un fichier valide avec :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
(
|
||||
echo -n "$YOUP0M_USERNAME"
|
||||
echo -n ":"
|
||||
openssl passwd -crypt "$YOUP0M_PASSWORD"
|
||||
) > myhtpasswd
|
||||
```bash
|
||||
(
|
||||
echo -n "$YOUP0M_USERNAME"
|
||||
echo -n ":"
|
||||
openssl passwd -crypt "$YOUP0M_PASSWORD"
|
||||
) > myhtpasswd
|
||||
```
|
||||
</div>
|
||||
|
||||
|
|
@ -93,22 +95,23 @@ Il faut ensuite passer le fichier sur la ligne de commande grâce à l'option
|
|||
`-htpasswd`.
|
||||
|
||||
|
||||
### Exercice
|
||||
### Exercice {-}
|
||||
|
||||
Écrivez un script d'`ENTRYPOINT`, analysant les variables d'environnement, à la
|
||||
recherche de `YOUP0M_USERNAME` et `YOUP0M_PASSWORD` pour initialiser le fichier
|
||||
`.htpasswd` qui sera ajouté à la liste des arguments à passer au service.
|
||||
Écrivez un script d'`ENTRYPOINT`{.dockerfile}, analysant les variables
|
||||
d'environnement, à la recherche de `YOUP0M_USERNAME` et `YOUP0M_PASSWORD` pour
|
||||
initialiser le fichier `.htpasswd` qui sera ajouté à la liste des arguments à
|
||||
passer au service.
|
||||
|
||||
Par exemple :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
42sh$ docker run -d -p 8081:8081 -e YOUP0M_USERNAME=admin -e YOUP0M_PASSWORD=admin youp0m -bind=:8081
|
||||
42sh$ docker run -d -p 8081:8081 -e YOUP0M_USERNAME=admin -e YOUP0M_PASSWORD=admin youp0m -bind=:8081
|
||||
|
||||
42sh$ curl -u admin:badpasswd http://localhost:8081/admin/
|
||||
You are not allowed to perform this request.
|
||||
42sh$ curl -u admin:badpasswd http://localhost:8081/admin/
|
||||
You are not allowed to perform this request.
|
||||
|
||||
42sh$ curl -u admin:admin http://localhost:8081/admin/
|
||||
<!DOCTYPE html>
|
||||
42sh$ curl -u admin:admin http://localhost:8081/admin/
|
||||
<!DOCTYPE html>
|
||||
```
|
||||
</div>
|
||||
|
|
|
|||
|
|
@ -68,10 +68,10 @@ votre InfluxDB écoute sur le port 8086 local :
|
|||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
TELEGRAF_VERSION=1.8.0
|
||||
wget https://dl.influxdata.com/telegraf/releases/telegraf-${TELEGRAF_VERSION}_linux_amd64.tar.gz
|
||||
tar xf telegraf-${TELEGRAF_VERSION}_linux_amd64.tar.gz
|
||||
TELEGRAF_CONFIG_PATH=./telegraf/etc/telegraf/telegraf.conf ./telegraf/usr/bin/telegraf
|
||||
TELEGRAF_VERSION=1.8.0
|
||||
wget https://dl.influxdata.com/telegraf/releases/telegraf-${TELEGRAF_VERSION}_linux_amd64.tar.gz
|
||||
tar xf telegraf-${TELEGRAF_VERSION}_linux_amd64.tar.gz
|
||||
TELEGRAF_CONFIG_PATH=./telegraf/etc/telegraf/telegraf.conf ./telegraf/usr/bin/telegraf
|
||||
```
|
||||
</div>
|
||||
|
||||
|
|
@ -82,16 +82,16 @@ Dans l'interface sélectionnez la base `telegraf` puis explorez les valeurs :
|
|||
|
||||
<div lang="en-US">
|
||||
```sql
|
||||
SHOW MEASUREMENTS
|
||||
SHOW FIELD KEYS
|
||||
SELECT usage_idle FROM cpu WHERE cpu = 'cpu-total' ORDER BY time DESC LIMIT 5
|
||||
SHOW MEASUREMENTS
|
||||
SHOW FIELD KEYS
|
||||
SELECT usage_idle FROM cpu WHERE cpu = 'cpu-total' ORDER BY time DESC LIMIT 5
|
||||
```
|
||||
</div>
|
||||
|
||||
Laissons tourner `telegraf` afin de constituer un petit historique de valeurs.
|
||||
|
||||
|
||||
## Rendu
|
||||
## Rendu {-}
|
||||
|
||||
Avant de passer à la suite, placez votre `Dockerfile` et les éventuels fichiers
|
||||
annexes dans un dossier `influxdb`.
|
||||
|
|
|
|||
|
|
@ -55,10 +55,10 @@ vous codez.
|
|||
Lorsqu'une ligne devient complexe, allez à la ligne :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
RUN apt-get update && apt-get install -y \
|
||||
nginx \
|
||||
php5-fpm
|
||||
```dockerfile
|
||||
RUN apt-get update && apt-get install -y \
|
||||
nginx \
|
||||
php5-fpm
|
||||
```
|
||||
</div>
|
||||
|
||||
|
|
@ -70,13 +70,13 @@ Lorsque c'est possible, ordonnez vos lignes suivant un ordre logique. Par
|
|||
exemple :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
RUN apt-get update && apt-get install -y \
|
||||
bzr \
|
||||
cvs \
|
||||
git \
|
||||
mercurial \
|
||||
subversion
|
||||
```dockerfile
|
||||
RUN apt-get update && apt-get install -y \
|
||||
bzr \
|
||||
cvs \
|
||||
git \
|
||||
mercurial \
|
||||
subversion
|
||||
```
|
||||
</div>
|
||||
|
||||
|
|
@ -99,9 +99,9 @@ Il y a un certain nombre de règles à connaître pour bien utiliser ce mécanis
|
|||
le(s) différente(s) image(s) qui dérive(nt) de la commande précédente. Si
|
||||
aucune commande correspondante n'est trouvé, le cache se retrouve invalidé
|
||||
pour les instructions suivantes.
|
||||
- Pour les instructions `ADD` et `COPY`, en plus de la comparaison précédente,
|
||||
la somme de contrôle du fichier est ajoutée. Si le fichier a été modifié, le
|
||||
cache se retrouve invalidé.
|
||||
- Pour les instructions `ADD`{.dockerfile} et `COPY`{.dockerfile}, en plus de
|
||||
la comparaison précédente, la somme de contrôle du fichier est ajoutée. Si le
|
||||
fichier a été modifié, le cache se retrouve invalidé.
|
||||
- Une fois que le cache est invalidé, toutes les commandes restantes à exécuter
|
||||
dans le `Dockerfile` vont être exécutées.
|
||||
|
||||
|
|
@ -132,10 +132,10 @@ lors de sa construction.
|
|||
|
||||
## Exposez les ports standards
|
||||
|
||||
La commande `EXPOSE` vous permet d'indiquer les ports sur lesquels votre
|
||||
conteneur s'attend à recevoir des paquets venant de l'extérieur. Ces ports ne
|
||||
sont pas partagés avec l'hôte ou les autres conteneur, donc vous n'avez pas de
|
||||
raison de ne pas utiliser les ports standards.
|
||||
La commande `EXPOSE`{.dockerfile} vous permet d'indiquer les ports sur lesquels
|
||||
votre conteneur s'attend à recevoir des paquets venant de l'extérieur. Ces
|
||||
ports ne sont pas partagés avec l'hôte ou les autres conteneur, donc vous
|
||||
n'avez pas de raison de ne pas utiliser les ports standards.
|
||||
|
||||
Si vous faites cela, il y a de forte chance qu'il n'y ait pas besoin de
|
||||
modifier la configuration des autres logiciels contenu dans d'autres conteneurs
|
||||
|
|
@ -154,9 +154,9 @@ L'entrypoint peut être utilisé de deux manières différentes :
|
|||
indiqué dans l'entrypoint. Par exemple pour nginx :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
ENTRYPOINT ["nginx"]
|
||||
CMD ["-g daemon off;"]
|
||||
```dockerfile
|
||||
ENTRYPOINT ["nginx"]
|
||||
CMD ["-g daemon off;"]
|
||||
```
|
||||
</div>
|
||||
|
||||
|
|
@ -166,28 +166,29 @@ L'entrypoint peut être utilisé de deux manières différentes :
|
|||
l'image de PostgreSQL possède cet entrypoint :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
#!/bin/bash
|
||||
set -e
|
||||
```bash
|
||||
#!/bin/bash
|
||||
set -e
|
||||
|
||||
if [ "$1" = 'postgres' ]; then
|
||||
chown -R postgres "$PGDATA"
|
||||
if [ "$1" = 'postgres' ]; then
|
||||
chown -R postgres "$PGDATA"
|
||||
|
||||
if [ -z "$(ls -A "$PGDATA")" ]; then
|
||||
gosu postgres initdb
|
||||
fi
|
||||
if [ -z "$(ls -A "$PGDATA")" ]; then
|
||||
gosu postgres initdb
|
||||
fi
|
||||
|
||||
exec gosu postgres "$@"
|
||||
fi
|
||||
exec gosu postgres "$@"
|
||||
fi
|
||||
|
||||
exec "$@"
|
||||
exec "$@"
|
||||
```
|
||||
</div>
|
||||
|
||||
|
||||
## `[""]`, `'` et sans `[]`
|
||||
|
||||
Les instructions `ENTRYPOINT` et `CMD` peuvent prendre deux formes :
|
||||
Les instructions `ENTRYPOINT`{.dockerfile} et `CMD`{.dockerfile} peuvent
|
||||
prendre deux formes :
|
||||
|
||||
- `["cmd", "arg1", "arg2"]` : ici, un simple `exexve` sera effectué avec ces
|
||||
arguments. Si d'éventuels variables se trouve dans les arguments, elles ne
|
||||
|
|
@ -201,14 +202,14 @@ pouvez pas utiliser les simple quotes.
|
|||
|
||||
## Volumes
|
||||
|
||||
L'instruction `VOLUME` doit être utilisée pour exposer tous les espaces de
|
||||
stockage de données, configuration, ...
|
||||
L'instruction `VOLUME`{.dockerfile} doit être utilisée pour exposer tous les
|
||||
espaces de stockage de données, configuration,\ ...
|
||||
|
||||
|
||||
## Réduisez les privilèges
|
||||
|
||||
Utilisez l'instruction `USER` dès que vous le pouvez, lorsqu'un service ne
|
||||
réclame pas de privilège particulier.
|
||||
Utilisez l'instruction `USER`{.dockerfile} dès que vous le pouvez, lorsqu'un
|
||||
service ne réclame pas de privilège particulier.
|
||||
|
||||
Il vous faudra sans doute créer l'utilisateur et son groupe dans le Dockerfile.
|
||||
|
||||
|
|
|
|||
|
|
@ -6,8 +6,8 @@ Modification interactive
|
|||
Pour créer une image, commençons par entrer dans un nouveau conteneur :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
docker container run -it ubuntu /bin/bash
|
||||
```bash
|
||||
docker container run -it ubuntu /bin/bash
|
||||
```
|
||||
</div>
|
||||
|
||||
|
|
@ -19,8 +19,8 @@ afin de ne pas livrer de superflu, la liste des paquets et son cache ne sont
|
|||
pas incluses dans le conteneur.
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
apt-get update
|
||||
```bash
|
||||
apt-get update
|
||||
```
|
||||
</div>
|
||||
|
||||
|
|
@ -33,8 +33,8 @@ jour.
|
|||
Installons maintenant un programme :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
apt-get install nano
|
||||
```bash
|
||||
apt-get install nano
|
||||
```
|
||||
</div>
|
||||
|
||||
|
|
@ -45,8 +45,8 @@ Sauvegardez vos modifications en tant que nouvelle image Docker, avec
|
|||
la commande `commit` :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
docker container commit CONTAINER my_nano
|
||||
```bash
|
||||
docker container commit CONTAINER my_nano
|
||||
```
|
||||
</div>
|
||||
|
||||
|
|
@ -57,8 +57,8 @@ doit servir de modèle. `my_nano` est le nom que vous voudrez utiliser
|
|||
Testons sans plus attendre notre nouvelle image :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
docker container run -it my_nano /bin/bash
|
||||
```bash
|
||||
docker container run -it my_nano /bin/bash
|
||||
```
|
||||
</div>
|
||||
|
||||
|
|
|
|||
|
|
@ -7,28 +7,28 @@ Projet
|
|||
------
|
||||
|
||||
Avec l'aide d'un `Dockerfile` *multi-stage*, réalisez l'image la plus petite
|
||||
possible (partant d'un `FROM scratch`), qui permette d'utiliser la [page de
|
||||
compte à rebours](https://virli.nemunai.re/countdown.html) avec cette
|
||||
possible (partant d'un `FROM scratch`{.dockerfile}), qui permette d'utiliser la
|
||||
[page de compte à rebours](https://virli.nemunai.re/countdown.html) avec cette
|
||||
configuration pour nginx :
|
||||
|
||||
<div lang="en-US">
|
||||
```conf
|
||||
events {}
|
||||
events {}
|
||||
|
||||
http {
|
||||
default_type text/html;
|
||||
http {
|
||||
default_type text/html;
|
||||
|
||||
index countdown.html;
|
||||
index countdown.html;
|
||||
|
||||
server {
|
||||
listen 8080;
|
||||
server {
|
||||
listen 8080;
|
||||
|
||||
root /srv/http;
|
||||
root /srv/http;
|
||||
|
||||
rewrite "^/[0-9]+:[0-9]{2}$" /countdown.html;
|
||||
rewrite "^/[0-9]+$" /countdown.html;
|
||||
}
|
||||
rewrite "^/[0-9]+:[0-9]{2}$" /countdown.html;
|
||||
rewrite "^/[0-9]+$" /countdown.html;
|
||||
}
|
||||
}
|
||||
```
|
||||
</div>
|
||||
|
||||
|
|
@ -46,9 +46,9 @@ une attention particulière au suivi des bonnes pratiques d'écriture des
|
|||
|
||||
<div lang="en-US">
|
||||
```
|
||||
42sh$ docker build -t countdown countdown
|
||||
42sh$ docker run -d -P countdown
|
||||
42sh$ firefox http://localhost:32198/42:23
|
||||
42sh$ docker build -t countdown countdown
|
||||
42sh$ docker run -d -P countdown
|
||||
42sh$ firefox http://localhost:32198/42:23
|
||||
```
|
||||
</div>
|
||||
|
||||
|
|
@ -83,15 +83,15 @@ supplémentaires) :
|
|||
|
||||
<div lang="en-US">
|
||||
```
|
||||
login_x-TP2/
|
||||
login_x-TP2/youp0m/
|
||||
login_x-TP2/youp0m/Dockerfile
|
||||
login_x-TP2/youp0m/entrypoint.sh
|
||||
login_x-TP2/youp0m/.dockerignore
|
||||
login_x-TP2/youp0m/...
|
||||
login_x-TP2/countdown/Dockerfile
|
||||
(login_x-TP2/countdown/nginx.conf)
|
||||
(login_x-TP2/countdown/countdown.html)
|
||||
login_x-TP2/
|
||||
login_x-TP2/youp0m/
|
||||
login_x-TP2/youp0m/Dockerfile
|
||||
login_x-TP2/youp0m/entrypoint.sh
|
||||
login_x-TP2/youp0m/.dockerignore
|
||||
login_x-TP2/youp0m/...
|
||||
login_x-TP2/countdown/Dockerfile
|
||||
(login_x-TP2/countdown/nginx.conf)
|
||||
(login_x-TP2/countdown/countdown.html)
|
||||
```
|
||||
</div>
|
||||
|
||||
|
|
|
|||
|
|
@ -1,22 +1,24 @@
|
|||
---
|
||||
title: Virtualisation légère -- TP n^o^ 2.1
|
||||
subtitle: Construire des images Docker
|
||||
author: Pierre-Olivier *Nemunaire* Mercier
|
||||
author: Pierre-Olivier *nemunaire* [Mercier]{.smallcaps}
|
||||
institute: EPITA
|
||||
date: Jeudi 18 octobre 2018
|
||||
abstract: |
|
||||
Durant ce deuxième TP, nous allons voir comment créer nos propres
|
||||
images !
|
||||
|
||||
\vspace{1em}
|
||||
|
||||
Tous les éléments de ce TP (exercices et projet) sont à rendre à
|
||||
<virli@nemunai.re> au plus tard le mercredi 24 octobre 2018 à 0
|
||||
h 42. Consultez la dernière section de chaque partie pour plus
|
||||
d'information sur les éléments à rendre.
|
||||
|
||||
En tant que personnes sensibilisées à la sécurité des échanges
|
||||
électroniques, vous devrez m'envoyer vos rendus signés avec votre
|
||||
clef PGP. Pensez à
|
||||
[me](https://pgp.mit.edu/pks/lookup?op=vindex&search=0x842807A84573CC96)
|
||||
faire signer votre clef et n'hésitez pas à [faire signer votre
|
||||
clef](https://www.meetup.com/fr/Paris-certification-de-cles-PGP-et-CAcert/).
|
||||
...
|
||||
|
||||
Durant ce deuxième TP, nous allons voir comment créer nos propres images !
|
||||
|
||||
Tous les éléments de ce TP (exercices et projet) sont à rendre à
|
||||
<virli@nemunai.re> au plus tard le mercredi 24 octobre 2018 à 0 h 42. Consultez la
|
||||
dernière section de chaque partie pour plus d'information sur les éléments à
|
||||
rendre.
|
||||
|
||||
En tant que personnes sensibilisées à la sécurité des échanges électroniques,
|
||||
vous devrez m'envoyer vos rendus signés avec votre clef PGP. Pensez à
|
||||
[me](https://pgp.mit.edu/pks/lookup?op=vindex&search=0x842807A84573CC96) faire
|
||||
signer votre clef et n'hésitez pas à
|
||||
[faire signer votre clef](https://www.meetup.com/fr/Paris-certification-de-cles-PGP-et-CAcert/).
|
||||
|
||||
\tableofcontents
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue