When to choose an LXD Container vs native Linux server install

There is a general trend in IT technology these days to solve every problems using docker containers running under Kubernetes. I am using a different kind of container technology called LXD. It was created by Canonical, the Ubuntu people. LXD is really just LXC version 2.

LXC Version 1 is the original Linux Containers technology, and it works, and is great and all that, but think of LXD as an enhanced LXC with the best parts of using Docker, like image repositories. LXD Containers appear to work as if they were virtual machines, but they benefit from being native processes on the host Linux kernel. Zero hypervisor overhead. A few key system resources were virtuallised, so now every container gets it’s own little access window into the shared host’s Linux Kernel.

My home server currently runs a bunch of services, a few for internal use only, some in LXD containers, others native. The list includes:

  • AUTHENTICATION SERVER
  • CHAT SERVER
  • WEB SERVER
  • EMAIL SERVER
  • EMAIL ANTI-SPAM
  • EMAIL ANTI-VIRUS
  • DNS SERVER
  • DATABASE SERVER
  • LOG SERVER

Not very long in the past, I would have wanted to isolate each service in it’s own LXD container, and use IP:port numbers to connect them together. But that just ended up creating lots of containers, and lengthy and sometimes tricky software upgrades. It also complicates backups. For awhile I tried going old school, with everything running native. But now, I’ve ended up with a mix of both native and LXD.

LXD containers also make good test environments. You can install any version of any package you need to try out, and if it turns out you don’t need it, no problem. You’re just going to start over in a new LXD container with the same in in 10 seconds. You should be building a recipe to re-build a appserver image from base image on up anyway. That’s your DR plan, to be able to rebuild it, restore data and config files from network backups, and be back up in business in an hour.

LXD containers are mostly more like “pets”, and less like “cattle”. You name them, you try to fix them when they’re broken, and you make an effort to keep them alive. The modern devops way requires you simply kill off any ill functioning container, and re-launch the image it’s based on. It’s your upgrade policy, your DR policy, your reboot policy.