自托管部署管道的 GitHub Actions
为什么自托管部署更复杂
云 PaaS 部署之所以简单，是因为部署目标——Vercel、Railway、Fly——已经建立了 GitHub Actions 集成。你提供一个 API 密钥，集成会处理其余部分。
对于自托管基础设施，你负责：让 GitHub Actions 运行器访问你的服务器、安全地管理 SSH 密钥、以及协调部署顺序，使服务在更新期间不会中断。
SSH 密钥管理
不要将 SSH 私钥存储为 GitHub secrets 并在 Actions 中使用它们。这会给每个能够创建工作流文件的人提供服务器访问权限。
更好的方法是使用专用的部署密钥：每个存储库一个密钥对，权限仅限于特定的部署用户，并且该用户的权限仅限于部署所需的操作。
Workflow 结构
一个可靠的自托管部署工作流应该：在测试失败时提前退出，在部署前构建产物，通过 SSH 传输到服务器，在服务器上执行部署脚本，以及验证部署后的健康检查。
- name: Deploy
uses: appleboy/ssh-action@v1
with:
host: ${{ secrets.SERVER_HOST }}
username: deploy
key: ${{ secrets.DEPLOY_KEY }}
script: /opt/deploy/run.sh零停机部署
对于必须保持在线的服务，部署脚本应该实现滚动更新：启动新实例，验证其健康，然后停止旧实例。Docker Compose 的 --scale 选项和健康检查结合使用可以使这种模式可靠。
回滚策略
每次部署都应该创建一个带时间戳的版本目录，当前部署通过符号链接指向最新版本。回滚就是将符号链接更新到上一个版本目录——这个操作需要几秒钟，而不是完整的重新部署。