Informations de contexte : le site est lot.almost-dead.net, version 2.8.0.beta4, hébergé sur Google Cloud/Compute ; j’ai suivi le guide officiel basé sur Docker pour le configurer. (Je maîtrise les technologies front-end des navigateurs et comprends les grandes lignes de l’hébergement cloud, mais je suis familier avec AWS et non avec Google.)
Cause préliminaire : j’ai arrêté l’instance VM, puis je l’ai redémarrée (en essayant d’ajuster les variables d’environnement exposées à Discourse).
Lorsque la VM est revenue et que le site était de nouveau en ligne, j’ai remarqué que les ressources JavaScript expiraient, ainsi que certaines avatars d’utilisateurs. Dans le panneau d’administration, la section Santé de la communauté ne se charge pas ; le spinner continue de tourner, et dans Chrome Dev Tools, l’onglet Réseau montre que toutes les requêtes /message-bus/.../poll échouent. La page de mise à niveau (/admin/upgrade) échoue presque immédiatement et Chrome affiche le code ERR_FAILED. Lors de la navigation dans les sujets, je vois des requêtes POST échouer avec ERR_CONNECTION_REFUSED et des requêtes GET initiées par JavaScript échouer avec ERR_FAILED. (Ceci provient d’un navigateur disposant de cookies de connexion pour mon compte administrateur.)
Le chargement du site depuis une nouvelle instance de navigateur affiche l’erreur ERR_CONNECTION_REFUSED de Chrome.
Ce que j’ai essayé :
reconstruction côté serveur — sudo ./launcher rebuild app semble réussir, mais il n’y a aucun changement dans le comportement du site
j’ai aussi essayé de commenter les plugins et de reconstruire, toujours aucun changement
mode sans échec — la requête /safe-mode aboutit immédiatement à la page ERR_FAILED de Chrome
Non, votre site n’est pas de nouveau en ligne, il est complètement hors service. Vous voyez en partie un cache mis en mémoire. Pour quelqu’un qui n’a jamais visité votre site, il ne répond pas du tout. Cela provient probablement d’un problème au niveau du réseau ou du pare-feu, ou bien nginx ne démarre pas ou plante.
Une fois que j’exécute sudo ./launcher enter app, il semble que nginx soit en cours d’exécution…
root@adn-prod-app:/var/www/discourse# ps aux | grep nginx
root 548 0.0 0.0 2156 64 ? Ss 07:04 0:00 runsv nginx
root 558 0.0 0.1 55236 2524 ? S 07:04 0:00 nginx: master process /usr/sbin/nginx
www-data 567 0.0 0.2 55996 5068 ? S 07:04 0:00 nginx: worker process
www-data 568 0.0 0.0 55996 1628 ? S 07:04 0:00 nginx: worker process
www-data 569 0.0 0.0 55792 1680 ? S 07:04 0:00 nginx: cache manager process
root 23179 0.0 0.0 6140 884 pts/1 S+ 21:23 0:00 grep nginx
Je ne connais pas suffisamment Google Cloud pour savoir quoi chercher dans ses paramètres de réseau/pare-feu… Je note que l’instance de machine virtuelle possède les balises « http-server » et « https-server », et que son système de pare-feu semble utiliser ces balises pour appliquer les règles intégrées « default-allow-http » et « default-allow-https » aux instances comportant ces balises. Cela me semble correct, et nslookup indique que le sous-domaine que j’utilise est bien résolu vers l’adresse IP externe affichée dans l’interface utilisateur de Google, mais le monde extérieur ne peut toujours pas accéder à l’instance.
Dans /var/discourse/shared/standalone/log/rails/production.log, je vois des erreurs concernant la connexion à Redis ; existe-t-il un moyen de réparer cela ?
Job exception: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)
Job exception: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)
Job exception: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)
Job exception: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)
Job exception: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)
Job exception: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)
Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL) subscribe failed, reconnecting in 1 second. Call stack /var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.4.0/lib/redis/client.rb:384:in `rescue in establish_connection'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.4.0/lib/redis/client.rb:365:in `establish_connection'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.4.0/lib/redis/client.rb:117:in `block in connect'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.4.0/lib/redis/client.rb:330:in `with_reconnect'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.4.0/lib/redis/client.rb:116:in `connect'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.4.0/lib/redis/client.rb:403:in `ensure_connected'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.4.0/lib/redis/client.rb:255:in `block in process'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.4.0/lib/redis/client.rb:342:in `logging'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.4.0/lib/redis/client.rb:254:in `process'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.4.0/lib/redis/client.rb:148:in `call'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/rack-mini-profiler-2.3.3/lib/mini_profiler/profiling_methods.rb:85 :in `block in profile_method'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.4.0/lib/redis.rb:959:in `block in get'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.4.0/lib/redis.rb:70:in `block in synchronize'
/usr/local/lib/ruby/2.7.0/monitor.rb:202:in `synchronize'
/usr/local/lib/ruby/2.7.0/monitor.rb:202:in `mon_synchronize'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.4.0/lib/redis.rb:70:in `synchronize'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.4.0/lib/redis.rb:958:in `get'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/message_bus-3.3.6/lib/message_bus/backends/redis.rb:361:in `process_global_backlog'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/message_bus-3.3.6/lib/message_bus/backends/redis.rb:269:in `block in global_subscribe'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/message_bus-3.3.6/lib/message_bus/backends/redis.rb:282:in `global_subscribe'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/message_bus-3.3.6/lib/message_bus.rb:781:in `global_subscribe_thread'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/message_bus-3.3.6/lib/message_bus.rb:729:in `block in new_subscriber_thread'
Job exception: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)
Creating scope :open. Overwriting existing method Poll.open.
Bonjour,
c’est un peu tiré par les cheveux, mais la dernière fois que j’ai rencontré une erreur Redis, elle était en quelque sorte liée (ou du moins dans le même domaine que) aux certificats SSL (manquants ?).
Peut-être que ./launcher logs app pourrait aider ?
Il semble que mon problème venait du fait que la machine virtuelle est revenue avec une adresse IP différente, et que j’ai dû modifier mon enregistrement A pour qu’il pointe vers la nouvelle adresse.
Le site est de nouveau en ligne, merci de m’avoir écouté !
Il semble que mon problème venait du fait que la machine virtuelle est revenue avec une adresse IP différente, et que j’ai dû modifier mon enregistrement A pour qu’il pointe vers la nouvelle adresse.