ARM templates are a powerfull tool and from a DevOps perspective can deal with a lot of the hassle in creating new environments and ensure that the environments don't differ. However writing ARM templates can be a tedious task as there aren't tools for generating templates and you often have to do an actual deploy to get relevant error messages about invalid values and missing dependencies. One method of creating ARM templates is to export templates from the Azure portal, however the templates generated this way are often bloated and you still need to do a lot of manual work to make parameters and variables for the settings that differ between environments.
We have developed a tool for generating ARM templates which can be seen here. The tool is still under development. Currently it's only possible to create storage accounts and blob containers, but it shows the potential of such a tool.
Structure of an ARM template
An ARM template consists of four parts:
We will go into a short description of each part excluding outputs.
Parameters are quite simple in their nature, but this is the point where you are able to differentiate the environments. You are able to define numbers, strings, objects etc. as a parameter, which can be used in variables and resources. Parameters are isolated, meaning they cannot reference any other parts of the ARM template.
Variables are a bit more complicated than parameters, but still their functionality is limited. You can define strings, arrays, and objects as a variable and you can use other variables and parameters as part of your variable. This can e.g. be used to combine two parameters:
Resources are the heart of the ARM template. Each resource corresponds to a resource in the Azure environment. The resources can utilise parameters and variables as part of their specification.
Resources only have a few shared properties between them, so knowing how e.g. a database server is defined doesn't necessarily help you with defining another type of resource. Also the limitations of a property is not always intuitive and it can be bothersome to look up what's possible. This is the main focus of the application to mitigate these differences in a simple way.
Goals of the tool
There is one main focus of the tool: Making it easy to create a functioning ARM template. The goal of the tool is not be able to support all use cases and especially not the large scale ones.
To achieve this goal, there are a few subgoals to complete:
Create or reference dependencies automatically
Create parameters automatically including limit to valid values
Be able to use parameters, variables, and functions
The tool looks like this:
The different parts are visible in a friendly way on the left, the working window in the middle (it's here the forms for parameters, variables, resources, and outputs will be, where you'll do most of your work), and finally the generated template on the right which is updated automatically each time you press save.
The idea of the project was to be as simple as possible and accessible, therefore we implemented it as a static web page using the following:
We're going to skip going into detail why these technologies are used as the program flow is in focus although a object oriented language in general makes it easier with the power of inheritence.
The general idea of the application is to have a base class handle all the basic information of resources such as name and location and let the inheriting classes handle resource specific information.
In our case two different base classes are needed: one for handling the resource information itself and one for handling form logic on the web page Resource.ts and ResourceTypeForm.tsx respectively.
The form logic classes are responsible for keeping track of the properties of the given resource and which parameters to create. For each resource property, it's possible to define a parameter name, if you want to generate a parameter for it. It will automatically create a parameter of the correct type for the property and limit the options to what's allowed including setting those limitations on the created parameter.
Automatic parameter creation
For parameter creation we went with a function in ResourceTypeForm.tsx to check if a parameter should be created and do so adding it to the list of new parameters.
When the function is called, the parameters for the function are quite self explanatory where they come from except for the allowed values. The allowed values are only applied if it's not an empty list. The allowed values are defined in each resource's respective class and fetched from there, when creating a parameter as can be seen here from the class StorageAccountForm.tsx:
This approach allows us to let the models keep track of what's possible and will in turn mean less maintenance when Microsoft adds other options. This static property is also used to populate the options list when setting the property in the web form.
Automatic dependency creation
The automatic dependency creation is really helpful if you just want a standard setup, or you're not sure what a resource actually depends on. When creating a resource, every type of dependent resource will be in the bottom of the form, where you can either select an existing resource (if any are available), or create a new one with the basic setup. All you need to specify is the name of the resource.
When creating a new resource, if that type of resource is dependant on another resource type, the form will recursively ask for dependencies until you either have selected existing resources or the resource types are not dependent on any other resource types e.g. when entering a blob container, the blob container requires a blob container service which in turn requires a storage account.
To achieve this functionality, every resource type implements a static function defined here:
All that's required is the name you want to assign to the resource and ResourceDependency. The resource dependency is a model to maintain the dependency graph. If you want to look into the implementation, you can find it here. An example from StorageAccountBlobContainer.ts, where it automatically creates a default blob service if you have chosen to create or new, otherwise it fetches the selected service, sets the dependent resources and adds the container to list of created resources which in turn tells the form logic to add the resources returned from the getDefault function.
Even though the tool creates valid templates, it doesn't check that the names are available, only that the syntax is valid. As the tool is meant as a light-weight helper tool, this is not planned to be implemented.
This tool shows that it's possible to make a tool, which can leviate a lot of the hassles of writing an ARM template, although utilising the full power of the ARM template with a tool like this would require a lot of work and may not be worth the development time.
The next step of the tool is to support more resource types and refactor the shared logic between resources to make it more readable and more simple.
At Monstarlab, we are using SonarQube to gather metrics about the quality of our code. One of the metrics we were interested in is code coverage. However, just running sonar-scanner on the project will not upload the coverage data to our instance of Sonar...
CI Pipelines help improve efficiency by automating complex workflows. With GitHub Actions, it's easier than ever to bring CI/CD directly into your workflow from your repository. Put together with the CI pipeline, a series of automated workflows that help ...