launcher run을 이해하려다 보니, 예를 들어
groot@galaxy:/var/discourse$ sudo ./launcher run app whoami
이렇게 사용할 경우, 사이트가 이미 실행 중이라면 위 명령어는 해당 사이트에 진입하여 bash를 통해 whoami 명령을 실행하는 것이 아니라, 마지막으로 부트스트랩된 이미지를 기반으로 새로운 컨테이너를 시작하고 그 안에서 명령을 실행합니다.
즉, 컨테이너에서 실행 중인 라이브 사이트에 대해 launcher를 사용하여 정보를 얻고자 한다면 launcher run 대신 launcher enter를 사용해야 합니다.
@EricGT 님, 안녕하세요.
네, 많은 Discourse 시스템 관리자가 다음을 사용합니다:
./launcher enter <container_name>
… 실행 중인 컨테이너에 진입하여 상태를 확인하거나(또는 작업을 수행)하기 위해.
다만, “원하시는 것처럼” 직접 docker를 사용하여(그리고 쉽게) 이 정보를 얻을 수 있다는 점을 기억해 두세요. 실행 중인 컨테이너에서 이 정보를 얻기 위해 중간 셸 스크립트를 사용할 필요가 없습니다:
# docker exec -it app whoami
root
docker exec 명령어의 문법에 대해 다음 링크가 유용할 수 있습니다.
재미로 몇 가지 더 예시를 들어보겠습니다:
# 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
이러한 재미있는 예시들이 @EricGT 님이 질문하신 “컨테이너에서 실행 중인 라이브 사이트에 대해 배우는” 방법을 위해 docker exec를 즐겁게 사용하는 방법에 대한 몇 가지 아이디어를 제공해 주기를 바랍니다.
재미로 몇 가지 더 예시를 들어보겠습니다:
# docker exec -it app ls -l /shared/tmp/redis.sock
srwxrwxrwx 1 redis redis 0 Jun 7 04:57 /shared/tmp/redis.sock
유닉스 소켓이 공유 볼륨에 있으므로 이것은 필수적이지는 않지만, 아이디어를 파악하셨을 것입니다:
#docker exec -it app redis-cli -s /shared/tmp/redis.sock monitor
OK
(truncated, tons of live, streaming data)
마지막으로, 물론, 시스템 관리 명령어 중 우리의 가장 오래된 "고전"인 다음을 보여드립니다:
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)
보실 수 있거나 상상하실 수 있듯이, docker exec는 매우 유용하며, @EricGT 님의 상상력을 조금이라도 자극해 주기를 바랍니다.
Discourse를 위한 몇 가지 더 유용한 docker exec 명령어입니다:
정말 멋진 답변이었고, 다른 Docker 시스템 관리자들이 무엇을 중요하게 생각하는지, 그리고 그 정보를 어떻게 빠르게 파악하는지에 대한 통찰을 주신 점에 대해 진심으로 감사드립니다. 다만 Docker 명령어는 저에게 낯설지 않은 친구이고, 사실 제가 원했던 것은 다음 질문에 대한 단순한 ‘예’ 또는 ‘아니오’ 답변이었거든요.
제 이해가 맞는지 확인해 주세요.
launcher run은 현재 실행 중인 컨테이너를 사용하지 않나요?
며칠 전 launcher run 명령어의 bash 트레이스를 분석하는 데 몇 시간을 보냈고, 제 분석이 정확한지 확인하고 싶었습니다. whoami 같은 단일 명령어를 실행하기 위해 완전히 새로운 컨테이너를 시작하는 launcher run의 동작은 예상하지 못했거든요. 더 무서운 점은, 이 명령어가 현재 실행 중인 컨테이너(실제 사이트를 실행 중인 컨테이너)에 대해 작동한다고 생각하고 실행했을 때, 실제로는 다른 컨테이너에 대한 정보를 반환하게 된다는 것입니다.
Docker 명령어를 사용하는 방식에 대해서는 전적으로 동의하며, 제가 만약 같은 상황이라면 그렇게 했을 것입니다. 하지만 $와 #의 차이를 모른다면 Docker 명령어와는 최대한 거리를 두고 launcher를 신뢰하는 것이 좋다고도 생각합니다.
질문 뒤에 '이것은 정말 멋지다’라고 외치고 싶은 것을 사전에 붙여넣는 방식을 좋아하신다는 걸 이제 알았으니, 저도 가끔 몰래 그렇게 해보겠습니다. 
@EricGT 님, 안녕하세요.
저도 docker run를 사용하고 있습니다(다만 launcher run은 사용하지 않음). 하지만 제 답변에서 언급했듯이, 저는 항상 docker exec를 사용하므로 docker run 뒤에 셸 명령어를 붙여 실행할 이유는 크게 찾지 못했습니다.
제가 docker exec를 사용하는 이유에 대해 답변드린 것을 "이슈를 떠들어대기 위한 구실"이라고 생각하신 점에 대해 죄송합니다. 저는 여러 프로젝트로 정말 바쁘기 때문에 이슈를 떠들어대기 위한 구실이 필요 없으며, launcher run을 Discourse 컨테이너에서 셸 명령어를 실행하는 데 사용하지 않고 제 답변에서 언급했듯이 docker exec만 사용하고 있으므로, 그저 여러분이 여러분의 작업을 완수할 수 있도록 돕고자 했을 뿐입니다.
앞으로의 Discourse 시스템 관리 업무에 행운을 빕니다!
즐겁게 보내시며, 항상 호기심을 유지하세요!
launch run에 대해 구체적으로 질문하는 이유는, 자체 호스팅(self-hosting) 가능성을 검토하면서 다른 Discourse 관리자들을 위한 SOP 매뉴얼을 작성 중이기 때문입니다. 이를 위해 각 launcher 명령어를 자세히 이해하여 문서화해야 했습니다. 현재 SOP에는 launcher run을 사용하면 새 컨테이너가 생성되므로, launcher run을 사용하지 않도록 경고하는 내용이 포함되어 있습니다.
./launcher run이 새 컨테이너를 시작하고 그 안에서 명령을 실행한다는 의견에 동의합니다. 기존 컨테이너에서 명령을 실행하려면 위에서 논의한 대로 docker를 사용해야 합니다.
만약 ./launcher가 이렇게 동작하지 않는다면, 기존 컨테이너가 없는 경우 작동할 수 없었을 것입니다.