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; bu nedenle 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 gerçeklikten kaynaklanır. Otomatik başlatma işlemi, daemon yerine systemd'nin görevi haline gelir. Volume sahipliği, bir kullanıcı namespace'i ü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 şey Docker socket'ine ihtiyaç duyana kadar bir sarmalayıcı (wrapper) aracılığıyla çalışmaya devam eder.

Daemon yokluğu: Bir container başlattığınızda gerçekte ne çalışır

Bir Docker sunucusunda pstree -a komutu, dockerd sürecini root olarak, yanında containerd sürecini ve çalışan her 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ı kalmaz. Daemon'ı durdurursanız sunucudaki tüm container'lar için kontrol düzlemini kaybedersiniz; ayrıca 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, komutu çalıştıran kullanıcıya ait olan ve container'ın ana sürecini tutan 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; curl komutu ise 200 çıktısını vermelidir. Container'ların sahibi olan merkezi bir servis bulunmadığı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ğinin bir bedeli de vardır. Yeniden başlatma sonrasında container'larınızı otomatik olarak başlatan bir mekanizma yoktur. 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 bilgisayar dosya sistemini bağlayan 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 verme bölümünde 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ı kimlikleri (subordinate IDs) aralığını 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. Bu sürüm farkı önemlidir; çünkü quadlet dosyaları 4.4 veya daha yeni bir sürüm gerektirirken, .pod quadlet dosyaları 5.0 sürümüne ihtiyaç duyar. Resmi dokümantasyondan bir örnek kopyalamadan önce podman --version komutunu çalıştırın.

Her rootless kullanıcının bir alt kimlik 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 değildir 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 ilgili 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 user namespace içinde çalışır. Namespace içinde container'ın süper kullanıcısı UID 0'dır. Namespace dışında, yani VPS'inizde, aynı süreç sizin sıradan kullanıcı hesabınızla çalışı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 açıklarına karşı koruma sağlamaması ve kendi dosyalarınızı korumamasıdır; çünkü kaçan süreç sizin adınıza çalışır ve sizin okuyabildiğiniz her şeyi okuyabilir.

Docker da rootless çalışabilir. dockerd-rootless-setuptool.sh install kullanıcı bazlı bir daemon kurulumu yapar ve sorunsuz çalışır. Fark, varsayılan yapılandırmanın yönüdür. Podman ile rootless yapılandırması herhangi bir ek ayar gerektirmeden gelir; bu nedenle ilk karşılaştığınız hata, iki yıl boyunca sessizce root olarak çalışan bir servis yerine, 80 numaralı porta bağlanamayan bir container olur.

Neden volume dosyalarımın sahibi UID 100999?

Bunun nedeni aynı kullanıcı isim 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 artar. 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 makine listelemesi ise 100999 sahibini gösterir, çünkü 100000 artı 1000 eksi 1, 100999 eder. Herhangi bir hata yoktur ve basit bir chown komutu bunu düzeltmeyecektir, çünkü yetkisiz kullanıcınız isim alanı dışında dosya sahipliğini değiştiremez.

Çözüm için dört yol mevcuttur:

• podman unshare chown 1000:1000 "$PWD/data", chown işlemini aynı kullanıcı isim alanı içinde çalıştırır; burada numaralar container için ne ifade ediyorsa o anlama gelir.
• -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 volume (named volume), bu sorunu tamamen ortadan kaldırır çünkü Podman bunu kendi depolama alanı içinde, sahiplik bilgisi zaten doğru olacak şekilde oluşturur.

Eğer bu sorunla Docker'da da karşılaştıysanız, bu bir katman yukarıdaki 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 makinede hala 100999 sahipliğine sahip dosyalar oluşturur. Numaraları bu ikinci eşlemeyi göz önünde bulundurarak seçin veya verileri adlandırılmış bir volume içine taşıyarak bu konuyla uğraşmayı bırakın.

Mount işlemleriyle ilgili iki not daha: Fedora ve RHEL örneklerinde gördüğünüz :z ve :Z bayrakları SELinux yeniden etiketleme seçenekleridir; Ubuntu AppArmor kullandığı için bu bayrakların orada bir etkisi yoktur. Ayrıca rootless Podman, kullanıcınızın okuyamadığı bir ana makine dizinini mount edemez; bu bir hata değil, sistemin çalışma prensibidir.

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

Çünkü 1024'ün altındaki bir porta bağlanmak, kullanıcı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 80 değerini döndürmelidir. Bu ayarın ne işe yaradığını netleştirin: Artık sadece container çalıştıran kullanıcı değil, makinedeki her kullanıcı 80 ve 443 numaralı portlara bağlanabilir. Tek bir yöneticinin bulunduğu bir VPS üzerinde bu kabul edilebilir bir durumdur. Başkalarının hesaplarının bulunduğu bir sunucuda ise bu uygun değildir. Diğer çözüm yolu ise 8080 üzerinden yayın yapmak ve önüne bir reverse proxy koymaktır; zaten certbot ile nginx üzerinde sertifika oluşturma ve yenileme işlemini 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 logları 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 kaybı pahasına gerçek kaynak adresini geri getirir.

Burada iyi bir sürpriz var. 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ı buna 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 sandığınız ufw kuralını görmezden gelir. 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 evet, ancak iki farklı yöntemle. İ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'ın Docker ile 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'ın 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 mevcuttur. /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. depends_on ile condition: service_healthy kullanımı, podman-compose sürümleri arasında tutarsız desteklenir. restart: always, yeniden başlatma sonrasında kendi kendine ayağa kalkmaz; bir sonraki bölüm bu sorunu çözer. Compose, tek bir dosyada çoklu konteyner yığını tanımlamak için iyi bir yöntem olmaya devam eder ve Podman altında bir çeviri katmanı görevi görür. Yıllarca kullanmayı planladığınız bir yığın için, bunu quadlet yapısına dönüştürün ve iki farklı soyutlama yerine tek bir tanesini 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ğa veya servis keşfine ihtiyaç duymadan 127.0.0.1 üzerinden birbirlerine ulaşırlar.

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 komutu, infra container'ı da dahil olmak üzere üç container içeren 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ı nedeniyle iki kural geçerlidir: portları pod üzerinde yayınlayın (asla bir üye üzerinde değil) ve hiçbir üye aynı portu dinleyemez.

Bu, Kubernetes modelidir ve Podman bu modeli benimser. podman kube generate app > app.yaml, çalışan yapıdan bir Kubernetes manifest dosyası yazar (eski paketlerde bu komut podman generate kube şeklindedir) 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ı, açılışta gerçek bir systemd servisine dönüştürür. Dosyalar, root 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, bölüm başlığı birimi oluşturduğu için neredeyse boş olabilir:

[Volume]

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

Servis adı dosya adından 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 neredeyse herkesi yanıltan ayara gelelim:

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

Linger=yes komutunun çalıştırılması beklenir. Linger ayarı yapılmazsa, son SSH bağlantınız kapandığında systemd tüm kullanıcı oturumunu sonlandırır; bu nedenle root olmayan tüm konteynerler durur ve hiçbiri açılışta geri gelmez. Oturumu kapattığınızda kaybolan konteynerlerin sebebi her zaman budur.

Konteyner, standart bir servis biriminin ana süreci olduğundan, systemd'nin kendi denetimleri 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, 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 ile bunu doğrulayın.

Güncellemelerin eşleşen bir mekanizması vardır. 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 takma adı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ı kurar. nodocker dosyası olmadan, 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ılmayanlar ise daha kısa ve daha keskin bir listedir. Swarm modunun bir karşılığı yoktur, bu nedenle bir Swarm yığınının çalışabileceği bir yer bulunmaz. Docker soketi ile iletişim kuran araçların Podman soketinin dışa aktarılmasına ihtiyacı vardır ve bazıları aradaki farkı yine de algılar; Traefik'in Docker sağlayıcısı /run/user/<uid>/podman/podman.sock adresine yönlendirildiğinde çalışırken, Watchtower'ın hiçbir yeri yoktur çünkü bu işi podman auto-update yapar. Depolama alanı ayrıdır, bu nedenle Podman daha önce Docker ile çektiğiniz imajları göremez ve yoğun bir Docker ana makinesindeki podman images boş başlar.

Ç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. Registry'den gelen her şeyi tam nitelikli adlarını 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'un 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 tekrar listelediğini kontrol edin.

İki motor hiçbir şeyi paylaşmaz: image depolama alanları ve ağlar birbirinden ayrıdır. Bu nedenle taşıma işlemi sırasında her ikisini de çalıştırabilirsiniz; çakışabilecekleri tek nokta ana makine 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'nizde hangisi yer almalı?

Eğer yığınınız başkalarının da yönettiği 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. 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, büyük ölçüde Docker gibi 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 rootless (kök yetkisi gerektirmeyen) çalışma özelliğinden vazgeçmenize neden olur; bu yüzden bunu geçici bir durak olarak değerlendirin.

Eğer hala ilk container 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 büyük oranda öyledir. 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 bunun yerine kullanıcıya özel Podman soketine yönlendirilmelidir ve Docker tarafından çekilen imajlar, iki araç farklı depolama alanları kullandığı için Podman tarafından görülmez.

Neden rootless Podman container'larım SSH oturumunu kapattığımda duruyor?

Çünkü son oturumunuz kapandığında systemd, kullanıcı oturumunu ve bu oturuma bağlı tüm kullanıcı servislerini 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ğini doğrulayın. 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.

Neden volume içindeki dosyalar 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 1 ve üzerindeki UID değerlerini subuid aralığınıza haritalar. 100000 ile başlayan bir aralıkta, container içindeki UID 1000 değeri ana makinede 100999 olur. Bu durumu namespace içinden podman unshare chown 1000:1000 /path/to/data ile düzeltebilir, ilk çalıştırmada :U bayrağını kullanabilir veya container UID'lerinin sizinle eşleşmesi için --userns=keep-id seçeneğinden yararlanabilirsiniz.

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ştirip DOCKER_HOST=unix:///run/user/$(id -u)/podman/podman.sock değişkenini ayarlayarak gerçek docker compose komutunu bu soket üzerinden çalıştırabilirsiniz. network_mode: host kullanımı, Docker soketini mount eden servisler ve yeniden başlatma sonrasında kalıcı olması için quadlet unit ve linger gerektiren restart: always yapılandırmalarında 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.