Small Ookla Speedtest container

aboulfad · Wed Dec 13, 2023 10:41 pm

I packaged ookla's speedtest (arm64) & with few tweaks I was able to get it running. Kudos to @tangent's work and docs, as my Dockerfile is inspired by @tangent’s iperf3 one. The size of this image is roughly the size of the speedtest static binary (~ 2.5M)

FROM alpine:latest AS build
RUN wget -O speedtest.tgz \
	"https://install.speedtest.net/app/cli/ookla-speedtest-1.2.0-linux-aarch64.tgz" \
	&& tar zxvf speedtest.tgz \
	&& chmod +x speedtest && chown root:root speedtest
RUN rm speedtest.tgz
RUN wget https://curl.se/ca/cacert.pem

From scratch
COPY --from=build /speedtest /bin/
COPY --from=build /cacert.pem /

ENTRYPOINT ["/bin/speedtest", "--accept-license"]
CMD [ "--ca-certificate=/cacert.pem" ]

Updated test during low/no usage on router/modem. Topology: RB5009 (vanilla bridge, no routing) <-> Giga Hub <-> Internet

11:17:03 container,info,debug Speedtest by Ookla
11:17:03 container,info,debug Server: Bell Canada - ABCD (id: 12345)
11:17:03 container,info,debug ISP: Bell Canada
11:17:03 container,info,debug Idle Latency: 1.00 ms (jitter: 0.23ms, low: 0.98ms, high: 1.84ms)
11:17:08 container,info,debug r Download: 1610.22 Mbps (data used: 727.5 MB)
11:17:08 container,info,debug 4.63 ms (jitter: 0.39ms, low: 2.96ms, high: 6.66ms)
11:17:18 container,info,debug r Upload: 1015.11 Mbps (data used: 1.2 GB)
11:17:18 container,info,debug 13.60 ms (jitter: 1.53ms, low: 3.69ms, high: 24.74ms)
11:17:18 container,info,debug Packet Loss: 0.0%
11:17:18 container,info,debug Result URL: https://www.speedtest.net/result/c/xyz

Thu Dec 14, 2023 3:59 am

I found a lot to improve in that container, resulting in a new section on my MikroTik Solutions site, here. Here's what I changed/improved:

Mine builds for all four major platforms rather than hard-code aarch64.
I unpack the client tarball on the fly to extract the single static binary I want, letting the rest of the contents go to the bit bucket. Keep in mind that with a 2-stage build like this, that isn't strictly necessary, nor is your "rm speedtest.tgz" step. Everything from the first stage goes away in the second stage, so you can leave the first stage as messy as you like.
I get the CA certificate bundle from Alpine rather than copy it in redundantly from the curl folk.
You don't need all that dancing about with chmod and chown. The tarball has the executable marked properly, and the COPY step from the build stage to the final "FROM scratch" stage resets the permissions to root.
The default operation mode for the CLI tool assumes you're running it interactively on a terminal, but under RouterOS, you can't see the cutesy ASCII art animations, so I disabled them.
I split the flags between ENTRYPOINT and CMD differently, with the intent of separating those presumed to be unchanging from those likely to be overridden. The CA cert setting step belongs to ENTRYPOINT, IMHO, not to CMD. This allows one to set cmd="--format=json" to allow easy consumption of the results by another script watching rsyslog.

Thank you for the inspiration, aboulfad. I would not have bothered producing this new container without it.

aboulfad · Thu Dec 14, 2023 12:57 pm

I thought I lost my mind when I didn’t find my post

. Thank you for creating a new thread and appreciate a lot the improvements which will give me more to learn. I had a hunch you’d find much to improve, container noob here. Containerizing is lots of fun !

I actually spent hours being stuck on 3 areas and lessons:
1- I was trying to run (specifying - platform) the arm64 binary on docker desktop under qemu emulation & speedtest would just hang on « stage 1 ». I learnt later that running a binary in a container whose arch is not natively supported on docker desktop may and will have failure. Lesson: upload to router and run.
2- I needed to figure it out a way to accept the license agreement in a headless environment when running. Mysteriously and undocumented, speedtest spit out the option for it in the router logs but not in CLI on my rpi4, it was neither documented nor in —help. Maybe I missed it…
3- The speedtest.md file mentions how to deal with the cacerts so I just blindly copied that.

toffifee · Tue Feb 27, 2024 12:53 am

I found a lot to improve in that container, resulting in a new section on my MikroTik Solutions site, here. Here's what I changed/improved:

Hi Tangent,
just tried your container, but stuck with this log message

To accept the message please run speedtest interactively or use the following: 
    speedtest --accept-gdpr

How does this work? Tried an ENVS with "OOKLA_EULA_GDPR=true" but it doesn't work.

Tue Feb 27, 2024 1:33 am

Try it again; I've added that flag to the command line.

It doesn't demand that here, but perhaps it skips that when it doesn't detect that you are in the EU.

toffifee · Tue Feb 27, 2024 10:16 am

Try it again; I've added that flag to the command line.

Cool! Thank you for this quick response, Tangent.
And for the solution, works now

Next step for me now: How to extract the results (timestamp, id, latency, download, upload, loss) from LOG and send it via MQTT... or is there anyone who did this already and may share the solution?

First issue is: How to identify these LOG records? Alle Containers use the same topic = "container, info, debug"?!?
Maybe a prefix would be usefull for a filter, e.g. all records with a leading "[speedtest]"?

toffifee · Thu Feb 29, 2024 8:04 pm

Any speedtest is just interessting, but not really helpfull without any option for an constant/frequent automated monitoring.

Something with Netwatch or automated Script-usage of the data is from my POV mandatory. But currently I'm e little bit lost how to solve this best = low performance impact and stable/easy to use. Currenttly the LOG output is not easy to filter.

* maybe it would make sense to adjust the output with a prefix to filter the log
> script for LOG screening
* maybe soemthing else is possible in the container to be usefull
> maybe a JSON output?
* other option?

toffifee · Thu Mar 14, 2024 9:13 pm

Try it again; I've added that flag to the command line.

It doesn't demand that here, but perhaps it skips that when it doesn't detect that you are in the EU.

Hi tangent,

your solution runs fine, thank you

Unfortunately one server always leads to much too low values. For this the CLI offers some parameters. Is it possible to use ENV in mikrotik container solution to bypass parameters to the speedtest-call in your container. This is especially:

  --server SERVER       Specify a server ID to test against. Can be supplied
                        multiple times
  --exclude EXCLUDE     Exclude a server from selection. Can be supplied
                        multiple times
  --json                Suppress verbose output, only show basic information
                        in JSON format. Speeds listed in bit/s and not
                        affected by --bytes

With this the output could be changed to JSON and servers with no reliable ressponse can be exluded (or dedicated Servers could be set)
I think that would be a big progress for your solution and should not effect that it is lightwight. It's just for bypassing one ENV (with many paramters in the right format, e.g. "--json --exlude 10010") or a few ENV (with one paramter each) to the CLI.

Thank you! I would really appreciate if this could be implemented somewhen

Thu Mar 14, 2024 9:34 pm

Is it possible to use ENV in mikrotik container solution to bypass parameters to the speedtest-call in your container.

With ENV? No, but I don’t see any reason it has to be done that particular way.

Note the split between ENTRYPOINT and CMD in the Dockerfile. That’s on purpose; it lets you keep ENTRYPOINT as it is while overriding CMD with any flags you prefer.

toffifee · Fri Mar 15, 2024 10:52 am

To be honest: I use Docker and understand the concept behind and how it works in general, but I don't know how much about the dockerfile and the mechanics inside and CMD and ENTRYPOINT. My thought was: Isn't it possible to the container to bypass such paramters "somehow" into the container? And from the use of containers in the past the ENVs seems to be the right place. But any other way would be fine for me as it it is usefull with the standard tools of the MT container solution

Unfortunately I don't understand what you meant with your last response, sorry.

Fri Mar 15, 2024 11:52 am

For a single parameter:

/container
  add remote-image=tangentsoft/speedtest-cli:latest \
  interface=veth1 cmd="--json" logging=yes

For multiple parameters, RouterOS' container feature won't break arguments up by spaces, and there is no shell inside to do the work for us, so you have to rebuild the container per your needs. Follow the documented source build steps to clone my repo, then before the third step, edit the CMD array at the end of the Dockerfile you find there, and then continue on to produce an image tarball you can upload to the router and load via "/container add file=…"

toffifee · Fri Mar 15, 2024 3:55 pm

For a single parameter:

/container
  add remote-image=tangentsoft/speedtest-cli:latest \
  interface=veth1 cmd="--json" logging=yes

Thank you, that was very helpfull and usefull for me. Wasn't aware of usage of CMD in the MT container definition as there was no example. That is sufficent for me. Great!

oskaratk · Tue Sep 24, 2024 3:46 am

Howdy,

I am trying to get this working, but I feel I am missing something:

/container
  add remote-image=tangentsoft/speedtest-cli:latest \
  interface=veth1 cmd="--json" logging=yes

[/quote]

add remote-image seems to require to set a registry-url first.

what would be the correct one?

Thanks
Oskar

Tue Sep 24, 2024 5:24 am

add remote-image seems to require to set a registry-url first. what would be the correct one?

Quoting the container's README.md file, "Start by installing the container package per MikroTik’s docs…" That link gives you this command:

/container/config/set registry-url=https://registry-1.docker.io tmpdir=disk1/pull

oskaratk · Tue Sep 24, 2024 5:15 pm

add remote-image seems to require to set a registry-url first. what would be the correct one?

Quoting the container's README.md file, "Start by installing the container package per MikroTik’s docs…" That link gives you this command:
Code: Select all
/container/config/set registry-url=https://registry-1.docker.io tmpdir=disk1/pull

Argh, RTFM. Must have had tomatoes on my eyes

Thanks

oskaratk · Wed Sep 25, 2024 2:06 am

well, I am back.
container seems to have installed :

 /container> print
 0 name="58319538-67ab-453f-abd6-b24dc918d17a" tag="tangentsoft/speedtest-cli:latest" os="linux" arch="arm" interface=veth1 cmd="--json" mounts="" workdir="/" logging=yes 
   status=stopped

but then /container/start 0

16:58:30 container,info,debug execve: No such file or directory

Any hints are highly welcome
Thanks
Oskar

Wed Sep 25, 2024 9:35 am

but then /container/start 0

16:58:30 container,info,debug execve: No such file or directory

I don't get that error, but I do get a different one, owing to the fact that above, I was echoing "--json" from @toffifee's post above without having tested it. That flag is for a third-party speedtest-cli program, not the official Ookla "speedtest" CLI binary that I package. The correct command is:

/container
add remote-image=tangentsoft/speedtest-cli:latest \
interface=veth1 cmd="--format=json" logging=yes

Do realize that if you run it that way, you're subjecting yourself to one of the most annoying limitations of RouterOS's container feature: lack of a local image cache. Each time you run the command, it pulls the image back down from Docker Hub again even though it hasn't changed since I originally published it.

(And that's not because I've failed to track updates from Ookla; their CLI program remains at version 1.2.0.84.)

If you're going to run this repeatedly, downloading an image tarball to the router as I have documented it and re-instantiating the container from it will side-step this limitation.

…unless, that is, you merely want to run up my pull stats on Docker Hub.

Small Ookla Speedtest container

Small Ookla Speedtest container

Re: Small Ookla Speedtest container

Re: Small Ookla Speedtest container

Re: Small Ookla Speedtest container

Re: Small Ookla Speedtest container

Re: Small Ookla Speedtest container

Re: Small Ookla Speedtest container

Re: Small Ookla Speedtest container

Re: Small Ookla Speedtest container

Re: Small Ookla Speedtest container

Re: Small Ookla Speedtest container

Re: Small Ookla Speedtest container

Re: Small Ookla Speedtest container

Re: Small Ookla Speedtest container

Re: Small Ookla Speedtest container

Re: Small Ookla Speedtest container

Re: Small Ookla Speedtest container

Who is online