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


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

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


2910
2018-04-16 21:19


origine


Réponses:


Docker utilisé à l'origine Conteneurs LinuX (LXC), mais plus tard commuté à runC (anciennement connu sous le nom de libcontainer), qui s'exécute dans le même système d'exploitation que son hôte. Cela lui permet de partager un grand nombre de ressources du système d'exploitation hôte. En outre, il utilise un système de fichiers en couches (AuFS) et gère le réseautage.

AuFS est un système de fichiers en couches, de sorte que vous pouvez 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é entre tous vos conteneurs), puis donner à chaque conteneur son propre montage pour l'écriture.

Supposons 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 fois le nombre de machines virtuelles souhaité. Avec Docker et AuFS, vous pouvez partager la majeure partie des 1 Go entre tous les conteneurs et si vous avez 1000 conteneurs, vous pouvez toujours avoir 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) .

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'isolation, 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 il ne clignotera même pas. Essayez de faire ça avec Xen, et à moins d'avoir un très gros serveur, je ne pense pas que ce soit possible.

Un système virtualisé complet prend généralement quelques minutes pour démarrer, alors que les conteneurs Docker / LXC / runC prennent des 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 voulez simplement isoler les processus les uns des autres et que vous voulez 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 de billets de blog qui fait un bon travail d'expliquer comment fonctionne LXC.

Pourquoi est-il plus facile de déployer un logiciel sur une image de docker (si c'est le bon terme) que de simplement le déployer 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 Fantoche, 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 permet de capturer le système d'exploitation dans une image partagée et de le déployer facilement sur d'autres hôtes Docker. Localement, dev, qa, prod, etc .: tous de la même image. Bien sûr, vous pouvez le faire avec d'autres outils, mais pas aussi facilement ou rapidement.

C'est génial pour les tests; Disons que vous avez des milliers de tests qui doivent se connecter à une base de données, et chaque test nécessite une copie parfaite 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 comme S'envoler - 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 lancer 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 sont exécutés en parallèle et dans des conteneurs Docker, ils peuvent tous fonctionner sur la même boîte en même temps et devraient se terminer beaucoup plus rapidement. Essayez de le faire avec une VM complète.

De commentaires ...

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

Eh bien, voyons si je peux expliquer. Vous commencez avec une image de base, puis effectuez vos modifications et validez ces modifications à l'aide du menu fixe, puis créez une image. Cette image ne contient que les différences par rapport à la base. Lorsque vous voulez exécuter votre image, vous avez également besoin de la base, et elle superpose votre image sur la base en utilisant un système de fichiers en couches: comme mentionné ci-dessus, Docker utilise AUFS. AUFS fusionne les différentes couches et vous obtenez ce que vous voulez; vous avez juste besoin de le lancer. Vous pouvez continuer à ajouter de plus en plus d'images (couches) et continuer à enregistrer uniquement les différences. Depuis Docker construit généralement sur le dessus d'images prêtes à l'emploi à partir d'un enregistrement, vous avez rarement besoin de "prendre un instantané" de l'OS entier.


2807
2018-04-16 22:35



Bonnes réponses Juste pour obtenir une représentation d'image de conteneur vs VM, jetez un oeil à celui ci-dessous.

enter image description here

La source: https://www.docker.com/what-container#/package_software


338
2017-10-14 18:02



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

Note: Je simplifie un peu en décrivant ci-dessous. Voir les références pour plus d'informations.

Comment fonctionne la virtualisation à bas niveau?

Dans ce cas, le gestionnaire VM prend en charge l'anneau CPU 0 (ou le «mode racine» dans les nouvelles CPU) et intercepte tous les appels privilégiés effectués par l'OS invité pour créer l'illusion que l'OS invité a son propre matériel. Fait amusant: Avant 1998, on pensait qu'il était impossible de réaliser cela dans l'architecture x86 car il n'y avait aucun moyen de faire ce genre d'interception. Les gens de VMWare étaient les premiers qui avait une idée de réécrire les octets exécutables en mémoire pour les appels privilégiés d'OS 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 OS invité passe par tous les processus d'amorçage, de chargement du noyau, etc. Vous pouvez avoir une sécurité très stricte, par exemple, l'OS invité ne peut pas avoir un accès complet à l'OS hôte ou à d'autres invités.

Comment les conteneurs fonctionnent à bas niveau?

Autour 2006, les gens, y compris certains des employés de Google mis en œuvre une nouvelle fonctionnalité de niveau du noyau appelé espaces de noms (cependant l'idée longue avant existait dans FreeBSD). Une fonction du système d'exploitation est de permettre le partage des ressources globales comme le réseau et le disque vers les processus. Que se passe-t-il si ces ressources globales ont été enveloppées dans des espaces de noms afin qu'elles ne soient visibles que pour 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 de l'espace de noms X ne peuvent accéder à aucune mémoire allouée à l'espace de noms Y. Bien entendu, les processus de X ne peuvent pas voir ou parler aux processus de l'espace de noms Y. Voici comment fonctionne docker: Chaque conteneur s'exécute dans son propre espace de noms mais utilise exactement le même noyau comme tous les autres conteneurs. L'isolation se produit car le noyau connaît l'espace de noms affecté au processus et lors des appels d'API, il s'assure que le processus ne peut accéder aux ressources que dans son propre espace de noms.

Les limitations des conteneurs vs VM 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'isolation n'est pas aussi fort que dans VM. En fait, il y avait 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 complète du système d'exploitation ne démarre pas comme dans VM. Tous les conteneurs partager le même noyau. C'est pourquoi les contenants sont légers. De même, contrairement à VM, vous n'avez pas besoin de pré-allouer une partie importante 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 pendant le sandbox, ce qui pourrait ne pas être possible si nous exécutions une copie séparée du système d'exploitation sur sa propre machine virtuelle.


294
2018-01-13 01:49



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 tout le processus. Contrairement aux machines virtuelles, Docker n'est pas (seulement) sur le partage optimal des ressources matérielles, en outre, il fournit un "système" pour l'application de l'emballage (préférable mais pas un must, comme un ensemble de Microservices).

Pour moi, cela correspond à l'écart entre les outils orientés développeur comme rpm, les paquets debian, maven, npm + git d'un côté et les outils Ops comme Puppet, VMWare, Xen vous l'appelez ...

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

Votre question suppose un environnement de production cohérent. Mais comment le garder cohérent?  Considérons une certaine quantité (> 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, des règles non publiées et / ou beaucoup de documentation ... En théorie, les serveurs peuvent fonctionner indéfiniment et être maintenus complètement cohérents et à jour. La pratique ne parvient pas à gérer complètement la configuration d'un serveur. Il existe donc une marge considérable de dérive de la configuration et des modifications inattendues des serveurs en cours d'exécution.

Donc, il y a un modèle connu pour éviter cela, le soi-disant Serveur immuable. Mais le modèle de serveur immuable n'a pas été aimé. Surtout à cause des limitations des machines virtuelles, il était utilisé avant Docker. Traiter plusieurs images gigabytes, déplacer ces grandes images, juste pour changer certains champs de l'application, était très très laborieux. Compréhensible...

Avec un écosystème Docker, vous n'aurez jamais besoin de déplacer des gigaoctets sur de «petits changements» (Merci aufs et Registry) et vous n'avez pas besoin de perdre vos performances en empaquetant des applications dans un conteneur Docker à l'exécution. Vous n'avez pas besoin de 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 des conteneurs docker dans les 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.

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


279
2017-09-19 16:21



Docker n'est pas une méthodologie de virtualisation. Il s'appuie sur d'autres outils qui implémentent 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 il est passé à libcontainer qui est maintenant renommé en tant que runc. Docker se concentre principalement sur l'automatisation du déploiement des applications dans les 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, tels que des machines virtuelles. Ainsi, Docker est considéré comme un outil de gestion de conteneur ou de déploiement d'application sur les systèmes conteneurisés.

Pour savoir comment elle est différente des autres virtualisations, passons à la virtualisation et à ses types. Ensuite, il serait plus facile de comprendre quelle est la différence là-bas.

Virtualisation

Dans sa forme conçue, elle était considérée comme une méthode de division logique des mainframes pour permettre à plusieurs applications de fonctionner 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 gestion des instructions privilégiées d'une manière ou d'une autre et permettre l'exécution simultanée de plusieurs systèmes d'exploitation sur un seul système basé sur 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 poussé 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. l'intégration du support matériel dans les processeurs de produits, tels que Intel VT et AMD-V.

Types de virtualisation

La méthode de virtualisation peut être catégorisée en fonction de la façon dont elle imite le matériel d'un système d'exploitation invité et émule l'environnement d'exploitation invité. Principalement, il existe trois types de virtualisation:

  • Émulation
  • Paravirtualisation
  • Virtualisation par conteneur

Émulation

L'émulation, également appelée virtualisation complète, exécute entièrement le noyau du système d'exploitation de la machine virtuelle dans les logiciels. L'hyperviseur utilisé dans ce type est connu sous le nom d'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 noyau du système d'exploitation invité en instructions logicielles. La traduction est entièrement réalisée en logiciel et ne nécessite aucune intervention matérielle. L'émulation permet d'exécuter tout système d'exploitation non modifié prenant en charge l'environnement en cours d'émulation. L'inconvénient de ce type de virtualisation est l'augmentation des ressources système qui entraîne une baisse des performances par rapport aux autres types de virtualisation.

Emulation

Les exemples dans 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 y sont exécutées. Il aide le système d'exploitation, le matériel virtualisé et le matériel réel à collaborer pour obtenir des performances optimales. Ces hyperviseurs ont généralement une empreinte plutôt faible et ne nécessitent pas de ressources importantes.

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

Paravirtualization

Virtualisation par conteneur

La virtualisation par conteneur, également appelée virtualisation au niveau du système d'exploitation, permet de multiples exécutions isolées dans un même noyau de système d'exploitation. Il offre les meilleures performances et la meilleure densité possibles et propose une gestion dynamique des ressources. L'environnement d'exécution virtuel isolé fourni par ce type de virtualisation est appelé conteneur et peut être vu comme un groupe de processus tracés.

Container-based virtualization

Le concept d'un conteneur est rendu possible par la fonctionnalité namespaces 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 le cloner() appel système qui permet de créer des instances distinctes d'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 pas de visibilité ou d'accès aux objets à l'extérieur 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 racine à 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 composant majeur suivant permettant la virtualisation par conteneur, est utilisé pour regrouper les processus et gérer leur consommation de ressources agrégées. Il est couramment utilisé pour limiter la consommation de mémoire et de CPU des conteneurs. Comme un système Linux conteneurisé n'a qu'un 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 de 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 par conteneur unique et souhaitable par rapport aux autres approches de virtualisation.

Étant donné que la virtualisation par conteneur n'entraîne que peu ou pas de surcharge pour la machine hôte, la virtualisation par conteneur a des performances quasi natives.

Pour la virtualisation par conteneur, aucun logiciel supplémentaire n'est requis, contrairement aux autres virtualisations.

Tous les conteneurs d'une machine hôte partagent le planificateur de la machine hôte, ce qui permet d'économiser des ressources supplémentaires.

Les états de conteneur (images Docker ou LXC) sont de petite taille par rapport aux images de machine virtuelle, donc les images de conteneur sont faciles à distribuer.

La gestion des ressources dans les conteneurs est réalisée par des groupes de contrôle. Cgroups n'autorise pas les conteneurs à consommer plus de ressources que celles qui leur sont allouées. 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 courant top ou htop sur les conteneurs et la machine hôte en même temps. La sortie dans tous les environnements sera similaire.


121
2018-04-02 00:55



A travers ce post, nous allons dessiner quelques lignes de différences entre VM et LXC. Commençons par les définir.

VM:

Une machine virtuelle émule un environnement informatique physique, mais les demandes d'unité centrale, 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 requêtes vers le matériel physique sous-jacent.

Dans ce contexte, la machine virtuelle est appelée en tant qu'invité alors que l'environnement sur lequel elle s'exécute s'appelle l'hôte.

LXCs:

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

Maintenant, sauf si vous avez été drogué par Alan (Zach Galifianakis de la série Hangover) et que vous êtes à Vegas depuis un an, vous serez très conscient de l'énorme intérêt pour la technologie des conteneurs Linux, et si je vais être un conteneur spécifique Le projet qui a suscité un engouement dans le monde au cours des derniers mois - Docker a suscité des opinions contradictoires selon lesquelles les environnements de cloud computing devraient abandonner les machines virtuelles (VM) et les remplacer par des conteneurs moins performants.

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

une. Les LXC sont limités à 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 basés sur Windows sont maintenant étendus à une instance de Windows si nous regardons les machines virtuelles. hyperviseurs vous n'êtes pas limité aux systèmes d'exploitation Linux ou Windows.

b. Les LXC ont des frais généraux faibles et ont de meilleures performances par rapport aux machines virtuelles. Outils à savoir. Docker, qui repose sur la technologie LXC, a fourni aux développeurs une plate-forme pour exécuter leurs applications tout en donnant aux opérateurs un outil leur permettant 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, amorçant et testant une application et une personne chargée des opérations déployant cette application de manière transparente, car c'est là que tout le frottement réside et que DevOps a pour but de briser ces silos.

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

Abandonner les machines virtuelles n'est pas pratique à partir de maintenant. Les machines virtuelles et les LXC ont donc leur propre existence et leur propre importance.


117
2017-08-26 07:46



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

Docker est juste une façon élégante d'exécuter un processus, pas une machine virtuelle.

Maintenant, laissez-moi vous expliquer un peu plus sur ce que cela signifie. Les machines virtuelles sont leur propre bête. J'ai envie d'expliquer ce que Docker Cela vous aidera à comprendre cela plus 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 ils disent "machine virtuelle". Alors...

Un conteneur Docker est juste un processus (et ses enfants) qui est compartimenté en utilisant 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 cours d'exécution ps aux sur l'hôte. Par exemple, commencer apache2 "dans un conteneur" ne fait que commencer apache2 comme un processus spécial sur l'hôte. Il vient d'être compartimenté 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 conteneur. Lorsque votre processus meurt, votre conteneur meurt. C'est parce que Docker remplace pid 1 à l'intérieur de votre conteneur avec votre application (pid 1 est normalement le système init). Ce dernier point à propos de pid 1 c'est tres important.

En ce qui concerne le système de fichiers utilisé par chacun de ces processus conteneurs, Docker utilise UnionFS-backed images, qui est ce que vous téléchargez lorsque vous faites 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 Dockerfile lors de la construction d'un conteneur Docker, vous créez simplement une couche au-dessus du dernier calque qui indique "ce fichier a été supprimé". Incidemment, 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 l'actuel. Les calques eux-mêmes sont juste des archives de fichiers. Vous pouvez tester cela avec docker save --output /tmp/ubuntu.tar ubuntuet alors cd /tmp && tar xvf ubuntu.tar. Ensuite, vous pouvez jeter un coup d'oeil autour. Tous les répertoires qui ressemblent à des hachages longs sont en réalité les calques individuels. Chacun contient des fichiers (layer.tar) et les 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 calque "au-dessus" de son état d'origine. Lors de la lecture des données "en cours", le système de fichiers lit les données comme s'il ne regardait que les couches de modifications les plus importantes. C'est pourquoi le fichier semble être supprimé, même s'il existe encore dans les calques "précédents", car le système de fichiers ne regarde que les couches supérieures. Cela permet à des conteneurs complètement différents de partager leurs couches de système de fichiers, même si certains changements importants ont pu arriver au système de fichiers sur les couches supérieures de chaque conteneur. Cela peut vous faire économiser une tonne d'espace disque lorsque vos conteneurs partagent leurs couches d'images de base. Cependant, lorsque vous montez des répertoires et des fichiers du système hôte dans votre conteneur au moyen de volumes, ces volumes "contournent" l'UnionFS, les modifications ne sont donc pas stockées dans des couches.

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

Docker se déplace très vite. Ses 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 par rapport à tout ce que vous lisez en ligne, y compris Stack Overflow. Si vous avez des questions spécifiques, je recommande fortement de rejoindre #docker sur Freenode IRC et demander là (vous pouvez même utiliser Freenode discussion en ligne pour ça!).


89
2018-04-04 02:35



Docker encapsule une application avec toutes ses dépendances, un virtualiseur encapsule un O.S. qui peut exécuter toutes les applications qu'il peut normalement exécuter sur une machine de métal nu.


57
2017-08-27 18:25