Creating ARM Template using Visual Studio

Using Visual Studio 2015 or greater, it provides syntax and dependency checking as you type and allows you to use track changes using a source control repository. One of the most helpful features of using VS is the intellisense available when constructing a template. For this walk through, we will create a template to provision a Service Bus topic and a subscription.

Start Visual Studio and open a new Azure Resource Group project then give it a name. After adding the project name, you will be presented with a list of templates. Choose the option for a Blank Template; we will go through the steps of creating our own.

Creating ARM Template using Visual Studio

This will create a skeleton template project with two folders—a Scripts folder to hold PowerShell scripts for deployment, which contains a default deployment script, and Templates folder to hold your templates, which contains the resource template and a parameters file.

Go to the Templates folder, right-click and add a new item. Select Azure Resource Mana... DeploymentProject template as follows:

Creating ARM Template using Visual Studio

We can now start filling in the template sections, starting with the parameterssection. The following input parameters listed here will be used to configure the resources at runtime:

  • The name of the serviceBusNamespace
  • The name of the serviceBusTopic
  • The name of the serviceBusSubscription
  • The name of the serviceBusRule
  • Messaging tier for the Service Bus

The basic structure of the parameter section is shown later. Note that we have set the length of the serviceBusNamespace to be between 10 and 25 characters. The serviceBusSku also has a restriction list to allow a selection from predefined values with a default value being specified. Also, serviceBusApiVersion has been set to a default version of 2015-08-01:

"parameters": {
    "serviceBusNamespace": {
      "maxLength": 25,
      "metadata": { "description": "Sunny Electrical Service Bus Namespace" },
      "minLength": 10,
      "type": "string"
    },
    "serviceBusSku": {
      "type": "string",
      "allowedValues": [ "Standard", "Premium" ],
      "defaultValue": "Standard",
      "metadata": { "description": "Messaging tier for the service bus." }
    },
    "serviceBusTopic": {
      "type": "string",
      "metadata": {
        "description": "Name of the Topic"
      }
    },
    "serviceBusSubscription": {
      "type": "string",
      "metadata": {
        "description": "Name of the Subscription"
      }
    },
    "serviceBusRule": {
      "type": "string",
      "metadata": {
        "description": "Name of the Rule"
      }
    },
    "serviceBusApiVersion": {
      "type": "string",
      "defaultValue": "2015-08-01",
      "metadata": {
        "description": "Service Bus ApiVersion used by the template"
      }
    }
  },

The next section is declaring any optional variables. For provisioning a Service Bus, we will use the following variables here:

  • location: This calls the function resourceId(), which returns the unique identifier of a resource
  • sbVersion: This is set to the parameter value in the parameters section
  • defaultSASKeyName: This has been hard coded to "RootManageSharedAccessKey"
  • authRuleResourceId: This is the ID of the resource being created

The final code for the variables section is constructed as follows:

"variables": {
    "location": "[resourceGroup().location]",
    "sbVersion": "[parameters('serviceBusApiVersion')]",
    "defaultSASKeyName": "RootManageSharedAccessKey",
    "authRuleResourceId": "[resourceId('Microsoft.ServiceBus/namespaces/authorizationRules', parameters('serviceBusNamespace'), variables('defaultSASKeyName'))]"
  },

Tip

To debug a computed variable, use the Output section to display the evaluated value.

The next section is resources, which is mandatory and at least one resource must be specified. As we are creating a Service Bus Topic and a subscription, the following resource template will be used. Note that the Subscription resource has been created as a dependency on the Topic being created first by setting the dependsOn property to the "[parameters('serviceBusTopic')]" value:

"resources": [
        {
          "apiVersion": "[variables('sbVersion')]",
          "name": "[parameters('serviceBusTopic')]",
          "type": "Topics",
          "dependsOn": [
            "[concat('Microsoft.ServiceBus/namespaces/', parameters('serviceBusNamespace'))]"
          ],
          "properties": {
            "path": "[parameters('serviceBusTopic')]"
          },
          "resources": [
            {
              "apiVersion": "[variables('sbVersion')]",
              "name": "[parameters('serviceBusSubscription')]",
              "type": "Subscriptions",
              "dependsOn": [
                "[parameters('serviceBusTopic')]"
              ],
              "properties": { },
              "resources": [
                {
                  "apiVersion": "[variables('sbVersion')]",
                  "name": "[parameters('serviceBusRule')]",
                  "type": "Rules",
                  "dependsOn": [
                    "[parameters('serviceBusSubscription')]"
                  ],
                  "properties": {
                    "filter": {
                      "sqlExpression": "TransactionType = 'PO'"
                    },
                    "action": {
                      "sqlExpression": "set FilterTag = 'true'"
                    }
                  }
                }
              ]
            }
          ]
        }
      ]
    }
  ],

The final section is output. For the output, we will display the Service Bus connection string and the Shared Access Policy keys:

"outputs": {
    "NamespaceDefaultConnectionString": {
      "type": "string",
      "value": "[listkeys(variables('authRuleResourceId'), parameters('serviceBusApiVersion')).primaryConnectionString]"
    },
    "DefaultSharedAccessPolicyPrimaryKey": {
      "type": "string",
      "value": "[listkeys(variables('authRuleResourceId'), parameters('serviceBusApiVersion')).primaryKey]"
    }
  }

Now that the template is completed, we can now deploy it using Visual Studio. Right-click on the project and select New Deployment. This will bring up a dialog box where you can select your Subscription:, Resource group:, and templates.

Creating ARM Template using Visual Studio

Now click on the button Edit Parameters. This will open another dialog box that displays all the parameters that were defined in the template and allows you to add the values. Parameters that have allowedValues assigned are represented by a drop-down control.

Creating ARM Template using Visual Studio

After saving the parameters, click on Deploy. This now starts provisioning the resources in Azure. Use the Visual Studio Output window and view the current status. Once completed, the Output window will display the message here:

Creating ARM Template using Visual Studio

If you open azuredeploy.parameters.jsonlocated in the Templates folder, it will now contain the values you had entered from the Edit Parameters dialog window as follows:

{
    "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentParameters.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "serviceBusNamespace": {
            "value": "SunnyElectricalSB"
        },
        "serviceBusTopic": {
            "value": "WebTransactions"
        },
        "serviceBusSubscription": {
            "value": "Orders"
        },
        "serviceBusRule": {
            "value": "PurchaseOrders"
        }
    }
}

The same ARM template and parameters file can now also be deployed from a PowerShell console window using the following steps:

  1. Open a PowerShell console window and log in to your account by executing the flowing script: Add-AzureRmAccount.
  2. Before you can execute the ARM template, you need to have an existing resource group. If not, you will need to execute the script here to create the resource group first:
           New-AzureRmResourceGroup -Name <name-of-resource-group> 
           -Location "<region-name-to-create-resource>"
  3. The following script is then used to create the resources using the ARM template and parameters file:
           New-AzureRmResourceGroupDeployment -Name ExampleDeployment 
           -ResourceGroupName ExampleResourceGroup 
           -TemplateUri <LinkToTemplate> 
           -TemplateParameterUri <LinkToParameterFile>

    After successfully running the script, the following will be displayed in the PowerShell console:

    Creating ARM Template using Visual Studio

Best practices

The new set of APIs available from Microsoft has revolutionized the deployment and management of Azure resources. Although there is a large number of quick start templates available, this should not discount you from the following best practices.

The following is not a complete list but a starting point of some best practices to follow:

  • Use Visual Studio for authoring your ARM templates. It provides inbuilt IntelliSense and validation using the Visual Studio JSON editor, and you can visualize the resources and parameters using the JSON outline window. As with any best practices, using Visual Studio provides the capability to manage your artifacts and deployment templates using source control repositories.
  • Increment the version number of the contentVersion element in the template file after any updates are made to the template to ensure that the correct template is being used for the various deployments:
           {
              "$schema": "http://schema.management.azure.com/schemas/2015-01-
              01/deploymentTemplate.json#",
              "contentVersion": "1.0.0.3",
              "parameters": { },
              "variables": { },
              "resources": [ ],
              "outputs": { }
           }
  • Test your templates by predeploying them to ensure that there are no dependencies required. Don't rely on compiling the templates as this only ensures that it is syntactically correct.
  • Decompose a large single template into smaller separate templates that are purpose specific. Use the templateLink property to link these together. More about linking templates can be found here: https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-linked-templates.
  • If requesting passwords and secrets from the user in the parameters section of the ARM template, use the securestring type instead of normal string type. This will encrypt the entered text for privacy when being used and then delete it from the computer memory when no longer needed:
    "parameters": {
        "secretValue": {
            "type": "securestring",
            "metadata": {
                "description": "Value of the secret to store in the vault"
            }
        }
    }
  • If deploying a resource that is dependent on other resources that must exist first, use the DependsOn property to specify the dependent resources. Use this property to define the deployment sequence of your resources also.
  • Get into the habit of using the outputs element to return something when the deployment of the resources was successful. This could be the resource URL to visually check that the deployment was successful.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset