Текст и данные · Инструкция
Docker build: named contexts и дополнительные источники
Named contexts подходят, когда Dockerfile должен читать файлы из нескольких источников, но вы не хотите копировать всё в один каталог или временно перестраивать дерево проекта.
Короткий ответ
Передайте дополнительные контексты через --build-context name=source, а в Dockerfile обращайтесь к имени как к отдельному источнику, например через COPY.
Что важно понять до начала
BuildKit позволяет передавать именованные дополнительные контексты вместе с основным. Источник может быть локальным путём или поддерживаемым удалённым контекстом. Имя контекста затем используется Dockerfile как отдельный источник. Содержимое контекста всё равно должно соответствовать модели безопасности и правилам сборки BuildKit.
Совет: Практический ориентир: Обычный контекст — главный источник сборки. Named context добавляется отдельно под именем и используется только там, где Dockerfile на него ссылается.
Пошаговый порядок действий
- 1. Оставьте основным контекстом только каталог, который действительно нужен большинству инструкций.
- 2. Добавьте `--build-context docs=./docs` или другой именованный источник.
- 3. В Dockerfile используйте именованный источник только в тех инструкциях, где нужны его файлы.
- 4. Соберите образ с `--progress=plain`, чтобы видеть, какой контекст передаётся и используется.
- 5. Проверьте итоговый образ: временные исходники не должны попадать в слои без необходимости.
Важно: Критично для этой задачи: Named context не отменяет контроль секретов.
Ошибки и пограничные случаи
Named context не отменяет контроль секретов. Не передавайте каталог с ключами «на всякий случай»: любой доступный build context следует считать входом сборки. Для больших монорепозиториев этот подход часто уменьшает случайную связанность Dockerfile с корнем репозитория и делает кеширование понятнее.
Предупреждение: Пограничный случай: Может уменьшить объём ненужных входных данных и улучшить структуру кеша, но ускорение зависит от проекта и фактически используемых файлов.
Проверка перед завершением
- Оставьте основным контекстом только каталог, который действительно нужен большинству инструкций.
- В Dockerfile используйте именованный источник только в тех инструкциях, где нужны его файлы.
- Проверьте итоговый образ: временные исходники не должны попадать в слои без необходимости.
- Проверено отдельно: Обычный контекст — главный источник сборки. Named context добавляется отдельно под именем и используется только там, где Dockerfile на него ссылается.
Практический сценарий и контроль результата
Named context полезен, когда дополнительный исходник нужен лишь на отдельных шагах сборки: документация, артефакты соседнего проекта или отдельный Git‑источник. Держите основной context минимальным и обращайтесь к именованному источнику только там, где он действительно нужен. Это не гарантирует ускорение само по себе: выигрыш зависит от размера контекстов и cache reuse. После сборки проверьте history и содержимое финального образа, чтобы временные файлы из дополнительного контекста не оказались в runtime‑слое.
Дополнительные нюансы и проверка
Не путайте named context с обычным COPY из родительского каталога: BuildKit получает дополнительный источник явно, и Dockerfile обращается к нему по имени. Это удобнее временного копирования файлов в основной context и помогает контролировать границы сборки. Но секреты и приватные данные всё равно нельзя бездумно помещать в контекст. После сборки проверьте, что дополнительный источник использовался только на нужном этапе и не оказался в финальном runtime‑образе.
Что учитывать
BuildKit позволяет передавать именованные дополнительные контексты вместе с основным. Источник может быть локальным путём или поддерживаемым удалённым контекстом. Имя контекста затем используется Dockerfile как отдельный источник. Содержимое контекста всё равно должно соответствовать модели безопасности и правилам сборки BuildKit.
Источники и проверка
Фактическая часть сверена по первичным источникам (в т.ч. Build context). Пример и формулировки — редакция N1RO на 2026-09-22.