Управление конфигурацией системы Linux: управление версиями и развертывание

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

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

Я предпочитаю управлять сервером обычным образом (т. Е. Входить и вносить изменения в рабочий сервер по мере необходимости), а затем сохранять эти изменения (после внесения) в систему управления. (Хорошо, если честно, я должен сказать органически: Я не хочу терять гибкость, позволяя делать то, что того требуют потребности и ситуации.) Я считаю этот подход, а не развертывание конфигурации, которая была настроена и протестирована в другом месте, более предсказуемой и с потенциалом для меньшего количества сюрпризов (за исключением возможность испортить конфигурацию на живой системе, то есть!)

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

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

Параметры

1. Системы декларативной метаконфигурации, такие как Puppet, среди прочего, вероятно, являются хорошим выбором, когда задействовано много серверов с минимальным различием между ними или без них, и особенно когда заранее ясно, как должна выглядеть конфигурация. Я не думаю, что было бы разумно использовать такой инструмент без промежуточной инфраструктуры.

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

2. etckeeper может работать, но, насколько я знаю, он не может управлять чем-либо, кроме / etc. т.е. он не подходит для хранения пользовательских скриптов, которые по традиции находятся в / usr / local / bin. Кроме того, etckeeper предположительно управляет все из / etc, где я бы предпочел версии только определенных вещей (например, postfix, apache, fail2ban, ssh и, возможно, munin).

3. Простое репозиторий git или svn, конечно, не годится, потому что, хотя git отслеживает разрешения, он не отслеживает владение, и svn тоже не отслеживает.

   svn сохраняет .svn подкаталог в каждом отслеживаемом каталоге, тогда как .git существует только в корневом каталоге рабочей копии. В обоих случаях есть свои преимущества и недостатки. Наличие .svn каталог в определенном месте может быть в порядке в некоторых местах (например, / etc / apache2 / sites-enabled), но расстраивает мертвые скрипты / инструменты в другом месте. (Уверен, я что-то читал некоторое время назад: было ли дело в том, что cron был в порядке с .svn dir в /etc/cron.d, но depmod не было с / lib / modules?)

   С другой стороны, с .git в /, git считает все кандидат для отслеживания, даже (предположительно) другие репозитории git!

Индивидуальное решение

Вот что я предлагаю сделать: репозиторий Subversion, хранящийся на первичном компьютере (скажем, / usr / local / sc-repo), и сценарий управления, написанный на Писвн который реализует следующее:

• add (но по умолчанию не рекурсивно), который сохраняет режим и принадлежность файла как настраиваемые свойства. Еще мне нравится $Id$ теги в моих файлах конфигурации, так что это обеспечит svn:keywords установлен правильно.

• совершить

• обновление, которое применяет право собственности и режим после записи файла

• вернуться, то же самое

• perms, как и diff, но для владельца и режима, с флагом исправления, который можно исправить при необходимости.

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

Почему подрывная деятельность?

• Я знаю, нравится и есть много более знаком с svn, чем я с git. Да, наверное, я динозавр.

• Pysvn прост, и я использовал его раньше.

• svn поддерживает настраиваемые свойства с поддержкой версий, где git, похоже, не

• это не распределенная разработка: распределенные репозитории усложняют ситуацию без пользы. Доступность удаленного репо не имеет значения, потому что коммиты с удаленного компьютера будут редкими.

Буду признателен за отзыв. Я обдумал это как можно больше, но наверняка что-то упустил.