Aller au contenu

Conteneur (virtualisation)

Un article de Wikipédia, l'encyclopédie libre.

La virtualisation au niveau du système d'exploitation est un paradigme de système d'exploitation (SE) dans lequel le noyau permet l'existence de plusieurs instances d'espace utilisateur isolées, appelées le plus souvent conteneurs (LXC, Solaris containers, Docker, Podman), mais également zones (Solaris containeurs), serveurs privés virtuels (OpenVZ), partitions, environnements virtuels, noyaux virtuels (DragonFly BSD) ou encore prisons (FreeBSD jail ou chroot jail)[1]. De telles instances peuvent ressembler à de vrais ordinateurs du point de vue des programmes qui y sont exécutés. Un programme informatique exécuté sur un système d'exploitation ordinaire peut voir toutes les ressources (périphériques connectés, fichiers et dossiers, partages réseau, puissance du processeur, capacités matérielles quantifiables) de cet ordinateur. Cependant, les programmes exécutés à l'intérieur d'un conteneur ne peuvent voir que le contenu du conteneur et les périphériques affectés au conteneur.

Sur les systèmes d'exploitation de type Unix , cette fonctionnalité peut être considérée comme une implémentation avancée du mécanisme chroot standard, qui modifie le dossier racine apparent pour le processus en cours d'exécution et ses enfants. En plus des mécanismes d'isolation, le noyau fournit souvent des fonctionnalités de gestion des ressources pour limiter l'impact des activités d'un conteneur sur d'autres conteneurs. Les conteneurs Linux sont tous basés sur les mécanismes de virtualisation, d'isolation et de gestion des ressources fournis par le noyau Linux, notamment les espaces de noms Linux et les cgroups[2].

Le terme conteneur, bien qu'il se réfère le plus souvent aux systèmes de virtualisation au niveau du système d'exploitation, est parfois utilisé de manière ambiguë pour désigner des environnements de machines virtuelles plus complets fonctionnant à des degrés divers de concert avec le système d'exploitation hôte, par exemple les conteneurs Hyper-V de Microsoft.

Opération

[modifier | modifier le code]

Sur les systèmes d'exploitation ordinaires pour ordinateurs personnels, un programme informatique peut voir (même s'il ne peut pas y accéder) toutes les ressources du système. Ce qui inclut :

  1. Le capacités matérielles pouvant être utilisées, telles que le processeur et la connexion réseau
  2. Les données pouvant être lues ou écrites, telles que des fichiers, des dossiers et des partages réseau
  3. Les périphériques connectés avec lesquels il peut interagir, tels qu'une webcam, une imprimante, un scanner ou un fax

Le système d'exploitation peut être en mesure d'autoriser ou de refuser l'accès à ces ressources en fonction du programme qui les demande et du compte d'utilisateur dans le contexte duquel il s'exécute. Le système d'exploitation peut également masquer ces ressources, de sorte que lorsque le programme informatique les énumère, elles n'apparaissent pas dans les résultats de l'énumération. Néanmoins, le programme informatique a interagi avec ces ressources par le biais du système d'exploitation.

Avec la conteneurisation, il est possible d'exécuter des programmes dans des conteneurs, auxquels seule une fraction de ces ressources sont allouées. Un programme qui s'attend à voir l'ensemble de l'ordinateur, une fois exécuté à l'intérieur d'un conteneur, ne peut voir que les ressources allouées et, de son point de vue, ce sont les seules disponibles. Plusieurs conteneurs peuvent être créés sur chaque système d'exploitation, à chacun desquels un sous-ensemble des ressources de l'ordinateur est alloué. Chaque conteneur peut contenir n'importe quel nombre de programmes informatiques. Ces programmes peuvent s'exécuter simultanément ou séparément, et peuvent même interagir les uns avec les autres.

La conteneurisation présente des similitudes avec la virtualisation des applications : dans cette dernière, un seul programme informatique est placé dans un conteneur isolé et l'isolation ne s'applique qu'au système de fichiers.

Usages

[modifier | modifier le code]

La conteneurisation est couramment utilisée dans les environnements d'hébergement virtuel, où elle est utile pour allouer en toute sécurité des ressources matérielles finies entre un grand nombre d'utilisateurs qui ne peuvent pas nécessairement se faire confiance. Les administrateurs système peuvent également l'utiliser pour consolider le matériel du serveur en déplaçant les services sur des hôtes distincts dans des conteneurs sur le même serveur.

D'autres scénarios typiques incluent la séparation de plusieurs programmes pour séparer les conteneurs pour une sécurité améliorée, l'indépendance du matériel et des fonctionnalités de gestion des ressources supplémentaires. La sécurité améliorée fournie par l'utilisation d'un mécanisme chroot est cependant loin d'être à toute épreuve[3]. Les implémentations de virtualisation au niveau du système d'exploitation capables de migration dynamique peuvent également être utilisées pour l'équilibrage de charge dynamique des conteneurs entre les nœuds d'un cluster.

Meilleure utilisation des ressources

[modifier | modifier le code]

La conteneurisation nécessite généralement moins de ressources que la virtualisation complète, car les programmes des partitions virtuelles au niveau du système d'exploitation utilisent l'interface d'appel système normale du système d'exploitation et n'ont pas besoin d'être soumis à une émulation ou d'être exécutés dans une machine virtuelle intermédiaire, comme c'est le cas cas avec la virtualisation complète (telle que VMware ESXi, QEMU ou Hyper-V ) et la paravirtualisation (telle que Xen ou Linux en mode utilisateur ). Cette forme de virtualisation ne nécessite pas non plus de support matériel pour des performances efficaces.

Souplesse

[modifier | modifier le code]

La conteneurisation n'est pas aussi flexible que les autres approches de virtualisation car elle ne peut pas héberger un système d'exploitation invité différent de celui de l'hôte, ou un noyau invité différent. Par exemple, avec Linux, différentes distributions conviennent, mais d'autres systèmes d'exploitation tels que Windows ne peuvent pas être hébergés.

Solaris surmonte partiellement la limitation décrite ci-dessus avec sa fonctionnalité branded zones, qui permet d'exécuter un environnement dans un conteneur qui émule une ancienne version de Solaris 8 ou 9 dans un hôte Solaris 10. Les branded zones Linux (appelées zones de marque "lx") sont également disponibles sur les systèmes Solaris basés sur x86, fournissant un espace utilisateur Linux complet et une prise en charge de l'exécution des applications Linux ; de plus, Solaris fournit les utilitaires nécessaires à l'installation de Red Hat Enterprise Linux 3.x ou CentOS Distributions Linux 3.x à l'intérieur des zones "lx"[4],[5]. Cependant, en 2010, les branded zones Linux ont été supprimées de Solaris; en 2014, ils ont été réintroduits dans Illumos, qui est le fork open source de Solaris, prenant en charge les noyaux Linux 32 bits[6].

Stockage

[modifier | modifier le code]

Certaines implémentations fournissent des mécanismes de copie sur écriture au niveau des fichiers. (Le plus souvent, un système de fichiers standard est partagé entre les partitions, et les partitions qui modifient les fichiers créent automatiquement leurs propres copies. ) Ceci est plus facile à sauvegarder, plus économe en espace et plus simple à mettre en cache que les schémas de copie sur écriture au niveau des blocs courants lors de la virtualisation de système entier. La virtualisation de système complet, cependant, peut fonctionner avec des systèmes de fichiers non natifs, et créer et restaurer des instantanés de l'état du système en entier.

Implémentations

[modifier | modifier le code]
Nom Système d'exploitation Licence Développé activement depuis/entre Fonctionnalitées
Isolation du système de fichier Copie à l'écriture Quotas de disque Limitation du taux d'E/S Limitations de mémoire Quotas CPU Isolation réseau Virtualisations imbriquées Contrôle de partition et migration à chaud Isolation des droits root
chroot La plupart des systèmes de type Unix Variable 1982 Partiel[note 1] Non Non Non Non Non Non Oui Non Non
Docker Linux[8], FreeBSD[9], Windows x64 (Pro, Enterprise aet Education)[10] macOS[11] Licence Apache 2.0 2013 Oui Oui Pas nativement Oui (depuis la version 1.10) Oui Oui Oui Oui Seleument en version expérimentale avec CRIU [1] Oui (depuis la version 1.10)
Linux-VServer

(security context) 		Linux, Windows Server 2016 GNU GPLv2 2001 Oui Oui Oui Oui[note 2] Oui Oui Partiel[note 3] ? Non Partial[note 4]
lmctfy Linux Licence Apache 2.0 2013 – 2015 Oui Oui Oui Oui[note 2] Oui Oui Partiel[note 3] ? Non Partial[note 4]
LXC Linux GNU GPLv2 2008 Oui[13] Oui Partiel[note 5] Partiel[note 6] Oui Oui Oui Oui Oui Oui[13]
Singularity Linux Licence BSD 2015[14] Oui[15] Oui Oui Non Non Non Non Non Non Oui[16]
OpenVZ Linux GNU GPLv2 2005 Oui Oui[17] Oui Oui[note 7] Oui Oui Oui[note 8] Partiel[note 9] Oui Yes[note 10]
Virtuozzo Linux, Windows Propriétaire, avec une période d'essai gratuite 2000[21] Oui Oui Oui Oui[note 11] Oui Oui Oui[note 8] Partiel[note 12] Oui Oui
Solaris Containers (Zones) illumos (OpenSolaris),

Solaris 		CDDL,
Propriétaire 		2004 Oui Oui (ZFS) Oui Partiel[note 13] Oui Oui Oui[note 14][24],[25] Partiel[note 15] Partiel[note 16][note 17] Yes[note 18]
FreeBSD jail FreeBSD, DragonFly BSD Licence BSD 2000[27] Oui Oui (ZFS) Oui[note 19] Oui Oui[28] Oui Oui[29] Oui Partiel[30],[31] Oui[32]
vkernel DragonFly BSD Licence BSD 2006[33] Oui[34] Oui[34] NC ? Oui[35] Ouir Oui[36] ? ? Oui
sysjail OpenBSD, NetBSD Licence BSD 2006–2009 Oui Non Non Non Non Non Oui Non Non ?
WPARs AIX Propriétaire 2007 Oui Non Oui Oui Oui Oui Oui[note 20] Non Oui[38] ?
iCore Virtual Accounts Windows XP Propriétaire 2008 Oui Non Oui Non Non Non Non ? Non ?
Sandboxie Windows GNU GPLv3 2004 Oui Oui Partiel Non Non Non Partiel Non Non Oui
systemd-nspawn Linux GNU GPLv2.1+ 2010 Oui Oui Oui[39],[40] Oui[39],[40] Oui[39],[40] Oui[39],[40] Oui ? ? Oui
Turbo Windows Propriétaire 2012 Oui Non Non Non Non Non Oui Non Non Oui
rkt Linux Licence Apache 2.0 2014[41]–2018 Oui Oui Oui Oui Oui Oui Oui ? ? Oui

Les conteneurs Linux non répertoriés ci-dessus incluent :

  • LXD, un wrapper alternatif autour de LXC développé par Canonical [42]
  • Podman[43], un remplaçant de Docker
  • Charliecloud, un ensemble d'outils de conteneur utilisés sur les systèmes HPC [44]
  • La plateforme MicroVM de conteneurs Kata [45]
  • Bottlerocket, un système d'exploitation open source basé sur Linux qui est spécialement conçu par Amazon Web Services pour exécuter des conteneurs sur des machines virtuelles ou des hôtes bare metal [46]
  1. ↑ Un utilisateur avec les droits root peut facilement quitter le chroot, qui n'a jamais été conçu comme un environnement sécurisé[7].
  2. ↑ a et b Avec le superviseur CFQ, il y a une file séparée par invité.
  3. ↑ a et b La gestion du réseau est isolée, pas la virtualisation.
  4. ↑ a et b Jusqu'à 14 utilisateurs par conteneur, c'est considéré comme sûr. Au delà, on ne peut garantir qu'un processus n'interférera pas avec l'extérieur du conteneur[12].
  5. ↑ Les quotas de disque par conteneur sont possibles lorsqu'on utilise des partitions séparées pour chaque conteneur à l'aide de LVM, ou lorsque le système de fichiers hôte sous-jacent est btrfs, auquel cas des sous-volumes btrfs sont automatiquement utilisés.
  6. ↑ La limitation d'E/S est supportée avec Btrfs.
  7. ↑ isponible depuis le noyau Linux 2.6.18-028stable021. L'implémentation est basée sur l'ordonnanceur d'E/S de disque CFQ, mais c'est un schéma à deux niveaux, donc la priorité d'E/S n'est pas par processus, mais plutôt par conteneur[18].
  8. ↑ a et b Chaque conteneur peut disposer de ses propres adresses IP, règles de pare-feu, tables de routage, etc. Trois schémas de mise en réseau différents sont possibles : basés sur les routes réseaux, les passerelles réseaux, ou l'attribution d'un véritable périphérique réseau à un conteneur.
  9. ↑ Des conteneurs Docker peuvent s'éxecuter dans un conteneur OpenVZ[19].
  10. ↑ Chaque conteneur peut avoir un accès root sans que cela n'affecte les autres conteneurs[20].
  11. ↑ Available since version 4.0, January 2008.
  12. ↑ Des conteneurs Docker peuvent s'exécuter dans un conteneur Virtuozzo[22].
  13. ↑ Oui, avec illumos[23]
  14. ↑ Cf. OpenSolaris Network Virtualization and Resource Control (en).
  15. ↑ Uniquement lorsque le niveau supérieur est une zone KVM (illumos) ou une zone kz (Oracle).
  16. ↑ À partir de Solaris 11.3 Beta, les Solaris Kernel Zones peuvent utiliser la migration à chaud.
  17. ↑ La migration à froid (arrêt, transfert et redémarrage) est implémentée.
  18. ↑ Les zones non globales sont limitées de manière à ne pas affecter les autres zones. La zone globale peut administrer les zones non globales[26].
  19. ↑ Cf. l'option "allow.quotas" et la section "Jails and File Systems" sur la page de manuel FreeBSD jail.
  20. ↑ Available since TL 02[37].

Articles connexes

[modifier | modifier le code]

Références

[modifier | modifier le code]
  1. ↑ Hogg, « Software Containers: Used More Frequently than Most Realize », Network World, Network World, Inc, (consulté le ) : « There are many other OS-level virtualization systems such as: Linux OpenVZ, Linux-VServer, FreeBSD Jails, AIX Workload Partitions (WPARs), HP-UX Containers (SRP), Solaris Containers, among others. »
  2. ↑ Rami, « Namespaces and Cgroups, the basis of Linux Containers » (consulté le )
  3. ↑ Yanek Korff, Paco Hope et Bruce Potter, Mastering FreeBSD and OpenBSD Security, O'Reilly Media, Inc., coll. « O'Reilly Series », (ISBN 0596006268, lire en ligne), p. 59
  4. ↑ « System Administration Guide: Oracle Solaris Containers-Resource Management and Oracle Solaris Zones, Chapter 16: Introduction to Solaris Zones », Oracle Corporation, (consulté le )
  5. ↑ « System Administration Guide: Oracle Solaris Containers-Resource Management and Oracle Solaris Zones, Chapter 31: About Branded Zones and the Linux Branded Zone », Oracle Corporation, (consulté le )
  6. ↑ Bryan Cantrill, « The dream is alive! Running Linux containers on an illumos kernel », slideshare.net, (consulté le )
  7. ↑ « 3.5. Limiting your program's environment », sur freebsd.org
  8. ↑ « Docker drops LXC as default execution environment », InfoQ
  9. ↑ « Docker comes to FreeBSD », FreeBSDNews.com,
  10. ↑ « Get started with Docker for Windows », Docker,
  11. ↑ « Get started with Docker Desktop for Mac », Docker Documentation,
  12. ↑ « Paper - Linux-VServer », sur linux-vserver.org
  13. ↑ a et b Stéphane Graber, « LXC 1.0: Security features [6/10] », (consulté le ) : « LXC now has support for user namespaces. [...] LXC is no longer running as root so even if an attacker manages to escape the container, he'd find himself having the privileges of a regular user on the host »
  14. ↑ « Sylabs Brings Singularity Containers into Commercial HPC | TOP500 Supercomputer Sites », www.top500.org
  15. ↑ « Redirecting… », sur www.sylabs.io,
  16. ↑ Gregory M. Kurtzer, Vanessa Sochat et Michael W. Bauer, « Singularity: Scientific containers for mobility of compute », PLOS ONE, vol. 12, no 5,‎ , e0177459 (PMID 28494014, PMCID 5426675, DOI 10.1371/journal.pone.0177459 Accès libre, Bibcode 2017PLoSO..1277459K)
  17. ↑ Sergey Bronnikov, « Comparison on OpenVZ wiki page », sur OpenVZ Wiki, OpenVZ (consulté le )
  18. ↑ « I/O priorities for containers », sur OpenVZ Virtuozzo Containers Wiki
  19. ↑ « Docker inside CT »
  20. ↑ « Container », sur OpenVZ Virtuozzo Containers Wiki
  21. ↑ « Initial public prerelease of Virtuozzo (named ASPcomplete at that time) »
  22. ↑ « Parallels Virtuozzo Now Provides Native Support for Docker »
  23. ↑ Bill Pijewski, « Our ZFS I/O Throttle »
  24. ↑ Network Virtualization and Resource Control (Crossbow) FAQ « https://web.archive.org/web/20080601182802/http://www.opensolaris.org/os/project/crossbow/faq/ »(Archive.org • Wikiwix • Archive.is • Google • Que faire ?),
  25. ↑ « Managing Network Virtualization and Network Resources in Oracle® Solaris 11.2 », sur docs.oracle.com
  26. ↑ Oracle Solaris 11.1 Administration, Oracle Solaris Zones, Oracle Solaris 10 Zones and Resource Management E29024.pdf, pp. 356-360. Available within an archive.
  27. ↑ « Contain your enthusiasm - Part Two: Jails, Zones, OpenVZ, and LXC » : « Jails were first introduced in FreeBSD 4.0 in 2000 »
  28. ↑ « Hierarchical_Resource_Limits - FreeBSD Wiki », Wiki.freebsd.org, (consulté le )
  29. ↑ « Implementing a Clonable Network Stack in the FreeBSD Kernel », usenix.org,
  30. ↑ « VPS for FreeBSD » (consulté le )
  31. ↑ « [Announcement] VPS // OS Virtualization // alpha release » (consulté le )
  32. ↑ « 3.5. Limiting your program's environment », Freebsd.org (consulté le )
  33. ↑ Matthew Dillon, « sys/vkernel.h », BSD Cross Reference, DragonFly BSD,
  34. ↑ a et b « vkd(4) — Virtual Kernel Disc », DragonFly BSD : « "treats the disk image as copy-on-write." »
  35. ↑ Sascha Wildner, « vkernel, vcd, vkd, vke — virtual kernel architecture », sur DragonFly Miscellaneous Information Manual, DragonFly BSD,
  36. ↑ « vke(4) — Virtual Kernel Ethernet », DragonFly BSD
  37. ↑ « IBM Fix pack information for: WPAR Network Isolation - United States », sur ibm.com,
  38. ↑ « Live Application Mobility in AIX 6.1 », sur www.ibm.com,
  39. ↑ a b c et d « systemd-nspawn », sur www.freedesktop.org
  40. ↑ a b c et d « 2.3. Modifying Control Groups Red Hat Enterprise Linux 7 », sur Red Hat Customer Portal
  41. ↑ Polvi, « CoreOS is building a container runtime, rkt » [archive du ], CoreOS Blog (consulté le )
  42. ↑ « LXD », linuxcontainers.org (consulté le )
  43. ↑ Rootless containers with Podman and fuse-overlayfs, CERN Workshop, 2019-06-04
  44. ↑ « Overview — Charliecloud 0.25 documentation » (consulté le )
  45. ↑ « Home », katacontainers.io
  46. ↑ « Bottlerocket is a Linux-based operating system purpose-built to run containers »

Liens externes

[modifier | modifier le code]
Ce document provient de « https://fr.wikipedia.org/w/index.php?title=Conteneur_(virtualisation)&oldid=215216124 ».