Stefano Marinelli's Blog (Articoli su lxc)

Backup efficienti di container LXC in Proxmox - ZFS

Stefano Marinelli — Wed, 18 Jan 2023 08:34:19 GMT

NOTA: Il seguente post è la traduzione dell'equivalente in inglese sul blog it-notes. L'originale sarà sempre più aggiornato.

Ho già scritto relativamente ad alcune delle mie strategie di backup in Proxmox. Proxmox Backup Server è un valido strumento, ma non è sempre l'opzione migliore, soprattutto se si utilizzano container lxc.

I container LVM e Ceph RBD sono già stati trattati in un altro post, ma una delle (molte) ottime opzioni, se si usa Proxmox, è ZFS. Utilizzo ampiamente ZFS sia su FreeBSD che su Linux (e ho sempre desiderato che BTRFS potesse raggiungere lo stesso livello di affidabilità).

Quando non ho bisogno di un file system in rete (come Ceph) o voglio superare i limiti di LVM, tendo a installare le VM di Proxmox e i container lxc su ZFS. Concentriamoci ora sul backup dei container lxc.

Proxmox utilizza i dataset ZFS per lo storage dei container lxc, quindi tutti i file si trovano su /nome-pool/subvol-x-disk-y. Possiamo eseguire facilmente il backup come abbiamo fatto nel mio precedente articolo, abbiamo solo bisogno di un modo diverso per eseguire le snapshot di tutti questi dataset.

I dataset ZFS forniscono una directory .zfs, nascosta, che contiene tutte le istantanee attualmente esistenti di quel dataset specifico. "ls" non la mostrerà, ma si può fare un "cd" e sarà utilizzabile.

Naturalmente si può usare zfs send/receive in maniera nativa (o un utile software che uso quotidianamente, zfs-autobackup, sia per le istantanee locali che per la replica remota), ma vogliamo salvare i file, non il dataset zfs, in modo da poter eseguire il backup su un file system diverso. Qualsiasi file system. Quindi useremo borg backup.

Supponiamo che il nostro pool ZFS sia chiamato "proxzfs". Ecco uno script di esempio. Naturalmente, questo è il mio script, funziona per me e non sono responsabile se non funziona per voi/distrugge tutti i vostri dati/mangia il vostro server/ecc.

#!/bin/bash

/usr/sbin/zfs snapshot -r proxzfs@forborg

REPOSITORY=yourpath/server/whatever:borgrepository/
TAG=mytag
borg create -v --stats --compression zstd --progress    \
   $REPOSITORY::$TAG'-{now:%Y-%m-%dT%H:%M:%S}'          \
   /proxzfs/*/.zfs/snapshot/forborg/  \
   --exclude '*subvolYouMayWantToExclude-disk-0*'

/usr/sbin/zfs destroy -vrR proxzfs@forborg

borg prune -v $REPOSITORY --stats --prefix $TAG'-' \
   --keep-daily=31 --keep-weekly=4 --keep-monthly=12

Questo piccolo script creerà un'istantanea @forborg per qualsiasi dataset che troverà sotto "proxzfs", quindi avvierà borg e gli chiederà di attraversare le snapshot forborg montate automaticamente all'interno della directory .zfs di qualsiasi dataset.

Quindi distruggerà le istantanee "forborg" ed eseguirà un prune di borg. Questo eliminerà i vecchi backup, in base alla politica impostata. Questo passaggio può essere evitato, ma io preferisco eseguirlo dopo un backup, in modo che il mio repository sia sempre coerente con la mia politica di data retention.

Docker e la nuova separazione dei servizi

Stefano Marinelli — Tue, 03 Apr 2018 17:45:46 GMT

Se c'è una cosa che mi piace, nell'ambito informatico, è il trovare nuove soluzioni a vecchi problemi. O nuovi problemi a vecchie soluzioni, ma allo scopo di risolvere eventuali punti lasciati in sospeso da tempo, per mancanza di tempo o per mancanza di soluzioni a disposizione.

Una delle questioni più annose, per chi lavora nel settore (ma non solo) è sempre la vecchia scelta operativa: accentrare i servizi su un server o separarli il più possibile?

Continua la lettura… (ulteriori 2 minuti di lettura)

Un assaggio di Proxmox

Stefano Marinelli — Mon, 28 Aug 2017 12:22:14 GMT

Proxmox, la storia

Proxmox nasce nel 2008 come sistema completo di virtualizzazione (alternativo a prodotti come VMWare) "a pacchetto". Lo scopo è sempre stato, ed è ancora, quello di fornire un sistema semplice e pratico di preparazione di hardware fisico allo scopo di ospitare macchine virtuali, il tutto gestito attraverso una comoda interfaccia web.

Fino alla versione 3.0, Proxmox ha sofferto di serie problematiche di gioventù. Pur essendo, infatti, già sufficientemente maturo, c'erano alcuni problemi (bug o mancanza di feature) che non lo rendevano estremamente adatto ad ambienti di produzione importanti. Dalla 3.0 in poi, invece, si è assistito al lancio verso l'olimpo in quanto le funzionalità di base erano ormai mature e affidabili e le nuove opzioni erano tutte incentrate sul renderlo sempre più un prodotto enterprise.

Sviluppato e diretto dall'Austriaca Proxmox Server Solutions GmbH, è un progetto in rapido progresso e con interessantissime funzionalità che si aggiungono versione dopo versione.

Il sistema è interamente Open Source, prevede la possibilità di acquistare un abbonamento (a prezzi molto vantaggiosi) per accedere al repository di aggiornamento enterprise, più collaudato e sicuro di quello standard, e tutto il supporto e l'assistenza necessari al sistemista che ne possa avere necessità.

Continua la lettura... … (ulteriori 7 minuti di lettura)

Un assaggio di Docker

Stefano Marinelli — Sat, 05 Aug 2017 19:30:12 GMT

Preambolo

Ho fatto i primi passi nella virtualizzazione nel lontano 1998. Mi affascinava l'idea di inscatolare un intero computer all'interno del mio PC e non dover più essere schiavo di installare, cancellare, reinstallare, avere due sistemi operativi diversi per scopi diversi contemporaneamente nella stessa macchina e avere eventuali problemi di boot all'aggiornamento di uno ei due.

Sperimentai dunque VMWare e capii subito che la virtualizzazione sarebbe stata il futuro. Nel corso degli anni la penalizzazione sulle prestazioni si è via via assottigliata e nella mia tesi di laurea, nel 2003, mi occupai proprio degli internal di vari virtualizzatori tra cui il neonato i QEMU. Il bello di qemu era proprio la possibilità di emulare piattaforme hardware diverse per lo sviluppo o l'emulazione, e in maniera sufficientemente (per l'epoca) rapida grazie alla traslazione dinamica delle chiamate di sistema, un metodo per l'epoca rivoluzionario. C'erano anche i primordi di Xen, che dava risultati assolutamente interessanti ma richiedeva modifiche al sistema operativo guest. Venne poi fuori un modulo kernel per qemu (divenuto poi KVM, la base dei principali virtualizzatori moderni) che gestiva la virtualizzazione passando direttamente le chiamate all'hardware sottostante, abbattendo l'overhead prestazionale a livelli bassissimi e consentendo di avere un buon numero di VM su un server fisico.

Da allora mi occupo di virtualizzazione ma ho sempre cercato anche altre possibilità proprio perché nell'informatica bisogna sempre avere fame di novità.

Ho lavorato (con estremo successo, ne racconterò prima o poi l'esperienza) già dal 2005 con OpenVZ, che mi ha permesso (per anni) di far girare il mio server principale sia sul VIA EPIA che su un server esterno a cui migravo il tutto in base alle necessità. I container, insomma, mi sono sempre piaciuti.

Nel 2010, ho iniziato a implementare soluzioni basate su FreeBSD proprio per avere le sue jail, ovvero degli ambienti non emulati ma separati dal sistema operativo principale. In pratica, stesso kernel ma userland completamente diversa. Nessun overhead di virtualizzazione ma semplice separazione degli ambienti. Non era un concetto nuovo, infatti Solaris utilizza i container (o zone) già dal 2004, ma di sicuro un concetto vincente: se il mio scopo non è avere sistemi operativi diversi ma solo tenere separati i servizi, perché dover lanciare n macchine virtuali con n sistemi operativi uguali in esecuzione?

Poco dopo è arrivato anche GNU/Linux, e già nel 2011 sperimentavo con lxc, pur sapendo che non c'erano ancora i requisiti di sicurezza necessari, ma avevo già degli strumenti per tenere separati vari ambienti basati su GNU/Linux.

Proprio su lxc si basa Docker, una soluzione di inscatolamento di ambienti, che ne consente la creazione e l'utilizzo su qualsiasi piattaforma compatibile e crea un ambiente standard in un solo comando.

I miei primi passi con Docker

...sono stati disastrosi, come credo quelli di tutti quelli che hanno iniziato ai suoi albori. Docker è un progetto relativamente recente e, come tale, in forte sviluppo. Uno dei problemi, infatti, è che lo sviluppo è rapido e, a volte, distruttivo. Basta un aggiornamento e cambia qualcosa nella riga di comando, nel setup della rete, nella funzionalità e ci si può trovare con un sistema malfunzionante. Il primo passo che feci non fu diverso. Installai Docker, lo misi in funzione per alcuni test, aggiornai alla nuova versione stabile e tutti i miei contenitori smisero di funzionare per variazioni di struttura. Decisi di buttare via tutto e aspettare tempi migliori.

D'altronde si sa come funziona: o una tecnologia diventa sufficientemente matura in poco tempo, oppure muore. Nel primo caso, l'attesa non è così lunga. Nel secondo, non conviene perdere tempo con qualcosa che non avrà futuro.

Alcuni mesi fa ho deciso di rimettere in piedi il discorso. Di solito imparo qualcosa per necessità, poi lo espando e lo riutilizzo. A volte la necessità è puro vezzo privato, magari per fare qualcosa di non strettamente lavorativo ma si sa, l'animo nerd non lo si tiene a freno e, anzi, guai se ciò avvenisse!

Docker su strada

Rimettere in strada Docker non è stato difficile. A oggi, infatti, le cose sono state rese più facili (sia per architetture tradizionali che per le ARM come Raspberry PI o similari) da un rapido & semplice comando:

curl -sSL get.docker.com | sh

ovviamente a patto di avere curl installato, cosa non del tutto scontata in tutte le installazioni (Debian base non ce l'ha).

In un lampo, sono stato pronto col mio eseguibile pronto da usare e libero di fare dei test.

Ho iniziato. Immediatamente mi sono trovato a mio agio sia con la sintassi (anche se, a mio avviso, va ancora un po' uniformata tra un container normale e uno Swarm sia col funzionamento generale. Il vantaggio dell'inscatolamento delle risorse è indubbiamente evidente. Ogni cosa resta nel suo mondo, con le sue dipendenze, senza andare a intaccare o modificare alcunché sul resto del sistema.

Ho subito iniziato ad aver bisogno di alcune funzionalità non ancora presenti nei container presenti nell'hub ufficiale (specialmente per quanto riguarda le architetture ARM in mio possesso) per cui ho esplorato la creazione di una immagine personalizzata. Anche qui semplicità assoluta, un Dockerfile con tutte le istruzioni necessarie e una bella procedura. In un lampo ho avuto tutto il necessario.

Gli Swarm

Uno Swarm è un gruppo di sistemi su cui Docker è installato che si uniscono in un cluster. In uno swarm, ogni worker può far partire uno dei container e metterlo a disposizione. In uno swarm, un container può essere definito come servizio singolo (farne girare sempre uno su uno dei nodi), oppure come servizio multiplo (far girare n copie, che verranno distribuite nei nodi dello swarm) e milioni di sfumature di configurazione.

In uno Swarm, per scelta progettuale, una porta esposta da un container sarà raggiungibile connettendosi all'IP di uno qualunque dei nodi. Se, ad esempio, abbiamo due nodi (nodo1 e nodo2) e un container che espone la porta 80 (un server http), una volta configurato il servizio come parte dello Swarm sarà possibile connettersi al container stesso sia sull'IP del nodo1 che su quello del nodo2.

Conclusioni

Questo articolo voleva essere solo una rapida carrellata su quella che è stata la mia recente esperienza con Docker e sul perché ho deciso non solo di utilizzarlo ma di approfondirne sempre di più le potenzialità.

Seguiranno altri articoli in merito, quando il tempo me lo consentirà, che spiegheranno come ho risolto alcune delle problematiche principali che possono occorrere nell'utilizzo quotidiano e in produzione di un sistema del genere (es: storage condiviso tra nodi, ecc.)

Suggerisco a tutti di cominciare a prendere in considerazione questo tipo di tecnologia, sia per ragioni di sicurezza che di scalabilità e praticità. Volenti o nolenti, sarà il futuro. O il presente.