在我们的环境中,我们在 30 多台服务器上使用了各种脚本。目前,我们在安装操作系统时将脚本复制到每台服务器上。然而,这样做的问题是,更改脚本需要手动重新部署。
我正在考虑设置 NFS 导出,但这有一些缺点:
- 我的印象是,NFS 导出即使不使用也会消耗网络资源。
- 当我从 NFS 挂载 /scripts 目录时,它将隐藏任何本地脚本。
- 权限。这些机器都有本地(基于文件的)用户和组。
- 如果 NFS 出现故障,脚本就会消失。
我考虑过的其他选项是 Subversion(或任何源代码控制)、rsync 和 rpm。svn 的好处是可以控制脚本的版本。rsync 很简单,允许使用本地脚本。由于我们的 Solaris 服务器,我认为 rpm 不起作用。
我们有 Solaris、Redhat Enterprise Linux 和 Suse Linux 服务器,并且只有少量(~10)小脚本需要部署,因此越简单越好。
答案1
考虑:Puppet、Bcfg2、Cfengine。
答案2
我们使用 subversion 开发本地脚本,然后使用 RPM 部署它们 - 一个简单的构建脚本(也作为我们脚本包的一部分进行维护)提取 SVN 导出并运行它在那里找到的 RPM 规范文件。然后将结果部署到我们的本地 yum 存储库,所有机器都可以从该存储库提取它,使用自动更新或手动,具体取决于机器的类型(开发、暂存、生产等)。
在我目前的公司中,我们只使用 RHEL/CentOS 服务器,因此单个 yum repo 就足以满足我们的需求,但在之前的公司中,我曾构建过类似的设置,输出 RHEL(yum repo)和 Mandriva(urpmi repo)的 RPM、Solaris 的自解压 tgzs 以及 Windows 的可执行安装程序(NSIS 可用于在进行所有构建的同一 Linux 服务器上构建安装程序包)。
一旦您有了自解压的 tgz,只需进行 SSH 调用即可自动将其部署到您的 Solaris 机器上。
答案3
- 我不知道你从哪里得到这种印象。我以前从未遇到过这样的问题。我怀疑即使是微不足道的 10Mbps 速度也不会让人望而却步。
- 您可以通过将本地脚本放入 /usr/local/bin/ 来解决这个问题
- 这听起来确实是一个问题。但您可以通过创建用于登录的身份验证服务器或在每台机器上设置标准用户名和用户 ID 号来解决这个问题。
如果您的设置如此之小,那么 Subversion 可能有点过分。同时,它还提供变更管理,这是良好系统管理的支柱之一。
答案4
我们的情况类似,大约有 30 台服务器,有 15-25 个脚本需要分发,还有其他软件包。我们在实验室中使用 SVN、使用 yum 进行分发以及在实际服务器上使用 RPM 进行软件包维护,取得了非常好的效果。
棘手的部分是自动化 RPM 构建,因为它会耗费时间。每次发现错误时,您都需要在本地解决它,然后在 RPM 上制作新版本以进行安装,否则您将失去所有的魔力。
虽然 Puppet 或 Bcfg2 似乎是不错的选择,但我们放弃了它们,因为它们似乎增加了系统的复杂性。保持简单。