Static sites and SPAs auf Nodion deployen

Static sites and SPAs Schritt für Schritt deployen

1. Lockfile und build-Skript committen Committe dein Lockfile; ohne Lockfile scheitert der Build. Nodion führt das build-Skript aus und nimmt den Output-Ordner deines Frameworks: dist/ bei Vite, build/ bei Create React App, dist/<projekt>/browser bei Angular, public/ bei Gatsby und _site/ bei Eleventy. package.json

   "scripts": {
     "dev": "vite",
     "build": "vite build"
   }

2. Build-Variablen setzen Dein Bundler schreibt Variablen wie VITE_*, REACT_APP_* oder GATSBY_* beim Build in die Dateien, sie brauchen auf dem Tab Environment also das Häkchen Build. Alles darin ist öffentlich, Secrets haben dort nichts verloren.
3. Andere Output-Ordner in static.toml angeben Auch andere Generatoren funktionieren: Nodion sucht eine index.html in dist, build, out, .output/public, public und _site. Schreibt deiner woandershin, so wie VitePress, leg neben die package.json eine static.toml. Sie sorgt außerdem dafür, dass Nodion das Repository als statische Site behandelt, wo es sonst keine erkennen würde. Mit fallback legst du fest, welche Datei für Pfade ausgeliefert wird, die es nicht gibt. static.toml

   output-dir = "docs/.vitepress/dist"
   fallback = "index.html"

4. Reines HTML braucht keinen Build Ein Repository mit index.html im Root und ohne package.json wird ausgeliefert, wie es ist. .git, .env-Dateien und einige übliche Schlüsseldateien lässt Nodion weg, behandle aber alles, was du committest, als öffentlich und halte Secrets aus dem Repository heraus.
5. App anlegen und pushen Lege im Dashboard eine Application aus deinem GitHub-, GitLab-, Bitbucket- oder Gitea-Repository in der Region EU Central an und wähl die kleinste Größe. Jeder Push baut ein neues Release, und der Traffic wechselt, sobald / antwortet; darum kümmert sich deine index.html.

Gut zu wissen

• Clientseitiges Routing funktioniertPfade ohne passende Datei bekommen deine index.html, Routen von React Router, Vue Router und Angular überstehen also ein Neuladen. Abschalten lässt sich der Fallback nicht; fallback in der static.toml tauscht nur die Datei.
• Keine Procfile-Prozesse, kein Server-CodeProcfile-Prozesse haben bei einer statischen Site keine Wirkung, und ausgeliefert wird nur der Output-Ordner. Eine release:-Zeile liefe zwar, aber in einem Image, das nur die gebauten Dateien enthält; lass sie also weg. Ist dein Repository ein Node.js-Server mit build-Skript, lies im Node.js-Guide, wie Nodion die beiden unterscheidet.
• Angular SSRNodion baut Angular-Projekte als statische Sites, auch mit @angular/ssr; Server-Rendering läuft also nicht. Für SSR nimmst du ein Dockerfile.
• Hugo und JekyllHugo- und Jekyll-Builds führt Nodion nicht aus. Bau die Site selbst, committe den erzeugten Ordner (public/ oder _site/) und setz das Base Directory der App darauf: Ein Ordner mit index.html und ohne package.json wird ausgeliefert, wie er ist. Oder bau die Site in einem Dockerfile.

Was Nodion für dich betreibt

• Deploys ohne Downtime Push auf deinen Branch und Nodion baut ein neues Release. Der Traffic wechselt erst, wenn die neuen Instanzen ihren Health Check bestehen; ein fehlgeschlagenes Release lässt das laufende stehen. Apps mit lokalem Volume starten stattdessen neu, weil die Disk zu einer Instanz gehört.
• Datenbanken neben der App Managed PostgreSQL, pgvector, MySQL, Valkey und ClickHouse in derselben Region. Angehängte Datenbanken kommen als DATABASE_URL, REDIS_URL oder CLICKHOUSE_URL in die App.
• Previews pro Pull Request Schalte Previews ein, und Pull Requests aus deinem Repository bekommen eine eigene App mit eigener URL und frischen, leeren Datenbanken, automatisch oder per Hand angelegt. Forks und Bot-Pull-Requests werden übersprungen.
• Worker, Cron Jobs und Skalierung Worker laufen als weitere Prozesse derselben App, Jobs planst du auf dem Tab Cron, und jeden Prozess skalierst du auf bis zu 16 Instanzen.
• Release-Schritt Mit Buildpacks läuft eine release:-Zeile in der Procfile bei jedem neuen Build. Dockerfile-Apps sowie Redeploys und Rollbacks auf ein früheres Image nutzen einen Release Command, der an der App selbst gesetzt ist; er hat auch Vorrang vor der Procfile-Zeile. Bei statischen Sites läuft ein Release-Schritt in einem Image, das nur die gebauten Dateien enthält.
• Logs und Metriken Build-, Release- und Laufzeit-Logs sowie CPU-, Speicher-, Disk- und Netzwerk-Metriken für jede Instanz im Dashboard.
• Domains und HTTPS Ein Default-Hostname mit HTTPS ab dem ersten Deploy; deine eigenen Domains bekommen automatisch Zertifikate.

Weiterlesen

• Preview-Environments erklärt: eine App pro Pull Request Eine laufende Kopie deiner App für jeden Pull Request: wofür Preview-Environments gut sind, wo es knifflig wird und wie Nodion sie handhabt.
• Cloud Native Buildpacks erklärt Buildpacks machen aus deinem Quellcode ein Container-Image ohne Dockerfile. Was sie sind und wie sie funktionieren.

Static sites and SPAs auf Nodion: Fragen und Antworten