Vent’anni di self-hosting: perché u/jc-21 tiene un piccolo homelab

Eva Wong

IceWhale author

Eva Wong è la redattrice tecnica e appassionata di tecnologia di ZimaSpace. Geek da sempre, appassionata di homelab e software open source, è specializzata nel tradurre concetti tecnici complessi in guide pratiche. Eva crede che l’hosting autonomo debba essere divertente, non intimidatorio. Attraverso i suoi tutorial, aiuta la community a comprendere meglio le configurazioni hardware, dalla costruzione del primo NAS alla padronanza dei container Docker.

Official Nginx Proxy Manager proxy-host list screenshot

Immagine di copertina: Raspberry Pi — foto ufficiale del prodotto Raspberry Pi 5.

Un home lab utile ha un suo ritmo. I servizi domestici funzionano, il proprietario sa dove si trovano i dati importanti e un esperimento può aspettare che chi usa la rete abbia finito la giornata. È questo tipo di progresso che speravamo di ascoltare quando abbiamo invitato la community a condividere le storie della propria giornata dedicata al self-hosting.

Nel contributo di u/jc-21, circa vent’anni di sperimentazione portano a una configurazione Linux volutamente semplice. L’autore descrive un router FriendlyWrt, un Raspberry Pi 5 per i servizi quotidiani, tra cui AdGuard e Nginx Proxy Manager, e un NAS per i carichi di lavoro più pesanti o meno compatibili con ARM, come Plex. I computer compatti e le apparecchiature di rete sono collegati a un UPS. L’autore si presenta inoltre come creatore di Nginx Proxy Manager, collegando la necessità personale di semplificare l’accesso a un progetto open source.

«Il mio lab è piccolo, pratico e noioso nel senso migliore del termine»
u/jc-21

L’aggiornamento dell’architettura chiarisce la divisione delle responsabilità

Dal punto di vista di ZimaSpace, l’idea applicabile anche ad altri contesti è la separazione delle responsabilità. Il nucleo dei servizi quotidiani richiede una routine di manutenzione diversa da quella di una macchina usata per esperimenti di archiviazione o applicazioni impegnative. Una volta definiti chiaramente i ruoli, diventa più facile motivare le scelte hardware: cosa deve rimanere disponibile, cosa richiede maggiore capacità e cosa si può riavviare senza interrompere il lavoro di qualcun altro?

Inizia dalle dipendenze, non dall’elenco dei container. Un’applicazione può funzionare correttamente mentre gli utenti non riescono a raggiungerla perché un nome non viene più risolto o il percorso di accesso scelto non è disponibile. Crea una breve mappa che colleghi l’azione di un utente ai servizi che la supportano. Può essere una pagina di appunti. È utile perché descrive il sistema con sufficiente precisione da evitare che la manutenzione si trasformi in un esercizio di supposizioni.

Una mappa pratica per pianificare un piccolo home lab

Responsabilità	Domanda di pianificazione	Un registro utile
Servizi quotidiani	Di cosa ha bisogno la famiglia durante una giornata normale?	Una mappa delle dipendenze e un controllo dal lato client.
Applicazioni	Quali carichi di lavoro richiedono risorse proprie o una finestra di manutenzione?	Versione, posizione della configurazione e procedura di riavvio.
Dati condivisi	Dove si trovano i file autorevoli e chi può modificarli?	Disposizione dello spazio di archiviazione e decisioni sugli accessi.
Ripristino	Che cosa resta disponibile in caso di guasto di un dispositivo o di interruzione di una modifica?	Una copia indipendente e l’esito documentato di un ripristino.

Programma la manutenzione ordinaria del nucleo dei servizi

Un piccolo nucleo di servizi sempre attivi è utile quando il suo comportamento è prevedibile. Assegna a ogni servizio essenziale un responsabile identificato, una posizione nota per la configurazione e un modo per verificare che svolga davvero il proprio compito. Per un servizio DNS, significa controllare da un client una risoluzione rappresentativa. Per un’applicazione domestica, significa aprirla tramite il percorso usato abitualmente dalle persone. Un indicatore di processo attivo è solo una parte di questa verifica.

Mantieni le modifiche abbastanza contenute da poterle annullare. Annota la versione attuale dell’applicazione e conserva la configurazione prima di un aggiornamento. Scegli una finestra di manutenzione adatta alle persone che usano il sistema, poi verifica il normale funzionamento dal client. Sono abitudini operative che una piccola installazione può adottare senza creare una piattaforma di gestione elaborata. La misura utile è quanto il proprietario sappia spiegare e ripristinare una modifica con sicurezza.

Elenco ufficiale degli host proxy di Nginx Proxy Manager — L’elenco degli host proxy del progetto mostra le destinazioni in un unico posto; conserva anche il contesto delle applicazioni e degli accessi correlati. Immagine: progetto Nginx Proxy Manager.

Un proxy inverso merita un posto a sé nella mappa dei servizi

La documentazione ufficiale del progetto Nginx Proxy Manager descrive un approccio grafico alla gestione degli host proxy e dei certificati. È un esempio utile di un servizio la cui configurazione collega diverse altre applicazioni. Tieni traccia di quale nome host conduce a quale destinazione, di dove l’applicazione stessa archivia i dati e di quale account controlla l’accesso.

Una comoda interfaccia proxy non elimina la necessità di capire l’applicazione che si trova dietro. Esamina ogni percorso nella sua interezza: client, nome, proxy, destinazione e account dell’applicazione. Decidi con attenzione quali percorsi devono essere disponibili sulla rete locale o tramite un accesso remoto privato. Se un’applicazione viene spostata su un’altra macchina, aggiorna la mappa e prova l’indirizzo salvato da un client reale prima di considerare conclusa la migrazione.

Modulo ufficiale di configurazione degli host proxy di Nginx Proxy Manager — L’esempio ufficiale di configurazione degli host proxy di Nginx Proxy Manager mostra le impostazioni di destinazione da includere nella mappa dei servizi. Immagine: progetto Nginx Proxy Manager.

Pianifica l’alimentazione e il ripristino in base ai servizi che le persone notano

Un piano per le interruzioni dovrebbe spiegare quali funzionalità restano utili quando una parte del sistema smette di funzionare. Individua i dispositivi necessari per mantenere attivo quel percorso, comprese le apparecchiature di rete pertinenti, invece di considerare solo il server. Se utilizzi un UPS, misura il carico effettivo collegato e verifica il comportamento di spegnimento previsto. L’autonomia dipende dalla batteria, dal carico e dalla configurazione; va determinata per l’installazione specifica, non dedotta dalle dimensioni del dispositivo.

Tieni le istruzioni per il ripristino in un luogo diverso dal servizio a cui si riferiscono. Uno schema di rete archiviato solo dietro un servizio di accesso non funzionante è scomodo proprio nel momento meno opportuno. Conserva una copia accessibile delle note importanti, un percorso documentato per raggiungere il backup e una procedura per ripristinare il sistema in un ordine sensato. In questo modo sarà più facile gestire una normale interruzione domestica senza trasformare ogni guasto in una serata passata a ricostruire tutto da capo.

Dove si inserisce ZimaCube 2 quando il livello dati cresce

Per chi adotta una divisione simile dei compiti, un NAS cloud personale ZimaCube 2 può fornire il livello dati condiviso insieme a una macchina già utilizzata per i servizi quotidiani. Questo è il nostro suggerimento per la pianificazione dell’hardware: il contributo della community descrive un’installazione diversa. Archivia i contenuti multimediali da conservare, i file di progetto e i dati delle applicazioni in posizioni gestite in modo chiaro, quindi decidi quali client e servizi devono accedere a ciascuna area.

Gli alloggiamenti per unità e le opzioni di espansione M.2 di ZimaCube 2 offrono spazio per pianificare una raccolta in crescita in base ai diversi ruoli di archiviazione. Dimensiona la configurazione in base ai dati da conservare, ai servizi effettivamente in esecuzione e al backup indipendente che intendi mantenere. Spostare i dati in un case più grande non richiede di trasferire contemporaneamente tutti i servizi domestici. Un passaggio graduale mantiene comprensibile il sistema attuale mentre si sviluppa il ruolo dell’archiviazione.

Vista frontale ufficiale del NAS cloud personale ZimaCube 2 color argento — Fotografia ufficiale del prodotto ZimaCube 2, che illustra l’opzione di archiviazione condivisa discussa nelle note di pianificazione di ZimaSpace. Immagine: ZimaSpace.

Fai in modo che il prossimo aggiornamento sia un passaggio di consegne che sai spiegare

Scegli una raccolta o una scheda applicativa per una migrazione di prova. Conservane la posizione attuale, copiala nella destinazione proposta e verifica l’accesso dal client previsto. Documenta eventuali modifiche a percorsi o account, poi ripristina un campione dal backup in una posizione separata. Un trasferimento completato è più convincente quando un’altra persona riesce a trovare le stesse informazioni e a capire quale copia è quella di riferimento.

Lascia una breve nota di consegna sul sistema: servizi quotidiani, archiviazione condivisa, copia di ripristino e modifiche ancora in fase di test. Per un esempio più approfondito di virtualizzazione, il nostro setup community con Proxmox su ZimaBoard 2 mostra un altro modo per organizzare un laboratorio domestico in espansione. L’obiettivo è lo stesso: un sistema che rimane utile mentre il proprietario continua a imparare.

Il consiglio del Self-Hosting Day

Per il Self-Hosting Day, il consiglio pratico è un principio operativo: rendi il sistema di tutti i giorni abbastanza comprensibile da potertene fidare e tieni a disposizione uno spazio separato per sperimentare. Un nucleo compatto di servizi e un livello dati ben gestito possono crescere a ritmi diversi.

Continua a esplorare

Racconto originale e riferimenti al progetto

Basato sul contributo pubblico per il Self-Hosting Day collegato sopra. L’interpretazione dell’architettura e le note sulla pianificazione dell’hardware sono di ZimaSpace. Gli screenshot e le illustrazioni dei prodotti sono attribuiti ai rispettivi progetti o produttori originali.