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.

Windows 11’de WSL2 ile Docker Kurulumu ve Performans Ayarları (Adım Adım)

WSL2 ile Docker: Neden Hâlâ En Pratik Seçenek?

Windows 11 kullanıyorsanız ve geliştirme ortamınızı “Linux hissiyatı” ile kurmak istiyorsanız, WSL2 (Windows Subsystem for Linux) + Docker ikilisi bugün hâlâ en pratik çözümlerden biri. WSL2, Windows üzerinde gerçek bir Linux çekirdeğiyle çalıştığı için klasik sanal makine kurulumlarına göre daha hızlı başlatma, daha iyi entegrasyon ve daha az uğraş sunuyor. Bu yazıda, WSL2 üzerinde Docker’ı kurup sorunsuz çalıştırmanın yanında, performans ve disk yönetimi gibi can sıkıcı noktaları da ileri seviye ayarlarla toparlayacağız.

Ön Koşullar: Sürüm ve Özellik Kontrolü

Başlamadan önce Windows 11’in güncel olduğundan emin olun. Windows Özellikleri tarafında iki bileşenin etkin olması gerekiyor: Windows Subsystem for Linux ve Virtual Machine Platform. Bunları elle açabilirsiniz; ancak en temiz yöntem, Microsoft’un komutlarıyla ilerlemek.

1) WSL2 Kurulumu ve Varsayılan Sürümü Ayarlama

PowerShell’i Yönetici olarak açın ve şu komutu çalıştırın:

wsl --install

Bu komut çoğu sistemde gerekli bileşenleri açar ve varsayılan bir dağıtım (genellikle Ubuntu) kurar. Kurulum sonrası yeniden başlatma istenirse sistemi yeniden başlatın. Ardından WSL sürümünü 2 yapın:

wsl --set-default-version 2

Kurulu dağıtımların WSL2’de olup olmadığını görmek için:

wsl -l -v

Eğer dağıtımınız WSL1 görünüyorsa şu şekilde WSL2’ye yükseltebilirsiniz:

wsl --set-version Ubuntu 2

2) Docker Desktop Kurulumu ve WSL Entegrasyonu

Windows tarafında Docker kullanmanın en sorunsuz yolu, Docker Desktop kurmaktır. Kurulum sırasında “Use WSL 2 instead of Hyper-V” benzeri bir seçenek görürseniz WSL2’yi tercih edin. Kurulum bittikten sonra Docker Desktop’ı açın ve ayarlardan Resources > WSL Integration bölümüne gidin.

Burada, Docker’ın hangi Linux dağıtımıyla entegre çalışacağını seçebilirsiniz. Örneğin Ubuntu kullanıyorsanız ilgili dağıtımı etkinleştirin. Bu adım, “Docker komutlarını Ubuntu içinde çalıştırayım” senaryosunun anahtarıdır.

3) Ubuntu İçinde Docker’ın Çalıştığını Doğrulama

Ubuntu terminalinizi (WSL) açın ve şu komutlarla kontrol edin:

docker version

docker run --rm hello-world

İkinci komut, küçük bir imaj indirip çalıştırır ve kurulumun doğru yapıldığını net şekilde gösterir. Eğer “Cannot connect to the Docker daemon” hatası alırsanız, Docker Desktop’ın açık olduğundan ve WSL Integration’ın seçili dağıtım için etkinleştirildiğinden emin olun.

4) Performans: Dosyaları Nereye Koymalısınız?

WSL2 + Docker’da performansı belirleyen en kritik noktalardan biri dosya sistemidir. Projenizi /home/kullaniciadi/proje gibi WSL’in Linux dosya sistemi içinde tutmak genellikle çok daha hızlıdır. Projeyi /mnt/c altında (Windows diskine bağlı konumda) çalıştırmak, özellikle Node.js, PHP Composer veya yoğun küçük dosya erişimi yapan işler için belirgin yavaşlık yaratabilir.

Özet kural: Kod ve bağımlılıklar Linux tarafında, Windows tarafıyla paylaşım gerekiyorsa bunu kontrollü yapın.

5) İleri Ayar: WSL Kaynak (CPU/RAM) Sınırı ve Disk Yönetimi

WSL2 varsayılan olarak sistem kaynaklarını dinamik kullanır. Ancak Docker ile birlikte yoğun işlerde RAM tüketimi artabilir. Bunu kontrol etmek için Windows kullanıcı klasörünüzde .wslconfig adında bir dosya oluşturup şu örnek ayarları ekleyebilirsiniz:

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

Değişikliklerin uygulanması için WSL’i kapatın:

wsl --shutdown

Bir diğer yaygın sorun, Docker imajları ve katmanları arttıkça disk tüketiminin şişmesidir. WSL2 sanal diski zamanla büyür ve her zaman otomatik küçülmez. Gereksiz imajları temizlemek için periyodik olarak şu komutlar işinize yarar:

docker system prune -a

Bu komut kullanılmayan imajları da sileceği için üretim benzeri ortamlarda dikkatli olun. Düzenli temizlik, WSL2 disk şişmesi ve gereksiz alan kullanımını azaltır.

6) Sık Karşılaşılan Hatalar ve Hızlı Çözümler

Docker daemon’a bağlanamıyorum: Docker Desktop açık mı, WSL Integration doğru dağıtımda etkin mi kontrol edin. Gerekirse wsl --shutdown sonrası Docker’ı yeniden başlatın.

İmaj indirme çok yavaş: Kurumsal ağ veya proxy varsa Docker Desktop proxy ayarlarını kontrol edin. DNS problemlerinde WSL içinde resolv.conf ayarları bazen etkili olur.

Dosya erişimi yavaş: Projeyi /mnt/c yerine Linux dosya sistemine taşıyın. Özellikle bağımlılık klasörleri (node_modules gibi) için fark dramatiktir.

Sonuç: Stabil Bir Geliştirme Ortamı İçin Kısa Reçete

Windows 11’de WSL2 ile Docker kurmak artık birkaç adımda tamamlanıyor; asıl farkı yaratan kısım doğru entegrasyon ve performans ayarları. Projeyi Linux tarafında tutmak, WSL kaynaklarını mantıklı sınırlandırmak ve Docker temizliğini düzenli yapmak; hem hız hem stabilite açısından günlük geliştirme akışını ciddi şekilde iyileştirir. Bu kurulumla, Windows konforunu bozmadan Linux tabanlı bir geliştirme düzenine geçebilirsiniz.

Windows 11’de WSL2 ile Docker Kurulumu ve Geliştirici Ortamını Hızlandırma Rehberi

WSL2 + Docker Neden Bu Kadar Popüler?

Windows 11 üzerinde yazılım geliştirenlerin önemli bir kısmı, Linux araçlarını yerel hızda çalıştırmak ve aynı anda Windows uygulamalarından da vazgeçmemek istiyor. WSL2 (Windows Subsystem for Linux 2), Linux çekirdeğini sanal makine benzeri bir mimaride çalıştırırken, kullanıcıya terminal ve dosya erişimi açısından çok pratik bir deneyim sunuyor. İşin içine Docker da girince; mikroservisler, test ortamları, veritabanları ve CI/CD’ye yakın bir yerel geliştirme düzeni kurmak oldukça kolaylaşıyor.

Bu rehberde, Windows 11’de WSL2’yi etkinleştirip bir Linux dağıtımı kuracak, Docker’ı WSL2 tabanlı şekilde çalıştıracak ve performans/uyumluluk için birkaç kritik ayarı yapacağız. Anlatım sade; ancak adımlar güncel ve geliştirici kullanımına uygun olacak.

1) Ön Koşullar ve Kontroller

Başlamadan önce sisteminizde sanallaştırmanın açık olduğundan emin olun. Görev Yöneticisi > Performans sekmesinde Sanallaştırma: Etkin görmelisiniz. Değilse BIOS/UEFI üzerinden Intel VT-x veya AMD-V özelliğini açmanız gerekir.

Windows 11’in güncel olması da önemli. Bazı WSL2 ve ağ bileşenleri güncellemelerle iyileşiyor. Ayarlar > Windows Update bölümünden güncelleme kontrolü yapın.

2) WSL2 Kurulumu ve Varsayılan Sürümü Ayarlama

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

wsl --install

Bu komut çoğu sistemde gerekli bileşenleri kurar ve varsayılan olarak bir dağıtım (genellikle Ubuntu) önerir. Kurulumdan sonra yeniden başlatmanız istenebilir. Ardından WSL sürümünü 2 olarak sabitlemek için:

wsl --set-default-version 2

Kurulu dağıtımları görmek için:

wsl -l -v

Eğer dağıtımınız WSL 1 görünüyorsa, örnek olarak Ubuntu’yu WSL2’ye çevirebilirsiniz:

wsl --set-version Ubuntu 2

3) Ubuntu İçinde Temel Güncelleme ve Kullanışlı Paketler

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

sudo apt update && sudo apt upgrade -y

Geliştirme süreçlerinde sık kullanılan araçlar için:

sudo apt install -y build-essential git curl ca-certificates

4) Docker’ı WSL2 Üzerinde Çalıştırma (Docker Desktop ile)

Windows tarafında en sorunsuz yöntem, Docker Desktop kullanmaktır. Docker Desktop’ı kurduktan sonra Ayarlar (Settings) içinde Use the WSL 2 based engine seçeneğini etkinleştirin. Ardından Resources > WSL Integration bölümünde Ubuntu dağıtımınızı seçip entegrasyonu açın.

Bu aşamadan sonra Ubuntu terminalinde Docker komutlarını çalıştırabilmelisiniz. Kontrol için:

docker version

docker run --rm hello-world

Komutlar çalışıyor ama izin hatası alıyorsanız, genellikle Docker Desktop entegrasyonu eksik veya dağıtım seçimi kapalıdır. Ayarlara geri dönüp WSL Integration’ı doğrulayın.

5) Performans İçin Kritik İpucu: Dosyaları Nerede Tutmalı?

WSL2 + Docker kullanımında en sık yaşanan performans farkı, proje dosyalarının konumundan kaynaklanır. Eğer kaynak kodunuz Windows dosya sisteminde (ör. C:\) duruyor ve siz WSL içinden bu klasöre /mnt/c üzerinden erişiyorsanız, yoğun dosya okuma/yazma yapan projelerde yavaşlık hissedebilirsiniz.

Daha iyi performans için projelerinizi WSL dosya sisteminde tutun. Örneğin:

mkdir -p ~/projeler

Bu klasör altında çalışıp editör olarak VS Code’un Remote - WSL eklentisini kullanırsanız hem Windows arayüzüyle düzenleme yapar hem de Linux tarafında hızlı I/O avantajını korursunuz.

6) Docker Compose ile Örnek Bir Geliştirme Ortamı

Hızlı bir test ortamı için bir klasör oluşturup içine docker-compose.yml ekleyebilirsiniz. Örneğin PostgreSQL başlatmak, çoğu projede büyük kolaylık sağlar. Dosyanızın mantığı basit: bir veritabanı servisi, port yönlendirme ve kalıcı veri dizini. Compose çalıştırmak için genelde şu komut yeterlidir:

docker compose up -d

Sonrasında konteynerleri kontrol edin:

docker ps

İşiniz bitince ortamı kaldırmak için:

docker compose down

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

WSL dağıtımı açılmıyor veya güncellenmiyor: PowerShell’de wsl --update komutunu deneyin ve Windows Update’i kontrol edin.

Docker komutları bulunamıyor: Docker Desktop’ın açık olduğundan ve WSL Integration’ın ilgili dağıtım için etkin olduğundan emin olun.

Port çakışması: 5432, 3306 gibi yaygın portlar başka servisler tarafından kullanılıyor olabilir. Compose dosyasında portları değiştirin veya çakışan servisi kapatın.

Sonuç

Windows 11’de WSL2 ile Docker kullanmak, tek bilgisayarda hem Windows uygulamalarını hem de Linux tabanlı geliştirme araçlarını verimli şekilde bir araya getirir. Doğru entegrasyon yapıldığında, konteyner tabanlı projeler daha taşınabilir olur; test ve geliştirme ortamları birkaç komutla ayağa kalkar. En büyük kazanım ise şudur: “Makinemde çalışıyor” cümlesini ekibin geri kalanından daha az duyarsınız.