Sto sperimentando l’esecuzione di Discourse nelle istanze basate su graviton di AWS poiché sono interessanti dal punto di vista del prezzo. Capisco che il supporto aarch64 è sperimentale, ma il messaggio di build dice di segnalare i problemi, quindi eccolo qui. Penso che molti stiano eseguendo Discourse su AWS, quindi spero che questo possa essere utile anche ad altri.
Sono riuscito a far funzionare un’installazione esistente su arm64 dopo una ricostruzione e alcuni controlli di base per assicurarmi che il frontend si caricasse. Tuttavia, un ./launcher logs web_only mostra che rails.stderr.log viene costantemente riempito con questi:
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, infatti, /usr/lib/libjemalloc.so.1 non esiste su arm64 come invece esiste sulle immagini x86, ma esiste /usr/lib/libjemalloc.so.2. Ho tracciato la differenza di versione su arm64 a questo:
Nota a margine: complimenti per la buona documentazione della modifica.
Penso che il messaggio di errore provenga dalla menzione specifica del file inesistente /usr/lib/libjemalloc.so.1 qui:
Una sovrascrittura rapida e sporca di $RUBY_ALLOCATOR su templates/web.template.yml sembra aver interrotto con successo il messaggio di errore, quindi sembra che rails (puma?) ora venga eseguito con il corretto libjemalloc.
Detto questo, non so se una correzione adeguata possa richiedere più modifiche di questa e se tale modifica possa avere altre implicazioni per i sistemi di produzione. Tuttavia, volevo condividere nel caso in cui influenzi altri che cercano di utilizzare Discourse con arm64 su AWS. Forse anche il team di Discourse può dare un’occhiata?
Come mostra il link di @merefield, sto lavorando attivamente all’immagine container aarch64 e ho finito il tempo venerdì scorso.
Penso di aver coperto tutti i posti e il passo successivo è cambiare quell’ENV per il symlink principale che termina in .so, che funzionerà sia su x64 che su ARM64.
Oh, wow, che tempismo fortunato per me allora. Stavo pensando di provare arm64 da molto tempo, ma ho iniziato a farlo solo oggi, proprio mentre ci stavi lavorando.
Sono felice di aiutare a testare quando sarai pronto, se desideri che le modifiche vengano testate con un’istanza graviton2.
A proposito, dato che la versione personalizzata di jemalloc può causare problemi (ma è comunque necessaria per alcune configurazioni di Raspberry Pi), avrebbe senso prendere la decisione sulla versione in base alla ricerca della PAGESIZE specifica sulla macchina su cui viene creata l’immagine? Il motivo per cui suggerisco questo è che l’istanza graviton2 che sto testando ha PAGESIZE=4k. Una versione più recente di jemalloc sarebbe comunque necessaria per alcuni casi, ma forse potrebbe ridurre le differenze tra le configurazioni delle immagini arm64 e x64.
L’ho testato su Graviton un paio di anni fa e funziona benissimo. Il lavoro che sto facendo ora è anche renderlo compatibile con le nuove piattaforme ARM con PAGESIZE non standard. Le modifiche sono tutte retrocompatibili con le vecchie piattaforme, quindi nulla dovrebbe cambiare per quelle.
Confermo che la compilazione funziona bene senza modifiche locali su un graviton2 e che non ci sono errori jemalloc nei log che posso vedere. Grazie per aver affrontato questo problema.
Continuerò a sperimentare poiché potremmo spostare il nostro server di produzione su arm64 se sarà abbastanza stabile. Se riscontrerò qualcos’altro, lo segnalerò.