23 Aralık 2025 Salı

Docker Compose ile PostgreSQL + pgAdmin Kurulumu: Geliştirme Ortamını 10 Dakikada Ayağa Kaldırma

Hedef: Tek Komutla Veritabanı Ortamı

Yerel geliştirme ortamında PostgreSQL kurmak çoğu zaman “kuruldu mu, servis başladı mı, port çakıştı mı, kullanıcı yetkileri doğru mu?” gibi küçük ama zaman yiyen sorularla uzar. Üstelik ekip çalışmasında herkesin makinesinde aynı sürüm ve aynı ayarlarla çalışmak daha da zorlaşır. Bu yazıda, Docker Compose ile PostgreSQL’i ve yönetim aracı olarak pgAdmin’i birlikte çalıştıran, tekrar üretilebilir (reproducible) bir kurulum hazırlayacağız. Amaç: projeyi klonlayan herkesin tek komutla aynı veritabanına erişebilmesi.

Konu “ileri seviye” tarafına şu noktada yaklaşıyor: sadece konteyneri çalıştırmakla kalmayacağız; kalıcı veri (volume), başlangıç SQL dosyaları, servis bağımlılıkları ve güvenli sayılabilecek temel ayarlarla pratik bir şablon oluşturacağız. Bu yapı; Node.js, Python, Java, .NET gibi farklı backend’lerle rahatça kullanılabilir.

Ön Koşullar

Bilgisayarınızda Docker ve Docker Compose yüklü olmalı. Güncel Docker Desktop sürümlerinde Compose genellikle hazır gelir. Terminalde docker --version ve docker compose version komutlarıyla kontrol edebilirsiniz.

Proje Yapısını Hazırlama

Proje klasörünüzde aşağıdaki gibi bir yapı işinizi kolaylaştırır. Özellikle init dosyalarını ayrı klasörde tutmak, veritabanını ilk kurulumda otomatik hazırlamak için idealdir.

Önerilen dizinler:
- docker-compose.yml
- db/init/01-schema.sql
- db/init/02-seed.sql

docker-compose.yml Dosyası

Aşağıdaki Compose tanımı PostgreSQL (db) ve pgAdmin (pgadmin) servislerini ayağa kaldırır. PostgreSQL verisi named volume ile kalıcı hale gelir; pgAdmin ayarları da ayrı volume’da tutulur. Ayrıca PostgreSQL’e ilk kurulumda SQL çalıştırmak için ./db/init klasörünü otomatik mount ediyoruz.

docker-compose.yml içeriği:

version satırı artık zorunlu olmasa da okunabilirlik için ekleyebilirsiniz. Örnek YAML:

Not: Aşağıdaki blokları dosyanıza aynen yazın (girintiler YAML için kritiktir).

docker-compose.yml
services:
  db:
    image: postgres:16
    container_name: local_postgres
    restart: unless-stopped
    environment:
      POSTGRES_USER: appuser
      POSTGRES_PASSWORD: apppass
      POSTGRES_DB: appdb
    ports:
      - "5432:5432"
    volumes:
      - postgres_data:/var/lib/postgresql/data
      - ./db/init:/docker-entrypoint-initdb.d:ro
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U appuser -d appdb"]
      interval: 5s
      timeout: 3s
      retries: 20

  pgadmin:
    image: dpage/pgadmin4:latest
    container_name: local_pgadmin
    restart: unless-stopped
    environment:
      PGADMIN_DEFAULT_EMAIL: [email protected]
      PGADMIN_DEFAULT_PASSWORD: adminpass
    ports:
      - "5050:80"
    volumes:
      - pgadmin_data:/var/lib/pgadmin
    depends_on:
      db:
        condition: service_healthy

volumes:
  postgres_data:
  pgadmin_data:

Başlangıç SQL Dosyaları (Opsiyonel ama Çok Faydalı)

PostgreSQL’in resmi imajı, ilk kez boş bir data dizini oluştururken /docker-entrypoint-initdb.d altındaki .sql dosyalarını otomatik çalıştırır. Bu sayede tablo şemasını ve örnek veriyi sürüm kontrolüne alabilirsiniz. Örnek iki dosya hazırlayalım:

db/init/01-schema.sql

CREATE TABLE IF NOT EXISTS users (
  id SERIAL PRIMARY KEY,
  email TEXT UNIQUE NOT NULL,
  created_at TIMESTAMP NOT NULL DEFAULT NOW()
);

db/init/02-seed.sql

INSERT INTO users (email) VALUES ('[email protected]')
ON CONFLICT DO NOTHING;

Buradaki önemli detay: init dosyaları sadece veritabanı ilk kez oluşturulurken devreye girer. Eğer volume zaten doluysa ve siz SQL’i değiştirdiyseniz, değişikliğin uygulanması için ya manuel migration çalıştırmanız ya da geliştirme ortamında ilgili volume’u temizleyip yeniden başlatmanız gerekir.

Servisleri Başlatma

Aynı klasörde terminal açın ve şu komutu çalıştırın:

docker compose up -d

Ardından konteynerlerin durumunu görmek için:

docker compose ps

pgAdmin ile Bağlantı Kurma

Tarayıcıdan http://localhost:5050 adresine gidin. Giriş için Compose dosyasındaki PGADMIN_DEFAULT_EMAIL ve PGADMIN_DEFAULT_PASSWORD değerlerini kullanın. Yeni bir server kaydı eklerken:

Host name/address: db
Port: 5432
Maintenance database: appdb
Username: appuser
Password: apppass

Burada “host” olarak db yazmamızın sebebi, Compose ağında servis isimlerinin DNS gibi çalışmasıdır. Yani pgAdmin konteyneri, PostgreSQL’e db:5432 üzerinden erişir.

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

Port çakışması: Makinenizde 5432 zaten kullanılıyorsa, “5432:5432” satırını örneğin “5433:5432” yapın. Uygulamanızdan bağlanırken host portunu (5433) kullanırsınız.

Şifreleri dosyaya yazmak: Bu örnek geliştirme içindir. Ekip içinde daha güvenli kullanım için ortam değişkenlerini .env dosyasına taşıyıp Compose’dan çağırabilirsiniz.

Veriyi sıfırlama: Tamamen temiz kurulum için servisleri durdurup volume’ları silin: docker compose down -v. Sonra tekrar docker compose up -d dediğinizde init SQL dosyaları yeniden çalışır.

Sonuç

Docker Compose ile PostgreSQL + pgAdmin kurulumu, hem tek kişilik projelerde hem de ekip çalışmalarında standart bir geliştirme zemini sağlar. En büyük kazanım; “benim makinemde çalışıyor” problemini azaltmanız, versiyon uyumunu korumanız ve veritabanını birkaç komutla yönetebilmenizdir. Bu şablonu temel alıp Redis, MinIO, Kafka gibi servisleri de aynı Compose dosyasına ekleyerek daha kapsamlı bir yerel ortam kurabilirsiniz.

22 Aralık 2025 Pazartesi

Windows 11’de WSL2 ile Docker Kurulumu ve Performans Ayarları (Adım Adım)

WSL2 ile Docker: Neden Hâlâ En Pratik Seçenek?

Windows 11 kullanıyorsanız ve geliştirme ortamınızı “Linux hissiyatı” ile kurmak istiyorsanız, WSL2 (Windows Subsystem for Linux) + Docker ikilisi bugün hâlâ en pratik çözümlerden biri. WSL2, Windows üzerinde gerçek bir Linux çekirdeğiyle çalıştığı için klasik sanal makine kurulumlarına göre daha hızlı başlatma, daha iyi entegrasyon ve daha az uğraş sunuyor. Bu yazıda, WSL2 üzerinde Docker’ı kurup sorunsuz çalıştırmanın yanında, performans ve disk yönetimi gibi can sıkıcı noktaları da ileri seviye ayarlarla toparlayacağız.

Ön Koşullar: Sürüm ve Özellik Kontrolü

Başlamadan önce Windows 11’in güncel olduğundan emin olun. Windows Özellikleri tarafında iki bileşenin etkin olması gerekiyor: Windows Subsystem for Linux ve Virtual Machine Platform. Bunları elle açabilirsiniz; ancak en temiz yöntem, Microsoft’un komutlarıyla ilerlemek.

1) WSL2 Kurulumu ve Varsayılan Sürümü Ayarlama

PowerShell’i Yönetici olarak açın ve şu komutu çalıştırın:

wsl --install

Bu komut çoğu sistemde gerekli bileşenleri açar ve varsayılan bir dağıtım (genellikle Ubuntu) kurar. Kurulum sonrası yeniden başlatma istenirse sistemi yeniden başlatın. Ardından WSL sürümünü 2 yapın:

wsl --set-default-version 2

Kurulu dağıtımların WSL2’de olup olmadığını görmek için:

wsl -l -v

Eğer dağıtımınız WSL1 görünüyorsa şu şekilde WSL2’ye yükseltebilirsiniz:

wsl --set-version Ubuntu 2

2) Docker Desktop Kurulumu ve WSL Entegrasyonu

Windows tarafında Docker kullanmanın en sorunsuz yolu, 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 bittikten sonra Docker Desktop’ı açın ve ayarlardan Resources > WSL Integration bölümüne gidin.

Burada, Docker’ın hangi Linux dağıtımıyla entegre çalışacağını seçebilirsiniz. Örneğin Ubuntu kullanıyorsanız ilgili dağıtımı etkinleştirin. Bu adım, “Docker komutlarını Ubuntu içinde çalıştırayım” senaryosunun anahtarıdır.

3) Ubuntu İçinde Docker’ın Çalıştığını Doğrulama

Ubuntu terminalinizi (WSL) açın ve şu komutlarla kontrol edin:

docker version

docker run --rm hello-world

İkinci komut, küçük bir imaj indirip çalıştırır ve kurulumun doğru yapıldığını net şekilde gösterir. Eğer “Cannot connect to the Docker daemon” hatası alırsanız, Docker Desktop’ın açık olduğundan ve WSL Integration’ın seçili dağıtım için etkinleştirildiğinden emin olun.

4) Performans: Dosyaları Nereye Koymalısınız?

WSL2 + Docker’da performansı belirleyen en kritik noktalardan biri dosya sistemidir. Projenizi /home/kullaniciadi/proje gibi WSL’in Linux dosya sistemi içinde tutmak genellikle çok daha hızlıdır. Projeyi /mnt/c altında (Windows diskine bağlı konumda) çalıştırmak, özellikle Node.js, PHP Composer veya yoğun küçük dosya erişimi yapan işler için belirgin yavaşlık yaratabilir.

Özet kural: Kod ve bağımlılıklar Linux tarafında, Windows tarafıyla paylaşım gerekiyorsa bunu kontrollü yapın.

5) İleri Ayar: WSL Kaynak (CPU/RAM) Sınırı ve Disk Yönetimi

WSL2 varsayılan olarak sistem kaynaklarını dinamik kullanır. Ancak Docker ile birlikte yoğun işlerde RAM tüketimi artabilir. Bunu kontrol etmek için Windows kullanıcı klasörünüzde .wslconfig adında bir dosya oluşturup şu örnek ayarları ekleyebilirsiniz:

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

Değişikliklerin uygulanması için WSL’i kapatın:

wsl --shutdown

Bir diğer yaygın sorun, Docker imajları ve katmanları arttıkça disk tüketiminin şişmesidir. WSL2 sanal diski zamanla büyür ve her zaman otomatik küçülmez. Gereksiz imajları temizlemek için periyodik olarak şu komutlar işinize yarar:

docker system prune -a

Bu komut kullanılmayan imajları da sileceği için üretim benzeri ortamlarda dikkatli olun. Düzenli temizlik, WSL2 disk şişmesi ve gereksiz alan kullanımını azaltır.

6) Sık Karşılaşılan Hatalar ve Hızlı Çözümler

Docker daemon’a bağlanamıyorum: Docker Desktop açık mı, WSL Integration doğru dağıtımda etkin mi kontrol edin. Gerekirse wsl --shutdown sonrası Docker’ı yeniden başlatın.

İmaj indirme çok yavaş: Kurumsal ağ veya proxy varsa Docker Desktop proxy ayarlarını kontrol edin. DNS problemlerinde WSL içinde resolv.conf ayarları bazen etkili olur.

Dosya erişimi yavaş: Projeyi /mnt/c yerine Linux dosya sistemine taşıyın. Özellikle bağımlılık klasörleri (node_modules gibi) için fark dramatiktir.

Sonuç: Stabil Bir Geliştirme Ortamı İçin Kısa Reçete

Windows 11’de WSL2 ile Docker kurmak artık birkaç adımda tamamlanıyor; asıl farkı yaratan kısım doğru entegrasyon ve performans ayarları. Projeyi Linux tarafında tutmak, WSL kaynaklarını mantıklı sınırlandırmak ve Docker temizliğini düzenli yapmak; hem hız hem stabilite açısından günlük geliştirme akışını ciddi şekilde iyileştirir. Bu kurulumla, Windows konforunu bozmadan Linux tabanlı bir geliştirme düzenine geçebilirsiniz.

21 Aralık 2025 Pazar

Windows 11’de WSL2 ile Docker Kurulumu ve Geliştirici Ortamını Hızlandırma Rehberi

WSL2 + Docker Neden Bu Kadar Popüler?

Windows 11 üzerinde yazılım geliştirenlerin önemli bir kısmı, Linux araçlarını yerel hızda çalıştırmak ve aynı anda Windows uygulamalarından da vazgeçmemek istiyor. WSL2 (Windows Subsystem for Linux 2), Linux çekirdeğini sanal makine benzeri bir mimaride çalıştırırken, kullanıcıya terminal ve dosya erişimi açısından çok pratik bir deneyim sunuyor. İşin içine Docker da girince; mikroservisler, test ortamları, veritabanları ve CI/CD’ye yakın bir yerel geliştirme düzeni kurmak oldukça kolaylaşıyor.

Bu rehberde, Windows 11’de WSL2’yi etkinleştirip bir Linux dağıtımı kuracak, Docker’ı WSL2 tabanlı şekilde çalıştıracak ve performans/uyumluluk için birkaç kritik ayarı yapacağız. Anlatım sade; ancak adımlar güncel ve geliştirici kullanımına uygun olacak.

1) Ön Koşullar ve Kontroller

Başlamadan önce sisteminizde sanallaştırmanın açık olduğundan emin olun. Görev Yöneticisi > Performans sekmesinde Sanallaştırma: Etkin görmelisiniz. Değilse BIOS/UEFI üzerinden Intel VT-x veya AMD-V özelliğini açmanız gerekir.

Windows 11’in güncel olması da önemli. Bazı WSL2 ve ağ bileşenleri güncellemelerle iyileşiyor. Ayarlar > Windows Update bölümünden güncelleme kontrolü yapın.

2) WSL2 Kurulumu ve Varsayılan Sürümü Ayarlama

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

wsl --install

Bu komut çoğu sistemde gerekli bileşenleri kurar ve varsayılan olarak bir dağıtım (genellikle Ubuntu) önerir. Kurulumdan sonra yeniden başlatmanız istenebilir. Ardından WSL sürümünü 2 olarak sabitlemek için:

wsl --set-default-version 2

Kurulu dağıtımları görmek için:

wsl -l -v

Eğer dağıtımınız WSL 1 görünüyorsa, örnek olarak Ubuntu’yu WSL2’ye çevirebilirsiniz:

wsl --set-version Ubuntu 2

3) Ubuntu İçinde Temel Güncelleme ve Kullanışlı Paketler

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

sudo apt update && sudo apt upgrade -y

Geliştirme süreçlerinde sık kullanılan araçlar için:

sudo apt install -y build-essential git curl ca-certificates

4) Docker’ı WSL2 Üzerinde Çalıştırma (Docker Desktop ile)

Windows tarafında en sorunsuz yöntem, Docker Desktop kullanmaktır. Docker Desktop’ı kurduktan sonra Ayarlar (Settings) içinde Use the WSL 2 based engine seçeneğini etkinleştirin. Ardından Resources > WSL Integration bölümünde Ubuntu dağıtımınızı seçip entegrasyonu açın.

Bu aşamadan sonra Ubuntu terminalinde Docker komutlarını çalıştırabilmelisiniz. Kontrol için:

docker version

docker run --rm hello-world

Komutlar çalışıyor ama izin hatası alıyorsanız, genellikle Docker Desktop entegrasyonu eksik veya dağıtım seçimi kapalıdır. Ayarlara geri dönüp WSL Integration’ı doğrulayın.

5) Performans İçin Kritik İpucu: Dosyaları Nerede Tutmalı?

WSL2 + Docker kullanımında en sık yaşanan performans farkı, proje dosyalarının konumundan kaynaklanır. Eğer kaynak kodunuz Windows dosya sisteminde (ör. C:\) duruyor ve siz WSL içinden bu klasöre /mnt/c üzerinden erişiyorsanız, yoğun dosya okuma/yazma yapan projelerde yavaşlık hissedebilirsiniz.

Daha iyi performans için projelerinizi WSL dosya sisteminde tutun. Örneğin:

mkdir -p ~/projeler

Bu klasör altında çalışıp editör olarak VS Code’un Remote - WSL eklentisini kullanırsanız hem Windows arayüzüyle düzenleme yapar hem de Linux tarafında hızlı I/O avantajını korursunuz.

6) Docker Compose ile Örnek Bir Geliştirme Ortamı

Hızlı bir test ortamı için bir klasör oluşturup içine docker-compose.yml ekleyebilirsiniz. Örneğin PostgreSQL başlatmak, çoğu projede büyük kolaylık sağlar. Dosyanızın mantığı basit: bir veritabanı servisi, port yönlendirme ve kalıcı veri dizini. Compose çalıştırmak için genelde şu komut yeterlidir:

docker compose up -d

Sonrasında konteynerleri kontrol edin:

docker ps

İşiniz bitince ortamı kaldırmak için:

docker compose down

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

WSL dağıtımı açılmıyor veya güncellenmiyor: PowerShell’de wsl --update komutunu deneyin ve Windows Update’i kontrol edin.

Docker komutları bulunamıyor: Docker Desktop’ın açık olduğundan ve WSL Integration’ın ilgili dağıtım için etkin olduğundan emin olun.

Port çakışması: 5432, 3306 gibi yaygın portlar başka servisler tarafından kullanılıyor olabilir. Compose dosyasında portları değiştirin veya çakışan servisi kapatın.

Sonuç

Windows 11’de WSL2 ile Docker kullanmak, tek bilgisayarda hem Windows uygulamalarını hem de Linux tabanlı geliştirme araçlarını verimli şekilde bir araya getirir. Doğru entegrasyon yapıldığında, konteyner tabanlı projeler daha taşınabilir olur; test ve geliştirme ortamları birkaç komutla ayağa kalkar. En büyük kazanım ise şudur: “Makinemde çalışıyor” cümlesini ekibin geri kalanından daha az duyarsınız.

20 Aralık 2025 Cumartesi

Windows 11’de WSL2 ile Docker Kurulumu ve Performans İyileştirme Rehberi (2025)

WSL2 + Docker Neden Hâlâ En Mantıklı Kombinasyon?

Windows 11 üzerinde yazılım geliştirenlerin büyük bölümü iki farklı dünyayı aynı anda yönetiyor: Windows uygulamaları ve Linux tabanlı geliştirme araçları. WSL2 (Windows Subsystem for Linux 2), Linux çekirdeğini sanallaştırma katmanıyla çalıştırdığı için klasik WSL1’e göre çok daha hızlı dosya sistemi ve ağ performansı sunuyor. Docker ise mikro servis, test otomasyonu ve yerel geliştirme ortamlarını standartlaştırma konusunda artık neredeyse “varsayılan” araç. Bu rehberde Windows 11’de WSL2 ile Docker kurulumunu adım adım yapacak, ardından sık görülen darboğazları performans odaklı ayarlarla gidereceğiz.

Ön Koşullar: Sürüm ve Özellik Kontrolü

Kuruluma başlamadan önce Windows 11’in güncel olduğundan emin olun. WSL2 için sanallaştırma desteği (BIOS/UEFI üzerinden VT-x/AMD-V) açık olmalı. Kurumsal cihazlarda bu ayar kilitli olabilir; böyle bir durumda BT birimiyle görüşmek gerekir. Ayrıca Hyper-V ve Virtual Machine Platform özellikleri WSL2 için önemlidir.

Windows özelliklerini hızlıca etkinleştirmek için PowerShell’i yönetici olarak açıp şu komutları kullanabilirsiniz:

1) wsl --install

Bu komut WSL’yi kurar, varsayılan olarak bir Linux dağıtımı (genelde Ubuntu) yükler ve gerekli bileşenleri etkinleştirmeye çalışır. Kurulum sonrası yeniden başlatma istenirse ertelemeyin.

WSL2 Dağıtımını Kurma ve Güncelleme

Yeniden başladıktan sonra Ubuntu (veya seçtiğiniz dağıtım) ilk açılışta kullanıcı adı ve parola oluşturmanızı ister. Ardından Linux paketlerini güncellemek iyi bir alışkanlıktır:

sudo apt update && sudo apt upgrade -y

WSL sürümünü kontrol etmek için Windows tarafında şu komutu çalıştırabilirsiniz:

wsl -l -v

Dağıtımınızın “VERSION” sütununda 2 yazdığını görmelisiniz. Eğer 1 ise:

wsl --set-version Ubuntu 2

Docker Desktop Kurulumu ve WSL2 Entegrasyonu

Docker’ı Windows 11’de en sorunsuz yöntemle kullanmak için güncel Docker Desktop tercih ediliyor. Kurulum sırasında “Use WSL 2 instead of Hyper-V” benzeri seçenekler görürseniz WSL2’yi seçin. Kurulumdan sonra Docker Desktop’ı açın ve şu ayarları kontrol edin:

Settings > General: WSL2 tabanlı motor etkin olmalı.

Settings > Resources > WSL Integration: Ubuntu dağıtımınız için entegrasyonu açın.

Bu aşamadan sonra Ubuntu terminalinde Docker komutlarının çalıştığını doğrulayın:

docker version

Test amaçlı basit bir container çalıştırabilirsiniz:

docker run --rm hello-world

Performans İyileştirme: En Kritik 3 Nokta

1) Proje dosyalarını doğru yerde tutun (çok önemli). WSL2 ile çalışırken kaynak kodunuzu Windows dosya sisteminde (ör. C:\Users\...) tutup WSL üzerinden erişmek I/O gecikmesini artırabilir. Docker build süreleri ve testler gereksiz uzar. En iyi pratik, projeyi Linux dosya sisteminde tutmaktır: /home/kullanici/proje. VS Code kullanıyorsanız “Remote - WSL” eklentisiyle projeyi doğrudan WSL içinde açarak hem hızlı hem stabil bir akış elde edersiniz.

2) WSL kaynak limitlerini ayarlayın. Varsayılan durumda WSL2, sistem kaynaklarını dinamik yönetir; bu bazen RAM’in gereksiz şişmesine ya da CPU’nun dengesiz kullanımına yol açabilir. Windows kullanıcı dizininizde bir .wslconfig dosyası oluşturarak limit koyabilirsiniz:

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

Değerleri sisteminize göre uyarlayın. Ardından WSL’yi kapatıp açın: wsl --shutdown. Bu ayar, Docker build ve compose senaryolarında daha öngörülebilir performans sağlar.

3) Docker Desktop kaynaklarını gereksiz şişirmeyin. Docker Desktop tarafında da CPU/RAM limitleri bulunur. Eğer WSL2 motorunu kullanıyorsanız çoğu yük WSL2 üzerinde koşar; yine de ağır compose projelerinde denge önemlidir. Gereğinden fazla CPU vermek her zaman hızlandırmaz; özellikle aynı anda IDE, tarayıcı ve test araçları çalışıyorsa sistem geneli yavaşlayabilir.

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

Docker komutu bulunamıyor: WSL Integration açık mı kontrol edin. Docker Desktop çalışıyor olmalı. Ubuntu içinde docker komutu hâlâ yoksa dağıtım entegrasyonu kapalı olabilir.

Port çakışması (ör. 3000/5432): Aynı portu kullanan başka bir servis Windows tarafında çalışıyor olabilir. docker ps ile container portlarını kontrol edin ve gerekirse docker compose yapılandırmanızda portları değiştirin.

Dosya izleme (hot reload) yavaş: Proje Windows dizinindeyse WSL içine taşıyın. Ayrıca Node.js gibi araçlarda dosya izleme ayarlarını WSL için optimize eden parametreler gerekebilir, ancak çoğu durumda dosya konumu değişikliği sorunu kökten çözer.

Sonuç: Daha Hızlı Build, Daha Stabil Geliştirme

Windows 11’de WSL2 ile Docker kullanmak, doğru kurulum ve birkaç kritik ayarla hem hızlı hem de üretken bir geliştirme ortamı sunuyor. En büyük kazanım genellikle “dosyaları doğru yerde tutmak” ile geliyor: kaynak kodu WSL dosya sistemine taşıdığınızda build süreleri kısalır, container içi I/O performansı hissedilir biçimde artar. Üstüne .wslconfig ile kaynakları dengelediğinizde sistem stabilitesi belirgin şekilde iyileşir. Eğer yerel geliştirme ortamınızı modernleştirmek istiyorsanız, bu kombinasyon 2025’te de en pratik seçeneklerden biri olmaya devam ediyor.

19 Aralık 2025 Cuma

Güncel Rehber: Docker’da Rootless Mod ile Güvenli Konteyner Çalıştırma (Adım Adım)

Rootless Docker nedir ve neden önemli?

Docker’ı klasik kurulumla kullandığınızda, arka plandaki dockerd servisi genellikle root yetkileriyle çalışır. Bu, konteyner izolasyonu güçlü olsa bile “daemon” katmanında yetki seviyesinin yüksek olduğu anlamına gelir. Rootless Docker ise Docker daemon’ını ve konteynerleri root olmayan bir kullanıcıyla çalıştırarak olası bir kaçış senaryosunda zararın etkisini düşürür. Özellikle paylaşımlı sunucular, geliştirici makineleri ve CI ortamlarında “en az ayrıcalık” yaklaşımını uygulamak için güncel ve pratik bir yöntemdir.

Bu yazıda Rootless Docker’ın ne işe yaradığını, hangi sınırlamalara sahip olduğunu ve Linux üzerinde nasıl kurup günlük kullanımda problemsiz çalıştırabileceğinizi adım adım göreceksiniz. Odak noktası, güvenliği artırırken geliştirici deneyimini mümkün olduğunca bozmadan ilerlemek.

Ön koşullar ve desteklenen sistemler

Rootless mod en sorunsuz şekilde modern Linux dağıtımlarında çalışır. Ubuntu 22.04/24.04, Debian 12, Fedora gibi sistemler uygun adaylardır. Çekirdek tarafında kullanıcı isim alanları (user namespaces) ve cgroup desteği gibi bileşenler önemlidir. Ayrıca Rootless Docker, ağ tarafında çoğunlukla slirp4netns ile kullanıcı alanı NAT kullanır; performans ve port yönlendirme mantığı root’lu kurulumdan farklı olabilir.

Bu rehberde komutlar Debian/Ubuntu çizgisinde düşünülmüştür. Fedora veya Arch kullanıyorsanız paket isimleri değişebilir, mantık aynı kalır.

1) Gerekli paketler ve Docker kurulumu

Öncelikle Docker Engine’in kurulu olması gerekir. Resmî depodan kurulum önerilir. Kurulumdan sonra Rootless için gerekli yardımcı araçlar gerekebilir. Ubuntu/Debian’da çoğu zaman aşağıdakiler işinizi görür:

Komut örneği:
sudo apt update
sudo apt install -y uidmap slirp4netns fuse-overlayfs

Burada uidmap paketi rootless çalışmada kullanıcı kimliği eşlemeleri için kritik olan newuidmap/newgidmap araçlarını sağlar. fuse-overlayfs ise overlay dosya sistemi rootless senaryolarda daha iyi performans/uyumluluk sunabilir.

2) Rootless kurulumu başlatma

Docker kurulumunuzda genellikle dockerd-rootless-setuptool.sh adlı bir kurulum aracı bulunur. Bu araç, kullanıcı düzeyinde systemd servislerini ve gerekli dizinleri oluşturur.

Komut örneği:
dockerd-rootless-setuptool.sh install

Kurulum bittiğinde size DOCKER_HOST gibi ortam değişkenlerini ayarlamanızı öneren bir çıktı gösterebilir. Rootless Docker’da daemon, kullanıcıya ait bir UNIX soketi üzerinden çalışır. Bu da varsayılan /var/run/docker.sock yerine genellikle şu tarz bir yola işaret eder:

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

3) Ortam değişkeni ve kalıcı ayar

Mevcut terminal oturumunda Rootless Docker’ı kullanmak için aşağıdaki değişkeni tanımlayabilirsiniz:

Komut örneği:
export DOCKER_HOST=unix:///run/user/$(id -u)/docker.sock

Kalıcı yapmak için bunu ~/.bashrc veya kullandığınız shell’in profil dosyasına ekleyebilirsiniz. Ardından Docker istemcisinin doğru daemon’a bağlandığını doğrulayın:

Komut örneği:
docker info

Çıktıda “rootless” ile ilgili bir ibare görmeniz veya daemon’ın user socket üzerinden çalıştığını doğrulamanız gerekir. Eğer hâlâ root’lu servise bağlanıyorsa DOCKER_HOST ayarını ve terminal oturumunuzu kontrol edin.

4) Systemd ile otomatik başlatma

Rootless kurulum çoğunlukla kullanıcı seviyesinde systemd servisi oluşturur. Servisi yönetmek için:

Komut örneği:
systemctl --user status docker
systemctl --user enable --now docker

Uzak oturumlarda veya yeniden başlatmalarda kullanıcı servisi çalışsın istiyorsanız “linger” açmak gerekebilir:

Komut örneği:
sudo loginctl enable-linger $(whoami)

5) Port yönlendirme ve ağ davranışı

Rootless modda 1024 altındaki portlara (80, 443 gibi) bağlanmak bazı dağıtımlarda doğrudan mümkün olmayabilir. Geliştirme ortamında alternatif olarak 8080/8443 gibi portlar kullanabilir ya da ters vekil (reverse proxy) yaklaşımına gidebilirsiniz. Örneğin Nginx’i root yetkisiyle host’ta dinleyip trafiği rootless konteyner portuna aktarabilirsiniz.

Basit bir test için bir web sunucusu çalıştırın:

Komut örneği:
docker run --rm -p 8080:80 nginx

Ardından tarayıcıdan http://localhost:8080 ile doğrulayın. Rootless ağ katmanı kullanıcı alanında çalıştığı için bazı senaryolarda performans root’lu kurulumdan düşük olabilir; ancak güvenlik hedefiniz yüksekse bu takas kabul edilebilir.

6) Sık karşılaşılan sorunlar ve çözüm ipuçları

“newuidmap: write to uid_map failed” gibi hatalar genellikle uidmap paketinin eksikliğine veya /etc/subuid ve /etc/subgid eşlemelerinin yetersizliğine işaret eder. Çoğu sistemde kurulum aracı bunları ayarlar, ancak sorun yaşıyorsanız kullanıcıya yeterli aralık tanımlandığından emin olun.

Disk sürücüsü ve overlay problemi yaşayanlar için fuse-overlayfs önemli bir çözümdür. Ayrıca Docker’ın storage driver seçimi rootless modda farklı davranabilir. Günlükleri kontrol etmek için:

Komut örneği:
journalctl --user -u docker --no-pager -n 200

Kaynak tüketimi ve limitler konusunda da cgroup v2 uyumluluğu önemlidir. Modern dağıtımlar cgroup v2 ile daha sorunsuzdur. “docker info” çıktısında cgroup sürümünü kontrol ederek ilerleyin.

Sonuç: Rootless Docker kimler için ideal?

Rootless Docker, tek başına tüm güvenlik sorunlarını sihirli şekilde çözmez; yine de konteyner çalıştırma katmanında root yetkisini ortadan kaldırarak saldırı yüzeyini ciddi biçimde azaltır. Kişisel geliştirme makineleri, eğitim ortamları, çok kullanıcılı sistemler ve güvenlik hassasiyeti yüksek ekipler için güncel ve uygulanabilir bir yaklaşımdır. Eğer amacınız “konteyner çalıştırıyorum, ama host üzerinde root daemon istemiyorum” ise Rootless mod, bugün tercih edilebilecek en pratik çözümlerden biridir.

18 Aralık 2025 Perşembe

Web Sitelerinde Core Web Vitals İyileştirme Rehberi: INP, LCP ve CLS’yi Gerçekten Düşürmek

Core Web Vitals neden hâlâ önemli?

Google’ın Core Web Vitals metrikleri (LCP, CLS ve güncel olarak FID yerine geçen INP) sadece “SEO puanı” için değil, ziyaretçinin sayfayı akıcı kullanabilmesi için de kritik. Özellikle mobil trafikte, birkaç yüz milisaniyelik gecikme bile etkileşimi düşürüyor. Bu rehberde, geliştirici araçlarıyla sorunu bulup, kod seviyesinde uygulanabilir optimizasyonları adım adım ele alacağım.

1) Ölçmeden iyileştirme olmaz: Doğru metrik kaynağını seçin

İlk hata, yalnızca laboratuvar testlerine bakıp (Lighthouse gibi) gerçek kullanıcı verisini (field data) göz ardı etmek. Başlangıç için şu kaynakları birlikte kullanın: PageSpeed Insights (CrUX saha verisi + lab), Chrome DevTools Performance (iz sürme), WebPageTest (farklı cihaz/ağ senaryoları) ve mümkünse RUM (Real User Monitoring) ile gerçek ziyaretçiden telemetri toplama. Hedefiniz net olmalı: LCP < 2,5 sn, CLS < 0,1 ve INP < 200 ms.

2) LCP (Largest Contentful Paint): “En büyük” içeriği hızlandırın

LCP çoğu sitede “hero” görseli, başlık alanı veya üstteki büyük bir kart bileşeni olur. LCP’yi iyileştirmenin ana fikri şudur: kritik içeriğe giden yolu kısaltın. Önce DevTools’ta Performance kaydı alın, “Timings” ve “LCP” işaretini bulun; ardından LCP öğesinin ne olduğunu tespit edin.

Uygulanabilir adımlar: 1) Sunucu yanıt süresini düşürün (TTFB). CDN kullanın, HTML’i önbelleğe alın, dinamik sorguları azaltın. 2) Kritik CSS’i öne alın; sayfanın üst kısmını boyamak için gereken CSS’i geciktirmeyin. 3) Render-blocking kaynakları azaltın: büyük JS paketlerini başlangıçta yüklemek LCP’yi uzatır. 4) Web fontları için doğru stratejiyi seçin: font-display: swap gibi ayarlar, metnin beklemesini azaltır.

3) CLS (Cumulative Layout Shift): Kaymaların kaynağını kapatın

CLS çoğu zaman “reklam alanı sonradan geldi”, “görsel boyutu belirtilmedi”, “font geç yüklendi ve satırlar oynadı” gibi sebeplerle yükselir. Sorunun güzelliği şu: Genellikle birkaç net düzeltmeyle ciddi düşer.

Uygulanabilir adımlar: 1) Görseller ve iframe’ler için genişlik/yükseklik belirtin ya da CSS ile en-boy oranını sabitleyin. 2) Üst kısma dinamik banner ekliyorsanız yer tutucu alan ayırın. 3) Geç yüklenen fontlarda satır kaymasını azaltmak için benzer metriklere sahip font fallback’leri seçin. 4) “Yukarıdan açılan” çerez bildirimi gibi bileşenleri sayfa içeriğini itmek yerine, sabit konumda (overlay) tasarlamayı değerlendirin.

4) INP (Interaction to Next Paint): Etkileşim gecikmesini azaltmanın kısa yolu

INP, kullanıcının tıklama/dokunma/klavye gibi etkileşiminden sonra arayüzün bir sonraki çizimine kadar geçen süreyi ölçer. Kısaca: JS ana iş parçacığını (main thread) tıkamayın. Büyük framework projelerinde bile INP’yi düşüren en etkili hamle, “gereksiz iş”i doğru zamana yaymaktır.

Uygulanabilir adımlar: 1) Uzun süren görevleri bölün: 200–300 ms’yi aşan işlemleri küçük parçalara ayırın. 2) Olay dinleyicilerini sadeleştirin; her tıklamada ağır DOM işlemleri yapmayın. 3) “Passive event listener” kullanın (özellikle scroll/touch). 4) Üçüncü taraf script’leri (chat, analytics, tag manager) denetleyin; INP’yi en çok bunlar bozabilir. Mümkünse gecikmeli yükleyin veya daha hafif alternatiflere geçin.

5) Pratik bir kontrol listesi: Hızlı kazanımlar

Kontrol listesi: (1) Ana sayfa ve en çok trafik alan 3 şablonda ölçüm alın. (2) LCP öğesini belirleyip kritik yolu kısaltın. (3) CLS için boyut belirtmeyen medya alanlarını tespit edin. (4) INP için Performance kaydında “Long Task” avına çıkın. (5) Üçüncü taraf script’leri tek tek devre dışı bırakıp etkisini ölçün. (6) Değişiklik sonrası PageSpeed Insights + gerçek kullanıcı verisiyle doğrulayın.

6) Sık yapılan hatalar ve doğru yaklaşım

Sadece Lighthouse skorunu yükseltmeye odaklanmak çoğu zaman yanıltıcıdır; çünkü kullanıcılar farklı cihaz ve ağlarda geziyor. Diğer hata, her şeyi aynı anda optimize etmeye çalışmak. En iyi yöntem: önce en çok etkileyen metriği seçin (örneğin LCP), en büyük darboğazı giderin, sonra diğerine geçin. Küçük ama doğrulanmış iyileştirmeler, bir “büyük refactor”dan daha güvenli sonuç verir.

Sonuç

Core Web Vitals optimizasyonu, “tek seferlik” değil, ölçüm-iyileştirme döngüsüdür. LCP’de kritik içeriği hızlandırın, CLS’de düzen kaymalarını kökten engelleyin, INP’de ana iş parçacığını rahatlatın. Bu üçlüde doğru teşhis ve küçük ama hedefli dokunuşlarla hem kullanıcı deneyimini hem de organik görünürlüğü aynı anda güçlendirebilirsiniz.

Docker Compose ile Yerel Geliştirme Ortamı Kurma: PostgreSQL + Redis + Uygulama Servisi (İleri Seviye How-To)

Docker Compose neden hâlâ en pratik seçenek?

Yerel geliştirme ortamı kurarken en çok vakit yediren şey, bağımlılıkların (veritabanı, cache, mesaj kuyruğu, reverse proxy vb.) makineden makineye farklı davranmasıdır. Docker Compose, birden fazla servisi tek bir dosyada tanımlayıp ayağa kaldırarak “bende çalıştı” problemini ciddi ölçüde azaltır. Bu yazıda PostgreSQL ve Redis’i, bir uygulama servisiyle birlikte aynı ağda koşturacak; kalıcı veri, healthcheck, profil ve ortam değişkeni yönetimi gibi ileri seviye pratiklere değineceğiz.

1) Proje yapısı: düzenli başlamak önemli

Örnek bir dizin yapısı oluşturalım. Terminalde bir klasör açıp içerisine aşağıdaki gibi dosyalar koymanız yeterli: docker-compose.yml, .env ve isterseniz uygulamanız için bir Dockerfile. Uygulama diliniz önemli değil; Compose tarafında servislerin birbirini görmesi ve konfigürasyonun taşınabilir olması hedef.

2) .env ile gizli bilgileri yönetmek

Compose dosyasına gömmek yerine şifreleri ve sık değişen değerleri .env içine almak daha temizdir. Proje köküne bir .env dosyası oluşturun ve örnek olarak şunları ekleyin: POSTGRES_DB=appdb, POSTGRES_USER=appuser, POSTGRES_PASSWORD=gucluSifre123, REDIS_PASSWORD=redisSifre123. Bu dosyayı versiyon kontrolüne koymamayı unutmayın; gerekirse örnek bir .env.example

3) docker-compose.yml: PostgreSQL + Redis + app

Aşağıdaki Compose tanımı, üç servisi aynı network üzerinde çalıştırır. PostgreSQL için kalıcı volume, Redis için parola ve iki servis için healthcheck ekledik. Uygulama servisini ise örnek bir “app” konteyneri olarak tanımlıyoruz; burada kendi Dockerfile’ınızı kullanabilir ya da hazır bir imajla test edebilirsiniz.

docker-compose.yml içeriği:

version: "3.9"
services:
  db:
    image: postgres:16-alpine
    container_name: local-postgres
    restart: unless-stopped
    environment:
      POSTGRES_DB: ${POSTGRES_DB}
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    ports:
      - "5432:5432"
    volumes:
      - pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER} -d ${POSTGRES_DB}"]
      interval: 5s
      timeout: 3s
      retries: 20

  redis:
    image: redis:7-alpine
    container_name: local-redis
    restart: unless-stopped
    command: ["sh", "-c", "redis-server --requirepass ${REDIS_PASSWORD}"]
    ports:
      - "6379:6379"
    healthcheck:
      test: ["CMD-SHELL", "redis-cli -a ${REDIS_PASSWORD} ping | grep PONG"]
      interval: 5s
      timeout: 3s
      retries: 20

  app:
    build: .
    container_name: local-app
    restart: unless-stopped
    depends_on:
      db:
        condition: service_healthy
      redis:
        condition: service_healthy
    environment:
      DATABASE_URL: postgres://${POSTGRES_USER}:${POSTGRES_PASSWORD}@db:5432/${POSTGRES_DB}
      REDIS_URL: redis://:${REDIS_PASSWORD}@redis:6379/0
    ports:
      - "8080:8080"

volumes:
  pgdata:

4) Uygulama servisi için minimal Dockerfile fikri

“app” servisi için örnek bir Dockerfile ihtiyacınız olacak. Kendi stack’inize göre değişir; ancak temel prensip aynıdır: bağımlılıkları kur, kaynak kodu kopyala, uygulamayı çalıştır. Örneğin Node.js kullanıyorsanız node:20-alpine ile başlayabilir; Python’da python:3.12-slim tercih edebilirsiniz. Önemli nokta, Compose içindeki bağlantı adreslerinin db ve redis servis adları üzerinden verilmesidir; çünkü konteynerlar aynı Compose ağı içinde DNS ile birbirini bu isimlerle bulur.

5) Çalıştırma, log takibi ve durdurma

Kurulumdan sonra proje kökünde şu komut yeterlidir: docker compose up -d. İlk çalıştırmada imajlar indirileceği için birkaç dakika sürebilir. Servislerin durumunu görmek için docker compose ps, logları takip etmek için docker compose logs -f kullanın. Her şeyi kapatmak için docker compose down işinizi görür; veriyi de silmek istiyorsanız (PostgreSQL volume) docker compose down -v uygulayabilirsiniz.

6) Sık yapılan hatalar ve pratik ipuçları

En yaygın hata, uygulama içinde veritabanına localhost ile bağlanmaya çalışmaktır. Konteyner içinden “localhost”, o konteynerın kendisini ifade eder; bu yüzden bağlantı adresi db:5432 olmalı. İkinci hata, servisler hazır olmadan uygulamanın ayağa kalkmasıdır; burada kullandığımız healthcheck ve depends_on condition: service_healthy yaklaşımı bu sorunu büyük ölçüde azaltır. Son olarak, geliştirme sürecinde dosya değişikliklerini anında görmek istiyorsanız volumes ile proje klasörünü konteynere mount edebilir, fakat bu ayarı işletim sisteminize ve kullandığınız dile göre dikkatle yapmalısınız.

Sonuç: taşınabilir, tekrarlanabilir bir yerel ortam

Bu yapı sayesinde PostgreSQL ve Redis’i tek komutla ayağa kaldırıp uygulamanızla aynı ağda konuşturabilirsiniz. Üstelik ekipteki herkes aynı Compose dosyasını kullandığı için ortam farklılıkları azalır, hata ayıklama hızlanır. İsterseniz bir sonraki adım olarak profil ekleyip (ör. test/prod), ya da ters proxy (Nginx/Traefik) ile TLS ve routing katmanı ekleyerek daha da gerçekçi bir geliştirme ortamı kurabilirsiniz.