Mises à jour
Deux choses se mettent à jour, volontairement de façon indépendante :
| Se met à jour | Qui décide | |
|---|---|---|
| L'application | Automatiquement, au redémarrage | Chaque utilisateur |
| La pile serveur | Quand vous lancez une mise à jour | L'administrateur |
Une mise à jour de l'application ne touche jamais votre serveur. C'est délibéré : aucun serveur documentaire ne devrait redémarrer parce que quelqu'un a accepté une mise à jour d'application.
Avant de mettre à jour
Faites une sauvegarde. Admin → Sauvegardes → Sauvegarder maintenant. Trente secondes, et c'est ce qui sépare une mise à jour ratée d'un après-midi perdu.
Le backend se protège aussi : lorsqu'une mise à jour modifie le schéma de la base, il en fait d'abord un export et refuse de migrer si cet export échoue.
Mettre à jour depuis l'application
Admin → Mises à jour affiche la version actuelle et l'existence d'une version plus récente. Lancer la mise à jour fait tout, en affichant le journal en direct : récupération du fichier compose courant, téléchargement des nouvelles images et redémarrage de la pile.
Comptez quelques minutes et un gros téléchargement. L'application est inutilisable pendant le redémarrage du backend ; elle se reconnecte seule.
Vérifier automatiquement les mises à jour ne contrôle que le fait d'être prévenu. Rien ne s'installe tout seul.
Mettre à jour depuis un terminal
cd /opt/chronicler
docker compose pull
docker compose up -d
docker compose logs -f backend
pull récupère les nouvelles images, up -d recrée les conteneurs modifiés. Vos
volumes — base, documents, modèles — ne sont pas touchés.
docker-compose.yml par la version publiée. Les modifications manuelles de ce
fichier (montage de sauvegarde externe, modèle fixé) sont perdues. Si vous l'avez
personnalisé, mettez à jour depuis le terminal, ou conservez votre copie et
réappliquez-la après chaque mise à jour.Figer une version
latest signifie que chaque mise à jour vous emmène sur la version la plus
récente. Sur un serveur dont des gens dépendent, figez-la :
CHRONICLER_VERSION=1.0.9
Mettre à jour devient alors un acte délibéré : changez le numéro,
docker compose up -d.
Revenir en arrière
Figer la version précédente
CHRONICLER_VERSION=1.0.8
Redémarrer
docker compose up -d
Restaurer la sauvegarde si le schéma a changé
Si la version plus récente a migré la base, un backend plus ancien peut ne pas savoir la lire. Restaurez la sauvegarde prise avant la mise à jour (Sauvegardes et restauration).
Mettre à jour Ollama
Le runtime du modèle a sa propre version :
OLLAMA_VERSION=0.32.4
N'y touchez pas sans raison précise. Les modèles téléchargés sont dans un volume distinct et survivent au changement.
Après une mise à jour
- Connectez-vous et posez une question.
- Vérifiez que Admin → Modèle affiche toujours votre modèle comme actif.
- Vérifiez que Admin → Licence affiche toujours Active.
- Si la recherche semble fausse, lancez Tout réindexer.
À quelle fréquence
Environ une fois par mois est raisonnable pour un serveur en production : assez récent pour les correctifs, sans essuyer les plâtres pour tout le monde. Lisez les notes de version pour tout ce qui mentionne migrations ou changements incompatibles, et ne mettez jamais à jour une heure avant d'en avoir besoin.