Grafana: Docker: as imagens ARM não funcionam desde a v6.4.x

Criado em 2 out. 2019  ·  39Comentários  ·  Fonte: grafana/grafana

O que aconteceu :
O Grafana 6.4.X ARM no Docker não funciona no Raspbian Buster.
Mensagem de erro ao tentar executar o contêiner:
/run.sh: linha 80: / usr / share / grafana / bin / grafana-server: Não existe esse arquivo ou diretório

O que você esperava que acontecesse :
Óbvio: o Grafana é executado sem erros.

Como reproduzi-lo (o mínimo e precisamente possível) :
docker run grafana / grafana

Mais alguma coisa que precisamos saber? :
O erro é causado por uma incompatibilidade de lib-c: Grafana é compilado com ld-linux-armhf.so, mas a imagem base Alpine contém apenas ld-musl-armv7.so.

Meio Ambiente :

  • Versão Grafana: 6.4.X
  • Tipo e versão da fonte de dados: InfluxDB
  • OS Grafana está instalado em: Raspbian Buster com Docker
  • Sistema operacional e navegador do usuário: Windows / Firefox
  • Plug-ins Grafana: Nenhum
  • Outros: Nenhum
aredocker typbug

Comentários muito úteis

Obrigado a todos. Nós mesclamos isso com o master, mas decidimos incluir essa correção no Grafana v6.5.0, que será lançado em algumas semanas. Até lá, você pode usar compilações noturnas se quiser executar imagens do Grafana compatíveis com Grafana v6.5-pre ARM usando a tag grafana/grafana:master .

Todos 39 comentários

Obrigado por relatar este @theWaldschrat , iremos investigá-lo melhor

@theWaldschrat qual dispositivo você está usando? É uma arquitetura de 32 ou 64 bits (armv6m armv7, armv8 etc)?

Talvez seja necessário incluir https://pkgs.alpinelinux.org/package/edge/main/armhf/libc6-compat na imagem docker do Grafana?

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

@theWaldschrat você pode confirmar que acima resolve o problema? É mais difícil para nós verificarmos sem acesso a um dispositivo ARM real. A imagem do braço baseada no dock pode ser uma possibilidade, mas agradecemos se você pode nos ajudar aqui. obrigado

O dispositivo é um Raspberry Pi 4B. Tecnicamente, é um ARM64v8, mas o Raspbian por padrão roda um kernel e userland de 32 bits, então ARM32v7.

uname -a
SO host:
Linux raspberrypi 4.19.66-v7l+ #1253 SMP Thu Aug 15 12:02:08 BST 2019 armv7l GNU/Linux
Imagem 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
Imagem Grafana 6.4.X (mais recente):
Linux 84a01cb75816 4.19.66-v7l+ #1253 SMP Thu Aug 15 12:02:08 BST 2019 armv7l Linux

Eu não construí muitas imagens do Docker ainda, então não posso tentar o comando acima em uma nova imagem, pelo menos não rapidamente. Mas o que eu fiz: Executei um
docker run -it -p 3001:3000 --entrypoint="bash" --user=root grafana/grafana
Aqui está o resultado:

  • Executar manualmente /run.sh dá a mesma mensagem de erro, então isso é confirmado.
  • Executar o comando acima: Sem erro.
  • Execute novamente /run.sh: Novas mensagens de erro:
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
  • A execução de ldd /usr/share/grafana/bin/grafana-server não reclama mais sobre a falta de bibliotecas, mas fornece os mesmos resultados acima.

Não sou um especialista, mas acho que os lib-c ainda não são compatíveis.

@theWaldschrat obrigado muito útil.

Apenas para verificar algumas coisas adicionais, você pode tentar especificamente estas para verificar se você obtém o mesmo 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

Para ter certeza, você também pode tentar executar e iniciar o grafana-server:
docker run -it -p 3001:3000 --entrypoint="bash" --user=root grafana/grafana-arm64v8-linux:6.4.1

Os dois primeiros fazem o mesmo conforme descrito anteriormente.
Executar /run.sh ou diretamente /usr/share/grafana/bin/grafana-server não faz diferença.

O terceiro nem começa com uma incompatibilidade de arco:
standard_init_linux.go:211: exec user process caused "exec format error"

Eu tenho o mesmo problema e tive que fazer o downgrade para a versão 6.3.6 , então parece que todas as imagens 6.4.x baseadas em Alpine estão corrompidas para ARMv7.

Obrigado. Depois de inserir o bash, você pode tentar instalar o pacote musl-dev usando apk add?

musl-dev instala bem para mim, mas não tem impacto no problema, com ou sem libc6-compat .

Instalar os apks glibc de https://github.com/armhf-docker-library/alpine-pkg-glibc/releases permite que grafana-server seja iniciado. Se bem entendi o problema, é melhor vincular estaticamente os binários ao musl.

É ideia da Alpine vincular estaticamente a musl em vez de vinculação glibc dinâmica. É mais rápido, menor, mais estável e potencialmente mais seguro. Pelo menos é o que dizem.
Mas, pelo que posso ver, o Grafana é construído fora da imagem de destino vinculando com a glibc, então é provavelmente a melhor ideia instalar a glibc como acima ou usar uma imagem base diferente que já inclua a glibc.

Considerando que essa mudança quebrou efetivamente a imagem do docker para dispositivos ARM, eu esperava algo melhor do que uma etiqueta de "investigação precisa".

Suspiro! A maldição do "desenvolvimento ágil", eu acho.

Posso reproduzir o erro no OS X, embora pareça um pouco diferente do seu:

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

Vou ver se consigo consertar.

Posso ter uma pista sobre a causa raiz desse problema, esperando poder corrigi-lo amanhã.

Trabalhando para resolver isso criando binários musl além dos glibc.

Apenas corri para isso também. Meu sistema é aarch64 (RockPro64) e estou recebendo o mesmo erro:

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

Com base no trabalho em # 19798, enviamos uma tag chamada dev-musl aos repositórios de hub do docker da grafana. Só conseguimos testar a execução das imagens do docker arm e arm64 usando emulação, por isso pedimos gentilmente a todos que nos ajudem a testar as imagens docker arm e arm64 para verificar se funcionam conforme o esperado. Nenhum manifesto foi enviado para grafana / grafana, portanto, se você quiser tentar arm ou arm64, deverá especificar manualmente o repositório correto, veja abaixo.

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

Observe que essas imagens são baseadas no ramo de desenvolvedor atual (master / Grafana v6.5.0-pre) do Grafana, portanto, se você quiser testar com uma instalação Grafana existente, lembre-se de fazer backup dos dados existentes .

Escopo do teste:

  • Verifique se o contêiner pode ser executado com êxito e o uso de docker logs <image name> não deve gerar nada inesperado, como erros.
  • Se possível, tente adicionar / conectar a uma fonte de dados e renderizar um painel / painel
  • Opcional: verifique se você pode baixar / instalar plug-ins
  • Forneça feedback sobre esta edição ou PR # 19798 fazendo um comentário informando qual dispositivo / arquitetura você usou e o resultado.

desde já, obrigado

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

LGTM rodando em um Raspberry 3B

  • [x] Verifique se o contêiner pode ser executado com êxito e usando logs do dockernão deve produzir nada inesperado como erros.
  • [x] Se possível, tente adicionar / conectar a uma fonte de dados e renderizar um painel / painel
  • [x] Opcional: verifique se você pode baixar / instalar plug-ins

SBC: Cubietruck (também conhecido como CubieBoard 3)

$ uname -a
Linux fernia 4.19.62-sunxi # 5.92 SMP Quarta, 31 de julho 22:07:23 CEST 2019 armv7l armv7l armv7l GNU / Linux

LGTM

  • [x] Verifique se o contêiner pode ser executado com êxito e o uso de logs do docker não deve gerar nada inesperado como erros.
  • [x] Se possível, tente adicionar / conectar a uma fonte de dados e renderizar um painel / painel
  • [x] Opcional: verifique se você pode baixar / instalar plug-ins

Muito obrigado pelas respostas rápidas e ajuda. Muito apreciado.

Concordo, obrigado por ajudar no teste!

Em ter, 22 de outubro de 2019, 19:05 Marcus Efraimsson [email protected]
escrevi:

Muito obrigado pelas respostas rápidas e ajuda. Muito apreciado.

-
Você está recebendo isto porque foi designado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/grafana/grafana/issues/19585?email_source=notifications&email_token=AACEVV4YMCESH5G7XWTY3QLQP4XHPA5CNFSM4I42J4CKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEB6PL5A#issuecomment-545060340 ,
ou cancelar
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

framboesa pi 4b

docker -v
Docker version 19.03.4, build 9013bf5
  • [x] Verifique se o contêiner pode ser executado com êxito e o uso de registros do docker não deve gerar nada inesperado, como erros
  • [X] se possível, tente adicionar / conectar a uma fonte de dados e renderizar um painel / painel (influxdb com painel gráfico
  • [] Opcional: verifique se você pode baixar / instalar plug-ins

LGTM: framboesa 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 se o contêiner pode ser executado com êxito e o uso de registros do docker não deve gerar nada inesperado, como erros
  • [x] se possível, tente adicionar / conectar a uma fonte de dados e renderizar um painel / painel (influxdb, prometheus, loki)
  • [x] Verifique se você pode baixar / instalar plug-ins (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 se o contêiner pode ser executado com êxito e o uso de registros do docker não deve gerar nada inesperado, como erros
  • [x] se possível, tente adicionar / conectar a uma fonte de dados e renderizar um painel / painel (influxdb, prometheus, loki)
  • [] Verifique se você pode baixar / instalar plug-ins (raintank-worldping-app, grafana-kubernetes-app, devopsprodigy-kubegraf-app, grafana-piechart-panel)

Nível de habilidade do Docker
Novato
Nível de habilidade Grafana
Novato
-uname -a
Linux SwingerPictureServer 4.19.75-v7 + # 1270 SMP ........... armv71 GNU / Linux
HW
Framboesa pi 3B
arquivo 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

Arquivo de log:
warn: msg = "phantomJS está obsoleto e será removido na versão futura ...

Obrigado a todos. Nós mesclamos isso com o master, mas decidimos incluir essa correção no Grafana v6.5.0, que será lançado em algumas semanas. Até lá, você pode usar compilações noturnas se quiser executar imagens do Grafana compatíveis com Grafana v6.5-pre ARM usando a tag grafana/grafana:master .

Adicione uma nota ao hub do docker para que seja mais fácil encontrar este problema. Se você estiver puxando grafana / grafana, ainda obterá uma imagem não funcional no armhf.

Apenas comentando para observar que grafana / grafana-arm32v7- linux: mais recente agora funciona bem para mim (esta imagem ), então desmarquei as versões 👍

@mhansen você pode usar diretamente a imagem base (grafana / grafana: mais recente), é multiarca :)

Atualmente, estou usando grafana / grafana: 6.5.1@sha256 : befcd84da2c1f3310b23d93ba9eec4a80df4c86c04bd39455623ac632fbcefdd em um cluster ARM.

@theWaldschrat @pedroetb @mhansen @herm @SySfRaMe @ krystian-wojtas @pgolm @gcgarner @JochenLutz @iwittkau @JasonSwindle @ protik77 @ ata4 poderíamos usar alguma ajuda para testar novas construções (imagens Docker e arquivos tar) em várias arquiteturas ARM dar uma mão? Nós agradeceríamos!

As imagens Docker em questão

Os arquivos tar em questão

Os arquivos MUSL são para Alpine Linux, os GLIBC são para distros regulares do Linux:

RPMs

Imagem Docker
grafana / grafana-arm64v8- linux: master-df1d43167af035c6819923ecce135056f37c79c2-new-pipeline funciona bem no Raspberry Pi 4B com Kernel 4.19.97-v8 + e Docker CE 19.03.5.

Obrigado @volschin!

Tive um problema com o contêiner hoje depois de rodar cerca de 24h (sem init de templates) Isso não é nada que aconteceu nos últimos meses. Portanto, talvez haja um problema de estabilidade.

Tive um problema com o contêiner hoje depois de rodar cerca de 24h (sem init de templates) Isso não é nada que aconteceu nos últimos meses. Portanto, talvez haja um problema de estabilidade.

Que tipo de problema você viu exatamente @volschin?

@ aknuds1 desculpe, ainda não

Não tenho nenhum método automatizado, desculpe @iwittkau.

Não estou mais vendo grafana / grafana: mais recente como multiarch, apenas amd64 / linux.

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

Eu mudei para grafana / grafana: mestre

Não estou mais vendo grafana / grafana: mais recente como multiarch, apenas amd64 / linux.

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

Eu mudei para grafana / grafana: mestre

@mhansen Interessante, obrigado pelo

Para constar, estou usando grafana/grafana-arm32v7-linux:latest por enquanto. Embora tenha instalado 6.7.1.

Esta página foi útil?
0 / 5 - 0 avaliações