Containers, Containers, Containers
Dopo aver scassato il server Linux per l’ennesima volta a causa di script che non sono pensati per essere undone, mi son deciso a passare alle maniere forti. Si tratta di un problema di isolamento: installi la minchiata X che interferisce con la minchiata Y e all’improvviso l’applicazione Z smette di funzionare.
Nei grossi data-center l’isolamento viene risolto con una macchina virtuale per ogni app. Per il mio Cray-1 però sarebbe un po’ esagerato.
Il pallino mi è venuto quando ho pensato di installare a casa pi-hole (e in futuro usarlo in cascata con qualche DNS più aggressivo per evitare altra roba come il phishing) ma di dedicarci un Raspberry Pi davvero non mi andava: andrebbe alimentato e sono a corto di prese elettriche; e andrebbe connesso via LAN e sono a cortissimo di porte di rete a meno di installare uno switch che richiederebbe alimentazione aggiuntiva. E allora perché non virtualizzare?
Nel frattempo tra virtualizzazione full-plus (quella della mia Workstation Windows 10) e para-virtualizzazione, si è sviluppata una via di mezzo, quella dei containers. Ho pensato di dare un’occhiata a LXC per non dovermi sobbarcare l’onere di imparare qualcosa di profondo come Dockers da zero.
In poche parole un container LXC è una macchina virtuale in tutto e per tutto, senza la penalizzazione dovuta all’emulazione HW.
E così ho creato il mio primo container, collegatolo al bridge di rete esistente e la nuova macchina pseudo-virtuale è diventata visibile a tutta la LAN. Ci ho installato pi-hole, configurato il router assegnandovi un IP dedicato, impostato il DNS e tutta la LAN magicamente ha cominciato a filtrare pubblicità. Per sfizio ho provato anche la compatibilità binaria, copiando sul container una app scritta in Go. Anche quello ha funzionato, lasciandomi un po’ perplesso. Nell’informatica quando va tutto TROPPO LISCIO…
L’ultima prova è stata quella di esporre un intero file system dell’host al container. Rilassando un po’ la sicurezza è stato possibile anche testare che il container avesse la possibilità di modificare i file dell’host.
Next step trasformare in container tutto il trasformabile, ovvero
- un container per SAMBA e annessi e connessi
- un container per Crashplan
- un container per servizi vari ed eventuali: pi-hole e BFTS
L’obiettivo finale è quello di, una volta salvata in file la configurazione di ciascun container, ridurre al minimo l’installabile sul metallo dopo il prossimo eventuale formattone: ZFS, LXC e KVM, roba scriptabile in 10 righe o meno di bash.
-quack