Split Docker tutorials into basis, orchestration and dockerfiles
This commit is contained in:
parent
2d364556a2
commit
2c48fa7942
@ -1,50 +0,0 @@
|
||||
\newpage
|
||||
|
||||
Installation
|
||||
============
|
||||
|
||||
## `docker-compose`
|
||||
|
||||
Pour ce TP, nous allons avoir besoin de `docker-compose`.
|
||||
|
||||
Ce projet ne bénéficie pas d'une intégration au sein du projet Docker et doit
|
||||
être téléchargé séparément, car originellement, le projet était développé par
|
||||
une équipe indépendante. S'étant révélé primordiale, ils ont trouvé une place
|
||||
au sein du projet Docker, mais l'incompatibilité des langages utilisés fait que
|
||||
`docker-compose` n'est toujours pas intégré dans docker.
|
||||
|
||||
### Par le gestionnaire de paquets
|
||||
|
||||
Les distributions à jour vous proposeront un paquet `docker-compose` qui
|
||||
fonctionnera avec la version de Docker qu'ils fournissent.
|
||||
|
||||
### Par la distribution binaire
|
||||
|
||||
L'équipe en charge de Docker compose met à disposition un exécutable contenant
|
||||
tous les scripts. Nous pouvons l'installer en suivant la procédure suivante :
|
||||
|
||||
```shell
|
||||
curl -L https://github.com/docker/compose/releases/download/1.8.0/docker-compose-Linux-x86_64 \
|
||||
> /usr/bin/docker-compose
|
||||
chmod +x /usr/bin/docker-compose
|
||||
```
|
||||
|
||||
### `pip`
|
||||
|
||||
Le projet étant écrit en Python, il est également disponible via `pip`, si vous
|
||||
préférez cette méthode. N'oubliez pas de préciser une version compatible avec
|
||||
votre version de Docker.
|
||||
|
||||
|
||||
### Vérification du fonctionnement
|
||||
|
||||
Comme avec Docker, nous pouvons vérifier le bon fonctionnement de
|
||||
`docker-compose` en exécutant la commande :
|
||||
|
||||
```
|
||||
42sh$ docker-compose --version
|
||||
docker-compose version: 1.8.0
|
||||
```
|
||||
|
||||
Si vous obtenez une réponse similaire, c'est que vous êtes prêt à commencer le
|
||||
TP ! Alors n'attendons pas, partons à l'aventure !
|
@ -1,4 +1,4 @@
|
||||
SOURCES = tutorial.md installation.md what.md first.md cleaning.md dockerfile.md volumes.md linking.md rendu.md
|
||||
SOURCES = tutorial.md installation.md what.md first.md cleaning.md volumes.md linking.md rendu.md
|
||||
PANDOCOPTS = --latex-engine=xelatex \
|
||||
--standalone \
|
||||
--normalize \
|
@ -166,61 +166,3 @@ sans quoi `bash` ne se lancera pas en mode interractif[^bashnointer].
|
||||
|
||||
L'option `-i` reste néanmoins nécessaire pour que l'entrée standard soit
|
||||
transmise au conteneur.
|
||||
|
||||
|
||||
### Modification interactive
|
||||
|
||||
Nous voilà maintenant dans le conteneur ! Il est assez épuré, il n'y a rien de
|
||||
superflu : même pas d'éditeur de texte : ni vim, ni emacs, même pas `vi` !
|
||||
|
||||
La première chose à faire est de télécharger la liste des paquets. En effet,
|
||||
afin de ne pas livrer de superflu, la liste des paquets et son cache ne sont
|
||||
pas inclues dans le conteneur.
|
||||
|
||||
```
|
||||
apt-get update
|
||||
```
|
||||
|
||||
Il peut arriver que des paquets présents dans l'image ne soient pas à
|
||||
jour. Afin de garder un environnement cohérent, il est recommandé de ne pas
|
||||
utiliser le gestionnaire de paquets pour mettre à jour les paquets présent de
|
||||
base, mais plutôt de contacter le mainteneur de l'image pour qu'il la mette à
|
||||
jour.
|
||||
|
||||
Installons maintenant un programme :
|
||||
|
||||
```
|
||||
apt-get install nano
|
||||
```
|
||||
|
||||
En attendant la fin de l'installation, jetons un œil à la commande dans un
|
||||
autre terminal :
|
||||
|
||||
```
|
||||
docker container ls
|
||||
```
|
||||
|
||||
Cette commande liste les conteneurs actifs. Notez le *Container ID* ainsi que
|
||||
le *NAMES* du conteneur du conteneur actuellement en cours d'installation de
|
||||
`nano`.
|
||||
|
||||
Lorsque l'installation de `nano` est terminée, quittez l'image en tapant
|
||||
`exit`.
|
||||
|
||||
Sauvegardez votre image modifiée avec la commande `commit` pour pouvoir
|
||||
commencer directement de votre image avec `nano` :
|
||||
|
||||
```
|
||||
docker container commit CONTAINER my_nano
|
||||
```
|
||||
|
||||
En remplaçant `CONTAINER` par le nom ou l'identifiant de votre
|
||||
container. `my_nano` est le nom que vous voudrez utiliser à la place
|
||||
d'`ubuntu` :
|
||||
|
||||
```
|
||||
docker container run -it my_nano /bin/bash
|
||||
```
|
||||
|
||||
Vous constatez cette fois que vous pouvez lancer `nano`, alors que vous ne
|
||||
pouvez toujours pas le faire dans un conteneur issue d'une image `ubuntu` !
|
Before Width: | Height: | Size: 247 KiB After Width: | Height: | Size: 247 KiB |
@ -1,4 +1,4 @@
|
||||
SOURCES = tutorial.md installation.md what.md first.md supervisor.md goodpractices.md compose.md project.md
|
||||
SOURCES = tutorial.md setup.md what.md manual.md compose.md project.md
|
||||
PANDOCOPTS = --latex-engine=xelatex \
|
||||
--standalone \
|
||||
--normalize \
|
141
tutorial/docker-orchestration/check.sh
Executable file
141
tutorial/docker-orchestration/check.sh
Executable file
@ -0,0 +1,141 @@
|
||||
#!/bin/sh
|
||||
|
||||
note_init() {
|
||||
NOTE=0
|
||||
echo -n $@
|
||||
}
|
||||
|
||||
note() {
|
||||
NOTE=$(($NOTE + $1))
|
||||
echo -n ,$@
|
||||
}
|
||||
|
||||
for LOGIN in $@
|
||||
do
|
||||
note_init $LOGIN
|
||||
pushd $LOGIN > /dev/null
|
||||
|
||||
# Questions
|
||||
|
||||
if grep -i "go" questions.txt 2> /dev/null > /dev/null; then
|
||||
note 1
|
||||
else
|
||||
note 0
|
||||
fi
|
||||
|
||||
if grep -E -i "(linkage|static|statique|liaison)" questions.txt 2> /dev/null > /dev/null; then
|
||||
note 1
|
||||
else
|
||||
note 0
|
||||
fi
|
||||
|
||||
|
||||
# Exercice InfluxDB
|
||||
|
||||
DOCKERFILE_influxdb="influxdb/Dockerfile"
|
||||
if ! [ -f "${DOCKERFILE_influxdb}" ] && [ -f "influxdb/dockerfile" ]; then
|
||||
DOCKERFILE_influxdb="influxdb/dockerfile"
|
||||
fi
|
||||
|
||||
NBRUN=$(grep -E -i ^RUN "${DOCKERFILE_influxdb}" 2> /dev/null | wc -l)
|
||||
if [ $NBRUN -le 2 ] && [ $NBRUN -gt 0 ]; then
|
||||
note 1
|
||||
else
|
||||
note 0
|
||||
fi
|
||||
|
||||
if grep -E -i '^EXPOSE.*8083' "${DOCKERFILE_influxdb}" 2> /dev/null > /dev/null && grep -E -i '^EXPOSE.*8086' "${DOCKERFILE_influxdb}" 2> /dev/null > /dev/null && \
|
||||
grep -i ^EXPOSE "${DOCKERFILE_influxdb}" 2> /dev/null | sed "s/ 8083//g;s/ 8086//g" | grep -E '^EXPOSE[[:space:]]*$' > /dev/null; then
|
||||
note 1
|
||||
else
|
||||
note 0
|
||||
fi
|
||||
|
||||
if grep -E -i '^MAINTAINER[[:space:]]' "${DOCKERFILE_influxdb}" 2> /dev/null > /dev/null; then
|
||||
note 1
|
||||
else
|
||||
note 0
|
||||
fi
|
||||
|
||||
if grep -E -i '^(ADD|COPY)[[:space:]]' "${DOCKERFILE_influxdb}" 2> /dev/null > /dev/null; then
|
||||
CONFIGFILE=$(grep -E -i '^(ADD|COPY)[[:space:]]' "${DOCKERFILE_influxdb}" | sed -r 's/^(COPY|ADD)[[:space:]]+([^[:space:]]*).*$/\2/')
|
||||
if [ -f "influxdb/${CONFIGFILE}" ]; then
|
||||
note 1
|
||||
else
|
||||
note 0
|
||||
fi
|
||||
else
|
||||
note 0
|
||||
fi
|
||||
|
||||
|
||||
# Exercice mymonitoring
|
||||
|
||||
DOCKERFILE_mymonitoring="mymonitoring/Dockerfile"
|
||||
if grep -E -i '^FROM[[:space:]]' "${DOCKERFILE_mymonitoring}" 2> /dev/null > /dev/null; then
|
||||
note 1
|
||||
else
|
||||
note 0
|
||||
fi
|
||||
|
||||
if grep -E -i '^ENV[[:space:]]' "${DOCKERFILE_mymonitoring}" 2> /dev/null > /dev/null; then
|
||||
note 1
|
||||
else
|
||||
note 0
|
||||
fi
|
||||
|
||||
CONFIGFILE=$(grep -E -i '^(ADD|COPY)[[:space:]]' "${DOCKERFILE_mymonitoring}" 2> /dev/null | grep -vi "influx" | grep -vi "chrono" | sed -r 's/^(COPY|ADD)[[:space:]]+([^[:space:]]*).*$/\2/')
|
||||
if ! [ -f "mymonitoring/${CONFIGFILE}" ]; then
|
||||
CONFIGFILE="mymonitoring/supervisor.conf"
|
||||
fi
|
||||
if [ -f "mymonitoring/${CONFIGFILE}" ]; then
|
||||
ERRS=0
|
||||
|
||||
if grep -E -i "command=.*service.*start" "mymonitoring/${CONFIGFILE}" > /dev/null; then
|
||||
ERRS=$(($ERRS + 1))
|
||||
fi
|
||||
|
||||
note $((2 - $ERRS))
|
||||
else
|
||||
note 0
|
||||
fi
|
||||
|
||||
|
||||
# Exercice docker-compose
|
||||
|
||||
DOCKERCOMPOSE="docker-compose.yml"
|
||||
|
||||
NBBUILD=$(grep -E -i "build[[:space:]]*:" "${DOCKERCOMPOSE}" 2> /dev/null | wc -l)
|
||||
if [ $NBBUILD -ge 2 ]; then
|
||||
note 2
|
||||
elif [ $NBBUILD -ge 1 ]; then
|
||||
note 1
|
||||
else
|
||||
note 0
|
||||
fi
|
||||
|
||||
NBVOLS=$(grep -E -i "volumes[[:space:]]*:" "${DOCKERCOMPOSE}" 2> /dev/null | wc -l)
|
||||
if [ $NBVOLS -ge 2 ]; then
|
||||
note 2
|
||||
elif [ $NBVOLS -ge 1 ]; then
|
||||
note 1
|
||||
else
|
||||
note 0
|
||||
fi
|
||||
|
||||
NBNET=$(grep -E -i "networks[[:space:]]*:" "${DOCKERCOMPOSE}" 2> /dev/null | wc -l)
|
||||
NBLINK=$(grep -E -i "networks[[:space:]]*:" "${DOCKERCOMPOSE}" 2> /dev/null | wc -l)
|
||||
if [ $NBNET -ge 2 ]; then
|
||||
note 2
|
||||
elif [ $NBNET -ge 1 ]; then
|
||||
note 1
|
||||
elif [ $NBLINK -ge 1 ]; then
|
||||
note 2
|
||||
else
|
||||
note 0
|
||||
fi
|
||||
|
||||
|
||||
echo #" = $NOTE"
|
||||
popd > /dev/null
|
||||
done
|
Before Width: | Height: | Size: 92 KiB After Width: | Height: | Size: 92 KiB |
@ -1,57 +1,7 @@
|
||||
\newpage
|
||||
|
||||
# Compose
|
||||
|
||||
Avec notre conteneur utilisant `supervisor`, nous ne respectons pas
|
||||
cette dernière bonne pratique d'un seul processus par conteneur :-(
|
||||
|
||||
L'intérêt est de permettre à chaque conteneur d'effectuer une tâche
|
||||
simple et générique, de manière à pouvoir être réutilisé pour d'autres
|
||||
projets dans le futur. Par exemple, notre conteneur InfluxDB pourra
|
||||
être utilisé pour stocker des relevés de métriques d'autres systèmes
|
||||
ou des logs. Chronograf peut être connecté à d'autres serveurs afin
|
||||
de corréler les métriques, ...
|
||||
|
||||
|
||||
## Séparer le `Dockerfile`
|
||||
|
||||
Commençons par séparer notre `Dockerfile` en deux : dans une partie
|
||||
nous allons garder la partie InfluxDB, de l'autre la partie Chronograf.
|
||||
|
||||
Il va vous falloir créer deux dossiers distincts, il en faut un par
|
||||
`Dockerfile` : réutilisez l'image `influxdb` créée précédemment et créez le
|
||||
dossier pour l'image `chronograf`.
|
||||
|
||||
\vspace{1em}
|
||||
|
||||
Pour tester la bonne marche de vos conteneurs, vous pouvez le lancer votre
|
||||
conteneur chronograf avec la commande suivante (en considérant que votre
|
||||
conteneur influxdb de la première partie est toujours lancé).
|
||||
|
||||
```shell
|
||||
docker run --rm --link YOUR_INFLUX_CNTR_NAME:influxdb chronograf
|
||||
```
|
||||
|
||||
Remplacez `YOUR_INFLUX_CNTR_NAME` par le nom du conteneur qui fait tourner
|
||||
votre influxdb. En créant ce lien, `chronograf` sera capable de contacter une
|
||||
machine nommée `influxdb` (indiqué par la partie du lien après les `:`).
|
||||
|
||||
|
||||
### Visualiser les données dans `chronograf`
|
||||
|
||||
Avant d'arrêter `telegraf` et nos conteneurs pour passer à une nouvelle étape,
|
||||
prenez le temps d'afficher les données que vous avez collecté depuis le début
|
||||
du TP.
|
||||
|
||||
Après avoir ajouté le serveur (en remplaçant `localhost` proposé par défaut par
|
||||
`influxdb` issue du *link*), ajouter deux visualisations avec les requêtes
|
||||
suivantes :
|
||||
|
||||
```sql
|
||||
SELECT used, available, cached FROM mem WHERE tmpltime()
|
||||
SELECT mean(usage_idle) FROM cpu WHERE tmpltime() GROUP BY time(20s), cpu
|
||||
```
|
||||
|
||||
Compose
|
||||
=======
|
||||
|
||||
## Automatiser la construction et le lancement
|
||||
|
6
tutorial/docker-orchestration/manual.md
Normal file
6
tutorial/docker-orchestration/manual.md
Normal file
@ -0,0 +1,6 @@
|
||||
\newpage
|
||||
|
||||
Lier des conteneurs entre-eux
|
||||
=============================
|
||||
|
||||
TODO
|
123
tutorial/docker-orchestration/setup.md
Normal file
123
tutorial/docker-orchestration/setup.md
Normal file
@ -0,0 +1,123 @@
|
||||
\newpage
|
||||
|
||||
Mise en place
|
||||
=============
|
||||
|
||||
Durant le premier TP, nous avons installé l'environnement Docker principal, qui
|
||||
inclut le client, le daemon et toute sa machinerie. Mais le projet Docker
|
||||
propose de nombreuses autres ressources, souvent directement trouvée dans les
|
||||
usages de la communauté, et parfois même approprié par Docker.
|
||||
|
||||
|
||||
## `docker-machine`
|
||||
|
||||
Pour ce TP, nous allons avoir besoin de `docker-machine`, installez-le sur
|
||||
votre machine hôte, même si ce n'est pas un Linux : le but va être de lancer
|
||||
plusieurs machines virtuelles Docker pour simuler un cluster.
|
||||
|
||||
Ce programme permet de simplifier la gestion du multiples environnements
|
||||
Docker, comme par exemple lorsque l'on souhaite gérer un cluster de machines
|
||||
pour un projet.
|
||||
|
||||
Ainsi, il est possible de provisionner et gérer des machines hôtes sur les
|
||||
plates-formes de cloud habituelles. C'est également ce projet qui est à la base
|
||||
de *Docker for Mac* et *Docker for Windows*, en permettant de lancer via,
|
||||
respectivement, VirtualBox et Hyper-V, un environnement Linux prêt à être
|
||||
utilisé avec Docker.
|
||||
|
||||
### Par la distribution binaire
|
||||
|
||||
L'équipe en charge de `docker-machine` met à disposition un exécutable compilé
|
||||
pour bon nombres d'environnements. Nous pouvons l'installer en suivant la
|
||||
procédure suivante :
|
||||
|
||||
```shell
|
||||
curl -L https://github.com/docker/machine/releases/download/v0.12.2/docker-machine-Linux-x86_64 \
|
||||
> /usr/bin/docker-machine
|
||||
chmod +x /usr/bin/docker-machine
|
||||
```
|
||||
|
||||
Si vous êtes dans un environnement différent, jetez un œil à
|
||||
[la documentation d'installation](https://docs.docker.com/machine/install-machine/).
|
||||
|
||||
|
||||
### Support de KVM
|
||||
|
||||
Le programme support de base de nombreux environnement, dont VirtualBox et
|
||||
Hyper-V. Bien d'autres environnements peuvent être supportés, au moyen de
|
||||
plug-ins.
|
||||
|
||||
Si vous utilisez KVM comme hyperviseur, vous allez avoir besoin d'installer le
|
||||
plugins
|
||||
[`docker-machine-kvm`](https://github.com/dhiltgen/docker-machine-kvm). Vous
|
||||
n'aurez qu'à suivre les instructions du
|
||||
[`README`](https://github.com/dhiltgen/docker-machine-kvm/blob/master/README.md)
|
||||
!
|
||||
|
||||
|
||||
### Vérification du fonctionnement
|
||||
|
||||
Comme avec Docker, nous pouvons vérifier le bon fonctionnement de
|
||||
`docker-machine` en exécutant la commande :
|
||||
|
||||
```
|
||||
42sh$ docker-machine version
|
||||
docker-machine version 0.12.2, build 9371605
|
||||
```
|
||||
|
||||
|
||||
## `docker-compose`
|
||||
|
||||
Pour ce TP, nous allons également avoir besoin de `docker-compose`.
|
||||
|
||||
Ce projet ne bénéficie pas d'une intégration au sein du projet Docker et doit
|
||||
être téléchargé séparément, car originellement, le projet était développé par
|
||||
une équipe indépendante[^fig]. Il constitue aujourd'hui une brique de
|
||||
l'écosystème Docker, presque indispensable !
|
||||
|
||||
[^fig]: Le site du projet initial est toujours en ligne :
|
||||
<https://www.fig.sh/>.
|
||||
|
||||
### Par le gestionnaire de paquets
|
||||
|
||||
Les distributions à jour vous proposeront un paquet `docker-compose` qui
|
||||
fonctionnera avec la version de Docker qu'ils fournissent.
|
||||
|
||||
### Par la distribution binaire
|
||||
|
||||
L'équipe en charge de Docker compose met à disposition un exécutable contenant
|
||||
tous les scripts. Nous pouvons l'installer en suivant la procédure suivante :
|
||||
|
||||
```shell
|
||||
curl -L https://github.com/docker/compose/releases/download/1.16.1/docker-compose-Linux-x86_64 \
|
||||
> /usr/bin/docker-compose
|
||||
chmod +x /usr/bin/docker-compose
|
||||
```
|
||||
|
||||
### `pip`
|
||||
|
||||
Le projet étant écrit en Python, il est également disponible via `pip`, si vous
|
||||
préférez cette méthode. N'oubliez pas de préciser une version compatible avec
|
||||
votre version de Docker.
|
||||
|
||||
|
||||
### Vérification du fonctionnement
|
||||
|
||||
Comme avec Docker, nous pouvons vérifier le bon fonctionnement de
|
||||
`docker-compose` en exécutant la commande :
|
||||
|
||||
```
|
||||
42sh$ docker-compose --version
|
||||
docker-compose version: 1.16.1
|
||||
```
|
||||
|
||||
Si vous obtenez une réponse similaire, c'est que vous êtes prêt à commencer le
|
||||
TP ! Alors n'attendons pas, partons à l'aventure !
|
||||
|
||||
|
||||
## Play With Docker
|
||||
|
||||
Tout comme pour le TP précédent, si vous avez des difficultés pour réaliser les
|
||||
exercices sur vos machines, vous pouvez utiliser le projet
|
||||
[Play With Docker](https://play-with-docker.com/) qui vous donnera accès à un
|
||||
bac à sable avec lequel vous pourrez réaliser tous les exercices de ce TP.
|
@ -3,13 +3,13 @@ title: Virtualisation légère -- TP n^o^ 2
|
||||
subtitle: Aller plus loin avec Docker
|
||||
author: Pierre-Olivier *Nemunaire* Mercier
|
||||
institute: EPITA
|
||||
date: Jeudi 15 septembre 2016
|
||||
date: Jeudi 19 octobre 2017
|
||||
...
|
||||
|
||||
Durant ce deuxième TP, nous allons approfondir l'utilisation de Docker !
|
||||
|
||||
Tous les éléments de ce TP (exercices et questions) sont à rendre à
|
||||
<virli@nemunai.re> au plus tard le jeudi 6 octobre 2016 à 8 h 42. Consultez la
|
||||
Tous les éléments de ce TP (exercices et projet) sont à rendre à
|
||||
<virli@nemunai.re> au plus tard le jeudi 26 octobre 2017 à 8 h 42. Consultez la
|
||||
dernière section de chaque partie pour plus d'information sur les éléments à
|
||||
rendre.
|
||||
|
||||
@ -18,8 +18,6 @@ vous devrez m'envoyer vos rendus signés avec votre clef PGP. Pensez à
|
||||
[me](http://pgp.mit.edu/pks/lookup?op=vindex&search=0x842807A84573CC96) faire
|
||||
signer votre clef et n'hésitez pas à
|
||||
[faire signer votre clef](http://www.meetup.com/fr/Paris-certification-de-cles-PGP-et-CAcert/).
|
||||
Vous pouvez utiliser l'adresse <signcheck@nemunai.re> pour savoir si vous vous
|
||||
y prenez correctement.
|
||||
|
||||
\hypersetup{linkcolor=black}
|
||||
\tableofcontents
|
@ -3,10 +3,12 @@
|
||||
But du TP
|
||||
=========
|
||||
|
||||
Aujourd'hui, nous allons réaliser un système de monitoring.
|
||||
Aujourd'hui, nous allons réaliser un système de monitoring, prêt à
|
||||
être déployé chez un fournisseur de cloud.
|
||||
|
||||
Le résultat attendu d'ici la fin du TP, est un groupe de conteneurs
|
||||
indépendants les uns des autres, réutilisables en fonction des besoins.
|
||||
indépendants les uns des autres, réutilisables en fonction de besoins
|
||||
génériques et pouvant facilement être mis à l'échelle.
|
||||
|
||||
Nous collecterons les données d'utilisation de votre machine avec
|
||||
[Telegraf](https://www.influxdata.com/time-series-platform/telegraf/). Ces
|
22
tutorial/dockerfiles/Makefile
Normal file
22
tutorial/dockerfiles/Makefile
Normal file
@ -0,0 +1,22 @@
|
||||
SOURCES = tutorial.md interactive.md dockerfile.md first.md supervisor.md goodpractices.md split.md entrypoint.md multistaged.md
|
||||
PANDOCOPTS = --latex-engine=xelatex \
|
||||
--standalone \
|
||||
--normalize \
|
||||
--number-sections \
|
||||
--smart \
|
||||
-M lang=french \
|
||||
-M fontsize=12pt \
|
||||
-M papersize=a4paper \
|
||||
-M mainfont="Linux Libertine O" \
|
||||
-M monofont="FantasqueSansMono-Regular" \
|
||||
-M sansfont="Linux Biolinum O" \
|
||||
--include-in-header=../header.tex
|
||||
|
||||
|
||||
all: tutorial.pdf
|
||||
|
||||
tutorial.pdf: ${SOURCES}
|
||||
pandoc ${PANDOCOPTS} -o $@ $+
|
||||
|
||||
clean::
|
||||
rm tutorial.pdf
|
Before Width: | Height: | Size: 23 KiB After Width: | Height: | Size: 23 KiB |
@ -3,7 +3,7 @@
|
||||
`Dockerfile`
|
||||
============
|
||||
|
||||
## Mon premier conteneur ... par `Dockerfile`
|
||||
## 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
|
@ -1,6 +1,7 @@
|
||||
\newpage
|
||||
|
||||
# Entrypoint
|
||||
Entrypoint
|
||||
==========
|
||||
|
||||
Jusque là, à chaque redémarrage d'InfluxDB, il est nécessaire de reconfigurer
|
||||
Grafana pour lui indiquer la nouvelle IP du conteneur. En effet, le data
|
@ -5,7 +5,7 @@ Premières étapes
|
||||
|
||||
Dans un premier temps, nous allons créer une image Docker comme si l'on
|
||||
réalisait une installation sur une machine classique : en suivant une recette,
|
||||
sans trop se préoccuper des fonctionnalitées que propose Docker.
|
||||
sans trop se préoccuper des fonctionnalités que propose Docker.
|
||||
|
||||
La machine (notre première image Docker) contiendra tout le nécessaire pour
|
||||
faire fonctionner notre service de monitoring.
|
||||
@ -13,11 +13,15 @@ faire fonctionner notre service de monitoring.
|
||||
|
||||
## Les caches
|
||||
|
||||
Nous avons vu que chaque instruction de notre `Dockerfile` génère une
|
||||
couche. Chaque couche sert de cache d'une construction d'image à
|
||||
l'autre. Ainsi, lorsque vous modifiez une instruction dans votre `Dockerfile`,
|
||||
les instructions précédentes ne sont pas réexécutées mais sont ressorties du
|
||||
cache.
|
||||
Nous avons vu que chaque instruction de notre `Dockerfile` est exécutée dans un
|
||||
conteneur, qui génère ensuite une image intermédiaire. Cette image
|
||||
intermédiaire sert ensuite d'image de base pour l'instruction suivante.
|
||||
|
||||
Lorsque l'on lance la reconstruction du même `Dockerfile`, les images
|
||||
intermédiaires sont utilisées comme un cache d'instructions, permettant ainsi
|
||||
de gagner du temps sur les étapes qui n'ont pas changées. Ainsi, lorsque vous
|
||||
modifiez une instruction dans votre `Dockerfile`, les instructions précédentes
|
||||
ne sont pas réexécutées mais sont ressorties du cache.
|
||||
|
||||
Le cache se base principalement sur le contenu de chaque instruction du
|
||||
`Dockerfile` (pour les `COPY` et `ADD`, il va aussi regarder la date de
|
||||
@ -25,20 +29,22 @@ dernière modification de fichier à copier ou à ajouter). Donc tant qu'une
|
||||
instruction n'est pas modifiée dans le `Dockerfile`, le cache sera utilisé.
|
||||
|
||||
Il est possible de ne pas utiliser le cache et de relancer toutes les étapes du
|
||||
`Dockerfile` en ajoutant l'option `--no-cache` au moment du `docker build`.
|
||||
`Dockerfile` en ajoutant l'option `--no-cache` au moment du `docker image
|
||||
build`.
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
Pour profiter du cache, on va placer de préférences les étapes les plus
|
||||
génériques (qui seraient les plus susceptibles d'apparaître dans d'autres
|
||||
images), en haut du `Dockerfile`.
|
||||
|
||||
Commençons donc notre `Dockerfile` : choisissez une image de base pour remplir
|
||||
votre `FROM`, et indiquez votre nom avec l'instruction `MAINTAINER` (pour
|
||||
indiquez que c'est vous qui maintenez ce conteneur, si des utilisateurs ont besoin
|
||||
de vous avertir pour le mettre à jour par exemple).
|
||||
votre `FROM`, et indiquez votre nom avec l'instruction `LABEL maintainer` (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).
|
||||
|
||||
|
||||
## `RUN` ou script ?
|
||||
@ -46,10 +52,13 @@ de vous avertir pour le mettre à jour par exemple).
|
||||
### InfluxDB
|
||||
|
||||
Ensuite vient la suite d'instructions pour installer d'InfluxDB. Le paquet
|
||||
n'est pas disponible dans les dépôts. La
|
||||
[procédure décrite du site](https://docs.influxdata.com/influxdb/v1.0/introduction/installation/#ubuntu-debian)
|
||||
incite à télécharger le paquet mis à disposition puis à l'installer via `dpkg
|
||||
-i`.
|
||||
n'est pas disponible dans les dépôts[^debrepos]. La
|
||||
[procédure décrite du site](https://portal.influxdata.com/downloads) incite à
|
||||
télécharger le paquet mis à disposition puis à l'installer via `dpkg -i`.
|
||||
|
||||
[^debrepos]: Le projet met à disposition des dépôts, si vous préférez cette
|
||||
méthode, consultez la
|
||||
[documentation d'installation](https://docs.influxdata.com/influxdb/v1.3/introduction/installation/#ubuntu-debian).
|
||||
|
||||
Deux solutions s'offrent à nous :
|
||||
|
59
tutorial/dockerfiles/interactive.md
Normal file
59
tutorial/dockerfiles/interactive.md
Normal file
@ -0,0 +1,59 @@
|
||||
\newpage
|
||||
|
||||
Modification interactive
|
||||
========================
|
||||
|
||||
Nous voilà maintenant dans le conteneur ! Il est assez épuré, il n'y a rien de
|
||||
superflu : même pas d'éditeur de texte : ni vim, ni emacs, même pas `vi` !
|
||||
|
||||
La première chose à faire est de télécharger la liste des paquets. En effet,
|
||||
afin de ne pas livrer de superflu, la liste des paquets et son cache ne sont
|
||||
pas inclues dans le conteneur.
|
||||
|
||||
```
|
||||
apt-get update
|
||||
```
|
||||
|
||||
Il peut arriver que des paquets présents dans l'image ne soient pas à
|
||||
jour. Afin de garder un environnement cohérent, il est recommandé de ne pas
|
||||
utiliser le gestionnaire de paquets pour mettre à jour les paquets présent de
|
||||
base, mais plutôt de contacter le mainteneur de l'image pour qu'il la mette à
|
||||
jour.
|
||||
|
||||
Installons maintenant un programme :
|
||||
|
||||
```
|
||||
apt-get install nano
|
||||
```
|
||||
|
||||
En attendant la fin de l'installation, jetons un œil à la commande dans un
|
||||
autre terminal :
|
||||
|
||||
```
|
||||
docker container ls
|
||||
```
|
||||
|
||||
Cette commande liste les conteneurs actifs. Notez le *Container ID* ainsi que
|
||||
le *NAMES* du conteneur du conteneur actuellement en cours d'installation de
|
||||
`nano`.
|
||||
|
||||
Lorsque l'installation de `nano` est terminée, quittez l'image en tapant
|
||||
`exit`.
|
||||
|
||||
Sauvegardez votre image modifiée avec la commande `commit` pour pouvoir
|
||||
commencer directement de votre image avec `nano` :
|
||||
|
||||
```
|
||||
docker container commit CONTAINER my_nano
|
||||
```
|
||||
|
||||
En remplaçant `CONTAINER` par le nom ou l'identifiant de votre
|
||||
container. `my_nano` est le nom que vous voudrez utiliser à la place
|
||||
d'`ubuntu` :
|
||||
|
||||
```
|
||||
docker container run -it my_nano /bin/bash
|
||||
```
|
||||
|
||||
Vous constatez cette fois que vous pouvez lancer `nano`, alors que vous ne
|
||||
pouvez toujours pas le faire dans un conteneur issue d'une image `ubuntu` !
|
6
tutorial/dockerfiles/multistaged.md
Normal file
6
tutorial/dockerfiles/multistaged.md
Normal file
@ -0,0 +1,6 @@
|
||||
\newpage
|
||||
|
||||
Multi-stage build
|
||||
=================
|
||||
|
||||
TODO
|
54
tutorial/dockerfiles/split.md
Normal file
54
tutorial/dockerfiles/split.md
Normal file
@ -0,0 +1,54 @@
|
||||
\newpage
|
||||
|
||||
Une application par conteneur
|
||||
=============================
|
||||
|
||||
Avec notre conteneur utilisant `supervisor`, nous ne respectons pas
|
||||
cette dernière bonne pratique d'un seul processus par conteneur :-(
|
||||
|
||||
L'intérêt est de permettre à chaque conteneur d'effectuer une tâche
|
||||
simple et générique, de manière à pouvoir être réutilisé pour d'autres
|
||||
projets dans le futur. Par exemple, notre conteneur InfluxDB pourra
|
||||
être utilisé pour stocker des relevés de métriques d'autres systèmes
|
||||
ou des logs. Chronograf peut être connecté à d'autres serveurs afin
|
||||
de corréler les métriques, ...
|
||||
|
||||
|
||||
## Séparer le `Dockerfile`
|
||||
|
||||
Commençons par séparer notre `Dockerfile` en deux : dans une partie
|
||||
nous allons garder la partie InfluxDB, de l'autre la partie Chronograf.
|
||||
|
||||
Il va vous falloir créer deux dossiers distincts, il en faut un par
|
||||
`Dockerfile` : réutilisez l'image `influxdb` créée précédemment et créez le
|
||||
dossier pour l'image `chronograf`.
|
||||
|
||||
\vspace{1em}
|
||||
|
||||
Pour tester la bonne marche de vos conteneurs, vous pouvez le lancer votre
|
||||
conteneur chronograf avec la commande suivante (en considérant que votre
|
||||
conteneur influxdb de la première partie est toujours lancé).
|
||||
|
||||
```shell
|
||||
docker run --rm --link YOUR_INFLUX_CNTR_NAME:influxdb chronograf
|
||||
```
|
||||
|
||||
Remplacez `YOUR_INFLUX_CNTR_NAME` par le nom du conteneur qui fait tourner
|
||||
votre influxdb. En créant ce lien, `chronograf` sera capable de contacter une
|
||||
machine nommée `influxdb` (indiqué par la partie du lien après les `:`).
|
||||
|
||||
|
||||
### Visualiser les données dans `chronograf`
|
||||
|
||||
Avant d'arrêter `telegraf` et nos conteneurs pour passer à une nouvelle étape,
|
||||
prenez le temps d'afficher les données que vous avez collecté depuis le début
|
||||
du TP.
|
||||
|
||||
Après avoir ajouté le serveur (en remplaçant `localhost` proposé par défaut par
|
||||
`influxdb` issue du *link*), ajouter deux visualisations avec les requêtes
|
||||
suivantes :
|
||||
|
||||
```sql
|
||||
SELECT used, available, cached FROM mem WHERE tmpltime()
|
||||
SELECT mean(usage_idle) FROM cpu WHERE tmpltime() GROUP BY time(20s), cpu
|
||||
```
|
@ -79,6 +79,9 @@ cela. Mais plein de gens ont cette problématique et l'application `supervisor`
|
||||
répond parfaitement à notre problématique !
|
||||
|
||||
|
||||
## `HEALTHCHECK`
|
||||
|
||||
|
||||
## `supervisor`
|
||||
|
||||
Première étape : installer `supervisor`, le paquet se trouve dans les dépôts.
|
23
tutorial/dockerfiles/tutorial.md
Normal file
23
tutorial/dockerfiles/tutorial.md
Normal file
@ -0,0 +1,23 @@
|
||||
---
|
||||
title: Virtualisation légère -- TP n^o^ 3
|
||||
subtitle: Construire des images Docker
|
||||
author: Pierre-Olivier *Nemunaire* Mercier
|
||||
institute: EPITA
|
||||
date: Jeudi 11 octobre 2018
|
||||
...
|
||||
|
||||
Durant ce troisiè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 jeudi 18 octobre 2018 à 8 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](http://pgp.mit.edu/pks/lookup?op=vindex&search=0x842807A84573CC96) faire
|
||||
signer votre clef et n'hésitez pas à
|
||||
[faire signer votre clef](http://www.meetup.com/fr/Paris-certification-de-cles-PGP-et-CAcert/).
|
||||
|
||||
\hypersetup{linkcolor=black}
|
||||
\tableofcontents
|
Loading…
Reference in New Issue
Block a user