Le lancement via le launcher fonctionne différemment de la commande "enter and run"

Soutien Installation
1

Entering app context and running my command works as expected.

/var/discourse# ./launcher enter app
/var/www/discourse# discourse disable_restore
Restore are now forbidden. Enable them with `enable_restore`

I expected the ./launcher run app "discourse disable_restore" to be the same thing, implicitly changing to the docker context, but it fails with an weird redis connection refused.

/var/discourse# ./launcher run app "discourse disable_restore"
Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 2 Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) subscribe failed, reconnecting in 1 second. 
Call stack ["/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/redis-4.0.1/lib/redis/client.rb:344:in `rescue in establish_connection'", "/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/redis-4.0.1/lib/redis/client.rb:328:in `establish_connection'", "/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/redis-4.0.1/lib/redis/client.rb:99:in `block in connect'", "/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/redis-4.0.1/lib/redis/client.rb:291:in `with_reconnect'", "/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/redis-4.0.1/lib/redis/client.rb:98:in `connect'", "/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/redis-4.0.1/lib/redis/client.rb:274:in `with_socket_timeout'", "/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/redis-4.0.1/lib/redis/client.rb:131:in `call_loop'", "/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/redis-4.0.1/lib/redis/subscribe.rb:43:in `subscription'", "/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/redis-4.0.1/lib/redis/subscribe.rb:12:in `subscribe'", "/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/redis-4.0.1/lib/redis.rb:2824:in `_subscription'", "/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/redis-4.0.1/lib/redis.rb:2192:in `block in subscribe'", "/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/redis-4.0.1/lib/redis.rb:45:in `block in synchronize'", "/usr/local/lib/ruby/2.5.0/monitor.rb:226:in `mon_synchronize'", "/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/redis-4.0.1/lib/redis.rb:45:in `synchronize'", "/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/redis-4.0.1/lib/redis.rb:2191:in `subscribe'", "/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/message_bus-2.1.6/lib/message_bus/backends/redis.rb:337:in `global_subscribe'", "/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/message_bus-2.1.6/lib/message_bus.rb:533:in `global_subscribe_thread'", "/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/message_bus-2.1.6/lib/message_bus.rb:481:in `block in new_subscriber_thread'"] 
bundler: failed to load command: script/discourse (script/discourse)
Redis::CannotConnectError: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED)

Is it expected behaviour?

I’m running from master (discourse 42aefc3 and discourse_docker 3377f26).

2 « J'aime »
2

It worked for me just now.

root@lh:/var/discourse#` ./launcher run web_only "discourse disable_restore"`
Restore are now forbidden. Enable them with `enable_restore`
root@lh:/var/discourse# ./launcher run web_only "discourse enable_restore"
Restore are now permitted. Disable them with `disable_restore`

But maybe there’s something different in a web-only vs single-container solution. You might try

 ./launcher run app  "su discourse discourse disable_restore"
3

Tried your solution but does not work. :frowning:

/var/discourse# ./launcher run app "su discourse discourse disable_restore" discourse is not in the sudoers file. This incident will be reported.

1 « J'aime »
4

Hmm. Well, I’ll try on a single container install today if I get a chance.

1 « J'aime »
5

I solved my issue with another @pfaffman answer: Running commands inside discourse container?

docker exec -w /var/www/discourse -i app discourse enable_restore

Works for me, but I expected ./launcher run app "command" to be the way to do it.

Thanks!

2 « J'aime »
6

Glad my answer worked! The ./launcher run command is pretty new, but I’d expect it to work too.

3 « J'aime »
7

Salut à tous !

J’ai rencontré le même problème. Je souhaite exécuter ./launcher pour activer la restauration. Quelle est la bonne méthode pour le faire ?

Donc, au lieu de :

vagrant ssh -c 'cd /vagrant;sudo ./launcher run discourse discourse enable_restore'

cela fonctionne pour moi (comme indiqué ci-dessus) :

vagrant ssh -c 'sudo docker exec -w /var/www/discourse -i discourse discourse enable_restore'

mais j’attendais quelque chose de plus simple. Je ne veux tout simplement pas plonger dans les détails techniques et rester « en sécurité » en utilisant les commandes standard. Je pensais que c’était le rôle de launcher.

8

Je suis ravi que vous l’ayez mentionné.

Je sais que le message date de 2018, mais ce n’était probablement pas une commande simple à mettre au point compte tenu du public visé.

J’ai passé les derniers jours à décomposer le script du lanceur morceau par morceau, et je suis maintenant sur la commande run. Lorsque je travaille sur les commandes du lanceur, j’essaie également de reproduire les mêmes étapes en utilisant les commandes Docker utilisées.

Pour run, je savais qu’il existait deux commandes Docker qui utilisent run :

docker container run
docker run

mais n’étant pas un expert de Docker, je ne peux pas expliquer à mon canard en caoutchouc quelles sont les différences ou s’il n’y en a pas.

Alors, lorsque j’ai essayé un simple ls, cela a pris tellement de temps que j’ai failli faire une pause pour prendre une boisson. Cela a bien renvoyé un résultat ls correct, c’est donc à ce moment-là que j’ai examiné exactement ce que faisait launcher run.

Quand j’ai vu cela :

  (exec $docker_path run --rm --shm-size=512m $user_args $links "${env[@]}" -e DOCKER_HOST_IP="$docker_ip" -i -a stdin -a stdout -a stderr $volumes $run_image \
    /bin/bash -c "$run_command") || ERR=$?

Je n’ai pas pu y croire. Je n’ai pas demandé pourquoi c’était ainsi, car parfois la réponse se trouve dans un message si vous cherchez, mais aussi, si je ne trouve pas la réponse, je serai beaucoup mieux informé.

** ÉDIT **

Message connexe : Essayer de comprendre le lanceur comme une série de commandes Docker

Résultat de l’exécution de launcher run app ls comme indiqué dans le message connexe, c’est-à-dire :

groot@galaxy:/var/discourse$ sudo bash -x launcher run app ls 2> ~/traces/ls_01
eric@swi-prolog:/var/discourse$ grep /usr/bin/docker ~/traces/ls_01

Sortie :

+ docker_path=/usr/bin/docker
+ '[' -z /usr/bin/docker ']'
++ /usr/bin/docker info
+ /usr/bin/docker info
++ /usr/bin/docker --version
++ /usr/bin/docker images
++ /usr/bin/docker run -i --rm -a stdout -a stderr discourse/base:2.0.20200512-1735 echo working
++ /usr/bin/docker info --format '{{.DockerRootDir}}'
+ '[' -z /usr/bin/docker ']'
++ /usr/bin/docker --version
+++ /usr/bin/docker run --rm -i -a stdin -a stdout discourse/base:2.0.20200512-1735 ruby -e 'require '\''yaml'\''; puts YAML.load(STDIN.readlines.join)['\''templates'\'']'
++++ /usr/bin/docker run --rm -i -a stdin -a stdout discourse/base:2.0.20200512-1735 ruby -e 'require '\''yaml'\''; puts YAML.load(STDIN.readlines.join)['\''templates'\'']'
++ /usr/bin/docker run --rm -i -a stdin -a stdout discourse/base:2.0.20200512-1735 ruby -e 'require '\''yaml'\''
++ /usr/bin/docker run --rm -i -a stdin -a stdout discourse/base:2.0.20200512-1735 ruby -e 'require '\''yaml'\''
++ /usr/bin/docker run --rm -i -a stdin -a stdout discourse/base:2.0.20200512-1735 ruby -e 'require '\''yaml'\''
++ /usr/bin/docker run --rm -i -a stdout -a stdin discourse/base:2.0.20200512-1735 ruby -e 'require '\''yaml'\''; puts YAML.load(STDIN.readlines.join)['\''docker_args'\'']'
++ /usr/bin/docker run --rm -i -a stdout -a stdin discourse/base:2.0.20200512-1735 ruby -e 'require '\''yaml'\''; puts YAML.load(STDIN.readlines.join)['\''volumes'\''].map{|v| '\''-v '\'' << v['\''volume'\'']['\''host'\''] << '\'':'\'' << v['\''volume'\'']['\''guest'\''] << '\'' '\''}.join'
++ /usr/bin/docker run --rm -i -a stdout -a stdin discourse/base:2.0.20200512-1735 ruby -e 'require '\''yaml'\''; puts YAML.load(STDIN.readlines.join)['\''links'\''].map{|l| '\''--link '\'' << l['\''link'\'']['\''name'\''] << '\'':'\'' << l['\''link'\'']['\''alias'\''] << '\'' '\''}.join'
++ /usr/bin/docker run --rm -i -a stdin -a stdout discourse/base:2.0.20200512-1735 ruby -e 'require '\''yaml'\''; puts YAML.load(STDIN.readlines.join)['\''run_image'\'']'
+ exec /usr/bin/docker run --rm --shm-size=512m -e LANG=en_US.UTF-8 -e RAILS_ENV=production -e UNICORN_WORKERS=4 -e UNICORN_SIDEKIQS=1 -e RUBY_GLOBAL_METHOD_CACHE_SIZE=131072 -e RUBY_GC_HEAP_GROWTH_MAX_SLOTS=40000 -e RUBY_GC_HEAP_INIT_SLOTS=400000 -e RUBY_GC_HEAP_OLDOBJECT_LIMIT_FACTOR=1.5 -e DISCOURSE_DB_SOCKET=/var/run/postgresql -e DISCOURSE_DB_HOST= -e DISCOURSE_DB_PORT= -e LETSENCRYPT_DIR=/shared/letsencrypt -e DISCOURSE_HOSTNAME=discourse.galaxy.org -e DISCOURSE_DEVELOPER_EMAILS=groot@galaxy.org -e DISCOURSE_SMTP_ADDRESS=smtp.mailgun.org -e DISCOURSE_SMTP_PORT=587 -e DISCOURSE_SMTP_USER_NAME=groot@mg.galaxy.org -e DISCOURSE_SMTP_PASSWORD= I_am_Groot -e LETSENCRYPT_ACCOUNT_EMAIL=groot@galaxy.org -e DOCKER_HOST_IP=NNN.MMM.OOO.PPP -i -a stdin -a stdout -a stderr -v /var/discourse/shared/standalone:/shared -v /var/discourse/shared/standalone/log/var-log:/var/log local_discourse/app /bin/bash -c ls