Ostatnio sporo pracuję z narzędziami do konteneryzacji na routerach. Cały stack i jego możliwości są dość skomplikowane, dlatego stworzyłem na użytek własny mały “słownik pojęć”. Temat dość hermetyczny ale kto wie – może komuś ułatwi przyszłą pracę.
Po co nam LCM i kontenery?
Middleware na urządzeniach embedded w końcu skorzysta z dobrodziejstw XXI wieku. W LCM czyli LifeCycle Management chodzi o możliwość zdalnego zarządzania aplikacjami na urządzeniach udostępnionych klientom. Kontenery i narzędzia do ich obsługi powinny nam zapewnić:
- Dynamiczne zarządzanie usługami działającymi w systemie (np. instalacja, konfiguracja, usuwanie)
- Izolację serwisów zarządzanych przez LCM od reszty systemu – zwiększamy bezpieczeństwo i stabilność. Potencjalne zhackowanie aplikacji zamiast dostępu do powłoki roota da co najwyżej dostęp do kontenera, w którym mało co można popsuć.
- Jedno zunifikowane API do zarządzania – wtedy dużo łatwiej przenosić aplikacje i serwisy między różnymi platformami
VM vs kontener
Maszyna wirtualna (VM) to kompletna platforma z własnym systemem operacyjnym i emulacją sprzętu. W odróżnieniu od VM, kontenery zajmują mało miejsca i współdzielą jądro systemu operacyjnego hosta, izolując aplikacje przy jednoczesnym wykorzystaniu mniejszej ilości zasobów niż maszyny wirtualne.
Docker vs LXC
Docker – znany i lubiany(?). Na początku zaimplementowany jako potężny monolit, potem rozdzielony na kilka warstw. Wszystko ładnie pokazane na grafice poniżej.
LXC – ku mojemu zdziwieniu, nie jest na tej samej warstwie co docker, LXC działa o wiele bliżej systemu operacyjnego. Jest to w zasadzie bezpośredni interfejs do funkcjonalności w kernelu, które dają wsparcie dla konteneryzacji. W skrócie: Coś pomiędzy chroot a pełną maszyną wirtualną.
Z dokumentacji: “it lets Linux users easily create and manage (…) containers” – to akurat w ogóle nieprawda, poprawna obsługa i konfiguracja LXC to trudne (żeby nie powiedzieć: upierdliwe) zadanie, wymaga dość sporego wysiłku integracyjnego. W innym wypadku czemu ktoś w ogóle używałby na Linuxie dockera?
Czym jest container runtime?
Czyli środowisko uruchomieniowe kontenera. To ten kawałek oprogramowania, który umożliwia uruchamianie kontenerów w systemie operacyjnym hosta. Obsługuje cykl życia kontenerów, w tym pobieranie obrazów kontenerów z rejestrów, zarządzanie ich wykonywaniem oraz zapewnianie odpowiedniej alokacji i izolacji zasobów. Przykładowo, przez komunikację z kernelem i ustawianie cgroups.
Istnieje kilka implementacji container runetime’u:
runc – lekkie, ustandaryzowane narzędzie CLI, które jest zgodne ze specyfikacjami Open Container Initiative (OCI). Napisany w Go, domyślnie używany przez dockera.
crun – odmiennie od przodka, napisany w C, przez co zajmuje mniej miejsca i lepiej wychodzi w benchmarkach.
LXC – także funkcjonuje jako runtime, ale oprócz tego daje dostęp do bardziej wysokopoziomowych narzędzi.
OCI – inicjatywa m in dockera i coreOS mająca na celu stworzenie otwartego standardu dla kontenerów systemowych. Obecnie istnieją 3 specyfikacje (Runtime, Image, Distribution). Patrząc z góry, implementacja OCI pobiera obraz OCI, a następnie rozpakowuje go do OCI Runtime filesystem bundle. Następnie bundle może być odpalony przez OCI Runtime.
Przykład praktycznej implementacji – prplLCM, framework konteneryzacji stworzony na routery. Tam oprócz powyższego mamy też narzędzia, które zarządzają całym “systemem produkcji kontenerów” w zależności od wybranego runtime’u. Na uwagę szczególnie zasługuje nazwenictwo – Cthulhu, Rlyeh i Timingila. Źródło: https://gitlab.com/prpl-foundation/prplrdkb/metalayers/meta-lcm
Dodaj komentarz