groot@galaxy:/var/discourse$ sudo ./launcher run app whoami
Si un sitio está activo y en ejecución, el comando anterior no ingresará a ese sitio ni iniciará bash para ejecutar el comando whoami, sino que iniciará un nuevo contenedor basado en la última imagen bootstrapada y luego ejecutará el comando.
En otras palabras, si quiero usar launcher para aprender sobre un sitio en vivo que se ejecuta en un contenedor, debería usar launcher enter en lugar de launcher run.
Sí, creo que muchos administradores de sistemas de Discourse usan:
./launcher enter <container_name>
… para entrar al contenedor en ejecución y verificar su estado (o realizar tareas) dentro del mismo.
Sin embargo, ten en cuenta que puedes hacer “lo que parece que quieres hacer” usando Docker directamente (y de forma sencilla). No es necesario usar un script intermedio de shell para obtener esta información en un contenedor en ejecución:
# docker exec -it app whoami
root
Puede que encuentres útil este enlace sobre la sintaxis del comando 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
Esperemos que estos ejemplos divertidos te den algunas ideas sobre cómo disfrutar usando docker exec para “aprender sobre un sitio en vivo que se ejecuta en un contenedor”, como preguntaste @EricGT
Aquí hay algunos ejemplos más por diversión:
# docker exec -it app ls -l /shared/tmp/redis.sock
srwxrwxrwx 1 redis redis 0 Jun 7 04:57 /shared/tmp/redis.sock
Este no es necesario porque el socket Unix está en el volumen compartido, pero entiendes la idea:
#docker exec -it app redis-cli -s /shared/tmp/redis.sock monitor
OK
(truncated, tons of live, streaming data)
Y finalmente, por supuesto, nuestra favorita “vieja soltera” de los comandos de administración de sistemas:
Esa fue una respuesta genial y estoy muy agradecido por ella, ya que me dio una idea de cómo piensan otros administradores de sistemas Docker sobre lo que es importante y cómo acceder rápidamente a esa información. Sin embargo, los comandos de Docker son un viejo amigo mío, y lo que realmente quería era una respuesta simple de sí o no a:
¿Lo entendí bien? launcher run no utiliza un contenedor en ejecución actual.
Pasé unas horas el otro día analizando un rastreo de bash del comando launcher run y quería asegurarme de que mi análisis era correcto. No habría esperado que launcher run iniciara un contenedor completamente nuevo solo para ejecutar un comando simple como whoami. Lo más preocupante es que, si uno piensa que el comando funcionará contra el contenedor en ejecución actual y le dará retroalimentación sobre el contenedor que ejecuta el sitio en vivo, en su lugar obtendrá información sobre un contenedor diferente.
Estoy totalmente de acuerdo en que la forma en que lo haces con los comandos de Docker es como yo lo haría, pero también coincido en que, a menos que conozcas la diferencia entre $ y #, deberías mantenerte muy lejos de los comandos de Docker y confiar en launcher.
Ahora que sé que te gusta usar preguntas con una pregunta auxiliar como pretexto para destacar cosas que te parecen geniales, intentaré añadirlas de vez en cuando de forma encubierta.
Sí, también utilizo docker run (sin embargo, no launcher run); pero no he encontrado realmente una razón para ejecutar docker run y añadir un comando de shell después del comando run, ya que, como mencioné en mi respuesta, siempre uso docker exec.
Lamento que hayas considerado mi explicación sobre por qué uso docker exec como un “pretexto para hacer menciones”. Te aseguro que estoy realmente ocupado con muchos proyectos y no necesito pretextos para hacer menciones; solo intentaba ayudarte a ti a completar tu tarea, ya que no uso launcher run para ejecutar comandos de shell en un contenedor de Discourse, sino que solo uso docker exec, como mencioné en mi respuesta; intentando ayudarte.
¡Buena suerte con tus futuras tareas de administración de sistemas en Discourse!
La razón por la que pregunto específicamente sobre launch run es que estoy creando un manual de procedimientos operativos estándar (SOP) para otros administradores de Discourse, ya que estamos explorando la posibilidad de autoalojarlo y necesitaba entender cada comando del lanzador en detalle para documentarlo. En este momento, el SOP indica que usar launcher run creará un nuevo contenedor, por lo que advierte no usar launcher run.
Creo que tienes razón en que ./launcher run inicia un nuevo contenedor y ejecuta el comando allí. Si quieres ejecutar el comando en el contenedor existente, debes hacerlo con docker, como se discutió.
Si ./launcher no se comportara de esta manera, no podría funcionar si no hubiera un contenedor existente.
