In teoria, non c’è nessuna differenza fra teoria e pratica. Ma, in pratica, c’è. — Yogi Berra
Indice Serie Homelab
Libertà digitale: creare un ecosistema di servizi personali senza dipendere dalle big tech.
Da Teoria a Pratica Link to heading
Dopo aver descritto nel primo articolo la motivazione e l’hardware scelto per il mio homelab, è arrivato il momento di sporcarsi le mani. L’HP 260 G4 è arrivato, Proxmox VE è stato installato, e ora inizia il bello: configurare tutto per bene.
Installazione Proxmox VE Link to heading
L’installazione di Proxmox è stata sorprendentemente semplice. Ho scaricato l’ISO dal sito ufficiale, creato una USB bootable e seguito il wizard di installazione.
In meno di 15 minuti avevo il sistema operativo pronto e l’interfaccia web accessibile.
Il Warning della Subscription Link to heading
Una volta loggato nella web interface, ho subito notato il messaggio rosso:
Niente panico, è normale. Proxmox ha due repository:
- Enterprise Repository: Richiede abbonamento a pagamento, più stabile per ambienti di produzione
- No-Subscription Repository: Gratuito, perfetto per homelab e testing
Per rimuovere il warning e ricevere gli aggiornamenti, basta modificare i repository. Si può fare tramite interfaccia web (Node → Updates → Repositories) disabilitando quello enterprise e aggiungendo quello no-subscription, oppure via console modificando /etc/apt/sources.list.d/pve-enterprise.list.
Decisioni Infrastrutturali Link to heading
Prima di procedere con la creazione dei container, è importante definire alcuni aspet ti architetturali fondamentali che influenzeranno tutto il setup futuro: come gestire lo storage dei dati, come organizzare i servizi nei container, e quale approccio adottare per bilanciare isolamento ed efficienza delle risorse.
Strategia Storage: Separazione Sistema e Dati Link to heading
Una delle decisioni più importanti nell’architettura di un homelab è come gestire lo storage. Con l’SSD interno da soli 256GB e la previsione di crescita dei dati, ho optato per una separazione netta fin dall’inizio aggiungendo un SSD esterno dedicato.
Questa scelta potrebbe sembrare prematura - dopotutto, con circa 50GB di foto attuali, avrei ancora margine sul disco interno. Ma è proprio questo il punto: implementare l’architettura corretta prima di trovarsi con il disco pieno è una scelta lungimirante. Separare sistema e dati da subito significa non dover mai affrontare migrazioni forzate o riorganizzazioni complesse quando lo spazio inizierà a scarseggiare.
Il controllo indipendente dei backup è un altro fattore determinante. Poter fare snapshot solo dei dati senza coinvolgere tutto il sistema operativo semplifica enormemente la strategia di backup e recovery. E quando arriverà il momento di espandere lo storage - perché arriverà - sarà questione di sostituire un singolo disco esterno anziché riprogettare l’intera architettura.
Directory Storage vs Bind Mount Points Link to heading
Inizialmente avevo valutato i Bind Mount Points per il controllo granulare: poter strutturare i dati come volevo sull’host, dare a ogni container accesso solo alle directory necessarie, e mantenere piena visibilità su cosa succede al filesystem. L’approccio “hands-on” perfetto per un homelab di apprendimento.
Però dopo aver sperimentato con mapping UID complessi, problemi di permessi tra host e container LXC unprivileged, e debug di configurazioni che funzionavano “quasi sempre”, mi sono reso conto che stavo complicando inutilmente.
Il Directory Storage di Proxmox offre esattamente quello che serve: colleghi il disco, lo aggiungi tramite GUI, e tutti i container lo vedono automaticamente. È l’approccio “zero configurazione” che funziona bene e, soprattutto, funziona sempre. A volte la semplicità vince sulla complessità, specialmente quando l’obiettivo è avere servizi stabili e funzionanti.
Implementazione Pratica Link to heading
La struttura che ho pianificato è semplice ma flessibile:
/mnt/external-ssd/
├── immich/
│ ├── photos/
│ └── database/
└── navidrome/
└── music/
Ogni servizio ha la sua area dedicata, posso fare backup selettivi per categoria, e aggiungere nuovi servizi significa semplicemente creare una nuova directory. Dal punto di vista delle performance è identico al Directory Storage - i container accedono direttamente al filesystem dell’host senza overhead.
L’architettura finale separa chiaramente i ruoli: l’SSD interno ospita Proxmox, i container LXC e le applicazioni Docker, mentre l’SSD esterno si concentra esclusivamente sui dati persistenti. Quando Immich processerà migliaia di foto o quando aggiungerò la libreria musicale, il sistema rimarrà reattivo perché i dati pesanti vivono sul disco dedicato.
Filosofia Container: L’Equilibrio tra Isolamento ed Efficienza Link to heading
Un’altra decisione architettturale importante è la granularità dei container: un servizio per container o più servizi raggruppati? È una domanda che va oltre la semplice efficienza - tocca aspetti di manutenibilità, debug e strategia di backup.
La mia prima inclinazione era creare container separati per ogni servizio. L’isolamento totale è elegante: se Immich ha problemi, Navidrome continua imperterrito. Debug e aggiornamenti diventano operazioni chirurgiche che non rischiano di compromettere altri servizi. E a livello di backup, fare snapshot granulari di singoli servizi è un lusso che semplifica enormemente il recovery.
C’è da considerare l’overhead di risorse: secondo la documentazione Proxmox, un container LXC Ubuntu consuma circa 50-100MB di RAM per l’OS di base. Ma parliamo di numeri irrisori su un sistema con 16GB - per quello che prevedo di fare non arriverò mai neanche lontanamente a saturare la RAM.
I Vantaggi dell’Isolamento Totale Link to heading
Nonostante l’overhead, i container singoli offrono vantaggi concreti:
- Fault isolation: Un crash di Immich non tocca minimamente Navidrome
- Risorse dedicate: Posso allocare 6GB a Immich e 2GB a Navidrome senza conflitti
- Backup granulari: Snapshot di Immich senza coinvolgere altri servizi
- Aggiornamenti sicuri: Test di nuove versioni in isolamento completo
- Portabilità: Migrare un servizio significa spostare un solo container
La Decisione: Container Separati Link to heading
Visti tutti i vantaggi dell’isolamento e l’irrilevanza dell’overhead di RAM per il mio caso d’uso, mantengo un container per ogni servizio. L’isolamento totale, i backup granulari e la semplicità di debug superano di gran lunga qualsiasi considerazione teorica sull’efficienza delle risorse.
Primo Container LXC Link to heading
Con le decisioni architetturali definite, posso procedere alla creazione del primo container per testare l’intera configurazione. Ho creato un container LXC con Ubuntu per ospitare Docker e verificare l’integrazione con lo storage esterno:
- Template: Ubuntu 22.04 LTS
- RAM: 4 GB
- Swap: 1 GB
- Storage: 10 GB su SSD interno
- CPU: 4 core
Il container si è avviato in pochi secondi - una delle magie di LXC rispetto alle VM tradizionali. Le risorse sono comunque espandibili in qualsiasi momento tramite l’interfaccia web di Proxmox.
Installazione Docker Link to heading
Una volta dentro il container Ubuntu, ho installato Docker utilizzando il comando ufficiale che scarica lo script di installazione ufficiale in base alla tua macchina, e configura tutto automaticamente:
curl -fsSL https://get.docker.com | sudo sh
Test e Verifica Link to heading
Questo container di test mi permette di verificare che tutto l’ecosistema funzioni correttamente: Docker si avvia senza problemi, l’accesso al storage esterno tramite bind mount è operativo, e le performance sono in linea con le aspettative prima di procedere con il deploy dei servizi definitivi.
Prossimi Passi Link to heading
Con Proxmox configurato, il primo container LXC operativo e lo storage esterno pronto, la base dell’homelab è solida. È il momento di deployare il primo servizio reale.
→ Continua con: Homelab: Deploy Immich e Gestione Foto dove installeremo e configureremo Immich