Use this repository to create an environment to perform basic benchmark testing on an API Management instance either using GitHub workflows or manually deploying the Terraform setup. If utilizing the GitHub workflows, create your own repository using this repository as the template and follow the setup instructions. If you choose to manually deploy the Terraform code, you will need to go into the Portal and follow the instructions in the related blog post to run your load tests.
This repo has basic workflows in the .github/
folder and Terraform deployment files in the src/infra
folder.
These are the workflows contained in this repository:
validate.yml
This workflow runs on a pull request to main. It formats and validates your Terraform and then commits the formatting changes back to your branch.build-and-deploy.yml
This workflow runs on a push to main or a manual dispatch. It handles deploying the Terraform code and running three basic load tests.destroy.yml
This workflow runs on manual dispatch. It will delete your Terraform infrastructure on demand.dependabot.yml
Handles package management for GitHub Actions and Terraform versions.
The Terraform code included in this repository demonstrates basic file structure for a Terraform solution:
main.tf
This file contains either resource definitions or references to Terraform modules to deploy.providers.tf
This file contains the Terraform providers needed for the solution and the versions or features required for each.variables.tf
This file contains definitions for variables used in the Terraform deployment.outputs.tf
This file contains definitions for outputs from the Terraform deployment.variables.tfvars
This file contains definitions in the formatvariable_name=example
of variables to be used in the deployment. This file is for local deployments and should NOT be committed to a repository as it may contain passwords, credentials, or other sensitive information.
- API Management Service with a Premium SKU
- App Service hosting a sample api, httpbin
- Application Insights for monitoring APIM and App Service
- Azure Load Test
Three tests are run the deployment workflow using a JMeter script and config files. You can use any JMeter script you already have, but for the purposes of this example, the JMeter script was generated through Azure Load Testing Quick Test. When we perform system testing, we need to look at functional and performance. The CI/CD implementation is intended to demonstrate that anytime you make a change to your environment with APIM, you need to re-run basic load tests as you would unit tests to determine if that change had any effect on your environment's performance. For the purposes of this example, we have demonstrated three basic load tests each run with 500 requests per second (RPS).
- 500 byte payload
- 1,000 byte payload
- 1,500 byte payload
These cases are meant to be a basic example of how you would want to configure your environment setup. Your use cases will differ based on number of users, throughput and other factors.
You will need a service principal that is scoped to either the subscription level or resource group level. This repository uses OIDC authentication for Azure login. This method requires Federated Credentials for GitHub to deploy resources to Azure on your behalf. Follow the steps below for setting them up in the portal or use the Azure CLI or PowerShell instructions in the provided link.
Follow the steps below to setup:
- Navigate to your service principal in the Azure Portal
- Click on Certificates and Secrets and then Federated Credentials
- Click on Add credential and select GitHub Actions deploying Azure resources
- Fill out your organization, repository, and entity type information.
- If you only want users to deploy resources off the main branch, select Branch as the entity type and put main as the branch name.
- If you only want users to deploy resources into a specific environment, select Environment as the entity type and put your environment name in the name field.
- If you only want users to deploy resources during a pull request, select Pull request as the entity type.
- If you only want users to deploy resources off a GitHub tag, select Tag as the entity type.
Create the following secrets in your GitHub repository:
AZURE_TENANT_ID
AZURE_SUBSCRIPTION_ID
AZURE_CLIENT_ID
PUBLISHER_EMAIL
(Email for setting up APIM instance)
STATE_STORE_RGNAME
Existing resource group or name of one to be created for your remote state storage accountSTORAGE_ACCOUNT_NAME
Existing storage account or name of one to be created for your Terraform remote state to be storedSTATE_STORAGE_CONTAINER_NAME
Existing container name or name of one to be created for your Terraform remote state to be storedSTATE_STORE_FILENAME
Existing filename or new filename for your Terraform state fileDESTROY_TERRAFORM
True or False. Whether you want to destroy the Terraform architecture after it's been created through the workflow.LOCATION
Location where you want the Azure resources and Terraform state storage to be deployed.
- Create a feature/fix branch in your repository
- When you create a pull request, it will trigger the validate workflow to check your Terraform syntax and format it.
- Once the validate workflow has completed successfully, you can merge in your changes
- Once the changes are merged in, it will trigger the build and deploy workflow to test deploying the architecture.