Mettre à jour une instance

Une mise à jour ordinaire, ce sont deux commandes :

git pull
docker compose up -d --build

L’application applique ses nouvelles migrations elle-même avant de servir.

Danger

Prenez une sauvegarde avant, celle des deux de Sauvegarder que vous tenez. Une mise à jour apporte les migrations dont elle a besoin, une migration réécrit vos tables, et on ne défait pas une migration.

L’installation se fait une fois, à Premier démarrage. Ceci est la partie qui se répète.

Ce que coûte la seconde commande

Pas les secondes d’un redémarrage. Le pull a changé les sources, donc l’image est bâtie depuis elles de nouveau, ce qui sur une petite machine de maison se compte en minutes plutôt qu’en secondes, la compilation de l’interface pour l’essentiel, et Docker affiche la construction au fur et à mesure.

L’instance continue de répondre pendant tout ce temps, depuis le conteneur qui fait encore tourner l’image précédente. L’interruption, c’est l’échange de la fin : pendant quelques secondes l’adresse ne répond plus rien, et c’est le nouveau conteneur qui démarre et applique les nouvelles migrations avant de servir.

L’onglet qui a une visite de retard

Un navigateur qui avait déjà l’instance ouverte a une visite de retard sur elle, et le dit désormais. Badlen déclare un service worker, si bien qu’un chargement de page après une mise à jour vient du cache de ce navigateur et reste la construction précédente, parlant à une API mise à jour. L’onglet ouvert demande à l’instance quelle version elle sert, environ toutes les demi-heures et chaque fois que l’onglet revient au premier plan ; quand la réponse n’est pas la version depuis laquelle la page a elle-même été bâtie, une ligne apparaît en bas de l’écran et propose de recharger.

C’est une proposition et jamais plus que cela. Elle ne prend pas le focus, elle se place sous les fenêtres de dialogue pour ne pas pouvoir tomber par-dessus un formulaire en cours de saisie, et son bouton Plus tard la renvoie pour de bon pour cette version, dans cet onglet et dans le suivant. Le rechargement qu’elle propose est celui qui vaut d’être pris : il rafraîchit d’abord le service worker, si bien que la page qui revient est la nouvelle construction plutôt que celle du cache, et la session comme les chiffres y survivent. L’ignorer entièrement ne coûte rien de plus que de rester sur l’ancienne interface jusqu’au rechargement suivant.

Quelle version tourne

Réglages → À propos le dit, sur toute installation. Il lit le fichier VERSION commité dans le dépôt, que l’image emporte, si bien que cela fonctionne sur une construction faite depuis une archive de sources téléchargée, sans le moindre historique git. C’est le numéro à citer dans un rapport de bug. Entre deux versions publiées il porte un suffixe -dev, qui veut dire une construction faite depuis main plutôt que depuis une étiquette ; docker compose logs app nomme toujours chaque migration appliquée en montant.

Ce suffixe est aussi la limite de la proposition ci-dessus. Le numéro bouge quand une version est publiée, si bien que deux reconstructions depuis main entre deux publications portent la même version et qu’un onglet ouvert n’a rien à comparer : il ne proposera pas le rechargement, et un chargement de page sera encore répondu depuis le cache du navigateur lors de cette première visite. Suivre les étiquettes est ce qui fait qu’une mise à jour s’annonce ; suivre main veut dire recharger l’onglet vous-même après une mise à jour, comme avant.

L’image qu’elle a remplacée

Chaque mise à jour laisse sur la machine l’image qu’elle a remplacée, sans étiquette, puisque seule l’étiquette est passée à la nouvelle, et aussi grosse qu’elle est : près de 800 Mo pièce. docker image prune emporte celles qui n’ont pas d’étiquette et rien d’autre ; aucune image qu’utilise un conteneur n’est sans étiquette.

Quand l’image postgres elle-même change de version majeure, cette page ne suffit plus : Montée de version PostgreSQL est l’opération qui n’est pas un docker compose up.