Una caja de herramientas de desarrollo local con Docker Compose: bases de datos, emuladores de nube y mocks

Cómo armar un entorno local reproducible con Docker Compose para bases de datos, MinIO, emuladores de AWS, Azure y GCP, y WireMock, y qué compromisos implica.

Probar integraciones contra servicios reales es lento, costoso y a veces peligroso. Armé un repositorio, dev-tools, que reúne en un solo lugar todo lo necesario para montar un entorno local y probar sin depender de servicios reales:

• Bases de datos y almacenamiento locales con Docker Compose.
• Emuladores de AWS, Azure y GCP.
• Un servidor de mocks con WireMock.
• Datos de ejemplo en JSON.

Este artículo explica la idea, cómo usarlo y, sobre todo, sus límites.

El problema

Un proyecto típico depende de una base de datos, de almacenamiento de objetos, a veces de servicios en la nube y de APIs de terceros. Sin un entorno local consistente pasan cosas que ya conoces:

• "En mi máquina funciona", porque cada desarrollador instaló versiones distintas.
• Pruebas que dependen del sandbox de otra persona, que se cae o tiene límites de uso.
• Credenciales reales en las máquinas de desarrollo, un riesgo innecesario.
• Incorporaciones lentas: días para dejar el entorno funcionando.

La solución es declarar el entorno como código y levantarlo con un solo comando.

Estructura del repositorio

Cada carpeta es independiente: solo usas la que necesitas.

dev-tools/
├── dev-infra/    # Bases de datos y almacenamiento locales
├── floci/        # Emuladores de nube de AWS / Azure / GCP
├── wiremock/     # Servidor de mocks + colecciones de Postman y Bruno
├── demo/         # Datos de ejemplo en JSON

dev-infra: bases de datos y almacenamiento

Un archivo de Compose con MinIO, PostgreSQL, MySQL, Redis, Oracle, MongoDB y SQL Server, con un usuario de desarrollo creado en cada servicio. Las credenciales viven en un .env local que no se versiona; solo se publica la plantilla .env.example.

floci: emuladores de nube

Emuladores locales de AWS, Azure y GCP con una consola web unificada, basados en las imágenes del proyecto de código abierto Floci. Te permiten desarrollar contra las APIs de S3, DynamoDB, Lambda y otros servicios sin una cuenta real ni costos.

wiremock: mocks de APIs de terceros

Un servidor WireMock con interfaz de administración, stubs de ejemplo y colecciones de Postman y Bruno. Sirve para simular APIs externas: respuestas exitosas, errores, latencias y casos límite difíciles de provocar en el servicio real.

demo: datos de ejemplo

Catálogos JSON bilingües (países, bancos, profesiones…) para usar en seeds, mocks y pruebas.

Cómo usarlo

git clone <https://github.com/ifirestone/dev-tools.git>
cd dev-tools

# Credenciales locales (no se versionan)
cp dev-infra/.env.example dev-infra/.env

# Cada stack es independiente
docker compose -f dev-infra/docker-compose.yml up -d
docker compose -f floci/docker-compose.yml up -d
docker compose -f wiremock/docker-compose.yml up -d

Los tres stacks no comparten puertos, así que pueden correr al mismo tiempo. Para apagar uno:

docker compose -f <carpeta>/docker-compose.yml down      # conserva los datos
docker compose -f <carpeta>/docker-compose.yml down -v   # también borra los datos

Un ejemplo con el emulador de AWS:

export AWS_ACCESS_KEY_ID=test
export AWS_SECRET_ACCESS_KEY=test
export AWS_DEFAULT_REGION=us-east-1

aws --endpoint-url <http://localhost:4566> s3 ls

El código de tu aplicación solo cambia el endpoint. El resto del cliente es el mismo que usarías en la nube real.

Por qué mocks además de emuladores

Los emuladores cubren servicios con una API pública y estable. Para APIs de terceros específicas (un proveedor de pagos, una plataforma corporativa) no existe un emulador, y ahí es donde ayuda WireMock:

• Determinismo: la respuesta siempre es la misma, así que las pruebas no se vuelven frágiles.
• Casos de error a demanda: un 500, un timeout o una respuesta mal formada se simulan en segundos.
• Trabajo en paralelo: puedes desarrollar la integración antes de tener acceso al sandbox del proveedor.
• Contrato explícito: los stubs documentan cómo esperas que responda el tercero.

Compromisos y límites (lo que debes saber)

Una caja de herramientas como esta tiene costos, y conviene decirlos:

• Fidelidad parcial. Un emulador no replica el 100% del comportamiento de la nube real: los permisos, los límites de cuota y los casos límite pueden diferir. Úsalo para desarrollo y pruebas rápidas, no como sustituto de probar contra el servicio real antes de producción.
• Consumo de recursos. Oracle y SQL Server usan mucha memoria. Si tu máquina anda justa, levanta solo los servicios que necesitas.
• Solo para desarrollo local. Nada de esto está pensado para producción ni para exponerse en una red compartida. Las credenciales de ejemplo son públicas.
• Acceso a Docker. Los emuladores montan /var/run/docker.sock para soportar servicios como las funciones serverless, lo que les da control sobre Docker en tu máquina. Quita ese montaje en los entornos donde no lo necesites.
• Imágenes con la etiqueta latest. Varios servicios usan esa etiqueta. Si necesitas reproducibilidad, fija las versiones.
• Apple Silicon. Algunas imágenes solo existen para x86_64 y corren emuladas; verás una advertencia de plataforma, no un error.

Qué haría distinto con más tiempo

• Fijar por defecto las versiones de todas las imágenes.
• Agregar profiles de Compose para levantar combinaciones típicas (por ejemplo, "solo PostgreSQL + MinIO").
• Automatizar health checks para saber cuándo está listo cada servicio.

Conclusión

• Un entorno local declarado como código acelera la incorporación y elimina el "en mi máquina funciona".
• Los emuladores y los mocks permiten probar integraciones sin depender de terceros ni exponer credenciales reales.
• Úsalos para desarrollo, con claridad sobre sus límites de fidelidad y de seguridad.

El repositorio es de código abierto (licencia MIT). Si lo usas y falta algún servicio, las contribuciones son bienvenidas.