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

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

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

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

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

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

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

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

3 ответа

Решение

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

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

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 событие, передаст файл в локальный репозиторий и передаст изменения на удаленный сервер.

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

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

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

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

Для файлов конфигурации взгляните на 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

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

/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

Попробуйте.

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

Другие вопросы по тегам