Дайте этому движение
# In stripdown.pp :
class stripdown {
service { "mysql":
enable => "false",
ensure => "stopped"
}
}
# In mysql.pp :
class mysql::server inherits stripdown {
Service["mysqld"] {
enable => true,
ensure => running,
hasrestart => true,
hasstatus => true,
path => "/etc/init.d/mysql",
require => Package["mysql-server"],
}
}
# Then nodes in nodes.pp :
node basenode {
include stripdown
}
node myserver.local inherits basenode {
include mysql::server
}
Делайте попытку с этим:
# In stripdown.pp :
class stripdown {
service { "mysql":
enable => "false",
ensure => "stopped"
}
}
# In mysql.pp :
class mysql::server {
if defined(Service["mysql"]) {
Service["mysql"] {
enable => true,
ensure => running,
hasrestart => true,
hasstatus => true,
path => "/etc/init.d/mysql",
require => Package["mysql-server"],
}
} else {
service { "mysql":
enable => true,
ensure => running,
hasrestart => true,
hasstatus => true,
path => "/etc/init.d/mysql",
require => Package["mysql-server"],
}
}
}
# Then nodes in nodes.pp :
node basenode {
include stripdown
}
node myserver.local inherits basenode {
include mysql::server
}
Это, конечно, идет с протестом, что Вам уже определили Пакет ["mysql-сервер"], в другом месте было это, перестанет работать, как записано без него из-за Вашего require
операторы.
Другая ошибка, которую я нашел, состояла в том, что у Вас было слишком много пробелов после опций. Там опции в строке файла конфигурации должны быть выровненные не больше, чем 1, располагают с интервалами больше, чем самое длинное имя опции.
Одной вещью, на которую можно хотеть посмотреть, является Виртуальный Ressources для обхождения повторного определения ресурсов. Документация относительно той темы может быть найдена: http://reductivelabs.com/trac/puppet/wiki/VirtualResources
Конечно, другой путь был бы к простому, создают объекты узла для каждого хоста, который не выполняет mysql и затем загружает разделенный класс там.
Каждый раз, когда Вы говорите, "Я хочу, чтобы этот компонент вел себя один путь в одном узле, но другой путь в другом узле", вероятно, необходимо смотреть на определение, управляемое переменными, или через условные выражения в определении класса или через замены в шаблоне.
К сожалению, Ваш пример показывает Вам пытающийся использовать наследование, которое довольно плохо повреждается в марионетке и вызовет Вас много горя здесь, потому что одной из вещей, которые это повреждает, является переменное переопределение в узлах.
ОБНОВЛЕНИЕ: старые детали ответа являются устаревшими
То, что я делаю с 2,7, должно гарантировать, что все переменные, используемые классом, не являются глобальными переменными вообще, а скорее параметрами с разумным набором значений по умолчанию. Вы все еще не хотите использовать наследование, встроенное в Марионетку, но можно теперь переопределить конкретные переменные непосредственно из определения узла, и у Вас может даже быть примитивная форма наследования вручную при наличии одного класса, берут переменные и затем передают их вызову другого класса. Например, Вы имели бы в своих определениях узла:
node experimental_server {
# This will still call class 'databases', but will install Postgresql and not Mysql
# as a default. You can still override it the same way as with 'databases'
class { 'mydept::nextgeneration': },
}
node server_with_mysql {
class { 'databases':
mysql_enabled => true,
}
}
node server_with_no_db {
class { 'databases': # this installs only the clients }
}
class databases (
# By default, install no servers, just clients
$pgsql_enabled => false,
$mysql_enabled => false
)
{
...
}
class mydept::nextgeneration (
# If not explicitly overridden, an undef value passed as a parameter to a class
# assumes the default value in that class
$mysql_enabled => undef,
$pgsql_enabled => true
)
{
class { 'databases':
mysql_enabled => $mysql_enabled,
pgsql_enabled => $pgsql_enabled,
}
}
Как комментатор отметил, существует теперь также изящная новая возможность под названием Hiera, который позволяет Вам разгружать значения по умолчанию в отдельную структуру данных, и необходимо изучить его, если Вы имеете Марионеточные 3.2 в наличии. К сожалению, много дистрибутивов Linux все еще поставлются с 2,6 или 2.7, таким образом, это еще не может быть опцией для Вас.
Предыдущие детали ответа, сохраненные ниже
Способ, которым я обычно обрабатываю что-то вроде этого, состоит в том, чтобы создать 'default_parameters.pp' файл, который ничего не имеет в нем кроме присвоений по умолчанию для длинного списка переменных, так в этом случае, он содержал бы строку что-то как $mysql_enabled = false
. Этот файл затем включен init.pp файлом модуля. Затем файл определений узла посмотрел бы что-то как:
import "mymodule"
node myserver.local { # NOTE: no inheritance!
$mysql_enabled = true
include mysql::server
}
node otherserver.local {
include mysql::server
}
Затем в определении класса для mysql:: сервер Вы проверяете если $mysql_enabled
верно, и если так, используйте селектор на enable
и ensure
.
Это повреждается немедленно, если узел myserver.local наследовал что-нибудь, потому что это заблокирует значение переменных в, наследовали время, и дальнейшие изменения в определении узла не будут иметь никакого эффекта, но иначе я использую эту технику повсеместно, чтобы иметь отдельные компоненты, ведут себя по-другому, не генерируя несколько классов.
Если у Вас абсолютно должно быть наследование, но список машин с включенным mysql является маленьким, можно следовать альтернативным маршрутом: вместо того, чтобы установить переменную в определении узла, создайте свой селектор прочь $fqdn
, со значением по умолчанию для отключения, и выбрал включенный fqdns.
mysql::server
не имеет отношений сstripdown
класс. И кроме тогоmysql::server
уже наследовал классmysql
, я действительно находил путь при помощи переменных и должностных лиц, но кажется, что я сталкиваюсь со странным марионеточным поведением, поскольку кажется, что глобальные переменные класса установлены, даже если класс не включен узлом – Alex F 11 December 2009 в 16:09