Blog post -
Testing Against DDoS Attacks Part 2 - Customizing the Load Test
Note: This is part 2 in a series of posts showing how you can set up Locust in Google Cloud to do a load/stress test on your website. If you haven’t read that, you should start there. These instructions should be used ONLY for testing websites that YOU own, or have express permission to test. Please do not use these instructions for any other purposes.
The previous post provided instructions on how to set up the environment needed to execute these tests. This post will focus on customizing the Docker images, Locust, and Kubernetes configurations for your tests.
To start, make a copy of the git repository provided by Google. From the terminal, create a folder to work in, then clone the git repository.
| mkdir loadtest && cd loadtest git clone https://github.com/GoogleCloudPlatform/distributed-load-testing-using-kubernetes.gitcd distributed-load-testing-using-kubernetes |
Next, create a project using the gcloud command. You can also do this from the web interface. The project-id is just a name for the project, you’ll be typing it a lot in the upcoming steps. I created a project called baffinbayloadtest The second command will set the project as the active project within the SDK on your machine.
| gcloud projects create PROJECT-IDgcloud config set project PROJECT-ID |
You’ll also need to link the new project to a billing account. You can do this via the CLI or via the billing section on the console. It is unclear to me if the $300 free credits can be used via the CLI, and unfortunately I didn’t think to document the process while setting up initially. The official instructions are here. To link a billing account from the CLI, run the following commands
| gcloud alpha billing accounts list (Copy the billing account ID, which looks like XXXXXX-XXXXXX-XXXXXX) gcloud alpha billing projects link PROJECT-ID --account-id=XXXXXX-XXXXXX-XXXXXX |
Now choose a region to start your test from. This can be easily changed later to start the test from different places around the world. The scripts I’ll be sharing will allow you to start a test from any particular gcloud region. For now, choose whatever zone is closest to you, based on this diagram. Once you’ve determined the zone, run the following command:
| gcloud config set compute/zone ZONE |
Updating the Docker Image.
Since the docker images are quite out of date, you’ll need to update the requirements.txt file used to build the image. Do the following:
cd docker-image/locust-tasksCp requirements.txt requirements.oldnano requirements.txt
Now edit the file, updating the versions to match the below. Then hit control-x to save and exit.
| Flask==0.12.2 gevent==1.2.2 greenlet==0.4.12 itsdangerous==0.24 Jinja2==2.8 locustio==0.8.1 MarkupSafe==0.23 msgpack-python==0.4.8 pyzmq==16.0.2 requests==2.9.1 Werkzeug==0.12.2 |
Let’s take a short break here to talk about the load testing software we are using, Locust. Locust is a testing framework that has a ton of capabilities. It’s open source, doesn’t require overly complicated setup, and can be run in a distributed environment. The example below will only scratch the surface of what is possible.
The specific actions taken by locust are defined in a locustfile. The git repository contains a very basic test set at docker-image/locust-tasks/tasks.py, and changing that is our next step. I recommend you take a look at the locust documentation briefly to better understand the capabilities and what we are about to configure.
In order to make the test more effective, the locustfile will need to be customized to the website you’re testing. Depending on how complex your site is, this might be a challenge. There are a few tools that can be used to map your site, i used http://www.xsitemap.com/ to list all the pages available on my testing website https://bbn-demo.website.
Now we have a list of links to use in our locustfile. Using the format below, you can modify the example to use your links. I’ve also included a file download to increase load on the webserver. The min_wait and max_wait variables set the waiting times between requests in the locust workers. Make sure to adjust those as shown.
|
#!/usr/bin/env python from locust import Locust, HttpLocust, TaskSet, task class MetricsTaskSet(TaskSet): _deviceid = None def on_start(self): self._deviceid = str(uuid.uuid4()) #Heres the tests class MyTaskSet(TaskSet): @task def index(self): self.client.get("/") @task(1) def about(self): self.client.get("/index.html") @task(1) def price(self): self.client.get("/our_services.html") @task(1) def contact(self): self.client.get("/our_products.html") @task(1) def contact(self): self.client.get("/contact_us.html") #Downloading a junk file to increase load @task(2) def products(self): self.client.get("/junk10MB.img") class MyLocust(HttpLocust): task_set = MyTaskSet min_wait = 500 max_wait = 1000 |
This file should be saved as docker-image/locust-tasks/tasks.py. Once this has been done, you can tag, build and upload the image to Google Container Registry.
From the docker-image directory, run the following. Note that the ‘push’ command is different from the original documentation.
docker build -t USERNAME/locust-tasks .docker tag USERNAME/locust-tasks gcr.io/PROJECT-ID/locust-tasksgcloud docker -- push gcr.io/PROJECT-ID/locust-tasks |
Next, we will modify the Kubernetes configuration to use the new images and the correct website. Do the following
| cd kubernetes-confignano locust-master-controller.yaml |
You’ll need to change the url to the docker image you’ve uploaded as well as the TARGET_HOST variable, which should point to the website you’re testing. Note that YAML is very specific about tabs and spaces. Don’t change the indentation, or things may not work.
|
spec: containers: - name: locust image: gcr.io/PROJECT-ID/locust-tasks:latest env: - name: LOCUST_MODE value: master - name: TARGET_HOST value: http://www.bbn-demo.website |
Make the same changes to the locust-worker-controller.yaml file as well.
If you’re still reading this, the good news is that the hard part is done. Locust is configured, the docker images are built, the kubernetes config is ready to go. The bad news is that you’ll have to wait for part 3 of this series to see the scripting. If you can’t wait to test it out, the instructions here will allow you to test your configuration in the meantime.
Stay Tuned to Part 3! Follow us on LinkedIn.
Topics
- Computer security
