Cloud, Docker y DevOps — despliegues rápidos y fiables
Contenerizamos todas las aplicaciones con Docker, las orquestamos con Docker Compose (o Kubernetes en proyectos de empresa), configuramos Caddy como proxy inverso con SSL automático y automatizamos todo el ciclo de despliegue con GitHub Actions: del commit a producción.
Contenedores con Docker y Docker Compose
Cada servicio tiene su propio Dockerfile multietapa: una etapa de compilación que instala las dependencias y compila, y una etapa final mínima (distroless o alpine) que solo contiene los artefactos necesarios. Una imagen típica de Next.js queda por debajo de 150 MB; una de FastAPI, por debajo de 80 MB. Las imágenes se reconstruyen en cada fusión con main y se etiquetan de forma semántica (`v1.2.3` y `latest`).
Docker Compose define toda la pila: frontend, API, base de datos, Redis y worker. Las variables sensibles (contraseña de la base de datos, claves de API, secreto de Stripe) viven en un `.env` excluido de git, nunca fijadas dentro de la imagen. Los health checks de Compose garantizan que las dependencias estén listas antes del arranque (base de datos lista → arranca la API → arranca el frontend).
- Caché de compilación con `--mount=type=cache`: `npm ci` en menos de 30 s en CI
- Orden de capas optimizado: primero las dependencias estables, después el código fuente
- Gestión de secretos con Docker secrets o HashiCorp Vault en proyectos de empresa
- `restart: unless-stopped` y `docker compose up --no-deps` para un despliegue atómico
Caddy: proxy inverso moderno con SSL automático
Caddy 2.8 gestiona SSL/TLS de forma automática mediante ACME (Let's Encrypt o ZeroSSL): ningún certificado caducado, ninguna configuración manual. HTTP/2 y HTTP/3 (QUIC) vienen activados de serie. Las cabeceras de seguridad (HSTS, X-Frame-Options, CSP) se establecen de forma global mediante fragmentos reutilizables. La configuración declarativa del Caddyfile se puede comparar con diff y se versiona en git.
La limitación de peticiones, la compresión gzip/brotli y el registro estructurado en JSON se activan mediante directivas nativas de Caddy, sin módulos de Nginx ni configuraciones complejas de Apache. El acceso a rutas sensibles (`/admin`, `.env`, `.git`) devuelve un 444 (sin respuesta), configurado como fragmento global de seguridad.
- Solo TLS 1.3, con suites de cifrado modernas
- TLS bajo demanda para SaaS multiinquilino con subdominios dinámicos
- Recarga sin caída de servicio: `caddy reload` no interrumpe las conexiones activas
- Registros de Caddy → Loki → Grafana: análisis de tráfico y alertas ante anomalías
CI/CD con GitHub Actions y monitorización
El pipeline de CI se ejecuta en cada PR: lint, comprobación de tipos, pruebas unitarias, construcción de la imagen Docker y análisis de vulnerabilidades (Trivy). Si todo pasa, la imagen se sube al registro y el despliegue en staging se realiza automáticamente. Fusionar en main equivale a un despliegue automático en producción con health check posterior. Si ese health check falla en 60 segundos, se revierte de forma automática.
Monitorizamos con Grafana y Prometheus las métricas de la aplicación (latencia, tasa de errores, tamaño de la cola) y con Loki la agregación de registros. Las alertas se configuran en Slack o correo: tasa de errores superior al 1 %, latencia P95 por encima de 500 ms, disco por encima del 85 %. La monitorización externa de disponibilidad la cubre Better Uptime, con un panel público de SLA disponible a petición.
- Análisis de vulnerabilidades con Trivy sobre las imágenes: los CVE críticos bloquean el despliegue
- Dependabot con fusión automática para actualizaciones de parche (exige CI en verde)
- Copia de seguridad automática de la base de datos en almacenamiento compatible con S3 (nocturna, 30 días de retención)
Ventajas y limitaciones
Ventajas
- Despliegue con reversión automática si falla el health check.
- SSL/TLS automático mediante Caddy: ningún certificado caducado por descuido.
- Entorno reproducible: la misma imagen Docker en desarrollo, staging y producción.
- Monitorización y alertas (Grafana, Loki): los problemas se ven antes que los usuarios.
Limitaciones
- Docker Compose no escala como Kubernetes en entornos de empresa con varios nodos.
- La configuración inicial de CI/CD exige tiempo y experiencia en DevOps.
- Las imágenes y los registros consumen espacio en disco: hace falta limpiarlos periódicamente.
- Una monitorización completa (Prometheus y Grafana) añade servicios que hay que mantener.
Veredicto breve
Docker, Caddy y GitHub Actions son la combinación ideal para desplegar de forma fiable en un VPS o en unos pocos nodos. Con decenas de nodos y autoescalado agresivo, conviene pasar a Kubernetes.
Tabla de especificaciones
| Capacidad | Límite / umbral | Uso habitual | |
|---|---|---|---|
| Orquestación | Docker Compose, pila completa | Un solo nodo; con varios nodos hacen falta Swarm o K8s | VPS, proyectos pequeños y medianos |
| Proxy inverso | Caddy 2.8, HTTP/3, SSL automático | Las reglas muy complejas exigen una configuración extensa | Multidominio, multiinquilino |
| CI/CD | GitHub Actions, despliegue automatizado | Los minutos de CI se facturan más allá del plan gratuito | Del commit a producción de forma automática |
| Coste típico | VPS desde unos 5 €/mes | La monitorización y las copias de seguridad añaden coste | Desde una sola web hasta varias marcas |
Docker Compose frente a Kubernetes
| Criterio | Docker Compose | Kubernetes |
|---|---|---|
| Complejidad de la puesta en marcha | Baja | Alta |
| Escalado multinodo y autoescalado | Limitado (un nodo) | Excelente |
| Adecuado para | VPS, proyectos pequeños y medianos | Grandes flotas, entornos de empresa |
Preguntas frecuentes
¿Por qué Caddy y no Nginx?
Caddy gestiona SSL/TLS automáticamente mediante ACME, activa HTTP/2 y HTTP/3 de serie y tiene una configuración declarativa breve. Nginx necesita certbot y bastante más configuración manual para el mismo resultado.
¿Necesito Kubernetes?
Para la mayoría de las webs, no. Docker Compose en un VPS gestiona con fiabilidad un sitio o unos cuantos servicios. Kubernetes solo compensa a partir de decenas de nodos con autoescalado agresivo.
¿Cómo funciona el despliegue?
GitHub Actions construye una imagen nueva, la arranca junto a la anterior, ejecuta un health check y después conmuta el tráfico. Si el health check falla en 60 segundos, se revierte automáticamente a la versión anterior.
¿Qué monitorización recomendáis?
Grafana y Prometheus para las métricas (latencia, tasa de errores) y Loki para los registros agregados, con alertas en Slack o correo. Para la disponibilidad externa añadimos un servicio independiente como Better Uptime.