Apple M1での実行をサポート

Discourse の実行を自動化およびツール作成のために M1 を使用しています。discourse-setup スクリプトは ARM ベースの CPU を認識する際に問題があり、次のエラーで失敗します。これにより、コンテナが起動しませんでした。私の場合は、Web + データコンテナのアプローチを採用しているため、Web コンテナが起動に失敗します。

./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

はい、私もmacOSではなくLinuxで実行しています。UTM経由でM1上でフルRHEL9イメージ(UBIではない)を使用しています。したがって、問題は確かにLinuxに関連しています。このPRとスレッドを投稿した後、開発チームがM1を使用していることに関するいくつかのスレッドを見つけましたが、さらに詳しく調べることなく、開発チームが別のブートストラップ方法を使用していることが関係しているのではないかと疑っています。

「いいね!」 1

M1のプロダクショングレードのハードウェアがないのに、M1でのプロダクションへの労力投資は時間の無駄ではないでしょうか。

開発環境のインストールは確認しましたか?

ここで誤解があると思います。私はDiscourse自体の開発を行おうとしているわけではありません。また、M1でDiscourseを本番環境で実行しようとしているわけでもありません。私がやろうとしていることは以下の通りです。

  • インフラストラクチャを管理するための自動化コードを作成する
    • これにはDiscourseのインストールと定期的なアップグレードが含まれます。
    • 作業はUTM経由で実行されるRHEL9イメージを使用した私のM1ラップトップで行われます。
    • これには、RHEL9 VM内でDiscourseのインストールとブートストラップを行うための自動化コードが必要です。
  • IntelベースのサーバーでDiscourseを実行する
    • 自動化コードは、UATおよび本番環境のためにRHELベースのサーバーにデプロイされます。

したがって、私の認識が間違っていなければ、macOSで実行しようとしているわけではないため、追加の変更は必要ありません。もしPRに含まれているもの以外に追加の変更が必要な場合は、適切なサーバーを入手して作業を進めることにしますが、それは必要でしょうか?一方で、すでに完了しているPRがマージをブロックするような問題はありますか?

元の投稿では、プロダクションインストールパッケージのApple M1サポートを求めています。問題は、新しいAppleプロセッサを使用するプロダクションハードウェアが存在しないことです。

したがって、質問ですが、プロダクション/M1のインストールシナリオが不可能な場合、このサポートを追加することに意味があるのでしょうか?

最終的なインストールシナリオをより代表する環境でこれを開発する方が理にかなっていませんか?

それは誤解でしょう。元の投稿で「Discourse を実行するための自動化とツール開発に M1 を使用しています」と述べました。Discourse を実行するためではなく、自動化を開発するためです。

代表的なハードウェアで実行できれば良いのですが、これは Discourse をインストールして開始するためのツールを開発するためのもので、それ以上のことは何もありません。時々移動中で、VPN 接続を確立する必要があるデータセンターにあるマシンから切り離された状態で、M1 ラップトップだけでこれができるようにしたいのです。

おっしゃることは理解できます。私が言いたいのは、M1は本番環境で使用できないため、本番環境のインストールがM1にインストールされないということです。

これは厳密には正しくありません。例えば、Raspberry PiはARM SoCを使用しており、discourseは問題なくインストールできます。以下を参照してください。

M1 の問題だけで ARM ベースの CPU だと言ったのは間違いだったようです。

とにかく、私がやったことは以下の通りです。

  1. 新しいブランチをチェックアウトする
    PR の変更で discourse-setup は問題なく実行されましたが、その後ランチャーが起動し、最新の master コードを持っているか確認されます。そこで、新しいブランチをチェックアウトし、その新しいブランチに変更を加えました。また、/etc/hosts にエントリを追加したので、ドメインで実行しているかどうかを確認するテストに合格します。
  2. discourse-setup を再度実行する
    今回は、ランチャーによるビルドの実行とコンテナの起動を含め、問題なく実行されました。

以下は、出力の最後の方に見られるものです。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]#