86 lines
3.4 KiB
Markdown
86 lines
3.4 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 les méthodes
|
|
habituelles, mais tout en écrivant notre recette dans le `Dockerfile`. La
|
|
machine (notre première image Docker) contiendra 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 base 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
|
|
fichiers (afin de profiter du cache du système de fichiers au moment de
|
|
l'exécution du conteneur).
|
|
|
|
\vspace{1.5em}
|
|
|
|
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 vient l'installation d'InfluxDB. Le paquet n'est pas disponible dans
|
|
les dépôts. La
|
|
[procédure décrite sur le site](https://influxdb.com/docs/v0.9/introduction/installation.html)
|
|
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` (ou de manière plus maline en utilisant `--volume` au moment du `docker
|
|
run`, cela fonctionne pas qu'avec les dossiers). 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*.
|