W połowie 2022r odkryłem CasaOS i dzięki temu projektowi wciągnął mnie temat konteneryzacji i Docker.
ZimaOS to system operacyjny NAS rozwijany przez firmę IceWhale Technology, ewoluujący z wcześniejszego projektu CasaOS. Powstał w 2023 roku jako fork CasaOS, zbudowany od podstaw na fundamencie Buildroot dla lepszej stabilności, skalowalności i kompatybilności z hardware’em x86-64, w tym urządzeniami Zima jak ZimaBoard czy ZimaCube. Pierwsza beta wersja została wydana pod koniec 2023, a repozytorium GitHub wystartowało we wrześniu 2023.
System jest otwarty w części (Docker Compose na immutable bazie), skupiony na prostocie NAS dla domu/SOHO, z RAID (0/1/5/6/JBOD), backupami i appkami kontenerowymi.
ZimaOS stosuje model hybrydowy: open-source w części publicznej (repozytorium GitHub z kodem bazowym, immutable design na Buildroot), ale z elementami proprietary w zaawansowanych funkcjach i UI. Community Edition jest darmowa z limitami (np. 10 app, 4 dyski), a Plus Edition to jednorazowa opłata 29 USD lifetime za pełne możliwości (więcej dysków, app, użytkowników).
Zaangażowanie społeczności
Projekt mocno opiera się na społeczności (43 tys. członków Discord, 1 mln pobrań), z co-creation, tłumaczeniami (26 uczestników) i feedbackiem cotygodniowym. Powstał z ewolucji CasaOS (open-source Apache 2.0), ale dla zrównoważonego biznesu wprowadzono kontrolę licencyjną.
ZimaOS to dzieło chińskiej firmy i może dla tego jest tak bardzo pragmatyczny i taki “dla ludu”.
Nie musisz poświęcać się dla zrozumienia jak to wszystko działa jak to jest w przypadku PVE czy TruNas Sclale. W dalszej części postaram się przybliżyć pierwsze kroki w tym systemie i pokazać jak niewiele wymaga od swojego użytkownika.
Po paru następnych krokach, gdzie instalator upewnia się, że jesteśmy świadomi wyboru i zakończeniu procesu instalacji mamy takie okno informujące nas o konieczności usunięcia nośnika instalacyjnego i ponownym uruchomianiu maszyny.
Widzimy adres IP pod którym znajdziemy webUI naszego systemu.
Informację, że domyślnie SSH mamy wyłączone.
Powinniśmy ustawić nasze supertajne hasło dla użytkownika root
Pod wskazanym w konsoli adresem wita nas powitalne okno z wyborem języka. Jest nasz ojczysty na liście i to z całkiem dobrym tłumaczeniem jak się dalej okaże.
W tym osobnym GUI jest dobrze przemyśleć jaką obierzemy strukturę dla naszych danych. Ja na potrzeby aplikacji wykorzystuję folder AppData na jednym ze stworzonych woluminów. Aplikacje to kontenery, więc pod ich dane tworzę osobne foldery.
Mając już zorganizowaną przestrzeń dyskową możemy przejść do instalacji pierwszej aplikacji z App Store. Ale zanim to zrobimy, proponuję zapoznać się z możliwością rozszerzania naszej listy dostępnych obrazów kontenerów o dodatkowe repozytoria w App Store. Pod przyciskiem “więcej” mamy link do strony z adresami dodatkowych repozytoriów
Mając już długą listę możliwych do zainstalowania aplikacji, możemy zwyczajnie kliknąć instaluj i dane dla aplikacji trafią do domyślnie ustawionego folderu na dysku systemowym. Zobaczmy co zadzieje się gdy tak zainstaluję Home Assistant (kontener HA CORE) z dodanego repozytorium Home Automation. Aczkolwiek w podstawowym repozytorium BigBearCasaOS też jest.
To w ustawieniach tego i każdego kontenera (aplikacji) mogę mapować katalogi i sprzęt hosta (1), mogę podejrzeć logi z terminala uruchomionego kontenera (2), mogę konfigurację całej aplikacji wyeksportować do pliku docker-copose w YAML.
Co jeśli nie ma mojej aplikacji w AppStore? Nic wielkiego dla ZimaOS, możemy instalować obrazy niestandardowe przez dodanie własnych ustawień z GUI lub importując plik docker-compose.
Bardzo mi się podoba to rozwiązanie i gdybym miał zaczynać “od nowa” to pewnie zrobił bym to według twojego tutoriala. Niestety brak czasu i lenistwo skłania mnie do zostania przy swoich dotychczasowych rozwiązaniach
@angler interesujący materiał, polubień nie bedę już klepal, dobra robota👍. Nie wiem po co ale jutro to postawie. Jedno pytanie: czy dla każdej maszyny mogę ustawić osobne IP z puli domowej? Taka zaszłość i nie chcę tego zmieniać.
EDIT:
Ponieważ ZVM bazuje na KVM/libvirt, możesz użyć virsh w terminalu do edycji ustawień VM, możesz przez komendę virsh edit <vm_name> edytować cały plik XML, ale UWAGA zmiany w XML są „na własne ryzyko”, nie ma tego w dokumentacji i nie wiadomo jak UI ZVM zadziała równolegle ze zmianami w warstwievirsh.
Z uwagi na to, że nie jestem fanem maszyn wirtualnych, nie chcę się aby kogoś wprowadzać tu w błąd. Jestem jednak wielkim fanem kontenerów dokera. Nie było jak dotąd w moim doświadczeniu z Docker sytuacji, że musiałem koniecznie postawić VM, bo nie znalazłem rozwiązania z kontenerami.
Dla przykładu mogę podać aplikację Immich, która w tym momencie przejmuje u mnie funkcjonalność zdjęć w chmurze komercyjnych dostawców, wraz z synchronizacją, wyszukiwaniem osób, lokalizacji itp.
Pod jednym plikiem docker-compose zawiera się kilka serwisów działających wspólnie, w sumie 5 kontenerów, tworzących jedną, kompletną aplikację.
Lista usług/kontenerów dla Immich:
immich-postgres: Baza PostgreSQL z pgvector (dla wektorowego wyszukiwania AI).
immich-machine-learning: Moduł ML do rozpoznawania twarzy/obiektów (używa modeli TensorFlow/PyTorch).
immich-server: Główny serwer API i backend (port 2283), zarządza uploadami, bibliotekami mediów.
immich-redis: Cache Redis dla sesji i kolejek zadań.
immich-web (nie jawnie w snippet, ale standardowy w Immich compose dla frontend UI).
Gorąco poleca zatem Zima OS dla chcących zrozumieć jak działa konteneryzacja.
Czy bezpłatna wersja wprowadza jakieś istotne dla naszych zastosowań ograniczenia?
Te backupy mnie przkonują.
Obecnie mam proxmox i mialem przypadki, że do natywnego systemu musiałem doinstalować jakieś pakiety. W Zimie to chyba lipa?
Np. musiałem utworzyć urządenie systemowe /video z kamery IP.
Nie wiem czy istnieje taka możliwość aby zasoby jednego kontenera udostęplić innemu? …popytam AI
4 Disks w opisie wersji free odnosi się do 4 puli dyskowych, nie pojedynczych dysków. 3 Members - i tak jestem sam z administracją mojego homelab, więc nie robi mi różnicy.
Pozostaje dla mnie niewiadomą dlaczego, przy niektórych funkcjonalnościch pojawia się ikonka z “+”, tu chyba będzie nacisk na rozwój dodatkowych możliwości dla wersji płatnej.
Nie próbowałem, bo nie miałem jeszcze potrzeby. Ale wszystko się da, to jest Linux, co prawda bliżej mu do HAOS niż Debiana ale zawsze można skompilować potrzebne pakiety ze źródła. Sterowniki apex dla Coral TPU pod Frigate miałem od razu. Brakuje jeszcze podobno pod Hailo-8, ale społeczność projektu jest aktywna, a deweloperzy jej słuchają.
W tym linku masz też instrukcję jak zainstalować Zima OS na PVE.
Nie bardzo rozumiem ten dylemat, kontenery dzielą zasoby razem z hostem (jeśli na to pozwolisz przy konfiguracji kontenera poprzez mapowanie zasobów czy opcje nadania wysokich uprawnień). Sprzęt nie jest emulacją w wirtualizacji maszyny, to ten sam sprzęt hosta. Jeśli tylko sprzęt (sterownik) czy oprogramowanie OS na to pozwala, to zasoby są do dyspozycji dla wielu procesów. Jeśli postawisz np. DB jako kontener i udostępnisz ją dla innych kontenerów np. HA czy Grafana, to te kontenery mogą korzystać z tej bazy wspólnie. Tak samo dzieje się wewnątrz HAOS z kontenerami w postaci AdOnns.
Normalnie to na host instaluje v4l2loopback, tworzę /dev/video10 i mogę to udostępnić do innego kontenera.
Z Zima instalacja v4l2loopback może być niemożliwa.
Myślałem o czymś takim:
kontener1(debian… v4l2loopback… /dev/video10) ===> kontener2 /dev/video10
… łoo panie
Zacznę od tego problemu … jeśli nie będę potrafił to dalsza zmiana będzie bezcelowa.
Ok …zadaję zbyt dużo pytań… a jeszcze nie zacząłem ale temat kusi.
p.s. AI podpowiada:
To sytuacja patowa w klasycznym rozumieniu, ponieważ architektura Linuxa wymaga modułu jądra (v4l2loopback), aby system w ogóle “zrozumiał”, czym jest urządzenie /dev/video. Jeśli host go nie ma i nie możesz go doinstalować, fizycznie nie stworzysz tam pliku urządzenia.
Istnieje jednak jedno zaawansowane obejście, które pozwala oszukać drugi kontener bez dotykania systemu hosta.
W przypadku Hyperion.NG sytuacja jest o tyle łatwiejsza, że jest to oprogramowanie bardzo elastyczne, mimo że domyślnie sugeruje użycie urządzenia /dev/video.
Skoro nie możesz zmodyfikować hosta (brak v4l2loopback), masz dwie drogi, aby “oszukać” Hyperiona lub zmusić go do współpracy bez fizycznego urządzenia /dev/video:
Hyperion.NG posiada wbudowany moduł “Protocol Buffers”, który pozwala na wysyłanie obrazu bezpośrednio do niego przez sieć (localhost). Nie potrzebujesz wtedy w ogóle urządzenia /dev/video.
Kontener 1 (FFmpeg): Pobiera strumień z kamery IP i wysyła go do Hyperiona protokołem UDP/Proto.Bashffmpeg -rtsp_transport tcp -i rtsp://KAMERA_IP -f rawvideo -pix_fmt rgb24 -s 640x480 - | \ hyperion-remote -a adres_kontenera_hyperion:19445 -p 50 -i "Kamera_IP" -v RGB24
Kontener 2 (Hyperion): W konfiguracji Hyperiona włączasz “Network Network” (domyślnie port 19445).
Proponuję załóż osobny temat z tym zagadnieniem, bo jest to bardzo ciekawe. A zdaje się, że nie ma takiego dotyczącego projektu Hyperion. Z pewnością się w nim wypowiem, bo parę pomysłów by się znalazło. Zastanawia mnie jedynie dlaczego jesteś zmuszony używać akurat v4l2loopback?
@angler a powiedz mi tak szczerze: wiem że korzystałeś z HAOS bare metal i jaka teraz instalacja bardziej Ci odpowiada? Nigdy nie myślałem o przejściu na dockery i też nigdy się tym nie bawiłem więc zastanawiam się poważnie nad przejściem na ZimaOS. Z drugiej strony czy jest sens rezygnować z rozwiązania które nigdy mnie nie zawiodło przez tyle lat
I nadal korzystam, mam dwie maszyny. Na początku miałem (nadal mam) bramkę AI-Speaker Dev3 i małą przygodę z xpenelogy jako domowy NAS. Następnie poszukiwałem dość długo rozwiązania dla typowego serwera pod homelab. Był przez chwilę TruNas Scale, ale poległem na zarządzaniu użytkownikami, uprawnieniami i administrowaniu zasobami. Były też testy OMV, Cockpit i wspomniane wcześniej Casa OS, który to podobał się bardzo (na tamte czasy), ale brakowało tworzenia macierzy RAID.
Teraz będzie ZimaOS pod NAS, który tu opisuję.
Zawsze chciałem mieć dwie maszyny, nie jestem zwolennikiem VM na PVE. Moim zdaniem takie rozwiązanie, przy obecnych możliwościach tworzenia kopi zapasowych w HAOS, daje największą elastyczność z zachowaniem bezpieczeństwa mojej instancji HA. Przy jednoczesnym wykorzystaniu nawet przeciętnych zasobów dzięki kontenerom. Do tego mogę korzystać z dobrodziejstw, wygody AddOns. A jeśli czegoś nie mogę w HAOS to jest Docker, który pozwala na prawie wszystko, bo mnogość aplikacji kontenerowych jest ogromna. Główne funkcje jakie realizuje ten NAS to:
Archiwum zdjęć/filmów rodzinnych - Immich
nagrania z Frigate NVR
synchronizacja dokumentów i kopie zapasowe w tym z HAOS
w planie dokończenie wdrożenia Paperless-ngx z OCR i AI-GTP (Skaner i naklejki z kodami ASN kupione już dawno).
W sumie można to wszystko robić też za pomocą AddOns w HAOS, ale on jest u mnie nie od wszystkiego, ale tylko od Smart Home.
W Zima OS nie ma (na ten moment) migawek maszyn wirtualnych, co jest dla wybierających PVE chyba kluczowe. Ale mając ZimaOS i w tym VM z HA, czy też sam kontener z HA Core, mogę testować przed aktualizacją różne rozwiązania, zanim świadomie przeniosę je na maszynę z HA.
Innymi słowy, nie rezygnuj z HAOS (bare metal), ale zachęcam do poznania Docker, a tu Zima OS może być świetnym uzupełnieniem jako NAS i laboratorium do nauki.
