Att skriva ubuntu:latest att klistra in i ZimaOS-fältet ”Installera en anpassad app” skapar inte automatiskt en liten Ubuntu-server som alltid är igång. Avbildningen är ett minimalt Ubuntu-containerfilsystem, inte en förkonfigurerad virtuell maskin med en fullständig startsekvens, SSH-demon, tjänstehanterare och en bakgrundsapplikation som redan körs.
Den skillnaden förklarar källfallet från oktober 2025. Avbildningen kunde hämtas och en container kunde skapas, men den fortsatte inte att köras på det sätt som användaren förväntade sig. Den rätta lösningen beror på det verkliga målet: att köra en applikation i en container eller att köra ett komplett Debian-/Ubuntu-operativsystem i en virtuell maskin.
En Docker-container är inte en liten virtuell maskin
En virtuell maskin emulerar en komplett datormiljö och startar sin egen operativsystemstack. En container delar värddatorns Linux-kärna och kör en eller flera isolerade processer i sitt eget användarutrymme.
Dockers modell kretsar kring containerns huvudprocess. Om processen i förgrunden avslutas avslutas även en frikopplad container. Containrar byggs därför normalt kring en långvarig tjänst, till exempel en webbserver, databas, synkroniseringsdemon eller applikationsarbetare.
Officiella Ubuntu- och Debian-avbildningar är minimala basavbildningar
Den aktuella officiella Ubuntu-avbildningen är byggd från Canonicals minimala rotfilsystem, och Docker beskriver den som en minimal installation snarare än en komplett virtuell serverenhet. Den officiella Debian-avbildningen använder på liknande sätt ett minimalt minbase rotfilsystem.
Om du startar en av dem interaktivt med en terminal känns den som en liten Linux-miljö eftersom du får ett skal. När skalet avslutas kanske det inte finns någon återstående tjänst i förgrunden som håller containern igång.
Använd informationen om den underhållna Ubuntu-basavbildningen eller informationen om den underhållna Debian-basavbildningen innan du betraktar någon av dem som en färdig serverenhet.
Varför ubuntu:latest kan stoppas omedelbart
ZimaOS förväntar sig att en installerad Docker-app har en meningsfull långvarig process. En ren distributionsavbildning är vanligtvis en grund för en annan avbildning eller en interaktiv skalmiljö. Om ingen tjänsteprocess har konfigurerats för att fortsätta köras som PID 1 kan containern avslutas normalt i stället för att ”krascha”.
Kontrollera containerloggen och avslutningsstatusen innan du antar att ZimaOS misslyckades med att installera avbildningen. En avslutad container utan någon konfigurerad applikation är ett annat problem än en tjänst som startar och utlöser ett fel.
Om du bara behöver en applikation, börja med applikationen
Användaren förtydligade att de egentligen inte ville ha en fullständig VM. De ville ha en applikation – iDrive – och åtkomst till NAS-lagring. I den situationen är den bästa Docker-designen vanligtvis att hitta en underhållen avbildning för den faktiska applikationen eller skapa en liten avbildning som installerar och startar den applikationen.
Containern bör endast exponera de portar, volymer, autentiseringsuppgifter och enheter som applikationen behöver. Beständiga filer bör ligga i mappad ZimaOS-lagring, inte endast i det flyktiga containerlagret.
Använd Docker Compose för en riktig containertjänst
I community-svaret föreslogs en korrekt Compose-definition i stället för att bara ange ubuntu:latest och ett containernamn. Aktuella ZimaOS har gått ännu längre i den riktningen: det kan importera Docker Compose, redigera YAML och köra stackar med flera containrar med livscykelhantering.
Aktuella riktlinjer från IceWhale säger att standardkonfiguration för containerkörning hör hemma i Docker Compose, medan ZimaOS-specifika butiksmetadata hör hemma i x-casaos.
Använd den aktuella ZimaOS Compose-modellen för självhostade appar i stället för att behandla namnet på en distributionsavbildning som en komplett applikationsdefinition.
Mappa NAS-lagring till containern
Om applikationen bara behöver åtkomst till en mapp mappar du den faktiska ZimaOS-mappen till containern. På värdsidan bör sökvägen peka på en säkerhetskopierings- eller datamapp i den avsedda lagringspoolen, medan containersidan exponerar en enkel sökväg som applikationen förväntar sig.
I aktuella ZimaOS förklaras hur lagring på värdsystemet mappas till containersökvägar. Detta är vanligtvis mindre resurskrävande än att köra en hel Debian-VM bara för att komma åt en mapp.
Använd ZVM när programvaran förväntar sig en komplett Linux-maskin
En virtuell maskin passar bättre när installationsprogrammet för applikationen förväntar sig saker som:
- en konventionell pakethanterare och ett förändringsbart systemfilsystem;
- systemd eller flera tjänster på operativsystemnivå;
- beteende på kärnnivå som inte kan tillhandahållas på ett säkert sätt via en container;
- en traditionell Linux-servermiljö som administreras via SSH;
- programvara från en leverantör som uttryckligen stöder installationer på Ubuntu/Debian, men inte Docker.
Det stämmer med det första svaret från communityn: om målet är ett fristående Debian- eller Ubuntu-operativsystem ska du använda ZVM i stället för att tvinga en bascontaineravbildning att fungera som en fullständig VM.
Installera inte appen i ZimaOS rotfilsystem i stället
Att gå från ”Ubuntu-containern avslutas” till ”jag installerar programvaran med apt på själva ZimaOS” är vanligtvis fel riktning. Aktuella ZimaOS håller de flesta systemmappar skrivskyddade med flit och är inte en generell Debian-/Ubuntu-värd med apt som sin vanliga modell för applikationshantering.
Containrar och virtuella maskiner finns just för att programberoenden ska kunna hållas åtskilda från ZimaOS-bassystemet.
När en Ubuntu-/Debian-baserad avbildning fortfarande är användbar
Det finns legitima skäl att bygga från ubuntu eller debian: målprogramvaran kanske bara publicerar installationsanvisningar för dessa distributioner, eller så kan du behöva deras paketförråd under byggandet av avbildningen.
I så fall skapar du en Dockerfile- eller Compose-baserad avbildning som installerar applikationen och definierar ett riktigt kommando i förgrunden. Förlita dig inte på att manuellt öppna ett skal, installera paket interaktivt och hoppas att den ändrade containern blir en beständig app. När containern återskapas kan ändringar som inte byggts in i avbildningen eller sparats i beständiga volymer gå förlorade.
En omstartspolicy ersätter inte en saknad huvudprocess
Dockers omstartspolicyer är användbara för en riktig tjänst som ska startas igen efter en omstart eller ett oväntat avslut. De förvandlar inte en annars avslutad skalsession till en applikationsserver. Om containerns avsedda arbete redan är slutfört skapar upprepade omstarter bara en loop.
Välj det minsta isoleringslagret som passar programvaran
- Appen har redan en underhållen Docker-avbildning: använd den avbildningen.
- Appen kan paketeras från Ubuntu-/Debian-beroenden: bygg en riktig applikationscontainer.
- Appen behöver en komplett konventionell Linux-värd: använd ZVM.
- Du behöver bara åtkomst till lagring: mappa de NAS-mappar som krävs i stället för att virtualisera hela disken.
Vanliga frågor om Ubuntu och Debian på ZimaOS
Varför installeras ubuntu:latest men fortsätter inte att köras?
En avbildning av en basdistribution är inte automatiskt en tjänst som körs hela tiden. En Docker-container behöver en huvudprocess som fortsätter att köra.
Är ubuntu:latest en fullständig virtuell Ubuntu-maskin?
Nej. Det är en minimal containeranvändarmiljö som delar värdkärnan.
Bör jag använda ZVM för alla Linux-applikationer?
Nej. En riktig Docker-applikation är vanligtvis lättare och enklare att hantera när programvaran stöder containrar.
När är ZVM det bättre valet?
Använd en VM när programvaran förväntar sig en traditionellt föränderlig Ubuntu-/Debian-server med systemtjänster eller installationsantaganden som inte passar i en container.
