Что такое контекст сборки и почему используется файл .dockerignore?

Question

Accepted Answer

Когда вы запускаете `docker build`, Docker отправляет **контекст сборки** (файлы в директории сборки) демону. Файл **.dockerignore** исключает ненужные файлы из этого контекста — ускоряя сборку, уменьшая размер образа и предотвращая утечку чувствительных файлов.

## Контекст сборки

```bash
docker build -t myapp .     # the "." is the build context — the directory sent to the daemon
# → Docker tarballs the ENTIRE context directory and sends it to the daemon BEFORE building
# → a big context (node_modules, .git, large files) = slow builds, more data transferred
```

**Контекст сборки** — это набор файлов, которые Docker отправляет демону для построения образа. Все файлы в директории сборки включаются по умолчанию, если они не исключены — поэтому раздутый контекст замедляет каждую сборку.

## .dockerignore — исключение ненужных файлов

```text
# .dockerignore (like .gitignore, for the build context)
node_modules        # don't send local deps (they're installed in the image anyway)
.git                # don't send version history
*.log
.env                # ⚠️ don't send SECRETS into the build context/image
Dockerfile
dist
.vscode
```

`.dockerignore` работает как `.gitignore`, исключая файлы из контекста сборки.

## Почему это важно (три преимущества)

```text
✓ FASTER builds — a smaller context transfers faster; fewer files to process
  (also helps caching: COPY . . won't be invalidated by irrelevant file changes)
✓ SMALLER images — excluded files (node_modules, .git) don't get COPYed into the image
✓ SECURITY — keep SECRETS (.env, keys, credentials) out of the context AND the image
  (a COPY . . could otherwise copy a .env file into the image — a real leak risk)
```

## Почему это важно

Понимание контекста сборки и `.dockerignore` ценно для **эффективной и безопасной сборки Docker**, поэтому это практически полезное знание.

Многие разработчики не осознают, что `docker build .` отправляет **всю директорию контекста сборки демону** перед построением — поэтому раздутый контекст (содержащий `node_modules`, `.git`, артефакты сборки, большие файлы) делает **каждую сборку медленнее** (больше данных для передачи и обработки) и рискует скопировать нежелательные файлы в образ.

Файл **`.dockerignore`** (работающий как `.gitignore`) решает эту проблему тремя конкретными преимуществами: **более быстрые сборки** (меньший контекст передаётся и обрабатывается быстрее, также улучшается кэширование слоёв, так как `COPY . .` не будет инвалидирован изменениями в посторонних файлах), **меньшие образы** (исключённые файлы не копируются — например, локальный `node_modules` не будет собран в образ, так как он переустанавливается в любом случае), и критически важно **безопасность** (хранение **секретов как `.env` файлы, ключи и учётные данные вне контекста сборки и образа** — так как `COPY . .` иначе скопирует `.env` в образ, реальный и распространённый риск утечки учётных данных).

Это преимущество безопасности особенно важно, так как случайное добавление секретов или чувствительных файлов в образы через слишком широкое копирование — это реальная ошибка, которую `.dockerignore` помогает предотвратить.

Поскольку сборки происходят постоянно, и эффективность сборки, размер образа, и предотвращение утечек секретов имеют значение, и поскольку понимание контекста сборки и использование `.dockerignore` непосредственно улучшают все три аспекта, понимание контекста сборки и `.dockerignore` является ценным, практически релевантным знанием Docker — простой, но важной практикой для быстрых, компактных и безопасных сборок, которую легко упустить, но которая имеет значительный практический эффект, особенно для предотвращения случайного включения секретов в образы.