Why would I consider Selenium Grid through Docker, if I were you

Lots of QA engineers work with Selenium Webdriver and much more people just heard about it. Whether we want it or not, automated testing of web applications depends on this tool a lot. It means it’s not enough just take it and use, we should do it effectively. And here lies the trick – different browsers with their own specific drivers and versions, different OSs make our life too complicated, even overcomplicated I’d say. Managing such dependencies and capabilities isn’t always an easy task.  However, we live in the modern world where even Selenium can be tamed. So, I’m not gonna explain the basics (how to install it, select a browser, find an element, blah-blah-blah…). Let’s have a look instead what benefits combining Selenium Grid with the Docker ecosystem can bring us.

Challenge: to setup Selenium Grid with nodes on the remote machine through docker.

Docker is getting better and better every day so far. Three years ago almost nobody knew about Docker except Linux community members. Nowadays, Docker is growing up, conquering new peaks and offering more and more features for developers, DevOps engineers, sysadmins and us, QAs. If you are not familiar with Docker basics yet, here is a couple of links to catch up:

Let’s assume that Docker is installed and running. The very first step is to pull a hub image from the official Selenium repository. It can be done by executing the following command:

docker pull selenium/hub

When the image is downloaded, we can run it in the container by the following command:

docker run −d −p 4444:4444 −−name myHub selenium/hub

There are 2 important options in the command above:

  • −p 4444:4444 – expose the Selenium hub 4444 port inside the docker container to the same 4444 port outside the container (on the host). You are allowed to specify any other pair of free ports but pay attention that Selenium hub console will be accessible” remotely (from your local workstation) through the remote machine IP and the port mentioned earlier;
  • −−name myHub – where myHub is an alias for the hub container. We will attach Selenium nodes to the running hub using this alias later on.

After the hub container on the remote docker machine is started, it’s accessible on the local workstation by the following URL:


For example, if the remote machine IP is, your hub will be available by the URL. If it’s not available, please check the firewall on the remote machine with the docker/Selenium hub running – it might filter and block outgoing traffic. In case if you want to access the Selenium Grid console from the remote machine directly, it’s available by the http://localhost:4444 URL.

Before proceeding to the node deployment, we can check the just started Selenium hub in the 2 ways:

  1. By running the docker ps command. We will see the list of running containers and our Selenium hub in it with all data specified before (alias, exposed port);
  2. By executing the docker logs myHub command where we will see logs generated by the hub itself. This command is also very useful from that point of view that we can see registered nodes in its output.

Now we can move on to the node installation. Like we’ve done with the Selenium hub, we need to pull docker images for required browser we’d like to install on the node. The Official Selenium repository contains 3 node images for different browsers for now: Chrome, Firefox and PhantomJS. Let’s pull the first two images one by one:

docker pull selenium/node-chrome
docker pull selenium/node-firefox

When images are downloaded, it’s time to register them on the hub. We can do that adding the link flag to the known docker run command. This option links running containers to the hub and allows them talks to each other. For example:

docker run −d −−link myHub:hub −−name chrome selenium/node-chrome
docker run −d −−link myHub:hub −−name firefox selenium/node-firefox

When we run the docker ps command again, we should see our hub and 2 node containers running. The registered nodes are also displayed in the Selenium Grid console (available by the URL in our example). Now our Selenium Grid is set up and we can use it in our tests in a usual way:

The code above displays a typical example of the Selenium Grid test which can be easily extended by using features of unit test frameworks (JUnit, TestNG), i.e. we can run tests in different browsers, run tests in parallel, put different capabilities and parameters to our tests. But in the case of combining Selenium Grid with Docker we gain additional benefits:

  • no need to manage Selenium server jar – it’s done automatically inside the Selenium hub container;
  • no need to download browsers drivers and configure classpath – for the same reason;
  • registering nodes on the hub is done much more easily, Grid is easily extendable and manageable.

Like this post?

Subscribe to updates from my blog, if you don't want to miss more interesting future posts and materials

Please check your email and confirm subscription

Pin It on Pinterest

Share This