Grafana: Docker: les images ARM ne fonctionnent pas depuis la v6.4.x

Merci d'avoir signalé cela @theWaldschrat, nous l'

@theWaldschrat quel appareil utilisez-vous? S'agit-il d'une architecture 32 ou 64 bits (armv6m armv7, armv8, etc.)?

Peut-être que nous devons inclure https://pkgs.alpinelinux.org/package/edge/main/armhf/libc6-compat dans l'image docker Grafana?

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

@theWaldschrat pouvez-vous confirmer que ci-dessus résout le problème? Il est plus difficile pour nous de vérifier sans avoir accès à un appareil ARM réel.L'image de bras basée sur un docker peut être une possibilité, mais appréciez si vous pouvez nous aider ici. Merci

L'appareil est un Raspberry Pi 4B. Techniquement, c'est un ARM64v8, mais Raspbian exécute par défaut un noyau et un espace utilisateur 32 bits, donc ARM32v7.

uname -a
OS hôte:
Linux raspberrypi 4.19.66-v7l+ #1253 SMP Thu Aug 15 12:02:08 BST 2019 armv7l GNU/Linux
Image 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
Image Grafana 6.4.X (dernière):
Linux 84a01cb75816 4.19.66-v7l+ #1253 SMP Thu Aug 15 12:02:08 BST 2019 armv7l Linux

Je n'ai pas encore construit beaucoup d'images Docker, donc je ne peux pas essayer la commande ci-dessus dans une nouvelle image, du moins pas rapidement. Mais ce que j'ai fait: Exécuter un grafana: dernier conteneur avec point d'entrée bash et user root:
docker run -it -p 3001:3000 --entrypoint="bash" --user=root grafana/grafana
Voici le résultat:

• L'exécution manuelle de /run.sh donne le même message d'erreur, donc c'est confirmé.
• Exécuter la commande ci-dessus: aucune erreur.
• Exécutez à nouveau /run.sh: Nouveaux messages d'erreur:

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

• Lancer ldd /usr/share/grafana/bin/grafana-server ne se plaint plus des bibliothèques manquantes, mais donne les mêmes résultats que ci-dessus.

Je ne suis pas un expert, mais je suppose que les lib-c ne sont toujours pas compatibles.

@theWaldschrat merci très utile.

Juste pour vérifier certaines choses supplémentaires, vous pouvez les essayer spécifiquement pour vérifier que vous rencontrez le même problème:
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

Pour être sûr, pouvez-vous également essayer d'exécuter et de démarrer grafana-server:
docker run -it -p 3001:3000 --entrypoint="bash" --user=root grafana/grafana-arm64v8-linux:6.4.1

Les deux premiers font tous la même chose que celle décrite précédemment.
Lancer /run.sh ou directement /usr/share/grafana/bin/grafana-server ne fait aucune différence.

Le troisième ne commence même pas par une discordance d'arche:
standard_init_linux.go:211: exec user process caused "exec format error"

J'ai le même problème et j'ai dû passer à la version 6.3.6 , il semble donc que toutes les images 6.4.x basées sur Alpine sont cassées pour ARMv7.

Merci. Après avoir entré bash, pouvez-vous essayer d'installer le packade musl-dev en utilisant apk add?

musl-dev s'installe bien pour moi, mais n'a pas d'impact sur le problème, avec ou sans libc6-compat .

L'installation des apks de la glibc depuis https://github.com/armhf-docker-library/alpine-pkg-glibc/releases permet à grafana-server de démarrer. Si je comprends bien le problème, il est préférable de lier statiquement les binaires avec musl.

C'est l'idée d'Alpine de se lier statiquement à musl au lieu d'un lien glibc dynamique. C'est plus rapide, plus petit, plus stable et potentiellement plus sécurisé. Du moins c'est ce qu'ils disent.
Mais pour autant que je puisse voir, Grafana est construit en dehors de l'image cible liée à la glibc, c'est donc probablement la meilleure idée d'installer la glibc comme ci-dessus ou d'utiliser une image de base différente qui inclut déjà la glibc.

Considérant que ce changement a effectivement cassé l'image du docker pour les appareils ARM, je m'attendais à quelque chose de mieux qu'une balise «enquête sur les besoins».

Soupir! La malédiction du "développement agile", je suppose.

Je peux reproduire l'erreur sous OS X, même si elle est un peu différente du vôtre:

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

Je verrai si je peux le réparer.

Je pourrais avoir une piste sur la cause profonde de ce problème, en espérant pouvoir le résoudre demain.

Travailler pour résoudre ce problème en construisant des binaires musl en plus de ceux de la glibc.

Je viens de rencontrer cela aussi. Mon système est aarch64 (RockPro64) et j'obtiens la même erreur:

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

Sur la base du travail de # 19798, nous avons poussé une balise nommée dev-musl dans les référentiels du hub grafana docker. Nous n'avons pu tester que les images docker arm et arm64 à l'aide de l'émulation.Nous demandons donc à quiconque de bien vouloir vous aider à tester les images docker arm et arm64 pour vérifier qu'elles fonctionnent comme prévu. Aucun manifeste n'a été poussé vers grafana / grafana, donc si vous voulez essayer arm ou arm64, vous devez spécifier manuellement le référentiel correct, voir ci-dessous.

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

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

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

Veuillez noter que ces images sont basées sur la branche de développement actuelle (master / Grafana v6.5.0-pre) de Grafana, donc si vous souhaitez tester avec une installation Grafana existante, n'oubliez pas de sauvegarder vos données existantes .

Portée du test:

• Vérifiez que le conteneur peut s'exécuter correctement et que l'utilisation de docker logs <image name> ne doit pas générer de résultat inattendu, comme des erreurs.
• Si possible, essayez d'ajouter / de vous connecter à une source de données et de rendre un tableau de bord / panneau
• Facultatif: vérifiez que vous pouvez télécharger / installer des plugins
• Donnez votre avis dans ce numéro ou dans le PR # 19798 en faisant un commentaire indiquant le périphérique / l'architecture que vous avez utilisé et le résultat.

Merci d'avance

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

LGTM fonctionnant sur un Raspberry 3B

• [x] Vérifiez que le conteneur peut s'exécuter correctement et utiliser les journaux du dockerne devrait rien afficher d'inattendu comme des erreurs.
• [x] Si possible, essayez d'ajouter / de vous connecter à une source de données et de rendre un tableau de bord / un panneau
• [x] Facultatif: vérifiez que vous pouvez télécharger / installer des plug-ins

SBC: Cubietruck (alias CubieBoard 3)

$ uname -a
Linux fernia 4.19.62-sunxi # 5.92 SMP mercredi 31 juillet 22:07:23 CEST 2019 armv7l armv7l armv7l GNU / Linux

LGTM

• [x] Vérifiez que le conteneur peut s'exécuter correctement et que l'utilisation des journaux de docker ne doit pas générer de résultat inattendu comme des erreurs.
• [x] Si possible, essayez d'ajouter / de vous connecter à une source de données et de rendre un tableau de bord / un panneau
• [x] Facultatif: vérifiez que vous pouvez télécharger / installer des plug-ins

Merci beaucoup pour les réponses rapides et l'aide. Très apprécié.

D'accord, merci d'avoir aidé à tester!

Le mar 22 octobre 2019, 19:05 Marcus Efraimsson [email protected]
a écrit:

Merci beaucoup pour les réponses rapides et l'aide. Très apprécié.

-
Vous recevez cela parce que vous avez été affecté.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/grafana/grafana/issues/19585?email_source=notifications&email_token=AACEVV4YMCESH5G7XWTY3QLQP4XHPA5CNFSM4I42J4CKYY3PNVWWK3TUL52HS4YMCESH5G7XWTY3QLQP4XHPA5CNFSM4I42J4CKYY3PNVWWK3TUL52HS4YMCESH5G7XWTY3QLQP4XHPA5CNFSM4I42J4CKYY3PNVWWK3TUL52HS4VMVFVOMBX63NVWWK3TUL52HS4VMVFVOMX63NVWWK3TUL52HS4VMVLOX63
ou se désinscrire
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

framboise pi 4b

docker -v
Docker version 19.03.4, build 9013bf5

• [x] Vérifiez que le conteneur peut s'exécuter correctement et que l'utilisation des journaux Docker ne doit pas générer de résultat inattendu comme des erreurs
• [X] si possible, essayez d'ajouter / de vous connecter à une source de données et de rendre un tableau de bord / panneau (influxdb avec panneau graphique
• [] Facultatif: vérifiez que vous pouvez télécharger / installer des plug-ins

LGTM: framboise 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] Vérifiez que le conteneur peut s'exécuter correctement et que l'utilisation des journaux Docker ne doit pas générer de résultat inattendu comme des erreurs
• [x] si possible, essayez d'ajouter / de vous connecter à une source de données et de rendre un tableau de bord / panneau (influxdb, prometheus, loki)
• [x] Vérifiez que vous pouvez télécharger / installer des plugins (raintank-worldping-app, grafana-kubernetes-app, devopsprodigy-kubegraf-app, grafana-fragment-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] Vérifiez que le conteneur peut s'exécuter correctement et que l'utilisation des journaux Docker ne doit pas générer de résultat inattendu comme des erreurs
• [x] si possible, essayez d'ajouter / de vous connecter à une source de données et de rendre un tableau de bord / panneau (influxdb, prometheus, loki)
• [] Vérifiez que vous pouvez télécharger / installer des plugins (raintank-worldping-app, grafana-kubernetes-app, devopsprodigy-kubegraf-app, grafana-fragment-panel)

Niveau de compétence Docker
Noob
Niveau de compétence Grafana
Noob
-uname -a
Linux SwingerPictureServer 4.19.75-v7 + # 1270 SMP ........... armv71 GNU / Linux
HW
Framboise pi 3B
Fichier compose.sh:
docker run \
--name 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

Fichier journal:
warn: msg = "phantomJS est obsolète et sera supprimé dans la prochaine version ...

Merci a tous. Nous avons fusionné cela pour master, mais avons décidé d'inclure ce correctif dans Grafana v6.5.0, qui sera publié dans quelques semaines. Jusque-là, vous pouvez utiliser des builds nocturnes si vous souhaitez exécuter des images docker Grafana compatibles Grafana v6.5-pre ARM en utilisant la balise grafana/grafana:master .

Veuillez ajouter une note à Docker Hub afin qu'il soit plus facile de trouver ce problème. Si vous tirez actuellement grafana / grafana, vous obtenez toujours une image non fonctionnelle sur armhf.

Il suffit de commenter pour noter que grafana / grafana-arm32v7- linux: latest fonctionne maintenant très bien pour moi (cette image ), donc j'ai des versions non épinglées 👍

@mhansen vous pouvez utiliser directement l'image de base (grafana / grafana: dernier), c'est multiarch :)

J'utilise actuellement grafana / grafana: 6.5.1@sha256 : befcd84da2c1f3310b23d93ba9eec4a80df4c86c04bd39455623ac632fbcefdd dans un cluster ARM.

@theWaldschrat @pedroetb @mhansen @herm @SySfRaMe @ krystian-wojtas @pgolm @gcgarner @JochenLutz @iwittkau @JasonSwindle @ protik77 @ ata4 nous pourrions utiliser de l'aide pour tester de nouveaux architectures de builds (images Docker et archives

Les images Docker en question

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

Les archives tar en question

Les archives MUSL sont pour Alpine Linux, celles GLIBC sont pour les distributions Linux classiques:

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

RPM

• ARM64
• ARMv7

Image Docker
grafana / grafana-arm64v8- linux: master-df1d43167af035c6819923ecce135056f37c79c2-new-pipeline fonctionne

Merci @volschin!

J'ai eu un problème avec le conteneur aujourd'hui après avoir fonctionné environ 24h (pas de création de modèles). Ce n'est rien de ce qui s'est passé ces derniers mois. Il y a donc peut-être un problème de stabilité.

J'ai eu un problème avec le conteneur aujourd'hui après avoir fonctionné environ 24h (pas de création de modèles). Ce n'est rien de ce qui s'est passé ces derniers mois. Il y a donc peut-être un problème de stabilité.

Quel genre de problème avez-vous vu exactement @volschin?

@ aknuds1 désolé, je n'ai pas encore réussi à tester complètement les nouvelles images du bras docker. Existe-t-il un moyen d'automatiser les tests?

Je n'ai pas de méthode automatisée, désolé @iwittkau.

Je ne vois plus grafana / grafana: le dernier étant multiarch, seulement amd64 / linux.

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

Je suis passé à grafana / grafana: master

Je ne vois plus grafana / grafana: le dernier étant multiarch, seulement amd64 / linux.

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

Je suis passé à grafana / grafana: master

@mhansen Intéressant, merci pour la mise en

Pour ce que ça vaut, j'utilise grafana/grafana-arm32v7-linux:latest pour le moment. Bien qu'il ait installé 6.7.1.