☰

Puppet: bedingte Definition von Typen

tag-icon • tag-icon puppet
Puppet: bedingte Definition von Typen

Ich bin nicht sicher, wie ich diese Frage formulieren soll, schlagen Sie daher bitte eine Änderung vor, wenn Sie der Meinung sind, dass sie unangemessen ist.

Ich versuche, vorhandene Puppet-Module mit Unterstützung für verschiedene Betriebssysteme zu erweitern. Dabei bin ich auf ein kleines Problem gestoßen und bin mir nicht sicher, wie ich es auf elegante Weise lösen könnte. In der params.ppDatei gibt es folgende Definition der zu installierenden betriebssystemspezifischen Pakete:

case $::osfamily {
  'RedHat': {
    $package_server = 'mariadb-server'
    $package_client = 'mariadb'
    $php_package_name = 'php-mysql'
  }
...

Das Modul ist so geschrieben, dass die gesamte Konfiguration von der $php_package_nameInstallation abhängt. Ich möchte dieses Modul für verschiedene Betriebssysteme erweitern, die kein separates MySQL-Paket für PHP haben, daher setze ich $php_package_namedie Variable auf undef. Dies führt zu einem Problem, da Puppet versucht, zu installieren Package[undef].

Wie könnte man das am besten verhindern? Bisher habe ich daran gedacht, es auf „false“ zu setzen und die gesamte Definition $php_package_namenur auf „fire“ zu setzen if $php_package_name != false. Vielleicht gibt es einen besseren Weg?

Antwort1

Ja, das scheint ein vernünftiger Ansatz zu sein. Ich würde eine leichte Variation davon vorschlagen, füge einen neuen Parameter hinzu, der bestimmt, ob die packageverwendete Ressource $php_package_nameüberhaupt angewendet werden soll:

case $::osfamily {
  'RedHat': {
    $package_server = 'mariadb-server'
    $package_client = 'mariadb'
    $php_package_name = 'php-mysql'
    $php_package_install = true
  }
  'otherOS': {
    $package_server = 'mariadb-server'
    $package_client = 'mariadb'
    $php_package_install = false
  }
  ...

Dann wo sich die Ressource befindet:

if $thismodule::params::php_package_install {
  package { $thismodule::params::php_package_name:
    ensure => present,
    ...
  }
}

Bedenken Sie, dass die Vorgehensweise zum Ausführen aller betriebssystemspezifischen Aufgaben in params.pp möglicherweise nicht sauberer ist, wenn die für die Installation auf dem neuen Betriebssystem erforderlichen Ressourcen völlig unterschiedlich sind. Dadurch wird Ihre Manifestdatei möglicherweise zu einem unlesbaren Wirrwarr aus Bedingungen und Parametern. Scheuen Sie sich in diesem Fall nicht, die verschiedenen Betriebssysteme einfach in eine separate Klasse aufzuteilen (z. B. install_el.ppfür die RedHat-Familie und install_otheros.ppdie neue Familie, wobei die richtige von init.ppoder eingeschlossen wird params.pp).

verwandte Informationen