Лучшие практики для обновления машин EC2 Ubuntu

12

После недавнего heartbleed уязвимости OpenSSL, я хотел бы, чтобы мои EC2 машины обновляются на регулярной основе. Наивным подходом было бы установить почасовую работу cron для обновлений безопасности ( sudo apt-get update && sudo unattended-upgrade).

Есть ли риск сделать это? Есть ли рекомендуемый механизм обновления для машин EC2?

unattended-upgrades

— Адам Матан
источник

13

Пакет автоматических обновлений - это стандартный способ автоматического применения важных исправлений ошибок и исправлений безопасности в Ubuntu.

Я рекомендую установить это в каждой системе Ubuntu:

sudo apt-get update &&
sudo apt-get install unattended-upgrades

Вам не нужно создавать свою собственную работу cron. Пакет устанавливает один для вас.

Вы можете изменить конфигурацию по умолчанию, если хотите изменить ее поведение: https://help.ubuntu.com/lts/serverguide/automatic-updates.html.

— Эрик Хаммонд
источник

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

— ianjs

3

Под «каждым» я имел в виду и производственные системы. Я автоматически применяю исправления безопасности для Ubuntu уже много лет и не могу вспомнить каких-либо серьезных проблем. Я нервничаю из-за того, что рабочий сервер сидит без патчей к известным проблемам безопасности и рискует их использовать. Тем не менее, каждая ситуация имеет свои потребности, поэтому вам лучше пройти этап тщательного тестирования для каждого патча. Имейте в виду, однако, что они выпущены все время, так что вы будете заняты.

— Эрик Хаммонд

1

Я не советую это, если у вас нет избыточной / кластерной установки. Процедуры обновления Ubuntu не подходят для работы, я останавливал службы несколько раз, а совсем недавно даже сломал загрузочный сектор ... И мы не делаем ничего особенного - только Apache в качестве приложений обратного прокси и Tomcat.

— сдал экзамен

1

Мы использовали unattended-upgradesс 2015 по 2020 год без проблем. У нас есть небольшая установка (на DigitalOcean) с:

nginx
mysql-server
php5-fpm php5-curl php5-mysql

Основываясь на хороших прошлых результатах, делать обновления таким образом удобнее, чем не делать это. Но это не обязательно гарантия будущего!

Это может быть не очень хорошая идея apache, основываясь на отчетах других пользователей и моем прошлом опыте apacheобновлений. [См выше и здесь ]

При этом unattended-upgrades, ручное вмешательство все еще потребуется, когда выпуск приближается к EOL .

(Помимо вопроса: по моему опыту работы с TWiki, WordPress и Jenkins, актуальность этих приложений на самом деле является более серьезной проблемой, чем сама ОС, хотя, конечно, мы должны действительно делать и то, и другое. Для спокойствия, Вы можете помещать приложения, работающие в Интернете, как «некорневые» процессы, работающие внутри контейнера Docker.)

Но так как вы спросили о передовой практике , основной подход, рекомендуемый в документации AWS :

Создайте и запустите новые экземпляры, чтобы заменить ваши текущие онлайн-экземпляры. Затем удалите текущие экземпляры.

Новые экземпляры будут иметь последний набор исправлений безопасности, установленных во время установки.

(Февраль 2020 г.)

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

Другие преимущества:

Тесты могут дать вам предварительное предупреждение, если требуется человеческое внимание (в отличие от того unattended-upgrades, когда предупреждения приходят от ваших пользователей только тогда, когда проблема существует!)
Если ваша система скомпрометирована или вы решили сменить провайдера, этот подход должен облегчить развертывание нового развертывания. Ваша стратегия развертывания основана на сценариях, а не на древней памяти.

Но, конечно, для этого подхода требуется больше настроек, чем просто установка unattended-upgrades, и сложность, поэтому все еще есть место для ошибки.

AWS также упоминает о выполнении «команды стека обновления зависимостей», которая, по-видимому, является их официальным способом сделать нечто подобное unattended-upgrades. Кажется, что это может быть вызвано из их интерфейса Instances, но я не уверен, может ли это быть автоматизировано.

— joeytwiddle
источник