En quoi Docker est-il différent d'une machine virtuelle ?

Question

Je continue à relire la documentation de Docker pour essayer de comprendre la différence entre Docker et une VM complète. Comment parvient-il à fournir un système de fichiers complet, un environnement réseau isolé, etc. sans être aussi lourd ?

Pourquoi est-il plus facile de déployer un logiciel dans une image Docker (si c'est le bon terme) que de le déployer simplement dans un environnement de production cohérent ?

Answer 1

À l'origine, Docker utilisait Conteneurs LinuX (LXC), mais est ensuite passé à runC (anciennement connu sous le nom de libcontainer ), qui fonctionne dans le même système d'exploitation que son hôte. Cela lui permet de partager une grande partie des ressources du système d'exploitation de l'hôte. En outre, il utilise un système de fichiers en couches ( AuFS ) et gère la mise en réseau.

AuFS est un système de fichiers en couches, vous pouvez donc avoir une partie en lecture seule et une partie en écriture qui sont fusionnées. On pourrait avoir les parties communes du système d'exploitation en lecture seule (et partagées entre tous vos conteneurs) et donner à chaque conteneur son propre montage pour l'écriture.

Ainsi, disons que vous disposez d'une image de conteneur de 1 Go ; si vous souhaitez utiliser une VM complète, vous devrez disposer de 1 Go x le nombre de VM souhaité. Avec Docker et AuFS, vous pouvez partager la majeure partie des 1 Go entre tous les conteneurs et si vous avez 1 000 conteneurs, il se peut que vous n'ayez qu'un peu plus de 1 Go d'espace pour le système d'exploitation des conteneurs (en supposant qu'ils utilisent tous la même image de système d'exploitation).

Un système entièrement virtualisé se voit allouer son propre ensemble de ressources et le partage est minimal. L'isolation est plus grande, mais le système est beaucoup plus lourd (il nécessite plus de ressources). Avec Docker, l'isolation est moindre, mais les conteneurs sont légers (ils nécessitent moins de ressources). Vous pouvez donc facilement faire tourner des milliers de conteneurs sur un hôte, sans qu'il ne bronche. Essayez de faire cela avec Xen, et à moins que vous n'ayez un très gros hôte, je ne pense pas que ce soit possible.

Le démarrage d'un système entièrement virtualisé prend généralement plusieurs minutes, alors que les conteneurs Docker/LXC/runC prennent quelques secondes, voire moins d'une seconde.

Il y a des avantages et des inconvénients pour chaque type de système virtualisé. Si vous souhaitez une isolation totale avec des ressources garanties, une VM complète est la solution. Si vous souhaitez simplement isoler les processus les uns des autres et en exécuter une tonne sur un hôte de taille raisonnable, Docker/LXC/runC semble être la solution.

Pour plus d'informations, consultez le site cette série d'articles de blog qui expliquent bien le fonctionnement de LXC.

Pourquoi est-il plus facile de déployer un logiciel sur une image Docker (si c'est le bon terme) que de le déployer simplement sur un environnement de production cohérent ?

Déployer un environnement de production cohérent est plus facile à dire qu'à faire. Même si vous utilisez des outils comme Chef y Marionnette Il y a toujours des mises à jour du système d'exploitation et d'autres choses qui changent entre les hôtes et les environnements.

Docker vous donne la possibilité d'instantaner le système d'exploitation dans une image partagée, et facilite le déploiement sur d'autres hôtes Docker. Localement, dev, qa, prod, etc. : tous ont la même image. Bien sûr, vous pouvez faire cela avec d'autres outils, mais pas aussi facilement ni aussi rapidement.

C'est idéal pour les tests ; disons que vous avez des milliers de tests qui doivent se connecter à une base de données, et que chaque test a besoin d'une copie vierge de la base de données et apportera des modifications aux données. L'approche classique consiste à réinitialiser la base de données après chaque test, soit avec du code personnalisé, soit avec des outils tels que Voie de migration - Cela peut prendre beaucoup de temps et signifie que les tests doivent être exécutés en série. Cependant, avec Docker, vous pouvez créer une image de votre base de données et exécuter une instance par test, puis exécuter tous les tests en parallèle puisque vous savez qu'ils seront tous exécutés sur le même instantané de la base de données. Puisque les tests sont exécutés en parallèle et dans des conteneurs Docker, ils peuvent être exécutés sur la même machine en même temps et devraient se terminer beaucoup plus rapidement. Essayez de faire cela avec une VM complète.

Des commentaires...

Intéressant ! Je suppose que je suis toujours confus par la notion de "snapshot[ting] du système d'exploitation". Comment fait-on cela sans, eh bien, faire une image du système d'exploitation ?

Eh bien, voyons si je peux expliquer. Vous commencez avec une image de base, puis vous apportez vos modifications, et vous les validez en utilisant Docker, et cela crée une image. Cette image ne contient que les différences par rapport à la base. Lorsque vous souhaitez exécuter votre image, vous avez également besoin de l'image de base. L'image est alors superposée à l'image de base à l'aide d'un système de fichiers en couches : comme mentionné ci-dessus, Docker utilise AuFS. AuFS fusionne les différentes couches et vous obtenez ce que vous voulez ; il vous suffit de l'exécuter. Vous pouvez continuer à ajouter de plus en plus d'images (couches) et il continuera à ne sauvegarder que les différences. Étant donné que Docker se construit généralement à partir d'images prêtes à l'emploi provenant d'un serveur de registre vous devez rarement faire un "snapshot" de l'ensemble du système d'exploitation vous-même.

Answer 2

J'aime La réponse de Ken Cochrane .

Mais je veux ajouter un point de vue supplémentaire, qui n'est pas couvert en détail ici. À mon avis, Docker diffère également dans l'ensemble du processus. Contrairement aux VM, Docker ne vise pas (uniquement) à optimiser le partage des ressources matérielles, il fournit en outre un "système" pour le conditionnement des applications (de préférence, mais pas obligatoirement, sous la forme d'un ensemble de microservices).

Pour moi, il se situe à mi-chemin entre les outils orientés vers les développeurs comme rpm, Debian paquets, Maven npm + Git d'une part et des outils d'exploitation tels que Marionnette VMware, Xen, et bien d'autres encore...

Pourquoi est-il plus facile de déployer un logiciel sur une image Docker (si c'est le bon terme) que de le déployer simplement sur un environnement de production cohérent ?

Votre question suppose un environnement de production cohérent. Mais comment faire pour que cela reste cohérent ? Considérez une certaine quantité (>10) de serveurs et d'applications, des étapes dans le pipeline.

Pour garder tout cela en synchronisation, vous commencerez à utiliser quelque chose comme Puppet, Chef ou vos propres scripts de provisionnement, des règles non publiées et/ou beaucoup de documentation... En théorie, les serveurs peuvent fonctionner indéfiniment, et être maintenus complètement cohérents et à jour. La pratique ne parvient pas à gérer complètement la configuration d'un serveur, il y a donc une marge considérable pour la dérive de la configuration, et des changements inattendus aux serveurs en cours d'exécution.

Il y a donc un modèle connu pour éviter cela, le soi-disant serveur immuable . Mais le modèle de serveur immuable n'était pas apprécié. Principalement à cause des limitations des VMs qui étaient utilisées avant Docker. Il était très laborieux de gérer des images de plusieurs gigaoctets et de les déplacer, juste pour modifier certains champs de l'application. C'est compréhensible...

Avec un écosystème Docker, vous n'aurez jamais besoin de déplacer des gigaoctets pour de "petites modifications" (merci aux aufs et au Registre) et vous n'aurez pas à vous inquiéter de perdre des performances en empaquetant des applications dans un conteneur Docker au moment de l'exécution. Vous n'avez pas besoin de vous soucier des versions de cette image.

Et enfin, vous serez même souvent en mesure de reproduire des environnements de production complexes même sur votre ordinateur portable Linux (ne m'appelez pas si cela ne fonctionne pas dans votre cas ;)).

Et bien sûr, vous pouvez démarrer des conteneurs Docker dans des VM (c'est une bonne idée). Réduire le provisionnement de vos serveurs au niveau des VM. Tout ce qui précède pourrait être géré par Docker.

P.S. Entre-temps, Docker utilise sa propre implémentation "libcontainer" au lieu de LXC. Mais LXC est toujours utilisable.

Answer 3

A travers ce post, nous allons tracer quelques lignes de différences entre VMs et LXCs. Commençons par les définir.

VM :

Une machine virtuelle émule un environnement informatique physique, mais les demandes de CPU, de mémoire, de disque dur, de réseau et d'autres ressources matérielles sont gérées par une couche de virtualisation qui traduit ces demandes en matériel physique sous-jacent.

Dans ce contexte, la machine virtuelle est appelée l'invité, tandis que l'environnement sur lequel elle fonctionne est appelé l'hôte.

LXC s :

Les conteneurs Linux (LXC) sont des capacités au niveau du système d'exploitation qui permettent d'exécuter plusieurs conteneurs Linux isolés, sur un hôte de contrôle (l'hôte LXC). Les conteneurs Linux constituent une alternative légère aux machines virtuelles, car ils ne nécessitent pas d'hyperviseurs (Virtualbox, KVM, Xen, etc.).

À moins d'avoir été drogué par Alan (Zach Galifianakis - de la série Hangover) et d'avoir séjourné à Las Vegas l'année dernière, vous êtes certainement au courant de l'intérêt considérable que suscite la technologie des conteneurs Linux. Pour être plus précis, je dirai que l'un des projets de conteneurs qui a fait le tour du monde au cours des derniers mois est Docker, ce qui a conduit certains à penser que les environnements de cloud computing devraient abandonner les machines virtuelles (VM) et les remplacer par des conteneurs en raison de leur faible coût et de leurs performances potentiellement meilleures.

Mais la grande question est de savoir si c'est faisable et si c'est raisonnable.

a. Les LXC sont adaptés à une instance de Linux. Il peut s'agir de différentes saveurs de Linux (par exemple, un conteneur Ubuntu sur un hôte CentOS, mais il s'agit toujours de Linux). De même, les conteneurs basés sur Windows sont limités à une instance de Windows, mais si nous examinons les VM, leur champ d'application est plus large et, en utilisant les hyperviseurs, vous n'êtes pas limité aux systèmes d'exploitation Linux ou Windows.

b. Les LXC ont de faibles frais généraux et de meilleures performances par rapport aux VM. Les outils tels que Docker, qui s'appuient sur la technologie LXC, ont fourni aux développeurs une plateforme pour exécuter leurs applications et, dans le même temps, ont donné aux opérateurs un outil qui leur permet de déployer le même conteneur sur des serveurs ou des centres de données de production. Il s'agit de faire en sorte que l'expérience entre un développeur qui exécute une application, la démarre et la teste, et une personne chargée des opérations qui déploie cette application soit transparente, car c'est là que se situent toutes les frictions et l'objectif de DevOps est de briser ces silos.

La meilleure approche consiste donc à ce que les fournisseurs d'infrastructure en nuage préconisent une utilisation appropriée des VM et de LXC, car ils sont tous deux adaptés à la gestion de charges de travail et de scénarios spécifiques.

L'abandon des VM n'est pas pratique pour l'instant. Les VM et les LXC ont donc leur propre existence et leur propre importance.

Answer 4

Docker encapsule une application avec toutes ses dépendances.

Un virtualiseur encapsule un système d'exploitation qui peut exécuter toutes les applications qu'il peut normalement exécuter sur une machine métallique nue.

Answer 5

Ils sont tous deux très différents. Docker est léger et utilise LXC/libcontainer (qui repose sur l'espacement des noms du noyau et les cgroups) et ne dispose pas d'émulation de machine/matériel comme l'hyperviseur KVM. Xen qui sont lourds.

Docker et LXC sont davantage destinés au sandboxing, à la conteneurisation et à l'isolation des ressources. Ils utilisent l'API de clonage du système d'exploitation hôte (actuellement uniquement le noyau Linux) qui fournit un espacement des noms pour IPC, NS (mount), réseau, PID, UTS, etc.

Qu'en est-il de la mémoire, des E/S, du processeur, etc. ? Cela est contrôlé à l'aide de cgroups où vous pouvez créer des groupes avec certaines spécifications/restrictions de ressources (CPU, mémoire, etc.) et y placer vos processus. En plus de LXC, Docker fournit un backend de stockage ( http://www.projectatomic.io/docs/filesystems/ ) par exemple, un système de fichiers de montage d'union où vous pouvez ajouter des couches et partager des couches entre différents espaces de noms de montage.

Il s'agit d'une fonctionnalité puissante lorsque les images de base sont généralement en lecture seule et que ce n'est que lorsque le conteneur modifie quelque chose dans la couche qu'il écrit quelque chose sur la partition en lecture-écriture (alias copie sur écriture). Il fournit également beaucoup d'autres enveloppes telles que le registre et la gestion des versions des images.

Avec LXC normal, vous devez venir avec des rootfs ou partager les rootfs et lorsqu'ils sont partagés, et les changements sont reflétés sur les autres conteneurs. Grâce à ces nombreuses fonctionnalités supplémentaires, Docker est plus populaire que LXC. LXC est populaire dans les environnements embarqués pour mettre en œuvre la sécurité autour des processus exposés à des entités externes telles que le réseau et l'interface utilisateur. Docker est populaire dans les environnements multi-tenant en nuage où un environnement de production cohérent est attendu.

Une VM normale (par exemple, VirtualBox et VMware) utilise un hyperviseur, et les technologies connexes ont soit un firmware dédié qui devient la première couche pour le premier OS (OS hôte, ou OS invité 0), soit un logiciel qui s'exécute sur l'OS hôte pour fournir une émulation matérielle telle que CPU, USB/accessoires, mémoire, réseau, etc. aux OS invités. Les VMs sont encore (en 2015) populaires dans les environnements multi-locataires de haute sécurité.

Docker/LXC peut presque être exécuté sur n'importe quel matériel bon marché (moins de 1 Go de mémoire est également acceptable tant que vous avez un noyau plus récent), alors que les VM normales ont besoin d'au moins 2 Go de mémoire, etc. pour en faire quelque chose de significatif. Mais le support de Docker sur le système d'exploitation hôte n'est pas disponible dans des systèmes d'exploitation tels que Windows (depuis novembre 2014), alors que de nombreux types de VM peuvent être exécutés sur Windows, Linux et Mac.

Voici une image de docker/rightscale :