86 lines
3.2 KiB
Markdown
86 lines
3.2 KiB
Markdown
|
\newpage
|
||
|
|
||
|
# Premiers pas
|
||
|
|
||
|
Dans un premier temps, nous allons créer une image Docker comme si
|
||
|
l'on réalisait l'installation sur une machine classique : en suivant
|
||
|
une recette. La machine (notre première image Docker) contient tout le
|
||
|
nécessaire pour faire fonctionner notre service.
|
||
|
|
||
|
|
||
|
## 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 à
|
||
|
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 basant principalement sur le contenu de chaque instruction
|
||
|
dans le `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é.
|
||
|
|
||
|
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 fichier (afin de profiter du cache du système de
|
||
|
fichiers au moment de l'exécution du conteneur).
|
||
|
|
||
|
|
||
|
## `apt-get`
|
||
|
|
||
|
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 qu'il faut le mettre à jour par exemple).
|
||
|
|
||
|
|
||
|
## `RUN` ou script ?
|
||
|
|
||
|
### InfluxDB
|
||
|
|
||
|
Ensuite viens l'installation d'InfluxDB. Le paquet n'est pas
|
||
|
disponible dans les dépôts. La
|
||
|
[https://influxdb.com/docs/v0.9/introduction/installation.html](procédure
|
||
|
décrite sur le site) 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. Ou faire un `RUN` avec toutes
|
||
|
ces opérations (sans oublier l'installation de `wget`/`curl`).
|
||
|
|
||
|
La copie étant définitive (supprimer le fichier ne le supprimera pas
|
||
|
des couches où il a pu exister), donc la seconde solution semble
|
||
|
préférable (mais `wget` restera en déchet).
|
||
|
|
||
|
Écrivez 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`, ... Il est possible
|
||
|
que vous ayez à écraser le fichier de configuration via un
|
||
|
`COPY`. Garder la ligne qui vous permet de lancer votre serveur web
|
||
|
dans un coin, en attendant la partie suivante.
|
||
|
|
||
|
|
||
|
### Grafana
|
||
|
|
||
|
Une fois InfluxDB configuré, nous allons avoir la même réflexion avec
|
||
|
Grafana.
|
||
|
|
||
|
De la même manière, téléchargez, installez et supprimez le paquet.
|
||
|
|
||
|
Lors de vos tests, sachez que vous pouvez vous connecter sur grafana avec
|
||
|
l'utilisateur *admin*, mot de passe *admin*.
|