Evde Kendi VPN’ini Kur: WireGuard ile Güvenli ve Hızlı Bağlantı Rehberi

WireGuard Nedir ve Neden Tercih Edilmeli?

Ev dışındayken ev ağınıza güvenli biçimde erişmek, halka açık Wi‑Fi’da trafiğinizi şifrelemek veya kendi kişisel VPN’inizi kurup üçüncü taraf hizmetlere bağımlılığı azaltmak istiyorsanız, WireGuard son yılların en pratik çözümlerinden biri. OpenVPN gibi köklü alternatiflere göre daha az bileşenle çalışır, kurulum ve bakım tarafı daha sade ilerler. Performans tarafında ise özellikle mobil cihazlarda hızlı bağlanma süresi ve düşük gecikme avantajı dikkat çeker.

Bu rehberde, evdeki bir Linux sunucusu (ör. Ubuntu) üzerinde WireGuard kurup telefonu veya dizüstünü güvenli şekilde bağlamayı adım adım anlatacağım. Anlatım ileri seviye sayılabilecek ağ konularına değinse de, komutları takip ederek güvenli bir kurulum yapmak mümkün.

Ön Koşullar: Ne Gerekli?

Kuruluma başlamadan önce şu hazırlıklar işinizi kolaylaştırır: (1) İnternete bağlı ve mümkünse 7/24 açık bir Linux makine (Ubuntu 22.04/24.04 gibi), (2) Modem/router üzerinde port yönlendirme yapabilme yetkisi, (3) Statik IP’niz yoksa bir DDNS alan adı (No-IP, DuckDNS vb.), (4) Sunucuda yönetici yetkisi (sudo). Ayrıca ev internetiniz CGNAT arkasındaysa port yönlendirme çalışmayabilir; bu durumda sağlayıcınızdan gerçek IP talep etmek veya ters tünel gibi farklı mimariler düşünmek gerekir.

1) WireGuard Kurulumu (Ubuntu)

Önce paketleri güncelleyin ve WireGuard’ı kurun:

Komutlar:
sudo apt update
sudo apt install -y wireguard

Ardından sunucu için anahtar çiftini üretin. Anahtarları doğru izinlerle saklamak güvenlik açısından kritik:

Komutlar:
umask 077
wg genkey | tee /etc/wireguard/server_private.key | wg pubkey > /etc/wireguard/server_public.key

2) Sunucu Yapılandırması: wg0.conf

WireGuard arayüzünü wg0 adıyla yapılandıralım. Aşağıdaki örnek, VPN ağı olarak 10.10.10.0/24 kullanır. Sunucuya 10.10.10.1 veriyoruz. Ayrıca IP yönlendirmeyi ve NAT’ı da ekliyoruz ki istemciler internet çıkışını VPN üzerinden yapabilsin (isteğe bağlı).

/etc/wireguard/wg0.conf dosyasını oluşturun:

Komut:
sudo nano /etc/wireguard/wg0.conf

Örnek içerik:
[Interface]
Address = 10.10.10.1/24
ListenPort = 51820
PrivateKey = (server_private.key içeriği)

PostUp = ufw route allow in on wg0 out on eth0; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = ufw route delete allow in on wg0 out on eth0; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

Not: Sunucunuzun dış bacak arayüz adı eth0 olmayabilir (ör. enp0s3). ip a ile kontrol edip wg0.conf içinde güncelleyin.

3) IP Forwarding Açma

VPN istemcilerinin ağlar arası paket iletebilmesi için kernel IP yönlendirmeyi açın:

Komutlar:
echo "net.ipv4.ip_forward=1" | sudo tee /etc/sysctl.d/99-wireguard.conf
sudo sysctl --system

4) Güvenlik Duvarı ve Port Yönlendirme

Sunucuda UFW kullanıyorsanız, WireGuard portunu açın:

Komutlar:
sudo ufw allow 51820/udp
sudo ufw enable

Router tarafında UDP 51820 portunu sunucunun yerel IP’sine yönlendirin. Eğer DDNS kullanıyorsanız, istemci yapılandırmasında IP yerine alan adınızı yazabilirsiniz.

5) İstemci (Telefon/Dizüstü) Anahtarı ve Peer Ekleme

Şimdi bir istemci oluşturalım. İsterseniz anahtarları istemci cihazında üretebilirsiniz; burada sunucuda üretip sonra istemciye aktaracağız:

Komutlar:
umask 077
wg genkey | tee /etc/wireguard/client1_private.key | wg pubkey > /etc/wireguard/client1_public.key

İstemciye 10.10.10.2 verelim. Sunucu yapılandırmasına istemciyi bir Peer olarak eklemek için wg0.conf dosyasının sonuna şunu ekleyin:

Ek satırlar:
[Peer]
PublicKey = (client1_public.key içeriği)
AllowedIPs = 10.10.10.2/32

6) İstemci Konfigürasyonu (WireGuard Uygulaması)

Telefonunuzda WireGuard uygulamasında yeni tünel oluşturup aşağıdaki yapıyı kullanın. Endpoint kısmına ev IP’nizi veya DDNS alan adınızı yazın. “AllowedIPs” alanı önemlidir: Tüm trafiği VPN’e yönlendirmek için 0.0.0.0/0 kullanılabilir; sadece ev ağına erişmek istiyorsanız daha dar bir aralık tanımlayın.

Örnek istemci dosyası:
[Interface]
PrivateKey = (client1_private.key içeriği)
Address = 10.10.10.2/32
DNS = 1.1.1.1

[Peer]
PublicKey = (server_public.key içeriği)
Endpoint = alanadiniz-or-ipniz:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

“PersistentKeepalive” özellikle mobil ağlarda veya NAT arkasında bağlantının düşmesini engellemek için faydalıdır.

7) Servisi Başlatma ve Test

Sunucuda WireGuard arayüzünü ayağa kaldırın ve otomatik başlatmayı etkinleştirin:

Komutlar:
sudo systemctl enable --now wg-quick@wg0
sudo wg show

İstemciden bağlandıktan sonra sunucuda “latest handshake” alanının güncellendiğini görmelisiniz. İstemci tarafında IP’nizi kontrol ederek trafiğin VPN üzerinden gidip gitmediğini anlayabilirsiniz. Eğer sadece ev ağına erişmek istiyorsanız, “AllowedIPs” değerini örneğin 192.168.1.0/24 gibi yerel ağa göre daraltmak performans ve yönlendirme karmaşıklığı açısından daha temiz olabilir.

Sık Karşılaşılan Sorunlar ve İpuçları

El sıkışma (handshake) yok: Port yönlendirme yanlış olabilir, sunucu güvenlik duvarı UDP 51820’yi engelliyor olabilir veya CGNAT nedeniyle dışarıdan erişim mümkün değildir.

Bağlanıyor ama internet yok: NAT (MASQUERADE) kuralı eksik olabilir, yanlış dış arayüz adı girilmiş olabilir veya IP forwarding açık değildir.

Güvenlik önerisi: WireGuard yapılandırmalarını yedekleyin ama özel anahtarları düz metin olarak paylaşmayın. İstemci kaybolursa ilgili peer’i sunucudan kaldırın ve anahtarları yenileyin.

Sonuç

WireGuard ile kendi VPN’inizi kurmak, hem hız hem de kontrol açısından çoğu “tek tık VPN” hizmetinden daha tatmin edici bir çözüm sunar. Kurulumun özü; doğru anahtar yönetimi, doğru port yönlendirme ve temiz bir yönlendirme/NAT kural seti oluşturmaktan geçiyor. Bir kez oturttuktan sonra yeni cihaz eklemek de sadece yeni bir peer tanımlamak kadar basit hale geliyor.

ChatGPT API ile Araç (Tools) Entegrasyonu: Gerçek Dünya İş Akışlarını Bağlamak İçin Adım Adım Rehber

ChatGPT “Tools” (Araç) Nedir ve Neden Önemli?

Büyük dil modelleri artık sadece soru-cevap üreten “akıllı sohbet” katmanından ibaret değil. OpenAI’nin Tools (araç çağırma) yaklaşımı sayesinde model, belirlediğiniz fonksiyonları çağırarak dış sistemlerle konuşabiliyor: veritabanı sorgulama, kargo durumunu çekme, takvim kaydı açma, CRM güncelleme, hatta bir log analizini başlatma gibi. Buradaki kritik nokta şu: Model “metin” üretirken, aynı zamanda yapılandırılmış bir biçimde hangi aracı hangi parametrelerle çalıştıracağını da önerebiliyor.

Bu rehberde ileri seviye ama uygulanabilir bir senaryo kuracağız: “Sipariş durumunu kontrol et” talebini alan bir asistanın, bir API’den sipariş bilgisini çekmesi ve kullanıcıya anlaşılır bir özet sunması. Örnekler basit görünebilir; ancak yapı taşları aynıdır ve kurumsal iş akışlarına rahatça ölçeklenir.

Mimari: Model + Araç Katmanı + Doğrulama

Sağlam bir araç entegrasyonu üç parçadan oluşur: (1) Model kullanıcı niyetini anlar ve gerekli aracı seçer, (2) Araç katmanı seçilen fonksiyonları güvenli şekilde çalıştırır, (3) doğrulama/guardrail ise yanlış parametreleri, yetkisiz işlemleri ve “halüsinasyon” kaynaklı hataları engeller. En yaygın hata, modele fazla yetki verip her şeyi “serbest metin” üzerinden yaptırmaktır. Bunun yerine her kritik işlemi araç fonksiyonlarına bölmek ve parametreleri şemayla kısıtlamak gerekir.

Örnek Senaryo: Sipariş Durumu Sorgulama

Senaryomuzda iki araç tanımlayacağız: get_order (sipariş detaylarını getir) ve list_orders (kullanıcının son siparişlerini listele). Kullanıcı sipariş numarasını bilmiyorsa model önce list_orders çağıracak, sonra kullanıcıya seçenek sunacak veya en olası siparişi soracak. Bu yaklaşım, gerçek hayatta destek ekiplerinin iş yükünü ciddi biçimde azaltır.

Araç Şemalarını Tasarlama (En Kritik Adım)

Araç şemaları ne kadar net olursa, modelin yanlış çağrı yapma ihtimali o kadar düşer. Parametreleri minimumda tutun, veri tiplerini belirleyin ve mümkünse enum kullanın. Örneğin “status” alanını serbest metin yerine belirli değerlerle sınırlandırmak, hem raporlama hem de güvenlik açısından faydalıdır.

Node.js ile Uygulama (Örnek Kod)

Aşağıdaki iskelet, OpenAI API üzerinden araç çağırmayı gösteren pratik bir örnektir. Mantık aynı kalsa da kullandığınız sürüm ve SDK isimleri değişebilir; bu nedenle kendi ortamınıza göre uyarlayın. Önemli olan, modelden gelen tool call isteğini yakalayıp ilgili fonksiyonu çalıştırmanız ve sonucu tekrar modele vermenizdir.

1) Kurulum
Node.js 18+ önerilir. Projenize SDK’yı ekleyin ve API anahtarını ortam değişkeni olarak saklayın. Anahtarı kesinlikle kod içine gömmeyin.

2) Araçların tanımlanması ve çağrı döngüsü

Örnek: Uygulama, kullanıcı “12345 numaralı sipariş nerede?” dediğinde get_order aracını çağırır.

Not: Aşağıdaki kod bir “iskelet”tir; gerçek projede hata yönetimi, zaman aşımı, rate limit ve loglama eklemelisiniz.

Kod (özet):

tools listesi içinde fonksiyon isimleri ve parametre şemaları tanımlanır. Model bir araç çağırmak isterse, uygulama bu çağrıyı yakalar, ilgili fonksiyonu çalıştırır ve çıktıyı tekrar “tool” rolüyle modele geri verir. Sonrasında model kullanıcıya nihai yanıtı üretir.

Uygulama mantığı (psödo-akış):
1) Kullanıcı mesajını modele gönder
2) Model “tool çağrısı” döndürürse: aracı çalıştır
3) Aracın sonucunu modele geri gönder
4) Modelin ürettiği son yanıtı kullanıcıya göster

Gerçek Hayat İpuçları: Güvenlik ve Doğruluk

Parametre doğrulama: Modelin gönderdiği değerleri “doğru kabul etmeyin”. Örneğin order_id için sadece sayısal değer ve belirli uzunluk kontrolü uygulayın. Ayrıca kullanıcı kimliğine göre erişim kontrolü yapın; bir kullanıcı başka birinin siparişini görmemeli.

Yetki sınırları: Araçları “okuma” ve “yazma” olarak ayırın. Örneğin iade başlatma gibi riskli işlemleri ayrı bir onay adımına bağlayın. Modelin tek bir cümleyle geri ödeme başlatabilmesi, güvenlik açığına dönüşebilir.

Cache ve maliyet: Sık sorgulanan bilgiler için kısa süreli cache kullanın. Aynı kullanıcı, aynı sipariş durumunu 10 saniye içinde tekrar sorarsa API’ye yeniden gitmek yerine cache’den yanıtlamak maliyeti düşürür.

Gözlemlenebilirlik: Tool çağrılarını, parametreleri (maskelenmiş şekilde) ve hata kodlarını loglayın. Üretimde “model neden yanlış araç çağırdı?” sorusunun cevabı ancak bu izlerle bulunur.

İnce Ayar: Sistem Talimatı ve Yanıt Formatı

Araç entegrasyonunda çoğu sorun, modelin “ne zaman araç çağıracağı”nın belirsiz olmasından çıkar. Sistem talimatında şu netlik işe yarar: “Siparişle ilgili bilgi isteyen kullanıcıda önce order_id var mı kontrol et; yoksa list_orders çağır; veri geldikten sonra kullanıcıya sadece özet ver; gereksiz teknik detay verme.” Böylece model hem kullanıcı deneyimini korur hem de hatalı çağrıları azaltır.

Sonuç

ChatGPT API ile Tools entegrasyonu, yapay zekâyı “konuşan bir arayüz” olmaktan çıkarıp doğrudan iş süreçlerine bağlayan en güçlü yaklaşımlardan biri. Doğru şema tasarımı, güvenli araç katmanı ve iyi bir çağrı döngüsüyle; destek, e-ticaret, finans, IT operasyonları gibi alanlarda ciddi verimlilik kazanımı sağlayabilirsiniz. Küçük bir sipariş sorgu senaryosuyla başladık; aynı prensiplerle stok kontrolü, randevu planlama, log analizi veya otomatik raporlama gibi daha karmaşık süreçlere rahatça geçebilirsiniz.

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.