Au détour d’un coin de web, je suis tombé par hasard sur un article sur serveur410 demandant des retours d’expérience autour de l’auto-hébergement. L’article de synthèse ayant été publié quelques jours après que j’ai pris connaissance du premier et avant que j’aie eu le temps de commencer à écrire, j’en profite donc pour produire ici un article dédié au sujet et qui me permettra, par la même occasion, de faire un bilan de ses quelques années d’auto-hébergement. Entrons dans le vif du sujet.
Mon aventure de l’auto-hébergement commence en même temps que les prémices d’Unicoda, durant les rencontres mondiales du logiciel libre 2011 à Strasbourg. C’est à ce moment-là que, conférence après conférence, discussion après discussion, atelier après atelier, je prends la décision de me lancer dans l’aventure pour créer mon bout d’internet. Les motivations sont variées, mais le premier objectif est de disposer d’un espace de publication que je contrôle et où les données m’appartiennent. L’autre élément clé de l’histoire: ma soif d’apprendre. Après deux années de classes préparatoires, pendant lesquelles j’ai laissé de côté mon apprentissage de la programmation et mes expériences avec PHP et MySQL, commencés au lycée en autodidacte (l’option informatique en CPGE étant plutôt dédié à la résolution ou l’analyse de problèmes mathématiques avec l’outil informatique, que de la technique informatique), j’ai décidé de m’engager dans un cursus d’ingénieur en informatique, et enfin, plus simplement, le sujet m’intéresse et me passionne.
Il faudra néanmoins attendre début 2012, pour que je pose les premières pierres d’Unicoda. Achat du nom de domaine, location d’un serveur chez RedHerberg (association qui proposait à des formules d’hébergement très accessible financièrement pour débuter), installation et déploiement de WordPress, configuration d’un serveur web, modification de zone DNS, autant d’éléments à apprendre au fur et à mesure.
Dans les années qui suivront, Unicoda migrera vers OVH sur un serveur Kimsufi avec davantage de puissance et de mémoire. Ce serveur me permettra de continuer mes expérimentations: sous-domaines, installation d’Owncloud, mise en place de certificats HTTPS sur l’ensemble des domaines avec StartSSL et test de nombreux services pour construire ce que je désigne comme mon nuage de services auto-hébergés. De nombreux articles témoignent de ces essais et de cet apprentissage progressif et des évolutions de l’ensemble au fil des ans.
Avance rapide quelques années plus tard, je décide de pousser l’expérience plus loin et d’héberger l’ensemble des services chez moi, à l’exception d’Unicoda, qui reste comme service unique sur une machine virtuelle chez OVH, afin de garantir une certaine disponibilité de service et de disposer d’une généreuse bande passante (bien davantage que l’upload de ma connexion ADSL à ce moment là). Je recycle une machine assemblée pendant mes années de lycée et qui sans être très performante, permet de faire fonctionner convenablement les services que j’utilise.
Peu après, je m’intéresse à l’énergie consommée par cette machine et décide que 35 Watts minimum pour une machine majoritairement en mode idle est un peu trop élevé à mon goût (bien que ridicule par rapport à la consommation de mon PC fixe en utilisation). Je migre donc l’ensemble vers un Pi 3, ordinateur de poche consommant 4 à 5 Watts en mode idle, avec des pics de consommation mesurés à 7 Watts sur une période d’un mois. La facture d’électricité s’allège un peu. Je profite de la migration pour mettre en place un Pi 1 remplissant le rôle de passerelle et permettant de faire cohabiter les deux machines, le temps de migrer chaque service l’un après l’autre.
En parallèle, s’ajoute la mise en place d’une sauvegarde automatique, pour éviter d’effectuer le tout à la main périodiquement, d’abord avec duplicity vers hubic, puis duplicity vers Backblaze B2 et enfin, restic vers Backblaze, avec duplicity version allégé en complément de secours. Une fois la sauvegarde en place, j’ai pu me concentrer sur l’écriture de script de déploiement automatique pour être en mesure de redéployer l’ensemble de mes services rapidement et avec peu d’intervention humaine à partir de la sauvegarde journalière. Plus récemment, cette quête de stabilité a vu l’ajout d’un onduleur au système, pour parer aux éventuels problèmes d’alimentation électrique.
Il est clair que décider de s’auto-héberger, c’est faire le choix de passer plusieurs heures par semaines et parfois par jour, pour installer les services, puis les maintenir, les mettre à jour, les protéger et parfois investiguer les problèmes de fonctionnement. Est-ce que cela en vaut la peine… oui ! Et d’autant plus si vous exercez, ou voulez exercer un métier dans le domaine de l’informatique, ou simplement par intérêt ou passion pour le domaine. L’élément le plus chronophage restant la montée de version des services, surtout lorsque celle-ci est effectuée peu après la sortie de la mise à jour. Pour l’anecdote, j’ai en mémoire une soirée complète passée à mettre à jour Gitlab et déboguer la configuration, alors que le but principal était d’écrire quelques lignes de code sur l’un de mes programmes du moment.
En conclusion, il ne faut pas hésiter à se lancer dans l’aventure de l’auto-hébergement, à condition d’être conscient des enjeux et des responsabilités qui viennent avec. Faire simple, commencer petit et surtout disposer du temps et de l’envie d’apprendre !
