Cap sur LXC

Cap sur LXC

Rendez-vous à Farpoint

J’ai parcouru les quatre coins de la toile afin de me documenter sur la mise en place de LXC. Après huit mois de travail le projet commence à se concrétiser. Voici la configuration que j’ai installée afin de réaliser mes essais sur LXC. Mon cahier des charges étant très simple, exécuter mes différents serveurs (mails, dns, web, et autres) dans des containers et en faire une sauvegarde externalisée en cas de pépin. Ce sera l’occasion de faire une petite série d’articles sur mon utilisation de LXC.

 

Le serveur

Tout d’abord j’ai cherché un nouveau matériel, quelque-chose de peu encombrant, le moins énergivore possible et qui me permettrait de pouvoir exécuter des containers. Actuellement mon serveur hôte datant de 2010 abrite un vieil Athlon II dual-core accompagné de 8Go de ram et d’un disque dur de 500go de disque dur en sata. C’est largement suffisant pour héberger mes quatre containers Openvz et mes deux VM Kvm (qui seront amenées à disparaître avec la nouvelle solution) le tout orchestré par Proxmox. Ma démarche actuelle n’est pas de changer pour plus puissant, je n’utilise même pas la moitié de la RAM et le processeur ne vacille jamais au dessus de 15% d’utilisation. Ce que j’ai mis en place en 2010 n’est plus en adéquation avec ce que  j’aspire aujourd’hui. En effet ce serveur est en configuration moyen tour avec une alimentation de 450 watts et un ventilo de 120mm en façade. Au niveau encombrement il n’est pas facile de lui trouver une place loin du lieu de vie et à cause de sa ventilation vieillissante il a de plus en plus de mal à se faire oublier.
J’ai donc opté pour un petit Brix de chez gigabyte le GB-BXBT-2807. Équipé d’un intel dual-core qui ne consomme que 4w. J’y ai rajouté 8go de ram et un disque-dur de 500Go.  L’encombrement est minimal et je retrouve presque les mêmes performances que mon vieux serveur.

La bête mise à nue
La bête mise à nue

Voici le détail du matériel que j’utilise pour cette configuration :

  • BRIX GB-BXBT-2807
  • 8 Go de ram Corsair Value Select SO-DIMM 8 Go DDR3L 1333 MHz CL9
  • Disque dur Seagate Constellation 500 Go 7200 RPM 64 Mo Serial ATA 6Gb/s

Le choix du disque n’est pas encore arrêté, je me demande si au de niveau bruit il ne vaudrait pas mieux prendre un 5400 tours, mais d’un autre côté j’ai peur de perdre des performances. La vitesse du disque dur est-elle prépondérante dans le fonctionnement des containers ? Je planche encore sur la question. Je commence aussi à regarder du côté des SSD, mais j’avoue que la technologie me fait encore un peu peur.

Mise en place

Le choix du moteur de containers n’a pas était long à prendre, car d’un côté j’avais OpenVZ :

  • Vieux noyau
  • Incompatible avec systemd donc condamné à utiliser Wheezy
  • Silence complet sur le nouveau projet Virtuozzo 7(au moment où j’écris ses lignes)

et de l’autre LXC :

  • basé sur les outils noyau donc noyau plus récent
  • compatible systemd utilisable sur Jessie et supérieure
  • Projet très actif, la dernière mise à jours date de novembre 2015
  • Mon goût pour l’aventure, essayé quelque chose de nouveau, bousculer ma routine de geek.

C’est pourquoi j’ai souhaité migrer sous LXC, plutôt que de continuer dans la valeur sûr OpenVZ que j’utilise depuis quelque année déjà.

Pour mon système hôte j’ai donc choisi de partir sur :

  • Une Base Debian 8
  • Système de fichier BTRFS
  • Un point de montage NFS pour les sauvegardes

Voici comment sera organisé mon installation système.

Dans un premier temps l’intérêt du dispositif LXC+BTRFS réside dans la possibilité de créer très rapidement des instantanés et des clones. Pour les instantanés (snapshot) il faut que le dossier lxcsnaps soit intégré dans le système de fichier btrfs. Les instantanés sont utiles avant une mise à jour système par exemple pour un retour en arrière rapide en cas de problème ou sauvegarder le container en toute simplicité. Le clonage est aussi très intéressant il permet de gagner du temps lors de la création d’un nouveau container. Dans un second temps il s’agit d’une meilleure gestion de l’espace disque lorsque l’on fait plusieurs instantanés d’un même container il ne copie que la partie du conteneur qui a changé. La finalité étant de mettre la partition /var/lib/lxcsnaps sur mon Nas en évitant de sauvegarder les containers sur le serveur.

Pour bénéficier de ce système de fichiers je crée la partition mère lxc-data qui hébergera les différents sous-volumes

et de je la monte de façon permanente dans le fstab. Il est recommandé de monter les partitions et sous-volumes btrfs avec l’UUID. Ici l’UUID de sd4 est a69d9182-f4c7-4276-b35d-7d5f9bd50a57.

Ensuite je crée les deux sous-volumes,

et toujours pour que le montage soit permanent j’ajoute dans le fstab.

Voila l’environnement des containers est en place. A voir avec le temps si celui-ci viable pour mon utilisation de LXC, ça tombe bien cela fait parti du test.

Installation et configuration de LXC

Préparation du noyau :

LXC est en perpétuel évolution afin de bénéficier des récents changements, j’utilise un noyau plus récent que celui fournit avec Jessie. J’installe donc celui de la branche testing. Je crée un fichier préférence pour définir la priorité des dépôts :

Ensuite dans le fichier source.list d’apt j’ajoute :

Pour finir dans mon terminal :

Après un redémarrage me voilà en version 4.3 du noyau. En revanche, j’ai été obligé de désactiver la mise en veille de l’écran, car celui-ci ne se rallume pas une fois en mode veille.

Installation de LXC sous Debian 8.2 :

Souhaitant gérer la mémoire et le swap de mes containers je suis obligé d’activer le cgroup responsable de la mémoire qui est déactiver par défaut. Debian a choisi de ne pas activer par défaut ce cgroup afin de ne pas pénaliser les utilisateurs qui ne souhaitent pas les utiliser. Cela évite une trop grande consommation mémoire pour rien. Il me suffit d’ajouter l’instruction « cgroup_enable=memory » et pour le swap « swapaccount=1 » au démarrage de Grub.

Pour activer les changements sur grub.

Pour finir je redémarre mon hôte et vérifie l’installation de LXC

Tout est OK, je continue avec la configuration réseau de mon hôte. Pour plus de simplicité la configuration de l’interface réseau de mon hôte sera en mode bridge. L’activation du mode bridge sur le serveur hôte se fait dans le fichier interfaces. Attention toutefois à ce que le paquet bridge-utils soit installé sur l’hôte. Ce fichier régente la configuration des tous les périphériques réseau du système. Il se trouve dans /etc/network/interfaces.

Validation de la modification.

Sur le container qui me servira de base pour cloner les autres, j’applique la configuration réseau suivante.

LXC est maintenant en place, le gros du travail commence. Découvrir l’utilisation des containers, leur configuration, leur sauvegarde et bien d’autre. D’après mes premières manipulations, LXC est aussi facile d’utilisation qu’OpenVz. Il faut que je me familiarise avec les différentes commandes et la philosophie qui ne sont pas les mêmes.  J’ai encore pas mal des questions en suspend, c’est pour cela que je me lance dans ses essais grandeurs natures. Petit à petit je basculerai certains des mes serveurs sur cette nouvelle infrastructure en mode presque réel afin d’observer le comportement de tout ce petit monde. Suite au prochain épisode.

Merci à Deimos et au Wiki Debian qui m’ont beaucoup aidés à mettre en place cette plateforme de test.

 

 

12 thoughts on “Cap sur LXC

  1. Merci pour ce partage d’information sur ta nouvelle plateforme. Pour ma part j’ai testé LXC avec la nouvelle version de Proxmox qui intègre LXC à la place d’openvz. Mon avis est plus mitigé sur LXC car je trouve que l’on a beaucoup perdu de la souplesse que proposait openvz en particulier le changement à chaud des caractéristiques de la VM (nb core, ram et surtout augmentation de l’espace disque).
    De plus avec LXC si on fait un top ou htop on ne voit pas les ressources utilisées par le container mais celles de l’hôte… Mais je n’ai pas poussé beaucoup plus loin pour le moment… et donc je suis forcément intéressé par tes avancées. D’ailleurs as-tu abandonné proxmox ? si oui, pourquoi ?

    1. Salut,

      Je n’ai pas encore poussé mon utilisation d’LXC. Mais au cours des mes différentes recherchent les problèmes que tu abordes ont été souvent évoqués. Il me semble que certains sont en voie de résolution, je ne me rappelle plus j’ai lu tellement de choses sur LXC j’arrive un peu à saturation. Je me rends bien compte que LXC est encore jeune et il a encore beaucoup de chemin à parcourir pour arrivé à une certaine maturité, mais je voulais dès à présent explorer son fonctionnement et voir s’il était viable pour mon utilisation personnelle. Pour l’instant je n’ai pas abandonné Proxmox mais à terme se sera le cas si l’expérience LXC est concluante, je le garde en plan B au cas ou. Pourquoi je souhaite me séparer de Proxmox, tout simplement pour voir ce qui se fait ailleurs, avoir une infra faite maison est qui correspond mieux à mes usages. Proxmox s’adresse de plus en plus aux entreprises et je n’ai pas les même besoins ni moyens qu’une entreprise. Si je m’auto-héberge c’est justement pour ne pas être dépendant d’une solution unique et c’est actuellement le cas avec Proxmox. Alors j’essaie d’autres alternatives.

  2. Concernant la problématique de consommation d’énergie, il ne fait pas oublier que la phase d’usage d’un ordinateur est négligeable par rapport à sa construction/destruction. D’un point de vue environnemental, il faut donc essayer de réutiliser l’existant. Je pense qu’avec votre ancien matériel il aurait été possible de le réintégrer dans un boitier plus réduit, quitte à l’imprimer en 3D.
    L’utilisation de LXC est intéressante, ça change des traditionnels conteneurs Docker à la mode aujourd’hui 🙂

  3. Sympa mais je me pose quelques questions :
    – Pourquoi une partition swap ?
    – Pourquoi une partition ext4 ?
    – Tu n\’abordes pas ce point mais est-ce que tu utilises des containers \ »unprivileged\ » ? (cad non pas créé par root mais par un user classique)

    Frinux : Je ne sais pas comment se débrouille proxmox mais perso dans mes containers je ne vois pas les process de l\’hôte dans htop ou ps.

    1. @Lord
      – Pourquoi une partition swap ?
      – Pourquoi une partition ext4 ?
      Parce que btrfs pose encore beaucoup de problèmes de stabilités sur les partitions systèmes. De plus je découvre aussi ce système de fichiers et donc j’apprends petit à petit son utilisation. Pour la partition swap c’est réflexe lors de l’installation j’ai toujours utilisé une swap sur mes linux.

      Concernant le containers \”unprivileged\” j’ai découvert leur existence après cet article dont j’ai commencé la rédaction début décembre, je suis en train de me renseigner dessus. D’ailleurs si tu as des éléments de lecture je suis preneur. Est ce que les containers unprivileged améliore l’allocation des ressources ? ou est ce un moyen pour améliorer la sécurité du système hôte ?

      J’ai un peu regarder du côté de proxmox 4, il n’utilise pas complétement LXC et les cgroup. Si tu regarde dans /var/lib/lxc/container/rootfs celui-ci est vide, par contre une image en .raw est créee pour le système de fihcier du container. Je pense que les développeurs ont crées leur propre surcouche pour LXC, peut-être pour pallier le manque d’isolation des containers. J’ai aussi remarqué que certains outils natif d’LXC ne fonctionnaient pas correctement sous Proxmox comme « lxc-ls -f » qui n’affiche pas le détails des containers. J’ai remarqué aussi plein d’autres différences que je n’ai plus en tête.

      1. Bonjour,
        je suis un utilisateur de proxmox 4 avec un petit serveur (un proliant miniserv) qui à 4 disque de 2To en raid,
        La bonne nouvelle c’est que proxmox 4 prend en charge le raid logiciel, il suffit quand à l’installation il demande sur quel disque installer de cliquer sur option.
        Après je voulait un raid 6, ça marche mais mon processeur (un AMD Turion II Neo N54L) ramait à mort.
        Donc ré-installation en raid60 et c’est bon,
        comme il utilise zfs comme système de fichier, les lxc sont stocké dans des datasets qu’on peut redimensionner comme on veux (en gros ça ressemble à des répertoires avec des quotas).

  4. Personnelement je pense pas que btrfs pose soucis pour le système 😉

    Pour les containers unprivileged c\’est surtout d\’un point de vue sécurité. Vu qu\’ils sont gérés par un utilisateurs non root. En cas de faille ou autre, il n\’y a pas de risque de sécu énorme. Alors qu\’un container classique pourrait éventuellement monter les partitions hôte ou juste devenir root sur l\’hôte. Bref LXC sans ça a peu d\’intéret à mes yeux.
    Pour de la doc sympa perso j\’ai suivi le wiki gentoo (j\’utilise pas de debian).

  5. Bonjour Jimmy, j’ai remarqué que tu intervenais sur pas mal de forum qui on pour sujet LXC en ventant la formation PAYANTE de alphorm, j’espère que c’est purement non commercial de ta par

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.