Я создал несколько разных каталогов на своем хост-компьютере, пытаясь узнать о Docker, чтобы мои файлы докеров были организованы. Мой Dockerfile, который я только что запустил, выглядит так:

FROM crystal/centos
MAINTAINER crystal

ADD ./rpms/test.rpm ./rpms/ 
RUN yum -y --nogpgcheck localinstall /rpms/test.rpm 

Моя фактическая частота вращения составляет всего 1 ГБ. Но когда я пытаюсь это сделать sudo docker build -t="crystal/test" ., я получаю отправку контекста сборки демону Docker 3,5 ГБ. Есть ли что-то еще, о чем я не знаю, пока вы продолжаете создавать образы Docker? Накапливается ли моя память по мере того, как я создаю больше изображений в других каталогах на моем хост-компьютере?

Клиент Docker отправляет весь «контекст сборки» демону Docker. Этот контекст сборки (по умолчанию) - это весь каталог, в котором Dockerfileнаходится (то есть все rpmsдерево).

Вы можете настроить .dockerignoreфайл, чтобы Docker игнорировал некоторые файлы. Вы можете поэкспериментировать с этим.

В качестве альтернативы вы можете переместить свою rpmsпапку на один уровень каталога выше вашего Dockerfile, и только символическую ссылку test.rpmв Dockerfileкаталог.

Как отмечали многие пользователи в комментариях, нужно добавить .gitпапку в папку,.dockerignore которая в моем случае была причиной разницы в 150 МБ -> 5 ГБ.

Обновление 2019

Начиная с Docker v18.06 есть возможность использовать новый конструктор образов под названием Build Kit .

Он предустановлен с Docker, ничего устанавливать не нужно. Он обратно совместим с Dockerfileсинтаксисом, нет необходимости изменять Dockerfile.

Устаревшая сборка Docker против нового набора Docker BuildKit

Вот пример создания образа с огромным неиспользуемым файлом в каталоге сборки:

Устаревшая сборка Docker:

$ time docker image build --no-cache .
Sending build context to Docker daemon  4.315GB
[...]
Successfully built c9ec5d33e12e

real    0m51.035s
user    0m7.189s
sys 0m10.712s

Новый Docker BuildKit:

$ time DOCKER_BUILDKIT=1 docker image build --no-cache .
[+] Building 0.1s (5/5) FINISHED                                                
 => [internal] load build definition from Dockerfile                       0.0s
 => => transferring dockerfile: 37B                                        0.0s
 => [internal] load .dockerignore                                          0.0s
 => => transferring context: 2B                                            0.0s
[...]
 => => writing image sha256:ba5bca3a525ac97573b2e1d3cb936ad50cf8129eedfa9  0.0s

real    0m0.166s
user    0m0.034s
sys 0m0.026s

Единственное изменение - DOCKER_BUILDKIT=1переменная окружения, разница во времени огромная.

.dockerignore файл

Обратите внимание, что .dockerignoreфайл по-прежнему действителен и полезен. Некоторые Dockerfileкоманды, например COPY . ., по-прежнему будут учитывать .dockerignoreправила. Но побочные файлы в каталоге сборки (не упомянутые в Dockerfile) больше не копируются BuildKit как «контекст сборки».

Я исправил это, переместив свой Dockerfile и docker-compose.yml во вложенную папку, и он отлично работал. Видимо докер отправляет текущую папку демону и у меня в папке было 9 гигов.

Если у вас есть .dockerignoreфайл и контекст сборки по-прежнему велик, вы можете проверить, что отправляется в контекст сборки докера, с помощью Silver Searcher :

ag --path-to-ignore .dockerignore --files-with-matches

Обратите внимание, что некоторые **шаблоны могут работать неправильно.

Дополнительные комментарии см. В этой проблеме Github: https://github.com/moby/moby/issues/16056

В моем случае это было, когда я выполняю с неправильными -fаргументами - без пути к каталогу, в котором находится Dockerfile

docker build --no-cache -t nginx5 -f /home/DF/Dockerfile /home/DF/ - право

docker build --no-cache -t nginx5 -f /home/DF/Dockerfile - неправильно

Если вы хотите полностью контролировать свой контекст сборки, вы также можете полностью построить контейнер без какого-либо контекста и COPYсоответствующих данных в контейнере впоследствии.

docker build - < Dockerfile

Одним из недостатков этого подхода является то, что при таком подходе вы можете только ADDвещи в файле докеров, ссылающиеся на удаленный URL-адрес, а не файлы с вашего локального хоста.

См. Https://docs.docker.com/engine/reference/commandline/build/#build-with--

У меня была та же проблема, что и с FreeStyler. Однако я строил из каталога, находящегося выше моего контекста. Значит, аргументы -f верны, контекст неверен.

project 
|
-------docker-dir 

Сборка из docker-dir была в порядке

docker build -t br_base:0.1 . 

Сборка из dock-dir контекст сборки изменился. Поэтому мне нужно было изменить контекст в команде. Контекст задается символом '.' в команде выше.

Новая команда из каталога проекта должна быть

docker build -t br_base:0.1 ./base

Контекст здесь задается './base'

если вы создаете изображение и получаете сообщение об отправке контекста сборки демону докера, для копирования которого требуется время журнала,

затем добавьте файл .dockerignore . он должен включать файлы или каталог, которые не нужно копировать.

Для NodeJS Applicationдобавления .dockerignoreфайла в корневой каталог проекта и внутри .dockerignoreфайла добавьте следующие

node_modules
dist