支持在Apple M1上运行

我正在使用 M1 开发用于运行 Discourse 的自动化和工具。discourse-setup 脚本在识别基于 ARM 的 CPU 时存在问题,并因以下错误而失败。这导致容器未能启动。在我的情况下,我使用的是 web + data 容器方法,因此是 web_container 无法启动。

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

这显然是由于该脚本仅支持基于 Intel 的 /proc/cpuinfo 输出,而基于 ARM 的处理器不同。示例可以在 /proc/cpuinfo inside containers reports meaningless data on Apple M1 Max · Issue #6111 · docker/for-mac · GitHub 中看到。

以下 PR 试图通过改用 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 个赞

是的,我也在 Linux 上运行,而不是 macOS。我正在通过 UTM 在 M1 上使用完整的 RHEL9 镜像,而不是 UBI。所以问题确实与 Linux 有关。在我发布此 PR 和线程后,我偶然发现了一些关于开发团队使用 M1 的帖子,但没有进一步研究,我怀疑这与开发团队使用另一种方式进行引导有关?

1 个赞

当没有生产级别的 M1 硬件时,投入精力进行 M1 生产是否值得?这听起来不是一个好的时间利用方式。

你是否查看了开发安装?

我认为这里存在误解。我并不是想在 Discourse 本身上面进行开发,也不是想在 M1 上运行 Discourse 的生产环境。我想要做的是:

  • 编写自动化代码来管理我的基础设施
    • 这包括 Discourse 的安装和定期升级。
    • 这项工作将在我的 M1 笔记本上完成,使用通过 UTM 运行的 RHEL9 镜像。
    • 这涉及到让自动化代码在 RHEL9 虚拟机中完成 Discourse 的安装和引导。
  • 在基于 Intel 的服务器上运行 Discourse
    • 自动化代码将部署在基于 RHEL 的服务器上,用于 UAT 和生产环境。

所以,除非我弄错了,否则不需要做任何额外的更改,因为我并不是想在 MacOS 上运行。如果除了 PR 中已有的内容之外还需要其他更改,那么我猜我会继续寻找一个合适的服务器来完成这项工作,但情况是这样的吗?另一方面,提交的 PR 是否存在任何可能阻止其合并的问题,因为它已经完成了?

您最初的帖子是要求为生产安装包添加对 Apple M1 的支持。问题在于,目前没有使用新款 Apple 处理器的生产硬件。

因此,我的问题是:在不可能出现生产/M1 安装场景的情况下,添加此支持是否有意义?

在硬件更能代表最终安装场景的环境中进行开发,难道不更有意义吗?

这一定是个误会。我在原帖中说的是“我正在使用 M1 开发自动化和工具来运行 Discourse”。这是为了开发自动化,而不是为了运行 Discourse。

是的,在代表性硬件上运行它会很好,但这只是为了开发用于安装和启动 Discourse 的工具,仅此而已。有时我会在路上,只想用我的 M1 笔记本电脑完成这项工作,无需连接到位于某个数据中心的机器,也无需建立 VPN 连接。

我明白你想做什么,我只是说生产环境的安装在 M1 上无法进行,因为 M1 不能用于生产环境。

这不完全正确,例如树莓派使用 ARM SoC,并且 discourse 可以正常安装,根据:

好吧,我猜我说它是基于 ARM 的 CPU 是错的,因为问题只出在 M1 上?

无论如何,这是我所做的……

  1. 检出一个新分支
    discourse-setup 在 PR 的更改后运行正常,但随后会启动 launcher,然后 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]#