作为一个例子,我们通常认为在将系统借给木偶管理之前已经建立了主机名.至少在用于接触puppetmaster的网络上的基本IP连接必须正常工作.使用puppet自动创建dns区域文件很诱人,但是在启动之前应该已经存在DNS反向指针,或者证书会很有趣.
那么我应该从木偶中省略IP配置吗？或者我应该在第一次启动puppet之前进行设置,但是仍然使用puppet管理ip地址？具有多个IP的系统(例如WAN,LAN和SAN)如何？
IPMI怎么样？您可以使用ipmitool配置大部分(如果不是全部)它,从而使您无法获得控制台访问权限(物理,LAN上串行,远程KVM等),因此可以使用puppet进行自动化.但是在每个木偶代理运行中重新检查它的状态对我来说听起来并不酷,并且在做任何其他事情之前我想要的基本灯光访问系统.
另一个故事是关于安装更新.我不是在这个特定的点上,已经有很多关于SF的问题以及不同系统管理员之间的许多不同的哲学.我自己,我决定不让木偶更新东西(例如,只确保=>安装)并按照我们已经习惯的方式手动进行更新,将此任务的自动化留给我们对木偶更有信心的日子(例如.通过添加MCollective混合).
这些只是我现在想到的几个例子.
该系统的任何方面是否应该被傀儡所忽视？
或者,换句话说,在配置时应该设置什么和在系统中“静态”配置之间的界限,以及通过集中配置管理处理什么？
解决方法
具体的例子(从问题中解决,所有“这就是你想要管理它的原因”叙述)：
IP网络配置
确定,在将机器放入机架之前,您已在机器上配置了地址/网关/ NS.我的意思是,如果你不是如何运行puppet来完成配置的其余部分？
但是现在说你在你的环境中添加了另一个名称服务器,你需要更新你的所有机器 – 你不希望你的配置管理系统为你做这个吗？
或者说你的公司被收购了,你的新母公司要求你从192.168.0.0/24地址改为10.11.12.0/24以适应他们的编号系统.
或者你突然得到一份巨额的政府合同 – 只有赶上你现在必须打开IPv6 RIGHT FREAKIN,否则这笔交易就会被打破….
看起来网络配置是我们想要管理的……
IPMI配置
就像使用IP地址一样,我确定你在将机器放入机架之前进行了设置 – 在具有此功能的任何机器上启用IPMI,远程控制台等,这是一个很好的常识,这些配置不是变化不大……
…在我上面的IP配置中提到的那个假设的收购之前 – 你被迫腾出那些192.168网络地址的原因是因为根据你的新公司霸主的IPMI-land,你需要更新你所有的IPMI卡现在,因为他们将践踏某人保留的IP空间.
好吧,这里有点延伸,但就像你说的那样 – 所有这些都可以通过ipmitool进行管理,那么为什么不让Puppet运行该工具并在完成所有其他工作时确认配置？我的意思是它不会伤害任何东西,所以我们也可以包括IPMI ……
更新
软件更新更像是一个灰色区域 – 在我的组织中,我们为此评估了木偶并发现它“非常缺乏”,因此我们使用radmind来实现此目的. Puppet没有理由不能调用radmind – 事实上,如果/当我们迁移到Puppet进行配置管理时,那将会发生什么！
这里重要的是以标准方式安装所有更新(整个组织的标准或平台内的标准) – 只要您经过全面测试,Puppet就不应该启动更新过程一切都是为了确保Puppet不会搞砸任何东西.如果你已经确定Puppet不能自己做好工作,那么Puppet也没有理由不能召唤出更适合这项任务的工具……
