tuto1: orthograf
This commit is contained in:
parent
d8d9365a4b
commit
dfbca22549
20 changed files with 133 additions and 76 deletions
|
|
@ -44,9 +44,9 @@ fonctionnalités de Docker.
|
|||
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`.
|
||||
Ils 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`.
|
||||
|
|
@ -86,8 +86,8 @@ l'emplacement à partager :
|
|||
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 !
|
||||
que les conteneurs puissent 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 :
|
||||
|
|
@ -105,7 +105,7 @@ networks:
|
|||
|
||||
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
|
||||
port. Les ports alloués par le conteneur ne devront pas entrer en conflit avec
|
||||
les ports ouverts par la machine hôte.
|
||||
|
||||
|
||||
|
|
@ -122,7 +122,7 @@ un backup de base de données.
|
|||
|
||||
#### Driver `bridge`
|
||||
|
||||
Le driver `bridge` crée un nouveau bridge qui sera partagée entre tous les
|
||||
Le driver `bridge` crée un nouveau bridge qui sera partagé entre tous les
|
||||
conteneurs qui la référencent.
|
||||
|
||||
Avec cette configuration, les conteneurs ont accès à une résolution DNS des
|
||||
|
|
|
|||
|
|
@ -9,29 +9,29 @@ conteneurs manuellement, de la même manière que nous avons pu le faire avec
|
|||
l'interface d'administration du FIC et MySQL.
|
||||
|
||||
|
||||
## Conteneur central : la base de données
|
||||
## Conteneur central : la base de données
|
||||
|
||||
Le premier conteneur qui doit être lancé est la base de données orientée séries
|
||||
temporelles :
|
||||
temporelles :
|
||||
[InfluxDB](https://www.influxdata.com/time-series-platform/influxdb/).
|
||||
En effet, tous les autres conteneurs ont besoin de cette base de données pour
|
||||
fonctionner correctement\ : il serait impossible à *Chronograf* d'afficher les
|
||||
fonctionner correctement\ : il serait impossible à *Chronograf* d'afficher les
|
||||
données sans base de données, tout comme *Telegraf* ne pourrait écrire les
|
||||
métriques dans une base de données à l'arrêt.
|
||||
|
||||
Afin d'interagir avec les données, InfluxDB expose une
|
||||
[API REST](https://fr.wikipedia.org/wiki/Representational_state_transfer)
|
||||
sur le port 8086. Pour éviter d'avoir plus de configuration à réaliser, nous
|
||||
allons tâcher d'utiliser ce même port pour tester localement :
|
||||
allons tâcher d'utiliser ce même port pour tester localement :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
docker container run -p 8086:8086 -d --name mytsdb influxdb
|
||||
docker container run -p 8086:8086 -d --name mytsdb influxdb:1.8
|
||||
```
|
||||
</div>
|
||||
|
||||
Comme il s'agit d'une API REST, nous pouvons vérifier le bon fonctionnement de
|
||||
notre base de données en appelant :
|
||||
notre base de données en appelant :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
|
|
@ -41,8 +41,18 @@ notre base de données en appelant :
|
|||
```
|
||||
</div>
|
||||
|
||||
Notez que comme nous avons lancé le conteneur en mode détaché (option `-d`),
|
||||
nous ne voyons pas les logs qui sont écrits par le daemon. Pour les voir, il
|
||||
faut utiliser la commande `docker container logs` :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
docker container logs mytsdb
|
||||
```
|
||||
</div>
|
||||
|
||||
Si votre influxdb répond, vous pouvez vous y connecter en utilisant directement
|
||||
le client fourni :
|
||||
le client officiel (le binaire s'appelle `influx`) :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
|
|
@ -60,27 +70,63 @@ _internal
|
|||
Si vous aussi vous voyez la table `_internal`, bravo ! vous pouvez passer à la
|
||||
suite.
|
||||
|
||||
Notez que comme nous avons lancé le conteneur en mode détaché (option `-d`),
|
||||
nous ne voyons pas les logs qui sont écrits par le daemon. Pour les voir, il
|
||||
faut utiliser la commande `docker container logs` :
|
||||
#### Mais quelle était cette commande magique ? {-}
|
||||
|
||||
Oui, prenons quelques minutes pour l'analyser ...
|
||||
|
||||
L'option `--link` permet de lier deux conteneurs. Ici nous souhaitons lancer un
|
||||
nouveau conteneur pour notre client, en ayant un accès réseau au conteneur
|
||||
`mytsdb` que nous avons créé juste avant. L'option `--link` prend en argument
|
||||
le nom d'un conteneur en cours d'exécution (ici `mytsdb`, nom que l'on a
|
||||
attribué à notre conteneur exécutant la base de données influxdb via l'option
|
||||
`--name`), après les `:`, on précise le nom d'hôte que l'on souhaite attribuer
|
||||
à cette liaison, au sein de notre nouveau conteneur.
|
||||
|
||||
`influx -host influxdb` que nous avons placé après le nom de l'image,
|
||||
correspond à la première commande que l'on va exécuter dans notre conteneur, à
|
||||
la place du daemon `influxdb`. Ici nous voulons exécuter le client, il
|
||||
s'appelle `influx`, auquel nous ajoutons le nom de l'hôte dans lequel nous
|
||||
souhaitons nous connecter : grâce à l'option `--link`, le nom d'hôte à utiliser
|
||||
est `influxdb`.
|
||||
|
||||
L'option `--link` peut être particulièrement intéressante lorsque l'on souhaite
|
||||
sauvegarder une base, car en plus de définir un nom d'hôte, cette option fait
|
||||
hériter le nouveau conteneur des variables d'environnement du conteneur
|
||||
auquel elle est liée : on a donc accès aux `$MYSQL_USER`,
|
||||
`$MYSQL_PASSWORD`, ...
|
||||
|
||||
On aurait aussi pu créer un réseau entre nos deux conteneurs (via `docker
|
||||
network`), ou bien encore, on aurait pu exécuter notre client `influx`
|
||||
directement dans le conteneur de sa base de données :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
docker container logs mytsdb
|
||||
42sh$ docker container exec mytsdb influx -execute "show databases"
|
||||
name: databases
|
||||
name
|
||||
---------------
|
||||
_internal
|
||||
```
|
||||
</div>
|
||||
|
||||
Dans ce dernier exemple, nous n'avons pas besoin de préciser l'hôte, car
|
||||
`influx` va tenter `localhost` par défaut, et puisque nous lançons la commande
|
||||
dans notre conteneur `mytsdb`, il s'agit bien du conteneur où s'exécute
|
||||
localement `influxdb`.
|
||||
|
||||
\hspace{2em}**Exercice :** Ajoutez à la ligne de commande de lancement du
|
||||
conteneur les bon(s) volume(s) qui permettront de ne pas perdre les données
|
||||
d'influxDB si nous devions redémarrer le conteneur. Aidez-vous pour cela de la
|
||||
[documentation du conteneur](https://hub.docker.com/_/influxdb).
|
||||
|
||||
#### Exercice : {-}
|
||||
|
||||
Ajoutez à la ligne de commande de lancement du conteneur les bon(s) volume(s)
|
||||
qui permettront de ne pas perdre les données d'influxDB si nous devions
|
||||
redémarrer le conteneur. Aidez-vous pour cela de la [documentation du
|
||||
conteneur](https://hub.docker.com/_/influxdb).
|
||||
|
||||
|
||||
## Collecter les données locales
|
||||
|
||||
Tentons maintenant de remplir notre base de données avec les métriques du
|
||||
système. Pour cela, on commence par télécharger *Telegraf* :
|
||||
système. Pour cela, on commence par télécharger *Telegraf* :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
|
|
@ -89,7 +135,7 @@ tar xzv -C /tmp
|
|||
```
|
||||
</div>
|
||||
|
||||
Puis, lançons *Telegraf* :
|
||||
Puis, lançons *Telegraf* :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
|
|
@ -98,17 +144,18 @@ cd /tmp/telegraf
|
|||
```
|
||||
</div>
|
||||
|
||||
**Remarque :** La configuration par défaut va collecter les données de la
|
||||
machine locale et les envoyer sur le serveur situé à
|
||||
<http://localhost:8086>. Ici, cela fonctionne parce que l'on a fait en sorte de
|
||||
rediriger le port de notre conteneur sur notre machine locale (option `-p`).
|
||||
#### Remarque : {-}
|
||||
|
||||
Et observons ensuite :
|
||||
La configuration par défaut va collecter les données de la machine locale et
|
||||
les envoyer sur le serveur situé à <http://localhost:8086>. Ici, cela
|
||||
fonctionne parce que l'on a fait en sorte de rediriger le port de notre
|
||||
conteneur sur notre machine locale (option `-p`).
|
||||
|
||||
Et observons ensuite :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
42sh$ docker container run --rm -it --link mytsdb:influxdb --entrypoint "/usr/bin/influx" \
|
||||
influxdb -host influxdb
|
||||
42sh$ docker container run --rm -it --link mytsdb:zelda influxdb:1.8 influx -host zelda
|
||||
InfluxDB shell version: 1.8.9
|
||||
> show databases
|
||||
name: databases
|
||||
|
|
@ -135,13 +182,15 @@ system
|
|||
```
|
||||
</div>
|
||||
|
||||
La nouvelle base a donc bien été créé et tant que nous laissons *Telegraf*
|
||||
La nouvelle base a donc bien été créée et tant que nous laissons *Telegraf*
|
||||
lancé, celui-ci va régulièrement envoyer des métriques de cette machine.
|
||||
|
||||
|
||||
## Afficher les données collectées
|
||||
|
||||
**Exercice :** À vous de jouer pour lancer le conteneur
|
||||
#### Exercice : {-}
|
||||
|
||||
À vous de jouer pour lancer le conteneur
|
||||
[*Chronograf*](https://store.docker.com/images/chronograf).
|
||||
|
||||
L'interface de *Chronograf* est disponible sur le port 8888.
|
||||
|
|
@ -149,9 +198,11 @@ L'interface de *Chronograf* est disponible sur le port 8888.
|
|||
Consultez la [documentation du conteneur](https://hub.docker.com/_/chronograf)
|
||||
si besoin.
|
||||
|
||||
**Attention :** la page d'accueil est vide au démarrage, pour savoir si vous avez
|
||||
réussi, rendez-vous sous l'onglet *Hosts*, le nom de votre machine devrait y
|
||||
apparaître. En cliquant dessus vous obtiendrez des graphiques similaires à ceux
|
||||
ci-dessous :
|
||||
#### Attention : {-}
|
||||
|
||||
la page d'accueil est vide au démarrage, pour savoir si vous avez réussi,
|
||||
rendez-vous sous l'onglet *Hosts*, le nom de votre machine devrait y
|
||||
apparaître. En cliquant dessus, vous obtiendrez des graphiques similaires à
|
||||
ceux ci-dessous :
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,7 @@
|
|||
## Limiter les ressources
|
||||
\newpage
|
||||
|
||||
Limiter les ressources
|
||||
======================
|
||||
|
||||
Lorsque l'on gère un environnement de production, on souhaite bien
|
||||
évidemment éviter tout déni de service autant que possible. Ou
|
||||
|
|
@ -31,11 +34,10 @@ Ainsi, lorsque la machine n'est pas chargée, que le processeur n'a pas
|
|||
constamment du travail à effectuer, l'ordonnanceur ne va pas empêcher
|
||||
une tâche très consommatrice en puissance de calcul de s'exécuter.
|
||||
|
||||
Par contre, sous une forte charge, si l'on défini que notre conteneur
|
||||
exécutant un cpuburn ne peut pas utiliser plus de 50% des ressources
|
||||
de la machine, ce pourcentage ne pourra effectivement pas être
|
||||
dépassé, l'ordonnanceur privilégiant alors les autres processus du
|
||||
système.
|
||||
Par contre, sous une forte charge, si l'on définit que notre conteneur
|
||||
exécutant un cpuburn ne peut pas utiliser plus de 50% des ressources de la
|
||||
machine, ce pourcentage ne pourra effectivement pas être dépassé,
|
||||
l'ordonnanceur privilégiant alors les autres processus du système.
|
||||
|
||||
Par défaut, le taux maximal (1024 = 100%) d'utilisation CPU est donné
|
||||
aux nouveaux conteneurs, on peut le réduire en utilisant l'option
|
||||
|
|
@ -46,7 +48,7 @@ aux nouveaux conteneurs, on peut le réduire en utilisant l'option
|
|||
|
||||
En plus des dénis de service, on peut également vouloir se protéger
|
||||
contre des attaques provenant des conteneurs eux-mêmes. On n'est pas à
|
||||
l'abri d'une vulnérabilité dans un des services exécuté dans un
|
||||
l'abri d'une vulnérabilité dans un des services exécutés dans un
|
||||
conteneur. Plusieurs mécanismes sont mis en place pour accroître la
|
||||
difficulté du rebond.
|
||||
|
||||
|
|
@ -66,12 +68,12 @@ capabilities.
|
|||
|
||||
### seccomp
|
||||
|
||||
Si les capabilities sont un regroupement grossiers de fonctionnalités
|
||||
Si les capabilities sont un regroupement grossier de fonctionnalités
|
||||
du noyau, seccomp est un filtre que l'on peut définir pour chaque
|
||||
appel système. Liste blanche, liste noire, tout est possible.
|
||||
|
||||
Docker filtre notamment tous les appels systèmes qui pourraient
|
||||
débordés à l'extérieur du conteneur : il n'est par exemple pas
|
||||
déborder à l'extérieur du conteneur : il n'est par exemple pas
|
||||
possible de changer l'heure dans un conteneur, car il n'y a
|
||||
aujourd'hui aucun mécanisme pour isoler les visions des dates d'un
|
||||
conteneur à l'autre.
|
||||
|
|
|
|||
|
|
@ -6,7 +6,8 @@ Mise en place
|
|||
Dans la première partie du TP, nous avons installé l'environnement Docker
|
||||
principal, qui inclut le client, le daemon et toute sa machinerie. Mais le
|
||||
projet Docker propose de nombreuses autres ressources, souvent directement
|
||||
trouvée dans les usages de la communauté, et parfois même approprié par Docker.
|
||||
trouvées dans les usages de la communauté, et parfois même appropriées par
|
||||
Docker.
|
||||
|
||||
|
||||
## `docker-compose`
|
||||
|
|
|
|||
|
|
@ -20,5 +20,5 @@ abstract: |
|
|||
clef PGP. Pensez à
|
||||
[me](https://keys.openpgp.org/search?q=nemunaire%40nemunai.re)
|
||||
faire signer votre clef et n'hésitez pas à [faire signer la
|
||||
votre](https://www.meetup.com/fr/Paris-certification-de-cles-PGP-et-CAcert/).
|
||||
vôtre](https://www.meetup.com/fr/Paris-certification-de-cles-PGP-et-CAcert/).
|
||||
...
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue