Несколько Docker-файлов в проекте с разными контекстами

Question

У меня есть репозиторий, в котором мне нужно создать несколько файлов Docker, но каждый из них должен иметь свой контекст.

Мне нравится опубликованное решение здесь , но оно не полностью соответствует моему варианту использования.

НЕТ, ЭТО НЕ ДУБЛИКАТ. Это другой случай использования. ПОЖАЛУЙСТА, ПРОЧИТАЙТЕ ЧТЕНИЕ .

Я знаю, что лучше исключить из контекста ненужные папки , особенно если они большие. Ну, мой проект состоит из нескольких папок, некоторые из которых действительно огромны .

Для простоты предположим, что это дерево файлов моего проекта:

• hugeFolder1/
• hugeFolder2/
• littleFolder1/
• littleFolder2/

И предположим, что мне нужно создать два файла Docker (следуя решению , которое я ранее упомянул ):

• docker/A/Dockerfile <- назовем этот Dockerfile "<strong> A "
• docker/B/Dockerfile <- назовем этот Dockerfile "<strong> B "
• docker-compose.yml

Теперь дело в том:

• A требуется только hugeFolder1 и обе маленькие папки.
• B требуется только hugeFolder2 и обе маленькие папки.

Так что я бы хотел исключить ненужные огромные папки соответственно.

Каков наилучший способ добиться этого?

Answer 1

Редактировать: в предыдущем ответе к изображению добавлялись папки, находящиеся вне контекста сборки, что не будет работать. Кроме того, OP разъяснил содержание и то, как изображение будет использоваться в комментариях, показывая очень хороший вариант использования для многоэтапных сборок.

Я сделаю удар, основываясь на предоставленной информации.

Во-первых, вы не можете исключить папки из заданного контекста докера. Если вы используете docker build -t bluescores/myimage /some/path, ваш контекст будет /some/path/**/*. Там нет исключая огромные папки, или маленькие папки, или что-нибудь в них.

Во-вторых, чтобы использовать ADD или COPY для переноса файлов в образ докера, они должны существовать в контексте сборки.

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

Пропустить docker-compose сейчас

Решение здесь , на которое вы ссылаетесь, на самом деле не направлено на решение проблемы тесного контроля контекста. Это хороший ответ на совершенно другой вопрос, чем тот, который вы задаете. Вы просто пытаетесь создать образы прямо сейчас, и хотя docker-compose может с этим справиться, это ничего не принесет в таблицу, которой у вас нет с docker build. Когда вам нужно организовать эти контейнеры, которые вы создаете, тогда docker-compose будет невероятно.

Если вы не уверены, что вам нужен docker-compose, попробуйте сделать это без него. Вы всегда можете вернуть его в смесь позже.

Теперь мое изображение гигантское

Посмотрите, можете ли вы использовать многоэтапные сборки .

Это, по сути, позволит вам выбрать выходные данные сборки из изображения, в которое вы COPY поместили огромные папки, и поместить этот вывод в новое, более чистое изображение меньшего размера.