ostrelle
Menü

OSTRELLE · LERNEN · MIT ÜBUNGEN

1. Eine isolierte Runtime starten

Du baust den richtigen Quellstand und trennst öffentlichen und internen Listener. Mit konkreten Schritten, eigener Übung, Musterlösung und Erfolgskontrolle.

Eine Testinstanz verantwortlich betreiben · Lektion 1 von 4 · Quellstand 3. November 2026

Das lernst du

Du baust den richtigen Quellstand und trennst öffentlichen und internen Listener.

Das Rustprogramm und seine Runtimepakete gehören zusammen. Das reine Starten eines Binaries legt weder eine Site noch ein Administratorenkonto an. Die Produktwebsite nutzt für ihre eigenen synthetischen Tests den vorhandenen Operator product_site; für fremde Hostnamen ist dieser Weg ausdrücklich nicht vorgesehen.

Der nachfolgende Aufruf dient dem lokalen Lernlauf mit SQLite. Er öffnet nur Loopbackports und enthält keine produktiven Zugangsdaten. Die Shellvariable zeigt auf ein neu erzeugtes temporäres Verzeichnis. Ein frischer leerer Server darf für / zunächst 404 liefern; das ist kein Grund, eine zweite Renderingpipeline zu bauen.

Schritt für Schritt

  1. Prüfe git status und den verwendeten Commit. Lies rust-toolchain.toml und die Konfigurationsreferenz. Verwende pro Worktree ein eigenes Cargo-Target.
  2. Baue den Server aus dem aktuellen Stand mit gesperrtem Lockfile. In diesem betreuten Workspace gelten zusätzlich der zentrale Buildlock und die Ressourcenlimits.
  3. Starte den unten gezeigten Aufruf in einem eigenen Terminal. Verwende freie Loopbackports; prüfe vorher, ob sie bereits belegt sind.
  4. Lies /health und /ready am öffentlichen Listener. Prüfe die ausführliche Readiness ausschließlich am internen Listener.
  5. Beende den Prozess mit Strg+C und kontrolliere den sauberen Shutdown. Behalte die Testdaten für den weiteren Lernlauf geschützt.
cargo build --locked -p wpnext-server --bin wpnext-server
runtime_dir=$(mktemp -d "${TMPDIR:-/tmp}/ostrelle-kurs.XXXXXX")
chmod 700 "$runtime_dir"
WPNEXT_STORE_DATA_DIR="$runtime_dir" \
WPNEXT_SERVER_PUBLIC_BIND=127.0.0.1:18586 \
WPNEXT_SERVER_INTERNAL_BIND=127.0.0.1:18587 \
  "${CARGO_TARGET_DIR:-target}/debug/wpnext-server"
# In einem zweiten Terminal:
curl -i http://127.0.0.1:18586/health
curl -i http://127.0.0.1:18586/ready

Deine Übung

Starte den Server ohne Site. Prüfe /, /health und /ready und erkläre, weshalb nicht jeder Pfad denselben Status liefern muss.

Musterlösung und Erklärung

/health zeigt den lebenden Prozess. /ready spiegelt seine tatsächliche Einsatzbereitschaft wider; bei einer fehlenden Pflichtvoraussetzung muss der Status nachvollziehbar bleiben. / ohne provisionierte Site liefert 404. Ein 404 an dieser Stelle widerlegt den Healthcheck nicht.

Der interne Port bleibt auf 127.0.0.1. Der Prozess wurde aus deinem Commit gebaut; eine zufällig vorhandene alte Binary ist kein Nachweis für den neuen Stand.

So prüfst du dein Ergebnis

  • Öffentlicher und interner Port sind verschieden und lokal gebunden.
  • Antwortstatus und Softwarecommit stehen im eigenen Protokoll.
  • Der Prozess lässt sich sauber beenden.

Kursübersicht · Nächste Lektion →