Another month, another Incus release! Incus 0.3 is now out, featuring OpenFGA support, a lot of improvements to our migration tool and support for hot-plug/hot-remove of shared paths in virtual machines.
The full announcement and changelog can be found here. And for those who prefer videos, here’s the release overview video:
Finally just a quick reminder that my company is now offering commercial support on Incus, ranging from by-the-hour support contracts to one-off services on things like initial migration from LXD, review of your deployment to squeeze the most out of Incus or even feature sponsorship. You’ll find all details of that here: https://zabbly.com/incus
Donations towards my work on this and other open source projects is also always appreciated, you can find me on Github Sponsors, Patreon and Ko-fi.
As has become a bit of a tradition by now, I’ll be attending FOSDEM 2024 in Brussels, Belgium on the weekend of the 3-4th of February 2024.
I’m once again one of the organizers of the containers devroom, a devroom we’ve been running for over 5 years now. And on top of that, will also help organize the kernel devroom. This is going to be our second year for this devroom after a very successful first year in 2023!
The CFPs for both devrooms are currently still open with a submission deadline of December 10th:
For anyone who hasn’t seen it before, you can try the Incus container and virtual machine manager online by just heading to our website and starting a demo session.
This gets you a dedicated VM on an Incus cluster with a bunch of resources and with a 30min time limit so you can either poke around for yourself or go through our guided showcase.
Now as neat as this is, it’s nothing new and we’ve been offering this for quite a while.
What’s new is that “Try a Web UI” link you can see alongside the console timer, click it and you’ll be getting into a web app that lets you play with the same temporary Incus server as the regular text demo.
What web UI?
Unlike LXD, Incus doesn’t have an official web UI. Instead, it just serves whatever web UI you want.
Part of that work was to also do some minimal re-branding, changing some links and updating the list of config options so it matches Incus. That’s handled as a series of patches that are applied during the package build.
How does it all work?
Now to get this available for anyone as part of the online demo service, some work had to be done!
The first part was the easy one, simply get the incus-ui-canonical package installed in our demo image. Those images are generated through a simple shell script, building a new base image every day.
With the package present and Incus configured to listen on the network, the next step was to add a bunch of logic to the incus-demo-server codebase. Each demo session is identified by a UUID. You can see that UUID in the URL whenever you start a demo session.
When a new session is created, a database record is made which amongst other things records the IPv6 address of the instance. Until now, this wasn’t really used other than for debugging purposes.
Now the easy approach would have been to just provide the IPv6 address to the end user and so long as they have IPv6 connectivity, they could just access the web UI directly. There are a few problems with that approach though:
Adoption rate for IPv6 is only slightly above 50% when looking at Incus users
The target web server (Incus) doesn’t have a valid TLS certificate
Authentication in the web UI requires a client certificate in the user’s browser
This would have made for a very high bar for anyone to try the UI, something better was needed. And so that’s where the idea of having incus-demo-server act as a SNI-aware proxy came about.
The setup basically looks like:
User hits https://<UUID>.incus-demo-linuxcontainers.org
Wildcard DNS record catches *.incus-demo.linuxcontainers.org and sends to HAProxy
HAProxy uses a valid Let’s Encrypt wildcard certificate to answer
HAProxy forwards the traffic to incus-demo-server on a dedicated port, keeping the SNI (Server Name Indication) value
incus-demo-server inspects the SNI value, extracts the instance UUID and gets the target IPv6 address from its database
incus-demo-server forwards the traffic to the Incus server running in the instance, using its own TLS client certificate for that connection
This results in the end user being able to access the web UI in their temporary instance with a valid HTTPS certificate and without needing to worry about authentication at all.
You can find the incus-demo-server side of this logic here.
I believe this turned out to be a very elegant trick, making things as easy as humanly possible for anyone to try Incus, letting them mix and match using the CLI or using a web UI.
As mentioned, there is no such thing as an official web UI with Incus, so we’re looking forward to getting some more of the alternative web UIs packaged and will be looking at ways to offer them up on the demo service too, likely by having the user install whichever one they want through the terminal.