96 lines
4.2 KiB
Markdown
96 lines
4.2 KiB
Markdown
|
L'écosystème des conteneurs
|
|||
|
===========================
|
|||
|
|
|||
|
Pour entrer dans le monde des conteneurs, il faut bien saisir un certain nombre
|
|||
|
de concepts qui ont vu le jour progressivement, au fil des tentatives faites
|
|||
|
pour standardiser tout cet écosystème. Ce sont des notions importantes, car la
|
|||
|
plupart des outils utilisent d'une manière ou d'une autre ces concepts.
|
|||
|
|
|||
|
|
|||
|
Les images
|
|||
|
----------
|
|||
|
|
|||
|
Une image est une méthode pour distribuer un logiciel, qui s'apparente à un
|
|||
|
package. L'image contient les exécutables, mais aussi toutes les dépendances,
|
|||
|
les bibliothèques systèmes, les fichiers de configuration, ... Tout ce dont
|
|||
|
notre logiciel a besoin pour fonctionner.
|
|||
|
|
|||
|
Il existe différentes typologies d'images :
|
|||
|
|
|||
|
- certaines contiennent des logiciels ou des services prêts à l'emploi : le
|
|||
|
serveur web `nginx`, ou `apache`, ou encore la base de données MySQL, ou
|
|||
|
MongoDB, ...
|
|||
|
- certaines contiennent un programme spécifique : on peut vouloir utiliser
|
|||
|
`git`, le client `MySQL`, `emacs` ou bien encore le navigateur Chrome ;
|
|||
|
- d'autes enfin servent pour développer et étendre les possibilités. Ce sont
|
|||
|
souvent des images utilisées comme bases pour les deux types que l'on a vus :
|
|||
|
Debian, Alpine, Windows, ...
|
|||
|
|
|||
|
Il est aisé de s'échanger des images, ainsi tout le monde peut récupérer des
|
|||
|
images de ses logiciels favoris.
|
|||
|
|
|||
|
|
|||
|
Les registres
|
|||
|
-------------
|
|||
|
|
|||
|
Les registres sont des plateformes qui centralisent les images. Ils permettent
|
|||
|
de récupérer les images, ils disposent généralement d'une interface permettant
|
|||
|
de consulter leur catalogue, et ils permettent aussi d'en envoyer.
|
|||
|
|
|||
|
Les registres les plus connus sont le Docker Hub ou Quay.io. Ils contiennent à
|
|||
|
la fois :
|
|||
|
- des images officielles (`nginx`, `postgres`, ...) issues directement de leurs
|
|||
|
éditeurs,
|
|||
|
- des images communautaires, maintenues par les utilisateurs d'un logiciel,
|
|||
|
mais aussi,
|
|||
|
- des images de tout un chacun pour ses propres besoins.
|
|||
|
|
|||
|
D'autres registres existent en dehors de ces grands noms publics. Certaines
|
|||
|
forges telles que GitHub, GitLab ou Gitea proposent un service de registre que
|
|||
|
leurs utilisateurs peuvent utiliser pour publier les images liées à un
|
|||
|
projet. Cela permet aux utilisateurs de retrouver tous les produits de
|
|||
|
compilation au même endroit.
|
|||
|
|
|||
|
Enfin, chacun peut déployer son propre registre, qui peut alors avoir des
|
|||
|
droits d'accès restreint. Une entreprise peut vouloir déployer un registre
|
|||
|
privé lorsqu'elle utilise des conteneurs dans son infrastructure, mais qu'il
|
|||
|
n'est pas souhaitable que ses images soient diffusées.
|
|||
|
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
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
|
|||
|
pas de changements qui pourrait altérer son fonctionnement. L'idée directrice dans
|
|||
|
le design des conteneurs est de toujours être en mesure de pouvoir relancer un
|
|||
|
conteneur ailleurs et s'attendre exactement au même comportement.
|
|||
|
|
|||
|
Cela signifie que l'on ne fait par exemple pas de mise à jour dans un
|
|||
|
conteneur : lorsque notre application ou le système sous-jacent a besoin d'être
|
|||
|
mis à jour, on construit ou on télécharge une nouvelle image.
|
|||
|
|
|||
|
Ce qui distingue deux exécutions de la même image, ce sont les données que l'on
|
|||
|
donne au conteneur.
|
|||
|
|
|||
|
::::: {.question}
|
|||
|
|
|||
|
##### Tous les conteneurs utilisent ces principes ? {-}
|
|||
|
|
|||
|
Nous avons décrit ici les concepts propres aux conteneurs applicatifs. Dans le
|
|||
|
cas des conteneurs systèmes, leurs cycles de vie sont plus proches de l'usage que
|
|||
|
l'on peut avoir des machines virtuelles classiques : chaque conteneur démarre
|
|||
|
avec son historique (la manière dont il a été installé, les mises à jour qui
|
|||
|
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.
|
|||
|
|
|||
|
:::::
|