En quoi Docker est-il différent d'une machine virtuelle?
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 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?
Docker utilisait à l'origine LinuX Containers (LXC), mais est passé plus tard à runC (anciennement appelé 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. Les parties communes du système d'exploitation peuvent être lues en lecture seule (et partagées entre tous vos conteneurs), puis attribuer à chaque conteneur sa propre monture pour écriture.
Donc, disons que vous avez 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. Avec Docker et AuFS, vous pouvez partager la majeure partie du 1 Go entre tous les conteneurs. Si vous disposez de 1 000 conteneurs, il ne reste peut-être 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 virtualisé complet reçoit son propre ensemble de ressources et effectue un partage minimal. Vous obtenez plus d'isolement, mais il 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 faire fonctionner des milliers de conteneurs sur un hôte, qui ne clignote 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 entièrement virtualisé prend généralement quelques minutes à démarrer, tandis que les conteneurs Docker/LXC/runC prennent quelques secondes, voire même moins d’une seconde.
Il existe des avantages et des inconvénients pour chaque type de système virtualisé. Si vous souhaitez une isolation complète avec des ressources garanties, vous devez utiliser un VM complet. Si vous souhaitez simplement isoler les processus les uns des autres et en exécuter une tonne sur un hôte de taille raisonnable, alors Docker/LXC/runC semble être la solution.
Pour plus d’informations, consultez cet ensemble d’articles de blog qui expliquent bien le fonctionnement de LXC.
Pourquoi le déploiement de logiciels sur une image de menu fixe (si c'est le bon terme) est-il plus facile que le simple déploiement dans un environnement de production cohérent?
Le déploiement d'un environnement de production cohérent est plus facile à dire qu'à faire. Même si vous utilisez des outils tels que Chef et Puppet , il y a toujours des mises à jour de système d'exploitation et d'autres éléments qui changent entre les hôtes et les environnements.
Docker vous permet de capturer 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 la même image. Bien sûr, vous pouvez le faire avec d’autres outils, mais pas aussi facilement ni aussi rapidement.
C'est génial pour les tests. Supposons que des milliers de tests doivent être connectés à une base de données et que chaque test nécessite 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 un code personnalisé, soit avec des outils tels que Flyway . Cela peut prendre beaucoup de temps et obliger à exécuter les tests 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écutent tous sur le même instantané de la base de données. Étant donné que les tests se déroulent en parallèle et dans des conteneurs Docker, ils peuvent être exécutés simultanément sur la même boîte et doivent être terminés beaucoup plus rapidement. Essayez de faire cela avec une machine virtuelle complète.
De commentaires ...
Intéressant! Je suppose que la notion d ’" instantané [du système d’exploitation ") me laisse encore perplexe. Comment fait-on cela sans, eh bien, créer 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 à l'aide de docker, qui crée une image. Cette image ne contient que les différences de la base. Lorsque vous souhaitez exécuter votre image, vous avez également besoin de la base, qui la superpose en utilisant un système de fichiers superposé: comme mentionné ci-dessus, Docker utilise AUFS. AUFS fusionne les différentes couches et vous obtenez ce que vous voulez. vous avez juste besoin de l'exécuter. Vous pouvez continuer à ajouter de plus en plus d'images (couches) et il continuera à enregistrer uniquement les diffs. Étant donné que Docker s'appuie généralement sur des images prêtes à l'emploi issues d'un registre , vous devez rarement "capturer" l'ensemble du système d'exploitation vous-même.
Bonnes réponses. Juste pour obtenir une représentation image du conteneur contre la VM, regardez celle ci-dessous.
Il peut être utile de comprendre comment la virtualisation et les conteneurs fonctionnent à bas niveau. Cela éclaircira beaucoup de choses.
Note: 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 VM reprend l'anneau de processeur 0 (ou le "mode racine" des processeurs récents) et intercepte tous les appels privilégiés effectués par le système d'exploitation invité pour créer l'illusion que le système d'exploitation invité dispose de son propre matériel. Anecdote: avant 1998, on pensait qu'il était impossible d'y parvenir sous une architecture x86 car il n'y avait aucun moyen de faire ce type d'interception. Les gens de VMWare étaient les premiers qui ont 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é afin d’atteindre cet objectif.
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é effectue tout le processus d'amorçage, de chargement du noyau, etc. Vous pouvez bénéficier d'une sécurité très stricte, par exemple, un système d'exploitation invité ne peut pas obtenir un accès complet à l'OS hôte ou à d'autres invités et tout gâcher.
Comment les conteneurs fonctionnent-ils à bas niveau?
Autour de 2006 , des personnes, y compris des employés de Google, ont implémenté une nouvelle fonctionnalité au niveau du noyau appelée des espaces de noms (mais l'idée long avant existait 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 avec des processus. Et si ces ressources globales étaient encapsulées dans des espaces de noms de sorte qu'elles ne soient visibles que par les processus exécutés dans le même espace de noms? Disons que vous pouvez obtenir un morceau de disque et le placer dans l’espace de noms X, puis les processus s’exécutant dans l’espace de noms Y ne peuvent pas y accéder ou y accéder. De même, les processus de l'espace de noms X ne peuvent accéder à rien dans la mémoire allouée à l'espace de noms Y. Bien entendu, les processus de X ne peuvent ni voir ni parler aux processus de l'espace de noms Y. Cela fournit un type de virtualisation et d'isolation pour les ressources globales. Voici comment fonctionne Docker: chaque conteneur s'exécute dans son propre espace de noms mais utilise exactement le noyau identique comme tous les autres conteneurs. L'isolation se produit car le noyau connaît l'espace de nom attribué au processus et, lors des appels d'API, s'assure que ce processus ne peut accéder qu'aux ressources de son propre espace de nom.
Les limitations des conteneurs par rapport à VM devraient maintenant être évidentes: vous ne pouvez pas exécuter un système d'exploitation complètement différent dans des conteneurs comme dans les VM. Cependant, vous pouvez exécuter différentes distributions de Linux car elles partagent le même noyau. Le niveau d'isolation n'est pas aussi fort que dans la VM. En fait, il y avait un moyen pour le conteneur "invité" de prendre en charge l'hôte dans les premières mises en œuvre. Vous pouvez également constater que lorsque vous chargez un nouveau conteneur, la nouvelle copie complète du système d'exploitation ne démarre pas comme dans VM. Tous les conteneurs partagent le même noya . C'est pourquoi les conteneurs sont légers. De plus, contrairement à VM, vous n'avez pas à pré-allouer une quantité importante de 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 sur 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 ordinateurs virtuels, Docker ne vise pas uniquement le partage optimal des ressources matérielles. Il fournit en outre un "système" pour l’emballage des applications (préférable, mais pas indispensable, comme un ensemble de microservices).
Pour moi, cela correspond au fossé entre les outils orientés développeur tels que rpm, Debian paquets, Maven , npm + Git d'un côté et les outils ops tels que Puppet , VMware, Xen, vous l'appelez ...
Pourquoi le déploiement de logiciels sur une image de menu fixe (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 rester cohérent? Considérez un certain nombre (> 10) de serveurs et d'applications, des étapes dans le pipeline.
Pour que cela reste synchronisé, vous commencerez à utiliser quelque chose comme Puppet, Chef ou vos propres scripts de provisioning, règles non publiées et/ou beaucoup de documentation ... En théorie, les serveurs peuvent fonctionner indéfiniment et être conservés. complètement cohérent et à jour. Practice ne parvient pas à gérer complètement la configuration d'un serveur. La dérive de configuration et les modifications inattendues apportées aux serveurs en cours sont donc très étendues.
Il existe donc un schéma connu pour éviter cela, le soi-disant serveur immuable. Mais le modèle de serveur immuable n'a pas été aimé. Principalement en raison des limitations des ordinateurs virtuels utilisés avant Docker. Traiter des images de plusieurs gigaoctets, déplacer ces images, juste pour changer certains champs de l'application, était très laborieux. Compréhensible...
Avec un écosystème Docker, vous n’aurez plus jamais besoin de déplacer des gigaoctets pour des "petits changements" (merci aufs et Registry) et vous n'avez pas à craindre de perdre des performances en empaquetant des applications dans un conteneur Docker au moment de l’exécution. Vous n'avez pas à vous soucier des versions de cette image.
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 les ordinateurs virtuels (c'est une bonne idée). Réduisez le provisionnement de votre serveur au niveau VM. Tout ce qui précède pourrait être géré par Docker.
P.S. 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 le 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 dans des conteneurs d’applications. Les conteneurs d'applications sont conçus pour conditionner et exécuter un seul service, alors que les conteneurs système sont conçus pour exécuter plusieurs processus, tels que des machines virtuelles. Docker est donc considéré comme un outil de gestion des conteneurs ou de déploiement d’applications sur des systèmes conteneurisés.
Pour savoir en quoi elle se distingue des autres virtualisations, passons en revue la virtualisation et ses types. Ensuite, il serait plus facile de comprendre quelle est la différence.
Virtualisation
Sous sa forme conçue, il a été considéré comme une méthode de division logique des ordinateurs centraux 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 été en mesure de fournir une méthode de traitement des instructions privilégiées d'une manière ou d'une autre et de permettre à plusieurs systèmes d'exploitation de s'exécuter 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 si nécessaire. 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 encore renforcé 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. incorporation de la prise en charge matérielle dans les processeurs standard, tels qu'Intel VT et AMD-V.
Types de virtualisation
La méthode de virtualisation peut être catégorisée en fonction de la manière dont elle reproduit le matériel sur un système d'exploitation invité et émule l'environnement d'exploitation invité. Il existe principalement trois types de virtualisation:
- Émulation
- Paravirtualisation
- Virtualisation par conteneur
Émulation
L'émulation, également appelée virtualisation complète, exécute le logiciel d'exploitation du noyau de la machine virtuelle. L'hyperviseur utilisé dans ce type est appelé hyperviseur de type 2. Il est installé sur le système d'exploitation de l'hôte, qui est chargé de traduire le code du noyau du système d'exploitation invité en instructions logicielles. La traduction est entièrement réalisée dans un 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 la surcharge des ressources système qui entraîne une baisse des performances par rapport aux autres types de virtualisation.
Les exemples de cette catégorie incluent VMware Player, VirtualBox, QEMU, Bochs, Parallels, etc.
Paravirtualisation
La paravirtualisation, également appelée 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 l’exécutent. Il aide le système d'exploitation, le matériel virtualisé et le matériel réel à collaborer pour atteindre des performances optimales. Ces hyperviseurs ont généralement un encombrement relativement réduit et ne nécessitent pas, en eux-mêmes, de ressources considérables.
Les exemples de cette catégorie incluent Xen, KVM, etc.
Virtualisation par conteneur
La virtualisation par conteneur, également appelée virtualisation au niveau du système d'exploitation, permet plusieurs exécutions isolées au sein d'un même noyau de système d'exploitation. Il offre les meilleures performances et densité possibles et dispose d'une gestion dynamique des ressources. L'environnement d'exécution virtuel isolé fourni par ce type de virtualisation est appelé conteneur et peut être considéré comme un groupe de processus tracé.
Le concept de conteneur est rendu possible par la fonctionnalité des espaces de noms ajoutée à la version 2.6.24 du noyau Linux. Le conteneur ajoute son ID à chaque processus et ajoute de nouvelles vérifications 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 d’espaces de nommage précédemment globaux.
Les espaces de noms peuvent être utilisés de nombreuses manières différentes, mais l'approche la plus courante consiste à créer un conteneur isolé qui n'a aucune visibilité ou accès à des objets en dehors du conteneur. Les processus s'exécutant dans le 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, identiques pour d'autres types d'objets. Par exemple, lors de l'utilisation d'espaces de nommage, l'utilisateur root à l'intérieur du conteneur n'est pas traité comme une racine à l'extérieur du conteneur, ce qui ajoute une sécurité supplémentaire.
Le sous-système Linux Control Groups (cgroups), prochain composant majeur permettant la virtualisation basée sur le conteneur, permet de regrouper des processus et de gérer leur consommation de ressources agrégées. Il est couramment utilisé pour limiter la consommation de mémoire et de processeur des conteneurs. Dans la mesure où un système Linux conteneurisé ne comporte qu'un seul noyau et que celui-ci bénéficie d'une visibilité complète sur les conteneurs, il n'existe qu'un seul niveau d'allocation de ressources et de planification.
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. Par conséquent, les conteneurs peuvent être créés en moins d'une seconde. Cette fonctionnalité rend la virtualisation par conteneur unique et souhaitable par rapport aux autres approches de virtualisation.
Étant donné que la virtualisation basée sur le conteneur ajoute peu ou pas de surcharge à la machine hôte, les performances de la virtualisation basée sur le conteneur sont quasi natives.
Pour la virtualisation par conteneur, 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, ce qui évite des ressources supplémentaires.
Les états des conteneurs (images Docker ou LXC) sont de taille réduite par rapport aux images de machine virtuelle. Les images de conteneur sont donc faciles à distribuer.
La gestion des ressources dans les conteneurs est réalisée par le biais de groupes de contrôle. Cgroups ne permet pas aux conteneurs de consommer plus de ressources que ce qui leur est alloué. Cependant, à partir de maintenant, 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 top ou htop sur les conteneurs et la machine hôte en même temps. La sortie dans tous les environnements sera similaire.
Mise à jour:
Comment Docker exécute-t-il des conteneurs sur des systèmes autres que Linux?
Si les conteneurs sont possibles en raison des fonctionnalités disponibles dans le noyau Linux, 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 les ordinateurs virtuels Virtual Box. Mais le dernier Docker utilise Hyper-V sous Windows et Hypervisor.framework sous Mac.
Laissez-moi maintenant décrire comment Docker pour Mac exécute les conteneurs en détail.
Docker pour Mac utilise https://github.com/moby/hyperkit pour émuler les capacités d'hyperviseur et Hyperkit utilise hypervisor.framework en son noyau. Hypervisor.framework est la solution d’hyperviseur native de Mac. Hyperkit utilise également VPNKit et DataKit pour le réseau d’espaces de noms et le système de fichiers, respectivement.
Linux VM que Docker exécute sous Mac est en lecture seule. Cependant, vous pouvez y accéder en lançant:
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 dans cette machine virtuelle.
Hypervisor.framework a quelques limitations. À cause de cela, Docker n'expose pas l'interface réseau docker0 sous Mac. Vous ne pouvez donc pas accéder aux conteneurs à partir de l'hôte. A partir de maintenant, docker0 n'est disponible que dans la VM.
Hyper-v est l'hyperviseur natif de Windows. Ils tentent également de tirer parti des capacités de Windows 10 pour exécuter les systèmes Linux de manière native.
A travers cet article, nous allons tracer des 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 ressources matérielles CPU, mémoire, disque dur, réseau et autres sont gérées par une couche de virtualisation qui traduit ces demandes en matériel physique sous-jacent.
Dans ce contexte, la VM est appelée en tant qu'invité tandis que l'environnement sur lequel il 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 ordinateurs virtuels, car ils ne requièrent pas l'hyperviseur. Virtualbox, KVM, Xen, etc.
Maintenant, à moins que vous 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 au courant du formidable élan d'intérêt suscité par la technologie des conteneurs Linux, et si je vais être spécifique à un conteneur Le projet qui a fait le buzz dans le monde entier ces derniers mois est - Docker fait écho à l'opinion selon laquelle les environnements informatiques en nuage devraient abandonner les machines virtuelles (VM) et les remplacer par des conteneurs en raison de leurs frais généraux et de leurs performances potentiellement meilleures.
Mais la grande question est: est-ce faisable?
une. Les LXC sont étendus à une instance de Linux. Il peut s'agir de variantes de Linux (par exemple, un conteneur Ubuntu sur un hôte CentOS mais ce dernier est toujours Linux). De la même manière, les conteneurs Windows sont étendus à une instance de Windows si les machines virtuelles ont une portée beaucoup plus large et utilisent le hyperviseurs, vous n'êtes pas limité aux systèmes d'exploitation Linux ou Windows.
b. Les LXC ont des frais généraux peu élevés et des performances supérieures à celles des ordinateurs virtuels. Outils à savoir. Docker, qui repose sur la technologie LXC, a fourni aux développeurs une plate-forme pour exécuter leurs applications et, en même temps, a doté les responsables des opérations d’un outil leur permettant de déployer le même conteneur sur des serveurs de production ou des centres de données. Il tente de rendre l'expérience entre un développeur exécutant une application, démarrant et testant une application, et une personne chargée des opérations déployant cette application, car c'est là que tout le frottement réside et que l'objectif de DevOps est de décomposer ces silos.
La meilleure approche est donc que les fournisseurs d'infrastructure cloud devraient préconiser une utilisation appropriée des machines virtuelles et de LXC, chacune étant adaptée à la gestion de charges de travail et de scénarios spécifiques.
Abandonner les ordinateurs virtuels n’est pas pratique pour le moment. Les VM et les LXC ont donc leur propre existence et leur importance.
La plupart des réponses ici parlent de machines virtuelles. Je vais vous donner une réponse unique à 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, laissez-moi vous expliquer un peu plus ce que cela signifie. Les machines virtuelles sont leur propre bête. J'ai envie d'expliquer ce que Docker vous aidera à comprendre davantage que d'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". Alors...
Un conteneur Docker est simplement un processus (et ses enfants) compartimenté à l'aide de cgroups dans le noyau du système hôte à partir du reste des processus. Vous pouvez réellement voir vos processus de conteneur Docker en exécutant ps aux sur l'hôte. Par exemple, le démarrage de Apache2 "dans un conteneur" ne fait que démarrer Apache2 en tant que processus spécial sur l'hôte. Il vient tout juste d'être compartimenté par rapport aux autres processus de 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. En effet, Docker remplace pid 1 dans votre conteneur avec votre application (pid 1 est normalement le système init). Ce dernier point à propos de pid 1 est très important.
En ce qui concerne le système de fichiers utilisé par chacun de ces processus de conteneur, Docker utilise nionFS - des images sauvegardées, ce que vous téléchargez en effectuant un docker pull ubuntu. Chaque "image" est juste une série de couches et de métadonnées associées. Le concept de superposition est très important ici. Chaque couche est juste un changement de la couche en dessous. Par exemple, lorsque vous supprimez un fichier dans votre fichier Docker lors de la construction d'un conteneur Docker, vous créez en fait un calque au-dessus du dernier calque indiquant "ce fichier a été supprimé". C'est d'ailleurs pour cette raison que vous pouvez supprimer un gros fichier de votre système de fichiers, mais que l'image occupe toujours la même quantité d'espace disque. Le fichier est toujours là, dans les couches sous le fichier actuel. Les couches elles-mêmes ne sont que des archives de fichiers. Vous pouvez tester ceci avec docker save --output /tmp/ubuntu.tar ubuntu puis cd /tmp && tar xvf ubuntu.tar. Ensuite, vous pouvez regarder autour de vous. Tous les répertoires qui ressemblent à de longs hachages sont en réalité les couches individuelles. Chacun contient des fichiers (layer.tar) et des métadonnées (json) contenant 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 "par-dessus" 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 changements les plus hautes. 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 en haut. Cela permet à des conteneurs totalement différents de partager leurs couches de système de fichiers, même si des modifications importantes peuvent avoir été apportées au système de fichiers des couches situées en haut de chaque conteneur. Cela peut vous faire économiser une tonne d'espace disque lorsque vos conteneurs partagent leurs couches d'image de base. Toutefois, lorsque vous montez des répertoires et des fichiers du système hôte dans votre conteneur à l'aide de volumes, ceux-ci "contournent" UnionFS, de sorte que les modifications ne sont pas stockées dans des couches.
La mise en réseau dans Docker est réalisée à l'aide d'un pont Ethernet (appelé docker0 sur l'hôte) et d'interfaces virtuelles pour chaque conteneur de l'hôte. Il crée un sous-réseau virtuel dans docker0 pour que vos conteneurs puissent communiquer "entre" les uns les autres. Il existe de nombreuses options pour la mise en réseau ici, y compris 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 y accéder directement.
Docker va très vite. 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 consulter la documentation disponible pour plus d'informations et de faire confiance à la documentation avant tout ce que vous lisez en ligne, y compris Stack Overflow. Si vous avez des questions spécifiques, je vous recommande vivement de rejoindre #docker sur Freenode IRC et de le demander (vous pouvez même utiliser le Webchat de Freenode!).
Docker encapsule une application avec toutes ses dépendances.
Un virtualiseur encapsule un système d'exploitation pouvant exécuter toutes les applications qu'il peut normalement exécuter sur une machine sans système d'exploitation.
Ils sont tous les deux très différents. Docker est léger et utilise LXC/libcontainer (qui repose sur l'espacement des noms du noyau et les groupes de contrôle) et ne dispose pas d'une émulation machine/matériel telle que l'hyperviseur, KVM. Xen qui sont lourds.
Docker et LXC sont davantage destinés au sandboxing, à la conteneurisation et à l'isolation des ressources. Il utilise l'API de clonage du système d'exploitation hôte (uniquement pour le noyau Linux) qui fournit un espacement de nom 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 groupes de contrôle où vous pouvez créer des groupes avec certaines ressources (CPU, mémoire, etc.) spécification/restriction et y placer vos processus. En plus de LXC, Docker fournit un système de stockage ( http://www.projectatomic.io/docs/filesystems/ ), par exemple, un système de fichiers de montage en union où vous pouvez ajouter des calques et les partager entre différents espaces de noms. .
Il s'agit d'une fonctionnalité puissante dans laquelle 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 écrira quelque chose sur la partition en lecture-écriture (une copie sur écriture). Il fournit également de nombreux autres wrappers, tels que le registre et le contrôle de version des images.
Avec LXC normal, vous devez fournir des rootfs ou les partager quand ils sont partagés. Les modifications sont répercutées sur les autres conteneurs. En raison de nombreuses fonctionnalités supplémentaires, Docker est plus populaire que LXC. LXC est populaire dans les environnements intégrés pour la mise en œuvre de la sécurité autour de processus exposés à des entités externes telles que le réseau et l'interface utilisateur. Docker est populaire dans les environnements multi-locataires en nuage où un environnement de production cohérent est attendu.
Un VM normal (par exemple, VirtualBox et VMware) utilise un hyperviseur. Les technologies associées disposent d'un micrologiciel dédié qui devient la première couche du premier système d'exploitation (OS hôte ou invité 0) ou d'un logiciel s'exécute sur le système d'exploitation hôte pour fournir aux systèmes d'exploitation invités une émulation matérielle telle qu'un processeur, une clé USB/des accessoires, une mémoire, un réseau, etc. Les machines virtuelles sont toujours (à partir de 2015) populaires dans un environnement multi-locataire haute sécurité.
Docker/LXC peut presque fonctionner sur tout matériel économique (moins de 1 Go de mémoire est également acceptable tant que le noyau est récent), alors que les machines virtuelles normales ont besoin d'au moins 2 Go de mémoire, etc. . Mais la prise en charge de Docker sur le système d'exploitation hôte n'est pas disponible dans les systèmes d'exploitation tels que Windows (à compter de novembre 2014), où des types de machines virtuelles peuvent être exécutés sous Windows, Linux et Mac.
Voici une photo de docker/rightscale: 
1. Léger
C'est probablement la première impression pour beaucoup d'apprenants dockers.
Premièrement, les images du menu fixe 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 VM démarre en secondes.
2. Système de fichiers en couches
C'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 rapide à créer.
Si tous les conteneurs utilisent Ubuntu comme images de base, toutes les images ne possèdent 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é
Pensez aux conteneurs en tant que processus!
Tous les conteneurs s'exécutant sur un hôte constituent en effet un ensemble de processus avec différents systèmes de fichiers. Ils partagent le même noyau de système d'exploitation, n'encapsulant que la bibliothèque système et les dépendances.
Ceci est utile dans la plupart des cas (aucun noyau supplémentaire n'est maintenu par le noyau du système d'exploitation), mais peut poser problème si des isolements stricts sont nécessaires entre les conteneurs.
Pourquoi est-ce important?
Tout cela semble être une amélioration, pas une révolution. Eh bien, l'accumulation quantitative conduit à une transformation qualitative .
Pensez au déploiement d'applications. Si nous souhaitons déployer un nouveau logiciel (service) ou en mettre à niveau un, il est préférable de modifier les processus et les fichiers de configuration plutôt que de créer un nouvel ordinateur virtuel. Étant donné que la création d'un VM avec un service mis à jour, le test (partage entre développeurs et assurance qualité), 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. Utilisez donc un outil de gestion de la configuration (marionnettes, saltstack, chef, etc.) pour installer un nouveau logiciel. Il est préférable de télécharger de nouveaux fichiers.
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 le service d'assurance qualité, la tester, la déployer ne prend que quelques minutes (si tout est automatisé), des heures dans le pire des cas. Cela s'appelle infrastructure immuable: ne maintenez pas de logiciel (de mise à niveau), créez-en un nouveau.
Cela transforme la manière dont les services sont fournis. Nous voulons des applications, mais devons maintenir les machines virtuelles (ce qui est pénible et a peu à 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 a le sentiment qu’elle dispose d’une instance complète d’un système d’exploitation alors que VM prend en charge virtualisation matérielle . Vous avez l’impression que c’est une machine physique sur laquelle vous pouvez démarrer n’importe quel système d’exploitation.
Dans Docker, les conteneurs exécutés partagent le noyau de l'OS hôte, alors que dans les VM, ils possèdent leurs propres fichiers OS. L’environnement (le système d’exploitation) dans lequel vous développez une application sera le même lorsque vous la déploierez dans différents environnements de services, 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 ne fonctionne donc plus. 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. Ainsi, les dépendances seraient également présentes à tout endroit de l'image.
Dans l'exemple ci-dessous, la machine hôte dispose de trois ordinateurs virtuels. Afin de fournir aux applications des machines isolées complètes, les machines virtuelles disposent chacune de leurs propres copies de fichiers de système d'exploitation, de bibliothèques et de code d'application, ainsi que d'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 de l’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 utilisé est la mémoire et l'espace disque nécessaires à l'exécution de l'application dans le conteneur. Bien que l’environnement de l’application ressemble à un système d’exploitation dédié, l’application se déploie exactement comme 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 VM. 
Source: https://Azure.Microsoft.com/en-us/blog/containers-docker-windows-and-trends/
Il existe trois configurations différentes qui fournissent une pile sur laquelle exécuter une application (cela nous aidera à reconnaître ce qu'est un conteneur et ce qui le rend plus puissant que d'autres solutions):
1) Traditional Servers(bare metal)
2) Virtual machines (VMs)
3) Containers
1) Serveur traditionnel La pile est constituée d’un serveur physique exécutant un système d’exploitation et votre application.
Avantages:
Utilisation des ressources brutes
Isolement
Inconvénients:
- Temps de déploiement très lent
- Coûteux
- Ressources gaspillées
- Difficile à l'échelle
- Difficile de migrer
- Configuration complexe
2) Le groupe VM stack consiste en un serveur physique qui exécute un système d'exploitation et un hyperviseur qui gère votre machine virtuelle, vos ressources partagées et votre interface réseau. Chaque VM exécute un système d'exploitation invité, une application ou un ensemble d'applications.
Avantages:
- Bon usage des ressources
- Facile à mettre à l'échelle
- Facile à sauvegarder et à migrer
- Rapport coût-efficacité
- Souplesse
Inconvénients:
- L'allocation des ressources est problématique
- Lockin du vendeur
- Configuration complexe
3) Configuration du conteneur, la principale différence avec les autres piles est que la virtualisation basée sur le conteneur utilise le noyau du système d'exploitation hôte pour définir plusieurs instances d'invité isolées. Ces instances d'invité sont appelées conteneurs. L'hôte peut être un serveur physique ou une machine virtuelle.
Avantages:
- Isolement
- Poids léger
- Ressource efficace
- Facile à migrer
- Sécurité
- Frais généraux bas
- Environnement de production et de développement de miroirs
Inconvénients:
- Même architecture
- Applications lourdes en ressources
- Problèmes de mise en réseau et de sécurité.
En comparant la configuration du conteneur avec ses prédécesseurs, nous pouvons en conclure que la conteneurisation est la configuration la plus rapide, la plus efficace sur le plan des 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 certaine manière, les couches reçoivent 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 la couche de copie sur écriture créée par dessus une fois que nous nous sommes engagés dans le conteneur, exécute l'exécution des conteneurs. Dans le cas de machines virtuelles, le chargement de tout dans l'environnement de virtualisation prend environ une minute. 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 constitue une aide précieuse dans les processus de CI/CD. Les avantages que les conteneurs peuvent offrir sont si convaincants qu'ils sont définitivement là pour rester.
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 VM utilisent un noyau séparé 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. par conséquent, il est 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 ne sont donc pas pleinement utilisées lorsque la machine virtuelle est inactive plusieurs fois. Dans Docker, les conteneurs ne sont pas alloués avec une quantité fixe de ressources matérielles. Ils 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 utilisé par les conteneurs. Lire la suite ici
En relation avec:-
"Pourquoi le déploiement de logiciels sur une image de menu fixe est-il plus facile que le simple 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:
- PC développeur individuel
- Environnement de développeur partagé
- PC testeur individuel
- Environnement de test partagé
- Environnement QA
- Environnement UAT
- Test de charge/performance
- Mise en scène en direct
- Production
- Archiver
Il faut également tenir compte des facteurs suivants:
- Les développeurs, et même les testeurs, auront tous des configurations de PC subtiles ou très différentes, en fonction de la nature même du travail.
- Les développeurs peuvent souvent développer sur des PC au-delà du contrôle des règles de standardisation d'entreprise ou d'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 "engagés" pour configurer leurs PC façon)
- Certains environnements consisteront en un nombre fixe de plusieurs machines dans une configuration à charge équilibrée
- De nombreux environnements de production auront des serveurs en nuage créés et détruits de manière dynamique (ou "élastiquement") en fonction des niveaux de trafic.
Comme vous pouvez le constater, le nombre total de serveurs extrapolés pour une organisation est rarement chiffré à un chiffre, très souvent à trois chiffres et peut facilement être considérablement plus élevé encore.
Tout cela signifie que la création d'environnements cohérents au départ est déjà assez difficile simplement à cause du volume considérable (même dans un scénario à fond vert), mais les maintenir cohérents est quasiment impossible étant donné le nombre élevé de serveurs, ajout de nouveaux serveurs (de manière dynamique ou manuelle), mises à jour automatiques de fournisseurs O/S, de fournisseurs d'antivirus, de fournisseurs de navigateurs, etc., installations manuelles de logiciels ou modifications de configuration effectuées par des développeurs ou des techniciens de serveurs, etc. Permettez-moi de répéter - c'est pratiquement (sans jeu de mots) impossible de garder des environnements cohérents (ok, pour les puristes, cela peut être fait, mais cela demande énormément 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 dans la première place).
Alors, pensez plutôt à votre question "Etant donné la difficulté extrême de maintenir la cohérence de tous les environnements, est-il plus facile de déployer un logiciel sur une image fixe, même en tenant compte de la courbe d’apprentissage?" . Je pense que vous constaterez que la réponse sera invariablement "oui" - mais il n’ya qu’un moyen de le savoir: posez cette nouvelle question sur Stack Overflow.
Avec une machine virtuelle , nous avons un serveur, nous avons un système d'exploitation hôte sur ce serveur, puis un hyperviseur. Et puis, fonctionnant au-dessus de cet hyperviseur, nous avons un nombre quelconque de systèmes d'exploitation invités avec une application et ses fichiers binaires dépendants, ainsi que des bibliothèques sur ce serveur. Il apporte tout un système d'exploitation invité. C'est assez lourd. De plus, il y a une limite à ce que vous pouvez réellement mettre sur chaque machine physique.
Les conteneurs Docker sont en revanche 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 de Docker , dans ce cas . Dans ce cas, nous n’apportons pas un système d’exploitation invité complet. Nous apportons une couche très fine 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.
Il ne contient que le code de l'application, ainsi que les fichiers binaires et les bibliothèques nécessaires. Et ces fichiers binaires et bibliothèques peuvent en fait être partagés entre différents conteneurs si vous souhaitez qu'ils le soient également. Et cela nous permet de faire un certain nombre de choses. Ils ont un temps de démarrage beaucoup plus rapide . Vous ne pouvez pas tenir un seul VM en quelques secondes de la sorte. Et également, en les abaissant aussi rapidement… afin que nous puissions monter et descendre très rapidement et nous examinerons cela plus tard.
Chaque conteneur pense qu'il s'exécute sur sa propre copie du système d'exploitation. Il possède son propre système de fichiers, son propre registre, etc., ce qui est une sorte de mensonge. C’est en train d’être virtualisé.
J'ai beaucoup utilisé Docker dans des environnements de production et de mise en scène. Lorsque vous vous y habituerez, vous constaterez qu'il est très puissant pour créer un environnement multi-conteneurs et isolé.
Docker a été développé sur la base de LXC (Linux Container) et fonctionne parfaitement dans de nombreuses distributions Linux, notamment Ubuntu.
Les conteneurs Docker sont des environnements isolés. Vous pouvez le voir lorsque vous exécutez la commande top dans un conteneur Docker créé à partir d'une image Docker.
En outre, ils sont très légers et flexibles grâce à la configuration de dockerFile.
Par exemple, vous pouvez créer une image Docker et configurer un fichier DockerFile et le dire, par exemple, lorsqu'il s'exécute, puis wget 'this', apt-get 'that', exécutez 'un script Shell', définissez des variables d'environnement, etc.
Dans les projets et l’architecture de micro-services, Docker est un atout très viable. Vous pouvez obtenir évolutivité, résilience et élasticité avec Docker, Docker swarm, Kubernetes et Docker Compose.
Un autre problème important concernant Docker est Docker Hub et sa communauté. Par exemple, j'ai mis en place un écosystème pour surveiller kafka à l'aide de Prometheus, Grafana, Prometheus-JMX-Exporter et Dokcer.
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 yml ou pour d'autres, j'ai modifié certains fichiers et la configuration dans le conteneur Docker et j'ai construit l'ensemble système de surveillance kafka utilisant des Dockers à conteneurs multiples sur une seule machine avec isolation, évolutivité et résilience, ce qui permet de déplacer facilement cette architecture sur plusieurs serveurs.
Outre le site Docker Hub, il existe un autre site appelé quay.io que vous pouvez utiliser pour disposer de votre propre tableau de bord des images Docker et pour tirer/pousser vers/depuis. Vous pouvez même importer des images Docker de Docker Hub sur un quai, puis les exécuter à partir du quai sur votre propre ordinateur.
Remarque: apprendre Docker en premier lieu semble complexe et difficile, mais lorsque vous vous y habituerez, vous ne pourrez plus travailler sans.
Je me souviens des premiers jours où je travaillais avec Docker lorsque j’émettais les mauvaises commandes ou supprimais mes conteneurs ainsi que toutes les données et configurations par erreur.
Source: Kubernetes en action.
Voici comment Docker se présente:
Docker est la société qui gère le mouvement des conteneurs et le seul fournisseur de plate-forme de conteneurs à traiter toutes les applications du cloud hybride. Les entreprises d’aujourd’hui subissent des pressions pour se transformer numériquement, mais sont contraintes par les applications et l’infrastructure existantes tout en rationalisant un portefeuille de plus en plus diversifié de nuages, de centres de données et d’architectures d’application. Docker permet une réelle indépendance entre les applications et les infrastructures, ainsi que les développeurs et les responsables informatiques, afin de libérer leur potentiel et crée un modèle pour une meilleure collaboration et innovation.
Donc Docker est basé sur des conteneurs, ce qui signifie que vous avez des images et des conteneurs pouvant être exécutés sur votre ordinateur actuel. Cela n'inclut pas le système d'exploitation comme VM s, mais ressemble à un pack de différents packs de travail tels que Java, Tomcat, etc.
Si vous comprenez les conteneurs, vous obtenez ce qu'est Docker et en quoi il est différent de VM s ...
Alors, qu'est-ce qu'un conteneur?
Une image de conteneur est un package léger, autonome et exécutable d'un logiciel qui inclut tout le nécessaire pour l'exécuter: code, exécution, outils système, bibliothèques système, paramètres. Disponible pour les applications Linux et Windows, le logiciel conteneurisé fonctionnera 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.
Comme vous le voyez dans l'image ci-dessous, chaque conteneur possède un pack séparé et s'exécute sur une seule machine partageant le système d'exploitation de cette machine ... Ils sont sécurisés et faciles à expédier ...
Il y a beaucoup de réponses techniques intéressantes ici qui décrivent clairement les différences entre les machines virtuelles et les conteneurs, ainsi que les origines de Docker.
Pour moi, la différence fondamentale entre les ordinateurs virtuels et Docker réside dans la manière dont vous gérez la promotion de votre application.
Avec les VM, vous promouvez votre application et ses dépendances d’un VM au prochain DEV, de l’UAT au PRD.
- Souvent, ces machines virtuelles auront des correctifs et des bibliothèques différents.
- Il n'est pas rare que plusieurs applications partagent une machine virtuelle. Cela nécessite de gérer la configuration et les dépendances de toutes les applications.
- La sauvegarde nécessite l'annulation des 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 le conteneur entier en une seule unité.
- À l'exception du noyau, les correctifs et les bibliothèques sont identiques.
- En règle générale, il n'y a qu'une seule application par conteneur, ce qui simplifie la configuration.
- La sauvegarde consiste à arrêter et à supprimer le conteneur.
Ainsi, au niveau le plus fondamental avec les ordinateurs virtuels, vous promouvez l'application et ses dépendances en tant que composants discrets, tandis que Docker permet de tout promouvoir 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 grandement la tâche.