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.

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

Docker Desktop olmadan neden Docker?

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

Ön koşullar

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

1) WSL 2 ve Ubuntu kurulumu

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

wsl --install

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

wsl --list --online

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

wsl --install -d Ubuntu

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

2) Docker Engine’i WSL içinde kurma

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

sudo apt update && sudo apt upgrade -y

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

sudo apt install -y ca-certificates curl gnupg

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

sudo install -m 0755 -d /etc/apt/keyrings

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

sudo chmod a+r /etc/apt/keyrings/docker.gpg

echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo $VERSION_CODENAME) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

Şimdi Docker Engine ve gerekli bileşenleri kurun:

sudo apt update

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

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

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

sudo nano /etc/wsl.conf

İçine şunu ekleyin:

[boot]
systemd=true

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

wsl --shutdown

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

sudo systemctl enable docker

sudo systemctl start docker

sudo systemctl status docker

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

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

sudo usermod -aG docker $USER

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

docker run --rm hello-world

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

5) Docker Compose ve örnek proje

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

docker compose version

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

docker run --rm -p 8080:80 nginx

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

Performans ve dosya sistemi ipuçları

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

Sık karşılaşılan sorunlar

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

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

Sonuç

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

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

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

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

Ön koşullar ve genel yaklaşım

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

1) WSL 2’yi kurma ve doğrulama

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

Komut: wsl --install

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

Komut: wsl -l -v

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

Komut: wsl --set-version Ubuntu 2

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

2) Ubuntu içinde Docker Engine kurulumu

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

sudo apt update && sudo apt upgrade -y

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

Docker’ın resmi deposunu ekleyip GPG anahtarını tanımlayın:

sudo install -m 0755 -d /etc/apt/keyrings

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

sudo chmod a+r /etc/apt/keyrings/docker.gpg

Depo kaydını ekleyin:

echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo $VERSION_CODENAME) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

Docker Engine’i kurun:

sudo apt update

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

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

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

sudo nano /etc/wsl.conf

İçine şunu ekleyin:

[boot]
systemd=true

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

PowerShell: wsl --shutdown

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

sudo systemctl enable docker

sudo systemctl start docker

systemctl status docker --no-pager

4) “sudo” yazmadan Docker kullanmak

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

sudo usermod -aG docker $USER

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

docker run --rm hello-world

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

5) Docker Compose ve örnek proje

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

docker compose version

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

docker compose up -d

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

docker compose down

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

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

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

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

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

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

Kapanış

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