我们使用Ruby，Collectd，Ant，Java（以及更多）的版本，这在CentOS或EPEL版本中是不可用的。 到目前为止，我们的安装策略一直是一种破坏：
为每个包编写一个（版本控制的）脚本，将源代码或二进制代码通过curl下载到Puppet主机上，并在必要时编译源代码; 重新包装成gzipped tarball，如果有必要的话
使用Puppet文件服务器将二进制文件分发到我们的服务器，而Puppet则清除了在/ usr / local（或任何地方）
编写脚本可能会很痛苦，如果我们依赖下载的站点之一更改其API，则必须更新它们。 同样，软件在每个环境中分别编译，这看起来很浪费，并且可能会导致编译时依赖项缺失的问题（例如，Ruby：require'readline'或者'yaml'可能在某些环境中工作，
所以，我可以想到另外两个select：
只需将定制的第三方二进制文件检入到Subversion中，并将其与我们其余的Puppet代码一起分发即可。 我担心这会严重影响结账和木偶代码的性能， 我们正在研究将近800MB（和不断增长的）第三方代码。 再加上它只是感觉不对，像Java的多版本和体系结构并行版本控制。
不要版本控制二进制文件或编写下载脚本 – 当我们决定升级Ruby时，在开发箱上进行编译，并在我们决定升级时，将新软件包手动上传到我们所有的Puppet master。 除此之外，如果包裹被</s>灭了呢？ 或在不同的主人不同步？ 现在我们可以轻松地从头开始重新生成所有的定制软件包。
哪三种select更好？ 人们通常如何使用Puppetpipe理自定义编译/重新打包的第三方软件？ 如果您创build了本地Yum存储库，那么您是否使用版本控制来创buildRPM？ 如果你的Yum回购消灭，会发生什么？
Puppet并不是真正用来分发大文件的，所以你应该这样做。 最好的方法是将自定义/第三方软件打包为RPM，并托pipe您自己的RPM存储库。 RPM包装（即spec文件和补丁）理想情况下应该受版本控制，并且RPM存储库备份或托pipe在多台机器上。
我强烈build议使用Yum知识库来部署所有的软件，包括你编译的软件。 一旦正确configuration，你将得到所有的依赖性问题，版本控制等。
我的学习是为我的知识库build立一个三分支系统（dev，qa，prod）。 这允许给定的系统被添加到不同的存储库并相应地运行。
我通过Puppet来做到这一点（以及对yum更新的调度）。
回应另外两个答案：使用您的发行版现有的包pipe理系统。
我们这样做与Ubuntu和apt安装RabbitMQ和OAuth这样的：
class apt::example { file { "/etc/apt/sources.list.d/repo.example.list": source => "puppet:///modules/apt/repo.example.list", ensure => present, } exec {"install-gpg-key": command => "/usr/bin/curl -s http://repo.example.com/[email protected] | /usr/bin/apt-key add -; /usr/bin/apt-get update", refreshonly => true, subscribe => File["/etc/apt/sources.list.d/repo.example.list"], require => File["/etc/apt/sources.list.d/repo.example.list"], } }
并使用回购：
class apache2::platform { package { ["librabbitmq0", "php5-amqp", "php5-oauth"]: ensure => installed, notify => Service["apache2"], require => File["/etc/apt/sources.list.d/repo.example.list"] } [...] }
这里的require确保在我们尝试从它安装任何东西之前添加回购。
可能有更好的方法来处理添加GPG键和运行和更新，因为这个命令返回一个正面的退出代码，导致puppet认为失败，但是因为它的工作原理，我没有花费太多的精力来修复虚假的错误消息。
我没有试图添加回购configurationpuppet或自动化的构build和添加到新软件包的回购进程，但一旦你达到一定的规模，这些任务将是值得的。 备份总是值得的。
RPM和yum的过程应该非常相似。