Как можно контролировать версии файлов конфигурации сервера, которые изменяются во время выполнения приложения, используя git или другую систему контроля версий?

Question

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

Обратите внимание, что этот вопрос может относиться ко многим ситуациям,это не относится только к Minecraft.

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

Во-первых, некоторые файлы администраторам придется редактировать.изменяются сервером во время выполнения. Я предполагаю, что это запутает git, если я сделаю сам каталог сервера репозиторием. Используя решение post-receive checkout, это будет менее проблематично, если я прав (я все еще изучаю git).

Мне также нужно, чтобы изменения, внесенные сервером, были отправлены в репозиторий, чтобы администраторы могли извлечь эти изменения в свои локальные репозитории. Я видел решения, использующиеinotifyожидатьно все это, похоже, учитывает только изменения одного файла. На моем сервере есть 50-80 файлов конфигурации, которые мне нужно отслеживать и автоматически фиксировать, когда среда выполнения сервера изменяет их. Как лучше всего с этим справиться?

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

Первоначально я опубликовал это на StackOverflow, но мне сказали, что оно больше подходит для этого места.

Answer 1

Это не полный ответ, но, надеюсь, некоторые полезные мысли:

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

inotifywait -m -r -e close_write /etc

И получаем следующий лог после редактирования /etc/passwd:/etc/postfix/main.cf

/etc/ CLOSE_WRITE,CLOSE .passwd.swpx
/etc/ CLOSE_WRITE,CLOSE .passwd.swp
/etc/ CLOSE_WRITE,CLOSE 4913
/etc/ CLOSE_WRITE,CLOSE passwd
/etc/ CLOSE_WRITE,CLOSE .passwd.swp
/etc/postfix/ CLOSE_WRITE,CLOSE .main.cf.swx
/etc/postfix/ CLOSE_WRITE,CLOSE .main.cf.swp
/etc/postfix/ CLOSE_WRITE,CLOSE 4913
/etc/postfix/ CLOSE_WRITE,CLOSE main.cf
/etc/postfix/ CLOSE_WRITE,CLOSE .main.cf.swp

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

Также обратите внимание, чтоинкрон— отличный инструмент для автоматизации такого рода рабочих процессов на основе inotify (но он не изменит существенно суть решения).

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

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

Answer 2

В подобных ситуациях я делал так: делал живую конфигурацию репозиторием (я обычно использую Bazaar) и писал cronjob для автоматической фиксации любых изменений. Наличие живой конфигурации в репозитории VCS не должно быть проблемой — единственное отличие — это каталог .git, который в большинстве случаев следует просто игнорировать. Интервал cronjob будет любой гранулярностью, которая вас устроит. Каждый час был достаточно хорош для моих ситуаций, но это может быть каждые 5 минут или даже 1 минута, если необходимо.

Answer 3

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

Для файлов конфигурации взгляните наetckeeper:

Name       : etckeeper
Arch       : noarch
Version    : 0.63
Release    : 1.el5
Size       : 36 k
Repo       : epel
Summary    : Store /etc in a SCM system (git, mercurial, bzr or darcs)
URL        : http://kitenet.net/~joey/code/etckeeper/
License    : GPLv2+
Description: The etckeeper program is a tool to let /etc be stored in a git,
           : mercurial, bzr or darcs repository. It hooks into yum to automatically
           : commit changes made to /etc during package upgrades. It tracks file
           : metadata that version control systems do not normally support, but that
           : is important for /etc, such as the permissions of /etc/shadow. It's
           : quite modular and configurable, while also being simple to use if you
           : understand the basics of working with version control.
           : 
           : The default backend is git, if want to use a another backend please
           : install the appropriate tool (mercurial, darcs or bzr).
           : To use bzr as backend, please also install the etckeeper-bzr package.
           : 
           : To start using the package please read /usr/share/doc/etckeeper-0.63/README

Во-первых, некоторые файлы администраторам придется редактировать.изменяются сервером во время выполнения.

Без проблем.

Мне также необходимо, чтобы изменения, вносимые сервером, были отправлены в репозиторий, чтобы администраторы могли извлечь эти изменения в свои локальные репозитории.

По умолчанию etckeeperзапускается ежедневно как задание cron:

/etc/cron.daily/etckeeper

#!/bin/sh
set -e
if [ -x /usr/bin/etckeeper ] && [ -e /etc/etckeeper/etckeeper.conf ]; then
    . /etc/etckeeper/etckeeper.conf
    if [ "$AVOID_DAILY_AUTOCOMMITS" != "1" ]; then
        # avoid autocommit if an install run is in progress
        lockfile=/var/cache/etckeeper/packagelist.pre-install
        if [ -e "$pe" ] && [ -n "$(find "$lockfile" -mtime +1)" ]; then
            rm -f "$lockfile" # stale
        fi
        if [ ! -e "$lockfile" ]; then
            AVOID_SPECIAL_FILE_WARNING=1
            export AVOID_SPECIAL_FILE_WARNING
            if etckeeper unclean; then
                etckeeper commit "daily autocommit" >/dev/null
            fi
        fi
    fi
fi

Если вы также хотите выполнить отправку в удаленный репозиторий, отредактируйте указанный выше файл следующим образом:

        if etckeeper unclean; then
            etckeeper commit "daily autocommit" >/dev/null
            cd /etc && git push origin master
        fi

Если ежедневного или даже минутного интервала недостаточно,Наблюдательможете зафиксировать свои файлы конфигурации сразу после изменения:

/etc/watcher.ini

[DEFAULT]
logfile=/tmp/watcher.log
pidfile=/tmp/watcher.pid
[job1]
watch=/etc
events=create,delete,write_close
recursive=true
autoadd=true
command=cd /etc && etckeeper commit "daily autocommit" >/dev/null && git push origin master

Попробуйте.