Si vous effectuez les mises à jour à partir de l’interface utilisateur, vous finirez par recevoir un message indiquant que vous devez effectuer une mise à jour en ligne de commande. Cela dépend non pas de Debian, mais de l’image Discourse de base.
2 « J'aime »
Et avec la méthode à 2 conteneurs, il n’y aurait pas du tout de bouton de mise à jour de l’interface graphique, n’est-ce pas ?
La mise à jour de l’interface graphique provient du plugin discourse_docker. Si vous avez ce plugin, vous avez la mise à jour de l’interface graphique.
Lorsqu’il y a des vulnérabilités découvertes dans les outils de manipulation d’images, une exception de code à distance s’est définitivement produite dans le passé, ce qui signifie que vous êtes à une téléversement d’image d’un système compromis.
Clear Linux a établi la norme en matière de rapidité de démarrage sous Linux. C’est un travail formidable, j’approuve de tout cœur.
1 « J'aime »
Oh, cela change un peu les choses alors. Pour une raison quelconque, je pensais que le programme de mise à jour de l’interface graphique ne fonctionnerait pas avec une installation non standard à 2 conteneurs. Dans ce cas, tant que l’administrateur est techniquement compétent, il semble qu’il n’y ait pas beaucoup d’inconvénients à une installation à 2 conteneurs. Je veux absolument avoir des mises à jour de l’interface graphique, par exemple si je voyage avec seulement mon téléphone et qu’une mise à jour de sécurité majeure de Discourse sort, je peux au moins l’appliquer sans accès SSH.
1 « J'aime »
C’est ce que je crois. Il faut juste faire assez attention pour savoir quand il y a une mise à niveau de Postgres ou Redis qui nécessite de reconstruire le conteneur de données. Il faut aussi savoir faire ./launcher bootstrap web_only && ./launcher destry web_only; ./launcher start web_only, mais ce n’est pas si difficile. Vous pouvez simplement faire un ./launcher rebuild web_only, mais cela met le site hors service pendant sa reconstruction.
2 « J'aime »
Pour être complet : la construction de l’interface utilisateur Web n’a normalement aucun temps d’arrêt ; le bootstrap/destroy/start a un temps d’arrêt minimal et je ne le ferais que normalement avec une page de maintenance fournie en externe comme avec nginx en externe, comme documenté ici. Mais c’est de toute façon une bonne pratique, ne serait-ce que pour obtenir les adresses IPv6 dans le conteneur.
Très bien, merci. Et avec une installation à 2 conteneurs, recevez-vous toujours les notifications du tableau de bord Discourse lorsque le conteneur doit être reconstruit ? Et dans ce cas, je pourrais déterminer s’il faut reconstruire uniquement l’application ou aussi le conteneur de données ?
1 « J'aime »
Oui. Je le vois maintenant car je n’ai pas appliqué la mise à jour « seule la version a changé » 3.1.0.beta1. 
1 « J'aime »
C’est un cas de « tout va bien jusqu’à ce que ça n’aille plus » — les gens paniquent lorsque la mise à jour échoue dans l’interface utilisateur et qu’ils ne savent pas qu’il faut faire git pull; ./launcher rebuild app pour contourner le problème. Cela se produit à chaque fois qu’il y a un changement qui invalide la mise à jour de l’interface graphique, je pense. C’est encore arrivé :
Je pense que cette panique souligne l’importance d’avoir un mécanisme de mise à jour cohérent et normal qui évite cette expérience.
Dans le même temps, j’ai rencontré le cas également peu fréquent où le bootstrap casse le système en cours d’exécution : les mises à jour avec un temps d’arrêt quasi nul se cassent occasionnellement comme cela, une ou deux fois par an peut-être en moyenne ? Il ne faut donc pas tarder entre le bootstrap et le destroy/start.
Je devrais mettre à jour le texte pour clarifier cela, je vais donc le faire ensuite.
Je n’ai pas encore déployé LibreTranslate, mais j’envisage de le faire pour rendre mon site plus accessible à l’international.
Si j’y parviens, j’ai l’intention de l’ajouter au premier message. 
2 « J'aime »