Docker Container Basics: An Operations Guide, Part 1 of 3

Docker containers crash into the enterprise…

In the last three years Docker containers have become synonymous for containers and are often confused for some kind of über machine virtualization. By its own admission Docker is trying to make the lives of developers easier with these containers but… has this translated to a simpler environment for techops? The jury is still out on that question nevertheless, the most obvious gap for techops is generally still a knowledge gap.

In fact as soon as the subject of Docker comes up the marketecture starts to fly and phrases like Google infrastructure, infrastructure as code, continuous deployment and DevOps are soon to follow but none of it really spells out why operations should adopt containers. For those not initiated in the philosophies of Gene Kim, Martin Fowler, and the brotherhood of Googlers these oft uttered phrases leads techops to ask why is this better than the virtual infrastructure they already have. If your techops team is proactive then they will try to get in front of this Docker thing and will try to mold these containers into the überVM or maybe just try using them as a stand in for an on premise “ami”.

While spending the last 2+ years training and consulting for organizations who are adopting Docker into their ecosystems I have witnessed all these reactions from techops and more. So with Docker making this year’s theme one of expanding their ecosystem into the “enterprise” I thought it would be useful to go back to the basics for those techops teams that want to catch the wave before it crashes over them. This three part post will spell out why operations should use containers, how to get going with a test bed of your very own, and how operations can participate in the containerization process.

So why containers?

So let’s get to where the noise around containers is coming from to help us understand why you too might want to use them. In a word “DEVELOPERS” or more precisely impatient developers with tight deadlines. The average enterprise today has some form of private cloud that is often sold as “AWS-like”. The reality is that unlike AWS where the provisioning process only takes a couple of minutes (yes! this is the off books experience)… in the private cloud, thanks to the middle management bureaucracy, this can often take weeks. Now that the bean counters are getting wise to developers side stepping IT by expensing some AWS time, they are trying to kill it. So what is a “poor developer” to do when he needs to prototype an application that needs a mysql database, redis key value store, and an ELK stack; oh and his manager wants it ready by end of week. This is where Docker steps in and gets him going in a matter of minutes with no need to bother IT. Let’s break this down:

1. Docker LOVES developers and has dumped a ton of cash into making the consumption of the Docker platform as easy as using an iphone app. They know developers mostly use Mac and Windows laptops and have produced packages that works natively on either platform with the execution of a single download: Get Docker for your laptop
2. Docker Hub, get to know it. This is basically the free app store for developers building applications using popular open source applications! The commercial version coming soon.
3. Docker containers are basically self assembling services that run anywhere that the docker engine will run.

That’s right self assembling services with a single command or one-click of a GUI. That means no more need to wait for some techops guy to configure an instance to provide some service they need to develop against and more importantly these services are version controlled and immutable!

How does this make life simpler?

Imagine never having to check if all the dependencies for an application you’re deploying have been installed. Or maybe you want the ability to launch a hundred applications in a fraction of a second. How about an immutable toolbox that will run on any linux flavor with the best version of the tool you like! Mastering Docker containers can put you on a path to worrying more about the improvement of the application services you deploy than in how to deploy them. That’s the promise of Docker and it has begun to show techops the LOVE by dumping a ton of dollars into making containers in production as painless as they are in development. I can feel the eye rolls already …and this is better than VMs, how?

• Containers are full functioning, self deploying, services that developers maintain
• The method of creating of Docker containers is repeatable, reusable, documented, and highly automated
• If you’re tasked with implementing linux containers then the Docker image format is the gold standard
• The tool sets being created around containers lend themselves in shifting from downtime deployments toward continuous deployments

At the end of the day containers aren’t “better” than VMs …nor are they a stand-in replacement for them. However, there are many business conditions driving the need for faster deployment of applications and features into production to meet business and customer needs. The innovation to meet these needs are being invested into containers and the tools that support them. Since Docker containers are synonymous for containers that investment is creating a wave behind Docker that is changing how applications will be deployed. You can choose to either ride it or be drowned in it.