Retrieve the Function Host Keys while deploying an ARM template
Todays conundrum: As I deploy a new Function Application, I need a simple methodology to retrieve the Host Keys for the function application so that I validate the deployment has been successful; and potentially pass on the key to related services, for example API Management.
As before, I am leveraging templates, and will stay cloud native; this time depending on the functions Output ability to present the keys.
Retrieve the Function Host Keys while deploying an ARM template
Todays conundrum: As I deploy a new Function Application, I need a simple methodology to retrieve the Host Keys for the function application so that I validate the deployment has been successful; and potentially pass on the key to related services, for example API Management.
As before, I am leveraging templates, and will stay cloud native; this time depending on the functions Output ability to present the keys.
Solution
A not well know ARM resource is going to be our Hero in this journey. The resource is a called Microsoft.Web/sites/host/functionKeys and you can gain a little (actually almost none) more details on the Microsoft reference site.
The Documentation refer the API release 2018-02-01; But as you will see in the example code; I discovered that a slightly newer version available.
The Key to this deployment is the following resource definition
"resources": [
{
"comments": "~~ Function App Keys ~~",
"type": "Microsoft.Web/sites/host/functionKeys",
"apiVersion": "2018-11-01",
"name": "[concat(variables('webappName'), '/default/apimanagement')]",
"dependsOn": [
"[resourceId('Microsoft.Web/sites/', variables('webappName'))]"
],
"properties": {
"name": "api-management"
}
}
]Let’s inspect this closer
| Lines | Description |
|---|---|
| 2 | A simple comment defining the objective of this resource |
| 3 | The Resource type we are deploying |
| 4 | The Current API Version of the resource; Normally extracted from the Documentation. |
| 5 | The Name of the resource, In this case we are defining a sub-resource of a Microsoft.Web/sites; therefore the name is defined as {resourcename}/host/{Function Apps, Host Level Key Name} |
| 6-8 | Ensure that the Function App has been deployed before we attempt to create the Function App Host Key |
| 9-11 | Set the name for the Host Key we are creating |
After this resource has been deployed, we then will reference this in our template output section
"outputs": {
"functionKey": {
"type": "string",
"value": "[listkeys(concat(resourceId('Microsoft.Web/sites', variables('webappName')), '/host/default/'),'2016-08-01').functionKeys.apimanagement]"
}
}In the value section of this output, we are getting a reference to the Function Applications resource identity we just deployed, and with this leverage the ARM Function of listkeys to return the function key for the resource we identified on Line 5 in the earlier snippet.
With this output, we can now chain this as the input for additional templates, or reference the value for our scripts.
All links in a practical list
More articles
Using AI to Empower Cloud Architecture and Deployments
The integration of artificial intelligence (AI) into cloud infrastructure is revolutionizing how we manage and deploy cloud resources. AI, now a pivotal component, optimizes the entire lifecycle of cloud architecture, enhancing tasks like deployment, maintenance, and scaling. This article explores the role of AI in empowering cloud architecture and deployments, especially when combined with Infrastructure as Code (IaC) tools like Bicep and Terraform.
Bicep - Tags as Parameters
Deploying infrastructure ARM Templates to Azure, but using Tags and their respective value as the parameter configuration settings
In a post earlier, we look at using arm to lookup the value of tags’ at both the Subscription and Resource Level.
With Bicep this is much easier to understand. This is the same lab configuration as in the original post, but this time to code should be a lot more readable.
Azure IaC - Tags as Parameters
Deploying infrastructure ARM Templates to Azure, but using Tags and thier respective value as the parameter configuration settings
In the post, I am going to introduce a concept which will allow you to greatly up your Infrastructure as Code game, by using Azure as a State Machine!
One of the typical challenges when deploying ARM templates, is the sheer number of parameters which we find as a requirement to complete a deployment; which as you will appreciate gets considerably harder as we target many environments.
Azure IaC - Appending Tags
Dynamically appending Tags to our ARM template with the union function
Todays conundrum: As I am leveraging templates, there will always be some standard tags I require to implement within the template, but I also require to provide additional tags as a parameter to be appended with the deployment.
My objective is to set up tags within an ARM template in accordance with good governance and the Cloud adoption framework.
Guacamole Azure Appliance
Apache Guacamole is a free and open source web application which lets you access your dashboard from anywhere using a modern web browser. It is a clientless remote desktop gateway which only requires Guacamole installed on a server and a web browser supporting HTML5.
Guacamole is the best way to keep multiple instances accessible over the internet. Once you add an instance to Guacamole, you don’t need to remember the password as it can securely store the credentials. It also lets you share the desktops among other users in a group. Guacamole supports multiple connection methods such as SSH, Telnet, VNC, and RDP.