armhf docker image of Selenium

[vipulgupta2048]

🚀 Feature Proposal

I am trying to run Selenium on RPi3 in a docker container and all the docker images that are available are of x86 architecture type. Henceforth I am willing to build a fully-featured arm7hf image for Selenium to be able to run on modern ARM devices (with some help from your side) if you feel this is viable enough.

Motivation

ARM is a fast-approaching architecture that is becoming better day by day with recent advancements. Selenium especially being quite popular with folks working in web automation and testing, if the framework can run on modern high-performance boards like RaspberryPi's then it would be extremely helpful to the community in general.

Superior web automation now becomes portable with ARM-based devices sounds like a great pitch.

Example

Build a fully-featured dockerfile for selenium that is compatible with ARM to build a docker image, we can either modify present components (recommended) or build a new one. Folks, wanting to run on Selenium on ARM devices, can easily pull the image and start working on it.

Ubuntu Bionic 18.04 has multi-arch support for armhf so we are sorted there for the base image.
Google-Chrome is not available on ARM, so we can use Chromium.
And, Chromium-Chromedriver as an alternative for chromedriver. That's the two major things that gets changed.

Let me know what you think folks! Happy to help to build this if it sounds viable enough.

[diemol]

@vipulgupta2048
Yeah, I guess over time there will be more interest in these images, but not having Chrome or ChromeDriver is less than ideal.
Additionally, I guess we need to compile the Selenium Server jar for ARM?

[vipulgupta2048]

Thanks for replying @diemol
Can you explain why Chromium and Chromium-Chromedriver won't fit together and would be less than ideal for running Selenium? I understand everything is configured with taking Chrome and Chromedriver as a base but isn't there any way to run the alternatives.

Yes, Selenium server needs to be recompiled for ARM since it contains some non-JVM code. Otherwise, it might have just worked. How do you think I should go about this?

[diemol]

Well, people want to test on the same browser customers use. We know that Chromium is the base for Chrome, but in reality, people want to test with Chrome.

About Selenium jar, we need to figure out how to do it in a simple way. For now, the focus is Selenium 4 and after that is released, we can check this again. In general, this does not look as a simple thing to achieve.

[vipulgupta2048]

@diemol Agreed to that, more users use Chrome so makes sense to take that. With your response, I thought Chromium wouldn't work at all even with a little tinkering.

About Selenium jar, at first, it seemed quite straightforward as we can just run the same Bazel build over on the ARM container. But, since Bazel is not available on ARM as a package to begin with. I am not sure how to proceed. Please do let me know if there is a way about how I can go implementing this at the moment. Anything would help at this point. Thanks!

[diemol]

@vipulgupta2048 yeah, right now we are still working towards a beta in Selenium 4, so no priority for this right now. I will comment back later.

[vipulgupta2048]

Thanks @diemol appreciate it!
Happy to help, I have laid some groundwork for the same when i tried porting myself. Let me know I can share it over here when the time comes 👍

[henningn]

Since apple silicon is released, this issue might be relevant for more users.

Currently selenium/standalone-chrome failed in my setup with "driver.version: unknown".
The selenium/standalone-firefox still works. I've build standaloneFirefox for arm64, which was pretty straightforward and give a decent preformance boost.

(Tested with DockerPreview7.)

[jmichaelward]

+1 for relevancy. Just tried to run our tests this morning on Apple M1, and the same errors reported 6 days ago are there. I'll give standalone-firefox a look in the meantime.

[thomasphilibert]

Since apple silicon is released, this issue might be relevant for more users.

Currently selenium/standalone-chrome failed in my setup with "driver.version: unknown".
The selenium/standalone-firefox still works. I've build standaloneFirefox for arm64, which was pretty straightforward and give a decent preformance boost.

(Tested with DockerPreview7.)

Hello @henningn,
Can you explain to me how you did it? I get the same result between Chrome and Firefox on an Apple M1.

Best,
Thomas

[henningn]

@thomasphilibert,
I can use selenium/standalone-firefox:4.0.0-beta-1-prerelease-20201208 out of the box. It is slow but it works.

To build an arm image you have to ake some changes to the "Base"-Dockerfile and "NodeFirefox"-Dockerfile. (see henningn@c0f0f64)

I've pushed the image to docker hub, where the amd64 version is the official one and the arm64 version is the self build version. You can find it here: https://hub.docker.com/repository/docker/henningn/selenium-standalone-firefox

[DmitrySkripkin]

I tried @henningn solutions with firefox, it didn't help. Then I tried to recreate Base and Hub images with arm64 ubuntu, same results.
From my perspective the problem is in Base and Hub images. When I run Hub on Linux amd64 machine i can browse to localhost:4444 and see Selenium page, but it doesn't work on arm machine (ports are exposed but response is empty).

BTW, no problems with running selenium with Chrome natively without Docker. I think we can manage it to run as expected in a container.

EDIT:
I was able to run Hub successfully. Now I can open localhost:4444 page. I have no idea why it didn't work previously. Now I think I can try to run firefox image.

[sj26]

Does armhf run on arm64? (I'm guessing the reverse doesn't work, armv9 > armv7.)

I have multi-arch linux amd64/arm64 images for all the Selenium parts as well as Chromium and Firefox which work great on Docker for Mac on an M1 as linux/arm64, and on AWS Graviton2 instances as the same, and still work on linux/amd64 platform as well:

https://github.com/sj26/docker-selenium

They're currently pushed to Docker Hub here:

https://hub.docker.com/u/seleniarm

The main blocker seems to be getting good upstream browser binaries. The best I could find was Debian who build Chromium and Firefox across many platforms.

[jamesmortensen]

@sj26 How did it go compiling the selenium docker images for the ARM architecture? I tried to pull from seleniarm but it seems the images are not published on Docker, unless I'm just missing something.

version: "3"
services:
  chrome0:
    image: seleniarm/node-chromium:4.0.0-beta-1-20210215
    volumes:
      - /dev/shm:/dev/shm
    depends_on:
      - seleniarm-hub
    environment:
      - SE_EVENT_BUS_HOST=seleniarm-hub
      - SE_EVENT_BUS_PUBLISH_PORT=4442
      - SE_EVENT_BUS_SUBSCRIBE_PORT=4443
    ports:
      - "6900:5900"

  chrome1:
    image: seleniarm/node-chromium:4.0.0-beta-1-20210215
    volumes:
      - /dev/shm:/dev/shm
    depends_on:
      - seleniarm-hub
    environment:
      - SE_EVENT_BUS_HOST=seleniarm-hub
      - SE_EVENT_BUS_PUBLISH_PORT=4442
      - SE_EVENT_BUS_SUBSCRIBE_PORT=4443
    ports:
      - "6901:5900"

  chrome2:
    image: seleniarm/node-chromium:4.0.0-beta-1-20210215
    volumes:
      - /dev/shm:/dev/shm
    depends_on:
      - seleniarm-hub
    environment:
      - SE_EVENT_BUS_HOST=seleniarm-hub
      - SE_EVENT_BUS_PUBLISH_PORT=4442
      - SE_EVENT_BUS_SUBSCRIBE_PORT=4443
    ports:
      - "6902:5900"

  seleniarm-hub:
    image: seleniarm/hub
    container_name: seleniarm-hub:4.0.0-beta-1-20210215

    ports:
      - "4442:4442"
      - "4443:4443"
      - "4444:4444"

I tried running a hub from here but it said:

$ docker-compose -f docker-compose-hub-arm64.yml up -d
Pulling seleniarm-hub (seleniarm/hub:)...
ERROR: manifest for seleniarm/hub:latest not found: manifest unknown: manifest unknown

What am I missing? Thanks.

[sj26]

I think I didn't publish a latest tag for seleniarm/hub sorry! Only 4.0.0-beta-1-20210215. I think the scripts still push 3.x series as latest.

https://hub.docker.com/r/seleniarm/hub/tags

[jamesmortensen]

@sj26 Thank you! Glad to be able to run my Docker Selenium Hub again! Here is my updated docker-compose:

version: "3"
services:
  chrome0:
    image: seleniarm/node-chromium:4.0.0-beta-1-20210215
    volumes:
      - /dev/shm:/dev/shm
    depends_on:
      - seleniarm-hub
    environment:
      - SE_EVENT_BUS_HOST=seleniarm-hub
      - SE_EVENT_BUS_PUBLISH_PORT=4442
      - SE_EVENT_BUS_SUBSCRIBE_PORT=4443
    ports:
      - "6900:5900"

  chrome1:
    image: seleniarm/node-chromium:4.0.0-beta-1-20210215
    volumes:
      - /dev/shm:/dev/shm
    depends_on:
      - seleniarm-hub
    environment:
      - SE_EVENT_BUS_HOST=seleniarm-hub
      - SE_EVENT_BUS_PUBLISH_PORT=4442
      - SE_EVENT_BUS_SUBSCRIBE_PORT=4443
    ports:
      - "6901:5900"

  chrome2:
    image: seleniarm/node-chromium:4.0.0-beta-1-20210215
    volumes:
      - /dev/shm:/dev/shm
    depends_on:
      - seleniarm-hub
    environment:
      - SE_EVENT_BUS_HOST=seleniarm-hub
      - SE_EVENT_BUS_PUBLISH_PORT=4442
      - SE_EVENT_BUS_SUBSCRIBE_PORT=4443
    ports:
      - "6902:5900"

  seleniarm-hub:
    image: seleniarm/hub:4.0.0-beta-1-20210215
    container_name: seleniarm-hub-4.0.0-beta-1-20210215

    ports:
      - "4442:4442"
      - "4443:4443"
      - "4444:4444"

[zeevo]

+1 for these images. It would be nice to run a selenium server on Raspberry Pi 4 using Docker.

[idontusenumbers]

I have multi-arch linux amd64/arm64 images for all the Selenium parts as well as Chromium and Firefox which work great on Docker for Mac on an M1 as linux/arm64, and on AWS Graviton2 instances as the same, and still work on linux/amd64 platform as well:

This has been working well for me, thanks!

Any chance of an updated build? I'd be curious about the new noVnc server that seems to have been merged since the latest build.

[jamesmortensen]

Thank you @jamesmortensen !
Edited: For those who would like to build non-64 bit arm images: I was able to build armhf images out from the @jamesmortensen repo right on the rPi 4. Changes required to make it happen:

• replace arm64 with arm/v7 at the build.sh
• replace arm64 with armhf at the Base/Dockerfile

Keeping all this local as I'm not experienced with docker publishing enough.

I am trying to follow these steps, but I am unsure where I need to make these changes. Could someone please post slightly more elaborated steps to follow? I tried pulling the linked Github image directly, but the repository doesn't seem to be a git repository. Docker pull worked, but I don't see where I can go to edit these files directly.

Hi @Coliinnn you'll need to clone the arm fork of docker-selenium:

$ git clone https://github.com/seleniarm/docker-selenium

and then in the build.sh script, change all references of arm64 to armhf or arm/v7. You'll also need to edit the Dockerfile in the Base folder and ensure the ARCH environment variable is set to armhf or arm/v7. As long as you're only building the Chromium images, this should be all you need to do. Once done, execute the build script:

$ sh build.sh

This should build the images for you, and you should then be able to run standalone-chromium like so:

$ docker run --rm -it -p 4444:4444 -p 5900:5900 -p 7900:7900 --shm-size 3g local-seleniarm/standalone-chromium:latest

I do not have a Raspberry Pi, so I have not tried this myself. If someone who can test this and can confirm the exact values and in which places (arm/v7 vs armhf) can open a pull request adding the specific platform string(s) to line 6 of https://github.com/seleniarm/docker-selenium/blob/trunk/build-and-deploy-multi-arch.sh#L6, then I may be able to push a multi-arch build for amd64, arm64, and arm/v7 (or armhf) to Docker Hub.

@zwbetz-gh Thanks for sharing the override feature in docker-compose. That will come in handy for folks wanting to utilize different platform images instead of the multi-arch images. Thanks.

[Coliinnn]

@jamesmortensen Thank you for the quick response. I have spent several hours trying to build the image and your steps have helped me come a long way. However, the build script fails midway, as it attempts to install Node-Chromium and Standalone-Chromium. Please see the error log here.

I've tried several combinations of arm/v7 and armhf in build.sh and Base/Dockerfile, but none seem to solve this issue. I now suspect that I run into this error because of line 3 in build.sh:
CHROMIUM=93.0.4577.82 # Not yet used at this time. Edit in NodeChromium/Dockerfile.txt

I took a peek at NodeChromium/Dockerfile.txt, but cannot figure out what I exactly need to change to install Chromium for arm32. Do you, or someone else, know how I can get past this error? I suspect (hope!) that the build will then finish, and I'll gladly open the pull request with the correct values once it does.

[jamesmortensen]

@jamesmortensen Thank you for the quick response. I have spent several hours trying to build the image and your steps have helped me come a long way. However, the build script fails midway, as it attempts to install Node-Chromium and Standalone-Chromium. Please see the error log here.

I've tried several combinations of arm/v7 and armhf in build.sh and Base/Dockerfile, but none seem to solve this issue. I now suspect that I run into this error because of line 3 in build.sh: CHROMIUM=93.0.4577.82 # Not yet used at this time. Edit in NodeChromium/Dockerfile.txt

I took a peek at NodeChromium/Dockerfile.txt, but cannot figure out what I exactly need to change to install Chromium for arm32. Do you, or someone else, know how I can get past this error? I suspect (hope!) that the build will then finish, and I'll gladly open the pull request with the correct values once it does.

Line 78 in the pastebin shows the node chromium image failing because there is no chromium with that specific version on your platform. Instead, replace the chromium version with the version 97 on line 9 in NodeChromium/Dockerfile.txt. Rerun the build script after that.

See:
https://packages.debian.org/sid/armhf/chromium/download 97.0.4692.71

[Coliinnn]

Perfect, thank you! The build succeeded with the following version: 97.0.4692.71-0.1. I can play around with the different values tomorrow to make sure that we know whether we need armhf or arm/v7. Should the Chromium version also be included in the pull request? I have not made a pull request before, so let me know if there is anything to keep in mind whilst doing that.

[jamesmortensen]

Perfect, thank you! The build succeeded with the following version: 97.0.4692.71-0.1. I can play around with the different values tomorrow to make sure that we know whether we need armhf or arm/v7. Should the Chromium version also be included in the pull request? I have not made a pull request before, so let me know if there is anything to keep in mind whilst doing that.

From what I can see, the chromium version should work for all the platforms, so you can include it. Just open the pr against seleniarm/docker-selenium and I can help you make any changes needed.

[Coliinnn]

@jamesmortensen Apologies for the delay- I've created the pull request now. I hope this is a decent starting point to get 32-bit ARM support in the multi-arch build. Feedback on the PR is appreciated! My workaround may not be the best way of doing things.

[jamesmortensen]

@Coliinnn I built and pushed images to Docker Hub; however, I'm not able to verify that the x86_64 and armhf images are working correctly since I'm on a Mac M1. I ran seleniarm/standalone-chromium via QEMU emulation, but Chromium crashes in armhf and noVNC wasn't working properly on x86_64. Not sure if it's a problem with the image or because I'm trying to emulate those architectures on an M1.

If volunteers working on x86_64 and armhf platforms can verify that the following images work on their platforms, then I'll push the multi-arch images under the "latest" tag.

docker pull seleniarm/standalone-chromium:4.1.1-alpha-20220119
docker pull seleniarm/node-chromium:4.1.1-alpha-20220119
docker pull seleniarm/hub:4.1.1-alpha-20220119

Chromium is also updated to v97.0.4692.71-0.1 for all three architectures.

[Coliinnn]

@jamesmortensen Thank you for the work! I have just updated the docker image to seleniarm/standalone-chromium:4.1.1-alpha-20220119 (on my 32-bit Raspbian OS). Everything seems to run OK: I see no errors in the logs and the client seems to work. If you want to make sure everything is running as it should, here are the complete logs: https://pastebin.com/1KaxTs61.

[jamesmortensen]

@Coliinnn Thanks for confirming with the logs. This is helpful.

[bbaraban]

Hello,

Is there any plan to have M1 Mac support in the official docker-selenium releases? What are the blockers if there are any? If a large organization needs official support what is the current recommendation? To build and maintain their own M1 architecture images?

Developers on M1 macs are becoming more prevalent as people upgrade their machines. I have tested the Seleniarm images and can confirm at-least the hub and chromium images work (thank you @jamesmortensen).

[sparkanist]

It seems like there is an official M1 release of gekodriver as well so a release of hub, firefox, and chromium should be feasible for m1 I also was able to get a multi-arch build going as well.

https://hub.docker.com/r/sarkwright/hub/tags

This was just a quick PoC I compiled because I needed an image, but they are functional. I did reference your work too so thanks @jamesmortensen

[diemol]

As M1 is slowly becoming popular, it'd be nice to support that architecture in this repo.

However, some blockers are:

• We do not have an M1 to develop this. I am the person who spends most of the time maintaining this repo, and I might get an M1 in a few months from work due to normal laptop replacement policy. Any suggestions to get around this are appreciated.
• The most relevant blocker is summarized by @jamesmortensen here. Getting binaries with the latest version of browsers and browser drivers is currently impossible (which reminds me of the time where everyone was asking for alpine images).

These blockers bring two points:

• Having an M1 will be eventually solved. But we also need a CI that supports the architecture. I've spent a lot of time automating many maintenance tasks because I also need time to maintain the upstream Grid and help with other Selenium projects. Manual steps are a no-go.
• A more relevant point related to not having access to latest binaries. Are folks willing to test on latest-3 versions? What would be the point of that?

I feel a way to go for now would be to keep those images in a separate repo while they are still on the "experimental" phase. An option would be to create a community supported repo at https://github.com/seleniumhq-community, and then reference that one from the official. Ideally, folks in this thread could help to maintain it, maybe lead by @jamesmortensen?

What do you think?

[idontusenumbers]

Docker can run non-native images via QEMU; Could you use an arm docker image to develop the docker image? Raspberry Pi 4 has a 64bit ARM CPU; would that work? I know development on a pi is very slow but you'd only need to build/test and not actually code I would hope.

[jamesmortensen]

@diemol I do have some ideas for the CI server. One thing I had in mind was to use one of Oracle's free ARM64 Ampere A1's to host an ARM64 GitHub Actions self-hosted runner for building and testing container images. This is something I'm hoping to find time to explore in the coming weeks.

Images for Chromium and Firefox ARM64 are here in this fork of docker-selenium: https://github.com/seleniarm/docker-selenium and published on Docker Hub here. Are you proposing I move the images to this location instead? https://github.com/seleniumhq-community.

Should I maintain this as a fork of what's in SeleniumHQ/docker-selenium or are you proposing it just be a completely separate repo? About once a month, I've been merging from upstream from the https://github.com/seleniumhq/docker-selenium repo into https://github.com/seleniarm/docker-selenium and then running some scripts on my Mac M1 to rebuild the images and publish them. There are still enough similarities between the x86 images and ARM64 Dockerfiles where maintaining this as a fork may be beneficial than it being a completely new repo. What do you think?

As for blockers, such as the browser and driver binaries, if there's anyone who has contacts in the Debian or Ubuntu maintainer communities (preferably Ubuntu, since that's what this upstream repo relies on), perhaps someone can work on getting support for more frequent updates for Chromium, Chromedriver, Firefox, and geckodriver on these platforms. It would require volunteers who can commit to building those binaries on a regular basis.

[diemol]

@jamesmortensen

Images for Chromium and Firefox ARM64 are here in this fork of docker-selenium: https://github.com/seleniarm/docker-selenium and published on Docker Hub here. Are you proposing I move the images to this location instead? https://github.com/seleniumhq-community.

Yeah, if the idea is to give some sort of "official" but experimental solution for this architecture. Of course, hoping that you'd like to work on it and be part of the Selenium org. We could publish the images to the Selenium Docker hub account if you wish as well.

Should I maintain this as a fork of what's in SeleniumHQ/docker-selenium or are you proposing it just be a completely separate repo? About once a month, I've been merging from upstream from the https://github.com/seleniumhq/docker-selenium repo into https://github.com/seleniarm/docker-selenium and then running some scripts on my Mac M1 to rebuild the images and publish them. There are still enough similarities between the x86 images and ARM64 Dockerfiles where maintaining this as a fork may be beneficial than it being a completely new repo. What do you think?

Definitely as a fork, yes. Makes more sense.

What do you think?

[diemol]

Also, feel free to join us in Slack/IRC/Matrix if you want to chat more about it.

[jamesmortensen]

Multi-arch container images have been updated on Docker Hub. Release notes are here:
https://github.com/seleniarm/docker-selenium/releases/tag/seleniarm-v4.1.2-20220222

Images are available for linux/arm64, linux/amd64, and linux/arm/v7:

Pull commands:

docker pull seleniarm/base:4.1.2-20220222
docker pull seleniarm/hub:4.1.2-20220222
docker pull seleniarm/node-base:4.1.2-20220222
docker pull seleniarm/node-chromium:4.1.2-20220222
docker pull seleniarm/standalone-chromium:4.1.2-20220222
docker pull seleniarm/node-firefox:4.1.2-20220222
docker pull seleniarm/standalone-firefox:4.1.2-20220222

Configuration:

• Debian 11.2
• Selenium - 4.1.2
• Chromium - 98.0.4758.102
• Firefox - 96.0.3

See Seleniarm on Docker Hub for published images.

[viktorianer]

@jamesmortensen you are incredible! Great. Thank you a lot.

[jamesmortensen]

Multi-arch container images have been updated on Docker Hub. Release notes are here: https://github.com/seleniumhq-community/docker-seleniarm/releases/tag/seleniarm-v4.1.2-20220227

Release Notes

Fixes an issue where arm64 geckodriver binary was still used on x86_64 hosts for the node-firefox and standalone-firefox container images. At this point, the Selenium Grid and Chromium and Firefox standalone images should be working on amd64, armv7, and arm64.

Pushed the following images to Docker Hub:

Images are available for linux/arm64, linux/amd64, and linux/arm/v7:

Pull commands:

docker pull seleniarm/base:4.1.2-20220227
docker pull seleniarm/hub:4.1.2-20220227
docker pull seleniarm/node-base:4.1.2-20220227
docker pull seleniarm/node-chromium:4.1.2-20220227
docker pull seleniarm/standalone-chromium:4.1.2-20220227
docker pull seleniarm/node-firefox:4.1.2-20220227
docker pull seleniarm/standalone-firefox:4.1.2-20220227

Configuration:

• Debian 11.2
• Selenium - 4.1.2
• Chromium - 98.0.4758.102
• Firefox - 96.0.3

See Seleniarm on Docker Hub for published images.

[diemol]

Huge thanks to @jamesmortensen!

Now we have these experimental images https://github.com/SeleniumHQ/docker-selenium#experimental-mult-arch-aarch64armhfamd64-images

I will close this issue and futher detailed discussions can be done in issues on the community driver project.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.