Марионетка: Как переопределить / переопределяют внешний дочерний класс (вариант использования и подробный пример)

Да, Вы видите обоих worgroups, но:

Это не nessecary, чтобы быть в обеих рабочих группах. Вы просто отображаете доли от 2-х рабочих групп с сетевым ресурсом команды x: \win2k3\share/user:win2k3_local_acccount

6
задан 10 December 2009 в 06:10
4 ответа

Дайте этому движение

# 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
}
0
ответ дан 3 December 2019 в 00:34
  • 1
    Да, я знаю о наследовании, но я не хочу его в этом случае, потому что класс mysql::server не имеет отношений с stripdown класс. И кроме того mysql::server уже наследовал класс mysql, я действительно находил путь при помощи переменных и должностных лиц, но кажется, что я сталкиваюсь со странным марионеточным поведением, поскольку кажется, что глобальные переменные класса установлены, даже если класс не включен узлом –  Alex F 11 December 2009 в 16:09

Делайте попытку с этим:

# 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, располагают с интервалами больше, чем самое длинное имя опции.

2
ответ дан 3 December 2019 в 00:34

Одной вещью, на которую можно хотеть посмотреть, является Виртуальный Ressources для обхождения повторного определения ресурсов. Документация относительно той темы может быть найдена: http://reductivelabs.com/trac/puppet/wiki/VirtualResources

Конечно, другой путь был бы к простому, создают объекты узла для каждого хоста, который не выполняет mysql и затем загружает разделенный класс там.

0
ответ дан 3 December 2019 в 00:34

Каждый раз, когда Вы говорите, "Я хочу, чтобы этот компонент вел себя один путь в одном узле, но другой путь в другом узле", вероятно, необходимо смотреть на определение, управляемое переменными, или через условные выражения в определении класса или через замены в шаблоне.

К сожалению, Ваш пример показывает Вам пытающийся использовать наследование, которое довольно плохо повреждается в марионетке и вызовет Вас много горя здесь, потому что одной из вещей, которые это повреждает, является переменное переопределение в узлах.

ОБНОВЛЕНИЕ: старые детали ответа являются устаревшими

То, что я делаю с 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.

3
ответ дан 3 December 2019 в 00:34
  • 1
    интересный, я должен попробовать это. В настоящее время у меня есть целая схема с переменными и должностным лицом в определении (это работает), который я частично описал в марионеточном списке рассылки. Это было долгим обсуждением, но в конце, никто не мог найти способ сделать это –  Alex F 3 March 2010 в 18:13

Теги

Похожие вопросы