Split Docker tutorials into basis, orchestration and dockerfiles
This commit is contained in:
parent
2d364556a2
commit
2c48fa7942
36 changed files with 477 additions and 188 deletions
|
|
@ -1,128 +0,0 @@
|
|||
\newpage
|
||||
|
||||
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.
|
||||
|
||||
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 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 du
|
||||
`Dockerfile` (pour les `COPY` et `ADD`, il va aussi regarder la date de
|
||||
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`.
|
||||
|
||||
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).
|
||||
|
||||
|
||||
## `RUN` ou script ?
|
||||
|
||||
### 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`.
|
||||
|
||||
Deux solutions s'offrent à nous :
|
||||
|
||||
* télécharger le paquet hors du conteneur, le copier, puis l'installer.
|
||||
* faire un `RUN` avec toutes ces opérations (sans oublier l'installation
|
||||
préalable de `wget`/`curl`).
|
||||
|
||||
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 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 (`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 ne fonctionne pas qu'avec les dossiers !). Ou peut-être ferez-vous
|
||||
un `ENTRYPOINT` ?
|
||||
|
||||
|
||||
### `telegraf`
|
||||
|
||||
`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
|
||||
[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 :
|
||||
|
||||
```bash
|
||||
TELEGRAF_VERSION=1.0.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
|
||||
```
|
||||
|
||||
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 :
|
||||
|
||||
```sql
|
||||
SHOW MEASUREMENTS
|
||||
SHOW FIELD KEYS
|
||||
SELECT usage_idle FROM cpu WHERE cpu = 'cpu-total' ORDER BY time DESC LIMIT 5
|
||||
```
|
||||
|
||||
Laissons tourner `telegraf` afin de constituer un petit historique de valeurs.
|
||||
|
||||
|
||||
## Rendu
|
||||
|
||||
### 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`.
|
||||
Loading…
Add table
Add a link
Reference in a new issue