Mettre à jour une instance

Une mise à jour ordinaire tient en deux commandes :

git pull
docker compose up -d --build

L’application applique d’elle-même ses nouvelles migrations avant de redémarrer.

L’installation ne se fait qu’une fois, comme l’explique Premier démarrage. Cette page décrit ce qui se répète.

La durée de la seconde commande

Le pull a modifié les sources, l’image est donc reconstruite à partir d’elles. Sur une petite machine domestique, cela prend quelques minutes, surtout pour compiler l’interface, et Docker affiche la construction au fur et à mesure.

Pendant tout ce temps, l’instance continue de répondre, depuis le conteneur qui fait encore tourner l’ancienne image. L’interruption n’a lieu qu’à la toute fin, au moment du remplacement : pendant quelques secondes, l’adresse ne répond plus, le temps que le nouveau conteneur démarre et applique les nouvelles migrations.

L’onglet qui a une visite de retard

Un navigateur où l’instance était déjà ouverte a une visite de retard, et il vous le signale désormais. Badlen installe un service worker : après une mise à jour, un chargement de page vient du cache de ce navigateur et affiche encore l’ancienne version, qui dialogue avec une API à jour. L’onglet ouvert demande à l’instance quelle version elle sert, environ toutes les demi-heures et chaque fois qu’il repasse au premier plan ; si la réponse diffère de la version de la page elle-même, une ligne apparaît en bas de l’écran et propose de recharger.

Cette ligne ne prend pas le focus, et elle passe sous les fenêtres de dialogue pour ne jamais recouvrir un formulaire en cours de saisie. Son bouton Plus tard la masque définitivement pour cette version, dans cet onglet comme dans les suivants. Le rechargement qu’elle propose vaut la peine : il met d’abord à jour le service worker, si bien que la page qui revient est bien la nouvelle version et non celle du cache, et vous ne perdez ni votre session ni vos chiffres. L’ignorer ne coûte rien d’autre que de rester sur l’ancienne interface jusqu’au prochain rechargement.

La version en service

Réglages → À propos l’indique, sur toute installation. La version vient du fichier VERSION enregistré dans le dépôt et copié dans l’image : elle s’affiche donc même pour une construction faite à partir d’une archive de sources téléchargée, sans historique git. C’est ce numéro qu’il faut citer dans un rapport de bug. Entre deux versions publiées, il porte le suffixe -dev, qui signale une construction faite depuis main plutôt que depuis une étiquette ; docker compose logs app cite toujours chaque migration appliquée au démarrage.

Ce suffixe fixe aussi la limite du mécanisme décrit plus haut. Le numéro ne change qu’à la publication d’une version : deux reconstructions depuis main entre deux publications portent le même numéro, et un onglet ouvert n’a rien à comparer. Il ne proposera pas de recharger, et le premier chargement de page sera encore servi depuis le cache du navigateur.

C’est aujourd’hui le cas de toutes les mises à jour. Le dépôt n’a encore aucune étiquette et aucune version n’a été publiée : construire depuis main est la seule façon de mettre à jour, et il faut alors recharger l’onglet vous-même. Le mécanisme fonctionnera à partir de la première version publiée, et c’est aussi à partir de là que vous pourrez choisir de suivre les étiquettes.

L’ancienne image

Chaque mise à jour laisse sur la machine l’image remplacée, sans étiquette, puisque seule l’étiquette est passée à la nouvelle, et elle garde toute sa taille : près de 800 Mo chacune. docker image prune supprime les images sans étiquette et rien d’autre ; aucune image utilisée par un conteneur n’en est dépourvue.