Ever since discovering Docker, I've been a huge fan of the whole concept of containers and how they separate concerns.

Up until recently, I always saw a container as a "container", and did not understand that Docker is very specific about what they interpret a container to be. Then 1 day, I wished to try to install a bunch of different applications to get a mail-server running (namely: Postfix, Dovecot and Roundcube).

Much to my dismay, I discovered that it was a real PITA to install these things into a single Docker container. Digging deeper into my issues, I was led to the discovery that Dockers philosophy is driven by the whole "micro-services" concept. What this means is that Docker views each container as something that does a single process and a single process alone. You can make the process as big (or small) as you wish, but the goal of this philosophy is to encourage small services vs. a monolith (or so I interpreted it as that). Think about it as: confining your single search box into its own process vs. the big box of bad that is "WordPress, Apache, MySQL and PHP combined".

Well things weren't going too great, so after wrangling lots of minds on #Docker and asking a few friends/colleagues via various mediums, it was brought to my attention that perhaps LXC would be a better option for what I wished to do. I could dump entire monoliths into LXC and that would be fine.

During my research time, I also found this really cool infographic (with detailed article) that everyone learning about containers should see:

Flockport: Docker vs. LXC

Being able to understand this fully will probably save you (and likely myself) lots of headaches in the future, especially as we all move to the containerized world in 2016 and beyond. Just like many developers out there in the far reaches of the world, I am but a small fry. I used to use Docker as a drop-in replacement for virtualenv for separating my Python projects. This did work reasonably well, but when I decided that I'd like to get my Postfix/Dovecot monolith up, the not-so-obvious warts crept in. I'm no Google/Amazon and I can probably get by with 98% of my projects being monoliths. The micro-service architecture also adds a level of complexity that turns the 1-man coder into a certified devops/sysadmin that needs to understand a lot of important things on that devops/sysadmin level.

From a security point-of-view, if you don't get things right with Docker containers, you can/will probably shoot yourself in the foot (when containers were meant to protect you from shots in the first place).

So what is this LXC thing?

I don't (and probably can't) go into too much detail about the technical workings of LXC. Simply put, LXC is the (apparent) daddy of the container eco-system. In fact, I don't think words can ever explain it as good as the infographic above, so please go look at it again.

Docker has an interesting relationship with LXC. It was built on top of it (with the micro-service philosophy in mind), but I have since heard/read that they have moved away from LXC (on some level I assume).

When I first heard that Docker was "built on top of LXC", my first reaction to it was on a level similar to that of people saying "I built a layer on top of the C API", indicating that a major layer of complexity was taken out of the equation (C code is C code afterall).

Fortunately for the 1-man-coder, wordpress-hackers, beginner-coders and more, LXC is not as complex as you might think it could be (and it definitely was not the nightmare I thought it would be - thinking I'd need to write C/other-boilerplate-code just to build/run containers). I even noted down a few commands to get the basics working, and the total of these commands came to: 7

With these 7 commands, you can: create, start, stop, attach (get into), info (get properties), destroy and "ls" (get a full list of all containers)

Once you get your first LXC container going though, it starts to feel a lot more like regular Linux/Ubuntu, compared to Dockers opinionated way of doing things.

The only terrible/difficult thing so far has been to attach a host filesystem to an LXC container (which took a day or 2 to figure out), but LXC seems more in tune with my current needs as a tinkerer/programmer/1-man-coder.

Is it already time to start bashing Docker yet?

Not at all. Docker has its place and it will be used a lot at many different places. The only problem I personally see is the "bandwagon" issue. A lot of people are trying to get into containerization without fully understanding Dockers philosophy ("micro-services architecture").

That infographic I linked to above explains things a million times more clearly than the wads of text I had to read through (whilst learning about containers since a year or 2 ago).

Just remember that: micro-services are based on an architectural decision to address the issues at a Google/Amazon level

This blog, a drop-in for virtualenv for Python environments or your dads WordPress business-site probably don't need a Docker container (and some would argue that they probably don't need any containerization - LXC included - at all).

Moving forward, I will be (and have been) learning/using LXC as my go-to for containers.

In part 2 of this 2-part blog, I will do a basic walk-through of installing LXC, creating a bare/minimal container(Ubuntu) and then slapping an example Python library/software (possibly Pelican, Twisted or some other library) onto a container built on top of the bare/minimal Ubuntu container.