Quick notes in Docker in relation to LXC.

Docker is a front-end single application virtualization engine based on OS level virtualization. Docker started with LXC (Linux Containers) , but what is exciting here,

• Portable - single file (I believe)
• Low overhead - should run inside of my Ubuntu KVM
• Has become cross-platform (in a sense) 
• Works with the vanilla Linux kernel (no patching).

Unlike LXC containers Docker containers do not behave like lightweight VMs and cannot be treated as such. Docker containers are restricted to a single application by design. The under the hoods but since version 0.9 switched to it's own libcontainer as the default virtual engine.

The two technologies appear to have similar functions. Initially I had a hard time wrapping my head around why to use Docker over LXC which to me is much more flexible and I don't lose ssh access. However, interestingly enough as I used LXC more, I started to appreciate the spirit of Docker's approach to being so restrictive. From the view of writing applications and operating them:

• Ephemeral - Being stateless you build must externalize the right things (logs, application property files) from day 1.
• Single Process as Best Practice - I lose SSH access, but I then stop thinking of stacks (OS, Java, JEE Server, Application Code) and instead of a single package.
• No Upgrading, Just Rebuilt - Day 1 you script your application and OS. Why upgrade, update your script and automate from day 1.

It's a fundamental mind shift. If forces both Ops and Developers into a repeatable automated approach to building servers and coding applications. This shifts work instead to using good orchestration software (which I am in process of researching). The Docker base OS template is pared down to a single app environment and does not have a proper init or support things like endorse an init, services, daemons, syslog, cron or running multiple applications. (from http://www.flockport.com/lxc-vs-docker/ - this can be explained and worded better?). In addition Docker containers are ephemeral as your only option. Unlike LCX which is an option, "lxc-start-ephemeral".

See my hosting page for Virtualization technologies.

However, after a bit more reading this all seems very limiting, but I this is by design. If forces both Ops and Developers into a repeatable automated approach to building servers and coding applications. This fundamentally shifts how we manage servers and application containers.... now we think in terms of orchestration of operating systems, containers and code as one singular unit.

In fact, it seems that Docker has great marketing that overshadows LXC. In order to compete, Ubuntu has built out LXD which is a simpler front-end to LXC.

I've taken a look at LXD,

• It has the same core team from LXC is behind
• At the core this is all still LXC
• Provides API for higher level orchestration of Containers

Bottom line, LXC is what I've been doing in Solaris Containers but for Linux.

References

That's why this article is in relation to and not versus.

Which one to learn first? If you want to really understand things, learn LXC and you'll know Docker. It's like starting with DOS then learning Windows.

References

See my hosting page for Virtualization technologies.

LXC vs Docker - http://www.flockport.com/lxc-vs-docker/

...