Multi-application

Exécutez des dizaines d'applications sur un seul binaire bext en utilisant le routage basé sur le nom d'hôte. Chaque application obtient sa propre configuration, son propre espace de noms de cache et son cycle de vie de déploiement tout en partageant le même processus, les mêmes certificats TLS et le même port.

Configuration#

Définissez les applications dans la table [apps] de bext.config.toml :

toml

# bext.config.toml
[server]
listen = "0.0.0.0:443"

[apps.marketing]
hostname = "example.com"
root = "./apps/marketing"
type = "static"

[apps.dashboard]
hostname = "app.example.com"
root = "./apps/dashboard"
type = "ssr"
workers = 4

[apps.api]
hostname = "api.example.com"
root = "./apps/api"
type = "proxy"
upstream = "http://127.0.0.1:8080"

[apps.blog]
hostname = "blog.example.com"
root = "./apps/blog"
type = "ssr"

Comportement de routage#

Lorsqu'une requête arrive, bext résout l'application en faisant correspondre l'en-tête Host aux noms d'hôtes configurés :

Correspondance exacte — app.example.com correspond à hostname = "app.example.com"
Correspondance générique — *.example.com correspond à n'importe quel sous-domaine
Application par défaut — si aucun nom d'hôte ne correspond, l'application [apps.default] le gère (ou 404)

toml

[apps.catch_all]
hostname = "*.example.com"
root = "./apps/fallback"
type = "static"

Types d'applications#

Taper	Comportement
`static`	Sert les fichiers de `root` avec compression et mise en cache
`ssr`	Exécute le pool de rendu V8 pour le rendu côté serveur
`proxy`	Proxy inversés vers `upstream` avec contrôles de santé et coupure de circuit
`spa`	Sert `index.html` pour tous les itinéraires (application d'une seule page)
`php`	Exécute le runtime PHP intégré (Enterprise)

Configuration par application#

Chaque application peut remplacer les paramètres globaux :

toml

[apps.dashboard]
hostname = "app.example.com"
root = "./apps/dashboard"
type = "ssr"
workers = 4

[apps.dashboard.cache]
max_entries = 5000
default_ttl_ms = 60000

[apps.dashboard.tls]
cert = "/etc/certs/app.example.com/fullchain.pem"
key = "/etc/certs/app.example.com/privkey.pem"

[apps.dashboard.headers]
X-Frame-Options = "DENY"
Content-Security-Policy = "default-src 'self'"

Mise en cache isolée#

Chaque application obtient son propre espace de noms de cache. Les balises de cache, l'invalidation et l'ISR fonctionnent indépendamment :

bash

# Invalidate only the blog's cache
bext cache purge --app blog --tag "posts"

# View per-app cache stats
bext cache stats
# marketing: 1,234 entries (12 MB)
# dashboard: 567 entries (8 MB)
# blog:      89 entries (2 MB)

Déploie#

Déployez des applications de manière indépendante sans aucun temps d'arrêt :

bash

# Deploy only the marketing site
bext deploy ./apps/marketing --app marketing

# Rollback a specific app
bext rollback dashboard

Chaque application possède son propre historique de déploiement et sa propre pile de restauration.

Mode multi-locataire#

Pour les plateformes SaaS, combinez multi-applications et isolation des locataires :

toml

[apps.saas]
hostname = "*.myplatform.com"
root = "./apps/saas"
type = "ssr"
tenant_resolution = "subdomain"   # extract tenant from subdomain
tenant_cache_isolation = true     # separate cache per tenant

Le {tenant_id} est disponible dans votre application via l'en-tête X-Bext-Tenant-Id.

Limites#

Aucune limite stricte sur le nombre d'applications par instance
Chaque application SSR consomme les threads [render] workers du pool
Les certificats TLS sont partagés par défaut (utilisez des certificats génériques) ou par application
Le tableau de bord d'administration sur /__bext/admin/ affiche les statistiques de toutes les applications

Conseil

Le cache de chaque application est isolé par espace de noms, donc l'invalidation du cache d'une application n'en affecte jamais une autre. Pour connaître les mécanismes de purge du cache et la configuration TTL, consultez le Guide de mise en cache.

En rapport#

Référence de configuration — schéma bext.config.toml complet incluant tous les champs de l'application
Mise en cache – espaces de noms de cache par application, ISR et invalidation
Sécurité et WAF — Règles WAF par application et configuration CORS
TLS et HTTPS — certificats génériques et configuration TLS par application
Modes de déploiement — Explication des types d'applications statiques, SSR, proxy et PHP
Opérations – Mise à l’échelle : dimensionnement du pool de travailleurs sur plusieurs applications SSR