Docker'dan Podman'a Geçmemin Nedeni

• Docker, arka plan daemon'u (dockerd) mimarisi nedeniyle güvenlik açıkları ve kaynak tüketimi sorunlarıyla uzun süredir eleştiriliyor
• Podman, daemon'suz bir mimari benimsediği için container'lar kullanıcı yetkileriyle doğrudan çalışır; bu da saldırı yüzeyini azaltır ve kararlılığı artırır
• Systemd entegrasyonu, Kubernetes dostu tasarım ve Buildah/Skopeo gibi Unix felsefesine dayalı ayrık araçlar desteği sayesinde operasyonel verimlilik yükselir
• Docker CLI ile yüksek uyumluluk sunduğundan, yalnızca alias docker=podman ile mevcut iş akışlarının çoğu aynen çalışır
• Gerçek operasyon ortamlarında da güvenlik ve kaynak yönetimi sadeleşir; yeni projelerde Podman, daha makul ve geleceğe dönük bir seçenek haline geliyor

---

Docker'ın sınırlamaları ve güvenlik sorunları

• Docker, dockerd daemon'unun her zaman root yetkisiyle çalıştığı bir yapıya sahiptir
  • Daemon'da bir açık bulunursa tüm host risk altına girebilir
• Başlıca güvenlik olayı örnekleri
  • 2019: runC container escape (CVE-2019-5736)
  • 2022: Linux Dirty Pipe açığı, cgroups v1 escape
  • 2024: runC “Leaky Vessels”, BuildKit açığı
  • 2024: Docker API açığa çıkarılması üzerinden yürütülen cryptojacking kampanyası
• Bu tür olayların tekrarlanması, daemon tabanlı mimarinin temel riskini ortaya koydu

Podman'ın daemon'suz mimarisi

• Podman, arka planda daemon kullanmaz
  • podman run çalıştırıldığında container, komutu çalıştıran kullanıcının doğrudan child process'i olarak işler
  • Rootless modda çalıştığı için container içindeki root yetkisi de host üzerinde yalnızca normal kullanıcı yetkisine karşılık gelir
• Avantajları
  • Daha güçlü güvenlik: container escape yaşansa bile etki alanı küçülür
  • Daha yüksek kararlılık: bir container çökse bile diğerleri etkilenmez
  • Kaynak verimliliği: gereksiz bir daemon sürekli çalışmadığı için bellek kullanımı azalır

Podman'ın öne çıkan özellikleri

• Systemd entegrasyonu
  • podman generate systemd ile systemd unit dosyaları otomatik oluşturulabilir
  • Standart systemctl komutlarıyla servis yönetimi yapılabilir
• Kubernetes uyumluluğu
  • Pod kavramı yerleşik olduğu için çok container'lı uygulamalar geliştirmek kolaydır
  • podman generate kube ile doğrudan Kubernetes YAML üretilebilir
• Unix felsefesi
  • Podman container çalıştırmaya odaklanır; image build için Buildah, registry yönetimi için Skopeo kullanılır
  • Böylece amaca göre optimize edilmiş araçlardan yararlanılabilir

Geçiş süreci ve uyumluluk

• Docker'dan Podman'a geçiş neredeyse kesintisizdir
  • CLI uyumlu olduğu için docker yerine doğrudan podman kullanılabilir
  • Mevcut Dockerfile'lar da aynen çalışır
• Farklı noktalar
  • Rootless modda 1024 altındaki portlara bind edilemez → reverse proxy önerilir
  • Volume izinlerinin yönetilmesi gerekir
  • Docker socket'e bağımlı araçlar için Podman'ın Docker API uyumluluk modu kullanılabilir

Gerçek kullanımda uygulama ve faydalar

• Operasyon ortamında Podman kullanıldıktan sonra
  • Güvenlik denetimi yükü hafifler, rootless güvenlik varsayılan olarak uygulanır
  • Kaynak kullanım modeli daha sade ve öngörülebilir hale gelir
• Docker hâlâ yaygın olsa da, yeni projelerde veya teknoloji seçimi esnekse Podman daha uygun olabilir
  • Linux yönetim sistemiyle doğal entegrasyon
  • Kubernetes odaklı mimari
  • Daha güvenli ve daha makul bir container çalıştırma ortamı

FastAPI geçiş rehberi özeti

• Mevcut Dockerfile aynen kullanılabilir
• podman build, podman run ile kolayca değiştirilebilir
• podman generate systemd ile systemd servisi olarak kaydedilebilir
• Pod kullanarak DB gibi çok servisli ortamlar desteklenebilir
• Docker Compose iş akışı, podman-compose veya kompose dönüşümüyle karşılanabilir

[shortstories]

Burada kesintisiz geçişin mümkün olduğu yazıyor ama gerçek üretim ortamında epey tuhaflık var. Örneğin mac ortamında varsayılan ayarda zstd sıkıştırması kullanıldığı için, oluşturulan imajların registry’de epey sorun çıkardığı gibi..

[codemasterkimc]

Docker da Podman da....

securityContext:
allowPrivilegeEscalation: false
capabilities:
drop:
- ALL

securityContext:
runAsNonRoot: true
runAsUser: UID

[koxel]

Aslında Docker uyumluluğu pek iyi olmadığı için kullanım deneyimi çok da iyi değil...
Rootless diye düşünüp Podman'a geçtim ama sonra tekrar Docker'a döndüm.
Diğerlerinin dediği gibi Kubernetes ile kullanacaksam zaten doğrudan containerd kullanırım.

[click]

Docker compose düzgün çalışmıyorsa ve Kubernetes uyumluluğunun iyi olması avantajıysa, o zaman doğrudan Kubernetes kullanmak gerekmez mi diye düşünüyorum.
Ben de denemeye kalktım ama tek seferde çalışmadı; ayrıca 1024 altındaki port eşlemesini de doğrudan yapamadığı için, ben sadece k3s ile image build için nerdctl kombinasyonunu kullanıyorum.

[ndrgrd]

Bir gün değiştirmek istiyorum ama daha önce denediğimde, geliştiricilerin söylediğinin aksine çok fazla docker compose projesi düzgün çalışmıyordu...

[afewgoodman]

Docker network desteği yok ya.

[devsepnine]

Docker’a benzer şekilde ağ özelliklerini de desteklediğini biliyorum.
Hâlâ düzgün çalışmayan bir şey var mı?

[GN⁺]

Hacker News görüşleri

• 2001/2002'de WiFi hotspot kutuları kurmam gerekiyordu. O zamanlar bir OpenBSD hayranıydım ve Python tabanlı dağıtımı olabildiğince hafif tutmak istiyordum. Gereksiz dosya kopyalamalarından ve bağımlılık sorunlarından kaçınmak için chroot ve jail kavramlarını seçtim. Dağıtım kodum yazılımı jail ortamının dışında çalıştırıyor, ptrace ile sürecin açtığı dosyaları izliyordu. Bu çıktıyla bağımlılık listesini çıkarıp paketledim. Sonuçta dağıtım küçük kaldı, değişmezlik korundu ve güvenlik de güçlendi. Docker çıktığında bana eski yöntemi hatırlattı; gerçekten de Docker container dosya kullanımını izleyip dağıtımı küçülten benzer bir araç olup olmadığını merak ediyorum
  • Kullandığım en iyi CI/CD pipeline, Django freelance dağıtımıydı. Her git push için git post-receive hook ile statik dosya build etme ve httpd yeniden başlatmayı otomatikleştiriyordum. Sadece git push live master diyordum, dağıtım oluyordu. Docker'ı çok kullandım ama en kolay dağıtım buydu. Docker'ın avantajlarını anlıyorum ama Ubuntu ya da OpenBSD'de HTTP ayarlamak o kadar da zor değil. Docker'ın sunduğu tekrarlanabilirlik gerçekten o yönetim overhead'ine değecek kadar değerli mi, emin değilim
  • Google aramasındaki ilk sonuçta 22k yıldıza sahip slimtoolkit/slim var
  • OpenWrt ortamında ujail diye bir araç var; ELF çalıştırılabilir dosyasını verirsen gerekli kütüphane bağımlılıklarını parse ediyor ve tmpfs üzerinde yalnızca gerekli dosyaları salt okunur biçimde mount ediyor
    İlgili kod bağlantısı
• Podman benim için gerçekten harika bir deneyim. Docker kullanımı bana zor ve tuzaklarla dolu geliyordu, ama Podman hiç geri kalmıyor. En önemlisi de çalıştığım şirkette lisans konusunda endişe etmemize gerek yok. Tam bir kazan-kazan
  • Şirkette lisansın gerçekten bir endişe konusu olup olmadığını merak ediyorum. Docker Desktop ücretli lisans politikası makul. 250'den az çalışanı olan ya da geliri 10 milyon doların altında olan şirketler için ücretsiz. Lisans ücreti yılda 90 dolar olsa bile, ABD'li geliştirici maaşları düşünülünce öğle yemeği parası bile değil. Üstelik tüm işletim sistemlerinde resmi destekli araçları kullanabiliyorsun
  • Aslında şirketin lisans konusunda çok da endişelenmesine gerek yok. Docker Engine tamamen açık kaynak ve ücretsiz. Sadece Docker Desktop'ı kurumsal kullanımda kullanıyorsan ayrı lisans gerekiyor. Ama çoğu özellik zaten Docker Engine'de mevcut
  • Podman, Docker'dan çok daha iyi. Kullanıcı/grup izinleri veya root süreç güvenliği konusunda endişelenmene gerek kalmıyor. Veriyi bir daemon'a göndermene de gerek yok
  • Bazı PC'lerde Podman'ın Windows uninstall aracı tüm bileşenleri düzgün silmiyor, bu yüzden yeniden çalıştırınca hata kalıyor. Hizmetleri elle silmek de sorunu çözmüyor. Oldukça sık can sıkıcı bir durum
• Podman'ı çok seviyorum ama her container'da her zaman iyi çalışmıyor. Örneğin gitlab gibi büyük container'lar, Docker'ın karmaşık geçmişine ve tuhaflıklarına dayandığı için podman'da sık sık hata veriyor. Kendi yaptığım image'ların çoğu podman'da iyi çalışıyor. Sorunlu container'lar için incus VM başlatıp içinde çalıştırarak dolaşıyorum. Podman ve Docker'ın ikisinde de GPU erişimi tutarlı değil, bu da rahatsız edici. Yine de podman'ın biraz daha iyi olduğunu düşünüyorum. Özellikle rootless büyük avantaj
  • Sorunların çoğunun PID 1'i root olarak başlatan image'lardan kaynaklandığını tahmin ediyorum. Podman varsayılan olarak rootless olduğu için bu sorun ortaya çıkıyor. Docker olmadan root tabanlı image'lar da kullanmak istiyorsan Podman'ı rootful ve rootless modlarda ayrı tutup istediğin ortamı --connection bayrağıyla seçebilirsin. Gerekirse Podman otomatik VM de oluşturabilir (lima kullanarak). Podman Desktop'ta Docker uyumluluk katmanı da var, bu da uyumluluk sorunlarını azaltıyor
  • Bazı container'ların podman'da çalışmaması, bence blog yazısının çıkış noktası zaten. Kullanıcı kitlesi yeterince büyürse, yayınlamadan önce podman ortamını da kontrol etmek yerleşik bir alışkanlık haline gelir
  • Biz GitLab sunucusu ve runner'ların tamamını podman üzerinde çalıştırıyoruz. Ben şahsen runner'ları k8s'e taşımayı isterdim ama şu anda Traefik kullanarak gayet iyi çalışıyor
  • buildx ile ilgili özellikleri çok kullanıyorum; görünüşte podman'da da var gibi duruyor ama pratikte iyi çalışmıyor
• Ubuntu'da podman desteği en büyük sorun. Ubuntu'nun varsayılan podman sürümü çok eski, bu yüzden doğrudan kullanılamıyor. Ben podman v5 kullanıyorum, GitHub Actions v3 kullanıyor, ekip arkadaşlarım ise docker kullanıyor. Sonuçta script'lerimin eski podman, yeni podman ve docker'ın hepsinde çalışmasını sağlayacak bir karmaşıklık ortaya çıkıyor
  • Güvenilir bir .deb build deposu yok. Resmi .deb yok; bulduklarımın hepsi ya çok eski ya da artık güncellenmeyeceği söylenen yerlerdi. O zaman da şu soru kalıyor: Podman neden kurulumu daha kolay hale getirmiyor? Bana kalırsa RedHat, rakip bir ürünün desteğine geliştirme kaynağı ayırmak istemiyor. Anlaşılabilir ama RedHat ekosistemi dışında ikinci sınıf vatandaş muamelesi gördüğü hissi oluşuyor
  • Bence en büyük sorun bu. Docker'a kıyasla düşük bilinirlik de bir sorun ama sürüm uyumsuzluğu, Podman'ı niş bir çözüm haline getiren asıl neden. Ubuntu gibi dağıtımlar sık sık eski yazılım sunuyor; bunu sürdürücülerin çözmesi gerekse de Podman tarafı bu konuda çok aktif görünmüyor. Bu yüzden ben de home server'ımı en güncel Podman'ı kullanabilmek için Red Hat türevi bir sisteme geçirdim
  • Resmi upstream .deb paketlerinin sürekli sunulmaması, Podman'ı kurum içinde kullanamıyor olmamızın nedeni. Docker'ın resmi .deb deposu iyi yönetildiği için kıskandırıyor
  • Ubuntu/Debian'ın güncellemeleri çok yavaş verdiği için kullanmama nedenlerimden biri de bu. Belki flatpak ile kullanılabilir ama böyle yazılımların varsayılan olarak sağlanması daha iyi olurdu
  • Podman açık kaynak olduğu için Ubuntu gibi dağıtımlar bunu kendileri paketleyip güncelleyebilir. RedHat'in doğrudan rakip yazılım dağıtımları için paketleme desteği vermekte isteksiz olmasını da anlayabiliyorum
• Kısa süre önce iş gereği Podman kurulumu deneyimledim ve yaşadığım en kötü deneyimlerden biriydi. Rootless Podman + SELinux + container içindeki normal kullanıcı kombinasyonu tam anlamıyla cehennem
  • Aslında isterse insan her şeyi zorlaştırabilir ama pratikte çoğu şey iyi çalışıyor. SELinux etkin RHEL10 makinelerde nginx reverse proxy arkasında rootless container'larla birçok servisi (Forgejo, runner, uptime-kuma vb.) sorunsuz çalıştırıyorum
  • Rootless'ın faydasını hiç hissetmedim. Makine tek bir güvenlik domain'iyse root olarak çalıştırmakta sorun yok; değilse de gerçek bir izolasyon ortamı (ör. Firecracker/Kata VM vb.) kullanmak gerekir diye düşünüyorum. Rootless çok uğraştırıyor ama getirisi şüpheli
  • Ben de işte aynı durumla karşılaştım ama podman'a özgü yöntemle (dokümantasyona bakarak) çözünce kullanılabilir hale geldi. Önemli olan güncel sürümün dokümantasyonuna bakmak
  • Fedora'da 7 yıldan uzun süredir sadece podman kullanıyorum
  • Bizim organizasyon Docker'dan Podman'a tamamen geçti; arada bazı pürüzler oldu ama SysDev ekibinin yetkinliğiyle makul şekilde çözüldü
• Docker Compose workflow'n çok karmaşık hale gelirse doğrudan Kubernetes YAML'ına geç deniyor ama benim deneyimime göre K8s YAML, docker compose'dan çok daha karmaşık. Ayrıca herkes Kubernetes kullanmıyor
  • Ben tersini düşünüyorum. K8s YAML'ın karmaşıklığı docker compose ile benzer, hatta bazen daha bile basit olabiliyor. Sadece aşırı uzun. 100 satırlık bir compose dosyası, her biri 50 satır olan 20 YAML dosyasına bölünebiliyor. Keşke kubectl, basit/karmaşık YAML'lar arasında dönüşüm yapan sugar özelliklere sahip olsa
  • docker compose'u k8s yaml'a dönüştürürken LLM'i bir katman olarak kullanmak inanılmaz iyi çalışıyor. Bu arada podman'ın da k8s yaml üretme özelliği var, yani geçiş doğal şekilde yapılabiliyor
  • Ben compose dosyası yazmayı bilmiyorum ama k8s yaml yazabiliyorum. O yüzden compose bana daha "karmaşık" geliyor
• Yazıda geçen podman generate systemd komutu artık deprecated. Alternatif olarak Podman Quadlets var; bu da systemd unit dosyası içinde tanımlanan, docker-compose.yaml benzeri bir yaklaşım
  • Compose/orchestration işini systemd'ye bırakmak mantıklı. docker gibi client-server yapısı değil, doğrudan gerçek kullanıcı süreci olduğu için gayet yerinde bir tercih
  • Sorun şu ki neredeyse hiç dokümantasyon yok
• Çoklu UID kullanan container'ları tek bir host kullanıcısına map etmek zor. Varsayılan olarak container içindeki root, host'taki çalıştıran kullanıcıya map ediliyor ama son zamanlarda birçok uygulama container içinde root olmayan kullanıcılar (ör. www-data, kullanıcı 1000 vb.) kullanmaya başladı. Bunlar host'ta ikincil ID'lere map ediliyor; bu da volume mapping sırasında dosya sahiplerinin sahipsiz görünmesine ve ciddi kafa karışıklığına yol açıyor. Tüm UID'leri tek kullanıcıya map eden basit bir seçeneğin eksikliği hissediliyor ve mevcut seçenekler (crun'ın uidmap'i, userns) pek iyi çalışmıyor. İkincil ID eşlemenin gerçekten ne kadar işe yaradığı konusunda şüpheliyim
  • Doğru anlıyorsam bu, Linux namespace'lerinin bir sınırı. Docker veya Podman gibi araçların bu tür mapping'i destekleyebilmesi için Linux tarafında destek olması gerekir. 1:1 UID mapping'in gerekli olmasının nedeni şu: container içindeki 1000 numaralı kullanıcı ile 0 numaralı kullanıcı aynı host kullanıcısına map edilirse dosya sahipliği bilgisi bozulur
  • idmapped mount'lara bakmak mantıklı olabilir. Bunlar yalnızca dosya sistemi yeniden eşlemeyi destekliyor, kernel çağrıları tarafını çözmüyor
  • Keşke container içinde sadece "kendisi" olarak çalışmanın bir yolu olsa. Log'larda sahipliğin de aynen görünmesi gibi
  • ignore_chown_errors seçeneğini kullanırsan, root'u kullanıcı kimliğine map ederken ek mapping olmadan bunu daha kolay uygulayabilirsin
• Podman'a geçişi birkaç kez denedim ama birçok noktada başarısız oldum. Birincisi, podman'ın performansı küçük VPS'imde docker'dan çok daha kötüydü (ayrıntıları atlıyorum). İkincisi, geliştirme ekosistemi hâlâ tam olarak yetişebilmiş değil. Birçok araç Docker socket'ine bağımlı; podman ise izin sorunları ya da API uyumluluk farkları nedeniyle iyi çalışmıyor. Podman kusursuz bir drop-in replacement değil
  • Rootless podman kullanırken yavaş ağ performansı slirp4netns kaynaklı olabilir. Daha hızlı yöntem pasta'dır. Docker varsayılan olarak ağ kurulumunu yetkili bir daemon ile yaptığı için, podman'ı root kullanıcı olarak çalıştırıyorsan performans farkı olmaması gerekir
  • podman ve quadlet ile ilgili SELinux yetki hataları sürekli baş ağrısı olmaya devam ediyor. Mümkünse host genelinde yetkili bir pod oluşturup sadece gerekli /dev aygıtlarını mount etmek ve çok sınırlı programları izole ağ üzerinden açığa çıkarmak daha kolay oluyor
  • İlginç biçimde benim kaynak kısıtlı sistemlerimde podman, docker'dan hem performans hem de kaynak kullanımı açısından çok daha iyiydi. Bunun nedeni muhtemelen crun ile runc arasındaki fark. Ayrıca podman'da daemon olmadığı için daha hafif
• Docker ve Podman'ı bırakıp FreeBSD Jails'e geçtim
  • Daha ayrıntılı bilgi ve yönetim araçları için buraya,
    buraya,
    buraya,
    buraya bakabilirsin
  • FreeBSD jail içinde MS SQL Server'ı veya binlerce docker container'ı anında çalıştırabilir misin? FreeBSD seçimi büyük bir bedel istiyor (uyumluluk kısıtları vb.). Jails'in yaygınlaşmamasının nedeni de bu
  • Kurulumu epey fazla görünüyor; FreeBSD'de de containerd benzeri bir şey olup olmadığını merak ediyorum
  • FreeBSD jails, dağıtıma özgü bir özellik
  • Linux host üzerinde VM çalıştırmakla FreeBSD jail arasında ne fark var?