Skip to content

Services, Servers, DomUs and Containers, Oh My!

  • by

What a tangled web we weave…

I was confused. Staring at a console window, wondering how I’d installed a program. The system package manager knew nothing about it, pip pretended like it never heard of it, and I hadn’t downloaded and compiled the source.

I’ve never really had what anyone would call a sane management approach to my servers and services. The closest I’ve got is using Xen as a hypervisor and trying to separate DomUs (VM guests) by service type, backed by LVM-on-mdraid storage*. That sounds alright in theory, but in practice most services have tended to congregate on the largest guest, turning that DomU into a virtualised general purpose server. A server that mixes and matches the system package manager, other package managers like pip, SteamCMD and manual installs.

Pug fugly, in other words.

Pug-fugly, as coined in Pgymoelian

* the storage also sounds good in theory but the implementation has led me to dub the machine the ‘Frankenserver’ (more on that another time)

This is fairly typical. You need to do X. Not only that, but you need to do it RIGHT NOW. Software ABC does that. So you download it from whatever source seems most convenient and up-to-date, glance at the ‘Quickstart guide’ (while saying thank goodness for those!), do a bit of minimal configuration and then you’re up and running, doing X.

But what’s the big deal? The service[s] work, after all.

The issue is a general one: it takes time to figure out the setup before you can usefully interact with it.

This doesn’t just apply to DevOps; but to coding, writing, maintenance and repair, DIY, cooking, house management.

Or more simply: Fail to plan, plan to fail.

I found that it was taking me time to get my head around:

  •  what I was dealing with
  • how it had been set up
  • why it wasn’t working
  • how to fix it
  • how to update it

I’d do those things, sort whatever, get the service working again, then six months later I’d have to figure it all out again.

“What a way to run a railroad…”

Clearly, there must be a better way.

In fact there are several better ways, depending on what you want to do. DevOps is huge business, and scales into the multinational megacorp range. But the home user can benefit too. There are clear benefits in using a well-organised system for pretty much anything, and managing servers, services and other applications is no exception. Used well, maintainability, security, reliability are all enhanced.

But how does one get started? There are plenty to choose from. Some folks I know love Docker, others opt for LXD on LXC (those options are not exclusive). There are also the configuration management tools, like Puppet, Ansible, Chef (etc).

Well, I briefly used Docker in the past, and now have it on one of the DomU guests, hosting a few services I used to run elsewhere. This seems like reason enough to dip my toes deeper in the waters and move more services to containers, or at least to automated processes.

It’s rarely glamorous, but writing good documentation can make a huge difference to the person that follows you. Even when that person is you.

As an aside, the other key ingredient other than having good systems in place is to have good documentation.

For example, before writing this up I wondered about installing a new spam plugin. I used to use Spam Karma 2, but that’s been unmaintained for a long while. But which one? Well, seems I’ve used Akismet and Anti Spam Bee in the past, but why did I stop using them? I have a vague recollection of the former re-moderating old comments and declaring them spam, and the latter not working in some way, but what?

Good documentation, make it your non-New Year’s Resolution.

So the take-home message here is that ad-hoc setup pop up and stick around for longer than they should; don’t do that, have a good system instead and document what you’re doing and why.

Because it’s good to have a goal, my aim is to get low-hanging fruit services moved over to Docker in the first instance (heh) to learn more about the tech. Fore there I can decide what I can move to containers, and maybe even see if LXC would fit my needs anywhere. I’d also like to see if I can apply this to the wee tools I write myself to help automate my workflows- rather than running them manually, perhaps I can develop them as services. And while doing all of this documenting what I am doing and why.

Then maybe one day I won’t have to ask “I have a (python-based) program installed that doesn’t seem to have been installed either by apt or pip, and obviously I can’t remember… is there any way to figure out how I actually installed it? :D”.


beets, for music library organisation/tagging/management

Featured image by steve gibson on Flickr

Tell us what's on your mind

Discover more from Rob's Blog

Subscribe now to keep reading and get access to the full archive.

Continue reading