Tuesday, August 23, 2011

Хранение конфигов unix-систем в VCS (или git sucks)

Как известно, большинство конфигурационных файлов в Unix-системах - это простые текстовые файлы. Они идеально подходят для хранения в системах контроля версий. Большинство статей по этой теме, которые мне встречались, советуют использовать git. Но по-моему, subversion (централизованная система) для этого подходит лучше.

Как это делаю я (заодно сравним subversion и git):

  1. Все конфиги хранятся в одном репозитории. Это упрощает изменение конфигов для нескольких хостов одновременно, в одном коммите. Соответственно, на каждой машине нужен чекаут определенной части репозитория (e.g. папки, в которой хранятся конфиги для данного хоста).



    Git не позволяет сделать чекаут произвольной папки в репозитории и работать с ней. Придется скачивать весь репозиторий целиком. В данном случае это влечет проблемы и с безопасностью, и с масштабированием. Subversion с этим отлично справляется.




  2. Каждая машина работает только со своими конфигами, т.е. с нее нельзя получить доступ к конфигам других машин.



    Subversion дает возможность контроля доступа к отдельным частям репозитория на стороне сервера (apache+mod_authz_svn). Тут я пожалуй сделаю такую оговорку: следует избегать копирования файлов внутри репозитория при одновременном ограничении доступа к частям репозитория. Например, если некий конфигурационный файл был скопирован из другого хоста (i.e. папки), и у пользователя нет прав на просмотр этой папки, тот же svn log будет работать некорректно. Выход - в использовании svn add вместо svn copy. В остальном схема хорошо себя зарекомендовала. Git, естественно, контроля доступа не поддерживает.




  3. Есть набор "глобальных" файлов, общих для всех хостов (например, настройки vim или screen).



    Subversion поддерживает механизм externals, который идеально подходит для этой цели. В git такой функции нет.



2 comments:

  1. Не сказал бы что "git sucks".
    Соответсвенно по пунктам:
    1. git имеет branch's
    2. Можно создать для каждого сервера по branch'у и забирать/обновлять только для сервера из его ветки. Или по проекту на сервер, это проще чем в svn.
    3. git submodule
    + есть
    Инструмент вторичен, кто чем может пользоваться тот с тем и работает.

    ReplyDelete
  2. Я имел в виду, "git sucks" для моей конкретной задачи :) На тот момент, когда я интересовался вопросом, git мне не подошел в силу некоторых ограничений.

    ReplyDelete