Zum Hauptinhalt springen

Bereitstellung und Konfiguration

Im vorherigen Artikel haben wir die Grundlagen zum schnellen Einstieg mit Logto behandelt. Dieser Artikel geht einen Schritt weiter und konzentriert sich auf Best Practices und detaillierte Konfigurationsschritte für die Bereitstellung von Logto in einer Produktionsumgebung.

Umgebungsvariablen​

Wir verwenden ein generiertes Preset von Umgebungsvariablen in unserem Demo (docker-compose.yml), das du durch deine eigenen ersetzen und über mehrere Logto-Instanzen hinweg konsistent halten solltest.

Du kannst Umgebungsvariablen direkt setzen oder eine .env-Datei im Logto-Projektstamm ablegen. Wenn du mit Docker testest, schaue dir die vom Image generierte .env in /etc/logto an.

Wesentliches​

  • DB_URL Die Postgres DSN für die Logto-Datenbank.
  • PORT Der Port, auf dem Logto lauscht. Standard 3001.
  • ENDPOINT Du kannst eine URL mit deiner eigenen Domain für die Produktion angeben (z. B. ENDPOINT=https://logto.domain.com). Dies beeinflusst auch den Wert des OIDC-Aussteller-Identifiers.

Admin Console aktivieren

  • ADMIN_PORT Der Port, auf dem die Logto Admin Console lauscht. Standard 3002.
  • ADMIN_ENDPOINT Du kannst eine URL mit deiner eigenen Domain für die Produktion angeben (z. B. ADMIN_ENDPOINT=https://admin.domain.com). Dies beeinflusst auch den Wert der Redirect-URIs der Admin Console.

Admin Console deaktivieren

  • ADMIN_DISABLE_LOCALHOST Setze dies auf 1 oder true, um den Port für die Admin Console zu schließen. Wenn ADMIN_ENDPOINT nicht gesetzt ist, wird die Admin Console vollständig deaktiviert.

Weitere Details zu Umgebungsvariablen findest du unter Konfiguration.

Secret Vault aktivieren

  • Um den Secret Vault zu verwenden, musst du SECRET_VAULT_KEK auf einen base64-codierten String deines Key Encryption Key (KEK) setzen. Dieser wird verwendet, um Data Encryption Keys (DEK) im Secret Vault zu verschlüsseln. AES-256 (32 Bytes) wird empfohlen. Beispiel: crypto.randomBytes(32).toString('base64').

HTTPS​

Du kannst Node.js verwenden, um HTTPS direkt bereitzustellen, oder einen HTTPS-Proxy / Balancer vor Node.js einrichten. Siehe HTTPS aktivieren für Details.

Reverse Proxy​

Wenn du einen Reverse Proxy auf deinem Server verwenden möchtest, zum Beispiel Nginx oder Apache, musst du die Ports 3001 und 3002 separat in deinen Proxy-Pass-Einstellungen abbilden. Angenommen, du verwendest Nginx, dein Logto-Auth-Endpunkt läuft auf Port 3001 und deine Logto-Admin-Console läuft auf 3002, dann füge die folgende Konfiguration in nginx.conf ein:

server {
  listen 443 ssl;
  server_name <your_endpoint_url>; // z. B. auth.your-domain.com
  ...

  location / {
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto https;

    proxy_pass http://127.0.0.1:3001;
  }

  ssl_certificate <path-to-your-certificate-for-auth-endpoint>;
  ssl_certificate_key <path-to-your-certificate-key-for-auth-endpoint>
  ...
}

Füge dann eine ähnliche Konfiguration für deine Admin Console hinzu:

server {
  listen 443 ssl;
  server_name <your_admin_endpoint_url>; // z. B. admin.your-domain.com
  ...

  location / {
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto https;

    proxy_pass http://127.0.0.1:3002;
  }

  ssl_certificate <path-to-your-certificate-for-admin-endpoint>;
  ssl_certificate_key <path-to-your-certificate-key-for-admin-endpoint>
  ...
}

Lade die Nginx-Konfiguration neu, um die neuesten Änderungen zu übernehmen:

nginx -s reload

Jetzt ist alles bereit. Öffne den Browser und besuche https://admin.your-domain.com, du solltest die Logto-Willkommensseite sehen.

Containerisierung​

Für die Produktion kannst du Docker verwenden, um Logto zu containerisieren. Die Dockerfile findest du im Stammverzeichnis des Projekts. Wenn du mehrere Instanzen von Logto ausführen möchtest, zum Beispiel Logto in einem Kubernetes-Cluster bereitstellen, gibt es einige zusätzliche Schritte, die du beachten musst.

Gemeinsamer Connectors-Ordner​

Standardmäßig erstellt Logto einen connectors-Ordner im Stammverzeichnis des core-Ordners. Wir empfehlen, den Ordner zwischen mehreren Instanzen von Logto zu teilen. Du musst den Ordner packages/core/connectors ins Container mounten und npm run cli connector add -- --official ausführen, um die Connectors bereitzustellen.

Hier ein minimales Beispiel für ein deployment in Kubernetes:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: logto
  namespace: default
spec:
  template:
    spec:
      volumes:
        - name: connectors
          emptyDir: {}
      initContainers:
        - image: ghcr.io/logto-io/logto
          command:
            - /bin/sh
          args:
            - '-c'
            - 'npm run cli connector add -- --official'
          name: init
          volumeMounts:
            - name: connectors
              mountPath: /etc/logto/packages/core/connectors
      containers:
        - image: ghcr.io/logto-io/logto
          name: logto
          volumeMounts:
            - name: connectors
              mountPath: /etc/logto/packages/core/connectors

In diesem Beispiel erstellen wir ein leeres Verzeichnis als Volume und mounten es in die Container. Dann führen wir npm run cli connector add -- --official im Init-Container aus, um die Connectors herunterzuladen. Schließlich teilen sich alle Container denselben Connectors-Ordner mit unseren offiziellen Connectors darin.

hinweis:

Dies ist ein Beispiel-yaml. Um Logto auszuführen, musst du die Umgebungsvariablen korrekt setzen.

Für die Produktion kannst du das "empty dir"-Volume durch ein persistentes Volume ersetzen und den "init"-Job auf deine eigene Weise durchführen – du weißt, was du tust!

Datenbankänderung​

Ähnlich wie bei den Connectors muss die Datenbankänderung in einer einzelnen Instanz ausgeführt werden. Du kannst einen Job verwenden, um das Änderungsskript auszuführen.

Die Umgebungsvariable CI=true ist notwendig, wenn die Änderung nicht-interaktiv ausgeführt wird.

apiVersion: batch/v1
kind: Job
metadata:
  name: alteration
spec:
  template:
    spec:
      containers:
        - name: alteration
          image: ghcr.io/logto-io/logto
          imagePullPolicy: Always
          env:
            - name: CI
              value: 'true'
            - name: DB_URL
              value: postgresql://user:password@localhost:5432/logto
          command:
            - /bin/sh
          args:
            - '-c'
            - 'npm run alteration deploy latest'
      restartPolicy: Never

Siehe Datenbankänderung für Details zum Änderungskommando.