Grafana: Docker: las imágenes ARM no funcionan desde v6.4.x

Gracias por informar de este @theWaldschrat, lo investigaremos más a fondo

@theWaldschrat ¿qué dispositivo estás usando? ¿Es esa una arquitectura de 32 o 64 bits (armv6m armv7, armv8, etc.)?

¿Quizás debamos incluir https://pkgs.alpinelinux.org/package/edge/main/armhf/libc6-compat en la imagen de la ventana acoplable de Grafana?

apk add --no-cache --repository=http://dl-cdn.alpinelinux.org/alpine/edge/main libc6-compat

@theWaldschrat ¿ puede confirmar que lo anterior resuelve el problema? Es más difícil para nosotros verificar sin acceso a un dispositivo ARM real. La imagen del brazo basada en Docker tal vez sea una posibilidad, pero agradecería que nos ayude aquí. Gracias

El dispositivo es una Raspberry Pi 4B. Técnicamente es un ARM64v8, pero Raspbian de forma predeterminada ejecuta un kernel y un área de usuario de 32 bits, por lo que ARM32v7.

uname -a
SO anfitrión:
Linux raspberrypi 4.19.66-v7l+ #1253 SMP Thu Aug 15 12:02:08 BST 2019 armv7l GNU/Linux
Imagen de Grafana 6.3.6:
Linux 97f0bb9a456d 4.19.66-v7l+ #1253 SMP Thu Aug 15 12:02:08 BST 2019 armv7l armv7l armv7l GNU/Linux
Imagen de Grafana 6.4.X (más reciente):
Linux 84a01cb75816 4.19.66-v7l+ #1253 SMP Thu Aug 15 12:02:08 BST 2019 armv7l Linux

Todavía no he creado muchas imágenes de Docker, por lo que no puedo probar el comando anterior en una nueva imagen, al menos no rápidamente. Pero lo que hice: ejecutar un grafana: el último contenedor con el punto de entrada bash y la raíz del usuario:
docker run -it -p 3001:3000 --entrypoint="bash" --user=root grafana/grafana
Aquí está el resultado:

• La ejecución manual de /run.sh da el mismo mensaje de error, por lo que se confirma.
• Ejecutar el comando anterior: sin error.
• Vuelva a ejecutar /run.sh: Nuevos mensajes de error:

Error relocating /usr/share/grafana/bin/grafana-server: __memset_chk: symbol not found
Error relocating /usr/share/grafana/bin/grafana-server: __memcpy_chk: symbol not found
Error relocating /usr/share/grafana/bin/grafana-server: __vfprintf_chk: symbol not found
Error relocating /usr/share/grafana/bin/grafana-server: __fprintf_chk: symbol not found

• Ejecutar ldd /usr/share/grafana/bin/grafana-server ya no se queja de la falta de bibliotecas, pero da los mismos resultados que los anteriores.

No soy un experto, pero supongo que las lib-c todavía no son compatibles.

@theWaldschrat gracias muy útil.

Solo para verificar algunas cosas adicionales, puede probar específicamente estas para verificar que tiene el mismo problema:
docker run -it -p 3001:3000 --entrypoint="bash" --user=root grafana/grafana-arm32v7-linux:6.4.1

docker run -it -p 3001:3000 --entrypoint="bash" --user=root grafana/grafana-arm32v7-linux:6.4.0-beta1

Solo para estar seguro, también puede intentar ejecutar e iniciar grafana-server:
docker run -it -p 3001:3000 --entrypoint="bash" --user=root grafana/grafana-arm64v8-linux:6.4.1

Los dos primeros hacen lo mismo que se describió anteriormente.
Ejecutar /run.sh o directamente /usr/share/grafana/bin/grafana-server no hace ninguna diferencia.

El tercero ni siquiera comienza con un desajuste de arco:
standard_init_linux.go:211: exec user process caused "exec format error"

Tengo el mismo problema y tuve que cambiar a la versión 6.3.6 , por lo que parece que todas las imágenes 6.4.x basadas en Alpine están dañadas para ARMv7.

Gracias. Después de ingresar a bash, ¿puedes intentar instalar el paquete musl-dev usando apk add?

musl-dev instala bien para mí, pero no tiene un impacto en el problema, con o sin libc6-compat .

La instalación de glibc apks de https://github.com/armhf-docker-library/alpine-pkg-glibc/releases permite que grafana-server comience. Sin embargo, si entiendo el problema correctamente, es mejor vincular estáticamente los binarios con musl.

Es la idea de Alpine vincular estáticamente a musl en lugar de vincular dinámicamente glibc. Es más rápido, más pequeño, más estable y potencialmente más seguro. Al menos eso es lo que dicen.
Pero por lo que puedo ver, Grafana se construye fuera de la imagen de destino que se vincula con glibc, por lo que probablemente sea la mejor idea instalar glibc como se indicó anteriormente o usar una imagen base diferente que ya incluya glibc.

Teniendo en cuenta que este cambio rompió efectivamente la imagen de la ventana acoplable para dispositivos ARM, esperaba algo mejor que una etiqueta de "investigación de necesidades".

¡Suspiro! La maldición del "desarrollo ágil", supongo.

Puedo reproducir el error en OS X, aunque se ve un poco diferente al tuyo:

$ docker run --platform arm grafana/grafana
/lib/ld-linux-armhf.so.3: No such file or directory

Veré si puedo arreglarlo.

Es posible que tenga una pista sobre la causa raíz de este problema, con la esperanza de poder solucionarlo mañana.

Trabajando para resolver esto construyendo binarios musl además de glibc.

Me encontré con esto también. Mi sistema es aarch64 (RockPro64) y recibo el mismo error:

/run.sh: line 80: /usr/share/grafana/bin/grafana-server: No such file or directory

Basado en el trabajo en # 19798, hemos enviado una etiqueta llamada dev-musl a los repositorios de grafana docker hub. Solo hemos podido probar la ejecución de las imágenes de la ventana acoplable arm y arm64 mediante la emulación, por lo que le pedimos a cualquier persona que nos ayude a probar las imágenes de la ventana acoplable arm y arm64 para verificar que funcionan como se esperaba. No se ha enviado ningún manifiesto a grafana / grafana, por lo que si desea probar arm o arm64, debe especificar manualmente el repositorio correcto, consulte a continuación.

linux / amd64 :
docker run <args> grafana/grafana:dev-musl

linux / arm64 :
docker run <args> grafana/grafana-arm64v8-linux:dev-musl

linux / brazo :
docker run <args> grafana/grafana-arm32v7-linux:dev-musl

Tenga en cuenta que estas imágenes se basan en la rama de desarrollador actual (master / Grafana v6.5.0-pre) de Grafana, por lo que si desea probar con una instalación de Grafana existente, recuerde hacer una copia de

Alcance de prueba:

• Verifique que el contenedor se pueda ejecutar correctamente y que el uso de docker logs <image name> no produzca nada inesperado, como errores.
• Si es posible, intente agregar / conectarse a una fuente de datos y renderizar un tablero / panel
• Opcional: Verifique que pueda descargar / instalar complementos
• Proporcione comentarios sobre este problema o PR # 19798 haciendo un comentario que indique qué dispositivo / arquitectura ha utilizado y el resultado.

Gracias por adelantado

$ uname -a
Linux black-pearl 4.14.70-hypriotos-v7+ #1 SMP Sat Sep 22 05:54:18 UTC 2018 armv7l GNU/Linux

LGTM ejecutándose en una Raspberry 3B

• [x] Verifique que el contenedor pueda ejecutarse correctamente y usar registros de Dockerno debería generar nada inesperado como errores.
• [x] Si es posible, intente agregar / conectarse a una fuente de datos y renderizar un tablero / panel
• [x] Opcional: verifique que pueda descargar / instalar complementos

SBC: Cubietruck (también conocido como CubieBoard 3)

$ uname -a
Linux fernia 4.19.62-sunxi # 5.92 SMP Mié 31 de julio 22:07:23 CEST 2019 armv7l armv7l armv7l GNU / Linux

LGTM

• [x] Verifique que el contenedor se pueda ejecutar correctamente y que el uso de registros de la ventana acoplable no debería generar nada inesperado, como errores.
• [x] Si es posible, intente agregar / conectarse a una fuente de datos y renderizar un tablero / panel
• [x] Opcional: verifique que pueda descargar / instalar complementos

Muchas gracias por las respuestas rápidas y la ayuda. Muy apreciado.

De acuerdo, gracias por ayudarme con la prueba.

El martes 22 de octubre de 2019 a las 19:05 Marcus Efraimsson [email protected]
escribió:

Muchas gracias por las respuestas rápidas y la ayuda. Muy apreciado.

-
Está recibiendo esto porque fue asignado.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/grafana/grafana/issues/19585?email_source=notifications&email_token=AACEVV4YMCESH5G7XWTY3QLQP4XHPA5CNFSM4I42J4CKYY3PNVWWK3TUL52HS4DFVREXG43VMDVNBW63 ,
o darse de baja
https://github.com/notifications/unsubscribe-auth/AACEVV3OBIAWAV3ZNAP4XEDQP4XHPANCNFSM4I42J4CA
.

uname -a
Linux raspberrypi4 4.19.75-v7l+ #1270 SMP Tue Sep 24 18:51:41 BST 2019 armv7l GNU/Linux

frambuesa pi 4b

docker -v
Docker version 19.03.4, build 9013bf5

• [x] Verifique que el contenedor se pueda ejecutar correctamente y que el uso de registros de la ventana acoplable no debería generar nada inesperado, como errores
• [X] si es posible, intente agregar / conectarse a una fuente de datos y renderizar un tablero / panel (influxdb con panel gráfico
• [] Opcional: verifique que pueda descargar / instalar complementos

LGTM: frambuesa pi 4

$ uname -a
Linux worker-3 4.19.75-v7l+ #1270 SMP Tue Sep 24 18:51:41 BST 2019 armv7l GNU/Linux

• [x] Verifique que el contenedor se pueda ejecutar correctamente y que el uso de registros de la ventana acoplable no debería generar nada inesperado, como errores
• [x] si es posible, intente agregar / conectarse a una fuente de datos y renderizar un tablero / panel (influxdb, prometheus, loki)
• [x] Verifique que pueda descargar / instalar complementos (raintank-worldping-app, grafana-kubernetes-app, devopsprodigy-kubegraf-app, grafana-piechart-panel)

LGTM

rockchip rock64

$ uname -a
Linux rock64 4.4.132-1072-rockchip-ayufan-ga1d27dba5a2e #1 SMP Sat Jul 21 20:18:03 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux

• [x] Verifique que el contenedor se pueda ejecutar correctamente y que el uso de registros de la ventana acoplable no debería generar nada inesperado, como errores
• [x] si es posible, intente agregar / conectarse a una fuente de datos y renderizar un tablero / panel (influxdb, prometheus, loki)
• [] Verifique que pueda descargar / instalar complementos (raintank-worldping-app, grafana-kubernetes-app, devopsprodigy-kubegraf-app, grafana-piechart-panel)

Nivel de habilidad de Docker
Novato
Nivel de habilidad de Grafana
Novato
-uname -a
Linux SwingerPictureServer 4.19.75-v7 + # 1270 SMP ........... armv71 GNU / Linux
HW
Frambuesa pi 3B
archivo compose.sh:
Docker ejecutar \
--nombre Grafana_test \
-p 3001: 3001 \
-e "GF_SERVER_ROOT_URL = http: //: 3001 "\
-e "GF_SECURITY_ADMIN_PASSOWRD ="\
--mount type = bind, source = "/ home / pi / DockerConf / Grafana / test / config", target = "/ etc / grafana": ro \
grafana / grafana-arm32v7- linux: dev-musl

Archivo de registro:
warn: msg = "phantomJS está obsoleto y se eliminará en la versión futura ...

Gracias a todos. Hemos fusionado esto para master, pero decidimos incluir esta corrección en Grafana v6.5.0, que se lanzará en un par de semanas. Hasta entonces, puede usar compilaciones nocturnas si desea ejecutar imágenes acoplables de Grafana compatibles con Grafana v6.5-pre ARM mediante la etiqueta grafana/grafana:master .

Agregue una nota a Docker Hub para que sea más fácil encontrar este problema. Si actualmente está extrayendo grafana / grafana, todavía obtiene una imagen no funcional en armhf.

Solo comentando para tener en cuenta que grafana / grafana-arm32v7- linux: latest ahora funciona bien para mí (esta imagen ), así que he desanclado versiones 👍

@mhansen puedes usar directamente la imagen base (grafana / grafana: última), es multiarca :)

Actualmente estoy usando grafana / grafana: 6.5.1@sha256 : befcd84da2c1f3310b23d93ba9eec4a80df4c86c04bd39455623ac632fbcefdd en un clúster ARM.

@theWaldschrat @pedroetb @mhansen @herm @SySfRaMe @ krystian-wojtas @pgolm @gcgarner @JochenLutz @iwittkau @JasonSwindle @ protik77 @ ata4 Nos vendría bien un poco de ayuda para probar nuevas compilaciones (imágenes de Docker y archivos tar) en varias arquitecturas ARM, ¿podría ¿ayudar? ¡Lo apreciaríamos!

Las imágenes de Docker en cuestión

• grafana / grafana-arm64v8- linux: master-df1d43167af035c6819923ecce135056f37c79c2-new-pipeline
• grafana / grafana-arm64v8- linux: master-df1d43167af035c6819923ecce135056f37c79c2-ubuntu-new-pipeline
• grafana / grafana-arm32v7- linux: master-df1d43167af035c6819923ecce135056f37c79c2-new-pipeline
• grafana / grafana-arm32v7- linux: master-df1d43167af035c6819923ecce135056f37c79c2-ubuntu-new-pipeline

Los archivos de alquitrán en cuestión

Los archivos MUSL son para Alpine Linux, los de GLIBC son para distribuciones regulares de Linux:

• ARM64 / MUSL
• ARM64 / GLIBC
• ARMv6 / GLIBC
• ARMv7 / MUSL
• ARMv7 / GLIBC

RPM

• ARM64
• ARMv7

Imagen de Docker
grafana / grafana-arm64v8- linux: master-df1d43167af035c6819923ecce135056f37c79c2-new-pipeline funciona bien en Raspberry Pi 4B con Kernel 4.19.97-v8 + y Docker CE 19.03.5.

¡Gracias @volschin!

Tuve un problema con el contenedor hoy después de ejecutar aproximadamente 24 horas (sin inicio de plantilla). Esto no es nada de lo que sucedió en los últimos meses. Entonces, tal vez haya un problema de estabilidad.

Tuve un problema con el contenedor hoy después de ejecutar aproximadamente 24 horas (sin inicio de plantilla). Esto no es nada de lo que sucedió en los últimos meses. Entonces, tal vez haya un problema de estabilidad.

¿Qué tipo de problema vio exactamente @volschin?

@ aknuds1 lo siento,

No tengo ningún método automatizado, lo siento @iwittkau.

Ya no veo grafana / grafana: latest como multiarch, solo amd64 / linux.

$ docker run --rm mplatform/mquery grafana/grafana
Image: grafana/grafana
 * Manifest List: No
 * Supports: amd64/linux

Me cambié a grafana / grafana: master

Ya no veo grafana / grafana: latest como multiarch, solo amd64 / linux.

$ docker run --rm mplatform/mquery grafana/grafana
Image: grafana/grafana
 * Manifest List: No
 * Supports: amd64/linux

Me cambié a grafana / grafana: master

@mhansen Interesante, gracias por el

Por lo que vale, estoy usando grafana/grafana-arm32v7-linux:latest por ahora. Aunque instaló 6.7.1.