Skip to main content

Selenium Grid with Docker: custom nodes

In my last post I wrote about creating Selenium Grid with use of Docker. I’ve received some questions about customising node’s containers – by default, Docker containers for Selenium Grid nodes run only one instance of browser per node. It’s important to understand that running Grid on Docker is slightly different approach than running it alone – instead of building huge Grid with multiple nodes and dozens of browsers, you run few smaller, independent machines. If one machine is down – you throw it away and build another one. Great use case of Selenium Grid with Docker is to build Grid’s machines as a self service for teams in your company, or to build it automatically before automated tests trigger, and destroy it after. 

Nevertheless, it is possible to tweak default node’s conteiners, so they would contain more browser instances. In this post we’ll create container with custom Selenium Grid’s node configuration – our container would provide more than one instance of browser. Remember, that if you have an account on Docker Hub, you can host one container for free, so after going through this tutorial you can commit your own container and host it, or just create your own, custom Grid on Docker, tailored to your needs.




Prerequisites 

For purpose of this tutorial, we’ll assume that you’ve already set your Selenium Grid with Docker. If not, see the full step-by-step tutorial in my previous post. Starting point for this post is having hub and at least one node linked and running…


… so right now we’re having Selenium Grid with one node, running one instance of Firefox:


Our goal is to increase number of instances to – let’s say – three Firefox’es. How to do that, since Docker containers are isolated units by default? First thing we have to do is ssh to container. It’s not a simple ssh though, it’s rather connecting to node’s tty:

$ docker exec -it firefox bash

… and we’re in! Now you can execute command on container process:


Changing configuration 

Our node is configured by config.json file. How can we locate it? First, let’s go sudo…

$ sudo su

… and find it!

$ find . -name "config.json"


Our config is in ./opt/selenium/ directory. We can’t open config.json in vi, vim, or any other, because Docker containers are running on minimalistic linux vm’s, without any additional tools. We have apt-get though, so we can add some!

$ apt-get update && apt-get install vim

After downloading vim, let’s edit our config.json. File looks as follows:


We have two maxInstances keys. First one is Selenium RC, which is deprecated, and the second one is WebDriver. Our goal is to change the number of Firefox instances to 3, so let’s change the value of the second maxInstances key from 1 to 3 (“maxInstances”: 3). If you’re having problems navigating through the file by arrows, try to use h,j,k,l keys. When value is changed, save and exit from the file, and then type exit to change user and one more exit to go abandon container’s terminal.

Our new container’s configuration is ready to go. Last thing we have to do is to restart out container:

$ docker restart firefox

If you open your Grid in browser now, you’ll see 3 Firefox instances in Webdriver protocol:


Continue reading 

If you want to continue reading and expand your knowledge in area of Docker and Selenium Grid, I recommend you these books:

Summary 

Although recommended approach to work with Selenium Grid with containers is slightly different, Docker gives you many possibilities. It’s always good to search your own, best solution. If you have any thoughts or questions – leave a comment!




Popular posts from this blog

Test Automation: Good, Bad and Ugly

The modern approach to software quality and software development life cycle requires that business guys, developers and testers understand that the long manual test phase, although often still necessary, must be reduced to a minimum and replaced by test automation. Working in continuous delivery and continuous integration environment requires us to create automated tests that run on demand, checking our application integration and it’s core functionality correctness. However, there are still many problems with designing and writing automated tests, resulting in their costly maintenance or abandonment in favour of a return to manual processes.
In this article I will focus on describing common good practices of test automation. This post is more than an overview than complete reference guide. Broader aspects, such as the Page Object pattern or Page Factory will be described in detail in a separate article on this blog. Although most practices apply for every types of automated tests, thi…

REST-Assured framework overview

In modern software development, REST services becomes most popular choice for implementing distributed and scalable web application. They are light and easy to maintain, which results in faster and more effective implementation and system integration.
I recommend you also my other posts about REST-Assured and building microservice’s test automation frameworks: REST-Assured: going deeperBuilding microservices testing framework
With the increase popularity of RESTful services, there is a need for fast and lightweight tool for REST webservices testing automation. One of the most popular choice is Rest-Assured framework from Jayway. It introduces simplicity of testing web services from dynamic languages like groovy or ruby to java. In this post we will get our hands dirty and write automatic test in Rest-Assured framework.
In order to create complete implementation of automated tests in Rest-Assured framework, we need to write our code against some example API. We’ll use standalone Wiremock m…

REST-Assured: going deeper

In my previous post I described the basic REST-Assured usage – the lightweight framework for testing RESTful services. Despite the fact that described range of functionalities would be enough in most cases,REST-Assured has a lot more to offer. In this post I would like to bring some more advanced examples of the framework usage.



I recommend you also my other posts about REST-Assured and building microservice’s test automation frameworks:

REST-Assured – framework overviewBuilding microservices testing framework
Object Mapping Sending request’s body as string is easy and straightforward, but it can be inconvenient in the case of more complex operations on request / response properties. Proven solution for this is a good-known serialization of request/response body to objects. REST-Assured supports object mapping to (and from) JSON and XML. For JSON you need either to have Jackson or Gson in your classpath and for XML you need JAXB. Here is an example of request object serialization using J…