Zum Inhalt

Einstieg

Dieser Einstieg bringt eine bestehende Anwendung unter BaseHarbor zum Laufen, ohne dass du Provider-Interna verstehen oder das Manifest manuell bearbeiten musst.

Mit dem Bedarfswizard erstellst du ein Projekt interaktiv, änderst seine Anforderungen und prüfst seinen Target-Footprint.

Mit den Anforderungen der Anwendung beginnen

Eine unterstützte lokale Workload ohne verwaltete Capabilities läuft ohne Core-Installation und Login. Repository inspizieren und initialisieren, dann über den bestehenden Application-Lifecycle planen und starten. SQL ist kein impliziter Default. Ein leeres Verzeichnis benötigt weiterhin eine echte unterstützte Workload; Intent allein bedeutet nicht READY.

Benötigen ausgewählte Capabilities verwaltete Infrastruktur, verwendet BaseHarbor eine kompatible eigene Installation oder fragt interaktiv nach expliziter Einrichtung. Ein ausdrücklich installierter Management-Core stellt weiterhin SQL + Secrets + Identity (PostgreSQL, OpenBao und Keycloak) bereit. Die Web Console bleibt optional. TLS und geschützte Zugangsdaten gelten weiter für verwaltete Services.

Fehlt der benötigte Core bei nichtinteraktiver App-Ausführung, folgt core_required; Application---yes erlaubt keinen Core-Bootstrap. Automation kann zuerst explizit baha up --control-plane-only ausführen. Außerhalb eines App-Repositories prüft baha status diese Installation. Retry verwendet denselben eigenen Core nach geprüfter Readiness.

Shared-Placement verwendet kompatible Provider erneut. Isolierte Provider können zusätzliche Ressourcen benötigen; verwaltete native Capabilities verwenden die volle bestehende Core-Topologie. Core-Ressourcen und App-Footprint unterscheiden Messung, Schätzung und unbekannte Werte. Die Application-Befehle beschreiben unterstützten Core-losen Betrieb und seine Grenzen.

Konkretes Beispiel: Go-API mit SQL

Voraussetzungen: baha ist installiert, Docker oder Podman ist lokal verfügbar und der aktuelle Ordner enthält noch keinen Unterordner orders-api. Prüfe zuerst CLI und Target:

baha version
baha target show

Fehlt ein Target, konfiguriere es anhand der Target-Befehle. Erzeuge danach eine neue Anwendung:

baha new application orders-api --stack go --http --sql
cd orders-api
baha plan
baha up -e dev
baha status
baha doctor

app new erzeugt main.go, go.mod, Dockerfile, compose.yaml, baseharbor.yaml, Repository-Metadaten und .env.example mit leeren Werten. Das Manifest fordert SQL an und beschreibt den HTTP-Workload app auf Port 8080. Der Go-Code verwendet pgx und die geschützte Bindung DATABASE_URL; vor dem HTTP-Start prüft er die Datenbankverbindung.

Beim ersten up beantwortest du die unten beschriebenen Betreiberentscheidungen. Erst eine erfolgreiche Bereitstellung führt zu READY; erzeugte Dateien allein starten keine Runtime. Öffne danach die von status angezeigte HTTPS-Adresse und rufe /healthz auf. Übernimm den angezeigten Port, da Docker und rootless Podman unterschiedliche Ports verwenden können.

Eigene Bestell-Endpunkte und Tabellen ergänzt du im erzeugten Code. Das PostgreSQL-Beispiel zeigt das Einfügen und Lesen einer konkreten Bestellung.

Nur die Anwendung stoppen und ihre persistenten Daten behalten:

baha down

Mit baha up im selben Repository startest du sie wieder.

Bestehendes Repository übernehmen

Bei einer vorhandenen Anwendung folgt auf die optionale Inspektion baha init und danach baha up. Dafür brauchst du kein neues Scaffold und keine manuelle Compose-Umschreibung.

1. Optional: Repository prüfen

baha inspect .

Die Inspektion ist schreibgeschützt. BaseHarbor zeigt den erkannten Workload, ersetzbare Infrastruktur und die erkannten Fähigkeiten, ohne das Repository zu verändern.

Detaillierte Nachweise:

baha inspect . --verbose

2. Portablen Anwendungsvertrag erstellen

baha init

BaseHarbor erkennt so viel wie sicher möglich und fragt nur bei Mehrdeutigkeit oder echten Benutzerentscheidungen nach.

Der Wizard kann unter anderem fragen nach:

  • der maßgeblichen Workload-Quelle bei mehreren Compose-, Quadlet- oder Kubernetes-Kandidaten;
  • Anwendungs-Workload gegenüber ersetzbarer Infrastruktur;
  • provider-neutralen Anforderungen an SQL, Cache, Objektspeicher und Observability;
  • anwendungseigenen Geheimnissen einschließlich Pflicht-/Optional-Status;
  • automatischer Erzeugung, Eingabe beim ersten Anwenden oder späterer Konfiguration;
  • Berechtigungen der Runtime-API aus konkreten Quellnachweisen.

Vor dem Schreiben von baseharbor.yaml zeigt BaseHarbor eine menschenlesbare Zusammenfassung. Rohes YAML erscheint nur als Zusatzdetail unter --verbose.

Deterministische Automatisierung bei eindeutiger Erkennung:

baha init --quick

--quick bricht bei Mehrdeutigkeit der Quelle sicher ab und übernimmt heuristisch erkannte Geheimnis-Kandidaten niemals stillschweigend. Eindeutige Compose-, im Repository gepflegte Quadlet- und rohe Kubernetes-YAML-Quellen können geprüft und übernommen werden, ohne quellenspezifische Namen in den portablen Anwendungsvertrag zu übernehmen.

3. Anwendung starten

baha up

Beim ersten Lauf kann BaseHarbor nur Informationen abfragen, die es nicht sicher selbst bestimmen darf, zum Beispiel:

  • Annahme oder Anpassung des vorgeschlagenen, Target-bezogenen Pfads für die vom Betreiber verwahrte OpenBao-Wiederherstellungsdatei;
  • Wert eines fehlenden verpflichtenden Anwendungsgeheimnisses;
  • Bestätigung eines sicheren Ausweichports.

Interaktive Eingabe von Geheimnissen erfolgt ohne Terminal-Echo. Zugangsdaten für Provider und Runtime werden von BaseHarbor verwaltet und nicht vom Entwickler abgefragt.

Derselbe baha up-Lauf konvergiert danach weiter bis READY. Nach erfolgreichem OpenBao-Bootstrap speichert BaseHarbor am effektiven Target nur die Pfadreferenz auf die Wiederherstellungsdatei. Spätere baha up-Läufe verwenden diese Referenz automatisch, um den gemeinsam genutzten OpenBao-Provider zu entsperren, wenn die Datei vorhanden ist.

4. Ergebnis prüfen

baha status

baha doctor

Erfolg bedeutet verifizierte Capability-Bereitschaft, nicht nur einen gestarteten Container.

Fortgeschrittene und Automation-Befehle

Diese Befehle bleiben verfügbar, gehören aber nicht zum notwendigen Standardablauf:

baha dev domain
baha dev credentials

Automatisierung kann weiterhin ausdrücklich --stdin verwenden:

baha plan
baha app preflight
baha app apply
baha app secret set APP_SECRET

Durchgängige Referenzdemo

Das externe Repository mcpdev80/baseharbor-demo ist der Release-seitige Nachweis dieses Ablaufs. Seine README beschreibt den vollständigen Test vom unveränderten Repository über baha init und baha up bis READY, Neustart und Aufräumen.

Die Vorabprüfung validiert sowohl den geführten Benutzerablauf als auch deterministische Komponentenpfade. Der finale Release verwendet diese unveränderlichen Nachweise wieder, statt dieselbe aufwendige Matrix erneut auszuführen.

Nächste Schritte

Weitere technische Beispiele

printf '%s' "$APP_SECRET" | baha app secret set APP_SECRET --stdin

Technische Bezeichner: baha.localhost, https://my-app.baha.localhost, https://secrets.baha.localhost, 127.0.0.1:<port>.