J’aimerai partager avec vous amélioration que j’aimerais bien voir arriver sur Yunohost.
Je n’ai aucune idée de sa faisabilité ni des difficultés qu’elle représente. Je préfère donc en parler avec vous ici plutôt que d’ouvrir un ticket sur github.
C’est une idée que j’ai depuis longtemps mais qui prend encore plus son sens ce matin avec l’arrivée du RasPi 4 et de son option de RAM (1,2 voir 4 Go).
Souvent, nous ne possédons qu’une seule IPv4 à la maison. Nous ne pouvons donc ouvrir les ports 80, 443 etc de son routeur que vers une seule machine, un seul serveur Yunohost.
Ainsi, si la machine avec laquelle on démarre son projet d’auto-hébergement devient trop faible pour ses besoins, il est nécessaire d’en changer le jour où de plus gros besoin se font sentir (on jette l’ancien Raspi?).
Typiquement, quelqu’un qui commence sur un Raspi 2 ou 3 voudrait aujourd’hui changer pour un Raspi 4. Son ancien Raspi devient alors inutile et c’est bien dommage…
Ou alors simplement, quelqu’un qui a un raspi qui fonctionne bien avec plusieurs services et qui voudrait en ajouter un autre qui demande beaucoup de ressources (synapse par exemple). Il n’aurait besoin que d’acheter un second Raspi dédié à cette application, mais se poserait alors la question de l’IPv4, des ports, du certificat SSL…
Ainsi je vous soumets l’idée d’un réseau local de Yunohosts.
Imaginons qu’on puisse installer un Yunohost principal (maître) qui puisse reconnaître, identifier sur le réseau local des yunohosts secondaires (esclaves) qu’il pourrait gérer [depuis sa propre interface d’admin].
Je vous donne un exemple.
Quelqu’un décide de s’auto-hérberger. Il achète un Raspi et installe Yunohost. A l’installation, on lui dit que si c’est son premier yunohost à la maison (option par défaut), il doit installer la version yunohost maître. Ça installe le yunohost qu’on connaît bien. Il installe les services qui lui vont bien pour le moment.
Un an passe et il aimerait alors installer un cloud ou bien synapse mais son Raspi est trop limité. Il en achète un autre qu’il va dédier à ce service.
Lors de l’installation de ce yunohost, il installe la version esclave de yunohost cette fois. A la fin de cette installation, il a un identifiant et mot de passe qu’il est invité à enregistrer, avec l’ip local de ce yunohost esclave, dans l’interface admin de son yunohost maître.
Et c’est ensuite à partir de son yunohost maître qu’il va pouvoir installer son cloud (ou synapse…) sur son yunohost esclave. C’est le yunohost maître qui gère le yunohost secondaire, ses noms de domaines (Nginx c’est ça?), ses utilisateurs (LDAP, donc les mêmes que sur le maître), ses applications… Le yunohost esclave est donc plus léger et peut donc être dédié pleinement à l’application qu’il héberge.
Le yunohost maître indiquerait aussi les DNS qu’il faut renseigner chez son registar pour ses propres applications mais aussi toutes celles de son réseau de yunohost esclave. Les ports à ouvrir dans son routeur seraient tous vers le yunohost maître qui lui s’occuperait de renvoyer vers le bon yunohost du réseau (lui même ou un esclave).
Le yunohost maître aussi gérerait les sauvegardes de tous son réseau local (en local sur HDD externe ou bien par internet chez un ami…).
Ce système offrirait une vraie modularité des petits serveurs du type RasPi pour l’auto-hébergement et permettrait ainsi de résoudre le problème environnemental des serveurs auto-hébergés sur-dimensionnés, sous-utilisés puisque ainsi, au lieu de prendre trop gros pour prévenir des besoins futurs, il suffirait de commencer petit (pour ses besoins du moment) et de rajouter d’autres petits serveurs en cas de besoin seulement.
Vous en pensez quoi? C’est une bonne idée? Est-ce que ça vous semble réalisable? Difficile? Devrais-je ouvrir un ticket sur Github?
) pour tester des apps avant des les mettre en production ! Soit des version beta, soit juste pour voir, soit pour en packager.