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

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将它们复制回映像中以进行下一次构建。

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

正如许多人已经回答的那样，在构建期间挂载主机卷是不可能的。我只是想添加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运行容器

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

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

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

docker run -v /export:/export data

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

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

首先，要回答“为什么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。