WSLC Mimarisi: Oturum, Depolama ve Ağ Modeli
WSLC, Windows üzerinde Linux konteynerlerini çalıştıran yeni bir konteyner altyapısı; kullanıma wslc.exe komutuyla açılıyor. Microsoft Command Line ekibinden Pierre Boulay’ın mimari yazısı, platformun klasik WSL’den hangi noktalarda ayrıldığını anlatıyor. Oturumların nasıl oluşturulduğunu, depolama katmanının hangi ilkeller üzerine kurulduğunu ve ağ trafiğinin Windows yığınına nasıl bağlandığını burada özetliyorum. Amaç, WSLC’yi kullanmadan önce “arka planda ne oluyor” sorusuna net bir cevap verebilmek.
Oturum modeli: ayrıcalıklı servis sahipliği bırakıyor
WSL’de olduğu gibi WSLC’de de istemci süreçleri ayrıcalıklı bir Windows servisiyle, yani wslservice.exe ile konuşuyor. Bu servisin HCS üzerinden sanal makine oluşturma ve bu sanal makinelerde Linux iş akışları çalıştırma yetkisi var.
Mimari fark da burada başlıyor: wslservice.exe sanal makinenin sahipliğini üzerinde tutmuyor. Bunun yerine, çağrıyı yapan kullanıcı adına çalışan bir alt süreç oluşturuyor, wslcsession.exe. Konteyner oluşturma, dizin bağlama, ağ portlarını bağlama, bütün oturum işlemlerini kullanıcı adına bu süreç yürütüyor.
Bu modelin iki pratik sonucu var:
- Her oturum farklı bir süreçte yaşadığı için oturumlar birbirinden güçlü biçimde yalıtılıyor.
- Oturum işlemleri
wslservice.exe‘ye kıyasla daha az ayrıcalıklı bir süreçte çalıştığından güvenlik sınırı sağlamlaşıyor.
Yani ayrıcalık gerektiren tek adım sanal makinenin oluşturulması, günlük konteyner işlemleri bu ayrıcalık seviyesinden uzakta kalıyor.
Depolama: oturum VHD’leri, volume’lar ve VHD volume’lar
WSLC, veriyi hem oturum içinde hem de Windows depolama yığınında tutabilmek için birkaç farklı ilkel sunuyor.
Oturum VHD’si
Her WSLC oturumunun kendine ait bir depolama VHD’si var. Mevcut imajlar, konteynerler, ağlar ve volume’lar gibi oturum durumu bu VHD’de saklanıyor. wslc.exe kullanıldığında dosyalar %AppData%\Local\wslc\sessions altında duruyor.
Konteyner volume’ları ve virtiofs
Konteyner volume’ları, veriyi konteynerin scratch alanı dışında saklıyor; o alan konteyner silindiğinde kayboluyor. En basit senaryo bir Windows yolunu konteynere paylaştırmak:
$ wslc container run -v C:\Windows\System32\drivers\etc:/volume -it debian:latest ls /volume
hosts hosts.ics lmhosts.sam networks protocol servicesArka planda bu volume’lar, Linux sanal makinesi içinde virtiofs paylaşımları bağlanarak uygulanıyor ve konteynere sunuluyor. Bağlama noktaları sanal makine içinde /mnt altında oluşturuluyor, ardından konteynere bind mount olarak ekleniyor.
Windows tarafındaki erişim de virtiofs üzerinden. virtiofs, hipervizör ile sanal makine arasındaki birlikte çalışabilirlik için tasarlanmış yüksek performanslı bir dosya sistemi; kaynakta plan9 ile karşılaştırıldığında yaklaşık iki kat daha hızlı olduğu belirtiliyor.
VHD volume’lar
VHD volume’lar, bir Windows yolu yerine VHD tarafından desteklenen özel bir konteyner volume türü. Konteynerin doğal bir Linux dosya sistemine ihtiyaç duyduğu ya da volume boyutuna sınır konulmak istendiği durumlarda işe yarıyor:
$ wslc volume create --driver vhd -o SizeBytes=200000000 my-volumeOluşturulduktan sonra volume, adıyla bir veya birden fazla konteynere bağlanabiliyor:
$ wslc container run -v my-volume:/volume -it debian:latest findmnt /volume TARGET SOURCE FSTYPE OPTIONS /volume /dev/sdf ext4 rw,relatime,stripe=4Çıktıda görüldüğü gibi volume, konteyner içinde ext4 formatlı bir blok cihaz olarak görünüyor.
Ağ: Consommé modeli ve kullanıcı adına çıkan trafik
WSLC ağ bağlantısını Consommé adlı yeni bir ağ modeliyle sağlıyor. Kurgunun hedefi, port eşleme ve host loopback gibi ileri senaryolar için gereken ince kontrolü Linux sanal makinesi üzerinde kurmak, bunu yaparken Windows ağ yığınıyla bütünleşik kalmak.
Modelde Linux sanal makinesinin tüm trafiği ethernet çerçeveleri halinde bir virtio kuyruğuna gönderiliyor, bu kuyruğu da kullanıcı adına çalışan bir Windows süreci okuyor. Söz konusu süreç sanal makineye şu ağ hizmetlerini sunuyor:
- DNS sorgularını yanıtlama
- UDP ve TCP trafiğinin yönlendirilmesi
- Port eşleme (port mapping)
Bu yaklaşımın en önemli avantajı, sanal makineden dışarı yönlendirilen trafiğin WSLC oturumunun sahibi olan kullanıcı adına gönderilmesi. Trafik sıradan bir Windows sürecinden çıkmış gibi aktığı için VPN’ler ve güvenlik duvarlarıyla uyumluluk da geniş oluyor. Kaynakta örnek akış olarak, bir konteynerde nginx çalışırken 8000 numaralı portun konteyner içindeki 80 numaralı porta eşlendiği senaryo gösteriliyor.
Kaynak kodu ve devamı
WSLC açık kaynak. Kodu incelemek, kendi derlemenizi yapmak veya katkıda bulunmak için microsoft/WSL deposuna bakabilirsiniz. Özelliğin genel kullanıma sunulmasına dair duyuru ise Windows Developer blogunda.
Kaynaklar ve İleri Okuma
- WSLC Architecture deep dive — Pierre Boulay, Windows Command Line
- WSL containers now generally available — Windows Developer Blog
- microsoft/WSL GitHub deposu
- Windows Command Line blogu
- WSL Container Public Preview: Windows’ta Linux Konteyner Devri
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.
Yorum gönder