部署工具和应用程序的最佳实践 脚本到生产？
我有许多在 Linux/PHP 网站后台运行的批处理进程。 它们的数量和复杂性开始增长，所以我想对它们进行少量的处理。
我的源代码树有一堆 cpp 文件和脚本，它们是根据开发进行组织的，但没有考虑到部署。 编译所有可执行文件后，我需要将各种脚本和二进制文件放在机器集群上。 不同的机器需要不同的可执行文件、脚本和配置文件来进行批处理。 我还编写了一些适用于每台机器的工具。 目前，此部署过程是手动的并且容易出错。
我猜我最终会得到一个在源树的根部运行的脚本，并构建一个包含任何机器所需的一切的较小树。 然后，我会将其同步到适当的机器。 但我很好奇其他人是如何解决此类问题的。 有任何想法吗？
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.
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.
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
这里有几个类别的工具。 有些人使用这些类别的工具组合。 例如，我有时会同时使用 Puppet 和 Capistrano。 请参阅 Puppet 或 Capistrano - 使用适合工作的正确工具进行讨论。
旨在部署应用程序的脚本工具：
此类工具的一般模式是创建脚本和/或配置文件，通常使用类似于 Makefile 的命令集，并且该工具将通过 ssh转到您的生产框，检查源代码，然后运行任何其他必要的步骤。
该领域的工具通常具有回滚到先前版本的功能。 因此，如果一切顺利，他们将检查您的源代码到releases/目录，并创建从“current”到“releases/”的符号链接。 如果出现问题，您可以通过运行命令来恢复到以前的版本，该命令将删除“current”并将其链接到以前的releases/目录。
将文件放入生产盒的选项：
打包工具
使用操作系统的打包系统生成包含应用程序文件的包。 创建一个主包，其中包含您需要的其他包的依赖项。 RubyWorks 系统就是一个示例，用于部署 Rails 堆栈和示例应用程序。 然后就是使用 apt、yum/rpm、Windows msi 或其他工具来部署给定版本。 回滚涉及卸载并重新安装旧版本。
旨在安装应用程序/配置和维护一组系统的通用工具
这些工具并不专门针对部署 Web 应用程序的问题，而是针对部署/维护应用程序/配置的更普遍的问题。一组服务器或整个公司的工作站。 它们更多地针对系统管理员而不是 Web 开发人员，尽管两者都觉得它们很有用。
对于这些的比较以及此类别中的更多工具，请参阅维基百科文章开源配置管理软件的比较 。
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.
Scripting Tools aimed at Deploying an Application:
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.
Options for getting the files to the production box:
Packaging Tools
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.
General Tools Aimed at Installing Apps/Configs and Maintaining a Set of Systems
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.
For a comparison of these and many more tools in this category, see the Wikipedia article, Comparison of open source configuration management software.
查看 cfengine 教程，看看 cfengine 是否是正确的工具对于你的情况。 对于一个小型网站来说，这可能有点太复杂了，但是如果将来要涉及更多的计算机和更多的配置，在某些时候你最终会使用 cfengine 或类似的东西。
Take a look at the cfengine tutorial to see if cfengine looks like the right tool for your situation. It may be a little too complicated for a small website, but if it is going to involve more computers and more configuration in the future, at some point you will end up using cfengine or something like that.
按照您的发行版使用的格式创建您自己的软件包，例如 Debian 软件包 (.deb)。 这些可以复制到每台计算机并手动安装，或者您可以设置自己的存储库，并将其添加到源列表中。
应该设置您的包，以便它们包含的脚本参考配置文件，该文件在每个主机上都不同，具体取决于每个主机上需要运行的脚本。
为了将它们结合在一起，您可以创建一个元包，该元包仅依赖于您创建的每个其他包。 这样，当您设置一台新服务器时，您将安装该元包，并且其他包将作为依赖项引入。
虽然这个过程听起来有点复杂，但如果您有很多脚本和很多要部署它们的主机，从长远来看，它确实可以带来回报。
Create your own packages in the format your distribution uses, e.g. Debian packages (.deb). These can either be copied to each machine and installed manually, or you can set up your own repository, and add it to your list of sources.
Your packages should be set up so that the scripts they contain consult a configuration file, which is different on each host, depending on what scripts need to be run on each.
To tie it all together, you can create a meta package that just depends on each of the other packages you create. That way, when you set up a new server, you install that one meta package, and the other packages are brought in as dependencies.
Although this process sounds a bit complicated, if you have many scripts and many hosts to deploy them to, it can really pay off in the long run.
我必须经常向多个客户推出 PHP 脚本和 Apache 配置。 由于他们都运行 Debian Linux，因此我在我的服务器上设置了 Debian 软件包存储库，客户所需要做的就是输入 apt-get update，他们就可以获得最新版本。
I have to roll out PHP scripts and Apache configurations to several customers on a frequent basis. Since they all run Debian Linux, I've set up a Debian package repository on my server and the all the customer has to do is type apt-get upgrade and they get the latest version.
首先要做的是将所有这些脚本放入源代码控制存储库（svn 或 git 都不错），以便您可以跟踪这些脚本随时间的变化。
如果您对 ruby 感兴趣，请查看 Capistrano，它非常适合将事物部署到集群中的多台计算机，并且设置起来相当容易。 它可以直接从版本控制系统读取文件。
The first thing to do is get all these scripts into a source control repository (svn or git are good) so that you can track changes to these scripts over time.
If you are interested in ruby, check out Capistrano, it is well suited deploying things to multiple machines in a cluster, and is fairly easy to set up. It can read files directly from your version control system.
Puppet 是另一种可以在这种情况下使用的工具。 它与 cfengine 类似 - 您创建所需部署的模型，然后 Puppet 计算出如何使环境达到此状态。
Puppet is another tool that can be used in this situation. It is similar to cfengine - you create a model of the desired deployment and Puppet figures how to get the environment to this state.