Konteneryzacja w projektach embedded. Jak Docker ułatwia tworzenie i zarządzanie środowiskiem developerskim?

Jakie są główne zalety konteneryzacji w projektach embedded? Jak Docker ułatwia proces wprowadzania nowego członka do zespołu? I co powinna wiedzieć osoba, która wcześniej nie miała do czynienia z Dockerem, aby móc skutecznie korzystać z tego narzędzia w nowej pracy? O korzyściach z konteneryzacji rozmawiamy z Michałem Kozieniem, project technical leadem w ASSA ABLOY.

Czym jest konteneryzacja w IT i dlaczego jej popularność rośnie?

Konteneryzacja to technologia pozwalająca na tworzenie wirtualnych maszyn wraz z dodatkowymi narzędziami zamykanych wewnątrz „kontenerów”. Od tradycyjnych maszyn wirtualnych to rozwiązanie różni się możliwością łatwego wyboru zasobów dostępnych wewnątrz kontenera i „gotowością” do wykonania konkretnych zadań bez konieczności ręcznego instalowania potrzebnych nam narzędzi wewnątrz systemu. Można by powiedzieć, że kontenery to takie lekkie maszyny wirtualne skrojone do potrzeb programisty lub projektu.

Jakie są główne zalety konteneryzacji w projektach embedded?

W przypadku projektów programistycznych często spotykamy się z potrzebą posiadania środowiska zawierającego szereg narzędzi potrzebnych do budowania i debugowania kodu. Wiąże się to z koniecznością instalacji dodatkowych, czasem niestandardowych aplikacji (np. kompilatorów). 

Konteneryzacja pozwala zamknąć cały zestaw wymaganych narzędzi wewnątrz maszyny wirtualnej, która udostępnia jej użytkownikom gotowe środowisko wymagające tylko instalacji oprogramowania Docker na komputerze programisty lub maszynie wykonującej zadania automatyzujące (np. Continuous Integration).

W jaki sposób Docker ułatwia tworzenie i zarządzanie środowiskiem developerskim w projektach embedded?

Jak wspomniałem wcześniej, kontenery Dockera zapewniają możliwość stworzenia środowiska wirtualnego zawierającego wszystkie potrzebne nam narzędzia do prowadzenia developmentu. Kontenery Dockera tworzy się za pomocą przepisu (tzw. Dockerfile). W tradycyjnym podejściu do tworzenia środowiska programistycznego podobne czynności wykonalibyśmy, np. pisząc instrukcję zawierającą listę zależności i narzędzi, które musimy zainstalować lokalnie.

W przypadku Dockera taka instrukcja jest tożsama z przepisem Dockerfile, na podstawie którego tworzony jest obraz (image) kontenera. Możemy potem taki obraz udostępnić dla innych członków zespołu, np. poprzez repozytorium typu Gitlab lub Nexus.

Dodatkowo, na podstawie naszych własnych obrazów (image) kontenerów możemy tworzyć ich rozszerzone wersje, co łatwo pozwala na rozbudowywanie uprzednio stworzonych środowisk do nowych potrzeb. Możemy również bazować na licznych gotowych obrazach Dockera dostępnych w internecie (np. na stronie Docker Hub), udostępnianych na licencjach open-source.

Czy Docker ma jakieś ograniczenia lub wady, zwłaszcza w kontekście embedded?

W zasadzie widzę cztery główne ograniczenia Dockera, na które należy zwrócić uwagę przy wyborze tej technologii.

Pierwszym z nich jest wolniejsze działanie procesów wewnątrz kontenera. Wynika to z wykorzystywania wirtualizacji przez Dockera. Widoczne jest to szczególnie na komputerach o niższej mocy obliczeniowej i mniejszej liczbie rdzeni procesora.

Drugim ograniczeniem może być ostateczny rozmiar kontenerów, który często sięga nawet kilku gigabajtów. Wiąże się to z faktem, że bazą kontenera jest często pełna instalacja wirtualizowanego systemu operacyjnego, na którą dodatkowo są nakładane nasze zależności. Istnieje jednak szereg lekkich dystrybucji Linuksa wystarczających do większości zastosowań, które znacznie ograniczają rozmiar kontenera. Dodatkowo rozmiar ten można optymalizować, stosując różne techniki tworzenia opisu kontenera w Dockerfile.

Trzecim ograniczeniem jest fakt, że Docker pracuje najlepiej pod systemem Linux. Windows nie wspiera tej technologii natywnie, co może zwiększać próg wejścia dla nowych osób korzystających z tego systemu. Korzystanie z Dockera w systemie Windows możliwe jest poprzez moduł Windows Subsystem for Linux (WSL), który wymaga dodatkowych kroków potencjalnie wymagających uprawnień administratora naszego komputera. Niestety nie jestem w stanie wypowiedzieć się o pracy z Dockerem na komputerach Mac.

Ostatnie ograniczenie, z jakim się spotkałem to nie zawsze działające sterowniki urządzeń USB, które chcemy używać wewnątrz kontenera — jest to szczególnie uciążliwe w przypadku rozwoju projektów embedded, gdzie często używamy zewnętrznych urządzeń (płytek ewaluacyjnych, debuggerów itp.). O ile większość problemów, z którymi miałem do czynienia, udawało mi się dość szybko rozwiązać, doczytując dokumentację lub instalując dodatkowe narzędzia, zdarzył mi się osobiście jeden kłopot z połączeniem USB, którego nie byłem w stanie przeskoczyć. Nie wykluczam, że przy głębszym rozpoznaniu tematu udałoby się go rozwiązać, ale zdaję sobię sprawę z tego, że takie problemy mogą nieco odstraszać developerów embedded od Dockera.

Jakie są Twoje doświadczenia związane z korzystaniem z Dockera? Kiedy poznałeś to narzędzie i jak szybko się wdrożyłeś w korzystanie z niego?

Z Dockerem pierwszy raz do czynienia miałem ok. 2 lata temu, gdy pracowałem jako full stack developer przy rozwijaniu aplikacji webowych. Używaliśmy wtedy Dockera głównie do ułatwienia procesu deploymentu naszych aplikacji na serwerach klienta (co pokazuje też uniwersalność tej technologii).

Wydaje mi się, że większość programistów korzystających z Dockera nie musi znać wszystkich szczegółów tej technologii, stąd próg wejścia ocenię jako niski. Najważniejsze to poznać podstawowe zasady jego działania i sposób tworzenia plików Dockerfile. Reszta przychodzi dość naturalnie — pliki konfiguracyjne pisze się w podobny sposób do wykonywania poleceń (np. instalacji programów) w normalnym systemie operacyjnym.

Czy istnieją sytuacje, w których Docker okazał się szczególnie pomocny lub przeciwnie, nie spełnił oczekiwań?

Pozwolę sobie na użycie konkretnych przykładów takich sytuacji.

Na duży plus Docker spisał się w projekcie, którego celem było propagowanie systemu operacyjnego RTOS Zephyr w firmie, z naciskiem na osoby nie znające tej technologii. Pozwoliło to na stworzenie pełnego środowiska programistycznego, wraz z edytorem kodu (Visual Studio Code) wspierającym podpowiedzi i dodatkowe narzędzia związane z SDK systemu Zephyr.

Konteneryzacja nie spełniła się jednak w 100% w projektach wymagających dużych nakładów obliczeniowych podczas budowania projektu (np. budowania dystrybucji systemu Linux). Z uwagi na używanie wirtualizacji wewnątrz kontenera, proces ten przebiegał znacznie wolniej niż budowanie bezpośrednio na systemie programisty. Mimo tego w tych projektach Docker stanowił dobry punkt wyjścia jako „przepis” do instalacji odpowiednich narzędzi i zależności lokalnie, jeśli zachodziła potrzeba szybszego budowania.

Jak Docker ułatwia proces wprowadzania nowego członka do zespołu?

Posiadając gotowe środowisko ze wszystkimi potrzebnymi programiście narzędziami w postaci kontenera Dockera unikamy konieczności ich instalowania na komputerze nowego członka zespołu. Nie jest potrzebna też wtedy długa instrukcja wprowadzająca tę osobę — przy jej tworzeniu można skupić się na faktycznie istotnych elementach z punktu widzenia rozwoju oprogramowania w projekcie. Przy poprawnej instalacji Dockera u nowego członka zespołu, jest on w stanie w zasadzie od razu zacząć budować kod źródłowy.

Jeżeli środowisko oparte na Dockerze nie odpowiada danej osobie lub ograniczenia techniczne uniemożliwiają pracę z nim, wspomniany wcześniej Dockerfile może posłużyć jako „instrukcja” opisująca, co należy zainstalować i jakie polecenia wykonać w celu odtworzenia takiego środowiska lokalnie na maszynie programisty.

Co powinna wiedzieć osoba, która wcześniej nie miała do czynienia z Dockerem, aby móc skutecznie korzystać z tego narzędzia w nowej pracy?

Moim zdaniem do korzystania z Dockera nie jest potrzebna bardzo specjalistyczna wiedza. Używanie tej technologii sprowadza się do kilku komend specyficznych dla Dockera.

Natomiast wewnątrz kontenerów działamy tak jak w normalnym systemie operacyjnym, najczęściej typu Linux. W związku z tym główną potrzebną umiejętnością jest zdolność poruszania się w tym systemie i korzystania z podstawowych komend Linuksa.

Podobnie jest w przypadku jeśli chcemy tworzyć własne Dockerfile. Znajomość komend Linuksa uzupełniona krótką lekturą oficjalnej dokumentacji lub przykładów tworzenia tych plików jest zupełnie wystarczająca do opanowania podstaw Dockera.

Jak widzisz przyszłość konteneryzacji w obszarze projektów embedded? Czy istnieją potencjalne kierunki rozwoju lub nowe technologie, które mogą wpłynąć na to środowisko w przyszłości?

Myślę, że Docker i inne technologie konteneryzacji będą mocno rozwijać się we wszystkich obszarach projektów programistycznych. Już teraz widzę trend, że Docker staje się nieodzowną częścią projektów IT, niezależnie od języków programowania, docelowej platformy tworzonych aplikacji — nie tylko w obszarze embedded.

Wydaje mi się, że największy wpływ na popularność będzie miało poprawianie przez autorów wydajności operacji wykonywanych wewnątrz kontenerów, usprawnianie technologii wirtualizacji i (naturalnie) pojawianie się mocniejszego sprzętu komputerowego w niższej cenie 😉

Jakie praktyczne wskazówki mógłbyś dać wszystkim, którzy chcą zacząć korzystać z Dockera?

Jako że jestem osobą, która najsprawniej uczy się na praktycznych przykładach, po krótkiej lekturze dokumentacji Dockera polecałbym próbę konteneryzacji środowiska w prostym przykładowym projekcie — najlepiej własnym, który dobrze znamy. Powinno to pozwolić na sprawne opanowanie podstaw Dockera w realnym przypadku.

---

Michał Kozień. Aktualnie pracuje w ASSA ABLOY jako project technical lead, gdzie zajmuje się koordynacją prac zespołu programistów embedded. W branży IT pracuje od ok. 12 lat i w swojej karierze zajmował się zarówno programowaniem (embedded i full stack web) jak i zarządzaniem zespołami oraz projektami.

Zdjęcie główne pochodzi z Unsplash.com.