Podman ve Docker Arasındaki Temel Farklar

Podman ve Docker arasındaki temel farklar

Podman ve Docker, bir VPS üzerinde aynı OCI (Open Container Initiative) imajlarını çalıştırır; dolayısıyla seçim, hangi yazılımı çalıştırabileceğinizle ilgili değildir. Fark, süreç modelindedir. Docker, her container'ın sahibi olan root yetkili bir daemon çalıştırır ve docker komutu, bu daemon'dan işi yapmasını isteyen küçük bir istemcidir. Podman'in daemon'ı yoktur: podman run, container'ı onu çağıran sürecin bir alt süreci olarak, kendi yetkisiz kullanıcınız altında başlatır.

Diğer tüm farklar bu tek olgudan kaynaklanır. Otomatik başlatma işlemi, daemon yerine systemd'nin görevi haline gelir. Volume sahipliği bir kullanıcı isim alanı (user namespace) üzerinden aktarılır; bu nedenle ana makinede ls -l ile gördüğünüz sahip, container'ın gördüğü sahip değildir. 1024'ün altındaki portlar, bir kernel ayarını değiştirene kadar bağlanmayı reddeder. docker CLI (komut satırı arayüzü), bir sarmalayıcı aracılığıyla çalışmaya devam eder; ancak Docker socket'ine ihtiyaç duyan bir durumla karşılaşılana kadar.

Daemon yok: bir container başlattığınızda gerçekte ne çalışır

Bir Docker sunucusunda pstree -a komutu, dockerd sürecini root olarak, containerd sürecini onun yanında ve her çalışan container için bir adet containerd-shim-runc-v2 sürecini gösterir. Uygulamanız bu shim sürecinin bir alt sürecidir ve shim süreci de PID 1'in alt sürecidir. Container ile onu başlatan kabuk arasında hiçbir bağlantı yoktur. Daemon'ı durdurduğunuzda sunucudaki tüm container'lar için kontrol düzlemini kaybedersiniz ve varsayılan live-restore ayarı kapalıysa, systemctl restart docker komutu container'larınızı da yeniden başlatır.

Podman'in buna eşdeğer bir süreci yoktur. Bir container başlattığınızda, container'ın ana sürecini tutan ve komutu çalıştıran kullanıcıya ait bir adet conmon (container izleyicisi) süreci elde edersiniz.

podman run -d --name web -p 8080:80 docker.io/library/caddy:2
ps -o user,pid,ppid,args -C conmon
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080

ps komutu, conmon sürecini root olarak değil, oturum açan kullanıcınız olarak listelemelidir ve curl komutu 200 çıktısını vermelidir. Merkezi bir servis container'ın sahibi olmadığından, sudo apt upgrade podman komutu halihazırda çalışan hiçbir şeyi durdurmaz ve bir container'ın izleyicisinin çökmesi diğerlerini etkilemez.

Daemon'ın eksikliği size bir maliyet de getirir. Yeniden başlatma sonrasında container'larınızı hiçbir şey otomatik olarak başlatmaz. Docker'ın --restart=always özelliği, daemon'ın açılışta tuttuğu bir sözdür; Podman ise bunun yerine aşağıda yer alan quadlet bölümünün konusu olan systemd'yi kullanır.

Soket, hikayenin diğer yarısıdır. /var/run/docker.sock, root sahipliğinde bir API (uygulama programlama arayüzü) uç noktasıdır ve buraya yazma yetkisi olan her süreç, ana makine dosya sistemini mount eden ayrıcalıklı bir container başlatabilir. Bir kullanıcıyı docker grubuna eklemek, o kullanıcıya daha dolaylı bir yoldan root yetkisi verir; bu konu her servis hesabına yalnızca ihtiyaç duyduğu erişimi vermek başlığı altında ayrıca okunmalıdır. Podman, siz talep etmediğiniz sürece hiçbir soket açmaz ve elde ettiğiniz soket /run/user/<uid>/podman/podman.sock konumunda tek bir kullanıcıya aittir.

Ubuntu 24.04 üzerinde Podman kurulumu ve rootless modunun doğrulanması

sudo apt update
sudo apt install -y podman uidmap
podman --version
podman info | grep -i rootless

uidmap paketi, newuidmap ve newgidmap araçlarını sağlar. Bunlar, sıradan bir kullanıcının alt kullanıcı kimliği (subordinate ID) aralığı talep etmesine olanak tanıyan setuid yardımcılarıdır; bunlar olmadan rootless container'lar başlatılamaz. podman info komutu rootless: true çıktısını vermelidir.

Ağustos 2026 itibarıyla Ubuntu 24.04, Podman 4.9; Debian 13 ise Podman 5.x sürümü ile gelmektedir. Quadlet dosyaları 4.4 veya daha yeni bir sürüm gerektirdiğinden ve .pod quadlet dosyaları 5.0 sürümüne ihtiyaç duyduğundan bu fark önemlidir. Upstream dokümantasyonundan bir örnek kopyalamadan önce podman --version komutunu çalıştırın.

Her rootless kullanıcının bir alt kullanıcı kimliği aralığına ihtiyacı vardır:

grep "$USER" /etc/subuid /etc/subgid

Ubuntu üzerinde adduser ile oluşturulan bir kullanıcı, bu aralığı otomatik olarak alır. useradd -M ile veya bir yapılandırma aracıyla oluşturulan kullanıcılar genellikle bu aralığa sahip olmaz ve hata mesajı bunu belirtir:

Error: cannot find UID/GID for user deploy: no subuid ranges found for user "deploy" in /etc/subuid - check rootless mode in man pages.

Bir aralık atayın, ardından yeni eşlemenin kullanılması için kullanıcının depolama alanını sıfırlayın:

sudo usermod --add-subuids 100000-165535 --add-subgids 100000-165535 deploy
podman system migrate

İlk çalıştırmada karşılaşılan bir diğer sürpriz: Podman, Docker Hub'ı varsayılan olarak kabul etmez. Kısa bir imaj adı, /etc/containers/registries.conf içindeki unqualified-search-registries üzerinden çözümlenir ve terminale bağlı olmayan bir betik içerisinde çekme işlemi short-name resolution enforced but cannot prompt without a TTY hatasıyla başarısız olur. Her zaman tam adı yazın. nginx yerine docker.io/library/nginx:1.27 kullanın.

Kiralık bir sunucuda rootless container kullanmanın gerçek kazanımları

Rootless container, bir sürecin kendi özel kullanıcı kimliği (UID) haritasına sahip olmasını sağlayan bir çekirdek özelliği olan kullanıcı ad alanı (user namespace) içinde çalışır. Ad alanı içinde container'ın süper kullanıcısı UID 0'dır. Dışarıda, yani VPS'inizde ise aynı süreç, normal oturum açtığınız kullanıcıdır. Container içindeki root, ana makinede root değildir.

Elde edilen kazanımın gerçek boyutu budur. Root olarak çalışmakta ısrar eden bir imaj, uzaktan kod yürütme açığına sahip bir web uygulaması veya dışarıda UID 0 olmayı gerektiren bir kaçış senaryosu; bunların tümü, makinenin yetkileri yerine sizin yetkisiz kullanıcı izinlerinizle sınırlı kalır. Rootless yapısının korumadığı durumlar ise çekirdek hatalarıdır; ayrıca kendi dosyalarınızı da korumaz, çünkü kaçan süreç sizin adınıza çalışır ve sizin okuyabildiğiniz her şeyi okuyabilir. İzole edilen birimin niteliği, en az UID eşlemesi kadar önemlidir; bu durum, bir kayıt defterinden çekilen katmanlı bir imaj yerine, küçük bir makine gibi yönettiğiniz tüm bir kullanıcı alanını kapsayan bir FreeBSD jail örneğinde daha net görülebilir.

Docker da rootless çalışabilir. dockerd-rootless-setuptool.sh install her kullanıcı için ayrı bir daemon kurar ve bu yapı oldukça iyi çalışır. Aradaki fark, varsayılanın neyi hedeflediğidir. Podman ile rootless yapılandırması sormadan gelir; bu sayede ilk karşılaştığınız hata, iki yıl boyunca sessizce root olarak çalışan bir servis yerine, 80 numaralı portu bağlayamayan bir container olur.

Hacim dosyalarımın sahibi neden UID 100999?

Bunun nedeni aynı kullanıcı ad alanıdır (user namespace). Container içindeki UID 0, ana makinenizdeki (host) UID ile eşleşir. Container içindeki UID 1, subuid aralığınızdaki ilk ID ile eşleşir ve oradan itibaren saymaya devam eder. 100000 ile başlayan bir aralıkta, container içindeki UID 1000, ana makinede 100999 olarak görünür.

mkdir -p "$PWD/data"
podman run --rm --user 1000 -v "$PWD/data:/data" docker.io/library/alpine:3 sh -c 'id -u; touch /data/f'
ls -ln "$PWD/data"

Container 1000 çıktısını verir. Ana makinedeki liste ise 100999 sahibini gösterir, çünkü 100000 artı 1000 eksi 1, 100999 eder. Hiçbir şey bozuk değildir ve basit bir chown komutu bunu düzeltmeyecektir, çünkü yetkisiz kullanıcınız ad alanı dışında dosya sahipliğini değiştiremez.

Dört çözüm yolu mevcuttur:

• podman unshare chown 1000:1000 "$PWD/data", chown işlemini aynı kullanıcı ad alanı içinde çalıştırır; burada numaralar container için ne anlama geliyorsa o şekilde işlenir.
• -v "$PWD/data:/data:U", Podman'den kaynak dizinin sahipliğini sizin yerinize düzeltmesini ister. Bunu mevcut verilerinizde değil, yeni bir dizinde kullanın.
• --userns=keep-id, ana makine UID'nizi container içindeki aynı UID ile eşler, böylece yeni dosyalar sizin sahipliğinizde oluşturulur.
• -v appdata:/data gibi adlandırılmış bir hacim (named volume) kullanmak bu sorunu tamamen ortadan kaldırır, çünkü Podman bunu kendi depolama alanı içinde zaten doğru sahiplikle oluşturur.

Eğer bu sorunla Docker'da da karşılaştıysanız, bu bir katman üstteki aynı sorundur. Birçok imajın sunduğu PUID ve PGID değişkenleri, container içindeki sürecin kullanacağı UID'yi belirler ve rootless Podman altında bu UID ikinci kez eşlenir. Rootless bir container içinde PUID=1000 kullanmak, ana makinedeki dosyaların yine 100999 sahipliğiyle yazılmasına neden olur. Numaraları bu ikinci eşlemeyi göz önünde bulundurarak seçin veya verileri adlandırılmış bir hacme taşıyarak bu konuyla uğraşmayı bırakın.

Mount işlemleri hakkında iki not daha: Fedora ve RHEL örneklerinde gördüğünüz :z ve :Z bayrakları SELinux yeniden etiketleme seçenekleridir; Ubuntu ise AppArmor kullandığı için bu bayraklar orada bir işlev görmez. Ayrıca rootless Podman, kullanıcınızın okuyamadığı bir ana makine dizinini mount edemez; bu bir hata değil, sistemin temel güvenlik özelliğidir.

Rootless Podman neden 80 numaralı portu yayınlamayı reddediyor?

Çünkü 1024'ün altındaki bir portu bağlamak, kullanıcı hesabınızın sahip olmadığı bir ayrıcalık gerektirir. Hata mesajı çözüm yolunu belirtir:

Error: rootlessport cannot expose privileged port 80, you can add 'net.ipv4.ip_unprivileged_port_start=80' to /etc/sysctl.conf (currently 1024), or choose a larger port number (>= 1024): listen tcp 0.0.0.0:80: bind: permission denied

İki çözüm yolu mevcuttur. Tüm ana makine için eşik değerini düşürün:

echo 'net.ipv4.ip_unprivileged_port_start=80' | sudo tee /etc/sysctl.d/99-podman.conf
sudo sysctl --system
sysctl net.ipv4.ip_unprivileged_port_start

Son komut, çıktı olarak 80 değerini döndürmelidir. Bu ayarın ne yaptığı konusunda net olun: Artık sadece konteynerleri çalıştıran kullanıcı değil, makinedeki her kullanıcı 80 ve 443 numaralı portları bağlayabilir. Tek bir yöneticisi olan bir VPS üzerinde bu kabul edilebilir bir takastır. Başka insanların hesaplarını barındıran bir sunucuda ise bu durum uygun değildir. Diğer çözüm ise 8080 portunda yayın yapmak ve önüne bir reverse proxy koymaktır; zaten certbot ile nginx üzerinde sertifika düzenleme ve yenileme işlemlerini de burada yapmak istersiniz.

Rootless yayınlama, uygulamanızın gördüğü veriyi de değiştirir. Podman 4.x varsayılan olarak rootlesskit port işleyicisi ile slirp4netns kullanır ve iletilen bağlantılar yeniden yazılmış bir kaynak adresiyle gelir; bu nedenle erişim günlükleri her ziyaretçiyi 10.0.2.100 olarak kaydeder. Podman 5.0 ile varsayılan ayar, gerçek istemci adresini koruyan pasta olarak değiştirilmiştir. 4.x sürümünde --network slirp4netns:port_handler=slirp4netns, bir miktar performans maliyeti karşılığında gerçek kaynak adresini geri yükler.

Burada olumlu bir sürpriz vardır. Rootless yayınlanan bir port, normal bir süreç tarafından sahiplenilen sıradan bir dinleme soketidir; bu nedenle güvenlik duvarınızın giriş kuralları bu porta uygulanır. Docker, portları NAT (ağ adresi çevirisi) kuralları ve kendi yönlendirme izinleri ile yazar; işte tam da bu yüzden yayınlanan bir Docker portu, engellediğini düşündüğünüz ufw kuralını yok sayar. Rootful Podman benzer bir altyapı kullanır ve aynı tuzağı miras alır. Rootless ise bunu yapmaz.

Docker Compose dosyalarım Podman altında çalışmaya devam eder mi?

Çoğunlukla, iki farklı yöntemle çalışır. İlki, aynı dosyayı okuyan ve Podman CLI'yı yöneten ayrı bir uygulama olan podman-compose'dır:

sudo apt install -y podman-compose
podman-compose up -d
podman ps

İkincisi ise, Podman'in Docker uyumlu API'si ile kullanıcı bazlı bir soket üzerinden konuşan gerçek Docker Compose'dur:

systemctl --user enable --now podman.socket
export DOCKER_HOST="unix:///run/user/$(id -u)/podman/podman.sock"
docker compose up -d
podman ps

docker compose ps ve podman ps aynı konteyner listesini vermelidir, çünkü tek bir konteyner kümesi mevcuttur. İsim çözümleme de çalışır: Podman'in varsayılan ağ arka ucu olan netavark, aardvark-dns çalıştırır; bu sayede kullanıcı tanımlı bir ağ üzerindeki konteynerler birbirlerini isimleriyle bulabilirler.

Uç durumlar gerçektir. /var/run/docker.sock bağlayan her şey Podman soketine yönlendirilmeli veya kaldırılmalıdır. network_mode: host, kullanıcı isim alanı (user namespace) altında farklı davranır. condition: service_healthy ile depends_on kullanımı, podman-compose sürümleri arasında tutarsız desteklenir. restart: always, yeniden başlatma sonrasında kendi kendine hayatta kalamaz; bir sonraki bölüm bunu düzeltmektedir. Compose, tek bir dosyada çoklu konteyner yığını tanımlamak için iyi bir yol olmaya devam eder ve Podman altında bir çeviri katmanı görevi görür. Yıllarca tutmayı planladığınız bir yığın için, bunu quadlet yapısına dönüştürün ve iki soyutlama yerine tek bir soyutlama ile yönetin.

Pod'lar: Docker'ın yanıt veremediği fikir

Pod, tek bir ağ ad alanını (network namespace) paylaşan bir grup container'dır. Podman, bu ad alanını açık tutmak için küçük bir infra container'ı başlatır; ardından üyeler, kullanıcı tanımlı bir ağ veya servis keşfi (service discovery) gerekmeksizin 127.0.0.1 üzerinden birbirlerine erişirler.

podman pod create --name app -p 8080:80
podman run -d --pod app --name app-cache docker.io/library/redis:7
podman run -d --pod app --name app-web docker.io/library/nginx:1.27
podman pod ps
podman ps --pod

podman pod ps, infra container'ı da dahil ederek üç container'lı pod Running yapısını göstermelidir. Web container'ı artık Redis'e app-cache:6379 adresi yerine 127.0.0.1:6379 üzerinden ulaşır. Paylaşılan ad alanından iki kural doğar: portları üye üzerinde değil pod üzerinde yayınlayın ve hiçbir üye aynı portu dinleyemez.

Bu, Kubernetes modelidir ve Podman bu modeli benimser. podman kube generate app > app.yaml, çalışmakta olan yapıdan bir Kubernetes manifest dosyası oluşturur (eski paketlerde bu komut podman generate kube olarak geçer) ve podman kube play app.yaml bunu başka bir sunucuda yeniden oluşturur. Quadlet, böyle bir dosyayı systemd servisi olarak çalıştıran bir .kube birim türüne sahiptir. Bu, servisleri gruplandırmak için gerçekten farklı bir yöntemdir ve gelecekte Kubernetes kullanma ihtimaliniz varsa Podman'i seçmek için en güçlü nedendir.

Daemon olmadan otomatik başlatma: Quadlet birimleri

Quadlet bir systemd oluşturucusudur. Bir konteyneri tanımlayan kısa bir dosyayı, sistem açılışında gerçek bir systemd servisine dönüştürür. Dosyalar, root yetkisi olmayan kullanıcılar için ~/.config/containers/systemd/ dizinine, root kullanıcısı için ise /etc/containers/systemd/ dizinine yerleştirilir.

~/.config/containers/systemd/caddy.container:

[Unit]
Description=Caddy web server
After=network-online.target

[Container]
Image=docker.io/library/caddy:2
ContainerName=caddy
PublishPort=8080:80
Volume=caddy-data.volume:/data
Environment=TZ=UTC
AutoUpdate=registry

[Service]
Restart=always
MemoryMax=512M

[Install]
WantedBy=default.target

~/.config/containers/systemd/caddy-data.volume neredeyse boş olabilir, çünkü bölüm başlığı birimin oluşturulmasını sağlar:

[Volume]

systemctl --user daemon-reload
systemctl --user start caddy
systemctl --user status caddy
journalctl --user -u caddy -n 50

Servis adı dosya isminden gelir: caddy.container, caddy.service haline gelir. systemctl --user enable caddy komutunu çalıştırmayın. Oluşturulan birimler etkinleştirilemez ve systemd Failed to enable unit: Unit /run/user/1000/systemd/generator/caddy.service is transient or generated. yanıtını verir. [Install] bölümü konteyneri açılışta başlatan kısımdır, daemon-reload ise dosyayı düzenledikten sonra birimi yeniden oluşturan komuttur.

Şimdi hemen herkesin takıldığı ayara gelelim:

sudo loginctl enable-linger deploy
loginctl show-user deploy --property=Linger

Linger=yes komutunu bekleyin. Linger özelliği etkinleştirilmediğinde, son SSH bağlantınız kapandığında systemd tüm kullanıcı oturumunu sonlandırır; bu nedenle root yetkisi olmayan tüm konteynerler durur ve hiçbiri açılışta geri gelmez. Oturumu kapattığınızda kaybolan konteynerlerin sebebi her zaman budur.

Konteyner, sıradan bir servis biriminin ana süreci olduğu için systemd'nin kendi kontrolleri doğrudan uygulanır. [Service] bölümündeki MemoryMax= ve CPUQuota=, systemd ile sınırladığınız diğer tüm servislerde olduğu gibi davranır. Bu işlem, Ubuntu'nun 22.04 sürümünden beri varsayılan olarak kullandığı cgroup v2 (control group version 2) gerektirir. podman info | grep -i cgroup komutu ile bunu doğrulayın.

Güncellemeler için eşleşen bir mekanizma mevcuttur. AutoUpdate=registry ve systemctl --user enable --now podman-auto-update.timer kullanımı, aynı etiket (tag) üzerinde daha yeni bir imaj olup olmadığını kayıt defterinden kontrol eder, birimi yeniden başlatır ve yeni konteyner başlatılamazsa önceki imaja geri döner. Nelerin değişeceğini görmek için önce podman auto-update --dry-run komutunu çalıştırın. Daha eski olan podman generate systemd komutu hala mevcuttur ancak kullanımdan kaldırılmıştır; bu nedenle yeni her şey için quadlet yazın.

Docker alias'ının geçerli olduğu ve olmadığı durumlar

sudo apt install -y podman-docker
sudo touch /etc/containers/nodocker
docker ps

podman-docker, Podman'i çağıran bir /usr/bin/docker sarmalayıcısı (wrapper) kurar. nodocker dosyası bulunmadığında, her çağrı önce Emulate Docker CLI using podman. Create /etc/containers/nodocker to quiet msg. çıktısını verir. Bu sarmalayıcı, gün boyu kullandığınız şu komutları kapsar: run, ps, logs, exec, build, pull, push, inspect, cp, volume, network.

Aktarılmayan özellikler ise daha kısa ve daha keskin bir listeden oluşur. Swarm modunun bir karşılığı yoktur, bu nedenle bir Swarm yığınının (stack) çalışabileceği bir yer bulunmaz. Docker soketi ile iletişim kuran araçların Podman soketine yönlendirilmesi gerekir; bazı araçlar yine de aradaki farkı algılar. Traefik'in Docker sağlayıcısı /run/user/<uid>/podman/podman.sock adresine yönlendirildiğinde çalışırken, Watchtower'ın burada bir yeri yoktur çünkü bu işi podman auto-update yapar. Depolama alanı ayrıdır, bu yüzden Podman daha önce Docker ile çektiğiniz imajları göremez ve yoğun bir Docker ana makinesindeki podman images başlangıçta boş görünür.

Çalışan bir yığının adım adım taşınması

1. Container'ların sahibi olacak yetkisiz kullanıcıyı oluşturun veya seçin ve bu kullanıcının /etc/subuid içinde bir aralığa sahip olduğunu doğrulayın.
2. Bir kayıt defterinden gelen her şeyi tam nitelikli adlar kullanarak yeniden çekin. Podman kendi image deposuna sahiptir ve Docker'ınkini okumaz.
3. Yerel olarak oluşturulan image'ları docker save app:1.4 | podman load kullanarak taşıyın.
4. Docker container'ını durdurun, her bir volume içeriğini /var/lib/docker/volumes/<name>/_data dizininden kopyalayın ve ardından podman unshare chown -R 1000:1000 <path> ile sahiplik ayarlarını düzeltin.
5. Port sorununu çözün: 1024 üzerindeki portları bir reverse proxy arkasında yayınlayın veya net.ipv4.ip_unprivileged_port_start ayarını yapın.
6. Her container için bir quadlet dosyası yazın, systemctl --user daemon-reload komutunu çalıştırın ve her servisi başlatın.
7. sudo loginctl enable-linger <user> komutunu çalıştırın, VPS'i yeniden başlatın, tekrar giriş yapın ve podman ps komutunun her servisi listelediğini doğrulayın.

İki motor hiçbir şeyi paylaşmaz: ayrı image depolama alanları ve ayrı ağlar kullanırlar. Bu nedenle taşıma sırasında her ikisini de çalıştırabilirsiniz; çakışabilecekleri tek nokta host port numarasıdır. Bir servisi taşıyın, bir gün boyunca izleyin ve ardından diğerine geçin.

Podman ve Docker: VPS'niz için hangisi uygun?

Eğer yığınınız başkalarının da bakımını yaptığı compose dosyalarında yaşıyorsa veya Docker soketi ile iletişim kuran araçlara bağımlıysanız Docker kullanmaya devam edin. Başkalarının yazdığı kodlarla uyumluluk gerçek bir özelliktir ve Docker bu konuda daha fazlasına sahiptir. Dizüstü bilgisayarlarında Docker çalıştıran bir ekip, üretim ortamında da aynı motoru çalıştırarak somut bir kazanım elde eder.

Eğer VPS'niz uçtan uca kontrol ettiğiniz birkaç servisi çalıştırıyorsa veya her uygulamanın sunucuda hiçbir docker grubu olmadan kendi yetkisiz kullanıcısı altında çalışmasını istiyorsanız Podman'e geçin. Dağıtım uyumu da önemlidir: RHEL ve türevleri, desteklenen motor olarak Podman ile gelir; bu nedenle bu sistemlerde Podman daha az sürpriz içeren yoldur. Yine de bu ana makinelerden birinde Docker kullanmak isterseniz, Rocky Linux ve AlmaLinux üzerinde dnf yolu, halihazırda docker komutuna sahip olan podman-docker sarmalayıcısını kaldırarak başlar. Eğer diğer her şeyi zaten systemd birimleri ile yönetiyorsanız, quadlet'ler öğrenilmesi gereken yeni bir araçtan ziyade eksik bir parçanın tamamlanması gibi hissettirecektir.

Bir orta yol seçeneğinden bahsetmekte fayda var. Rootful Podman, Docker'a benzer şekilde davranır, sarmalayıcı aracılığıyla docker komutunu korur ve sürekli çalışan daemon ihtiyacını ortadan kaldırır. Ancak bu yöntem, güvenlik duruşunuzu değiştiren kısım olan rootless (kök dizin yetkisi gerektirmeyen) çalışma özelliğinden vazgeçmenize neden olur; bu yüzden bunu bir geçiş durağı olarak değerlendirin.

Eğer hala ilk konteyner ana makinenizi oluşturuyorsanız, yeni bir VPS üzerinde Docker kurulumu ve sıkılaştırma yolu daha kısa olan yoldur ve bu süreçte edindiğiniz hiçbir bilgi boşa gitmez. İmajlar ve birimler (volumes) her iki motor altında da aynı nesnelerdir; bu nedenle daha sonra yapacağınız bir geçiş, servislerinizin denetlenme biçimini değiştirir ancak bunun dışında çok az şeyi etkiler.

FAQ

Podman, Docker'ın doğrudan bir alternatifi midir?

Komut satırı kullanımı açısından oldukça yakındır. podman-docker kurulumu size bir /usr/bin/docker sarmalayıcısı sağlar; run, ps, build, logs ve exec komutları aynı şekilde çalışır. Ancak daemon yapısı için bir alternatif değildir. Swarm'ın bir karşılığı yoktur, /var/run/docker.sock ile bağlantı kuran araçların kullanıcı bazlı Podman soketine yönlendirilmesi gerekir ve Docker tarafından çekilen imajlar, iki araç ayrı depolama alanları kullandığı için Podman tarafından görülmez.

Rootless Podman container'larım neden SSH oturumunu kapattığımda duruyor?

Çünkü son oturumunuz kapandığında systemd, kullanıcı oturumunu ve bu oturuma bağlı tüm servisleri sonlandırır. sudo loginctl enable-linger <user> komutunu çalıştırın ve ardından loginctl show-user <user> --property=Linger komutunun Linger=yes çıktısını verdiğinden emin olun. Linger özelliği, aktif bir oturum olmasa dahi kullanıcının systemd örneğinin çalışmaya devam etmesini sağlar; bu aynı zamanda container'ların yeniden başlatma sonrasında otomatik olarak ayağa kalkmasını sağlar.

Volume içindeki dosyalar neden UID 100999 sahipliğinde görünüyor?

Rootless Podman, container içindeki UID 0 değerini ana makinedeki kullanıcınızla eşler, ardından container içindeki UID 1 ve üzerini subuid aralığınıza göre eşler. 100000 ile başlayan bir aralıkta, container içindeki UID 1000, ana makinede 100999'a karşılık gelir. Bu durumu namespace içinden podman unshare chown 1000:1000 /path/to/data ile düzeltin, ilk çalıştırmada :U bayrağını kullanın veya container UID'lerinin kendi UID'nizle eşleşmesi için --userns=keep-id seçeneğinden yararlanın.

docker-compose.yml dosyasını Podman ile kullanmaya devam edebilir miyim?

Evet, iki yöntemle mümkündür. podman-compose dosyayı okur ve Podman CLI'yı doğrudan yönetir. Alternatif olarak, systemctl --user enable --now podman.socket ile uyumluluk soketini etkinleştirin, DOCKER_HOST=unix:///run/user/$(id -u)/podman/podman.sock değişkenini ayarlayın ve gerçek docker compose komutunu bu soket üzerinden çalıştırın. network_mode: host üzerinde, Docker soketini mount eden servislerde ve yeniden başlatma sonrası süreklilik için quadlet birimi ve linger gerektiren restart: always üzerinde bazı uyumsuzluklar yaşanabilir.

Rootless kullanımı container'ları gerçekten daha güvenli hale getirir mi?

Belirli bir riski ortadan kaldırır: rootless bir container'dan dışarı sızan bir süreç, root yetkileri yerine sizin yetkisiz kullanıcı izinlerinize sahip olur. Bu önemli bir kazanımdır ve root yetkilerine eşdeğer olan docker grubunun rootless Podman altında bir karşılığının olmamasının nedeni budur. Bu durum çekirdek (kernel) açıklarını engellemez ve kendi kullanıcınızın okuyabildiği dosyaları korumaz; bu nedenle herhangi bir sunucuda uygulayacağınız diğer güvenlik sıkılaştırma adımlarını uygulamaya devam etmelisiniz.