> ## Content Index > Fetch the complete content index at: https://blog.ifirestone.dev/llms.txt > Use this file to discover other available public pages before exploring further. # Una caja de herramientas de desarrollo local con Docker Compose: bases de datos, emuladores de nube y mocks - URL: https://blog.ifirestone.dev/una-caja-de-herramientas-de-desarrollo-local-con-docker-compose-bases-de-datos-emuladores-de-nube-y-mocks/ - Published: 2026-10-23T16:35:01.000Z - Updated: 2026-10-23T16:37:40.000Z - Description: 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. - Author: Ivan Firestone - Tags: docker, devops, testing, #spanish > 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](https://github.com/ifirestone/dev-tools?ref=blog.ifirestone.dev), 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](https://wiremock.org/?ref=blog.ifirestone.dev) 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 ```bash git clone 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: ```bash docker compose -f /docker-compose.yml down # conserva los datos docker compose -f /docker-compose.yml down -v # también borra los datos ``` Un ejemplo con el emulador de AWS: ```bash export AWS_ACCESS_KEY_ID=test export AWS_SECRET_ACCESS_KEY=test export AWS_DEFAULT_REGION=us-east-1 aws --endpoint-url 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.