Quadlet: Podman konteynerlerini systemd ile çalıştırmak

 (mo8it.com)
2 puan yazan GN⁺ 2025-03-25 | 1 yorum | WhatsApp'ta paylaş
  • Podman daemon’sız olduğu için, sunucu açıldıktan sonra konteynerleri güvenilir biçimde ayağa kaldıracak bir yürütücüye ihtiyaç duyar; Quadlet bunu systemd servis dosyası yaklaşımıyla çözer
  • Mevcut podman generate systemd yönteminde konteyner oluşturma ile servis dosyası üretimini ayrı ayrı ele almak gerekiyordu; üretilen dosyayı her değiştirmede elle düzenleme yükü oluşuyordu
  • Quadlet, ~/.config/containers/systemd altındaki .container dosyasında [Container], [Service], [Install] ayarlarını birlikte tutarak Podman seçeneklerini ve systemd davranışını tek yerden yönetir
  • Rootless Podman’da açılışta otomatik başlatma için WantedBy=default.target ve linger’ın etkinleştirilmesi gerekir; multi-user.target kullanıcı modunda tanımlı değildir
  • AutoUpdate=registry, systemd bağımlılıkları, dizinlere göre dosya gruplama ve podlet dönüştürme aracı da kullanıldığında Quadlet, rootless·daemonless Podman işletimine iyi uyar

Quadlet neden gerekli?

  • Quadlet, Podman konteynerlerini systemd servisi gibi çalıştırmayı sağlayan bir yöntemdir
    • Konteynerleri arka planda çalıştırabilir
    • Sunucu yeniden başlatıldıktan sonra konteynerleri otomatik başlatabilir
  • Podman konteynerlerini systemd altında çalıştırma yaklaşımı yeni değildir
    • Daha önce podman generate systemd komutu kullanılıyordu
    • Bu komut artık Quadlet’e geçilmesini öneren bir kullanımdan kaldırma uyarısı gösteriyor
  • Podman daemonless bir yapıya sahip olduğundan, daemon olmadan konteynerleri başlatacak bir yürütücüye ihtiyaç duyar

Mevcut podman generate systemd yönteminin zahmetleri

  • Eski yöntemde önce podman create ile konteyner oluşturmak gerekiyordu
    • Örnek konteyner docker.io/library/postgres:16 imajını kullanır
    • -p 5432:5432, volume mount, POSTGRES_PASSWORD ortam değişkeni ve io.containers.autoupdate=registry label’ını içerir
  • Ardından podman generate systemd test-db -fn --new çalıştırılarak container-test-db.service dosyası oluşturuluyordu
  • Oluşturulan servis dosyası ~/.config/systemd/user içine yerleştirilip aşağıdaki komutla etkinleştiriliyor ve başlatılıyordu
    • systemctl --user enable --now container-test-db
  • Bu akış; konteyner oluşturma, servis dosyası üretme, gerekirse dosyayı taşıma ve servisi etkinleştirme adımlarını tekrar ettirir
  • Konteyner oluşturma komutu uzadıkça, daha sonra yeniden çalıştırmak için ayrıca bir shell script yönetmek gerekiyordu
  • Oluşturulan systemd servis dosyasını özelleştirmek için her seferinde yeniden elle düzenleme yapmak gerekiyordu

Quadlet dosya yapısı

  • Quadlet yaklaşımında ~/.config/containers/systemd dizini oluşturulur ve içine .container dosyası konur
  • Örnek test-db.container dosyası şu öğeleri içerir
    • [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 dosyası normal bir systemd servis dosyasıdır, ancak özel bir [Container] bölümü içerir
  • [Container] içindeki birçok seçenek, podman create ile kullanılan komut satırı seçeneklerine karşılık gelir
    • Image: kullanılacak imaj ve tag
    • AutoUpdate=registry: --label "io.containers.autoupdate=registry" karşılığıdır
    • PublishPort: -p karşılığıdır
    • Volume: -v karşılığıdır
    • Environment: -e karşılığıdır
  • Kullanıcı home dizini için ~ yerine systemd belirteci olan %h kullanılmalıdır
  • [Service] içindeki Restart=always, elle durdurulmadığı sürece konteynerin her zaman yeniden başlatılmasını sağlar
  • [Install] içindeki WantedBy=default.target, konteynerin açılışta otomatik başlatılmasını sağlar

Rootless Podman’da gerekli systemd ayarları

  • Rootless konteynerlerde multi-user.target değil default.target kullanılmalıdır
    • multi-user.target, systemd kullanıcı modunda tanımlı değildir
    • systemctl --user status multi-user.target ile kontrol edilebilir
    • Sistem modunda systemctl status multi-user.target ile kontrol edilebilir
  • Konteynerler systemd kullanıcı servisi olarak çalıştığından, kullanıcı oturum açmasa da konteynerlerin başlaması isteniyorsa linger etkinleştirilmelidir
    • loginctl enable-linger
  • Sunucu yeniden başlatıldıktan sonra otomatik başlatma gerekiyorsa linger’ın etkinleştirilmesi şarttır
  • systemd’nin yeni servis dosyasını keşfetmesi için aşağıdaki komut çalıştırılır
    • systemctl --user daemon-reload
  • Konteyner başlatma ve durum kontrolü hem systemd hem de Podman tarafından yapılabilir
    • systemctl --user start test-db
    • systemctl --user status test-db
    • podman ps
  • Varsayılan konteyner adı, servis dosyası adının başına systemd- eklenmiş halidir
    • test-db.container için varsayılan konteyner adı systemd-test-db olur
    • Bu, çakışmaları önlemeye yönelik bir adlandırma kuralıdır
    • [Container] bölümündeki ContainerName seçeneğiyle doğrudan belirtilebilir

Quadlet’in operasyonel avantajları

  • Quadlet, konteyner servis ayarlarını tek dosyada yönetmeyi sağlar
    • Eski yöntemdeki gibi servis dosyasını üreten script ile üretilmiş servis dosyasını ayrı ayrı yönetmek gerekmez
  • systemd’nin [Unit] ve [Service] bölümlerinde kullanılabilen seçenekler kullanılabilir
    • Örneğin konteyner başlamadan önce çalıştırılacak komut StartExecPre ile belirtilebilir
    • Üretilmiş dosyayı sonradan elle düzeltme süreci azalır
  • Shell script yazıp debug etmek yerine, konteynerleri yapılandırma dosyası merkezli işletebilirsiniz
  • Konteynerler arası bağımlılıkları systemd yöntemiyle ifade etmek kolaydır

Konteynerler arası bağımlılıkları ifade etme

  • Bir uygulama konteyneri veritabanı konteynerine bağımlıysa, ilişki systemd’nin [Unit] bölümüyle belirtilebilir
  • OxiTraffic konteyneri, test-db konteynerine bağımlı bir örnektir
    • [Unit] içinde Requires=test-db.service ayarlanarak uygulamanın yalnızca veritabanı başladığında başlaması sağlanır
    • İki konteynerin paralel başlamaması için After=test-db.service ayarlanır
  • Referans verirken .container dosya adı değil servis adı kullanılır
    • test-db.container: dosya adı
    • test-db.service: servis adı
    • systemd-test-db: varsayılan konteyner adı
  • Uygulamanın veritabanıyla iletişim kurabilmesi için iki konteynerin de [Container] bölümüne Network seçeneği eklenmelidir; ancak burada ağ yapılandırması ele alınmıyor

Birden fazla dosya ve gruplama

  • Quadlet, her konteyner için ayrı bir .container dosyası kullanılacak şekilde yapılandırılabilir
  • Çok konteynerli bir uygulamada her şeyi tek bir Docker Compose dosyasına koymaya kıyasla, konteyner bazlı dosyalar bilişsel yükü azaltabilir
  • Docker Compose dosyası yüzlerce satır ve onlarca konteyner içerdiğinde bakımı zorlaşabilir
  • Docker Compose da dosyaları birden fazla parçaya bölmeyi destekler
  • Quadlet, ~/.config/containers/systemd altındaki dizinlere unit dosyaları koyabilir
    • Örnekte oxitraffic dizini oluşturulup uygulama ve veritabanı dosyaları birlikte konabilir

İmaj güncellemeleri

  • AutoUpdate=registry ayarlanırsa podman auto-update ile imaj güncellemeleri kontrol edilebilir
  • Registry’de kullanılan tag ile uyumlu yeni bir imaj varsa Podman imajı pull eder ve konteyneri yeniden başlatır
  • Docker’da bu amaç için Watchtower gibi araçlar gerekebilir; Podman ise bu özelliği yerleşik olarak sunar
  • latest gibi tag’ler riskli olabilir
    • OxiTraffic’te latest, sonraki sürümdeki breaking change’leri içerebilir
    • PostgreSQL’de latest kullanılırsa yeni major sürüme geçilebilir ve PostgreSQL major yükseltmelerinde her zaman elle migration gerekir
  • Üretim ortamında breaking change’e yol açmayacak tag’ler kullanılmalıdır
  • podman auto-update birkaç günde bir elle çalıştırılıp nelerin güncellendiğini görmek ve ardından konteynerlerin normal çalıştığını kontrol etmek de mümkündür

podman-compose ve migration araçları

  • podman-compose, Compose dosyalarını Podman ile çalıştıran bir Python script’idir
  • Uzun vadeli bir Docker Compose alternatifi olarak görülmesinin zor olmasının nedenleri şunlardır
    • Compose spesifikasyonu ile Podman·systemd arasında bir çeviri katmanıdır ve systemd’nin tüm özelliklerini kullanmanızı sağlamaz
    • Resmî Podman projesi Rust veya Go gibi derlenen dillerle yazılır
    • Son commit 5 ay önce olduğu için aktif biçimde bakımı yapılmıyor
  • Quadlet, Podman’ın rootless·daemonless tasarımıyla daha iyi örtüşür
  • Compose dosyasından Quadlet’i denemek için podlet kullanılabilir
    • Podman komutlarından veya Docker Compose dosyalarından Quadlet dosyaları oluşturabilen bir Rust aracıdır

Daha fazla okuma

İlgili okumalar

1 yorum

 
GN⁺ 2025-03-25
Hacker News yorumları

  • Quadlet, Podman’dan çıkan en iyi şeylerden biri sayılır; Podman’ı merak edenlere ya da konteyner tabanlı iş yüklerine geçmeyi düşünenlere şiddetle tavsiye ederim
    Konteynerleri sıradan sistem servisleri gibi araya yerleştirip yönetebilirsiniz; birlikte çalıştırmak için ayrı bir orkestrasyon katmanı öğrenmeniz ya da konteyner dışı kaynaklara bağımlı olmanız gerekmez
    Zaten yazdığınız systemd unit’lerini olduğu gibi yazarsınız; otomatik güncellemeler ya da hata durumunda servisi yeniden başlatma/bildirim gibi şeyler de bonus
    Docker ile benzerini yapmaya çalıştığınız yaklaşım, dev bir run komutuyla Docker daemon’ını dolanırken çoğu zaman geride hayalet servisler ve konteynerler bırakıyordu; Quadlet çok daha temiz ve yapılandırma da /etc/systemd/, .config/systemd, /usr/local/lib/systemd gibi systemd unit konumlarında durduğu için yedeklemesi kolay
    Ancak yerel geliştirmede docker-compose’un karşılığı değil; Podman ekibi de o alana pek ilgi duymuyor gibi
    Kullanıcı konteynerleri, arka planda çalışan veritabanları gibi uzun süreli yerel test altyapısı için iyi; ama tipik derleme → docker compose up → test → docker compose down döngüsü için fazla zahmetli
    Pratik cevap ya .kube Quadlet (Kubernetes play) ya da Podman soketine karşı docker compose kullanmak
    Aylardır boş zamanlarımda Quadlet yöneten bir GitOps aracı yapacak kadar hoşuma gitti; konteynerleştirilmiş sunucuları yönetmenin doğru yolu gibi hissettiriyor
    [0]’ın podman-compose olmadığı nokta önemli. Yazıda da podman-compose’un pek iyi olmadığı ve geliştirme açısından eksik kaldığı belirtilmişti. Podman, compose spesifikasyonunun çoğunu uyguladığı için çoğu durumda docker compose kullanabilirsiniz
    RH ilk Podman’ı öne çıkarmaya başladığında deneyenlerin, Podman 3’ün muğlaklığı ve podman-compose’un kötü deneyimi yüzünden uzaklaşmış olması çok olası

    • RH yaklaşımına daha yakın gitmek istediğim için Quadlet ve podlet kullanmayı denedim, ama Podman üzerindeki docker compose’tan geçiş deneyimi berbat oldu
      Çeşitli flag’leri değiştirmek, sürüm yükseltmek ve podlet’in kendisinin başka bir araca geçmeyi önermesi derken iş bitmeyen bir tavşan deliğine dönüştü
      Sonunda benim systemd’m sadece podman compose up çalıştırıyor
      Compose’un kendi işini yapmasına izin vermekle karşılaştırınca Quadlet’in avantajı ne, merak ediyorum
      Bu arada Podman benim kullanıcım olarak çalışıyor ve hiç daemon yok
    • Geliştirme için püf noktası Podman soketini açmak; rootless konteynerlerse kullanıcı düzeyinde açıp bağımsız docker-compose kullanmak
    • Windows ya da Mac’te systemd kullanılamadığı için geriye yalnızca podman compose kalıyor

  • Yakın zamanda Quadlet’i keşfettim ve tüm homelab’imi atomic OS ve rootless Quadlet üzerine kurdum; kesinlikle tavsiye ederim
    systemd soket aktivasyonu da mümkün; örneğin systemd http/https soketleri oluşturup, ssh.socket ve podman.socketın sırasıyla sshd.service, podman.serviceı etkinleştirmesi gibi Traefik’i otomatik etkinleştirebilirsiniz
    Rootless kurulumda kaynak IP’yi korumanın fiilen tek yolu olduğu için adeta hayat kurtarıcı. Rootless Podman/Docker normalde kaynak IP korumaya büyük dezavantajlar olmadan kolayca izin vermez
    https://github.com/savely-krasovsky/homelab

    • Traefik’in etkinleşmesinin ne kadar sürdüğünü merak ediyorum

  • Quadlet, “üretime benzer bir ortamda birbirine bağımlı konteynerlerin hepsini çalıştırma” şeklindeki docker compose kullanımı için iyi bir alternatif
    Ancak docker compose’un bir diğer kullanım alanı olan geliştirme tarafında daha iyi olmasını isterdim
    docker compose ile veritabanı, Redis, OpenSearch, diğer bağımlılıklar, nginx proxy’si ve .:/app yolunu volume olarak mount eden geliştirme konteynerini birlikte ayağa kaldırıp birlikte kaldırabiliyor, docker-compose.yml dosyasını depoya koyabiliyorsunuz
    Quadlet ise tüm dosyaları ~/.config/containers/systemd altına koymanızı söylediği için artık projeye izole olmuyor; diğer geliştiricilerle check-in edip paylaşmak da pek rahat değil. Üstelik onların da Podman kullanması gerekiyor
    Çoğunluk hâlâ Docker kullanıyor, Codespaces gibi barındırılan geliştirme ortamlarında da Docker sağlanıyor
    Bu yüzden check-in edilmiş YAML dosyasıyla docker compose kullanıyorum. Ben Podman kullandığım için tüm volume’lara elle :Z eklemem gerekiyor, ama normal Docker bunu işleyemiyor
    Geliştirme için bir docker compose alternatifi olsa güzel olurdu ama Quadlet pek uygun görünmüyor

    • podman-compose --in-pod=1 systemd -a create-unit kullanırsanız podman-compose@ servisini oluşturabilir, ardından podman-compose systemd -a register ile compose.yml dosyasını $name ile birlikte kaydedebilirsiniz
      Böylece compose dosyası tabanlı pod’u podman-compose@$name.service ile yönetebilirsiniz; tamamen rootless olarak da çalışır
    • Bu durumda aradığınız şey Podman pod; ben de tamamını Ansible ile orkestre eder, ardından Ansible playbook’unu herkese dağıtıp yerelde çalıştırmalarını sağlardım
    • systemd-run, rastgele bir komuta dayalı geçici systemd servisi çalıştırmanızı sağlar
      Gerekirse timer dâhil, systemd kapsam kurallarına uyan temiz bir geçici unit oluşturur
      [1] https://www.freedesktop.org/software/systemd/man/systemd-run...
    • Quadlet’i genel olarak dağıtım için daha uygun görüyorum. compose alternatifi arıyorsanız Podman Kube Play’e[1] bakmanız daha iyi olur
      Kubernetes’e benzer bir formatta, konteyner build etme gibi birkaç kolaylık özelliği eklenmiş
      kube play dosyasını proje köküne koyup podman kube play project.yaml --build çalıştırırsanız pod, volume vb. birlikte çalışır
      Quadlet dosyaları dağıtım aşamasında kullanışlıdır. Projeyi bir VPS’e koymak istiyorsanız, elinizdeki project.yaml ile birlikte Kube Quadlet[2] kullanabilirsiniz
      [1] https://docs.podman.io/en/latest/markdown/podman-kube-play.1...
      [2] https://docs.podman.io/en/latest/markdown/podman-systemd.uni...
    • Bizim şirkette de geliştirme için docker-compose.yml kullanılıyor, o yüzden acıyı anlıyorum
      Genel olarak gayet iyi çalışıyor ama OSX’te o lanet ara VM yüzünden bazen garip davranabiliyor
      Ara sıra Podman uyumluluğunu kontrol ediyorum, ama artık rootless felsefesinin çok farklı olduğunu ve tam uyumluluğun imkânsız olduğunu kabullendim
      Yine de bu araç production için harika. Birkaç hobi projemi bare-metal node’da elle yazılmış systemd servisleriyle çalıştırıyorum; şu anda kullanıcı modunda containerd kullanıyorlar
      Vakit bulursam taşımayı deneyebilirim

  • Bu yazının Podman-Compose için “aktif olarak bakımı yapılmıyor” deyip son commit’in 5 ay önce olduğunu belirtmesi, ardından hemen alternatif olarak son commit’i yine 5 ay önce olan Podlet’i önermesi ilginç
    Podlet faydalı olabilir ama Docker Compose’un birçok özelliğini desteklemiyor ve her zaman temiz bir dönüşüm de yapmıyor
    Özellikle -f docker-compose.yml -f docker-compose.override.yml gibi birden fazla YAML dosyasını üst üste bindirme özelliğini desteklemiyor

    • compose dosyalarını seviyorsanız Docker’ın compose uygulamasını[1] Podman[2] ile birlikte kullanabilirsiniz
      compose CLI soket üzerinden motoru kontrol ediyor gibi görünüyor; Podman ile Docker engine neredeyse aynı API’ye sahip
      podman-compose beklendiği gibi çalışmadığı için bu yöntemi kullanıyorum
      Docker-compose normalde docker istemci eklentisi olarak kuruluyor, ama ben Podman ile kullanmak için bağımsız bir uygulama olarak kullanıyorum
      Ayrıca entegrasyon ayarlarında DOCKER_HOST ortam değişkeni yerine docker contexts kullanmayı tercih ediyorum
      Sadece Quadlet yeterince güçlü değilse Quadlet[3] ve normal Podman[4] da sınırlı Kubernetes manifest’lerini çalıştırmayı destekliyor
      compose dosyasındaki restart seçeneğini Podman’ın nasıl ele aldığını henüz çözemedim. Çünkü Podman’da bir denetleyici daemon yok
      Öte yandan healthcheck seçeneğinin systemd timer’larına dayandığını biliyorum
      systemd olmayan bir dağıtım olan Gentoo’da Podman kullanırken otomatik healthcheck çalışmadı, ama healthcheck’i elle çalıştırınca ayarların geri kalanı sonuna kadar ilerledi
      [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...
    • Adil olmak gerekirse Podlet işlevleri sürekli güncelleme gerektirmiyor; podman compose için ise durum öyle değil
      Podlet yardımcı bir araç ve uzun vadede Quadlet ile çalışmak daha iyi
    • Commit tarihi, bir şeyin bakımının yapıldığını göstermek için kesin bir ölçüt değildir ama bakımının yapılmadığını gösterebilir
      5 ay, bakım yapılmıyor demek değildir; bunun için yaklaşık 2 yıl gerekir
      Yine de endişeyi artırır. Ancak 5 ay kesinlikle bakımın sürdüğüne dair kanıt değildir
      Bakımı yapılmayan depoların da güncellenmesi için pek çok neden olabilir; bunu engelleyen tek şey GitHub’ın son dönemde pek iyi olmayan arşivleme özelliği

  • Birkaç yıl önce self-hosting kurulumumu sıfırlarken farklı bir şey denemek istediğim için openSUSE MicroOS seçtim ve sonunda Podman konteynerlerini systemd/Quadlet altında çalıştırmaya başladım; mevcut kurulumdan oldukça memnunum
    Konteynerler Podman’ın yerleşik araçlarıyla otomatik güncelleniyor, log kontrolü ve izleme işlerini de her zamanki systemd araçlarıyla yapıyorum
    Bir şeyi değiştirmem gerektiğinde yapılandırma dosyalarının yerini unutmuş olsam bile bulması kolay, okuyup değiştirmesi de kolay
    Rootless ve daemonless olması da güzel
    Arada birkaç şey denedim ama podman compose hantal hissettirdi; deprecated olmasına sevindim ve gidilecek yolun Quadlet olduğu açık
    Bir öğrenme eğrisi olduğunu ve Docker’a göre daha az kaynak bulunduğunu hesaba katmak gerekiyor
    Yerel geliştirmede birden fazla servis yığınını ayağa kaldırıp indirmek için hâlâ Docker ve docker compose tarafını seçerdim

    • Ucuz, eski bir workstation üzerinde Fedora CoreOS ile Nextcloud çalıştırıyorum
      Ayarları oturtmak biraz zaman aldı ama neredeyse hiç bakım gerektirmemesinden çok etkilendim. Şimdiye kadar hiç gerekmedi
      Benzer bir şey yapmak isteyenler yapılandırmama bakabilir
      https://github.com/jeppester/coreos-nextcloud
    • Quadlet + MicroOS kombinasyonu çok güçlü; Fedora CoreOS gibi diğer atomic dağıtımlar için de aynı şey geçerli
      Tüm node’ları yavaş yavaş MicroOS’a taşıyorum ve şirkette de MicroOS’u ya da benzer bir şeyi öne çıkarıyoruz
      Temel OS’in otomatik rollback’i ile bildirime dayalı konteyner yapılandırması ve otomatik güncellemeler birleşimi birbirine tam oturuyor gibi

  • Biçim, podman generate systemd ya da Kubernetes YAML’dan daha anlaşılır ve systemd entegrasyonu da harika
    Can sıkıcı nokta, Podman upstream’in Debian/Ubuntu için depo sunmaması
    Debian stable’da 4.3.1’e takılı kaldım ve birçok yeni özelliği kaçırdım; sonunda Docker compose’a dönmeye karar verdim

    • Debian çalıştıran Raspberry Pi üzerinde Quadlet kullanmaya çalışırken aynı sorunla karşılaştım
      Önerilen geçici çözümler Podman’ı kendiniz derlemek ya da debian/testing kullanmaktı

  • Bu yeni yaklaşımın insanların Docker’dan Podman’a geçmesine gerçekten yardımcı olmasını umuyorum
    Docker-Compose, birçok kişinin geçişte tereddüt etmesinin nedeni; bende de öyleydi
    Kabul etmek gerekirse Quadlet’ten önce Podman’ın düzgün bir yanıtı yoktu
    Docker-Compose yüzünden Docker’dan ayrılmakta tereddüt ettiyseniz, Quadlet ile birlikte Podman çok daha denk bir alternatif
    Sandığınız kadar Docker’ı özlemeyeceksiniz; ayrıca rootless container çalıştırarak güvenlik iyileştirmesi de elde edebilirsiniz

    • Birden fazla bağımsız Quadlet ortamına sahip olabilene kadar geçiş yapmayacağım
      Her şeyi ~/.config/quadlet/systemd içine koyma yaklaşımı olmaz
      Geliştirme ve test için bu şart; şu anda Quadlet kesinlikle bir dağıtım çözümü

  • Quadlet’i gerçekten seviyorum; container’ları sıradan sistem servisleri gibi kullanmayı sağlıyor
    Ancak rootless container kullanıcı deneyimi bu kavramsallaştırmaya pek uymuyor
    Normalde sistem servisleri systemd’nin sistem oturumunda, sistem kullanıcısı olarak çalışır; rootless container servisleri ise sistem kullanıcısının kullanıcı systemd oturumunda bulunur
    Rootless Quadlet’i sistem oturumu içinde çalıştırabilmek güzel olurdu

    • user-lingerı açıp kullanıcı systemd’si üzerinden rootless çalıştırmaktan pratikte bir farkı olup olmadığını merak ediyorum
      Ben hep böyle yaptım
    • Ben de sistem oturumu içinde rootless Quadlet çalıştırabilmeyi isterdim
      Ayrıca DynamicUser= seçeneğiyle rootless Quadlet çalıştırabilmek de güzel olurdu
      DynamicUser= sistem servislerinin yetkilerini kısıtlamak için harika bir yöntemdi, ama şu anda Podman ile pek iyi uyuşmuyor

  • Hacker News’in ön sayfasında Quadlet’i görmek ilginç. Yeterince ilgi görmediğini düşünüyorum
    Projeden Ygal ve Valentin, inlets tünel istemcisini çalıştırma yöntemi hakkında daha önce konuk yazı göndermişti. Ngrok/Cloudflared benzeri, ama SaaS kısıtlamaları olmadan self-host edilen bir yaklaşım
    https://inlets.dev/blog/2023/10/03/client-quadlet.html
    [container] yerine [kube] kullanarak standart Kubernetes YAML’ını kullanabildiler; bu da onu epey taşınabilir hale getiriyor

  • İlgilenenler için, yakın zamanda Quadlet dağıtımının ne kadar kolay olduğunu gösteren bir Ansible şablonu hazırladım
    GH: https://github.com/Mati365/hetzner-podman-bunjs-deploy