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

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

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

Docker utilisait à l' origine des conteneurs LinuX (LXC), mais est ensuite passé à runC (anciennement libcontainer ), qui s'exécute 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 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), puis donner à chaque conteneur sa propre monture pour l'écriture.

Supposons donc que vous ayez une image de conteneur de 1 Go; si vous souhaitez utiliser une machine virtuelle complète, vous devez disposer de 1 Go x nombre de machines virtuelles souhaitées. Avec Docker et AuFS, vous pouvez partager la majeure partie des 1 Go entre tous les conteneurs et si vous avez 1000 conteneurs, vous n'aurez peut-être encore qu'un peu plus de 1 Go d'espace pour le système d'exploitation des conteneurs (en supposant qu'ils exécutent tous la même image du système d'exploitation) .

Un système virtualisé complet obtient son propre ensemble de ressources qui lui est alloué et fait un partage minimal. Vous obtenez plus d'isolement, mais c'est beaucoup plus lourd (nécessite plus de ressources). Avec Docker, vous obtenez moins d'isolement, mais les conteneurs sont légers (nécessitent moins de ressources). Ainsi, vous pouvez facilement exécuter des milliers de conteneurs sur un hôte, et cela ne clignotera même pas. 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.

Un système virtualisé complet prend généralement quelques minutes pour démarrer, tandis que les conteneurs Docker / LXC / runC prennent quelques secondes, et souvent 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 une isolation complète avec des ressources garanties, une machine virtuelle complète est la solution. Si vous souhaitez simplement isoler les processus les uns des autres et exécuter une tonne d'entre eux sur un hôte de taille raisonnable, Docker / LXC / runC semble être la solution.

Pour plus d'informations, consultez cet ensemble de billets de blog qui expliquent bien le fonctionnement de LXC.

Pourquoi le déploiement de logiciels sur une image Docker (si c'est le bon terme) est-il plus facile que le simple déploiement dans 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 et Puppet , 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'instantanés du 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 la même image. Bien sûr, vous pouvez le faire avec d'autres outils, mais pas aussi facilement ou 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 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 avec du code personnalisé ou avec des outils comme Flyway - 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, car vous savez qu'ils s'exécuteront tous sur le même instantané de la base de données. Étant donné que les tests s'exécutent en parallèle et dans des conteneurs Docker, ils pourraient s'exécuter tous sur la même boîte en même temps et devraient se terminer beaucoup plus rapidement. Essayez de le faire avec une machine virtuelle complète.

Des commentaires ...

Intéressant! Je suppose que je suis encore confus par la notion de "snapshot [ting] the OS". Comment faire cela sans, bien, faire une image de l'OS?

Eh bien, voyons si je peux expliquer. Vous commencez avec une image de base, puis apportez vos modifications et validez ces modifications à l'aide de 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 la base et elle superpose votre image au-dessus de la base à l'aide d'un système de fichiers en couches: comme mentionné ci-dessus, Docker utilise AuFS. AuFS fusionne les différentes couches ensemble et vous obtenez ce que vous voulez; il vous suffit de l'exécuter. Vous pouvez continuer à ajouter de plus en plus d'images (calques) et il ne continuera à enregistrer que les différences. Étant donné que Docker s'appuie généralement sur des images prédéfinies à partir d'un registre , vous devez rarement «prendre un instantané» de l'ensemble du système d'exploitation vous-même.

Bonnes réponses. Juste pour obtenir une représentation d'image du conteneur par rapport à la VM, jetez un œil à celui ci-dessous.

La source

Il peut être utile de comprendre comment la virtualisation et les conteneurs fonctionnent à bas niveau. Cela éclaircira beaucoup de choses.

Remarque: je simplifie un peu la description ci-dessous. Voir les références pour plus d'informations.

Comment fonctionne la virtualisation à bas niveau?

Dans ce cas, le gestionnaire de VM prend en charge l'anneau CPU 0 (ou le "mode racine" dans les CPU plus récents) et intercepte tous les appels privilégiés effectués par l'OS invité pour créer l'illusion que l'OS invité possède son propre matériel. Fait amusant: avant 1998, on pensait qu'il était impossible d'y parvenir dans l'architecture x86 car il n'y avait aucun moyen de faire ce type d'interception. Les gens de VMWare ont été les premiers à avoir eu l'idée de réécrire les octets exécutables en mémoire pour les appels privilégiés du système d'exploitation invité pour y parvenir.

L'effet net est que la virtualisation vous permet d'exécuter deux systèmes d'exploitation complètement différents sur le même matériel. Chaque système d'exploitation invité passe par tout le processus de démarrage, de chargement du noyau, etc. Vous pouvez avoir une sécurité très stricte, par exemple, le système d'exploitation invité ne peut pas obtenir un accès complet au système d'exploitation hôte ou à d'autres invités et gâcher les choses.

Comment fonctionnent les conteneurs à bas niveau?

Vers 2006 , des personnes, dont certains employés de Google, ont implémenté une nouvelle fonctionnalité au niveau du noyau appelée espaces de noms (mais l'idée existait bien avant dans FreeBSD). L'une des fonctions du système d'exploitation est de permettre le partage de ressources globales telles que le réseau et le disque sur les processus. Et si ces ressources globales étaient enveloppées dans des espaces de noms afin qu'elles ne soient visibles que par les processus qui s'exécutent dans le même espace de noms? Dites, vous pouvez obtenir un morceau de disque et le mettre dans l'espace de noms X, puis les processus s'exécutant dans l'espace de noms Y ne peuvent pas le voir ou y accéder. De même, les processus dans l'espace de noms X ne peuvent accéder à rien en mémoire qui est alloué à l'espace de noms Y. Bien sûr, les processus dans X ne peuvent pas voir ou parler aux processus dans l'espace de noms Y. Cela fournit une sorte de virtualisation et d'isolement pour les ressources globales. Voici comment fonctionne Docker: chaque conteneur s'exécute dans son propre espace de noms mais utilise exactement le mêmenoyau comme tous les autres conteneurs. L'isolement se produit parce que le noyau connaît l'espace de noms qui a été attribué au processus et lors des appels d'API, il s'assure que le processus ne peut accéder qu'aux ressources de son propre espace de noms.

Les limites des conteneurs par rapport à la machine virtuelle devraient être évidentes maintenant: vous ne pouvez pas exécuter un système d'exploitation complètement différent dans des conteneurs comme dans les machines virtuelles. Cependant, vous pouvez exécuter différentes distributions de Linux car elles partagent le même noyau. Le niveau d'isolement n'est pas aussi fort que dans VM. En fait, il existait un moyen pour le conteneur "invité" de prendre en charge l'hôte dans les premières implémentations. Vous pouvez également voir que lorsque vous chargez un nouveau conteneur, la nouvelle copie entière du système d'exploitation ne démarre pas comme dans VM. Tous les conteneurs partagent le même noyau. C'est pourquoi les conteneurs sont légers. Contrairement à VM, vous n'avez pas à pré-allouer une grande partie de la mémoire aux conteneurs car nous n'exécutons pas de nouvelle copie du système d'exploitation. Cela permet d'exécuter des milliers de conteneurs sur un système d'exploitation tout en les mettant en sandbox, ce qui pourrait ne pas être possible si nous exécutions une copie distincte du système d'exploitation dans sa propre machine virtuelle.

J'aime la réponse de Ken Cochrane.

Mais je veux ajouter un point de vue supplémentaire, non couvert en détail ici. À mon avis, Docker diffère également dans l'ensemble du processus. Contrairement aux machines virtuelles, Docker ne concerne pas (uniquement) le partage optimal des ressources matérielles, il fournit en outre un "système" pour la mise en package des applications (préférable, mais pas indispensable, comme un ensemble de microservices).

Pour moi, cela s'inscrit dans l'écart entre les outils orientés développeur comme rpm, les packages Debian , Maven , npm + Git d'un côté et les outils ops comme Puppet , VMware, Xen, vous l'appelez ...

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

Votre question suppose un environnement de production cohérent. Mais comment le garder cohérent? Considérez une certaine quantité (> 10) de serveurs et d'applications, les étapes du pipeline.

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

Il existe donc un schéma connu pour éviter cela, le serveur dit immuable . Mais le modèle de serveur immuable n'a pas été aimé. Principalement en raison des limitations des machines virtuelles utilisées avant Docker. Le traitement de plusieurs gigaoctets de grandes images, le déplacement de ces grandes images, juste pour changer certains champs dans l'application, était très très laborieux. Compréhensible...

Avec un écosystème Docker, vous n'aurez jamais besoin de vous déplacer de gigaoctets sur de "petits changements" (merci aufs et Registry) et vous n'avez pas à vous soucier de perdre les performances en empaquetant des applications dans un conteneur Docker lors de l'exécution. Vous n'avez pas à vous soucier des versions de cette image.

Et enfin, vous pourrez même souvent 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 les conteneurs Docker dans des machines virtuelles (c'est une bonne idée). Réduisez le provisionnement de votre serveur au niveau de la machine virtuelle. Tout ce qui précède pourrait être géré par Docker.

PS Pendant ce temps, Docker utilise sa propre implémentation "libcontainer" au lieu de LXC. Mais LXC est toujours utilisable.

Docker n'est pas une méthodologie de virtualisation. Il s'appuie sur d'autres outils qui implémentent réellement la virtualisation basée sur conteneur ou la virtualisation au niveau du système d'exploitation. Pour cela, Docker utilisait initialement le pilote LXC, puis a été déplacé vers libcontainer qui est maintenant renommé runc. Docker se concentre principalement sur l'automatisation du déploiement d'applications à l'intérieur de conteneurs d'applications. Les conteneurs d'applications sont conçus pour regrouper et exécuter un seul service, tandis que les conteneurs système sont conçus pour exécuter plusieurs processus, comme les machines virtuelles. Docker est donc considéré comme un outil de gestion de conteneurs ou de déploiement d'applications sur des systèmes conteneurisés.

Afin de savoir en quoi il diffère des autres virtualisations, passons en revue la virtualisation et ses types. Ensuite, il serait plus facile de comprendre quelle est la différence.

Virtualisation

Dans sa forme conçue, il était considéré comme une méthode de division logique des mainframes pour permettre à plusieurs applications de s'exécuter simultanément. Cependant, le scénario a radicalement changé lorsque les entreprises et les communautés open source ont pu fournir une méthode de traitement des instructions privilégiées d'une manière ou d'une autre et permettre à plusieurs systèmes d'exploitation d'être exécutés simultanément sur un seul système x86.

Hyperviseur

L'hyperviseur gère la création de l'environnement virtuel sur lequel les machines virtuelles invitées fonctionnent. Il supervise les systèmes invités et s'assure que les ressources sont allouées aux invités selon les besoins. L'hyperviseur se situe entre la machine physique et les machines virtuelles et fournit des services de virtualisation aux machines virtuelles. Pour le réaliser, il intercepte les opérations du système d'exploitation invité sur les machines virtuelles et émule l'opération sur le système d'exploitation de la machine hôte.

Le développement rapide des technologies de virtualisation, principalement dans le cloud, a poussé davantage l'utilisation de la virtualisation en permettant la création de plusieurs serveurs virtuels sur un seul serveur physique à l'aide d'hyperviseurs, tels que Xen, VMware Player, KVM, etc., et intégration de la prise en charge matérielle dans les processeurs de base, tels que Intel VT et AMD-V.

Types de virtualisation

La méthode de virtualisation peut être classée en fonction de la façon dont elle imite le matériel à un système d'exploitation invité et émule un environnement d'exploitation invité. Il existe principalement trois types de virtualisation:

• Émulation
• Paravirtualisation
• Virtualisation basée sur des conteneurs

Émulation

L'émulation, également connue sous le nom de virtualisation complète, exécute le noyau du système d'exploitation de la machine virtuelle entièrement dans le logiciel. L'hyperviseur utilisé dans ce type est appelé hyperviseur de type 2. Il est installé sur le dessus du système d'exploitation hôte qui est responsable de la traduction du code du noyau du système d'exploitation invité en instructions logicielles. La traduction se fait entièrement en logiciel et ne nécessite aucune implication matérielle. L'émulation permet d'exécuter tout système d'exploitation non modifié prenant en charge l'environnement émulé. L'inconvénient de ce type de virtualisation est une surcharge de ressources système supplémentaire qui entraîne une baisse des performances par rapport aux autres types de virtualisations.

Les exemples de cette catégorie incluent VMware Player, VirtualBox, QEMU, Bochs, Parallels, etc.

Paravirtualisation

La paravirtualisation, également connue sous le nom d'hyperviseur de type 1, s'exécute directement sur le matériel, ou «bare-metal», et fournit des services de virtualisation directement aux machines virtuelles qui y sont exécutées. Il aide le système d'exploitation, le matériel virtualisé et le vrai matériel à collaborer pour obtenir des performances optimales. Ces hyperviseurs ont généralement une empreinte assez petite et ne nécessitent pas, eux-mêmes, de ressources importantes.

Les exemples de cette catégorie incluent Xen, KVM, etc.

Virtualisation basée sur des conteneurs

La virtualisation basée sur des conteneurs, également connue sous le nom de virtualisation au niveau du système d'exploitation, permet plusieurs exécutions isolées dans un seul noyau de système d'exploitation. Il offre les meilleures performances et densité possibles et propose une gestion dynamique des ressources. L'environnement d'exécution virtuelle isolé fourni par ce type de virtualisation est appelé conteneur et peut être considéré comme un groupe de processus tracés.

Le concept de conteneur est rendu possible par la fonctionnalité d'espaces de noms ajoutée à la version 2.6.24 du noyau Linux. Le conteneur ajoute son ID à chaque processus et ajoute de nouveaux contrôles de contrôle d'accès à chaque appel système. Il est accessible par l' appel système clone () qui permet de créer des instances distinctes des espaces de noms précédemment globaux.

Les espaces de noms peuvent être utilisés de différentes manières, mais l'approche la plus courante consiste à créer un conteneur isolé qui n'a aucune visibilité ou accès aux objets en dehors du conteneur. Les processus s'exécutant à l'intérieur du conteneur semblent s'exécuter sur un système Linux normal bien qu'ils partagent le noyau sous-jacent avec des processus situés dans d'autres espaces de noms, de même pour d'autres types d'objets. Par exemple, lors de l'utilisation d'espaces de noms, l'utilisateur root à l'intérieur du conteneur n'est pas traité comme root à l'extérieur du conteneur, ce qui ajoute une sécurité supplémentaire.

Le sous-système Linux Control Groups (cgroups), le prochain composant majeur pour activer la virtualisation basée sur des conteneurs, est utilisé pour regrouper les processus et gérer leur consommation globale de ressources. Il est couramment utilisé pour limiter la consommation de mémoire et de CPU des conteneurs. Puisqu'un système Linux conteneurisé n'a qu'un seul noyau et que le noyau a une visibilité complète sur les conteneurs, il n'y a qu'un seul niveau d'allocation et de planification des ressources.

Plusieurs outils de gestion sont disponibles pour les conteneurs Linux, notamment LXC, LXD, systemd-nspawn, lmctfy, Warden, Linux-VServer, OpenVZ, Docker, etc.

Conteneurs vs machines virtuelles

Contrairement à une machine virtuelle, un conteneur n'a pas besoin de démarrer le noyau du système d'exploitation, de sorte que les conteneurs peuvent être créés en moins d'une seconde. Cette fonctionnalité rend la virtualisation basée sur conteneur unique et souhaitable par rapport aux autres approches de virtualisation.

Étant donné que la virtualisation basée sur les conteneurs ajoute peu ou pas de surcharge à la machine hôte, la virtualisation basée sur les conteneurs a des performances quasi natives

Pour la virtualisation basée sur des conteneurs, aucun logiciel supplémentaire n'est requis, contrairement aux autres virtualisations.

Tous les conteneurs sur une machine hôte partagent le planificateur de la machine hôte, économisant ainsi des ressources supplémentaires.

Les états des conteneurs (images Docker ou LXC) sont de petite taille par rapport aux images de machines virtuelles, de sorte que les images de conteneurs sont faciles à distribuer.

La gestion des ressources dans les conteneurs est réalisée via des groupes de contrôle. Cgroups n'autorise pas les conteneurs à consommer plus de ressources que ce qui leur est alloué. Cependant, pour l'instant, toutes les ressources de la machine hôte sont visibles dans les machines virtuelles, mais ne peuvent pas être utilisées. Cela peut être réalisé en exécutant topou htopsur des conteneurs et une machine hôte en même temps. La sortie dans tous les environnements sera similaire.

Mise à jour:

Comment Docker exécute-t-il les conteneurs dans les systèmes non Linux?

Si les conteneurs sont possibles en raison des fonctionnalités disponibles dans le noyau Linux, alors la question évidente est de savoir comment les systèmes non Linux exécutent les conteneurs. Docker pour Mac et Windows utilisent des machines virtuelles Linux pour exécuter les conteneurs. Docker Toolbox utilisé pour exécuter des conteneurs dans des machines virtuelles Virtual Box. Mais, le dernier Docker utilise Hyper-V sous Windows et Hypervisor.framework sous Mac.

Maintenant, permettez-moi de décrire en détail comment Docker pour Mac exécute les conteneurs.

Docker pour Mac utilise https://github.com/moby/hyperkit pour émuler les capacités de l'hyperviseur et Hyperkit utilise hypervisor.framework dans son cœur. Hypervisor.framework est la solution d'hyperviseur native de Mac. Hyperkit utilise également VPNKit et DataKit pour le réseau d'espace de noms et le système de fichiers respectivement.

La machine virtuelle Linux que Docker exécute sur Mac est en lecture seule. Cependant, vous pouvez y pénétrer en exécutant:

screen ~/Library/Containers/com.docker.docker/Data/vms/0/tty.

Maintenant, nous pouvons même vérifier la version du noyau de cette machine virtuelle:

# uname -a Linux linuxkit-025000000001 4.9.93-linuxkit-aufs #1 SMP Wed Jun 6 16:86_64 Linux.

Tous les conteneurs s'exécutent à l'intérieur de cette machine virtuelle.

Il y a quelques limitations à hypervisor.framework. À cause de cela, Docker n'expose pas l' docker0interface réseau dans Mac. Vous ne pouvez donc pas accéder aux conteneurs depuis l'hôte. Pour l'instant, docker0n'est disponible qu'à l'intérieur de la machine virtuelle.

Hyper-v est l'hyperviseur natif de Windows. Ils essaient également de tirer parti des capacités de Windows 10 pour exécuter les systèmes Linux en mode natif.

À travers ce post, nous allons tracer quelques lignes de différences entre les VM et les LXC. Définissons-les d'abord.

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 en tant qu'invité tandis que l'environnement sur lequel elle s'exécute est appelé l'hôte.

LXC s:

Les conteneurs Linux (LXC) sont des fonctionnalité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 les hyperviseurs à savoir. Virtualbox, KVM, Xen, etc.

Maintenant, à moins que vous n'ayez été drogué par Alan (Zach Galifianakis- de la série Hangover) et que vous soyez à Vegas depuis l'année dernière, vous serez assez conscient de l'énorme intérêt suscité par la technologie des conteneurs Linux, et si je vais être spécifique à un conteneur projet qui a créé un buzz dans le monde ces derniers mois est - Docker conduit à des opinions qui font écho que les environnements de cloud computing devraient abandonner les machines virtuelles (VM) et les remplacer par des conteneurs en raison de leur faible surcharge et potentiellement de meilleures performances.

Mais la grande question est: est-ce faisable?, Sera-t-il raisonnable?

une. Les LXC sont étendus à une instance de Linux. Il peut s'agir de différentes versions de Linux (par exemple, un conteneur Ubuntu sur un hôte CentOS mais c'est toujours Linux.) De même, les conteneurs Windows sont étendus à une instance de Windows maintenant si nous regardons les machines virtuelles, elles ont une portée assez large et utilisent le 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 ont de meilleures performances par rapport aux VM. Outils à savoir. Docker, construit sur les épaules de la technologie LXC, a fourni aux développeurs une plate-forme pour exécuter leurs applications et en même temps, a donné aux opérateurs un outil qui leur permettra de déployer le même conteneur sur des serveurs de production ou des centres de données. Il essaie de rendre l'expérience entre un développeur exécutant une application, démarrant et testant une application et une personne des opérations déployant cette application de manière transparente, car c'est là que réside tout le frottement et le but de DevOps est de briser ces silos.

La meilleure approche est donc que les fournisseurs d'infrastructure cloud devraient préconiser une utilisation appropriée des machines virtuelles et LXC, car ils sont chacun adaptés pour gérer des charges de travail et des scénarios spécifiques.

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

La plupart des réponses ici parlent de machines virtuelles. Je vais vous donner une réponse unilatérale à cette question qui m'a le plus aidé au cours des deux dernières années d'utilisation de Docker. C'est ça:

Docker n'est qu'un moyen sophistiqué d'exécuter un processus, pas une machine virtuelle.

Maintenant, permettez-moi d'expliquer un peu plus ce que cela signifie. Les machines virtuelles sont leur propre bête. J'ai envie d'expliquer ce qu'est Docker vous aidera à comprendre cela plus qu'à expliquer ce qu'est une machine virtuelle. Surtout parce qu'il y a beaucoup de bonnes réponses ici qui vous disent exactement ce que quelqu'un veut dire quand il dit "machine virtuelle". Donc...

Un conteneur Docker n'est qu'un processus (et ses enfants) qui est compartimenté à l'aide cgroups à l'intérieur du noyau du système hôte du reste des processus. Vous pouvez réellement voir vos processus de conteneur Docker en exécutant ps auxsur l'hôte. Par exemple, démarrer apache2"dans un conteneur" ne fait que commencer apache2comme un processus spécial sur l'hôte. Il vient d'être compartimenté à partir d'autres processus sur la machine. Il est important de noter que vos conteneurs n'existent pas en dehors de la durée de vie de votre processus conteneurisé. Lorsque votre processus meurt, votre conteneur meurt. C'est parce que Docker remplace l' pid 1intérieur de votre conteneur par votre application ( pid 1c'est normalement le système init). Ce dernier point pid 1est très important.

En ce qui concerne le système de fichiers utilisé par chacun de ces processus de conteneur, Docker utilise des images sauvegardées par UnionFS, ce que vous téléchargez lorsque vous effectuez un docker pull ubuntu. Chaque "image" n'est qu'une série de couches et de métadonnées associées. Le concept de superposition est ici très important. Chaque couche est juste un changement par rapport à la couche en dessous. Par exemple, lorsque vous supprimez un fichier dans votre Dockerfile lors de la construction d'un conteneur Docker, vous créez en fait un calque au-dessus du dernier calque qui dit "ce fichier a été supprimé". Soit dit en passant, c'est pourquoi vous pouvez supprimer un gros fichier de votre système de fichiers, mais l'image occupe toujours la même quantité d'espace disque. Le fichier est toujours là, dans les calques sous celui en cours. Les couches elles-mêmes ne sont que des archives de fichiers. Vous pouvez tester cela avecdocker save --output /tmp/ubuntu.tar ubuntuet puis cd /tmp && tar xvf ubuntu.tar. Ensuite, vous pouvez regarder autour de vous. Tous ces répertoires qui ressemblent à de longs hachages sont en fait les couches individuelles. Chacun contient des fichiers ( layer.tar) et des métadonnées (json) avec des informations sur cette couche particulière. Ces couches décrivent simplement les modifications apportées au système de fichiers qui sont enregistrées en tant que couche "au-dessus" de son état d'origine. Lors de la lecture des données "actuelles", le système de fichiers lit les données comme s'il ne regardait que les couches de modifications les plus élevées. C'est pourquoi le fichier semble être supprimé, même s'il existe toujours dans les couches "précédentes", car le système de fichiers ne regarde que les couches les plus hautes. Cela permet à des conteneurs complètement différents de partager leurs couches de système de fichiers, même si des changements importants peuvent avoir eu lieu sur le système de fichiers sur les couches les plus hautes de chaque conteneur. Cela peut vous faire économiser une tonne d'espace disque lorsque vos conteneurs partagent leurs couches d'images de base. cependant,

La mise en réseau dans Docker est obtenue en utilisant un pont Ethernet (appelé docker0sur l'hôte) et des interfaces virtuelles pour chaque conteneur sur l'hôte. Il crée un sous-réseau virtuel docker0pour que vos conteneurs communiquent "entre" les uns les autres. Il existe de nombreuses options de mise en réseau ici, notamment la création de sous-réseaux personnalisés pour vos conteneurs et la possibilité de «partager» la pile de mise en réseau de votre hôte pour que votre conteneur puisse accéder directement.

Docker se déplace très rapidement. Sa documentation est l'une des meilleures documentations que j'ai jamais vues. Il est généralement bien écrit, concis et précis. Je vous recommande de vérifier la documentation disponible pour plus d'informations et de faire confiance à la documentation par rapport à tout ce que vous lisez en ligne, y compris Stack Overflow. Si vous avez des questions spécifiques, je vous recommande fortement #dockerde vous inscrire sur Freenode IRC et de le demander (vous pouvez même utiliser le webchat de Freenode pour cela!).

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 bare metal.

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

Docker et LXC sont davantage destinés au sandboxing, à la conteneurisation et à l'isolement des ressources. Il utilise l'API clone du système d'exploitation hôte (actuellement uniquement le noyau Linux) qui fournit un espace de noms pour IPC, NS (montage), 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 mettre 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 à montage 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 où les images de base sont généralement en lecture seule et 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 de nombreux autres wrappers tels que le registre et la version des images.

Avec LXC normal, vous devez venir avec certains rootfs ou partager les rootfs et lorsqu'ils sont partagés, et les changements sont reflétés sur d'autres conteneurs. En raison de beaucoup de ces fonctionnalités supplémentaires, Docker est plus populaire que LXC. LXC est populaire dans les environnements embarqués pour implémenter 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 un environnement mutualisé cloud où un environnement de production cohérent est attendu.

Une machine virtuelle normale (par exemple, VirtualBox et VMware) utilise un hyperviseur, et les technologies associées ont soit un micrologiciel dédié qui devient la première couche pour le premier système d'exploitation (système d'exploitation hôte ou système d'exploitation invité 0) ou un logiciel qui s'exécute sur le système d'exploitation hôte pour fournir une émulation matérielle telle que CPU, USB / accessoires, mémoire, réseau, etc., aux OS invités. Les machines virtuelles sont toujours (à partir de 2015) populaires dans un environnement multi-locataire 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 OK tant que vous avez un noyau plus récent) par rapport aux machines virtuelles normales ont besoin d'au moins 2 Go de mémoire, etc., pour faire quoi que ce soit de significatif avec lui . Mais la prise en charge de Docker sur le système d'exploitation hôte n'est pas disponible dans des systèmes d'exploitation tels que Windows (à partir de novembre 2014), où des types de machines virtuelles peuvent également être exécutés sur Windows, Linux et Mac.

Voici une photo de Docker / Rightscale:

1. Léger

C'est probablement la première impression pour de nombreux apprenants dockers.

Tout d'abord, les images Docker sont généralement plus petites que les images VM, ce qui facilite la création, la copie et le partage.

Deuxièmement, les conteneurs Docker peuvent démarrer en plusieurs millisecondes, tandis que la VM démarre en quelques secondes.

2. Système de fichiers en couches

Ceci est une autre caractéristique clé de Docker. Les images ont des calques et différentes images peuvent partager des calques, ce qui le rend encore plus compact et plus rapide à construire.

Si tous les conteneurs utilisent Ubuntu comme images de base, toutes les images n'ont pas leur propre système de fichiers, mais partagent les mêmes fichiers ubuntu soulignés et ne diffèrent que par leurs propres données d'application.

3. Noyau de système d'exploitation partagé

Considérez les conteneurs comme des processus!

Tous les conteneurs fonctionnant sur un hôte sont en effet un tas de processus avec différents systèmes de fichiers. Ils partagent le même noyau de système d'exploitation, encapsule uniquement la bibliothèque système et les dépendances.

C'est bon dans la plupart des cas (aucun noyau OS supplémentaire ne maintient) mais peut être un problème si des isolations strictes sont nécessaires entre les conteneurs.

Pourquoi est-ce important?

Tout cela semble être des améliorations, pas une révolution. Eh bien, l'accumulation quantitative mène à une transformation qualitative .

Pensez au déploiement d'applications. Si nous voulons déployer un nouveau logiciel (service) ou en mettre à niveau un, il est préférable de changer les fichiers de configuration et les processus au lieu de créer une nouvelle VM. Parce que créer une machine virtuelle avec un service mis à jour, le tester (partager entre Dev et QA), le déploiement en production prend des heures, voire des jours. Si quelque chose ne va pas, vous devez recommencer, perdre encore plus de temps. Donc, utilisez l'outil de gestion de la configuration (marionnette, saltstack, chef, etc.) pour installer un nouveau logiciel, télécharger de nouveaux fichiers est préférable.

En ce qui concerne Docker, il est impossible d'utiliser un conteneur Docker nouvellement créé pour remplacer l'ancien. La maintenance est beaucoup plus facile! Construire une nouvelle image, la partager avec QA, la tester, la déployer ne prend que quelques minutes (si tout est automatisé), des heures dans le pire des cas. C'est ce qu'on appelle une infrastructure immuable : ne maintenez pas (mettez à niveau) le logiciel, créez-en un nouveau à la place.

Il transforme la façon dont les services sont fournis. Nous voulons des applications, mais devons maintenir des machines virtuelles (ce qui est pénible et n'a pas grand-chose à voir avec nos applications). Docker vous permet de vous concentrer sur les applications et de tout lisser.

Docker, essentiellement des conteneurs, prend en charge la virtualisation du système d'exploitation, c'est-à-dire que votre application estime qu'elle possède une instance complète d'un système d'exploitation, tandis que la VM prend en charge la virtualisation matérielle . Vous avez l'impression que c'est une machine physique dans laquelle vous pouvez démarrer n'importe quel système d'exploitation.

Dans Docker, les conteneurs en cours d'exécution partagent le noyau du système d'exploitation hôte, tandis que dans les machines virtuelles, ils ont leurs propres fichiers de système d'exploitation. L'environnement (le système d'exploitation) dans lequel vous développez une application est le même lorsque vous la déployez dans divers environnements de service, tels que «test» ou «production».

Par exemple, si vous développez un serveur Web qui s'exécute sur le port 4000, lorsque vous le déployez dans votre environnement de "test", ce port est déjà utilisé par un autre programme, il cesse donc de fonctionner. Dans les conteneurs, il y a des couches; toutes les modifications que vous avez apportées au système d'exploitation seraient enregistrées dans un ou plusieurs calques et ces calques feraient partie de l'image, donc où que l'image aille, les dépendances seraient également présentes.

Dans l'exemple ci-dessous, la machine hôte possède trois machines virtuelles. Afin de fournir l'isolement complet des applications dans les machines virtuelles, elles ont chacune leurs propres copies des fichiers du système d'exploitation, des bibliothèques et du code d'application, ainsi qu'une instance complète en mémoire d'un système d'exploitation. Alors que la figure ci-dessous montre le même scénario avec des conteneurs. Ici, les conteneurs partagent simplement le système d'exploitation hôte, y compris le noyau et les bibliothèques, de sorte qu'ils n'ont pas besoin de démarrer un système d'exploitation, de charger des bibliothèques ou de payer un coût de mémoire privée pour ces fichiers. Le seul espace incrémentiel qu'ils prennent est l'espace mémoire et disque nécessaire au fonctionnement de l'application dans le conteneur. Alors que l'environnement de l'application ressemble à un système d'exploitation dédié, l'application se déploie comme elle le ferait sur un hôte dédié. L'application conteneurisée démarre en quelques secondes et beaucoup plus d'instances de l'application peuvent tenir sur la machine que dans le cas de la machine virtuelle.

Source: https://azure.microsoft.com/en-us/blog/containers-docker-windows-and-trends/

Il existe trois configurations différentes qui fournissent une pile pour exécuter une application (cela nous aidera à reconnaître ce qu'est un conteneur et ce qui le rend si puissant que d'autres solutions):

1) Traditional Servers(bare metal)
2) Virtual machines (VMs)
3) Containers

1) La pile de serveurs traditionnelle se compose d'un serveur physique qui exécute un système d'exploitation et votre application.

Avantages:

• Utilisation des ressources brutes

• Isolement

Désavantages:

• Temps de déploiement très lent
• Coûteux
• Ressources gaspillées
• Difficile à mettre à l'échelle
• Difficile de migrer
• Configuration complexe

2) La pile VM compose d'un serveur physique qui exécute un système d'exploitation et un hyperviseur qui gère votre machine virtuelle, les ressources partagées et l'interface réseau. Chaque VM exécute un système d'exploitation invité, une application ou un ensemble d'applications.

Avantages:

• Bonne utilisation des ressources
• Facile à mettre à l'échelle
• Sauvegarde et migration faciles
• Rapport coût-efficacité
• Souplesse

Désavantages:

• L'allocation des ressources est problématique
• Verrouillage fournisseur
• Configuration complexe

3) La configuration du conteneur , la principale différence avec les autres piles est que la virtualisation basée sur les conteneurs utilise le noyau du système d'exploitation hôte pour créer plusieurs instances invitées isolées. Ces instances invitées sont appelées comme conteneurs. L'hôte peut être un serveur physique ou une machine virtuelle.

Avantages:

• Isolement
• Poids léger
• Efficace sur le plan des ressources
• Facile à migrer
• Sécurité
• Frais généraux faibles
• Environnement de production et de développement miroir

Désavantages:

• Même architecture
• Applications gourmandes en ressources
• Problèmes de réseau et de sécurité.

En comparant la configuration du conteneur avec ses prédécesseurs, nous pouvons conclure que la conteneurisation est la configuration la plus rapide, la plus efficace en termes de ressources et la plus sécurisée que nous connaissions à ce jour. Les conteneurs sont des instances isolées qui exécutent votre application. Docker fait tourner le conteneur d'une manière, les couches obtiennent de la mémoire d'exécution avec des pilotes de stockage par défaut (pilotes de superposition) qui s'exécutent en quelques secondes et une couche de copie sur écriture créée par-dessus une fois que nous nous engageons dans le conteneur, ce qui alimente l'exécution de conteneurs.Dans le cas de VM, il faudra environ une minute pour tout charger dans l'environnement de virtualisation. Ces instances légères peuvent être remplacées, reconstruites et déplacées facilement. Cela nous permet de refléter l'environnement de production et de développement et est d'une aide précieuse dans les processus CI / CD. Les avantages que les conteneurs peuvent offrir sont tellement convaincants qu'ils sont définitivement là pour rester.

En relation avec:-

"Pourquoi le déploiement de logiciels sur une image Docker est-il plus simple que le déploiement dans un environnement de production cohérent?"

La plupart des logiciels sont déployés dans de nombreux environnements, généralement au moins trois des éléments suivants:

1. PC (s) développeur individuel (s)
2. Environnement de développeur partagé
3. Testeur individuel PC (s)
4. Environnement de test partagé
5. Environnement QA
6. Environnement UAT
7. Test de charge / performance
8. Mise en scène en direct
9. Production
10. Archiver

Il faut également tenir compte des facteurs suivants:

• Les développeurs, et même les testeurs, auront tous des configurations PC subtilement ou très différentes, par la nature même du travail
• Les développeurs peuvent souvent développer sur des PC échappant au contrôle des règles de normalisation de l'entreprise ou de l'entreprise (par exemple, des pigistes qui développent sur leurs propres machines (souvent à distance) ou des contributeurs à des projets open source qui ne sont ni «employés» ni «contractés» pour configurer leurs PC un certain façon)
• Certains environnements seront constitués d'un nombre fixe de plusieurs machines dans une configuration à charge équilibrée
• De nombreux environnements de production auront des serveurs cloud dynamiquement (ou «élastiquement») créés et détruits en fonction des niveaux de trafic

Comme vous pouvez le voir, le nombre total de serveurs extrapolés pour une organisation est rarement en chiffres uniques, très souvent en chiffres triples et peut facilement être encore beaucoup plus élevé.

Tout cela signifie que la création d'environnements cohérents en premier lieu est déjà assez difficile simplement en raison du volume (même dans un scénario de champ vert), mais les maintenir cohérents est presque impossible étant donné le nombre élevé de serveurs, l'ajout de nouveaux serveurs (dynamiquement ou manuellement), les mises à jour automatiques des fournisseurs o / s, des fournisseurs d'antivirus, des fournisseurs de navigateurs et similaires, des installations manuelles de logiciels ou des changements de configuration effectués par des développeurs ou des techniciens de serveurs, etc. Permettez-moi de répéter - c'est pratiquement (sans jeu de mots) impossible pour garder les environnements cohérents (d'accord, pour les puristes, cela peut être fait, mais cela implique beaucoup de temps, d'efforts et de discipline, c'est précisément pourquoi les machines virtuelles et les conteneurs (par exemple Docker) ont été conçus en premier lieu).

Pensez donc à votre question plus comme ceci "Étant donné l'extrême difficulté de garder tous les environnements cohérents, est-il plus facile de déployer un logiciel sur une image Docker, même en tenant compte de la courbe d'apprentissage?" . Je pense que vous trouverez que la réponse sera toujours «oui» - mais il n'y a qu'une seule façon de le savoir, postez cette nouvelle question sur Stack Overflow.

Il existe de nombreuses réponses qui expliquent plus en détail les différences, mais voici ma très brève explication.

Une différence importante est que les machines virtuelles utilisent un noyau distinct pour exécuter le système d'exploitation . C'est la raison pour laquelle il est lourd et prend du temps à démarrer, consommant plus de ressources système.

Dans Docker, les conteneurs partagent le noyau avec l'hôte; il est donc léger et peut démarrer et s'arrêter rapidement.

Dans la virtualisation, les ressources sont allouées au début de la configuration et, par conséquent, les ressources ne sont pas entièrement utilisées lorsque la machine virtuelle est inactive pendant la plupart du temps. Dans Docker, les conteneurs ne sont pas alloués avec une quantité fixe de ressources matérielles et sont libres d'utiliser les ressources en fonction des besoins et sont donc hautement évolutifs.

Docker utilise le système de fichiers UNION . Docker utilise une technologie de copie sur écriture pour réduire l'espace mémoire consommé par les conteneurs. En savoir plus ici

Avec une machine virtuelle , nous avons un serveur, nous avons un système d'exploitation hôte sur ce serveur, puis nous avons un hyperviseur. Et puis en cours d'exécution sur cet hyperviseur, nous avons un certain nombre de systèmes d'exploitation invités avec une application et ses binaires dépendants, et des bibliothèques sur ce serveur. Il apporte un système d'exploitation invité complet avec lui. C'est assez lourd. Il y a aussi une limite à ce que vous pouvez réellement mettre sur chaque machine physique.

Les conteneurs Docker, en revanche, sont légèrement différents. Nous avons le serveur. Nous avons le système d'exploitation hôte. Mais à la place d'un hyperviseur , nous avons le moteur Docker , dans ce cas. Dans ce cas, nous n'apportons pas un système d'exploitation invité complet avec nous. Nous apportons une couche très mince du système d'exploitation , et le conteneur peut communiquer avec le système d'exploitation hôte afin d'accéder aux fonctionnalités du noyau. Et cela nous permet d'avoir un conteneur très léger.

Tout ce qu'il contient est le code de l'application et tous les fichiers binaires et bibliothèques dont il a besoin. Et ces fichiers binaires et bibliothèques peuvent en fait être partagés entre différents conteneurs si vous le souhaitez également. Et ce que cela nous permet de faire, c'est un certain nombre de choses. Ils ont un temps de démarrage beaucoup plus rapide . Vous ne pouvez pas tenir une seule machine virtuelle en quelques secondes comme ça. Et également, en les supprimant aussi rapidement ... afin que nous puissions augmenter et réduire très rapidement et nous verrons cela plus tard.

Chaque conteneur pense qu'il s'exécute sur sa propre copie du système d'exploitation. Il a son propre système de fichiers, son propre registre, etc., ce qui est une sorte de mensonge. Il est en train d'être virtualisé.

Source: Kubernetes en action.

J'ai utilisé Docker dans des environnements de production et de mise en scène. Lorsque vous vous y habituerez, vous le trouverez très puissant pour la construction d'un multi conteneur et d'environnements isolés.

Docker a été développé sur la base de LXC (Linux Container) et fonctionne parfaitement dans de nombreuses distributions Linux, en particulier Ubuntu.

Les conteneurs Docker sont des environnements isolés. Vous pouvez le voir lorsque vous exécutez la topcommande dans un conteneur Docker créé à partir d'une image Docker.

En plus de cela, ils sont très légers et flexibles grâce à la configuration dockerFile.

Par exemple, vous pouvez créer une image Docker et configurer un DockerFile et dire que, par exemple, lorsqu'il est en cours d'exécution, puis wget 'this', apt-get 'that', exécutez 'some shell script', définissant des variables d'environnement, etc.

Dans les projets et l'architecture de micro-services, Docker est un atout très viable. Vous pouvez atteindre l'évolutivité, la résilience et l'élasticité avec Docker, Docker swarm, Kubernetes et Docker Compose.

Docker Hub et sa communauté constituent un autre problème important concernant Docker. Par exemple, j'ai implémenté un écosystème pour surveiller la kafka à l'aide de Prometheus, Grafana, Prometheus-JMX-Exporter et Docker.

Pour ce faire, j'ai téléchargé des conteneurs Docker configurés pour zookeeper, kafka, Prometheus, Grafana et jmx-collector puis monté ma propre configuration pour certains d'entre eux à l'aide de fichiers YAML, ou pour d'autres, j'ai changé certains fichiers et la configuration dans le conteneur Docker et je construire un système complet de surveillance de kafka à l'aide de Dockers multi-conteneurs sur une seule machine avec isolation, évolutivité et résilience afin que cette architecture puisse être facilement déplacée sur plusieurs serveurs.

Outre le site Docker Hub, il existe un autre site appelé quay.io que vous pouvez utiliser pour y avoir votre propre tableau de bord d'images Docker et tirer / pousser vers / depuis celui-ci. Vous pouvez même importer des images Docker de Docker Hub vers quay puis les exécuter depuis quay sur votre propre machine.

Remarque: apprendre Docker en premier lieu semble complexe et difficile, mais lorsque vous vous y habituez, vous ne pouvez pas travailler sans.

Je me souviens des premiers jours de travail avec Docker lorsque j'ai émis les mauvaises commandes ou supprimé mes conteneurs et toutes les données et configurations par erreur.

C'est ainsi que Docker se présente:

Docker est la société qui pilote le mouvement des conteneurs et le seul fournisseur de plates-formes de conteneurs à traiter toutes les applications du cloud hybride. Les entreprises d'aujourd'hui sont contraintes de se transformer numériquement, mais sont contraintes par les applications et les infrastructures existantes tout en rationalisant un portefeuille de plus en plus diversifié de nuages, de centres de données et d'architectures d'applications. Docker permet une véritable indépendance entre les applications et l'infrastructure et les développeurs et les opérateurs informatiques pour libérer leur potentiel et crée un modèle pour une meilleure collaboration et innovation.

Donc , Docker est basé récipient, ce qui signifie que vous avez des images et des conteneurs qui peuvent être exécutés sur votre machine actuelle. Il n'inclut pas le système d'exploitation comme les VM , mais comme un pack de différents packs de travail comme Java, Tomcat, etc.

Si vous comprenez les conteneurs, vous obtenez ce qu'est Docker et comment il est différent des machines virtuelles ...

Alors, qu'est-ce qu'un conteneur?

Une image de conteneur est un package exécutable léger et autonome d'un logiciel qui comprend tout le nécessaire pour l'exécuter: code, runtime, outils système, bibliothèques système, paramètres. Disponible pour les applications basées sur Linux et Windows, les logiciels conteneurisés fonctionneront toujours de la même manière, quel que soit l'environnement. Les conteneurs isolent les logiciels de leur environnement, par exemple les différences entre les environnements de développement et de transfert et aident à réduire les conflits entre les équipes exécutant différents logiciels sur la même infrastructure.

Donc, comme vous le voyez dans l'image ci-dessous, chaque conteneur a un pack séparé et s'exécute sur une seule machine partage le système d'exploitation de cette machine ... Ils sont sécurisés et faciles à expédier ...

Il y a beaucoup de bonnes réponses techniques ici qui discutent clairement des différences entre les machines virtuelles et les conteneurs ainsi que les origines de Docker.

Pour moi, la différence fondamentale entre les machines virtuelles et Docker est la façon dont vous gérez la promotion de votre application.

Avec les VM, vous faites la promotion de votre application et de ses dépendances d'une VM à la DEV suivante en UAT en PRD.

1. Souvent, ces machines virtuelles auront des correctifs et des bibliothèques différents.
2. Il n'est pas rare que plusieurs applications partagent une VM. Cela nécessite de gérer la configuration et les dépendances pour toutes les applications.
3. La sauvegarde nécessite d'annuler les modifications de la machine virtuelle. Ou le restaurer si possible.

Avec Docker, l'idée est de regrouper votre application dans son propre conteneur avec les bibliothèques dont elle a besoin, puis de promouvoir l' ensemble du conteneur comme une seule unité.

1. À l'exception du noyau, les correctifs et les bibliothèques sont identiques.
2. En règle générale, il n'y a qu'une seule application par conteneur, ce qui simplifie la configuration.
3. Le retrait consiste à arrêter et à supprimer le conteneur.

Donc, au niveau le plus fondamental avec les machines virtuelles, vous promouvez l'application et ses dépendances en tant que composants discrets tandis qu'avec Docker, vous promouvez tout en un seul coup.

Et oui, il y a des problèmes avec les conteneurs, y compris leur gestion, bien que des outils comme Kubernetes ou Docker Swarm simplifient considérablement la tâche.