Windows 11’de WSL 2 ile Docker Desktop Kullanmadan Docker Kurulumu ve Hızlandırma Rehberi

Giriş: Neden Docker Desktop’sız Docker?

Windows 11’de Docker kullanmanın en popüler yolu Docker Desktop olsa da, her senaryoda en iyi seçenek olmayabiliyor. Lisans politikaları, sistem kaynak tüketimi, kurumsal kısıtlar veya daha “çıplak” bir kurulum isteği gibi sebeplerle WSL 2 üzerinde doğrudan Docker Engine kurmak hem daha hafif hem de daha kontrol edilebilir bir yaklaşım sunuyor. Bu yazıda, Windows 11 üzerinde WSL 2 kullanarak Docker’ı Docker Desktop olmadan kurmayı, Windows ile entegrasyonu sağlamayı ve performansı iyileştirecek birkaç ileri seviye ayarı adım adım ele alacağım.

1) Ön Koşullar: WSL 2 ve Dağıtım Seçimi

Öncelikle WSL 2’nin etkin olduğundan emin olmalısınız. Windows 11’de çoğu sistemde WSL zaten sorunsuz çalışır; yine de güncel bir kurulum için PowerShell’i yönetici olarak açıp WSL’yi kurmak veya güncellemek iyi bir başlangıçtır. Ardından Ubuntu 22.04/24.04 gibi yaygın bir dağıtım seçmenizi öneririm; dokümantasyon ve topluluk desteği güçlü olduğu için sorun çözmek daha kolay olur.

Kontrol: WSL sürümünüzü görmek için Windows tarafında wsl -l -v komutunu kullanabilirsiniz. Dağıtımınızın sürümü “2” değilse WSL 2’ye yükseltmeniz gerekir. Ayrıca BIOS/UEFI’de sanallaştırma (Virtualization) açık olmalıdır; aksi halde WSL 2 beklenmedik şekilde yavaşlar veya hiç çalışmaz.

2) WSL İçinde Docker Engine Kurulumu

Docker Desktop kurmadan Docker çalıştırmanın ana fikri şu: Docker Engine, Linux ortamında çalışır; biz de bunu WSL 2 içindeki Ubuntu’da kurarız. Ardından Docker komutlarını aynı WSL ortamında kullanırız. Böylece arka planda ayrı bir GUI uygulaması değil, standart Linux servisleri devreye girer.

Adımlar: Ubuntu terminalini açın ve sisteminizi güncelleyin. Daha sonra Docker’ın resmi deposunu ekleyerek Docker Engine kurun. Depodan kurmak, dağıtım deposundaki eski sürümlere göre genellikle daha güncel bir Docker sürümü sağlar. Kurulumdan sonra Docker servisinin çalıştığını doğrulamak için docker version ve docker run hello-world komutlarını deneyebilirsiniz.

Kurulum sonrası sık yapılan bir ayar da kullanıcıyı “docker” grubuna eklemektir. Böylece her komutta sudo yazmanız gerekmez. Bu değişiklikten sonra WSL oturumunu kapatıp yeniden açmanız gerekir; aksi halde yetki değişimi görünmeyebilir.

3) systemd ile Servis Yönetimi (İleri Seviye ve Önerilen)

Eskiden WSL’de servis yönetimi daha zahmetliydi; ancak modern Windows 11 ve güncel WSL sürümlerinde systemd desteği bulunuyor. Docker Engine’i düzgün bir Linux makinesindeki gibi yönetmek istiyorsanız systemd oldukça kritik. Böylece Docker servisi WSL oturumu açıldığında otomatik başlar ve kapanışta düzgün durur.

systemd’yi etkinleştirmek için WSL içindeki yapılandırma dosyasına ilgili ayarı eklemeniz gerekir. Değişiklikten sonra Windows tarafında wsl --shutdown çalıştırıp WSL’yi yeniden başlatmak gerekir. Ardından Ubuntu içinde systemctl status docker ile servisin durumunu kontrol edebilirsiniz.

4) Windows Terminal ve VS Code ile Akıcı Geliştirme

Bu kurulumun pratik tarafı, geliştirme araçlarıyla birleştiğinde ortaya çıkar. Windows Terminal üzerinden Ubuntu profilinizi açıp Docker komutlarını doğrudan çalıştırabilirsiniz. Eğer Visual Studio Code kullanıyorsanız, Remote - WSL eklentisi ile projenizi WSL dosya sistemi içinde açıp konteyner build/run süreçlerini Linux tarafında yürütebilirsiniz. Bu, özellikle Node.js, Python ve Go projelerinde dosya izinleri ve satır sonu farklılıklarından kaynaklı problemleri ciddi şekilde azaltır.

Önemli not: Proje dosyalarınızı mümkünse WSL dosya sisteminde tutun (ör. /home/kullanici/proje). Windows sürücüsü üzerinden (ör. /mnt/c/...) çalışmak, özellikle çok sayıda küçük dosya içeren projelerde I/O performansını düşürebilir.

5) Performans İyileştirmeleri: .wslconfig ile Kaynak Sınırları

Docker konteynerleri CPU ve RAM tüketimini hızla artırabilir. WSL 2, varsayılan olarak sistem kaynaklarını dinamik kullanır; bu iyi olsa da bazı durumlarda RAM şişmesi veya disk kullanımının kontrolsüz büyümesi can sıkabilir. Windows kullanıcı dizininizde yer alan .wslconfig dosyasıyla WSL’nin kullanacağı kaynakları sınırlayabilirsiniz.

Örneğin RAM’i 8 GB ile sınırlamak, CPU sayısını belirlemek veya swap boyutunu ayarlamak mümkündür. Bu ayarlar özellikle aynı anda tarayıcı, IDE ve birkaç konteyner çalıştıran geliştiriciler için sistemin tepkiselliğini korur. Ayarlardan sonra wsl --shutdown ile WSL’yi yeniden başlatmayı unutmayın.

6) Ağ ve Port Yayınlama Mantığı: “localhost” Gerçeği

WSL 2, kendi sanal ağ katmanına sahip olduğu için “localhost” konusu zaman zaman kafa karıştırır. İyi haber şu: Güncel Windows 11 sürümlerinde WSL ile Windows arasında “localhost” üzerinden port yönlendirme çoğu senaryoda otomatik çalışır. Yani WSL içinde 8080 portunu yayınlayan bir konteyneri, Windows’ta tarayıcıdan http://localhost:8080 ile açabilirsiniz.

Yine de kurumsal güvenlik yazılımları veya özel firewall kuralları port erişimini engelleyebilir. Böyle bir durumda Windows Firewall izinlerini kontrol etmek, konteynerin gerçekten port yayınladığını docker ps ile doğrulamak ve WSL’nin IP adresini kullanarak test yapmak işe yarar.

7) Artılar, Eksiler ve Ne Zaman Tercih Etmeli?

Artılar: Daha az arka plan bileşeni, daha düşük kaynak tüketimi, daha “Linux’a yakın” bir Docker deneyimi ve kurulum üzerinde daha fazla kontrol. Ayrıca bazı kullanıcılar için Docker Desktop’ın getirdiği ekstra katmanlar yerine doğrudan Engine kullanmak daha öngörülebilir.

Eksiler: GUI yönetim paneli yoktur, bazı entegrasyonlar (Kubernetes tek tıkla aç/kapat gibi) Docker Desktop kadar hazır gelmez. Ayrıca birden fazla WSL dağıtımı kullanıyorsanız Docker’ın hangi dağıtımda kurulu olduğu ve nereden çalıştırıldığı konusunu iyi yönetmeniz gerekir.

Sonuç

Windows 11’de WSL 2 üzerinde Docker Engine kurup Docker Desktop kullanmadan çalışmak, özellikle geliştirici odaklı ve performans hassasiyeti olan kullanıcılar için güçlü bir alternatiftir. Doğru yapılandırma ile servis yönetimi systemd üzerinden düzenli çalışır, proje dosyalarını WSL içinde tutarak I/O performansı korunur ve .wslconfig ile sistem kaynakları kontrol altına alınır. Eğer hedefiniz “hafif, hızlı ve kontrol edilebilir” bir Docker ortamıysa bu yöntem, günlük geliştirme akışınıza beklediğinizden daha rahat uyum sağlayacaktır.

Windows 11’de WSL2 ile Docker Desktop Kullanmadan Docker Kurulumu ve Performans Ayarları

WSL2 ile “hafif” Docker fikri neden mantıklı?

Windows 11 üzerinde Docker çalıştırmanın en popüler yolu Docker Desktop. Ancak bazı senaryolarda (kurumsal lisans politikaları, kaynak tüketimi, arka planda çalışan servisler, ekstra arayüz katmanı) Docker Desktop yerine doğrudan WSL2 içinde Docker Engine kurmak daha temiz bir çözüm olabiliyor. Bu yazıda, Docker Desktop kullanmadan WSL2 üzerinde Docker’ı kuracağız; ardından performans ve disk kullanımını iyileştiren birkaç kritik ayarı yapacağız.

Ön koşullar

Gerekenler: Windows 11, yönetici yetkisi, WSL2 desteği ve bir Linux dağıtımı (Ubuntu önerilir). Windows tarafında WSL2 etkin değilse önce etkinleştirmeniz gerekir. Ayrıca BIOS/UEFI’de sanallaştırmanın açık olması, WSL2’nin stabil çalışması için önemlidir.

Adım 1: WSL2 ve Ubuntu kurulumu

PowerShell’i yönetici olarak açıp aşağıdaki komutu çalıştırın. Bu komut WSL’yi kurar ve varsayılan olarak Ubuntu’yu indirip kurabilir:

Komut: wsl --install

Kurulumdan sonra bilgisayarınızı yeniden başlatın. Ardından Ubuntu ilk açılışta kullanıcı adı/şifre oluşturmanızı ister. Mevcut WSL dağıtımlarınızı görmek için:

wsl -l -v

Burada dağıtımınızın Version 2 olduğundan emin olun. Değilse:

wsl --set-version Ubuntu 2

Adım 2: WSL2 içinde Docker Engine kurulumu

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

sudo apt update && sudo apt upgrade -y

Docker’ın resmi deposunu eklemek güncel sürüm için daha sağlıklıdır. Sırasıyla şu komutları çalıştırın:

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

Şimdi Docker Engine ve gerekli bileşenleri kurun:

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

Adım 3: Docker’ı root’suz kullanmak (sudo derdini bitirin)

Geliştirici deneyimi açısından en önemli adım: kullanıcıyı docker grubuna eklemek. Böylece her komutta sudo yazmanız gerekmez.

sudo usermod -aG docker $USER

Değişikliğin uygulanması için Ubuntu oturumunu kapatıp açın ya da şu komutla kabuğu yenileyin:

newgrp docker

Docker’ın çalıştığını doğrulamak için:

docker run --rm hello-world

Adım 4: WSL2’de Docker servisini otomatik başlatma

WSL, klasik Linux gibi her zaman systemd ile açılmayabilir. Windows 11 ve güncel WSL sürümlerinde systemd desteği var. Etkinleştirerek Docker’ın açılışta başlamasını sağlayabilirsiniz.

WSL içinde /etc/wsl.conf dosyasını düzenleyin:

sudo nano /etc/wsl.conf

İçerik şu şekilde olsun:

[boot] systemd=true

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

wsl --shutdown

Ubuntu’yu tekrar açınca Docker servisini başlatıp kalıcı hale getirebilirsiniz:

sudo systemctl enable --now docker

Adım 5: Performans için kritik ayar: proje dosyalarını nereye koymalısınız?

WSL2’de en sık yapılan hata, proje klasörünü /mnt/c gibi Windows dosya sistemi altında tutup Docker build ve bind mount işlemlerini burada yapmak. Bu kullanım çalışır ama dosya erişimi katmanı nedeniyle özellikle Node.js, PHP, Python gibi çok sayıda küçük dosya okuyan projelerde performans düşebilir.

Öneri: Kodunuzu WSL2 Linux dosya sistemi içinde (ör. /home/kullanici/proje) tutun. Windows’tan erişmek için de Dosya Gezgini’ne \\wsl$ yazarak Ubuntu dizinlerine ulaşabilirsiniz. Bu sayede Docker build süreleri ve canlı geliştirme (hot reload) daha stabil hale gelir.

Adım 6: Disk şişmesini kontrol etme ve temizlik

Docker kullanırken imajlar ve kullanılmayan katmanlar zamanla disk alanını şişirir. Düzenli aralıklarla temizlik yapmak iyi bir alışkanlık:

docker system df

docker system prune -a

Eğer sadece kullanılmayan container’ları ve dangling imajları temizlemek isterseniz daha güvenli bir yaklaşım seçebilirsiniz. Ancak prune -a tüm kullanılmayan imajları da siler; tekrar gerektiğinde yeniden indirmek zorunda kalırsınız.

Sık karşılaşılan sorunlar

“Cannot connect to the Docker daemon”: Docker servisi çalışmıyor olabilir. Systemd etkinse sudo systemctl status docker ile kontrol edin. Değilse geçici olarak sudo dockerd ile daemon başlatılabilir, fakat kalıcı çözüm systemd’yi aktif etmektir.

Port çakışmaları: Windows’ta aynı portu kullanan bir servis varsa container ayağa kalksa bile erişim sorunları yaşayabilirsiniz. netstat ile Windows tarafında portu kim kullanıyor bakın ve compose dosyanızdaki portları değiştirin.

Ağ erişimi: WSL2 ağ katmanı NAT üzerinden çalışır. Yerel ağdan WSL2 içindeki bir servise erişmek bazen ekstra yönlendirme gerektirebilir; çoğu geliştirme senaryosunda ise localhost yeterlidir.

Sonuç

Docker Desktop olmadan WSL2 üzerinde Docker Engine kurmak, daha az arka plan bileşeniyle daha “Linux’a yakın” bir deneyim sunar. Özellikle performans hassas projelerde dosyaları Linux tarafında tutmak ve systemd ile Docker’ı otomatik başlatmak günlük kullanım konforunu ciddi şekilde artırır. Bu kurulumla hem docker compose kullanabilir hem de modern buildx özelliklerinden faydalanabilirsiniz.

Docker ile Yerel LLM Çalıştırma: Ollama + Open WebUI Kurulumu ve İnce Ayarları

Yerelde Yapay Zekâ: Neden Ollama?

Bulut tabanlı yapay zekâ servisleri pratik olsa da her proje için ideal değil. Gizlilik, maliyet, gecikme ve internet bağımlılığı gibi konular devreye girdiğinde yerel (local) LLM çalıştırmak çok daha mantıklı hale geliyor. Bu yazıda, güncel ve popüler bir yöntemle Ollama üzerinden bir dil modelini yerelde çalıştırmayı, ardından da Open WebUI ile web arayüzü ekleyerek kullanımı “ChatGPT benzeri” bir seviyeye taşımayı adım adım anlatacağım. Kurulumun odağı Docker olacak; böylece sisteminizi kirletmeden, taşınabilir bir kurulum elde edeceksiniz.

Gereksinimler ve Kısa Hazırlık

Bu rehber, Windows 11 + WSL2, macOS veya Linux üzerinde uygulanabilir. Docker yaklaşımı sayesinde dağıtım farklılıkları minimuma iner. İhtiyacınız olanlar: Docker (Docker Desktop veya Engine), en az 8 GB RAM (14B ve üzeri modellerde 16–32 GB daha rahat), yeterli disk alanı (model boyutuna göre 5–20 GB arası) ve tercihen modern bir CPU. NVIDIA GPU’nuz varsa hız artışı mümkün, ancak bu yazı CPU odaklı ve genel bir kurulum sunuyor.

1) Docker ile Ollama Kurulumu

Önce Ollama’yı bir konteyner olarak ayağa kaldıralım. Aşağıdaki komut, Ollama servisini 11434 portunda yayınlar ve model verisini kalıcı tutmak için volume kullanır:

Komut:

docker run -d --name ollama -p 11434:11434 -v ollama:/root/.ollama ollama/ollama

Kurulum tamamlandıktan sonra çalıştığını doğrulamak için:

docker logs -f ollama

Log akışı sorunsuzsa bir sonraki adım modele karar vermek. Ollama’nın güçlü yanı, modeli tek satır komutla indirip çalıştırabilmesi. Örneğin hafif ve hızlı bir başlangıç için:

docker exec -it ollama ollama run llama3.1

Bu komut, model yoksa indirir ve ardından etkileşimli sohbet başlatır. İndirme süresi internet hızınıza ve model boyutuna bağlıdır.

2) Open WebUI ile Web Arayüzü Eklemek

Terminalde konuşmak tamam, ama günlük kullanımda web arayüzü büyük rahatlık. Open WebUI, Ollama ile çok iyi çalışan modern bir arayüz sunuyor. Aynı makinede çalışacak şekilde şu komutu kullanabilirsiniz:

docker run -d --name open-webui -p 3000:8080 -e OLLAMA_BASE_URL=http://host.docker.internal:11434 -v open-webui:/app/backend/data ghcr.io/open-webui/open-webui:main

Linux üzerinde host.docker.internal her zaman hazır gelmeyebilir. Böyle bir durumda iki pratik seçenek var: (1) Ollama ve Open WebUI’yi aynı Docker ağına almak, (2) Ollama’yı doğrudan makinenin IP’si üzerinden çağırmak. En temiz yöntem, iki servisi aynı ağda koşturmaktır. Örneğin:

docker network create llm-net

docker network connect llm-net ollama

docker rm -f open-webui

docker run -d --name open-webui --network llm-net -p 3000:8080 -e OLLAMA_BASE_URL=http://ollama:11434 -v open-webui:/app/backend/data ghcr.io/open-webui/open-webui:main

Ardından tarayıcıdan http://localhost:3000 adresine giderek arayüzü açın. İlk girişte kullanıcı oluşturmanız istenir. Sonrasında “Models” bölümünden Ollama’da hazır olan modeli seçerek sohbet edebilirsiniz.

3) Performans ve Kalite İçin İnce Ayarlar

Yerel LLM deneyimini iyi yapan şey sadece kurulum değil; doğru model ve doğru ayarlar. Öncelikle model seçimi: Hafif kullanım için 7B–8B sınıfı modeller, kod üretimi için “code” odaklı varyantlar, daha yüksek kalite için 14B ve üzeri tercih edilebilir. RAM sınırlıysa daha küçük modelle başlayın; aksi halde sistem “swap” kullanmaya başlar ve hız dramatik biçimde düşer.

İkinci kritik konu: context (bağlam) uzunluğu. Daha uzun bağlam daha iyi “hatırlama” sağlar, fakat RAM tüketimini artırır. Open WebUI tarafında model ayarlarından bağlam ve üretim parametrelerini (örneğin temperature) dengeli seçmek önemli. Örneğin teknik dokümantasyon, özetleme gibi işlerde daha düşük temperature daha tutarlı sonuç verir.

Üçüncü konu: veri kalıcılığı. Burada hem Ollama hem Open WebUI için volume kullandığımızdan, konteyneri silseniz bile modeller ve sohbet geçmişi (kurulumunuza bağlı olarak) korunur. Bu, Blogger okurları için pratik bir detay: “kur-düşür-kur” senaryolarında zaman kaybetmezsiniz.

4) Basit Bir Sorun Giderme Listesi

Port çakışması: 11434 veya 3000 doluysa, komutlarda host portunu değiştirin (ör. 3001:8080). Model inmiyor: Docker’ın internet erişimini ve disk alanını kontrol edin. Open WebUI model görmüyor: OLLAMA_BASE_URL değerinin doğru olduğundan emin olun; aynı ağdaysa “http://ollama:11434” kullanın. Performans düşük: Daha küçük modele geçin, bağlam uzunluğunu azaltın veya arka planda ağır uygulamaları kapatın.

Sonuç: Yerel LLM ile Kontrol Sizde

Ollama + Open WebUI kombinasyonu, yerelde LLM çalıştırmayı şaşırtıcı derecede erişilebilir hale getiriyor. Docker ile kurulum hem temiz hem de taşınabilir; üstelik gizlilik ve maliyet avantajları da cabası. İster kişisel notlarınızı özetlemek, ister kod fikirleri almak, ister kapalı ağda çalışan bir asistan kurmak isteyin, bu yapı sağlam bir temel sunuyor. Bir sonraki adım olarak farklı modelleri deneyip, Open WebUI’de sistem yönergeleri (system prompt) ve şablonlarla kendi kullanım senaryonuza göre ince ayar yapabilirsiniz.

Web Sitelerinde HTTP/3 (QUIC) Etkinleştirme Rehberi: Nginx + Cloudflare ile Daha Hızlı ve Dayanıklı Bağlantı

HTTP/3 Nedir ve Neden Önemli?

HTTP/3, web trafiğinin yeni nesil taşıma katmanı olarak TCP yerine UDP üzerinde çalışan QUIC protokolünü kullanır. Kulağa “sadece bir sürüm yükseltmesi” gibi gelse de etkisi pratiktir: bağlantı kurulumu daha hızlıdır, paket kaybı yaşandığında toparlanma daha akıllıdır ve aynı bağlantı üzerinde birden fazla istek gönderirken (multiplexing) TCP’nin “head-of-line blocking” sorununu önemli ölçüde azaltır. Mobil ağlar, Wi‑Fi’dan hücresel ağa geçiş gibi sık bağlantı değişimlerinin olduğu senaryolar ve yüksek gecikmeli hatlar HTTP/3’ten ciddi fayda görür.

Bu rehberde, HTTP/3’ü üretim ortamına yakın bir şekilde devreye almak için en pratik iki adımı ele alacağız: Cloudflare üzerinden hızlı aktivasyon ve Nginx tarafında doğru yapılandırma. Amaç, hem gerçek kullanıcı performansını artırmak hem de modern tarayıcıların sunduğu bağlantı optimizasyonlarından yararlanmak.

Ön Koşullar ve Kapsam

HTTP/3 etkinleştirmeden önce şunlara ihtiyacınız var: HTTPS (geçerli TLS sertifikası), alan adınızın DNS kontrolü ve tercihen CDN/Reverse Proxy katmanı. Cloudflare kullanıyorsanız süreç oldukça kolaylaşır çünkü HTTP/3 desteği edge katmanında sunulur. Nginx tarafında HTTP/3 doğrudan “klasik” paketlerle her dağıtımda aynı şekilde gelmeyebilir; bu nedenle burada daha çok doğru mantığı ve yapı taşlarını anlatacağım. Dağıtımınıza göre (Ubuntu, Debian, AlmaLinux vb.) paket isimleri ve sürümler değişebilir.

1) Cloudflare Üzerinden HTTP/3’ü Açma

En hızlı yol Cloudflare’dır: Cloudflare, istemci ile Cloudflare arasındaki bağlantıda HTTP/3’ü açar ve origin sunucunuza (Nginx/Apache) olan bağlantıyı ayrı şekilde yönetir. Böylece origin tarafında HTTP/3 hazır olmasa bile ziyaretçi tarafında kazanım elde edebilirsiniz.

Adımlar: Cloudflare paneline girin, ilgili alan adını seçin. Network (Ağ) sekmesinde HTTP/3 (with QUIC) seçeneğini bulun ve etkinleştirin. Ardından SSL/TLS kısmında modun en az “Full” (tercihen “Full (strict)”) olduğundan emin olun. HTTP/3, HTTPS olmadan zaten çalışmaz; bu adım kritik.

Bu noktadan sonra tarayıcılar, destekliyorsa Cloudflare edge ile HTTP/3 konuşmaya başlar. Ancak bazı durumlarda tarayıcının HTTP/3’e daha hızlı geçmesi için Alt-Svc duyurusu gerekir; Cloudflare bu başlığı genellikle otomatik yönetir.

2) Origin Sunucuda (Nginx) HTTP/3 Hazırlığı

Cloudflare kullanıyor olsanız bile origin tarafını modern tutmak iyi bir pratiktir. Özellikle Cloudflare’siz bir alt alan adı, özel bir edge senaryosu veya farklı CDN kullanımında origin’in HTTP/3 konuşabilmesi değerli olabilir. Nginx dünyasında HTTP/3 desteği, sürüme ve derleme seçeneklerine bağlıdır. Bazı dağıtımlar hazır paket sunarken, bazıları için HTTP/3 özellikli build gerekebilir.

Konsept olarak HTTP/3 için iki temel ihtiyaç vardır: UDP 443 portunun açık olması ve Nginx’in QUIC/HTTP/3 desteğiyle çalışması. Geleneksel HTTPS trafiği TCP/443’te kalırken, HTTP/3 UDP/443 üzerinden gelir. Bu yüzden güvenlik duvarınızda yalnızca TCP/443 açıksa HTTP/3 çalışmaz.

3) Güvenlik Duvarı ve Ağ Ayarları (UDP 443)

Sunucunuzun güvenlik duvarında UDP 443 trafiğine izin verin. Örnek olarak UFW kullanan bir sistemde mantık şudur: TCP 443 zaten açıktır, buna ek olarak UDP 443’ü de açmanız gerekir. Kurumsal ortamlarda load balancer, WAF veya güvenlik cihazlarının UDP trafiğini engellemediğinden emin olun. Aksi halde tarayıcı HTTP/3 denese bile geri düşerek HTTP/2 veya HTTP/1.1’e döner.

4) Nginx Konfigürasyonu: Dinleme ve Alt-Svc Mantığı

HTTP/3’ün “aktif” görünmesi için tarayıcıların bunu keşfetmesi gerekir. Bu genelde Alt-Svc başlığı ile yapılır. Mantık şudur: Sunucu, “aynı host için şu protokol ve port üzerinden de hizmet verebilirim” diye tarayıcıya duyuru yapar. Böylece tarayıcı sonraki isteklerde HTTP/3’e geçer.

Nginx tarafında (HTTP/3 destekli bir build varsayımıyla) tipik yaklaşım; TCP/443 üzerinde HTTP/2’yi açık tutarken aynı zamanda UDP/443 üzerinde QUIC/HTTP/3 dinlemektir. Konfigürasyonun detayı sürüme göre değişse de kontrol etmeniz gerekenler şunlardır: 443 portunda hem TCP hem UDP dinleme, TLS ayarlarının doğru olması, ve yanıt başlıklarında Alt-Svc duyurusunun bulunması. Alt-Svc örneği genellikle “h3=\":443\"; ma=...” gibi bir değer taşır; “ma” süresi tarayıcının bu bilgiyi ne kadar cache’leyeceğini belirler.

Ek olarak, HTTP/3 ile birlikte TLS 1.3 pratikte standarttır. Bu nedenle TLS yapılandırmanızın güncel olduğundan, eski şifre kümelerine bel bağlamadığınızdan ve sertifika zincirinizin doğru sunulduğundan emin olun.

5) Doğrulama: HTTP/3 Çalışıyor mu?

Değişikliklerden sonra test etmek önemlidir. En pratik yöntemlerden biri Chromium tabanlı tarayıcılarda geliştirici araçlarıdır: Network sekmesinde ilgili isteğin “Protocol” alanında h3 veya benzeri bir ifade görmeniz beklenir. Alternatif olarak komut satırında HTTP/3 destekli bir istemci ile (örneğin h3 destekli curl varyantları veya özel test araçları) hedef URL’yi sorgulayabilirsiniz. Eğer HTTP/3 devreye girmiyorsa genellikle sorunlar üç noktada toplanır: UDP 443 kapalı, Alt-Svc duyurusu yok veya proxy/CDN katmanının ayarları.

6) Performans ve SEO Açısından Etkisi

HTTP/3 tek başına “SEO puanı” veren bir sihir değildir; ancak hız ve kararlılık üzerinden dolaylı katkı sağlar. Daha hızlı bağlantı kurulumu ve özellikle mobil ağlarda daha stabil veri akışı, Core Web Vitals metriklerine olumlu yansıyabilir. Ayrıca modern tarayıcılar HTTP/3’e geçebildiğinde, yoğun istekli sayfalarda kullanıcı deneyimi daha tutarlı hale gelir. Yine de unutmayın: asıl kazanç; görsel optimizasyonu, doğru cache stratejisi, sıkıştırma (Brotli), kritik CSS ve iyi bir CDN kurgusu ile birlikte gelir. HTTP/3 bu zincirin güçlü bir halkasıdır.

Sonuç

HTTP/3 (QUIC), özellikle mobil kullanıcıların yoğun olduğu sitelerde ve gecikmenin hissedildiği bölgelerde gerçek fayda sağlayan modern bir yükseltmedir. Cloudflare kullanıyorsanız birkaç tıkla devreye alabilir, Nginx tarafında ise UDP 443, doğru TLS yaklaşımı ve Alt-Svc duyurusunun mantığını kavrayarak kalıcı bir kurulum planlayabilirsiniz. İyi bir test ve ölçüm süreciyle HTTP/3’ün sitenize etkisini net şekilde görür, gerektiğinde HTTP/2 ile birlikte hibrit bir yapı kullanarak en geniş uyumluluğu korursunuz.

Android’de DNS over HTTPS (DoH) ile Reklam ve Takipçi Engelleme: AdGuard DNS Kurulumu ve Testi

DNS’i değiştirmek neden fark yaratır?

Akıllı telefonlarda reklam ve takipçi trafiğinin önemli bir kısmı, uygulamalar daha içerik yüklemeden önce DNS sorguları üzerinden başlar. DNS (Alan Adı Sistemi), bir alan adını (ör. example.com) IP adresine çeviren katmandır. Eğer reklam ağlarına ve bilinen takip alan adlarına giden DNS sorgularını daha baştan durdurursanız, hem tarayıcıda hem de uygulamalarda gereksiz istekler azalır; veri tüketimi ve pil kullanımı düşebilir.

Son yıllarda bu konuda öne çıkan yaklaşım DNS over HTTPS (DoH) oldu. DoH, DNS sorgularını HTTPS tüneli içinde taşıyarak operatör/yerel ağ seviyesinde “DNS dinleme ve yönlendirme” riskini azaltır. Android 9 ve sonrası sürümlerdeki Özel DNS özelliğiyle, ekstra uygulama kurmadan DoH/DoT tabanlı bir DNS sağlayıcısına bağlanmak mümkün.

Bu rehberde ne kuracağız?

Bu yazıda Android’in yerleşik “Özel DNS” ayarını kullanarak AdGuard DNS yapılandırmasını yapacağız. Hedef: reklamlara ve temel takipçilerin bir kısmına karşı sistem genelinde ek bir filtre katmanı eklemek. Bu yöntem, klasik reklam engelleyiciler gibi sayfa içi öğeleri “gizlemez”; reklam alan adını çözümleyemediği için içeriğin yüklenmesini engellemeye çalışır. Sonuç, çoğu senaryoda gözle görülür hızlanma ve daha temiz bir deneyimdir.

Gereksinimler

Android 9 (Pie) ve üzeri önerilir. Android 9+ cihazlarda “Özel DNS” ayarı standarttır. Ayrıca internet bağlantınızın olduğu bir anı seçin; DNS değişikliği sonrası bağlantı testi yapacağız.

Adım adım: Android’de AdGuard DNS (DoH/Özel DNS) kurulumu

1) Ayarlar uygulamasını açın ve arama kısmına Özel DNS yazın. Bazı cihazlarda yol şu şekilde olabilir: Ağ ve İnternet > Gelişmiş > Özel DNS.

2) Özel DNS sağlayıcı ana bilgisayar adı seçeneğini işaretleyin. Buraya DNS sağlayıcısının alan adını gireceğiz. AdGuard DNS için yaygın seçenek: dns.adguard.com.

3) Kaydedin ve bir iki saniye bekleyin. Android, arka planda bağlantıyı doğrular. “Bağlandı” benzeri bir durum görmüyorsanız bile kaydetme başarılıysa çoğu cihazda aktif hale gelir.

4) Uçak modunu aç/kapat yaparak ya da Wi‑Fi’ı kapatıp açarak DNS önbelleğini hızlıca tazeleyebilirsiniz. Bu şart değildir ama ilk kurulumda işe yarar.

Kurulumun çalıştığını nasıl test edersiniz?

1) Basit tarayıcı testi: Daha önce yoğun reklam gösteren bir haber sitesine girin. Sayfanın daha hızlı açıldığını veya bazı reklam alanlarının boş kaldığını gözlemleyebilirsiniz. Ancak unutmayın: DNS tabanlı engelleme “her şeyi” temizlemez; özellikle aynı alan adı üzerinden servis edilen (first-party) reklamlar yine gelebilir.

2) DNS sızıntısı ve DoH kontrolü: Tarayıcı üzerinden DoH testi yapan güvenilir sitelerle sorguların hangi DNS üzerinden gittiğini kontrol edebilirsiniz. Her test sitesi aynı sonucu vermeyebilir; bazıları tarayıcı DoH’unu, bazıları sistem DNS’ini ölçer. Buradaki amaç, “Özel DNS” sonrası sistem genelinde DNS sağlayıcısının değiştiğini teyit etmektir.

3) Uygulama içi reklamlar: Ücretsiz bir oyunu veya reklamlı bir uygulamayı açın. Reklamların tamamen kaybolması garanti değil; fakat çoğu reklam çağrısı DNS seviyesinde bloke edildiğinde reklam yüklenemeyebilir ya da gecikebilir.

Performans, gizlilik ve olası yan etkiler

Performans: Daha az istek, daha az izleyici betiği ve daha düşük veri tüketimi bekleyebilirsiniz. Öte yandan bazı DNS sağlayıcıları belirli bölgelerde daha yavaş olabilir. Gecikme hissederseniz alternatif bir DoH/DoT sağlayıcısıyla kıyaslamak mantıklıdır.

Gizlilik: DoH, yerel ağdaki gözlemcilerin DNS trafiğinizi okumasını zorlaştırır; ancak tüm güveni DNS sağlayıcısına verirsiniz. Bu nedenle, hangi şirketin politikasına güvendiğinizi seçmek önemlidir.

Yan etkiler: Bazı bankacılık uygulamaları, içerik filtreleme tespit ettiğinde sorun çıkarabilir. Ayrıca bazı sitelerde giriş, ödeme veya yorum gibi servisler üçüncü taraf alan adlarına dayanır; bu alan adları engellenirse sayfanın bir bölümü çalışmayabilir. Böyle bir durumda “Özel DNS”i geçici olarak kapatıp sorunun DNS kaynaklı olup olmadığını hızlıca anlarsınız.

İleri seviye ipuçları

1) Hız ve tutarlılık için karşılaştırma: Aynı ağda (Wi‑Fi) bir hafta AdGuard DNS, bir hafta farklı bir sağlayıcı deneyerek pil, veri ve hız farkını gözlemleyin. Android’de “Özel DNS” değişimi hızlıdır; geri dönüş kolay.

2) Tarayıcı tarafını güçlendirin: DNS engelleme, “temel katman”dır. Daha temiz bir deneyim için tarayıcıda içerik engelleme eklentileri veya izleyici koruması olan bir tarayıcıyla birleştirmek, özellikle sayfa içi yerleşimler ve çerez banner’larında daha iyi sonuç verir.

3) Sorun giderme: İnternet tamamen kesilirse önce alan adını doğru yazdığınızı kontrol edin (dns.adguard.com). Ardından mevcut VPN/kurumsal profil/özel güvenlik uygulamalarının “Özel DNS” ile çakışıp çakışmadığını inceleyin.

Sonuç

Android’in yerleşik “Özel DNS” özelliğiyle AdGuard DNS kullanmak, ekstra uygulama yüklemeden sistem genelinde reklam ve takip trafiğinin bir kısmını azaltmanın pratik bir yoludur. DoH sayesinde DNS sorgularınız şifreli taşınır; bu da özellikle halka açık Wi‑Fi ağlarında ek bir güvenlik ve gizlilik katmanı sağlayabilir. Tam bir reklam engelleyici olmasa da, hızlı kurulum ve düşük bakım ihtiyacıyla günlük kullanımda fark edilir bir iyileştirme sunar.

Local AI Dönemi: Ollama ile Bilgisayarında LLM Çalıştırma ve Open WebUI ile ChatGPT Benzeri Arayüz Kurma

Yerelde LLM çalıştırmak neden yeniden gündemde?

Bulut tabanlı yapay zekâ servisleri hızlı ve pratik; ancak veri gizliliği, abonelik maliyetleri ve hız dalgalanmaları gibi konular yüzünden “yerel AI” tekrar yükselişte. Özellikle metin üretimi, kod yardımı, özetleme ve belge sorgulama gibi işlerde, bilgisayarında çalışan bir LLM (Large Language Model) çoğu senaryoda yeterli olabiliyor. Bu yazıda, Ollama ile yerel model çalıştırmayı ve Open WebUI ile tarayıcıdan erişilen modern bir sohbet arayüzü kurmayı adım adım anlatıyorum.

Ön koşullar: Donanım ve işletim sistemi

Ollama; macOS, Linux ve Windows üzerinde çalışabiliyor. Temel gereksinim RAM tarafında. Küçük modeller için 8 GB RAM ile başlanabilir; daha rahat kullanım için 16 GB ve üzeri önerilir. GPU şart değil, ancak güçlü bir GPU (özellikle NVIDIA) hız avantajı sağlar. Depolama tarafında ise model dosyaları birkaç GB’tan başlayıp çift haneli GB seviyelerine çıkabildiği için en az 20–30 GB boş alan iyi olur.

1) Ollama kurulumu

Ollama’nın amacı, yerel LLM çalıştırmayı “tek komut” kadar kolay hale getirmek. Kurulum yöntemleri işletim sistemine göre değişir; en güncel adımlar için Ollama’nın resmi sitesine göz atmak mantıklı. Kurulum tamamlandıktan sonra komut satırından Ollama’nın çalıştığını doğrulayabilirsiniz. macOS/Linux’ta genellikle Terminal, Windows’ta PowerShell kullanılır.

Kontrol adımı: Ollama servisinin arka planda çalıştığından emin olun. Bazı sistemlerde kurulumla birlikte servis otomatik başlar. Başlamadıysa Ollama uygulamasını/servisini çalıştırmanız gerekebilir.

2) İlk modeli indirme ve çalıştırma

Ollama’da mantık basit: Bir modeli indirir ve “run” ile sohbet başlatırsınız. Örnek olarak genel amaçlı bir model seçebilirsiniz. Aşağıdaki komut, modelin cihazınıza indirilmesini ve ardından etkileşimli sohbetin açılmasını sağlar:

Komut: ollama run llama3.1

İlk çalıştırmada indirme süresi internet hızınıza bağlıdır. Sohbet ekranı geldiğinde Türkçe de yazabilirsiniz. Eğer yanıtlar yavaşsa, daha küçük bir model deneyin veya bağlam (context) boyutunu düşük tutun. Yerel kullanımda performansı belirleyen ana etkenler; model boyutu, quantization seviyesi ve donanım kapasitesidir.

3) Open WebUI ile tarayıcıdan modern arayüz kurma

Komut satırı pratik olsa da günlük kullanım için web arayüzü daha konforlu. Open WebUI, Ollama ile çalışan ve ChatGPT benzeri bir deneyim sunan popüler bir seçenek. Kurulumun en temiz yolu çoğu sistemde Docker kullanmaktır. Docker yüklüyse, Open WebUI konteyneri birkaç komutla ayağa kalkar ve tarayıcıdan erişirsiniz.

Örnek Docker komutu (genel yaklaşım): Open WebUI konteynerini çalıştırıp Ollama’ya bağlayacak şekilde yapılandırın. Bu adımda, Ollama servisinin yerelde hangi adreste çalıştığı önemlidir. Aynı makinede çalışıyorsanız genellikle “localhost” üzerinden erişilir; ancak Docker ağ ayarları işletim sistemine göre farklılık gösterebilir.

Kurulum sonrası tarayıcıda Open WebUI’ye girip model seçebilir, sohbet geçmişini yönetebilir, sistem prompt’u tanımlayabilir ve farklı konuşma profilleri oluşturabilirsiniz. Bu, yerel LLM’yi sadece “denemelik” olmaktan çıkarıp günlük bir üretkenlik aracına dönüştürüyor.

4) İleri seviye ayarlar: Model seçimi, quantization ve bağlam

Yerel LLM’lerde “tek doğru model” yok. İhtiyacınıza göre seçim yapmalısınız. Kod yardımı için kod odaklı modeller, Türkçe metin üretimi için Türkçe başarımı iyi olan modeller daha uygun olabilir. Ayrıca quantization (ör. 4-bit/8-bit) modelin RAM kullanımını düşürür; genellikle küçük kalite kaybı karşılığında ciddi hız ve kapasite avantajı sağlar. Uzun dokümanlarla çalışıyorsanız bağlam penceresi (context window) büyüdükçe RAM ihtiyacı artar. Bu yüzden “uzun bağlam” ile “hız” arasında denge kurmak gerekir.

5) Güvenlik ve gizlilik: Yerelde çalıştırmanın gerçek avantajı

Yerel çalıştırmanın en büyük artısı, verinin cihazınızdan çıkmamasıdır. Özellikle müşteri notları, proje dokümanları, sözleşmeler veya şirket içi kodlar söz konusuysa, buluta veri göndermemek kritik olabilir. Yine de unutmayın: Yerelde bile çalışsanız, kullandığınız arayüzlerin eklenti/telemetri ayarlarını kontrol etmek ve makinenizi güncel tutmak önemlidir. Ayrıca Open WebUI’yi yerel ağda erişime açacaksanız parola/kimlik doğrulama ayarlarını mutlaka etkinleştirin.

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

Yanıtlar çok yavaş: Daha küçük model deneyin, quantization kullanın, arka plandaki uygulamaları kapatın. GPU kullanımı mümkünse etkinleştirin.

RAM yetmiyor / sistem kasıyor: Model boyutunu düşürün, aynı anda tek model çalıştırın, bağlam penceresini küçültün. Swap kullanımı artıyorsa performans dramatik düşer.

Open WebUI Ollama’yı görmüyor: Docker ağ yapılandırmasını kontrol edin. Ollama servisinin çalıştığından ve doğru adrese/porta bağlandığınızdan emin olun.

Sonuç: Yerel AI’yı günlük akışa taşımak

Ollama + Open WebUI ikilisi, yerel LLM dünyasına giriş için en pratik yollardan biri. Bir yandan komut satırıyla esnek bir kullanım sunuyor, diğer yandan tarayıcı arayüzüyle ekip içi veya kişisel üretkenliği artırıyor. Doğru model seçimi ve donanımınıza uygun ayarlar ile; özetleme, e-posta taslağı, toplantı notu düzenleme, kod açıklama gibi işlerde bulut bağımlılığını azaltabilirsiniz. Yerel AI’nın asıl gücü, kontrolün sizde olması: hız, gizlilik ve özelleştirme bir araya geldiğinde ortaya gerçekten kullanışlı bir araç çıkıyor.

Docker Üzerinde Rootless Mod ile Güvenli Container Çalıştırma: Adım Adım Kurulum ve İnce Ayarlar

Rootless Docker Nedir ve Neden Önemli?

Docker, geliştiricilerin uygulamaları taşınabilir şekilde paketlemesini kolaylaştırdı; ancak klasik kurulumda Docker daemon (dockerd) genellikle root yetkileriyle çalışır. Bu da teorik olarak bir container kaçışı veya yanlış yapılandırma durumunda sistem genelinde daha büyük risk anlamına gelebilir. Rootless Docker, Docker’ı root yetkisi olmadan çalıştırarak saldırı yüzeyini azaltmayı hedefleyen güncel ve ileri seviye bir yaklaşımdır.

Rootless modda hem daemon hem de container süreçleri normal bir kullanıcı hesabıyla çalışır. Böylece “root” ayrıcalıklarına ihtiyaç duymadan container yönetimi yapılır. Bu yaklaşım özellikle paylaşımlı sunucularda, geliştirici makinelerinde veya güvenlik politikasının sıkı olduğu kurum ortamlarında ciddi avantaj sağlar.

Ön Koşullar: Sistem ve Kernel Gereksinimleri

Rootless Docker için güncel bir Linux dağıtımı önerilir (Ubuntu 22.04+, Debian 12, Fedora vb.). Temel olarak user namespace altyapısına ihtiyaç duyulur. Pek çok modern dağıtımda bu özellik varsayılan olarak hazır gelir; yine de aşağıdaki iki dosyanın doğru yapılandırılmış olması önemlidir: /etc/subuid ve /etc/subgid. Bu dosyalar, root yetkisi olmadan UID/GID eşlemesi yapabilmek için kullanılır.

Kısaca hedef şu: Kendi kullanıcı hesabınız (ör. ali) için belirli bir UID/GID aralığı atanır ve Docker bunu container içi “root”u, host tarafında ayrıcalıksız bir UID’ye map’leyerek gerçekleştirir.

Kurulum: Rootless Modu Etkinleştirme

Önce Docker’ın sisteminizde kurulu olması gerekir. Dağıtımınızın resmi Docker deposunu kullanmanız tavsiye edilir. Kurulum tamamlandıktan sonra rootless kurulumu için Docker’ın sağladığı script devreye girer. Çoğu sistemde şu komut yeterlidir:

dockerd-rootless-setuptool.sh install

Bu adım, kullanıcı düzeyinde bir systemd servisi oluşturur ve gerekli ortam değişkenleriyle birlikte rootless daemon’ı ayağa kaldırır. Ardından rootless daemon’ı başlatmak için genellikle şu komut kullanılır:

systemctl --user start docker

Otomatik başlaması için:

systemctl --user enable docker

Ortam Değişkenleri: Docker Client Doğru Daemon’a Bağlansın

Rootless modda Docker, varsayılan olarak kullanıcıya özel bir UNIX socket üzerinden hizmet verir. Bu nedenle terminal oturumunuzun doğru socket’e bağlanması gerekir. Çoğu kurulum aşağıdaki gibi bir öneri verir:

export DOCKER_HOST=unix:///run/user/1000/docker.sock

Buradaki 1000 değeri sizin kullanıcı UID’nizdir; id -u komutuyla öğrenebilirsiniz. Bu export satırını kalıcı yapmak için ~/.bashrc veya ~/.zshrc içine ekleyebilirsiniz.

Test: Rootless Çalıştığını Nasıl Anlarsınız?

Kurulum sonrası hızlı bir doğrulama için:

docker info

Çıktıda rootless ile ilgili ibareler ve “Security Options” altında user namespace benzeri detaylar görmeniz beklenir. Ayrıca basit bir container çalıştırarak da test edebilirsiniz:

docker run --rm hello-world

Bu komutun başarılı çalışması, client’ın rootless daemon’a bağlanabildiğini ve temel container akışının sağlıklı olduğunu gösterir.

İnce Ayar 1: Port Yönlendirme ve 1024 Altı Portlar

Rootless Docker’ın en çok kafa karıştıran noktası port yayınlama tarafıdır. Klasik Docker’da 80/443 gibi ayrıcalıklı portlara kolayca bind edilebilirken, rootless modda bu işlem sınırlıdır. Çünkü 1024 altı portlara bind etmek genelde root yetkisi ister.

Çözüm olarak uygulamanızı 8080/8443 gibi yüksek portlarda çalıştırıp ters proxy (ör. Nginx) ile yönlendirebilir veya sistemde setcap gibi yöntemlerle belirli ikili dosyalara sınırlı yetki verebilirsiniz. Güvenlik bakış açısıyla en temiz yaklaşım, servisleri yüksek portta çalıştırıp yönlendirme katmanını ayrıca yönetmektir.

İnce Ayar 2: Dosya İzinleri ve Bind Mount Davranışı

Rootless modun doğal sonucu olarak, host dosya izinleri daha belirleyici hale gelir. Bind mount yaptığınızda container içindeki kullanıcı ile host tarafındaki UID eşleşmesi farklı görünebilir. Özellikle CI ortamlarında veya “volume” olarak paylaşılan dizinlerde yazma izni sorunları çıkabilir.

Pratikte en iyi yöntem, proje dizininizin sahipliğini ve izinlerini net tutmak, gerekiyorsa container içinde çalışacak kullanıcıyı açıkça belirlemek ve “her şeyi 777 yapmak” gibi kötü alışkanlıklardan kaçınmaktır. Rootless, güvenliği artırırken disiplinli izin yönetimini de zorunlu kılar.

Rootless Docker Ne Zaman Mantıklı, Ne Zaman Değil?

Kişisel geliştirme ortamı, paylaşımlı sistemler ve güvenlik öncelikli senaryolarda rootless mod çok mantıklıdır. Buna karşılık, düşük portlara yoğun ihtiyaç, bazı sürücü/overlay kısıtları veya özel ağ/iptables beklentileri olan ortamlarda klasik kurulum daha az sürtünmeyle çalışabilir. Yine de güncel Docker sürümleriyle rootless olgunlaştı; güvenlik açısından “varsayılan tercih” olmaya giderek daha yakın.

Özetle: Eğer makinenizde container’ları “root gibi” çalıştırmak zorunda değilseniz, rootless Docker ile daha güvenli bir temel elde edersiniz. Kurulum birkaç adım sürer; kazandırdığı güvenlik kazanımı ise uzun vadede oldukça değerlidir.