Зачем нужен .dockerignore и какие проблемы он реально решает?
.dockerignore исключает файлы из build context: secrets, node_modules, git history, артефакты тестов. Это ускоряет сборку, стабилизирует cache invalidation и снижает риск утечки чувствительных данных в builder.
Зачем нужен .dockerignore
.dockerignore управляет тем, что попадает в build context, отправляемый builder. Это не косметика: context влияет на скорость сборки, cache keys и безопасность. Если в context попадают .env, приватные ключи или огромные каталоги, Docker передаёт их builder даже если Dockerfile их не копирует.
Как это работает
Перед выполнением Dockerfile клиент формирует build context из текущего каталога (или указанного источника) и отправляет его демону. Инструкции COPY и ADD могут брать только файлы из этого context. .dockerignore работает похоже на .gitignore: он перечисляет шаблоны путей, которые должны быть исключены до передачи. Типичные кандидаты на исключение — node_modules, target, dist, .git, локальные базы данных, coverage reports, IDE-файлы и секреты.
В CI это особенно заметно: remote builder или BuildKit worker получает меньше данных. Случайное изменение coverage-файла не сбрасывает cache для слоя COPY . ., потому что этот файл просто не попадает в context.
Пример .dockerignore для Node.js-проекта
.git
node_modules
coverage
.env
.env.local
*.pem
*.key
Dockerfile.local
.tmp
dist
.DS_Store
Влияние на безопасность
Если .dockerignore отсутствует, builder получает весь рабочий каталог, включая .env с паролями, SSH-ключи из ~/.ssh (если сборка идёт из home), а также .git с историей коммитов. Даже если ни один COPY не копирует эти файлы явно, они присутствуют в context, который может логироваться или кэшироваться.
Подводные камни
- Иллюзия безопасности: .dockerignore не заменяет secrets management. Если секрет нужен во время build (например, токен для приватного npm registry), используйте BuildKit secrets (
--mount=type=secret), а не исключение файла из context плюс ARG. - Игнорирование нужных исходников: слишком агрессивный .dockerignore может исключить lockfile или конфиг, после чего build проходит локально из-за кэша, но падает в чистом CI с ошибкой «file not found».
- Глобы без проверки: шаблон
*.envне совпадает с.envбез расширения — нужно добавлять оба варианта явно. - Отсутствие ревью вместе с Dockerfile: список исключений должен проверяться одновременно с
COPY-инструкциями, иначе легко пропустить файл, который попадёт в слой. - Забытый .git: история git добавляет мегабайты в context и может содержать давно удалённые секреты в истории коммитов.
Common mistakes
- Считать, что .dockerignore удаляет файлы из уже собранного image.
- Оставлять .env, SSH keys и .git в build context.
- Игнорировать lockfiles или entrypoint scripts, которые реально нужны Dockerfile.
What the interviewer is testing
- Объясняет build context и связь с COPY/ADD.
- Называет security и performance причины.
- Понимает отличие .dockerignore от runtime secrets.