Add arm5/6/7 docker images

[martini1992]

Based on the comment here https://www.reddit.com/r/selfhosted/comments/ukhcae/scrutiny_beta_release_needs_testers_hard_drive/i7xv9w3/

Request to add other ARM arch's to the docker images (for me armv7)

[martini1992]

Also FYI getting an email when posting a new issue warning that "Label sponsors workflow run" failed, don't know if that is a misconfiguration of some Github settings.

[AnalogJ]

Hey @martini1992 thanks for the PR.

This might be harder than I initially thought. There doesn't seem to be an arm32v7 binary for influxDB, and I really don't want to compile it from source.

[AnalogJ]

Also, thanks for the heads up regarding the Label sponsors workflow, I've fixed that issue.

[martini1992]

No problem, and yeah the lack of official builds does seem to be an issue. It might be worth compiling though (or using the repo listed in your link) because I can see people using (like me) ARMv7 NAS boards or the ever popular RaspberryPi, especially since (I assume) you plan to stop supporting the SQLite3 version.

Unless there could be a simple port back to influxdb 1.x which does support those older arch's, purely to allow those arch's to use this software.

[AnalogJ]

Yeah, the issue with using that unofficial pre-compiled package is that it will make my Dockerfile a lot more complicated.
I'd like to support this, but I may have to back-burner this issue for a bit (there's alot of UI related TODO's).

[martini1992]

OK, would a viable workaround be to run the collector on the ARMv7 machine and the web and db components on a separate x86_64 machine? In which case building ARMv7 etc images for the components you can might be worth it?

[AnalogJ]

Fair point. I've gone ahead and created linux/arm/v7 versions of the web and collector docker images. You could technically run the webapp and collectors on the ARM machine, and use a x86_64 (or cloudhosted) version of Influxdb.

[martini1992]

Excellent, thank you. You might want to update the compatibility table in the README.md and add a note about the lack of omnibus support.

[Canhobix]

Hello Gents,

Any update on the ARM7 support ?
I'm getting this error when I try to deploy using composer.

failed to deploy a stack: influxdb Pulling web Pulling collector Pulling web Error collector Error no matching manifest for linux/arm/v7 in the manifest list entries

[AnalogJ]

Hey @Canhobix Scrutiny does create ARM7 images, however the InfluxDB image (maintained by the InfluxDB developers) does not have an ARM7 version, which is the failure you're seeing.

Though.. I just found:

• https://hub.docker.com/r/arm32v7/influxdb/
• https://hub.docker.com/r/arm64v8/influxdb/

Does one of those work for you?

[martadinata666]

After looking around armv7 support is influxdb v1.8, and the v2 only arm64 or amd64. Does scrutiny work with influxdb 1.8?

[AnalogJ]

Unfortunately not, Scrutiny requires InfluxDB v2

[Canhobix]

Hey @Canhobix Scrutiny does create ARM7 images, however the InfluxDB image (maintained by the InfluxDB developers) does not have an ARM7 version, which is the failure you're seeing.

Though.. I just found:

• https://hub.docker.com/r/arm32v7/influxdb/
• https://hub.docker.com/r/arm64v8/influxdb/

Does one of those work for you?

Hello AnalogJ,

I'm getting this error from both influxdb.
From the arm64v8 I got this: WARNING: The requested image's platform (linux/arm64/v8) does not match the detected host platform (linux/arm/v7) and no specific platform was requested
exec /entrypoint.sh: exec format error
From the arm32v7 I got this: docker: Error response from daemon: manifest for arm32v7/influxdb:2.0 not found: manifest unknown: manifest unknown.

Thank you so much, I will wait to see if someone update the arm32v7 to 2.0

Cheers

[jesuslop]

Though this is two years closed, google send me always here for this problem. I got Scrutiny running in armhf (or armv7 or arm32) with the help of a kind soul that has created a dockerized builder to generate influx 2 packages, and for the laziest even has some binary debian package releases. So in my case I have influx 2 installed on armhf with dpkg running on my host as any other package, and have a collector and a scrutiny-web containers defined in docker compose, that talk to influx in the host by using host-type networking in the containers. Just in case, pay some attention to the tradeoff of security implications that go with using unevenly maintaned software. An example of docker compose file:

common.yaml:

version: '3.3'
services:
    base:
        user: 1000:1000
        restart: always

    environment:
      - TZ=Europe/Madrid

scrutiny.yaml:

services:
  scrutiny-web:
    extends:
      file: common.yaml
      service: base
    image: ghcr.io/analogj/scrutiny:master-web
    container_name: scrutiny-web
    environment:
      - SCRUTINY_WEB_INFLUXDB_HOST=nas
    volumes:
      - ./app-configs/scrutiny/:/opt/scrutiny/config
    network_mode: host
    healthcheck:
      test: ["CMD", "curl", "-f", "http://nas:8085/api/health"]
      interval: 10m
      timeout: 30s
      retries: 3
      start_period: 10s

  scrutiny-collector:
    extends:
      file: common.yaml
      service: base
    image: ghcr.io/analogj/scrutiny:master-collector
    user: '0'
    cap_add:
      - SYS_RAWIO
      - SYS_ADMIN
    volumes:
      - /run/udev:/run/udev:ro
      - ./app-configs/scrutiny/:/opt/scrutiny/config
    network_mode: host
    environment:
      COLLECTOR_API_ENDPOINT: 'http://nas:8085'
      COLLECTOR_HOST_ID: 'scrutiny-collector-hostname'
    depends_on:
      scrutiny-web:
        condition: service_healthy
    devices:
      - /dev/sda