Soluzione della community

Scopri quali porte usano le app di ZimaOS: Dockpeek, mappatura delle porte Docker e la trappola dei socket

A January 2026 thread asking for a GUI list of ports used by ZimaOS applications. Community users suggested Docker inspection and Dockpeek; one tester broke Dockpeek by replacing its required /var/run/docker.sock volume, then confirmed reinstalling it with the original socket mapping restored container visibility.

In questa discussione di gennaio 2026, ZimaOS non offriva una dashboard dedicata a tutte le porte delle applicazioni, quindi gli utenti ricorrevano all'ispezione a livello Docker e a uno strumento dell'App Store della community chiamato Dockpeek. Dockpeek può fornire esattamente la panoramica desiderata dall'autore del post originale: nome del container, immagine, porte pubblicate, stato e metadati correlati in un'unica tabella.

La discussione ha inoltre evidenziato un problema importante e specifico di Docker. Un utente ha seguito la propria abitudine di modificare i percorsi dei volumi delle app di terze parti impostandoli su /DATA/AppData/... e ha accidentalmente sostituito il mount speciale del socket Docker di Dockpeek. L'app si apriva, ma non mostrava alcun container. Reinstallandola senza modificare il volume del socket, l'elenco è tornato visibile.

L'inventario delle porte ha due significati diversi

Per le app Docker, è utile distinguere tra:

  • porta del container: la porta su cui l'applicazione è in ascolto all'interno di Docker;
  • porta dell'host: la porta che ZimaOS espone sulla propria interfaccia di rete.

Una mappatura come host 3420 → container 8000 significa che gli utenti si connettono all'host ZimaOS sulla porta 3420, anche se l'applicazione è in ascolto sulla porta 8000 all'interno del container.

Dockpeek offre una visualizzazione grafica delle porte dei container

Dashboard di Dockpeek con l'elenco dei container Docker di ZimaOS, delle immagini, delle porte pubblicate e dello stato di integrità
Dockpeek ha fornito alla community la panoramica richiesta, immediata e completa, delle porte host utilizzate dalle diverse app Docker.

Lo screenshot originale mostra container con porte pubblicate come 9100, 8888, 8443, 8090, 8081 e 7580, insieme ai nomi e alle immagini delle applicazioni corrispondenti.

Una schermata Dockpeek vuota non significa che Docker non abbia container

Dashboard di Dockpeek senza container dopo la modifica della mappatura del socket Docker
Inizialmente, un utente vedeva un elenco Dockpeek vuoto anche se il server ZimaOS eseguiva numerose applicazioni.

Il problema non riguardava il rilevamento di Docker. Dockpeek deve poter accedere al socket Unix di Docker per interrogare il demone.

Mantieni /var/run/docker.sock mappato sullo stesso percorso del container

Impostazioni di Dockpeek in ZimaOS con /var/run/docker.sock mappato sullo stesso percorso all'interno del container e DOCKER_HOST che utilizza il socket Unix
Dockpeek dipende dal socket Docker dell'host e dal valore DOCKER_HOST corrispondente per elencare i container.

Questo volume non contiene dati dell'applicazione. Sostituirlo con una normale cartella AppData rimuove il collegamento di Dockpeek al demone Docker.

Non tutti i volumi devono essere spostati in AppData

L'utente ha spiegato che i pacchetti di terze parti dell'App Store lo avevano abituato a controllare attentamente i percorsi dei volumi e a spostare i dati persistenti nelle posizioni AppData standard. Questo è generalmente sensato per i database e le configurazioni delle applicazioni, ma mount speciali come socket Docker, dispositivi, certificati o file di sistema dell'host hanno uno scopo diverso.

La documentazione attuale di ZimaOS spiega come i normali dati delle applicazioni vengono mappati nello spazio di archiviazione dell'host. Usa questo modello per i dati persistenti, ma non modificare un mount di sistema speciale se non hai compreso perché il container ne ha bisogno.

Una porta già in uso deve essere ricondotta al proprietario attuale

L'autore del post originale voleva liberare specificamente le porte 80 e 443 dopo una precedente installazione di Nginx. Una risposta della community ipotizzava che ZimaOS utilizzasse almeno la porta 80. La discussione non conteneva una conferma di IceWhale secondo cui entrambe le porte siano riservate permanentemente in ogni versione.

Prima di eliminare un'app o modificare la porta di una dashboard, identifica il listener effettivo o la mappatura Docker presente nel sistema in uso.

Anche la CLI Docker può produrre un inventario delle porte

Un membro della community ha condiviso comandi Docker che elencano i nomi dei container, le immagini e le assegnazioni delle porte e possono esportarli in un file di testo. Poiché tali comandi sono stati creati dalla community e non sono istruzioni di IceWhale, questa pagina ne conserva l'idea senza presentare la pipeline shell esatta come procedura ufficiale di ZimaOS.

Per gli utenti che preferiscono il terminale, l'ispezione dei container Docker fornisce i dati alla base di ciò che Dockpeek visualizza.

L'accesso al socket Docker è potente

Un container che può accedere a /var/run/docker.sock può ispezionare e potenzialmente controllare il demone Docker, a seconda delle funzionalità dell'applicazione. Considera Dockpeek e strumenti di gestione simili come infrastruttura privilegiata, non come normali app web.

Non esporre pubblicamente la WebUI di Dockpeek senza autenticazione e un adeguato livello di controllo degli accessi.

Domande frequenti sulla visualizzazione delle porte di ZimaOS

Dockpeek può mostrare quale app ZimaOS possiede una porta Docker pubblicata?

Sì. Lo screenshot originale mostra insieme nomi dei container, immagini, mappature delle porte e stato.

Perché Dockpeek non mostrava alcun container per un utente?

L'utente aveva modificato il volume obbligatorio /var/run/docker.sock. Reinstallando l'app senza modificare quel mount speciale, l'elenco è tornato visibile.

Ogni volume di un'app di terze parti deve essere spostato in /DATA/AppData?

No. I dati persistenti delle app spesso appartengono a quella posizione, ma i mount speciali, come il socket Docker, devono mantenere la risorsa host prevista.