将工具和脚本部署到生产环境的最佳实践?

这里有几类工具。有些人使用这些类别的工具组合。例如,我有时使用木偶和卡皮斯特拉诺。见 Puppet or Capistrano - Use the Right Tool for the Job 进行讨论。

旨在部署应用程序的脚本工具:

此类工具的一般模式是创建脚本和/或配置文件,通常使用类似于makefile的命令集,该工具将ssh连接到生产框,签出源代码,并运行任何其他必要步骤。

此区域中的工具通常具有回滚到以前版本的工具。因此,如果一切顺利,他们会将您的源代码签出到releases/目录,并创建一个从“current”到“releases/”的符号链接。如果出现问题,您可以通过运行一个命令来还原以前的版本,该命令将删除“当前”并将其链接到以前的版本/目录。

• Capistrano 来自rails社区,但是是通用的。卡皮斯特拉诺的用户可能对 deprec ,capistrano的一组部署方法。
• Vlad the Deployer 是Capistrano的替代品,同样来自Rails社区。
• 编写自己的shell脚本或makefile。

将文件放入生产框的选项:

• 直接从源签出。如果您的产品箱缺少开发工具,尤其是源代码管理工具,则不一定总是可能的。
• 在本地签出源代码,然后对其进行tar/zip压缩。使用scp或rsync复制tarball。有时对于亚马逊Ac2部署来说,这是首选的,压缩后的塔球可以节省时间/带宽。
• 在本地签出源,然后将其rsync到生产框。

包装工具

使用操作系统的打包系统生成包含应用程序文件的包。创建一个主包,该主包具有所需的其他包作为依赖项。这个 RubyWorks system就是一个例子,用于部署rails堆栈和示例应用程序。然后就是使用apt、yum/rpm、windows msi或其他什么工具来部署给定的版本。回滚包括卸载和重新安装旧版本。

用于安装应用程序/配置和维护一组系统的通用工具

这些工具并不是专门针对部署web应用程序的问题,而是针对为一组服务器或整个公司的工作站部署/维护应用程序/配置的更一般的问题。它们的目标是系统管理员,而不是Web开发人员,尽管它们都可以找到有用的。

• Cfengine 是这一类的工具。
• Puppet 旨在改进cfengine。它有一个学习曲线,但很多人觉得花时间来研究如何进行配置是值得的。一旦启动,每个框都会定期检查中心服务器,并确保所有内容都是最新的。如果有人编辑文件或更改权限,则会检测并更正此错误。因此,与上面的部署工具不同,puppet不仅为您将文件放在正确的位置,还确保它们保持这种方式。
• Chef 比木偶小一点,方法也差不多。
• Smartfrog 是该类别中的另一个工具。
• Ansible 使用纯yaml文件,不需要在它管理的服务器上运行代理

要比较这些工具和更多此类工具,请参阅wikipedia文章, Comparison of open source configuration management software .

看看 cfengine tutorial 看看cfengine是否适合您的情况。对于一个小网站来说,这可能有点太复杂了,但是如果将来它涉及到更多的计算机和更多的配置,那么在某个时候,您将最终使用cfengine或类似的东西。

按照发行版使用的格式创建自己的包,例如Debian包(.deb)。它们可以被复制到每台机器并手动安装,或者您可以设置自己的存储库,并将其添加到源列表中。

您的程序包应该设置为它们包含的脚本参考一个配置文件,每个主机上的配置文件不同,具体取决于需要在每个主机上运行哪些脚本。

为了将所有这些绑定在一起,您可以创建一个元包,它只取决于您创建的每个其他包。这样,当您设置一个新服务器时,您安装了一个元包,其他包作为依赖项引入。

虽然这个过程听起来有点复杂,但是如果你有很多脚本和许多主机来部署它们,从长远来看,它真的可以得到回报。

我必须经常向几个客户推出php脚本和apache配置。由于它们都运行debian linux,我在服务器上建立了debian包存储库,客户只需输入 更新已安装包 他们得到了最新的版本。

Puppet 是在这种情况下可以使用的另一种工具。它类似于cfengine—您创建了一个所需部署的模型,并绘制了如何使环境达到这种状态的傀儡图。

首先要做的是把这些脚本都放进一个源代码管理库(Svn或Git很好),这样你就可以跟踪这些脚本随时间的变化。

如果你对ruby感兴趣,可以去看看 Capistrano ,它非常适合将东西部署到集群中的多台计算机上,而且设置起来相当容易。它可以直接从您的版本控制系统读取文件。