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