# infra Alles, was NICHT Anwendungscode ist: lokale Infrastruktur (Podman Compose), Kubernetes/Helm, CI-Pipeline, Lasttest. Diese Seite ist die Landkarte über das gesamte Verzeichnis - für die Details jedes Themas siehe die verlinkten Tiefen-Dokumente. > Dieses Projekt nutzt **Podman** (rootless, daemonless) statt Docker. `podman compose` > delegiert an das eingebaute Compose-Backend; alternativ funktioniert `podman-compose` > (separates Python-Tool). Dateinamen wie `docker-compose.yml` und `Dockerfile` bleiben > bewusst erhalten - Podman liest sie unverändert. ## Verzeichnisstruktur ``` infra/ ├── docker-compose.yml Komplette lokale Umgebung: Infrastruktur + optional alle 9 Services ├── postgres/ │ └── init-multiple-dbs.sh Legt beim ersten Start 7 logische Datenbanken in EINER Postgres-Instanz an ├── keycloak/ │ └── realm-library.json Realm-Export: Rollen, Clients, 3 Testnutzer (siehe unten) ├── prometheus/ │ └── prometheus.yml Scrape-Konfiguration für alle 9 Services (/actuator/prometheus) ├── grafana/ │ └── provisioning/ │ └── datasources/ Prometheus-Datasource wird beim Start automatisch verdrahtet (kein manuelles Einrichten nötig) ├── helm/ │ ├── library-service/ EIN generisches Helm-Chart für 9 Anwendungen (8 Backends + Frontend) │ └── values/ Eine values-Datei je Anwendung (Image, Port, Umgebungsvariablen, Ingress/HPA) ├── ci/ │ └── README.md Erklärt .github/workflows/ci.yml (liegt aus technischen Gründen im Repo-Root, siehe dort) └── k6/ └── borrow-load-test.js Lasttest gegen den Ausleih-Endpunkt (siehe "Lasttest" unten) ``` ## Podman Compose: die lokale Umgebung ```bash cd infra podman compose up -d # alles im Hintergrund starten podman compose ps # Status prüfen podman compose logs -f kafka # Logs eines einzelnen Containers verfolgen podman compose down # stoppen, Volumes (Daten) bleiben erhalten podman compose down -v # stoppen UND Volumes löschen - kompletter Neustart ``` Seit Phase 7 zwei Betriebsarten: 1. **Alles containerisiert**: `podman compose up -d` baut und startet auch alle neun Spring-Boot-Services (Erstlauf dauert wegen des Maven-Reactor-Builds im [`library-platform/Dockerfile`](../library-platform/Dockerfile) einige Minuten). 2. **Nur Infrastruktur**: gezielt einzelne Container starten, z. B. `podman compose up -d postgres kafka rabbitmq redis keycloak config-server discovery-server`, und einzelne Java-Services stattdessen aus der IDE heraus laufen lassen (Breakpoints, Hot-Reload) - der bisherige Standard-Workflow aus Phase 1-6. **Ausführliche Anleitung (inkl. Podman-Machine-Setup unter Windows), Port-Tabelle, bekannte Stolpersteine:** [docker-compose-guide.md](../documentation/docs/05-devops/docker-compose-guide.md). ### Alle Komponenten auf einen Blick | Komponente | Host-Port | Zweck | Login/Zugang | |---|---|---|---| | PostgreSQL | 5432 | 7 logische DBs in einer Instanz (siehe `postgres/init-multiple-dbs.sh`) | library / library | | pgAdmin | 5050 | Web-UI für Postgres | admin@library-platform.local / admin | | Redis | 6379 | Cache (catalog-service) | - | | Kafka | 9092 | Event-Bus (KRaft-Modus, kein Zookeeper) | - | | Kafka UI | 8090 | Topics/Nachrichten inspizieren | - | | RabbitMQ (AMQP) | 5672 | Task-/Command-Queues | library / library | | RabbitMQ Management | 15672 | Web-UI | library / library | | Keycloak | 8180 | Identity Provider (OAuth2/OIDC) | admin / admin (Admin-Konsole); siehe Testnutzer unten | | Prometheus | 9090 | Metriken | - | | Grafana | 3000 | Dashboards | admin / admin | | Zipkin | 9411 | Distributed Tracing | - | | discovery-server | 8761 | Eureka-Dashboard (nur Compose-Profil, siehe ADR-0007) | - | | config-server | 8888 | `curl localhost:8888/catalog-service/default` | - | | api-gateway | 8080 | Single Entry Point für das Frontend | - | | catalog-service | 8081 | | | | member-service | 8082 | | | | lending-service | 8083 | | | | reservation-service | 8084 | | | | fine-service | 8085 | | | | notification-service | 8086 | | | | Angular-Frontend (dev) | 4200 | `cd ../library-frontend && npx ng serve` | | ### Keycloak: Realm und Testnutzer `keycloak/realm-library.json` wird beim ersten Container-Start automatisch importiert (`start-dev --import-realm`). Enthält den Realm `library` mit drei Rollen (`LIBRARY_ADMIN`, `LIBRARIAN`, `MEMBER`, siehe `common-security.LibraryRoles`), zwei Clients (`library-frontend` - public, PKCE; `library-swagger-ui` - public, Direct Access Grants für Swagger-UI-"Try it out" und den k6-Lasttest) und drei Testnutzer: | Benutzername | Passwort | Rolle | |---|---|---| | `admin.bibliothek` | `admin123` | LIBRARY_ADMIN | | `lisa.bibliothekarin` | `librarian123` | LIBRARIAN | | `erika.mustermann` | `member123` | MEMBER | **Nur zur lokalen Entwicklung** - diese Zugangsdaten stehen im Klartext im Repository, siehe Sicherheitshinweis in [docker-compose-guide.md](../documentation/docs/05-devops/docker-compose-guide.md). ### Observability: Prometheus, Grafana, Zipkin Seit Phase 7 mit echten Daten (`common-observability`-Modul in jedem Service, siehe [library-platform/common-observability/README.md](../library-platform/common-observability/README.md)). Ausführliche Anleitung, Beispiel-Queries, Trace-Interpretation: **[observability.md](../documentation/docs/05-devops/observability.md)**. ## Kubernetes/Helm `helm/library-service` ist EIN generisches Chart für neun in Kubernetes betriebene Anwendungen (acht Backend-Services plus `library-frontend`; `discovery-server` wird gemäß [ADR-0007](../documentation/docs/01-architektur/adr/0007-service-discovery.md) nicht in Kubernetes betrieben), parametrisiert durch je eine eigene Datei in `helm/values/`. ```bash helm lint helm/library-service -f helm/values/catalog-service-values.yaml helm template catalog-service helm/library-service -f helm/values/catalog-service-values.yaml -n library ``` **Vollständige Anleitung** (Deployment-Schritte, Infrastruktur-Voraussetzungen, Vergleich Compose vs. Kubernetes): **[kubernetes-guide.md](../documentation/docs/05-devops/kubernetes-guide.md)**. ## CI-Pipeline Der lauffähige Workflow liegt unter [`.github/workflows/ci.yml`](../.github/workflows/ci.yml) im Repository-Root (GitHub erkennt Workflows ausschließlich dort). `ci/README.md` in diesem Verzeichnis erklärt die vier Jobs (Backend, Frontend, Container-Image-Matrix, Helm-Lint) und den bewussten Cut zwischen CI und echtem CD: **[ci/README.md](ci/README.md)**. ## Lasttest (k6) `k6/borrow-load-test.js` fährt eine Lastspitze (bis 50 virtuelle Nutzer:innen) gegen `POST /api/loans` über `api-gateway`, um das Verhalten der Resilience4j-Circuit-Breaker-/Retry- Konfiguration in `lending-service` unter Last sichtbar zu machen. Legt in einer `setup()`-Phase selbst Testdaten an (ein Buch mit 500 Exemplaren, 20 Mitglieder) - keine Vorbereitung nötig außer einem laufenden Stack. ```bash # Stack muss laufen: podman compose up -d (siehe oben) k6 run k6/borrow-load-test.js ``` Realistisch bleibt eine Fehlerquote eingeplant statt ausgeblendet: STANDARD-Mitglieder dürfen laut Fachregel maximal 3 aktive Ausleihen haben (`MembershipTier.java`) - bei genug Last läuft ein wiederverwendetes Mitglied absichtlich in HTTP 422. Details und Interpretation der Ergebnisse (Circuit-Breaker-Metriken in Grafana beobachten) direkt im Skript-Kommentar. ## Verwandte Dokumentation - [docker-compose-guide.md](../documentation/docs/05-devops/docker-compose-guide.md) - Port-Tabelle, Betriebsarten, Stolpersteine - [observability.md](../documentation/docs/05-devops/observability.md) - Metriken/Tracing im Detail - [kubernetes-guide.md](../documentation/docs/05-devops/kubernetes-guide.md) - Helm-Deployment im Detail - [ci/README.md](ci/README.md) - CI-Pipeline im Detail - [ADR-0002: Database-per-Service](../documentation/docs/01-architektur/adr/0002-database-per-service.md) - [ADR-0003: Kafka und RabbitMQ](../documentation/docs/01-architektur/adr/0003-kafka-und-rabbitmq.md) - [ADR-0004: Keycloak/OIDC](../documentation/docs/01-architektur/adr/0004-keycloak-oidc.md) - [ADR-0007: Service Discovery](../documentation/docs/01-architektur/adr/0007-service-discovery.md)