Cap sur LXC

Rendez-vous à Farpoint

Il y a quelques mois j’entamais une réflexion sur le changement de ma solution d’hébergement. Ce fut le point départ de longues semaines de travail. 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.

HDD
├── /(/dev/sda1)ext4
│           
├── swap(/dev/sda2)swap
│
└── /lxc-data(/dev/sda4)btrfs
      ├── /var/lib/lxc/(sous-volume0)btrfs
      │       ├── container1
      │       ├── container2
      │       ├── container3
      │       └──....
      │           
      └──/var/lib/lxcsnaps/(sous-volume1)btrfs
              ├── snapshot container1
              ├── snapshot container2
              ├── snapshot container3
              └──....

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

mkfs.btrfs /dev/sda4

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.

UUID=a69d9182-f4c7-4276-b35d-7d5f9bd50a57      /lxc-data      Btrfs      rw,noatime,compress=zlib,autodefrag      0      0

Ensuite je crée les deux sous-volumes,

#le sous-volume des containers
btrfs subvolume create lxc
#le sous-volume des instantanés
btrfs subvolume create lxcsnaps

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

UUID=a69d9182-f4c7-4276-b35d-7d5f9bd50a57      /var/lib/lxc      Btrfs      rw,noatime,compress=zlib,autodefrag,subvol=lxc-data/lxc      0      0
UUID=a69d9182-f4c7-4276-b35d-7d5f9bd50a57      /var/lib/lxcsnaps      Btrfs      rw,noatime,compress=zlib,autodefrag,subvol=lxc-data/lxcsnaps      0      0

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 :

nano /etc/apt/preferences.d/kernel

Package: *
Pin: release a=stable
Pin-priority: 900
 
Package: *
Pin: release a=testing
Pin-priority: 100
 
Package: linux-image-*
Pin: release a=testing
Pin-priority: 1001
 
Package: linux-headers-*
Pin: release a=testing
Pin-priority: 1001
 
Package: linux-kbuild-*
Pin: release a=testing
Pin-priority: 1001

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

nano /etc/apt/sources.list

# Kernel Testing
deb http://ftp.fr.debian.org/debian/ testing main non-free contrib
deb-src http://ftp.fr.debian.org/debian/ testing main non-free contrib

Pour finir dans mon terminal :

apt update
apt install linux-image-amd64

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.

nano /etc/default/grub
#ajouter consoleblank=0 à la ligne
GRUB_CMDLINE_LINUX_DEFAULT="quiet consoleblank=0"
#reconfiguration de grub
update-grub
#redémarrage du serveur

Installation de LXC sous Debian 8.2 :

apt install lxc bridge-utils libvirt-bin debootstrap cgroupfs-mount

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.

nano /etc/default/grub
# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
#   info -f grub -n 'Simple configuration'
 
GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet consoleblank=0 cgroup_enable=memory swapaccount=1"
GRUB_CMDLINE_LINUX=""
[...]

Pour activer les changements sur grub.

update-grub

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

lxc-checkconfig
Kernel configuration not found at /proc/config.gz; searching...
Kernel configuration found at /boot/config-3.16.0-4-amd64
--- Namespaces ---
Namespaces: enabled
Utsname namespace: enabled
Ipc namespace: enabled
Pid namespace: enabled
User namespace: enabled
Network namespace: enabled
Multiple /dev/pts instances: enabled

--- Control groups ---
Cgroup: enabled
Cgroup clone_children flag: enabled
Cgroup device: enabled
Cgroup sched: enabled
Cgroup cpu account: enabled
Cgroup memory controller: enabled
Cgroup cpuset: enabled

--- Misc ---
Veth pair device: enabled
Macvlan: enabled
Vlan: enabled
File capabilities: enabled

Note : Before booting a new kernel, you can check its configuration
usage : CONFIG=/path/to/config /usr/bin/lxc-checkconfig

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.

nano /etc/network/interfaces
# je commente les lignes de l'’interface réseau principale 
#allow-hotplug eth0
#iface eth0 inet dhcp

#J'active le bridge avec ip statique sur l’hôte
auto br0
iface br0 inet static
       bridge_ports eth0
       bridge_fd 0
       address < IP de l’hôte ici, exemple: 192.168.1.20>
       netmask 255.255.255.0
       network <IP du réseau ici, exemple: 192.168.1.0>
       broadcast <IP de broadcast ici, exemple: 192.168.1.255>
       gateway <IP de la passerelle ici, exemple: 192.168.1.1>
       dns-nameservers <Adresse IP du DNS ici, exemple: 192.168.1.1>
       dns-search votre.domaine.de.Recherche.ici

Validation de la modification.

systemctl restart networking

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

## Réseau
lxc.utsname = containershostname
lxc.network.type = veth
lxc.network.flags = up

# Ceci est l’interface définit plus haut dans le fichier interface de l’hôte :
lxc.network.link = br0

# Nom de l’interface réseau dans le container,
# lxc.network.name = eth0 

lxc.network.hwaddr = 00:FF:AA:00:00:01

# L’ip du container 
lxc.network.ipv4 = 192.168.1.110/24

# Définissez la passerelle pour avoir un accès à Internet
lxc.network.ipv4.gateway = 192.168.1.1

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.

 

 

Vus : 1822
Publié par Olivier Delort : 73