Go-приложение. Бинарник – 10MB, статически слинкован, без зависимостей. docker images показывает 900MB. Внутри образа: весь Go SDK (500MB), git, gcc, make, исходники, кеш сборки. Ничего из этого не нужно в production.

900MB на каждый микросервис, 12 сервисов – это 10.8GB на ноду. При деплое скачивается 900MB на каждый pod restart. Rollout занимает минуты вместо секунд.

Multi-stage build решает проблему: один этап для сборки, другой – для запуска. В финальный образ попадает только бинарник.

КАК УСТРОЕНО

Multi-stage build – это несколько FROM в одном Dockerfile. Каждый FROM начинает новый этап (stage). Из предыдущего этапа можно скопировать артефакты через COPY --from=.

# Этап 1: builder -- полная среда сборки
FROM golang:1.23 AS builder
# ... компиляция ...

# Этап 2: production -- минимальный образ
FROM alpine:3.20
COPY --from=builder /app/main /app/main

Финальный образ содержит только то, что есть в последнем FROM + что вы скопировали из предыдущих этапов.

Варианты базовых образов для production:

ПРАКТИКА

Соберите multi-stage Dockerfile для Go-приложения: этап сборки с Go SDK и финальный этап на alpine с одним бинарником.

РАЗБОР

# ===== Этап 1: Builder =====
# Полный Go SDK для компиляции
FROM golang:1.23 AS builder
WORKDIR /app

# Сначала зависимости (кешируются)
COPY go.mod go.sum ./
RUN go mod download

# Затем исходники
COPY . .

# Компиляция статического бинарника
RUN go build -o main .

# ===== Этап 2: Production =====
# Минимальный образ -- только для запуска
FROM alpine:3.20
WORKDIR /app

# Копируем ТОЛЬКО бинарник из builder
COPY --from=builder /app/main /app/main

# Запуск
CMD ["/app/main"]

Результат:

docker images
# REPOSITORY  TAG     SIZE
# myapp       latest  17MB    # <- вместо 900MB

900MB -> 17MB. Разница в 50 раз. Rollout быстрее, registry меньше, attack surface минимален.

Для ещё меньшего образа – scratch вместо alpine:

FROM scratch
COPY --from=builder /app/main /app/main
CMD ["/app/main"]

Это даст ~12MB, но без shell – нельзя зайти внутрь для отладки.

ВОПРОС НА СОБЕСЕ

Вопрос: Как уменьшить размер Docker-образа? Назовите 3–5 способов.

Ревью Docker-образа перед деплоем. docker images показывает 2.1GB для простого Node.js-приложения. Запускаете docker run --rm myapp ls -la и видите: node_modules (800MB), .git (400MB), test-data (500MB). И самое страшное – .env с DB_PASSWORD, JWT_SECRET, AWS_SECRET_KEY.

Образ уже в Docker Hub. Пароли в открытом доступе. Даже если удалить .env в следующем слое – он останется в истории образа. docker history покажет всё.

Исправление: .dockerignore – файл-фильтр, который не пускает лишнее в контекст сборки.

КАК УСТРОЕНО

Когда вы запускаете docker build ., Docker отправляет в daemon весь текущий каталог – это build context. Всё, что в контексте – доступно для COPY и ADD. Всё, что не нужно – замедляет сборку и раздувает образ.

.dockerignore работает как .gitignore: указывает файлы и директории, которые НЕ попадут в build context.

Что должно быть в .dockerignore почти всегда:

ПРАКТИКА

Составьте правильный .dockerignore для Node.js-проекта. Расставьте строки в логичном порядке: сначала VCS и среда, затем зависимости, секреты, тесты и документация.

РАЗБОР

# .dockerignore

# VCS и настройки редактора
.git
.gitignore
.vscode
.idea

# Зависимости (ставятся при сборке)
node_modules

# Секреты — НИКОГДА не должны попасть в образ
.env
.env.*

# Docker мета-файлы
Dockerfile
.dockerignore

# Тесты и покрытие
tests/
coverage/

# Логи и документация
*.log
*.md

Эффект:

• Размер: контекст сборки уменьшается с 2GB до десятков мегабайт
• Скорость: docker build не копирует гигабайты в daemon
• Безопасность: .env физически не попадает в образ, даже случайный COPY . . не утянет секреты

Проверить что попадает в контекст:

# Размер контекста видно в первой строке docker build
docker build . 2>&1 | head -1
# => Sending build context to Docker daemon  45.2MB

ВОПРОС НА СОБЕСЕ

Вопрос: Секрет попал в Docker-образ через COPY. Удаление файла в следующем слое решает проблему?

# Посмотреть историю слоёв
docker history myapp

# Извлечь файловую систему конкретного слоя
docker save myapp | tar -xf - --include='*/layer.tar'

CI pipeline: 47 коммитов в день, каждый запускает docker build. Сборка занимает 8 минут, из них 7 – npm ci. Вы поменяли одну строку в src/index.ts, но Docker заново устанавливает все 1200 зависимостей. Каждый. Раз.

За день это 47 * 7 = 329 минут впустую. За месяц – 110 часов ожидания. И всё потому, что COPY . . стоит перед RUN npm ci.

КАК УСТРОЕНО

Docker собирает образ слоями. Каждая инструкция FROM, COPY, RUN создаёт слой. Слои кешируются.

Правило кеша: если инструкция и всё, что было до неё, не менялись – Docker берёт слой из кеша. Но если слой инвалидирован – все последующие слои тоже пересобираются.

Плохой порядок:

COPY . .          # <-- любое изменение файла инвалидирует кеш
RUN npm ci        # <-- пересобирается каждый раз

Хороший порядок:

COPY package.json package-lock.json ./   # <-- меняется редко
RUN npm ci                                # <-- кешируется!
COPY . .                                  # <-- только исходники

Принцип: от редко меняющегося к часто меняющемуся. Зависимости меняются раз в неделю, код – 47 раз в день. Разнесите их по разным слоям.

ПРАКТИКА

Dockerfile для Node.js-приложения тормозит CI. Расставьте инструкции так, чтобы npm ci кешировался при изменении исходников.

РАЗБОР

# 1. Базовый образ -- меняется раз в квартал
FROM node:22-alpine

# 2. Рабочая директория -- никогда не меняется
WORKDIR /app

# 3. Lock-файлы -- меняются раз в неделю
COPY package.json package-lock.json ./

# 4. Установка зависимостей -- кешируется пока lock-файл тот же
RUN npm ci

# 5. Исходники -- меняются каждый коммит
COPY . .

# 6. Сборка -- пересобирается при изменении кода (это ок)
RUN npm run build

# 7. Запуск
CMD ["node", "dist/index.js"]

Результат: при изменении кода Docker использует кеш для шагов 1–4 (FROM, WORKDIR, COPY lock-файлов, npm ci) и пересобирает только шаги 5–7. Вместо 8 минут – 30 секунд.

Проверить кеширование можно в выводе docker build:

=> CACHED [2/6] WORKDIR /app
=> CACHED [3/6] COPY package.json package-lock.json ./
=> CACHED [4/6] RUN npm ci
=> [5/6] COPY . .

CACHED – значит слой взят из кеша.

ВОПРОС НА СОБЕСЕ

Вопрос: Как работает кеширование слоёв Docker и когда кеш инвалидируется?

Джуниор присылает в чат: “У меня всё работает”. Вы клонируете репозиторий, запускаете npm install – ошибка. У него Node 18, у вас Node 22. У него Ubuntu, у вас macOS. У него python3 указывает на 3.10, у вас – на 3.12.

“Работает у меня” – это не баг, это отсутствие воспроизводимой среды. Dockerfile решает проблему: он описывает среду декларативно. Кто бы ни собрал образ – результат будет одинаковый.

КАК УСТРОЕНО

Dockerfile – это текстовый файл с инструкциями для сборки образа. Каждая инструкция создаёт слой (layer) в образе.

Основные инструкции:

Порядок инструкций важен: Docker кеширует слои, и если слой не менялся – он берётся из кеша. Об этом подробнее в Level 03.

ПРАКТИКА

Вам нужно собрать образ для Node.js-приложения: взять базовый образ, задать рабочую директорию, скопировать исходники, установить зависимости, указать порт и команду запуска.

РАЗБОР

# Базовый образ: Node.js 22 на Alpine Linux (маленький)
FROM node:22-alpine

# Все команды выполняются в /app
WORKDIR /app

# Копируем всё из текущей директории в /app контейнера
COPY . .

# Устанавливаем зависимости
RUN npm install

# Документируем порт (для docker run -P)
EXPOSE 3000

# Команда запуска -- выполнится при docker run
CMD ["node", "app.js"]

Этот Dockerfile работает, но не оптимален. Каждое изменение кода инвалидирует кеш npm install. Как это исправить – в Level 03.

Сборка и запуск:

docker build -t myapp .
docker run -d -p 3000:3000 myapp

ВОПРОС НА СОБЕСЕ

Вопрос: В чём разница между CMD и ENTRYPOINT?

CMD ["node", "app.js"]
# docker run myapp           -> node app.js
# docker run myapp bash      -> bash (CMD заменён)

ENTRYPOINT ["node"]
CMD ["app.js"]
# docker run myapp           -> node app.js
# docker run myapp server.js -> node server.js (CMD заменён, ENTRYPOINT нет)

Пятница, 18:47. Вы обновляете Python на сервере, где крутятся 5 микросервисов. apt upgrade python3 – и бот в Telegram падает, потому что ему нужен Python 3.10, а вы только что поставили 3.12. Заодно сломался Flask-сервис, который зависел от libssl1.1, а теперь стоит libssl3.

Знакомо? Это классика: конфликт зависимостей на общем хосте. Один apt update может положить всё, потому что 5 сервисов делят одну файловую систему, одни библиотеки, один Python.

Docker решает эту боль изоляцией: каждый сервис живёт в своём контейнере со своими зависимостями. Обновление Python в одном контейнере не трогает остальные.

КАК УСТРОЕНО

docker run – это точка входа в мир контейнеров. Одна команда берёт образ (image) и запускает из него изолированный процесс (контейнер).

Что происходит при docker run nginx:

1. Docker ищет образ nginx локально
2. Если нет – скачивает из Docker Hub
3. Создаёт изолированный контейнер (namespaces + cgroups)
4. Запускает процесс nginx внутри

Ключевые флаги, которые нужно знать:

ПРАКТИКА

Вам нужно запустить веб-приложение в контейнере: фоновый режим, проброс порта 8080 на 80, имя webapp, переменная NODE_ENV=production, том для данных.

РАЗБОР

# Полная команда
docker run -d \
  --name webapp \
  -p 8080:80 \
  -e NODE_ENV=production \
  -v ./data:/app/data \
  node:22-alpine

Что здесь происходит:

• docker run -d – запускаем контейнер в фоне, терминал не блокируется
• --name webapp – даём контейнеру понятное имя вместо случайного angry_turing
• -p 8080:80 – порт 8080 на хосте проксируется на порт 80 контейнера
• -e NODE_ENV=production – переменная окружения, приложение знает что это прод
• -v ./data:/app/data – локальная папка ./data монтируется внутрь контейнера, данные переживут рестарт
• node:22-alpine – образ (всегда последний аргумент перед командой)

ВОПРОС НА СОБЕСЕ

Вопрос: Чем отличается контейнер от виртуальной машины?