docker-selenium
[NOT MAINTAINED] Please use <https://github.com/SeleniumHQ/docker-selenium>
Top Related Projects
Provides a simple way to run Selenium Grid with Chrome, Firefox, and Edge using Docker, making it easier to perform browser automation
Selenium Hub successor running browsers within containers. Scalable, immutable, self hosted Selenium-Grid on any platform with single binary.
Automated driver management and other helper features for Selenium WebDriver in Java
Deploy headless browsers in Docker. Run on our cloud or bring your own. Free for non-commercial uses.
Testcontainers is a Java library that supports JUnit tests, providing lightweight, throwaway instances of common databases, Selenium web browsers, or anything else that can run in a Docker container.
Quick Overview
Docker-Selenium is a project that provides Docker images for running Selenium Grid with Chrome and Firefox browsers. It allows users to easily set up and scale Selenium Grid environments for automated browser testing, with support for video recording, VNC viewer access, and various customization options.
Pros
- Easy setup and deployment of Selenium Grid using Docker containers
- Supports both Chrome and Firefox browsers with various versions
- Includes video recording capabilities for test sessions
- Provides VNC viewer access for debugging and monitoring
Cons
- May require significant system resources, especially when running multiple containers
- Limited to Chrome and Firefox browsers; doesn't support other browsers like Safari or Edge
- Requires Docker knowledge and infrastructure for optimal usage
- May have compatibility issues with certain Selenium versions or test frameworks
Getting Started
To get started with docker-selenium, follow these steps:
- Install Docker on your system
- Pull the docker-selenium image:
docker pull elgalu/selenium
- Run a standalone Chrome instance:
docker run -d --name selenium -p 4444:4444 -p 5900:5900 -e VNC_PASSWORD=secret elgalu/selenium
- Access the Selenium Grid console at
http://localhost:4444/grid/console
- Connect your test scripts to
http://localhost:4444/wd/hub
For more advanced configurations, such as running multiple nodes or customizing browser versions, refer to the project's documentation on GitHub.
Competitor Comparisons
Provides a simple way to run Selenium Grid with Chrome, Firefox, and Edge using Docker, making it easier to perform browser automation
Pros of docker-selenium
- Official Selenium project, ensuring better alignment with Selenium's core development
- More frequent updates and broader community support
- Simpler setup and configuration for basic use cases
Cons of docker-selenium
- Less customization options out-of-the-box
- Fewer pre-configured browser versions available
- Limited support for advanced networking scenarios
Code Comparison
docker-selenium:
selenium-hub:
image: selenium/hub:4.8.0
container_name: selenium-hub
ports:
- "4442:4442"
- "4443:4443"
- "4444:4444"
elgalu/docker-selenium:
selenium:
image: elgalu/selenium:latest
ports:
- 4444:4444
environment:
- SELENIUM_HUB_HOST=selenium
- SELENIUM_HUB_PORT=4444
- GRID=true
- CHROME=true
- FIREFOX=true
The docker-selenium example shows a simpler configuration focused on the Selenium Hub, while elgalu/docker-selenium offers more granular control over browser options and grid settings in the initial setup.
Selenium Hub successor running browsers within containers. Scalable, immutable, self hosted Selenium-Grid on any platform with single binary.
Pros of Selenoid
- Lightweight and faster startup times
- Better resource management with automatic container scaling
- Supports video recording and live browser viewing
Cons of Selenoid
- Less out-of-the-box browser support compared to Docker Selenium
- Requires more initial setup and configuration
- Limited to running on Linux systems
Code Comparison
Docker Selenium configuration:
selenium:
image: elgalu/selenium
ports:
- 4444:4444
environment:
- SCREEN_WIDTH=1360
- SCREEN_HEIGHT=1020
Selenoid configuration:
selenoid:
image: aerokube/selenoid
ports:
- 4444:4444
volumes:
- /var/run/docker.sock:/var/run/docker.sock
- $PWD/config:/etc/selenoid:ro
Both projects aim to provide Selenium Grid functionality using Docker containers. Docker Selenium offers a more straightforward setup with pre-configured browser images, while Selenoid focuses on performance and scalability. Docker Selenium is more suitable for users who need quick setup and cross-platform compatibility, whereas Selenoid is better for those requiring high-performance, resource-efficient Selenium Grid deployments on Linux systems.
Automated driver management and other helper features for Selenium WebDriver in Java
Pros of WebDriverManager
- Language-agnostic: Supports multiple programming languages, not limited to Java
- Easier setup: Automatically manages driver binaries without manual configuration
- Lightweight: Smaller footprint compared to full Docker containers
Cons of WebDriverManager
- Less isolated: Runs on the host machine, potentially affecting system state
- Limited browser versions: May not support as wide a range of browser versions as Docker-based solutions
- No built-in parallel execution support: Requires additional setup for concurrent testing
Code Comparison
WebDriverManager:
WebDriverManager.chromedriver().setup();
WebDriver driver = new ChromeDriver();
Docker-Selenium:
docker run -d --name selenium-hub -p 4444:4444 elgalu/selenium
docker run -d --name chrome -p 5900:5900 --link selenium-hub:hub elgalu/selenium
Key Differences
- WebDriverManager focuses on driver management, while Docker-Selenium provides a complete Selenium environment
- Docker-Selenium offers better isolation and reproducibility across different environments
- WebDriverManager is more suitable for local development and simpler setups, while Docker-Selenium excels in complex, scalable test infrastructures
Use Cases
- Choose WebDriverManager for quick local setups and language flexibility
- Opt for Docker-Selenium when needing consistent, isolated environments or scaling test execution across multiple machines
Deploy headless browsers in Docker. Run on our cloud or bring your own. Free for non-commercial uses.
Pros of browserless
- Designed specifically for headless Chrome automation, offering a more streamlined and focused solution
- Provides a REST API for easier integration and management of browser instances
- Supports concurrent sessions and request queuing out of the box
Cons of browserless
- Limited to Chrome-based browsers, lacking support for Firefox or other browsers
- May require more setup and configuration for complex scenarios compared to docker-selenium
Code comparison
browserless:
const puppeteer = require('puppeteer');
const browser = await puppeteer.connect({ browserWSEndpoint: 'ws://browserless:3000' });
const page = await browser.newPage();
await page.goto('https://example.com');
await browser.close();
docker-selenium:
from selenium import webdriver
from selenium.webdriver.common.desired_capabilities import DesiredCapabilities
driver = webdriver.Remote(
command_executor='http://localhost:4444/wd/hub',
desired_capabilities=DesiredCapabilities.CHROME
)
driver.get('https://example.com')
driver.quit()
Key differences
- browserless focuses on headless Chrome automation, while docker-selenium supports multiple browsers
- browserless offers a REST API for easier management, whereas docker-selenium relies on Selenium's WebDriver protocol
- docker-selenium provides a more traditional Selenium setup, which may be familiar to users of Selenium Grid
Testcontainers is a Java library that supports JUnit tests, providing lightweight, throwaway instances of common databases, Selenium web browsers, or anything else that can run in a Docker container.
Pros of Testcontainers
- Broader scope: Supports various databases, message brokers, and other services beyond just Selenium
- Tighter integration with Java testing frameworks like JUnit and TestNG
- More actively maintained with frequent updates and contributions
Cons of Testcontainers
- Steeper learning curve due to its extensive feature set
- May require more setup and configuration for Selenium-specific use cases
- Potentially higher resource usage when running multiple containers
Code Comparison
Docker-selenium:
docker run -d --name selenium-hub -p 4444:4444 selenium/hub:3.141.59-zinc
docker run -d --name chrome --link selenium-hub:hub selenium/node-chrome:3.141.59-zinc
Testcontainers:
@Rule
public BrowserWebDriverContainer chrome = new BrowserWebDriverContainer()
.withCapabilities(new ChromeOptions());
@Test
public void testWithBrowser() {
chrome.getWebDriver().get("https://example.com");
// Test logic here
}
Docker-selenium focuses specifically on providing Selenium Grid setup with Docker, making it simpler for Selenium-only use cases. Testcontainers offers a more comprehensive solution for various testing scenarios, including but not limited to Selenium, with tighter Java integration. The choice between the two depends on the specific project requirements and the desired level of integration with Java testing frameworks.
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual CopilotREADME
[NOT MAINTAINED] Please use https://github.com/SeleniumHQ/docker-selenium
Selenium in Docker with Chrome and Firefox
- selenium server grid with 2 nodes (chrome & firefox)
- mp4 video recording
- VNC access (useful for debugging the container)
- google-chrome-stable
- google-chrome-beta: no longer provided but can still be found here
- google-chrome-unstable: no longer provided but can still be found here
- firefox stable latest
- firefox stable last 18 versions can be found here
- fluxbox (openbox window manager can still be found here)
Selenium 3 docker run ... elgalu/selenium:latest
Selenium 2 docker run ... elgalu/selenium:2
no longer maintained
Purpose
The purpose of this project is to have Selenium running as simple and as fast as possible.
This purpose is augmented by Zalenium a project which uses this one to provide docker-selenium(s) on-demand.
Zalenium also forwards tests to a Cloud Provider (Sauce Labs, BrowserStack, TestingBot & LambdaTest) when necessary.
Official repo
Note SeleniumHQ/docker-selenium and this one share the same purpose however both projects have diverged considerably in the last two years, some major differences are:
- both browsers and also the grid are on the same container in this repo
- support for video recording
- process manager: this image uses supervisord while the official uses bash
Even though both projects share the same purpose is good to have alternatives, see also for example docker-alpine-selenium. Letting more than 1 docker-selenium project grow to be able to learn from each other's success or failures ultimately impacts the final users positively. This doesn't discard that at some point all selenium maintainers will sit together a sprint to coordinate some major changes and cleanup open issues and perhaps we might merge N similar projects in the future.
Statistics
Alternatives
If you don't require video recording we suggest to use either Google Chrome in headless mode or Firefox in headless mode.
We also recommend avoiding PhantomJS as maintenance was stopped after Chrome & Firefox headless became available.
You can also use a paid service like Sauce Labs, BrowserStack or LambdaTest, note they offer free open source accounts and straightforward integration with Travis CI.
Requisites
This project is normally tested in the last version of Docker and docker-compose and also in the release candidates. To figure out the currently used specific versions it surely works on, see file .travis.yml example values:
docker --version #=> 17.09.0-ce
docker-compose --version #=> 1.16.1
If you need to use docker-machine to run docker (like for example on a Mac before the Docker native version 1.12), you also need to install VirtualBox and then run these commands to get started:
docker-machine create --driver virtualbox default
eval "$(docker-machine env default)"
You will need to run the second eval
command for every new terminal window.
Usage
Run
-
Pull the image and run the container
docker pull elgalu/selenium #upgrades to latest if a newer version is available docker run -d --name=grid -p 4444:24444 -p 5900:25900 \ -e TZ="US/Pacific" -v /dev/shm:/dev/shm --privileged elgalu/selenium
-
Wait until the grid starts properly before starting the tests (Optional but recommended)
docker exec grid wait_all_done 30s # Or if docker exec is not available (eg. circleci) wget --retry-connrefused --no-check-certificate -T 30 http://localhost:4444/grid/console -O /dev/null
After this, Selenium will be up and ready to accept clients at http://localhost:4444/wd/hub
. The grid's available browsers can be viewed by opening the console at http://localhost:4444/grid/console
.
If you are using Mac (OSX) or Microsoft Windows localhost
won't work unless you are in Docker Beta (version >= 1.12) If you are using Docker version <= 1.11 please find out the correct IP through docker-machine ip default
.
Notes:
- The new default
VNC_PASSWORD=no
will make it VNC passwordless accessible. - Once this docker feature is in place
wait_all_done
won't be necessary anymore.
Stop
Shutdown gracefully
docker exec grid stop
docker stop grid
Shutdown immediately, no mercy
docker rm -vf grid
Docker Compose
See docker-compose
Jenkins
See jenkins
Parallel
We now have a better suited product for this use case, is called Zalenium
This image is designed to run one test on each docker container but if you still want to run multiple tests in parallel you can still do so with Zalenium
If you want to limit yourself to this project, you still can. There are some ways to do it:
-
The recommended way is via docker-compose and you should replace
mock
with your web service under test within the [docker-compose-tests.yml][] file.docker-compose -f docker-compose-tests.yml -p grid up --force-recreate docker-compose -f docker-compose-tests.yml -p grid scale mock=1 hub=1 chrome=3 firefox=3
-
The (not recommended) way is by increasing
MAX_INSTANCES
andMAX_SESSIONS
which now defaults to 1.docker run -d --name=grid -p 4444:24444 -p 5900:25900 \ -v /dev/shm:/dev/shm --privileged \ -e MAX_INSTANCES=20 -e MAX_SESSIONS=20 \ elgalu/selenium
The drawback is that all tests will run on the same desktop meaning the video recording will only capture the browser in the foreground but it's in the roadmap to make all this transparent, see issues #78 and #77.
Another problem with increasing MAX_INSTANCES
& MAX_SESSIONS
is focus issues. So in this case is better scale up/down via docker-compose.
OSX
If you are in Mac, you need to get the correct IP of the docker machine. One of these two commands should work to get it:
docker-machine ip default
or former:
boot2docker ip
Screen size
You can set a custom screen size at docker run time by providing SCREEN_WIDTH
and SCREEN_HEIGHT
environment variables:
docker pull elgalu/selenium
docker run -d --name=grid -p 4444:24444 -p 5900:25900 \
-v /dev/shm:/dev/shm --privileged \
-e SCREEN_WIDTH=1920 -e SCREEN_HEIGHT=1480 \
elgalu/selenium
docker exec grid wait_all_done 10s
open vnc://:hola@localhost:5900
TimeZone
You can control and modify the timezone on a container by using the TZ environment variable through the docker run
command, e.g. by adding -e TZ="US/Pacific"
docker run --rm -ti --name=grid -p 4444:24444 -p 5900:25900 \
-e TZ="US/Pacific" \
-v /dev/shm:/dev/shm --privileged elgalu/selenium
Examples:
docker run ... -e TZ="US/Pacific" ...
docker exec grid date
#=> Fri May 20 06:04:58 PDT 2016
docker run ... -e TZ="America/Argentina/Buenos_Aires" ...
docker exec grid date
#=> Fri May 20 10:04:58 ART 2016
docker run ... -e TZ="Europe/Berlin" ...
docker exec grid date
#=> Fri May 20 15:04:58 CEST 2016
Chrome flavor
This feature was available in previous versions, please go to 2.47.1m to use it.
To configure which Chrome flavor you want to use (stable, beta, unstable), just pass -e CHROME_FLAVOR=beta
to docker run
. Default is stable
.
Firefox version
This feature was available in previous versions, please go to 2.47.1m to use it.
To configure which Firefox version to use, first check available versions in the CHANGELOG. Then pass -e FIREFOX_VERSION=38.0.6
to docker run
. Default is the latest number of the available list.
Record Videos
Step by step guide at docs/videos.md
If you create the container with -e VIDEO=true
it will start recording a video through the vnc connection run upon start.
It is recommended to create first a local folder videos
in your current directory, and mount the videos directory for
an easy transfer with -v $(pwd)/videos:/videos
.
Once your tests are done you can either manually stop the recording via docker exec grid /bin-utils/stop-video
where
grid is just the arbitrary container chosen name in docker run
command. Or simply stop the container and that will stop the video recording automatically.
Relevant up-to-date environment variables to customize it are at the Dockerfile, below a possibly outdated list of settings:
FFMPEG_FRAME_RATE=10
FFMPEG_CODEC_ARGS="-crf 0 -preset ultrafast -qp 0 -pix_fmt yuv420p"
FFMPEG_FINAL_CRF=0
FFMPEG_DRAW_MOUSE=1
VIDEO_TMP_FILE_EXTENSION="mkv"
VIDEO_FILE_EXTENSION="mp4"
MP4_INTERLEAVES_MEDIA_DATA_CHUNKS_SECS="500"
VIDEO_FILE_NAME="test"
It is important to note that ffmpeg
video recording takes an important amount of CPU usage, even more when a well compressed format like mp4 is selected.
VNC
When you don't specify a VNC password, the new default VNC_PASSWORD=no
will make it VNC passwordless accessible.
noVNC
Disabled by default, noVNC provides a browser VNC client so you don't need to install a vnc viewer if you choose so. Note: we were using guacamole before.
Safari Browser already comes with a built-in vnc viewer so this feature is overkill and is disabled by default, just navigate to vnc://localhost:5900 in your Safari browser.
You need to pass the environment variable -e NOVNC=true
in order to start the noVNC service and you will be able to open a browser at localhost:6080
docker run --rm -ti --name=grid -p 4444:24444 -p 5900:25900 \
-v /dev/shm:/dev/shm --privileged -p 6080:26080 -e NOVNC=true \
elgalu/selenium
You can provide additional NoVNC options such as ?view_only=false
to allow you to interact with the virtual desktop which now is read-only by default so you don't mess with the tests accidentally.
If the VNC password was randomly generated find out with
docker exec grid wait_all_done 30s
#=> ... a VNC password was generated for you: ooGhai0aesaesh
Issues with Chrome
Chrome crashed
If your tests crashes in Chrome you may need to increase shm size or simply start your container by sharing -v /dev/shm:/dev/shm --privileged
or, alternatively, -v /dev/shm:/dev/shm --privileged
docker run ... -v /dev/shm:/dev/shm --privileged ...
Firefox crashed
Same as Chrome, people have reported the shm fix might also be necessary for Firefox.
Chrome not reachable or timeout after 60 secs
In CentOS and apparently since docker 1.10.0 is necessary to disable sandbox mode through --no-sandbox example client implementation.
The error comes along with this message while starting Chrome:
Failed to move to new namespace: PID namespaces supported. Network namespace supported, but failed: errno = Operation not permitted
No Sandbox
ChromeOptions options = new ChromeOptions();
options.addArguments("--no-sandbox");
In Protrator
capabilities: {
browserName: 'chrome',
chromeOptions: {
args: ['--no-sandbox'],
},
},
However this is now the default of this image, see CHROME_ARGS="--no-sandbox"
in the Dockerfile so don't be surprised to see the "Stability and security will suffer" banner when opening Chrome inside the container.
Cloud Testing Platforms
We now have a better suited product for this use case, is called Zalenium
Additional Uses
Using Xephyr to redirect X to the docker host
Note the below method gives full access to the docker container to the host machine.
Host machine, terminal 1:
sudo apt-get install xserver-xephyr
export XE_DISP_NUM=12 SCREEN_WIDTH=2000 SCREEN_HEIGHT=1500
Xephyr -ac -br -noreset -resizeable \
-screen ${SCREEN_WIDTH}x${SCREEN_HEIGHT} :${XE_DISP_NUM}
Host machine, terminal 2:
docker run --rm --name=ch -p=4444:24444 \
-v /dev/shm:/dev/shm --privileged \
-e SCREEN_WIDTH -e SCREEN_HEIGHT -e XE_DISP_NUM \
-v /tmp/.X11-unix/X${XE_DISP_NUM}:/tmp/.X11-unix/X${XE_DISP_NUM} \
elgalu/selenium
3
Now when you run your tests instead of connecting. If docker run fails try xhost +
Step by step build
Build this image
If you git clone this repo locally, i.e. git clone
it and cd
into where the Dockerfile is, you can:
docker build -t selenium .
Use this image
e.g. Spawn a container for Chrome testing:
CH=$(docker run --rm --name=CH -p=127.0.0.1::24444 -p=127.0.0.1::25900 \
-v /e2e/uploads:/e2e/uploads selenium)
Note: -v /e2e/uploads:/e2e/uploads
is optional in case you are testing browser uploads on your WebApp, you'll probably need to share a directory for this.
The 127.0.0.1::
part is to avoid binding to all network interfaces, most of the time you don't need to expose the docker container like that so just localhost for now.
I like to remove the containers after each e2e test with --rm
since this docker container is not meant to preserve state, spawning a new one is less than 3 seconds. You need to think of your docker container as processes, not as running virtual machines in case you are familiar with vagrant.
A dynamic port will be bound to the container ones, i.e.
# Obtain the selenium port you'll connect to:
docker port $CH 4444
#=> 127.0.0.1:49155
# Obtain the VNC server port in case you want to look around
docker port $CH 25900
#=> 127.0.0.1:49160
In case you have RealVNC binary vnc
in your path, you can always take a look, view only to avoid messing around your tests with an unintended mouse click or keyboard.
./bin/vncview.sh 127.0.0.1:49160
e.g. Spawn a container for Firefox testing:
This command line is the same as for Chrome, remember that the selenium running container is able to launch either Chrome or Firefox, the idea around having 2 separate containers, one for each browser is for convenience, plus avoid certain :focus
issues your WebApp may encounter during e2e automation.
FF=$(docker run --rm --name=ff -p=127.0.0.1::24444 -p=127.0.0.1::25900 \
-v /e2e/uploads:/e2e/uploads selenium)
How to get docker internal IP through logs
CONTAINER_IP=$(docker logs sele10 2>&1 | grep "Container docker internal IP: " | sed -e 's/.*IP: //' -e 's/<.*$//')
echo ${CONTAINER_IP} #=> 172.17.0.34
Look around
docker images
#=>
REPOSITORY TAG IMAGE ID CREATED SIZE
selenium latest a13d4195fc1f About an hour ago 2.927 GB
ubuntu xenial-20160525 2fa927b5cdd3 4 weeks ago 122 MB
DNS
How to share the host DNS
By default docker run
sets the DNS to Google ones 8.8.8.8 and 8.8.4.4 however you may need to use your own.
First attempt is to use --dns
option, e.g.
docker run --dns=1.1.1.1 --dns=1.1.1.2 <args...>
However this may not work for you and simply want to share the same DNS name resolution than the docker host machine, in which case you should use --net=host
along with --pid=host
docker run --net=host --pid=host <args...>
So --pid=host
is included to avoid https://github.com/docker/docker/issues/5899 sudo: unable to send audit message: Operation not permitted
Pid
Full example using --net=host
and --pid=host
but for this to work in OSX you need the latest docker mac package, upgrade if you haven't done so in the last month.
docker run -d --name=grid --net=host --pid=host \
-v /dev/shm:/dev/shm --privileged -e SELENIUM_HUB_PORT=4444 \
elgalu/selenium
docker exec grid wait_all_done 30s
./test/python_test.py
DNS example
docker run -d --net=host --pid=host --name=grid -v /dev/shm:/dev/shm --privileged elgalu/selenium
docker exec grid wait_all_done 30s
Who is using docker-selenium?
Troubleshooting
All output is sent to stdout so it can be inspected by running:
$ docker logs -f <container-id|container-name>
Powered by Supervisor, the container leaves many logs;
/var/log/cont/docker-selenium-status.log
/var/log/cont/selenium-hub-stderr.log
/var/log/cont/selenium-hub-stdout.log
/var/log/cont/selenium-node-chrome-stderr.log
/var/log/cont/selenium-node-chrome-stdout.log
/var/log/cont/selenium-node-firefox-stderr.log
/var/log/cont/selenium-node-firefox-stdout.log
/var/log/cont/supervisord.log
/var/log/cont/video-rec-stderr.log
/var/log/cont/video-rec-stdout.log
/var/log/cont/vnc-stderr.log
/var/log/cont/vnc-stdout.log
/var/log/cont/xmanager-stderr.log
/var/log/cont/xmanager-stdout.log
/var/log/cont/xterm-stderr.log
/var/log/cont/xterm-stdout.log
/var/log/cont/xvfb-stderr.log
/var/log/cont/xvfb-stdout.log
Changelog
See CHANGELOG.md
The sha256 digests are generated after pushing the image to the registry therefore the last version of this docker-selenium will always have digest TBD (to be determined) but will be updated manually at releases
The image ids also change after scm-source.json has being updated which triggers a cyclic problem so value TBD will be set there and updated in the releases page by navigating into any release tag.
How to get container versions
docker exec grid versions
Security
See SECURITY.md
License
See LICENSE.md
Top Related Projects
Provides a simple way to run Selenium Grid with Chrome, Firefox, and Edge using Docker, making it easier to perform browser automation
Selenium Hub successor running browsers within containers. Scalable, immutable, self hosted Selenium-Grid on any platform with single binary.
Automated driver management and other helper features for Selenium WebDriver in Java
Deploy headless browsers in Docker. Run on our cloud or bring your own. Free for non-commercial uses.
Testcontainers is a Java library that supports JUnit tests, providing lightweight, throwaway instances of common databases, Selenium web browsers, or anything else that can run in a Docker container.
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual Copilot