LXD vs Docker

Tout ce qui est nouveau n'est pas bon et tout ce qui est révolutionnaire n'est pas nécessaire. Avec les technologies de conteneurs, comme avec toutes les autres «prochaines grandes choses», nous voyons une invention rampante d'abstractions de niveau supérieur suivie d'un déploiement en production, avec l'infrastructure CD / CI entière qui en dépend et DevOps ne comprenant pas ce qu'il fait réellement.

Commençons par ce qu'étaient réellement les conteneurs, historiquement. Au début des années 2000, FreeBSD a présenté le concept de «prisons» qui offrait un nouvel environnement, comme une nouvelle installation du système d'exploitation qui propose toute la bibliothèque FreeBSD et l'infrastructure du noyau qui est déjà en place. Une ardoise propre pour les développeurs pour tester de nouveaux logiciels.

Ceci contraste fortement avec VMware, KVM ou VirtualBox Like Technologies où tout le matériel est virtualisé, où, votre système d'exploitation hôte provient un ensemble virtuel de CPU, de RAM et d'autres ressources. Votre système d'exploitation invité se trouve au-dessus de ces ressources matérielles virtuelles. Presque chaque couche d'abstraction est répétée deux fois et des ressources comme RAM et CPU une fois allouées à l'invité ne sont plus disponibles pour l'hôte (que l'invité les utilise ou non entièrement).

Conteneurs Docker et Linux-Y

Le système d'exploitation étant virtualisé, les conteneurs peuvent être tournés avec des quotas pour leur utilisation des ressources. Par exemple, si nous fixons une limite maximale de 2 Go d'utilisation de la RAM pour le conteneur, il ne pourra pas le dépasser. D'un autre côté, comme il n'y a qu'un seul noyau dans la boucle, si le conteneur n'utilise pas la RAM entière, le noyau peut utiliser la ressource restante à utiliser ailleurs.

Le premier inconvénient que les gens ont réalisé avec le modèle de conteneur est que comme nous virtualisons le système d'exploitation et non le matériel, vous pouvez avoir plusieurs instances du même système d'exploitation et vous perdez la capacité de faire tourner un système d'exploitation arbitraire.

Il n'y a pas comme le conteneur Windows sur des conteneurs Linux ou Linux sur Windows. Docker sur Windows, par exemple, utilise Moby Linux qui s'exécute réellement dans une machine virtuelle à l'intérieur de votre boîte Windows.

Quand il s'agit d'une distribution Linux, cependant, vous pouvez faire beaucoup de choses intéressantes. Puisque ce que nous appelons Linux, ce n'est que le noyau et qu'il a besoin d'une pile GNU de bibliothèques pour fournir un environnement OS complet, vous pouvez imiter diverses distributions telles que Centos, Ubuntu, Alpine dans différentes instances de conteneurs.

C'est vrai pour LXD et Docker.

Docker comme mécanisme d'emballage

Docker fera à APT, ce qu'APT a fait à Tar. C'est-à-dire que vous utiliserez toujours APT mais avec une couche d'abstraction supplémentaire. Pour comprendre comment, considérez l'exemple suivant.

Vous avez une instance de votre site Web en cours de php5.6 Et vous devez exécuter un autre service Web sur le même serveur en utilisant PHP7.0. Maintenant, exécuter deux versions différentes de PHP elle-même est une idée effrayante, ne sachant pas quels conflits en découleraient. La mise à jour et la mise à niveau deviendront bientôt une entreprise désespérée.

Mais que se passe-t-il si nous avions notre instance Web d'origine dans un conteneur Docker? Maintenant, tout ce dont nous avons besoin est un nouveau conteneur Docker à l'intérieur de laquelle nous pouvons installer PHP7.0 et notre deuxième service Web fonctionnera à partir de ce conteneur nouvellement filé. Nous utiliserons toujours APT en arrière-plan, tout comme APT utilise le goudron en arrière-plan, mais Docker s'assurerait que diverses applications de différents conteneurs ne sont pas en conflit.

Docker est particulièrement utile pour exécuter des applications sans état et vous entendrez des gens dire souvent que vous ne pouvez pas exécuter plus d'un processus dans un conteneur. Bien que cela soit faux, exécuter plusieurs services avec état dans une instance de conteneur peut souvent amener Docker à donner des résultats incohérents. Vous vous retrouverez bientôt à redémarrer le même ensemble de conteneurs encore et encore.

LXD comme hyperviseur

Avec les conteneurs LXD, ce que vous obtenez est beaucoup plus proche d'un système d'exploitation autonome que ce que vous obtenez de Docker. Les conteneurs Docker partagent tous la même pile de réseautage et la même pile de stockage.

Cela signifie des commandes de base comme ping-ping ou ifconfig sont indisponibles de l'intérieur d'un conteneur docker. En fait, vous ne pouvez presque rien savoir sur le réseau sur lequel vous vous trouvez, de l'intérieur de ce conteneur. Docker Nat fonctionnant sur la pile de réseautage de l'hôte offre la majeure partie de la connectivité et des installations comme le rediffusion.

Les conteneurs LXD sont bien en avance sur la courbe, prenant en charge les ponts de réseau, Macvlan et plusieurs autres options. Vos conteneurs LXD et votre hôte forment tous un réseau privé et peuvent communiquer entre eux comme s'ils parlaient à différents ordinateurs sur un réseau.

Il en va de même avec la pile de stockage. Il est souvent beaucoup plus pratique d'utiliser LXD avec des pools ZFS où vous pouvez allouer des ensembles de données avec des quotas limitant l'utilisation du stockage. LXD est en concurrence directe avec VMware, KVM et d'autres technologies d'hyperviseur.

L'utiliser, votre fournisseur de cloud peut désormais vous fournir votre conteneur personnel qui sentait et ressemblerait à un système d'exploitation complet et est toujours bon marché pour tourner et tuer, ainsi que toutes les subtilités de données persistantes que vous vous attendez.

Du point de vue du fournisseur, les choses sont également économiques. Étant donné que tout le monde n'utilise pas la RAM entière qu'ils demandent, vous pouvez entasser beaucoup plus de conteneurs sur le même métal que vous pouvez.

Aux utilisateurs finaux, cela peut ressembler à la tricherie au début, mais ils gagnent également à la fin, les conteneurs LX sont plus rapides à tourner et à tuer, ce qui rend le processus beaucoup plus fluide et «évolutif» (comme les gens aiment le dire).

Vous pouvez faire tourner des conteneurs sur un nœud de calcul où réside vos données, faire le calcul que vous souhaitez faire, puis détruire le conteneur en laissant les données intactes. Ceci est beaucoup plus rapide que de récupérer les données pertinentes jusqu'à votre machine virtuelle qui s'exécute sur un autre centre de données. Cela fonctionne particulièrement bien avec ZFS dans la boucle.

TL; Dr

Pour résumer tout ce que nous savons, LXD et Docker sont des technologies de contenerisation. Docker est léger, simpliste et est bien adapté pour isoler les applications les unes des autres, ce qui le rend populaire parmi les DevOps et les développeurs. Une application par conteneur Docker.

LXD, en revanche, est beaucoup mieux équipé et est beaucoup plus proche d'un environnement complet du système d'exploitation avec des interfaces de mise en réseau et de stockage. Vous pouvez exécuter plusieurs conteneurs Docker imbriqués à l'intérieur de LXD, si vous le souhaitez.