Я управляю около 30 серверами Ubuntu, используя Puppet. Я видел много ссылок на cron-apt и apticron как на подходы к обновлению своих пакетов, но я не смог найти способ централизованно управлять процессом. С помощью cront-apt / apticron мне все равно нужно было бы войти на каждый хост и aptitude updateвыполнить обновление. Не говоря уже о проверке уведомлений со всех 30 машин при каждом обновлении основного пакета.
Там должен быть лучший способ. Какие-либо предложения?
Пейзаж может быть интересен для вас. Это «официальный» инструмент управления для управления большими развертываниями Ubuntu, и Canonical, вероятно, очень хочет получить ваши деньги за его использование.
RE-EDIT:
Во-первых, отказ от ответственности; Я не использовал зеркалирование для Debian или Ubuntu, поэтому я не знаком с программным обеспечением.
Во-вторых, кажется, что apt-mirror будет «слишком тяжелым» решением, мои извинения. Первоначальная идея заключалась в том, что у вас будет отдельная тестовая машина (или тестовая среда, возможно, виртуальная машина?) Для развертывания обновления. Как только вы будете удовлетворены производительностью обновления, вы перетащите пакет в свое зеркало «развертывания» (из официальных источников будет локальное зеркало и дополнительное зеркало только для обновлений, которые вы хотите развернуть). Затем удаленные машины будут запускать обновление в заранее установленное время и извлекать его из зеркала «развертывания» на каждую машину, задание cron, состоящее из:
apt-get update && apt-get upgrade --quiet --assume-yes
К сожалению, когда я начал читать подробности, кажется, что apt-mirrorон потянет все виды вещей, а не только пакеты, которые вы ищете. Итак, я собираюсь отказаться от этой идеи, хотя концепция имеет некоторые достоинства.
Сотрудник обнаружил и кратко изучил apt-dater, который является «удаленным диспетчером обновления пакетов на основе терминала».
Вы используете интерфейс на основе curses для управления обновлениями на всех ваших хостах или группах хостов и т. Д. Поддерживает ведение журнала полного сеанса, включая любые ошибки, которые могут возникнуть, и т. Д.
Полагается на ssh и sudo на управляемых машинах.
см. http://www.ibh.de/apt-dater/
Сам не использовал, так что я не могу это одобрить, но это звучит близко к тому, что вы ищете.
источник
Поскольку вы уже используете Puppet, самый простой способ сделать это (и лучший для целей управления изменениями / отслеживания) - указать нужную версию пакетов, которые вы хотите установить в манифесте puppet. Вы следите за списком объявлений о безопасности, и когда что-то, что вы используете, проходит через вас, просто обновите Puppet, чтобы сказать «установить эту новую версию этого пакета». Предполагая, что вы используете контроль ревизий в своих манифестах, вы затем знаете, когда была изменена «политика», и отчеты из Puppet точно показывают, когда именно это изменение было внесено (так что вы можете легко сопоставить это с любыми последующими событиями журнала).
источник
Посмотрите на clusterssh (apt-get install clusterssh):
$ cssh server1 server2 server3 ...
источник
Не задумываясь об этом раньше, моей первой идеей будет нечто похожее на то, что предлагал Эйвери, особенно если у вас уже есть тестовая среда.
По сути, вы настраиваете свои производственные машины на автоматическое обновление с вашего собственного локального репо, и вы обновляете этот репо только после того, как вы обновили свою тестовую среду до самой новой версии того, что вы запускаете.
Apticron не очень хорошо масштабируется, он спроектирован для работы в довольно небольших средах, но у него есть несколько положительных моментов:
источник
Иногда назад я писал низкоуровневый / грязный сценарий автоматизации Fabric (fabfile), чтобы удовлетворить аналогичные требования, вы можете проверить его по адресу:
https://gist.github.com/lgaggini/2be3c5bb47b8ce9267bd
источник