![多服务器部署策略-生产服务器上的 Git?](https://linux22.com/image/603640/%E5%A4%9A%E6%9C%8D%E5%8A%A1%E5%99%A8%E9%83%A8%E7%BD%B2%E7%AD%96%E7%95%A5-%E7%94%9F%E4%BA%A7%E6%9C%8D%E5%8A%A1%E5%99%A8%E4%B8%8A%E7%9A%84%20Git%EF%BC%9F.png)
主要问题:在生产服务器上使用 Git 部署是一个好策略吗?
我看到的许多部署策略都围绕在服务器(开发、暂存和生产)上安装 Git。
对于阶段/生产部署来说,这样做的优点显而易见:
- 能够快速引入变更
- 更简单的自动化
- 如果需要可以切换分支(可能是每个测试服务器的分支)
- 可以查看生产服务器中的文件是否发生了某种变化
然而,我发现这样做有一些缺点:
- 安全性——即使生产环境具有只读访问权限,Git 似乎也是一个潜在的攻击载体
git pull
如果生产中存在未暂存的更改,则生产服务器上的更改可能会失败(尽管可以使用 -f 克服)
部署即服务公司(例如 Beanstalkapp.com、deployhq.com)使用 FTP、SFTP 或 SSH。Beanstalkapp 尤其擅长仅根据 git 历史记录修改文件(而不是重新部署每个文件)。这些服务不要求您在阶段/生产服务器上安装 git(尽管如果您通过 SSH 部署,您可能会/可以使用该策略,这一点值得商榷)。
我发现我喜欢使用 sftp:
- 仍可在部署前/部署后运行脚本
- 无论生产服务器上是什么,都会覆盖、移动、删除文件(这对我来说是一个优点)
- 生产环境中没有.git 目录或任何基于 git 的攻击漏洞
从最佳实践和安全性的角度来看,在生产服务器上使用 git 的便利性是否值得?如果不值得,那么跳过持续集成工具进行部署的好方法是什么?
(我仅询问是否跳过 CI 工具,因为时间/预算/客户限制不允许我在日常使用它们)。
答案1
回答您的问题:是的,使用 git(或任何其他修订控制)进行部署是可行的方法,特别是当您的基础设施开始变得复杂/庞大时。
回答你的疑虑
安全必须分层实施,即使 git 确实是一个令人担忧的攻击媒介,也需要有人获得服务器访问权限才能做到这一点。拥有良好的服务器安全性、基于 SSH 密钥的身份验证和访问控制/日志记录,您的风险就会非常低。
如果您想编写部署工具,当然您必须考虑回滚程序,以防代码更新失败。好消息是,像 capistrano(我更熟悉)这样的工具已经内置了所有这些步骤,您可以更改行为等。
我认为最好的是使用部署工具卡皮斯特拉诺或者部署者弗拉德甚至Chef 部署如果您已经有 Chef(或其他配置管理工具)。
例如,Capistrano 默认针对的是 Rails,但您可以对其进行定制以部署任何内容。它将连接到您的服务器,更新代码(保留一些旧版本以防您需要回滚到以前的版本),执行数据库迁移或清理等任务,然后在需要时重新启动服务。您可以根据您的环境对其进行定制,甚至可以拥有不同的环境(我曾使用生产、声明和其他 3 个环境)。
所有其他工具都允许您做类似的事情,我认为只有当您的系统与“通常”的系统确实不同时,花时间编写部署脚本才有效。