Docker is a new technology, on which, we are building some of our newer distributed systems and services. You may say to yourself, "Another new technology?" and the answer would be yes. I thought the same thing. Why adopt another new thing when we haven't finished flushing out the older thing. The hope is, that with enough buy-in this wouldn't be just the next thing. I want to describe the parts of Docker that took me some time to understand and then talk about some of the ways this helps developers.
Docker is based on the idea of shipping containers. You know, the big metal things that we always see on boats (In movies at least). Prior to the invention of standard shipping containers it was a huge hassle to load a barge. I'm sure it was like an expensive version of Tetris but with an infinite number of shapes falling from the sky. By putting things in identically shaped boxes the shipping industry was revolutionized.
There are a few terms for things that have an established hierarchy.
Container
+------------------------------+
| Image |
| +---------------------------++
| | Filesystem Layers ||
| | +-----------------------+ ||
| | |-----------------------| ||
| | |-----------------------| ||
| | |-----------------------| ||
| | |-----------------------| ||
| | |-----------------------| ||
| | +-----------------------+ ||
| | ||
| +----------------------------|
+-+----------------------------+
A container wraps an image which contains a series of filesystem changes as
layers. The first layer in an image is normally a base OS like Ubuntu or
Debian. Then, each layer afterwards is the result of running a command like
apt-get update on the previous layer. Normally an image is created using
a Dockerfile. A Dockerfile is a set of instructions used to build an image
by running a series of commands.
Great question. Think about the application or service that you are working on. If you could describe a shape to represent your app it may be shaped like a Bugatti or it could be shaped like an elephant. Either way, it may not be shaped like other apps that do some of the same things. Could you imagine trying to drive an elephant the same way as a Bugatti. Somebody would be let down. Likewise, it's easier to deploy and manage apps if they are all shaped the same. Docker is the container that abstracts the shape of your app. This allows developers to build an infrastructure to host, deploy and manage your apps in an efficient way. We can build one tool that knows how to handle a container shaped app instead of customizing our tools for Bugatti and elephant shapes. It also allows you, as a developer, to take advantage of other people putting similar things in containers already. They figured out how so you don't have to.
Yes, We are all unique. Docker allows you to build a tree-shaped service within a standard container. That way, you can get the infrastructure, monitoring and deployment benefits that all other containers get.
Convincingly, it seems like it but it is actually based on a technology that ships with Linux. A few things like it have been around for a while.
My previous arguments should be enough, but if you are not easily swayed then I have some more things that I really enjoyed while learning how to work with docker.
- Containers can be easily shared and replicated once packed
- In order to pack a container you have to document it
- Containers make it obvious when your app has external dependencies at runtime
- Containers strongly encourage well defined interfaces (there's only one door on every shipping container)
- Multiple instances of containers have complete parity
- Many containers have already been built so we can just add our code and say "Go!"
I recommend you read about Docker at their website or look at a few of the docker projects that are currently in progress. I plan on writing more about best practices and gotchas that I ran into while learning and building a service in Docker.