Merci — donc ./launcher rebuild web_only (ou rebuild data) au lieu de ./launcher rebuild app, et je devrais lire attentivement les mises à jour pour voir quand postgres ou redis est mis à jour afin de les mettre à jour manuellement également. Et le principal avantage par rapport à une installation autonome est que les reconstructions n’ont pas besoin d’attendre que la base de données s’arrête puis redémarre, en annulant les transactions si elle était arrêtée.
Mais avec les derniers changements de Falco, la base de données ne devrait jamais être arrêtée à moins qu’elle ne prenne plus de 10 minutes pour s’arrêter, ce qui ne sera certainement pas le cas à moins que nous ayons beaucoup plus d’utilisateurs. Donc les mises à jour ne devraient pas échouer à cause de ce problème, et l’impact principal est simplement de rallonger les mises à jour de quelques minutes.
D’après ce que je comprends, le changement ajoute finalement beaucoup de complexité et de charge mentale pour très peu de gain. Veuillez me corriger si je me trompe, ce n’est pas dit avec sarcasme/etc.
Juste pour information, le changement devrait offrir des avantages substantiels pour justifier cette charge mentale car tout cela est un service bénévole de ma part (qui s’étend maintenant sur plus de 15 ans, mais néanmoins), ce n’est pas mon travail. C’est une situation où votre expérience peut varier.
Beaucoup de gens partagent cette opinion, ce qui continue de me surprendre. Les mises à niveau de Postgres sont moins fréquentes qu’une fois par an, et il n’y a généralement aucune pénalité à les retarder de plusieurs mois après le changement initial. Avoir une configuration à 2 conteneurs signifie que vous pouvez plus facilement retarder la mise à niveau de postgres que si vous avez un seul conteneur, ce qui me semble être un autre avantage.
Retarder les mises à niveau de postgres a toujours signifié un simple changement de configuration yaml, à moins que vous n’envisagiez d’arrêter de le prendre en charge. Nous pouvons supporter quelques minutes d’indisponibilité supplémentaires pour les mises à niveau, et à mes yeux, cela représente moins de risques que de compter sur une seule personne (moi !) pour maintenir correctement une configuration moins standard et plus complexe.
De mon point de vue, le principal avantage de deux conteneurs est la réduction des temps d’arrêt - comme vous, je pense, je suis d’accord avec 20-30 minutes d’arrêt tous les quelques mois. Mais il est facile de comprendre que pour certains forums, c’est trop.
Absolument. Même si nous parlions d’une indisponibilité de 90 minutes contre 5 minutes séparées, je ne penserais probablement pas que le changement en valait la peine, bien que je ferais probablement les mises à niveau tard le soir plutôt qu’en plein milieu de la journée si cela prenait autant de temps. Nous ne sommes pas une plateforme de trading boursier en temps réel, nous sommes un forum gratuit sur les jeux vidéo.
Avec la configuration à 2 conteneurs, cela signifie que vous n’avez même pas besoin de savoir pour apporter ce simple changement. Et il n’y aurait aucune chance que vous commenciez une mise à niveau et que vous appreniez ensuite que vous aviez déjà commencé à mettre à niveau postgres.
Mais j’ai passé près de 35 ans à vivre dans un shell.
Et maintenant, j’ai un tableau de bord qui automatise ces mises à niveau en ligne de commande (et gère les mises à niveau de postgres et un tas d’autres choses).
Mais ne réparez pas ce qui n’est pas cassé, et je comprends que déplacer des choses et potentiellement casser des choses fait peur.
J’ai commencé avec Slackware moi-même, je ne vois tout simplement pas la maintenance du forum comme un projet amusant et je veux qu’elle disparaisse pour pouvoir continuer à me cogner la tête contre le mur en essayant d’intégrer Google Home à Home Assistant (ou tout autre chose qui me plaît cette semaine).