Infrastructure and Configuration as Code

In the previous chapter, the focus was on storing and building application code and releasing the created binaries. You learned how to create a pipeline, from source control to a target environment for the automated, repeatable deployment of your applications.

In this chapter, you will learn how to apply the same principles to the infrastructure that your application runs on and the runtime configuration of your application. Doing so will help you to further increase the speed at which changes can be delivered to production, increasing the flow of value to your end users.

This chapter will start off by explaining the value of having everything, infrastructure and configuration included, as code. Next, it continues by explaining ARM templates. The syntax will be explained, as well as how to deploy ARM templates. Then, it proceeds to explain...

Technical requirements

To experiment with one or more of the technologies described in this chapter, one or more of the following may be required:

• An Azure subscription, for executing ARM templates and running Azure Automation
• PowerShell with the Azure PowerShell modules, for executing ARM templates, available from https://docs.microsoft.com/en-us/powershell/azure/install-az-ps
• The Azure CLI, for executing ARM templates, available from https://docs.microsoft.com/en-us/powershell/azure/install-az-ps
• One or more virtual machines for experimenting with the different tools discussed in this chapter

Having everything as code

If you have been responsible for creating and maintaining application infrastructure and configuration in the past, you have most likely experienced what is called configuration drift. Configuration drift is the name for the phenomenon where the configuration between servers in acceptance and the production environment differs. Or, even worse, when having multiple servers in the production environment, it might be the case that the configuration of these is not always the same.

The most common cause of configuration drift is manual change. When making changes manually, maybe under the pressure of a production issue, there is always the risk that you apply different settings to different servers or hosts. And if you ever need to scale out and add another server to your production environment, the chance of that server taking on the same configuration of...

Working with ARM templates

When working on the Azure platform, infrastructure is described using Azure Resource Manager (ARM) templates. ARM templates are written in JSON and a skeleton template looks as follows:

{
  "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
  },
  "variables": {
  },
  "resources": [
  ],
  "outputs": {
  }
}

The template itself is, at the highest level, a JSON object. There is a mandatory property, $schema, for which the shown value is also mandatory. The contentVersion property is also mandatory and can be specified to version the contents. This version can be used by the author to version the template if necessary.

The rest of this chapter will discuss the different parts that make up ARM...

Using Azure Automation

Azure Automation is a service in Azure that is designed to help users to create, manage, deploy, and maintain their Azure resources. Azure Automation contains several concepts that remove some of the complexities and low-level details from these actions. Azure Automation allows for the formulation of workflows in the form of runbooks. These runbooks can be executed against Azure resources on behalf of the user.

Automation account resources

Within an Azure Automation account, there are several resources that make this more than just a scripting engine. These resources are shared on the level of the automation account and can hence be reused within multiple runbooks.

...

Managing application settings

Another part of the infrastructure of an application is the application configuration. In this section, a number of approaches for storing and loading the application configuration for an Azure App Service are discussed. They include the following:

• Storing the configuration in the app settings
• Using a combination of Managed Identity and key vault
• Using the Azure App configuration service

The disadvantage of the first approach is that the app settings can be read by any user who has administrative (read) access to the app service that is configured. The next two approaches do not have this disadvantage.

Azure app service settings from an ARM template

The first way to configure application settings...

Other tools

There are many other tools available for managing infrastructure and configuration through code. Next to the native Azure and Windows options discussed in the previous sections, there are many alternatives widely in use and some of them are listed in this section. It is important to know which tool can be used for which scenarios and how to integrate with them.

CloudFormation

CloudFormation is the IaC language for the AWS Cloud. CloudFormation templates can be written in either JSON or YAML format. One example of creating an AWS S3 Storage Bucket that is publicly readable would look like this:

Resources:
 HelloBucket:
 Type: AWS::S3::Bucket
 Properties:
 AccessControl: PublicRead

There is an extension available that...

Summary

In this chapter, you learned about the concept of infrastructure and configuration as code, its value, and how to use it in practice. For implementing these, you learned about ARM templates, the IaC mechanism for Azure. You also learned about PowerShell DSC for managing the configuration of virtual machines and about different techniques for managing the configuration of your applications. Finally, you learned about several other tools available in the market. You learned which tool can be used in which situation and whether these tools can integrate with Azure DevOps.

With this knowledge, you are now able to start describing the infrastructure and configuration of your application(s) in source control using one or more of the tools you have read about. You are also capable of setting up the means to deliver the infrastructure using automation, either from a release pipeline...

Questions

As we conclude, here is a list of questions for you to test your knowledge regarding this chapter's material. You will find the answers in the Assessments section of the Appendix:

1. True or False: ARM templates can be used for creating, updating, and deleting Azure Resources.
2. Which of the following is not an Azure Automation Account resource?
   1. Modules
   2. Containers
   3. Run As account
   4. Variables
3. True or False: One disadvantage of infrastructure as code is that you have to put sensitive information in source control as ARM template parameter files.
4. True or False: Azure Automation Accounts allow for the execution of Powershell runbooks at a predefined schedule.
5. What are some of the benefits of using infrastructure as code?

Further reading

• A formal breakdown of the ARM template structure and syntax can be found at https://docs.microsoft.com/en-us/azure/azure-resource-manager/templates/template-syntax.
• The complete ARM Template reference can be found at https://docs.microsoft.com/en-us/azure/templates/.
• An overview of all functions that can be used in ARM templates can be found at https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-template-functions.
• More information about Azure Blueprints can be found at https://docs.microsoft.com/en-us/azure/governance/blueprints/overview.
• Details about the WhatIf command for ARM templates can be found at https://docs.microsoft.com/en-us/azure/azure-resource-manager/templates/template-deploy-what-if.
• There are many online references to the story of "turtles all the way down", but an early reference can be found digitized at https...