Как вы думаете, как лучше всего поддерживать десятки (если не сотни) серверов debian в актуальном состоянии? Помня, что:
В настоящее время, когда я, наконец, завершаю все обновления, появляется новое обновление безопасности, и мне приходится делать это снова и снова.
Заранее спасибо сообществу serverfault!
я использую умелый для управления обновлением всех моих ящиков Debian. Кажется, достаточно хорошо справляется с задачей. Однако не пробовал масштабировать его до сотен хостов.
Google решил это с помощью debmarshal:
http://code.google.com/p/debmarshal/
Это позволяет вам утверждать пакеты из вышестоящего репозитория для установки на ваши производственные хосты.
Тогда вы можете просто запустить cron-apt в полностью автоматическом режиме.
Вот вступительное видео:
Мы пробовали использовать марионетку для обновления исправлений безопасности для несущественных пакетов. Мы запускали apticron, чтобы отправлять по электронной почте список обновлений для каждого сервера, а затем ежедневно запускать сценарий, который объединял эти обновления в файл манифеста марионетки, который давал пакет и версию для каждого распределения. Затем это обновит кучу файлов на отдельных серверах и запустит сценарий обновления, когда пакет нуждается в обновлении. Это работало неплохо, но мы еще не тестировали его так, как хотелось бы. Эта схема обошла ограничение Puppet, заключающееся в том, что один и тот же ресурс не был определен в нескольких местах.
Мне также было неудобно выполнять автоматическое обновление таких вещей, как MySQL или PostgreSQL, когда случайное обновление отключало бы службу, возможно, в середине дня. Для них по-прежнему потребуется обновление вручную.
Spacewalk и Debmarshall действительно выглядят подходящими альтернативами нашей марионеточной схеме.
По-видимому, Выход в открытый космос теперь есть предварительная поддержка 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. Работал как шарм.
Cluster ssh - хорошее предложение.
debmarshal еще не является частью debian - я даже не уверен, что это будет пакет - кажется, это совершенно другая система со специализированным репозиторием. Как сказал спикер, в настоящее время это враждебно для пользователя, а не для пользователя.
Spacewalk кажется клоном Redhat Network, по крайней мере, в веб-интерфейсе. У меня были плохие результаты от использования Redhat Network для обновления систем. Один раз он завис, без видимой причины, и вызвал сбой в обслуживании. Я сделал обновление yum сразу после этого, и он справился с этим отлично, поэтому я могу только предположить, что проблема была связана с чем-то, что заблокировано на стороне RHN. Еще одна вещь, которая мне не нравится в обновлениях RHN, - это то, что вы не знаете, когда произойдет обновление, чтобы следить за проблемами.