0

3 つのプロパティ ファイルに依存する Java で実装されたサービスがあります。共通プロパティ モジュール内のプロパティ ファイルごとに「定義」を定義し、サービス固有のモジュールからそれらを使用しています。プロパティ ファイルの 1 つの「定義」を以下に示します。

define properties::rabbitmq (
  $property_file,
  $service_name,
  $rabbitmq_host,
  $rabbitmq_username,
  $rabbitmq_password,
  $rabbitmq_port,
  $rabbitmq_vhost) {
  file { $property_file:
    ensure  => file,
    content => template('config/rabbitmq.properties.erb'),
    mode    => '0644',
    notify  => Service[$service_name],
  }
}

パペット コードで役割とプロファイル パターンに従っており、サービス固有のプロファイルですべての hiera ルックアップを実行しています。このため、プロパティ ファイルが変更されるたびに、そのプロパティ ファイルを使用するすべての puppet モジュールにカスケード変更を加える必要があります。変更は、プロファイル (hiera ルックアップ)、モジュール init.pp (コンストラクターからのパラメーターの追加/削除)、および config.pp (プロパティ ファイルの「define」を呼び出すときのパラメーター調整) で必要です。

上記の問題は、次のように、プロパティ ファイルの「定義」に hiera ルックアップを組み込むことで解決できると思います。

define properties::rabbitmq ($property_file, $service_name,) {

  $rabbitmq_host = hiera('rabbitmq_host')
  $rabbitmq_username = hiera('rabbitmq_username')
  $rabbitmq_password = hiera('rabbitmq_password')
  $rabbitmq_port = hiera('rabbitmq_port')
  $rabbitmq_vhost = hiera('rabbitmq_vhost')

  file { $property_file:
    ensure  => file,
    content => template('config/rabbitmq.properties.erb'),
    mode    => '0644',
    notify  => Service[$service_name],
  }
}

ただし、上記はロールとプロファイル パターンの違反です。上記は、プロファイルで行うのではなく、モジュールで hiera ルックアップを行っています。現在、モジュールは hiera に密接に依存しています。これは内部モジュール (puppet forge 向けではない) であるため、コードの保守性を優先してガイドラインに違反しても問題ないと思います。

上記について他の方の意見を求めます。

4

0 に答える 0