Jump to content
Калькуляторы

Централизованное управление конфигами через SVN или аналоги

Не подскажите, как вы работаете с конфигами?

У меня сейчас с этим небольшой бардак — где-то конфиги сохраняются на FTP/TFTP, где-то просто логгируются управляющие сеансы, где-то ничего не сохраняется.

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

Не посоветуете какое-нибудь более-менее коробочное решение, чтобы самому все не делать?

Share this post


Link to post
Share on other sites

По взрослому, это, наверное NOC.

Я делаю вот на этом при помощи вот этого. Применяю только для D-Link, т.к. на доступе только он. Как раз в данный момент автоматизирую процесс.

 

Briseis шлет на устройство команду save config, через 5 секунд - upload config, еще через 5 - download config. Конфиги генерятся dracon'ом, который пишет в MongoDB все уникальное (неизвестный ранее MD5), что через него пролетело. И есть front-end для просмотра базы монго и поиска отличий в конфигах.

 

А так параллельно еще NOC собирает конфиги, но свой велосипед забавнее же. :)

Share this post


Link to post
Share on other sites

alibek

по-взрослому это будет поставить NMS от каждого вендора и собирать ими конфиги. ну правда NMS некоторых недовендоров это не умеют, так это оборудование не взрослое :)

 

вообще, rancid(хранение в cvs и git(последние версии)), noc(хранение в БД) или тупо свои скрипты(это будет быстрее чем устанавливать и настраивать noc)

Share this post


Link to post
Share on other sites

это будет быстрее чем устанавливать и настраивать noc

 

Ну NOC мне интересен безотносительно хранения конфигов, а как инструмент мониторинга/учета.

Я его правда сейчас не использую, но планирую со временем.

Однако насколько я понял, NOC просто хранит конфиги за определенный период времени.

CVS или SVN в этом плане удобнее.

Share this post


Link to post
Share on other sites

(это будет быстрее чем устанавливать и настраивать noc)

это в первый раз :)

на пятой попытке можно управиться часа за четыре :)

Share this post


Link to post
Share on other sites

zi_rus

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Однако насколько я понял, NOC просто хранит конфиги за определенный период времени.

diffы тоже поддерживаются

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

А на практике это требуется? В смысле как часто и по каким причинам требуется смотреть старый конфиг?

Чтобы узнать как были настроены вланы и интерфейсы, чтобы поднять что только что завалил? :)

Share this post


Link to post
Share on other sites

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

Не посоветуете какое-нибудь более-менее коробочное решение, чтобы самому все не делать?

Научить людей пользоваться git'ом не судьба?

Share this post


Link to post
Share on other sites

Научить людей пользоваться git'ом не судьба?

Кроме git'a потребуются костыли для опрашивания свичей и слива конфигов (ну на цисках есть archive, а на остальных?). Плюс еще неплохо бы валидацию прикрутить. Плюс...

Короче, одним git'ом тут точно не обойтись

Share this post


Link to post
Share on other sites

Научить людей пользоваться git'ом не судьба?

Зачем давать на откуп фактору человеческих ошибок то, что можно автоматизировать?

Share this post


Link to post
Share on other sites

А на практике это требуется? В смысле как часто и по каким причинам требуется смотреть старый конфиг?

Чтобы узнать как были настроены вланы и интерфейсы, чтобы поднять что только что завалил? :)

 

реально требуется. я как-то искал одного клиента с белыми /30 в конфигах за 10 лет (тупо grep-ом). или например после модернизации что-то забыто или ещё что-то, вообщем много вариантов

Share this post


Link to post
Share on other sites

Да, реально требуется. Особенно если вы не единственный кто может завалить.

Тем более что диффы весят немного, особенно если вырезать из конфига всякие ненужные динамические строки типа "generated <дата время>" и закидывать только реально изменившиеся конфиги

Share this post


Link to post
Share on other sites

Кроме git'a потребуются костыли для опрашивания свичей и слива конфигов (ну на цисках есть archive, а на остальных?). Плюс еще неплохо бы валидацию прикрутить. Плюс...

Короче, одним git'ом тут точно не обойтись

Какой-то бардак.

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

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

Share this post


Link to post
Share on other sites

У меня вот нет таких проблем. Речь про коммутаторы доступа или про агрегацию/ядро?

На доступе у меня настройки условно разбиты на 3 части:

1. Управление. Настраивается вручную 1 раз при установке устройства.

2. Пользовательские vlan'ы. Также настраиваются 1 раз вручную при установке. При схеме vlan-на-свич у меня редко когда больше 2-3 пользовательских vlan на коммутаторе.

3. Все остальное. Генерируется на 100% автоматически.

 

То есть если не крутить управление и эти 2-3 влана, то сломать попросту нечего, хоть 1 человек ковыряется, хоть 10. Если вдруг что-то не так - просто заливаем с сервера конфиг, который будет сгенерен как раз в этот момент и потому актуален.

 

Нет такого, что кто-то постоянно копошится, экспериментирует, правит, пробует и т.п. Новые фичи отлаживаю я, затем применяю в генераторе конфигов и дальше все просто.

 

С агрегацией/маршрутизацией чуть иначе, там 100% ручные настройки, но сеть не так часто перестраивается, чтобы там что-то менялось. Глобальные изменения делает один человек, протаскивать вланы могут все. Но и тут не возникает нужды постоянно делать диффы и что-то там искать.

 

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

Edited by xcme

Share this post


Link to post
Share on other sites

Понимание того что это бывает полезно приходит с третьей-четвертой сотней l3 свитчей/роутеров или тысячей пятидесятой свитчей доступа. Потому что к этому времени в них начинают ковыряться шаловливые ручки дежурных администраторов, младших администраторов, просто неадекватных администраторов. И офигенно удобно когда что-то "само сломалось" просто глянуть дифф и увидеть что поменялось в конфиге.

 

Git неудобно. Ибо нужно обвешивать костылями сбора и заливки, жрет больше места, нужно как-то бэкапить и реплицировать, геморройно искать, сложно и неудобно интегрировать в морду мониторинга (и еще более сложно научить пользоваться людей без нее), валидация вообще из области фантастики. А монгу можно поставить из репозитория одной командой. Ну и вся реализация gridvcs у меня по мотивам noc занимает полсотни строк, которые оформляются как модуль.

 

Заливать что-то в конфиг из таких мест вообще зло. Как вы будете проверять что все дошло и корректно применилось? А если неправильно и вы сломали пару тысяч/десятков тысяч свитчей? Деплой изменений вообще отдельной системой делать нужно, причем бОльшая часть кода в ней это проверки.

 

И поверьте, я пробовал git, svn, mercurial, хранение тупо в файликах и все это сливает текущему решению по полной.

Share this post


Link to post
Share on other sites

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

вся реализация gridvcs у меня по мотивам noc занимает полсотни строк, которые оформляются как модуль

Поделитесь? Интересно на код взглянуть.

Share this post


Link to post
Share on other sites

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

...

И поверьте, я пробовал git, svn, mercurial, хранение тупо в файликах и все это сливает текущему решению по полной.

Неа, git вы вообще никогда не видели в глаза. Как и mercurial.

Их, в отличии от всякого древнего хлама, типа svn и cvs, не нужно ни бэкапить, ни реплицировать. Не нужно ставить никакие монги и серверы репозиториев. Нужно только научиться пользоваться.

 

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

Share this post


Link to post
Share on other sites

Неа, git вы вообще никогда не видели в глаза. Как и mercurial.

Их, в отличии от всякого древнего хлама, типа svn и cvs, не нужно ни бэкапить, ни реплицировать. Не нужно ставить никакие монги и серверы репозиториев. Нужно только научиться пользоваться.

 

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

До. Не нужно. Нагрузка на сервер зашкаливает - реплицировать и размазывать не нужно. И диски не дохнут в серверах никогда. А есличо, потерянные данные лично Линус Торвальдс восстановит. Да и разворачивать сам хаб у себя не нужно, гит в светоносном эфире хранит все и работает. Или вы из этих, любителей на сервера сторонних сервисов где-то в интернете выкладывать?

 

Интересная идея запретить. Запретить всему штату инженеров трогать что-либо и потом просто жить на работе ничего не успевая. А есличо и в другой город мотнуться не проблема там поработать часик. Хайлоада и больших масштабов вы походу не встречали, уважаемый.

 

Поделитесь? Интересно на код взглянуть.

Так прямо в NOC Project в открытых сорцах модуль gridvcs лежит, гуглится за пару минут. Я его только под реалии нашей системы мониторинга подправил немного.

Share this post


Link to post
Share on other sites

До. Не нужно. Нагрузка на сервер зашкаливает - реплицировать и размазывать не нужно. И диски не дохнут в серверах никогда. А есличо, потерянные данные лично Линус Торвальдс восстановит. Да и разворачивать сам хаб у себя не нужно, гит в светоносном эфире хранит все и работает.

Не позорьтесь, такой бред писать, почитайте о работе git хоть немного.

Share this post


Link to post
Share on other sites

Ну просветите меня. Что такого космического умеет нынче гит что спасёт хранилище от сдохших дисков или размажет запись по нескольким серверам?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this