Перейти к содержимому
Калькуляторы

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

судя по вашим запросам вам нужен rancid :) http://www.shrubbery.net/rancid/

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

alibek

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

zi_rus

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

 

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

 

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

 

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

 

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

Изменено пользователем xcme

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

...

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

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

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

 

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.