主页 / server / 问题 / 414758
Accepted
Luke404
Asked: 2012-08-07 08:42:34 +0800 CST

傀儡不应该管理什么？

  • 772

我正在通过一般的配置管理学习我的方式，并特别使用puppet来实现它，我想知道系统的哪些方面（如果有的话）不应该用 puppet 管理？

例如，我们通常认为主机名在将系统借给 puppet 管理之前就已经设置好了。基本 IP 连接，至少在用于连接 puppetmaster 的网络上，必须正常工作。使用 puppet 自动创建 dns 区域文件很诱人，但 DNS 反向指针应该在启动之前就已经到位，否则证书会很有趣。

那么我应该从 puppet 中省略 IP 配置吗？或者我应该在第一次启动 puppet 之前设置它，但仍然使用 puppet 管理 ip 地址？具有多个 IP 的系统（例如 WAN、LAN 和 SAN）怎么样？

IPMI呢？您可以使用ipmitool配置大部分（如果不是全部） ，从而避免获得控制台访问（物理、串行局域网、远程 KVM 等），因此可以使用 puppet 实现自动化。但是在每次 Puppet 代理运行时重新检查它的状态对我来说听起来并不酷，而且我希望在执行任何其他操作之前能够基本关闭对系统的访问权限。

另一个完整的故事是关于安装更新。我不打算讨论这个具体点，已经有很多关于 SF 的问题以及不同系统管理员之间的许多不同哲学。我自己，我决定不让 puppet 更新东西（例如，仅ensure => installed），而是像我们已经习惯的那样手动更新，将此任务的自动化留到以后我们对 puppet 更有信心时（例如，通过将MCollective添加到混合）。

这些只是我现在想到的几个例子。系统中是否有任何方面是 Puppet 无法触及的？或者，换句话说，应该在供应时设置什么和在系统中“静态”配置什么与通过集中配置管理处理什么之间的界线在哪里？

linux

6 个回答

  1. Best Answer

    一般规则：如果您正在使用配置管理，请尽可能管理配置的各个方面。您越集中，就越容易扩展您的环境。

    具体例子（摘自问题，所有“这就是你想要管理它的原因”的叙述）：

    IP网络配置

    好的，当然，您在将机器放入机架之前在机器上配置了地址/网关/NS。我的意思是，如果您不这样做，您将如何运行 puppet 来完成其余的配置？

    但是假设现在您向您的环境中添加了另一个名称服务器并且您需要更新所有机器——您不希望您的配置管理系统为您做这件事吗？

    或者假设您的公司被收购，您的新母公司要求您将地址从 192.168.0.0/24 更改为 10.11.12.0/24 以适应他们的编号系统。

    或者您突然获得了一份庞大的政府合同——唯一的问题是您必须立即启用 IPv6 RIGHT FREAKIN'否则交易就失败了……

    看起来网络配置是我们想要管理的东西......

    IPMI配置

    就像 IP 地址一样，我确定您在将机器放入机架之前就已经设置好了——在任何具有此功能的机器上启用 IPMI、远程控制台等是很好的常识，而这些配置不会变化不大...

    ...直到我在上面的 IP 配置中提到的那个假设的收购——你被迫腾出那些 192.168 网络地址的原因是因为根据你的新公司霸主，那是 IPMI 土地，你需要去更新你所有的 IPMI 卡现在，因为他们将要践踏某人的保留 IP 空间。

    好的，这里有点牵强，但正如您所说 - 所有这些都可以使用 进行管理ipmitool，那么为什么不让 Puppet 在执行所有其他操作时运行该工具并确认配置呢？我的意思是它不会造成任何伤害，所以我们也可以包括 IPMI ...

    更新

    软件更新更像是一个灰色地带——在我的组织中，我们为此评估了 puppet，发现它“非常缺乏”，因此我们将radmind其用于此目的。Puppet 没有理由不能调用 radmind——事实上，如果/当我们迁移到 Puppet 进行配置管理时，这正是将要发生的事情！

    这里重要的是以标准方式安装所有更新（跨组织的标准，或平台内的标准）——没有理由 Puppet 不应该启动你的更新过程，只要你已经彻底测试过确保 Puppet 不会搞砸任何事情的一切。
    如果您确定 Puppet 不能靠自己做好工作，那么 Puppet 也没有理由不能调用更适合此任务的工具......

    • 26

  2. 不要重新发明轮子。

    是的，您可以拥有 50 个 puppet 虚拟用户资源并根据需要在您的模块中实现它们……但是如果可以的话，请使用 LDAP。

    我是从痛苦的经历中说出来的。虽然 ldap 在这里不是一个选项，但是。

    另一个例子是推出主机文件，而不仅仅是使用 DNS。

    • 11
    • Puppet 不是编排系统。尤其是：
      • Puppet 不太适合 VM 编排，因为 VM 有自己的生命周期，应该受到尊重。
      • Puppet 不太适合应用程序发布管理/复杂的升级。可以为此利用独立的人偶运行，但至少它不是 Puppet 控制的，而是你的包装脚本或人类机器人，这很好。
    • Puppet 不是一个好的用户管理系统（它必须管理每个用户条目，甚至删除的用户，才能有效。所以找到另一个解决方案）
    • Puppet 不是一个好的配置数据库（看看使用某种外部数据库，以及 ENC、Hiera 或类似的胶水）

    当然，您可以使用 Puppet 完成所有这些事情……但这并不是他们的最佳解决方案。有时你应该放下锤子，去找扳手。

    然而，Puppet 非常擅长维护机器的基本配置，以及安装让您执行 VM 和发布编排、用户管理等的工具。

    • 8

  4. 就我而言，我有一个加载最小系统配置 (Ubuntu) 的引导脚本：Ruby、Rubygems、build-essential、git 等。我的 Puppet 清单受版本控制，我只需克隆存储库。从那里开始，我的引导程序脚本做出了一个有效的假设hostname --short，并尝试puppet apply /root/infrastructure/puppet/hosts/$( hostname --short ).pp.

    回答你的问题：

    • 我的脚本假定基本的网络连接（DNS、IP），并且不管理或更改它；
    • 我的脚本假设机器的身份是正确的，并且不改变它；
    • 我的脚本假定存在 Ruby / Rubygems / Git，但之后会对其进行管理。
    • 2

  5. 我基本同意 voretaq7，但有几点需要注意。

    • 我很少在 puppet 中配置 IP 寻址，除非系统使用 DHCP（我假设大多数大型“云”提供商都这样做）。我遇到过用 puppet 破坏网络配置的情况，但无法用 puppet 纠正它们，因为节点没有任何方式联系 puppetmaster。

    • 我坚信更新管理属于系统工具，我不认为使用 puppet 作为美化的 cron 是一种改进。

    • 2

  6. 认为您不需要使用 puppet 进行网络配置。它通常是一次配置的东西。如果您对 IP 或 MAC 或木偶带来的类似问题有错误，您也会得到一些废话。

    • 0

相关问题