Re:The Man Who Would Build a Computer the Size of the Entire...
by peterwwillis on Monday September 09, 2013 @02:57PM
(#6355418)
Docker is a couple different things in one, so in that respect, it works in different ways.
The main thing Docker does is run arbitrary commands with (or like) LXC, which is basically a way of running a program inside a chroot environment, plus providing a more low-level separation for various parts of the kernel. The end result is your host is kept insulated from the program being run. Here's a great HOWTO on setting up LXC: http://lxc.teegra.net/ And here's a great StackOverflow answer on what Docker/LXC does: http://stackoverflow.com/questions/16047306/how-is-docker-io...
And the best technical summary from Docker's documentation on what a container is:
"Once you start a process in Docker from an Image, Docker fetches the image and its Parent Image, and repeats the process until it reaches the Base Image. Then the Union File System adds a read-write layer on top. That read-write layer, plus the information about its Parent Image and some additional information like its unique id, networking configuration, and resource limits is called a container."
On top of that it adds a Registry, an Index, and a Remote API. So really, it has remote deployment features, it builds chroot environments, and it combines them and runs applications in a container. Oh, and here is the FAQ: http://docs.docker.io/en/latest/faq/ Summary of their points de-marketingized:
Portable deployment across machines
You can copy a big image of your chroot environment, application, etc to a remote machine and run it. Docker makes the configuration configurable.
Application-centric
They added features to make it easier to deploy a program and run it how you want it to run.
Automatic build
Instead of using a shell script to build your container's chroot environment, you use a Dockerfile, which is like a less useful shell script.
Versioning
Docker assigns a SHA hash to each image you deploy so you can roll back and do other things on the hash instead of the file name. It also transfers deltas of changes, apparently.
Component re-use
Due to using a unionfs, you can mount multiple images on top of one another, so you can have smaller separate images and pick the ones you want to use for your app.
Sharing
You can upload your images to a public repository or download them for your own use.
The main thing Docker does is run arbitrary commands with (or like) LXC, which is basically a way of running a program inside a chroot environment, plus providing a more low-level separation for various parts of the kernel. The end result is your host is kept insulated from the program being run. Here's a great HOWTO on setting up LXC: http://lxc.teegra.net/ And here's a great StackOverflow answer on what Docker/LXC does: http://stackoverflow.com/questions/16047306/how-is-docker-io...
This page from Docker's blog discusses not only the security aspects of a container, but a comparison to traditional virtual machines: http://blog.docker.io/2013/08/containers-docker-how-secure-a...
And the best technical summary from Docker's documentation on what a container is:
"Once you start a process in Docker from an Image, Docker fetches the image and its Parent Image, and repeats the process until it reaches the Base Image. Then the Union File System adds a read-write layer on top. That read-write layer, plus the information about its Parent Image and some additional information like its unique id, networking configuration, and resource limits is called a container."
On top of that it adds a Registry, an Index, and a Remote API. So really, it has remote deployment features, it builds chroot environments, and it combines them and runs applications in a container. Oh, and here is the FAQ: http://docs.docker.io/en/latest/faq/ Summary of their points de-marketingized:
You can copy a big image of your chroot environment, application, etc to a remote machine and run it. Docker makes the configuration configurable. They added features to make it easier to deploy a program and run it how you want it to run. Instead of using a shell script to build your container's chroot environment, you use a Dockerfile, which is like a less useful shell script. Docker assigns a SHA hash to each image you deploy so you can roll back and do other things on the hash instead of the file name. It also transfers deltas of changes, apparently. Due to using a unionfs, you can mount multiple images on top of one another, so you can have smaller separate images and pick the ones you want to use for your app. You can upload your images to a public repository or download them for your own use. Docker has an API. (Actually three APIs)