Chapter 17: Scripted Deployments and DevOps Automation
In Chapter 16, Developing Business Continuity, we looked at how to ensure our solutions have adequate backups in the event that the unexpected happens.
In this chapter, we continue the operational theme, looking at how we can deploy components into Azure, specifically using scripts, templates, and automation tools.
We will begin by exploring what options are available and then start to investigate in more detail how Azure exposes a series of REST APIs. We will then continue looking at using the APIs via command-line tools and Azure Resource Manager (ARM) templates.
Finally, we will look at how to automate deployments using ARM templates and Azure DevOps, along with a brief overview of agile DevOps processes.
We will specifically explore the following topics:
- Exploring provisioning options
- Looking at the Azure RESTful API
- Choosing between PowerShell and Azure CLI
- Understanding ARM templates
- Looking at Azure...
Exploring provisioning options
When building solutions in Azure, the most obvious, and arguably easiest option, is to use the Azure portal.
Although this is great for the quick exploration of components, for learning, or even basic setup, using a manual hands-on approach is difficult to replicate with guaranteed consistency.
What we mean by this is the fact that any manual approach that involves a user clicking buttons or entering information cannot be easily repeated in a way that prevents mistakes from happening. In a traditional on-premises environment, solution builds might be verbosely documented so that other engineers can build the system by following step-by-step instructions.
The major problem with this, aside from the time it takes to write the documentation, is the fact that whoever is following the instructions could very easily enter some information incorrectly, misclick a button, or even miss entire steps.
This can be overcome by opting for a scripted environment...
Looking at the Azure REST API
The first option we will consider is the Azure REST API. All actions on Azure resources are managed through ARM, and this is exposed by a set of APIs. When we perform actions in the Azure portal, we are actually making HTTP calls to the REST APIs.
Information Note
Representational State Transfer (REST) is an architectural pattern that exposes data using a defined set of standards in a text-based format using stateless protocols – that is, information between calls (the state) is not expected to be maintained. A web service that implements this pattern is said to be RESTful.
Other management options such as PowerShell, CLI, and DevOps also just wrap calls to the APIs in a more friendly way; however, you can interact with those APIs directly, as we can see in the following diagram:
Figure 17.1 – REST APIs are used by other services
Any call to the API must use the following URI and format:
https://management.azure.com/<resource...
Choosing between PowerShell and the Azure CLI
When we start to consider automating the deployment and management of resources in Azure, the first option would be using the command line, and here we then have two further options: PowerShell and the Azure CLI.
PowerShell and the CLI are very similar: they both run from a command prompt, they both allow access to the Azure platform, and the commands are also very similar.
Traditionally, PowerShell was only available on Windows computers; however, in recent years, PowerShell has been made available on macOS and Linux platforms. PowerShell has a much broader use than Azure and can be used on Windows platforms to manage and script many processes and Windows management functions.
PowerShell is also extensible: you can build functions, classes, scripts, and modules in a similar fashion to development languages. It is a separate module, called the Az PowerShell module, that enables Azure functionality.
Information Note
The current...
Understanding ARM templates
Just as other tools are simply wrappers for the Azure REST APIs, everything that is built in Azure is defined as an ARM template. Whether you create a service through the Azure portal, PowerShell, REST APIs, or the CLI, ultimately that service is described within an ARM template.
An ARM template is a JSON-based text file and is broken down into the following sections:
- A header containing $schema, contentVersion, and metadata: As an evolving platform, Microsoft is continually adding new components and adding new capabilities to existing components. For this reason, an ARM template contains information that states the schema and version.
- parameters: ARM templates can be built to be re-usable by allowing you to define and pass in parameters. These are then added either as a separate parameters file, as command-line arguments, or, when deploying a template within the Azure portal, a parameters form.
- variables: The variables section enables you to...
Looking at Azure DevOps
Throughout this chapter, we have been looking at how we can encode infrastructure in script files and ARM templates that then allow us to automate deployments using those artifacts. This process is often referred to as Infrastructure as Code (IaC) and fits well with agile-based delivery mechanisms as it provides the ability to build solutions iteratively.
Another related discipline is immutable infrastructure, which dictates that no changes should be made to existing infrastructure. When changes are required, the amendments should be made to the code that describes the system, and the existing infrastructure should then be completely destroyed and then re-deployed using the update code. This not only enforces the use of IaC but it also ensures that any changes are always encoded.
If, therefore, we are building out systems using code, we can start to utilize software development tools and technologies. Together, the tools and processes we employ are called...
Summary
In this chapter, we have seen how everything in Azure can be managed by a series of REST APIs and how these are protected using your Azure account.
We saw how we integrate directly with these APIs or via command-line tools such as Azure PowerShell or the Azure CLI. We also looked at how we can use command-line tools and the Azure portal to automate and standardize deployments with ARM templates, which allow us to set specific configurations.
Finally, we looked at using Azure DevOps to manage and version control code and perform automated, repeatable deployments.
This chapter finishes our look at operations and monitoring. In Chapter 18, Engaging with Real-World Customers, we take our architectures beyond the exam to look at customer considerations, cost optimizations, and what types of challenges we face when dealing with large enterprises.
Exam scenario
MegaCorp Inc. is building a new platform in Azure for customers to view details of their own accounts. The solution will be built over time with regular releases and updates; therefore, the management team wishes to embrace agile development methodologies.
The project team will consist of two teams of developers with five developers in each team, and work will be assigned to each team at the start of every two-week sprint.
The project lead is concerned about developers overwriting each other's code or causing other conflicts. They also want to ensure that there is always a working copy of the core code base at any one time.
Each team has a senior developer who must review any code changes prior to a release. Because the deployment mechanism will change regularly as the solution grows, they also need a way to track and manage changes made to it as well.
Advise on how these requirements can be met as part of the solution design.
Further reading
Refer to the following links for more information on topics covered:
