Ciao, sto usando l’M1 per sviluppare automazioni e strumenti per eseguire Discourse. Lo script discourse-setup ha un problema nel riconoscere le CPU basate su ARM e fallisce con il seguente errore. Ciò ha causato il mancato avvio del container. Nel mio caso, sto optando per l’approccio del container web + dati, quindi è il container web che non riesce ad avviarsi.
./discourse-setup: line 261: *0: syntax error: operand expected (error token is \"*0\")
./discourse-setup --two-container
Il file di configurazione containers/web_only.yml esiste già!
. . . riconfigurazione . . .
Salvataggio del vecchio file come web_only.yml.2022-06-12-062509.bak
Arresto del container esistente tra 5 secondi o premi Control-C per annullare.
ATTENZIONE: Il supporto per aarch64 è attualmente sperimentale. Si prega di segnalare eventuali problemi su https://meta.discourse.org/tag/arm
Premi un tasto per continuare
ATTENZIONE: Stiamo per iniziare a scaricare l'immagine base di Discourse
Questo processo potrebbe richiedere da pochi minuti a un'ora, a seconda della velocità della tua rete
Si prega di essere pazienti
aarch64: Estrazione da discourse/base
Digest: sha256:a2ce381fdc4fed59fe160fb01b79bce0d5266f59ad907a22f3399772c8711791
Stato: L'immagine è aggiornata per discourse/base:aarch64
docker.io/discourse/base:aarch64
ATTENZIONE: il file containers/web_only.yml è leggibile da tutti. Puoi proteggere questo file eseguendo: chmod o-rwx containers/web_only.yml
web_only non è stato avviato!
./discourse-doctor può aiutare a diagnosticare il problema.
./discourse-setup: line 261: *0: syntax error: operand expected (error token is \"*0\")
Hostname per il tuo Discourse? [discourse.example.com]:
Ciao sì, sto anche eseguendo su Linux, non su MacOS. Sto usando un’immagine RHEL9 completa, non UBI, tramite UTM su M1. Quindi il problema è effettivamente correlato a Linux. Mi sono imbattuto in alcuni thread sul team di sviluppo che utilizza M1 dopo aver pubblicato questo PR e thread, ma senza approfondire ulteriormente, sospetto che sia correlato al fatto che il team di sviluppo utilizzi un altro modo per il bootstrap?
Penso ci sia un malinteso qui. Non sto cercando di fare sviluppo su Discourse stesso. Né sto cercando di eseguire Discourse in produzione su M1. Quello che sto cercando di fare è:
Scrivere codice di automazione per gestire la mia infrastruttura
Ciò include l’installazione e l’aggiornamento periodico di Discourse.
Il lavoro verrà svolto sul mio laptop M1, utilizzando un’immagine RHEL9 in esecuzione tramite UTM.
Ciò comporta la disponibilità del codice di automazione per l’installazione e il bootstrap di Discourse all’interno della VM RHEL9.
Eseguire Discourse su server basati su Intel
Il codice di automazione verrà distribuito su un server basato su RHEL per gli ambienti UAT e di produzione.
Quindi, a meno che non mi sbagli, non sono necessarie modifiche aggiuntive perché non sto cercando di eseguire su MacOS. Se ci sono modifiche aggiuntive richieste oltre a quelle nel PR, allora immagino che passerò a procurarmi un server adeguato per farlo, ma è così? D’altra parte, ci sono problemi con il PR inviato che possono impedirne il merge dato che è già stato fatto?
La tua richiesta originale riguarda il supporto per Apple M1 per il pacchetto di installazione di produzione. Il problema è che non esiste hardware di produzione che utilizzi i nuovi processori Apple.
Quindi la mia domanda è: ha senso aggiungere questo supporto, quando non è possibile alcuno scenario di installazione di produzione/M1?
Non avrebbe più senso sviluppare questo in un ambiente in cui il tuo hardware è più rappresentativo dello scenario di installazione finale?
Deve esserci stato un malinteso. Ho scritto “Sto usando l’M1 per sviluppare automazione e strumenti per far funzionare Discourse” nel post originale. È per sviluppare automazione, non per far funzionare Discourse.
Sì, sarebbe bello eseguirlo su hardware rappresentativo, ma questo serve per sviluppare gli strumenti per installare e avviare Discourse, e nient’altro. A volte sono in viaggio e voglio poterlo fare solo con il mio laptop M1, senza essere legato alle macchine che si trovano in qualche data center e che richiedono una connessione VPN.
Capisco cosa stai cercando di fare, tutto quello che sto dicendo è che l’installazione di produzione non si installa su M1, perché l’M1 non può essere utilizzato in produzione.
Questo non è del tutto vero, il Raspberry Pi ad esempio utilizza un SoC ARM e discourse si installa senza problemi, come da:
Allora, suppongo di essermi sbagliato nel dire che è una CPU basata su ARM dato che il problema riguarda solo M1?
Comunque, ecco cosa ho fatto…
Creare un nuovo branch discourse-setup funziona bene con la modifica nella PR, ma poi avvia il launcher che verificherà se ho il codice più recente su master. Quindi ho creato un nuovo branch e ho inserito la modifica nel nuovo branch. Ho anche aggiunto una voce in /etc/hosts in modo che quando verifica se sto eseguendo sul dominio su cui ho detto che sto eseguendo, superi il test.
Eseguire nuovamente discourse-setup
Questa volta è andato tutto bene, incluso il launcher per eseguire la build e avviare un container.
Quello che vedo verso la fine dell’output. Ho provato a navigare su http://127.0.0.1 e vedo solo una pagina con il nginx predefinito. Probabilmente non funziona davvero su M1 a causa di altri problemi. Lo testerò su un sistema basato su Intel. Sebbene ai fini della verifica del funzionamento del processo e dell’ascolto su porta 80 / 443 vada bene, sarebbe bello poter effettivamente servire una pagina.
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]#
