Как хранить серверные конфиги в svn и их выкатывать?
Приветствую!
Есть такая проблема. Есть сервер, на нем стоит Apache, Tomcat и приложения. Конфиги апача обширные, помимо httpd.conf есть sites.d/*.conf, конфиги томката лежат понятно в другом месте и их там тоже букет.
По-мимо этого, два сервера тестовые, и еще n — продакшены. Они немного различаются (в частности количеством приложений и соответствующих конфигов под них).
Все это барахло хотелось бы контроллируемо мейнтейнить. А именно иметь историю правок (на ум приходит svn) и уметь все это централизованно выкатывать, желательно в каком-то автоматическом режиме.
Я плохо представляю вообще как этот процесс должен выглядить, поэтому свои пожелания я оставлю при себе, но очень хочу узнать как в этом случае поступают true админы?
Ну это уже хороший вариант, потому что не создает всяких ненужных файлов в etc, но хотелось бы конечно чего-то более автоматического, например пропатченный vi, чтобы при сохранении всегда комитил изменения и запрашивал комментарии к изменению, тогда не забудешь комитнуть и их указать. А я из доки не понял — он _только_ на etc?
именно он да, для /etc
по поводу автоматического, в настройках есть, скажем, опция для ежедневного автокоммита
опять же можно сделать с инотифи связку и коммитить сразу при записи файла
Самые тру админы делают Full Backup + ежедневные бекапы на ленты.
SVN изначально не очень правильное рещение для подобных вещей. Как костыль — сделайте папку, в которой симлинками накидайте нужные конфиги.
Саму папку загоните в SVN
Ну, полные бэкапы не отображают кто, что поменял. Плюс — все таки это более грубый вариант. Что если я внес несколько чейнджей? Короче, гибкость системы контроля версий, имхо, вещь полезная в таких работах. Вот только как система должна быт применена в таком процессе — вот вопрос.
Да, вы абсолютно правы по поводу изменений. Действительно вы не посмотрите историю изменений построчно.
Но могу сказать свое мнение по этому поводу: Существует ITIL, который четкого говорит что должен быть процесс Change Management применимый к Configuration Item
Далее есть тулза для CM — например ORTS. Там есть история изменений и т.д. куда в свободном виде или в виде файла складываются данные. Но это больше процессно-техническое решение, нежели чисто техническое.
Чисто технически я бы, наверное, сделал как описал выше.
Из моего опыта: процессно-техническое решение работает только тогда, когда оно не дает широких возможностей выстрелить себе в ногу, это значит оно должно быть подркреплено техническими решениями, сводящими человеческий фактор к минимуму, но не должна быть «чемоданом-без-ручки», т.е. быть помаксимому удобной
Папка с симлинками — штука хорошая, но она не даст возможность конфиги заливать в трэкинговую систему. Если конечно не сделать наоброт — конфиги положить в папку и сделать симлинки с мест их оригинального места пребывания
