دعم التشغيل على Apple M1

مرحباً، أنا أستخدم M1 لتطوير الأتمتة والأدوات لتشغيل Discourse. لدى البرنامج النصي discourse-setup مشكلة في التعرف على وحدات المعالجة المركزية المستندة إلى ARM وتفشل مع الخطأ التالي. أدى هذا إلى عدم بدء الحاوية. في حالتي، سأستخدم نهج الحاوية المزدوجة (الويب + البيانات)، لذا فإن حاوية الويب هي التي تفشل في البدء.

./discourse-setup: line 261: *0: syntax error: operand expected (error token is "*0")

من الواضح أن هذا يرجع إلى أن البرنامج النصي يدعم فقط مخرجات /proc/cpuinfo المستندة إلى Intel، ومعالجات ARM مختلفة. يمكن رؤية مثال على /proc/cpuinfo داخل الحاويات يبلغ عن بيانات لا معنى لها على Apple M1 Max · Issue #6111 · docker/for-mac · GitHub

يحاول طلب السحب التالي معالجة هذا باستخدام lscpu بدلاً من ذلك.
FEATURE: Updated avail_cores calculation to handle Apple M1 or ARM processors by cheungtitus · Pull Request #631 · discourse/discourse_docker (github.com)

الإخراج الكامل

./discourse-setup --two-container
The configuration file containers/web_only.yml already exists!

. . . reconfiguring . . .


Saving old file as web_only.yml.2022-06-12-062509.bak
Stopping existing container in 5 seconds or Control-C to cancel.
WARNING: Support for aarch64 is experimental at the moment. Please report any problems at https://meta.discourse.org/tag/arm 
Press any key to continue
WARNING: We are about to start downloading the Discourse base image
This process may take anywhere between a few minutes to an hour, depending on your network speed

Please be patient

aarch64: Pulling from discourse/base
Digest: sha256:a2ce381fdc4fed59fe160fb01b79bce0d5266f59ad907a22f3399772c8711791
Status: Image is up to date for discourse/base:aarch64
docker.io/discourse/base:aarch64
WARNING: containers/web_only.yml file is world-readable. You can secure this file by running: chmod o-rwx containers/web_only.yml
web_only was not started !
./discourse-doctor may help diagnose the problem.

./discourse-setup: line 261: *0: syntax error: operand expected (error token is "*0")

Hostname for your Discourse? [discourse.example.com]: 

إعجابَين (2)

إعداد الإنتاج الخاص بنا مخصص لنظام Linux فقط. هناك دعم لتشغيل بيئة تطوير على M1.

إعجاب واحد (1)

نعم، أنا أعمل أيضًا على لينكس، وليس على نظام ماك أو إس. أنا أستخدم صورة RHEL9 كاملة، وليس UBI، عبر UTM على M1. لذا فإن المشكلة تتعلق بالفعل بنظام لينكس. لقد عثرت على بعض المواضيع حول فريق التطوير الذي يستخدم M1 بعد نشر هذا الـ PR والخيط، ولكن دون البحث في هذا الأمر بشكل أعمق، أشك في أن ذلك يتعلق بفريق التطوير الذي يستخدم طريقة أخرى للتمهيد؟

إعجاب واحد (1)

هل يستحق الأمر استثمار الجهد في الإنتاج على M1، عندما لا توجد أجهزة M1 مناسبة للإنتاج؟ لا يبدو هذا استخدامًا جيدًا للوقت.

هل نظرت في تثبيت التطوير؟

أعتقد أن هناك سوء فهم هنا. أنا لا أحاول التطوير على Discourse نفسه. أنا أيضًا لا أحاول تشغيل Discourse في بيئة الإنتاج على M1. ما أحاول القيام به هو:

  • كتابة كود أتمتة لإدارة البنية التحتية الخاصة بي
    • وهذا يشمل تثبيت وترقية Discourse بشكل دوري.
    • سيتم العمل على جهاز الكمبيوتر المحمول M1 الخاص بي، باستخدام صورة RHEL9 تعمل عبر UTM.
    • يتضمن ذلك وجود كود الأتمتة للقيام بالتثبيت والتهيئة الأولية لـ Discourse داخل جهاز RHEL9 الافتراضي.
  • تشغيل Discourse على خوادم تعتمد على Intel
    • سيتم نشر كود الأتمتة على خادم يعتمد على RHEL لبيئات UAT والإنتاج.

لذلك، ما لم أكن مخطئًا، لا توجد تغييرات إضافية مطلوبة لأنني لا أحاول التشغيل في نظام MacOS. إذا كانت هناك تغييرات إضافية مطلوبة بخلاف ما هو موجود في طلب السحب (PR)، فسأنتقل إلى الحصول على خادم مناسب للقيام بذلك، ولكن هل هذا هو الحال؟ من ناحية أخرى، هل هناك أي مشكلة في طلب السحب المقدم يمكن أن تمنعه من الاندماج نظرًا لأنه تم إنجازه بالفعل؟

إن مشاركتك الأصلية تطلب دعم Apple M1 لحزمة تثبيت الإنتاج. المشكلة هي عدم وجود أجهزة إنتاج تستخدم معالجات Apple الجديدة.

ومن هنا يأتي سؤالي: هل من المنطقي إضافة هذا الدعم، عندما لا يكون سيناريو تثبيت الإنتاج/M1 ممكنًا؟

ألن يكون من المنطقي تطوير هذا في بيئة يكون فيها جهازك أكثر تمثيلاً لسيناريو التثبيت النهائي؟

يجب أن يكون هذا سوء فهم. قلت “أنا أستخدم M1 لتطوير الأتمتة والأدوات لتشغيل Discourse” في المنشور الأصلي. إنه لتطوير الأتمتة، وليس لتشغيل Discourse.

نعم، سيكون من الجيد تشغيله على أجهزة تمثيلية، ولكن هذا لتطوير الأدوات اللازمة لتثبيت وتشغيل Discourse، ولا شيء أكثر. في بعض الأحيان أكون في الخارج وأريد أن أكون قادرًا على القيام بذلك باستخدام كمبيوتر M1 المحمول الخاص بي فقط، دون الاعتماد على الأجهزة الموجودة في بعض مراكز البيانات التي تتطلب مني إنشاء اتصال VPN.

أنا أفهم ما تحاول القيام به، كل ما أقوله هو أن تثبيت الإنتاج لا يتم تثبيته على M1، لأن M1 لا يمكن استخدامه في الإنتاج.

هذا ليس صحيحًا تمامًا، على سبيل المثال، تستخدم Raspberry Pi معالج ARM SoC، ويتثبت discourse بشكل جيد، وفقًا لـ:

حسنًا، أعتقد أنني كنت مخطئًا في قولي إنها وحدة معالجة مركزية تعتمد على ARM حيث أن المشكلة تقتصر على M1؟

على أي حال، إليك ما فعلته…

  1. التحقق من فرع جديد
    يعمل discourse-setup بشكل جيد مع التغيير في طلب السحب (PR) ولكنه بعد ذلك يبدأ المشغل (launcher) الذي سيتحقق بعد ذلك مما إذا كان لدي أحدث رمز في الفرع الرئيسي (master). لذلك، قمت بالتحقق من فرع جديد ووضعت التغيير في الفرع الجديد. لقد أضفت أيضًا إدخالًا في /etc/hosts بحيث عندما يتحقق مما إذا كنت أقوم بتشغيل النطاق الذي قلت إنني أقوم بتشغيله عليه، فإنه يجتاز الاختبار.
  2. تشغيل discourse-setup مرة أخرى
    هذه المرة، تم تشغيله بشكل جيد بما في ذلك المشغل (launcher) لإجراء البناء وبدء حاوية.

ما يلي هو ما أراه في نهاية الإخراج. حاولت تصفح http://127.0.0.1 وأرى فقط صفحة مع nginx الافتراضي. ربما لا يعمل حقًا بعد كل شيء على M1 بسبب بعض المشكلات الأخرى. سأقوم بالاختبار على نظام يعتمد على Intel بشكل صحيح. على الرغم من أنه لغرض التحقق مما إذا كانت العملية تعمل ولدينا شيء يستمع على المنفذ 80 / 443، إلا أنه جيد، ولكن سيكون من الجيد أن تكون قادرًا على خدمة صفحة بالفعل.

I, [2022-06-14T15:29:42.810750 #1]  INFO -- : Replacing (?-mix:#?ACCOUNT_EMAIL=.+) with ACCOUNT_EMAIL=$$ENV_LETSENCRYPT_ACCOUNT_EMAIL
 in /shared/letsencrypt/account.conf
I, [2022-06-14T15:29:42.811886 #1]  INFO -- : Replacing (?-mix:ssl_certificate_key.+) with ssl_certificate_key /shared/ssl/$$ENV_DISCOURSE_HOSTNAME.key;
ssl_certificate_key /shared/ssl/$$ENV_DISCOURSE_HOSTNAME_ecc.key;
 in /etc/nginx/conf.d/discourse.conf
I, [2022-06-14T15:29:42.812148 #1]  INFO -- : Replacing (?-mix:add_header.+) with add_header Strict-Transport-Security 'max-age=63072000'; in /etc/nginx/conf.d/discourse.conf
I, [2022-06-14T15:29:42.812430 #1]  INFO -- : Replacing location @discourse { with location @discourse {
add_header Strict-Transport-Security 'max-age=31536000'; # remember the certificate for a year and automatically connect to HTTPS for this domain in /etc/nginx/conf.d/discourse.conf
I, [2022-06-14T15:29:42.813521 #1]  INFO -- : > echo "Beginning of custom commands"
I, [2022-06-14T15:29:42.814803 #1]  INFO -- : Beginning of custom commands

I, [2022-06-14T15:29:42.814856 #1]  INFO -- : > echo "End of custom commands"
I, [2022-06-14T15:29:42.816137 #1]  INFO -- : End of custom commands

I, [2022-06-14T15:29:42.818177 #1]  INFO -- : Terminating async processes
I, [2022-06-14T15:29:42.819361 #1]  INFO -- : Sending INT to HOME=/var/lib/postgresql USER=postgres exec chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert /usr/lib/postgresql/13/bin/postmaster -D /etc/postgresql/13/main pid: 57
2022-06-14 15:29:42.819 UTC [57] LOG:  received fast shutdown request
I, [2022-06-14T15:29:42.820068 #1]  INFO -- : Sending TERM to exec chpst -u redis -U redis /usr/bin/redis-server /etc/redis/redis.conf pid: 118
118:signal-handler (1655220582) Received SIGTERM scheduling shutdown...
2022-06-14 15:29:42.829 UTC [57] LOG:  aborting any active transactions
2022-06-14 15:29:42.832 UTC [57] LOG:  background worker "logical replication launcher" (PID 66) exited with exit code 1
2022-06-14 15:29:42.835 UTC [61] LOG:  shutting down
118:M 14 Jun 2022 15:29:42.866 # User requested shutdown...
118:M 14 Jun 2022 15:29:42.867 * Saving the final RDB snapshot before exiting.
118:M 14 Jun 2022 15:29:42.876 * DB saved on disk
118:M 14 Jun 2022 15:29:42.876 # Redis is now ready to exit, bye bye...
2022-06-14 15:29:42.958 UTC [57] LOG:  database system is shut down
sha256:5f552461c03594fde4b917c0e995c5f63a777b44ee1638e0367c22a29fe1ec16
ef60feb320f8684423dcb5c3ca6062226d937cd72a642485052fa641f15cbc01

+ /usr/bin/docker run --shm-size=512m -d --restart=always -e LANG=en_US.UTF-8 -e RAILS_ENV=production -e UNICORN_WORKERS=4 -e UNICORN_SIDEKIQS=1 -e RUBY_GLOBAL_METHOD_CACHE_SIZE=131072 -e RUBY_GC_HEAP_GROWTH_MAX_SLOTS=40000 -e RUBY_GC_HEAP_INIT_SLOTS=400000 -e RUBY_GC_HEAP_OLDOBJECT_LIMIT_FACTOR=1.5 -e DISCOURSE_DB_SOCKET=/var/run/postgresql -e DISCOURSE_DB_HOST= -e DISCOURSE_DB_PORT= -e LETSENCRYPT_DIR=/shared/letsencrypt -e DISCOURSE_FORCE_HTTPS=true -e LC_ALL=en_US.UTF-8 -e LANGUAGE=en_US.UTF-8 -e EMBER_CLI_PROD_ASSETS=1 -e DISCOURSE_HOSTNAME=dev.bogus.com -e DISCOURSE_DEVELOPER_EMAILS=support@bogus.com -e DISCOURSE_SMTP_ADDRESS=smtp-relay.gmail.com -e DISCOURSE_SMTP_PORT=587 -e DISCOURSE_SMTP_USER_NAME=support@bogus.com -e DISCOURSE_SMTP_PASSWORD=stupidpassword -e DISCOURSE_SMTP_DOMAIN=dev.bogus.com -e DISCOURSE_NOTIFICATION_EMAIL=noreply@dev.bogus.com -e LETSENCRYPT_ACCOUNT_EMAIL=me@example.com -h bogusdev-app -e DOCKER_HOST_IP=172.17.0.1 --name app -t -p 80:80 -p 443:443 -v /var/discourse/shared/standalone:/shared -v /var/discourse/shared/standalone/log/var-log:/var/log --mac-address 02:f1:a1:42:8a:5f local_discourse/app /sbin/boot
0be6584a62912bae1d517882fde2a5bf61d1c39466448803be811fbd777c87a5
[root@bogusdev discourse]# 
[root@bogusdev discourse]# docker ps
CONTAINER ID   IMAGE                 COMMAND        CREATED          STATUS          PORTS                                                                      NAMES
0be6584a6291   local_discourse/app   "/sbin/boot"   35 seconds ago   Up 34 seconds   0.0.0.0:80->80/tcp, :::80->80/tcp, 0.0.0.0:443->443/tcp, :::443->443/tcp   app
[root@bogusdev discourse]#