Утоньшение образа: multi-stage, distroless и слои, которые тянутся за секунды

Multi-stage: собирай тяжело, отгружай легко

Ключевая техника — multi-stage сборка: одна стадия держит тяжёлый тулчейн, финальная — только артефакт. Образом становится лишь последняя стадия; всё в стадии сборки — компиляторы, кэши, dev-зависимости — отбрасывается.

# ---- стадия сборки: тяжёлая, никогда не отгружается ----
FROM golang:1.23 AS build
WORKDIR /src
COPY go.mod go.sum ./
RUN go mod download                 # кэшируется, пока go.mod/go.sum не изменятся
COPY . .
RUN CGO_ENABLED=0 go build -o /app ./cmd/server

# ---- финальная стадия: крошечная, отгружается ----
FROM gcr.io/distroless/static-debian12   # база ~2 МБ: ни shell, ни менеджера пакетов
COPY --from=build /app /app
USER nonroot:nonroot
ENTRYPOINT ["/app"]

Финальный образ — это distroless-база (минимальный образ от Google без shell, пакетного менеджера и libc-утилит, ~2 МБ) плюс бинарник — для статического Go-бинарника ~25 МБ всего против 1.2 ГБ наивной одностадийной сборки на golang:1.23. Этот размер — не метрика тщеславия; он возвращается на каждой операции. Pull на холодном узле падает с ~90 с до ~2 с, что напрямую сокращает время реакции автоскейлера и длительность раската. Реестр хранит и передаёт долю байт. И attack surface схлопывается: distroless не тащит ни shell, ни менеджера пакетов, ни OS-утилит, так что скомпрометированный процесс не может sh, curl, apt-get или пивотить через libc-инструменты — а CVE-сканер рапортует почти ноль находок, ведь OS-пакетов, у которых были бы уязвимости, почти нет. Для по-настоящему статического бинарника можно даже FROM scratch (пустая база), отгружая буквально один бинарник; distroless — прагматичная середина, ведь добавляет CA-сертификаты, /etc/passwd и данные таймзон, которых нет у scratch.

Упорядочивание слоёв: кэшируй медленные шаги

Финальный образ уже 25 МБ — но если порядок инструкций Dockerfile неверный, каждая правка кода всё равно запускает многоминутную переустановку зависимостей. Размер образа платишь на pull; порядок слоёв платишь на каждом коммите.

Слои образа контент-адресуемы и кэшируются: слой переиспользуется лишь если его инструкция и все предшествующие слои не изменились. Упорядочь инструкции от наименее- к наиболее-часто-меняющимся, чтобы однострочная правка кода не сбивала слой установки зависимостей. Единственное правило наибольшего рычага — копируй и устанавливай зависимости до копирования исходного кода.

# ХОРОШО — слой зависимостей переживает правки исходника
COPY package.json package-lock.json ./
RUN npm ci                # кэшируется, пока package-файлы не изменятся
COPY . .                  # правки исходника инвалидируют только отсюда вниз
RUN npm run build

# ПЛОХО — каждая правка исходника перезапускает npm ci (минуты)
COPY . .
RUN npm ci                # любая правка файла сбивает это; полная переустановка каждой сборки

В плохом порядке COPY . . идёт до npm ci, так что правка одной строки исходника меняет контекст сборки, инвалидирует тот COPY-слой и форсит полную переустановку зависимостей — превращая 5-секундную инкрементальную сборку в многоминутную. В хорошем порядке установка зависимостей сидит на стабильном слое, ключованном лишь lock-файлами, так что переиспользуется на каждой правке только-исходника. Ещё две дисциплины слоёв важны: .dockerignore, исключающий node_modules, .git и тест-фикстуры, держит мусор вне контекста сборки (меньше, быстрее, и не даёт устаревшему локальному node_modules протечь); и объединение связанных RUN-шагов с очисткой в том же слое (apt-get install ... && rm -rf /var/lib/apt/lists/* ) важно, ведь удаление файлов в более позднем слое не ужимает образ — байты уже закоммичены в раннем слое и лишь маскируются, не удаляются. Число слоёв тоже реальное число: каждый слой — отдельный tar, тянущийся и распаковывающийся, так что десятки крошечных RUN-строк замедляют pull’ы; консолидируй, но не так агрессивно, чтобы уничтожить переиспользование кэша.