Convert Figma logo to code with AI

elgalu logodocker-selenium

[NOT MAINTAINED] Please use <https://github.com/SeleniumHQ/docker-selenium>

1,421
334
1,421
35

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:

  1. Install Docker on your system
  2. Pull the docker-selenium image:
    docker pull elgalu/selenium
    
  3. Run a standalone Chrome instance:
    docker run -d --name selenium -p 4444:4444 -p 5900:5900 -e VNC_PASSWORD=secret elgalu/selenium
    
  4. Access the Selenium Grid console at http://localhost:4444/grid/console
  5. 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 Figma logo designs to code with AI

Visual Copilot

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

[NOT MAINTAINED] Please use https://github.com/SeleniumHQ/docker-selenium

Selenium in Docker with Chrome and Firefox

Build Status Docker Pulls Docker

Selenium 3 docker run ... elgalu/selenium:latest docker-selenium-grid

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:

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

ga-datastudio-docker-selenium

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

  1. 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
    
  2. 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:

  1. 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
    
  2. The (not recommended) way is by increasing MAX_INSTANCES and MAX_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