Git Based Configuration Management for Azure API Management
For each Azure API Management instance, it has a database that contains the configuration information for that instance. These include the configuration related to APIs, Products, Groups as well as the policies we create for the APIs etc. There are several ways of managing configuration for Azure API Management that includes, using the Azure Portal, using PowerShell and the REST API. Also, you can make changes by using a Git Repository. This allows you to make changes in bulk, meaning you can do changes to multiple areas of the API Management instance and deploy the at once and also version the changes that you make allowing you to easily rollback changes if you want.
We’ll see how we can enabled Git Based Configuration and how we can deploy the changes. To start, navigate to your Azure API Management instance in the Azure Portal and under the Security section of the menu, Click on Repository.
In the new blade, you can see the URL to clone the Git repository to your local PC. Here you can see the Repository URL, and current Commit in Use as well as Last Configuration Sync time and Last Config Change time. Since we are enabling this for the first time, the Commit in Use and Last Config Sync values should be empty.
On this blade, click on the Save To Repository button. It will open up a new blade.
Here you can enter the branch name and the commit message for the initial configuration save. Add the relevant values and click on Save button.
Once you have created the initial configuration save, you can see the commit in use and last config sync values populated. Next you need to generate the credentials needed to clone the Git Repository and work with it.
Click on the Access Credentials button to open up the Access Credentials blade.
Here you can see the username for git and then you can generate the password for accessing the repository. You can set an expiry time for the password with a maximum date range of 30 days. You can select the which secret key to generate the password. And the click on Generate button to generate the password.
Note: Make sure to save the password somewhere since you can only see the password once.
Next clone the repository down to your local development machine.
Use the username and the password that was generated when prompted. (I am using Git Extensions for cloning and committing. You can use the command line or any GUI tool you use)
To make a change to the configuration, I am going to add a inbound rule to Rate Limit the API. I have the Calculator API hosted by Microsoft (http://calcapi.cloudapp.net/) configured as an available API in Azure API Management Instance. I am going to add the inbound rate limiting policy at the API level.
I have opened up the repository in VS Code. I am not going in to the structure of the project. Look at the documentation for more details.
Here I am adding the rate-limit rule with allowing 10 calls in a period of 10 seconds with the subscription ID as the key to uniquely identify the request.
Once done with the changes next step is to commit the changes.
I am going to commit the changes and push the changes to the API Management git repository. Once the changes are pushed, still the change won’t take effect. You need to deploy the changes to the API management database in order for the changes to take effect.
On the Repository blade, click on the Deploy to API Management to trigger the deployment.
Then you need to set the branch name to deploy and click on Deploy button to deploy the changes to the API Management instance.
To make sure the changes are made to the API Management instance, when you navigate to the APIs Section and click on the API (Basic Calculator in my case) and select All Operations, you can see the rate-limit-by-key policy is added to the inbound processing section.
Also, if you check the code view for the inbound policies you can see the rate-limit rule we added in XML is there.
So that is how you would manage the configuration for your Azure API Management using a git-based workflow by enabling Git based configuration management.
You Might Also Like
← Previous Post
Managed Service Identity for Azure Resources
April 28, 2018
Next Post →