In trying to understand launcher run, e.g.
groot@galaxy:/var/discourse$ sudo ./launcher run app whoami
If a site is up and running the above command would not enter that site and start bash to run the command whoami but start up a new container based on the last bootstrapped image and then run the command.
In other words if I wanted to use launcher to learn about a live site running in a container I should use launcher enter instead of launcher run.
Hi @EricGT
Yes, I think many Discourse system admins use:
./launcher enter <container_name>
… to enter the running container and the check on status (or perform tasks) in the running container.
However, keep in mind this you can do “as you seem to want to do” using docker directly (and easily). There is no need to use an intermediate shell script to get this information in a running container:
# docker exec -it app whoami
root
You may find this link useful on the syntax of the docker exec command.
Let’s try a few more examples for fun:
# docker exec -it app ps aux | grep nginx | wc -l
4
# docker exec -it app ps aux | grep redis | wc -l
2
# docker exec -it app df
Filesystem 1K-blocks Used Available Use% Mounted on
overlay 51043548 26426300 22005700 55% /
tmpfs 65536 0 65536 0% /dev
tmpfs 1017712 0 1017712 0% /sys/fs/cgroup
shm 524288 8 524280 1% /dev/shm
/dev/sda 51043548 26426300 22005700 55% /shared
tmpfs 1017712 0 1017712 0% /proc/acpi
tmpfs 1017712 0 1017712 0% /proc/scsi
tmpfs 1017712 0 1017712 0% /sys/firmware
failed to resize tty, using default size
# docker exec -it app du -sh /shared
403M /shared
# docker exec -it app du -sh /shared/uploads
2.0M /shared/uploads
# docker exec -it app ls -l /var/www/discourse/plugins/
total 36
drwxr-xr-x 1 discourse discourse 4096 Jun 7 04:49 discourse-details
drwxr-xr-x 1 discourse discourse 4096 Jun 7 04:49 discourse-local-dates
drwxr-xr-x 1 discourse discourse 4096 Jun 7 04:49 discourse-narrative-bot
drwxr-xr-x 1 discourse discourse 4096 Jun 7 04:49 discourse-presence
drwxr-xr-x 1 discourse discourse 4096 Jun 7 04:49 discourse-unsupported-browser
drwxr-xr-x 12 discourse root 4096 Jun 7 04:49 docker_manager
drwxr-xr-x 1 discourse discourse 4096 Jun 7 04:49 lazy-yt
drwxr-xr-x 11 discourse root 4096 Jun 7 04:49 neo-revive-discourse
drwxr-xr-x 1 discourse discourse 4096 Jun 7 04:49 poll
root@localhost:/var/discourse# docker exec -it app ls -l /shared
total 112
drwxr-xr-x 3 discourse www-data 4096 May 23 09:57 backups
drwxr-xr-x 10 root root 4096 Jun 7 04:55 letsencrypt
drwxr-xr-x 4 root root 4096 May 23 09:43 log
drwxr-xr-x 2 postgres postgres 4096 May 23 09:43 postgres_backup
drwx------ 19 postgres postgres 4096 Jun 7 04:57 postgres_data
drwxrwxr-x 3 postgres postgres 4096 Jun 7 04:57 postgres_run
drwxr-xr-x 2 redis redis 4096 Jun 8 02:56 redis_data
drwxr-xr-x 2 root root 4096 May 28 04:19 ssl
drwxr-xr-x 4 root root 4096 May 23 09:52 state
drwxrwxrwx 4 discourse www-data 4096 Jun 7 04:57 tmp
drwxr-xr-x 3 discourse www-data 4096 May 23 09:46 uploads
Hopefully, these fun examples give you some ideas on how to enjoy using docker exec to “learn about a live site running in a container”, as you asked about @EricGT
Here are a few more examples for fun:
# docker exec -it app ls -l /shared/tmp/redis.sock
srwxrwxrwx 1 redis redis 0 Jun 7 04:57 /shared/tmp/redis.sock
This one is not necessary because the unix socket is in the shared volume, but you get the idea:
#docker exec -it app redis-cli -s /shared/tmp/redis.sock monitor
OK
(truncated, tons of live, streaming data)
and finally, of course, our favorite “old maid” of sys admin commands:
root@localhost:~# docker exec -it app ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.0 6660 292 pts/0 Ss+ Jun07 0:00 /bin/bash /sb
root 627 0.0 0.0 2308 60 pts/0 S+ Jun07 0:01 /usr/bin/runs
root 628 0.0 0.0 2156 68 ? Ss Jun07 0:00 runsv cron
root 629 0.0 0.0 2156 64 ? Ss Jun07 0:00 runsv rsyslog
root 630 0.0 0.0 2156 68 ? Ss Jun07 0:00 runsv redis
root 631 0.0 0.0 2156 64 ? Ss Jun07 0:00 runsv postgre
root 632 0.0 0.0 2156 64 ? Ss Jun07 0:00 runsv nginx
root 633 0.0 0.0 2156 64 ? Ss Jun07 0:00 runsv unicorn
discour+ 634 0.0 0.1 15128 2484 ? S Jun07 0:35 /bin/bash con
root 635 0.0 0.1 55176 3956 ? S Jun07 0:00 nginx: master
postgres 636 0.0 1.2 351840 26132 ? S Jun07 0:04 /usr/lib/post
root 637 0.0 0.0 2300 60 ? S Jun07 0:00 svlogd /var/l
redis 638 0.3 0.3 56700 7880 ? Sl Jun07 4:01 /usr/bin/redi
root 639 0.0 0.0 156184 588 ? Sl Jun07 0:00 rsyslogd -n
root 640 0.0 0.0 8436 1216 ? S Jun07 0:00 cron -f
www-data 651 0.0 0.3 56628 6852 ? S Jun07 0:00 nginx: worker
www-data 652 0.0 0.0 55668 1676 ? S Jun07 0:00 nginx: cache
postgres 657 0.0 1.8 352116 36776 ? Ss Jun07 0:01 postgres: 10/
(truncated)
As you might see or imagine, docker exec is very useful and hopefully these examples spark your imagination a little bit, @EricGT
Here are a few more, useful docker exec commands for Discourse:
That was an awesome reply and am I very grateful for the reply which gave me some insight into how other Docker system admins think about what is important and quickly get a look at that info, however Docker commands are an old friend of mine and what I really just wanted was a simple yes or no answer to
Did I get this right.
launcher rundoes not use a current running container?
I spent a few hours the other day analyzing a bash trace of the launcher run command and was wanting to make sure my analysis was right. I would not have expected launcher run to start up an entirely new container just to run a single command like whoami. What is more scary is that if one thinks the command will work against the current running container and give them feedback about the container running the live site, instead it will be giving information back about a different container.
I fully agree that the way you are doing it with the Docker commands is the way I would be doing it, but I also would agree that unless you know the difference between $ and # that you shoud stay very far away from the Docker commands and put your trust in launcher.
Now that I know you like using questions with an auxiliary question as a pretext to shout-out about things the you find awesome, I will try and surreptitiously add them from time to time. 
Dear @EricGT
Yes, I use docker run as well (however, not launcher run) ; but I have not really found a reason to run docker run and append a shell command after the run command, because as mentioned in my reply, I always use docker exec.
Sorry you found my reply about why I use docker exec a “pretext to shout-out about things”. I assure you, I am really busy on many projects and don’t need pretexts to shout-out things and was only trying to help you accomplish your task because I don’t use launcher run to run shell commands in a Discourse container, I only use docker exec as mentioned in my reply; trying to help you.
Good luck with your future Discourse sys admin tasks!
Enjoy and stay curious!
The reason I am asking specifically about launch run is that I am creating an SOP manual for some other Discourse admins as we are exploring the possibility of self-hosting and I needed to understand each launcher command in detail to document it. Right now the SOP notes that using launcher run will create a new container so warns not to use launcher run.
I believe that you are right that ./launcher run cranks up a new container and runs the command there. If you want to run the command in the existing container you need to do it with docker as discussed.
If ./launcher didn’t behave this way then it couldn’t work if there wasn’t an existing container.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.