Які існують рішення, щоб дозволити використання контролю версій для файлів конфігурації сервера? [зачинено]


85

В середовищі з декількома системними адміністраторами я бачу кілька переваг щодо додавання файлів конфігурації сервера в систему управління ревізією. Найбільш помітними є можливість відстеження змін, хто їх вніс, і, звичайно, можливість повернення до відомих робочих конфігурацій.

Мене в основному цікавлять рішення Unix / Linux, але мені також цікаво впровадження Windows.


Здається, дублювати або бути дуже пов'язаним з цим питанням serverfault.com/questions/3852/…
Zoredache

Відповіді:


52

Я тестую це вдома (~ 3 хости) вже деякий час, пробуючи різні scms (RCS, Subversion, git). Налаштування, яка зараз ідеально працює для мене, - це git with setgitpermsгак.

Що потрібно враховувати:

Обробка дозволів та прав власності на файли

  • RCS: робить це споконвічно
  • Subversion: останній раз я спробував, вам потрібна обгортка навколо , svnщоб зробити це
  • git: setgitpermsгак обробляє це прозоро ( post-checkoutхоча досить нова версія git із підтримкою гачків)

Крім того, якщо ви не хочете, щоб всі ваші /etcпід контролем версій, а лише ті файли, які ви насправді змінили (як я), вам знадобиться scm, який підтримує подібне використання.

  • RCS: так чи інакше працює лише на одних файлах.
  • Підрив: Я вважав це хитрим.
  • git: немає проблем, поставте " *" у .gitignoreфайл верхнього рівня та додайте лише ті файли, які ви хочете використовуватиgit add --force

Нарешті, є деякі проблемні каталоги в /etcяких пакети можуть впасти конфігурації фрагментів, які потім читають який - то програми або демон ( /etc/cron.d, /etc/modprobe.dі т.д.). Деякі з цих програм досить розумні, щоб ігнорувати RCS-файли (наприклад, cron), деякі - (наприклад, modprobe). Те саме і з .svn каталогами. Знову великий плюс для git (створюється лише один .git каталог верхнього рівня ).


1
Subversion потребує asvn svn.collab.net/repos/svn/trunk/contrib/client-side/asvn . Архів SVN (asvn) дозволить записувати типи файлів, які зазвичай не обробляються svn. Наразі це включає пристрої, символьні посилання та право власності / дозволу на файли.
Крістіан Ciupitu

У вас є запитання, де показано, як встановити використовувані гачки, тощо?
grufftech

Короткий опис
8jeд

Ось публікація про те, як налаштувати щось подібне в Arch Linux ARM, в цьому слід застосовувати однаково добре. zduck.com/2012/storing-your-raspberry-pi-config-in-git
silent__thought

28

Я робив це неофіційно з git, але є також проект etckeeper, який є більш комплементальним та детальним виконанням.


4
і т.д. Крім того, є інтеграція в APT, так що кожного разу, коли ви робите операцію apt-get, сховище / etc здійснюється і зберігається через ніч. Я використовував це деякий час, і в цілому це набагато краще, ніж використання VCS з ваніллю, якщо тільки для функції дозволів.
RichVel

23

Іншим варіантом є використання автоматизованого інструменту налаштування сервера, такого як Puppet або Cfengine, для скриптування конфігурацій вашого сервера декларативною мовою.

Це додаткова робота на передній частині, але використання такої утиліти, як Puppet, дозволяє автоматично відновити та налаштувати сервер з дуже невеликим втручанням людини.


5
Так, але ви також повинні переглянути ревізію ваших конфігурацій Puppet / CFengine. Я теж фанат перегляд контролюючого виходу , так що ви можете відповісти на питання «що був конфиг на дату х?» а також "яким повинен бути конфігурація відповідно до маріонетки?", а також співвідносити входи з виходами для усунення несправностей системи управління конфігурацією.
Роб Чентер

10

Я експериментував з etckeeper, який, здається, працює досить добре. Мені не потрібен централізований сервер, який може бути важливим у деяких ситуаціях. Ви можете використовувати декілька різних записів DVCS, щоб ви могли вибрати той, який вам найбільше знайомий. Здається, це працює дуже добре для мене, але я ще не намагався отримати інші технології, де я працюю, щоб почати його використовувати.


6

Я останнім часом заглядаю в шефа . Він не тільки зберігає шаблонні (.erb) конфігурації в контролі версій, але дозволяє виконувати дії (наприклад, перезапуск служби після завантаження конфігурацій у вузол). Шеф-кухар допомагає в управлінні пакунками, щоб ви могли перевірити залежності на будь-якому вузлі, з яким ви взаємодієте (тобто повинен бути встановлений пакет sudo). Шеф-кухар, здається, легко розширюється в Ruby, тому, якщо у вас є якісь спеціальні процеси, ви можете просто зафіксувати його в рамках.

Але все ще не пробували, і вам доведеться встановити Ruby на клієнті та сервері з відповідними дорогоцінними каменями (це насправді не так складно). Загалом виглядає дуже просто керувати багатьма серверами одночасно.


Ми досить широко використовуємо шефа (60+ серверів). Усі рецепти та конфігураційні файли перевіряються в Subversion.
organicveggie

3

Я зараз впроваджую Лялечку на всій нашій інфраструктурі, і це дуже сприяє утриманню її даних під контролем версій.

Я віддаю перевагу Mercurial, оскільки це просто колекція файлів з деякими метаданими, які зберігаються у прихованих каталогах (простий в управлінні, зрозумілий, простий у користуванні).

Мої файли ляльок знаходяться в / usr / local / etc / puppet / (FreeBSD 7.1). Все, що потрібно, щоб додати Меркуріал до нього:

> cd /usr/local/etc/puppet
> hg init

Усі зміни здійснюються простим "hg-дозволом". Якщо зміна щось потребує, я можу повернути кожен сервер до заданої версії файлу (скажімо, sudoers) за допомогою однієї команди.

Чудовий вступ до Меркуріалу


3

Я використовую Subversion на серверах, якими керую. Добре працює. Я також створив екземпляр Trac , тому у нас є перегляд часової шкали, система квитків, перегляд веб-сайтів тощо.

Використовуючи символьні посилання, cron та subversion, я також налаштував автоматизований розподіл конфігурації на основі сховища субверсії, де кожен сервер Linux оновлює сховище за svn updateдопомогою скриптів (наприклад, сценарії брандмауера).


2

Ось випадок використання реального життя: Використовується Subversion для управління файлами конфігурації на 4 різних серверах. Я рекомендую використовувати керування версіями для файлів конфігурації з тієї ж причини, що ви використовуєте їх з кодом - це резервна копія та кнопка скасування все в одному. Якби я керував набагато більшою кількістю серверів, і вони були набагато ближчі з точки зору конфігурації, я б використовував щось на зразок Лялечки, як це детально описано у відповіді Берберіха.

Ідея полягає в тому, що у вас може бути одне сховище, на якому ви можете перевіряти певні папки на серверах (наприклад, / var / name /), тому у мене є історія та резервна копія файлів конфігурації (резервна копія - бонус, якщо ви помилитесь використання програми конфігурації графічного інтерфейсу, яка видаляє додатки, відредаговані вашими руками, відредаговані кашлем Server Admin в Mac OS X Server кашель ). Тоді легко протестувати його на тестовому сервері та згодом оновити виробничий сервер файлами, які працюють без копіювання файлів вручну.


1

Я створив проект кілька років тому, щоб зробити саме це: Савон

Він використовує підрив для зберігання файлів і має деякі додаткові функції, такі як відстеження власності, дозволів та контексту SELinux. Це також дозволяє логічно розділити зміни вашої файлової системи на шари, так що ви можете, наприклад, відслідковувати зміни, які повинні йти на всі ваші веб-сервери окремо.



0

Більшою частиною змін ми керуємо за допомогою нашої служби довідкової служби, навіть для роботи з технічним обслуговуванням. Ми повільно переносимо свою документацію у вікі для власного використання та те, що ми публікуємо для кінцевих користувачів. Опублікувати зміни в конфігурації та обговорення за нею, приємно відкрити в нашій інтранети.


0

Протягом багатьох років я використовував rcs для файлів, які я почав змінювати, але пару років тому я почав ставити цілий / etc під контроль git. Це вимагає певної роботи, щоб перевірити файли в зернистих групах (іноді я вдаюсь до величезної "різних оновлень" реєстрації), і я написав кілька сценаріїв, щоб допомогти у цьому, але згадуваний etckeeper здається дуже цікавим, я спробую негайно.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.