☰

Marioneta: definición condicional de tipos.

tag-icon • tag-icon puppet
Marioneta: definición condicional de tipos.

No estoy seguro de cómo redactar estas preguntas, así que sugiera una edición si cree que es inapropiada.

Estoy intentando ampliar los módulos de Puppet existentes con soporte para diferentes sistemas operativos. Me encontré con un pequeño problema que no estoy seguro de cómo podría resolver de manera elegante. En params.ppel archivo existe la definición de paquetes específicos del sistema operativo para instalar:

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

El módulo está escrito de tal manera que toda la configuración depende de haberlo $php_package_nameinstalado. Quiero extender este módulo para diferentes sistemas operativos, que no tienen un paquete mysql separado para php, por lo que configuré $php_package_namela variable en undef. Esto trae un problema, que el títere intenta instalarse Package[undef].

¿Cuál sería una buena manera de prevenirlo? Mis pensamientos hasta ahora son falsos y $php_package_namesolo tienen una definición completa de fuego if $php_package_name != false. ¿Quizás haya una mejor manera?

Respuesta1

Sí, parece un enfoque razonable. Sugeriría una ligera variación al respecto, agregar un nuevo parámetro que determine si el packagerecurso que se utiliza $php_package_namedebe aplicarse:

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
  }
  ...

Entonces donde está el recurso:

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

Tenga en cuenta que el método para hacer todas las cosas específicas del sistema operativo en params.pp podría no terminar siendo más limpio si los recursos necesarios para la instalación en el nuevo sistema operativo son muy diferentes; eso podría convertir su archivo de manifiesto en un nido de condiciones y parámetros ilegibles. En ese caso, no tenga miedo de simplemente dividir los diferentes sistemas operativos en una clase separada (como install_el.pppara la familia RedHat y install_otheros.pppara la nueva familia, incluyéndose el correcto en init.ppo params.pp).

información relacionada