Commit 1d3e5ada authored by Adam Hawkins's avatar Adam Hawkins

Complete second editing around

parent 4a3717e6
......@@ -22,14 +22,14 @@ site. You can do that with Docker containers.
## The Easy Way
However doing so introduces a small problem. Most examples (even the
official images) do something like this:
Most examples (even the official images) do something like this:
```bash
docker run --rm -it "${PWD}:/data" some_image
docker run --rm -it "${PWD}:/data" some_image --output /data
```
I do the same thing to generate my Ruby dependencies:
Where `some_image` writes files to `/data`. I do the same thing to
generate my Ruby dependencies:
```bash
docker run --rm -it "${PWD}:/data" -w /data ruby:2.3 \
......@@ -42,16 +42,15 @@ container to generate artifacts on the Docker host.
## A Fix
This is the easiest to get data in/out of the container. This creates
a problem though since Docker containers are often run as root. This
approach may litter the file system with root owner artifacts depending
on your Docker setup (e.g. the docker daemon runs directly on your
host or the docker daemon is running in a VM). The problem usually
reveals itself if the commands happen on CI. These machines usually
run Linux with a native Docker install so container run as root and
write root owned files back to the bind mount. This is solved by
running the container as the current user (`-u $(id -u)`). Here's an
example:
This is the easiest way to get data in/out of containers. However it
creates a problem since Docker containers are often run as root. This
approach may litter the file system with root owner artifacts
depending on your Docker setup (e.g. the Docker daemon runs directly
on your host or the Docker daemon is running in a VM). The problem
usually reveals itself on CI. These machines usually run Linux with a
native Docker install so container run as root and write root owned
files back to the bind mount. The workaround is to run the container
as the current user (`-u $(id -u)`). Here's an example:
```bash
docker run --rm -it -u $(id -u) "${PWD}:/data" -w /data ruby:2.3 \
......@@ -60,21 +59,19 @@ docker run --rm -it -u $(id -u) "${PWD}:/data" -w /data ruby:2.3 \
Now the container runs as `$USER`, thus files generated by the
container are owned by that `$USER`. This solves probably 90% of use
cases. There are scenarios where this may not work.
This solution does not work with remote Docker hosts (e.g. something
like Swarm). `docker-machine` on OSX solves this by mounting `$HOME`
as a shared directory in the VM so file system mounts (inside `$HOME`)
work transparently.
cases. There are scenarios where this may not work. This solution does
not work with remote Docker hosts (e.g. something like Swarm).
`docker-machine` on OSX solves this by mounting `$HOME` as a shared
directory in the VM so file system mounts (inside `$HOME`) work
transparently.
## The Correct Way
There is a sure fire way to do this that works in 100% of scenarios
without any workarounds. The solution is to use `docker cp`. The `cp`
command allows you to copy files into and out of containers. `cp`
works on individual files or directories. Files are copied directly
while directories are tarred. This solution requires a few more
commands but works **100% of the time**. Let's see some examples.
`docker cp` works in 100% of scenarios without any workarounds. The
`cp` command copies files into and out of containers. `cp` works on
individual files or directories. Files are copied directly while
directories are tarred. This solution requires a few more commands but
works **100% of the time**. Let's see some examples.
Here we assume the Docker image contains everything required to build
the artifact(s).
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment