Как обновлять Linux-сервер на проде?

Для этого есть бэкапы. И докер.

Много статей в интернете, как люди решаю такие проблемы. У них отдельно есть окружения для тестирования и staging. Если сайт не приносит достаточной прибыли для построения инфры, то можно прям и на проде. Варианты то тогда какие?

Понятно. То есть, только так? У нас есть бэкап. Обновляем. Если все ок – то ок. А нет – восстанавливаем бэкап, и забываем про обновления?

Так?

Про Докер услышал.

Понял. Да не знаю, какие варианты. Вот и спрашиваю.

Так-то я и сам представлял, что есть тестовое окружение. Но подумал спросить еще на форуме.

Ну если обновили, и что-то размотало → смотрите, что, чините. Если вообще никак, раскатываете обратно бэкап. А еще можно на тесте гонять сначала.

Собственно обновлять надо, критические уязвимости никто не отменял. И лучше ещё добавить apt autoremove, чтобы удалить старые версии ядер, потому что они иначе накапливаются, и, если раздел /boot недостаточно большой (а его обычно делают небольшим), то место на нём может со временем закончиться.

Если сайт очень ответственный, то тут, понятно, нужно предварительное тестирование, но для обычных сайтов надёжность официальных обновлений дистрибутива в целом можно посчитать достаточной.

По поводу неправильного времени, на 1 час - слишком похоже на ошибку, связанную с изменением данных часовых поясов или перехода на летнее/зимнее время, там точно не в самом движке сайта была ошибка?

Да, если у вас там не HA кластер, то небольшой даунтайм на

Люди вообще обновляют такие машины командами apt update && apt upgrade ?

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

после апдейта функция сайта на JS стала время на 1 час назад возвращать

Такое тоже бывает:

Или запустили сайт, и забили на машину?

но если проект живой, а не заброшеный, то это рак.

Лично у меня параноя с обновлениями, но только на stable. Я бы даже назвал себя - «мистер апдейт».
Если что-то поломалось, ну есть же логи, вдумчиво читаем что происходит и исправляем проблему.

Уже не помню, в чем ошибка была. Обновился пакет tz_data (или подобный, не помню). Скорее потому и сломалось потом время на сайте.

Но ситуация тогда была неприятная. :) причем, была тестовая машина – я сначала на ней oбновлял. На ней было ок. Но потом, оказалось, что на тестовой машине и на продовской – разные версии nodejs – поэтому на продовской выскочил глюк потом.

Но потом, оказалось, что на тестовой машине и на продовской – разные версии nodejs

А такое не должно быть возможно в принципе. Надо ставить две одинаковые системы и рулить ими через configuration management. Конфигурация лежит в гите, любое изменение накатывается сначала на стейдж, потом на прод. Деплой новой версии сайта — частный случай изменения конфигурации: меняется версия пакета, гитового тэга или что-то в этом духе. Тогда всё всегда будет одинаково, с точностью до одного тестируемого коммита.

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

Запустили новую тестовую машину. Установили mysql, nginx, nodejs. Еще что-то там. И вот, на новой тестовой машине более новая версия nodejs оказалась. Ну, теперь я понимаю, конечно, что неправильно так делать.

Да, это вручную делалось.

2 сервера с одинаковой конфигурацией — это уже «парк», нужны другие методы

Понял, спасибо. Погуглю подробнее про это.

Как обоновлять Linux-сервер на проде?

После теста не на проде )

proxmox (или другой гипервизер)
клонируешь vm, меняешь ip
обновляешь
проверяешь/чинишь
старый отключаешь
на новом меняешь ip

да небольшой просто будет на последних 2 этапах

Ставишь рядом временную копию сервера, переключаешь трафик на неё, обновляешь основной, добиваешься нормальной работы, перекидываешь трафик обратно на обновлённый сервер, сворачиваешь временный сервер.

Это если сайт должен 24/7 пахать и это очень критично.

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

Зачем обновлять-то? Да и что обновлять?

Если вам функций каких-то не хватает, то у соответствующего софта есть release & upgrade notes, где всё расписано. Если ваш собственный софт новой версии выпущен, то вы и так знаете, как его лучше обновлять.

От apt upgrade добра ждать вообще не стоит.

P. S. Если вот прямо невтерпёж обновить всё и вся, то поднимаете рядом ещё одну машину, разворачиваете туда свою инсталляцию с новыми версиями, смотрите, что всё ок с ней, переключаете на неё трафик, старую выключаете.

Зачем обновлять-то?

Чтобы уязвимости убирать в используемом софте

Да и что обновлять?

Используемый софт.

Чем дольше ты не обновляешь, тем быстрее растёт технический долг и тем толще и геморройнне будет процедура миграции на актуальные версии софта.

btrfs + docker.

Btrfs позволит быстро откатится на снапшот перед обновлением, если система сломается. А сайт упакованный в docker облегчит руление зависимостями проекта.

любое изменение накатывается сначала на стейдж, потом на прод

тут есть просторы для факапа

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

Если нужно работать 24/7 то всё хитрее и для этого желательно иметь ещё один сервер. Но судя по описанию это не ваш кейс.

Linux-сервер на проде: Ubuntu 24.04 LTS.

Ну вы понели (с)

Нормально, я ващпе Arch использую.

Порекомендую distrobox для поднятия локальной копии, если проект не хочется в докер заворачивать.

уязвимости … в используемом софте

процедура миграции на актуальные версии софта

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

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

Если используемый софт таков, что там регулярно обнаруживается уязвимость, то не нужно его использовать.

Что посоветуешь вместо ядра Linux? BSD?

Что посоветуешь вместо ядра Linux? BSD?

Ядро здесь на последнем месте. Какой-нибудь drupal или набор самописных cgi на perl более опасны.

Если используемый софт таков, что там регулярно обнаруживается уязвимость, то не нужно его использовать.

Ггг, «если у вас нет хлеба, просто ешьте пончики» (с) :)

Если используемый софт таков, что там регулярно обнаруживается уязвимость, то не нужно его использовать. Если обновления обратно не совместимы, то не нужны такие обновления.

Только где взять идеальный софт, без уязвимостей и где обновления никогда ничего не ломают? :-)

пирожные

Self-fix

Метод «херак-херак» не пробовал?

у меня тоже сайт на VPS требовательный к аптайму. но ночью и выходные мучать можно.

все настройки системы лежат в каталоге сайта. я их ссылками вывожу в каталог etc. т.к. сервер настраивал я то знаю на что надо обратить внимание. делаю инкрементальный бэкап сайта и БД. потом обновляю систему и сайт. успешно обновился с убунту 22.04 на 2404.

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

Или запустили сайт, и забили на машину?

это зависит от определённой владельцом важности сайта. Судя по

Есть Linux-сервер на проде: Ubuntu 24.04 LTS.

важность околонулевая.

Вообще, нужно поддерживать в актуальном состоянии и код и среду исполнения кода.

Как делаю я: втыкаю резервный, предварительно настроенный, сервер (кстати, вот он, под столом стоит), делаю бэкуп, обновляю, ставлю взад.

Профит!

Люди вообще обновляют такие машины командами apt update && apt upgrade ?

Да, для этого не нужен бэкап и докер, для этого нужен нормальный дистрибутив, коим является Debian и его хороший дериватив Ubuntu server.

резерв как у вас готовится? у меня сайт весит 250гигов. просто так его не скопируешь.

250 гиг кода? Или видосов?

Так же как и домашние задания делают в школе. Регулярно и часто. Тогда особых проблем не предвидится.

А если забить и ждать контрольной / пока петух не клюнет, то можно и огрести.

...просто так его не скопируешь.

А что, какие-то проблемы?

))) с 250 гиг можно только поулыбаться

я хотел узнать ваш опыт подготовки резерва. свой подход я уже описал. у меня инкрементальный бэкап с помощью duplicity. полный быкап на узком канале занимает много времени. а на самом VPS делать дорого и опять время.

Так что у тебя там на 250 гиг, сирьозный Йура? У нас, например, на одном из бэков (точнее, на одной из копий из одного из бэков)

92T   87T  5,6T  94% 
10T  109M   10T   1% 

Они, конечно, между собой синкаются.

Действительно, 250 гиг - это МНОГО *хохот на заднем плане* Это же ЦЕЛЫХ ПЯТЬ ФИЛЬМОВ!!!

ваше решение мне не подойдет. если я буду постоянно синхронизировать это удвоение стоимости хостинга. у вас судя по всему другие бюджеты. суть топика в безопасном обновлении системы и сайта. у меня место занимают в основном фото архив организации.

Можно поднять под кроватью s3, сделать от него vpn до твоей машины и скидывать копии-лишнее.

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

Сделай из vps кэширующий фронт с подкроватными бэками через vpn с балансировкой

У тебя все 250 гигов данных лежат там же, где и код? И ни то, ни другое никуда не бекапится и никак не проверяется? Скопировать куда-то код и проверить обновление без данных невозможно? Если да, то момент когда всё развалится, это просто дело времени.

Регулярно автоматически делаю apt update && apt upgrade. Когда получаю уведомления о security-апдейтах, ставлю их внепланово. Вот dist-upgrade между релизами - это уже отдельный вопрос. Тут надо готовиться и не спешить.

после апдейта функция сайта на JS стала время на 1 час назад возвращать

Вызывает вопросы. Или программисты привязывались к каким-то недокументированным функциям для расчёта времени. Или в процессе обновления по какой-то причине были изменены системные конфиги. Тогда вопрос к тому, кто делал обновление.

Так же я держу отдельные виртуалки для отдельных сервисов. Когда есть вероятность, что апдейт может что-то сломать(например, такое бывает при обновлении мажорных версий nextcloud), я делаю копию виртуалки с nextcloud, проверяю апдейт там. Если всё ок, переключаю проксирующий nginx на неё, старую виртуалку удаляю. Данные лежат вне виртуалки. База тоже и так же перед обновлением копируется. Но это не apt update && apt upgrade. Это именно обновление фронта и бека, которые управляются отдельно от системы.

Ну, можно хард воткнуть в мать или по сетке перебросить.

Но потом, оказалось, что на тестовой машине и на продовской – разные версии nodejs – поэтому на продовской выскочил глюк потом.

Освой docker и о таких проблемах забудешь как о страшном сне. Ну и оркестратор какой-нибудь для удобства, если проектов больше одного (хотя и с одним будет намного удобнее). Связка nomad+consul например. Плюсом сразу из коробки получишь мониторинг.