docker build
Создаёт образ из Dockerfile
Использование
$ docker build [OPTIONS] PATH | URL | -
Обратитесь к разделу параметров для обзора доступных OPTIONS для этой команды.
Описание
Команда docker build создаёт образы Docker из файла Dockerfile и «контекста». Контекст сборки — это множество файлов, расположенных в указанном PATH или URL. Процесс сборки может ссылаться на любой из файлов в контексте. Например, ваша сборка может использовать инструкцию COPY для ссылки на файл в контексте.
Параметр URL может относиться к трем видам ресурсов: репозиториям Git, предварительно упакованным tarball-контекстам и текстовым файлам.
Git-репозитории
Когда параметр URL указывает на расположение репозитория Git, репозиторий действует как контекст сборки. Система рекурсивно выбирает репозиторий и его подмодули. История коммитов не сохраняется. Репозиторий сначала загружается во временный каталог на вашем локальном хосте. После успешного завершения каталог отправляется демону Docker в качестве контекста. Локальная копия предоставляет вам возможность доступа к частным репозиториям с использованием учетных данных локального пользователя, VPN и т. д.
Примечание
Если параметр URL содержит фрагмент, система рекурсивно клонирует репозиторий и его подмодули с помощью команды git clone --recursive.
URL-адреса Git принимают конфигурацию контекста в разделе фрагментов, разделенном двоеточием ( : ). Первая часть представляет собой ссылку, которую Git извлечет, и может быть веткой, тегом или удаленной ссылкой. Вторая часть представляет собой подкаталог внутри репозитория, который будет использоваться в качестве контекста сборки.
Например, запускает эту команду, чтобы использовать каталог с именем docker в ветке container:
$ docker build https://github.com/docker/rootfs.git#container:docker
В следующей таблице представлены все допустимые суффиксы с их контекстами сборки:
Построить синтаксический суффикс |
Фиксация использована |
Используемый контекст сборки |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Примечание
Вы не можете указывает каталог контекста сборки ( myfolder в приведенных выше примерах) при использовании BuildKit в качестве компоновщика ( DOCKER_BUILDKIT=1 ). Поддержка этой функции отслеживается в сборка # 1684.
Тарбол контексты
Если вы передаете URL-адрес удаленному архиву, сам URL-адрес отправляется демону:
$ docker build http://server/context.tar.gz
Операция загрузки будет выполняться на хосте, на котором запущен демон Docker, который не обязательно является тем же хостом, с которого выдается команда сборки. Демон Docker получит context.tar.gz и будет использовать его в качестве контекста сборки. Контексты Tarball должны представлять собой архивы tar, соответствующие стандартному формату tar UNIX, и могут быть сжаты в любом из форматов «xz», «bzip2», «gzip» или «identity» (без сжатия).
Текстовые файлы
Вместо указания контекста вы можете передать один Dockerfile в URL или передать файл через STDIN . Для трубы Dockerfile от STDIN:
$ docker build - < Dockerfile
С Powershell в Windows вы можете выполнить:
Get-Content Dockerfile | docker build -
Если вы используете STDIN или указываете URL, указывающий на обычный текстовый файл, система помещает содержимое в файл с именем Dockerfile, а любой параметр -f, --file игнорируется. В этом сценарии нет контекста.
По умолчанию команда docker build будет искать Dockerfile в корне контекста сборки. Параметр -f , --file , позволяет указывает путь к альтернативному файлу, который будет использоваться вместо этого. Это полезно в тех случаях, когда один и тот же множество файлов используется для нескольких сборок. Путь должен быть к файлу в контексте сборки. Если указан относительный путь, он интерпретируется как относительный к корню контекста.
В большинстве случаев лучше поместить каждый Dockerfile в пустой каталог. Затем добавляет в данный каталог только файлы, необходимые для создания Dockerfile. Чтобы повысить производительность сборки, вы можете исключить файлы и каталоги, добавив в данный каталог файл .dockerignore. Сведения о его создании см. в статье .dockerignore файл.
Если клиент Docker теряет соединение с демоном, сборка отменяется. Это происходит, если вы прервете работу клиента Docker с помощью CTRL-c или если клиент Docker по какой-либо причине будет убит. Если сборка инициировала извлечение, которое все ещё выполнялось в момент отмены сборки, извлечение также отменяется.
Примеры использования этой команды см. в разделе примеров далее.
Параметры
Имя, сокращенно |
По умолчанию |
Описание |
|---|---|---|
|
Добавляет пользовательское сопоставление хоста и IP (хост: ip) |
|
|
Устанавливает переменные времени сборки |
|
|
Образы, которые следует рассматривать как источники кеша |
|
|
Необязательная родительская контрольная группа для контейнера |
|
|
Сожмите контекст сборки с помощью gzip |
|
|
Ограничьте период CPU CFS (Completely Fair Scheduler) |
|
|
Ограничьте квоту CPU CFS (Completely Fair Scheduler) |
|
|
Доли ЦП (относительный вес) |
|
|
ЦП, в которых разрешено выполнение (0-3, 0,1) |
|
|
MEM, в которых разрешено выполнение (0-3, 0,1) |
|
|
|
Пропустить проверку образа |
|
Имя Dockerfile (по умолчанию — «PATH/Dockerfile») |
|
|
Всегда удаляйте промежуточные контейнеры |
|
|
Записывает идентификатор образа в файл |
|
|
Технология изоляции контейнеров |
|
|
Устанавливает метаданные для образа |
|
|
Лимит памяти |
|
|
Предел подкачки равен объему памяти плюс подкачка: „-1“ для включения неограниченного подкачки |
|
|
Устанавливает сетевой режим для инструкций RUN во время сборки |
|
|
Не используйте кеш при построении образа |
|
|
API 1.40+ Назначение вывода (формат: тип=локальный,назначение=путь) |
|
|
API 1.40+ Устанавливает платформу, если сервер поддерживает несколько платформ |
|
|
|
Устанавливает тип вывода прогресса (авто, обычный, tty). Используйте обычный, чтобы показывает вывод контейнера |
|
Всегда пытайтесь получает более новую версию образа |
|
|
Подавить вывод сборки и распечатывает идентификатор образа в случае успеха |
|
|
|
Удаляет промежуточные контейнеры после успешной сборки |
|
Секретный файл для сборки (только если включён BuildKit): id=mysecret,src=/local/secret |
|
|
Параметры безопасности |
|
|
Размер/dev/shm |
|
|
экспериментальный (демон) Склеить вновь созданные слои в один новый слой |
|
|
Сокет или ключи агента SSH для предоставления сборке (только если включён BuildKit) (формат: по умолчанию|<id>[=<socket>|<key>[,<key>]]) |
|
|
Поток подключается к серверу для согласования контекста сборки |
|
|
Имя и, возможно, тег в формате «имя:тег» |
|
|
Устанавливает целевую стадию сборки для сборки. |
|
|
Улимит варианты |
Примеры
Построить с помощью PATH
$ docker build .
Uploading context 10240 bytes
Step 1/3 : FROM busybox
Pulling repository busybox
---> e9aa60c60128MB/2.284 MB (100%) endpoint: https://cdn-registry-1.docker.io/v1/
Step 2/3 : RUN ls -lh /
---> Running in 9c9e81692ae9
total 24
drwxr-xr-x 2 root root 4.0K Mar 12 2013 bin
drwxr-xr-x 5 root root 4.0K Oct 19 00:19 dev
drwxr-xr-x 2 root root 4.0K Oct 19 00:19 etc
drwxr-xr-x 2 root root 4.0K Nov 15 23:34 lib
lrwxrwxrwx 1 root root 3 Mar 12 2013 lib64 -> lib
dr-xr-xr-x 116 root root 0 Nov 15 23:34 proc
lrwxrwxrwx 1 root root 3 Mar 12 2013 sbin -> bin
dr-xr-xr-x 13 root root 0 Nov 15 23:34 sys
drwxr-xr-x 2 root root 4.0K Mar 12 2013 tmp
drwxr-xr-x 2 root root 4.0K Nov 15 23:34 usr
---> b35f4035db3f
Step 3/3 : CMD echo Hello world
---> Running in 02071fceb21b
---> f52f38b7823e
Successfully built f52f38b7823e
Removing intermediate container 9c9e81692ae9
Removing intermediate container 02071fceb21b
В этом примере указано, что PATH — это ., поэтому все файлы в локальном каталоге получают tar d и отправляются демону Docker. PATH указывает, где найти файлы для «контекста» сборки на демоне Docker. Помните, что демон может работать на удаленной машине и что анализ Dockerfile не происходит на стороне клиента (где вы используете docker build). Это означает, что будут отправлены все файлы по адресу PATH, а не только те, которые указаны в *ДОБАВЛЯТЬ* в Dockerfile.
Передача контекста с локального компьютера демону Docker — это то, что имеет в виду клиент docker, когда вы видите сообщение «Отправка контекста сборки».
Если вы хотите сохраняет промежуточные контейнеры после завершения сборки, вы должны использовать --rm=false. Это не влияет на кеш сборки.
Построить с URL
$ docker build github.com/creack/docker-firefox
Это клонирует репозиторий GitHub и использует клонированный репозиторий в качестве контекста. Dockerfile в корне репозитория используется как Dockerfile. Вы можете указывает произвольный репозиторий Git, используя схему git:// или git@.
$ docker build -f ctx/Dockerfile http://server/ctx.tar.gz
Downloading context: http://server/ctx.tar.gz [===================>] 240 B/240 B
Step 1/3 : FROM busybox
---> 8c2e06607696
Step 2/3 : ADD ctx/container.cfg /
---> e7829950cee3
Removing intermediate container b35224abf821
Step 3/3 : CMD /bin/ls
---> Running in fbc63d321d73
---> 3286931702ad
Removing intermediate container fbc63d321d73
Successfully built 377c409b35e4
Это отправляет URL-адрес http://server/ctx.tar.gz демону Docker, который загружает и извлекает указанный tar-архив. Параметр -f ctx/Dockerfile указывает путь внутри ctx.tar.gz к Dockerfile, который используется для построения образа. Любые команды ADD в этом Dockerfile, которые ссылаются на локальные пути, должны относиться к корню содержимого внутри ctx.tar.gz. В приведённом выше примере архив содержит каталог ctx/ , поэтому операция ADD ctx/container.cfg / работает должным образом.
Построить с -
$ docker build - < Dockerfile
Это будет читать Dockerfile из STDIN без контекста. Из-за отсутствия контекста никакое содержимое любого локального каталога не будет отправлено демону Docker. Поскольку контекста нет, Dockerfile ADD работает только в том случае, если он ссылается на удаленный URL-адрес.
$ docker build - < context.tar.gz
Это создаст образ для сжатого контекста, считанного из STDIN. Поддерживаемые форматы: bzip2, gzip и xz.
Используйте файл .dockerignore
$ docker build .
Uploading context 18.829 MB
Uploading context
Step 1/2 : FROM busybox
---> 769b9341d937
Step 2/2 : CMD echo Hello world
---> Using cache
---> 99cc1ad10469
Successfully built 99cc1ad10469
$ echo ".git" > .dockerignore
$ docker build .
Uploading context 6.76 MB
Uploading context
Step 1/2 : FROM busybox
---> 769b9341d937
Step 2/2 : CMD echo Hello world
---> Using cache
---> 99cc1ad10469
Successfully built 99cc1ad10469
В этом примере показано использование файла .dockerignore для исключения каталога .git из контекста. Его эффект можно увидеть в измененном размере загружаемого контекста. Справочник по сборщику содержит подробную информацию о создание файла .dockerignore .
При использовании Серверная часть BuildKit docker build ищет файл .dockerignore относительно имени Dockerfile. Например, запуск docker build -f myapp.Dockerfile . сначала будет искать игнорируемый файл с именем myapp.Dockerfile.dockerignore. Если такой файл не найден, используется файл .dockerignore, если он есть. Использование файла Docker на основе .dockerignore полезно, если проект содержит несколько файлов Dockerfile, которые предполагают игнорировать разные множества файлов.
Пометить образ (-t)
$ docker build -t vieux/apache:2.0 .
Это будет построено так же, как и в предыдущем примере, но затем оно пометит результирующее образ. Имя репозитория будет vieux/apache, а тег — 2.0. Подробнее о допустимых тегах .
К образу можно применить несколько тегов. Например, вы можете применить тег latest к вновь созданному образу и добавить ещё один тег, который ссылается на конкретную версию. Например, чтобы пометить образ как whenry/fedora- jboss:latest, так и whenry/fedora-jboss:v2.1, используйте следующее:
$ docker build -t whenry/fedora-jboss:latest -t whenry/fedora-jboss:v2.1 .
Указывает Dockerfile (-f)
$ docker build -f Dockerfile.debug .
Это будет использовать файл с именем Dockerfile.debug для инструкций по сборке вместо Dockerfile.
$ curl example.com/remote/Dockerfile | docker build -f - .
Приведённая выше команда будет использовать текущий каталог в качестве контекста сборки и читать Dockerfile из стандартного ввода.
$ docker build -f dockerfiles/Dockerfile.debug -t myapp_debug .
$ docker build -f dockerfiles/Dockerfile.prod -t myapp_prod .
Вышеупомянутые команды создадут текущий контекст сборки (как указано в . ) дважды, один раз с использованием отладочной версии Dockerfile и один раз с использованием рабочей версии.
$ cd /home/me/myapp/some/dir/really/deep
$ docker build -f /home/me/myapp/dockerfiles/debug /home/me/myapp
$ docker build -f ../../../../dockerfiles/debug /home/me/myapp
Данные две команды docker build делают одно и то же. Оба они используют содержимое файла debug вместо поиска Dockerfile и будут использовать /home/me/myapp в качестве корня контекста сборки. Обратите внимание, что debug находится в структуре каталогов контекста сборки, независимо от того, как вы ссылаетесь на него в командной строке.
Примечание
docker build возвращает ошибку no such file or directory, если файл или каталог не существует в загруженном контексте. Это может произойти, если нет контекста или если вы укажете файл, который находится в другом месте хост-системы. Контекст ограничен текущим каталогом (и его дочерними элементами) по соображениям безопасности и для обеспечения повторяемости сборок на удаленных узлах Docker. Это также является причиной того, что ADD ../file не работает.
Используйте пользовательскую родительскую контрольную группу (–cgroup-parent)
Когда docker build запускается с параметром --cgroup-parent, контейнеры, используемые в сборке, будут запускаться с соответствующим флагом docker запускает.
Устанавливает ulimits в контейнере (–ulimit)
Использование параметра --ulimit с docker build приведёт к запуску контейнера каждого шага сборки с использованием данных значений флага –ulimit.
Устанавливает переменные времени сборки (–build-arg)
Вы можете использовать инструкции ENV в Dockerfile для определения значений переменных. Данные значения сохраняются в построенном образе. Однако часто настойчивость — это не то, что вам нужно. Пользователи хотят указывать переменные по-разному в зависимости от того, на каком хосте они создают образ.
Хороший пример — http_proxy или исходные версии для извлечения промежуточных файлов. Оператор ARG позволяет авторам Dockerfile определять значения, которые пользователи могут устанавливать во время сборки, используя флаг --build-arg:
$ docker build --build-arg HTTP_PROXY=http://10.20.30.2:1234 --build-arg FTP_PROXY=http://40.50.60.5:4567 .
Данный флаг позволяет передавать переменные времени сборки, к которым обращаются как к обычным переменным среды, в инструкции RUN файла Dockerfile. Кроме того, данные значения не сохраняются в промежуточных или конечных образах, как это делают значения ENV. Вы должны добавить --build-arg для каждого аргумента сборки.
Использование этого флага не изменит вывод, который вы видите, когда строки ARG из Dockerfile отображаются в процессе сборки.
Подробную информацию об использовании инструкций ARG и ENV см. в Справочник по Dockerfile.
Вы также можете использовать флаг --build-arg без значения, и в этом случае значение из локальной среды будет распространено в создаваемый контейнер Docker:
$ export HTTP_PROXY=http://10.20.30.2:1234
$ docker build --build-arg HTTP_PROXY .
Это похоже на то, как работает docker run -e. Дополнительные сведения см. в документации docker запускает.
Дополнительные параметры безопасности (–security-opt)
Данный флаг поддерживается только демоном, работающим в Windows, и поддерживает только параметр credentialspec. credentialspec должен быть в формате file://spec.txt или registry://keyname .
Указывает технологию изоляции для контейнера (–isolation)
Данный параметр полезен в ситуациях, когда вы запускаете контейнеры Docker в Windows. Параметр --isolation=<value> устанавливает технологию изоляции контейнера. В Linux поддерживается только параметр default, который использует пространства имён Linux. В Microsoft Windows вы можете указывает данные значения:
Значение |
Описание |
|---|---|
|
Используйте значение, указанное |
|
Только изоляция пространства имён. |
|
Hyper-V изоляция на основе разделов гипервизора. |
Указание флага --isolation без значения аналогично установке --isolation="default".
Добавляет записи в файл hosts контейнера (–add-host)
Вы можете добавить другие узлы в файл контейнера /etc/hosts, используя один или несколько флагов --add-host. В этом примере добавляется статический адрес для узла с именем docker:
$ docker build --add-host=docker:10.180.0.1 .
Указание целевого этапа сборки (–target)
При создании Dockerfile с несколькими этапами сборки можно использовать --target, чтобы указывает промежуточный этап сборки по имени в качестве конечного этапа для результирующего образа. Команды после целевого этапа будут пропущены.
FROM debian AS build-env
# ...
FROM alpine AS production-env
# ...
$ docker build -t mybuildimage --target build-env .
Пользовательские выходные данные сборки
По умолчанию локальный образ контейнера создаётся из результата сборки. Флаг --output (или -o ) позволяет переопределить это поведение и указывает пользовательский экспортёр. Например, пользовательские экспортеры позволяют экспортировать артефакты сборки в виде файлов в локальную файловую систему вместо образа Docker, что может быть полезно для создания локальных двоичных файлов, генерации кода и т. д.
Значение для --output — это строка в формате CSV, определяющая тип и параметры экспортера. В настоящее время поддерживаются экспортеры local и tar. Средство экспорта local записывает полученные файлы сборки в каталог на стороне клиента. Экспортёр tar похож, но записывает файлы как один tarball ( .tar ).
Если тип не указан, по умолчанию используется выходной каталог локального экспортера. Используйте дефис ( - ), чтобы записывает выходной архив в стандартный вывод ( STDOUT ).
В следующем примере создаётся образ с использованием текущего каталога ( . ) в качестве контекста сборки и экспортируются файлы в каталог с именем out в текущем каталоге. Если каталог не существует, Docker автоматически создаёт каталог:
$ docker build -o out .
В приведённом выше примере используется сокращенный синтаксис, без параметров type, и поэтому используется экспортёр по умолчанию ( local ). В приведённом далее примере показан аналогичный опция с использованием длинного синтаксиса CSV с указанием type и dest (путь назначения):
$ docker build --output type=local,dest=out .
Используйте тип tar, чтобы экспортировать файлы в виде архива .tar:
$ docker build --output type=tar,dest=out.tar .
Пример далее показывает эквивалент при использовании сокращенного синтаксиса. В этом случае в качестве места назначения указывается -, который автоматически выбирает тип tar и записывает выходной tar-архив в стандартный вывод, который затем перенаправляется в файл out.tar:
$ docker build -o - . > out.tar
Опция --output экспортирует все файлы из целевой сцены. Распространенным шаблоном для экспорта только определённых файлов является выполнение многоэтапных сборок и копирование нужных файлов на новую рабочую стадию с помощью КОПИРОВАТЬ –из .
В приведённом далее примере Dockerfile используется отдельный этап для сбора артефактов сборки для экспорта:
FROM golang AS build-stage
RUN go get -u github.com/LK4D4/vndr
FROM scratch AS export-stage
COPY --from=build-stage /go/bin/vndr /
При сборке Dockerfile с параметром -o в каталог out экспортируются только файлы из финальной стадии, в данном случае бинарный файл vndr:
$ docker build -o out .
[+] Building 2.3s (7/7) FINISHED
=> [internal] load build definition from Dockerfile 0.1s
=> => transferring dockerfile: 176B 0.0s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 2B 0.0s
=> [internal] load metadata for docker.io/library/golang:latest 1.6s
=> [build-stage 1/2] FROM docker.io/library/golang@sha256:2df96417dca0561bf1027742dcc5b446a18957cd28eba6aa79269f23f1846d3f 0.0s
=> => resolve docker.io/library/golang@sha256:2df96417dca0561bf1027742dcc5b446a18957cd28eba6aa79269f23f1846d3f 0.0s
=> CACHED [build-stage 2/2] RUN go get -u github.com/LK4D4/vndr 0.0s
=> [export-stage 1/1] COPY --from=build-stage /go/bin/vndr / 0.2s
=> exporting to client 0.4s
=> => copying files 10.30MB 0.3s
$ ls ./out
vndr
Примечание
Для этой функции требуется серверная часть BuildKit. Вы можете либо использовать включить билдкит, либо использовать плагин buildx, который предоставляет больше вариантов типа вывода.
Указание внешних источников кэша
В дополнение к локальному кешу сборки сборщик может повторно использовать кеш, сгенерированный из предыдущих сборок с флагом --cache-from, указывающим на образ в реестре.
Чтобы использовать образ в качестве источника кэша, метаданные кэша необходимо записывает в образ при создании. Это можно сделать, установив --build-arg BUILDKIT_INLINE_CACHE=1 при построении образа. После этого построенный образ можно использовать как источник кеша для последующих сборок.
После импорта кеша сборщик будет извлекать из реестра только метаданные JSON и определять возможные попадания в кеш на основе этой информации. При попадании в кеш совпадающие слои переносятся в локальную среду.
Помимо образов, кеш также можно извлечь из специальных манифестов кеша, сгенерированных buildx или интерфейсом командной строки BuildKit (buildctl). Данные манифесты (при построении с параметрами type=registry и mode=max) позволяют извлекать данные слоя для промежуточных этапов в многоэтапных сборках.
В следующем примере создаётся образ с метаданными встроенного кэша, который передаётся в реестр, а затем используется в качестве источника кэша на другом компьютере:
$ docker build -t myname/myapp --build-arg BUILDKIT_INLINE_CACHE=1 .
$ docker push myname/myapp
После отправки образа оно используется в качестве источника кеша на другом компьютере. BuildKit автоматически извлекает образ из реестра, если это необходимо.
На другой машине:
$ docker build --cache-from myname/myapp .
Примечание
Для этой функции требуется серверная часть BuildKit. Вы можете либо включить билдкит, либо использовать плагин buildx. Предыдущий билдер имеет ограниченную поддержку повторного использования кеша из предварительно загруженных образов.
Сжатие слоев образа (–squash) (экспериментальная функция)
Обзор
Как только образ будет создано, объединяет новые слои в новое образ с одним новым слоем. Сжатие не уничтожает существующее образ, а создаёт новое образ с содержимым сжатых слоев. Это эффективно создаёт впечатление, что все команды Dockerfile были созданы с одним слоем. Кэш сборки сохраняется с помощью этого метода.
Параметр --squash является экспериментальной функцией и не должен считаться стабильным.
Сжатие слоев может быть полезным, если ваш Dockerfile создаёт несколько слоев, изменяющих одни и те же файлы, например, файлы, которые создаются на одном этапе и удаляются на другом этапе. В других случаях сжатие образов может негативно сказаться на производительности; при вытягивании образы, состоящего из нескольких слоев, слои могут вытягиваться параллельно и позволяет обмениваться слоями между образами (экономия места).
В большинстве случаев многоэтапные сборки являются лучшей альтернативой, поскольку они обеспечивают более детальный контроль над вашей сборкой и могут использовать преимущества будущих оптимизаций в сборщике. Дополнительные сведения см. в разделе использовать многоэтапные сборки руководства пользователя.
Известные ограничения
Параметр --squash имеет ряд известных ограничений:
При сжатии слоев результирующее образ не может использовать преимущества совместного использования слоев с другими образами и может занимать значительно больше места. Совместное использование базового образа по-прежнему поддерживается.
При использовании этого параметра вы можете увидеть значительно больше места, используемого из-за хранения двух копий образа, одной для кэша сборки со всеми неповрежденными слоями кэша и одной для сжатой версии.
Хотя сжатие слоев может создавать образы меньшего размера, это может отрицательно сказаться на производительности, поскольку извлечение одного слоя занимает больше времени, а загрузка одного слоя не может быть распараллелена.
При попытке сжимает образ, который не вносит изменений в файловую систему (например, файл Dockerfile содержит только инструкции
ENV), шаг сквош завершится ошибкой (см. релиз №33823).
Предпосылки
В примере на этой странице используется экспериментальный режим в Docker 19.03.
Экспериментальный режим можно включить, используя флаг --experimental при запуске демона Docker или установив experimental: true в файле конфигурации daemon.json.
По умолчанию экспериментальный режим отключён. Чтобы увидеть текущую конфигурацию демона docker, используйте команду docker version и проверяет строку Experimental в разделе Engine:
Client: Docker Engine - Community
Version: 19.03.8
API version: 1.40
Go version: go1.12.17
Git commit: afacb8b
Built: Wed Mar 11 01:21:11 2020
OS/Arch: darwin/amd64
Experimental: false
Server: Docker Engine - Community
Engine:
Version: 19.03.8
API version: 1.40 (minimum version 1.12)
Go version: go1.12.17
Git commit: afacb8b
Built: Wed Mar 11 01:29:16 2020
OS/Arch: linux/amd64
Experimental: true
[...]
Чтобы включить экспериментальный режим, пользователям необходимо перезапустить демон Docker с включенным экспериментальным флагом.
Включить экспериментальный Docker
Чтобы включить экспериментальные функции, вам нужно запускает демон Docker с флагом --experimental. Вы также можете включить флаг демона, например, через /etc/docker/daemon.json :
{
"experimental": true
}
Затем убедиться, что экспериментальный флаг включён:
$ docker version -f '{{.Server.Experimental}}'
true
Создаёт образ с
Далее приведён пример сборки Docker с аргументом --squash
FROM busybox
RUN echo hello > /hello
RUN echo world >> /hello
RUN touch remove_me /remove_me
ENV HELLO=world
RUN rm /remove_me
Образ с именем test создаётся с аргументом --squash.
$ docker build --squash -t test .
<...>
Если все верно, то история выглядит так:
$ docker history test
IMAGE CREATED CREATED BY SIZE COMMENT
4e10cb5b4cac 3 seconds ago 12 B merge sha256:88a7b0112a41826885df0e7072698006ee8f621c6ab99fca7fe9151d7b599702 to sha256:47bcc53f74dc94b1920f0b34f6036096526296767650f223433fe65c35f149eb
<missing> 5 minutes ago /bin/sh -c rm /remove_me 0 B
<missing> 5 minutes ago /bin/sh -c #(nop) ENV HELLO=world 0 B
<missing> 5 minutes ago /bin/sh -c touch remove_me /remove_me 0 B
<missing> 5 minutes ago /bin/sh -c echo world >> /hello 0 B
<missing> 6 minutes ago /bin/sh -c echo hello > /hello 0 B
<missing> 7 weeks ago /bin/sh -c #(nop) CMD ["sh"] 0 B
<missing> 7 weeks ago /bin/sh -c #(nop) ADD file:47ca6e777c36a4cfff 1.113 MB
Мы можем обнаружить, что имя слоя — <missing>, и есть новый слой с COMMENT merge.
Протестируйте образ, убедиться, что /remove_me отсутствует, убедиться, что hello\nworld находится в /hello , убедиться, что значение переменной среды HELLO равно world .