Tienes Containers Docker que Nunca Usas — y te Están Costando RAM

Si llevas mas de 3 meses con un servidor de producción, probablemente tienes al menos un container Docker que sigue corriendo sin que nadie lo use. A esto le llamo "container zombie": consume CPU, RAM y atención operacional, pero no genera ningun valor.

Esta semana hice una auditoria de mi servidor principal (VPS con 15 GB RAM) y encontre 5 servicios candidatos a apagar que en conjunto consumian 1.7 GB de RAM completamente desperdiciada.

Aquí esta la metodología que use.

El Problema: Containers que se Quedan Vivos por Inercia

Cuando construyes infra, hay una tendencia natural a "no apagar nada, por si acaso". Un browser agent que instalaste para un proyecto puntual, un VPN que solo sirve para ese agente, un servicio de standby que nunca has necesitado activar.

El problema no es solo el costo de RAM. Es que:

1. Aumentan la superficie de ataque — cada container es un proceso que puede tener vulnerabilidades

2. Generan ruido en logs y alertas — cuando algo falla en un container zombie, produce alertas que distraen de problemas reales

3. Crean deuda mental — cada servicio que no entiendes bien genera incertidumbre al hacer cambios

La Auditoria en 4 Preguntas

Para cada container corriendo en tu servidor, responde estas 4 preguntas:

1. ¿Cuándo fue la última vez que recibio una request real?

Ver logs del container en las ultimas 48 horas
docker logs --since 48h nombre-container 2>&1 | wc -l

Si son menos de 10 lineas en 48 horas, es sospechoso.

2. ¿Quién es su consumidor activo?

No el consumidor original que imaginaste cuando lo creaste — el consumidor hoy. Busca en el codigo de otros servicios si alguien hace requests a ese container.

Buscar referencias al nombre del servicio en el codigo
grep -r "nombre-container" /opt//config /opt//.py /opt//*.env 2>/dev/null

3. ¿Cuántos recursos consume?

docker stats --no-stream --format "table {{.Name}}\t{{.MemUsage}}\t{{.CPUPerc}}" | sort -k2 -hr

4. ¿Cuál es el plan de contingencia si lo apago?

Si la respuesta es "no tengo", probablemente tampoco tienes un plan real de cuando lo necesitarías. Lo cual significa que no lo necesitas urgentemente.

Los 5 Candidatos que Encontre

| Servicio | RAM | CPU | Problema |

|---------|-----|-----|---------|

| browser-agent | 1.29 GB | 5.4% | Sin consumidor activo desde hace semanas |

| vpn-proxy | 112 MB | bajo | Solo existe para servir a browser-agent |

| log-aggregator | 57 MB | bajo | 39 días sin actividad confirmada |

| cron de scraping | bajo | bajo | 15 ejecuciones consecutivas sin resultados |

| base de datos standby | 16 MB | bajo | DR sin plan de failover documentado |

Total: ~1.5 GB RAM + ~5% CPU desperdiciados

En un servidor de 15 GB, eso es el 10% de la RAM total. En uno de 4 GB seria el 37.5%.

Señales de Alerta

• El cron tiene 10+ ejecuciones consecutivas sin resultados: Probablemente la fuente de datos cambio o desaparecio. No tiene sentido seguir corriendo.
• El servicio de VPN solo existe para servir a un agente: Si apagas el agente, apaga el VPN también. Dos containers por el precio de uno.
• "Standby" sin runbook: Un sistema de DR que nunca has probado y no tienes documentado como activar no es DR — es ilusión de DR.

Protocolo de Apagado Seguro

Antes de apagar cualquier container:

1. Confirmar que nadie hace requests activas
docker logs --since 24h nombre-container 2>&1 | grep -v "health\|ping\|heartbeat" | tail -20
2. Verificar que ningun otro container depende de este
docker inspect $(docker ps -q) --format '{{.Name}}: {{range .HostConfig.Links}}{{.}}{{end}}' | grep nombre-container
3. Hacer backup de config/datos si tiene estado
docker exec nombre-container tar czf /tmp/backup-$(date +%F).tar.gz /app/data 2>/dev/null
docker cp nombre-container:/tmp/backup-$(date +%F).tar.gz ~/backups/
4. Apagar sin eliminar (reversible)
docker stop nombre-container
docker update --restart no nombre-container
5. Esperar 48-72 horas antes de eliminar definitivamente

La clave es apagar primero, eliminar despues. Si en 72 horas nadie grita que algo no funciona, puedes hacer docker rm.

El Resultado

Despues de identificar los candidatos (aun pendiente ejecutar el apagado en mi caso — lo hago con confirmacion explicita), el servidor tendra:

• ~1.7 GB RAM disponibles para servicios reales
• Menos containers en docker ps = menos superficie de ataque
• Logs mas limpios
• Menor carga cognitiva al operar la infra

La Leccion de Fondo

Los containers zombie no nacen malos — nacen utiles. El problema es que los sistemas evolucionan, los consumidores cambian, y los servicios que antes eran criticos se vuelven obsoletos. Sin una auditoria periodica, acumulas deuda de infra silenciosamente.

Recomendacion: programar una auditoria de containers cada 60 días. No tienes que apagar todo — solo identificar y decidir conscientemente.

---

Si necesitas ayuda auditando tu infraestructura Docker o quieres una revisión profesional de tus containers en producción, escribe a contacto@varelainsights.com.

---

Preguntas Frecuentes

¿Con qué frecuencia debería hacer esta auditoria?

Cada 60 días como mínimo. Si tu equipo crece o tienes muchos proyectos activos, cada 30 días. El comando docker stats --no-stream tarda menos de 10 segundos en darte el panorama completo.

¿Qué hago si no sé para qué sirve un container?

Primero revisa: docker inspect nombre --format '{{.Config.Labels}}' para ver si hay metadatos. Luego docker logs --tail 50 nombre para ver qué hace. Si despues de eso sigues sin saber, es candidato a apagar y observar.

¿Es seguro apagar un container de base de datos standby?

Solo si tienes un plan de failover documentado y probado. Si tu standby nunca ha sido activado y no tienes runbook, en realidad no tienes DR — solo tienes un container que consume recursos. En ese caso, apagar y crear un backup schedule real puede ser mas util que mantener una ilusión de alta disponibilidad.