Proxmox VE: rolling update del cluster con Ansible

Aggiornare un singolo host Proxmox VE è semplice; aggiornare un cluster senza trasformare una normale manutenzione in un fermo generalizzato richiede metodo. Il punto non è eseguire apt upgrade più velocemente, ma serializzare le operazioni, verificare la salute del cluster e fermarsi appena una condizione non è sicura.

Ansible rende la procedura ripetibile e verificabile. Non sostituisce però la conoscenza di Proxmox: quorum, replica, storage condiviso, alta affidabilità e carichi locali vanno compresi prima di automatizzare. La strategia seguente è adatta a piccoli cluster e homelab, ma applica precauzioni sensate anche alle infrastrutture aziendali.

Preparare una via di ritorno

Un aggiornamento non è un backup. Prima della finestra di manutenzione servono backup recenti e almeno un ripristino di prova. Con Proxmox Backup Server, controllare gli ultimi job, la disponibilità del datastore e i task di verifica.

Registrare versione, repository e kernel in uso:

pveversion -v
apt-cache policy pve-manager
uname -r

Gli host dello stesso cluster devono usare repository coerenti. Mescolare repository enterprise e no-subscription, oppure release Debian diverse, rende il risultato imprevedibile. Le credenziali non vanno inserite nel playbook: meglio gestirle sul nodo o tramite Ansible Vault.

Inventario e serializzazione

L’inventario deve contenere soltanto i nodi del cluster interessato:

[proxmox]
pve01 ansible_host=10.10.10.11
pve02 ansible_host=10.10.10.12
pve03 ansible_host=10.10.10.13

[proxmox:vars]
ansible_user=root
ansible_python_interpreter=/usr/bin/python3

Nel playbook, serial: 1 è la protezione fondamentale: Ansible completa un host prima di passare al successivo. any_errors_fatal: true blocca gli altri nodi dopo un errore. Una manutenzione lenta è preferibile a tre server aggiornati a metà.

Controlli pre-flight

Prima di cambiare pacchetti bisogna verificare quorum e stato generale. Un controllo minimo interroga pvecm status; con HA è utile aggiungere ha-manager status.

- name: Rolling update Proxmox VE
  hosts: proxmox
  serial: 1
  any_errors_fatal: true
  gather_facts: true

  pre_tasks:
    - name: Legge lo stato del cluster
      ansible.builtin.command: pvecm status
      register: cluster_status
      changed_when: false

    - name: Richiede il quorum
      ansible.builtin.assert:
        that:
          - ""Quorate:          Yes" in cluster_status.stdout"
        fail_msg: "Cluster non quorato: manutenzione interrotta"

    - name: Verifica spazio libero in root
      ansible.builtin.assert:
        that:
          - ansible_mounts | selectattr("mount", "equalto", "/")
            | map(attribute="size_available") | first > 2147483648
        fail_msg: "Meno di 2 GiB liberi su root"

L’output di pvecm status può cambiare tra versioni: provare l’asserzione sul proprio cluster e adattarla. In produzione controllare anche Ceph, repliche ZFS, task in corso e allarmi. Con storage esclusivamente locale, la migrazione online potrebbe richiedere replica o copia dei dischi.

Drenare il nodo

Prima dell’update, elencare guest e container:

qm list
pct list

La migrazione può restare un passaggio manuale approvato dall’operatore, oppure diventare un ruolo separato con una mappa nodo-destinazione. Evitare algoritmi che spostano tutto sul primo host disponibile. Vanno valutati RAM, CPU, vincoli HA, passthrough PCI, bridge di rete e accessibilità dello storage.

Per una piccola infrastruttura, un buon compromesso è mettere il nodo in manutenzione, migrare i carichi dalla GUI o con qm migrate e pct migrate, quindi limitare il playbook a quel nodo. Solo dopo i test si procede con il successivo.

Aggiornamento controllato

Il modulo ansible.builtin.apt gestisce cache e pacchetti senza analizzare l’output di apt-get:

  tasks:
    - name: Aggiorna tutti i pacchetti
      ansible.builtin.apt:
        update_cache: true
        cache_valid_time: 3600
        upgrade: dist
      register: apt_result

    - name: Mostra il risultato
      ansible.builtin.debug:
        var: apt_result.stdout_lines

Dopo l’aggiornamento di kernel o componenti PVE, pianificare un riavvio presidiato del singolo nodo. Non automatizzarlo di notte: un problema di boot, rete o storage richiede una console, preferibilmente IPMI, iDRAC o iLO. Attendere che il nodo sia completamente rientrato nel cluster prima di intervenire sul successivo.

Verifica finale

Un nodo raggiungibile via SSH non è necessariamente sano. Aggiungere controlli sui servizi e ripetere la verifica del quorum:

  post_tasks:
    - name: Verifica i servizi PVE
      ansible.builtin.command: >-
        systemctl is-active pveproxy pvedaemon pvestatd
      changed_when: false

    - name: Ricontrolla il cluster
      ansible.builtin.command: pvecm status
      register: cluster_after
      changed_when: false
      failed_when: ""Quorate:          Yes" not in cluster_after.stdout"

Dalla GUI verificare che storage, VM, container e metriche siano visibili. Controllare versione con pveversion -v, kernel con uname -r e log con journalctl -b -p warning. Attendere qualche minuto prima di ribilanciare i carichi: problemi di rete o replica non emergono sempre immediatamente.

Checklist operativa

backup completati e ripristino di prova disponibile;
console remota funzionante per ogni nodo;
repository e release coerenti;
cluster quorato e senza task critici;
capacità sufficiente sugli host di destinazione;
un nodo alla volta grazie a serial: 1;
arresto immediato al primo errore;
verifica di servizi, storage, kernel e log;
rientro delle VM dopo un periodo di osservazione.

L’automazione migliore non elimina i punti di controllo: li rende espliciti. Un rolling update affidabile è una sequenza di piccoli cambiamenti reversibili, non un unico comando distribuito su tutto il cluster.

Esecuzione prudente del playbook

Avviare prima la modalità di simulazione, sapendo che non tutti i comandi dichiarativi possono prevedere ogni effetto:

ansible-playbook -i inventory.ini rolling-update.yml --check --diff
ansible-playbook -i inventory.ini rolling-update.yml --limit pve01

Il limite esplicito riduce il rischio di selezionare accidentalmente l’intero gruppo durante la prima esecuzione. Conservare l’output del job insieme al ticket di manutenzione e annotare versioni iniziali e finali. Se l’aggiornamento di un nodo fallisce, non forzare il passaggio al seguente: raccogliere apt log, stato dei servizi e messaggi del kernel, poi decidere se correggere o ripristinare. Infine, eseguire un test applicativo reale su almeno una VM migrata: il solo stato verde dell’hypervisor non conferma che DNS, VLAN, mount e servizi dei guest funzionino correttamente.