Running Docker in Memory?

As far as I understand Docker uses memory mapped files to start from image. Since I can do this over and over again and as far as I remember start different instances of the same image in parallel, I guess docker abstracts the file system and stores changes somewhere else.

I wonder if docker can be configured (or does it by default) to run in a memory only mode without some sort of a temporary file?

  • How to docker exec to IBM bluemix containers
  • How can you get Grunt livereload to work inside Docker?
  • Docker run giving different result to docker build (trying to use 32bit image on 64bit host)
  • Unable To Disconnect Docker Container From Network
  • Multi command with docker in a script
  • Golang binary built inside Docker container, still Mach-O executable format?
  • Docker environmental variables as calculated parameters
  • How can I check that Openwhisk gets invoked?
  • Variable substitution in docker-compose.yml file when running docker-compose with sudo
  • Push images to private docker registry error with 500
  • How can i upload data to docker (container)?
  • unresolved dependencies: sbt-routes-compiler and sbt-run-support
  • One Solution collect form web for “Running Docker in Memory?”

    Docker uses a union filesystem that allows it to work in “layers” (devicemapper, BTRFS, etc). It’s doing copy-on-write so that starting new containers is cheap, and when it performs the first write, it actually creates a new layer.

    When you start a container from an image, you are not using memory-mapped files to restore a frozen process (unless you built all of that into the image yourself…). Rather, you’re starting a normal Unix process but inside a sandbox where it can only see its own unionfs filesystem.

    Starting many copies of an image where no copy writes to disk is generally cheap and fast. But if you have a process with a long start-up time, you’ll still pay that cost for every instance.

    As for running Docker containers wholly in memory, you could create a RAM disk and specify that as Docker’s storage volume (configurable, but typically located under /var/lib/docker).

    In typical use-cases, I would not expect this to be a useful performance tweak. First, you’ll spend a lot of memory holding files you won’t access. The base layer of an image contains most Linux system files. If you fetch 10 packages from the Docker Hub, you’ll probably hit 20G worth of images easily (after that the storage cost tends to plateau). Second, the system already manages memory and swapping pretty well (which is why a RAM disk is a performance tweak) and you get all of that applied to processes running inside a container. Third, for most of the cases where a RAM disk might help, you can use the -v flag to mount the disk as a volume on the container rather than needing to store your whole unionfs there.

    Docker will be the best open platform for developers and sysadmins to build, ship, and run distributed applications.