Générateurs d'infrastructures

Le bext est livré avec quatre générateurs CLI qui produisent une configuration d'infrastructure adaptée à votre projet. Ils lisent bext.config.toml, détectent le framework à partir des marqueurs de fichiers ambiants (comme astro.config.mjs, Gemfile, manage.py ) et émettent une valeur par défaut raisonnable que vous pouvez valider et modifier.

Les quatre générateurs utilisent par défaut la sortie standard afin que vous puissiez les rediriger directement vers un fichier, ou transmettre --out <path> pour écrire le fichier vous-même.

bext dockerfile gen#

Émet un Dockerfile en plusieurs étapes adapté au framework détecté.

bext dockerfile gen > Dockerfile
# or
bext dockerfile gen --out Dockerfile

Le Dockerfile généré comporte trois étapes :

1. bext-base — l'image d'exécution officielle de bext ( ghcr.io/bextdev/bext:latest par défaut ; remplacement par --bext-image )
2. framework-build — la chaîne d'outils du framework : oven/bun:1 pour Astro / SvelteKit / SolidStart / Qwik / PRISM, ruby:3.3-slim pour Rails, python:3.12-slim pour Django, composer:2 + php:8.3-fpm-alpine pour Laravel, elixir:1.16-alpine pour Phoenix
3. runtime — image minimale finale qui copie la sortie de construction, définit un HEALTHCHECK par rapport à bext health et exécute bext serve

Pour les projets pour lesquels aucun framework n'est détecté, le générateur ignore l'étape de construction du framework et émet un runtime minimal qui copie simplement l'arborescence du projet et exécute bext serve.

Drapeaux#

bext ci gen#

Émet un flux de travail CI pour une plate-forme prise en charge : Actions GitHub (par défaut), GitLab CI, CircleCI, Cloudflare, Fly et Render.

bext ci gen --platform github > .github/workflows/bext.yml
# with a deploy target
bext ci gen --platform github --deploy-target self-hosted --out .github/workflows/bext.yml
# no deploy step, just build + test
bext ci gen --platform github --deploy-target none

Le flux de travail GitHub par défaut comprend :

• Un travail build qui extrait le référentiel, installe la chaîne d'outils Rust, installe bext via le programme d'installation curl et exécute bext check, bext build et bext test
• Un travail deploy qui s'exécute uniquement lors des transmissions vers main / master, effectue des SSH dans DEPLOY_HOST à l'aide de secrets et exécute bext upgrade + systemctl reload bext

Drapeaux#

bext systemd gen#

Émet un fichier d'unité bext.service (et éventuellement une unité bext.socket associée lorsque --socket-activation est transmis).

bext systemd gen > bext.service
# with socket activation
bext systemd gen --socket-activation > units.txt
# custom user + working directory
bext systemd gen --user www-data --working-dir /srv/bext

La sortie utilise un en-tête sentinelle ### FILE: bext.service pour séparer chaque unité du flux. Divisez sur cet en-tête si vous avez redirigé les deux unités vers un seul fichier.

L'unité par défaut utilise Type=notify, définit des indicateurs de renforcement ( NoNewPrivileges, ProtectSystem=strict, PrivateTmp, PrivateDevices ) et redémarre en cas d'échec avec un intervalle de 2 secondes.

Avec --socket-activation, le service obtient Requires=bext.socket + Sockets=bext.socket et l'unité de socket écoute sur 0.0.0.0:80 + 0.0.0.0:443 avec ReusePort=true. C'est la forme attendue par le chemin de mise à niveau binaire sans temps d'arrêt — voir Mises à niveau sans temps d'arrêt.

Drapeaux#

bext export docker-compose#

L'inverse de bext import : parcourez votre bext.config.toml et les plugins déclarés, puis émettez un docker-compose.yaml adapté au développement local.

bext export docker-compose > docker-compose.yaml

Le service bext est toujours présent. Les services backend sont des automatiquement ajoutés à partir des conventions de dénomination des plugins :

Ainsi, un projet qui déclare @bext/session-redis et @bext/locking-pg obtient à la fois les services redis et postgres avec les variables d'environnement correspondantes câblées au service bext. Des volumes et un réseau bext-net partagé sont émis pour chaque backend.

Une version plus riche qui lit requires_capabilities à partir des manifestes de plug-in est un élément wave-2 ; pour la v1, la convention de dénomination fait autorité.

Drapeaux#

Régénération#

Les quatre générateurs sont des fonctions pures de l'état du projet : leur exécution deux fois produit une sortie identique. Réexécutez-les après avoir cogné bext ou ajouté des plugins et validé la différence ; c'est la boucle de révision prévue.

Ils n’ont également aucun effet de bord en dehors de l’écriture du fichier cible. Ils ne modifient jamais bext.config.toml, ne téléchargent rien et ne touchent jamais au cache des extensions. Ils peuvent donc être exécutés dans des pipelines CI, des hooks pre-commit ou des scripts.

Détection du framework#

Les générateurs reconnaissent :

• Astro — astro.config.*
• SvelteKit — svelte.config.*
• SolidStart — solid.config.*
• Qwik — qwik.config.*
• Rails — Gemfile avec une ligne gem 'rails'
• Django — manage.py
• Laravel — composer.json avec "laravel/framework"
• Phoenix — mix.exs avec :phoenix
• Projet TSX de forme PRISM — ancienne heuristique : package.json avec une dépendance "react" et aucun marqueur Next.js. React peut être présent uniquement pour un îlot client ; le rendu natif PRISM n’appelle pas React.

La détection repose sur un simple balayage des fichiers marqueurs, sans analyse complète du projet. Si les générateurs identifient mal un projet, ouvrez un ticket.

En rapport#

• Mises à niveau sans temps d'arrêt — l'unité systemd générée par bext systemd gen --socket-activation est la forme recommandée pour le flux de signal de mise à niveau
• Mise à l'échelle — bext export docker-compose connecte Redis et Postgres à partir des noms de plugins ; voir la page de mise à l'échelle pour la configuration du cache Redis L2
• Configuration : Docker — Configuration d'exécution spécifique à Docker qui complète le Dockerfile généré
• Configuration : bext.config.toml — le fichier de configuration que les générateurs lisent pour adapter leur sortie
• Cadres : présentation — les marqueurs de détection de framework correspondent aux frameworks répertoriés ici