Hopefully, these days more and more corporates are moving to SaaS based solutions (ie. Saucelabs and alike) for their test automation infrastructure. But for some reason, if you are running your own on-premise infrastructure using Selenium grid, continue to read.
Recently, I was doing a side project that was completely NodeJs stack for webapi, UI and everything. While I’m doing non-windows stuff, thought its wise to use Google Container Engine to host, run and maintain my containers. Part of this whole thing, I had to do little screen scrapping and can’t use something like Saucelabs. That’s where Gcloud and Kubernetes came in very handy. Below is the setup..
Before we go too far, little bit Kubernetes 101 to set the context
Refer this get started with Google container engine, setup your cluster and node. I’m assuming that your node is setup and ready to go.
We are going to setup a Selenium hub and two selenium chrome nodes and configure them to talk to each other.
Selenium Grid hub setup
Hub Replication Controller – in essence, create a pod from the selenium-hub v2.50.0 image with ONE replication and expose port 4444 for tests to be queued.
While this will start running the pods, there is no standard way to access this from outside. So, next 2 steps
Now, this will create a service but still not exposed to the Internet for you Queue the tests. So, run below command
kubectl expose rc selenium-hub –name=selenium-hub-external — labels=”app=selenium-hub,external=true” –type=“LoadBalancer”
Get services – to get external IP, run below command
kubectl get services
You should see an output something similar (I’ve masked Cluster IP and External IPs)
Test by hitting the external IP
Selenium node-chrome setup
Goal is to setup 2 pods, expose port 5900 for selenium node <–> hub communication
Now, if you go back to your grid console, you should see something like this
Depending on your VMs capacity, you could replicate more agent pods to run tests. This works out fantastic for me and I hope this could save some money if you are still using on-premise selenium grid setup.
Perhaps, you could setup and tear down selenium-nodes on demand based on the requirements provided by your test suite instead of running agents 24/7.
All this source controlled here in Github