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.

Windows 11’de WSL2 ile Docker Desktop’sız Geliştirici Ortamı Kurulumu (Adım Adım)

Docker Desktop olmadan neden Docker?

Windows 11’de Docker kullanmanın en popüler yolu Docker Desktop. Ancak özellikle kurumsal cihazlarda lisans politikaları, performans beklentisi veya daha “hafif” bir kurulum isteği nedeniyle alternatif arayan çok kişi var. Bu yazıda, WSL2 (Windows Subsystem for Linux) üzerinde Docker Engine kurarak, Docker Desktop’a ihtiyaç duymadan konteyner tabanlı bir geliştirme ortamını nasıl oluşturabileceğinizi adım adım anlatacağım. Hedefimiz: Windows’ta terminalden yönetilen, güncel ve performanslı bir Docker deneyimi.

Ön koşullar: Neler gerekli?

Bu rehber için Windows 11 kullanmanız önerilir (Windows 10’da da çalışır). Yönetici yetkisine sahip olmanız, PowerShell’i açabilmeniz ve Microsoft Store’dan bir Linux dağıtımı kurabilmeniz yeterli. Ayrıca BIOS/UEFI’de sanallaştırmanın açık olması gerekir. Kurulum sırasında komutları kopyalayıp yapıştırmanız işleri hızlandırır.

1) WSL2’yi etkinleştirme ve Ubuntu kurma

Önce WSL2’yi açalım. PowerShell’i Yönetici olarak çalıştırın ve şu komutu girin:

wsl --install

Bu komut genellikle WSL bileşenlerini etkinleştirir ve varsayılan dağıtım olarak Ubuntu’yu kurar. Eğer sisteminizde WSL zaten kuruluysa, sürümü kontrol etmek için:

wsl -l -v

Listede dağıtımınızın sürümü 2 görünmelidir. Değilse şu komutla yükseltebilirsiniz:

wsl --set-version Ubuntu 2

2) Ubuntu içinde temel güncellemeler

Başlat menüsünden Ubuntu’yu açın ve paket listesini güncelleyin:

sudo apt update && sudo apt upgrade -y

Bu adım, Docker kurulumu sırasında bağımlılık sorunlarını azaltır. Ardından gerekli yardımcı paketleri yükleyelim:

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

3) Docker Engine kurulumu (Ubuntu/WSL2)

WSL2 üzerinde en sağlıklı yöntem, Docker’ı Docker’ın resmi deposundan kurmaktır. Önce anahtar ve depo ekleyelim:

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 kuralım:

sudo apt update

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

4) Docker’ı root’suz (daha rahat) kullanma

Varsayılan olarak Docker komutları root yetkisi ister. Sürekli sudo yazmamak için kullanıcıyı docker grubuna ekleyin:

sudo usermod -aG docker $USER

Ardından Ubuntu oturumunu kapatıp tekrar açın (WSL penceresini kapatmak yeterli). Not: Bazı sistemlerde değişikliğin etkinleşmesi için Windows tarafında şu komutla WSL’yi yeniden başlatmak gerekebilir:

wsl --shutdown

5) Docker servisinin WSL2’de başlatılması

WSL dağıtımlarında systemd her zaman varsayılan olmayabilir. Windows 11’de güncel WSL sürümleri systemd desteği sunuyor. Eğer kullanmak isterseniz Ubuntu içinde /etc/wsl.conf dosyasını oluşturup şu satırları ekleyin:

[boot]
systemd=true

Sonra Windows’ta wsl --shutdown çalıştırıp Ubuntu’yu yeniden açın. Ardından Docker servis durumunu kontrol edin:

systemctl status docker

Aktif değilse başlatın:

sudo systemctl enable --now docker

6) Kurulum testi: İlk konteynerinizi çalıştırın

Şimdi her şeyin çalıştığını doğrulamak için klasik testi yapalım:

docker run --rm hello-world

Çıktıda Docker’ın başarıyla çalıştığını belirten bir mesaj görmelisiniz. Ardından Compose eklentisini test etmek için sürüme bakabilirsiniz:

docker compose version

7) Windows ile dosya performansı: Küçük ama kritik bir ipucu

WSL2 ile Docker kullanırken en çok performans kaybı, proje dosyalarını /mnt/c altında (Windows dosya sistemi) tutunca yaşanır. Özellikle Node.js, PHP veya Python gibi çok sayıda küçük dosya okuyan projelerde fark dramatiktir. En iyi pratik: projeyi Ubuntu dosya sisteminde (ör. /home/kullanici/proje) tutmak ve editörü (VS Code gibi) WSL eklentisiyle oradan açmak. Böylece I/O gecikmeleri düşer, konteyner build süreleri kısalır.

Sonuç: Hafif, hızlı ve kontrol sizde

Bu yöntemle Docker Desktop kullanmadan, WSL2 üzerinde güncel bir Docker Engine kurmuş oldunuz. Avantajları net: daha az arka plan servisi, daha yalın bir kurulum ve Linux’a daha yakın bir çalışma ortamı. Dezavantaj olarak ise bazı GUI odaklı Desktop özellikleri (tek tıkla Kubernetes, bazı entegrasyonlar) sizden ek kurulum isteyebilir. Yine de terminal seven geliştiriciler için bu kurulum, Windows 11 üzerinde konteyner tabanlı geliştirme yapmanın en pratik yollarından biri.

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

Docker’ı Windows’ta “hafif” çalıştırmak neden önemli?

Windows 11 üzerinde konteyner geliştirme yapanların büyük kısmı Docker Desktop ile başlıyor. Ancak zamanla kaynak tüketimi, otomatik güncellemeler, kurumsal lisans gereksinimleri veya arka planda çalışan servislerin fazlalığı gibi sebeplerle daha “temiz” bir kurulum arayışı doğuyor. Bu yazıda, WSL 2 (Windows Subsystem for Linux) kullanarak Docker’ı Docker Desktop’a ihtiyaç duymadan kurmayı, performans ve ağ ayarlarını ince ayarlamayı ve günlük kullanımda dikkat edilmesi gereken noktaları adım adım ele alacağım.

1) Ön koşullar: WSL 2 ve Linux dağıtımı

Öncelikle Windows 11’de WSL 2’nin aktif olması gerekiyor. Microsoft Store üzerinden Ubuntu 22.04/24.04 gibi güncel bir dağıtım kurmanız önerilir. WSL tarafında çalışacağımız için, komutların büyük kısmı Ubuntu terminalinde çalıştırılacak. Kurulumdan sonra Ubuntu’yu açıp güncellemeleri almak iyi bir başlangıçtır:

sudo apt update && sudo apt upgrade -y

WSL sürümünüzün 2 olduğundan emin olmak için Windows Terminal (PowerShell) tarafında şu komutu kullanabilirsiniz: wsl -l -v. Dağıtımınız “Version 2” görünmüyorsa WSL 2’ye çevirmek gerekir.

2) Docker Engine kurulumu (Docker Desktop olmadan)

Docker’ı WSL içindeki Ubuntu’ya kurduğumuzda aslında Docker Engine (dockerd) Linux içinde çalışır. Bu yaklaşımın avantajı, Windows tarafında ekstra arayüz ve servis yükü olmadan konteyner çalıştırabilmenizdir.

Ubuntu üzerinde önerilen yöntem, Docker’ın resmi deposunu eklemektir. Sırasıyla şu komutları çalıştırın:

sudo apt-get update

sudo apt-get 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-get update

Ardından Docker bileşenlerini kurun:

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

3) WSL’de systemd ve Docker servisinin yönetimi

Güncel WSL sürümlerinde systemd desteği mevcut. Docker servisinin otomatik ve sorunsuz başlaması için systemd’yi etkinleştirmek işleri kolaylaştırır. Ubuntu içinde /etc/wsl.conf dosyasını açıp aşağıdakini ekleyin:

[boot]
systemd=true

Sonra Windows tarafında WSL’i kapatıp yeniden başlatın: wsl --shutdown. Ubuntu’yu tekrar açtıktan sonra Docker’ı başlatıp durumunu kontrol edebilirsiniz:

sudo systemctl enable --now docker

systemctl status docker

4) “sudo” derdini bitirmek: docker grubuna kullanıcı ekleme

Her docker komutunda sudo yazmak istemiyorsanız, kullanıcıyı docker grubuna alın:

sudo usermod -aG docker $USER

Değişikliğin uygulanması için terminal oturumunu kapatıp açın. Ardından test:

docker run --rm hello-world

5) Docker Compose ve modern kullanım

Yeni yaklaşımda “docker-compose” ayrı bir ikili yerine çoğunlukla docker compose alt komutu olarak gelir. Kurulumla birlikte “Compose plugin” geldiği için şu şekilde kullanabilirsiniz:

docker compose version

Örneğin basit bir servis ayağa kaldırmak için bir klasörde compose.yaml oluşturup docker compose up -d komutuyla çalıştırabilirsiniz. Bu yöntem, yerel geliştirmede Nginx, Postgres, Redis gibi servisleri hızlıca yönetmek için oldukça pratik.

6) Performans ve dosya sistemi: projeyi nereye koymalı?

WSL 2’de performansı belirleyen en kritik detaylardan biri dosyaların konumudur. Projeyi Windows dosya sisteminde (örn. /mnt/c/...) tutmak mümkündür ama yoğun I/O yapan Node.js veya Python projelerinde yavaşlama görebilirsiniz. En iyi performans için projeyi WSL dosya sisteminde, örneğin ~/projects altında tutmak genellikle daha iyi sonuç verir.

7) Port yönlendirme ve erişim mantığı

Docker konteynerleri WSL içinde çalıştığı için portlar WSL ağı üzerinden yayınlanır. Windows 11’de çoğu senaryoda localhost erişimi otomatik çalışır; örneğin -p 8080:80 ile Nginx çalıştırdığınızda tarayıcıdan http://localhost:8080 ile erişebilirsiniz. Yine de bazı ağ senaryolarında WSL’in IP’sini öğrenmek gerekebilir: ip addr veya hostname -I iş görür.

8) Bu yaklaşımın artıları ve eksileri (kısa inceleme)

Artılar: Daha az arka plan bileşeni, daha düşük kaynak tüketimi, daha “Linux’a yakın” çalışma biçimi, lisans ve GUI bağımlılığının azalması.

Eksiler: Docker Desktop’taki bazı kolaylıklar (tek tıkla Kubernetes, görsel arayüz, otomatik entegrasyonlar) yoktur. Ayrıca WSL ve Linux ağ/dosya sistemi mantığına biraz daha hâkim olmanız gerekir.

Sonuç

Eğer amacınız Windows 11 üzerinde modern bir geliştirme ortamı kurarken Docker’ı daha kontrollü, daha hafif ve daha “geliştirici dostu” biçimde kullanmaksa, WSL 2 + Docker Engine yaklaşımı güçlü bir alternatiftir. Kurulumu tamamladıktan sonra en kritik iki noktayı aklınızda tutun: projeleri mümkünse WSL dosya sisteminde tutmak ve systemd ile Docker servisinin yönetimini düzgün yapmak. Bu sayede Docker Desktop’sız da günlük iş akışınızı sorunsuz şekilde sürdürebilirsiniz.

Windows 11’de WSL2 ile Docker Desktop Kurulumu: Yerel Kubernetes ve Hızlı Geliştirme Ortamı

WSL2 + Docker ile neden uğraşalım?

Windows 11 kullanırken Linux tabanlı geliştirme araçlarını “gerçek” bir Linux deneyimine yakın şekilde çalıştırmanın en pratik yolu WSL2’dir. WSL2 üzerine Docker kurduğunuzda, hem container’larınızı yerel olarak hızlıca ayağa kaldırabilir hem de isterseniz Docker Desktop’ın sağladığı entegre Kubernetes’i kullanarak mikro servis denemeleri yapabilirsiniz. Bu yazıda hedefimiz; Windows 11’de WSL2’yi etkinleştirmek, uygun bir Linux dağıtımı kurmak, Docker Desktop’ı WSL2 altyapısıyla çalıştırmak ve yaygın hatalara karşı kontrol listesi oluşturmak.

Ön koşullar

Gerekenler: Windows 11 (güncel), yönetici yetkisi, BIOS/UEFI’de sanallaştırmanın açık olması (Intel VT-x/AMD-V), en az 8 GB RAM (Kubernetes açacaksanız 16 GB daha rahat). Ayrıca kurulum sırasında internet bağlantısı şart.

1) WSL2’yi etkinleştirin

Önce Windows özellikleri tarafında WSL2 altyapısını açacağız. En hızlı yöntem PowerShell’i yönetici olarak çalıştırıp aşağıdaki komutu kullanmaktır:

PowerShell (Yönetici): wsl --install

Bu komut gerekli bileşenleri kurar ve varsayılan bir Linux dağıtımı yükler. Kurulum bitince bilgisayarı yeniden başlatmanız istenebilir. Halihazırda WSL yüklüyse sürümü doğrulamak için şu komutu çalıştırın:

PowerShell: wsl -l -v

Çıktıda dağıtımınızın VERSION sütununda 2 görünmesi gerekir. Eğer 1 ise, WSL2’ye çevirmek için:

PowerShell: wsl --set-version Ubuntu 2

2) Ubuntu’yu güncelleyin ve temel araçları kurun

Ubuntu terminalini açın (Başlat menüsünden “Ubuntu”). İlk iş paketleri güncellemek iyi bir alışkanlıktır:

Ubuntu: sudo apt update && sudo apt -y upgrade

Git ve bazı yardımcı paketler de işinizi kolaylaştırır:

Ubuntu: sudo apt -y install git ca-certificates curl

3) Docker Desktop’ı kurun ve WSL2 entegrasyonunu açın

Docker’ı Windows tarafında Docker Desktop ile yönetmek, ağ, proxy, GUI ayarları ve Kubernetes gibi özellikleri tek yerden kontrol etmenizi sağlar. Resmi kurulum dosyasını Docker’ın web sitesinden indirip standart şekilde kurabilirsiniz. Kurulum sırasında veya sonrasında Docker Desktop içinde şu ayarları kontrol edin:

Ayarlar > General: “Use the WSL 2 based engine” seçeneği açık olmalı.

Ayarlar > Resources > WSL Integration: “Enable integration with my default WSL distro” açık olmalı ve Ubuntu dağıtımınız seçili olmalı.

Bu noktadan sonra Ubuntu terminalinde Docker komutlarının çalıştığını test edin:

Ubuntu: docker version

Eğer sürüm bilgisi geliyorsa bağlantı tamamdır. Basit bir test container’ı çalıştırabilirsiniz:

Ubuntu: docker run --rm hello-world

4) Yerel Kubernetes’i etkinleştirme (isteğe bağlı)

Mikro servis mimarisiyle uğraşıyorsanız, yerel Kubernetes büyük kolaylık. Docker Desktop içinde:

Ayarlar > Kubernetes: “Enable Kubernetes” seçeneğini açın ve kurulumu bekleyin. İlk kurulum birkaç dakika sürebilir.

Kurulum tamamlanınca kubectl komutunu doğrulayın. Docker Desktop genellikle kubectl’i beraberinde getirir. Ubuntu içinde:

Ubuntu: kubectl version --client

Ardından cluster durumuna bakın:

Ubuntu: kubectl get nodes

Tek node “Ready” görünüyorsa, yerel Kubernetes ortamınız hazırdır.

5) Performans için kritik ipuçları

WSL2 üzerinde Docker kullanırken en sık yapılan hata, proje dosyalarını Windows dosya sistemi altında (ör. /mnt/c/...) tutmaktır. Bu, özellikle Node.js, Python veya büyük bağımlılık ağaçlarında ciddi yavaşlamaya neden olur. En iyi pratik, projeleri Linux dosya sistemi içinde (ör. ~/projects) saklamaktır.

Ayrıca Docker Desktop’ta Resources bölümünden CPU/RAM sınırlarını iş yükünüze göre ayarlayın. Kubernetes açıkken RAM tüketimi artar; 8 GB sistemlerde aynı anda çok container çalıştırmak zorlaşabilir.

6) Yaygın sorunlar ve hızlı çözüm listesi

“WSL 2 installation is incomplete”: Windows Update’i çalıştırın, ardından “wsl --update” komutunu deneyin.

Docker çalışıyor ama Ubuntu’da “Cannot connect to the Docker daemon”: Docker Desktop’ta WSL Integration açık mı kontrol edin. Ubuntu’yu kapatıp yeniden açın; gerekirse “wsl --shutdown” ile WSL’yi yeniden başlatın.

Kubernetes pod’ları sürekli Pending: Sistem kaynakları yetersiz olabilir. Docker Desktop kaynak limitlerini yükseltin veya Kubernetes’i kapatın.

Disk şişmesi: Kullanılmayan imaj ve volume’ları düzenli temizleyin: “docker system prune” (dikkatli kullanın) ve büyük volume’ları gözden geçirin.

Sonuç

Windows 11’de WSL2 ile Docker Desktop kurduğunuzda, hem Linux uyumlu geliştirme akışını yakalarsınız hem de container tabanlı projeleri hızlıca test edebilirsiniz. Üstelik tek tıkla Kubernetes açıp kapatabilmek, yerel ortamda prod’a benzer senaryoları denemenin en pratik yollarından biridir. Dosyaları Linux tarafında tutmak ve kaynak ayarlarını doğru yapmak, bu kurulumdan maksimum verimi almanızı sağlar.

WebAssembly ile Tarayıcıda Rust Çalıştırma: Performans Odaklı Kurulum ve Gerçekçi Kullanım Senaryoları

WebAssembly (Wasm) Nedir ve Neden Rust?

Tarayıcıda “native’e yakın” hız hedefleyen herkesin yolu bir noktada WebAssembly (Wasm) ile kesişiyor. Wasm; JavaScript’in yerine geçmekten çok, onu tamamlamak için tasarlanmış taşınabilir bir düşük seviye bytecode formatı. Performansın kritik olduğu yerlerde (görüntü işleme, kriptografi, veri sıkıştırma, oyun motoru parçaları, büyük veri dönüşümleri vb.) JavaScript tarafında zorlanan işlemleri Wasm’a taşıyabiliyorsunuz.

Bu noktada Rust pratik bir tercih: bellek güvenliği yaklaşımı, güçlü derleyici optimizasyonları ve Wasm ekosisteminin olgunlaşması sayesinde tarayıcı hedefleri için oldukça düzgün bir geliştirme deneyimi sunuyor. Bu yazıda, Blogger’da yayınlanabilir şekilde, sıfırdan Rust + Wasm projesi hazırlayıp tarayıcıda çalıştırmayı ve gerçek hayatta işinize yarayacak püf noktalarını adım adım ele alıyorum.

Ön Koşullar

Kuruluma başlamadan önce sisteminizde Rust ve Node.js bulunmalı. Rust için resmi kurulum aracı rustup yeterli. Node.js tarafında LTS sürüm tercih edin. Ayrıca yerel geliştirme için basit bir web sunucusu kullanacağız (Vite veya benzeri). Örnekleri macOS, Linux ve Windows’ta uygulayabilirsiniz; komutlar büyük ölçüde aynı.

1) Rust’ı Wasm Hedefiyle Hazırlama

İlk adım olarak Rust’ın WebAssembly hedefini ekleyin. Terminalde şu komutu çalıştırın:

rustup target add wasm32-unknown-unknown

Bu hedef, Rust kodunu Wasm bytecode’una derlemenizi sağlar. Ancak tarayıcıyla daha rahat entegrasyon için çoğu projede bir adım daha ileri gidip wasm-bindgen ve wasm-pack kullanılır. wasm-pack, proje iskeletini yönetir, derler ve JavaScript bağlayıcılarını üretir.

2) wasm-pack Kurulumu ve Proje Oluşturma

wasm-pack’i Rust’ın paket yöneticisi Cargo ile kurun:

cargo install wasm-pack

Ardından yeni bir kütüphane projesi oluşturun:

cargo new --lib hizli-wasm

Klasöre girip Cargo.toml dosyanıza wasm-bindgen bağımlılığını ekleyin. Dosyanın ilgili kısmı kabaca şöyle olmalı:

[dependencies]
wasm-bindgen = "0.2"

3) Rust Kodunu Tarayıcıya Açma (wasm-bindgen)

src/lib.rs içine basit ama ölçülebilir bir örnek koyun. Örneğin bir dizi içindeki sayıları filtreleyip toplamak gibi CPU’ya yük bindiren işleri Wasm’a taşımak yaygın bir yaklaşım. Örnek mantık: dışarıdan bir sayı listesi al, tek sayıları süz, kalanları topla. wasm-bindgen ile fonksiyonu dışa açabilirsiniz:

use wasm_bindgen::prelude::*;

#[wasm_bindgen]
pub fn ciftleri_topla(nums: Vec<u32>) -> u32 {
  nums.into_iter().filter(|n| n % 2 == 0).sum()
}

Buradaki önemli nokta: Tarayıcıya “güvenli” ve “anlaşılır” bir arayüz vermek. Karmaşık veri tipleri mümkündür ama başlangıçta sayılar ve basit diziler üzerinden ilerlemek, performans ve hata ayıklama açısından daha stabildir.

4) Derleme: Wasm Paketini Üretme

Proje klasöründe şu komutu çalıştırın:

wasm-pack build --target web

Komut tamamlandığında pkg adlı bir klasör oluşur. İçinde .wasm dosyası, JavaScript sarmalayıcısı ve package.json benzeri çıktılar yer alır. Bu klasör, web projenizde “modül” gibi kullanılabilir.

5) Vite ile Basit Bir Web Arayüzü

Wasm çıktısını hızlıca test etmek için Vite iyi bir seçenek. Ayrı bir klasörde Vite projesi oluşturun:

npm create vite@latest web-arayuz -- --template vanilla

Klasöre girip bağımlılıkları kurun:

cd web-arayuz
npm install

Ardından Rust projenizdeki pkg klasörünü web-arayuz içine kopyalayın (örneğin web-arayuz/src/pkg). Sonra src/main.js içinde Wasm modülünü içe aktarın:

import init, { ciftleri_topla } from "./pkg/hizli_wasm.js";

async function run() {
  await init();
  const nums = Array.from({ length: 100000 }, (_, i) => i);
  const sonuc = ciftleri_topla(nums);
  console.log("Sonuç:", sonuc);
}

run();

Son olarak geliştirme sunucusunu başlatın:

npm run dev

Tarayıcı konsolunda sonucu görüyorsanız temel entegrasyon tamamdır. Buradan sonra UI ekleyebilir, girdileri form üzerinden alabilir ya da daha gerçekçi veri işleme senaryolarına geçebilirsiniz.

Performans ve Gerçek Hayat İpuçları

Wasm her zaman otomatik olarak “daha hızlı” demek değildir. Kazanç, işin türüne göre değişir. Sık çağrılan küçük fonksiyonlarda JavaScript ↔ Wasm sınırı (FFI) maliyeti baskın hale gelebilir. Bu yüzden çok küçük işleri binlerce kez çağırmak yerine, mümkünse işi Wasm tarafında daha “toplu” yapacak şekilde tasarlayın.

Ayrıca tarayıcı tarafında bellek kopyaları önemli bir maliyet kalemidir. Büyük dizileri sürekli Rust’a geçirip geri almak yerine, veri akışını minimize edin. Daha ileri senaryolarda TypedArray ile bellek paylaşımı ve wasm-bindgen’in sunduğu yardımcılar gündeme gelir; fakat temel kurulum oturduktan sonra bu optimizasyonlara geçmek daha sağlıklı olur.

Hata Ayıklama ve Yaygın Sorunlar

En sık görülen problem, yanlış hedefle derleme veya modülün doğru yüklenmemesidir. Vite gibi bundler’lar ESM modüllerle iyi çalışır; bu yüzden wasm-pack build --target web seçimi önemlidir. Eğer “Failed to load module script” gibi hatalar alıyorsanız, dosya yollarını ve modül import biçimini kontrol edin.

Bir diğer konu da sürüm uyumsuzluklarıdır. wasm-bindgen sürümü yükseldiğinde, eski çıktılarla karışıklık yaşayabilirsiniz. Böyle durumlarda pkg klasörünü temizleyip yeniden derlemek genellikle sorunu çözer.

Sonuç

Rust ile WebAssembly kullanarak tarayıcıya performans odaklı bir modül eklemek, doğru kurulum yapıldığında şaşırtıcı derecede pratik. Bu rehberde Rust hedefini ekledik, wasm-pack ile derleme çıktısı ürettik ve Vite üzerinden tarayıcıda çalıştırdık. Buradan sonra gerçek bir uygulamada kriptografi, görüntü dönüştürme, sıkıştırma veya büyük veri filtreleme gibi alanlarda Wasm’ın avantajını daha net görmeye başlayacaksınız.

Web Push Bildirimleri Kurulumu: Firebase Cloud Messaging ile PWA’nıza Bildirim Ekleyin (Adım Adım)

Web Push nedir ve neden hâlâ önemli?

Web Push bildirimleri, kullanıcı tarayıcıyı kapatsa bile (izin verdiği sürece) tarayıcı üzerinden bildirim göndermenizi sağlar. Özellikle PWA (Progressive Web App) kullanan projelerde kullanıcıyı geri çağırmak, kampanya duyurmak veya kritik olayları bildirmek için hâlâ en etkili yöntemlerden biridir. Bu yazıda güncel ve pratik bir yaklaşım olarak Firebase Cloud Messaging (FCM) ile web push bildirimlerini nasıl kuracağınızı anlatacağım.

Ön koşullar ve dikkat edilmesi gerekenler

Kuruluma başlamadan önce şu maddeleri kontrol edin: (1) Siteniz HTTPS üzerinden yayınlanmalı. (2) Kullanıcı izni olmadan bildirim gönderemezsiniz; izin isteme akışını doğru tasarlayın. (3) Push, tarayıcı ve platforma göre değişir: Android’de Chrome oldukça sorunsuzken, iOS tarafında Web Push desteği sürüm ve kurulum tipine göre farklı davranabilir. (4) Bu öğretici, istemci tarafta JavaScript ve Service Worker, sunucu tarafta ise token yönetimi mantığını esas alır.

1) Firebase projesi oluşturma ve Web uygulaması ekleme

Firebase Console’a girip yeni bir proje oluşturun. Proje hazır olunca “Project settings” üzerinden “Your apps” bölümünde bir Web App ekleyin. Firebase size bir yapılandırma nesnesi (apiKey, authDomain, projectId vb.) verecek. Bu bilgileri istemci tarafta kullanacağız. Ardından “Cloud Messaging” sekmesinden bir VAPID key (Web Push certificates) üretin. Bu anahtar, tarayıcıların push aboneliğini doğrulamak için kullanılır ve istemci tarafında gerekecek.

2) Projeye Firebase SDK ekleme (modüler yaklaşım)

Blogger’da veya klasik bir web projesinde modüler Firebase SDK kullanımında iki seçenek var: (a) Paket yöneticisi (npm) ile derlenmiş proje, (b) CDN üzerinden modül import. Basit senaryoda CDN işinizi görür. Örneğin bir “app.js” dosyasında Firebase App ve Messaging modüllerini içeri alıp yapılandırmayı başlatırsınız. Önemli nokta: Bildirim için messaging modülünü doğru import etmek ve tarayıcı desteğini kontrol etmektir.

3) Service Worker dosyasını hazırlama (firebase-messaging-sw.js)

Web Push’un kalbi Service Worker’dır. Kök dizinde firebase-messaging-sw.js gibi bir dosya oluşturun. Bu dosya arka planda gelen mesajları yakalar. Arka plan bildirimi göstermek için “onBackgroundMessage” benzeri bir dinleyici kullanılır. Burada bildirimin başlığı, gövdesi ve tıklama davranışı gibi alanları tanımlayabilirsiniz. Service Worker dosyanızın mutlaka sitenin köküne veya kapsamı doğru ayarlanmış bir dizine konumlandığından emin olun; aksi halde tarayıcı bildirimleri doğru scope’ta yakalayamaz.

4) Tarayıcıdan izin isteme ve FCM token alma

İstemci tarafta kullanıcıdan bildirim izni istemeniz gerekir. Burada yapılan en büyük hata, sayfa açılır açılmaz izin istemektir. Bunun yerine kullanıcıya bir değer önerin: “Sipariş güncellemeleri için bildirimleri aç” gibi. Kullanıcı izin verince FCM üzerinden bir registration token alırsınız. Bu token’ı sunucunuza gönderip kullanıcı hesabı, cihaz veya abonelik tercihleriyle ilişkilendirmeniz gerekir. Token yönetimini doğru yapmazsanız, aynı kullanıcıda birden fazla token birikir ve gereksiz bildirim gönderimleri oluşur.

5) Sunucu tarafında bildirim gönderme mantığı

FCM ile push göndermenin iki yolu öne çıkar: (1) Firebase Console’dan test amaçlı gönderim, (2) Sunucudan FCM HTTP v1 API ile programatik gönderim. Üretim senaryosunda ikinci yöntem şarttır. Bunun için bir servis hesabı (service account) ile OAuth 2.0 üzerinden erişim token’ı alıp FCM endpoint’ine istek atarsınız. Mesaj gövdesinde hedef olarak token (tek cihaz), topic (kanal) veya condition (mantıksal filtre) kullanabilirsiniz. Ayrıca web tarafında bildirim göstermek için payload içinde notification ve/veya data alanlarını doğru kurgulamak önemlidir.

6) İleri seviye ipuçları: Topic, segmentasyon ve ölçüm

Web push’u “herkese aynı bildirim” seviyesinde bırakırsanız kullanıcılar hızlıca izinleri kapatır. Daha iyi bir yaklaşım, kullanıcının tercihine göre topic aboneliği yaptırmaktır: örneğin “indirimler”, “blog”, “stok” gibi kanallar. Böylece sadece ilgili kitleye bildirim gider. Bir diğer ileri seviye konu da ölçümdür: Bildirimin tıklanma oranı (CTR) ve dönüşümünü takip etmek için linklere UTM parametreleri ekleyin ve Analytics tarafında kampanyaları ayrı raporlayın. Ayrıca Service Worker’da “notificationclick” event’ini yakalayıp kullanıcıyı doğru sayfaya yönlendirmek, deneyimi ciddi şekilde iyileştirir.

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

Token alınamıyor: VAPID anahtarını doğru kullandığınızdan ve Notification izninin “granted” olduğundan emin olun. Service Worker çalışmıyor: Dosya yolu/scope hatalarını kontrol edin; tarayıcı “Application” sekmesinden kayıt durumuna bakın. Bildirim geliyor ama tıklayınca açılmıyor: Service Worker’daki “notificationclick” içinde doğru URL ve focus mantığı kurun. Çoklu cihaz kirliliği: Token’ları kullanıcı bazında güncelleyin; geçersiz token’ları (NotRegistered) yanıtlarına göre temizleyin.

Sonuç

Firebase Cloud Messaging ile web push bildirimleri, doğru kurgulandığında PWA veya klasik web sitenizde kullanıcı etkileşimini ciddi ölçüde artırabilir. Bu rehberde proje oluşturma, VAPID anahtarı, Service Worker mantığı, token yönetimi ve üretim senaryosunda gönderim yaklaşımını ele aldık. Bir sonraki adım olarak topic tabanlı abonelik ve ölçümleme ekleyerek bildirimi “spam” olmaktan çıkarıp gerçek bir ürüne dönüştürebilirsiniz.

Docker Compose ile PostgreSQL + pgAdmin Kurulumu: Geliştirme Ortamını 10 Dakikada Ayağa Kaldırma

Hedef: Tek Komutla Veritabanı Ortamı

Yerel geliştirme ortamında PostgreSQL kurmak çoğu zaman “kuruldu mu, servis başladı mı, port çakıştı mı, kullanıcı yetkileri doğru mu?” gibi küçük ama zaman yiyen sorularla uzar. Üstelik ekip çalışmasında herkesin makinesinde aynı sürüm ve aynı ayarlarla çalışmak daha da zorlaşır. Bu yazıda, Docker Compose ile PostgreSQL’i ve yönetim aracı olarak pgAdmin’i birlikte çalıştıran, tekrar üretilebilir (reproducible) bir kurulum hazırlayacağız. Amaç: projeyi klonlayan herkesin tek komutla aynı veritabanına erişebilmesi.

Konu “ileri seviye” tarafına şu noktada yaklaşıyor: sadece konteyneri çalıştırmakla kalmayacağız; kalıcı veri (volume), başlangıç SQL dosyaları, servis bağımlılıkları ve güvenli sayılabilecek temel ayarlarla pratik bir şablon oluşturacağız. Bu yapı; Node.js, Python, Java, .NET gibi farklı backend’lerle rahatça kullanılabilir.

Ön Koşullar

Bilgisayarınızda Docker ve Docker Compose yüklü olmalı. Güncel Docker Desktop sürümlerinde Compose genellikle hazır gelir. Terminalde docker --version ve docker compose version komutlarıyla kontrol edebilirsiniz.

Proje Yapısını Hazırlama

Proje klasörünüzde aşağıdaki gibi bir yapı işinizi kolaylaştırır. Özellikle init dosyalarını ayrı klasörde tutmak, veritabanını ilk kurulumda otomatik hazırlamak için idealdir.

Önerilen dizinler:
- docker-compose.yml
- db/init/01-schema.sql
- db/init/02-seed.sql

docker-compose.yml Dosyası

Aşağıdaki Compose tanımı PostgreSQL (db) ve pgAdmin (pgadmin) servislerini ayağa kaldırır. PostgreSQL verisi named volume ile kalıcı hale gelir; pgAdmin ayarları da ayrı volume’da tutulur. Ayrıca PostgreSQL’e ilk kurulumda SQL çalıştırmak için ./db/init klasörünü otomatik mount ediyoruz.

docker-compose.yml içeriği:

version satırı artık zorunlu olmasa da okunabilirlik için ekleyebilirsiniz. Örnek YAML:

Not: Aşağıdaki blokları dosyanıza aynen yazın (girintiler YAML için kritiktir).

docker-compose.yml
services:
  db:
    image: postgres:16
    container_name: local_postgres
    restart: unless-stopped
    environment:
      POSTGRES_USER: appuser
      POSTGRES_PASSWORD: apppass
      POSTGRES_DB: appdb
    ports:
      - "5432:5432"
    volumes:
      - postgres_data:/var/lib/postgresql/data
      - ./db/init:/docker-entrypoint-initdb.d:ro
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U appuser -d appdb"]
      interval: 5s
      timeout: 3s
      retries: 20

  pgadmin:
    image: dpage/pgadmin4:latest
    container_name: local_pgadmin
    restart: unless-stopped
    environment:
      PGADMIN_DEFAULT_EMAIL: [email protected]
      PGADMIN_DEFAULT_PASSWORD: adminpass
    ports:
      - "5050:80"
    volumes:
      - pgadmin_data:/var/lib/pgadmin
    depends_on:
      db:
        condition: service_healthy

volumes:
  postgres_data:
  pgadmin_data:


Başlangıç SQL Dosyaları (Opsiyonel ama Çok Faydalı)

PostgreSQL’in resmi imajı, ilk kez boş bir data dizini oluştururken /docker-entrypoint-initdb.d altındaki .sql dosyalarını otomatik çalıştırır. Bu sayede tablo şemasını ve örnek veriyi sürüm kontrolüne alabilirsiniz. Örnek iki dosya hazırlayalım:

db/init/01-schema.sql

CREATE TABLE IF NOT EXISTS users (
  id SERIAL PRIMARY KEY,
  email TEXT UNIQUE NOT NULL,
  created_at TIMESTAMP NOT NULL DEFAULT NOW()
);


db/init/02-seed.sql

INSERT INTO users (email) VALUES ('[email protected]')
ON CONFLICT DO NOTHING;


Buradaki önemli detay: init dosyaları sadece veritabanı ilk kez oluşturulurken devreye girer. Eğer volume zaten doluysa ve siz SQL’i değiştirdiyseniz, değişikliğin uygulanması için ya manuel migration çalıştırmanız ya da geliştirme ortamında ilgili volume’u temizleyip yeniden başlatmanız gerekir.

Servisleri Başlatma

Aynı klasörde terminal açın ve şu komutu çalıştırın:

docker compose up -d

Ardından konteynerlerin durumunu görmek için:

docker compose ps

pgAdmin ile Bağlantı Kurma

Tarayıcıdan http://localhost:5050 adresine gidin. Giriş için Compose dosyasındaki PGADMIN_DEFAULT_EMAIL ve PGADMIN_DEFAULT_PASSWORD değerlerini kullanın. Yeni bir server kaydı eklerken:

Host name/address: db
Port: 5432
Maintenance database: appdb
Username: appuser
Password: apppass

Burada “host” olarak db yazmamızın sebebi, Compose ağında servis isimlerinin DNS gibi çalışmasıdır. Yani pgAdmin konteyneri, PostgreSQL’e db:5432 üzerinden erişir.

Sık Karşılaşılan Sorunlar ve İpuçları

Port çakışması: Makinenizde 5432 zaten kullanılıyorsa, “5432:5432” satırını örneğin “5433:5432” yapın. Uygulamanızdan bağlanırken host portunu (5433) kullanırsınız.

Şifreleri dosyaya yazmak: Bu örnek geliştirme içindir. Ekip içinde daha güvenli kullanım için ortam değişkenlerini .env dosyasına taşıyıp Compose’dan çağırabilirsiniz.

Veriyi sıfırlama: Tamamen temiz kurulum için servisleri durdurup volume’ları silin: docker compose down -v. Sonra tekrar docker compose up -d dediğinizde init SQL dosyaları yeniden çalışır.

Sonuç

Docker Compose ile PostgreSQL + pgAdmin kurulumu, hem tek kişilik projelerde hem de ekip çalışmalarında standart bir geliştirme zemini sağlar. En büyük kazanım; “benim makinemde çalışıyor” problemini azaltmanız, versiyon uyumunu korumanız ve veritabanını birkaç komutla yönetebilmenizdir. Bu şablonu temel alıp Redis, MinIO, Kafka gibi servisleri de aynı Compose dosyasına ekleyerek daha kapsamlı bir yerel ortam kurabilirsiniz.