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

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

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

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 (но не меняет существенно природу решения).

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

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

Существует несколько руководств по использованию 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

Попробуйте.