Я ищу наилучший способ (для моих целей и ситуации) для версионирования файлов конфигурации системы и управления развертыванием (владение и режим) между двумя машинами (рабочей и резервной, обе следует рассматривать как «производственные»). Я хотел бы иметь возможность использовать эту систему для автоматического (но выборочного) дублирования и управления соответствующей и указанной конфигурацией на резервной машине (экземпляр EC2).
В настоящее время эти машины в основном являются веб- и SMTP-серверами (мы не храним почтовые ящики пользователей), но наш проект растет, и кто знает, какими могут быть будущие требования. Например, есть вероятность, что мы реализуем радио и веб-чат в какой-то момент в будущем.
Я предпочитаю управлять сервером традиционным способом (т. е. заходить и вносить изменения в работающий сервер по мере необходимости), а затем сохранять эти изменения (после их внесения) в системе управления. (Ладно, если честно, я должен сказатьорганически: Я не хочу терять гибкость, позволяющую делать то, что требуется в зависимости от потребностей и ситуации.) Я считаю такой подход более предсказуемым, чем развертывание конфигурации, которая была настроена и протестирована в другом месте, и потенциально менее непредсказуемым (за исключением возможности испортить конфигурацию в работающей системе, конечно!).
Я понимаю, что, говоря философски, это задом наперед, и я, вероятно, сделал бы это наоборот, если бы у меня были ресурсы (тестовая инфраструктура и, что еще важнее, рабочая сила). А так мне придется обходиться тем, что у меня есть. Мне нравится структура, но чрезмерная инфраструктура начинает жить своей жизнью, и в какой-то момент ее ценность теряется.
Я сделал домашнюю работу и рассмотрел несколько вариантов, но ни один из них, похоже, не делает то, что я хочу, поэтому сейчас я испытываю искушение свернуть свое собственное решение. Цель этого вопроса — увидеть, о чем я не подумал, и проверить здравомыслие, прежде чем я пойду лаять на неправильное дерево.
Параметры
Системы декларативной метаконфигурации, такие как Puppet,в частности, вероятно, являются хорошим выбором, когда задействовано много серверов с небольшим или отсутствующим различием между ними, и особенно когда заранее ясно, как должна выглядеть конфигурация. Я не думаю, что было бы разумно использовать такой инструмент без промежуточной инфраструктуры.
Он также немного тяжеловесный и чрезмерно сложный. Я единственный администратор, я делаю это в свободное время, и если со мной что-то случится, то все, что я оставлю после себя, должно быть достаточно разумным для счастливчика/счастливицы, которая придет после меня.
etckeeper может подойти, но насколько я видел, он не очень подходит для управления чем-либо, кроме /etc. т.е. он не подойдет для хранения пользовательских скриптов, которые традиционно находятся в /usr/local/bin. Также, etckeeper, по-видимому, управляетвсе/etc, где, как мне кажется, я бы предпочел версионировать только определенные вещи (например, postfix, apache, fail2ban, ssh и, возможно, munin).
Простой репозиторий git или svn, конечно, не подойдет, поскольку git отслеживает права доступа, но не отслеживает владельцев, а svn не отслеживает ни то, ни другое.
svn хранит
.svnподкаталог в каждом отслеживаемом каталоге, тогда как.gitсуществует только в корневом каталоге рабочей копии. В обоих случаях есть свои преимущества и недостатки. Наличие каталога.svnв определенном месте может быть приемлемым в некоторых местах (например, /etc/apache2/sites-enabled), но расстраивать безмозглые скрипты/инструменты в других местах. (Я уверен, что читал что-то некоторое время назад: было ли так, что cron был приемлем с каталогом.svnв /etc/cron.d, но depmod не был с /lib/modules?)С другой стороны, с помощью
.git/ git считаетвсекандидат на отслеживание, даже (предположительно) других репозиториев git!
Индивидуальное решение
Вот что я предлагаю сделать: репозиторий Subversion, хранящийся на основной машине (например, /usr/local/sc-repo), и скрипт управления, написанный наПысвнкоторый реализует следующее:
add (но по умолчанию не рекурсивно), который сохраняет режим файла и владение как пользовательские свойства. Кроме того, мне нравятся
$Id$теги в моих файлах конфигурации, так что это гарантируетsvn:keywordsправильную установку.совершить
обновление, которое применяет владельца и режим после записи файла
вернуться, то же самое
разрешения, как и diff, но для владельца и режима, с флагом исправления для исправления при необходимости.
Резервная машина будет получать доступ к репозиторию через ssh и выполнять операцию обновления каждую ночь. (Она также будет выполнять другие действия, например, восстанавливать SQL сайта и файловые системы приложений из резервного репозитория основной машины (S3), и мне, вероятно, придется написать какую-то хакерскую штуку, которая будет искать новые пакеты, добавленные на основную машину, и добавлять их на резервную машину — но все это выходит за рамки этого вопроса.)
Почему подрывная деятельность?
Я знаю, люблю и люблюмногоЯ больше знаком с svn, чем с git. Да, я, наверное, динозавр.
Pysvn прост, и я уже пользовался им раньше.
svn поддерживает версионные пользовательские свойства, в то время как git, похоже, этого не делает
это не распределенная разработка: распределенные репозитории усложняют ситуацию без выгоды. Доступность удаленных репозиториев не имеет значения, поскольку коммиты с удаленной машины будут редкими.
Буду благодарен за ваш отзыв. Я обдумал все, что мог, но наверняка что-то упустил.
решение1
Не изобретайте велосипед. Существуют инструменты, которые помогут вам сделать то, что вам нужно. Вы можете посмотретьbcfg2, особенно учитывая, что вы, похоже, особенно сосредоточены на файлах конфигурации. Подумайте также о службах. Где должен находиться центральный репозиторий по отношению к производственному серверу?
Возможно, промежуточным вариантом может быть осторожное изменение выходных данныхЧертежинструмент. Я использую Blueprint для обратного проектирования существующих систем. Выходные данные запуска Blueprint могут создать скрипт оболочки, модуль Puppet или кулинарную книгу Chef... После проверки конфигурации на производственном сервере вы можете использовать этот инструмент для фиксации состояния системы, а затем пометить и версионировать результат. Читатьчерез примерыи сообщите, если вам покажется, что это соответствует вашему варианту использования.
решение2
Системы декларативной метаконфигурации, такие как Puppet, среди прочего, вероятно, являются хорошим выбором, когда задействовано много серверов с небольшим или отсутствующим различием между ними, и особенно когда заранее ясно, как должна выглядеть конфигурация. Я не думаю, что было бы разумно использовать такой инструмент без промежуточной инфраструктуры.
Я использую Puppet (но да, существуют Chef, Ansible, Salt и т. п.) даже для одномашинных установок. Я еще не сталкивался с ситуацией, когда кто-то заранее понимал, как должна выглядеть конфигурация машины (возможно, многие не понимали, как должна выглядеть конфигурация после, но это уже совсем другая проблема)
Что касается «инфраструктуры подготовки», то этобродягаиVirtualBox(или какая-то другая поддерживающая технология виртуализации) - запустите ее на своей машине разработчика для нулевых затрат. Я не делаю никаких разработок манифеста Puppet без нее. Также автоматизированные тесты сТрэвис CI
Он также немного тяжеловесный и чрезмерно сложный. Я единственный администратор, я делаю это в свободное время, и если со мной что-то случится, то все, что я оставлю после себя, должно быть достаточно разумным для счастливчика/счастливицы, которая придет после меня.
Кажется непоследовательным говорить это, а затем описывать, как вы планируете собственное решение вместо существующих с большим количеством документации, примеров, существующих «библиотек» и активной разработкой.