WSL Container Public Preview: Windows’ta Linux Konteyner Devri
Şunu açık söyleyeyim: Windows üstünde Linux konteyner çalıştırma işi yıllardır biraz garip bir yerde duruyordu. Docker Desktop vardı, sonra lisans konusu patladı; Rancher Desktop çıktı, Podman Desktop çıktı, derken herkes kendi yolunu çizmeye başladı. Kurumsal tarafta iş daha da karıştı,. Lisans komiteleri ayrı dert, güvenlik ekipleri ayrı dert, proxy ayarları işe bambaşka bir hikâye… Sonunda Microsoft “tamam ya, bu işi WSL’in içine gömelim” dedi.
Bakın, Microsoft Build 2026’da duyurulan WSL container özelliği artık public preview’da. Yanı indirip kurabiliyorsunuz. Ben de birkaç gündür kurcalıyorum ve açık konuşayım — beklediğimden daha oturmuş geldi. Kağıt üstünde iyi dürüyor, pratikte de şu ana kadar canımı sıkmadı. Bu bile tek başına fena değil.
Kısa bir not düşeyim buraya.
Peki tam olarak ne geldi?
Kısaca iki parça var. Biri CLI aracı: wslc.exe. Diğeri de Windows uygulamalarının programatik şekilde Linux konteyner çalıştırabilmesi için bir API. İlk bakışta aynı şey gibi duruyorlar ama aslında farklı kapıları açıyorlar.
CLI tarafı, docker CLI’a alışmış olanlara baya tanıdık gelecek. Aynı kaş hafızası, aynı argüman mantığı. run, ps, exec, logs… hepsi orada. Hatta Microsoft bir de container.exe alias’ı koymuş. Isterseniz container run... diye de yazabiliyorsunuz. İkisi de aynı yere çıkıyor.
API tarafı işe biraz daha ilginç, hatta dürüst olayım, asıl olay orada dönüyor. NuGet üzerinden gelen bir paket var; C, C++ ve C# destekli. Şöyle düşünün: Native bir Windows uygulaması yazıyorsunuz ve bunun içinde Linux tarafında koşması gereken bir iş var — mesela eski bir Python bilimsel hesaplama kütüphanesi ya da sadece Linux’ta düzgün çalışan bir CLI aracı. Eskiden bunu WSL’e komut atarak çözmeye çalışıyordunuz, şimdi doğrudan API çağrısıyla hallediyorsunuz.
Neden bu ayrım önemli?
Çünkü Docker Desktop’ın çözemediği temel meselelerden biri buydu aslında. Docker Desktop bir developer aracı; uygulamanızın üretim akışına gömmek her zaman rahat olmuyor. WSL container API işe başka türlü çalışıyor; uygulamanızın parçası olabiliyor. MSBuild. CMake entegrasyonu da var, yanı proje dosyanıza birkaç satır ekleyip konteyner build/deploy adımlarını build sürecine sokabiliyorsunuz. Manuel adım azalıyor, hatta bazı yerlerde tamamen kayboluyor.
İşte tam da bu noktada devreye giriyor.
wslc.exe ile ilk temas
Dürüst olmak gerekirse, wsl --update --pre-release ile güncellemeyi çektikten sonra PATH’e wslc.exe düşüyor. Ben ilk olarak şunu denedim — CUDA sürücü testi:
wslc run --rm --gpus all pytorch/pytorch:2.5.1-cuda12.4-cudnn9-runtime \
python -c "import torch; print(torch.cuda.is_available()); print(torch.cuda.get_device_name(0))"Ve… çalıştı. GPU’yu gördü, cihaz adını bastı. Docker Desktop üstünden GPU passthrough ayarlamaya uğraşanlar bilir; bazen sabahınızı yiyebiliyor bu iş. Burada daha düz gitti.
Sonra ikinci denemede tam tersine biraz saçma. Keyifli bir şey yaptım: konteyner içinde Linux masaüstü ayağa kaldırdım.
wslc run -d --name=webtop \
-e PUID=1000 -e PGID=1000 -e TZ=Etc/UTC \
-p 3000:3000 -p 3001:3001 \
lscr.io/linuxserver/webtop:ubuntu-kdelocalhost:3000 adresine girdim ve KDE masaüstü karşıma geldi. Gösteriş olsun diye yapılmış gibi dürüyor, evet; ama altındaki mesaj net: GUI çalışıyor, GPU çalışıyor, network port mapping çalışıyor (ve pek uğraştırmıyor). Kötü değil yanı.
Docker CLI’dan farkı ne?
Açık konuşayım, günlük kullanımda devasa bir fark hissetmiyorsunuz bile olabilir. Bunu eksiklik gibi değil de bilinçli tasarım gibi görüyorum ben. Microsoft “gelin yeni paradigma icat ettik” demiyor; “aynı işi Windows’a daha derin gömdük” diyor resmen. Farklar daha çok kaputun altında:
- Docker daemon yok — konteyner runtime doğrudan WSL kernelinde çalışıyor
- Ayrı servis kurmuyorsunuz; WSL zaten Windows’un parçası sayılıyor
- Lisans derdi yok; kurumsal kullanım için ekstra sözleşme kovalamıyorsunuz
- Windows uygulamalarından API ile erişilebiliyor — Docker’da bu Docker Engine API üzerinden REST’ti, burada yerel.NET/C++ çağrısı var
Kurumsal cephede işler nasıl değişiyor?
Burası işin en can sıkıcı ama aynı zamanda en önemli kısmı bence (ben de ilk duyduğumda şaşırmıştım). Türkiye’deki kurumsal müşterilerde son üç-dört yılda aynı senaryoyu defalarca gördüm: Yazılım ekibi Docker Desktop kullanmak istiyor, güvenlik ekibi lisansa takılıyor, satın alma “bu kaça patlar” diye hesap yapıyor; sonuçta ya WSL2 üstüne ham Docker Engine kuruluyor ya da herkes kendi laptopunda farklı bir şeyle idare ediyor.
WSL container bu tabloyu ciddi biçimde değiştirebilir gibi dürüyor. Neden? Çünkü zaten Windows Enterprise lisansınız varsa WSL o paketin içinde geliyor gibi düşününce iş rahatlıyor (evet biraz kaba söyledim ama gerçek bu). Ayrıca konteyner platformu için ayrıca lisans peşinde koşmuyorsunuz. Group Policy ile yönetebiliyorsunuz, Intune ile dağıtabiliyorsunuz. IT departmanının sevdiği türden bütün oyuncaklar burada toplanmış durumda.
Bir şeyi net söyleyeyim: Docker Desktop bitti demiyorum tabiî ki olmaz öyle şey. Docker’ın ekosistemi hâlâ değerli; Docker Hub entegrasyonu var, Compose UI var, image tarama araçları var… Ama “ben sadece konteyner çalıştıracağım, gerisini istemiyorum” diyen kurumsal müşteri için WSL container artık daha temiz bir yol gibi görünüyor.
Küçük ekip mi, büyük kurum mu?
Bunu ayırmadan geçmek olmaz sanırım.
Startup ya da küçük ekipseniz: Docker Desktop’ın ücretli tarafına hâlâ ihtiyaç duyabilirsiniz; Compose UI, Dev Environments veya Docker Scout zaman kazandırıyorsa bedeli çıkarabiliyor açıkçası.
Ama sadece docker run ve docker build
kullanıyorsanız — ki çoğu ekip aslında buna yakın geziyor — WSL container’a geçmek baya mantıklı olabilir.
Kurum içindeyseniz:
Pilot ekip seçin,
üç ay wslc üzerinden yürüyün,
sonra kademeli geçiş yapın.
Docker Desktop lisans yenileme dönemine denk getirirseniz bütçe kalemlerinden biri sessizce kapanabilir.
500-1000 developer olan büyük kurumlarda yıllık maliyet hesabını görünce insanın yüz ifadesi değişiyor;
TL bazında rakam ciddi yerlere gidebiliyor.
WSL container ile o kalem sıfırlanabiliyor.
sAPI tarafı: Asıl ilgimi çeken yer burasıyla başladı yavaş yavaş
CLI güzel tamam da benim gözüm API’ye kaydı doğrusu.
Şöyle bir durum düşünün:
Bir muhasebe uygulamanız var,
tamamen.NET ile yazılmış,
Windows üstünde koşuyor.
Ama vergi hesaplamalarında kullandığınız kütüphane sadece Linux’ta düzgün çalışan,
C ile yazılmış eski bir parça.
Peki şimdiye kadar seçenekler neydi?
- Kütüphaneyi Windows’a taşımaya uğraşmak (uzar gider)
- Ayrı Linux sunucu kurup HTTP üzerinden konuşmak (network overhead + deployment karmaşası) (bu kritik)
- WSL’e komut satırından çağrı yapmak (biraz yamuk dürüyor)
Artık dördüncü seçenek var:
WSL container API.
NuGet paketini alıyorsunuz,
C# kodundan doğrudan Linux konteyner başlatıyorsunuz,
hesaplamayı yaptırıp sonucu geri alıyorsunuz.
Süreç uygulamanın içine giriyor;
arada ekstra servis dönmüyor.
API’nın MSBuild ve CMake entegrasyonu,
konteyner build adımlarını uygulama build sürecine katmanıza izin veriyor.
Yanı
.NET build </dev/null>
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
4 comments