Aggiornamenti

Sapere quando esce una nuova versione

Il controllo degli aggiornamenti è disattivato per impostazione predefinita, come ogni connessione a Internet. Lo attivi in Impostazioni › Piattaforma › Generale › Connessioni › Cerca aggiornamenti. Legge soltanto i tag delle versioni pubblicate: non viene inviata alcuna informazione sull’istanza.

Una volta attivato:

• il piè di pagina della barra laterale mostra Aggiornamento disponibile: … quando esce una versione più recente;
• Impostazioni › Piattaforma › Aggiornamento elenca le versioni più recenti con Le novità;
• il controllo viene eseguito automaticamente ogni sei ore; Cerca aggiornamenti nella pagina Aggiornamento lo esegue subito e La avvisa del risultato.

La scheda Versione mostra la Versione attuale, il Canale, l’Ultima versione e lo stato del Programma di aggiornamento. La scheda Note di rilascio elenca tutte le versioni pubblicate, dalla più recente, con le novità di ciascuna e le eventuali operazioni da eseguire a mano.

Aggiornare dalle impostazioni

Richiede il servizio updater dello stack di produzione (la pagina mostra Programma di aggiornamento: In esecuzione) e il controllo degli aggiornamenti attivato.

1. Apra Impostazioni › Piattaforma › Aggiornamento. Sotto Aggiornamenti disponibili, legga le novità della versione.

2. Clicchi su Aggiorna alla … e confermi con Aggiorna.

3. La pagina segue le fasi: Backup (il database viene salvato nella cartella backups dell’installazione), Download, Riavvio, Verifica. Auditix non è disponibile per uno o due minuti mentre i suoi servizi si riavviano, poi la pagina si ricarica da sola.

Se la nuova versione non si avvia, la precedente torna da sola. Una versione può anche richiedere una modifica a compose.yaml: le sue note di rilascio lo indicano, e la modifica si applica a mano (vedere Note di aggiornamento).

Il modo in cui il programma di aggiornamento riavvia i servizi dipende da AUDITIX_VERSION in .env:

• latest (qualsiasi installazione, Portainer compreso): la versione scelta diventa latest sull’host e il programma di aggiornamento ricrea i container Auditix su di essa. Lo stack continua a indicare latest: non c’è nulla da modificare in Portainer.
• Una versione fissa (vX.Y.Z), con la cartella di installazione montata su /install: il programma di aggiornamento imposta la nuova versione in .env, poi scarica e riavvia i servizi.

Build di sviluppo

Quando la licenza include le Versioni di sviluppo, il Canale della pagina Aggiornamento offre Produzione (le versioni pubblicate, per impostazione predefinita) e Sviluppo (l’ultima build di sviluppo, in anticipo sulle versioni pubblicate). Le build di sviluppo possono contenere lavoro non finito, e le loro modifiche al database possono precedere la prossima versione: il ritorno a Produzione attende una versione più recente della build installata. Le riservi alle istanze di test.

Aggiornare a mano

Senza il servizio di aggiornamento, o se preferisce:

Versione fissa

Imposti la nuova versione in .env, poi scarichi e riavvii:

.env

AUDITIX_VERSION=v0.13.0

docker compose pull
docker compose up -d
docker image prune -f

latest

Mantenga AUDITIX_VERSION=latest e scarichi di nuovo:

docker compose pull
docker compose up -d
docker image prune -f

Il backend applica da solo le modifiche al database all’avvio, a partire da qualsiasi versione precedente. Esegua prima un backup del database (vedere Backup).

Per tornare indietro, imposti la versione precedente ed esegua gli stessi comandi. Le modifiche al database vanno solo in avanti: se torna indietro oltre una modifica al database, ripristini il backup eseguito prima dell’aggiornamento.

Nota

I tag delle versioni iniziano con v (v0.13.0). I tag senza v delle versioni fino alla 0.4.0 non esistono più.

Note di aggiornamento

Modifiche da applicare a mano a compose.yaml, a seconda della versione da cui è partita l’installazione:

• Installata prima della 0.11.1: aggiunga cookie_name auditix_live alle MERCURE_EXTRA_DIRECTIVES del servizio mercure. Senza questa riga, i browser ricevono gli aggiornamenti in tempo reale tramite un relay più lento e registrano una richiesta /.well-known/mercure rifiutata.

  mercure:
    environment:
      MERCURE_EXTRA_DIRECTIVES: |
        resource_identifier http://mercure/.well-known/mercure
        cookie_name auditix_live
        transport bolt {
          path /data/mercure.db
          size 1000
          cleanup_frequency 0.3
        }
        heartbeat 15s

• 0.6 o precedente: rimuova il servizio worker, aggiunga il servizio orchestrator e rimuova il container lasciato dal servizio worker (docker rm -f <project>-worker-1; con Portainer: Containers).

• 0.2 o precedente: aggiunga il blocco x-logging e il logging di ogni servizio; i servizi gateway, rabbitmq, mercure, developer e logs e i loro volumi; MESSENGER_TRANSPORT_DSN, GATEWAY_SECRET, RABBITMQ_PASSWORD e MERCURE_JWT_SECRET (openssl rand -hex 32), come nel file compose attuale. Ora è il gateway a pubblicare le porte: rimuova quelle del frontend e, se presente, punti il Suo reverse proxy alla porta HTTP del gateway.