The premise of Docker ;
Docker allows you to package an application with all of its dependencies into a standardized unit for software development.
Or with a bit more words ;
Docker containers wrap up a piece of software in a complete filesystem that contains everything it needs to run: code, runtime, system tools, system libraries – anything you can install on a server. This guarantees that it will always run the same, regardless of the environment it is running in.
So what is the difference with plain virtualization? You strip the hypervisor “emulation” layer and do not deploy individual operating systems…
From an operations/infrastructure point of view it is a bit of mix between application virtualization & virtual machines. The technical base is “containerization”, which is an operating system level virtualization. This is not something new in IT land, as I recall it was the way virtualization was done in the hosting world before VMware (and equivalents) came to rise. So where is the difference? For me… in the ecosphere that was created around the technology!
Docker, docker, docker, … and more docker?!? The docker toolbox!
Docker to me is more than the docker engine… So let us dive into the different tools that you can use to enhance your deployments.
- Docker Engine : At the core of the Docker platform is Docker Engine, a lightweight runtime and robust tooling that builds and runs your Docker containers. Docker Engine runs on Linux to create the operating environment for your distributed applications. The in-host daemon communicates with the Docker client to execute commands to build, ship and run containers.
- Docker Machine : To get started with Docker, first you need to setup a Docker Engine. Docker Machine automatically sets up Docker on your computer, on cloud providers, and inside your data center. Docker Machine provisions the hosts, installs Docker Engine on them, and then configures the Docker client to talk to the Docker Engines.
- Docker Registry : Docker Registry is an open source application dedicated to the storage and distribution of your Docker images. Its seamless architecture allows both for fine grain integration with other systems and high-level scalability. Aggressively developed, its vibrant community includes industry leaders and users using it at the core of their images distribution solutions.
- Docker Swarm : The nature of distributed applications requires compute resources that are also distributed. Docker Swarm provides native clustering capabilities to turn a group of Docker engines into a single, virtual Docker Engine. With these pooled resources, you can scale out your application as if it were running on a single, huge computer.
- Docker Compose : Distributed applications consist of many small applications that work together. Docker transforms these applications into individual containers that are linked together. Instead of having to build, run and manage each individual container, Docker Compose allows you to define your multi-container application with all of its dependencies in a single file, then spin your application up in a single command. Your application’s structure and configuration are held in a single place, which makes spinning up applications simple and repeatable everywhere.
So how does that look in reality?
A full scenario would go as following ;
- Use docker machine to roll out several hosts with the docker engine installed
- Put the docker engines into a swarm to provide with one logical resource pool with high availability features.
- Use docker compose to design your solution blueprint.
- Whilst deploying this blueprint (compose) to your cluster (swarm), you retrieve the various images from the registry (typically docker hub).
Are there any gotcha’s
Offcourse there are! It wouldn’t be a field of technology if there werent… 😉 From my (limited) experience, you have to watch out with networking & permanent storage.
You have several options in terms of networking… Yet as an infrastructure / operations minded person, you will soon see pitfalls in possible deployment methods. The most basic deployment is (roughly translated) a NAT-deployment.
For storage you should consider a container as volatile (“cattle“). Where you should be sure to store your persistent data on “volumes“. They are saved on your local system, and/or can be mapped directly to your host file system too (if needed). At this moment I’m more in favor of the latter. Where the mapped directory is then even stored on a shared file system.
Performance… The typical nightmare of all operations guys! For me, Docker does not care too much for this out of the box. So be wary to keep this in mind when you are designing your solution. It is meant to be volatile & local, which in turns benefits a true “scale out” mechanism. So it enforces a different mindset than which is traditionally brought to the table. Also be sure to implement monitoring systems to
Docker is a containerization technology with a lot of supporting tools to make life easier. For me it’s here to stay, though we should be aware that there are still a lot of considerations from an infrastructure / operations point-of-view.