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

TP2 ready

Browse source
This commit is contained in:
nemunaire 2016-09-15 04:27:59 +02:00 • committed by Pierre-Olivier Mercier
parent f0a7e085fe
commit 5fa883f6ae
8 changed files with 184 additions and 108 deletions
Download patch file Download diff file Expand all files Collapse all files

9
tutorial/2/Makefile
View file

@ -1,13 +1,16 @@
SOURCES = tutorial.md installation.md what.md first.md supervisor.md goodpractices.md compose.md project.md
TEMPLATE = ../../template.tex
PANDOCOPTS = --latex-engine=xelatex \
--standalone \
--normalize \
--number-sections \
-M lang=frenchb \
--smart \
-M lang=french \
-M fontsize=12pt \
-M papersize=a4paper \
--template=${TEMPLATE}
-M mainfont="Linux Libertine O" \
-M monofont="Inconsolata" \
-M sansfont="Linux Biolinum O" \
--include-in-header=../header.tex
all: tutorial.pdf

130
tutorial/2/compose.md
View file

@ -3,15 +3,14 @@
# Compose
Avec notre conteneur utilisant `supervisor`, nous ne respectons pas
bien cette dernière bonne pratique d'un seul processus par conteneur
:-(
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
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 systèmes ou des logs.
Chronograf peut être connecté à d'autres serveurs afin de corréler les
métriques, ...
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`
@ -23,22 +22,19 @@ 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`.
Profitez en pour rajouter les Data Volume Container, si vous ne l'avez
pas fait dans la partie précédente !
\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 `influxdb` (la partie après les `:`).
machine nommée `influxdb` (indiqué par la partie du lien après les `:`).
### Visualiser les données dans `chronograf`
@ -51,7 +47,7 @@ Après avoir ajouté le serveur (en remplaçant `localhost` proposé par défaut
`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
```
@ -67,7 +63,7 @@ conteneurs, définissez à la racine de votre projet un fichier
`docker-compose.yml` qui contiendra les méthodes de construction et
les paramètres d'exécution.
```
```yaml
version: '2'
services:
influxdb:
@ -86,9 +82,7 @@ services:
Ce fichier est un condensé des options que vous passez habituellement
au `docker run`.
L'exemple ci-dessus est à adapter largement, consultez
<http://docs.docker.com/compose/compose-file/> pour une liste exhaustive des
options que vous pouvez utiliser.
### `version`
Notez toutefois la présence d'une ligne `version` ; il ne s'agit pas de la
version de vos conteneurs, mais de la version du format de fichier
@ -96,14 +90,108 @@ docker-compose qui sera utilisé. Sans indication de version, la version
originale sera utilisée.
Une fois que votre `docker-compose.yml` sera prêt, lancez tout d'abord
`docker-compose build` pour commencer la phase de build de tous les
conteneurs listés dans le fichier.
### `services`
Cette section énumère la liste des services (ou conteneurs) qui seront gérés
par `docker-compose`.
Il peuvent dépendre d'une image à construire localement, dans ce cas ils auront
un fils `build`. Ou ils peuvent utiliser une image déjà existante, dans ce cas
ils auront un fils `image`.
Les autres fils sont les paramètres classiques que l'on va passer à `docker
run`.
### `volumes`
Cette section est le pendant de la commandes `docker volume`.
L'idée est d'éviter de créer des *Data Volume Container* qui ont une partie de
système de fichiers inutile, et de ne garder que l'idée d'emplacement servant
pour du stockage persistant.
On les déclare simplement en leur donnant un nom et un driver comme suit :
```yaml
volumes:
mysql-data:
driver: local
```
Leur utilisation est identique à un *Data Volume Container* : on référence le
nom ainsi que l'emplacement à partager :
```yaml
[...]
mysql:
[...]
volumes:
- mysql-data:/var/lib/mysql
```
### `network`
Cette section est le pendant de la commandes `docker network`.
Par défaut, Docker relie tous les conteneurs sur un bridge et fait du NAT pour
que les conteneur puisse accéder à l'Internet. Mais ce n'est pas le seul mode
possible !
De la même manière que pour les `volumes`, cette section déclare les réseaux
qui pourront être utilisés par les `services`. On pourrait donc avoir :
```yaml
networks:
knotdns-slave-net:
driver: bridge
```
#### Driver `host`
Le driver `host` réutilise la pile réseau de la machine hôte. Le conteneur
pourra donc directement accéder au réseau, sans NAT et sans redirection de
port. Les ports alloués par le conteneur ne devront pas entrer en conflits avec
les ports ouverts par la machine hôte.
#### Driver `null`
Avec le driver `null`, la pile réseau est recréée et aucune interface (autre
que l'interface de loopback) n'est présente. Le conteneur ne peut donc pas
accéder à Internet, ni aux autres conteneur, ...
Lorsque l'on exécute un conteneur qui n'a pas besoin d'accéder au réseau, c'est
le driver à utiliser. Par exemple pour un conteneur dont le but est de vérifier
un backup de base de données.
#### Driver `bridge`
Le driver `bridge` crée un nouveau bridge qui sera partagée entre tous les
conteneurs qui la référencent.
Avec cette configuration, les conteneurs ont accès à une résolution DNS des
noms de conteneurs qui partagent leur bridge. Ainsi, sans avoir à utiliser la
fonctionnalité de `link` au moment du `run`, il est possible de se retrouvé
lié, même après que l'on ait démarré. La résolution se fera dynamiquement.
### Utiliser le `docker-compose.yml`
Consultez <http://docs.docker.com/compose/compose-file/> pour une liste
exhaustive des options que vous pouvez utiliser.
Une fois que votre `docker-compose.yml` est prêt, lancez tout d'abord
`docker-compose build` pour commencer la phase de build de tous les conteneurs
listés dans le fichier.
Une fois le build terminé, vous pouvez lancer la commande suivante et admirer
le résultat :
```
```shell
docker-compose up
```

87
tutorial/2/first.md
View file

@ -4,23 +4,25 @@ 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. La machine (notre première image Docker) contiendra tout le nécessaire
pour faire fonctionner notre service.
réalisait une installation sur une machine classique : en suivant une recette,
sans trop se préoccuper des fonctionnalitées que propose Docker.
La machine (notre première image Docker) contiendra tout le nécessaire pour
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 de conteneur à
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.
Le cache se base principalement sur le contenu de chaque instruction dans le
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
dernière modification de fichier copié ou ajouté). Donc tant qu'une instruction
n'est pas modifiée dans le `Dockerfile`, le cache sera utilisé.
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`.
@ -29,27 +31,25 @@ 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.
\vspace{1.5em}
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`.
Pour profiter du cache, il faut donc placer les étapes les plus génériques (qui
seraient susceptibles d'apparaître dans plusieurs conteneur), en haut du
`Dockerfile`.
Commençons donc notre `Dockerfile` : choisissez une image de base pour
votre `FROM`, et indiquez votre nom avec l'instruction `MAINTAINER`,
pour indiquez que c'est vous qui maintenez ce conteneur (si d'autres
gens ont besoin de vous avertir pour le mettre à jour par exemple).
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).
## `RUN` ou script ?
### InfluxDB
Ensuite vient l'installation d'InfluxDB. Le paquet n'est pas disponible dans
les dépôts. La
[https://docs.influxdata.com/influxdb/v1.0/introduction/installation/#ubuntu-debian](procédure
décrite sur le site) incite à télécharger le paquet mis à disposition puis à
l'installer via `dpkg -i`.
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`.
Deux solutions s'offrent à nous :
@ -59,33 +59,34 @@ Deux solutions s'offrent à nous :
La copie étant définitive (supprimer le fichier ne le supprimera pas des
couches où il a pu exister), on préférera la seconde méthode, malgré que `wget`
restera en déchet. La première méthode aura plus sa place dans un dépôt où les
binaires auront été préalablement compilés, il ne restera plus qu'à les copier
dans le conteneur au bon emplacement.
restera en déchet. La première méthode aura plus sa place dans un dépôt de
projet où les binaires auront été préalablement compilés, il ne restera plus
qu'à les copier dans le conteneur au bon emplacement.
Écrivons une commande `RUN` qui va télécharger la dernière version
d'InfluxDB, qui va l'installer et supprimer le fichier.
\vspace{1em}
À ce stade, nous pouvons déjà terminer le conteneur et tester qu'InfluxDB est
bien utilisable : `EXPOSE`, `CMD`, ...
À ce stade, nous pouvons déjà terminer le conteneur (`EXPOSE`, `CMD`, ...) et
[tester](http://localhost:8083) qu'InfluxDB est bien utilisable.
Il est possible que vous ayez à écraser le fichier de configuration via un
`COPY` (ou de manière plus maligne en utilisant `--volume` au moment du `docker
run`, cela fonctionne pas qu'avec les dossiers). Ou peut-être ferez-vous un
`ENTRYPOINT` ?
run`, cela ne fonctionne pas qu'avec les dossiers !). Ou peut-être ferez-vous
un `ENTRYPOINT` ?
### Telegraf
### `telegraf`
Telegraf est un programme qui permet de collecter des métriques systèmes. Il
travaille de paire avec InfluxDB pour stocker les valeurs.
`telegraf` est un programme qui permet de collecter des métriques systèmes. Il
travaille de paire avec InfluxDB, qu'il utilise pour stocker les valeurs
relevées.
Vous pouvez monitorer les métriques de n'importe quelle machine, simplement en
installant *Telegraf* et en lui indiquant l'emplacement de son serveur
InfluxDB. Nous allons installer *telegraf* sur notre machine à l'aide de la
[https://docs.influxdata.com/telegraf/v1.0/introduction/installation/](documentation).
installant `telegraf` et en lui indiquant l'emplacement de son serveur
InfluxDB. Nous allons installer `telegraf` sur notre machine à l'aide de la
[documentation](https://docs.influxdata.com/telegraf/v1.0/introduction/installation/).
Ces quelques lignes devraient suffir à lancer la collecte, à condition que
votre InfluxDB écoute sur le port 8086 local :
@ -97,10 +98,10 @@ tar xf telegraf-${TELEGRAF_VERSION}_linux_amd64.tar.gz
TELEGRAF_CONFIG_PATH=./telegraf/etc/telegraf/telegraf.conf ./telegraf/usr/bin/telegraf
```
Rendez-vous ensuite dans [http://localhost:8083/](l'interface d'InfluxDB) pour
Rendez-vous ensuite dans [l'interface d'InfluxDB](http://localhost:8083/) pour
voir si la collecte se passe bien.
Dans l'interface sélectionnez la base *telegraf* puis explorez les valeurs :
Dans l'interface sélectionnez la base `telegraf` puis explorez les valeurs :
```sql
SHOW MEASUREMENTS
@ -113,5 +114,15 @@ Laissons tourner `telegraf` afin de constituer un petit historique de valeurs.
## Rendu
Avant de passer à la suite, placez votre `Dockerfile` dans un dossier
`influxdb` (pour le moment il ne contient rien d'autre !).
### Questions
1. Dans quel langage est écrit `telegraf` ?
1. Quelle(s) particularité(s) de ce langage permet de se passer de la variable
`LD_LIBRARY_PATH` au lancement de `telegraf`, alors qu'on ne l'a pas
installé ?
### Éléments à rendre
Avant de passer à la suite, placez votre `Dockerfile` et les éventuels fichiers
annexes dans un dossier `influxdb`.

6
tutorial/2/goodpractices.md
View file

@ -3,12 +3,12 @@
Retour sur les bonnes pratiques
===============================
Pour chacune des bonnes pratiques ci-dessous, vérifiez que vous les respectez
Pour chaque bonne pratique ci-dessous, vérifiez que vous la respectez
bien, faites les modifications nécessaires.
## Utilisez le fichier `.dockerignore`
Dans la plupart des cas, vos Dockerfile seront dans des dossiers contenant
Dans la plupart des cas, vos `Dockerfile` seront dans des dossiers contenant
beaucoup de fichiers qui ne sont pas nécessaire à la construction de votre
conteneur (par exemple, vous pouvez avoir un `Dockerfile` placé à la racine
d'un dépôt git : il va avoir besoin des binaires compilés, mais pas des
@ -159,7 +159,7 @@ CMD ["-g daemon off;"]
(rappelez-vous, il doit être éphémère !). Par exemple, le `Dockerfile` pour
l'image de PostgreSQL possède cet entrypoint :
```
```shell
#!/bin/bash
set -e

35
tutorial/2/installation.md
View file

@ -1,38 +1,11 @@
\newpage
# Installation
## Docker
Ce TP requiert la dernière version de Docker (1.12). Commencez par vérifier que
vous avez bien cette version :
```
42sh$ docker version
Client:
Version: 1.12.1
API version: 1.24
Go version: go1.7
Git commit: 23cf638
Built:
OS/Arch: linux/amd64
Server:
Version: 1.12.1
API version: 1.24
Go version: go1.7
Git commit: 23cf638
Built:
OS/Arch: linux/amd64
```
Si vous n'avez pas une version assez récente, consultez le premier TP pour
savoir comment installer Docker.
Installation
============
## `docker-compose`
Nous allons également avoir besoin de `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
@ -50,7 +23,7 @@ fonctionnera avec la version de Docker qu'ils fournissent.
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

2
tutorial/2/project.md
View file

@ -9,7 +9,7 @@ Amusez-vous à la piscine, il n'y a pas de projet en plus des exercices fait en
TP !
En complément de ce TP, vous pouvez jetez un œil à
[https://docs.docker.com/engine/swarm](Docker Swarm) !
[Docker Swarm](https://docs.docker.com/engine/swarm) !
## Modalité de rendu

13
tutorial/2/supervisor.md
View file

@ -7,7 +7,7 @@ Notre système de monitoring commence enfin à ressembler à quelque chose. Mais
ce serait tellement plus pratique de voir tous ces tableaux de nombres sous
forme de graphiques !
Nous allons pour cela ajouter `chronograf` dans notre conteneur.
Nous allons pour cela ajouter `chronograf` dans notre image.
Avant de modifier votre `Dockerfile`, créez un nouveau dossier de rendu :
`mymonitoring`, dans lequel vous recopierez l'état actuel de notre image
@ -20,14 +20,13 @@ Commençons par compléter la commande d'installation existante pour `influxdb`,
afin d'installer simultanément `chronograf`.
La documentation de la procédure est disponible
[https://docs.influxdata.com/chronograf/v1.0/introduction/installation/](à
cette adresse).
[à cette adresse](https://docs.influxdata.com/chronograf/v1.0/introduction/installation/).
## Script d'init
Lors du dernier TP, nous avons vu que les conteneurs étaient détruits dès que
le premier processus du conteneur (celui qui a le PID 1, à la place d'`init`)
Lors du dernier TP, nous avons vu que les conteneurs s'arrêtaient dès que le
premier processus du conteneur (celui qui a le PID 1, à la place d'`init`)
terminait son exécution, quelque soit le statut de ses éventuels fils.
Pour lancer tous nos daemons, nous avons donc besoin d'écrire un script qui
@ -40,7 +39,7 @@ lance puis attend que les deux deamons aient terminés de s'exécuter.
Pour vérifier que votre conteneur fonctionne correctement, vous pouvez le
lancer :
```
```shell
docker run --rm -p 10000:10000 mymonitoring
```
@ -61,7 +60,7 @@ conteneur qui délivre des pages web), il va être possible de redémarrer le
conteneur automatiquement grâce à la *restart policy* que l'on peut définir au
moment du `docker run` :
```
```shell
docker run -d -p 80:80 --restart=on-failure nginx
```

10
tutorial/2/what.md
View file

@ -1,3 +1,5 @@
\newpage
But du TP
=========
@ -7,10 +9,10 @@ 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.
Nous collecterons les données d'utilisation de votre machine avec
[https://www.influxdata.com/time-series-platform/telegraf/](Telegraf). Ces
[Telegraf](https://www.influxdata.com/time-series-platform/telegraf/). Ces
données seront envoyés vers
[https://www.influxdata.com/time-series-platform/influxdb/](InfluxDB), puis
elles seront affichées sous forme de graphique dans
[https://www.influxdata.com/time-series-platform/chronograf/](Chronograf).
[InfluxDB](https://www.influxdata.com/time-series-platform/influxdb/), puis
elles seront affichées sous forme de graphique grâce à
[Chronograf](https://www.influxdata.com/time-series-platform/chronograf/).
![Dashboard de l'utilisation CPU et mémoire sur Chronograf](chronograf.png)