GitLab

1. Acknowledgements
2. What's Docker?
3. Why Docker?
4. Docker Hows
5. Todo

Acknowledgements:

• Thanks go out to Chris Jones, who put on a highly educational Docker presentation at Greater Orlando Linux User Group (GoLUG) and who took the time to answer many of my Docker questions before and during the presentation Thanks also to the Docker developers and documenters for this fine resource. What's Docker?:
• Docker is a facility for creating encapsulated computer environments, each with its own running copy of Linux. Each encapsulated computer environment is called a container. Each container (encapsulated computer environment) shares the host computer's copy of the kernel. This means there's no hypervisor, and no extended bootup. Starting up a Docker container is lightning fast. The fact that the kernel must be a Linux kernel creates these two restrictions on Docker: Docker runs only on Linux Docker containers can run only Linux programs If you need to simultaneously run different operating systems (like Windows, OS/X or BSD), or run programs compiled for other operating systems, Docker can't help you: You need to do a full Virtual Machines implantation like KVM, VirtualBox or VMware Docker Documentation:
• This document you're now reading is just an overview, perhaps with a few general ideas of how to accomplish certain things. It's not a document to teach yourself Docker. For that, you need the full Docker Documentation, the root of which is located at http://www.docker.io. Useful specific docs include: Docker installation Docker tutorials Interactive commandline tutorial Dockerfile tutorial The preceding are documentation from the makers of Docker, they're excellent, and there's no substitute for reading them. The document you're currently reading is great for an overview before jumping in, but when actually performing Docker activities, you should use the official Docker documentation. If you want to have a good life in Dockerland, take the time to read the Docker docs.

Docker Encapsulation:

• A Docker container shares a kernel with the host OS and with other containers. Other than that, the container is completely isolated from everything else, at least by default. Therefore, Docker is a great sandbox for development, testing, experimentation. But Docker's abilities as a sandbox barely scratch the surface of its capabilities and usefulness. Docker's greater use is as a thing that can be plopped down on a computer to run an application, without any worry about dependencies. This is huge, but this requires deliberate holes in the container's encapsulation. Here are just a few of the easy ways you can poke controlled holes in a Docker container's encapsulation: mount --span to share disk space with the host OS. Port forwarding so the host OS can access the container via a port. ssh -X so the container's X server can output to the host OS' X client, enabling the container to run GUI apps. Some GUI apps can also be run from containers by bind mounting the host OS' /tmp directory to the container's /tmp directory and setting the container's $DISPLAY to :0, but this works on only some GUI apps, and seems not to work on Qt apps.

Docker Terminology:

• Before getting to Docker-specific definitions, the word sandbox refers to a computing environment in which what happens in the sandbox stays in the sandbox. If you were to perform an rm -rf within the sandbox, the contents of the sandbox get erased, but the containing computer suffers no damage. If you were to create a security breach within the sandbox, enabling a badguy to get in, theoretically the badguy could harm only the sandbox, not the containing computer. Of course, the practicality of the preceding sentence depends on the nature of the security breach and the knowledge and ability of the badguy, but all things being equal, a security problem in a sandbox is hugely preferable to the same security breach on the containing computer. Now let's talk about Docker specific terminology. Life is much easier if you understand Docker terminology from the very start. The easiest way to get an initial grasp of Docker terminology is via the following (greatly simplified) diagram: Docker terminology diagram Looking at the diagram, you'll see that a container is a runtime implementation of an image. Many containers can be started from one image. As an analogy, an image is kind of like an architectural drawing of a house, and a container is a house built based on that drawing. As anyone who has driven through a housing community knows, several houses can be constructed from one drawing. Another analogy might be in Object Oriented Programming, with the image being a class and the container being an object. The thing that does all the computing is the container: An image alone does nothing except serve as a template for containers. the following (greatly simplified) diagram:

Docker terminology diagram:

Why Docker?:

• If you need a sandbox in which to develop or test, the value of Docker is intuitively obvious to the most casual observer. Other benefits need some explanation... On Linux (and on Windows, but that's not relevant here), every piece of software has all sorts of dependencies. The complexity of all these interlinking dependencies is so overwhelming that every Linux distribution needs a package manager to install software. Oh, of course you could ./configure;make;make install, but on software of even moderate complexity you'll spend an hour or so working out all the dependencies. This dependency complexity becomes a problem for three classes of people: