Mettre à jour Agora en un clic (et le canal bêta)

En bref. Une mise à jour se lance depuis Administration → Agora, en quelques clics. Agora fait une sauvegarde complète de sa base avant de toucher à quoi que ce soit, et revient automatiquement à la version précédente si la nouvelle ne démarre pas. Cela marche pareil avec Docker, avec un panel et sur un serveur Node.js.

Avant de commencer #

• Sois administrateur de ton Hub et connecte-toi : la mise à jour se fait depuis l'administration.
• Ta licence ne doit être ni expirée ni verrouillée : sinon le bouton est absent, voir Comprendre l'état de ta licence.
• Le serveur a besoin d'un peu de place sur le disque : la sauvegarde d'avant mise à jour s'y écrit. Une base, une sauvegarde, une migration : les mots sont dans le glossaire.

Étapes #

1. Ouvre Administration → Agora. Une pastille « version disponible » sur l'onglet te prévient (vérification automatique toutes les 6 heures). Clique sur Vérifier maintenant si besoin.

   <!-- CAPTURE C-076 -->

2. Lis les Nouveautés. Deux mentions peuvent apparaître : Mise à jour importante (sécurité) et Comprend des migrations de base de données.

3. Clique sur « Mettre à jour vers X.Y.Z ».

4. Suis les étapes à l'écran : sauvegarde, téléchargement, vérification, migrations, redémarrage. Le site redémarre pendant la mise à jour.

   <!-- CAPTURE C-077 -->

5. Recharge la page à la fin. Une page ouverte avant la mise à jour peut afficher « Agora vient d'être mis à jour » : recharge-la.

   <!-- CAPTURE C-079 -->

6. Redéploie la ressource FiveM si sa version a changé. Serveur → Joueurs affiche la version attendue. Voir Mettre à jour la ressource.

Tu sais que c'est réussi quand… #

Administration → Agora affiche la nouvelle version, sans « Dernière erreur », et /api/health répond "ok": true.

Si ça ne marche pas #

Quand le bouton n'est pas là #

Si la mise à jour échoue #

L'écran affiche « Échec : » suivi d'une cause en clair (sauvegarde impossible, disque plein, téléchargement refusé, migrations refusées…), avec ce qu'il faut corriger. Tant que la sauvegarde n'est pas faite, rien n'est modifié. Si un message se termine par un code, réessaie une fois : s'il revient, transmets ce code au support. Voir Mise à jour échouée.

<!-- CAPTURE C-081 -->

Coupure pendant la préparation. Si l'application s'arrête avant la bascule (mémoire saturée, redémarrage du serveur pendant le téléchargement), l'écran dit tout de suite « l'application s'est arrêtée en pleine mise à jour » au lieu de rester sur « Téléchargement… » ; rien n'a été modifié, relance simplement la mise à jour. Une demande de bascule déjà complète au moment de la coupure est, elle, jouée. Ce constat vient du superviseur : sur une installation qui n'a pas encore l'image à jour, l'écran finit par dire « la mise à jour précédente s'est interrompue » au bout de 30 minutes. Avant de télécharger, Agora vérifie aussi qu'il reste assez de place libre (environ cinq fois la taille de la version) et le dit plutôt que d'échouer à l'extraction.

La vérification automatique a échoué ? Si la dernière vérification (toutes les 6 heures) n'a pas pu aboutir (serveur de mises à jour muet, signature refusée, licence non éligible), la page le dit sous la date de vérification, même si ce n'est pas ton clic qui a échoué.

Le site reste muet après la mise à jour ? Attends quelques minutes : si la nouvelle version ne répond pas en 3 minutes, Agora remet tout seul la précédente. Sur un panel, la console du serveur dit pourquoi. Si le message parle de la base de données intégrée, voir Dépanner la base intégrée du Hub.

Pour aller plus loin #

Ce qui se passe, dans l'ordre #

Agora garde les 3 sauvegardes automatiques les plus récentes. Une sauvegarde que tu as nommée toi-même n'est jamais effacée automatiquement.

Avec la base intégrée d'un panel ou d'un serveur Node.js, la sauvegarde d'avant mise à jour est faite de la même façon et reste dans le dossier de sauvegardes d'Agora. <!-- À CONFIRMER : œuf tout-en-un (claude/pg-integre), BASE-INTEGREE §6 point 5 : mise à jour 1 clic (bascule et repli) avec la base intégrée, non éprouvée sur le banc -->

« Elle répond » veut dire : saine, base de données comprise. Pour confirmer la nouvelle version, Agora ne se contente pas que le site réponde : la page de santé (/api/health) doit aussi annoncer que la base est joignable ("ok": true). Une version qui démarre mais dont la base ne répond pas n'est pas confirmée saine. Une base lente à démarrer a toute la fenêtre des 3 minutes pour répondre ; seule une base encore injoignable au bout de ce délai déclenche le retour. Le retour ne répare pas la base : vérifie qu'elle tourne (conteneur, réseau, identifiants), puis relance la mise à jour.

Où lire la cause d'un retour. La source fiable est la console du panel : la ligne pas de santé en 180 s … sa base de données restait injoignable nomme la base. L'écran de mise à jour est servi par la version de repli : il ne peut dire « sa base ne répondait pas » que si cette version contient déjà ce changement. Sinon tu verras « la nouvelle version n'a pas démarré » même quand la base est en cause : lis alors la console.

Si le serveur lui-même redémarre entre la bascule et la confirmation (coupure, mémoire saturée, docker restart), la base peut revenir plus tard que l'application : dans ce cas seulement, la version est confirmée sur le simple fait qu'elle répond.

Pas de retour en arrière. Agora retient la version la plus haute qu'il a déjà fait tourner et refuse d'installer plus ancien, même si le serveur de mises à jour le propose (une vieille version signée garderait ses failles, et les migrations de la base ne se défont pas). Pour la même raison, les appels vers le serveur de licences et le téléchargement des mises à jour ne suivent aucune redirection.

Après une restauration d'une sauvegarde plus ancienne, le même passage de mise à jour (étape Remise à niveau après restauration…) remet la base au niveau de la version qui tourne. Cette remise à niveau ne garde pas la version précédente sur le disque : voir Sauvegardes et restauration.

Le repli remet l'ancienne application, il ne défait pas les migrations de la base. Pour revenir en arrière côté base, restaure le fichier pre-update-… : voir Mise à jour échouée.

Le canal bêta #

• Stable (recommandé) : les versions publiées.
• Bêta : les versions de test, réservées au palier Pro. Ailleurs, l'option est grisée et l'instance suit le canal stable.

Pour changer : Administration → Agora, liste Canal. Le choix s'applique dès que tu le sélectionnes et lance tout de suite une vérification. Pour la bêta, Agora te demande de confirmer : ce sont des versions de test, et une fois installées on ne revient pas en arrière (les migrations de la base ne se défont pas).

<!-- CAPTURE C-078 -->

Il n'y a jamais de rétrogradation : si le canal choisi n'a qu'une version plus ancienne que la tienne, la page l'indique (« plus ancienne que ta version : rien à installer ») et tu recevras la prochaine version du canal dès qu'elle dépassera la tienne.

Si tu tournes sur un correctif du support (une version 1.8.0-fix.<réf>.<n>), un correctif compte comme plus récent que toutes les bêtas de sa version : la page ne dit donc jamais « plus ancienne que ta version ». Elle compare sur la base du correctif (1.8.0) : toute version normale du canal dont la base est au moins celle-là reste proposée, bêtas suivantes comprises. Revenir à la version normale devient alors le bouton principal. Une version sous la base du correctif s'affiche « plus basse que la base de ton correctif : rien à installer ». Une bêta de cette base ou plus récente est proposée sous un correctif comme une version normale, selon ton canal.

Sous une version normale, Revenir à la version normale ne te fait jamais descendre sous la version qui tourne : la version en cours sert de plancher.

Mettre à jour au démarrage #

Utile si l'administration est inaccessible :

• Docker (install.sh) : cd /opt/agora && AGORA_UPDATE=1 docker compose up -d
• Panel : variable Mettre a jour au demarrage à 1, redémarre, puis remets 0.

<!-- CAPTURE C-080 -->

Les mêmes règles s'appliquent : sauvegarde avant les migrations, retour à la version d'avant en cas d'échec. Voir Les variables d'environnement.