Kubernetes ve Docker Swarm Karşılaştırması: Container Orkestrasyonu için En İyi Seçenek

Container orkestrasyonu, modern yazılım geliştirme ve dağıtımı için kritik bir süreçtir. Kubernetes ve Docker Swarm, bu alanda en popüler iki çözümdür. Bu makalede, her iki çözümün özellikleri, avantajları ve dezavantajları karşılaştırmalı olarak incelenecektir.

Kubernetes

Kubernetes, açık kaynaklı bir container orkestrasyon aracıdır. Google tarafından geliştirilmiş ve Cloud Native Computing Foundation (CNCF) tarafından yönetilmektedir. Kubernetes, konteynerlerin otomatik dağıtımı, ölçeklenmesi ve yönetimi için tasarlanmıştır.

Kubernetes'in ana özellikleri arasında self-healing (kendini iyileştirme), resource management (kaynak yönetimi) ve scaling (ölçekleme) bulunur. Ayrıca, çoklu bulut desteği sunar ve güvenlik için Network Policies gibi özellikleri içerir.

Docker Swarm

Docker Swarm, Docker tarafından geliştirilmiş bir container orkestrasyon aracıdır. Docker Swarm, konteynerlerin kolayca dağıtımı ve yönetimi için tasarlanmıştır.

Docker Swarm'in ana özellikleri arasında basit kurulum, kolay yönetim ve hızlı dağıtım bulunur. Ayrıca, Docker Compose ile entegre çalışır ve güvenlik için swarm mode gibi özellikleri içerir.

Karşılaştırma

Kubernetes ve Docker Swarm arasındaki ana farklar şunlardır:

• Komplekslik: Kubernetes daha kompleks bir sistemdir ve daha fazla özellik sunar. Docker Swarm daha basit ve kolayca kurulabilen bir sistemdir.
• Ölçeklenebilirlik: Kubernetes daha büyük ölçekli sistemler için tasarlanmıştır ve daha iyiyimleştirme özelliğine sahiptir. Docker Swarm daha küçük ölçekli sistemler için daha uygundur.
• Güvenlik: Her iki çözüm de güvenlik özellikleri sunar, ancak Kubernetes daha gelişmiş güvenlik özellikleri sunar.

Sonuç olarak, Kubernetes ve Docker Swarm arasındaki seçim, proje gereksinimlerine ve ekip expérienceine bağlıdır. Kubernetes, daha kompleks ve büyük ölçekli sistemler için daha uygun bir seçenektir. Docker Swarm, daha basit ve küçük ölçekli sistemler için daha uygun bir seçenektir.

Konteyner Orkestrasyonu: Kubernetes ve Docker Swarm Karşılaştırması

Konteynerleştirme teknolojileri, modern yazılım geliştirme ve dağıtımı için temel bir bileşen haline geldi. Kubernetes ve Docker Swarm, konteyner orkestrasyonu için en popüler iki çerçeve olarak öne çıkıyor. Bu makalede, her iki çerçevenin özellikleri, avantajları ve değerlendirmeleri karşılaştırılacaktır.

Kubernetes

Kubernetes, Google tarafından geliştirilen ve Cloud Native Computing Foundation (CNCF) tarafından yönetilen bir açık kaynaklı konteyner orkestrasyon aracıdır. Kubernetes, konteynerlerin otomatik dağıtımı, ölçeklendirilmesi ve yönetimi için güçlü bir platform sağlar.

Kubernetes Avantajları

Kubernetes'in bazı önemli avantajları şunlardır:

• Genişletilebilirlik: Kubernetes, büyük ölçekli dağıtımları destekler ve binlerce düğümü yönetebilir.
• Esneklik: Kubernetes, farklı konteyner runtime环境lerini destekler ve çeşitli bulut sağlayıcıları ile entegre edilebilir.
• Güvenlik: Kubernetes, güçlü güvenlik özellikleri sunar, such as kimlik doğrulama ve yetkilendirme.

Docker Swarm

Docker Swarm, Docker tarafından geliştirilen bir konteyner orkestrasyon aracıdır. Docker Swarm, konteynerlerin kolayca dağıtılması ve yönetilmesi için bir platform sağlar.

Docker Swarm Avantajları

Docker Swarm'in bazı önemli avantajları şunlardır:

• Kolay Kullanım: Docker Swarm, kullanıcı dostu bir arayüz sunar ve kolayca kurulabilir.
• Hızlı Dağıtım: Docker Swarm, hızlı konteyner dağıtımı sağlar ve uygulama teslimatını hızlandırır.
• Entegrasyon: Docker Swarm, Docker ekosistemi ile sıkıca entegre edilir ve Docker araçlarını kullanabilir.

Her iki çerçevenin de güçlü yönleri ve zayıf yönleri vardır. Kubernetes, büyük ölçekli dağıtımlar için daha uygunken, Docker Swarm, küçük ve orta ölçekli projeler için daha uygundur. Seçim, proje gereksinimlerine ve ekip deneyimine bağlı olarak yapılmalıdır.

Kubernetes ve Docker Swarm: 2026'da Konteyner Orkestrasyonu için En İyi Seçenek

Konteyner orkestrasyonu, modern yazılım geliştirme ve dağıtımı için kritik bir bileşendir. Kubernetes ve Docker Swarm, bu alanda iki popüler seçenek olarak karşımıza çıkıyor. Bu makalede, her iki teknolojinin özellikleri, avantajları ve dezavantajları hakkında derinlemesine bir analiz yapılacak.

Kubernetes

Kubernetes, açık kaynaklı bir konteyner orkestrasyon platformudur. Google tarafından geliştirilen ve Cloud Native Computing Foundation (CNCF) tarafından yönetilen Kubernetes, geniş bir topluluk tarafından desteklenmektedir. Kubernetes, yüksek düzeyde esneklik ve ölçeklenebilirlik sunar, ancak öğrenme eğrisi biraz dik olabilir.

Kubernetes'in bazı temel özellikleri şunlardır:

• Pod'lar: Kubernetes'te en küçük çalıştırma birimi pod'dur. Bir pod, bir veya daha fazla konteynirden oluşur.
• Deployments: Deployments, pod'ların dağıtımını ve yönetimini sağlar.
• Services: Services, pod'ların dışarıya açılmasını ve trafiğin yönlendirilmesini sağlar.

Docker Swarm

Docker Swarm, Docker tarafından geliştirilen bir konteyner orkestrasyon aracıdır. Docker Swarm, Docker konteynerlerini kolayca yönetmenizi sağlar ve docker-compose gibi araçlarla entegre çalışır.

Docker Swarm'in bazı temel özellikleri şunlardır:

• Node'lar: Docker Swarm'de, her bir makine bir node olarak kabul edilir.
• Services: Docker Swarm'de, services konteynerlerin dağıtımını ve yönetimini sağlar.
• Stacks: Docker Swarm'de, stacks birden fazla service'in bir araya gelerek oluşturduğu bir yapıdır.

Karşılaştırma

Kubernetes ve Docker Swarm arasındaki seçim, projenizin ihtiyaçlarına ve ekibinizin uzmanlığına bağlıdır. Kubernetes, daha büyük ve daha karmaşık sistemler için daha uygunken, Docker Swarm, daha küçük ve daha basit sistemler için daha uygun olabilir.

Ölçeklenebilirlik, esneklik ve güvenlik gibi faktörleri dikkate alındığında, her iki teknolojinin de avantajları ve dezavantajları vardır. Kubernetes, daha geniş bir topluluk tarafından desteklenmektedir ve daha fazla kaynak mevcuttur, ancak öğrenme eğrisi daha dik olabilir. Docker Swarm, daha basit ve daha leicht bir seçenek olabilir, ancak daha az esneklik sunar.

Sonuç olarak, Kubernetes ve Docker Swarm arasındaki seçim, projenizin özel ihtiyaçlarına bağlıdır. Her iki teknolojinin de avantajları ve dezavantajları vardır ve seçim, ekibinizin uzmanlığına ve projenizin karmaşıklığına bağlıdır.

Kubernetes ve Docker Swarm: 2026'da Konteyner Orkestrasyonu için En İyi Seçenek

2026 yılında, konteyner orkestrasyonu için Kubernetes ve Docker Swarm gibi araçlar arasında seçim yapmak, geliştiriciler ve sistem yöneticileri için kritik bir karar haline geldi. Bu rehberde, her iki aracın özellikleri, avantajları ve dezavantajları hakkında derinlemesine bilgi vereceğiz.

Kubernetes

Kubernetes, açık kaynaklı bir konteyner orkestrasyon aracıdır. Google tarafından geliştirilen ve Cloud Native Computing Foundation (CNCF) tarafından yönetilen Kubernetes, geniş bir topluluk ve güçlü bir destek altyapısına sahiptir. Kubernetes, konteynerlerin dağıtılması, ölçeklendirilmesi ve yönetilmesi için güçlü bir platform sağlar.

Kubernetes Avantajları

Kubernetes'in bazı avantajları şunlardır:

• Genişletilebilirlik: Kubernetes, büyük ölçekli dağıtımlar için idealdir.
• Esneklik: Kubernetes, çeşitli konteyner runtimeleri ve bulut sağlayıcıları ile uyumludur.
• Topluluk desteği: Kubernetes, güçlü bir topluluğa ve geniş bir ekosisteme sahiptir.

Docker Swarm

Docker Swarm, Docker tarafından geliştirilen bir konteyner orkestrasyon aracıdır. Docker Swarm, konteynerlerin kolayca dağıtılması ve yönetilmesi için tasarlanmıştır. Docker Swarm, Docker CLI ile entegre çalışır ve konteynerlerin yönetilmesi için basit bir arayüz sağlar.

Docker Swarm Avantajları

Docker Swarm'in bazı avantajları şunlardır:

• Kolay kullanım: Docker Swarm, basit ve kullanıcı dostu bir arayüze sahiptir.
• Hızlı dağıtım: Docker Swarm, konteynerlerin hızlı dağıtılması için tasarlanmıştır.
• Entegrasyon: Docker Swarm, Docker CLI ile entegre çalışır.

2026 yılında, Kubernetes ve Docker Swarm arasında seçim yapmak, projelerin özgünlüğüne ve ihtiyaçlarına bağlıdır. Her iki araç da konteyner orkestrasyonu için güçlü seçenekler sunar, ancak Kubernetes, genişletilebilirlik ve esneklik açısından daha güçlüdür. Docker Swarm ise, kolay kullanım ve hızlı dağıtım açısından daha avantaja sahiptir.

Otomatik Docker Container Deployment: Ansible ile DevOps Otomasyonu Kılavuzu

Otomatik Docker Container Deployment: Ansible ile DevOps Otomasyonu

Docker ve DevOps ekosisteminin merkezinde yer alan otomasyon, modern yazılım geliştirme süreçlerini hızlandırır. Ancak, manuel Docker container dağıtımına zaman kaybetmeden, Ansible gibi orkestrasyon araçlarıyla bu süreci otomatikleştirmek, hem hata payını azaltır hem de tekrar tekrar aynı görevleri yapmaya gerek kalmaz. Bu kılavuzda, Docker konteynerlerini Ansible kullanarak nasıl otomatik dağıtabileceğinizi adım adım anlatacağım.

Amaç

DevOps Otomasyonunun Neden Kritik

Docker konteynerleri dağıtım süreçlerini standartlaştırırken, manuel müdahaleler her seferinde hata riskini artırır. Ansible ile Docker deployment sürecini otomatik hale getirerek;

• İkili dağıtım (binary deployment) süreçlerini hızlandırabilirsiniz.
• Konteyner güncellemelerini tek bir komutla yönetebilirsiniz.
• Çoklu sunuculara paralel otomatik dağıtım yapabilirsiniz.

Ön Koşullar

Aşağıdaki araçların veya bilgilerin hazır olduğundan emin olun:

• Linux/Unix tabanlı sistem (örnek: Ubuntu 22.04)
• Docker kurulmuş olmalıdır (sudo apt install docker.io)
• Ansible kurulmuş olmalıdır (sudo apt install ansible)
• YAML ve Dockerfile temeli bilgisi

Adım Adım Anlatım

Adım 1: Dockerfile Oluşturma

Öncelikle bir Docker image oluşturmak için Dockerfile yaratalım. Aşağıdaki örnekte, Python uygulaması içeren bir konteyner image’ı tanımladık:

FROM python:3.9-slim  
WORKDIR /app  
COPY . /app  
RUN pip install -r requirements.txt  
CMD ["python", "app.py"]  

Adım 2: Ansible Playbook Oluşturun

Ansible, playbook.yml dosyası üzerinden görevleri tanımlar. Aşağıdaki playbook, Dockerfile’ı derler, image’ı çalıştırır ve konteyneri başlatır:

- hosts: all  
  become: yes  
  tasks:  
    - name: Dockerfile'dan image derle  
      docker_image:  
        path: ./docker-repo  
        name: my-python-app  
        source: build  
    - name: Konteyner başlat  
      docker_container:  
        name: my-container  
        image: my-python-app:latest  
        state: started  
        ports:  
          - "5000:5000"  

Adım 3: Inventory Dosyası Ayarlayın

Ansible, inventory dosyası üzerinden hedef sunucuları tanımlar. Örneğin, hosts dosyanızda:

[docker_servers]  
192.168.1.10  
192.168.1.11  

Adım 4: Playbook'u Çalıştırın

Aşağıdaki komutla playbook’u çalıştırın:

ansible-playbook -i hosts playbook.yml  

Bu komut, listedeki tüm sunucularda Docker konteynerlerini otomatik olarak dağıtır.

Geliştirme Tavsiyeleri

Ekstra: CI/CD Entegrasyonu

Bu playbook’u Github Actions veya Jenkins ile entegre ederek, her kod değişikliğinde otomatik deployment sağlayabilirsiniz.

Sonuç

Bu kılavuzda, Ansible ile Docker konteyner dağıtımını nasıl otomatikleştireceğinizi öğrendik. Docker ve Ansible’nin birleşimi, DevOps süreçlerinde hem hız kazandırır hem de hata payını minimize eder. Bu yöntemi bir sonraki adım olarak, kubernetes veya OpenShift gibi container orchestrators ile genişletebilirsiniz. Unutmayın: Otomasyon, sadece kodlama değil, yazılım yaşam döngüsünün her aşamasını dönüştürür.

Referanslar

• Docker Documentation
• Ansible Documentation

Docker ile Lokal Geliştirmede Gelişmiş Hızlandırma: BuildKit, Cache ve Multi-Stage Build Rehberi

Docker ile “Neden Bu Kadar Yavaş?” Sorununu Kökten Çözmek

Docker kullanarak geliştirme yapmak artık standart hâline geldi; ancak birçok ekip, konteyner imajı alırken “her seferinde her şeyi baştan indiriyor” hissiyle boğuşuyor. Özellikle Node.js, Python, Go veya Java tabanlı projelerde bağımlılıkların kurulumu ve katmanların tekrar tekrar oluşması, CI süreçlerini ve yerel geliştirmeyi ciddi biçimde yavaşlatabiliyor. Bu yazıda, Docker’ın modern derleme altyapısı olan BuildKit ile daha hızlı build alma, doğru cache stratejisi kurma ve multi-stage derlemelerle daha küçük imaj üretme konusunu ileri seviye ama uygulanabilir bir şekilde ele alacağım.

1) BuildKit Nedir ve Neden Önemli?

BuildKit, Docker build sürecini daha akıllı hâle getiren yeni nesil derleme motorudur. Paralel adım çalıştırma, gelişmiş cache yönetimi ve “secret” gibi güvenlik odaklı özellikler sunar. En önemli etkisi, doğru yazılmış bir Dockerfile ile build sürelerini gözle görülür şekilde azaltmasıdır. Ayrıca BuildKit, “cache’i dışarı aktar, başka makinede kullan” gibi senaryolara da kapı açar; bu da özellikle CI/CD ortamlarında altın değerindedir.

BuildKit’i etkinleştirmek için genellikle ekstra kurulum gerekmez. Terminalde tek seferlik şu şekilde kullanabilirsiniz: DOCKER_BUILDKIT=1 docker build .. Docker Desktop kullananlarda çoğu zaman varsayılan olarak açıktır. BuildKit ile birlikte buildx komutu da devreye girer ve cache ihracı/ithali gibi gelişmiş işlevler pratikleşir.

2) Dockerfile’da Katman Mantığını Doğru Kullanmak

Docker build hızının temelinde katman (layer) cache’i vardır. Basit kural şudur: Sık değişen dosyaları (uygulama kodu) daha sona, nadir değişenleri (bağımlılık tanımları) daha başa koyun. Örneğin Node.js için package.json ve package-lock.json dosyaları bağımlılık değişmediği sürece sabit kalır. Bu dosyaları önce kopyalayıp bağımlılıkları kurarsanız, uygulama kodu değişse bile bağımlılık katmanı cache’ten gelir.

Örnek mantık: Önce COPY package*.json, sonra RUN npm ci, en son COPY . .. Python tarafında benzer şekilde requirements.txt önce kopyalanır, pip install sonra çalışır. Bu yaklaşım “her değişiklikte yeniden bağımlılık kurma” hatasını ortadan kaldırır.

3) BuildKit Cache Mount ile Bağımlılık Kurulumunu Hızlandırmak

BuildKit’in en güçlü taraflarından biri, belirli dizinleri build sırasında cache olarak bağlayabilmesidir. Böylece paket yöneticileri (npm, pip, apt) her seferinde internetten indirmek yerine yerel/BuildKit cache’inden yararlanır. Bu özellik klasik layer cache’inden farklıdır; layer bozulsa bile cache mount sayesinde indirme havuzu korunabilir.

Örneğin Debian/Ubuntu tabanlı imajlarda apt için: RUN --mount=type=cache,target=/var/cache/apt gibi bir yaklaşım mümkündür. Node.js için npm cache dizinini, Python için pip cache dizinini cache mount ile tanımlamak özellikle CI’da büyük hız kazandırır. Buradaki kritik nokta, bu yöntemin BuildKit gerektirmesidir; yani eski “docker build” davranışına göre daha moderndir.

4) Multi-Stage Build ile Küçük ve Güvenli İmaj

Performans sadece build süresi değildir; imaj boyutu ve saldırı yüzeyi de önemlidir. Multi-stage build yaklaşımıyla, derleme için gereken araçları (ör. derleyiciler, dev bağımlılıklar) bir “builder” aşamasında tutup, çalıştırma aşamasına sadece gerekli çıktıları taşıyabilirsiniz. Bu sayede imaj küçülür, deploy hızlanır, container açılış süreleri kısalır ve olası güvenlik açıkları azalır.

Örneğin Go projelerinde ilk aşamada binary derlenir, ikinci aşamada ise “scratch” veya minimal bir base imaj üzerinde yalnızca binary çalıştırılır. Node.js tarafında ise build aşamasında webpack/tsc gibi araçlar kullanılırken, runtime aşamasında sadece derlenmiş çıktı ve üretim bağımlılıkları tutulur. Bu ayrım, üretim ortamında “devDependencies” taşıma hatasını da engeller.

5) .dockerignore: Sessiz Kahraman

Bir başka sık yapılan hata, build context’in gereksiz şişmesidir. Docker, build ederken bulunduğunuz dizini (context) daemon’a gönderir. Eğer node_modules, dist, log dosyaları, test çıktıları gibi klasörler context’e giriyorsa hem gönderim süresi uzar hem de cache beklenmedik şekilde bozulur. Burada .dockerignore dosyası devreye girer.

Temel öneri: node_modules, .git, dist, coverage, *.log gibi öğeleri .dockerignore ile hariç tutun. Bu, özellikle monorepo yapılarda ve büyük projelerde build hızını dramatik biçimde etkiler.

6) CI/CD İçin Cache İhracı: buildx ile Bir Üst Seviye

Yerelde cache iyi çalışsa bile CI ortamında “her şey baştan” problemi devam edebilir. BuildKit ve buildx ile cache’i registry’ye veya bir dosya deposuna dışa aktarabilirsiniz. Böylece farklı CI koşucularında bile cache yeniden kullanılabilir. Mantık olarak, bir build’in ürettiği cache metadata’sı sonraki build’e beslenir ve özellikle bağımlılık kurulumları ile derleme adımları hızlanır.

Bu yaklaşım, sık deploy eden ekiplerde maliyeti de azaltır: daha kısa çalışan pipeline, daha az kaynak tüketimi demektir. Buradaki püf nokta; cache stratejisini proje yapısına göre doğru kurgulamak ve Dockerfile katmanlarını mantıklı sıralamaktır. Aksi hâlde cache ihracı yapsanız bile, küçük bir değişiklik her şeyi geçersiz kılabilir.

Sonuç: Hız, Doğru Alışkanlıkların Yan Ürünü

Docker build sürelerini kısaltmak için tek bir “sihirli komut” yok; ama BuildKit’i etkin kullanmak, Dockerfile katmanlarını doğru düzenlemek, cache mount ile paket indirimi tekrarını azaltmak ve multi-stage build ile imajı inceltmek birlikte güçlü bir etki yaratır. Eğer her commit’te dakikalarca build bekliyorsanız, sorunun kaynağı genellikle yanlış katmanlama veya şişkin build context’tir. Bugün küçük bir Dockerfile refaktörü yaparak hem yerelde hem CI’da daha akıcı bir geliştirme deneyimi yakalayabilirsiniz.

Docker + Podman ile Rootless Container Kurulumu: Güvenli ve Güncel Bir Geliştirici Rehberi

Rootless container nedir, neden gündemde?

Container dünyası uzun süre “Docker kur, daemon root çalışsın, bitti” kolaylığıyla yürüdü. Ancak güvenlik tarafında bu yaklaşımın maliyeti var: root yetkisiyle çalışan bir servis, yanlış yapılandırma veya zafiyet durumunda sistemin tamamını riske atabilir. Rootless container yaklaşımı ise container’ları ve ilgili süreçleri root olmayan kullanıcıyla çalıştırarak saldırı yüzeyini ciddi biçimde küçültür. Son yıllarda Podman’ın popülerleşmesi ve Docker’ın rootless modunun olgunlaşmasıyla bu yaklaşım masaüstünde ve sunucuda daha ulaşılabilir hale geldi.

Bu yazıda, Linux üzerinde hem Docker Rootless hem de Podman ile rootless çalışmayı kurup günlük kullanım için pratik hale getireceğiz. Hedefimiz “kurulum bitti” demek değil; ağ, port, volume ve servis yönetimi gibi gerçek hayatta takılınan noktaları da ele almak.

Ön koşullar ve temel kavramlar

Rootless çalışmanın temelinde Linux’un user namespace kabiliyeti yatar. Kısaca, container içindeki “root” kullanıcı kimliği, host üzerinde normal bir kullanıcıya eşlenir. Bu sayede container içi root yetkileri host’a taşınmaz. Rootless kurulumlarda ayrıca genellikle slirp4netns (kullanıcı modunda ağ), fuse-overlayfs (overlay dosya sistemi) ve uid/gid map yapılandırması gibi parçalar devreye girer.

Kontrol etmeniz gereken ilk şey, sistemde yeterli kullanıcı ID aralığının tanımlı olmasıdır. Aşağıdaki dosyalarda kullanıcı adınıza ait satırların olması idealdir: /etc/subuid ve /etc/subgid. Örnek bir satır şu şekildedir: kullanici:100000:65536. Bu, rootless container’ların içerideki kullanıcılarını host üzerinde izole bir ID aralığına eşlemeyi sağlar.

Seçenek 1: Docker Rootless kurulumu ve kullanımı

Docker’ı rootless kullanmak istiyorsanız, dağıtımınızın paketleriyle Docker Engine kurulu olmalı ve ardından rootless “setup tool” çalıştırılmalıdır. Kurulum mantığı şudur: root yetkisiyle çalışan sistem servisi yerine, kullanıcı oturumunuz altında çalışan bir Docker daemon devreye girer. Bu sayede docker komutları da root olmadan çalışır.

Kurulumdan sonra iki kritik nokta vardır: Birincisi, Docker istemcisinin hangi sockete bağlanacağını bilmesi. Rootless modda genellikle socket yolu kullanıcı dizini altındadır. Bu yüzden DOCKER_HOST değişkenini ayarlamak gerekebilir. İkincisi, rootless ağ sürücüsü nedeniyle bazı port yönlendirmelerinde farklı davranışlar görülebilir.

Günlük kullanımda en çok karşılaşılan konu 80/443 gibi düşük portlardır. Root olmayan bir süreç bu portları doğrudan açamaz. Çözüm olarak 8080/8443 gibi portlar kullanılabilir veya sistemde düşük portlara izin veren bir ayar yapılabilir. Alternatif olarak ters proxy (Nginx/Caddy) root yetkisiyle değil, yetkili bir servis olarak konumlandırılıp backend’e yüksek porttan bağlanabilir.

Volume tarafında ise rootless modda dosya izinleri daha görünür hale gelir. Host’taki dosya sahipliği, container içi kullanıcı eşleşmesine göre yorumlanır. Eğer “container yazamıyor” gibi bir durum yaşıyorsanız, çoğu zaman mesele uygulamanın container içindeki kullanıcı UID’si ile host’taki dizin izinlerinin uyuşmamasıdır. Çözüm, uygulamayı uygun kullanıcıyla çalıştırmak veya host dizin sahipliğini/izinlerini düzenlemektir.

Seçenek 2: Podman ile daemon’suz rootless deneyim

Podman’ın en güçlü tarafı, daemon gerektirmeden çalışmasıdır. Rootless senaryoda bu avantaj daha da anlam kazanır: kullanıcı oturumunuz altında, her şey “normal bir süreç” gibi çalışır. Podman ayrıca Docker’a benzer bir CLI sunduğu için geçiş bariyeri düşüktür. Birçok komut birebir aynıdır; hatta isterseniz “docker” alışkanlıklarınızı sürdürmek için uyumluluk katmanları kullanabilirsiniz.

Podman ile rootless kullanımda ağ genellikle slirp4netns ile sağlanır. Bu, performans olarak kernel seviyesindeki bridge çözümlerinden bir miktar geride olabilir; ama masaüstü geliştirme, CI işleri ve çok sayıda servis çalıştırmayan senaryolarda gayet yeterlidir. Eğer daha ileri seviye ağ ihtiyaçlarınız varsa, Podman ekosisteminde farklı ağ sürücüleri ve sistem entegrasyon seçenekleri bulunur.

Podman’ın pratik bir artısı da podman generate systemd yaklaşımıdır. Rootless container’larınızı bir systemd user servisi gibi yönetebilir, oturum açınca otomatik başlatabilirsiniz. Bu sayede “terminali kapatınca container duruyor” derdi azalır. Bunun için kullanıcı systemd biriminin etkin olduğundan emin olmak ve “linger” benzeri ayarlarla oturum kapalıyken de çalıştırmak isteyebilirsiniz (sunucu senaryosunda faydalı).

Hangisini seçmeli? Karar matrisi

Docker Rootless, Docker ekosistemiyle sıkı bağlı ekipler için mantıklıdır. Compose dosyaları, üçüncü parti araçlar ve CI şablonları Docker merkezliyse, rootless moda geçiş görece kolay olur. Öte yandan rootless kısıtlarıyla uyumlu hale getirmek için port, volume ve ağ tarafında biraz disiplin gerekir.

Podman ise “daemon istemiyorum, kullanıcı oturumumda yalın çalışsın” diyenler için güçlü bir alternatiftir. Ayrıca systemd entegrasyonu ve rootless felsefesi daha doğal bir çizgide ilerler. Eğer yeni bir proje başlatıyor, yerel geliştirmede güvenliği varsayılan yapmak istiyorsanız Podman ciddi bir adaydır.

İleri seviye ipuçları: Güvenlik ve bakım

Rootless kullanıyorsanız yine de bazı iyi pratikleri uygulamak gerekir. Öncelikle container’larda minimum yetki yaklaşımını sürdürün: gereksiz capability’leri kapatın, “privileged” moddan kaçının. İkinci olarak imaj kaynağına dikkat edin; resmi veya güvenilir registry’lerden çekin ve imajları düzenli güncelleyin. Üçüncü olarak log ve veri dizinlerini kontrol altında tutun; kullanıcı dizini altında büyüyen loglar zamanla disk sorunlarına yol açabilir.

Son olarak, rootless container’lar her derde deva değildir. Örneğin çok düşük port gereksinimi, kernel modülleriyle etkileşim, özel ağ topolojileri veya yüksek performanslı network senaryolarında rootful kurulum daha uygun olabilir. Ancak modern geliştirme akışlarının büyük çoğunluğu için rootless yaklaşım, güvenlik-kullanışlılık dengesinde çok iyi bir noktaya oturur.

Özet: Rootless container, “güvenliği sonradan eklemek” yerine varsayılan yapmak isteyenler için güncel ve güçlü bir yaklaşım. Docker Rootless daha tanıdık bir ekosistem sunarken, Podman daha yalın ve daemon’suz bir deneyim vadediyor. İkisini de denedikten sonra kendi iş akışınıza en iyi uyanı seçmeniz, uzun vadede daha az sürpriz ve daha güvenli bir çalışma ortamı anlamına gelir.

Windows 11’de WSL2 ile Docker Desktop Olmadan Docker Kurulumu ve Performans Ayarları

Docker Desktop’sız bir Docker deneyimi mümkün mü?

Windows 11 üzerinde Docker kullanmanın en popüler yolu Docker Desktop kurmak. Ancak bazı kullanıcılar lisans koşulları, sistem kaynak tüketimi veya arka planda çalışan servisler nedeniyle daha hafif bir alternatif arıyor. İyi haber şu: WSL2 (Windows Subsystem for Linux) ile Docker Engine’i doğrudan Linux dağıtımı içinde kurup, Windows’ta da komut satırından rahatça kullanabilirsiniz. Bu yazıda, güncel bir yöntemle Docker Desktop olmadan kurulum, entegrasyon ve performans ayarlarını adım adım anlatıyorum.

Ön koşullar

Başlamadan önce şunlara ihtiyacınız var: Windows 11 (güncel), yönetici yetkisi, WSL2 ve bir Linux dağıtımı (Ubuntu 22.04/24.04 önerilir). Terminal kullanmayı bilmek kurulum süresini kısaltır. Bu yöntem, Docker konteynerlerini Linux çekirdeği üzerinde çalıştırdığı için hem uyumluluk hem de hız açısından genelde iyi sonuç verir.

1) WSL2 ve Ubuntu kurulumu (kısa yol)

Windows Terminal’i yönetici olarak açıp aşağıdaki komutu çalıştırın. Bu komut WSL’i etkinleştirir ve varsayılan olarak Ubuntu’yu kurar:

Komut: wsl --install

Kurulum bittiğinde bilgisayar yeniden başlatılabilir. Ardından Ubuntu ilk açılışta kullanıcı adı ve parola oluşturmanızı ister. WSL sürümünü kontrol etmek için:

wsl -l -v

Dağıtımınızın VERSION sütununda 2 yazmalıdır. Değilse şu komutla yükseltin:

wsl --set-version Ubuntu 2

2) Ubuntu içinde Docker Engine kurulumu

Ubuntu terminalinde önce sistem paketlerini güncelleyin:

sudo apt update && sudo apt upgrade -y

Ardından gerekli paketleri yükleyin:

sudo apt install -y ca-certificates curl gnupg

Docker’ın resmi deposunu eklemek için anahtar ve repo tanımını yapın (Ubuntu sürümüne uygun komutlar güncel yöntemdir):

sudo install -m 0755 -d /etc/apt/keyrings

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

sudo chmod a+r /etc/apt/keyrings/docker.gpg

echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo $VERSION_CODENAME) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

Şimdi Docker paketlerini kurun:

sudo apt update

sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

3) WSL2’de Docker servisini başlatma (systemd ayarı)

Windows 11’in güncel sürümlerinde WSL içinde systemd desteği bulunuyor. Docker’ın her açılışta sorunsuz başlaması için bu ayarı aktif etmek iyi olur. Ubuntu’da şu dosyayı düzenleyin:

sudo nano /etc/wsl.conf

İçine şunları ekleyin:

[boot]
systemd=true

Ardından Windows tarafında WSL’i kapatıp tekrar açın:

wsl --shutdown

Ubuntu’yu tekrar açtıktan sonra Docker servis durumunu kontrol edin:

sudo systemctl status docker

4) “sudo”suz Docker kullanımı

Her komutta sudo yazmamak için kullanıcıyı docker grubuna ekleyin:

sudo usermod -aG docker $USER

Oturumu kapatıp açın ya da WSL’i yeniden başlatın. Sonrasında test:

docker run --rm hello-world

5) Windows Terminal’den pratik kullanım

Bu kurulumda Docker komutlarını Ubuntu içinde çalıştırırsınız. Windows Terminal’de Ubuntu sekmesi açıp docker ps gibi komutları kullanmak yeterli. Ayrıca proje klasörünüz Windows dosya sistemindeyse (ör. C:\projeler), WSL’den /mnt/c/projeler yoluyla erişebilirsiniz. Ancak performans için kritik bir öneri var: sık I/O yapan projelerde (Node.js, PHP, büyük bağımlılık klasörleri) kodu mümkünse WSL dosya sisteminde tutmak (ör. ~/projects) daha hızlı olur.

6) Performans ve kaynak ayarları (.wslconfig)

WSL2, varsayılan olarak RAM’i dinamik yönetir; bazı senaryolarda fazla RAM tüketebilir. Windows kullanıcı klasörünüzde (ör. C:\Users\KullaniciAdiniz) .wslconfig dosyası oluşturup kaynak sınırı koyabilirsiniz. Örnek:

[wsl2]
memory=6GB
processors=4
swap=2GB

Değişiklikten sonra wsl --shutdown ile WSL’i yeniden başlatın. Bu ayarlar özellikle aynı anda IDE, tarayıcı ve birkaç konteyner çalıştırırken sistemi daha öngörülebilir hale getirir.

7) Artılar, eksiler ve ne zaman tercih edilmeli?

Artılar: Daha hafif kurulum, daha az arka plan servisi, Docker Desktop bağımlılığı olmadan çalışma, Linux tabanlı daha “doğal” Docker deneyimi.

Eksiler: Bazı GUI özellikleri (entegre panel, otomatik güncelleyici) yoktur; port yönlendirme ve dosya sistemine erişimde dikkat gerekir. Yine de CLI odaklı geliştiriciler için bu yöntem günlük kullanımda gayet konforlu ve verimlidir.

Sonuç olarak, Windows 11 + WSL2 ikilisiyle Docker Desktop kurmadan da güncel ve hızlı bir konteyner çalışma ortamı kurabilirsiniz. Kurulum bir kez tamamlandıktan sonra günlük iş akışı büyük ölçüde “Linux’ta Docker kullanmak” kadar akıcı hale gelir.

Windows 11’de WSL2 ile Docker Desktop Kullanmadan Docker Kurulumu ve İnce Ayar Rehberi

Docker Desktop olmadan neden Docker?

Windows 11 kullanırken Docker ile çalışmanın en popüler yolu Docker Desktop kurmak. Ancak kurumsal lisans kısıtları, kaynak tüketimi veya “arka planda sürekli servis” yaklaşımını sevmeme gibi sebeplerle daha hafif ve kontrol edilebilir bir seçenek arayanların sayısı artıyor. Bu yazıda, WSL2 üzerinde Docker Engine kurarak Docker Desktop olmadan konteyner çalıştırmayı adım adım anlatacağım. Ayrıca performans, ağ erişimi ve sık görülen hatalar için pratik ince ayarları da ekleyeceğim.

Ön koşullar

Bu rehber Windows 11 ve WSL2 mantığını temel alır. İhtiyacınız olanlar: Windows 11, yönetici yetkisi, WSL2 etkinleştirilmiş bir Linux dağıtımı (Ubuntu önerilir) ve PowerShell/Windows Terminal. WSL sürümünüzü kontrol etmek için PowerShell’de wsl -l -v komutunu kullanabilirsiniz. Dağıtımınızın “VERSION” değeri 2 değilse, wsl --set-version Ubuntu 2 ile dönüştürebilirsiniz.

1) WSL2 üzerinde Docker Engine kurulumu

Ubuntu’yu açın ve önce sistem paketlerini güncelleyin:

sudo apt update && sudo apt upgrade -y

Docker’ın resmi deposunu eklemek için gerekli paketleri kurun:

sudo apt install -y ca-certificates curl gnupg

Docker GPG anahtarını ekleyin ve depo kaydını oluşturun:

sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

echo \
"deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
$(. /etc/os-release && echo $VERSION_CODENAME) stable" | \
sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

Ardından Docker Engine ve temel bileşenleri kurun:

sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

2) Servis yönetimi: systemd ve Docker’ın başlatılması

Güncel WSL sürümlerinde systemd desteği mevcut. Etkinleştirirseniz Docker’ı normal Linux gibi servis olarak yönetebilirsiniz. Ubuntu içinde şu dosyayı düzenleyin:

sudo nano /etc/wsl.conf

İçine şunu ekleyin:

[boot]
systemd=true

Sonra Windows tarafında WSL’i yeniden başlatın (PowerShell):

wsl --shutdown

Ubuntu’yu tekrar açınca Docker servisini başlatın:

sudo systemctl enable --now docker

Kontrol:

docker version
docker info

3) sudo yazmadan Docker kullanmak (güvenli kullanım notuyla)

Sürekli sudo yazmak istemiyorsanız kullanıcıyı docker grubuna ekleyebilirsiniz:

sudo usermod -aG docker $USER

Oturumu kapatıp açın veya WSL’i yeniden başlatın. Not: Docker grubu pratik ama güçlü yetkilere sahiptir; paylaşımlı makinelerde dikkatli olun.

4) Hızlı test: nginx konteyneri çalıştırma

Kurulumun doğru olduğunu görmek için küçük bir test iyi olur:

docker run --rm -d --name web -p 8080:80 nginx:alpine

Ardından tarayıcıda http://localhost:8080 adresini açın. WSL2 ağ katmanı sayesinde port yönlendirme genellikle sorunsuz çalışır. İşiniz bitince durdurun:

docker stop web

5) İnce ayar: disk performansı ve proje konumu

WSL2 + Docker kullanımında en kritik konu dosya sistemi performansıdır. Projenizi Windows dosya sisteminde (ör. /mnt/c/...) tutup konteyner içinde bind mount yaparsanız, yoğun I/O işlemlerinde yavaşlık görebilirsiniz. Daha iyi performans için kaynak kodunu WSL Linux dosya sisteminde (ör. /home/kullanici/proje) konumlandırın. Editör olarak VS Code kullanıyorsanız Remote - WSL eklentisiyle bu akış oldukça rahattır.

6) Sık karşılaşılan sorunlar ve çözümler

“Cannot connect to the Docker daemon” hatası alıyorsanız çoğunlukla servis çalışmıyordur: sudo systemctl status docker ile kontrol edin, gerekirse sudo systemctl restart docker deneyin. Systemd aktif değilse, önce /etc/wsl.conf ayarını doğrulayın ve wsl --shutdown ile tamamen kapatıp açın.

Port çakışması yaşarsanız (ör. 8080 doluysa) farklı bir port seçin: -p 8081:80. Ayrıca bazı güvenlik yazılımları veya şirket VPN’leri localhost portlarını etkileyebilir; sorun yaşarsanız geçici olarak kapatıp test etmek mantıklı olur.

Kaynak tüketimi için WSL’e limit koyabilirsiniz. Windows kullanıcı dizininizde .wslconfig dosyası oluşturup bellek/CPU sınırı vermek, özellikle uzun süre açık kalan geliştirme makinelerinde sistemi rahatlatır. Örneğin 4 GB RAM ve 4 çekirdek sınırı çoğu orta ölçekli iş için yeterlidir.

Sonuç

Docker Desktop olmadan Docker kullanmak, özellikle “hafif ve kontrol edilebilir” bir geliştirme ortamı isteyenler için güçlü bir alternatif. WSL2 üzerinde Docker Engine kurduğunuzda hem Linux ekosisteminin doğallığını korur hem de Windows tarafındaki iş akışınızı bozmadan konteynerlerle çalışabilirsiniz. Doğru proje konumu seçimi ve systemd ile servis yönetimi gibi küçük dokunuşlar, deneyimi ciddi biçimde iyileştirir.

Docker ile Rootless Container Çalıştırma: Linux’ta Daha Güvenli ve Pratik Kurulum Rehberi

Rootless Docker nedir ve neden önemli?

Docker’ı çoğu sistemde “root” ayrıcalıklarıyla çalıştırmak alışıldık bir durumdur. Ancak bu yaklaşım, Docker daemon’una (dockerd) erişebilen bir kullanıcının sistem üzerinde beklenmedik yetkilere ulaşabilmesi gibi güvenlik riskleri doğurabilir. Rootless Docker, container’ları ve Docker daemon’unu root yetkisi olmadan, sıradan bir kullanıcı hesabı altında çalıştırarak saldırı yüzeyini azaltmayı hedefler. Özellikle çok kullanıcılı makinelerde, geliştirme sunucularında veya güvenlik hassasiyeti yüksek ortamlarda rootless yaklaşım belirgin bir avantaj sağlar.

Bu yazıda, güncel Linux dağıtımlarında rootless Docker’ı adım adım kuracak, ağ ve port yönlendirme gibi sık karşılaşılan noktaları netleştirecek ve kullanım sırasında işinize yarayacak pratik ipuçlarını paylaşacağım. Anlatım Debian/Ubuntu çizgisinde olsa da, Fedora/Arch gibi dağıtımlarda da kavramlar büyük ölçüde aynıdır.

Ön koşullar ve temel kavramlar

Rootless modun arkasında birkaç önemli mekanizma bulunur: Linux user namespace (kullanıcı isim alanı) sayesinde container içindeki “root”, host üzerinde gerçek root olmaz; ayrıca ağ tarafında çoğunlukla slirp4netns veya benzeri user-space ağ çözümleri devreye girer. Bu sayede Docker, root yetkisi olmadan da container’lara izolasyon sağlayabilir. Yine de bazı sınırlamalar vardır: düşük portlara (1-1023) doğrudan bind etmek, belirli network sürücüleri veya bazı kernel özellikleri rootless senaryoda farklı davranabilir.

Gerekenler: 1) Güncel bir Linux kernel (çoğu modern dağıtım yeterli), 2) Sisteminizde Docker’ın rootless araçları (paket içeriği veya docker-ce kurulumuyla gelir), 3) user namespace desteği (genelde açıktır), 4) Ağ için slirp4netns ve yardımcı araçlar (dağıtıma göre paket isimleri değişebilir).

Kurulum: Rootless Docker’ı etkinleştirme

Önce Docker’ın sisteminizde kurulu olduğundan emin olun. Dağıtımınızın deposundan veya Docker’ın resmi paketlerinden kurulumu yapabilirsiniz. Rootless kurulumun kritik adımı, kullanıcı bazında bir Docker daemon’u başlatmaktır. Bunun için Docker, genellikle dockerd-rootless-setuptool.sh adlı bir yardımcı betik sağlar.

Terminalde kullanıcı hesabınızla şu komutu çalıştırın (dosya yolu dağıtıma göre değişebilir):

dockerd-rootless-setuptool.sh install

Bu işlem, kullanıcı seviyesinde systemd servisleri tanımlar ve Docker socket’ini kullanıcı dizininize taşır. Kurulum tamamlandığında size çoğu zaman bir “DOCKER_HOST” önerisi de gösterilir. Tipik olarak rootless Docker socket’i şu yolda olur:

unix:///run/user/1000/docker.sock

Eğer systemd kullanıyorsanız, rootless daemon’u şu şekilde yönetebilirsiniz:

systemctl --user start docker

systemctl --user enable docker

Ardından Docker istemcisinin doğru socket’e bağlanması gerekir. Çoğu kurulum betiği ortam değişkeni önerir. Örneğin:

export DOCKER_HOST=unix:///run/user/1000/docker.sock

Bu değişkeni kalıcı yapmak için shell profilinize ekleyebilirsiniz (ör. ~/.bashrc veya ~/.zshrc). Sonrasında kontrol için:

docker info

Çıktıda “rootless” ibaresini ve “Server” kısmında kullanıcı-oturumuna bağlı socket yolunu görmeniz beklenir.

Portlar, ağ ve “1024 altı” konusu

Rootless Docker’da en çok takılınan başlık port yönlendirmedir. Normalde root yetkisiyle 80/443 gibi düşük portlara bind etmek kolaydır; rootless modda ise bu portlar için ek ayar gerekir. İki pratik yaklaşım var: 1) Container’ı 8080/8443 gibi yüksek portlarda yayınlayıp reverse proxy ile 80/443’e taşımak, 2) Rootless için port yönlendirme yardımcılarını kullanmak (dağıtıma ve kurulum biçimine göre değişebilir).

Basit bir test için Nginx container’ını 8080’e yayınlayabilirsiniz:

docker run --rm -p 8080:80 nginx:latest

Tarayıcıdan http://localhost:8080 ile kontrol edin. Bu senaryo rootless modda genellikle sorunsuz çalışır.

Depolama ve performans notları

Rootless modda depolama sürücüsü seçimi ve overlay kullanımı dağıtıma göre değişebilir. Modern sistemlerde “overlay2” çoğu zaman mümkün olsa da, bazı ortamlarda “fuse-overlayfs” devreye girer. Bu, uyumluluk açısından avantaj sağlarken belirli iş yüklerinde performansı etkileyebilir. Eğer çok sayıda küçük dosya operasyonu yapan build süreçleriniz varsa (ör. büyük Node.js bağımlılıkları veya yoğun katmanlı Dockerfile’lar), rootless ve rootful performansını kendi ortamınızda kıyaslamak mantıklıdır.

Bir diğer pratik nokta: Rootless kurulum, imajları ve container verisini kullanıcı dizinine yakın bir yerde tutar. Bu da çok kullanıcı bulunan sistemlerde kullanıcı başına ayrı izolasyon sağlar. Öte yandan disk kotası, home dizini şifrelemesi veya NFS üzerinde home kullanımı gibi durumlar performansı etkileyebilir.

Güvenlik açısından artılar ve dikkat edilmesi gerekenler

Rootless Docker, “Docker grubuna eklenen kullanıcı root olur” eleştirisini önemli ölçüde azaltır; daemon ve container’lar ayrıcalıksız çalıştığı için bir kaçış senaryosunun etkisi genellikle sınırlanır. Yine de bu, tüm risklerin sıfırlandığı anlamına gelmez. Container içindeki uygulamalarınıza dair zafiyetler, yanlış volume mount kullanımı veya hassas dosyaların container’a verilmesi gibi hatalar rootless modda da sorun çıkarabilir.

Öneriler: Gereksiz yetkileri kapatın, container’lara sadece ihtiyaç duyduğu klasörleri bind edin, mümkünse read-only mount kullanın, “latest” yerine sabit etiketli imajlar tercih edin ve düzenli olarak imajlarınızı güncelleyin.

Ne zaman rootless tercih edilmeli?

Eğer kişisel geliştirme makinenizde, paylaşımlı bir Linux sunucusunda veya CI ortamında Docker kullanıyorsanız rootless yaklaşım ciddi bir güvenlik artısı sağlar. “Ben zaten sudo kullanıyorum” diyenler için bile rootless, Docker daemon’u üzerinden gelebilecek ayrıcalık yükseltme risklerini azaltır. Bununla birlikte özel network gereksinimleri, düşük port zorunluluğu veya yüksek I/O performansı gibi ihtiyaçlarınız varsa rootful Docker hâlâ daha uygun olabilir. İdeal yaklaşım, iş yüküne göre iki modeli de doğru yerde kullanmaktır.

Bu rehberdeki adımlarla rootless Docker’ı aktif ettikten sonra günlük kullanım alışkanlıklarınız çok değişmeden, daha güvenli bir çalışma düzenine geçebilirsiniz. İlk etapta port ve ağ detaylarını netleştirmeniz, sonrasında da build ve runtime performansını kendi projenizde test etmeniz yeterli olacaktır.

Windows 11’de WSL2 ile Docker Desktop Kullanmadan Docker Kurulumu ve İleri Seviye Ayarlar

Docker Desktop’sız Docker: Neden ve Ne Kazandırır?

Windows 11 üzerinde Docker kullanmanın en popüler yolu Docker Desktop kurmaktır. Ancak kurumsal lisans politikaları, kaynak tüketimi, arka planda çalışan servislerin fazlalığı veya daha “Linux’a yakın” bir Docker deneyimi isteği, birçok geliştiriciyi alternatif arayışına itiyor. İyi haber şu: WSL2 sayesinde Docker Engine’i doğrudan Linux tarafında kurup, Windows’tan komut satırı ile yönetmek mümkün. Bu yöntem genellikle daha hafif çalışır, daha kontrol edilebilir bir yapı sunar ve özellikle terminal odaklı geliştiriciler için oldukça rahattır.

Bu yazıda, Windows 11’de WSL2 (Ubuntu örneğiyle) kullanarak Docker Engine kurulumunu, Windows terminalinden Docker komutlarını çalıştırmayı ve performans/depoma/ ağ ayarları gibi birkaç ileri seviye noktayı adım adım ele alacağım. Sonuçta Docker Desktop olmadan da modern konteyner geliştirme akışını sürdürebileceksiniz.

Ön Koşullar: WSL2 ve Ubuntu Kurulumu

Öncelikle sisteminizde WSL2 aktif olmalı. Windows Terminal veya PowerShell’i yönetici olarak açıp aşağıdaki komutu çalıştırabilirsiniz:

wsl --install

Kurulum tamamlandıktan sonra Microsoft Store üzerinden Ubuntu yükleyebilir ya da komutla kurabilirsiniz. Ardından Ubuntu’yu açıp kullanıcı adı/parola belirleyin. WSL sürümünü kontrol etmek için:

wsl -l -v

Ubuntu’nun VERSION sütununda 2 yazdığından emin olun. Değilse:

wsl --set-version Ubuntu 2

Adım 1: Ubuntu’da Docker Engine Kurulumu (Resmi Depo)

WSL içindeki Ubuntu terminalinde önce paketleri güncelleyin:

sudo apt update && sudo apt upgrade -y

Gerekli paketleri yükleyin:

sudo apt install -y ca-certificates curl gnupg

Docker’ın resmi GPG anahtarını ekleyin ve depo kaynağını tanımlayın:

sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo $VERSION_CODENAME) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

Sonra Docker paketlerini kurun:

sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Adım 2: Docker Servisini WSL’de Çalıştırma

WSL2’de systemd artık destekleniyor; en temiz yöntem systemd’yi açmaktır. Ubuntu içinde /etc/wsl.conf dosyasını düzenleyin:

sudo nano /etc/wsl.conf

İçeriğe şunu ekleyin:

[boot]
systemd=true

Ardından Windows tarafında WSL’i kapatıp yeniden başlatın:

wsl --shutdown

Ubuntu’yu tekrar açınca Docker servisini başlatın ve durumunu kontrol edin:

sudo systemctl enable docker
sudo systemctl start docker
sudo systemctl status docker

Adım 3: Sudo’suz Docker Kullanımı (Geliştirici Konforu)

Her komutta sudo yazmamak için kullanıcıyı docker grubuna ekleyin:

sudo usermod -aG docker $USER

Değişikliğin uygulanması için oturumu kapatıp açın ya da Ubuntu terminalini kapatıp yeniden başlatın. Test:

docker run --rm hello-world

Windows Terminal’den Docker Komutlarını Yönetmek

Docker Engine WSL içinde çalıştığı için en basit yönetim biçimi, Windows Terminal’de doğrudan Ubuntu profilini kullanmaktır. Yani komutları Ubuntu sekmesinde çalıştırdığınızda her şey doğal şekilde ilerler. Eğer PowerShell’den tek satırla çalıştırmak isterseniz:

wsl -d Ubuntu -- docker ps

Bu yaklaşım, CI benzeri yerel script’lerde veya kısa kontrollerde oldukça işe yarar.

İleri Seviye Ayar 1: WSL Kaynak Sınırları (RAM/CPU)

WSL, varsayılan olarak sistem kaynaklarını dinamik kullanır. Docker build süreçleri ağırlaştığında RAM tüketimi artabilir. Bunu sınırlamak için Windows kullanıcı dizininize .wslconfig dosyası oluşturup örnek bir sınır koyabilirsiniz:

[wsl2]
memory=6GB
processors=4

Değişiklikten sonra wsl --shutdown yaparak yeniden başlatın. Bu ayar, özellikle dizüstü bilgisayarlarda fan ve pil performansını belirgin şekilde iyileştirir.

İleri Seviye Ayar 2: Dosya Performansı ve Proje Konumu

Kritik nokta şu: Docker konteynerleri WSL içindeki Linux dosya sisteminde daha hızlı çalışır. Projeyi /home/kullanici/proje altında tutmak genelde, projeyi /mnt/c üzerinden Windows dosya sisteminde tutmaktan daha performanslıdır. Özellikle Node.js bağımlılıkları, PHP vendor dizinleri veya çok sayıda küçük dosya içeren projelerde fark gözle görülür hale gelir.

İleri Seviye Ayar 3: Docker Compose v2 ve Buildx

Kurulumda gelen docker compose (v2) ve buildx eklentileri, modern geliştirme akışının temel parçaları. Örneğin çoklu servisli bir projeyi ayağa kaldırmak için:

docker compose up -d

Daha hızlı ve tekrar kullanılabilir build işlemleri için build cache’i etkin kullanan bir Dockerfile tasarlamak, WSL ortamında da doğrudan avantaj sağlar. Ayrıca buildx ile farklı platformlar için build almak (ör. linux/amd64 ve linux/arm64) ileri seviye senaryolarda elinizi güçlendirir.

Sık Karşılaşılan Sorunlar ve Hızlı Çözümler

Docker daemon çalışmıyor: systemd açık mı kontrol edin. cat /etc/wsl.conf ile doğrulayın, ardından wsl --shutdown ile yeniden başlatın.

Permission denied: Kullanıcınız docker grubunda olmayabilir. groups komutuyla kontrol edin, gerekirse usermod -aG docker adımını tekrarlayın.

Disk şişmesi: Konteyner ve imajlar büyüdükçe WSL sanal diski genişler. Düzenli olarak docker system prune kullanmak ve gereksiz imajları temizlemek iyi bir alışkanlıktır.

Sonuç

Docker Desktop kullanmadan, WSL2 üzerinde Docker Engine çalıştırmak Windows 11’de hem pratik hem de “Linux’a yakın” bir geliştirme ortamı sunuyor. Kurulum bir kez oturduğunda günlük kullanımda fark edilir bir hafiflik sağlıyor; kaynak yönetimi daha esnek oluyor ve terminal odaklı iş akışları daha akıcı ilerliyor. Eğer konteyner geliştirmeyi daha kontrollü ve minimal bir kurulumla sürdürmek istiyorsanız, bu yöntem kesinlikle değerlendirilmeye değer.

Docker ile Rootless (Yetkisiz) Container Çalıştırma: Güvenli Kurulum ve İnce Ayar Rehberi

Rootless Docker nedir ve neden önemli?

Docker çoğu sistemde varsayılan olarak root yetkisiyle çalışan bir “daemon” kullanır. Bu, günlük kullanımda pratik olsa da saldırı yüzeyi açısından risklidir: bir konteynerden kaçış (container escape) veya yanlış yapılandırılmış bir bind mount gibi senaryolarda etkiler büyüyebilir. Rootless Docker ise Docker’ı sistemde ayrıcalıklı (root) bir servis olarak çalıştırmadan, normal bir kullanıcı hesabı altında çalıştırmanıza imkân tanır. Böylece olası bir ihlal durumunda etki alanı, o kullanıcıyla sınırlı kalır.

Bu yazıda rootless Docker’ı kurup yapılandıracağız; ayrıca ağ, port yönlendirme, dosya izinleri ve performans tarafındaki kritik ayrıntıları netleştireceğiz. Anlatım Linux odaklıdır ve özellikle Ubuntu/Debian türevlerinde sorunsuz ilerler; Fedora ve benzerlerinde komutlar büyük ölçüde aynıdır.

Ön koşullar

Rootless Docker için çekirdek tarafında kullanıcı ad alanları (user namespaces) ve bazı yardımcı araçlar gerekir. Önce sisteminizde aşağıdakilerin yüklü olduğundan emin olun: uidmap (newuidmap/newgidmap), slirp4netns (rootless ağ), fuse-overlayfs (rootless overlay sürücüsü, her sistemde şart değil) ve mümkünse güncel bir Docker paketi.

Debian/Ubuntu için temel paketler: sudo apt-get update ardından sudo apt-get install -y uidmap slirp4netns fuse-overlayfs. Docker’ı dağıtımın deposundan veya Docker’ın resmi deposundan kurabilirsiniz; rootless mod için modern sürüm önerilir.

Subuid/subgid yapılandırması

Rootless modun kalbi, kullanıcıya ayrılmış UID/GID aralıklarıdır. Sistem, normal kullanıcının konteyner içinde farklı kimliklerle işlem yapabilmesi için bu aralıkları /etc/subuid ve /etc/subgid dosyalarında tutar. Çoğu dağıtımda kurulum sırasında otomatik eklenir; yine de kontrol etmek iyi fikir.

Örnek satır formatı şöyledir: kullanici:100000:65536. Eğer yoksa eklemek için root yetkisi gerekir. Değerler sisteminize göre değişebilir; önemli olan çakışmayan bir aralık olmasıdır. Bu aşamayı doğru yapmak, ileride “permission denied” türü gizemli hataları ciddi ölçüde azaltır.

Rootless kurulumu: dockerd-rootless-setuptool.sh

Docker’ın rootless kurulumu genellikle tek bir komutla yapılır. Normal kullanıcı hesabınızla oturum açtıktan sonra şu komutu çalıştırın: dockerd-rootless-setuptool.sh install. Bazı sistemlerde bu script PATH içinde değilse, Docker paketinin dokümantasyonundaki konuma göre çağırmanız gerekebilir.

Kurulum sonunda size genellikle iki kritik bilgi verilir: Docker soketinin bulunduğu yol ve ortam değişkeni önerisi. Rootless Docker çoğunlukla kullanıcı seviyesinde çalıştığı için soket yolu $XDG_RUNTIME_DIR/docker.sock benzeri bir konumda olur. Terminalinizde rootless bağlamı kullanmak için çoğu zaman export DOCKER_HOST=unix:///run/user/$(id -u)/docker.sock yeterlidir.

Servis olarak çalıştırma (systemd --user)

Sürekli kullanım için rootless Docker’ı kullanıcı servisi olarak çalıştırmak idealdir. Kurulum script’i çoğu zaman systemctl --user enable --now docker adımını önerir. Böylece sistem açıldığında, kullanıcı oturumu etkinleştiğinde Docker arka planda hazır olur.

Eğer “linger” etkin değilse, kullanıcı oturumu kapandığında servis durabilir. Sunucu senaryolarında bunun önüne geçmek için sudo loginctl enable-linger kullanici komutu işe yarar. Bu sayede kullanıcı oturumu kapalı olsa bile user-level servisler çalışmaya devam eder.

Port yönlendirme ve ağ kısıtları

Rootless modun en çok sorulan kısmı port yayınlamadır. Linux’ta 1024 altı “privileged port” sayılır ve root gerektirir. Rootless Docker’da -p 80:80 gibi bir eşleme çoğu sistemde doğrudan çalışmaz. Alternatif olarak uygulamanızı 8080 gibi bir porta alabilir veya sistem çapında bir ters proxy (Nginx/Traefik) ile 80/443 trafiğini root yetkisi olan servis üzerinden yönlendirebilirsiniz.

Ağ tarafında rootless genellikle slirp4netns ile kullanıcı alanında NAT benzeri bir yapı kullanır. Bu, güvenlik açısından avantajlıdır; ancak bazı yoğun ağ senaryolarında performans farkı görülebilir. Geliştirme ortamlarında çoğu kullanıcı için yeterlidir; yüksek bant genişliği ve düşük gecikme hedefliyorsanız ölçüm yapmanız önerilir.

Depolama sürücüsü ve dosya izinleri

Rootless Docker, dosya sistemi sürücüsü olarak çoğu zaman fuse-overlayfs veya uygun bir alternatif kullanır. Bu, klasik root modundaki overlay2 kadar “ham performans” vermeyebilir; ama güncel çekirdek ve SSD üzerinde günlük işler için genellikle sorun çıkarmaz. İmaj çekme, build ve volume kullanımlarında davranış farklılıkları olabileceği için CI/CD ortamlarınızda deneme yapmak akıllıca olur.

Volume tarafında kritik nokta şudur: Konteyner içindeki UID/GID eşlemeleri, hosttaki dosya sahipliğiyle farklı görünebilir. “Dosyalar yazılamıyor” sorunu yaşarsanız önce mount ettiğiniz klasörün izinlerini, ardından konteynerin çalıştığı kullanıcıyı ve gerekiyorsa --user parametresini kontrol edin.

Hızlı test: Rootless çalışıyor mu?

Kurulumdan sonra şu komutlarla doğrulama yapabilirsiniz: docker info çıktısında rootless ibaresini arayın. Ardından basit bir konteyner başlatın: docker run --rm hello-world. İmaj iniyor ve konteyner sorunsuz çalışıyorsa temel kurulum tamamdır.

Son olarak küçük bir web testi yapmak isterseniz: docker run --rm -p 8080:80 nginx deyip tarayıcıdan http://localhost:8080 adresini kontrol edin. Eğer port erişimi varsa rootless ağ zinciri de doğru çalışıyor demektir.

Ne zaman rootless, ne zaman klasik Docker?

Rootless Docker; geliştirici makineleri, çok kullanıcılı sunucular, güvenliği öncelikleyen laboratuvar ortamları ve “en az yetki” yaklaşımı için güçlü bir seçenektir. Buna karşın düşük portlara doğrudan bind ihtiyacı, bazı ağ sürücüleri (macvlan benzeri) veya belirli kernel özelliklerine bağımlı iş yükleri gibi durumlarda klasik (root) Docker hâlâ daha sorunsuz olabilir.

İyi haber şu: Rootless’a geçiş genellikle geri dönüşü zor bir karar değildir. Aynı makinede her iki yaklaşımı da senaryoya göre kullanabilir, kritik servisleri geleneksel olarak yönetirken geliştirme ve test süreçlerinizi rootless ile daha güvenli hale getirebilirsiniz.

Windows 11’de WSL 2 ile Docker Desktop Kullanmadan Docker Kurulumu ve Hızlandırma Rehberi

Giriş: Neden Docker Desktop’sız Docker?

Windows 11’de Docker kullanmanın en popüler yolu Docker Desktop olsa da, her senaryoda en iyi seçenek olmayabiliyor. Lisans politikaları, sistem kaynak tüketimi, kurumsal kısıtlar veya daha “çıplak” bir kurulum isteği gibi sebeplerle WSL 2 üzerinde doğrudan Docker Engine kurmak hem daha hafif hem de daha kontrol edilebilir bir yaklaşım sunuyor. Bu yazıda, Windows 11 üzerinde WSL 2 kullanarak Docker’ı Docker Desktop olmadan kurmayı, Windows ile entegrasyonu sağlamayı ve performansı iyileştirecek birkaç ileri seviye ayarı adım adım ele alacağım.

1) Ön Koşullar: WSL 2 ve Dağıtım Seçimi

Öncelikle WSL 2’nin etkin olduğundan emin olmalısınız. Windows 11’de çoğu sistemde WSL zaten sorunsuz çalışır; yine de güncel bir kurulum için PowerShell’i yönetici olarak açıp WSL’yi kurmak veya güncellemek iyi bir başlangıçtır. Ardından Ubuntu 22.04/24.04 gibi yaygın bir dağıtım seçmenizi öneririm; dokümantasyon ve topluluk desteği güçlü olduğu için sorun çözmek daha kolay olur.

Kontrol: WSL sürümünüzü görmek için Windows tarafında wsl -l -v komutunu kullanabilirsiniz. Dağıtımınızın sürümü “2” değilse WSL 2’ye yükseltmeniz gerekir. Ayrıca BIOS/UEFI’de sanallaştırma (Virtualization) açık olmalıdır; aksi halde WSL 2 beklenmedik şekilde yavaşlar veya hiç çalışmaz.

2) WSL İçinde Docker Engine Kurulumu

Docker Desktop kurmadan Docker çalıştırmanın ana fikri şu: Docker Engine, Linux ortamında çalışır; biz de bunu WSL 2 içindeki Ubuntu’da kurarız. Ardından Docker komutlarını aynı WSL ortamında kullanırız. Böylece arka planda ayrı bir GUI uygulaması değil, standart Linux servisleri devreye girer.

Adımlar: Ubuntu terminalini açın ve sisteminizi güncelleyin. Daha sonra Docker’ın resmi deposunu ekleyerek Docker Engine kurun. Depodan kurmak, dağıtım deposundaki eski sürümlere göre genellikle daha güncel bir Docker sürümü sağlar. Kurulumdan sonra Docker servisinin çalıştığını doğrulamak için docker version ve docker run hello-world komutlarını deneyebilirsiniz.

Kurulum sonrası sık yapılan bir ayar da kullanıcıyı “docker” grubuna eklemektir. Böylece her komutta sudo yazmanız gerekmez. Bu değişiklikten sonra WSL oturumunu kapatıp yeniden açmanız gerekir; aksi halde yetki değişimi görünmeyebilir.

3) systemd ile Servis Yönetimi (İleri Seviye ve Önerilen)

Eskiden WSL’de servis yönetimi daha zahmetliydi; ancak modern Windows 11 ve güncel WSL sürümlerinde systemd desteği bulunuyor. Docker Engine’i düzgün bir Linux makinesindeki gibi yönetmek istiyorsanız systemd oldukça kritik. Böylece Docker servisi WSL oturumu açıldığında otomatik başlar ve kapanışta düzgün durur.

systemd’yi etkinleştirmek için WSL içindeki yapılandırma dosyasına ilgili ayarı eklemeniz gerekir. Değişiklikten sonra Windows tarafında wsl --shutdown çalıştırıp WSL’yi yeniden başlatmak gerekir. Ardından Ubuntu içinde systemctl status docker ile servisin durumunu kontrol edebilirsiniz.

4) Windows Terminal ve VS Code ile Akıcı Geliştirme

Bu kurulumun pratik tarafı, geliştirme araçlarıyla birleştiğinde ortaya çıkar. Windows Terminal üzerinden Ubuntu profilinizi açıp Docker komutlarını doğrudan çalıştırabilirsiniz. Eğer Visual Studio Code kullanıyorsanız, Remote - WSL eklentisi ile projenizi WSL dosya sistemi içinde açıp konteyner build/run süreçlerini Linux tarafında yürütebilirsiniz. Bu, özellikle Node.js, Python ve Go projelerinde dosya izinleri ve satır sonu farklılıklarından kaynaklı problemleri ciddi şekilde azaltır.

Önemli not: Proje dosyalarınızı mümkünse WSL dosya sisteminde tutun (ör. /home/kullanici/proje). Windows sürücüsü üzerinden (ör. /mnt/c/...) çalışmak, özellikle çok sayıda küçük dosya içeren projelerde I/O performansını düşürebilir.

5) Performans İyileştirmeleri: .wslconfig ile Kaynak Sınırları

Docker konteynerleri CPU ve RAM tüketimini hızla artırabilir. WSL 2, varsayılan olarak sistem kaynaklarını dinamik kullanır; bu iyi olsa da bazı durumlarda RAM şişmesi veya disk kullanımının kontrolsüz büyümesi can sıkabilir. Windows kullanıcı dizininizde yer alan .wslconfig dosyasıyla WSL’nin kullanacağı kaynakları sınırlayabilirsiniz.

Örneğin RAM’i 8 GB ile sınırlamak, CPU sayısını belirlemek veya swap boyutunu ayarlamak mümkündür. Bu ayarlar özellikle aynı anda tarayıcı, IDE ve birkaç konteyner çalıştıran geliştiriciler için sistemin tepkiselliğini korur. Ayarlardan sonra wsl --shutdown ile WSL’yi yeniden başlatmayı unutmayın.

6) Ağ ve Port Yayınlama Mantığı: “localhost” Gerçeği

WSL 2, kendi sanal ağ katmanına sahip olduğu için “localhost” konusu zaman zaman kafa karıştırır. İyi haber şu: Güncel Windows 11 sürümlerinde WSL ile Windows arasında “localhost” üzerinden port yönlendirme çoğu senaryoda otomatik çalışır. Yani WSL içinde 8080 portunu yayınlayan bir konteyneri, Windows’ta tarayıcıdan http://localhost:8080 ile açabilirsiniz.

Yine de kurumsal güvenlik yazılımları veya özel firewall kuralları port erişimini engelleyebilir. Böyle bir durumda Windows Firewall izinlerini kontrol etmek, konteynerin gerçekten port yayınladığını docker ps ile doğrulamak ve WSL’nin IP adresini kullanarak test yapmak işe yarar.

7) Artılar, Eksiler ve Ne Zaman Tercih Etmeli?

Artılar: Daha az arka plan bileşeni, daha düşük kaynak tüketimi, daha “Linux’a yakın” bir Docker deneyimi ve kurulum üzerinde daha fazla kontrol. Ayrıca bazı kullanıcılar için Docker Desktop’ın getirdiği ekstra katmanlar yerine doğrudan Engine kullanmak daha öngörülebilir.

Eksiler: GUI yönetim paneli yoktur, bazı entegrasyonlar (Kubernetes tek tıkla aç/kapat gibi) Docker Desktop kadar hazır gelmez. Ayrıca birden fazla WSL dağıtımı kullanıyorsanız Docker’ın hangi dağıtımda kurulu olduğu ve nereden çalıştırıldığı konusunu iyi yönetmeniz gerekir.

Sonuç

Windows 11’de WSL 2 üzerinde Docker Engine kurup Docker Desktop kullanmadan çalışmak, özellikle geliştirici odaklı ve performans hassasiyeti olan kullanıcılar için güçlü bir alternatiftir. Doğru yapılandırma ile servis yönetimi systemd üzerinden düzenli çalışır, proje dosyalarını WSL içinde tutarak I/O performansı korunur ve .wslconfig ile sistem kaynakları kontrol altına alınır. Eğer hedefiniz “hafif, hızlı ve kontrol edilebilir” bir Docker ortamıysa bu yöntem, günlük geliştirme akışınıza beklediğinizden daha rahat uyum sağlayacaktır.

Windows 11’de WSL2 ile Docker Desktop Kullanmadan Docker Kurulumu ve Performans Ayarları

WSL2 ile “hafif” Docker fikri neden mantıklı?

Windows 11 üzerinde Docker çalıştırmanın en popüler yolu Docker Desktop. Ancak bazı senaryolarda (kurumsal lisans politikaları, kaynak tüketimi, arka planda çalışan servisler, ekstra arayüz katmanı) Docker Desktop yerine doğrudan WSL2 içinde Docker Engine kurmak daha temiz bir çözüm olabiliyor. Bu yazıda, Docker Desktop kullanmadan WSL2 üzerinde Docker’ı kuracağız; ardından performans ve disk kullanımını iyileştiren birkaç kritik ayarı yapacağız.

Ön koşullar

Gerekenler: Windows 11, yönetici yetkisi, WSL2 desteği ve bir Linux dağıtımı (Ubuntu önerilir). Windows tarafında WSL2 etkin değilse önce etkinleştirmeniz gerekir. Ayrıca BIOS/UEFI’de sanallaştırmanın açık olması, WSL2’nin stabil çalışması için önemlidir.

Adım 1: WSL2 ve Ubuntu kurulumu

PowerShell’i yönetici olarak açıp aşağıdaki komutu çalıştırın. Bu komut WSL’yi kurar ve varsayılan olarak Ubuntu’yu indirip kurabilir:

Komut: wsl --install

Kurulumdan sonra bilgisayarınızı yeniden başlatın. Ardından Ubuntu ilk açılışta kullanıcı adı/şifre oluşturmanızı ister. Mevcut WSL dağıtımlarınızı görmek için:

wsl -l -v

Burada dağıtımınızın Version 2 olduğundan emin olun. Değilse:

wsl --set-version Ubuntu 2

Adım 2: WSL2 içinde Docker Engine kurulumu

Ubuntu terminalini açın ve sistemi güncelleyin:

sudo apt update && sudo apt upgrade -y

Docker’ın resmi deposunu eklemek güncel sürüm için daha sağlıklıdır. Sırasıyla şu komutları çalıştırın:

sudo apt install -y ca-certificates curl gnupg

sudo install -m 0755 -d /etc/apt/keyrings

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

sudo chmod a+r /etc/apt/keyrings/docker.gpg

echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo $VERSION_CODENAME) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt update

Şimdi Docker Engine ve gerekli bileşenleri kurun:

sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Adım 3: Docker’ı root’suz kullanmak (sudo derdini bitirin)

Geliştirici deneyimi açısından en önemli adım: kullanıcıyı docker grubuna eklemek. Böylece her komutta sudo yazmanız gerekmez.

sudo usermod -aG docker $USER

Değişikliğin uygulanması için Ubuntu oturumunu kapatıp açın ya da şu komutla kabuğu yenileyin:

newgrp docker

Docker’ın çalıştığını doğrulamak için:

docker run --rm hello-world

Adım 4: WSL2’de Docker servisini otomatik başlatma

WSL, klasik Linux gibi her zaman systemd ile açılmayabilir. Windows 11 ve güncel WSL sürümlerinde systemd desteği var. Etkinleştirerek Docker’ın açılışta başlamasını sağlayabilirsiniz.

WSL içinde /etc/wsl.conf dosyasını düzenleyin:

sudo nano /etc/wsl.conf

İçerik şu şekilde olsun:

[boot] systemd=true

Ardından Windows tarafında WSL’yi yeniden başlatın:

wsl --shutdown

Ubuntu’yu tekrar açınca Docker servisini başlatıp kalıcı hale getirebilirsiniz:

sudo systemctl enable --now docker

Adım 5: Performans için kritik ayar: proje dosyalarını nereye koymalısınız?

WSL2’de en sık yapılan hata, proje klasörünü /mnt/c gibi Windows dosya sistemi altında tutup Docker build ve bind mount işlemlerini burada yapmak. Bu kullanım çalışır ama dosya erişimi katmanı nedeniyle özellikle Node.js, PHP, Python gibi çok sayıda küçük dosya okuyan projelerde performans düşebilir.

Öneri: Kodunuzu WSL2 Linux dosya sistemi içinde (ör. /home/kullanici/proje) tutun. Windows’tan erişmek için de Dosya Gezgini’ne \\wsl$ yazarak Ubuntu dizinlerine ulaşabilirsiniz. Bu sayede Docker build süreleri ve canlı geliştirme (hot reload) daha stabil hale gelir.

Adım 6: Disk şişmesini kontrol etme ve temizlik

Docker kullanırken imajlar ve kullanılmayan katmanlar zamanla disk alanını şişirir. Düzenli aralıklarla temizlik yapmak iyi bir alışkanlık:

docker system df

docker system prune -a

Eğer sadece kullanılmayan container’ları ve dangling imajları temizlemek isterseniz daha güvenli bir yaklaşım seçebilirsiniz. Ancak prune -a tüm kullanılmayan imajları da siler; tekrar gerektiğinde yeniden indirmek zorunda kalırsınız.

Sık karşılaşılan sorunlar

“Cannot connect to the Docker daemon”: Docker servisi çalışmıyor olabilir. Systemd etkinse sudo systemctl status docker ile kontrol edin. Değilse geçici olarak sudo dockerd ile daemon başlatılabilir, fakat kalıcı çözüm systemd’yi aktif etmektir.

Port çakışmaları: Windows’ta aynı portu kullanan bir servis varsa container ayağa kalksa bile erişim sorunları yaşayabilirsiniz. netstat ile Windows tarafında portu kim kullanıyor bakın ve compose dosyanızdaki portları değiştirin.

Ağ erişimi: WSL2 ağ katmanı NAT üzerinden çalışır. Yerel ağdan WSL2 içindeki bir servise erişmek bazen ekstra yönlendirme gerektirebilir; çoğu geliştirme senaryosunda ise localhost yeterlidir.

Sonuç

Docker Desktop olmadan WSL2 üzerinde Docker Engine kurmak, daha az arka plan bileşeniyle daha “Linux’a yakın” bir deneyim sunar. Özellikle performans hassas projelerde dosyaları Linux tarafında tutmak ve systemd ile Docker’ı otomatik başlatmak günlük kullanım konforunu ciddi şekilde artırır. Bu kurulumla hem docker compose kullanabilir hem de modern buildx özelliklerinden faydalanabilirsiniz.

Docker Üzerinde Rootless Mod ile Güvenli Container Çalıştırma: Adım Adım Kurulum ve İnce Ayarlar

Rootless Docker Nedir ve Neden Önemli?

Docker, geliştiricilerin uygulamaları taşınabilir şekilde paketlemesini kolaylaştırdı; ancak klasik kurulumda Docker daemon (dockerd) genellikle root yetkileriyle çalışır. Bu da teorik olarak bir container kaçışı veya yanlış yapılandırma durumunda sistem genelinde daha büyük risk anlamına gelebilir. Rootless Docker, Docker’ı root yetkisi olmadan çalıştırarak saldırı yüzeyini azaltmayı hedefleyen güncel ve ileri seviye bir yaklaşımdır.

Rootless modda hem daemon hem de container süreçleri normal bir kullanıcı hesabıyla çalışır. Böylece “root” ayrıcalıklarına ihtiyaç duymadan container yönetimi yapılır. Bu yaklaşım özellikle paylaşımlı sunucularda, geliştirici makinelerinde veya güvenlik politikasının sıkı olduğu kurum ortamlarında ciddi avantaj sağlar.

Ön Koşullar: Sistem ve Kernel Gereksinimleri

Rootless Docker için güncel bir Linux dağıtımı önerilir (Ubuntu 22.04+, Debian 12, Fedora vb.). Temel olarak user namespace altyapısına ihtiyaç duyulur. Pek çok modern dağıtımda bu özellik varsayılan olarak hazır gelir; yine de aşağıdaki iki dosyanın doğru yapılandırılmış olması önemlidir: /etc/subuid ve /etc/subgid. Bu dosyalar, root yetkisi olmadan UID/GID eşlemesi yapabilmek için kullanılır.

Kısaca hedef şu: Kendi kullanıcı hesabınız (ör. ali) için belirli bir UID/GID aralığı atanır ve Docker bunu container içi “root”u, host tarafında ayrıcalıksız bir UID’ye map’leyerek gerçekleştirir.

Kurulum: Rootless Modu Etkinleştirme

Önce Docker’ın sisteminizde kurulu olması gerekir. Dağıtımınızın resmi Docker deposunu kullanmanız tavsiye edilir. Kurulum tamamlandıktan sonra rootless kurulumu için Docker’ın sağladığı script devreye girer. Çoğu sistemde şu komut yeterlidir:

dockerd-rootless-setuptool.sh install

Bu adım, kullanıcı düzeyinde bir systemd servisi oluşturur ve gerekli ortam değişkenleriyle birlikte rootless daemon’ı ayağa kaldırır. Ardından rootless daemon’ı başlatmak için genellikle şu komut kullanılır:

systemctl --user start docker

Otomatik başlaması için:

systemctl --user enable docker

Ortam Değişkenleri: Docker Client Doğru Daemon’a Bağlansın

Rootless modda Docker, varsayılan olarak kullanıcıya özel bir UNIX socket üzerinden hizmet verir. Bu nedenle terminal oturumunuzun doğru socket’e bağlanması gerekir. Çoğu kurulum aşağıdaki gibi bir öneri verir:

export DOCKER_HOST=unix:///run/user/1000/docker.sock

Buradaki 1000 değeri sizin kullanıcı UID’nizdir; id -u komutuyla öğrenebilirsiniz. Bu export satırını kalıcı yapmak için ~/.bashrc veya ~/.zshrc içine ekleyebilirsiniz.

Test: Rootless Çalıştığını Nasıl Anlarsınız?

Kurulum sonrası hızlı bir doğrulama için:

docker info

Çıktıda rootless ile ilgili ibareler ve “Security Options” altında user namespace benzeri detaylar görmeniz beklenir. Ayrıca basit bir container çalıştırarak da test edebilirsiniz:

docker run --rm hello-world

Bu komutun başarılı çalışması, client’ın rootless daemon’a bağlanabildiğini ve temel container akışının sağlıklı olduğunu gösterir.

İnce Ayar 1: Port Yönlendirme ve 1024 Altı Portlar

Rootless Docker’ın en çok kafa karıştıran noktası port yayınlama tarafıdır. Klasik Docker’da 80/443 gibi ayrıcalıklı portlara kolayca bind edilebilirken, rootless modda bu işlem sınırlıdır. Çünkü 1024 altı portlara bind etmek genelde root yetkisi ister.

Çözüm olarak uygulamanızı 8080/8443 gibi yüksek portlarda çalıştırıp ters proxy (ör. Nginx) ile yönlendirebilir veya sistemde setcap gibi yöntemlerle belirli ikili dosyalara sınırlı yetki verebilirsiniz. Güvenlik bakış açısıyla en temiz yaklaşım, servisleri yüksek portta çalıştırıp yönlendirme katmanını ayrıca yönetmektir.

İnce Ayar 2: Dosya İzinleri ve Bind Mount Davranışı

Rootless modun doğal sonucu olarak, host dosya izinleri daha belirleyici hale gelir. Bind mount yaptığınızda container içindeki kullanıcı ile host tarafındaki UID eşleşmesi farklı görünebilir. Özellikle CI ortamlarında veya “volume” olarak paylaşılan dizinlerde yazma izni sorunları çıkabilir.

Pratikte en iyi yöntem, proje dizininizin sahipliğini ve izinlerini net tutmak, gerekiyorsa container içinde çalışacak kullanıcıyı açıkça belirlemek ve “her şeyi 777 yapmak” gibi kötü alışkanlıklardan kaçınmaktır. Rootless, güvenliği artırırken disiplinli izin yönetimini de zorunlu kılar.

Rootless Docker Ne Zaman Mantıklı, Ne Zaman Değil?

Kişisel geliştirme ortamı, paylaşımlı sistemler ve güvenlik öncelikli senaryolarda rootless mod çok mantıklıdır. Buna karşılık, düşük portlara yoğun ihtiyaç, bazı sürücü/overlay kısıtları veya özel ağ/iptables beklentileri olan ortamlarda klasik kurulum daha az sürtünmeyle çalışabilir. Yine de güncel Docker sürümleriyle rootless olgunlaştı; güvenlik açısından “varsayılan tercih” olmaya giderek daha yakın.

Özetle: Eğer makinenizde container’ları “root gibi” çalıştırmak zorunda değilseniz, rootless Docker ile daha güvenli bir temel elde edersiniz. Kurulum birkaç adım sürer; kazandırdığı güvenlik kazanımı ise uzun vadede oldukça değerlidir.

Windows 11’de WSL2 ile Docker Kurulumu: Yerel Geliştirmede Hızlı ve Temiz Bir Linux Ortamı

WSL2 + Docker neden bu kadar popüler?

Windows üzerinde yazılım geliştirirken bir yandan da “Linux gibi” çalışmak isteyenlerin sayısı arttı. Eskiden bunun için sanal makine kurmak, ayrı bir disk imajı yönetmek veya çift işletim sistemi kullanmak gerekiyordu. Windows 11 ile birlikte WSL2 (Windows Subsystem for Linux) olgunlaştı ve Docker’ı da bu altyapı üstünden kullanmak oldukça pratik hale geldi. Sonuç: daha az kaynak tüketen, daha hızlı açılan ve proje bağımlılıklarını daha tutarlı yöneten bir geliştirme ortamı.

Bu yazıda, Windows 11 üzerinde WSL2’yi etkinleştirip Ubuntu kuracak, ardından Docker’ı WSL2 motoruyla çalıştıracak şekilde yapılandıracağız. Amacımız “kuruluyor mu?” seviyesini geçip, günlük kullanımda sorun çıkaran detayları da doğru ayarlamak.

Ön koşullar ve kısa kontrol listesi

Başlamadan önce Windows 11’in güncel olduğundan emin olun. Ayrıca sisteminizde sanallaştırma (Virtualization) açık olmalı. Bunu görev yöneticisinde Performans > CPU bölümünde “Sanallaştırma: Etkin” şeklinde görebilirsiniz. Kapalıysa BIOS/UEFI üzerinden açmanız gerekebilir.

Kurulum için yönetici yetkisi olan bir Windows hesabı ve en az 8 GB RAM önerilir. Docker konteynerleri çalıştıracağımız için disk tarafında da rahat etmek adına en az 20 GB boş alan iyi olur.

1) WSL2’yi etkinleştirme ve Ubuntu kurulumu

Windows Terminal’i (PowerShell) yönetici olarak açın ve aşağıdaki komutu çalıştırın:

wsl --install

Bu komut WSL bileşenlerini yükler, varsayılan Linux dağıtımını (genellikle Ubuntu) kurar ve gerekli özellikleri aktif eder. Kurulumdan sonra sistem yeniden başlatma isteyebilir.

Kurulum tamamlanınca Ubuntu ilk açılışta sizden bir kullanıcı adı ve parola belirlemenizi ister. Bu parola Windows parolanız değildir; Linux içi yönetici işlemlerinde kullanılacak.

WSL sürümünüzü kontrol etmek için şu komutu kullanın:

wsl -l -v

Burada Ubuntu’nun “Version” sütununda 2 görünmesini hedefliyoruz. Eğer 1 görünüyorsa şu komutla WSL2’ye çevirebilirsiniz:

wsl --set-version Ubuntu 2

2) Docker Desktop kurulumu ve WSL2 entegrasyonu

Docker’ı Windows üzerinde en sorunsuz şekilde kullanmanın yolu çoğu senaryoda Docker Desktop kurmaktır. Kurulum sırasında “Use WSL 2 instead of Hyper-V” benzeri bir seçenek görürseniz WSL2’yi tercih edin. Kurulum tamamlandıktan sonra Docker Desktop’ı açın.

Docker Desktop içinde Settings bölümüne girin ve şu kontrolleri yapın:

General altında WSL2 tabanlı motorun açık olduğundan emin olun.

Resources > WSL Integration altında Ubuntu dağıtımınız için entegrasyonu etkinleştirin. Burada sadece kurduğunuz dağıtımı seçmeniz yeterli.

Bu noktadan sonra Docker komutlarını doğrudan Ubuntu terminalinde kullanabilirsiniz. Ubuntu içinde doğrulamak için:

docker version

Eğer sürüm bilgileri geliyorsa entegrasyon tamamdır.

3) Hızlı test: Basit bir konteyner çalıştırma

Kurulumun sağlıklı olduğundan emin olmak için klasik test imajını çalıştırın:

docker run --rm hello-world

Bu komut imajı indirir ve bir mesaj basıp çıkar. “Hello from Docker!” benzeri bir çıktı görmeniz gerekir. Bu aşamada hata alırsanız, Docker Desktop’ın çalıştığını ve Ubuntu entegrasyonunun açık olduğunu yeniden kontrol edin.

4) Geliştiriciler için kritik ayarlar: Dosya sistemi ve performans

WSL2 ile Docker kullanırken performansı en çok etkileyen konu proje dosyalarının nerede durduğudur. En iyi performans için kodlarınızı Windows tarafındaki C:\ altında değil, Ubuntu’nun kendi dosya sistemi içinde tutun. Örneğin Ubuntu terminalinde bir proje klasörü oluşturup burada çalışmak genellikle daha akıcı olur:

mkdir -p ~/projelerim/ornek

Windows dosyalarına Ubuntu’dan /mnt/c üzerinden erişebilirsiniz; ancak çok sayıda küçük dosyaya sahip Node.js, PHP Composer veya Python paketlerinde bu yol daha yavaş hissedilebilir.

5) İleri seviye ipuçları: Kaynak yönetimi ve ağ davranışı

WSL2, Linux çekirdeğini hafif bir sanallaştırma katmanında çalıştırır ve RAM kullanımını dinamik yönetir. Yine de yoğun konteyner kullanımında kaynak sınırlarını ayarlamak isteyebilirsiniz. Bunun için Windows kullanıcı dizininizde .wslconfig dosyası oluşturup örneğin RAM ve CPU limitleri belirlemek mümkün olur. Bu sayede “Docker çalışınca bilgisayar yavaşlıyor” şikâyetlerini azaltabilirsiniz.

Ağ tarafında ise konteyner portlarını Windows’a yönlendirmek genelde sorunsuzdur. Örneğin bir web servisini 8080 portunda ayağa kaldırdıysanız tarayıcıdan http://localhost:8080 ile erişebilirsiniz. Kurumsal ağlarda VPN veya güvenlik yazılımları bazen yerel port erişiminde sorun çıkarabilir; böyle bir durumda Windows güvenlik duvarı ve VPN bölünmüş tünelleme ayarları kontrol edilmelidir.

Sonuç: Windows üzerinde “temiz” Linux geliştirme deneyimi

WSL2 ile Docker’ı bir araya getirdiğinizde, Windows’un konforundan vazgeçmeden Linux araç zincirini neredeyse yerel hızda kullanabilirsiniz. Üstelik proje bağımlılıklarını konteynerlere taşıyarak “bende çalışıyor” tartışmalarını ciddi ölçüde azaltırsınız. Doğru dosya konumlandırması, WSL entegrasyonu ve temel kaynak ayarlarıyla bu kurulum uzun süre sorunsuz şekilde günlük iş akışınıza hizmet eder.

Docker’da Rootless Mod ile Güvenli Konteyner Çalıştırma: Adım Adım Kurulum ve İpuçları

Rootless Docker Nedir ve Neden Önemlidir?

Konteyner teknolojileri üretim ortamlarında standart hâline gelirken, güvenlik tarafında hâlâ sık yapılan bir hata var: Docker’ı kök kullanıcı (root) yetkileriyle çalıştırmak. Varsayılan Docker kurulumunda dockerd servisi root ayrıcalıklarıyla çalışır ve Docker grubuna eklediğiniz kullanıcılar fiilen root’a yakın yetkiler kazanır. Bu, yanlış yapılandırılmış bir konteyner veya zayıf bir imaj üzerinden sistemin tamamına sıçrama riskini artırır.

İşte burada Rootless Docker devreye girer. Rootless mod, Docker daemon’ını ve konteynerleri root olmadan çalıştırır. Böylece olası bir güvenlik açığında saldırganın erişimi kullanıcı alanıyla sınırlı kalır. Özellikle çok kullanıcılı sunucularda, CI/CD ajanlarında veya geliştiricilerin kendi makinelerinde güvenliği artırmak için oldukça iyi bir yaklaşımdır.

Kimler Rootless Docker Kullanmalı?

Rootless mod her senaryoya birebir uymaz; ancak pek çok kullanımda ciddi avantaj sağlar. Paylaşımlı geliştirme sunucuları, kurumsal dizüstüler, “konteyner çalıştırıyorum ama root yetkisi istemiyorum” yaklaşımı olan ekipler ve saldırı yüzeyini küçültmek isteyenler için idealdir. Öte yandan bazı ağ senaryolarında (örneğin düşük portlara doğrudan bind etmek) ekstra ayar gerekir. Bu yazıda temel kurulumun yanında pratik kısıtları ve çözüm yollarını da ele alacağım.

Ön Koşullar (Linux)

Rootless Docker en sorunsuz şekilde modern Linux dağıtımlarında çalışır. Bu rehberde Ubuntu/Debian çizgisini baz alıyorum; ancak Fedora/Arch tarafında da mantık aynı. Gerekli olanlar: güncel bir Docker kurulumu, kullanıcı bazlı servisleri yönetmek için systemd (çoğu dağıtımda var) ve kullanıcı namespace’lerinin düzgün ayarlanması.

Öncelikle Docker’ın kurulu olduğunu doğrulayın. Kurulu değilse dağıtımınızın resmi yönergelerini izleyin. Rootless mod için ayrıca Docker’ın sunduğu kurulum betiğini kullanacağız.

Adım Adım Rootless Docker Kurulumu

1) Kullanıcı namespace eşlemelerini kontrol edin
Rootless çalışabilmek için sistemde subuid ve subgid atamaları gerekir. Çoğu sistemde otomatik gelir; ancak kontrol etmekte fayda var. Aşağıdaki dosyalarda kullanıcı adınıza ait satır olmalı:

/etc/subuid ve /etc/subgid içinde kullanıcı adınızın karşısında bir aralık görmelisiniz (ör. kullanici:100000:65536). Yoksa yönetici yetkisiyle bu aralığı tanımlamak gerekir.

2) Rootless kurulum betiğini çalıştırın
Docker, rootless kurulumu kolaylaştıran bir betik sunar. Terminalde kendi kullanıcınızla şu komutu çalıştırın:

dockerd-rootless-setuptool.sh install

Kurulum sonunda size iki kritik bilgi verir: Docker soketinin yolu ve ortam değişkenleri. Genellikle DOCKER_HOST için kullanıcı dizini altında bir socket yolu tanımlanır.

3) Ortam değişkenlerini kalıcı hâle getirin
Terminal her açıldığında rootless daemon’a bağlanmak için genelde şu satır gerekir:

export DOCKER_HOST=unix:///run/user/1000/docker.sock

Kendi kullanıcı ID’nize göre yol değişebilir. Bunu ~/.bashrc veya ~/.zshrc dosyanıza ekleyin. Ardından yeni bir terminal açıp docker ps ile test edin.

4) Servisi kullanıcı olarak başlatın
Systemd kullanan sistemlerde rootless Docker genellikle kullanıcı servisi olarak yönetilir. Kurulum betiği çoğu zaman bunu ayarlar. Elle kontrol etmek isterseniz:

systemctl --user status docker

Servis aktif değilse başlatıp etkinleştirebilirsiniz:

systemctl --user enable --now docker

Sık Karşılaşılan Kısıtlar ve Pratik Çözümler

1) 1024 altı portlara bind etme
Rootless modda düşük portlara (80, 443 gibi) doğrudan bind etmek kısıtlıdır. Çözüm olarak 8080/8443 gibi yüksek portları kullanabilir, ters vekil (reverse proxy) ile yönlendirebilir veya sistemde ilgili capability ayarlarıyla çalışabilirsiniz. Üretimde en temiz yaklaşım genellikle Nginx/Traefik gibi bir ters vekilin 80/443’ü dinlemesi ve konteynerlere yüksek porttan trafik iletmesidir.

2) Ağ performansı ve uyumluluk
Rootless, ağ tarafında çoğunlukla kullanıcı alanı çözümlerine dayanır. Bu, bazı ortamlarda küçük bir performans maliyeti veya farklı davranışlar doğurabilir. Ancak geliştirici makinelerinde ve birçok CI işinde bu fark pratikte sorun yaratmaz.

3) Dosya izinleri ve bind mount
Konteyner içine bağladığınız (bind mount) dizinlerde izin problemleri görebilirsiniz. Rootless mod, host tarafındaki kullanıcı izinleriyle daha “doğal” çalışır; yine de UID/GID uyumsuzluğu olan imajlarda ek ayar gerekebilir. Bu noktada user direktifini kullanmak, uygulamayı konteyner içinde root yerine belirli bir kullanıcıyla çalıştırmak ve volume izinlerini netleştirmek işleri kolaylaştırır.

Güvenlik İçin Ek İpuçları

Rootless kullanıyor olsanız bile güvenlik katmanlarını çoğaltmak iyi bir alışkanlıktır. İmajları mümkünse resmi kaynaklardan çekin, gereksiz paketleri içermeyen minimal imajları tercih edin, gizli anahtarları imaj içine gömmeyin. Konteyner çalıştırırken read-only dosya sistemi, sınırlı yetkiler ve kaynak kotaları gibi seçenekler de saldırı yüzeyini küçültür.

Son olarak, rootless Docker’ı “tek başına her şeyi çözen” bir sihir gibi görmek yerine, doğru senaryoda güçlü bir güvenlik hamlesi olarak değerlendirin. Özellikle paylaşımlı sistemlerde, geliştirici ortamlarında ve otomasyon sunucularında rootless yaklaşımı çoğu zaman daha rahat uyumanızı sağlar.

Sonuç

Rootless Docker, konteyner ekosisteminde güvenliği pratik biçimde artıran modern bir yöntem. Kurulumu birkaç adımda tamamlanıyor; en önemli nokta kullanıcı namespace eşlemeleri ve doğru DOCKER_HOST ayarı. Eğer bugüne kadar Docker’ı “Docker grubuna al, tamam” mantığıyla kullanıyorsanız, rootless moda geçmek özellikle güvenlik hassasiyeti olan ortamlarda ciddi bir iyileştirme sunar.

Windows 11’de WSL2 ile Docker Desktop’sız Container Çalıştırma (Podman ile İleri Seviye Rehber)

Docker Desktop’sız bir konteyner ortamı mümkün mü?

Windows 11 kullanırken konteyner çalıştırmanın “varsayılan” yolu çoğu kişi için Docker Desktop oluyor. Ancak lisanslama tercihleri, kaynak tüketimi ya da daha yalın bir kurulum isteği nedeniyle alternatif arayanların sayısı arttı. Bu yazıda, WSL2 üzerinde Podman kurarak Docker Desktop olmadan konteyner çalıştırmayı adım adım anlatacağım. Yöntem; geliştiriciler, DevOps meraklıları ve yerel ortamda hızlı test yapanlar için güncel, pratik ve ileri seviye sayılabilecek bir çözüm sunuyor.

Ön koşullar: WSL2 ve Linux dağıtımı

Podman’ı Windows’a doğrudan kurup kullanmak yerine, en stabil deneyimi WSL2 içindeki Linux ortamında alırsınız. Windows 11’de WSL2 genellikle hazır gelir; yine de kontrol etmek için PowerShell’i yönetici olarak açıp aşağıdaki komutu kullanabilirsiniz:

wsl --install

Bu komut, varsayılan bir dağıtım kurabilir. Alternatif olarak Microsoft Store’dan Ubuntu 22.04/24.04 gibi bir sürüm seçmek daha kontrollü olur. Kurulumdan sonra dağıtımı açıp kullanıcı oluşturun ve sistemi güncelleyin:

sudo apt update && sudo apt upgrade -y

Podman kurulumu (Ubuntu)

Ubuntu üzerinde Podman kurulumu oldukça basittir. Depo paketleri çoğu senaryoda yeterli olur:

sudo apt install -y podman

Kurulum tamamlandıktan sonra sürümü doğrulayın:

podman --version

Podman’ın önemli farkı şudur: Docker’daki gibi tek bir “daemon”a bağlı olmak zorunda değildir. Bu yaklaşım hem güvenlik hem de mimari sadelik açısından avantaj sağlar. WSL2 üzerinde de bu sadelik hissedilir.

Rootless çalışma ve temel ayarlar

Podman varsayılan olarak rootless (kök yetkisiz) çalışmaya uygundur. Bu, özellikle yerel geliştirme makinesinde iyi bir güvenlik alışkanlığıdır. Rootless ağ ve port yönlendirme konularında bazı kısıtlar olabilir; güncel Podman sürümleri bunu büyük ölçüde kolaylaştırsa da yine de mantığını bilmek önemlidir.

İlk deneme için basit bir “hello world” çalıştırın:

podman run --rm docker.io/library/hello-world

İmaj çekme (pull) sırasında Docker Hub kullanıyorsanız “docker.io/...” şeklinde açık yazmak, ileride registry karmaşasını azaltır. İsterseniz kısa yol olarak şöyle de çalışır:

podman run --rm hello-world

Docker komutlarına alışkın olanlar için: Podman Docker uyumluluğu

Podman, Docker CLI’ye benzer komutları destekler. Hatta çoğu ekipte geçişi kolaylaştırmak için bir “alias” yaklaşımı kullanılır. Örneğin terminal profilinize şu satırı ekleyebilirsiniz:

alias docker=podman

Bu sayede docker run gibi alışık olduğunuz komutlar, arka planda Podman ile çalışır. Tabii ki bu bir alışkanlık konusu; ben özellikle eğitim ve üretim öncesi testlerde komutun gerçekten Podman olduğunu açık tutmayı tercih ediyorum.

Podman ile web servisi çalıştırma (port yayınlama örneği)

Basit bir Nginx konteyneri çalıştırıp Windows’tan tarayıcıyla erişmek iyi bir testtir. WSL2, Windows ile ağ köprüsü kurabildiği için genellikle sorunsuz çalışır:

podman run -d --name webtest -p 8080:80 docker.io/library/nginx:latest

Ardından Windows’ta tarayıcıdan http://localhost:8080 adresini deneyin. Eğer erişimde sorun yaşarsanız, WSL2’nin bazen IP/localhost yönlendirmesinde farklı davrandığını unutmayın. Bu durumda WSL içinden ip addr ile dağıtımın IP’sini kontrol edip o IP üzerinden erişmeyi deneyebilirsiniz.

Podman Compose: Docker Compose alternatifi

Çoklu servis senaryolarında Compose benzeri bir araca ihtiyaç doğar. Podman ekosisteminde bunun karşılığı çoğu zaman podman-compose olur. Ubuntu’da şu şekilde kurabilirsiniz:

sudo apt install -y podman-compose

Ardından proje klasörünüzdeki docker-compose.yml (adı böyle kalabilir) dosyasını şu komutla çalıştırabilirsiniz:

podman-compose up -d

Her Compose dosyası birebir uyumlu olmayabilir; özellikle ağ sürücüleri, volume sürücüleri veya bazı özel Docker özellikleri kullanılıyorsa küçük uyarlamalar gerekebilir. Yine de tipik web+db gibi senaryolarda oldukça tatmin edici sonuç verir.

İmaj yönetimi ve temizlik: Disk alanını kontrol altında tutma

Konteyner dünyasında zamanla biriken imaj katmanları disk tüketimini artırır. Podman’da temel temizlik için şu komutlar işinizi görür:

podman images

podman ps -a

podman system prune -a

Özellikle WSL2 disk imajı büyüyebildiği için arada bir “prune” yapmak iyi bir alışkanlık. Ancak system prune -a kullanılmayan imajları da sileceğinden, sık kullandığınız baz imajların tekrar indirileceğini hesaba katın.

Ne zaman Podman, ne zaman Docker Desktop?

Podman’ın WSL2 üzerinde Docker Desktop’sız çalışması; hafiflik, esneklik ve açık bir mimari isteyenler için güçlü bir seçenek. Buna karşın bazı ekipler Docker Desktop’ın GUI araçlarını, Kubernetes entegrasyonunu veya kurumsal standartlarını tercih edebilir. Benim önerim şu: Yerel geliştirmede hızlı, sade ve script odaklı bir akış istiyorsanız Podman’ı mutlaka deneyin; kurumsal ekip standartlarınız Docker Desktop ise yine de Podman’ı alternatif olarak elinizin altında tutun.

Bu rehberdeki adımlarla Windows 11 üzerinde WSL2 tabanlı, güncel ve ileri seviye sayılabilecek bir konteyner geliştirme ortamını Docker Desktop olmadan kurmuş oldunuz. Bir sonraki adım olarak, CI süreçlerinizde Podman ile imaj build edip registry’ye push etmeyi ve rootless güvenlik ayarlarını derinleştirmeyi düşünebilirsiniz.