Я думаю об использовании 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
Вы также можете использовать (часть) Container ID . Следующая команда эквивалентна первой
$ sudo docker cp 1b4a:/out_read.jpg .
Вам не нужно использовать docker run
Вы можете сделать это с docker create
Из документов Команда создания докера создает слой записываемого контейнера над указанным изображением и подготавливает его к выполнению указанной команды. Идентификатор контейнера затем печатается в 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
на хосте.
Caveat: При этом вы можете столкнуться с проблемами, когда идентификатор пользователя докера соответствует идентификатору пользователя текущего работающего пользователя. То есть файлы в / artifacts
будут отображаться как принадлежащие пользователю с 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
Установите том, скопируйте артефакты, настройте идентификатор владельца и идентификатор группы:
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
в hedoc принимает значения $ (id -u): $ (id -g)
снаружи работающего контейнера; то есть., хост докера.
Преимущества:
docker container run --name
или docker container create --name
раньшеконтейнер для докеров 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 для Mac. Это то, что сработало для меня
$ mkdir mybackup # local directory on Mac
$ docker run --rm --volumes-from <containerid> \
-v `pwd`/mybackup:/backup \
busybox \
cp /data/mydata.txt /backup
Обратите внимание, что при монтировании с помощью -v
этот каталог backup
создается автоматически.
Я надеюсь, что это когда-нибудь будет полезно для кого-то. :)
В качестве более общего решения [есть плагин CloudBees для Jenkins, который можно построить внутри контейнера Docker][1]. Вы можете выбрать изображение для использования из реестра Docker или определить Dockerfile для сборки и использования.
Он будет монтировать рабочее пространство в контейнер в виде тома (с соответствующим пользователем), устанавливать его в качестве рабочего каталога, выполнять любые команды, которые вы запрашиваете (внутри контейнера). Вы также можете использовать плагин docker-workflow (если вы предпочитаете код вместо пользовательского интерфейса) для этого с помощью команды image.inside () {{{}}}.
В основном все это, запекается на вашем сервере CI / CD, а затем на некоторых.
[1]: https://wiki.jenkins-ci.org/display/JENKINS/CloudBees + Docker + Custom + Build + Environment + Plugin
docker run -dit --rm IMAGE
docker cp CONTAINER:SRC_PATH DEST_PATH
https://docs.docker.com/engine/reference/commandline/run/ https://docs.docker.com/engine/reference/commandline/cp/
Если вы просто хотите извлечь файл из изображения (вместо работающего контейнера), вы можете сделать это:
docker run --rm < image > кошка < source > > < local_dest >
Это приведет к появлению контейнера, записи нового файла, а затем удалит контейнер. Однако одним из недостатков является то, что разрешения на файл и измененная дата не будут сохранены.
Я использовал PowerShell (Администратор) с этой командой.
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, чтобы изменить место назначения вывода. Вы можете использовать это, чтобы записать результаты сборки в локальный каталог, а не в изображение. Например. вот сборка бинарного го:
$ 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
позволяет мне записывать их в локальный каталог вместо изображения. Это необходимо выполнить с двигателем BuildKit, который поставляется с 19.03:
$ 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 hostpath:dockerimag
Создайте каталог данных в хост-системе (за пределами контейнера) и смонтируйте его в каталог, видимый изнутри контейнера. Это помещает файлы в известное место в хост-системе и позволяет инструментам и приложениям в хост-системе легко получать доступ к файлам
docker run -d -v /path/to/Local_host_dir:/path/to/docker_dir docker_image:tag
Вы можете использовать bind
вместо `` volume```
, если вы хотите смонтировать только одну папку, а не создавать специальное хранилище для контейнера:
Создайте свое изображение с помощью тега < image >:
сборка докеров . -t < image >
Запустите изображение и свяжите текущий каталог $ (pwd), в котором app.py хранит, и сопоставьте его с / root / example / внутри вашего контейнера.
``` docker run --mount type = bind, source = "$ (pwd)", target = / root / example / < image > python app.py````