Ubuntu 24.04: зміни Netplan не застосовуються — чому (і як зробити їх постійними)

Швидка діагностика — план дій

Коли зміни Netplan не застосовуються, найшвидший шлях — припинити гадати і відповісти на три питання:
(1) Хто рендерить мережу? (2) Хто перезаписує YAML? (3) Що згенерував Netplan?
Ви зможете зробити це менше ніж за п’ять хвилин, якщо будете дисципліновані.

1) Підтвердіть активний renderer (NetworkManager чи systemd-networkd)

• Перевірте, яка служба фактично керує інтерфейсом (а не яку ви надаєте перевагу).
• Якщо NetworkManager керує інтерфейсом, редагування renderer: networkd не переможе магічно.

2) Перевірте, чи cloud-init перезаписує налаштування мережі під час завантаження

• Якщо ви використовуєте образ cloud (або похідний від нього), вважайте, що cloud-init має власні думки.
• Шукайте /etc/netplan/50-cloud-init.yaml та відповідні логи.

3) Перевірте валідність YAML та огляньте згенерований вивід

• Netplan компілює YAML у конфігурацію для бекенду.
• Якщо згенеровані файли не відповідають вашим очікуванням, Netplan не зрозумів ваш YAML або не прочитав його.

4) Застосовуйте безпечно (щоб не DDoSнути свій власний SSH)

• Використовуйте netplan try для віддалених змін.
• Потім перевірте за допомогою ip addr, ip route та розв’язування DNS.

Якщо ви робите тільки одну річ: припиніть редагувати випадкові YAML-файли, поки не визначите, який файл є авторитетним і який renderer активний.
Інакше ви просто відтворюєте ту саму помилку з більшою впевненістю.

Як Netplan працює насправді (і чому ваші правки зникають)

Netplan — це не менеджер мережі. Netplan — це шар абстракції конфігурації та генератор:
ви оголошуєте намір у YAML під /etc/netplan/, а Netplan генерує конфігурацію для бекенд-рендера — найчастіше
systemd-networkd на серверах і NetworkManager на робочих столах (а також все частіше на «сервероподібних» інсталяціях, де хочуть GUI або Wi‑Fi).

Це розмежування важливе, бо воно породжує три поширені режими відмови:

1. Ви відредагували не той файл (файл існує, але це не той, що використовується через пріоритет/лексичний порядок).
2. Renderer не той, який ви гадаєте (NetworkManager контролює інтерфейс, а ви пишете наміри у стилі networkd).
3. Інша система перезаписує (cloud-init — звичний підозрюваний, але не єдиний).

І так: ви можете запустити netplan apply і все одно нічого не побачити, якщо бекенд-сервіс відхилив згенеровану конфігурацію, інтерфейс не перебуває під керуванням, або YAML був проігнорований.
Робота Netplan в основному завершена, щойно він записав згенеровані файли і попросив бекенд перезавантажитися.

Людям, що відповідають за надійність, подобається чітка власність. Netplan-проекти виходять з ладу, коли власність розпливчаста:
NetworkManager контролює деякі пристрої, networkd — інші, cloud-init пише YAML, а адміністратори «виправляють», редагуючи якийсь очевидний файл.
Так і з’являється система, де все налагоджено, а нічого не працює.

Факти та історичний контекст для аргументів

Кілька конкретних пунктів, які можна використати у рев’ю дизайну або постмортемі, бо «здається» — не корінь проблеми.

1. Netplan вперше з’явився в Ubuntu 17.10 як спроба Canonical уніфікувати конфігурацію мережі між інсталятором та середовищами.
2. Netplan — декларативний YAML, але в машині врешті-решт працює нативна конфігурація рендера (юнити networkd або профілі NetworkManager).
3. Порядок файлів має значення: Netplan читає YAML-файли в лексичному порядку; пізніші файли можуть перекривати ранні.
4. Облачні образи часто використовують cloud-init для генерації 50-cloud-init.yaml, і він може перегенерувати його під час завантаження залежно від джерела даних і налаштувань.
5. NetworkManager тепер може керувати «серверними» NIC, особливо там, де команди уніфікують інструменти між ноутбуками та серверами.
6. systemd-networkd — це не NetworkManager: він легший, детермінований і часто кращий для безголових серверів — але не торкається інтерфейсів, якими не управляє.
7. Ubuntu переміщував обробку DNS з роками (resolvconf, потім systemd-resolved, плюс поведінки NM). Проблема з DNS зазвичай — це шар резольвера, а не Netplan.
8. «Apply» не завжди означає «persist»: зміна в рантаймі може застосуватися, але бути перезаписаною при перезавантаженні cloud-init, автоматизацією або іншим renderer-ом.

Типові симптоми та що вони зазвичай означають

Симптом: netplan apply проходить успішно, але IP ніколи не змінюється

Зазвичай: інтерфейс не керується тим renderer-ом, для якого ви генеруєте, або YAML, який ви редагували, не є тим, що використовується.
Іноді: бекенд відхилив конфігурацію і відкотився без повідомлення в терміналі.

Симптом: працює до перезавантаження, потім повертається

Зазвичай: cloud-init перезаписав файл при завантаженні або система управління конфігурацією (або скрипт «першого запуску» образу) знову застосувала стару конфігурацію.
Менш часто: ви редагували файл, який програв за лексичним порядком іншому YAML-файлу.

Симптом: маршрути неправильні (можна пінгувати шлюз, але не світ)

Зазвичай: дефолтний маршрут не застосований, інший інтерфейс виграє дефолтний маршрут, або присутнє політик-роутінг (VPN і оверлеї люблять це).

Симптом: DNS не відповідає тому, що ви вказали в YAML

Зазвичай: systemd-resolved використовує інший апстрім, NetworkManager штовхає інші DNS, або ви дивитесь у /etc/resolv.conf, не перевіривши, чи це заглушка або символічне посилання.

Цитата, щоб зберегти спокій під час інциденту:
«Надія — це не стратегія.» — Джеймс Кемерон

Жарт №1: Якщо ваша мережа «застосована», але нічого не змінилося — вітаємо: ви досягли корпоративного рівня неоднозначності.

Практичні завдання: команди, значення виводу та рішення

Це реальні, виконувані перевірки. Кожна включає: що виконати, що говорить вивід і яке рішення прийняти далі.
Виконуйте їх у порядку, якщо ви на виклику і ваша майбутня версія заслуговує пощади.

Завдання 1: Перелічіть файли Netplan і подивіться, що може кого перекривати

cr0x@server:~$ ls -l /etc/netplan/
total 8
-rw-r--r-- 1 root root  348 Nov  2 10:14 00-installer-config.yaml
-rw-r--r-- 1 root root  512 Nov  2 10:15 50-cloud-init.yaml

Значення: Netplan читає YAML у лексичному порядку. Якщо обидва визначають той самий інтерфейс, пізніший файл (тут 50-cloud-init.yaml) може перемогти.
Рішення: Якщо ви редагували 00-installer-config.yaml, очікуючи, що зміни залишаться, ви, ймовірно, програли битву перекриттів. Або змініть авторитетний файл, або видаліть джерело перекриттів.

Завдання 2: Подивіться, що Netplan вважає об’єднаною конфігурацією

cr0x@server:~$ sudo netplan get
network:
  ethernets:
    eno1:
      dhcp4: false
      addresses:
      - 10.20.30.40/24
      routes:
      - to: default
        via: 10.20.30.1
      nameservers:
        addresses:
        - 10.20.0.53
        - 10.20.0.54
  version: 2
  renderer: networkd

Значення: Це ефективна конфігурація після парсингу і злиття файлів.
Рішення: Якщо netplan get не показує ваших змін, Netplan не читає ваші правки (неправильний файл, помилка YAML або перезапис). Виправте це перед тим, як торкатися бекендів.

Завдання 3: Перевірте синтаксис (і впіймайте невидимі пастки YAML)

cr0x@server:~$ sudo netplan --debug generate
DEBUG:command generate: running ['/usr/libexec/netplan/generate']
DEBUG:Parsing /etc/netplan/00-installer-config.yaml
DEBUG:Parsing /etc/netplan/50-cloud-init.yaml
DEBUG:eno1: setting default backend to 1
DEBUG:Configuration is valid

Значення: «Configuration is valid» — необхідно, але не достатньо. Але якщо це падає, зупиніться і виправте YAML.
Рішення: Якщо debug-вивід парсить інший файл, ніж той, який ви редагували, ви працюєте з неправильним вхідним файлом.

Завдання 4: Перегляньте згенерований конфіг бекенду (те, що реально застосовується)

cr0x@server:~$ sudo ls -l /run/systemd/network/
total 4
-rw-r--r-- 1 root root 682 Nov  2 10:16 10-netplan-eno1.network

Значення: Netplan згенерував unit networkd у рантаймі.
Рішення: Відкрийте його. Якщо там немає ваших адрес/маршрутів, Netplan не генерує те, що ви думаєте. Якщо є — проблема в застосуванні бекенду або конфлікті.

Завдання 5: Прочитайте згенерований файл, щоб підтвердити точний застосований намір

cr0x@server:~$ sudo sed -n '1,120p' /run/systemd/network/10-netplan-eno1.network
[Match]
Name=eno1

[Network]
Address=10.20.30.40/24
DNS=10.20.0.53 10.20.0.54
Gateway=10.20.30.1

Значення: Якщо це збігається, Netplan виконав свою роботу. Тепер ви налагоджуєте networkd (або конфлікти).
Рішення: Якщо це не відповідає — повертайтеся до YAML Netplan і порядку файлів; не «ремонтуйте» networkd напряму, якщо не хочете боротися з Netplan при кожному перезавантаженні.

Завдання 6: Визначте, яка служба керує лінком

cr0x@server:~$ networkctl status eno1
● 2: eno1
                 Link File: /usr/lib/systemd/network/99-default.link
              Network File: /run/systemd/network/10-netplan-eno1.network
                      Type: ether
                     State: routable (configured)
              Online state: online
                   Address: 52:54:00:12:34:56

Значення: networkd управляє eno1 і вважає його налаштованим.
Рішення: Якщо стан «unmanaged» або «configuring», шукайте причину, чому networkd не бере його (неправильна умова відповідності імені, невідповідність renderer або NM захопив інтерфейс).

Завдання 7: Перевірте, чи NetworkManager також бере участь (і отже може вас відмінити)

cr0x@server:~$ nmcli dev status
DEVICE  TYPE      STATE      CONNECTION
eno1    ethernet  unmanaged  --
lo      loopback  unmanaged  --

Значення: NM не керує пристроєм. Це добре, якщо ви використовуєте networkd.
Рішення: Якщо NM показує connected з профілем на інтерфейсі, зупиніться і вирішіть, чи NM або networkd має бути вашим власником — потім зробіть renderer у Netplan відповідним.

Завдання 8: Перевірте реальний рантайм IP і маршрут (не довіряйте лише одному інструменту)

cr0x@server:~$ ip -br addr show eno1
eno1             UP             10.20.30.40/24

cr0x@server:~$ ip route show
default via 10.20.30.1 dev eno1 proto static
10.20.30.0/24 dev eno1 proto kernel scope link src 10.20.30.40

Значення: Це земна істина. Якщо це неправильно, зміна не застосована або була перезаписана після застосування.
Рішення: Якщо рантайм правильний, але зв’язок зламаний — переходьте до DNS/фаєрволу/маршрутизації вгору по ланцюгу. Якщо рантайм неправильний — повертайтеся до контролю renderer і згенерованих конфігів.

Завдання 9: Перевірте логи systemd-networkd на відхилення або флапи

cr0x@server:~$ sudo journalctl -u systemd-networkd -b --no-pager | tail -n 20
Nov 02 10:16:21 server systemd-networkd[812]: eno1: Configuring with /run/systemd/network/10-netplan-eno1.network.
Nov 02 10:16:21 server systemd-networkd[812]: eno1: Gained carrier
Nov 02 10:16:22 server systemd-networkd[812]: eno1: DHCPv4 client: disabled
Nov 02 10:16:22 server systemd-networkd[812]: eno1: Setting addresses
Nov 02 10:16:22 server systemd-networkd[812]: eno1: Setting routes
Nov 02 10:16:22 server systemd-networkd[812]: eno1: Configured

Значення: Ви можете побачити, чи networkd застосував статичну конфігурацію, чи пробував DHCP, чи не вдалось встановити маршрути тощо.
Рішення: Будь-які помилки тут мають перевагу над вашими припущеннями. Виправляйте задокументовану проблему замість випадкових перезаписів YAML.

Завдання 10: Перевірте, чи cloud-init контролює мережу на цьому хості

cr0x@server:~$ sudo cloud-init status --long
status: done
boot_status_code: enabled-by-generator
detail:
  DataSource: DataSourceNoCloud [seed=/var/lib/cloud/seed/nocloud-net]
  errors: []

Значення: Cloud-init запустився і має джерело даних; він також може керувати мережевою конфігурацією залежно від налаштувань.
Рішення: Якщо ви бачите cloud-init і 50-cloud-init.yaml, вважайте, що він може перезаписати вашу роботу при наступному завантаженні. Вирішіть, чи вимкнути cloud-init мережі, чи передати йому потрібну конфігурацію мережі.

Завдання 11: Подивіться, чи cloud-init недавно писав Netplan YAML

cr0x@server:~$ sudo journalctl -u cloud-init -b --no-pager | grep -i netplan | tail -n 20
Nov 02 10:10:03 server cloud-init[601]: Generating network configuration from datasource
Nov 02 10:10:03 server cloud-init[601]: Writing to /etc/netplan/50-cloud-init.yaml
Nov 02 10:10:04 server cloud-init[601]: Running command ['netplan', 'generate']

Значення: Це курильна гармата. Якщо cloud-init пише цей файл, ваші ручні правки можуть бути перезаписані при завантаженні.
Рішення: Або зупиніть cloud-init від управління мережею, або внесіть зміни через конфіг cloud-init, щоб він записував бажаний стан.

Завдання 12: Підтвердіть права та власність файлів (Netplan ігноруватиме небезпечні файли)

cr0x@server:~$ sudo stat -c '%A %U:%G %n' /etc/netplan/*.yaml
-rw------- root:root /etc/netplan/00-installer-config.yaml
-rw-r--r-- root:root /etc/netplan/50-cloud-init.yaml

Значення: Netplan очікує, що конфіги належатимуть root і не будуть записувані групою/іншими. Забагато дозволів може призвести до ігнорування файлу.
Рішення: Якщо бачите групозаписуваний або загально-записуваний файл, виправте права і знову запустіть generate/apply.

Завдання 13: Застосуйте безпечно з відкатом (підходить для віддаленої роботи)

cr0x@server:~$ sudo netplan try
Do you want to keep these settings?

Press ENTER before the timeout to accept the new configuration

Changes will revert in 120 seconds

Значення: Netplan ставить зміну у чернетку і відкотить її, якщо ви втратите з’єднання або не підтвердите.
Рішення: Використовуйте це, коли ви підключені по SSH і цінуєте свій час. Якщо зміна не підніме лінк, відкат відбудеться автоматично — тоді ви можете налагоджувати без поїздки в дата-центр.

Завдання 14: Якщо DNS «не застосовується», перевірте стан resolved (не тільки resolv.conf)

cr0x@server:~$ resolvectl status
Global
         Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub
Current DNS Server: 10.20.0.53
       DNS Servers: 10.20.0.53 10.20.0.54

Значення: systemd-resolved відповідає і знає ваші передбачені DNS-сервери.
Рішення: Якщо Netplan показує один DNS, а resolvectl — інший, renderer (або NM) може штовхати DNS інакше. Вирішіть, хто володіє DNS, і налаштуйте той шар правильно.

Завдання 15: Підтвердіть, що ім’я інтерфейсу відповідає тому, що ви налаштували

cr0x@server:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00
eno1             UP             52:54:00:12:34:56
enp6s0           DOWN           52:54:00:aa:bb:cc

Значення: Передбачувані імена інтерфейсів існують, щоб зменшити неоднозначність, але це все одно б’є під час змін шаблонів VM і перестановки NIC.
Рішення: Якщо ви налаштували ens3, а система має eno1, ваш YAML — красива поезія, яку ніхто не читає. Виправте ім’я відповідності.

Cloud-init: тихий переписувач конфігурацій

Cloud-init існує, щоб зробити образи переносними: завантажуйся будь-де, виявляй метадані, налаштовуй мережу, підставляй SSH-ключі і загалом роби те, що ви не хочете зберігати в золотому образі.
Проблема в тому, що коли машина перестає бути «епхемерною», корисність cloud-init стає нерозрізненною від саботажу.

В образах Ubuntu 24.04 часто зустрічається /etc/netplan/50-cloud-init.yaml. Цей файл не є священним.
Він згенерований. І залежно від конфігурації cloud-init та джерела даних, він може перегенеруватися при завантаженні.
Якщо ви редагуєте його вручну, ви ведете переговори з автоматизованою системою, яка ніколи не спить і не читає ваші коментарі в тикеті.

Як визначити, чи cloud-init перезапише мережу

Найшвидший знак — записи в логах, що він пише 50-cloud-init.yaml.
Другий знак — ваші зміни «працюють до перезавантаження».
Третій знак — ваша система управління конфігурацією «постійно програє», навіть якщо YAML на диску виглядає правильним відразу після запуску автоматизації.

Як зробити зміни постійними: оберіть одну зі стратегій

1. Вимкніть мережеву частину cloud-init на довгоживучих хостах.
   Це звичний підхід у приватних дата-центрах, де метадані екземпляра не є джерелом істини.
2. Передайте cloud-init бажану мережеву конфігурацію, щоб він генерував правильний Netplan YAML.
   Це найкраще, коли ви дійсно хочете портативності образу і послідовної поведінки при першому запуску.
3. Змініть порядок файлів netplan так, щоб ваш файл вигравав (наприклад, 99-local.yaml), але тільки якщо ви впевнені, що cloud-init не перегенерує інші ключі, від яких ви залежите.
   Це тактичне виправлення. Це не чиста архітектура.

Жарт №2: Cloud-init — як добронамі рпзробник, що «виправив» вашу таблицю, відсортувавши її — технічно правильно, оперативно катастрофічно.

Вимкнення мережі cloud-init (обережно)

Якщо машина більше не має бути динамічно налаштована метаданими, вимкніть цю функцію cloud-init явно.
Точний механізм може відрізнятися в різних середовищах, але мета одна: cloud-init має припинити генерацію і застосування мережевої конфігурації.

Після зміни налаштувань cloud-init перезавантажтеся або запустіть відповідні стадії cloud-init лише якщо розумієте наслідки. У продакшні віддавайте перевагу контролюваному вікну перезавантаження і доступу до консолі.

Війни renderer: NetworkManager проти systemd-networkd

Netplan може таргетити кілька renderer-ів. Два, з якими ви зустрінетеся в реальному житті — це systemd-networkd і NetworkManager.
Ваше завдання — не обрати «найкращий» у відриві від контексту. Ваше завдання — забезпечити, щоб точно один з них володів кожним інтерфейсом передбачувано.

systemd-networkd: нудний, детермінований, дружній до серверів

networkd зазвичай рекомендують для безголових серверів, бо він простий, інтегрується з systemd і робить менше «допоміжних» речей.
Коли ви декларуєте статичні IP, маршрути і DNS у Netplan з renderer: networkd, ви зазвичай прагнете цього світу.

NetworkManager: гнучкий, дружній для користувача, іноді надто кмітливий

NM блищить на робочих столах, з Wi‑Fi, VPN і динамічними мульти-мережевими середовищами.
Він також з’являється на серверах, коли команди стандартизують на nmcli і хочуть однакову поведінку по флоту.
Це нормально — поки хтось не відредагує Netplan, припускаючи networkd, тоді як NM активно управляє NIC.

Правило, яке запобігає 80% інцидентів «Netplan не застосувався»

Оберіть один renderer для хоста (або хоча б для кожного інтерфейсу) і забезпечте його дотримання.
Можливе змішування, але вам потрібна причина, документація і тести. Інакше це просто ентропія з YAML.

Пастки YAML, права доступу і чому «валідно» — це недостатньо

YAML дружелюбний так само, як і кухонний ніж: він не вб’є вас навмисно, але може зіпсувати день, якщо ви ставитесь до нього як до ложки.
У Netplan класичні пастки тонкі: неправильні відступи, помилкове розміщення ключів, застарілі ключі і файли, які Netplan мовчки ігнорує з міркувань безпеки.

Лексичний порядок: тихий механізм перекриття

Netplan читає /etc/netplan/*.yaml у лексичному порядку. Якщо два файли визначають той самий інтерфейс, пізніші можуть перекрити ранні декларації.
Це одночасно функція і джерело «я ж робив зміни».

Прагматичний підхід для локальних перекриттів (коли вам це справді потрібно) — очевидно названий хвостовий файл на кшталт 99-local.yaml.
Але якщо ви використовуєте автоматизацію, віддавайте перевагу одному авторитетному файлу замість купи перекриттів, які ніхто не пам’ятає.

Права: Netplan не довіряє конфігам, які записуються іншими

Якщо хтось зробив Netplan YAML записуваним групою, щоб «допомогти команді», він ненавмисно створив фаулґан.
Netplan пом’якшує це, ігноруючи небезпечні конфіги. Результат виглядає як «apply нічого не зробив», з приємною порцією плутанини.

Застарілі ключі та зміна семантики

Netplan еволюціонував. Деякі ключі, що працювали в старих прикладах, можуть бути застарілими або не рекомендованими. У сучасному Netplan часто краще явно використовувати routes замість старих скорочень для шлюзу в складних налаштуваннях.
Виправлення — не в тому, щоб зазубрити всі зміни — а в тому, щоб покладатися на netplan --debug generate і оглядати згенеровані конфіги.

Маршрути, DNS та «застосовано, але не працює»

Найбільш фрустраційна категорія — коли Netplan справді застосував вашу конфігурацію: IP адреса правильна, лінк піднятий — але система все одно не може дістатися до потрібних ресурсів.
Це не провал Netplan; це неповний мережевий намір.

Конфлікти дефолтного маршруту

Багато-NIC сервери стали звичними: один інтерфейс для управління, один для сховища, один для фронтенд-трафіку, іноді оверлеї або VPN.
Якщо два інтерфейси обидва пропонують дефолтний маршрут (через DHCP або статичні маршрути), Linux обере один на основі метрик і часу.
Це може виглядати як «випадкове підключення», особливо після перезавантажень.

Виправлення — бути явним: визначте, який інтерфейс володіє дефолтним маршрутом, і розгляньте використання метрик маршруту або політик маршрутизації, якщо ваш дизайн потребує кількох uplink-ів.

Шари DNS

Люди все ще трактують DNS як «файл у /etc/resolv.conf». На Ubuntu 24.04 таке мислення забирає годину вашого часу.
Часто /etc/resolv.conf — це заглушка, що вказує на systemd-resolved. NetworkManager також може вставляти DNS.
Netplan може задати DNS-сервери, але фінальна поведінка залежить від renderer-а і стеку резольвера.

Діагностуйте за допомогою resolvectl. Потім вирішіть, хто володіє DNS: networkd+resolved, NetworkManager чи виділений резольвер. Зробіть один шлях авторитетним.

Три корпоративні історії з поля бою

1) Інцидент через неправильне припущення: «Netplan — це менеджер мережі»

Команда успадкувала флот серверів Ubuntu, які «використовували Netplan». Вони хотіли перемістити VLAN сервісу і вирішили оновити блок статичних IP.
Запит на зміну був простий: відредагувати YAML, запустити netplan apply, перевірити. Саме так вони й зробили.

На половині хостів нічого не змінилося. На іншій половині зміни застосувалися і потім повернулися після перезавантаження під час координованого вікна обслуговування.
Команда вирішила, що «netplan apply зламався в 24.04», бо це був єдиний видимий інструмент, до якого вони торкалися.

Аналіз після інциденту був дивно простим: хости були змішаними інсталяціями.
Деякі використовували renderer: networkd. Інші мали встановлений NetworkManager і керували NIC через нього через попередню «стандартизацію».
А образи з хмари генерували 50-cloud-init.yaml.

Усунення проблеми не вимагало героїчної інженерії. Це була політика: обрати один renderer для ролі хоста, видалити інший менеджер там, де потрібно, вимкнути мережеву частину cloud-init на довгоживучих вузлах і додати перевірку CI, щоб падати, якщо кілька файлів netplan визначають той самий інтерфейс.
Наступне обслуговування пройшло тихо. І це найкраще, що може бути.

2) Оптимізація, що відкотилася: «Прискоримо провіжнінг, дозволивши cloud-init робити мережу назавжди»

Інша організація сильно покладалася на швидкий провіжнінг. Вони використовували cloud-init мережу не лише для першого завантаження, а як постійне «джерело істини» для мережевої конфігурації.
Це працювало добре, поки кожен інстанс був епхемерний. Потім деякі вузли почали жити місяцями через гравітацію даних.

Відбулася зміна мережі: DNS-сервери змінилися, маршрути оновилися, і потрібен був новий MTU для оверлею. Автоматизація прямо оновила Netplan YAML у /etc/netplan.
На диску виглядало коректно, але при наступному перезавантаженні все поверталося. Іноді поверталися лише частини — наприклад DNS — створюючи розділений стан, де зв’язок частково працював.

«Оптимізація» полягала в тому, що cloud-init мав завжди тримати мережу синхронною з метаданими. На практиці метадані і реальність розійшлися: у деяких інстансів були застарілі метадані, в деяких їх не було, а деякі мали кастомне джерело даних.
Cloud-init вірно застосовував нісенітницю.

Вони виправили це, змінивши мету оптимізації. Замість «cloud-init завжди володіє мережею» вони зробили межу: cloud-init налаштовує мережу одного разу при першому запуску, потім власність переходить до системи управління конфігурацією. Також додали запобіжник: якщо cloud-init намагається перезаписати Netplan після першого завантаження, це логуватиметься гучно і блокуватиме pipeline розгортання.
Провіжнінг залишився швидким, але операції перестали бути грою в відгадування.

3) Нудна, але правильна практика, яка врятувала ситуацію: netplan try + доступ до консолі + поетапний реліз

Компанії потрібно було змінити IP-адреси мережі управління у великому середовищі. Зміни були рутинними, але ризикованими: не можна виправити відрізаний сервер через SSH.
Провідний SRE наполягав на трьох «нудних» практиках: завжди використовувати netplan try для віддалених змін, завжди мати протестований доступ до out-of-band консолі і робити зміни поетапно.

Перший пакет виявив тонку невідповідність: деякі NIC були перейменовані через апаратне оновлення, тож Netplan націлював невірне ім’я інтерфейсу.
На цих вузлах netplan try не зміг встановити зв’язок і автоматично відкатився.
Цей відкат зберіг час і запобіг купі екстрених сесій на консолі.

Оскільки реліз був поетапним, вони відкоригували інвентар, згенерували YAML з правильними іменами інтерфейсів і продовжили.
Ніякого великого інциденту. Жодних героїв. Просто процес, який не отримує нагород, але зберігає доступність систем.

Урок не в тому, що netplan try класний. Урок у тому, що детермінований механізм відкату і поетапні релізи — це функції надійності, а не опціональна церемонія.

Типові помилки: симптом → корінь проблеми → виправлення

1) «Я відредагував YAML і нічого не сталося»

Симптом: netplan apply повертає без помилок; IP залишається незмінним.
Корінь проблеми: Ви редагували файл, який перекривається іншим YAML (лексичний порядок), або Netplan проігнорував файл через небезпечні права.
Виправлення: Запустіть sudo netplan get, щоб підтвердити об’єднану конфігурацію; забезпечте власність root і безпечні права; консолідуйте в один авторитетний файл або перемістіть перекриття в 99-local.yaml.

2) «Працює до перезавантаження, потім повертається»

Симптом: Правильно після apply; неправильно після рестарту.
Корінь проблеми: cloud-init перезаписує 50-cloud-init.yaml або знову генерує мережу при завантаженні.
Виправлення: Зупиніть cloud-init від управління мережею на цій ролі хоста або перенесіть мережевий намір у конфіг cloud-init, щоб він генерував правильний YAML при кожному завантаженні (якщо це справді бажано).

3) «Netplan показує networkd, але NM реально підключений»

Симптом: YAML декларує renderer: networkd, але nmcli dev status показує connected на NIC.
Корінь проблеми: Невідповідність renderer-ів; NetworkManager управляє інтерфейсом і може перекривати адресацію/DNS/маршрути.
Виправлення: Визначте власність. Або перемкніть Netplan на renderer: NetworkManager (і керуйте через NM), або налаштуйте NM, щоб не керувати цим пристроєм і послідовно використовувати networkd.

4) «IP застосовано, але немає інтернету / немає маршруту»

Симптом: Інтерфейс має правильну адресу; не можна дістатися за межі підмережі.
Корінь проблеми: Відсутній дефолтний маршрут, неправильний шлюз або конкуренція дефолтних маршрутів на іншому інтерфейсі.
Виправлення: Використовуйте ip route show. Визначте дефолтний маршрут явно в routes:, відрегулюйте метрики і забезпечте існування лише одного очікуваного дефолтного маршруту (якщо ви не реалізуєте політик-роутінг навмисно).

5) «DNS не змінюється»

Симптом: YAML перераховує DNS-сервери; /etc/resolv.conf показує щось інше.
Корінь проблеми: systemd-resolved stub, ін’єкція DNS від NM або шар резольвера вище Netplan.
Виправлення: Перевірте resolvectl status і визначте власника DNS. Узгодьте renderer Netplan з цим власником; не редагуйте вручну /etc/resolv.conf, сподіваючись, що зміни переживуть перезавантаження.

6) «netplan apply ламає SSH»

Симптом: Apply рве з’єднання; система може або не може відновитися.
Корінь проблеми: Віддалені зміни застосовані без відкату; неправильне ім’я інтерфейсу; випадкове видалення адрес/маршрутів.
Виправлення: Використовуйте netplan try. Переконайтеся в наявності доступу до консолі. Робіть зміни поступово: спочатку адреса, потім маршрут, DNS вкінці.

Контрольні списки / покроковий план

Чеклист A: Застосувати зміни Netplan на довгоживучому сервері

1. Перелічіть YAML-файли Netplan: визначте перекриття і згенеровані файли (ls -l /etc/netplan).
2. Підтвердіть об’єднаний намір (sudo netplan get). Якщо це не те, що ви очікуєте — зупиніться.
3. Перевірте власність renderer-а: networkctl status IFACE і nmcli dev status.
4. Перевірте, чи cloud-init володіє: cloud-init status --long, логи на запис Netplan YAML.
5. Визначте модель авторитету:
   • Cloud-init володіє лише першим запуском, потім CM; або
   • Cloud-init володіє мережею завжди (рідко розумно для довгоживучих вузлів); або
   • Ніколи cloud-init мережі (звично для bare metal).
6. Консолідуйте YAML в один файл на роль хоста, коли можливо.
7. Встановіть безпечні права: належність root, не записуваний групою/іншими.
8. Запустіть sudo netplan --debug generate і огляньте згенерований конфіг бекенду.
9. Застосовуйте з sudo netplan try, якщо віддалено.
10. Перевірте за допомогою ip -br addr, ip route і resolvectl.

Чеклист B: Безпечна послідовність змін для міграції статичної IP

1. Підтвердіть імена інтерфейсів і MAC у вашому інвентарі (ip -br link).
2. Додайте новий IP як вторинний (якщо середовище це підтримує) перед видаленням старої адреси, щоб уникнути відключення.
3. Оновіть маршрути, перевірте зв’язок зі шлюзом і наступними хопами.
4. Оновіть DNS останнім, бо проблеми з DNS плутають і виглядають як проблеми з маршрутизацією.
5. Заплануйте тест перезавантаження для перевірки постійності після того, як зміни стабільні.

Чеклист C: Коли підозрюєте конфлікти (NM vs networkd vs cloud-init)

1. Доведіть, хто володіє інтерфейсом (networkctl і nmcli).
2. Доведіть, хто пише Netplan YAML (логи cloud-init, логи CM, час модифікації файлів).
3. Доведіть, що Netplan згенерував (/run/systemd/network/ або профілі NM залежно від renderer-а).
4. Видаліть або вимкніть програючу сторону. Часткове співіснування породжує періодичні відмови.

Часті запитання

1) Чому netplan apply успішний, але нічого не змінюється?

Тому що Netplan може розпарсити і згенерувати конфіги, але бекенд може не керувати тим інтерфейсом, або інший YAML перекриває ваш.
Підтвердіть через netplan get, потім перевірте networkctl/nmcli, а потім огляньте згенеровані файли.

2) Який файл редагувати: 00-installer-config.yaml чи 50-cloud-init.yaml?

За замовчуванням — ні той, ні інший. Редагуйте файл, який є авторитетним для моделі власності вашого хоста.
Якщо cloud-init пише 50-cloud-init.yaml при завантаженні, ручні правки там — тимчасова ілюзія.
Віддавайте перевагу одному стабільному файлу, яким керує ваша автоматизація, або передавайте cloud-init правильну мережеву конфігурацію.

3) Як дізнатися, який renderer я використовую?

Не довіряйте пам’яті. Використовуйте netplan get для задекларованого renderer-а і перевірте фактичний контроль через networkctl status IFACE і nmcli dev status.
Важливим є власник інтерфейсу.

4) Чи можу я змішувати NetworkManager і systemd-networkd на одному хості?

Можете, але напевно не повинні, якщо немає чіткої причини і тестів.
Змішана власність підвищує ймовірність плутанини з маршрутами/DNS і «застосовано, але відкотилось».
Якщо змішуєте, переконайтеся, що кожен інтерфейс чітко управляється лише однією службою.

5) Чому DNS у Netplan не відповідає /etc/resolv.conf?

Тому що /etc/resolv.conf часто є заглушкою або символічним посиланням для systemd-resolved, і NetworkManager також може вставляти DNS.
Використовуйте resolvectl status, щоб побачити ефективні резольвери, а потім узгодьте renderer і стек резольвера.

6) Чи безпечно використовувати netplan try по SSH?

Так — в цьому сенс. Він застосовує зміни з таймаутом відкату, якщо ви не підтвердите.
Це не магія, але різниця між контрольованою зміною і незапланованою поїздкою до консолі.

7) Чому мої зміни відкотились лише інколи?

Бо кілька систем змагаються: оновлення DHCP, NetworkManager autoconnect, стадії boot cloud-init або автоматизація, яка знову застосовує.
Переривчаста поведінка — ознака конфліктуючої власності. Визначте, хто пише, і видаліть конфлікт.

8) Куди Netplan пише згенеровану конфігурацію?

Для networkd зазвичай під /run/systemd/network/ як 10-netplan-*.network.
Для NetworkManager це переводиться в профілі з’єднань NM (керовані NM). Точні артефакти залежать від renderer-а, тому перевіряйте, що присутнє і активне на системі.

9) Який найнадійніший спосіб забезпечити персистентність через перезавантаження?

Забезпечте одне джерело істини: один Netplan YAML-файл під управлінням root і вашої автоматизації, один renderer, який володіє інтерфейсом, і cloud-init мережа або вимкнена, або правильно налаштована.
Потім перезавантажте в вікні техобслуговування і перевірте стан рантайму.

10) Чи варто правити згенеровані файли в /run/systemd/network/ вручну?

Ні, не як виправлення. Ці файли ефемерні і будуть перегенеровані.
Редагуйте Netplan YAML (або вхід cloud-init), щоб згенерований вивід був правильним.
Єдиний випадок редагування згенерованих файлів — тимчасовий діагностичний експеримент, коли ви розумієте, що виходите за межі системи.

Висновок: наступні кроки, що не змусять вас відповідати о 3:00

Коли зміни Netplan не застосовуються в Ubuntu 24.04, система зазвичай робить саме те, що їй наказали — просто не ви, і не на тому шарі, який ви редагували.
Виправлення рідко є «спробувати ще раз». Виправлення — встановити власність і зробити конвеєр конфігурацій прісним.

Зробіть це далі, у такому порядку:

1. Запустіть sudo netplan get і підтвердіть, що ваш намір справді знаходиться в об’єднаній конфігурації.
2. Підтвердіть власність інтерфейсу через networkctl і nmcli; оберіть один renderer і забезпечте його дотримання.
3. Перевірте, чи cloud-init перезаписує, і вирішіть, чи cloud-init має володіти мережею на цьому хості.
4. Огляньте згенерований конфіг бекенду під /run, щоб довести, що буде застосовано.
5. Використайте netplan try для віддалених змін, потім перевірте з ip/resolvectl.

Зробіть це детермінованим. Зробіть це тестованим. Зробіть так, щоб наступний, хто вийде на виклик, не мав вивчати вашу інфраструктуру, читаючи логи о 03:00.