В мастера положить конфиг1, в бранче держать конфиг 2. Конфиг 1 обновлять только в мастере и мержить его в бранч.

Ну это само собой, я об этом и писал, только мне тогда хуки надо прикручивать чтоб мержить мастер в бранчи, плюс бранчей у меня в лучшем случае штук 7 получается.

для всех конфиг базовый, на хостах, если есть, то дополняется базовый, локальным конфигом

etckeeper

а если нужен деплой на сто пятьсот хостов?

А конфиги - просто данные, или скрипты ? Если скрипты, можно по hostname привязаться попробовать. В смысле конфиг общий, а отдельные части применяются в зависимости от имени хоста, хотя копируются на все хосты. Ну и имена хостов тоже можно стандартизировать для удобства перебора.

Ansible. Можно конфиги и в Git хранить, для истории, но не обязательно. Мне Ansible на ЛОРе посоветовали :) Нравится, осилить не сложно. Запускаю локально в основном, хотя оно рассчитано на выполнение на нескольких машинах по SSH.

Как-то мне давали совет, что если данные надо много читать и мало править, то их удобно будет хранить в OpenLDAP. Но практически проверить это руки не дошли.

Сразу отвечу и на вопрос AS.

С Ansible я работаю, на нем и будет все основано в части раскидывания конфигов, конфиги будут в виде шаблонов так что некотрые параметры, которые специфичны для разных хостов будут браться из переменных\параметров этих хостов (то есть для host1 и host3 из примера мне не нужно хранить две версии config2 - он будет шаблонизирован). Проблема в том, как именно организовать хранение этих шаблонов - хочется какой-то логики, которая была бы максимально проста для администратора, который будет управлять этими конфигами, при этом не нагружая его необходимостью жестко следовать «config1 править только в бранче master и никак иначе» - это лишь повышает шанс что кто-то забудет\ошибется и поломает вообще всю логику хранения конфигов. А связка Git+Ansible в этом случае в моем понимании предоставляет с одной стороны удобный интерфейс для изменения конфигов, с другой - обеспечивает легкость применения изменений на хостах.

То есть держать связи между файлами на уровне ОС, а сами файлы в git? Это интересно, спасибо!

Он, на сколько я помню, больше предназначен для локального контроля изменений, а мне нужна связка с централизованным хранилищем. Или в нем можно указать уделенное хранилище для хранения конфигов? Но в любом случае этот вариант скорее всего отпадает, так как требует дополнительного софта на удаленных хостах, хочется обойтись без этого.

В случае с данными пользователей (логин-пароль-почта-телефон) может так и есть, но у меня конфиги будут довольно гетерогенны, да и вообще LDAP не люблю =).

структуру можно в документации подсмотреть http://docs.ansible.com/playbooks_best_practices.html#content-organization а ветки не особо нужны

Там в основном советы по организации хранения плейбуков (кстати прикол этих ролей я так и не понял и не использую их). Вообще мне не удалось найти каких-то success story по применению Ansible для больших разномастных проектов. Тут вопрос скорее всего не в контексте Ansible следует рассматривать.

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

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

IMHO(пока экстраполированное), что «пробежаться по репам» - лучшее(*) из того, что человечество придумало. Возможно намного проще будет исправить «неудобства» этого подхода, чем бодаться с «более мощными» решениями с исполнимыми/компилируемыми/etc. конфигами.

(*) по набору критериев ленивого сисадмина.

гугли:

json merge

json merge config

Он, на сколько я помню, больше предназначен для локального контроля изменений

почему это вдруг?

так как требует дополнительного софта на удаленных хостах

Всего то git,mercurial или что то еще.

почему это вдруг?

Я особо его не использовал, но так показалось после просмотра примера конфига в репе проекта.

Всего то git,mercurial или что то еще.

Все равно это какие-то изменения в системе. Если реализовать это через тот же Ansible телодвижений будет гораздо меньше, не смотря на то что git на удаленном хосте можно одной командой поставить.

Конфиги в любом случае будут «компилироваться» (они будут шаблонизированы), но репы для каждой «уникальной» группы хостов мне тоже кажется единственным нормальным вариантом.

в любом случае будут «компилироваться»

В этом случае, IMO, отдельные репы/каталоги/etc - лишняя сущность, всё можно засунуть в шаблоны/playbookи/прочее.

Интересно было бы обойтись без лишних языков. Изоморфизм планируемых и настоящих конфигов - фича, кажущаяся полезной. Есть вероятность, что система репов с миграцией отдельных патчей между ними(+ пара костылей для автоматизации) может оказаться достаточно удобной, чтобы её ограничения компенсировались достоинствами упомянутого выше изоморфизма.

Пытался ли кто либо такое устроить и на какие грабли наступил? Не хочется повторять чужие ошибки.

В этом случае, IMO, отдельные репы/каталоги/etc - лишняя сущность, всё можно засунуть в шаблоны/playbookи/прочее.

Тут я вижу смысл отдельных реп в том, чтоб было проще управлять набором файлов (как config2 в примере, который нужен не везде) - если файлов один-два то это можно засунуть в сценарий, но если их больше, то уже не так удобно будет писать «возьми конфиги из репы %repo_address%, только не бери config2 и config3 и config 4 и ... configN». Опять же при добавлении\удалении конфига придется править сам сценарий, а так выполнил действия на уровне репозитория и готово.

Интересно было бы обойтись без лишних языков. <...> Есть вероятность, что система репов с миграцией отдельных патчей между ними(+ пара костылей для автоматизации) может оказаться достаточно удобной

На мой взгляд это не совсем удобно - есть, например, 10 хостов, для которых в конфиге должны быть разные значения somevariable - в случае с шаблонизированным конфигом мы можем просто указать какое значение брать в случае конкретного хоста, причем это все будет сделано на уровне системы, которая будет эти конфиги раскладывать по хостам (Ansible в данном случае). В случае с патчами придется отдельно хранить патчи для каждого хоста, либо писать регулярки, либо еще как-то осуществлять не подстановку значения, а именно его замену.

10 хостов, для которых в конфиге должны быть разные значения

Правильно. Однако, это идёт в пакете с невозможностью, в общем случае, найти источник строки или использовать текущий рабочий конфиг для раздачи другим хостам. Вот, скажем, вернулся ты из запоя или отпуска, смотришь конфиг, а там длинная «строка» с кучей подробностей, добавленная «не помню кем/когда/зачем». Как, например, убедиться, что «она» есть на всех аналогичных хостах? Как узнать, «значение» в оригинале прописано как есть, или появилось в результате расширения «somevariable»? Кажется, чем «приятнее» было писать конфиг, тем труднее потом воспользоваться реальными данными, т.ч. не дай тебе анзибль исправить хоть строчку вне его ведома.

С другой стороны, мелкий скрипт для клонирования репы при установке/подключении нового хоста с авторегистрацией token replace патчей и «автоподпиской» на «наследуемые» репы, и ты можешь в любой момент втащить рабочий конфиг, посмотреть/распространить изменения в нём на другие, просто грепнуть нужную строку по всем/интересным репам, и не обязательно держать под рукой предметы из хевиметала для дисциплинирования соадминов.

Однако, это идёт в пакете с невозможностью, в общем случае, найти источник строки или использовать текущий рабочий конфиг для раздачи другим хостам.

Да, сейчас как раз используется такое решение, что конфиг где-то обкатывается а потом «как есть» тиражируется по остальным хостам, затем в нем правятся нужные переменные. Но это создает трудности в том случае, когда кто-то внес изменения на host2, а другой на host3, при этом все остальные знаю что «эталонный» конфиг лежит на host1, в результате чего что-то потеряется либо придется «мержить» эти конфиги.

а там длинная «строка» с кучей подробностей, добавленная «не помню кем/когда/зачем»

Для этого и планирую использовать git

Как, например, убедиться, что «она» есть на всех аналогичных хостах?

Для этого нужно все изменения проводить через систему управления конфигами - если кто-то поправил что-то на хосте то система должна сообщить об этом, тогда можно стукнуть того кто руками полез на хост. Если речь о строке из репы то в крайнем случае конфиг можно перенакатить на все хосты или проверить какой-нибудь md5 (сравнить то что есть на хосте с тем, что должно там быть).

Как узнать, «значение» в оригинале прописано как есть, или появилось в результате расширения «somevariable»?

Для этого планирую прикрутить возможность посмотреть сгенерированные конфиги без копирования его на удаленные хосты.

не дай тебе анзибль исправить хоть строчку вне его ведома.

Это вообще одна из причин, по которой я планирую такую штуку для управления конфигами внедрить - были случаи, когда после долгого дебага ошибки выясняется что кто-то влез в конфиги и перемудрил там, а ты даже не в курсе.

не обязательно держать под рукой предметы из хевиметала для дисциплинирования соадминов.

Думаю без этого все равно не обойдется - люди почему-то склонны все портить и делать не так, как договорились =)

все изменения проводить через систему

Да, если бы всё всегда делалось так, как задумано, жизнь была бы не такая, как на самом деле:) Однако, «нормальная» система должна предусматривать исправление неплановых отклонений.

возможность посмотреть сгенерированные конфиги

Это не помогает, в общем случае. Ведь искомая строка сгенерирована шаблонизатором из никто не знает каких входных данных(или язык описания шаблонов слишком прост, что будет раздражать). В принципе, если научиться генерировать к конфигам ещё debuginfo, в котором будет написано, откуда что берётся, жить можно; но это ещё один (+)(см. ниже)

склонны все портить и делать не так, как договорились

Это, IMHO, происходит, когда «как договорились» предусматривает лишнюю работу, отклонение от кратчайшего пути к решению текущей задачи. Зачем, обычно, человек лезет в системы? Ему звонят/пишут/говорят /что-то где-то не (так)? работает/. Чтобы понять «почему» или «как», нужно лезть не в репозиторий с шаблонами, и не на «шаблонный» хост, а в конкретную рабочую систему с настоящими конфигами, где и стряслось. Следующий шаг - придумывание патча. Тут(+) шаблонизация наносит первый удар - тебе нужно вспомнить, что «правильный» конфиг сгенерён из каких-то исходников, и тебе нужно реверснуть компиляцию шаблона, чтобы догадаться, что куда писать. Потом, этот патч нужно протестить - человеки ошибаются. Короткая процедура - исправить(нужный файл уже часто в редакторе) и посмотреть. «Правильная», к этому (+) пойти в систему управления,(+) привести в состояние повторяемости проблемы тестовые системы, (+) убедить систему управления наливать новый патч только на тестовые системы. (+) описать, утвердить, и т.п, кому повезло вступить в процедуры управления изменениями. И хорошо, если тестирование выявило все глюки, иначе повторить с начала (*) N раз.

Посчитав (+) нетрудно понять, работать это если и будет, то за счёт огромного административного оверхеда(кто-то видел, чтобы админов нанимали с пятикратным запасом?), или в случае «массовости» услуги(когда цена медленной починки меньше цены неудачного патча).

Моя несбыточная (пока) мечта - процедуры, которые упрощают «реальную» работу(или, хотя бы, не мешают ей). Похоже, это подразумевает исправление «на месте»(с отложенным(когда всё заработало) импортом изменений в репу/тестированием/распространением), и отсутствие умных «шаблонизаторов» вне процесса начальной настройки/других «offline» задач. Вероятно, там будут свои проблемы - но подробности пока в тумане.

Зачем, обычно, человек лезет в системы? Ему звонят/пишут/говорят /что-то где-то не (так)? работает/. Чтобы понять «почему» или «как», нужно лезть не в репозиторий с шаблонами, и не на «шаблонный» хост, а в конкретную рабочую систему с настоящими конфигами, где и стряслось. <...> Короткая процедура - исправить(нужный файл уже часто в редакторе) и посмотреть.

Для этого планирую механизм, который будет сверять состояние конфигов на системе с тем, что там должно быть. Если есть расхождения - нотификация (планирую с каким-нибудь IM интерграцию сделать + дашборды + лог) что в таком-то конфиге добавили\удалили строчку. Так как есть инженеры, которые отвечают за конкретную систему, они будут принимать решение добавить ли эту строку в шаблон или кто-то накосячил. То есть с одной стороны мы не кладем сразу изменения в шаблоны, с другой - не сталкиваемся с проблемой, когда быстро поднял важную систему, а тут «эта тупая штука опять все поломала».

В принципе, если научиться генерировать к конфигам ещё debuginfo, в котором будет написано, откуда что берётся, жить можно.

В Ansible это уже «встроено» - там очень подробно логируются все действия (порой это даже раздражает), так что можно проследить процесс формирования конфига «изнутри», при чем такой подход не требует каких-то дополнительных действий и сейчас у меня используется «по-умолчанию» даже для очень простых и отлаженных сценариев, так как проблемы иногда (не по вине Ansible обычно) возникают на «ровном месте». (Если интересно то следует посмотреть на callback'и).

кто-то видел, чтобы админов нанимали с пятикратным запасом?

Вот у нас какая-то промежуточная ситуация - с одной стороны админов мало чтоб заниматься бюрократией, а с другой - админов достаточно для того, чтоб в систему был доступ у нескольких человек, благодаря чему часто стали возникать вопросы «кто это добавил, у меня все поломалось». Конечно, какая-то система управления конфигами не решит полностью задачу отслеживания автора изменений (мы же уже решили что ее будут использовать не всегда), но хотя бы позволяет отследить изменения конфигов.

К задаче отслеживания автора

вероятно, будет выгодно добавить проверку соответствия куда-то в .bash_logout, на фоне, с отсылкой инфы об обновлённых с момента начала сессии файлах(ещё лучше - diff-ах) кому-то «ответственному» - будет жрать ресурсы, но следы останутся даже если конечные исполнители совсем разгильдяи, и можно будет не заставлять их думать о великом.

А все равно же «имя» автора изменений не узнать. Нужно наверно тогда на уровне authorized_keys прикручивать к каждому ключу идентификатор его владельца, но есть вариант когда используется какой-то общий ключ для всех администраторов. А так идея интересная, спасибо, посмотрю что уже есть для реализации такого «контроля».

Кстати, о белках(проблемы прыжков по веткам)

Если твоя vcs-а рассматривает данные не как странную непонятную хрень из веток и листьев, а как множество патчей, понятие «[не]мастер» отсутствует, и перетаскивание патчей из любых в любые - достаточно тривиальная задача, требующая минимальных усилий. В теории.

«имя» автора изменений не узнать

кол-во подозреваемых сильно сужается - админы не должны «сидеть» на серверах без повода(тоже можно контроллировать), т.ч. если придётся опросить больше одного - это невезение.

Да тут проблема скорее не на уровне vcs (тот же git работает с изменениями, так что мержи обычно проходят довольно прозрачно и гладко), проблема с организацией самой структуры хранения информации (как например для хостов одной группы нужны конфиги config1 и config2, а для хостов другой группы - config1 и config3 - как не тянуть config2 на вторую группу и config3 - на первую).

Вот тут проблемы не видно совсем. Заводишь ветку «группа1», и в ней скрипт (втянуть всё из config1 и config3). Аналогично «группа2», с своим скриптом. и «for i in */втянуть ; do (cd $i && vcs в помощь ) ; done».