Lets talk about Containers

So, lets talk about containers.

Lately, I’ve been spending quite a bit of my time trying to learn as much about containers as I can. Truth be told I don’t really like containers, for the most part I think they tend to add an unnecessary layer of complexity into my infrastructer and become just one more thing to firewall, patch, and maintain a separate lifecycle for. However, it seems that I am in the minority opinion regarding this technology so I’ve been making an honest attempt to learn about the various container technologies and see if I can apply any of it to my day to day activities. I am open to the possibility that, maybe, I haven’t put in enough work to gain an appreciation of Docker, or LXC, or Atomic, or CoreOS, or whatever other new fangled technology these young folk are into 🙂 To that end I’m hoping over the next few months to identify some portion of this site that can be moved into a container to find out what I’ve been missing! Who knows maybe I’ll find out I like containers.

Why the resistance to containers?

For me the problem really comes down to a few things. The main idea being that I don’t know enough about them to feel comfortable using them for anything that I even remotely care about.

1) I have far more familiarity and skill with traditional server and application architecture. I have yet to see anything that can be done with a container that can’t be done with a traditional application installation. So, why add additional risk with a new(ish) technology that I don’t know a whole lot about?

2) I think container technology is moving too quickly and has not yet matured to a point that I feel comfortable with it. I have resisted the urge to widely adopt Docker or other containers largely because I don’t think it’s a good idea to jump in with both feet if a technology is going to be changing so rapidly. For example it was not that long ago that persistent storage was a problem for containers. Apparently this is no longer the case, which is a good thing, but still illustrates how quickly things can change in this sphere.

3) Patching, firewalling, and locking down permissions on any one server is a daunting enough task. If a web server that hosted 10 websites is now split into 10 containers, what used to be a relatively simple task of patching an OS + Apache, now becomes patching a host OS, plus 10 different containers. To me this seems like more to manage, more to go wrong, more to overlook, and more risk than it’s worth. But again, as I learn more about Docker and LXC over the next couple months maybe I’ll find out that this assessment is incorrect.

4) In a large enterprise you have policies for everything. You might have a policy for servers that requires a monitoring agent to be installed, or a patching schedule that must be adhered to, or a password policy, or firewall requirements, and a bunch of other stuff. Unless you don’t plan to treat a container as a virtual server all of this would theoretically need to be enforced for containers as well. This is sort of a continuation of my complaints about complexity. But more than that, if a container is just a lightweight VM that is ephemeral, then I think we all need to be mindful to resist the urge to cut corners with security. Because of these non-technical problems, I tend to think that the time and effort to conform to these norms might make containers too expensive to be treated as ephemeral in the long run… and in that case why not just use a VM? (LXC seems to fit the bill nicely between an ephemeral container and a lightweight VM more on that in a later post).

So, what changed my mind?

Well nothing yet. I’ve made the decision to start evaluating containers based solely on the fact that they refuse to go away 🙂 and it will probably be important for me to understand them in the near future to stay up on my game.

Primary learning tools

How do I plan to get a deeper understanding of containers? A couple ways.

First, I have a subscription to Linux Academy (https://linuxacademy.com) and have been progressing through the LXC course. Linux Academy is great because you get a lot of instructor interaction in the help forums, they have excellent training materials, and you get 6 cloud servers to play with in a safe environment where you can break things as often as you want with no consequences!

I’ve started with the LXD course and I’m most of the way through it. LXD has been a great place for me to start because it seems like LXD/LXC containers follow a model that treats a container as if it were a small VM. This means that almost all of my current skill set can be applied to LXC, I just needed to learn a few core commands to find, launch, and interact with the container machines.

The second way I plan to become familiar with containers is by experimenting on this site! So if in the near future you come here and notice that it is broken you can take comfort in the knowledge that I am breaking things. I’ll share both my successes and failures (of which I’m sure there will be many) with you all as I go through this process.

In a follow up post I’ll share some of the things I like about LXD and how I think it can address some of the concerns that I’ve laid out here.

Luke has an RHCSA for Red Hat Enterpirse Linux 7 and currently works as a Linux Systems Adminstrator in Ohio.

This post, re-published here with permission, was originally published on Luke’s site here.