Digitare ubuntu:latest nel campo “Installa un'app personalizzata” di ZimaOS non crea automaticamente un piccolo server Ubuntu sempre attivo. L'immagine è un filesystem container Ubuntu minimo, non una macchina virtuale preconfigurata con una sequenza di avvio completa, un demone SSH, un gestore dei servizi e un'applicazione in background già in esecuzione.
Questa distinzione spiega il caso di origine dell'ottobre 2025. L'immagine poteva essere scaricata e si poteva creare un container, ma non rimaneva in esecuzione come l'utente si aspettava. La soluzione corretta dipende dall'obiettivo reale: eseguire una singola applicazione in un container oppure eseguire un sistema operativo Debian/Ubuntu completo e generico all'interno di una VM.
Un container Docker non è una piccola macchina virtuale
Una macchina virtuale emula un ambiente informatico completo e avvia il proprio stack del sistema operativo. Un container condivide il kernel Linux dell'host ed esegue uno o più processi isolati nel proprio spazio utente.
Il modello Docker si basa sul processo principale del container. Se il processo in primo piano termina, anche un container in background termina. Per questo, i container vengono normalmente creati attorno a un servizio di lunga durata, come un server web, un database, un demone di sincronizzazione o un worker applicativo.
Le immagini ufficiali di Ubuntu e Debian sono immagini di base minime
L'immagine ufficiale attuale di Ubuntu è basata sul filesystem root minimo di Canonical e Docker la descrive come un'installazione minima, non come un'appliance VM completa. Anche l'immagine ufficiale di Debian utilizza un filesystem root minimo minbase filesystem root.
Se ne avvii una in modalità interattiva con un terminale, sembra un piccolo ambiente Linux perché hai a disposizione una shell. Quando la shell termina, potrebbe non rimanere alcun servizio in primo piano che mantenga attivo il container.
Consulta le informazioni aggiornate sull'immagine di base ufficiale di Ubuntu o le informazioni aggiornate sull'immagine di base ufficiale di Debian prima di considerare una delle due come un'appliance server preconfigurata.
Perché ubuntu:latest può arrestarsi immediatamente
ZimaOS si aspetta che un'app Docker installata disponga di un processo significativo e di lunga durata. Un'immagine di distribuzione di base è generalmente il fondamento per un'altra immagine o per un ambiente shell interattivo. Se non è configurato alcun processo di servizio che rimanga in esecuzione come PID 1, il container può terminare normalmente anziché “bloccarsi”.
Controlla il log e lo stato di uscita del container prima di presumere che ZimaOS non abbia installato l'immagine. Un container terminato senza alcuna applicazione configurata è un problema diverso da un servizio che si avvia e genera un errore.
Se ti serve una sola applicazione, parti dall'applicazione
L'utente originale ha chiarito che non desiderava davvero una VM completa. Voleva una sola applicazione, iDrive, e l'accesso alla memoria NAS. In questa situazione, di solito la progettazione Docker migliore consiste nel trovare un'immagine mantenuta per l'applicazione effettiva o nel creare una piccola immagine che installi e avvii quell'applicazione.
Il container dovrebbe esporre solo le porte, i volumi, le credenziali e i dispositivi necessari all'applicazione. I file persistenti dovrebbero risiedere nella memoria mappata di ZimaOS, non solo nel livello effimero del container.
Usa Docker Compose per un vero servizio containerizzato
La risposta della community suggeriva una definizione Compose appropriata invece di inserire soltanto ubuntu:latest e un nome del container. L'attuale ZimaOS si è spinto ancora oltre in questa direzione: può importare file Docker Compose, modificare file YAML ed eseguire stack multi-container con controllo del ciclo di vita.
Le indicazioni attuali di IceWhale stabiliscono che la configurazione standard del runtime dei container appartiene a Docker Compose, mentre i metadati specifici di ZimaOS appartengono a x-casaos.
Usa l'attuale modello Compose di ZimaOS per le applicazioni self-hosted invece di trattare il nome di un'immagine della distribuzione come una definizione completa dell'applicazione.
Mappa la memoria NAS nel container
Se l'applicazione deve accedere solo a una directory, mappa quella cartella reale di ZimaOS nel container. Il lato host dovrebbe puntare a una cartella di backup o di dati nel pool di archiviazione previsto, mentre il lato container espone un semplice percorso previsto dall'applicazione.
L'attuale ZimaOS spiega come la memoria dell'host viene mappata nei percorsi del container. Di solito è più leggero che eseguire un'intera VM Debian solo per accedere a una cartella.
Usa ZVM quando il software richiede una macchina Linux completa
Una VM è la scelta migliore quando il programma di installazione dell'applicazione si aspetta elementi come:
- un gestore di pacchetti convenzionale e un filesystem di sistema modificabile;
- systemd o diversi servizi a livello di sistema operativo;
- un comportamento a livello di kernel che non può essere fornito in modo sicuro tramite un container;
- un ambiente server Linux tradizionale amministrato tramite SSH;
- software di un fornitore che supporta esplicitamente le installazioni Ubuntu/Debian, ma non Docker.
Questo coincide con la prima risposta della community: se l’obiettivo è un sistema operativo Debian o Ubuntu autonomo, usa ZVM invece di costringere un’immagine container di base a comportarsi come una VM completa.
Non installare invece l’app nel filesystem principale di ZimaOS
Passare da «il container Ubuntu termina» a «installerò il software direttamente su ZimaOS con apt» è generalmente la direzione sbagliata. L’attuale ZimaOS mantiene intenzionalmente in sola lettura la maggior parte delle cartelle di sistema e non è un host Debian/Ubuntu generico con apt come normale modello di gestione delle applicazioni.
Container e VM esistono proprio per mantenere separate le dipendenze delle applicazioni dal sistema di base ZimaOS.
Quando un’immagine di base Debian/Ubuntu è ancora utile
Esistono validi motivi per creare un’immagine a partire da ubuntu o debian: il software di destinazione potrebbe pubblicare istruzioni di installazione solo per quelle distribuzioni, oppure potresti aver bisogno dei relativi repository di pacchetti durante la creazione dell’immagine.
In tal caso, crea un Dockerfile o un’immagine basata su Compose che installi l’applicazione e definisca un vero comando in primo piano. Non affidarti all’accesso manuale a una shell, all’installazione interattiva dei pacchetti e alla speranza che il container modificato diventi un’app duratura. La ricreazione del container può eliminare le modifiche che non sono state incorporate nell’immagine o archiviate in volumi persistenti.
Una policy di riavvio non sostituisce un processo principale mancante
Le policy di riavvio di Docker sono utili per un vero servizio che deve tornare in esecuzione dopo un riavvio o un’uscita imprevista. Non trasformano una sessione shell altrimenti conclusa in un server applicativo. Se il lavoro previsto dal container è già terminato, riavviarlo ripetutamente crea solo un ciclo.
Scegli il livello di isolamento più semplice compatibile con il software
- L’app dispone già di un’immagine Docker gestita: usa quell’immagine.
- L’app può essere pacchettizzata a partire dalle dipendenze di Ubuntu/Debian: crea un vero container applicativo.
- L’app ha bisogno di un host Linux completo e convenzionale: usa ZVM.
- Ti serve solo l’accesso allo spazio di archiviazione: mappa le cartelle NAS necessarie invece di virtualizzare l’intero disco.
Domande frequenti su Ubuntu e Debian in ZimaOS
Perché ubuntu:latest si installa ma non rimane in esecuzione?
Un’immagine della distribuzione di base non è automaticamente un servizio sempre attivo. Un container Docker ha bisogno di un processo principale che rimanga in esecuzione.
ubuntu:latest è una macchina virtuale Ubuntu completa?
No. È un ambiente utente minimale per container che condivide il kernel dell’host.
Devo usare ZVM per ogni applicazione Linux?
No. Una vera applicazione Docker è generalmente più leggera e facile da gestire quando il software supporta i container.
Quando è preferibile ZVM?
Usa una VM quando il software si aspetta un server Ubuntu/Debian tradizionale e modificabile, con servizi a livello di sistema o presupposti di installazione non compatibili con un container.
