Nel tentativo di comprendere launcher run, ad esempio:
groot@galaxy:/var/discourse$ sudo ./launcher run app whoami
Se un sito è attivo e funzionante, il comando sopra non entra nel sito e avvia bash per eseguire il comando whoami, ma avvia un nuovo container basato sull’immagine bootstrappata più recente e poi esegue il comando.
In altre parole, se volessi utilizzare launcher per esplorare un sito live in esecuzione in un container, dovrei usare launcher enter invece di launcher run.
Sì, penso che molti amministratori di sistema Discourse utilizzino:
./launcher enter <container_name>
… per entrare nel container in esecuzione e controllare lo stato (o eseguire attività) all’interno del container attivo.
Tuttavia, tieni presente che puoi fare “come sembri voler fare” usando direttamente Docker (e in modo semplice). Non c’è bisogno di utilizzare uno script shell intermedio per ottenere queste informazioni in un container in esecuzione:
# docker exec -it app whoami
root
Potresti trovare utile questo link sulla sintassi 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
Speriamo che questi divertenti esempi ti diano qualche idea su come goderti l’uso di docker exec per “imparare a conoscere un sito live in esecuzione in un container”, come hai chiesto @EricGT
Ecco altri esempi per divertimento:
# docker exec -it app ls -l /shared/tmp/redis.sock
srwxrwxrwx 1 redis redis 0 Jun 7 04:57 /shared/tmp/redis.sock
Questo non è necessario perché il socket Unix si trova nel volume condiviso, ma hai capito l’idea:
#docker exec -it app redis-cli -s /shared/tmp/redis.sock monitor
OK
(troncato, tonnellate di dati live in streaming)
e infine, ovviamente, il nostro preferito “vecchio soldato” dei comandi di amministrazione di sistema:
Quella è stata una risposta fantastica e sono molto grato per il riscontro che mi ha dato un’idea di come altri amministratori di sistemi Docker valutino le priorità e di come accedere rapidamente a tali informazioni. Tuttavia, i comandi Docker sono un vecchio amico per me, e quello che volevo davvero era solo una semplice risposta sì o no alla seguente domanda:
Ho capito bene? launcher run non utilizza un container attualmente in esecuzione?
Qualche giorno fa ho dedicato alcune ore ad analizzare un tracciato bash del comando launcher run e volevo solo essere sicuro che la mia analisi fosse corretta. Non mi sarei aspettato che launcher run avviasse un intero nuovo container solo per eseguire un singolo comando come whoami. Ancora più preoccupante è che, se si pensa che il comando funzioni sul container attualmente in esecuzione fornendo feedback sul container che gestisce il sito live, in realtà restituirà informazioni relative a un container diverso.
Concordo pienamente sul fatto che il metodo che stai utilizzando con i comandi Docker sia quello che adotterei anch’io, ma sono anche d’accordo nel dire che, a meno che tu non conosca la differenza tra $ e #, è meglio tenersi alla larga dai comandi Docker e affidarsi a launcher.
Ora che so che ti piace usare domande con una domanda ausiliaria come pretesto per fare degli elogi alle cose che trovi fantastiche, cercherò di inserirle furtivamente ogni tanto.
Sì, uso anch’io docker run (tuttavia, non launcher run); ma non ho davvero trovato un motivo per eseguire docker run e aggiungere un comando shell dopo il comando run, poiché, come ho già menzionato nella mia risposta, uso sempre docker exec.
Mi dispiace che tu abbia considerato la mia spiegazione sul perché uso docker exec come un “pretesto per fare sfoggio di cose”. Ti assicuro che sono davvero impegnato in molti progetti e non ho bisogno di pretesti per fare sfoggio; stavo solo cercando di aiutarti tu a completare il tuo compito, dato che non uso launcher run per eseguire comandi shell in un contenitore Discourse, ma solo docker exec, come ho già specificato nella mia risposta, nel tentativo di esserti utile.
In bocca al lupo per le tue future attività di amministrazione di sistema su Discourse!
Il motivo per cui chiedo specificamente di launch run è che sto creando un manuale SOP per altri amministratori di Discourse, mentre stiamo esplorando la possibilità di un hosting autonomo, e avevo bisogno di comprendere ogni comando del launcher in dettaglio per documentarlo. Al momento, le note SOP indicano che l’uso di launcher run creerà un nuovo container, quindi avverte di non utilizzare launcher run.
Credo che tu abbia ragione: ./launcher run avvia un nuovo container ed esegue il comando al suo interno. Se desideri eseguire il comando nel container esistente, devi farlo tramite docker, come discusso.
Se ./launcher non si comportasse in questo modo, non potrebbe funzionare senza un container già esistente.
