Praxis-Labs Tiefenfinalisierung

Ziel: Docker Compose Stack sauber hochfahren und jeden Dienst pruefen.

Aufgabe: Fuehre die Befehle aus und notiere, welche Komponente beteiligt ist.

docker compose up -d
docker compose ps
docker compose logs postgres --tail=30

Erwartete Beobachtung:
- Alle Container sind running oder healthy.
- Adminer, RabbitMQ, Keycloak und Grafana sind erreichbar.

Loesung / Auswertung:
1. Pruefe zuerst den technischen Status.
2. Vergleiche dann Datenbank, Queue, Log oder HTTP-Antwort.
3. Notiere nicht nur, dass es funktioniert, sondern warum.

Varianten:
- Fuehre denselben Schritt mit bewusst falscher Konfiguration aus.
- Suche den Fehler mit dem Fehlerkatalog.
- Erstelle einen Screenshot oder eine kurze Notiz fuer spaetere Wiederholung.

Ziel: REST Flow ausloesen und Datenbankwirkung verstehen.

Aufgabe: Fuehre die Befehle aus und notiere, welche Komponente beteiligt ist.

curl -X POST http://localhost:8080/api/orders/ORD-LAB-02/accept
select * from order_platform.orders where order_id='ORD-LAB-02';

Erwartete Beobachtung:
- Order existiert.
- Status ist ACCEPTED.

Loesung / Auswertung:
1. Pruefe zuerst den technischen Status.
2. Vergleiche dann Datenbank, Queue, Log oder HTTP-Antwort.
3. Notiere nicht nur, dass es funktioniert, sondern warum.

Varianten:
- Fuehre denselben Schritt mit bewusst falscher Konfiguration aus.
- Suche den Fehler mit dem Fehlerkatalog.
- Erstelle einen Screenshot oder eine kurze Notiz fuer spaetere Wiederholung.

Ziel: Outbox Event von NEW nach PUBLISHED beobachten.

Aufgabe: Fuehre die Befehle aus und notiere, welche Komponente beteiligt ist.

select event_id,event_type,status from outbox.events order by event_id desc;
sleep 6
select event_id,event_type,status,published_at from outbox.events order by event_id desc;

Erwartete Beobachtung:
- Event ist gespeichert.
- Relay markiert es als PUBLISHED.

Loesung / Auswertung:
1. Pruefe zuerst den technischen Status.
2. Vergleiche dann Datenbank, Queue, Log oder HTTP-Antwort.
3. Notiere nicht nur, dass es funktioniert, sondern warum.

Varianten:
- Fuehre denselben Schritt mit bewusst falscher Konfiguration aus.
- Suche den Fehler mit dem Fehlerkatalog.
- Erstelle einen Screenshot oder eine kurze Notiz fuer spaetere Wiederholung.

Ziel: Exchange, Routing Key und Consumer nachvollziehen.

Aufgabe: Fuehre die Befehle aus und notiere, welche Komponente beteiligt ist.

curl -u order_user:order_pass http://localhost:15672/api/queues/%2F/billing.order-accepted
docker compose logs rabbitmq --tail=80

Erwartete Beobachtung:
- Queue existiert.
- Messages werden geroutet oder konsumiert.

Loesung / Auswertung:
1. Pruefe zuerst den technischen Status.
2. Vergleiche dann Datenbank, Queue, Log oder HTTP-Antwort.
3. Notiere nicht nur, dass es funktioniert, sondern warum.

Varianten:
- Fuehre denselben Schritt mit bewusst falscher Konfiguration aus.
- Suche den Fehler mit dem Fehlerkatalog.
- Erstelle einen Screenshot oder eine kurze Notiz fuer spaetere Wiederholung.

Ziel: Mit order-admin Token geschuetzten Endpoint aufrufen.

Aufgabe: Fuehre die Befehle aus und notiere, welche Komponente beteiligt ist.

./scripts/security/get-keycloak-token.sh order-admin admin
./scripts/security/call-secured-order-flow.sh

Erwartete Beobachtung:
- HTTP 200 oder erfolgreicher REST Flow.

Loesung / Auswertung:
1. Pruefe zuerst den technischen Status.
2. Vergleiche dann Datenbank, Queue, Log oder HTTP-Antwort.
3. Notiere nicht nur, dass es funktioniert, sondern warum.

Varianten:
- Fuehre denselben Schritt mit bewusst falscher Konfiguration aus.
- Suche den Fehler mit dem Fehlerkatalog.
- Erstelle einen Screenshot oder eine kurze Notiz fuer spaetere Wiederholung.

Ziel: Mit order-reader die Grenze zwischen 401 und 403 verstehen.

Aufgabe: Fuehre die Befehle aus und notiere, welche Komponente beteiligt ist.

./scripts/security/get-keycloak-token.sh order-reader reader
curl -i -X POST http://localhost:8080/api/orders/ORD-LAB-06/accept -H "Authorization: Bearer $TOKEN"

Erwartete Beobachtung:
- Token gueltig, aber Rolle reicht nicht.
- Erwartung: 403.

Loesung / Auswertung:
1. Pruefe zuerst den technischen Status.
2. Vergleiche dann Datenbank, Queue, Log oder HTTP-Antwort.
3. Notiere nicht nur, dass es funktioniert, sondern warum.

Varianten:
- Fuehre denselben Schritt mit bewusst falscher Konfiguration aus.
- Suche den Fehler mit dem Fehlerkatalog.
- Erstelle einen Screenshot oder eine kurze Notiz fuer spaetere Wiederholung.

Ziel: Providerfehler simulieren und Resilience beobachten.

Aufgabe: Fuehre die Befehle aus und notiere, welche Komponente beteiligt ist.

curl http://localhost:8089/__admin/mappings
curl -i -X POST http://localhost:8089/payment/authorize

Erwartete Beobachtung:
- Mapping ist sichtbar.
- Fehler kann ueber Mapping variiert werden.

Loesung / Auswertung:
1. Pruefe zuerst den technischen Status.
2. Vergleiche dann Datenbank, Queue, Log oder HTTP-Antwort.
3. Notiere nicht nur, dass es funktioniert, sondern warum.

Varianten:
- Fuehre denselben Schritt mit bewusst falscher Konfiguration aus.
- Suche den Fehler mit dem Fehlerkatalog.
- Erstelle einen Screenshot oder eine kurze Notiz fuer spaetere Wiederholung.

Ziel: Runtime Metriken von Prometheus aus betrachten.

Aufgabe: Fuehre die Befehle aus und notiere, welche Komponente beteiligt ist.

curl http://localhost:8080/actuator/prometheus | head
curl http://localhost:9090/api/v1/targets

Erwartete Beobachtung:
- Runtime liefert Metriken.
- Prometheus Target ist UP.

Loesung / Auswertung:
1. Pruefe zuerst den technischen Status.
2. Vergleiche dann Datenbank, Queue, Log oder HTTP-Antwort.
3. Notiere nicht nur, dass es funktioniert, sondern warum.

Varianten:
- Fuehre denselben Schritt mit bewusst falscher Konfiguration aus.
- Suche den Fehler mit dem Fehlerkatalog.
- Erstelle einen Screenshot oder eine kurze Notiz fuer spaetere Wiederholung.

Ziel: Metriken fachlich interpretieren.

Aufgabe: Fuehre die Befehle aus und notiere, welche Komponente beteiligt ist.

open http://localhost:3000
admin/admin

Erwartete Beobachtung:
- Dashboard zeigt HTTP, Latenz oder Outbox-Signale.

Loesung / Auswertung:
1. Pruefe zuerst den technischen Status.
2. Vergleiche dann Datenbank, Queue, Log oder HTTP-Antwort.
3. Notiere nicht nur, dass es funktioniert, sondern warum.

Varianten:
- Fuehre denselben Schritt mit bewusst falscher Konfiguration aus.
- Suche den Fehler mit dem Fehlerkatalog.
- Erstelle einen Screenshot oder eine kurze Notiz fuer spaetere Wiederholung.

Ziel: Domain darf keine Spring-Abhaengigkeit haben.

Aufgabe: Fuehre die Befehle aus und notiere, welche Komponente beteiligt ist.

grep -R "org.springframework" maven-project/domain/src/main/java || true
mvn -pl domain test

Erwartete Beobachtung:
- Kein Spring Import in domain.

Loesung / Auswertung:
1. Pruefe zuerst den technischen Status.
2. Vergleiche dann Datenbank, Queue, Log oder HTTP-Antwort.
3. Notiere nicht nur, dass es funktioniert, sondern warum.

Varianten:
- Fuehre denselben Schritt mit bewusst falscher Konfiguration aus.
- Suche den Fehler mit dem Fehlerkatalog.
- Erstelle einen Screenshot oder eine kurze Notiz fuer spaetere Wiederholung.

Ziel: Testcontainers und Failsafe ausfuehren.

Aufgabe: Fuehre die Befehle aus und notiere, welche Komponente beteiligt ist.

./scripts/tests/run-phase4-e2e.sh
mvn -pl integration-tests -am verify

Erwartete Beobachtung:
- *IT.java Tests werden ausgefuehrt.

Loesung / Auswertung:
1. Pruefe zuerst den technischen Status.
2. Vergleiche dann Datenbank, Queue, Log oder HTTP-Antwort.
3. Notiere nicht nur, dass es funktioniert, sondern warum.

Varianten:
- Fuehre denselben Schritt mit bewusst falscher Konfiguration aus.
- Suche den Fehler mit dem Fehlerkatalog.
- Erstelle einen Screenshot oder eine kurze Notiz fuer spaetere Wiederholung.

Ziel: Datenbankdump erstellen und kontrollieren.

Aufgabe: Fuehre die Befehle aus und notiere, welche Komponente beteiligt ist.

./scripts/db/backup-postgres.sh
ls -lh backups/

Erwartete Beobachtung:
- Backup-Datei existiert und ist groesser als 0 Bytes.

Loesung / Auswertung:
1. Pruefe zuerst den technischen Status.
2. Vergleiche dann Datenbank, Queue, Log oder HTTP-Antwort.
3. Notiere nicht nur, dass es funktioniert, sondern warum.

Varianten:
- Fuehre denselben Schritt mit bewusst falscher Konfiguration aus.
- Suche den Fehler mit dem Fehlerkatalog.
- Erstelle einen Screenshot oder eine kurze Notiz fuer spaetere Wiederholung.

Ziel: Restore nicht blind ausfuehren, sondern Ziel pruefen.

Aufgabe: Fuehre die Befehle aus und notiere, welche Komponente beteiligt ist.

kubectl config current-context || true
psql -h localhost -U order_user -d orderdb -c "select current_database();"

Erwartete Beobachtung:
- Zielumgebung ist bewusst gewaehlt.

Loesung / Auswertung:
1. Pruefe zuerst den technischen Status.
2. Vergleiche dann Datenbank, Queue, Log oder HTTP-Antwort.
3. Notiere nicht nur, dass es funktioniert, sondern warum.

Varianten:
- Fuehre denselben Schritt mit bewusst falscher Konfiguration aus.
- Suche den Fehler mit dem Fehlerkatalog.
- Erstelle einen Screenshot oder eine kurze Notiz fuer spaetere Wiederholung.

Ziel: Kustomize/Helm Output ohne Cluster rendern.

Aufgabe: Fuehre die Befehle aus und notiere, welche Komponente beteiligt ist.

kustomize build deployment/kubernetes/overlays/local || true
helm template order-runtime deployment/helm/order-runtime || true

Erwartete Beobachtung:
- Manifest wird generiert oder Fehler ist eindeutig.

Loesung / Auswertung:
1. Pruefe zuerst den technischen Status.
2. Vergleiche dann Datenbank, Queue, Log oder HTTP-Antwort.
3. Notiere nicht nur, dass es funktioniert, sondern warum.

Varianten:
- Fuehre denselben Schritt mit bewusst falscher Konfiguration aus.
- Suche den Fehler mit dem Fehlerkatalog.
- Erstelle einen Screenshot oder eine kurze Notiz fuer spaetere Wiederholung.

Ziel: Einen Betriebsfehler strukturiert bearbeiten.

Aufgabe: Fuehre die Befehle aus und notiere, welche Komponente beteiligt ist.

docker compose stop rabbitmq
curl -X POST http://localhost:8080/api/orders/ORD-INCIDENT/accept
select status,count(*) from outbox.events group by status;

Erwartete Beobachtung:
- Outbox/Relay zeigt Fehler.
- Runbook fuehrt zur Wiederherstellung.

Loesung / Auswertung:
1. Pruefe zuerst den technischen Status.
2. Vergleiche dann Datenbank, Queue, Log oder HTTP-Antwort.
3. Notiere nicht nur, dass es funktioniert, sondern warum.

Varianten:
- Fuehre denselben Schritt mit bewusst falscher Konfiguration aus.
- Suche den Fehler mit dem Fehlerkatalog.
- Erstelle einen Screenshot oder eine kurze Notiz fuer spaetere Wiederholung.