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

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

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

il pourrait être utile de comprendre comment la virtualisation et les conteneurs fonctionnent à bas niveau. Qui va éclaircir beaucoup de choses.

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

Comment la virtualisation fonctionne à un niveau bas?

dans ce cas VM manager prend en charge le ring 0 CPU (ou le "mode root" dans les CPU plus récents) et intercepte tous les appels privilégiés effectués par OS invité pour créer l'illusion que 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 parce qu'il n'y avait aucun moyen de faire ce genre d'interception. Les gens de VMWare étaient les premiers qui ont eu une idée de réécrire les octets exécutables en mémoire pour les appels privilégiés de guest OS pour réaliser ceci.

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

Comment conteneurs fonctionne à un niveau bas?

autour de 2006 , les gens, y compris certains des employés de Google mis en œuvre nouvelle fonctionnalité au niveau du noyau appelé espaces de noms (cependant l'idée long avant existait sous FreeBSD ). Une fonction de L'OS est de permettre le partage des ressources globales comme le réseau et le disque aux processus. Et si ces ressources globales étaient enveloppées dans des espaces de noms de sorte qu'elles ne soient visibles que par les processus qui fonctionnent dans le même espace de noms? Par exemple, vous pouvez obtenir un morceau de disque et le mettre dans namespace X et puis les processus tournant dans namespace Y ne peuvent pas le voir ou y accéder. Pareillement, les processus dans namespace X ne peuvent pas accéder à quoi que ce soit en mémoire qui est alloué à namespace Y. bien sûr, les processus dans X ne peuvent pas voir ou parler aux processus dans namespace Y. Cela fournit une sorte de virtualisation et d'isolement pour les ressources globales. C'est ainsi que docker fonctionne: chaque conteneur tourne dans son propre espace de noms mais utilise exactement le même noyau que tous les autres conteneurs. L'isolation se produit parce que le noyau connaît l'espace de noms qui a été assigné au processus et pendant L'API appelle il s'assure que le processus ne peut accéder aux ressources que dans son propre espace de noms.

les limites des conteneurs vs VM devraient être évidentes maintenant: vous ne pouvez pas exécuter complètement différents OS dans les conteneurs comme dans VMs. Cependant vous peut exécuter différentes distributions de Linux, car ils partagent le même noyau. Le niveau d'isolement n'est pas aussi fort qu'en 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. Aussi, vous pouvez voyez que lorsque vous chargez un nouveau conteneur, la nouvelle copie entière de OS ne démarre pas comme dans VM. Tous les conteneurs partagent le même noyau . C'est pourquoi les conteneurs sont de poids léger. De plus, contrairement à VM, vous n'avez pas à pré-allouer une partie significative de la mémoire aux conteneurs parce que nous n'exécutons pas de nouvelle copie de OS. Cela permet de faire fonctionner des milliers de conteneurs sur un seul OS tout en les sabotant, ce qui pourrait ne pas être possible si nous exécutions une copie séparée de L'OS dans sa propre VM.

j'aime la réponse de Ken Cochrane.

mais je tiens à 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 à VMs, Docker n'est pas (seulement) une question de partage optimal des ressources du matériel, il fournit en outre un "système" pour l'application d'empaquetage (préférable, mais pas indispensable, comme un ensemble de microservices).

pour moi, il tient dans l'écart entre les outils orientés développeur comme rpm, Debian packages, Maven , npm + Git d'un côté et les outils ops comme Puppet , VMware, Xen, you name it...

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

votre question suppose un environnement de production cohérent. mais comment le garder - elle cohérente? Considérez une certaine quantité (>10) de serveurs et d'applications, des étapes dans le pipeline.

pour garder cela synchronisé, vous commencerez à utiliser quelque chose comme Puppet, Chef ou vos propres scripts d'approvisionnement, règles non publiées et/ou beaucoup de documentation... En théorie, les serveurs peuvent s'exécuter indéfiniment, et se maintenir cohérente et à jour. La pratique ne permet pas de gérer complètement la configuration d'un serveur, de sorte qu'il y a beaucoup de place pour dérive de la configuration, et changements inattendus sur les serveurs en cours d'exécution.

donc il y a un motif 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 limites des VMs qui ont été utilisés avant Docker. Faire face à plusieurs gigaoctets de grandes images, déplacer ces grandes images autour, juste pour changer certains domaines 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 en gigaoctets sur les "petits changements" (merci aufs et Registry) et vous n'avez pas besoin de vous soucier de perdre des performances en empaquetant des applications dans un conteneur Docker à l'exécution. Vous n'avez pas à vous soucier des versions de cette image.

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

et bien sûr, vous pouvez démarrer Docker conteneurs dans VMs (c'est une bonne idée). Réduisez l'approvisionnement de votre serveur au niveau de la VM. Tout ce qui précède pourrait être géré par Docker.

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 mettent en œuvre la virtualisation basée sur les conteneurs ou la virtualisation au niveau du système d'exploitation. Pour cela, Docker utilisait initialement le pilote LXC, puis s'est déplacé vers libcontainer qui est maintenant renommé runc. Docker se concentre principalement sur l'automatisation du déploiement des applications à l'intérieur des conteneurs d'application. Les conteneurs d'Application sont conçus pour emballer et faire fonctionner un service unique, tandis que les conteneurs système sont conçus pour exécuter plusieurs processus, comme des machines virtuelles. Docker est donc considéré comme un outil de gestion des conteneurs ou de déploiement d'applications sur les systèmes conteneurisés.

pour savoir en quoi elle se distingue des autres virtualisations, passons à travers 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é une méthode de diviser logiquement les ordinateurs centraux pour permettre aux applications multiples de fonctionner 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 d'être exécutés simultanément sur un seul système x86 basé.

hyperviseur

les poignées de l'hyperviseur créer l'environnement virtuel sur lequel fonctionnent les machines virtuelles invitées. Il supervise le système des 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é plus loin l'utilisation de la virtualisation en permettant la création de plusieurs serveurs virtuels sur un seul serveur physique avec l'aide d'hyperviseurs, tels que Xen, VMware Player, KVM, etc. et intégration de matériel de soutien des produits de base de processeurs, tels que Intel VT et AMD-V.

Types de virtualisation

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

• émulation
• paravirtualisation
• virtualisation basée sur les conteneurs

émulation

Émulation

, aussi connu sous le nom d'exécution de virtualisation complète le noyau de la machine virtuelle OS entièrement en logiciel. 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 chargé de traduire le code du noyau OS invité en instructions de logiciel. La traduction se fait entièrement en logiciel et ne nécessite aucune intervention matérielle. L'émulation permet d'exécuter n'importe quel système d'exploitation non modifié qui supporte l'environnement émulé. L'inconvénient de ce type de virtualisation est une charge supplémentaire de ressources système qui entraîne une diminution de la performance par rapport à d'autres types de virtualisations.

exemples dans cette catégorie: VMware Player, VirtualBox, QEMU, Bochs, Parallels, etc.

paravirtualisation

Paravirtualization, également connu sous le nom de type 1 hyperviseur, fonctionne directement sur le hardware, ou" bare-metal", et fournit des services de virtualisation directement aux machines virtuelles tournant sur elle. 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, eux-mêmes, des ressources importantes.

exemples dans cette catégorie: Xen, KVM, etc.

virtualisation basée sur les conteneurs

la virtualisation basée sur le conteneur, aussi connue sous le nom de 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 a la meilleure performance possible et la densité et les caractéristiques de 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 tracé groupe de processus.

le concept de 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 d'accès à chaque appel système. Il est accessible par l'appel de système clone () qui permet de créer des instances séparées de précédemment-global les espaces de noms.

Les espaces de noms

peuvent être utilisés de différentes façons, 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 qui tournent à l'intérieur du conteneur semblent fonctionner 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 que pour d'autres types d'objets. Par exemple, lors de l'utilisation d'espaces de noms, l'utilisateur root container n'est pas traité comme root à l'extérieur du container, ajoutant une sécurité supplémentaire.

le sous-système Linux Control Groups (cgroups), prochain composant majeur pour la virtualisation basée sur les conteneurs, est utilisé pour grouper les processus et gérer leur consommation de ressources agrégées. Il est couramment utilisé pour limiter la mémoire et la consommation CPU des conteneurs. Comme un système Linux containerized n'a qu'un seul noyau et que le noyau a une visibilité complète dans les conteneurs, il n'y en a qu'un seul niveau d'affectation des ressources et établissement du calendrier.

plusieurs outils de gestion sont disponibles pour les conteneurs Linux, y compris 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, afin de conteneurs peuvent être créés en moins d'une seconde. Cette caractéristique rend virtualisation basée sur le conteneur unique et souhaitable que les autres approches de virtualisation.

étant donné que la virtualisation basée sur les conteneurs ajoute peu ou pas de frais généraux à la machine hôte, la virtualisation basée sur les conteneurs a des performances quasi-natives

pour la virtualisation basée sur le conteneur, aucun logiciel supplémentaire n'est requis, contrairement aux autres virtualisations.

tous les conteneurs sur une machine hôte partagent l'ordonnanceur de la machine hôte épargne besoin de ressources supplémentaires.

Les États de conteneur

(images Docker ou LXC) sont de petite taille par rapport aux images de machines virtuelles, de sorte que les images de conteneur sont faciles à distribuer.

la gestion des ressources dans les conteneurs est assurée par l'entremise de groupes consultatifs. Les Cgroups ne permettent pas aux conteneurs de 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. Ceci 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 similaires.

mise à jour:

comment Docker exécute-t-il les conteneurs dans les systèmes autres que 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 fonctionnent les conteneurs. Les deux Docker pour Mac et Windows utiliser Linux VMs pour exécuter les conteneurs. Docker Toolbox utilisé pour exécuter des conteneurs dans des boîtes virtuelles VMs. Mais, le dernier Docker utilise Hyper-V dans Windows et Hypervisor.cadre dans Mac.

maintenant, permettez-moi de décrire comment Docker for Mac fonctionne conteneurs en détail.

Docker pour Mac utilise https://github.com/moby/hyperkit pour émuler les capacités de l'hyperviseur et L'Hyperkit utilise l'hyperviseur.cadre de son noyau. L'hyperviseur.cadre de Mac solution d'hyperviseur native. Hyperkit utilise également VPNKit et DataKit respectivement pour namespace network et filesystem.

la VM Linux que Docker exécute sur Mac est en lecture seule. Cependant, vous pouvez l'enfoncer 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 VM:

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

tous les conteneurs circulent à l'intérieur de cette VM.

Il y a certaines limites à l'hyperviseur.Framework. À cause de ce Docker n'expose pas docker0 interface réseau dans Mac. Donc, vous ne pouvez pas accéder aux conteneurs de l'hôte. A partir de Maintenant, docker0 n'est disponible qu'à l'intérieur de la VM.

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

a travers ce post nous allons tracer quelques lignes de différences entre VMs et LXCs. Nous allons tout d'abord définir.

VM :

une machine virtuelle émule un environnement informatique physique, mais les requêtes pour CPU, Mémoire, disque dur, réseau et 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 VM est appelée Guest tandis que l'environnement sur lequel elle tourne est appelé host.

LXC s:

les conteneurs Linux (LXC) sont des capacités au niveau du système d'exploitation qui permettent d'exécuter plusieurs conteneurs Linux isolés, sur un seul hôte de contrôle (l'hôte LXC). Les conteneurs Linux servent d'alternative légère aux VM puisqu'ils n'ont pas besoin de l'hyperviseur viz. Virtualbox, KVM, Xen,etc.

Now sauf si vous avez été drogué par Alan (Zach Galifianakis-de la série Hangover) et avez été à Vegas pour l'année dernière, vous serez assez au courant de l'énorme poussée d'intérêt pour la technologie des conteneurs Linux, et si je vais être spécifique un projet de conteneur qui a créé un buzz dans le monde entier ces derniers mois est – Docker conduisant à certaines opinions faisant écho que les environnements de cloud computing devrait abandonner les machines virtuelles (VMs) et les remplacer par des conteneurs en raison de leur plus faible frais généraux et potentiellement meilleures performances.

Mais la grande question est, est-ce faisable? qu'il est raisonnable?

A. LXCs sont scopés à une instance de Linux. Il peut s'agir de différentes saveurs de Linux (par exemple un conteneur Ubuntu sur un serveur CentOS, mais C'est encore Linux.) De la même manière, les conteneurs Windows sont scopés vers une instance de Windows maintenant si nous regardons VMs ils ont une portée plus large et en utilisant les hyperviseurs vous n'êtes pas limité à l'exploitation les systèmes Linux ou Windows.

B. Les LXC ont de faibles frais généraux et ont de meilleures performances que les Vm. Tools viz. Docker qui sont construits sur les épaules de la technologie LXC ont fourni aux développeurs une plate-forme pour exécuter leurs applications et en même temps ont habilité les gens des opérations avec un outil qui leur permettra de déployer le même conteneur sur les serveurs de production ou les centres de données. Il essaie de faire l'expérience entre un développeur qui exécute une application, démarrer et tester une application et un opérateur déployant cette application sans problème, car c'est là que réside toute la friction et le but du DevOps est de briser ces silos.

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

abandonner VMs n'est pas pratique pour le moment. Donc à la fois VMs et LXCs ont leur propre existence et importance.

la plupart des réponses ici parlent de machines virtuelles. Je vais vous donner une réponse d'une seule ligne à 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 pour exécuter un processus, pas une machine virtuelle.

maintenant, permettez-moi d'expliquer un peu plus sur ce que cela signifie. Les machines virtuelles sont leur propre bête. Je me sens comme expliquer ce qu' Docker is 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 ils disent "machine virtuelle". Si...

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 à partir du reste des processus. Vous pouvez voir votre menu fixe processus conteneur en exécutant 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é 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é. Lors de 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 sur 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 UnionFS - images sauvegardées, ce qui est ce que vous téléchargez lorsque vous faites un docker pull ubuntu . Chaque "image" n'est qu'une série de couches et de métadonnées connexes. Le concept de stratification est très important ici. Chaque couche est juste un changement de la couche sous-jacente. Pour par exemple, lorsque vous supprimez un fichier dans votre fichier Dockerfile pendant que vous construisez un conteneur Docker, vous créez en fait juste une couche au-dessus de la dernière couche 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 prend toujours la même quantité d'espace disque. Le fichier est toujours là, dans les couches sous la couche courante. Les couches elles-mêmes ne sont que des amas de fichiers. Vous pouvez le tester avec docker save --output /tmp/ubuntu.tar ubuntu et puis cd /tmp && tar xvf ubuntu.tar . Ensuite, vous pouvez prendre un coup d'oeil autour. Tous les répertoires qui ressemblent à des hachures longues sont en fait des couches individuelles. Chacune contient des fichiers ( layer.tar ) et des métadonnées ( json ) contenant des informations sur cette couche particulière. Ces couches décrivent simplement des modifications au système de fichiers qui sont sauvegardées comme une couche "au-dessus de" son état d'origine. En lisant les données" courantes", le système de fichiers lit les données comme s'il ne regardait que les couches supérieures des changements. C'est pourquoi le fichier semble être supprimé, même s'il existe encore dans les couches "précédentes", parce que le système de fichiers ne regarde que les couches supérieures. Cela permet à des conteneurs complètement différents de partager leurs couches du système de fichiers, même si des changements significatifs peuvent être survenus au système de fichiers sur la plupart des couches de chaque conteneur. Cela peut vous sauver 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 à partir du système hôte dans votre conteneur par le biais de volumes, ces volumes "contourner" L'UnionFS, donc les changements ne sont pas stockés en 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 puissent communiquer" entre eux". 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 réseau de votre hôte pour que votre conteneur y accède directement.

Docker se déplace 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 vérifier la documentation disponible pour plus d'informations, et de faire confiance à la documentation sur tout ce que vous lisez en ligne, y compris le débordement de pile. Si vous avez des questions spécifiques, je nous vous recommandons fortement de rejoindre #docker sur Freenode IRC et de demander là-bas (vous pouvez même utiliser le webchat de Freenode pour cela!).

Docker encapsule une application avec toutes ses dépendances.

un virtualizer encapsule un système D'exploitation qui peut exécuter toutes les applications qu'il peut normalement exécuter sur une machine en métal nu.

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

Docker et LXC est plus destiné au bac à sable, la conteneurisation, et l'isolation des ressources. Il utilise L'API clone du système d'exploitation hôte (actuellement seulement pour le noyau Linux) qui fournit l'espace de noms pour IPC, NS (mount), network, PID, UTS, etc.

Ce que sur la mémoire, I/O, CPU, etc.? C'est contrôlé en utilisant des cgroups où vous pouvez créer des groupes avec certaines ressources (CPU, mémoire, etc.) spécification / restriction et mettez vos processus là-dedans. En plus de LXC, Docker fournit un support de stockage ( http://www.projectatomic.io/docs/filesystems / ) par exemple, union mount filesystem où vous pouvez ajouter des couches et partager des couches entre différents espaces de noms de montage.

c'est une caractéristique 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 écrira quelque chose à lire-partition d'écriture (A. K. A. copy on write). Il fournit également de nombreux autres enveloppements tels que le registre et la version des images.

avec LXC normal, vous devez venir avec quelques rootfs ou partager les rootfs et lorsqu'ils sont partagés, et les changements se répercutent sur d'autres conteneurs. En raison de beaucoup de ces caractéristiques ajoutées, Docker est plus populaire que LXC. LXC is populaire dans les environnements embarqués pour mettre en œuvre la sécurité autour des processus exposés à des entités externes telles que le réseau et L'interface utilisateur. Docker est populaire dans les environnements de multi-location cloud où un environnement de production cohérent est attendu.

une VM normale (par exemple, VirtualBox et VMware) utilise un hyperviseur, et les technologies connexes ont soit un firmware dédié qui devient la première couche pour le premier OS (OS hôte, ou OS invité 0) ou un logiciel qui tourne sur L'OS hôte à fournir l'émulation matérielle comme CPU, USB / accessoires, mémoire, réseau, etc., pour les Systèmes d'exploitation invités. Les mv sont encore (à partir de 2015) populaires dans l'environnement multi-locataires 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 aussi OK tant que vous avez un nouveau noyau) vs. les Vm normales ont besoin d'au moins 2 Go de mémoire, etc., à faire quelque chose de significatif. Mais le support Docker sur l'OS hôte N'est pas disponible dans les systèmes D'exploitation tels que Windows (à partir de Nov. 2014) où les types de VMs peuvent être exécutés sous windows, Linux et Macs.

Voici une photo de docker / rightscale :

1. Léger

C'est probablement la première impression pour beaucoup d'apprenants dockers.

tout d'abord, les images docker sont généralement plus petites que les images VM, ce qui les rend faciles à construire, Copier, Partager.

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

2. Système De Fichiers En Couches

C'est une autre caractéristique clé de Docker. Les Images ont des couches, et différentes images peuvent partager des calques, le rendre encore plus économe en espace et plus rapide à construire.

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

3. Noyau OS partagé

pensez aux conteneurs comme des processus!

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

cela est bon pour la plupart des cas(aucun entretien supplémentaire du noyau OS) mais peut être un problème si des isolations strictes sont nécessaires entre les conteneurs.

Pourquoi est-ce important?

tout cela ressemble à des améliorations, pas à une révolution. Eh bien, l'accumulation quantitative conduit à qualitative transformation .

pensez au déploiement de l'application. Si nous voulons déployer un nouveau logiciel(service) ou en mettre un à niveau, 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 VM avec un service mis à jour, le tester(partager entre Dev & QA), le déploiement à la production prend des heures, voire des jours. Si quelque chose tourne mal, tu dois recommencer, en gaspillant encore plus de temps. Ainsi, utilisez l'outil de gestion de la configuration (puppet, saltstack, chef de cuisine etc.) pour installer un nouveau logiciel, de télécharger de nouveaux fichiers est préféré.

Quand il s'agit de docker, il est impossible d'utiliser un nouveau conteneur docker, pour remplacer l'ancien. Entretien 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. Cela s'appelle infrastructure immuable : ne pas maintenir (mettre à niveau) le logiciel, créer un nouveau à la place.

il transforme la façon dont les services sont fournis. Nous voulons des applications, mais nous devons maintenir VMs(ce qui est une douleur et qui n'a pas grand chose à voir avec nos applications). Docker vous fait vous concentrer sur les applications et lisse tout.

Docker, essentiellement des conteneurs, prend en charge virtualisation OS c'est-à-dire que votre application estime qu'elle a une instance complète D'un OS tandis que VM prend en charge virtualisation matériel . Vous avez l'impression que c'est une machine physique dans laquelle vous pouvez démarrer n'importe quel OS.

dans Docker, les conteneurs tournant partagent le noyau OS hôte, alors que dans VMs ils ont leurs propres fichiers OS. L'environnement (l'OS) dans lequel vous développez un l'application serait la même lorsque vous le déployez dans différents environnements de service, tels que "test" ou "production".

par exemple, si vous développez un serveur web qui tourne sur le port 4000, lorsque vous le déployez dans votre environnement" testing", 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 faites à L'OS seraient sauvegardées dans une ou plusieurs couches et ces couches feraient partie de l'image, donc partout où l'image va les dépendances soient bien présents.

dans l'exemple ci-dessous, la machine hôte a trois VM. Afin de fournir les applications dans le VMs isolation complète, ils ont chacun leurs propres copies de fichiers OS, bibliothèques et code d'application, avec une instance complète en mémoire D'un OS. Alors que la figure ci-dessous montre le même scénario avec les conteneurs. Ici, les conteneurs partagent simplement l'hôte d'exploitation système, y compris le noyau et les bibliothèques, de sorte qu'ils n'ont pas besoin de démarrer un OS, charger les bibliothèques ou payer un coût de mémoire privée pour ces fichiers. Le seul espace incrémental qu'ils prennent est n'importe quelle mémoire et l'espace disque nécessaire pour l'application de courir dans le conteneur. Alors que l'environnement de l'application ressemble à un OS dédié, l'application se déploie exactement comme elle le ferait sur un hôte dédié. L'application containerized commence en quelques secondes et beaucoup plus d'instances de l'application peuvent tenir sur le machine que dans le cas de VM.

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

en relation avec: -

" pourquoi déployer un logiciel sur une image docker est-il plus facile que simplement 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 un minimum de trois des suivants:

1. développeur PC(s)
2. Partagé environnement de développement
3. appareil D'essai individuel PC (s)
4. environnement d'essai partagé
"151990920 de l'assurance qualité de l'environnement
5. UAT environment
6. essai de charge / performance
"151990920 Vivre" mise en scène", 1519100920"
7. Production
8. Archive

il y a aussi les facteurs suivants à considérer:

• les développeurs, et même les testeurs, auront tous soit subtlely ou très différentes configurations de PC, de par la nature de la tâche
• les développeurs peuvent souvent développer sur des PC au-delà du contrôle des règles de standardisation de l'entreprise ou de l'entreprise (par exemple, les pigistes qui développent sur leurs propres machines (souvent à distance) ou les contributeurs à des projets open source qui ne sont pas "employés" ou "sous contrat" pour configurer leurs PC d'une certaine manière)
• certains environnements se composeront d'un nombre fixe de machines multiples dans un équilibrage de charge configuration
• de nombreux environnements de production auront des serveurs infonuagiques créés et détruits de façon dynamique (ou "élastique") en fonction des niveaux de trafic

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

Cela signifie que la création d'environnements compatibles en premier lieu est assez difficile juste en raison du volume (même dans un scénario de champ vert), mais les garder cohérent est tout sauf impossible étant donné le nombre élevé de serveurs, l'ajout de nouveaux serveurs (dynamiquement ou manuellement), mises à jour automatiques de O/S vendeurs, anti-virus vendeurs, navigateurs vendeurs et similaires, installation manuelle de logiciels ou des changements de configuration effectués par les développeurs ou techniciens de serveur, etc Laissez - moi répéter que-il est virtuellement (pas de jeu de mots destiné) impossible de maintenir des environnements cohérents (d'accord, pour le puriste, cela peut être fait, mais cela nécessite énormément de temps, d'effort et de discipline, ce qui est précisément la raison pour laquelle VMs et les conteneurs (par exemple Docker) ont été conçus en premier lieu).

alors pensez plutôt à votre question comme celle-ci " étant donné l'extrême difficulté de maintenir 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 invariablement " Oui " - mais il n'y a qu'un seul moyen de le savoir, postez cette nouvelle question sur Stack Overflow.

il existe trois configurations différentes qui fournissent une pile pour exécuter une application sur (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) serveur Traditionnel pile se composent d'un serveur physique qui exécute un système d'exploitation et votre application.

avantages:

• utilisation des ressources brutes

• l'Isolement

inconvénients:

• Très lent déploiement de temps
• cher
• ressources gaspillées
• Difficile à l'échelle
• difficile de migrer
• configuration complexe

2) La VM stack se 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 de 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 à échelle
• facile à sauvegarder et à migrer
• rentabilité
• flexibilité

inconvénients:

• L'affectation des ressources est problématique
• Vendeur de faire adopter la
• configuration Complexe

3) La configuration du conteneur , la clé la différence avec les autres stack est que la virtualisation basée sur le conteneur utilise le noyau de l'OS hôte pour gérer plusieurs instances guest isolées. Ces instances guest sont appelées containers. L'hôte peut être un serveur physique ou une machine virtuelle.

avantages:

• l'Isolement
• léger
• Ressource efficace
• facile à migrer
• Sécurité
• Faible surcharge
• Miroir de la production et de l'environnement de développement

inconvénients:

• Même Architecture
• Ressources lourd apps
• la mise en Réseau et les questions de sécurité.

en comparant la configuration du conteneur avec ses prédécesseurs, nous pouvons conclure que la conteneurisation est la plus rapide, la plus efficace et la plus sûre que nous connaissons à ce jour. Les conteneurs sont des instances isolées qui exécutent votre application. Docker faire tourner le conteneur d'une manière, les calques obtiennent la mémoire de temps de course avec les pilotes de stockage par défaut(pilotes de superposition) qui tournent en quelques secondes et la couche de copie-sur-écriture créé sur elle une fois que nous nous engageons dans le conteneur, qui alimente l'exécution des conteneurs. dans le cas de VM qui prendra autour d'un minute pour charger tout dans l'environnement virtualiser. 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 énorme dans les processus de CI/CD. Les avantages des conteneurs sont si convaincants qu'ils sont certainement là pour rester.

il y a beaucoup de 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 VMs 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 du système.

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

dans la virtualisation, les ressources sont allouées au début de la mise en place et donc les ressources ne sont pas pleinement utilisées lorsque la machine virtuelle est inactive pendant de nombreuses périodes. Dans Docker, les conteneurs ne sont pas alloués avec une quantité fixe de ressources matérielles et est libre d'utiliser les ressources en fonction des besoins et il est donc très évolutif.

Docker utilise UNION de système de Fichiers .. Docker utilise un technologie de copie-sur-écriture pour réduire l'espace mémoire consommé par les conteneurs. lire la suite ici

Avec un machine virtuelle , nous disposons d'un serveur, nous avons un système d'exploitation hôte sur le serveur, et puis nous avons un hyperviseur. Et puis, en plus de 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 ensemble de système d'exploitation invité. C'est assez lourd. Il y a aussi une limite à ce que vous pouvez réellement mettre sur chaque machine physique.

conteneurs Docker , d'autre part, sont légèrement différents. Nous avons le serveur. Nous avons le système d'exploitation hôte. Mais au lieu d'un hyperviseur , nous avons le Support moteur , dans ce cas. Dans ce cas, nous n'apportons pas tout un système d'exploitation invité avec nous. nous apportons une couche très mince du système d'exploitation , et le conteneur peut parler dans l'OS hôte afin d'obtenir le noyau de fonctionnalités. Et qui nous permet d'avoir un très léger conteneur.

il N'y a que le code d'application et les binaires et bibliothèques dont il a besoin. Et ces binaires et bibliothèques peuvent en fait être partagés à travers différents conteneurs si vous voulez qu'ils soient aussi bien. Et ce que cela nous permet de faire, c'est un certain nombre de choses. Ils ont beaucoup plus rapide temps de démarrage . On ne peut pas monter une seule VM en quelques secondes comme ça. Et aussi, les faire tomber aussi vite.. donc nous pouvons monter et descendre très rapidement et nous verrons cela plus tard.

chaque conteneur pense qu'il tourne sur sa propre copie du système d'exploitation. Il a son propre système de fichiers, propre registre, etc. qui est une sorte de mensonge. C'est effectivement en cours d' virtualiser.

j'ai beaucoup utilisé Docker dans les environnements de production et de mise en scène. Lorsque vous vous y habituerez, vous le trouverez très puissant pour construire un conteneur multi et des 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 Dockers

sont des environnements isolés. Vous pouvez le voir lorsque vous lancez la commande top dans un conteneur Docker qui a été créé à partir d'une image Docker.

en outre, 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 fichier DockerFile et le dire par exemple quand il est en cours d'exécution puis wget 'this', apt-get 'that', run 'some shell script', setting environment variables et ainsi de suite.

dans les projets de micro-services et D'architecture Docker est un très un atout viable. Vous pouvez atteindre l'extensibilité, la résilience et l'élasticité avec Docker, Docker essaim, Kubernetes et Docker composer.

une autre question importante concernant Docker est Docker Hub et sa communauté. Par exemple, j'ai mis en place un écosystème pour surveiller kafka en utilisant Prometheus, Grafana, Prometheus-JMX-Exporter, et Dokcer.

pour avoir fait ça, j'ai téléchargé des conteneurs Docker configurés pour zookeeper, kafka, Prometheus, Grafana et JMX-collector puis j'ai monté ma propre configuration pour certains d'entre eux en utilisant des fichiers yml ou pour d'autres j'ai changé certains fichiers et la configuration dans le conteneur Docker et je construis un système complet pour surveiller kafka en utilisant des Dockers multi-conteneurs sur une seule machine avec isolation et évolutivité et la résilience que cette architecture peut être facilement déplacé dans plusieurs serveurs.

en plus du site Docker Hub, il y a un autre site appelé quay.io que vous pouvez utiliser pour avoir vos propres images Docker tableau de bord il y et tirer/pousser/. Vous pouvez même importer des images Docker de Docker Hub à quay puis les exécuter à partir de quay sur votre propre machine.

Note: apprendre Docker en premier lieu semble complexe et difficile, mais quand vous vous habituez à elle, alors vous ne pouvez pas travailler sans elle.

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

Voici comment Docker se présente:

Docker est la société qui conduit le mouvement des conteneurs et le seul fournisseur de plate-forme de conteneurs pour traiter chaque application à travers le le cloud hybride. Les entreprises d'aujourd'hui sont sous pression pour transformer mais sont limités par les applications existantes et infrastructure tout en rationalisant un portefeuille de plus en plus diversifié des nuages, des centres de données et des applications architecture. Docker active une véritable indépendance entre les applications et l'infrastructure et les développeurs et les opérations informatiques pour libérer leur potentiel et créer un modèle pour une meilleure collaboration et innovation.

So Docker est basé sur le conteneur, ce qui signifie que vous avez des images et des conteneurs qui peuvent être exécutés sur votre machine actuelle. Il ne comprend pas le système d'exploitation comme VM s, mais comme un paquet de travail différent des packs comme Java, Tomcat,etc.

si vous comprenez conteneurs, vous obtenez ce Qu'est Docker et comment il est différent de VM S...

Alors, qu'est ce qu'un conteneur?

une image de conteneur est un léger, autonome, paquet exécutable de un logiciel qui inclut tout ce dont vous avez besoin pour l'exécuter: code, exécution, Outils Système, bibliothèques système, Paramètres. Disponible pour les deux Linux et Windows apps, conteneurs logiciel fonctionnera toujours la même, quel que soit l'environnement. Conteneurs isoler logiciel de son environnement, par exemple les différences entre le développement et environnements de mise en scène et aider à réduire les conflits entre les équipes de course logiciel différent sur la même infrastructure.

comme vous le voyez dans l'image ci-dessous, chaque conteneur dispose d'un pack séparé et fonctionne sur une seule machine partagent le système d'exploitation de cette machine... Ils sont sûrs et faciles à expédier...

Il ya beaucoup de belles réponses techniques ici qui traitent clairement les différences entre VMs et conteneurs ainsi que les origines de Docker.

pour moi, la différence fondamentale entre VMs et Docker est la façon dont vous gérez la promotion de votre application.

avec VMs vous faites la promotion de votre application et de ses dépendances d'une VM au prochain DEV à UAT à PRD.

1. souvent ces VM auront différents correctifs et des bibliothèques.
2. il n'est pas rare que plusieurs applications partagent une VM. Cela nécessite la gestion de la configuration et des dépendances pour toutes les applications.
3. Sauvegarde requiert l'annulation des modifications dans la machine virtuelle. Ou le restaurer si possible.

avec Docker l'idée est que vous empaquetez votre application à l'intérieur de son propre conteneur avec les bibliothèques dont il a besoin et ensuite promouvoir le entier conteneur comme une seule unité.

1. sauf pour le 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 qui simplifie la configuration.
3. Sauvegarde se compose de l'arrêt et la suppression du conteneur.

ainsi au niveau le plus fondamental avec VMs vous promouvoir l'application et ses dépendances en tant que discret alors qu'avec Docker vous faites la promotion de tout en un coup.

et oui il ya des problèmes avec les conteneurs, y compris leur gestion, bien que des outils comme Kubernetes ou Docker essaim simplifier considérablement la tâche.

Source: Kubernetes dans l'Action.