Catégorie : Auto-hébergement

Mon petit nuage de service personnel commence à vieillir. Si la mise à jour des différents composants s’effectue généralement sans anicroche, certains d’entre eux consomment bien trop de ressources pour une utilisation mono-utilisateur. Constatant que mon dernier article faisant l’inventaire des services utilisés remonte à déjà deux ans, je me dois d’effectuer un petit rattrapage avant d’aller plus loin.

Voici donc un inventaire des services en septembre 2017 :

• Baïkal : Pour la gestion des contacts et du calendrier.
• Etherpad : Pour de l’édition collaborative.
• FreshRSS : Pour la gestion des flux RSS.
• Gitlab : Pour la gestion de code.
• Seafile : Pour la gestion et le partage de fichiers.
• Shaarli : Pour sauvegarder simplement des urls depuis n’importe quel support.
• Wallabag : Pour la conservation d’article à lire ultérieurement.

La maintenance de deux de ces services : Gitlab, et Seafile dans une moindre mesure, commençaient à devenir de plus en plus lourde. Par ailleurs, l’empreinte mémoire de Gitlab semblait devenir toujours plus importante au fil du temps. Qu’on ne s’y trompe pas, les deux services sont plutôt bons. Gitlab est fantastique, mais n’est plus adapté aux petites configurations, il me semble davantage destiné aux communautés et aux entreprises désormais (ou à ceux qui veulent/peuvent réserver 2Go de mémoire vive à Gitlab). A ces considérations, s’ajoute le défi et l’objectif d’auto-héberger la majorité des services. Pour y arriver, je me suis donc fixé des impératifs en termes de consommations de ressources, dictés par le matériel à ma disposition. Enfin, c’est la décision d’aller vers davantage de simplicité qui prime, en essayant de trouver des composants stables, rapidement déployable et dont la sauvegarde est aisée.

Vous l’aurez compris, j’ai arrêté mes instances de Gitlab et de Seafile. A la place de Gitlab, j’utilise désormais Gitea, fork de gogs, pour une empreinte mémoire largement réduite et des fonctionnalités suffisantes. J’ai remplacé Seafile par Nextcloud; retour aux sources après avoir renoncé à Owncloud il y a deux ans. Au passage, j’en profite donc pour me séparer de Baïkal en utilisant les modules calendrier et contacts de Nextcloud.

J’obtiens donc le découpage suivant :

• FreshRSS : Pour la gestion des flux RSS.
• Gitea: Pour la gestion de code.
• Nextcloud : Pour la gestion de fichiers, les contacts et les calendriers.
• Shaarli : Pour sauvegarder simplement des urls depuis n’importe quel support.
• Wallabag : Pour la conservation d’article à lire ultérieurement.

Voici donc l’état de mon nuage de service à l’automne 2017, quelques changements de services et du changement du côté de l’hébergement. A voir maintenant à l’utilisation si Nextcloud sera à la hauteur. La suite des opérations concerne désormais ce site en particulier, qui migrera à un endroit qui reste encore à définir.

Depuis quelques mois déjà, j’ai tenté l’expérience de l’auto-hébergement pour deux des services que j’utilise. Je ne vais pas m’attarder sur les contraintes de l’hébergement chez soi, d’autres l’ont déjà fait. Si vraiment cela devenait indispensable, cela ferait alors l’objet d’un billet spécifique. L’auto-hébergement donc, étape supplémentaire dans ma quête d’indépendance numérique.

J’ai effectué mes premiers tests avec un Raspberry Pi modèle B de première génération faisant office de serveur. Les résultats sont très positifs. Pas de problème particulier de disponibilité, l’ensemble est stable. J’envisage donc de continuer dans cette direction en migrant davantage de services sur ma propre infrastructure.

C’est là que la question du matériel intervient. Mon Pi, très pratique pour de l’expérimentation limitée, montre quelques faiblesses sur des services plus gourmands en ressources (constaté sur Wallabag notamment). Pour être en mesure d’auto-héberger mes autres services, utiliser une machine plus puissante me semble tout indiqué.

J’ai identifié trois possibilités : utiliser un PI dernier modèle, passer à un mini PC type NUC, BRIX ou enfin, monter une configuration moi-même. Chaque choix a ses avantages et ses inconvénients. En faveur du Pi, je vois la faible consommation électrique et l’encombrement minimal. Un moins peut-être pour le stockage sur carte SD (il est néanmoins possible d’utiliser un disque dur classique). Le coût d’acquisition me semble être le plus faible des trois. Pour la solution médiane du barebone (NUC, BRIX, …)  : coût plus élevé avec nécessité d’acquérir HDD et RAM (type PC portable) en sus. Plus de puissance que le PI, mais plus de consommation électrique aussi. Troisième et dernière solution envisagée, construire une configuration. Comme pour le barebone, plus de puissance, plus de consommation et prix plus élevé, mais davantage de possibilité d’évolution.

La solution Pi 3 est attractive car très simple à mettre en place et ne nécessitant pas un investissement monétaire important. Je m’interroge encore sur la création d’une configuration sur mesure. Je dispose d’une machine vieillissante, vestige de mes premiers essais de serveur domestique, qui date d’une époque où le Raspberry Pi n’existait pas et où on pouvait aller acheter ses composants chez Surcouf. Le CPU est un Dual Core E3400 qui pourrait faire l’affaire. Le problème se situe plutôt du côté de la RAM, puisque la carte mère n’accepte que de la DDR2 800/667 MHz jusqu’à 4 GB total sur 2 slots. Il est heureusement encore possible de trouver ce type de RAM dans le commerce, mais le prix de la DDR2 reste plus élevé que celui de la DDR4 dernière génération, à capacité égale (en termes de mémoire, pas de fréquence).

Je vais donc me tourner vers une solution intermédiaire, en « recyclant » cette machine pour remplacer le Pi 1 utilisé jusqu’à présent. Je resterai sur 1 Go de RAM dans un premier temps et jetterai un coup d’œil du côté de l’occasion pour éventuellement passer à 4 Go à faible coût. De cette manière, je devrais être en mesure de migrer progressivement vers l’auto-hébergement de la majorité des services jusqu’à présent hébergé sur un serveur OVH. Si les performances s’avéraient trop faible, il serait alors possible d’envisager un changement de carte mère, processeur et mémoire RAM, et de réduire au passage la consommation électrique (en supposant que des progrès aient été réalisés dans le domaine de la gestion d’énergie ces dix dernières années).

Il restera néanmoins toujours la limitation du débit montant sur les lignes adsl, qui pourrait remettre en cause la migration de l’un ou l’autre des services. Nous verrons ceci à l’usage. Enfin, reste la question de ce site même, qui n’a pas vocation à être auto-hébergé pour le moment et qui sera donc migré vers un autre service.