Technologie und Infrastruktur → Docker Compose und Dev-Umgebung

Docker Compose und Dev-Umgebung

1) Warum Compose

• Parität mit dem Verkauf (Bilder, Variablen, Netzwerke) → weniger „funktioniert für mich“.
• Ein schneller Start für Anfänger → „make up“ und in die Schlacht.
• Isolierte Stände pro Entwickler/Filiale → paralleler Betrieb ohne Konflikte.
• Integrationstests an realen Abhängigkeiten.

2) Grundlegende Repository-Struktur

project/
docker/
app/      # Dockerfile, скрипты web/      # Nginx/Traefik конфиги seed/      # сидеры/фикстуры compose.yaml       # общий базовый стек compose.override.yaml   # локальные оверрайды (в.gitignore)
compose.ci.yaml      # для CI
.env.example       # шаблон окружения
Makefile         # удобные цели devcontainer.json     # VS Code Dev Containers (опционально)

• compose. yaml - beschreibt das „Skelett“ (Dienste, Netzwerke, Volumes) das gleiche für dev/CI.
• override - nur lokale Bearbeitungen: Verzeichnis-Mappings, Ports, Debug-Flags.
• .env. example → der Entwickler kopiert in '.env' und ersetzt die Werte.

3) Compose-Rahmen. yaml (Beispiel)

yaml name: project services:
gateway:
image: traefik:v3 command:
- "--providers.docker=true"
- "--entrypoints.web.address=:80"
- "--entrypoints.websecure.address=:443"
- "--certificatesresolvers.dev.acme.tlschallenge=true"
ports: ["80:80", "443:443"]
volumes:
- /var/run/docker.sock:/var/run/docker.sock:ro networks: [edge, core]

api:
build:
context:.
dockerfile: docker/app/Dockerfile target: dev env_file: [.env]
command:./scripts/dev-start.sh volumes:
-./:/app:cached depends_on: [db, redis, kafka]
labels:
- "traefik.http.routers.api.rule=Host(`${API_HOST}`)"
- "traefik.http.services.api.loadbalancer.server.port=8080"
networks: [core]

db:
image: postgres:16 environment:
POSTGRES_USER: ${DB_USER}
POSTGRES_PASSWORD: ${DB_PASS}
POSTGRES_DB: ${DB_NAME}
volumes:
- pgdata:/var/lib/postgresql/data healthcheck: {test: ["CMD-SHELL","pg_isready -U $$POSTGRES_USER"], interval: 5s, timeout: 3s, retries: 20}
networks: [core]

redis:
image: redis:7 command: ["redis-server","--appendonly","yes"]
volumes: [ "redisdata:/data" ]
networks: [core]

kafka:
image: bitnami/kafka:3 environment:
KAFKA_ENABLE_KRAFT: "yes"
KAFKA_CFG_PROCESS_ROLES: "controller,broker"
KAFKA_CFG_NODE_ID: 1
KAFKA_CFG_LISTENERS: PLAINTEXT://:9092
KAFKA_CFG_ADVERTISED_LISTENERS: PLAINTEXT://kafka:9092 networks: [core]

mailhog:
image: mailhog/mailhog ports: ["8025:8025"]
networks: [core]

mock-psp:
image: wiremock/wiremock:3 command: ["--verbose","--global-response-templating"]
volumes: ["./docker/mocks/psp:/home/wiremock"]
labels:
- "traefik.http.routers.mockpsp.rule=Host(`${PSP_HOST}`)"
networks: [core]

volumes:
pgdata: {}
redisdata: {}

networks:
edge: {}
core: {}

• Traefik/NGINX als Gateway: Bringt das Routing-Schema näher an die Produktion.
• Healthcheck und depends_on mit 'condition: service_healthy' (in v3 über waiting-scripts) ist ein geordneter Start.
• Volumes für Persistenz (DB/Cache) und Bind-Mount für Code (Hot-Reload).

4) Profile und mehrere Dateien

Profiles ('profiles: [dev, ci, extras]') aktivieren/eliminieren Dienste ('docker compose --profile extras up -d').

• `docker compose -f compose. yaml -f compose. dev. yaml up'- Zusammenführen von Konfigurationen.

• `compose. yaml 'ist die Basis.
• `compose. dev. yaml'- bind-mounts, debag, ficheflags.
• `compose. extras. yaml'- instrumental (Grafana, pgAdmin, Kafdrop).
• `compose. ci. yaml'- „Kopf ohne Grafik“, ohne bind-mounts.

5) Variablen, Geheimnisse und Einstellungen

.env ist die gemeinsame Quelle von Variablen: Hosts, Credits von Test-DBs, Flags.

• lokale Dummy-Geheimnisse (Stub-Schlüssel),
• Integration mit skinny-Vault/SOPS für besonders sensible.
• Das Prinzip: minimal benötigte Daten. PAN/PII - Token/Fiktionen.

6) Baugruppen und Geschwindigkeit

6. 1 Multi-stage + BuildKit

Dockerfile mit den Zielen 'base', 'dev', 'prod'; gemeinsamer Cache-Layer für Abhängigkeiten.
BuildKit aktivieren: 'DOCKER _ BUILDKIT = 1' (oder in config).
Caching: '--mount = type = cache, target =/root/.cache/...' für pip/npm/maven.

6. 2 Schneller Zyklus

Bind-mount кода + hot-reload (nodemon, uvicorn --reload, Spring Devtools).
Separates Dev-Target mit Montage nur des Gewünschten.
Makefile цели: `make up`, `make down`, `make logs`, `make rebuild`, `make seed`.

make
ENV?= dev up:
docker compose --profile $(ENV) up -d down:
docker compose down -v logs:
docker compose logs -f --tail=200 rebuild:
DOCKER_BUILDKIT=1 docker compose build --pull --no-cache api seed:
docker compose run --rm api./scripts/seed.sh migrate:
docker compose run --rm api./scripts/migrate.sh test:
docker compose -f compose.yaml -f compose.ci.yaml run --rm api./scripts/test.sh

7) DB, Migration, Siding

Migrationen (Flyway/Liquibase/Alembic/Prisma) werden durch ein Hook-Script nach dem Start von 'db' (Warten auf healthcheck) ausgelöst.
Siding: separater Container 'seed' mit Fikturen; wiederholbar und idempotent.
Daten-Snapshots: Das Volume' pgdata 'kann mit dem Skript' reset-db 'zurückgesetzt/wiederhergestellt werden. sh`.

8) Broker, Caches, CDC

Kafka/Rabbit/Redpanda - wie in der Produktion (minimale Configs).
Redis mit AOF aktiviert für Realismus.
CDC-Konnektoren (optional): Debezium in einem separaten Service für Analytics-Integrationstests.

9) Moki von externen Lieferanten

WireMock/Prism für REST, MockServer für komplexe Szenarien.
Mailhog/SMTP4Dev für Briefe.
Localstack/MinIO für Cloud-Stops und S3-Kompatibilität.
Richtlinie: Alle externen PSPs/KYCs/KMSs sind über einen Mock-Hub für Verträge (OpenAPI) und nicht „online“.

10) Reverse Proxy und TLS

• `api. local. test`, `mockpsp. local. test`.
• TLS: mkcert für die Ausstellung eines vertrauenswürdigen lokalen Zertifikats zum Testen von HSTS/Secure-Cookies.
• Aktivieren Sie Sticky-Sitzungen nur für Fälle, in denen es wirklich wichtig ist.

11) Entwicklungsprofile: Node/Python/Java

Node: mount 'node _ modules' als Cache (Volume), um die Installation zu beschleunigen; 'CHOKIDAR _ USEPOLLING = 1' unter Windows/WSL.
Python: `pip cache` как volume, `watchfiles`/`uvicorn --reload`.
Java: JRebel/Devtools, 'mvn -T 1C -o' + -Ebene mit Abhängigkeiten.

12) Tests und Qualität

Wir fahren Integrationstests innerhalb des Compose-Netzwerks: 'docker compose run test'.
Testcontainer (für JVM/Node/Python/.NET) ist eine Choi-Option für Unit-Integration ohne Full-Stack.
Vertragstests mit dem Mock-Hub → Gate in CI.
Linters/Pre-commit: Starten Sie in einem Container für Wiederholbarkeit.

13) Devcontainer und „IDE-as-Code“

`devcontainer. json 'erfasst das Image von razrab (CLI, SDK, linters), mountet das Projekt, jagt' postCreateCommand'.
Profit: die gleichen Werkzeuge, nicht „verstopfen“ den Host, neue Maschine - bereit in Minuten.

14) Sicherheit in dev

Ohne root in den App-Images; 'readOnlyRootFilesystem' wann immer möglich.
Keine Kampfschlüssel/Geheimnisse, auch nicht vorübergehend.
Logs - ohne PII/PAN; Maskierung auf Formatterebene.
Trennung von Ports und Netzwerken: externer Zugriff nur über Gateway.

15) FinOps/Leistung in Lokalen

Ressourcen begrenzen: 'deploy. resources. limits'(Compose liest teilweise, hilft aber bei der Disziplin).
Reduzieren Sie das Fan-Out (weniger Standarddienste; extras - Profile).
BuildKit-Cache und Volume-Caches für Paketmanager.

16) CI с Compose

Verwenden Sie die gleichen 'compose. yaml` + `compose. ci. yaml 'ohne bind-mounts.
Abhängigkeitscaches sind wie attachable volumes zwischen Jobs/Layern.
Parallele Jobs: 'name:' in Compose ist anders (oder Präfix durch Zweig), damit die Stände nicht kollidieren.

17) Trablschuting

'docker compose ps '/' logs -f '/' exec' - grundlegende Diagnose.
Überprüfen Sie DNS im Compose-Netzwerk (Service by Name).
Wenn bind-mount auf macOS/Windows „verlangsamt“ -': cached '/': delegated 'oder Mutagen/virtiofs.
Healthcheck ist „grün“, aber der Service ist „tot“: Überprüfen Sie die „Bereitschaft“ Ihrer Apps und die Reihenfolge der Migrationen.

18) Checkliste Umsetzung

1. Der Basis-Stack (Gateway, api, db, cache, queue) in compose. yaml.
2. Lokale Bearbeitungen sind in override (v. gitignore).
3..env. Beispiel vollständig und aktuell; 'make bootstrap' kopiert es in '.env'.
4. Healthchecks und DB/Migrations-Warteskript.
5. WireMock/Localstack/MinIO für externe Anbieter.
6. Siding und Migrationen als Cmdlets' make seed/migrate'.
7. BuildKit + multi-stage, Abhängigkeitscaches.
8. Devcontainers/Makefile für einen schnellen Start.
9. 'extras' Profile für Werkzeuge (Grafana/pgAdmin/Kafdrop).
10. CI verwendet die gleiche compose (+ ci-override).

19) Anti-Muster

„Monster-compose“ auf 40 Dienste, immer läuft: Profile einschalten.
Hart genagelte Ports, die zwischen Entwicklern in Konflikt geraten.
Geheimnisse/Schlüssel in Git oder '.env. example`.
Abhängigkeit vom „Internet“ für Tests (echte PSP/KYC).
Mangel an Healthcheck/Erwartung - Rennen von Migrationen und Starts.
Fehlende Siding → flaky Integrationstests.

20) Das Ergebnis

Compose ist der Motor der Entwicklungsgeschwindigkeit: Eine Datei beschreibt Ihre Servicewelt und Profile/Overrides geben Flexibilität. Halten Sie die Parität mit dem Verkauf aufrecht, automatisieren Sie Siding und Migrationen, halten Sie Moki und TLS „wie im Kampf“, beschleunigen Sie BuildKit-Builds - und Sie erhalten eine lokale Umgebung, in der es bequem ist, zu arbeiten, einfach zu testen und iGaming-/Fintech-Verkaufsszenarien sicher zu reproduzieren.