Échec du déploiement - exec_command.rb:117:in `spawn

Installation
1

Salut tout le monde.
Avant de polluer ici avec de longs logs, je les ai collés ci-dessous.
Le déploiement échoue à chaque fois de cette manière. Quelqu’un peut-il partager une suggestion sur ce qui pose problème et comment le résoudre ? Je l’apprécierais beaucoup.
…

I, [2023-06-20T14:08:40.997134 #1]  INFO -- : > cd /var/www/discourse & su discourse -c 'LOAD_PLUGINS=0 bundle exec rake plugin:pull_compatible_all'
I, [2023-06-20T14:08:43.104608 #1]  INFO -- : docker_manager est déjà à la dernière version compatible

I, [2023-06-20T14:08:43.104825 #1]  INFO -- : > cd /var/www/discourse & su discourse -c 'bundle exec rake db:migrate'
rake aborted!
Redis::CommandError: READONLY You can't write against a read only replica. script: bcec1d9b3bbcfb089dc0b7316771be9f011872b6, on @user_script:8.
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/redis-4.8.1/lib/redis/client.rb:162:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/rack-mini-profiler-3.1.0/lib/mini_profiler/profiling_methods.rb:85:in `block in profile_method'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/redis-4.8.1/lib/redis.rb:270:in `block in send_command'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/redis-4.8.1/lib/redis.rb:269:in `synchronize'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/redis-4.8.1/lib/redis.rb:269:in `send_command'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/redis-4.8.1/lib/redis/commands/scripting.rb:110:in `_eval'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/redis-4.8.1/lib/redis/commands/scripting.rb:97:in `evalsha'
/var/www/discourse/lib/discourse_redis.rb:273:in `eval'
/var/www/discourse/lib/distributed_mutex.rb:82:in `get_lock'
/var/www/discourse/lib/distributed_mutex.rb:50:in `block in synchronize'
/var/www/discourse/lib/distributed_mutex.rb:49:in `synchronize'
/var/www/discourse/lib/distributed_mutex.rb:49:in `synchronize'
/var/www/discourse/lib/distributed_mutex.rb:34:in `synchronize'
/var/www/discourse/lib/tasks/db.rake:221:in `block in <main>'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/rake-13.0.6/exe/rake:27:in `<top (required)>'
/usr/local/bin/bundle:25:in `load'
/usr/local/bin/bundle:25:in `<main>'
Tasks: TOP => db:migrate
(See full trace by running task with --trace)
I, [2023-06-20T14:08:45.555646 #1]  INFO -- : 

FAILED
--------------------
Pups::ExecError: cd /var/www/discourse & su discourse -c 'bundle exec rake db:migrate' failed with return #<Process::Status: pid 687 exit 1>
Location of failure: /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/exec_command.rb:117:in `spawn'
exec failed with the params {"cd"=>"$home", "hook"=>"db_migrate", "cmd"=>["su discourse -c 'bundle exec rake db:migrate'"]}
bootstrap failed with exit code 1
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
./discourse-doctor may help diagnose the problem.
1 « J'aime »
2

Auhh.. c’est Redis - être un novice a pris du temps - n’est-ce pas ?
Mais si oui, alors comment déployer d’une manière telle que l’on y penserait, on l’appellerait « réplique en attente » ? - oui, c’est bien d’une instance Discourse dont je parle.

3

S’agit-il d’une installation standard, d’une installation de développement ou autre chose ? Avez-vous créé votre propre redis ? Pour une installation standard, redis doit être dans le conteneur et fonctionner sans problème.

1 « J'aime »
4

Salut.
Je n’ai pas mentionné - j’ai présumé et je présume toujours - que ce que j’essaie n’est pas inhabituel - que Redis et pgSQL sont tous deux externes au conteneur Discourse.
Est-il possible de déployer Discourse de manière plus ou moins standard comme « standby » - de la même manière ou d’une manière similaire à Redis - afin qu’une telle instantiation/déploiement de conteneur ne échoue pas ?

1 « J'aime »
5

Oui, mais vous devrez déboguer votre serveur redis par vous-même.

L’erreur est

Vous ne pouvez pas écrire sur une réplique en lecture seule

Il semble que vous ayez créé une réplique et que vous deviez écrire sur la principale. Si vous essayez de basculer, vous devrez trouver comment faire passer la réplique à l’état actif et arrêter d’être une réplique.

Vous devrez obtenir cette aide ailleurs.

6

Oui. Mais le basculement n’est pas le problème que j’ai ici, pas encore.
Ici, j’essaie d’instancier un tel conteneur Discourse « en veille/secondaire » sur un nœud/système différent et séparé, où Redis et pgSQL sont tous deux des répliques en lecture seule - comment faire cela ?

L’erreur s’explique d’elle-même et la question évidente est - pour moi, car c’est ma toute première incursion dans Discourse - comment déployer et exécuter un tel conteneur « hot-standby », si cela est possible.

7

Vous devrez configurer Discourse pour utiliser le primaire. En cas d’échec, vous utiliserez DNS ou HAProxy pour basculer vers le secondaire.

Ce n’est pas un problème de Discourse. Si vous souhaitez apprendre à gérer Redis et PostgreSQL dans une configuration haute disponibilité, vous devrez chercher ailleurs.