Kotrak Software w kontenerze

Rok 2018 był dla nas przełomowy pod względem technologicznym. Nowy, ogromny projekt oraz nowe wymagania – wszystko to poprzedzone Proof Of Concept. Pozwoliło nam to na gruntowne przeglądanie naszego podejścia do systemów oraz technologicznego „stacku”, którego do tej pory używaliśmy. My, młodzi adepci Domain-Driven Design, ostatecznie otrzymaliśmy możliwość zamodelowania całego systemu. Przyklejaliśmy kolorowe karteczki na Event Stormingach, powstawały kolejne serwisy w nowiuśkim ASP.NET Core, a Angular wybijał się na czoło całej grupy. Świat stał przed nami otworem. Ale do pełni szczęścia brakowało nam tylko jednego – KONTENERA.

Docker (o którym będziemy mówić) już wtedy był niekwestionowanym liderem. Na każdej większej konferencji poruszano temat Dockera i konteneryzacji. Wręcz dało się odczuć, że nie jest to nowy trend, lecz standard, który zmienia całe IT. Firmy nie pytały „czy potrzebujemy tego?”, lecz mówiły „musimy to mieć”. Podobnie było i z nami. Jeszcze nie bardzo wiedzieliśmy, co z tym zrobić, ale chcieliśmy to jakoś ogarnąć – wzbogacić portfolio, poszerzyć kompetencje. Warto tutaj w skrócie wyjaśnić, o co chodzi z tą konteneryzacją.

Prawdopodobnie większość osób wie, co to jest Maszyna Wirtualna – piaskownica, w której instalujemy różne rzeczy, testujemy i modyfikujemy do woli, która w żaden sposób nie wpływa na stabilność naszego systemu operacyjnego – dosłownie, taki drugi wewnętrzny system operacyjny z własnym stanem. Ja, starzejący się wyga programowania, doskonale pamiętam (nie tak odległe) czasy, gdy na dyskach albo pendrivach kopiowało się maszyny wirtualne z przygotowanymi środowiskami deweloperskimi. Był tam cały zestaw narzędzi i aplikacji, wszystko skonfigurowane i gotowe do użycia. Wystarczyło tylko uruchomić VirtualBoxa. Oczywiście, miało to swoje minusy. Taka maszyna zajmowała sporo miejsca i uruchamiała się wolno. Dodatkowo, ponieważ mieliśmy „pod spodem” pełnoprawny system operacyjny, zajmował też odpowiednio dużo procesora i pamięci RAM. Tutaj pojawiła się idea kontenerów – „sandbox” uruchamiany niezależnie od systemu operacyjnego, który współdzieli jego zasoby (tak jak inne aplikacje), ale w przeciwieństwie do maszyny wirtualnej posiada minimalny zestaw funkcji i bibliotek potrzebnych do uruchomienia, dzięki czemu można go szybko uruchomić i tak samo szybko „zabić”.

Źródło: https://www.atlassian.com/pl/microservices/cloud-computing/containers-vs-vms

Docker był odpowiedzią na wiele problemów przeszłości. Prostsza instalacja i „orkiestracja” aplikacji. Kontener posiada cały zestaw potrzebnych SDK, nic nie trzeba instalować. Dodatkowo, ten sam obraz mogę użyć zarówno produkcyjnie, jak i do lokalnych testów, zawsze mając pewność, że wszystko jest skonfigurowane tak samo. Dodatkowo, Docker pilnuje za mnie stanu aplikacji – jeśli jakiś kontener przestanie działać, automatycznie go restartuje, a cały system wraca do poprawnego działania. Docker pozwala na tworzenie obrazów zarówno dla Windowsa, jak i dla Linuxa. Ze względu na brak dobrej znajomości Linuxa oraz wygodę (większość z nas jednak używa Windowsa), oczywistym wyborem był dla nas Windows. Dodatkowo wspomniany wcześniej klient dysponował swoimi własnymi środowiskami on-premise również na Windowsach (wtedy Windows Server 2016, a chwilę później 2019).

Skrupulatnie zaczęliśmy przygotowywać Dockerfile’e dla każdego serwisu. Zbudowane obrazy Dockerowe przechowywaliśmy w naszym lokalnym repozytorium, a następnie publikowaliśmy wersje na oficjalnym Docker Hubie, gotowe do wdrożenia na produkcję. Pierwszym poważnym „zgrzytem” były wersje Windowsa. Windows Server 2016 wymagał, aby obrazy bazowały na nanoserver-sac2016, a Windows 2019 na nanoserver-1809. Samo to wymagało utrzymywania dwóch zestawów obrazów, co wpływało zarówno na ilość przechowywanych danych, jak i na czas „ciągłej integracji”, nie wspominając już o testowaniu. Dodatkowo pojawiła się prośba o przygotowanie koncepcyjnego środowiska Linuxowego – kolejny, trzeci typ obrazów (na szczęście maszyny Linuxowe były w stanie uruchamiać różne wersje obrazów bazowych).

Przyszedł czas na próbę generalną w 2019 roku. Pierwsze uruchomienia produkcyjne na mniejszych fabrykach zakończyły się sukcesem. Jednak z czasem na jednym ze środowisk pre-prod natrafiliśmy na dziwny problem z wewnętrzną podsiecią Dockera – kontenery nie potrafiły się komunikować między sobą. W systemie rozproszonym, składającym się z kilkunastu serwisów, jest to jednym słowem tragedia. Po długiej analizie różnych podobnych zgłoszeń, czy to na GitHubie czy na StackOverflow, okazało się, że winowajcą jest poprawka KB Windowsa. Przygotowaliśmy zapasowe rozwiązanie z hostingiem opartym o IIS. Używaliśmy modelu hybrydowego. Na środowiskach, gdzie to było możliwe, był Docker, na innych zaś IIS. Gwoździem do trumny był oficjalny komunikat, jaki dostaliśmy od Microsoftu podczas jednego ze spotkań: „Microsoft nie zaleca używania Dockera produkcyjnie na Windowsie”.

To był definitywny koniec Dockera w tym projekcie (w tamtej chwili). Jeszcze przez jakiś czas część środowisk pracowała na Dockerze, ale wszystkie nowe uruchomienia były oparte o IIS, a z czasem stare środowiska też zostały zmigrowane. Ślad po Dockerze pozostał tylko w skryptach i na kilku środowiskach testowych.

Nie zniechęciliśmy się tą porażką i wyciągnęliśmy wnioski. Znaliśmy plusy konteneryzacji, poznaliśmy też minusy. Sukcesywnie Docker pojawiał się w nowych projektach, oswoiliśmy się z Linuxem, zaczęliśmy odpowiednio rozwijać też naszą infrastrukturę i zaczęliśmy klientom oferować rozwiązania Linuxowe tam, gdzie to było możliwe.

W 2022 roku, naturalną koleją rzeczy, zaczęliśmy inwestować siły w Kubernetesa. Potężną platformę, której tylko małym wycinkiem jest konteneryzacja i obrazy Dockera. Oczywiście i tutaj było wiele przeszkód. Nie pomagało też to, że Kubernetes na pierwszy rzut oka jest bardzo skomplikowany, przytłacza mnogością konfiguracji i dostępnych funkcji. O tym można by spokojnie napisać osobny artykuł. Małymi krokami dochodzimy do…

Rok 2024. Dzisiaj każdy nasz nowy projekt tworzony jest zgodnie z zasadą Cloud Agnostic – tak dobieramy technologie, abyśmy mogli uruchomić się gdziekolwiek. Głównie dzięki konteneryzacji. Zrezygnowaliśmy z lokalnego repozytorium obrazów – używamy już tylko Docker Huba. Lokalne środowiska testowe są oparte o Linuxa i Dockera. W Azure głównie używamy AKS – Azure Kubernetes Service. Z powodzeniem nie tylko testowo, ale i produkcyjnie. Dockera używamy też na naszych lokalnych, deweloperskich komputerach do codziennej pracy i przy testowaniu. Zamiast instalować różne narzędzia czy aplikacje, w pierwszej kolejności szukamy ich dostępności w ramach Dockera. Jest to dzisiaj dużo łatwiejsze niż kiedyś, ponieważ Microsoft wdrożył do Windowsów funkcję WSL2 (Windows Subsystem for Linux). W skrócie, Windows ma wbudowane swoje własne jądro Linuxa, dzięki któremu możemy zainstalować dystrybucję Linuxa i używać jej po prostu jak aplikacji. Wiążemy też nadzieje co do tego rozwiązania, jeśli chodzi o produkcyjne uruchomienie Dockera na Windowsie – może tym razem się uda.

P.S. W opisanym projekcie ciągle utrzymywaliśmy obrazy Dockera, z nadzieją, że kiedyś znowu będą potrzebne. I stało się. Obecnie nasz klient małymi krokami migruje swoje środowiska do Azure, i padło pytanie, czy jesteśmy w stanie się zmigrować. Tak, ciągle mamy „Dockera”, cierpliwie czekał. 😊