Enterprise Platform Lab

Konsolidiertes Masterbuch aus Roh-Markdown

Diese Fassung wurde neu aus den Roh-Markdown-Schritten konsolidiert. Die Struktur folgt nicht mehr der Entstehungsreihenfolge, sondern einer fachlichen Lernlogik: Zielbild, Infrastruktur, Plattform, Security, Anwendungen, Daten, Betrieb, DevOps, Beispielprojekt, Praxisfälle, Übungen und Glossar.

Die Build-, Abnahme- und Pflegekapitel stehen nicht als normale Hauptkapitel im Lernweg. Sie sind im Anhang gebündelt, damit das Buch nicht wie eine Chat-Historie wirkt.

Strukturprinzipien

• Fachliche Kapitel statt künstlicher Schrittfolge.
• Praxis direkt im passenden Kontext.
• Glossar und Begriffe als Referenz, nicht als Ersatz für Inhalt.
• Code, YAML, SQL, Terraform, Bash und Konfigurationsbeispiele bleiben erhalten.
• HTML-Ausgabe ist offlinefähig, mit zentralem JetBrains-Dark-Codeblock-Stil und klappbarer Navigation.

Hauptteile

• Teil A: Orientierung, Unternehmenskontext und Zielarchitektur
• Teil B: Hybrid-Infrastruktur: Netzwerk, Cloud, VM, Bare Metal und OpenShift
• Teil C: Identity, Security, Governance und Plattformregeln
• Teil D: Moderne Anwendungen, Datenflüsse, Messaging und Integration
• Teil E: Observability, Betrieb, Backup, Disaster Recovery und Resilienz
• Teil F: DevOps, GitOps, Release Management und AI-Unterstützung
• Teil G: Komplettes Beispielprojekt und große Codebasis
• Teil H: Praxisfälle, Betriebsstörungen und End-to-End-Szenarien
• Teil I: Übungen, Runbooks, Musterlösungen, kompakte SVGs und Fachglossar
• Anhang K: Build-, Abnahme- und Pflegeprozess

---

Teil A: Orientierung, Unternehmenskontext und Zielarchitektur

Konsolidiert aus Rohmaterial: Teil 1.

Unternehmenskontext und Zielbild

1. Warum dieses Projekt existiert

Ein modernes Enterprise-System entsteht selten auf einer grünen Wiese. In vielen Unternehmen gibt es bereits Anwendungen, Datenbanken, Server, Batchjobs, Integrationen, Berechtigungsmodelle und Betriebsprozesse. Manche Systeme laufen auf virtuellen Maschinen, manche auf Bare-Metal-Servern, manche bereits in Kubernetes oder OpenShift, andere teilweise in der Cloud. Genau daraus entsteht die zentrale Herausforderung dieses Lernprojekts.

Das Ziel ist nicht, eine einzelne kleine Demo-Anwendung zu bauen. Das Ziel ist, eine realistische Enterprise-Landschaft zu verstehen und daraus Schritt für Schritt eine moderne Plattform abzuleiten. Diese Plattform soll mehrere Infrastrukturarten gleichzeitig nutzen: Cloud, virtuelle Maschinen, Bare Metal und Kubernetes/OpenShift. Moderne Anwendungen sollen nicht isoliert betrachtet werden, sondern als Teil eines größeren Betriebsmodells.

In einem echten Unternehmen reicht es nicht, nur einen Spring Boot Service zu starten. Man muss wissen, wie dieser Service authentifiziert wird, wie er Logs schreibt, wie er Metriken liefert, wie er deployt wird, wie Secrets verwaltet werden, wie Daten gesichert werden, wie Störungen behandelt werden und wie Änderungen nachvollziehbar dokumentiert werden. Genau deshalb verbindet dieses Projekt Architektur, Infrastruktur, Entwicklung, Security, Betrieb und DevOps.

Der wichtigste Lernpunkt lautet:

Dieses Projekt soll zeigen, wie man eine solche Plattform fachlich sauber plant und technisch nachvollziehbar umsetzt.

2. Das Beispielunternehmen

Für das Lernprojekt verwenden wir ein fiktives Unternehmen:

Die Alpine Retail & Services Group betreibt mehrere digitale Systeme. Kunden bestellen Produkte und Dienstleistungen über ein modernes Portal. Interne Mitarbeiter bearbeiten Aufträge, prüfen Zahlungen, verwalten Kunden und analysieren Kennzahlen. Partnerunternehmen liefern Daten über Schnittstellen. Einige Prozesse laufen in Echtzeit, andere als nächtliche Verarbeitung.

Die bestehende IT-Landschaft ist historisch gewachsen. Es gibt alte Anwendungen auf virtuellen Maschinen, einige Datenbanken auf Bare-Metal-Servern, einzelne Cloud-Dienste und erste Container-Plattformen. Die Organisation möchte nicht alles auf einmal ersetzen. Stattdessen soll eine moderne Plattform entstehen, die neue Anwendungen sauber aufnimmt und alte Systeme kontrolliert integriert.

Das Unternehmen hat folgende Ziele:

Dieses Unternehmen ist bewusst realistisch gewählt. Es gibt keine perfekte Ausgangslage. Genau dadurch wird das Projekt nützlich.

3. Ausgangslage der IT-Landschaft

Die Ausgangslandschaft besteht aus mehreren Bereichen.

Es gibt klassische virtuelle Maschinen für interne Anwendungen. Diese Systeme sind stabil, aber oft schwer automatisierbar. Updates werden teilweise manuell durchgeführt. Konfigurationen liegen nicht immer vollständig in Git. Monitoring existiert, aber nicht überall einheitlich.

Es gibt Bare-Metal-Server für datenintensive oder besonders performante Systeme. Dazu gehören große Datenbanken, File-Verarbeitung und Backup-Systeme. Diese Systeme sind wichtig, weil nicht jede Enterprise-Last sinnvoll in Kubernetes verschoben wird. Manche Workloads brauchen direkten Zugriff auf Storage, spezielle Hardware oder besonders planbare Performance.

Es gibt erste Cloud-Komponenten. Diese werden für Object Storage, Testumgebungen, externe APIs oder skalierbare Web-Komponenten genutzt. Die Cloud bringt Flexibilität, aber auch neue Risiken: Kostenkontrolle, Identitätsmanagement, Netzwerkdesign und Datenklassifizierung müssen sauber geregelt werden.

Außerdem gibt es eine OpenShift-Plattform. Auf dieser Plattform sollen moderne Services laufen: Order Service, Billing Service, Customer Portal, Admin Portal, Reporting-Komponenten und Integrationsservices. OpenShift dient als standardisierte Laufzeitumgebung für containerisierte Anwendungen.

Die Ausgangslage ist also nicht:

sondern:

Das ist der Kern des Projekts.

4. Warum Hybrid statt nur Cloud oder nur Kubernetes?

Viele Lernprojekte zeigen eine sehr einfache Welt: Anwendung bauen, Dockerfile schreiben, Kubernetes Deployment erstellen, fertig. Das ist für den Einstieg gut, aber nicht ausreichend für Enterprise-Architektur.

In echten Unternehmen gibt es Gründe, warum nicht alles in die Cloud oder nach Kubernetes wandert.

Eine relationale Hauptdatenbank kann auf Bare Metal bleiben, weil sie sehr große Datenmengen verarbeitet, spezielle Backup-Strategien nutzt oder bestehende Lizenzmodelle hat. Ein altes Reporting-System kann auf einer VM bleiben, weil es noch nicht modernisiert wurde, aber weiterhin gebraucht wird. Ein File Processing Service kann bewusst außerhalb von Kubernetes laufen, weil er sehr große Dateien verarbeitet und direkten Zugriff auf ein internes Dateisystem benötigt.

Gleichzeitig ist Kubernetes oder OpenShift sehr sinnvoll für moderne Services. Neue APIs, Web-Portale, Event Consumer, Backend-for-Frontend-Komponenten und Integrationsservices profitieren von Containerisierung, automatisierten Deployments, Health Checks, Skalierung und GitOps.

Cloud-Dienste sind wiederum stark bei Object Storage, globaler Verfügbarkeit, temporären Umgebungen, Managed Services und externer Integration.

Die Architekturentscheidung lautet daher:

Das Ziel ist keine ideologische Plattformentscheidung, sondern eine fachlich begründete Zuordnung.

5. Zielplattform des Projekts

Die Zielplattform heißt:

Sie besteht aus folgenden Bausteinen:

Diese Plattform ist kein einzelnes Produkt. Sie ist ein Betriebsmodell.

6. Die wichtigsten Anwendungen im Lab

Customer Portal

Das Customer Portal ist die Weboberfläche für Kunden. Es zeigt Bestellungen, Rechnungen, Statusinformationen und Benachrichtigungen. Es läuft als moderne Frontend-Anwendung, zum Beispiel mit React oder Angular. Die Anwendung nutzt OIDC für Login und ruft Backend-APIs auf.

Das Customer Portal eignet sich gut für OpenShift oder Cloud Hosting, weil es skaliert werden kann und häufige Releases möglich sind.

Order Service

Der Order Service verwaltet Bestellungen. Er nimmt neue Bestellungen entgegen, validiert sie, speichert sie in PostgreSQL und veröffentlicht Events. Dieser Service ist ein typischer moderner Backend-Service.

Er läuft auf OpenShift, weil er gut containerisierbar ist, Health Checks unterstützt und über GitOps deployt werden kann.

Billing Service

Der Billing Service verarbeitet abrechnungsrelevante Events. Er erstellt Rechnungsentwürfe, prüft Zahlungsstatus und schreibt Audit-Informationen. Er konsumiert Events aus Kafka oder RabbitMQ.

Dieser Service zeigt, wie eventgetriebene Architektur funktioniert.

Reporting Service

Der Reporting Service erzeugt Auswertungen. Er kann teilweise als Kubernetes CronJob laufen, teilweise aber auch auf einer VM, wenn er alte Reporting-Werkzeuge oder spezielle Treiber benötigt.

Dieses Beispiel zeigt bewusst, dass nicht jeder Prozess automatisch ein dauerhafter Kubernetes-Service sein muss.

File Processing Service

Der File Processing Service verarbeitet große Dateien von Partnern. Er prüft Dateiformate, extrahiert Inhalte, schreibt Fehlerprotokolle und übergibt gültige Daten an interne Services.

Dieser Service kann auf Bare Metal oder VM laufen, wenn er sehr große Dateien verarbeitet oder direkten Zugriff auf Storage benötigt. Alternativ kann er modernisiert und als containerisierter Worker betrieben werden.

Admin Portal

Das Admin Portal ist für interne Mitarbeiter. Es erlaubt manuelle Korrekturen, Statusprüfungen und administrative Aktionen. Wegen sensibler Funktionen braucht es starke Authentifizierung, Rollenmodell, Audit Logging und klare Berechtigungen.

Dieses Portal zeigt, warum Security nicht am Ende angeklebt werden darf.

7. Zielarchitektur im Überblick

Kunden
  ↓
Customer Portal
  ↓
API Gateway / Ingress / Route
  ↓
Order Service
  ↓
PostgreSQL
  ↓
Outbox Events
  ↓
Kafka / RabbitMQ
  ↓
Billing Service
  ↓
Invoice Store / Audit Log

Parallel dazu gibt es interne Mitarbeiter:

Mitarbeiter
  ↓
Admin Portal
  ↓
Keycloak Login
  ↓
interne APIs
  ↓
Order / Billing / Reporting

Und es gibt Partner:

Partnerunternehmen
  ↓
SFTP / API / Object Storage
  ↓
File Processing
  ↓
Validierung
  ↓
Events oder API-Aufrufe
  ↓
Order Service / Reporting

8. Zielbild als Diagramm

flowchart LR
    Customer[Kunde] --> Portal[Customer Portal]
    Employee[Mitarbeiter] --> Admin[Admin Portal]
    Partner[Partnerunternehmen] --> File[File Processing]

    Portal --> Gateway[API Gateway / OpenShift Route]
    Admin --> Gateway
    Gateway --> Order[Order Service]
    Gateway --> Billing[Billing Service]

    Order --> OrderDB[(PostgreSQL Orders)]
    Billing --> BillingDB[(PostgreSQL Billing)]

    Order --> Outbox[Outbox Tabelle]
    Outbox --> Broker[Kafka oder RabbitMQ]
    Broker --> Billing

    File --> Broker
    Reporting[Reporting Service] --> OrderDB
    Reporting --> BillingDB

    Keycloak[Keycloak] --> Portal
    Keycloak --> Admin
    LDAP[LDAP / Active Directory] --> Keycloak

    Prometheus[Prometheus] --> Order
    Prometheus --> Billing
    Loki[Loki] --> Order
    Loki --> Billing
    Grafana[Grafana] --> Prometheus
    Grafana --> Loki

9. Infrastruktur-Zuordnung

Die Zielarchitektur verwendet bewusst unterschiedliche Infrastrukturtypen.

OpenShift wird für moderne Services genutzt. Dazu gehören Order Service, Billing Service, Customer Portal, API Gateway, kleinere Worker und GitOps-gesteuerte Anwendungen. Diese Workloads profitieren von standardisierten Deployments, automatischem Neustart, Skalierung und Observability.

Virtuelle Maschinen bleiben wichtig für Systeme, die noch nicht containerisiert sind oder die besondere Betriebsvorgaben haben. Dazu gehören interne Tools, ältere Reporting-Komponenten, Migrationshelfer oder Dienste mit speziellen Betriebssystemabhängigkeiten.

Bare Metal wird dort genutzt, wo Performance, Storage, Latenz oder Hardwarebindung entscheidend sind. Beispiele sind große Datenbanken, Backup-Systeme, Storage Gateways oder besonders datenintensive File-Verarbeitung.

Cloud wird dort eingesetzt, wo Flexibilität, schnelle Bereitstellung oder externe Verfügbarkeit wichtig ist. Beispiele sind Object Storage, Testumgebungen, externe Schnittstellen, CDN-nahe Webauslieferung oder temporäre Analyseumgebungen.

10. Erste Architekturentscheidung

ADR 001: Hybrid statt Single Platform

11. Erste Repository-Struktur

modern-hybrid-enterprise-platform-runtime-lab/
├── docs/
│   ├── architecture/
│   ├── adr/
│   ├── runbooks/
│   ├── security/
│   └── operations/
├── apps/
│   ├── customer-portal/
│   ├── admin-portal/
│   ├── order-service/
│   ├── billing-service/
│   ├── reporting-service/
│   └── file-processing-service/
├── platform/
│   ├── openshift/
│   ├── helm/
│   ├── kustomize/
│   ├── argocd/
│   └── network-policies/
├── infrastructure/
│   ├── cloud/
│   ├── vm/
│   ├── bare-metal/
│   └── ansible/
├── security/
│   ├── keycloak/
│   ├── rbac/
│   ├── secrets/
│   └── policies/
├── observability/
│   ├── prometheus/
│   ├── grafana/
│   ├── loki/
│   └── tempo/
├── ci-cd/
│   ├── github-actions/
│   ├── gitlab-ci/
│   └── jenkins/
└── README.md

12. Dokumentation als Architekturartefakt

In vielen Projekten wird Dokumentation als Zusatz betrachtet. Man schreibt zuerst Code, danach vielleicht eine README. In einem Enterprise-Projekt ist das zu spät.

Dokumentation ist ein Architekturartefakt. Eine README erklärt den Zweck eines Systems. Ein ADR erklärt, warum eine Entscheidung getroffen wurde. Ein Runbook erklärt, wie der Betrieb reagiert, wenn etwas schiefgeht. Ein Manifest zeigt die technische Umsetzung. Ein Test zeigt, ob eine Annahme überprüfbar ist.

13. Beispiel: README für den Order Service

14. Erste technische Leitplanken

Für Java-Services gilt Java 21, Spring Boot oder Quarkus, REST APIs mit OpenAPI, strukturierte Logs, Health Checks, Metriken, Testcontainers, Flyway oder Liquibase und eine klare Paketstruktur.

Für Frontends gilt React oder Angular, OIDC Login, Trennung von API Client und UI-Komponenten, sichtbare Fehlerzustände, keine Secrets im Frontend und Build als Container Image.

Für OpenShift gilt Deployment, Service, Route, ConfigMap, Secret oder ExternalSecret, Resource Requests und Limits, Probes, NetworkPolicy, ServiceMonitor und Argo CD Application.

15. Erstes Beispiel: Service-Skelett

order-service/
├── source-material/main/java/com/seb4u/demo/spring/order/
│   ├── OrderServiceApplication.java
│   ├── api/
│   │   ├── OrderController.java
│   │   └── CreateOrderRequest.java
│   ├── application/
│   │   ├── CreateOrderUseCase.java
│   │   └── OrderApplicationService.java
│   ├── domain/
│   │   ├── Order.java
│   │   ├── OrderId.java
│   │   ├── OrderStatus.java
│   │   └── OrderRepository.java
│   ├── infrastructure/
│   │   ├── persistence/
│   │   ├── messaging/
│   │   └── security/
│   └── observability/
│       └── OrderMetrics.java
├── source-material/main/resources/
│   ├── application.yaml
│   └── db/migration/
└── pom.xml

16. Beispielcode: erster Use Case

package com.seb4u.demo.spring.order.application;

import com.seb4u.demo.spring.order.domain.Order;
import com.seb4u.demo.spring.order.domain.OrderRepository;
import com.seb4u.demo.spring.order.domain.OrderStatus;
import com.seb4u.demo.spring.order.domain.events.OrderCreatedEvent;
import com.seb4u.demo.spring.order.infrastructure.messaging.OutboxPublisher;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;

import java.time.Clock;
import java.time.Instant;
import java.util.Objects;

@Service
public class OrderApplicationService implements CreateOrderUseCase {

    private final OrderRepository orderRepository;
    private final OutboxPublisher outboxPublisher;
    private final Clock clock;

    public OrderApplicationService(OrderRepository orderRepository, OutboxPublisher outboxPublisher, Clock clock) {
        this.orderRepository = orderRepository;
        this.outboxPublisher = outboxPublisher;
        this.clock = clock;
    }

    @Override
    @Transactional
    public CreateOrderResult createOrder(CreateOrderCommand command) {
        validate(command);

        Order order = Order.create(command.customerId(), command.items(), OrderStatus.CREATED, Instant.now(clock));
        Order savedOrder = orderRepository.save(order);

        outboxPublisher.store(new OrderCreatedEvent(
                savedOrder.id().value(),
                savedOrder.customerId().value(),
                savedOrder.totalAmount(),
                savedOrder.createdAt()
        ));

        return new CreateOrderResult(savedOrder.id().value(), savedOrder.status().name());
    }

    private void validate(CreateOrderCommand command) {
        Objects.requireNonNull(command, class="str">"command must not be null");
        if (command.customerId() == null || command.customerId().isBlank()) {
            throw new IllegalArgumentException(class="str">"customerId must not be blank");
        }
        if (command.items() == null || command.items().isEmpty()) {
            throw new IllegalArgumentException(class="str">"order must contain at least one item");
        }
    }
}

17. Warum Outbox wichtig ist

Ohne Outbox könnte der Order Service eine Bestellung speichern und danach ein Event an Kafka senden. Wenn Kafka in diesem Moment nicht erreichbar ist, wurde die Bestellung gespeichert, aber kein Event veröffentlicht. Der Billing Service erfährt nichts davon.

Das Outbox Pattern löst dieses Problem, indem das Event zunächst in derselben Datenbanktransaktion gespeichert wird wie die Bestellung.

18. Erste Datenbankmigration

CREATE TABLE orders (
    id UUID PRIMARY KEY,
    customer_id VARCHAR(80) NOT NULL,
    status VARCHAR(40) NOT NULL,
    total_amount NUMERIC(12, 2) NOT NULL,
    created_at TIMESTAMP WITH TIME ZONE NOT NULL,
    updated_at TIMESTAMP WITH TIME ZONE
);

CREATE TABLE outbox_events (
    id UUID PRIMARY KEY,
    aggregate_type VARCHAR(120) NOT NULL,
    aggregate_id VARCHAR(120) NOT NULL,
    event_type VARCHAR(160) NOT NULL,
    payload JSONB NOT NULL,
    created_at TIMESTAMP WITH TIME ZONE NOT NULL,
    published_at TIMESTAMP WITH TIME ZONE,
    publish_attempts INTEGER NOT NULL DEFAULT 0,
    last_error TEXT
);

19. Erste OpenShift-Sicht

apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service
  labels:
    app: order-service
spec:
  replicas: 2
  selector:
    matchLabels:
      app: order-service
  template:
    metadata:
      labels:
        app: order-service
    spec:
      containers:
        - name: order-service
          image: registry.example.com/alpine/order-service:1.0.0
          ports:
            - containerPort: 8080
          readinessProbe:
            httpGet:
              path: /actuator/health/readiness
              port: 8080
          livenessProbe:
            httpGet:
              path: /actuator/health/liveness
              port: 8080

20. Typische Fehler

Ein häufiger Fehler ist, sofort Code zu schreiben, ohne Zielbild und Betriebsmodell zu klären. Ein zweiter Fehler ist, Kubernetes als Lösung für alles zu betrachten. Ein dritter Fehler ist, Security zu spät einzubauen. Ein vierter Fehler ist fehlende Dokumentation. Ein fünfter Fehler ist fehlende Observability.

21. Übung und Musterlösung

Erstelle eine eigene Zielbeschreibung mit Anwendungen, Plattformzuordnung, Authentifizierung, Event-Verarbeitung und Monitoring. Eine mögliche Lösung ordnet Customer Portal, Admin Portal, Order Service und Billing Service OpenShift zu, lässt Reporting vorerst auf VM, hält große Datenbanken auf Bare Metal und nutzt Keycloak, Kafka, Prometheus, Loki und Grafana als gemeinsame Plattformdienste.

22. Merksätze

Eine Enterprise-Plattform ist kein einzelnes Tool. Eine Hybrid-Architektur ist oft die realistische Antwort auf unterschiedliche Anforderungen. OpenShift eignet sich sehr gut für moderne Services, aber nicht jeder Workload muss dort laufen. Dokumentation ist Teil der Architektur, nicht Nacharbeit.

Teil B: Hybrid-Infrastruktur: Netzwerk, Cloud, VM, Bare Metal und OpenShift

Konsolidiert aus Rohmaterial: Teil 2, Teil 3, Teil 4, Teil 5.

Infrastruktur-Fundament

1. Warum Infrastruktur zuerst verstanden werden muss

Moderne Anwendungen hängen nicht in der Luft. Jede Anwendung braucht Netzwerk, DNS, Zertifikate, Routing, Storage, Identität, Monitoring und Zugriff auf andere Systeme. Wenn diese Grundlagen unklar sind, wird selbst ein sauber geschriebener Service im Betrieb instabil.

Viele Entwickler sehen Infrastruktur erst, wenn ein Problem entsteht: Die Anwendung startet lokal, aber im Cluster nicht. Die API funktioniert intern, aber von außen ist sie nicht erreichbar. Der Login funktioniert in der Testumgebung, aber in Produktion scheitert OIDC wegen falscher Redirect-URI. Die Datenbank ist erreichbar, aber nur aus einem Namespace, nicht aus dem anderen.

Deshalb beginnt ein Enterprise-Projekt nicht nur mit Code. Es beginnt mit einer klaren Infrastruktur-Landkarte.

2. Netzwerkzonen im Unternehmen

Ein Unternehmen trennt sein Netzwerk in Zonen. Diese Trennung schützt Systeme, begrenzt Schäden und macht Zugriffe kontrollierbar.

Eine einfache Enterprise-Landschaft kann folgende Zonen haben:

Die DMZ ist eine Übergangszone zwischen Internet und internem Netzwerk. Hier stehen Systeme, die von außen erreichbar sein müssen, aber nicht direkt Zugriff auf alle internen Systeme bekommen sollen.

Die Application Zone enthält interne Anwendungen, APIs, OpenShift Worker Nodes oder virtuelle Maschinen mit Applikationsdiensten. Die Data Zone enthält Datenbanken, Message Broker, Storage-Systeme und andere datenführende Komponenten. Die Management Zone enthält Administrationszugänge, Monitoring-Systeme, Jump Hosts, Bastion Hosts, Deployment-Server oder zentrale Management-Dienste.

3. Beispielhafte Netzwerkarchitektur

flowchart TB
    Internet[Internet] --> WAF[Web Application Firewall]
    WAF --> LB[External Load Balancer / Router]

    subgraph DMZ[DMZ]
        LB
        APIGW[API Gateway / Reverse Proxy]
    end

    subgraph APP[Application Zone]
        OCP[OpenShift Cluster]
        VMAPP[VM Application Servers]
        WORKER[File Processing Worker]
    end

    subgraph DATA[Data Zone]
        PG[(PostgreSQL)]
        MQ[(Kafka / RabbitMQ)]
        S3[(MinIO / Object Storage)]
    end

    subgraph MGMT[Management Zone]
        GIT[Git Server]
        ARGO[Argo CD]
        MON[Monitoring]
        BASTION[Bastion Host]
    end

    subgraph BACKUP[Backup Zone]
        BACKUPSTORE[(Backup Repository)]
    end

    APIGW --> OCP
    OCP --> PG
    OCP --> MQ
    VMAPP --> PG
    WORKER --> S3
    MON --> OCP
    MON --> VMAPP
    BACKUPSTORE --> PG

4. DMZ

Die DMZ ist eine Sicherheitsgrenze. Ein Customer Portal oder API Gateway muss von außen erreichbar sein. Trotzdem soll ein Angreifer, der diese Komponente erreicht, nicht automatisch Zugriff auf interne Datenbanken bekommen.

In einer vereinfachten Architektur sieht der Zugriff so aus:

Internet
↓
Firewall
↓
DMZ Load Balancer
↓
API Gateway
↓
interner Service
↓
Datenbank

Jede Stufe hat eigene Regeln.

5. VLANs und Subnetze

Ein VLAN trennt Netzwerkverkehr logisch. Ein Subnetz beschreibt den IP-Adressbereich. In Unternehmen werden VLANs oft genutzt, um Zonen technisch zu trennen.

VLAN 10: Management  -> 10.10.10.0/24
VLAN 20: DMZ         -> 10.10.20.0/24
VLAN 30: Application -> 10.10.30.0/24
VLAN 40: Data        -> 10.10.40.0/24
VLAN 50: Backup      -> 10.10.50.0/24
VLAN 60: Development -> 10.10.60.0/24

Eine IP-Adresse ist nicht nur eine Adresse. Sie verrät oft, in welcher Zone ein System steht.

6. Firewall-Regeln als Architekturartefakt

Firewall-Regeln sollten nicht nur in einer Firewall-Oberfläche existieren. Sie sollten dokumentiert werden. Eine gute Regel beschreibt Quelle, Ziel, Port, Protokoll, Zweck, verantwortlichen Service und Review-Datum.

Beispiel:

Das ist besser als eine breite Regel wie Allow 10.10.30.0/24 to 10.10.40.0/24 any.

7. DNS

DNS wird oft unterschätzt. Wenn DNS falsch ist, sehen Fehler häufig wie Anwendungsfehler aus. Typische Symptome sind fehlerhafte OIDC-Redirects, TLS-Probleme, falsche Umgebung oder nicht erreichbare Datenbanken.

Beispielhafte Namen:

8. Load Balancer

Ein Load Balancer verteilt Anfragen auf mehrere Ziele. In Enterprise-Architekturen gibt es oft mehrere Load-Balancer-Ebenen:

Externer Load Balancer
↓
OpenShift Router
↓
Service
↓
Pod

Wenn eine Anwendung nicht erreichbar ist, kann der Fehler an DNS, Firewall, Load Balancer, OpenShift Route, Service Selector, Pod Readiness oder Anwendungsport liegen.

9. Beispiel: Fehlersuche bei nicht erreichbarer API

# 1. DNS prüfen
nslookup api.alpine.example.com

# 2. Verbindung prüfen
curl -vk https://api.alpine.example.com/order

# 3. OpenShift Route prüfen
oc get route -n order-prod

# 4. Service prüfen
oc get svc -n order-prod

# 5. Endpoints prüfen
oc get endpoints -n order-prod order-service

# 6. Pods prüfen
oc get pods -n order-prod -l app=order-service

# 7. Logs prüfen
oc logs -n order-prod deployment/order-service --tail=100

10. Virtuelle Maschinen im Lab

VMs eignen sich für Anwendungen mit Betriebssystemabhängigkeiten, alte Reporting-Systeme, interne Admin-Tools, Migrationshelfer, Tools mit grafischer Oberfläche, Systeme, die noch nicht containerisiert wurden, und Übergangsarchitekturen.

Eine VM braucht Patchmanagement, SSH-Kontrolle, lokale Logs, Systemdienste, Dateisystemüberwachung, Backup und Konfigurationsmanagement.

11. Beispiel: Ansible Baseline für Linux-VM

---
- name: Linux baseline for application servers
  hosts: app_servers
  become: true

  tasks:
    - name: Ensure required packages are installed
      ansible.builtin.package:
        name:
          - curl
          - vim
          - unzip
          - chrony
          - firewalld
        state: present

    - name: Ensure chrony is enabled
      ansible.builtin.service:
        name: chronyd
        enabled: true
        state: started

    - name: Disable password authentication for SSH
      ansible.builtin.lineinfile:
        path: /etc/ssh/sshd_config
        regexp: class="str">'^PasswordAuthentication'
        line: class="str">'PasswordAuthentication no'
      notify: Restart sshd

  handlers:
    - name: Restart sshd
      ansible.builtin.service:
        name: sshd
        state: restarted

12. Bare Metal im Lab

Bare Metal bedeutet, dass ein System direkt auf physischer Hardware läuft. Das kann sinnvoll sein, wenn Performance, Storage oder Hardwarezugriff wichtig sind. Beispiele sind große relationale Datenbanken, Backup-Repositories, Storage-Systeme, große File Processing Jobs und Systeme mit spezieller Hardware.

13. Storage-Grundlagen

Es gibt Block Storage, File Storage, Object Storage, Database Storage, Backup Storage und Ephemeral Storage. Ein typischer Anfängerfehler ist, Dateien im Container-Dateisystem zu speichern und zu erwarten, dass sie nach einem Neustart noch da sind. Container sind vergänglich.

14. File Processing mit Object Storage

Partner
↓
SFTP Gateway oder Upload API
↓
Object Storage Bucket incoming
↓
File Processing Worker
↓
Validierung
↓
Object Storage Bucket processed oder rejected
↓
Event an Broker
↓
Order Service oder Reporting

15. OpenShift im Infrastrukturkontext

OpenShift ist Teil der Infrastruktur, aber nicht die gesamte Infrastruktur. Ein OpenShift Cluster braucht Nodes, Netzwerk, DNS, Zertifikate, Storage, Registry, Authentifizierung, Monitoring, Logging und Backup.

Ein Service im Cluster braucht Namespace, ServiceAccount, Deployment, Service, Route oder Ingress, ConfigMap, Secret, Resource Limits, Probes und NetworkPolicy.

16. Namespaces

Namespaces helfen bei Zugriffskontrolle, Resource Quotas, NetworkPolicies, Deployment-Trennung, Monitoring-Zuordnung, Kosten- und Verantwortungszuordnung.

apiVersion: v1
kind: Namespace
metadata:
  name: order-prod
  labels:
    owner: team-order
    environment: prod
    data-classification: internal
---
apiVersion: v1
kind: ResourceQuota
metadata:
  name: order-prod-quota
  namespace: order-prod
spec:
  hard:
    requests.cpu: class="str">"4"
    requests.memory: 8Gi
    limits.cpu: class="str">"8"
    limits.memory: 16Gi
    pods: class="str">"20"

17. NetworkPolicy

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-order-to-postgres-and-kafka
  namespace: order-prod
spec:
  podSelector:
    matchLabels:
      app: order-service
  policyTypes:
    - Egress
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              name: data-services
          podSelector:
            matchLabels:
              app: postgres-orders
      ports:
        - protocol: TCP
          port: 5432
    - to:
        - namespaceSelector:
            matchLabels:
              name: messaging
          podSelector:
            matchLabels:
              app: kafka
      ports:
        - protocol: TCP
          port: 9092

18. Zeit, NTP und Zertifikate

Wenn Server unterschiedliche Uhrzeiten haben, entstehen Probleme mit OIDC Tokens, TLS-Zertifikaten, Log-Korrelation, Audit-Nachweisen und Datenbankreplikation. Deshalb braucht jedes System sauberes NTP oder Chrony.

19. Infrastructure as Code

Infrastruktur sollte nicht nur in Oberflächen geklickt werden. Klicks sind schwer wiederholbar.

resource class="str">"aws_s3_bucket" class="str">"partner_files" {
  bucket = class="str">"alpine-partner-files-prod"

  tags = {
    owner       = class="str">"team-integration"
    environment = class="str">"prod"
    purpose     = class="str">"partner-file-processing"
  }
}

resource class="str">"aws_s3_bucket_versioning" class="str">"partner_files" {
  bucket = aws_s3_bucket.partner_files.id

  versioning_configuration {
    status = class="str">"Enabled"
  }
}

20. Runbook: Datenbank nicht erreichbar

oc get pods -n order-prod -l app=order-service

oc logs -n order-prod deployment/order-service --tail=100

oc get secret -n order-prod order-db-secret -o yaml

21. Typische Fehler

Typische Fehler sind fehlende Zonierung, fehlende Namenskonvention, manuelle Serverkonfiguration, fehlende Dokumentation von Firewall-Regeln, Storage-Missverständnisse und fehlende Zeit-Synchronisation.

22. Übung und Musterlösung

Erstelle eine Infrastruktur-Landkarte mit mindestens fünf Netzwerkzonen, drei Anwendungen, zwei Datenkomponenten, einem Broker, Monitoring, Backup-Pfad und administrativem Zugriffspfad. Eine mögliche Lösung trennt DMZ, Application Zone, Data Zone, Management Zone und Backup Zone und erlaubt aus dem Internet nur HTTPS auf den externen Load Balancer.

23. Merksätze

Infrastruktur ist Teil der Anwendungsarchitektur. DNS, Firewall, Zertifikate und Routing sind keine Nebensachen. Eine DMZ schützt interne Systeme vor direkter Exposition. Nicht jede Anwendung gehört in Kubernetes. Infrastructure as Code macht Infrastruktur nachvollziehbar.

Cloud-Architektur

1. Warum Cloud im Hybrid-Lab wichtig ist

Cloud ist in diesem Lernprojekt kein Ersatz für alles andere. Cloud ist ein zusätzlicher Baustein in einer hybriden Enterprise-Landschaft. Sie wird dort eingesetzt, wo sie echte Vorteile bringt: schnelle Bereitstellung, flexible Testumgebungen, Object Storage, externe Schnittstellen, skalierbare Frontend-Auslieferung, temporäre Analyseumgebungen oder Managed Services.

Der wichtigste Punkt lautet: Cloud ist nicht automatisch modern, sicher oder günstig. Eine schlecht geplante Cloud-Umgebung kann teurer, unübersichtlicher und unsicherer werden als eine klassische VM-Landschaft. Deshalb muss Cloud-Architektur genauso sorgfältig geplant werden wie Netzwerk, OpenShift, Bare Metal oder virtuelle Maschinen.

Für die Alpine Retail & Services Group bedeutet Cloud nicht: Alle Systeme werden in AWS, Azure oder Google Cloud verschoben. Die Cloud übernimmt gezielte Aufgaben. Das Customer Portal kann Cloud-nahe ausgeliefert werden. Partnerdateien können in Object Storage landen. Testumgebungen können temporär erstellt und wieder gelöscht werden. Externe APIs können über Cloud-nahe Gateways angebunden werden. Kritische Hauptdatenbanken können trotzdem auf Bare Metal oder in einer kontrollierten privaten Umgebung bleiben.

Cloud wird also nicht ideologisch verwendet, sondern fachlich begründet.

2. Grundprinzip einer Cloud-Landing-Zone

Eine Cloud-Landing-Zone ist die vorbereitete Grundfläche für Cloud-Workloads. Sie ist vergleichbar mit dem Fundament eines Gebäudes. Bevor Anwendungen einziehen, müssen Netzwerk, Identität, Logging, Sicherheit, Kostenkontrolle und Governance definiert sein.

Eine Landing-Zone beantwortet Fragen wie:

Ohne Landing-Zone entstehen schnell einzelne Cloud-Ressourcen ohne Zusammenhang. Ein Entwickler erstellt einen Storage Bucket, ein anderer eine Datenbank, ein dritter ein öffentliches Netzwerk. Nach einigen Monaten weiß niemand mehr, welche Ressource produktiv ist, welche Daten sie enthält und wer verantwortlich ist.

Eine gute Landing-Zone verhindert dieses Chaos nicht vollständig, aber sie setzt klare Leitplanken.

3. Accounts, Subscriptions und Umgebungen

In großen Umgebungen werden Cloud-Ressourcen nicht alle in einem einzigen Konto betrieben. Es gibt eine Trennung nach Umgebung, Verantwortung und Risiko.

Ein mögliches Modell:

cloud-root
├── platform-shared
├── security-logging
├── network-hub
├── dev-workloads
├── test-workloads
├── prod-workloads
└── sandbox

platform-shared enthält gemeinsame Plattformdienste. security-logging sammelt Logs, Audit-Ereignisse und Sicherheitsinformationen. network-hub enthält zentrale Netzwerkkomponenten wie VPN, Transit Gateway oder Firewall. dev-workloads, test-workloads und prod-workloads trennen Anwendungen nach Umgebung. sandbox erlaubt Experimente, aber nur mit begrenzten Rechten und Budgetgrenzen.

Diese Trennung ist wichtig. Eine fehlerhafte Testressource darf nicht Produktionsdaten erreichen. Eine Sandbox darf keine unkontrollierten öffentlichen Datenbanken erzeugen. Produktionsressourcen müssen strenger geschützt und stärker überwacht werden als Entwicklungsressourcen.

4. VPC und VNet als Cloud-Netzwerk

In AWS heißt das virtuelle Netzwerk VPC. In Azure heißt es VNet. Andere Clouds haben ähnliche Konzepte. Die Idee ist dieselbe: Man erstellt ein isoliertes Netzwerk in der Cloud und unterteilt es in Subnetze.

Für das Lab könnte die Cloud-Netzwerkstruktur so aussehen:

Cloud Network 10.50.0.0/16
├── public-subnet-a      10.50.10.0/24
├── public-subnet-b      10.50.11.0/24
├── private-app-subnet-a 10.50.20.0/24
├── private-app-subnet-b 10.50.21.0/24
├── private-data-subnet-a 10.50.30.0/24
├── private-data-subnet-b 10.50.31.0/24
└── management-subnet    10.50.40.0/24

Öffentliche Subnetze sind nicht automatisch gefährlich, aber sie müssen streng kontrolliert werden. Dort stehen typischerweise Load Balancer, NAT Gateways oder Reverse Proxies. Anwendungen und Datenbanken gehören normalerweise in private Subnetze.

Ein typischer Fehler ist, eine Datenbank in ein öffentliches Subnetz zu stellen, weil es beim ersten Test einfacher ist. Das ist im Enterprise-Kontext fast immer falsch.

5. Cloud-Netzwerkdiagramm

flowchart TB
    Internet[Internet] --> PublicLB[Public Load Balancer]

    subgraph Cloud[Cloud VPC / VNet]
        subgraph Public[Public Subnets]
            PublicLB
            NAT[NAT Gateway]
        end

        subgraph PrivateApp[Private App Subnets]
            UploadAPI[Partner Upload API]
            TestPortal[Test Customer Portal]
            Worker[Cloud Worker]
        end

        subgraph PrivateData[Private Data Subnets]
            ObjectStore[(Object Storage Endpoint)]
            ManagedDB[(Managed Database optional)]
        end

        subgraph Mgmt[Management Subnet]
            Runner[CI Runner]
            Bastion[Cloud Bastion]
        end
    end

    PublicLB --> UploadAPI
    UploadAPI --> ObjectStore
    Worker --> ObjectStore
    Worker --> ManagedDB
    Runner --> PrivateApp
    Bastion --> PrivateApp

    subgraph Datacenter[On-Prem Rechenzentrum]
        OCP[OpenShift]
        PG[(Bare Metal PostgreSQL)]
        Kafka[(Kafka / RabbitMQ)]
    end

    PrivateApp <-->|VPN / Direct Connect| OCP
    PrivateData <-->|VPN / Direct Connect| PG
    Worker --> Kafka

Dieses Diagramm zeigt, dass Cloud und Rechenzentrum miteinander verbunden sind. Die Cloud ist nicht isoliert. Sie muss in DNS, Identität, Monitoring, Sicherheit und Betriebsprozesse integriert werden.

6. Public und Private Subnets

Public Subnets haben typischerweise eine Route ins Internet. Private Subnets haben keine direkte öffentliche Erreichbarkeit. Sie erreichen externe Dienste über NAT, Proxy oder definierte Ausgänge.

Für Enterprise-Workloads gilt oft:

Das Customer Portal kann öffentlich erreichbar sein, aber seine Backend-Services müssen nicht öffentlich sein. Eine Upload API kann extern erreichbar sein, aber sie sollte nicht direkt Datenbanken erreichen. Stattdessen schreibt sie Dateien in Object Storage und veröffentlicht kontrolliert Events oder Metadaten.

Ein gutes Netzwerkdesign reduziert die Angriffsfläche.

7. Security Groups und Network Security Groups

Cloud-Firewalls werden je nach Anbieter unterschiedlich genannt. In AWS heißen sie Security Groups, in Azure Network Security Groups. Sie definieren, welche Verbindungen erlaubt sind.

Eine gute Security Group ist eng begrenzt:

Eine schlechte Regel sieht so aus:

0.0.0.0/0 darf auf Port 5432 zugreifen.

Das würde bedeuten: Jede Adresse im Internet darf versuchen, PostgreSQL zu erreichen. Auch wenn Benutzername und Passwort stark sind, ist das eine unnötige und gefährliche Exposition.

Security Groups sind Teil der Architektur. Sie gehören in Code, Review und Dokumentation.

8. Beispiel: Terraform/OpenTofu für Netzwerk

variable class="str">"environment" {
  type    = string
  default = class="str">"prod"
}

resource class="str">"aws_vpc" class="str">"main" {
  cidr_block           = class="str">"10.50.0.0/16"
  enable_dns_support   = true
  enable_dns_hostnames = true

  tags = {
    Name        = class="str">"alpine-${var.environment}-vpc"
    Environment = var.environment
    Owner       = class="str">"platform-team"
  }
}

resource class="str">"aws_subnet" class="str">"private_app_a" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = class="str">"10.50.20.0/24"
  availability_zone = class="str">"eu-central-1a"

  tags = {
    Name = class="str">"alpine-${var.environment}-private-app-a"
    Tier = class="str">"application"
  }
}

resource class="str">"aws_subnet" class="str">"private_data_a" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = class="str">"10.50.30.0/24"
  availability_zone = class="str">"eu-central-1a"

  tags = {
    Name = class="str">"alpine-${var.environment}-private-data-a"
    Tier = class="str">"data"
  }
}

Dieses Beispiel ist noch kein vollständiges Netzwerk. Es zeigt aber das Prinzip: Netzwerk wird als Code beschrieben, bekommt Tags und ist reproduzierbar.

9. Object Storage als Cloud-Baustein

Object Storage ist einer der nützlichsten Cloud-Bausteine für hybride Enterprise-Systeme. Er eignet sich für Dateien, Exporte, Partnerdaten, Reports, Backups, statische Assets und Archivdaten.

Im Lab nutzen wir Object Storage für Partnerdateien:

incoming/     neue Dateien von Partnern
processing/   Dateien in Verarbeitung
processed/    erfolgreich verarbeitete Dateien
rejected/     fachlich oder technisch abgelehnte Dateien
archive/      langfristige Ablage

Diese Struktur ist einfach, aber sehr hilfreich. Sie macht Zustände sichtbar und erlaubt Wiederholungen.

Eine Datei wird nicht einfach überschrieben. Sie bekommt eine eindeutige ID, Metadaten und einen Verarbeitungsstatus. Dadurch kann man später nachvollziehen, wann sie angekommen ist, wer sie geliefert hat, welche Prüfung fehlgeschlagen ist und ob ein erneuter Lauf möglich ist.

10. Beispiel: Bucket mit Versionierung und Verschlüsselung

resource class="str">"aws_s3_bucket" class="str">"partner_files" {
  bucket = class="str">"alpine-partner-files-prod"

  tags = {
    owner          = class="str">"team-integration"
    environment    = class="str">"prod"
    classification = class="str">"internal"
    purpose        = class="str">"partner-file-processing"
  }
}

resource class="str">"aws_s3_bucket_versioning" class="str">"partner_files" {
  bucket = aws_s3_bucket.partner_files.id

  versioning_configuration {
    status = class="str">"Enabled"
  }
}

resource class="str">"aws_s3_bucket_server_side_encryption_configuration" class="str">"partner_files" {
  bucket = aws_s3_bucket.partner_files.id

  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = class="str">"AES256"
    }
  }
}

resource class="str">"aws_s3_bucket_public_access_block" class="str">"partner_files" {
  bucket = aws_s3_bucket.partner_files.id

  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

Wichtig ist der letzte Block. Ein Bucket mit Partnerdaten darf nicht versehentlich öffentlich werden.

11. IAM: Identität in der Cloud

IAM regelt, wer oder was Cloud-Ressourcen verwenden darf. Dabei geht es nicht nur um menschliche Benutzer. Auch Anwendungen, CI/CD-Pipelines, Worker und externe Integrationen brauchen Identitäten.

Ein gutes IAM-Modell verwendet möglichst kurze, konkrete Rechte.

Nicht gut:

Besser:

Rechte sollten sich an Aufgaben orientieren, nicht an Bequemlichkeit.

12. Beispiel: IAM Policy für File Processor

{
  class="str">"Version": class="str">"2012-10-17",
  class="str">"Statement": [
    {
      class="str">"Sid": class="str">"ReadIncomingFiles",
      class="str">"Effect": class="str">"Allow",
      class="str">"Action": [
        class="str">"s3:GetObject",
        class="str">"s3:ListBucket"
      ],
      class="str">"Resource": [
        class="str">"arn:aws:s3:::alpine-partner-files-prod",
        class="str">"arn:aws:s3:::alpine-partner-files-prod/incoming/*"
      ]
    },
    {
      class="str">"Sid": class="str">"WriteProcessingResults",
      class="str">"Effect": class="str">"Allow",
      class="str">"Action": [
        class="str">"s3:PutObject"
      ],
      class="str">"Resource": [
        class="str">"arn:aws:s3:::alpine-partner-files-prod/processed/*",
        class="str">"arn:aws:s3:::alpine-partner-files-prod/rejected/*"
      ]
    }
  ]
}

Diese Policy ist fachlich verständlich. Sie beschreibt nicht nur technische Rechte, sondern spiegelt den Ablauf des File Processing wider.

13. Managed Databases: Nutzen und Grenzen

Cloud-Anbieter bieten Managed Databases an. Das kann sehr hilfreich sein, weil viele Betriebsaufgaben übernommen werden: Patching, Backups, Replikation, Monitoring-Integration und Hochverfügbarkeit.

Trotzdem ist eine Managed Database nicht automatisch die richtige Wahl.

Sie ist gut, wenn:

Sie ist problematisch, wenn:

Im Lab bleibt die Hauptdatenbank zunächst auf Bare Metal. Eine optionale Cloud-Datenbank kann für Testumgebungen oder weniger kritische Dienste genutzt werden.

14. Hybrid-Anbindung: VPN und Direct Connect

Eine hybride Plattform braucht eine Verbindung zwischen Cloud und Rechenzentrum. Dafür gibt es typischerweise VPN oder dedizierte Verbindungen wie Direct Connect, ExpressRoute oder Interconnect.

VPN ist oft schneller einzurichten und günstiger. Es eignet sich für Testumgebungen, kleinere Datenmengen und erste Integrationen.

Dedizierte Verbindungen sind stabiler, planbarer und leistungsfähiger. Sie eignen sich für produktive Lasten, große Datenmengen oder niedrige Latenzanforderungen.

Eine wichtige Regel lautet:

Dann braucht sie Monitoring, Redundanz, Runbooks und klare Eskalationswege.

15. DNS und Hybrid Cloud

DNS wird in hybriden Architekturen anspruchsvoller. Interne Systeme müssen Cloud-Ressourcen auflösen können. Cloud-Systeme müssen interne Dienste finden können. Gleichzeitig dürfen interne Namen nicht unkontrolliert öffentlich sichtbar sein.

Ein mögliches Modell:

Wichtig ist eine klare Trennung zwischen öffentlichen und internen Namen. DNS-Forwarding, Private Hosted Zones oder Private DNS-Zonen müssen sauber dokumentiert werden.

16. Cloud-Kostenkontrolle

Cloud-Kosten entstehen schnell. Nicht nur große Server kosten Geld, sondern auch Datenübertragung, Storage, Snapshots, Logs, NAT Gateways, Load Balancer, Managed Databases und dauerhaft laufende Testumgebungen.

Ein Enterprise-Projekt braucht daher Kostenregeln:

Kostenkontrolle ist kein rein kaufmännisches Thema. Architekturentscheidungen beeinflussen Kosten direkt. Ein NAT Gateway, das große Datenmengen verarbeitet, kann teuer werden. Eine falsch konfigurierte Log-Retention kann hohe Speicherkosten erzeugen. Eine Testdatenbank, die monatelang läuft, obwohl sie niemand nutzt, verschwendet Budget.

17. Beispiel: Tagging-Standard

Tags helfen bei Kosten, Sicherheit, Betrieb und Verantwortlichkeit. Sie ersetzen keine Dokumentation, aber sie machen Cloud-Ressourcen auswertbar.

18. Cloud Security Baseline

Eine Cloud Security Baseline definiert Mindestregeln. Für das Lab verwenden wir diese Baseline:

Diese Regeln sind nicht spektakulär, aber sie verhindern viele typische Fehler.

19. Beispiel: Cloud-Runbook für öffentlichen Bucket-Fund

aws s3api get-public-access-block --bucket alpine-partner-files-prod

aws s3api get-bucket-policy --bucket alpine-partner-files-prod

aws s3api get-bucket-acl --bucket alpine-partner-files-prod

Dieses Runbook verbindet Betrieb, Security und Infrastructure as Code.

20. Cloud und OpenShift

Cloud und OpenShift können auf verschiedene Weise zusammenarbeiten.

Variante 1: OpenShift läuft im eigenen Rechenzentrum, Cloud liefert Zusatzdienste wie Object Storage oder externe APIs.

Variante 2: OpenShift läuft als Managed Service in der Cloud, zum Beispiel als OpenShift Dedicated oder vergleichbare Plattform.

Variante 3: Es gibt OpenShift on-prem und zusätzlich Cloud-native Workloads.

Für das Lab betrachten wir vor allem Variante 1 und Variante 3. Das ist realistisch für Unternehmen, die bereits ein Rechenzentrum betreiben und Cloud schrittweise integrieren möchten.

21. Beispiel: Partner Upload API in Cloud, Verarbeitung hybrid

Ein Partner lädt eine Datei in der Cloud hoch. Die Upload API prüft Authentifizierung, Dateigröße und Metadaten. Danach legt sie die Datei im Object Storage ab. Ein File Processing Worker verarbeitet die Datei. Dieser Worker kann in OpenShift, auf einer VM oder auf Bare Metal laufen.

Der Ablauf:

Partner sendet Datei
↓
Cloud Load Balancer
↓
Upload API
↓
Object Storage incoming
↓
Event oder Polling
↓
File Processing Worker
↓
Validierung
↓
Object Storage processed/rejected
↓
Event an Kafka/RabbitMQ
↓
Order oder Reporting

Diese Architektur nutzt Cloud dort, wo sie stark ist: externe Erreichbarkeit und Object Storage. Die Verarbeitung bleibt flexibel.

22. Beispielcode: einfache Upload-Validierung

package com.seb4u.demo.spring.integration.upload;

import org.springframework.stereotype.Service;
import org.springframework.web.multipart.MultipartFile;

import java.util.Set;

@Service
public class PartnerUploadValidator {

    private static final long MAX_SIZE_BYTES = 100 * 1024 * 1024;
    private static final Set<String> ALLOWED_CONTENT_TYPES = Set.of(
            class="str">"text/csv",
            class="str">"application/json",
            class="str">"application/xml"
    );

    public void validate(MultipartFile file, String partnerId) {
        if (partnerId == null || partnerId.isBlank()) {
            throw new IllegalArgumentException(class="str">"partnerId must not be blank");
        }

        if (file == null || file.isEmpty()) {
            throw new IllegalArgumentException(class="str">"file must not be empty");
        }

        if (file.getSize() > MAX_SIZE_BYTES) {
            throw new IllegalArgumentException(class="str">"file exceeds maximum upload size");
        }

        if (!ALLOWED_CONTENT_TYPES.contains(file.getContentType())) {
            throw new IllegalArgumentException(class="str">"unsupported content type: " + file.getContentType());
        }
    }
}

Dieser Code ist nur ein Einstieg. In einer echten Umgebung kommen Virenscan, Prüfsummen, Partnerberechtigungen, Audit Logging, Rate Limiting und Quarantäne hinzu.

23. Cloud Observability

Cloud-Ressourcen müssen genauso beobachtet werden wie Anwendungen im Rechenzentrum. Man braucht Metriken, Logs, Events und Kosteninformationen.

Wichtige Signale:

Cloud-Audit-Logs sind besonders wichtig. Sie zeigen, wer wann welche Ressource verändert hat. Ohne Audit-Logs kann ein öffentlicher Bucket oder eine gelöschte Datenbank schwer aufgeklärt werden.

24. Typische Cloud-Fehler

Ein häufiger Fehler ist ein öffentlicher Storage Bucket. Er entsteht oft durch Tests, unklare Policies oder manuelle Änderungen.

Ein zweiter Fehler ist zu breites IAM. Service-Rollen bekommen Administratorrechte, weil eine konkrete Policy am Anfang aufwendiger erscheint. Später weiß niemand, welche Rechte wirklich gebraucht werden.

Ein dritter Fehler ist fehlende Kostenkontrolle. Temporäre Ressourcen bleiben dauerhaft aktiv. Logs werden ewig gespeichert. Snapshots werden nicht aufgeräumt.

Ein vierter Fehler ist unklare Netzwerkführung. Cloud-Systeme sprechen direkt mit internen Systemen, ohne dass DNS, Firewall, Routing und Monitoring sauber dokumentiert sind.

Ein fünfter Fehler ist fehlende Datenklassifizierung. Teams speichern Daten in der Cloud, ohne zu wissen, ob diese Daten dort liegen dürfen.

25. Übung: Cloud-Zielbild für Partnerdateien

Entwirf ein Cloud-Zielbild für Partnerdateien.

Beantworte:

26. Musterlösung zur Übung

Eine mögliche Lösung:

27. ADR 002: Cloud gezielt nutzen

28. Merksätze

VM- und Bare-Metal-Betrieb

1. Warum VM und Bare Metal weiterhin wichtig sind

In modernen Architekturgesprächen klingt es manchmal so, als müssten alle Systeme sofort in Container, Kubernetes oder Cloud-Dienste verschoben werden. Das ist in echten Unternehmen selten realistisch. Eine Enterprise-Landschaft besteht fast immer aus mehreren Laufzeitmodellen. Neue Services laufen vielleicht auf OpenShift, aber zentrale Datenbanken, alte Reporting-Systeme, File-Verarbeitung, Backup-Repositories oder Spezialsoftware laufen weiterhin auf virtuellen Maschinen oder physischer Hardware.

Das ist kein Fehler. Es ist eine Realität, die sauber gestaltet werden muss.

Eine virtuelle Maschine ist sinnvoll, wenn ein System ein eigenes Betriebssystem braucht, wenn vorhandene Software nicht containerfähig ist oder wenn ein kontrollierter Übergang von alter zu neuer Architektur geplant wird. Bare Metal ist sinnvoll, wenn Hardwareleistung, Storage-Zugriff, Latenz, spezielle Karten, große Datenmengen oder sehr planbare Performance wichtig sind.

Das Ziel dieses Kapitels ist nicht, Container gegen VMs auszuspielen. Das Ziel ist, Workloads fachlich richtig zuzuordnen und für VM- sowie Bare-Metal-Systeme dieselben Qualitätsprinzipien anzuwenden wie für moderne Plattformdienste: Automatisierung, Sicherheit, Monitoring, Backup, Dokumentation und nachvollziehbare Änderungen.

Merksatz:

---

2. Die Rolle von virtuellen Maschinen im Lab

Im Enterprise Platform Lab werden virtuelle Maschinen bewusst eingesetzt. Sie bilden Systeme ab, die in Unternehmen häufig vorhanden sind und nicht sofort modernisiert werden können.

Typische VM-Kandidaten im Lab sind:

Eine VM bietet eine stabile Umgebung mit eigenem Betriebssystem. Das kann für alte Software wichtig sein. Gleichzeitig entstehen Pflichten: Patchmanagement, Benutzerverwaltung, SSH-Härtung, Firewall, Logrotation, Monitoring-Agent, Backup und Dokumentation.

Ein häufiger Fehler ist, VMs als Ausnahmebereich zu behandeln. Dann entsteht ein Schattenbetrieb: einige Systeme laufen modern mit GitOps, andere werden per SSH von Hand geändert. Das ist gefährlich, weil niemand zuverlässig rekonstruieren kann, wie ein Server wiederhergestellt werden soll.

Deshalb gilt im Lab:

---

3. Die Rolle von Bare Metal im Lab

Bare Metal bezeichnet physische Server ohne Hypervisor-Schicht zwischen Betriebssystem und Hardware. In Enterprise-Umgebungen wird Bare Metal oft für besonders datenintensive oder storage-nahe Systeme verwendet.

Im Lab sind typische Bare-Metal-Kandidaten:

Bare Metal kann sehr performant sein, aber es nimmt dem Betrieb auch weniger ab. Eine VM kann leichter verschoben, geklont oder gesichert werden. Ein physischer Server braucht klare Hardwaredokumentation, Ersatzteilstrategie, RAID-/Storage-Konzept, Firmwarepflege und definierte Restore-Prozesse.

Ein Bare-Metal-System ohne Runbook ist riskant. Wenn die Hardware ausfällt, reicht es nicht zu wissen, dass dort „die Datenbank“ läuft. Man muss wissen, welche Daten, welche Version, welche Konfiguration, welche Backup-Quelle und welche Wiederherstellungsreihenfolge relevant sind.

---

4. Workload-Zuordnung: VM, Bare Metal oder OpenShift?

Eine gute Architekturentscheidung entsteht nicht aus Geschmack, sondern aus Anforderungen.

Ein moderner REST-Service mit klarer Konfiguration, Health Checks und horizontaler Skalierung passt gut zu OpenShift. Ein altes Reporting-Tool mit lokalen Fonts, nativen Bibliotheken und speziellen ODBC-Treibern passt zunächst besser auf eine VM. Eine große Datenbank mit sehr hohem I/O-Bedarf kann auf Bare Metal besser aufgehoben sein.

Die Leitfrage lautet:

Nicht:

Beispielentscheidungen im Lab:

---

5. Standard-Baseline für Linux-Server

Jeder Linux-Server im Lab bekommt eine Baseline. Diese Baseline legt Mindeststandards fest. Sie ist unabhängig davon, ob der Server eine VM oder Bare Metal ist.

Die Baseline umfasst:

Der Server soll nicht erst nach einem Audit gehärtet werden. Die Härtung beginnt beim Aufbau.

---

6. Beispiel: Ansible-Baseline für VM und Bare Metal

---
- name: Enterprise Linux baseline
  hosts: linux_servers
  become: true

  vars:
    management_network: class="str">"10.10.10.0/24"
    timezone_name: class="str">"Europe/Vienna"

  tasks:
    - name: Set timezone
      ansible.builtin.timezone:
        name: class="str">"{{ timezone_name }}"

    - name: Install baseline packages
      ansible.builtin.package:
        name:
          - chrony
          - firewalld
          - curl
          - vim
          - unzip
          - jq
          - rsync
          - logrotate
        state: present

    - name: Enable time synchronization
      ansible.builtin.service:
        name: chronyd
        enabled: true
        state: started

    - name: Disable direct root login
      ansible.builtin.lineinfile:
        path: /etc/ssh/sshd_config
        regexp: class="str">'^PermitRootLogin'
        line: class="str">'PermitRootLogin no'
      notify: restart sshd

    - name: Disable SSH password login
      ansible.builtin.lineinfile:
        path: /etc/ssh/sshd_config
        regexp: class="str">'^PasswordAuthentication'
        line: class="str">'PasswordAuthentication no'
      notify: restart sshd

    - name: Start and enable firewall
      ansible.builtin.service:
        name: firewalld
        enabled: true
        state: started

    - name: Allow SSH only from management network
      ansible.posix.firewalld:
        source: class="str">"{{ management_network }}"
        service: ssh
        permanent: true
        immediate: true
        state: enabled

    - name: Create application group
      ansible.builtin.group:
        name: appops
        state: present

  handlers:
    - name: restart sshd
      ansible.builtin.service:
        name: sshd
        state: restarted

Dieses Playbook ist kein vollständiges Hardening, aber es zeigt den richtigen Ansatz: Server werden nicht per Hand geklickt, sondern reproduzierbar beschrieben.

---

7. Systemd für interne Services

Nicht jede Anwendung läuft in Kubernetes. Ein interner Worker auf einer VM kann als systemd-Service betrieben werden.

Beispiel: File Processing Worker.

[Unit]
Description=Alpine File Processing Worker
After=network-online.target
Wants=network-online.target

[Service]
User=fileworker
Group=fileworker
WorkingDirectory=/opt/alpine/file-worker
EnvironmentFile=/etc/alpine/file-worker.env
ExecStart=/usr/bin/java -jar /opt/alpine/file-worker/file-worker.jar
Restart=on-failure
RestartSec=10
TimeoutStopSec=45
SuccessExitStatus=143

NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=full
ProtectHome=true
ReadWritePaths=/var/lib/alpine/file-worker /var/log/alpine/file-worker

[Install]
WantedBy=multi-user.target

Dieser Service zeigt mehrere wichtige Punkte. Die Anwendung läuft nicht als root. Konfiguration liegt außerhalb des JARs. Schreibrechte sind begrenzt. systemd startet den Dienst bei Fehlern neu. Das ist einfacher als Kubernetes, aber trotzdem professionell.

---

8. Konfiguration eines VM-basierten Workers

Eine VM-Anwendung braucht eine klare Konfigurationsdatei. Secrets gehören nicht in Git. Nicht geheime Konfiguration darf versioniert werden.

Beispiel für /etc/alpine/file-worker.env:

APP_ENV=prod
APP_PORT=8085
INCOMING_DIR=/data/partner/incoming
PROCESSED_DIR=/data/partner/processed
REJECTED_DIR=/data/partner/rejected
BROKER_URL=kafka.internal.alpine.example.com:9092
METRICS_ENABLED=true
LOG_FORMAT=json

Sensitive Werte wie Passwörter, Tokens oder private Schlüssel würden über ein Secret-Verfahren bereitgestellt, zum Beispiel über Vault, eine geschützte Datei mit engen Rechten oder ein Betriebssystem-Secret-Management.

Ein häufiger Fehler ist, VM-Konfiguration nicht zu versionieren. Dann unterscheidet sich Produktion von Test, ohne dass es jemand bemerkt.

---

9. Logging auf VMs

Containerisierte Anwendungen schreiben Logs meist nach stdout. Auf VMs landen Logs oft in Dateien oder im systemd Journal. Beide Varianten sind möglich, aber sie müssen zentral gesammelt werden.

Für das Lab gilt:

Beispiel für einen JSON-Logeintrag:

{
  class="str">"timestamp": class="str">"2026-07-05T20:15:00Z",
  class="str">"level": class="str">"ERROR",
  class="str">"service": class="str">"file-processing-worker",
  class="str">"environment": class="str">"prod",
  class="str">"traceId": class="str">"8e21c1b7f0a44e2d",
  class="str">"partnerId": class="str">"partner-42",
  class="str">"message": class="str">"File validation failed",
  class="str">"reason": class="str">"missing mandatory column customer_id"
}

Dieser Logeintrag ist nützlich, weil er einen Fehler konkret beschreibt, aber keine vertraulichen Inhalte der Datei ausgibt.

---

10. Monitoring für VM- und Bare-Metal-Systeme

Ein Server ist nicht gesund, nur weil er pingbar ist. Monitoring muss fachliche und technische Signale erfassen.

Für eine VM sind typische Metriken:

Für Bare-Metal-Datenbanken kommen hinzu:

Für File Processing sind fachliche Metriken wichtig:

Gerade die letzte Metrik ist wichtig. Wenn eine Datei seit Stunden im Eingang liegt, ist das oft kritischer als eine hohe CPU-Auslastung.

---

11. Beispiel: Prometheus Node Exporter Ziel

VMs und Bare-Metal-Server können über den Node Exporter überwacht werden.

scrape_configs:
  - job_name: class="str">"linux-nodes"
    static_configs:
      - targets:
          - class="str">"reporting-vm-01.internal.alpine.example.com:9100"
          - class="str">"file-worker-01.internal.alpine.example.com:9100"
          - class="str">"postgres-bm-01.internal.alpine.example.com:9100"
        labels:
          environment: class="str">"prod"
          platform: class="str">"vm-bare-metal"

In echten Umgebungen würde man Ziele nicht immer statisch pflegen. Man kann Service Discovery, Inventory oder Konfigurationsmanagement verwenden. Für das Lab ist die statische Variante gut verständlich.

---

12. Patchmanagement

Patchmanagement ist ein zentraler Unterschied zwischen Managed Services und selbst betriebenen Systemen. Bei VMs und Bare Metal trägt das Unternehmen mehr Verantwortung.

Ein Patchprozess braucht:

Ein Produktivserver darf nicht spontan aktualisiert werden, nur weil ein Paketmanager Updates anbietet. Gleichzeitig dürfen Sicherheitsupdates nicht monatelang liegen bleiben. Enterprise-Betrieb bedeutet, zwischen Stabilität und Sicherheit kontrolliert abzuwägen.

Beispielregel:

---

13. Backup für VMs

VM-Backups können auf mehreren Ebenen erfolgen: Image-Backup, Dateisicherung, Anwendungssicherung oder Datenbankdump. Nicht jede Ebene ersetzt die andere.

Ein VM-Image-Backup kann helfen, ein System schnell zurückzubringen. Es garantiert aber nicht immer konsistente Anwendungsdaten, besonders bei Datenbanken. Für Datenbanken braucht man transaktionskonsistente Backups oder native Datenbankmechanismen.

Für eine Reporting-VM könnte die Backup-Strategie so aussehen:

Für einen File Worker:

Der wichtigste Punkt: Ein Backup ohne Restore-Test ist nur eine Hoffnung.

---

14. Backup für Bare-Metal-Datenbanken

Bei Datenbanken ist Backup besonders kritisch. Es reicht nicht, den Server zu sichern. Man muss wissen, bis zu welchem Zeitpunkt Daten wiederhergestellt werden können.

Für PostgreSQL kann ein produktionsnahes Konzept enthalten:

Beispiel für eine einfache Backup-Idee:

#!/usr/bin/env bash
set -euo pipefail

BACKUP_DIR=class="str">"/backup/postgres/orders"
TIMESTAMP=class="str">"$(date +%Y%m%d-%H%M%S)"
DB_NAME=class="str">"orders"

mkdir -p class="str">"${BACKUP_DIR}/${TIMESTAMP}"

pg_dump \
  --format=custom \
  --file=class="str">"${BACKUP_DIR}/${TIMESTAMP}/${DB_NAME}.dump" \
  class="str">"${DB_NAME}"

sha256sum class="str">"${BACKUP_DIR}/${TIMESTAMP}/${DB_NAME}.dump" \
  > class="str">"${BACKUP_DIR}/${TIMESTAMP}/${DB_NAME}.dump.sha256"

Dieses Skript ist bewusst einfach. Für produktive PostgreSQL-Backups wären Werkzeuge wie pgBackRest, Barman oder ein professionelles Backup-System besser geeignet. Das Beispiel zeigt aber, welche Nachweise wichtig sind: Backup-Datei, Zeitstempel und Prüfsumme.

---

15. Restore ist wichtiger als Backup

Viele Teams dokumentieren Backups, aber nicht den Restore. Im Ernstfall ist jedoch der Restore entscheidend.

Ein Restore-Runbook muss beantworten:

Beispiel für eine Prüffrage:

Wenn die Antwort nein ist, ist der Backup-Prozess nicht reif genug.

---

16. Security-Härtung für VM und Bare Metal

Security für Server beginnt mit einfachen, aber konsequenten Regeln:

Besonders wichtig ist die Trennung von Anwendung und Administration. Ein Service-User sollte keine Administrationsrechte haben. Ein Admin-User sollte nicht für den regulären Anwendungsprozess verwendet werden.

Beispiel:

---

17. Beispiel: sudo-Regel für eingeschränkten Betrieb

Diese Regel erlaubt dem Betriebsteam, den Service zu prüfen und neu zu starten, aber nicht beliebige Root-Kommandos auszuführen. In echten Umgebungen muss man solche Regeln sorgfältig prüfen, weil manche erlaubten Kommandos indirekt Rechte ausweiten können.

---

18. Migration von VM zu OpenShift

Nicht jedes VM-System bleibt für immer auf einer VM. Manche Systeme werden später modernisiert. Dafür braucht man eine Migrationsstrategie.

Ein sinnvoller Weg:

Der wichtigste Schritt ist oft nicht das Dockerfile. Der wichtigste Schritt ist, die Anwendung so zu verändern, dass sie in einer dynamischen Umgebung laufen kann.

Typische Hindernisse:

---

19. Beispiel: Containerisierung eines alten Workers

Ein einfacher erster Dockerfile-Ansatz:

FROM eclipse-temurin:21-jre

RUN useradd --system --uid 10001 appuser

WORKDIR /app
COPY target/file-worker.jar /app/file-worker.jar

USER 10001

EXPOSE 8085

ENTRYPOINT [class="str">"java", class="str">"-jar", class="str">"/app/file-worker.jar"]

Das ist nur ein Start. Für OpenShift müssen zusätzlich Schreibpfade, SecurityContext, ConfigMaps, Secrets, Probes und Ressourcenlimits betrachtet werden. Wenn die Anwendung weiterhin lokale Dateien erwartet, braucht sie ein PersistentVolume oder muss auf Object Storage umgebaut werden.

---

20. Betriebliches Szenario: Reporting-VM fällt aus

Ausgangslage: Die Reporting-VM erzeugt jeden Morgen um 06:00 Uhr Management-Berichte. Um 06:30 Uhr meldet der Fachbereich, dass keine Reports vorhanden sind.

Ein unreifer Betrieb würde per SSH auf die VM gehen und zufällig Logs suchen.

Ein reifer Betrieb arbeitet nach Runbook:

Das Ziel ist nicht nur, den Report einmal nachzuliefern. Das Ziel ist, die Ursache zu verstehen und Wiederholung zu verhindern.

---

21. Runbook: Reporting-Job fehlgeschlagen

ssh reporting-vm-01

systemctl status alpine-reporting-scheduler

journalctl -u alpine-reporting-scheduler --since "today 05:30"

df -h

nc -vz orders-db.internal.alpine.example.com 5432

nc -vz billing-db.internal.alpine.example.com 5432

---

22. Qualitätskriterien für VM- und Bare-Metal-Systeme

Ein VM- oder Bare-Metal-System gilt im Lab als produktionsnah, wenn folgende Kriterien erfüllt sind:

Diese Kriterien verhindern, dass klassische Systeme zu unsichtbaren Risiken werden.

---

23. Typische Fehler bei VM und Bare Metal

Ein häufiger Fehler ist manuelle Konfiguration ohne Dokumentation. Dadurch entsteht ein Server, den niemand reproduzieren kann.

Ein zweiter Fehler ist fehlendes Monitoring. Solange niemand bemerkt, dass ein Dienst ausgefallen ist, ist der Betrieb blind.

Ein dritter Fehler ist falsches Backup-Verständnis. Ein VM-Snapshot ersetzt nicht automatisch ein konsistentes Datenbankbackup.

Ein vierter Fehler ist zu breiter Netzwerkzugriff. Wenn eine VM aus historischen Gründen viele Ports offen hat, wird sie zum Risiko.

Ein fünfter Fehler ist fehlende Migrationsstrategie. Systeme bleiben dann nicht aus fachlichen Gründen auf VMs, sondern weil niemand den ersten Schritt zur Modernisierung definiert.

---

24. Übung: VM-Betriebsmodell entwerfen

Entwirf ein Betriebsmodell für eine Reporting-VM im Lab.

Beantworte:

---

25. Musterlösung zur Übung

Die Reporting-VM erzeugt tägliche Berichte aus Orders- und Billing-Daten. Sie liest aus PostgreSQL Orders und PostgreSQL Billing, schreibt Ergebnisdateien in Object Storage und wird über einen systemd Scheduler gestartet.

Offen sein müssen ausgehend Verbindungen zu den Datenbanken auf Port 5432 und zum Object Storage auf HTTPS. Eingehend ist nur SSH aus dem Management-Netz erlaubt. Der Betrieb greift über persönliche Konten und sudo-Regeln zu.

Logs werden im systemd Journal und zusätzlich zentral gesammelt. Kritische Metriken sind Job-Erfolg, Job-Dauer, letzter erfolgreicher Lauf, Speicherplatz, CPU, RAM und Datenbankverbindungsfehler.

Die VM selbst kann über Image-Backup gesichert werden. Wichtiger ist aber, dass Anwendungspaket, Konfiguration und Scheduler-Definition reproduzierbar sind. Reports liegen im Object Storage und sind versioniert.

Später kann die Report-Erzeugung in einen Kubernetes CronJob migriert werden, wenn Treiber, Konfiguration, Storage-Zugriff und Laufzeitverhalten containerfähig sind.

---

26. Merksätze

Kubernetes- und OpenShift-Plattform

1. Warum Kubernetes/OpenShift im Lab eine zentrale Rolle spielt

Kubernetes ist in diesem Lernprojekt nicht einfach ein weiterer Deployment-Ort. Es ist die standardisierte Plattform für moderne, containerisierte Anwendungen. OpenShift erweitert Kubernetes um Enterprise-Funktionen wie integrierte Routes, Security Context Constraints, Build- und Image-Funktionen, Operatoren, Monitoring-Integration und ein stärkeres Betriebsmodell.

Für das Enterprise Platform Lab bedeutet das: Neue Services werden nicht mehr einzeln auf Server kopiert. Sie werden als Container Images gebaut, versioniert, geprüft und über deklarative Manifeste ausgerollt. Eine Änderung an einer Anwendung besteht nicht nur aus Code, sondern auch aus Deployment-Konfiguration, Ressourcenlimits, Health Checks, Security-Einstellungen, Monitoring und GitOps-Zustand.

Der wichtigste Unterschied zu einer klassischen VM ist:

Ein Pod darf verschwinden. Ein Node darf ausfallen. Ein neues Image darf ausgerollt werden. Die Plattform versucht, den gewünschten Zustand wiederherzustellen. Genau deshalb müssen Anwendungen für diese Welt gebaut werden: stateless wo möglich, externes Storage wo nötig, Health Checks, robuste Konfiguration, kontrollierter Shutdown und gute Beobachtbarkeit.

---

2. Kubernetes-Grundidee

Kubernetes beschreibt Anwendungen nicht als einzelne Prozesse, sondern als Ressourcen. Eine Anwendung wird in Objekte zerlegt: Namespace, Deployment, Pod, Service, ConfigMap, Secret, Route oder Ingress, PersistentVolumeClaim, NetworkPolicy und weitere Bausteine.

Ein Deployment beschreibt, wie viele Instanzen einer Anwendung laufen sollen und welches Container Image verwendet wird. Ein Pod ist die kleinste ausführbare Einheit. Ein Service gibt Pods eine stabile interne Adresse. Eine Route oder ein Ingress macht eine Anwendung erreichbar. ConfigMaps und Secrets liefern Konfiguration. Probes sagen der Plattform, ob die Anwendung bereit oder gesund ist.

Für Entwickler ist wichtig: Kubernetes startet nicht einfach nur einen Container. Kubernetes betreibt einen gewünschten Zustand.

Beispiel:

Diese Selbstheilung funktioniert aber nur, wenn die Manifeste sauber beschrieben sind.

---

3. OpenShift-spezifische Sicht

OpenShift ist Kubernetes, aber mit zusätzlichen Enterprise-Bausteinen. Dazu gehören unter anderem:

Für das Lab nutzen wir OpenShift als Zielplattform für moderne Anwendungen. Dabei achten wir darauf, keine OpenShift-Funktion blind zu verwenden. Manche Ressourcen sind Kubernetes-Standard, andere sind OpenShift-spezifisch. Das ist wichtig, wenn Anwendungen später auch auf anderen Kubernetes-Distributionen laufen sollen.

Beispiel:

Im Lab verwenden wir für externe Zugriffe bevorzugt OpenShift Routes, erklären aber den Unterschied zu Ingress.

---

4. Namespace-Strategie

Namespaces sind eine der wichtigsten Ordnungsstrukturen im Cluster. Sie trennen Ressourcen, Berechtigungen, Quotas, Netzwerkregeln und Verantwortlichkeiten.

Für das Lab verwenden wir keine einzige große Sammelzone. Stattdessen werden Fachbereiche und Umgebungen getrennt.

Diese Struktur verhindert nicht automatisch alle Fehler, aber sie macht Verantwortlichkeiten sichtbar. Ein Team erkennt, welche Ressourcen zu seinem Bereich gehören. Security kann Rechte gezielter vergeben. Betrieb kann Ressourcenverbrauch pro Bereich beobachten.

Ein häufiger Fehler ist, Entwicklung, Test und Produktion in denselben Namespace zu legen. Dadurch verschwimmen Grenzen. Ein Test-Deployment kann versehentlich produktive Secrets verwenden oder produktive Ressourcen blockieren.

---

5. Namespace-Definition mit Labels

Labels sind wichtig, weil viele andere Mechanismen darauf aufbauen. Monitoring, NetworkPolicies, Kostenberichte und GitOps können Labels auswerten.

apiVersion: v1
kind: Namespace
metadata:
  name: order-prod
  labels:
    app.kubernetes.io/part-of: order-domain
    environment: prod
    owner: team-order
    data-classification: internal
    network-zone: application

Diese Labels wirken einfach, sind aber wertvoll. Eine NetworkPolicy kann auf network-zone reagieren. Ein Kostenreport kann nach owner gruppieren. Ein Audit kann zeigen, welche Namespaces produktiv sind.

---

6. Deployment für den Order Service

Ein Deployment beschreibt, wie ein Service ausgeführt wird. Es sollte nicht nur Image und Port enthalten. Für einen produktionsnahen Service gehören Ressourcenlimits, Probes, Labels und Konfigurationsquellen dazu.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service
  namespace: order-prod
  labels:
    app.kubernetes.io/name: order-service
    app.kubernetes.io/part-of: order-domain
spec:
  replicas: 2
  revisionHistoryLimit: 5
  selector:
    matchLabels:
      app.kubernetes.io/name: order-service
  template:
    metadata:
      labels:
        app.kubernetes.io/name: order-service
        app.kubernetes.io/part-of: order-domain
        environment: prod
    spec:
      serviceAccountName: order-service
      containers:
        - name: order-service
          image: registry.example.com/alpine/order-service:1.0.0
          imagePullPolicy: IfNotPresent
          ports:
            - name: http
              containerPort: 8080
          envFrom:
            - configMapRef:
                name: order-service-config
            - secretRef:
                name: order-service-secret
          readinessProbe:
            httpGet:
              path: /actuator/health/readiness
              port: http
            initialDelaySeconds: 20
            periodSeconds: 10
            timeoutSeconds: 3
            failureThreshold: 3
          livenessProbe:
            httpGet:
              path: /actuator/health/liveness
              port: http
            initialDelaySeconds: 60
            periodSeconds: 20
            timeoutSeconds: 3
            failureThreshold: 3
          resources:
            requests:
              cpu: class="str">"250m"
              memory: class="str">"512Mi"
            limits:
              cpu: class="str">"1000m"
              memory: class="str">"1024Mi"
          securityContext:
            allowPrivilegeEscalation: false
            runAsNonRoot: true
            capabilities:
              drop:
                - ALL

Dieses Manifest zeigt mehrere wichtige Entscheidungen. Der Service läuft nicht als privilegierter Container. Er hat klare Ressourcen. Die Health Checks unterscheiden zwischen readiness und liveness. Konfiguration wird nicht fest ins Image geschrieben, sondern über ConfigMap und Secret geliefert.

---

7. Readiness und Liveness richtig verstehen

Readiness und Liveness werden häufig verwechselt.

Readiness bedeutet: Kann dieser Pod gerade Traffic annehmen?

Liveness bedeutet: Ist dieser Pod grundsätzlich noch lebendig, oder muss er neu gestartet werden?

Ein Pod kann lebendig sein, aber nicht ready. Zum Beispiel wenn die Anwendung startet, aber die Datenbankverbindung noch nicht aufgebaut ist. In diesem Fall soll Kubernetes den Pod nicht töten, sondern nur noch keinen Traffic schicken.

Ein häufiger Fehler ist, die Liveness Probe zu streng zu machen. Wenn eine Datenbank kurz langsam ist und die Liveness Probe deshalb fehlschlägt, startet Kubernetes die Anwendung ständig neu. Dadurch wird die Störung schlimmer.

Besser ist:

Für Spring Boot kann man getrennte Actuator-Endpunkte nutzen:

management:
  endpoint:
    health:
      probes:
        enabled: true
  health:
    livenessstate:
      enabled: true
    readinessstate:
      enabled: true

---

8. Service und Route

Ein Deployment allein macht eine Anwendung noch nicht stabil erreichbar. Pods haben wechselnde IPs. Ein Kubernetes Service gibt ihnen eine stabile interne Adresse.

apiVersion: v1
kind: Service
metadata:
  name: order-service
  namespace: order-prod
  labels:
    app.kubernetes.io/name: order-service
spec:
  type: ClusterIP
  selector:
    app.kubernetes.io/name: order-service
  ports:
    - name: http
      port: 8080
      targetPort: http

In OpenShift kann eine Route diesen Service nach außen verfügbar machen.

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: order-service
  namespace: order-prod
spec:
  host: api.alpine.example.com
  path: /orders
  to:
    kind: Service
    name: order-service
  port:
    targetPort: http
  tls:
    termination: edge
    insecureEdgeTerminationPolicy: Redirect

Diese Route nutzt TLS am Edge. In manchen Umgebungen ist Re-Encrypt besser, wenn die Verbindung vom Router zum Pod ebenfalls verschlüsselt bleiben soll. Diese Entscheidung hängt von Sicherheitsanforderungen und Zertifikatsmodell ab.

---

9. ConfigMap und Secret

Konfiguration und Secrets müssen getrennt werden. Eine ConfigMap enthält nicht-sensitive Einstellungen. Ein Secret enthält sensible Werte wie Passwörter, Tokens oder Zertifikatsmaterial.

apiVersion: v1
kind: ConfigMap
metadata:
  name: order-service-config
  namespace: order-prod
data:
  SPRING_PROFILES_ACTIVE: class="str">"openshift,prod"
  ORDER_OUTBOX_BATCH_SIZE: class="str">"100"
  KAFKA_BOOTSTRAP_SERVERS: class="str">"kafka.messaging-prod.svc.cluster.local:9092"

apiVersion: v1
kind: Secret
metadata:
  name: order-service-secret
  namespace: order-prod
type: Opaque
stringData:
  DB_HOST: class="str">"orders-db.internal.alpine.example.com"
  DB_PORT: class="str">"5432"
  DB_NAME: class="str">"orders"
  DB_USERNAME: class="str">"order_app"
  DB_PASSWORD: class="str">"change-me-in-real-secret-management"

In einer produktionsnahen Umgebung sollte das Secret nicht dauerhaft als Klartext in Git liegen. Besser sind External Secrets, Sealed Secrets, Vault oder ein anderes Secret-Management-Verfahren. Im Lab wird später External Secrets behandelt.

---

10. Resource Requests und Limits

Kubernetes plant Pods anhand von Requests. Limits begrenzen den maximalen Verbrauch. Ohne Requests weiß der Scheduler nicht zuverlässig, wie viel Kapazität ein Pod braucht. Ohne Limits kann ein fehlerhafter Prozess zu viel Speicher oder CPU verbrauchen.

Beispiel:

resources:
  requests:
    cpu: class="str">"250m"
    memory: class="str">"512Mi"
  limits:
    cpu: class="str">"1000m"
    memory: class="str">"1024Mi"

Das bedeutet nicht, dass jeder Service genau diese Werte braucht. Werte müssen beobachtet und angepasst werden. Für Java-Anwendungen ist Speicher besonders wichtig, weil JVM Heap, Metaspace, Threads und native Speicherbereiche berücksichtigt werden müssen.

Ein häufiger Fehler ist, ein Java-Container-Limit auf 512 MiB zu setzen und der JVM gleichzeitig einen zu großen Heap zu erlauben. Dann wird der Pod vom Kernel beendet, oft als OOMKilled.

Besser ist, JVM-Parameter und Container-Limits gemeinsam zu betrachten:

---

11. ServiceAccount und RBAC

Jeder Service sollte mit einem eigenen ServiceAccount laufen. Dadurch kann man Berechtigungen gezielt vergeben.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: order-service
  namespace: order-prod

Der Order Service braucht normalerweise keine Rechte, um Kubernetes-Ressourcen zu lesen oder zu ändern. Deshalb bekommt er keine breiten Cluster-Rollen.

Ein häufiger Fehler ist, Anwendungen mit zu vielen Rechten laufen zu lassen. Zum Beispiel mit Admin-Rechten im Namespace oder sogar Cluster-Rechten. Das ist gefährlich, wenn die Anwendung kompromittiert wird.

RBAC-Regel:

---

12. SecurityContext und OpenShift SCC

Container sollten nicht als root laufen. Privilege Escalation sollte deaktiviert werden. Linux Capabilities sollten entfernt werden, wenn sie nicht gebraucht werden.

securityContext:
  allowPrivilegeEscalation: false
  runAsNonRoot: true
  capabilities:
    drop:
      - ALL

OpenShift hat zusätzlich Security Context Constraints. Diese bestimmen, welche Sicherheitskontexte Pods verwenden dürfen. OpenShift ist hier oft strenger als ein Standard-Kubernetes-Cluster. Das ist gut, weil unsichere Container schneller auffallen.

Ein typischer Fehler ist ein Container Image, das erwartet, als root zu laufen oder in feste Verzeichnisse schreiben zu dürfen. In OpenShift kann das scheitern.

Besser ist:

---

13. NetworkPolicy für den Order Service

Eine produktionsnahe Plattform sollte nicht erlauben, dass jeder Pod mit jedem anderen Pod spricht. NetworkPolicies begrenzen Kommunikation.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: order-service-egress
  namespace: order-prod
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/name: order-service
  policyTypes:
    - Egress
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: messaging-prod
      ports:
        - protocol: TCP
          port: 9092
    - to:
        - ipBlock:
            cidr: 10.10.40.25/32
      ports:
        - protocol: TCP
          port: 5432
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: security-keycloak
      ports:
        - protocol: TCP
          port: 8443

Diese Policy erlaubt nur Kafka, die externe Datenbank-IP und Keycloak. In echten Umgebungen muss man außerdem DNS-Zugriffe berücksichtigen, da Services Namen auflösen müssen.

---

14. Persistent Volumes und wann man sie vermeidet

Nicht jede Anwendung braucht persistentes Volume. Moderne Backend-Services sollten nach Möglichkeit zustandslos sein. Daten liegen in Datenbanken, Object Storage oder spezialisierten Systemen.

Persistent Volumes sind sinnvoll für:

Für den Order Service ist ein PersistentVolume meistens nicht nötig. Der Service speichert fachliche Daten in PostgreSQL und Events in der Outbox-Tabelle. Lokale Dateien wären riskant, weil Pods verschoben oder neu gestartet werden können.

Ein typischer Fehler ist:

Besser:

---

15. Jobs und CronJobs

Nicht jede Aufgabe ist ein dauerhaft laufender Service. Manche Aufgaben laufen einmalig oder regelmäßig. Dafür gibt es Jobs und CronJobs.

Beispiel: nächtlicher Reporting-Export.

apiVersion: batch/v1
kind: CronJob
metadata:
  name: nightly-order-report
  namespace: reporting-prod
spec:
  schedule: class="str">"0 2 * * *"
  concurrencyPolicy: Forbid
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 5
  jobTemplate:
    spec:
      backoffLimit: 2
      template:
        spec:
          restartPolicy: Never
          containers:
            - name: report-generator
              image: registry.example.com/alpine/reporting-service:1.0.0
              args:
                - class="str">"generate-nightly-order-report"
              envFrom:
                - configMapRef:
                    name: reporting-config
                - secretRef:
                    name: reporting-secret
              resources:
                requests:
                  cpu: class="str">"500m"
                  memory: class="str">"1Gi"
                limits:
                  cpu: class="str">"2000m"
                  memory: class="str">"4Gi"

concurrencyPolicy: Forbid verhindert, dass ein neuer Lauf startet, während der vorherige noch läuft. Das ist bei Reporting wichtig, damit keine doppelten Exporte entstehen.

---

16. GitOps mit Argo CD

GitOps bedeutet: Der gewünschte Zustand der Plattform liegt in Git. Argo CD vergleicht diesen Zustand mit dem Cluster und synchronisiert Änderungen.

Der Vorteil ist Nachvollziehbarkeit. Niemand muss per Hand oc apply ausführen, ohne dass Git den Zielzustand kennt. Jede Änderung wird als Pull Request sichtbar, geprüft und versioniert.

Beispiel für eine Argo CD Application:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: order-service-prod
  namespace: platform-gitops
spec:
  project: order-domain
  source:
    repoURL: https://git.example.com/alpine/platform-config.git
    targetRevision: main
    path: apps/order-service/overlays/prod
  destination:
    server: https://kubernetes.default.svc
    namespace: order-prod
  syncPolicy:
    automated:
      prune: false
      selfHeal: true
    syncOptions:
      - CreateNamespace=false

In Produktion ist prune manchmal bewusst deaktiviert oder stark kontrolliert, damit Ressourcen nicht versehentlich gelöscht werden. Für Testumgebungen kann eine aggressivere Automatisierung sinnvoll sein.

---

17. Kustomize-Struktur

Für das Lab eignet sich Kustomize, um gemeinsame Basis-Manifeste und umgebungsspezifische Overlays zu trennen.

platform-config/
└── apps/
    └── order-service/
        ├── base/
        │   ├── deployment.yaml
        │   ├── service.yaml
        │   ├── route.yaml
        │   ├── configmap.yaml
        │   ├── serviceaccount.yaml
        │   └── kustomization.yaml
        └── overlays/
            ├── dev/
            │   ├── kustomization.yaml
            │   └── patch-replicas.yaml
            ├── test/
            │   ├── kustomization.yaml
            │   └── patch-resources.yaml
            └── prod/
                ├── kustomization.yaml
                ├── patch-replicas.yaml
                ├── patch-resources.yaml
                └── patch-route-host.yaml

Der Vorteil: Die Grundstruktur bleibt gleich, aber Produktionswerte unterscheiden sich kontrolliert von Dev-Werten.

---

18. Helm oder Kustomize?

Helm und Kustomize lösen ähnliche, aber nicht identische Probleme.

Helm ist stark, wenn man parametrisierte Pakete veröffentlichen will. Viele Plattformkomponenten werden als Helm Charts bereitgestellt. Kustomize ist stark, wenn man vorhandene YAML-Manifeste über Overlays anpassen will.

Für Anwendungen im Lab nutzen wir bevorzugt Kustomize, weil es einfach nachvollziehbar ist. Für Plattformkomponenten wie Prometheus, Grafana, Loki oder externe Operatoren kann Helm sinnvoll sein.

Die Regel lautet:

Wichtig ist, nicht beides chaotisch zu vermischen. Ein Team sollte klar dokumentieren, welche Methode es verwendet.

---

19. Build, Image und Registry

Ein Container Image ist ein Lieferartefakt. Es muss versioniert, gescannt und nachvollziehbar sein.

Ein gutes Image hat:

Beispiel für ein Spring Boot Dockerfile:

FROM eclipse-temurin:21-jre-alpine

WORKDIR /app

RUN addgroup -S app && adduser -S app -G app

COPY target/order-service.jar /app/order-service.jar

USER app

EXPOSE 8080

ENTRYPOINT [class="str">"java", class="str">"-XX:MaxRAMPercentage=70", class="str">"-jar", class="str">"/app/order-service.jar"]

Dieses Image ist bewusst einfach. In einer erweiterten Version könnte man Distroless Images, Buildpacks oder mehrstufige Builds verwenden.

---

20. Beispiel: GitHub Actions Pipeline

name: order-service-ci

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  build-test-scan:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Set up Java
        uses: actions/setup-java@v4
        with:
          distribution: temurin
          java-version: class="str">'21'
          cache: maven

      - name: Build and test
        run: mvn -B clean verify

      - name: Build container image
        run: |
          docker build -t registry.example.com/alpine/order-service:${{ github.sha }} .

      - name: Scan image
        run: |
          trivy image --exit-code 1 --severity HIGH,CRITICAL registry.example.com/alpine/order-service:${{ github.sha }}

      - name: Push image
        if: github.ref == class="str">'refs/heads/main'
        run: |
          docker push registry.example.com/alpine/order-service:${{ github.sha }}

Diese Pipeline baut nicht nur Code. Sie testet, baut ein Image und scannt es. In einem vollständigen GitOps-Prozess würde danach ein Pull Request im Plattform-Repository den Image-Tag aktualisieren.

---

21. Observability im Cluster

Ein Service muss im Cluster beobachtbar sein. Dazu gehören Logs, Metriken und Traces.

Für Prometheus braucht man oft einen ServiceMonitor:

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: order-service
  namespace: order-prod
  labels:
    release: platform-monitoring
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: order-service
  endpoints:
    - port: http
      path: /actuator/prometheus
      interval: 30s

Wenn dieser ServiceMonitor fehlt, läuft der Service vielleicht korrekt, aber niemand sammelt seine Metriken. Dadurch fehlen Dashboards und Alerts.

Wichtige Metriken für den Order Service:

---

22. Alerts für den Order Service

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: order-service-alerts
  namespace: order-prod
spec:
  groups:
    - name: order-service.rules
      rules:
        - alert: OrderServiceHighErrorRate
          expr: |
            sum(rate(http_server_requests_seconds_count{namespace=class="str">"order-prod",status=~class="str">"5.."}[5m]))
            /
            sum(rate(http_server_requests_seconds_count{namespace=class="str">"order-prod"}[5m])) > 0.05
          for: 10m
          labels:
            severity: warning
            service: order-service
          annotations:
            summary: class="str">"Order Service has high HTTP 5xx error rate"
            description: class="str">"More than 5 percent of requests failed for 10 minutes."

        - alert: OrderOutboxBacklogGrowing
          expr: order_outbox_pending_events > 1000
          for: 15m
          labels:
            severity: critical
            service: order-service
          annotations:
            summary: class="str">"Order outbox backlog is growing"
            description: class="str">"Pending outbox events exceed threshold. Billing may not receive new orders."

Diese Alerts verbinden technische Metriken mit fachlichen Risiken. Ein wachsender Outbox-Rückstand bedeutet nicht nur ein technisches Problem. Es bedeutet, dass Folgeprozesse wie Billing verzögert werden.

---

23. Rollout-Strategien

Kubernetes Deployments unterstützen Rolling Updates. Dabei werden alte Pods schrittweise durch neue ersetzt. Das funktioniert gut, wenn die Anwendung rückwärtskompatibel ist.

Ein Problem entsteht, wenn neue Anwendungsversion und Datenbankschema nicht zusammenpassen. Deshalb müssen Datenbankmigrationen vorsichtig geplant werden.

Eine robuste Regel lautet:

Beispiel:

Für kritische Systeme können Blue/Green oder Canary Deployments sinnvoll sein. Im Lab beginnen wir mit Rolling Updates und erklären später erweiterte Strategien.

---

24. PodDisruptionBudget

Ein PodDisruptionBudget verhindert, dass bei geplanten Wartungen zu viele Pods gleichzeitig verschwinden.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: order-service-pdb
  namespace: order-prod
spec:
  minAvailable: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: order-service

Bei zwei Replicas stellt minAvailable: 1 sicher, dass mindestens ein Pod verfügbar bleiben soll. Das hilft bei Node-Wartungen, ersetzt aber keine echte Hochverfügbarkeitsplanung.

---

25. Typische Fehler in Kubernetes/OpenShift

Ein häufiger Fehler ist, nur ein Deployment zu erstellen und alles andere zu vergessen. Ohne Service, Route, Probes, Limits, SecurityContext und Monitoring ist der Service nicht produktionsnah.

Ein zweiter Fehler ist, Secrets direkt ins Image oder in Git zu schreiben. Das macht Rotation schwierig und erhöht das Risiko bei Leaks.

Ein dritter Fehler ist, alle Workloads mit Admin-Rechten laufen zu lassen. Das widerspricht Least Privilege.

Ein vierter Fehler ist fehlende NetworkPolicy. Dann kann eine kompromittierte Anwendung möglicherweise zu vielen internen Zielen sprechen.

Ein fünfter Fehler ist falsche Liveness Probe. Zu aggressive Liveness Checks erzeugen Neustart-Schleifen und verschlimmern Störungen.

Ein sechster Fehler ist fehlende Ressourcenplanung. Ohne Requests und Limits kann der Cluster Pods schlecht planen und bei Last instabil werden.

Ein siebter Fehler ist blinde Helm-Nutzung. Wenn niemand versteht, welche Ressourcen ein Chart erzeugt, wird Betrieb schwierig.

---

26. Runbook: Pod startet nicht

oc get pods -n order-prod -l app.kubernetes.io/name=order-service

oc describe pod -n order-prod -l app.kubernetes.io/name=order-service

oc logs -n order-prod deployment/order-service --previous

oc logs -n order-prod deployment/order-service --tail=200

oc get events -n order-prod --sort-by=.metadata.creationTimestamp

oc get secret -n order-prod

oc get configmap order-service-config -n order-prod -o yaml

oc get secret order-service-secret -n order-prod -o yaml

Dieses Runbook ist ein Beispiel dafür, wie Kubernetes-Betrieb konkret beschrieben wird. Es verbindet Status, Events, Logs, Konfiguration und Verantwortlichkeiten.

---

27. Übung: Order Service produktionsnah machen

Erstelle eine produktionsnahe Ressourcenliste für den Order Service.

Sie soll enthalten:

Beschreibe für jede Ressource, warum sie gebraucht wird.

---

28. Musterlösung zur Übung

Eine mögliche Antwort:

---

29. Merksätze

Teil C: Identity, Security, Governance und Plattformregeln

Konsolidiert aus Rohmaterial: Teil 6.

Identity, Security und Governance

1. Warum Identity und Security nicht nachträglich angeklebt werden dürfen

In einer modernen Enterprise-Plattform ist Security kein späteres Zusatzkapitel. Sie bestimmt, wie Benutzer auf Anwendungen zugreifen, wie Services miteinander sprechen, wie Secrets geschützt werden, wie Änderungen genehmigt werden und wie ein Audit später nachvollziehen kann, was passiert ist.

Wenn Security erst am Ende eingebaut wird, entstehen typische Probleme:

Identity und Security müssen deshalb von Anfang an mitgedacht werden. In diesem Lab bedeutet das: Jede Anwendung bekommt eine klare Authentifizierungsstrategie, ein Rollenmodell, technische Zugriffskontrollen, Secret-Management, Audit-Logging und dokumentierte Governance-Regeln.

Der wichtigste Grundsatz lautet:

---

2. Identity als zentrales Plattformthema

Identity beantwortet die Frage: Wer oder was greift auf ein System zu?

Dabei gibt es zwei Arten von Identitäten:

Ein häufiger Fehler ist, nur menschliche Benutzer zu betrachten. In einer Enterprise-Plattform sind technische Identitäten mindestens genauso wichtig. Ein Billing Service, der Events konsumiert, braucht eine technische Identität. Ein Argo CD Controller, der Deployments ausführt, braucht Rechte. Ein CI Runner, der Container Images baut, braucht Zugriff auf Registry und Quellcode.

Das Ziel ist nicht, allen Identitäten möglichst viele Rechte zu geben. Das Ziel ist, jeder Identität genau die Rechte zu geben, die sie für ihre Aufgabe braucht.

---

3. Keycloak im Zielbild

Im Lab verwenden wir Keycloak als Identity Provider. Keycloak übernimmt Login, Token-Ausstellung, OIDC-Flows, Rollen und die Anbindung an ein bestehendes LDAP oder Active Directory.

Die Zielarchitektur sieht so aus:

flowchart LR
    User[Kunde oder Mitarbeiter] --> Portal[Customer Portal / Admin Portal]
    Portal --> Keycloak[Keycloak]
    Keycloak --> LDAP[LDAP / Active Directory]
    Portal --> API[Backend API]
    API --> TokenCheck[Token Validierung]
    TokenCheck --> Roles[Rollen und Claims]

Keycloak ist dabei nicht nur ein Login-Bildschirm. Keycloak ist ein zentrales Sicherheitssystem. Es entscheidet, welche Clients existieren, welche Redirect-URIs erlaubt sind, welche Rollen vergeben werden und welche Token-Informationen an Anwendungen weitergegeben werden.

Für das Lab gibt es mehrere Clients:

Das Customer Portal verwendet einen Browser-basierten OIDC-Flow. Das Admin Portal benötigt strengere Rollen. Service-zu-Service-Kommunikation kann über Client Credentials oder interne Plattformmechanismen abgesichert werden.

---

4. Unterschied zwischen Authentifizierung und Autorisierung

Authentifizierung beantwortet:

Autorisierung beantwortet:

Ein Benutzer kann korrekt angemeldet sein und trotzdem nicht berechtigt sein, eine bestimmte Aktion auszuführen.

Beispiel:

Im Code muss dieser Unterschied sichtbar sein. Ein API-Endpunkt darf nicht nur prüfen, ob ein Token vorhanden ist. Er muss prüfen, ob die passende Rolle oder Berechtigung vorhanden ist.

---

5. Rollenmodell für das Lab

Für das Lab definieren wir fachliche Rollen:

Diese Rollen dürfen nicht zufällig wachsen. Jede Rolle braucht eine Bedeutung.

Beispiele:

Wichtig ist: Rollen sind fachliche Begriffe. Kubernetes RBAC ist ein technischer Mechanismus. Beides darf nicht verwechselt werden.

---

6. Keycloak Realm-Konzept

Ein Realm in Keycloak ist ein abgegrenzter Sicherheitsbereich. Für das Lab verwenden wir einen Realm:

Darin liegen Clients, Rollen, Gruppen und Benutzerzuordnungen.

Beispielhafte Struktur:

Realm: alpine-enterprise
├── Clients
│   ├── customer-portal
│   ├── admin-portal
│   ├── order-service
│   └── billing-service
├── Realm Roles
│   ├── CUSTOMER
│   ├── SUPPORT_AGENT
│   ├── ORDER_MANAGER
│   ├── BILLING_SPECIALIST
│   └── SECURITY_AUDITOR
├── Groups
│   ├── customers
│   ├── support
│   ├── billing
│   └── platform-ops
└── Identity Provider
    └── LDAP / Active Directory

In produktionsnahen Umgebungen muss man entscheiden, ob Entwicklung, Test und Produktion getrennte Realms oder getrennte Keycloak-Instanzen verwenden. Für ein Lab reicht oft ein Realm mit klaren Umgebungsclients. Für echte Produktion ist stärkere Trennung sinnvoll.

---

7. Beispiel: Keycloak Client-Konfiguration als JSON

{
  class="str">"clientId": class="str">"admin-portal",
  class="str">"name": class="str">"Admin Portal",
  class="str">"protocol": class="str">"openid-connect",
  class="str">"publicClient": true,
  class="str">"standardFlowEnabled": true,
  class="str">"directAccessGrantsEnabled": false,
  class="str">"redirectUris": [
    class="str">"https://admin.alpine.example.com/*"
  ],
  class="str">"webOrigins": [
    class="str">"https://admin.alpine.example.com"
  ],
  class="str">"attributes": {
    class="str">"pkce.code.challenge.method": class="str">"S256"
  }
}

Diese Konfiguration zeigt mehrere wichtige Punkte. Das Admin Portal ist ein Browser-Client. Es nutzt den Standard Flow und PKCE. Direct Access Grants sind deaktiviert, weil Passwörter nicht direkt an die Anwendung gegeben werden sollen. Redirect-URIs sind explizit eingeschränkt.

Ein häufiger Fehler wäre:

Das ist bequem, aber gefährlich. Es öffnet die Tür für Redirect-Missbrauch.

---

8. OIDC-Token und Claims

Ein OIDC-Token enthält Claims. Claims sind Aussagen über Benutzer oder technische Clients.

Beispiele:

{
  class="str">"sub": class="str">"9f7a2d4c-1234-44f0-91a1-abcdef123456",
  class="str">"preferred_username": class="str">"maria.schmidt",
  class="str">"email": class="str">"maria.schmidt@example.com",
  class="str">"realm_access": {
    class="str">"roles": [
      class="str">"SUPPORT_AGENT",
      class="str">"REPORTING_VIEWER"
    ]
  },
  class="str">"aud": class="str">"admin-portal",
  class="str">"iss": class="str">"https://keycloak.alpine.example.com/realms/alpine-enterprise"
}

Eine Anwendung darf Claims nicht blind vertrauen, wenn Token-Signatur, Issuer und Audience nicht geprüft wurden. Ein Token ist nur gültig, wenn es von der richtigen Quelle kommt, korrekt signiert ist, nicht abgelaufen ist und für den erwarteten Client oder Service bestimmt ist.

---

9. Spring Security im Order Service

Der Order Service soll Token validieren und Rollen auswerten.

package com.seb4u.demo.spring.order.infrastructure.security;

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.core.convert.converter.Converter;
import org.springframework.security.authentication.AbstractAuthenticationToken;
import org.springframework.security.config.annotation.method.configuration.EnableMethodSecurity;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.oauth2.jwt.Jwt;
import org.springframework.security.oauth2.server.resource.authentication.JwtAuthenticationConverter;
import org.springframework.security.web.SecurityFilterChain;

@Configuration
@EnableMethodSecurity
public class SecurityConfiguration {

    @Bean
    SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        return http
                .authorizeHttpRequests(auth -> auth
                        .requestMatchers(class="str">"/actuator/health/**").permitAll()
                        .requestMatchers(class="str">"/actuator/prometheus").hasRole(class="str">"PLATFORM_OPERATOR")
                        .requestMatchers(class="str">"/api/orders/**").authenticated()
                        .anyRequest().denyAll()
                )
                .oauth2ResourceServer(oauth2 -> oauth2
                        .jwt(jwt -> jwt.jwtAuthenticationConverter(jwtAuthenticationConverter()))
                )
                .build();
    }

    @Bean
    Converter<Jwt, AbstractAuthenticationToken> jwtAuthenticationConverter() {
        JwtAuthenticationConverter converter = new JwtAuthenticationConverter();
        converter.setJwtGrantedAuthoritiesConverter(new KeycloakRealmRoleConverter());
        return converter;
    }
}

Diese Konfiguration macht mehrere Dinge bewusst:

---

10. Keycloak-Rollen in Spring Authorities übersetzen

package com.seb4u.demo.spring.order.infrastructure.security;

import org.springframework.core.convert.converter.Converter;
import org.springframework.security.core.GrantedAuthority;
import org.springframework.security.core.authority.SimpleGrantedAuthority;
import org.springframework.security.oauth2.jwt.Jwt;

import java.util.Collection;
import java.util.List;
import java.util.Map;
import java.util.stream.Collectors;

public class KeycloakRealmRoleConverter implements Converter<Jwt, Collection<GrantedAuthority>> {

    @Override
    public Collection<GrantedAuthority> convert(Jwt jwt) {
        Map<String, Object> realmAccess = jwt.getClaimAsMap(class="str">"realm_access");

        if (realmAccess == null || !realmAccess.containsKey(class="str">"roles")) {
            return List.of();
        }

        Object rolesObject = realmAccess.get(class="str">"roles");

        if (!(rolesObject instanceof Collection<?> roles)) {
            return List.of();
        }

        return roles.stream()
                .filter(String.class::isInstance)
                .map(String.class::cast)
                .map(role -> new SimpleGrantedAuthority(class="str">"ROLE_" + role))
                .collect(Collectors.toUnmodifiableSet());
    }
}

Dieser Code ist klein, aber wichtig. Ohne solche Übersetzung sieht Spring die Keycloak-Rollen oft nicht in der erwarteten Form.

Ein typischer Fehler ist, Rollen im Token zu haben, aber im Code hasRole("ORDER_MANAGER") zu verwenden, ohne die Rollen vorher als ROLE_ORDER_MANAGER bereitzustellen.

---

11. Method Security im Use Case

Security sollte nicht nur im Controller stehen. Kritische Aktionen sollten auch an der Anwendungsschicht abgesichert werden.

package com.seb4u.demo.spring.order.application;

import org.springframework.security.access.prepost.PreAuthorize;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;

@Service
public class OrderApprovalService {

    private final OrderRepository orderRepository;
    private final AuditLog auditLog;

    public OrderApprovalService(OrderRepository orderRepository, AuditLog auditLog) {
        this.orderRepository = orderRepository;
        this.auditLog = auditLog;
    }

    @Transactional
    @PreAuthorize(class="str">"hasRole('ORDER_MANAGER')")
    public void approveOrder(String orderId, String reason) {
        Order order = orderRepository.findRequired(orderId);
        order.approve(reason);
        orderRepository.save(order);

        auditLog.record(
                class="str">"ORDER_APPROVED",
                orderId,
                class="str">"Order approved with reason: " + reason
        );
    }
}

Der Vorteil: Selbst wenn später ein zweiter Controller oder ein interner API-Pfad diese Methode aufruft, bleibt die Sicherheitsregel erhalten.

---

12. Kubernetes RBAC ist etwas anderes als Fachrollen

Kubernetes RBAC steuert, was ein Benutzer oder ServiceAccount im Cluster darf.

Beispiel:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: order-service
  namespace: order-prod
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: order-service-config-reader
  namespace: order-prod
rules:
  - apiGroups: [class="str">""]
    resources: [class="str">"configmaps"]
    verbs: [class="str">"get", class="str">"list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: order-service-config-reader-binding
  namespace: order-prod
subjects:
  - kind: ServiceAccount
    name: order-service
    namespace: order-prod
roleRef:
  kind: Role
  name: order-service-config-reader
  apiGroup: rbac.authorization.k8s.io

Diese YAML-Datei hat nichts mit der fachlichen Rolle ORDER_MANAGER zu tun. Sie beschreibt, was der Pod im Cluster darf. Eine fachliche Rolle beschreibt, was ein Benutzer in der Anwendung darf.

Beide Ebenen sind nötig.

---

13. ServiceAccount-Fehler, die man vermeiden muss

Ein sehr gefährlicher Fehler ist, Anwendungen mit zu mächtigen ServiceAccounts laufen zu lassen.

Schlecht:

Warum schlecht?

Besser:

Viele Anwendungen brauchen überhaupt keinen Zugriff auf die Kubernetes API. Dann sollte ihnen auch kein besonderer Zugriff gegeben werden.

---

14. Secrets: Warum sie besonders behandelt werden müssen

Secrets sind Zugangsdaten oder vertrauliche Informationen.

Beispiele:

Ein Secret darf nicht in Klartext in Git liegen. Auch nicht in einem privaten Repository, wenn es vermeidbar ist.

Es gibt mehrere Möglichkeiten:

Für ein Enterprise-Lab ist External Secrets oder Vault sinnvoll, weil GitOps dann keine Klartext-Secrets enthält.

---

15. ExternalSecret Beispiel

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: order-db-secret
  namespace: order-prod
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: platform-vault
    kind: ClusterSecretStore
  target:
    name: order-db-secret
    creationPolicy: Owner
  data:
    - secretKey: username
      remoteRef:
        key: prod/order/postgres
        property: username
    - secretKey: password
      remoteRef:
        key: prod/order/postgres
        property: password
    - secretKey: host
      remoteRef:
        key: prod/order/postgres
        property: host

Diese Definition enthält nicht das Passwort. Sie beschreibt nur, woher das Passwort geladen wird. Das ist ein wichtiger Unterschied.

---

16. Secret Rotation

Secret Rotation bedeutet, Zugangsdaten regelmäßig oder anlassbezogen zu erneuern.

Anlässe:

Ein Secret-Rotation-Prozess muss beantworten:

Ohne Prozess kann Secret Rotation gefährlich werden, weil produktive Systeme plötzlich keine Datenbankverbindung mehr bekommen.

---

17. SecurityContext für Pods

Container sollten nicht unnötig privilegiert laufen.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service
  namespace: order-prod
spec:
  template:
    spec:
      serviceAccountName: order-service
      containers:
        - name: order-service
          image: registry.example.com/alpine/order-service:1.0.0
          securityContext:
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            runAsNonRoot: true
            capabilities:
              drop:
                - ALL

Diese Einstellungen reduzieren Angriffsmöglichkeiten. Nicht jede Anwendung funktioniert sofort mit read-only Root Filesystem. Dann muss man bewusst temporäre Verzeichnisse konfigurieren, statt die Sicherheitsregel einfach zu entfernen.

---

18. OpenShift SCC

OpenShift verwendet Security Context Constraints. SCCs steuern, welche Sicherheitskontexte Pods verwenden dürfen.

Ein häufiger Anfängerfehler ist, bei Problemen sofort eine privilegierte SCC zu vergeben.

Schlecht:

oc adm policy add-scc-to-user privileged -z order-service -n order-prod

Das löst kurzfristig Startprobleme, öffnet aber ein großes Sicherheitsloch.

Besser ist, die Ursache zu verstehen:

Security-Härtung bedeutet oft, das Image und die Anwendung sauberer zu bauen, nicht die Plattformregeln abzuschalten.

---

19. Network Security und Zero Trust

Zero Trust bedeutet nicht, dass man niemandem vertraut und alles blockiert. Es bedeutet: Vertrauen wird nicht aus Netzwerkposition abgeleitet.

Früher war ein typisches Denken:

Modernes Denken:

Für das Lab heißt das:

---

20. Audit Logging

Audit Logging beantwortet nicht nur die Frage, was technisch passiert ist. Es beantwortet fachliche Nachweisfragen.

Beispiele:

Ein Audit-Log muss vorsichtig gestaltet werden. Es darf genug Informationen enthalten, um Vorgänge nachzuvollziehen, aber keine unnötigen sensiblen Daten speichern.

Guter Audit-Eintrag:

{
  class="str">"eventType": class="str">"ORDER_APPROVED",
  class="str">"actor": class="str">"maria.schmidt",
  class="str">"actorType": class="str">"USER",
  class="str">"resourceType": class="str">"ORDER",
  class="str">"resourceId": class="str">"ORD-2026-00091",
  class="str">"timestamp": class="str">"2026-07-05T18:45:12Z",
  class="str">"traceId": class="str">"5f2a9a3c8e4b",
  class="str">"outcome": class="str">"SUCCESS"
}

Schlechter Audit-Eintrag:

{
  class="str">"message": class="str">"Maria approved order with customer email, address, full payment data and internal notes"
}

Audit Logging ist kein Ort für Datenablage. Es ist ein Nachweisprotokoll.

---

21. Audit Service Beispiel

package com.seb4u.demo.spring.order.infrastructure.audit;

import org.springframework.jdbc.core.JdbcTemplate;
import org.springframework.stereotype.Component;

import java.time.Clock;
import java.time.Instant;
import java.util.UUID;

@Component
public class JdbcAuditLog implements AuditLog {

    private final JdbcTemplate jdbcTemplate;
    private final CurrentActorProvider currentActorProvider;
    private final TraceIdProvider traceIdProvider;
    private final Clock clock;

    public JdbcAuditLog(
            JdbcTemplate jdbcTemplate,
            CurrentActorProvider currentActorProvider,
            TraceIdProvider traceIdProvider,
            Clock clock
    ) {
        this.jdbcTemplate = jdbcTemplate;
        this.currentActorProvider = currentActorProvider;
        this.traceIdProvider = traceIdProvider;
        this.clock = clock;
    }

    @Override
    public void record(String eventType, String resourceId, String summary) {
        jdbcTemplate.update(class="str">"""
                INSERT INTO audit_events
                (id, event_type, actor, resource_id, summary, trace_id, created_at)
                VALUES (?, ?, ?, ?, ?, ?, ?)
                class="str">""",
                UUID.randomUUID(),
                eventType,
                currentActorProvider.currentActor(),
                resourceId,
                summary,
                traceIdProvider.currentTraceId(),
                Instant.now(clock)
        );
    }
}

Der Code zeigt bewusst mehrere Abhängigkeiten: aktueller Benutzer, Trace-ID und Zeit. Dadurch können Audit-Einträge später mit Logs und Traces verbunden werden.

---

22. Governance: Regeln für kontrollierte Veränderung

Governance bedeutet nicht Bürokratie um der Bürokratie willen. Governance bedeutet, dass wichtige Änderungen nachvollziehbar, überprüfbar und verantwortet sind.

Im Lab betrifft Governance vor allem:

Eine gute Governance-Regel ist konkret. Eine schlechte Regel ist allgemein.

Schlecht:

Besser:

---

23. Pull Request Regeln

Jede Änderung an produktionsnahen Artefakten läuft über Pull Request.

Ein PR muss beantworten:

Beispiel-Template:

Dieses Template verhindert nicht alle Fehler, aber es zwingt zu besseren Fragen.

---

24. Policy as Code

Policy as Code bedeutet, dass Regeln maschinenlesbar beschrieben und automatisch geprüft werden.

Beispiele für Regeln:

Solche Regeln können mit Tools wie Kyverno, OPA Gatekeeper, Conftest oder CI-Skripten geprüft werden.

Beispiel einer Kyverno-Regel:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-resource-limits
spec:
  validationFailureAction: Enforce
  rules:
    - name: validate-resources
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        message: class="str">"CPU and memory requests and limits are required."
        pattern:
          spec:
            containers:
              - resources:
                  requests:
                    memory: class="str">"?*"
                    cpu: class="str">"?*"
                  limits:
                    memory: class="str">"?*"
                    cpu: class="str">"?*"

Eine solche Regel macht Plattformstandards verbindlicher.

---

25. Container Image Security

Ein Container Image ist Teil der Lieferkette. Es enthält Betriebssystembestandteile, Laufzeit, Bibliotheken und Anwendungscode.

Risiken:

Gute Praxis:

Beispiel Dockerfile:

FROM eclipse-temurin:21-jre-alpine

RUN addgroup -S app && adduser -S app -G app

WORKDIR /app
COPY target/order-service.jar /app/order-service.jar

USER app
EXPOSE 8080

ENTRYPOINT [class="str">"java", class="str">"-XX:MaxRAMPercentage=75", class="str">"-jar", class="str">"/app/order-service.jar"]

Dieses Dockerfile ist nicht perfekt für alle Fälle, aber besser als ein großes Image mit Root-User und unnötigen Tools.

---

26. Supply Chain Security

Supply Chain Security betrachtet den Weg von Code bis Produktion.

Fragen:

Ein moderner Release sollte nachvollziehbar sein:

Git Commit
↓
Pull Request Review
↓
CI Build
↓
Tests
↓
Security Scan
↓
Image Build
↓
Image Signatur
↓
GitOps Manifest Update
↓
Argo CD Sync
↓
Deployment

Wenn eine Sicherheitslücke gefunden wird, muss man wissen, welche Images und Umgebungen betroffen sind.

---

27. Beispiel: GitHub Actions Security Pipeline

name: build-and-scan-order-service

on:
  push:
    branches: [ main ]
  pull_request:

jobs:
  build:
    runs-on: ubuntu-latest

    permissions:
      contents: read
      packages: write
      security-events: write

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Set up Java
        uses: actions/setup-java@v4
        with:
          distribution: temurin
          java-version: class="str">'21'

      - name: Build
        run: ./mvnw -B verify

      - name: Build container image
        run: docker build -t registry.example.com/alpine/order-service:${{ github.sha }} .

      - name: Scan image
        run: trivy image --exit-code 1 --severity HIGH,CRITICAL registry.example.com/alpine/order-service:${{ github.sha }}

Diese Pipeline bricht bei kritischen Funden ab. In echten Unternehmen müssen Ausnahmen geregelt werden. Eine Ausnahme darf aber nicht einfach mündlich entstehen. Sie braucht Begründung, Ablaufdatum und Verantwortlichen.

---

28. Datenschutz und sensible Daten

Security schützt Systeme. Datenschutz schützt personenbezogene Daten.

Im Lab können folgende Daten sensibel sein:

Regeln:

Ein typischer Fehler ist, komplette Request- oder Response-Bodies zu loggen. Das hilft beim Debugging, kann aber personenbezogene oder vertrauliche Daten offenlegen.

---

29. Sichere Logging-Regeln

Gute Logs enthalten:

Schlechte Logs enthalten:

Beispiel guter Log:

{
  class="str">"level": class="str">"WARN",
  class="str">"service": class="str">"order-service",
  class="str">"event": class="str">"ORDER_VALIDATION_FAILED",
  class="str">"orderReference": class="str">"ORD-2026-00091",
  class="str">"traceId": class="str">"8af7e2c9",
  class="str">"reasonCode": class="str">"ITEM_NOT_AVAILABLE"
}

Dieser Log hilft im Betrieb, ohne unnötige Daten offenzulegen.

---

30. Admin Portal als Security-Beispiel

Das Admin Portal ist besonders kritisch, weil interne Mitarbeiter dort Daten sehen oder Aktionen auslösen können.

Risiken:

Gute Praxis:

Wichtig: Die UI darf Buttons ausblenden, aber die API muss trotzdem Berechtigungen prüfen. Frontend-Security allein ist keine Security.

---

31. Incident Response im Security-Kontext

Ein Security Incident ist ein Ereignis, das Vertraulichkeit, Integrität oder Verfügbarkeit gefährdet.

Beispiele:

Ein Incident-Prozess braucht Phasen:

Security ist erst ernsthaft, wenn auch der Umgang mit Fehlern beschrieben ist.

---

32. Runbook: Verdacht auf Secret Leak

Dieses Runbook ist bewusst klar. Bei Secret Leaks darf man nicht zuerst lange diskutieren. Man rotiert.

---

33. Übung: Rollen- und Rechtekonzept erstellen

Erstelle ein Rollen- und Rechtekonzept für das Admin Portal.

Es soll enthalten:

Denke dabei an:

---

34. Musterlösung zur Übung

Eine mögliche Lösung:

Technisch werden diese Rollen in Keycloak gepflegt. Das Admin Portal zeigt UI-Funktionen rollenabhängig an. Die Backend-APIs prüfen Rollen mit Spring Security. Kritische Aktionen schreiben Audit Events.

---

35. Merksätze

Teil D: Moderne Anwendungen, Datenflüsse, Messaging und Integration

Konsolidiert aus Rohmaterial: Teil 7, Teil 8.

Moderne Anwendungen

1. Warum moderne Anwendungen anders geplant werden

Eine moderne Enterprise-Anwendung ist nicht nur eine Anwendung mit neuem Framework. Sie ist ein Baustein in einer Plattform. Sie muss fachliche Verantwortung klar schneiden, sicher deploybar sein, mit anderen Systemen über stabile Schnittstellen sprechen, beobachtbar sein und im Fehlerfall kontrolliert reagieren. Genau hier unterscheiden sich produktionsnahe Systeme von kleinen Demo-Projekten.

Im Enterprise Platform Lab betrachten wir moderne Anwendungen deshalb nicht isoliert. Ein Order Service ist nicht nur ein REST Controller mit Datenbankzugriff. Er hat Authentifizierung, fachliche Regeln, Transaktionen, Outbox Events, Metriken, Logs, Datenbankmigrationen, Kubernetes-Manifeste, CI/CD, Runbooks und Betriebsgrenzen. Ein Customer Portal ist nicht nur ein React-Frontend. Es braucht OIDC, Token Handling, Fehlerzustände, API-Verträge, Routing, Build-Prozess und sichere Konfiguration.

Die wichtigste Regel lautet:

In diesem Teil bauen wir das Anwendungsbild des Labs. Die Anwendungen werden nicht als künstliche Beispiele nebeneinander gestellt, sondern als zusammenhängendes System: Customer Portal, Admin Portal, Order Service, Billing Service, Reporting Service, File Processing Service und API Gateway.

---

2. Die Anwendungslandkarte

Die moderne Anwendungslandschaft des Labs besteht aus mehreren Services mit klarer Verantwortung.

Diese Landkarte macht sichtbar, dass jede Anwendung einen eigenen Grund hat. Es gibt keine generischen Platzhalterdienste. Jeder Service erfüllt eine Aufgabe im Gesamtprozess.

---

3. Architekturprinzipien für Anwendungen

Für alle modernen Anwendungen gelten gemeinsame Architekturprinzipien.

Erstens: Jeder Service besitzt eine klare fachliche Verantwortung. Der Order Service erstellt keine Rechnungen. Der Billing Service verändert keine Bestellung. Das Customer Portal enthält keine Geschäftslogik, die eigentlich in einen Backend-Service gehört.

Zweitens: Jeder Service besitzt seine eigenen Betriebsartefakte. Dazu gehören README, Konfigurationsbeschreibung, Health Checks, Metriken, Logs und Runbook. Ein Service ohne Betriebsbeschreibung wird im Lab nicht als fertig betrachtet.

Drittens: Jeder Service kommuniziert über definierte Schnittstellen. REST APIs werden mit OpenAPI dokumentiert. Events werden mit klaren Eventnamen und Payload-Strukturen beschrieben. Datenbanktabellen anderer Services werden nicht direkt manipuliert.

Viertens: Jeder Service ist sicher konfigurierbar. Secrets liegen nicht im Code. Rollen werden nicht hart im Frontend entschieden. Sicherheitsentscheidungen müssen serverseitig überprüfbar sein.

Fünftens: Jeder Service ist ersetzbar und deploybar. Ein Deployment muss über Pipeline und GitOps reproduzierbar sein. Manuelle Änderungen in Produktion sind kein Zielzustand.

---

4. Customer Portal: Aufgabe und Grenzen

Das Customer Portal ist die Oberfläche für Kunden. Es soll einfach wirken, ist aber sicherheitstechnisch wichtig. Kunden sehen Bestellungen, Rechnungen, Profilinformationen und Statusmeldungen. Sie können neue Bestellungen auslösen oder bestehende Vorgänge einsehen.

Das Portal darf keine geheimen Zugangsdaten enthalten. Es darf keine Datenbank direkt erreichen. Es darf keine kritischen Entscheidungen allein treffen. Wenn das Frontend einen Button versteckt, ist das keine Sicherheit. Die Backend-API muss trotzdem prüfen, ob der Benutzer die Aktion ausführen darf.

Die typische Laufzeit ist OpenShift oder Cloud Hosting. Das Portal wird als statisches oder serverseitig ausgeliefertes Frontend gebaut. Der Build erzeugt ein Container Image oder statische Assets, die über einen Webserver ausgeliefert werden.

Ein typischer Ablauf:

Kunde öffnet customer.alpine.example.com
↓
Portal leitet zu Keycloak weiter
↓
Kunde meldet sich an
↓
Portal erhält OIDC Token
↓
Portal ruft API Gateway auf
↓
Order Service liefert Bestellungen des Kunden

Wichtig ist: Das Portal muss Token sauber behandeln. Es darf Access Tokens nicht unnötig lange speichern. Es muss Fehler wie abgelaufene Sitzung, fehlende Berechtigung und API-Ausfall sichtbar behandeln.

---

5. Beispiel: Frontend API Client

Der API Client trennt technische Kommunikation von UI-Komponenten. Dadurch wird die Oberfläche einfacher testbar.

export type OrderSummary = {
  id: string;
  status: class="str">'CREATED' | class="str">'CONFIRMED' | class="str">'CANCELLED' | class="str">'BILLED';
  totalAmount: number;
  createdAt: string;
};

export class ApiError extends Error {
  constructor(
    message: string,
    public readonly status: number,
    public readonly correlationId?: string
  ) {
    super(message);
  }
}

export async function loadOrders(accessToken: string): Promise<OrderSummary[]> {
  const response = await fetch(class="str">'/api/orders', {
    method: class="str">'GET',
    headers: {
      Authorization: `Bearer ${accessToken}`,
      Accept: class="str">'application/json'
    }
  });

  if (!response.ok) {
    const correlationId = response.headers.get(class="str">'x-correlation-id') ?? undefined;
    throw new ApiError(class="str">'Bestellungen konnten nicht geladen werden.', response.status, correlationId);
  }

  return response.json();
}

Dieser Code zeigt zwei wichtige Punkte. Erstens wird das Token nur für den API-Aufruf verwendet. Zweitens wird eine Correlation-ID aus der Antwort übernommen. Dadurch kann ein Fehler im Frontend später mit Backend-Logs verbunden werden.

---

6. Admin Portal: interne Oberfläche mit höherem Risiko

Das Admin Portal ist deutlich sensibler als das Customer Portal. Mitarbeiter können Bestellungen prüfen, Rechnungsstatus einsehen, Kundendaten bearbeiten oder Fehlerfälle korrigieren. Solche Aktionen müssen protokolliert werden.

Ein Admin Portal braucht daher:

Ein typischer Fehler ist, interne Oberflächen als weniger kritisch zu betrachten, weil sie „nur intern“ erreichbar sind. Das ist gefährlich. Interne Systeme haben oft mächtige Funktionen. Deshalb brauchen sie mindestens genauso klare Sicherheitsregeln wie externe Anwendungen.

Beispiel für Rollen:

Nicht jeder interne Benutzer ist automatisch Administrator. Das Rollenmodell muss fein genug sein, damit Aufgaben sauber getrennt werden können.

---

7. Order Service: fachlicher Kern

Der Order Service ist einer der zentralen Backend-Services. Er nimmt Bestellungen entgegen, validiert sie, speichert sie und veröffentlicht Events. Er ist bewusst nicht für Abrechnung, E-Mail-Versand oder Reporting zuständig.

Die wichtigste fachliche Verantwortung lautet:

Das bedeutet: Andere Systeme dürfen Bestellstatus nicht heimlich in ihrer eigenen Datenhaltung ändern. Sie können Ereignisse verarbeiten, Informationen ergänzen oder eigene Sichten aufbauen, aber die fachliche Bestellentscheidung liegt beim Order Service.

Der Service nutzt eine klassische Schichtung:

Diese Struktur verhindert, dass Infrastrukturdetails die Fachlogik dominieren.

---

8. Beispiel: REST Controller für Bestellungen

package com.seb4u.demo.spring.order.api;

import com.seb4u.demo.spring.order.application.CreateOrderCommand;
import com.seb4u.demo.spring.order.application.CreateOrderUseCase;
import jakarta.validation.Valid;
import org.springframework.http.HttpStatus;
import org.springframework.http.ResponseEntity;
import org.springframework.security.access.prepost.PreAuthorize;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RequestBody;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
@RequestMapping(class="str">"/api/orders")
public class OrderController {

    private final CreateOrderUseCase createOrderUseCase;

    public OrderController(CreateOrderUseCase createOrderUseCase) {
        this.createOrderUseCase = createOrderUseCase;
    }

    @PostMapping
    @PreAuthorize(class="str">"hasAuthority('SCOPE_order:write')")
    public ResponseEntity<CreateOrderResponse> createOrder(
            @Valid @RequestBody CreateOrderRequest request
    ) {
        var result = createOrderUseCase.createOrder(
                new CreateOrderCommand(request.customerId(), request.items())
        );

        return ResponseEntity
                .status(HttpStatus.CREATED)
                .body(new CreateOrderResponse(result.orderId(), result.status()));
    }
}

Der Controller bleibt dünn. Er kennt HTTP, Validierung und Security Annotation. Er enthält aber keine Geschäftslogik. Die eigentliche Bestellung wird im Use Case verarbeitet.

---

9. Domain-Modell für Order

Das Domain-Modell schützt Regeln vor zufälliger Verteilung im Code.

package com.seb4u.demo.spring.order.domain;

import java.math.BigDecimal;
import java.time.Instant;
import java.util.ArrayList;
import java.util.List;
import java.util.UUID;

public class Order {

    private final OrderId id;
    private final CustomerId customerId;
    private final List<OrderItem> items;
    private OrderStatus status;
    private final Instant createdAt;

    private Order(OrderId id, CustomerId customerId, List<OrderItem> items, OrderStatus status, Instant createdAt) {
        if (items == null || items.isEmpty()) {
            throw new IllegalArgumentException(class="str">"Eine Bestellung benötigt mindestens eine Position.");
        }
        this.id = id;
        this.customerId = customerId;
        this.items = new ArrayList<>(items);
        this.status = status;
        this.createdAt = createdAt;
    }

    public static Order create(CustomerId customerId, List<OrderItem> items, Instant createdAt) {
        return new Order(new OrderId(UUID.randomUUID()), customerId, items, OrderStatus.CREATED, createdAt);
    }

    public void confirm() {
        if (status != OrderStatus.CREATED) {
            throw new IllegalStateException(class="str">"Nur neu erstellte Bestellungen können bestätigt werden.");
        }
        status = OrderStatus.CONFIRMED;
    }

    public void cancel() {
        if (status == OrderStatus.BILLED) {
            throw new IllegalStateException(class="str">"Eine bereits abgerechnete Bestellung kann nicht storniert werden.");
        }
        status = OrderStatus.CANCELLED;
    }

    public BigDecimal totalAmount() {
        return items.stream()
                .map(OrderItem::totalPrice)
                .reduce(BigDecimal.ZERO, BigDecimal::add);
    }

    public OrderId id() {
        return id;
    }

    public CustomerId customerId() {
        return customerId;
    }

    public OrderStatus status() {
        return status;
    }

    public Instant createdAt() {
        return createdAt;
    }
}

Dieses Modell verhindert, dass beliebige Codestellen den Status einer Bestellung ohne Regelprüfung verändern. Die Methoden confirm und cancel enthalten fachliche Regeln.

---

10. Billing Service: Eventgetriebene Verarbeitung

Der Billing Service reagiert auf Events aus dem Order Service. Er erzeugt Rechnungsentwürfe, prüft Abrechnungsregeln und speichert eigene Rechnungsdaten. Er ist bewusst nicht Teil derselben Datenbank wie der Order Service.

Das Ziel ist lose Kopplung:

Order Service veröffentlicht OrderCreatedEvent
↓
Broker transportiert Event
↓
Billing Service konsumiert Event
↓
Billing Service erstellt Billing Draft

Lose Kopplung bedeutet aber nicht, dass Fehler ignoriert werden dürfen. Eventverarbeitung braucht Idempotenz. Wenn ein Event zweimal geliefert wird, darf nicht zweimal eine Rechnung erzeugt werden.

---

11. Beispiel: Idempotenter Event Consumer

package com.seb4u.demo.spring.billing.messaging;

import com.seb4u.demo.spring.billing.application.CreateBillingDraftCommand;
import com.seb4u.demo.spring.billing.application.CreateBillingDraftUseCase;
import com.seb4u.demo.spring.billing.persistence.ProcessedEventRepository;
import org.springframework.stereotype.Component;
import org.springframework.transaction.annotation.Transactional;

@Component
public class OrderCreatedConsumer {

    private final ProcessedEventRepository processedEventRepository;
    private final CreateBillingDraftUseCase createBillingDraftUseCase;

    public OrderCreatedConsumer(
            ProcessedEventRepository processedEventRepository,
            CreateBillingDraftUseCase createBillingDraftUseCase
    ) {
        this.processedEventRepository = processedEventRepository;
        this.createBillingDraftUseCase = createBillingDraftUseCase;
    }

    @Transactional
    public void handle(OrderCreatedMessage message) {
        if (processedEventRepository.existsByEventId(message.eventId())) {
            return;
        }

        createBillingDraftUseCase.createDraft(
                new CreateBillingDraftCommand(
                        message.orderId(),
                        message.customerId(),
                        message.totalAmount(),
                        message.createdAt()
                )
        );

        processedEventRepository.markProcessed(message.eventId(), message.eventType());
    }
}

Idempotenz ist kein Luxus. Sie ist in eventgetriebenen Systemen Pflicht, weil Broker Nachrichten erneut liefern können.

---

12. Reporting Service: Lesen ohne Fachlogik zu beschädigen

Reporting ist in Enterprise-Systemen oft schwierig. Fachbereiche wollen Auswertungen, Exporte, Excel-Dateien und historische Sichten. Gleichzeitig darf Reporting nicht die produktiven Kernprozesse stören.

Der Reporting Service soll daher nicht direkt in die Transaktionslogik eingreifen. Er liest aus freigegebenen Sichten, Replikaten oder speziell vorbereiteten Reporting-Tabellen. In kleinen Umgebungen kann er direkt aus Datenbanken lesen, aber in produktionsnahen Umgebungen sollte man Belastung, Rechte und Datenqualität beachten.

Mögliche Betriebsformen:

Das Lab zeigt bewusst mehrere Varianten, weil Reporting in Unternehmen selten vollständig modernisiert ist.

---

13. Beispiel: Kubernetes CronJob für Reporting

apiVersion: batch/v1
kind: CronJob
metadata:
  name: daily-order-report
  namespace: reporting-prod
spec:
  schedule: class="str">"15 2 * * *"
  concurrencyPolicy: Forbid
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 5
  jobTemplate:
    spec:
      backoffLimit: 2
      template:
        metadata:
          labels:
            app: daily-order-report
        spec:
          restartPolicy: Never
          containers:
            - name: report-generator
              image: registry.example.com/alpine/reporting-service:1.0.0
              args:
                - class="str">"generate-daily-order-report"
              envFrom:
                - secretRef:
                    name: reporting-db-secret
              resources:
                requests:
                  cpu: class="str">"500m"
                  memory: class="str">"1Gi"
                limits:
                  cpu: class="str">"2000m"
                  memory: class="str">"2Gi"

Der CronJob nutzt concurrencyPolicy: Forbid, damit nicht mehrere Berichte gleichzeitig laufen und dieselbe Datenbank belasten.

---

14. File Processing Service: große Dateien kontrolliert verarbeiten

Der File Processing Service verarbeitet Dateien von Partnern. Solche Dateien können CSV, XML, JSON oder proprietäre Formate enthalten. Fehlerhafte Dateien dürfen nicht stillschweigend verschwinden. Jede Datei braucht einen nachvollziehbaren Status.

Ein sauberer Ablauf:

Datei kommt an
↓
Datei bekommt technische ID
↓
Checksumme wird berechnet
↓
Schema wird geprüft
↓
Fachliche Regeln werden geprüft
↓
valide Datensätze werden weitergegeben
↓
fehlerhafte Datensätze werden protokolliert
↓
Originaldatei wird archiviert

Dieser Service kann auf OpenShift laufen, wenn die Dateigrößen und Storage-Anforderungen passen. Er kann aber auch auf VM oder Bare Metal laufen, wenn sehr große Dateien, lokale Storage-Anbindungen oder Spezialsoftware benötigt werden.

---

15. Beispiel: File Processing Pipeline in Java

package com.seb4u.demo.spring.fileprocessing.application;

import com.seb4u.demo.spring.fileprocessing.domain.FileValidationResult;
import com.seb4u.demo.spring.fileprocessing.domain.PartnerFile;
import com.seb4u.demo.spring.fileprocessing.infrastructure.storage.ObjectStorageClient;
import org.springframework.stereotype.Service;

@Service
public class PartnerFileProcessingService {

    private final ObjectStorageClient objectStorageClient;
    private final PartnerFileParser parser;
    private final PartnerRecordValidator validator;
    private final ProcessingEventPublisher eventPublisher;

    public PartnerFileProcessingService(
            ObjectStorageClient objectStorageClient,
            PartnerFileParser parser,
            PartnerRecordValidator validator,
            ProcessingEventPublisher eventPublisher
    ) {
        this.objectStorageClient = objectStorageClient;
        this.parser = parser;
        this.validator = validator;
        this.eventPublisher = eventPublisher;
    }

    public void process(String bucket, String objectKey) {
        PartnerFile file = objectStorageClient.load(bucket, objectKey);
        var records = parser.parse(file);
        FileValidationResult result = validator.validate(records);

        if (result.hasErrors()) {
            objectStorageClient.storeRejected(file, result.errors());
            eventPublisher.publishRejected(file.id(), result.errors().size());
            return;
        }

        objectStorageClient.storeProcessed(file);
        eventPublisher.publishAccepted(file.id(), records.size());
    }
}

Der Service löscht Dateien nicht einfach. Er verschiebt sie in definierte Zustände: verarbeitet oder abgelehnt. Das erleichtert Betrieb und Nachvollziehbarkeit.

---

16. API Gateway: Eingangspunkt und Schutzschicht

Das API Gateway ist der zentrale technische Eingang für APIs. Es ist nicht der Ort für komplette Fachlogik. Es übernimmt technische Querschnittsaufgaben.

Typische Aufgaben:

Fachliche Autorisierung bleibt trotzdem in den Services. Das Gateway kann prüfen, ob ein Token existiert. Der Order Service muss aber weiterhin prüfen, ob die konkrete Aktion erlaubt ist.

Ein häufiger Fehler ist, das Gateway zu mächtig zu machen. Dann entsteht eine zentrale Monsterkomponente. Besser ist: Gateway für technische Querschnittslogik, Fachentscheidungen in den Services.

---

17. API-Verträge und OpenAPI

REST APIs brauchen Verträge. Ohne Vertrag weiß das Frontend nicht zuverlässig, welche Felder existieren, welche Fehler auftreten können und welche Statuscodes verwendet werden.

Ein kleiner OpenAPI-Ausschnitt für den Order Service:

openapi: 3.0.3
info:
  title: Order Service API
  version: 1.0.0
paths:
  /api/orders:
    post:
      summary: Create a new order
      operationId: createOrder
      security:
        - bearerAuth: []
      responses:
        class="str">'201':
          description: Order created
          content:
            application/json:
              schema:
                $ref: class="str">'#/components/schemas/CreateOrderResponse'
        class="str">'400':
          description: Invalid request
        class="str">'401':
          description: Missing or invalid token
        class="str">'403':
          description: Missing permission
components:
  securitySchemes:
    bearerAuth:
      type: http
      scheme: bearer
      bearerFormat: JWT
  schemas:
    CreateOrderResponse:
      type: object
      required:
        - orderId
        - status
      properties:
        orderId:
          type: string
        status:
          type: string

OpenAPI ist nicht nur Dokumentation. Es kann auch für Tests, Client-Generierung und Review genutzt werden.

---

18. Fehlerbehandlung als Architekturthema

Fehlerbehandlung darf nicht zufällig entstehen. Moderne Anwendungen brauchen ein einheitliches Fehlermodell.

Ein gutes Fehlermodell enthält:

Beispielantwort:

{
  class="str">"code": class="str">"ORDER_VALIDATION_FAILED",
  class="str">"message": class="str">"Die Bestellung enthält ungültige Positionen.",
  class="str">"correlationId": class="str">"7ff8c1d2-0b23-4fa7-98a0-79916b827111",
  class="str">"timestamp": class="str">"2026-07-05T20:30:00Z",
  class="str">"details": [
    {
      class="str">"field": class="str">"items[0].quantity",
      class="str">"message": class="str">"Die Menge muss größer als 0 sein."
    }
  ]
}

Damit kann das Frontend dem Benutzer eine verständliche Meldung zeigen und der Betrieb kann über die Correlation-ID Logs suchen.

---

19. Observability in Anwendungen

Eine moderne Anwendung muss beobachtbar sein. Beobachtbarkeit besteht aus Logs, Metriken und Traces.

Logs beantworten:

Metriken beantworten:

Traces beantworten:

Der Order Service sollte zum Beispiel messen:

Ohne solche Metriken merkt man Probleme oft erst, wenn Benutzer sie melden.

---

20. Beispiel: fachliche Metrik in Spring

package com.seb4u.demo.spring.order.observability;

import io.micrometer.core.instrument.Counter;
import io.micrometer.core.instrument.MeterRegistry;
import org.springframework.stereotype.Component;

@Component
public class OrderMetrics {

    private final Counter ordersCreated;
    private final Counter orderValidationFailures;

    public OrderMetrics(MeterRegistry registry) {
        this.ordersCreated = Counter.builder(class="str">"orders_created_total")
                .description(class="str">"Anzahl erfolgreich erstellter Bestellungen")
                .register(registry);

        this.orderValidationFailures = Counter.builder(class="str">"order_validation_failures_total")
                .description(class="str">"Anzahl fehlgeschlagener Bestellvalidierungen")
                .register(registry);
    }

    public void orderCreated() {
        ordersCreated.increment();
    }

    public void validationFailed() {
        orderValidationFailures.increment();
    }
}

Diese Metriken sind fachlich verständlich. Sie helfen nicht nur Entwicklern, sondern auch Betrieb und Fachbereich.

---

21. Konfiguration moderner Anwendungen

Konfiguration muss zwischen Umgebungen variieren können. Eine Anwendung darf nicht für jede Umgebung neu gebaut werden, nur weil sich Datenbankhost oder Keycloak-URL ändern.

Richtig ist:

Beispiel application.yaml:

server:
  port: 8080

spring:
  datasource:
    url: ${DB_URL}
    username: ${DB_USERNAME}
    password: ${DB_PASSWORD}
  security:
    oauth2:
      resourceserver:
        jwt:
          issuer-uri: ${OIDC_ISSUER_URI}

management:
  endpoints:
    web:
      exposure:
        include: health,prometheus,info
  endpoint:
    health:
      probes:
        enabled: true

Secrets kommen aus Kubernetes Secrets, External Secrets oder Vault. Sie gehören nicht in Git.

---

22. Container Image für Spring Boot

FROM eclipse-temurin:21-jre

RUN addgroup --system app && adduser --system --ingroup app app

WORKDIR /app
COPY target/order-service.jar /app/order-service.jar

USER app

EXPOSE 8080

ENTRYPOINT [class="str">"java", class="str">"-XX:MaxRAMPercentage=75", class="str">"-jar", class="str">"/app/order-service.jar"]

Dieses Dockerfile nutzt einen Nicht-Root-Benutzer. Das ist wichtig für Security. Zusätzlich sollte das Image später gescannt und versioniert werden.

---

23. Deployment-Paket pro Anwendung

Jede Anwendung braucht neben Code auch Deployment-Artefakte.

Eine sinnvolle Struktur:

order-service/
├── source-material/
├── pom.xml
├── Dockerfile
├── README.md
├── docs/
│   ├── adr/
│   └── runbooks/
└── deploy/
    ├── base/
    │   ├── deployment.yaml
    │   ├── service.yaml
    │   ├── route.yaml
    │   ├── configmap.yaml
    │   ├── networkpolicy.yaml
    │   └── kustomization.yaml
    └── overlays/
        ├── dev/
        ├── test/
        └── prod/

Damit ist die Anwendung nicht nur lokal lauffähig, sondern auch plattformfähig.

---

24. Tests als Teil der Architektur

Tests sind nicht nur Qualitätskontrolle. Sie dokumentieren Annahmen. Besonders wichtig sind Integrationstests mit Datenbank, Broker und Security-Kontext.

Beispiel für einen Test mit Testcontainers:

package com.seb4u.demo.spring.order;

import org.junit.jupiter.api.Test;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.boot.testcontainers.service.connection.ServiceConnection;
import org.testcontainers.containers.PostgreSQLContainer;
import org.testcontainers.junit.jupiter.Container;
import org.testcontainers.junit.jupiter.Testcontainers;

import static org.assertj.core.api.Assertions.assertThat;

@Testcontainers
@SpringBootTest
class OrderServiceIntegrationTest {

    @Container
    @ServiceConnection
    static PostgreSQLContainer<?> postgres = new PostgreSQLContainer<>(class="str">"postgres:16");

    @Test
    void contextStartsWithPostgreSQL() {
        assertThat(postgres.isRunning()).isTrue();
    }
}

Dieser Test beweist nicht alle Fachregeln, aber er zeigt, dass der Service mit einer echten PostgreSQL-Instanz starten kann.

---

25. Typische Fehler bei modernen Anwendungen

Ein häufiger Fehler ist zu viel Logik im Controller. Dann wird der Controller schwer testbar und jede Änderung betrifft HTTP, Fachlogik und Datenbank gleichzeitig.

Ein zweiter Fehler ist direkte Kopplung zwischen Services und fremden Datenbanken. Wenn Billing direkt Order-Tabellen verändert, ist die Servicegrenze kaputt.

Ein dritter Fehler ist fehlende Idempotenz bei Events. Dadurch entstehen doppelte Rechnungen, doppelte Benachrichtigungen oder falsche Statuswechsel.

Ein vierter Fehler ist unklare Fehlerbehandlung. Wenn jeder Service andere Fehlerformate liefert, wird das Frontend kompliziert und Betrieb verliert Nachvollziehbarkeit.

Ein fünfter Fehler ist fehlende Observability. Ein Service ohne fachliche Metriken kann im Betrieb technisch gesund wirken, obwohl fachlich nichts mehr funktioniert.

Ein sechster Fehler ist Build-Time-Konfiguration. Wenn für jede Umgebung ein anderes Image gebaut wird, entstehen schwer nachvollziehbare Unterschiede.

---

26. Runbook: Outbox wächst an

oc logs -n order-prod deployment/order-service --tail=200 | grep -i outbox

oc exec -n order-prod deployment/order-service -- curl -s localhost:8080/actuator/health

SELECT event_type, count(*)

FROM outbox_events

WHERE published_at IS NULL

GROUP BY event_type;

SELECT id, event_type, publish_attempts, last_error

FROM outbox_events

WHERE published_at IS NULL

ORDER BY created_at

LIMIT 20;

oc get pods -n messaging

oc logs -n messaging statefulset/kafka --tail=100

Dieses Runbook ist direkt mit der Anwendung verbunden. Es ist kein separater Anhang, sondern Teil des Betriebswissens zum Order Service.

---

27. Übung: Servicegrenze prüfen

Prüfe folgende Aussage:

Beantworte:

---

28. Musterlösung

Die Aussage ist problematisch, weil der Billing Service damit die fachliche Verantwortung des Order Service verletzt. Die Order-Datenbank gehört dem Order Service. Wenn Billing direkt hineinschreibt, entstehen versteckte Kopplung und schwer nachvollziehbare Fehler.

Besser ist ein definierter Kommunikationsweg. Der Billing Service kann ein InvoiceCreatedEvent veröffentlichen. Der Order Service kann dieses Event konsumieren und selbst entscheiden, ob der Bestellstatus auf BILLED geändert werden darf. Alternativ kann Billing eine interne API des Order Service aufrufen, sofern dieser Weg fachlich und technisch gewünscht ist.

Sinnvolle Events wären:

Direktes Schreiben kann zu falschen Statuswechseln, Race Conditions, fehlendem Audit Logging, unklaren Transaktionsgrenzen und beschädigter Datenhoheit führen.

---

29. Merksätze

Daten, Messaging und Integration

1. Warum Daten und Integration der Kern eines Enterprise-Systems sind

Moderne Anwendungen bestehen nicht nur aus Benutzeroberflächen und REST-Endpunkten. Der wichtigste Teil einer Enterprise-Landschaft ist häufig der Datenfluss: Welche Daten entstehen in welchem System, wer darf sie verändern, wer darf sie lesen, welche Ereignisse werden veröffentlicht, wie werden Fehler wiederholt und wie bleibt nachvollziehbar, was passiert ist?

Im Enterprise Platform Lab sind Daten nicht an eine einzige Infrastruktur gebunden. Einige Daten liegen in PostgreSQL auf Bare Metal, andere in einer Managed Database in der Cloud, Partnerdateien liegen in Object Storage, Events laufen über Kafka oder RabbitMQ, und Anwendungen auf OpenShift konsumieren oder veröffentlichen diese Informationen. Genau dadurch entsteht ein realistisches Bild: Moderne Anwendungen arbeiten selten allein. Sie sind Teil eines Netzes aus Datenbanken, APIs, Broker-Systemen, Dateiablagen und Legacy-Schnittstellen.

Ein häufiger Fehler ist, Integration nur als technische Verbindung zu betrachten. Man sagt dann: "Service A ruft Service B auf" oder "Event X wird an Kafka gesendet". Das reicht nicht. In Enterprise-Systemen muss man zusätzlich verstehen:

Datenarchitektur ist deshalb keine Nebendisziplin. Sie entscheidet, ob ein System zuverlässig, auditierbar und wartbar ist.

---

2. Datenbesitz statt gemeinsame Datenbank

In alten Enterprise-Landschaften greifen oft viele Anwendungen auf dieselbe Datenbank zu. Das ist am Anfang bequem, wird aber mit der Zeit gefährlich. Wenn mehrere Systeme dieselben Tabellen direkt verändern, ist unklar, wem die Daten wirklich gehören. Jede Änderung am Schema kann andere Anwendungen beschädigen. Fachliche Regeln sind verteilt, und niemand kann zuverlässig sagen, welcher Prozess einen Wert geändert hat.

Im Zielbild des Labs gilt daher eine klare Regel:

Der Order Service besitzt Bestellungen. Der Billing Service besitzt Rechnungen. Der Reporting Service darf Daten lesen oder aus Replikaten verarbeiten, aber er darf nicht heimlich Bestellungen verändern. Das Admin Portal besitzt keine Kerndaten, sondern ruft fachliche APIs auf.

Diese Regel ist wichtig, weil sie fachliche Verantwortung sichtbar macht. Wenn eine Bestellung falsch ist, ist der Order Service verantwortlich. Wenn eine Rechnung falsch ist, ist der Billing Service verantwortlich. Wenn ein Report falsch aggregiert, ist der Reporting Service verantwortlich.

Datenbesitz bedeutet nicht, dass jeder Service zwingend eine eigene physische Datenbank braucht. In einem Lab kann man mehrere Schemas auf derselben PostgreSQL-Instanz verwenden. Wichtig ist die logische Grenze:

Andere Services dürfen diese Schemas nicht direkt verändern.

---

3. Datenmodell im Lab

Das Lab verwendet mehrere Datenbereiche.

Der Order Service speichert Bestellungen, Bestellpositionen und Outbox-Events. Der Billing Service speichert Rechnungsentwürfe, Rechnungen, Zahlungsstatus und Audit-Einträge. Der File Processing Service speichert Metadaten zu Partnerdateien. Der Reporting Service erzeugt eigene Auswertungsdaten, die aus Events, Datenbank-Views oder Exporten entstehen können.

Eine vereinfachte Sicht:

Diese Aufteilung verhindert, dass ein einziger Datenbankbereich zu einem unkontrollierten Sammelbecken wird.

---

4. Relationale Datenbanken

Relationale Datenbanken bleiben in modernen Enterprise-Systemen sehr wichtig. Sie sind besonders stark, wenn Daten konsistent, abfragbar und transaktional verarbeitet werden müssen. Bestellungen, Rechnungen, Kundenreferenzen, Statusänderungen und Audit-Daten sind typische Beispiele.

Im Lab verwenden wir PostgreSQL als Standarddatenbank. PostgreSQL kann lokal, auf einer VM, auf Bare Metal, in OpenShift oder als Managed Cloud Database betrieben werden. Die Architektur muss aber bewusst entscheiden, welche Variante für welchen Zweck passt.

Für produktionsnahe Kernsysteme kann Bare Metal oder eine dedizierte VM sinnvoll sein, wenn I/O-Leistung, Backup-Kontrolle oder bestehende Betriebsprozesse wichtig sind. Für Testumgebungen kann eine Managed Cloud Database praktisch sein. Für lokale Entwicklung reicht Docker Compose.

Eine wichtige Regel lautet:

Diese Entkopplung ermöglicht spätere Migrationen.

---

5. Schema-Migration mit Flyway

Datenbankschema darf nicht manuell verändert werden. Jede Änderung muss versioniert sein. Dafür verwenden wir Flyway oder Liquibase.

Ein Beispiel für Flyway im Order Service:

source-material/main/resources/db/migration/
├── V001__create_order_tables.sql
├── V002__create_outbox_table.sql
├── V003__add_order_status_index.sql
└── V004__add_customer_reference.sql

Eine Migration ist ein technischer Nachweis. Sie zeigt, wann und wie das Datenmodell verändert wurde.

Beispiel:

CREATE TABLE orders (
    id UUID PRIMARY KEY,
    customer_id VARCHAR(80) NOT NULL,
    status VARCHAR(40) NOT NULL,
    total_amount NUMERIC(12, 2) NOT NULL,
    currency VARCHAR(3) NOT NULL,
    created_at TIMESTAMP WITH TIME ZONE NOT NULL,
    updated_at TIMESTAMP WITH TIME ZONE
);

CREATE INDEX idx_orders_customer_id ON orders(customer_id);
CREATE INDEX idx_orders_status ON orders(status);

Diese Migration enthält bereits zwei wichtige Betriebsaspekte: Abfragen nach Kunde und Status werden erwartet und deshalb indiziert. Ein Schema ist also nicht nur Datenspeicherung, sondern auch Ausdruck der erwarteten Nutzung.

---

6. Transaktionen und fachliche Konsistenz

Eine Bestellung wird nicht nur als einzelner Datensatz gespeichert. Sie enthält Positionen, Beträge, Status und möglicherweise ein fachliches Event. Diese Schritte müssen konsistent sein.

Wenn die Bestellung gespeichert wird, aber das Event nicht entsteht, kann Billing nicht reagieren. Wenn das Event entsteht, aber die Bestellung nicht gespeichert wird, verarbeitet Billing falsche Informationen.

Darum gilt:

Beispiel:

package com.seb4u.demo.spring.order.application;

import com.seb4u.demo.spring.order.domain.Order;
import com.seb4u.demo.spring.order.domain.OrderRepository;
import com.seb4u.demo.spring.order.outbox.OutboxEvent;
import com.seb4u.demo.spring.order.outbox.OutboxRepository;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;

import java.time.Clock;
import java.time.Instant;
import java.util.UUID;

@Service
public class ConfirmOrderService {

    private final OrderRepository orderRepository;
    private final OutboxRepository outboxRepository;
    private final Clock clock;

    public ConfirmOrderService(
            OrderRepository orderRepository,
            OutboxRepository outboxRepository,
            Clock clock
    ) {
        this.orderRepository = orderRepository;
        this.outboxRepository = outboxRepository;
        this.clock = clock;
    }

    @Transactional
    public void confirmOrder(UUID orderId) {
        Order order = orderRepository.findByIdForUpdate(orderId)
                .orElseThrow(() -> new IllegalArgumentException(class="str">"order not found: " + orderId));

        order.confirm(Instant.now(clock));
        orderRepository.save(order);

        outboxRepository.save(OutboxEvent.orderConfirmed(
                order.id(),
                order.customerId(),
                order.totalAmount(),
                Instant.now(clock)
        ));
    }
}

Die Methode verwendet eine Transaktion. Dadurch werden Bestellung und Outbox-Eintrag gemeinsam bestätigt oder gemeinsam zurückgerollt.

---

7. Outbox Publisher

Der Outbox Publisher liest unveröffentlichte Events und sendet sie an den Broker. Er ist bewusst von der fachlichen Transaktion getrennt. Dadurch bleibt die Bestellung schnell und konsistent, während die Veröffentlichung wiederholt werden kann.

Ein einfaches Beispiel:

package com.seb4u.demo.spring.order.outbox;

import org.springframework.scheduling.annotation.Scheduled;
import org.springframework.stereotype.Component;
import org.springframework.transaction.annotation.Transactional;

import java.time.Clock;
import java.time.Instant;
import java.util.List;

@Component
public class OutboxPublisherJob {

    private final OutboxRepository outboxRepository;
    private final EventBrokerClient eventBrokerClient;
    private final Clock clock;

    public OutboxPublisherJob(
            OutboxRepository outboxRepository,
            EventBrokerClient eventBrokerClient,
            Clock clock
    ) {
        this.outboxRepository = outboxRepository;
        this.eventBrokerClient = eventBrokerClient;
        this.clock = clock;
    }

    @Scheduled(fixedDelayString = class="str">"${outbox.publisher.delay:5000}")
    @Transactional
    public void publishPendingEvents() {
        List<OutboxEvent> events = outboxRepository.findNextUnpublishedBatch(50);

        for (OutboxEvent event : events) {
            try {
                eventBrokerClient.publish(event.topic(), event.key(), event.payload());
                event.markPublished(Instant.now(clock));
            } catch (Exception ex) {
                event.registerFailure(ex.getMessage());
            }
        }
    }
}

Dieses Beispiel ist bewusst einfach. In produktionsnahen Umgebungen würde man zusätzlich Sperrmechanismen, Backoff, Dead-Letter-Handling, Metriken und Tracing ergänzen.

---

8. Messaging: Kafka oder RabbitMQ?

Messaging verbindet Systeme asynchron. Das bedeutet: Ein Service muss nicht warten, bis ein anderer Service seine Arbeit sofort erledigt. Stattdessen veröffentlicht er ein Event oder eine Nachricht.

Kafka eignet sich besonders für Event Streams, hohe Durchsätze, Wiederholbarkeit, zeitliche Entkopplung und mehrere Consumer-Gruppen. RabbitMQ eignet sich stark für klassische Work Queues, Routing, bestimmte Zustellmuster und Aufgabenverteilung.

Im Lab können beide Varianten vorkommen:

Die Entscheidung hängt nicht von Mode ab, sondern von Semantik.

Ein Event sagt:

Ein Command sagt:

Diese Unterscheidung ist sehr wichtig.

---

9. Event-Naming

Events sollten fachlich benannt werden. Schlechte Namen sind technisch oder unklar:

Bessere Namen:

Ein Event beschreibt eine fachliche Tatsache in der Vergangenheit. Deshalb wird häufig die Vergangenheitsform verwendet.

Ein Event sollte nicht lauten:

Das wäre eher ein Command.

Besser:

Der Billing Service entscheidet dann, ob daraus eine Rechnung entsteht.

---

10. Event Payload

Ein Event sollte genug Informationen enthalten, damit Consumer sinnvoll reagieren können. Es sollte aber nicht die gesamte Datenbankstruktur eines Services exportieren.

Beispiel:

{
  class="str">"eventId": class="str">"7c6715a3-ff91-4e96-b6e1-7f7cf4e18c50",
  class="str">"eventType": class="str">"OrderConfirmed",
  class="str">"occurredAt": class="str">"2026-07-05T18:30:00Z",
  class="str">"orderId": class="str">"0b33b8b8-81d8-4af1-9343-660d0f4a4131",
  class="str">"customerId": class="str">"CUST-4711",
  class="str">"totalAmount": 129.90,
  class="str">"currency": class="str">"EUR",
  class="str">"traceId": class="str">"82b81f5f91d342aa"
}

Wichtige Felder sind:

Nicht jedes Event muss alle Details enthalten. Wenn ein Consumer mehr Informationen braucht, kann er über eine API nachladen. Das ist ein bewusstes Design.

---

11. Idempotenz

In verteilten Systemen können Nachrichten mehrfach ankommen. Das ist kein Ausnahmefall, sondern normales Verhalten. Ein Consumer muss deshalb idempotent sein.

Idempotenz bedeutet:

Beispiel: Wenn Billing ein OrderConfirmed Event zweimal erhält, darf nicht zweimal dieselbe Rechnung erstellt werden.

Eine einfache Lösung ist eine Tabelle für verarbeitete Events:

CREATE TABLE processed_events (
    event_id UUID PRIMARY KEY,
    event_type VARCHAR(160) NOT NULL,
    processed_at TIMESTAMP WITH TIME ZONE NOT NULL
);

Der Consumer prüft vor der Verarbeitung, ob event_id bereits existiert.

package com.seb4u.demo.spring.billing.messaging;

import com.seb4u.demo.spring.billing.domain.InvoiceService;
import org.springframework.stereotype.Component;
import org.springframework.transaction.annotation.Transactional;

@Component
public class OrderConfirmedConsumer {

    private final ProcessedEventRepository processedEventRepository;
    private final InvoiceService invoiceService;

    public OrderConfirmedConsumer(
            ProcessedEventRepository processedEventRepository,
            InvoiceService invoiceService
    ) {
        this.processedEventRepository = processedEventRepository;
        this.invoiceService = invoiceService;
    }

    @Transactional
    public void handle(OrderConfirmedMessage message) {
        if (processedEventRepository.existsById(message.eventId())) {
            return;
        }

        invoiceService.createInvoiceDraft(
                message.orderId(),
                message.customerId(),
                message.totalAmount(),
                message.currency()
        );

        processedEventRepository.markProcessed(message.eventId(), message.eventType());
    }
}

Ohne Idempotenz wirkt Messaging im Test oft korrekt, aber in Produktion entstehen doppelte Rechnungen, doppelte E-Mails oder doppelte Buchungen.

---

12. Dead Letter Queue

Nicht jede Nachricht kann erfolgreich verarbeitet werden. Manchmal ist das Format falsch, eine Referenz fehlt, ein externer Dienst ist nicht erreichbar oder ein fachlicher Zustand passt nicht.

Wenn ein Consumer dieselbe fehlerhafte Nachricht endlos wiederholt, blockiert er Verarbeitung. Deshalb braucht man ein Dead-Letter-Konzept.

Eine Dead Letter Queue enthält Nachrichten, die nach mehreren Versuchen nicht verarbeitet werden konnten.

Wichtig ist: Eine Dead Letter Queue ist kein Mülleimer. Sie ist ein Betriebsartefakt.

Sie braucht:

Beispiel für eine Fehlerstruktur:

{
  class="str">"failedAt": class="str">"2026-07-05T19:10:00Z",
  class="str">"consumer": class="str">"billing-order-confirmed-consumer",
  class="str">"reason": class="str">"customer reference not found",
  class="str">"attempts": 5,
  class="str">"traceId": class="str">"0a74ddfd1b7b4f12",
  class="str">"originalEvent": {
    class="str">"eventType": class="str">"OrderConfirmed",
    class="str">"orderId": class="str">"0b33b8b8-81d8-4af1-9343-660d0f4a4131",
    class="str">"customerId": class="str">"CUST-404"
  }
}

---

13. Integration über REST APIs

Nicht jede Integration ist Event-basiert. REST APIs bleiben wichtig, besonders wenn ein System eine direkte Antwort braucht.

Beispiel:

REST eignet sich gut für synchrone Abfragen und direkte Benutzerinteraktionen. Es ist weniger gut für lange Hintergrundprozesse oder viele abhängige Zustandsänderungen.

Eine gute API definiert klare Ressourcen:

Eine schlechte API versteckt Fachlichkeit hinter technischen Namen:

---

14. API-Verträge mit OpenAPI

OpenAPI macht REST-Schnittstellen dokumentierbar und prüfbar. In Enterprise-Projekten ist das wichtig, weil mehrere Teams dieselben Schnittstellen verwenden.

Ein kleiner Ausschnitt:

openapi: 3.0.3
info:
  title: Order Service API
  version: 1.0.0
paths:
  /orders:
    post:
      summary: Create a new order
      operationId: createOrder
      requestBody:
        required: true
        content:
          application/json:
            schema:
              $ref: class="str">'#/components/schemas/CreateOrderRequest'
      responses:
        class="str">'201':
          description: Order created
          content:
            application/json:
              schema:
                $ref: class="str">'#/components/schemas/CreateOrderResponse'
        class="str">'400':
          description: Invalid request
components:
  schemas:
    CreateOrderRequest:
      type: object
      required:
        - customerId
        - items
      properties:
        customerId:
          type: string
        items:
          type: array
          items:
            $ref: class="str">'#/components/schemas/CreateOrderItem'
    CreateOrderItem:
      type: object
      required:
        - productId
        - quantity
      properties:
        productId:
          type: string
        quantity:
          type: integer
          minimum: 1

OpenAPI hilft nicht nur beim Lesen. Es kann auch für Client-Generierung, Contract Tests und API Reviews genutzt werden.

---

15. Anti-Corruption Layer

Wenn moderne Services mit Legacy-Systemen sprechen, dürfen Legacy-Begriffe nicht unkontrolliert in die neue Domäne gelangen.

Ein Anti-Corruption Layer übersetzt alte Schnittstellen in moderne fachliche Modelle.

Beispiel: Ein Legacy-System liefert Statuswerte:

Der moderne Order Service will aber klare Status:

Die Übersetzung gehört nicht überall verteilt in Controller, Services und Repositories. Sie gehört in eine klare Integrationsschicht.

package com.seb4u.demo.spring.order.integration.legacy;

import com.seb4u.demo.spring.order.domain.OrderStatus;
import org.springframework.stereotype.Component;

@Component
public class LegacyOrderStatusMapper {

    public OrderStatus map(String legacyStatus) {
        return switch (legacyStatus) {
            case class="str">"A" -> OrderStatus.CREATED;
            case class="str">"B" -> OrderStatus.CONFIRMED;
            case class="str">"C" -> OrderStatus.CANCELLED;
            case class="str">"X", class="str">"9" -> OrderStatus.FAILED;
            default -> throw new IllegalArgumentException(class="str">"Unknown legacy status: " + legacyStatus);
        };
    }
}

Dieser Mapper sieht klein aus, ist aber architektonisch wichtig. Er verhindert, dass Legacy-Codes die moderne Domäne verschmutzen.

---

16. Dateibasierte Integration

Viele Enterprise-Systeme verwenden weiterhin Dateien. Das ist nicht automatisch schlecht. Dateien sind besonders nützlich, wenn Partner keine APIs anbieten, große Datenmengen übertragen werden oder rechtliche Archivierung erforderlich ist.

Ein moderner dateibasierter Ablauf sieht kontrolliert aus:

Partner stellt Datei bereit
↓
Datei landet im incoming Bucket
↓
Metadaten werden gespeichert
↓
Validierung startet
↓
gültige Datensätze werden verarbeitet
↓
fehlerhafte Datensätze werden mit Gründen abgelegt
↓
Event wird veröffentlicht
↓
Reporting und Fachservices reagieren

Wichtig ist, dass Datei-Verarbeitung nicht nur ein Bash-Skript auf einem Server ist. Sie braucht Status, Wiederholbarkeit, Fehlerprotokolle und Monitoring.

---

17. File Batch Datenmodell

CREATE TABLE file_batches (
    id UUID PRIMARY KEY,
    partner_id VARCHAR(80) NOT NULL,
    file_name VARCHAR(255) NOT NULL,
    object_storage_key VARCHAR(500) NOT NULL,
    status VARCHAR(40) NOT NULL,
    received_at TIMESTAMP WITH TIME ZONE NOT NULL,
    processed_at TIMESTAMP WITH TIME ZONE,
    total_records INTEGER,
    valid_records INTEGER,
    invalid_records INTEGER,
    last_error TEXT
);

CREATE TABLE file_record_errors (
    id UUID PRIMARY KEY,
    batch_id UUID NOT NULL REFERENCES file_batches(id),
    line_number INTEGER NOT NULL,
    error_code VARCHAR(80) NOT NULL,
    error_message TEXT NOT NULL,
    raw_record TEXT
);

Dieses Modell ist betriebsfreundlich. Man sieht nicht nur, dass eine Datei fehlgeschlagen ist, sondern auch, wie viele Datensätze betroffen sind und warum.

---

18. Integration mit Object Storage

Object Storage eignet sich gut für Partnerdateien, Exporte, Reports und Archivierung. Die Anwendung speichert nicht direkt auf lokaler Platte, sondern in Buckets.

Beispiel mit S3-kompatibler API:

package com.seb4u.demo.spring.fileprocessing.storage;

import software.amazon.awssdk.core.sync.RequestBody;
import software.amazon.awssdk.services.s3.S3Client;
import software.amazon.awssdk.services.s3.model.PutObjectRequest;
import org.springframework.stereotype.Component;

import java.nio.file.Path;

@Component
public class PartnerFileStorage {

    private final S3Client s3Client;
    private final PartnerFileStorageProperties properties;

    public PartnerFileStorage(S3Client s3Client, PartnerFileStorageProperties properties) {
        this.s3Client = s3Client;
        this.properties = properties;
    }

    public void storeIncomingFile(String partnerId, String fileName, Path localFile) {
        String key = class="str">"incoming/%s/%s".formatted(partnerId, fileName);

        PutObjectRequest request = PutObjectRequest.builder()
                .bucket(properties.bucket())
                .key(key)
                .metadata(java.util.Map.of(
                        class="str">"partnerId", partnerId,
                        class="str">"originalFileName", fileName
                ))
                .build();

        s3Client.putObject(request, RequestBody.fromFile(localFile));
    }
}

Auch hier gilt: Die Dateiablage ist Teil der Architektur. Bucket-Namen, Verschlüsselung, Versionierung, Aufbewahrung und Zugriff müssen dokumentiert werden.

---

19. Datenklassifizierung

Nicht alle Daten sind gleich sensibel. Eine Plattform muss unterscheiden können.

Beispiele:

Diese Klassifizierung beeinflusst:

Ein häufiger Fehler ist, produktive Daten einfach in Testumgebungen zu kopieren. Das kann Datenschutz- und Compliance-Probleme erzeugen. Testdaten müssen anonymisiert, synthetisch erzeugt oder streng kontrolliert werden.

---

20. Logging von Datenflüssen

Datenflüsse müssen nachvollziehbar sein, aber Logs dürfen keine sensiblen Daten unkontrolliert enthalten.

Gute Logs enthalten:

Schlechte Logs enthalten:

Beispiel für ein gutes Log:

{
  class="str">"level": class="str">"INFO",
  class="str">"service": class="str">"billing-service",
  class="str">"traceId": class="str">"82b81f5f91d342aa",
  class="str">"eventId": class="str">"7c6715a3-ff91-4e96-b6e1-7f7cf4e18c50",
  class="str">"message": class="str">"invoice draft created",
  class="str">"orderId": class="str">"0b33b8b8-81d8-4af1-9343-660d0f4a4131",
  class="str">"invoiceId": class="str">"INV-2026-0004711"
}

Das Log ist nützlich, ohne unnötig sensible Details zu veröffentlichen.

---

21. Tracing über Systemgrenzen

In einer verteilten Architektur reicht ein einzelnes Log nicht aus. Eine Anfrage oder ein Event wandert durch mehrere Systeme. Tracing verbindet diese Schritte.

Beispiel:

Customer Portal
↓ traceId=abc123
Order Service
↓
Outbox Publisher
↓
Kafka
↓
Billing Service
↓
Invoice Database

Wenn überall dieselbe Trace-ID sichtbar ist, kann der Betrieb den Ablauf nachvollziehen. Ohne Trace-ID sieht man nur isolierte Logzeilen.

Für HTTP wird Trace-Kontext oft über Header weitergegeben. Für Events muss man Trace-Informationen in Message Headers oder Payload-Metadaten übernehmen.

---

22. Reporting und Datenkopien

Reporting braucht oft andere Datenstrukturen als operative Anwendungen. Ein Order Service speichert Bestellungen transaktional. Reporting möchte aggregierte Zahlen pro Tag, Region, Produkt oder Partner sehen.

Es ist meist falsch, komplexe Reports direkt auf operativen Tabellen auszuführen. Das kann Produktivsysteme belasten und fachliche Grenzen verwischen.

Besser sind kontrollierte Kopien:

Events → Reporting Consumer → Reporting Schema
Datenbank Export → Reporting Import → Reporting Tabellen
CDC Stream → Data Platform → Auswertungen

Im Lab genügt zunächst ein Reporting Consumer, der Events verarbeitet und eigene Summary-Tabellen pflegt.

CREATE TABLE daily_order_summary (
    summary_date DATE NOT NULL,
    currency VARCHAR(3) NOT NULL,
    order_count INTEGER NOT NULL,
    total_amount NUMERIC(14, 2) NOT NULL,
    PRIMARY KEY (summary_date, currency)
);

Diese Tabelle gehört dem Reporting Service, nicht dem Order Service.

---

23. Change Data Capture

Change Data Capture, kurz CDC, liest Änderungen aus einer Datenbank und stellt sie anderen Systemen bereit. Werkzeuge wie Debezium können Änderungen aus PostgreSQL erfassen und als Events veröffentlichen.

CDC kann nützlich sein, wenn bestehende Systeme keine Events veröffentlichen können. Es ist aber kein Ersatz für fachliches Event-Design.

Ein technisches Datenbank-Update sagt nicht automatisch, was fachlich passiert ist.

Beispiel:

Das ist technisch.

Fachlich könnte es bedeuten:

CDC ist daher besonders gut für Integration mit Legacy-Systemen, Replikation und Übergangslösungen. Für neue Services sollte man fachliche Events bewusst modellieren.

---

24. Konsistenzmodelle

Nicht alle Systeme sind sofort konsistent. Bei asynchroner Verarbeitung entsteht zeitweise Verzögerung.

Beispiel:

Das ist nicht automatisch ein Fehler. Es ist eventual consistency.

Wichtig ist, dass Benutzeroberflächen und Fachprozesse damit umgehen können. Das Portal darf nicht erwarten, dass eine Rechnung im selben Millisekunden-Moment existiert. Es kann stattdessen anzeigen:

Eine gute Architektur erklärt solche Zustände fachlich.

---

25. Integrationstest mit Testcontainers

Integration muss getestet werden. Mock-Tests reichen nicht aus, wenn Datenbank, Migrationen und Messaging beteiligt sind.

Mit Testcontainers kann ein Test echte Infrastrukturkomponenten starten.

package com.seb4u.demo.spring.order;

import org.junit.jupiter.api.Test;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.test.context.DynamicPropertyRegistry;
import org.springframework.test.context.DynamicPropertySource;
import org.testcontainers.containers.PostgreSQLContainer;
import org.testcontainers.junit.jupiter.Container;
import org.testcontainers.junit.jupiter.Testcontainers;

@SpringBootTest
@Testcontainers
class OrderServiceIntegrationTest {

    @Container
    static PostgreSQLContainer<?> postgres = new PostgreSQLContainer<>(class="str">"postgres:16")
            .withDatabaseName(class="str">"orders")
            .withUsername(class="str">"orders")
            .withPassword(class="str">"orders");

    @DynamicPropertySource
    static void databaseProperties(DynamicPropertyRegistry registry) {
        registry.add(class="str">"spring.datasource.url", postgres::getJdbcUrl);
        registry.add(class="str">"spring.datasource.username", postgres::getUsername);
        registry.add(class="str">"spring.datasource.password", postgres::getPassword);
    }

    @Test
    void contextStartsWithRealPostgres() {
        // Der Test startet die Anwendung mit echter PostgreSQL-Datenbank.
        // Flyway-Migrationen laufen dabei ebenfalls.
    }
}

Dieser Test prüft nicht nur Java-Code. Er prüft, ob Anwendung, Konfiguration und Datenbankmigration zusammenpassen.

---

26. Runbook: Outbox wächst an

oc logs -n order-prod deployment/order-service --tail=200 | grep -i outbox

SELECT count(*)

FROM outbox_events

WHERE published_at IS NULL;

SELECT event_type, count(*)

FROM outbox_events

WHERE published_at IS NULL

GROUP BY event_type;

SELECT id, event_type, publish_attempts, last_error, created_at

FROM outbox_events

WHERE published_at IS NULL

ORDER BY created_at

LIMIT 20;

oc get pods -n messaging

oc logs -n messaging statefulset/kafka --tail=100

---

27. Typische Fehler bei Daten und Integration

Ein häufiger Fehler ist direkter Datenbankzugriff zwischen Services. Dadurch entstehen versteckte Kopplungen und unklare Verantwortlichkeiten.

Ein zweiter Fehler ist fehlende Idempotenz. In Testumgebungen fällt das selten auf, in Produktion führt es zu doppelten Rechnungen, doppelten Benachrichtigungen oder falschen Reports.

Ein dritter Fehler ist zu große Event Payload. Wenn Events komplette Datenbankobjekte enthalten, werden sie schwer versionierbar und koppeln Consumer an interne Modelle.

Ein vierter Fehler ist fehlendes Dead-Letter-Konzept. Fehlerhafte Nachrichten werden endlos wiederholt oder verschwinden unkontrolliert.

Ein fünfter Fehler ist fehlende Datenklassifizierung. Dann landen sensible Informationen in Logs, Testdatenbanken oder ungeschützten Buckets.

Ein sechster Fehler ist ungeprüfte Datei-Verarbeitung. Partnerdateien werden verarbeitet, ohne Fehlerzeilen, Status und Wiederholbarkeit sauber zu dokumentieren.

---

28. Übung: Datenfluss für eine Bestellung modellieren

Modelliere den Datenfluss vom Erstellen einer Bestellung bis zur Rechnung.

Beantworte:

---

29. Musterlösung zur Übung

Eine mögliche Lösung:

---

30. Merksätze

Teil E: Observability, Betrieb, Backup, Disaster Recovery und Resilienz

Konsolidiert aus Rohmaterial: Teil 9, Teil 10, Teil 38.

Observability und Betrieb

1. Warum Observability mehr ist als Monitoring

In vielen Projekten wird Monitoring erst am Ende eingebaut. Dann läuft die Anwendung zwar technisch, aber niemand kann zuverlässig erklären, was im Fehlerfall passiert. Ein Service ohne gute Beobachtbarkeit ist im Betrieb schwer zu verantworten. Man sieht vielleicht, dass ein Pod neu gestartet wurde, aber nicht warum. Man sieht vielleicht, dass eine API langsam ist, aber nicht, ob die Ursache im Code, in der Datenbank, im Broker, im Netzwerk oder in einer externen Abhängigkeit liegt.

Observability bedeutet, dass ein System so gebaut wird, dass sein Zustand von außen verständlich wird. Es reicht nicht, nur CPU und RAM zu messen. Für ein Enterprise-System braucht man technische Signale, fachliche Signale und Betriebsnachweise.

Ein modernes System beantwortet im Betrieb Fragen wie:

Observability ist deshalb keine Zusatzfunktion. Sie ist Teil der Architektur. Wenn ein Service keine Logs, Metriken, Traces, Health Checks, Dashboards und Runbooks hat, ist er nicht produktionsnah.

---

2. Die drei klassischen Säulen

Observability wird häufig über drei Säulen beschrieben:

Logs beschreiben Ereignisse. Sie erzählen, was passiert ist. Ein Logeintrag kann zeigen, dass eine Bestellung erstellt wurde, dass eine Validierung fehlgeschlagen ist oder dass ein Aufruf zur Datenbank nicht funktioniert hat.

Metriken beschreiben Zahlen über die Zeit. Sie zeigen zum Beispiel Anzahl von Requests, Fehlerquote, Antwortzeiten, Speicherverbrauch, CPU-Nutzung, Queue-Länge oder Anzahl unveröffentlichter Outbox-Events.

Traces verbinden einzelne Schritte einer Anfrage über mehrere Services hinweg. Ein Trace zeigt, dass ein Request vom Customer Portal über das API Gateway zum Order Service, zur Datenbank, zur Outbox und später zum Billing Service geführt hat.

Diese drei Signale ergänzen sich. Logs ohne Metriken führen zu mühsamer Suche. Metriken ohne Logs zeigen nur Symptome. Traces ohne fachliche Informationen erklären oft nicht genug. Erst zusammen entsteht ein brauchbares Betriebsbild.

---

3. Observability-Zielbild im Lab

Im Enterprise Platform Lab verwenden wir folgende Zielarchitektur:

flowchart LR
    Portal[Customer Portal] --> Gateway[API Gateway]
    Gateway --> Order[Order Service]
    Order --> DB[(PostgreSQL)]
    Order --> Outbox[Outbox]
    Outbox --> Broker[Kafka / RabbitMQ]
    Broker --> Billing[Billing Service]

    Order --> Logs[Loki]
    Billing --> Logs
    Gateway --> Logs

    Order --> Metrics[Prometheus]
    Billing --> Metrics
    DB --> Metrics
    Broker --> Metrics

    Order --> Traces[Tempo]
    Billing --> Traces
    Gateway --> Traces

    Metrics --> Grafana[Grafana]
    Logs --> Grafana
    Traces --> Grafana

Grafana ist dabei nicht die Datenquelle selbst. Grafana visualisiert Daten aus Prometheus, Loki und Tempo. Prometheus sammelt Metriken. Loki speichert Logs. Tempo speichert Traces. In anderen Unternehmen können andere Werkzeuge genutzt werden, zum Beispiel Elastic, Splunk, Datadog, New Relic oder OpenTelemetry Collector mit verschiedenen Backends. Das Prinzip bleibt gleich.

---

4. Health Checks: gestartet ist nicht gesund

Ein Prozess kann laufen und trotzdem fachlich nicht funktionieren. Deshalb braucht ein Service Health Checks.

Spring Boot unterscheidet typischerweise zwischen Liveness und Readiness.

Liveness beantwortet: Muss der Container neu gestartet werden?

Readiness beantwortet: Darf der Service Traffic erhalten?

Ein Service kann live, aber nicht ready sein. Beispiel: Die Anwendung läuft, aber die Datenbank ist nicht erreichbar. Dann soll Kubernetes den Container nicht unbedingt sofort töten, aber der Service soll vorübergehend keinen Traffic bekommen.

Beispiel für OpenShift/Kubernetes:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service
  namespace: order-prod
spec:
  replicas: 2
  selector:
    matchLabels:
      app: order-service
  template:
    metadata:
      labels:
        app: order-service
    spec:
      containers:
        - name: order-service
          image: registry.example.com/alpine/order-service:1.4.2
          ports:
            - containerPort: 8080
          livenessProbe:
            httpGet:
              path: /actuator/health/liveness
              port: 8080
            initialDelaySeconds: 40
            periodSeconds: 20
            failureThreshold: 3
          readinessProbe:
            httpGet:
              path: /actuator/health/readiness
              port: 8080
            initialDelaySeconds: 20
            periodSeconds: 10
            failureThreshold: 2

Ein häufiger Fehler ist, für beide Probes denselben Endpunkt zu verwenden. Wenn die Readiness wegen einer abhängigen Datenbank fehlschlägt, ist das sinnvoll. Wenn aber die Liveness wegen einer kurzzeitig nicht erreichbaren Datenbank fehlschlägt, kann Kubernetes den Pod unnötig oft neu starten. Dadurch wird die Störung schlimmer.

---

5. Spring Boot Actuator richtig nutzen

Spring Boot Actuator liefert viele Betriebsendpunkte. Diese dürfen aber nicht unkontrolliert nach außen exponiert werden.

Beispielkonfiguration:

management:
  endpoints:
    web:
      exposure:
        include: health,info,prometheus
  endpoint:
    health:
      probes:
        enabled: true
      show-details: never
  health:
    livenessstate:
      enabled: true
    readinessstate:
      enabled: true
  metrics:
    tags:
      application: order-service
      environment: prod

Für produktionsnahe Umgebungen gilt: Health, Info und Prometheus sind nützlich. Detaillierte interne Informationen sollten nicht öffentlich erreichbar sein. Debug- oder Env-Endpunkte gehören nicht offen ins Internet.

Ein sauberer Betrieb trennt zwischen internen Management-Endpunkten und externen API-Endpunkten. In OpenShift kann das über Services, Routes, NetworkPolicies und Authentifizierung geregelt werden.

---

6. Strukturierte Logs

Logs sollten maschinenlesbar sein. Freitext-Logs sind schwer zu durchsuchen. Strukturierte Logs enthalten Felder wie Zeitstempel, Level, Service, Trace-ID, Request-ID, Benutzerkontext, Fehlercode und fachlichen Bezug.

Ein guter Logeintrag beantwortet:

Beispiel als JSON-Log:

{
  class="str">"timestamp": class="str">"2026-07-05T20:42:11.450Z",
  class="str">"level": class="str">"WARN",
  class="str">"service": class="str">"order-service",
  class="str">"environment": class="str">"prod",
  class="str">"traceId": class="str">"7a5f0f3e8d1a91c2",
  class="str">"spanId": class="str">"42ac917e2f1b",
  class="str">"orderId": class="str">"8c7db3d2-5b42-4f37-9ef8-8be092f2d011",
  class="str">"event": class="str">"OUTBOX_PUBLISH_RETRY",
  class="str">"message": class="str">"Outbox event could not be published. Retry scheduled.",
  class="str">"attempt": 3,
  class="str">"broker": class="str">"kafka-orders",
  class="str">"errorClass": class="str">"TimeoutException"
}

Dieser Logeintrag ist besser als:

Denn er enthält Kontext, Wiederholungsversuch, Event, Service und Korrelation.

---

7. Logback-Konfiguration für JSON Logs

In einem Spring Boot Service kann JSON Logging zum Beispiel über einen JSON Encoder umgesetzt werden. Wichtig ist nicht die konkrete Library, sondern das Ergebnis: Logs sollen strukturiert und einheitlich sein.

Beispielhafte logback-spring.xml:

<configuration>
    <springProperty scope=class="str">"context" name=class="str">"appName" source=class="str">"spring.application.name"/>

    <appender name=class="str">"CONSOLE" class=class="str">"ch.qos.logback.core.ConsoleAppender">
        <encoder class=class="str">"net.logstash.logback.encoder.LoggingEventCompositeJsonEncoder">
            <providers>
                <timestamp/>
                <logLevel/>
                <loggerName/>
                <threadName/>
                <message/>
                <mdc/>
                <arguments/>
                <stackTrace/>
                <pattern>
                    <pattern>
                        {
                          class="str">"service": class="str">"${appName}",
                          class="str">"runtime": class="str">"spring-boot"
                        }
                    </pattern>
                </pattern>
            </providers>
        </encoder>
    </appender>

    <root level=class="str">"INFO">
        <appender-ref ref=class="str">"CONSOLE"/>
    </root>
</configuration>

Im Container sollten Logs nach stdout/stderr geschrieben werden. Der Container schreibt nicht selbst in lokale Dateien, die später niemand findet. Die Plattform sammelt stdout/stderr zentral ein.

---

8. Trace-ID und Correlation-ID

In verteilten Systemen ist Korrelation entscheidend. Eine Benutzeraktion löst oft mehrere technische Schritte aus. Ohne gemeinsame ID ist die Suche schwer.

Beispielablauf:

Customer Portal
↓ traceId=abc123
API Gateway
↓ traceId=abc123
Order Service
↓ traceId=abc123
PostgreSQL
↓
Outbox Event
↓ traceId=abc123 im Event Header
Kafka
↓
Billing Service

Wenn die Trace-ID nur im HTTP Request existiert, aber nicht im Event Header, bricht die Kette. Deshalb muss bei Messaging darauf geachtet werden, Korrelation weiterzugeben.

Beispiel für einen Kafka Header:

package com.seb4u.demo.spring.order.infrastructure.messaging;

import org.apache.kafka.clients.producer.ProducerRecord;
import org.springframework.stereotype.Component;

import java.nio.charset.StandardCharsets;

@Component
public class OrderEventRecordFactory {

    public ProducerRecord<String, String> createRecord(
            String topic,
            String key,
            String payload,
            String traceId,
            String eventType
    ) {
        ProducerRecord<String, String> record = new ProducerRecord<>(topic, key, payload);
        record.headers().add(class="str">"trace-id", traceId.getBytes(StandardCharsets.UTF_8));
        record.headers().add(class="str">"event-type", eventType.getBytes(StandardCharsets.UTF_8));
        record.headers().add(class="str">"producer", class="str">"order-service".getBytes(StandardCharsets.UTF_8));
        return record;
    }
}

Das ist kein Luxus. Ohne solche Header wird Fehleranalyse über HTTP und Messaging hinweg deutlich schwieriger.

---

9. Metriken: technische und fachliche Werte

Metriken sollten nicht nur Infrastrukturwerte zeigen. CPU, RAM und Pod-Restarts sind wichtig, aber sie erklären nicht, ob der fachliche Prozess funktioniert.

Für den Order Service brauchen wir zum Beispiel:

Fachliche Metriken sind oft wertvoller als reine Infrastrukturwerte. Wenn die CPU niedrig ist, aber keine Bestellungen mehr verarbeitet werden, ist das System trotzdem gestört.

---

10. Eigene Metriken in Spring Boot

Mit Micrometer können eigene Metriken erzeugt werden.

package com.seb4u.demo.spring.order.observability;

import io.micrometer.core.instrument.Counter;
import io.micrometer.core.instrument.Gauge;
import io.micrometer.core.instrument.MeterRegistry;
import org.springframework.stereotype.Component;

import java.util.concurrent.atomic.AtomicLong;

@Component
public class OrderMetrics {

    private final Counter createdOrders;
    private final Counter rejectedOrders;
    private final Counter outboxPublishFailures;
    private final AtomicLong unpublishedOutboxEvents = new AtomicLong(0);

    public OrderMetrics(MeterRegistry meterRegistry) {
        this.createdOrders = Counter.builder(class="str">"orders_created_total")
                .description(class="str">"Number of successfully created orders")
                .tag(class="str">"service", class="str">"order-service")
                .register(meterRegistry);

        this.rejectedOrders = Counter.builder(class="str">"orders_rejected_total")
                .description(class="str">"Number of rejected order requests")
                .tag(class="str">"service", class="str">"order-service")
                .register(meterRegistry);

        this.outboxPublishFailures = Counter.builder(class="str">"outbox_publish_failures_total")
                .description(class="str">"Number of failed outbox publish attempts")
                .tag(class="str">"service", class="str">"order-service")
                .register(meterRegistry);

        Gauge.builder(class="str">"outbox_unpublished_events", unpublishedOutboxEvents, AtomicLong::get)
                .description(class="str">"Number of outbox events not yet published")
                .tag(class="str">"service", class="str">"order-service")
                .register(meterRegistry);
    }

    public void orderCreated() {
        createdOrders.increment();
    }

    public void orderRejected() {
        rejectedOrders.increment();
    }

    public void outboxPublishFailed() {
        outboxPublishFailures.increment();
    }

    public void updateUnpublishedOutboxEvents(long value) {
        unpublishedOutboxEvents.set(value);
    }
}

Die Metrik outbox_unpublished_events kann später direkt für Alerts verwendet werden. Wenn sie längere Zeit steigt, hängt die Event-Verarbeitung.

---

11. ServiceMonitor für Prometheus

In OpenShift mit Prometheus Operator kann ein ServiceMonitor beschreiben, wie Prometheus Metriken abholt.

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: order-service
  namespace: order-prod
  labels:
    team: order
spec:
  selector:
    matchLabels:
      app: order-service
  namespaceSelector:
    matchNames:
      - order-prod
  endpoints:
    - port: http
      path: /actuator/prometheus
      interval: 30s
      scrapeTimeout: 10s

Dazu muss der Kubernetes Service einen passenden Portnamen haben.

apiVersion: v1
kind: Service
metadata:
  name: order-service
  namespace: order-prod
  labels:
    app: order-service
spec:
  selector:
    app: order-service
  ports:
    - name: http
      port: 8080
      targetPort: 8080

Ein häufiger Fehler ist, dass ServiceMonitor und Service nicht zusammenpassen. Dann läuft die Anwendung, aber Prometheus sammelt keine Metriken.

---

12. Alerting: gute und schlechte Alarme

Ein Alarm ist nur nützlich, wenn er eine klare Handlung auslöst. Schlechte Alarme erzeugen Lärm. Gute Alarme zeigen einen Zustand, der Aufmerksamkeit braucht, und verweisen auf ein Runbook.

Schlechter Alarm:

Warum schlecht? Eine hohe CPU kann normal sein. Ohne Kontext weiß niemand, ob eine Handlung nötig ist.

Besser:

Noch besser:

Alerts sollten fachlich priorisiert werden. Nicht jeder technische Ausschlag ist ein Incident.

---

13. PrometheusRule für Outbox

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: order-service-alerts
  namespace: order-prod
  labels:
    team: order
spec:
  groups:
    - name: order-service.rules
      rules:
        - alert: OrderOutboxBacklogGrowing
          expr: outbox_unpublished_events{service=class="str">"order-service"} > 100
          for: 15m
          labels:
            severity: warning
            team: order
          annotations:
            summary: class="str">"Order Service outbox backlog is growing"
            description: class="str">"More than 100 unpublished outbox events for at least 15 minutes. Check broker connectivity and publisher logs."
            runbook_url: class="str">"docs/runbooks/outbox-stuck.md"

        - alert: OrderServiceHighErrorRate
          expr: |
            sum(rate(http_server_requests_seconds_count{application=class="str">"order-service",status=~class="str">"5.."}[5m]))
            /
            sum(rate(http_server_requests_seconds_count{application=class="str">"order-service"}[5m]))
            > 0.05
          for: 10m
          labels:
            severity: critical
            team: order
          annotations:
            summary: class="str">"Order Service has high 5xx error rate"
            description: class="str">"More than 5% of requests fail with 5xx responses for 10 minutes."
            runbook_url: class="str">"docs/runbooks/order-service-errors.md"

Diese Regeln sind besser als reine CPU-Alarme, weil sie näher am Serviceverhalten sind.

---

14. Dashboards: vom Management bis zum Entwickler

Ein Dashboard sollte nicht nur hübsch aussehen. Es muss Entscheidungen unterstützen.

Für den Order Service brauchen unterschiedliche Zielgruppen unterschiedliche Sichten.

Eine technische Sicht zeigt:

Eine fachliche Sicht zeigt:

Eine Betriebsübersicht zeigt:

Dashboards sollten nicht mit zu vielen Panels überladen werden. Ein gutes Dashboard zeigt zuerst Symptome und erlaubt dann Drilldown.

---

15. SLI, SLO und SLA

Ein SLI ist ein messbarer Indikator. Ein SLO ist ein Zielwert. Ein SLA ist eine vertragliche Zusage.

Beispiel:

Für interne Plattformen arbeitet man häufig zuerst mit SLOs, nicht sofort mit harten SLAs.

Mögliche SLOs im Lab:

SLOs zwingen Teams, über messbare Qualität zu sprechen. Ohne SLO ist „läuft gut“ nur ein Gefühl.

---

16. Betrieb über Infrastrukturgrenzen hinweg

Das Lab ist hybrid. Deshalb müssen nicht nur Kubernetes-Services beobachtet werden. Auch VMs, Bare-Metal-Systeme und Cloud-Ressourcen gehören in das Betriebsbild.

Für OpenShift sammeln wir:

Für VMs sammeln wir:

Für Bare Metal sammeln wir zusätzlich:

Für Cloud sammeln wir:

Observability darf nicht an der Clustergrenze enden.

---

17. Node Exporter für VM und Bare Metal

Node Exporter kann Linux-Systemmetriken für Prometheus bereitstellen.

Beispiel systemd Unit:

[Unit]
Description=Prometheus Node Exporter
Wants=network-online.target
After=network-online.target

[Service]
User=node_exporter
Group=node_exporter
Type=simple
ExecStart=/usr/local/bin/node_exporter \
  --web.listen-address=:9100 \
  --collector.systemd \
  --collector.filesystem.mount-points-exclude=class="str">'^/(sys|proc|dev|run)($|/)'
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

Dazu gehört eine Firewall-Regel. Prometheus darf den Node Exporter erreichen, aber nicht das ganze Netzwerk.

Auch hier gilt: Observability braucht Netzwerkfreigaben und Dokumentation.

---

18. Logging für VM-Dienste

Ein File Processing Service auf einer VM schreibt möglicherweise in journald oder in lokale Dateien. Für Enterprise-Betrieb sollte er zentral angebunden werden.

Mögliche Wege:

Beispiel Promtail-Konfiguration:

server:
  http_listen_port: 9080
  grpc_listen_port: 0

positions:
  filename: /var/lib/promtail/positions.yaml

clients:
  - url: https://loki.internal.alpine.example.com/loki/api/v1/push

scrape_configs:
  - job_name: journal
    journal:
      max_age: 12h
      labels:
        job: systemd-journal
        host: file-worker-01
    relabel_configs:
      - source_labels: [class="str">'__journal__systemd_unit']
        target_label: class="str">'unit'
      - source_labels: [class="str">'__journal_priority_keyword']
        target_label: class="str">'level'

Dadurch können Fehler aus VM-Diensten zusammen mit OpenShift-Logs betrachtet werden.

---

19. OpenTelemetry

OpenTelemetry ist ein Standard für Telemetriedaten. Es hilft, Traces, Metriken und Logs einheitlicher zu erzeugen und weiterzuleiten.

Im Lab kann OpenTelemetry genutzt werden, um Service-zu-Service-Aufrufe sichtbar zu machen.

Beispiel für Spring Boot Konfiguration:

management:
  tracing:
    sampling:
      probability: 1.0
  otlp:
    tracing:
      endpoint: http://otel-collector.observability.svc:4318/v1/traces

In Produktion wird Sampling oft niedriger gesetzt. Für Lern- und Testumgebungen kann 100 Prozent Sampling hilfreich sein, damit man alle Abläufe sieht.

OpenTelemetry ersetzt nicht automatisch gutes Logging oder gute Metriken. Es ergänzt sie.

---

20. OpenTelemetry Collector

Der Collector nimmt Telemetriedaten entgegen und leitet sie weiter.

apiVersion: v1
kind: ConfigMap
metadata:
  name: otel-collector-config
  namespace: observability
data:
  collector.yaml: |
    receivers:
      otlp:
        protocols:
          grpc:
          http:

    processors:
      batch:

    exporters:
      otlp/tempo:
        endpoint: tempo.observability.svc:4317
        tls:
          insecure: true

    service:
      pipelines:
        traces:
          receivers: [otlp]
          processors: [batch]
          exporters: [otlp/tempo]

Der Vorteil: Anwendungen müssen nicht jedes Backend direkt kennen. Sie senden an den Collector. Der Betrieb kann später das Backend ändern oder zusätzliche Exporte ergänzen.

---

21. Incident Management

Ein Incident ist eine Störung mit Auswirkung. Nicht jeder Fehler ist ein Incident. Ein einzelner 400-Fehler durch falsche Benutzereingabe ist normal. Eine dauerhaft steigende 500-Fehlerquote ist ein Incident-Kandidat.

Ein Incident-Prozess klärt:

Ohne Incident-Prozess reagieren Teams zufällig. Manche schauen Logs, andere ändern Konfiguration, jemand startet Pods neu, aber niemand koordiniert das Gesamtbild.

---

22. Runbook: Order Service hohe Fehlerquote

oc get pods -n order-prod -l app=order-service

oc get events -n order-prod --sort-by=.lastTimestamp | tail -50

oc logs -n order-prod deployment/order-service --tail=200

oc rsh -n order-prod deployment/order-service

nc -vz orders-db.internal.alpine.example.com 5432

nc -vz kafka.messaging.svc 9092

oc rollout history deployment/order-service -n order-prod

oc rollout undo deployment/order-service -n order-prod

Dieses Runbook verbindet technische Prüfung, Entscheidung und Kommunikation.

---

23. Change und Release im Betrieb

Viele Incidents entstehen nach Änderungen. Deshalb muss Observability mit Release-Management verbunden sein.

Ein Dashboard sollte anzeigen:

Ein Service kann seine Build-Informationen über Actuator Info bereitstellen.

management:
  info:
    git:
      mode: full
    env:
      enabled: true
info:
  application:
    name: order-service
    owner: team-order

Im Build sollte die Git-Commit-ID ins Artefakt geschrieben werden. Dadurch kann Betrieb später genau erkennen, welche Version läuft.

---

24. Fehlerbudget

Ein Fehlerbudget beschreibt, wie viel Unzuverlässigkeit innerhalb eines SLO toleriert wird. Wenn ein Service ein SLO von 99,5 Prozent hat, darf er im Monat eine bestimmte Zeit oder Fehlerquote verbrauchen.

Das Fehlerbudget hilft bei Entscheidungen:

Das ist besonders wichtig, wenn Entwicklung und Betrieb unterschiedliche Ziele haben. Entwicklung möchte Features liefern. Betrieb möchte Stabilität. Fehlerbudget verbindet beide Sichtweisen über messbare Qualität.

---

25. Capacity Management

Betrieb bedeutet nicht nur Störungen beheben. Betrieb bedeutet auch vorausplanen.

Capacity Management fragt:

Für das Lab kann man Lastprofile definieren:

Diese Profile helfen, Tests und Alerts realistisch zu gestalten.

---

26. Lasttest als Betriebsartefakt

Ein Lasttest ist nicht nur Entwicklung. Er ist ein Betriebsartefakt, weil er zeigt, wie sich das System unter Druck verhält.

Beispiel mit k6:

import http from class="str">'k6/http';
import { check, sleep } from class="str">'k6';

export const options = {
  stages: [
    { duration: class="str">'2m', target: 20 },
    { duration: class="str">'5m', target: 100 },
    { duration: class="str">'2m', target: 0 }
  ],
  thresholds: {
    http_req_failed: [class="str">'rate<0.02'],
    http_req_duration: [class="str">'p(95)<500']
  }
};

export default function () {
  const payload = JSON.stringify({
    customerId: class="str">'C-10001',
    items: [
      { productId: class="str">'P-100', quantity: 1, unitPrice: 29.90 }
    ]
  });

  const params = {
    headers: {
      class="str">'Content-Type': class="str">'application/json',
      class="str">'Authorization': `Bearer ${__ENV.ACCESS_TOKEN}`
    }
  };

  const response = http.post(`${__ENV.API_URL}/orders`, payload, params);

  check(response, {
    class="str">'status is 201': (r) => r.status === 201,
    class="str">'response time below 500ms': (r) => r.timings.duration < 500
  });

  sleep(1);
}

Der Lasttest gehört in Git. Ergebnisse sollten mit Version, Umgebung und Konfiguration dokumentiert werden.

---

27. Betrieb von Batch und CronJobs

Nicht alle Workloads sind APIs. Reporting, File Processing und Abgleichjobs laufen oft zeitgesteuert.

Bei CronJobs sind andere Fragen wichtig:

Beispiel Kubernetes CronJob:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: nightly-report-export
  namespace: reporting-prod
spec:
  schedule: class="str">"0 2 * * *"
  concurrencyPolicy: Forbid
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 5
  jobTemplate:
    spec:
      backoffLimit: 2
      template:
        spec:
          restartPolicy: Never
          containers:
            - name: report-export
              image: registry.example.com/alpine/report-export:1.2.0
              envFrom:
                - secretRef:
                    name: reporting-db-secret

concurrencyPolicy: Forbid verhindert, dass ein neuer Lauf startet, während der alte noch läuft. Das ist wichtig für viele Batchprozesse.

---

28. Runbook: CronJob fehlgeschlagen

oc get cronjob -n reporting-prod nightly-report-export

oc get jobs -n reporting-prod --sort-by=.metadata.creationTimestamp

oc logs -n reporting-prod job/<job-name>

oc create job -n reporting-prod manual-report-export-$(date +%Y%m%d%H%M) \

--from=cronjob/nightly-report-export

Batchbetrieb braucht genauso klare Runbooks wie APIs.

---

29. Postmortem statt Schuldsuche

Nach einem Incident sollte ein Postmortem erstellt werden. Das Ziel ist Lernen, nicht Schuldzuweisung.

Ein gutes Postmortem enthält:

Wichtig ist, konkrete Verbesserungen abzuleiten. Ein Postmortem ohne Maßnahmen ist nur ein Bericht.

---

30. Beispiel-Postmortem Kurzfassung

Dieses Beispiel zeigt, dass ein technischer Fehler in Netzwerkpolicy, Deploymentprozess, Testabdeckung und Runbook sichtbar wird.

---

31. Übung: Observability-Konzept für Billing Service

Erstelle ein Observability-Konzept für den Billing Service.

Es soll enthalten:

Denke daran: Billing ist eventgetrieben. Es reicht nicht, HTTP Requests zu betrachten. Der Service muss Broker, Event-Lag, Idempotenz, Datenbank und fachliche Rechnungsverarbeitung sichtbar machen.

---

32. Musterlösung zur Übung

Eine mögliche Lösung:

Diese Lösung zeigt den Unterschied zwischen API-Monitoring und Event-Monitoring.

---

33. Merksätze

Backup, Restore und Disaster Recovery

1. Warum Backup nicht erst am Ende geplant wird

Backup wird in vielen Projekten zu spät betrachtet. Eine Anwendung wird entwickelt, deployt, überwacht und erst danach fragt jemand, wie die Daten wiederhergestellt werden können. In einem Enterprise-Projekt ist das falsch. Backup, Restore und Disaster Recovery gehören von Anfang an zur Architektur.

Der Grund ist einfach: Eine Plattform ist nur so belastbar wie ihre Wiederherstellung. Es reicht nicht, dass ein Service heute läuft. Entscheidend ist, ob er nach einem Fehlerzustand wieder kontrolliert in einen brauchbaren Zustand gebracht werden kann.

Fehler können sehr unterschiedlich sein:

Nicht jeder Fehler braucht dieselbe Antwort. Ein Pod-Neustart ist kein Disaster Recovery. Eine versehentlich gelöschte Datenbank ist ein Restore-Fall. Der Ausfall eines Standorts ist ein Disaster-Recovery-Fall. Eine fehlerhafte fachliche Verarbeitung kann wiederum einen fachlichen Korrekturprozess brauchen, nicht nur ein technisches Backup.

Deshalb trennt dieses Kapitel drei Begriffe:

Eine moderne Hybrid-Plattform braucht alle drei Ebenen.

---

2. RPO und RTO

Zwei Begriffe sind für Backup und Disaster Recovery besonders wichtig.

RPO bedeutet Recovery Point Objective. Es beschreibt, wie viel Datenverlust maximal akzeptiert wird.

RTO bedeutet Recovery Time Objective. Es beschreibt, wie lange die Wiederherstellung maximal dauern darf.

Beispiel:

Das bedeutet: Im Fehlerfall darf das Unternehmen höchstens Daten aus den letzten 15 Minuten verlieren, und der Dienst soll innerhalb von zwei Stunden wieder nutzbar sein.

Diese Werte sind keine technischen Spielereien. Sie sind Geschäftsentscheidungen. Ein Customer Portal darf vielleicht 30 Minuten ausfallen. Eine Zahlungsabrechnung darf eventuell länger pausieren, darf aber keine Daten verlieren. Ein Reporting-System kann vielleicht einen Tag später wiederhergestellt werden. Ein Identity-System wie Keycloak ist kritischer, weil ohne Login viele andere Systeme nicht nutzbar sind.

Für das Lab definieren wir beispielhaft:

Diese Werte sind nur Beispiele. Wichtig ist die Denkweise: Nicht alle Systeme bekommen automatisch dieselben Ziele.

---

3. Was überhaupt gesichert werden muss

Backup bedeutet nicht nur Datenbankdump. In einer Hybrid-Plattform gibt es viele sicherungswürdige Artefakte.

Gesichert werden müssen unter anderem:

Dabei ist wichtig: Nicht alles wird gleich gesichert. Git-Repositories enthalten deklarative Plattformdefinitionen. Sie werden über Git selbst gesichert. Datenbanken brauchen konsistente Datenbanksicherungen. Object Storage braucht Versionierung, Replikation oder Snapshots. Kubernetes-Secrets dürfen nicht einfach unverschlüsselt exportiert werden.

Ein häufiger Fehler ist, nur die Datenbank zu sichern und die Plattformdefinitionen zu vergessen. Dann hat man zwar Daten, aber keine saubere Möglichkeit, die Umgebung wieder aufzubauen.

Ein anderer Fehler ist, nur Kubernetes-Ressourcen zu exportieren und zu glauben, damit sei die Anwendung vollständig gesichert. Persistent Volumes, externe Datenbanken und Cloud-Ressourcen fehlen dann oft.

---

4. Backup-Strategie für PostgreSQL

PostgreSQL ist im Lab zentral. Order Service und Billing Service verwenden eigene Datenbanken. Reporting kann Daten aus beiden Bereichen lesen oder eigene Kopien verwenden.

Für produktionsnahe PostgreSQL-Systeme reicht ein gelegentlicher Dump nicht aus. Eine bessere Strategie kombiniert:

WAL steht für Write-Ahead Log. Über WAL-Archivierung kann PostgreSQL Änderungen zwischen Full Backups nachvollziehen. Dadurch wird Point-in-Time-Recovery möglich.

Point-in-Time-Recovery bedeutet: Die Datenbank kann auf einen bestimmten Zeitpunkt zurückgesetzt werden, zum Beispiel kurz vor einer fehlerhaften Migration.

Ein einfaches Backup-Konzept für Orders könnte so aussehen:

Wichtig: Ein Backup, das nie zurückgespielt wurde, ist nur eine Hoffnung.

---

5. Beispiel: PostgreSQL Backup-Skript

Für ein Lab kann ein einfaches Skript genutzt werden. In Produktion würde man häufig spezialisierte Werkzeuge verwenden, aber das Prinzip bleibt gleich.

#!/usr/bin/env bash
set -euo pipefail

APP_NAME=class="str">"orders-db"
BACKUP_DIR=class="str">"/backup/postgresql/orders"
DATE=class="str">"$(date +%Y%m%d-%H%M%S)"
FILE=class="str">"${BACKUP_DIR}/${APP_NAME}-${DATE}.dump"
LOG_FILE=class="str">"${BACKUP_DIR}/${APP_NAME}-${DATE}.log"

mkdir -p class="str">"${BACKUP_DIR}"

export PGHOST=class="str">"${PGHOST:-orders-db.internal.alpine.example.com}"
export PGPORT=class="str">"${PGPORT:-5432}"
export PGDATABASE=class="str">"${PGDATABASE:-orders}"
export PGUSER=class="str">"${PGUSER:-backup_user}"

{
  echo class="str">"Starting backup for ${PGDATABASE} at ${DATE}"

  pg_dump \
    --format=custom \
    --verbose \
    --file=class="str">"${FILE}" \
    class="str">"${PGDATABASE}"

  sha256sum class="str">"${FILE}" > class="str">"${FILE}.sha256"

  echo class="str">"Backup completed: ${FILE}"
  echo class="str">"Checksum written: ${FILE}.sha256"
} 2>&1 | tee class="str">"${LOG_FILE}"

Dieses Skript erzeugt einen komprimierten Dump im Custom-Format und zusätzlich eine Prüfsumme. Die Prüfsumme hilft zu erkennen, ob die Datei später beschädigt wurde.

Für Enterprise-Betrieb fehlen hier noch Dinge wie Secret Handling, zentrale Logs, Aufbewahrungsregeln, Upload in ein Backup-Repository und Monitoring. Trotzdem zeigt das Beispiel die Grundlage.

---

6. Restore ist wichtiger als Backup

Viele Teams können ein Backup erzeugen. Weniger Teams können zuverlässig wiederherstellen.

Restore muss geübt werden. Ein Restore-Test beantwortet Fragen wie:

Ein Restore-Test sollte nicht auf Produktion durchgeführt werden. Er läuft in einer isolierten Umgebung, zum Beispiel in einem Test-Namespace oder auf einer separaten VM.

---

7. Beispiel: PostgreSQL Restore in Testumgebung

#!/usr/bin/env bash
set -euo pipefail

BACKUP_FILE=class="str">"$1"
TARGET_DB=class="str">"orders_restore_test"

if [[ ! -f class="str">"${BACKUP_FILE}" ]]; then
  echo class="str">"Backup file not found: ${BACKUP_FILE}" >&2
  exit 1
fi

createdb class="str">"${TARGET_DB}" || true

pg_restore \
  --clean \
  --if-exists \
  --no-owner \
  --dbname=class="str">"${TARGET_DB}" \
  class="str">"${BACKUP_FILE}"

psql class="str">"${TARGET_DB}" -c class="str">"SELECT count(*) AS orders_count FROM orders;"
psql class="str">"${TARGET_DB}" -c class="str">"SELECT count(*) AS outbox_count FROM outbox_events;"

Nach dem Restore reicht es nicht, dass der Befehl erfolgreich war. Es müssen fachliche Prüfungen erfolgen. Zum Beispiel: Anzahl der Bestellungen, Statusverteilung, offene Outbox Events und Datenkonsistenz zwischen Orders und Order Items.

---

8. Persistent Volumes in OpenShift

OpenShift-Anwendungen können Persistent Volumes verwenden. Dabei muss man verstehen, was gesichert wird.

Ein Deployment selbst ist deklarativ und liegt idealerweise in Git. Ein Persistent Volume enthält Laufzeitdaten. Wenn diese Daten wichtig sind, braucht das Volume eine Backup-Strategie.

Beispiele für persistente Daten im Cluster:

In produktionsnahen Architekturen sollte man kritisch prüfen, ob wichtige Daten wirklich nur in einem Kubernetes-Volume liegen sollen. Häufig ist eine externe Datenbank oder Object Storage besser geeignet.

Wenn Persistent Volumes verwendet werden, muss klar sein:

---

9. VolumeSnapshot Beispiel

Wenn der Cluster VolumeSnapshots unterstützt, kann ein Snapshot so aussehen:

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: reporting-data-snapshot-2026-07-05
  namespace: reporting-prod
spec:
  volumeSnapshotClassName: csi-snapshot-class
  source:
    persistentVolumeClaimName: reporting-data

Ein Snapshot ist aber kein vollständiges Backup-Konzept. Er liegt oft im selben Storage-System. Wenn dieses Storage-System ausfällt, ist auch der Snapshot betroffen. Für Disaster Recovery braucht man zusätzliche Kopien oder Replikation in eine andere Zone oder einen anderen Standort.

---

10. Object Storage und Versionierung

Object Storage eignet sich sehr gut für Partnerdateien, Exporte, Reports und Backup-Artefakte. Im Lab kann Object Storage durch Cloud-S3 oder MinIO bereitgestellt werden.

Für wichtige Buckets sollten folgende Funktionen geprüft werden:

Versionierung schützt vor versehentlichem Überschreiben. Lifecycle-Regeln verschieben alte Objekte in günstigere Speicherklassen oder löschen temporäre Dateien nach definierter Zeit. Object Lock kann vor absichtlichem oder versehentlichem Löschen schützen, ist aber organisatorisch sorgfältig zu planen.

Beispiel für Bucket-Regeln:

---

11. Beispiel: MinIO Client für Backup-Kopie

#!/usr/bin/env bash
set -euo pipefail

BACKUP_FILE=class="str">"$1"
BUCKET=class="str">"backup-artifacts/postgresql/orders"
ALIAS=class="str">"labminio"

if [[ ! -f class="str">"${BACKUP_FILE}" ]]; then
  echo class="str">"Backup file not found: ${BACKUP_FILE}" >&2
  exit 1
fi

mc cp class="str">"${BACKUP_FILE}" class="str">"${ALIAS}/${BUCKET}/"
mc cp class="str">"${BACKUP_FILE}.sha256" class="str">"${ALIAS}/${BUCKET}/"

mc ls class="str">"${ALIAS}/${BUCKET}/"

Die Kopie in Object Storage ist nützlich, weil sie Backup-Dateien von der Datenbankmaschine trennt. Wenn die Datenbankmaschine verloren geht, liegt das Backup nicht nur lokal auf demselben System.

---

12. Keycloak Backup

Keycloak ist kritisch, weil viele Anwendungen von Login und Token-Ausstellung abhängen. Ohne Keycloak funktionieren Customer Portal, Admin Portal und API-Zugriffe nicht korrekt.

Bei Keycloak müssen zwei Dinge betrachtet werden:

Wenn Keycloak eine PostgreSQL-Datenbank verwendet, wird diese wie andere PostgreSQL-Datenbanken gesichert. Zusätzlich kann die Realm-Konfiguration exportiert werden, damit Clients, Rollen, Gruppen und Mappings nachvollziehbar bleiben.

Ein Realm-Export ist kein Ersatz für ein konsistentes Datenbankbackup, aber ein wichtiger zusätzlicher Nachweis.

Beispiel:

/opt/keycloak/bin/kc.sh export \
  --realm alpine \
  --file /backup/keycloak/alpine-realm-$(date +%Y%m%d).json

In einem GitOps-orientierten Projekt sollten Keycloak-Clients und Rollen möglichst deklarativ beschrieben werden. Dann ist ein Realm nicht nur ein Zustand in einer Oberfläche, sondern Teil der Plattformdefinition.

---

13. Git als Wiederherstellungsquelle

Git ist nicht nur für Anwendungscode wichtig. Git enthält im Zielbild auch:

Wenn ein Cluster neu aufgebaut werden muss, ist Git die wichtigste Quelle für den gewünschten Zustand.

Aber Git allein reicht nicht. Git enthält nicht automatisch Datenbanken, Object Storage Inhalte oder dynamische Secrets. Deshalb muss klar getrennt werden: