La mise à jour automatique des applications : mode d'emploi
Le script maj-applications met à jour vos conteneurs chaque dimanche. Ce qu'il fait, comment voir ce qui a changé, le lancer, le désactiver et revenir en arrière.
Avec l’option Mise à jour des applis de Mon serveur, vos applications se mettent à jour toutes seules le dimanche à 5 h. Pratique, mais il faut savoir ce qui se passe, et quoi faire le jour où une mise à jour casse quelque chose.
Ce que fait le script
/usr/local/bin/maj-applications est très court. Pour chaque dossier de /opt/stacks :
docker compose pull -q # télécharge la dernière version des images
docker compose up -d # recrée les conteneurs dont l'image a changé
Puis docker image prune -f supprime les anciennes versions devenues inutiles, pour ne pas remplir le disque.
« Dernière version » veut dire : la dernière version du tag écrit dans le compose.yml. Avec image: gitea/gitea:1,
vous recevez les 1.x, jamais la 2.0. Avec :latest, vous recevez tout, y compris les changements majeurs.
Voir ce qui s’est passé dimanche
journalctl -u maj-applications --since "last sunday"
systemctl list-timers maj-applications.timer
Pour savoir quelle version tourne maintenant :
sudo docker ps --format "table {{.Names}}\t{{.Image}}\t{{.Status}}"
« Up 2 days » le mardi : le conteneur a été recréé dimanche, donc mis à jour.
Mettre à jour tout de suite
sudo systemctl start maj-applications.service
Ou une seule application, à la main :
cd /opt/stacks/vaultwarden
sudo docker compose pull && sudo docker compose up -d
Désactiver les mises à jour automatiques
sudo systemctl disable --now maj-applications.timer
Le script reste installé : vous pouvez le lancer à la main quand vous voulez, ou réactiver la planification avec
enable --now.
Exclure une seule application
Le plus simple : figer sa version dans son compose.yml. Remplacez par exemple
image: ghcr.io/immich-app/immich-server:release
par une version précise, celle qui tourne aujourd’hui (numéro exact sur la page « Releases » de l’application) :
image: ghcr.io/immich-app/immich-server:vX.Y.Z # remplacez par le vrai numéro
Le script continuera de passer, mais il n’y aura jamais rien de nouveau à télécharger pour ce tag. Pour Immich,
figez le même numéro sur immich-server et immich-machine-learning : les deux doivent toujours avoir la même version.
Une mise à jour a tout cassé : revenir en arrière
- Trouvez la version d’avant dans l’historique des versions de l’application (page « Releases » de son dépôt GitHub, ou les tags sur Docker Hub).
- Figez cette version dans le
compose.yml, comme ci-dessus. - Relancez :
cd /opt/stacks/<application>
sudo docker compose up -d
- Si les données ont été modifiées par la nouvelle version (migration de base de données), restaurez aussi la sauvegarde de la nuit précédente : celle de 3 h, faite avant la mise à jour de 5 h.
Pourquoi la sauvegarde passe avant : la sauvegarde tourne à 3 h et la mise à jour à 5 h. Le dimanche matin, vous avez donc toujours une copie de l’état d’avant la mise à jour. Ne changez pas ces horaires dans le mauvais sens.
Faut-il activer les mises à jour automatiques ?
- Oui si vous n’allez pas sur le serveur toutes les semaines : une application jamais mise à jour finit par avoir des failles connues.
- Non pour les applications à risque de casse (Immich et Nextcloud changent souvent en profondeur) : figez leur version et mettez-les à jour vous-même après avoir lu les notes de version.
Le guide mettre à jour ses applications sans rien casser détaille une approche plus prudente : n’installer une version que lorsqu’elle a quelques jours.
Une commande qui ne marche pas, une explication pas claire ? Signaler une erreur dans cette page.