diff --git a/tutorial/docker-advanced/manual.md b/tutorial/docker-advanced/manual.md index 99df211..6b9120c 100644 --- a/tutorial/docker-advanced/manual.md +++ b/tutorial/docker-advanced/manual.md @@ -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 +. 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 : + ![Résultat obtenu](chronograf_latest.png) diff --git a/tutorial/docker-advanced/rendu.md b/tutorial/docker-advanced/rendu.md index 27e0b85..cc49664 100644 --- a/tutorial/docker-advanced/rendu.md +++ b/tutorial/docker-advanced/rendu.md @@ -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 : + +
+``` + 42sh$ docker-compose up +``` +
+ +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) :
``` - 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/... ```
+ +Utilisez la même tarball pour le rendu que pour la partie précédente. diff --git a/tutorial/docker-advanced/security.md b/tutorial/docker-advanced/security.md index 8460224..d5602b0 100644 --- a/tutorial/docker-advanced/security.md +++ b/tutorial/docker-advanced/security.md @@ -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)`) : + +
+```js +{ + "defaultAction": "SCMP_ACT_ALLOW", + "syscalls": [ + { + "names": [ + "nanosleep" + ], + "action": "SCMP_ACT_ERRNO", + "args": [], + "comment": "", + "includes": {}, + "excludes": {} + } + ] +} +``` +
+ +On peut ensuite l'appliquer à un conteneur Docker : + +
+``` + 42sh$ docker container run -it --security-opt seccomp=nanosleep.json ubuntu /bin/bash + (cntnr)$ sleep 42 + sleep: cannot read realtime clock: Operation not permitted +``` +
diff --git a/tutorial/docker-advanced/what.md b/tutorial/docker-advanced/what.md index 46b5de0..8c58945 100644 --- a/tutorial/docker-advanced/what.md +++ b/tutorial/docker-advanced/what.md @@ -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