Qu'est-ce que Docker ajoute aux outils lxc (les outils LXC de l'espace utilisateur)?

398

Si vous regardez les fonctionnalités de Docker, la plupart d'entre elles sont déjà fournies par LXC.

Alors, qu'est-ce que Docker ajoute? Pourquoi devrais-je utiliser Docker sur du LXC ordinaire?

docker lxc Flimm
la source

Réponses:

550

De la FAQ Docker :

Docker ne remplace pas lxc. "lxc" fait référence aux capacités du noyau Linux (en particulier les espaces de noms et les groupes de contrôle) qui permettent aux processus de sandboxing les uns des autres et de contrôler leurs allocations de ressources.

En plus de cette base de bas niveau des fonctionnalités du noyau, Docker propose un outil de haut niveau avec plusieurs fonctionnalités puissantes:

  • Déploiement portable sur plusieurs machines.Docker définit un format pour regrouper une application et toutes ses dépendances en un seul objet qui peut être transféré vers n'importe quelle machine compatible Docker et exécuté là-bas avec la garantie que l'environnement d'exécution exposé à l'application sera le même. Lxc implémente le sandboxing de processus, qui est une condition préalable importante pour un déploiement portable, mais cela ne suffit pas à lui seul pour un déploiement portable. Si vous m'envoyiez une copie de votre application installée dans une configuration lxc personnalisée, elle ne fonctionnerait certainement pas sur ma machine comme elle le fait sur la vôtre, car elle est liée à la configuration spécifique de votre machine: mise en réseau, stockage, journalisation, distribution, etc. Docker définit une abstraction pour ces paramètres spécifiques à la machine, afin que le même conteneur de docker puisse s'exécuter - inchangé - sur de nombreuses machines différentes,

  • Centré sur l'application. Docker est optimisé pour le déploiement d' applications , par opposition aux machines. Cela se reflète dans son API, son interface utilisateur, sa philosophie de conception et sa documentation. En revanche, les scripts d'assistance lxc se concentrent sur les conteneurs en tant que machines légères - essentiellement des serveurs qui démarrent plus rapidement et nécessitent moins de RAM. Nous pensons que les conteneurs ne se limitent pas à cela.

  • Construction automatique . Docker comprend un outil permettant aux développeurs d'assembler automatiquement un conteneur à partir de leur code source, avec un contrôle total sur les dépendances des applications, les outils de construction, le conditionnement, etc. Ils sont libres d'utiliser make, maven, chef, puppet, salt, debian packages, rpms, source tarballs, ou toute combinaison des éléments ci-dessus, quelle que soit la configuration des machines .

  • Versioning. Docker inclut des fonctionnalités de type git pour suivre les versions successives d'un conteneur, inspecter les différences entre les versions, valider de nouvelles versions, restaurer, etc. L'historique comprend également la façon dont un conteneur a été assemblé et par qui, de sorte que vous bénéficiez d'une traçabilité complète à partir du serveur de production tout le chemin du développeur en amont. Docker implémente également des téléchargements et téléchargements incrémentiels, similaires à "git pull", de sorte que les nouvelles versions d'un conteneur peuvent être transférées en envoyant uniquement des différences.

  • Réutilisation des composants. Tout conteneur peut être utilisé comme une "image de base" pour créer des composants plus spécialisés. Cela peut être fait manuellement ou dans le cadre d'une construction automatisée. Par exemple, vous pouvez préparer l'environnement python idéal et l'utiliser comme base pour 10 applications différentes. Votre configuration postgresql idéale peut être réutilisée pour tous vos futurs projets. Etc.

  • Partage. Docker a accès à un registre public ( https://registry.hub.docker.com/ ) où des milliers de personnes ont téléchargé des conteneurs utiles: tout, de redis, couchdb, postgres aux videurs irc aux rails des serveurs d'applications sur rails pour hadoop pour baser des images pour diverses distributions. Le registre comprend également une "bibliothèque standard" officielle de conteneurs utiles maintenue par l'équipe des dockers. Le registre lui-même est open-source, donc tout le monde peut déployer son propre registre pour stocker et transférer des conteneurs privés, pour les déploiements de serveurs internes par exemple.

  • Écosystème d'outils. Docker définit une API pour automatiser et personnaliser la création et le déploiement de conteneurs. Il existe un grand nombre d'outils intégrant avec docker pour étendre ses capacités. Déploiement de type PaaS (Dokku, Deis, Flynn), orchestration multi-nœuds (maestro, salt, mesos, openstack nova), tableaux de bord de gestion (docker-ui, openstack horizon, chantier naval), gestion de la configuration (chef, marionnette), intégration continue (jenkins, strider, travis), etc. Docker s'impose rapidement comme la norme pour l'outillage à base de conteneurs.

J'espère que ça aide!

Solomon Hykes
la source
3
Lorsque vous dites "n'importe quel conteneur peut être utilisé comme image de base", je suppose que vous voulez dire un conteneur Docker, pas un conteneur LXC créé indépendamment de Docker. Pour autant que je sache, on ne peut pas créer un conteneur Docker à partir de zéro, il doit toujours hériter d'un autre conteneur Docker (question connexe: stackoverflow.com/questions/18274088/… ).
Flimm
18
Vous pouvez facilement créer un nouveau conteneur à partir de n'importe quelle archive tar avec "importation Docker". Par exemple: "debootstrap raring ./rootfs; tar -C ./rootfs -c. | Docker import flimm / mybase".
Solomon Hykes
3
est-ce toujours vrai maintenant que Docker a libcontainer (que ce n'est pas un remplacement)?
Garet Claborn
3
@GaretClaborn oui, puisque libcontainer est juste leur propre bibliothèque pour accéder aux espaces de noms et aux groupes de contrôle, tout ce que Solomon a dit s'applique toujours.
John Morales
10
Un conteneur Linux est le résultat de la contrainte et de l'isolement d'un processus à l'aide d'un ensemble d'installations Linux: chroot, cgroups et namespaces. LXC est un outil de l'espace utilisateur qui manipule ces installations. libcontainer est une alternative à LXC qui manipule ces mêmes fonctionnalités. Docker utilise libcontainer par défaut mais peut utiliser LXC à la place. Cela dit, Docker est (bien) plus qu'une couche de compatibilité au-dessus de libcontainer / LXC; il ajoute des fonctionnalités supplémentaires que les autres réponses ont répertoriées.
user100464
71

Jetons un coup d'œil à la liste des fonctionnalités techniques de Docker et vérifions celles qui sont fournies par LXC et celles qui ne le sont pas.

Fonctionnalités:

1) Isolement du système de fichiers : chaque conteneur de processus s'exécute dans un système de fichiers racine complètement séparé.

Fourni avec LXC ordinaire.

2) Isolement des ressources : les ressources système comme le processeur et la mémoire peuvent être allouées différemment à chaque conteneur de processus, à l'aide de cgroups.

Fourni avec LXC ordinaire.

3) Isolement du réseau : chaque conteneur de processus s'exécute dans son propre espace de noms réseau, avec une interface virtuelle et une adresse IP qui lui sont propres.

Fourni avec LXC ordinaire.

4) Copie sur écriture : les systèmes de fichiers racine sont créés à l'aide de la copie sur écriture, ce qui rend le déploiement extrêmement rapide, peu coûteux en mémoire et peu coûteux en disque.

Ceci est fourni par AUFS, un système de fichiers union dont Docker dépend. Vous pouvez configurer manuellement AUFS avec LXC, mais Docker l'utilise comme standard.

5) Journalisation : les flux standard (stdout / stderr / stdin) de chaque conteneur de processus sont collectés et journalisés pour une récupération en temps réel ou par lots.

Docker fournit cela.

6) Gestion des modifications: les modifications apportées au système de fichiers d'un conteneur peuvent être validées dans une nouvelle image et réutilisées pour créer plus de conteneurs. Aucune configuration de modèle ou manuelle requise.

"Templating ou configuration manuelle" est une référence à LXC, où vous devez en savoir plus sur ces deux choses. Docker vous permet de traiter les conteneurs de la manière dont vous êtes habitué à traiter les machines virtuelles, sans avoir à connaître la configuration de LXC.

7) Shell interactif : le docker peut allouer un pseudo-tty et l'attacher à l'entrée standard de n'importe quel conteneur, par exemple pour exécuter un shell interactif jetable.

LXC fournit déjà cela.

Je viens juste de commencer à apprendre sur LXC et Docker, donc je serais heureux de recevoir des corrections ou de meilleures réponses.

Flimm
la source
35
À mon humble avis, cette réponse manque le point. Docker ne «fournit» pas ces fonctionnalités; il les rend simplement faciles à utiliser. Si nous voulons être exigeants, nous pouvons dire que LXC ne fournit pas d'isolement: les espaces de noms le fournissent, et LXC n'est qu'un outil de base pour les rendre plus facile à utiliser qu'avec l' unshareoutil de base (ou directement le clone()syscall). De même, Docker rend ces choses plus faciles à utiliser (et apporte beaucoup plus de fonctionnalités sur la table, comme la possibilité de pousser / tirer des images). Mon 2c.
jpetazzo
6
@jpetazzo: LXC est en fait assez facile, comment Docker le rend-il plus facile (en plus d'ajouter d'autres fonctionnalités comme pousser et tirer des images)?
Flimm
31
@Flimm: J'aime la comparaison dans le numéro 16 du magazine Admin , p. 34: Docker regroupe LXC avec d'autres technologies de prise en charge et l'enveloppe dans une interface de ligne de commande facile à utiliser. L' utilisation des conteneurs est un peu comme essayer d'utiliser Git avec seulement des commandes comme update-indexet read-tree, sans outils familiers tels que add, commitet merge. Docker fournit cette couche de "porcelaine" sur la "plomberie" de LXC, vous permettant de travailler avec des concepts de niveau supérieur et de vous soucier moins des détails de bas niveau.
0xC0000022L
4
J'ai exécuté des tests de performances UnixBench dans un conteneur Docker et un conteneur LXC, exécutant le même système d'exploitation, et LXC a excellé dans le score. Étant docker basé sur LXC, je suis très perplexe quant à mes résultats.
gextra
7
Il me semble que le ralentissement des performances de Docker était lié aux E / S disque, donc peut-être causé par l'adoption d'AUFS.
gextra
16

Les articles et réponses ci-dessus deviennent rapidement obsolètes à mesure que le développement de LXD continue d'améliorer LXC . Oui, je sais que Docker n'est pas resté immobile non plus.

LXD implémente désormais un référentiel pour les images de conteneurs LXC à partir desquelles un utilisateur peut pousser / tirer pour contribuer ou réutiliser.

L'API REST de LXD vers LXC permet désormais la création / déploiement / gestion locale et à distance de conteneurs LXC à l'aide d'une syntaxe de commande très simple.

Les principales caractéristiques de LXD sont:

  • Sécurisé par conception (conteneurs non privilégiés, restrictions de ressources et bien plus encore)
  • Évolutif (des conteneurs sur votre ordinateur portable à des milliers de nœuds de calcul)
  • Intuitif (API simple et claire et expérience nette en ligne de commande)
  • Basé sur l'image (plus de modèles de distribution, seulement de bonnes images fiables) Migration en direct

Il existe maintenant un plugin NCLXD pour OpenStack permettant à OpenStack d'utiliser LXD pour déployer / gérer des conteneurs LXC en tant que VM dans OpenStack au lieu d'utiliser KVM, vmware etc.

Cependant, NCLXD permet également un cloud hybride d'un mélange de machines virtuelles HW traditionnelles et de machines virtuelles LXC.

Le plugin OpenStack nclxd une liste de fonctionnalités prises en charge comprend:

stop/start/reboot/terminate container
Attach/detach network interface
Create container snapshot
Rescue/unrescue instance container
Pause/unpause/suspend/resume container
OVS/bridge networking
instance migration
firewall support

Au moment de la sortie d'Ubuntu 16.04 en avril 2016, il y aura des fonctionnalités supplémentaires intéressantes telles que la prise en charge des périphériques de bloc, la prise en charge de la migration en direct .

bmullan
la source
4

Les dockers utilisent des images construites en couches. Cela ajoute beaucoup en termes de portabilité, de partage, de versioning et d'autres fonctionnalités. Ces images sont très faciles à porter ou à transférer et puisqu'elles sont en couches, les modifications dans les versions suivantes sont ajoutées sous forme de couches sur les couches précédentes. Ainsi, lors du portage plusieurs fois, vous n'avez pas besoin de porter les couches de base. Les dockers ont des conteneurs qui exécutent ces images avec un environnement d'exécution contenu, ils ajoutent des modifications en tant que nouvelles couches offrant un contrôle de version facile.

En dehors de cela, Docker Hub est un bon registre avec des milliers d'images publiques, où vous pouvez trouver des images sur lesquelles le système d'exploitation et d'autres logiciels sont installés. Ainsi, vous pouvez obtenir une assez bonne longueur d'avance pour votre application.

div
la source
Lorsque vous dites "couches intégrées" - qu'est-ce que cela signifie - (A) Une copie des couches de base, adaptée et engagée dans une "nouvelle" couche. Donc, la couche de base est déconnectée de la suivante? (B) La ou les couches de base sont incluses dans la "NOUVELLE" couche et également liées. Ainsi, les modifications apportées au calque de base se répercutent automatiquement sur le "NOUVEAU" calque. Désolé, si la clarification demandée est trop naïve. :( Kapil
Kapil
Les images Docker sont construites en couches. Pour mettre en termes granulaires tous les changements jusqu'à un point où un calque est validé sont présents dans les calques d'image réalisés jusqu'à ce point. Toutes les modifications apportées par la suite sont ajoutées aux couches suivantes et supérieures. Ainsi, une nouvelle couche est liée à la couche de base. Je ne pense pas que la même nouvelle couche puisse être ajoutée à une couche de base différente avec des modifications supplémentaires. Cependant, si plusieurs entités souhaitent conserver la cohérence et avoir les mêmes couches de base, seules les nouvelles couches doivent être attribuées à ces entités pour atteindre le même état.
div
Cependant, je ne suis pas mis à jour sur les développements actuels sur docker et il peut y avoir des changements dans l'implémentation de l'image docker qui ne sont pas couverts dans le commentaire ci-dessus.
div
Pour être plus précis, les calques sont identifiés par une signature (SHA-quelque chose, je crois) ce qui signifie que si vous changez un calque, c'est un calque différent. @Kapil: Cela signifie que bien que son comportement soit un peu plus proche de votre option (B), vous ne pouvez en fait pas modifier une couche de base. (ou n'importe quel calque, d'ailleurs) Une image est construite à partir d'une liste de calques, chacun appliqué dans l'ordre; les couches peuvent être nettoyées (et je pense qu'elles sont automatiquement nettoyées par le docker lui-même) lorsqu'elles ne sont plus nécessaires; c'est-à-dire lorsque toutes les images de référence ont été supprimées.
codermonkeyfuel
@Kapil: Honnêtement, votre question fonctionnerait probablement mieux en tant que nouvelle question, plutôt qu'en tant que commentaire sur celle-ci, car elle est utile pour que les gens puissent rechercher par eux-mêmes. Si vous voulez la poser comme une nouvelle question, j'y répondrai aussi.
codermonkeyfuel
0

Va garder ce plus vif, c'est déjà demandé et répondu ci-dessus .

Je prendrais du recul cependant et y répondrais légèrement différemment, le moteur docker lui-même ajoute l'orchestration comme l'un de ses extras et c'est la partie perturbatrice. Une fois que vous commencez à exécuter une application en tant que combinaison de conteneurs exécutés «quelque part» sur plusieurs moteurs de conteneur, cela devient vraiment excitant. Robustesse, mise à l'échelle horizontale, abstraction complète du matériel sous-jacent, je pourrais continuer encore et encore ...

Ce n'est pas seulement Docker qui vous donne cela, en fait la norme de facto Container Orchestration est Kubernetes qui se décline en beaucoup de saveurs, une Docker, mais aussi OpenShift, SuSe, Azure, AWS ...

Ensuite, sous K8S, il existe d'autres moteurs de conteneurs; les plus intéressants sont Docker et CRIO - récemment construits, sans démon, destinés à être un moteur de conteneur spécifiquement pour Kubernetes mais immatures. C'est la concurrence entre ceux-ci qui, je pense, sera le véritable choix à long terme pour un moteur de conteneur.

Will Rothwell
la source