Güvenliği artırılmış Docker alternatifi: ‘Podman’ incelemesi

 (betterstack.com)
6 puan yazan GN⁺ 2024-01-14 | 1 yorum | WhatsApp'ta paylaş
  • Podman, Docker’a benzer bir konteyner çalıştırma deneyimi sunarken daemon olmadan çalışması sayesinde güvenlik ve denetim izi açısından ayrışır
  • Docker, Docker daemon merkezli bir istemci-sunucu yapısı kullanırken Podman, konteynerleri doğrudan kullanıcı oturumunda oluşturur; bu da çalıştıran kullanıcıyı izlemeyi daha net hale getirir
  • OCI standardını izlediği için Docker Hub’daki hello-world, caddy, wordpress, mysql:5.7 gibi imajları çalıştırabilir ve birçok durumda docker komutunu podman ile değiştirerek kullanabilirsiniz
  • Kısa imaj adları, Docker’daki gibi Docker Hub’ı otomatik varsayılan olarak kullanmadığından tam imaj adı, takma ad veya unqualified-search-registries ayarlarından biri gerekir
  • Çoklu konteyner yapılandırmaları Podman Compose, pod’lar ve Kubernetes manifest’leriyle yönetilebilir; ancak Docker Swarm benzeri yerleşik üretim orkestrasyonu olmadığından Kubernetes gibi harici bir sistem kullanmak gerekir

Podman ile Docker’ın ayrıldığı nokta

  • Podman, Docker’a göre daha güvenli ve daha hafif bir alternatif olmayı hedefleyen açık kaynaklı bir konteyner motorudur
  • Sürekli arka planda çalışan bir daemon olmadan konteyner çalıştırır ve kullanıcıların konteynerleri doğrudan yönetmesini sağlayan bir yapıya sahiptir
  • Varsayılan güvenlik yaklaşımı rootless konteynerler, kullanıcı ad alanları ve kernel capability’lerinin daha temkinli kullanımına odaklanır
  • Docker imajları ve komut yapısıyla yüksek uyumluluk sunduğu için Docker alternatifi arayan geliştiriciler ve sistem yöneticileri için pratik bir seçenektir

Mimari ve denetim izi

  • Docker, istemci-sunucu modelini kullanır ve konteyner çalıştırma istekleri Docker client’tan Docker daemon’a iletilir
    • Konteyner süreçleri, kullanıcı oturumunun değil Docker daemon’un alt süreçleri olur
    • Linux denetim sistemi auditd, konteyner süreç olaylarını algıladığında denetim kullanıcı kimliği gerçek kullanıcı kimliği yerine unset olarak görünebilir
    • Bu yapıda kötü niyetli etkinlikleri belirli bir kullanıcıyla ilişkilendirmek zordur
  • Podman, daemon’suz mimari kullanır
    • Her konteyner doğrudan kullanıcının oturum açtığı oturum üzerinden oluşturulur
    • Konteyner süreç verileri kullanıcı bilgisini korur
    • auditd, belirli bir konteyner sürecini başlatan kullanıcı kimliğini doğru biçimde algılayıp kaydedebilir
  • İmaja bağlı olarak Podman’ın konteyner başlatma hızı Docker’dan %50’ye kadar daha hızlı olabilir

Konteyner yaşam döngüsü yönetimi

  • Podman’da daemon olmadığı için konteyner yaşam döngüsü yönetimi de Docker’dan farklıdır
  • Linux’ta büyük ölçüde Systemd’ye dayanır
    • --restart always bayrağıyla belirtilen konteynerlerin yeniden başlatma ilkesini uygulamak için podman-restart adlı bir systemd servisi kullanır
    • Bu servis, sistem yeniden başlatıldıktan sonra belirtilen konteynerleri otomatik olarak tekrar başlatır
  • Çalışan konteynerlerden Systemd servis dosyası oluşturan komutlar da sunar
    • Konteynerleri systemd yönetimine almak; başlatma, durdurma ve denetimi kolaylaştırır
  • Docker bu işleri daemon içinde halleder

Orkestrasyon seçenekleri

  • Yerel geliştirmede Docker kullanıcıları genelde çoklu konteyner uygulamalarını tanımlamak ve yönetmek için Docker Compose kullanır
  • Podman, Compose dosyalarını yerleşik olarak desteklemez ancak Podman Compose ile uyumlu bir alternatif sunar
    • Genellikle mevcut docker-compose.yml dosyalarıyla çalışır
    • Docker Compose’a alışkın kullanıcılar mevcut Compose dosyalarını kullanmayı sürdürebilir
  • Podman’ın yerel yaklaşımı olarak pod’lar kullanılabilir
    • Bu kavram Kubernetes’ten gelir
    • Birden fazla konteyner tek bir birim gibi yönetilebilir
  • Üretim dağıtımlarında Podman’da Docker Swarm benzeri yerleşik bir orkestrasyon aracı yoktur
    • Bu durumda Kubernetes gibi harici orkestrasyon sistemleri alternatif olur
    • Kubernetes, Podman ile entegre olabilir ancak düzgün çalışması için ek yapılandırma ve ayarlar gerekebilir

Varsayılan güvenlik ayarları

  • Konteyner güvenliğindeki büyük risklerden biri, konteynerden kaçış yaşanıp ana sistemin ele geçirilmesidir
  • Podman, Docker’a göre daha güçlü varsayılan güvenlik ayarları sunacak şekilde tasarlanmıştır
    • rootless konteynerler
    • kullanıcı ad alanları
    • seccomp profilleri
  • Docker’da da rootless konteynerler, kullanıcı ad alanları ve seccomp profilleri kullanılabilir; ancak bunlar varsayılan olarak etkin değildir ve çoğu zaman ek yapılandırma gerekir
  • Podman’ın varsayılan yapılandırması, rootless konteynerleri izole kullanıcı ad alanları içinde çalıştırarak olası kaçışların etkisini sınırlar
  • Docker’ın varsayılan yapılandırması ise konteyner süreçlerini root olarak çalıştırır; bu da kaçış durumunda daha yüksek risk oluşturur
  • Capability varsayılanları da farklıdır
    • Podman varsayılan olarak konteynerleri 11 capability ile başlatır
    • Docker ise daha izin verici bir varsayılanla 14 capability kullanır
  • Her iki araç da güçlü güvenlik yapılandırmalarıyla ayarlanabilir, ancak Podman’da bu seviyeye ulaşmak için genelde daha az çaba gerekir

Özellik karşılaştırmasında öne çıkan farklar

  • Podman, daemon’suz mimariyi ve Systemd entegrasyonunu destekler
  • Konteynerleri pod’lar halinde gruplayabilir ve Kubernetes YAML dosyalarıyla çalışabilir
  • Docker, Docker Swarm’ı desteklerken Podman desteklemez
  • Bunun dışındaki çoğu özellikte iki taraf büyük ölçüde eşdeğer kabul edilebilir

Kurulum ve çalışma ortamı

  • Podman, Docker gibi başlıca işletim sistemlerinde çalışabilir
    • macOS
    • Windows
    • büyük Linux dağıtımları
  • Önemli fark, Linux’ta yerel olarak çalışırken Windows ve macOS’te sanal makine gerektirmesidir
  • Örnekler, Debian tabanlı Linux dağıtımları olan Ubuntu, Mint ve Debian’ı varsayar
  • En güncel Podman’ı kurmak için nispeten yeni bir dağıtım gerekir
    • Yazının yazıldığı sıradaki en güncel ana Podman sürümü 4.x
    • Ubuntu 22.04 LTS, Podman 3.x sürümüne bağlıdır
    • Örnekler Ubuntu 23.10 temel alınarak verilmiştir
  • Kurulumdan sonra örnek çıktı podman version 4.3.1 şeklindedir ve yerelde podman komutunun çalıştırılabildiğini doğrular

Docker imajlarını çalıştırma ve OCI uyumluluğu

  • Podman, Docker ekosistemi araçlarıyla oluşturulmuş hello-world imajını çalıştırabilir
  • Bu uyumluluk, hem Docker’ın hem de Podman’ın OCI (Open Container Initiative) standartlarını izlemesinden kaynaklanır
    • OCI, imaj biçimi belirtimini ve çalışma zamanı belirtimini tanımlar
    • Farklı konteyner çalışma zamanlarının birlikte çalışabilmesini sağlar
  • Docker Hub’daki çoğu Docker imajı ve konteyneri Podman’da kullanılabilir
  • Böylece mevcut iş yüklerini değişiklik yapmadan Podman’a taşıyabilir veya Docker Hub’daki imaj kütüphanesinden yararlanabilirsiniz
  • hello-world çıktısında “Hello from Docker!” yazsa bile gerçekte çalıştıran Podman’dır
    • Docker client ya da Docker daemon çalıştırma sürecine dahil olmaz

Kısa imaj adı işleme biçimi

  • Docker, tam imaj adı belirtilmezse varsayılan kayıt defteri olarak Docker Hub docker.io’yu kullanır
  • Podman, kısa ad kullanımını teşvik etmez ve varsayılan kayıt defterini otomatik olarak varsaymaz
  • hello-world, shortnames.conf içinde bir takma ada sahip olduğu için docker.io/library/hello-world olarak çözümlenir
  • caddy gibi takma adı olmayan bir imaj kısa adla çalıştırılırsa şu hata alınır
    • Error: short-name "caddy" did not resolve to an alias and no unqualified-search registries are defined in "/etc/containers/registries.conf"
  • Bunun üç çözümü vardır
    • Tam imaj adı kullanarak docker.io/library/caddy gibi açıkça belirtmek
    • registries.conf içine [aliases] bölümü ekleyip "caddy"="docker.io/caddy" biçiminde takma ad tanımlamak
    • unqualified-search-registries=["docker.io"] ayarlayıp kısa adların Docker Hub’da aranmasını sağlamak
  • Kullanıcıya özel ayarlar $HOME/.config/containers/registries.conf dosyasına konabilir
    • Bu dosya /etc/containers/registries.conf dosyasından önceliklidir
    • Root yetkisi olmadan yapılandırılabildiği için rootless yaklaşımla daha iyi uyum sağlar
  • Podman’ı bir Docker yerine kullanmak istiyorsanız, uzun vadede takma adlardan çok unqualified-search-registries ayarı daha kullanışlıdır

Özel kayıt defteri kullanımı

  • Podman da Docker gibi özel kayıt defterleri kullanabilir
  • Docker Hub hesabı kullanılan örnek şu akışı izler
    • Docker Hub’da bir access token oluşturulur
    • Açıklama Podman tutorial, izinler Read & Write olarak ayarlanır
    • Özel bir repository oluşturulur
    • podman login docker.io ile oturum açılır
  • docker.io, registries.conf içindeki ilk unqualified-search-registries girdisiyse atlanabilir; ancak kayıt defterini açıkça belirtmek iyi bir pratiktir
  • Kayıt defteri belirtilmezse podman login şu hatayla başarısız olur
    • Error: no registries found in registries.conf, a registry must be provided
  • Oturum açtıktan sonra hello-world imajı özel repository’ye push edilebilir, yereldeki public imaj silinebilir ve ardından özel repository imajıyla konteyner çalıştırılabilir
  • Geçerli oturum açma bilgileri yoksa özel imajı pull etmeye çalışırken erişim reddi ve kimlik doğrulama gerektiğine dair hata alınır
  • Özel kayıt defteri kullanımında dikkat çeken temel fark, docker yerine podman kullanılmasıdır; Podman yaygın özel kayıt defterleriyle çalışabilir

Podman Compose ile çoklu konteyner çalıştırma

  • Birden fazla konteyneri tek bir birim olarak çalıştırmanız gerektiğinde Podman birkaç seçenek sunar
    • Podman Compose
    • pod’lar
    • Kubernetes manifest’leri
  • Örnek, Podman Compose kullanarak WordPress ve MySQL çalıştırır
  • Podman Compose, topluluk odaklı bir araçtır; Compose specification standardını uygular ve Podman ile entegre olur
  • Python 3’e bağımlıdır ve örnekte pipx ile kurulur
    • Örnek kurulum çıktısı podman-compose 1.0.6
    • Kullanılan Podman sürümü 4.3.1
  • pipx, $HOME/.local/bin altına kurulum yaparsa bu yol $PATH içinde olmayabilir
    • pipx ensurepath ile yol eklenebilir
    • Yeni bir terminal açmak veya kabuk yapılandırma dosyasını yeniden yüklemek gerekir

WordPress ve MySQL örneği

  • Örnekte, veritabanı kullanıcısı, parola ve veritabanı adı .env dosyasında tanımlanır; WordPress ve MySQL servisleri ise docker-compose.yml ile yapılandırılır
  • podman-compose up -d çalıştırıldığında Podman Compose, docker-compose.yml dosyasını analiz eder
  • wordpress servisinin işlenişi
    • Gerekli external volume aranır, yoksa oluşturulur
    • Uygun network aranır, yoksa oluşturulur
    • wordpress konteyneri çalıştırılır
    • Yerel imaj yoksa yapılandırılmış docker.io kayıt defterinden wordpress:latest çekilir
  • db servisinin işlenişi
    • podman-tutorial_db volume’u oluşturulur
    • Mevcut ağ kontrol edilir
    • mysql:5.7 konteyneri çalıştırılır
    • Yerel imaj yoksa Docker Hub’dan çekilir
  • Çalıştırdıktan sonra localhost:8080 adresinde WordPress kurulum sayfası görülebilir
  • podman ps çıktısında wordpress ve db konteynerlerinin çalıştığı görünür
    • wordpress, 0.0.0.0:8080->80/tcp ile porta eşlenmiştir
    • db, mysql:5.7 imajıyla çalışır
  • İmaj listesinde docker.io/library/wordpress:latest ve docker.io/library/mysql:5.7 görünür
  • Ağ listesinde varsayılan podman ağı ile Podman Compose’un oluşturduğu podman-tutorial_default ağı görünür
    • podman-tutorial_default, docker-compose.yml içinde tanımlı konteynerleri aynı sistemdeki diğer konteynerlerden ayırmak için oluşturulur
  • Volume listesinde podman-tutorial_db ve podman-tutorial_wordpress görünür
  • podman-compose down, konteynerleri durdurup siler ancak ağı ve volume’leri korur
    • Volume kaldırmak için podman volume rm kullanılır
    • Ağ kaldırmak için podman network rm kullanılır
  • Komutlar Docker ve Docker Compose’a çok benzer; fark, docker ve docker-compose yerine podman ve podman-compose yazılmasıdır

Seçim ölçütleri

  • Podman, konteyner iş yüklerini çalıştırmak için Docker’a pratik bir alternatiftir
  • Docker’ın yapabildiği işlerin çoğunu yapabilir ve arka planda çalışan bir daemon gerektirmemesi avantaj sağlar
  • Docker’da olmayan bazı özellikler de sunar
    • Kubernetes manifest dosyalarıyla çalışma
    • Tek tek konteynerleri pod’lar halinde düzenleme
  • Daha hafif ve daha güvenli bir konteyner yönetim çözümüne ihtiyacınız varsa Podman daha iyi bir seçenek olabilir
  • Güçlü ekosistem ve geniş topluluk desteği önceliğinizse Docker daha uygun olabilir
  • Daha fazla inceleme için Podman resmi web sitesi, dokümantasyon ve topluluk kaynaklarına bakabilirsiniz

İlgili okumalar

1 yorum

 
GN⁺ 2024-01-14
Hacker News yorumları

  • Podman'ın systemd unit dosyalarını desteklediği zamanlar iyiydi. Çünkü yalnızca container'ları değil, tüm pod'ları da systemd ile otomatik başlatıp otomatik güncelleyebiliyordunuz
    Sonra bu özelliği kaldırıp Quadlet'i öne çıkarmaya başladılar. Tekil container'lar unit dosyalarıyla yapılabiliyor ama pod'lar için Kubernetes cluster tanımı kullanmak gerekiyor
    Üstelik Docker'dan farklı olarak container'lar SELinux tanımlarına uyduğu için, eşlediğim dizinlere erişemedikleri durumlarda birkaç kez epey uğraştım
    Sonuçta Podman'ın ne yapmamı istediğini anlayamıyorum. Kubernetes mi kullanmalıyım? Mantıksal yolları eşlemek yerine her şey için özel dizinler mi oluşturmalıyım?

    • Altyapımı zaten docker-compose.yml ile tanımlıyordum; podman-compose'ta systemd unit'leri oluşturmak için, dokümantasyonu zayıf bir özellik olduğunu öğrendim
      Bu özellik artık kullanımdan kaldırılmış Podman işlevini kullanmadan unit dosyalarını doğrudan yazıyor; kişisel olarak da eski Podman yönteminden çok daha sorunsuz buldum
      Özelliği etkinleştirmek için $ podman-compose systemd -a create-unit, systemd unit kaydı için ise $ podman-compose systemd -a register, $ systemctl --user enable --now "podman-compose@$PROJECT_NAME" kullanılıyor
      Güncelleme $ podman-compose pull ardından $ systemctl --user restart "podman-compose@$PROJECT_NAME" ile yapılıyor. $PROJECT_NAME genelde dizin adı oluyor
      İncelemek isterseniz özelliğin kaynak kodu burada: https://github.com/containers/podman-compose/blob/f6dbce3618...
      Hâlâ podman 4.3.1 kullanıyorum ama sonraki sürümlerde bu yöntemin durması için bir neden görünmüyor
    • “Docker'dan farklı olarak container'lar SELinux tanımlarına uyar” denmesi aslında Docker'daki bir hata. Sistem SELinux için yapılandırılmadıysa kapatılmalı
      Ayrıca podman-generate-systemd'nin ürettiği systemd dosyaları nihayetinde "podman start containername" çalıştırmaktan ibaretti, bu yüzden elle yazmak da kolay. Ancak docker-compose gibi şeylerden farklı olarak container neredeyse bir kara kutu
      Quadlet'in avantajı, container tanımının .container dosyasında bildirimsel olarak yer alması. Eskiden podman run komut satırını elle systemd unit'ine yazardık; bu açıdan Quadlet büyük bir iyileştirme ve docker-compose'a alternatif de olabilir. Elbette artıları ve eksileri var
    • Uzun süredir hayranı olarak bunu kabul ediyorum
      podman generate systemd [...] çalıştırmaya her kalktığımda bu geçişin yaşandığını yeniden hatırlıyorum
      Bunu sık yaşamamamın nedeni, bu işi makul bir şekilde halleden bir Ansible rolünü kendim yazmış olmam
      Yine de Podman'ın yönünü kaybetmiş gibi hissettirdiği çok açık. Unit dosyası bakımı ve ilişki tasarımı tarafını zaten benimsediniz; o hâlde keşke generator'ı kullanmamıza izin verseniz. Quadlet'miş, daha iyiymiş gibi argümanlar umurumda değil
    • SELinux ile uğraşmak istemiyorsanız containers.conf dosyasına şunu ekleyebilirsiniz: [containers] label=false
      Podman'ın varsayılan güvenlik seviyesi hoşunuza gitmiyorsa genelde kapatmanın bir yolu vardır
    • Yakın zamanda NixOS'a geçtim; NixOS, container'lar dahil her şey için referans noktası olarak systemd'yi kullanıyor
      Bu model çok sezgiseldi ama Docker Compose'a uygulamak için çok fazla elle taşıma gerekiyordu
      Bu yüzden Compose dosyalarını NixOS yapılandırmasına dönüştürüp yerel olarak yorumlanıp yönetilebilmesini sağlayan bir araç yaptım: https://github.com/aksiksi/compose2nix

  • Podman'ı Docker'a tercih etmek için belirleyici bir neden olarak pek dile getirilmeyen bir avantaj var: Docker ağ ayarlarını bozuyor
    Docker ile KVM sanal makinelerini bridge ile aynı anda çalıştırmaya çalışmak kâbus; Podman ise varsayılan ayarlarla bile çok daha uyumlu
    VPN de Docker yüzünden çoğu kez bozuldu ya da Docker'ı bozdu. Podman'ın ağ tarafında içeride nasıl çalıştığını pek bilmiyorum ama en azından diğer işleri engellemeyecek şekilde iyi tasarlanmış gibi görünüyor. Docker için bunu asla söyleyemem

    • Bana göre asıl kilit özellik Buildah. Docker ile de iyi çalışabilir ama Podman'la aynı ailedeki araçlara daha yakın
      Dockerfile'ın tamamen çöp olduğunu düşünüyorum. Mevcut diller fazlasıyla yeterliyken “canı sıkılmış geliştiricilerin” yeni bir DSL ya da programlama dili oluşturmasından gerçekten nefret ediyorum. Özellikle YAML olunca daha da öyle; bu örnekte YAML değil ama Dockerfile, bu işi neden bırakmamız gerektiğini gösteren harika bir örnek
      Buildah'a bud olmadan bakınca nedeni ortaya çıkıyor. Kullanım senaryosu standart yoldan azıcık saptığında bile sinir bozucu, özensiz bir DSL yerine Bash, Fish ya da istediğiniz herhangi bir şeyi kullanabiliyorsunuz
      Bu kötü karar Docker ekosisteminin tamamına yayılıyor. DCS ve onun hep yarım kalan alternatifleri de örnek. Cosign gibi yerleşik bir imzalama protokolü kullanmak yerine, otomasyonu zor ve özellikle anahtar rotasyonu zahmetli olan karmaşık bir sistem yapmak istediler
    • Podman ücretsiz. Docker da ücretsiz ama Docker Desktop olmadan Docker kurmak zahmetli
    • Docker ve KVM sanal makinelerini bridge ile hâlâ çalıştırıyorum; kâbus olmadan gayet iyi çalışıyor. Biraz tuhaf

  • Podman'ın daha yaygın kullanılmasına sevindim. Çok fazla araç, kullanıcının sudo docker grubunu eklediğini varsayarak yapılmış; bu yüzden root erişimini gelişigüzel vermeyen türden güvenliği önemseyen Docker kurulumlarında bozuluyor

    • Sunucusuz ve container gibi ileri teknoloji geleceklerin sonunda her şeyi root olarak çalıştırma temeli üzerine kurulmuş olması her zaman komik geliyor

  • Sertifikalı bir RHEL mühendisi olarak Podman’ı birkaç yıldır kullanıyorum.
    Açıkçası kişisel konteyner kullanımı için oldukça hoşuma gidiyor. Ancak iş yerinde geliştiricilere hâlâ Docker sunuyoruz. Şimdiye kadar geliştiricilere docker compose’un sadeliğine denk bir şey sunmanın bir yolunu bulamamıştık.
    Konteyner imajları oluştururken CI pipeline’larında buildah da kullanıyoruz, ancak geliştirici son kullanıcı açısından docker compose hâlâ baskın.

  • https://www.techrepublic.com/article/how-to-fix-the-docker-a...
    Bu sorun yüzünden neredeyse yakalanıyordum.

    • Docker, varsayılan yapılandırma ve kurulumla bile iptables’a müdahale ediyor. Özellikle daha yeni nftables’ı kullanmak istediğimde bu hep baş ağrısı oldu.
    • Docker’ın güvenli olmayan varsayılan tercihleri yüzünden, yalnızca VPN üzerinden kullanılmak üzere tasarlanmış bir GitHub projesine ait özel self-hosted konteynerlerimden birine kripto para madencisi girdi. Hâlâ sinir bozucu.
    • Ağ sorunlarına gelecek olursak, iç içe geçmiş bir yapılandırmada ağ aygıtları için bellek tükenip sistemi yeniden başlatmayı gerektiren büyük bir sorun yaşamıştım. Bu olmasaydı harika bir lxc alternatifi olabilirdi; yazık oldu.

  • Red Hat’in Docker’a alternatif geliştirmeye neden yatırım yaptığını hâlâ tam olarak bilmiyorum, ama ortaya çıkan sonucu gerçekten beğeniyorum
    Podman, Docker’ın yaptığı neredeyse her şeyi yaparken pod gibi ek özellikler sunuyor ya da daemon’sız konteyner oluşturma süreci gibi çoğu zaman yaklaşım olarak daha iyi seçenekler getiriyor
    Sıradan geliştiriciler için en büyük sorun muhtemelen Docker compose olacaktır; basit bir compose dosyası kullanıyorsanız Docker compose belirtimiyle uyumlu olmaya çalışan podman-compose betiği var
    docker-compose’un backend’i olarak Podman kullanmanın bir yolu da var [1]. Genel olarak 2024’te bir Linux makinede Docker kullanmak için bir neden göremiyorum. macOS veya Windows’ta Podman’ın nasıl olduğunu ise pek bilmiyorum
    [1] https://www.redhat.com/sysadmin/podman-docker-compose

    • Red Hat aslında geçmişte ortaya çıkan çeşitli sorunları, örneğin belirli kullanım senaryolarındaki systemd uyumluluğu sorununu çözmek için Docker ile iş birliği yapmaya çalıştı, ama pek sonuç alamadı
      Buna Docker’ın eskiden de şimdi de alışılmadık derecede çok güvenlik sorunu olması ve Docker tarzı konteynerlerin ve imajların geliştiriciler arasında çok yaygın kullanılması eklenince, RHEL’in değerleri ve yaklaşımıyla daha uyumlu kendi uygulamasını geliştirmek zorunda kaldı
      Örneğin Docker rootless çalışabilse de hâlâ bunu varsayılan olarak kullanmıyor. Sertleştirilmiş ortamlarda docker kullanıcı grubu da, grup olmadan çalıştırma yöntemi de güvenlik açısından birçok kullanım senaryosunda kabul edilmesi zor şeyler
      İlk dönem Docker, ayrıcalıksız konteynerlerin en azından asgari düzeyde yalıtılmasını sağlama konusunda fazla isteksizdi ve sorunlar bilindikten sonra bile düzeltmesi uzun sürdü. Güvenlik duvarı ve ağ kurallarıyla, SELinux ile etkileşim biçimi de çok sorunlu. Güvenliği önemseyen, özel Linux sistem yöneticileri olan şirketlerde Docker yasağının nadir olmamasının nedeni bu
    • Windows’ta Podman kullanıyorum. Windows’taki Docker bitmek bilmeyen bir sinir ve hayal kırıklığı silsilesiydi
      Daha en baştan tüm belgeler agresif biçimde kullanıcı dostu olmayan bir GUI kurulumuna yönlendiriyor. Açılışta ağır süreçler başlatıyor, nedense bir bulut hesabına kaydolmayı istiyor ve sözde açık kaynak ürünü işte kullanmamanız gerektiği konusunda bir de dırdır ediyor
      “Yalnızca komut satırı Docker” kurmaya yönelik desteklenmeyen alternatif gereksiz derecede karmaşıktı ve en son denediğimde çoğu WSL VM varsayılan hâliyle bunu desteklemiyordu bile
      Buna karşılık Podman için winget install podman yeterli ve sizi rahatsız etmiyor. Yalnızca bir konteyner çalıştırmanız gerektiğinde Podman VM’i başlatıyorsunuz; gerekmediğinde sistem eskisi gibi davranıyor
      Bir compose dosyasıyla bir şey çalıştırmanız gerekiyorsa podman-compose var. Alışılmadık ayarları ele alamayabilir ama benim kullanımımda iyi çalıştı
      Podman’ın düzgün yapamadığı şey aşağı yukarı VS Code entegrasyonu; ama Windows’ta Docker’ı uslu uslu çalışır hâle getirmenin zahmeti, birkaç VS Code kısayolunu kaybetmekten çok daha sinir bozucu olduğundan bu sorun olmuyor
      Windows’ta konteynerler için varsayılan çözüm olarak Podman’ı öneririm. Docker kullanmak için nedenler ancak şirketinizin ücretini ödemesi ya da karmaşık bir compose yapılandırmanız olması gibi durumlar; öyleyse de Kubernetes’e geçmeye değebilir
    • Red Hat’in yatırım yapmasının nedeni Docker’ın Linux’ta işlerin nasıl yürüdüğünden çok kopuk olması
      Sistemi bozan şeyler yapıyor, rootless konusunda yıllarca zorlandı ve tedarikçiye bağımlılık da cabası
      Podman açık, standartlara uyan ve Kubernetes ile de iyi örtüşen bir araç. Kolay konteyner pazarına önce çıktığı için geliştiricilerin Docker’a harcadığı emek akıl almaz derecede fazlaydı
    • “Linux’ta Docker kullanmak için neden yok” bakış açısının çoğunluk görüşü hâline gelmemesini umarım. Docker, RedHat/IBM değil
      Docker ortadan kalkarsa RedHat kendi kurumsal gündemini daha güçlü bir elle dayatabilir
      Podman’ın avantajları var, ama RedHat’in Docker’daki her şeyi ikame etmeye çalıştığı süreçte iyi yürütülmemiş kısımlar da var
      RedHat’in konteyner alanına yaklaşım geçmişine bakınca, katkı yapıp iyileştirebileceği birçok projede zaman ve emek harcamış, hatta boşa harcamış olduğu yanlar var
      RedHat müşterileri için doğru olanı yapma gündemine sahip bir şirket değil; bu yüzden büyük resimde ne istediğinizi düşünmek gerekiyor
    • macOS’ta Podman kullanıyorum. Genel olarak deneyimim Docker’dan daha iyi oldu; özellikle eski macOS sürümlerini destekleme konusunda
      macOS için Podman’ın tek büyük eksiği, konteynerlerden host ağını kullanamamak. Ama konteynerlerden host ağını kullanmak istemek nadir görülen bir durum
      Yine de konteyner içinde ağla ilgili deneyler yaparken host ile aynı host adını ve IP adresini korumak istiyorsanız bunu aklınızda bulundurmalısınız. Buna rağmen bu sınırlamayı aşarak kullanıyorum

  • Güvenliği önceleyen yaklaşım ve kararlar iyi görünüyor. Varsayılan ayarlarından itibaren güvenli olması ve docker compose ile de çalışması hoşuma gidiyor
    Yine de Podman yeterince popüler olursa bir gün komutlar ve yml formatında kendi yoluna gidip gitmeyeceğini merak ediyorum. Şu anda Docker ve Docker compose dosya formatına yaslanan bir araç gibi görünüyor
    Podman’da bir Swarm alternatifi olsa iyi olurdu. Şu anda orkestrasyon eksikliği yüzünden Kubernetes koltuk değneği gibi kullanılıyor hissi veriyor
    Güvenliği iyi düşünen bir ekip, varsayılanlarından itibaren güvenli olmayan Kubernetes’i doktora konusu gibi didiklemek zorunda kalmadan, küçük ölçekte konteynerleri makul ve basit biçimde çalıştırmanın bir yolunu geliştirebilir gibi geliyor. Bunu yaparken Docker compose formatıyla uyumluluğu da koruyabilir

  • Rootless konteynerlerin ve yalıtılmış ad alanlarının önemli bir güvenlik özelliği olduğuna katılıyorum. Ancak bu Docker rootless ile de mümkün ve karmaşık değil. Sadece o şekilde yapılandırmak yeterli
    Mevcut en iyi uygulamaların tümünü uygulayarak Mastodon'u docker rootless ile kurma hakkında bir yazı yazmıştım [1]
    Docker kullanmaya devam etmenin avantajı daha erişilebilir olması. Daha fazla topluluk ve blog var, docker compose yapılandırmaları yaygın ve çevrenizde kullanmayı bilen kişi sayısı da daha fazla
    Sonuçta Podman da Docker da ana makinenin yalıtılmış ad alanlarında süreç çalıştırıyor
    [1]: https://du.nkel.dev/blog/2023-12-12_mastodon-docker-rootless...

  • Yanlış anlaşılmasın. Podman harika ve son zamanlarda Docker yerine onu kullanıyorum; ama başta basit bir Docker ikamesi sanıp kullanmaya başlayınca UID/GID eşlemeleri, SELinux ilkeleri, eksik DNS ayarları gibi konularda epey canım yandı
    Sorunu düzeltmek için system migrate çalıştırıp tüm yapılandırmayı bozduğum da birkaç kez oldu. Güvenlik ACL'leri, ID eşlemeleri ve etiketlerle ilgili ayrı bir düzeni var
    Ev klasörü altında chmod -R yaparsanız muhtemelen tüm konteynerleriniz ölebilir
    Sonuçtan memnunum ama Docker gibi “sadece çalışan” bir çözüm olmaktan uzaktı. Ben kullanmaya başladıktan sonra muhtemelen epey iyileşmiştir

    • Bu yıl kullanmaya başladım; amacım birden çok geliştirme ortamını yalıtmak ve npm'in geliştirme makinesinin tamamına kolayca erişmesini engellemekti
      Benim açımdan Docker'dan daha kolaydı. Görünüşe göre yukarıda yaşanan duruma kıyasla şimdi iyileşmiş

  • Büyük resme bakınca Podman, eski Linux gibi vazgeçilmez bir varlık hissi veriyor
    Çok az kişi kullansa bile, sırf varlığıyla çok daha büyük kapalı kaynak yazılım kardeşlerinin korkunç şeyler yapmasını engelliyor
    Burada “eski Linux” derken Linux'un daha az önemli hale geldiğini kastetmiyorum; aksine bugün çok daha vazgeçilmez ve merkezi hale geldiği için söylüyorum

    • “Çok daha büyük kapalı kaynak yazılım kardeşleri” ile Docker kastediliyorsa bu biraz ironik. Çünkü RedHat ve IBM'in açık kaynak alanında yaptığı kötü şeyler de çok fazla