Aller au contenu principal

Mise à jour et retour arrière

Une mise à jour tient en une commande. Elle ne démarre jamais sans une sauvegarde récente, garde de quoi revenir en arrière et laisse un rapport consultable dans l'application.

Vue d'ensemble​

./liberty upgrade — ce que fait une seule commande1 · Contrôledoctor (indicatif)2 · Garder l'imagerollback-<stamp>3 · Sauvegardearrêt si elle échoue4 · Pull + recréationmêmes overlays qu'à l'installation5 · Migrationspaquet d'applis + schémas6 · Rapportpuis statusUn problème ?./liberty rollback : image précédente + cette sauvegardeDéployer → Historique → Upgradesversions avant / après, chaque étape, migrations

Docker​

cd liberty-next/release
git pull                                  # les scripts de la nouvelle version
./liberty upgrade                         # vers la dernière version
./liberty upgrade --tag 7.0.58            # ou vers une version donnée (conservée dans .env)

Ce que fait la commande, dans l'ordre :

ÉtapeDétail
1. ContrôleLance doctor. Les problèmes sont signalés mais n'arrêtent pas la mise à jour — c'est souvent elle qui les corrige.
2. Garder l'imageL'image en service est étiquetée localement rollback-<date> pour pouvoir être relancée.
3. Sauvegardebackup de chaque volume et du dossier des applications, conservée --keep jours (30 par défaut). Si la sauvegarde échoue, la mise à jour s'arrête et rien n'est modifié.
4. Téléchargement et recréationLa nouvelle image est téléchargée et les conteneurs recréés avec les fichiers compose enregistrés — le HTTPS et les applications sous licence restent en place.
5. Applications et migrationsAvec --apps <wheel>, le nouveau paquet d'applications est installé (avec son plan de fusion) ; puis les migrations de schéma en attente sont appliquées.
6. RapportLe rapport est enregistré et status est affiché.

L'interruption de service dure le temps de redémarrer le conteneur, en général bien moins d'une minute.

Mettre à jour les applications sous licence​

./liberty upgrade --apps ./liberty_apps-7.0.58-py3-none-any.whl

Framework et applications sont mis à jour en une seule exécution. Pour actualiser seulement les applications, sans nouvelle image du framework : ./liberty apps <wheel>.

Installation Python​

liberty-ops upgrade                                       # framework vers la dernière version
liberty-ops upgrade --version 7.0.58                      # une version donnée
liberty-ops upgrade --apps ./liberty_apps-7.0.58-py3-none-any.whl

Même enchaînement : doctor → sauvegarde (la seule étape qui peut arrêter la mise à jour) → pipx upgrade (ou la version fixée) → le wheel des applications → liberty-admin migrate → redémarrage du service et attente de /ready → rapport → status. --no-restart laisse le redémarrage à faire à la main ; --backup-dest choisit l'emplacement de la sauvegarde.

La lancer sous l'utilisateur du service avec son environnement chargé, comme toute commande liberty-ops.

Le rapport de mise à jour​

Chaque upgrade et chaque rollback enregistre un rapport : versions avant et après, version de l'image, fichiers compose, dossier de sauvegarde, constats de doctor, résultat de chaque étape et migrations appliquées. Il est stocké avec la configuration (.versions/upgrades/) et, avec Docker, une copie est aussi écrite dans le dossier de sauvegarde.

Il se consulte dans Liberty Next → Déployer → Historique → Upgrades. Chaque entrée indique son composant :

EntréeEnregistrée par
Stack./liberty upgrade, ./liberty rollback, liberty-ops upgrade — le rapport décrit ci-dessus.
Framework, AppsUn changement de version constaté au démarrage du serveur — affiché avec les notes de version de la nouvelle version.
<application> schemaliberty-admin migrate — les migrations appliquées à la base d'une application.
framework-schemaLes colonnes ajoutées par le serveur à ses propres tables quand une nouvelle version en a besoin.

Migrations de schéma​

Le framework crée et complète ses propres tables au démarrage. Les bases des applications sous licence évoluent par des migrations livrées dans le wheel des applications :

  • ./liberty upgrade et liberty-ops upgrade les appliquent ;
  • ./liberty status, ./liberty doctor et le journal du serveur au démarrage signalent celles en attente ;
  • ./liberty migrate --dry-run les liste, ./liberty migrate les applique ;
  • avec LIBERTY_AUTO_MIGRATE=1 dans .env, le serveur les applique lui-même au démarrage.

Chaque exécution est enregistrée dans Liberty Next → Déployer → Historique → Upgrades. Pour une base dont la version enregistrée est en avance sur ses tables réelles, liberty-admin migrate --app nomasx1 --stamp <révision> enregistre la version sans rien exécuter, puis applique ce qui reste — voir CLI.

Retour arrière​

./liberty rollback            # demande confirmation
./liberty rollback --yes

La commande relance l'image gardée avant la dernière mise à jour et restaure la sauvegarde prise juste avant. Tout ce qui a été écrit depuis cette sauvegarde est perdu — d'où la confirmation. Le rapport de la mise à jour est conservé, et le retour arrière a le sien.

Sur une installation Python, liberty-ops rollback réinstalle la version précédente du framework et restaure la sauvegarde prise avant la mise à jour. pipx ne garde pas de copie de l'ancien wheel des applications : le passer avec --apps <wheel précédent> pour revenir aussi sur les applications.

Pour revenir plus loin que la dernière mise à jour : ./liberty restore <dossier de sauvegarde> puis ./liberty upgrade --tag <version>.

Docker Swarm​

./liberty ne pilote pas un swarm. Prendre une sauvegarde avec ./backup.sh, puis :

docker service update --image ghcr.io/fblettner/liberty-next:7.0.58 liberty_liberty-next
docker exec -u liberty $(docker ps -qf name=liberty_liberty-next) liberty-admin migrate
docker service rollback liberty_liberty-next      # en cas de problème

Ou définir LIBERTY_IMAGE_TAG dans .env et relancer ./deploy-swarm.sh.

Versions​

ChangementÀ quoi s'attendre
Version corrective (7.0.57 → 7.0.58)Corrections et fonctionnalités ; la configuration reste compatible ; les changements de base ne font qu'ajouter des tables ou des colonnes.
Une étape plus importanteLes notes de version précisent ce qu'il faut vérifier avant et après.

Lire les notes de version avant de mettre à jour : Liberty Next → Documenter → Notes de version affiche celles de la version en service.

Conseils​

  • Fixer la version en production (--tag) et mettre à jour volontairement, d'abord sur un serveur de test.
  • Lancer ./liberty doctor avant la mise à jour : un problème signalé est plus simple à corriger avant qu'après.
  • Après la mise à jour, se connecter, ouvrir un écran de chaque application et lancer une tâche Nomaflow à la main.
  • Garder la sauvegarde de la mise à jour jusqu'à la suivante.