DEV Community: Daniel Edwards

Running Gatling in Azure Container Instances Part 2 - Adding an API to control Gatling

Daniel Edwards — Mon, 23 Sep 2019 11:38:41 +0000

Part 1 - Getting Gatling to run in Azure

In the last post, I went over a way to run Gatling in Azure Container Instances by mounting certain Azure Storage and editing configuration files. It was a somewhat hacky way to get it running and could certainly improved.

It this article I will go into one way of automating it - adding an ASP.NET API on top.

Step one - Creating a custom Docker runtime container

The first step was to take the original Gatling docker container (denvazh/gatling) and use it as a base to create an image that has the dotnet dependencies baked in.

This was a fairly simple process of adding the parts from the runtime-deps image and then adding on the parts needed for ASP.NET to run.

You end up with this dockerfile.

FROM denvazh/gatling:3.0.3

RUN apk add --no-cache \
        ca-certificates \
        \
        # .NET Core dependencies
        krb5-libs \
        libgcc \
        libintl \
        libssl1.1 \
        libstdc++ \
        lttng-ust \
        tzdata \
        userspace-rcu \
        zlib

# Configure web servers to bind to port 80 when present
ENV ASPNETCORE_URLS=http://+:80 \
    # Enable detection of running in a container
    DOTNET_RUNNING_IN_CONTAINER=true \
    # Set the invariant mode since icu_libs isn't included (see https://github.com/dotnet/announcements/issues/20)
    DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=true

# Install ASP.NET Core
ENV ASPNETCORE_VERSION 2.2.7

RUN wget -O aspnetcore.tar.gz https://dotnetcli.blob.core.windows.net/dotnet/aspnetcore/Runtime/$ASPNETCORE_VERSION/aspnetcore-runtime-$ASPNETCORE_VERSION-linux-musl-x64.tar.gz \
    && aspnetcore_sha512='d3c1cc27998fc8e45fbf0c652a8d8694e999a3cd5909f83fb11b1e5cf713b93f4e7614c4b74c92d6c04f0b0759373b6b6ff7218d9d143d36bb9b261ef8161574' \
    && echo "$aspnetcore_sha512  aspnetcore.tar.gz" | sha512sum -c - \
    && mkdir -p /usr/share/dotnet \
    && tar -zxf aspnetcore.tar.gz -C /usr/share/dotnet \
    && rm aspnetcore.tar.gz \
    && ln -s /usr/share/dotnet/dotnet /usr/bin/dotnet

I currently have this published on dockerhub here.

With that made we have our runtime image.

Step two - Creating the API

Visual Studio comes with some decent Docker templates already, so I started with a blank API with docker support. After that's spun up, the only change I needed to make in the dockerfile it created was changing the base to my own.

FROM dantheman999/gatling-aspnet AS base # Change the base image
WORKDIR /app
EXPOSE 80
EXPOSE 443

FROM mcr.microsoft.com/dotnet/core/sdk:2.2 AS build
WORKDIR /src
COPY ["Gatling.Runner.csproj", ""]
RUN dotnet restore "./Gatling.Runner.csproj"
COPY . .
WORKDIR "/src/."
RUN dotnet build "Gatling.Runner.csproj" -c Release -o /app

FROM build AS publish
RUN dotnet publish "Gatling.Runner.csproj" -c Release -o /app

FROM base AS final
WORKDIR /app
COPY --from=publish /app .
ENTRYPOINT ["dotnet", "Gatling.Runner.dll"]

Then it was a case of creating the API itself. There were two approaches I was considering for this:

Continuing on with my original plan, mounting Azure Storage when the container is created, leaving the possibility of it being shared across multiple containers.
Adding the simulation into the container directly when starting a new test.

I ended up opting for option 2. It gives much more flexibility, for example you could have the container running whilst you run multiple different tests before tearing it down, or having tests running concurrently if you so desired.

Below I'm going to walk through some of the code used to get this to work. You can either follow it along or have a little look around the repo.

deadwards90 / Gatling.Runner

Azure + Gatling - Running Gatling in the Cloud

The projects in the repo contain applications that help to run Gatling in an automated fashion in Azure.

Currently there is:

base-image: The folder containing a Gatling Docker container that can also run .NET Core applications.
src/Gatling.Runner: An API for running Gatling tests on a machine. Combined with the Gatling container above this allows remote running of Gatling tests in the Cloud.
src/Gatling.Orchestrator: A Durable Function for orchestrating running Gatling tests across multiple Azure Container Instances with returns a single combined result.

View on GitHub

The Controller (GatlingController.cs)

The controller has 3 endpoints:

Start
StartAsync
GetResults

Start will take a test upload, store the files, run the test and return the results as one operation. StartAsync and GetResults do the same thing except StartAsync will just return the runId which can be used to query the results whilst the test is running in the background.

Starting with the simplest method, Start.

It is basically as explained above. We take the runId and create the folders necessary for Gatling to run. If the full report is required, then it will run the simulation and return a zip of the result, otherwise it will return the results of the run which is just the console output created by Gatling when it runs.

Then we have the async version of this which is a little more complicated.

It takes the same format of request as Start, but all it does is creates the folders and then queues up a job to be run asynchronously in the background, before returning the runId location.

You could then poll the GetResults endpoint for the run, which will return the zipped up Gatling results when completed (or return that there was a failure).

The Services

File Service (FileService.cs)

Two very simple methods here, one for creating the necessary folder structure for Gatling to run and the other that creates a FileStream to send back the zipped results folder.

One thing to notice here is that it reads a file out of the zip provided through the controller called run.json. All this has in it at the moment is the name of the simulation to run.

{
    "SimulationClassName": "apimsimulations.ApiMSimulation"
}

Gatling Service (GatlingService.cs)

The only job this has so far is to run the a test given the RunSettings from the FileService is to run that against Gatling, and that is done by just running the process and waiting for it to finish. You can see what each of the command line arguments for Gatling does here, but for the most part we are just telling it where things are and what simulation we wish to run.

The Background Services

For the asynchronous methods, I took the skeleton of the code from the ASP.NET Core documentation and changed a few pieces of it. The main change was to add a jobId to an item when queued which had an accompanying state. When the job was finished, its state was updated for the GetResults endpoint.

Job Status Service (JobStatusService.cs)

This service keeps track of the state for a run. Obviously not ideal using a ConcurrentDictionary as a data store but given the container should be spun up for one or two jobs before being destroyed, it works fine.

Background Task Queue (BackgroundTaskQueue.cs)

This is pretty much a copy of the documentation example, except we now have it taking a Tuple with the job id and job to run. When the job gets queued, it's State is set to started which is a little wrong in all honesty as it's only been queued up at this point.

Queue Hosted Service (QueueHostedService.cs)

Finally the task is dequeued here, and run. Once finished its State is updated so that the controller knows it can pick up the results.

Step 3 - Run a request

With all of this set up, we can now run a test!

Create a zip with your simulation (and resources if you have them) in the same format as it would be in the Gatling folders, and also your run.json that was explained earlier.

Send a request to the API on api/gatling/start/{uuid}?returnReport=true (easiest just to start with the synchronous method) with your zip file attached. The request will take as long as your simulation is, plus around 10 seconds for the initial start up time.

And that's it 🎉 You now have a remotely controlled Gatling that can be hosted in Azure once it is built.

If you just want to directly play around with container without compiling it yourself, you can grab it here.

Next steps

In part three, I will be creating a wrapper around this in Azure that will

Create a set number of Azure Container Instances of the container, possibly in mulitple regions
Set them all to run a test using a similar API as the one in the container (with more checking that the zip looks "correct").
Wait for them all to finish and get all the simulation.log.
Merge the log files and create a master report.

Running Gatling in Azure Container Instances Part 1 - Getting Gatling to run in Azure

Daniel Edwards — Fri, 13 Sep 2019 07:42:27 +0000

Part 2 - Adding an API to control Gatling

I am going to preface this by saying that I know rather little about Gatling overall so this was a best effort to get this at least running. I could not find any other tutorials on how to have Gatling running at all in Azure.

I will also assume if you are reading this you have at least some knowledge of Azure and the Azure CLI.

Setting Up

If you are unaware of what Azure Container Instances are, I would suggest having a quick read through this page. Essentially they can provide a short lived container for a very cheap price.

Creating the Azure File Shares

The first thing you're going to need is an Azure Storage Account which can be either created through the portal or through a small script.

az storage account create \
    --resource-group gatling \
    --name stgatling \
    --location uksouth \
    --sku Standard_LRS

You will then need a three file shares, conf, user-files and results

az storage share create --name conf --account-name stgatling 

az storage share create --name user-files --account-name stgatling 

az storage share create --name results --account-name stgatling

And finally you're going to want to grab the account key.

az storage account keys list --resource-group gatling --account-name stgatling --query "[0].value" --output tsv

Of course you can also grab this very simply through the portal.

Creating the Container Instance

Now you're going to want to create a YAML file to deploy the Gatling container. To do this we'll be using the container groups template but just deploying the one container. Below is an example that should work, you will just need to insert your storage key into the the volumes.

apiVersion: '2018-10-01'
location: uksouth
name: gatling-aci
properties:
  containers:
    - name: gatling
      properties:
        environmentVariables: []
        image: denvazh/gatling
        ports:
          - port: 80
        resources:
          requests:
            cpu: 1.0
            memoryInGB: 1.5
        volumeMounts:
          - mountPath: /opt/gatling/conf
            name: conf
          - mountPath: /opt/gatling/user-files
            name: user-files
          - mountPath: /opt/gatling/results
            name: results
  osType: Linux
  restartPolicy: Never
  ipAddress:
    type: Public
    ports:
      - port: 80
    dnsNameLabel: gatling-test
  volumes:
    - name: conf
      azureFile:
        sharename: conf
        storageAccountName: stgatling
        storageAccountKey: <insert-storage-key-here>
    - name: user-files
      azureFile:
        sharename: user-files
        storageAccountName: stgatling
        storageAccountKey: <insert-storage-key-here>
    - name: results
      azureFile:
        sharename: results
        storageAccountName: stgatling
        storageAccountKey: <insert-storage-key-here>

tags: {}
type: Microsoft.ContainerInstance/containerGroups

This will create and start your container group. What should happen at this point is Gatling will run but then stop very quickly as there are no simulations to run.

Uploading the configuration

So we need to go ahead and upload those to the file share user-files. There are a number of ways you can go about this depending on what OS you are using, starting off with mounting the Azure File Shares we made earlier:

Alternatively you could upload the files through Azure Storage Explorer or through the portal.

Our folder had a simulations and resources folder directly under it.

(Ignore the bad naming)

Finally, we're going to want to take the default gatling.conf and edit two lines.

First one to edit is runDescription to be anything that isn't a blank string. Whatever your run is going to be!

Secondly, edit simulationClass to be the fully qualified class name of simulation you wish to run. For us this was apimsimulations.ApiMSimulation (we were testing out an API Management integration).

Now upload that into the conf file share.

Running the simulation

You're now all set to run the simulation.

az container start \
   --resource-group gatling
   --name gatling-aci

Container start up should be fairly quick and it will compile your simulation and run it. The easiest way to see what it is doing is just to check the logs through the portal, or you can get these from the cli.

az container logs \
   --resource-group gatling
   --name gatling-aci

At the end it should say that it has generated the report(s)

Reports generated in 2s.
Please open the following file: /opt/gatling/results/apimsimulation-20190912115211503/index.html
Global: count of failed requests is 0.0 : true
Global: mean of response time is less than 500.0 : true

And then you can retrieve those from the file share using the same method as you did to upload the files.

TODO

There are quite a few things I'd like to work out how to do, some of which I think would be fairly simple:

Running Gatling in non-interactive mode. This should just be editing the startup command (entrypoint) for the container instance to include the simulation you wish to run. This could allow for a level of automation...
Working out how to get the container to stop once it has finished running.
Automating this whole process. You could use an Azure Function to create a container on demand, mounting onto the file shares. It then would just need to specify a simulation to run in non-interactive mode, wait for completion and stop / delete the container.

For a first attempt though, pretty happy with how far I managed to get it. Little cheaper and somewhat easier than spinning up a whole VM to do this!