Dois-je réinventer la roue pour mon auto-hébergement?

Café du commerce
1

Bonjour,

J’aimerais auto-héberger différents services comme mastodon, pixelfed, mobilizon etc. Je vise une base de minimum 200 utilisateurs. J’aimerais que cette ferme de logiciels libres soit accesible avec un oauth2 comme keycloak pour éviter de se connecter à tous les services à chaque fois.

Au delà, de l’aspect technique de ma demande sur lequel je ne connais pas encore sa pertinence, j’aimerais que cet écosystème d’auto-hébergement puisse monter en charge si besoin.

Mes connaissances en auto-hébergement se limitent à Docker et Linux mais je suis loin d’être un expert.

Par contre, je me suis rendu compte que chaque évolution de version d’un logiciel peut nécessiter à minima une mise à jour du schéma de la base de données et peut-être d’autres choses encore que je n’ai pas notées …

Alors je me suis demandé si les Chatons qui se retrouvent souvent avec les mêmes solutions logiciels libres à héberger, auraient un ou des repos avec tout le code qu’ils écrivent (si il y en a) pour gérer les spécificités de chaque logiciel libre utilisé et si il est possible d’avoir un modèle d’architecture facilement téléchargeable et adaptable sans se lancer dans des dévs longues et parfois complexes tout en fournissant un service complet de mise à jour des produits quand nécessaire ?

Je ne sais pas du tout comment cette demande va être perçue. Si c’est inapproprié, je m’en excuse dès maintenant. Sinon je serai curieux de savoir si c’est une réflexion qui a pu déjà voir le jour chez vous pour favoriser l’émergence de chatons ou simplement des auto-hébergement par des associations qui disposent d’un peu de connaissances sur le sujet ?

Merci pour votre accueil et votre parole,

2

Bonjour,

Tes besoins ressemblent beacoup à ce que la distribution yunohost.org (Why You No Host), basée sur debian propose.
Une bonne partie des petits CHATONS (dont le mien) repose sur cette distribution qui permet, en vrac de :

  • installer un serveur en une ligne de commande
  • installer en un clic via l’interface web un ribambelle de services
  • maintenir à jour en 1 clic
  • gerer les zones DNS (automatiquement si OVH, et proposition de texte si autre
  • fournir un SSO pour la grande majorité des services
  • et plein d’autre chose
    La comu est majoritairement franophone et le forum permet de se débloquer en cas de pepin.
3

Installer YunoHost est effectivement dans ma todo liste (je suis en train). D’après la doc, il faut mettre en production YunoHost qui si on a confiance dans les utilisateurs et je trouve à titre personnel cette remarque pas très rassurante (en tout cas, c’est dissuasif) mais il y a peut-être des subtilités qui m’échappent.

La question que 'ai posée concerne aussi sur des configurations plus sérieuses comme celle de Framasoft et j’imagine d’autres chatons du collectif. (Enfin c’est ma vision extérieure à tout ça, je ne sais pas ce qu’il en est réellement).

Merci pour vos retours instructifs.

4

YunoHost et chatons

YunoHost est à l’origine une distribution qui était faite pour l’auto-hébergement personnel, mais au fur et à mesure des années elle s’étend de plus en plus à des cas d’usage autour de « petites et moyennes communautés ». Les chatons sont clairement dans l’esprit des contributeurices et il y a clairement une direction dédiée au cas d’usage chatons & co.

Néanmoins, l’avertissement est là pour une bonne raison, car par défaut, les apps sont quand même plutôt réglées pour le cas d’usage d’héberger sa famille ou ses ami⋅es.

Les réglages par défaut de certaines apps peuvent donc être à revoir si on ne veut pas que chaque compte puisse découvrir la liste des autres comptes par exemple.

De même, certaines permissions sont à proscrire si il n’y a pas de confiance dans l’utilisateurice, typiquement, les permissions SSH ou SFTP. Mais dans l’absolu, à ce stade de développement de YunoHost, même la permission mail (sans retouche) peut être un soucis si une des personnes cherchent à abuser du service en envoyant plein de mail.

Pour le moment, l’adoption par des communautés trop large est freinée par la non présence d’un formulaire de renouvellement de mot de passe, mais c’est sur la feuille de route. Ca n’empêche pas certains setup d’atteindre le milliers de comptes sur certaines apps OU quelques centaines de compte YunoHost (SSO)… YunoHost 12.1 (testing) relève notamment le nombre de compte YunoHost possible en supprimant un soucis de performance dans les insertions ldap.

Je dirais aussi que YunoHost n’est pas le seul outils à prendre en compte, Mobilizon par exemple a déjà eu son connecteur LDAP cassé pendant plusieurs mois. Dans une démarche hors YunoHost, je suis pas sûr que toutes les apps du fediverse citées puissent faire de l’oAuth.

Les git des chatons

Les chatons sont censés publier des infos sur la façon dont sont déployés leurs solutions, il n’est pas censé y avoir de code propriétaire (sauf exceptions). Bref, les setup sont donc logiquement répétables.

Beaucoup de chatons n’ont pas mis d’authentification centralisée (car c’est pas simple à faire). Sauf erreur de ma part Frama n’en a pas (par choix d’après leurs anciens billets, Frama est plutôt sur un créneau avec des services publics bien séparés, sur des ndd distincts, etc.). Je sais que @lacontrevoix et @sleto ont fait des choses sur ce sujet, probablement @IndieHosters aussi…

5

ljf Merci bcp pour cette mine d’or d’informations qui me donne un horizon moins vague sur l’ampleur de la tâche à réaliser.

Le but à terme est de déployer des associations. Chaque asso est une communauté de membres qui peut atteindre entre 200 et 250 personnes (au delà, ça devient moins humain et surtout plus compliqué à gérer).

Le problème sur les mails est grave en effet … Et ça pourrait être bloquant surtout si il n’y a pas de flag pour empêcher l’envoi de mails par certains comptes.

Le fait de connaître les autres membres au sein d’une communauté n’est pas forcément bloquant car ça peut être une bonne chose porur favoriser les rapprochements. Si un outil peut être paramétré pour diffuser les contacts (avec une carte du genre prénom, trois premières lettres du nom + compte Matrix, Signal, Sessions, Telegram etc.), ce serait super en fait !

Les demandes d’amis sont gérés par les messageries et voilà !

Dans l’idéal, il faudrait résoudre les problèmes identifiés sur la sécurité dans l’utilisation de YunoHost sur des déploiements sur le web et proposer des bots de surveillance pour bloquer ou à minima avertir les admins des actions litigieuses.

@isAAAc
++

1 Like
6

Ben tu peux empêcher l’envoi de mail (en retirant la permission) et tu peux déployer l’app rspamd_ynh. ET de façon général, tu peux intégrer toi même la protection que tu souhaites en fonction de ton cas d’usage. SI c’est faisable sur debian, c’est faisable sur YunoHost en général.

Si ton yunohost envoie trop de mail, tu es avertis par le diagnostique yunohost (2x/jour) que ta queue d’email est pleine (car les serveur smtp destinataires vont refuser en quelques heures les mails). Mais, l’idéal ce serait d’avoir un mécanisme préventif.

2 Likes
7

Bonjour,

Le code de notre infra est dispo ici:

Il faut un peu connaitre kubernetes, on a une formation ici:
https://k8s.libre.sh/training/

Je suis prêt a t’aider a naviguer notre code, en mode documentation croisée :smiley:

L’objectif de libre.sh est de proposer un espèce de yunohost scalable sur k8s. Mais la.doc n’est.pas encore au.niveau de yunohost, comme le code d’ailleurs.

Voilà tout! Une bonne journee!

8

J’ai parcouru la doc avec perplexity AI … Désolé !

Libre.sh présente une vision de Kubernetes comme une distribution visant à héberger des logiciels libres pour les utilisateurs et les organisations à grande échelle1. Ils considèrent Kubernetes comme la base d’une infrastructure modulaire et opinionnée, comparable à Debian pour les distributions Kubernetes ou à un YunoHost distribué.

Les principales raisons avancées par libre.sh pour utiliser Kubernetes plutôt que YunoHost sont :

  1. Scalabilité : Kubernetes permet de gérer des centaines d’instances de logiciels libres, ce qui est plus difficile avec YunoHost
  2. Haute disponibilité : Kubernetes offre une meilleure gestion de la haute disponibilité, même pour une seule instance d’application
  3. Flexibilité : L’approche basée sur les opérateurs de Kubernetes permet une meilleure organisation et automatisation du cluster
  4. Évolutivité : Kubernetes facilite le passage à l’échelle du cloud public si nécessaire.

Cependant, libre.sh reconnaît certaines difficultés :

  1. Complexité : Kubernetes est plus complexe que YunoHost, ce qui peut être un défi pour les utilisateurs moins expérimentés.
  2. Stabilité : Bien que Kubernetes soit stable, la multiplicité des variables (matériel, versions, réseau, etc.) peut entraîner des problèmes d’instabilité
  3. Garantie de service : La complexité de l’écosystème Kubernetes rend difficile la garantie d’un service stable pour l’utilisateur moyen

Ces difficultés affectent les utilisateurs de plusieurs manières :

  1. Courbe d’apprentissage : Les utilisateurs doivent investir plus de temps pour maîtriser Kubernetes par rapport à YunoHost
  2. Problèmes techniques : Les utilisateurs peuvent rencontrer des problèmes comme des bases de données corrompues ou des serveurs à réinstaller
  3. Temps de résolution : Les problèmes peuvent prendre beaucoup de temps à résoudre, ce qui peut être frustrant pour les utilisateurs

En conclusion, bien que libre.sh voie Kubernetes comme une solution puissante pour l’hébergement de logiciels libres à grande échelle, ils reconnaissent que cette approche n’est pas adaptée à tous les utilisateurs, en particulier ceux qui recherchent une solution simple pour l’auto-hébergement à petite échelle.

Même si je comprends bien l’intérêt d’utiliser Kubernetes à terme pour moi ou nous, plusieurs choses me chiffonnent :

  • C’est un produit open source ? dont Google est à la base mais c’est devenu un standard de l’industrie cloud alors a-t-on vraiment le choix ? (On peut pas réinventer la roue ? Si ?)
  • La résolution de problème est réputée difficile ou nécessitant un niveau avancé de compétences … Avons-nous déjà ce genre de ressources en nombre ? Combien de temps de formation est nécessaire à l’émergence de compétences adaptés à la gestion de parc k8s ?
  • Depuis combien de temps, travaillez-vous sur ce projet en dev ? Est-il en prod ? Avez-vous un ou des parcs aux dimensions de ce qu’est capable de fournir K8s ?
9

J’hésite à poser la question mais bon. J’en ai juste entendu parlé et je ne sais pas ce que ça vaut.

Ce que j’ai retenu, c’est que l’installation de cet OS ou des mises à jour étaient programmables et prédictibles.

Je crois que ça s’appelle NixOS ? Est-ce qu’il y a des experts sur ce sujet et est-ce que ça pourrait avoir un intérêt avec K8s, Docker pour des architectures plus complexes ?

++

10

Et voici ce qu’en penses l’industrie selon Perplexity AI !

L’industrie a une opinion généralement positive de Kubernetes (K8s), le considérant comme un outil puissant et flexible pour l’orchestration de conteneurs et la gestion d’applications à grande échelle. Voici un aperçu des principaux avantages reconnus par l’industrie :

Haute disponibilité : Kubernetes maintient la continuité opérationnelle des applications en orchestrant la redondance des conteneurs, assurant un basculement automatique en cas d’incident.

Équilibrage de charge : K8s optimise la distribution des requêtes utilisateur à travers plusieurs instances, garantissant une répartition équilibrée de la charge et le maintien de performances optimales.

Gestion efficace des ressources : Kubernetes optimise l’allocation en exécutant les conteneurs sur les hôtes de manière efficace.

Scalabilité : L’outil permet de dimensionner les applications en réponse aux fluctuations de demande sans intervention manuelle, idéal pour les applications ayant des exigences de performance élevées et variables.

Gestion du déploiement : Kubernetes facilite les mises à jour progressives et les retours en arrière automatiques, simplifiant ainsi les mises à jour sans interruption de services.

Sécurité améliorée : K8s permet de gérer de manière plus sécurisée les données et autres configurations sensibles, réduisant les risques liés à la sécurité des applications.

Automatisation de l’orchestration : Kubernetes automatise les processus manuels impliqués dans le déploiement, la mise à échelle et l’administration des applications conteneurisées, simplifiant les opérations et réduisant le potentiel d’erreur humaine.

Flexibilité et portabilité : Il permet de déployer les applications sur différents types d’environnements, que ce soit sur des clouds publics, privés, ou hybrides.

Cependant, l’industrie reconnaît également certains défis liés à l’utilisation de Kubernetes :

Complexité : La courbe d’apprentissage de Kubernetes peut être raide, en particulier pour les équipes moins expérimentées en matière de conteneurisation et d’orchestration.

Ressources nécessaires : La mise en place et la maintenance d’un cluster Kubernetes peuvent nécessiter des ressources importantes, tant en termes de matériel que d’expertise.

En conclusion, bien que Kubernetes soit largement adopté et apprécié dans l’industrie pour sa puissance et sa flexibilité, son utilisation nécessite une réflexion approfondie sur les besoins spécifiques de chaque organisation et les ressources disponibles pour sa mise en œuvre et sa gestion.

11

Un GT Chatons (SM2TP : GT mutualisation SMTP) travail justement à imaginer un outil trop chouette pour gérer l’envoi massif d’email.

1 Like
12

Un GT Chatons (SM2TP : GT mutualisation SMTP) travail justement à imaginer un outil trop chouette pour gérer l’envoi massif d’email.

J’en ai entendu parlé sur l’émission podcast d’APRIL sur paheko mais j’avais pas le point de contact. Merci !

13

installer YunoHost est effectivement dans ma todo liste

[…]

YunoHost est à l’origine une distribution qui était faite pour l’auto-hébergement
en complément:
c’est aussi car c’est pas du pro, c’est à dire que des issues soit sur ynh directement, ou sur des applis portées/packagées *_ynh peuvent avoir du retard au regard de l’appli mère, et ou avoir leur propre issues qui ne seront pas forcément traitées en urgence, car ça dépend de « main d’oeuvre » qui officie sur son temps libre,
donc dans un cas pro ou de gros collectif, ça peut poser pb si on dépend clairement des mainteneurs.

Ceci étant dit,
j’utilise ynh en production depuis de longues années sans gros problème majeur, faut être sûr de ses backups et être certain de pouvoir restorer en cas de besoin,
et d’une amnière générale, et là , c’st de l’hygiène informatique:
si c’est sensible, c’est backupé à plusieurs endroits indépendants les uns des autres :wink:

1 Like
14

pour info à tout le monde, je rajoute qu’il y a alternc qui est pas mal aussi:

https://aide.alternc.org (la 3.5 bookworm est sur le point de sortir pour de bon, elle est en test au taf et ça marche plutôt pas mal du tout )

on évite pas mal une bonne partie des pbs des applis packages , mais il n’y a pas de solution sans inconvénient

1 Like
15

Hello

Je confirme AlternC c’est bien :slight_smile: Mais clairement je suis parti pris sur ce projet.
@isAAAc a donné le pointeur intéressant. Les autres sites de la galaxie ne sont pas encore à jour, on finalise la version stable avant.

Ne pas hésiter à bipper pour toute question à son propos.

1 Like
16

Nous utilisons Docker plutôt que Kubernetes…

Voici un article et un petit fascicule qui présente les services essentiels à intégrer pour maximiser l’indépendance numérique et rejoindre notre coopérative des auto-hébergeurs relié en toile de confiance.

@elloh es-tu à l’aise en bash ? Quel matériel vas-tu utiliser pour devenir auto-hébergeur?

17

@elloh es-tu à l’aise en bash ? Quel matériel vas-tu utiliser pour devenir auto-hébergeur?

A court terme, nos besoins sont modestes …

Voici mon plan d’action :

  • constituer une équipe de développeur réguliers
  • m’appuyer sur un chatons pour l’hébergement de notre serveur de DEV
  • découvrir, apprécier, critiquer YunoHost en tant que système devant accueillir lorsqu’il sera en production chez nous des communautés associatives.

Je prévois lors du passage en production de m’appuyer sur un chatons qui me permette d’augmenter le nombre de serveur hébergés pour suivre l’évolution dans le déploiement du produit réalisé.

Mais on en est pas là encore. En ce qui concerne les conteneurs applicatifs plutôt que des conteneurs système (ou les deux), je n’ai pas d’avis tranché sur le sujet. Mon expérience en la matière se limite au DEV.

Mais si l’utilisation de conteneur applicatif nécessite des connaissances techniques avancées et qu’on ne dispose pas des ressources nécessaires pour héberger à terme plusieurs dizaines voir plus d’associations sur le produit développé … Le risque est d’avoir un frein important au déploiement de la solution.

Ce sont des considérations qui doivent être prises en compte dès le départ.

EDIT:
Concernant le bash, je le pratique régulièrement en ligne de commande (et peu importe le langage avec l’IA on a plus d’excuses …).

18

NixOS c’est vraiment super, quelques CHATONS l’utilisent (DeuxFleurs, Immae, et moi aussi sur mon infra perso).
Mais c’est très complexe, vraiment pas facile à apprendre. Faut compter quelques mois pour savoir faire des trucs simples ou quelques années pour vraiment maîtriser la techno quand on s’y connait pas spécialement

19

Merci @ppom , je crois qu’on a déjà échangé ensemble peut-être même sur Paris dans un café mais je suis plus sûr du pseudo.

Pourquoi ce temps de formation de quelques années, il y a des concepts nouveaux ? Les lignes de commandes sont à rallonges ? Ça pique ma curiosité !

Et en fonction de ton expérience sur le sujet, que peux-tu dire sur la solution NixOs dans le contexte des chatons ? A-t-il révolutionné ta productivité en fournissant un service que tu ne retrouves pas ailleurs dans les distributions linux standards à base de packages deb ou même dans yunohost ?

Merci pour ton retour d’expérience

20

Je me permets de répondre avec Perplexity AI :

NixOS présente plusieurs avantages significatifs par rapport à Debian classique ou YunoHost pour le déploiement d’applications, la conteneurisation et le déploiement cloud :

Reproductibilité et fiabilité

NixOS garantit une reproductibilité totale des configurations système et des déploiements d’applications37. Contrairement à Debian, où les mises à jour peuvent parfois causer des incompatibilités, NixOS permet de revenir facilement à des versions antérieures du système ou des applications sans risque de corruption19.

Gestion déclarative

La configuration entière du système se fait via un fichier déclaratif unique, ce qui simplifie grandement la gestion et la maintenance du système par rapport à Debian ou YunoHost5. Cette approche permet une meilleure reproductibilité et facilite l’automatisation des déploiements.

Isolation et conteneurisation avancées

NixOS offre des capacités de conteneurisation natives plus avancées que Debian :

  • Possibilité de créer des conteneurs légers natifs sans Docker6
  • Isolation fine des applications et de leurs dépendances7
  • Cohabitation de plusieurs versions d’une même application ou bibliothèque sans conflit3

Déploiement cloud optimisé

Pour le déploiement cloud, NixOS présente plusieurs avantages :

  • Création d’images Docker optimisées et reproductibles directement depuis la configuration NixOS2
  • Déploiement automatisé via Terraform avec des outils comme nixos-infect4
  • Gestion déclarative des conteneurs et de leur orchestration6

Mises à jour atomiques et rollback

NixOS permet des mises à jour atomiques du système et des applications, avec la possibilité de revenir instantanément à un état précédent en cas de problème19. Cette fonctionnalité n’existe pas nativement dans Debian ou YunoHost.

En conclusion, NixOS offre une approche plus robuste, reproductible et flexible pour le déploiement d’applications et la gestion de systèmes, particulièrement adaptée aux environnements cloud et aux infrastructures complexes.