Tecnología e Infraestructura → Docker Compose y entorno Dev

Docker Compose y entorno Dev

1) Por qué Compose

• La paridad con la venta (imágenes, variables, redes) → menos «funciona para mí».
• Inicio rápido para los principiantes → 'make up' y en la batalla.
• Stands aislados por desarrollador/rama → trabajo paralelo sin conflictos.
• Pruebas de integración en dependencias reales.

2) Estructura básica del repositorio

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 - describe el «esqueleto» (servicios, redes, volúmenes) igual para dev/CI.
• override - sólo ediciones locales: mappings de directorios, puertos, banderas debug.
• .env. ejemplo → el desarrollador copia en '.env' y sustituye los valores.

3) Marco compuesto. yaml (ejemplo)

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 como gateway: acerca el circuito de routing a la venta.
• Healthcheck y depends_on con 'condition: service_healthy' (en v3 a través de scripts de espera) es un inicio ordenado.
• Volume para persistencia (DB/caché) y bind-mount para código (hot-reload).

4) Perfiles y varios archivos

Los perfiles ('perfiles: [dev, ci, extras]') incluyen/excluyen servicios ('docker compose --profile extras up -d').

• `docker compose -f compose. yaml -f compose. dev. yaml up '- fusión de configuraciones.

• `compose. yaml '- básico.
• `compose. dev. yaml' - bind-mounts, debag, fichflagi.
• `compose. extras. yaml '- instrumental (Grafana, pgAdmin, Kafdrop).
• `compose. ci. yaml '- «cabeza sin gráficos», sin bind-mounts.

5) Variables, secretos y ajustes

.env es una fuente común de variables: hosts, créditos de prueba de DB, banderas.

• secretos dummy locales (claves de enchufe),
• integración con skinny-Vault/SOPS para ser especialmente sensible.
• Principio: los datos mínimos necesarios. PAN/PII - tokens/fixtures.

6) Ensamblaje y velocidad

6. 1 Multi-stage + BuildKit

Dockerfile con objetivos 'base', 'dev', 'prod'; cache-layer compartido para dependencias.
Habilitar BuildKit: 'DOCKER _ BUILDKIT = 1' (o en configuración).
Almacenamiento en caché: '--mount = type = cache, target =/root/.cache/...' para pip/npm/maven.

6. 2 Ciclo rápido

Bind-mount кода + hot-reload (nodemon, uvicorn --reload, Spring Devtools).
Destino dev separado con el conjunto sólo deseado.
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, migración, sentado

Las migraciones (Flyway/Liquibase/Alembic/Prisma) se ejecutan mediante un script de gancho después del inicio de 'db' (espera healthcheck).
Siding: contenedor separado 'seed' con fixtures; repetible e idempotente.
Snapshots de datos: el volumen 'pgdata' se puede restablecer/restaurar con el script' reset-db. sh`.

8) Corredores, cachés, CDC

Kafka/Rabbit/Redpanda - como en la venta (confecciones mínimas).
Redis con AOF incluido para el realismo.
Conectores CDC (opcional): Debezium en un servicio separado para pruebas de análisis de integración.

9) Proveedores externos de Moki

WireMock/Prism para NAT, MockServer para scripts complejos.
Mailhog/SMTP4Dev para las cartas.
Localstack/MinIO para la compatibilidad en la nube y S3.
Política: Todos los PSP/KYC/KMS externos - a través del moc-hub por contrato (OpenAPI), no «en línea».

10) Proxy inverso y TLS

• `api. local. test`, `mockpsp. local. test`.
• TLS: mkcert para emitir un certificado local de confianza para probar las cookies HSTS/Secure.
• Las sesiones de sticky sólo se incluyen para casos en los que sea importante.

11) Perfiles del desarrollador: Node/Python/Java

Node: mount 'node _ modules' como caché (volumen) para acelerar el install; 'CHOKIDAR _ USEPOLLING = 1' en Windows/WSL.
Python: `pip cache` как volume, `watchfiles`/`uvicorn --reload`.
Java: JRebel/Devtools, 'mvn -T 1C -o' + capa con dependencias.

12) Pruebas y calidad

Las pruebas de integración corren dentro de la red Compose: 'docker compose run test'.
Testcontainers (para JVM/Node/Python/.NET) es una opción de coros para la integración de unidades sin una pila completa.
Pruebas de contrato con moc hub → gate en CI.
Linters/Pre-commit: ejecutar en el contenedor para la repetibilidad.

13) Devcontainers y «IDE-as-code»

`devcontainer. json 'fija la imagen del razrab (CLI, SDK, linters), monta el proyecto, ejecuta el' postCreateCommand '.
Profit: las mismas herramientas, no «obstruimos» el host, la nueva máquina está lista en minutos.

14) Seguridad en dev

Sin root en imágenes de aplicaciones; 'readOnlyRootFilesystem' siempre que sea posible.
Sin llaves de combate/secretos, incluso temporalmente.
Registros - sin PII/PAN; enmascaramiento a nivel de formateador.
Segregación de puertos y redes: acceso externo sólo a través de gateway.

15) FinOps/rendimiento en el local

Limite los recursos: 'deploy. resources. limits '(Compose lee parcialmente, pero ayuda a la disciplina).
Reduzca el fan out (menos servicios predeterminados; extras - perfiles).
Caché BuildKit y caché de volumen para administradores de paquetes.

16) CI с Compose

Use el mismo 'compose. yaml` + `compose. ci. yaml 'sin bind-mounts.
Cachés de dependencia: como volums attachables entre jobs/capas.
Jobs paralelos: 'name:' en Compose diferente (o prefijo por rama) para que los stands no estén en conflicto.

17) Trablshuting

'docker compose ps '/' logs -f '/' exec' es un diagnóstico básico.
Compruebe el DNS en la red Compose (servicio por nombre).
Si bind-mount «frena» en macOS/Windows - ': cached '/': delegated' o Mutagen/virtiofs.
Healthcheck es «verde», pero el servicio está «muerto»: comprueba la 'readiness' de tus apps y el orden de las migraciones.

18) Lista de verificación de implementación

1. Pila básica (gateway, api, db, cache, queue) en compose. yaml.
2. Ediciones locales - en override (v.gitignore).
3..env. ejemplo completo y actual; 'make bootstrap' lo copia en '.env'.
4. Healthchecks y script de espera DB/migraciones.
5. WireMock/Localstack/MinIO para proveedores externos.
6. Sentarse y migrar como cmdlets 'make seed/migrate'.
7. BuildKit + multi-stage, cachés de dependencias.
8. Devcontainers/Makefile para un inicio rápido.
9. Perfiles 'extras' para herramientas (Grafana/pgAdmin/Kafdrop).
10. El CI utiliza el mismo compose (+ ci-override).

19) Anti-patrones

«Monster-compose» en 40 servicios, siempre en ejecución: incluye perfiles.
Puertos rígidamente clavados, en conflicto entre desarrolladores.
Secretos/claves en Git o '.env. example`.
Dependencia de «Internet» para pruebas (PSP/KYC reales).
La ausencia de healthcheck/espera es una carrera de migraciones y lanzamientos.
Sin sentarse → pruebas de integración flaky.

20) Resultado

Compose es un motor de velocidad de desarrollo: un archivo describe su mundo de servicios y los perfiles/sobrecargas dan flexibilidad. Mantenga la paridad con la venta, automatice el side and migration, mantenga el moki y el TLS «como en combate», acelere los ensambles BuildKit 'om, y obtendrá un entorno local en el que funcione cómodamente, sea fácil de probar y reproduzca con seguridad los scripts de venta iGaming/fintech.