{"id":91905,"date":"2020-08-20T07:42:23","date_gmt":"2020-08-20T05:42:23","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/chto-takoe-docker-kratkij-ekskurs-v-istoriyu-i-osnovnye-abstrakczii"},"modified":"2020-08-20T07:42:23","modified_gmt":"2020-08-20T05:42:23","slug":"chto-takoe-docker-kratkij-ekskurs-v-istoriyu-i-osnovnye-abstrakczii","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/chto-takoe-docker-kratkij-ekskurs-v-istoriyu-i-osnovnye-abstrakczii","title":{"rendered":"Qu'est-ce que Docker : aper\u00e7u de l'histoire et des principales abstractions","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Le 10 ao\u00fbt, un cours vid\u00e9o sur Docker<\/a><\/noindex>, dans lequel nous l'explorons en profondeur \u2014 des abstractions de base aux param\u00e8tres r\u00e9seau. <\/p>\n

<\/p>\n

Dans cet article, nous discuterons de l'histoire de Docker et de ses principales abstractions : Image, Cli, Dockerfile. La le\u00e7on est destin\u00e9e aux d\u00e9butants, elle ne sera donc probablement pas int\u00e9ressante pour les utilisateurs exp\u00e9riment\u00e9s. Il n'y aura pas de d\u00e9tails techniques complexes, juste les fondamentaux.<\/p>\n

<\/p>\n

\"Qu'est-ce<\/p>\n

<\/a><\/noindex><\/p>\n

Qu'est-ce que Docker<\/h2>\n

<\/p>\n

Voyons la d\u00e9finition de Docker sur Wikip\u00e9dia.<\/p>\n

<\/p>\n

Docker est un logiciel permettant d'automatiser le d\u00e9ploiement et la gestion des applications dans des environnements prenant en charge la containerisation.<\/p><\/blockquote>\n

Cette d\u00e9finition peut sembler floue. En particulier, il n'est pas clair ce que signifie \u00ab dans des environnements prenant en charge la containerisation \u00bb. Pour mieux comprendre, revenons en arri\u00e8re. Commen\u00e7ons par une \u00e9poque que j'appelle 'l'\u00e8re monolithique'.<\/p>\n

<\/p>\n

L'\u00e8re monolithique<\/h2>\n

<\/p>\n

L'\u00e8re monolithique correspond au d\u00e9but des ann\u00e9es 2000, lorsque toutes les applications \u00e9taient monolithiques et comportaient de nombreuses d\u00e9pendances. Le d\u00e9veloppement \u00e9tait long. Par ailleurs, nous avions peu de serveurs, et nous les connaissions tous par leur nom et les surveillons. Il existe une comparaison amusante :<\/p>\n

\n

\r\n \"Lire\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

Les animaux de compagnie \u2014 c'est comment nous d\u00e9crivons nos serveurs. \u00c0 l'\u00e8re monolithique, nous les traitions comme des animaux de compagnie, en prenant soin d'eux et en les chouchoutant. Pour mieux g\u00e9rer les ressources, nous utilisions la virtualisation : nous prenions un serveur et le portions en plusieurs machines virtuelles, assurant ainsi l'isolation de l'environnement.<\/p>\n

<\/p>\n

Syst\u00e8mes de virtualisation bas\u00e9s sur un hyperviseur<\/h2>\n

<\/p>\n

Tout le monde a probablement entendu parler des syst\u00e8mes de virtualisation : VMware, VirtualBox, Hyper-V, Qemu KVM, etc. Ils assurent l'isolation des applications et la gestion des ressources, mais pr\u00e9sentent \u00e9galement des inconv\u00e9nients. Pour mettre en place la virtualisation, un hyperviseur est n\u00e9cessaire. Et l'hyperviseur entra\u00eene une surcharge de ressources. De plus, la machine virtuelle est souvent tr\u00e8s lourde : elle comprend un syst\u00e8me d'exploitation, Nginx, Apache, et peut-\u00eatre MySQL. L'image est volumineuse, et il est compliqu\u00e9 de travailler avec une machine virtuelle. Par cons\u00e9quent, le travail avec des machines virtuelles peut \u00eatre lent. Pour r\u00e9soudre ce probl\u00e8me, des syst\u00e8mes de virtualisation au niveau du noyau ont \u00e9t\u00e9 cr\u00e9\u00e9s.<\/p>\n

<\/p>\n

Syst\u00e8mes de virtualisation au niveau du noyau<\/h2>\n

<\/p>\n

La virtualisation au niveau du noyau est prise en charge par des syst\u00e8mes comme OpenVZ, Systemd-nspawn, LXC. Un exemple frappant de ce type de virtualisation est LXC (Linux Containers). <\/p>\n

<\/p>\n

LXC \u2014 un syst\u00e8me de virtualisation au niveau du syst\u00e8me d'exploitation permettant de lancer plusieurs instances isol\u00e9es du syst\u00e8me d'exploitation Linux sur un m\u00eame n\u0153ud. LXC ne utilise pas de machines virtuelles, mais cr\u00e9e un environnement virtuel avec son propre espace de processus et sa pile r\u00e9seau.<\/p>\n

<\/p>\n

En essence, LXC cr\u00e9e des conteneurs. Quelle est la diff\u00e9rence entre les machines virtuelles et les conteneurs ?<\/p>\n

<\/p>\n

\"Qu'est-ce<\/p>\n

<\/p>\n

Le conteneur n'est pas adapt\u00e9 \u00e0 l'isolation des processus : dans les syst\u00e8mes de virtualisation au niveau du noyau, on trouve des vuln\u00e9rabilit\u00e9s qui permettent de sortir du conteneur vers l'h\u00f4te. Donc, si vous devez isoler quelque chose, il est pr\u00e9f\u00e9rable d'utiliser une machine virtuelle.<\/p>\n

<\/p>\n

Les diff\u00e9rences entre la virtualisation et la conteneurisation peuvent \u00eatre visualis\u00e9es sur un sch\u00e9ma.
\nIl existe des hyperviseurs mat\u00e9riels, des hyperviseurs bas\u00e9s sur l'OS et des conteneurs. <\/p>\n

<\/p>\n

\"Qu'est-ce<\/p>\n

<\/p>\n

Les hyperviseurs \u00ab mat\u00e9riels \u00bb sont une chose formidable si vous souhaitez r\u00e9ellement isoler quelque chose. Parce qu'ils permettent l'isolation au niveau des pages m\u00e9moire et des processeurs.<\/p>\n

<\/p>\n

Il existe des hyperviseurs sous forme de programmes et des conteneurs, c'est de ces derniers que nous parlerons ensuite. Dans les syst\u00e8mes de conteneurisation, il n'y a pas d'hyperviseur, mais il y a un moteur de conteneur qui cr\u00e9e et g\u00e8re les conteneurs. C'est une solution plus l\u00e9g\u00e8re, donc, gr\u00e2ce \u00e0 son interaction avec le noyau, la surcharge est moindre, voire inexistante.<\/p>\n

<\/p>\n

\n

Ce qui est utilis\u00e9 pour la conteneurisation au niveau du noyau<\/h2>\n

Les principales technologies permettant de cr\u00e9er un conteneur isol\u00e9 des autres processus sont les Namespaces et les Control Groups.<\/p>\n

Namespaces : PID, R\u00e9seau, Montage et Utilisateur. Il y en a d'autres, mais pour simplifier la compr\u00e9hension, nous allons nous concentrer sur ceux-ci.<\/p>\n

Le Namespace PID limite les processus. Lorsque nous cr\u00e9ons par exemple un Namespace PID, y pla\u00e7ons un processus, il devient avec PID 1. En g\u00e9n\u00e9ral, dans les syst\u00e8mes, le PID 1 est systemd ou init. Ainsi, lorsque nous pla\u00e7ons un processus dans un nouveau namespace, il re\u00e7oit \u00e9galement PID 1.<\/p>\n

Le Namespace R\u00e9seau permet de limiter\/isolier le r\u00e9seau et d'y placer ses propres interfaces. Le Montage est une restriction au niveau du syst\u00e8me de fichiers. Utilisateur \u2014 restriction au niveau des utilisateurs.<\/p>\n

Control Groups : M\u00e9moire, CPU, IOPS, R\u00e9seau \u2014 environ 12 param\u00e8tres au total. On les appelle aussi Cgroups (\u00ab groupes C \u00bb).<\/p>\n

Les Control Groups g\u00e8rent les ressources pour le conteneur. Gr\u00e2ce aux Control Groups, nous pouvons sp\u00e9cifier qu'un conteneur ne doit pas consommer plus d'une certaine quantit\u00e9 de ressources.<\/p>\n

Pour que la conteneurisation fonctionne pleinement, des technologies suppl\u00e9mentaires sont utilis\u00e9es : Capabilities, Copy-on-write et d'autres.<\/p>\n

Les Capabilities d\u00e9signent ce que nous disons \u00e0 un processus qu'il peut ou ne peut pas faire. Au niveau du noyau, ce ne sont que des cartes de bits avec de nombreux param\u00e8tres. Par exemple, l'utilisateur root a tous les privil\u00e8ges et peut tout faire. Un serveur de temps peut modifier le temps syst\u00e8me : il poss\u00e8de des capacit\u00e9s sur Time Capsule, c'est tout. Gr\u00e2ce aux privil\u00e8ges, il est possible de configurer de mani\u00e8re flexible les restrictions pour les processus, assurant ainsi notre s\u00e9curit\u00e9.<\/p>\n

Le syst\u00e8me Copy-on-write nous permet de travailler avec des images Docker, les utilisant de mani\u00e8re plus efficace.<\/p>\n

\u00c0 ce jour, Docker a des probl\u00e8mes de compatibilit\u00e9 avec Cgroups v2, c'est pourquoi cet article aborde sp\u00e9cifiquement Cgroups v1.<\/em><\/p><\/blockquote>\n

Mais revenons \u00e0 l'histoire. <\/p>\n

<\/p>\n

Lorsque les syst\u00e8mes de virtualisation au niveau du noyau sont apparus, ils ont \u00e9t\u00e9 rapidement adopt\u00e9s. La surcharge du hyperviseur a disparu, mais certains probl\u00e8mes persistent :<\/p>\n

<\/p>\n