CDK template to run appium tests on AWS autoscaled spot *.metal instances

We were struggling for a long time to find a cost efficient and stable way to run our appium tests.
We tried AWS device farm but it was unstable and we took a look at genymotion but it was too expensive.

Finally we found the following article series with the amazing idea of autoscaling spot instances, making the instances mostly available and the costs acceptable:
https://medium.com/swlh/deploying-android-emulators-on-aws-ec2-3-3-autoscaling-bare-metal-instances-cost-optimizations-8fc4e636b81d

So we took this approach and translated it to CDK with help of https://github.com/budtmo/docker-android and voila, we had finally our cost efficient emulators to run our appium tests.

The result can is here: https://github.com/felipeloha/aws-appium

The repository contains a sample apk with basic appium tests and the CDK project.

At the end of the installation you will have:

• An autoscaling group initiating a EC2 spot instance which will be restarted when the spot instance is taken away
• An EC2 instance with a docker compose running the selenium grid, the emulator and the appium server
• A route53 entry containing the EC2 instance public DNS to be able to reach the emulator with a fix url. The entry will be updated on EC2 start.
• A script that copies an apk to the target instance through ssh and runs the tests on the selenium grid

Technical Implementation

The infrastructure ci/appium contains the following resources:

• Autoscaling group with one ec2 c5.metal instance with amazon-linux
• A route53 entry in your configured hosted zone
• An autoscaling policy to turn off the instance during the weekends
• Security groups to ssh into the instance
• Permissions for the instance to run

The instance configuration:

• installs docker, docker-compose, awscli
• runs the selenium grid and an emulator with `ci/appium/docker-compose.yaml`
• updates the route53 entry with the instance public dns name `ci/appium/lib/awsConfig.ts:33`

The script to run the tests run-grid.sh does the following:

• Copies an apk into the instance with a hardcoded name. Beware of the volume mapping in the docker-compose. It is important if you want to modify the wdio.config
• Opens a tunnel to the grid AND to the VNC
• Runs the tests pointing to the selenium grid

Beware of reading the getting started section of the README as you might need some minor changes in the code to get it up and running.

This is just the first step towards an automation. The docker-compose allows scaling the emulators and therefore parallel executions.
Another important cost optimization possibility is to improve the auto scaling so that the instance is only running whenever you need it.

I hope this saves you some time and gets you in the right track towards automated mobile testing.

If you liked this post, please follow me. I would be very grateful ;)