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

Замечательная программа является ShadowProtect., это делает ТОЧНО, что Вы хотите, можно смонтировать файлы резервных копий для получения идеального снимка того, как это в то время позволяло отдельное восстановление файла. Можно даже сделать виртуальную машину из сохраненного изображения в случае отказа.

Вы, вероятно, захотите использовать возрастающий.

Incremental=changes с тех пор в последний раз возрастающий. Если один файл в цепочке потерян, вся цепочка потеряна.

Дифференциал = изменения начиная с последнего полного резервного копирования. Размеры файла растут со временем, но зависимость находится ТОЛЬКО на защитнике.

Что-то еще можно хотеть рассмотреть: Некоторые консалтинговые компании IT делают BDR (скопируйте аварийное восстановление), планы, которые включают удаленные резервные копии и поддерживают Ваши резервные копии за ежемесячную плату обычно включая арендованный сервер и удаленное устройство хранения данных. Доверяйте мне, сохранение хорошего резервного копирования может быть большой работой.

2
задан 26 August 2012 в 00:45
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. Вы столкнетесь с этими проблемами при любом виде распределенного асинхронно синхронизированного общего обслуживания файлов.

очевидно, что вы можете сохранить конфликтующие изменения в двух разных ветвях репозитория, но сервер видит только одну ветку).

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

0
ответ дан 3 December 2019 в 15:40

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

0
ответ дан 3 December 2019 в 15:40

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

Файлы конфигурации см. на 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

Попробуйте.

0
ответ дан 3 December 2019 в 15:40

Теги

Похожие вопросы