Build context в Docker — это каталог (и его содержимое), который Docker целиком упаковывает и отправляет демону при выполнении docker build; только из этого контекста инструкции COPY и ADD могут брать файлы. Файл .dockerignore позволяет исключать ненужные файлы и папки из контекста, чтобы они вообще не передавались демону. Это ускоряет сборку, уменьшает размер образов и снижает риск попадания в образ секретов и временных артефактов.
При запуске команды вида docker build <context-path> -f Dockerfile Docker берёт указанный путь (чаще всего .), рекурсивно собирает все файлы внутри него, упаковывает их в архив и передаёт этот архив демону Docker — так формируется build context. После этого уже внутри демона выполняются инструкции из Dockerfile, и инструкции COPY/ADD могут работать только с тем, что есть в этом архиве; любые файлы вне контекста просто «невидимы» для сборки.
Важно, что Docker не подгружает файлы по мере надобности: он всегда сначала отправляет весь контекст целиком. Поэтому, если в корне проекта, который вы указали как контекст, лежат тяжёлые каталоги вроде node_modules, .git или различные артефакты сборки, они всё равно будут отправлены демону, даже если вы их не копируете в образ — это замедляет сборку и тратит лишний трафик/диск.
Файл .dockerignore, располагающийся в корне контекста, задаёт шаблоны файлов и каталогов, которые не нужно включать в build context. Синтаксис похож на .gitignore: вы перечисляете паттерны, и Docker просто не упаковывает совпадающие файлы в архив контекста.
.env), приватные ключи, директории .git, IDE-конфиги и т.п., чтобы они не оказались внутри образа.Нужно помнить, что всё, что исключено через .dockerignore, для сборки как бы не существует: вы не сможете потом сделать COPY или ADD этих файлов, потому что они вообще не попали в архив контекста. Хорошая практика — задавать контекст как можно более узким (например, подкаталог ./app) и агрессивно чистить его с помощью .dockerignore, оставляя только действительно нужные для сборки файлы.
В этом примере видно, что выбор пути контекста напрямую влияет на то, какие файлы вообще доступны Docker при сборке: если вы укажете в качестве контекста только ./app, то ни один файл из каталога уровнем выше не сможет быть скопирован в образ, даже если вы попытаетесь это сделать в Dockerfile.
Во втором примере .dockerignore отсекает тяжёлые и чувствительные файлы (такие как node_modules, .git, логи и .env) ещё до упаковки контекста, за счёт чего сборка становится быстрее, а в образ не попадают лишние данные и секреты, даже несмотря на то, что инструкция COPY . . формально копирует весь оставшийся контекст.
Отметьте свой прогресс