11 Şubat 2026 Çarşamba

Federated Learning ile Merkezsiz Makine Öğrenimi: Gönül Rahatlığıyla Veri Paylaşımı

Dijital dönüştürümün hızla ilerlediği günümüzde, gizliliği korurken veri analizi yapmanın yolları kritik öneme sahip. Federated Learning, bu dengeyi sağlayan革新 bir teknolojik yaklaşımdır. Bu makalede, Federated Learning konseptinin mantığı, uygulama adımları ve avantajları teknik detaylarıyla ele alınacak.

Amaç

Geleneksel makine öğrenimi projelerinde veri merkezî bir sunucuya toplanır. Bu yöntem, gizliliğe duyarlı alanlarda (sağlık, finans) ciddi riskler doğurur. Federated Learning, model eğitimi sırasında verilerin orijinal konumunda kalarak sadece model parametrelerinin paylaşılması prensibiyle, veri gizliliği ve performans arasındaki çelişkiyi çözüme kavuşturur. Bu makalenin amacı, bu teknolojinin teknik altyapısını adım adım açıklamaktır.

Federated Learning Nedir?

Federated Learning, veri merkezliliği yerine model merkezliliği yaklaşımını benimser. Kullanıcı cihazları (telefon, sensör) lokal veriler üzerinden bir model eğitirken, bu modelin ağırlıkları merkezi sunucuya gönderilir. Sunucu, gelen ağırlıkları ortalama alarak global modeli güçlendirir. Bu döngü, veri asla merkezden ayrılmadan gerçekleşir.

Ön Koşullar

Federated Learning projelerine başlamadan aşağıdaki araçlar ve bilgiler gereklidir:

  • Python 3.8+: TensorFlow Federated kütüphanesi Python 3.8 veya üstü ile çalışır.
  • TensorFlow Federated (TFF): Open-source kütüphane, Federated Learning algoritmaları için temeldir.
  • Jupyter Notebook: Deneylerinizi etkileşimli ortamda test edebilirsiniz.
  • Temel Makine Öğrenimi Bilgisi: Doğrusal regresyon ve sinir ağları algoritmaları için temel anlayış yeterlidir.

Adım Adım Federated Learning Uygulaması

Adım 1: Ortam Kurulumu

Python ortamını hazırlayarak gerekli kütüphaneleri yükleyin:

  
pip install tensorflow_federated  
pip install numpy jupyter  

Adım 2: Örnek Veri Seti Oluşturma

TFF'nin dahili veri setlerinden EMNIST (el yazısı rakam ve harf) kullanarak cihazları simüle edin:

  
import tensorflow_federated as tff  
emnist_train, emnist_test = tff.simulation.datasets.emnist.load_data()  

Adım 3: Veri Dağılımı

Her cihazın veri setini birleştirmek yerine, veri parçalama süreci başlatın:

  
def preprocess(dataset):  
    return dataset.batch(20).shuffle(100)  
train_data = emnist_train.preprocess(preprocess)  

Adım 4: Model Tanımı

Basit bir sinir ağı modeli oluşturun. Ağırlıklar, cihazlar arasında paylaşılmak üzere tanımlanır:

  
def create_keras_model():  
    model = tf.keras.Sequential([...])  # 1. katman: Dense, 2. katman: Output  
    return model  

Adım 5: Federated Eğitim Döngüsü

TFF'nin federated_averaging algoritmasıyla eğitim döngüsünü başlatın:

  
fed_avg = tff.learning.build_federated_averaging_process(model_fn)  
state = fed_avg.initialize()  
for round_num in range(1, 10):  
    state, metrics = fed_avg.next(state, train_data)  

Adım 6: Model Değerlendirme

Test veri setiyle global modelin performansını değerlendirin:

  
test_data = emnist_test.preprocess(preprocess)  
test_metrics = fed_avg.test(state, test_data)  

Zorluklar ve Çözümler

Federated Learning, veri dağılımı çelişkileri (non-IID) ve cihaz kayıpları gibi zorluklarla karşılaşabilir. Bu sorunlara çözüm için:

  • Adaptif öğrenme oranları (adaptive learning rates) kullanın.
  • Cihazlara otomatik yeniden eşleme algoritmaları entegre edin.
  • Özelleştirilmiş veri önişleme (data augmentation) teknikleri uygulayın.

Sonuç

Federated Learning, veri gizliliği ve makine öğrenimi performansı arasında kritik bir denge kurar. TensorFlow Federated gibi araçlarla, cihazlar merkezdeki gizlilik riskinden uzak kalmakla kalmaz, aynı zamanda daha etkili modeller üretir. Bu teknoloji, sağlık, finans ve akıllı şehir uygulamalarında büyük potansiyeller sunar. Gelecekte, şifreli Federated Learning ve edge computing ile entegrasyonu daha da öne çıkacak. Teknik detayların adım adım incelenmesi, bu alanda uzmanlaşmanın ilk kademeleridir.

Otomatik Docker Container Deployment: Ansible ile DevOps Otomasyonu Kılavuzu

Otomatik Docker Container Deployment: Ansible ile DevOps Otomasyonu

Docker ve DevOps ekosisteminin merkezinde yer alan otomasyon, modern yazılım geliştirme süreçlerini hızlandırır. Ancak, manuel Docker container dağıtımına zaman kaybetmeden, Ansible gibi orkestrasyon araçlarıyla bu süreci otomatikleştirmek, hem hata payını azaltır hem de tekrar tekrar aynı görevleri yapmaya gerek kalmaz. Bu kılavuzda, Docker konteynerlerini Ansible kullanarak nasıl otomatik dağıtabileceğinizi adım adım anlatacağım.

Amaç

DevOps Otomasyonunun Neden Kritik

Docker konteynerleri dağıtım süreçlerini standartlaştırırken, manuel müdahaleler her seferinde hata riskini artırır. Ansible ile Docker deployment sürecini otomatik hale getirerek;

  • İkili dağıtım (binary deployment) süreçlerini hızlandırabilirsiniz.
  • Konteyner güncellemelerini tek bir komutla yönetebilirsiniz.
  • Çoklu sunuculara paralel otomatik dağıtım yapabilirsiniz.

Ön Koşullar

Aşağıdaki araçların veya bilgilerin hazır olduğundan emin olun:

  • Linux/Unix tabanlı sistem (örnek: Ubuntu 22.04)
  • Docker kurulmuş olmalıdır (sudo apt install docker.io)
  • Ansible kurulmuş olmalıdır (sudo apt install ansible)
  • YAML ve Dockerfile temeli bilgisi

Adım Adım Anlatım

Adım 1: Dockerfile Oluşturma

Öncelikle bir Docker image oluşturmak için Dockerfile yaratalım. Aşağıdaki örnekte, Python uygulaması içeren bir konteyner image’ı tanımladık:

FROM python:3.9-slim  
WORKDIR /app  
COPY . /app  
RUN pip install -r requirements.txt  
CMD ["python", "app.py"]  

Adım 2: Ansible Playbook Oluşturun

Ansible, playbook.yml dosyası üzerinden görevleri tanımlar. Aşağıdaki playbook, Dockerfile’ı derler, image’ı çalıştırır ve konteyneri başlatır:

- hosts: all  
  become: yes  
  tasks:  
    - name: Dockerfile'dan image derle  
      docker_image:  
        path: ./docker-repo  
        name: my-python-app  
        source: build  
    - name: Konteyner başlat  
      docker_container:  
        name: my-container  
        image: my-python-app:latest  
        state: started  
        ports:  
          - "5000:5000"  

Adım 3: Inventory Dosyası Ayarlayın

Ansible, inventory dosyası üzerinden hedef sunucuları tanımlar. Örneğin, hosts dosyanızda:

[docker_servers]  
192.168.1.10  
192.168.1.11  

Adım 4: Playbook'u Çalıştırın

Aşağıdaki komutla playbook’u çalıştırın:

ansible-playbook -i hosts playbook.yml  

Bu komut, listedeki tüm sunucularda Docker konteynerlerini otomatik olarak dağıtır.

Geliştirme Tavsiyeleri

Ekstra: CI/CD Entegrasyonu

Bu playbook’u Github Actions veya Jenkins ile entegre ederek, her kod değişikliğinde otomatik deployment sağlayabilirsiniz.

Sonuç

Bu kılavuzda, Ansible ile Docker konteyner dağıtımını nasıl otomatikleştireceğinizi öğrendik. Docker ve Ansible’nin birleşimi, DevOps süreçlerinde hem hız kazandırır hem de hata payını minimize eder. Bu yöntemi bir sonraki adım olarak, kubernetes veya OpenShift gibi container orchestrators ile genişletebilirsiniz. Unutmayın: Otomasyon, sadece kodlama değil, yazılım yaşam döngüsünün her aşamasını dönüştürür.

Referanslar

Windows 11’de WSL2 ile Docker’sız Dev Ortamı: Podman ile Rootless Container Kurulumu ve İpuçları

Windows 11’de “Docker kurmadan container” mümkün mü?

Windows 11 üzerinde container tabanlı bir geliştirme ortamı kurmak isteyenlerin ilk aklına gelen seçenek çoğunlukla Docker Desktop oluyor. Ancak lisanslama, kaynak tüketimi ve arka planda çalışan servisler nedeniyle daha hafif ve kontrol edilebilir bir alternatif arıyorsanız, WSL2 + Podman (rootless) ikilisi oldukça güçlü bir çözüm sunuyor. Bu yazıda, Docker Desktop kurmadan Podman ile Linux container’larını WSL2 içinde nasıl çalıştıracağınızı ve günlük geliştirmede işinizi kolaylaştıracak pratik ayarları adım adım anlatıyorum.

Ön gereksinimler

Kuruluma başlamadan önce aşağıdakiler hazır olmalı: Windows 11, etkinleştirilmiş WSL2, bir Linux dağıtımı (ör. Ubuntu 22.04/24.04) ve Windows Terminal. WSL2 kurulu değilse PowerShell’i yönetici olarak açıp wsl --install komutunu çalıştırabilir, ardından sistemi yeniden başlatabilirsiniz. Zaten WSL kuruluysa sürümü doğrulamak için wsl -l -v komutu yeterlidir; dağıtımınızın VERSION sütununda 2 yazmalıdır.

1) WSL2 içinde Podman kurulumu

Ubuntu kullanıyorsanız Podman kurulumu oldukça düz: Terminalde WSL dağıtımınıza girin ve paketleri güncelleyin: sudo apt update. Ardından Podman’ı kurun: sudo apt install -y podman. Bu noktada Podman, Docker gibi daemon’a bağımlı olmadığı için daha sade bir mimariyle gelir. Yani arka planda sürekli çalışan bir servis zorunlu değildir; komutu verdiğinizde çalışır, işiniz bittiğinde kapanır.

2) Rootless (yetkisiz) container mantığı

Podman’ın en sevilen taraflarından biri rootless çalışmayı birinci sınıf desteklemesidir. Rootless, container’ları sistemde root yetkisi olmadan, kendi kullanıcı hesabınızla çalıştırmanız demektir. Bu, hem güvenlik açısından hem de “makinemi bozar mı?” kaygısını azaltma açısından ciddi avantaj sağlar. Rootless modda bazı ağ özellikleri veya port bağlama detayları farklılık gösterebilir; birazdan bunları pratik şekilde ele alacağız.

3) Podman ile ilk container’ı çalıştırma

Kurulumdan sonra hızlı bir test yapın. Örneğin Alpine imajını çekip bir komut çalıştırabilirsiniz: podman run --rm alpine:latest echo "Merhaba Podman". Her şey doğruysa Podman imajı indirecek ve çıktıyı göreceksiniz. Ardından mevcut imajları listelemek için podman images, çalışan container’ları görmek için podman ps komutları kullanılabilir.

4) Port yönlendirme ve web uygulaması örneği

Bir web uygulamasını ayağa kaldırmak için Nginx iyi bir örnektir. Aşağıdaki komut Nginx’i 8080 portuna bağlar: podman run --rm -p 8080:80 docker.io/library/nginx:alpine. Sonrasında Windows tarafında tarayıcıdan http://localhost:8080 adresine gittiğinizde Nginx karşılama sayfasını görmelisiniz. WSL2 ağ mimarisi çoğu durumda bunu sorunsuz taşır; ancak şirket VPN’i, güvenlik yazılımları veya özel firewall kuralları bazen localhost erişimini etkileyebilir. Bu durumda ilk kontrol edilecek yer Windows güvenlik duvarı ve WSL ağ ayarlarıdır.

5) Docker CLI alışkanlığını bırakmadan: podman-docker

Eğer yıllardır “docker run”, “docker compose” refleksiyle çalışıyorsanız Podman’a geçişi yumuşatmak için podman-docker paketi işinize yarar. Ubuntu’da çoğu sürümde şu şekilde yüklenebilir: sudo apt install -y podman-docker. Bu paket, “docker” komutunu Podman’a yönlendiren bir uyumluluk katmanı sağlar. Böylece birçok script ve dokümantasyon neredeyse değişmeden çalışır. Yine de üretim kalitesinde akışlarda komutları Podman’a göre netleştirmenizi öneririm.

6) Compose benzeri kullanım: Podman Compose veya Quadlet

Çoklu servis kurulumlarında Docker Compose benzeri bir deneyim için iki seçenek öne çıkıyor: podman-compose ve systemd tabanlı Quadlet. Basit senaryolarda sudo apt install -y podman-compose ile başlayabilirsiniz. Mevcut docker-compose.yml dosyalarınızın önemli bir kısmı çalışır; ancak network isimleri, volume izinleri ve bazı sürüme özel direktiflerde küçük uyarlamalar gerekebilir. Daha “kalıcı servis” yaklaşımı istiyorsanız Quadlet ile container’ları systemd birimleri gibi yönetmek, WSL içinde bile daha düzenli bir yapı sağlayabilir.

7) Volume, dosya izinleri ve performans notları

WSL2’de performansın kritik noktası genellikle dosya sistemi seçimidir. Proje dosyalarınızı WSL Linux dosya sistemi içinde (ör. /home/kullanici/proje) tutmak, Windows dosya sistemi altındaki /mnt/c yollarına göre çoğu zaman daha hızlıdır. Rootless container’larda volume bağlarken izin sorunları yaşarsanız, bağladığınız dizinlerin sahipliğini ve izinlerini kontrol edin. Özellikle Node.js gibi çok dosyalı projelerde, kaynak kodu Linux tarafında tutup editor olarak VS Code’un WSL eklentisini kullanmak hem stabil hem hızlı bir deneyim verir.

Sonuç: Hafif, güvenli ve kontrol edilebilir bir container deneyimi

WSL2 üzerinde Podman ile rootless container çalıştırmak, Windows 11’de modern geliştirme akışları için oldukça güncel ve ileri seviye bir alternatif sunuyor. Docker Desktop’a bağımlı kalmadan, daha az servisle daha fazla kontrol elde ediyorsunuz. Üstelik Podman’ın daemon’sız yaklaşımı ve rootless modeli, güvenlik ve kaynak kullanımı açısından da avantajlı. Eğer hedefiniz “Windows üzerinde Linux container geliştirme” ise bu kurulum, günlük iş akışınıza hızlıca entegre olabilecek pratik bir temel sağlar.

10 Şubat 2026 Salı

Docker ile Lokal Geliştirmede Gelişmiş Hızlandırma: BuildKit, Cache ve Multi-Stage Build Rehberi

Docker ile “Neden Bu Kadar Yavaş?” Sorununu Kökten Çözmek

Docker kullanarak geliştirme yapmak artık standart hâline geldi; ancak birçok ekip, konteyner imajı alırken “her seferinde her şeyi baştan indiriyor” hissiyle boğuşuyor. Özellikle Node.js, Python, Go veya Java tabanlı projelerde bağımlılıkların kurulumu ve katmanların tekrar tekrar oluşması, CI süreçlerini ve yerel geliştirmeyi ciddi biçimde yavaşlatabiliyor. Bu yazıda, Docker’ın modern derleme altyapısı olan BuildKit ile daha hızlı build alma, doğru cache stratejisi kurma ve multi-stage derlemelerle daha küçük imaj üretme konusunu ileri seviye ama uygulanabilir bir şekilde ele alacağım.

1) BuildKit Nedir ve Neden Önemli?

BuildKit, Docker build sürecini daha akıllı hâle getiren yeni nesil derleme motorudur. Paralel adım çalıştırma, gelişmiş cache yönetimi ve “secret” gibi güvenlik odaklı özellikler sunar. En önemli etkisi, doğru yazılmış bir Dockerfile ile build sürelerini gözle görülür şekilde azaltmasıdır. Ayrıca BuildKit, “cache’i dışarı aktar, başka makinede kullan” gibi senaryolara da kapı açar; bu da özellikle CI/CD ortamlarında altın değerindedir.

BuildKit’i etkinleştirmek için genellikle ekstra kurulum gerekmez. Terminalde tek seferlik şu şekilde kullanabilirsiniz: DOCKER_BUILDKIT=1 docker build .. Docker Desktop kullananlarda çoğu zaman varsayılan olarak açıktır. BuildKit ile birlikte buildx komutu da devreye girer ve cache ihracı/ithali gibi gelişmiş işlevler pratikleşir.

2) Dockerfile’da Katman Mantığını Doğru Kullanmak

Docker build hızının temelinde katman (layer) cache’i vardır. Basit kural şudur: Sık değişen dosyaları (uygulama kodu) daha sona, nadir değişenleri (bağımlılık tanımları) daha başa koyun. Örneğin Node.js için package.json ve package-lock.json dosyaları bağımlılık değişmediği sürece sabit kalır. Bu dosyaları önce kopyalayıp bağımlılıkları kurarsanız, uygulama kodu değişse bile bağımlılık katmanı cache’ten gelir.

Örnek mantık: Önce COPY package*.json, sonra RUN npm ci, en son COPY . .. Python tarafında benzer şekilde requirements.txt önce kopyalanır, pip install sonra çalışır. Bu yaklaşım “her değişiklikte yeniden bağımlılık kurma” hatasını ortadan kaldırır.

3) BuildKit Cache Mount ile Bağımlılık Kurulumunu Hızlandırmak

BuildKit’in en güçlü taraflarından biri, belirli dizinleri build sırasında cache olarak bağlayabilmesidir. Böylece paket yöneticileri (npm, pip, apt) her seferinde internetten indirmek yerine yerel/BuildKit cache’inden yararlanır. Bu özellik klasik layer cache’inden farklıdır; layer bozulsa bile cache mount sayesinde indirme havuzu korunabilir.

Örneğin Debian/Ubuntu tabanlı imajlarda apt için: RUN --mount=type=cache,target=/var/cache/apt gibi bir yaklaşım mümkündür. Node.js için npm cache dizinini, Python için pip cache dizinini cache mount ile tanımlamak özellikle CI’da büyük hız kazandırır. Buradaki kritik nokta, bu yöntemin BuildKit gerektirmesidir; yani eski “docker build” davranışına göre daha moderndir.

4) Multi-Stage Build ile Küçük ve Güvenli İmaj

Performans sadece build süresi değildir; imaj boyutu ve saldırı yüzeyi de önemlidir. Multi-stage build yaklaşımıyla, derleme için gereken araçları (ör. derleyiciler, dev bağımlılıklar) bir “builder” aşamasında tutup, çalıştırma aşamasına sadece gerekli çıktıları taşıyabilirsiniz. Bu sayede imaj küçülür, deploy hızlanır, container açılış süreleri kısalır ve olası güvenlik açıkları azalır.

Örneğin Go projelerinde ilk aşamada binary derlenir, ikinci aşamada ise “scratch” veya minimal bir base imaj üzerinde yalnızca binary çalıştırılır. Node.js tarafında ise build aşamasında webpack/tsc gibi araçlar kullanılırken, runtime aşamasında sadece derlenmiş çıktı ve üretim bağımlılıkları tutulur. Bu ayrım, üretim ortamında “devDependencies” taşıma hatasını da engeller.

5) .dockerignore: Sessiz Kahraman

Bir başka sık yapılan hata, build context’in gereksiz şişmesidir. Docker, build ederken bulunduğunuz dizini (context) daemon’a gönderir. Eğer node_modules, dist, log dosyaları, test çıktıları gibi klasörler context’e giriyorsa hem gönderim süresi uzar hem de cache beklenmedik şekilde bozulur. Burada .dockerignore dosyası devreye girer.

Temel öneri: node_modules, .git, dist, coverage, *.log gibi öğeleri .dockerignore ile hariç tutun. Bu, özellikle monorepo yapılarda ve büyük projelerde build hızını dramatik biçimde etkiler.

6) CI/CD İçin Cache İhracı: buildx ile Bir Üst Seviye

Yerelde cache iyi çalışsa bile CI ortamında “her şey baştan” problemi devam edebilir. BuildKit ve buildx ile cache’i registry’ye veya bir dosya deposuna dışa aktarabilirsiniz. Böylece farklı CI koşucularında bile cache yeniden kullanılabilir. Mantık olarak, bir build’in ürettiği cache metadata’sı sonraki build’e beslenir ve özellikle bağımlılık kurulumları ile derleme adımları hızlanır.

Bu yaklaşım, sık deploy eden ekiplerde maliyeti de azaltır: daha kısa çalışan pipeline, daha az kaynak tüketimi demektir. Buradaki püf nokta; cache stratejisini proje yapısına göre doğru kurgulamak ve Dockerfile katmanlarını mantıklı sıralamaktır. Aksi hâlde cache ihracı yapsanız bile, küçük bir değişiklik her şeyi geçersiz kılabilir.

Sonuç: Hız, Doğru Alışkanlıkların Yan Ürünü

Docker build sürelerini kısaltmak için tek bir “sihirli komut” yok; ama BuildKit’i etkin kullanmak, Dockerfile katmanlarını doğru düzenlemek, cache mount ile paket indirimi tekrarını azaltmak ve multi-stage build ile imajı inceltmek birlikte güçlü bir etki yaratır. Eğer her commit’te dakikalarca build bekliyorsanız, sorunun kaynağı genellikle yanlış katmanlama veya şişkin build context’tir. Bugün küçük bir Dockerfile refaktörü yaparak hem yerelde hem CI’da daha akıcı bir geliştirme deneyimi yakalayabilirsiniz.

9 Şubat 2026 Pazartesi

Docker ile Lokal Yapay Zekâ Modeli Çalıştırma: Ollama Kurulumu ve Open WebUI ile Web Arayüzü

Giriş: Bulutta Değil, Kendi Bilgisayarında Yapay Zekâ

Yapay zekâ modellerini denemek için çoğu kişi web servislerine yöneliyor. Ancak hem gizlilik hem de maliyet açısından, modeli kendi bilgisayarında çalıştırmak ciddi avantaj sağlayabiliyor. Bu rehberde güncel ve pratik bir yaklaşımı ele alacağım: Ollama ile yerel (local) LLM çalıştırmak ve bunu Docker üzerinden Open WebUI ile şık bir web arayüzüne bağlamak. Sonuçta tarayıcıdan sohbet edebileceğiniz, API erişimi sunan ve tamamen sizin kontrolünüzde bir kurulum elde edeceksiniz.

Ön Gereksinimler

Kuruluma başlamadan önce şunlara ihtiyacınız var: Docker (Docker Desktop ya da Linux üzerinde Docker Engine), temel terminal kullanımı, en az 8 GB RAM (tercihen 16 GB ve üzeri) ve yeterli disk alanı. Modeller boyuta göre 2–10+ GB arası yer kaplayabiliyor. GPU şart değil; CPU ile de çalışır ama performans beklentinizi buna göre ayarlamanız gerekir.

Adım 1: Ollama Kurulumu (Host Üzerinde)

Ollama, popüler açık kaynak modelleri yerel ortamda kolayca indirip çalıştırmanızı sağlayan bir araç. Windows ve macOS için yükleyicisi var; Linux tarafında ise resmi kurulum komutu ile hızlıca kurulabiliyor. Kurulumdan sonra Ollama varsayılan olarak 11434 portunda bir servis gibi çalışır ve API sağlar.

Kurulumun doğru yapıldığını test etmek için terminalden bir model çalıştırabilirsiniz. Örneğin: ollama run llama3.1. İlk çalıştırmada model indirileceği için bekleme süresi internet hızınıza bağlı olarak değişir. İndirme tamamlandığında komut satırında doğrudan sohbet edebildiğinizi görürsünüz.

Adım 2: Docker ile Open WebUI Kurulumu

Komut satırından sohbet etmek iş görse de çoğu kullanıcı için tarayıcı tabanlı bir arayüz daha konforlu. Open WebUI bu noktada devreye giriyor: modern bir arayüz, sohbet geçmişi ve model seçimi gibi özellikleri tek yerde topluyor. Open WebUI’yi Docker ile çalıştırmak hem güncellemeyi kolaylaştırır hem de sisteminizi “temiz” tutar.

Aşağıdaki örnek komut, Open WebUI konteynerini ayağa kaldırır. Buradaki kritik nokta, Open WebUI’nin Ollama API’sine erişebilmesi. Eğer Ollama host üzerinde çalışıyorsa, Docker konteynerinden host’a erişim yöntemi işletim sistemine göre değişebilir. Docker Desktop (Windows/macOS) için genellikle host.docker.internal kullanılabilir.

Örnek Docker komutu:
docker run -d --name open-webui -p 3000:8080 -e OLLAMA_BASE_URL=http://host.docker.internal:11434 -v open-webui:/app/backend/data --restart unless-stopped ghcr.io/open-webui/open-webui:main

Adım 3: Linux Kullanıcıları İçin Host Erişimi

Linux’ta host.docker.internal her zaman otomatik gelmeyebilir. Bu durumda iki pratik seçenek var: (1) Ollama’yı da Docker içinde çalıştırmak, (2) konteynerin host ağına erişimini ayarlamak. En basit yaklaşım çoğu senaryoda Ollama’yı da Docker’a almak olur; fakat rehberin amacında “host üzerinde Ollama + Docker’da arayüz” olduğu için, Linux’ta genellikle host IP’sini ya da ağ yapılandırmasını kullanmak gerekir. Örneğin host’un yerel IP’si 192.168.1.10 ise OLLAMA_BASE_URL değeri http://192.168.1.10:11434 olabilir.

Diğer bir yöntem, bazı Docker sürümlerinde ekstra parametreyle host ismini çözümletmektir. Ancak ağ yapılandırmaları sistemden sisteme değiştiği için, en stabil yöntem çoğu kullanıcı için host IP’sini kullanmaktır.

Adım 4: Open WebUI Üzerinden Model Yönetimi

Konteyner çalıştıktan sonra tarayıcıdan http://localhost:3000 adresine gidin. İlk açılışta bir kullanıcı oluşturmanız istenir. Ardından ayarlarda Ollama bağlantısını doğrulayabilir, indirdiğiniz modelleri listede görebilirsiniz. Eğer listede model görünmüyorsa genellikle iki sebep olur: OLLAMA_BASE_URL yanlış girilmiştir ya da Ollama servisi çalışmıyordur.

Model seçerken donanımınıza uygun boyutta kalmak önemli. Daha küçük modeller (ör. 7B civarı) günlük kullanımda daha akıcı yanıt verir. Daha büyük modeller daha iyi muhakeme sağlayabilir ama RAM ve işlemciye yük bindirir. Open WebUI, aynı anda birden fazla sohbet oturumu açmanıza da izin verir; bu da farklı “denemeleri” yan yana götürmek için kullanışlıdır.

Performans ve Güvenlik İpuçları

Yerel yapay zekâ kurulumunda performansı etkileyen en büyük faktör, modelin boyutu ve sistem kaynaklarıdır. Arka planda gereksiz uygulamaları kapatmak, modeli ilk kez çalıştırdıktan sonra sistemin “ısınmasına” izin vermek ve mümkünse SSD üzerinde çalışmak hız kazandırır. Ayrıca bu kurulumun güzel tarafı, verilerinizin dışarı çıkmamasıdır; ancak yine de Open WebUI’yi internetten erişilebilir hale getirecekseniz güçlü parola, ters proxy ve HTTPS gibi temel önlemleri almalısınız.

Son olarak, Docker ile çalıştığınız için güncelleme oldukça basit: yeni imajı çekip konteyneri yeniden oluşturabilirsiniz. Veri kaybı yaşamamak için volume kullanımını (örnekte open-webui:/app/backend/data) ihmal etmeyin.

Sonuç

Ollama + Open WebUI ikilisi, yerel yapay zekâ deneyimini “kur, çalıştır ve yönet” seviyesine taşıyor. Bulut maliyetlerine girmeden, API ve web arayüzü rahatlığını aynı anda elde etmek mümkün. Eğer geliştirme yapıyorsanız, Ollama’nın sunduğu yerel API ile uygulamalarınıza hızlıca entegrasyon da ekleyebilirsiniz. Kendi bilgisayarınızda, kendi kurallarınızla çalışan bir LLM kurulumu için bu yaklaşım güncel ve oldukça pratik bir seçenek.

8 Şubat 2026 Pazar

IPv6’ya Geçiş Rehberi: Dual Stack, DNS ve Güvenlik Ayarlarıyla Adım Adım Kurulum

IPv6 neden şimdi gündemde?

IPv4 adreslerinin pratikte tükenmesi, CGNAT kullanımının artması ve uzaktan erişim senaryolarının çoğalması IPv6’yı “bir gün geçeriz” seviyesinden çıkarıp gerçek bir ihtiyaç hâline getirdi. IPv6 sadece daha fazla adres demek değil; doğru planlandığında daha temiz bir ağ tasarımı, daha az NAT bağımlılığı ve modern güvenlik yaklaşımlarına daha uyumlu bir altyapı anlamına geliyor. Bu yazıda, ev/ofis ölçeğinden başlayıp küçük işletmeye kadar uygulanabilecek şekilde Dual Stack (IPv4+IPv6 birlikte) kurulumu, DNS kayıtları ve temel güvenlik adımlarını pratik bir rehber olarak ele alacağım.

1) Ön koşullar: ISS ve modem/router desteğini doğrulayın

Önce internet servis sağlayıcınızın (ISS) IPv6 sağladığını kontrol edin. Birçok ISS, DHCPv6-PD (Prefix Delegation) ile router’a bir “prefix” (örneğin /56 veya /64) atar. Modem/router arayüzünüzde IPv6 menüsünü bulun; “Native IPv6”, “DHCPv6”, “Prefix Delegation” gibi seçenekler görmelisiniz. Eğer cihazınız çok eskiyse IPv6 desteklese bile gelişmiş firewall/RA ayarlarını sunmayabilir. Bu aşamada hedefiniz: router’ın WAN tarafında IPv6 adresi alması ve LAN tarafına prefix dağıtabilmesi.

2) Dual Stack kurulum: IPv4’e dokunmadan IPv6’yı ekleyin

En sorunsuz geçiş yaklaşımı Dual Stack’tir. Çünkü cihazlar ve uygulamalar IPv6’yı destekliyorsa onu kullanır, desteklemiyorsa IPv4 ile devam eder. Router’da IPv6’yı etkinleştirdikten sonra genellikle iki kritik ayar vardır: DHCPv6-PD ve RA (Router Advertisement). DHCPv6-PD ile ISS’den aldığınız prefix, LAN’a dağıtılır. RA ise istemcilere “bu ağda IPv6 var, varsayılan ağ geçidi benim” bilgisini duyurur. Çoğu ev router’ında “SLAAC” (Stateless Address Autoconfiguration) otomatik gelir; bu sayede Windows, macOS, Linux ve mobil cihazlar IPv6 adresini kendisi üretir.

Kurulumdan sonra istemci tarafta doğrulama yapın. Windows’ta ipconfig, Linux/macOS’ta ip a komutuyla global IPv6 adresi görmelisiniz (genellikle 2000::/3 aralığında). Ardından bir IPv6 test sitesine girip erişimi doğrulayın. Eğer “IPv6 var ama internet yok” gibi bir durum oluşursa, çoğunlukla DNS veya firewall kuralı hatasıdır.

3) DNS tarafı: AAAA kayıtları, ters kayıt ve split-horizon

IPv6’da web sunucunuzu veya evdeki servislerinizi dışarı açacaksanız DNS’e AAAA kaydı eklemeniz gerekir. Örneğin example.com için hem A (IPv4) hem AAAA (IPv6) kaydı eklemek, istemcinin en uygun protokolle bağlanmasını sağlar. Bazı sistemler IPv6’yı tercih edebilir; bu yüzden IPv6’nız stabil değilse AAAA kaydını eklemek “yavaş açılıyor” şikâyetlerine yol açabilir. En iyi pratik: önce IPv6 bağlantısını ve firewall’ı sağlamlaştırın, sonra AAAA kaydını yayınlayın.

Kurumsal tarafta iç ağ isim çözümlemesi için split-horizon DNS (içeride farklı, dışarıda farklı kayıt döndürme) kullanılıyorsa, IPv6’yı her iki tarafta da tutarlı planlamak önemlidir. İçeride özel servisler için ULA (fc00::/7) kullanmak cazip görünse de çoğu senaryoda ISS’den gelen global prefix ile devam etmek, NAT benzeri karmaşıklıklardan kaçınmanızı sağlar. Ters DNS (PTR) kaydı ise genellikle barındırma sağlayıcı/ISS tarafında yönetilir; e-posta gibi servisler planlıyorsanız ihmal etmeyin.

4) Güvenlik: “NAT yoksa güvensiz” yanılgısı ve doğru firewall

IPv4 dünyasında NAT, yanlışlıkla “güvenlik duvarı” yerine kondu. IPv6’da her cihazın global adres alabilmesi, doğru yapılandırılmamış ağlarda yüzey alanını artırır. Bu yüzden IPv6’ya geçerken yapılacak en kritik iş, router üzerinde stateful firewall kurallarını kontrol etmektir. İyi haber: Çoğu modern router, IPv6’da varsayılan olarak dışarıdan içeri gelen bağlantıları engeller, içeriden dışarıya izin verir.

Kontrol etmeniz gerekenler: WAN’dan LAN’a inbound trafiğin kapalı olması, yönetim arayüzünün (web/SSH) internetten erişime açık olmaması, UPnP benzeri otomatik port açma mekanizmalarının IPv6’da ne yaptığı ve misafir ağlarının IPv6 izolasyonu. Ayrıca IoT cihazlar için ayrı VLAN veya misafir SSID kullanıyorsanız, IPv6 tarafında da aynı segmentasyonun uygulandığından emin olun. IPv6’da “port taraması daha zor” gibi iddialar pratikte güvenlik stratejisi değildir; temel yaklaşım yine aynıdır: minimum yetki, segmentasyon ve güncel yazılım.

5) Adres planlama: /64, /56 ve küçük ölçekli iyi pratikler

IPv6’da tipik bir LAN segmenti /64 kullanır. ISS’den /56 alıyorsanız teoride 256 adet /64 alt ağınız vardır; bu da “her VLAN’a bir /64” yaklaşımını kolaylaştırır. Ev/ofis için basit bir plan: ana ağ, misafir ağı ve IoT ağı için üç ayrı /64 ayırmak. Router bunu otomatik yapabiliyorsa harika; yapamıyorsa en azından tek bir /64 ile başlayıp ileride genişletebilirsiniz. Burada amaç, büyüdükçe yamalı bohça olmamak.

6) Sorun giderme: En sık karşılaşılan 5 problem

1) IPv6 var görünüyor ama site açılmıyor: DNS çözümlemesi veya firewall sorunu olabilir. İstemcide farklı DNS deneyin (ISS DNS’i, güvenilir bir genel DNS). 2) Bazı cihazlar IPv6 alıyor bazıları almıyor: RA yayınları kapalı olabilir veya Wi‑Fi izolasyonu/ACL engeli vardır. 3) Oyunlarda/VoIP’de sorun: Uygulama IPv6’yı kötü yönetiyor olabilir; geçici olarak AAAA kaydını kaldırmak veya istemci tarafında IPv6 önceliğini düşürmek test amaçlı yapılabilir. 4) Prefix sık değişiyor: ISS dinamik prefix veriyorsa, dış erişim için dinamik DNS ve otomatik güncelleme şarttır. 5) Port açmadan servis yayınlamak: IPv6’da NAT yok diye her şey açık değildir; yine firewall’da ilgili portlara izin vermelisiniz.

Sonuç: IPv6’yı kontrollü şekilde devreye alın

IPv6’ya geçişi “bir gecede IPv4’ü kapatalım” şeklinde düşünmek yerine, Dual Stack ile başlayıp adım adım olgunlaştırmak en sağlıklı yoldur. Önce ISS ve router uyumluluğunu doğrulayın, sonra RA/DHCPv6-PD ile istemcilere stabil adresleme sağlayın, DNS’te AAAA kayıtlarını kontrollü yayınlayın ve en önemlisi IPv6 firewall kurallarını bilinçli yönetin. Doğru kurulduğunda IPv6, erişilebilirliği artırır ve ağ yönetimini daha öngörülebilir hâle getirir.

7 Şubat 2026 Cumartesi

Cloudflare Tunnel ile Evdeki Sunucunuza Statik IP Olmadan Güvenli Erişim (Adım Adım Kurulum)

Cloudflare Tunnel nedir ve neden tercih edilmeli?

Evde NAS, Raspberry Pi, mini PC ya da bir Docker sunucusu çalıştırıyorsanız, dışarıdan güvenli erişim genellikle iki seçeneğe sıkışır: port yönlendirme (NAT) veya VPN. Port yönlendirme pratik görünse de güvenlik riskleri ve dinamik IP gibi sorunlar doğurabilir. Cloudflare Tunnel (eski adıyla Argo Tunnel) ise statik IP’ye ihtiyaç duymadan, router’da port açmadan ve servislerinizi doğrudan internete maruz bırakmadan dış erişim sağlayan modern bir yöntemdir.

Tunnel mantığı basittir: Yerel ağınızdaki bir “connector” (cloudflared) Cloudflare’a doğru dışarıya bir bağlantı başlatır. Dışarıdan gelen istekler Cloudflare üzerinden bu tünel aracılığıyla içerdeki servise iletilir. Böylece ev IP’niz ifşa olmaz, saldırı yüzeyiniz küçülür ve Cloudflare’ın WAF/Rate Limiting gibi korumalarıyla entegre olursunuz.

Ön koşullar

Bu öğreticide örnek olarak yerel ağda çalışan bir web servisini (ör. http://localhost:8080) yayınlayacağız. İhtiyacınız olanlar: Cloudflare hesabı, Cloudflare’a eklenmiş bir alan adı (ör. example.com), tüneli çalıştıracağınız bir makine (Linux önerilir; Docker da olur) ve yayınlanacak servis.

Not: Cloudflare Tunnel ile yalnızca web uygulamaları değil, uygun yapılandırma ile çeşitli TCP servisleri de yönetilebilir. Ancak en temiz ve güvenli senaryo, HTTP/HTTPS tabanlı servisleri Cloudflare Access ile kimlik doğrulama ekleyerek yayınlamaktır.

1) Cloudflare’da Tunnel oluşturma

Cloudflare paneline girin ve ilgili domaini seçin. Sol menüde Zero Trust (veya “Access/Zero Trust”) bölümüne geçin. Buradan Networks > Tunnels menüsünü açıp Create a tunnel ile yeni bir tünel oluşturun. Tünele anlaşılır bir ad verin (ör. “ev-sunucu”).

Cloudflare size kurulum adımlarını gösterecek. Bu aşamada iki yol var: doğrudan binary kurmak ya da Docker ile çalıştırmak. İleri seviye kullanıcılar için Docker, otomasyon ve taşınabilirlik açısından daha rahattır.

2) Docker ile cloudflared çalıştırma

Cloudflare panelinde “Run the connector” adımında bir token üretilir. Bu token tünelin kimliğidir. Token’ı kopyalayın ve tüneli çalıştıracağınız makinede aşağıdaki komutu kullanın:

docker run -d --name cloudflared --restart unless-stopped cloudflare/cloudflared:latest tunnel --no-autoupdate run --token YOUR_TOKEN

Bu komut, cloudflared’ı arka planda başlatır ve makine yeniden başladığında otomatik ayağa kaldırır. Sorun yaşarsanız logları görmek için:

docker logs -f cloudflared

Burada “connected” benzeri bir ifade görüyorsanız tüneliniz Cloudflare’a başarıyla bağlanmıştır.

3) Public hostname tanımlama (subdomain yönlendirme)

Şimdi dış dünyadan erişilecek adresi belirleyeceğiz. Yine Zero Trust panelinde ilgili tünelin içine girin ve Public Hostnames bölümünden yeni kayıt ekleyin. Örneğin:

Subdomain: panel
Domain: example.com
Path: (boş bırakabilirsiniz)
Service: http://localhost:8080

Bu ayarla https://panel.example.com isteği Cloudflare üzerinden tünelinize gelir ve yereldeki 8080 portuna yönlenir. Router’da port açmadığınız için servisiniz “internete açık” hale gelmez; yalnızca Cloudflare tüneli üzerinden erişilebilir olur.

4) Güvenliği bir üst seviyeye taşıma: Cloudflare Access

Tünel çalışsa bile erişimi herkese açık bırakmak istemezsiniz. Cloudflare’ın en büyük artısı burada başlar: Access policy ile kimlerin gireceğini belirleyebilirsiniz. Zero Trust panelinde Access > Applications bölümüne gidip “Self-hosted” uygulama ekleyin ve aynı hostname’i (panel.example.com) seçin.

Ardından bir politika tanımlayın. Örneğin yalnızca belirli e-posta adreslerine izin verin (Google/Microsoft ile SSO da mümkün). Bu sayede URL’yi bilen herkes değil, sadece yetkili kullanıcılar giriş yapabilir. Bu yaklaşım klasik Basic Auth’tan daha esnek ve denetlenebilir bir güvenlik katmanı sunar.

5) Sık yapılan hatalar ve ipuçları

Servis “Bad Gateway” veriyor: Genellikle yereldeki servis yanlış portta çalışıyordur veya yalnızca 127.0.0.1 yerine belirli bir arayüze bağlıdır. Docker içinden başka bir konteynıra yönlendiriyorsanız ağ ayarlarınızı kontrol edin.

HTTPS/sertifika konusu: Cloudflare dışarıya HTTPS sunar. İçerideki servisiniz HTTP olabilir; bu yaygın bir kullanımdır. Ancak içeride de TLS istiyorsanız origin sertifikası gibi seçenekler mevcut.

Performans ve gecikme: Tunnel trafiği Cloudflare POP’ları üzerinden geçer. Çoğu ev senaryosunda gecikme farkı ihmal edilebilir düzeydedir; asıl sınır genellikle ev internetinizin upload hızıdır.

Log ve izleme: Zero Trust üzerinden bağlantı denemelerini ve Access loglarını inceleyin. Şüpheli denemelerde rate limiting veya ek erişim kısıtları uygulayabilirsiniz.

Sonuç

Cloudflare Tunnel, evde barındırdığınız servisleri statik IP olmadan, port açmadan ve daha kontrollü şekilde yayınlamak için güncel ve güçlü bir çözümdür. Özellikle Cloudflare Access ile birlikte kullanıldığında, “herkese açık admin paneli” gibi riskli senaryoları neredeyse tamamen ortadan kaldırır. Eğer self-hosted uygulamalarınız var ve güvenliği ciddiye alıyorsanız, bu yaklaşım modern bir varsayılan haline gelmeye başladı.