Hostly

Beispiel: Web-App mit PostgreSQL ​

Dieses Beispiel deployt eine Web-App, die ihre Daten in einer PostgreSQL-Datenbank speichert. Die App ist öffentlich, die Datenbank ist nur für die App erreichbar.

text
Internet ──HTTPS──> app (app.example.hostly.ninja, Port 3000)
                     │
                     └──> db:5432 (intern, Volume)

Die Beispiele verwenden das Workspace-Domainfragment example. Ersetze es und das Image der App durch deine eigenen.

Bezahlter Tarif

Dieses Beispiel betreibt zwei Services in einem Workspace, und die Datenbank braucht ein Volume, damit ihre Daten Neustarts überstehen. Beides erfordert den bezahlten Tarif: Der Free Tier erlaubt einen Service pro Workspace und keine Volumes.

1. Datenbank deployen ​

Erstelle einen neuen Service mit diesen Einstellungen:

SchrittEinstellungWert
SubdomainNur intern erreichbaran
Name des Servicedb
High Availabilityaus
ImageImagepostgres:18
Container App Port5432
KonfigurationSecretDB_PASSWORD
Environment Variablessiehe unten
VolumeMount-Pfad /var/lib/postgresql, 5 GB

Lege im Konfigurationsschritt zuerst das Datenbank-Passwort an: Klicke im Bereich Secrets neben den Environment Variables auf Add, nenne das Secret DB_PASSWORD und gib ein starkes Passwort ein. Secrets gehören zum Workspace, die App kann dasselbe Secret also später verwenden. Das Passwort steht nie im Klartext in einer Environment Variable.

TIP

Verwende im Passwort nur Buchstaben und Ziffern. Sonderzeichen wie @, / oder : müssten im Connection String der App URL-kodiert werden.

Trage danach die Environment Variables ein. Das Secret referenzierst du, indem du es in den Editor ziehst oder ${DB_PASSWORD} eintippst:

dotenv
POSTGRES_USER=app
POSTGRES_DB=app
POSTGRES_PASSWORD=${DB_PASSWORD}

Der Service-Name db ist Teil der Adresse, die die App verwendet, und kann später nicht mehr geändert werden.

Nach dem Deployment zeigt die Service-Detailseite Intern erreichbar unter db:5432. Der Service hat keine öffentliche URL.

WARNING

Aktiviere für die Datenbank keine High Availability. Die drei Instanzen würden sich ein Volume teilen und die Daten beschädigen.

2. Web-App deployen ​

Erstelle einen zweiten Service:

SchrittEinstellungWert
SubdomainNur intern erreichbaraus
Subdomainapp
Name des Serviceapp (aus der Subdomain vorausgefüllt)
SSLan
ImageImageregistry.hostly.ninja/example/app:1.0.0
Container App Port3000
KonfigurationEnvironment Variablessiehe unten
dotenv
NODE_ENV=production
DATABASE_URL=postgres://app:${DB_PASSWORD}@db:5432/app

Das beim Deployment der Datenbank angelegte Secret DB_PASSWORD erscheint bereits im Bereich Secrets. Referenziere es auf dieselbe Weise, statt es erneut anzulegen. Hostly setzt ${DB_PASSWORD} beim Start des Containers aus dem Secret-Store ein. Der Host db ist der Service-Name der Datenbank.

Die App ist jetzt unter https://app.example.hostly.ninja erreichbar und verbindet sich intern mit der Datenbank.

Gut zu wissen ​

  • Reihenfolge: Deploye zuerst die Datenbank. Startet die App, bevor die Datenbank bereit ist, sollte sie die Verbindung erneut versuchen, statt sich zu beenden. Andernfalls startet Hostly sie neu, bis die Datenbank Verbindungen annimmt.
  • Pausieren und Stoppen: Beim Pausieren der Datenbank bleiben das Volume und seine Daten erhalten. Beim Stoppen der Datenbank werden das Volume und alle Daten gelöscht.
  • Betrieb: Die Datenbank ist ein normaler Container. Upgrades der PostgreSQL-Hauptversion und Backups liegen bei dir, z. B. mit einem Worker, der regelmäßig pg_dump ausführt.
  • Andere Datenbanken funktionieren genauso: MySQL oder MariaDB auf 3306, MongoDB auf 27017. In der Dokumentation des Images findest du das Datenverzeichnis, an dem du das Volume mountest.

Verwandte Seiten ​