部署工具和最佳做法脚本生产？ [英] Best practices for deploying tools & scripts to production?

问题描述

我有一些批处理流程，在Linux / PHP网站的后台运行。他们的数量和复杂程度开始增长，所以我想要少量的流程来承担它们。

I've got a number of batch processes that run behind the scenes for a Linux/PHP website. They are starting to grow in number and complexity, so I want to bring a small amount of process to bear on them.

我的源代码树有一堆cpp文件，脚本，与开发有关，但不考虑部署。在编译所有可执行文件之后，我需要将各种脚本和二进制文件放在一组机器上。不同的机器需要不同的可执行文件，脚本和配置文件来进行批处理。我也有几个我写的工具，属于每台机器。目前，这种部署过程是手动的和容易出错的。

My source tree has a bunch of cpp files and scripts, organized with development but not deployment in mind. After compiling all the executables, I need to put various scripts and binaries on a cluster of machines. Different machines need different executables, scripts, and config files for their batch processes. I also have a few of tools that I've written that belong on every machine. At the moment, this deployment process is manual and error prone.

我猜想我最终会得到一个运行在源树，并构建任何机器所需的一切小树。然后，我只是rsync到相应的机器。但我很好奇，其他人如何管理这种类型的问题。任何想法？

I'm guessing I'm just going to end up with a script that runs at the root of the source tree and builds a smaller tree of everything necessary for any of the machines. Then, I'll just rsync that to the appropriate machines. But I'm curious how other people are managing this type of problem. Any ideas?

推荐答案

这里有几类工具。有些人使用这些类别的工具组合。我有时甚至使用Puppet和Capistrano。请参阅 Puppet或Capistrano - 使用

There are a several categories of tool here. Some people use a combination of tools from these categories. I sometimes use, for example, both Puppet and Capistrano. See Puppet or Capistrano - Use the Right Tool for the Job for a discussion.

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

此类别中具有工具的一般模式是创建脚本和/或配置文件，通常使用与Makefile类似的命令集，并且该工具将ssh转到您的生产箱，做检查您的来源，并运行任何其他步骤是必要的。

The general pattern with tools in this category is that you create a script and/or config file, often with sets of commands similar to a Makefile, and the tool will ssh over to your production box, do a checkout of your source, and run whatever other steps are necessary.

该区域的工具通常具有回滚到以前版本的功能。所以他们会检查你的源到版本/目录，并创建一个符号链接从当前到发布/，如果一切顺利。如果有问题，您可以通过运行一个将删除当前命令并将其链接到以前的版本/目录的命令恢复到以前的版本。

Tools in this area usually have facilities for rollback to a previous version. So they'll check out your source to releases/ directory, and create a symbolic link from "current" to "releases/" if all goes well. If there's a problem, you can revert to the previous version by running a command that will remove "current" and link it to the previous releases/ directory.

• Capistrano 来自Rails社区，但是是通用的。 Capistrano的用户可能对 deprec 感兴趣，这是一组Capistrano的部署配方。


• Vlad the Deployer 是来自Rails社区的Capistrano的替代品。


• 编写自己的shell脚本或Makefile。

• Capistrano comes from the Rails community but is general-purpose. Users of Capistrano may be interested in deprec, a set of deployment recipes for Capistrano.
• Vlad the Deployer is an alternative to Capistrano, again from the Rails community.
• Write your own shell script or Makefile.

将文件导入生产箱的选项：

Options for getting the files to the production box:

• 从源码直接结帐。如果您的生产箱缺少开发工具，特别是源代码管理工具，并不总是可能。


• 在本地结帐源码，然后tar / zip。使用scp或rsync复制tarball。有时候，这有利于像Amazon EC2这样的部署，压缩的tarball可以节省时间/带宽。


• 在本地结帐源码，然后将rsync转移到制作框。

包装工具

使用操作系统的包装系统生成包含应用程序文件的软件包。创建一个主包，它与您需要的其他包具有依赖关系。 RubyWorks 系统是一个例子，用于部署Rails堆栈和示例应用程序。那么这是一个使用apt，yum / rpm，Windows msi或任何部署给定版本的问题。回滚涉及卸载并重新安装旧版本。

Use your OS's packaging system to generate packages containing the files for your app. Create a master package that has as dependencies the other packages you need. The RubyWorks system is an example of this, used to deploy a Rails stack and sample application. Then it's a matter of using apt, yum/rpm, Windows msi, or whatever to deploy a given version. Rollback involves uninstalling and reinstalling an old version.

旨在安装应用程序/配置和维护一组系统的常规工具

这些工具没有专门针对部署Web应用程序的问题，而是针对一组服务器或整个公司的工作站部署/维护Apps / Config的更普遍的问题。他们的目标更多的是系统管理员，而不是Web开发人员，但是可以发现它们很有用。

These tools do not specifically target the problem of deploying a web app, but rather the more general problem of deploying/maintaining Apps/Configs for a set of servers, or an entire company's workstations. They are aimed more at the system administrator than the web developer, though either can find them useful.

• Cfengine 是这个类别的工具。


• Puppet 旨在改善Cfengine。它有一个学习曲线，但很多人发现值得的时间来弄清楚如何做配置。一旦完成，每个盒子将定期检查中央服务器，并确保一切都是最新的。如果有人编辑文件或更改权限，则会检测并更正。所以，与上面的部署工具不同，Puppet不仅可以将文件放在正确的位置，还可以保证这些文件保持不变。


• 比Puppet稍微年轻一点。


• Smartfrog 是此类别的另一个工具。


• 可复制可以使用纯YAML文件，不需要在其管理的服务器上运行代理

• Cfengine is a tool in this category.
• Puppet aims to improve on Cfengine. It's got a learning curve but many find it worth the time to figure out how to do the configs. Once you've got it going, each box checks the central server periodically and makes sure everything is up to date. If someone edits a file or changes a permission, this is detected and corrected. So, unlike the deployment tools above, Puppet not only puts files in the right place for you, it ensures they stay that way.
• Chef is a little younger than Puppet with a similar approach.
• Smartfrog is another tool in this category.
• Ansible works with plain YAML files and does not require agents running on the servers it manages

为了比较这些类别中的更多工具，请参阅维基百科文章开源配置管理软件的比较。

For a comparison of these and many more tools in this category, see the Wikipedia article, Comparison of open source configuration management software.

这篇关于部署工具和最佳做法脚本生产？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！