The headline from the docker website is a pretty good summary:
Build, Ship and Run Any App, Anywhere.
Docker – An open platform for distributed applications for developers and sysadmins.
On the “What is Docker” page, is a bit more information, but still in marketing speak:
Docker is an open platform for developers and sysadmins to build, ship, and run distributed applications. Consisting of Docker Engine, a portable, lightweight runtime and packaging tool, and Docker Hub, a cloud service for sharing applications and automating workflows, Docker enables apps to be quickly assembled from components and eliminates the friction between development, QA, and production environments. As a result, IT can ship faster and run the same app, unchanged, on laptops, data center VMs, and any cloud.
So, creating a docker image is similar to creating a virtual machine but it’s more lightweight as it runs within a linux environment, so it can allow that environment to handle things like device drivers and the like. Docker does this by combining a lightweight container virtualization platform with workflows and tooling that helps manage and deploy applications.
At its core, Docker provides a way to run almost any application securely isolated in a container. The isolation and security allow you to run many containers simultaneously on the host. The lightweight nature of containers, which run without the extra load of a hypervisor, means you can get more out of your hardware.
Its also like a version control system for any changes that are made to the docker image whilst it’s being built. This allows efficient management of the Docker images. If we have a Docker image that just has a Java installation on it, and we next build two new images, one with Tomcat and the other with Apache HTTPD, then they can both reference the same base Java Docker image, and the new images will only have the changes above the base Java image.
A Docker container consists of an operating system, user-added files, and meta-data. Each container is built from an image. That image tells Docker what the container holds, what process to run, when the container is launched, and a variety of other configuration data. The Docker image is read-only. When Docker runs a container from an image, it adds a read-write layer on top of the image (using a union file system) in which the application can then run. Unless those changes are saved outside the Docker image (like shared drives for Virtual Machines), or the Docker image is “committed” once it’s finished, those changes are lost when the container closes.
What our Docker strategy?
So how will we use Docker within our Project? Initial efforts are on producing repeatable testing environments for QA, using one docker container, running one docker image, per component. This is an accepted standard for docker containers, so that’s one container for Tomcat running the public facing web interface, one for Tomcat running the ESB, and one for the caching services, one for MongoDB, and, well you get the picture.
As an aside, as the Docker runtime provides a REST interface we can do clever things in combination with GIT hooks. For example, if we commit a new feature branch to the central repository, we’d need somewhere for QA’s to test the new features separate from the main development branch QA environment. Using GIT hooks to let us know when a new branch has been created, we can create a new set of docker containers running the whole of the application, so that QA can test the new features. Once the branch has been merged back into the main development branch, these new containers can be archived, and torn down.
Various Docker container can be link together using Docker compose. Docker compose is nice tool, which have intuitive way of defining your multi-container application with all of its dependencies in a single file. Entire application can be spin up within the docker host using command line
This leads naturally onto to deploying into Linux environments, and into cloud based environments such as Amazon Elastic Compute Cloud (EC2), and Azure, both of which support Docker out-of-the-box.
Currently, we haven’t doing our development using Docker, due to fact vexing process of setting up the development. Currently it’s a bit clunky to get Docker running on Windows, which involves the use of a Virtual Box running TinyLinux, which in turn runs the docker runtime, and hence the containers. There is only one share available between the host Windows environment and Virtual Box that is accessible from within the docker runtime, and that’s on a fixed path. Plus, remote debugging needs to set between the machines.
One hack would be to setup dev environment in the single container with our fav IDE, code and symbols in one box, but this won’t go the long way for the next stage deployment.
There is a lot of hype around Docker, and every man and their dog aspires to include Docker in their product descriptions, whether it makes sense to do so, and whether they have a product rather than a set of loose documentation and a variety of aims.
Microsoft is a case in point. They have stated that they will support Docker in the future, but what isn’t widely reported is that they will only support Windows Docker images – it won’t run the tens of thousands of linux based docker images. For anyone old enough, Windows NT used to have a POSIX subsystem, so somewhere that code must still exist….
Another area that promises much, but delivery can vary is the area of value-add on top of Docker, in areas such as clustering, distributing and monitoring of Docker containers. The two solutions for enterprise level distributing services and applications, Chef and Puppet, were quick to deliver solutions around Docker.
On a smaller scale there are products such as ShipYard for monitoring Docker containers, but a lot of the functionality is still on the horizon. The Docker team have several interesting side projects that are in differing stages of completion:
Compose: Compose is a tool for defining and running complex applications with Docker. With Compose, multi-container applications are defined in a single file, then the application spun up in a single command which does everything that needs to be done to get it running.
Swarm: Docker Swarm is native clustering for Docker. It turns a pool of Docker hosts into a single, virtual host. Swarm serves the standard Docker API, so any tool which already communicates with a Docker daemon can use Swarm to transparently scale to multiple hosts. It ships with a simple scheduling backend out of the box, and as initial development settles, an API will develop to enable pluggable backends. The goal is to provide a smooth out-of-box experience for simple use cases, and allow swapping in more powerful backends, like Mesos, for large scale production deployments. Currently in beta, not ready for production.
Running Docker locally on Windows (and Mac), then boot2docker is a must, which can be found at: http://boot2docker.io/.
There are a couple of interesting videos on YouTube which introduce Docker and give a few real world examples: Introduction to Docker and A 3 hour introduction and real world examples (3 hours!!)