Docker originally used LinuX Containers (LXC), but later switched to runC (formerly known as libcontainer), which runs in the same operating system as its host. This allows it to share a lot of the host operating system resources. Also, it uses a layered filesystem (AuFS) and manages networking.
AuFS is a layered file system, so you can have a read only part and a write part which are merged together. One could have the common parts of the operating system as read only (and shared amongst all of your containers) and then give each container its own mount for writing.
So, let's say you have a 1 GB container image; if you wanted to use a full VM, you would need to have 1 GB x number of VMs you want. With Docker and AuFS you can share the bulk of the 1 GB between all the containers and if you have 1000 containers you still might only have a little over 1 GB of space for the containers OS (assuming they are all running the same OS image).
A full virtualized system gets its own set of resources allocated to it, and does minimal sharing. You get more isolation, but it is much heavier (requires more resources). With Docker you get less isolation, but the containers are lightweight (require fewer resources). So you could easily run thousands of containers on a host, and it won't even blink. Try doing that with Xen, and unless you have a really big host, I don't think it is possible.
A full virtualized system usually takes minutes to start, whereas Docker/LXC/runC containers take seconds, and often even less than a second.
There are pros and cons for each type of virtualized system. If you want full isolation with guaranteed resources, a full VM is the way to go. If you just want to isolate processes from each other and want to run a ton of them on a reasonably sized host, then Docker/LXC/runC seems to be the way to go.
For more information, check out this set of blog posts which do a good job of explaining how LXC works.
Why is deploying software to a docker image (if that's the right term) easier than simply deploying to a consistent production environment?
Deploying a consistent production environment is easier said than done. Even if you use tools like Chef and Puppet, there are always OS updates and other things that change between hosts and environments.
Docker gives you the ability to snapshot the OS into a shared image, and makes it easy to deploy on other Docker hosts. Locally, dev, qa, prod, etc.: all the same image. Sure you can do this with other tools, but not nearly as easily or fast.
This is great for testing; let's say you have thousands of tests that need to connect to a database, and each test needs a pristine copy of the database and will make changes to the data. The classic approach to this is to reset the database after every test either with custom code or with tools like Flyway - this can be very time-consuming and means that tests must be run serially. However, with Docker you could create an image of your database and run up one instance per test, and then run all the tests in parallel since you know they will all be running against the same snapshot of the database. Since the tests are running in parallel and in Docker containers they could run all on the same box at the same time and should finish much faster. Try doing that with a full VM.
From comments...
Interesting! I suppose I'm still confused by the notion of "snapshot[ting] the OS". How does one do that without, well, making an image of the OS?
Well, let's see if I can explain. You start with a base image, and then make your changes, and commit those changes using docker, and it creates an image. This image contains only the differences from the base. When you want to run your image, you also need the base, and it layers your image on top of the base using a layered file system: as mentioned above, Docker uses AuFS. AuFS merges the different layers together and you get what you want; you just need to run it. You can keep adding more and more images (layers) and it will continue to only save the diffs. Since Docker typically builds on top of ready-made images from a registry, you rarely have to "snapshot" the whole OS yourself.
Docker 1.9.0 and above
Use volume API
docker volume create --name hello
docker run -d -v hello:/container/path/for/volume container_image my_command
This means that the data-only container pattern must be abandoned in favour of the new volumes.
Actually the volume API is only a better way to achieve what was the data-container pattern.
If you create a container with a -v volume_name:/container/fs/path
Docker will automatically create a named volume for you that can:
- Be listed through the
docker volume ls
- Be identified through the
docker volume inspect volume_name
- Backed up as a normal directory
- Backed up as before through a
--volumes-from
connection
The new volume API adds a useful command that lets you identify dangling volumes:
docker volume ls -f dangling=true
And then remove it through its name:
docker volume rm <volume name>
As @mpugach underlines in the comments, you can get rid of all the dangling volumes with a nice one-liner:
docker volume rm $(docker volume ls -f dangling=true -q)
# Or using 1.13.x
docker volume prune
Docker 1.8.x and below
The approach that seems to work best for production is to use a data only container.
The data only container is run on a barebones image and actually does nothing except exposing a data volume.
Then you can run any other container to have access to the data container volumes:
docker run --volumes-from data-container some-other-container command-to-execute
- Here you can get a good picture of how to arrange the different containers.
- Here there is a good insight on how volumes work.
In this blog post there is a good description of the so-called container as volume pattern which clarifies the main point of having data only containers.
Docker documentation has now the DEFINITIVE description of the container as volume/s pattern.
Following is the backup/restore procedure for Docker 1.8.x and below.
BACKUP:
sudo docker run --rm --volumes-from DATA -v $(pwd):/backup busybox tar cvf /backup/backup.tar /data
- --rm: remove the container when it exits
- --volumes-from DATA: attach to the volumes shared by the DATA container
- -v $(pwd):/backup: bind mount the current directory into the container; to write the tar file to
- busybox: a small simpler image - good for quick maintenance
- tar cvf /backup/backup.tar /data: creates an uncompressed tar file of all the files in the /data directory
RESTORE:
# Create a new data container
$ sudo docker run -v /data -name DATA2 busybox true
# untar the backup files into the new container᾿s data volume
$ sudo docker run --rm --volumes-from DATA2 -v $(pwd):/backup busybox tar xvf /backup/backup.tar
data/
data/sven.txt
# Compare to the original container
$ sudo docker run --rm --volumes-from DATA -v `pwd`:/backup busybox ls /data
sven.txt
Here is a nice article from the excellent Brian Goff explaining why it is good to use the same image for a container and a data container.
Best Answer
It looks like your
chown -R nginx:nginx ...
commands inside your container are changing the ownership bits on your files to be owned bylibuuid
on your host machine.See Understanding user file ownership in docker: how to avoid changing permissions of linked volumes for a basic explanation on how file ownership bits work between your host and your docker containers.