mesos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Itamar Ostricher <>
Subject Docker Tip: On the mortality of the container filesystem
Date Mon, 13 Jun 2016 07:52:07 GMT
As mentioned in the seminar(s) and in the previous tip, "bind-mounting" is
the Docker way to share a directory between the host filesystem (yours),
and a running container.

Again, reminding that you'd want to bind-mount to:
1. Give the container access to files on your host, that are not available
inside the sandbox (e.g. the Docker image).
2. Allow the container to write output to the host, so it can live beyond
the lifetime of the container. (like SCons does to put the built binaries
in your build/release)

That second point can be tricky to digest.
Whenever you use Docker to run something that has any output that lives in
the filesystem, this output can go to one of two places:
1. A path inside the container filesystem itself (e.g. `/tmp`).
2. A bind-mounted volume that is mapped from the host into the container
(e.g. `/project` in most of the commands we commonly use).

Docker containers are ephemeral (e.g., mortal - go away once the
application they're running ends). Once the container ends, the container
filesystem "evaporates" with it.
*This means that anything written to it since it began also goes away with

You may consider this an annoyance (why this Docker thing throws away my
stuff?!), but it's also a pretty useful feature (hey, look at this easy way
to revert my application to its default good state!).
It is actually used in production systems to quickly recover from hacking
attacks (the application in a container was hacked - throw away hacked
container and start a clean new one).

*For the cases that you actually need to have outputs from the container
outlive the container itself* - bind-mounting is the solution that enables
it, and it is done using (one or more) `-v /foo:/bar` flags on the `docker
run` command-line.

Now, with this understanding, you might want to revisit the previous tip on
faking uid inside a container, in case it was confusing... :-)

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message