Управление обновлениями на сотнях серверов Debian

Как вы думаете, как лучше поддерживать десятки (если не сотни) серверов Debian в актуальном состоянии? Помня, что:

• Существуют группы серверов (т. Е. Идентичные веб-серверы, серверы БД, ...)
• Может быть несколько проблем с Debian (lenny, etch)
• Запуск цикла на всех серверах и обновление apt-get && недопустимо (потому что это то, что я делаю в данный момент :)). Это должно быть лучше, чем это!

В настоящее время, когда я, наконец, закончу все обновления, будет опубликовано новое обновление безопасности, и мне придется делать это снова и снова.

Заранее спасибо сообществу serverfault!

Я использую apt-dater для управления обновлением всех своих коробок Debian. Кажется, сделать трюк достаточно хорошо. Хотя я не пытался увеличить его до сотен хостов.

Google решил это с помощью debmarshal:

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

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

Тогда вы можете просто запустить cron-apt в полностью автоматическом режиме.

Вот вступительное видео:

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

Мы пробовали использовать puppet для обновления исправлений безопасности для несущественных пакетов. Мы будем запускать apticron для отправки списка обновлений для каждого сервера по электронной почте, а затем ежедневно запускать сценарий, объединяющий эти обновления в файл манифеста, содержащий пакет и версию для каждого дистрибутива. Это затем обновит кучу файлов на отдельных серверах и запустит скрипт обновления, когда пакет нуждается в обновлении. Это работало разумно, но мы не проверяли это так, как хотелось бы. Эта схема обошла ограничение Puppet тем, что один и тот же ресурс не определен в нескольких местах.

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

Spacewalk и Debmarshall выглядят как подходящие альтернативы для нашей кукольной схемы.

Судя по всему, у Spacewalk теперь есть предварительная поддержка Debian. Это, возможно, вместе с Puppet, станет моей отправной точкой. Я почти уверен, что парень, разрабатывающий поддержку Debian для Spacewalk, полюбит вас за то, что вы работаете с ним над тем, чтобы поднять поддержку Debian на более высокий уровень.

На пути систем конфигурирования на основе pull, таких как Puppet, существуют также bcfg2 и cfengine. Один или другой из них может хорошо удовлетворить ваши потребности. Я сейчас запускаю bcfg2 в своей лаборатории.

Решение может быть дано func

Я не уверен, какой тип решения вы ожидаете. Вы, вероятно, знаете о рабочих местах в cron, но я бы не стал обновлять системы для слепых, поскольку необходимы вмешательства человека (и именно поэтому они платят вам за это, верно?)

Если бы у вас были полностью идентичные системы, вы могли бы рассмотреть возможность использования чего-то вроде rsync, чтобы внести различия, но выяснить, какие файлы не для rsync, может быть сложно, и я бы не стал этого делать во время работы служб. По крайней мере, сценарии обновления настроены для управления перезапуском служб и объединением различий в файлах конфигурации.

Возможно, если вы объясните, в чем проблема с выполнением команд apt-get, мы увидим, чего вы хотите избежать.

Если проблема заключается в пропускной способности и времени для загрузки, возможно, вам следует настроить один ящик в качестве локального репозитория Debian. Как это сделать, есть руководства Debian.

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

Когда вы устанавливаете Debian, не устанавливайте Desktop, если вам действительно не нужно использовать X на этой консоли. Большинство серверов не требуют X установлен. Это может значительно уменьшить количество пакетов в системе, и вам не нужно обновлять столько пакетов.

Убедитесь, что в sources.list включены только те репозитории, которые вам действительно нужны. Если вы экспериментировали с каким-либо хранилищем и забыли об этом, возможно, вы вносите обновления, которые вам не нужны или не нужны.

Если у вас возникли проблемы с слепым выполнением обновлений на рабочем сервере, будьте осторожны, обращаясь к руководствам по обновлению Debian, когда происходит серьезное обновление (4.0 до 5.0). Они пройдут очень хорошо, если вы будете следовать инструкциям по обновлению. Это не так просто, как запустить apt-get dist-upgrade и уйти. Иногда в инструкциях даже есть указатели на то, когда следует запускать aptitude, а не apt-get - в них есть небольшие различия.

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

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

И он в хранилище.

ClusterSSH. Вы входите на все серверы и даете им одинаковые команды, чтобы вы также могли реагировать на диалоги. Если один сервер получает дополнительный вопрос, просто нажмите на него, и он будет единственным, кто ответит.

Я использовал его для обновления 25 веб-серверов с etch до lenny. Работал как шарм.

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

Кластер SSH является хорошим предложением.

debmarshal еще не является частью Debian - я даже не уверен, что это будет пакет - похоже, это совершенно другая система со специализированным репозиторием. Как сказал докладчик, это в настоящее время враждебно для пользователя, а не для пользователя.

Spacewalk, похоже, является клоном Redhat Network, по крайней мере, в веб-интерфейсе. У меня были плохие результаты от использования Redhat Network для обновления систем. Один раз он завис без всякой видимой причины и вызвал перерыв в обслуживании. Я сразу же сделал обновление yum, и оно справилось с этим отлично, так что я могу только предположить, что проблема была в чем-то, что вызвало раздражение на стороне RHN. Еще одна вещь, которая мне не нравится в обновлениях RHN, это то, что вы не знаете, когда произойдет обновление, чтобы следить за проблемами.