Olá, estou usando o M1 para desenvolver automação e ferramentas para colocar o Discourse em funcionamento. O script discourse-setup tem um problema ao reconhecer CPUs baseadas em ARM e falha com o seguinte erro. Isso resultou no contêiner não iniciando. No meu caso, estou optando pela abordagem de contêiner web + dados, então é o contêiner web que falha ao iniciar.
./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]:
Olá, sim, eu também estou rodando no Linux, não no MacOS. Estou usando uma imagem RHEL9 completa, não UBI, via UTM no M1. Portanto, o problema está realmente relacionado ao Linux. Eu me deparei com alguns tópicos sobre a equipe de desenvolvimento usando M1 depois que postei este PR e tópico, mas sem investigar mais, suspeito que isso esteja relacionado à equipe de desenvolvimento usando outra maneira de inicializar?
Acho que há um mal-entendido aqui. Não estou tentando fazer desenvolvimento no Discourse em si. Também não estou tentando executar o Discourse em produção no M1. O que estou tentando fazer é:
Escrever código de automação para gerenciar minha infraestrutura
Isso inclui instalação e atualização periódica do Discourse.
O trabalho será feito no meu laptop M1, usando uma imagem RHEL9 rodando via UTM.
Isso envolve ter o código de automação para fazer a instalação e o bootstrap do Discourse dentro da VM RHEL9.
Executar o Discourse em servidores baseados em Intel
O código de automação será implantado em um servidor baseado em RHEL para ambientes UAT e de produção.
Portanto, a menos que eu esteja enganado, não há alterações adicionais necessárias porque não estou tentando executar no MacOS. Se houver alterações adicionais necessárias além do que está no PR, então acho que passarei para obter um servidor adequado para fazer isso, mas é esse o caso? Por outro lado, há algum problema com o PR enviado que possa impedir sua fusão, dado que já está pronto?
Sua postagem original está solicitando suporte para Apple M1 para o pacote de instalação de produção. O problema é que não há hardware de produção que use os novos processadores da Apple.
Daí minha pergunta: faz sentido adicionar esse suporte, quando nenhum cenário de instalação de Produção/M1 é possível?
Não faria mais sentido desenvolver isso em um ambiente onde seu hardware é mais representativo do cenário de instalação final?
Deve ter havido um mal-entendido. Eu disse “Estou usando o M1 para desenvolver automação e ferramentas para colocar o Discourse em funcionamento” na postagem original. É para desenvolver automação, não para executar o Discourse.
Sim, seria bom executá-lo em hardware representativo, mas isso é para desenvolver as ferramentas para instalar e iniciar o Discourse, e nada mais. Às vezes, estou na estrada e quero poder fazer isso apenas com meu laptop M1, sem depender das máquinas em algum Data Center que exigem que eu estabeleça uma conexão VPN.
Eu entendo o que você está tentando fazer, tudo o que estou dizendo é que a instalação de produção não instala no M1, porque o M1 não pode ser usado em produção.
Isso não é estritamente verdade, o Raspberry Pi, por exemplo, usa um SoC ARM, e o Discourse instala perfeitamente, de acordo com:
Ok, então acho que eu estava errado em dizer que o problema é com a CPU baseada em ARM, já que o problema é apenas com o M1?
De qualquer forma, aqui está o que eu fiz…
Criar um novo branch
O discourse-setup funciona bem com a alteração no PR, mas então ele inicia o launcher, que verifica se tenho o código mais recente no master. Então, eu criei um novo branch e coloquei a alteração no novo branch. Eu também adicionei uma entrada em /etc/hosts para que, quando ele verificar se estou executando no domínio que eu disse que estou executando, ele passe no teste.
Executar discourse-setup novamente
Desta vez, funcionou bem, incluindo o launcher para fazer o build e iniciar um container.
O que vejo no final da saída está abaixo. Tentei navegar para http://127.0.0.1 e vejo apenas uma página com o nginx padrão. Provavelmente, realmente não funciona no M1 devido a outros problemas. Testarei em um sistema adequado baseado em Intel. Embora, para o propósito de verificar se o processo funciona e se temos algo escutando nas portas 80 / 443, esteja tudo bem, mas seria bom ter a capacidade de realmente servir uma 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]#
