Het bedrijf achter Ubuntu bouwt ook deze verrassend nuttige ontwikkeltools

Als je "Canonical" hoort, denk je waarschijnlijk als eerste aan Ubuntu, 's werelds populairste cloudbesturingssysteem. Maar het in Londen gevestigde bedrijf heeft stilletjes een arsenaal aan open-source tools verzameld die de manier waarop ontwikkelaars software bouwen, testen en uitbrengen, hervormen. Van directe lokale VM's tot productieklare Kubernetes, Canonical's zijprojecten presteren ver boven hun gewichtsklasse. Deze diepgaande analyse verkent de drie verborgen pareltjes in Canonical's portfolio die elke frontend-ontwikkelaar, DevOps-ingenieur en systeemarchitect in zijn gereedschapskist zou moeten hebben.

Multipass: directe Ubuntu-VM's op elk platform

De vloek van het bestaan van een cross-platform ontwikkelaar is omgevingspariteit. Je codeert op macOS, implementeert op Linux en hoopt dat de CI-pipeline opvangt wat je lokale machine niet deed. Multipass elimineert deze wrijving. Het is een lichtgewicht VM-beheerder die met één terminalcommando een verse Ubuntu-instantie opstart. Geen Vagrantfiles, geen VirtualBox GUI, geen complexe netwerktoverij.

Multipass gebruikt native hypervisors – Hyper-V op Windows, QEMU op macOS en KVM op Linux – waardoor het aanzienlijk sneller is dan alternatieven op basis van VirtualBox. Opstarttijden zijn onder de drie seconden op moderne hardware.

Hoe Multipass beter presteert dan Docker voor pure Linux-workloads

Containers zijn fantastisch, maar ze delen de hostkernel. Wanneer je een echte Linux-kernelomgeving nodig hebt – voor het testen van kernelmodules, het uitvoeren van snaps of het gebruik van systemd – levert multipass een volledig besturingssysteem, geen opgedirkte proces. De CLI voelt native aan in moderne workflows:

# Start een VM genaamd 'dev-node' met 4GB RAM en 2 CPU's
multipass launch --name dev-node --memory 4G --cpus 2

# Voer direct een commando uit
multipass exec dev-node -- sudo apt update

# Mount uw host-projectmap in de VM
multipass mount ~/my-project dev-node:/home/ubuntu/work

Voor frontend-ontwikkelaars die werken aan server-side rendering of Node.js-backends is de mogelijkheid om lokaal te testen op een exacte replica van de productie-infrastructuur transformatief. Geen discussies meer over "werkt op mijn machine".

LXD: systeemcontainers die aanvoelen als VM's

LXD vervaagt de grens tussen containers en virtuele machines. Dit zijn "systeemcontainers": ze draaien een volledig init-systeem, hebben persistente opslag en gedragen zich precies als een zelfstandige Linux-server. Toch verbruiken ze veel minder bronnen dan een traditionele VM omdat ze de hostkernel delen. LXD is Canonical's antwoord op de vraag: "Wat als Docker een volledig besturingssysteem erin had?"

Praktijkworkflow: lokale microservice-architectuur

Stel je voor dat je een moderne webapplicatie bouwt met een React-frontend, een Python-API, een Redis-cache en een PostgreSQL-database. Met LXD kun je de volledige productietopologie lokaal modelleren:

# Maak een container voor de database
lxc launch ubuntu:22.04 db-server
lxc exec db-server -- apt install postgresql -y

# Maak een container voor de API
lxc launch ubuntu:22.04 api-server
lxc exec api-server -- apt install python3-pip -y

# Wijs statische IP's toe en koppel ze
lxc network attach lxdbr0 db-server eth0
lxc config device set db-server eth0 ipv4.address=10.0.0.10

Elke container krijgt zijn eigen netwerkinterface, firewallregels en bronlimieten. Je kunt netwerkvertraging, pakketverlies simuleren of zelfs de stekker uit een service trekken om veerkracht te testen.

LXD integreert native met cloud-init, wat betekent dat je containers kunt inrichten met dezelfde configuratiebeheertools die worden gebruikt in AWS, Azure en Google Cloud. Je lokale testomgeving komt overeen met je productie-infrastructuur tot aan de OS-pakketversies.

Juju: applicatiemodellering voorbij YAML-uitbreiding

Infrastructure as Code betekent typisch enorme YAML-bestanden en Bash-scripts die binnen enkele maanden onhoudbaar worden. Juju hanteert een fundamenteel andere aanpak: het modelleert relaties tussen services, niet alleen hun configuraties. Een Juju "bundle" is een declaratie van je volledige stack en hoe de onderdelen verbonden zijn.

Het Charm-ecosysteem automatiseert ops-kennis

Een "Charm" is een operator, een stuk code dat de operationele wijsheid encapsuleert van het implementeren en beheren van een service. Heb je een hoogbeschikbaar PostgreSQL-cluster nodig met automatische failover? Daar is een charm voor, onderhouden door database-experts. Het implementeren ervan is een enkel commando:

juju deploy postgresql --channel 14/stable -n 3
juju deploy my-django-app
juju relate my-django-app postgresql:db

De laatste regel is de magie. juju relate vertelt Juju dat je Django-app een database nodig heeft. Juju configureert automatisch PostgreSQL, maakt de database en gebruiker aan, en injecteert de verbindingsstring in de omgevingsvariabelen van je Django-app. Geen handmatige configuratie.

De kloof tussen ontwikkelaar en productie overbruggen

De echte kracht van Canonical's ecosysteem komt naar voren wanneer je deze tools samen gebruikt. Een veelvoorkomende workflow ziet er als volgt uit:

1. Ontwikkel lokaal met Multipass-VM's die overeenkomen met jouw doel-Ubuntu-versie.
2. Simuleer de volledige topologie met LXD-containers voor elke service.
3. Modelleer de implementatie met Juju-bundels die relaties en schaalregels definiëren.
4. Implementeer identiek naar elke publieke of private cloud, of bare metal.