groot@galaxy:/var/discourse$ sudo ./launcher run app whoami
Se um site estiver ativo e em execução, o comando acima não entrará nesse site e iniciará o bash para executar o comando whoami, mas sim iniciará um novo contêiner baseado na última imagem bootstrap e então executará o comando.
Em outras palavras, se eu quiser usar o launcher para aprender sobre um site em execução ao vivo em um contêiner, devo usar launcher enter em vez de launcher run.
Sim, acho que muitos administradores de sistema do Discourse usam:
./launcher enter <container_name>
… para entrar no container em execução e verificar o status (ou executar tarefas) dentro dele.
No entanto, lembre-se de que você pode fazer “como parece querer fazer” usando o Docker diretamente (e facilmente). Não há necessidade de usar um script intermediário para obter essas informações em um container em execução:
# docker exec -it app whoami
root
Você pode achar este link útil sobre a sintaxe do 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
Esperamos que esses exemplos divertidos lhe deem algumas ideias sobre como aproveitar o uso do docker exec para “aprender sobre um site ao vivo rodando em um container”, como você perguntou, @EricGT
Aqui estão mais alguns exemplos para diversão:
# docker exec -it app ls -l /shared/tmp/redis.sock
srwxrwxrwx 1 redis redis 0 Jun 7 04:57 /shared/tmp/redis.sock
Este não é necessário porque o socket Unix está no volume compartilhado, mas você entendeu a ideia:
#docker exec -it app redis-cli -s /shared/tmp/redis.sock monitor
OK
(truncated, tons of live, streaming data)
E finalmente, claro, nossa favorita “velha solteira” de comandos de administração de sistema:
Essa foi uma resposta incrível e sou muito grato por ela, pois me deu uma visão sobre como outros administradores de sistemas Docker pensam sobre o que é importante e como acessar essas informações rapidamente. No entanto, os comandos do Docker são velhos conhecidos meus, e o que eu realmente queria era apenas uma resposta simples de sim ou não para:
Estou certo? O launcher run não usa um contêiner em execução atual?
Gastei algumas horas no outro dia analisando um rastreamento bash do comando launcher run e queria ter certeza de que minha análise estava correta. Não esperaria que o launcher run iniciasse um contêiner totalmente novo apenas para executar um único comando como whoami. O que é mais assustador é que, se alguém achar que o comando funcionará no contêiner em execução atual e fornecerá feedback sobre o contêiner que está executando o site ao vivo, na verdade, estará retornando informações sobre um contêiner diferente.
Concordo plenamente que a maneira como você está fazendo isso com os comandos do Docker é como eu também faria, mas também concordo que, a menos que você conheça a diferença entre $ e #, deve se manter muito longe dos comandos do Docker e confiar no launcher.
Agora que sei que você gosta de usar perguntas com uma pergunta auxiliar como pretexto para destacar coisas que você acha incríveis, tentarei adicioná-las de forma sorrateira de vez em quando.
Sim, eu também uso docker run (no entanto, não launcher run); mas não encontrei realmente uma razão para executar docker run e adicionar um comando de shell após o comando run, pois, como mencionei em minha resposta, eu sempre uso docker exec.
Desculpe que você tenha considerado minha resposta sobre por que uso docker exec um “pretexto para falar sobre coisas”. Eu garanto a você, estou realmente ocupado com muitos projetos e não preciso de pretextos para falar sobre coisas; eu estava apenas tentando ajudar você a realizar sua tarefa, porque eu não uso launcher run para executar comandos de shell em um contêiner Discourse, uso apenas docker exec, conforme mencionado em minha resposta; tentando ajudá-lo.
Boa sorte com suas futuras tarefas de administração de sistema Discourse!
A razão pela qual estou perguntando especificamente sobre launch run é que estou criando um manual de POE (Procedimento Operacional Padrão) para outros administradores do Discourse, enquanto exploramos a possibilidade de auto-hospedagem, e precisei entender cada comando do launcher em detalhes para documentá-lo. No momento, as notas do POE indicam que usar launcher run criará um novo contêiner, então alerta para não usar launcher run.
Acredito que você esteja certo ao dizer que ./launcher run inicia um novo container e executa o comando nele. Se você quiser executar o comando no container existente, precisa fazê-lo com docker, conforme discutido.
Se ./launcher não se comportasse dessa maneira, não funcionaria se não houvesse um container existente.
