Part 1: Introduction of Custom Resource Provider
Azure Custom Resource Provider (CRP) is an extensibility platform to Azure. It extends Azure Resource Manager (ARM) REST API to not only include internal services, but also external services. It enables custom scenarios on top of existing Azure workflows. Also, with the CRP, you can customize ARM template control and effect.
CRP is a high-efficient option to manage your resources because there is no need to switch tools back and forth. You can use ARM to manage both internal and external resources at the same time. It does help save time in managing external resources since you can modify the existing ARM template in your hand to extend to external resources and modify the existing CLI/PowerShell script to easily create/read/update/delete external resources.
CRP is a contract between Azure and an endpoint, which defines a list of new resources and actions via a new resource type called “Microsoft.CustomProviders/resourceProviders”. This contract describes how Azure should interact with an endpoint. The CRP acts like a proxy and will forward requests and responses to and from the specified endpoint.
Reference: https://docs.microsoft.com/en-us/azure/azure-resource-manager/custom-providers/overview
Part 2: Deploy Custom Resource Provider
Same as other resources, you can use the ARM template to deploy the CRP to your Azure subscription(s). The example ARM template below can be deployed through Azure CLI, PowerShell, or the Azure Portal.
Example template: https://github.com/Azure/azure-docs-json-samples/blob/master/custom-providers/customprovider.json
As you can see in the detailed ARM template below, the CRP contains two kinds of properties: resourceTypes and actions. These are enabled through endpoint definitions. An endpoint definition is comprised of three fields: name, routingType, and endpoint.
- resourceTypes –describe new custom resources that are added to Azure. These expose basic RESTful CRUD methods. It handles GET, PUT, and DELETE.
- Actions – describe new actions that are added to Azure. These can be exposed on top of the resource provider or nested under a resourceType. It handles POST.
After the ARM template deployment succeeds, the CRP can be found in Azure portal by selecting the “Show hidden types”.
Part 3: Synchronous Deployment vs. Asynchronous Deployment
Synchronous deployments are typically used when the client must wait to receive the response before processing continues on the client side. In this case, the deployment blocks the main thread until ARM responds and the client only receives one response indicating if the deployment is successful.
Asynchronous deployment is a good option for the operation that cannot be completed quickly. Some operations may take long time to complete, so asynchronous deployment can help you avoid this long procedure without no status of deployment. This kind of deployment does not block the main thread. The client keeps sending requests and receives multiple responses that indicating the status of deployment.
In our case, we can identify the Synchronous deployment and the Asynchronous deployment by checking the response code. When a PUT request returns 200 OK, it is considered as a Synchronous operation. When a PUT request returns 201 Created/Accepted, it can be recognized as an asynchronous operation. Client is expected to receive the provisioning state and Location header with the 201 response code.
Part 4: Use Function App to achieve the Asynchronous Deployment
We recommend using Function App as an endpoint. Any other Web Hook endpoint can be used as well. In this blog, we use the Function App as an example. You can download the sample project with the link below.
Example Function App code: Please check the attachment of this blog
Custom resources are a way to declare a resource type of your own. To achieve the asynchronous deployment of custom resources in the Azure, we use the CRP as a proxy to redirect requests to your Function App. In our sample Function App project, we have two HTTP triggers to achieve our goal.
You can follow the following guidance to publish the Function App and gain an experience of how asynchronous deployment works.
Step 1: Create a new Function App.
Reference: https://docs.microsoft.com/en-us/azure/azure-functions/functions-create-function-app-portal
Step 2: Open the project file (sample.sln) in the downloaded sample project with Microsoft Visual Studio.
Step 3: Open ResourceProvider.cs and modify the value of location header within the method Put().
$"https://yourfunctionappname.azurewebsites.net/api/operations/{id}"
In this case, we provide a URL pointing to another HTTP trigger for client to get the deployment status. Please note that this URL should point to a function rather than ARM endpoint.
Step 4: Right click the “sample” project in the Solution Explorer and click “Publish”.
Publish the HTTP triggers to the Function App created previously.
Once you see “Ready to publish” on your page, you are free to click the “Publish”.
Step 5: Find the HTTP triggers in the Function App on the Azure Portal.
When the publish process is done, you can go to the Azure Portal to check the new added HTTP triggers.
Now, you have set up our Function App in your environment. Then, you are ready to deploy a custom resource in an asynchronous way.
Step 6: Use the ARM template to deploy a custom resource.
This is an example ARM template to create a custom resource. There are a few things that you need to modify accordingly.
|
{ |
- yourResourceTypeName: This is the name of Resource Type that you deploy in the first ARM template (Part 2 of this blog. e.g., users).
- You can also find “yourResourceTypeName” on the CRP page by clicking the “View value as JSON”.
- yourCRPname: This is the name you CRP that you create in the first ARM template (Part 2 of this blog).
- newNameforCustomResource: This is the name for the new custom resource that you want to create. So, you can pick any name you want.
- Location: You can pick a location that you want your new custom resource deployed in.
Once you have done with the modifications, please copy and paste the ARM template into the template editor on the Azure Portal and deploy it.
Step 7: Double confirm the new custom resource is successfully created.
After you successfully deploy the ARM template, you can use the following commands to get the custom resource that you just create.
|
$subID = "your subscription id" $rgName = "your resource group name" $CRPName = "your CRP name" $CRType = “your custom resource type” $CRName = “your new created custom resource name”
$addURI = "https://management.azure.com/subscriptions/$subID/resourceGroups/$rgName/providers/Microsoft.CustomP... ?api-version=2018-09-01-preview"
az rest --method get --url $addURI |
You will receive a response like below, which confirms that the custom resource is existing.
Step 8: Confirm it’s an asynchronous deployment.
Go to the resource group where you deploy the ARM template and then click the “Related events”.
In the “Activity log”, you can find the “Accepted” records. Clicking in each record will give you more details.
Part 5: Conclusion
In this blog, we introduce you how Custom Resource Provider (CRP) achieve asynchronous deployment. We use the Function App as an endpoint. Then we deploy an ARM template to create a custom resource. The PUT request is redirected to the Function App. The whole custom resource deployment process is finished in an asynchronous way.