Faites attention à ne pas supposer que l’interface web de mise à jour fonctionnera toujours. La mise à jour via la page web ne fonctionne pas toujours. Certaines mises à jour (comme une mise à jour très récente de la version de la base de données) nécessiteront une reconstruction en ligne de commande. Cela signifie d’accéder au serveur via SSH et d’utiliser la ligne de commande pour effectuer la reconstruction.
Contrairement à beaucoup d’administrateurs, j’utilise généralement l’interface web pour effectuer les mises à jour, mais j’ai une invite de commande ouverte pour exécuter la mise à jour manuellement si nécessaire.
J’ai donc suivi toute la procédure, avec l’aide du bot de Discourse, ce qui m’a facilité la tâche, car il semble que le sujet d’origine « Move from standalone container to separate web and data containers » ait été rédigé il y a 10 ans, et je ne voulais pas créer de désordre.
Après quelques questions et beaucoup de notes prises, je crois comprendre un peu mieux les choses. Mon installation fonctionne, donc je suppose que tout a été correctement configuré… ?
Le bot m’a indiqué que lorsque je veux mettre à jour quelque chose qui nécessite réellement l’utilisation de SSH, l’ordre des opérations devrait être le suivant :
# cela prendra environ 20 minutes (la première fois) ; généralement 5 à 15 min ensuite
# (ce n'est pas le temps exact du premier bootstrap — docker met en cache les couches lors des reconstructions ultérieures)
sudo ./launcher bootstrap web_only
# après un bootstrap réussi, exécutez :
sudo ./launcher destroy web_only && sudo ./launcher start web_only
# de temps en temps, vérifiez l'espace disque :
df -h
# et si l'espace disque est faible en raison d'anciennes images inutilisées :
sudo ./launcher cleanup
et je suis prêt à y aller.
Cette mise à jour « une fois par an » est un peu plus complexe, mais j’ai aussi pris des notes à ce sujet, je n’ai juste pas encore organisé ces notes, car je ne les utiliserai pas tout de suite.
Je ne suis pas un expert, d’autres sont bien plus compétents en la matière, mais… d’après mon expérience, il ne faut jamais compter sur le succès de la mise à jour via l’interface web, il faut toujours être prêt à reconstruire depuis la ligne de commande. La récente mise à niveau de PostgreSQL 15 à 18 détaillée ici était une formalité, on sait qu’on ne peut pas s’en tirer avec la mise à niveau via l’interface web.
Ce n’est pas si difficile, considérez la mise à jour via l’interface web comme une commodité ; si elle fonctionne… tant mieux, mais soyez prêts au cas où elle ne fonctionnerait pas. Au moins, quand elle échoue, elle vous fournit une explication informative sur ce qui s’est passé et ce qu’il faut faire pour le corriger. De nombreux administrateurs professionnels de Discourse ici vous diraient de ne même pas essayer. Mon forum est petit et à faible volume, je peux me permettre de parier, vous n’avez peut-être pas ce luxe.
je ne poste plus beaucoup ici ces derniers temps, mais si vous avez besoin d’aide pour configurer un dual container ou si vous avez des questions, n’hésitez pas à m’envoyer un message privé. J’exploite deux forums distincts en dual container derrière un CDN Cloudflare avec un stockage d’objets compatible S3 (R2). Oui, c’est un peu plus complexe qu’un single container, mais ce n’est pas aussi difficile que beaucoup le pensent. C’est très facile à maintenir et vous pouvez utiliser un script bash pour simplifier encore davantage les mises à jour.