Use lang en-US for samples
This commit is contained in:
parent
f2f93440a7
commit
13dadd8c59
@ -77,6 +77,7 @@ Sous Linux, les attributs sont regroupés dans des espaces de noms :
|
||||
|
||||
Par exemple, on peut définir un attribut sur un fichier comme cela :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
42sh$ echo 'Hello World!' > toto
|
||||
42sh$ setfattr -n user.foo -v bar toto
|
||||
@ -84,9 +85,11 @@ Par exemple, on peut définir un attribut sur un fichier comme cela :
|
||||
# file: toto
|
||||
user.foo="bar"
|
||||
```
|
||||
</div>
|
||||
|
||||
Encore plus fort, vous pouvez utiliser les ACL POSIX :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
42sh$ sudo chown root:root toto && sudo chmod o-r toto
|
||||
42sh$ cat toto
|
||||
@ -95,17 +98,20 @@ cat: toto: Permission denied
|
||||
42sh$ cat toto
|
||||
Hello World!
|
||||
```
|
||||
</div>
|
||||
|
||||
Bien que les droits UNIX traditionnels ne vous donnent pas accès au fichier,
|
||||
les ACL POSIX vous autorisent à le lire.
|
||||
|
||||
Vous pouvez voir ces attributs avec la commande :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
42sh$ getfattr -d -m "^system" toto
|
||||
# file: toto
|
||||
system.posix_acl_access=0sgAAEAD/////AgAEOgDAEAA/////xAABAD////8=
|
||||
```
|
||||
</div>
|
||||
|
||||
|
||||
### `ping`
|
||||
@ -119,18 +125,22 @@ l'utilisation de cet attribut auquel on accroîtrait l'ensemble des
|
||||
|
||||
Si votre distribution profite de ces attributs étendus, vous devriez obtenir :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
42sh$ getfattr -d -m "^security" $(which ping)
|
||||
# file: bin/ping
|
||||
security.capability=0sAQAAAgAgAAAAAAAAAAAAAAAAAAA=
|
||||
```
|
||||
</div>
|
||||
|
||||
Ou, dans sa version plus lisible :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
42sh$ getcap $(which ping)
|
||||
/bin/ping = cap_net_raw+ep
|
||||
```
|
||||
</div>
|
||||
|
||||
|
||||
## Exercice : visualisateur de capabilities d'un processus
|
||||
@ -138,6 +148,7 @@ Ou, dans sa version plus lisible :
|
||||
Écrivons maintenant un programme permettant de voir les *capabilities*
|
||||
d'un processus :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
42sh$ ./view_caps 1
|
||||
cap_user_header_t
|
||||
@ -165,6 +176,7 @@ permitted: 0xffffffff
|
||||
CAP_DAC_READ_SEARCH
|
||||
inheritable: 0x0
|
||||
```
|
||||
</div>
|
||||
|
||||
Astuces : `capget(2)`, X-macros, ...
|
||||
|
||||
|
||||
@ -22,10 +22,12 @@ En fonction de la configuration de votre système, il est possible que les
|
||||
pas de dossier `freezer` ou si celui-ci est vide, montez-le en suivant la
|
||||
procédure suivante :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
mkdir /sys/fs/cgroup/freezer/
|
||||
mount -t cgroup -o freezer none /sys/fs/cgroup/freezer/
|
||||
```
|
||||
</div>
|
||||
|
||||
Cette dernière commande monte le groupe de processus racine, pour le *cgroup*
|
||||
freezer. Tous les dossiers contenu dans cette racine sont donc des
|
||||
@ -40,10 +42,12 @@ groupe.
|
||||
Pour créer un groupe, il suffit de créer un nouveau dossier dans un groupe
|
||||
existant, par exemple la racine :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
mkdir /sys/fs/cgroup/freezer/virli/
|
||||
ls /sys/fs/cgroup/freezer/virli/
|
||||
```
|
||||
</div>
|
||||
|
||||
Nous avons maintenant un nouveau groupe de processus `virli` dans le *cgroup*
|
||||
Freezer. Comme il s'agit d'une hiérarchie, le groupe `virli` hérite des
|
||||
@ -60,9 +64,11 @@ PID : `echo $$`.
|
||||
La liste des processus rattachés à un *cgroup* se trouve dans le fichier `task`
|
||||
du groupe. Pour ajouter une tâche à ce groupe, cela se passe de cette manière :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
echo $PID > /sys/fs/cgroup/freezer/virli/tasks
|
||||
```
|
||||
</div>
|
||||
|
||||
Il faut ici remplacer `$PID` par le PID du shell que l'on a relevé juste avant.
|
||||
|
||||
@ -91,23 +97,29 @@ consulter
|
||||
Faisons exécuter à notre interpréteur une commande pour voir effectivement
|
||||
l'exécution s'arrêter. Si vous manquez d'inspiration, utilisez :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
for i in $(seq 9999); do echo -n $i; sleep .1; echo -n " - "; sleep .1; done
|
||||
```
|
||||
</div>
|
||||
|
||||
Maintenant, nous avons donné l'ordre au noyau de ne plus allouer de temps de
|
||||
calcul à notre shell et ses fils :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
echo FROZEN > /sys/fs/cgroup/freezer/virli/freezer.state
|
||||
```
|
||||
</div>
|
||||
|
||||
À cet instant, vous devriez voir votre compteur s'arrêter. Pour reprendre
|
||||
l'exécution :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
echo THAWED > /sys/fs/cgroup/freezer/virli/freezer.state
|
||||
```
|
||||
</div>
|
||||
|
||||
|
||||
## Exercice : script de monitoring
|
||||
@ -121,16 +133,20 @@ données des statistiques issues des *cgroup*s.
|
||||
Commençons par lancer le conteneur Docker d'InfluxDB (pour éviter de
|
||||
l'installer sur notre machine) :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
docker run -d -p 8086:8086 -p 8083:8083 influxdb
|
||||
```
|
||||
</div>
|
||||
|
||||
Il nous faut ensuite créer une base de données pour y stocker les métriques,
|
||||
rendez-vous à <http://localhost:8083/> puis entrez la requête :
|
||||
|
||||
<div lang="en-US">
|
||||
```sql
|
||||
CREATE DATABASE metrics;
|
||||
```
|
||||
</div>
|
||||
|
||||
|
||||
### Monitoring instantané vers la console
|
||||
@ -157,17 +173,21 @@ par défaut par votre système. Si vous êtes dans ce cas, essayez d'ajouter
|
||||
Maintenant, envoyons nos données vers la base
|
||||
<https://docs.influxdata.com/influxdb/v1.0/guides/writing_data/> :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
curl -i -XPOST 'http://localhost:8086/write?db=metrics' --data-binary \
|
||||
"$my_cgroup_name memory.usage_in_bytes=$(cat .../my_cgroup_name/memory.usage_in_bytes)"
|
||||
```
|
||||
</div>
|
||||
|
||||
Pour vérifier que les données ont bien été ajoutées, nous pouvons effectuer la
|
||||
requête suivante dans l'interface web d'InfluxDB :
|
||||
|
||||
<div lang="en-US">
|
||||
```sql
|
||||
SELECT * from "$my_cgroup_name";
|
||||
```
|
||||
</div>
|
||||
|
||||
|
||||
### Monitorer davantage de données
|
||||
@ -195,10 +215,12 @@ privilèges particuliers.
|
||||
|
||||
#### Exemple
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
42sh$ sudo ./monitor_init my_cgroup_name
|
||||
42sh$ ./monitor my_cgroup_name memhog 500
|
||||
```
|
||||
</div>
|
||||
|
||||
|
||||
## Fixer des limites
|
||||
|
||||
@ -13,9 +13,11 @@ vu comme étant la racine du système de fichiers. En anglais : *change root*:
|
||||
Pour se créer un environnement afin de changer notre racine, il va falloir
|
||||
commencer par créer le dossier de notre nouvelle racine :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
mkdir newroot
|
||||
```
|
||||
</div>
|
||||
|
||||
### `busybox`
|
||||
|
||||
@ -25,10 +27,12 @@ dynamiques. Il se suffit donc à lui-même dans un chroot (dans lequel on ne peu
|
||||
pas accéder aux bibliothèques du système, il faudrait toutes les copier à la
|
||||
main).
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
cp $(which busybox) newroot/
|
||||
chroot newroot /busybox ash
|
||||
```
|
||||
</div>
|
||||
|
||||
|
||||
### `debootstrap`
|
||||
@ -38,9 +42,11 @@ Debian et ses dérivés. Il permet d'installer dans un dossier (en général, ce
|
||||
dossier correspond au point de montage de la nouvelle racine choisie par
|
||||
l'utilisateur lors de l'installation) le système de base.
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
debootstrap jessie newroot/ http://httpredir.debian.org/debian/
|
||||
```
|
||||
</div>
|
||||
|
||||
`pacstrap` est le programme équivalent pour Archlinux.
|
||||
|
||||
@ -50,10 +56,12 @@ debootstrap jessie newroot/ http://httpredir.debian.org/debian/
|
||||
Les distributions « à l'ancienne » proposent encore de télécharger leur système
|
||||
de base sous forme de tarball :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
wget ftp://gentoo.mirrors.ovh.net/gentoo-distfiles/releases/amd64/autobuilds/20160929/stage3-amd64-20160929.tar.bz2
|
||||
tar xpf stage3-amd64-*.tar.bz2 -C newroot/
|
||||
```
|
||||
</div>
|
||||
|
||||
L'avantage de télécharger l'archive de Gentoo est que l'on a déjà `gcc` dans un
|
||||
environnement qui tient dans 300 MB.
|
||||
@ -63,24 +71,30 @@ environnement qui tient dans 300 MB.
|
||||
|
||||
Écrivons maintenant un programme dont le seul but est de s'échaper du `chroot`:
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
make escape
|
||||
echo bar > ../foo
|
||||
chroot .
|
||||
```
|
||||
</div>
|
||||
|
||||
Dans le nouvel environnement, vous ne devriez pas pouvoir faire :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
cat ../foo
|
||||
```
|
||||
</div>
|
||||
|
||||
Mais une fois votre programme `escape` exécuté, vous devriez pouvoir !
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
./escape
|
||||
cat /path/to/foo
|
||||
```
|
||||
</div>
|
||||
|
||||
|
||||
## Rendu
|
||||
|
||||
@ -9,6 +9,7 @@ Ce TP requiert un noyau Linux, dans sa version 3.8 au minimum. Il doit de plus
|
||||
être compilé avec les options suivantes (lorsqu'elles sont disponibles pour
|
||||
votre version) :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
General setup --->
|
||||
[*] Control Group support --->
|
||||
@ -38,6 +39,7 @@ Device Drivers --->
|
||||
<M> MAC-VLAN support
|
||||
<M> Virtual ethernet pair device
|
||||
```
|
||||
</div>
|
||||
|
||||
|
||||
### Vérification via `menuconfig`
|
||||
@ -53,9 +55,11 @@ disponible sur la page d'accueil de <https://kernel.org>.
|
||||
|
||||
Dans les sources, on affiche la liste des options avec la commande :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
make menuconfig
|
||||
```
|
||||
</div>
|
||||
|
||||
|
||||
### Vérification via `/boot/config-xxx`
|
||||
@ -69,6 +73,7 @@ fichiers initial (`initramfs-xxx`) et des symboles de débogage
|
||||
Ce fichier répertorie toutes les options qui ont été activées. Par rapport à
|
||||
l'arbre présenté ci-dessus, vous devriez trouver :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
CONFIG_CGROUPS=y
|
||||
CONFIG_CGROUP_FREEZER=y
|
||||
@ -96,6 +101,7 @@ CONFIG_NETDEVICES=y
|
||||
CONFIG_MACVLAN=m
|
||||
CONFIG_VETH=m
|
||||
```
|
||||
</div>
|
||||
|
||||
|
||||
### Vérification via `/proc/config.gz`
|
||||
|
||||
@ -22,6 +22,7 @@ n'est pas forcément une mauvaise solution.
|
||||
Réduisez au maximum les capabilities, de telle sorte qu'il ne soit pas possible
|
||||
de faire un ping dans l'environnement restreint :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
42sh# ping 8.8.8.8
|
||||
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
|
||||
@ -39,6 +40,7 @@ rtt min/avg/max/mdev = 3.931/3.954/3.978/0.067 ms
|
||||
bash# ping 8.8.8.8
|
||||
ping: icmp open socket: Permission denied
|
||||
```
|
||||
</div>
|
||||
|
||||
Astuces : `prctl(2)`, `capabilities(7)`, `capget(2)`, `capset(2)`, ...
|
||||
|
||||
|
||||
@ -20,8 +20,10 @@ placer à la racine de votre rendu.
|
||||
|
||||
Voici une arborescence type :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
login_x-TP3/questions.txt
|
||||
login_x-TP3/mymoulette/README
|
||||
login_x-TP3/mymoulette/...
|
||||
```
|
||||
</div>
|
||||
|
||||
@ -10,10 +10,12 @@ unique partant d'une racine[1] et où l'on peut placer au sein de son arborescen
|
||||
des points de montage. Ainsi, l'utilisateur définit généralement deux points de
|
||||
montage :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
/dev/sda1 on / type ext4 (rw,relatime,data=ordered)
|
||||
/dev/sda3 on /home type ext4 (rw,relatime,data=ordered)
|
||||
```
|
||||
</div>
|
||||
|
||||
Dans ce schéma, la racine correspond à la première partition du premier disque,
|
||||
et les fichiers des utilisateurs sont sur la troisième partition du premier
|
||||
@ -72,9 +74,11 @@ Après avoir exécuté le script, nous devrions avoir :
|
||||
|
||||
Voici un exemple d'utilisation :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
42sh$ ./rev_kdb_leds.sh input20
|
||||
```
|
||||
</div>
|
||||
|
||||
|
||||
### `procinfo`
|
||||
@ -82,6 +86,7 @@ Voici un exemple d'utilisation :
|
||||
Explorons le pseudo système de fichiers `/proc` pour écrire un script qui va
|
||||
afficher des informations sur un processus donné :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
42sh$ ./procinfo $$
|
||||
PID: 4242
|
||||
@ -117,6 +122,7 @@ pid:[4026531836]
|
||||
user:[4026531837]
|
||||
uts:[4026531838]
|
||||
```
|
||||
</div>
|
||||
|
||||
## Rendu
|
||||
|
||||
|
||||
@ -44,12 +44,14 @@ intégralité : vous ne pourrez pas monter les partitions indiquées par le
|
||||
Pour que tout cela fonctionne, vous avez besoin au préalable d'exécuter les
|
||||
commandes suivantes :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
cd newroot
|
||||
mount --bind /dev dev
|
||||
mount --bind /proc proc
|
||||
mount --bind /sys sys
|
||||
```
|
||||
</div>
|
||||
|
||||
En se `chroot`ant à nouveau dans cette nouvelle racine, nous voyons que tous
|
||||
nos outils fonctionnent comme prévu.
|
||||
@ -65,12 +67,14 @@ monter au nouvel emplacement le système de fichier ainsi que tous les points
|
||||
d'accroche qu'il contient, il faut utiliser `--rbind`. Il serait donc plus
|
||||
correct de lancer :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
cd newroot
|
||||
mount --rbind /dev dev
|
||||
mount -t proc none proc
|
||||
mount --rbind /sys sys
|
||||
```
|
||||
</div>
|
||||
|
||||
|
||||
## Les montages parfumés
|
||||
@ -89,6 +93,7 @@ partage (on parle de *peer group*).
|
||||
|
||||
Essayons de voir à quoi cela correspond avec l'exemple suivant :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
# Création de nos répertoires de travail
|
||||
cd /mnt
|
||||
@ -100,14 +105,17 @@ mount --make-shared /tmp
|
||||
# Duplication de l'accroche, sans s'occuper des éventuels sous-accroches
|
||||
mount --bind /tmp /mnt/test-shared
|
||||
```
|
||||
</div>
|
||||
|
||||
Si l'on attache un nouveau point de montage dans `/tmp` ou dans
|
||||
`/mnt/test-shared`, avec la politique `shared`, l'accroche sera propagée :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
mkdir /mnt/test-shared/toto
|
||||
mount -t tmpfs none /mnt/test-shared/toto
|
||||
```
|
||||
</div>
|
||||
|
||||
Un coup de `findmnt` nous montre l'existence de deux nouveaux points de
|
||||
montages. À `/mnt/test-shared/toto`, mais également à `/tmp/toto`.
|
||||
@ -119,6 +127,7 @@ De la même manière que lorsque la propagation est partagée, cette politique
|
||||
propagera, mais seulement dans un sens. Le point de montage déclaré comme
|
||||
esclave ne propagera pas ses nouveaux points de montage.
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
# Suite de l'exemple précédent
|
||||
cd /mnt
|
||||
@ -130,20 +139,25 @@ mount --bind /mnt/test-shared /mnt/test-slave
|
||||
# On rend notre dossier esclave
|
||||
mount --make-slave /mnt/test-slave
|
||||
```
|
||||
</div>
|
||||
|
||||
Si l'on effectue un montage dans `/mnt/test-shared` :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
mkdir /mnt/test-shared/foo
|
||||
mount -t tmpfs none /mnt/test-shared/foo
|
||||
```
|
||||
</div>
|
||||
|
||||
Le point de montage apparaît bien sous `/mnt/test-slave/foo`. Par contre :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
mkdir /mnt/test-slave/bar
|
||||
mount -t tmpfs none /mnt/test-slave/bar
|
||||
```
|
||||
</div>
|
||||
|
||||
Le nouveau point de montage n'est pas propagé dans `/mnt/test-shared/bar`.
|
||||
|
||||
@ -155,25 +169,31 @@ C'est le mode le plus simple : ici les points de montage ne sont pas propagés.
|
||||
Pour forcer un point d'accroche a ne pas propager et à ne pas recevoir de
|
||||
propagation, on utilise l'option suivante :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
mount --make-private mountpoint
|
||||
```
|
||||
</div>
|
||||
|
||||
|
||||
### non-attachable -- *unbindable mount*
|
||||
|
||||
Ce mode interdira tout tentative d'attache à un autre endroit.
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
mount --make-unbindable /mnt/test-slave
|
||||
```
|
||||
</div>
|
||||
|
||||
Il ne sera pas possible de faire :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
mkdir /mnt/test-unbindable
|
||||
mount --bind /mnt/test-slave /mnt/test-unbindable
|
||||
```
|
||||
</div>
|
||||
|
||||
|
||||
### Parfums récursifs
|
||||
@ -182,12 +202,14 @@ Les options que nous venons de voir s'applique sur un point de montage. Il
|
||||
existe les mêmes options pour les appliquer en cascade sur les points d'attache
|
||||
contenu dans le sous-arbre :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
mount --make-rshared mountpoint
|
||||
mount --make-rslave mountpoint
|
||||
mount --make-rprivate mountpoint
|
||||
mount --make-runbindable mountpoint
|
||||
```
|
||||
</div>
|
||||
|
||||
|
||||
## `bind` de dossiers et de fichiers
|
||||
@ -212,15 +234,19 @@ emplacement soit prévenu du changement.
|
||||
|
||||
On utilise pour cela l'option `--move` de `mount(8)` :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
mount --move olddir newdir
|
||||
```
|
||||
</div>
|
||||
|
||||
Par exemple :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
mount --move /dev /newroot/dev
|
||||
```
|
||||
</div>
|
||||
|
||||
Il est courant de faire appel à cette option lorsque l'on souhaite changer la
|
||||
racine de notre système de fichier : passer de l'initramfs au système au
|
||||
|
||||
@ -40,10 +40,12 @@ ne se trouvait pas à la racine d'une partition au moment du basculement.
|
||||
|
||||
Si vous n'avez pas de partition à disposition, vous pouvez utiliser un `tmpfs` :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
mkdir /mnt/newroot
|
||||
mount -t tmpfs none /mnt/newroot
|
||||
```
|
||||
</div>
|
||||
|
||||
Placez ensuite dans cette nouvelle racine le système de votre choix (cf. le TP
|
||||
précédent pour les différentes méthodes et liens).
|
||||
@ -72,9 +74,11 @@ devoir nous isoler sur :
|
||||
|
||||
Isolons-nous :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
unshare -p -m -f --mount-proc
|
||||
```
|
||||
</div>
|
||||
|
||||
|
||||
### Dissocier la propagation des démontages
|
||||
@ -86,9 +90,11 @@ mount*.
|
||||
Commençons donc par étiqueter tous nos points de montage (de ce *namespace*),
|
||||
comme esclave :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
mount --make-rslave /
|
||||
```
|
||||
</div>
|
||||
|
||||
|
||||
### Démonter tout !
|
||||
@ -125,6 +131,8 @@ Une fois le pivot effectué, on peut démonter l'ancienne racine.
|
||||
Pour lancer la première commande dans la nouvelle racine, on passe généralement
|
||||
par :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
exec chroot / command
|
||||
```
|
||||
</div>
|
||||
|
||||
@ -121,6 +121,7 @@ nouveaux *namespaces* et placer le processus dedans.
|
||||
Par exemple, nous pouvons modifier sans crainte le nom de notre machine, si
|
||||
nous sommes passé dans un autre *namespace* `UTS` :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
42sh# hostname --fqdn
|
||||
koala.zoo.paris
|
||||
@ -134,6 +135,7 @@ bash# exit
|
||||
42sh# hostname --fqdn
|
||||
koala.zoo.paris
|
||||
```
|
||||
</div>
|
||||
|
||||
Nous avons pu ici modifier le nom de machine, sans que cela n'affecte notre
|
||||
machine hôte.
|
||||
@ -167,6 +169,7 @@ Les mêmes `flags` sont utilisés lors des appels à `unshare(2)` ou `setns(2)`.
|
||||
Pour créer un nouveau processus qui sera à la fois dans un nouvel *namespace*
|
||||
réseau et dans un nouveau *namespace* CGroup, on écrirait un code similaire à :
|
||||
|
||||
<div lang="en-US">
|
||||
```c
|
||||
#include <sched.h>
|
||||
|
||||
@ -180,6 +183,7 @@ pid_t pid = clone(do_execvp,
|
||||
clone_flags,
|
||||
&args);
|
||||
```
|
||||
</div>
|
||||
|
||||
Le premier argument est un pointeur sur fonction. Il s'agit de la fonction qui
|
||||
sera appelée par le nouveau processus.
|
||||
@ -198,6 +202,7 @@ programmes s'exécutent dans les mêmes *namespaces*.
|
||||
|
||||
### Exemples
|
||||
|
||||
<div lang="en-US">
|
||||
```sh
|
||||
42sh$ ./cmpns $(pgrep influxdb) $(pgrep init)
|
||||
- cgroup: differ
|
||||
@ -208,7 +213,9 @@ programmes s'exécutent dans les mêmes *namespaces*.
|
||||
- user: same
|
||||
- uts: same
|
||||
```
|
||||
</div>
|
||||
|
||||
<div lang="en-US">
|
||||
```sh
|
||||
42sh$ ./cmpns $(pgrep init) self
|
||||
- cgroup: same
|
||||
@ -219,11 +226,13 @@ programmes s'exécutent dans les mêmes *namespaces*.
|
||||
- user: same
|
||||
- uts: same
|
||||
```
|
||||
</div>
|
||||
|
||||
Ici, `self` fait référence au processus actuellement exécuté.
|
||||
|
||||
Et pourquoi pas :
|
||||
|
||||
<div lang="en-US">
|
||||
```sh
|
||||
42sh$ unshare -m ./cmpns $$ self
|
||||
- cgroup: same
|
||||
@ -234,6 +243,7 @@ Et pourquoi pas :
|
||||
- user: same
|
||||
- uts: same
|
||||
```
|
||||
</div>
|
||||
|
||||
|
||||
## Rejoindre un *namespace*
|
||||
@ -242,6 +252,7 @@ Rejoindre un *namespace* se fait en utilisant l'appel système `setns(2)`,
|
||||
auquel on passe le *file descriptor* d'un des liens du dossier
|
||||
`/proc/<PID>/ns/` :
|
||||
|
||||
<div lang="en-US">
|
||||
```c
|
||||
#define _GNU_SOURCE
|
||||
#include <fcntl.h>
|
||||
@ -271,12 +282,15 @@ int main(int argc, char *argv[])
|
||||
return EXIT_FAILURE;
|
||||
}
|
||||
```
|
||||
</div>
|
||||
|
||||
Dans un shell, on utilisera la commande `nsenter(1)` :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
42sh# nsenter --uts=/proc/42/ns/uts /bin/bash
|
||||
```
|
||||
</div>
|
||||
|
||||
|
||||
### `docker exec`
|
||||
@ -310,10 +324,12 @@ termine.
|
||||
Lorsque l'on a besoin de référencer un *namespace* (par exemple pour le faire
|
||||
persister après le dernier processus), on peut utiliser un `mount bind` :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
42sh# touch /tmp/ns/myrefns
|
||||
42sh# mount --bind /proc/<PID>/ns/mount /tmp/ns/myrefns
|
||||
```
|
||||
</div>
|
||||
|
||||
De cette manière, même si le lien initial n'existe plus (si le `<PID>` s'est
|
||||
terminé), `/tmp/ns/myrefns` pointera toujours au bon endroit.
|
||||
|
||||
@ -12,11 +12,13 @@ règles de filtrage, etc.
|
||||
En entrant dans un nouvel espace de nom `network`, on se retrouve dans un
|
||||
environnement qui n'a plus que l'interface de loopback :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
42sh# unshare -n ip a
|
||||
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default qlen 1
|
||||
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
|
||||
```
|
||||
</div>
|
||||
|
||||
Qui dit nouvelle pile réseau, dit également que les ports qui étaient assignés
|
||||
dans l'espace principal, ne le sont plus dans le conteneur : il est donc
|
||||
@ -31,9 +33,11 @@ La suite d'outils `iproute2` propose une interface simplifiée pour utiliser le
|
||||
|
||||
Tout d'abord, nous allons créer un nouvel espace de nom :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
42sh$ ip netns add virli
|
||||
```
|
||||
</div>
|
||||
|
||||
La technique utilisée ici pour avoir des *namespaces* nommés est la même que
|
||||
celle que nous avons vu dans la première partie sur les *namespaces* : via un
|
||||
@ -42,9 +46,11 @@ persister le namespace malgré le fait que plus aucun processus ne s'y exécute.
|
||||
|
||||
Maintenant que notre *namespace* est créé, voyons s'il contient des interfaces :
|
||||
|
||||
<div lang="en-US">
|
||||
```sh
|
||||
42sh$ ip netns exec virli ip link
|
||||
```
|
||||
</div>
|
||||
|
||||
Cette commande ne devrait vous montrer que l'interface de *loopback*, car nous
|
||||
n'avons pour l'instant pas encore attaché la moindre interface.
|
||||
@ -52,16 +58,20 @@ n'avons pour l'instant pas encore attaché la moindre interface.
|
||||
D'ailleurs, cette interface est rapportée comme étant désactivée, activons-là
|
||||
via la commande :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
42sh$ ip netns exec virli ip link set dev lo up
|
||||
```
|
||||
</div>
|
||||
|
||||
Si tout se passe bien, vous devriez maintenant pouvoir lancer un `ping` sur
|
||||
cette interface :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
42sh$ ip netns exec virli ping 127.0.0.1
|
||||
```
|
||||
</div>
|
||||
|
||||
|
||||
## *Virtual Ethernet*
|
||||
@ -74,9 +84,11 @@ centaines de conteneurs à gérer.
|
||||
Une technique couramment employée consiste à créer une interface virtuelle de
|
||||
type `veth` :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
ip link add veth0 type veth peer name veth1
|
||||
```
|
||||
</div>
|
||||
|
||||
Une interface `veth` se comporte comme un tube bidirectionnel : tout ce qui
|
||||
entre d'un côté sort de l'autre et inversement. La commande précédente a donc
|
||||
@ -89,24 +101,30 @@ devient alors possible de réaliser un échange de paquet entre les deux.
|
||||
|
||||
Pour déplacer `veth1` dans notre *namespace* `virli` :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
42sh# ip link set veth1 netns virli
|
||||
```
|
||||
</div>
|
||||
|
||||
Il ne reste plus maintenant qu'à assigner une IP à chacune des interfaces :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
42sh# ip netns exec virli ip a add 10.10.10.42/24 dev veth1
|
||||
42sh# ip a add 10.10.10.41/24 dev veth0
|
||||
```
|
||||
</div>
|
||||
|
||||
Testons maintenant que la communication entre les deux passe bient :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
42sh# ping 10.10.10.42
|
||||
- et -
|
||||
42sh# ip netns exec virli ping 10.10.10.41
|
||||
```
|
||||
</div>
|
||||
|
||||
Il ne reste donc pas grand chose à faire pour fournir Internet à notre
|
||||
conteneur, via un peu de NAT ou grâce à un pont Ethernet.
|
||||
@ -125,11 +143,13 @@ gourmande.
|
||||
Il est possible d'attribuer juste une interface de VLAN, si l'on a switch les
|
||||
supportant.
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
42sh# ip link add link eth0 name eth0.100 type vlan id 100
|
||||
42sh# ip link set dev eth0.100 up
|
||||
42sh# ip link set eth0.100 netns virli
|
||||
```
|
||||
</div>
|
||||
|
||||
|
||||
### MACVLAN
|
||||
@ -149,9 +169,11 @@ l'équipement réseau derrière la machine de rerouter le paquet vers la machine
|
||||
|
||||
Pour construire une nouvelle interface de ce type :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
ip link add link eth0 mac0 type macvlan mode vepa
|
||||
```
|
||||
</div>
|
||||
|
||||
|
||||
#### *Bridge*
|
||||
@ -163,9 +185,11 @@ sortie.
|
||||
|
||||
Pour construire une nouvelle interface de ce type :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
ip link add link eth0 mac1 type macvlan mode bridge
|
||||
```
|
||||
</div>
|
||||
|
||||
|
||||
## Aller plus loin
|
||||
|
||||
@ -22,9 +22,11 @@ se trouve).
|
||||
|
||||
Première étape s'isoler :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
unshare --pid --fork /bin/bash
|
||||
```
|
||||
</div>
|
||||
|
||||
Nous utilisons ici l'option `-f`, pour que le passage dans le nouvel espace de
|
||||
noms des PID soit effectif (cf. Introduction).
|
||||
@ -47,9 +49,11 @@ système initial. Pour s'en sortir, il est nécessaire de s'isoler du *namespace
|
||||
|
||||
Voici la nouvelle ligne de commande que l'on va utiliser :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
unshare --pid --mount --fork --mount-proc /bin/bash
|
||||
```
|
||||
</div>
|
||||
|
||||
Avec l'option `--mount-proc`, `unshare` va s'occuper de monter le nouveau
|
||||
`/proc`.
|
||||
|
||||
@ -40,6 +40,7 @@ Astuce : `pivot_root(2)`, `umount(2)`.
|
||||
|
||||
Partant d'une liste d'interfaces sur la machine hôte similaire à :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
42sh$ ip link
|
||||
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1
|
||||
@ -47,9 +48,11 @@ Partant d'une liste d'interfaces sur la machine hôte similaire à :
|
||||
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
|
||||
link/ether 90:2b:34:5e:fa:a7 brd ff:ff:ff:ff:ff:ff
|
||||
```
|
||||
</div>
|
||||
|
||||
Vous devrez pouvoir `ping` votre conteneur depuis votre hôte :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
42sh$ ip address
|
||||
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
|
||||
@ -69,6 +72,7 @@ PING 10.10.10.42 (10.10.10.42) 56(84) bytes of data.
|
||||
2 packets transmitted, 2 received, 0% packet loss, time 1003ms
|
||||
rtt min/avg/max/mdev = 3.789/3.847/3.906/0.085 ms
|
||||
```
|
||||
</div>
|
||||
|
||||
Dans l'exemple ci-dessus, l'interface dans le conteneur a l'IP `10.10.10.42`,
|
||||
tandis que la machine hôte a l'IP `10.10.10.41`.
|
||||
|
||||
@ -17,7 +17,9 @@ ZIP, RAR, ...).
|
||||
|
||||
Voici une arborescence type:
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
login_x-mymoulette/README
|
||||
login_x-mymoulette/...
|
||||
```
|
||||
</div>
|
||||
|
||||
@ -61,9 +61,11 @@ Sur chaque ligne, on doit indiquer :
|
||||
|
||||
Par exemple, le *namespace* `user` initial défini le correspondance suivante :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
0 0 4294967295
|
||||
```
|
||||
</div>
|
||||
|
||||
Cela signifie que les utilisateurs dont l'identifiant court de 0 à -2 inclu,
|
||||
dans cet espace de noms, correspond aux utilisateurs allant de 0 à -1 inclu,
|
||||
@ -71,9 +73,11 @@ pour le processus affichant ce fichier.
|
||||
|
||||
Lorsque l'on crée un *namespace* `user`, généralement, la correspondance vaut :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
0 1000 1
|
||||
```
|
||||
</div>
|
||||
|
||||
Dans cette situation, on comprend que notre processus considère que
|
||||
l'utilisateur root, dans le conteneur équivaut à l'utilisateur 1000 hors de
|
||||
@ -88,9 +92,11 @@ des groupes au lieu des utilisateurs.
|
||||
|
||||
## Utilisation de l'espace de noms
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
42sh$ unshare --mount --pid --mount-proc --fork --net --user --map-root-user /bin/bash
|
||||
```
|
||||
</div>
|
||||
|
||||
Un `capsh --print` nous montre que l'on est bien root et que l'on possède
|
||||
toutes les capabilities. Cependant, cela ne signifie pas que l'on a tous les
|
||||
|
||||
@ -19,25 +19,31 @@ l'option `--rm`.
|
||||
Vous pouvez afficher l'ensemble des conteneurs, quelque soit leur état (en
|
||||
cours d'exécution, arrêtés, ...) avec la commande suivante :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
42sh$ docker container ls -a
|
||||
CONTAINER ID IMAGE COMMAND CREATED STATUS NAMES
|
||||
552d71619723 hello-world "/hello" 4 days ago Exited (0) 4 days ago dreamy_gates
|
||||
0e8bbff6d500 debian "/bin/bash" 2 weeks ago Exited (0) 2 weeks ago cranky_jones
|
||||
```
|
||||
</div>
|
||||
|
||||
Il y a de fortes chances pour que vous n'ayez plus besoin de ces vieux
|
||||
conteneurs. Pour les supprimer, utilisez la commande :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
docker container rm 0e8bbff6d500 552d71619723
|
||||
```
|
||||
</div>
|
||||
|
||||
ou encore :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
docker container rm cranky_jones dreamy_gates
|
||||
```
|
||||
</div>
|
||||
|
||||
|
||||
## Images
|
||||
|
||||
@ -6,9 +6,11 @@ Mon premier conteneur
|
||||
Afin de tester la bonne marche de notre installation, lançons notre premier
|
||||
conteneur avec la commande :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
docker container run hello-world
|
||||
```
|
||||
</div>
|
||||
|
||||
Cette commande va automatiquement exécuter une série de commandes pour nous,
|
||||
comme indiqué dans le message affiché en retour :
|
||||
@ -23,16 +25,20 @@ node.js, etc.
|
||||
Nous pouvons directement utiliser le client pour rechercher une image sur le
|
||||
*Store*, en utilisant la commande `search` :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
docker search mariadb
|
||||
```
|
||||
</div>
|
||||
|
||||
Il est possible de mettre à jour les images locales ou simplement
|
||||
pré-télécharger des images depuis le Store en utilisant la commande `pull` :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
docker image pull ubuntu
|
||||
```
|
||||
</div>
|
||||
|
||||
Remarquez comment on interagit avec chaque *objet Docker* : dans la ligne de
|
||||
commande, le premier mot clef est le type d'objet (`container`, `image`,
|
||||
@ -52,9 +58,11 @@ Par exemple, pour consulter la liste des images dont nous disposons localement
|
||||
(soit parce qu'on les a téléchargées, soit parce que nous les avons créées
|
||||
nous-même), on utilise la commande `ls` sous le type d'objets `image` :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
docker image ls
|
||||
```
|
||||
</div>
|
||||
|
||||
Vous devriez constater la présence de plusieurs images « Ubuntu », mais chacune
|
||||
a un *TAG* différent. En effet, souvent, il existe plusieurs versions d'une même
|
||||
@ -79,9 +87,11 @@ La commande `run` de Docker prend comme derniers arguments le programme à
|
||||
lancer dans le conteneur ainsi que ses éventuels arguments. Essayons d'afficher
|
||||
un Hello World :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
docker container run ubuntu /bin/echo "Hello World"
|
||||
```
|
||||
</div>
|
||||
|
||||
Dans notre exemple, c'est bien le `/bin/echo` présent dans le conteneur qui est
|
||||
appelé. Ce n'est pas le programme `/bin/echo` de la machine hôte qui a été
|
||||
@ -92,9 +102,11 @@ pas présent sur notre machine, mais bien uniquement dans le conteneur. Si vous
|
||||
n'utilisez pas [Alpine Linux](https://www.alpine-linux.org), vous pourriez
|
||||
tenter d'utiliser son gestionnaire de paquet `apk`, via :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
docker container run alpine /sbin/apk stats
|
||||
```
|
||||
</div>
|
||||
|
||||
|
||||
## Modifier une image
|
||||
@ -125,24 +137,30 @@ créer une nouvelle image à partir de ce conteneur.
|
||||
|
||||
Pour créer une image, commençons par entrer dans un nouveau conteneur :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
docker container run -it ubuntu /bin/bash
|
||||
```
|
||||
</div>
|
||||
|
||||
Vous avez remarqué l'utilisation des options `--tty` et `--interactive` ? Avant
|
||||
le nom de l'image, elles sont gérées par Docker pour modifier le comportement
|
||||
du `run`. En fait, tout comme `git(1)` et ses sous-commandes, chaque niveau de
|
||||
commande peut prendre des paramètres :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
docker DOCKER_PARAMS container run RUN_OPTS image IMAGE_CMD IMAGE_ARGS ...
|
||||
```
|
||||
</div>
|
||||
|
||||
Par exemple :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
docker -H unix:///var/run/docker.sock container run -it alpine /bin/ash -c "echo foo"
|
||||
```
|
||||
</div>
|
||||
|
||||
Ici, l'option `-H` sera traitée par le client Docker (pour définir
|
||||
l'emplacement du point de communication avec le daemon), tandis que les options
|
||||
@ -157,12 +175,14 @@ sans quoi `bash` ne se lancera pas en mode interractif[^bashnointer].
|
||||
[^bashnointer]: Mais il sera possible de l'utiliser sans allouer de TTY, comme
|
||||
par exemple en faisant :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
42sh$ cat cmd
|
||||
echo foo
|
||||
42sh$ cat cmd | docker run -i busybox
|
||||
foo
|
||||
```
|
||||
</div>
|
||||
|
||||
L'option `-i` reste néanmoins nécessaire pour que l'entrée standard soit
|
||||
transmise au conteneur.
|
||||
|
||||
@ -16,15 +16,19 @@ c'est sur cette dernière que Docker pourra être exploité à son plein potenti
|
||||
Avant de continuer, assurez-vous que votre machine a bien démarré sur un noyau
|
||||
64 bits. Le retour de la commande `uname -m` doit vous indiquer :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
x86_64
|
||||
```
|
||||
</div>
|
||||
|
||||
Assurez-vous également d'avoir un noyau récent, avec la commande `uname -r` :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
4.13.4-gentoo
|
||||
```
|
||||
</div>
|
||||
|
||||
Vous ne pourrez pas utiliser Docker avec un noyau antérieur à la version 3.10.
|
||||
|
||||
@ -73,12 +77,15 @@ un bac à sable dans lequel vous pourrez commencer à faire ce TP.
|
||||
|
||||
Vous devriez maintenant être capable de lancer la commande suivante :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
docker version
|
||||
```
|
||||
</div>
|
||||
|
||||
Une sortie similaire au bloc suivant devrait apparaître sur votre écran :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
Client:
|
||||
Version: 17.09.0-ce
|
||||
@ -97,15 +104,18 @@ Server:
|
||||
OS/Arch: linux/amd64
|
||||
Experimental: false
|
||||
```
|
||||
</div>
|
||||
|
||||
### `no such file or directory`?
|
||||
|
||||
Si vous avez cette erreur : `dial unix /var/run/docker.sock: no such file or
|
||||
directory.`, le deamon n'est sans doute pas lancé. Lancez-le :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
sudo service docker restart
|
||||
```
|
||||
</div>
|
||||
|
||||
|
||||
### `permission denied`?
|
||||
@ -114,9 +124,11 @@ Si vous avez cette erreur : `dial unix /var/run/docker.sock: permission
|
||||
denied.`, ajoutez votre utilisateur au groupe `docker` et **relancer votre
|
||||
session** :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
sudo gpasswd -a $USER docker
|
||||
```
|
||||
</div>
|
||||
|
||||
**Attention :** cette action n'est pas anodine d'un point de vue sécurité :
|
||||
<https://docs.docker.com/engine/security/security/#docker-daemon-attack-surface>
|
||||
|
||||
@ -21,6 +21,7 @@ Docker propose de base trois pilotes (*drivers*) pour « gérer » cela :
|
||||
Ces trois *drivers* sont instanciés de base dans Docker avec le même nom que
|
||||
leur pilote. Pour consulter la liste de réseaux utilisables, lancez :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
42sh$ docker network ls
|
||||
NETWORK ID NAME DRIVER SCOPE
|
||||
@ -28,6 +29,7 @@ NETWORK ID NAME DRIVER SCOPE
|
||||
d5d907add6e2 host host local
|
||||
16b702ed01a0 none null local
|
||||
```
|
||||
</div>
|
||||
|
||||
Par défaut, c'est le réseau `bridge` (de type `bridge`) qui est employé : ce
|
||||
réseau utilise le pont `docker0` que vous pouvez voir dans vos interfaces
|
||||
@ -55,17 +57,21 @@ est recommandé de créer des réseaux utilisateur.
|
||||
La création d'un réseau se fait tout simplement au travers des sous-commandes
|
||||
relatives aux objets Docker `network` :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
docker network create --driver bridge my_network
|
||||
```
|
||||
</div>
|
||||
|
||||
C'est ensuite ce nom de réseau que vous passerez à l'option `--network` de vos
|
||||
`run`, ou vous pouvez également faire rejoindre un conteneur déjà lancé à un
|
||||
réseau :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
docker network connect NETWORK CONTAINER
|
||||
```
|
||||
</div>
|
||||
|
||||
Lorsque plusieurs conteneurs ont rejoints un réseau utilisateur, ils peuvent
|
||||
mutuellement se découvrir grâce à un système de résolution de nom basé sur leur
|
||||
@ -76,18 +82,22 @@ nom de conteneur.
|
||||
|
||||
Lancez votre serveur web avec :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
docker container run --name helloapp -d my_webserver
|
||||
```
|
||||
</div>
|
||||
|
||||
Puis créez un réseau utilisateur, rejoignez-le et lancez un conteneur dans le
|
||||
même réseau utilisateur. Vous devriez être capable de lancer dans ce conteneur
|
||||
les commandes :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
ping helloapp
|
||||
curl http://helloapp/
|
||||
```
|
||||
</div>
|
||||
|
||||
|
||||
## Liaison à l'ancienne
|
||||
@ -108,9 +118,11 @@ moins le mot de passe à utiliser via la variable d'environnement
|
||||
disponible sur la page dédiée à l'image sur le *store* :
|
||||
<https://store.docker.com/images/postgres>
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
docker container run --name some-postgres -e POSTGRES_PASSWORD=mysecretpassword -d postgres
|
||||
```
|
||||
</div>
|
||||
|
||||
Le lien permet de fournir à n'importe quel autre conteneur les mêmes variables
|
||||
d'environnement. Cela évite d'avoir à recopier le mot de passe pour lancer un
|
||||
@ -119,6 +131,8 @@ doit se connecter à une base de données : l'application doit être configurée
|
||||
pour utiliser le mot de passe défini au lancement du conteneur de base de
|
||||
données :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
docker run -it --rm --link some-postgres:postgres postgres psql -h postgres -U postgres
|
||||
```
|
||||
</div>
|
||||
|
||||
@ -56,6 +56,7 @@ placer dans une tarball (pas d'archive ZIP, RAR, ...).
|
||||
|
||||
Voici une arborescence type:
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
login_x-TP1/webserver
|
||||
login_x-TP1/webserver/Dockerfile
|
||||
@ -63,6 +64,7 @@ login_x-TP1/webserver/index.html
|
||||
login_x-TP1/mycloud
|
||||
login_x-TP1/mycloud/mycloud-run.sh
|
||||
```
|
||||
</div>
|
||||
|
||||
## Signature du rendu
|
||||
|
||||
@ -94,6 +96,7 @@ signature.
|
||||
|
||||
Si vous recevez un rapport avec l'erreur suivante :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
[FAIL] Bad signature. Here is the gnupg output:
|
||||
|
||||
@ -102,6 +105,7 @@ gpg: using RSA key 842807A84573CC96
|
||||
gpg: requesting key E2CCD99DD37BD32E from hkp server pool.sks-keyservers.net
|
||||
gpg: Can't check signature: No public key
|
||||
```
|
||||
</div>
|
||||
|
||||
C'est que votre clef publique n'est pas dans mon trousseau et que les méthodes
|
||||
de récupération automatique n'ont pas permis de la trouver. Uploadez votre
|
||||
@ -114,9 +118,11 @@ de retenter votre rendu.
|
||||
|
||||
Si vous recevez un rapport avec l'erreur suivante :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
[FAIL] The username of your key is not explicit, I can't find you.
|
||||
```
|
||||
</div>
|
||||
|
||||
Votre clef ne contient sans doute pas vos noms et prénoms ou l'adresse
|
||||
électronique associée à la clef n'est pas celle que j'ai dans ma base de
|
||||
@ -127,9 +133,11 @@ données.
|
||||
|
||||
Si vous recevez un rapport concluant ainsi :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
After analyzing your e-mail, I've decided to SKIP it.
|
||||
```
|
||||
</div>
|
||||
|
||||
Cela signifie que la lecture de votre courriel qui a été préférée n'est pas
|
||||
celle d'un rendu. Vérifiez que vous n'envoyez pas votre clef publique avec
|
||||
|
||||
@ -27,9 +27,11 @@ exemple si vous voulez partager des fichiers avec votre voisin, en passant par
|
||||
le protocole HTTP, mais sans se casser la tête à installer et configurer un
|
||||
serveur web :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
docker container run --rm -p 80:80 -v ~/Downloads:/usr/share/nginx/html:ro -d nginx
|
||||
```
|
||||
</div>
|
||||
|
||||
Une fois cette commande lancée, votre voisin pourra accéder à votre dossier
|
||||
Downloads en renseignant l'IP de votre machine dans son navigateur favori !
|
||||
@ -45,16 +47,20 @@ soucier de leur réel emplacement.
|
||||
Comme il s'agit d'un objet, la première chose à faire va être de créer notre
|
||||
volume :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
docker volume create prod_db
|
||||
```
|
||||
</div>
|
||||
|
||||
Ensuite, nous pouvons démarrer un conteneur utilisant, par exemple :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
docker container run --name mydb --mount source=prod_db,target=/var/lib/mysql \
|
||||
-e MYSQL_ROOT_PASSWORD=my-secret-pw mysql
|
||||
```
|
||||
</div>
|
||||
|
||||
Lorsque le volume est vide, si des données sont présentes à l'endroit du point
|
||||
de montage, celles-ci sont recopiées dans le volume.
|
||||
@ -62,9 +68,11 @@ de montage, celles-ci sont recopiées dans le volume.
|
||||
Si plus tard, vous souhaitez créer un conteneur chargé de faire des
|
||||
sauvegardes, vous pourriez le lancer comme ceci :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
docker container run -it --volume-from mydb busybox /bin/bash
|
||||
```
|
||||
</div>
|
||||
|
||||
|
||||
## Volumes temporaires
|
||||
|
||||
@ -10,6 +10,7 @@ allons définir à la racine de notre projet un fichier `docker-compose.yml` qui
|
||||
contiendra les paramètres d'exécution (et éventuellement les méthodes de
|
||||
construction).
|
||||
|
||||
<div lang="en-US">
|
||||
```yaml
|
||||
version: '3'
|
||||
services:
|
||||
@ -25,6 +26,7 @@ services:
|
||||
links:
|
||||
- influxdb
|
||||
```
|
||||
</div>
|
||||
|
||||
Ce fichier est un condensé des options que nous passons habituellement au
|
||||
`docker container run`.
|
||||
@ -57,15 +59,18 @@ Cette section est le pendant de la commandes `docker volume`.
|
||||
On déclare les volumes simplement en leur donnant un nom et un driver comme
|
||||
suit :
|
||||
|
||||
<div lang="en-US">
|
||||
```yaml
|
||||
volumes:
|
||||
mysql-data:
|
||||
driver: local
|
||||
```
|
||||
</div>
|
||||
|
||||
Pour les utiliser avec un conteneur, on référence le nom ainsi que
|
||||
l'emplacement à partager :
|
||||
|
||||
<div lang="en-US">
|
||||
```yaml
|
||||
[...]
|
||||
mysql:
|
||||
@ -73,6 +78,7 @@ l'emplacement à partager :
|
||||
volumes:
|
||||
- mysql-data:/var/lib/mysql
|
||||
```
|
||||
</div>
|
||||
|
||||
|
||||
### `network`
|
||||
@ -86,11 +92,13 @@ 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 :
|
||||
|
||||
<div lang="en-US">
|
||||
```yaml
|
||||
networks:
|
||||
knotdns-slave-net:
|
||||
driver: bridge
|
||||
```
|
||||
</div>
|
||||
|
||||
|
||||
#### Driver `host`
|
||||
@ -136,9 +144,11 @@ listés dans le fichier.
|
||||
Une fois le build terminé, nous pouvons lancer la commande suivante et admirer
|
||||
le résultat :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
docker-compose up
|
||||
```
|
||||
</div>
|
||||
|
||||
Encore une fois, testez la bonne connexion entre chronograf (accessible sur
|
||||
<http://localhost:8888>) et influxdb.
|
||||
|
||||
@ -42,9 +42,11 @@ Pour créer une nouvelle machine, nous allons utiliser la commande
|
||||
donner à cette machine (les machines ne sont pas considérées comme jetables,
|
||||
leur nom vous permettra par exemple de relancer une machine plus tard) :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
docker-machine create --driver virtualbox echinoidea
|
||||
```
|
||||
</div>
|
||||
|
||||
Consultez la section suivante, réservée aux gens qui ne peuvent pas passer par
|
||||
`docker-machine` si vous souhaitez avoir plus d'information sur ce que fait
|
||||
@ -66,6 +68,7 @@ pouvait ne pas se trouver sur la même machine que le client `docker`. Eh bien
|
||||
avec `docker-machine` cela prend tout son sens, car vous pouvez très facilement
|
||||
changer de daamon/machine avec une simple commande :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
$ docker container ls
|
||||
CONTAINER ID IMAGE COMMAND CREATED STATUS
|
||||
@ -75,6 +78,7 @@ CONTAINER ID IMAGE COMMAND CREATED
|
||||
a814293b9f45 armbuild/busybox "/bin/sh" 18 seconds ago Up 10 minutes
|
||||
0caddeed5037 armbuild/alpine "/bin/sh" 2 weeks ago Created
|
||||
```
|
||||
</div>
|
||||
|
||||
On remarque que le client Docker est influencé par l'exécution de notre
|
||||
commande `docker-machine env`. En effet, cette commande va modifier
|
||||
@ -124,19 +128,23 @@ virtuelles. Néanmoins, cela ne coûte rien de voir les procédures mise en œuv
|
||||
Commençons par voir sur quel port le daemon `dockerd` de notre machine
|
||||
virtuelle écoute :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
(virt1) 42sh$ netstat -tpln | grep dockerd
|
||||
Proto Recv-Q Send-Q Local Address Foreign Address PID/Program name
|
||||
tcp 0 0 :::2376 :::* 980/dockerd
|
||||
```
|
||||
</div>
|
||||
|
||||
Essayons de renseigner simplement cette configuration à notre client Docker :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
(main) 42sh$ docker -H tcp://$VM1_IP:2376/ info
|
||||
Get http://$VM1_IP:2376/v1.32/info: net/http: HTTP/1.x transport connection broken: malformed HTTP response "\x15\x03\x01\x00\x02\x02".
|
||||
* Are you trying to connect to a TLS-enabled daemon without TLS?
|
||||
```
|
||||
</div>
|
||||
|
||||
En effet, Docker met tout en œuvre pour rendre compliqué l'utilisation
|
||||
non-sécurisée de la plate-forme. Mais ils font également en sorte que la
|
||||
@ -152,6 +160,7 @@ connexion TLS classique.
|
||||
Tout le nécessaire est déjà configuré au sein de `boot2docker`, pour nos tests,
|
||||
nous n'avons qu'à recopier la clef et les certificats en place.
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
(main) 42sh$ mkdir remote/virt1
|
||||
(main) 42sh$ scp "docker@$VM1_IP:.docker/*" remote/virt1
|
||||
@ -159,11 +168,14 @@ ca.pem
|
||||
cert.pem
|
||||
key.pem
|
||||
```
|
||||
</div>
|
||||
|
||||
Tentons maintenant de nous connecter au daemon distant en utilisant ces éléments :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
42sh$ DOCKER_CERT_PATH=remote/virt1/ docker -H tcp://$VM1_IP:2376/ --tlsverify info
|
||||
```
|
||||
</div>
|
||||
|
||||
Vous pouvez effectuer la même opération pour la seconde VM.
|
||||
|
||||
@ -24,22 +24,27 @@ Afin d'interagir avec les données, InfluxDB expose une
|
||||
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 :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
docker container run -p 8086:8086 -d --name mytsdb influxdb
|
||||
```
|
||||
</div>
|
||||
|
||||
Comme il s'agit d'une API REST, nous pouvons vérifier le bon fonctionnement de
|
||||
notre base de données en appelant :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
42sh$ curl -f http://localhost:8086/ping
|
||||
42sh$ echo $?
|
||||
0
|
||||
```
|
||||
</div>
|
||||
|
||||
Si votre influxdb répond, vous pouvez vous y connecter en utilisant directement
|
||||
le client fourni :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
42sh$ docker container run --rm -it --link mytsdb:influxdb \
|
||||
--entrypoint "/usr/bin/influx" influxdb -host influxdb
|
||||
@ -52,6 +57,7 @@ name: databases
|
||||
name
|
||||
_internal
|
||||
```
|
||||
</div>
|
||||
|
||||
Si vous aussi vous voyez la table `_internal`, bravo ! vous pouvez passer à la
|
||||
suite.
|
||||
@ -60,9 +66,11 @@ 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>
|
||||
|
||||
|
||||
\hspace{2em}**Exercice :** Ajoutez à la ligne de commande de lancement du
|
||||
@ -76,17 +84,21 @@ d'influxDB si nous devions redémarrer le conteneur.
|
||||
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* :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
curl https://dl.influxdata.com/telegraf/releases/telegraf-1.4.2-static_linux_amd64.tar.gz | \
|
||||
tar xzv -C /tmp
|
||||
```
|
||||
</div>
|
||||
|
||||
Puis, lançons *Telegraf* :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
cd /tmp/telegraf
|
||||
./telegraf --config telegraf.conf
|
||||
```
|
||||
</div>
|
||||
|
||||
**Remarque :** La configuration par défaut va collecter les données de la
|
||||
machine locale et les envoyer sur le serveur situé à
|
||||
@ -96,6 +108,7 @@ sorte de redirigé le port de notre conteneur sur notre machine locale (option
|
||||
|
||||
Et observons ensuite :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
42sh$ docker container run --rm -it --link mytsdb:influxdb \
|
||||
--entrypoint "/usr/bin/influx" influxdb -host influxdb
|
||||
@ -125,6 +138,7 @@ processes
|
||||
swap
|
||||
system
|
||||
```
|
||||
</div>
|
||||
|
||||
La nouvelle base a donc bien été créé et tant que nous laissons *Telegraf*
|
||||
lancé, celui-ci va régulièrement envoyer des métriques de cette machine.
|
||||
|
||||
@ -30,6 +30,7 @@ placer à la racine de votre rendu.
|
||||
|
||||
Voici une arborescence type:
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
login_x-TP2/influxdb
|
||||
login_x-TP2/influxdb/Dockerfile
|
||||
@ -42,3 +43,4 @@ login_x-TP2/fic-server/Dockerfile-admin
|
||||
login_x-TP2/fic-server/Dockerfile-backend
|
||||
login_x-TP2/fic-server/Dockerfile-frontend
|
||||
```
|
||||
</div>
|
||||
|
||||
@ -31,11 +31,13 @@ L'équipe en charge de `docker-machine` met à disposition un exécutable compil
|
||||
pour bon nombres d'environnements. Nous pouvons l'installer en suivant la
|
||||
procédure suivante :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
curl -L https://github.com/docker/machine/releases/download/v0.12.2/docker-machine-Linux-x86_64 \
|
||||
> /usr/bin/docker-machine
|
||||
chmod +x /usr/bin/docker-machine
|
||||
```
|
||||
</div>
|
||||
|
||||
Si vous êtes dans un environnement différent, jetez un œil à
|
||||
[la documentation d'installation](https://docs.docker.com/machine/install-machine/).
|
||||
@ -60,10 +62,12 @@ n'aurez qu'à suivre les instructions du
|
||||
Comme avec Docker, nous pouvons vérifier le bon fonctionnement de
|
||||
`docker-machine` en exécutant la commande :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
42sh$ docker-machine version
|
||||
docker-machine version 0.12.2, build 9371605
|
||||
```
|
||||
</div>
|
||||
|
||||
|
||||
## `docker-compose`
|
||||
@ -88,11 +92,13 @@ fonctionnera avec la version de Docker qu'ils fournissent.
|
||||
L'équipe en charge de Docker compose met à disposition un exécutable contenant
|
||||
tous les scripts. Nous pouvons l'installer en suivant la procédure suivante :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
curl -L https://github.com/docker/compose/releases/download/1.16.1/docker-compose-Linux-x86_64 \
|
||||
> /usr/bin/docker-compose
|
||||
chmod +x /usr/bin/docker-compose
|
||||
```
|
||||
</div>
|
||||
|
||||
### `pip`
|
||||
|
||||
@ -106,10 +112,12 @@ votre version de Docker.
|
||||
Comme avec Docker, nous pouvons vérifier le bon fonctionnement de
|
||||
`docker-compose` en exécutant la commande :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
42sh$ docker-compose --version
|
||||
docker-compose version: 1.16.1
|
||||
```
|
||||
</div>
|
||||
|
||||
Si vous obtenez une réponse similaire, c'est que vous êtes prêt à commencer le
|
||||
TP ! Alors n'attendons pas, partons à l'aventure !
|
||||
|
||||
@ -10,12 +10,14 @@ de commits. Docker dispose d'un mécanisme permettant d'automatiser la
|
||||
construction de nouvelles images. Vous pouvez arriver au même résultat que ce
|
||||
que l'on a réussi à faire précédemment en utilisant le `Dockerfile` suivant :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
FROM ubuntu:latest
|
||||
|
||||
RUN apt-get update
|
||||
RUN apt-get install -y nano
|
||||
```
|
||||
</div>
|
||||
|
||||
La syntaxe d'un `Dockerfile` est simple, le premier mot de chaque ligne est
|
||||
l'intitulé d'une instruction (que l'on écrit généralement en majuscule), elle
|
||||
@ -29,16 +31,20 @@ Pour lancer la construction de la nouvelle image, créer un nouveau dossier ne
|
||||
contenant que votre fichier `Dockerfile`, placez-vous dedans, puis utilisez la
|
||||
commande `build` :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
docker image build --tag=my_editor .
|
||||
```
|
||||
</div>
|
||||
|
||||
Une fois la construction de l'image terminée, vous pouvez la lancer et
|
||||
constater l'existence de notre éditeur favori :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
docker container run -it my_editor /bin/bash
|
||||
```
|
||||
</div>
|
||||
|
||||
|
||||
## `RUN` dans le `Dockerfile`
|
||||
@ -48,11 +54,13 @@ correspondra à une nouvelle couche de notre image.
|
||||
|
||||
Cela signifie que l'exemple suivant **ne fonctionne pas** :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
COPY db.sql /db.sql
|
||||
RUN service mysqld start
|
||||
RUN mysql -u root -p toor virli < /db.sql
|
||||
```
|
||||
</div>
|
||||
|
||||
Cet exemple ne fonctionne pas car le serveur MySQL qui est lancé dans le
|
||||
premier `RUN`, n'est plus lancé au moment du deuxième `RUN`. En effet, chaque
|
||||
@ -60,10 +68,12 @@ commande du `Dockerfile` a pour but de modifier le système de fichiers.
|
||||
|
||||
Pour avoir le résultat escompté, il faut exécuter les commandes ensemble :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
COPY db.sql /db.sql
|
||||
RUN service mysqld start && mysql -u root -p toor virli < /db.sql
|
||||
```
|
||||
</div>
|
||||
|
||||
Après le `RUN`, MySQL sera de nouveau arrêté, si on veut l'utiliser dans le
|
||||
conteneur, il ne faudra pas oublier de lancer le processus.
|
||||
@ -73,6 +83,7 @@ conteneur, il ne faudra pas oublier de lancer le processus.
|
||||
|
||||
Construisons maintenant un conteneur avec un serveur web :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
FROM my_editor
|
||||
|
||||
@ -81,6 +92,7 @@ RUN apt-get install -y nginx
|
||||
|
||||
EXPOSE 80
|
||||
```
|
||||
</div>
|
||||
|
||||
L'instruction `EXPOSE` sera traitée plus tard par le client Docker (équivalent
|
||||
à l'argument `--expose`). Il s'agit de préciser les ports sur lesquels votre
|
||||
@ -89,11 +101,13 @@ image écoute.
|
||||
En utilisant l'option `-P` du `run`, vous allez pouvoir assigner une
|
||||
redirection de port aléatoire sur la machine hôte vers votre conteneur :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
docker image build --tag=my_webserver .
|
||||
docker container run -it -P my_webserver /bin/bash
|
||||
service nginx start
|
||||
```
|
||||
</div>
|
||||
|
||||
Dans un autre terminal, lancer un `docker ps` et consulter la colonne *PORTS*
|
||||
pour connaître le port choisi par Docker pour effectuer la redirection.
|
||||
@ -109,14 +123,18 @@ Rendez-vous ensuite dans votre navigateur sur <http://localhost:49153/>.
|
||||
Vous pouvez placer dans un `Dockerfile` une instruction `CMD` qui sera exécutée
|
||||
si aucune commande n'est passée lors du `run`, par exemple :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
CMD nginx -g "daemon off;"
|
||||
```
|
||||
</div>
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
docker image build --tag=my_nginx .
|
||||
docker container run -d -P my_nginx
|
||||
```
|
||||
</div>
|
||||
|
||||
L'option `-d` passée au `run` lance le conteneur en tâche de fond. Si vous
|
||||
constatez via un `docker container ls` que le conteneur s'arrête directement,
|
||||
|
||||
@ -11,9 +11,11 @@ l'ip de notre conteneur Docker dans la table `data_source` :
|
||||
|
||||
Petit indice, les requêtes SQL sont les suivantes :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
DELETE FROM "data_source";
|
||||
INSERT INTO "data_source" VALUES(1,1,0,'influxdb','influx','direct','http://${}:8086/','user','pass','metrics',0,'','',0,'null','2015-10-29 09:00:00','2015-10-29 09:05:00');
|
||||
```
|
||||
</div>
|
||||
|
||||
La base se trouve dans `/var/lib/grafana/grafana.db`.
|
||||
|
||||
@ -100,23 +100,27 @@ InfluxDB. Nous allons installer `telegraf` sur notre machine à l'aide de la
|
||||
Ces quelques lignes devraient suffir à lancer la collecte, à condition que
|
||||
votre InfluxDB écoute sur le port 8086 local :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
TELEGRAF_VERSION=1.0.0
|
||||
wget https://dl.influxdata.com/telegraf/releases/telegraf-${TELEGRAF_VERSION}_linux_amd64.tar.gz
|
||||
tar xf telegraf-${TELEGRAF_VERSION}_linux_amd64.tar.gz
|
||||
TELEGRAF_CONFIG_PATH=./telegraf/etc/telegraf/telegraf.conf ./telegraf/usr/bin/telegraf
|
||||
```
|
||||
</div>
|
||||
|
||||
Rendez-vous ensuite dans [l'interface d'InfluxDB](http://localhost:8083/) pour
|
||||
voir si la collecte se passe bien.
|
||||
|
||||
Dans l'interface sélectionnez la base `telegraf` puis explorez les valeurs :
|
||||
|
||||
<div lang="en-US">
|
||||
```sql
|
||||
SHOW MEASUREMENTS
|
||||
SHOW FIELD KEYS
|
||||
SELECT usage_idle FROM cpu WHERE cpu = 'cpu-total' ORDER BY time DESC LIMIT 5
|
||||
```
|
||||
</div>
|
||||
|
||||
Laissons tourner `telegraf` afin de constituer un petit historique de valeurs.
|
||||
|
||||
|
||||
@ -54,11 +54,13 @@ vous codez.
|
||||
|
||||
Lorsqu'une ligne devient complexe, allez à la ligne :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
RUN apt-get update && apt-get install -y \
|
||||
nginx \
|
||||
php5-fpm
|
||||
```
|
||||
</div>
|
||||
|
||||
Notez les backslashs à la fin des lignes, indiquant qu'elle n'est pas terminée.
|
||||
|
||||
@ -67,6 +69,7 @@ Notez les backslashs à la fin des lignes, indiquant qu'elle n'est pas terminée
|
||||
Lorsque c'est possible, ordonnez vos lignes suivant un ordre logique. Par
|
||||
exemple :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
RUN apt-get update && apt-get install -y \
|
||||
bzr \
|
||||
@ -75,6 +78,7 @@ RUN apt-get update && apt-get install -y \
|
||||
mercurial \
|
||||
subversion
|
||||
```
|
||||
</div>
|
||||
|
||||
|
||||
## Profitez du système de cache
|
||||
@ -149,16 +153,19 @@ L'entrypoint peut être utilisé de deux manières différentes :
|
||||
après le nom de l'image, corresponde aux arguments attendu par le programme
|
||||
indiqué dans l'entrypoint. Par exemple pour nginx :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
ENTRYPOINT ["nginx"]
|
||||
CMD ["-g daemon off;"]
|
||||
```
|
||||
</div>
|
||||
|
||||
- Vous pouvez aussi utiliser un script qui servira à faire les initialisations
|
||||
ou les configurations nécessaire au bon fonctionnement du conteneur
|
||||
(rappelez-vous, il doit être éphémère !). Par exemple, le `Dockerfile` pour
|
||||
l'image de PostgreSQL possède cet entrypoint :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
#!/bin/bash
|
||||
set -e
|
||||
@ -175,6 +182,7 @@ fi
|
||||
|
||||
exec "$@"
|
||||
```
|
||||
</div>
|
||||
|
||||
|
||||
## `[""]`, `'` et sans `[]`
|
||||
|
||||
@ -10,9 +10,11 @@ La première chose à faire est de télécharger la liste des paquets. En effet,
|
||||
afin de ne pas livrer de superflu, la liste des paquets et son cache ne sont
|
||||
pas incluses dans le conteneur.
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
apt-get update
|
||||
```
|
||||
</div>
|
||||
|
||||
Il peut arriver que des paquets présents dans l'image ne soient pas à
|
||||
jour. Afin de garder un environnement cohérent, il est recommandé de ne pas
|
||||
@ -22,16 +24,20 @@ jour.
|
||||
|
||||
Installons maintenant un programme :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
apt-get install nano
|
||||
```
|
||||
</div>
|
||||
|
||||
En attendant la fin de l'installation, jetons un œil à la commande dans un
|
||||
autre terminal :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
docker container ls
|
||||
```
|
||||
</div>
|
||||
|
||||
Cette commande liste les conteneurs actifs. Notez le *Container ID* ainsi que
|
||||
le *NAMES* du conteneur actuellement en cours d'installation de `nano`.
|
||||
@ -42,17 +48,21 @@ Lorsque l'installation de `nano` est terminée, quittez l'image en tapant
|
||||
Sauvegardez votre image modifiée avec la commande `commit` pour pouvoir
|
||||
commencer directement de votre image avec `nano` :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
docker container commit CONTAINER my_nano
|
||||
```
|
||||
</div>
|
||||
|
||||
en remplaçant `CONTAINER` par le nom ou l'identifiant de votre
|
||||
container. `my_nano` est le nom que vous voudrez utiliser à la place
|
||||
d'`ubuntu` :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
docker container run -it my_nano /bin/bash
|
||||
```
|
||||
</div>
|
||||
|
||||
Vous constatez cette fois que vous pouvez lancer `nano`, alors que vous ne
|
||||
pouvez toujours pas le faire dans un conteneur issu d'une image `ubuntu` !
|
||||
|
||||
@ -29,9 +29,11 @@ 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é).
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
docker run --rm --link YOUR_INFLUX_CNTR_NAME:influxdb chronograf
|
||||
```
|
||||
</div>
|
||||
|
||||
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
|
||||
@ -48,7 +50,9 @@ 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 :
|
||||
|
||||
<div lang="en-US">
|
||||
```sql
|
||||
SELECT used, available, cached FROM mem WHERE tmpltime()
|
||||
SELECT mean(usage_idle) FROM cpu WHERE tmpltime() GROUP BY time(20s), cpu
|
||||
```
|
||||
</div>
|
||||
|
||||
@ -39,9 +39,11 @@ lance puis attend que les deux deamons aient terminés de s'exécuter.
|
||||
Pour vérifier que votre conteneur fonctionne correctement, vous pouvez le
|
||||
lancer :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
docker run --rm -p 10000:10000 mymonitoring
|
||||
```
|
||||
</div>
|
||||
|
||||
Puis accéder à chronograf : <http://localhost:10000/>. Donnez un nom à votre
|
||||
configuration, puis cliquez sur *Add*. Les paramètres préremplis dans le
|
||||
@ -60,9 +62,11 @@ conteneur qui délivre des pages web), il va être possible de redémarrer le
|
||||
conteneur automatiquement grâce à la *restart policy* que l'on peut définir au
|
||||
moment du `docker run` :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
docker run -d -p 80:80 --restart=on-failure nginx
|
||||
```
|
||||
</div>
|
||||
|
||||
Il existe trois règles de redémarrage différentes :
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user