GitLab Runner 应部署在能同时访问 GitLab 仓库和目标服务器的机器上，推荐跳板机或独立部署机；敏感变量须通过 GitLab CI Variables 管理；collectstatic 权限问题需修正目录属主；migrate 必加 --noinput 并校验。
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 历史移除敏感信息（密码、密钥、token、私钥） - 想要删除意外提交的大文件 - 想要重写 Git 历史、移除特定文件的所有痕迹 - 提到 "force push"、"重写 commit 历史" - 需要从所有分支、所有 tag 中删除某个文件
立即学习“Python免费学习笔记（深入）”；
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 中做，只在本地生成，提交到仓库
实际最难的不是写脚本，是让每次 git push 后的部署行为可预测、可回滚、可观测。比如没加 --noinput 卡住 pipeline，或 STATIC_ROOT 权限不对导致页面 500，这类问题往往要等用户反馈才发现。
