Si vous examinez 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 un LXC ordinaire?
Depuis le Docker FAQ :
Docker ne remplace pas lxc. "lxc" fait référence aux fonctionnalités du noyau Linux (en particulier les espaces de noms et les groupes de contrôle) qui permettent aux processus en bac à sable de s'interconnecter et de contrôler leurs allocations de ressources.
En plus de cette base basique des fonctionnalités du noyau, Docker propose un outil de haut niveau avec plusieurs fonctionnalités puissantes:
Déploiement portable sur plusieurs ordinateurs. Docker définit un format pour regrouper une application et toutes ses dépendances dans un seul objet pouvant être transféré sur n'importe quel ordinateur compatible docker et y être exécuté avec la garantie que l'environnement d'exécution exposé l'application sera la même. Lxc implémente le sandboxing de processus, qui est une condition préalable importante pour le 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 personnalisée lxc, 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, etc. Docker définit une abstraction pour ces paramètres spécifiques à la machine, de sorte que le même conteneur de docker puisse être exécuté - sans modification - sur de nombreuses machines différentes, avec de nombreuses configurations différentes.
Centré sur les applications. Docker est optimisé pour le déploiement de 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 de 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 inclut 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 d’application, les outils de compilation, les emballages, etc. des archives, ou toute combinaison de ce qui précède, quelle que soit la configuration des machines.
Versioning. Docker inclut des fonctionnalités similaires à celles de Git pour le suivi des versions successives d'un conteneur, l'inspection des différences entre les versions, la validation de nouvelles versions, la restauration, etc. L'historique inclut également comment le contenu d'un conteneur assemblés et par qui, vous obtenez ainsi une traçabilité complète du serveur de production jusqu'au développeur en amont. Docker implémente également des téléchargements incrémentiels, similaires à ceux de "git pull", afin que les nouvelles versions d'un conteneur puissent être transférées en envoyant uniquement des diff.
Réutilisation de composants. N'importe quel conteneur peut être utilisé comme "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 projets futurs. 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: des contenus tels que redis, couchdb, postgres ou Videurs irc sur les serveurs d’applications Rails pour hadoop afin de créer des images pour diverses distributions. Le registre comprend également une "bibliothèque standard" officielle de conteneurs utiles maintenus par l'équipe de docker. Le registre lui-même est à code source ouvert. Chacun peut donc déployer son propre registre pour stocker et transférer des conteneurs privés, pour des déploiements de serveurs internes, par exemple.
Outil écosystémique. 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 s’intégrant à 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’est rapidement imposé comme la norme en matière d’outillage pour conteneurs.
J'espère que ça aide!
Jetons un coup d'oeil à la liste des caractéristiques techniques de Docker , et vérifions celles qui sont fournies par LXC et celles qui ne le sont pas.
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 simple.
2) Isolation de ressources: les ressources système telles que la CPU et la mémoire peuvent être attribuées différemment à chaque conteneur de processus, à l'aide de cgroups.
Fourni avec LXC simple.
3) Isolation 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 propres.
Fourni avec LXC simple.
4) Copy-on-write: 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 dépend Docker. Vous pouvez configurer AUFS vous-même manuellement avec LXC, mais Docker l'utilise comme norme.
5) Logging: les flux standard (stdout/stderr/stdin) de chaque conteneur de processus sont collectés et consignés pour une extraction en temps réel ou par lots.
Docker fournit ceci.
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 davantage de conteneurs. Aucun gabarit ou configuration manuelle requis.
"Modèle ou configuration manuelle" est une référence à LXC, où vous devez vous familiariser avec ces deux choses. Docker vous permet de traiter les conteneurs de la même manière que vous avez l'habitude de traiter des machines virtuelles, sans vous familiariser avec la configuration de LXC.
7) Interactive Shell: 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 à jeter.
LXC fournit déjà cela.
Je viens tout juste de commencer à apprendre à connaître LXC et Docker, je serais donc ravi de recevoir des corrections ou de meilleures réponses.
Les 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 maintenant un référentiel pour les images de conteneur LXC sur lesquelles un utilisateur peut appuyer/extraire pour contribuer ou être réutilisé.
L'API REST de LXD vers LXC permet désormais la création/le déploiement/la gestion locale et distante de conteneurs LXC à l'aide d'une syntaxe de commande très simple.
Les principales caractéristiques de LXD sont les suivantes:
Il existe plugin NCLXD maintenant pour OpenStack permettant à OpenStack d'utiliser LXD pour déployer/gérer les conteneurs LXC en tant que machines virtuelles dans OpenStack au lieu d'utiliser KVM, vmware, etc.
Cependant, NCLXD active également un nuage hybride composé d’un mélange de machines virtuelles matérielles traditionnelles et de machines virtuelles LXC.
Le plugin OpenStack nclxd contient une liste des fonctionnalités prises en charge:
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
À la sortie d'Ubuntu 16.04, en avril 2016, il y aurait eu d'autres fonctionnalités intéressantes telles que la prise en charge des périphériques en mode bloc, la prise en charge de la migration en direct.
Les dockers utilisent des images construites en couches. Cela ajoute beaucoup en termes de portabilité, de partage, de gestion des versions et d'autres fonctionnalités. Ces images sont très faciles à porter ou à transférer et, comme elles sont en couches, les modifications apportées aux versions suivantes sont ajoutées sous forme de couches par-dessus les couches précédentes. Ainsi, lorsque vous portez plusieurs fois, vous n'avez pas besoin de porter les couches de base. Les dockers ont des conteneurs qui exécutent ces images avec l'environnement d'exécution contenu, ils ajoutent les modifications sous forme de 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 un système d'exploitation et d'autres logiciels sont installés. Vous pouvez donc avoir une assez bonne longueur d'avance pour votre application.
Je vais garder cela plus facile, c'est déjà demandé et répondu ci-dessus .
Je me retirais cependant et y répondais légèrement différemment, le moteur de menu fixe lui-même ajoute l’orchestration à ses extras et c’est la partie perturbatrice. Une fois que vous commencez à exécuter une application sous la forme d'une combinaison de conteneurs s'exécutant «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 le donne, en fait, le standard de facto Container Orchestration est Kubernetes, qui se décline en plusieurs saveurs, celle de Docker, mais aussi OpenShift, SuSe, Azure, AWS ...
Ensuite, sous K8S, il existe d'autres moteurs de conteneur; les plus intéressants sont Docker et CRIO - récemment construits, sans démon, conçus comme un moteur de conteneur spécifiquement pour Kubernetes mais immatures. C’est la concurrence entre ceux-ci qui, à mon avis, sera le véritable choix à long terme pour un moteur de conteneur.