Сервери Ubuntu 24.04: Snap проти apt — коли Snap тихо створює проблеми (і що з цим робити)

January 24, 2026 • February 3, 2026 • Читання: 6 хв • Views: 7

Було корисно?

Найдивніші інциденти в продакшені не починаються з паніки ядра. Вони починаються з цілком нормального вівторка: ви нічого не патчите, нічого не розгортаєте,
і все ж сервіс перезапустився з іншим бінарником, ніж учора. Або використання диска повільно підкрадається на «статичному» хості, поки о 03:00 вам не дзвонить людина,
бо /var стало лише для читання.

На Ubuntu 24.04 екосистема Snap достатньо зріла, щоб бути нудною на десктопах — і все ще дивовижно гострою на серверах.
Не завжди. Не скрізь. Але достатньо часто, щоб мати власну думку та операційну стратегію.

Snap проти apt в одній сторінці: що змінюється на сервері

apt встановлює пакети Debian (.deb) з APT-репозиторіїв. Файли потрапляють у звичні локації файлової системи,
бібліотеки спільні, оновлення контролюються вашою політикою APT, і інструменти управління конфігурацією вже 20 років знають, як з цим працювати.
Коли ви оновлюєте, ви оновлюєте весь граф залежностей, який репозиторій пропонує на цей момент. Можна зафіксувати версії, утримувати пакети та ставити оновлення на стейдж.

Snap встановлює squashfs-образи плюс шар рантайму (snapd). Кожен додаток більш автономний, постачає більшість своїх залежностей
і працює в ізоляції (AppArmor-профілі, mount namespaces, інтеграція з cgroups тощо). Оновлення керуються в першу чергу
snap refresh (за замовчуванням автоматично), і додатки можуть оновлюватися незалежно від решти ОС.
Така відокремленість — і суть, і проблема.

Реальність сервера, а не маркетинг

Операційний контроль: apt — це «ваше управління змінами»; Snap — це «ваше управління змінами плюс друге».
Якщо ви навмисно їх не узгодите, зрештою натрапите на дрейф.
Диск і маунти: Snap додає loop-пристрої та маунти. Це не обов’язково погано, але змінює сенс того, коли «df показує заповнено»
і як деякі інструменти поводяться під навантаженням.
Модель безпеки: confinement може зменшити радіус ураження, але також руйнує припущення про шляхи в файловій системі, сокети та доступ до ресурсів хоста.
Залежність від мережі: Snap очікує з’єднання зі Snap Store. Проксі, TLS-інспекція, ізольовані мережі та обмежений egress роблять це… цікавим.

Моя упередженість: на продакшн-серверах віддавайте пріоритет apt, якщо Snap не дає конкретної, перевіреної переваги, яку ви зможете експлуатувати.
«Це було за замовчуванням у образі інсталяції» — це не перевага. Це просто ентропія з логотипом.

Жарт №1: Snap як мінібар — зручний, поки не перевірите рахунок і не зрозумієте, що платили за крихітні пляшечки того, що вже мали.

Факти та історія, які справді важливі

Це не факти на вікторину. Це контекст, який пояснює, чому ваш сервер Ubuntu 24.04 працює інакше, ніж у вашій ментальній моделі.

Snap починався як «snappy» для Ubuntu Core і IoT, де атомарні оновлення і бандлінг додатків — це переваги, а не занепокоєння.
Сервери успадкували цей підхід до пакування пізніше, іноді без тих самих обмежень.
snapd працює як системний сервіс і управляє маунтами, confinement і розкладом refresh. На мінімальному сервері це ще один демон
зі своїми логами, таймерами та режимами відмов.
Snaps — це squashfs-образи, змонтовані через loop-пристрої. Ось чому ви бачите додаткові /dev/loop* пристрої та маунти під /snap.
Ревізії snap зберігаються для відкату (зазвичай кілька ревізій). Це корисно, коли оновлення зламало вас, і також причина, чому використання диска зростає непомітно.
Оновлення транзакційні на рівні Snap. Зазвичай ви отримуєте або «стара ревізія працює», або «нова ревізія працює», що чудово — поки refresh не стався
під час вашої найгарячішої години.
Canonical просував певні додатки у Snap-першому розповсюдженні з часом. Класичний приклад — браузери на десктопах; на серверах тиск проявляється,
коли «пакет, який ви чекали», замінено або застаріло.
Confinement Snap сильно залежить від AppArmor. Якщо ви відключите AppArmor або працюєте в незвичних контекстах безпеки, модель безпеки Snap може деградувати або дивно фейлити.
systemd інтегрується зі Snap через згенеровані unit-файли і сервіси, керовані snapd. Ваше звичне припущення «unit файл живе в /etc/systemd/system» може бути хибним.

Одна перефразована ідея, яка в операціях працює: «Hope is not a strategy.» — приписують генерал-майору Gordon R. Sullivan (перефразовано).
Вибір пакування — це стратегія. Або ви її обираєте, або успадковуєте.

Де Snap тихо створює проблеми (реальні режими відмов)

1) Несподівані оновлення під час пікової навантаження

Snap refresh автоматичний за замовчуванням. Для ноутбука поведінка за замовчуванням прийнятна. На сервері «прийнятно» означає «згодом вам можуть подзвонити».
Оновлення можуть перезапускати сервіси, міняти бінарники й змінювати поведінку під час роботи навантаження.

Підступне не в тому, що оновлення відбуваються. Підступне в тому, що вони відбуваються поза шляхом контролю змін, який вже існує у вашій команді для apt,
управління конфігурацією і вікон обслуговування.

2) Використання диска, що повільно підкрадається

Snap зберігає кілька ревізій і тримає дані під /var/snap та /var/lib/snapd.
Якщо у вас маленькі кореневі томи (поширено в образах cloud), Snap може штовхнути вас у зону «root 100% full» швидше, ніж ви очікуєте.
Тим часом df стає шумнішим через змонтовані snap-образи.

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

3) Confinement руйнує припущення про інтеграцію

Snaps ізольовані. Чудово. Але «ізольовано» означає «ваш додаток не бачить хост так, як ви думаєте».
Типові больові точки:

Доступ до шляхів /etc і /var, які ви вважаєте наявними (або записуваними).
Привілейовані порти або прив’язка до мережі хоста в несподіваний спосіб залежно від snap і підключених інтерфейсів.
Читання сертифікатів хоста, SSH-ключів або CA-бандлів зі стандартних місць, коли snap використовує свої власні.
Спілкування з сокетами хоста (Docker socket, systemd socket activation, кастомні Unix-сокети) без потрібних інтерфейсів.

В огляді інциденту це часто з’являється як: «Але файл конфігурації правильний». Так. Процес просто не може його прочитати.

4) Дрейф в observable: логи, шляхи й unit-файли не там, де ви звикли

З apt ви знаєте, де unit-файл, куди пишуть логи і де патчити конфіги. Snap абстрагує ці деталі й іноді переміщує їх.
Це переживеться, але уповільнює вас під тиском.

5) Залежність від Store і поведінка флоту в обмежених мережах

Якщо ваші сервери за суворими правилами egress, через проксі або з TLS-інспекцією, snap refresh може постійно падати.
Повторні збої можуть спричинити:

Постійні таймери, що прокидаються і працюють (спам логів, CPU-пробудження).
Затягнуті refresh-и, що блокують інші операції.
Частковий дрейф флоту: деякі машини оновлюються, інші — ні, і ви отримуєте «такі ж версії» у постмортемі, хоча їх немає.

6) Накладні витрати маунтів і loop-пристроїв в крихких середовищах

Більшість серверів не помітять кількох додаткових маунтів. Деякі помітять:

Системи з жорсткими припущеннями про простір маунтів (деякі контейнери, інструменти на основі chroot або скрипти жорсткого хардінгу).
Старе моніторингове забезпечення, яке трактує «багато loop-пристроїв» як «хтось майнить крипту».
Хости з обмеженнями на loop-пристрої або дивною поведінкою initramfs.

7) «Але вчора працювало» через зміну рантайму

Оновлення Snap можуть підтягувати нові рантайми та бази (наприклад, core snap). Це може тонко змінити TLS-поведінку, дефолтні шифри
або поведінку бібліотек у пакеті. Ви не побачите цього в apt-історії. Побачите як помилку рукопотискання клієнта і зростаюче відчуття катастрофи.

Жарт №2: Коли Snap каже, що він «refresh-иться», він не пропонує серверу СПА — він перевставляє кухню під час вечері.

Практичні завдання: команди, виводи та рішення (12+)

Нижче — завдання, які можна виконати на Ubuntu 24.04 прямо зараз. Кожне включає: команду, реалістичний вивід, що це означає і яке рішення прийняти.
Написано для людей, які мають виправляти ситуацію, а не дебатувати філософію пакування.

Завдання 1: Визначити, чи встановлено і активний Snap

cr0x@server:~$ systemctl status snapd --no-pager
● snapd.service - Snap Daemon
     Loaded: loaded (/usr/lib/systemd/system/snapd.service; enabled; preset: enabled)
     Active: active (running) since Mon 2025-12-29 08:11:22 UTC; 2h 14min ago
TriggeredBy: ● snapd.socket
   Main PID: 1123 (snapd)
      Tasks: 14 (limit: 18956)
     Memory: 54.7M
        CPU: 1min 12.333s
     CGroup: /system.slice/snapd.service
             └─1123 /usr/lib/snapd/snapd

Що це означає: snapd працює і ввімкнено. Оновлення Snap і маунти працюють.

Рішення: Якщо це продакшн-сервер і Snap явно не потрібен, сплануйте його видалення/відключення або зафіксуйте поведінку оновлень.

Завдання 2: Перелік встановлених snap (і пошук «сюрпризних» пакетів)

cr0x@server:~$ snap list
Name        Version           Rev   Tracking       Publisher   Notes
core22      20241001          1380  latest/stable  canonical✓  base
lxd         5.21              33110 5.21/stable    canonical✓
snapd       2.63.1            23159 latest/stable  canonical✓  snapd

Що це означає: Ви запускаєте LXD зі Snap, плюс базовий snap і сам snapd.

Рішення: Підтвердіть власність: чи підтримує ваша платформа LXD як snap? Якщо ні, мігруйте на apt-пакети (де доступно) або задокументуйте Snap як залежність.

Завдання 3: Подивитися, коли Snap оновиться наступного разу (і чи заблоковано)

cr0x@server:~$ snap refresh --time
timer: 00:00~24:00/4
last: today at 06:17 UTC
next: today at 10:19 UTC

Що це означає: Snap refresh може статися будь-коли протягом дня, приблизно кожні 4 години, залежно від політики.

Рішення: На серверах встановіть вікно оновлення узгоджене з вікном обслуговування або тимчасово утримайте refresh під час критичних подій.

Завдання 4: Встановити вікно оновлень (контроль вікна обслуговування)

cr0x@server:~$ sudo snap set system refresh.timer=Sun03:00-05:00

Що це означає: Snap намагатиметься оновлюватися в неділю 03:00–05:00.

Рішення: Використовуйте вікно, що відповідає реаліям on-call. Якщо ваше вікно обслуговування — «ніколи», то ваша система вже працює на інтуїції.

Завдання 5: Утримати refresh під час замороження (короткочасно, не завжди)

cr0x@server:~$ sudo snap refresh --hold=24h
General refreshes of "all snaps" held until 2025-12-30T08:33:10Z

Що це означає: Ви призупинили оновлення на 24 години.

Рішення: Використовуйте це під час реагування на інцидент або великих релізів. Створіть follow-up ticket, щоб зняти hold і патчити свідомо.

Завдання 6: Перевірити, чи refresh snap нещодавно перезапускав сервіс

cr0x@server:~$ journalctl -u snapd --since "today" --no-pager | tail -n 12
Dec 29 06:16:59 server snapd[1123]: Refreshing "lxd"
Dec 29 06:17:21 server snapd[1123]: Restarted snap.lxd.daemon.service
Dec 29 06:17:22 server snapd[1123]: Refreshing "core22"
Dec 29 06:17:35 server snapd[1123]: Finished refresh, 2 snaps updated

Що це означає: LXD оновився і його демон перезапустився.

Рішення: Якщо ви не планували цей перезапуск, ущільніть контроль оновлень і додайте моніторинг перезапусків, ініційованих snap.

Завдання 7: Визначити systemd-юнити, якими керує snap

cr0x@server:~$ systemctl list-units --type=service | grep -E '^snap\.'
snap.lxd.activate.service          loaded active exited  Service for snap application lxd.activate
snap.lxd.daemon.service            loaded active running Service for snap application lxd.daemon
snap.snapd.apparmor.service        loaded active exited  Load AppArmor profiles managed internally by snapd

Що це означає: Це згенеровані snap-ом юніти; редагувати їх напряму зазвичай неправильне рішення.

Рішення: Використовуйте налаштування snap або systemd drop-in (обережно) і задокументуйте, що підтримується.

Завдання 8: Зрозуміти loop-пристрої й маунти, які додає Snap (шум дисків/маунтів)

cr0x@server:~$ lsblk -o NAME,TYPE,SIZE,MOUNTPOINT | grep -E 'loop|NAME'
NAME   TYPE   SIZE MOUNTPOINT
loop0  loop  74.2M /snap/core22/1380
loop1  loop  95.3M /snap/lxd/33110
loop2  loop  53.6M /snap/snapd/23159

Що це означає: Кожна ревізія snap — змонтований squashfs-образ через loop.

Рішення: Не «чистити loop-пристрої» вручну. Якщо місця замало — зменште кількість збережених ревізій і видаліть невикористовувані snaps.

Завдання 9: Виміряти, скільки місця займає Snap (і де)

cr0x@server:~$ sudo du -sh /var/lib/snapd /var/snap 2>/dev/null
1.3G	/var/lib/snapd
612M	/var/snap

Що це означає: Ви витрачаєте ~2 ГБ на інфраструктуру Snap і дані додатків snap.

Рішення: На малих кореневих томах або виділіть бюджет під Snap, або видаліть його. Якщо лишаєте — налаштуйте утримання ревізій і моніторте /var.

Завдання 10: Зменшити кількість збережених ревізій snap (контроль диска)

cr0x@server:~$ sudo snap set system refresh.retain=2

Що це означає: Snap буде тримати менше старих ревізій (за замовчуванням часто більше).

Рішення: Встановіть retain=2 на серверах, якщо у вас немає сильної політики відкату, що вимагає більше, і ваш бюджет диска це підтримує.

Завдання 11: Відкат snap після невдалого оновлення

cr0x@server:~$ sudo snap revert lxd
lxd reverted to 5.21

Що це означає: Ви відкотилися до попередньої ревізії, яку snapd зберіг.

Рішення: Трактуйте revert як крок стабілізації. Далі: заморозити оновлення, відкрити інцидент і спланувати контрольоване виправлення.

Завдання 12: Знайти підключення інтерфейсів snap (чому доступ заборонено)

cr0x@server:~$ snap connections lxd | head
Interface  Plug            Slot                 Notes
network    lxd:network     :network             -
network-bind lxd:network-bind :network-bind     -
mount-observe lxd:mount-observe :mount-observe  -

Що це означає: Snaps використовують інтерфейси для дозволів. Відсутні підключення можуть спричиняти «permission denied» навіть для сервісів, що запускаються від root.

Рішення: Якщо snap не може отримати доступ, перевірте інтерфейси перед тим, як змінювати дозволи файлів. Використовуйте snap connect лише коли розумієте компроміс щодо безпеки.

Завдання 13: Помітити таймери refresh і що вони робитимуть

cr0x@server:~$ systemctl list-timers --all | grep -E 'snap|apt' | head -n 20
snapd.refresh.timer         loaded active waiting   Tue 2025-12-29 10:19:00 UTC  1h 41min left
apt-daily.timer             loaded active waiting   Tue 2025-12-29 06:12:41 UTC  21h left
apt-daily-upgrade.timer     loaded active waiting   Tue 2025-12-29 06:27:10 UTC  21h left

Що це означає: У вас два незалежні планувальники оновлень: apt-таймери й таймер оновлення snapd.

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

Завдання 14: Підтвердити, що конкретна команда — це snap, а не deb

cr0x@server:~$ command -v lxd
/snap/bin/lxd

Що це означає: Ви виконуєте бінарник, наданий snap, а не той, що встановлений apt.

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

Завдання 15: Перевірити apt-еквіваленти і що встановлено

cr0x@server:~$ apt-cache policy lxd | sed -n '1,12p'
lxd:
  Installed: (none)
  Candidate: 1:0.0~git20240301.abcdef-0ubuntu1
  Version table:
     1:0.0~git20240301.abcdef-0ubuntu1 500
        500 http://archive.ubuntu.com/ubuntu noble/universe amd64 Packages

Що це означає: LXD доступний через apt, але не встановлений. Ви запускаєте snap-версію.

Рішення: Вирішіть один канал пакування для кожного сервісу. Змішані інсталяції породжують фантомні баги й поведінку «залежить від хоста».

Завдання 16: Чисто видалити snap (якщо ви обираєте apt-першими)

cr0x@server:~$ sudo snap remove --purge lxd
Remove "lxd" snap
lxd removed

Що це означає: Пакет snap та його дані видалені (purge).

Рішення: Робіть це тільки після міграції даних і валідації плана розгортання через apt. Purge — це не «можливо». Purge — це «я серйозно».

Завдання 17: Відключити snapd (якщо потрібно зупинити поведінку, але лишити пакет)

cr0x@server:~$ sudo systemctl disable --now snapd.service snapd.socket
Removed "/etc/systemd/system/multi-user.target.wants/snapd.service".
Removed "/etc/systemd/system/sockets.target.wants/snapd.socket".

Що це означає: snapd зупинено і він не автозапуститься через сокет.

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

Завдання 18: Довести, що snapd більше не функціональний (перевірка)

cr0x@server:~$ snap list
error: cannot communicate with server: Post "http://localhost/v2/snaps": dial unix /run/snapd.socket: connect: no such file or directory

Що це означає: snap-клієнт не може поговорити зі snapd. Добре — якщо це було вашим наміром.

Рішення: Оновіть базові перевірки і золоті образи, щоб не опинитися з напівкерованими хостами.

Швидка діагностика: що перевірити першим/другим/третім

Це послідовність «горить і в мене 15 хвилин» для болю, пов’язаного зі Snap на серверах Ubuntu 24.04.
Мета — не елегантність. Мета — швидко бути правильним.

Перше: Чи щось оновилося або перезапустилося?

Перевірте час останнього refresh:
```
cr0x@server:~$ snap refresh --time
timer: 00:00~24:00/4
last: today at 06:17 UTC
next: today at 10:19 UTC
```
Інтерпретація: Якщо last співпадає з початком інциденту, підозрівайте зміну, спричинену refresh.

Перевірте логи snapd на перезапуски:

cr0x@server:~$ journalctl -u snapd --since "today" --no-pager | grep -E 'Refreshing|Restarted' | tail -n 20
Dec 29 06:16:59 server snapd[1123]: Refreshing "lxd"
Dec 29 06:17:21 server snapd[1123]: Restarted snap.lxd.daemon.service

Інтерпретація: Snap щось зробив. Тепер потрібно вирішити — відкотити/утримати чи ні.

Друге: Це проблема диска, CPU, мережі чи дозволів?

Тиск на диск (root/var):
```
cr0x@server:~$ df -h / /var
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        30G   28G  1.2G  96% /
/dev/vda1        30G   28G  1.2G  96% /var
```
Інтерпретація: Ви в зоні ризику одного сплеску логів. Утримання ревізій і /var/lib/snapd — головні підозрювані.

CPU-навантеження від спроб refresh:

cr0x@server:~$ top -b -n 1 | head -n 12
top - 10:41:10 up  1 day,  2:30,  1 user,  load average: 1.21, 1.05, 0.88
Tasks: 231 total,   1 running, 230 sleeping,   0 stopped,   0 zombie
%Cpu(s):  9.0 us,  2.1 sy,  0.0 ni, 88.2 id,  0.3 wa,  0.0 hi,  0.4 si,  0.0 st
MiB Mem :  3906.7 total,   612.3 free,  1298.4 used,  1996.0 buff/cache
MiB Swap:  2048.0 total,  2048.0 free,     0.0 used.  2340.1 avail Mem
    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
   1123 root      20   0 1349808  56032  19840 S   6.0   1.4   1:12.33 snapd

Інтерпретація: snapd споживає CPU. Якщо це співпадає з циклом refresh або проблемами з доступом до Store, виправте мережу/проксі і встановіть вікно обновлень.

Проблеми з дозволами або confinement:
```
cr0x@server:~$ journalctl -u snap.lxd.daemon --since "today" --no-pager | tail -n 8
Dec 29 06:18:04 server lxd[14555]: Error: failed to open /etc/lxd/cluster.crt: permission denied
Dec 29 06:18:04 server lxd[14555]: Error: daemon failed to start
```
Інтерпретація: Сервіс не може отримати доступ до шляху хоста. Перевірте інтерфейси snap і очікування confinement перед тим, як «хакнути» дозволи файлів.

Третє: Стабілізувати, потім вирішити стратегію каналів

Стабілізація: утримати refresh і відкотити, якщо потрібно.

cr0x@server:~$ sudo snap refresh --hold=24h
General refreshes of "all snaps" held until 2025-12-30T10:44:22Z

Вирішити: залишити Snap, але експлуатувати його (вікна, моніторинг, утримання), або видалити Snap і стандартизувати на apt.

Три корпоративні міні-історії з передової

Міні-історія №1: Інцидент через хибне припущення

Середня компанія мала флот серверів Ubuntu, що хостили внутрішні інструменти розробки: дзеркала артефактів, CI-ранепли й невеликий кластер LXD для епемерних тестових середовищ.
Вони були хороші в патчингу: apt-оновлення йшли тижнево, з канарками, дашбордами й людиною на сторожі error budget.

Під час гарячого спринту розробники почали скаржитися, що контейнери LXD не стартують на підмножині хостів. Інженер on-call перевірив apt-історію і нічого не знайшов.
Репозиторій конфігів не змінювався. CPU і пам’ять були в нормі. Хости на папері виглядали «ідентично».

Хибне припущення було простим: «Якщо встановлено, то керується apt». Насправді LXD був встановлений через Snap на цих образах, бо хтось колись слідував upstream-гіду.
Snap оновив LXD на кількох хостах того ранку, перезапустив демон. Нова ревізія загострила правило confinement і демон перестав читати шлях сертифіката, який лежав поза дозволеними шляхами snap.

Розв’язання було швидким, коли це зрозуміли: snap revert для стабілізації, snap refresh --hold щоб зупинити хаос, а потім правильне рішення з інтерфейсами/шляхами.
Справжня робота була в постмортемі: додали перевірку базового образу в провізінгу, яка помічала будь-які несподівані snaps, і задокументували «підтримувані канали пакування» для критичних сервісів.

Ніхто не був звільнений. Але кілька рунабуків переписали з меншою оптимістичністю і більше командами.

Міні-історія №2: Оптимізація, що обернулася проти

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

Провал виник через просту математику. Ревізії snap накопичувалися на хостах, які рідко ребуталися і майже ніколи не мали ручного обслуговування.
Між /var/lib/snapd, старими ревізіями і даними додатків під /var/snap, машини з 20–30 ГБ коренями почали стикатися з 90% заповнення.
Достатньо, щоб бути крихкими, але не достатньо, щоб миттєво алармити.

Потім інцидент з галасливим сусідом спричинив сплески логів. Декілька хостів перейшли 100% використання, journald перестав писати, чекхелси почали таймаутитись, і оркестратор став переназначати навантаження.
Переназначення зробило інші хости гарячішими, і нудна проблема з диском перетворилася на каскадну відмову, що виглядала як «випадкова нестабільність сервісів».

Їхня «оптимізація» полягала у спрощенні базового образу. Насправді вони додали другий кеш пакування з власною політикою утримання, і не заклали його в бюджет.
Виправили це, встановивши refresh.retain=2, перемістивши частину даних з кореня, і — що люди часто пропускають — додавши дашборд, який розбивав використання диска за категоріями,
включно з путями, керованими Snap. Якщо не графати це, воно все одно заповниться. Просто заповнюватиметься тихо.

Міні-історія №3: Бюрократично правильно, що врятувало день

Команда фінансових сервісів тримала сервери Ubuntu з жорсткими вікнами змін. Вони не були анти-Snap, але ставилися до Snap як до будь-якого іншого джерела змін:
плануй, спостерігай і роби відкат.

Їхня база включала:
вікно оновлень у неділю,
утримання ревізій у 2,
моніторинг перезапусків snapd-юнитів,
і просту CI-роботу, що порівнювала snap list по флоту для виявлення дрейфу.
Нічого надзвичайного. Просто дисципліна.

Одного вікенду оновлення snap змінило поведінку агента моніторингу. Декілька канарок оновилися першими (бо вікна оновлень були по групах).
Дашборди миттєво це помітили: падіння reconnect rate агента, незначне підвищення CPU і нові підписи попереджень у логах.

Оскільки команда мала операційний шлях, відповідь була нудною: hold оновлень по флоту, revert на канарках, тикет вендору і ретест у стенді. Продакшн не побачив широкого впливу.
Ніхто не дізнався про це від клієнтів.

Ось як більшість днів виглядає reliability engineering: ви запобігаєте хвилям. Це нудно. Але працює.

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

1) Симптом: «Сервіс сам по собі перезапустився»

Корінна причина: snap refresh перезапустив systemd-юнит, що керується snap.

Виправлення: Встановіть refresh.timer у вікні обслуговування; моніторте перезапуски snapd; розгляньте утримання оновлень під час критичних подій.

2) Симптом: «Коренева файлова система повільно заповнюється, хоча дані додатка десь інде»

Корінна причина: Ревізії snap і дані snap під /var/lib/snapd і /var/snap.

Виправлення: Встановіть refresh.retain на 2; видаліть невикористовувані snaps; закладіть місце; моніторте шляхи Snap окремо.

3) Симптом: «Permission denied при читанні /etc/… навіть від root»

Корінна причина: Confinement Snap і відсутні підключення інтерфейсів; процес працює в обмеженому контексті.

Виправлення: Використовуйте snap connections для інспекції; адаптуйте конфігурацію під snap-схвалені шляхи; підключайте лише потрібні інтерфейси свідомо.

4) Симптом: «snap refresh постійно падає, логи спамлять, CPU прокидається»

Корінна причина: Обмежений egress, проблеми з проксі, TLS-інспекція або DNS, що блокує доступ до Store.

Виправлення: Перевірте вихідну зв’язність; налаштуйте проксі для snapd; якщо не можете забезпечити доступ до Store, не запускайте snaps у такому середовищі.

5) Симптом: «Моніторинг показує багато loop-пристроїв; хтось панікує про компроміс»

Корінна причина: Нормальна поведінка Snap: кожна ревізія монтує squashfs-образ як loop-пристрій.

Виправлення: Просвітіть моніторинг і людей; алертьте за використанням диска і подіями refresh, а не за наявністю loop-пристроїв.

6) Симптом: «Ми оновили через apt, але запущений бінарник не змінився»

Корінна причина: Бінарник походить з /snap/bin і не керується apt.

Виправлення: Перевірте command -v, стандартизуйте канал пакування і впевніться, що провізінг це дотримується.

7) Симптом: «Systemd override не працюють»

Корінна причина: Згенеровані snap-ом юніти можуть перебудовуватися; редагувати unit-файл напряму крихко.

Виправлення: Використовуйте drop-in файли обережно; віддавайте перевагу опціям конфігурації snap; документуйте, що переживе refresh.

8) Симптом: «Той самий додаток поводиться по-різному на різних хостах»

Корінна причина: Дрейф ревізій snap (різні ревізії), особливо у флотах без узгоджених вікон оновлень або з невдалими refresh на деяких вузлах.

Виправлення: Порівнюйте snap list по флоту; наведіть вікна оновлень; алертьте на версійну розбіжність; для критичних сервісів розгляньте apt з фіксованими версіями.

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

План A: Ви залишаєте Snap (але керуйте ним відповідально)

Інвентаризація snaps на кожній ролі сервера.
```
cr0x@server:~$ snap list
Name   Version   Rev   Tracking       Publisher   Notes
snapd  2.63.1    23159 latest/stable  canonical✓  snapd
```
Рішення: Якщо роль має snaps, яких ви не чекали, зупиніться і визначте власника.
Встановіть вікно оновлень узгоджене з вікном обслуговування.
```
cr0x@server:~$ sudo snap set system refresh.timer=Sun03:00-05:00
```
Рішення: Перемістіть оновлення туди, де є люди.
Зменшіть утримання ревізій, якщо диск не безмежний.
```
cr0x@server:~$ sudo snap set system refresh.retain=2
```
Рішення: Якщо хочете «безкінечний відкат», купіть «безкінечний диск». Інакше тримайте це вузько.
Алерт на перезапуски snapd і snap-керованих сервісів.
```
cr0x@server:~$ systemctl list-units --type=service | grep -E '^snap\.'
snap.snapd.apparmor.service        loaded active exited  Load AppArmor profiles managed internally by snapd
```
Рішення: Трактуйте refresh як деплой. Висвітлюйте його.
Документуйте очікування confinement для кожного snap (шляхи, сокети, порти).
```
cr0x@server:~$ snap connections snapd | head
Interface  Plug         Slot           Notes
network    snapd:network :network      -
```
Рішення: Якщо ваш додаток потребує інтеграції з хостом понад стандартні інтерфейси, перегляньте вибір пакування.
Запускайте канарки: рознесіть вікна оновлень по групах.

Рішення: Хочете малий blast radius при наступному «цікавому» оновленні.

План B: Ви переходите на apt-перші (рекомендується для більшості продакшн-серверів)

Знайдіть бінарники, що надаються snap, у вашому PATH.
```
cr0x@server:~$ command -v lxd
/snap/bin/lxd
```
Рішення: Якщо критичний рантайм під /snap/bin, сплануйте міграцію перед видаленням.
Міграція сервіс за сервісом (не відривайте snapd спочатку).
```
cr0x@server:~$ snap list
Name  Version  Rev  Tracking       Publisher   Notes
lxd   5.21     33110 5.21/stable   canonical✓
```
Рішення: Видаляйте один snap за раз, перевіряйте функціональність, потім рухайтеся далі.
Чисто видаляйте snaps після міграції.
```
cr0x@server:~$ sudo snap remove --purge lxd
Remove "lxd" snap
lxd removed
```
Рішення: Purge видаляє дані. Робіть бекапи перед цим.

Відключіть snapd коли хост вільний від snap.

cr0x@server:~$ sudo systemctl disable --now snapd.service snapd.socket
Removed "/etc/systemd/system/multi-user.target.wants/snapd.service".
Removed "/etc/systemd/system/sockets.target.wants/snapd.socket".

Рішення: Це політичне рішення. Закріпіть його у вашому базовому образі.

Підтвердіть власність apt і зафіксуйте/утримуйте за потреби.
```
cr0x@server:~$ apt-mark showhold
```
Рішення: Для критичних компонентів використовуйте apt pinning/holds і контрольований rollout, а не «що останнім оновилося».
Ускладніть повторне ненавмисне введення Snap через золоті образи й CI-перевірки.

Рішення: Дрейф пакування — це регресія як будь-яка інша. Тестіруйте його.

Питання та відповіді

1) Чи Snap «поганий» для серверів?

Не за визначенням. Це друга система пакування з автоматичними оновленнями, confinement і залежністю від Store.
Це нормально, якщо вона відповідає вашій операційній моделі. На багатьох продакшн-серверах вона не підходить — якщо ви її не управляєте активно.

2) Який найбільший ризик Snap у продакшні?

Некоординовані зміни. Авто-refresh, що перезапускає демони поза вікном обслуговування — це №1 шлях, як Snap стає причиною paging-а.
Виправте це першим: вікна оновлень, утримання під час замороження і моніторинг.

3) Чи можна просто відключити refresh Snap і забути?

Можна тимчасово утримувати оновлення і обмежити час їх виконання. Але постійне заморожування оновлень — шлях до накопичення вразливостей
з красивим інтерфейсом. Якщо ви не можете патчити snaps надійно, не запускайте snaps для критичних сервісів.

4) Чому Snap їсть диск навіть після видалення додатку?

Snap зберігає ревізії, а snapd і базові snaps займають місце. Якщо ви видалили лише один додаток, у вас можуть лишитися базові snaps.
Перевірте snap list, du -sh /var/lib/snapd /var/snap і зменшіть refresh.retain.

5) Чому я бачу так багато loop-пристроїв?

Кожен snap — це змонтований squashfs-образ, представлений як loop-пристрій. Це нормально.
Операційна дія — не «видаляти loop-пристрої», а «контролювати, скільки ревізій зберігається» і «розумно моніторити використання диска».

6) Який найчистіший спосіб зрозуміти, чи бінарник походить від Snap?

Використовуйте command -v або which. Якщо шлях під /snap/bin, ви виконуєте snap-версію.
Потім перевірте snap list, щоб побачити ревізію і канал.

7) Чи snaps безпечніші через confinement?

Confinement може зменшити радіус ураження, так. Але безпека — це системна властивість: потрібен цикл патчів, який ви контролюєте, спостережуваність
і мережева модель, що підтримує Store. Добре керований deb може бути безпечнішим за snap, який ви ніколи не оновлювали.

8) А як щодо ізольованих або з обмеженим egress середовищ?

Припускайте, що Snap буде проблемним, якщо у вас немає підтримуваної офлайн-стратегії і ви не тестували refresh end-to-end.
Якщо не можете гарантувати доступ до Store (безпосередньо або через схвалений механізм), репозиторії apt, які ви зеркалите внутрішньо, простіші і передбачуваніші.

9) Якщо я залишаю Snap, які мінімальні контролі слід впровадити?

Встановіть вікно оновлень, зменшіть утримання ревізій, моніторьте перезапуски snapd і snap-керованих сервісів, регулярно перевіряйте версійну розбіжність по флоту.
Якщо ви не можете цього зробити — ви не «маєте Snap» — Snap має вас.

10) Чому усунення несправностей здається повільнішим зі Snap?

Бо ментальна карта змінюється: unit-файли згенеровані, логи й локації даних можуть відрізнятися, помилки confinement виглядають як проблеми з правами,
і оновлення відбуваються за окремим графіком. Коли ваші рунабуки включають Snap-специфічні перевірки, це стає простішим.

Практичні наступні кроки

Вирішіть, чи ваші сервери — apt-перші, чи Snap-операційні. Не будьте «як вийшло історично».
Змішана стратегія — це місце, куди баги приходять відтворюватися лише по п’ятницях.

Інвентаризація: запустіть snap list на кожній ролі сервера і зафіксуйте, що встановлено.
Контроль змін: якщо Snap є — встановіть refresh.timer у реальне вікно обслуговування і refresh.retain=2.
Моніторинг: алертьте про події refresh snapd і перезапуски snap-керованих юнітів; графайте зростання /var/lib/snapd.
Стандартизація: для критичних сервісів виберіть один канал, задокументуйте його і забезпечте дотримання в образах і CI-перевірках.
Практика відкату: тестуйте snap revert і вашу apt-стратегію відкату в стенді, щоб не вчитися під тиском.

Ubuntu 24.04 — надійна серверна платформа. Snap може бути частиною цієї оповіді. Але на серверах зручність — не фіча, якщо ви не можете її експлуатувати.
Краща система пакування — та, яка не дивує вас. Друга краща — та, яку ви можете відкотити до того, як клієнти помітять.