Chaque PaaS vit ou meurt par une seule question : à quelle vitesse un nouvel utilisateur peut-il passer de « je me suis inscrit » à « mon application tourne » ? Nous avions besoin de déploiements en un clic. Pas dix templates. Pas trente. Cent dix-neuf, couvrant tout de WordPress à Ollama, de PostgreSQL à ERPNext.
Voici comment nous avons construit un moteur de templates basé sur YAML en Rust, embarqué 119 templates directement dans le binaire sh0, et livré un magasin d'applications en un clic en trois jours.
Le schéma de template
Un format YAML personnalisé conçu pour le déploiement en un clic. Les variables sont déclarées au niveau supérieur avec des types qui pilotent l'auto-génération. Les services référencent les variables via des placeholders ${VAR}. Un service est marqué expose: true -- c'est celui qui reçoit le domaine public et le routage Caddy.
Le moteur de substitution de variables
Trois couches de variables : valeurs intégrées (APP_NAME, DOMAIN), secrets auto-générés, et surcharges utilisateur. La chaîne de priorité : surcharges utilisateur > auto-génération > valeurs par défaut > rien.
Tri topologique pour l'ordonnancement des services
L'algorithme de Kahn produit une séquence de déploiement qui respecte le graphe de dépendances. Pour Plausible : [postgres, clickhouse] (parallèle), puis [plausible].
Embarquer 119 templates dans le binaire
La crate include_dir a permis d'embarquer le répertoire templates/ complet dans le binaire compilé. Pas d'accès au système de fichiers. Pas de répertoire de configuration. Chaque template est compilé directement dans le binaire sh0.
Les 119 templates couvrent neuf catégories : CMS et E-Commerce (16), Bases de données (6), Analytiques (6), Auth et Identité (6), IA et ML (7), Outils de développement (12), Communication (5), Productivité (8), Infrastructure (53).
Prochain dans la série : Docker Compose sur un PaaS : parsing, validation, déploiement.