Docker mı Podman mı? Komutlar benzer, güvenlik modeli aynı değil

Mevcut Docker araçlarına ve Compose iş akışına bağlı bir ekip için Docker daha doğrudan seçimdir. Docker’ın mimari açıklamasında istemcinin imajları, konteynerleri, ağları ve birimleri yöneten dockerd servisiyle çalıştığı; Docker Desktop’ın da istemci, daemon ve Compose’u birlikte sunduğu belirtiliyor. Bu düzen, kullandığınız araçlar Docker API’sine bağlanıyorsa geçiş işini azaltır.

Linux sunucuda konteynerleri ayrıcalıksız bir kullanıcıyla çalıştırmak ve merkezi bir Docker daemon’una bağlı olmamak öncelikse Podman güçlü bir seçenektir. Podman’ın resmî tanımı, onu Linux’a özgü, daemon gerektirmeyen bir OCI aracı olarak tanımlıyor; Docker kullanıcılarına tanıdık komutlar sunduğunu ve konteynerlerin root ya da ayrıcalıksız kullanıcı tarafından çalıştırılabildiğini açıklıyor. Benzer komutlar geçişin başlangıcını kolaylaştırır, ancak servis erişimi ve kullanıcı yetkileri açısından aynı düzeni sağlamaz.

Daemon ve rootless çalışma seçimi nasıl değiştiriyor?

Docker’da terminalde kullanılan docker komutu istemcidir; konteyner oluşturma ve yönetme isteklerini dockerd işler. Sunucuda bu nedenle yalnızca komutu kimin çalıştırdığına değil, daemon’a kimin bağlanabildiğine de bakmak gerekir. API erişimi, konteyner başlatmanın yanında ana makineden dizin bağlama gibi işlemlere de kapı açar. Paylaşılan bir sunucuda servis soketinin izinleri, kullanıcı hesaplarından ayrı bir yönetim kararıdır.

Podman’ın Linux üzerindeki yerel kullanımı sürekli çalışan merkezi bir daemon gerektirmez. Konteyneri ayrıcalıksız hesap altında başlatmak isteyen bir ekip için bunun sonucu, yetki sınırının servis soketine erişim vermek yerine ilgili kullanıcı ve onun konteynerleri etrafında kurulabilmesidir. Bu mimari özellik tek başına güvenlik garantisi değildir: bağlanan ana makine dizinleri, konteyner içindeki süreçlerin izinleri ve uygulamaya verilen ek yetkiler yine belirleyicidir.

Docker’da da ayrıcalıksız çalışma mümkündür. Docker’ın rootless modu belgesi, hem daemon’un hem konteynerlerin kullanıcı ad alanında root yetkisi olmadan çalışabildiğini ve bunun kullanıcı ile grup kimliği eşlemesi için ön koşulları bulunduğunu açıklıyor. Dolayısıyla karar, rootless desteğinin varlığına indirgenemez: bir tarafta ayrıcalıksız da olsa yönetilecek bir daemon, diğer tarafta Linux’ta yerel daemon gerektirmeyen bir çalışma düzeni vardır.

macOS ve Windows’ta “daemonsuz” ne anlama geliyor?

Linux’taki yerel Podman modeli macOS veya Windows ana makinesinde aynı biçimde çalışmaz. Podman machine belgesi, bu sistemlerde Linux konteynerleri için sanal makine gerektiğini ve machine komutlarının bu ortamı yönettiğini belirtiyor. Kullanıcının ana işletim sisteminde yazdığı komut, konteynerin çalıştığı Linux ortamına bağlanır.

Bu ayrım geliştirme sırasında somutlaşır. Kaynak kodu dizinini konteynere bağlama, dosya değişikliklerini izleme ve yerel ağ portlarına erişme işlemleri ana makine ile sanal makine arasındaki sınırdan geçer. Linux sunucusunda sorunsuz çalışan bir bağlama yolunun dizüstü bilgisayarda da aynı davranacağını varsaymak bu yüzden doğru değildir. Docker Desktop mevcut iş akışının parçasıysa karşılaştırılması gereken şey yalnızca iki komut satırı değil, ekibin kullandığı bütün yerel geliştirme ortamıdır.

Aynı OCI imajıyla geçişte neyi karşılaştırmalı?

docker run ile podman run arasındaki benzerlik, tek konteynerli bir uygulamada başlangıç maliyetini düşürebilir. Aynı OCI imajı kullanılabiliyorsa uygulamayı sırf motor değişti diye yeniden paketlemek gerekmeyebilir. Yine de imaj, çalışan sistemin tamamı değildir: ortam değişkenleri, port eşlemeleri, bağlı dizinler, kalıcı veri ve ağ düzeni konteyner başlatılırken ayrıca tanımlanır.

Geçişi değerlendiren ekip, kullandığı imajı iki motorda aynı çalışma seçenekleriyle başlatıp uygulamanın sonucunu karşılaştırmalıdır. Özellikle bağlanan dizindeki dosyaların sahibi ve erişim izinleri önemlidir; rootless kullanımda konteyner içindeki kullanıcı kimliği ile ana makinedeki kimlik arasındaki eşleme görünür hâle gelir. Sürecin konteyner içinde başlaması, uygulamanın veriyi okuyabildiği veya yazabildiği anlamına gelmez.

Birden fazla hizmeti Compose ile yöneten ekiplerde sınır daha geniştir. Compose dosyası imajların yanında hizmetler arası ağları, birimleri ve başlatma ayarlarını tarif eder; CI görevi ya da geliştirme eklentisi de Docker API’sine dayanabilir. Böyle bir düzende yalnızca docker komutunu podman adıyla değiştirmek yeterli bir uyumluluk ölçüsü değildir. Karşılaştırmanın konusu, aynı imajdan başlayan tüm geliştirme ve dağıtım iş akışının beklenen sonucu üretmesidir.

Yayımlanmış disk ölçümü karar için ne söylüyor?

2024 tarihli SysBench araştırmasında, aynı Ubuntu iş istasyonunda tekrarlanan disk okuma testinde Docker için 6,92 MiB/s, Podman için 11,84 MiB/s raporlandı. Bunlar belirli bir donanım, işletim sistemi, test aracı ve konteyner yapılandırmasının sonuçlarıdır; genel kullanımda motorların sabit disk hızları olarak okunmamalıdır.

Sentetik okuma testi, gerçek uygulamanın dosya erişimini tek başına temsil etmez. Bir uygulamanın küçük dosyaları sık açması, veriyi bağlı bir dizinde tutması veya macOS ve Windows’ta sanal makine üzerinden çalışması farklı darboğazlar yaratabilir. Disk erişimi seçimde belirleyiciyse yayımlanmış sonuç, hangi ölçümün yapılacağını gösterir; karar için aynı imajın, gerçek veri ve depolama düzeniyle iki ortamda ölçülmesi gerekir.

Geliştirici ve sunucu ekipleri için karar matrisi

• Docker araç zinciri yerleşikse: Compose, CI ve Docker API’sine bağlanan araçları korumak geçiş maliyetini azaltır. Podman’a geçiş gerekçesi varsa komut uyumundan önce bu bağımlılıkların davranışı değerlendirilmelidir.
• Linux sunucuda yetki düzeni öncelikse: Podman’ın yerel ve merkezi daemon gerektirmeyen modeli uygun olabilir. Docker’ın rootless seçeneği de karşılaştırmaya alınmalı; fark, ekibin hangi servis ve erişim düzenini yöneteceğidir.
• Geliştirme makinesi macOS veya Windows ise: Podman machine gereksinimi kurulumun parçasıdır. Dosya bağlama ve ağ davranışı, Linux sunucusundaki yerel Podman kullanımından ayrı değerlendirilmelidir.
• Disk erişimi kritikse: Yayımlanmış sentetik sonuç bir ipucudur. Motor seçimi, uygulamanın kendi imajı ve depolama koşulları altında elde edilen ölçüme dayanmalıdır.

Ayrıca okuyun:

• KOSGEB desteği hibe değil: 1,5 milyon TL için geri ödeme hesabı
• Consensus mu Elicit mi? Hızlı yanıt ile sistematik tarama aynı iş değil
• 8,7 milyon yolcunun verisi yayımlandı: Ödeme bilgileri listede değil