Skip to content

Goodbye LXC-LXD, hello Docker & Kubernetes.

I’m finally ditching LXC / LXD in favor of Docker and K8s, but maybe not for the reasons you might be thinking…

LXC is still, in my opinion, the best container technology for Mautic, and also for most of the monolithic projects out there, which in the case of open source marketing and open-martech, it’s over 85% of the existing projects.

However, recent changes have occurred in the LXD world, Canonical decided to pull the project from the guys at Linux Containers, that have been developing and maintaining both LXC and LXD projects for many years and bring it fully in-house.

I do not have first-hand information about how this was done, but given the recent fork and how things have been going lately, I do not have the same level of trust I used to have in Canonical. At the same time, I am uncertain of what the new path for the fork, Incus will look like in a couple of years from now. I’m pretty sure I’ll be revisiting LXC, LXD and Incus over time, but for right now, it is time for a change!

Of course there are many other reasons, maybe even more important reasons to use Docker over LXC, however, for me, coming from OpenVZ and Proxmox, it really made no sense to move to Docker, when its father, LXC, was better suited for the task at hand, running Mautic.
In reality, LXD, which is, comparable in features to using Docker + Swarm, is a far superior technology when dealing with monolithic applications. That said, Docker and LXC are father and son and both can do exactly the same thing if you configure them for whatever specific purpose.

LXC is, as far as I know, the second-oldest container technology, after OpenVZ, it is rich, seasoned very powerful and stable.
Docker is the third generation of container technology, based on the same principles of “dad” and “grandpa”, but with a new and fresh view of the world, and with its sight focused on the datacenter and more specifically, the cloud.

LXD can run microservices, can be clustered, can auto-heal if you add a couple of scripts, etc…
Docker can run persistent applications, just like a system container would, if configured for that purpose…
So the underlying difference is in its spirit, in how you create the containers, LXC is meant to be a “System container” You launch it, log in, work on its contents…
Docker is meant as an Application (or even process) container, you create Docker containers with code…

So there is not a big difference? Well, there are significant differences, the main difference being, LXC containers are meant to be persistent, Docker containers are meant to be ephemeral, and from that unique differentiator, two entirely different philosophies drive the development of these 2 tools away from each other.

– LXD can now run virtual machines, Docker can not and probably never will.
– You can run Docker in Windows, Mac and others, you can only run LXC on top of Linux.
– LXD is a system container, you launch it like you would any other OS, you do your thing inside it, and it runs your software “forever”.
– Docker is a “Thread in a container” it is meant to run for a limited amount of time, die and, most of the time, resurrect somewhere else.

Differences between LXC and Docker containers

As a result,
– LXC containers are meant to be persistent.
– Docker containers are meant to be ephemeral.

– LXC containers are “launched and used”, then saved into an image, which you can make multiple copies of.
– Docker containers are “created with code”, then brought up from its lesser parts (layers).

Not the full story, but you could say LXC containers are more on the static side, while Docker containers are more on the dynamic side. You can, with very few exceptions, accomplish the same with one or the other, however Docker has some trouble keeping its state and LXC lacks the amount of flexibility Docker can offer.


What is LXD?

The success of Docker impulsed this new idea of refreshing the old “Linux Containers” (LXC), and they did it with a wrapper API, that is LXD, brilliant!

LXD is to LXC what Swarm is to Docker, it helps manage multiple containers, facilitates networking, helps with clustering, and so on, just as Swarm does not bring the most advanced features that Kubernetes has, LXD also does not help with these, out of the box.

Hence, not because Docker is better, not because LXC is obsolete, I am in the process of moving from LXC to Docker, the switch will be completed about when Mautic 5 is ready for production, a few months from now.

But because of political reasons, it is time to move away from Canonical, Ubuntu and LXD, and while I love the idea and the people behind Incus, to me, Docker is the obvious future-proof choice and the one container technology that, while maybe not as good as LXC for Monolithic apps, is clearly tha path to the future, a future which is clearly made of Microservices, Serverless and Event-driven, yes it might need a few more years, but it is clearly the path of the future, so here we go!!!

What about Kubernetes?

I still believe K8S is a complete waste of time and resources for running Mautic, K8s is meant to run microservices, and Mautic, no matter how much “separation of concerns” you throw down its throat is a rock solid MONOLITH, and K8s will only make it go slower. Prove me wrong!
However, given the choice between Swarm or Kubernetes, I will probably be using more and more of the latter over time…

Additionally, seeing the political, ethical and technical turbulence in the Mautic community, after it was “left free” from Acquia, I have decided to diversify, meaning chasing other possible income sources, mainly running and servicing other open-martech apps, while most of them are monolithic still, and very few of these are microservice-based, a bunch are native to or moving towards a modular architecture which, while far from being microservice-based, some use modern technologies and paradigms, amongst them, Docker and K8s.

Yosu Cadilla

My name is Yosu Cadilla, a Systems Analyst and Platform Engineer for mktg.dev
I discovered Mautic in 2017 and since have specialized in:
– Running Mautic for Marketing Agencies.
– Running large Mautic instances, sometimes
with millions of contacts.
– Helping companies build and optimize their (usually Mautic) runtime infrastructure.

If you are planning on deploying Mautic for your Marketing Agency, or you have a large Mautic Instance…
Let’s have a chat! yosu.cadilla@gmail.com