armhf docker image of Selenium

Question

armhf docker image of Selenium

vipulgupta2048 opened this issue 4 years ago · 54 comments

vipulgupta2048 commented 4 years ago

🚀 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.

Answer 1 · 2020-07-06T21:56:47.000Z

@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?

Answer 2 · 2020-07-07T14:24:47.000Z

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?

Answer 3 · 2020-07-08T08:53:48.000Z

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.

Answer 4 · 2020-07-08T15:07:15.000Z

@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!

Answer 5 · 2020-07-13T21:55:10.000Z

@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.

Answer 6 · 2020-07-14T07:57:06.000Z

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 👍

Answer 7 · 2020-12-22T18:26:35.000Z

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.)

Answer 8 · 2020-12-28T14:24:40.000Z

+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.

Answer 9 · 2021-01-19T15:05:41.000Z

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

Answer 10 · 2021-01-19T17:59:53.000Z

@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

Answer 11 · 2021-02-12T10:59:58.000Z

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.

Answer 12 · 2021-03-01T22:22:13.000Z

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.

Answer 13 · 2021-06-20T05:02:01.000Z

@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.

Answer 14 · 2021-06-21T02:22:14.000Z

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

Answer 15 · 2021-06-22T05:37:09.000Z

@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"

Answer 16 · 2021-06-26T04:24:09.000Z

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

Answer 17 · 2021-09-07T02:28:42.000Z

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.

Answer 18 · 2021-09-16T06:30:25.000Z

any updates?

Answer 19 · 2021-09-20T06:44:40.000Z

For my fork, I don't have the time to rebase it against upstream sorry so updates will be sporadic. I'd love to see upstream support for ARM.

Answer 20 · 2021-09-21T14:30:49.000Z

We'd love to see contributions in this aspect as well, we do not have machines to test this and we have little time to research on this. However, seems @sj26 has had the time to get this ahead. We are happy to discuss how we can get this done. Looking forward to your contributions!

Answer 21 · 2021-09-21T17:39:54.000Z

I've been looking to do the same for sitespeed.io so I can help out here or test. There are some problems though:

@diemol what's Seleniums requirements for browser versions? I always try to run my test with the latest stable versions for Chrome/Firefox but getting those for ARM (and corresponding drivers) is a pain (at least at the moment)
Has anyone found a way to use different docker files per platform/arch? That way you don't have to have big if/else depending on the platform. I haven't been able to find a way with docker buildx but maybe someone else has?

Answer 22 · 2021-09-21T18:12:27.000Z

Has anyone found a way to use different docker files per platform/arch? That way you don't have to have big if/else depending on the platform. I haven't been able to find a way with docker buildx but maybe someone else has?

@soulgalore how about just specifying the Dockerfile with -f?

Answer 23 · 2021-09-23T08:43:04.000Z

@diemol what's Seleniums requirements for browser versions? I always try to run my test with the latest stable versions for Chrome/Firefox but getting those for ARM (and corresponding drivers) is a pain (at least at the moment)

Ideally we only want to support the latest stable versions, and I believe that is the main problem with this, getting the binaries for browsers and browser drivers is not straight forward.

Answer 24 · 2021-09-25T12:14:14.000Z

Is it possible to just ease into the ARM64 waters slowly by at least supporting Debian ARM64 and Chromium, such as seleniarm/standalone-chromium only? The Chromium ARM64 binary on Debian 10 seems pretty stable. I haven't tried other browsers, but being able to run tests in a Chromium browser in containers on the Mac M1 is better than not being able to run any tests at all. I've been using @sj26 solution for some time now and it's allowed me to continue to be productive while on the Mac M1...

I also noticed that TravisCI appears to support running tests on the ARM64 architecture, which means you should be able to run these through automated tests before publishing them, even if you don't have a physical ARM machine. https://docs.travis-ci.com/user/multi-cpu-architectures/

Answer 25 · 2021-09-27T11:40:42.000Z

@soulgalore how about just specifying the Dockerfile with -f?

yes building containers from different Docker files and give them different tags works fine with -f but if you want the them to have the same name and same tag but built for different architecture I haven't find a way to do that. For example building with docker buildx for one platform at a time and then pushing them, the Docker hub only contains the latest pushed container/platform, not for all platforms. Or at least when I did a quick try.

Answer 26 · 2021-09-30T05:58:29.000Z

I apologize for assuming this is easier than it sounds. As with many of these things, once you dig in, you realize it's not so straightforward.

I created a fork to update Selenium/Standalone-Chrome to use 4.0.0-rc-2-prerelease (or off the latest trunk at the time of this writing)

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

You can build the images yourself with the sh build.sh command and then use the noVNC client in your browser. I haven't had time to look at Firefox or the Selenium Grid yet, but others are welcome to give it a try.

Answer 27 · 2021-11-11T09:10:09.000Z

I pushed some of the ARM64 Docker Selenium images to Docker Hub. They can be found here: https://hub.docker.com/u/seleniarm.

Answer 28 · 2021-11-12T11:39:12.000Z

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.

Answer 29 · 2021-12-10T20:00:54.000Z

thanks a lot @DmitriyYukhanov ! for some reason I was not able to get it to work replacing arm64 with arm/v7 and had to replace it with armhf.

So just replace arm64 with armhf in both build.sh and Base/Dockerfile from that repo. I didn't get Firefox working but Chrome does so I can manage with that for the moment

Answer 30 · 2021-12-15T12:42:49.000Z

After great work from @jamesmortensen, we have an image for arm based arch.
I would be nice to merge it in this repo. If I knew how to help, I would do it myself. I've already created a ticket.

I think @jamesmortensen or @sj26 can help much more than me. :)

Answer 31 · 2021-12-25T18:06:49.000Z

Seleniarm container images are built with a lot of unknowns that make merging them upstream a risky endeavor. Here are the challenges that need to be overcome:

There are no Google Chrome binaries, only Chromium, for ARM64, and the Selenium maintainers prefer to support the browsers used most by users, which is Google Chrome.
The ARM64 binary for Chromium on Debian is 3 major versions behind the latest Chromium on the x86_64 platform, and Debian is the only distro where we can find a matching ARM64 Chromedriver binary.
Firefox on ARM64 is also a few versions behind the x86_64 build.
There are no ARM64 binaries for geckodriver available on Mozilla's site or in any Linux distro packages. I have to build it manually in an intermediate ARM64 container and then copy it into the node-firefox container image during the build process. Currently, it cannot be automated like it can for the upstream images due to problems attempting to run cargo build in a shell script.
There are no ARM64 binaries for Microsoft Edge or Opera, at least not to my knowledge, and if there were, we would need corresponding WebDrivers for them as well.
The other images in the seleniarm repo have not been built and tested, such as the distributor, standalone-docker, etc.
Coming back to testing, to the best of my knowledge, we don't have any automated tests for the seleniarm images.

I am not sure what the update process is for browser binaries and WebDrivers on Debian/Ubuntu ARM64. It doesn't seem like those communities are able to keep the binaries up to date. At this time, it seems best to maintain the seleniarm fork until things stabilize, as most people working on Intel based systems will probably be better served by the images which are in the upstream repo.

I consider seleniarm to be helpful for those of us on ARM64 machines, but they should also be considered very alpha at this time. If you're able to run the Intel images, I highly recommend running them instead. Hope this helps!

Answer 32 · 2021-12-28T22:11:48.000Z

@sj26 / @jamesmortensen - just want to say thank you 💯.

I burned most of today debugging these error messages, only to find this wonderful thread.

I now have to maintain 2 docker compose files, an arm64 for myself, and a regular amd64 for the rest of the team. Which I'll happily do in exchange for a working setup 🙂

docker-compose.e2e.arm64.yml
docker-compose.e2e.yml

Edit: I recently learned about the concept of "override" in docker compose. So, now I can override just the image value. See snippets below:

File docker-compose.e2e.yml:

version: '3.4'
services:

  e2e:
    depends_on:
      - hub
      - chrome
    build:
      context: ./e2e
      dockerfile: ./Dockerfile
    volumes:
      - ./e2e/tests_output:/app/tests_output
    env_file:
      - .env
    command: ./run.sh

  hub:
    image: selenium/hub:4.1.1-20211217
    ports:
      - "4442:4442"
      - "4443:4443"
      - "4444:4444"
    env_file:
      - .env
    environment:
      - GRID_DEBUG=true

  chrome:
    depends_on:
      - hub
    image: selenium/node-chrome:4.1.1-20211217
    shm_size: 2gb
    env_file:
      - .env
    environment:
      - SE_EVENT_BUS_HOST=hub
      - SE_EVENT_BUS_PUBLISH_PORT=4442
      - SE_EVENT_BUS_SUBSCRIBE_PORT=4443
      - SCREEN_WIDTH=1920
      - SCREEN_HEIGHT=1080
      - START_XVFB=false
      - GRID_DEBUG=true

File docker-compose.e2e.arm64.yml:

version: '3.4'
services:

  hub:
    image: seleniarm/hub:4.0.0-20211213

  chrome:
    image: seleniarm/node-chromium:4.0.0-20211213

Run it with:

docker compose \
-f docker-compose.yml \
-f docker-compose.e2e.yml \
-f docker-compose.e2e.arm64.yml \
build hub chrome e2e

docker compose \
-f docker-compose.yml \
-f docker-compose.e2e.yml \
-f docker-compose.e2e.arm64.yml \
up -d hub chrome

docker compose \
-f docker-compose.yml \
-f docker-compose.e2e.yml \
-f docker-compose.e2e.arm64.yml \
run --rm e2e

Answer 33 · 2022-01-12T19:08:36.000Z

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.

Answer 34 · 2022-01-13T03:36:19.000Z

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.

Answer 35 · 2022-01-13T23:31:55.000Z

@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.

Answer 36 · 2022-01-14T10:24:56.000Z

@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

Answer 37 · 2022-01-14T20:30:57.000Z

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.

Answer 38 · 2022-01-16T16:03:26.000Z

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.

Answer 39 · 2022-01-17T22:47:58.000Z

@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.

Answer 40 · 2022-01-20T12:00:16.000Z

@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.

Answer 41 · 2022-01-21T22:56:28.000Z

@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.

Answer 42 · 2022-01-26T12:46:08.000Z

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

Answer 43 · 2022-02-14T14:28:04.000Z

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).

Answer 44 · 2022-02-17T17:06:43.000Z

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

Answer 45 · 2022-02-17T22:15:13.000Z

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?

Answer 46 · 2022-02-17T22:21:47.000Z

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.

Answer 47 · 2022-02-21T17:53:01.000Z

@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.

Answer 48 · 2022-02-22T11:09:54.000Z

@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?

Answer 49 · 2022-02-22T11:10:29.000Z

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

Answer 50 · 2022-02-22T16:01:52.000Z

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.

Answer 51 · 2022-02-22T17:59:59.000Z

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

Answer 52 · 2022-02-27T05:51:52.000Z

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.

Answer 53 · 2022-03-02T15:42:27.000Z

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.

Answer 54 · 2022-04-02T00:14:54.000Z

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.