29 czerwca 2026 Microsoft udostępnił public preview WSL Containers, czyli nowej warstwy do budowania, uruchamiania i zarządzania kontenerami Linuksa bezpośrednio przez Windows Subsystem for Linux. To nie jest kolejna dystrybucja w WSL ani prosty wrapper na istniejący Docker Desktop. W wydaniu WSL 2.9.3 pojawił się nowy binarny interfejs wslc.exe, alias container.exe oraz API dla aplikacji Windows, które chcą programowo używać kontenerów Linuksa.
Dla administratorów, DevOpsów i zespołów developerskich jest to ważny sygnał: kontenery Linuksa przestają być na Windowsie wyłącznie domeną zewnętrznych narzędzi desktopowych. Microsoft buduje natywną ścieżkę, w której hostem użytkownika pozostaje Windows 11, ale workflow aplikacyjny nadal opiera się o obrazy, procesy, porty, wolumeny i ograniczenia zasobów typowe dla świata Linux/Unix-like. Funkcja jest w public preview, więc nie powinna bezrefleksyjnie trafiać do krytycznych pipeline’ów, ale już teraz warto ją przetestować w labie, szczególnie tam, gdzie flota developerska pracuje na Windowsie, a produkcja działa na Linuksie lub Kubernetesie.
Co dokładnie zostało wydane 29 czerwca 2026
Public preview WSL Containers jest częścią pre-release WSL 2.9.3. Po aktualizacji pojawia się narzędzie wslc.exe, którego składnia ma być znajoma dla osób pracujących z kontenerami. Microsoft opisuje dwa główne komponenty: CLI do lokalnego workflow oraz API, dzięki któremu aplikacje Windows mogą tworzyć sesje, pobierać obrazy, uruchamiać kontenery i komunikować się z procesami Linuksa.
Zakres funkcji w WSL 2.9.3 jest zaskakująco szeroki jak na preview. Release notes wymieniają obsługę cyklu życia kontenera, obrazów, sieci, wolumenów, GPU, sesji, logów, statystyk, integrację z MSBuild i CMake oraz wsparcie dla polityk grupowych ADMX. To oznacza, że Microsoft nie pokazuje tylko prostego run ubuntu, ale próbuje wprowadzić kompletny lokalny runtime dla typowych scenariuszy developerskich.
- Kontenery: tworzenie, uruchamianie, start, kill, export, prune, inspect oraz limity
--cpus,--memory,--ulimiti--shm-size. - Obrazy: build, pull, push, import, save, inspect, listowanie, czyszczenie i usuwanie wielu obrazów.
- Sieć: tworzenie sieci, aliasy, publikowanie portów, podłączanie do wielu sieci i tryb
container:<name|id>. - Wolumeny: tworzenie, listowanie, czyszczenie i usuwanie wolumenów, w tym wolumeny oparte o VHD.
- GPU: kontenery GPU przez CDI, z dostępem do bibliotek i narzędzi GPU również dla procesów nierootowych.
- Enterprise: ADMX/GPO, zapowiedziana obsługa w Intune oraz prywatny preview zdarzeń kontenerów w Microsoft Defender for Endpoint.
Dlaczego to ma znaczenie dla pracy z Linuksem
WSL od lat rozwiązuje problem „Linuxowego userspace’u na laptopie z Windowsem”. Administrator może uruchomić Ubuntu, Debiana czy Fedorę, używać ssh, rsync, bash, systemd i narzędzi chmurowych bez przesiadania się na maszynę wirtualną. WSL Containers przesuwa ten model o poziom wyżej: zamiast traktować dystrybucję WSL jako środowisko robocze, można traktować WSL jako lokalną warstwę kontenerową dla obrazów Linuksa.
W praktyce oznacza to mniejszy dystans między laptopem developera a środowiskiem CI/CD. Jeżeli aplikacja jest budowana jako obraz kontenerowy, to lokalny test nie musi zaczynać się od instalowania osobnej platformy desktopowej. Wystarczy pre-release WSL i wslc. Dla organizacji z restrykcjami licencyjnymi, politykami endpointów albo ograniczonym prawem instalowania aplikacji użytkownika może to być istotna zmiana operacyjna.
Nie oznacza to jednak, że Docker Desktop, Podman Desktop czy Rancher Desktop z dnia na dzień tracą sens. Te narzędzia mają ekosystem, GUI, integracje, obsługę Compose, rozszerzenia i przyzwyczajenia zespołów. WSL Containers w wersji z 29 czerwca 2026 należy traktować jako nową platformową warstwę bazową i potencjalnie prostszy runtime dla części workflow, a nie jako natychmiastowy zamiennik całego stosu narzędzi kontenerowych.
Pierwsze testy w labie
Najbezpieczniej zacząć od osobnej stacji testowej albo maszyny deweloperskiej, która nie jest krytyczna dla codziennej pracy. Funkcja jest dostępna w pre-release, więc warto liczyć się z błędami, zmianami składni i ograniczeniami kompatybilności. Instalacja odbywa się przez aktualizację WSL do kanału pre-release albo ręczne pobranie paczki z GitHuba.
wsl --update --pre-release
wsl --version
wslc --version
# test minimalnego kontenera
wslc run --rm -it ubuntu:latest bash -c "cat /etc/os-release && uname -a"
# test prostego serwera HTTP
wslc run -d --rm -p 8080:80 --name web nginx
curl http://localhost:8080
wslc container ps
wslc container stop webTen zestaw poleceń weryfikuje trzy rzeczy: czy wslc znajduje się w PATH, czy runtime potrafi pobrać obraz z rejestru oraz czy publikowanie portu na hosta działa poprawnie. W środowiskach korporacyjnych szczególnie istotny będzie test sieci przez VPN, proxy, inspekcję TLS i firmowe DNS-y. Microsoft wprowadza dla WSL Containers domyślny tryb sieciowy Consomme, którego celem jest lepsze dopasowanie ruchu Linuksa do sieciowego kontekstu Windowsa. To obszar, który warto sprawdzić przed jakąkolwiek standaryzacją.
GPU i lokalne workloady AI
Jednym z najciekawszych elementów WSL Containers jest obsługa GPU. Microsoft w release notes wymienia kontenery GPU z CDI oraz montowanie bibliotek i narzędzi GPU tak, aby były dostępne również dla użytkowników innych niż root. To ważne dla zespołów pracujących z PyTorch, CUDA, inferencją lokalnych modeli, narzędziami testującymi akcelerację albo pipeline’ami ML, które na produkcji i tak zwykle lądują w kontenerach Linuksa.
Przykład testu GPU nie powinien być traktowany jako benchmark. To raczej szybki smoke test: czy kontener widzi akcelerator, czy runtime poprawnie wystawia urządzenie i czy biblioteki użytkownika nie rozjeżdżają się z konfiguracją hosta.
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))"Dla administratora oznacza to konieczność rozszerzenia checklisty endpointowej. Jeśli organizacja pozwala na lokalne kontenery GPU, trzeba wiedzieć, kto może je uruchamiać, z jakich rejestrów mogą pochodzić obrazy, gdzie trafiają dane wejściowe oraz czy logi i zdarzenia bezpieczeństwa są zbierane w taki sam sposób jak dla procesów WSL. Microsoft zapowiada integrację zdarzeń kontenerów z istniejącym pluginem Microsoft Defender for Endpoint dla WSL, ale 29 czerwca 2026 ta część była opisana jako private preview.
Bezpieczeństwo i zarządzanie: najważniejsze różnice względem „zwykłego WSL”
Z punktu widzenia bezpieczeństwa WSL Containers zmienia powierzchnię ataku na stacjach roboczych. Użytkownik może uruchamiać obrazy z rejestrów, montować katalogi, publikować porty, używać sieci i potencjalnie GPU. To są te same pytania, które administratorzy zadają przy Dockerze lub Podmanie, tylko przeniesione do platformowego komponentu Windows/WSL.
W WSL 2.9.3 pojawia się wsparcie dla zarządzania przez Group Policy i ADMX. Microsoft zapowiada także ustawienia Intune pozwalające kontrolować użycie dystrybucji WSL i kontenerów oraz wskazywać allowlistę rejestrów kontenerowych. To bardzo ważne, bo bez polityk organizacyjnych wslc może stać się kolejną ścieżką pobierania niezweryfikowanych obrazów do środowiska firmowego.
Minimalna polityka testowa powinna obejmować co najmniej: listę dozwolonych rejestrów, zasady skanowania obrazów, sposób przechowywania danych w wolumenach, logowanie uruchomień kontenerów, reguły publikowania portów, limity CPU/RAM oraz procedurę czyszczenia obrazów po testach. Warto również wymusić, aby zespoły nie montowały do kontenerów katalogów z sekretami, tokenami chmurowymi i kluczami SSH, jeśli nie ma takiej potrzeby.
Virtiofs, Consomme i pamięć: mniej widoczne, ale ważne zmiany
Najbardziej medialnym elementem jest wslc, ale pod spodem Microsoft wprowadza zmiany, które mogą być ważniejsze dla codziennej wydajności. Dla WSL Containers domyślnym systemem plików ma być virtiofs, a Microsoft deklaruje do dwukrotnie szybszy dostęp do plików Windows. W kontenerowych workflow oznacza to krótsze buildy przy dużej liczbie małych plików, choć realny wynik będzie zależał od projektu, antywirusa, cache i sposobu montowania katalogów.
Drugim elementem jest Consomme, czyli domyślny tryb sieciowy dla WSL Containers. Jego zadaniem jest przekazywanie ruchu Linuksa przez Windows, aby aplikacje linuksowe korzystały z tego samego środowiska sieciowego, polityk bezpieczeństwa i integracji enterprise co aplikacje Windows. To brzmi technicznie mniej efektownie niż GPU, ale w firmach z VPN, ZTNA, proxy i segmentacją sieci może decydować o tym, czy lokalny workflow po prostu działa.
Trzeci element to ulepszone odzyskiwanie pamięci. WSL bywa krytykowany za to, że potrafi zatrzymać dużo RAM-u po intensywnej pracy. WSL Containers ma stopniowo i konsekwentnie oddawać niewykorzystaną pamięć do hosta Windows. Warto sprawdzić to na realnym projekcie: build obrazu, testy integracyjne, uruchomienie większego kontenera bazodanowego, zatrzymanie sesji i obserwacja zużycia pamięci przez kilka minut.
Co warto zrobić praktycznie
WSL Containers nie jest funkcją, którą należy włączyć wszystkim użytkownikom bez planu. Jest jednak na tyle konkretna, że warto przygotować kontrolowany pilotaż. Najlepszy scenariusz to mały zespół developerski pracujący z aplikacją kontenerową, jasny zestaw obrazów testowych i prosta macierz porównawcza: Docker Desktop lub Podman Desktop kontra wslc.
- Wyznacz jedną lub dwie maszyny testowe z Windows 11 i WSL 2.9.3 pre-release.
- Sprawdź pull/build/run dla obrazów używanych w projekcie, nie tylko dla
nginxiubuntu. - Przetestuj sieć przez firmowy VPN, proxy, DNS i publikowanie portów lokalnych.
- Zweryfikuj limity CPU/RAM oraz zachowanie po zatrzymaniu kontenerów i sesji.
- Sprawdź, czy narzędzia bezpieczeństwa widzą procesy, porty i pobrane obrazy.
- Przygotuj politykę rejestrów i zasady przechowywania danych w wolumenach.
Podsumowanie praktyczne: WSL Containers z 29 czerwca 2026 to jeden z najciekawszych ruchów w kierunku natywnego workflow Linux containers na desktopach Windows. Administratorzy powinni potraktować wslc jako realny komponent platformy developerskiej: przetestować wydajność, sieć, GPU i polityki bezpieczeństwa, ale z wdrożeniem produkcyjnym poczekać do stabilizacji poza public preview.
