Управление конфигурацией системы 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) и сценарий управления, написанный на Pysvn, который реализует следующее:

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

• совершить

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

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

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

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

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

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

• Пысвн это легко, и я использовал это раньше.

• SVN поддерживает версионные пользовательские свойства, где Git, кажется, не

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

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