Docker-Compose-Guide

Lokale Entwicklungsumgebung: eine PostgreSQL-Instanz (mit sechs Datenbanken, eine je Service, siehe ADR-0003) und ein Single-Node-Kafka-Broker (KRaft-Modus, kein ZooKeeper nötig). Bewusst kein Kubernetes/Helm — siehe ADR-0004.

Starten

cd infra
docker compose up -d

Dienst	Port	Zugangsdaten
PostgreSQL	`localhost:5432`	Benutzer `aurorabank`, Passwort `aurorabank`; Datenbanken: `customer_db`, `accounts_db`, `cards_db`, `payments_db`, `lending_db`, `notification_db`
Kafka	`localhost:9092`	kein Auth (nur lokale Entwicklung)
Keycloak	`localhost:8180`	Admin-Konsole: `admin`/`admin`; Realm `aurorabank` wird per `--import-realm` automatisch geladen (siehe `infra/keycloak/aurorabank-realm.json`)

Jeder Service verbindet sich über sein eigenes application.yml mit seiner Datenbank (spring.datasource.url=jdbc:postgresql://localhost:5432/<service>_db) — niemals mit der eines anderen Service.

Stoppen / Zurücksetzen

docker compose down          # stoppen, Daten bleiben im Volume erhalten
docker compose down -v       # stoppen und alle Daten loeschen (frischer Start)

Verhältnis zu Testcontainers

Dieses docker-compose.yml ist für manuelle, interaktive lokale Entwicklung (z. B. einen Service mit mvn spring-boot:run starten und mit curl/Postman ausprobieren). Automatisierte Integrationstests (*IT.java) verwenden nicht diese Instanz, sondern starten ihre eigenen, isolierten Testcontainers-Container (siehe ADR-0006 und common-testing) — so bleiben Testläufe reproduzierbar und unabhängig davon, ob docker compose up gerade läuft oder welchen Datenstand die manuelle Instanz gerade hat.

Keycloak

docker-compose.yml enthält einen Keycloak-Dienst mit vorkonfiguriertem Realm-Export (infra/keycloak/aurorabank-realm.json, per start-dev --import-realm automatisch geladen: Realm aurorabank, ein öffentlicher Client aurorabank-swagger, ein Testnutzer alice/alice123). Nur customer-service prüft Tokens tatsächlich (siehe ADR-0007) - alle anderen fünf Services laufen weiterhin ohne Authentifizierung, eine bewusste Scope-Entscheidung, um den TDD-Kern-Flow der übrigen Domain-Use-Cases nicht nachträglich zu verwässern.