16 Ocak 2026 Cuma

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

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

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

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

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

1) Ollama kurulumu

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

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

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

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

Komut: ollama run llama3.1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

15 Ocak 2026 Perşembe

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

Rootless Docker Nedir ve Neden Önemli?

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

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

Ön Koşullar: Sistem ve Kernel Gereksinimleri

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

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

Kurulum: Rootless Modu Etkinleştirme

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

dockerd-rootless-setuptool.sh install

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

systemctl --user start docker

Otomatik başlaması için:

systemctl --user enable docker

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

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

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

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

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

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

docker info

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

docker run --rm hello-world

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

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

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

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

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

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

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

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

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

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

14 Ocak 2026 Çarşamba

Android 15’te Private Space (Özel Alan) Nasıl Kurulur ve Günlük Hayatta Nasıl Kullanılır?

Private Space Nedir ve Neden Önemli?

Android 15 ile birlikte gelen Private Space (Özel Alan), telefonda ikinci bir “gizli profil” gibi çalışan, ayrı bir uygulama alanı sunuyor. Bu alanın en büyük farkı, uygulamaların ve bildirimlerin ana ekrandan ve uygulama çekmecesinden kolayca görünmemesi; ayrıca kilitliyken arama sonuçlarına, bildirim gölgelerine ve bazı öneri panellerine sızmaması. Özellikle aynı telefonu iş ve kişisel kullanım için paylaşanlar, sosyal medya/mesajlaşma uygulamalarını ayrı tutmak isteyenler veya meraklı gözlerden uzak kalması gereken uygulamaları olanlar için pratik bir güvenlik katmanı sağlıyor.

Bu yazıda Android 15’te Özel Alan’ı sıfırdan kurmayı, kilitleme mantığını, uygulama taşıma/kurma yöntemlerini ve günlük kullanımda işinize yarayacak ayarları adım adım anlatacağım. Not: Menü isimleri üreticiye göre (Pixel, Samsung, Xiaomi vb.) küçük farklılıklar gösterebilir; ancak mantık aynı.

Kurulum Öncesi: Gereksinimler ve Kısa Notlar

Özel Alan özelliği Android 15 ile sunulsa da her modelde aynı hızda gelmeyebilir. Cihazınızın Android sürümünü Ayarlar > Telefon hakkında bölümünden kontrol edin. Ayrıca, Özel Alan’ı açtığınızda genellikle ayrı bir kilit yöntemi tanımlamanız istenir: desen, PIN ya da parola. Biyometrik doğrulama (parmak izi/yüz) bazı cihazlarda ek kolaylık olarak sunulabilir.

Özel Alan’ın amacı “tam kripto kasası” olmak değil; günlük gizlilik ve ayrıştırma sağlamak. Yine de doğru ayarlarla, ana profilde uygulama izlerinin minimuma inmesini sağlayabilirsiniz.

Android 15’te Private Space (Özel Alan) Nasıl Açılır?

1) Ayarlar menüsünü açın: Ayarlar uygulamasına girin.

2) Güvenlik ve gizlilik bölümünü bulun: Çoğu cihazda Güvenlik ve gizlilik ya da Gizlilik altında yer alır.

3) Özel Alan / Private Space seçeneğini açın: Menüde Private Space veya Türkçeleştirilmiş olarak Özel Alan seçeneğini göreceksiniz.

4) Kilit yöntemini belirleyin: Ana ekran kilidinizden farklı bir PIN/desen belirlemek, pratikte daha iyi ayrım sağlar. Aynı PIN’i kullanmak kolaylık sağlasa da, gizlilik hedefi açısından önerilmez.

5) Başlangıç ayarlarını tamamlayın: Android, Özel Alan’da bildirimlerin nasıl davranacağına dair bazı varsayılanları seçmenizi isteyebilir. “Kilitliyken bildirim gösterme” gibi seçenekleri dikkatle ayarlayın.

Uygulamaları Özel Alan’a Kurma ve Taşıma

Özel Alan’ın en güzel yanı, uygulamaları “ayrı bir kutu” gibi yönetebilmeniz. İki temel yöntem var:

Yöntem A: Özel Alan içinden yeni uygulama kurma — Özel Alan’ı açtıktan sonra içerideki uygulama çekmecesinden Play Store’a girip uygulamayı oradan kurabilirsiniz. Bu şekilde kurulan uygulama, ana alandaki aynı uygulamadan ayrı çalışır; ayrı hesapla giriş yapabilir, ayrı bildirim kuralları tanımlayabilirsiniz.

Yöntem B: Mevcut uygulamayı kopyalama/ayrı örnek oluşturma — Bazı arayüzler, ana alandaki uygulamayı Özel Alan’a “taşıma” yerine “ayrı bir örnek” olarak ekler. Bu, özellikle WhatsApp/Telegram gibi uygulamalarda ikinci bir hesap yönetmek isteyenler için idealdir. Eğer cihazınız izin veriyorsa, uygulama detay ekranında Özel Alan’a ekle benzeri bir seçenek görürsünüz.

Özel Alan’ı Kilitleme Mantığı: Bildirimler, Arama ve Son Uygulamalar

Özel Alan kilitliyken, hedeflenen şey şu: Özel Alan uygulamalarının varlığı olabildiğince az iz bıraksın. Bu yüzden aşağıdaki ayarlar kritik:

Bildirimler: Özel Alan uygulamalarının bildirimlerini kilitliyken göstermemek, hem içerik sızıntısını hem de “uygulama kullanılıyor” izini azaltır. Ayarlarda Özel Alan bildirimleri için “kilitliyken gizle” seçeneğini tercih edin.

Arama/Öneriler: Ana ekrandaki arama çubuğu veya uygulama çekmecesi araması bazen uygulama önerileri sunar. Özel Alan kilitliyken bu önerilerin kapalı olduğundan emin olun.

Son uygulamalar ekranı: Çoklu görev ekranında (son uygulamalar) Özel Alan uygulamalarının önizleme kartı görünüyorsa, ilgili gizlilik ayarlarından “önizlemeyi gizle” seçeneğini açın. Bazı cihazlarda bu, uygulama bazlı bir izin olarak yer alır.

Günlük Kullanım Senaryoları: Ne Zaman Gerçekten İşe Yarıyor?

İş/Kişisel ayrımı: Şirket e-postası, kurumsal mesajlaşma veya iki farklı Google hesabı kullanıyorsanız, Özel Alan’ı “iş profilinden daha hafif” bir çözüm gibi düşünebilirsiniz. Uygulamalar karışmaz, bildirim düzeni daha kontrol edilebilir olur.

Seyahat ve paylaşım: Telefonunuzu kısa süreliğine birine verirken (navigasyon, fotoğraf gösterme vb.) Özel Alan kilitli kalır; içerideki uygulamalar ve veriler daha az görünür olur.

İkinci hesap yönetimi: Sosyal medya veya mesajlaşmada ikinci hesap ihtiyacı olanlar için, uygulama klonlama araçlarına göre daha “sistem içi” ve güvenli bir yaklaşım sunar.

İpuçları ve Dikkat Edilecek Noktalar

1) Özel Alan kilidini unutmayın: PIN/desen unutulursa kurtarma süreci can sıkıcı olabilir. Mümkünse güvenli ama hatırlanabilir bir PIN seçin.

2) Yedekleme beklentisini yönetin: Bazı üreticiler Özel Alan’daki uygulama verilerini yedeklerken sınırlamalar koyabilir. Kritik uygulamalarda kendi bulut senkronizasyonunu (ör. not uygulaması, şifre yöneticisi) ayrıca etkinleştirin.

3) Şifre yöneticisi kullanın: Özel Alan’da ayrı hesap açıyorsanız, güçlü parolaları yönetmek için bir şifre yöneticisi şart. Böylece hem güvenlik artar hem de hesap karmaşası azalır.

4) Kilit otomasyonu: Eğer cihazınız destekliyorsa Özel Alan’ı belirli süre kullanılmadığında otomatik kilitleyin. Bu, günlük hayatta unutkanlığı telafi eder.

Sonuç

Android 15’in Private Space (Özel Alan) özelliği, üçüncü parti uygulama klonlama çözümlerine başvurmadan, sistem düzeyinde daha derli toplu bir gizlilik ve ayrıştırma sunuyor. Doğru kurulum ve bildirim/arama/önizleme ayarlarıyla, telefonunuzu hem daha düzenli hem de daha kontrollü kullanabilirsiniz. Özellikle iş-kişisel ayrımı yapanlar ve cihazını zaman zaman paylaşmak zorunda kalanlar için, Android ekosisteminde uzun zamandır beklenen “pratik gizlilik” araçlarından biri olduğunu söylemek mümkün.

13 Ocak 2026 Salı

Windows 11’de WSL2 ile Docker Kurulumu: Yerel Geliştirmede Hızlı ve Temiz Bir Linux Ortamı

WSL2 + Docker neden bu kadar popüler?

Windows üzerinde yazılım geliştirirken bir yandan da “Linux gibi” çalışmak isteyenlerin sayısı arttı. Eskiden bunun için sanal makine kurmak, ayrı bir disk imajı yönetmek veya çift işletim sistemi kullanmak gerekiyordu. Windows 11 ile birlikte WSL2 (Windows Subsystem for Linux) olgunlaştı ve Docker’ı da bu altyapı üstünden kullanmak oldukça pratik hale geldi. Sonuç: daha az kaynak tüketen, daha hızlı açılan ve proje bağımlılıklarını daha tutarlı yöneten bir geliştirme ortamı.

Bu yazıda, Windows 11 üzerinde WSL2’yi etkinleştirip Ubuntu kuracak, ardından Docker’ı WSL2 motoruyla çalıştıracak şekilde yapılandıracağız. Amacımız “kuruluyor mu?” seviyesini geçip, günlük kullanımda sorun çıkaran detayları da doğru ayarlamak.

Ön koşullar ve kısa kontrol listesi

Başlamadan önce Windows 11’in güncel olduğundan emin olun. Ayrıca sisteminizde sanallaştırma (Virtualization) açık olmalı. Bunu görev yöneticisinde Performans > CPU bölümünde “Sanallaştırma: Etkin” şeklinde görebilirsiniz. Kapalıysa BIOS/UEFI üzerinden açmanız gerekebilir.

Kurulum için yönetici yetkisi olan bir Windows hesabı ve en az 8 GB RAM önerilir. Docker konteynerleri çalıştıracağımız için disk tarafında da rahat etmek adına en az 20 GB boş alan iyi olur.

1) WSL2’yi etkinleştirme ve Ubuntu kurulumu

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

wsl --install

Bu komut WSL bileşenlerini yükler, varsayılan Linux dağıtımını (genellikle Ubuntu) kurar ve gerekli özellikleri aktif eder. Kurulumdan sonra sistem yeniden başlatma isteyebilir.

Kurulum tamamlanınca Ubuntu ilk açılışta sizden bir kullanıcı adı ve parola belirlemenizi ister. Bu parola Windows parolanız değildir; Linux içi yönetici işlemlerinde kullanılacak.

WSL sürümünüzü kontrol etmek için şu komutu kullanın:

wsl -l -v

Burada Ubuntu’nun “Version” sütununda 2 görünmesini hedefliyoruz. Eğer 1 görünüyorsa şu komutla WSL2’ye çevirebilirsiniz:

wsl --set-version Ubuntu 2

2) Docker Desktop kurulumu ve WSL2 entegrasyonu

Docker’ı Windows üzerinde en sorunsuz şekilde kullanmanın yolu çoğu senaryoda Docker Desktop kurmaktır. Kurulum sırasında “Use WSL 2 instead of Hyper-V” benzeri bir seçenek görürseniz WSL2’yi tercih edin. Kurulum tamamlandıktan sonra Docker Desktop’ı açın.

Docker Desktop içinde Settings bölümüne girin ve şu kontrolleri yapın:

General altında WSL2 tabanlı motorun açık olduğundan emin olun.

Resources > WSL Integration altında Ubuntu dağıtımınız için entegrasyonu etkinleştirin. Burada sadece kurduğunuz dağıtımı seçmeniz yeterli.

Bu noktadan sonra Docker komutlarını doğrudan Ubuntu terminalinde kullanabilirsiniz. Ubuntu içinde doğrulamak için:

docker version

Eğer sürüm bilgileri geliyorsa entegrasyon tamamdır.

3) Hızlı test: Basit bir konteyner çalıştırma

Kurulumun sağlıklı olduğundan emin olmak için klasik test imajını çalıştırın:

docker run --rm hello-world

Bu komut imajı indirir ve bir mesaj basıp çıkar. “Hello from Docker!” benzeri bir çıktı görmeniz gerekir. Bu aşamada hata alırsanız, Docker Desktop’ın çalıştığını ve Ubuntu entegrasyonunun açık olduğunu yeniden kontrol edin.

4) Geliştiriciler için kritik ayarlar: Dosya sistemi ve performans

WSL2 ile Docker kullanırken performansı en çok etkileyen konu proje dosyalarının nerede durduğudur. En iyi performans için kodlarınızı Windows tarafındaki C:\ altında değil, Ubuntu’nun kendi dosya sistemi içinde tutun. Örneğin Ubuntu terminalinde bir proje klasörü oluşturup burada çalışmak genellikle daha akıcı olur:

mkdir -p ~/projelerim/ornek

Windows dosyalarına Ubuntu’dan /mnt/c üzerinden erişebilirsiniz; ancak çok sayıda küçük dosyaya sahip Node.js, PHP Composer veya Python paketlerinde bu yol daha yavaş hissedilebilir.

5) İleri seviye ipuçları: Kaynak yönetimi ve ağ davranışı

WSL2, Linux çekirdeğini hafif bir sanallaştırma katmanında çalıştırır ve RAM kullanımını dinamik yönetir. Yine de yoğun konteyner kullanımında kaynak sınırlarını ayarlamak isteyebilirsiniz. Bunun için Windows kullanıcı dizininizde .wslconfig dosyası oluşturup örneğin RAM ve CPU limitleri belirlemek mümkün olur. Bu sayede “Docker çalışınca bilgisayar yavaşlıyor” şikâyetlerini azaltabilirsiniz.

Ağ tarafında ise konteyner portlarını Windows’a yönlendirmek genelde sorunsuzdur. Örneğin bir web servisini 8080 portunda ayağa kaldırdıysanız tarayıcıdan http://localhost:8080 ile erişebilirsiniz. Kurumsal ağlarda VPN veya güvenlik yazılımları bazen yerel port erişiminde sorun çıkarabilir; böyle bir durumda Windows güvenlik duvarı ve VPN bölünmüş tünelleme ayarları kontrol edilmelidir.

Sonuç: Windows üzerinde “temiz” Linux geliştirme deneyimi

WSL2 ile Docker’ı bir araya getirdiğinizde, Windows’un konforundan vazgeçmeden Linux araç zincirini neredeyse yerel hızda kullanabilirsiniz. Üstelik proje bağımlılıklarını konteynerlere taşıyarak “bende çalışıyor” tartışmalarını ciddi ölçüde azaltırsınız. Doğru dosya konumlandırması, WSL entegrasyonu ve temel kaynak ayarlarıyla bu kurulum uzun süre sorunsuz şekilde günlük iş akışınıza hizmet eder.

12 Ocak 2026 Pazartesi

Cloudflare Workers ile Edge’de JSON API Oluşturma ve JWT Doğrulama (Adım Adım)

Edge tarafında API fikri neden bu kadar popüler?

Klasik yaklaşımda bir JSON API’yi bir sunucuda (VPS, container, PaaS) çalıştırır, ölçekleme ve gecikme sorunlarını ayrı ayrı yönetirsiniz. Cloudflare Workers ise kodunuzu kullanıcıya daha yakın “edge” noktalarında çalıştırarak düşük gecikme, otomatik ölçeklenme ve yönetim kolaylığı sunar. Bu yazıda, güncel ve ileri seviye bir senaryo olarak Cloudflare Workers ile minimal bir JSON API kuracak, ardından JWT doğrulama ekleyerek endpoint’leri koruma altına alacağız.

Ön koşullar

Bu öğretici için bir Cloudflare hesabı, Node.js (tercihen LTS) ve Cloudflare’ın CLI aracı Wrangler gerekli. Ayrıca JWT üretmek için bir kimlik sağlayıcı (Auth0, Firebase, Keycloak vb.) kullanabilirsiniz; ancak burada doğrulama kısmını Workers üzerinde ele alacağız. Amaç, “Authorization: Bearer ...” başlığıyla gelen token’ı doğrulayıp yetkisiz istekleri reddetmek.

1) Projeyi oluşturma (Wrangler)

Yerel ortamda yeni bir Worker projesi başlatın. Wrangler, TypeScript ve modern Worker runtime’ı ile hızlı bir iskelet oluşturur. Terminalde proje klasörünü oluşturduktan sonra geliştirme sunucusunu ayağa kaldırarak endpoint’leri test edebilirsiniz. Buradaki kritik nokta: Worker kodu Node.js sunucusu gibi “stateful” değildir; tasarımınızı stateless düşünmek daha doğru sonuç verir.

2) JSON API: Basit bir route yapısı

Workers ortamında istekleri fetch handler’ı ile karşılarız. Birkaç route ile başlayalım: /health (servis kontrolü), /api/profile (JWT gerektiren örnek endpoint). Aşağıdaki örnek, JSON cevapları standartlaştırmak için küçük yardımcı fonksiyonlar kullanır.

Örnek Worker kodu (TypeScript mantığı):

Not: Kod örneğini kendi projenize göre uyarlayın; özellikle JWT doğrulama için kullanacağınız public key veya JWKS adresi değişecektir.

Route mantığı: /health herkese açık, /api/profile ise Bearer token ister. Token doğrulanırsa örnek bir profil JSON’u döner.

3) JWT doğrulama: HS256 yerine RS256/JWKS yaklaşımı

Güncel pratikte JWT doğrulamada iki ana yol var: paylaşılan gizli anahtar (HS256) veya asimetrik anahtar (RS256/ES256). Üretim ortamında, özellikle üçüncü parti kimlik sağlayıcıları ile, JWKS (JSON Web Key Set) üzerinden public key çekip doğrulama yapmak daha sürdürülebilir bir yöntemdir. Böylece anahtar rotasyonu kimlik sağlayıcı tarafında yönetilir ve Worker sadece güncel anahtarı kullanır.

Workers içinde JWKS kullanırken iki konu önem kazanır: cache ve performans. Her istekte JWKS çekmek gecikmeyi artırır. Bu yüzden JWKS yanıtını belirli bir süre cache’lemek gerekir. Cloudflare Workers, Cache API ile bu işi oldukça pratik hale getirir. Alternatif olarak KV ya da D1 gibi çözümler de kullanılabilir, fakat JWKS için Cache API genellikle yeterlidir.

4) Güvenlik kontrol listesi (pratik öneriler)

Audience (aud) ve issuer (iss) doğrulaması yapın. Sadece imza doğrulamak yetmez; token’ın kimin için üretildiğini ve hangi otorite tarafından imzalandığını da kontrol etmek gerekir. Ayrıca token süresi için exp kontrolü zorunludur. Saat kayması ihtimaline karşı küçük bir tolerans (clock skew) eklemek sahada hataları azaltır.

CORS konusu da sık atlanır. API’niz tarayıcıdan çağrılacaksa doğru origin’leri whitelist ederek “*” kullanımını sınırlayın. Workers, preflight (OPTIONS) isteklerini yönetmek için idealdir. Ek olarak rate limit için Cloudflare’ın WAF ve Rate Limiting özellikleri veya uygulama seviyesinde basit limit mekanizmaları kullanılabilir.

5) Deploy ve test

Geliştirme tamamlanınca Wrangler ile deploy alırsınız. Ardından uç noktaları curl veya Postman ile test edin. İlk test olarak /health çağrısının 200 dönmesi beklenir. Sonra /api/profile’a token olmadan istek atarak 401 aldığınızı doğrulayın. Son adımda geçerli bir JWT ile çağrı yapıp JSON yanıtı alın. Hata durumlarında özellikle Authorization header formatı (Bearer boşluk) ve token’ın doğru issuer/audience değerleri kontrol edilmelidir.

Sık karşılaşılan hatalar ve çözüm ipuçları

“Invalid signature”: Yanlış public key, yanlış JWKS endpoint’i veya token’ın farklı bir kid ile imzalanması. JWKS’ten doğru anahtarı seçtiğinizden emin olun. “Token expired”: exp geçmiş olabilir; sistem saatini ve clock skew toleransını gözden geçirin. CORS hataları: OPTIONS isteklerine 200 dönmeyi ve gerekli Access-Control-Allow-* başlıklarını eklemeyi unutmayın.

Sonuç: Neyi kazandınız?

Bu rehberle Cloudflare Workers üzerinde edge’de çalışan, gecikmesi düşük ve otomatik ölçeklenen bir JSON API kurmanın mantığını kurdunuz. Üstüne JWT doğrulama ekleyerek gerçek hayattaki “korumalı endpoint” ihtiyacını da çözdünüz. Buradan sonra loglama için Workers Analytics, veri katmanı için D1/KV, daha gelişmiş yetkilendirme için role-based kontrol ve rate limiting gibi adımlarla mimariyi büyütebilirsiniz.

11 Ocak 2026 Pazar

Docker Compose ile Yerel LLM (Ollama) Kurulumu ve Open WebUI Üzerinden ChatGPT Benzeri Arayüz

Yerelde LLM Çalıştırmak Neden Gündemde?

Bulut tabanlı yapay zekâ servisleri pratik olsa da, veri gizliliği, maliyet ve gecikme (latency) gibi konular birçok kişiyi yerel (local) çözümlere yönlendiriyor. Son dönemde öne çıkan yaklaşımlardan biri, LLM modellerini bilgisayarında veya ev sunucunda çalıştırıp, web arayüzü üzerinden sohbet edebilmek. Bu yazıda, Ollama ile yerel model çalıştırmayı ve Open WebUI ile tarayıcıdan kullanmayı Docker Compose üzerinden adım adım kuracağız. Hedefimiz: birkaç komutla, sürdürülebilir ve güncellenebilir bir kurulum yapmak.

Ön Koşullar ve Sistem Notları

Kurulum Linux tabanlı bir sistemde (Ubuntu/Debian gibi) en sorunsuz şekilde ilerler. macOS ve Windows üzerinde de Docker ile yapılabilir; ancak GPU kullanımı (özellikle NVIDIA) için Linux tarafı daha stabil. Minimumda 8 GB RAM ile küçük modeller çalıştırılabilir; 16 GB ve üzeri daha rahat olur. GPU’nuz varsa performans belirgin şekilde artar. Gerekenler: Docker, Docker Compose ve internete erişim (modeli ilk kez indirirken).

Mimari: Ollama + Open WebUI Nasıl Çalışır?

Ollama, LLM modellerini indirip yerelde servis eden bir katman gibi düşünülebilir. Siz “modeli indir, çalıştır” dersiniz; o da arka tarafta bir API üzerinden yanıt üretir. Open WebUI ise bu API’ye bağlanan modern bir web arayüzüdür. Böylece tarayıcıdan sohbet edebilir, model seçebilir, geçmiş konuşmaları saklayabilir ve temel ayarları yönetebilirsiniz. İkisini Docker Compose ile yönetmek, güncelleme ve taşınabilirlik açısından büyük kolaylık sağlar.

Adım 1: Docker Compose Dosyasını Oluşturma

Önce bir klasör açın ve içine docker-compose.yml dosyası oluşturun. Örnek içerik aşağıdaki gibi olabilir. Bu yapı iki servisi çalıştırır: Ollama ve Open WebUI. Open WebUI, Ollama’nın API’sine bağlanır ve 3000 portundan yayın yapar.

docker-compose.yml:

version: "3.8"
services:
  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    restart: unless-stopped
    ports:
      - "11434:11434"
    volumes:
      - ollama:/root/.ollama

  openwebui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: openwebui
    restart: unless-stopped
    ports:
      - "3000:8080"
    environment:
      - OLLAMA_BASE_URL=http://ollama:11434
    depends_on:
      - ollama
    volumes:
      - openwebui:/app/backend/data

volumes:
  ollama:
  openwebui:

Not: Bu örnek temel kurulumdur. NVIDIA GPU ile hızlandırma isterseniz Docker’ın GPU runtime ayarlarını ayrıca yapılandırmanız gerekebilir. CPU ile de çalışır; sadece daha yavaş yanıt alırsınız.

Adım 2: Servisleri Ayağa Kaldırma

Compose dosyasının bulunduğu klasörde şu komutu çalıştırın:

docker compose up -d

Ardından konteynerlerin durumunu kontrol edin:

docker ps

Her şey yolundaysa tarayıcıdan http://localhost:3000 adresine gidin. İlk açılışta Open WebUI sizden bir kullanıcı oluşturmanızı isteyebilir; bu normaldir.

Adım 3: Model İndirme ve İlk Çalıştırma

Ollama tarafında bir model indirmek için iki yol var: Open WebUI içinden model çekmek veya terminalden indirmek. Terminal üzerinden daha kontrol edilebilir olduğu için şu komutla başlayabilirsiniz:

docker exec -it ollama ollama pull llama3.1

Model adı zamanla değişebilir; Ollama’nın desteklediği güncel isimleri kontrol etmek gerekebilir. İndirme bittiğinde Open WebUI’ye dönün. Model seçimi bölümünde indirdiğiniz modeli görüp sohbet başlatabilirsiniz. İlk yanıtlar biraz yavaş gelebilir; modelin “ısınması” ve CPU/GPU durumuna göre performans değişir.

İpuçları: Performans, Depolama ve Güvenlik

Depolama: Modeller büyük yer kaplar. Compose dosyasında tanımlı volume’lar sayesinde konteyner silinse bile modelleriniz kalır. Disk alanınızı izlemek için düzenli kontrol edin.

Performans: Daha küçük bir model seçmek (ör. daha düşük parametreli sürümler) yanıt süresini ciddi biçimde iyileştirir. Ayrıca aynı anda çok uzun bağlam (context) kullanmak RAM tüketimini artırır.

Güvenlik: Kurulumu ev ağı dışına açacaksanız (port yönlendirme gibi), mutlaka ters proxy + HTTPS ve kimlik doğrulama kullanın. Varsayılan şekilde yerelde kullanmak daha güvenlidir.

Sık Karşılaşılan Sorunlar

Open WebUI model görmüyor: OLLAMA_BASE_URL değişkeninin doğru olduğundan emin olun. Compose içinde servis adı “ollama” ise URL de “http://ollama:11434” olmalı. Ayrıca konteynerlerin aynı network’te olması gerekir; Compose bunu varsayılan olarak sağlar.

Yanıtlar çok yavaş: CPU ile çalışıyorsanız bu normal olabilir. Daha küçük model deneyin, arka planda çalışan uygulamaları azaltın. GPU kurulumuna geçmek ciddi fark yaratır.

Port çakışması: 3000 veya 11434 portu başka bir uygulama tarafından kullanılıyorsa, compose dosyasında sol taraftaki portu değiştirin (ör. “3001:8080”).

Sonuç

Docker Compose ile Ollama ve Open WebUI kurmak, yerel LLM dünyasına hızlı bir giriş sunuyor. Kurulum hem taşınabilir hem de güncellemesi kolay: yeni sürümler için genellikle docker compose pull ve docker compose up -d yeterli. En önemlisi, sohbet veriniz ve model kullanımı sizin kontrolünüzde kalıyor. Eğer hedefiniz gizlilik odaklı bir “yerel yapay zekâ asistanı” ise bu ikili, güncel ve pratik bir başlangıç noktası.

10 Ocak 2026 Cumartesi

Docker’da Rootless Mod ile Güvenli Konteyner Çalıştırma: Adım Adım Kurulum ve İpuçları

Rootless Docker Nedir ve Neden Önemlidir?

Konteyner teknolojileri üretim ortamlarında standart hâline gelirken, güvenlik tarafında hâlâ sık yapılan bir hata var: Docker’ı kök kullanıcı (root) yetkileriyle çalıştırmak. Varsayılan Docker kurulumunda dockerd servisi root ayrıcalıklarıyla çalışır ve Docker grubuna eklediğiniz kullanıcılar fiilen root’a yakın yetkiler kazanır. Bu, yanlış yapılandırılmış bir konteyner veya zayıf bir imaj üzerinden sistemin tamamına sıçrama riskini artırır.

İşte burada Rootless Docker devreye girer. Rootless mod, Docker daemon’ını ve konteynerleri root olmadan çalıştırır. Böylece olası bir güvenlik açığında saldırganın erişimi kullanıcı alanıyla sınırlı kalır. Özellikle çok kullanıcılı sunucularda, CI/CD ajanlarında veya geliştiricilerin kendi makinelerinde güvenliği artırmak için oldukça iyi bir yaklaşımdır.

Kimler Rootless Docker Kullanmalı?

Rootless mod her senaryoya birebir uymaz; ancak pek çok kullanımda ciddi avantaj sağlar. Paylaşımlı geliştirme sunucuları, kurumsal dizüstüler, “konteyner çalıştırıyorum ama root yetkisi istemiyorum” yaklaşımı olan ekipler ve saldırı yüzeyini küçültmek isteyenler için idealdir. Öte yandan bazı ağ senaryolarında (örneğin düşük portlara doğrudan bind etmek) ekstra ayar gerekir. Bu yazıda temel kurulumun yanında pratik kısıtları ve çözüm yollarını da ele alacağım.

Ön Koşullar (Linux)

Rootless Docker en sorunsuz şekilde modern Linux dağıtımlarında çalışır. Bu rehberde Ubuntu/Debian çizgisini baz alıyorum; ancak Fedora/Arch tarafında da mantık aynı. Gerekli olanlar: güncel bir Docker kurulumu, kullanıcı bazlı servisleri yönetmek için systemd (çoğu dağıtımda var) ve kullanıcı namespace’lerinin düzgün ayarlanması.

Öncelikle Docker’ın kurulu olduğunu doğrulayın. Kurulu değilse dağıtımınızın resmi yönergelerini izleyin. Rootless mod için ayrıca Docker’ın sunduğu kurulum betiğini kullanacağız.

Adım Adım Rootless Docker Kurulumu

1) Kullanıcı namespace eşlemelerini kontrol edin
Rootless çalışabilmek için sistemde subuid ve subgid atamaları gerekir. Çoğu sistemde otomatik gelir; ancak kontrol etmekte fayda var. Aşağıdaki dosyalarda kullanıcı adınıza ait satır olmalı:

/etc/subuid ve /etc/subgid içinde kullanıcı adınızın karşısında bir aralık görmelisiniz (ör. kullanici:100000:65536). Yoksa yönetici yetkisiyle bu aralığı tanımlamak gerekir.

2) Rootless kurulum betiğini çalıştırın
Docker, rootless kurulumu kolaylaştıran bir betik sunar. Terminalde kendi kullanıcınızla şu komutu çalıştırın:

dockerd-rootless-setuptool.sh install

Kurulum sonunda size iki kritik bilgi verir: Docker soketinin yolu ve ortam değişkenleri. Genellikle DOCKER_HOST için kullanıcı dizini altında bir socket yolu tanımlanır.

3) Ortam değişkenlerini kalıcı hâle getirin
Terminal her açıldığında rootless daemon’a bağlanmak için genelde şu satır gerekir:

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

Kendi kullanıcı ID’nize göre yol değişebilir. Bunu ~/.bashrc veya ~/.zshrc dosyanıza ekleyin. Ardından yeni bir terminal açıp docker ps ile test edin.

4) Servisi kullanıcı olarak başlatın
Systemd kullanan sistemlerde rootless Docker genellikle kullanıcı servisi olarak yönetilir. Kurulum betiği çoğu zaman bunu ayarlar. Elle kontrol etmek isterseniz:

systemctl --user status docker

Servis aktif değilse başlatıp etkinleştirebilirsiniz:

systemctl --user enable --now docker

Sık Karşılaşılan Kısıtlar ve Pratik Çözümler

1) 1024 altı portlara bind etme
Rootless modda düşük portlara (80, 443 gibi) doğrudan bind etmek kısıtlıdır. Çözüm olarak 8080/8443 gibi yüksek portları kullanabilir, ters vekil (reverse proxy) ile yönlendirebilir veya sistemde ilgili capability ayarlarıyla çalışabilirsiniz. Üretimde en temiz yaklaşım genellikle Nginx/Traefik gibi bir ters vekilin 80/443’ü dinlemesi ve konteynerlere yüksek porttan trafik iletmesidir.

2) Ağ performansı ve uyumluluk
Rootless, ağ tarafında çoğunlukla kullanıcı alanı çözümlerine dayanır. Bu, bazı ortamlarda küçük bir performans maliyeti veya farklı davranışlar doğurabilir. Ancak geliştirici makinelerinde ve birçok CI işinde bu fark pratikte sorun yaratmaz.

3) Dosya izinleri ve bind mount
Konteyner içine bağladığınız (bind mount) dizinlerde izin problemleri görebilirsiniz. Rootless mod, host tarafındaki kullanıcı izinleriyle daha “doğal” çalışır; yine de UID/GID uyumsuzluğu olan imajlarda ek ayar gerekebilir. Bu noktada user direktifini kullanmak, uygulamayı konteyner içinde root yerine belirli bir kullanıcıyla çalıştırmak ve volume izinlerini netleştirmek işleri kolaylaştırır.

Güvenlik İçin Ek İpuçları

Rootless kullanıyor olsanız bile güvenlik katmanlarını çoğaltmak iyi bir alışkanlıktır. İmajları mümkünse resmi kaynaklardan çekin, gereksiz paketleri içermeyen minimal imajları tercih edin, gizli anahtarları imaj içine gömmeyin. Konteyner çalıştırırken read-only dosya sistemi, sınırlı yetkiler ve kaynak kotaları gibi seçenekler de saldırı yüzeyini küçültür.

Son olarak, rootless Docker’ı “tek başına her şeyi çözen” bir sihir gibi görmek yerine, doğru senaryoda güçlü bir güvenlik hamlesi olarak değerlendirin. Özellikle paylaşımlı sistemlerde, geliştirici ortamlarında ve otomasyon sunucularında rootless yaklaşımı çoğu zaman daha rahat uyumanızı sağlar.

Sonuç

Rootless Docker, konteyner ekosisteminde güvenliği pratik biçimde artıran modern bir yöntem. Kurulumu birkaç adımda tamamlanıyor; en önemli nokta kullanıcı namespace eşlemeleri ve doğru DOCKER_HOST ayarı. Eğer bugüne kadar Docker’ı “Docker grubuna al, tamam” mantığıyla kullanıyorsanız, rootless moda geçmek özellikle güvenlik hassasiyeti olan ortamlarda ciddi bir iyileştirme sunar.