Лучший способ сохранить файлы конфигурации под SVN?

Question

Каков наилучший способ сохранить файлы конфигурации (например, httpd.conf, my.cnf, .bashrc ...) под управлением версии? В дополнение к преимуществу версии я хочу, чтобы решение работало как резервное копирование, так что я могу принести новый сервер и проверить (или экспортировать) файлы конфигурации из SVN напрямую

Хорошее прикосновение будет для сохранения исходного пути файла config.

Answer 1

Я делаю это для нескольких машин, начиная от старых Solaris 8 ящиков для Mac OS X, и у меня есть очень простой макет:

В моем репозитории у меня есть следующие:

<root>/common 
    /.emacs.d 
    /.bash_common 
    /scripts # platform-independent binary tools 

<root>/linux 
    .bashrc 
    .emacs 
    ... 

<root>/solaris 
    .bashrc 
    .emacs 
    ... 

<root>/osx 
    .bashrc 
    .emacs 
    ... 

Каждый из homedirs ОС имеет ссылку svn: externals на .emacs.d, .bash_common и скрипты, поэтому они не дублируются.

Кроме того, у меня есть .bash_hostconfig в каталогах linux и solaris с настройкой пути к конкретному хосту и тому подобное, потому что у меня совсем другая настройка на работе, чем у меня дома (FC5-8 и RHEL3-5, в зависимости от того, где я).

Итак, между этими вещами у меня довольно простой процесс для запуска и запуска новой машины: я просто проверяю платформу/$ во временную директорию, а затем перезаписываю все в $ HOME этими файлами. Мне не нужно сохранять исходный путь, потому что он всегда относится к $ HOME таким образом.

Answer 2

I ревизия - контроль моих конфигурационных файлов, но я использую git вместо svn (что проще, когда у вас несколько компьютеров). У меня есть сценарий bash (называемый install.sh), также под репозиторием, который либо копирует, либо символизирует файлы в соответствующее место на машине.

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

Answer 3

Мы используем CVS для хранения конфигураций в структуре каталога, которая является как можно более плоской. Этот метод легко распространяется на SVN.

Тогда мы имеем Makefile настроены на использование экспорта CVS для:

1. создать копию структуры каталогов CVS без компонентов CVS,
2. создать структуру каталогов, необходимую для целевой машины в вашем локальный каталог, как если бы вы были в корневом каталоге на целевой машине, например ./my_cvs_dir/etc/ .. и ./my_cvs_dir/usr/local/newapp/..,
3. скопировать файлы из структуры CVS в структуру каталогов целевых,
4. создать архив для целевой структуры каталогов, и
5. Разверните tarball на целевой машине.

У нас также есть эти tarballs, созданные при повышении специализации, например. Sol10, Apache, конкретные приложения и т. Д.

НТН

веселит,

Роб

Answer 4

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

И это дерево можно было бы проверить на любом VCS, который вам нравится.

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

Answer 5

Это то, что я реализовал:

У меня есть сервер, который делает Rsync всех конфигов в одну директорию (скажем/данные/конфиги/имя хоста/{и т.д., HTTPD}

у меня есть. rsync работает каждый час, чтобы перенести изменения, как только rsync будет завершен, есть сценарий svnautocommit, который выполняет автоматическую модификацию изменений. Таким образом, я могу откатиться до любых изменений или любой другой версии, которую я хочу.

Возможно, вам потребуется запланировать структуру каталогов SVN на основе ваших требований.

Answer 6

Как вы хотите, центральный магазин в любом случае, вы можете пойти на что-то более сложное, например Slack. Вы управляете и управляете версиями файлов на push-сервере, а затем rsync его клиентам. В файле explanation of subroles есть несколько примеров того, как структурировать дерево.