Django容器化与迁移最佳实践：本地迁移失效及配置疑问

一、解决本地migrate提示“无迁移可应用”的问题 #

• 检查迁移文件路径：确认makemigrations生成的文件在对应app的migrations目录下，且目录包含__init__.py文件（Django依赖该文件识别迁移目录）。
• 核对INSTALLED_APPS配置：生成迁移的app必须准确添加到settings.py的INSTALLED_APPS列表中，拼写和大小写需完全匹配。
• 确认数据库连接一致性：确保本地migrate命令使用的数据库与makemigrations时的数据库为同一个，避免误连测试库或其他环境的数据库。可执行python manage.py showmigrations查看迁移状态，对比生成的迁移文件是否出现在列表中。
• 检查迁移依赖：查看迁移文件内的dependencies字段，若依赖其他未应用的迁移，需先完成依赖迁移的应用。
• 重置迁移状态（本地开发谨慎操作）：若本地数据可丢弃，可清空数据库的django_migrations表，删除所有app下migrations目录内的文件（保留__init__.py），重新执行makemigrations和migrate。

二、Docker Compose容器化场景下的迁移最佳实践 #

• 分离迁移与应用启动逻辑：不要将migrate命令写入Docker镜像的CMD或ENTRYPOINT中，避免容器每次启动都执行迁移，引发并发冲突或重复执行问题。建议在启动应用容器前单独执行迁移。
• 使用临时容器执行迁移：通过Docker Compose启动临时容器完成迁移，示例命令：

  docker-compose run --rm web python manage.py migrate
  

  其中web为你的Django服务容器名，--rm参数会在执行完成后自动删除临时容器，避免残留资源。
• 确保数据库服务就绪：迁移前需确认数据库容器已启动并可正常连接。可使用wait-for-it工具实现等待逻辑，示例：

  docker-compose run --rm web sh -c "wait-for-it db:5432 -- python manage.py migrate"
  

  （假设数据库服务名为db，端口为5432）
• 控制数据库权限：执行迁移的容器所使用的数据库用户需具备足够权限（如创建表、修改表结构）。生产环境建议使用专门的迁移用户，而非超级管理员账户。
• CI/CD流程中的迁移处理：在GitHub Actions等CI/CD流程中，优先执行迁移命令，确认迁移成功后再启动新版本应用服务。需保证CI环境可正常访问目标数据库。
• 生产环境迁移前备份：执行迁移前必须备份数据库，避免迁移失败导致数据丢失。可在CI/CD流程中添加备份步骤，或利用数据库自带的自动备份功能。

内容的提问来源于stack exchange，提问作者Cédric Leroy