Kürzlich war ich damit beauftragt, einen dedizierten Monitoring-Stack aus Grafana, Prometheus, Loki und Alertmanager aufzubauen. Gegeben war eine RHEL-9-VM und der klare Wunsch, den Betrieb auf Basis solider Standardtechnologien mit möglichst wenigen beweglichen Teilen aufzusetzen.
Genau in solchen Situationen zeigt sich, worauf es in der Praxis ankommt: nicht auf möglichst viele Features, sondern auf einen ruhigen, belastbaren Betriebsmodus.
.container), aus der systemd beim Laden automatisch eine Service-Unit erzeugt. Ergebnis: Container lassen sich wie normale Dienste über systemctl und journalctl betreiben.
Container sind technisch schnell gestartet, aber im Alltag oft unnötig fragmentiert: andere Startlogik, andere Logs, andere Runbooks, andere Rufbereitschaftspfade.
Quadlets waren für mich genau hier der Gegenentwurf, obwohl ich sie bis dahin selbst noch nicht auf dem Schirm hatte. Sie erlauben, Container wie normale Services zu betreiben. Für das Betriebsteam sind dann in der Praxis vor allem zwei Werkzeuge entscheidend: systemctl und journalctl.
Das macht einen großen Unterschied, vor allem wenn ein kleines Team sehr heterogene Anwendungen betreuen und zugleich Rufbereitschaft abdecken muss.
Noch wichtiger: Quadlets wirken im Betrieb wie ein stabiler Contract. Selbst wenn sich auf dem zugrunde liegenden Betriebssystem Details ändern, bleibt die deklarative Service-Beschreibung erhalten. Gerade bei Major-Upgrades hilft das, nach dem Neustart oder Re-Provisioning wieder einen klar definierten Sollzustand herzustellen.
Für Betriebsplattformen gilt ein simples Prinzip: Die Plattform selbst darf nicht zur Sollbruchstelle werden. Wenn Deployments intransparent werden, von der Verfügbarkeit externer Dienste abhängen, Konfigurationen schwer nachvollziehbar sind und zu viele bewegliche Teile zusammenkommen, steigt nicht nur der Aufwand, sondern auch das Betriebsrisiko.
Das Monitoring-Beispiel macht das besonders sichtbar, steht aber stellvertretend für viele Plattformbereiche. Gerade dort, wo Systeme rund um die Uhr zuverlässig funktionieren müssen, sind klare Zuständigkeiten, reproduzierbare Abläufe und robuste Standardmechanismen der größte Hebel.
Im Monitoring passt die Alarmanlagen-Analogie gut: Widerstandsfähigkeit gegenüber externen Einflüssen und eine möglichst hohe Unabhängigkeit von Fremddiensten sind zentrale Qualitätsmerkmale, etwa durch eigene Stromversorgung.
Was sind Quadlets?
Quadlets sind deklarative Dateien (zum Beispiel .container, .network, .volume, .image), aus denen beim Laden automatisch systemd-Units erzeugt werden.
Statt lange podman run-Kommandos oder eigene Wrapper-Skripte zu pflegen, beschreibt man den gewünschten Zustand in Dateien. systemd übernimmt dann das bekannte Lebenszyklus-Management.
Ein minimalistisches Beispiel:
# /etc/containers/systemd/web.container
[Unit]
Description=Webcontainer
After=network-online.target
Wants=network-online.target
[Container]
Image=docker.io/library/nginx:alpine
ContainerName=web
PublishPort=8080:80
[Service]
Restart=always
[Install]
WantedBy=multi-user.target
Danach läuft der Alltag über Standardbefehle:
systemctl daemon-reload
systemctl enable --now web.service
systemctl status web.service
journalctl -u web.service -f
Quadlets reduzieren nicht nur Konfigurationsaufwand, sondern vor allem kognitive Last im Tagesbetrieb. Die Bedienoberfläche für klassische Dienste und Container wird weitgehend identisch.
Zusätzlich entsteht ein belastbarer Betriebsvertrag: Die gewünschte Laufzeit wird deklarativ beschrieben und kann nach Änderungen am Hostsystem konsistent erneut hergestellt werden.
Ursprung und Integration in Podman
Die Idee hinter Quadlets kommt aus der konsequenten Nutzung von systemd als Betriebs-Backbone auf Linux-Servern.
- Frühere Podman-Ansätze setzten oft auf manuell erzeugte systemd-Units.
- Mit Podman 4.4 (2023) wurde Quadlet als integrierter, deklarativer Weg offiziell verfügbar.
- Seitdem hat sich der Ansatz vor allem dort etabliert, wo Containerbetrieb ohne volle Orchestrierungsplattform gewünscht ist.
Gerade im Umfeld von Fedora, RHEL und kompatiblen Distributionen passt das sehr gut zur vorhandenen Systemd- und Betriebsrealität.
Rolle auf Red Hat und Derivaten
Auf Red-Hat-nahen Plattformen ist die Kombination aus Podman + systemd ohnehin naheliegend:
- systemd ist gesetzt
- Podman ist stabil verfügbar und gut dokumentiert
- Betriebsprozesse sind häufig service-orientiert organisiert
In diesen Umgebungen schaffen Quadlets einen pragmatischen Mittelweg:
- mehr Struktur und Wiederholbarkeit als „nur
podman run“ - deutlich weniger Plattformaufwand als ein vollständiger Kubernetes-Stack
Für viele Teams ist das genau der Punkt, an dem Standardisierung realistisch wird.
Und genau dort liegt der operative Hebel: Nicht jeder im Team muss jede Container-Option im Detail beherrschen. Entscheidend ist, dass der Vertrag zwischen Anwendung und Betrieb klar definiert ist und mit den gewohnten Service-Mechanismen reproduzierbar bleibt.
Bis dahin habe ich solche Hybridszenarien vor allem mit den Podman-Tasks von Ansible aufgebaut. Das funktioniert, hat aber zwei klare Nachteile: fehlendes echtes Dependency-Management im Service-Layer und eine durchgängige Abhängigkeit von Ansible für Re-Deployments.
podman-compose war für mich in diesem Kontext eher Migrationshilfe oder Stopgap für Docker-Emulation. Quadlet standardisiert dagegen an einer sauberen, nativen Schnittstelle zwischen Containerlaufzeit und Init-System. Genau das macht den Ansatz so pragmatisch.
Stärken und praktische Grenzen
| Bereich | Einordnung |
|---|---|
| Betrieb | Einheitliche Steuerung über systemctl/journalctl, genau das ist im Enterprise-Umfeld ein starker Standard. |
| Wartbarkeit | Deklarative Dateien sind gut versionierbar und bilden einen stabilen Betriebsvertrag über Upgrades hinweg. |
| Skalierbarkeit | Einzelne Services und Appliances lassen sich sehr gut abbilden, komplette Cluster-Topologien beschreibt man mit Quadlet allein jedoch nicht. |
| Multi-Node-Betrieb | Für größere Landschaften bietet sich Ansible an, um Quadlets zu templaten, konsistent auszurollen und node-übergreifend zu orchestrieren. |
| Onboarding | Der Einstieg bleibt niedrig, weil das Betriebsteam primär systemctl und journalctl sicher beherrschen muss. |
Meine Beschäftigung mit Quadlets kommt aus einer sehr konkreten Realität: heterogene Landschaften, hybride Szenarien aus klassischer Enterprise-IT und Containern, kleine Teams im Betrieb und der Anspruch, in Rufbereitschaft nicht unnötig Komplexität zu erzeugen.
In vielen On-Prem-Szenarien, gerade in IoT-, Automotive- und Industrie-Umfeldern, ist der Engpass meist nicht die horizontale Skalierung. Solide Ausfallsicherheit lässt sich häufig schon mit physisch getrennten Active-Active-Setups erreichen, ohne unnötigen operativen Lärm.
Der größere operative Hebel entsteht dann nicht durch zusätzliche Schichten, sondern durch klare Standardisierung an wenigen, robusten Schnittstellen.
Dazu kommt: Plattformen mit vielen verschachtelten Ebenen und zahlreichen Service-Abhängigkeiten erhöhen im Alltag oft die Störanfälligkeit und die Diagnosekomplexität. Kubernetes ist hier nur ein Beispiel für solche mehrschichtigen Betriebsmodelle: Container laufen in Pods, Pods auf Nodes, der Node als Linux-System in einer VM, die VM in einem ESX-Cluster, und dieses am Ende auf Bare-Metal-Hardware. Diese Kette ist gut betreibbar, aber im Incident-Fall werden Fehlerpfade länger und Abhängigkeiten schwerer zu entkoppeln.
Das ist insbesondere in kleinen Bereitschaftsteams relevant, wenn am Sonntagabend unter Zeitdruck stabilisiert werden muss. Unabhängig davon gilt: Wo Anwendungen selbst bereits ausgereifte Redundanz- und Skalierungslogik mitbringen (zum Beispiel Apache Pulsar mit Broker- und Bookie-Redundanz), können zusätzliche externe Regelkreise ungünstig aufschwingen.
Einfache Quadlet-Bausteine in der Praxis
Neben .container sind vor allem drei Dateitypen nützlich:
.networkfür dedizierte Container-Netze.volumefür persistente Daten.imagefür klar definierte Image-Beschaffung
Das ergibt nachvollziehbare, wiederverwendbare Bausteine je Anwendung.
frontend.network
webdata.volume
nginx.image
web.container
Das Ergebnis: ein deklarativer Stack, der im Betrieb wie klassische Services geführt wird.
Weitergedacht: Was ist mit Single-Node-Appliances ohne systemd?
Die interessante Frage kommt erst danach: Was ist, wenn die Zielplattform kein Red Hat Linux und kein systemd hat?
Ein typisches Beispiel ist Alpine Linux. Ich schätze Alpine für Minimalismus, kleine Angriffsfläche und eine erfrischend einfache Architektur. Dort ist aber OpenRC Standard.
Alpine Linux ist eine schlanke Distribution mit kleinem Footprint, musl-libc und BusyBox als technischem Fundament. Gerade für Appliances, Edge-Systeme und klar abgegrenzte On-Prem-Rollen ist das oft ein sehr passender Unterbau: wenig Ballast, schnelle Updates und gut kontrollierbare Laufzeitumgebung.
Alpine Linux: alpinelinux.org
Also das Experiment: Was wäre, wenn es analog zu systemd-Quadlets einen Generator gäbe, der aus deklarativen Quadlet-Dateien OpenRC-init.d-Skripte erzeugt?
Genau daraus ist dieses Projekt entstanden. Das Grundprinzip bleibt gleich: deklarativ beschreiben, Generator laufen lassen, dann Services über den nativen Init-Mechanismus verwalten.
Beispielablauf auf Alpine:
quadlet-openrc check
quadlet-openrc lint
quadlet-openrc generate --clean
rc-update add quadlet-network-frontend default
rc-update add quadlet-volume-webdata default
rc-update add quadlet-image-nginx default
rc-update add web default
rc-service web start
rc-service web status
Und im Betrieb:
rc-service web restart
rc-status -a
podman logs web
Wer den Quadlet-Ansatz in OpenRC-Umgebungen nutzen möchte, findet hier das passende Generator-Projekt: quadlet-openrc auf GitHub
Hinweis: Der aktuelle Stand ist experimenteller Code, bislang nur teilweise getestet und mit Unterstützung von KI-Agenten entwickelt.
Persönliches Fazit
Wenn kleine Teams hybride Landschaften aus klassischer Enterprise-Software und Containern betreiben, ohne dass Kubernetes wirklich notwendig ist, dann ist ein Punkt zentral:
Standardisieren auf der Ebene von systemctl und journalctl ist der kleinste gemeinsame Nenner, den jedes Betriebsteam kurzfristig anstreben sollte.
Quadlets sind dafür kein theoretisches Konstrukt, sondern ein sofort nutzbares Werkzeug. Und genau deshalb sind sie in der Praxis so wertvoll. Gleichzeitig zeigt der OpenRC-Ansatz, dass sich dieses Betriebsmodell mit überschaubarem Aufwand auch für Systeme ohne systemd sinnvoll weiterdenken lässt.
Bildnachweis: Das Docker-Logo ist eine Marke der Docker Inc.; Verwendung im Rahmen redaktioneller Berichterstattung. Tux, das Linux-Maskottchen, wurde von Larry Ewing erstellt (unter Verwendung von GIMP, 1996); Verwendung im Rahmen redaktioneller Berichterstattung.