Una decena de aplicaciones en un solo servidor, operadas por una persona. Cada caso es un incidente real contado como postmortem: qué se veía, qué pasaba en realidad y qué quedó cambiado para que no vuelva.
Armado con los posts publicados al 20 de septiembre de 2026.
El firewall del sistema no protege a los contenedores. Docker inserta sus reglas antes, así que todo puerto publicado queda expuesto sin importar lo que diga el firewall. La defensa real es no publicar lo que no hace falta, filtrar en la cadena que Docker sí consulta, poner contraseña incluso «puertas adentro» y tener un aviso automático que grite cuando aparece un puerto nuevo.
Casi nada de lo que queda expuesto se publicó a propósito: vino con la imagen, con un compose de desarrollo o con una prueba que quedó. Un solo punto de entrada, lo demás en redes internas, lo que necesite host atado a la interfaz local, y verificación desde afuera en vez de confianza en la configuración.
El fondo de internet es permanente y no significa nada. Lo que importa no es la cantidad de intentos sino los códigos de respuesta y lo que salió bien: un 200 donde iba un 404, un acceso exitoso desde donde no corresponde, tráfico de salida raro. Alertas pocas y excepcionales; si suena siempre, dejó de ser alerta.
Montar un archivo ata el contenedor a un inodo; guardarlo con un editor crea otro. Por eso el reload puede responder OK y servir la versión vieja. Verificá el cambio adentro del contenedor, no en el resultado del comando, y preferí montar directorios cuando el archivo se vaya a editar.
La barra final del destino decide si el prefijo se recorta, y ese carácter es todo el problema. La aplicación tiene que saber bajo qué base vive para generar sus enlaces; el proxy tiene que reenviar host, esquema e IP del cliente. Y antes de tocar nada, pedile directo al contenedor para saber de qué lado está la falla.
Un servidor detrás de un proxy no sabe por qué dominio ni con qué esquema lo pidieron. Si arma redirecciones absolutas, las arma con lo que ve: el nombre interno y sin cifrado. Redirecciones relativas cuando se pueda, cabeceras reenviadas y confiables cuando no, y verificación con la respuesta cruda, no con el navegador.
Renovar no es servir. El archivo puede estar nuevo y el proceso seguir presentando el anterior porque nadie lo recargó, o el certificado que se sirve puede ser uno viejo que ya no se renueva. La única comprobación que cubre todo es conectarse desde afuera al dominio y leer qué vence.
Compartir el Dockerfile no significa compartir la imagen: cada servicio construye la suya. Reconstruir sólo una parte deja la base migrada por código viejo, y el error aparece recién en la primera petición. Un solo comando que reconstruya todo el conjunto, y migraciones compatibles hacia atrás para que la convivencia de versiones no importe.
Un contenedor con nombre temporal es el rastro de un despliegue que se cortó por la mitad, no una caída. Y un chequeo por nombre miente en los dos sentidos: dice caído lo que sirve y dice bien lo que está colgado. Medí con una petición real, verificá después de desplegar y chequeá disco y memoria antes.
Ejecutar el archivo de desarrollo en producción publica puertos, cambia volúmenes y aplica credenciales de prueba, muchas veces sin un solo error visible. No se previene con cuidado sino con asimetría: archivos nombrados por entorno, un script como única vía de despliegue y el archivo de desarrollo fuera del servidor. Y si ya pasó, primero inventariar, nunca restaurar de entrada.
El pipeline confirma en un entorno limpio; no es donde uno se entera. Tipos, formato y los tests del alcance mientras trabajás; la suite completa y el build una vez, al cerrar la tanda; un solo push. Y en una máquina compartida, agrupar la verificación no es prolijidad: es no competir con lo que está sirviendo.
No se puede alertar sobre un error que no existe: se alerta sobre la ausencia de la señal de vida. Marca al terminar bien, comprobación externa de que esa marca sea reciente, registro de cuánto trabajo real hizo cada corrida, y un inventario de qué tareas deberían estar pasando.
Si al recibir una alerta no hay nada que hacer, no era una alerta. Avisar por síntoma y no por causa, con umbral sostenido, agrupadas, con qué, desde cuándo y qué mirar primero. Y las que se vienen ignorando hace un mes: se ajustan o se borran.
Un respaldo no probado es una hipótesis. Respaldá todo lo necesario para volver —no sólo la base—, cifrado y fuera del servidor, con alerta si no corre; y restaurá de verdad cada tanto, midiendo el tiempo y anotando los pasos. La primera restauración no puede ser el día del incidente.
El disco no se llena por un error sino por el funcionamiento normal sin límites. Rotación de registros, techo para la caché de construcción y limpieza programada por categorías explícitas —nunca volúmenes automáticamente—, más una alerta con margen. Y si un archivo borrado no libera espacio, es que alguien todavía lo tiene abierto.
atlas.matiascaliz.com.ar/materias/incidentes-de-produccion — si algo de acá no se entiende solo, el post completo lo explica.