by Yogit Thakral, Senior Test Engineer & Kandeel Chauhan, Testing Lead, Naukri.com at STeP-IN SUMMIT 2018 15th International Conference on Software Testing on August 31, 2018 at Taj, MG Road, Bengaluru
Azure Monitor & Application Insight to monitor Infrastructure & Application
Docker–Grid (A On demand and Scalable dockerized selenium grid architecture)
1. DOCKER - GRID
ON DEMAND AND SCALABLE DOCKERIZED SELENIUM GRID
ARCHITECTURE
Kandeel Chauhan, Yogit Thakral
2. Agenda
• Objective (Slide No. 3)
• Introduction of Project (Slide No. 4-7)
• Docker Grid v/s Windows Grid (Slide No. 8)
• How it Works ? (Slide No. 9)
• Case Study (Slide No. 10-13)
• Statistical Data (Slide No. 14-15)
• Conclusion (Slide No. 16)
• References (Slide No. 17)
2
3. Objective
• To create an infra where Selenium Grids are available on-demand.
- Ensure availability to each tester in the team.
- Eliminate waiting time for Jobs in queues.
• To Reduce Execution Time of Test Suites.
• To create a Plug N Play solution compatible with different frameworks.
• To reduce maintenance effort.
• To ensure reliable execution of test scripts.
3
5. Challenges With a Normal/Traditional
Selenium-Grid
• Stability – Encounters with crashes are more often, requires
manual maintenance/rebooting .
• Scalability – Not scalable/Fixed size. We cannot specify number
of nodes or hubs at the runtime for efficient parallel execution.
• Efficiency – Resource Hungry , needs a full OS on separate node
to operate.
5
6. Jenkins Job
(Test Suite
T1)
Jenkins Job
(Test Suite
T2)
Jenkins Job
(Test Suite
Tn)
Hub 2
Node
N3
Node Nn
....................
Host Machine 192.168.0.1
.........................
Node
N2
Node
N1
Hub 1
Node
N3
Node Nn
Node
N2
Node
N1
Hub x
Node
N3
Node Nn
Node
N2
Node
N1
Docker Grid Architecture
6
7. Benefits of Docker-Grid
• Zero Waiting Time:- Since Test Suite will all start executing at once ,
you will experience zero waiting time of your scripts.
• Decreased Execution Time :- Running Test Cases on non-GUI mode
saves execution time.
• Isolated Execution Environment :- Each Test Suite can be executed
inside a separate Selenium Grid Cluster which will be created at
runtime for Test Suite Execution and will be disposed off after we get
our execution Reports.
• Efficient Resource Utilization :- Since you do not need to have a Full
OS installed for setting up Multiple Nodes , it saves a lot of CPU
utilization and System RAM.
• Maintenance Effort :-Since the execution environment will be 7
8. DOCKER GRID V/S WINDOWS GRID
8
FEATURES Windows Grid Docker Grid
Isolated Execution Environment ✔
Scalable ✔
On Demand ✔
Underlying OS Windows Linux
Centalized ✔
Maintainence Free ✔
Hardware Efficient ✔
Zero Waiting Time ✔
Browsers Supported
Chome,Firefox, Opera,
Safari , Internet Explorer
Chome,Firefox,
Opera 8
9. Working Model of Docker Grid
9
Jenkins
Slave(Host
machine)
Docker-
compose file
run
Jenkins Build
NodeSelenium
Hub
Download Project Through Git and Execute
mvn test command
............
Command is
successful
No Dipose the grid
Containers
Yes
Dipose the grid
Containers
Take out the
results and
upload them to
jenkins
10. Case Study:-
# Hardware Infra :-
1) Windows Grid :8 Core 16 GB (4 pcs worth 2 core @2.5ghz 4 gb each).
2) Docker Grid : 8 Core 16 GB (Centralized Linux machine).
10
Capabilities Windows Grid Docker Grid
Max No. of Parallel Browser Sessions Supported 8 24
Suites that can be run at the same time
(Parallel Test Suite Execution)
Single Multiple
Changing the No. of Nodes /Browser Instances
dynamically. ✔
11. Case Study:-
Test Suite Jenkins Build
Status
Test Suite 1 Running
Test Suite 2 Waiting in Queue
Test Suite 3 Waiting in Queue
Test Suite 4 Waiting in Queue
Test Suite 5 Waiting in Queue
Test Suite Jenkins Build
Status
Test Suite 1 Running
Test Suite 2 Running
Test Suite 3 Running
Test Suite 4 Running
Test Suite 5 Running
Before Implementation After Implementation
11
12. Scenario 2 :-Selenium hub Situation on Windows Grid
(Test Suite Running on Staging Server and Live Server Simultaneously)
Jenkins
Slave(Hub)
Hub, Nodes
-- 1.1.1.1
Un
Intentional
Results
Jenkins
Slave(Hub)
Test
Suite1(Staging)
Test Suite 2(Live)
Jenkins
Build
Change host
Entry to Staging
Server
Jenkins
Build
This will also
start Executing
on Staging
server
Jenkins
Slave(Hub1)
Hub, Nodes
-- 1.1.1.1
Hub, Nodes
-- 1.1.1.2
Jenkins
Slave(Hub2)
Test
Suite1(Staging)
Test Suite 2(Live)
Jenkins
Build
Setting host
Entry to Staging
Server
Jenkins
Build
Setting host
Entry to Live
Server
Windows Grid :-
Docker Grid :-
12
Hub 1
Hub2
13. Jenkins Slave Start Execution
ErrorJenkins Slave
Test
Suite1(Test
server)
Test Suite
1(Live)
Jenkins
Build
Downloading
Project Inside
Jenkins Host
Jenkins
Build
Downloading
Project Inside
Jenkins Host
Master
Branch
Debug
Branch
Scenario 3 :-Selenium hub Situation On Windows Grid
Use Case :- Same Project Different Branches/Code Base
Windows Grid :-
Jenkins
Slave(Docker
Host)
Test Suite 1
execution is
isolated .
Test Suite 1
execution is
isolated .
Jenkins
Slave(Docker
Host)
Test
Suite1(Test
server)
Test Suite
1(Live)
Downloading
Project Inside
Hub 1
Jenkins
Build
Downloading
Project Inside
Hub 2
Jenkins
Build
Master
Branch
Debug
Branch
Docker Grid :-
13
14. Statistics:- For Single Test Suite Execution
Suite Before
Implementation
After Implementation
(With 16 browsers
Sessions)
Percentage decrease
in execution time.
Test Suite A 6 minutes 2 Minutes 66.67%
Test Suite B 40 Minutes 19 Minutes 52.5%
Test Suite C 13 Minutes 4 Minutes 2 Seconds 69.2%
Test Suite D 7 Minutes 30 Seconds 2 Minute 3 Seconds 72.67%
14
15. Statistics:- Execution Time Comparison
Suite Before Implementation After Implementation
(With 3 parallel Grids and 16 Browser sessions)
Test Suite 1 32 Minutes 15 Minutes
Test Suite 2 17 Minutes 7 Minutes
Test Suite 3 38 Minutes 19 Minutes
Test Suite 4 8 Minutes 3 Minutes
Test Suite 5 29 Minutes 14 Minutes
Test Suite 6 55 Minutes 26 Minutes
Test Suite 7 35 Minutes 17.50 Minutes
Test Suite 8 22 Minutes 8.50 Minutes
Test Suite 9 5.5 Minutes 2.50 Minutes
Test Suite 10 31 Minutes 14.50 Minutes
Test Suite 11 120 Minutes 56 Minutes
Total Execution Time 6 hours 30 Minutes <70 Minutes
Percentage Decrease 82.05% Decrease in Overall Execution Time
15
16. Conclusion
After Implementing this architecture :-
1. There is practically zero waiting time of our test suite execution.
2. There is no limit up to which we can increase our execution
nodes, this all depends on how large your VM or physical
machine resources are.
3. This doesn’t require any major modification in your framework ,
just pointing your Firefox/Chrome to correct path(Docker
container path ) will do.
4. This architecture is centralized , so , for all your multiple teams ,
multiple projects , you can use the same powerful infra which can
be maintained easily.
16