Podman ile Docker'a Alternatif Konteyner Yönetimi

Konteyner teknolojisi denince akla ilk gelen isim yıllardır Docker oldu. Ancak son birkaç yılda özellikle üretim sunucularında ve güvenlik odaklı ekiplerde Podman'ın adı giderek daha sık duyuluyor. Bunun tesadüf olmadığını, gerçek bir müşteriyle karşılıklı otururken anlattığım gibi anlatayım: Podman, Docker'ın çözemediği iki temel mimari sorunu tasarımın en başından ele alıyor. Birincisi arka planda 7/24 root yetkisiyle çalışan tek bir merkezi servise (daemon) olan bağımlılık, ikincisi ise konteynerleri çalıştırmak için root olma zorunluluğu. Podman her ikisini de ortadan kaldırıyor.

Bu rehberde Podman'ın daemonsuz ve rootless mimarisinin ne anlama geldiğini, günlük hayatta Docker komutlarınızı neredeyse hiç değiştirmeden nasıl kullanabileceğinizi, Kubernetes'in temel yapı taşı olan pod kavramını, konteynerlerinizi systemd servisine dönüştürerek sunucu açılışında otomatik başlatmayı ve Docker'dan geçerken karşılaşacağınız uyumsuzluk noktalarını tek tek ele alacağız. Amacım bu yazıyı bitirdiğinizde kendi VDS veya sanal sunucunuzda Podman'ı güvenle kurup çalıştırabilecek düzeye gelmeniz. Konteyner kavramlarına henüz aşina değilseniz önce Docker nedir başlangıç rehberimizi okumanız oturmayı kolaylaştıracaktır.

Podman Nedir ve Docker'dan Farkı#

Podman (Pod Manager), Red Hat tarafından geliştirilen, OCI (Open Container Initiative) standardıyla tam uyumlu bir konteyner ve pod yönetim aracıdır. Aynı imajları çalıştırır, aynı Docker Hub kayıt defterlerinden imaj çeker, aynı Dockerfile'ları derler. Kullanıcı açısından bakıldığında Docker'la neredeyse ikiz gibidir. Farkı motorun kapağının altındadır.

Docker'da tüm işi dockerd adlı bir arka plan servisi yapar. Siz docker run yazdığınızda komut satırı istemcisi aslında bu servise bir istek gönderir, işi asıl yapan odur. Bu servis root yetkisiyle çalışır ve tüm konteynerlerin atası odur. Servis çökerse çalışan tüm konteynerler tehlikeye girer, servis ele geçirilirse saldırgan doğrudan root olur.

Podman'da böyle bir merkezi servis yoktur. Her konteyner, onu başlatan kullanıcının doğrudan bir alt süreci (child process) olarak çalışır. podman run dediğinizde arada aracı bir daemon olmadan konteyner doğrudan sizin süreç ağacınızın altında başlar. Bu fork-exec modeli, Podman'ın en temel felsefesidir ve tüm avantajları buradan doğar.

Pratikte en önemli sonuç şu: Podman kurmak için sisteminizde sürekli çalışan yeni bir servis eklemezsiniz. Konteyner çalışmıyorsa Podman'a ait hiçbir süreç RAM tüketmez.

Rootless ve Daemonsuz Mimarinin Anlamı#

Rootless kelimesi kulağa teknik bir ayrıntı gibi gelse de güvenlik açısından oyunun kurallarını değiştiriyor. Geleneksel Docker kurulumunda docker grubuna eklenen bir kullanıcı, pratikte root yetkisine denk bir güce sahip olur. Çünkü herhangi bir imajı -v /:/host gibi bir bağlama ile başlatıp ana sistemin kök dizinine yazma izni elde edebilir. Bu, paylaşımlı ortamlarda ciddi bir risktir.

Podman rootless modda, Linux çekirdeğinin user namespace özelliğini kullanır. Sizin normal kullanıcınız konteynerin içinde root gibi görünür (UID 0), ancak ana sistemde bu aslında sizin sıradan kullanıcı kimliğinize eşlenir. Yani konteynerin içindeki root, dışarıda hiçbir ayrıcalığa sahip değildir. Bir saldırgan konteynerden kaçmayı başarsa bile eline geçen tek şey, o konteyneri başlatan yetkisiz kullanıcının hakları olur.

Bu eşleme /etc/subuid ve /etc/subgid dosyalarındaki alt kimlik aralıklarıyla yapılır. Kurulumdan sonra kullanıcınıza bir aralık tanımlanmış olmalıdır:

# Kullanıcıya ayrılan alt UID/GID aralığını kontrol edin
cat /etc/subuid
# ornek cikti: mehmet:100000:65536

cat /etc/subgid
# ornek cikti: mehmet:100000:65536

# Aralık atanmadıysa manuel ekleyin
sudo usermod --add-subuids 100000-165535 --add-subgids 100000-165535 mehmet

Daemonsuz olmanın ikinci büyük faydası dayanıklılıktır. Docker'da dockerd süreci yeniden başlatıldığında ya da güncellendiğinde işler karışabilir. Podman'da her konteyner bağımsız bir süreç olduğu için tek bir merkezi noktanın çökmesi tüm sistemi etkilemez. Güvenlik yaklaşımının bütününü kavramak için sunucu güvenliği temelleri rehberimize göz atmanızı öneririm; rootless konteyner bu bütünün önemli bir parçasıdır.

Kurulum ve İlk Konteyner#

Podman çoğu güncel dağıtımın resmi depolarında yer alır, ek bir üçüncü parti depo eklemenize genellikle gerek kalmaz. Aşağıda yaygın dağıtımlar için kurulum komutlarını görüyorsunuz:

# Ubuntu / Debian
sudo apt update
sudo apt install -y podman

# RHEL / Rocky / AlmaLinux / Fedora
sudo dnf install -y podman

# Kurulumu dogrulayin
podman --version
podman info --format '{{.Host.Security.Rootless}}'

Son komut true döndürüyorsa rootless mod aktif demektir. Şimdi ilk konteynerimizi normal kullanıcı olarak, yani sudo kullanmadan çalıştıralım:

# Basit bir test
podman run --rm docker.io/library/hello-world

# Arka planda bir Nginx web sunucusu baslat
podman run -d --name web -p 8080:80 docker.io/library/nginx:alpine

# Calisan konteynerleri listele
podman ps

# Loglari izle
podman logs -f web

Dikkat ederseniz komutlar Docker ile birebir aynı. Tek fark, imaj adını tam yoluyla (docker.io/library/...) yazmamdır. Podman, hangi kayıt defterine bağlanacağını varsayım yapmaz; bu bilinçli bir güvenlik tercihidir çünkü yanlış bir kayıt defterinden sahte imaj çekmeyi engeller. İsterseniz /etc/containers/registries.conf dosyasına varsayılan kayıt defterlerini ekleyerek kısa isim kullanabilirsiniz:

# /etc/containers/registries.conf
unqualified-search-registries = ["docker.io"]

[[registry]]
location = "docker.io"

Bu ayardan sonra podman run -d nginx:alpine gibi kısa yazımlar da çalışır. Rootless modda 1024 altındaki portları doğrudan dinleyemezsiniz; bu yüzden yukarıdaki örnekte 80 yerine 8080 kullandım. Bunu aşmanın yolları var, birazdan değineceğim.

Docker Komut Uyumluluğu ve alias#

Podman'a geçişin en sevindirici tarafı, mevcut kas hafızanızı ve betiklerinizi çöpe atmak zorunda olmamanızdır. Podman komut satırı arayüzü, Docker CLI ile neredeyse birebir uyumlu olacak şekilde tasarlanmıştır. docker run, docker build, docker ps, docker exec, docker images, docker rmi gibi komutların tamamının Podman karşılığı aynı isim ve aynı parametrelerle çalışır.

En yaygın geçiş yöntemi basit bir takma ad (alias) tanımlamaktır. Böylece parmaklarınız docker yazmaya devam eder ama arkada Podman çalışır:

# ~/.bashrc veya ~/.zshrc dosyaniza ekleyin
alias docker=podman

# Degisikligi aktif edin
source ~/.bashrc

# Artik bu komut aslinda Podman'i cagirir
docker ps

Bazı ekipler alias yerine podman-docker paketini tercih eder. Bu paket sisteme gerçek bir /usr/bin/docker sembolik bağlantısı kurar; böylece alias tanımlamadığınız betikler, cron görevleri ve üçüncü parti araçlar bile Podman'ı Docker sanarak kullanır:

# Debian/Ubuntu
sudo apt install -y podman-docker

# RHEL ailesi
sudo dnf install -y podman-docker

docker-compose alışkanlığınız varsa Podman burada da yalnız bırakmıyor. Podman'ın kendi yerleşik komutu podman compose bulunuyor ve arka planda docker-compose ya da podman-compose aracını kullanabiliyor. Mevcut docker-compose.yml dosyalarınızın büyük çoğunluğu değişiklik gerektirmeden çalışır:

# Mevcut compose dosyanizi Podman ile calistirin
podman compose up -d

# Servisleri durdurun
podman compose down

Uygulama kapsayıcılarınızı bir sunucuda barındıracaksanız sunucu yönetimi hizmetimiz ile bu geçişi sizin adınıza planlayıp güvenli biçimde hayata geçirebiliriz.

Pod Kavramı ve Kubernetes'e Yakınlık#

Podman'ın adındaki "pod" tesadüf değil. Kubernetes'te bir pod, birbirine sıkı bağlı, aynı ağ ad alanını (network namespace) paylaşan bir veya birden fazla konteyner grubudur. Aynı pod içindeki konteynerler localhost üzerinden birbirleriyle konuşur, aynı IP adresini paylaşırlar. Docker'da bu kavram yoktur; oradaki en yakın karşılık kullanıcı tanımlı ağlardır ama aynı şey değildir.

Podman, pod'u birinci sınıf bir kavram olarak sunar. Örneğin bir WordPress uygulamasını, uygulama konteyneri ile veritabanı konteynerini aynı pod içinde çalıştırarak birbirlerine localhost üzerinden erişecek şekilde kurabilirsiniz:

# Once pod'u olusturun, dis dunyaya sadece 8080 portunu acin
podman pod create --name blog -p 8080:80

# MariaDB'yi bu pod'un icine yerlestirin
podman run -d --pod blog --name blog-db \
  -e MYSQL_ROOT_PASSWORD=gizli \
  -e MYSQL_DATABASE=wordpress \
  docker.io/library/mariadb:11

# WordPress'i ayni pod'a ekleyin; veritabanina localhost'tan erisir
podman run -d --pod blog --name blog-app \
  -e WORDPRESS_DB_HOST=127.0.0.1 \
  -e WORDPRESS_DB_NAME=wordpress \
  -e WORDPRESS_DB_USER=root \
  -e WORDPRESS_DB_PASSWORD=gizli \
  docker.io/library/wordpress:latest

# Pod'un durumunu gorun
podman pod ps
podman ps --pod

Burada dikkat edilecek nokta, veritabanı konteynerinin dışarıya hiçbir port açmamasıdır. Sadece uygulama konteynerinin ihtiyaç duyduğu 80 portu, pod seviyesinde 8080 olarak dış dünyaya açıldı. Veritabanı yalnızca pod içinden erişilebilir. Bu, saldırı yüzeyini daralttığı için başlı başına bir güvenlik kazanımıdır.

Pod'un asıl gücü, olduğu gibi Kubernetes'e taşınabilmesidir. Podman, çalışan bir pod'dan doğrudan Kubernetes YAML dosyası üretebilir:

# Pod'u Kubernetes manifestine cevirin
podman kube generate blog > blog.yaml

# Ureyen YAML'i baska bir Podman ana makinesinde geri oynatabilirsiniz
podman kube play blog.yaml

Bu özellik, yerelde Podman ile geliştirip aynı tanımı üretimde Kubernetes'e taşımak isteyen ekipler için köprü görevi görür. WordPress tabanlı bir projeyi bu yapıyla kurmayı düşünüyorsanız hazır ve yönetimi bize ait olan WordPress hosting paketlerimize da göz atabilirsiniz.

systemd ile Konteynerleri Servise Dönüştürmek#

Konteyner çalıştırdınız, güzel. Peki sunucu yeniden başladığında ne olacak? Docker'da bu işi dockerd servisi hallederdi. Podman daemonsuz olduğu için bu görevi Linux'un kendi servis yöneticisine, yani systemd'ye devreder. Bu aslında bir dezavantaj değil, tersine daha temiz bir yaklaşımdır çünkü konteynerleriniz sistemdeki diğer tüm servisler gibi standart araçlarla yönetilir.

Podman, çalışan bir konteyner için hazır bir systemd birim dosyası üretebilir. Rootless konteynerlerde bunu kullanıcı seviyesinde (user unit) yaparsınız:

# Kullanici systemd dizinini olusturun
mkdir -p ~/.config/systemd/user

# Calisan 'web' konteyneri icin birim dosyasi uretin
podman generate systemd --name web --files --new

# Ureyen dosyayi dogru yere tasiyin
mv container-web.service ~/.config/systemd/user/

# Servisi tanitin ve etkinlestirin
systemctl --user daemon-reload
systemctl --user enable --now container-web.service

# Durumu kontrol edin
systemctl --user status container-web.service

Burada kritik bir ayrıntı var. Rootless servislerin, siz oturumu kapattığınızda bile çalışmaya devam etmesi için "lingering" özelliğini açmanız gerekir. Aksi halde SSH oturumunuzu kapattığınızda servis durur:

# Kullanici oturumdan cikinca da servislerin surmesini saglayin
sudo loginctl enable-linger mehmet

Yeni Podman sürümlerinde generate systemd yerine Quadlet adı verilen daha modern bir yöntem öne çıkıyor. Quadlet ile konteynerinizi doğrudan bir .container tanım dosyasıyla tarif edersiniz ve systemd bunu otomatik olarak bir servise çevirir:

# ~/.config/containers/systemd/web.container
[Unit]
Description=Nginx web konteyneri

[Container]
Image=docker.io/library/nginx:alpine
PublishPort=8080:80

[Service]
Restart=always

[Install]
WantedBy=default.target

Dosyayı yerleştirdikten sonra systemctl --user daemon-reload ve systemctl --user start web komutlarıyla servisiniz hazır olur. Bu yöntem daha okunabilir olduğu için üretim ortamlarında giderek daha çok tercih ediliyor. Kritik servislerinizin sürekliliğini garanti altına almak için düzenli yedekleme çözümlerimizi de bu yapıyla birlikte kurgulamanızı tavsiye ederim.

Güvenlik Avantajları ve Ağ Yönetimi#

Podman'ı öne çıkaran şey, güvenliğin sonradan eklenen bir özellik değil, mimarinin temeli olmasıdır. Rootless mod sayesinde en kötü senaryoda bile bir konteyner ihlali root erişimine dönüşmez. Buna ek olarak Podman, SELinux ile yerel entegrasyon sunar; RHEL ailesi dağıtımlarda konteyner süreçleri ve bağlanan dizinler otomatik olarak SELinux etiketleriyle izole edilir.

Rootless modda ağ trafiği, çekirdek yerine kullanıcı alanında çalışan slirp4netns ya da daha yeni ve performanslı pasta aracıyla yönetilir. Bu, ağ yığınının bile ayrıcalıksız kullanıcı hakkıyla çalıştığı anlamına gelir. Kendi köprü ağınızı oluşturup konteynerleri isimle birbirine bağlayabilirsiniz:

# Ozel bir ag olusturun
podman network create uygulama-agi

# Konteynerleri bu aga baglayin; birbirlerini isimle bulurlar
podman run -d --network uygulama-agi --name db mariadb:11
podman run -d --network uygulama-agi --name app -p 8080:3000 benim-uygulamam

Daha önce değindiğim 1024 altı port sorununu üretimde çözmek için iki temiz yol var. Birincisi çekirdeğe ayrıcalıksız kullanıcıların düşük port bağlamasına izin vermektir:

# 80 ve uzeri portlara ayricaliksiz erisime izin ver
sudo sysctl net.ipv4.ip_unprivileged_port_start=80

# Kalici hale getirin
echo "net.ipv4.ip_unprivileged_port_start=80" | sudo tee /etc/sysctl.d/99-podman.conf

İkinci ve daha yaygın tercih ise konteyneri yüksek bir portta (örneğin 8080) çalıştırıp önüne bir ters vekil (reverse proxy) koymaktır. Böylece 80 ve 443 portlarını ayrı bir katman dinler, TLS sonlandırmayı da orada yaparsınız:

# /etc/nginx/conf.d/uygulama.conf
server {
    listen 80;
    server_name uygulama.example.com;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Bu mimaride uygulamanızı ücretsiz SSL sertifikası ile şifreleyip önüne bir web uygulama güvenlik duvarı ekleyerek katmanlı bir savunma kurabilirsiniz. Yüksek trafik alan ya da saldırıya açık projelerde DDoS koruma hizmetimizi de bu yapının önüne yerleştirmenizi öneririm.

Docker'dan Podman'a Geçişte Uyumsuzluk Noktaları#

Her ne kadar Podman büyük ölçüde Docker uyumlu olsa da, geçiş sırasında bilmeniz gereken birkaç farklılık var. Bunları önceden bilmek, "neden çalışmıyor" diye saatler kaybetmenizi önler. Aşağıdaki tablo en sık karşılaşılan farkları özetliyor:

En sık takılınan konu Docker soketidir. Bazı araçlar (örneğin bir CI aracı ya da izleme çözümü) /var/run/docker.sock üzerinden Docker ile konuşmayı bekler. Podman daemonsuz olduğu için varsayılan olarak böyle bir soket yoktur. İhtiyaç halinde Podman'ın uyumluluk API'sini bir kullanıcı servisi olarak açabilirsiniz:

# Podman'in Docker uyumlu soketini etkinlestirin
systemctl --user enable --now podman.socket

# Soketin yolunu ogrenin
echo $XDG_RUNTIME_DIR/podman/podman.sock

# Docker soketi bekleyen araclar icin ortam degiskeni tanimlayin
export DOCKER_HOST=unix://$XDG_RUNTIME_DIR/podman/podman.sock

İkinci sık sorun, imaj ve veri depolamanın kullanıcıya özel olmasıdır. Rootless Podman'da imajlar ~/.local/share/containers altında saklanır. sudo podman ile çektiğiniz bir imaj, sıradan kullanıcının podman komutuyla görünmez çünkü bunlar tamamen farklı depolardır. Bu yüzden her zaman tutarlı olun: ya hep root ile ya hep kullanıcı ile çalışın, ikisini karıştırmayın.

Bir diğer nokta veri kalıcılığıdır. Rootless modda bir dizini bağlarken (-v) SELinux etkin sistemlerde :Z ya da :z etiketini eklemeyi unutmayın; aksi halde izin hatası alırsınız:

# Kalici veri icin dogru baglama (SELinux uyumlu)
podman run -d --name veritabani \
  -v ./veri:/var/lib/mysql:Z \
  -e MYSQL_ROOT_PASSWORD=gizli \
  docker.io/library/mariadb:11

Bu farklar korkutucu görünse de aslında birkaç saatlik alışma süreciyle kolayca aşılıyor. Mevcut Docker tabanlı bir sistemi Podman'a taşımayı planlıyorsanız site taşıma hizmetimiz kapsamında bu geçişi kesintisiz biçimde planlayabiliriz. Uygun altyapı için de VDS sunucularımızı veya sanal sunucularımızı değerlendirebilirsiniz.

Sıkça Sorulan Sorular#

Podman, Docker'ın yerini tamamen alabilir mi?#

Çoğu senaryoda evet. Podman, OCI standardına tam uyduğu için aynı imajları çalıştırır, aynı Dockerfile'ları derler ve komut satırı arayüzü Docker ile neredeyse birebir aynıdır. Tek konteyner ya da compose tabanlı uygulamaların büyük çoğunluğu değişiklik gerektirmeden çalışır. İstisna, Docker soketine doğrudan bağımlı olan bazı özel araçlardır; onlar için de Podman'ın uyumluluk soketini etkinleştirmek genellikle yeterli olur.

Rootless mod performansı düşürür mü?#

Günlük kullanımda hissedilir bir fark yaşamazsınız. Rootless modun tek gözle görülür maliyeti ağ katmanındadır, çünkü trafik çekirdek yerine kullanıcı alanında yönetilir. Ancak yeni nesil pasta aracı bu farkı büyük ölçüde kapattı. Yoğun ağ trafiği olan uygulamalarda dilerseniz konteyneri host ağı moduyla çalıştırarak ya da önüne bir ters vekil koyarak performansı Docker seviyesine getirebilirsiniz.

Mevcut docker-compose dosyalarımı kullanmaya devam edebilir miyim?#

Evet. Podman'ın yerleşik podman compose komutu mevcut docker-compose.yml dosyalarınızı okur ve çalıştırır. Arka planda docker-compose ya da podman-compose aracını kullanır. Dosyalarınızın büyük kısmı hiç değişmeden çalışır; yalnızca düşük port bağlama ve SELinux etiketi gibi rootless moda özgü birkaç ayrıntıya dikkat etmeniz yeterlidir.

Konteynerlerim sunucu yeniden başlayınca otomatik açılır mı?#

Kendiliğinden açılmaz, çünkü Podman'da her şeyi ayakta tutan bir daemon yoktur. Bunun yerine konteynerinizi systemd servisine dönüştürürsünüz. podman generate systemd komutu ya da daha modern Quadlet tanım dosyaları bu işi yapar. Rootless servislerde ek olarak loginctl enable-linger komutuyla oturum kapansa bile servisin sürmesini sağlamayı unutmayın.

Podman ile Kubernetes arasında nasıl bir ilişki var?#

Podman, Kubernetes'in temel yapı taşı olan pod kavramını yerel olarak destekler. Yerelde bir pod oluşturup içine konteynerlerinizi yerleştirebilir, ardından podman kube generate ile bu yapıyı doğrudan Kubernetes YAML dosyasına dönüştürebilirsiniz. Bu sayede aynı tanımı hem geliştirme makinenizde Podman ile hem de üretimde Kubernetes ile kullanarak temiz bir geçiş köprüsü kurmuş olursunuz.

Podman'ı paylaşımlı hosting üzerinde çalıştırabilir miyim?#

Genellikle hayır. Paylaşımlı hosting ortamlarında user namespace, subuid/subgid aralıkları ve sysctl ayarları gibi Podman'ın ihtiyaç duyduğu çekirdek yeteneklerine erişemezsiniz. Konteyner çalıştırmak için kök yetkilerine sahip olduğunuz bir VDS ya da sanal sunucuya ihtiyacınız var. Bu tür bir altyapı için sunucu paketlerimiz doğru başlangıç noktasıdır.

Kapanış#

Podman, Docker'ın yıllardır taşıdığı iki temel mimari yükü, yani merkezi daemon bağımlılığını ve root zorunluluğunu ortadan kaldırarak konteyner dünyasına daha güvenli ve daha temiz bir alternatif sunuyor. Komut uyumluluğu sayesinde geçiş neredeyse ağrısız, rootless mimarisi sayesinde güvenlik varsayılan olarak açık, systemd ve pod entegrasyonu sayesinde de üretim ortamına yakın. Docker'dan gelen bilginizin büyük kısmı olduğu gibi geçerliliğini koruyor; yalnızca birkaç uyumsuzluk noktasını öğrenmeniz yeterli.

Bu mimariyi kendi ortamınızda hayata geçirmek için tam yetkiye sahip olduğunuz bir sunucuya ihtiyacınız var. Clou.TR olarak yüksek performanslı VDS ve sanal sunucu çözümlerimiz, kurulumdan güncellemeye kadar yanınızda olan sunucu yönetimi hizmetimiz ve katmanlı güvenlik için SSL, WAF ve DDoS koruma paketlerimizle konteyner altyapınızı baştan sona kurmanıza destek oluyoruz. Doğru altyapıyla Podman'ın sunduğu güvenlik ve esnekliğin tadını çıkarın; gerisini birlikte hallederiz.