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 нет)