Hébergement et taille de containers

Dans le prolongement de mon article “Choix du système pour s’auto-héberger”, je peux faire un bilan des 6 mois écoulés avec mon hébergement à base de containers LXC avec la distribution Proxmox.

Commençons par les avantages

Le passage d’une installation monolithique à une installation containerisée avec des services répartis dans une dizaine de containers donne la flexibilité de choisir le meilleur outil pour chaque tâche :

  • les micro-services Python se contentent de containers Alpine ultra-légers (64 Mo de RAM).
  • le service Nextcloud a migré d’un container Alpine à un container ArchLinux. Je n’aurais jamais pensé utiliser Arch sur un serveur mais c’est une bonne solution pour garantir une version stable et toujours à jours en terme de sécurité de Nextcloud.
  • le middleware RabbitMQ est installé sur sa distribution de prédilection CentOS dans un container dédié.

La modularité facilite l’administration du serveur : on a besoin d’un nouveau service, on rajoute un container et on limite les risques de casser quelque chose sur l’installation existante.

L’interface Web d’administration de Proxmox est de qualité. Au delà de la gestion des machines virtuelles KVM et des containers LXC, elle donne une vision des ressources CPU /Mémoire consommées par container et au niveau physique.

Tableau de bord Proxmox

Ce qui n’est pas parfait

J’ai un service Nextloud, aisé à gérer dans un seul container avec l’application, les données et la base de donnée. Pour sauvegarder, c’est moins drôle, cela revient à sauvegarder le container de bientôt 100 Go avec Proxmox et la balancer sur l’espace FTP de 100 Go offert par Online. Autre option, sauvegarder les données du calendrier et les contacts avec des scripts maison et mettre en place une sauvegarde classique vers un disque externe des fichiers synchronisés sur mon ordinateur portable. C’est vers cette solution que je m’oriente.

La nuée de services développés par bibi autour du blog (SRMail, Stacosys) serait parfaite pour Docker. Aujourd’hui c’est installé dans des containers LXC, avec des partages de répertoires entre le hôte et les containers pour externaliser la configuration et les données. Docker permettrait de standardiser cet assemblage et d’en profiter à la maison pour facilement remonter un environnement de test.

C’est vraiment le point négatif : j’ai des relations troubles entre la machine hôte et les containers. J’ai installé un serveur NginX sur Proxmox qui fait du proxy vers les NginX des différents containers en fonction du service demandé. J’ai partagé des répertoires entre le hôte et les containers pour externaliser les parties sensibles (la configuration et les données) et faciliter leur sauvegarde puis la machine hôte. Je gère les certificats Let’s Encrypt au niveau du hôte aussi. Bref j’ai une installation custom de Proxmox avec des containers mais aussi plein de trucs installés au niveau de l’hyperviseur.

Conclusion

Ca fonctionne bien mais si j’ai un souci (mise à jour de Proxmox qui casse quelque chose, panne du serveur), je risque de passer des jours à tout remettre en service car j’ai tout installé à la mano. L’idée de tout reprendre à zéro en passant plus de temps pour tout containeriser refait surface. L’idéal pour moi serait de tout exécuter dans des containers et d’avoir une seule arborescence de fichiers à sauvegarder. J’avais tâté un peu Docker et je sais que ça prend pas mal de temps de repenser en containers, de choisir les bonnes images de base… Autre bémol, miser sur une seule entreprise ne m’emballe pas, malgré les efforts de l’Open Container Initiative pour standardiser partiellement la technologie.

Donc j’étudie les options :

  • un provisioning avec Ansible d’un container LXC générique
  • l’ajout de Docker à Proxmox pour rajouter Docker au panel KVM / LXC: dockeriser c’est long, donc garder Proxmox permettrait de répondre rapidement à un besoin avec un container LXC, quitte à dockeriser ensuite le service dans un 2ème temps…

Si vous avez des suggestions je suis carrément preneur :-)

Mctimber - 2018-05-20 23:48:42

Merci pour cette article et retour d’expérience.

1) Dans le deuxième paragraphe, est-ce des inconvénients ou des points à améliorée? (Pas sur de la nuace)

2) Avez vous regardé du coté de Vagrant?

Je réfléchie aussi à une manière d’automatisé mon Proxmox, j’ai pas le temps de tester. Je serais ravie de lire un retour sur votre choix.

Bonne soirée

Liandri - 2018-05-20 23:50:52

Ou sinon, gérer le dossier data du container Nextcloud dans Proxmox, en le partageant au container : limite la taille du container à sauvegarder, permet de partager les données à plusieurs containers aussi. Et du coup, gérer la sauvegarde de ces datas différement.

Mirabellette - 2018-05-21 06:48:12

Hello,

“J’ai partagé des répertoires entre le hôte et les containers pour externaliser les parties sensibles (la configuration et les données) et faciliter leur sauvegarde puis la machine hôte. “

C’est peut-être là le problème que tu rencontres avec ton utilisation des conteneurs. Ils ont pour vocation à être indépendant et fonctionnel seul. L’externalisation des parties sensibles n’est pas nécessaires et t’ajoute un système de dépendance entre ton hôte et tes conteneurs.

Ce que je te recommande comme utilisation pour les conteneurs, c’est de soit les sauvegarder dans leurs intégralités. Comme ça tu as juste à les mettre sur une nouvelle machine avec lxc et la bonne configuration réseau / reverse proxy et roulé jeunesse.

Et en parallèle, si tu veux pas forcement sauvegarder les conteneurs dans leurs intégralités (je te conseille vivement de le faire dans leurs intégralités, le gain en administration est tellement énorme), tu installes les nouveaux logiciels uniquement dans /opt. Ce qui te permet de faire une sauvegarde de /etc et de /opt et d’avoir toutes les informations importantes pour tes logiciels.

Pour les datas, je te conseille de tout externaliser dans un répertoire spécifique sur la machine hôte et de jouer avec les points de montage.

Pour le conteneur générique, ce que j’ai fais personnellement, c’est de faire un conteneur template avec tous les logiciels de bases, épuré à mort et bien configuré (pare-feu, systctl, logrotate). Comme ça dés que je veux faire un nouveau conteneur, je fais une copie de celui-ci et j’installe les différences. Aujourd’hui avec Ansible c’est pas forcément le mieux, mais c’est le plus simple si tu veux éviter d’ajouter une nouvelle technologie.

Yax - 2018-05-21 09:56:05

@Mctimber la standardisation de la création des containers est un point à améliorer : être capable de remonter le même environnement sur un autre serveur en cas de migration ou d’installer un environnement de test.

L’installation de composants au niveau de l’hyperviseur est un vrai inconvénient. La plupart auraient pu donner lieu à un container aussi. C’est surtout cette partie que je dois revoir car elle complique toute migration vers un autre serveur.

J’avais utilisé Vagrant il y a quelques années pour faire du provisioning de VM Virtualbox avec Ansible. Aujourd’hui il annoncent une compatibilité avec Docker. Ca permet de monter un environnement de test isolé en VM sur un poste de travail. Je ne sais pas si c’est applicable sur un serveur pour des containers LXC. Il faut que je jette un oeil c’est une piste.

Merci pour ces retours.

Yax - 2018-05-21 09:58:16

@Liandri oui ce serait pousser la même logique que pour les microservices.

Yax - 2018-05-21 10:15:40

Merci pour vos retours, ça m’aide à clarifier ce que je veux améliorer !

@Mirabellette Je suis à la croisée des chemins en fait.

Soit je mise sur des containers autonomes que je sauvegarde intégralement et régulièrement ; Proxmox permet de faire cela à chaud et je pourrais monter les 100 Go de FTP avec curlftpfs comme espace de sauvegarde distant. Dans cette option, le fait d’avoir installé mes containers à la mano n’est pas grave car si je dois migrer vers un nouveau serveur je copie mes sauvegardes de containers. Par contre, pour avoir un environnement local de test pour mes microservices, je n’ai pas vraiment de solution automatisée.

Soit je le fais à la Docker. Je pars d’un container générique et j’automatise son installation avec Ansible (ou autre tu sembles dire qu’il y a mieux? ) et j’externalise données et configuration par des partages vers l’hôte.

Jonathan - 2018-05-21 11:09:19

Je connais proxomox juste pour l’avoir installé une fois, mais j’utilise les conteneurs lxc sous debian depuis quelques mois maintenant. Je voulais simplement suggérer pour la sauvegarde des conteneurs: tar gz. J’utilise tar avec la commande -I pigz (pigz, qui permet d’utiliser tous les coeurs du processeur) et c’est vraiment bluffant. Maintenant, comme dit plus haut, je ne sais pas si c’est transposable à proxmox mais ça permet de gagner de la place à la sauvegarde. Jo

Geckeon - 2018-05-21 13:50:52

Salut à tous, j’utilise aussi Proxmox pour mes services et j’ai aussi choisi les conteneurs LXC.
J’ai un peu la même problématique que toi concernant les sauvegardes et la récupération des données.
J’ai pensé dans un premier temps utiliser l’hôte pour le partage des données et de la configuration, mais il pourrait être intéressant de le faire depuis conteneur dans lequel il y aurait toutes les données partager en NFS, par exemple.
Qu’en pensez-vous ?

Mirabellette - 2018-05-22 06:25:40

@Yax Pour l’environnement local de test pour microservice, tu peux installer lxc sur ton desktop personnel avec la même configuration que celle de ton serveur. Après, LXC c’est pas vraiment des microservices, c’est plus gros.

Je ne sais pas si c’est mieux, je connais pas vraiment l’alternative Ansible avec comme critère une maintenance sur plusieurs années. Ce que j’ai lu par contre c’est que les playsbooks pouvaient changer de syntaxe ce qui t’oblige à refaire tous tes books en cas d’upgrade majeure. A toi de voir et de faire des recherches.

@Geckeon Le partage de configuration créé un lien de dépendance entre le containeur et celui qui possède la configuration. Est-ce que le jeu en vaut la chandelle ? Perdre l’indépendance du conteneur au profil du facilitation de l’administration ?

Personnellement je fais sans et ça marche plutôt bien. Dans le cas où je veux propager de la conf partout, tu peux faire un script pour la copier dans tous les conteneurs de ton choix.

Yann - 2018-05-22 17:07:07

Kubernetes ? Ce sera certainement un peu fastidieux de créer tous les manifests pour Kubernetes mais cela permettra de restaurer facilement toute l’infra. Avec une utilisation judicieuse des volumes, les sauvegardes seront également facilitées. Il reste que l’investissement initial est un peu conséquent.

Yax - 2018-05-23 13:25:20

@Geckeon je suis partagé entre pousser ce genre de solution et migrer certains conntainers légers vers Docker

@Mirabellette Merci pour la pertinence de tes retours, ça a fait mûrir ma réflexion. Je ne suis pas Google, c’est de l’auto-hébergement, je pense que je vais continuer un bout avec LXC et utiliser Ansible pour automatiser l’installation de certains containers afin d’avoir mon environnement LXC de test sur le Desktop.

@Yann j’ai pas dépassé docker file et docker-compose dans mon auto-formation sur l’écosystème Docker, donc je ne mesure pas l’effort pour aller au bout d’une solution complète avec supervision, sauvegarde des données et mise à jour maîtrisée des images Docker.

Mirabellette - 2018-05-24 08:43:14

@Yax Avec plaisir :)

Je suis content d’avoir pu t’aider à murir ta réflexion.

Bonne journée à toi

Angristan - 2018-06-21 04:07:28

Quand j’ai découvert LXC je me suis fait plaisir en faisant plein de conteneurs. En suite j’ai réalisé que ça serrait impossible à maintenir proprement. J’ai donc pensé à reporter tout ça dans ansible, mais étant donné la quantité de services, c’était juste pas possible.

Au final, je suis parti sur Docker qui résout complètement cette problématique, surtout lié à docker-compose.

Yax - 2018-06-21 13:23:42

J’ai commencé à automatiser un peu avec Ansible mais j’ai stoppé pour différentes raisons :

  • Je connais déjà bien Ansible et mon hébergement est un loisir. Or là ça ne m’amuse pas et je n’apprends rien.
  • Mes containers étaient trop monolithiques : j’ai commencé à les éclater en plus petits, puis partager les confs et les données avec le hôte avec des points de montge, bref à faire du docker-like.

Du coup j’ai pris le problème dans l’autre sens. Au lieu de chercher un moyen de me créer un environnement de test conforme à mon environnent hébergé, j’ai fait table rase et j’ai créé mes images puis mes containers et mon docker compose pour obtenir un environnement de test (5 containers dont Hugo, des microservices, RabbitMQ). Je suis rôdé sur les bonnes manières de mettre à jour les images et les containers, des volumes me permettent de fonctionner en mode dev.

Bref l’approche me convient et il ne sera pas très difficile de pondre un docker compose pour l’environnement de production. Ce qui me retient pour l’instant c’est que je suis plongé dans le vaste écosystème autour de Docker et que je me tâte pour voir ce qui est le plus adapté sur le serveur pour mon profil hébergement personnel :

  • je peux juste faire un docker compose (et même me permettre de reconstruire les images sur le serveur) et ajouter Portainer pour garder un oeil par une interface Web. Mais pas d’alerte, pas de relancer automatique en cas de problème… après c’est pas forcément grave pour un hébergement personnel…
  • creuser docker stack et/ou pour dégainer la grosse artillerie : swarm ou K8 (sur un cluster d’un seul noeud)

C’est en réflexion…

Votre commentaire
Le site Web est optionel
Le message peut être rédigé au format Markdown