Plattform aktualisieren

Ein UDSP-Upgrade verändert nicht nur Container-Images. Ein freigegebener Plattformstand verbindet Playbooks, Helm-Charts, Datenbankschemata und die dazu passende Inventory-Struktur. Diese Seite führt von der Auswahl des Zielreleases bis zur dokumentierten Produktionsabnahme.

Die verwendeten Felder werden unter Konfiguration erstellen erläutert. Für die technische Abnahme gelten mindestens dieselben Prüfungen wie bei der Verifikation eines Erst-Rollouts.

Kontrollierter ReleasewechselEin Upgrade durchläuft sechs verbindliche Stationen

Erst wenn eine Station abgeschlossen ist, wird der nächste Stand freigegeben. Produktion übernimmt exakt die in Staging geprüften Artefakte.

01Release

Zielstand und Änderungen bewerten

→

02Inventory

Soll-Konfiguration migrieren

→

03Rückfallpunkt

Daten und Plattformstand sichern

→

04Staging

Upgrade ausführen und abnehmen

→

05Produktion

Geprüften Stand ausrollen

→

06Verifikation

Technik und Datenpfade prüfen

Update-Pfad festlegen

Releasewechsel

Vollständiges Playbook

Verwenden, sobald sich der UDSP-Release, gemeinsam ausgelieferte Versionen oder die Inventory-Struktur ändern.

Standardpfad für Upgrades

Release bleibt unverändert

Selektiver Komponentenlauf

Nur für bekannte Konfigurationsänderungen, wenn Zielkomponente und alle Abhängigkeiten bereits kompatibel installiert sind.

Immer zuerst in Staging prüfen

Die folgenden Schritte beschreiben den vollständigen Releasewechsel. Ein selektiver Komponentenlauf ist nur unter den später beschriebenen Bedingungen vorgesehen. Einzelne Image-Tags werden nicht unabhängig vom freigegebenen UDSP-Stand angehoben.

1. Zielrelease bewerten

Das Ergebnis dieses Schritts ist eine belastbare Entscheidung, ob das Zielrelease mit dem vorhandenen Cluster, den aktivierten Plattformkomponenten und den kundenspezifischen Erweiterungen kompatibel ist.

Prüfen Sie dafür:

• Release Notes und bekannte Breaking Changes
• Änderungen an default_inventory.yml
• Änderungen an full_install.yml und den verfügbaren Tags
• neue oder entfernte Operatoren, CRDs und Helm-Charts
• Änderungen an PostgreSQL-, Keycloak-, MinIO- oder Kubernetes-Kompatibilität
• notwendige Migrationen für kunden- oder mandantenspezifische Images

git fetch --tags
git diff <aktuelles-release>..<zielrelease> -- \
  02_core_platform/default_inventory.yml \
  02_core_platform/full_install.yml \
  02_core_platform/vars/00_software_references.yml

00_software_references.yml zeigt, welche Komponenten- und Chartversionen das Zielrelease gemeinsam ausliefert.

2. Inventory migrieren

Das Ziel ist ein neues, versionsgebundenes Inventory. Verwenden Sie die Vorlage des Zielreleases als Struktur und übertragen Sie die weiterhin gültigen kundenspezifischen Werte bewusst. Kopieren Sie das bisherige Inventory nicht unverändert in den neuen Release-Stand.

Inventory-MigrationNeue Vorlage als Zielstruktur verwenden

Kundenspezifische Werte werden bewusst übertragen – die alte Struktur wird nicht kopiert.

01 · Ausgangspunkt

Alte Vorlage

Zeigt den bisher produktiv verwendeten Aufbau.

bewerten→übertragen

02 · Kontrollierte Übernahme

Kundenwerte

DomainsSecretsStorageMandanten

Nur weiterhin gültige Werte und Entscheidungen übernehmen.

einsetzen→validieren

03 · Ergebnis

Neues Inventory

Vollständig, versionsgebunden und nachvollziehbar gespeichert.

git show <aktuelles-release>:02_core_platform/default_inventory.yml \
  > /tmp/inventory-old-template.yml

git show <zielrelease>:02_core_platform/default_inventory.yml \
  > /tmp/inventory-new-template.yml

diff -u \
  /tmp/inventory-old-template.yml \
  /tmp/inventory-new-template.yml

Bewerten Sie insbesondere:

• neue Pflichtfelder
• geänderte Namespace- oder Domainwerte
• geänderte enable-Schalter
• neue Secret-Formate
• Replica-, Storage- und Retention-Werte
• neue Mandanten- oder Komponentenabhängigkeiten

Speichern Sie das migrierte Inventory als neue, nachvollziehbare Version. Überschreiben Sie den letzten produktiv verwendeten Stand nicht.

3. Rückfallpunkt vorbereiten

Ein Rückfallpunkt muss sowohl die Plattformkonfiguration als auch die zustandsbehafteten Daten abdecken. Vor einem produktiven Upgrade müssen vorhanden und eindeutig referenziert sein:

• Sicherung aller relevanten PostgreSQL-Datenbanken
• Sicherung von MinIO-Objektdaten
• Velero-Backup der vorgesehenen Kubernetes-Namespaces, sofern eingesetzt
• Export beziehungsweise Sicherung wichtiger Keycloak-Konfiguration
• vorheriger UDSP-Release-Stand
• vorheriges Inventory
• dokumentierte DNS-, Zertifikats- und externe Konfiguration

Ein Backup gilt erst als belastbar, wenn die Wiederherstellung mindestens in einer geeigneten Testumgebung geprüft wurde.

Rollback umfasst mehr als den Git-Stand

Ein Checkout des alten Git-Tags stellt keine bereits migrierten Datenbanken oder CRDs zurück. Der Rückfallplan muss pro Release festlegen, welche Komponenten zurückgerollt und welche Daten aus Backups wiederhergestellt werden.

4. In Staging aktualisieren

FreigabepfadStaging qualifiziert den unveränderten Produktionsstand

Commit, Inventory und Werkzeugkette dürfen zwischen beiden Läufen nicht wechseln.

Erster Lauf

Staging aktualisieren

Technische Prüfung und fachliche Abnahme mit repräsentativen Datenpfaden.

Freigabegate✓Abnahme dokumentiert

Freigegebener Lauf

Produktion aktualisieren

Identischen Stand im Wartungsfenster ausrollen und anschließend beobachten.

Unverändert übernehmenGit-CommitInventory-VersionPython- und Ansible-Umgebungfreigegebene Images und Charts

Staging verwendet das migrierte Inventory und denselben Zielstand, der später für Produktion vorgesehen ist:

git checkout <zielrelease>

ansible-galaxy collection install -r requirements.yml

ansible-playbook \
  -i inventories/customer-staging.yml \
  -l localhost \
  02_core_platform/full_install.yml \
  --syntax-check

ansible-playbook \
  -i inventories/customer-staging.yml \
  -l localhost \
  02_core_platform/full_install.yml

Führen Sie bei einem Releasewechsel standardmäßig das vollständige Playbook aus. Dadurch werden gemeinsam erwartete Versionen und Konfigurationen konsistent angewendet.

Staging-Abnahme

Die Freigabe umfasst mindestens:

• Kubernetes- und Helm-Status
• Datenbankbereitschaft und Persistenz
• Keycloak-Anmeldung und Mandanten-Realm
• TLS-Zertifikate
• API-Routen und Authentifizierung
• Schreiben und Lesen eines Testdatensatzes
• aktivierte Anwendungen wie Grafana, CKAN, Superset oder Geoportal
• Metriken, Logs und Alerting

5. Produktion aktualisieren

Produktion übernimmt ausschließlich den abgenommenen Staging-Stand. Legen Sie vor Beginn fest:

• Wartungsfenster und Kommunikationsweg
• verantwortliche Personen für Rollout und Abnahme
• Abbruchkriterien
• Zeitpunkt der letzten Backups
• erwartete Dauer von Datenbank- oder Schemaänderungen
• Beobachtungszeit nach dem Rollout

ansible-playbook \
  -i inventories/customer-prod.yml \
  -l localhost \
  02_core_platform/full_install.yml

Verwenden Sie exakt den in Staging geprüften Commit und dieselbe Controller-Werkzeugkette.

Selektive Komponentenaktualisierung

Ein selektiver Lauf ist eine gezielte Wiederholung innerhalb desselben UDSP-Releases. Er ist nur sinnvoll, wenn:

• das UDSP-Release unverändert bleibt,
• nur Inventory-Werte einer bekannten Komponente geändert wurden,
• alle Abhängigkeiten bereits installiert und kompatibel sind,
• der konkrete Tag zuvor in Staging geprüft wurde.

Die Zuordnung von Inventory-Blöcken, Ansible-Tags und direkten Voraussetzungen steht bei der jeweiligen Komponente unter Mandanten konfigurieren.

Beispiel für Grafana eines Mandanten:

ansible-playbook \
  -i inventories/customer-prod.yml \
  -l localhost \
  02_core_platform/full_install.yml \
  --tags tenant,tenant_stadt,dm_grafana

Beispiel für die gemeinsame Observability-Ebene:

ansible-playbook \
  -i inventories/customer-prod.yml \
  -l localhost \
  02_core_platform/full_install.yml \
  --tags monitoring

Wenn eine Zielkomponente neue APISIX-Routen benötigt, muss anschließend auch api_mgmt für den betreffenden Mandanten ausgeführt werden.

Abschluss und Dokumentation

Der Upgrade-Nachweis verbindet freigegebenen Quellstand, Konfiguration, Ausführung, Sicherungen und Abnahme. Halten Sie nach jedem Upgrade fest:

01 · ReleasewechselAlter und neuer Releasev3.0.2 → <zielrelease>

02 · QuellstandExakter Zielstandvollständiger Git-Commit-Hash

03 · KonfigurationVerwendetes InventoryPfad, Vault-Version oder CI-Artefakt

04 · AusführungReproduzierbarer AufrufAnsible-Befehl ohne Secrets

05 · SicherungVerwendete RückfallpunkteZeitstempel und Storage Location

06 · AbnahmeErgebnisse der PrüfungenKubernetes, TLS, Login, APIs, Anwendungen

07 · AbweichungenOffene technische PunkteWarnungen, Verantwortliche, Folgemaßnahmen

Erst nach erfolgreicher Abnahme und Beobachtungszeit wird der vorherige Rückfallpunkt gemäß der vereinbarten Aufbewahrungspolitik ausgemustert.

Wenn die Inventory-Struktur des Zielreleases neue oder geänderte Felder enthält, gleichen Sie den dokumentierten Endstand erneut mit Plattformbasis konfigurieren und Mandanten konfigurieren ab. Die vollständige technische Abschlussprüfung folgt dem Abschnitt Technisch verifizieren.