Pour essayer de comprendre launcher run, par exemple :
groot@galaxy:/var/discourse$ sudo ./launcher run app whoami
Si un site est actif et en cours d’exécution, la commande ci-dessus n’entrera pas dans ce site pour lancer bash et exécuter la commande whoami, mais lancera un nouveau conteneur basé sur la dernière image amorcée, puis exécutera la commande.
Autrement dit, si je souhaitais utiliser launcher pour explorer un site en direct s’exécutant dans un conteneur, je devrais utiliser launcher enter plutôt que launcher run.
Oui, je pense que de nombreux administrateurs système de Discourse utilisent :
./launcher enter <container_name>
… pour entrer dans le conteneur en cours d’exécution et vérifier son état (ou effectuer des tâches) à l’intérieur de ce conteneur.
Cependant, gardez à l’esprit que vous pouvez faire ce que vous semblez vouloir faire directement avec Docker (et facilement). Il n’est pas nécessaire d’utiliser un script intermédiaire pour obtenir ces informations dans un conteneur en cours d’exécution :
# docker exec -it app whoami
root
Vous pourriez trouver ce lien utile concernant la syntaxe de la commande docker exec :
Essayons quelques autres exemples pour le plaisir :
# 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
J’espère que ces exemples amusants vous donnent des idées sur la façon d’utiliser docker exec pour « apprendre à connaître un site en direct exécuté dans un conteneur », comme vous l’avez demandé @EricGT
Voici encore quelques exemples pour le plaisir :
# docker exec -it app ls -l /shared/tmp/redis.sock
srwxrwxrwx 1 redis redis 0 Jun 7 04:57 /shared/tmp/redis.sock
Celui-ci n’est pas nécessaire car le socket Unix se trouve dans le volume partagé, mais vous avez compris l’idée :
#docker exec -it app redis-cli -s /shared/tmp/redis.sock monitor
OK
(tronqué, énormément de données en direct et en flux)
et enfin, bien sûr, notre « vieille fille » préférée parmi les commandes d’administration système :
C’était une réponse géniale, et je vous en suis très reconnaissant. Elle m’a donné un aperçu de la façon dont les autres administrateurs système Docker perçoivent les priorités et accèdent rapidement à ces informations. Cependant, les commandes Docker sont de vieilles connaissances pour moi. Ce que je recherchais vraiment, c’était simplement une réponse par oui ou par non à la question suivante :
Ai-je bien compris ? launcher run n’utilise pas un conteneur actuellement en cours d’exécution ?
J’ai passé quelques heures l’autre jour à analyser une trace bash de la commande launcher run et je voulais m’assurer que mon analyse était correcte. Je ne m’attendrais pas à ce que launcher run lance un tout nouveau conteneur juste pour exécuter une commande unique comme whoami. Ce qui est encore plus inquiétant, c’est que si l’on pense que la commande s’exécutera sur le conteneur en cours d’exécution et fournira des informations sur le conteneur qui héberge le site en direct, elle renverra en réalité des informations sur un autre conteneur.
Je suis tout à fait d’accord avec vous : la méthode que vous utilisez avec les commandes Docker est celle que j’adopterais moi-même. Toutefois, je reconnais aussi que, sauf si vous connaissez la différence entre $ et #, il vaut mieux rester très loin des commandes Docker et faire confiance à launcher.
Maintenant que je sais que vous aimez poser des questions contenant une question auxiliaire comme prétexte pour souligner des éléments que vous trouvez géniaux, je vais essayer d’en glisser subrepticement de temps en temps.
Oui, j’utilise aussi docker run (cependant, pas launcher run) ; mais je n’ai pas vraiment trouvé de raison d’exécuter docker run et d’ajouter une commande shell après la commande run, car comme mentionné dans ma réponse, j’utilise toujours docker exec.
Désolé que vous ayez considéré ma réponse expliquant pourquoi j’utilise docker exec comme un « prétexte pour faire des annonces ». Je vous assure que je suis réellement occupé par de nombreux projets et que je n’ai pas besoin de prétextes pour faire des annonces ; je tentais simplement de vous aider vous à accomplir votre tâche, car je n’utilise pas launcher run pour exécuter des commandes shell dans un conteneur Discourse, mais uniquement docker exec comme indiqué dans ma réponse, dans le but de vous aider.
Bon courage pour vos futures tâches d’administration système avec Discourse !
La raison pour laquelle je pose spécifiquement la question concernant launcher run est que je suis en train de créer un manuel de procédure opérationnelle standardisée (SOP) à l’intention d’autres administrateurs Discourse, alors que nous explorons la possibilité de l’hébergement autonome. J’avais besoin de comprendre chaque commande du lanceur en détail pour la documenter. Actuellement, la SOP indique que l’utilisation de launcher run crée un nouveau conteneur, et elle met donc en garde contre son emploi.
Je pense que vous avez raison : ./launcher run lance un nouveau conteneur et exécute la commande dedans. Si vous voulez exécuter la commande dans le conteneur existant, vous devez le faire avec docker, comme discuté.
Si ./launcher ne se comportait pas ainsi, il ne pourrait pas fonctionner s’il n’y avait pas de conteneur existant.
