4 Ocak 2026 Pazar

Windows 11’de WSL 2 + Docker ile Yerel Geliştirme Ortamı Kurulumu (Adım Adım)

Giriş: Neden WSL 2 + Docker?

Windows üzerinde yazılım geliştirenlerin en büyük şikâyetlerinden biri, Linux tabanlı araçlarla uyumlu ve hızlı bir ortamı stabil şekilde kurmanın zor olmasıydı. Windows Subsystem for Linux (WSL) 2 bu tabloyu ciddi şekilde değiştirdi. WSL 2, gerçek bir Linux çekirdeğiyle çalıştığı için performans ve uyumluluk açısından eski yöntemlere göre çok daha iyi. Buna Docker’ı eklediğinizde; Node.js, Python, Go, PostgreSQL, Redis gibi bileşenleri “makinenizi kirletmeden” konteynerlerle yönetebilir, projeleri daha taşınabilir hale getirebilirsiniz. Bu yazıda Windows 11 üzerinde WSL 2 + Docker ile modern bir yerel geliştirme ortamını adım adım kuracağız.

Ön Koşullar

Kuruluma başlamadan önce Windows 11’in güncel olduğundan emin olun. Ayrıca BIOS/UEFI tarafında sanallaştırma (Intel VT-x / AMD-V) açık olmalı. Eğer daha önce sanallaştırma tabanlı bir yazılım (eski VirtualBox yapılandırmaları gibi) sorun çıkardıysa, kurulum sırasında çakışma ihtimalini göz önünde bulundurun.

1) WSL 2 Kurulumu (Tek Komutla)

En pratik yöntem, Windows Terminal veya PowerShell’i Yönetici olarak açıp şu komutu çalıştırmaktır:

wsl --install

Bu komut WSL bileşenlerini kurar, varsayılan Linux dağıtımını indirir ve gerekli ayarları yapar. İşlem sonrası yeniden başlatma istenirse mutlaka yeniden başlatın. Kurulum tamamlandığında dağıtım ilk açılışta sizden bir Linux kullanıcı adı ve parola belirlemenizi isteyecek.

2) Varsayılan Dağıtımı ve Sürümü Kontrol Etme

Kurulumdan sonra WSL dağıtımlarını ve hangi sürümde çalıştıklarını görmek için:

wsl -l -v

Burada dağıtımınızın sürümü 2 görünmelidir. Eğer 1 görünüyorsa (bazı eski sistemlerden yükseltmelerde olabiliyor), şu komutla WSL 2’ye dönüştürebilirsiniz:

wsl --set-version Ubuntu 2

“Ubuntu” yerine listede gördüğünüz dağıtım adını yazın.

3) Docker Kurulumu: Docker Desktop + WSL Entegrasyonu

Windows 11 üzerinde en sorunsuz seçenek genellikle Docker Desktop kullanmaktır. Docker Desktop’ı kurduktan sonra ayarlarda WSL entegrasyonunu açmanız gerekir. Docker Desktop içinde:

Settings > Resources > WSL Integration bölümüne gidin ve kullandığınız Linux dağıtımı için entegrasyonu etkinleştirin.

Bu sayede Docker komutlarını doğrudan WSL terminalinden çalıştırabilir, Linux ortamında konteyner yönetimini çok daha doğal bir şekilde yapabilirsiniz.

4) WSL İçinde Gerekli Paketleri Güncelleme

Ubuntu (veya kullandığınız dağıtım) terminalini açın ve paketleri güncelleyin:

sudo apt update && sudo apt upgrade -y

Geliştirme araçlarını sıklıkla kullanacaksanız temel araç seti de işinize yarar:

sudo apt install -y build-essential git curl

5) Test: Docker WSL İçinde Çalışıyor mu?

WSL terminalinde şu komutla Docker’ın doğru çalıştığını doğrulayın:

docker version

Ardından basit bir konteyner test edebilirsiniz:

docker run --rm hello-world

Bu komut, Docker’ın imaj çekme ve çalıştırma adımlarının sorunsuz olduğunu gösterir.

6) Örnek Proje: docker-compose ile PostgreSQL + Redis

Gerçek bir geliştirme senaryosunda genelde veritabanı ve önbellek servislerini konteynerle yönetmek istersiniz. Proje klasörünüzde docker-compose.yml dosyası oluşturup aşağıdaki yapıyı kullanabilirsiniz (örnek):

services:
postgres:
image: postgres:16
environment:
POSTGRES_PASSWORD: example
ports:
- "5432:5432"
redis:
image: redis:7
ports:
- "6379:6379"

Konteynerleri ayağa kaldırmak için:

docker compose up -d

Durdurmak için:

docker compose down

Bu yaklaşımın en güzel tarafı, proje klasörünü başka bir makineye taşıdığınızda aynı servislerin neredeyse aynı komutlarla ayağa kalkmasıdır.

7) Performans İpucu: Projeyi WSL Dosya Sisteminde Tutun

WSL ile çalışırken en kritik performans noktalarından biri proje dosyalarının nerede durduğudur. Özellikle Node.js gibi çok fazla küçük dosya okuyan araçlar kullanıyorsanız, projeyi Windows diskinde (ör. C:\) tutmak yerine WSL tarafındaki Linux dosya sisteminde (ör. /home/kullanici/proje) tutmak ciddi hız kazandırır. Editör olarak VS Code kullanıyorsanız, “WSL” uzantısıyla projeyi WSL içinde açmak da iş akışını kolaylaştırır.

Kapanış: Daha Temiz, Daha Taşınabilir Bir Geliştirme Düzeni

Windows 11 üzerinde WSL 2 ve Docker birlikte kullanıldığında, hem Linux uyumlu araçların rahatlığını hem de Windows ekosisteminin pratikliğini bir arada alırsınız. Üstelik projeleriniz “benim bilgisayarımda çalışıyor” sorununa daha az takılır; çünkü servisleri konteynerlerle standartlaştırırsınız. Bu kurulumdan sonra CI/CD, özel ağlar, multi-container mikroservis geliştirme ve hatta Kubernetes denemeleri gibi daha ileri senaryolara geçmek çok daha kolay hale gelir.

3 Ocak 2026 Cumartesi

WebAssembly (Wasm) ile Node.js Performansını Artırma: Rust ile Hızlı Modül Geliştirme Rehberi

WebAssembly neden gündemde?

Node.js ekosistemi pratikliğiyle ünlü ama bazı işlerde “kolay” her zaman “hızlı” anlamına gelmiyor. Özellikle JSON işleme, sıkıştırma, görüntü/ham veri dönüştürme, kriptografi veya matematiksel hesaplar gibi CPU ağırlıklı senaryolarda JavaScript tek başına sınıra dayanabiliyor. WebAssembly (Wasm) burada devreye giriyor: Rust gibi sistem dilleriyle yazılmış kodu Wasm’a derleyip Node.js içinden çalıştırarak performansı hissedilir biçimde artırmak mümkün.

Bu yazıda ileri seviye ama uygulanabilir bir yaklaşımı ele alacağız: Rust ile Wasm modülü yazıp Node.js projesine entegre etmek. Hedefimiz “her şeyi Wasm’a taşıyalım” değil; darboğaz olan parçaları tespit edip kritik fonksiyonları hızlandırmak.

Ne zaman Wasm kullanmalı?

Wasm, her sorunun sihirli çözümü değil. Aşağıdaki durumlarda özellikle anlamlı olur: çok sayıda tekrar eden hesap (ör. hashing, parsing, diff), büyük veri üzerinde döngüler, yüksek frekanslı çağrılan saf fonksiyonlar ve GC baskısı oluşturan işlemler. Buna karşılık, ağ I/O ağırlıklı API’larda veya veritabanı bekleme süresi baskınken Wasm’a geçiş beklediğiniz kazanımı getirmeyebilir.

Bir kural: Önce ölçün. Node.js tarafında --prof, clinic.js veya yerleşik CPU profilleyicilerle darboğazı doğrulamadan Wasm’a koşmak genelde gereksiz karmaşıklık yaratır.

Kurulum: Rust ve wasm-pack

Bu rehberde Rust tarafında wasm-pack aracını kullanacağız. Node.js ile entegrasyon için en pratik yollardan biri. Gerekenler: güncel Node.js (LTS), Rust toolchain ve wasm-pack.

Rust kurulumu: Rust’ı resmi yöntemle kurduktan sonra wasm-pack yükleyin. Komut satırında: cargo install wasm-pack. Ardından projenizi oluşturacağız.

Adım adım: Rust ile Wasm modülü yazma

Örnek olarak CPU’yu yoran ama anlaşılır bir iş seçelim: büyük bir dizide basit istatistik (toplam ve ortalama) hesaplamak. Elbette gerçek hayatta daha karmaşık algoritmalar daha iyi kazanç sağlar; amaç süreçleri göstermek.

Yeni bir Rust-Wasm paketi oluşturun: wasm-pack new faststats. Klasör içine girip src/lib.rs dosyasını düzenleyin. Rust tarafında JavaScript’ten veri alırken kopyalama maliyetlerine dikkat etmek gerekir; mümkünse TypedArray yaklaşımı tercih edilir. wasm-bindgen ile gelen veri türlerini kontrollü kullanacağız.

Temel bir örnek mantık: JavaScript’ten Float64Array gönderip Rust’ta döngüyle toplamı hesaplayacağız. Dönüşte toplam ve ortalamayı tek bir yapı olarak dönmek yerine, sade kalması için JSON benzeri bir nesne döndürmek yerine iki sayıyı ayrı döndürmek veya küçük bir struct kullanmak mantıklıdır. wasm-bindgen, basit türlerde daha verimli çalışır.

Derleme: Node.js hedefi ile paketleme

Derleme için: wasm-pack build --target nodejs komutunu kullanın. Bu işlem pkg klasöründe Node.js’in içe aktarabileceği bir sarmalayıcı ve .wasm

Projeyi bir monorepo gibi kullanabilir veya üretilen paketi ana Node.js projenize kopyalayabilirsiniz. Daha temiz yöntem, Rust tarafını ayrı paket tutup ana projede dosya bağımlılığıyla kullanmaktır.

Node.js tarafında kullanım

Node.js projenizde üretilen paketi içe aktarın. Eğer aynı repo içindeyseniz, örneğin ./faststats/pkg yolundan import edebilirsiniz. Ardından Float64Array oluşturup Wasm fonksiyonunu çağırın. Bu noktada iki şeye dikkat edin: veri kopyalama ve çağrı sıklığı. Çok küçük dizilerde veya çok seyrek çağrılarda Wasm köprüsünün maliyeti kazancı gölgeleyebilir.

Pratik bir yaklaşım: veriyi parça parça göndermek yerine tek seferde daha büyük bloklar halinde işlemek. Ayrıca Rust tarafında gereksiz bellek tahsisi yapmamak. Wasm modülleri hız sağlar, ama yanlış veri akışı tasarımı tüm kazanımı yiyebilir.

Performans ölçümü: Gerçekçi benchmark

Performansı değerlendirirken “tek bir çalıştırma” yerine, ısınma etkisini ve JIT davranışını göz önüne alan bir ölçüm yapın. Basitçe process.hrtime.bigint() ile süre ölçebilirsiniz. Aynı işi saf JavaScript ile ve Wasm ile yaptığınız iki senaryoyu karşılaştırın. Önemli olan sadece ortalama süre değil; p95/p99 gecikmeleri de fark yaratır.

Wasm’ın en güçlü olduğu yerlerden biri de deterministik performanstır: GC dalgalanmalarını azaltabilir. Özellikle yoğun hesap yapan servislerde daha stabil gecikme dağılımları elde edebilirsiniz.

Sık yapılan hatalar ve ipuçları

1) Her şeyi Wasm’a taşımak: Uygulamanın tamamını Wasm’a geçirmek yerine sadece sıcak noktaları hedefleyin. 2) Küçük fonksiyonları çok sık çağırmak: Köprü maliyeti artar; daha büyük iş parçaları tasarlayın. 3) Yanlış veri türü seçmek: String alışverişi maliyetlidir; mümkünse binary/TypedArray kullanın. 4) Hata ayıklamayı zorlaştırmak: Rust tarafında basit loglama ve testler ekleyin; Node tarafında da giriş doğrulaması yapın.

Ek bir öneri: Eğer amacınız Node.js’e “native hız” kazandırmaksa Wasm tek seçenek değil. N-API ile C/C++ eklentileri veya Rust tabanlı native modüller de güçlüdür. Ancak Wasm, taşınabilirlik ve dağıtım kolaylığı açısından birçok projede daha sürdürülebilir bir yol sunar.

Sonuç

WebAssembly, Node.js projelerinde performans darboğazlarını kırmak için modern ve pratik bir araç. Rust ile yazıp wasm-pack ile paketleyerek, kritik hesaplama fonksiyonlarını güvenli ve hızlı bir şekilde Node.js’e taşıyabilirsiniz. Doğru senaryoda, daha düşük CPU kullanımı ve daha stabil gecikmeler elde etmek mümkün. En iyi sonuç için profilleme yapın, veri geçişini optimize edin ve Wasm’ı “cerrahi” bir hızlandırma katmanı gibi konumlandırın.

2 Ocak 2026 Cuma

Windows 11’de WSL 2 ile Docker Desktop Kullanmadan Docker Çalıştırma (Adım Adım Rehber)

Docker Desktop olmadan neden Docker?

Windows 11’de Docker kullanmak isteyenlerin ilk karşılaştığı çözüm genellikle Docker Desktop oluyor. Ancak lisans koşulları, arka planda tükettiği kaynaklar ve zaman zaman “WMI/Hyper-V/servis” kaynaklı sorunlar nedeniyle daha hafif ve kontrol edilebilir bir kurulum tercih edilebilir. Bu yazıda, WSL 2 üzerinde Ubuntu (veya benzeri bir dağıtım) kurup, Docker Engine’i doğrudan Linux tarafında çalıştırarak Windows’ta Docker deneyimini nasıl elde edeceğinizi anlatıyorum. Sonuçta konteynerlar Linux çekirdeği üzerinde, daha “doğal” bir şekilde çalışır; siz de Windows’tan terminal ve IDE ile yönetirsiniz.

Ön koşullar

Bu rehber Windows 11 içindir ve WSL 2 gerektirir. Yönetici yetkisi olan bir Windows hesabı işinizi kolaylaştırır. Ayrıca sanallaştırmanın BIOS/UEFI tarafında açık olması (Intel VT-x/AMD-V) önemlidir. Adımlara başlamadan önce, Windows Update’in güncel olması da olası WSL hatalarını azaltır.

1) WSL 2 ve Ubuntu kurulumu

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

wsl --install

Bu komut genellikle WSL’yi etkinleştirir ve varsayılan bir Linux dağıtımı kurar. Eğer dağıtım seçmek isterseniz, mevcut dağıtımları listeleyebilirsiniz:

wsl --list --online

Ardından örneğin Ubuntu kurmak için:

wsl --install -d Ubuntu

Kurulum sonrası Ubuntu ilk kez açıldığında sizden bir Linux kullanıcı adı ve parola belirlemeniz istenir. Bu kullanıcı, Docker komutlarını daha sonra “sudo” ile çalıştırmanız gereken temel kullanıcı olacaktır.

2) Docker Engine’i WSL içinde kurma

Ubuntu terminali açıldıktan sonra önce paket listesini güncelleyin:

sudo apt update && sudo apt upgrade -y

Docker’ın resmi deposunu eklemek en sorunsuz yoldur. Gerekli paketleri kurun:

sudo apt install -y ca-certificates curl gnupg

Ardından Docker GPG anahtarını ve repo bilgisini ekleyin (Ubuntu sürümünüze göre uyumlu şekilde):

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 Engine ve gerekli bileşenleri kurun:

sudo apt update

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

3) WSL’de Docker servisinin çalıştırılması

WSL, klasik Linux dağıtımları gibi her zaman systemd ile başlamayabilir. Güncel Windows 11 ve WSL sürümlerinde systemd desteği var; bunu etkinleştirmek için Ubuntu içinde şu dosyayı oluşturun/düzenleyin:

sudo nano /etc/wsl.conf

İçine şunu ekleyin:

[boot]
systemd=true

Kaydedip çıkın. Sonra Windows tarafında WSL’yi yeniden başlatın:

wsl --shutdown

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

sudo systemctl enable docker

sudo systemctl start docker

sudo systemctl status docker

4) Sudo’suz Docker kullanmak (opsiyonel ama pratik)

Her seferinde “sudo” yazmamak için kullanıcıyı docker grubuna ekleyebilirsiniz:

sudo usermod -aG docker $USER

Değişikliğin geçerli olması için Ubuntu oturumunu kapatıp açın. Ardından test edin:

docker run --rm hello-world

Bu komut başarıyla çalışıyorsa Docker Engine WSL içinde hazır demektir.

5) Docker Compose ve örnek proje

Docker Compose artık çoğu kurulumda eklenti olarak gelir. Sürümü kontrol edin:

docker compose version

Hızlı bir örnek olarak Nginx ayağa kaldırabilirsiniz:

docker run --rm -p 8080:80 nginx

Windows’ta tarayıcıdan http://localhost:8080 açtığınızda Nginx sayfasını görmeniz gerekir. Bu, WSL-Linux konteyner ağının Windows’a düzgün biçimde köprülenebildiğini de doğrular.

Performans ve dosya sistemi ipuçları

WSL 2 ile Docker kullanırken en kritik noktalardan biri proje dosyalarının nerede tutulduğudur. Yoğun dosya erişimi yapan Node.js, Python veya PHP projelerinde, kaynak kodunu WSL dosya sistemi içinde (ör. /home/kullanici/proje) tutmak genellikle çok daha hızlıdır. Windows sürücülerine (ör. /mnt/c) yerleştirilmiş projeler bazı senaryolarda belirgin yavaşlayabilir. IDE kullanıyorsanız Visual Studio Code’un Remote - WSL eklentisiyle projeyi WSL içinde açmak hem hız hem de araç uyumluluğu açısından iyi bir çözümdür.

Sık karşılaşılan sorunlar

“Cannot connect to the Docker daemon” hatası alırsanız önce Docker servisinin çalıştığını doğrulayın: systemctl status docker. systemd etkin değilse /etc/wsl.conf ayarını kontrol edin ve wsl --shutdown ile WSL’yi tamamen kapatıp açın.

Port çakışması durumunda (ör. 8080 doluysa) farklı bir port seçin: -p 8081:80. Ayrıca Windows güvenlik duvarı ve kurumsal ağ politikaları bazı port erişimlerini kısıtlayabilir.

Sonuç

Bu yöntemle Windows 11 üzerinde Docker Desktop kurmadan, daha minimal bir kurulumla Docker Engine’i WSL 2 içinde çalıştırabilirsiniz. Özellikle geliştirici makinesinde kaynak tüketimini azaltmak, lisans tartışmalarına takılmamak ve Linux’a daha yakın bir çalışma ortamı elde etmek isteyenler için oldukça mantıklı bir seçenek. Kurulum tamamlandığında hem docker hem de docker compose komutlarıyla modern konteyner iş akışınızı rahatça sürdürebilirsiniz.

1 Ocak 2026 Perşembe

Windows 11’de WSL 2 ile Docker Desktop Olmadan Docker Kurulumu ve Sorunsuz Çalıştırma Rehberi

Docker’ı Docker Desktop olmadan kullanmak neden mantıklı?

Windows 11 üzerinde Docker denince çoğu kişinin aklına doğrudan Docker Desktop geliyor. Ancak özellikle kurumsal lisans koşulları, sistem kaynak tüketimi veya daha “hafif” bir geliştirme ortamı arayanlar için Docker Desktop’sız bir kurulum oldukça cazip. İyi haber: WSL 2 (Windows Subsystem for Linux) sayesinde Windows içinde gerçek bir Linux çekirdeği üzerinde Docker Engine çalıştırmak mümkün. Bu rehberde, Windows 11’de WSL 2 kurulumunu doğrulayıp bir Linux dağıtımı üzerinde Docker Engine kuracak, ağ ve servis ayarlarını yapacak ve günlük kullanım için pratik ipuçlarını paylaşacağım.

Ön koşullar ve genel yaklaşım

Bu yöntem, Docker Engine’i Windows’a değil, WSL 2 içindeki Linux’a kurar. Böylece konteynerler Linux ortamında çalışır, siz ise Windows’tan veya WSL terminalinden komut gönderirsiniz. İhtiyacınız olanlar: Windows 11, yönetici yetkisi, bir WSL dağıtımı (Ubuntu önerilir) ve temel terminal kullanımı. Kurulum adımlarını mümkün olduğunca sade tuttum, ama sorun yaşamamanız için kritik noktalara özellikle değineceğim.

1) WSL 2’yi kurma ve doğrulama

PowerShell’i Yönetici olarak açın ve WSL’yi kurun:

Komut: wsl --install

Sistem sizden yeniden başlatma isteyebilir. Kurulumdan sonra yüklü dağıtımları ve WSL sürümünü kontrol edin:

Komut: wsl -l -v

Listede Ubuntu (veya seçtiğiniz dağıtım) görünmeli ve VERSION alanında 2 yazmalıdır. Eğer 1 ise şunu çalıştırabilirsiniz:

Komut: wsl --set-version Ubuntu 2

Ardından Ubuntu’yu açıp bir Linux kullanıcı adı/şifresi oluşturun. Bu hesap Linux içinde yönetim (sudo) işlemleri için kullanılacak.

2) Ubuntu içinde Docker Engine kurulumu

Önce paketleri güncelleyin ve gerekli bağımlılıkları yükleyin:

sudo apt update && sudo apt upgrade -y

sudo apt install -y ca-certificates curl gnupg lsb-release

Docker’ın resmi deposunu ekleyip GPG anahtarı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

Depo kaydını ekleyin:

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

Docker Engine’i kurun:

sudo apt update

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

3) WSL 2’de Docker servisini çalıştırma (kritik nokta)

WSL 2’de systemd desteği artık mümkün, ancak dağıtım ayarınıza bağlı olarak kapalı olabilir. En temiz yöntem systemd’yi açıp Docker servisinin otomatik yönetilmesini sağlamaktır. Ubuntu’da şu dosyayı düzenleyin:

sudo nano /etc/wsl.conf

İçine şunu ekleyin:

[boot]
systemd=true

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

PowerShell: wsl --shutdown

Ubuntu’yu tekrar açın ve Docker servis durumunu kontrol edin:

sudo systemctl enable docker

sudo systemctl start docker

systemctl status docker --no-pager

4) “sudo” yazmadan Docker kullanmak

Her komutta sudo yazmak istemiyorsanız kullanıcıyı docker grubuna ekleyin:

sudo usermod -aG docker $USER

Bu değişikliğin uygulanması için oturumu kapatıp açın veya WSL’yi kapatıp yeniden başlatın. Ardından test edin:

docker run --rm hello-world

Çıktıda “Hello from Docker!” benzeri bir mesaj görüyorsanız temel kurulum tamamdır.

5) Docker Compose ve örnek proje

Yeni kurulumla birlikte Docker Compose ayrı bir ikili olmaktan çok “plugin” olarak gelir. Sürümü doğrulayın:

docker compose version

Hızlı bir test için bir klasör oluşturup basit bir Nginx servisi ayağa kaldırabilirsiniz. Örneğin proje dizinine compose.yaml koyup şu içeriği yazın (metin olarak): nginx imajı, 8080 portu. Sonrasında çalıştırın:

docker compose up -d

Tarayıcıdan http://localhost:8080 açıldığında Nginx karşılama sayfası geliyorsa ağ yönlendirmesi doğru çalışıyordur. İşiniz bitince:

docker compose down

6) Performans ve dosya konumu: Küçük ama önemli bir ipucu

WSL 2’de en sık yapılan hatalardan biri projeyi Windows dosya sisteminde (ör. C:\) tutup WSL içinden çalıştırmaktır. Bu, özellikle çok dosyalı Node.js/Python projelerinde I/O performansını düşürür. Daha akıcı bir deneyim için projeyi Linux dosya sisteminde (ör. /home/kullanici/proje) tutun. Visual Studio Code kullanıyorsanız “Remote - WSL” yaklaşımıyla klasörü doğrudan WSL içinde açabilirsiniz.

Sık karşılaşılan sorunlar ve hızlı çözümler

Docker çalışmıyor / daemon’a bağlanılamıyor: Büyük ihtimalle servis başlamamıştır. sudo systemctl start docker ile başlatın, systemd ayarını kontrol edin.

İzin hatası (permission denied): Kullanıcınız docker grubunda olmayabilir. sudo usermod -aG docker $USER ardından WSL’yi yeniden başlatın.

Port çakışması: 8080 gibi portlar doluysa Compose dosyasında farklı port seçin (ör. 8081:80).

Kapanış

WSL 2 üzerinde Docker Engine kurmak, Windows 11’de Linux konteyner ekosistemini daha kontrol edilebilir ve çoğu zaman daha hafif bir şekilde kullanmanızı sağlar. Üstelik günlük geliştirme işlerinde Docker Desktop’a bağlı kalmadan modern bir iş akışı kurabilirsiniz. Bu kurulumdan sonra CI benzeri script’ler yazmak, Compose ile çoklu servis ortamları hazırlamak ve BuildKit/Buildx ile imaj üretimini hızlandırmak çok daha keyifli hale geliyor.

31 Aralık 2025 Çarşamba

Next.js 15’te Server Actions ile Form İşleme: API Route Yazmadan Güvenli ve Hızlı Akış

Giriş: Neden Server Actions?

Next.js’in son sürümleriyle birlikte uygulama mimarisi “daha az kablo, daha çok iş” anlayışına yaklaştı. Bunların başında da Server Actions geliyor. Klasik yaklaşımda bir form gönderimini işlemek için API route yazmak, doğrulama yapmak, CSRF önlemleri düşünmek, sonra istemci tarafında fetch ile bağlanmak gerekiyordu. Server Actions, özellikle App Router kullanan projelerde, bu akışı sadeleştirerek form verisini doğrudan sunucu tarafında çalışan bir fonksiyona teslim etmenizi sağlıyor.

Bu yazıda, Next.js 15 (App Router) üzerinde Server Actions ile API yazmadan form işleme akışını kuracağız. Örnek senaryomuz basit bir “Bültene kayıt” formu olacak: e-posta doğrulama, rate limit mantığına uygun küçük bir kontrol ve sonuç mesajını kullanıcıya gösterme. Kod örnekleri TypeScript odaklıdır, fakat aynı mantık JavaScript ile de birebir uygulanır.

Ön Koşullar

Devam etmeden önce projede App Router kullanıyor olmanız ve Node.js sürümünüzün güncel olması gerekir. Ayrıca örnekte veri saklama katmanını basit tutacağız; dilerseniz Prisma, Drizzle veya doğrudan PostgreSQL ile genişletebilirsiniz. Ama amaç, Server Actions’ın form + doğrulama + sunucu tarafı işlem üçlüsünde neleri kolaylaştırdığını net görmek.

1) Server Action Fonksiyonunu Tanımlama

Server Actions’ın temel fikri, bir fonksiyonun sunucuda çalışacağını açıkça belirtmektir. Bu sayede fonksiyonunuz istemci paketine taşınmaz ve güvenli tarafta kalır. Genellikle app altında bir dosyada, örneğin app/actions/newsletter.ts gibi konumlandırılır.

app/actions/newsletter.ts:

Not: Aşağıdaki kod bloğunu Blogger HTML’inde göstermek için düz metin olarak paylaşıyorum.

Kod:

"use server";

type ActionState = { ok: boolean; message: string };

function isValidEmail(email: string) {

  return /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email);

}

export async function subscribeNewsletter(prevState: ActionState, formData: FormData): Promise<ActionState> {

  const email = String(formData.get("email") ?? "").trim().toLowerCase();

  if (!email) return { ok: false, message: "E-posta alanı boş olamaz." };

  if (!isValidEmail(email)) return { ok: false, message: "Geçerli bir e-posta girin." };

  // Basit bir “oran sınırlama” fikri: aynı e-postayı kısa sürede tekrar alma

  // Gerçek projede Upstash/Redis veya benzeri bir katman önerilir.

  await new Promise((r) => setTimeout(r, 300)); // örnek gecikme

  // Burada DB’ye yazma veya üçüncü parti servise iletme yapılır

  return { ok: true, message: "Kaydınız alındı. Teşekkürler!" };

}

2) Formu Server Action’a Bağlama

Şimdi bu action’ı bir formun action özelliğine bağlayacağız. Next.js tarafında bu, “form submit” ile birlikte verinin otomatik olarak sunucu fonksiyonuna gitmesi demek. Eğer kullanıcıya durum mesajı göstermek istiyorsanız useActionState (veya proje yapılandırmanıza göre benzer state kancaları) oldukça pratik.

app/newsletter/page.tsx örneği:

Kod:

"use client";

import { useActionState } from "react";

import { subscribeNewsletter } from "../actions/newsletter";

const initialState = { ok: false, message: "" };

export default function NewsletterPage() {

  const [state, formAction, pending] = useActionState(subscribeNewsletter, initialState);

  return (

    <div>

      <h2>Bültene Katıl</h2>

      <form action={formAction}>

        <label>E-posta</label>

        <input name="email" type="email" placeholder="[email protected]" required />

        <button type="submit" disabled={pending}>

          {pending ? "Gönderiliyor..." : "Kaydol"}

        </button>

      </form>

      {state.message ? (

        <p><b>{state.ok ? "Başarılı:" : "Hata:"}</b> {state.message}</p>

      ) : null}

    </div>

  );

}

3) Güvenlik ve Üretim İpuçları

Server Actions API route ihtiyacını azaltır, ama güvenlik sorumluluğunu ortadan kaldırmaz. Öncelikle, sunucu tarafında çalışan fonksiyonlarınızda her zaman doğrulama yapın; istemci tarafındaki required gibi kontroller sadece kullanıcı deneyimidir, güvenlik değildir. İkinci olarak, bülten gibi uç noktalarda bot trafiği yoğun olur; bu yüzden gerçek projede rate limit’i Redis/Upstash gibi bir katmanla uygulamak mantıklıdır. Üçüncü olarak, e-posta kaydını bir veritabanına yazıyorsanız tekrarlı kayıtları engellemek için benzersiz indeks kullanın.

Performans tarafında da avantajlar var: fetch katmanı, ayrı endpoint, ekstra JSON serileştirme gibi adımlar azaldığı için akış sadeleşir. Ayrıca action’ın sunucu tarafında kalması, anahtar ve gizli bilgilerin istemciye sızma riskini ciddi biçimde düşürür. Buna rağmen üçüncü parti servis çağrıları yapıyorsanız (Mailchimp, Brevo, vb.), hata yönetimini iyi kurgulayın ve kullanıcıya ham hata mesajı döndürmeyin.

4) Sık Yapılan Hatalar

En sık görülen hata, action dosyasına "use server" eklemeyi unutmak veya action’ı istemci bileşeninde yanlış şekilde çağırmaktır. İkinci hata, form alan adlarının (örneğin name="email") action içinde okunan anahtarlarla uyuşmaması. Üçüncü hata ise, action içinde doğrulama yokken yalnızca istemci doğrulamasına güvenmek. Bu üç noktayı kontrol ettiğinizde, Server Actions akışı genellikle sorunsuz çalışır.

Sonuç

Next.js 15’te Server Actions, özellikle form temelli işlemlerde “API route yaz, fetch bağla, JSON dön” rutinini büyük ölçüde azaltıyor. Bu yaklaşım, hem kod tabanını sadeleştiriyor hem de hassas işlemleri doğal şekilde sunucu tarafında tutuyor. Buradaki bülten örneği küçük görünse de aynı mimariyi parola sıfırlama, ödeme sonrası kayıt, yönetim paneli formları ve veri güncelleme ekranları gibi daha kritik alanlara ölçekleyebilirsiniz.

30 Aralık 2025 Salı

Android Telefonda Private DNS ile Reklâm ve Takip Engelleme (AdGuard DNS/NextDNS) – Adım Adım Kurulum ve İnce Ayar

Private DNS Nedir ve Neden İşe Yarar?

Android 9 ve üzeri sürümlerde yer alan Private DNS (Özel DNS) özelliği, telefonunuzun DNS sorgularını şifreli şekilde (DoT – DNS over TLS) belirlediğiniz bir DNS sağlayıcısına yönlendirmenizi sağlar. Pratikte bu, hem ağ düzeyinde daha tutarlı bir gizlilik sunar hem de doğru bir DNS servisi seçtiğinizde reklâm, takip alanı ve zararlı alan adı filtreleme gibi avantajlar getirebilir. Üstelik uygulama yüklemeden çalıştığı için pil tüketimi ve performans açısından çoğu “VPN tabanlı reklâm engelleyici”ye göre daha hafiftir.

Bu yazıda, Android’de Private DNS’i kullanarak reklâm ve takip engelleme yaklaşımını, iki popüler seçenek olan AdGuard DNS ve NextDNS üzerinden anlatacağım. Ayrıca bazı uygulamaların (özellikle oyunlar ve reklam SDK’ları) engellemeye takılınca neler olabileceği ve nasıl ince ayar yapılacağına da değineceğim.

Yöntemin Artıları ve Sınırları

Artılar: Kurulumu birkaç dakikadır, root gerektirmez, ekstra uygulama çalıştırmadığı için genellikle daha stabil ve hızlıdır, her uygulamayı kapsar (tarayıcı eklentisi gibi sınırlı değildir). Sınırlar: DNS tabanlı engelleme, “alan adı” seviyesinde çalışır; yani bir uygulama reklâmları aynı alan adından servis ediyorsa engelleme etkisi sınırlı olabilir. Ayrıca bazı servisler DNS üzerinden izleme/telemetri göndermese bile uygulama içi ölçümleme devam edebilir. Yine de mobilde “en az eforla en çok etki” sağlayan yöntemlerden biridir.

Hangi DNS Servisini Seçmeli?

AdGuard DNS genellikle “kur ve unut” yaklaşımına uygundur. Varsayılan filtre setiyle reklâm ve takip alanlarının önemli bir kısmını engeller. Öte yandan NextDNS daha “ileri seviye” bir deneyim sunar: panel üzerinden filtre listelerini seçebilir, istatistikleri görebilir, beyaz liste (allowlist) ve kara liste (denylist) ile çok ince ayar yapabilirsiniz. Eğer uğraşmayı seviyorsanız NextDNS, kontrol hissini ciddi biçimde artırır.

Adım Adım: Android’de Private DNS Kurulumu

1) Ayarlar menüsünü açın: Telefonunuzda Ayarlar > Ağ ve internet (bazı arayüzlerde “Bağlantılar”) bölümüne girin.

2) Özel DNS’i bulun: Özel DNS veya Private DNS

3) “Özel DNS sağlayıcı ana bilgisayar adı” seçin: Seçenekler genelde “Kapalı”, “Otomatik” ve “Özel DNS sağlayıcı ana bilgisayar adı” şeklindedir. Üçüncüyü seçin.

4) Sağlayıcı alan adını girin: Aşağıdaki seçeneklerden birini yazıp kaydedin:

AdGuard DNS (genel): dns.adguard.com

AdGuard DNS (aile koruması): dns-family.adguard.com (uygun içerik filtreleri içerir)

NextDNS: NextDNS kullanacaksanız size özel bir alan adı verilir. Örnek format genelde xxxxxx.dns.nextdns.io şeklindedir (buradaki x’ler size özel kimliktir). Kendi panelinizde “Setup” bölümünde Android/Private DNS için verilen hostname’i kopyalayın.

Kurulumun Çalıştığını Nasıl Anlarsınız?

En basit kontrol, sık reklâm çıkan bir uygulama veya web sitesini açıp farkı gözlemlemektir; ancak bu her zaman güvenilir bir test değildir. Daha teknik bir doğrulama için tarayıcıdan DNS test sayfalarını kullanabilirsiniz. Ayrıca NextDNS kullanıyorsanız panelde Logs (günlükler) bölümünde cihazınızın yaptığı sorguları anlık görerek Private DNS’in aktif olduğundan emin olabilirsiniz.

İleri Seviye İnce Ayar: NextDNS ile Beyaz Liste/Kara Liste

NextDNS’in asıl gücü, “bir şey bozulduğunda” hızlıca düzeltmenize izin vermesidir. Örneğin bir bankacılık uygulaması ya da bir oyunun giriş ekranı takılı kalıyorsa sebep çoğunlukla bir alan adının engellenmesidir. Böyle bir durumda NextDNS panelinde sorgu kayıtlarına bakıp engellenen alan adını tespit edebilir, ilgili alan adını Allowlist (izin verilenler) tarafına ekleyerek sorunu çözebilirsiniz.

Benim önerim, önce “agresif” liste sayısını abartmadan başlamak. Özellikle “tracking” listeleri ile “reklâm” listelerini dengeli tutmak, hem reklâmı azaltır hem de uygulama uyumluluğunu artırır. Engelleme arttıkça bazı içeriklerin (örneğin uygulama içi haber akışları veya video önerileri) eksik yüklenmesi gibi yan etkiler görülebilir.

Olası Sorunlar ve Çözümleri

1) Wi‑Fi’a bağlanıyor ama internet yok: Bazı kurumsal ağlar veya oteller şifreli DNS’e izin vermeyebilir. Bu durumda geçici olarak Özel DNS’i “Otomatik”e alıp deneyin.

2) Bir uygulama çalışmıyor veya doğrulama ekranı gelmiyor: NextDNS kullanıyorsanız loglardan engellenen alan adını bulup Allowlist’e ekleyin. AdGuard DNS kullanıyorsanız geçici olarak Private DNS’i kapatıp test edin; sorun düzelirse DNS engellemesine takılan bir alan adı vardır.

3) YouTube reklamları hâlâ var mı? DNS tabanlı engelleme, YouTube gibi aynı alan adı üzerinden farklı içerik servis eden platformlarda sınırlı kalabilir. Private DNS’i “her şeyi çözen tek yöntem” gibi değil, genel reklâm ve takip azaltma katmanı olarak düşünmek daha gerçekçi olur.

Sonuç: Uygulamasız, Hafif ve Etkili Bir Katman

Android’de Private DNS ile reklâm ve takip engelleme, birkaç ayarla cihaz genelinde hissedilir bir temizlik sağlar. Özellikle mobil veri tüketimini azaltması, sayfa yüklemelerini hafifletmesi ve bazı takip alanlarını kesmesi günlük kullanımda fark yaratır. Basitlik istiyorsanız AdGuard DNS, kontrol ve ince ayar istiyorsanız NextDNS iyi birer seçenek. Kurulumu yaptıktan sonra bir-iki gün gözlemleyin; sorun yaşarsanız “Allowlist” yaklaşımıyla sistemi kendi kullanımınıza göre rafine edebilirsiniz.

29 Aralık 2025 Pazartesi

Windows 11’de WSL 2 ile Docker’ı Kurmak ve Performanslı Bir Geliştirme Ortamı Hazırlamak

WSL 2 + Docker neden bu kadar popüler oldu?

Windows üzerinde Linux tabanlı bir geliştirme ortamı kurmanın en pratik yollarından biri WSL 2 (Windows Subsystem for Linux). Üzerine bir de Docker eklediğinizde, hem Linux ekosistemindeki araçları kullanabilir hem de container tabanlı projeleri Windows’ta zahmetsizce çalıştırabilirsiniz. Bu yazıda, Windows 11’de WSL 2 kurulumundan Docker entegrasyonuna, performans ayarlarından sık yapılan hatalara kadar uçtan uca bir “how-to” rehberi bulacaksınız.

Ön koşullar ve kısa kontrol listesi

Başlamadan önce sisteminizin sanallaştırma desteğinin açık olduğundan emin olun. Görev Yöneticisi > Performans > CPU bölümünde “Sanallaştırma: Etkin” görmelisiniz. Değilse BIOS/UEFI üzerinden Intel VT-x ya da AMD-V etkinleştirilmelidir. Ayrıca Windows 11’in güncel sürümünü kullanmanız (özellikle WSL tarafında) daha az sürpriz çıkarır.

1) WSL 2’yi kurma ve varsayılanı WSL 2 yapma

En hızlı yöntem, PowerShell’i yönetici olarak açıp aşağıdaki komutu çalıştırmaktır. Bu komut WSL bileşenlerini kurar, çekirdeği indirir ve bir Linux dağıtımı yüklemenize yardımcı olur:

Komut: wsl --install

Kurulumdan sonra sistemi yeniden başlatın. Ardından WSL sürümünüzü ve dağıtımlarınızı kontrol edin:

Komut: wsl -l -v

Varsayılan sürümü WSL 2 yapmak için:

Komut: wsl --set-default-version 2

2) Dağıtım seçimi: Ubuntu ile başlamak

Yeni başlayanlar ve geniş topluluk desteği nedeniyle çoğu geliştirici WSL üzerinde Ubuntu tercih ediyor. Microsoft Store üzerinden “Ubuntu” kurabilir ya da komutla listeleyip yükleyebilirsiniz:

Komut: wsl --list --online

Komut: wsl --install -d Ubuntu

İlk açılışta Linux kullanıcı adı ve şifre belirleyeceksiniz. Burada seçtiğiniz kullanıcı, geliştirme süreçlerinde sürekli kullanılacağı için basit ama anlamlı bir isim seçmek işinizi kolaylaştırır.

3) Docker Desktop kurulumu ve WSL entegrasyonu

Windows 11 üzerinde en sorunsuz yol genellikle Docker Desktop kurmaktır. Kurulum sırasında “Use WSL 2 instead of Hyper-V” benzeri bir seçenek görürseniz WSL 2’yi tercih edin. Kurulum tamamlandıktan sonra Docker Desktop’ı açın ve şu ayarları kontrol edin:

Settings > General: WSL 2 tabanlı motor etkin olmalı.

Settings > Resources > WSL Integration: Kurduğunuz Ubuntu dağıtımı için entegrasyonu aktif edin.

Bu noktadan sonra Ubuntu terminalinde docker version ve docker ps komutlarını çalıştırarak her şeyin düzgün bağlandığını doğrulayabilirsiniz.

4) Performans için kritik öneri: Projeyi Linux dosya sisteminde tutun

WSL 2 ile en sık yapılan performans hatası, projeyi Windows dosya sisteminde (ör. C:\) tutup WSL içinden işlemektir. Bu, özellikle Node.js, PHP Composer veya büyük Git depolarında dramatik yavaşlamaya neden olur. Bunun yerine projenizi Ubuntu tarafında, örneğin /home/kullaniciadi/proje altında konumlandırın. Windows’tan erişmek isterseniz Dosya Gezgini’ne \\wsl$ yazarak WSL dosya sistemine girebilirsiniz.

5) Kaynak yönetimi: .wslconfig ile RAM/CPU sınırı koyma

Docker container’ları ve WSL 2 birlikte çalışırken bazen sistem RAM’ini gereğinden fazla tüketebilir. Bu durumda Windows kullanıcı profiliniz altına .wslconfig dosyası oluşturup kaynak sınırı koyabilirsiniz. Dosya yolu genellikle C:\Users\KullaniciAdiniz\.wslconfig şeklindedir. İçeriği örnek olarak şu mantıkta olabilir: RAM limit, CPU çekirdeği, swap boyutu. Değişiklik sonrası WSL’yi kapatıp açmanız gerekir:

Komut: wsl --shutdown

Bu ayar, özellikle aynı anda IDE, tarayıcı ve container’lar açıkken sistemin nefes almasını sağlar.

6) Port yönlendirme ve yerel geliştirme

Docker ile ayağa kaldırdığınız servisleri (ör. 3000, 8080, 5432) Windows üzerinden de kullanmak isteyeceksiniz. Genel senaryoda container portlarını -p ile publish ettiğinizde Windows tarafında localhost üzerinden erişebilirsiniz. Yine de bazı ağ senaryolarında güvenlik yazılımları veya kurumsal politikalar trafiği engelleyebilir. Sorun yaşarsanız ilk kontrol noktası Windows Güvenlik Duvarı ve Docker Desktop’ın network ayarları olmalıdır.

7) Sık karşılaşılan sorunlar ve hızlı çözümler

Docker çalışmıyor / daemon’a bağlanamıyor: Docker Desktop’ın açık olduğundan ve ilgili dağıtımda WSL entegrasyonunun aktif edildiğinden emin olun. Ardından Ubuntu terminalinde yeniden deneyin.

Disk şişmesi: Uzun süre kullanılan Docker ortamlarında image ve volume birikir. Düzenli aralıklarla gereksiz kaynakları temizlemek için docker system prune (dikkatli kullanın) faydalı olabilir.

Git performansı düşük: Proje konumu çoğu zaman sebep olur. Repo’yu Windows yerine Linux dosya sistemine taşıyın.

Sonuç: Windows’ta Linux konforu, Docker ile taşınabilirlik

WSL 2 + Docker ikilisi, Windows 11 üzerinde modern geliştirme akışlarının neredeyse tamamını kapsayan güçlü bir kombinasyon sunuyor. Doğru kurulum ve birkaç performans ayarıyla; container tabanlı projeleri daha hızlı çalıştırabilir, bağımlılık karmaşasını azaltabilir ve ekip içinde tutarlı bir ortam sağlayabilirsiniz. Özellikle projelerinizi WSL dosya sisteminde tutmak ve kaynak yönetimini doğru yapmak, bu kurulumdan alacağınız verimi belirgin biçimde artırır.