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

[alibek]

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

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

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

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

[xcme]

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

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

 

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

 

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

[DejaVu]

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

[s.lobanov]

alibek

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

 

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

[alibek]

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

 

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

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

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

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

[alex39x]

У нас rancid + cvsweb.

[zi_rus]

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

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

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

[s.lobanov]

zi_rus

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

[zi_rus]

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

[Night_Snake]

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

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

[sexst]

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

[xcme]

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

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

[ttttt]

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

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

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

[Night_Snake]

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

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

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

[alibek]

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

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

[s.lobanov]

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

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

 

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

[sexst]

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

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

[ttttt]

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

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

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

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

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

[xcme]

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

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

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

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

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

 

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

 

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

 

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

 

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

Edited July 16, 2015 by xcme

[sexst]

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

 

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

 

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

 

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

[nu11]

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

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

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

[ttttt]

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

...

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

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

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

 

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

[sexst]

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

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

 

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

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

 

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

 

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

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

[ttttt]

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

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

[sexst]

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