3599 votes

Comment le Docker.io est différent d’une machine virtuelle normale ?

<p>Je continue à relire <a href="http://docs.docker.io/en/latest/terms/container/">la documentation de Docker.io</a> pour essayer de comprendre la différence entre Docker.io et une machine virtuelle complète. Comment il parvient à fournir un environnement isolé du réseau de système de fichiers complet, etc., sans être aussi lourd ?</p> <p>Pourquoi déploie des logiciels à une image de docker (si c’est le bon terme) plus facile que de simplement déployer dans un environnement de production cohérent ?</p>

3359voto

Ken Cochrane Points 12318

Docker utilise actuellement LinuX Containers (LXC), qui s'exécutent dans le même système d'exploitation que son hôte. Cela permet de partager une grande partie du système d'exploitation hôte des ressources. Il utilise également AuFS pour le système de fichiers. Il gère également la mise en réseau pour vous aussi.

AuFS est une couche de système de fichiers, donc vous pouvez lire uniquement une partie, et une écriture de la partie, et les fusionner ensemble. Vous pouvez donc avoir les parties communes de l'exploitation du système en lecture seule, qui sont partagés entre tous de vos conteneurs, et ensuite, donner à chaque conteneur sa propre monture pour l'écriture.

Donc, disons que vous avez un conteneur de l'image qui est de 1 go en taille. Si vous vouliez utiliser une machine virtuelle, vous devez avoir 1 go de x fois le nombre de machines virtuelles que vous souhaitez. Avec LXC et AuFS vous pouvez partager le plus gros de 1 go et si vous avez 1000 conteneurs vous pourriez encore avoir seulement un peu plus de 1 go d'espace pour les conteneurs OS, en supposant qu'ils sont tous de la même image de l'OS.

Plein virtualisé, le système devient son propre ensemble de ressources qui lui sont allouées, et effectue un minimum de partage. Vous obtenez plus de l'isolement, mais c'est beaucoup plus lourd (nécessite plus de ressources).

Avec LXC vous obtenez moins d'isolement, mais ils sont plus légers et nécessitent moins de ressources. Donc, vous pouvez facilement exécuter des 1000 sur un ordinateur hôte, et il n'a même pas cligner des yeux. Essayez de faire ça avec Xen, et, sauf si vous avez vraiment un gros hôte, je ne pense pas que c'est possible.

Plein virtualisé système prend habituellement quelques minutes à démarrer, les conteneurs LXC prendre quelques secondes, et parfois même moins d'une seconde.

Il y a des avantages et des inconvénients pour chaque type de système virtualisé. Si vous voulez l'isolation complète avec garantie de ressources, un VM est le chemin à parcourir. Si vous voulez juste pour isoler les processus les uns des autres et que vous voulez exécuter une tonne d'entre eux sur une taille raisonnable de l'hôte, puis LXC pourrait être le chemin à parcourir.

Pour plus d'informations, découvrez cette série de billets de blog qui font un bon travail en expliquant comment LXC œuvres.

Je me sens stupide de demander, mais pourquoi déploiement de logiciels à un panneau de l'image (si c'est le bon terme) de plus facile que de déployer simplement pour une production constante de l'environnement?

Le déploiement d'une production constante de l'environnement est plus facile à dire qu'à faire. Même si vous utilisez des outils comme chef et puppet, il y a toujours des mises à jour OS et d'autres choses qui changent entre les hôtes et les environnements.

Ce panneau n'est qu'il vous donne la possibilité de prendre un instantané de l'OS dans une image commune, et il est facile à déployer sur d'autres docker hôtes. Localement, dev, qa, prod, etc, tous de la même image. Bien sûr, vous pouvez le faire avec d'autres outils, mais pas aussi facilement ou rapidement.

Ce qui est excellent pour les tests unitaires, disons que vous avez de 1000 tests et ils ont besoin de se connecter à une base de données, et afin de ne pas casser tout ce que vous devez exécuter en série, de sorte que les tests ne sont pas les uns sur les autres (l'exécution de chaque test dans une transaction et de restaurer). Avec Docker, vous pouvez créer une image de votre base de données, puis exécuter tous les tests en parallèle parce que vous savez qu'ils vont tous être en cours d'exécution à l'encontre de l'instantané de la base de données. Depuis, ils sont exécutés en parallèle et dans des conteneurs LXC ils pouvaient courir tous sur la même zone au même moment, et que vos tests terminer beaucoup plus rapidement. Essayez de faire ça avec un VM.

Edit: D'après les commentaires...

Intéressant! Je suppose que je suis toujours confus par la notion de "snapshot[chaudron] l'OS". Comment fait-on le faire sans, bien, la réalisation d'une image de l'OS?

Eh bien, voyons voir si je peux l'expliquer. Vous commencez avec une image de base, puis effectuez vos modifications, et de commettre ces changements à l'aide de menu fixe, et crée une image. Cette image ne contient que les différences à partir de la base. Lorsque vous voulez exécuter votre image, vous avez également besoin de base, et les couches de votre image sur le dessus de la base en utilisant une couche de système de fichier, dans ce cas AUFS. AUFS fusionne les différentes couches ensemble et vous obtenez ce que vous voulez, et il vous suffit de l'exécuter. Vous pouvez continuer à ajouter de plus en plus d'images (couches) et il continuera à enregistrer uniquement les diff.

326voto

shuron Points 31

J'aime Ken Cochrane réponse.

Mais je tiens à ajouter d'autres point de vue, ne sont pas couverts en détail ici. À mon avis, menu fixe diffère également dans l'ensemble du processus. En revanche le VMs Docker n'est pas (seulement) sur les ressources de façon optimale le partage de matériel, de plus il fournit un "système" pour le conditionnement de l'application (de préférence mais pas une nécessité, comme un ensemble de Microservices).

Pour moi, il s'inscrit dans l'écart entre Orienté Développeur des outils comme le rpm, les paquets debian, maven, gnp + git sur un côté et Ops des outils comme Puppet, VMWare, Xen vous le nom...

Pourquoi déploiement de logiciels à un panneau de l'image (si c'est le bon terme) de plus facile que de déployer simplement pour une production constante de l'environnement?

Votre question suppose une certaine cohérence environnement de production. Mais comment garder-il cohérent? Envisager une certaine quantité (>10), de serveurs et d'applications, les étapes du pipeline.. Pour garder cette synchronisation, vous allez commencer à utiliser quelque chose comme Puppet, Chef ou propre approvisionnement des scripts, des inédits règles et/ou beaucoup de documentation... En théorie, les serveurs peuvent s'exécuter indéfiniment, et se maintenir cohérente et à jour. La pratique ne parvient pas à gérer la configuration du serveur complètement, donc il existe de nombreuses possibilités pour la configuration de la dérive, et des changements inattendus dans l'exécution des serveurs.

Il y a donc un schéma connu, pour éviter cela, dits Immuable du Serveur. Mais immuable serveur tendance n'était pas aimé. Surtout à cause des limitations de la machine virtuelle, il a été utilisé avant de Docker. Traiter avec plusieurs Gigaoctets de grandes images, le déplacement de ces grandes images de coin, de modifier certains champs de l'application, a été très très laborieux. Compréhensible...

Avec le Panneau de l'écosystème, vous n'aurez plus jamais besoin de se déplacer autour de Giga-octets sur "petits changements" (Merci aufs et de Registre) et vous n'avez pas besoin de vous soucier de perdre de la performance par les applications d'emballage dans un conteneur Docker sur l'exécution. Vous n'avez pas besoin de vous soucier de versions de cette image. Et enfin vous pourrez même souvent être en mesure de reproduire complexe des environnements de production, même sur votre linux ordinateur portable (ne m'appelez pas si c'est ne pas fonctionner dans votre cas.; -))

Un de sûr, vous pouvez commencer à conteneurs docker dans VMs (c'est une bonne idée). Réduire votre serveur de provisionnement sur le niveau de la VM. Tous les ci-dessus pourrait être géré par Docker.

P. S. pendant ce temps Docker utilise sa propre mise en œuvre "libcontainer" au lieu de LXC. Mais LXC est encore utilisable.

145voto

Pankaj Arora Points 111

Par le biais de ce post, nous allons tracer quelques lignes de différences entre les ordinateurs virtuels et LXCs. Permet d'abord de les définir.

VM:

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

Dans ce contexte, la VM est appelé en tant que Guest tandis que l'environnement, il s'appelle l'Hôte

LXCs:

Linux Containers (LXC) système d'exploitation niveau de capacités qui font qu'il est possible d'exécuter plusieurs isolé Linux conteneurs, sur un contrôle de l'hôte (LXC hôte). Linux Conteneurs servir comme une alternative légère aux VMs, car ils ne nécessitent pas les hyperviseurs viz. Virtualbox, KVM, Xen, etc.

Maintenant, à moins que vous avez été drogué par Alan (Zach Galifianakis - à partir de la Gueule de bois de la série) et ont été à las Vegas pour la dernière année, vous sera très conscients de la formidable poussée de l'intérêt pour linux de la technologie des conteneurs et si je vais être spécifique d'un récipient projet qui a créé un buzz dans le monde au cours des derniers mois, est – Docker, conduisant ainsi à une écho des opinions que les environnements de cloud computing devrait abandonner les machines virtuelles (Vm) et de les remplacer par des contenants en raison de leur moindre frais généraux et potentiellement de meilleures performances.

Mais la grande question est, est-il possible?, sera-ce raisonnable ?

un. LXCs sont limités à une instance de Linux. Il peut être de différentes saveurs de Linux ( par exemple, une Ubuntu conteneur sur un Centos hôte, mais il est encore Linux. ) De même, Windows conteneurs sont limités à une instance de Windows maintenant, si nous regardons VMs ils ont un assez large champ d'application et en utilisant les hyperviseurs vous n'êtes pas limité aux Systèmes d'Exploitation linux ou windows.

b. LXCs ont de faibles frais généraux et d'avoir de meilleures performances par rapport à des machines virtuelles. Outils viz. Docker qui sont construites sur les épaules de LXC la technologie ont fourni aux développeurs une plate-forme pour exécuter leurs applications et dans le même temps ont le pouvoir ops personnes avec un outil qui va leur permettre de déployer le même conteneur sur les serveurs de production ou de centres de données. Il tente de faire l'expérience entre un développeur de l'exécution d'une application, le démarrage et test d'une application et d'une personne du déploiement de l'application sans faille car c'est là où le frottement se trouve dans et le but de DevOps est de briser les silos.

Donc, la meilleure approche est l'infrastructure du cloud des fournisseurs devrait préconiser l'utilisation du VMs et d'un conteneur LXC, car ils sont chacun adaptés pour gérer des charges de travail spécifiques et des scénarios.

L'abandon de VMs n'est pas pratique dès maintenant. Donc, les deux VMs et LXCs ont leur propre existence et de l'importance.

87voto

<p>Docker encapsule une application avec toutes ses dépendances, un virtualiseur encapsule un O.S. qui peut exécuter n’importe quelle application qu'il peut normalement fonctionner sur une machine de métal nue.</p>

58voto

purpletech Points 349

Ils sont tous les deux très différents. Docker est léger et utilise un conteneur lxc ( qui s'appuie sur le noyau namespacing et cgroups ) et n'ont pas de machine/de l'émulation matérielle comme l'hyperviseur KVM. Xen qui sont lourds.

lxc est destiné plus pour le bac à sable,la conteneurisation et de ressources de l'isolement. Il utilise le système d'exploitation hôte ( actuellement, seul le noyau linux) clone de l'API qui fournit namespacing de l'IPC, NS (mont), réseau, PID, UT, etc., ce sujet de mémoire, io, cpu, etc., ? qui est contrôlé à l'aide des cgroups où vous pouvez créer des groupes avec certaines ressources ( cpu, mémoire...) spec, de restriction et de mettre votre processus.

normal vm utilise de l'hyperviseur et les technologies connexes, soit avoir un firmware dédié qui devient la première couche pour le premier OS ( système d'exploitation hôte, ou de l'OS invité 0 ) ou un logiciel qui s'exécute sur le système d'exploitation hôte pour fournir de l'émulation matérielle telles que le processeur, usb/accessoires, mémoire, réseau, etc, pour les Systèmes d'exploitation invités.

menu fixe/lxc peut presque être exécuté sur n'importe quel matériel bon marché (<1 go de mémoire est également OK, tant que vous avez plus récente du noyau) vs normale vms besoin d'au moins 2 go de mémoire etc., de faire quelque chose de significatif. Mais docker appui sur l'OS hôte n'est pas disponible dans les systèmes d'exploitation tels que windows (comme de nov/2014) où, comme il peut les types de machines virtuelles peut être exécuté sur windows,linux, mac.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X