Python Django怎么实现自动化部署_编写GitLab Runner流水线脚本-Python教程-PHP中文网

GitLab Runner 应部署在能同时访问 GitLab 仓库和目标服务器的机器上，推荐跳板机或独立部署机；敏感变量须通过 GitLab CI Variables 管理；collectstatic 权限问题需修正目录属主；migrate 必加 --noinput 并校验。

python django怎么实现自动化部署_编写gitlab runner流水线脚本

GitLab Runner 要装在哪儿才能访问 Django 项目代码和服务器

Runner 必须部署在能同时触达 GitLab 仓库（拉代码）和目标部署机（执行部署命令）的机器上。常见错误是把 Runner 装在跳板机或本地开发机上——前者常因网络策略无法直连生产服务器，后者根本没法持久运行。

推荐做法：gitlab-runner 安装在跳板机或独立部署机（非 Django 应用所在服务器），再通过 ssh 或 rsync 推送文件、执行远程命令。若权限允许，也可将 Runner 直接注册为 shell executor 并安装在 Django 所在服务器（但需确保 Runner 用户有 sudo 权限管理服务）。

Runner 注册时用 sudo gitlab-runner register，避免权限不足导致 job 启动失败
检查 /etc/gitlab-runner/config.toml 中 executor = "shell" 或 "ssh"，别误配成 "docker"（除非你真用容器部署）
Runner 用户必须能无密码 ssh 到目标服务器（配置好 ~/.ssh/id_rsa 和 authorized_keys）

流水线脚本里怎么安全传入数据库密码和 SECRET_KEY

绝不能硬编码在 .gitlab-ci.yml 里，也不能提交到仓库。GitLab CI 的变量机制是唯一合规路径：在项目 Settings → CI/CD → Variables 里添加 DB_PASSWORD、DJANGO_SECRET_KEY 等，勾选 Mask variable（对非正则匹配的值才生效）和 Protected（仅在 protected branch 上暴露）。

在脚本中直接引用即可，Django 会自动从环境读取：

从 Git 仓库历史中彻底删除文件

|Git删除了文件，但还会在Git 仓库历史中遗留。 - 想要从 Git 历史移除敏感信息（密码、密钥、token、私钥） - 想要删除意外提交的大文件 - 想要重写 Git 历史、移除特定文件的所有痕迹 - 提到 "force push"、"重写 commit 历史" - 需要从所有分支、所有 tag 中删除某个文件

下载

deploy:
  script:
    - export DJANGO_SETTINGS_MODULE="myproject.settings.production"
    - python manage.py migrate --noinput
    - python manage.py collectstatic --noinput
    - sudo systemctl restart gunicorn

确保 settings/production.py 中用 os.environ.get('DJANGO_SECRET_KEY') 替代硬编码
如果用 django-environ，记得在 CI 环境中也安装它：pip install django-environ
敏感变量不会出现在 job 日志里（只要没主动 echo $DB_PASSWORD），但一旦写错成 echo "$DB_PASSWORD" 就会泄露

为什么 collectstatic 总报错 “Permission denied”

本质是 CI 运行用户（如 gitlab-runner）没有权限写入 STATIC_ROOT 目录，比如 /var/www/myproject/static/。不是 Django 配置问题，是 Linux 文件系统权限问题。

部署前加一步：sudo chown -R gitlab-runner:www-data /var/www/myproject/static/
或者改用 rsync 同步静态文件，绕过 CI 进程直接写磁盘（更可控）
别在 collectstatic 命令后加 --clear，CI 环境下容易误删线上已有静态资源
如果用 Nginx 直接服务静态文件，确认 nginx.conf 中 location /static/ 指向的路径与 STATIC_ROOT 严格一致

如何让迁移（migrate）不卡住或破坏线上数据

python manage.py migrate 在 CI 中执行本身没问题，但有两个致命陷阱：一是没加 --noinput 会导致交互式提示阻塞 job；二是没人检查迁移是否真成功，就直接重启服务，结果服务起不来。

必须加 --noinput 参数，否则遇到 Are you sure? 就挂起
加个简单校验：python manage.py showmigrations | grep '\[ \]' && echo "UNAPPLIED MIGRATIONS FOUND" && exit 1，防止漏跑
迁移失败时，Gunicorn 不该重启。用 && 连接命令链，而不是 ; —— python manage.py migrate --noinput && sudo systemctl restart gunicorn
高风险操作（如 makemigrations）永远不在 CI 中做，只在本地生成，提交到仓库