Hola, estoy usando el M1 para desarrollar automatización y herramientas para poner en marcha Discourse. El script discourse-setup tiene un problema para reconocer las CPU basadas en ARM y falla con el siguiente error. Esto resultó en que el contenedor no se iniciara. En mi caso, opto por el enfoque de contenedor web + datos, por lo que es el contenedor web el que falla al iniciarse.
./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]:
Hola, sí, yo también estoy ejecutando en Linux, no en MacOS. Estoy usando una imagen RHEL9 completa, no UBI, a través de UTM en el M1. Por lo tanto, el problema está efectivamente relacionado con Linux. Me encontré con algunos hilos sobre el equipo de desarrollo que usa M1 después de que publiqué este PR y hilo, pero sin mirarlo más a fondo, sospecho que está relacionado con que el equipo de desarrollo usa otra forma de arrancar?
Creo que aquí hay un malentendido. No estoy intentando hacer desarrollo en Discourse en sí. Tampoco estoy intentando ejecutar Discourse en producción en M1. Lo que estoy intentando hacer es:
Escribir código de automatización para gestionar mi infraestructura
Esto incluye la instalación y actualización periódica de Discourse.
El trabajo se realizará en mi portátil M1, utilizando una imagen RHEL9 ejecutándose a través de UTM.
Esto implica tener el código de automatización para realizar la instalación y el arranque de Discourse dentro de la VM RHEL9.
Ejecutar Discourse en servidores basados en Intel
El código de automatización se implementará en un servidor basado en RHEL para los entornos UAT y de producción.
Así que, a menos que me equivoque, no hay cambios adicionales requeridos porque no estoy intentando ejecutar en MacOS. Si hay cambios adicionales que se requieren más allá de lo que está en el PR, entonces supongo que pasaré a conseguir un servidor adecuado para hacerlo, pero ¿es ese el caso? Por otro lado, ¿hay algún problema con el PR enviado que pueda impedir su fusión dado que ya está hecho?
Tu publicación original solicita compatibilidad con Apple M1 para el paquete de instalación de producción. El problema es que no hay hardware de producción que utilice los nuevos procesadores de Apple.
Por lo tanto, mi pregunta es: ¿tiene sentido agregar esta compatibilidad, cuando no es posible ningún escenario de instalación de producción/M1?
¿No tendría más sentido desarrollar esto en un entorno donde su hardware sea más representativo del escenario de instalación final?
Debe ser un malentendido. Dije “Estoy usando el M1 para desarrollar automatización y herramientas para poner en marcha Discourse” en la publicación original. Es para desarrollar automatización, no para ejecutar Discourse.
Sí, sería bueno ejecutarlo en hardware representativo, pero esto es para desarrollar las herramientas para instalar y poner en marcha Discourse, y nada más. A veces estoy de viaje y quiero poder hacer esto solo con mi portátil M1, sin depender de las máquinas que están en algún centro de datos y que requieren que establezca una conexión VPN.
Entiendo lo que intentas hacer, lo único que digo es que la instalación de producción no se instala en M1, porque el M1 no se puede usar en producción.
Esto no es estrictamente cierto, la Raspberry Pi, por ejemplo, utiliza un SoC ARM y Discourse se instala perfectamente, según:
Entonces, supongo que me equivoqué al decir que el problema es la CPU basada en ARM, ¿ya que solo afecta a M1?
De todos modos, esto es lo que hice…
Crear una nueva rama discourse-setup se ejecuta bien con el cambio en el PR, pero luego inicia el lanzador que verifica si tengo el código más reciente en master. Así que creé una nueva rama y apliqué el cambio en la nueva rama. También agregué una entrada en /etc/hosts, por lo que cuando verifica si estoy ejecutando en el dominio que dije que estoy ejecutando, pasa la prueba.
Ejecutar discourse-setup de nuevo
Esta vez se ejecutó bien, incluido el lanzador para hacer la compilación y se inició un contenedor.
A continuación, se muestra lo que veo al final de la salida. Intenté navegar a http://127.0.0.1 y solo veo una página con el nginx predeterminado. Probablemente realmente no funcione en M1 debido a otros problemas. Probaré en un sistema basado en Intel adecuado. Aunque para el propósito de verificar si el proceso funciona y tenemos algo escuchando en los puertos 80/443, está bien, pero sería bueno poder servir una página.
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]#
