SHA256

Watch

Alcune sperimentazioni con OpenTofu e Incus

HCL 100%

Find a file

Repository files (latest commit first)
Filename	Latest commit message	Latest commit date
Andrea Pappacoda 5785f880d5 Alcune modifiche per allineare a container_prova_open_tofu		2026-08-16 15:18:09 +02:00
.gitignore	La devo smettere	2026-08-15 01:13:08 +02:00
main.tf	Alcune modifiche per allineare a container_prova_open_tofu	2026-08-16 15:18:09 +02:00
README.md	Aggiunti dei linkz	2026-08-15 01:24:55 +02:00

README.md

Vegan Incus

Alcune sperimentazioni con OpenTofu e Incus.

Pensieri

Ieri sera io e il freek abbiamo creato una prima configurazione OpenTofu per fare la inizializzazione di un container LXC sul Milan. E ha funzionato, super figo.

Per fare ciò abbiamo usato un provider Proxmox per OpenTofu, perché è virtual machine manager che usiamo al momento.

Tengo a sottolineare che usare il provider Proxmox non è l'obiettivo, ma una necessità. Il nostro vero obiettivo è quello di creare macchine virtuali (leggere e non)ᵃ attraverso OpenTofu.

Collegandomi anche a quanto detto dal carne, ovvero che decidere di gestire l'infrastruttura come codice significa abbandonare la gestione attraveso pannello di controllo grafico, mi chiedo: quali sono le parti di Proxmox che vogliamo tenere? Esiste una tecnologia che più si presta per quelli che sono i nostri obiettivi?

Proxmox

Premetto che io di Proxmox so veramente poco. Sicuramente so che mi ha pagato il volo per la DebConf 26, in quanto sponsor platino della conferenza. Ma a parte averci interagito marginalmente per creare macchine virtuali dalla sua interfaccia grafica web, non ho gran esperienza. Questa sezione quindi discute quelle che sono le mie sensazioni riguardo Proxmox, e che potrebbero cambiare nel momento in cui mi esporrò più a lungo alle sue caratteristiche.

In termini brevi: non mi piace. Mi dà l'impressione di essere un carrozzone enorme con tantissime parti che si muovono in direzioni e interagiscono in modi che non comprendo minimamenteᵇ.

È anche vero che però alcune sensazioni sono state condizionate da alcuni fatti che ho osservato. Il più recente ha a che fare col messaggio un po' ironico un po' preoccupato che ho mandato sul gruppo ieri pomeriggio:

Sarebbe da indagare, ma nei 90 giorni(!) in cui il server di HackInPovo è stato up, i cinque processi (escludendo quelli del kernel) che hanno mangiato di più la CPU sono...
root@milan:~# LIBPROC_HIDE_KERNEL=1 ps -A -o time,pid,args | cut -c -70 | sort -r | head -n 5
9-05:01:40  2207 /usr/bin/kvm -id 101 -name firewall,debug-threads=on
2-19:40:13  2123 pvestatd
06:37:02       1 /usr/lib/systemd/systemd --system --deserialize=88
05:34:15 3072832 /usr/bin/kvm -id 102 -name mail,debug-threads=on -no-
05:32:14    2121 pve-firewall
...

Al primo posto: il firewall, con ben 9 giorni di utilizzo della CPU non-stop. I miei personali complimenti a FreeBSD per questa cifra non indifferente.

Segue con 2 giorni il demone delle statistiche di Proxmox, che ha lavorato molto duro per informarci di quanto la nostra RAM sia perennemente satura.

Chiude il podio systemd con sole 6 ore. Un utilizzo di risorse minimo se messo a confronto coi secondi di tempo risparmiati per ogni avvio del sistema.

Manca il bronzo per poco il server mail. Giusto il tempo di iniziare a ricevere messaggi di inviti a interviste da parte dei giornali trentini e ne riparliamo.

E così come l'ha aperta, chiude la classifica il secondo firewall del milan. La sicurezza prima di tutto.

Forti applausi per tutti i partecipanti 👏

Di questa classifica, due processi su cinque sono parte della suite di Proxmox, ed è una cosa gravissima per tanti motivi. Prima di tutto perché sono in cima a una classifica di processi con comportamenti estremamente patologici, dove i consumi di systemd sono causa di un problema di configurazione di CheckMK che chiede al service manager di essere riavviato ogni pochi secondi (causando una creazione di cgroup e namespace ogni volta), e quelli del server mail sono una coppia del fatto che dovecot e postfix (in mailcow) sono soggetti a tantissimi brute force da parte degli spambot e che mailcow è un carrozzone gigantesco di suo, come descritto in https://git.hackinpovo.it/HackInPovo/melissa#il-problema.

Ora, in questo contesto patologico il firewall di Proxmox (che abbiamo disattivato!) e il demone delle statistiche (che è ridondante in quanto abbiamo CheckMK) riescono comunque a dominare i consumi.

Ci sono anche altre piccolezze. Ad esempio, le immagini di Debian che Proxmox usa per creare i container LXC contengono una configurazione non standard e del software che non si capisce bene perché sia messo lì (vedi Postfix), e che mi ha causato problemi in passato (quando stavo cercando di configurare melissa).

Di positivo, però, ci sono alcune cose che usiamo attivamente e che ci hanno già salvato il culo:

Il sistema dei backup tra Open e Reggia
I backup incrementali via object storage S3
Altro?

Quindi qualunque nuovo "backend" per la nostra infrastruttura deve avere tutte le funzionalità di Proxmox che ci servono ad oggi, e meno problemi.

Incus

Incus è un gestore di macchine virtuali, system container e application container. È nato come fork guidato dalla community di LXD, un progetto di Canonical, ed è ora guidato dall'organizzazione Linux Containers (gli stessi che fanno LXC). È in grado di eseguire qualsiasi immagine OCI (anche quelle pensate per Docker!), e fornisce integrazioni ufficiali con OpenTofu e Ansible.

Non fornisce una GUI di default; ne esiste una sviluppata da Canonical, ma nell'ottica di gestire l'infrastruttura con OpenTofu questo è solo un vantaggio.

Supporta storage pool zfs, btrfs, ceph e altri, ha backup e snapshot built-in e rende possibile integrare le metriche in Prometheus, da visualizzarsi poi in Graphana.

Da indagare:

È davvero più leggero?
Supporta il backup S3 figo come Proxmox?

Note

a. Con "macchina virtuale" intendo anche i container, perché la differenza tra la concezione popolare di container e quella di macchina virtuale è in realtà molto sfumata -- una immagine OCI eseguita in un runtime che fa uso di un kernel hypervisor attraverso Docker è un container o VM? Host e guest non condividono il kernel, cosa tipica di una macchina virtuale, ma il software che stiamo eseguendo è ciò che tradizionalmente viene chiamato container. Mi sento quindi di estenere e generalizzare il termine "macchina virtuale" anche per includere i container LXC

b. È anche possibile che questa mia percezione sia condizionata dal fatto che Proxmox sia stato setuppato prima del mio arrivo in hacklab, e tutt'oggi ignoro cosa sia stato fatto per tirarlo su.

P.S. sono SICURO che ho scritto un sacco di cazzate perché sono tanto ignorante in tema Proxmox. Ma è una ignoranza che mi ha spinto a sperimentare, e magari a stimolare qualcosa di costruttivo in assemblea :)