Пытаясь понять, как работает launcher run, например:
groot@galaxy:/var/discourse$ sudo ./launcher run app whoami
Если сайт запущен и работает, указанная выше команда не войдёт в этот сайт и не запустит bash для выполнения команды whoami, а создаст новый контейнер на основе последнего образа, полученного при сборке, и выполнит команду в нём.
Другими словами, если вы хотите использовать launcher, чтобы изучить работающий в контейнере живой сайт, вам следует использовать launcher enter вместо launcher run.
Да, я думаю, что многие администраторы систем Discourse используют:
./launcher enter <container_name>
… чтобы войти в работающий контейнер и проверить его состояние (или выполнить задачи) внутри этого контейнера.
Однако имейте в виду, что вы можете сделать то, что, кажется, хотите сделать, используя Docker напрямую (и легко). Нет необходимости использовать промежуточный скрипт оболочки для получения этой информации в работающем контейнере:
# docker exec -it app whoami
root
Эта ссылка может быть вам полезна для изучения синтаксиса команды docker exec.
Давайте попробуем ещё несколько примеров для развлечения:
# 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
Надеюсь, эти забавные примеры дадут вам идеи о том, как использовать docker exec для «изучения живого сайта, работающего в контейнере», как вы спрашивали, @EricGT
Вот ещё несколько примеров для развлечения:
# docker exec -it app ls -l /shared/tmp/redis.sock
srwxrwxrwx 1 redis redis 0 Jun 7 04:57 /shared/tmp/redis.sock
Этот пример не обязателен, так как unix-сокет находится в общем томе, но вы уловили суть:
#docker exec -it app redis-cli -s /shared/tmp/redis.sock monitor
OK
(сокращено, тонны живых потоковых данных)
И наконец, конечно, наш любимый «старый знакомый» среди команд системного администратора:
Это был отличный ответ, и я очень благодарен за него — он дал мне представление о том, как другие администраторы Docker-систем определяют приоритеты и как быстро получить доступ к этой информации. Однако команды Docker — мои старые знакомые, и на самом деле я просто хотел получить простой ответ «да» или «нет» на вопрос:
Прав ли я? launcher run не использует уже запущенный контейнер?
Несколько дней назад я потратил несколько часов на анализ трассировки bash-команды launcher run и хотел убедиться, что мои выводы верны. Я бы не стал ожидать, что launcher run запустит совершенно новый контейнер только для выполнения одной команды, например whoami. Что ещё более страшно: если кто-то думает, что команда будет работать с текущим запущенным контейнером и предоставит обратную связь о контейнере, на котором работает живой сайт, то на самом деле она вернёт информацию о другом контейнере.
Я полностью согласен, что способ, который вы используете с командами Docker, — это именно то, как поступил бы и я. Но также согласен и с тем, что если вы не знаете разницы между $ и #, то вам лучше держаться подальше от команд Docker и довериться launcher.
Теперь, когда я знаю, что вам нравятся вопросы с дополнительным вопросом в качестве предлога, чтобы похвастаться тем, что вы находите впечатляющим, я тоже буду время от времени незаметно добавлять их.
Да, я тоже использую docker run (однако не launcher run); но у меня нет реальной причины запускать docker run и добавлять команду оболочки после команды run, потому что, как я уже упоминал в своём ответе, я всегда использую docker exec.
Извините, что вы восприняли мой ответ о том, почему я использую docker exec, как «предлог для того, чтобы высказаться о вещах». Я заверяю вас, что я действительно занят множеством проектов и мне не нужны предлоги, чтобы высказываться; я лишь пытался помочь вам выполнить вашу задачу, потому что я не использую launcher run для запуска команд оболочки в контейнере Discourse — я использую только docker exec, как указано в моём ответе, пытаясь помочь вам.
Удачи вам в будущих задачах системного администрирования Discourse!
Я спрашиваю конкретно о launch run, потому что я создаю руководство по стандартным операционным процедурам (SOP) для других администраторов Discourse, так как мы изучаем возможность самостоятельного хостинга, и мне нужно было подробно изучить каждую команду запуска для её документирования. В настоящее время в SOP указано, что использование launcher run создаст новый контейнер, поэтому предупреждается не использовать launcher run.
Я считаю, что вы правы: команда ./launcher run запускает новый контейнер и выполняет команду внутри него. Если же вы хотите выполнить команду в уже существующем контейнере, нужно использовать docker, как обсуждалось ранее.
Если бы ./launcher работал иначе, он не мог бы функционировать без уже существующего контейнера.
