LXD : la pièce manquante

LXD signifie Linux Container Daemon. Il s’agit d’une technologie de conteneur. Mais LXD est très différent. Il se distingue du peloton. Ce n’est pas nécessairement mieux ni beaucoup plus rapide ni plus sécurisé ! Mais cela résout un autre problème que les autres conteneurs ne peuvent pas solutionner. La transition des machines virtuelles traditionnelles vers les conteneurs d’applications s’est faite trop rapidement. Cela est dû notamment au hype autour de Docker, Kubernetes et les autres.

Mais il existe un type de conteneur plus ancien. Ce dernier a essayé de couvrir un grand nombre de cas d’utilisation que nous avons encore aujourd’hui et pour encore un certain temps.

Virtualisation en quelques mots

La figure ci-dessous montre clairement la différence entre les hyperviseurs (1,2) et les conteneurs.

Beaucoup d’entre nous connaissent aujourd’hui la différence entre une machine virtuelle et un conteneur. La virtualisation est une technologie qui ment à un système d’exploitation hôte ! L’hyperviseur émule une couche matérielle. Ainsi, l’invité peut le voir et penser qu’il fonctionne sur un vrai matériel. Il envoie des appels système à cette couche à l’aide des pilotes du matériel émulé (càd. E / S). L’hyperviseur intercepte ces appels et les convertit / redirige vers le matériel physique de l’hôte à l’aide des pilotes du matériel physique. Celui qui contrôle ces pilotes indique le type de l’hyperviseur. Si l’hyperviseur est en contrôle, il s’agit d’un hyperviseur de type 1. Si le système d’exploitation hôte gère les pilotes pour l’hyperviseur, il s’agit d’un hyperviseur hébergé ou d’un hyperviseur de type 2. Les hyperviseurs de type 1 sont les plus puissants. Ils sont généralement destinés aux environnements de production. Bien que les hyperviseurs de type 2 soient très simples à installer et à utiliser, ce type est utilisé pour les environnements de développement et de test.

La faiblesse de la virtualisation provient de sa plus puissante fonctionnalité

La virtualisation est très fascinante. Les hyperviseurs peuvent héberger plusieurs types de système d’exploitation et émuler plusieurs architectures matérielles (CPU, disques, réseau, etc.). Il est donc possible d’exécuter une large gamme de systèmes d’exploitation, avec un matériel émulé différent du matériel physique. Il n’y a pas de solution miracle ni de solution sans inconvénients. L’émulation et le passage d’appels système entre le matériel émulé et le matériel physique entraînent un coût supplémentaire en terme de performances. Cela est vrai, outre la nécessité d’exécuter un système d’exploitation invité complet pour chaque machine virtuelle (noyau, pilotes, shell complet, etc.). Cela est lent, très lourd sur le disque et non optimal. De nombreuses technologies ont été introduites pour réduire le overhead, telles que la para-virtualisation et les capacités d’accélération matérielle intégrées à la CPU. Tandis que les hyperviseurs tentaient de réduire le temps système d’émulation, les conteneurs l’enlevaient.

C’est l’ère de Linux

Linux et l’Open Source ont longtemps été les négligés, mais ce n’est plus le cas ! La majorité des applications fonctionnent sous Linux. Les conteneurs deviennent populaires en raison du nombre croissant d’applications fonctionnant sous Linux - ou l’inverse ! Les conteneurs ont également amené beaucoup d’utilisateurs à Linux. Étant donné que le système d’exploitation d’application standard est Linux, il n’est pas nécessaire d’émuler du matériel ni d’exécuter un système d’exploitation invité complet.

”avec le vent dans les cheveux et la terre sous mes pieds, je ne fais qu’un avec la nature, mon esprit est libre” [1], a déclaré le conteneur sur un hôte Linux.

Un conteneur est un ensemble de processus isolés qui s’exécutent sur le noyau à côté d’autres processus. Les processus conteneurs “ne veulent pas” / “n’ont pas besoin” de connaître les processus hôtes. Ainsi, le processus à l’intérieur d’un conteneur ne peut pas voir ce qui se passe à l’extérieur. L’hôte gère les processus de conteneur en tant que processus normaux.

Le conteneur repose sur l’hypothèse que nous pouvons partager le noyau hôte entre tous les conteneurs. Les anciennes technologies Linux tels que les groupes de contrôle, les espaces de noms, les rootfs isolent ces invités / conteneurs et créent des espaces de noms dédiés (réseau, montage, PID, utilisateur, etc.). Il n’y a donc pas besoin de l’émulation et de tous ses frais supplémentaires. Tous les conteneurs parlent directement au noyau, qui exécute toutes les actions privilégiées. Néanmoins, seul un système d’exploitation invité supporté peut être exécuté sur ce noyau. Par conséquent, seul Linux peut être exécuté en tant que conteneur. Il peut sembler que c’est un inconvénient des conteneurs Linux, mais dans la réalité, c’est l’inconvénient “des autres”, de ne pas être Linux.

LXD résout ce que Docker ne résout pas

Le conteneur d’applications fournit uniquement l’environnement très basique pour l’exécution d’un processus. Le conteneur reste donc très léger, très rapide, facile à entretenir et à mettre à jour. C’est ce que fournit un conteneur Docker. D’un autre côté, les conteneurs de machines sont des conteneurs conçus pour exécuter un environnement VMlike complet. LXD (LXC + LXD) fournit l’expérience de la machine virtuelle sans les machines virtuelles !

LXC fournit un environnement pour exécuter un système d’exploitation complet, avec tous les services nécessaires. En termes simples, vous pouvez faire sur un conteneur LXC ce que vous faites sur une machine virtuelle. LXD fournit des fonctionnalités de gestion d’ Hypervisor. Il peut effectuer efficacement et facilement l’ajustement des allocations de ressources pendant l’exécution du conteneur, la capture instantanée, la restauration, la migration d’un hôte à un autre et la copie …

LXD tente de remplacer les machines virtuelles et les hyperviseurs pour une large gamme de cas d’usage. Docker est très puissant, mais son adoption par les développeurs est très difficile, en particulier pour les opérations. En effet, elle implique de changer la façon dont nous exploitons la plateforme. Il existe de nombreuses applications qui coûtent une fortune à développer et sans aucune intention de faire une refonte pour les adapter aux environnements Docker. En résumé, LXD offre tous les avantages de l’utilisation des conteneurs. Sans qu’il soit nécessaire de changer notre façon de procéder, elle est transparente pour les opérateurs d’applications et les SE invités.

Quelle est la prochaine ?

Vient ensuite un article pour une visite rapide de LXD. Nous allons configurer un environnement, configurer LXD, créer des conteneurs et les gérer.

[1] Citation de Christy Ann Martine

Partagez cet article