TrueNAS CORE i Jail – o co chodzi?
Pierwotnie pomysłem zastosowanym TrueNAS CORE na dodawanie aplikacji, funkcjonalności były tzw Plugin-y. Można w ten sposób instalować Nextcloud, Plex Media server, i sporo innych Pluginów. Zresztą jak ktoś nie znajdzie co potrzebuje to zawsze może uruchomić pusty Jail i zainstalować wewnątrz co tam potrzebuje. Jail polega to na tym, że odpala się aplikację „uwięzioną”, ograniczoną do konkretnego katalogu na dysku. Ma ona dostęp do tego samego RAM do tego samego procesora tego samego jądra systemu. Współdzielą nawet przestrzeń dyskową choć jak wspomniałem Jail jest uwięziony w swoim katalogu i nie ma dostępu do całości dysku gospodarza. Separacja oprogramowania od systemu wydaje się zapewniać bezpieczeństwo.
Niewątpliwą zaletą rozwiązania jest jego prostota i bardzo mały narzut na zasoby. W odróżnieniu klasycznej wirtualizacji każdy proces wewnątrz Jail jest jak każdy inny proces uruchomiony i widoczny w systemie gospodarza. Oczywiście procesy gospodarza nie są widziane przez Jail.
I co to komu szkodziło żeby było tak jak było można by zapytać?
Wadą która naprawdę potrafi utrudnić swobodne korzystanie z tego rozwiązania jest fakt, że Jail-e współdzielą z gospodarzem również jądro systemu z którego korzystają. Sprawia to, że wszystkie aplikacje w Jail-ach muszą być zgodne z systemem gospodarza. TrueNAS CORE oparty jest na FreeBSD i Jail-e na nim odpalane muszą być tylko zgodne z FreeBSD ale i na ogół również z jego konkretną wersją. Czyli aktualizacja aplikacji może się okazać nie możliwa bez aktualizacji systemu a aktualizacja systemu często wymaga aktualizacji Jail-i lub je po prostu czasem …psuje.
Docker
Rozwiązaniem którego pozazdroszczono w TrueNAS CORE jest właśnie Docker. Rozwiązuje on bolączki związane z Jail-ami. Docker pozwala na budowę minimalnego systemu operacyjnego zawierającego wyłącznie elementy potrzebne do obsługi aplikacji dla której jest stworzony. Co ważne zawiera on również wszystkie zależności, właściwe sobie wersje aplikacji bibliotek i wszystko co potrzebne do jego uruchomienia. Jest on odseparowany od systemu gospodarza rozwiązując problem niekompatybilności wersji oprogramowania bibliotek itp. Nie tylko wersje systemu nie muszą być zgodne ale mogą być różne systemy operacyjne.
Cały system operacyjny z serwerem HTTP czy bazą danych zajmuje kilkadziesiąt to maks kilkuset MB. To jest olbrzymią różnicą w porównaniu co wirtualnego serwera
Taki kontener jest na tyle uniwersalny, że możemy go swobodnie przenieść na dowolny komputer kompatybilny z Docker i go tam odpalić bez obaw o niekompatybilność.
TrueNAS SCALE docker – i co chodzi?
Jak już sobie ogólnie przepowiedzieliśmy dlaczego Jail nie jest fajny z kilku względów a Docker jest to wróćmy do TrueNAS. Teoretycznie najprostszym było by po prostu wdrożyć Docker do TrueNAS. Tylko, że jak wspominałem TrueNAS CORE jest na FreeBSD a mimo zalet tego systemu niestety skrajnie upraszczając.. FreeBSD nie umie w Docker-a.
Dlatego między innymi odpalono gałąź TrueNAS SCALE. Podstawową różnicą techniczną jest to, że jest on oparty na Debian-ie. Debian i oparty na nim Ubuntu natomiast świetnie graja w Docker-a.
Dygresyjnie również ważnym elementem różniącym CORE i SCALE jest możliwość skalowania systemu plików przez łączenie minimum trzech nodów w klaster co ma sprawić, że klaster będzie nie dosyć że odporny na awarie jednego noda to jeszcze szybszy.
Kubernetes
Współczesne złożone i mocno obciążone usługi najczęściej rozbija się na tzw mikro-usługi. Logicznie oddziela się np. bazy danych od serwerów HTTP, serwerów cache czy load-balancerów itp. Sprawia to że odpalając wiele instancji takiej mikro usługi HTTP na kilku serwerach umożliwiamy niemal natychmiastową skalowalność i jednocześnie zwiększamy odporność na awarię jednego z serwerów.
Wszystko pięknie ale… okazuje się że w praktyce takich kontenerów dla jednej aplikacji na start bywa często po kilka. Dodatkowo w ramach redundancji trzeba by było to replikować na inne nody. Odpalać dodatkowe kontenery w ramach potrzeb… robie się dużo.
Z pomocą przychodzą na tu orkiestratory. Na przykład SWARM, docker-compose czy używany właśnie w TrueNAS Kubernetes.
On właśnie w tle dba o utrzymanie właściwej ilości kontenerów, stworzenie wewnętrznych sieci do komunikacji między kontenerami, przekierowaniem zapytań do właściwych kontenerów, przydzieleniem zasobów dyskowy i wiele wiele innych o których nie musimy myśleć. Przynajmniej ne początku jak wszystko działa.
Z aktualnie widocznych na pierwszy rzut oka wad tego rozwiązania wymienić można znacznie większą złożoność rozwiązania w porwaniu z Jail. Drugą wadą ale już nie samej konteneryzacji tylko wydania w wersji TrueNAS jest brak redundancji. Przynajmniej w wersji natywnej. Chodzi o to, że kontenery często bywają duplikowane po kilku fizycznych serwerach ze względów zarówno niezawodności jak i skalowalności obciążenia. W tym wypadku tak to nie zadziała. Zapewne dało by się to jakoś rozwiązać z większą lub mniejszą ingerencją w trzewia systemu, jak zresztą większość rzeczy w open source, ale nie o to w tym miejscu chodzi.
Laboratorium
Do prezentacji wykorzystałem TrueNAS SCALE 22.12 Bluefin. Na maj 2023 konieczna okazała się ręczna zmiana linii na Bluefin ponieważ we wcześniejszej wersji występował kłopot z aktualizacją aplikacji z poza natywnej listy IXSystems. Dodatkowo muszę przyznać, że tak jak na początku czuć było niedopracowanie SCALE od strony interface użytkownika tak z wydania na wydanie wygląda coraz sensowniej i ładniej. Dodam też że laboratorium to maszyna wirtualna z dyskami NVMe ponieważ kontenery, a zwłaszcza ich inicjowanie potrafią być bardzo ciężkie również dla dysków dla dysków.
Podsumowanie
To tylko podstawa kobernetes czy ogólnie kontenery to mega złożony temat ale zachęcam do zabawy.
Czy postawił bym na tym produkcyjne kontenery z danymi krytycznymi. No raczej nie. Czy posadził bym na tym kontenery na użytek własny? Tak, uważam, że to świetny punkt wyjścia to rozpoczęcia zabawy z Docker/kubernetes.
Jeśli chcielibyście dowiedzieć się więcej o TrueNAS napiszcie do nas. Opowiemy Wam jak działa i dlaczego warto?