将代码部署到多个前端服务器

在这种情况下，我们有多个负载均衡的服务器指向一个公共数据库。

在正常情况下，它可以正常工作，并提供冗余，可伸缩性等。

但是，我们发现部署有些麻烦。

我们正在广泛使用功能，并正在尝试自动化部署。目前的部署还不是很可靠。

以简化形式，每个服务器的部署脚本分为两个阶段

1. 更新档案

2. 还原功能（将管理依赖关系，设置更改等）

有没有在多个服务器上部署而不导致它们处于不一致状态的最佳实践？

据我所知，如果您将步骤1和2部署到服务器A，它将导致服务器B损坏，如果在继续执行步骤2之前在两个服务器上尝试步骤1，它们都将被破坏一段时间。

您可能应该研究Aegir，它是迄今为止最灵活，功能最强大的Drupal站点管理/部署系统。它能够管理跨越多个Web头或群集的“平台”，以及各种其他配置。

我建议有通过他们的读社区文档通常是相当不错的，以及通过阅读mig5的很好的概括和介绍性文章和他的一些像其他文章的这一个。

您也可以在#aegir IRC频道中获得良好的支持。

这将对工作流程进行一些更改，这肯定会花费一些时间来解决问题，但是一旦到达那里，您就不会回头。

在我们公司，我们维护着许多Drupal网站，我们当前的设置如下：

• 每个站点的代码库都有自己的git repo
• 新功能可能不太稳定，无法在下一个版本中发布，因此在git中获得了自己的功能分支

我想说的是，对于大多数Drupal网站来说，上述情况是相当普遍的。

我们公司的特别之处是使用自定义drush命令-'Drush Debian Packaging ' 将站点进行debian打包。

Drush Debian Packaging提供了一个Drush命令，用于构建Drupal站点的Debian软件包，作为将Drupal站点部署到Debian或Ubuntu服务器的一种方式。

Drush Debian Packaging利用Drupal挂钩系统构建最适合您站点需求的Debian软件包。功能包括：

• Apache2和Nginx Web服务器的自动虚拟主机配置
• 在/etc/cron.d中的Cron设置
• 通过站点/默认/文件的分区拆分实现自动代码部署
• 通过dpkg debconf设置工具自动配置
• 自动化的部署过程
• 定制的Git VCS处理程​​序，用于从Git构建软件包

这是什么意思？

要构建发行版：

cd /path/to/drupal-root
drush dh-make

要部署发行版，请先将.deb SCP放到群集中的所有Web服务器上。然后在所有Web服务器上运行（您可以使用linux软件包cssh在同一时间向服务器场中的所有服务器键入命令）：

sudo dpkg -i drupal-site-yoursitehere.2011.05.25-1.all.deb

在一台Web服务器上运行：

cd /path/to/drupal-root
sudo -u drupal-site-yoursitehere drush updb && drush fra -y && drush cron

完成

当然，从代码库的角度来看，现在回滚是微不足道的，只需将先前版本的.deb安装到所有Web服务器上，然后回滚数据库。

很高兴回答有关此的任何问题

部署过程的哪一部分比较繁琐/不可靠？

如果是“先更新服务器A然后B /不一致”问题，那么在推送期间放置维护页面该怎么办？向上维护页面，更新两个Web头上的代码，对其中之一运行update.php ，向下维护页面。这很容易编写脚本。

另一个选择：根据您所运行的站点的类型，您可以创建一个“只读模式”，该模式将使所有用户脱机并禁用登录/注册。将您的数据库克隆到同一数据库框中的另一个数据库，将您的前端克隆到一个新的docroot，在那里进行更新，然后将Apache的docroot链接到新的前端docroot。工作流程类似于：

1. 只读模式
2. 选择current_db INTO new_db
3. cp -R current_docroot new_docroot
4. new.yourdomain.com ==> / new_docroot
5. 将代码更新到new_docroot
6. update.php
7. symlink / new_docroot ==> current_docroot
8. 只读模式关闭。

正如Entendu所说，这将取决于您所做的更改。如果尚未更新数据库，可以运行什么比例的代码更新而不会导致错误？对于不依赖于数据库更新的任何事情（也许您可以稍微更改开发过程以使其更常见），实际上并没有什么特别的事情要做。我假设您要在停机时间最少的情况下进行部署，否则，这将需要一些基本的同步操作。在这种情况下，总会有一些时间窗口产生不良影响（即使只是将网站设置为只读模式），但我认为大多数情况下时间可能会很小。

您可以进行基本优化，例如提前在每台服务器上设置一个“新”目录，然后将它们全部切换到同一时间指向新目录（也许使用Entendu的答案中的符号链接），以便获得所有服务器在5到10秒内切换到新文件。

剩下数据库更新的问题。如果只需要在一台服务器上完成它们，则可能需要将其他服务器置于维护模式或调整负载均衡器以在发生这种情况时不使用它们。当然，如果在用户处于活动状态时无法完成这些操作，则只需要使所有内容都处于维护模式即可，但是对于简单的更新，您可以在30秒或更短的时间内完成。

对于不同类型的更改，可能有必要使用不同的部署脚本，因此您可以运行所需的最小过程，无论是复制文件，运行小型数据库更新还是进行大型数据库更改。

如果您可以优化文件和数据库更新，并查看是否可以对事物的开发方式进行简单的更改，这可以使您更接近，但我不知道这对您来说是否是新的：）

Aegir对管理站点网络很有用。我使用它为单个客户端部署和管理2000多个站点。

您的问题建议您要管理一个具有多个webhead的站点。在这种情况下，Aegir对您可能没有用。相反，我建议您考虑使用支持网络的文件系统。这不仅可以确保您的代码保持同步，还意味着您可以在所有节点上进行上传。

历史上人们使用NFS，它允许一台服务器的文件系统与其他节点共享。不幸的是，这会引入单点故障，因为如果NFS服务器锁定或死机，将无法为您的站点提供服务。

如果您愿意在IO性能上做出一些妥协以支持更可靠的服务器，那么我建议您使用GlusterFS。我已经在一些生产环境中使用过。它不是完美的，但是比NFS更好。Gluster允许webhead始终在本地读取，然后将写入复制到其他节点。

就您的部署策略而言，您应该将drush作为列表上的第一个工具。使用drush，您应该能够自动化部署步骤。您应该考虑将Jenkins添加到组合中，以便可以跟踪部署作业并在失败时确定模式。Capistrano对于自动化部署中涉及的步骤很有用。如果您做的正确，您可以做到，这样您的用户甚至都不会知道您进行了部署。