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

Testing Asynchronous APIs: Awaitility tutorial

Despite the growing popularity of test automation, most of it is still likely to be done on the frontend side of application. While GUI is a single layer that puts all the pieces together, focusing your automation efforts on the backend side requires dealing with distributed calls, concurrency, handling their diversity and integration. Backend test automation is especially popular in the microservices architecture, with testing REST API’s. I’ve noticed that dealing with asynchronous events is particularly considered as challenging. In this article I want to cover basic usage of Awaitility – simple java library for testing asynchronous events. All the code examples are written in groovy and our REST client is Rest-Assured. Synchronous vs Asynchronous  In simple words, synchronous communication is when the API calls are dependent and their order matters, while asynchronous communication is when the API calls are independent. Quoting Apigee definition: Synchronous  If a

Rerun Flaky Tests – Spock Retry

One question I get asked a lot is how you can automatically rerun your test on failure. This is a typical case for heavy, functional test scenarios, which are often flaky. While test flakiness and its management is crucial and extensive matter itself, in this post I want to give a shout to the extremely simple yet useful library: Spock-Retry. It introduce possibility to create retry policies for Spock tests, without any additional custom-rules implementation – just one annotation. If you are not a fan of Spock testing framework and you prefer JUnit – stay tuned! I will post analogous bit about rerunning JUnit tests soon. Instalation  If you are an maven user, add following dependency: <dependency>       < groupId > com.anotherchrisberry < /groupId >       < artifactId > spock-retry < /artifactId >       < version > 0.6.2 < /version >       < type > pom < /type >   </dependency> For gradle users:

Performance Testing – Vegeta Attack!

Performance testing is crucial field of modern software development. Taking into account that in today’s world majority of app’s communication is web-based, it turns out to be even more important. However, it still enjoys less interest than automated functional testing, and publications on load testing subject usually focus on mature and complex tools like JMeter or Gatling. In this post I’d like to introduce command line usage of a super simple and lightweight tool for performance testing of HTTP services, which is Vegeta. Who is Vegeta  Besides Dragon Ball’s character, Vegeta is a simple load testing tool written in GO, that can be used both from command line and as an external library in your project. In order to use Vegeta, download executables from here . It is recommended to set environment variable for ease of use.  For Mac users, you can download vegeta directly from Homebrew repositories: $ brew update && brew install vegeta Vegeta’s Arsenal  Usage