El reload que leía la configuración vieja
Se edita el archivo, el contenedor valida la configuración, el reload responde OK y el cambio no existe. No es caché: es que montar un archivo —y no un directorio— ata el contenedor a un inodo que el editor ya reemplazó.
La secuencia parecía impecable: editar la configuración del proxy, validarla dentro del contenedor, pedir una recarga sin cortar el servicio. Las tres respondieron bien. El cambio no estaba aplicado.
Y no estaba aplicado de la peor manera posible: sin ningún síntoma. La validación pasaba, la recarga decía que sí, y el contenedor seguía sirviendo la configuración anterior, porque el archivo que estaba leyendo ya no era el que yo había editado.
Qué es un inodo y por qué importa acá
En Linux, un nombre de archivo no es el archivo. El nombre es una entrada del directorio que apunta a un inodo: la estructura que contiene realmente los datos y los metadatos. Varios nombres pueden apuntar al mismo inodo, y un mismo nombre puede apuntar a inodos distintos a lo largo del tiempo.
Cuando un contenedor monta un archivo —no el directorio que lo contiene—, el montaje queda atado al inodo que existía en ese momento.
Lo que hace un editor moderno al guardar
- Escribe el contenido nuevo en un archivo temporal, al lado del original.
- Lo renombra sobre el nombre original, de forma atómica.
- El nombre pasa a apuntar a un inodo nuevo. El viejo sigue existiendo mientras alguien lo tenga abierto o montado.
- Desde el host, el archivo se ve modificado. Desde adentro del contenedor, no cambió nada: sigue viendo el inodo viejo.
Esa es la trampa completa. Es un guardado seguro —justamente pensado para que nadie lea un archivo a medio escribir— y es la razón por la que el cambio no llega.
Buscá en el log
El log del contenedor después de pedir la recarga. ¿Qué línea muestra que la configuración nueva nunca se leyó?
debug 4info 5warn 1error 010 de 10
El inodo que el proxy tiene abierto no es el del archivo que quedó en el disco. La recarga hizo todo bien —releyó, validó y aplicó— sobre el archivo viejo, que sigue existiendo porque alguien lo tiene abierto. Por eso no hay error: desde adentro del contenedor no cambió nada. La comprobación que cierra el caso es comparar el inodo que ve el proceso con el del archivo actual.
Cómo se confirma, y cómo se arregla
La verificación que sí sirve es preguntarle al contenedor por el contenido, no al reload por su resultado: buscar adentro del contenedor una cadena de texto que sólo exista en la versión nueva. Si no aparece, el montaje quedó viejo.
| Cómo se guarda | Qué ve el contenedor | Qué hace falta para aplicar |
|---|---|---|
| Editor que reemplaza el archivo | La versión vieja, para siempre | Reiniciar o recrear el contenedor |
| Escritura en el mismo inodo (redirección o apertura en modo escritura) | La versión nueva al instante | Una recarga, sin caída |
| Montar el directorio en vez del archivo | Siempre la versión nueva | Una recarga, sin caída |
Antes de seguir, predecí
En este caso el arreglo inmediato fue reiniciar el contenedor del proxy: unos segundos de caída para todos los sitios del servidor, lo que convierte a los cambios de configuración en algo que conviene juntar en una sola tanda. El arreglo de fondo, para el día a día, es escribir el archivo sin reemplazar el inodo; ahí la recarga alcanza y no hay corte.
La familia de fallas «se edita y no se aplica»
Una vez que se reconoce la forma —la herramienta dice que sí y el sistema sigue igual—, aparece en varios lugares:
Parientes cercanos
- Configuración copiada dentro de la imagen. Editarla en el repositorio no cambia nada hasta reconstruir: el contenedor corre lo que se horneó, no lo que está en disco.
- Variables de entorno. Cambiar el archivo de variables no afecta a un contenedor ya corriendo: se leen una sola vez, al arrancar.
- Servicios que recrean sólo parte del conjunto. Si un componente comparte archivo de construcción con otro pero tiene imagen propia, reconstruir uno deja al otro viejo, y el despliegue queda a mitad de camino sin error visible.
- Un reenvío que reescribe mal la ruta. Cuando el destino se arma con una variable, el prefijo de la ruta deja de recortarse solo y el servicio de atrás responde 404 a un camino que nadie pidió. La configuración se aplicó perfecto; lo que está mal es lo que hace.
Más a fondo · nivel seniorLa regla general
Cada una de estas fallas comparte una estructura: la señal de éxito viene de una capa distinta a la que tiene el efecto. La recarga confirma que el proceso releyó su archivo, no que ese archivo sea el tuyo. La reconstrucción confirma que esa imagen se armó, no que el contenedor en ejecución la use. Cuando algo «se aplicó» pero no se ve el efecto, el hábito que ahorra tiempo es preguntarle al último eslabón —el que produce el efecto— si ya tiene el cambio.
Verificar lo que se aplicó
Cierre
Autoevaluación
¿Lo entendiste?
Práctica