Evde DNS Üzerinden Reklam ve İzleyici Engelleme: Pi-hole’u Docker ile 30 Dakikada Kurma Rehberi

Pi-hole Nedir ve Neden DNS Seviyesinde Engelleme?

Reklam engelleyiciler genellikle tarayıcı eklentisi olarak çalışır ve sadece o tarayıcıyı etkiler. Pi-hole ise DNS seviyesinde filtreleme yaparak ev ağınızdaki telefon, tablet, akıllı TV, oyun konsolu gibi tüm cihazlarda reklam ve takip alanlarını engelleyebilir. Yani bir uygulamanın içine gömülü reklam çağrıları da, tarayıcı dışındaki izleme servisleri de büyük ölçüde kesilir. Bu yaklaşım, özellikle “her cihazda tek tek eklenti kurmakla uğraşmak istemiyorum” diyenler için oldukça temiz bir çözümdür.

Bu rehberde Pi-hole’u bir Raspberry Pi zorunluluğu olmadan, herhangi bir Linux makinede (mini PC, NAS, eski laptop veya bir VPS değil; tercihen ev içi cihaz) Docker ile kuracağız. Docker sayesinde güncelleme, yedekleme ve taşınabilirlik daha kolay olur. Ayrıca sistemi bozma riskini de azaltır.

Kurulum Öncesi Gereksinimler

Başlamadan önce aşağıdakilere sahip olmanız işinizi kolaylaştırır: Docker ve Docker Compose kurulu bir Linux cihazı, yerel ağda sabit IP (ya router’dan DHCP rezervasyonu ya da cihazda statik IP), ve modem/router arayüzüne erişim. Pi-hole’un stabil çalışması için cihazın mümkün olduğunca 7/24 açık kalması önerilir. Eğer sık kapatıyorsanız, DNS çözümleme sorunları yaşamamak için router’da ikinci bir DNS (örneğin 1.1.1.1) yedek olarak tanımlanabilir; fakat bu, bazı istemcilerin engeli aşmasına neden olabilir.

Docker Compose ile Pi-hole Kurulumu

Önce Pi-hole için bir klasör oluşturun ve içine bir docker-compose.yml dosyası hazırlayın. Klasör yapısı olarak yapılandırma ve DNS servisinin kalıcı verisini saklayacağız. Örnek bir yaklaşım: /opt/pihole altında çalışmak.

1) Klasörleri oluşturun (örnek):

/opt/pihole/etc-pihole ve /opt/pihole/etc-dnsmasq.d klasörlerini oluşturun. Bu klasörler Pi-hole ayarlarının yeniden başlatmalarda kaybolmamasını sağlar.

2) docker-compose.yml içeriği (kendi ağınıza göre uyarlayın):

Önemli: Aşağıdaki ayarlarda TZ zaman dilimi, WEBPASSWORD yönetim paneli şifresi ve volume yolları kritik. Router’ınızın DNS portu 53’ü engellemediğinden emin olun.

services:
  pihole:
    container_name: pihole
    image: pihole/pihole:latest
    hostname: pihole
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "80:80/tcp"
    environment:
      - TZ=Europe/Istanbul
      - WEBPASSWORD=GucluBirSifreBelirleyin
    volumes:
      - "/opt/pihole/etc-pihole:/etc/pihole"
      - "/opt/pihole/etc-dnsmasq.d:/etc/dnsmasq.d"
    restart: unless-stopped

3) Servisi ayağa kaldırın:

Klasörün içinde docker compose up -d komutunu çalıştırın. Ardından tarayıcıdan http://CIHAZ_IP_ADRESI/admin adresine giderek yönetim panelini açın. Şifrenizi compose dosyasındaki WEBPASSWORD ile belirlediyseniz doğrudan giriş yapabilirsiniz.

Router’da DNS Ayarı: Tüm Ağı Pi-hole’a Yönlendirme

Pi-hole’u “gerçekten etkili” yapan adım, DNS’i cihaz bazında değil ağ genelinde yönlendirmektir. Bunun için modem/router arayüzünde DHCP DNS alanına Pi-hole’un IP adresini girin. Bazı modemlerde “Primary DNS” ve “Secondary DNS” alanları vardır. Maksimum engelleme için ikisini de Pi-hole yapmak ideal olsa da, kesinti toleransı istiyorsanız ikincil DNS’i farklı bir sağlayıcıya vermek zorunda kalabilirsiniz. Bu durumda bazı istemciler ikinci DNS’i kullanarak reklamları çözümleyebilir; bunu azaltmanın yolu router’da dış DNS isteklerini kural ile engelleyip sadece Pi-hole’a izin vermektir (gelişmiş cihazlarda mümkün).

Performans, Gizlilik ve İnce Ayar Önerileri

Kurulumdan sonra yönetim panelinde Query Log bölümünü inceleyin. Burada hangi alan adlarının en çok istek aldığını görürsünüz. Bazı uygulamalar beklenmedik şekilde çok sayıda izleme domain’ine istek atar; Pi-hole bunları görünür kıldığı için aynı zamanda iyi bir “ağ sağlığı” aracıdır.

Engelleme listeleri (adlist) Pi-hole’un bel kemiğidir. Varsayılan listeler çoğu kullanıcı için yeterli olur; fakat daha agresif listeler eklerseniz bazı sitelerde giriş, video oynatma veya yorum bölümleri bozulabilir. Bu noktada Whitelist kullanmak gerekir. Tavsiyem, önce birkaç gün standart ayarlarla izleyip sorun yaşadığınız domain’leri tek tek beyaz listeye almaktır. Böylece “her şeyi engelleyeyim” yaklaşımının getirdiği kırılmaları minimize edersiniz.

İleri seviye bir adım olarak Pi-hole’un yukarı akış DNS’ini (Upstream DNS) seçerken DoH/DoT düşünebilirsiniz. Pi-hole tek başına DoH sunmaz; ancak Unbound gibi yerel bir recursive resolver ile birleştirildiğinde hem gizlilik hem de hız tarafında kazanımlar elde edilir. Yine de başlangıç için Cloudflare, Quad9 veya Google DNS gibi sağlayıcılar yeterli olabilir; önemli olan trafik ve log kontrolünün Pi-hole panelinde toplanmasıdır.

Artılar, Eksiler ve Sonuç

Artılar: Tüm cihazlarda tek noktadan reklam/izleyici engelleme, düşük kaynak tüketimi, kolay yönetim paneli, ağ trafiğine dair görünürlük. Eksiler: DNS altyapınız Pi-hole’a bağımlı hale gelir; cihaz kapanırsa ağda çözümleme sorunları yaşanabilir. Ayrıca bazı bankacılık veya medya servisleri zaman zaman engellemeye takılabilir ve beyaz liste gerekebilir.

Genel olarak Pi-hole’u Docker ile kurmak, ev ağında “sessizce” büyük fark yaratan modern bir iyileştirme. Doğru IP planlaması ve router ayarıyla, 30 dakikada kurulup uzun süre dokunmadan çalışabilen bir çözüm elde edersiniz. Eğer evde çok sayıda cihaz varsa ve özellikle mobil uygulamalardaki izleyiciler can sıkıyorsa, Pi-hole kesinlikle denemeye değer.

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

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

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

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

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

wsl --install

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

sudo apt update && sudo apt upgrade -y

Podman kurulumu (Ubuntu)

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

sudo apt install -y podman

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

podman --version

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

Rootless çalışma ve temel ayarlar

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

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

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

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

podman run --rm hello-world

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

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

alias docker=podman

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

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

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

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

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

Podman Compose: Docker Compose alternatifi

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

sudo apt install -y podman-compose

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

podman-compose up -d

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

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

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

podman images

podman ps -a

podman system prune -a

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

Ne zaman Podman, ne zaman Docker Desktop?

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

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

Proxmox ve Ubuntu Laboratuvar Kurulum Rehberi (Uçtan Uca)

A'dan Z'ye Proxmox & Ubuntu Sanallaştırma Laboratuvarı

Bu rehber, fiziksel sunucunun Wi-Fi ile internete bağlanmasından, izole ağ yapılandırmasına ve sanal makinelerin benzersizleştirilmesine kadar tüm teknik adımları içerir.

1. Proxmox Host: Wi-Fi ve İnternet Erişimi (CLI)

Sunucuyu kablosuz ağ üzerinden internete çıkarmak için Shell üzerinden uygulanan adımlar:

# Wi-Fi araçlarını yükle ve şifreyi yapılandır
apt install wpasupplicant
wpa_passphrase "SSID_ADINIZ" "SIFRENIZ" >> /etc/wpa_supplicant/wpa_supplicant.conf

# Arayüzü ayağa kaldır ve IP al
ip link set wlp4s0 up
dhclient wlp4s0

2. Proxmox Sanal Ağ ve NAT Yapılandırması

Sanal makinelerin internete çıkabilmesi için 10.10.10.0/24 bloğunun `vmbr1` üzerinden tanımlanması:

# nano /etc/network/interfaces dosyasına ekle:
auto vmbr1
iface vmbr1 inet static
    address 10.10.10.1/24
    bridge-ports none
    bridge-stp off
    bridge-fd 0

İnternet Paylaşımı (NAT) Komutları:

• IP Forwarding: echo 1 > /proc/sys/net/ipv4/ip_forward
• NAT Kuralı: iptables -t nat -A POSTROUTING -s '10.10.10.0/24' -o wlp4s0 -j MASQUERADE

3. 1 TB Disk Yönetimi (LVM-Thin CLI)

wipefs -a /dev/sdb
pvcreate /dev/sdb
vgcreate depo1tb /dev/sdb
lvcreate -L 920G -T depo1tb/thinpool_depo
pvesm add lvmthin DEPO_ALANI --vgname depo1tb --thinpool thinpool_depo --content rootdir,images

4. Ubuntu Master Template Hazırlığı

Şablon oluşturmadan önce ana makinede yapılan erişim ayarları:

• SSH Enable: sudo apt install openssh-server -y && sudo systemctl enable --now ssh
• Ubuntu Firewall Disable: sudo ufw disable
• Proxmox Firewall Off: VM Donanım -> Network -> Firewall: Off

5. Klon Sonrası Benzersizleştirme (Kritik)

Klonlanan makinede çakışmaları önlemek için terminalden uygulanan adımlar:

# 1. Hostname Değiştir
sudo hostnamectl set-hostname yeni-sunucu

# 2. IP Güncelle (Netplan)
sudo nano /etc/netplan/00-installer-config.yaml (IP: 10.10.10.11)
sudo netplan apply

# 3. Machine-ID Sıfırla ve Yeniden Başlat
echo "" | sudo tee /etc/machine-id && sudo systemd-machine-id-setup && sudo reboot

6. Dış Erişim (Windows Route)

Kendi bilgisayarınızdan 10.10.10.x ağına ulaşmak için Windows CMD (Yönetici) üzerinden:

route add 10.10.10.0 mask 255.255.255.0 192.168.1.50

Laboratuvar Altyapısı Tamamlandı. Zabbix Kurulumuna Hazır!

Cloudflare Zero Trust ile Uzak Erişimde VPN’siz Güvenli Tünel: Tailscale Alternatifi mi?

VPN yorgunluğuna modern bir alternatif

Uzaktan çalışma kalıcılaştıkça, ofis ağına erişim için klasik VPN kurulumları birçok ekipte “gerekli ama can sıkan” bir rutine dönüştü. Sertifika yenilemeleri, port yönlendirme, split-tunnel karmaşası, performans düşüşü ve mobil cihazlarda kopmalar… Bu noktada Cloudflare Zero Trust, özellikle küçük ekiplerden ileri seviye homelab kullanıcılarına kadar geniş bir kitle için “VPN’siz güvenli erişim” fikrini pratik hale getiriyor. Bu yazıda, Cloudflare’ın WARP ve Tunnel yaklaşımını adım adım kurulum mantığıyla ele alacak; hangi senaryolarda Tailscale benzeri çözümlere alternatif olabileceğini inceleyeceğiz.

Zero Trust mimarisi neyi değiştiriyor?

Geleneksel VPN’de cihaz “ağın içine” girer; yetki kontrolü çoğu zaman ağ segmenti ve firewall kurallarıyla yapılır. Zero Trust yaklaşımı ise “önce doğrula, sonra en az ayrıcalıkla eriştir” felsefesine dayanır. Cloudflare tarafında bu; kullanıcı kimliği (SSO/OTP), cihaz durumu, uygulama bazlı erişim ve kayıtlı politikalarla yönetilir. Yani hedef, tüm ağa tünel açmak değil; ihtiyaç duyulan uygulamaya güvenli bir şekilde eriştirmektir. Özellikle admin panelleri, dahili dashboard’lar, Git sunucuları, staging ortamları veya NAS arayüzleri gibi “internet’e açmak istemediğiniz” servisler için bu yaklaşım oldukça temiz çalışır.

Ön hazırlık: Hesap, alan adı ve temel kavramlar

Başlamak için bir Cloudflare hesabına ve mümkünse Cloudflare’a yönlendirilmiş bir alan adına ihtiyacınız var. Şu iki kavramı netleştirelim: Cloudflare Tunnel, içerideki bir sunucudan Cloudflare’a “dışarı doğru” güvenli bir bağlantı başlatır; böylece ev/iş yerindeki NAT arkasında kalan servisleri port açmadan yayınlayabilirsiniz. Access ise bu yayına kimlerin, hangi koşullarda erişeceğini belirler. Kullanıcı tarafında ise WARP istemcisi, cihazın trafiğini belirli politikalara göre Cloudflare ağı üzerinden yönetmenizi sağlar (her zaman şart değil, birazdan anlatacağım).

Adım adım: Cloudflare Tunnel ile içerideki servisi yayınlama

Kurulumun en kritik noktası, içeride erişmek istediğiniz servisin (ör. 192.168.1.10:3000 üzerindeki bir dashboard) dışarıdan port açmadan erişilebilir hale gelmesidir. Bunun için içerideki makineye cloudflared ajanını kurarsınız. Kurulum komutu işletim sistemine göre değişse de mantık sabittir: Cloudflare panelinde bir “Tunnel” oluşturulur, size verilen kimlik bilgileriyle ajan yetkilendirilir ve bir yönlendirme kuralı tanımlanır.

Ardından “Public Hostname” kısmında örneğin dash.ornekalanadi.com gibi bir alt alan adı belirleyip, hedefi http://localhost:3000 veya yerel IP:port şeklinde tanımlarsınız. Burada önemli bir avantaj var: Port açmadığınız için saldırı yüzeyiniz ciddi şekilde azalır; ayrıca IP’niz değişse bile tünel içeriden çıktığı için erişim bozulmaz. Ev internetinde CGNAT kullananlar için bu, tek başına büyük bir kazanım.

Kimlik doğrulama: Access politikalarıyla “kim girebilir?” sorusunu çözmek

Tunnel tek başına servisi yayınlar; güvenlik tarafı ise Access ile tamamlanır. Cloudflare Zero Trust panelinde “Access → Applications” bölümünden az önce yayınladığınız host için bir uygulama tanımlarsınız. Sonrasında bir politika eklersiniz: örneğin sadece belirli e-posta alan adlarından (@sirket.com) gelen kullanıcılar girsin; ya da sadece tek tek tanımladığınız e-posta adresleri izinli olsun.

Daha ileri senaryoda SSO (Google Workspace, Microsoft Entra ID vb.) entegre edip MFA zorunlu kılabilirsiniz. Böylece servis internete “açık” görünse bile, gerçek erişim bir kimlik katmanının arkasında kalır. Üstelik bu, uygulamanızın kendi login sisteminden bağımsız bir ek güvenlik perdesi oluşturur.

WARP istemcisi ne zaman gerekli?

Birçok kişi WARP’ı “VPN gibi” düşünür; aslında WARP çoğu zaman uç cihaz politikasını işletmek için kullanılır. Eğer hedefiniz sadece web tabanlı bir arayüze (HTTP/HTTPS) erişmekse, Tunnel + Access çoğu senaryoda yeterlidir ve kullanıcılar tarayıcı üzerinden doğrulanarak erişir. Ancak SMB/RDP/SSH gibi tarayıcı dışı protokoller veya özel IP aralıklarına erişim gibi durumlarda WARP + Private Network kurgusu devreye girer. Bu sayede cihaz, Cloudflare üzerinden iç ağdaki belirli IP aralıklarına güvenli biçimde yönlendirilir.

Performans, güvenlik ve pratik kullanım değerlendirmesi

Performans tarafında en büyük değişken, Cloudflare POP noktalarına olan yakınlığınız ve içerideki uplink kalitenizdir. Web panelleri ve API erişimleri genellikle akıcı çalışır. Güvenlikte ise port açmamak, kaba kuvvet denemelerini ve servis keşfini azaltır; Access katmanı da kimlik doğrulamayı standartlaştırır. Günlük pratikte en sevdiğim taraf, yeni bir servis eklemenin “bir DNS kaydı + bir Access politikası” mantığıyla hızlıca yapılabilmesidir.

Peki Tailscale ile kıyas? Tailscale daha çok “cihazdan cihaza özel ağ” hissini çok iyi verir; Cloudflare Zero Trust ise “uygulama bazlı yayın ve kontrol” konusunda güçlüdür. Eğer hedefiniz ekip içi dahili web uygulamalarını güvenli sunmak ve merkezi erişim politikası yönetmekse Cloudflare yaklaşımı daha derli toplu olabilir. Tam tersine, cihazlar arası esnek dosya paylaşımı, mesh ağ kolaylığı ve geniş protokol çeşitliliği arıyorsanız Tailscale hâlâ çok iddialı.

Sonuç: Kimler denemeli?

Evinde NAS arayüzünü, Home Assistant’ı, bir monitoring panelini veya şirket içinde staging ortamını internet’e “açmadan” uzaktan erişmek isteyen herkes Cloudflare Zero Trust’ı denemeli. Özellikle port yönlendirme yapmadan ve MFA ile güvenliği artırarak ilerlemek isteyenler için modern bir çözüm sunuyor. İlk kurulumda kavramlar biraz yeni gelebilir; fakat bir kez oturduğunda, VPN’e dönüş ihtiyacı ciddi ölçüde azalıyor.

WebAssembly ile Tarayıcıda Yüksek Performans: Rust Kullanarak Adım Adım İlk Modülünü Yayınla

Giriş: Neden WebAssembly (Wasm)?

Web uygulamalarında performans ihtiyacı arttıkça, tarayıcının “sadece JavaScript” ile sınırlı olmadığı gerçeği daha fazla önem kazanıyor. WebAssembly (Wasm), C/C++ veya Rust gibi dillerle derlenen kodu tarayıcıda güvenli bir sanal makinede çalıştırarak, özellikle CPU yoğun işlerde (şifreleme, görüntü işleme, sıkıştırma, fizik simülasyonları, veri pars etme) ciddi hız avantajı sunuyor. Bu yazıda ileri seviye ama uygulanabilir bir örnekle, Rust kullanarak Wasm modülü üretmeyi ve bunu modern bir web projesinde çalıştırmayı adım adım anlatacağım.

Hangi Senaryolarda Wasm Mantıklı?

Wasm her şeyin ilacı değil. DOM manipülasyonu, UI güncellemeleri ve tipik CRUD akışları JavaScript/TypeScript ile zaten yeterince hızlıdır. Wasm’ın güçlü olduğu taraf, hesaplama ağırlıklı fonksiyonları izole edip hızlandırmaktır. Örneğin JSON parse etmek yerine ikili format işlemek, büyük diziler üzerinde matematik, kripto, audio DSP veya WebGPU öncesi hazırlık işlemleri gibi alanlarda fark yaratır. Ayrıca Rust tarafında bellek güvenliği avantajı da cabasıdır.

Kurulum: Rust + Wasm Toolchain

Öncelikle Rust kurulu olmalı. Rust’ın resmi aracı olan rustup ile kurulum yaptıktan sonra Wasm hedefini ekleyeceğiz. Ardından JavaScript ile köprü kurmayı kolaylaştıran wasm-bindgen ekosisteminden yararlanacağız. Terminalde aşağıdaki adımları uygulayın:

1) Wasm hedefi: rustup target add wasm32-unknown-unknown

2) wasm-pack (opsiyonel ama pratik): cargo install wasm-pack

wasm-pack, derleme ve paketleme sürecini tek komutla yönetmenizi sağlar. Bu sayede npm tabanlı projelere Wasm çıktısını daha rahat entegre edebilirsiniz.

Örnek Proje: Rust ile Hızlı Fibonacci (Memoization’lı)

Klasik Fibonacci örneği basit görünse de, burada amaç “Wasm köprüsü” kurmayı göstermek. Gerçek projede benzer şekilde sık çağrılan fonksiyonlarınızı Wasm’a taşıyabilirsiniz. Yeni bir klasör açıp Rust kütüphanesini oluşturalım:

cargo new --lib wasm-fibo

Proje klasöründe Cargo.toml dosyasını Wasm uyumlu hale getirelim. Kütüphaneyi cdylib olarak derlemek gerekiyor. Ayrıca wasm-bindgen ekleyeceğiz:

Cargo.toml içinde şu alanlar olmalı:

[lib]
crate-type = ["cdylib", "rlib"]

[dependencies]
wasm-bindgen = "0.2"

Şimdi src/lib.rs dosyasını düzenleyelim. Basit bir memoization yaklaşımıyla, büyük n değerlerinde gereksiz tekrar hesaplamayı azaltacağız:

Not: Rust’ta Wasm tarafında performans için panik mesajlarını kapatmak, uygun allocator seçmek gibi ek optimizasyonlar da yapılabilir; ama bu yazıda temeli sağlam kurmaya odaklanıyoruz.

src/lib.rs örneği:

use wasm_bindgen::prelude::*;

#[wasm_bindgen]
pub fn fib(n: u32) -> u64 {
    let mut a: u64 = 0;
    let mut b: u64 = 1;
    for _ in 0..n {
        let tmp = a + b;
        a = b;
        b = tmp;
    }
    a
}

Derleme: wasm-pack ile Paket Üretmek

Şimdi derleyelim. Proje kök dizininde:

wasm-pack build --target web

Bu komut, pkg adlı bir klasör oluşturur. İçinde .wasm dosyası, JavaScript bağlayıcıları ve package.json benzeri paket metadata’ları yer alır. --target web seçeneği, doğrudan tarayıcıda ES Module olarak kullanım senaryosuna uygundur.

Tarayıcıda Kullanım: Minimal HTML + JS

Wasm çıktısını bir web projesinde kullanmak için birçok yol var: Vite, Webpack, Next.js veya sadece statik dosyalar. En kolay anlaşılır yöntem için “düz” bir kullanım mantığını tarif edelim: pkg klasörünü web kökünüze kopyalayın ve modülü ES Module olarak import edin.

Örnek JavaScript (ör. main.js) akışı şu şekilde olur:

import init, { fib } from "./pkg/wasm_fibo.js";

async function run() {
    await init();
    console.log("fib(50) =", fib(50));
}

run();

Buradaki kritik nokta init() fonksiyonudur. Wasm modülünün yüklenmesi ve başlatılması bu aşamada gerçekleşir. Eğer init çağrısını atlar veya yanlış path verirseniz, tarayıcı modülü bulamaz ya da instantiate edemez.

Performans İpuçları ve Sık Yapılan Hatalar

1) Veri kopyalama maliyetine dikkat: Wasm ile JS arasında büyük diziler taşıyorsanız, asıl darboğaz “kopyalama” olabilir. Mümkün olduğunca TypedArray ve paylaşımlı bellek (uygun senaryolarda) stratejilerini araştırın.

2) Küçük fonksiyonları Wasm’a taşımayın: Çok sık ama çok küçük işler için köprü maliyeti performansı düşürebilir. Wasm’ı “toplu iş” mantığıyla kullanmak genelde daha verimlidir.

3) Release derleme kullanın: wasm-pack zaten uygun optimizasyonları hedefler; yine de üretimde “debug” benzeri çıktılarla test yapmayın. Boyut ve hız farkı barizdir.

4) Hata ayıklama yaklaşımı: Rust tarafında panik durumlarını yönetmek ve tarayıcı konsolunda anlamlı hata görmek için ek araçlar (ör. console_error_panic_hook) kullanılabilir. Proje büyüdükçe bu tür “geliştirici deneyimi” bağımlılıkları ciddi zaman kazandırır.

Sonuç: Rust + Wasm ile Modern Web’e Performans Katmanı

Bu rehberde, Rust ile basit bir fonksiyonu WebAssembly’ye derleyip tarayıcıda çalıştırmanın temel yolunu kurduk. Buradaki yapı taşları gerçek projelerde de aynıdır: Rust tarafında Wasm uyumlu kütüphane, wasm-bindgen ile arayüz, wasm-pack ile paketleme ve tarayıcıda modül yükleme. Eğer uygulamanızda CPU yoğun bir bölüm varsa, doğru tasarımla Wasm size hem performans hem de daha güvenli bir kod tabanı sağlayabilir.

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.

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.