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

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.

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.

@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.

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

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.

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

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 ?

@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.

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.

@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.

@Yax Avec plaisir :)

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

Bonne journée à toi

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.

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...