Jak Docker Engine na WSL2 zastąpił Docker Desktop w Prescient

Docker Desktop i środowisko Windows

W dobie ciągłego rozwoju rynku IT rośnie popularność usług opartych na mikroserwisach, konteneryzacji i orkiestracji. Coraz więcej firm buduje model przedsiębiorstwa w oparciu o te usługi, dostosowując również środowiska lokalne, jak i dodatkowo wspiera działy odpowiedzialne za prawidłowe dostosowanie tego środowiska.

Wygodnym rozwiązaniem, które w szybki sposób umożliwia rozpoczęcie pracy z wdrażaniem konteneryzacji aplikacji jest oprogramowanie Docker Desktop. Oprogramowanie to przeznaczone jest m.in. dla systemu operacyjnego Windows, a jego główną zaletą jest zintegrowany instalator, który w ciągu kilku sekund konfiguruje wszystko, czego potrzebujemy do pełnego korzystania z platformy Docker.

Zmiana warunków umowy subskrypcji dla Docker Desktop

Prawdopodobnie każdy, kto porusza się w świecie IT, odebrał w 2021 roku wiadomość, która zawierała informacje o zmianie warunków umowy subskrypcji licencyjnej dla oprogramowania Docker Desktop. Zmiana ta opisywała szereg nowych zastosowań licencyjnych, m.in:

• Docker Desktop pozostaje bezpłatny dla małych firm (mniej niż 250 pracowników oraz poniżej 10 milionów dolarów rocznych przychodów firmy), użytku osobistego, edukacji i niekomercyjnych projektów open source.
• Wymaga płatnej subskrypcji (Pro, Team lub Business) za jedyne 5 USD za użytkownika miesięcznie, do użytku profesjonalnego w większych firmach.
• Data wejścia w życie nowych warunków licencyjnych to 31 sierpnia 2021 r. Dla osób, które będą korzystały z płatnej subskrypcji Docker Desktop, obowiązuje okres karencji do 31 stycznia 2022 r.
• Subskrypcje Docker Pro, Docker Team i Docker Business obejmują teraz komercyjne wykorzystanie Docker Desktop.

Wyżej wymieniony komunikat o wprowadzeniu płatnego rozwiązania spowodował chęć wprowadzenia alternatywnego podejścia. Kiedy na horyzoncie pojawiła się opcja przetestowania Docker Engine bezpośrednio w środowisku WSL2 (Windows Subsystem for Linux), zrezygnowaliśmy z wdrażania rozwiązania opartego o WSL1. Powodem był fakt, że WSL2 posiada własną wersję jądra, natomiast WSL1 jest kompatybilny z jądrem Linuxa.

Przygotowanie środowiska – jak się to odbywało

Podczas prób testowania środowiska za pomocą skryptów powershellowych pojawiły się różne problemy. Poniżej opisaliśmy najczęściej występujące oraz przedstawiliśmy działania, które pomogły nam je rozwiązać.

Głównym problemem był brak kompatybilności Docker Engine z wersją Windowsa oraz jego aktualizacjami, które powodowały brak możliwości zainstalowania jądra Linux w wersji >= 5.10. Brak odpowiedniego builda Windowsa, skutkował także komunikatem: “The term ‘C:\Program Files\Docker\Docker\Docker Desktop Installer.exe’ is not recognized as the name of a cmdlet”, który także uniemożliwiał uruchomienie skryptu.

Aby rozwiązać ten problem, musieliśmy podjąć następujące kroki:

Aktualizacja komponentów Windowsa i weryfikacja Windows build

Version 1903 or higher, with Build 18362 or higher.

Po weryfikacji wersji builda, dodatkowo instalowaliśmy także komponenty Windowsa. W tym celu uruchamialiśmy polecenie – Check online for updates from Microsoft Update. Dzięki ww. krokom mogliśmy przejść do dalszego wdrażania.

Instalacja WSL2 na dystrybucji Ubuntu 20.04 LTS

PS C:\> wsl –unregister Ubuntu
PS C:\> Disable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux

W tym momencie po poprawnej instalacji pojawił się kolejny problem. Część użytkowników miała zainstalowaną już jakąś wersję Ubuntu na silniku WSL1. Aby rozwiązać ten problem dopisaliśmy do skryptu linię –set-default Ubuntu 2, dzięki czemu nasza instalacja startowała z defaultu w odpowiednim środowisku.

cmd
C:\> shutdown /r -t 00
PS C:\> wsl –install
PS C:\> wsl –set-default Ubuntu 2
C:\> shutdown /r -t 00

Wersja jądra>= 5.10

Weryfikację jądra przeprowadziliśmy poprzez zastosowanie polecenia:

PS C:\> bash -c “uname –r”

Wdrożenie

Po wdrożeniu ww. składników przystąpiliśmy do instalacji niezbędnych narzędzi umożliwiających wdrożenie Docker Engine wewnątrz dystrybucji Ubuntu 20.04 LTS z poziomu konsoli PowerShell za pomocą oprogramowania PDQ.

Uśpienie Ubuntu

PS C:\> Start-sleep -s 120
PS C:\> Stop-Process -Name “ubuntu”

W tym kroku pojawiał się ekran nowo zainstalowanej dystrybucji Ubuntu z możliwością utworzenia usera. Ten krok został przez nas pominięty ze względu na to, że użytkowników tworzyliśmy w samym WSL, na późniejszych etapach instalacji. Dodatkowo utworzenie usera w tym punkcie uniemożliwiłoby dalszą instalację komponentów.

Instalacja Basha na Windows

PS C:\> Install-PackageProvider -Name NuGet -Force
PS C:\> Install-Module -Name Bash –Force

Instalacja dockera na WSL2

PS C:\> bash -c “sudo apt-get update; sudo apt-get install apt-transport-https ca-certificates curl gnupg lsb-release -y; curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg –dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg –yes; echo ‘deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu focal stable’ | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null; sudo apt-get update; sudo apt-get install docker-ce docker-ce-cli containerd.io -y”

Autorunning usługi docker i dopisanie profilu do autostartu

PS C:\> bash -c “echo ‘sudo service docker start’ >> ~/.profile”

Dodatkowe instalacje na potrzeby firmy

Na potrzeby firmy instalowane również był następujące komponenty:

Instalacja Azure CLI

PS C:\> bash -c “sudo apt-get update; curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash”

Instalacja kubectl

PS C:\> bash -c “curl -LO https://dl.k8s.io/release/v1.23.0/bin/linux/amd64/kubectl”
PS C:\> bash -c “sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl”
PS C:\> bash -c “rm kubectl”

Instalacja minikube

PS C:\> bash -c “curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64”

PS C:\> bash -c “sudo install minikube-linux-amd64 /usr/local/bin/minikube”

Podsumowanie

Wdrożenie Docker Engine na platformie WSL2 przyniosło korzyści w dwóch wymiarach. Po pierwsze – optymalizację pracy naszych zespołów developerskich i wspierających działów DevOps IT. Po drugie – obniżenie kosztów narzędzi, których używamy w procesie rozwoju oraz dostarczania oprogramowania, dzięki uniknięciu dodatkowych kosztów związanych z nowym modelem licencyjnym Dockera.

Developerzy mogą m.in. pushować/pobierać obrazy, wdrażać aplikacje oraz łączyć się za pomocą azure cli do usług chmurowych. Zespół DevOps może korygować, pomagać przy części prac w środowisku developerskim i odczytywać logi z podejmowanych przez developerów działań. Dzięki pełnej automatyzacji i oskryptowaniu całości projektu, dział IT może w szybki i łatwy sposób dokonywać nowych instalacji środowiska na sprzętach developerskich oraz korygować błędy, które mogą się pojawiać podczas wdrożenia.

Mamy nadzieję, że nasze wdrożenie pomoże dostrzec wielkie możliwości, jakie niesie za sobą WSL2 i odpowiednia konfiguracja komponentów na nim działających. Liczymy też, że w jakikolwiek sposób udało się nam przetrzeć szlak i wyjaśnić pewne kwestie sporne, aby podobne tego typu wdrożenia obyły się bez problemów, z którymi musieliśmy się zmierzyć.

Autorzy: Jan Dulęba, Adrian Manikowski