Fix orthograf and grammar thanks to grammalecte
This commit is contained in:
parent
3d8dd24b78
commit
aa925795d1
46 changed files with 121 additions and 121 deletions
|
|
@ -18,7 +18,7 @@ spécifique :
|
|||
- [`blkio` (`io` dans la v2)
|
||||
:](https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/blkio-controller.html)
|
||||
limites et statistiques de bande passante sur les disques ;
|
||||
- `cpu` : cycles CPU minimum garantis ;
|
||||
- `cpu` : cycles CPU minimums garantis ;
|
||||
- [`cpuacct` (inclus dans `cpu` dans la v2)
|
||||
:](https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/cpuacct.html)
|
||||
statistiques du temps CPU utilisé ;
|
||||
|
|
@ -55,7 +55,7 @@ l'une de ces trois situations :
|
|||
la nouvelle version des `cgroup`s.
|
||||
|
||||
- Votre dossier `/sys/fs/cgroup` contient d'autres dossiers au nom des
|
||||
sous-systèmes que l'on a listé ci-dessus : il s'agit des `cgroup`s v1.
|
||||
sous-systèmes que l'on a listés ci-dessus : il s'agit des `cgroup`s v1.
|
||||
|
||||
- Votre dossier `/sys/fs/cgroup` est vide ou inexistant, vous pouvez choisir
|
||||
d'utiliser la version de votre choix :
|
||||
|
|
@ -94,7 +94,7 @@ sous-systèmes que l'on souhaite utiliser.
|
|||
|
||||
### Création d'un nouveau groupe
|
||||
|
||||
Les *cgroup*s sont organisé autour d'une arborescence de groupe, où chaque
|
||||
Les *cgroup*s sont organisés autour d'une arborescence de groupe, où chaque
|
||||
groupe est représenté par un dossier. Il peut bien évidemment y avoir des
|
||||
sous-groupes, en créant des dossiers dans les dossiers existants, etc.\
|
||||
|
||||
|
|
@ -192,7 +192,7 @@ adaptés.
|
|||
### Consultation de l'état
|
||||
|
||||
En affichant le contenu du dossier `virli`, nous pouvions constater que
|
||||
celui-ci contenait déjà un certain nombre de fichiers. Certains d'entre-eux
|
||||
celui-ci contenait déjà un certain nombre de fichiers. Certains d'entre eux
|
||||
sont en lecture seule et permettent de lire des statistiques instantanées sur
|
||||
le groupe ; tandis que d'autres sont des propriétés que nous pouvons modifier.
|
||||
|
||||
|
|
@ -252,7 +252,7 @@ mémoire utilisée par le groupe monitoré.
|
|||
Vous pouvez utiliser un programme comme `memhog`[^memhog] pour remplir rapidement votre
|
||||
mémoire.
|
||||
|
||||
[^memhog]: Ce programme fait parti du paquet `numactl`, mais vous trouverez une
|
||||
[^memhog]: Ce programme fait partie du paquet `numactl`, mais vous trouverez une
|
||||
version modifiée plus adaptée à nos tests sur
|
||||
<https://nemunai.re/posts/slow-memhog>.
|
||||
|
||||
|
|
|
|||
|
|
@ -43,7 +43,7 @@ chroot newroot /busybox ash
|
|||
Nous voici donc maintenant dans un nouveau shell (il s'agit d'`ash`, le shell
|
||||
de `busybox`).
|
||||
|
||||
Jusque là ... ça fonctionne, rien de surprenant ! Mais qu'en est-il pour
|
||||
Jusque-là ... ça fonctionne, rien de surprenant ! Mais qu'en est-il pour
|
||||
`bash` :
|
||||
|
||||
<div lang="en-US">
|
||||
|
|
|
|||
|
|
@ -58,7 +58,7 @@ ce sujet :\
|
|||
#### À 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
|
||||
limites](#Fixer-des-limites) de mémoire que pouvaient réserver les processus de
|
||||
notre groupe. Que se passe-t-il alors si `memhog` dépasse la quantité de
|
||||
mémoire autorisée dans le `cgroup` ?
|
||||
|
||||
|
|
|
|||
|
|
@ -40,12 +40,12 @@ apporter des modifications.
|
|||
|
||||
Linux emploie de nombreux systèmes de fichiers virtuels :
|
||||
|
||||
- `/proc` : contient, principalement, la liste des processus (`top` et ses
|
||||
- `/proc` : contiens, principalement, la liste des processus (`top` et ses
|
||||
dérivés se contentent de lire les fichiers de ce point de montage) ;
|
||||
- `/proc/sys` : contient la configuration du noyau ;
|
||||
- `/sys` : contient des informations à propos du matériel (utilisées notamment
|
||||
- `/proc/sys` : contiens la configuration du noyau ;
|
||||
- `/sys` : contiens des informations à propos du matériel (utilisées notamment
|
||||
par `udev` pour peupler `/dev`) et des périphériques (taille des tampons,
|
||||
clignottement des DELs, ...) ;
|
||||
clignotement des DELs, ...) ;
|
||||
- `/sys/firmware/efi/efivars` : pour accéder et modifier les variables de
|
||||
l'UEFI ;
|
||||
- ...
|
||||
|
|
|
|||
|
|
@ -55,7 +55,7 @@ autorisé conduit à un `SIGKILL` du processus.
|
|||
|
||||
Plus modulable que le mode strict, le mode de filtrage permet une grande
|
||||
amplitude en permettant au programmeur de définir finement quels appels
|
||||
systèmes le programme est autorisé à faire ou non, et quel sentence est
|
||||
systèmes le programme est autorisé à faire ou non, et quelle sentence est
|
||||
exécutée en cas de faute.
|
||||
|
||||
Notons que les processus fils issus (`fork(2)` ou `clone(2)`) d'un processus
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ Utiliser les *namespace*s
|
|||
### S'isoler dans un nouveau *namespace*
|
||||
|
||||
Si l'on voit l'isolation procurée par les *namespace*s en parallèle avec les
|
||||
machines virtuelle, on peut se dire qu'il suffit d'exécuter un appel système
|
||||
machines virtuelles, on peut se dire qu'il suffit d'exécuter un appel système
|
||||
pour arriver dans un conteneur bien isolé. Cependant, le choix fait par les
|
||||
développeurs de Linux a été de laisser le choix des espaces de noms dont on veut
|
||||
se dissocier.
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
Le noyau tient à jour un compteur de références pour chaque *namespace*. Dès
|
||||
qu'une référence tombe à 0, la structure de l'espace de noms est
|
||||
automatiquement libérée, les points de montage sont démontés, les interfaces
|
||||
réseaux sont réattribués à l'espace de noms initial, ...
|
||||
réseaux sont réattribuées à l'espace de noms initial, ...
|
||||
|
||||
Ce compteur évolue selon plusieurs critères, et principalement selon le nombre
|
||||
de processus qui l'utilisent. C'est-à-dire que, la plupart du temps, le
|
||||
|
|
|
|||
|
|
@ -11,17 +11,17 @@ systèmes de fichiers.
|
|||
## Les points de montage
|
||||
|
||||
Au premier abord, les points de montage dans l'arborescence d'un système de
|
||||
fichiers n'ont pas l'air d'être remplis de notions complexes : un répertoire
|
||||
fichiers n'ont pas l'air d'être remplis de notions complexes : un répertoire
|
||||
peut être le point d'entrée d'un montage vers la partition d'un disque
|
||||
physique... ou d'une partition virtuelle, comme nous l'avons vu précédemment.
|
||||
|
||||
Mais avez-vous déjà essayé de monter la même partition d'un disque physique à
|
||||
deux endroits différents de votre arborescence ?
|
||||
deux endroits différents de votre arborescence ?
|
||||
|
||||
Si pour plein de raisons on pouvait se dire que cela ne devrait pas être
|
||||
autorisé, ce problème s'avère être à la base de beaucoup de fonctionnalités
|
||||
intéressantes. Le noyau va finalement décorréler les notions de montage,
|
||||
d'accès et d'accroche dans l'arborescence : et par exemple, une partition ne
|
||||
d'accès et d'accroche dans l'arborescence : et par exemple, une partition ne
|
||||
sera plus forcément démontée après un appel à `umount(2)`, mais le sera
|
||||
seulement lorsque cette partition n'aura plus d'accroches dans aucune
|
||||
arborescence.
|
||||
|
|
@ -64,7 +64,7 @@ TARGET SOURCE FSTYPE OPTIONS
|
|||
## `bind` -- montage miroir
|
||||
|
||||
Lorsque l'on souhaite monter à un deuxième endroit (ou plus) une partition, on
|
||||
utilise le *bind mount* :
|
||||
utilise le *bind mount* :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
|
|
@ -77,12 +77,12 @@ l'installe ou qu'on le répare via un *live CD*), il est nécessaire de duplique
|
|||
certains points de montage, tels que `/dev`, `/proc` et `/sys`.
|
||||
|
||||
Sans monter ces partitions, vous ne serez pas en mesure d'utiliser le système
|
||||
dans son intégralité : vous ne pourrez pas monter les partitions indiquées par
|
||||
dans son intégralité : vous ne pourrez pas monter les partitions indiquées par
|
||||
le `/etc/fstab`, vous ne pourrez pas utiliser `top` ou `ps`, `sysctl` ne pourra
|
||||
pas accorder les paramètres du noyau, ...
|
||||
|
||||
Pour que tout cela fonctionne, nous aurons besoin, au préalable, d'exécuter les
|
||||
commandes suivantes :
|
||||
commandes suivantes :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
|
|
@ -96,7 +96,7 @@ mount --bind /sys sys
|
|||
En se `chroot`ant à nouveau dans cette nouvelle racine, tous nos outils
|
||||
fonctionneront comme prévu.
|
||||
|
||||
Tous ? ... en fait non. Si l'on jette un œil à `findmnt(1)`, nous constatons
|
||||
Tous ? ... en fait non. Si l'on jette un œil à `findmnt(1)`, nous constatons
|
||||
par exemple que `/sys/fs/cgroup` dans notre nouvelle racine est vide, alors que
|
||||
celui de notre machine hôte contient bien les répertoires de nos *cgroups*.
|
||||
|
||||
|
|
@ -105,7 +105,7 @@ partie de celui-ci) à un autre endroit, sans se préoccuper des points de
|
|||
montages sous-jacents. Pour effectuer cette action récursivement, et donc
|
||||
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 :
|
||||
correct de lancer :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
|
|
@ -119,7 +119,7 @@ mount --rbind /sys sys
|
|||
|
||||
## Les types de propagation des points de montage
|
||||
|
||||
On distingue quatre variétés de propagation des montages pour un sous-arbre :
|
||||
On distingue quatre variétés de propagation des montages pour un sous-arbre :
|
||||
partagé, esclave, privé et non-attachable.
|
||||
|
||||
Chacun va agir sur la manière dont seront propagées les nouvelles accroches au
|
||||
|
|
@ -130,7 +130,7 @@ sein d'un système de fichiers attaché à plusieurs endroits.
|
|||
|
||||
Dans un montage partagé, une nouvelle accroche sera propagée parmi tous les
|
||||
systèmes de fichiers de ce partage (on parle de *peer group*). Voyons avec un
|
||||
exemple :
|
||||
exemple :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
|
|
@ -146,7 +146,7 @@ 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 :
|
||||
`/mnt/test-shared`, avec la politique `shared`, l'accroche sera propagée :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
|
|
@ -178,7 +178,7 @@ mount --make-slave /mnt/test-slave
|
|||
```
|
||||
</div>
|
||||
|
||||
Si l'on effectue un montage dans `/mnt/test-shared` :
|
||||
Si l'on effectue un montage dans `/mnt/test-shared` :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
|
|
@ -187,7 +187,7 @@ mount -t tmpfs none /mnt/test-shared/foo
|
|||
```
|
||||
</div>
|
||||
|
||||
Le point de montage apparaît bien sous `/mnt/test-slave/foo`. Par contre :
|
||||
Le point de montage apparaît bien sous `/mnt/test-slave/foo`. Par contre :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
|
|
@ -201,11 +201,11 @@ Le nouveau point de montage n'est pas propagé dans `/mnt/test-shared/bar`.
|
|||
|
||||
### privé -- *private mount*
|
||||
|
||||
C'est le mode le plus simple : ici les points de montage ne sont tout
|
||||
C'est le mode le plus simple : ici les points de montage ne sont tout
|
||||
simplement pas propagés.
|
||||
|
||||
Pour forcer un point d'accroche à ne pas propager et à ne pas recevoir de
|
||||
propagation, on utilise l'option suivante :
|
||||
propagation, on utilise l'option suivante :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
|
|
@ -224,7 +224,7 @@ mount --make-unbindable /mnt/test-slave
|
|||
```
|
||||
</div>
|
||||
|
||||
Il ne sera pas possible de faire :
|
||||
Il ne sera pas possible de faire :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
|
|
@ -238,7 +238,7 @@ mount --bind /mnt/test-slave /mnt/test-unbindable
|
|||
|
||||
Les options que nous venons de voir s'appliquent sur un point de montage. Il
|
||||
existe les mêmes options pour les appliquer en cascade sur les points d'attache
|
||||
contenus dans leur sous-arbre :
|
||||
contenus dans leur sous-arbre :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
|
|
@ -253,7 +253,7 @@ mount --make-runbindable mountpoint
|
|||
## Montage miroir de dossiers et de fichiers
|
||||
|
||||
Il n'est pas nécessaire que le point d'accroche que l'on cherche à dupliquer
|
||||
pointe sur un point de montage (c'est-à-dire, dans la plupart des cas : une
|
||||
pointe sur un point de montage (c'est-à-dire, dans la plupart des cas : une
|
||||
partition ou un système de fichiers virtuel). Il peut parfaitement pointer sur
|
||||
un dossier, et même sur un simple fichier, à la manière d'un *hardlink*, mais
|
||||
que l'on pourrait faire entre plusieurs partitions et qui ne persisterait pas
|
||||
|
|
@ -272,7 +272,7 @@ faire même si un fichier est en cours d'utilisation. Il faut cependant veiller
|
|||
à ce que les programmes susceptibles d'aller chercher un fichier à l'ancien
|
||||
emplacement soient prévenus du changement.
|
||||
|
||||
Pour déplacer un point de montage, on utilise l'option `--move` de `mount(8)` :
|
||||
Pour déplacer un point de montage, on utilise l'option `--move` de `mount(8)` :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
|
|
@ -280,7 +280,7 @@ mount --move olddir newdir
|
|||
```
|
||||
</div>
|
||||
|
||||
Par exemple :
|
||||
Par exemple :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
|
|
@ -289,7 +289,7 @@ mount --move /dev /newroot/dev
|
|||
</div>
|
||||
|
||||
Cette possibilité s'emploie notamment lorsque l'on souhaite changer la racine
|
||||
de notre système de fichiers : par exemple pour passer de l'*initramfs* au
|
||||
de notre système de fichiers : par exemple pour passer de l'*initramfs* au
|
||||
système démarré, de notre système hôte au système d'un conteneur, ...
|
||||
|
||||
|
||||
|
|
@ -299,6 +299,6 @@ Voici quelques articles qui valent le détour, en lien avec les points de
|
|||
montage :
|
||||
|
||||
* [Shared subtree](https://lwn.net/Articles/159077) (<https://lwn.net/Articles/159077>) et la
|
||||
[documentation du noyau associée](https://kernel.org/doc/Documentation/filesystems/sharedsubtree.txt) (<https://kernel.org/doc/Documentation/filesystems/sharedsubtree.txt>) ;
|
||||
* [Mount namespaces and shared subtrees](https://lwn.net/Articles/689856) : <https://lwn.net/Articles/689856> ;
|
||||
[documentation du noyau associée](https://kernel.org/doc/Documentation/filesystems/sharedsubtree.txt) (<https://kernel.org/doc/Documentation/filesystems/sharedsubtree.txt>) ;
|
||||
* [Mount namespaces and shared subtrees](https://lwn.net/Articles/689856) : <https://lwn.net/Articles/689856> ;
|
||||
* [Mount namespaces, mount propagation, and unbindable mounts](https://lwn.net/Articles/690679) : <https://lwn.net/Articles/690679>.
|
||||
|
|
|
|||
|
|
@ -63,7 +63,7 @@ des interfaces :
|
|||
Cette commande ne nous montre que l'interface de *loopback*, car nous 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à
|
||||
D'ailleurs, cette interface est rapportée comme étant désactivée, activons-la
|
||||
via la commande :
|
||||
|
||||
<div lang="en-US">
|
||||
|
|
@ -72,7 +72,7 @@ via la commande :
|
|||
```
|
||||
</div>
|
||||
|
||||
À ce stade, nous pouvons déjà commencer à lancer un `ping` sur cette interface:
|
||||
À ce stade, nous pouvons déjà commencer à lancer un `ping` sur cette interface :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
|
|
|
|||
|
|
@ -91,7 +91,7 @@ de noms.
|
|||
[^PR_SET_CHILD_SUBREAPER]: en réalité, ce comportement est lié à la propriété
|
||||
`PR_SET_CHILD_SUBREAPER`, qui peut être définie pour n'importe quel processus
|
||||
de l'arborescence. Le processus au PID 1 hérite forcément de cette propriété\ ;
|
||||
il va donc récupérer tous les orphelins, si aucun de leurs parents n'ont la
|
||||
il va donc récupérer tous les orphelins, si aucun de leurs parents n'a la
|
||||
propriété définie.
|
||||
|
||||
Lorsque l'on lance un processus via `nsenter(1)` ou `setns(2)`, cela crée un
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ symbolique, représentant l'espace de nom.
|
|||
#### 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 »).
|
||||
s'il est issu du système de base (« l'hôte »).
|
||||
|
||||
Nous pouvons dès lors consulter le dossier `/proc/<PID>/ns/` de chaque
|
||||
processus, pour consulter les différents espaces de nom de nos processus.
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
|
||||
#### Noyau Linux
|
||||
|
||||
Pour pouvoir suivre les exercices ci-après, vous devez disposez d'un noyau
|
||||
Pour pouvoir suivre les exercices ci-après, vous devez disposer d'un noyau
|
||||
Linux, idéalement dans sa version 5.6 ou mieux. Il doit de plus être compilé
|
||||
avec les options suivantes (lorsqu'elles sont disponibles pour votre version) :
|
||||
|
||||
|
|
|
|||
|
|
@ -57,7 +57,7 @@ Chez Google (et d'autres entreprises qui ont depuis repris l'idée), des équipe
|
|||
sont chargées de développer la fiabilité des systèmes d'information de
|
||||
production. Ce sont les équipes SRE, pour Site Reliability Engineering. On
|
||||
confie alors complètement la responsabilité de l'environnement de production
|
||||
aux développeurs qui sont chargés de l'automatiser. Au delà de l'automatisation
|
||||
aux développeurs qui sont chargés de l'automatiser. Au-delà de l'automatisation
|
||||
des déploiements de services, il s'agit ici de développer des mécanismes
|
||||
permettant au système de réagir face aux situations telles que les montées en
|
||||
charges, les pannes, ...
|
||||
|
|
@ -108,7 +108,7 @@ Dans le cas d'un programme à télécharger
|
|||
([Python](https://buildbot.python.org/all/#/), VLC,
|
||||
[MariaDB](https://buildbot.askmonty.org/buildbot/), ...), on va placer les
|
||||
paquets sur le site internet, éventuellement mettre à jour un fichier pointant
|
||||
vers la dernière version (pour que les utilisateurs aient la notifications).
|
||||
vers la dernière version (pour que les utilisateurs aient la notification).
|
||||
|
||||
Ou bien dans le cas d'un service en ligne (GitHub, Netflix, GMail, ...), il
|
||||
s'agira de mettre à jour le service.
|
||||
|
|
@ -166,7 +166,7 @@ outils.
|
|||
**Basée sur les métriques** comme ELK, Prometheus, InfluxDB, ... : dans la
|
||||
stack TICK que nous avons mis en place précédemment, nous avions placé un
|
||||
agent sur la machine que nous souhaitions analyser. Outre les graphiques
|
||||
présenté dans Chronograf, le dernier outil que l'on n'avait pas configuré était
|
||||
présentés dans Chronograf, le dernier outil que l'on n'avait pas configuré était
|
||||
Kapacitor, qui permet après avoir analysé les données, d'alerter en fonction
|
||||
d'une évolution.
|
||||
|
||||
|
|
@ -177,7 +177,7 @@ faire remonter dans sa base de données de métriques.
|
|||
\
|
||||
|
||||
La différence entre les deux techniques est que nagios va vous alerter à partir
|
||||
d'un certain seuil que vous aurez préalablement défini (s'il reste moins de 10%
|
||||
d'un certain seuil que vous aurez préalablement défini (s'il reste moins de 10 %
|
||||
d'espace disque par exemple), tandis que Kapacitor va tenter d'interpréter les
|
||||
indicateurs (et donc vous alerter seulement si la courbe représentant l'espace
|
||||
disque disponible augmente de telle sorte qu'il ne reste plus que quelques
|
||||
|
|
@ -193,7 +193,7 @@ Enfin, citons le [Chaos Monkey](https://fr.wikipedia.org/wiki/Chaos_Monkey),
|
|||
conçu par Netflix, qui est un programme qui va casser de manière aléatoire des
|
||||
éléments de l'environnement de production. Le but est de provoquer sciemment
|
||||
des pannes, des latences, ... à n'importe quel niveau du produit, afin d'en
|
||||
tester (brulatement certes) sa résilience. Cela oblige les développeurs, les
|
||||
tester (brutalement certes) sa résilience. Cela oblige les développeurs, les
|
||||
opérationnels et les architectes à concevoir des services hautement tolérant
|
||||
aux pannes, ce qui fait que le jour où une véritable panne survient, elle n'a
|
||||
aucun impact sur la production (enfin on espère !).
|
||||
|
|
|
|||
|
|
@ -72,7 +72,7 @@ docker run --rm -p 8080:8080 localhost:5000/youp0m
|
|||
|
||||
::::: {.question}
|
||||
On notera que ceci est possible exclusivement parce que le registre
|
||||
`localhost:5000` est considéré non-sûr par défaut. C'est à dire qu'il n'a pas
|
||||
`localhost:5000` est considéré non-sûr par défaut. C'est-à-dire qu'il n'a pas
|
||||
besoin de certificat TLS sur sa connexion HTTP pour être utilisé.\
|
||||
Si on avait dû utiliser un autre nom de domaine, il aurait fallu
|
||||
[l'ajouter à la liste des
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
Tout comme Gitea, Drone tire un certain nombre de paramètres depuis son
|
||||
environnement. Nous allons donc commencer par indiquer l'identifiant et le
|
||||
secret de l'application que l'on a créé précédemment dans Gitea :
|
||||
secret de l'application que l'on a créés précédemment dans Gitea :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
On remarquera que l'on partage notre socket Docker : l'exécution de code
|
||||
arbitraire n'aura pas lieu directement dans le conteneur, en fait il s'agit
|
||||
d'un petit orchetrateur qui lancera d'autres conteneurs en fonction des tâches
|
||||
d'un petit orchestrateur qui lancera d'autres conteneurs en fonction des tâches
|
||||
qu'on lui demandera. Le code arbitraire sera donc toujours exécuté dans un
|
||||
conteneur moins privilégié.
|
||||
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ moderne, conçue tout autour de Docker. Idéale pour nous !
|
|||
Deux conteneurs sont à lancer : nous aurons d'un côté l'interface de contrôle
|
||||
et de l'autre un agent (*runner* dans le vocabulaire de Drone) chargé
|
||||
d'exécuter les tests. Dans un environnement de production, on aura généralement
|
||||
plusieurs agents, et ceux-ci seront situé sur des machines distinctes.
|
||||
plusieurs agents, et ceux-ci seront situés sur des machines distinctes.
|
||||
|
||||
### Interface de contrôle et de dispatch des tâches
|
||||
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ gestionnaire de versions. Nous allons ici utiliser Git.
|
|||
|
||||
### Problématique du stockage des produits de compilation
|
||||
|
||||
Outre les interfaces rudimentaires fournies au dessus de Git
|
||||
Outre les interfaces rudimentaires fournies au-dessus de Git
|
||||
([gitweb](https://git.wiki.kernel.org/index.php/Gitweb)), il y a de nombreux
|
||||
projets qui offrent davantage que le simple hébergement de dépôts. Vous pouvez
|
||||
voir sur GitHub notamment qu'il est possible d'attacher à un tag un [certain
|
||||
|
|
|
|||
|
|
@ -7,18 +7,18 @@ Bienvenue dans la société Électropcool !
|
|||
|
||||
Électropcool est une société française spécialisée dans
|
||||
l'[immotique](https://fr.wikipedia.org/wiki/Immotique), elle vend des
|
||||
équipements IoT, principalement à destination des professionels du bâtiment. Le
|
||||
équipements IoT, principalement à destination des professionnels du bâtiment. Le
|
||||
produit phare est une plate-forme de
|
||||
[GTB](https://fr.wikipedia.org/wiki/Gestion_technique_de_b%C3%A2timent)
|
||||
modulaire de suivi de la vie d'un bâtiment où sont regroupés les différents
|
||||
compteurs, capteurs et actionneurs que l'on retrouve dans les installations.
|
||||
Les nouveaux bâtiments conçus autour la plate-forme permettent de faire de
|
||||
sérieuses économies d'entretien (en ne faisant déplacer les techiciens que
|
||||
sérieuses économies d'entretien (en ne faisant déplacer les techniciens que
|
||||
lorsque c'est nécessaire) tout en permettant d'anticiper les problèmes (grâce à
|
||||
un moteur de *machine-learning* capable d'anticiper les pannes) et les besoins
|
||||
en combustible (liés à la météo)[^HOMEASSISTANT].
|
||||
|
||||
[^HOMEASSISTANT]: Si ça vous met l'eau à la bouche, jettez un œil du côté du
|
||||
[^HOMEASSISTANT]: Si ça vous met l'eau à la bouche, jetez un œil du côté du
|
||||
projet <https://www.home-assistant.io/> qui fait un peu moins de
|
||||
*bullshit*, mais est bien réel !
|
||||
|
||||
|
|
@ -51,7 +51,7 @@ Une grosse partie des travaux est donc réalisé avec un noyau Linux, sur du
|
|||
matériel très performant, pour de l'embarqué.
|
||||
\
|
||||
|
||||
Tous les modules logiciels qui interragissent avec les capteurs sont
|
||||
Tous les modules logiciels qui interagissent avec les capteurs sont
|
||||
aujourd'hui intégrés dans un système construit à l'aide de
|
||||
[`bitbake`](https://www.yoctoproject.org/). L'entreprise grossissant à vue d'œil,
|
||||
il devient de plus en plus difficile de synchroniser les équipes concilier la
|
||||
|
|
@ -70,7 +70,7 @@ défaillant.
|
|||
Vous êtes également chargés de jeter les bases du système d'intégration continu
|
||||
des modules. (La partie déploiement continu, sera réalisé plus tard par
|
||||
l'équipe développant le nouveau système de base, suivant le meilleur outil que
|
||||
retiendrez.)
|
||||
vous retiendrez.)
|
||||
\
|
||||
|
||||
Le projet qui vous servira de base pour vos tests sera
|
||||
|
|
|
|||
|
|
@ -54,7 +54,7 @@ run`.
|
|||
|
||||
#### `volumes`
|
||||
|
||||
Cette section est le pendant de la commandes `docker volume`.
|
||||
Cette section est le pendant de la commande `docker volume`.
|
||||
|
||||
On déclare les volumes simplement en leur donnant un nom et un driver comme
|
||||
suit :
|
||||
|
|
@ -83,7 +83,7 @@ l'emplacement à partager :
|
|||
|
||||
#### `network`
|
||||
|
||||
Cette section est le pendant de la commandes `docker network`.
|
||||
Cette section est le pendant de la commande `docker network`.
|
||||
|
||||
Par défaut, Docker relie tous les conteneurs sur un bridge et fait du NAT pour
|
||||
que les conteneurs puissent accéder à l'Internet. Mais ce n'est pas le seul
|
||||
|
|
@ -113,7 +113,7 @@ les ports ouverts par la machine hôte.
|
|||
|
||||
Avec le driver `null`, la pile réseau est recréée et aucune interface (autre
|
||||
que l'interface de loopback) n'est présente. Le conteneur ne peut donc pas
|
||||
accéder à Internet, ni aux autres conteneur, ...
|
||||
accéder à Internet, ni aux autres conteneurs, ...
|
||||
|
||||
Lorsque l'on exécute un conteneur qui n'a pas besoin d'accéder au réseau, c'est
|
||||
le driver à utiliser. Par exemple pour un conteneur dont le but est de vérifier
|
||||
|
|
@ -127,7 +127,7 @@ conteneurs qui la référencent.
|
|||
|
||||
Avec cette configuration, les conteneurs ont accès à une résolution DNS des
|
||||
noms de conteneurs qui partagent leur bridge. Ainsi, sans avoir à utiliser la
|
||||
fonctionnalité de `link` au moment du `run`, il est possible de se retrouvé
|
||||
fonctionnalité de `link` au moment du `run`, il est possible de se retrouver
|
||||
lié, même après que l'on ait démarré. La résolution se fera dynamiquement.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -6,9 +6,9 @@ Orchestrer un groupe de conteneurs
|
|||
Maintenant que nous savons démarrer individuellement des conteneurs et les lier
|
||||
entre-eux, nous allons voir une première manière d'automatiser cela.
|
||||
|
||||
Plutôt que de lancer les commandes `docker` comme nous l'avons fait jusque là :
|
||||
Plutôt que de lancer les commandes `docker` comme nous l'avons fait jusque-là :
|
||||
soit directement dans un terminal, soit via un script, nous allons décrire
|
||||
l'état que nous souhaitons atteindre : quels images lancer, quels volumes
|
||||
l'état que nous souhaitons atteindre : quelles images lancer, quels volumes
|
||||
créer, quels réseaux, etc. Cette description peut s'utiliser pour lancer un
|
||||
conteneur seul, mais elle prend tout son sens lorsqu'il faut démarrer tout un
|
||||
groupe de conteneurs qui fonctionnent de concert, parfois avec des dépendances
|
||||
|
|
@ -31,7 +31,7 @@ génériques et pouvant facilement être mis à l'échelle.
|
|||
|
||||
Nous collecterons les données d'utilisation de votre machine avec
|
||||
[Telegraf](https://www.influxdata.com/time-series-platform/telegraf/). Ces
|
||||
données seront envoyés vers
|
||||
données seront envoyées vers
|
||||
[InfluxDB](https://www.influxdata.com/time-series-platform/influxdb/), puis
|
||||
elles seront affichées sous forme de graphique grâce à
|
||||
[Chronograf](https://www.influxdata.com/time-series-platform/chronograf/).
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ d'informations dépréciées.
|
|||
|
||||
Dans la mesure du possible, Docker essaie de ne pas encombrer inutilement votre
|
||||
disque dur avec les vieilles images qui ne sont plus utilisées. Il ne va
|
||||
cependant jamais supprimer une image encore liée à un conteneur ; il ne
|
||||
cependant jamais supprimer une image encore liée à un conteneur ; il ne
|
||||
supprimera pas non plus les conteneurs qui n'auront pas été démarrés avec
|
||||
l'option `--rm`.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
::::: {.exercice}
|
||||
|
||||
Pour mettre en pratiques toutes les notions que l'on a vu jusque là, écrivez un
|
||||
Pour mettre en pratiques toutes les notions que l'on a vues jusque-là, écrivez un
|
||||
script `mycloud-run.sh` pour automatiser le lancement de votre instance
|
||||
personnelle de [`nextcloud`](https://hub.docker.com/_/nextcloud/) ou
|
||||
d'[`owncloud`](https://hub.docker.com/r/owncloud/server/). Une attention
|
||||
|
|
@ -29,7 +29,7 @@ exemple).
|
|||
|
||||
L'exécution doit être la plus sécurisée possible (pas de port MySQL exposé sur
|
||||
l'hôte par exemple, etc.) et la plus respectueuse des bonnes pratiques que l'on
|
||||
a pu voir jusque là.
|
||||
a pu voir jusque-là.
|
||||
|
||||
|
||||
### Exemple d'exécution {-}
|
||||
|
|
|
|||
|
|
@ -45,9 +45,9 @@ docker image pull ubuntu
|
|||
|
||||
Les registres publics tels quel le Docker Hub mettent à disposition des images
|
||||
officielles, mais aussi des images créées par la communauté. Chaque utilisateur
|
||||
est libre d'envoyer une image qu'il a lui-même créé : soit car l'éditeur ne
|
||||
est libre d'envoyer une image qu'il a lui-même créée : soit car l'éditeur ne
|
||||
proposait pas d'image et que quelqu'un s'est dévoué pour la faire, soit parce
|
||||
qu'il avait des besoins plus spécifiques qui n'étaient pas couvert par l'image
|
||||
qu'il avait des besoins plus spécifiques qui n'étaient pas couverts par l'image
|
||||
originale. Il est important de garder en tête que vous téléchargez des
|
||||
exécutables, et bien qu'ils s'exécutent dans un environnement isolé, ils
|
||||
peuvent contenir du code malveillant.
|
||||
|
|
@ -62,7 +62,7 @@ assurez-vous d'avoir confiance dans la personne affiliée à l'image.**
|
|||
|
||||
Remarquez comment on interagit avec chaque *objet Docker* : dans la ligne de
|
||||
commande, le premier mot clef est le type d'objet (`container`, `image`,
|
||||
`service`, `network`, `volume`, ...) ; ensuite, vient l'action que l'on
|
||||
`service`, `network`, `volume`, ...) ; ensuite, vient l'action que l'on
|
||||
souhaite faire dans ce cadre.[^oldcall]
|
||||
|
||||
[^oldcall]: cela n'a pas toujours été aussi simple, cette syntaxe n'existe que
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ Installation
|
|||
Docker repose sur plusieurs techniques implémentées dans les noyaux Linux
|
||||
récents (et plus marginalement, Windows). Ces techniques, contrairement aux
|
||||
instructions de virtualisation qui rendent les hyperviseurs attractifs, ne sont
|
||||
pas limitées à une architecture de microprocesseur spécifique ; cependant la
|
||||
pas limitées à une architecture de microprocesseur spécifique ; cependant la
|
||||
communauté autour de Docker utilise principalement l'architecture `amd64`,
|
||||
c'est sur cette dernière que Docker pourra être exploité à son plein potentiel,
|
||||
suivi de près par l'architecture `arm64`.
|
||||
|
|
@ -97,7 +97,7 @@ Si vous rencontrez des difficultés pour vous lancer, le projet Play With
|
|||
Docker[^PlayWithDocker] vous donne accès à un bac à sable
|
||||
dans lequel vous pourrez commencer à faire les exercices à suivre.
|
||||
|
||||
[^PlayWithDocker]: Play With Docker est accessible à cette addresse : <https://labs.play-with-docker.com/>
|
||||
[^PlayWithDocker]: Play With Docker est accessible à cette adresse : <https://labs.play-with-docker.com/>
|
||||
|
||||
Il vous faudra disposer [d'un compte
|
||||
Docker](https://hub.docker.com/signup). Une fois identifié, vous pourrez créer
|
||||
|
|
|
|||
|
|
@ -1,10 +1,10 @@
|
|||
### Au secours, ça veut pas se connecter !
|
||||
|
||||
Lorsque nous lançons pour la première fois notre conteneur MySQL ou MariaDB, un
|
||||
script est chargé d'initialisé le volume attaché à `/var/lib/mysql`. Les
|
||||
démarrage suivant, ou si vous réutilisez un volume déjà initialisé avec une
|
||||
script est chargé d'initialiser le volume attaché à `/var/lib/mysql`. Les
|
||||
démarrages suivant, ou si vous réutilisez un volume déjà initialisé avec une
|
||||
base de données, le script ne refait pas d'initialisation. Même si les
|
||||
variables d'environnement ont changées.
|
||||
variables d'environnement ont changé.
|
||||
|
||||
Si vous rencontrez des difficultés pour connecter votre conteneur à
|
||||
`my-db`, prenez le temps de recréer un volume.
|
||||
|
|
|
|||
|
|
@ -21,11 +21,11 @@ Mais avant, regardons d'un peu plus près la gestion des réseaux par Docker.
|
|||
|
||||
## Les pilotes réseau
|
||||
|
||||
Docker propose de base trois pilotes (*drivers*) pour « gérer » cela :
|
||||
Docker propose de base trois pilotes (*drivers*) pour « gérer » cela :
|
||||
|
||||
- `none` : pour limiter les interfaces réseau du conteneur à l'interface de
|
||||
loopback `lo` ;
|
||||
- `host` : pour partager la pile réseau avec l'hôte ;
|
||||
loopback `lo` ;
|
||||
- `host` : pour partager la pile réseau avec l'hôte ;
|
||||
- `bridge` : pour créer une nouvelle pile réseau par conteneur et rejoindre un
|
||||
pont réseau dédié.
|
||||
|
||||
|
|
@ -64,7 +64,7 @@ directement accessible, sans avoir à utiliser l'option `-p` du `run`.
|
|||
### Créer un nouveau réseau `bridge`
|
||||
|
||||
Afin de contrôler quels échanges peuvent être réalisés entre les conteneurs, il
|
||||
est recommandé de créer des réseaux utilisateur.
|
||||
est recommandé de créer des réseaux utilisateurs.
|
||||
|
||||
La création d'un réseau se fait tout simplement au travers des sous-commandes
|
||||
relatives aux objets Docker `network` :
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ volumes.
|
|||
Il est possible d'utiliser la dernière couche en lecture/écriture pour inscrire
|
||||
des données. Il n'est cependant pas recommandé de stocker des données de cette
|
||||
manière, car elles ne vont pas persister une fois que le conteneur aura terminé
|
||||
son exécution ; elles seront alors plus compliquées à retrouver manuellement.
|
||||
son exécution ; elles seront alors plus compliquées à retrouver manuellement.
|
||||
|
||||
Docker met à notre disposition plusieurs mécanismes pour que les données de nos
|
||||
applications persistent et soient prêtes à migrer plus facilement vers une
|
||||
|
|
|
|||
|
|
@ -67,7 +67,7 @@ proposent également.
|
|||
Alors que les images constituent la partie immuable de Docker, les conteneurs
|
||||
sont sa partie vivante. Chaque conteneur est créé à partir d'une image : à
|
||||
chaque fois que nous lançons un conteneur, une couche lecture/écriture est
|
||||
ajoutée au dessus de l'image. Cette couche est propre au conteneur et
|
||||
ajoutée au-dessus de l'image. Cette couche est propre au conteneur et
|
||||
temporaire : l'image n'est pas modifiée par l'exécution d'un conteneur.
|
||||
|
||||
{ width=70% }
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
Un outil complet indexer et chercher des vulnérabilités est
|
||||
[`Clair`](https://github.com/coreos/clair/), du projet CoreOS. À partir des
|
||||
informations mises à disposition par les équipes de sécurités des principales
|
||||
distributions, cela alimente en continu une base de données qui sera accéder au
|
||||
distributions, cela alimente en continu une base de données qui sera accédé au
|
||||
moment de l'analyse.
|
||||
|
||||
L'outil se présente sous la forme d'un serveur autonome dans la récupération
|
||||
|
|
|
|||
|
|
@ -68,7 +68,7 @@ shell sur la machine !
|
|||
On notera cependant que, positionné dans `services`, le shell que nous
|
||||
obtiendrons sera lui-même exécuté dans un conteneur, nous n'aurons donc pas un
|
||||
accès entièrement privilégier. Pour déboguer, il faut placer cette image dans
|
||||
la partie `init`, elle sera alors lancé comme un équivalent de
|
||||
la partie `init`, elle sera alors lancée comme un équivalent de
|
||||
`init=/bin/sh`.[^infogetty]
|
||||
|
||||
[^infogetty]: Plus d'infos à
|
||||
|
|
@ -177,7 +177,7 @@ serveur SSH aux `services` :
|
|||
```
|
||||
</div>
|
||||
|
||||
Comme nous n'avons définis aucun mot de passe, il va falloir utiliser une clef
|
||||
Comme nous n'avons défini aucun mot de passe, il va falloir utiliser une clef
|
||||
SSH pour se connecter. Voilà un bon début d'utilisation de la section `files` :
|
||||
|
||||
<div lang="en-US">
|
||||
|
|
|
|||
|
|
@ -9,9 +9,9 @@ fragmentation de l'écosystème.
|
|||
|
||||
Trois spécifications ont été écrites :
|
||||
|
||||
- [`runtime-spec`](https://github.com/opencontainers/runtime-spec/blob/master/spec.md#platforms): définit les paramètres du démarrage d'un conteneur ;
|
||||
- [`image-spec`](https://github.com/opencontainers/image-spec/blob/master/spec.md): définit la construction, le transport et la préparation des images ;
|
||||
- [`distribution-spec`](https://github.com/opencontainers/distribution-spec/blob/master/spec.md): définit la manière dont sont partagées et récupérées les images.
|
||||
- [`runtime-spec`](https://github.com/opencontainers/runtime-spec/blob/master/spec.md#platforms): définis les paramètres du démarrage d'un conteneur ;
|
||||
- [`image-spec`](https://github.com/opencontainers/image-spec/blob/master/spec.md): définis la construction, le transport et la préparation des images ;
|
||||
- [`distribution-spec`](https://github.com/opencontainers/distribution-spec/blob/master/spec.md): définis la manière dont sont partagées et récupérées les images.
|
||||
|
||||
|
||||
## `runtime-spec`
|
||||
|
|
@ -47,7 +47,7 @@ Le
|
|||
[manifest](https://github.com/opencontainers/image-spec/blob/master/manifest.md)
|
||||
est toujours le point d'entrée d'une image : il référence l'emplacement où
|
||||
trouver les différents éléments : configuration et couches. Lorsqu'une même
|
||||
image a des variation en fonction de l'architecture du processeur, du système
|
||||
image a des variations en fonction de l'architecture du processeur, du système
|
||||
d'exploitation, ... dans ce cas [l'index
|
||||
d'image](https://github.com/opencontainers/image-spec/blob/master/image-index.md)
|
||||
est utilisé pour sélectionner le bon manifest.
|
||||
|
|
@ -78,8 +78,8 @@ aussi en envoyer.
|
|||
## Pour aller plus loin {-}
|
||||
|
||||
Si maintenant `docker` fait appel à un programme externe pour lancer
|
||||
effectivement nos conteneurs, c'est que l'on peut changer cette implémentation
|
||||
? la réponse dans l'article :\
|
||||
effectivement nos conteneurs, c'est que l'on peut changer cette
|
||||
implémentation ? la réponse dans l'article :\
|
||||
<https://ops.tips/blog/run-docker-with-forked-runc/>
|
||||
|
||||
Et `containerd` dans l'histoire ?\
|
||||
|
|
|
|||
|
|
@ -186,7 +186,7 @@ Pensez également à tester avec d'autres images, comme par exemple
|
|||
`nemunaire/youp0m`. Il vous faudra alors extraire plusieurs couches.
|
||||
|
||||
Pour gérer les différentes couches, vous pouvez utiliser une stratégie
|
||||
similaire au driver `vfs` : en extrayant chaque tarball l'une au dessus de
|
||||
similaire au driver `vfs` : en extrayant chaque tarball l'une au-dessus de
|
||||
l'autre, en essayant de gérer les *whiteout files*. Ou bien en suivant le
|
||||
driver `overlayfs`, en montant un système de fichier à chaque couche (dans ce
|
||||
cas, votre script devra être lancé en `root`).
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ montages ou volumes, ... Attention, son rôle reste limité à la mise en place
|
|||
l'environnement conteneurisé, ce n'est pas lui qui télécharge l'image, ni fait
|
||||
l'assemblage des couches de système de fichiers, entre autres.
|
||||
|
||||
Aujourd'hui, le lancement de conteneur est faite avec `runc`, mais il est
|
||||
Aujourd'hui, le lancement de conteneur est fait avec `runc`, mais il est
|
||||
parfaitement possible d'utiliser n'importe quel autre programme à sa place, à
|
||||
partir du moment où il expose la même interface à Docker et qu'il accepte les
|
||||
*bundle* OCI.
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ l'effort de cloisonnement mis en place.
|
|||
Mais doit-on pour autant s'arrêter là et considérer que nous avons réglé
|
||||
l'ensemble des problématiques de sécurité liées aux conteneurs ?
|
||||
|
||||
Évidemment, non : une fois nos services lancés dans des conteneurs, il ne sont
|
||||
Évidemment, non : une fois nos services lancés dans des conteneurs, ils ne sont
|
||||
pas moins exposés aux bugs et autres failles applicatives ; qu'elles soient
|
||||
dans notre code ou celui d'une bibliothèque, accessible par rebond, ...
|
||||
|
||||
|
|
@ -20,7 +20,7 @@ Il est donc primordial de ne pas laisser ses conteneurs à l'abandon une fois
|
|||
leur image créée et envoyée en production. Nos conteneurs doivent être
|
||||
regénérés sitôt que leur image de base est mise à jour (une mise à jour d'une
|
||||
image telle que Debian, Ubuntu ou Redhat n'apparaît que pour cela) ou bien
|
||||
lorsqu'un des programmes ou l'une des bibliothèques que l'on a installés
|
||||
lorsqu'un des programmes ou l'une des bibliothèques que l'on a installées
|
||||
ensuite est mise à jour.
|
||||
|
||||
Convaincu ? Cela sonne encore comme des bonnes pratiques difficiles à mettre en
|
||||
|
|
@ -191,7 +191,7 @@ Total: 158 (UNKNOWN: 5, LOW: 19, MEDIUM: 64, HIGH: 61, CRITICAL: 9)
|
|||
|
||||
Les résultats sont un peu différents qu'avec `docker scan`, mais on constate
|
||||
que l'image `mysql` contient vraiment de nombreuses vulnérabilités. Même si
|
||||
elles ne sont heureusement pas forcément exploitable directement.
|
||||
elles ne sont heureusement pas forcément exploitables directement.
|
||||
|
||||
Voyons maintenant s'il y a des différentes avec l'image `nemunaire/fic-admin` :
|
||||
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ notre machine hôte, même si ce n'est pas un Linux : le but va être de lancer
|
|||
plusieurs machines virtuelles dédiées à Docker pour simuler un cluster.
|
||||
|
||||
Ce programme permet de simplifier la gestion de multiples environnements
|
||||
Docker, comme par exmple lorsque l'on souhaite gérer un cluster de machines
|
||||
Docker, comme par exemple lorsque l'on souhaite gérer un cluster de machines
|
||||
pour un projet.
|
||||
|
||||
Ainsi, il est possible de provisionner et gérer des machines hôtes sur les
|
||||
|
|
@ -38,7 +38,7 @@ Hyper-V. Bien d'autres environnements peuvent être supportés, au moyen de
|
|||
plug-ins.
|
||||
|
||||
Si vous utilisez KVM comme hyperviseur, vous allez avoir besoin d'installer le
|
||||
plugins
|
||||
plugin
|
||||
[`docker-machine-kvm`](https://github.com/machine-drivers/docker-machine-kvm). Vous
|
||||
n'aurez qu'à suivre les instructions du `README` :\
|
||||
<https://github.com/machine-drivers/docker-machine-kvm/>
|
||||
|
|
|
|||
|
|
@ -101,7 +101,7 @@ consulter la documentation à ce sujet :\
|
|||
|
||||
#### Mise à l'échelle et placement
|
||||
|
||||
On parle depuis toute à l'heure de lancer plusieurs tâches pour le même
|
||||
On parle depuis tout à l'heure de lancer plusieurs tâches pour le même
|
||||
service. La mise à l'échelle, c'est ça : exécuter plusieurs conteneurs pour la
|
||||
même tâche afin de mieux répartir la charge, idéalement sur des machines
|
||||
physiques différentes.
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ Swarm.
|
|||
|
||||
#### Initialisation du cluster
|
||||
|
||||
La première chose à faire est d'initialiser un cluster Swarm. Pour se faire,
|
||||
La première chose à faire est d'initialiser un cluster Swarm. Pour ce faire,
|
||||
ce n'est pas plus compliqué que de faire :
|
||||
|
||||
<div lang="en-US">
|
||||
|
|
@ -46,7 +46,7 @@ attendant d'autres nœuds.
|
|||
Pour rejoindre un cluster, il est nécessaire d'avoir le jeton associé à ce
|
||||
cluster.
|
||||
|
||||
La commande pour rejoindre un cluster et contenant le jeton est iniquée
|
||||
La commande pour rejoindre un cluster et contenant le jeton est indiquée
|
||||
lorsque vous initialisez le cluster. Si vous avez raté la sortie de la
|
||||
commande, vous pouvez retrouver le jeton avec :
|
||||
|
||||
|
|
@ -102,7 +102,7 @@ Pour que l'algorithme de consensus fonctionne de manière optimale, il convient
|
|||
de toujours avoir un nombre impair de managers : Docker en recommande 3
|
||||
ou 5. La pire configuration est avec deux managers, car si l'un des deux tombe,
|
||||
il ne peut pas savoir si c'est lui qui est isolé (auquel cas il attendrait
|
||||
d'être à nouveau en ligne avant de se procalmer leader) ou si c'est l'autre qui
|
||||
d'être à nouveau en ligne avant de se proclamer leader) ou si c'est l'autre qui
|
||||
est tombé. Avec trois managers, en cas de perte d'un manager, les deux restants
|
||||
peuvent considérer qu'ils ont perdu le troisième et peuvent élire le nouveau
|
||||
manager entre eux et continuer à faire vivre le cluster.
|
||||
|
|
|
|||
|
|
@ -151,7 +151,7 @@ suivante.
|
|||
|
||||
Lorsqu'on lance la reconstruction du même `Dockerfile`, les images
|
||||
intermédiaires sont réutilisées, comme un cache d'instructions. Cela permet de
|
||||
gagner du temps sur les étapes qui n'ont pas changées. Ainsi, lorsque vous
|
||||
gagner du temps sur les étapes qui n'ont pas changé. Ainsi, lorsque vous
|
||||
modifiez une instruction dans votre `Dockerfile`, les instructions précédentes
|
||||
ne sont pas réexécutées mais sont ressorties du cache.
|
||||
|
||||
|
|
@ -164,7 +164,7 @@ Il est possible de ne pas utiliser le cache et de relancer toutes les étapes du
|
|||
`Dockerfile` en ajoutant l'option `--no-cache` au moment du `docker image
|
||||
build`.
|
||||
|
||||
Les couches du cache peuvent être partagées entre plusieurs conteneur, c'est
|
||||
Les couches du cache peuvent être partagées entre plusieurs conteneurs, c'est
|
||||
ainsi que vous pouvez partager facilement une plus grosse partie du système de
|
||||
fichiers (rappelez-vous le principe d'union FS).
|
||||
|
||||
|
|
@ -195,7 +195,7 @@ pour indiquer que c'est vous qui maintenez cette image, si des utilisateurs ont
|
|||
besoin de vous avertir pour le mettre à jour ou s'ils rencontrent des
|
||||
difficultés par exemple.
|
||||
|
||||
On le place dès le début, car comme c'est une information qui n'est pas amener
|
||||
On le place dès le début, car comme c'est une information qui n'est pas amenée
|
||||
à changer, elle sera toujours retrouvée en cache.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -4,12 +4,12 @@ Les bonnes pratiques
|
|||
--------------------
|
||||
|
||||
Pour chaque bonne pratique ci-dessous, vérifiez que vous la respectez
|
||||
bien, faites les modifications nécessaire dans votre `Dockerfile`.
|
||||
bien, faites les modifications nécessaires dans votre `Dockerfile`.
|
||||
|
||||
### Utilisez le fichier `.dockerignore`
|
||||
|
||||
Dans la plupart des cas, vos `Dockerfile` seront dans des dossiers contenant
|
||||
beaucoup de fichiers qui ne sont pas nécessaire à la construction de votre
|
||||
beaucoup de fichiers qui ne sont pas nécessaires à la construction de votre
|
||||
conteneur (par exemple, vous pouvez avoir un `Dockerfile` placé à la racine
|
||||
d'un dépôt git).
|
||||
|
||||
|
|
@ -22,7 +22,7 @@ vous utilisez un langage compilé, excluez également les produits de compilatio
|
|||
si votre image construit le binaire. Dans le cas de NodeJS, vous allez sans
|
||||
doute vouloir exclure le dossier `node_modules` et faire un `npm install` dans
|
||||
votre `Dockerfile`. Cela permettra au passage de s'assurer que toutes les
|
||||
dépendances ont bien été enregistrée.
|
||||
dépendances ont bien été enregistrées.
|
||||
|
||||
Ce fichier fonctionne de la même manière que le `.gitignore` : vous pouvez
|
||||
utiliser du globing.
|
||||
|
|
@ -123,7 +123,7 @@ Il y a un certain nombre de règles à connaître pour bien utiliser ce mécanis
|
|||
dans le `Dockerfile` vont être exécutées.
|
||||
|
||||
|
||||
### Concevez des conteneur éphémères
|
||||
### Concevez des conteneurs éphémères
|
||||
|
||||
Les conteneurs que vous générez doivent être aussi éphémères que possible : ils
|
||||
devraient pouvoir être arrêtés, détruits et recréés sans nécessiter d'étape de
|
||||
|
|
@ -155,7 +155,7 @@ modifier la configuration des autres logiciels contenu dans d'autres conteneurs
|
|||
puisqu'ils sont généralement configurés pour se connecter aux ports standards.
|
||||
|
||||
S'il y a un conflit sur la machine hôte, il sera toujours temps de créer une
|
||||
redirection à ce moment là.
|
||||
redirection à ce moment-là.
|
||||
|
||||
|
||||
### La bonne utilisation de l'`ENTRYPOINT`
|
||||
|
|
@ -165,7 +165,7 @@ utilisé de deux manières différentes :
|
|||
|
||||
- Vous pouvez l'utiliser de telle sorte que la commande passée au `docker run`,
|
||||
après le nom de l'image, corresponde aux arguments attendu par le programme
|
||||
indiqué dans l'*entrypoint*. Par exemple pour nginx :
|
||||
indiqué dans l'*entrypoint*. Par exemple pour `nginx` :
|
||||
|
||||
<div lang="en-US">
|
||||
```dockerfile
|
||||
|
|
@ -208,7 +208,7 @@ prendre deux formes :
|
|||
arguments. Si d'éventuels variables se trouve dans les arguments, elles ne
|
||||
seront pas remplacées.
|
||||
- `cmd arg1 arg2` : ici l'exécution se fera au sein d'un `sh -c`, donc les
|
||||
variables seront remplacés et étendues.
|
||||
variables seront remplacées et étendues.
|
||||
|
||||
Les commandes sous forme de tableau étant parsées par un parser JSON, vous ne
|
||||
pouvez pas utiliser les *simples quotes*.
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@ quelles versions de nos dépendances on va récupérer.
|
|||
[^SECURITY_UPDATE]: Voir cet article :
|
||||
<https://pythonspeed.com/articles/security-updates-in-docker/>
|
||||
|
||||
Si vous souhaitez disposez d'une nouvelle version de l'image, il est
|
||||
Si vous souhaitez disposer d'une nouvelle version de l'image, il est
|
||||
plutôt recommandé de contacter le mainteneur de l'image pour qu'il la
|
||||
mette à jour, en utilisant un nouveau tag s'il le juge nécessaire. Si
|
||||
cette solution n'est pas envisageable, alors il vaut mieux créer votre
|
||||
|
|
|
|||
|
|
@ -126,7 +126,7 @@ Faites en sorte que le `Dockerfile` que vous avez créé pour `youp0m` indique u
|
|||
|
||||
Il est aussi possible de se passer complètement de Docker. La plupart des
|
||||
outils qui sont capables de générer des images de machines virtuelles, sont
|
||||
aussi capable de générer des images Docker. Citons notamment :
|
||||
aussi capables de générer des images Docker. Citons notamment :
|
||||
|
||||
- [Hashicorp Packer](https://www.packer.io/docs/builders/docker),
|
||||
- [Nix et Guix](https://nix.dev/tutorials/building-and-running-docker-images),
|
||||
|
|
|
|||
|
|
@ -9,13 +9,13 @@ Découverte de `kubectl`
|
|||
programme que l'on utilise pour interagir avec notre cluster.
|
||||
|
||||
Étant donné qu'il s'agit d'un programme client, qui ne fait rien de plus que
|
||||
discuter avec une API REST HTTP, on peut le considérer comme un gros wrapper au
|
||||
dessus de `curl`.
|
||||
discuter avec une API REST HTTP, on peut le considérer comme un gros wrapper
|
||||
au-dessus de `curl`.
|
||||
|
||||
### Obtenir de l'aide
|
||||
|
||||
Commençons par apprivoiser `kubectl` en prenant quelques
|
||||
renseignements et surtout en apprennant comment obtenir de l'aide :
|
||||
renseignements et surtout en apprenant comment obtenir de l'aide :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
|
|
@ -25,7 +25,7 @@ kubectl explain type
|
|||
</div>
|
||||
|
||||
Les `type`s que vous pouvez découvrir sont ceux que l'on a vu à la
|
||||
sections précédentes : `node`, `pod`, ...
|
||||
section précédente : `node`, `pod`, ...
|
||||
|
||||
La commande `describe` permet d'afficher l'état tel qu'il est attendu
|
||||
et tel qu'il est actuellement (cela permet de se rendre lorsque les
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
::::: {.warning}
|
||||
|
||||
Notez que le dashboard, avec cette configuration, va s'exécuter sans les
|
||||
prérequis minimum de sécurité : pas de certificat TLS, ni
|
||||
prérequis minimums de sécurité : pas de certificat TLS, ni
|
||||
d'authentification. Ceci est juste pour jouer avec l'interface, en production,
|
||||
on n'utilisera pas cette recette.
|
||||
|
||||
|
|
@ -44,7 +44,7 @@ la partie `Service` un *node port* plus spécifique :
|
|||
```
|
||||
|
||||
Maintenant, nous n'allons pas recréer un nouveau dashboard : nous allons
|
||||
simplement « appliquer » la nouvelle configuration :
|
||||
simplement « appliquer » la nouvelle configuration :
|
||||
|
||||
```bash
|
||||
kubectl apply -f my-insecure-dashboard.yaml
|
||||
|
|
|
|||
|
|
@ -6,5 +6,5 @@ Présentation du fil rouge
|
|||
Afin d'évaluer Kubernetes, nous allons travailler avec un mineur de
|
||||
pépites ... de chocolat !
|
||||
|
||||
Alors, on se sert un bon thé, on prend sa boîte de gâteaux pour teniir le coup,
|
||||
Alors, on se sert un bon thé, on prend sa boîte de gâteaux pour tenir le coup,
|
||||
et c'est parti !
|
||||
|
|
|
|||
|
|
@ -45,7 +45,7 @@ utiliser Kubernetes facilement :
|
|||
|
||||
### Docker for Mac/Windows {#dockerdesktop}
|
||||
|
||||
*Docker Desktop* pour Mac ou pour Windows intégre Kubernetes directement. Il
|
||||
*Docker Desktop* pour Mac ou pour Windows intègre Kubernetes directement. Il
|
||||
n'est pas activé par défaut, pour cela il convient d'activer l'option dans les
|
||||
préférences de l'application :
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue