Quadlet: Podman कंटेनरों को systemd के साथ चलाना

 (mo8it.com)
2 पॉइंट द्वारा GN⁺ 2025-03-25 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Podman daemonless होने के कारण, सर्वर बूट होने के बाद कंटेनरों को भरोसेमंद तरीके से उठाने के लिए एक execution host की ज़रूरत होती है, और Quadlet इसे systemd service file तरीके से हल करता है
  • पहले podman generate systemd में container creation और service file generation को अलग-अलग संभालना पड़ता था, और generated file बदलने पर हर बार manual editing का बोझ आता था
  • Quadlet ~/.config/containers/systemd की .container फ़ाइल में [Container], [Service], [Install] सेटिंग्स को साथ रखकर Podman options और systemd behavior को एक ही जगह manage करता है
  • rootless Podman में boot auto-start के लिए WantedBy=default.target और linger activation ज़रूरी है, जबकि multi-user.target user mode में define नहीं होता
  • AutoUpdate=registry, systemd dependencies, directory-based file grouping, और podlet conversion tool के साथ Quadlet rootless·daemonless Podman ऑपरेशन के लिए अच्छी तरह फिट बैठता है

Quadlet की ज़रूरत क्यों है

  • Quadlet Podman कंटेनरों को systemd service की तरह चलाने का तरीका है
    • कंटेनरों को background में चलाया जा सकता है
    • सर्वर reboot के बाद कंटेनर अपने-आप शुरू हो सकते हैं
  • Podman कंटेनरों को systemd के तहत चलाने का तरीका अपने-आप में नया नहीं है
    • पहले podman generate systemd कमांड इस्तेमाल की जाती थी
    • यह कमांड अब Quadlet पर migrate करने की deprecation warning दिखाती है
  • Podman daemonless architecture पर आधारित है, इसलिए daemon के बिना कंटेनर शुरू करवाने के लिए एक execution host चाहिए

पुराने podman generate systemd तरीके की असुविधा

  • पुराने तरीके में पहले podman create से कंटेनर बनाना पड़ता था
    • उदाहरण कंटेनर docker.io/library/postgres:16 image का उपयोग करता है
    • इसमें -p 5432:5432, volume mount, POSTGRES_PASSWORD environment variable, और io.containers.autoupdate=registry label शामिल हैं
  • इसके बाद podman generate systemd test-db -fn --new चलाकर container-test-db.service फ़ाइल बनाई जाती थी
  • बनी हुई service file को ~/.config/systemd/user में रखकर नीचे दिए गए कमांड से enable और start किया जाता था
    • systemctl --user enable --now container-test-db
  • इस flow में container creation, service file generation, ज़रूरत पड़ने पर file move, और service enablement बार-बार दोहराना पड़ता था
  • अगर container creation command लंबी हो जाए, तो बाद में फिर चलाने के लिए अलग से shell script संभालनी पड़ती थी
  • generated systemd service file को customize करना हो, तो हर बार फिर से manual editing करनी पड़ती थी

Quadlet फ़ाइल की संरचना

  • Quadlet तरीके में ~/.config/containers/systemd directory बनाई जाती है और उसके भीतर .container फ़ाइल रखी जाती है
  • उदाहरण test-db.container फ़ाइल में ये तत्व शामिल हैं
    • [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
  • .container फ़ाइल एक सामान्य systemd service file ही है, लेकिन इसमें एक खास [Container] section शामिल होता है
  • [Container] के कई options podman create में इस्तेमाल होने वाले command-line options से मेल खाते हैं
    • Image: इस्तेमाल की जाने वाली image और tag
    • AutoUpdate=registry: --label "io.containers.autoupdate=registry" के बराबर
    • PublishPort: -p के बराबर
    • Volume: -v के बराबर
    • Environment: -e के बराबर
  • user home directory के लिए ~ की जगह systemd specifier %h इस्तेमाल करना चाहिए
  • [Service] में Restart=always कंटेनर को तब तक हमेशा restart कराता है, जब तक उसे manually stop न किया जाए
  • [Install] में WantedBy=default.target कंटेनर को boot पर auto-start होने देता है

rootless Podman में ज़रूरी systemd सेटिंग्स

  • rootless कंटेनरों में multi-user.target नहीं, बल्कि default.target इस्तेमाल करना चाहिए
    • multi-user.target systemd user mode में define नहीं है
    • इसे systemctl --user status multi-user.target से जाँचा जा सकता है
    • system mode में इसे systemctl status multi-user.target से देखा जा सकता है
  • क्योंकि कंटेनर systemd user service के रूप में चलते हैं, इसलिए user login न होने पर भी कंटेनर शुरू हों, इसके लिए linger enable करना पड़ता है
    • loginctl enable-linger
  • सर्वर reboot के बाद auto-start चाहिए तो linger activation अनिवार्य है
  • नई service file को systemd से discover करवाने के लिए यह कमांड चलानी होगी
    • systemctl --user daemon-reload
  • कंटेनर start करना और उसकी स्थिति देखना systemd और Podman दोनों से किया जा सकता है
    • systemctl --user start test-db
    • systemctl --user status test-db
    • podman ps
  • default container name, service file name के आगे systemd- लगाकर बनता है
    • test-db.container का default container name systemd-test-db है
    • यह naming rule conflict से बचाने के लिए है
    • इसे [Container] section के ContainerName option से सीधे तय किया जा सकता है

Quadlet के संचालन संबंधी फायदे

  • Quadlet container service settings को एक ही फ़ाइल में manage करने देता है
    • पुराने तरीके की तरह service file generate करने वाली script और generated service file को अलग-अलग संभालना नहीं पड़ता
  • systemd के [Unit] और [Service] sections में उपलब्ध options इस्तेमाल किए जा सकते हैं
    • उदाहरण के लिए, कंटेनर शुरू होने से पहले चलने वाला command StartExecPre से दिया जा सकता है
    • बाद में generated file को manually बदलने की ज़रूरत कम हो जाती है
  • shell script लिखने और debug करने के बजाय configuration file-केंद्रित तरीके से कंटेनर चलाए जा सकते हैं
  • कंटेनरों के बीच dependencies को systemd तरीके से व्यक्त करना आसान हो जाता है

कंटेनरों के बीच dependencies व्यक्त करना

  • अगर app container किसी database container पर निर्भर हो, तो systemd के [Unit] section से यह संबंध बताया जा सकता है
  • OxiTraffic container, test-db container पर निर्भर रहने वाला उदाहरण है
    • [Unit] में Requires=test-db.service सेट करने पर app केवल database शुरू होने पर ही शुरू होगा
    • After=test-db.service सेट करने पर दोनों कंटेनर parallel में शुरू नहीं होंगे
  • reference देते समय .container फ़ाइल नाम नहीं, बल्कि service name इस्तेमाल होता है
    • test-db.container: फ़ाइल नाम
    • test-db.service: service name
    • systemd-test-db: default container name
  • app को database से बात करनी हो, तो दोनों कंटेनरों के [Container] section में Network option जोड़ना होगा, लेकिन networking यहाँ शामिल नहीं है

कई फ़ाइलें और grouping

  • Quadlet को इस तरह व्यवस्थित किया जा सकता है कि हर कंटेनर की अलग .container फ़ाइल हो
  • multi-container app को एक ही Docker Compose फ़ाइल में रखने की तुलना में, container-wise files cognitive load कम कर सकती हैं
  • अगर Docker Compose फ़ाइल सैकड़ों लाइनों और दर्जनों कंटेनरों तक पहुँच जाए, तो उसे maintain करना मुश्किल हो सकता है
  • Docker Compose में भी कई फ़ाइलों में बाँटने की सुविधा है
  • Quadlet ~/.config/containers/systemd के भीतर directories में unit files रखने की सुविधा देता है
    • उदाहरण में oxitraffic directory बनाकर app और database files को साथ रखा जा सकता है

image updates

  • AutoUpdate=registry सेट करने पर podman auto-update से image updates जाँची जा सकती हैं
  • अगर registry में उपयोग किए जा रहे tag के compatible कोई नई image हो, तो Podman image pull करके कंटेनर restart कर देता है
  • Docker में इसके लिए Watchtower जैसे tool की ज़रूरत पड़ सकती है, लेकिन Podman यह सुविधा built-in देता है
  • latest जैसे tags जोखिम भरे हो सकते हैं
    • OxiTraffic में latest अगले version की breaking changes ला सकता है
    • PostgreSQL में latest इस्तेमाल करने पर नया major version आ सकता है, और PostgreSQL major upgrade में हमेशा manual migration चाहिए होती है
  • production में ऐसे tags इस्तेमाल करने चाहिए जो breaking change तक न ले जाएँ
  • एक तरीका यह भी है कि podman auto-update को हर कुछ दिनों में manually चलाकर देखा जाए कि क्या update हुआ, और फिर कंटेनर ठीक चल रहा है या नहीं

podman-compose और migration tools

  • podman-compose एक Python script है जो Compose files को Podman के साथ चलाती है
  • इसे लंबे समय के Docker Compose alternative के रूप में देखना मुश्किल है, वजहें ये हैं
    • यह Compose spec और Podman·systemd के बीच translation layer है, इसलिए systemd की सारी capabilities उपलब्ध नहीं कराता
    • आधिकारिक Podman project Rust या Go जैसी compiled languages में लिखा जाता है
    • आख़िरी commit 5 महीने पहले का है, इसलिए इसका maintenance बहुत सक्रिय नहीं दिखता
  • Quadlet, Podman के rootless·daemonless design के साथ ज़्यादा स्वाभाविक रूप से मेल खाता है
  • Compose file से Quadlet आज़माने के लिए podlet इस्तेमाल किया जा सकता है
    • यह एक Rust tool है जो Podman commands या Docker Compose files से Quadlet files बना सकता है

आगे पढ़ने के लिए

  • Quadlet को गहराई से समझने के लिए podman-systemd.unit man page उपयोगी है
  • Quadlet केवल container ही नहीं, बल्कि pod, network, और volume भी manage कर सकता है
  • अगर systemd unit files लिखने की आदत नहीं है, तो systemd.unit और systemd.service man pages देखी जा सकती हैं
  • एक दूसरा दृष्टिकोण और दूसरा उदाहरण blog.while-true-do की मिलती-जुलती पोस्ट में देखा जा सकता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-03-25
Hacker News की राय

  • Quadlet Podman से निकली सबसे अच्छी चीज़ों में से एक है, और जो लोग Podman को लेकर उत्सुक हैं या container-based workloads पर शिफ्ट होना चाहते हैं, उन्हें मैं इसकी जोरदार सिफारिश करता हूं
    Containers को सामान्य system services की तरह जोड़कर संभाला जा सकता है, और उन्हें साथ में चलाने के लिए अलग orchestration layer सीखने या non-container resources पर निर्भर रहने की जरूरत नहीं पड़ती
    आप बस वही systemd units लिखते हैं जो आप पहले से लिखते आए हैं, और automatic updates या failure पर service restart/notifications बोनस हैं
    Docker से ऐसा ही करने की कोशिश में अक्सर विशाल run command के जरिए Docker daemon को bypass करना पड़ता था और ghost services व containers बचे रह जाते थे, जबकि Quadlet कहीं ज्यादा साफ-सुथरा है और configuration भी /etc/systemd/, .config/systemd, /usr/local/lib/systemd जैसी systemd unit locations में साथ रहता है, इसलिए backup लेना आसान है
    हालांकि local development में यह docker-compose का जवाब नहीं है, और Podman team भी उस क्षेत्र में बहुत रुचि लेती नहीं दिखती
    User containers background database जैसे long-running local test infrastructure के लिए अच्छे हैं, लेकिन आम compile → docker compose up → test → docker compose down loop के लिए बहुत झंझट वाले हैं
    व्यावहारिक जवाब या तो .kube Quadlet (Kubernetes play) है, या Podman socket के साथ docker compose इस्तेमाल करना
    यह मुझे इतना पसंद आया कि मैं कई महीनों से खाली समय में Quadlet manage करने वाला GitOps tool बना रहा हूं, और यह containerized servers manage करने का सही तरीका लगता है
    [0] का podman-compose न होना महत्वपूर्ण है। लेख में भी बताया गया था कि podman-compose खास अच्छा नहीं है और उसका development कम है। Podman compose spec का अधिकांश हिस्सा implement करता है, इसलिए ज्यादातर स्थितियों में आप docker compose इस्तेमाल कर सकते हैं
    जब RH ने पहली बार Podman को push करना शुरू किया था, तब जिन लोगों ने इसे try किया था वे शायद Podman 3 की अस्पष्टता और podman-compose के खराब अनुभव की वजह से दूर हो गए

    • मैं RH के तरीके के करीब जाना चाहता था, इसलिए Quadlet और podlet आजमाने की कोशिश की, लेकिन Podman पर docker compose से migrate करने का अनुभव भयावह था
      कई flags बदलना, versions upgrade करना, और podlet खुद ही किसी दूसरे tool पर जाने की सलाह देने वाली flow को follow करते-करते यह एक अंतहीन rabbit hole बन गया
      आखिर में मेरा systemd बस podman compose up चलाता है
      compose को अपना काम करने देने की तुलना में Quadlet का फायदा क्या है, यह जानने की उत्सुकता है
      संदर्भ के लिए, Podman मेरे user के रूप में चलता है, और कोई daemon बिल्कुल नहीं है
    • Development के लिए trick यह है कि Podman socket enable करें, rootless containers हों तो user unit के रूप में enable करें, और standalone docker-compose इस्तेमाल करें
    • Windows या Mac पर systemd इस्तेमाल नहीं कर सकते, इसलिए अंत में सिर्फ podman compose ही बचता है

  • हाल ही में Quadlet खोजा और atomic OS व rootless Quadlet के आधार पर पूरा homelab बनाया; इसकी जोरदार सिफारिश करता हूं
    systemd socket activation भी संभव है, यानी उदाहरण के लिए systemd http/https sockets बनाकर, जैसे ssh.socket और podman.socket क्रमशः sshd.service, podman.service को activate करते हैं, वैसे ही Traefik को auto-activate किया जा सकता है
    rootless setup में original IP preserve करने का यह व्यावहारिक रूप से इकलौता तरीका है, इसलिए यह लगभग lifesaver है। Rootless Podman/Docker आम तौर पर बिना बड़े drawbacks के original IP preservation को आसानी से allow नहीं करते
    https://github.com/savely-krasovsky/homelab

    • जानना चाहूंगा कि Traefik activate होने में कितना समय लेता है

  • Quadlet “प्रोडक्शन जैसे माहौल में आपस में निर्भर सभी containers चलाने” वाले docker compose use case के लिए अच्छा विकल्प है
    लेकिन docker compose का दूसरा use case, यानी development वाला, अगर बेहतर होता तो अच्छा होता
    docker compose के साथ database, Redis, OpenSearch, बाकी dependencies, nginx proxy, और .:/app को volume के रूप में mount किए हुए development container को साथ में start किया जा सकता है, साथ में हटाया जा सकता है, और docker-compose.yml को repository में रखा जा सकता है
    Quadlet सभी files को ~/.config/containers/systemd में रखने को कहता है, इसलिए यह अब project में isolated नहीं रहता, और दूसरे developers के साथ check-in करके share करना भी सुविधाजनक नहीं है। ऊपर से उन्हें भी Podman इस्तेमाल करना पड़ेगा
    ज़्यादातर लोग अभी भी Docker इस्तेमाल करते हैं, और Codespaces जैसे hosted development environments में भी Docker ही मिलता है
    इसलिए check-in की गई YAML file के साथ docker compose इस्तेमाल किया जाता है। मैं Podman इस्तेमाल करता हूं, इसलिए सभी volumes में manually :Z लगाना पड़ता है, लेकिन सामान्य Docker उसे handle नहीं कर पाता
    development के लिए docker compose का कोई विकल्प हो तो अच्छा होगा, लेकिन Quadlet उसके लिए ठीक fit नहीं लगता

    • podman-compose --in-pod=1 systemd -a create-unit इस्तेमाल करने पर podman-compose@ service बनाई जा सकती है, और बाद में podman-compose systemd -a register से compose.yml file को $name के साथ register किया जा सकता है
      फिर podman-compose@$name.service से compose file आधारित pod को manage किया जा सकता है, और यह पूरी तरह rootless तरीके से भी चलता है
    • इस मामले में आप जो खोज रहे हैं वह Podman pod है, और मैं इसे पूरा Ansible से orchestrate करने के बाद Ansible playbook सभी को देकर local में चलवाऊंगा
    • systemd-run arbitrary command के आधार पर temporary systemd service चलाने देता है
      ज़रूरत हो तो timer तक शामिल करके systemd scope rules का पालन करने वाली साफ-सुथरी temporary unit बना देता है
      [1] https://www.freedesktop.org/software/systemd/man/systemd-run...
    • Quadlet को मैं आम तौर पर deployment के ज्यादा करीब मानता हूं। अगर compose का विकल्प खोज रहे हैं, तो Podman Kube Play[1] देखना बेहतर है
      इसमें Kubernetes जैसी format है और container build जैसी कुछ convenience features जोड़ी गई हैं
      kube play file को project root में रखकर podman kube play project.yaml --build चलाएं, तो pod, volumes आदि साथ में चलने लगते हैं
      Quadlet files deployment stage में उपयोगी हैं। अगर project को VPS पर डालना चाहते हैं, तो आपके पास पहले से मौजूद project.yaml के साथ Kube Quadlet[2] इस्तेमाल कर सकते हैं
      [1] https://docs.podman.io/en/latest/markdown/podman-kube-play.1...
      [2] https://docs.podman.io/en/latest/markdown/podman-systemd.uni...
    • हमारी company भी development में docker-compose.yml इस्तेमाल करती है, इसलिए दर्द समझ आता है
      कुल मिलाकर यह बहुत अच्छी तरह काम करता है, लेकिन OSX पर उस घटिया intermediate VM की वजह से कभी-कभी अजीब behave करता है
      कभी-कभी Podman compatibility check करता हूं, लेकिन अब मान लिया है कि rootless philosophy इतनी अलग है कि full compatibility संभव नहीं है
      फिर भी यह tool production के लिए शानदार है। कुछ hobby projects bare-metal node पर हाथ से बनाए systemd services के रूप में चला रहा हूं, और अभी user-mode containerd है
      समय मिला तो migrate करके देख सकता हूं

  • यह बात मज़ेदार है कि यह लेख Podman-Compose को “actively maintained नहीं है” कहता है और बताता है कि आख़िरी commit 5 महीने पहले था, और तुरंत विकल्प के तौर पर Podlet की सिफ़ारिश करता है, जिसका आख़िरी commit भी 5 महीने पहले ही था
    Podlet उपयोगी हो सकता है, लेकिन यह Docker Compose की कई सुविधाएँ support नहीं करता और हमेशा साफ़-सुथरा conversion भी नहीं करता
    खासकर -f docker-compose.yml -f docker-compose.override.yml की तरह कई YAML files को stack करने वाली सुविधा support नहीं करता

    • अगर आपको compose files पसंद हैं, तो Docker का compose application[1] Podman[2] के साथ इस्तेमाल किया जा सकता है
      लगता है compose CLI socket के ज़रिए engine को control करता है, और Podman व Docker engine की API लगभग एक जैसी है
      podman-compose उम्मीद के मुताबिक काम नहीं कर रहा था, इसलिए मैं यही तरीका इस्तेमाल कर रहा हूँ
      Docker-compose आम तौर पर docker client plugin के रूप में install होता है, लेकिन मैं इसे Podman के साथ इस्तेमाल करने के लिए standalone application के रूप में चलाता हूँ
      साथ ही integration setup के लिए मैं DOCKER_HOST environment variable के बजाय docker contexts को तरजीह देता हूँ
      अगर सिर्फ़ Quadlet पर्याप्त powerful न हो, तो Quadlet[3] और सामान्य Podman[4] भी सीमित Kubernetes manifests चलाने को support करते हैं
      अभी तक यह नहीं समझ पाया कि compose file के restart option को Podman कैसे handle करता है, क्योंकि Podman में कोई supervising daemon नहीं है
      वहीं healthcheck option systemd timers पर निर्भर करता है, यह मुझे पता है
      Gentoo जैसे non-systemd distribution पर Podman इस्तेमाल करते समय automatic healthcheck काम नहीं करता था, लेकिन manually healthcheck चलाने पर बाकी setup अंत तक पूरा हो गया
      [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...
    • निष्पक्ष रूप से देखें तो Podlet की functionality को लगातार updates की ज़रूरत नहीं होती, लेकिन podman compose के साथ ऐसा नहीं है
      Podlet एक सहायक tool है, और लंबे समय में Quadlet के साथ काम करना बेहतर है
    • commit date यह दिखाने के लिए सटीक नहीं होती कि कोई चीज़ maintained है, लेकिन यह दिखा सकती है कि वह maintained नहीं है
      5 महीने का मतलब unmaintained नहीं होता; लगभग 2 साल होने चाहिए
      फिर भी यह चिंता बढ़ाता है। लेकिन 5 महीने maintenance में होने का सबूत बिल्कुल नहीं है
      unmaintained repositories को भी update होने की कई वजहें हो सकती हैं, और GitHub की हाल की कमज़ोर archive functionality ही इसे रोकती है

  • कुछ साल पहले self-hosting setup को reset करते समय कुछ अलग आज़माना चाहता था, इसलिए openSUSE MicroOS चुना, और आखिरकार systemd/Quadlet के तहत Podman containers चलाने लगा; मौजूदा setup से मैं काफ़ी संतुष्ट हूँ
    containers Podman के built-in tools से automatically update होते हैं, और logs देखना व monitoring सामान्य systemd tools से करता हूँ
    जब कुछ बदलना हो, तब configuration file की location भूल भी जाऊँ तो उसे ढूँढना आसान है, और पढ़ना व edit करना भी आसान है
    rootless और daemonless होना भी अच्छा है
    बीच में कुछ चीज़ें आज़माईं, लेकिन podman compose भारी-भरकम लगा, उसके deprecated होने से खुशी है, और साफ़ है कि Quadlet ही आगे का रास्ता है
    learning curve है और Docker की तुलना में resources कम हैं, यह ध्यान में रखना होगा
    local development में कई service stacks को up/down करने के लिए मैं अब भी Docker और docker compose ही चुनूँगा

    • एक सस्ते पुराने workstation पर Fedora CoreOS से Nextcloud चला रहा हूँ
      setup मिलाने में थोड़ा समय लगा, लेकिन इस बात से बहुत प्रभावित हूँ कि maintenance लगभग चाहिए ही नहीं। अब तक तो बिल्कुल नहीं
      जो लोग कुछ ऐसा ही करना चाहते हैं, वे मेरा setup देख सकते हैं
      https://github.com/jeppester/coreos-nextcloud
    • Quadlet + MicroOS combination बहुत powerful है, और Fedora CoreOS जैसी दूसरी atomic distributions के लिए भी यही बात लागू होती है
      मैं अपने सभी nodes को धीरे-धीरे MicroOS पर ले जा रहा हूँ, और कंपनी में भी MicroOS या उससे मिलती-जुलती चीज़ को push कर रहा हूँ
      base OS का automatic rollback और declarative container configuration व automatic updates का combination एक-दूसरे में बिल्कुल फिट बैठता महसूस होता है

  • format podman generate systemd या Kubernetes YAML से ज़्यादा स्पष्ट है, और systemd integration भी शानदार है
    परेशान करने वाली बात यह है कि Podman upstream Debian/Ubuntu के लिए repository provide नहीं करता
    Debian stable पर 4.3.1 में अटके रहने से कई नए features छूट गए, और अंततः Docker compose पर वापस लौटने का फैसला किया

    • Debian चलाने वाले Raspberry Pi पर Quadlet इस्तेमाल करने की कोशिश में मुझे भी यही समस्या मिली
      सुझाए गए workaround थे Podman को खुद compile करना या debian/testing इस्तेमाल करना

  • मैं सच में उम्मीद करता/करती हूँ कि यह नया तरीका लोगों को Docker से Podman पर शिफ्ट होने में मदद करेगा
    Docker-Compose ही वह वजह है जिसके चलते कई लोग स्विच करने से हिचकते हैं, और मेरे साथ भी ऐसा ही था
    मानना पड़ेगा कि Quadlet से पहले Podman के पास इसका कोई सही जवाब नहीं था
    अगर Docker-Compose की वजह से आप Docker छोड़ने में हिचक रहे थे, तो Quadlet के साथ Podman कहीं ज़्यादा मुकाबले लायक विकल्प है
    आपको शायद Docker उतना याद नहीं आएगा जितना सोचा था, और rootless containers चलाने से security में सुधार भी मिलेगा

    • जब तक कई स्वतंत्र Quadlet environments रखना संभव नहीं होता, मैं स्विच नहीं करूँगा/करूँगी
      सब कुछ ~/.config/quadlet/systemd में डालने वाला तरीका काम नहीं करेगा
      development और testing के लिए यह ज़रूरी है, और अभी Quadlet सख्ती से deployment solution है

  • Quadlet मुझे वाकई पसंद है क्योंकि यह containers को सामान्य system services की तरह इस्तेमाल करने देता है
    लेकिन rootless containers का user experience इस conceptualization से अच्छी तरह मेल नहीं खाता
    आम तौर पर system services, systemd के system session में system user के रूप में चलती हैं, लेकिन rootless container की services, system user के user systemd session में मौजूद होती हैं
    अच्छा होगा अगर system session के अंदर rootless Quadlet चलाया जा सके

    • मैं सोच रहा/रही हूँ कि user-linger enable करके user systemd के जरिए rootless चलाने से व्यावहारिक तौर पर कोई फर्क है क्या
      मैंने हमेशा यही किया है
    • मैं भी चाहता/चाहती हूँ कि system session के अंदर rootless Quadlet चलाया जा सके
      साथ ही, अच्छा होगा अगर DynamicUser= option के साथ rootless Quadlet चलाया जा सके
      DynamicUser= system service permissions को सीमित करने का शानदार तरीका था, लेकिन अभी Podman के साथ अच्छी तरह फिट नहीं बैठता

  • Hacker News के front page पर Quadlet देखना दिलचस्प है। मुझे लगता है इसे पर्याप्त attention नहीं मिला
    project के Ygal और Valentin ने inlets tunnel client चलाने के तरीके पर एक guest post भेजी थी। यह Ngrok/Cloudflared जैसा है, लेकिन SaaS limitations के बिना self-hosted तरीके से
    https://inlets.dev/blog/2023/10/03/client-quadlet.html
    उन्होंने [container] की जगह [kube] इस्तेमाल किया, जिससे standard Kubernetes YAML लिया जा सका, और portability काफी बेहतर हो गई

  • जिनकी रुचि हो, उनके लिए मैंने हाल ही में एक Ansible template बनाया है, जो दिखाता है कि Quadlet deployment कितना आसान है
    GH: https://github.com/Mati365/hetzner-podman-bunjs-deploy