Plattform ausrollen

Die Erstinstallation wird vollständig über 02_core_platform/full_install.yml ausgeführt. Das Playbook ist für wiederholbare Ausführung ausgelegt und installiert die Plattform in einer technisch notwendigen Reihenfolge.

Ausgangspunkt

Diese Seite beginnt nicht erneut mit dem Aufbau der Deployment-Umgebung. Vor dem Rollout müssen bereits abgeschlossen sein:

• die abgeschlossene Installationsvorbereitung einschließlich Deployment-Umgebung und Clusterzugriff,
• die vollständige Konfiguration der Plattformbasis,
• die Konfiguration der Mandanten,
• die sichere Ablage von Inventory und Kubeconfig.

Arbeiten Sie ab hier im bereits geklonten core-platform-Repository und aktivieren Sie dessen Python-Umgebung:

cd <pfad-zum-core-platform-repository>
source .venv/bin/activate

INVENTORY="inventories/customer-prod.yml"

1. Preflight ausführen

Die strukturelle Inventory-Prüfung wurde bereits während der Konfiguration durchgeführt. Unmittelbar vor dem Rollout wird sie als Freigabegate mit den unverändert bereitgestellten Artefakten wiederholt:

ansible-inventory -i "$INVENTORY" --graph

ansible-playbook -i "$INVENTORY" -l localhost \
  02_core_platform/full_install.yml --syntax-check

ansible-playbook \
  -i "$INVENTORY" \
  -l localhost \
  02_core_platform/full_install.yml \
  --tags validation

Die letzte Prüfung verbindet sich mit dem Cluster und kontrolliert die konfigurierten RWO-StorageClasses.

2. Vollständige Erstinstallation ausführen

ansible-playbook \
  -i "$INVENTORY" \
  -l localhost \
  02_core_platform/full_install.yml

Führen Sie die erste Installation ohne --skip-tags aus. Ein übersprungener Basisdienst kann erst bei einer späteren Komponente als schwer verständlicher Folgefehler sichtbar werden.

Tatsächliche Ausführungsreihenfolge

Reihenfolge des vollständigen Playbooks

Jede Phase schafft die Grundlage für die nächste

01

Validierung

Kubeconfig, Context und konfigurierte StorageClasses werden geprüft.

stoppt vor einem Rollout in die falsche Zielumgebung

→

02

Sicherheit & Operatoren

Kyverno, cert-manager sowie Datenbank- und Plattformoperatoren entstehen.

stellt CRDs, Policies, Datenbank- und TLS-Funktionen bereit

→

03

Gemeinsame Dienste

Keycloak, Observability, Velero und weitere globale Dienste folgen.

erzeugt Identität, Telemetrie und betriebliche Grundlagen

→

04

Mandanten

Die aktivierten Datenpfade und Anwendungen werden je Mandant installiert.

verwendet zuvor erzeugte Operatoren, Secrets und Identitäten

→

05

Integration

Übergreifende Portale und Datenbankexporter werden abschließend verbunden.

greift auf die vollständig installierten Mandantendienste zu

3. Installation beobachten

In einem zweiten Terminal:

KUBECONFIG="$HOME/.kube/customer-prod.conf"
CONTEXT="customer-prod"

kubectl --kubeconfig "$KUBECONFIG" --context "$CONTEXT" \
  get pods -A --watch

Achten Sie besonders auf:

• Pending bei Pods mit PersistentVolumeClaims
• ImagePullBackOff oder ErrImagePull
• CrashLoopBackOff
• nicht bereite PostgreSQL-Cluster
• fehlgeschlagene ACME-Challenges und Zertifikate
• nicht erreichbare Keycloak-Endpunkte während der Komponentenkonfiguration

Brechen Sie einen erkennbar fehlerhaften Rollout kontrolliert ab und beheben Sie die Ursache. Wiederholtes Starten ohne Ursachenanalyse kann teilweise erzeugte externe Konfigurationen schwerer nachvollziehbar machen.

4. Technisch verifizieren

Kubernetes-Ressourcen

kubectl --kubeconfig "$KUBECONFIG" --context "$CONTEXT" get nodes
kubectl --kubeconfig "$KUBECONFIG" --context "$CONTEXT" get pods -A
kubectl --kubeconfig "$KUBECONFIG" --context "$CONTEXT" get pvc -A
kubectl --kubeconfig "$KUBECONFIG" --context "$CONTEXT" get ingress -A
kubectl --kubeconfig "$KUBECONFIG" --context "$CONTEXT" get certificate -A
helm --kubeconfig "$KUBECONFIG" list -A

Erwartet werden:

• alle Nodes im Zustand Ready
• keine dauerhaft fehlerhaften oder ungeplant ausstehenden Pods
• alle benötigten PVCs im Zustand Bound
• TLS-Zertifikate im Zustand Ready
• Helm-Releases ohne Status failed oder pending-*

Plattformzugänge

Prüfen Sie mindestens:

1. Aufruf von https://idm.<domain> und Anmeldung mit dem Plattform-Admin.
2. Vorhandensein des konfigurierten Mandanten-Realm in Keycloak.
3. Erreichbarkeit der aktivierten Anwendungsendpunkte.
4. HTTPS-Zertifikatskette und Hostnamen.
5. API-Zugriff über APISIX für einen aktivierten Datenpfad.
6. Schreiben und Lesen eines Testdatensatzes in einem vorgesehenen nichtproduktiven Datenraum.

Der letzte Punkt ist ein Integrationsnachweis und sollte mit eigens dafür vorgesehenen Testdaten durchgeführt werden.

Selektive Wiederholung nach der Erstinstallation

Selektive Tags sind für gezielte Änderungen gedacht, nicht als Ersatz für die vollständige Erstinstallation. Inventory-Schalter, Ansible-Tags und direkte Voraussetzungen stehen bei der jeweiligen Komponente unter Mandanten konfigurieren.

Clusterweite Dienste:

ansible-playbook -i "$INVENTORY" -l localhost \
  02_core_platform/full_install.yml \
  --tags non_tenant

Ein bestimmter Operator:

ansible-playbook -i "$INVENTORY" -l localhost \
  02_core_platform/full_install.yml \
  --tags operator_postgres

Eine Komponente für alle Mandanten:

ansible-playbook -i "$INVENTORY" -l localhost \
  02_core_platform/full_install.yml \
  --tags tenant,dm_grafana

Eine Komponente für einen Mandanten:

ansible-playbook -i "$INVENTORY" -l localhost \
  02_core_platform/full_install.yml \
  --tags tenant,tenant_stadt,dm_grafana

stadt muss dabei exakt tenant_prefix entsprechen.

Mehrere zusammenhängende Komponenten können gemeinsam ausgewählt werden:

ansible-playbook -i "$INVENTORY" -l localhost \
  02_core_platform/full_install.yml \
  --tags tenant,tenant_stadt,context_mgmt,api_mgmt,dm_grafana

Führen Sie APISIX nach einer neu hinzugefügten Zielkomponente erneut aus, wenn dafür API-Routen angelegt werden sollen. Die Inventory-Werte der Komponenten werden auf der Seite Mandanten konfigurieren erklärt.

Häufige Fehlerbilder

Fehler	Wahrscheinliche Ursache	Erste Prüfung
StorageClass nicht gefunden	Name im Inventory stimmt nicht mit Cluster überein	kubectl get storageclass
PVC bleibt Pending	Provisioner, Kapazität oder Access Mode fehlt	kubectl describe pvc -n <namespace> <pvc>
ImagePullBackOff	Registry nicht erreichbar oder Token fehlt	Pod Events und Image-Pull-Secret prüfen
Zertifikat bleibt ausstehend	DNS, Ingress oder ACME-Challenge fehlerhaft	kubectl describe certificate und challenge
Komponente kann Keycloak nicht konfigurieren	idm.<domain> nicht erreichbar, Realm oder Secret fehlt	Keycloak-Pods, Ingress und Admin-Secret prüfen
Ansible findet Kubeconfig nicht	kubeconfig_file liegt nicht unter $HOME/.kube/	berechneten Pfad und Dateirechte prüfen
API-Routen fehlen	APISIX lief vor dem abhängigen Dienst oder selektiver Tag war unvollständig	APISIX-Task nach Zielkomponente erneut ausführen

Speichern Sie Ansible-Ausgabe und Abnahmeergebnisse zusammen mit den Deployment-Metadaten. Zugangsdaten müssen vor der Ablage aus Logs entfernt werden.

Ergebnis

Nach erfolgreicher Verifikation ist die Plattform technisch bereitgestellt und abgenommen. Die aktivierten Workloads laufen stabil, Persistenz und TLS sind funktionsfähig, die vorgesehenen Zugänge sind erreichbar und mindestens ein technischer Testdatenpfad wurde erfolgreich geprüft.

Für einen späteren Releasewechsel verwenden Sie den kontrollierten Ablauf unter Plattform aktualisieren. Die fachliche Einrichtung und Nutzung der bereitgestellten Datenräume und Anwendungen gehört anschließend in den Praxisleitfaden.