TP2 ready
This commit is contained in:
parent
f0a7e085fe
commit
5fa883f6ae
8 changed files with 184 additions and 108 deletions
|
|
@ -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
|
||||
```
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue