Das Unternehmen hinter Ubuntu entwickelt auch diese überraschend nützlichen Entwickler-Tools

Wenn Sie „Canonical“ hören, denken Sie wahrscheinlich zuerst an Ubuntu, das weltweit beliebteste Cloud-Betriebssystem. Doch das in London ansässige Unternehmen hat im Stillen ein Arsenal an Open-Source-Tools zusammengestellt, die die Art und Weise verändern, wie Entwickler Software bauen, testen und ausliefern. Von sofort einsatzbereiten lokalen VMs bis zu Kubernetes in Produktionsqualität – Canonicals Nebenprojekte spielen weit über ihrer Gewichtsklasse. Dieser Deep Dive untersucht die drei versteckten Juwelen im Portfolio von Canonical, die jeder Frontend-Entwickler, DevOps-Ingenieur und Systemarchitekt in seinem Werkzeugkasten haben sollte.

Multipass: Sofort einsatzbereite Ubuntu-VMs auf jeder Plattform

Der Fluch der Existenz eines plattformübergreifenden Entwicklers ist die Umgebungsparität. Sie programmieren auf macOS, stellen auf Linux bereit und beten, dass die CI-Pipeline abfängt, was Ihr lokaler Rechner nicht erkannt hat. Multipass beseitigt diese Friktion. Es ist ein leichtgewichtiger VM-Manager, der mit einem einzigen Terminalbefehl eine frische Ubuntu-Instanz startet. Keine Vagrantfiles, keine VirtualBox-GUI, kein komplexes Netzwerk-Hexenwerk.

Multipass nutzt native Hypervisoren – Hyper-V unter Windows, QEMU unter macOS und KVM unter Linux – und ist damit deutlich schneller als VirtualBox-basierte Alternativen. Die Bootzeiten liegen auf moderner Hardware bei unter drei Sekunden.

Wie Multipass Docker bei reinen Linux-Workloads übertrifft

Container sind fantastisch, aber sie teilen sich den Host-Kernel. Wenn Sie eine echte Linux-Kernel-Umgebung benötigen – zum Testen von Kernel-Modulen, zum Ausführen von Snaps oder zur Verwendung von systemd – liefert Multipass ein vollständiges Betriebssystem, keinen verkleideten Prozess. Die CLI fügt sich nahtlos in moderne Workflows ein:

# Launch a VM named 'dev-node' with 4GB RAM and 2 CPUs
multipass launch --name dev-node --memory 4G --cpus 2

# Execute a command directly
multipass exec dev-node -- sudo apt update

# Mount your host project directory inside the VM
multipass mount ~/my-project dev-node:/home/ubuntu/work

Für Frontend-Entwickler, die an Server-Side Rendering oder Node.js-Backends arbeiten, ist die Möglichkeit, lokal auf einer exakten Kopie der Produktionsinfrastruktur zu testen, transformativ. Schluss mit den „Bei mir funktioniert es“-Debatten.

LXD: Systemcontainer, die sich wie VMs anfühlen

LXD verwischt die Grenze zwischen Containern und virtuellen Maschinen. Dabei handelt es sich um „Systemcontainer“ – sie führen ein vollständiges Init-System aus, verfügen über persistenten Speicher und verhalten sich genau wie ein eigenständiger Linux-Server. Doch sie verbrauchen weit weniger Ressourcen als eine herkömmliche VM, da sie sich den Host-Kernel teilen. LXD ist Canonicals Antwort auf die Frage: „Was wäre, wenn Docker ein vollständiges Betriebssystem im Inneren hätte?“

Praxisbeispiel: Lokale Microservice-Architektur

Stellen Sie sich vor, Sie bauen eine moderne Webanwendung mit einem React-Frontend, einer Python-API, einem Redis-Cache und einer PostgreSQL-Datenbank. Mit LXD können Sie die gesamte Produktionstopologie lokal abbilden:

# Create a container for the database
lxc launch ubuntu:22.04 db-server
lxc exec db-server -- apt install postgresql -y

# Create a container for the API
lxc launch ubuntu:22.04 api-server
lxc exec api-server -- apt install python3-pip -y

# Assign static IPs and link them
lxc network attach lxdbr0 db-server eth0
lxc config device set db-server eth0 ipv4.address=10.0.0.10

Jeder Container erhält seine eigene Netzwerkschnittstelle, Firewall-Regeln und Ressourcengrenzen. Sie können Netzwerklatenz, Paketverluste simulieren oder sogar einem Dienst den Stecker ziehen, um die Widerstandsfähigkeit zu testen.

LXD integriert sich nativ in cloud-init, was bedeutet, dass Sie Container mit denselben Konfigurationsmanagement-Tools bereitstellen können, die auch in AWS, Azure und Google Cloud verwendet werden. Ihre lokale Testumgebung entspricht Ihrer Produktionsinfrastruktur bis hin zu den OS-Paketversionen.

Juju: Anwendungsmodellierung jenseits von YAML-Wildwuchs

Infrastructure as Code bedeutet typischerweise riesige YAML-Dateien und Bash-Skripte, die innerhalb weniger Monate unwartbar werden. Juju verfolgt einen grundlegend anderen Ansatz: Es modelliert Beziehungen zwischen Diensten, nicht nur deren Konfigurationen. Ein Juju-„Bundle“ ist eine Deklaration Ihres gesamten Stacks und wie die Teile verbunden sind.

Das Charm-Ökosystem automatisiert Betriebswissen

Ein „Charm“ ist ein Operator, ein Codebaustein, der das betriebliche Wissen über die Bereitstellung und Verwaltung eines Dienstes kapselt. Sie brauchen einen hochverfügbaren PostgreSQL-Cluster mit automatischem Failover? Dafür gibt es einen Charm, gepflegt von Datenbank-Experten. Die Bereitstellung ist ein einziger Befehl:

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

Die letzte Zeile ist die Magie. juju relate teilt Juju mit, dass Ihre Django-App eine Datenbank benötigt. Juju konfiguriert PostgreSQL automatisch, erstellt die Datenbank und den Benutzer und injiziert die Verbindungszeichenfolge in die Umgebungsvariablen Ihrer Django-App. Keine manuelle Konfiguration.

Überbrückung der Kluft zwischen Entwicklung und Produktion

Die wahre Stärke des Canonical-Ökosystems zeigt sich, wenn Sie diese Tools gemeinsam einsetzen. Ein typischer Workflow sieht so aus:

1. Lokal entwickeln mit Multipass-VMs, die Ihrer Ziel-Ubuntu-Version entsprechen.
2. Die vollständige Topologie simulieren mithilfe von LXD-Containern für jeden Dienst.
3. Die Bereitstellung modellieren mit Juju-Bundles, die Beziehungen und Skalierungsregeln definieren.
4. Identisch bereitstellen in jeder öffentlichen oder privaten Cloud oder auf Bare-Metal.

<ComparisonTable headers="[