OpenShip-Deployment: Wo die App läuft und was du prüfen solltest

Geschrieben von

OpenShip kann Anwendungen auf einem eigenen Server bereitstellen. Entscheidend ist der Unterschied zwischen dem Dashboard, das den Vorgang startet, und dem Rechner, auf dem die öffentliche Anwendung läuft.

Veröffentlicht am

OpenShip-Deployment: Wo die App läuft und was du prüfen solltest

Aktualisiert

Stoppt die Website, wenn die Desktop-App geschlossen wird?

Beim SSH-Deployment verbindet sich die Desktop-Steuerung mit einem entfernten Server. Die Anwendung läuft dort. Das lokale Dashboard zu schließen ist etwas anderes, als die entfernten Container zu stoppen. Die aktuelle OpenShip-README unterscheidet Desktop-Nutzung von einer dauerhaft laufenden Steuerung für Teamzugriff und automatische Deployments.

Bei der Fehlersuche ist das wesentlich. Eine erfolgreiche SSH-Verbindung belegt den Verwaltungszugriff. Sie beweist nicht, dass Besucher HTTPS erreichen, DNS auf die richtige Adresse zeigt oder alle abhängigen Dienste funktionieren.

Vom Code zur öffentlichen App
Code wird auf dem Server bereitgestellt und über die öffentliche Domain erreichbar gemacht.

Verfolge eine Anfrage durch das System

Bei einer Anwendung mit mehreren Diensten erreicht der Browser zuerst den öffentlichen Proxy. Dieser leitet den Hostnamen zum Webdienst. Der Webdienst kann eine API aufrufen, die Datenbank oder Objektspeicher liest. Jeder Übergang hat eigene Einstellungen.

OpenShip dokumentiert Compose-Anwendungen und seinen Edge-Proxy. Prüfe die Anleitung für deine installierte Version. Belegt ein Proxy bereits die öffentlichen Ports 80 und 443, darf ein zweiter nicht dieselben Host-Ports beanspruchen. Internes HTTP hinter einem Proxy mit TLS-Terminierung kann beabsichtigt sein.

Prüfungen, die echte Fehler aufdecken

Prüfung Benötigter Nachweis
Codeversion Der bereitgestellte Commit entspricht dem getesteten Stand
Build-Einstellungen Öffentliche URLs zeigen nicht auf localhost
Laufzeitkonfiguration API, Datenbank und Speicher sind intern erreichbar
Öffentlicher Zugriff Die echte Domain liefert die erwartete HTTPS-Seite
Persistenz Daten und Uploads überstehen einen Neustart
Wiederherstellung Ein Backup lässt sich einspielen, der vorherige Release ist bekannt

Teste einen vollständigen Ablauf. Veröffentliche einen Entwurf in der Testumgebung, öffne ihn über die öffentliche Route und prüfe ein hochgeladenes Bild. Eine funktionierende Startseite belegt keine funktionierenden Schreibvorgänge.

Build- und Laufzeitvariablen unterscheiden

Ein Frontend-Build kann Werte vor dem Containerstart fest einbauen. Eine später gesetzte Laufzeitvariable ändert diesen kompilierten Text nicht. Serverseitiger Code kann dagegen die Konfiguration während einer Anfrage lesen. Halte fest, welches Verfahren die kanonische Domain und API-Adresse bestimmt. Prüfe anschließend das ausgelieferte HTML.

Was bleibt deine Verantwortung?

Die Plattform spart wiederholte Einrichtung. Anwendungseinstellungen, Zugriffsregeln, Backups und Release-Prüfung bleiben Betriebsaufgaben. Lies vor einem Umzug die Anleitung zu Backups und Wiederherstellung und teste den Ablauf mit entbehrlichen Daten.

Ein konkretes Astro-Rust-Projekt ist Wegweiser Leben. Für neue Vorhaben findest du hier meine Webentwicklung.

Lass uns reden

Erzähl mir, was du vorhast. Ich antworte meist innerhalb eines Arbeitstages.