Did I get this right. `launcher run` does not use a current running container?

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.

1 Like

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:

5 Likes

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 run does 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. :grinning:

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!

2 Likes

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.

5 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.