我正在考虑使用 Docker 在持续集成 (CI) 服务器上构建我的依赖项,这样我就不必在代理本身上安装所有运行时和库。

为了实现这一点,我需要将容器内构建的构建工件复制回主机中。那可能吗?

有帮助吗?

解决方案

为了将文件从容器复制到主机,您可以使用命令

docker cp <containerId>:/file/path/within/container /host/path/target
.

这是一个例子:

$ sudo docker cp goofy_roentgen:/out_read.jpg .
.

goofy_roentgen 是我从以下命令获得的容器名称:

$ sudo docker ps

CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS                                            NAMES
1b4ad9311e93        bamos/openface      "/bin/bash"         33 minutes ago      Up 33 minutes       0.0.0.0:8000->8000/tcp, 0.0.0.0:9000->9000/tcp   goofy_roentgen
.

您还可以使用(部分)容器id 。以下命令等同于第一个

$ sudo docker cp 1b4a:/out_read.jpg .
.

其他提示

您不需要使用 docker run

你可以这样做 docker create

来自文档docker create 命令在指定的镜像上创建一个可写的容器层,并准备运行指定的命令。然后容器 ID 被打印到 STDOUT。这与 docker run -d 类似,只是容器从未启动。

所以,你可以做

docker create -ti --name dummy IMAGE_NAME bash
docker cp dummy:/path/to/file /dest/to/file
docker rm -f dummy

在这里,您永远不会启动容器。这看起来对我有利。

安装一个“卷”并将工件复制到其中:

mkdir artifacts
docker run -i -v ${PWD}/artifacts:/artifacts ubuntu:14.04 sh << COMMANDS
# ... build software here ...
cp <artifact> /artifacts
# ... copy more artifacts into `/artifacts` ...
COMMANDS

然后,当构建完成并且容器不再运行时,它已经将构建中的工件复制到 artifacts 主机上的目录。

编辑

警告: 执行此操作时,您可能会遇到 docker 用户的用户 ID 与当前运行用户的用户 ID 匹配的问题。也就是说,文件在 /artifacts 将显示为由用户拥有,并具有 docker 容器内使用的用户的 UID。解决这个问题的方法可能是使用调用用户的 UID:

docker run -i -v ${PWD}:/working_dir -w /working_dir -u $(id -u) \
    ubuntu:14.04 sh << COMMANDS
# Since $(id -u) owns /working_dir, you should be okay running commands here
# and having them work. Then copy stuff into /working_dir/artifacts .
COMMANDS

安装卷,复制伪像,调整所有者ID和组ID:

mkdir artifacts
docker run -i --rm -v ${PWD}/artifacts:/mnt/artifacts centos:6 /bin/bash << COMMANDS
ls -la > /mnt/artifacts/ls.txt
echo Changing owner from \$(id -u):\$(id -g) to $(id -u):$(id -u)
chown -R $(id -u):$(id -u) /mnt/artifacts
COMMANDS
.

太长了;

$ docker run --rm -iv${PWD}:/host-volume my-image sh -s <<EOF
chown $(id -u):$(id -g) my-artifact.tar.xz
cp -a my-artifact.tar.xz /host-volume
EOF

描述

docker run 具有主机卷, chown 神器, cp 主机卷的工件:

$ docker build -t my-image - <<EOF
> FROM busybox
> WORKDIR /workdir
> RUN touch foo.txt bar.txt qux.txt
> EOF
Sending build context to Docker daemon  2.048kB
Step 1/3 : FROM busybox
 ---> 00f017a8c2a6
Step 2/3 : WORKDIR /workdir
 ---> Using cache
 ---> 36151d97f2c9
Step 3/3 : RUN touch foo.txt bar.txt qux.txt
 ---> Running in a657ed4f5cab
 ---> 4dd197569e44
Removing intermediate container a657ed4f5cab
Successfully built 4dd197569e44

$ docker run --rm -iv${PWD}:/host-volume my-image sh -s <<EOF
chown -v $(id -u):$(id -g) *.txt
cp -va *.txt /host-volume
EOF
changed ownership of '/host-volume/bar.txt' to 10335:11111
changed ownership of '/host-volume/qux.txt' to 10335:11111
changed ownership of '/host-volume/foo.txt' to 10335:11111
'bar.txt' -> '/host-volume/bar.txt'
'foo.txt' -> '/host-volume/foo.txt'
'qux.txt' -> '/host-volume/qux.txt'

$ ls -n
total 0
-rw-r--r-- 1 10335 11111 0 May  7 18:22 bar.txt
-rw-r--r-- 1 10335 11111 0 May  7 18:22 foo.txt
-rw-r--r-- 1 10335 11111 0 May  7 18:22 qux.txt

这个技巧之所以有效,是因为 chown 内调用 特雷多克 需要的 $(id -u):$(id -g) 来自正在运行的容器外部的值;即 docker 主机。

好处是:

  • 你不必 docker container run --name 或者 docker container create --name
  • 你不必 docker container rm

如果您没有运行的容器,只是一个图像,并假设要只要复制文本文件,您可以执行类似的内容:

docker run the-image cat path/to/container/file.txt > path/to/host/file.txt
.

大多数答案并没有表明容器必须先运行 docker cp 将工作:

docker build -t IMAGE_TAG .
docker run -d IMAGE_TAG
CONTAINER_ID=$(docker ps -alq)
# If you do not know the exact file name, you'll need to run "ls"
# FILE=$(docker exec CONTAINER_ID sh -c "ls /path/*.zip")
docker cp $CONTAINER_ID:/path/to/file .
docker stop $CONTAINER_ID

我将这篇文章发布给所有使用 Docker for Mac 的人。这对我有用:

 $ mkdir mybackup # local directory on Mac

 $ docker run --rm --volumes-from <containerid> \
    -v `pwd`/mybackup:/backup \  
    busybox \                   
    cp /data/mydata.txt /backup 

请注意,当我使用安装时 -vbackup 目录会自动创建。

我希望有一天这对某人有用。:)

作为一个更常见的解决方案,有一个Cloudbees插件为Jenkins建立在Docker Container 内部。您可以从Docker注册表中选择要使用的图像或定义Dockerfile以构建和使用。

它将工作区装入容器作为卷(使用适当的用户),将其设置为工作目录,请执行您请求的任何命令(在容器中)。 您还可以使用Docker-Workflow插件(如果您喜欢通过UI的代码)使用image.inside(){}命令执行此操作。

基本上所有这一切,烘焙到您的CI / CD服务器中,然后是一些。

如果您只想从图像中提取文件(而不是运行容器),您可以执行以下操作:

docker run --rm <image> cat <source> > <local_dest>

这将显示容器,写入新文件,然后删除容器。但是,一个缺点是,文件权限和修改日期将不会被保留。

我用这个命令使用powershell(admin)。

docker cp {container id}:{container path}/error.html  C:\\error.html
.

示例

docker cp ff3a6608467d:/var/www/app/error.html  C:\\error.html
.

随着 Docker 19.03 的发布,您可以跳过创建容器甚至构建镜像。基于 BuildKit 的构建有一个选项可以更改输出目标。您可以使用它将构建结果写入本地目录,而不是写入图像。例如。这是 go 二进制文件的构建:

$ ls
Dockerfile  go.mod  main.go

$ cat Dockerfile
FROM golang:1.12-alpine as dev
RUN apk add --no-cache git ca-certificates
RUN adduser -D appuser
WORKDIR /src
COPY . /src/
CMD CGO_ENABLED=0 go build -o app . && ./app

FROM dev as build
RUN CGO_ENABLED=0 go build -o app .
USER appuser
CMD [ "./app" ]

FROM scratch as release
COPY --from=build /etc/passwd /etc/group /etc/
COPY --from=build /src/app /app
USER appuser
CMD [ "/app" ]

FROM scratch as artifact
COPY --from=build /src/app /app

FROM release

从上面的 Dockerfile 中,我正在构建 artifact 阶段仅包含我要导出的文件。还有新推出的 --output flag 允许我将它们写入本地目录而不是图像。这需要使用 19.03 附带的 BuildKit 引擎来执行:

$ DOCKER_BUILDKIT=1 docker build --target artifact --output type=local,dest=. .
[+] Building 43.5s (12/12) FINISHED
 => [internal] load build definition from Dockerfile                                                                              0.7s
 => => transferring dockerfile: 572B                                                                                              0.0s
 => [internal] load .dockerignore                                                                                                 0.5s
 => => transferring context: 2B                                                                                                   0.0s
 => [internal] load metadata for docker.io/library/golang:1.12-alpine                                                             0.9s
 => [dev 1/5] FROM docker.io/library/golang:1.12-alpine@sha256:50deab916cce57a792cd88af3479d127a9ec571692a1a9c22109532c0d0499a0  22.5s
 => => resolve docker.io/library/golang:1.12-alpine@sha256:50deab916cce57a792cd88af3479d127a9ec571692a1a9c22109532c0d0499a0       0.0s
 => => sha256:1ec62c064901392a6722bb47a377c01a381f4482b1ce094b6d28682b6b6279fd 155B / 155B                                        0.3s
 => => sha256:50deab916cce57a792cd88af3479d127a9ec571692a1a9c22109532c0d0499a0 1.65kB / 1.65kB                                    0.0s
 => => sha256:2ecd820bec717ec5a8cdc2a1ae04887ed9b46c996f515abc481cac43a12628da 1.36kB / 1.36kB                                    0.0s
 => => sha256:6a17089e5a3afc489e5b6c118cd46eda66b2d5361f309d8d4b0dcac268a47b13 3.81kB / 3.81kB                                    0.0s
 => => sha256:89d9c30c1d48bac627e5c6cb0d1ed1eec28e7dbdfbcc04712e4c79c0f83faf17 2.79MB / 2.79MB                                    0.6s
 => => sha256:8ef94372a977c02d425f12c8cbda5416e372b7a869a6c2b20342c589dba3eae5 301.72kB / 301.72kB                                0.4s
 => => sha256:025f14a3d97f92c07a07446e7ea8933b86068d00da9e252cf3277e9347b6fe69 125.33MB / 125.33MB                               13.7s
 => => sha256:7047deb9704134ff71c99791be3f6474bb45bc3971dde9257ef9186d7cb156db 125B / 125B                                        0.8s
 => => extracting sha256:89d9c30c1d48bac627e5c6cb0d1ed1eec28e7dbdfbcc04712e4c79c0f83faf17                                         0.2s
 => => extracting sha256:8ef94372a977c02d425f12c8cbda5416e372b7a869a6c2b20342c589dba3eae5                                         0.1s
 => => extracting sha256:1ec62c064901392a6722bb47a377c01a381f4482b1ce094b6d28682b6b6279fd                                         0.0s
 => => extracting sha256:025f14a3d97f92c07a07446e7ea8933b86068d00da9e252cf3277e9347b6fe69                                         5.2s
 => => extracting sha256:7047deb9704134ff71c99791be3f6474bb45bc3971dde9257ef9186d7cb156db                                         0.0s
 => [internal] load build context                                                                                                 0.3s
 => => transferring context: 2.11kB                                                                                               0.0s
 => [dev 2/5] RUN apk add --no-cache git ca-certificates                                                                          3.8s
 => [dev 3/5] RUN adduser -D appuser                                                                                              1.7s
 => [dev 4/5] WORKDIR /src                                                                                                        0.5s
 => [dev 5/5] COPY . /src/                                                                                                        0.4s
 => [build 1/1] RUN CGO_ENABLED=0 go build -o app .                                                                              11.6s
 => [artifact 1/1] COPY --from=build /src/app /app                                                                                0.5s
 => exporting to client                                                                                                           0.1s
 => => copying files 10.00MB                                                                                                      0.1s

构建完成后 app 二进制文件已导出:

$ ls
Dockerfile  app  go.mod  main.go

$ ./app
Ready to receive requests on port 8080

Docker 还有其他选择 --output 其上游 BuildKit 存储库中记录的标志: https://github.com/moby/buildkit#output

在主机系统(容器外部)上创建数据目录并将其安装到容器内部可见的目录中。这将文件放在主机系统上的已知位置,并使主机系统上的工具和应用程序易于访问文件

docker run -d -v /path/to/Local_host_dir:/path/to/docker_dir docker_image:tag
.

创建要复制文件的路径,然后使用:

docker run -d -v hostpath:dockerimag
.

您可以使用 bind 代替 volume 如果您只想挂载一个文件夹,则不要为容器创建特殊存储:

  1. 使用标签构建您的图像:

    docker build . -t <image>

  2. 运行您的图像并绑定 app.py 存储的当前 $(pwd) 目录并将其映射到容器内的 /root/example/ 。

    docker run --mount type=bind,source="$(pwd)",target=/root/example/ <image> python app.py

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top