Problème de pare-feu avec l'exécution de plusieurs conteneurs après la mise à niveau

AstonJ · Janvier 31, 2021, 10:03

J’ai rencontré des problèmes lors de la mise à niveau : le premier forum a échoué dès la première tentative (via le tableau de bord), puis a échoué à nouveau lors d’une reconstruction, mais il semble avoir fonctionné lors de la deuxième tentative de reconstruction, bien que j’aie dû effectuer une reconstruction supplémentaire par la suite. Cela m’a rappelé qu’il fallait arrêter toutes les instances de Discourse lors de la mise à jour vers PG12 (il y a trois forums Discourse sur ce serveur, chacun avec son propre conteneur). Ainsi, la procédure suivante a fonctionné pour les deux autres forums :

Cependant, pour une raison inconnue, le premier forum n’est plus accessible ; Safari indique que le serveur a interrompu la connexion de manière inattendue. Une reconstruction semble se dérouler sans problème, mais le forum reste inaccessible. Je peux accéder à l’application et à la console Rails, et la base de données semble intacte.

Les seuls avertissements que j’ai pu voir lors de la reconstruction et qui pourraient être pertinents :

168:M 31 Jan 2021 21:39:22.459 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
168:M 31 Jan 2021 21:39:22.459 # Server initialized
168:M 31 Jan 2021 21:39:22.459 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
168:M 31 Jan 2021 21:39:22.459 # WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo madvise > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled (set to 'madvise' or 'never').
168:M 31 Jan 2021 21:39:22.459 * Loading RDB produced by version 6.0.9
168:M 31 Jan 2021 21:39:22.459 * RDB age 21 seconds
168:M 31 Jan 2021 21:39:22.459 * RDB memory usage when created 4.03 Mb
168:M 31 Jan 2021 21:39:22.466 * DB loaded from disk: 0.006 seconds
168:M 31 Jan 2021 21:39:22.466 * Ready to accept connections

production.log :


Job exception: Error connecting to Redis on localhost:6379 (Errno::ENETUNREACH)

Error connecting to Redis on localhost:6379 (Errno::ENETUNREACH) subscribe failed, reconnecting in 1 second. Call stack /var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.2.5/lib/redis/client.rb:367:in `rescue in establish_connection'

Des messages similaires apparaissent dans unicorn.stderr.log et unicorn.stdout.log.

En entrant dans le conteneur et en exécutant redis-cli ping, je reçois un PONG. Redis est en cours d’exécution sur le serveur (mais pas dans les conteneurs individuels - bien que cela ait toujours été le cas, à ma connaissance).

Avez-vous des idées sur ce qui pourrait se passer ?

(J’ai également redémarré le serveur et créé un nouveau certificat letsencrypt pour ce domaine, par mesure de précaution, mais le problème persiste.)

fitzy · Janvier 31, 2021, 11:25

Cela semble indiquer que tout devrait fonctionner… Avez-vous essayé avec un autre navigateur ou vidé votre cache ? Si cela ne résout pas le problème, pourriez-vous publier le résultat de :

curl -vv -o /dev/null <forum url>

AstonJ · Janvier 31, 2021, 11:36

J’ai essayé sur plusieurs navigateurs, mais j’obtiens toujours la même erreur. Voici la sortie de cette commande :

~$ curl -vv -o /dev/null https://metaruby.com
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying 78.46.110.60...
* TCP_NODELAY set
* Connected to metaruby.com (78.46.110.60) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
} [226 bytes data]
* TLSv1.2 (IN), TLS handshake, Server hello (2):
{ [93 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [2473 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [333 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [70 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
{ [1 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: CN=metaruby.com
*  start date: Jan 31 03:33:05 2021 GMT
*  expire date: May  1 03:33:05 2021 GMT
*  subjectAltName: host "metaruby.com" matched cert's "metaruby.com"
*  issuer: C=US; O=Let's Encrypt; CN=R3
*  SSL certificate verify ok.
> GET / HTTP/1.1
> Host: metaruby.com
> User-Agent: curl/7.64.1
> Accept: */*
> 
  0     0    0     0    0     0      0      0 --:--:--  0:00:01 --:--:--     0* TLSv1.2 (IN), TLS alert, close notify (256):
{ [2 bytes data]
* Empty reply from server
  0     0    0     0    0     0      0      0 --:--:--  0:00:01 --:--:--     0
* Connection #0 to host metaruby.com left intact
curl: (52) Empty reply from server
* Closing connection 0

lucasbasquerotto · Février 1, 2021, 12:39

Certaines causes possibles de l’erreur de réponse vide :

Le serveur se trouve dans un VPN et il n’y a pas d’accès au port.
Si vous avez plusieurs instances de Discourse sur le même serveur, je suppose qu’il y a un proxy inverse devant. Assurez-vous qu’il pointe vers le conteneur Discourse (il se peut que vous deviez le redémarrer).
Il n’y a pas assez d’espace libre sur le serveur (vous pouvez exécuter df -hT /).

Je commencerais par vérifier l’espace disque disponible (3).

AstonJ · Février 1, 2021, 4:51

L’utilisation du disque était affichée à 31 %, mais j’ai quand même exécuté ./launcher cleanup :

docker container ls 
(Vérifier que les trois conteneurs du forum sont en cours d'exécution)

./launcher cleanup

ATTENTION ! Cela supprimera tous les conteneurs arrêtés.
Êtes-vous sûr de vouloir continuer ? [o/N] o
Espace récupéré au total : 0 octets
ATTENTION ! Cela supprimera toutes les images sans aucun conteneur associé.
Êtes-vous sûr de vouloir continuer ? [o/N] o
Images supprimées :
...
Espace récupéré au total : 32,56 Go

Nous utilisons HAProxy et je l’ai vérifié (et redémarré) : il est opérationnel (nous effectuons également la redirection de HTTP vers HTTPS via celui-ci, ce qui fonctionne également pour le domaine, donc je ne pense pas que le problème vienne de là — d’autant plus que tout fonctionnait avant cette mise à jour).

Je peux toujours accéder au conteneur et utiliser la console Rails, et la base de données est toujours présente/connectée au conteneur — c’est donc extrêmement étrange — quelqu’un aurait-il d’autres idées ou d’autres étapes pour dépanner ce problème ?

fitzy · Février 1, 2021, 10:47

Si vous n’avez pas pu déboguer le problème, une option consiste à effectuer une sauvegarde en ligne de commande et à la restaurer sur un nouveau site vierge fonctionnant sous PG13. Sinon, si vous avez besoin que votre site soit à nouveau opérationnel, vous pouvez revenir à la version PG12, déplacer le répertoire shared/postgres_data_old existant vers shared/postgres_data et reconstruire. Cependant, je recommande d’essayer la méthode de sauvegarde/restauration, car le problème ne semble pas être lié à la mise à niveau de la base de données elle-même.

pfaffman · Février 1, 2021, 10:51

Vous dépassez un peu une installation standard prise en charge ici.

Chaque instance Discourse dispose-t-elle de sa propre base PostgreSQL, ou avez-vous une seule base PostgreSQL pour les trois ?

Si vous avez un seul conteneur PostgreSQL/données, alors vous devez ARRÊTER toutes les instances Discourse avant d’essayer de mettre à niveau PostgreSQL.

HaProxy n’a rien à voir avec PostgreSQL, donc je ne pense pas que cela ait de l’importance.

AstonJ · Février 2, 2021, 12:38

Si vous avez d’autres idées pour enquêter sur ce problème, je serais ravi de les essayer, Michael. Heureusement, ce n’est pas un gros problème que ce forum soit hors ligne, car il était déjà en mode lecture seule (ayant été remplacé par un autre forum).

Si vous n’avez plus d’idées, je vais procéder à la restauration d’une sauvegarde, mais si possible, j’aimerais résoudre ce problème car je suis intéressé à comprendre pourquoi cela s’est produit (je suppose que vous aussi). Je suis donc tout à fait prêt à enquêter davantage si vous l’êtes aussi.

Pour être honnête, cela m’a rendu un peu nerveux à l’idée de convertir certains de mes autres forums vers Discourse, et savoir ce qui a mal tourné pourrait nous être utile à tous.

Il s’agit d’une installation standard à plusieurs conteneurs où chaque forum possède son propre fichier app.yml et une configuration de conteneurs basée sur host: discourse/shared-site-name/standalone et host: discourse/shared-site-name/standalone/log/var-log (comme indiqué dans les questions que j’ai posées et les publications sur ce forum).

En accédant à chaque conteneur et en exécutant psql (sudo -u postgres psql discourse) puis \l+, on voit qu’il n’y a qu’une seule base de données discourse par conteneur (et chacune a une taille différente), ce qui laisse supposer qu’il s’agit d’instances Discourse indépendantes.

Avez-vous un lien vers la méthode « standard » pour exécuter plusieurs forums Discourse indépendants sur un serveur ? Je peux vérifier si cela correspond à ce que j’ai ici, bien que je sois assez certain que ma configuration soit basée sur des publications et des conseils de l’équipe Discourse.

fitzy · Février 2, 2021, 12:47

Exécutez-vous nginx à l’intérieur du conteneur ? La prochaine étape serait de suivre où aboutissent les requêtes. Si je comprends bien, vous avez HAProxy qui effectue la terminaison SSL puis qui fait passer les requêtes vers les conteneurs respectifs ?

pfaffman · Février 2, 2021, 12:59

Ah. OK. Donc pour chacun, vous devez exécuter ./launcher rebuild VOTRE-NOM-D'APPLICATION deux fois. Je ne pense pas que ce soit possible via l’interface web.

Et les conteneurs yml ont-ils tous les modèles SSL et Let’s Encrypt commentés (ou supprimés) ?

AstonJ · Février 2, 2021, 1:16

À ma connaissance, les conteneurs eux-mêmes sont tous « standards » (donc, je suppose que chacun exécute nginx) et oui, HAProxy gère tout le SSL et dirige les requêtes vers chaque conteneur.

Ma configuration suit la procédure décrite ici : Set up Discourse on a server with existing Apache sites (avec la version SSL de la configuration HAProxy ici).

Il y avait un problème avec la configuration HAProxy :

backend main_apache_sites
  server server1 127.0.0.1:8080 cookie A check
  cookie JSESSIONID prefix nocache

backend discourse_docker
  server server2 127.0.0.1:8888 cookie A check
  cookie JSESSIONID prefix nocache

backend discourse_docker_2
  server server2 127.0.0.1:8889 cookie A check
  cookie JSESSIONID prefix nocache

backend discourse_docker_3
  server server2 127.0.0.1:8890 cookie A check
  cookie JSESSIONID prefix nocache

backend letsencrypt-backend
  server letsencrypt 127.0.0.1:54321

Pour une raison quelconque, tous les backends Discourse avaient server2 sur la deuxième ligne. J’ai modifié ces entrées en server2, server3, etc. hier, mais cela n’a rien changé (et cela fonctionnait parfaitement ainsi auparavant).

Y a-t-il des fichiers journaux spécifiques que je pourrais consulter pour obtenir d’autres indices ? Peut-être des fichiers journaux Docker ?

Oui, ils sont commentés :

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"

fitzy · Février 4, 2021, 4:25

Les journaux nginx à l’intérieur des conteneurs d’application devraient pouvoir confirmer que les requêtes parviennent bien à l’application. Pouvez-vous les vérifier ? nginx dans le conteneur fait office de proxy pour les requêtes vers 127.0.0.1:3000, ce qui correspond au processus unicorn.

AstonJ · Février 4, 2021, 9:12

En examinant /var/log/nginx et /shared/log/rails, rien ne ressort vraiment. En fait, aucun des fichiers de journalisation n’a été mis à jour aujourd’hui (le 4), à l’exception de /shared/log/rails/production.log, qui ne contient que quelques tâches comme celle-ci :

Journaux Rails :

Journaux Nginx :

J’ai également modifié le port dans HAProxy et j’ai obtenu l’erreur « serveur introuvable » comme prévu. Ensuite, j’ai mis à jour le conteneur avec le même port, et le comportement est revenu à l’état initial (je pense donc que cela permet d’exclure un problème lié à HAProxy).

Y a-t-il des journaux Docker à consulter ? Ou puis-je sauvegarder/exporter ce conteneur et vous l’envoyer afin que vous puissiez l’examiner ? Je suppose que vous vous demandez ce qui a mal tourné tout autant que moi

AstonJ · Février 4, 2021, 9:23

En fait, je viens de regarder à nouveau (ce qui précède datait d’hier soir) et il y en a maintenant dans :

unicorn.stderr.log

(Désolé, cela ne me permet pas de copier le texte)

Aucun des logs nginx n’a été modifié aujourd’hui, bien que le dernier log du 30 janvier indique 7 : limiting requests by zone “flood” client: my.ip.address, POST /mini-profiler-resources type error.

Edit : je ne sais pas si cela aide, mais en exécutant docker logs APP :

Pour le forum qui ne fonctionne pas :

# docker logs metaruby
run-parts: executing /etc/runit/1.d/00-ensure-links
run-parts: executing /etc/runit/1.d/00-fix-var-logs
run-parts: executing /etc/runit/1.d/01-cleanup-web-pids
run-parts: executing /etc/runit/1.d/anacron
run-parts: executing /etc/runit/1.d/cleanup-pids
Cleaning stale PID files
run-parts: executing /etc/runit/1.d/copy-env
Started runsvdir, PID is 43
ok: run: redis: (pid 55) 0s
ok: run: postgres: (pid 56) 0s
chgrp: invalid group: ‘syslog’
supervisor pid: 50 unicorn pid: 89

Pour le forum 2 (qui fonctionne bien) :

# docker logs f2

run-parts: executing /etc/runit/1.d/00-ensure-links

run-parts: executing /etc/runit/1.d/00-fix-var-logs

run-parts: executing /etc/runit/1.d/01-cleanup-web-pids

run-parts: executing /etc/runit/1.d/anacron

run-parts: executing /etc/runit/1.d/cleanup-pids

Cleaning stale PID files

run-parts: executing /etc/runit/1.d/copy-env

Started runsvdir, PID is 42

ok: run: redis: (pid 55) 0s

ok: run: postgres: (pid 54) 0s

chgrp: invalid group: ‘syslog’

supervisor pid: 51 unicorn pid: 82

(51) Reopening logs

(51) Reopening logs

(51) Reopening logs

(51) Stopping Sidekiq

(51) Reloading unicorn (82)

(51) Waiting for new unicorn master pid...

(51) Waiting for new unicorn master pid...

(51) Waiting for new unicorn master pid...

(51) Waiting for new unicorn master pid...

(51) Waiting for new unicorn master pid...

(51) Waiting for new unicorn master pid...

(51) Waiting for new unicorn master pid...

(51) Waiting for new unicorn master pid...

(51) Waiting for new unicorn master pid...

(51) Waiting for new unicorn master pid...

(51) Waiting for new unicorn master pid...

(51) Waiting for new unicorn master pid...

(51) Waiting for new unicorn master pid...

(51) Waiting for new unicorn master pid...

(51) Waiting for new unicorn master pid...

(51) Waiting for new unicorn master pid... 22039

(51) Old pid is: 82 New pid is: 22039

(51) Stopping Sidekiq

(51) Reloading unicorn (22039)

(51) Waiting for new unicorn master pid...

(51) Waiting for new unicorn master pid...

(51) Waiting for new unicorn master pid...

(51) Waiting for new unicorn master pid...

(51) Waiting for new unicorn master pid...

(51) Waiting for new unicorn master pid...

(51) Waiting for new unicorn master pid...

(51) Waiting for new unicorn master pid...

(51) Waiting for new unicorn master pid...

(51) Waiting for new unicorn master pid...

(51) Waiting for new unicorn master pid...

(51) Waiting for new unicorn master pid...

(51) Waiting for new unicorn master pid...

(51) Waiting for new unicorn master pid...

(51) Waiting for new unicorn master pid...

(51) Waiting for new unicorn master pid...

(51) Waiting for new unicorn master pid...

(51) Waiting for new unicorn master pid...

(51) Waiting for new unicorn master pid... 23358

(51) Old pid is: 22039 New pid is: 23358

(51) Reopening logs

(51) Reopening logs

Pour le forum trois (qui fonctionne aussi bien) :

# docker logs f3

run-parts: executing /etc/runit/1.d/00-ensure-links

run-parts: executing /etc/runit/1.d/00-fix-var-logs

run-parts: executing /etc/runit/1.d/01-cleanup-web-pids

run-parts: executing /etc/runit/1.d/anacron

run-parts: executing /etc/runit/1.d/cleanup-pids

Cleaning stale PID files

run-parts: executing /etc/runit/1.d/copy-env

Started runsvdir, PID is 42

ok: run: redis: (pid 54) 0s

chgrp: invalid group: ‘syslog’

ok: run: postgres: (pid 55) 0s

supervisor pid: 56 unicorn pid: 88

(56) Reopening logs

(56) Reopening logs

(56) Reopening logs

(56) Reopening logs

(56) Reopening logs

fitzy · Février 5, 2021, 12:28

En examinant les journaux et en relisant vos réponses précédentes, il semble que l’application tente d’accéder à Redis sur localhost:6379 à l’intérieur du conteneur. Redis semble bien démarrer, mais pour une raison inconnue, la connexion échoue (c’est déroutant). Il est possible que ces messages d’erreur proviennent du moment où message_bus tente de se connecter avant que Redis ne démarre, ou après qu’il s’arrête en cas de redémarrage.

Vous avez mentionné que Redis est en cours d’exécution sur le serveur mais pas dans les conteneurs individuels — pourriez-vous préciser cela ?

Avec cette configuration, Redis s’exécutera à l’intérieur du conteneur (comme vous pouvez le constater dans la sortie des journaux Docker).

Par ailleurs, lorsque vous accédez à l’URL du site qui ne fonctionne pas, qu’apparaît-il dans vos journaux nginx ? error.log devrait être vide, tandis que access.log devrait contenir diverses requêtes HTTP. Nous essayons simplement de déterminer à quel moment exactement quelque chose échoue.

AstonJ · Février 5, 2021, 2:00

Désolé, j’ai confondu les choses. Redis fonctionne en réalité dans chaque conteneur, ce qui a été vérifié en exécutant ces commandes directement sur le serveur, puis dans chacun des trois conteneurs Discourse, avec le même résultat pour chacun :

$ redis-cli ping
PONG
$ redis-server
# Création du socket TCP d'écoute du serveur *:6379 : bind : Adresse déjà utilisée (cela signifie qu'il est déjà démarré)
$ redis-cli
127.0.0.1:6379> ping
PONG
127.0.0.1:6379> get mykey
(nil)
127.0.0.1:6379> set mykey somevalue
OK
127.0.0.1:6379> get mykey
"somevalue"

Il en va de même pour les trois conteneurs (remarquable : le premier get mykey renvoie toujours nil), il est donc raisonnable de dire que Redis est actif et fonctionne indépendamment dans tous les conteneurs.

Il est vide et rien n’a été écrit dans ce répertoire aujourd’hui :

drwxr-xr-x 2 www-data www-data  4096 Feb  4 21:26 .
drwxrwxr-x 9 root     root      4096 Feb  2 08:03 ..
-rw-r--r-- 1 www-data www-data     0 Feb  3 07:38 access.log
-rw-r--r-- 1 www-data www-data     0 Feb  2 08:03 access.log.1
-rw-r--r-- 1 www-data www-data   294 Feb  1 09:43 access.log.2.gz
-rw-r--r-- 1 www-data www-data 37598 Jan 30 23:56 access.log.3.gz
-rw-r--r-- 1 www-data www-data 58059 Jan 30 07:36 access.log.4.gz
-rw-r--r-- 1 www-data www-data 55988 Jan 29 07:34 access.log.5.gz
-rw-r--r-- 1 www-data www-data 73964 Jan 28 07:49 access.log.6.gz
-rw-r--r-- 1 www-data www-data 78069 Jan 27 07:53 access.log.7.gz
-rw-r--r-- 1 www-data www-data     0 Feb  3 07:38 error.log
-rw-r--r-- 1 www-data www-data     0 Feb  2 08:03 error.log.1
-rw-r--r-- 1 www-data www-data    20 Feb  1 00:31 error.log.2.gz
-rw-r--r-- 1 www-data www-data   632 Jan 30 23:46 error.log.3.gz
-rw-r--r-- 1 www-data www-data   265 Jan 29 09:07 error.log.4.gz
-rw-r--r-- 1 www-data www-data    20 Jan 28 07:50 error.log.5.gz
-rw-r--r-- 1 www-data www-data  3107 Jan 28 07:41 error.log.6.gz
-rw-r--r-- 1 www-data www-data    20 Jan 26 07:53 error.log.7.gz

J’ai vérifié les journaux d’accès d’un autre conteneur et tout est correct, donc c’est uniquement celui-ci qui pose problème.

Il semble que HAProxy transmette la requête, mais que le conteneur ne puisse pas la traiter ou l’accepter — je me demande s’il y a quelque chose qui pourrait être réinitialisé là-bas ? (Ce à quoi j’aurais pensé que reconstruire le conteneur suffirait déjà ?)

fitzy · Février 5, 2021, 2:39

Cela semble correspondre. Pouvez-vous confirmer quelles liaisons de ports sont présentes pour chaque conteneur lorsque vous exécutez docker ps sur l’hôte ?

AstonJ · Février 5, 2021, 3:11

Bien sûr :

IMAGE                   COMMAND             CREATED             STATUS              PORTS                                     
local_discourse/1      	"/sbin/boot"        Il y a 20 heures        En exécution depuis 20 heures         0.0.0.0:2225->22/tcp, 0.0.0.0:8892->80/tcp
local_discourse/2   	"/sbin/boot"        Il y a 4 jours          En exécution depuis 4 jours           0.0.0.0:2223->22/tcp, 0.0.0.0:8889->80/tcp
local_discourse/3       "/sbin/boot"        Il y a 4 jours          En exécution depuis 4 jours           0.0.0.0:2224->22/tcp, 0.0.0.0:8890->80/tcp

Mon intuition me dit que cela est lié à la tentative échouée via le tableau de bord — habituellement, pour les mises à jour de PostgreSQL ou majeures, le tableau de bord indique qu’une reconstruction est nécessaire et que la mise à jour est désactivée via celui-ci. Mais pour une raison quelconque, cela ne s’est pas produit (peut-être parce que je n’avais pas mis à jour ce forum depuis un moment — d’où l’idée de le faire d’abord via le tableau de bord) ou il est possible qu’il n’ait pas été arrêté ou démarré correctement avant d’effectuer la reconstruction

fitzy · Février 5, 2021, 3:15

Dans la configuration HAProxy, je vois que les backends sont configurés pour transférer vers les ports 8888, 8889 et 8890 :

AstonJ:

backend discourse_docker
  server server2 127.0.0.1:8888 cookie A check
  cookie JSESSIONID prefix nocache

backend discourse_docker_2
  server server2 127.0.0.1:8889 cookie A check
  cookie JSESSIONID prefix nocache

backend discourse_docker_3
  server server2 127.0.0.1:8890 cookie A check
  cookie JSESSIONID prefix nocache

Cependant, les conteneurs de l’application écoutent sur 8892, 8889 et 8890 – il semble y avoir une incohérence pour le backend discourse_docker. Est-ce que vous avez mis à jour la configuration depuis la publication de ce message ?

AstonJ · Février 5, 2021, 3:43

Oui, les ports HAProxy correspondent bien aux ports des conteneurs Je suis presque certain que cela n’est pas lié à cela, car tout fonctionnait parfaitement avant ; c’est juste après cette mise à niveau/reconstruction que le problème est survenu.

Entrer dans le conteneur, ouvrir les statistiques Top, puis accéder au site ne semble pas non plus faire de différence. Au cas où cela pourrait aider, voici une capture d’écran :

Si cela t’est plus facile, je serais ravi de ‘sauvegarder’ le conteneur et de te l’envoyer (est-ce même possible avec les conteneurs Docker ? haha !)

Sujet		Réponses	Vues
Installed OK. Working fine for one day. Suddenly stopped working Self-hosting	14	2665	Juin 20, 2018
Can't rebuild due to failed postgres 12 upgrade Self-hosting	44	3966	Juillet 13, 2020
Discourse upgrade via Web UI Fails & SSH Upgrade Brings Down Discourse Instance Self-hosting	17	1986	Novembre 26, 2021
Discourse web interface becomes unresponsive a few minutes after starting Self-hosting	35	6961	Janvier 9, 2018
Discourse Bad Gateway after reboot Self-hosting	16	2151	Août 1, 2020

Problème de pare-feu avec l'exécution de plusieurs conteneurs après la mise à niveau

Sujets connexes