Publish Docker image that includes a browser

[mdcruz]

As per this conversation, The k6 Docker doesn't include Chromium so if someone wants to use grafana/k6 directly, they won't be able to run browser tests.

There is an example Dockerfile from xk6-browser so I think we also need a similar one for k6.

I'm not sure what the best way forward so raising this as an issue as we believe this needs more discussion with the k6-core side.

[imiric]

I think it's a good idea to publish a k6 Docker image that includes a browser, but it should definitely be a separate image from the current loadimpact/k6 one. The current one weighs just 35.8MB, whereas any image that includes Chromium would be hundreds of MBs more. We don't want to add that burden to all users that are not running browser scripts.

UPDATE: I just did a quick test adding chromium to our Dockerfile, and it produced a 401MB image(!). And this one is based on Alpine, which we probably shouldn't use for browser tests. Building from the xk6-browser repo's Dockerfile (Debian-based) produces a 1GB image.

So yeah, definitely as a separate image, maybe grafana/k6-browser.

[mdcruz]

I think it's a good idea to publish a k6 Docker image that includes a browser, but it should definitely be a separate image from the current loadimpact/k6 one. The current one weighs just 35.8MB, whereas any image that includes Chromium would be hundreds of MBs more. We don't want to add that burden to all users that are not running browser scripts.

UPDATE: I just did a quick test adding chromium to our Dockerfile, and it produced a 401MB image(!). And this one is based on Alpine, which we probably shouldn't use for browser tests. Building from the xk6-browser repo's Dockerfile (Debian-based) produces a 1GB image.

So yeah, definitely as a separate image, maybe grafana/k6-browser.

Thanks Ivan for the quick investigation! A separate docker image sounds like the best option 👍🏼

[andrewslotin]

Having a separate image (or even the same one, but with a separate tag) with browser installed and k6 browser module enabled might be a good idea. This way users explicitly opt in for using browser API in their tests, so no unexpected process launches.

[mstoykov]

I guess in that case you can even by default set --env K6_BROWSER_ENABLED=true --env XK6_HEADLESS=true so it is easier to use while still being pretty certain users are only running it because they do want to run a browser.
Also running it within a container definitely does help to elevate some of the security concerns

[ankur22]

I'd like to add a finding that might affect this or other docker images that we push to docker hub. We can run the docker image directly from command line such as:

docker run -v /path/to/tests/on/host/k6:/path/to/tests/in/docker/k6 grafana/k6:latest run /path/to/tests/in/docker/k6/my-super-test.js

If i now try running a browser test with something like this:

docker run -v /path/to/tests/on/host/k6:/path/to/tests/in/docker/k6 --env K6_BROWSER_ENABLED=true grafana/k6:latest run /path/to/tests/in/docker/k6/my-super-browser-test.js

We get the expected GoError: launching browser: exec: no command since the browser isn't installed in the image. All good so far.

If i now try to create a new image based on grafana/k6:0.43.0 with the following on a mac on arm which includes a browser:

FROM grafana/k6:0.43.0
USER root

RUN apk update && apk add --no-cache chromium

ENV K6_BROWSER_ENABLED=true

Build with docker build -t testing-k6 -f Dockerfile .

Run the test with docker run -v /path/to/tests/on/host/k6:/path/to/tests/in/docker/k6 testing-k6 run /path/to/tests/in/docker/k6/my-super-browser-test.js

I get panic: GoError: creating a new page: initializing networking *network.EnableParams: websocket: close 1006 (abnormal closure): unexpected EOF.

This only happens on mac on arm. It has been tested on ubuntu non arm and it works. So:

1. Why is that?
2. Can we (or do we need to) mitigate the issue for mac arm users (and possibly other arm based OSs)?

[imiric]

@ankur22 I think it's because the grafana/k6 image is only built for linux/amd64. You can see it in the "OS/Arch" column on Docker Hub. Then when you build an image based on it on macOS/ARM, it's likely that Chromium is failing to start.

There are ways of building multi-platform images, but I think we don't need to publish a separate ARM image, and you should be able to use the original image if you pass --platform linux/arm64 to that docker build command. Or to the run command... I'm not entirely sure, but try experimenting with that flag.

[ankur22]

if you pass --platform linux/arm64 to that docker build command

I tried that, with no luck. I agree that it does seem to be a bit too much to upload an image for different OS/Arch. I may do a bit more digging though. Thanks for the advice 👍

[nyccto]

+1 for k6 Dockerfile with a browser

Currently, there doesn't seem to be a Dockerfile that can be used for k6 browser-based testing. Adding browser support manually similar to xk6-browser Dockerfile has compatibility issues/errors within k6 core. It would be great to have a k6 core Dockerfile with a browser option