Hallo, ich benutze den M1, um Automatisierungs- und Tooling-Skripte für den Betrieb von Discourse zu entwickeln. Das Skript discourse-setup hat ein Problem mit der Erkennung von ARM-basierten CPUs und schlägt mit der folgenden Fehlermeldung fehl. Dies führte dazu, dass der Container nicht gestartet wurde. In meinem Fall gehe ich den Ansatz mit dem Web- und Datencontainer, sodass der Web-Container nicht startet.
./discourse-setup: line 261: *0: syntax error: operand expected (error token is \"*0\")
./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]:
Hallo, ja, ich arbeite auch unter Linux, nicht unter MacOS. Ich verwende ein vollständiges RHEL9-Image, kein UBI, über UTM auf dem M1. Das Problem hängt also tatsächlich mit Linux zusammen. Ich bin auf ein paar Threads gestoßen, in denen das Entwicklerteam M1 verwendet, nachdem ich diesen PR und Thread gepostet habe, aber ohne dies weiter zu untersuchen, vermute ich, dass dies damit zusammenhängt, dass das Entwicklerteam eine andere Methode zum Bootstrapping verwendet?
Macht es Sinn, Zeit in die Produktion auf M1 zu investieren, wenn es keine M1-Hardware in Produktionsqualität gibt? Das klingt nicht nach einer guten Zeitverwendung.
Haben Sie sich die Entwicklungsinstallation angesehen?
Ich glaube, hier gibt es ein Missverständnis. Ich versuche nicht, an Discourse selbst zu entwickeln. Ich versuche auch nicht, Discourse in der Produktion auf M1 laufen zu lassen. Was ich zu tun versuche, ist Folgendes:
Automatisierungscode schreiben, um meine Infrastruktur zu verwalten
Dies beinhaltet die Installation und regelmäßige Aktualisierung von Discourse.
Die Arbeit wird auf meinem M1-Laptop erledigt, wobei ein RHEL9-Image über UTM ausgeführt wird.
Dies beinhaltet, dass der Automatisierungscode die Installation und den Bootstrap von Discourse innerhalb der RHEL9-VM durchführt.
Discourse auf Intel-basierten Servern ausführen
Der Automatisierungscode wird auf einem RHEL-basierten Server für UAT- und Produktionsumgebungen bereitgestellt.
Wenn ich mich nicht irre, sind keine zusätzlichen Änderungen erforderlich, da ich nicht versuche, unter macOS auszuführen. Wenn zusätzliche Änderungen erforderlich sind, die über das hinausgehen, was im PR enthalten ist, werde ich mich wohl damit begnügen, einen geeigneten Server dafür zu bekommen, aber ist das der Fall? Gibt es andererseits Probleme mit dem eingereichten PR, die eine Zusammenführung verhindern könnten, da er bereits erledigt ist?
Ihre ursprüngliche Anfrage bezieht sich auf die Unterstützung von Apple M1 für das Produktionsinstallationspaket. Das Problem ist, dass keine Produktionshardware vorhanden ist, die die neuen Apple-Prozessoren verwendet.
Daher meine Frage: Macht es Sinn, diese Unterstützung hinzuzufügen, wenn kein Produktions-/M1-Installationsszenario möglich ist?
Wäre es nicht sinnvoller, dies in einer Umgebung zu entwickeln, in der Ihre Hardware besser dem endgültigen Installationsszenario entspricht?
Das muss ein Missverständnis sein. Ich habe im ursprünglichen Beitrag gesagt: „Ich benutze den M1, um Automatisierung und Tools zu entwickeln, um Discourse zum Laufen zu bringen.“ Es geht um die Entwicklung von Automatisierung, nicht um den Betrieb von Discourse.
Ja, es wäre schön, es auf repräsentativer Hardware laufen zu lassen, aber dies dient der Entwicklung der Tools, um Discourse zu installieren und zu starten, und nichts weiter. Manchmal bin ich unterwegs und möchte dies nur mit meinem M1-Laptop tun können, unabhängig von den Maschinen, die irgendwo in einem Rechenzentrum stehen und eine VPN-Verbindung erfordern.
Ich verstehe, was Sie versuchen, alles, was ich sage, ist, dass die Produktionsinstallation auf M1 nicht installiert, weil M1 nicht in der Produktion verwendet werden kann.
Das stimmt nicht ganz, der Raspberry Pi zum Beispiel verwendet einen ARM SoC, und Discourse lässt sich problemlos installieren, siehe:
Okay, ich lag also falsch mit der Aussage, dass es sich um eine ARM-basierte CPU handelt, da das Problem nur bei M1 auftritt?
Wie auch immer, hier ist, was ich getan habe…
Einen neuen Branch auschecken discourse-setup läuft mit der Änderung im PR einwandfrei, aber dann startet es den Launcher, der dann prüft, ob ich den neuesten Code auf dem Master habe. Also habe ich einen neuen Branch ausgecheckt und die Änderung in den neuen Branch übernommen. Ich habe auch einen Eintrag in /etc/hosts hinzugefügt, damit die Prüfung, ob ich auf der angegebenen Domain laufe, bestanden wird.
discourse-setup erneut ausführen
Dieses Mal lief es einwandfrei, einschließlich des Launchers, der den Build durchführte und einen Container startete.
Folgendes sehe ich am Ende der Ausgabe. Ich habe versucht, http://127.0.0.1 aufzurufen, und sehe nur eine Seite mit dem Standard-Nginx. Wahrscheinlich funktioniert es doch nicht auf dem M1 wegen anderer Probleme. Ich werde es auf einem richtigen Intel-basierten System testen. Obwohl es für die Überprüfung, ob der Prozess funktioniert und ob etwas auf Port 80 / 443 lauscht, ausreicht, wäre es schön, eine Seite bedienen zu können.
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]#
