Déployer un site PRISM

Déployer un site PRISM se fait en trois étapes : le builder, lier un domaine (ce qui émet le certificat TLS et écrit le vhost en un seul appel), puis évincer la route table de l'edge pour que le nouvel hôte soit servi. Pour les conventions de sous-domaines et l'hébergement multi-tenant, voir Sous-domaines.

Où vivent les sites

Un site déployé vit sous un répertoire sites/<name>-prism/. Ce répertoire est le root auquel vous liez un domaine ci-dessous.

1. Builder

Produisez le bundle de production dans dist/ :

bext build

Voir la Référence CLI pour bext build et bext run.

2. Lier le domaine

Un seul appel loopback provisionne tout. POST /__bext/sdk/vhost/upsert_auto émet le certificat Let's Encrypt (ACME HTTP-01, en réutilisant un certificat existant lorsqu'il lui reste plus de 30 jours de validité), écrit le vhost et recharge — de façon atomique :

curl -X POST http://127.0.0.1/__bext/sdk/vhost/upsert_auto \
  -H "X-Bext-App-Id: my-app" \
  -H "Content-Type: application/json" \
  -d '{
    "domain": "my-app.inklura.fr",
    "root": "/srv/sites/my-app-prism",
    "email": "ops@inklura.fr"
  }'
Champ Requis Notes
domain oui Le nom d'hôte à servir.
root oui Chemin absolu vers le répertoire sites/<name>-prism/.
email non Adresse du compte ACME / d'avis d'expiration.
Info

C'est un endpoint SDK loopback — appelez-le depuis l'hôte via 127.0.0.1 avec l'en-tête X-Bext-App-Id identifiant votre application. Il n'est pas atteignable depuis l'extérieur de la machine.

Le DNS et le TLS sont automatiques pour *.inklura.fr

Le DNS wildcard pour *.inklura.fr résout déjà, un nouveau <something>.inklura.fr ne nécessite donc aucun changement DNS. Le TLS est émis automatiquement par l'appel ci-dessus. Pointez un sous-domaine vers votre site et il est en ligne en HTTPS.

3. Évincer la route table de l'edge

Après avoir ajouté un nouveau site, évincez la route table de l'edge pour que le routeur commence à servir le nouvel hôte :

curl -X POST http://127.0.0.1:8444/nginx-cache/purge-site \
  -H "Content-Type: application/json" \
  -d '{"host":"my-app.inklura.fr"}'

Sautez cette étape et le nouvel hôte risque de ne pas encore résoudre vers votre site.

Live reload

Avec live_reload = true et vos sources sous [build] watch_dirs, le watcher par site invalide le cache de la route table et les bundles compilés en ~1-2 s après tout changement de fichier sous ces répertoires — aucun redéploiement nécessaire pour les modifications aux routes existantes.

[build]
watch_dirs = ["src/app", "src/components", "src/lib"]
live_reload = true

Pièges qui nécessitent un purge-site

Deux changements ne sont pas couverts par le watcher et nécessitent l'appel purge-site de l'étape 3 :

  • Un site ou une route flambant neufs. Ajouter un nouveau site — ou un nouveau page.tsx / route.ts — nécessite d'évincer la route table.
  • Une nouvelle méthode HTTP sur un route.ts existant. Ajouter export function DELETE à un route.ts qui n'exportait auparavant que GET renvoie 405 Method Not Allowed jusqu'à ce que vous purgiez — l'ensemble de handlers par méthode est un cache distinct.
Note

public/islands/* n'est volontairement pas surveillé. Cache-bustez les scripts d'island en incrémentant un paramètre de requête ?v= sur le <script src>.

Connexe