LINUX.ORG.RU
ФорумAdmin

Хранить в svn конфиги серверов.

 


0

3

День добрый, собираюсь хранить в свн конфиги большого кол-ва серверов (200+ штук, разбитых на ~40 категорий)

Подскажите, есть ли какие best practices для этого? С свн до этого не особо работал, но разберусь :) Главное подскажите куда копать

★★★

Ответ на: комментарий от KennyMinigun

Лучше завести конфиги в puppet, а вот конфиги самого puppet в git или mercurial, да. :)

strangeman ★★★★
()

По поводу svn вообще никаких приличных слов в голову не приходит. С гитом/меркуриалом разберёшься, ничего архисложного. Возможно, для руления категориями и серваками ветки окажутся полезными.

const86 ★★★★★
()

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

pztrn ★★★★
()

Первое что хочу сказать - ну слушай этих фанатов git и mercurial. Они кроме распределенных систем ничего не видят и о недостатках говорить не любят.

Лично я пользуюсь svn. Из достоинств:
- простая для понимания (git, говорят, по началу моск ломает)
- делает все, что нужно (пользуюсь с двух компов)
- централизованный репозиторий; как по мне удобно с точки зрения администрирования и когда захочется забекапить; в репозитории хранятся все версии, на локальном - только последняя (в децентрализованных, как я понял, ты конфиги всех компов будешь хранить на всех компах, пусть меня поправят, если я не прав; особенно пухнет если много бинарных данных)
- кросс-платформенность: хорошие клиенты (в т. ч. WEB, где-то видел плагин для dolphin, встраивается в MS Windows explorer), такие плюшки как преобразование символов перевода строки, полезно если захочешь Линуксовый конфиг посмотреть в Windows.

Недостатки:
- да, для работы с репозиторием нужно подключение к нему по сети
- медленней по сравнению с децентрализованными (если лишние 5-10 секунд для тебя принципиально).
- если будешь переименовывать/перемещать файлы, то в CVS нужно лишние телодвижения чтобы оно отследило эту операцию, иначе будет трактовать как удаление + добавление. В git или mercurual оно, AFAIK как-то это отслеживает.

Как по мне для твоей задачи SVN самое оно.

Это мое ИМХО. Послушай и других. Дальше решай.

Если устраивает (а меня даже очень), то вперед.

А из best practices - там все просто. Рекомендую почитать svn book: http://svnbook.red-bean.com/

Советы:
- настрой список файлов, которые нужно игнорить - например файлы типа abc.txt~ - бекап, созданный kwrite
- проследи чтобы нормально определяло текстовые и бинарные файлы; например, по началу оно у меня XML почему-то воспринимало как бинарный. Да и вообще проверь mime-types.
- настрой чтобы оно конвертило end-of-line символы при переносе на другие платформы.
- рекомендую делать отдельный репозиторий на один комп/набор конфигов.
- перед комитом делай svn status, ну, а если у тебя все будет в одном репозитории (но в разных каталогах), то svn update
- обязательно пиши осмысленные комментарии коммитам.

Если что, обращайся.

Kroz ★★★★★
()
Последнее исправление: Kroz (всего исправлений: 3)
Ответ на: комментарий от Kroz

простая для понимания (git, говорят, по началу моск ломает)

У меня было наоборот, гит по-моему как раз очень логичный и простой, свн шёл с трудом.

делает все, что нужно (пользуюсь с двух компов)

Я за месяц так и не нашёл возможности посмотреть всю активность в проекте (все коммиты во всех ветках)

кросс-платформенность: хорошие клиенты (в т. ч. WEB, где-то видел плагин для dolphin, встраивается в MS Windows explorer),

Все пункты есть и для гита, но интеграции особо и не нужны, ты сам описал почему.

преобразование символов перевода строки

Тоже настраивается в гите, но не нужно, редакторам давно плевать на такие мелочи, если это не блокнот.

В git или mercurual оно, AFAIK как-то это отслеживает

Вроде никак не отслеживает, ему откровенно пофиг что ты делал с файлами, важна только разница во время коммита.

...Звучу как фанатик, знаю.

Kalashnikov ★★★
()
Ответ на: комментарий от dbzer0

Не вижу причин чтобы не использовать SVN.

  • У серверов права только на read конфиг файлов.
  • У каждого сервера checkout только своей/своих директории
  • Коммитить можно только с локальных мест администратора.
  • Puppet - это следующий шаг, как и OpenLDAP

    GIT в этом случае не предоставляет никаких преимуществ

trofk ★★★
() автор топика
Ответ на: комментарий от Kalashnikov

...Звучу как фанатик, знаю.

Есть такое.

Честно, не со всем согласен, но не хочу начинать холиворов.

Ты бы лучше расписал плюсы и минусы git/mercurial , т. е. взвешенную оценку. От человека, который этим пользуется, это будет более объективно. А остальным полезно. Чтобы лучше понять когда использовать, а когда нет. За одно из категории «фанатики» выпадешь :P

Kroz ★★★★★
()
Ответ на: комментарий от trofk

Да, и готовься к кривому мерджу, а значит и ручному слиянию веток, если работаешь не один, готовься к тормозам и к тому, что svn в наше время умерло тоже готовься :)

dbzer0
()
Ответ на: комментарий от Kroz

простая для понимания (git, говорят, по началу моск ломает)

git clone git@server:config.git

изменения...

git add .
git commit -m "обновлен конфиг nginx"
git push

Ломает, да.

dbzer0
()
Ответ на: комментарий от dbzer0

Мержить у нас никто не будет. Организация работы такая. Хорошо это или плохо, но это так

trofk ★★★
() автор топика
Ответ на: комментарий от dbzer0

dbzer0 Если ты считаешь что необходим git вместо svn, то обьясни, пожалуйста, причины?


С учетом моих комментариев

У серверов права только на read конфиг файлов.
У каждого сервера checkout только своей/своих директории
Коммитить можно только с локальных мест администратора.

trofk ★★★
() автор топика
Ответ на: комментарий от dbzer0

вот почему не будем использовать CVS,

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

если было бы, то может и использовали бы :)

trofk ★★★
() автор топика

Хранить в git конфиги серверов.

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

//тред не читал

aol ★★★★★
()
Ответ на: комментарий от trofk

Все просто, git не имеет минусов, в отличие от svn. Для чего использовать заведомо худший продукт?

Ушел от SVN 4 года назад на Git и очень рад этому до сих пор.

dbzer0
()
Ответ на: комментарий от trofk

В git хочешь использовать с централизованный репозиторий - используй - это всего лишь уровень абстракции.

Хочешь мержить - мерж сначала у себя, чтобы не ждать 3 часа мерджа в удаленном репозитории SVN.

Push изменения когда тебе нравится.

dbzer0
()
Ответ на: комментарий от aol

конфиги однотипные чтоль

200+ штук, разбитых на ~40 категорий

вообще паппеты есть всякие еще

  • Puppet - это следующий шаг, как и OpenLDAP

    уже написал

trofk ★★★
() автор топика
Ответ на: комментарий от trofk

GIT в этом случае не предоставляет никаких преимуществ

Главное и основное - распределенность. На всех серваках хранится полный реп конфигов для всех других. Если у тебя падает SVN-хост, конфиги ты будешь собирать по кусочкам со всех хостов заново (ну или копаться в бэкапах). В случае гита - поднимаешь сервак обратно, git clone с любого работающего и вуаля

marvin_yorke ★★★
()
Ответ на: комментарий от Kalashnikov

В git или mercurual оно, AFAIK как-то это отслеживает

Вроде никак не отслеживает

В hg по умолчанию отслеживает просто переименование, и вроде даже пытается определить был ли файл изменен после переименования, если указать:

--similarity

orm-i-auga ★★★★★
()
Ответ на: комментарий от dbzer0

Не понимаю, о чем Вы коммит делает 1 команда:

git add .
git commit -m «обновлен конфиг nginx»
git push

Что из add, commit, push делает коммит и зачем тогда нужны остальные, если я просто хочу сделать коммит?

Kroz ★★★★★
()
Ответ на: комментарий от marvin_yorke

можно и одной коммандой git commit -am «обновлен конфиг nginx»

duck
()
Ответ на: комментарий от Kroz

add - добавить файл в индекс

commit - СДЕЛАТЬ КОММИТ

push - ЗАЛИТЬ в удаленный репозиторий, если надо

PS: если хотите, я лично для Вас напишу скрипт, делающий это все одной командой :)

dbzer0
()
Ответ на: комментарий от dbzer0

Продукт умирает тогда, когда его не используют новые пользователи

По данным статистики использования пакетов Linux-дистрибутивов Debian[9] и Ubuntu[10], количество активных пользователей Subversion примерно такое же, как у Git, и превосходит аналогичный показатель для CVS, Mercurial и Bazaar (по состоянию на июнь 2011 года).

http://ru.wikipedia.org/wiki/Subversion

Skolotovich ★★★
()
Ответ на: комментарий от Skolotovich

В последних версиях это вылечили, кажется

gwinn ★★★★
()
Ответ на: комментарий от duck

это пофиксили вроде с 1,7 версии

у меня 1.6.18, надо будет глянуть

Skolotovich ★★★
()
Ответ на: комментарий от dbzer0

Вы очередной раз пропустили слово НОВЫЕ :)

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

Skolotovich ★★★
()
Ответ на: комментарий от dbzer0

Все просто, git не имеет минусов, в отличие от svn.

В git уже можно сделать clone только для поддерева (не всего репозитория), что-то поменять и сделать push?

Толстые бинарники со всеми своими версиями лежат в каждом клоне, занимая много места, разве это плюс?

kamre ★★★
()
Ответ на: комментарий от marvin_yorke

У тебя было «обновлен конфиг», а не добавлен. :)

zz ★★★★
()
Ответ на: комментарий от kamre

В git уже можно сделать clone только для поддерева (не всего репозитория), что-то поменять и сделать push?

Конечно же нет и никогда не будет, ибо он распределенный, а значит всегда содержит полный реп и это плюс.

Толстые бинарники со всеми своими версиями лежат в каждом клоне, занимая много места, разве это плюс?

А для чего хранить бинарники в git?

dbzer0
()
Ответ на: комментарий от marvin_yorke

Неправильно прочитал, нет не добавляет, комитит только изменения в трекаемых файлах.

zz ★★★★
()
Ответ на: комментарий от dbzer0

Конечно же нет и никогда не будет

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

А для чего хранить бинарники в git?

Т.е. версионировать нужно только plain text, для остальных сложных документов вроде картинок/звуков/... это типа «не нужно»?

kamre ★★★
()
Ответ на: комментарий от kamre

Т.е. версионировать нужно только plain text, для остальных сложных документов вроде картинок/звуков/... это типа «не нужно»?

Вы сами себе враг. Вам следует переделать систему сборки пакетов. Все бинарные данные должны вливаться на этапе сборки/тестирования. И уж точно не надо их хранить ни в одной из VCS.

dbzer0
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.