This commit is contained in:
parent
8c3ea223e5
commit
25aef1af17
54 changed files with 123 additions and 122 deletions
|
|
@ -14,7 +14,7 @@ privilégiés outrepassaient ces tests, tandis que les autres devaient passer le
|
|||
tests de l'*effective UID*, *effective GID*, et autres groupes
|
||||
supplémentaires...
|
||||
|
||||
Dans les années 90, ce système s'est rélévé être un peu trop basique et
|
||||
Dans les années 90, ce système s'est révélé être un peu trop basique et
|
||||
conduisait régulièrement à des abus, au moyen de vulnérabilités trouvées dans
|
||||
les programmes *setuid root*.
|
||||
|
||||
|
|
@ -41,7 +41,7 @@ contient les hashs des mots de passe).
|
|||
C'est ainsi qu'est apparu le `suid-bit` parmi les modes de fichiers. Lorsque
|
||||
ce bit est défini sur un binaire exécutable, au moment de l'exécution, le
|
||||
contexte passe à celui du propriétaire du fichier (`root` si le propriétaire
|
||||
est `root`, mais cela fonctionne quelque soit le propriétaire du fichier : on
|
||||
est `root`, mais cela fonctionne quel que soit le propriétaire du fichier : on
|
||||
ne devient pas `root`, mais bien l'utilisateur propriétaire).\
|
||||
|
||||
|
||||
|
|
@ -158,7 +158,7 @@ Tout d'abord, il faut noter que chaque *thread* dispose de 5 ensembles de
|
|||
|
||||
- ***inheritable*** (I) : est utilisé au moment de la résolution des *capabilities*
|
||||
lors de l'exécution d'un nouveau processus. Il s'agit des *capabilities* qui
|
||||
seront transmises au processus fil. À moins d'avoir la *capability*
|
||||
seront transmises au processus fils. À moins d'avoir la *capability*
|
||||
`CAP_SETPCAP`, cet ensemble ne peut pas avoir plus de *capability* que celles
|
||||
présentent dans l'ensemble *permitted* ;
|
||||
|
||||
|
|
@ -331,7 +331,7 @@ struct vfs_cap_data {
|
|||
La valeur `magic` contient la version sur 1 octet, puis 3 octets sont réservés
|
||||
pour des *flags*. Actuellement un seul *flag* existe, il s'agit de
|
||||
`VFS_CAP_FLAGS_EFFECTIVE` qui détermine si la liste effective de *capabilities*
|
||||
du programme doit être remplie avec les *capabilities* *permitted* si elle doit
|
||||
du programme doit être remplie avec les *capabilities* *permitted* ou si elle doit
|
||||
rester vide (auquel cas ce sera au programme de s'ajouter les *capabilities* au
|
||||
cours de l'exécution).\
|
||||
|
||||
|
|
@ -698,5 +698,5 @@ Et de ces quelques articles :
|
|||
<https://forums.grsecurity.net/viewtopic.php?f=7&t=2522#p10271>
|
||||
* [Linux Capabilities on HackTricks](https://book.hacktricks.xyz/linux-unix/privilege-escalation/linux-capabilities) :\
|
||||
<https://book.hacktricks.xyz/linux-unix/privilege-escalation/linux-capabilities>
|
||||
- [POSIX Access Control Lists on Linux](https://www.usenix.org/legacy/publications/library/proceedings/usenix03/tech/freenix03/full_papers/gruenbacher/gruenbacher_html/main.html) :\
|
||||
* [POSIX Access Control Lists on Linux](https://www.usenix.org/legacy/publications/library/proceedings/usenix03/tech/freenix03/full_papers/gruenbacher/gruenbacher_html/main.html) :\
|
||||
<https://www.usenix.org/legacy/publications/library/proceedings/usenix03/tech/freenix03/full_papers/gruenbacher/gruenbacher_html/main.html>
|
||||
|
|
|
|||
|
|
@ -88,7 +88,7 @@ La principale différence entre les deux est la fusion des différents
|
|||
sous-systèmes au sein d'une même arborescence. Dans la première version, chaque
|
||||
sous-système disposait de sa propre arborescence et il fallait créer les
|
||||
groupes et associer les tâches pour chaque sous-système. Avec la seconde
|
||||
version, une seule création est nécessaire, quelque soit le nombre de
|
||||
version, une seule création est nécessaire, quel que soit le nombre de
|
||||
sous-systèmes que l'on souhaite utiliser.
|
||||
|
||||
:::::
|
||||
|
|
@ -360,7 +360,7 @@ max
|
|||
```
|
||||
</div>
|
||||
|
||||
Chaque *cgroup*s définit de nombreux indicateurs et possède de nombreux
|
||||
Chaque *cgroup* définit de nombreux indicateurs et possède de nombreux
|
||||
limiteurs, n'hésitez pas à consulter la documentation associée à chaque
|
||||
*cgroup*.
|
||||
|
||||
|
|
|
|||
|
|
@ -58,7 +58,7 @@ d'avoir de quoi bidouiller : un shell sera amplement suffisant pour commencer.
|
|||
|
||||
### `busybox`
|
||||
|
||||
Queques mots, pour commencer, à propos du projet Busybox : c'est un programme
|
||||
Quelques mots, pour commencer, à propos du projet Busybox : c'est un programme
|
||||
couteau-suisse qui implémente tous les binaires vitaux pour avoir un système
|
||||
fonctionnel et utilisable : `ls`, `sh`, `cat`, mais aussi `init`, `mdev` (un
|
||||
`udev`-like, cela permet de découvrir les périphériques attachés afin de les
|
||||
|
|
@ -171,7 +171,7 @@ chroot newroot/ bash
|
|||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
tar xpf alpine-minirootfs-*.tar.xz -C newroot/
|
||||
tar xpf alpine-minirootfs-*.tar.gz -C newroot/
|
||||
```
|
||||
</div>
|
||||
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ Gestion de la mémoire
|
|||
Linux a une gestion de la mémoire bien particulière[^vm-overcommit] : en effet,
|
||||
par défaut, `malloc(3)` ne retournera jamais `NULL`. En se basant sur
|
||||
l'euristique qu'un bloc mémoire demandé ne sera pas utilisé directement et que
|
||||
de nombreux process ne feront pas un usage total des blocs qu'ils ont alloués,
|
||||
de nombreux processus ne feront pas un usage total des blocs qu'ils ont alloués,
|
||||
le noyau permet d'allouer plus de mémoire qu'il n'y en a réellement
|
||||
disponible. La mémoire est ainsi utilisée de manière plus efficace.
|
||||
|
||||
|
|
@ -21,7 +21,7 @@ trouve dans l'impossibilité d'attribuer un bloc physiquement disponible, car il
|
|||
n'y en a tout simplement plus (y compris via le swap).
|
||||
|
||||
Puisque le noyau ne peut pas honorer sa promesse et qu'il n'a plus la
|
||||
possibilité de retourner `NULL` au programme qui réclamme sa mémoire (il s'agit
|
||||
possibilité de retourner `NULL` au programme qui réclame sa mémoire (il s'agit
|
||||
sans doute d'une simple assignation de variable à ce stade), il faut trouver
|
||||
une solution si l'on veut pouvoir continuer l'exécution du programme.
|
||||
|
||||
|
|
@ -107,7 +107,7 @@ mémoire autorisée au sein du `cgroup` ?
|
|||
:::::
|
||||
|
||||
Eh oui, l'OOM-killer passe également lorsqu'un `cgroup` atteint la limite de
|
||||
mémoire qui lui est réservé. Dans ce cas évidemment, les processus pris en
|
||||
mémoire qui lui est réservée. Dans ce cas évidemment, les processus pris en
|
||||
compte sont ceux contenus dans le `cgroup`.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ Rendu
|
|||
|
||||
Est attendu d'ici le TP suivant :
|
||||
|
||||
- le rendu des exercice de ce TP ;
|
||||
- le rendu des exercices de ce TP ;
|
||||
- vos réponses à [l'évaluation du cours](https://virli.nemunai.re/quiz/14).
|
||||
|
||||
Pour les GISTRE (et en bonus pour les SRS), [un
|
||||
|
|
|
|||
|
|
@ -69,4 +69,4 @@ sur `rendu3`, ... ce qui vous permet d'avoir une arborescence
|
|||
correspondant à ce qui est demandé, sans pour autant perdre votre
|
||||
travail (ou le rendre plus difficile d'accès).
|
||||
|
||||
::::
|
||||
:::::
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ combinaison de chaque couche.
|
|||
|
||||
### Historique
|
||||
|
||||
Les premières implémentations de ce type de systèmes de fichiers est apparu
|
||||
Les premières implémentations de ce type de systèmes de fichiers sont apparues
|
||||
avec les LiveCD : on disposait d'une distribution Linux complètement
|
||||
opérationnelle sur un support en lecture seule, mais on pouvait dédier un
|
||||
espace de stockage sur son disque dur (ou en RAM, au travers d'un `tmpfs`) pour
|
||||
|
|
@ -42,7 +42,7 @@ Historiquement, le noyau Linux devait être *patché* pour supporter ce type de
|
|||
système de fichiers (que ce soit `unionfs` ou `aufs`, les deux principaux
|
||||
*patch* apportant cette fonctionnalité). Les systèmes BSD disposent d'une
|
||||
implémentation depuis au moins 1995 et c'est SunOS qui fut le premier OS à
|
||||
développer cette technique dès 1986 (pour un système de fichier appelé
|
||||
développer cette technique dès 1986 (pour un système de fichiers appelé
|
||||
*Translucent File Service*). Pour Linux, il aura fallu attendre 2014 pour voir
|
||||
l'arrivée du système de fichier OverlayFS dans un noyau sans *patch*.
|
||||
|
||||
|
|
|
|||
|
|
@ -79,7 +79,7 @@ processus se fait en fonction des *flags* qui sont passés. On retrouve donc :
|
|||
Le nom du *flag* `CLONE_NEWNS` est historique et assez peu explicite
|
||||
contrairement aux autres : il désigne en fait l'espace de nom `mount`.
|
||||
|
||||
Au départ, les *namespace*s ont étés pensés pour former un tout : une couche
|
||||
Au départ, les *namespace*s ont été pensés pour former un tout : une couche
|
||||
d'isolation complète pour les processus. Mais lors des développements suivants,
|
||||
il s'est avéré pratique de pouvoir choisir finement de quels aspects on
|
||||
souhaitait se dissocier.
|
||||
|
|
@ -108,7 +108,7 @@ semblable à :
|
|||
#define STACKSIZE (1024 * 1024)
|
||||
static char child_stack[STACKSIZE];
|
||||
|
||||
int clone_flags = CLONE_CGROUP | CLONE_NEWNET | SIGCHLD;
|
||||
int clone_flags = CLONE_NEWCGROUP | CLONE_NEWNET | SIGCHLD;
|
||||
|
||||
pid_t pid = clone(do_execvp, // First function executed by child
|
||||
child_stack + STACKSIZE, // Assume stack grows downward
|
||||
|
|
@ -155,7 +155,7 @@ extensions GNU :
|
|||
\
|
||||
|
||||
Lorsque l'on crée un nouveau processus, on ajoute l'option `SIGCHLD` afin
|
||||
d'être notifié par signal lorsque notre processus fil a terminé son
|
||||
d'être notifié par signal lorsque notre processus fils a terminé son
|
||||
exécution. Cela permet d'être réveillé de notre `wait(2)`.
|
||||
|
||||
:::::
|
||||
|
|
|
|||
|
|
@ -89,7 +89,7 @@ processus est rendu orphelin dans ce *namespace*, il devient un fils de ce
|
|||
processus, et non un fils de l'`init` de l'arbre global.
|
||||
|
||||
|
||||
#### L'espace de nom `network` {.unnumbered}
|
||||
#### L'espace de noms `network` {.unnumbered}
|
||||
|
||||
Depuis Linux 2.6.29.
|
||||
|
||||
|
|
@ -149,9 +149,9 @@ Lorsque l'on souhaite mesurer un écoulement de temps, la méthode naïve consis
|
|||
soustraction avec l'heure de fin. Cette technique fonctionne bien, à partir du
|
||||
moment où l'on est sûr que l'horloge ne remontera pas dans le temps, parce
|
||||
qu'elle se synchronise ou que le changement d'heure été/hiver
|
||||
intervient, ... Pour palier ces situations imprévisibles, le noyau expose une
|
||||
intervient, ... Pour pallier ces situations imprévisibles, le noyau expose une
|
||||
horloge dite monotone (`CLOCK_MONOTONIC`) : cette horloge démarre à un entier
|
||||
abstrait et s'incrèmente chaque seconde qui passe, sans jamais sauter de
|
||||
abstrait et s'incrémente chaque seconde qui passe, sans jamais sauter de
|
||||
secondes, ni revenir en arrière. C'est une horloge fiable pour calculer des
|
||||
intervalles de temps.
|
||||
|
||||
|
|
|
|||
|
|
@ -8,5 +8,5 @@ abstract: |
|
|||
Le but de cette seconde partie sur les mécanismes internes du noyau
|
||||
va nous permettre d'utiliser les commandes et les appels système
|
||||
relatifs aux espaces de noms du noyau Linux ainsi que d'appréhender
|
||||
la complexité des sytèmes de fichiers.
|
||||
la complexité des systèmes de fichiers.
|
||||
...
|
||||
|
|
|
|||
|
|
@ -40,7 +40,7 @@ Cette commande nous dévoile déjà de nombreuses choses :
|
|||
contenerisé » (dans un *namespace*). Le processus initial de la machine se
|
||||
retrouve donc dans des espaces de nom, tout comme les processus d'un conteneur.
|
||||
|
||||
- On aperçoit un genre de hiérarchie dans certain cas.
|
||||
- On aperçoit un genre de hiérarchie dans certains cas.
|
||||
|
||||
- La première colonne nous renseigne sur l'identifiant du *namespace*.
|
||||
|
||||
|
|
|
|||
|
|
@ -168,7 +168,7 @@ esclave ne propagera pas ses nouveaux points de montage à son *maître*.
|
|||
<div lang="en-US">
|
||||
```bash
|
||||
# Suite de l'exemple précédent
|
||||
cd /mnt/test-slave
|
||||
mkdir /mnt/test-slave
|
||||
|
||||
# Duplication de l'accroche, sans s'occuper des éventuels sous-accroches
|
||||
mount --bind /mnt/test-shared /mnt/test-slave
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ l'autre.
|
|||
:::::
|
||||
|
||||
Afin d'amener du réseau à notre nouvel espace de nom, il va falloir lui
|
||||
attribuer des interface. En fait, nous allons pouvoir déplacer nos interfaces
|
||||
attribuer des interfaces. En fait, nous allons pouvoir déplacer nos interfaces
|
||||
réseaux, dans le *namespace* vers lequel elle doit être accessible. Une
|
||||
interface donnée ne peut se trouver que dans un seul *namespace* à la fois.
|
||||
|
||||
|
|
@ -88,7 +88,7 @@ foo virli
|
|||
</div>
|
||||
|
||||
Les fichiers utilisés par `ip netns` ne sont donc rien de plus que des
|
||||
*bind-mount*. Ce qui explique qu'ils soient persistant même sans processus
|
||||
*bind-mount*. Ce qui explique qu'ils soient persistants même sans processus
|
||||
s'exécutant à l'intérieur.
|
||||
|
||||
:::::
|
||||
|
|
|
|||
|
|
@ -98,7 +98,7 @@ donc été alloué à un processus d'initialisation de `bash`, qui s'est termin
|
|||
depuis.\
|
||||
|
||||
Le comportement du noyau, lorsque le PID 1 se termine, est de lancer un *kernel
|
||||
panic* (car c'est un processus indispensable, notamment de part son rôle de
|
||||
panic* (car c'est un processus indispensable, notamment de par son rôle de
|
||||
parent pour tous les processus orphelin). Au sein d'un *namespace* `PID` qui
|
||||
n'est pas le *namespace* racine, le noyau appelle la fonction
|
||||
`disable_pid_allocation` qui retire le *flag* `PIDNS_HASH_ADDING` de l'espace
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ Vous allez continuer aujourd'hui le projet qui s'étendra depuis le TP précéde
|
|||
et qui consistera à réaliser la partie d'isolation de la moulinette des ACUs !
|
||||
|
||||
Cette semaine, il faudra faire en sorte de restreindre un groupe de processus
|
||||
pour qu'il s'exécute indépendemment de votre système.
|
||||
pour qu'il s'exécute indépendamment de votre système.
|
||||
|
||||
Il n'y a pas de restriction sur le langage utilisé, vous pouvez tout aussi bien
|
||||
utiliser du C, du C++, du Python, du shell, etc.
|
||||
|
|
|
|||
|
|
@ -62,4 +62,4 @@ sur `rendu4`, ... ce qui vous permet d'avoir une arborescence
|
|||
correspondant à ce qui est demandé, sans pour autant perdre votre
|
||||
travail (ou le rendre plus difficile d'accès).
|
||||
|
||||
::::
|
||||
:::::
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@ main(int argc, char *argv[])
|
|||
Ce programme prend au minimum deux arguments :
|
||||
- le chemin d'un fichier d'espace de nom que l'on souhaite rejoindre (le chemin
|
||||
vers le lien symbolique donc) ;
|
||||
- le programme (et ses arguments) que l'on souhaite souhaite exécuter une fois
|
||||
- le programme (et ses arguments) que l'on souhaite exécuter une fois
|
||||
que l'on a rejoint l'espace de noms ciblé.
|
||||
|
||||
Dans un premier temps, on ouvre le fichier passé en paramètre afin d'obtenir un
|
||||
|
|
|
|||
|
|
@ -14,6 +14,6 @@ abstract: |
|
|||
|
||||
Les exercices de ce cours sont à rendre au plus tard le mardi 15
|
||||
novembre 2022 à 23 h 42. Consultez les sections matérialisées par un
|
||||
bandeau jaunes et un engrenage pour plus d'informations sur les
|
||||
bandeau jaune et un engrenage pour plus d'informations sur les
|
||||
éléments à rendre.
|
||||
...
|
||||
|
|
|
|||
|
|
@ -62,9 +62,9 @@ Les conteneurs
|
|||
|
||||
On parle d'un conteneur pour désigner une instance en cours d'exécution.
|
||||
|
||||
Lorsqu'on lance un conteneur, une copie de l'image est créée sur le disque,
|
||||
puis le système crée une isolation, pour contenir et restreindre l'exécution
|
||||
aux seules données de l'image.
|
||||
Lorsqu'on lance un conteneur, une couche lecture/écriture est créée à partir
|
||||
de l'image, puis le système crée une isolation, pour contenir et restreindre
|
||||
l'exécution aux seules données de l'image.
|
||||
|
||||
Les conteneurs sont par nature **immuables** : on exécute le contenu d'une
|
||||
image déjà construite, on n'y change pas le code qui est exécuté et on n'y fait
|
||||
|
|
@ -90,6 +90,6 @@ avec son historique (la manière dont il a été installé, les mises à jour qu
|
|||
ont été appliquées, les configurations modifiées et les données qui ont été
|
||||
apportées au fil du temps ...). On ne peut pas dans ces circonstances
|
||||
remplacer un conteneur système par un autre, tout comme on ne peut pas
|
||||
remplacer une machine virtuelle que l'on a installée et configuré à la main.
|
||||
remplacer une machine virtuelle que l'on a installée et configurée à la main.
|
||||
|
||||
:::::
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
#### Que fait Drone pour « surveiller » un dépôt ? {-}
|
||||
\
|
||||
|
||||
Grâce aux permissions de que Drone a récupéré lors de la connexion OAuth à
|
||||
Grâce aux permissions que Drone a récupéré lors de la connexion OAuth à
|
||||
Gitea, il peut non seulement lire et récupérer le code des différents dépôts
|
||||
auxquels vous avez accès, mais il peut aussi changer certains paramètres.
|
||||
|
||||
|
|
@ -17,5 +17,5 @@ dépôt, sous l'onglet *Déclencheurs Web*.
|
|||
|
||||
À chaque fois qu'un événement va se produire sur le dépôt, Gitea va prévenir
|
||||
Drone qui décidera si l'évènement doit conduire à lancer l'intégration continue
|
||||
ou non, selon les instructions qu'on lui a donné dans la configuration du
|
||||
ou non, selon les instructions qu'on lui a données dans la configuration du
|
||||
dépôt.
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ lors que la compilation est terminée, car nous n'en faisons rien.
|
|||
|
||||
::::: {.exercice}
|
||||
|
||||
Ajoutons donc une nouvelle règle à notre `.droneci.yml` pour placer le binaire
|
||||
Ajoutons donc une nouvelle règle à notre `.drone.yml` pour placer le binaire
|
||||
au sein de la liste des fichiers téléchargeables aux côtés des tags.
|
||||
|
||||
Vous aurez sans doute besoin de :
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ en tête.\
|
|||
Ces contraintes : tant liées à la **sécurité** (il faut s'assurer
|
||||
qu'un service n'utilise pas une bibliothèque vulnérable par exemple, donc soit
|
||||
utilisé sur un système à jour, et qu'il ne tourne pas en `root`), qu'à la
|
||||
**disponibilité** (si le service est mal codé est contient beaucoup de fuites
|
||||
**disponibilité** (si le service est mal codé et contient beaucoup de fuites
|
||||
mémoire, il ne faut pas que les autres services présents sur la même machine en
|
||||
pâtissent).
|
||||
|
||||
|
|
@ -29,7 +29,7 @@ Le même principe est aussi valable pour Python, Ruby, ... : les développeurs
|
|||
ont toujours eu tendance à vouloir utiliser les dernières améliorations d'un
|
||||
langage, mais les administrateurs système n'ont alors pas de paquets stables
|
||||
dans la distribution. En effet, les distributions stables telles que Debian,
|
||||
RedHat ou CentOS ont des cycles de vie assez long et se concentrent plus sur la
|
||||
RedHat ou CentOS ont des cycles de vie assez longs et se concentrent plus sur la
|
||||
stabilité.\
|
||||
Cette stabilité est obtenue grâce à l'utilisation de versions éprouvées des
|
||||
langages et des bibliothèques, qui assurent un temps de maintenance et de
|
||||
|
|
@ -197,6 +197,6 @@ conçu par Netflix, qui est un programme qui va casser de manière aléatoire de
|
|||
é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 (brutalement certes) sa résilience. Cela oblige les développeurs, les
|
||||
opérationnels et les architectes à concevoir des services hautement tolérant
|
||||
opérationnels et les architectes à concevoir des services hautement tolérants
|
||||
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 !).
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
### Et ensuite ?
|
||||
|
||||
Nous avons vu une manière possible de distribuer notre projet. Essayons-en une
|
||||
autre parmis celles proposées.
|
||||
autre parmi celles proposées.
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ Vous pouvez néanmoins tester les plugins
|
|||
[`scp`](http://plugins.drone.io/appleboy/drone-scp/) ou
|
||||
[`ansible`](http://plugins.drone.io/drone-plugins/drone-ansible/) si vous avez
|
||||
une machine virtuelle avec une connexion SSH. N'hésitez pas à l'ajouter à votre
|
||||
`.droneci.yml`.
|
||||
`.drone.yml`.
|
||||
|
||||
|
||||
### Profitons !
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ La commande que nous allons utiliser pour lancer Renovatebot est la suivante :
|
|||
<div lang="en-US">
|
||||
```shell
|
||||
docker container run --name renovate --network my_ci_net \
|
||||
-e RENOVATE_ENDPOINT="http://gitea:3000/api/v1/" RENOVATE_PLATFORM=gitea \
|
||||
-e RENOVATE_ENDPOINT="http://gitea:3000/api/v1/" -e RENOVATE_PLATFORM=gitea \
|
||||
-e RENOVATE_TOKEN -e RENOVATE_GIT_AUTHOR="Renovatebot <renovate@sample>" \
|
||||
-e RENOVATE_AUTODISCOVER=true -e RENOVATE_LOG_LEVEL=info -d \
|
||||
renovate/renovate
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@ Dès que le conteneur sera lancé, nous devrions voir apparaître une ou plusieu
|
|||
*pull-requests* pour le projet `youp0m`. Si votre CI est configurée
|
||||
correctement, des tests automatiques seront lancés.
|
||||
|
||||
Le conteneur s'arrête dès qu'il a terminé d'analysé tous les dépôts. Vous
|
||||
Le conteneur s'arrête dès qu'il a terminé d'analyser tous les dépôts. Vous
|
||||
devrez le relancer si vous attendez une nouvelle action de la part de
|
||||
Renovatebot. Il est courant de le lancer entre chaque heure et 2 ou 4 fois par
|
||||
jour.
|
||||
|
|
@ -18,7 +18,7 @@ consultez la liste des éléments de configuration :
|
|||
|
||||
Ne soyez pas effrayé par la liste interminable d'options. Il est vrai que la
|
||||
première fois, on peut se sentir submergé de possibilités, mais il faut noter
|
||||
que le projet arriver avec des options par défaut plutôt correctes, et que l'on
|
||||
que le projet arrive avec des options par défaut plutôt correctes, et que l'on
|
||||
peut facilement avoir une configuration commune pour tous nos dépôts, à travers
|
||||
les *presets*.
|
||||
|
||||
|
|
@ -26,7 +26,7 @@ Un certain nombre de *presets* sont distribués par défaut, voici la liste
|
|||
(humainement lisible cette fois) :
|
||||
<https://docs.renovatebot.com/presets-default/>
|
||||
|
||||
Voici un exemple de configuration que vous pouvez utilisé comme base de tous
|
||||
Voici un exemple de configuration que vous pouvez utiliser comme base de tous
|
||||
vos projets :
|
||||
|
||||
<div lang="en-US">
|
||||
|
|
@ -69,7 +69,7 @@ Voici un exemple de fichier `default.json` que vous pourriez vouloir utiliser :
|
|||
Attention, on ne le répétera jamais assez, mais Renovatebot peut vite devenir
|
||||
infernal, car il va créer de nombreuses *pull-requests*, inlassablement. Il
|
||||
convient de rapidement activer la fusion automatique des mises à jour pour
|
||||
lesquelles vous avez confiances et pour lesquelles vous ne feriez qu'appuyer
|
||||
lesquelles vous avez confiance et pour lesquelles vous ne feriez qu'appuyer
|
||||
sur le bouton de fusion, sans même tester vous-même. La fonctionnalité est
|
||||
décrite en détail dans la documentation[^RENOVATE_AUTOMERGE] et explique les
|
||||
différentes stratégies. Néanmoins, il est nécessaire d'avoir une bonne suite de
|
||||
|
|
|
|||
|
|
@ -1,13 +1,13 @@
|
|||
Autres outils indispensables
|
||||
----------------------------
|
||||
|
||||
### Maintient à jour des dépendances
|
||||
### Maintien à jour des dépendances
|
||||
|
||||
Une opération fastidieuse, souvent oubliée sitôt le projet envoyé en
|
||||
production, c'est la mise à jour des dépendances applicatives. Fastidieux car
|
||||
il faut d'une part être informé qu'une mise à jour est disponible, c'est-à-dire
|
||||
qu'il faut suivre les mails, parfois nombreux, informant des nouvelles
|
||||
*releases*, parfois il s'agir de newslettre, ou encore parfois aucune
|
||||
*releases*, parfois il s'agit de newsletters, ou encore parfois aucune
|
||||
notification ne peut être programmée, il faut se rendre régulièrement sur un
|
||||
site pour savoir si oui ou non une mise à jour est disponible.
|
||||
|
||||
|
|
|
|||
|
|
@ -64,7 +64,7 @@ accès au périphérique correspondant au compteur.
|
|||
|
||||
### Conteneur LXC
|
||||
|
||||
LXC peut s'utiliser de multiple manière différentes, y compris avec des images
|
||||
LXC peut s'utiliser de multiples manières différentes, y compris avec des images
|
||||
OCI. Choisissez la méthode qui vous semble la plus appropriée, il est attendu
|
||||
au moins un script pour lancer notre conteneur, s'il est différent d'un
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@ Voici à quoi pourrait ressembler le playbook Ansible démarrant notre agent Dro
|
|||
|
||||
<div lang="en-US">
|
||||
```yaml
|
||||
- name: Launch drone runer
|
||||
- name: Launch drone runner
|
||||
docker_container:
|
||||
name: droneci-runner
|
||||
image: "drone/drone-runner-docker:1"
|
||||
|
|
|
|||
|
|
@ -44,10 +44,10 @@ fundation*, notamment les [Compute Module 3 et
|
|||
4](https://www.raspberrypi.com/products/compute-module-4/) et les [Raspberry Pi
|
||||
Zero 2 W](https://www.raspberrypi.com/products/raspberry-pi-zero-2-w/), ainsi
|
||||
que de nombreux PCB fait par l'entreprise, à base de micro-contrôleurs AVR,
|
||||
lorsqu'il est nécessaire de pour s'interfacer avec des équipements
|
||||
lorsqu'il est nécessaire pour s'interfacer avec des équipements
|
||||
propriétaires non prévu pour l'immotique.
|
||||
|
||||
Une grosse partie des travaux est donc réalisé avec un noyau Linux, sur du
|
||||
Une grosse partie des travaux est donc réalisée avec un noyau Linux, sur du
|
||||
matériel très performant, pour de l'embarqué.
|
||||
\
|
||||
|
||||
|
|
@ -68,7 +68,7 @@ entraver la stabilité de la plate-forme en cas de déploiement d'un module
|
|||
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
|
||||
des modules. (La partie déploiement continu, sera réalisée plus tard par
|
||||
l'équipe développant le nouveau système de base, suivant le meilleur outil que
|
||||
vous retiendrez.)
|
||||
\
|
||||
|
|
@ -90,5 +90,5 @@ quelques tests automatiques. Puis nous publierons automatiquement le binaire
|
|||
`linky2influx` comme fichier associé à un tag au sein de l'interface web du
|
||||
gestionnaire de versions.
|
||||
|
||||
Nous testerons enfin différentes solution pour déployer notre binaire, afin
|
||||
Nous testerons enfin différentes solutions pour déployer notre binaire, afin
|
||||
d'établir quelle est la solution adéquate.
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ le projet `youp0m`, que l'on connaît déjà bien.
|
|||
\
|
||||
|
||||
Dans un premier temps, on voudra juste compiler notre projet, pour s'assurer
|
||||
que chaque *commmit* poussé ne contient pas d'erreur de compilation (dans
|
||||
que chaque *commit* poussé ne contient pas d'erreur de compilation (dans
|
||||
l'environnement défini comme étant celui de production, donc avec une version
|
||||
précise des outils de compilation). Ensuite, nous ajouterons quelques tests
|
||||
automatiques, puis nous publierons automatiquement le binaire `youp0m` comme
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ docker container run -p 8086:8086 -d --name mytsdb influxdb:1.8
|
|||
::::: {.warning}
|
||||
|
||||
Remarquez que nous n'utilisons pas la version 2 d'InfluxDB. Sa mise en
|
||||
place est plus contraignantes pour faire de simples tests. Si vous
|
||||
place est plus contraignante pour faire de simples tests. Si vous
|
||||
souhaitez tout de même utiliser la dernière version de la stack TICK,
|
||||
vous pouvez consulter le `README` du conteneur sur le Docker Hub :\
|
||||
<https://hub.docker.com/_/influxdb>
|
||||
|
|
|
|||
|
|
@ -59,7 +59,7 @@ difficulté du rebond.
|
|||
|
||||
Un certain nombre de capabilities Linux sont retirées par Docker au
|
||||
moment de l'exécution du conteneur, on peut utiliser les options
|
||||
`--cap-add` et `--cap-drop` pour respectivement ajouter et retirer une
|
||||
`--cap-add` et `--cap-drop` pour respectivement ajouter et retirer des
|
||||
capabilities.
|
||||
|
||||
Notez que l'option `--privileged` ne retire aucune capabilities à
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ communauté, et parfois même appropriées par Docker.
|
|||
Dans cette partie, nous allons avoir besoin du plugin `docker-compose`.
|
||||
|
||||
L'équipe en charge du projet met à disposition un exécutable que nous pouvons
|
||||
téléchargeant depuis <https://github.com/docker/compose/releases>.
|
||||
télécharger depuis <https://github.com/docker/compose/releases>.
|
||||
|
||||
Ajoutez l'exécutable dans le dossier des plugins : `$HOME/.docker/cli-plugins`
|
||||
(sans oublier de `chmod +x` !).
|
||||
|
|
@ -21,7 +21,7 @@ Ajoutez l'exécutable dans le dossier des plugins : `$HOME/.docker/cli-plugins`
|
|||
|
||||
Autrefois, `docker-compose` était un script tiers que l'on utilisait
|
||||
indépendamment de Docker. Le projet, historiquement écrit en Python, a été
|
||||
entièrement réécrit récemment afin qu'il s'intégre mieux dans l'écosystème.
|
||||
entièrement réécrit récemment afin qu'il s'intègre mieux dans l'écosystème.
|
||||
|
||||
Vous trouverez encore de nombreux articles vous incitant à utiliser
|
||||
`docker-compose`. Dans la plupart des cas, vous pouvez simplement remplacer par
|
||||
|
|
|
|||
|
|
@ -44,5 +44,5 @@ s'agit d'un mécanisme de séries temporelles (*Time Series*) moderne, que l'on
|
|||
peut utiliser pour stocker toute sorte de données liées à un indice temporel.
|
||||
|
||||
La pile logicielle TICK propose de collecter des métriques, en les enregistrant
|
||||
dans une base de données adaptées et permet ensuite de les ressortir sous
|
||||
dans une base de données adaptée et permet ensuite de les ressortir sous
|
||||
forme de graphiques ou de les utiliser pour faire des alertes intelligentes.
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ Consulter les journaux
|
|||
----------------------
|
||||
|
||||
La première étape consiste bien souvent à regarder ce que le conteneur affiche
|
||||
sur ses sorties standard et d'erreur. Lorsqu'il est lancé en monde *daemon*, il
|
||||
sur ses sorties standard et d'erreur. Lorsqu'il est lancé en mode *daemon*, il
|
||||
convient d'utiliser la commande :
|
||||
|
||||
<div lang="en-US">
|
||||
|
|
@ -76,7 +76,7 @@ docker container top cntr_name
|
|||
```
|
||||
</div>
|
||||
|
||||
Cela liste tous les processus rattaché au conteneur nommé : à la fois les
|
||||
Cela liste tous les processus rattachés au conteneur nommé : à la fois les
|
||||
processus démarrés par le `run`, mais également les éventuels processus
|
||||
rattachés par `exec`.
|
||||
|
||||
|
|
|
|||
|
|
@ -38,9 +38,9 @@ ici, puisque c'est ce volume qui assure la persistance des images.
|
|||
|
||||
:::::
|
||||
|
||||
Nos images sont bien persistantes d'une instance à l'autre de notre contenu.
|
||||
Nos images sont bien persistantes d'une instance à l'autre de notre conteneur.
|
||||
|
||||
Nous voici prêt à déployer en production notre service, sans crainte de perdre
|
||||
Nous voici prêts à déployer en production notre service, sans crainte de perdre
|
||||
les jolies contributions. Mais... est-ce que ce sera suffisant pour répondre aux
|
||||
milliers de visiteurs attendus ?
|
||||
|
||||
|
|
|
|||
|
|
@ -42,16 +42,16 @@ docker container run --publish 8080:8080 registry.nemunai.re/youp0m
|
|||
</div>
|
||||
|
||||
Cet argument va faire effectuer à Docker une étape supplémentaire lorsqu'il
|
||||
démarerra le conteneur : il va devoir mettre en place une redirection du port
|
||||
démarrera le conteneur : il va devoir mettre en place une redirection du port
|
||||
de notre système local (8080) vers le port 8080 du conteneur.
|
||||
|
||||
{ width=70% }
|
||||
|
||||
::::: {.question}
|
||||
|
||||
#### Peut-on démarrer plusieurs conteurs utilisant le même port de notre système local ? {-}
|
||||
#### Peut-on démarrer plusieurs conteneurs utilisant le même port de notre système local ? {-}
|
||||
|
||||
Si l'on essai de lancer deux fois la commande de notre dernier `run`, nous
|
||||
Si l'on essaie de lancer deux fois la commande de notre dernier `run`, nous
|
||||
obtenons l'erreur suivante :
|
||||
|
||||
<div lang="en-US">
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@ Le daemon assemble ensuite l'image et met en place les différents éléments
|
|||
d'isolation pour préparer l'exécution de notre conteneur.
|
||||
|
||||
Enfin, il lance la commande qui sera le premier processus du conteneur. Cette
|
||||
commande fait parti des métadonnées de l'image. Le processus ainsi lancé est un
|
||||
commande fait partie des métadonnées de l'image. Le processus ainsi lancé est un
|
||||
peu particulier : il obtient les mêmes caractéristiques que le PID 1 de notre
|
||||
système ('init').
|
||||
|
||||
|
|
@ -57,7 +57,7 @@ afficher beaucoup de contenu pour faire son choix. Aussi, il est souvent plus
|
|||
pratique d'aller explorer les registres en passant directement par leur interface
|
||||
web.
|
||||
|
||||
Vous trouverez forcément votre bonheur parmi les images proposées par les deux
|
||||
Vous trouverez forcément votre bonheur parmi les images proposées par les trois
|
||||
principaux registres :
|
||||
|
||||
- <https://hub.docker.com/>
|
||||
|
|
@ -358,7 +358,7 @@ c'est toujours le daemon qui exécute directement les commandes et gère les
|
|||
entrées et sorties standards et d'erreur. Avec l'option `--interactive`, on
|
||||
s'assure que l'entrée standard ne sera pas fermée (`close(2)`). Nous demandons
|
||||
également l'allocation d'un TTY, sans quoi `bash` ne se lancera pas en mode
|
||||
interractif[^bashnointer].
|
||||
interactif[^bashnointer].
|
||||
|
||||
[^bashnointer]: Mais il sera possible de l'utiliser sans allouer de TTY, comme
|
||||
dans cet exemple :
|
||||
|
|
|
|||
|
|
@ -54,7 +54,7 @@ distribution :
|
|||
|
||||
### Sous Windows et macOS
|
||||
|
||||
Bien que les fonctionnalités de contenerisation de Docker que nous utiliserons
|
||||
Bien que les fonctionnalités de conteneurisation de Docker que nous utiliserons
|
||||
ne soient disponibles que sous Linux, il est possible d'utiliser Docker de
|
||||
manière déportée : le daemon Docker tournera dans une machine virtuelle Linux,
|
||||
mais vous pourrez interagir avec lui via votre ligne de commande habituelle.
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ indiquent que le service cherche à se connecter à une base de données. Il va
|
|||
donc falloir lier notre interface d'administration à [un conteneur
|
||||
MariaDB](https://hub.docker.com/_/mariadb).
|
||||
|
||||
Ne vous embêtez pas avec les mots de passes des services, initialisez la base
|
||||
Ne vous embêtez pas avec les mots de passe des services, initialisez la base
|
||||
de données avec le nom d'utilisateur et le mot de passe par défaut. Vous les
|
||||
obtiendrez en lisant la documentation de l'image fic-admin :
|
||||
<https://hub.docker.com/r/nemunaire/fic-admin/>
|
||||
|
|
|
|||
|
|
@ -3,12 +3,12 @@
|
|||
Stockage de données applicatives
|
||||
================================
|
||||
|
||||
Il est généralement toujours possible d'écrire dans le système de fichier de
|
||||
Il est généralement toujours possible d'écrire dans le système de fichiers de
|
||||
notre conteneur. (Cela n'affecte pas l'image, chaque conteneur est démarré à
|
||||
partir de l'image originale.) Cependant, il n'est pas recommandé de chercher à
|
||||
stocker des données ainsi. En effet, il n'est pas aisé de récupérer ces données
|
||||
une fois l'exécution du conteneur terminée ; les données peuvent même être
|
||||
détruite si on a lancé le conteneur avec l'option `--rm`.
|
||||
détruites si on a lancé le conteneur avec l'option `--rm`.
|
||||
|
||||
Docker met donc à notre disposition plusieurs mécanismes pour que les données
|
||||
de nos applications persistent et soient prêtes à être migrées d'un conteneur à
|
||||
|
|
|
|||
|
|
@ -3,14 +3,14 @@ Composition de Docker
|
|||
|
||||
Docker est une suite d'outils de haut niveau, permettant d'utiliser des
|
||||
*conteneurs*. Le projet en lui-même utilise de nombreuses dépendances,
|
||||
originellement développées par l'entreprise Docker Inc., puis laissé dans le
|
||||
originellement développées par l'entreprise Docker Inc., puis laissées dans le
|
||||
domaine public lors des efforts de standardisation en 2015.
|
||||
|
||||
Commençons par planter le décor, en détaillant les principes de base de Docker.
|
||||
|
||||
### Séparation des compétences
|
||||
|
||||
Le projet s'article autour d'un daemon lancé au démarrage de la machine, avec
|
||||
Le projet s'articule autour d'un daemon lancé au démarrage de la machine, avec
|
||||
lequel on interagit via un client (le programme `docker`). La communication
|
||||
entre le daemon et le client s'effectuant sur une API REST généralement au
|
||||
travers d'une socket.
|
||||
|
|
@ -71,7 +71,7 @@ de nombreuses directions, chacun voulant tirer la couverture vers soi, et
|
|||
l'équipe maintenant le projet a parfois eu du mal à arbitrer les bonnes choses
|
||||
à ajouter ou non au projet.
|
||||
|
||||
Afin de pallier aux besoins complémentaires, parfois accessoires, parfois
|
||||
Afin de pallier les besoins complémentaires, parfois accessoires, parfois
|
||||
salvateurs, un système de plugins a été intégré. Il permet d'appeler d'autres
|
||||
programmes comme s'il s'agissait de composants de Docker.
|
||||
|
||||
|
|
@ -85,7 +85,7 @@ utilisateurs de notre machine ou dans `$HOME/.docker/` si l'on veut l'installer
|
|||
seulement pour nous.
|
||||
|
||||
Par exemple, les plugins ajoutant des commandes iront dans
|
||||
`$HOME/.docker/cli-plugins`. Par exemple, si l'on souhaite pouvoir disposer de
|
||||
`$HOME/.docker/cli-plugins`. Si l'on souhaite pouvoir disposer de
|
||||
la commande `docker compose`, on téléchargera le plugin vers l'emplacement :
|
||||
`$HOME/.docker/cli-plugins/docker-compose`.
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
Un outil complet pour 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
|
||||
informations mises à disposition par les équipes de sécurité des principales
|
||||
distributions, cela alimente en continu une base de données qui sera accédé au
|
||||
moment de l'analyse.
|
||||
|
||||
|
|
@ -57,7 +57,7 @@ export POSTGRES_PASSWORD=$(openssl rand -base64 16)
|
|||
|
||||
Parmi les volumes partagés avec `clair`, il y a un dossier
|
||||
`./clair_config`. Notez le `./` au début, qui indique que le dossier sera
|
||||
recherché relativement par rapport à l'emplacement du `docker-compsose.yml`.
|
||||
recherché relativement par rapport à l'emplacement du `docker-compose.yml`.
|
||||
|
||||
Dans ce dossier, vous devez placer un exemplaire du fichier de configuration
|
||||
dont un [exemple se trouve dans le dépôt du
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ Open Container Initiative
|
|||
=========================
|
||||
|
||||
Formée en juin 2015, l'Open Container Initiative (OCI) a pour but d'établir le
|
||||
standard commun aux programmes de contenerisation, afin d'éviter une
|
||||
standard commun aux programmes de conteneurisation, afin d'éviter une
|
||||
fragmentation de l'écosystème.
|
||||
|
||||
## Spécifications
|
||||
|
|
@ -101,7 +101,7 @@ est utilisé pour sélectionner le bon manifest correspondant au système.
|
|||
|
||||
Le format des [couches de système de
|
||||
fichiers](https://github.com/opencontainers/image-spec/blob/master/layer.md)
|
||||
sont spécifiées : il est nécessaire de passer par des formats standards (comme
|
||||
est spécifié : il est nécessaire de passer par des formats standards (comme
|
||||
les tarballs), contenant éventuellement des fichiers et dossiers spéciaux
|
||||
représentant les modifications ou les suppressions éventuelles de la couche.
|
||||
|
||||
|
|
@ -125,5 +125,5 @@ Cela permet de récupérer des images, mais aussi d'en envoyer, en gérant
|
|||
|
||||
\
|
||||
|
||||
Nous allons voir plus en détails, dans les chapitres suivantes, ce que l'on
|
||||
Nous allons voir plus en détails, dans les chapitres suivants, ce que l'on
|
||||
peut tirer de ces spécifications, en décortiquant des usages précis.
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
Mise en place
|
||||
=============
|
||||
|
||||
Les exercices suivants nécessiteront l'installation de plusieurs outils..
|
||||
Les exercices suivants nécessiteront l'installation de plusieurs outils.
|
||||
|
||||
- `docker-compose`
|
||||
- `venv`
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ exécution. Puis, lorsqu'il aura terminé, celui-ci sera passé dans un statut
|
|||
|
||||
Parmi ses attributions, `init`, le PID 1 de notre système, est le processus qui
|
||||
récupère les processus orphelins du système. Lorsque le parent direct d'un
|
||||
processus meurt, ses fils sont reparenté sous le processus `init` et ils
|
||||
processus meurt, ses fils sont reparentés sous le processus `init` et ils
|
||||
obtiennent alors comme `ppid` 1. Ils ne conservent pas le PID de leur défunt
|
||||
parent.
|
||||
|
||||
|
|
@ -29,7 +29,7 @@ l'argument `PR_SET_CHILD_SUBREAPER`.
|
|||
:::::
|
||||
|
||||
Docker procure une isolation, notamment au travers du *namespace* PID : les
|
||||
processus faisant parti du même *namespace* ne voient seulement qu'une partie
|
||||
processus faisant partie du même *namespace* ne voient seulement qu'une partie
|
||||
de l'arbre de processus de l'hôte, et notamment, un PID 1 est recréé, il s'agit
|
||||
du premier processus à s'exécuter dans le *namespace*.
|
||||
|
||||
|
|
@ -107,7 +107,7 @@ shell.
|
|||
|
||||
Voici donc une raison supplémentaire de préférer `tini` à `bash` (ou à rien du
|
||||
tout). D'autant plus qu'à moins d'avoir préparé la fin d'exécution, `bash` ne
|
||||
retournera pas le code d'erreur de la commande que l'on a lancé, mais plutôt 0.
|
||||
retournera pas le code d'erreur de la commande que l'on a lancée, mais plutôt 0.
|
||||
|
||||
|
||||
## Intégration dans les `Dockerfile`
|
||||
|
|
@ -121,7 +121,7 @@ semble particulièrement indiqué.
|
|||
L'utilisation par le paramètre `--init` du `run` n'est pas recommandée et
|
||||
devrait se limiter aux cas où l'image a été construite par quelqu'un qui
|
||||
n'avait pas en tête ces contraintes. Lorsque l'on sait que des zombies ne vont
|
||||
pas être géré par leurs parents, le mainteneur se doit d'ajouter `tini` dans
|
||||
pas être gérés par leurs parents, le mainteneur se doit d'ajouter `tini` dans
|
||||
son `Dockerfile`. La méthode recommandée est de l'installer par les paquets de
|
||||
la distribution (`apt-get install tini`, `apk add tini`, ...). Néanmoins, dans
|
||||
le cas d'une distribution qui ne possèderait pas le paquet, il convient
|
||||
|
|
|
|||
|
|
@ -152,7 +152,7 @@ the selected base image
|
|||
</div>
|
||||
|
||||
Ce dernier exemple est sans appel : `mysql` est une image officielle, et sa
|
||||
dernière version à l'écriture de ses lignes contient pas moins de 24
|
||||
dernière version à l'écriture de ces lignes contient pas moins de 24
|
||||
vulnérabilités dont 9 *high* (pourtant corrigées dans des versions suivantes).
|
||||
|
||||
|
||||
|
|
@ -216,7 +216,7 @@ Total: 0 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 0, CRITICAL: 0)
|
|||
```
|
||||
</div>
|
||||
|
||||
Nous pouvons remarque que Trivy, en plus de faire l'analyse statique des
|
||||
Nous pouvons remarquer que Trivy, en plus de faire l'analyse statique des
|
||||
vulnérabilités de l'image, a aussi fait une analyse des dépendances du binaire
|
||||
`/srv/youp0m`.
|
||||
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@ chmod +x /usr/bin/docker-machine
|
|||
|
||||
### Support de KVM
|
||||
|
||||
Le programme support de base de nombreux environnement, dont VirtualBox et
|
||||
Le programme supporte de base de nombreux environnements, dont VirtualBox et
|
||||
Hyper-V. Bien d'autres environnements peuvent être supportés, au moyen de
|
||||
plug-ins.
|
||||
|
||||
|
|
|
|||
|
|
@ -54,7 +54,7 @@ iyue3rgd0ohs myWebS replicated 1/1 nginx:latest
|
|||
</div>
|
||||
|
||||
Vous pouvez constater que sur l'un des nœuds, sur lequel votre serveur aura été
|
||||
déployé, le tâche apparaît dans la liste des conteneurs !
|
||||
déployé, la tâche apparaît dans la liste des conteneurs !
|
||||
|
||||
|
||||
Rien de très excitant pour le moment, car nous ne pouvons pas vraiment accéder
|
||||
|
|
@ -86,8 +86,8 @@ particulièrement.
|
|||
Essayons de nous connecter aux ports 80 des deux IP correspondant à nos deux
|
||||
nœuds. Vous devriez voir la même page.
|
||||
|
||||
Lorsque plusieurs tâches s'exécutent pour ce service, le nœud d'entrée choisi
|
||||
selon un round-robin à quelle tâche il va diriger la requête. C'est grâce à ce
|
||||
Lorsque plusieurs tâches s'exécutent pour ce service, le nœud d'entrée choisit
|
||||
selon un round-robin vers quelle tâche il va diriger la requête. C'est grâce à ce
|
||||
mécanisme qu'il est possible de faire de la répartition de charge très
|
||||
simplement.
|
||||
|
||||
|
|
@ -103,7 +103,7 @@ consulter la documentation à ce sujet :\
|
|||
|
||||
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
|
||||
même service afin de mieux répartir la charge, idéalement sur des machines
|
||||
physiques différentes.
|
||||
|
||||
Ce qui se fait souvent avec beaucoup de douleur hors de Docker, se résume ici
|
||||
|
|
@ -172,5 +172,5 @@ services:
|
|||
</div>
|
||||
|
||||
Certaines informations comme les ressources, permettent à l'orchestrateur de
|
||||
mieux choisir le *workers* de destination, en fonction de certaines de ses
|
||||
mieux choisir le *worker* de destination, en fonction de certaines de ses
|
||||
caractéristiques.
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ Regroupés au sein d'un cluster (on parle de *swarm* pour Docker), chaque
|
|||
*Docker engine* représente un nœud (*node*) dans lequel on va déployer des
|
||||
*services*.
|
||||
|
||||
Certain nœuds ont un rôle de *manager*, parmi ceux-ci, un seul est élu leader et
|
||||
Certains nœuds ont un rôle de *manager*, parmi ceux-ci, un seul est élu leader et
|
||||
prendra les décisions d'orchestration. Les autres sont là pour prendre le
|
||||
relais en cas de dysfonctionnement sur le manager élu.
|
||||
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ Les `type`s que vous pouvez découvrir sont ceux que l'on a vu à la
|
|||
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
|
||||
et tel qu'il est actuellement (cela permet de se rendre compte lorsque les
|
||||
deux divergent).
|
||||
|
||||
|
||||
|
|
@ -110,7 +110,7 @@ kindnet-2gwlp 1/1 Running 0 13m
|
|||
```
|
||||
|
||||
Eh oui ! De nombreux services de base de Kubernetes tournent dans des
|
||||
conteneurs... qu'il gèren lui-même ! Notamment :
|
||||
conteneurs... qu'il gère lui-même ! Notamment :
|
||||
|
||||
- `etcd` : notre base de données clef/valeur,
|
||||
- `kube-apiserver` : l'API REST avec qui communique `kubectl`,
|
||||
|
|
@ -166,7 +166,7 @@ kubectl logs -f pingpong
|
|||
Notez ici l'option -f qui permet de suivre les logs en direct.
|
||||
|
||||
|
||||
Notre premier test ayant réussi, nous pouvons arrêter de DDos Cloudflare :
|
||||
Notre premier test ayant réussi, nous pouvons arrêter de DDoS Cloudflare :
|
||||
|
||||
```bash
|
||||
kubectl delete pods pingpong
|
||||
|
|
@ -211,16 +211,16 @@ haut niveau et sont là pour s'assurer que les migrations se font en douceur :
|
|||
elles vont permettre de basculer progressivement les *pod*s d'une version X à une
|
||||
version Y (par exemple si l'on change notre ping d'alpine 3.16 vers alpine
|
||||
edge), mais éventuellement de revenir sur la version X si besoin, en cours de
|
||||
migration. Elles délèguent ensuite aux *replicatsets* la gestion des *pod*s.
|
||||
migration. Elles délèguent ensuite aux *replicasets* la gestion des *pod*s.
|
||||
|
||||
Le *replicatset* est là pour indiquer le nombre de *pod*s que l'on désire et
|
||||
Le *replicaset* est là pour indiquer le nombre de *pod*s que l'on désire et
|
||||
s'assurer que le nombre de *pod*s actuellement lancé est bien en adéquation avec
|
||||
le nombre de *pod*s attendu.
|
||||
\
|
||||
|
||||
Pour résumer : `kubectl` a créé une tâche de déploiement
|
||||
`deploy/pingpong`. Cette tâche de déploiement a créé elle-même un *replicatset*
|
||||
`rs/pingpong-xxxx`. Ce *replicatset* a créé un *pod* `po/pingpong-yyyy`.
|
||||
`deploy/pingpong`. Cette tâche de déploiement a créé elle-même un *replicaset*
|
||||
`rs/pingpong-xxxx`. Ce *replicaset* a créé un *pod* `po/pingpong-yyyy`.
|
||||
|
||||
|
||||
#### Passage à l'échelle : facile ?
|
||||
|
|
@ -232,8 +232,8 @@ kubectl scale deploy/pingpong --replicas 3
|
|||
```
|
||||
|
||||
À ce stade, comme nous ne modifions que le nombre de replicats, Kubernetes va
|
||||
tout simplement propager ce nombre au *replicatset* existant. Puis, le
|
||||
*replicatset* voyant un décalage entre le nombre de *pod*s attendus et le nombre
|
||||
tout simplement propager ce nombre au *replicaset* existant. Puis, le
|
||||
*replicaset* voyant un décalage entre le nombre de *pod*s attendus et le nombre
|
||||
de *pod*s en cours d'exécution, il va en lancer de nouveaux, afin de répondre à
|
||||
la demande.
|
||||
\
|
||||
|
|
@ -245,11 +245,11 @@ kubectl delete pod pingpong-yyyy-zzz
|
|||
```
|
||||
|
||||
Cela supprime bien un *pod*, mais un autre est relancé instantanément car le
|
||||
*replicatset* constate une différence dans le nombre attendu.
|
||||
*replicaset* constate une différence dans le nombre attendu.
|
||||
|
||||
Si nous voulons arrêter de DDoS Google/Cloudflare, il ne s'agit pas de tuer
|
||||
chacun des *pod*s un par un, car de nouveaux seraient créés par le
|
||||
*replicatset*. Si l'on supprime le *replicatset*, la tâche de déploiement en
|
||||
*replicaset*. Si l'on supprime le *replicaset*, la tâche de déploiement en
|
||||
recréera un similaire (avec de nouveaux *pod*s).
|
||||
|
||||
Pour arrêter nos conteneurs, il convient donc de supprimer la tâche de
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ Vue d'ensemble de Kubernetes
|
|||
*Kubernetes* (prononcé Ku-ber-né-tice[^prononciation-k8s] en grec) est un
|
||||
système *open source* d'orchestration et de gestion de conteneurs. C'est-à-dire
|
||||
qu'il se charge de faire coller constamment la liste des conteneurs qu'il voit
|
||||
vivant aux spécifications qu'on lui aura demandées.
|
||||
vivants aux spécifications qu'on lui aura demandées.
|
||||
|
||||
[^prononciation-k8s]: <https://github.com/kubernetes/kubernetes/issues/44308>
|
||||
|
||||
|
|
@ -37,7 +37,7 @@ d’une série de nœuds *workers*.
|
|||
|
||||
Le(s) *control-plane(s)* sont en charge de prendre des décisions globales sur
|
||||
le déroulement des opérations du cluster : cela va de la détection d'anomalies
|
||||
sur le cluster ou encore le traiter d'événements et l'organisation de leur
|
||||
sur le cluster ou encore le traitement d'événements et l'organisation de leur
|
||||
réponse, ...
|
||||
|
||||
On retrouve sur ces nœuds centraux les composants suivants :
|
||||
|
|
@ -52,7 +52,7 @@ L'ordonnanceur
|
|||
disponibles.
|
||||
|
||||
Les contrôleurs
|
||||
: Ils vont contrôler l'état des différents composants déployées au sein du
|
||||
: Ils vont contrôler l'état des différents composants déployés au sein du
|
||||
cluster, pour s'assurer d'être dans l'état désiré. Il y a en fait plusieurs
|
||||
contrôleurs ayant chacun la responsabilité de veiller sur une partie des
|
||||
objets, ainsi que le `cloud-controller-manager` lorsque le cluster se trouve
|
||||
|
|
@ -65,11 +65,11 @@ Les contrôleurs
|
|||
\
|
||||
|
||||
|
||||
Chaque nœud (généralement, le nœud *master* est également *worker*) est utilisé
|
||||
Chaque nœud (généralement, le nœud *control-plane* est également *worker*) est utilisé
|
||||
via deux composants :
|
||||
|
||||
`kubelet`
|
||||
: C'est l'agent qui va se charger de créer les conteneurs et les manager, afin
|
||||
: C'est l'agent qui va se charger de créer les conteneurs et les gérer, afin
|
||||
de répondre aux spécifications demandées par les *control-planes*.
|
||||
|
||||
`kube-proxy`
|
||||
|
|
@ -109,14 +109,14 @@ supprimer ou de vérifier qu'une interface va bien.
|
|||
|
||||
Ainsi, à la création d'un conteneur, Kubernetes va laisser aux plugins CNI le
|
||||
loisir d'ajouter les interfaces réseaux adéquates, d'allouer l'adresse IP, de
|
||||
configurer les routes, les règles de pare-feu, ... quelque soit
|
||||
configurer les routes, les règles de pare-feu, ... quelle que soit
|
||||
l'infrastructure et la complexité du réseau utilisé derrière.
|
||||
\
|
||||
|
||||
Terminons en ajoutant qu'un serveur DNS faisant autorité est nécessaire pour
|
||||
que, de la même manière que Docker, il soit possible d'accéder aux autres
|
||||
conteneurs via leur nom (sans qu'il ne soit nécessaire de le déclarer sur un
|
||||
serveur de noms public). Il n'y a pas de projet de porté par Kubernetes pour
|
||||
serveur de noms public). Il n'y a pas de projet porté par Kubernetes pour
|
||||
cela, mais cette tâche est généralement assurée par
|
||||
[CoreDNS](https://coredns.io/).
|
||||
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ leurs infrastructures, choisissent de passer par un prestataire. L'entreprise
|
|||
délègue donc la gestion de son/ses cluster(s) à une autre entreprise, dont
|
||||
c'est le cœur de métier. La plupart du temps, il va s'agir d'Amazon (via
|
||||
[Elastic Kubernetes Service](https://aws.amazon.com/fr/eks/)), d'Azure
|
||||
[Kubernetes
|
||||
([Kubernetes
|
||||
Service](https://azure.microsoft.com/fr-fr/services/kubernetes-service/)) ou
|
||||
Google ([Kubernetes Engine](https://cloud.google.com/kubernetes-engine/)), mais
|
||||
d'autres acteurs plus petits existent aussi
|
||||
|
|
@ -38,7 +38,7 @@ fonctionne.\
|
|||
Chaque distribution de *Kubernetes* aura donc pris soin de mettre à disposition
|
||||
des composants pour un usage plus ou moins spécifique. En dehors des composants
|
||||
strictement nécessaires qui ne changent pas, on verra d'une distribution à
|
||||
l'autre des choix quant au moteur d'exécution de conteneurs (tantot CRI-O,
|
||||
l'autre des choix quant au moteur d'exécution de conteneurs (tantôt CRI-O,
|
||||
Containerd, KataContainers, ...), le réseau sera géré par une brique spécifique
|
||||
(Flannel, Calico, Canal, Wave, ...), le stockage peut également faire l'objet
|
||||
de choix.\
|
||||
|
|
@ -147,8 +147,9 @@ Server Version: Version.Info{Major:"1", Minor:"21", GitVersion:"v1.25.3", [...]
|
|||
```
|
||||
</div>
|
||||
|
||||
Par défaut, `kubectl` va tenter de contacter le port local 2375, `kind` aura
|
||||
pris soin de l'exposer pour vous au moment de la création du cluster.
|
||||
Par défaut, `kubectl` va utiliser le fichier `~/.kube/config` pour contacter
|
||||
l'API du cluster, `kind` aura pris soin de le configurer pour vous au moment
|
||||
de la création du cluster.
|
||||
|
||||
::::: {.warning}
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue