¿Qué provoca que los trabajos programados se ejecuten en el host, pero no dentro de un contenedor?
Los trabajos programados fallan dentro de un contenedor cuando el programador, el entorno, el usuario, la hora o la ruta de ejecución necesaria difieren del contexto operativo del host.
Un comando que funciona en un shell interactivo del host puede depender del PATH del host, el perfil de inicio de sesión, la zona horaria, los archivos montados, las credenciales, el DNS o un demonio cron en ejecución continua. Dentro de un contenedor, nada de eso está garantizado. Empieza comprobando que haya un proceso de programación activo y, después, ejecuta el trabajo exacto con el mismo entorno mínimo y usuario que utiliza cron.
Confirma que realmente haya un proceso de programación en ejecución
Inspecciona los procesos activos del contenedor y el comando de inicio. Instalar paquetes de cron en la imagen no inicia el demonio, y normalmente un contenedor ejecuta solo el punto de entrada o el comando configurado.
La extensa discusión de Stack Overflow sobre cron en Docker gira en torno a la necesidad de ejecutar un programador dentro del contenedor, en lugar de asumir que el servicio del host controla su crontab. El primer factor de comprobación es si el proceso de cron está activo cuando llega la hora programada.
Si no hay ningún programador en ejecución, elige un diseño deliberado: ejecuta cron o un programador compatible con contenedores como proceso en primer plano, utiliza un contenedor independiente para el trabajo o invoca el contenedor de la aplicación desde el cron del host. No añadas un segundo demonio sin supervisión sin decidir cómo registrará su actividad y cómo se detendrá.
Ejecuta el comando exacto con un entorno mínimo
Copia el comando programado y ejecútalo dentro del contenedor como el usuario previsto para el trabajo, con un entorno reducido. Captura la salida estándar, la salida de error, el código de salida, el directorio actual y las variables de entorno.
Los trabajos de cron en contenedores suelen fallar porque cron no carga el perfil del shell interactivo que proporcionaba el PATH, los entornos de ejecución de lenguajes, los tokens de API o las variables de la aplicación. Una guía sobre programadores para contenedores destaca que conservar el entorno necesario para el trabajo es un requisito fundamental.
Si el comando falla únicamente con el entorno mínimo, añade rutas absolutas y solo las variables necesarias. Evita cargar un perfil de usuario completo que introduzca alias, indicadores o secretos irrelevantes.
Comprueba el PATH, el shell, el directorio de trabajo y el usuario
Sustituye los comandos y las rutas de archivo relativas por rutas absolutas. Confirma que el shell seleccionado exista y que la sintaxis del crontab coincida con la implementación de cron instalada en la imagen.
Ejecuta el trabajo como el usuario de cron configurado y comprueba el acceso de lectura, escritura y ejecución a los scripts, la configuración, los sockets y los directorios de salida. Una prueba manual realizada únicamente como root no demuestra que un trabajo programado sin privilegios pueda completarse.
Establece el directorio de trabajo dentro del comando o del script envoltorio. Si el trabajo funciona después de cambiar únicamente el directorio o el usuario, conserva ese contexto explícito en la configuración bajo control de versiones en lugar de depender de los valores predeterminados del contenedor.
Compara la hora y la zona horaria del contenedor con la programación
Muestra la hora actual, la zona horaria y la próxima ejecución prevista dentro del contenedor. Los contenedores comparten el reloj del kernel del host, pero pueden utilizar UTC u otros archivos de zona horaria para mostrar e interpretar las ejecuciones de cron.
Un caso de Server Fault muestra cómo la hora del contenedor puede aparecer en otra zona horaria aunque el host muestre la hora local, haciendo que un crontab correcto se ejecute a la hora local aparente equivocada.
Elige una estrategia explícita para la zona horaria y verifícala después de recrear el contenedor. No compenses desplazando la expresión de cron mientras mantienes ambigua la zona horaria subyacente, porque el horario de verano o los cambios en la imagen podrían volver a desplazarla.
Verifica los montajes, los secretos, el acceso a la red y la duración del contenedor
Comprueba que todos los directorios de entrada, rutas de salida, secretos, sockets y archivos de configuración existan dentro del contenedor en el momento de la ejecución. Después, prueba el acceso al DNS, la base de datos, la API o el NAS desde la misma red del contenedor.
El cron del host puede ver rutas del host que no existen dentro del contenedor. Un caso de Nextcloud en Docker demuestra cómo un trabajo en segundo plano puede parecer configurado mientras que el comando, el usuario o la ruta de la aplicación del contenedor impiden la ejecución en segundo plano esperada.
Confirma también que el contenedor siga en ejecución cuando llegue la hora programada. Los contenedores de aplicaciones de corta duración y los reemplazos durante despliegues pueden finalizar un programador interno antes de que se completen trabajos prolongados o poco frecuentes.
Elige un único límite de programación y demuestra que funciona sin supervisión
Utiliza un único responsable de la programación: el cron del host invocando docker exec, un contenedor de programación dedicado o un programador en primer plano dentro de la imagen de la aplicación. Los programadores duplicados pueden ejecutar dos veces la misma tarea de mantenimiento.
La guía de ZimaSpace sobre las pruebas de DNS desde el contenedor aborda una causa secundaria que aparece cuando el programador se inicia, pero no puede acceder a otro servicio.
El problema solo se considera resuelto cuando el trabajo se ejecuta a la hora prevista después de recrear el contenedor y reiniciar el host, genera registros capturados, utiliza el usuario y las rutas esperados y produce el resultado verificado de la aplicación. Un comando ejecutado correctamente de forma manual no es la prueba definitiva.
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...
