Migrationen und die Onboarding-Weiterleitung beim Start

Wenn MobilityManager startet, versucht es, das Datenbankschema auf den aktuellen Stand zu bringen, und leitet Benutzer zum Einrichtungsassistenten weiter, sofern das System noch nicht konfiguriert wurde. Das Verständnis dieses Startverhaltens hilft Ihnen, Protokolle und Erfahrungen beim ersten Start richtig zu deuten.

Migrationen werden beim Start angewendet

Beim Hochfahren führt die Anwendung ihre Datenbankmigrationsroutine aus. Sie migriert zunächst die Systemdatenbank und durchläuft anschließend jeden aktiven Mandanten, der über eine Vorlage für die Verbindungszeichenfolge verfügt, und migriert jede Mandantendatenbank der Reihe nach.

Der Vorgang ist bewusst fehlertolerant:

• Ist die Datenbank nicht erreichbar oder noch nicht konfiguriert, werden die Migrationen übersprungen und eine Warnung protokolliert — die Anwendung startet dennoch, damit der Onboarding-Assistent ausgeführt werden kann.
• Nicht relationale Anbieter (die vor der Konfiguration verwendete In-Memory-Ausweichlösung) werden vollständig übersprungen.
• Vor der Migration wird eine Konnektivitätsprüfung ausgeführt, sodass eine nicht erreichbare Datenbank eine klare Meldung protokolliert, anstatt den Start abstürzen zu lassen.

Hinweis: Da Migrationen beim Start automatisch ausgeführt werden, wendet eine rollierende Bereitstellung ausstehende Schemaänderungen an, sobald die neue Instanz hochfährt. Planen Sie Schemaänderungen so, dass sie während des Rollouts abwärtskompatibel sind.

Was "konfiguriert" bedeutet

Die Anwendung betrachtet sich nur dann als konfiguriert, wenn alle der folgenden Bedingungen in einer erreichbaren, nicht In-Memory-Datenbank zutreffen:

1. Es existiert mindestens ein Benutzer.
2. Eine aktive Lizenz ist vorhanden.
3. Es existiert mindestens ein Mandant.

Bis dahin gilt das System als nicht konfiguriert.

Die Onboarding-Weiterleitung

Eine Onboarding-Middleware prüft eingehende Browseranfragen. Ist das System nicht konfiguriert, leitet sie den Benutzer nach /setup weiter, damit er den Einrichtungsassistenten abschließen kann. Die Weiterleitung wird für Pfade übersprungen, die stets funktionieren müssen, darunter:

• API-Aufrufe unter /api/
• Die Einrichtungs- und Anmeldeseiten (/setup, /login)
• Health-Endpunkte (/healthz, /livez, /readyz)
• Framework- und statische Asset-Pfade sowie jede Anfrage nach einer Datei (Pfade, die einen Punkt enthalten)

Tipp: Health-Probes sind von der Weiterleitung ausgenommen, sodass Kubernetes- und Compose-Health-Checks weiterhin erfolgreich sind, auch während das System auf seine Konfiguration wartet.

Ablauf beim ersten Start

1. Starten Sie die Anwendung mit einem gültigen DatabaseProvider und Verbindungszeichenfolgen, die auf leere Datenbanken verweisen.
2. Die Startmigrationen erstellen das Systemschema; da noch keine Mandanten vorhanden sind, werden Mandantenmigrationen übersprungen.
3. Eine Browseranfrage wird nach /setup weitergeleitet.
4. Sie schließen den Assistenten ab, der den ersten Administratorbenutzer erstellt, die Lizenz aktiviert und den ersten Mandanten bereitstellt.
5. Nachfolgende Anfragen werden normal bedient; die Weiterleitung wird nicht mehr ausgelöst.

Verwandte Artikel

• Die Datenbank-Verbindungszeichenfolgen konfigurieren
• Zwischen PostgreSQL und SQL Server wählen
• Die Health-Endpunkte verstehen
• Fehlersuche bei einem fehlgeschlagenen Start