傀儡继承VS木偶组成

Question

我最近刚刚来到了傀儡遗产.围绕它的一些问题:

1. 使用傀儡继承是一种好习惯吗？一些有经验的傀儡同事告诉我,傀儡中的遗传不是很好,我不太相信.

2. 来自OO世界,我真的想在封面下理解,傀儡继承是如何运作的,如何压倒一切也是如此.

Answer 1

1. 这取决于,因为有两种类型的继承,你没有提到你的意思.

   1. 节点继承:从一个node fqdn { }定义继承到另一个定义.特别强烈建议不要这样做,因为它往往会失败的意外原则.吸引人们的典型例子是:

      node base {
        $mta_config = "main.cf.normal"
        include mta::postfix  # uses $mta_config internally
      }
      node mailserver inherits base {
        $mta_config = "main.cf.mailserver"
      }
      

      该$mta_config变量在基本范围内进行评估,因此在邮件服务器中尝试的"覆盖"不起作用.

      没有办法直接影响父节点中的内容,因此对构图的好处不大.通过从两者中删除继承和包含mta::postfix(或另一个"common"/"base"类)来修复此示例.然后,您也可以使用参数化类.

   2. 类继承:类继承的用途是可以覆盖父类中定义的资源的参数.以这种方式重新实现上面的例子,我们得到:

      class mta::postfix {
        file { "/etc/postfix/main.cf":
          source => "puppet:///modules/mta/main.cf.normal",
        }
        service { ... }
      }
      
      class mta::postfix::server inherits mta::postfix {
        File["/etc/postfix/main.cf"]:
          source => "puppet:///modules/mta/main.cf.server",
        }
        # other config...
      }
      

      这确实有效,但我会避免深入到一个以上的继承级别,因为它变得很难维护.

   3. 但是,在这两个示例中,通过提前指定数据(通过ENC)或通过extlookup或hiera内联查询数据,可以轻松改进它们.

2. 希望上面的例子有所帮助.类继承允许仅覆盖参数 - 您无法删除以前定义的资源(常见问题).始终使用大写类型名称(file { ..: }将成为File[..])引用资源.

   同样有用的是,您还可以定义参数undef,有效地取消它们.