Отсутствие нормальной системы управления пакетами, идея "соберем все сами из сырцов", положенная в основу.
А с какого перепугу он должен его видеть?
У нас это любимый вопрос на собеседовании, почему генту плохо подходит для использования в больших компаниях, когда число серверов исчисляется не единицами )
Ну мы же говорим только о профпригодных системных администраторах, которые не боятся читать документацию и писать скрипты-конфиги? ))
Разумеется. ибо в общем случае такой простой regexp не пойдет. Под one может попасть масса ненужного. Разумеется, в каждом конкретном случае можно придумать хитрый регексп.. Но врятли это удобнее augeas )
Очевидно Вам не приходилось встречаться с девелоперскими конторами, в которых разные группы разработчиков в силу ТЗ проектов должны работать с разными версиями ОС. Гораздо проще, основываясь на собственном опыте, назвать эту ситуацию бардаком, да.
Когда есть из чего выбирать. Предложите, например, аналог isc'шного dhcpd, умеющего fault tolerance?
Это один и тот же файл. Сервер, на котором должен будет располагаться vhost, является одним из атрибутов vhost'a и должен быть указан в файлике описания.
ну это не он считает. есть какой то поставляемый набор линз, можно дописывать самостоятельно.
Явно удобнее, нежели вручную изобретать с нуля велосипед для sed.
Как обычно, зависит от ситуации.
В ситуации, когда у меня в сети разные версии центоса, редхатов, убунт, дебианов - и мне на всех них надо добавить ключик в sshd_config, не перезаписывая конфиг - augeas удобно.
Ну когда выбор есть - то это может быть одним из поводов. Но далеко не всегда выбор есть.
эээ... считаем что конфиг для vhost конфигурится единым шаблоном, на основании данных из файлика, описания vhost'а. Ну и vhost'ы однотипные, мы же про mod-proxy в данном случае говорим.
прежде чем - проверь что бекап актуальный и читается )
sed -i 's/badone/goodone/' /etc/somefile
это не так. augeas несколько более функционален. а вот такой вот sed - действительно багогенерилка.
не все сервисы умеют такой синтаксис.
Непонятно зачем хочется описание конфигурации сервиса держать в паппете в одном файле, а не в двух? Или вообще не в файле, а в sql/ldap/etc ? Паттерн в паппете останется прежним.
Ну в первом приближении - да. Но с условием что для одной ноды может быть более одного инстанса сервиса, и как следствие - более одного конфига.
Еще до кучи, мне очень понравилось сочетание augeas+puppet, позволяет гибко редактировать конфиги, не перезаписывая их полностью. Если не видел - взгляни.
Ну и такой вариант вполне имеет право на существование, почему нет.
Хотя мне кажется более логичным файлы раскладывать рядом с рецептами, нежели все в одну кучу. Но как обычно, дело вкуса.
очень может быть )
Не совсем. В файлике nodes.pp мы описываем какие в принципе у нас хосты есть в системе.
Говорим что вот эти вот хосты - они модпрокси, вот та группа - sql сервера, третья - билд сервера и т.д. Само собой один и тот же сервер теоретически может исполнять разные роли.
И отдельно имеем файлик со списком виртуалхостов, где указано какой из них на каком мод-прокси сервере держать.
Переформулирую.
Хочется придумать паттерн для паппета, для создания конфигов для сервиса, могущего иметь несколько инстансов на каждом хосте, без описывания каждого инстанса в рецепте/описании ноды.
Ровно одно. При добавлении очередного виртуалхоста дописываем только в файл списка виртуалхостов.
