This blog is part of a series. Follow us on Twitter @ionCube so you don’t miss the next one!
Part 2 can be found here. The final part 3 can be found here.
The Problem
There comes a point when operating a virtual machine farm when you realise as the devs keep requesting a VM for this or that, there is only so much memory, CPU and disk space in the host machine.
That point arrived recently due to demands on resources for ionCube24 development and feature testing isolation. There had to be a stop on full-blown VMs for testing short term sub-projects as the hit on storage (and subsequent backups) and system performance was impacting operations.
After discussions with the devs it became clear that apart from the existing varied VMs that are used for cross platform support for the main ionCube Encoder/Loader, all the current requests are for very similar environments because they will eventually feed into the main server stack we use for ionCube24. Ah! We need some kind of virtualisation whereby the core remains the same but have segregation of application (features under test) and an associated server stack to test with.
The First Idea
First thoughts turned to Docker, you can’t avoid hearing the popularity of this container system, however I discounted it straight away. I remember playing with Docker a year ago and found it unsuitable for this particular situation. The reason for discarding was down to:
- it is really geared for single (or as few as possible) application packaging
- the data is best left external to the package so that a single or multiple containers can be spun and point to a common data source
- changes to the the container are incremental and frequent updates tend to bloat the image
- that then leads to pushing large files around the network
The Other Option
Instead I recalled another container based system from over a year ago which I found particularly appealing and would fit our situation better – LXC. This used kernel features that created what turned out to be sophisticated turbocharged root jails; mini virtual machines that used much of the host resources but segregated the process tree, and most importantly, the network stack. Ideal for creating small self-contained independent stacks.
The fact that the containers made use of the resources of the host such as the same kernel and architecture didn’t matter for this situation as the features under dev and test don’t make use of exotic features of the OS stack; this is pure application work.
So off I trot to take a look at LXC only to find a year down the line things have naturally advanced and LXD is the new LXC. Oh what joy I was to find there…
VirtualBox Icon courtesy of dAKirvy309. LXD Logo courtesy of Canonical Ltd.
