Я использую Puppet для создания /etc/exim4.conf и я хочу убедиться, что конфигурация действительна, прежде чем устанавливать файл в производственных системах.
Я считал -
использование крючка git для вызова exim4 -bV -C filename... но это не сработает, потому что я использую шаблон ERB для создания файла, поэтому конечный результат фактически не создается, пока не будет запущен агент Puppet. У меня уже есть git-крючок для проверки синтаксиса ERB.
позволить сценарию инициализации проверить файл конфигурации... но этого недостаточно, потому что, хотя сценарий откажется перезагружать exim, если конфигурация недействительна, файл уже будет установлен, и прямые вызовы Exim (например, для отправки почты из приложений) завершатся ошибкой .
В идеале мне нужна директива Puppet, которая выглядит как
file { '/etc/exim4/exim4.conf':
content => template("exim/etc/exim4/exim4.conf.erb"),
notify => Service[exim4],
but_before_we_install_check_syntax_with => '/usr/bin/exim4 -bV -C',
}
Как мне проверить синтаксис файла конфигурации после он был создан Puppet, но перед он устанавливается?
Я использую Exim 4.80 и Puppet 2.7.26 в системах Debian Wheezy.
Похоже, вы описываете validate_cmd параметр точно. Из Ссылка на тип марионетки для file:
Команда для проверки синтаксиса файла перед его заменой. Если Puppet потребуется перезаписать файл из-за нового источника или содержимого, он сначала проверит действительность нового содержимого. Если проверка не удалась, файловый ресурс не будет работать.
Эта команда должна иметь полный путь и должна содержать токен процента (%) там, где она должна ожидать входной файл. Он должен выйти из 0, если синтаксис правильный, и ненулевого в противном случае. Команда будет запущена в целевой системе при применении каталога, а не на мастере марионетки.
В вашем примере, я думаю, вы бы сделали это:
file { '/etc/exim4/exim4.conf':
content => template("exim/etc/exim4/exim4.conf.erb"),
notify => Service[exim4],
validate_cmd => '/usr/bin/exim4 -bV -C %',
}
Вы можете протестировать полученную конфигурацию, используя крючок git для запуска виртуальной машины / контейнера (для этого идеально подойдет Docker) и применить манифест в этой среде.
Если вы делаете это регулярно, вы можете подумать о внедрении системы CI (например, Дженкинс), в который вы отправляете свои изменения, пусть CI выполнит набор тестов и в случае успеха отправит изменения в рабочую среду.
Я бы, наверное, просто создал три задачи, которые зависят друг от друга:
Есть ли причина, по которой в данном случае это не сработает?