docker-compose中python:3镜像环境变量问题：迁移失败但CMD启动正常

这事儿核心就在于Docker的构建过程和容器运行过程是完全独立的两个阶段，环境变量的作用范围根本不一样：

• 构建阶段（Dockerfile里的RUN指令）：当你执行docker build构建镜像时，所有RUN命令都是在镜像的构建层中执行的。如果你的DJANGO_SECRET_KEY是在容器运行时才设置的（比如通过docker run -e、docker-compose的environment配置，或者容器启动时的其他注入方式），那构建阶段根本看不到这个变量——这就是你倒数第二行migrations失败的原因。

• 运行阶段（CMD/ENTRYPOINT指令）：当你启动容器时，Docker会加载你配置的所有运行时环境变量，然后执行CMD里的命令。这时候DJANGO_SECRET_KEY已经存在了，所以runserver能正常启动。

额外的最佳实践提醒 #

其实把数据库迁移（migrations）放在构建阶段本身就不是个好主意：

1. 构建镜像时，你的目标数据库可能还没启动，或者和最终运行时的数据库不是同一个实例，迁移根本无法正常执行。
2. 敏感信息比如DJANGO_SECRET_KEY如果通过构建参数（ARG）传递，会被留在镜像的构建历史里，存在安全风险。

解决办法：把migrations移到容器启动时执行 #

你可以写一个简单的启动脚本，让容器启动时先执行迁移，再启动服务：

1. 新建一个start.sh脚本：

#!/bin/sh
# 先执行数据库迁移
python manage.py migrate --settings=falcon.settings.dev-microservice
# 再启动开发服务器
python manage.py runserver 0.0.0.0:8001 --settings=falcon.settings.dev-microservice

2. 修改你的Dockerfile，替换原来的CMD：

# 复制启动脚本到容器内
COPY start.sh /app/start.sh
# 给脚本添加执行权限
RUN chmod +x /app/start.sh
# 设置容器启动时执行脚本
CMD ["/app/start.sh"]

这样一来，migrations和runserver都是在容器运行阶段执行的，能正常读取到你设置的环境变量，而且迁移也能和运行时的数据库正常交互。

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