ОБРАЗ ЯК ШАРИ, DOCKERFILE, КЕШ, БАГАТОЕТАПНА ЗБІРКА

Вступ: образ як послідовність diff-ів

Попередні дві лекції були про запущений контейнер: процес, якому namespaces підмінили видимість, а cgroups обмежили апетит. Сьогодні ми відступаємо на крок назад і дивимось на те, з чого цей процес узагалі стартує — на образ (image). Найпоширеніша інтуїтивна помилка — уявляти образ як файл, схожий на ISO-файл ОС або архів. Це невірно на фундаментальному рівні: образ — це впорядкований стек незмінних шарів (layers), кожен з яких є diff-ом файлової системи відносно попереднього. Розуміння цього факту пояснює одразу кілька практичних речей: чому образи можна кешувати частково, чому docker pull для спільної бази качає лише один раз, і чому порядок інструкцій у Dockerfile напряму впливає на швидкість збірки.

Образ — це не файл, а стек шарів

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

• незмінний (immutable) — після створення шар ніколи не редагується;
• адресований за вмістом (content-addressable) — ідентифікатор шару це криптографічний хеш (SHA-256) його вмісту, а не довільне ім'я;
• потенційно спільний — якщо два образи побудовані на тій самій базі (наприклад, ubuntu:24.04), вони буквально посилаються на той самий шар на диску й у реєстрі, без дублювання.

Саме тому docker pull для другого образу з тією ж базою завантажує значно менше даних — Docker перевіряє за хешем, які шари вже є локально, і качає лише відсутні.

Dockerfile: кожна інструкція — потенційний шар

Не кожна інструкція Dockerfile створює шар з реальним вмістом файлової системи. Практично важливий поділ:

ADD навмисно уникають на користь COPY, коли не потрібне автоматичне розпакування: ADD з URL-джерелом не кешує вміст за етагом надійно й може непомітно розпакувати архів там, де очікувалась проста копія файлу — менш передбачувана поведінка для звичайного випадку.

FROM ubuntu:24.04
RUN apt-get update && apt-get install -y curl
COPY app.sh /app.sh
CMD ["/app.sh"]

Тут — три змістовні шари з файловим вмістом (базовий образ, встановлений curl, скопійований файл) і одна метадані-інструкція CMD.

Кеш збірки: чому порядок інструкцій має значення

Docker кешує кожен шар за комбінацією хеша інструкції та хеша її вхідних даних (вмісту файлів для COPY/ADD, тексту команди для RUN). Якщо для конкретного кроку збірки хеш збігається з уже наявним у кеші шаром — Docker перевикористовує готовий шар, не виконуючи інструкцію заново.

Критичний нюанс: кеш ламається каскадно. Щойно один шар змінився (наприклад, змінився вміст файлу, який копіює COPY), усі наступні за ним інструкції в Dockerfile гарантовано виконуються заново, навіть якщо самі вони не залежать від зміненого файлу — Docker не аналізує залежності між кроками глибше, ніж «попередній шар відрізняється».

# погано: COPY усього коду перед install ламає кеш на кожній зміні коду
COPY . .
RUN npm install

# добре: спершу залежності — кешуються, доки package.json не змінився
COPY package*.json .
RUN npm install
COPY . .

Практичне правило: розташовуй стабільні, рідкозмінні інструкції (встановлення залежностей за lock-файлом) на початку Dockerfile, а мінливі (копіювання власного коду) — якомога ближче до кінця. Сучасний бекенд збірки BuildKit (типовий у Docker з версії 23+) додає ще один інструмент — кеш-монтування (--mount=type=cache), яке дозволяє кешувати вміст каталогу (наприклад, кеш пакетного менеджера) між збірками, навіть коли сам шар перебудовується:

RUN --mount=type=cache,target=/root/.cargo/registry \
    cargo build --release

OverlayFS: як шари стають однією файловою системою

Під час запуску контейнера всі шари образу об'єднуються в єдиний вигляд файлової системи за допомогою об'єднаної файлової системи (OverlayFS) — файлової системи ядра Linux, спеціально призначеної для накладання (overlay) кількох каталогів один на одного:

• lowerdir — стек шарів образу, змонтований лише для читання (їх може бути декілька, у порядку від найглибшого до найближчого);
• upperdir — один порожній на старті шар для запису, унікальний для кожного запущеного контейнера;
• workdir — службовий каталог, потрібний OverlayFS для внутрішніх операцій (атомарне перейменування тощо), не використовується напряму;
• merged — фінальний, об'єднаний вигляд, який і бачить процес усередині контейнера як звичайну кореневу файлову систему.

Коли процес усередині контейнера змінює файл, який фізично лежить у нижньому (read-only) шарі, спрацьовує механізм copy-up: файл спершу копіюється в upperdir, і вже там змінюється — сам образ (lowerdir) лишається незайманим. Це і є copy-on-write на рівні файлової системи. Видалення контейнера просто відкидає upperdir: образ, з якого він був запущений, ніяк не постраждав і готовий до наступного запуску.

Багатоетапна збірка (multi-stage build)

Типова проблема: інструменти, потрібні лише для збірки (компілятор, dev-заголовки, кеш пакетного менеджера), лишаються в фінальному образі, хоча під час виконання не потрібні взагалі. Наслідок — образ вагою 1.5 ГБ замість 15 МБ для одного статичного бінарника.

Багатоетапна збірка дозволяє описати кілька незалежних стадій FROM в одному Dockerfile, кожна — свій ізольований контекст файлової системи, і переносити з однієї стадії в іншу лише конкретні артефакти через COPY --from=<stage>:

FROM rust:1.80 AS build
WORKDIR /src
COPY . .
RUN cargo build --release

FROM scratch
COPY --from=build /src/target/release/app /app
ENTRYPOINT ["/app"]

Проміжна стадія build (з компілятором Rust, cargo-кешем, вихідним кодом) ніколи не потрапляє в фінальний образ — лише готовий бінарник /app, скопійований у порожній scratch. Стадій може бути й більше двох (наприклад, окрема стадія для тестів), і збірку можна зупинити на конкретній стадії прапорцем docker build --target=build, що зручно для CI, де потрібен лише проміжний артефакт або лише прогін тестів.

scratch, distroless та alpine: що обрати для фінального шару

scratch — буквально порожній образ: жодного шару, ні shell, ні libc, ні coreutils. Підходить винятково для статично зібраних бінарників (Rust зі статичним лінкуванням, Go). Плюс — мінімальний розмір і мінімальна поверхня атаки; мінус — усередині контейнера неможливо навіть зайти через sh для діагностики.

Distroless (образи від Google, gcr.io/distroless/*) — компроміс: містить лише мінімальний runtime (наприклад, glibc й necessary shared libraries для запуску динамічно злінкованого бінарника), але без пакетного менеджера, shell чи допоміжних утиліт — сильно звужена поверхня атаки порівняно з повноцінним дистрибутивом, і водночас працює з динамічно злінкованими бінарниками, на відміну від scratch.

Alpine — повноцінний, але надзвичайно компактний дистрибутив (~5 МБ) на основі musl libc замість glibc, із власним пакетним менеджером apk. Зручний, коли потрібен shell для діагностики або динамічні залежності, яких немає в distroless; підводний камінь — musl іноді поводиться інакше за glibc в деяких Rust/Go бінарниках (DNS-резолвінг, локалі), тому це не завжди «безкоштовна» заміна.

Digests: незмінна ідентичність образу

Тег (nginx:1.27) — зручне, але змінне ім'я: власник реєстру може перезаписати, на який саме вміст він указує. Digest — криптографічний хеш SHA-256 маніфесту образу — незмінний ідентифікатор:

docker inspect demo:1 | grep -A5 RootFS
# "RootFS": { "Type": "layers", "Layers": [ "sha256:1a2b...", "sha256:3c4d..." ] }

docker pull nginx@sha256:8f9c... # точний, незмінний вміст, а не "поточний nginx:latest"

У production-пайплайнах прийнято пінити саме digest (а не лише тег) для критичних базових образів — гарантія, що завтрашній docker pull не підмінить вміст несподівано оновленим тегом.

OCI: стандарт під капотом Docker

Docker — не єдиний інструмент, що вміє будувати й запускати такі шаруваті образи. Формат образу і шарів стандартизований організацією Open Container Initiative (OCI): OCI Image Spec визначає, як виглядає маніфест образу (перелік шарів з їхніми SHA-256-хешами, конфігурація запуску, мітки), а OCI Runtime Spec — як шари розгортаються в кореневу файлову систему й запускаються як процес. Завдяки цьому образ, зібраний docker build, можна запустити через podman, containerd чи будь-який інший OCI-сумісний рантайм без жодних змін — специфічного для Docker у самому образі немає нічого, лише в CLI поверх нього.

Це також пояснює, чому образ ubuntu:24.04 важить приблизно 80 МБ, а не кілька гігабайтів повноцінної інсталяції ОС: базовий образ — це мінімальний набір файлів дистрибутиву (coreutils, apt, базові бібліотеки), без ядра (ядро спільне з хостом!), без графічного стеку, без документації та локалей, які прибирають ще на етапі збірки офіційного образу.

Підводні камені

• latest — не «найновіший», а просто тег за замовчуванням, який будь-хто може перепризначити на інший вміст; для відтворюваних збірок пінь версію або digest.
• COPY . . на початку Dockerfile — найпоширеніша причина «завжди перебудовується з нуля»: будь-яка зміна в репозиторії (навіть у README) ламає весь подальший кеш.
• .dockerignore забувають, і контекст збірки (усе, що надсилається демону) роздувається до гігабайтів через node_modules, .git, артефакти збірки.
• scratch несумісний з динамічним лінкуванням: бінарник, який лінкується з glibc динамічно, у scratch просто не запуститься — потрібне статичне лінкування або distroless/alpine з відповідною бібліотекою.
• Багато дрібних RUN замість одного об'єднаного через && множить кількість шарів і фінальний розмір, бо видалені в наступному RUN файли не звільняють місце в попередньому шарі — вони лише позначені як видалені (whiteout-файли OverlayFS).

Підсумок

Docker-образ — не файл, а впорядкований стек незмінних, адресованих за вмістом шарів; кожна інструкція Dockerfile з файловим ефектом (FROM, RUN, COPY, ADD) створює новий шар, тоді як метадані-інструкції (ENV, CMD, WORKDIR) шару з вмістом не додають. Порядок інструкцій визначає ефективність кешу збірки — BuildKit і кеш-монтування додатково пришвидшують повторні збірки. OverlayFS об'єднує шари в єдину файлову систему через lowerdir/upperdir/merged, а багатоетапна збірка разом зі scratch/distroless/alpine дає змогу відокремити важкий інструментарій збірки від мінімального образу виконання. Наступний блок лабораторних переходить від одного контейнера до кількох, що спілкуються через ізольовану мережу.