في محاولة لفهم أمر launcher run، على سبيل المثال:
groot@galaxy:/var/discourse$ sudo ./launcher run app whoami
إذا كان الموقع قيد التشغيل، فإن الأمر أعلاه لن يدخل إلى الموقع ويبدأ bash لتنفيذ أمر whoami، بل سيقوم بتشغيل حاوية جديدة مبنية على آخر صورة تم إعدادها (bootstrapped) ثم تنفيذ الأمر.
بمعنى آخر، إذا أردت استخدام launcher للتعرف على موقع حي يعمل داخل حاوية، فيجب أن تستخدم launcher enter بدلاً من launcher run.
مرحبًا @EricGT
نعم، أعتقد أن العديد من مسؤولي أنظمة Discourse يستخدمون:
./launcher enter <container_name>
… للدخول إلى الحاوية النشطة والتحقق من حالتها (أو تنفيذ مهام) داخلها.
ومع ذلك، تذكر أنه يمكنك فعل “ما يبدو أنك ترغب في فعله” مباشرة باستخدام Docker (وبسهولة). لا توجد حاجة لاستخدام سكريبت وسيط للحصول على هذه المعلومات داخل حاوية نشطة:
# docker exec -it app whoami
root
قد تجد هذه الرابطة مفيدة فيما يتعلق ببنية أمر docker exec:
دعنا نجرب بعض الأمثلة الإضافية للمتعة:
# docker exec -it app ps aux | grep nginx | wc -l
4
# docker exec -it app ps aux | grep redis | wc -l
2
# docker exec -it app df
Filesystem 1K-blocks Used Available Use% Mounted on
overlay 51043548 26426300 22005700 55% /
tmpfs 65536 0 65536 0% /dev
tmpfs 1017712 0 1017712 0% /sys/fs/cgroup
shm 524288 8 524280 1% /dev/shm
/dev/sda 51043548 26426300 22005700 55% /shared
tmpfs 1017712 0 1017712 0% /proc/acpi
tmpfs 1017712 0 1017712 0% /proc/scsi
tmpfs 1017712 0 1017712 0% /sys/firmware
failed to resize tty, using default size
# docker exec -it app du -sh /shared
403M /shared
# 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
(مختصر، كم هائل من البيانات المباشرة والمتدفقة)
وأخيرًا، بالطبع، الأمر المفضل لدينا “القديم الثابت” بين أوامر الإدارة النظام:
root@localhost:~# docker exec -it app ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.0 6660 292 pts/0 Ss+ Jun07 0:00 /bin/bash /sb
root 627 0.0 0.0 2308 60 pts/0 S+ Jun07 0:01 /usr/bin/runs
root 628 0.0 0.0 2156 68 ? Ss Jun07 0:00 runsv cron
root 629 0.0 0.0 2156 64 ? Ss Jun07 0:00 runsv rsyslog
root 630 0.0 0.0 2156 68 ? Ss Jun07 0:00 runsv redis
root 631 0.0 0.0 2156 64 ? Ss Jun07 0:00 runsv postgre
root 632 0.0 0.0 2156 64 ? Ss Jun07 0:00 runsv nginx
root 633 0.0 0.0 2156 64 ? Ss Jun07 0:00 runsv unicorn
discour+ 634 0.0 0.1 15128 2484 ? S Jun07 0:35 /bin/bash con
root 635 0.0 0.1 55176 3956 ? S Jun07 0:00 nginx: master
postgres 636 0.0 1.2 351840 26132 ? S Jun07 0:04 /usr/lib/post
root 637 0.0 0.0 2300 60 ? S Jun07 0:00 svlogd /var/l
redis 638 0.3 0.3 56700 7880 ? Sl Jun07 4:01 /usr/bin/redi
root 639 0.0 0.0 156184 588 ? Sl Jun07 0:00 rsyslogd -n
root 640 0.0 0.0 8436 1216 ? S Jun07 0:00 cron -f
www-data 651 0.0 0.3 56628 6852 ? S Jun07 0:00 nginx: worker
www-data 652 0.0 0.0 55668 1676 ? S Jun07 0:00 nginx: cache
postgres 657 0.0 1.8 352116 36776 ? Ss Jun07 0:01 postgres: 10/
(مختصر)
كما ترون أو تتخيل، فإن docker exec أداة مفيدة جدًا، ونأمل أن تثير هذه الأمثلة خيالك قليلاً، @EricGT
إليك بعض أوامر docker exec المفيدة الإضافية لـ Discourse:
كانت تلك إجابة رائعة، وأنا ممتن جدًا لها لأنها منحتني نظرة ثاقفة حول كيفية تفكير مسؤولي أنظمة Docker الآخرين فيما هو مهم، وكيفية الحصول على معلومات ذلك بسرعة. ومع ذلك، فإن أوامر Docker هي صديق قديم لي، وما أردته حقًا كان مجرد إجابة بنعم أو لا على
هل فهمت هذا بشكل صحيح؟ هل لا يستخدم
launcher runحاوية قيد التشغيل حاليًا؟
قضيت بضع ساعات في يوم آخر في تحليل أثر bash لأمر launcher run وكنت أرغب في التأكد من صحة تحليلي. لم أتوقع أبدًا أن يبدأ launcher run حاوية جديدة تمامًا فقط لتشغيل أمر واحد مثل whoami. والأكثر رعبًا هو أنه إذا اعتقد شخص ما أن الأمر سيعمل ضد الحاوية قيد التشغيل حاليًا ويعطيه ملاحظات حول الحاوية التي تشغل الموقع المباشر، فبدلاً من ذلك سيعيد معلومات حول حاوية مختلفة.
أتفق تمامًا مع أن الطريقة التي تستخدمها مع أوامر Docker هي الطريقة التي كنت سأفعلها بها، لكنني أتفق أيضًا أنه ما لم تكن تعرف الفرق بين $ و #، فيجب أن تبتعد جدًا عن أوامر Docker وتضع ثقتك في launcher.
الآن بعد أن عرفت أنك تحب استخدام الأسئلة مع سؤال مساعد كذريعة للإشادة بالأشياء التي تجدها رائعة، سأحاول إضافة هذه الأسئلة سرًا بين الحين والآخر. 
عزيزي @EricGT
نعم، أنا أستخدم docker run أيضًا (ومع ذلك، لا أستخدم launcher run)؛ لكنني لم أجد سببًا حقيقيًا لتشغيل docker run وإضافة أمر shell بعد أمر run، لأنه كما ورد في ردي، أنا دائمًا أستخدم docker exec.
آسف لأنك وجدت ردي حول سبب استخدامي لـ docker exec مجرد “ذريعة للتحدث عن أشياء”. أؤكد لك أنني مشغول حقًا بالعديد من المشاريع ولا أحتاج إلى ذرائع للتحدث عن أشياء، وكنت أحاول فقط مساعدتك أنت في إنجاز مهمتك لأنني لا أستخدم launcher run لتشغيل أوامر shell في حاوية Discourse، بل أستخدم docker exec فقط كما ورد في ردي؛ محاولًا مساعدتك.
حظًا موفقًا في مهام إدارة أنظمة Discourse المستقبلية!
استمتع وابقَ فضوليًا!
السبب في أنني أسأل تحديدًا عن launcher run هو أنني أقوم بإنشاء دليل إجراءات قياسية (SOP) لبعض مسؤولي Discourse الآخرين بينما نستكشف إمكانية الاستضافة الذاتية، وقد احتجت إلى فهم كل أمر من أوامر launcher بالتفصيل لتوثيقه. حاليًا، تذكر ملاحظات الإجراءات القياسية أن استخدام launcher run سيؤدي إلى إنشاء حاوية جديدة، لذا تحذر من استخدام launcher run.
أعتقد أنك محق في أن ./launcher run يقوم بتشغيل حاوية جديدة وتنفيذ الأمر فيها. إذا كنت تريد تنفيذ الأمر في الحاوية الحالية، فيجب عليك القيام بذلك باستخدام docker كما تمت مناقشته.
لو لم يكن ./launcher يتصرف بهذه الطريقة، لما كان بإمكانه العمل في حال عدم وجود حاوية موجودة مسبقًا.