¿Por qué un servicio de Compose usa el archivo de entorno incorrecto solo después de reiniciar el host?
Un servicio de Compose puede usar valores de entorno diferentes después de reiniciar si el lanzador de arranque resuelve otro directorio del proyecto, archivo de entorno u origen de precedencia.
Un comando manual puede ejecutarse desde la carpeta prevista con un entorno de shell, mientras que systemd, un programador de NAS o Portainer inicia el mismo archivo de Compose desde otro contexto después del arranque. El servicio también puede reiniciar un contenedor existente cuyo entorno quedó fijado al crearlo, en lugar de volver a leer el archivo editado. Compare el modelo de Compose renderizado y el entorno del proceso en ejecución desde las rutas manual y de arranque antes de editar varios archivos a la vez.
Compare el entorno en ejecución con el archivo previsto
Registre el ID del contenedor, la hora de creación, la imagen, las etiquetas de Compose, el nombre del proyecto y los valores reales visibles dentro del proceso principal. Compárelos con el archivo de entorno previsto sin imprimir secretos en registros compartidos.
El entorno del proceso de Linux expone los valores suministrados durante la ejecución, lo que constituye una evidencia más sólida que leer un archivo de entorno que el contenedor actual quizá nunca haya utilizado.
Si el contenedor contiene los valores antiguos y es anterior al despliegue realizado durante el arranque, es posible que el servicio simplemente lo haya reiniciado. Si el contenedor es nuevo, continúe con la precedencia y la resolución de rutas.
Aplique la precedencia del entorno de Compose en el orden correcto
Enumere todas las fuentes para una variable no confidencial: indicadores de la CLI, valores del shell, environment:, env_file:, .env predeterminado o explícito y ENV de la imagen.
Docker define un orden formal de precedencia del entorno, por lo que un archivo de entorno correcto aún puede perder frente a un valor de mayor prioridad inyectado por el servicio de arranque o el administrador de la pila.
No busque únicamente nombres de archivo duplicados. Busque el nombre de la variable en el modelo de Compose renderizado, el archivo de unidad, la configuración del administrador, el entorno del shell y los valores predeterminados de la imagen.
Compruebe el directorio del proyecto y las rutas relativas de los archivos de entorno
Compare el directorio de trabajo del comando manual con el directorio de trabajo del lanzador de arranque, los argumentos de los archivos de Compose, el directorio del proyecto y las referencias relativas a env_file.
La especificación de Compose define el modelo de aplicación utilizado para resolver servicios y configuración, por lo que la definición del proyecto seleccionada y sus rutas son entradas del despliegue, no propiedades que se redescubran desde el contenedor en ejecución.
Use rutas absolutas para los archivos de entorno críticos durante el arranque cuando la herramienta de despliegue lo permita, o establezca un directorio del proyecto y un directorio de trabajo explícitos para que los lanzamientos manuales y automatizados resuelvan los mismos archivos.
Inspeccione el directorio de trabajo y los archivos de entorno de systemd
Lea la unidad efectiva, todas las extensiones, WorkingDirectory=, Environment=, EnvironmentFile= y ExecStart=. Compare la unidad cargada durante el arranque con el comando utilizado manualmente.
Los ajustes de ejecución de systemd definen el directorio de trabajo y los archivos de entorno del servicio, que no heredan automáticamente el directorio actual ni las variables exportadas de un shell de inicio de sesión interactivo.
Después de cambiar una unidad o una extensión, vuelva a cargar el administrador de systemd e inspeccione de nuevo la unidad efectiva. Editar una plantilla o un archivo sin usar no cambia el servicio que realmente se inicia.
Compruebe las variables del administrador de pilas y el estado de despliegue almacenado
Si Portainer o una interfaz de NAS administra la pila, compare sus variables guardadas, el archivo de entorno cargado, la ruta del despliegue de Git, el comportamiento de actualización mediante webhook y el modelo de Compose mostrado.
Portainer distingue entre el comportamiento de .env y stack.env, por lo que los valores introducidos en el administrador pueden diferir de los de un archivo editado directamente en el host.
Elija una única fuente de verdad. Una pila administrada desde Git o un editor web no debería iniciarse también manualmente desde otra copia local después de cada reinicio.
Vuelva a crear el contenedor en lugar de limitarse a reiniciarlo
Compare la hora de creación del contenedor con la hora de edición del archivo de entorno. Renderice la configuración de Compose prevista y, a continuación, realice una recreación controlada únicamente del servicio afectado.
La guía de systemd de Red Hat recomienda comprobar los archivos y las anulaciones que realmente utiliza un servicio antes de reiniciarlo, para evitar que una unidad o un envoltorio obsoleto vuelva a crear el contenedor con valores antiguos.
Reiniciar un contenedor no reconstruye su entorno a partir de Compose. Vuelva a crearlo solo después de proteger los datos persistentes y confirmar que el modelo renderizado apunta a los volúmenes y secretos previstos.
Haga que el inicio manual, el reinicio y el redespliegue produzcan el mismo modelo
Fije los archivos de Compose, el nombre del proyecto, el directorio del proyecto, la ruta del archivo de entorno, el propietario de la pila y la dependencia de arranque. Guarde una configuración renderizada con los datos confidenciales ocultos y una huella de entorno no confidencial.
El artículo de ZimaSpace sobre el alcance de las copias de seguridad de Docker ofrece la regla relacionada: los archivos de entorno y las definiciones de despliegue deben conservarse junto con el estado persistente.
El problema se resuelve cuando una recreación manual, un reinicio del host, una actualización programada y un redespliegue desde el administrador de pilas crean el servicio con la misma huella de entorno sin datos confidenciales.
Preguntas frecuentes
¿Cuál es la diferencia entre .env y env_file?
Un archivo .env del proyecto suele proporcionar valores de interpolación a Compose, mientras que un archivo env_file del servicio proporciona variables al contenedor. Su interacción y precedencia dependen del modelo de Compose completo.
¿Reiniciar un contenedor vuelve a cargar un archivo de entorno modificado?
No. Los valores de entorno se establecen cuando se crea el contenedor. Normalmente, el servicio debe volver a crearse a partir de la configuración de Compose corregida.
¿Por qué el problema aparece únicamente después de reiniciar?
La ruta de reinicio puede utilizar una unidad de systemd, un programador, variables almacenadas por el administrador, otro directorio de trabajo o una copia antigua de Compose que difiere del lanzamiento manual.
Productos recomendados
Soporte y Consejos
Más para leer
¿Por qué restaurar un volumen de Docker recrea el contenido de los archivos, pero elimina los atributos extendidos?
Un diagnóstico de restauración de volúmenes que abarca el inventario de atributos extendidos, las opciones de tar y Rsync, los espacios de nombres, la...
¿Por qué un contenedor en ejecución mantiene su antiguo límite de memoria después de cambiar el archivo de Compose?
Un diagnóstico del límite de memoria que abarca los cgroups activos, el reinicio frente a la recreación, los campos de Compose, los límites estrictos...
¿Por qué reiniciar un proxy inverso invalida todas las sesiones de una aplicación autoalojada?
Un diagnóstico de pérdida de sesión que abarca el alcance del reinicio, la propiedad de las cookies, la rotación de secretos, las sesiones respaldadas...
