Update docker-advanced
This commit is contained in:
parent
d9c7e92977
commit
d2097908c5
|
|
@ -101,7 +101,7 @@ Puis, lançons *Telegraf* :
|
|||
|
||||
**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
|
||||
<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 :
|
||||
|
|
@ -110,7 +110,6 @@ Et observons ensuite :
|
|||
```shell
|
||||
42sh$ docker container run --rm -it --link mytsdb:influxdb \
|
||||
--entrypoint "/usr/bin/influx" influxdb -host influxdb
|
||||
Connected to http://influxdb:8086 version 1.6.3
|
||||
InfluxDB shell version: 1.6.3
|
||||
> show databases
|
||||
name: databases
|
||||
|
|
@ -151,5 +150,10 @@ 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 :
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -1,3 +1,28 @@
|
|||
\newpage
|
||||
|
||||
Projet et rendu
|
||||
===============
|
||||
|
||||
Projet
|
||||
------
|
||||
|
||||
Réalisez le `docker-compose.yml` permettant de lancer toute notre stack de
|
||||
monitoring, d'un simple :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
42sh$ docker-compose up
|
||||
```
|
||||
</div>
|
||||
|
||||
Vous intégrerez les trois images (`influxdb`, `chronograf` et `telegraf`),
|
||||
mettrez en place les *volumes* et *networks* nécessaire au bon fonctionnement
|
||||
de la stack.
|
||||
|
||||
Le résultat final attendu doit permettre d'afficher dans `chronograf` l'hôte
|
||||
auto-monitoré par la stack, sans plus de configuration.
|
||||
|
||||
|
||||
Modalités de rendu
|
||||
------------------
|
||||
|
||||
|
|
@ -13,9 +38,6 @@ et exclusivement à celle-ci que vous devez envoyer vos rendus. Tout rendu
|
|||
envoyé à une autre adresse et/ou non signé et/ou reçu après la correction ne
|
||||
sera pas pris en compte.
|
||||
|
||||
Par ailleurs, n'oubliez pas de répondre à
|
||||
[l'évaluation du cours](https://www.epitaf.fr/moodle/mod/quiz/view.php?id=33).
|
||||
|
||||
|
||||
Tarball
|
||||
-------
|
||||
|
|
@ -28,7 +50,11 @@ cela dépendra de votre avancée dans le projet) :
|
|||
|
||||
<div lang="en-US">
|
||||
```
|
||||
login_x-TP2/tp/docker-compose.yml
|
||||
login_x-TP2/tp/mymonitoring-stack.yml
|
||||
login_x-TP2/
|
||||
login_x-TP2/tick/
|
||||
login_x-TP2/tick/docker-compose.yml
|
||||
login_x-TP2/tick/...
|
||||
```
|
||||
</div>
|
||||
|
||||
Utilisez la même tarball pour le rendu que pour la partie précédente.
|
||||
|
|
|
|||
|
|
@ -1,16 +1,111 @@
|
|||
## 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
|
||||
parfois, contenir un programme métier avec une fuite mémoire, dans
|
||||
certaines limites : il vaut parfois mieux le tuer et le relancer
|
||||
automatiquement, plutôt que d'attendre que potentiellement un autre
|
||||
processus se fasse tuer à sa place.
|
||||
|
||||
Pour cela, Docker expose tout un arsenal, reposant sur les cgroups du
|
||||
noyau Linux, que l'on verra plus en détail dans un prochain cours.
|
||||
|
||||
### Mémoire
|
||||
|
||||
Comme on peut s'y attendre, il est possible de limiter la mémoire que
|
||||
peut occuper un conteneur avec l'option `-m`/`--memory`.
|
||||
|
||||
|
||||
### CPU
|
||||
|
||||
### Mémoire
|
||||
En ce qui concerne la limitation d'utilisation du CPU, ce n'est pas
|
||||
aussi simple. En effet, on ne peut pas définir le nombre
|
||||
d'instructions par seconde qu'un conteneur est autorisé à consommer.
|
||||
|
||||
### Bande passante
|
||||
On ne peut définir qu'un taux d'utilisation relatif par rapport à
|
||||
l'ensemble du système (ou du groupe de processus auquel il
|
||||
appartient). Ce taux est appliqué par l'ordonnanceur, lorsqu'il
|
||||
détermine la prochaine tâche qui sera exécutée.
|
||||
|
||||
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 défaut, le taux maximal (1024 = 100%) d'utilisation CPU est donné
|
||||
aux nouveaux conteneurs, on peut le réduire en utilisant l'option
|
||||
`-c`/`--cpu-shares` : 512 = 50%, par exemple.
|
||||
|
||||
|
||||
## Sécuriser l'exécution
|
||||
|
||||
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
|
||||
conteneur. Plusieurs mécanismes sont mis en place pour accroître la
|
||||
difficulté du rebond.
|
||||
|
||||
### Capabilities
|
||||
|
||||
Un certain nombre de capabilities Linux sont retirées par Docker au
|
||||
moment de l'exécution du conteneur, on peut utiliser les options
|
||||
`--cap-add` et `--cap-drop` pour respectivement ajouter et retirer une
|
||||
capabilities.
|
||||
|
||||
Notez que l'option `--privileged` ne retire aucune capabilities à
|
||||
l'exécution.
|
||||
|
||||
Nous verrons dans un prochain cours exactement ce que permettent ces
|
||||
capabilities.
|
||||
|
||||
|
||||
### seccomp
|
||||
|
||||
### Capabilities
|
||||
Si les capabilities sont un regroupement grossiers 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
|
||||
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.
|
||||
|
||||
Voici par exemple un fichier de profil seccomp, interdisant
|
||||
l'utilisation de l'appel système `nanosleep(2)` (utilisé notamment par
|
||||
`sleep(1)`) :
|
||||
|
||||
<div lang="en-US">
|
||||
```js
|
||||
{
|
||||
"defaultAction": "SCMP_ACT_ALLOW",
|
||||
"syscalls": [
|
||||
{
|
||||
"names": [
|
||||
"nanosleep"
|
||||
],
|
||||
"action": "SCMP_ACT_ERRNO",
|
||||
"args": [],
|
||||
"comment": "",
|
||||
"includes": {},
|
||||
"excludes": {}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
</div>
|
||||
|
||||
On peut ensuite l'appliquer à un conteneur Docker :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
42sh$ docker container run -it --security-opt seccomp=nanosleep.json ubuntu /bin/bash
|
||||
(cntnr)$ sleep 42
|
||||
sleep: cannot read realtime clock: Operation not permitted
|
||||
```
|
||||
</div>
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
But du TP
|
||||
=========
|
||||
|
||||
Aujourd'hui, nous allons réaliser un système de monitoring, prêt à être déployé
|
||||
Nous allons réaliser un système de monitoring, prêt à être déployé
|
||||
chez un fournisseur de cloud.
|
||||
|
||||
Le résultat attendu d'ici la fin du TP, est un groupe de conteneurs
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user