Don't force line return on ####
This commit is contained in:
parent
bbd704d413
commit
6e135a40de
|
|
@ -172,7 +172,7 @@ Il s'agit d'une représentation d'une structure du noyau, pas forcément très
|
|||
lisible en l'état. On utilisera `getfacl` pour la version lisible.
|
||||
|
||||
|
||||
#### `ping`\
|
||||
#### `ping`
|
||||
|
||||
De la même manière que l'on peut définir de façon plus fine les droits d'accès
|
||||
par utilisateur, un attribut de l'espace de nom *security* peut être défini
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@
|
|||
Poursuivons [notre script de monitoring](#script-monitoring) afin d'envoyer nos
|
||||
résultats vers InfluxDB : nous l'appellerons `./telegraf.sh`.
|
||||
|
||||
#### Rappel d'InfluxDB\
|
||||
#### Rappel d'InfluxDB
|
||||
|
||||
Commençons par lancer le conteneur Docker d'InfluxDB (pour éviter de
|
||||
l'installer sur notre machine) :
|
||||
|
|
@ -32,7 +32,7 @@ EOF
|
|||
Vérifiez que la base de données `metrics` a bien été créée.
|
||||
|
||||
|
||||
#### Monitoring vers InfluxDB\
|
||||
#### Monitoring vers InfluxDB
|
||||
|
||||
Maintenant, envoyons nos données vers la base
|
||||
<https://docs.influxdata.com/influxdb/v1.8/guides/write_data/> :
|
||||
|
|
@ -54,7 +54,7 @@ SELECT * from "$my_cgroup_name";
|
|||
</div>
|
||||
|
||||
|
||||
#### Monitorer davantage de données\
|
||||
#### Monitorer davantage de données
|
||||
|
||||
Liste non exhaustive de données à monitorer :
|
||||
|
||||
|
|
@ -70,7 +70,7 @@ accessible ici :
|
|||
- v2 : <https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html>
|
||||
|
||||
|
||||
#### Permettre à l'utilisateur de monitorer des processus\
|
||||
#### Permettre à l'utilisateur de monitorer des processus
|
||||
|
||||
Maintenant, séparons notre script en deux parties afin qu'un utilisateur normal
|
||||
(non-root) puisse utiliser la partie monitoring de notre script.
|
||||
|
|
|
|||
|
|
@ -98,7 +98,7 @@ Les distributions *à l'ancienne* proposent de télécharger leur système de ba
|
|||
sous forme de tarball :
|
||||
|
||||
|
||||
#### Gentoo\
|
||||
#### Gentoo
|
||||
|
||||
<http://gentoo.mirrors.ovh.net/gentoo-distfiles/releases/amd64/autobuilds/current-stage3-amd64-openrc/stage3-amd64-openrc-20211128T170532Z.tar.xz>
|
||||
|
||||
|
|
@ -123,7 +123,7 @@ chroot newroot/ bash
|
|||
</div>
|
||||
|
||||
|
||||
#### Alpine\
|
||||
#### Alpine
|
||||
|
||||
<https://dl-cdn.alpinelinux.org/alpine/v3.14/releases/x86_64/alpine-minirootfs-3.14.2-x86_64.tar.gz>
|
||||
|
||||
|
|
|
|||
|
|
@ -55,7 +55,7 @@ ce sujet :\
|
|||
|
||||
::::: {.exercice}
|
||||
|
||||
#### À vous de jouer {-}\
|
||||
#### À vous de jouer {-}
|
||||
|
||||
Continuons l'exercice précédent où nous avions [fixé les
|
||||
limites](#Fixer-des-limites) de mémoire que pouvez réserver les processus de
|
||||
|
|
|
|||
|
|
@ -81,7 +81,7 @@ Vous devriez constater l'effet de cette commande sans plus attendre !
|
|||
|
||||
::::: {.exercice}
|
||||
|
||||
#### `procinfo`\
|
||||
#### `procinfo`
|
||||
|
||||
Explorons le pseudo système de fichiers `/proc` pour écrire un script qui va
|
||||
afficher des informations sur un processus donné :
|
||||
|
|
@ -125,7 +125,7 @@ uts:[4026531838]
|
|||
</div>
|
||||
|
||||
|
||||
#### `batinfo.sh`, `cpuinfo.sh`\
|
||||
#### `batinfo.sh`, `cpuinfo.sh`
|
||||
|
||||
Explorons le pseudo système de fichiers `/sys` pour écrire un script
|
||||
qui va, en fonction de ce que vous avez de disponible :
|
||||
|
|
@ -188,7 +188,7 @@ Thermal throttle count: 0
|
|||
N'hésitez pas à rajouter toute sorte d'information intéressantes !
|
||||
|
||||
|
||||
#### `rev_kdb_leds.sh`, `suspend_schedule.sh`\
|
||||
#### `rev_kdb_leds.sh`, `suspend_schedule.sh`
|
||||
|
||||
Maintenant que vous savez lire des informations dans `/sys`, tentons d'aller
|
||||
modifier le comportement de notre système. Au choix, réalisez l'un des scripts
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ Nous allons voir dans cette partie plusieurs méthodes pour utiliser ces espaces
|
|||
de noms.
|
||||
|
||||
|
||||
#### Avec son coquillage\
|
||||
#### Avec son coquillage
|
||||
|
||||
De la même manière que l'on peut utiliser l'appel système `chroot(2)` depuis un
|
||||
shell via la commande `chroot(1)`, la commande `unshare(1)` permet de faire le
|
||||
|
|
@ -55,7 +55,7 @@ Nous avons pu ici modifier le nom de la machine, sans que cela n'affecte notre
|
|||
machine hôte.
|
||||
|
||||
|
||||
#### Les appels systèmes\
|
||||
#### Les appels systèmes
|
||||
|
||||
L'appel système par excellence pour contrôler l'isolation d'un nouveau
|
||||
processus est `clone(2)`.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
\newpage
|
||||
|
||||
Les espaces de noms -- *namespaces* {#namespaces}
|
||||
Les espaces de noms -- *namespaces*
|
||||
===================================
|
||||
|
||||
Nous avons vu un certain nombre de fonctionnalités offertes par le noyau Linux
|
||||
|
|
|
|||
|
|
@ -30,7 +30,6 @@ obtenir un descripteur de fichier valide vers le *namespace* (pour passer à
|
|||
|
||||
::::: {.question}
|
||||
#### Faire persister un *namespace* ? {-}
|
||||
\
|
||||
|
||||
Il n'est pas possible de faire persister un espace de noms d'un reboot à
|
||||
l'autre.\
|
||||
|
|
|
|||
|
|
@ -45,7 +45,7 @@ montage virtuels. Le changement de racine sera donc effectif uniquement dans
|
|||
cet espace de noms.
|
||||
|
||||
|
||||
#### L'environnement\
|
||||
#### L'environnement
|
||||
|
||||
Pour pouvoir changer de racine, il est nécessaire que la nouvelle racine soit
|
||||
la racine d'un point de montage, comme l'explique `pivot_root(2)`. En effet, il
|
||||
|
|
@ -75,7 +75,7 @@ Voici les grandes étapes du changement de racine :
|
|||
3. `pivot_root` !
|
||||
|
||||
|
||||
#### S'isoler\
|
||||
#### S'isoler
|
||||
|
||||
Notre but étant de démonter toutes les partitions superflues, nous allons
|
||||
devoir nous isoler sur :
|
||||
|
|
@ -95,7 +95,7 @@ Isolons-nous :
|
|||
</div>
|
||||
|
||||
|
||||
#### Dissocier la propagation des démontages\
|
||||
#### Dissocier la propagation des démontages
|
||||
|
||||
Attention ! avant de pouvoir commencer à démonter les partitions, il faut
|
||||
s'assurer que les démontages ne se propagent pas via une politique de *shared
|
||||
|
|
@ -111,13 +111,13 @@ comme esclaves :
|
|||
</div>
|
||||
|
||||
|
||||
#### Démonter tout !\
|
||||
#### Démonter tout !
|
||||
|
||||
À vous maintenant de démonter vos points d'attache. Il ne devrait vous rester
|
||||
après cette étape que : `/`, `/dev`, `/sys`, `/proc`, `/run` et leurs fils.
|
||||
|
||||
|
||||
#### Switch !\
|
||||
#### Switch !
|
||||
|
||||
À ce stade, dans votre console, vous avez plusieurs solutions : utiliser
|
||||
`switch_root(8)` ou `pivot_root(8)`. La première abstrait plus de choses que la
|
||||
|
|
|
|||
|
|
@ -151,7 +151,7 @@ partout, mais c'est loin d'être la technique la plus rapide ou la moins
|
|||
gourmande.
|
||||
|
||||
|
||||
#### VLAN\
|
||||
#### VLAN
|
||||
|
||||
Il est possible d'attribuer juste une interface de VLAN, si l'on a un switch
|
||||
supportant la technologie [802.1q](https://fr.wikipedia.org/wiki/IEEE_802.1Q)
|
||||
|
|
@ -166,7 +166,7 @@ derrière notre machine.
|
|||
</div>
|
||||
|
||||
|
||||
#### MACVLAN\
|
||||
#### MACVLAN
|
||||
|
||||
<!-- https://hicu.be/bridge-vs-macvlan -->
|
||||
|
||||
|
|
|
|||
|
|
@ -45,7 +45,7 @@ notre système initial. Pour s'en sortir, il est nécessaire de s'isoler dans un
|
|||
*namespace* `mount` séparé.
|
||||
|
||||
|
||||
#### Double isolation : ajout du *namespace* `mount`\
|
||||
#### Double isolation : ajout du *namespace* `mount`
|
||||
|
||||
Voici la nouvelle ligne de commande que l'on va utiliser :
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
#### Exemple C\
|
||||
#### Exemple C
|
||||
|
||||
Voici un exemple de code C utilisant `setns(2)` :
|
||||
|
||||
|
|
@ -36,7 +36,7 @@ main(int argc, char *argv[])
|
|||
</div>
|
||||
|
||||
|
||||
#### Exemple shell\
|
||||
#### Exemple shell
|
||||
|
||||
Dans un shell, on utilisera la commande `nsenter(1)` :
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ respectivement un *file descriptor* ou le chemin vers le fichier, lien
|
|||
symbolique, représentant l'espace de nom.
|
||||
|
||||
|
||||
#### Voir les *namespace*s d'un processus\
|
||||
#### Voir les *namespace*s d'un processus
|
||||
|
||||
Chaque processus lancé est rattaché à une liste d'espaces de nom, y compris
|
||||
s'il est issu du système de base (« l'hôte »).
|
||||
|
|
@ -55,7 +55,9 @@ Pour les commandes *shell*, il convient de donner en argument le chemin vers le
|
|||
lien symbolique : la commande se chargera d'`open(2)` le fichier.
|
||||
|
||||
|
||||
#### `*_for_children`\
|
||||
::::: {.question}
|
||||
|
||||
##### `*_for_children` {-}
|
||||
|
||||
Vous avez peut-être remarqué des fichiers `*_for_children` dans le dossier `ns`
|
||||
de vos processus. Nous verrons par la suite que les espaces de noms *PID* et
|
||||
|
|
@ -65,3 +67,5 @@ processus/threads fils.
|
|||
|
||||
`pid_for_children` et `time_for_children` représentent donc les *namespace*s
|
||||
qui seront attribués aux fils lancés après un `unshare(2)` réussi.
|
||||
|
||||
:::::
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
### Prérequis
|
||||
|
||||
|
||||
#### Noyau Linux \
|
||||
#### Noyau Linux
|
||||
|
||||
Pour pouvoir suivre les exercices ci-après, vous devez disposez d'un noyau
|
||||
Linux, idéalement dans sa version 5.6 ou mieux. Il doit de plus être compilé
|
||||
|
|
@ -55,7 +55,7 @@ Référez-vous, si besoin, à la précédente configuration que l'on a faite pou
|
|||
marche à suivre.
|
||||
|
||||
|
||||
#### Paquets \
|
||||
#### Paquets
|
||||
|
||||
Nous allons utiliser des programmes issus des
|
||||
[`util-linux`](https://www.kernel.org/pub/linux/utils/util-linux/), de
|
||||
|
|
@ -75,7 +75,7 @@ Sous ArchLinux et ses dérivés, ces paquets sont respectivement :
|
|||
* `libcap`
|
||||
|
||||
|
||||
#### À propos de la sécurité de l'espace de noms `user` \
|
||||
#### À propos de la sécurité de l'espace de noms `user`
|
||||
|
||||
La sécurité du *namespace* `user` a souvent été remise en cause par le passé,
|
||||
on lui attribue de nombreuses vulnérabilités. Vous devriez notamment consulter
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ garder dans le nouvel espace, que les utilisateurs et les groupes utiles au
|
|||
processus, en les renumérotant au passage si besoin.
|
||||
|
||||
|
||||
#### L'utilisateur -2 : *nobody*\
|
||||
#### L'utilisateur -2 : *nobody*
|
||||
|
||||
Lorsque l'on arrive dans un nouvel espace, aucun utilisateur ni groupe n'est
|
||||
défini. Dans cette situation, tous les identifiants d'utilisateur et de groupe,
|
||||
|
|
@ -45,7 +45,7 @@ l'utilisateur *nobody* et au groupe *nogroup*.
|
|||
non-modification d'un paramètre passé en argument d'une fonction.
|
||||
|
||||
|
||||
#### `uid_map` et `gid_map` \
|
||||
#### `uid_map` et `gid_map`
|
||||
|
||||
Pour établir la correspondance, une fois que l'on a créé le nouveau
|
||||
*namespace*, ces deux fichiers, accessibles dans `/proc/self/`, peuvent être
|
||||
|
|
|
|||
|
|
@ -59,11 +59,13 @@ docker swarm join-token worker
|
|||
Lançons maintenant la commande `join` indiquée, sur une autre machine, en
|
||||
utilisant `docker-machine`.
|
||||
|
||||
[^avertVM]: Si vous utilisez Docker dans une VM, il faut que celle-ci soit
|
||||
configurée en mode bridge pour qu'elle soit sur le même sous-réseau. Il n'y
|
||||
a pas de problème à avoir des nœuds *workers* derrière un NAT, mais il est
|
||||
primordial que les managers soient joignables. Vous pouvez tenter de faire
|
||||
des redirections de ports, mais le résultat n'est pas garanti !
|
||||
::::: {.warning}
|
||||
Si vous utilisez Docker dans une VM, il faut que celle-ci soit
|
||||
configurée en mode bridge pour qu'elle soit sur le même sous-réseau. Il n'y
|
||||
a pas de problème à avoir des nœuds *workers* derrière un NAT, mais il est
|
||||
primordial que les managers soient joignables. Vous pouvez tenter de faire
|
||||
des redirections de ports, mais le résultat n'est pas garanti !
|
||||
:::::
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
|
|
|
|||
|
|
@ -268,7 +268,7 @@ produit de notre compilation.
|
|||
L'image ainsi générée est minime, car elle ne contient rien d'autre que le
|
||||
strict nécessaire pour s'exécuter.
|
||||
|
||||
#### Étapes nommées\
|
||||
#### Étapes nommées
|
||||
|
||||
Nous avons utilisé `--from=0` pour désigner la première image de notre
|
||||
`Dockerfile`. Lorsque l'on réalise des montages plus complexes, on peut vouloir
|
||||
|
|
|
|||
|
|
@ -62,7 +62,7 @@ place.
|
|||
|
||||
### Ordonnez vos lignes de commandes complexes
|
||||
|
||||
#### Allez à la ligne pour séparer les longues lignes de commandes complexes\
|
||||
#### Allez à la ligne pour séparer les longues lignes de commandes complexes
|
||||
|
||||
Aérez vos `Dockerfile` !
|
||||
|
||||
|
|
@ -81,7 +81,7 @@ RUN apt-get update && apt-get install -y \
|
|||
|
||||
Notez les backslashs à la fin des lignes, indiquant qu'elle n'est pas terminée.
|
||||
|
||||
#### Triez les arguments par ordre alphabétique\
|
||||
#### Triez les arguments par ordre alphabétique
|
||||
|
||||
Lorsque c'est possible, ordonnez vos lignes suivant un ordre logique. Par
|
||||
exemple :
|
||||
|
|
|
|||
|
|
@ -40,7 +40,7 @@ chmod +x ~/.docker/cli-plugins/docker-buildx
|
|||
```
|
||||
</div>
|
||||
|
||||
#### Utilisation\
|
||||
#### Utilisation
|
||||
|
||||
Nous pouvons réutiliser le `Dockerfile` que vous avez écrit pour `youp0m`, en
|
||||
remplaçant simplement la ligne de `docker build` par celle-ci :
|
||||
|
|
@ -60,7 +60,7 @@ Actions* :\
|
|||
|
||||
:::::
|
||||
|
||||
#### Changer la syntaxe de nos `Dockerfile`\
|
||||
#### Changer la syntaxe de nos `Dockerfile`
|
||||
|
||||
Parfois on peut se sentir un peu frustré par la syntaxe des `Dockerfile` ou par
|
||||
son manque d'évolutivité. Avec BuildKit, il est possible de préciser un parseur
|
||||
|
|
@ -107,7 +107,7 @@ notamment :
|
|||
`Dockerfile`, et autres scripts de CI et de tests.
|
||||
|
||||
|
||||
#### `docker/dockerfile:1.3`\
|
||||
#### `docker/dockerfile:1.3`
|
||||
|
||||
La version habituelle de la syntaxe des `Dockerfile` est la version 1.1. En
|
||||
utilisant BuildKit, nous pouvons dès à présent passer à la version 1.2 (stable)
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user