Docker: Alpine проти Debian-slim — припиніть обирати невірний базовий образ

Правило великого пальця (і коли його порушити)

Якщо ваш сервіс залежить від нативних бібліотек, попередньо зібраних бінарників, агентів від вендорів або взагалі чогось, що ви не компілювали самі: почніть з Debian-slim.
Ви отримуєте glibc, передбачуване пакування й менше дивних крайових випадків. Також краще, коли о 3:00 потрібно швидко подивитися, що всередині.

Якщо ви деплоїте один статичний бінарник (Go з CGO_ENABLED=0, Rust з musl або ретельно контролювана збірка) і точно знаєте, що вам потрібно:
Alpine може бути відмінним вибором. Також підходить для маленьких утилітних образів, де ви хочете простоту BusyBox і повний контроль над залежностями.

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

Жарт №1: Обирати Alpine тільки через те, що він менший, — все одно що купувати мотоцикл, бо він поміщається у вашу кухню. Технічно правда, емоційно сумнівно.

Просте дерево рішень

• Потрібна сумісність з glibc (більшість попередньо зібраного ПЗ розраховано на це): обирайте Debian-slim.
• Потрібно компілювати Python wheels, Node native модулі або використовувати бінарники від вендорів: обирайте Debian-slim.
• Деплойте один статичний бінарник, без shell-скриптів, без компіляції на рантаймі: Alpine підходить.
• Потрібне швидке налагодження інцидентів в контейнері: Debian-slim (або додайте спеціальний debug-образ).
• Потрібен найменший можливий фінальний образ: використовуйте мультистадійні збірки; розгляньте distroless. Не використовуйте Alpine як тимчасове рішення.

Факти й контекст, які можна використати в суперечці

Це не тривіалітети. Це фон «чому так відбувається», який переводить дебати про базові образи з емоцій у інженерні аргументи.

1. Alpine використовує musl libc, а не glibc. Багато бінарників і тонкі поведінкові відмінності libc відрізняються (локалі, DNS, режими багатопотоковості).
2. Користувацький простір Alpine сильно опирається на BusyBox. Звичні утиліти є, але їхні прапорці та поведінка можуть відрізнятися від GNU coreutils.
3. Debian-slim — це все ще Debian: glibc, apt/dpkg і екосистема, на яку орієнтується більшість Linux-ПЗ за замовчуванням.
4. «Slim» означає видалення документації/локалей і деяких пакетів, а не зміну фундаментальних очікувань ABI для Linux-бінарників.
5. Поведінка DNS-резолвера у musl відрізняється від glibc; ця відмінність проявлялася у продакшні під навантаженням або при невірних налаштуваннях resolv.conf.
6. Багато екосистем мов розповсюджують колеса/бінарники під glibc (Python wheels, Node prebuilt modules, агенти вендорів). musl часто змушує збирати з сорців.
7. Статичне лінкування — не безкоштовний бонус. Воно зменшує рантайм-залежності, але ускладнює патчування (ви патчите, перебудовуючи додаток, а не базу).
8. Сканери безпеки рахують пакети. Debian-образи можуть показувати «більше CVE» лише тому, що містять більше пакетів для зіставлення з базами даних.
9. Alpine історично позиціонувався як мінімалістичний і безпечний, але безпека — це процес оновлень, контроль ланцюжка постачання і поведінка під час виконання — не лише менше файлів.

Реальні компроміси: libc, пакети, налагодження, безпека, продуктивність

1) Сумісність libc: musl vs glibc — це ключовий фактор

musl у Alpine — компактна та орієнтована на стандарти бібліотека. glibc — це… glibc: величезна зона сумісності, десятиліття «цей дивний випадок має працювати, бо хтось випустив це в 2009». У світі контейнерів сумісність зазвичай перемагає.

Режим відмови: ви виконуєте docker run щось, що працювало на Ubuntu, і воно падає на Alpine з помилкою лінкеру. Або працює, але має дивну
поведінку під конкуренцією, DNS або локалями. Ваш інцидентний тикет прочитає «випадкові тайм-аути» або «працює лише в продакшні», що завжди весело.

Якщо ви розгортаєте сторонні бінарники (клієнти БД, агенти спостереження, PDF-рендерери, медіа-інструменти), припускайте glibc, поки не доведете протилежне.
Alpine може працювати, але за це доведеться заплатити «податком на розслідування».

2) Екосистема пакетів: apk vs apt — це не лише синтаксис

apk у Alpine швидкий і простий. apt у Debian важчий, але надзвичайно сумісний. Більша різниця в тому, які пакети існують, як часто доводиться збирати з джерел і які дефолтні налаштування включені (сертифікати, локалі, часові пояси).

Якщо ваш Dockerfile містить «залежності для збірки» (компілятори, заголовки), і ви намагаєтеся зберегти runtime-образ маленьким, вам слід робити мультистадійні збірки. Пакетний менеджер тоді стає інструментом збірки, а не способом життя.

3) Налагодження: мінімальні образи чудові, доки не потрібно налагоджувати

У продакшні вам потрібен план, як: «як я бачу DNS, маршрути, TLS-ланцюжки та стан процесів?» Debian-slim зазвичай зручніший тут.
Alpine часто змушує встановлювати інструменти під час інциденту, а це чудовий спосіб виявити, що ви заблокували вихідний трафік з причин безпеки.

Існують дорослі підходи до налагодження (епhemeral debug-контейнери, сайдкари, спеціальні debug-теги). Але якщо їх у вас немає, не обирайте базовий образ,
який робить вас сліпими.

4) Безпека: менше пакетів може означати менше попереджень, а не менший ризик

Менша площа Alpine часто дає менше знахідок у сканерах. Це не означає, що він безпечніший. Сканери вразливостей — це механізми зіставлення з базами даних пакетів, різної якості, а не джерело істини.

Операційне питання безпеки: чи можете ви швидко патчити, перестворювати образи детерміновано та шипити? Стабільний цикл Debian і велика екосистема допомагають.
Каденс Alpine також прийнятний, але його треба відстежувати. У будь-якому разі вам потрібна автоматизація перебудов образів, а не надія.

5) Продуктивність: іноді Alpine швидший, іноді повільніший — здебільшого складно

Люди люблять стверджувати, що Alpine «швидший», бо він менший. Час запуску рідко детерміновано кількома зайвими мегабайтами шарів файлової системи;
зазвичай це ініціалізація рантайму мови, прогрів JIT, затримки DNS, холодні кеші та залежності.

Пастка продуктивності — збірка з джерел. На Alpine ви можете компілювати залежності, які на Debian встановлювалися як попередньо зібрані wheels/бінарники.
Це робить CI повільнішим, збірки менш відтворюваними й іноді породжує відмінні від тестових шляхи виконання.

6) Рамка надійності

Мене цікавлять дві речі: чи можемо ми швидко доставляти зміни, і чи можемо ми налагодити, коли щось ламається? Ось і все. Менший базовий образ приємний, але це не стратегія надійності.

Цитата (перефразовано): Gene Kim часто підкреслює, що покращення надійності походить від скорочення зворотного зв’язку та підвищення видимості роботи — а не від героїчного налагодження.

Рекомендації по рантаймах (Go, Java, Node, Python, Rust, Nginx)

Go

Якщо ви можете зібрати справді статичний бінарник (CGO_ENABLED=0) і вам не потрібні функції, залежні від libc, Alpine підходить. Ви навіть можете зробити образ меншим за Alpine, використавши scratch або distroless для рантайму, з доступним debug-образом при потребі.

Якщо ви використовуєте cgo (драйвери БД, обробка зображень, інтеграції з системою), сумісність з glibc стає важливою. Debian-slim зазвичай безпечніший за замовчуванням.

Java / JVM

Обирайте базовий образ, що відповідає очікуванням вашого JDK/JRE. Багато JVM-дистрибутивів припускають glibc і стандартні інструменти. Існують образи JVM на основі Alpine, але треба свідомо підходити до сертифікатів CA, шрифтів (так, шрифтів) і поведінки DNS.

Node.js

Проекти Node з нативними модулями (node-gyp, bcrypt, sharp, grpc, canvas) — це місце, де проблеми Alpine процвітають. Вам або доведеться компілювати модулі з джерел (привіт, toolchain для збірки), або боротися з prebuilt артефактами, які націлені на glibc. Debian-slim уникає більшості цих проблем.

Python

Python на Alpine часто означає «збирати з джерел» для всього, що має нативні залежності (cryptography, lxml, numpy, pandas). Це не завжди погано, але операційно дорожче. Debian-slim зазвичай отримує багато prebuilt manylinux wheels, які «просто працюють».

Rust

Rust може таргетувати musl і виробляти майже статичні бінарники. Це реальна вигода для мінімальних рантайм-образів. Просто переконайтеся, що розумієте, як будете патчити залежності: ви патчите, перебудовуючи бінарник, а не апгрейдя libc через apt.

Nginx / Envoy / HAProxy

Для стандартного веб-проксіювання обидва варіанти підходять. Вибір зазвичай зводиться до екосистеми модулів і ваших звичок налагодження.
Якщо ви хочете знайомі інструменти і передбачувані модулі — Debian-slim зручніший. Якщо ви прагнете меншої поверхні і впевнені у своєму пайплайні збірки — Alpine теж може працювати.

Три історії з корпоративного життя

Міні-історія №1: Інцидент через неправильне припущення

Команда мігрувала набір внутрішніх API з «будь-якого базового образу, що був» на Alpine, щоб зменшити розмір образів і пришвидшити деплои. Нічого екзотичного:
сервіс на Node.js, спілкується з Postgres, робить HTTPS-запити до партнерів, шипить логи. CI був зелений, стаджинг виглядав нормально.

Дві тижні потому в продакшні почали з’являтися спорадичні тайм-аути при зовнішніх HTTPS-запитах. Не всі виклики. Не у всіх регіонах. І, звісно, не в стаджингу.
Дашборди показували сплески латентності, потім каскад повторних спроб, потім партнери почали лімітувати їх. Класична спіраль надійності: ретраї перетворюють невелику проблему на голосну.

Неправильне припущення було в тому, що «DNS — це DNS». Поведінка резолвера контейнера відрізнялася при конкретних налаштуваннях resolv.conf і способі, як кластер інджектував search-домени.
Під навантаженням ті додаткові спроби пошуку й інша кешувальна поведінка підсилювали латентність. Сервіс не «ламався», він системно гірше виконував резолв і це мало значення лише при продакшн-навантаженні.

Виправлення було не героїчним: вони повернули сервіс на Debian-slim, поки тестували налаштування резолвера і зменшували search-домени.
Латентність нормалізувалася миттєво. Пізніше вони знову розглядали Alpine з тестовими стендами і явними налаштуваннями резолвера. Але урок залишився:
зміни базового образу — це зміни поведінки рантайму, а не косметика.

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

Інша організація захотіла швидших збірок і менше попереджень від сканерів. Хтось запропонував єдиний стандарт: «Усе на Alpine. Однорідність — це менше рутинної роботи».
Вони оновили десяток сервісів, включно з Python задачами для обробки даних, що запускалися щогодини і були «достатньо прості».

Перший біль з’явився в CI: інсталяції заняли більше часу, бо пакети, що раніше були wheels, стали збиратися з джерел. Щоб тест пройшов, інженери додали залежності для збірки: компілятори, заголовки й достатньо тулчейну, щоб соромно стало невеликому дистрибутиву Linux.
Dockerfile ускладнилися. Промахи кешу стали дорожчими.

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

Вони врешті розділили флот: сервісам із чистими статичними бінарниками дали мінімальні образи; Python/Node сервіси повернулися до Debian-slim з мультистадійними збірками та агресивним фіксуванням залежностей.
Однорідність замінили на менший стандарт: «За замовчуванням обираємо сумісність; оптимізуємо лише там, де це справді важливо.» Нудно. Ефективно.

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

Платформна команда запровадила політику, що звучала нудно: кожен сервіс має мати (1) стадію збірки, (2) стадію рантайму і (3) опційний debug-тег з інструментами для налагодження, який відповідає libc рантайму.

Одної п’ятниці сервіс, пов’язаний з платежами, почав лягати під час TLS-рукопотискань з третьою стороною. Вендор обернув проміжний CA.
Сервіс працював в одному кластері і не працював в іншому — саме те, що може зіпсувати вихідні.

Оскільки у них був варіант debug-образу, on-call міг приєднати його і негайно перевірити ланцюжок сертифікатів, версії CA-бандлів і поведінку OpenSSL без перебудови образів під час інциденту.
Вони підтвердили, що рантайм-образ у проблемному кластері мав старіший CA-бандл через закріплений digest бази, який не перебудовували кілька тижнів.

Виправлення було нудним: перебудувати й перевдеплоїти з оновленим базовим образом і сертифікатами CA, потім додати політику перебудов тижнево навіть без змін коду.
Інцидент завершився швидко, бо команда інвестувала в непривабливі частини: відтворювані збірки й передбачуване налагодження.

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

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

Завдання 1: Визначити лінію походження базового образу

cr0x@server:~$ docker image inspect myapp:latest --format '{{.Id}} {{.RepoTags}}'
sha256:2c9f3d2a6b1f... [myapp:latest]

Що це означає: У вас є незмінний ID образу. Теги брешуть; ID — ні.

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

Завдання 2: Підтвердити, musl чи glibc

cr0x@server:~$ docker run --rm myapp:latest sh -c 'ldd --version 2>&1 | head -n 1'
musl libc (x86_64) Version 1.2.4

Що це означає: musl libc: по суті ви в середовищі Alpine, навіть якщо образ не має тегу alpine:tag.

Рішення: Якщо ви запускаєте попередньо зібрані бінарники від вендорів або нативні модулі Python/Node, припускайте ризик несумісності. Розгляньте перехід на Debian-slim або перебудову залежностей відповідно.

Завдання 3: Перевірити метадані релізу ОС

cr0x@server:~$ docker run --rm myapp:latest sh -c 'cat /etc/os-release'
PRETTY_NAME="Alpine Linux v3.20"
NAME="Alpine Linux"
ID=alpine
VERSION_ID=3.20.2

Що це означає: Ви знаєте дистрибутив і версію — корисно для обговорення CVE і відтворюваності.

Рішення: Закріпіть базову версію по major/minor (або краще — по digest) і заплануйте перебудови. «latest» — це шлях до несподіваних оновлень.

Завдання 4: Правильно виміряти розмір образу (стиснений та нестиснений)

cr0x@server:~$ docker image ls myapp:latest --format 'REPO={{.Repository}} TAG={{.Tag}} SIZE={{.Size}}'
REPO=myapp TAG=latest SIZE=146MB

Що це означає: Docker показує розмір, на який впливають шари й стиснення, а не лише «що ви шипите».

Рішення: Якщо ви оптимізуєте розмір, зосередьтеся на залежностях і шарах збірки; не міняйте libc як перший крок.

Завдання 5: Подивитися, що змінилося по шарах

cr0x@server:~$ docker history myapp:latest --no-trunc | head -n 6
IMAGE          CREATED        CREATED BY                                      SIZE      COMMENT
2c9f3d2a6b1f   2 days ago     /bin/sh -c apk add --no-cache curl bash         13.2MB
9a1d4f0c1e22   2 days ago     /bin/sh -c adduser -D -g '' app                 3.1kB
b17c11d9fba0   2 days ago     /bin/sh -c #(nop)  COPY file:... in /app        62.4MB
4f2a1c0f2d9e   3 weeks ago    /bin/sh -c #(nop)  FROM alpine:3.20             5.6MB

Що це означає: Ви можете помітити «ми встановили curl і bash у продакшні» та інші поступові нарощення.

Рішення: Перенесіть інструменти налагодження до debug-образу; тримайте рантайм легким і контрольованим.

Завдання 6: Перевірити наявність CA-сертифікатів (TLS-помилки часто через відсутні CA)

cr0x@server:~$ docker run --rm myapp:latest sh -c 'ls -l /etc/ssl/certs | head'
total 84
-rw-r--r--    1 root     root          1477 Oct  2  2025  ca-certificates.crt
drwxr-xr-x    2 root     root          4096 Oct  2  2025  java

Що це означає: Є бандл сертифікатів; щонайменше базові речі присутні.

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

Завдання 7: Відтворити TLS-рукопотискання і подивитися ланцюжок

cr0x@server:~$ docker run --rm myapp:latest sh -c 'echo | openssl s_client -connect api.example.com:443 -servername api.example.com 2>/dev/null | openssl x509 -noout -issuer -subject | head -n 2'
issuer=CN = Example Intermediate CA, O = Example Corp
subject=CN = api.example.com

Що це означає: Ви бачите, який CA використовується і чи контейнер може запускати інструменти OpenSSL.

Рішення: Якщо базовий образ не має інструментів, додайте debug-образ або шипніть мінімальні інструменти. Не чекайте на інцидент.

Завдання 8: Інспектувати конфігурацію DNS-резолвера всередині контейнера

cr0x@server:~$ docker run --rm myapp:latest sh -c 'cat /etc/resolv.conf'
nameserver 10.96.0.10
search default.svc.cluster.local svc.cluster.local cluster.local
options ndots:5

Що це означає: Велике значення ndots + кілька search-доменів можуть створювати додаткові запити і латентність.

Рішення: Якщо під навантаженням виникають тайм-аути DNS, зменшіть search-домени або налаштуйте ndots на рівні платформи; будьте обережні з образами на основі musl.

Завдання 9: Заміряти час DNS-запитів всередині контейнера

cr0x@server:~$ docker run --rm myapp:latest sh -c 'time getent hosts api.example.com | head -n 1'
203.0.113.10 api.example.com

real    0m0.043s
user    0m0.000s
sys     0m0.002s

Що це означає: getent використовує системний шлях резолвера. Це хороший первинний наближений тест поведінки DNS.

Рішення: Якщо резолв повільний, не профілюйте додаток ще. Спочатку виправте DNS або поведінку резолвера.

Завдання 10: Підтвердити, чи бінарник динамічно лінкований (і з чим)

cr0x@server:~$ docker run --rm myapp:latest sh -c 'file /app/myapp'
/app/myapp: ELF 64-bit LSB pie executable, x86-64, dynamically linked, interpreter /lib/ld-musl-x86_64.so.1, stripped

Що це означає: Він динамічно лінкований до musl. Не можна притворятися, що це «портативний Linux». Це musl Linux.

Рішення: Якщо ви хочете максимальну портативність і передбачувану поведінку, збудуйте бінарник під glibc і запускайте на Debian-slim, або зробіть повністю статичну збірку з відомими компромісами.

Завдання 11: Виявити відсутні спільні бібліотеки під час виконання

cr0x@server:~$ docker run --rm myapp:latest sh -c 'ldd /app/myapp | tail -n 3'
libpthread.so.0 => /lib/libpthread.so.0 (0x7f1f0c4a0000)
libc.musl-x86_64.so.1 => /lib/ld-musl-x86_64.so.1 (0x7f1f0c6a0000)
Error relocating /app/myapp: __strdup: symbol not found

Що це означає: У вас збіг символів — класична проблема libc/ABI.

Рішення: Припиніть примусово це тягнути. Перенесіть рантайм на Debian-slim (glibc) або перебудуйте бінарник спеціально для musl і ретельно протестуйте.

Завдання 12: Перевірити, чи ваш «slim» образ все ще має shell і інструменти

cr0x@server:~$ docker run --rm debian:bookworm-slim sh -c 'command -v bash || echo "bash missing"; command -v curl || echo "curl missing"'
bash missing
curl missing

Що це означає: Debian-slim — це не «повний Debian». Він навмисно лаконічний.

Рішення: Якщо вам потрібні інструменти, встановіть їх явно або покладайтеся на debug-образ. Не припускайте, що вони є.

Завдання 13: Порівняти інвентар пакетів (корисно для шуму сканера і поверхні атаки)

cr0x@server:~$ docker run --rm alpine:3.20 sh -c 'apk info | wc -l'
14

Що це означає: Дуже мало пакетів у базовому Alpine-образі.

Рішення: Якщо згодом ви бачите 120+ пакетів, ви вже не «мінімальні». Перегляньте Dockerfile і розбийте build і runtime-стадії.

Завдання 14: Перевірити, чи можна патчити базовий образ без змін коду

cr0x@server:~$ docker build --pull --no-cache -t myapp:rebuild .
...snip...
Successfully built 6c1a1a7f9f19
Successfully tagged myapp:rebuild

Що це означає: Ви можете перебудувати з актуальних базових шарів. Так ви підхоплюєте оновлення CA та патчі безпеки.

Рішення: Якщо перебудови падають або тривають години — виправте пайплайн збірки. Патчування має бути нудним.

Жарт №2: «Ми не можемо зараз перебудувати» — це контейнерний еквівалент «трінькотка дуже гучна, можна її вимкнути?» Це не план.

План швидкої діагностики

Коли контейнерний сервіс поводиться неправильно після зміни базового образу (або під час міграції), вам потрібна швидка, відтворювана послідовність дій.
Не починайте з профілювання CPU. Почніть з нудних шарів, які ламаються першими.

По-перше: підтвердіть, що саме запущено

• ID образу в проді проти того, що ви вважаєте деплойнутим. Якщо вони відрізняються — припиніть і виправляйте дрейф деплою.
• ОС + libc всередині контейнера: Alpine/musl або Debian/glibc. Це одразу звужує можливі причини відмови.
• Entrypoint і команда: переконайтеся, що ви не втратили bash і не зламали скрипти, або не змінили робочі директорії.

По-друге: перевірте базову мережеву роботу всередині контейнера

• Час розв’язування DNS за допомогою getent для критичних хостів.
• TLS-рукопотискання до ключових кінцевих точок. Шукайте помилки CA і відмінності в ланцюжку.
• Проксі-змінні (HTTP_PROXY, NO_PROXY) і конфіг резолвера.

По-третє: перевірте залежності рантайму та лінкування

• Спільні бібліотеки: запустіть ldd і шукайте «not found» або relocation-помилки.
• Сумісність рантайму мов: Python wheels, Node native модулі, Java cert stores, пакети шрифтів.
• Часові пояси/локалі, якщо симптом — «працює лише в регіоні X» або «зліпки часу невірні».

По-четверте: лише тоді вимірюйте продуктивність

• Розбиття латентності запиту: DNS, connect, TLS, час upstream.
• CPU проти I/O: перевірте, чи зміна базового образу спричинила інші шляхи виконання (наприклад, інший криптобекенд) або просто змістила вузькі місця.
• Відтворюваність збірки: якщо продуктивність змінилася, підтвердіть, що артефакт ідентичний, окрім базового шару.

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

1) «Exec format error» або «not found», коли файл явно існує

Симптом: Контейнер стартує і відразу падає з «no such file or directory» для бінарника, який присутній.

Корінь проблеми: Відсутній інтерпретатор/завантажувач або невідповідний libc ABI (glibc-лінкований бінарник у musl-образі), або неправильна архітектура.

Виправлення: Запустіть file і ldd всередині образу. Якщо він очікує glibc — переходьте на Debian-slim або перебудуйте під musl/статично.

2) TLS падає лише в окремих середовищах

Симптом: «x509: certificate signed by unknown authority» або помилки рукопотискання після ротації проміжних сертифікатів вендором.

Корінь проблеми: Застарілий CA-бандл або різна поведінка сховища сертифікатів (особливо між різними базовими образами).

Виправлення: Переконайтеся, що ca-certificates встановлені; регулярно перебудовуйте образи; валідуйте через openssl s_client у debug-образі.

3) DNS-тайм-аути, що зникають при повторній спробі

Симптом: Спорадичні тайм-аути при розв’язуванні імен сервісів; ретраї допомагають, але під навантаженням проблема посилюється.

Корінь проблеми: Взаємодія поведінки резолвера/search-доменів/ndots з musl; або DNS-кластер під навантаженням, підсилений додатковими запитами.

Виправлення: Заміряйте час резолву через getent; зменшіть search-домени; налаштуйте ndots; розгляньте Debian-slim, якщо поведінка відрізняється і вам потрібна передбачувана поведінка резолвера glibc.

4) Node/Python залежності раптом компілюються в CI і збірки сповільнюються

Симптом: Час збірки зріс; з’явилися нові залежності від компіляторів і заголовків; збірки стали нестабільними.

Корінь проблеми: Попередньо зібрані артефакти націлені на glibc; на musl ви переходите до збірки з джерел.

Виправлення: Використовуйте Debian-slim для таких навантажень або явно фіксуйте і збирайте артефакти в контрольованій стадії builder. Не додавайте apk add build-base у продакшн-образи.

5) «Працює в slim, падає в alpine» shell-скрипти

Симптом: Entrypoint-скрипти падають на Alpine через іншу поведінку sed, grep, date.

Корінь проблеми: Утиліти BusyBox відрізняються від GNU coreutils; скрипти залежать від непортованих прапорів.

Виправлення: Зробіть скрипти POSIX-сумісними або встановіть потрібні GNU-інструменти явно; краще: уникайте shell-склеювання в рантайм-образах, де це можливо.

6) Кількість CVE стрибнула після переходу на Debian-slim

Симптом: Сканер безпеки показує більше знахідок; менеджмент панікує.

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

Виправлення: Проведіть триаж за щільністю рантайму і наявністю фіксів. Зменште пакети через мультистадійні збірки. Відстежуйте каденс перебудов і закріплюйте digests.

7) «Мінімальні» образи, які насправді не мінімальні

Симптом: Alpine-образ стає більшим за Debian-slim після додавання тулчейну збірки, shell-ів і інструментів налагодження.

Корінь проблеми: Використання Alpine як хитрощі замість правильної мультистадійної роздільної збірки.

Виправлення: Розділіть build/runtime-стадії. Залишайте у фінальній стадії лише рантайм-бібліотеки і артефакти додатку.

Чеклісти / покроковий план

Чекліст A: Обрати базовий образ (дефолт для продакшну)

1. Перелічте рантайм-залежності: нативні бібліотеки, бінарники від вендорів, розширення мов, потреби SSL/TLS.
2. Якщо будь-яка залежність — «бінарник з інтернету», за замовчуванням обирайте Debian-slim.
3. Якщо сервіс — один статичний бінарник і ви можете це довести: Alpine прийнятний.
4. Визначте зараз, як будете налагоджувати: debug-образ, епhemeral debug-контейнери або мінімальні інструменти в рантаймі.
5. Закріпіть базовий образ по digest або за суворою політикою версій. Заплануйте перебудови.

Чекліст B: Пайплайн збірки, що не підведе

1. Використовуйте мультистадійні збірки: стадія builder має компілятори; рантайм-стадія — ні.
2. Роби збірки детермінованими: фіксуйте залежності; уникайте «curl | sh» інсталяторів.
3. Запускайте смок-тест всередині побудованого образу: DNS lookup, TLS рукопотискання, запуск бінарника.
4. Генеруйте debug-тег, що відповідає libc рантайму (musl debug інструменти для musl, glibc debug інструменти для glibc).
5. Перебудовуйте образи за розкладом, навіть без змін коду, щоб підхоплювати оновлення CA та патчі безпеки.

Чекліст C: Перед міграцією на Alpine

1. Запустіть ldd на кожному бінарнику, який ви шипите або завантажуєте.
2. Протестуйте поведінку DNS під навантаженням у середовищі, що відповідає продакшн-resolv.conf.
3. Перевірте TLS до всіх зовнішніх залежностей з актуальними CA-бандлами.
4. Підтвердьте, що ваша екосистема мов підтримує musl без несподіваних збірок з джерел.
5. Вирішіть, як ви справлятиметесь із моментами «потрібен tcpdump» (підказка: не через перебудову в продакшні).

Поширені питання (FAQ)

1) Чи Alpine «безпечніший», бо менший?

Менший розмір може зменшити кількість пакетів з потенційними вразливостями, але безпека здебільшого про швидкість патчів, автоматизацію перебудов і контроль виконання.
Alpine може бути безпечним. Debian-slim може бути безпечним. Небезпечний варіант — той, який ви не перебудовуєте.

2) Чому сканери показують менше CVE на Alpine?

Багато сканерів зіставляють CVE з назвами/версіями пакетів. Менше пакетів — менше збігів. Це сигнал, а не вирок. Зосередьтеся на шляхах експлуатації і можливості патчити.

3) Чи робить Debian-slim мій образ величезним?

Ні, якщо ви використовуєте мультистадійні збірки і тримаєте інструменти збірки поза рантаймом. Багато production-образів на Debian-slim невеликі, бо домінують розміром додаток і його рантайм-залежності, а не база.

4) Чи можна запускати glibc-додатки на Alpine, встановивши glibc?

Можна, але тоді ви підтримуєте гібридне середовище з більшою кількістю крайових випадків. Якщо ваш робочий навантаження потребує glibc, зазвичай дешевше і безпечніше запускати на Debian-slim.

5) Що з distroless-образами?

Distroless може бути відмінним для зменшення рантайм-поверхні, особливо для статичних бінарників або добре відомих рантаймів. Але вам потрібна стратегія налагодження. Distroless без debug-шляху — це операційний борг.

6) Чому Node native модулі не люблять Alpine?

Багато prebuilt Node модулів компілюються проти glibc. На Alpine (musl) ви часто переходите до збірки з джерел, що потребує компіляторів і заголовків. Це збільшує час збірки і складність.

7) Чи musl «гірша» за glibc?

Ні. Вона інша. musl — компактна і орієнтована на стандарти. glibc — максимізує сумісність. У продакшні сумісність із ширшою екосистемою часто виграє.

8) Чи варто стандартизувати на одному базовому образі в компанії?

Стандартизуйте на рамці для прийняття рішень, а не на одному образі. Один образ для всього звучить охайно, поки не зіштовхнетеся з рантаймом, який потребує інших припущень. Надавайте схвалені опції: Debian-slim за замовчуванням, Alpine для статичних бінарників, distroless де доцільно.

9) Як часто ми повинні перебудовувати образи, якщо код не змінюється?

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

Наступні кроки (зробіть це в понеділок)

1. Визначте дефолт: Debian-slim для більшості сервісів; Alpine — тільки для статичних бінарників і суворо контрольованих графів залежностей.
2. Додайте debug-варіант: сусідній образ/тег з базовими мережевими та TLS-інструментами, що відповідає libc вашого рантайму.
3. Запровадьте каденс перебудов: регулярно перебудовуйте і перевдеплойте базові образи; припиніть ставитися до базових шарів як до «встановив і забув».
4. Інструментуйте нудні речі: латентність DNS, помилки TLS і часи підключення до upstream. Це перші показники, що відрізняються між базовими образами.
5. Запишіть правило: «Ми обираємо базові образи за сумісністю та експлуатаційністю в першу чергу; розмір — другорядна оптимізація.» Покладіть це в документацію платформи і контролюйте в рев’ю.

Найкращий базовий образ — той, який не перетворює рутинні відмови на загадки. Alpine може бути таким образом. Debian-slim може бути таким образом.
Але якщо ви обираєте на основі відчуттів і мегабайтів, продакшн навчить вас — дорого.