Docker容器中Cronjob执行Django命令时环境变量失效问题

问题 #

我在使用Django REST Framework的Django应用中遇到持续问题：

• 应用包含带created_at时间戳的Project模型，manage.py中有管理命令archive_expired_new_project，会将创建后72小时未被用户操作的项目归档，该命令在生产环境由Cronjob执行，整套部署于Docker容器内。
• 最初后端分为两个Docker容器：一个运行Django应用提供API，另一个专门运行Cronjob。但该架构存在配置过时问题且维护开销大，因此将API与Cronjob合并到单个容器，用Supervisor管理Cronjob。
• Supervisor运行正常，Cronjob能按时执行，但存在环境变量问题：Cronjob使用过时配置（指向测试数据库的旧DB_HOST），而非Docker Compose设置的正确数据库地址；但正常访问的Django应用能正确使用生产环境变量连接数据库。
• 手动执行docker exec -it backend python3 manage.py archive_expired_new_project时，命令能正常使用正确的DB_HOST变量，仅Cronjob执行时会回退到旧的不可用数据库配置。这迫使我频繁清理Docker缓存、重建镜像，对日常维护不现实。
• 本地构建时一直使用--pull和--no-cache参数确保环境最新，但问题仍间歇性出现。本地通过.env文件设置测试环境的DB_HOST等变量，部署时Docker Compose直接注入生产环境变量，DB_HOST指向正确生产数据库。似乎Django命令从Cronjob执行时依赖某个缓存，但无法定位。

已尝试步骤：

• Docker清理：重建镜像、清除缓存层、确保Docker Compose环境变量更新，仅临时解决问题
• 配置检查：验证settings.py中DB_HOST等关键配置正确从环境变量加载
• Cronjob命令检查：确认Cronjob条目使用正确的manage.py路径，未引用过时配置文件

相关配置包含Dockerfile、crontab、supervisord.conf、docker-compose.yml及settings.py代码。

核心疑问：为何同一Docker容器内的Cronjob与Django应用拥有相同环境变量，但Cronjob执行时会使用过时配置？

可能的原因及解决方案 #

1. Cron默认不继承容器的完整环境变量 #

Cron进程启动时不会自动继承容器的所有环境变量，尤其是Docker Compose注入的运行时变量。即使由Supervisor启动，Cron的子进程（执行管理命令时）只能获取到有限的基础环境变量，可能包含构建镜像时硬编码的旧DB_HOST值。

解决方法：

• 在crontab条目里显式传递所需环境变量：

  * * * * * DB_HOST=$DB_HOST DB_PORT=$DB_PORT python3 /path/to/manage.py archive_expired_new_project >> /var/log/cron.log 2>&1
  

• 或者在Supervisor的Cron进程配置中，通过environment参数直接传递容器环境变量：

  [program:cron]
  command=/usr/sbin/cron -f
  environment=DB_HOST=%(ENV_DB_HOST)s,DB_PORT=%(ENV_DB_PORT)s,DB_NAME=%(ENV_DB_NAME)s,DB_USER=%(ENV_DB_USER)s,DB_PASSWORD=%(ENV_DB_PASSWORD)s
  

2. 构建镜像时环境变量被固化 #

如果构建Docker镜像时，本地测试环境的.env文件被意外加载，或者settings.py中设置了测试数据库的默认值，Cron执行时会优先读取这些固化在镜像里的旧值，而非Docker Compose注入的运行时变量。

解决方法：

• 确保Dockerfile中没有用ENV指令设置DB_HOST等数据库变量，所有配置完全依赖运行时环境变量。
• 修改settings.py，将数据库配置的默认值设为空占位符，避免硬编码测试地址：

  DATABASES = {
      'default': {
          'ENGINE': 'django.db.backends.postgresql',
          'NAME': os.environ.get('DB_NAME', ''),
          'USER': os.environ.get('DB_USER', ''),
          'PASSWORD': os.environ.get('DB_PASSWORD', ''),
          'HOST': os.environ.get('DB_HOST', ''),
          'PORT': os.environ.get('DB_PORT', '5432'),
      }
  }
  

• 把.env文件加入.dockerignore，防止构建时复制到镜像内。

3. Supervisor启动Cron时未传递最新变量 #

Supervisor启动Cron进程时，可能使用了容器启动初期的旧环境变量缓存，而非Docker Compose注入的最新值。

解决方法：

• 用Supervisor的环境变量占位符语法（%(ENV_XXX)s）显式传递变量，确保Cron进程能获取到最新值。
• 在容器启动脚本中添加supervisorctl reload命令，强制Supervisor重新加载配置，避免使用缓存的旧变量。

4. Django配置缓存（极少情况） #

如果使用了django-configurations等第三方配置库，可能存在配置缓存，导致Cron执行命令时没有重新读取最新环境变量。

解决方法：

• 执行管理命令时显式指定配置模块，强制重新加载配置：

  * * * * * python3 /path/to/manage.py archive_expired_new_project --settings=myproject.settings.production >> /var/log/cron.log 2>&1
  

• 检查第三方配置库的缓存机制，确保每次执行命令时都重新读取环境变量。

内容的提问来源于stack exchange，提问作者Thomas