У нас есть базовый класс nginx, а классы узлов включают этот базовый класс и добавляют свои файлы конфигурации в /etc/nginx/conf.d
Я хотел бы, чтобы служба nginx подписывалась на /etc/nginx/conf.d в одном месте, чтобы людям, пишущим классы узлов, не нужно было забывать добавлять notify => Service['nginx']
. Я пробовал использовать приведенный ниже код Puppet, но он не работал (т.е. после того, как я изменил application.conf, служба nginx не была перезагружена).
Это возможно?
модули / nginx / init.pp
class nginx {
package { 'nginx':
ensure => installed,
}
service { 'nginx':
ensure => running,
enable => true,
hasstatus => true,
hasrestart => true,
require => Package['nginx'],
subscribe => File['/etc/nginx', '/etc/nginx/conf.d'],
}
file { ['/etc/nginx', '/etc/nginx/conf.d']:
ensure => directory,
owner => application,
group => application,
recurse => true,
}
}
модули / приложение / init.pp
class application {
file {'/etc/nginx/conf.d/application.conf':
ensure => present,
owner => application,
group => application,
source => 'puppet:///modules/application/application.conf',
require => Package['nginx'],
}
}
С помощью Puppet я обнаружил, что если то, что вы делаете, не работает немедленно, вы, вероятно, пытаетесь сделать что-то, чего не следует делать. В этом случае вы, вероятно, не хотите, чтобы каждый отдельный сайт просто сбросил файл конфигурации в nginx / conf.d. Вместо этого вам нужно создать определенный ресурс, представляющий виртуальный хост nginx. В рамках этого ресурса вы должны будете поместить правильный файл конфигурации в conf.d и уведомить службу nginx.
Преимущество этого заключается в том, что вы можете стандартизировать всю необходимую конфигурацию. Например, большинству сайтов nginx потребуется gzip. Допустим, вы забыли об этом, вы бы предпочли внести это изменение в свой шаблон по умолчанию или вам нужно найти каждую определенную конфигурацию nginx, которую нужно изменить? Или, допустим, другая уязвимость обнаружена в шифрах, используемых для HTTPS. С одной стандартной конфигурацией nginx это одно место, где вам нужно ее изменить. Когда каждое приложение удаляет свой собственный файл конфигурации, вы будете его везде менять.
Если вам нужно абстрагировать общие функциональные возможности во что-то многократно используемое, лучший вариант - создать определенный тип. Примерно так должно работать:
define nginx::config_fragment (
$group,
$owner,
$source,
) {
file { "/etc/nginx/conf.d/${title}.conf":
ensure => 'file',
group => $group,
owner => $owner,
source => $source,
}
}
Затем в вашем site.pp
, установите значение по умолчанию для вашего типа ресурса:
Nginx::Config_fragment {
group => 'application',
owner => 'application',
notify => Service['nginx'],
}
В file
будет уведомлять окружающий определенный тип всякий раз, когда запускается обновление, которое затем планирует перезагрузку в службе nginx.
Не уверен, что это сработает, но как насчет создания простого exec, который генерирует один файл на основе содержимого отслеживаемого каталога, подписывается на этот файл, а затем запускает ваш перезапуск ...
например:
class nginx {
package { 'nginx':
ensure => installed,
}
service { 'nginx':
ensure => running,
enable => true,
hasstatus => true,
hasrestart => true,
require => Package['nginx'],
subscribe => File['/etc/nginx', '/etc/nginx/conf.d'],
}
file { ['/etc/nginx', '/etc/nginx/conf.d']:
ensure => directory,
owner => application,
group => application,
recurse => true,
}
exec { "/tmp/nginx-config-checksum":
path => "/usr/local/bin/:/bin:/usr/sbin",
command => 'find /etc/nginx/conf.d | xargs md5sum > /tmp/nginx-config-checksum',
}
file { "/tmp/nginx-config-checksum"
notify => Service['nginx']
}
}