Docker - El Ecosistema Startup

Docker es una plataforma de contenedorización que permite empaquetar una aplicación junto con todas sus dependencias (librerías, configuraciones, runtime) en un contenedor ligero y portable. Este contenedor puede ejecutarse de manera consistente en cualquier entorno: tu laptop, un servidor de staging, producción en AWS, o la máquina de otro developer, eliminando el clásico problema de «en mi máquina funciona».

En el ecosistema de desarrollo latinoamericano, Docker ha pasado de ser una tecnología de nicho a convertirse en el estándar de facto para desarrollo y despliegue. Según Stack Overflow Survey 2023, el 54% de los developers profesionales usan Docker regularmente, y esa cifra sube a 78% en empresas con más de 100 empleados. En startups tech de LATAM como Rappi (Colombia), Nubank (Brasil) y Mercado Libre (Argentina), Docker es fundamental para manejar arquitecturas de microservicios con cientos de servicios corriendo simultáneamente.

Este concepto va más allá de simplemente «virtualizar». Docker usa contenedores que comparten el kernel del sistema operativo host, haciéndolos muchísimo más ligeros que las máquinas virtuales tradicionales. Mientras que levantar una VM puede tomar 2-5 minutos y consumir 2GB+ de RAM, un contenedor Docker arranca en <1 segundo y consume 10-50MB de memoria. Esta diferencia es crítica cuando necesitas correr 20 microservicios en tu laptop para desarrollo local.

Entender qué es Docker y cómo usarlo es crítico si estás escalando tu aplicación a microservicios, si tu equipo sufre inconsistencias entre desarrollo y producción, o si pasas horas configurando ambientes nuevos cada vez que entra un developer.

Origen del Término

Docker fue lanzado en 2013 por Solomon Hykes como un proyecto open-source de la empresa dotCloud (luego renombrada a Docker Inc.). Hykes se inspiró en contenedores Linux (tecnología que existía desde 2008) pero los hizo accesibles para developers mediante una API simple y un ecosistema de imágenes pre-construidas (Docker Hub).

El nombre «Docker» viene de «dock worker» (trabajador portuario en inglés), haciendo analogía con contenedores de carga marítimos. Así como un contenedor de barco puede transportar cualquier cosa (autos, ropa, electrónica) de manera estandarizada sin importar el destino, un contenedor Docker puede ejecutar cualquier aplicación (Node.js, Python, Java) de manera consistente sin importar dónde corre.

Antes de Docker, configurar un ambiente de desarrollo requería documentos de 10 páginas con comandos como «instala Node 14.5.2, luego PostgreSQL 12, configura estas variables de entorno…». Si fallaba algo, debuggear tomaba horas. Docker resolvió esto con un solo comando: docker-compose up.

La adopción fue explosiva. En 2014, Google reveló que corría 2 mil millones de contenedores por semana usando su propia tecnología (que luego evolucionó a Kubernetes). Microsoft, históricamente enemigo de Linux, agregó soporte nativo de Docker en Windows en 2016. Amazon lanzó ECS (Elastic Container Service) en 2015 para correr contenedores Docker a escala masiva.

En América Latina, Docker llegó con fuerza entre 2015-2017 cuando startups comenzaron a migrar de monolitos a microservicios. Empresas como MercadoLibre que tenían aplicaciones gigantes corriendo en servidores físicos, comenzaron a contenedorizar servicios individuales (búsqueda, pagos, logística) para poder escalarlos independientemente. Rappi construyó toda su arquitectura desde el inicio con Docker + Kubernetes, permitiéndoles escalar de Colombia a 9 países en 5 años.

Hoy en día, Docker es tan ubicuo que es raro encontrar una startup tech que NO lo use. Incluso empresas tradicionales latinoamericanas están contenedorizando aplicaciones legacy para modernizar su infraestructura.

Docker vs Máquinas Virtuales

Diferencias Fundamentales

Máquina Virtual (VM):

Virtualiza hardware completo (CPU, memoria, disco)
Incluye un sistema operativo completo (Linux, Windows)
Requiere hypervisor (VMware, VirtualBox, Hyper-V)
Pesada: 2-10GB por VM
Arranque lento: 30 segundos – 5 minutos
Aislamiento fuerte (kernel separado por VM)

Contenedor Docker:

Virtualiza solo el espacio de usuario (apps y dependencias)
Comparte el kernel del sistema operativo host
Corre sobre Docker Engine
Ligero: 10-500MB por contenedor
Arranque rápido: <1 segundo
Aislamiento mediante namespaces y cgroups

Comparación Visual

Aspecto	VM	Docker
Tamaño	2-10GB	10-500MB
Arranque	30s – 5min	<1s
Uso de Memoria	2GB+ por VM	10-50MB por contenedor
Portabilidad	Difícil (dependiente de hypervisor)	Alta (corre en cualquier host con Docker)
Densidad	5-10 VMs por servidor físico	50-100 contenedores por servidor
Casos de Uso	Aislar sistemas operativos diferentes	Aislar aplicaciones con mismo kernel

Cuándo Usar Cada Una

Usa VMs cuando:

Necesitas correr sistemas operativos diferentes (Windows + Linux en un mismo servidor)
Requieres aislamiento de seguridad fuerte (multi-tenant con datos sensibles)
Aplicaciones legacy que no se pueden contenedorizar

Ejemplo: Un hospital que corre sistema contable en Windows Server 2012 + sistema de historias clínicas en Linux. Cada uno en su VM para aislamiento total.

Usa Docker cuando:

Desarrollas microservicios (cada servicio en su contenedor)
Quieres ambientes consistentes entre dev, staging, producción
Necesitas escalar horizontalmente (10 instancias del mismo servicio)

Ejemplo: Una startup fintech con 15 microservicios (API de usuarios, API de pagos, worker de emails, etc.). Cada uno en su contenedor Docker, fácil de escalar independientemente.

Híbrido (lo más común): Muchas empresas usan ambos: VMs para aislar clientes/proyectos, y dentro de cada VM corren contenedores Docker para los servicios.

Ejemplo real: MercadoLibre corre Kubernetes (orquestador de contenedores) sobre VMs de AWS. Cada VM tiene 50-100 contenedores corriendo.

Casos de Uso de Docker

1. Desarrollo Local Consistente

Problema que resuelve: «En mi máquina funciona» pero en producción falla porque tienen versiones diferentes de Node/Python/PostgreSQL.

Solución con Docker:

## docker-compose.yml
version: '3'
services:
  api:
    image: node:18
    volumes:

      - ./api:/app
    ports:

      - "3000:3000"

  db:
    image: postgres:15
    environment:
      POSTGRES_PASSWORD: devpass

Un developer nuevo ejecuta docker-compose up y en 30 segundos tiene el stack completo corriendo: API + base de datos, mismo ambiente que en producción.

Impacto real: En una startup que asesoré en Chile, pasar de setup manual a Docker redujo el tiempo de onboarding de nuevos developers de 2 días a 20 minutos. Además eliminó el 80% de los «funciona en mi máquina pero no en staging» bugs.

2. Ambientes de Staging Idénticos a Producción

Problema que resuelve: Producción tiene plugins/configuraciones que staging no tiene. Bugs aparecen solo en producción.

Solución con Docker: Usas la MISMA imagen Docker en staging y producción. La única diferencia son variables de entorno (database URLs, API keys).

## Dockerfile
FROM node:18
COPY package*.json ./
RUN npm install
COPY . .
CMD ["npm", "start"]

Esta imagen se construye una vez en CI/CD y se usa en todos los ambientes. Garantía de que staging y producción son idénticos.

Ejemplo real: Nubank despliega la misma imagen Docker a 20+ ambientes (dev, staging, prod-canary, prod-br, prod-mx, etc.). Si funciona en staging, funciona en prod.

3. Microservicios Escalables Independientemente

Problema que resuelve: Tu monolito tiene un componente (ej: procesamiento de imágenes) que necesita 10x más recursos que el resto. Pero al escalar, escalas TODO el monolito innecesariamente.

Solución con Docker: Cada microservicio en su propio contenedor. El servicio de imágenes corre en 10 contenedores (high CPU), mientras que el servicio de autenticación corre en 2 contenedores (low traffic).

Arquitectura típica:

[API Gateway] ← balanceo de carga
    ├── [Servicio Usuarios] x2 contenedores
    ├── [Servicio Pagos] x5 contenedores (crítico)
    ├── [Servicio Imágenes] x10 contenedores (CPU intensivo)
    └── [Servicio Emails] x1 contenedor (bajo tráfico)

Ejemplo real: Rappi tiene 200+ microservicios corriendo en contenedores Docker. El servicio de tracking de repartidores (tiempo real, alta carga) escala a 100+ contenedores, mientras que el servicio de facturación (batch, diario) corre en 2 contenedores.

4. CI/CD y Testing Automatizado

Problema que resuelve: Tests funcionan en laptop del developer pero fallan en CI porque las versiones de dependencias difieren.

Solución con Docker: El pipeline de CI/CD ejecuta tests dentro de contenedores Docker, garantizando mismo ambiente que desarrollo.

## .github/workflows/test.yml
jobs:
  test:
    runs-on: ubuntu-latest
    container:
      image: node:18
    steps:

      - run: npm install

      - run: npm test

Beneficio adicional: Puedes correr tests de múltiples versiones en paralelo (Node 16, 18, 20) para asegurar compatibilidad.

5. Despliegues Blue-Green y Canary

Problema que resuelve: Desplegar nueva versión a producción es riesgoso. Si tiene un bug crítico, downtime afecta a todos.

Solución con Docker: Despliegas nueva versión (imagen Docker nueva) solo al 5% del tráfico. Si las métricas se ven bien, escalas a 100%.

Flujo canary:

Tráfico 100% → version-1 (imagen Docker api:v1)
Despliegas version-2 (api:v2) al 5% tráfico
Monitoreas errores, latencia, conversión
Si OK → 10% → 25% → 50% → 100%
Si falla → Rollback instantáneo a v1

Ejemplo real: Netflix hace canary deployments de TODO. Si un cambio en su algoritmo de recomendaciones reduce el engagement 0.1%, automáticamente hace rollback.

Docker Compose: Multi-Contenedor Simplificado

Docker Compose permite definir aplicaciones multi-contenedor (API + DB + Redis + Worker) en un solo archivo YAML.

Ejemplo completo de stack típico:

## docker-compose.yml
version: '3.8'

services:
  # API Backend (Node.js)
  api:
    build: ./api
    ports:

      - "3000:3000"
    environment:
      DATABASE_URL: postgres://user:pass@db:5432/myapp
      REDIS_URL: redis://cache:6379
    depends_on:

      - db

      - cache
    restart: unless-stopped

  # Base de Datos (PostgreSQL)
  db:
    image: postgres:15
    volumes:

      - postgres_data:/var/lib/postgresql/data
    environment:
      POSTGRES_USER: user
      POSTGRES_PASSWORD: pass
      POSTGRES_DB: myapp
    ports:

      - "5432:5432"

  # Cache (Redis)
  cache:
    image: redis:7-alpine
    ports:

      - "6379:6379"

  # Worker Background Jobs (Python)
  worker:
    build: ./worker
    environment:
      DATABASE_URL: postgres://user:pass@db:5432/myapp
      REDIS_URL: redis://cache:6379
    depends_on:

      - db

      - cache

volumes:
  postgres_data:

Comandos útiles:

## Levantar todo el stack
docker-compose up -d

## Ver logs en tiempo real
docker-compose logs -f

## Reiniciar solo el servicio API
docker-compose restart api

## Ejecutar comando dentro del contenedor
docker-compose exec api npm run migrate

## Apagar todo
docker-compose down

Ventajas:

✅ Define infraestructura completa en 1 archivo
✅ Servicios se descubren entre sí automáticamente (usa nombres de servicio como hostnames)
✅ Networking y volúmenes gestionados automáticamente
✅ Perfecto para desarrollo local y ambientes de staging

Limitaciones:

❌ No escala horizontalmente (no es para producción multi-servidor)
❌ No tiene auto-recovery (si contenedor muere, no se reinicia automáticamente a menos que uses restart policies)
❌ Para producción con alta disponibilidad, usa Kubernetes o Docker Swarm

Imágenes y Docker Registry

Imágenes Docker

Una imagen Docker es una plantilla read-only que contiene tu aplicación + dependencias. Es como un «snapshot» de tu aplicación que puede ser ejecutado en cualquier lugar.

Anatomía de una imagen:

## Dockerfile
FROM node:18-alpine          # Imagen base (Node.js 18 en Alpine Linux)
WORKDIR /app                 # Directorio de trabajo
COPY package*.json ./        # Copiar archivos de dependencias
RUN npm ci --only=production # Instalar dependencias
COPY . .                     # Copiar código fuente
EXPOSE 3000                  # Puerto que expone la app
CMD ["node", "server.js"]    # Comando para iniciar la app

Build de la imagen:

docker build -t miapp:v1.0 .

Capas (Layers): Docker construye imágenes en capas. Cada línea del Dockerfile crea una capa. Si una capa no cambia, Docker la reutiliza (cache), haciendo builds subsecuentes súper rápidos.

Ejemplo práctico:

CAMBIO: Editas server.js
├── FROM node:18-alpine     ← Cache (no cambió)
├── COPY package*.json      ← Cache (no cambió)
├── RUN npm install         ← Cache (no cambió)
├── COPY . .                ← Rebuild (server.js cambió)
└── CMD ["node", ...]       ← Rebuild

Resultado: Build tarda 5 segundos en lugar de 2 minutos.

Docker Registry (Repositorio de Imágenes)

Un registry es donde guardas y compartes imágenes Docker.

Opciones populares:

1. Docker Hub (Público/Privado)

Gratis: 1 repo privado + ∞ repos públicos
Paid ($5/mes): Repos privados ilimitados
Ventaja: Más grande comunidad, millones de imágenes públicas
Desventaja: Rate limits (100 pulls/6h en tier gratis)

Ejemplo de uso:

## Login
docker login

## Push imagen
docker tag miapp:v1.0 tusername/miapp:v1.0
docker push tusername/miapp:v1.0

## Pull imagen
docker pull tusername/miapp:v1.0

2. GitHub Container Registry (GHCR)

Gratis: Repos públicos + privados ilimitados
Integrado con GitHub Actions (perfecto para CI/CD)
Ventaja: No hay rate limits agresivos
Desventaja: Menos imágenes públicas que Docker Hub

Ejemplo de CI/CD con GHCR:

## .github/workflows/deploy.yml

- name: Build y Push
  run: |
    echo ${{ secrets.GITHUB_TOKEN }} | docker login ghcr.io -u ${{ github.actor }} --password-stdin
    docker build -t ghcr.io/${{ github.repository }}:${{ github.sha }} .
    docker push ghcr.io/${{ github.repository }}:${{ github.sha }}

3. AWS ECR (Elastic Container Registry)

Integrado con AWS ECS/EKS
Pago por uso (~$0.10/GB/mes almacenamiento)
Ventaja: Baja latencia si tu infra está en AWS
Desventaja: Vendor lock-in

4. Self-Hosted Registry

Corres tu propio registry con Docker Registry (open source)
Ventaja: Control total, sin rate limits
Desventaja: Tú gestionas disponibilidad, backups, seguridad

Setup básico:

docker run -d -p 5000:5000 --name registry registry:2
docker tag miapp:v1.0 localhost:5000/miapp:v1.0
docker push localhost:5000/miapp:v1.0

Mejores Prácticas para Imágenes

1. Usa imágenes Alpine cuando sea posible:

node:18 → 900MB
node:18-alpine → 110MB Resultado: Builds 8x más rápidos, menor uso de disco

2. Aprovecha cache de capas:

## ❌ MAL (invalida cache en cada cambio de código)
COPY . .
RUN npm install

## ✅ BIEN (cache de dependencies se preserva)
COPY package*.json ./
RUN npm install
COPY . .

3. Multi-stage builds para production:

## Stage 1: Build
FROM node:18 AS builder
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build

## Stage 2: Production (solo runtime + artifacts)
FROM node:18-alpine
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY package*.json ./
RUN npm ci --only=production
CMD ["node", "dist/server.js"]

Resultado: Imagen final sin devDependencies ni archivos source → 60% más pequeña

4. No correr como root:

RUN addgroup -S appuser && adduser -S appuser -G appuser
USER appuser
CMD ["node", "server.js"]

Razón: Seguridad. Si alguien explota vulnerabilidad en tu app, no tiene permisos root.

Casos Reales en Latinoamérica

Caso 1: Rappi (Colombia) – Microservicios desde Día 1

Contexto: Fundada en 2015, Rappi necesitaba escalar rápido a múltiples ciudades y países. Monolito no era opción.

Cómo usan Docker:

Arquitectura: 200+ microservicios en contenedores Docker
Orchestration: Kubernetes en GCP
Despliegues: 50+ veces/día usando CI/CD con GitLab + Helm
Escalamiento: Auto-scaling basado en carga (Black Friday escalan a 1,000+ contenedores)

Resultados:

Pasaron de 1 ciudad (Bogotá) a 9 países en 5 años
Manejan 500K+ pedidos/día en picos
Developers pueden desplegar features independientemente sin coordinación

Lección clave: Docker + Kubernetes les permitió escalar equipos (300+ engineers) sin que se bloquearan entre sí. Cada squad (Pagos, Logística, Marketplace) despliega su servicio independientemente.

Caso 2: Startup Fintech (Chile) – De Heroku a Docker

Contexto: Startup de 8 personas con API en Ruby on Rails + workers en Python. Corrían en Heroku (US$500/mes) pero creciendo costos a US$2K/mes.

Migración a Docker:

Paso 1: Dockerizaron app Rails (1 día)
Paso 2: Migraron a DigitalOcean App Platform (US$120/mes)
Paso 3: Agregaron Redis y PostgreSQL como containers
Paso 4: CI/CD con GitHub Actions (gratis)

Resultados:

Redujeron costos de US$2K → US$150/mes (93% ahorro)
Deployment time de 10min → 3min
Developers pueden replicar producción localmente con docker-compose up

Lección clave: No necesitas Kubernetes para beneficiarte de Docker. Para startups pequeñas, Docker + PaaS simple (DigitalOcean, Railway) es suficiente y mucho más barato que Heroku.

Caso 3: Mercado Libre (Argentina) – Migración Legacy

Contexto: En 2013, MercadoLibre tenía un monolito Java gigante corriendo en servidores físicos. Escalar era costoso y lento.

Proceso de contenedorización:

2014-2016: Comenzaron migrando servicios no-críticos (búsqueda de productos)
2017-2019: Migraron servicios críticos (checkout, pagos) usando patrón Strangler Fig
2020+: 90% de workloads contenedorizados en Kubernetes

Resultados:

Redujeron tiempo de provisión de servidores de 2 semanas → 5 minutos
Costo por transacción bajó 60% (mejor utilización de recursos)
Elasticidad: Durante Hot Sale escalan automáticamente 10x capacity

Lección clave: No necesitas migrar todo de golpe. Patrón Strangler Fig (migrar servicio por servicio) funciona bien para legacy systems.

Errores Comunes al Usar Docker

❌ Error 1: Imágenes Gigantes (>2GB)

Por qué es un error: Imágenes pesadas hacen que builds tarden 10+ minutos, deployments fallen por timeouts, y desperdicias disco/bandwidth.

✅ Mejor enfoque: Usa imágenes Alpine, multi-stage builds, y .dockerignore para excluir node_modules, .git, etc.

## .dockerignore
node_modules
.git
*.md
.env

❌ Error 2: No Usar .dockerignore

Por qué es un error: Al hacer COPY . ., copias TODO (incluyendo node_modules de 500MB, archivos .git, logs). Build context gigante hace que cada build tome minutos.

✅ Mejor enfoque: Crear .dockerignore con archivos innecesarios.

❌ Error 3: Hardcodear Configuración en la Imagen

Por qué es un error: Si hardcodeas DATABASE_URL en el Dockerfile, no puedes usar la misma imagen en dev/staging/prod.

✅ Mejor enfoque: Usa variables de entorno:

## ❌ MAL
ENV DATABASE_URL=postgres://prod-db:5432/myapp

## ✅ BIEN (se pasa en runtime)
CMD ["node", "server.js"]

## En runtime
docker run -e DATABASE_URL=postgres://dev-db:5432/myapp miapp:v1

❌ Error 4: Correr Como Root

Por qué es un error: Si tu app tiene vulnerabilidad y alguien la explota, tiene permisos root sobre el contenedor (y potencialmente el host).

✅ Mejor enfoque: Crear usuario no-root.

❌ Error 5: No Hacer Health Checks

Por qué es un error: Un contenedor puede estar «corriendo» pero la app está crashed. Docker lo reporta como healthy.

✅ Mejor enfoque: Agregar HEALTHCHECK:

HEALTHCHECK --interval=30s --timeout=3s --retries=3 \
  CMD curl -f http://localhost:3000/health || exit 1

Herramientas del Ecosistema Docker

Desarrollo Local:

Docker Desktop (Mac/Windows) – GUI + CLI
Rancher Desktop (alternativa open source)
Orbstack (Mac) – Más rápido que Docker Desktop

Orchestration (Multi-Servidor):

Kubernetes – Estándar de industria, complejo
Docker Swarm – Más simple pero menos features
Nomad (HashiCorp) – Alternativa ligera

CI/CD:

GitHub Actions – GitHub Container Registry integrado
GitLab CI – Docker registry built-in
Jenkins – Flexible pero requiere setup

Seguridad:

Snyk – Escaneo de vulnerabilidades en imágenes
Trivy – Open source, escaneo de security issues
Docker Scout – Análisis de imágenes (built-in Docker)

Monitoreo:

cAdvisor – Métricas de contenedores
Prometheus + Grafana – Stack completo de monitoring
DataDog – APM + infraestructura (paid)

Cómo Empezar con Docker

Si recién estás comenzando:

Instala Docker Desktop (Semana 1)
Descarga: https://docker.com/products/docker-desktop
Tiempo estimado: 15 minutos
Costo: Gratis (uso personal)
Dockeriza Tu Aplicación Actual (Semana 1-2)
Crea Dockerfile básico
Build: docker build -t miapp .
Run: docker run -p 3000:3000 miapp
Tiempo estimado: 2-4 horas
Costo: Gratis
Agrega docker-compose.yml (Semana 2)
Define API + DB + Redis
Test: docker-compose up
Tiempo estimado: 2 horas
Costo: Gratis
Configura CI/CD (Semana 3)
GitHub Actions para build automático
Push imagen a GHCR
Tiempo estimado: 4 horas
Costo: Gratis
Despliega a Producción (Semana 4)
DigitalOcean App Platform o Railway
Conecta GitHub repo
Auto-deploy en cada push
Costo: US$12-25/mes

Recursos útiles:

Curso: Docker Mastery (Udemy, US$15)
Playground: https://labs.play-with-docker.com (gratis, browser-based)
Documentación oficial: https://docs.docker.com
Comunidad: Cagala – Aprende, Repite

Preguntas Frecuentes

¿Docker es solo para aplicaciones web? No. Puedes dockerizar: APIs, workers background, scripts batch, herramientas CLI, bases de datos, data pipelines, modelos de ML. Si corre en Linux, puede dockerizarse.

¿Necesito Linux para usar Docker? No. Docker Desktop funciona en Mac y Windows usando virtualización. Aunque técnicamente corre una VM Linux ligera en background, como user no notas diferencia.

¿Docker es gratis? Sí para uso personal y small teams. Docker Desktop es gratis para empresas <250 empleados. Docker Hub tier gratis tiene 1 repo privado. Alternativas 100% open source: Podman, containerd.

¿Cuánta memoria necesita Docker? Docker Engine usa ~100-200MB de RAM. Los contenedores en sí usan lo que tu app necesita (típicamente 50-500MB cada uno). En una laptop con 8GB RAM puedes correr 10-20 contenedores cómodamente.

¿Puedo correr Windows containers? Sí, pero es nicho. El 95% de contenedores son Linux. Windows containers existen pero tienen limitaciones (solo corren en hosts Windows Server).

Términos Relacionados

Contenedor – Instancia corriendo de una imagen Docker
Docker Compose – Herramienta para orquestar múltiples contenedores localmente
Kubernetes – Orquestador de contenedores para producción a escala
Registry – Repositorio donde se almacenan imágenes Docker
Docker Hub – Registry público/privado de Docker Inc.
Microservicios – Arquitectura donde cada servicio corre en su contenedor

¿Tienes Dudas sobre Docker?

Si estás implementando Docker en tu startup o tienes dudas sobre cómo dockerizar tu stack específico (Node + PostgreSQL, Python + Redis, etc.), únete a nuestra comunidad de emprendedores técnicos en Cagala – Aprende, Repite. Ahí podrás compartir tu arquitectura actual, recibir feedback sobre mejores prácticas de contenedorización y acceder a ejemplos de docker-compose.yml para casos de uso comunes en startups latinoamericanas.