不可能使用VOLUME指令告诉docker要挂载什么。这将严重破坏可移植性。这条指令告诉docker，这些目录中的内容不会放在图像中，并且可以使用——volumes-from命令行参数从其他容器中访问。必须使用-v /path/on/host:/path/in/container命令运行容器才能访问主机上的目录。

无法在构建期间挂载主机卷。没有特权构建，安装主机也会严重降低可移植性。您可能想尝试使用wget或curl下载构建所需的任何内容，并将其放置到合适的位置。

在运行容器时，将在主机上创建一个目录并将其挂载到容器中。你可以找到它所在的目录

$ docker inspect --format "{{ .Volumes }}" <ID>
map[/export:/var/lib/docker/vfs/dir/<VOLUME ID...>]

如果要在容器中挂载来自主机的目录，则必须使用-v参数并指定目录。在你的情况下，这将是:

docker run -v /export:/export data

你可以在容器中使用hosts文件夹。

我认为你可以通过docker命令来运行构建，这个命令本身是在docker容器中运行的。看到Docker现在可以运行在Docker | Docker博客。像这样的技术，但实际上是从容器访问外部docker，被使用，例如，当探索如何创建最小的docker容器| Xebia Blog。

另一篇相关文章是优化Docker图像| CenturyLink Labs，它解释了如果你在构建过程中下载了一些东西，你可以通过在一个RUN步骤中下载、构建和删除下载来避免在最终映像中浪费空间。

有一种方法可以在构建期间挂载卷，但它不涉及Dockerfiles。

该技术将从您想使用的任何基础上创建一个容器(使用-v选项将您的卷安装到容器中)，运行shell脚本来进行映像构建工作，然后在完成后将容器作为映像提交。

这不仅省去了您不想要的多余文件(这也适用于安全文件，如SSH文件)，而且还创建了单个映像。它也有缺点:commit命令不支持所有的Dockerfile指令，如果你需要编辑构建脚本，它不允许你在你离开的时候重新开始。

更新:

例如,

CONTAINER_ID=$(docker run -dit ubuntu:16.04)
docker cp build.sh $CONTAINER_ID:/build.sh
docker exec -t $CONTAINER_ID /bin/sh -c '/bin/sh /build.sh'
docker commit $CONTAINER_ID $REPO:$TAG
docker stop $CONTAINER_ID

更新:有人就是不会把“不”作为答案，我很喜欢，尤其是这个特别的问题。

好消息，现在有办法了

解决方案是Rocker: https://github.com/grammarly/rocker

约翰·亚尼说， “在我看来，它解决了Dockerfile的所有弱点，使其适合开发。”

摇滚歌手

https://github.com/grammarly/rocker

By introducing new commands, Rocker aims to solve the following use cases, which are painful with plain Docker: Mount reusable volumes on build stage, so dependency management tools may use cache between builds. Share ssh keys with build (for pulling private repos, etc.), while not leaving them in the resulting image. Build and run application in different images, be able to easily pass an artifact from one image to another, ideally have this logic in a single Dockerfile. Tag/Push images right from Dockerfiles. Pass variables from shell build command so they can be substituted to a Dockerfile. And more. These are the most critical issues that were blocking our adoption of Docker at Grammarly.

更新:根据Github上的官方项目回购，Rocker已经停产

截至2018年初，容器生态系统比三年前这个项目启动时要成熟得多。现在，虽然有些特性仍然是rocker独有的，但docker构建或其他支持良好的工具可以很容易地覆盖rocker的一些关键和突出的特性。详情见https://github.com/grammarly/rocker/issues/199。

它很丑，但我做到了这样的外观:

Dockerfile：

FROM foo
COPY ./m2/ /root/.m2
RUN stuff

imageBuild.sh:

docker build . -t barImage
container="$(docker run -d barImage)"
rm -rf ./m2
docker cp "$container:/root/.m2" ./m2
docker rm -f "$container"

我有一个java构建，下载宇宙到/root/。M2，每次都是这样。sh在构建后将该文件夹的内容复制到主机上，Dockerfile将它们复制回映像中以进行下一次构建。

这类似于卷的工作方式(即它在构建之间持续存在)。

首先，要回答“为什么VOLUME不起作用?”在Dockerfile中定义VOLUME时，只能定义目标，不能定义卷的源。在构建过程中，您只能从中获得一个匿名卷。该匿名卷将在每个RUN命令时挂载，用映像的内容预填充，然后在RUN命令结束时丢弃。只保存对容器的更改，不保存对卷的更改。

既然已经提出了这个问题，一些功能已经发布，可能会有所帮助。首先是多阶段构建，允许您构建磁盘空间效率低下的第一个阶段，并将所需的输出复制到交付的最后一个阶段。第二个特性是Buildkit，它极大地改变了图像构建的方式，并将新的功能添加到构建中。

对于多阶段构建，您将有多个FROM行，每一行开始创建一个单独的映像。默认情况下，只有最后一个图像被标记，但您可以从以前的阶段复制文件。标准的使用方法是使用编译器环境来构建二进制文件或其他应用程序工件，并使用运行时环境作为复制工件的第二个阶段。你可以有:

FROM debian:sid as builder
COPY export /export
RUN compile command here >/result.bin

FROM debian:sid
COPY --from=builder /result.bin /result.bin
CMD ["/result.bin"]

这将导致构建只包含生成的二进制文件，而不包含完整的/export目录。

Buildkit将在18.09推出实验版。它完全重新设计了构建过程，包括更改前端解析器的能力。解析器的变化之一是实现了RUN——mount选项，该选项允许您为运行命令挂载缓存目录。例如，这里有一个挂载一些debian目录(重新配置debian镜像，这可以加快包的重新安装):

# syntax = docker/dockerfile:experimental
FROM debian:latest
RUN --mount=target=/var/lib/apt/lists,type=cache \
    --mount=target=/var/cache/apt,type=cache \
    apt-get update \
 && DEBIAN_FRONTEND=noninteractive apt-get install -y --no-install-recommends \
      git

你可以为你拥有的任何应用程序缓存调整缓存目录，例如$HOME/。M2代表maven，或/root/。缓存golang。

答案在这里:使用RUN——mount语法，您还可以从构建上下文绑定挂载只读目录。该文件夹必须存在于构建上下文中，并且没有映射回主机或构建客户端:

# syntax = docker/dockerfile:experimental
FROM debian:latest
RUN --mount=target=/export,type=bind,source=export \
    process export directory here...

注意，因为目录是从上下文挂载的，所以它也是只读挂载的，您不能将更改推回主机或客户端。构建时，您需要18.09或更新版本的安装，并使用export DOCKER_BUILDKIT=1启用buildkit。

如果您得到不支持挂载标志的错误，这表明您没有使用上述变量启用buildkit，或者您没有在Dockerfile顶部的语法行(包括注释)之前启用实验性语法。请注意，只有当docker安装有内置的buildkit支持时，切换buildkit的变量才有效，这需要docker的18.09或更新版本，无论是在客户端还是服务器端。

下面是使用构建和提交的两步方法的简化版本，没有shell脚本。它包括:

部分地构建图像，没有卷 运行一个包含卷的容器，进行更改，然后提交结果，替换原来的映像名称。

对于相对较小的更改，额外的步骤只增加了几秒钟的构建时间。

基本上:

docker build -t image-name . # your normal docker build

# Now run a command in a throwaway container that uses volumes and makes changes:
docker run -v /some:/volume --name temp-container image-name /some/post-configure/command

# Replace the original image with the result:
# (reverting CMD to whatever it was, otherwise it will be set to /some/post-configure/command)   
docker commit --change="CMD bash" temp-container image-name 

# Delete the temporary container:
docker rm temp-container

在我的用例中，我想预先生成一个maven toolchains.xml文件，但是我的许多JDK安装都在运行时才可用的卷上。我的一些映像并不与所有JDKS兼容，因此我需要在构建时测试兼容性，并有条件地填充toolchains.xml。注意，我不需要图像是可移植的，我没有将它发布到Docker Hub。

正如许多人已经回答的那样，在构建期间挂载主机卷是不可能的。我只是想添加docker-compose方式，我认为它会很好，主要用于开发/测试用途

Dockerfile

FROM node:10
WORKDIR /app
COPY . .
RUN npm ci
CMD sleep 999999999

docker-compose.yml

version: '3'
services:
  test-service:
    image: test/image
    build:
      context: .
      dockerfile: Dockerfile
    container_name: test
    volumes:
      - ./export:/app/export
      - ./build:/app/build

然后通过docker-compose up -d——build运行容器

如果你正在寻找一种“挂载”文件的方法，比如-v用于docker run，你现在可以使用——secret标志用于docker build

echo 'WARMACHINEROX' > mysecret.txt
docker build --secret id=mysecret,src=mysecret.txt .

在Dockerfile中，你可以访问这个秘密

# syntax = docker/dockerfile:1.0-experimental
FROM alpine

# shows secret from default secret location:
RUN --mount=type=secret,id=mysecret cat /run/secrets/mysecret

# shows secret from custom secret location:
RUN --mount=type=secret,id=mysecret,dst=/foobar cat /foobar

更多关于——secret的深入信息可以在Docker Docs上找到

Git克隆从一个私人回购在docker使用我的私人SSH密钥

在使用BuildKit创建Linux映像时，docker build还使用——SSH标志提供SSH代理转发。Docker在build中使用SSH访问私有数据，Dockerfile可以在RUN命令中使用——mount=type= SSH，将SSH身份验证委托给主机的SSH代理:

# syntax=docker/dockerfile:1
FROM alpine
RUN apk add --no-cache openssh-client git

# Download public key of remote server at github.com 
RUN mkdir -p -m 0700 ~/.ssh && ssh-keyscan github.com >> ~/.ssh/known_hosts

# Enable verbose output (optional)
ENV GIT_SSH_COMMAND='ssh -Tvv'

# Clone using private keys known to SSH agent on the host
RUN --mount=type=ssh git clone git@github.com:myorg/myproject.git myproject

在构建时，上面的程序基本上可以通过简单地运行来使用主机的SSH密钥:

docker build --ssh default .

在主机上，这需要使用ssh-add进行一些配置，如上面链接的文档中所述;如果一切正常，那么echo $SSH_AGENT_SOCK或echo $SSH_AUTH_SOCK中的一个应该会给你一些输出，ssh-add -L应该会显示上面可用的标识。

使用详细日志记录时可能出现的一些错误:

主机密钥验证失败:您没有将远程主机添加到映像的~/.ssh/known_hosts pubkey_prepare: ssh_get_authentication_socket:没有这样的文件或目录:你忘记在docker build中包含——ssh默认参数 pubkey_prepare: ssh_get_authentication_socket: Permission denied: are you using some USER <username>?然后使用——mount=type=ssh,uid=<uid>指定它的用户id，或者使用——mount=type=ssh,mode=0666向所有用户打开套接字

这也适用于PIP/Conda/Mamba直接从版本控制安装Python依赖项，如git+ssh://git@github.com/myorg/myproject.git@mybranch#egg=myproject:

RUN --mount=type=ssh mamba env create -n myenv --file conda_environment.yml

由于Windows容器仍然不支持BuildKit，一种替代方法是使用网络共享。这将创建一个最小的Docker映像大小，因为安装程序是在单个RUN语句期间从容器中添加/删除的。

将EXE / MSI文件放在主机上的一个文件夹中 共享文件夹 开始构建Docker 从Docker容器内映射共享 复制+运行+删除每个安装程序 移除容器内的映射 Docker构建 取消主机上的共享文件夹

下面是一个创建Java 11 Windows容器的工作示例:

build.cmd:

host=%COMPUTERNAME%
set domainAndUser=whoami
set "pswd=<host-password>"
set "shareName=tmpSmbShare"
set netPath=\\%COMPUTERNAME%\%shareName%
set "localPath=C:/Users/tester/Desktop/docker/Java11/winsrvcore/installers"

powershell New-SmbShare -Name %shareName% -Path %localPath% -FullAccess "Everyone"
docker build ^
--build-arg domainAndUser=%domainAndUser% ^
--build-arg pswd=%pswd% ^
--build-arg netPath=%netPath% ^
-t <docker-username>/java-11.0.16-winsrvcore.ltsc2019:1.0 .
powershell Remove-SmbShare -Name %shareName% -Force

Dockerfile：

FROM mcr.microsoft.com/windows/servercore:ltsc2019-amd64

ARG domainAndUser
ARG pswd
ARG netPath

RUN powershell New-SMBMapping -LocalPath "R:" -RemotePath "$env:netPath" -UserName "$env:domainAndUser" -Password "$env:pswd" \
    && dir "R:/" \
    && copy "R:/jdk-11.0.16_windows-x64_bin.exe" "C:/" \
    && powershell Start-Process -filepath 'C:/jdk-11.0.16_windows-x64_bin.exe' -Wait -PassThru -ArgumentList "/s,/L,install64.log" \
    && powershell Remove-SMBMapping -LocalPath "R:" -Force \
    && del "C:/jdk-11.0.16_windows-x64_bin.exe" 

ENV JAVA_HOME "C:\Program Files\Java\jdk-11.0.16"