Rebase auf der Google Cloud Platform bereitstellen

Die Google Cloud Platform (GCP) bietet eine nahtlose Developer Experience für containerisierte Anwendungen. Für ein robustes Produktions-Setup empfiehlt sich Cloud SQL für die Datenbank und Cloud Run für die Runtime.

Um strenge europäische Datenschutzvorgaben einzuhalten, sollten Sie vollständig innerhalb einer EU-Region wie europe-west3 (Frankfurt), europe-west9 (Paris) oder europe-west1 (Belgien) arbeiten.

Nichts auf dieser Seite ist für Ihr Projekt GCP-spezifisch. Ein Rebase-Deployment besteht aus zwei trennbaren Teilen – dem veröffentlichten Runtime-Image und dem Bundle, das rebase build erzeugt. Dasselbe Bundle läuft unter Docker Compose auf einem Laptop, in der Rebase Cloud, unter dem Helm-Chart und hier.

1. Cloud SQL (PostgreSQL) bereitstellen

Navigieren Sie in Ihrer bevorzugten EU-Region zur Cloud SQL-Konsole.
Klicken Sie auf Instanz erstellen und wählen Sie PostgreSQL aus.
Legen Sie Ihre Instanz-ID fest und generieren Sie ein sicheres Passwort für den Benutzer postgres.
Erweitern Sie die Konfigurationsoptionen, um einen Maschinentyp auszuwählen (zwei vCPUs sind ein guter Anfang).
Konfigurieren Sie eine private IP-Adresse oder ein autorisiertes öffentliches Netzwerk, je nachdem, wie Cloud Run darauf zugreifen soll.
Stellen Sie Ihre Verbindungs-URI zusammen: postgresql://postgres:YOUR_PASSWORD@YOUR_IP:5432/postgres

Falls Ihre Collections eine vector-Eigenschaft deklarieren, aktivieren Sie die Extension einmalig in der Datenbank: CREATE EXTENSION vector;.

2. Bundle erstellen und in ein Image einbetten

Es gibt kein Anwendungs-Image, das aus Ihrem Quellcode gebaut werden muss. rebase build erzeugt ein dist-bundle-Verzeichnis mit Ihren kompilierten Collections, Functions, Crons und – falls Ihr Projekt eine statische App deklariert – Ihrem erstellten Frontend. Das veröffentlichte Runtime-Image führt dieses aus:

rebase build

Cloud Run bezieht Images aus einer Registry. Betten Sie das Bundle daher in ein abgeleitetes Image ein. Drei Zeilen genügen, um exakt festzulegen, was ausgeführt wird:

FROM rebasepro/server:0.24.0
COPY dist-bundle /bundle

# Set your active GCP project
gcloud config set project YOUR_PROJECT_ID

# Create an Artifact Registry repository (one-time)
gcloud artifacts repositories create rebase --repository-format=docker --location=europe-west3

# Authenticate Docker to Artifact Registry (one-time)
gcloud auth configure-docker europe-west3-docker.pkg.dev

# Build from the project root and push
docker build -t europe-west3-docker.pkg.dev/YOUR_PROJECT_ID/rebase/backend:latest .
docker push europe-west3-docker.pkg.dev/YOUR_PROJECT_ID/rebase/backend:latest

Ein späteres Upgrade von Rebase erfordert lediglich eine Anpassung dieser FROM-Zeile. Ihr Bundle bleibt unberührt.

3. Auf Cloud Run deployen

gcloud run deploy rebase-backend \
  --image europe-west3-docker.pkg.dev/YOUR_PROJECT_ID/rebase/backend:latest \
  --region europe-west3 \
  --set-env-vars NODE_ENV="production",CORS_ORIGINS="https://yourdomain.com",FRONTEND_URL="https://yourdomain.com",DISABLE_SELF_REGISTRATION="true",REBASE_ADMIN_EMAIL="you@yourdomain.com" \
  --set-secrets DATABASE_URL=rebase-database-url:latest,JWT_SECRET=rebase-jwt-secret:latest,REBASE_SERVICE_KEY=rebase-service-key:latest,REBASE_ADMIN_PASSWORD=rebase-admin-password:latest \
  --allow-unauthenticated

Cloud Run injiziert PORT und die Runtime bindet sich daran, sodass kein Port konfiguriert werden muss. Richten Sie die Startup-Probe auf /livez statt auf /health aus: Letzteres führt einen Datenbank-Roundtrip durch, weshalb eine Liveness-Probe darauf eine fehlerfreie Revision bei kurzen Datenbankunterbrechungen neu starten würde.

Über REBASE_ADMIN_EMAIL und REBASE_ADMIN_PASSWORD erhält dieser Dienst überhaupt erst einen Administrator: In der Produktion wird das erste registrierte Konto nicht automatisch hochgestuft, sodass es sonst keine Möglichkeit gibt, den ersten angemeldeten Aufrufer zu erstellen. Setzen Sie diese Variablen, bevor die erste Revision Traffic verarbeitet – siehe Ihr erster Administrator.

--set-env-vars ersetzt bei jedem Deploy den gesamten Umgebungsblock. Ein späteres Deployment, das eine Variable weglässt, entfernt diese somit stillschweigend. Behalten Sie die vollständige Liste in Ihrem Deployment-Skript bei.

Um eine private Cloud SQL-Instanz zu erreichen, sind --add-cloudsql-instances YOUR_PROJECT:REGION:INSTANCE und eine DATABASE_URL im Socket-Format erforderlich; eine öffentliche Instanz mit einem autorisierten Netzwerk benötigt beides nicht.

4. Das Schema

Die Runtime erstellt fehlende Tabellen beim Start, einschließlich der Tabellen Ihrer Collections. REBASE_MIGRATE_ON_BOOT ist standardmäßig auf ensure gesetzt, was über das gesamte Schema hinweg additiv wirkt – es erstellt fehlende Tabellen, Spalten und Enum-Typen und wendet deren Row-Level Security an –, sodass der erste Start gegen eine leere Instanz direkt Ihre Collections bereitstellt.

Was ensure niemals tut, ist, etwas Bestehendes zu verändern: Es ändert keinen Spaltentyp, löscht nichts und bearbeitet keine bestehenden Enum-Labels, da der Start einer Revision das Schema nicht als Nebeneffekt eines Deployments umgestalten darf.

Eine Sache erfordert daher weiterhin die CLI, ausgeführt aus einem Checkout oder einem CI-Job:

rebase db push

Jede Änderung, die nicht rein additiv ist – eine umbenannte Spalte, ein eingeschränkter Typ, ein entferntes Feld.

Verbinden Sie sich von Ihrem Rechner aus über den Cloud SQL Auth Proxy und verweisen Sie mit DATABASE_URL auf localhost. Das Runtime-Image wird ohne die CLI ausgeliefert, weshalb dies niemals innerhalb des Cloud Run-Containers ausgeführt wird. Für versionierte Migrationen committen Sie Migrationsdateien mit rebase db generate und führen Sie stattdessen rebase db migrate als Release-Schritt aus.

Dateispeicher

Cloud Run-Instanzen sind zustandslos und flüchtig (ephemeral). Lokaler Dateispeicher führt daher zu unbemerktem Datenverlust, weshalb die Runtime dies in der Produktion verweigert.

Erstellen Sie einen privaten Google Cloud Storage-Bucket in Ihrer ausgewählten EU-Region.
Setzen Sie STORAGE_TYPE=gcs und geben Sie den Bucket an – siehe Storage. Auf Cloud Run stellt das Service-Konto der Umgebung die Anmeldedaten bereit, sodass nichts weiter konfiguriert werden muss.

Nächste Schritte

Deployment – die Produktions-Checkliste und die Regeln für den ersten Administrator, die für alle Plattformen gelten.
Konfiguration – jede Umgebungsvariable, die von der Runtime gelesen wird.