Quadlet: Podman-Container mit systemd ausführen

 (mo8it.com)
2 Punkte von GN⁺ 2025-03-25 | 1 Kommentare | Auf WhatsApp teilen
  • Da Podman ohne Daemon arbeitet, braucht es nach dem Serverstart eine zuverlässige Instanz, die Container hochfährt; Quadlet löst das über systemd-Service-Dateien
  • Das bisherige podman generate systemd erforderte, Container-Erstellung und Service-Datei-Erzeugung getrennt zu behandeln, und brachte bei jeder Änderung an den generierten Dateien Aufwand durch manuelles Editieren mit sich
  • Quadlet bündelt in .container-Dateien unter ~/.config/containers/systemd die Einstellungen [Container], [Service] und [Install], sodass Podman-Optionen und systemd-Verhalten an einer Stelle verwaltet werden
  • Bei rootless Podman sind für den automatischen Start beim Booten WantedBy=default.target und aktiviertes linger nötig; multi-user.target ist im User-Modus nicht definiert
  • Mit AutoUpdate=registry, systemd-Abhängigkeiten, Dateigruppierung nach Verzeichnissen und dem Konvertierungstool podlet passt Quadlet gut zum Betrieb von Podman rootless und daemonless

Warum Quadlet nötig ist

  • Quadlet ist ein Ansatz, mit dem Podman-Container wie systemd-Services ausgeführt werden können
    • Container können im Hintergrund laufen
    • Nach einem Server-Neustart können Container automatisch gestartet werden
  • Podman-Container unter systemd auszuführen, ist an sich nicht neu
    • Bisher wurde dafür der Befehl podman generate systemd verwendet
    • Dieser Befehl zeigt inzwischen eine Deprecation-Warnung an und empfiehlt die Migration zu Quadlet
  • Da Podman daemonless aufgebaut ist, braucht es eine ausführende Instanz, die Container ohne Daemon startet

Nachteile des bisherigen Ansatzes mit podman generate systemd

  • Beim alten Ansatz musste zuerst mit podman create ein Container erstellt werden
    • Der Beispiel-Container verwendet das Image docker.io/library/postgres:16
    • Enthalten sind -p 5432:5432, ein Volume-Mount, die Umgebungsvariable POSTGRES_PASSWORD und das Label io.containers.autoupdate=registry
  • Danach wurde mit podman generate systemd test-db -fn --new die Datei container-test-db.service erzeugt
  • Die erzeugte Service-Datei wurde unter ~/.config/systemd/user abgelegt und mit folgendem Befehl aktiviert und gestartet
    • systemctl --user enable --now container-test-db
  • Dieser Ablauf führt dazu, dass Container-Erstellung, Service-Datei-Erzeugung, gegebenenfalls das Verschieben von Dateien und die Service-Aktivierung wiederholt werden müssen
  • Wenn der Befehl zur Container-Erstellung länger wird, musste man für eine spätere erneute Ausführung zusätzlich ein Shell-Skript pflegen
  • Um die erzeugte systemd-Service-Datei anzupassen, musste sie jedes Mal wieder manuell geändert werden

Aufbau einer Quadlet-Datei

  • Beim Quadlet-Ansatz legt man das Verzeichnis ~/.config/containers/systemd an und speichert darin .container-Dateien
  • Die Beispieldatei test-db.container enthält die folgenden Elemente
    • [Container]
      • Image=docker.io/library/postgres:16
      • AutoUpdate=registry
      • PublishPort=5432:5432
      • Volume=%h/volumes/test-db:/var/lib/postgresql/data:Z
      • Environment=POSTGRES_PASSWORD=CHANGE_ME
    • [Service]
      • Restart=always
    • [Install]
      • WantedBy=default.target
  • Eine .container-Datei ist eine normale systemd-Service-Datei, enthält aber einen besonderen Abschnitt [Container]
  • Viele Optionen in [Container] entsprechen Kommandozeilenoptionen von podman create
    • Image: zu verwendendes Image und Tag
    • AutoUpdate=registry: entspricht --label "io.containers.autoupdate=registry"
    • PublishPort: entspricht -p
    • Volume: entspricht -v
    • Environment: entspricht -e
  • Für das Home-Verzeichnis des Benutzers muss statt ~ der systemd-Specifier %h verwendet werden
  • Restart=always in [Service] sorgt dafür, dass der Container immer neu gestartet wird, solange er nicht manuell gestoppt wurde
  • WantedBy=default.target in [Install] sorgt dafür, dass der Container beim Booten automatisch gestartet wird

Erforderliche systemd-Einstellungen bei rootless Podman

  • Bei rootless Containern muss default.target statt multi-user.target verwendet werden
    • multi-user.target ist im systemd-User-Modus nicht definiert
    • Das lässt sich mit systemctl --user status multi-user.target prüfen
    • Im Systemmodus ist die Prüfung mit systemctl status multi-user.target möglich
  • Da Container als systemd-User-Services ausgeführt werden, muss linger aktiviert werden, damit Container auch dann starten, wenn der Benutzer nicht eingeloggt ist
    • loginctl enable-linger
  • Wenn nach einem Server-Neustart ein automatischer Start nötig ist, ist aktiviertes linger zwingend erforderlich
  • Damit systemd neue Service-Dateien findet, wird folgender Befehl ausgeführt
    • systemctl --user daemon-reload
  • Start und Statusprüfung des Containers sind sowohl über systemd als auch über Podman möglich
    • systemctl --user start test-db
    • systemctl --user status test-db
    • podman ps
  • Der Standard-Containername entsteht, indem dem Namen der Service-Datei systemd- vorangestellt wird
    • Der Standard-Containername von test-db.container lautet systemd-test-db
    • Das ist eine Namenskonvention, um Konflikte zu vermeiden
    • Mit der Option ContainerName im Abschnitt [Container] kann er direkt festgelegt werden

Betriebliche Vorteile von Quadlet

  • Quadlet ermöglicht es, Container-Service-Konfiguration in einer einzigen Datei zu verwalten
    • Anders als beim bisherigen Ansatz müssen ein Skript zur Erzeugung der Service-Datei und die generierte Service-Datei nicht getrennt verwaltet werden
  • Es können Optionen genutzt werden, die in den systemd-Abschnitten [Unit] und [Service] verfügbar sind
    • Beispielsweise kann ein vor dem Containerstart auszuführender Befehl mit StartExecPre angegeben werden
    • Der spätere manuelle Änderungsprozess für generierte Dateien wird reduziert
  • Statt Shell-Skripte zu schreiben und zu debuggen, können Container stärker über Konfigurationsdateien betrieben werden
  • Abhängigkeiten zwischen Containern lassen sich einfach im systemd-Stil ausdrücken

Abhängigkeiten zwischen Containern ausdrücken

  • Wenn ein App-Container von einem Datenbank-Container abhängt, kann die Beziehung über den systemd-Abschnitt [Unit] festgelegt werden
  • Der OxiTraffic-Container ist ein Beispiel, das vom Container test-db abhängt
    • In [Unit] wird Requires=test-db.service gesetzt, damit die App nur gestartet wird, wenn die Datenbank gestartet wird
    • After=test-db.service wird gesetzt, damit beide Container nicht parallel starten
  • Beim Referenzieren wird nicht der Name der .container-Datei verwendet, sondern der Servicename
    • test-db.container: Dateiname
    • test-db.service: Servicename
    • systemd-test-db: Standard-Containername
  • Damit die App mit der Datenbank kommunizieren kann, müssen beide Container im Abschnitt [Container] die Option Network ergänzen; Networking wird hier jedoch nicht behandelt

Mehrere Dateien und Gruppierung

  • Quadlet kann so organisiert werden, dass jeder Container eine eigene .container-Datei erhält
  • Im Vergleich dazu, alle Bestandteile einer Multi-Container-App in eine einzige Docker-Compose-Datei zu packen, können Dateien pro Container die kognitive Belastung verringern
  • Wenn eine Docker-Compose-Datei Hunderte Zeilen und Dutzende Container enthält, kann die Wartung schwierig werden
  • Auch Docker Compose unterstützt die Aufteilung auf mehrere Dateien
  • Quadlet kann Unit-Dateien in Verzeichnissen unter ~/.config/containers/systemd ablegen
    • Im Beispiel kann ein Verzeichnis oxitraffic angelegt werden, um App- und Datenbankdateien gemeinsam abzulegen

Image-Updates

  • Wenn AutoUpdate=registry gesetzt ist, kann mit podman auto-update nach Image-Updates gesucht werden
  • Wenn in der Registry ein neues Image vorhanden ist, das mit dem verwendeten Tag kompatibel ist, pullt Podman das Image und startet den Container neu
  • Bei Docker kann für diesen Zweck ein Tool wie Watchtower nötig sein; Podman bietet diese Funktion standardmäßig
  • Tags wie latest können riskant sein
    • Bei OxiTraffic kann latest Breaking Changes der nächsten Version enthalten
    • Wenn bei PostgreSQL latest verwendet wird, kann auf eine neue Major-Version gewechselt werden, und Major-Upgrades von PostgreSQL erfordern immer eine manuelle Migration
  • Im Betrieb sollten Tags verwendet werden, die nicht zu Breaking Changes führen
  • Es ist auch möglich, podman auto-update alle paar Tage manuell auszuführen, nachzusehen, was aktualisiert wurde, und anschließend zu prüfen, ob die Container normal laufen

podman-compose und Migrationstools

  • podman-compose ist ein Python-Skript, das Compose-Dateien mit Podman ausführt
  • Als langfristige Docker-Compose-Alternative ist es aus folgenden Gründen schwer zu betrachten
    • Es ist eine Übersetzungsschicht zwischen Compose-Spezifikation und Podman/systemd und ermöglicht nicht die Nutzung aller systemd-Funktionen
    • Offizielle Podman-Projekte sind in kompilierten Sprachen wie Rust oder Go geschrieben
    • Der letzte Commit liegt 5 Monate zurück, daher wird es nicht aktiv gepflegt
  • Quadlet passt besser zum rootless- und daemonless-Design von Podman
  • Wer Quadlet anhand einer Compose-Datei ausprobieren möchte, kann podlet verwenden
    • Ein Rust-Tool, das aus Podman-Befehlen oder Docker-Compose-Dateien Quadlet-Dateien erzeugen kann

Weiterführende Lektüre

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-03-25
Meinungen auf Hacker News

  • Quadlet ist so ziemlich das Beste, was aus Podman hervorgegangen ist, und ich empfehle es allen nachdrücklich, die neugierig auf Podman sind oder auf containerbasierte Workloads umsteigen wollen.
    Man kann Container wie gewöhnliche Systemdienste einhängen und behandeln, ohne eine separate Orchestrierungsschicht lernen zu müssen, nur damit sie zusammenarbeiten, oder von Nicht-Container-Ressourcen abhängig zu sein.
    Man schreibt einfach die gewohnten systemd-Units weiter; automatische Updates oder Neustart/Benachrichtigung eines Dienstes bei Fehlern gibt es obendrauf.
    Der Versuch, Ähnliches mit Docker zu erreichen, lief oft darauf hinaus, den Docker-Daemon mit riesigen run-Befehlen zu umgehen, wodurch häufig Geisterdienste und Container zurückblieben. Quadlet ist deutlich sauberer, und die Konfiguration liegt zusammen mit den systemd-Units an Orten wie /etc/systemd/, .config/systemd, /usr/local/lib/systemd, was Backups erleichtert.
    Für lokale Entwicklung ist es allerdings keine Antwort auf docker-compose, und das Podman-Team scheint sich für diesen Bereich auch nicht besonders zu interessieren.
    User-Container sind gut für langfristig laufende lokale Testinfrastruktur wie Hintergrunddatenbanken, aber für die übliche Schleife Kompilieren → docker compose up → Testen → docker compose down sind sie zu umständlich.
    Die pragmatische Antwort ist entweder .kube Quadlet (Kubernetes play) oder docker compose gegen den Podman-Socket zu verwenden.
    Mir gefällt es so gut, dass ich seit Monaten in meiner Freizeit ein GitOps-Tool zur Verwaltung von Quadlet baue; es fühlt sich wie die richtige Art an, containerisierte Server zu verwalten.
    Wichtig ist, dass [0] nicht podman-compose ist. Auch im Artikel wird erwähnt, dass podman-compose nicht besonders gut ist und es an Entwicklung mangelt. Podman implementiert den Großteil der Compose-Spezifikation, daher kann man in den meisten Situationen docker compose verwenden.
    Viele, die Podman ausprobierten, als RH begann, es zu pushen, dürften wegen der Unausgereiftheit von Podman 3 und der schlechten Erfahrung mit podman-compose abgesprungen sein.

    • Ich wollte näher an die RH-Variante heran und Quadlet sowie podlet ausprobieren, aber der Umstieg von docker compose auf Podman war schrecklich.
      Nachdem ich diverse Flags geändert, Versionen aktualisiert und dem Pfad gefolgt war, auf dem podlet selbst empfahl, zu einem anderen Tool zu wechseln, wurde es zu einem endlosen Kaninchenbau.
      Am Ende führt mein systemd einfach podman compose up aus.
      Ich frage mich, worin der Vorteil von Quadlet gegenüber der Variante liegt, Compose einfach seine Arbeit machen zu lassen.
      Zur Einordnung: Podman läuft unter meinem Benutzer, und es gibt überhaupt keinen Daemon.
    • Der Trick für die Entwicklung ist, den Podman-Socket zu aktivieren, bei rootless Containern auf Benutzerebene, und dann das eigenständige docker-compose zu verwenden.
    • Unter Windows oder Mac kann man systemd nicht verwenden, also bleibt am Ende nur podman compose.

  • Ich habe Quadlet vor Kurzem entdeckt und mein gesamtes Homelab auf Basis eines atomic OS und rootless Quadlet aufgebaut; ich kann es sehr empfehlen.
    Auch systemd-Socket-Aktivierung ist möglich: Man kann zum Beispiel systemd-http/https-Sockets erstellen und Traefik automatisch aktivieren, so wie ssh.socket und podman.socket jeweils sshd.service und podman.service aktivieren.
    In einer rootless Konfiguration ist das praktisch die einzige Möglichkeit, die ursprüngliche IP zu erhalten, und damit fast ein Lebensretter. Rootless Podman/Docker erlauben den Erhalt der ursprünglichen IP normalerweise nicht einfach und ohne größere Nachteile.
    https://github.com/savely-krasovsky/homelab

    • Ich frage mich, wie lange es dauert, bis Traefik aktiviert ist.

  • Quadlet ist eine gute Alternative für den docker compose-Einsatzzweck, „in einer produktionsähnlichen Umgebung alle voneinander abhängigen Container auszuführen“.
    Beim anderen Einsatzzweck von docker compose, der Entwicklung, wünschte ich mir aber etwas Besseres.
    Mit docker compose kann man Datenbanken, Redis, OpenSearch, weitere Abhängigkeiten, einen nginx-Proxy und einen Entwicklungscontainer, der .:/app als Volume gemountet hat, gemeinsam starten, gemeinsam wieder entfernen und die docker-compose.yml ins Repository legen.
    Quadlet verlangt, alle Dateien unter ~/.config/containers/systemd abzulegen; damit sind sie nicht mehr im Projekt isoliert und lassen sich auch nicht bequem einchecken und mit anderen Entwicklern teilen. Außerdem müssen diese dann ebenfalls Podman verwenden.
    Die meisten nutzen nach wie vor Docker, und auch in gehosteten Entwicklungsumgebungen wie Codespaces wird Docker bereitgestellt.
    Deshalb verwenden wir eine eingecheckte YAML-Datei mit docker compose. Da ich Podman nutze, muss ich an alle Volumes manuell :Z anhängen, aber das kann normales Docker nicht verarbeiten.
    Eine docker-compose-Alternative für die Entwicklung wäre schön, aber Quadlet scheint dafür nicht gut zu passen.

    • Mit podman-compose --in-pod=1 systemd -a create-unit kann man einen podman-compose@-Service erstellen und anschließend mit podman-compose systemd -a register eine compose.yml-Datei zusammen mit $name registrieren.
      Dann lässt sich ein auf der Compose-Datei basierender Pod als podman-compose@$name.service verwalten, und das funktioniert auch vollständig rootless.
    • Was man in diesem Fall sucht, ist ein Podman-Pod; ich würde das Ganze mit Ansible orchestrieren und dann allen das Ansible-Playbook geben, damit sie es lokal ausführen.
    • systemd-run ermöglicht es, auf Basis beliebiger Befehle transiente systemd-Services auszuführen.
      Bei Bedarf erstellt es saubere transiente Units, die den systemd-Scope-Regeln folgen, sogar inklusive Timern.
      [1] https://www.freedesktop.org/software/systemd/man/systemd-run...
    • Ich sehe Quadlet eher als Werkzeug für Deployments. Wenn man eine Compose-Alternative sucht, sollte man sich eher Podman Kube Play[1] ansehen.
      Es hat ein Kubernetes-ähnliches Format mit ein paar Komfortfunktionen wie Container-Builds.
      Legt man die kube-play-Datei ins Projekt-Root und führt podman kube play project.yaml --build aus, werden Pods, Volumes usw. gemeinsam gestartet.
      Quadlet-Dateien sind in der Deployment-Phase nützlich. Wenn man das Projekt auf einen VPS bringen möchte, kann man zusammen mit der vorhandenen project.yaml Kube Quadlet[2] verwenden.
      [1] https://docs.podman.io/en/latest/markdown/podman-kube-play.1...
      [2] https://docs.podman.io/en/latest/markdown/podman-systemd.uni...
    • In unserer Firma nutzen wir für die Entwicklung ebenfalls docker-compose.yml, daher kann ich den Schmerz nachvollziehen.
      Meist funktioniert es sehr gut, aber unter OSX verhält es sich wegen dieser verdammten Zwischen-VM manchmal seltsam.
      Ich prüfe gelegentlich die Podman-Kompatibilität, habe aber inzwischen akzeptiert, dass vollständige Kompatibilität unmöglich ist, weil die rootless-Philosophie zu unterschiedlich ist.
      Trotzdem ist dieses Tool für die Produktion großartig. Ich betreibe ein paar Hobbyprojekte auf Bare-Metal-Nodes mit handgeschriebenen systemd-Services; derzeit ist das containerd im User-Modus.
      Wenn ich Zeit habe, migriere ich sie vielleicht.

  • Interessant ist, dass der Artikel Podman-Compose als „nicht aktiv gepflegt“ bezeichnet und darauf hinweist, dass der letzte Commit fünf Monate zurückliegt, dann aber direkt als Alternative Podlet empfiehlt, dessen letzter Commit ebenfalls fünf Monate zurückliegt.
    Podlet kann nützlich sein, unterstützt aber viele Funktionen von Docker Compose nicht und konvertiert auch nicht immer sauber.
    Insbesondere unterstützt es nicht, mehrere YAML-Dateien wie -f docker-compose.yml -f docker-compose.override.yml übereinanderzulegen.

    • Wenn man Compose-Dateien mag, kann man die Compose-Anwendung[1] von Docker zusammen mit Podman[2] verwenden.
      Die Compose-CLI scheint die Engine über einen Socket zu steuern, und Podman und die Docker Engine haben nahezu dieselbe API.
      Ich nutze diesen Weg, weil podman-compose nicht wie erwartet funktioniert hat.
      Docker-compose wird normalerweise als Plugin für den Docker-Client installiert, aber ich verwende es als eigenständige Anwendung, um es mit Podman zu nutzen.
      Außerdem bevorzuge ich für die Integrationskonfiguration Docker-contexts gegenüber der Umgebungsvariable DOCKER_HOST.
      Wenn reines Quadlet nicht leistungsfähig genug ist, unterstützen auch Quadlet[3] und normales Podman[4] die Ausführung eingeschränkter Kubernetes-Manifeste.
      Ich habe noch nicht herausgefunden, wie Podman die restart-Option in Compose-Dateien behandelt. Podman hat nämlich keinen Supervisor-Daemon.
      Dagegen weiß ich, dass die Option healthcheck auf systemd-Timer angewiesen ist.
      Als ich Podman auf Gentoo, einer Distribution ohne systemd, verwendete, funktionierten automatische Healthchecks nicht; wenn man den Healthcheck aber manuell ausführte, lief die restliche Konfiguration bis zum Ende durch.
      [1] https://github.com/docker/compose
      [2] https://docs.podman.io/en/latest/markdown/podman-system-serv...
      [3] https://docs.podman.io/en/latest/markdown/podman-systemd.uni...
      [4] https://docs.podman.io/en/latest/markdown/podman-kube-play.1...
    • Fairerweise braucht der Funktionsumfang von Podlet keine ständigen Updates, bei podman compose ist das anders.
      Podlet ist ein Hilfswerkzeug, und langfristig ist es besser, direkt mit Quadlet zu arbeiten.
    • Commit-Daten sind kein präziser Hinweis darauf, dass etwas gepflegt wird, können aber zeigen, dass etwas nicht gepflegt wird.
      Fünf Monate bedeuten nicht, dass es nicht gepflegt wird; dafür müssten es eher etwa zwei Jahre sein.
      Trotzdem verstärkt es Bedenken. Allerdings sind fünf Monate keinesfalls ein Beleg dafür, dass es gepflegt wird.
      Auch nicht gepflegte Repositories haben viele Gründe, aktualisiert zu werden, und nur die jüngst eher schlechte Archivierungsfunktion von GitHub verhindert das.

  • Als ich vor ein paar Jahren mein Self-Hosting-Setup neu aufsetzte, wollte ich etwas anderes ausprobieren, entschied mich für openSUSE MicroOS und landete schließlich dabei, Podman-Container unter systemd/Quadlet laufen zu lassen; mit der aktuellen Konfiguration bin ich ziemlich zufrieden.
    Die Container werden mit den eingebauten Podman-Werkzeugen automatisch aktualisiert, Logs und Monitoring erledige ich mit den üblichen systemd-Tools.
    Wenn ich etwas ändern muss, ist es auch dann leicht zu finden, wenn ich den Ort der Konfigurationsdateien vergessen habe, und es ist einfach zu lesen und zu bearbeiten.
    Rootless und daemonless sind ebenfalls angenehm.
    Ich habe zwischendurch einiges ausprobiert, aber podman compose fühlte sich schwerfällig an; ich bin froh, dass es deprecated ist, und es ist klar, dass Quadlet der richtige Weg ist.
    Man muss eine Lernkurve und weniger Material als bei Docker einkalkulieren.
    Für lokale Entwicklung, bei der man Stacks mit mehreren Services hoch- und herunterfährt, würde ich weiterhin Docker und docker compose wählen.

    • Ich betreibe Nextcloud auf einer günstigen alten Workstation mit Fedora CoreOS.
      Es hat etwas gedauert, die Konfiguration hinzubekommen, aber ich bin sehr beeindruckt davon, wie wenig Wartung nötig ist. Bisher gar keine.
      Wer etwas Ähnliches ausprobieren möchte, kann sich meine Konfiguration ansehen.
      https://github.com/jeppester/coreos-nextcloud
    • Die Kombination Quadlet + MicroOS ist sehr leistungsstark, und dasselbe gilt für andere Atomic-Distributionen wie Fedora CoreOS.
      Ich migriere nach und nach alle Nodes auf MicroOS, und auch im Unternehmen drängen wir auf MicroOS oder etwas Ähnliches.
      Die Kombination aus automatischem Rollback des Basis-OS, deklarativer Container-Konfiguration und automatischen Updates fühlt sich an, als würde alles genau ineinandergreifen.

  • Das Format ist klarer als podman generate systemd oder Kubernetes-YAML, und auch die systemd-Integration ist hervorragend.
    Ärgerlich ist, dass Podman upstream kein Repository für Debian/Ubuntu bereitstellt.
    Unter Debian stable hing ich bei 4.3.1 fest und verpasste viele neue Funktionen, sodass ich mich schließlich entschied, zu Docker Compose zurückzukehren.

    • Beim Versuch, Quadlet auf einem Raspberry Pi mit Debian zu verwenden, stieß ich auf dasselbe Problem.
      Die vorgeschlagenen Workarounds waren, Podman selbst zu kompilieren oder debian/testing zu verwenden.

  • Ich hoffe wirklich, dass dieser neue Ansatz den Leuten hilft, von Docker zu Podman zu wechseln.
    Docker Compose ist ein Grund, warum viele mit dem Umstieg zögern, und bei mir war es genauso.
    Zugegeben: Vor Quadlet hatte Podman darauf keine richtige Antwort.
    Wenn Docker Compose dich davon abgehalten hat, von Docker wegzugehen, ist Podman mit Quadlet eine deutlich vergleichbarere Alternative.
    Du wirst Docker vermutlich weniger vermissen, als du denkst, und bekommst durch das Ausführen rootlesser Container auch noch mehr Sicherheit.

    • Ich werde nicht wechseln, solange man nicht mehrere unabhängige Quadlet-Umgebungen haben kann.
      Alles in ~/.config/quadlet/systemd zu packen, funktioniert nicht.
      Für Entwicklung und Tests ist das unverzichtbar, und aktuell ist Quadlet strikt eine Deployment-Lösung.

  • Mir gefällt Quadlet wirklich, weil es Container wie normale Systemdienste nutzbar macht.
    Allerdings passt die User Experience von rootless Containern nicht gut zu dieser Vorstellung.
    Normalerweise laufen Systemdienste als Systembenutzer in der systemweiten systemd-Session, aber Dienste für rootless Container befinden sich in der Benutzer-systemd-Session eines Systembenutzers.
    Es wäre schön, wenn man rootless Quadlet innerhalb der System-Session ausführen könnte.

    • Ich frage mich, ob es praktisch einen Unterschied dazu gibt, user-linger zu aktivieren und es rootless über user systemd auszuführen.
      Ich habe es immer so gemacht.
    • Auch ich fände es gut, wenn man rootless Quadlet innerhalb der System-Session ausführen könnte.
      Außerdem wäre es schön, wenn man rootless Quadlet mit der Option DynamicUser= ausführen könnte.
      DynamicUser= war eine großartige Möglichkeit, die Berechtigungen von Systemdiensten einzuschränken, passt derzeit aber nicht gut zu Podman.

  • Es ist interessant, Quadlet auf der Hacker-News-Startseite zu sehen. Ich finde, es hat nicht genug Aufmerksamkeit bekommen.
    Ygal und Valentin aus dem Projekt haben uns einmal einen Gastbeitrag darüber geschickt, wie man den inlets-Tunnel-Client ausführt. Ähnlich wie Ngrok/Cloudflared, aber selbst gehostet und ohne SaaS-Beschränkungen.
    https://inlets.dev/blog/2023/10/03/client-quadlet.html
    Sie konnten statt [container] [kube] verwenden und damit Standard-Kubernetes-YAML nutzen, was es ziemlich portabel macht.

  • Für Interessierte habe ich kürzlich ein Ansible-Template erstellt, das zeigt, wie einfach Quadlet-Deployments sind.
    GH: https://github.com/Mati365/hetzner-podman-bunjs-deploy