Estoy experimentando ejecutando Discourse en las instancias basadas en graviton de AWS, ya que son atractivas en cuanto a precio. Entiendo que el soporte para aarch64 es experimental, pero el mensaje de compilación dice que informe de los problemas, así que aquí está. Creo que muchos están ejecutando Discourse en AWS, así que espero que esto pueda beneficiar a otros también.
Logré poner en marcha una instalación existente en arm64 después de una reconstrucción y algunas comprobaciones básicas de cordura para asegurarme de que el frontend se carga. Sin embargo, un ./launcher logs web_only muestra que rails.stderr.log se llena constantemente con esto:
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.
Y, de hecho, /usr/lib/libjemalloc.so.1 no existe en arm64 como sí lo hace en las imágenes x86, pero sí existe /usr/lib/libjemalloc.so.2. Rastree la diferencia de versión en arm64 hasta esto:
Nota al margen: felicitaciones por la buena documentación del cambio.
Creo que el mensaje de error proviene de la mención específica al inexistente /usr/lib/libjemalloc.so.1 hecha aquí:
Una anulación rápida y sucia de $RUBY_ALLOCATOR en templates/web.template.yml parece haber detenido con éxito el mensaje de error, por lo que parece que rails (puma?) ahora se está ejecutando con el libjemalloc adecuado.
Habiendo dicho eso, no sé si una solución adecuada puede requerir más cambios que este y si dicho cambio puede tener otras implicaciones para los sistemas de producción. Aún así, quería compartir en caso de que afecte a otros que intentan usar Discourse con arm64 en AWS. ¿Quizás el equipo de Discourse también pueda echar un vistazo?
Como muestra el enlace de @merefield, estoy trabajando activamente en la imagen de contenedor aarch64 y me quedé sin tiempo el viernes pasado.
Creo que finalmente cubrí todos los lugares, y el siguiente paso es cambiar esa variable de entorno para el enlace simbólico principal que termina en .so, que funcionará tanto en x64 como en ARM64.
Vaya, qué suerte tengo entonces. Llevaba tiempo queriendo probar arm64, pero no lo he hecho hasta hoy, justo cuando tú has estado trabajando en ello.
Estaré encantado de ayudar a probar cuando estés listo, si quieres que los cambios se prueben en una instancia graviton2.
Hablando de eso, dado que la versión personalizada de jemalloc puede romper cosas (pero sigue siendo necesaria para algunas configuraciones de Raspberry Pi), ¿tendría sentido tomar la decisión de la versión basándose en la búsqueda del PAGESIZE particular en la máquina donde se está construyendo la imagen? La razón por la que sugiero esto es porque la instancia graviton2 con la que estoy probando tiene PAGESIZE=4k. Todavía se necesitaría una versión más reciente de jemalloc para algunos casos, pero quizás podría reducir las diferencias entre las configuraciones de imágenes arm64 y x64.
Lo probé en Graviton hace un par de años y funciona perfectamente. El trabajo que estoy haciendo ahora es también hacerlo compatible con plataformas ARM más nuevas con PAGESIZE no estándar. Los cambios son todos retrocompatibles con plataformas antiguas, por lo que nada debería cambiar para ellas.
Confirmo que se está compilando bien sin cambios locales en un graviton2 y que no hay errores de jemalloc en los registros que pueda ver. Gracias por abordar esto.
Seguiré jugando con él, ya que podríamos trasladar nuestro servidor de producción a arm64 si es lo suficientemente estable. Si me encuentro con algo más, lo informaré.