WebRTC ile Tarayıcıdan Tarayıcıya Dosya Aktarımı: Sinyal Sunucusu ve Güvenli P2P Akışı Kurulumu

WebRTC ile P2P dosya aktarımı neden hâlâ önemli?

Bulut depolama servisleri pratik ama her zaman ideal değil: büyük dosyalarda yükleme süresi, kota sınırları, bağlantı hızına bağlı gecikmeler ve kimi senaryolarda gizlilik endişeleri devreye giriyor. WebRTC (Web Real-Time Communication) ise tarayıcıların birbirleriyle doğrudan haberleşmesini sağlayarak, arada dosyayı tutan bir “depo” olmadan aktarımı mümkün kılıyor. Bu yazıda, ileri seviye ama uygulanabilir bir yaklaşımla, tarayıcıdan tarayıcıya güvenli P2P dosya transferi için gerekli bileşenleri ve kritik ayarları adım adım ele alacağım.

Mimarinin özeti: Sinyal mi, medya mı?

WebRTC, bağlantıyı “kendi kendine” başlatmaz. İki tarayıcının birbirini bulması ve bağlantı parametrelerini paylaşması için bir sinyal (signaling) kanalına ihtiyacı vardır. Bu kanal genellikle WebSocket ile kurulur. Sinyal sunucusu sadece şu verileri iletir: SDP teklif/yanıtları (offer/answer) ve ICE adayları. Dosyanın kendisi ise ideal durumda RTCDataChannel üzerinden P2P akar.

Özet akış: (1) İstemciler sinyal sunucusuna bağlanır. (2) Bir oda/kimlik üzerinden eşleşir. (3) SDP/ICE alışverişi yapılır. (4) NAT arkasından geçiş için STUN/TURN devreye girer. (5) DataChannel açılır ve dosya parçalı şekilde gönderilir.

Gereksinimler: STUN/TURN, HTTPS ve tarayıcı kısıtları

Modern tarayıcılarda WebRTC çoğu zaman “secure context” ister. Üretimde HTTPS kullanmanız önemlidir (localhost istisna). NAT/kurumsal ağ koşullarında yalnız STUN yetmeyebilir; bu nedenle bir TURN sunucusu kritik bir güvence katmanıdır. TURN, doğrudan bağlantı kurulamadığında trafiği relay eder; bu da maliyetli ama erişilebilirliği artıran bir çözümdür.

Pratik öneri: Geliştirme aşamasında STUN ile başlayın; sahaya çıkarken TURN ekleyin. En çok kullanılan açık kaynak TURN çözümü coturn’dür. Ayrıca aktarımın güvenliği WebRTC’de varsayılan olarak DTLS ile sağlanır; yani DataChannel üzerinde giden veri şifrelenir.

1) Basit bir sinyal sunucusu (Node.js + WebSocket)

Sinyal sunucusunun görevi “mesaj taşımak”tır, dosya aktarmak değil. Basit bir odalı yapı kurgulayabilirsiniz: istemci bir odaya katılır, diğer istemci gelince birbirlerinin mesajlarını iletir. Aşağıdaki yaklaşım üretim için değil, mantığı netleştirmek içindir: tek sunucu, oda eşleşmesi, mesaj yönlendirme.

İpucu: Mesajları tip alanıyla sınıflandırın: offer, answer, ice, join. Böylece istemci tarafı daha okunaklı olur ve hataları ayıklamak kolaylaşır.

2) İstemci tarafı: RTCPeerConnection ve RTCDataChannel

Tarayıcı tarafında iki temel nesne kullanılır: RTCPeerConnection ve RTCDataChannel. PeerConnection, ICE/STUN/TURN ile bağlantıyı kurar; DataChannel ise dosya parçalarını taşır. Buradaki kritik konu, dosyayı tek seferde göndermeye kalkmamak. Büyük bir Blob’u tek mesajla yollamak bellek patlamasına, tarayıcı takılmalarına veya kanal buffer’ının dolmasına yol açabilir.

Sağlıklı yöntem: Dosyayı chunk’lara bölün (örneğin 16 KB–256 KB arası), sırayla gönderin ve backpressure yönetin. WebRTC tarafında bunun için dataChannel.bufferedAmount değerini izleyip belirli eşiğin üstünde beklemek iyi bir pratiktir.

3) Chunk stratejisi, akış kontrolü ve bütünlük

Dosya transferinde üç konu genelde gözden kaçar: akış kontrolü, bütünlük ve yeniden birleştirme. Akış kontrolü için bufferedAmount eşiği belirleyin (ör. 8–16 MB). Bütünlük için en basit yaklaşım: dosya boyutu, parça sayısı, her parçanın indeks bilgisi ve isteğe bağlı hash (ör. SHA-256) gönderin. Yeniden birleştirmede alıcı tarafta parçaları sıraya koyup ArrayBuffer/Blob olarak birleştirin.

Ayrıca DataChannel için iki mod var: ordered (varsayılan) ve unordered. Dosya aktarımında genelde ordered işinizi kolaylaştırır. Paket kaybına dayanıklılık isterseniz, parçaları indeksleyip unordered kullanabilir, eksikleri yeniden isteyebilirsiniz; bu ileri seviye bir iyileştirmedir.

4) ICE yapılandırması: STUN ve TURN örneği

PeerConnection oluştururken ICE sunucularını tanımlarsınız. STUN, dış IP/port keşfine yardım eder; TURN ise relay görevi görür. Kurumsal ağlarda UDP engellenmiş olabilir; TURN’u TCP/TLS ile de sunmak gerekir. Üretimde en çok takılınan yer burasıdır: “Aynı Wi‑Fi’da çalışıyor, dış ağda çalışmıyor.” Sebebi genellikle TURN eksikliği veya yanlış kimlik bilgisidir.

Güvenlik notu: TURN kullanıcı adı/parola bilgilerini statik tutmak yerine zaman kısıtlı (time-limited) kimlik doğrulama kullanmak daha güvenlidir. coturn bu konuda esnektir.

5) Test, hata ayıklama ve performans ipuçları

Test aşamasında önce iki sekme arasında (aynı makine) deneyin; sonra aynı LAN, sonra farklı ağlar. Chrome’da chrome://webrtc-internals sayfası ICE adaylarını, bağlantı durumlarını ve kanal istatistiklerini incelemek için çok değerlidir. Bağlantı kurulamıyorsa genellikle sorun sinyal değil, ICE/TURN tarafındadır.

Performans için öneriler: Chunk boyutunu cihazlara göre ayarlayın, gereksiz kopyalamaları azaltın, alıcı tarafta parçaları birleştirirken bellek kullanımını izleyin. Çok büyük dosyalarda (ör. birkaç GB) tarayıcı sınırlarına yaklaşabilirsiniz; bu durumda indirme/streaming yaklaşımı ve dosya sistemi erişimi (File System Access API) gibi ek teknikler gündeme gelir.

Sonuç: Bulutsuz paylaşım için sağlam bir temel

WebRTC ile tarayıcıdan tarayıcıya dosya aktarımı, doğru kurgulandığında hem hızlı hem de şifreli bir deneyim sunar. Bu işin kalbi dosyayı taşımaktan çok, bağlantıyı güvenilir biçimde kurmaktır: sinyal sunucusu basit kalabilir, fakat ICE/STUN/TURN ayarları ve chunk tabanlı aktarım stratejisi projenin başarısını belirler. Buradaki yaklaşımı bir temel olarak alıp; oda yönetimi, kimlik doğrulama, yeniden deneme mekanizmaları ve transfer ilerleme göstergesi gibi parçalarla üretim seviyesine rahatça taşıyabilirsiniz.

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.

Cloudflare Zero Trust ile Uygulamalarını İnternete Açmadan Yayına Al: Tunnel Kurulumu ve İnce Ayarlar

İnternete Port Açmadan Yayınlamak Neden Önemli?

Evde ya da küçük bir ofiste bir web paneli, API, yönetim arayüzü veya test ortamı çalıştırıyorsanız “router’dan port yönlendirme” genellikle ilk akla gelen yöntem olur. Ancak bu yaklaşım, servisinizin doğrudan internete açılması demektir: zafiyet taramaları, brute force denemeleri ve yanlış yapılandırmalar bir anda ciddi bir güvenlik riskine dönüşebilir. Modern yaklaşım, uygulamayı dış dünyaya “açmadan” erişilebilir kılmak ve erişimi kimlik doğrulama politikalarıyla kontrol etmektir.

Bu yazıda Cloudflare Zero Trust ekosisteminin en pratik parçalarından biri olan Cloudflare Tunnel (cloudflared) ile, içeride çalışan bir servisi port açmadan dışarıya yayınlamayı anlatacağım. Ayrıca gerçek hayatta iş gören ayarları: alt alan adı yönlendirme, erişim politikaları, HTTPS davranışı ve temel sorun giderme adımlarını da ekleyeceğim.

Cloudflare Tunnel Nedir, Ne İşe Yarar?

Cloudflare Tunnel, içerideki sunucunuzdan Cloudflare ağına doğru çıkış yönlü (outbound) bir tünel kurar. Yani modeminizde inbound port açmazsınız. cloudflared arka planda Cloudflare’a bağlanır; ziyaretçi tarafında gelen istekler Cloudflare üzerinden bu tünelden iç servisinize iletilir. Böylece hem saldırı yüzeyi küçülür hem de Cloudflare’ın WAF, rate limit, Access politikaları gibi katmanları devreye alınabilir.

Ön Koşullar

1) Cloudflare’da yönetebildiğiniz bir alan adı (domain) 2) Cloudflare Zero Trust paneline erişim (ücretsiz plan çoğu senaryo için yeterli) 3) İç ağınızda yayınlanan bir servis: örneğin http://localhost:3000 veya http://192.168.1.50:8080 4) Linux/Windows/macOS üzerinde çalışacak bir makine (tüneli bu makine kuracak)

Adım Adım Kurulum (Zero Trust Panel Üzerinden)

1) Zero Trust’a girin: Cloudflare Dashboard > Zero Trust. Sol menüden Access veya Networks altından Tunnels bölümünü bulun.

2) Yeni tünel oluşturun: “Create a tunnel” deyin, tünele anlamlı bir isim verin (ör. ev-lab).

3) cloudflared kurun: Cloudflare, işletim sisteminize göre komutları ekranda gösterir. Linux için çoğunlukla paket deposu veya tek ikili (binary) ile kurulum sağlanır. Kurulumdan sonra, panelin verdiği komutla tüneli makinenize “bağlarsınız”. Bu adım, makinenizde kimlik doğrulaması yaparak tüneli Cloudflare hesabınıza iliştirir.

4) Public Hostname tanımlayın: Tünelin “Public Hostname” kısmında bir alt alan adı seçin. Örneğin panel.orneksite.com. “Service” bölümüne ise içerideki hedefi yazın: örneğin http://localhost:3000 ya da http://192.168.1.50:8080. Bu noktadan sonra Cloudflare, gelen trafiği tünel üzerinden doğru servise yönlendirmeyi bilir.

HTTPS, Origin ve Güvenli Varsayılanlar

Cloudflare tarafında kullanıcılar genellikle HTTPS ile bağlanır. İçerideki servisiniz HTTP çalışıyor olabilir; bu sorun değildir. Cloudflare, edge’de HTTPS sonlandırıp tünel üzerinden HTTP ile iletebilir. Yine de hassas bir panel yayınlıyorsanız, içeride de TLS kullanmak veya en azından erişimi Cloudflare Access ile kilitlemek iyi fikirdir.

Ek bir güvenlik adımı olarak, panel yayınlıyorsanız Cloudflare WAF kuralları, bot koruması ve rate limit seçeneklerine göz atın. Tunnel kullanmak tek başına “güvenli” anlamına gelmez; yetkisiz erişimi engelleyecek politika katmanı şarttır.

Cloudflare Access ile Kim Girebilir? (Gerçek Hayat Senaryosu)

En güçlü taraflardan biri, uygulamanıza giriş için IP whitelist yerine kimlik tabanlı kontrol sunmasıdır. Örneğin sadece Google Workspace hesabınızla giriş yapılmasını isteyebilirsiniz.

1) Zero Trust > Access > Applications > “Add an application” (Self-hosted seçin). 2) Uygulama alan adını seçin (ör. panel.orneksite.com). 3) Policy oluşturun: “Allow” ve şart olarak e-posta domain’i, belirli e-posta adresleri veya bir kimlik sağlayıcı grubu ekleyin. 4) İsterseniz ek doğrulama (MFA) koşulları ekleyin.

Bu sayede uygulamanız internete açık görünse bile, içeri girmek için kullanıcı Cloudflare Access ekranından geçmek zorunda kalır. Özellikle admin panelleri, Home Assistant, Grafana, Portainer, Git servisleri gibi araçlarda bu yaklaşım port açmaya göre çok daha kontrollüdür.

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

403/Access ekranı gelmiyor: Access uygulaması doğru hostname’e bağlandı mı kontrol edin. DNS kaydı Cloudflare proxy (turuncu bulut) arkasında mı? Tunnel tarafında “Public Hostname” doğru mu?

502/Bad Gateway: Tünel ayakta olsa bile içeride hedef servis yanıt vermiyor olabilir. Makinede curl http://localhost:3000 gibi bir test yapın. Hedef IP/port doğru mu, servis sadece 127.0.0.1’e mi bağlı, güvenlik duvarı trafiği kesiyor mu kontrol edin.

Performans dalgalanması: Aynı tüneli birden fazla “connector” ile çoğaltmak (yük devretme) mümkün. Kritik servislerde tüneli iki farklı makinede çalıştırarak kesintiye dayanıklılığı artırabilirsiniz.

Ne Zaman Tercih Etmelisiniz?

Cloudflare Tunnel; ev lab ortamları, küçük ekiplerin dahili araçları, müşteri demosu, staging ortamları ve port açmanın kurumsal politikalarla engellendiği senaryolarda çok iyi çalışır. “Hızlıca yayınla, sonra erişimi kilitle” yaklaşımı için idealdir. Buna karşın çok özel ağ topolojileri, L4 seviyesinde özel protokoller veya uçtan uca sertifikalı mTLS gibi gereksinimler varsa tasarımı biraz daha detaylı düşünmek gerekir.

Sonuç

Cloudflare Zero Trust + Tunnel ikilisi, klasik port yönlendirme yöntemini büyük ölçüde gereksiz kılıyor. En önemli kazanım, uygulamayı internete açmadan erişilebilir hale getirirken kimlik doğrulama ve politika katmanını işin merkezine koyması. Bir kez kurduktan sonra yeni servis eklemek de oldukça pratik: yalnızca yeni bir hostname ve hedef servis tanımlıyorsunuz, gerisini tünel taşıyor.

Ev Ağında DNS-over-HTTPS (DoH) Kurulumu: Pi-hole + Unbound ile Reklamsız ve Daha Güvenli DNS

DNS neden hâlâ önemli?

İnternette bir siteye girdiğinizde tarayıcınız önce alan adını (ör. ornek.com) bir IP adresine çevirir. Bu çeviri işlemini DNS yapar. Sorun şu: Klasik DNS trafiği çoğu ağda şifresizdir ve hem ISS düzeyinde hem de aynı ağdaki kötü niyetli bir kişi tarafından gözlemlenebilir. Ayrıca reklam, izleyici ve zararlı alan adlarını engellemek için merkezi bir DNS filtreleme yaklaşımı, tüm cihazlarda tek tek eklenti kurmaktan daha temiz bir çözüm sunar.

Bu rehberde ne kuruyoruz?

Bu “How-To” yazısında ev/Ofis ağında Pi-hole ile reklam/izleyici alan adlarını engelleyen bir DNS filtresi, Unbound ile yerel recursive DNS çözümleyici ve dışarıya çıkarken DNS-over-HTTPS (DoH) kullanarak şifreli DNS trafiği kuracağız. Hedef: ağdaki tüm cihazlar için daha hızlı, daha gizli ve daha az reklamlı bir deneyim. Kurulum örnekleri Debian/Ubuntu tabanlı bir mini PC veya Raspberry Pi üzerinde ilerleyecek.

Ön koşullar

Donanım: Raspberry Pi 3/4 veya düşük güç tüketimli bir mini PC idealdir. Yazılım: Debian/Ubuntu türevi bir Linux, root/sudo erişimi. Ağ: Cihaza statik IP atamanız önerilir (ör. 192.168.1.2). Ayrıca modem/router arayüzüne girip DHCP DNS ayarını değiştirebilmeniz gerekir.

1) Pi-hole kurulumu

Pi-hole kurulumunu resmi script ile yapmak en pratik yöntemdir. Sunucunuzda terminali açın ve güncelleme sonrası kurulumu başlatın:

Komutlar:
sudo apt update && sudo apt upgrade -y
curl -sSL https://install.pi-hole.net | bash

Kurulum sihirbazında ağ arayüzünü seçin, statik IP önerisini kabul edin ve yönetim paneli için parolayı not edin. Kurulum sonunda Pi-hole web paneli genellikle http://cihaz-ip/admine üzerinden erişilir. İlk etapta upstream DNS olarak geçici bir sağlayıcı seçebilirsiniz; birazdan bunu Unbound’a yönlendireceğiz.

2) Unbound ile yerel recursive DNS

Unbound, sorguları doğrudan kök DNS sunucularına kadar takip ederek çözen yerel bir recursive çözümleyicidir. Böylece tek bir harici DNS sağlayıcısına bağımlılığınız azalır ve önbellek avantajı elde edersiniz:

Kurulum:
sudo apt install unbound -y

Pi-hole ile çakışmaması için Unbound’u yerelde farklı bir portta çalıştırmak iyi bir pratiktir. Örnek bir Unbound yapılandırması oluşturun:

Dosya: /etc/unbound/unbound.conf.d/pi-hole.conf
İçerik:
server:
  verbosity: 0
  interface: 127.0.0.1
  port: 5335
  do-ip4: yes
  do-udp: yes
  do-tcp: yes
  root-hints: "/var/lib/unbound/root.hints"
  cache-min-ttl: 300
  cache-max-ttl: 86400
  hide-identity: yes
  hide-version: yes
  qname-minimisation: yes

Root hints dosyasını indirip servisi başlatın:

Komutlar:
sudo curl -o /var/lib/unbound/root.hints https://www.internic.net/domain/named.cache
sudo systemctl enable --now unbound
sudo systemctl restart unbound

3) DoH katmanı: şifreli DNS çıkışı

Burada iki yaklaşım var: (A) Unbound’u doğrudan recursive kullanmak ve sadece “dış DNS sağlayıcıya” gitmemek; (B) Mutlaka bir sağlayıcıya gidecekseniz bunu DoH ile yapmak. Bu yazıda pratikliği nedeniyle cloudflared (DoH proxy) örneğini kullanacağız. Böylece Pi-hole → Unbound yerine Pi-hole → DoH proxy veya Unbound → DoH proxy senaryosu kurulabilir. En yaygın kullanım, Pi-hole’un upstream DNS’ini DoH proxy’ye vermektir.

cloudflared kurulumu (Debian/Ubuntu):
sudo apt install cloudflared -y

cloudflared’ı yerelde DNS proxy olarak çalıştırın (ör. 127.0.0.1:5053):

Komut:
sudo cloudflared proxy-dns --address 127.0.0.1 --port 5053 --upstream https://1.1.1.1/dns-query --upstream https://1.0.0.1/dns-query

Bunu kalıcı servis yapmak için dağıtımınıza uygun systemd birim dosyası oluşturabilir veya cloudflared paketinin servis seçeneklerini kullanabilirsiniz. Mantık basit: DNS sorguları yerelden çıkar, HTTPS içinde şifrelenmiş şekilde DoH sağlayıcısına gider.

4) Pi-hole’u Unbound veya DoH’a yönlendirme

Pi-hole yönetim panelinde Settings > DNS bölümüne gidin. Burada hazır DNS sağlayıcılarını kapatıp Custom (IPv4) alanına bir upstream tanımlayın:

Seçenek 1 (Recursive): 127.0.0.1#5335 (Unbound)
Seçenek 2 (DoH): 127.0.0.1#5053 (cloudflared)

İkisini aynı anda kullanacaksanız mimariyi netleştirin: ya Pi-hole doğrudan Unbound’a gider (en bağımsız yaklaşım), ya Pi-hole doğrudan DoH proxy’ye gider (en basit şifreleme). “Unbound + DoH” birlikte de yapılabilir; ancak yapılandırma karmaşıklığı artar ve hata ayıklamak zorlaşır.

5) Router/DHCP ayarı: tüm ağa yayma

Amaç, ev ağındaki tüm cihazların DNS olarak Pi-hole’u kullanmasıdır. Router arayüzünde DHCP DNS sunucusunu Pi-hole IP adresi (ör. 192.168.1.2) yapın. Alternatif olarak DHCP’yi Pi-hole’un yönetmesine izin verebilirsiniz; fakat çoğu ev ağında router DHCP’si üzerinden DNS dağıtmak daha sorunsuzdur.

Test ve doğrulama

İstemci cihazınızda DNS sunucusunun Pi-hole’a döndüğünü kontrol edin. Ardından Pi-hole panelinde Query Log akışını izleyin. DoH doğrulaması için cloudflared loglarını takip edebilir veya dış DNS sorgularınızın 443 portu üzerinden çıktığını ağ izleme araçlarıyla gözlemleyebilirsiniz. Bir başka pratik test: reklam ağırlıklı bir sitede sayfa yükleme süreleri ve reklam sayısı belirgin biçimde azalmalıdır.

Sık karşılaşılan sorunlar

İnternet gidiyor, DNS çözemiyor: Router’da hâlâ ikinci DNS olarak ISS’nin DNS’i kalmış olabilir; cihazlar bazen onu seçer. DHCP DNS alanında yalnızca Pi-hole IP’si kaldığından emin olun.
Bankacılık/akış servisleri bozuldu: Bazı engelleme listeleri agresif olabilir. Pi-hole’da ilgili alan adını whitelist’e alın veya listeyi değiştirin.
DoH proxy çalışmıyor: 5053 portunu başka bir servis kullanıyor olabilir; portu değiştirip Pi-hole’daki custom upstream’i güncelleyin.

Sonuç

Pi-hole ile ağ genelinde reklam ve izleyici engellemek, günlük internet deneyimini gözle görülür şekilde iyileştirir. Üstüne Unbound ile recursive çözümleme eklediğinizde daha bağımsız ve tutarlı bir DNS altyapısı elde edersiniz. DoH kullanımı ise DNS trafiğini şifreleyerek ağdaki pasif izlemeyi zorlaştırır. Bu üçlüden hangisini seçeceğiniz ihtiyaçlarınıza bağlı; ancak ev ağı için “Pi-hole + DoH” en hızlı kazanım sağlayan, “Pi-hole + Unbound” ise en bağımsız yaklaşım olarak öne çıkar.

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.