Conteneurs Linux (LXC) sur Red Hat / CentOS EL6 - lxc-create contre libvirt?

Il est difficile d'essayer de rester dans les bonnes grâces de Red Hat et de planifier la longévité du système ...

Je suis un partisan des conteneurs Linux (LXC) depuis plus d'un an. Mes installations initiales étaient basées sur des informations glanées dans des tutoriels en ligne, comme celui-ci et celui-ci . Ce centré autour des lxc-create, lxc-start|stopet des lxc-destroycommandes et la modification existants des modèles OpenVZ .

Cela fonctionne bien et fonctionne heureusement en production. Cependant, j'apporte quelques systèmes supplémentaires et j'ai décidé de vérifier la documentation actuelle de Red Hat concernant les conteneurs dans EL6. J'ai été surpris de voir leur position officielle à ce sujet.

Dans RHEL 6 fournit-il les outils LXC nécessaires pour utiliser les conteneurs Linux? , Red Hat décrit LXC comme un aperçu technologique et suggère d'utiliser libvirt pour gérer la création et la gestion de conteneurs .

Pourtant, Oracle préconise une technique de conteneurisation totalement différente dans son Linux incassable.

Il semble y avoir des fonctionnalités manquantes dans la méthode libvirt, mais mon approche initiale avec les commandes lxc- * était un peu un processus manuel ... Je ne peux pas vraiment dire ce qui est bien ou les moyens "acceptés" de gérer les conteneurs sur EL6 .

• Quelle est la sagesse conventionnelle concernant les systèmes de type LXC et RHEL aujourd'hui?
• Comment les mettez - vous en œuvre dans votre organisation?
• Y a-t-il des avantages à une approche par rapport aux autres?
• Ces éléments peuvent-ils coexister?

Quelle est la sagesse conventionnelle concernant les systèmes de type LXC et RHEL aujourd'hui?

Personnellement, je trouve que la configuration actuelle manque un peu. LXC semble plus à l'avant-plan - certainement plus maintenu.

Comment les mettez-vous en œuvre?

En termes d'offre en tant qu'option de virtualisation, je ne le suis pas. Je trouve que la configuration technologique actuelle manque.

• Pas d'espace de nom de nom d'utilisateur.
• Certains points de montage ne sont pas compatibles avec les espaces de noms (cgroups, selinux)
• Les valeurs dans / proc sont des globaux système trompeurs qui ne tiennent pas compte du partitionnement des ressources dans les espaces de noms.
• Interrompt l'audit.

Je trouve cependant que c'est un très bon outil pour le confinement au niveau de l'application. Nous utilisons des espaces de noms et des groupes de contrôle directement pour contenir les ressources réseau et IPC pour certaines applications Web gérées par les utilisateurs. Nous fournissons notre propre interface pour le contrôler. Dans RHEL7, j'envisage de déplacer cette fonctionnalité en libvirt-lxctant que révisions plus récentes de la libvirtprise en charge du concept des listes de contrôle d'accès des utilisateurs.

Pour la virtualisation en termes de système entièrement initialisé, j'attends de voir ce qui est proposé dans RHEL7, mais en toute honnêteté, je pense que nous pourrions ne voir une solution suffisamment bonne qu'une fois que nous serons sur une version mineure ultérieure de RHEL7, puis peut-être uniquement sur un état d'aperçu de la technologie.

Gardez un œil sur systemd-nspawnquelque chose qui me dira au cours des 18 prochains mois qu'il pourrait prendre sa place est le meilleur outil pour faire de la virtualisation entièrement Linux, que les auteurs de systemd indiquent clairement que ce n'est pas sécurisé en ce moment! Je ne serais pas surpris si des libvirtgouttes libvirt-lxcfinissaient par arriver et proposaient juste un wrapper systemd-nspawnavec des tranches systemd définies.

En outre, méfiez-vous, il y a eu beaucoup de discussions au cours des 6 derniers mois en ce qui concerne la réimplémentation de cgroups en tant qu'interface de programmeur du noyau plutôt qu'en tant qu'interface de système de fichiers (peut-être en utilisant netlink ou quelque chose, non vérifié), donc systemd devrait être très chaud sur la queue d'obtenir ce droit très rapidement.

Y a-t-il des avantages à une approche par rapport à l'autre?

Je pense que l'option LXC (pas libvirt-lxc) est mieux maintenue. Après avoir lu le libvirt-lxccode source, il se sent pressé. Le LXC traditionnel a certainement de nouvelles fonctionnalités qui ont été mieux testées. Les deux nécessitent un certain degré de compatibilité par le système init qui y est exécuté, mais je pense que vous trouverez LXC légèrement plus "clé en main" que l' libvirt-lxcoption, en particulier en ce qui concerne le fonctionnement des distributions.

Ces éléments peuvent-ils coexister?

Bien sûr, rappelez-vous qu'à toutes fins utiles, les deux font la même chose. Organisation des espaces de noms, des groupes de contrôle et des points de montage. Toutes les primitives sont traitées par le noyau lui-même. Les deux lxcimplémentations offrent simplement un mécanisme d'interfaçage avec les options de noyau disponibles.

Red Hat fait un énorme effort de conteneurisation. Ils construisent un tout nouveau produit, Red Hat Enterprise Linux Atomic Host , autour de lui.

Pour une approche moins radicale, consultez leur Guide de gestion des ressources bêta RHEL7 et Linux Containers Guide ; vous remarquerez qu'il pousse libvirt-lxc et ne fait aucune mention des outils lxc.

Les exécutables lxc- * sont inclus dans le package lxc dans EPEL . Cependant, c'est l'ancienne version "support à long terme". Vous n'avez même pas l'option "-f" dans lxc-ls. J'installerais simplement Ubuntu pour mes hôtes LXC.

La façon RHEL de gérer LXC semble être via libvirt-lxc mais elle est apparemment obsolète .

A noté que Ubuntu prend en charge la plupart des nouveaux développements lxc / lxd tandis que Redhat se concentre sur KVM et docker.