Время от времени я захожу в рабочие окна web/db/tools и вижу типичное сообщение:
Можно обновить 30 пакетов. 16 обновлений — это обновления безопасности.
Мой вопрос: как вы все справляетесь с обновлениями на ваших рабочих Ubuntu-боксах? Автоматизируете ли вы эти обновления? Устанавливаете ли вы для них время простоя? Проблема в том, что вы никогда не знаете, когда обновление что-то сломает, например, существующий файл конфигурации и т. д.
Другая часть этой проблемы заключается в том, что следить за патчами — это «хорошее дело», но патчи выпускаются почти ежедневно. Сколько запланированных отключений нужно сделать, если каждый день выходит новый патч безопасности?
Я думаю, что тема с ответами на вопрос о том, как вы управляете обновлениями, была бы очень полезна.
решение1
Нет ничего особенного в патче Ubuntu по сравнению с Windows, RHEL, CentOS, SuSE, Debian и т. д.
Основное состояние ума, в котором вы должны находиться при разработке процедуры исправления, — это предположение чего-товоляперерыв.
Вот некоторые из основных рекомендаций, которые я обычно использую при проектировании схемы патча:
- Всегда используйте локальную систему для централизации внутри вашей сети, откуда устанавливаются исправления.
Это может включать использование WSUS или зеркал <your_os_here>на внутреннюю машину управления исправлениями. Предпочтительнее тот, который может централизованно запрашивать и сообщать вам о состоянии исправлений, установленных на ваших отдельных машинах.
- По возможности заранее подготовьте установку на машины.
Когда это возможно, по мере выхода патчей центральный сервер копирует их на отдельные машины. Это действительно экономит время, так как вам не нужно ждать, пока они загрузятся И установятся, вам просто нужно запустить установку во время вашего окна патча.
- Получите окно отключения для установки исправлений, вам, возможно, придется перезагрузиться, и что-то, вероятно, сломается. Убедитесь, что держатели акций этих систем знают, что будут развернуты исправления. Будьте готовы к звонкам «это» не работает.
В соответствии с моей базовой теорией о том, что исправления ломают все, убедитесь, что у вас есть окно простоя, достаточно длинное для применения исправлений, чтобы устранить критические проблемы и, возможно, откатить исправление. Вам не обязательно нужно, чтобы люди сидели и тестировали после исправлений. Лично я в значительной степени полагаюсь на свои системы мониторинга, чтобы знать, что все функционирует на самом минимальном уровне, с которым мы можем обойтись без проблем. Но также будьте готовы к мелким раздражающим проблемам, которые будут вызваны, когда люди придут на работу. У вас всегда должен быть кто-то, кто будет готов ответить на телефонный звонок — желательно, чтобы не тот парень, который не спал до 3 утра, исправляя коробки.
- автоматизировать как можно больше
Как и все остальное в ИТ, скрипт, скрипт, и еще скрипт. Скрипт загрузки пакета, запуска установки, зеркала. По сути, вы хотите превратить патч-окна в задание по присмотру за детьми, которому просто нужен человек на случай, если что-то сломается.
- Иметь несколько окон каждый месяц
Это дает вам возможность не патчить некоторые серверы, если по какой-либо причине они не могут быть пропатчены в "назначенную ночь". Если вы не можете сделать это в ночь 1, потребуйте, чтобы они были свободны в ночь 2. Также позволяет вам поддерживать количество серверов, пропатченных одновременно, в разумных пределах.
Самое главноеследите за обновлениями!Если вы этого не сделаете, то вам придется делать очень большие 10-часовые окна исправлений, чтобы вернуться к точке, где вы наверстали упущенное. Это вводит еще больше моментов, где что-то может пойти не так, и делает поиск исправления, вызвавшего проблему, гораздо сложнее.
Другая часть этой проблемы заключается в том, что следить за патчами — это «хорошее дело», но патчи выпускаются почти ежедневно. Сколько запланированных отключений нужно сделать, если каждый день выходит новый патч безопасности?
Патчить сервер раз в месяц или раз в два месяца - IMHO - вполне достижимая и приемлемая цель. Более того, и вы будете постоянно патчить серверы, не говоря уже о том, чтобы реже, и вы начнете попадать в ситуации, когда у вас есть сотни патчей, которые нужно применить к каждому серверу.
Что касается того, сколько окон вам нужно в месяц? Это зависит от вашей среды. Сколько у вас серверов? Какое время безотказной работы требуется для ваших серверов?
Небольшие среды, работающие 9x5, вероятно, могут обойтись одним окном исправления в месяц. Крупным магазинам, работающим 24x7, может потребоваться два окна. Очень большим 24x7x365 может потребоваться скользящее окно каждую неделю, чтобы еженедельно обновлять разные наборы серверов.
Найдите частоту, которая подходит вам и вашей среде.
Следует помнить, что 100% актуальность — этоневозможныйЦель, которую нужно достичь — не позволяйте вашему отделу безопасности говорить вам обратное. Делайте все возможное, не отставайте слишком сильно.
решение2
Дела, которые необходимо сделать:
- Сделайте резервную копию
- Убедитесь, что это восстанавливаемая резервная копия (хотя эти два пункта являются общими)
- Постарайтесь направить трафик в сторону от производственного блока во время обновления.
- Постарайтесь использовать метод доступа по дополнительному каналу на случай, если что-то пойдет не так: KVM, последовательную консоль, локальный доступ или удаленное управление.
- Протестируйте на одном сервере, затем убедитесь, что все работает, прежде чем развертывать обновления на других серверах.
- По возможности используйте puppet, чтобы гарантировать, что номера версий на нескольких серверах одинаковы. (Вы также можете использовать его для принудительного обновления)
- На тестовом сервере сравните версии конфигурационных файлов с новыми (установленными обновлениями) и убедитесь, что ничто не может серьезно что-то сломать. Кажется, я припоминаю, что dpkg спрашивал перед установкой новых версий, которые отличаются от установленных в данный момент.
Чего следует избегать:
- Делаю обновления в середине дня, или в 09:00 утра в понедельник, или в 17:00 вечера в пятницу днем! (спасибо @3influence!)
- Обновление MySQL на действительно больших серверах баз данных (перезапуск может занять много времени)
- Выполнение всех ваших серверов одновременно (особенно ядер)
- Делать что-либо, что может изменить /etc/networks (потому что вы можете потерять подключение)
- Автоматические обновления, которые могут выполнять вышеуказанные действия без вашего участия и проверки того, все ли в порядке.
решение3
Стоит отметить еще один момент: если вы привыкли к Windows, вы будете удивлены, что большинство обновлений Linux не...неттребуют простоя или перезагрузки. Некоторые требуют, например обновления ядра. Но обновления, требующие перезагрузки или простоя, обычно помечаются как таковые и могут обрабатываться по отдельному расписанию.
решение4
Для систем Ubuntu LTS обновления выполняются следующим образом:
- Поддерживать набор приемочных тестов, которые проверяют все критические пути в нашем программном обеспечении.
- Устанавливайте обновления безопасности без присмотра в 4 утра каждое утро и немедленно запускайте приемочные испытания. Если что-то не получается, инженеру отправляется сообщение на пейджер, и у него достаточно времени, чтобы исправить что-то или откатиться до 9 утра. Это случалось только дважды за пять лет — LTS хорошо протестирован и стабилен.
- Мы автоматически переустанавливаем всю нашу инфраструктуру каждую неделю (на digitalocean) с помощью сине-зеленых развертываний, что позволяет поддерживать все пакеты в последних версиях. Если новое развертывание не проходит приемочные испытания, развертывание приостанавливается до тех пор, пока инженер не сможет устранить проблему.
Следующим логическим шагом для нас является устранение хранящейся в памяти информации о сеансах, чтобы мы могли просто повторно развертывать инфраструктуру каждый день или даже несколько раз в день, не влияя на клиентов, и устранение шага (2).
Такой подход не требует особого обслуживания и полностью исключает необходимость в периодах технического обслуживания.