Oui, désolé, j’ai oublié d’ajouter que j’avais déjà ajouté le modèle Cloudflare au fichier app.yml il y a longtemps. Nous avons toujours été derrière Cloudflare, depuis le premier jour.
Voici une partie de app.yml, nous avons nos propres certificats renouvelés indépendamment, c’est pourquoi celui de letsencrypt est commenté :
## voici le modèle tout-en-un, autonome de conteneur Docker Discourse
##
## Après avoir apporté des modifications à ce fichier, vous DEVEZ reconstruire
## /var/discourse/launcher rebuild app
##
## SOYEZ *TRÈS* PRUDENT LORS DE LA MODIFICATION !
## LES FICHIERS YAML SONT EXTRÊMEMENT SENSIBLES AUX ERREURS D'ESPACEMENT OU D'ALIGNEMENT !
## visitez http://www.yamllint.com/ pour valider ce fichier si nécessaire
templates:
- "templates/postgres.template.yml"
- "templates/redis.template.yml"
- "templates/web.template.yml"
- "templates/web.ratelimited.template.yml"
## Décommentez ces deux lignes si vous souhaitez ajouter Lets Encrypt (https)
- "templates/web.ssl.template.yml"
# - "templates/web.letsencrypt.ssl.template.yml"
- "templates/cloudflare.template.yml"
## quels ports TCP/IP ce conteneur doit-il exposer ?
## Si vous souhaitez que Discourse partage un port avec un autre serveur web comme Apache ou nginx,
## voir https://meta.discourse.org/t/17247 pour plus de détails
expose:
- "80:80" # http
- "443:443" # https
[...]
Il semble que votre PostgreSQL soit surchargé. Il semble que la majeure partie de votre RAM soit inactive, j’essaierais d’ajuster la base de données pour qu’elle l’utilise et de voir comment les choses se passent ensuite.
Mais… pourquoi soudainement ? Après une simple mise à jour de la couche applicative ?
J’utilise le plugin d’exportation Prometheus de Discourse.
Si j’ajoutais un exportateur PostgreSQL en tant qu’autre conteneur sur la VM, serait-il possible de lui permettre d’accéder aux métriques de l’installation PostgreSQL de Discourse ?
Pas sûr que ce soit lié, mais cela a certainement commencé après la mise à jour, cliquer sur le bouton ignorer dans l’onglet non lu renvoie toujours un 503.
Eh bien, comme il semble qu’il n’y ait pas de solution, je vais essayer de revenir à la dernière version stable car elle est censée être… vous savez, stable.
Je croise les doigts pour qu’il n’y ait pas une dépendance principale qui casse le processus de compilation, comme la dernière fois.
Vous ne pouvez pas revenir de tests-passés à stable, à moins qu’une version stable supérieure ne soit disponible. La prochaine occasion pour vous sera donc lorsque la 3.4.0 sera publiée, je suppose que ce sera autour de Noël ou après…
Eh bien, je viens de le faire. Cela semble fonctionner. Nous ne nous soucions de toute façon d’aucune des fonctionnalités de la 3.3.0.
Je vais voir s’il y a encore des problèmes. Le pire qui puisse arriver, c’est que nous ayons toujours une pléthore de 429 et 502, pas un si grand changement.
Je mentionne toujours la version dans laquelle je me trouve lorsque je publie un problème.
Je pense qu’il est important de se rappeler que, précisément parce qu’il s’agit d’un logiciel open source, les problèmes critiques devraient être pris en compte au lieu d’écrire des choses comme ceci :
C’est encore un autre exemple de personnes qui se donnent du mal et passent à la version « stable », rencontrant des bugs qui passent entre les mailles du filet parce que ce n’est pas la version déployée la plus populaire.
Quand « stable » devrait signifier « stable », pas « obsolète ».
Le fait que des dépendances de base comme discourse docker soient poussées sans système d’étiquetage devrait suffire à être un peu plus humble lorsque l’on répond aux utilisateurs qui signalent un problème.
Je parlais du fait que vous mentionniez que vous aviez rétrogradé alors que techniquement vous ne le pouviez pas.
Je pense qu’il est important de se rappeler… que je ne travaille pas pour Discourse et que je vous aide de mon propre temps, donc je n’apprécie pas votre ton, ni ne suis en mesure de faire quoi que ce soit avec vos commentaires.
