Чому in-place upgrade Linux зривається на середині
In-place upgrade Linux рідко зривається на початку — машина тримається до моменту, коли пакетний менеджер починає розв'язувати залежності нового релізу поверх встановлених пакетів.
Метадані репозиторіїв уже замінені, частину бібліотек оновлено, а транзакція не може закритися: виникає конфлікт залежностей, де половина оточення тягне стару гілку, половина — нову. Після цього менеджер пакетів відмовляється працювати з обома наборами.
Наступний шар — осиротілі пакети. Реліз виключає частину компонентів, і вони залишаються без власника в нових метаданих: не видаляються, не оновлюються, тримають старі спільні бібліотеки й блокують розв'язання залежностей у сусідів. У списку встановленого вручну їх немає, тому під час розбору вони не видні.
Застарілі конфігураційні файли ламають уже запуск служб. Пакетний менеджер не перезаписує змінені налаштування мовчки — поруч створюється новий файл, і демон читає той, що підхопився першим.
Формат параметрів у новому релізі інший: служба падає на старті або піднімається з порожніми значеннями.
Найгірший випадок чекає після перезавантаження: ядро нове, а завантажувальний образ і модулі залишилися від попереднього релізу.
Коренева файлова система не монтується — це і є незавантажувана система, яку відновлюють з аварійного носія вручну, втрачаючи години доступності сервісу.
Усі ці точки відмови передбачувані й перевіряються до перезавантаження. Розбираємо, як це закривається — від інвентаризації пакетів до контрольного запуску на копії.
Що змінюється після контрольованого оновлення системи
Перехід між мажорними версіями перестає бути стихійним: сервіси перезапускаються в заданому порядку, і вікно простою тримається в оголошеному інтервалі, а не розтягується на серію аварійних нічних правок.
Перевірки проганяються на копії продакшену, тому залежності між сервісами й послідовність перезапуску відпрацьовані заздалегідь.
Оновлення Linux на місці (in-place upgrade) іде без перевстановлення: пакети, конфігурації та дані залишаються в тій самій системі, ролі не розгортаються заново. Це знімає основний ризик — розбіжність між тим, що налаштовано вручну, і тим, що описано в конфігурації.
Зникає цілий клас відмов, пов'язаний із застарілими бібліотеками: дистрибутив перестає отримувати виправлення безпеки й перестає збиратися проти актуальних залежностей.
Після переходу на підтримувану гілку Debian збірки знову відтворюються штатними засобами, без патчів зі сторонніх репозиторіїв.
План відкату фіксується до початку робіт: знімок стану, точка повернення й критерії, за яких перехід зупиняють. Якщо сервіс не проходить перевірки, повернення на попередній образ займає хвилини, а не години відновлення з резервної копії.
На виході — підтримка актуальних бібліотек, повторювана процедура наступного переходу й передбачуваний час відновлення, який можна закладати в угоду про рівень сервісу.
Способи переходу між мажорними версіями Linux
Вибір між оновленням на місці (in-place upgrade), перенесенням на чисту систему й паралельним стендом визначається не зручністю інженера, а тим, скільки простою допускає сервіс і наскільки керованою залишається конфігурація після переходу.
Оновлення на місці зберігає дані, локальні налаштування й адресацію, але тягне за собою нашарування попередніх мінорних версій — від застарілих конфігів до пакетів, які ніхто не наважується видалити.
Перенесення на чисту систему дає передбачуваний стан, зате вимагає повної інвентаризації служб і перенесення даних із перевіркою цілісності.
| Варіант | Коли підходить | Обмеження методу |
|---|---|---|
| Оновлення на місці | Одиночний вузол, припустиме вікно простою, конфігурація на керованій гілці | Залишкові файли й застарілі модулі переносяться автоматично; відкат після першого запуску нетривіальний |
| Перенесення на чисту систему | Потрібні відтворювані збірки й відмова від ручних правок | Простій на час копіювання; потрібна ревізія всіх служб, прав доступу й точок монтування |
| Паралельний стенд | Навантаження рознесене, є балансувальник і репліки | Подвійний супровід на період переведення; складніше налагоджувати розбіжності між контурами |
На практиці починають з оновлення на місці на одному некритичному вузлі: так перевіряються сценарії, скрипти й поведінка служб до того, як їх застосувати на бойових машинах.
Збереження даних у будь-якому варіанті спирається на знімок перед роботами й звірку після — інакше порівнювати «до» і «після» буде нічим.
Як проходить оновлення: етапи інженерних робіт
Оновлення між мажорними версіями — не одна команда в терміналі, а послідовність, де кожен крок залишає шлях назад. Роботи йдуть по одному хосту за раз: стан фіксується до й після, тому збій на будь-якому етапі не перетворюється на втрату сервісу.
Порядок однаковий для дистрибутивів родини Debian і сумісних із нею — різниться лише набір команд пакетного менеджера.
- Інвентаризація сервісів. Збираємо ролі хоста: активні юніти, таймери й завдання за розкладом, порти, що слухаються, зв'язки із сусідніми машинами, збірки в обхід пакетного менеджера. Без цього списку не можна стверджувати, що після оновлення нічого не загубилося.
- Зліпок стану. Фіксуємо список пакетів із версіями, вміст каталогу налаштувань, таблицю монтування, параметри мережі, встановлені модулі ядра. Плюс повний образ диска або снапшот тому — він потрібен і для порівняння, і для відкату.
- План відкату й вікно робіт. Визначаємо точку неповернення: до якого кроку повернення займає хвилини, після якого — години. Погоджуємо вікно, доступи й відповідального з боку замовника.
- Прогін на копії. Розгортаємо стенд зі зліпка й проходимо ланцюжок повністю: оновлення репозиторіїв, зміна релізу, злиття конфігів, перезавантаження. Так заздалегідь видно пакети, що зникли з нових репозиторіїв, і змінені формати файлів налаштування.
- Оновлення на місці. Переводимо сервіси в обслуговування, піднімаємо пакети до нового релізу, конфлікти налаштувань розбираємо вручну, а не автозаміною. Перезавантаження йде через консоль управління, щоб доступ не залежав від працюючої мережі.
- Перевірка після перезавантаження. Дивимося юніти в стані збою, журнали завантаження, точки монтування, терміни сертифікатів і прикладні перевірки: чи відповідає сервіс, чи йде запис у базу, чи бачать його сусідні вузли.
- Приймання результату. Передаємо чек-лист перевірок, оновлену документацію, перелік змін і вікно спостереження, у якому залишаємося на зв'язку. Хост повертається в роботу за підтвердженим результатом, а не за фактом перезавантаження.
Артефакти оновлення: конфігурації та регламенти
Оновлення між мажорними версіями через in-place upgrade закінчується не перезавантаженням, а передачею комплекту файлів і документів. За ним систему можна супроводжувати, відтворювати на іншому стенді й відкочувати без участі того, хто її оновлював. Нижче — перелік, який ми закриваємо до здачі: якщо пункту немає, робота не вважається завершеною.
- Схема інфраструктури — вузли, їхні ролі, мережеві сегменти й зв'язки між сервісами, актуальні на дату здачі, а не історичні.
- Конфігурації сервісів — налаштування, юніти systemd і параметри ядра, що відрізняються від стандартних, із поясненням, чому вибрано саме таке значення.
- Політики доступу — склад груп, правила підвищення прав, ключі та сертифікати, терміни їхньої дії й порядок відкликання при звільненні співробітника.
- Регламент обслуговування — періодичність оновлень, вікна робіт, перевірки перед застосуванням і критерії, за якими вузол визнається робочим.
- Порядок відкату — залишені точки повернення, що саме піднімається з резервної копії, скільки це займає і хто ухвалює рішення.
- Журнал змін — хронологія: що і навіщо змінювали, які перевірки пройшли, які відхилення знайшлися і як їх закрили.
Схема, конфігурації та журнал лежать поруч, у системі контролю версій, тому правки йдуть разом зі змінами, а не окремим документом. Кожен пункт підтверджується файлом або командою — комплект приймається формально, а не на словах.
Кейс: оновлення парку серверів без тривалого простою
Парк із 60+ серверів жив на мажорній версії дистрибутива, для якої вендор припинив випускати оновлення безпеки.
Оновлення відкладали рік за роком: штатний сценарій передбачав перевстановлення з нуля, перенесення даних і ручне налаштування кожної машини — за оцінкою самої команди це давало не менше двох діб простою на групу й десятки ручних операцій, де легко помилитися.
Як переводили навантаження
Парк розбили на групи по 8–10 машин і переводили їх послідовно. Вузол виводили з балансування, дочікувалися завершення активних сесій, знімали знімок і запускали in-place upgrade через керовані сценарії Ansible.
Після перезавантаження машина проходила автоматичні перевірки: відгук сервісу, доступність портів, цілісність каталогів із даними.
Лише за повного проходження вузол повертався в ротацію, інакше за хвилини відкочувався зі знімка, а навантаження продовжували тримати решта машин групи.
Метрики до і після
| Показник | До | Після |
|---|---|---|
| Робота з одним сервером | 4–6 годин ручних операцій | 25–40 хвилин, із них 5 хвилин участі інженера |
| Простій сервісу | вікно 8 годин на вихідних | нульовий, вузли виводяться по одному |
| Частка ручних кроків | близько 70% | менше 10% |
| Відкат при збої | перевстановлення з нуля | повернення знімка за 3–5 хвилин |
| Машин на актуальній гілці | 0% | 100% |
Весь парк перевели за півтора місяця, жодного разу не зупиняючи сервіс повністю. Ручні операції скоротилися до запуску сценарію й перевірки звіту, а оновлення на наступну мажорну версію тепер іде відпрацьованим маршрутом, а не з нуля.
Чим оновлення на місці відрізняється від перевстановлення?
Оновлення на місці й перевстановлення вирішують одне завдання — підняти систему на нову мажорну гілку, але ведуть до неї з різних боків.
У першому випадку пакетний менеджер замінює пакети поверх працюючого оточення й проганяє міграційні скрипти: він же звіряє файли конфігурації, позначає змінені вручну й пропонує залишити їх.
У другому ви отримуєте чистий корінь і переносите на нього дані, налаштування та служби руками — тобто заново збираєте машину з того, що вдалося згадати й знайти.
Звідси головна практична відмінність — збереження налаштувань. Оновлення на місці тягне за собою користувачів та їхні ключі, правила монтування, сертифікати, описи служб, завдання планувальника, обмеження ресурсів і мережеві параметри.
Усе це залишається на диску недоторканим, а пакетний менеджер лише запитує, що робити з тими файлами, які змінювали руками.
Перевстановлення системи такого не дає: будь-яке налаштування, яке не зафіксували в репозиторії конфігурацій або не винесли в резервну копію, зникає разом зі старим коренем, і згадується зазвичай уже після запуску.
Терміни робіт різняться на порядок. Оновлення на місці вкладається в одне вікно: зняття знімка файлової системи або резервної копії, перевірка вільного місця, прогін оновлення, перезавантаження, перевірка служб і логів.
Перевстановлення — це інвентаризація того, що реально працює на хості, збірка образу або розмітка, перенесення даних і конфігурацій, налаштування доступу, потім налагодження до стану «все як було», і на це йдуть дні, а не години.
Ризик втрати даних теж різний за природою.
Під час оновлення на місці він зосереджений в одному вікні: невдала міграція, нестача місця на розділі або несумісна конфігурація служби — і відкат робиться зі знімка, тому знімок зобов'язаний існувати до початку, а перевірка на копії стенда обов'язкова.
Під час перевстановлення дані губляться тихо: забули базу, не вивантажили чергу, пропустили сертифікат або правило міжмережевого екрана, і виявляється це за тижні.
Практичне правило просте: поки система налаштовувалася вручну й обростала винятками, оновлення на місці дешевше за часом і безпечніше для стану. Перевстановлення виправдане, коли корінь уже не відтворюваний і його чистіше зібрати заново з описаної конфігурації. Ми дивимося на це до початку робіт і вибираємо варіант за інвентарем хоста, а не за звичкою.
Технічні сумніви перед оновленням
Перед будь-яким in-place upgrade Linux виникають ті самі питання: скільки займе простій, чи впорається система, яка давно не оновлювалася, і що робити, якщо машина не підніметься. Нижче — короткі відповіді на ті, що задають найчастіше.
Скільки триватиме простій сервісів?
Оновлення вкладається в одну технологічну перерву: зміна пакетів, генерація образу завантаження, перезавантаження. Сервіси повертаються в роботу після перевірки працездатності застосунків, а не одразу після перезавантаження. У кластері вузли оновлюються по черзі, тому зовнішній сервіс залишається доступним.
Система не оновлювалася кілька років — чи оновиться вона напряму?
Не завжди: між гілками змінюються залежності, init-система й розташування конфігурацій. Шлях будується покроково, через проміжні релізи до цільової гілки, а перед першим кроком знімається повний образ диска — відкат залишається можливим на будь-якій стадії.
Як перевіряється сумісність прикладного ПЗ?
До робіт склад служб і версії бібліотек звіряються з вимогами цільової гілки. Те, що не підтримується напряму, ставиться з окремого репозиторію або замінюється сумісним аналогом — це потрапляє в план заздалегідь, а не з'ясовується в ніч оновлення.
Що робити, якщо система не завантажиться?
Відновлення завантаження йде з окремого носія: підмінюється ядро або запис завантажувача, зміни відкочуються зі знятого образу. Сам порядок дій перевіряється на копії інфраструктури до робіт, тому на бойовому контурі він виконується за готовим сценарієм.
Обговоримо ваше завдання оновлення
Оцінка оновлення між мажорними версіями тримається на деталях оточення: однакові на вигляд стенди розходяться за складом пакетів і сторонніх репозиторіїв, і саме це визначає обсяг робіт.
Щоб назвати терміни й порядок дій, а не діапазон «від і до», нам потрібен зріз контуру — надіслати все це можна в будь-якому зручному вигляді, хоч вивантаженням із системи управління конфігураціями, хоч текстовим переліком.
- список серверів і віртуальних машин з їхньою роллю в контурі: балансувальник, застосунок, база, черга, файлове сховище;
- поточні версії дистрибутивів і цільова гілка, до якої планується підніматися;
- нештатні джерела пакетів, модулі ядра й збірки з вихідних кодів — вони найчастіше ламають перехід;
- файли конфігурацій сервісів і юніти systemd, які перевизначають поведінку за замовчуванням;
- залежності між вузлами: спільні томи, реплікація, зовнішні інтеграції, жорсткі прив'язки за мережею;
- допустимий час недоступності й вікно, у яке оновлення можна почати;
- що вже є для відкату: знімки, резервні копії, резервні вузли.
За підсумками розбору ми повертаємо інвентаризацію оточення з позначеними точками ризику, оцінку й план робіт за етапами з порядком оновлення вузлів, а також критерії приймання — перелік перевірок, які сервіс має пройти до повернення в роботу.
Порядок передачі фіксуємо заздалегідь: що ви отримуєте на виході, які конфігурації та регламенти відкату залишаються у вашої команди і як передається система в експлуатацію після завершення.
Опишіть завдання — повернемося з оцінкою та планом.
