如何在CaptainDuckDuck与1GB Docker环境中处理Django数据库迁移问题

你遇到的问题核心其实是两个连锁因素：迁移文件未纳入Git版本控制，再加上CaptainDuckDuck的无状态容器特性——它会清除容器文件系统的所有临时更改，导致你本地生成的migrations文件夹在容器重启后彻底丢失，最终让Django无法匹配数据库中已应用的迁移记录。下面是一步步的实操解决方案：

1. 先把本地迁移文件同步到Git仓库 #

既然你已经成功执行过makemigrations，本地肯定有生成的迁移文件，现在必须把它们纳入Git追踪，这样CaptainDuckDuck部署时才能拉取到完整文件：

• 先确认每个Django App下的migrations文件夹都存在，且包含__init__.py和生成的迁移py文件
• 执行命令把这些文件加入Git：

  git add */migrations/*.py */migrations/__init__.py
  

• 提交并推送到远程仓库：

  git commit -m "Add Django migration files to version control"
  git push
  

2. 调整CaptainDuckDuck的启动脚本（runserver.sh） #

默认的启动逻辑没考虑迁移的持久化需求，我们需要修改captian-definition下的runserver.sh，让它在启动时自动处理迁移相关的前置工作：

#!/bin/bash

# 兜底：确保每个App的migrations文件夹存在（防止Git拉取时意外缺失）
for app in $(ls -d */ | grep -v "__pycache__" | grep -v "venv"); do
    if [ ! -d "$app/migrations" ]; then
        mkdir -p "$app/migrations"
        touch "$app/migrations/__init__.py"
    fi
done

# 自动执行迁移（--noinput避免交互）
python manage.py migrate --noinput

# 启动Django服务
python manage.py runserver 0.0.0.0:8000

这个脚本会先确保migrations目录结构完整，再自动执行迁移，最后启动服务，彻底避免手动执行时的遗漏。

3. 修复当前已部署环境的异常状态 #

如果现在容器里已经因为缺失migrations文件夹导致migrate报错，可以临时进入容器手动修复：

• 通过Docker命令或CaptainDuckDuck控制台进入运行中的容器：

  docker exec -it <你的容器名称> /bin/bash
  

• 在容器内拉取最新的Git代码（确保迁移文件已经推送到远程）：

  git pull
  

• 执行迁移命令恢复状态：

  python manage.py migrate
  

之后重启容器，服务就能正常运行了。

关键避坑提醒 #

• 绝对不要把migrations文件夹加入.gitignore，Django完全依赖这些文件来追踪数据库变更的历史脉络
• CaptainDuckDuck的容器是无状态的，所有需要持久化的文件（迁移文件、静态资源等）必须要么纳入Git，要么挂载外部持久化卷，否则重启后必然丢失
• 后续每次执行makemigrations生成新的迁移文件后，一定要记得提交并推送到Git，避免再次出现相同问题

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