Wpisanie ubuntu:latest w polu „Zainstaluj niestandardową aplikację” w ZimaOS nie tworzy automatycznie niewielkiego, stale działającego serwera Ubuntu. Obraz zawiera minimalny system plików kontenera Ubuntu, a nie wstępnie skonfigurowaną maszynę wirtualną z pełną sekwencją rozruchową, demonem SSH, menedżerem usług i działającą w tle aplikacją.
To rozróżnienie wyjaśnia przypadek ze źródła z października 2025 roku. Obraz można było pobrać i utworzyć kontener, ale nie pozostawał on uruchomiony w sposób oczekiwany przez użytkownika. Właściwe rozwiązanie zależy od rzeczywistego celu: uruchomienia jednej aplikacji w kontenerze albo uruchomienia kompletnego, ogólnego systemu operacyjnego Debian/Ubuntu wewnątrz maszyny wirtualnej.
Kontener Docker nie jest małą maszyną wirtualną
Maszyna wirtualna emuluje kompletne środowisko komputera i uruchamia własny stos systemu operacyjnego. Kontener współdzieli jądro Linux gospodarza i uruchamia jeden lub więcej odizolowanych procesów we własnej przestrzeni użytkownika.
Model Dockera koncentruje się na głównym procesie kontenera. Jeśli proces działający na pierwszym planie zakończy się, kontener uruchomiony w trybie odłączonym również się zakończy. Kontenery są więc zwykle budowane wokół długotrwale działającej usługi, takiej jak serwer internetowy, baza danych, demon synchronizacji lub proces roboczy aplikacji.
Oficjalne obrazy Ubuntu i Debiana są minimalnymi obrazami bazowymi
Obecny oficjalny obraz Ubuntu jest zbudowany na podstawie minimalnego głównego systemu plików firmy Canonical, a Docker opisuje go jako minimalną instalację, a nie kompletną maszynę wirtualną. Oficjalny obraz Debiana również korzysta z minimalnego minbase główny system plików.
Jeśli uruchomisz taki obraz interaktywnie w terminalu, będzie przypominał niewielkie środowisko Linux, ponieważ otrzymasz powłokę. Gdy powłoka się zakończy, może nie pozostać żaden działający na pierwszym planie proces usługi, który utrzymywałby kontener przy życiu.
Przed potraktowaniem któregokolwiek z tych obrazów jako gotowego serwera użyj informacji o utrzymywanym bazowym obrazie Ubuntu lub informacji o utrzymywanym bazowym obrazie Debian.
Dlaczego ubuntu:latest może zatrzymać się natychmiast
ZimaOS oczekuje, że zainstalowana aplikacja Docker będzie miała sensowny, długotrwale działający proces. Obraz bazowej dystrybucji jest zwykle podstawą dla innego obrazu lub środowiskiem interaktywnej powłoki. Jeśli nie skonfigurowano procesu usługi, który ma pozostać jako PID 1, kontener może zakończyć działanie normalnie, zamiast „ulec awarii”.
Przed założeniem, że ZimaOS nie zainstalował obrazu, sprawdź dziennik kontenera i jego stan zakończenia. Zatrzymany kontener bez skonfigurowanej aplikacji to inny problem niż usługa, która uruchamia się i zgłasza błąd.
Jeśli potrzebujesz tylko jednej aplikacji, zacznij od aplikacji
Użytkownik źródłowy wyjaśnił, że tak naprawdę nie chciał pełnej maszyny wirtualnej. Potrzebował jednej aplikacji — iDrive — oraz dostępu do pamięci NAS. W takiej sytuacji najlepszym rozwiązaniem Docker jest zwykle znalezienie utrzymywanego obrazu właściwej aplikacji albo zbudowanie małego obrazu, który ją zainstaluje i uruchomi.
Kontener powinien udostępniać tylko porty, woluminy, dane uwierzytelniające i urządzenia wymagane przez aplikację. Trwałe pliki powinny znajdować się w zmapowanej pamięci ZimaOS, a nie wyłącznie w ulotnej warstwie kontenera.
Użyj Docker Compose dla rzeczywistej usługi kontenerowej
Odpowiedź społeczności sugerowała użycie właściwej definicji Compose zamiast samego wpisania ubuntu:latest oraz nazwa kontenera. Aktualne ZimaOS poszło jeszcze dalej w tym kierunku: może importować pliki Docker Compose, edytować YAML i uruchamiać stosy złożone z wielu kontenerów wraz z kontrolą ich cyklu życia.
Aktualne wytyczne IceWhale mówią, że standardowa konfiguracja środowiska uruchomieniowego kontenera powinna znajdować się w Docker Compose, natomiast metadane sklepu właściwe dla ZimaOS powinny znajdować się w x-casaos.
Użyj aktualnego modelu Compose w ZimaOS dla aplikacji hostowanych samodzielnie, zamiast traktować nazwę obrazu dystrybucji jako kompletną definicję aplikacji.
Mapowanie pamięci NAS do kontenera
Jeśli aplikacja potrzebuje dostępu tylko do jednego katalogu, zmapuj ten rzeczywisty folder ZimaOS do kontenera. Po stronie hosta należy wskazać folder kopii zapasowej lub danych na wybranej puli pamięci, natomiast po stronie kontenera udostępnić prostą ścieżkę oczekiwaną przez aplikację.
Aktualna dokumentacja ZimaOS wyjaśnia , jak pamięć hosta jest mapowana na ścieżki w kontenerach. Zwykle jest to rozwiązanie lżejsze niż uruchamianie całej maszyny wirtualnej Debian tylko po to, aby uzyskać dostęp do jednego folderu.
Użyj ZVM, gdy oprogramowanie oczekuje pełnego komputera z systemem Linux
Maszyna wirtualna będzie lepszym rozwiązaniem, gdy instalator aplikacji oczekuje na przykład:
- konwencjonalny menedżer pakietów i zmienny system plików;
- systemd lub kilka usług na poziomie systemu operacyjnego;
- zachowanie na poziomie jądra, którego nie można bezpiecznie zapewnić za pomocą kontenera;
- tradycyjne środowisko serwera Linux zarządzanego przez SSH;
- oprogramowanie dostawcy, który wyraźnie obsługuje instalacje Ubuntu/Debian, ale nie Docker
To odpowiada pierwszej odpowiedzi społeczności: jeśli celem jest samodzielny system operacyjny Debian lub Ubuntu, użyj ZVM, zamiast zmuszać bazowy obraz kontenera do działania jak pełna maszyna wirtualna.
Zamiast tego nie instaluj aplikacji w głównym systemie plików ZimaOS
Przejście od „kontener Ubuntu kończy działanie” do „zainstaluję oprogramowanie za pomocą apt bezpośrednio w ZimaOS” jest zazwyczaj niewłaściwym kierunkiem. Obecny ZimaOS celowo utrzymuje większość folderów systemowych w trybie tylko do odczytu i nie jest ogólnym hostem Debiana/Ubuntu z apt jako zwykłego modelu zarządzania aplikacjami.
Kontenery i maszyny wirtualne istnieją właśnie po to, aby zależności aplikacji mogły pozostać oddzielone od systemu bazowego ZimaOS.
Kiedy obraz bazowy Debiana/Ubuntu jest nadal przydatny
Istnieją uzasadnione powody, aby budować na bazie ubuntu lub debian: docelowe oprogramowanie może publikować instrukcje instalacji wyłącznie dla tych dystrybucji lub możesz potrzebować ich repozytoriów pakietów podczas budowania obrazu.
W takim przypadku utwórz plik Dockerfile lub obraz oparty na Compose, który zainstaluje aplikację i zdefiniuje rzeczywiste polecenie działające na pierwszym planie. Nie polegaj na ręcznym otwieraniu powłoki, interaktywnym instalowaniu pakietów i nadziei, że zmodyfikowany kontener stanie się trwałą aplikacją. Odtworzenie kontenera może usunąć zmiany, które nie zostały zapisane w obrazie ani w trwałych woluminach.
Zasada ponownego uruchamiania nie zastępuje brakującego procesu głównego
Zasady ponownego uruchamiania Dockera są przydatne w przypadku rzeczywistej usługi, która powinna uruchomić się ponownie po restarcie lub nieoczekiwanym zakończeniu. Nie zmieniają one zakończonej sesji powłoki w serwer aplikacji. Jeśli zamierzona praca kontenera została już wykonana, jego wielokrotne uruchamianie tworzy jedynie pętlę.
Wybierz najmniejszą warstwę izolacji dopasowaną do oprogramowania
- Aplikacja ma już utrzymywany obraz Docker: użyj tego obrazu.
- Aplikację można spakować z zależnościami Ubuntu/Debiana: zbuduj właściwy kontener aplikacji.
- Aplikacja wymaga kompletnego, konwencjonalnego hosta linuksowego: użyj ZVM.
- Potrzebujesz tylko dostępu do pamięci masowej: zamapuj wymagane foldery NAS zamiast wirtualizować cały dysk.
Najczęściej zadawane pytania dotyczące Ubuntu i Debiana w ZimaOS
Dlaczego ubuntu:latest instaluje się, ale nie pozostaje uruchomiony?
Obraz bazowej dystrybucji nie jest automatycznie usługą działającą stale. Kontener Docker potrzebuje głównego procesu, który pozostaje uruchomiony.
Czy ubuntu:latest to pełna maszyna wirtualna Ubuntu?
Nie. To minimalne środowisko użytkownika kontenera, które współdzieli jądro hosta.
Czy powinienem używać ZVM dla każdej aplikacji linuksowej?
Nie. Prawdziwa aplikacja Docker jest zwykle lżejsza i łatwiejsza w zarządzaniu, gdy oprogramowanie obsługuje kontenery.
Kiedy ZVM jest lepszym wyborem?
Użyj maszyny wirtualnej, gdy oprogramowanie oczekuje tradycyjnego, modyfikowalnego serwera Ubuntu/Debian z usługami systemowymi lub założeniami instalacyjnymi, które nie pasują do kontenera.
