GitHub Actions 实现博客自动构建与部署

Words: 765Read Time: 2 minLast edited: 2026-8-4
以前发布博客的流程是:本地 dotnet publish,压缩,scp 上传,ssh 上去解压、重启服务。熟练之后也要十分钟,还经常漏步骤。忍无可忍,我用 GitHub Actions 把整套流程自动化了:push 到 main 分支,几分钟后线上自动更新。这篇记录 workflow 配置和踩坑。

workflow 全貌

在仓库里建 .github/workflows/deploy.yml
流程很直白:push 触发,装 .NET SDK,跑测试,发布,rsync 增量同步到服务器,ssh 过去重启 systemd 服务。rsync 只传变化的文件,比整包 scp 快得多。测试不过,后面的步骤不会执行,坏代码到不了线上。

secrets 怎么管

服务器地址、用户名、SSH 私钥这些绝不能写进仓库。在仓库的 Settings,Secrets and variables,Actions 里逐个添加,workflow 里用 ${{ secrets.XXX }} 引用。GitHub 会对日志里出现的 secret 自动打码,但自己也别手贱去 echo 它。
服务器侧做两点加固:给 CI 单独建一个低权限用户,authorized_keys 里只放专用公钥;再用 visudo 只允许这一条命令免密 sudo:
这样即使私钥泄露,攻击者拿到的也只是一把"能重启博客"的钥匙,而不是整台服务器。

踩坑记录

  • 对 `--delete` 要有敬畏。 rsync 的 --delete 会删掉目标目录里源没有的文件,让两边保持完全一致。有一次 remote_path 少写了一层,差点把上级目录清掉。建议先用 --dry-run 跑一遍,看看会动哪些文件
  • known_hosts 首次连接。 自己写 ssh 命令时,StrictHostKeyChecking 会在首次连接时卡住等确认,需要提前处理;我用的这两个 action 内部已经搞定
  • 数据库迁移别交给 CI 自动跑。 我坚持把迁移留在手动执行:代码回滚容易,数据变更难,这种不可回滚的操作值得留一个人工确认环节

收尾:加个状态徽章

workflow 跑通后,GitHub 会为每个 workflow 生成状态徽章,在 Actions 页面右上角就能拿到徽章代码,贴到 README 顶部,绿绿的 passing 标志看着就安心。现在每次 push 完我就去刷一眼 Actions:绿了就去倒杯咖啡,红了点进去看日志,定位问题比以前 ssh 上去瞎猜快得多。
整套配置花了一个周末,省下来的时间和提心吊胆,早就回本了。
Loading...
© 2024 - 2026 ihuadz
中文