Estou experimentando executar o Discourse em instâncias baseadas em Graviton da AWS, pois elas são atraentes em termos de preço. Entendo que o suporte aarch64 é experimental, mas a mensagem de compilação diz para relatar problemas, então aqui está. Acho que muitos estão executando o Discourse na AWS, então espero que isso possa beneficiar outros também.
Consegui colocar uma instalação existente em funcionamento em arm64 após uma reconstrução e algumas verificações básicas de sanidade para garantir que o frontend carregasse. No entanto, um ./launcher logs web_only mostra que rails.stderr.log está sendo constantemente preenchido com o seguinte:
ERROR: ld.so: object '/usr/lib/libjemalloc.so.1' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object '/usr/lib/libjemalloc.so.1' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
E, de fato, /usr/lib/libjemalloc.so.1 não existe em arm64 como existe nas imagens x86, mas /usr/lib/libjemalloc.so.2 existe. Rastreie a diferença de versão em arm64 para isto:
Nota lateral: parabéns pela boa documentação da mudança.
Acho que a mensagem de erro vem da menção específica ao /usr/lib/libjemalloc.so.1 inexistente feita aqui:
Uma substituição rápida e suja de $RUBY_ALLOCATOR em templates/web.template.yml parece ter parado com sucesso a mensagem de erro, então parece que o rails (puma?) agora está sendo executado com o libjemalloc correto.
Dito isso, não sei se uma correção adequada pode exigir mais alterações do que isso e se tal alteração pode ter outras implicações para sistemas de produção. Ainda assim, queria compartilhar caso afete outros que tentam usar o Discourse com arm64 na AWS. Talvez a equipe do Discourse também possa dar uma olhada?
Como o link de @merefield mostra, estou trabalhando ativamente na imagem do contêiner aarch64 e fiquei sem tempo para isso na sexta-feira passada.
Acho que finalmente cobri todos os lugares, e o próximo passo é mudar essa variável de ambiente para o link simbólico principal que termina em .so, que funcionará tanto em x64 quanto em ARM64.
Ah, que bom momento para mim, então. Eu estava querendo experimentar o arm64 há muito tempo, mas só comecei a fazer isso hoje, assim como você tem trabalhado nisso.
Ficarei feliz em ajudar a testar quando você estiver pronto, se você quiser que as alterações sejam testadas com uma instância graviton2.
Falando nisso, como a versão personalizada do jemalloc pode quebrar coisas (mas ainda é necessária para algumas configurações do Raspberry Pi), faria sentido tomar a decisão da versão com base na pesquisa do PAGESIZE específico na máquina em que a imagem está sendo criada? A razão pela qual sugiro isso é porque a instância graviton2 com a qual estou testando tem PAGESIZE=4k. Uma versão mais recente do jemalloc ainda seria necessária para alguns casos, mas talvez pudesse reduzir as diferenças entre as configurações de imagem arm64 e x64.
Eu testei no Graviton há alguns anos e funcionou perfeitamente. O trabalho que estou fazendo agora é também torná-lo compatível com plataformas ARM mais recentes com PAGESIZE não padrão. As alterações são totalmente retrocompatíveis com plataformas antigas, então nada deve mudar para elas.
Posso confirmar que está compilando bem sem alterações locais em um graviton2 e que não há erros de jemalloc nos logs que eu possa ver. Obrigado por resolver isso.
Continuarei a testá-lo, pois podemos mover nosso servidor de produção para arm64 se for estável o suficiente. Se eu encontrar algo mais, relatarei.