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

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

Windows 11 üzerinde Docker kullanmanın en popüler yolu Docker Desktop kurmak. Ancak bazı kullanıcılar lisans koşulları, sistem kaynak tüketimi veya arka planda çalışan servisler nedeniyle daha hafif bir alternatif arıyor. İyi haber şu: WSL2 (Windows Subsystem for Linux) ile Docker Engine’i doğrudan Linux dağıtımı içinde kurup, Windows’ta da komut satırından rahatça kullanabilirsiniz. Bu yazıda, güncel bir yöntemle Docker Desktop olmadan kurulum, entegrasyon ve performans ayarlarını adım adım anlatıyorum.

Ön koşullar

Başlamadan önce şunlara ihtiyacınız var: Windows 11 (güncel), yönetici yetkisi, WSL2 ve bir Linux dağıtımı (Ubuntu 22.04/24.04 önerilir). Terminal kullanmayı bilmek kurulum süresini kısaltır. Bu yöntem, Docker konteynerlerini Linux çekirdeği üzerinde çalıştırdığı için hem uyumluluk hem de hız açısından genelde iyi sonuç verir.

1) WSL2 ve Ubuntu kurulumu (kısa yol)

Windows Terminal’i yönetici olarak açıp aşağıdaki komutu çalıştırın. Bu komut WSL’i etkinleştirir ve varsayılan olarak Ubuntu’yu kurar:

Komut: wsl --install

Kurulum bittiğinde bilgisayar yeniden başlatılabilir. Ardından Ubuntu ilk açılışta kullanıcı adı ve parola oluşturmanızı ister. WSL sürümünü kontrol etmek için:

wsl -l -v

Dağıtımınızın VERSION sütununda 2 yazmalıdır. Değilse şu komutla yükseltin:

wsl --set-version Ubuntu 2

2) Ubuntu içinde Docker Engine kurulumu

Ubuntu terminalinde önce sistem paketlerini güncelleyin:

sudo apt update && sudo apt upgrade -y

Ardından gerekli paketleri yükleyin:

sudo apt install -y ca-certificates curl gnupg

Docker’ın resmi deposunu eklemek için anahtar ve repo tanımını yapın (Ubuntu sürümüne uygun komutlar güncel yöntemdir):

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

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

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

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

Şimdi Docker paketlerini kurun:

sudo apt update

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

3) WSL2’de Docker servisini başlatma (systemd ayarı)

Windows 11’in güncel sürümlerinde WSL içinde systemd desteği bulunuyor. Docker’ın her açılışta sorunsuz başlaması için bu ayarı aktif etmek iyi olur. Ubuntu’da şu dosyayı düzenleyin:

sudo nano /etc/wsl.conf

İçine şunları ekleyin:

[boot]
systemd=true

Ardından Windows tarafında WSL’i kapatıp tekrar açın:

wsl --shutdown

Ubuntu’yu tekrar açtıktan sonra Docker servis durumunu kontrol edin:

sudo systemctl status docker

4) “sudo”suz Docker kullanımı

Her komutta sudo yazmamak için kullanıcıyı docker grubuna ekleyin:

sudo usermod -aG docker $USER

Oturumu kapatıp açın ya da WSL’i yeniden başlatın. Sonrasında test:

docker run --rm hello-world

5) Windows Terminal’den pratik kullanım

Bu kurulumda Docker komutlarını Ubuntu içinde çalıştırırsınız. Windows Terminal’de Ubuntu sekmesi açıp docker ps gibi komutları kullanmak yeterli. Ayrıca proje klasörünüz Windows dosya sistemindeyse (ör. C:\projeler), WSL’den /mnt/c/projeler yoluyla erişebilirsiniz. Ancak performans için kritik bir öneri var: sık I/O yapan projelerde (Node.js, PHP, büyük bağımlılık klasörleri) kodu mümkünse WSL dosya sisteminde tutmak (ör. ~/projects) daha hızlı olur.

6) Performans ve kaynak ayarları (.wslconfig)

WSL2, varsayılan olarak RAM’i dinamik yönetir; bazı senaryolarda fazla RAM tüketebilir. Windows kullanıcı klasörünüzde (ör. C:\Users\KullaniciAdiniz) .wslconfig dosyası oluşturup kaynak sınırı koyabilirsiniz. Örnek:

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

Değişiklikten sonra wsl --shutdown ile WSL’i yeniden başlatın. Bu ayarlar özellikle aynı anda IDE, tarayıcı ve birkaç konteyner çalıştırırken sistemi daha öngörülebilir hale getirir.

7) Artılar, eksiler ve ne zaman tercih edilmeli?

Artılar: Daha hafif kurulum, daha az arka plan servisi, Docker Desktop bağımlılığı olmadan çalışma, Linux tabanlı daha “doğal” Docker deneyimi.

Eksiler: Bazı GUI özellikleri (entegre panel, otomatik güncelleyici) yoktur; port yönlendirme ve dosya sistemine erişimde dikkat gerekir. Yine de CLI odaklı geliştiriciler için bu yöntem günlük kullanımda gayet konforlu ve verimlidir.

Sonuç olarak, Windows 11 + WSL2 ikilisiyle Docker Desktop kurmadan da güncel ve hızlı bir konteyner çalışma ortamı kurabilirsiniz. Kurulum bir kez tamamlandıktan sonra günlük iş akışı büyük ölçüde “Linux’ta Docker kullanmak” kadar akıcı hale gelir.

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

Docker Desktop olmadan neden Docker?

Windows 11 kullanırken Docker ile çalışmanın en popüler yolu Docker Desktop kurmak. Ancak kurumsal lisans kısıtları, kaynak tüketimi veya “arka planda sürekli servis” yaklaşımını sevmeme gibi sebeplerle daha hafif ve kontrol edilebilir bir seçenek arayanların sayısı artıyor. Bu yazıda, WSL2 üzerinde Docker Engine kurarak Docker Desktop olmadan konteyner çalıştırmayı adım adım anlatacağım. Ayrıca performans, ağ erişimi ve sık görülen hatalar için pratik ince ayarları da ekleyeceğim.

Ön koşullar

Bu rehber Windows 11 ve WSL2 mantığını temel alır. İhtiyacınız olanlar: Windows 11, yönetici yetkisi, WSL2 etkinleştirilmiş bir Linux dağıtımı (Ubuntu önerilir) ve PowerShell/Windows Terminal. WSL sürümünüzü kontrol etmek için PowerShell’de wsl -l -v komutunu kullanabilirsiniz. Dağıtımınızın “VERSION” değeri 2 değilse, wsl --set-version Ubuntu 2 ile dönüştürebilirsiniz.

1) WSL2 üzerinde Docker Engine kurulumu

Ubuntu’yu açın ve önce sistem paketlerini güncelleyin:

sudo apt update && sudo apt upgrade -y

Docker’ın resmi deposunu eklemek için gerekli paketleri kurun:

sudo apt install -y ca-certificates curl gnupg

Docker GPG anahtarını ekleyin ve depo kaydını oluşturun:

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

Ardından Docker Engine ve temel bileşenleri kurun:

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

2) Servis yönetimi: systemd ve Docker’ın başlatılması

Güncel WSL sürümlerinde systemd desteği mevcut. Etkinleştirirseniz Docker’ı normal Linux gibi servis olarak yönetebilirsiniz. Ubuntu içinde şu dosyayı düzenleyin:

sudo nano /etc/wsl.conf

İçine şunu ekleyin:

[boot]
systemd=true

Sonra Windows tarafında WSL’i yeniden başlatın (PowerShell):

wsl --shutdown

Ubuntu’yu tekrar açınca Docker servisini başlatın:

sudo systemctl enable --now docker

Kontrol:

docker version
docker info

3) sudo yazmadan Docker kullanmak (güvenli kullanım notuyla)

Sürekli sudo yazmak istemiyorsanız kullanıcıyı docker grubuna ekleyebilirsiniz:

sudo usermod -aG docker $USER

Oturumu kapatıp açın veya WSL’i yeniden başlatın. Not: Docker grubu pratik ama güçlü yetkilere sahiptir; paylaşımlı makinelerde dikkatli olun.

4) Hızlı test: nginx konteyneri çalıştırma

Kurulumun doğru olduğunu görmek için küçük bir test iyi olur:

docker run --rm -d --name web -p 8080:80 nginx:alpine

Ardından tarayıcıda http://localhost:8080 adresini açın. WSL2 ağ katmanı sayesinde port yönlendirme genellikle sorunsuz çalışır. İşiniz bitince durdurun:

docker stop web

5) İnce ayar: disk performansı ve proje konumu

WSL2 + Docker kullanımında en kritik konu dosya sistemi performansıdır. Projenizi Windows dosya sisteminde (ör. /mnt/c/...) tutup konteyner içinde bind mount yaparsanız, yoğun I/O işlemlerinde yavaşlık görebilirsiniz. Daha iyi performans için kaynak kodunu WSL Linux dosya sisteminde (ör. /home/kullanici/proje) konumlandırın. Editör olarak VS Code kullanıyorsanız Remote - WSL eklentisiyle bu akış oldukça rahattır.

6) Sık karşılaşılan sorunlar ve çözümler

“Cannot connect to the Docker daemon” hatası alıyorsanız çoğunlukla servis çalışmıyordur: sudo systemctl status docker ile kontrol edin, gerekirse sudo systemctl restart docker deneyin. Systemd aktif değilse, önce /etc/wsl.conf ayarını doğrulayın ve wsl --shutdown ile tamamen kapatıp açın.

Port çakışması yaşarsanız (ör. 8080 doluysa) farklı bir port seçin: -p 8081:80. Ayrıca bazı güvenlik yazılımları veya şirket VPN’leri localhost portlarını etkileyebilir; sorun yaşarsanız geçici olarak kapatıp test etmek mantıklı olur.

Kaynak tüketimi için WSL’e limit koyabilirsiniz. Windows kullanıcı dizininizde .wslconfig dosyası oluşturup bellek/CPU sınırı vermek, özellikle uzun süre açık kalan geliştirme makinelerinde sistemi rahatlatır. Örneğin 4 GB RAM ve 4 çekirdek sınırı çoğu orta ölçekli iş için yeterlidir.

Sonuç

Docker Desktop olmadan Docker kullanmak, özellikle “hafif ve kontrol edilebilir” bir geliştirme ortamı isteyenler için güçlü bir alternatif. WSL2 üzerinde Docker Engine kurduğunuzda hem Linux ekosisteminin doğallığını korur hem de Windows tarafındaki iş akışınızı bozmadan konteynerlerle çalışabilirsiniz. Doğru proje konumu seçimi ve systemd ile servis yönetimi gibi küçük dokunuşlar, deneyimi ciddi biçimde iyileştirir.

Claude 3, GPT-4o ve Llama 3 ile RAG (Retrieval-Augmented Generation) Kurulumu: Üretim Odaklı Adım Adım Rehber

RAG Nedir ve Neden 2026’da Hâlâ En İyi Yaklaşımlardan Biri?

Büyük dil modelleri (LLM) tek başına güçlü olsa da, her zaman güncel veriye erişemez ve kurumsal dokümanlarınız gibi özel içerikleri “doğrudan” bilemez. RAG (Retrieval-Augmented Generation), modeli harici bir bilgi kaynağıyla besleyerek bu açığı kapatır: Önce doğru doküman parçaları (chunk) aranır, sonra bu parçalar modele bağlam olarak verilerek yanıt ürettirilir. Böylece halüsinasyon riski düşer, cevaplar kaynaklı ve izlenebilir hâle gelir, ayrıca model güncellemeden veri güncellenebilir.

Bu yazıda, ileri seviye ama uygulanabilir bir RAG mimarisini ele alacağız: parça stratejisi, embedding seçimi, vektör veritabanı, filtreleme, yeniden sıralama (reranking) ve üretim tarafında prompt tasarımı. Hedefimiz “demo” değil, üretim ortamına yakın bir kurulum mantığı vermek.

Mimari Genel Bakış: 5 Katmanlı RAG

Sağlam bir RAG sistemi genellikle 5 bileşenden oluşur: (1) Veri hazırlama (temizleme, bölümleme), (2) Embedding (vektörleştirme), (3) Vektör indeks (arama), (4) Yeniden sıralama (en alakalı parçaları seçme), (5) Üretim (LLM ile yanıt oluşturma). Bu yapı, “LLM’ye her şeyi verelim” yaklaşımından daha az maliyetli ve daha tutarlıdır.

1) Veri Hazırlama: Chunk Stratejisi ve Metadata

RAG kalitesi, çoğu zaman modelden önce chunk stratejinizle belirlenir. PDF’lerden, wiki sayfalarından veya ticket kayıtlarından gelen içerik düzensiz olabilir. Pratikte iyi çalışan yaklaşım: 500–900 token arası chunk boyutu ve 70–150 token overlap kullanmaktır. Çok küçük chunk, bağlamı parçalar; çok büyük chunk ise arama isabetini düşürür.

Her chunk’a mutlaka metadata ekleyin: kaynak doküman adı, URL (dahili olabilir), bölüm başlığı, tarih, erişim yetkisi, ürün/servis etiketi gibi alanlar. Üretimde asıl farkı yaratan kısım burasıdır; çünkü sonradan “sadece X ürününe ait, son 6 ayın dokümanlarını tara” gibi filtreleri metadata ile yaparsınız.

2) Embedding Seçimi: Doğru Vektör Doğru Sonuç

Embedding modeli, metni sayısal vektöre dönüştürür ve benzerlik aramasının temelini oluşturur. Türkçe içerikte embedding kalitesi kritiktir. Seçerken şu kriterlere bakın: çok dilli başarı, uzun metin performansı, maliyet ve gecikme. Kurumsal senaryoda aynı anda hem İngilizce hem Türkçe doküman varsa, çok dilli embedding genellikle daha güvenli tercihtir.

Ek bir ipucu: Embedding üretirken metni “ham” basmak yerine, başlık + bölüm + içerik şeklinde birleştirmek arama isabetini artırır. Örneğin: “Başlık: … | Bölüm: … | Metin: …” gibi küçük bir şablon, özellikle benzer kavramların çok geçtiği dokümanlarda yardımcı olur.

3) Vektör Veritabanı ve İndeks Ayarları

Vektör veritabanı seçiminde popüler seçenekler arasında FAISS (self-host), Milvus, Qdrant, Weaviate ve bulut tabanlı servisler bulunur. Üretimde dikkat edilmesi gerekenler: HNSW gibi indeks türleri, filtreli arama performansı, replikasyon/backup ve erişim kontrolüdür.

HNSW tabanlı aramada temel ayar mantığı şöyledir: daha yüksek doğruluk için arama parametreleri yükselir ama gecikme artar. Bu yüzden arama katmanını iki fazlı düşünmek iyi çalışır: önce hızlı bir aday havuzu (ör. top-50) çıkarın, sonra daha pahalı bir reranking ile top-5/top-8’e düşürün.

4) Reranking: “En Yakın” Parça Her Zaman “En Alakalı” Değildir

Embedding benzerliği, semantik yakınlığı yakalar ama her zaman kullanıcı sorusuna en alakalı parçayı seçmeyebilir. Özellikle teknik dokümanlarda aynı terimler farklı bağlamlarda geçebilir. Burada reranker devreye girer: Soru ile aday chunk’ları daha “dikkatli” karşılaştırıp yeniden sıralar.

Üretimde yaygın ve etkili bir desen: top-50 vektör araması → top-10 rerank → top-4 bağlam. Reranking maliyetli olabilir; bu yüzden sadece gerekli olduğunda açmak için basit bir eşik kullanabilirsiniz (örneğin, en iyi sonucun benzerlik skoru düşükse rerank uygula).

5) Üretim (LLM) Katmanı: Prompt Tasarımı ve Kaynak Gösterme

RAG’in “G” kısmı, yani generation tarafı, çoğu zaman yanlış anlaşılır: LLM’den mucize beklemek yerine ona disiplin kazandırmak gerekir. İyi çalışan prompt ilkeleri: (1) Modeli sadece verilen bağlamla cevap vermeye zorlamak, (2) Yetersiz bağlam varsa “bilmiyorum” demesini istemek, (3) Cevabı madde madde ve adım adım ürettirmek, (4) Mümkünse kaynak chunk referansı döndürmek.

Kısa bir örnek yönerge mantığı: “Aşağıdaki bağlam parçalarını kullan. Bağlam dışında tahmin yürütme. Yanıtın sonunda ‘Kullanılan Kaynaklar’ altında parça kimliklerini yaz.” Bu yaklaşım, özellikle denetim ve uyumluluk isteyen ekiplerde RAG’i güvenilir kılar.

Kalite Ölçümü: RAG’i “Hissetmek” Yerine Test Etmek

RAG sistemleri, “birkaç soru sorup iyi gibi” diyerek üretime alınmamalı. Basit ama etkili bir yöntem: 30–100 adet gerçek kullanıcı sorusunu toplayın, her soru için “beklenen kaynak doküman” düşünün ve şu metrikleri izleyin: retrieval recall (doğru kaynak top-k içinde mi), answer faithfulness (cevap bağlamla tutarlı mı), latency (uçtan uca gecikme) ve maliyet. Bu ölçümlerle chunk boyutu, top-k, reranking aç/kapa ve prompt ayarlarını kontrollü biçimde optimize edebilirsiniz.

Üretim İçin Pratik İpuçları (Sık Yapılan Hatalar)

1) Yetkilendirme yok sayılmasın: Kullanıcının görmemesi gereken dokümanı retrieval katmanında filtrelemezseniz, LLM yanlışlıkla sızdırabilir. Metadata’ya erişim seviyeleri ekleyin ve arama sorgusuna mutlaka uygulayın.

2) “Tek indeks her şeye yeter” yanılgısı: Destek kayıtları, teknik kılavuzlar ve release notları aynı dilde olsa bile farklı karakterdedir. Bazen iki ayrı koleksiyon/indeks, tek dev koleksiyondan daha iyi sonuç verir.

3) Güncelleme akışı planlayın: Dokümanlar değiştikçe embedding’lerin güncellenmesi gerekir. En azından günlük incremental indeksleme ve silinen içerik için “tombstone” mantığı kurun.

4) Caching kullanın: Sık sorulan sorular ve popüler retrieval sonuçları için cache, maliyeti ciddi düşürür. Ayrıca aynı sorunun farklı yazımları için basit bir normalizasyon (küçük harf, noktalama temizliği) bile kazanç sağlar.

Sonuç: RAG’i Bir “Özellik” Değil, Bir Sistem Olarak Kurun

RAG, doğru kurgulandığında LLM’leri kurumsal bilgiyle güvenli şekilde birleştirmenin en pratik yoludur. Başarı; modelden çok, chunk stratejisi, metadata disiplini, filtreleme, reranking ve ölçüm altyapısının birlikte çalışmasına bağlıdır. Bu yazıdaki adımları temel alıp kendi verinize göre ayarladığınızda, hem daha doğru yanıtlar alır hem de maliyeti ve gecikmeyi kontrol edebilirsiniz.

Docker ile Yerel LLM Çalıştırma: Ollama Kurulumu, Model Yönetimi ve API ile Entegrasyon

Yerelde yapay zekâ neden bu kadar popüler oldu?

Bulut tabanlı yapay zekâ servisleri hızlı ve pratik; ancak maliyet, gecikme, veri gizliliği ve entegrasyon esnekliği gibi başlıklarda her zaman ideal değiller. Özellikle hassas verilerle çalışan ekipler için yerelde (lokalde) çalışan büyük dil modelleri (LLM) ciddi bir avantaj sağlıyor. Son dönemde bu ihtiyacı en pratik şekilde karşılayan araçlardan biri de Ollama. Bu yazıda, Ollama’yı Docker ile kurup yerelde model çalıştırmayı, model yönetimini ve basit bir API kullanımını adım adım ele alıyorum.

Ollama nedir, ne işimize yarar?

Ollama, LLM’leri bilgisayarınızda çalıştırmayı kolaylaştıran bir çalışma zamanı ve model yönetim katmanı gibi düşünebilirsiniz. “Modeli indir, çalıştır, API üzerinden çağır” akışını sadeleştirir. Birçok model ailesini desteklemesi ve komut satırı üzerinden hızlı bir deneyim sunması sayesinde geliştiriciler arasında hızla yayıldı. Ayrıca yerel bir HTTP API sunduğu için, kendi uygulamanızdan bu modeli sanki bir servis gibi tüketebilirsiniz.

Kurulum ön koşulları

Bu rehberde Docker tabanlı bir kurulum anlatacağım. İhtiyacınız olanlar: Docker (ve mümkünse Docker Compose), yeterli disk alanı (model boyutuna göre 5–20 GB+), ve tercihen güçlü bir CPU/GPU. GPU hızlandırma her sistemde aynı kolaylıkta olmasa da, CPU ile de temel denemeler yapılabilir. Komutlar Linux/macOS için uygundur; Windows’ta WSL2 ile benzer şekilde ilerleyebilirsiniz.

Docker ile Ollama’yı çalıştırma

Önce kalıcı bir veri dizini kullanmak iyi bir fikirdir; çünkü modeller indirildiğinde container silinse bile tekrar indirmek zorunda kalmazsınız. Aşağıdaki komut, Ollama’yı arka planda ayağa kaldırır ve varsayılan API portunu (11434) dışarı açar:

Komut:

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

Bu noktada servis çalışır durumdadır. Kontrol etmek için:

docker logs -f ollama

İlk modelinizi indirme ve çalıştırma

Ollama, model yönetimini komut satırından çok kolaylaştırır. Container içine girip bir model çekebilir veya doğrudan “exec” ile komut çalıştırabilirsiniz. Örneğin küçük ve hızlı bir modelle başlamak mantıklıdır. Aşağıdaki örnekte bir modeli indirip interaktif şekilde çalıştırıyoruz:

docker exec -it ollama ollama run llama3

İlk çalıştırmada model indirileceği için biraz bekleyebilirsiniz. İndirme bittiğinde sohbet ekranı açılır; Türkçe istem (prompt) verip yanıt alabilirsiniz. Daha iyi yanıtlar için isteminizi net tutun: amaç, bağlam, çıktı formatı gibi detayları belirtin.

Model yönetimi: listeleme, silme, güncelleme

Disk alanı yerel LLM dünyasında hızlı tükenir. Bu yüzden indirilen modelleri düzenli yönetmek önemli. Yüklü modelleri listelemek için:

docker exec -it ollama ollama list

Kullanmadığınız bir modeli silmek için:

docker exec -it ollama ollama rm llama3

Modeli tekrar çekmek/güncellemek için aynı “run” komutu ya da ilgili pull akışı kullanılabilir. Ayrıca aynı modelin farklı varyantları (ör. boyut, quantization) performans ve kaliteyi ciddi etkiler. Daha küçük quantization daha hızlıdır ama doğruluk ve akıcılık düşebilir. Bu dengeyi kendi kullanım senaryonuza göre test ederek bulmanız gerekir.

HTTP API ile entegrasyon: uygulamaya bağlamak

Ollama’nın en büyük artılarından biri, yerelde bir servis gibi davranmasıdır. Böylece herhangi bir dille HTTP isteği atarak yanıt alabilirsiniz. Basit bir “prompt gönder, yanıt al” testi için terminalde şu isteği deneyin:

curl http://localhost:11434/api/generate -d '{ "model": "llama3", "prompt": "Bana 5 maddede SEO uyumlu blog yazısı ipucu ver.", "stream": false }'

Yanıtta genellikle modelin ürettiği metin ve bazı ek alanlar döner. Uygulama tarafında JSON parse edip “response” benzeri alanı kullanıcıya gösterebilirsiniz. stream seçeneğini açtığınızda token token akış alarak daha hızlı bir kullanıcı deneyimi sağlayabilirsiniz.

Performans ipuçları ve güvenlik notları

Yerel LLM çalıştırırken performans iki şeye bakar: donanım ve model seçimi. Eğer yalnızca metin özetleme, e-posta taslağı, basit kod yardımı gibi işler yapacaksanız daha küçük modeller yeterli olabilir. Daha karmaşık muhakeme ve uzun bağlam ihtiyaçlarında ise daha büyük modeller gerekebilir; bu da RAM/VRAM ve disk tüketimini artırır. Ayrıca Ollama’yı yalnızca kendi makinenizde kullanacaksanız portu dış dünyaya açmamak iyi bir güvenlik alışkanlığıdır. Sunucuda kullanıyorsanız, ters proxy ve erişim kontrolü (ör. yalnızca VPN içinden erişim) planlayın.

Sonuç: Yerelde LLM denemek artık zor değil

Docker ile Ollama kurulumunu yaptıktan sonra model indirmek, çalıştırmak ve API üzerinden uygulamaya bağlamak oldukça akıcı bir süreç. Bu yaklaşım; kişisel projeler, kurum içi araçlar, gizlilik odaklı metin işleme senaryoları ve düşük gecikme isteyen otomasyonlar için iyi bir seçenek. Bir sonraki adım olarak farklı model varyantlarını test edebilir, istem mühendisliğiyle çıktıları standardize edebilir ve kendi uygulamanızda bir “yerel yapay zekâ asistanı” deneyimi oluşturabilirsiniz.

WebRTC ile Tarayıcıdan Tarayıcıya Dosya Aktarımı: Sinyal Sunucusu ve Güvenli P2P Akışı Kurulumu

WebRTC ile P2P dosya aktarımı neden hâlâ önemli?

Bulut depolama servisleri pratik ama her zaman ideal değil: büyük dosyalarda yükleme süresi, kota sınırları, bağlantı hızına bağlı gecikmeler ve kimi senaryolarda gizlilik endişeleri devreye giriyor. WebRTC (Web Real-Time Communication) ise tarayıcıların birbirleriyle doğrudan haberleşmesini sağlayarak, arada dosyayı tutan bir “depo” olmadan aktarımı mümkün kılıyor. Bu yazıda, ileri seviye ama uygulanabilir bir yaklaşımla, tarayıcıdan tarayıcıya güvenli P2P dosya transferi için gerekli bileşenleri ve kritik ayarları adım adım ele alacağım.

Mimarinin özeti: Sinyal mi, medya mı?

WebRTC, bağlantıyı “kendi kendine” başlatmaz. İki tarayıcının birbirini bulması ve bağlantı parametrelerini paylaşması için bir sinyal (signaling) kanalına ihtiyacı vardır. Bu kanal genellikle WebSocket ile kurulur. Sinyal sunucusu sadece şu verileri iletir: SDP teklif/yanıtları (offer/answer) ve ICE adayları. Dosyanın kendisi ise ideal durumda RTCDataChannel üzerinden P2P akar.

Özet akış: (1) İstemciler sinyal sunucusuna bağlanır. (2) Bir oda/kimlik üzerinden eşleşir. (3) SDP/ICE alışverişi yapılır. (4) NAT arkasından geçiş için STUN/TURN devreye girer. (5) DataChannel açılır ve dosya parçalı şekilde gönderilir.

Gereksinimler: STUN/TURN, HTTPS ve tarayıcı kısıtları

Modern tarayıcılarda WebRTC çoğu zaman “secure context” ister. Üretimde HTTPS kullanmanız önemlidir (localhost istisna). NAT/kurumsal ağ koşullarında yalnız STUN yetmeyebilir; bu nedenle bir TURN sunucusu kritik bir güvence katmanıdır. TURN, doğrudan bağlantı kurulamadığında trafiği relay eder; bu da maliyetli ama erişilebilirliği artıran bir çözümdür.

Pratik öneri: Geliştirme aşamasında STUN ile başlayın; sahaya çıkarken TURN ekleyin. En çok kullanılan açık kaynak TURN çözümü coturn’dür. Ayrıca aktarımın güvenliği WebRTC’de varsayılan olarak DTLS ile sağlanır; yani DataChannel üzerinde giden veri şifrelenir.

1) Basit bir sinyal sunucusu (Node.js + WebSocket)

Sinyal sunucusunun görevi “mesaj taşımak”tır, dosya aktarmak değil. Basit bir odalı yapı kurgulayabilirsiniz: istemci bir odaya katılır, diğer istemci gelince birbirlerinin mesajlarını iletir. Aşağıdaki yaklaşım üretim için değil, mantığı netleştirmek içindir: tek sunucu, oda eşleşmesi, mesaj yönlendirme.

İpucu: Mesajları tip alanıyla sınıflandırın: offer, answer, ice, join. Böylece istemci tarafı daha okunaklı olur ve hataları ayıklamak kolaylaşır.

2) İstemci tarafı: RTCPeerConnection ve RTCDataChannel

Tarayıcı tarafında iki temel nesne kullanılır: RTCPeerConnection ve RTCDataChannel. PeerConnection, ICE/STUN/TURN ile bağlantıyı kurar; DataChannel ise dosya parçalarını taşır. Buradaki kritik konu, dosyayı tek seferde göndermeye kalkmamak. Büyük bir Blob’u tek mesajla yollamak bellek patlamasına, tarayıcı takılmalarına veya kanal buffer’ının dolmasına yol açabilir.

Sağlıklı yöntem: Dosyayı chunk’lara bölün (örneğin 16 KB–256 KB arası), sırayla gönderin ve backpressure yönetin. WebRTC tarafında bunun için dataChannel.bufferedAmount değerini izleyip belirli eşiğin üstünde beklemek iyi bir pratiktir.

3) Chunk stratejisi, akış kontrolü ve bütünlük

Dosya transferinde üç konu genelde gözden kaçar: akış kontrolü, bütünlük ve yeniden birleştirme. Akış kontrolü için bufferedAmount eşiği belirleyin (ör. 8–16 MB). Bütünlük için en basit yaklaşım: dosya boyutu, parça sayısı, her parçanın indeks bilgisi ve isteğe bağlı hash (ör. SHA-256) gönderin. Yeniden birleştirmede alıcı tarafta parçaları sıraya koyup ArrayBuffer/Blob olarak birleştirin.

Ayrıca DataChannel için iki mod var: ordered (varsayılan) ve unordered. Dosya aktarımında genelde ordered işinizi kolaylaştırır. Paket kaybına dayanıklılık isterseniz, parçaları indeksleyip unordered kullanabilir, eksikleri yeniden isteyebilirsiniz; bu ileri seviye bir iyileştirmedir.

4) ICE yapılandırması: STUN ve TURN örneği

PeerConnection oluştururken ICE sunucularını tanımlarsınız. STUN, dış IP/port keşfine yardım eder; TURN ise relay görevi görür. Kurumsal ağlarda UDP engellenmiş olabilir; TURN’u TCP/TLS ile de sunmak gerekir. Üretimde en çok takılınan yer burasıdır: “Aynı Wi‑Fi’da çalışıyor, dış ağda çalışmıyor.” Sebebi genellikle TURN eksikliği veya yanlış kimlik bilgisidir.

Güvenlik notu: TURN kullanıcı adı/parola bilgilerini statik tutmak yerine zaman kısıtlı (time-limited) kimlik doğrulama kullanmak daha güvenlidir. coturn bu konuda esnektir.

5) Test, hata ayıklama ve performans ipuçları

Test aşamasında önce iki sekme arasında (aynı makine) deneyin; sonra aynı LAN, sonra farklı ağlar. Chrome’da chrome://webrtc-internals sayfası ICE adaylarını, bağlantı durumlarını ve kanal istatistiklerini incelemek için çok değerlidir. Bağlantı kurulamıyorsa genellikle sorun sinyal değil, ICE/TURN tarafındadır.

Performans için öneriler: Chunk boyutunu cihazlara göre ayarlayın, gereksiz kopyalamaları azaltın, alıcı tarafta parçaları birleştirirken bellek kullanımını izleyin. Çok büyük dosyalarda (ör. birkaç GB) tarayıcı sınırlarına yaklaşabilirsiniz; bu durumda indirme/streaming yaklaşımı ve dosya sistemi erişimi (File System Access API) gibi ek teknikler gündeme gelir.

Sonuç: Bulutsuz paylaşım için sağlam bir temel

WebRTC ile tarayıcıdan tarayıcıya dosya aktarımı, doğru kurgulandığında hem hızlı hem de şifreli bir deneyim sunar. Bu işin kalbi dosyayı taşımaktan çok, bağlantıyı güvenilir biçimde kurmaktır: sinyal sunucusu basit kalabilir, fakat ICE/STUN/TURN ayarları ve chunk tabanlı aktarım stratejisi projenin başarısını belirler. Buradaki yaklaşımı bir temel olarak alıp; oda yönetimi, kimlik doğrulama, yeniden deneme mekanizmaları ve transfer ilerleme göstergesi gibi parçalarla üretim seviyesine rahatça taşıyabilirsiniz.

Docker ile Rootless Container Çalıştırma: Linux’ta Daha Güvenli ve Pratik Kurulum Rehberi

Rootless Docker nedir ve neden önemli?

Docker’ı çoğu sistemde “root” ayrıcalıklarıyla çalıştırmak alışıldık bir durumdur. Ancak bu yaklaşım, Docker daemon’una (dockerd) erişebilen bir kullanıcının sistem üzerinde beklenmedik yetkilere ulaşabilmesi gibi güvenlik riskleri doğurabilir. Rootless Docker, container’ları ve Docker daemon’unu root yetkisi olmadan, sıradan bir kullanıcı hesabı altında çalıştırarak saldırı yüzeyini azaltmayı hedefler. Özellikle çok kullanıcılı makinelerde, geliştirme sunucularında veya güvenlik hassasiyeti yüksek ortamlarda rootless yaklaşım belirgin bir avantaj sağlar.

Bu yazıda, güncel Linux dağıtımlarında rootless Docker’ı adım adım kuracak, ağ ve port yönlendirme gibi sık karşılaşılan noktaları netleştirecek ve kullanım sırasında işinize yarayacak pratik ipuçlarını paylaşacağım. Anlatım Debian/Ubuntu çizgisinde olsa da, Fedora/Arch gibi dağıtımlarda da kavramlar büyük ölçüde aynıdır.

Ön koşullar ve temel kavramlar

Rootless modun arkasında birkaç önemli mekanizma bulunur: Linux user namespace (kullanıcı isim alanı) sayesinde container içindeki “root”, host üzerinde gerçek root olmaz; ayrıca ağ tarafında çoğunlukla slirp4netns veya benzeri user-space ağ çözümleri devreye girer. Bu sayede Docker, root yetkisi olmadan da container’lara izolasyon sağlayabilir. Yine de bazı sınırlamalar vardır: düşük portlara (1-1023) doğrudan bind etmek, belirli network sürücüleri veya bazı kernel özellikleri rootless senaryoda farklı davranabilir.

Gerekenler: 1) Güncel bir Linux kernel (çoğu modern dağıtım yeterli), 2) Sisteminizde Docker’ın rootless araçları (paket içeriği veya docker-ce kurulumuyla gelir), 3) user namespace desteği (genelde açıktır), 4) Ağ için slirp4netns ve yardımcı araçlar (dağıtıma göre paket isimleri değişebilir).

Kurulum: Rootless Docker’ı etkinleştirme

Önce Docker’ın sisteminizde kurulu olduğundan emin olun. Dağıtımınızın deposundan veya Docker’ın resmi paketlerinden kurulumu yapabilirsiniz. Rootless kurulumun kritik adımı, kullanıcı bazında bir Docker daemon’u başlatmaktır. Bunun için Docker, genellikle dockerd-rootless-setuptool.sh adlı bir yardımcı betik sağlar.

Terminalde kullanıcı hesabınızla şu komutu çalıştırın (dosya yolu dağıtıma göre değişebilir):

dockerd-rootless-setuptool.sh install

Bu işlem, kullanıcı seviyesinde systemd servisleri tanımlar ve Docker socket’ini kullanıcı dizininize taşır. Kurulum tamamlandığında size çoğu zaman bir “DOCKER_HOST” önerisi de gösterilir. Tipik olarak rootless Docker socket’i şu yolda olur:

unix:///run/user/1000/docker.sock

Eğer systemd kullanıyorsanız, rootless daemon’u şu şekilde yönetebilirsiniz:

systemctl --user start docker

systemctl --user enable docker

Ardından Docker istemcisinin doğru socket’e bağlanması gerekir. Çoğu kurulum betiği ortam değişkeni önerir. Örneğin:

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

Bu değişkeni kalıcı yapmak için shell profilinize ekleyebilirsiniz (ör. ~/.bashrc veya ~/.zshrc). Sonrasında kontrol için:

docker info

Çıktıda “rootless” ibaresini ve “Server” kısmında kullanıcı-oturumuna bağlı socket yolunu görmeniz beklenir.

Portlar, ağ ve “1024 altı” konusu

Rootless Docker’da en çok takılınan başlık port yönlendirmedir. Normalde root yetkisiyle 80/443 gibi düşük portlara bind etmek kolaydır; rootless modda ise bu portlar için ek ayar gerekir. İki pratik yaklaşım var: 1) Container’ı 8080/8443 gibi yüksek portlarda yayınlayıp reverse proxy ile 80/443’e taşımak, 2) Rootless için port yönlendirme yardımcılarını kullanmak (dağıtıma ve kurulum biçimine göre değişebilir).

Basit bir test için Nginx container’ını 8080’e yayınlayabilirsiniz:

docker run --rm -p 8080:80 nginx:latest

Tarayıcıdan http://localhost:8080 ile kontrol edin. Bu senaryo rootless modda genellikle sorunsuz çalışır.

Depolama ve performans notları

Rootless modda depolama sürücüsü seçimi ve overlay kullanımı dağıtıma göre değişebilir. Modern sistemlerde “overlay2” çoğu zaman mümkün olsa da, bazı ortamlarda “fuse-overlayfs” devreye girer. Bu, uyumluluk açısından avantaj sağlarken belirli iş yüklerinde performansı etkileyebilir. Eğer çok sayıda küçük dosya operasyonu yapan build süreçleriniz varsa (ör. büyük Node.js bağımlılıkları veya yoğun katmanlı Dockerfile’lar), rootless ve rootful performansını kendi ortamınızda kıyaslamak mantıklıdır.

Bir diğer pratik nokta: Rootless kurulum, imajları ve container verisini kullanıcı dizinine yakın bir yerde tutar. Bu da çok kullanıcı bulunan sistemlerde kullanıcı başına ayrı izolasyon sağlar. Öte yandan disk kotası, home dizini şifrelemesi veya NFS üzerinde home kullanımı gibi durumlar performansı etkileyebilir.

Güvenlik açısından artılar ve dikkat edilmesi gerekenler

Rootless Docker, “Docker grubuna eklenen kullanıcı root olur” eleştirisini önemli ölçüde azaltır; daemon ve container’lar ayrıcalıksız çalıştığı için bir kaçış senaryosunun etkisi genellikle sınırlanır. Yine de bu, tüm risklerin sıfırlandığı anlamına gelmez. Container içindeki uygulamalarınıza dair zafiyetler, yanlış volume mount kullanımı veya hassas dosyaların container’a verilmesi gibi hatalar rootless modda da sorun çıkarabilir.

Öneriler: Gereksiz yetkileri kapatın, container’lara sadece ihtiyaç duyduğu klasörleri bind edin, mümkünse read-only mount kullanın, “latest” yerine sabit etiketli imajlar tercih edin ve düzenli olarak imajlarınızı güncelleyin.

Ne zaman rootless tercih edilmeli?

Eğer kişisel geliştirme makinenizde, paylaşımlı bir Linux sunucusunda veya CI ortamında Docker kullanıyorsanız rootless yaklaşım ciddi bir güvenlik artısı sağlar. “Ben zaten sudo kullanıyorum” diyenler için bile rootless, Docker daemon’u üzerinden gelebilecek ayrıcalık yükseltme risklerini azaltır. Bununla birlikte özel network gereksinimleri, düşük port zorunluluğu veya yüksek I/O performansı gibi ihtiyaçlarınız varsa rootful Docker hâlâ daha uygun olabilir. İdeal yaklaşım, iş yüküne göre iki modeli de doğru yerde kullanmaktır.

Bu rehberdeki adımlarla rootless Docker’ı aktif ettikten sonra günlük kullanım alışkanlıklarınız çok değişmeden, daha güvenli bir çalışma düzenine geçebilirsiniz. İlk etapta port ve ağ detaylarını netleştirmeniz, sonrasında da build ve runtime performansını kendi projenizde test etmeniz yeterli olacaktır.

Cloudflare Zero Trust ile Uygulamalarını İnternete Açmadan Yayına Al: Tunnel Kurulumu ve İnce Ayarlar

İnternete Port Açmadan Yayınlamak Neden Önemli?

Evde ya da küçük bir ofiste bir web paneli, API, yönetim arayüzü veya test ortamı çalıştırıyorsanız “router’dan port yönlendirme” genellikle ilk akla gelen yöntem olur. Ancak bu yaklaşım, servisinizin doğrudan internete açılması demektir: zafiyet taramaları, brute force denemeleri ve yanlış yapılandırmalar bir anda ciddi bir güvenlik riskine dönüşebilir. Modern yaklaşım, uygulamayı dış dünyaya “açmadan” erişilebilir kılmak ve erişimi kimlik doğrulama politikalarıyla kontrol etmektir.

Bu yazıda Cloudflare Zero Trust ekosisteminin en pratik parçalarından biri olan Cloudflare Tunnel (cloudflared) ile, içeride çalışan bir servisi port açmadan dışarıya yayınlamayı anlatacağım. Ayrıca gerçek hayatta iş gören ayarları: alt alan adı yönlendirme, erişim politikaları, HTTPS davranışı ve temel sorun giderme adımlarını da ekleyeceğim.

Cloudflare Tunnel Nedir, Ne İşe Yarar?

Cloudflare Tunnel, içerideki sunucunuzdan Cloudflare ağına doğru çıkış yönlü (outbound) bir tünel kurar. Yani modeminizde inbound port açmazsınız. cloudflared arka planda Cloudflare’a bağlanır; ziyaretçi tarafında gelen istekler Cloudflare üzerinden bu tünelden iç servisinize iletilir. Böylece hem saldırı yüzeyi küçülür hem de Cloudflare’ın WAF, rate limit, Access politikaları gibi katmanları devreye alınabilir.

Ön Koşullar

1) Cloudflare’da yönetebildiğiniz bir alan adı (domain) 2) Cloudflare Zero Trust paneline erişim (ücretsiz plan çoğu senaryo için yeterli) 3) İç ağınızda yayınlanan bir servis: örneğin http://localhost:3000 veya http://192.168.1.50:8080 4) Linux/Windows/macOS üzerinde çalışacak bir makine (tüneli bu makine kuracak)

Adım Adım Kurulum (Zero Trust Panel Üzerinden)

1) Zero Trust’a girin: Cloudflare Dashboard > Zero Trust. Sol menüden Access veya Networks altından Tunnels bölümünü bulun.

2) Yeni tünel oluşturun: “Create a tunnel” deyin, tünele anlamlı bir isim verin (ör. ev-lab).

3) cloudflared kurun: Cloudflare, işletim sisteminize göre komutları ekranda gösterir. Linux için çoğunlukla paket deposu veya tek ikili (binary) ile kurulum sağlanır. Kurulumdan sonra, panelin verdiği komutla tüneli makinenize “bağlarsınız”. Bu adım, makinenizde kimlik doğrulaması yaparak tüneli Cloudflare hesabınıza iliştirir.

4) Public Hostname tanımlayın: Tünelin “Public Hostname” kısmında bir alt alan adı seçin. Örneğin panel.orneksite.com. “Service” bölümüne ise içerideki hedefi yazın: örneğin http://localhost:3000 ya da http://192.168.1.50:8080. Bu noktadan sonra Cloudflare, gelen trafiği tünel üzerinden doğru servise yönlendirmeyi bilir.

HTTPS, Origin ve Güvenli Varsayılanlar

Cloudflare tarafında kullanıcılar genellikle HTTPS ile bağlanır. İçerideki servisiniz HTTP çalışıyor olabilir; bu sorun değildir. Cloudflare, edge’de HTTPS sonlandırıp tünel üzerinden HTTP ile iletebilir. Yine de hassas bir panel yayınlıyorsanız, içeride de TLS kullanmak veya en azından erişimi Cloudflare Access ile kilitlemek iyi fikirdir.

Ek bir güvenlik adımı olarak, panel yayınlıyorsanız Cloudflare WAF kuralları, bot koruması ve rate limit seçeneklerine göz atın. Tunnel kullanmak tek başına “güvenli” anlamına gelmez; yetkisiz erişimi engelleyecek politika katmanı şarttır.

Cloudflare Access ile Kim Girebilir? (Gerçek Hayat Senaryosu)

En güçlü taraflardan biri, uygulamanıza giriş için IP whitelist yerine kimlik tabanlı kontrol sunmasıdır. Örneğin sadece Google Workspace hesabınızla giriş yapılmasını isteyebilirsiniz.

1) Zero Trust > Access > Applications > “Add an application” (Self-hosted seçin). 2) Uygulama alan adını seçin (ör. panel.orneksite.com). 3) Policy oluşturun: “Allow” ve şart olarak e-posta domain’i, belirli e-posta adresleri veya bir kimlik sağlayıcı grubu ekleyin. 4) İsterseniz ek doğrulama (MFA) koşulları ekleyin.

Bu sayede uygulamanız internete açık görünse bile, içeri girmek için kullanıcı Cloudflare Access ekranından geçmek zorunda kalır. Özellikle admin panelleri, Home Assistant, Grafana, Portainer, Git servisleri gibi araçlarda bu yaklaşım port açmaya göre çok daha kontrollüdür.

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

403/Access ekranı gelmiyor: Access uygulaması doğru hostname’e bağlandı mı kontrol edin. DNS kaydı Cloudflare proxy (turuncu bulut) arkasında mı? Tunnel tarafında “Public Hostname” doğru mu?

502/Bad Gateway: Tünel ayakta olsa bile içeride hedef servis yanıt vermiyor olabilir. Makinede curl http://localhost:3000 gibi bir test yapın. Hedef IP/port doğru mu, servis sadece 127.0.0.1’e mi bağlı, güvenlik duvarı trafiği kesiyor mu kontrol edin.

Performans dalgalanması: Aynı tüneli birden fazla “connector” ile çoğaltmak (yük devretme) mümkün. Kritik servislerde tüneli iki farklı makinede çalıştırarak kesintiye dayanıklılığı artırabilirsiniz.

Ne Zaman Tercih Etmelisiniz?

Cloudflare Tunnel; ev lab ortamları, küçük ekiplerin dahili araçları, müşteri demosu, staging ortamları ve port açmanın kurumsal politikalarla engellendiği senaryolarda çok iyi çalışır. “Hızlıca yayınla, sonra erişimi kilitle” yaklaşımı için idealdir. Buna karşın çok özel ağ topolojileri, L4 seviyesinde özel protokoller veya uçtan uca sertifikalı mTLS gibi gereksinimler varsa tasarımı biraz daha detaylı düşünmek gerekir.

Sonuç

Cloudflare Zero Trust + Tunnel ikilisi, klasik port yönlendirme yöntemini büyük ölçüde gereksiz kılıyor. En önemli kazanım, uygulamayı internete açmadan erişilebilir hale getirirken kimlik doğrulama ve politika katmanını işin merkezine koyması. Bir kez kurduktan sonra yeni servis eklemek de oldukça pratik: yalnızca yeni bir hostname ve hedef servis tanımlıyorsunuz, gerisini tünel taşıyor.

Ev Ağında DNS-over-HTTPS (DoH) Kurulumu: Pi-hole + Unbound ile Reklamsız ve Daha Güvenli DNS

DNS neden hâlâ önemli?

İnternette bir siteye girdiğinizde tarayıcınız önce alan adını (ör. ornek.com) bir IP adresine çevirir. Bu çeviri işlemini DNS yapar. Sorun şu: Klasik DNS trafiği çoğu ağda şifresizdir ve hem ISS düzeyinde hem de aynı ağdaki kötü niyetli bir kişi tarafından gözlemlenebilir. Ayrıca reklam, izleyici ve zararlı alan adlarını engellemek için merkezi bir DNS filtreleme yaklaşımı, tüm cihazlarda tek tek eklenti kurmaktan daha temiz bir çözüm sunar.

Bu rehberde ne kuruyoruz?

Bu “How-To” yazısında ev/Ofis ağında Pi-hole ile reklam/izleyici alan adlarını engelleyen bir DNS filtresi, Unbound ile yerel recursive DNS çözümleyici ve dışarıya çıkarken DNS-over-HTTPS (DoH) kullanarak şifreli DNS trafiği kuracağız. Hedef: ağdaki tüm cihazlar için daha hızlı, daha gizli ve daha az reklamlı bir deneyim. Kurulum örnekleri Debian/Ubuntu tabanlı bir mini PC veya Raspberry Pi üzerinde ilerleyecek.

Ön koşullar

Donanım: Raspberry Pi 3/4 veya düşük güç tüketimli bir mini PC idealdir. Yazılım: Debian/Ubuntu türevi bir Linux, root/sudo erişimi. Ağ: Cihaza statik IP atamanız önerilir (ör. 192.168.1.2). Ayrıca modem/router arayüzüne girip DHCP DNS ayarını değiştirebilmeniz gerekir.

1) Pi-hole kurulumu

Pi-hole kurulumunu resmi script ile yapmak en pratik yöntemdir. Sunucunuzda terminali açın ve güncelleme sonrası kurulumu başlatın:

Komutlar:
sudo apt update && sudo apt upgrade -y
curl -sSL https://install.pi-hole.net | bash

Kurulum sihirbazında ağ arayüzünü seçin, statik IP önerisini kabul edin ve yönetim paneli için parolayı not edin. Kurulum sonunda Pi-hole web paneli genellikle http://cihaz-ip/admine üzerinden erişilir. İlk etapta upstream DNS olarak geçici bir sağlayıcı seçebilirsiniz; birazdan bunu Unbound’a yönlendireceğiz.

2) Unbound ile yerel recursive DNS

Unbound, sorguları doğrudan kök DNS sunucularına kadar takip ederek çözen yerel bir recursive çözümleyicidir. Böylece tek bir harici DNS sağlayıcısına bağımlılığınız azalır ve önbellek avantajı elde edersiniz:

Kurulum:
sudo apt install unbound -y

Pi-hole ile çakışmaması için Unbound’u yerelde farklı bir portta çalıştırmak iyi bir pratiktir. Örnek bir Unbound yapılandırması oluşturun:

Dosya: /etc/unbound/unbound.conf.d/pi-hole.conf
İçerik:
server:
  verbosity: 0
  interface: 127.0.0.1
  port: 5335
  do-ip4: yes
  do-udp: yes
  do-tcp: yes
  root-hints: "/var/lib/unbound/root.hints"
  cache-min-ttl: 300
  cache-max-ttl: 86400
  hide-identity: yes
  hide-version: yes
  qname-minimisation: yes

Root hints dosyasını indirip servisi başlatın:

Komutlar:
sudo curl -o /var/lib/unbound/root.hints https://www.internic.net/domain/named.cache
sudo systemctl enable --now unbound
sudo systemctl restart unbound

3) DoH katmanı: şifreli DNS çıkışı

Burada iki yaklaşım var: (A) Unbound’u doğrudan recursive kullanmak ve sadece “dış DNS sağlayıcıya” gitmemek; (B) Mutlaka bir sağlayıcıya gidecekseniz bunu DoH ile yapmak. Bu yazıda pratikliği nedeniyle cloudflared (DoH proxy) örneğini kullanacağız. Böylece Pi-hole → Unbound yerine Pi-hole → DoH proxy veya Unbound → DoH proxy senaryosu kurulabilir. En yaygın kullanım, Pi-hole’un upstream DNS’ini DoH proxy’ye vermektir.

cloudflared kurulumu (Debian/Ubuntu):
sudo apt install cloudflared -y

cloudflared’ı yerelde DNS proxy olarak çalıştırın (ör. 127.0.0.1:5053):

Komut:
sudo cloudflared proxy-dns --address 127.0.0.1 --port 5053 --upstream https://1.1.1.1/dns-query --upstream https://1.0.0.1/dns-query

Bunu kalıcı servis yapmak için dağıtımınıza uygun systemd birim dosyası oluşturabilir veya cloudflared paketinin servis seçeneklerini kullanabilirsiniz. Mantık basit: DNS sorguları yerelden çıkar, HTTPS içinde şifrelenmiş şekilde DoH sağlayıcısına gider.

4) Pi-hole’u Unbound veya DoH’a yönlendirme

Pi-hole yönetim panelinde Settings > DNS bölümüne gidin. Burada hazır DNS sağlayıcılarını kapatıp Custom (IPv4) alanına bir upstream tanımlayın:

Seçenek 1 (Recursive): 127.0.0.1#5335 (Unbound)
Seçenek 2 (DoH): 127.0.0.1#5053 (cloudflared)

İkisini aynı anda kullanacaksanız mimariyi netleştirin: ya Pi-hole doğrudan Unbound’a gider (en bağımsız yaklaşım), ya Pi-hole doğrudan DoH proxy’ye gider (en basit şifreleme). “Unbound + DoH” birlikte de yapılabilir; ancak yapılandırma karmaşıklığı artar ve hata ayıklamak zorlaşır.

5) Router/DHCP ayarı: tüm ağa yayma

Amaç, ev ağındaki tüm cihazların DNS olarak Pi-hole’u kullanmasıdır. Router arayüzünde DHCP DNS sunucusunu Pi-hole IP adresi (ör. 192.168.1.2) yapın. Alternatif olarak DHCP’yi Pi-hole’un yönetmesine izin verebilirsiniz; fakat çoğu ev ağında router DHCP’si üzerinden DNS dağıtmak daha sorunsuzdur.

Test ve doğrulama

İstemci cihazınızda DNS sunucusunun Pi-hole’a döndüğünü kontrol edin. Ardından Pi-hole panelinde Query Log akışını izleyin. DoH doğrulaması için cloudflared loglarını takip edebilir veya dış DNS sorgularınızın 443 portu üzerinden çıktığını ağ izleme araçlarıyla gözlemleyebilirsiniz. Bir başka pratik test: reklam ağırlıklı bir sitede sayfa yükleme süreleri ve reklam sayısı belirgin biçimde azalmalıdır.

Sık karşılaşılan sorunlar

İnternet gidiyor, DNS çözemiyor: Router’da hâlâ ikinci DNS olarak ISS’nin DNS’i kalmış olabilir; cihazlar bazen onu seçer. DHCP DNS alanında yalnızca Pi-hole IP’si kaldığından emin olun.
Bankacılık/akış servisleri bozuldu: Bazı engelleme listeleri agresif olabilir. Pi-hole’da ilgili alan adını whitelist’e alın veya listeyi değiştirin.
DoH proxy çalışmıyor: 5053 portunu başka bir servis kullanıyor olabilir; portu değiştirip Pi-hole’daki custom upstream’i güncelleyin.

Sonuç

Pi-hole ile ağ genelinde reklam ve izleyici engellemek, günlük internet deneyimini gözle görülür şekilde iyileştirir. Üstüne Unbound ile recursive çözümleme eklediğinizde daha bağımsız ve tutarlı bir DNS altyapısı elde edersiniz. DoH kullanımı ise DNS trafiğini şifreleyerek ağdaki pasif izlemeyi zorlaştırır. Bu üçlüden hangisini seçeceğiniz ihtiyaçlarınıza bağlı; ancak ev ağı için “Pi-hole + DoH” en hızlı kazanım sağlayan, “Pi-hole + Unbound” ise en bağımsız yaklaşım olarak öne çıkar.

Windows 11’de WSL2 ile Docker Desktop Kullanmadan Docker Kurulumu ve İleri Seviye Ayarlar

Docker Desktop’sız Docker: Neden ve Ne Kazandırır?

Windows 11 üzerinde Docker kullanmanın en popüler yolu Docker Desktop kurmaktır. Ancak kurumsal lisans politikaları, kaynak tüketimi, arka planda çalışan servislerin fazlalığı veya daha “Linux’a yakın” bir Docker deneyimi isteği, birçok geliştiriciyi alternatif arayışına itiyor. İyi haber şu: WSL2 sayesinde Docker Engine’i doğrudan Linux tarafında kurup, Windows’tan komut satırı ile yönetmek mümkün. Bu yöntem genellikle daha hafif çalışır, daha kontrol edilebilir bir yapı sunar ve özellikle terminal odaklı geliştiriciler için oldukça rahattır.

Bu yazıda, Windows 11’de WSL2 (Ubuntu örneğiyle) kullanarak Docker Engine kurulumunu, Windows terminalinden Docker komutlarını çalıştırmayı ve performans/depoma/ ağ ayarları gibi birkaç ileri seviye noktayı adım adım ele alacağım. Sonuçta Docker Desktop olmadan da modern konteyner geliştirme akışını sürdürebileceksiniz.

Ön Koşullar: WSL2 ve Ubuntu Kurulumu

Öncelikle sisteminizde WSL2 aktif olmalı. Windows Terminal veya PowerShell’i yönetici olarak açıp aşağıdaki komutu çalıştırabilirsiniz:

wsl --install

Kurulum tamamlandıktan sonra Microsoft Store üzerinden Ubuntu yükleyebilir ya da komutla kurabilirsiniz. Ardından Ubuntu’yu açıp kullanıcı adı/parola belirleyin. WSL sürümünü kontrol etmek için:

wsl -l -v

Ubuntu’nun VERSION sütununda 2 yazdığından emin olun. Değilse:

wsl --set-version Ubuntu 2

Adım 1: Ubuntu’da Docker Engine Kurulumu (Resmi Depo)

WSL içindeki Ubuntu terminalinde önce paketleri güncelleyin:

sudo apt update && sudo apt upgrade -y

Gerekli paketleri yükleyin:

sudo apt install -y ca-certificates curl gnupg

Docker’ın resmi GPG anahtarını ekleyin ve depo kaynağı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

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

Sonra Docker paketlerini kurun:

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

Adım 2: Docker Servisini WSL’de Çalıştırma

WSL2’de systemd artık destekleniyor; en temiz yöntem systemd’yi açmaktır. Ubuntu içinde /etc/wsl.conf dosyasını düzenleyin:

sudo nano /etc/wsl.conf

İçeriğe şunu ekleyin:

[boot]
systemd=true

Ardından Windows tarafında WSL’i kapatıp yeniden başlatın:

wsl --shutdown

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

sudo systemctl enable docker
sudo systemctl start docker
sudo systemctl status docker

Adım 3: Sudo’suz Docker Kullanımı (Geliştirici Konforu)

Her komutta sudo yazmamak için kullanıcıyı docker grubuna ekleyin:

sudo usermod -aG docker $USER

Değişikliğin uygulanması için oturumu kapatıp açın ya da Ubuntu terminalini kapatıp yeniden başlatın. Test:

docker run --rm hello-world

Windows Terminal’den Docker Komutlarını Yönetmek

Docker Engine WSL içinde çalıştığı için en basit yönetim biçimi, Windows Terminal’de doğrudan Ubuntu profilini kullanmaktır. Yani komutları Ubuntu sekmesinde çalıştırdığınızda her şey doğal şekilde ilerler. Eğer PowerShell’den tek satırla çalıştırmak isterseniz:

wsl -d Ubuntu -- docker ps

Bu yaklaşım, CI benzeri yerel script’lerde veya kısa kontrollerde oldukça işe yarar.

İleri Seviye Ayar 1: WSL Kaynak Sınırları (RAM/CPU)

WSL, varsayılan olarak sistem kaynaklarını dinamik kullanır. Docker build süreçleri ağırlaştığında RAM tüketimi artabilir. Bunu sınırlamak için Windows kullanıcı dizininize .wslconfig dosyası oluşturup örnek bir sınır koyabilirsiniz:

[wsl2]
memory=6GB
processors=4

Değişiklikten sonra wsl --shutdown yaparak yeniden başlatın. Bu ayar, özellikle dizüstü bilgisayarlarda fan ve pil performansını belirgin şekilde iyileştirir.

İleri Seviye Ayar 2: Dosya Performansı ve Proje Konumu

Kritik nokta şu: Docker konteynerleri WSL içindeki Linux dosya sisteminde daha hızlı çalışır. Projeyi /home/kullanici/proje altında tutmak genelde, projeyi /mnt/c üzerinden Windows dosya sisteminde tutmaktan daha performanslıdır. Özellikle Node.js bağımlılıkları, PHP vendor dizinleri veya çok sayıda küçük dosya içeren projelerde fark gözle görülür hale gelir.

İleri Seviye Ayar 3: Docker Compose v2 ve Buildx

Kurulumda gelen docker compose (v2) ve buildx eklentileri, modern geliştirme akışının temel parçaları. Örneğin çoklu servisli bir projeyi ayağa kaldırmak için:

docker compose up -d

Daha hızlı ve tekrar kullanılabilir build işlemleri için build cache’i etkin kullanan bir Dockerfile tasarlamak, WSL ortamında da doğrudan avantaj sağlar. Ayrıca buildx ile farklı platformlar için build almak (ör. linux/amd64 ve linux/arm64) ileri seviye senaryolarda elinizi güçlendirir.

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

Docker daemon çalışmıyor: systemd açık mı kontrol edin. cat /etc/wsl.conf ile doğrulayın, ardından wsl --shutdown ile yeniden başlatın.

Permission denied: Kullanıcınız docker grubunda olmayabilir. groups komutuyla kontrol edin, gerekirse usermod -aG docker adımını tekrarlayın.

Disk şişmesi: Konteyner ve imajlar büyüdükçe WSL sanal diski genişler. Düzenli olarak docker system prune kullanmak ve gereksiz imajları temizlemek iyi bir alışkanlıktır.

Sonuç

Docker Desktop kullanmadan, WSL2 üzerinde Docker Engine çalıştırmak Windows 11’de hem pratik hem de “Linux’a yakın” bir geliştirme ortamı sunuyor. Kurulum bir kez oturduğunda günlük kullanımda fark edilir bir hafiflik sağlıyor; kaynak yönetimi daha esnek oluyor ve terminal odaklı iş akışları daha akıcı ilerliyor. Eğer konteyner geliştirmeyi daha kontrollü ve minimal bir kurulumla sürdürmek istiyorsanız, bu yöntem kesinlikle değerlendirilmeye değer.

Docker ile Rootless (Yetkisiz) Container Çalıştırma: Güvenli Kurulum ve İnce Ayar Rehberi

Rootless Docker nedir ve neden önemli?

Docker çoğu sistemde varsayılan olarak root yetkisiyle çalışan bir “daemon” kullanır. Bu, günlük kullanımda pratik olsa da saldırı yüzeyi açısından risklidir: bir konteynerden kaçış (container escape) veya yanlış yapılandırılmış bir bind mount gibi senaryolarda etkiler büyüyebilir. Rootless Docker ise Docker’ı sistemde ayrıcalıklı (root) bir servis olarak çalıştırmadan, normal bir kullanıcı hesabı altında çalıştırmanıza imkân tanır. Böylece olası bir ihlal durumunda etki alanı, o kullanıcıyla sınırlı kalır.

Bu yazıda rootless Docker’ı kurup yapılandıracağız; ayrıca ağ, port yönlendirme, dosya izinleri ve performans tarafındaki kritik ayrıntıları netleştireceğiz. Anlatım Linux odaklıdır ve özellikle Ubuntu/Debian türevlerinde sorunsuz ilerler; Fedora ve benzerlerinde komutlar büyük ölçüde aynıdır.

Ön koşullar

Rootless Docker için çekirdek tarafında kullanıcı ad alanları (user namespaces) ve bazı yardımcı araçlar gerekir. Önce sisteminizde aşağıdakilerin yüklü olduğundan emin olun: uidmap (newuidmap/newgidmap), slirp4netns (rootless ağ), fuse-overlayfs (rootless overlay sürücüsü, her sistemde şart değil) ve mümkünse güncel bir Docker paketi.

Debian/Ubuntu için temel paketler: sudo apt-get update ardından sudo apt-get install -y uidmap slirp4netns fuse-overlayfs. Docker’ı dağıtımın deposundan veya Docker’ın resmi deposundan kurabilirsiniz; rootless mod için modern sürüm önerilir.

Subuid/subgid yapılandırması

Rootless modun kalbi, kullanıcıya ayrılmış UID/GID aralıklarıdır. Sistem, normal kullanıcının konteyner içinde farklı kimliklerle işlem yapabilmesi için bu aralıkları /etc/subuid ve /etc/subgid dosyalarında tutar. Çoğu dağıtımda kurulum sırasında otomatik eklenir; yine de kontrol etmek iyi fikir.

Örnek satır formatı şöyledir: kullanici:100000:65536. Eğer yoksa eklemek için root yetkisi gerekir. Değerler sisteminize göre değişebilir; önemli olan çakışmayan bir aralık olmasıdır. Bu aşamayı doğru yapmak, ileride “permission denied” türü gizemli hataları ciddi ölçüde azaltır.

Rootless kurulumu: dockerd-rootless-setuptool.sh

Docker’ın rootless kurulumu genellikle tek bir komutla yapılır. Normal kullanıcı hesabınızla oturum açtıktan sonra şu komutu çalıştırın: dockerd-rootless-setuptool.sh install. Bazı sistemlerde bu script PATH içinde değilse, Docker paketinin dokümantasyonundaki konuma göre çağırmanız gerekebilir.

Kurulum sonunda size genellikle iki kritik bilgi verilir: Docker soketinin bulunduğu yol ve ortam değişkeni önerisi. Rootless Docker çoğunlukla kullanıcı seviyesinde çalıştığı için soket yolu $XDG_RUNTIME_DIR/docker.sock benzeri bir konumda olur. Terminalinizde rootless bağlamı kullanmak için çoğu zaman export DOCKER_HOST=unix:///run/user/$(id -u)/docker.sock yeterlidir.

Servis olarak çalıştırma (systemd --user)

Sürekli kullanım için rootless Docker’ı kullanıcı servisi olarak çalıştırmak idealdir. Kurulum script’i çoğu zaman systemctl --user enable --now docker adımını önerir. Böylece sistem açıldığında, kullanıcı oturumu etkinleştiğinde Docker arka planda hazır olur.

Eğer “linger” etkin değilse, kullanıcı oturumu kapandığında servis durabilir. Sunucu senaryolarında bunun önüne geçmek için sudo loginctl enable-linger kullanici komutu işe yarar. Bu sayede kullanıcı oturumu kapalı olsa bile user-level servisler çalışmaya devam eder.

Port yönlendirme ve ağ kısıtları

Rootless modun en çok sorulan kısmı port yayınlamadır. Linux’ta 1024 altı “privileged port” sayılır ve root gerektirir. Rootless Docker’da -p 80:80 gibi bir eşleme çoğu sistemde doğrudan çalışmaz. Alternatif olarak uygulamanızı 8080 gibi bir porta alabilir veya sistem çapında bir ters proxy (Nginx/Traefik) ile 80/443 trafiğini root yetkisi olan servis üzerinden yönlendirebilirsiniz.

Ağ tarafında rootless genellikle slirp4netns ile kullanıcı alanında NAT benzeri bir yapı kullanır. Bu, güvenlik açısından avantajlıdır; ancak bazı yoğun ağ senaryolarında performans farkı görülebilir. Geliştirme ortamlarında çoğu kullanıcı için yeterlidir; yüksek bant genişliği ve düşük gecikme hedefliyorsanız ölçüm yapmanız önerilir.

Depolama sürücüsü ve dosya izinleri

Rootless Docker, dosya sistemi sürücüsü olarak çoğu zaman fuse-overlayfs veya uygun bir alternatif kullanır. Bu, klasik root modundaki overlay2 kadar “ham performans” vermeyebilir; ama güncel çekirdek ve SSD üzerinde günlük işler için genellikle sorun çıkarmaz. İmaj çekme, build ve volume kullanımlarında davranış farklılıkları olabileceği için CI/CD ortamlarınızda deneme yapmak akıllıca olur.

Volume tarafında kritik nokta şudur: Konteyner içindeki UID/GID eşlemeleri, hosttaki dosya sahipliğiyle farklı görünebilir. “Dosyalar yazılamıyor” sorunu yaşarsanız önce mount ettiğiniz klasörün izinlerini, ardından konteynerin çalıştığı kullanıcıyı ve gerekiyorsa --user parametresini kontrol edin.

Hızlı test: Rootless çalışıyor mu?

Kurulumdan sonra şu komutlarla doğrulama yapabilirsiniz: docker info çıktısında rootless ibaresini arayın. Ardından basit bir konteyner başlatın: docker run --rm hello-world. İmaj iniyor ve konteyner sorunsuz çalışıyorsa temel kurulum tamamdır.

Son olarak küçük bir web testi yapmak isterseniz: docker run --rm -p 8080:80 nginx deyip tarayıcıdan http://localhost:8080 adresini kontrol edin. Eğer port erişimi varsa rootless ağ zinciri de doğru çalışıyor demektir.

Ne zaman rootless, ne zaman klasik Docker?

Rootless Docker; geliştirici makineleri, çok kullanıcılı sunucular, güvenliği öncelikleyen laboratuvar ortamları ve “en az yetki” yaklaşımı için güçlü bir seçenektir. Buna karşın düşük portlara doğrudan bind ihtiyacı, bazı ağ sürücüleri (macvlan benzeri) veya belirli kernel özelliklerine bağımlı iş yükleri gibi durumlarda klasik (root) Docker hâlâ daha sorunsuz olabilir.

İyi haber şu: Rootless’a geçiş genellikle geri dönüşü zor bir karar değildir. Aynı makinede her iki yaklaşımı da senaryoya göre kullanabilir, kritik servisleri geleneksel olarak yönetirken geliştirme ve test süreçlerinizi rootless ile daha güvenli hale getirebilirsiniz.

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.