LINUX.ORG.RU

Бест практис по апгрейду ОС на серверах

 ,


0

1

Всем привет. Хочу развернуть еще одну вирталку на Debian 9. Сейчас одна уже в работе и это версия 8.9 в качестве DC. Работает, каши не просит. Но всегда ж лучше когда у тебя не зоопарк из разых версий, а все примерно одинаково.

Поэтому возник вопрос, а есть ли какие то бест практис по апгрейдам боевых серверов до свежих релизов? Не конкретно Debian или даже *nix, а в общем. Здравый смысл конечно подсказывает что лучше этого не делать:) Но все равно интересно. Нужно ли это делать вообще, если все работает или забить на это дело до наступления EOL?


Обычно у людей есть предпродакшен системы, на которых все заранее проверяется

annulen ★★★★★
()

Нужно ли это делать вообще, если все работает

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

ving2
()

Зависит от сервисов и характера обновлений. Схематически вот так:

Security апдтейты на любые сервисы - подъем тестовой платформы, апгрейд (строго говоря, я сторонник всегда иметь тестовый инстанс, но на текущей работе не практикуют, поднимают только по необходимости). В случае успеха тестирования - согласование даунтайма с руководством и в согласованное время накатываем на прод.

Минорщину (любой апгрейд, который не security и не имеет отношения к бизнесу) - не накатываем в принципе, держим до EOL.

Апгрейд бизнес-систем - чаще всего поднимается новая инсталляция на актуальном железе/софте, трафик переключается на нее, старая лежит месяц на случай непредвиденного отката, затем демонтируется.

Ну и в классической ситуации «нафиг не надо, но генеральный захотел» - танцуем по ситуации.

А, ну да, забыл. На некоторых системах предусмотрен CD. Не люблю такие, но случается - апгрейдятся сами, ловим баги на ходу.

l0stparadise ★★★★★
()
Последнее исправление: l0stparadise (всего исправлений: 2)
Ответ на: комментарий от l0stparadise

Спасибо всем ответившим.

Сделал вывод что in place апгрейды между релизами стоит делать только в случаях крайней необходимости, если сервер в продакшене. Если уж очень нужно/хочется, то либо делать фреш инстал, либо хорошенько забэкапиться+заиметь четкий и быстрый recovery plan на случай фейла. Но лучше фреш инстал наверное, ведь кто знает какие баги могут вылезти уже после тестирования на предпродакшене. Я правда с этим никогда не сталкивался, только предполагаю что такое может быть.

N-N
() автор топика

Зависит от реализации. Можно вообще держать всё в cobbler+ansible+git.

И тогда, вообще говоря, «строить мир» на каждый релиз как ОС, так и аппликухи: начиная пямо с создания виртуальной машины.

Если же полчаса-час простой продакшна по ночам допустим, то самый бескровный вариант: останавливаем VM прода, делаем снапшот (как вариант - клон) вирты, включаем VM прода и накатываем апдейт. Сдохнет с апдейта - возвращаем клон.

slamd64 ★★★★★
()

1) накопитель ленточный -1шт
2) кассеты для накопителя - 2шт
3) диск жесткий, запасной - 1шт

:-)

Deleted
()

Мне нравится подход инфраструктура-как-код. Но такое прокатывает не со всеми приложениями, особенно виндовыми, особенно скулями.

stave ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.