# Apple M1 지원
**URL:** https://meta.discourse.org/t/support-for-running-on-apple-m1/229724
**Category:** Feature
**Created:** [6월 12, 2022, 4:31오후 UTC](https://meta.discourse.org/t/support-for-running-on-apple-m1/229724 "2022-06-12T16:31:33Z")
**Posts on this page:** 9
**Page:** 1
### Author:  [@titusc](https://meta.discourse.org/u/titusc)
#### Post date: [6월 12, 2022, 4:31오후 UTC](https://meta.discourse.org/t/support-for-running-on-apple-m1/229724/1 "2022-06-12T16:31:33Z")
안녕하세요. 저는 M1을 사용하여 Discourse를 실행하기 위한 자동화 및 도구 개발을 하고 있습니다. discourse-setup 스크립트에는 ARM 기반 CPU를 인식하지 못하는 문제가 있어 다음과 같은 오류로 실패합니다. 이로 인해 컨테이너가 시작되지 않았습니다. 제 경우 웹 + 데이터 컨테이너 방식을 사용하고 있으므로 web\_container가 시작되지 않는 것입니다.
```plaintext
./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](https://github.com/docker/for-mac/issues/6111)에서 확인할 수 있습니다.
다음 PR은 lscpu를 사용하여 이 문제를 해결하려는 시도입니다.
[FEATURE: Updated avail\_cores calculation to handle Apple M1 or ARM processors by cheungtitus · Pull Request #631 · discourse/discourse\_docker (github.com)](https://github.com/discourse/discourse_docker/pull/631)
**전체 출력**
```plaintext
./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]:
```
---
### Author:  [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [6월 12, 2022, 10:06오후 UTC](https://meta.discourse.org/t/support-for-running-on-apple-m1/229724/2 "2022-06-12T22:06:11Z")
우리 프로덕션 환경은 Linux 전용입니다. 다만 M1에서 개발 환경을 실행하는 것은 지원됩니다.
---
### Author:  [@titusc](https://meta.discourse.org/u/titusc)
#### Post date: [6월 13, 2022, 2:54오후 UTC](https://meta.discourse.org/t/support-for-running-on-apple-m1/229724/3 "2022-06-13T14:54:37Z")
네, 저도 Linux를 사용하고 있으며, MacOS가 아닙니다. UBI가 아닌 RHEL9 전체 이미지를 M1에서 UTM을 통해 실행하고 있습니다. 따라서 문제는 실제로 Linux와 관련이 있는 것으로 보입니다. 이 PR과 스레드를 게시한 후 개발 팀이 M1을 사용한다는 몇몇 스레드를 우연히 발견했지만, 더 자세히 살펴보지는 않았지만, 개발 팀이 다른 방식으로 부트스트래핑을 수행하고 있기 때문일 것으로 추정됩니다.
---
### Author:  [@Stephen](https://meta.discourse.org/u/Stephen)
#### Post date: [6월 13, 2022, 4:12오후 UTC](https://meta.discourse.org/t/support-for-running-on-apple-m1/229724/4 "2022-06-13T16:12:13Z")
m1에 프로덕션 등급의 하드웨어가 없는 상황에서, m1에서 프로덕션 환경에 공력을 투자하는 것이 시간적으로 합리적인가? 좋은 시간 활용이라고 느껴지지 않는다.
개발용 설치에 대해 확인해 보았는가?
---
### Author:  [@titusc](https://meta.discourse.org/u/titusc)
#### Post date: [6월 14, 2022, 2:10오후 UTC](https://meta.discourse.org/t/support-for-running-on-apple-m1/229724/5 "2022-06-14T14:10:49Z")
여기서 오해가 있는 것 같습니다. 저는 Discourse 자체에 대한 개발을 하려는 것이 아닙니다. 또한 M1에서 Discourse를 프로덕션으로 실행하려는 것도 아닙니다. 제가 하려는 일은 다음과 같습니다:
- 인프라를 관리하기 위한 자동화 코드를 작성하는 것
- 여기에는 Discourse의 설치와 주기적인 업그레이드가 포함됩니다.
- 이 작업은 UTM을 통해 실행되는 RHEL9 이미지를 사용하여 제 M1 노트북에서 수행됩니다.
- 이는 RHEL9 VM 내에서 Discourse의 설치와 부트스트랩을 수행하도록 자동화 코드를 구성하는 것을 포함합니다.
- Intel 기반 서버에서 Discourse를 실행하는 것
- 자동화 코드는 UAT 및 프로덕션 환경을 위해 RHEL 기반 서버에 배포됩니다.
제가 잘못 알고 있지 않는 한, MacOS에서 실행하려는 것이 아니므로 추가적인 변경 사항은 필요하지 않습니다. PR에 포함된 것 외에 추가적인 변경 사항이 필요하다면, 이 작업을 수행할 적절한 서버를 구하는 방향으로 전환해야 할 것 같은데, 실제로 그런가요? 아니면 이미 완료된 상태의 제출된 PR에 병합을 막을 수 있는 문제가 있는 것인가요?
---
### Author:  [@Stephen](https://meta.discourse.org/u/Stephen)
#### Post date: [6월 14, 2022, 2:15오후 UTC](https://meta.discourse.org/t/support-for-running-on-apple-m1/229724/6 "2022-06-14T14:15:23Z")
원래 게시글에서는 프로덕션 설치 패키지에 Apple M1 지원을 요청하고 있습니다. 문제는 새로운 Apple 프로세서를 사용하는 프로덕션 하드웨어가 없다는 점입니다.
따라서 질문드립니다: 프로덕션/M1 설치 시나리오가 불가능한 상황에서 이 지원을 추가하는 것이 의미 있는 일일까요?
최종 설치 시나리오와 하드웨어가 더 잘 부합하는 환경에서 이 기능을 개발하는 것이 더 합리적이지 않을까요?
---
### Author:  [@titusc](https://meta.discourse.org/u/titusc)
#### Post date: [6월 14, 2022, 2:24오후 UTC](https://meta.discourse.org/t/support-for-running-on-apple-m1/229724/7 "2022-06-14T14:24:50Z")
아마 오해인 것 같습니다. 원래 게시글에서 "M1을 사용해 Discourse를 실행하기 위한 자동화 및 툴링을 개발하고 있다"고 명시했습니다. 이는 Discourse를 실행하기 위한 것이 아니라, 자동화를 개발하기 위한 것입니다.
대표적인 하드웨어에서 실행할 수 있다면 좋겠지만, 이는 Discourse를 설치하고 시작하기 위한 툴링을 개발하기 위한 목적일 뿐, 그 이상의 것은 아닙니다. 때로는 출장 중에도 VPN 연결을 위해 데이터센터에 있는 머신에 종속되지 않고, M1 노트북만으로 이 작업을 수행할 수 있으면 좋겠습니다.
---
### Author:  [@Stephen](https://meta.discourse.org/u/Stephen)
#### Post date: [6월 14, 2022, 2:25오후 UTC](https://meta.discourse.org/t/support-for-running-on-apple-m1/229724/8 "2022-06-14T14:25:58Z")
무엇을 하려는지는 이해합니다. 제가 말하고 싶은 것은 프로덕션 설치판이 M1에 설치되지 않는다는 점인데, **그 이유는** M1이 프로덕션 환경에서 사용할 수 없기 때문입니다.
> [@titusc](#):
>
> discourse-setup 스크립트는 ARM 기반 CPU를 인식하지 못하는 문제가 있으며, 다음과 같은 오류로 실패합니다.
이것은 엄밀히 말해 사실과 다릅니다. 예를 들어 라즈베리 파이는 ARM SoC를 사용하지만, 다음과 같은 자료에 따르면 Discourse가 정상적으로 설치됩니다:
> **[Discourse on a Raspberry Pi](https://blog.discourse.org/2021/12/2021-12-07-discourse-on-a-raspberry-pi/)**
>
> Running a production instance of Discourse in a $35 Raspberry Pi 4
---
### Author:  [@titusc](https://meta.discourse.org/u/titusc)
#### Post date: [6월 14, 2022, 3:49오후 UTC](https://meta.discourse.org/t/support-for-running-on-apple-m1/229724/9 "2022-06-14T15:49:22Z")
음, 그러니까 M1에서만 문제가 발생하는 것 같으니 ARM 기반 CPU라고 말한 내 말이 틀렸던 것 같습니다.
어쨌든 제가 한 작업은 다음과 같습니다 …
1. 새 브랜치 체크아웃
PR의 변경 사항을 적용하면 discourse-setup이 정상적으로 실행되지만, 이후 launcher가 실행되어 master에 최신 코드가 있는지 확인합니다. 그래서 새 브랜치를 체크아웃하고 변경 사항을 해당 새 브랜치에 적용했습니다. 또한 /etc/hosts에 항목을 추가하여, 제가 실행한다고 말한 도메인으로 실행 중인지 확인할 때 테스트를 통과하도록 했습니다.
2. discourse-setup 다시 실행
이번에는 launcher가 빌드를 수행하고 컨테이너를 시작하는 과정까지 모두 정상적으로 실행되었습니다.
아래는 출력 내용 중 후반부에 보이는 것입니다. [http://127.0.0.1로](http://127.0.0.xn--1-w30f) 접속해 보니 기본 nginx 페이지만 표시됩니다. 아마도 다른 문제들로 인해 M1에서는 결국 제대로 동작하지 않는 것 같습니다. 제대로 된 Intel 기반 시스템에서 테스트해 보겠습니다. 프로세스가 작동하는지, 포트 80/443에서 무언가가 리스닝하는지 확인하는 목적만으로는 괜찮지만, 실제로 페이지를 서빙할 수 있는 기능이 있다면 좋겠습니다.
```plaintext
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]#
```