Webdev like a boss - programujemy używając Windows Subsystem for Linux

Webdev like a boss - programujemy używając Windows Subsystem for Linux

Microsoft robi co się da, aby dla programistów technologii innych niż .NET system Windows nie był jedynie systemem do oglądania filmów, ale też pełnoprawnym środowiskiem pracy. Jednym z kroków do osiągnięcia tego celu było wprowadzenie w systemie Windows 10 czegoś, co oficjalnie nazywa się Windows Subsystem for Linux (WSL). W dzisiejszym poście zobaczymy, jak korzystając z powłoki Bash uruchamianej na Ubuntu uruchomionym na Windowsie (gaddemyt) można tworzyć aplikacje webowe.

Ciężkie życie programisty na Windowsie

Programowanie i Windows? Zapomnij.

Nie, to nie jest post w tych klimatach. Jeśli pracujesz w technologiach około-.NETowych, to właściwie nie ma powodu żeby interesować się systemami innymi niż Windows. Wszystko jest skrojone na miarę i działa tak, jak powinno. Nie ma co rozdmuchiwać problemu, ale jest małe ale…

Przez długi czas Linux (Unix) był systemem, który jednoznacznie kojarzył się z dobrą architekturą i niezawodnością. Ogromna liczba serwerów i baz danych stawianych na tym właśnie systemie nie jest przypadkiem. Windows był wszystkim, tylko nie systemem dla power-userów. Dobry do pooglądania filmów, do przeglądania internetu czy edycji dokumentów, ale na pewno nie do programowania. Zbyt dużo niespodzianek, zbyt mało jakości.

Wpływ takiego spojrzenia na system operacyjny Microsoftu widać dokładnie wśród programistów. Jeśli decydujesz się na C# lub coś innego związanego z .NETem, to typową ścieżką jest właśnie Windows, Visual Studio, może Azure i MSSQL. Tutaj wszystko działa tak jak powinno. Jeśli jednak programujesz w Railsach, Node.js’ie albo innej nie-microsoftowej technologii, to laptop z Windowsem wielu wprawia w osłupienie – jak tak można?

No niestety, ekosystem niektórych technologii często opiera się o komendy i programy których nie znajdziemy w Windowsie. Poza tym, niektóre języki tak jak Ruby przez długi czas nie były zbyt chętne na integrowanie się z Windowsem (uruchomisz, ale oczekuj nieoczekiwanego), więc środowisko po prostu odradzało ten system i kierowało zainteresowanych na Linuxy i macOS’y – cross-platform nie był celem samym w sobie, zamiast tego preferowano stabilność i niezawodność. Wiele rozwiązań tworzonych w oparciu o środowisku unixowe przepisano na Windowsa w sposób który pozostawia wiele do życzenia. Stąd jeszcze kilka lat temu mocno wierzono w przekonanie, że Windows i programowanie nie idą ze sobą w parze.

Na szczęście czasy się zmieniają, strategia Microsoftu także, a efektem tego jest dzisiejszy temat – Windows Subsystem for Linux (WSL).

Na czym rzecz polega

Technologia o której dzisiaj mowa została po raz pierwszy zaprezentowana podczas zeszłorocznej konferencji Build organizowanej przez Microsoft, gdzie prawie zwaliła z nóg wszystkich obecnych na sali. Czym ona tak naprawdę jest?

Aby zrozumieć model jej działania, trzeba dowiedzieć się więcej o komponentach które wchodzą w jej skład:

  • Pico Procesy – to funkcjonalność nad którą Microsoft pracował już w 2011 roku i która stanowi fundament Windows Subsystem for Linux. Została ona opracowana z myślą o tym, żeby w łatwy sposób uruchamiać aplikacje przeznaczone na systemy operacyjne inne niż np. Windows 10, bez użycia technologii pokroju maszyn wirtualnych. Jest to możliwe przez to, że dzięki wprowadzeniu abstrakcyjnej warstwy komunikacji dany Pico Proces nie odwołuje się bezpośrednio do jądra danego systemu operacyjnego, tylko korzysta z dedykowanych dla danej platformy sterowników (które implementują potrzebny takiej aplikacji interfejs).
  • Sterowniki – ogromną zaletą WSL jest używanie oryginalnych, natywnych binarek linuxowych – nie ma tutaj mowy o portowaniu rozwiązań, przepisywaniu ich czy wirtualizacji. Aby jednak dało się je uruchomić na Windowsie, musi istnieć sposób na zastąpienie odwołań do kernela Linuxa czymś innym – w tym przypadku niczym innym jak kernelem Windowsa. Za przechwytywanie odwołań i tłumaczenie zapytań do kernela odpowiadają sterowniki stworzone właśnie na potrzebę WSL – lxss.sys i lxcore.sys.
  • Usługa LXSS Manager – poza pico procesami i sterownikami które umożliwiają uruchamianie konkretnych programów i narzędzi, istnieje jeszcze jeden klocek odpowiadający za kontrolowanie całego tego przedsięwzięcia. Usługa LXSS Manager Service to pośrednik pomiędzy światami Windowsa i Linuxa, który odpowiada za komunikację pomiędzy procesami, synchronizację oraz kontrolę całego cyklu życia instancji linuxowej.

Do tego dochodzą jeszcze dwa systemy plików, które razem składają się na tzw. Virtual File System, którego jedna część jest odpowiedzialna za dokładne odwzorowanie systemu plików linuxa (hierarchia plików, symlinks, wsparcie dla znaków które na Windowsie nie mogą się znajdować w nazwach plików, czy praca w trybie case-sensitive), a druga odpowiedzialna jest dostarczenie “interoperatywności” ze światem Windowsa – w tym systemie plików wszystko musi spełniać normy znane z OSa firmy Microsoft.

W dokumentacji którą możemy odnaleźć na stronach Microsoftu, całość prezentuje się następująco:

WSL Overview – https://blogs.msdn.microsoft.com

Pomimo tego, że nigdy nie zajmowałem się programowaniem systemów operacyjnych, to architektura tego rozwiązania jest zaskakująco zrozumiała. Zapewne wewnętrzna implementacja mogłaby wielu z nas przyprawić o bóle głowy, jednak zrozumienie tematu na wysokim poziomie jest możliwe i w pewnym sensie tłumaczy to, z czym będziemy zaraz pracować.

Czas na zobaczenie tego wszystkiego na własne oczy!

Developer mode i włączenie WSL

Aby mieć możliwość włączenia usługi WSL na naszym komputerze z systemem Windows 10, musimy zacząć od przejścia w tryb developera. Zrobimy to z poziomu ustawień (Ustawienia / Aktualizacje i zabezpieczenia / Dla deweloperów):

Teraz przechodzimy do Panelu Sterowania, a konkretnie szukamy opcji Włącz lub wyłącz funkcje systemu Windows (Panel Sterowania / Programy). Po kliknięciu ukaże nam się okienko z listą usług, które możemy dodać lub usunąć. Szukamy pozycji Podsystem Windows dla systemu Linux, włączamy ją i czekamy na dokończenie procesu instalacji:

Usługa została dodana, ale od rozpoczęcia korzystania z WSL dzieli nas jeszcze jeden krok – musimy ją jawnie uruchomić z poziomu np. Powershella, wpisując tam komendę bash. Zostaniemy poinformowani, że usługa ta wciąż jest w fazie beta, ale godzimy się na to i czekamy na dokończenie instalacji. Po wszystkim możemy wpisać tę komendę raz jeszcze aby przeskoczyć do powłoki Bash (już na Ubuntu):

No dobra, tyle o instalacji – czas żeby zobaczyć po co to wszystko.

Narzędzia dostępne od ręki

Jest wiele powodów żeby zdecydować się na WSL – pierwszym z nich jest możliwość używania narzędzi, które do tej pory nie były dostępne na Windowsie, bądź miały nie do końca działające alternatywy.

Weźmy pierwszy z brzegu przykład z którym zderzyłem się osobiście – w świecie JavaScriptu istnieje znakomite narzędzie nvm umożliwiające zarządzanie wieloma wersjami Node’a na jednej maszynie. Jak wygląda instalacja jeśli masz pod ręką powłokę bash?

Jak wygląda instalacja na Windowsie?

Note: nvm does not support Windows (see #284). Two alternatives exist, which are neither supported nor developed by us

Hmm… no to zobaczmy, jak sprawdza się alternatywa dostępna na Windowsie – oczywiście spodziewam się takiej samej palety możliwości. Przykładowo, dzięki nvm i użyciu pliku o nazwie .nvmrc możemy zdefiniować, jaka wersja Node’a jest kompatybilna z danym projektem. Zawartość takiego pliku to jedna linijka, np.

Jeśli używamy konsoli i znajdujemy się w miejscu gdzie zdefiniowano plik .nvmrc to w szybki sposób możemy przeskoczyć / zainstalować poprawną wersję naszego środowiska (tutaj macOS):

Pobieram więc repozytorium tego samego projektu na Windowsie, i wykonuję tę samą komendę:

Alternatywa nie działa do końca tak jakbym się spodziewał. Nie chodzi mi tutaj w żadnym wypadku o wytykanie błędów autorowi (większość komend działa tak jak w oryginalnym nvm), ale ta konkretna komenda nie jest zaimplementowana poprawnie. Co prawda mogę teraz spędzić godziny na szukaniu odpowiedzi na GitHubie, jednak w tym cały sęk pracy z takimi narzędziami na Windowsie – projekt czeka, a ja walczę z komendami które nie działają tak jak w oryginale.

Zobaczmy teraz, jak dzięki Windows Subsystem for Linux możemy sobie oszczędzić takich problemów.

Dwa środowiska – ten sam projekt

Pracować będziemy w oryginalnej unixowej powłoce bash, która po włączeniu WSL będzie dostępna z poziomu menu Start:

Po jej uruchomieniu znajdziemy się w katalogu domowym naszego linuxowego użytkownika, ale my chcemy dostać się do plików które znamy z Windowsa – czy to możliwe?

Na szczęście tak! Dyski i partycje, a tym samym i pliki z którymi pracowaliśmy do tej pory dostępne są w katalogu /mnt które w systemach z rodziny unix służy właśnie do montowania dysków i urządzeń zewnętrznych.

Przejdźmy więc do naszej lokalizacji z plikiem .nvmrc, czyli D:/Dev i spróbujmy zainstalować “tę właściwą” wersję nvm:

W tym miejscu wykonujemy polecenie z instrukcji tak jakbyśmy pracowali na Linuxie, czyli:

Czekamy na zakończenie instalacji, a następnie próbujemy wykonać to do czego byliśmy przyzwyczajeni do tej pory:

Wygląda na to, że działa! Zainstalowaliśmy linuxową wersję nvm’a, kontekst Node.js’a został ustawiony poprawnie używając pliku .nvmrc, a pracujemy wciąż nad projektem który znajduje się partycji Windowsowej. Nic nie stoi na przeszkodzie, żeby uruchomić teraz swój ulubiony edytor i rozwijać kod np. w VS Code:

Mind. Blown.

Pierwszy projekt przy pomocy WSL

No dobra, jedno narzędzie być może nie robi was dużego wrażenia. Mam nadzieję, że wrażenie zrobi projekt który zaraz utworzymy, a następnie uruchomimy z poziomu Linuxa i dostaniemy się do niego z poziomu przeglądarki Chrome. Przydałoby się wybrać coś, co niekoniecznie kojarzy się z Windowsem – może okolice Ruby? Rails? Nie… zbyt popularne.

Co powiecie na stack Elixir/Phoenix w którym stworzymy aplikację webową?

Brzmi dość hipstersko, więc warto spróbować.

Instalację zaczynamy od zainstalowania Elixira, czyli języka programowania, a później zainicjalizujemy nowy projekt we frameworku Phoenix. Instalacja Elixira na Ubuntu wg dokumentacji odbywa się w sposób następujący:

Wracamy więc do basha, wykonujemy powyższe instrukcje (mija kilkanaście minut instalacji) i sprawdzamy na którym systemie zainstalowały się nowe zabawki (powyżej Linux, poniżej Windows):

Jest dobrze – elixir jest dostępny na środowisku linuxowym, a Windows o tym co robimy nie ma pojęcia. Teraz przechodzimy do instalacji frameworka Phoenix – krok po kroku opisanej tutaj. Podążamy krokami wg instrukcji, instalujemy przy okazji PostgreSQL z tej instrukcji, i po wszystkim uruchamiamy nasz projekt poleceniem:

Jeśli wszystko poszło dobrze, to – jeszcze raz przypominam, pracując na Windowsie, z Elixirem i PostgreSQL zainstalowanymi na Ubuntu – wchodząc na localhost:4000 zobaczymy główną stronę naszej aplikacji:

Ubuntu może współdzielić porty z Windowsem, w efekcie czego do wszystkiego co serwujemy z WSL możemy się dostać przez localhost, albo iść krok dalej i wystawić daną usługę na świat. Reakcja może być tylko jedna:

Tego brakowało na Windowsie!

Jeśli do tej pory pracowałeś na Ubuntu/macOS, to możesz nie doceniać wartości tego czym jest Windows Subsystem for Linux, jednak dla posiadaczy Windowsa może to być rewolucja.

W końcu pojawiła się możliwość na połączenie potrzeb zwykłego konsumenta z potrzebami programisty. Z jednej strony nie muszę rezygnować z aplikacji takich jak pakiet Office czy Adobe Photoshop, a z drugiej dostaję basha, unixowe komendy i zestaw narzędzi których mi, programiście, zawsze brakowało. Szczerze mówiąc wciąż nie dowierzam, że to prawda.

Cała usługa wciąż jeszcze jest w fazie beta, jednak z każdą kolejną aktualizacją Windowsa staje się ona bardziej stabilna i gotowa do sprostania kolejnym wyzwaniom. Ja w trakcie pisania tego posta czekałem, aż w końcu coś się posypie i będę musiał wymyślać nowy temat, ale się nie doczekałem. Byłem zaskoczony jak mało problemów pojawiło się w trakcie instalacji kolejnych paczek (brak), instalacji Elixira i Phoenixa (brak), czy inicjalizacji PostgreSQL (drobne problemy z uprawnieniami, które wg StackOverflow występują również na “normalnych” Linuxach). Jeśli jednak jakiś problem występował, to walczyłem z nim jakbym miał przed sobą Ubuntu i komputer z Linuxem, a nie coś co jedynie udaje inny system operacyjny. Wszystko co ktoś rozwiązał i opisał na https://askubuntu.com/ miało też zastosowanie u mnie.

Jestem naprawdę pozytywnie zaskoczony, a kupno laptopa które mam przed sobą stało się jeszcze trudniejsze 😉 Czy wy mieliście już okazję spróbować Linuxa na waszych Windowsach? Jak wrażenia – czy mieliście jakiś problem który był spowodowany wczesną wersją tej usługi? Podzielcie się wrażeniami w komentarzach i do następnego!

Dla zainteresowanych – blog poświęcony WSL na podstawie którego został przygotowany ten post znajduje się tutaj – https://blogs.msdn.microsoft.com/wsl/

  • Bardzo ciekawy wpis. Do tej pory nie słyszałem o Windows Subsystem for Linux, więc dobrze, że o tym napisałeś. Zanotowane i kiedyś może się przyda 🙂

    Nie zgodzę sięjednak, że przyczyną dla jakich Windows nie jest używany przez nie-.NET’owców jest brak “stabilność i niezawodność”. Jak sam napisałeś to różne narzędzia programistyczne są niedopracowane, niestabilne, ale trudno winić za to systemoperacyjny jako taki. Bo idąc tym tokiem rozumowania Linux jest niestabilny i zawodny bo nie mogę tam odpalić Visual Studio itp.

    • Przemek Smyrdek

      Masz rację – ale też zgodzisz się ze mną, że Windows wciąż walczy o swoją reputację systemu na którym programista zrobi swoje. Widać to po krokach Microsoftu, widać to po UserVoice tej firmy gdzie ludzie wciąż skarżą się na małe głupotki, itd. Jest lepiej, ale to jeszcze nie jest industry standard.

      • Zgadzam się, że Microsoft otwiera się coraz bardziej i stara się przyciągać programistów innych niż .NET I to krok wbardzo dobrą stronę. Kiedyś, ba kilka lat temu, byłoby to nie do pomyślenia.

        Zastanawiam się jednak co masz na myśli przez “industry standard”. Bo na przykład narzędzia dla programistów od Microsoft’u są moim zdaniem bardzo dobre (w szczególności dla .NET ale nie tylko) i to inni mogli by się od nich uczyć.

        Dla przykładu z tego co wiem taki Ruby do tej pory nie dorobił się debugger’a z prawdziwego zdarzenia i wiele osób stosuje technikę debugowania pod tytułem “wypisz na ekran”. I nie jest to bynajmniej moje spostrzeżenie, ale kolegi który na co dzień robi w Ruby.

        • Przemek Smyrdek

          Pisząc o “industry standard” mam na myśli status Windowsa jako podstawowego narzędzia pracy programisty, systemu na którym po prostu “się da” niezależnie w czym działasz. Oczywiście wiem, że to wszystko jest względne i zależy od tego skąd patrzysz na daną sprawę. Ja być może jestem skrzywiony bo zawsze kręciłem się wokół front-endu i laptop z Windowsem niejednego dziwił (czy nie mam problemów, jak to działa, co mogę robić na tym itd.). I wiem też, że z roku na rok jest lepiej – nie tylko z punktu widzenia software’u, ale też hardware’u który Microsoft wypuszcza.

          A propos Ruby to jest coś takiego jak RubyMine – Railsowcy mają możliwość debugowania kodu dzięki temu IDE w lepszy sposób niż wypisywanie na ekran 😉