я использую puppet parser validate в мерзавце pre-commit перехватчик, чтобы выявить проблемы перед фиксацией файлов в нашем репозитории конфигурации Puppet. К сожалению, эта команда представляет собой очень легкую проверку синтаксиса, которая отмечает только ошибки, такие как несбалансированные кавычки и скобки.
В validate похоже, что команда на самом деле не анализирует конфигурацию и не ищет такие вещи, как недопустимые атрибуты, неопределенные ссылки и т. д. Например, следующее не приведет к жалобе:
file { 'somefile': requires => File['some-other-file'] }
В этом примере requires должно быть require. Точно так же это также не вызывает ошибок:
file {'somefile': require => File['file-that-does-not-exist']}
Нет определения ресурса для file-that-does-not-exist.
Есть ли способ отловить такого рода ошибки без фактического применения конфигурации? Я надеялся на какой-то флаг на puppet apply команда, которая полностью проанализирует конфигурацию без внесения изменений, но, насколько я могу судить, такой опции нет в Puppet 2.7.1.
ОБНОВИТЬ
puppet apply --noop кажется, слишком старается в другом направлении. Он попытается stat() любой файл, указанный в манифесте, что часто приводит к сбою с ошибками разрешения, если он пытается stat() файл, который недоступен текущему пользователю.
Что делают другие люди?
Вы можете рассмотреть возможность начальной загрузки тестовой среды, такой как Cucumber-puppet.
Короче говоря, это нетривиальная проблема, и ее нелегко решить, проанализировав манифесты. Составление каталога может расширить рамки тестирования, но это не панацея. puppet master --compile требует доступа к фактам узла и в идеале фиктивного узла, который полностью тестирует все классы. Вам все равно придется столкнуться с ограничениями:
Например, если узел один включает a и b, это нормально, но узел два требует только b, это только сбой, который вы увидите с узлом два.
class a {
notify { 'hi': }
}
class b {
notify { 'bye':
require => Notify['hi'],
}
}
Если у вас есть ресурсы, вы можете составить каталог для всех узлов, и это обеспечит достаточно полное покрытие.
puppet apply --noop также имеет свои ограничения, вне моей головы: он выдает сбой в exec, развернутом пакетом, он отказывает файлы в зависимости от места размещения, и он не будет тестировать несколько платформ, если вы не развернете тестирование репрезентативной выборки ваших систем. В целом он обеспечивает достаточное покрытие, чтобы гарантировать отсутствие проблем с компиляцией, дает вам представление о том, какие системы затронуты, какие изменения, и вы можете судить по отчетам, являются ли изменения правильными или реальная проблема.
В большинстве случаев достаточно noop, я видел различные степени автоматизированного тестирования, такие как jenkins, где каждый файл тестов модулей моделируется с помощью --noop (применяются указанные выше ограничения), или использование Vagrant для создания виртуальных машин для выполнения полномасштабного тестирования.
Чтобы получить немного больше подтверждения разумности ресурсов и атрибутов, вы можете скомпилировать образец каталога узлов с помощью puppet master --compile. Это должно поймать первый пример.
Я не уверен, что ссылки на ресурсы (второй пример) проверяются на мастере или клиенте, но вы всегда можете выполнить его в режиме без операций с помощью puppet catalog apply, или puppet apply. Последний компилирует его снова и затем применяет, в то время как первый должен иметь возможность брать скомпилированный каталог из более ранней проверки.