Керування оновленнями на сотнях серверів Debian

Як ви вважаєте, які найкращі практики підтримувати десятки (якщо не сотні) серверів debian? Маючи на увазі, що:

• Є групи серверів (тобто однакові веб-сервери, сервери БД, ...)
• Існує декілька проблем Debian (lenny, etch)
• Запускати цикл на всіх серверах і робити оновлення & оновлення apt-get неприйнятно (тому що це я зараз роблю :)) Це повинно бути краще, ніж це!

В даний час, коли я нарешті закінчу всі оновлення, з'являється нове оновлення безпеки, і мені доведеться робити це заново.

Заздалегідь дякую спільноті за замовчуванням сервера!

Я використовую apt-dater для управління оновленням усіх моїх скриньок Debian. Здається, зробити трюк досить добре. Не намагався масштабувати це до сотень господарів.

Google вирішив це демаршалом:

http://code.google.com/p/debmarshal/

Що дозволяє схвалювати пакети із сховища вище за потоком для встановлення на ваших хостах виробництва.

Тоді ви можете просто запустити cron-apt в повністю автоматичному режимі.

Ось вступне відео:

http://www.youtube.com/watch?v=L3hRToC23mQ

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

Мені також не було зручно робити автоматичні оновлення таких речей, як MySQL або PostgreSQL, де випадкове оновлення вимкне сервіс, можливо, в середині дня. Вони все ще потребують оновлення вручну.

Spacewalk і Debmarshall виглядають як підходящі альтернативи для нашої лялькової схеми.

Мабуть, Spacewalk тепер має попередню підтримку для Debian. Це, можливо, разом з Лялькою було б моїм відправною точкою. Я впевнений, що хлопець, який розробляє підтримку Debian для Spacewalk, сподобається вам за те, що ви працювали з ним, щоб підняти підтримку Debian на більш високий рівень.

У способі натягуючих систем конфігурації, таких як Puppet, також є bcfg2 та cfengine. Одне або інше з них може добре відповідати вашим потребам. Я зараз розгортаю bcfg2 у своїй лабораторії.

Рішення може дати функція

Я не впевнений, якого типу рішення ви очікуєте. Ви, напевно, знаєте про роботу з Cron, але я б не оновлював системи в сліпому, оскільки потрібні втручання людини (і саме тому вони платять вам за це, правда?)

Якби у вас були повністю однакові системи, ви можете розглянути можливість використання чогось на зразок rsync для усунення відмінностей, але з'ясувати, які файли не для rsync може бути складним, і я б цього не робив під час роботи служб. Принаймні, сценарії оновлення створені для управління перезапуском послуг та об'єднанням у відмінності файлів конфігурації.

Можливо, якщо ви поясните, у чому полягає проблема у виконанні команд apt-get, ми могли б побачити того, чого ви хочете уникнути.

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

Ось кілька порад, як мінімізувати кількість речей, які потрібно оновити.

Встановлюючи Debian, не встановлюйте Desktop, якщо вам дійсно не потрібно використовувати X на цій консолі. Більшість серверів не потребує встановлення X. Це може значно зменшити кількість пакетів у системі, і тоді вам не потрібно буде оновлювати стільки пакетів.

Переконайтеся, що izvor.list включає лише сховища, які вам справді потрібні. Якщо ви експериментували з якимось сховищем і забули про це, можливо, ви вводите оновлення, які вам не потрібні чи не хочете.

Якщо у вас виникли проблеми зі сліпою роботою оновлень на виробничому сервері, будьте обережні, зверніться до посібників із оновлення Debian, коли є основне оновлення (4,0 до 5,0). Вони дуже добре пройдуть, якщо дотримуватись інструкцій щодо оновлення. Це не так просто, як запустити оновлення apt-get dist і перейти пішки. Іноді в інструкціях є навіть вказівки на те, коли запускати здатність, а не apt-get - в них є невеликі відмінності.

У вас зараз цей інструмент "оболонка танцюриста"? Мені це подобається і я його використовую. Але я не знаю, чи можете ви використовувати його для стількох хостів. Можливо, ви могли б спробувати ...

http://www.netfort.gr.jp/~dancer/software/dsh.html.en

І він у сховищі.

КластерSSH. Ви входите на всі сервери і даєте їм абсолютно однакові команди, тому ви також можете реагувати на діалоги. Якщо один сервер отримає додаткове запитання, просто натисніть на це, і він буде єдиним, хто відповість.

Я використовував його для оновлення 25 веб-серверів від etch до lenny. Працював як шарм.

http://sourceforge.net/projects/clusterssh/

Кластерний ssh ​​- хороша пропозиція.

debmarshal ще не є частиною debian - я навіть не впевнений, що це буде пакет - здається, це зовсім інша система зі спеціалізованим сховищем. За словами доповідача, це наразі вороже, не зручно для користувачів.

Схоже, Spacewalk є клоном мережі Redhat, принаймні у веб-інтерфейсі. У мене погані результати від використання Redhat Network для оновлення систем. Один раз він завис, без жодної причини, і призвів до відключення сервісу. Я оновлював yum одразу після цього, і це вирішило це чудово, тому я можу лише припустити, що проблема була в тому, що було з-за того, що збито з боку RHN. Інша річ, яка мені не подобається в оновленнях RHN, це те, що ви не знаєте, коли відбудеться оновлення, щоб спостерігати за проблемами.