Mises à jour

Savoir quand une version sort

La recherche de mises à jour est désactivée par défaut, comme toute connexion à Internet. Activez-la dans Paramètres › Plateforme › Général › Connexions › Vérifier les mises à jour. Elle lit uniquement les tags des versions publiées : rien sur l’instance n’est envoyé.

Une fois activée :

• le pied de la barre latérale affiche Mise à jour disponible : … lorsqu’une version plus récente est sortie ;
• Paramètres › Plateforme › Mise à jour liste les versions plus récentes avec Ce qu’elle apporte ;
• la vérification s’exécute d’elle-même toutes les six heures ; Rechercher des mises à jour, sur la page Mise à jour, la lance immédiatement et vous notifie du résultat.

L’onglet Version affiche la Version actuelle, le Canal, la Dernière version et l’état du Programme de mise à jour. L’onglet Notes de version liste toutes les versions publiées, de la plus récente à la plus ancienne, avec ce que chacune apporte et ce qu’il faut éventuellement faire à la main.

Mettre à jour depuis les paramètres

Cela nécessite le service updater de la stack de production (la page affiche Programme de mise à jour : En marche) et la recherche de mises à jour activée.

1. Ouvrez Paramètres › Plateforme › Mise à jour. Sous Mises à jour disponibles, lisez ce qu’apporte la version.

2. Cliquez sur Mettre à jour en … et confirmez avec Mettre à jour.

3. La page suit les étapes : Sauvegarde (la base de données est sauvegardée dans le dossier des sauvegardes de l’installation), Téléchargement, Redémarrage, Vérification. Auditix est indisponible une à deux minutes, le temps que ses services redémarrent, puis la page se recharge d’elle-même.

Si la nouvelle version ne démarre pas, la précédente revient d’elle-même. Une version peut aussi nécessiter une modification de compose.yaml : ses notes de version le précisent, et elle s’applique à la main (voir Notes de mise à niveau).

La façon dont l’updater redémarre les services dépend de AUDITIX_VERSION dans .env :

• latest (toute installation, Portainer compris) : la version choisie devient latest sur l’hôte et l’updater recrée les conteneurs Auditix sur cette base. La stack continue d’indiquer latest : rien à modifier dans Portainer.
• Une version fixe (vX.Y.Z), avec le dossier d’installation monté sur /install : l’updater inscrit la nouvelle version dans .env, puis télécharge les images et redémarre les services.

Versions de développement

Lorsque la licence inclut les Versions de développement, le Canal de la page Mise à jour propose Production (les versions publiées, par défaut) et Développement (la dernière version de développement, en avance sur les versions publiées). Les versions de développement peuvent contenir des travaux inachevés, et leurs modifications de la base de données peuvent précéder la prochaine version publiée : revenir en Production attend une version plus récente que celle en place. Réservez-les aux instances de test.

Mettre à jour à la main

Sans le service updater, ou si vous préférez :

Version fixe

Indiquez la nouvelle version dans .env, puis téléchargez les images et redémarrez :

.env

AUDITIX_VERSION=v0.13.0

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

latest

Conservez AUDITIX_VERSION=latest et téléchargez de nouveau les images :

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

Le backend applique lui-même les modifications de la base de données au démarrage, depuis n’importe quelle version antérieure. Sauvegardez d’abord la base de données (voir Sauvegarder).

Pour revenir en arrière, indiquez la version précédente et exécutez les mêmes commandes. Les modifications de la base de données ne vont que vers l’avant : pour revenir en arrière au-delà d’une modification de la base, restaurez la sauvegarde effectuée avant la mise à jour.

Note

Les tags de version commencent par v (v0.13.0). Les tags sans v des versions jusqu’à la 0.4.0 n’existent plus.

Notes de mise à niveau

Modifications à appliquer à la main dans compose.yaml, selon la version à partir de laquelle vous avez installé :

• Installée avant la 0.11.1 : ajoutez cookie_name auditix_live aux MERCURE_EXTRA_DIRECTIVES du service mercure. Sans cela, les navigateurs reçoivent les mises à jour en temps réel via un relais plus lent, et journalisent une requête /.well-known/mercure refusée.

  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 ou antérieure : supprimez le service worker, ajoutez le service orchestrator, et supprimez le conteneur laissé par le service worker (docker rm -f <project>-worker-1 ; avec Portainer : Containers).

• 0.2 ou antérieure : ajoutez le bloc x-logging et le logging de chaque service ; les services gateway, rabbitmq, mercure, developer et logs et leurs volumes ; MESSENGER_TRANSPORT_DSN, GATEWAY_SECRET, RABBITMQ_PASSWORD et MERCURE_JWT_SECRET (openssl rand -hex 32), comme dans le fichier compose actuel. La gateway publie désormais les ports : supprimez ceux du frontend, et faites pointer votre éventuel reverse proxy vers le port HTTP de la gateway.