1

显然，有两种策略用于部署 Web 应用程序。如果我错了，请纠正我。

拉取部署

我有自己的构建、部署脚本。我使用 git 作为 vcs。部署脚本将从 git 存储库中提取代码，构建脚本将配置应用程序。

优点

  • 简易安装。
  • 更好的可扩展性（因为我的 ssh 密钥驻留在服务器中，它可以联系我们的 vcs 服务器）。因此，即使我们的应用程序服务器增长，我们也不必费心。

缺点

  • 每个应用程序服务器中作为 ssh 密钥的安全问题。

推送部署

我在我的旧项目中使用了这种方法，在那里我使用 rsync 来推送代码。我从本地机器推送了一份副本，但我们仍然使用了 vcs。

优点

  • 完全控制，灵活性，因为我不必将代码推送到 vcs。

缺点

  • 没有更好的可扩展性。

我检查了一些提供两种策略的工具。( http://capifony.org/ )

问题

  • 对于大型项目，你们如何处理这个问题？（用php构建）。
  • 有没有更好的策略？
  • 这两者之间哪个更好？
  • 如果负载均衡器下有很多应用服务器怎么办？push 在这里有意义吗？

提前致谢。

4

1 回答 1

2

完全控制，灵活性，因为我不必将代码推送到 vcs

这对我来说不是一件好事。与不使用 VCS 相比，您将拥有更多的控制权。我通常在开发和功能分支旁边创建一个生产分支，这样生产服务器只会拉下我故意放入生产分支的代码。

此外，如果您遇到生产代码突然中断的问题，如果您使用的是 VCS，您应该能够回滚到工作版本，同时找出代码有什么问题。对我来说，这是使用拉式部署最有益的方面之一。

如果您使用像 Jenkins 这样的持续集成工具，您可以定期检查 VCS 中特定分支的更改，并让 Jenkins 自动为您拉取和构建您的项目，而无需任何人自己登录到生产服务器。这使得部署就像更新存储库中的代码一样简单。

每个应用程序服务器中作为 ssh 密钥的安全问题

根据您的代码托管位置，您可能能够设置仅部署密钥。这就是 Bitbucket 的设置方式，因此我们的生产服务器只能拉取代码，不能推送。此外，如果其中一台服务器遭到入侵，我们可以轻松地撤销对我们存储库的对该特定密钥的访问。

于 2013-02-20T05:34:07.573 回答