web-dev-qa-db-ja.com

以前に宣言されたPuppetリソースのパラメーターのオーバーライド

Nwallerの sssd puppet module を完全にLDAPベースにし、少しクリーンにするように再構築しようとしています。その中に、フォームの認証ドメインごとに定義されたリソースがあります

define sssd::domain ( 
  $domain = $name,
  $domain_description = '',
  $domain_type,
  $ldap_uri = 'ldap://example.com',
  $ldap_search_base = 'dc=example,dc=com',
  $simple_allow_groups,
....
)

次に、この定義はconcat::fragmentとして渡され、最終的なsssd.confを構築するためのテンプレートに入力されます。

次のように、各ノード内でLDAPサーバーを定義すると、これはすべてうまく機能します。

nodes.pp

node "node1.systems.private" {
  include "puppet::client"
  class {
    'sssd':
      domains => [ 'LDAP' ],
      make_home_dir => true;
  }
  sssd::domain { 'LDAP':
    domain_type            => 'ldap',
    ldap_uri               => 'ldaps://ldap.site.com:636',
    ldap_search_base       => 'DC=site,DC=com',
    ldap_user_search_base  => 'OU=People,DC=site,DC=com',
    ldap_group_search_base => 'OU=Groups,DC=site,DC=com',
    ldap_default_bind_dn   => 'CN=bindaccount,OU=Service Accounts,OU=People,DC=site,DC=com',
    ldap_default_authtok   => 'soopersekretbindpw',
    simple_allow_groups    => ['SysAdmins','AppAdmins'],
  }
}

私がむしろやりたいのは、はるかに階層的な設定です。 sssd::domain定義をできるだけ一般的なものにして、組織の構成に関係なくモジュールとして維持できるようにします。グローバル構成でLDAPサーバーを定義してから、各ノード内でアクセスが必要な特定のグループを定義します。つまり、次のようなものです。

modules/org/manifests/default.pp

class org::default {
  include "puppet::client"
  class {
    'sssd':
      domains => [ 'LDAP' ],
      make_home_dir => true;
  }
  sssd::domain { 'LDAP':
    domain_type            => 'ldap',
    ldap_uri               => 'ldaps://ldap.site.com:636',
    ldap_search_base       => 'DC=site,DC=com',
    ldap_user_search_base  => 'OU=People,DC=site,DC=com',
    ldap_group_search_base => 'OU=Groups,DC=site,DC=com',
    ldap_default_bind_dn   => 'CN=bindaccount,OU=Service Accounts,OU=People,DC=site,DC=com',
    ldap_default_authtok   => 'soopersekretbindpw',
  }
}

nodes.pp

node "node1.systems.private" {
  include "org::default"

  sssd::domain { 'LDAP':
    simple_allow_groups    => ['SysAdmins','AppAdmins'],
  }
}

予想どおり、これにより、定義を適用しようとしたときに重複宣言エラーが発生します。これを行う方法、パラメーターを選択的にオーバーライドする方法はありますか、それとも元の定義内で認証ドメインを定義してから、各ノード内の承認パラメーターをオーバーライドすることに固執していますか？

authenticationpuppetsssd
5
Scott Pack

Hieraを使用します： http://docs.puppetlabs.com/hiera/latest/

Hieraを使用すると、変数データをPuppetマニフェストから切り離すことができます。

Hieraは、その名前が示すように階層的であり、変数データをオーバーライドしたり結合したりするためのいくつかの興味深い方法を可能にします。

まず、sssd ::ドメイン宣言を変更して、パラメーターのHieraルックアップを実行します。

sssd::domain { 'LDAP':
    domain_type            => 'ldap',
    ldap_uri               => hiera('ldap_uri', 'ldaps://ldap.site.com:636'),
    ldap_search_base       => hiera('ldap_search_base', 'DC=site,DC=com'),
    ldap_user_search_base  => hiera('ldap_user_search_base', 'OU=People,DC=site,DC=com'),
    ldap_group_search_base => hiera('ldap_group_search_base', 'OU=Groups,DC=site,DC=com'),
    ldap_default_bind_dn   => hiera('ldap_default_bind', 'CN=bindaccount,OU=ServiceAccounts,OU=People,DC=site,DC=com'),
    ldap_default_authtok   => hiera('ldap_default_authtok', 'soopersekretbindpw'),
    simple_allow_groups    => hiera_array('ldap_simple_allow_groups', ['SysAdmins','AppAdmins']),
}

上記のコードでは、各ルックアップのデフォルト値を定義しました。必要に応じて、最も一般的なHieraデータファイル（通常は「common.yaml」または「common.json」）にデフォルトを設定することで、これらを除外できます。

common.yaml：

---
ldap_uri: ldaps://ldap.site.com:636
ldap_search_base: DC=site,DC=com
ldap_simple_allow_groups:
 - SysAdmins
 - AppAdmins

ホストごとにパーソナライズするビットについては、問題のホストのFQDNにちなんで名付けられたYAMLまたはJSONファイルを作成し、そこに必要な値を入力します。

node1.systems.private.yaml：

---
ldap_simple_allow_groups:
 - SomeOtherGroup

この例では、ldap_simple_allow_groupsがhiera_arrayルックアップ関数を使用していることに注意してください。これにより、階層内のすべての有効な検出結果が連結されます。そのため、node1は、common.yamlで定義された値と、独自のYAMLファイルで定義された「SomeOtherGroup」を取得します。

詳細については、Hieraルックアップタイプのドキュメントをお読みください。 http://docs.puppetlabs.com/hiera/latest/lookup_types.html

5
Scott Merrill

Hieraが最善の方法であり、当然受け入れられていますが、完全を期すために追加したいと思います。念頭に置いていたこのオーバーライドを実行するための構文があります。

node "node1.systems.private" {
  include "org::default"

  Sssd::Domain<| title == 'LDAP' |> {
    simple_allow_groups => ['SysAdmins','AppAdmins'],
  }
}

この構文は 仮想リソースの収集 にも役立ちますが、リソースパラメータを上書きするために使用される可能性があることに注意してください。

明らかに、この手法を使用すると混乱が生じるため、ほとんどの場合、Hieraの方が優れています。

3
Felix Frank