Infrastructure as Code

We typically build out our production environments to meet the needs of our users and to handle the load necessary for an acceptable user experience. This sometimes includes a complex infrastructure where load balancers and redundant data are needed.

It is also common to skimp on environments that are used for development in lower environments. When the environment we test in is vastly different from the environment users operate in, we run the risk of our software behaving differently in production than when we developed and tested it.

The reason we make this mistake is it is often too costly to duplicate a production environment. Furthermore, the configuration of these environments can be complex.

IAC_Overview.png

A DevOps technique known as infrastructure as code (IAC) is the practice of defining our infrastructure as source code and treating it like any other software artifact.

Using this technique, we define the details of our infrastructure using source code and configuration files. This “code” is deployed to an environment, and the defined infrastructure is created or modified as needed.

IAC is idempotent, meaning that a deployment may be performed multiple times and only the existing infrastructure will be affected by the changes.

Infrastructure as code is typically used in situations where it is possible to script infrastructure such as virtual environments and cloud-based solutions. For example, infrastructure-as-a-service (IaaS) and platform-as-a-service (PaaS) infrastructure are candidates for this approach. Sports Stores uses PaaS infrastructure for its database and website.

Note: This is a complex topic, and there are quite a few moving parts even in a simplified example like Sports Store. If you decide to tackle this on your own, be patient and have perseverance. The source code for this SportsStore is available on GitHub.

Azure PaaS Resource Groups

Our goal is to create Azure resource groups with a database server that has a single database and an App Service for our website. The website has an App Service plan as well as an Application Insights instance.

QA Resource Group.png

The DevOpsSportsStoreQA resource group is shown above. The SportsStore SQL server has a single database, SportsStore, in it.

The OcambSSQAWeb App Service application hosts the QA version of Sports Store. It has a corresponding App Service plan and application insights instance.

SportsStoreSettings.png

Websites in Azure store app settings and connection strings that override the values in Web.config. We have one connection string and two app settings: MyVal1 and MyVal2.

All of this infrastructure was created using Visual Studio Azure resource group templates. We used a template for the website and the database.

Website Implementation Details

Resource group templates are JSON files, for which Visual Studio provides an outline view. The WebSite.json file is shown below.

webCode.png

The outline view is a visual representation of the JSON file. You can see a set of parameters as well as connection strings and AppSettings.

The parameters are used to configure the infrastructure, construct the database connection strings, and provide the AppSettings values for MyVal1 and MyVal2.

AppSettingsCode.png

The above example shows two AppSettings variables in the JSON file.

ConnectionStringCode.png

We construct the database connection string using parameters as well.

It is also possible to use separate parameters files for each environment. We have implemented the AppSettings values using this approach.

JSONCode.png

The Website.QA.parameters.json file is shown above.

DefinitionParmDiagram.png

Above, we see how these files are related to each other. There is a single file for the website and a parameter file for each environment.

Database Implementation Details

The SportsStoreDatababase.json file is shown below.

DBCode.png

This is a much simpler implementation, as there are no parameter files. Here, we specify the configuration details of the Azure server and the single database it uses.

Deploying the Templates

The templates and the parameter files may be deployed directly from Visual Studio.

VSDeploy.png

The above example depicts this approach. Templates may also be deployed using PowerShell.

We will not use this approach, however. we will use a release pipeline in Visual Studio Team Services.

Deploy with Release Pipeline

A build is used to package up the source and generate artifacts. Let’s review the tasks in the build definition.

IACBuild.png
  • Get Sources – This task retrieves the source code of the Sports Store infrastructure solution for the sprint.
  • NuGet restore – Builds are run on an agent. This task restores any NuGet packages required by the solution.
  • Build solution – This task does not really compile anything, since we are using JSON files. It packages up the files into artifacts and makes them available for release.
  • Copy Files to  – This task copies the JSON files to the staging directory.
  • Publish Artifact – This task copies the files in the staging directory to a single location called Drop, which is comprised of the artifact that will get deployed.
IACArtifacts.png

Here you can see the definition files for the website and database, along with parameter files for each environment.

A release is used to provision the environments. We have a release for each of our three environments, and variables are used to configure each environment. The following examples are for the QA environment.

IACRelease.png

There are separate tasks for the database and the website.

IACParms.png

These variables, called release pipeline variables, are available to the release pipeline. Please note that passwords are protected, so the values are not displayed.

Create or Update Database Task

This task creates a database, if there are none present, or updates the database, if one exists. It requires the following information:

  • Azure Subscription – The Azure subscription that the database resides in.
  • Resource Group – The name of the resource group.
  • Location – The Azure Data Center.
  • Template – The JSON file that defines the database.
  • Template parameters – The JSON file for the parameters.
DatabaseParms.png

The above screenshot shows the parameters used by the task. The database credentials are pulled from the release pipeline variables. The database collation and the price model are also specified.

Create or Update Database Task

This task creates a database, if there are none present, or updates the database, if one exists. It requires the following information:

  • Azure Subscription – The Azure subscription that the database resides in.
  • Resource Group – The name of the resource group.
  • Location – The Azure Data Center.
  • Template – The JSON file that defines the database.
  • Template parameters – The JSON file for the parameters.
WebParms.png

The above screenshot shows the parameters used by the task. The database credentials are pulled from the release pipeline variables. This is used to construct the connection string for the website.

We also set the AppSettings values for MyVal1 and MyVal2, as well as the sku and capacity for the site.

The final article contains some Closing Thoughts.


Learn More

For details on the topics covered in this article, please visit the links below. You may also download the source code for the DevOps Roadmap Lab on Git HubContact me to set up a free meeting where we can dive deeply into the lab material  and discuss your individual needs.

  • This blog provides a good introduction to the technique used by Sports Store.
  • This Video from Channel 9 covers some valuable information about resource managers.
  • This article discusses the technical details and structure of resource manager templates.
  • This article offers detailed information on many Azure resource templates.