What you'll learn
- How to create and configure an Aurora Serverless v1 cluster with DataAPI to use with Artillery Pro
- How to configure Artillery Pro to use an Aurora Serverless cluster
- How to seed the initial database and run data migrations
Artillery Pro can be configured to use an Aurora Serverless v1 cluster (via Data API) as the backing store.
The Aurora Serverless database will be used to store information such as test run history, and associated test run data such as metrics, logs, notes and annotations and so on. The data can be queried via the CLI or through the web dashboard.
Artillery Pro does not provision a database cluster as part of its deployment. An Aurora Serverless v1 cluster has to be created separately, and its configuration needs to be provided to Artillery Pro. The rest of this document provides a walk-through of creating and configuring an Aurora Serverless v1 cluster for Artillery Pro.
Aurora Serverless v1 support is in beta. We do not recommend running production workloads with an Aurora Serverless cluster yet.
- Only Aurora Serverless v1 is supported, as Aurora Serverless v2 does not provide a Data API yet
- Only Postgres is supported as the underlying database engine
- If you're relying on current DynamoDB support note that Artillery Pro will not migrate existing data automatically from Dynamo to Aurora. Please get in touch via firstname.lastname@example.org if you need assistance migrating existing data.
Create a new Aurora Serverless v1 cluster
Run the following command to create a new database cluster:
export DB_PASS=`pwgen 32 -1` # generate a random 32-character string; substitute if needed
export REGION=us-east-1 # change this to the region you deployed Artillery Pro into
aws rds create-db-cluster \
--region "$REGION" \
--db-cluster-identifier artilleryio-cluster \
--engine aurora-postgresql --engine-version 10.14 \
--engine-mode serverless \
--scaling-configuration MinCapacity=2,MaxCapacity=4,SecondsUntilAutoPause=1000,AutoPause=true \
--master-username postgres \
--master-user-password "$DB_PASS" \
This command will return a JSON response. Take note of the following fields, which will be needed for further steps:
Create a Secrets Manager secret
Create a JSON file with credentials
Create a JSON file in
artillery-db-cluster-creds.json containing the following information:
"password": "<password we generated in $DB_PASS>",
password values with the value of
Endpoint field from the previous step, and the value of
Create a secret
Now we can use the JSON file to create a Secrets Manager secret:
aws secretsmanager create-secret --secret-string file://artillery-db-cluster-creds.json \
--region "$REGION" \
--name "artilleryio/db-credentials" \
Do not change the name of the secret as Artillery Pro expects it to be
artilleryio/db-credentials, and won't have IAM permissions to read any other secrets.
The command will return a JSON response. Take note of the
ARN field as we will need it in the next step.
Configure Artillery Pro to use the database cluster
Artillery Pro will look for database configuration in
BACKEND_DATABASE_CONFIG config value, and use that if it exists. The value of the
BACKEND_DATABASE_CONFIG is expected to be a string containing a JSON object with the following fields:
type- set to
secretArn- the ARN of Secrets Manager secret we created in the previous step
resourceArn- the ARN of the database cluster we created in the first step
region- the region in which the database cluster was created
database- set to
set-config-value command to create database configuration for Artillery Pro:
artillery set-config-value \
--region "$REGION" \
--name BACKEND_DATABASE_CONFIG \
Run database migrations
The final step is to initialize the new database with a schema.
artillery admin:run-db-migrations to initialize the database. The output should look similar to the following:
query: SELECT * FROM current_schema()
query: SELECT * FROM "information_schema"."tables" WHERE "table_schema" = 'public' AND "table_name" = 'migrations'
query: CREATE TABLE "migrations" ("id" SERIAL NOT NULL, "timestamp" bigint NOT NULL, "name" character varying NOT NULL, CONSTRAINT "PK_8c82d7f526340ab734260ea46be" PRIMARY KEY ("id"))
query: SELECT * FROM "migrations" "migrations" ORDER BY "id" DESC
query: CREATE TABLE "test_run" ("id" SERIAL NOT NULL, "testRunId" character varying NOT NULL, "status" character varying, "createdTime" TIMESTAMP, "startedAt" TIMESTAMP, "endedAt" TIMESTAMP, "metadata" jsonb, "launchConfig" jsonb, "tasks" text, "tags" jsonb, CONSTRAINT "PK_011c050f566e9db509a0fadb9b9" PRIMARY KEY ("id"))
query: CREATE TABLE "tag" ("id" SERIAL NOT NULL, "tagString" character varying NOT NULL, "name" character varying NOT NULL, "value" character varying NOT NULL, CONSTRAINT "UQ_89afdbf8c60805ec429a25c5aa5" UNIQUE ("tagString"), CONSTRAINT "PK_8e4052373c579afc1471f526760" PRIMARY KEY ("id"))
If you're testing Aurora Serverless support with a secondary Artillery Pro deployment, remember to set
ARTILLERY_BACKEND environment variable accordingly before running migrations.
Once Aurora Serverless database cluster is configured, Artillery Pro will use it to store all test related data. No changes are required to how tests are invoked. The upgrade is designed to be completely transparent.