L’auto-hébergement, sur le papier, c’est formidable. On garde ses données chez soi, on contrôle ses services et on ne dépend pas d’une plateforme qui peut doubler ses tarifs ou supprimer une fonctionnalité du jour au lendemain. Dans la pratique, cela signifie aussi passer son dimanche à comprendre pourquoi un conteneur ne démarre plus alors qu’on n’a, bien entendu, absolument rien touché.
Seelf essaie justement de rendre tout cela un peu moins pénible. Son objectif est assez simple : prendre une application qui fonctionne déjà avec Docker Compose et permettre de la déployer sur son propre serveur depuis une interface Web.
Ce n’est pas révolutionnaire et c’est probablement une bonne nouvelle. Seelf ne cherche pas à inventer une nouvelle manière de lancer des conteneurs. Il met simplement une interface et quelques automatismes autour d’outils que beaucoup utilisent déjà.
Seelf, c’est quoi au juste ?
Seelf est une plateforme de déploiement open source et auto-hébergée. Elle s’appuie actuellement sur Docker et Docker Compose pour installer des applications sur une machine locale ou sur un serveur distant.
L’idée est de partir d’un fichier compose.yml existant. S’il fonctionne déjà sur votre poste ou votre serveur, il y a de bonnes chances que Seelf puisse l’utiliser presque tel quel. La plateforme se charge ensuite de créer les conteneurs, d’exposer les services et de suivre le déploiement.
On est donc quelque part entre le bon vieux docker compose up -d lancé en SSH et les plateformes beaucoup plus complètes comme Kubernetes. Pour quelques applications personnelles ou professionnelles, c’est souvent exactement l’espace qu’il faut occuper.
Parce que Kubernetes, c’est très bien. Mais lorsqu’on veut simplement mettre en ligne trois applications sur un serveur, installer un cluster complet revient parfois à acheter une pelleteuse pour planter un géranium.
Comment ça fonctionne ?
Seelf ne demande pas d’apprendre un format de configuration spécial. Il travaille avec un fichier Docker Compose classique, comme celui-ci :
services:
app:
image: ghcr.io/mon-organisation/mon-application:latest
ports:
- "3000:3000"
environment:
DATABASE_URL: postgres://user:pass@db:5432/mabase
volumes:
- /chemin/sur/hote:/chemin/dans/conteneur
Dans l’interface, on commence par ajouter une cible. Il s’agit simplement de la machine sur laquelle les applications seront déployées. Cela peut être le serveur qui héberge Seelf ou une autre machine distante.
On crée ensuite une application, on lui fournit son projet ou sa configuration Compose, puis on lance le déploiement. Seelf affiche les journaux d’exécution, ce qui évite d’avoir à ouvrir une session SSH au moindre problème. On finira probablement quand même par le faire un jour, mais au moins ce n’est plus la première étape obligatoire.
Seelf peut également se connecter à un dépôt Git. On retrouve ainsi un fonctionnement assez logique : le code et la configuration restent dans le dépôt, tandis que la plateforme s’occupe de leur déploiement.
Domaines, HTTPS et Traefik
L’un des points intéressants de Seelf est qu’il ne se contente pas de lancer les conteneurs. Lors de la configuration d’une cible, il installe notamment un proxy Traefik chargé d’exposer les applications sur leurs domaines respectifs.
Si l’adresse de la cible utilise HTTPS, Seelf peut aussi demander et renouveler automatiquement les certificats. C’est une bonne chose, car configurer manuellement un reverse proxy et des certificats pour chaque petite application finit rapidement par devenir une corvée.
Il faudra tout de même configurer correctement le DNS et faire pointer les domaines vers le serveur. Seelf simplifie le travail, mais il ne peut pas réparer un enregistrement DNS envoyé vers la mauvaise adresse IP. Il a ses limites, le pauvre.
Ce que Seelf ne fera pas à votre place
Seelf rend le déploiement plus agréable, mais il ne supprime pas les contraintes de l’auto-hébergement. Il faut toujours maintenir le serveur, installer les mises à jour, surveiller l’espace disque et surtout organiser les sauvegardes.
Il faut également conserver quelques connaissances de base sur Docker. Quand une image n’existe plus, qu’un volume possède de mauvaises permissions ou qu’un service écoute uniquement sur localhost, aucune interface ne peut totalement masquer le problème.
La plateforme n’a pas non plus pour ambition de remplacer un orchestrateur complet. Si votre infrastructure exige des déploiements progressifs, de la haute disponibilité sur plusieurs nœuds ou des dizaines de services répartis sur plusieurs environnements, Seelf risque de devenir rapidement trop limité.
Mais si vous en êtes déjà à discuter de stratégies canary et de clusters multirégions, vous n’attendiez probablement pas qu’un article vous conseille Seelf.
À qui peut-il vraiment servir ?
Seelf semble surtout intéressant pour les développeurs indépendants, les petites équipes et les amateurs de homelab. Autrement dit, les personnes qui possèdent un ou plusieurs serveurs, utilisent déjà Docker Compose et commencent à en avoir assez de tout administrer à la main.
Il peut aussi convenir à une petite infrastructure interne. Une application métier, un outil de documentation, un service de supervision ou quelques projets de test n’ont pas toujours besoin d’une plateforme d’orchestration gigantesque. Dans ces cas-là, une solution lisible et suffisamment simple à maintenir est souvent préférable.
En revanche, Seelf n’est pas destiné à quelqu’un qui souhaite cliquer sur un bouton sans jamais se demander ce qu’est un conteneur. L’interface facilite les opérations courantes, mais Docker reste bien présent derrière le rideau.
Alors, Seelf vaut-il le coup ?
Oui, à condition de bien comprendre ce qu’il propose. Seelf n’est pas un nouveau Kubernetes et il ne transformera pas votre vieux serveur en plateforme cloud mondiale. Il permet surtout de déployer plus proprement des applications Docker Compose sans répéter les mêmes manipulations pour chaque projet.
Son approche a quelque chose d’assez raisonnable : partir de fichiers Compose standards, automatiser l’exposition des services, gérer les certificats et proposer une interface pour suivre les déploiements. Pas de concept révolutionnaire, pas de nouveau langage à apprendre et pas besoin d’un cluster de six machines pour afficher un blog et deux outils internes.
Pour un homelab ou un petit serveur, Seelf peut donc devenir un intermédiaire pratique entre la ligne de commande et les grosses plateformes de déploiement. Il ne supprimera pas toutes les soirées de dépannage, mais s’il peut en éviter quelques-unes, ce sera déjà pas mal.