Tutorial 1 ready for 2023
This commit is contained in:
parent
1e4154f133
commit
885a410b77
26 changed files with 462 additions and 256 deletions
|
|
@ -1,40 +1,56 @@
|
|||
\newpage
|
||||
|
||||
Composition de Docker
|
||||
---------------------
|
||||
|
||||
Docker est un écosystème d'outils de haut niveau, permettant d'utiliser des
|
||||
*conteneurs*.
|
||||
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
|
||||
domaine public lors des efforts de standardisation en 2015.
|
||||
|
||||
Docker est composé d'un daemon lancé au démarrage de votre machine, avec lequel
|
||||
vous interagissez 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.
|
||||
Commençons par planter le décor, en détaillant les principes de base de Docker.
|
||||
|
||||
Le client peut d'ailleurs ne pas être sur la même machine qui exécutera
|
||||
### Séparation des compétences
|
||||
|
||||
Le projet s'article 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.
|
||||
|
||||
::::: {.more}
|
||||
|
||||
Tous les programmes d'exécution de conteneurs n'utilisent pas une architecture
|
||||
avec un daemon et un client. `podman` que l'on peut généralement substituer à
|
||||
Docker n'emploie pas de daemon. Chaque utilisateur de la machine peut donc
|
||||
disposer de ses propres conteneurs, sans interférer avec ceux de ses voisins.
|
||||
|
||||
D'un point de vue de la sécurité, le daemon Docker est exécuté en tant que
|
||||
super-utilisateur. C'est sur ce daemon que repose la sécurité de la machine, ce
|
||||
qui peut être beaucoup de responsabilité. Gardez en tête que le modèle
|
||||
d'exécution de Docker n'est pas unique. Nous avons le choix.
|
||||
|
||||
:::::
|
||||
|
||||
Le processus client peut d'ailleurs ne pas être sur la même machine qui exécute
|
||||
effectivement les conteneurs.[^dockermachine]
|
||||
C'est ce qu'il se passe lorsqu'on utilise *Docker4Windows* ou *Docker4Mac* :
|
||||
C'est ce qu'il se passe lorsqu'on utilise Docker sur Windows ou macOS :
|
||||
une machine virtuelle Linux est lancée parallèlement au système de base et
|
||||
chaque commande `docker` tapée est passée au deamon dans la machine virtuelle.
|
||||
chaque commande `docker` tapée est passée au daemon dans la machine virtuelle.
|
||||
|
||||
[^dockermachine]: Il suffit de modifier la variable d'environnement
|
||||
`DOCKER_HOST` ou de passer le paramètre `-H` suivi de l'URL de la socket à
|
||||
`docker`. Voir aussi : <https://docs.docker.com/machine/overview/>
|
||||
|
||||
Commençons par planter le décor, en détaillant les principaux mécanismes de
|
||||
Docker.
|
||||
|
||||
|
||||
### Les images Docker
|
||||
|
||||
Une image Docker est un système de fichiers en lecture seule. Elle est formée
|
||||
d'un ensemble de couches, agrégées selon le principe d'UnionFS.
|
||||
Comme nous l'avons vu en introduction, les images sont un moyen de récupérer
|
||||
facilement un environnement d'exécution complet, prêt à l'emploi. Une image
|
||||
Docker donc est un système de fichiers en lecture seule.
|
||||
|
||||
Une image peut, par exemple, contenir :
|
||||
|
||||
* un système Ubuntu opérationnel,
|
||||
* le programme `busybox`,
|
||||
* un serveur web et votre application web, prêts à l'emploi,
|
||||
* votre site web personnel, prêt à l'emploi,
|
||||
* ...
|
||||
|
||||
Les images sont utilisées comme **modèle** qui sera ensuite dupliqué à chaque
|
||||
|
|
@ -43,36 +59,34 @@ fois que l'on démarrera un nouveau conteneur.
|
|||
Il y a deux méthodes pour obtenir des images Docker : soit les construire avec
|
||||
les outils fournis, soit les récupérer depuis un registre.
|
||||
|
||||
|
||||
### Les registres Docker (*Docker registries*)
|
||||
|
||||
Les registres sont des plates-formes de stockage, publiques ou privées,
|
||||
contenant des images. Ils permettent de récupérer des images, mais également
|
||||
d'en envoyer.
|
||||
|
||||
Le registre utilisé de base est le [Docker Hub](https://hub.docker.com/) : il
|
||||
contient à la fois des images officielles (ubuntu, debian, nginx, ...), des
|
||||
images créées par des utilisateurs, mais aussi des images de grands éditeurs,
|
||||
payantes, à destination des entreprises.
|
||||
|
||||
Des registres alternatifs existent comme celui de [quay.io](https://quay.io/search),
|
||||
et les dépôts de sources tels que
|
||||
[GitHub](https://github.blog/2020-09-01-introducing-github-container-registry/)
|
||||
et [GitLab](https://docs.gitlab.com/ee/user/packages/container_registry/) le
|
||||
proposent également.
|
||||
Lorsque vous ne précisez pas l'adresse d'un registre, Docker va aller chercher
|
||||
sur le [Docker Hub](https://hub.docker.com/). C'est son registre par défaut, chaque
|
||||
|
||||
|
||||
### Les conteneurs Docker
|
||||
### Les plugins Docker
|
||||
|
||||
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
|
||||
temporaire : l'image n'est pas modifiée par l'exécution d'un conteneur.
|
||||
L'architecture de Docker est devenue très modulable. Le projet est parti dans
|
||||
de nombreuses directions, chacun voulant tirer la couverture vers soit, et
|
||||
l'équipe maintenant le projet a parfois eu du mal à arbitrer les bonnes choses
|
||||
à ajouter ou non au projet.
|
||||
|
||||
{ width=70% }
|
||||
Afin de palier aux 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 composant de Docker.
|
||||
|
||||
Chaque conteneur s'exécute dans un environnement restreint et distinct de
|
||||
l'environnement principal (où vous avez votre bureau). Par exemple, dans cet
|
||||
environnement, vous ne pouvez pas voir les processus qui sont situés en dehors,
|
||||
ni accéder aux fichiers extérieurs.
|
||||
Certains plugins ajoutent des options à la ligne de commande (`docker-compose`,
|
||||
`docker-scan`, `docker-buildx` ...). D'autres ajoutent des typologies de
|
||||
réseaux, de gestion du stockage ou ajoutent de l'authentification.
|
||||
|
||||
Pour ajouter un plugin à Docker, il suffit de l'ajouter dans un sous-dossier de
|
||||
`/usr/lib/docker/cli-plugins` pour qu'il soit accessible à tous les
|
||||
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
|
||||
la commande `docker compose`, on téléchargera le plugin vers l'emplacement :
|
||||
`$HOME/.docker/cli-plugins/docker-compose`.
|
||||
|
||||
Plus récemment, de nouveaux plugins ont vu le jour et se basent directement sur
|
||||
des conteneurs que l'on peut télécharger depuis un registre d'images.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue