Кукла: условное определение типов

Кукла: условное определение типов

Я не уверен, как сформулировать этот вопрос, поэтому, пожалуйста, предложите правку, если вы считаете ее неуместной.

Я пытаюсь расширить существующие модули puppet поддержкой разных ОС. Я столкнулся с небольшой проблемой, которую не уверен, как решить элегантным способом. В params.ppфайле есть такое определение пакетов, специфичных для ОС, для установки:

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

Модуль написан таким образом, что вся конфигурация зависит от установки $php_package_name. Я хочу расширить этот модуль для другой ОС, в которой нет отдельного пакета mysql для php, поэтому я устанавливаю $php_package_nameпеременную в undef. Это приводит к проблеме, что puppet пытается установить Package[undef].

Какой был бы хороший способ предотвратить это? Мои мысли пока что ставят его на ложь и имеют полное определение $php_package_nameогня только if $php_package_name != false. Может быть, есть лучший способ?

решение1

Да, это кажется разумным подходом. Я бы предложил небольшую вариацию, добавить новый параметр, который определяет, следует ли вообще применять packageресурс, который использует :$php_package_name

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

Тогда где находится ресурс:

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

Имейте в виду, что метод выполнения всех ваших специфичных для ОС вещей в params.pp может оказаться не таким уж чистым, если ресурсы, необходимые для установки на новой ОС, сильно отличаются; это может просто превратить ваш файл манифеста в нечитаемое крысиное гнездо условий и параметров. В этом случае не бойтесь просто разделить другую ОС на отдельный класс (например, install_el.ppдля семейства RedHat и install_otheros.ppдля нового семейства, при этом правильный класс будет включен из init.ppили params.pp).

Связанный контент