Partie 1 — Pourquoi auto-héberger Supabase

#supabase #docker #selfhosting #francais

Partie 1 sur 7 — Supabase en auto-hébergement : retour d'expérience

Version française de Part 1 — I rebuilt Supabase from scratch to understand what I was paying for.

Le niveau gratuit de Supabase offre deux projets actifs : Postgres, authentification, stockage, abonnements temps réel, un tableau de bord. Tout cela gratuitement. Ça fonctionne bien. Le problème, c'est que ça fonctionne si bien qu'on finit par ne plus penser à ce qui se passe vraiment.

Quand on clique sur "Créer un projet", un backend complet apparaît en une trentaine de secondes. On récupère une chaîne de connexion à la base de données, une URL d'API, un jeu de clés. On les colle dans son application et ça marche. C'est pratique, mais c'est aussi une forme d'aveuglement. On ne peut pas raisonner sur un système qu'on ne comprend pas. On ne peut pas en estimer les limites, anticiper ses modes de défaillance ni le déboguer avec assurance. On espère juste que ça continue de fonctionner.

J'utilise Supabase depuis quelques mois et je voulais mieux le comprendre. J'ai donc décidé de reconstruire la même chose depuis zéro sur un serveur bon marché, voir chaque composant, faire toutes les erreurs. Pas pour économiser de l'argent. Le service géré est raisonnablement tarifé, et je le défendrai à la fin de cette série. L'objectif était d'apprendre.

Cette série documente ce parcours.

Ce qu'est Supabase

Supabase n'est pas un programme unique. C'est un assemblage de huit projets open source qui tournent derrière une passerelle API :

PostgreSQL -- la base de données
GoTrue -- serveur d'authentification (inscription, connexion, JWT)
PostgREST -- génère une API REST à partir du schéma Postgres
Realtime -- serveur WebSocket pour les mises à jour en direct de la base de données
Storage -- service d'upload de fichiers avec un backend compatible S3
Kong -- passerelle API qui se place devant tous les services ci-dessus
Studio -- le tableau de bord web
postgres-meta -- fournit l'introspection de schéma utilisée par Studio

Chacun est un processus distinct, dans son propre conteneur, avec sa propre configuration, son propre historique de versions, ses propres bugs. Supabase les assemble, les configure et les opère. Quand on utilise le service géré, tout ce travail est invisible.

Quand on auto-héberge, il devient très visible.

Ce qu'on va construire

À l'issue de cette série, on aura un cluster opérationnel avec deux instances Supabase entièrement isolées sur un seul serveur : HTTPS automatique pour chaque sous-domaine, secrets stockés dans HashiCorp Vault plutôt que dans des fichiers, détection d'intrusion à l'exécution via Falco (un outil basé sur eBPF qui surveille ce qui se passe à l'intérieur des conteneurs au niveau du système d'exploitation), et un test de charge qui montre exactement à quel moment le serveur commence à peiner.

Plus important encore, on aura une image claire de ce que le service géré fait à notre place.

             Internet
                 |
         +---------------+
         |    Traefik    |   TLS, routing
         +-------+-------+
                 |
        +--------+--------+
        |                 |
+---------------+  +---------------+
|   Project 1   |  |   Project 2   |
|  -----------  |  |  -----------  |
|  Kong         |  |  Kong         |
|  GoTrue       |  |  GoTrue       |
|  PostgREST    |  |  PostgREST    |
|  Realtime     |  |  Realtime     |
|  Storage      |  |  Storage      |
|  Studio       |  |  Studio       |
|  Postgres     |  |  Postgres     |
+---------------+  +---------------+

         +---------------+
         |     Vault     |   secrets, localhost only
         +---------------+

À qui s'adresse cette série

Cette série s'adresse aux développeurs qui apprennent en construisant. Il faut être à l'aise avec un terminal. Aucune expérience préalable de Docker Swarm, Vault ou Traefik n'est requise. Tout est expliqué depuis le début.

Comptez plusieurs soirées de travail. J'y ai passé plus de temps que prévu, en partie à cause de mes erreurs (que je documenterai), et en partie parce que chaque composant s'est révélé plus intéressant que je ne le pensais.

Si vous gérez une application en production avec de vrais utilisateurs et de l'argent réel, utilisez le service géré. Compter sur un seul serveur de hobbyiste pour quelque chose d'important n'est pas raisonnable. L'auto-hébergement signifie que c'est vous qui vous réveillez quand quelque chose tombe en panne. Cette série est là pour apprendre, pas pour remplacer un service dont vous dépendez.

Le matériel

Le serveur est un Hetzner CX22 : 2 vCPU, 4 Go de RAM, 40 Go de SSD, situé à Falkenstein, en Allemagne. Il coûte 4,51 EUR par mois.

Hetzner est un hébergeur allemand. Je l'ai choisi pour son coût et parce que la résidence des données dans l'UE est importante si vos utilisateurs sont en Europe.

Le CX22 paraît petit, et pour une offre cloud gérée, il l'est. Mais Supabase en auto-hébergement consomme étonnamment peu de mémoire au repos :

Service	Mémoire au repos
PostgreSQL	~77 Mo
Kong	~229 Mo
GoTrue	~8 Mo
PostgREST	~15 Mo
Realtime	~168 Mo
Studio	~170 Mo
Traefik	~30 Mo
Vault	~140 Mo

Deux instances Supabase complètes tiennent dans environ 2,2 Go. Le serveur dispose de 4 Go.

Ces chiffres ont été mesurés à vide. La partie 7 montre ce qui se passe sous charge.

Lors d'un test de charge réaliste, avec 50 utilisateurs simultanés et un temps de réflexion entre les actions, le CPU de la base de données a culminé à 0,67 %. Le serveur n'avait presque rien à faire.

Mes faux pas

Voici un aperçu des erreurs que cette série documente.

J'ai choisi la mauvaise version de Traefik. Elle n'était pas compatible avec la version de Docker installée. J'ai passé un après-midi à comprendre pourquoi les requêtes n'étaient pas routées avant de trouver la note de compatibilité enfouie dans le changelog.

J'ai déployé le service Realtime avec une clé de chiffrement de mauvaise longueur. Il a planté immédiatement avec une erreur sur la taille de la clé, sans mentionner la longueur attendue.

J'ai utilisé vault kv put là où il fallait utiliser vault kv patch. Résultat : tous mes secrets ont été remplacés par une seule nouvelle clé. Mon mot de passe Postgres est devenu le mot "change_me". Je m'en suis rendu compte quand chaque appel API a commencé à échouer avec des erreurs d'authentification.

J'ai exécuté un test de charge qui semblait échouer sur les lectures. Le problème ne venait pas du serveur. Le test tournait depuis l'Ohio et le serveur est en Allemagne. La latence réseau est bien réelle.

Chaque erreur m'a appris quelque chose sur le fonctionnement du système. Le service Supabase géré gère tous ces cas limites sans qu'on le sache jamais. C'est une partie de ce que le service apporte.

Le bilan honnête

Avant de consacrer un samedi à ça : le niveau gratuit offre déjà deux projets. Pour la plupart des usages personnels, l'auto-hébergement n'apporte pas plus de capacité. Ce qu'il apporte, c'est de la compréhension.

Après avoir construit ce cluster, j'ai une idée plus claire de ce que Supabase fait réellement, pourquoi le plan Pro coûte ce qu'il coûte, et ce à quoi on renonce en choisissant la voie du service géré. Ça valait le temps investi.

Une note avant de commencer : Supabase publie un guide officiel d'auto-hébergement basé sur Docker Compose simple. Cette série utilise Docker Swarm à la place, ce qui ajoute des limites mémoire par service et le redémarrage automatique des conteneurs. Les deux approches fonctionnent. L'approche Swarm est mieux adaptée à l'exécution de plusieurs projets sur un seul serveur avec une RAM contrainte, ce qui est exactement notre cas ici.

La suite : créer le serveur et le sécuriser.

Partie 2 — Le serveur →