Forem: CloudSkills.io

The Beginners Guide to Running Docker Containers on AWS

TeamCloudSkills — Sat, 06 Mar 2021 18:50:05 +0000

Learning the basics of AWS and Docker containers?

In this episode, we explain the basics of Docker and how to run containers on AWS.

This a one-hour project focused tutorial from our AWS Certified Solutions Architect training.

AWS Quick Tip: Working with EC2 and IAM Roles

TeamCloudSkills — Sat, 06 Mar 2021 18:40:12 +0000

Allowing your applications to access cloud services on your behalf can sometimes be tricky. In AWS, you can take advantage of IAM roles to make this a lot easier.

Working with IAM roles and delegating service access to applications is a core concept when it comes to dealing with AWS.

In this AWS Quick Tip, CloudSkills Author Michael Levan explains how this works.

AKS Virtual Nodes with Chad Crowell

TeamCloudSkills — Sat, 06 Mar 2021 18:37:41 +0000

Working with Azure Kubernetes Service (AKS)?

If you're in Azure and planning to work with Kubernetes, definitely check out how to SCALE virtual nodes and get your billing under control.

This 13 minute YouTube video is by CloudSkills Author Chad Crowell.

Packer and Terraform with Immutable Infrastructure

TeamCloudSkills — Tue, 02 Feb 2021 15:00:32 +0000

Terraform is red hot right now, and you probably know that it's an open-source Infrastructure as Code (IaC) solution.

OK, but what is Packer?

Well, Packer is an open source tool for creating identical machine images for multiple platforms from a single source configuration. It's lightweight, runs on every major operating system, and is highly performant, creating machine images for multiple platforms in parallel.

In this CloudSkills Community Call replay, Luke Orellana shows you how to get started with Packer, Terraform, and Immutable Infrastructure.

Resources from this episode:

HashiCorp Learn:
https://learn.hashicorp.com/terraform

Introduction to Packer
https://www.packer.io/intro

Learning Application Security with Tanya Janca

TeamCloudSkills — Tue, 02 Feb 2021 12:10:54 +0000

Tanya Janca, who was on the podcast last year, is back! Since the last time we talked, she’s been very busy founding her own company, We Hack Purple. Tanya’s an expert on App Security, and through her company, she’s sharing those skills with online on-demand courses.

In this episode, we talk about…

Tanya’s new community centered around her online academy, which has been a positive and kind space for discussing related topics.
Why, if you’re a software developer, you should learn about app security and have a strategy to talk to management to get what you want and legitimize your job.
Tanya’s book and how she teaches each lesson within it several different ways to make it accessible for various learning styles.
Tanya’s current free mini-course offering about scaling your security program and security team.
The best career advice Tanya has ever gotten.
The importance of mentors in everyone’s careers and why it’s very important to build a community.

Resources from this episode:

Follow Tanya on Twitter
Check out the We Hack Purple Academy
Read Tanya's new book: Alice and Bob Learn Application Security
Join the We Hack Purple Newsletter

Azure Automation: Managing Runbook Authentication and Modules

TeamCloudSkills — Tue, 02 Feb 2021 11:16:28 +0000

In my previous post, we took a look at creating your first Azure Automation PowerShell runbook. We set up the Azure Automation account, authored a PowerShell runbook, and incorporated parameters and variable assets. The next step is to understand how we can access and manage Azure resources from our runbooks.

In this guide, you will learn how Azure Automation can authenticate and access Azure resources. We will also take a look at importing PowerShell modules to add cmdlets to our runbooks. When you're finished, you'll have the skills to elevate your runbooks to the next level.

Prerequisites

Before you begin this guide, you'll need the following:

Azure tenant and subscription
Administrator account with sufficient permissions on a subscription, such as Owner, or a role containing Microsoft.Automation resource authorization
PowerShell knowledge

Azure Automation Run As Account

When I created the Azure Automation account in the first article, I enabled the option to create an Azure Run As account. By enabling this option, Azure will automatically create an Azure AD application. You can use this application identity to authenticate to an Azure subscription to access and manage resources. During the Run As account creation, Azure performs several other functions such as:

Adding a self-signed certificate to the application account.
Creating a service principal identity for the application.
Assigning the Contributor role for the account in the current subscription.
Creating Automation connection assets named AzureRunAsCertificate and AzureRunAsConnection.

If you want to view more information about the Run As account, from the Automation Account resource page, navigate to Account Settings > Run as accounts.

You can view the account's properties in the portal, including the certificate thumbprint, the Azure AD application information, service principal ID, role assignments, and runbooks utilizing the account.

At the top of the properties page, note an action named Renew Certificate. The account's certificate is only valid for one year, so be sure to renew before expiration to keep your runbooks from failing.

Along with the Run As account, Azure will create two connection assets: AzureRunAsCertificate and AzureRunAsConnection. The certificate asset authenticates to Azure so the runbook can manage Azure Resource Manager resources. The connection asset contains the application ID, tenant ID, subscription ID, and certificate thumbprint. Basically, everything you need to connect to Azure to start managing resources! In an upcoming example, I'll use this connection to connect to Azure and to retrieve some resources.

Automation Account Modules

Before I create a new runbook to manage my Azure resources, I need to make sure I have the right PowerShell commands available. When you create a new Automation Account, Azure will automatically import some PowerShell modules for you, such as AzureRM.Automation, AzureRM.Computer, and AzureRM.Resources. However, these modules are a part of the older AzureRM PowerShell module, which Microsoft is no longer developing. Microsoft has replaced this module with the newer Az PowerShell module.

Luckily, I'm not stuck using the older modules in my PowerShell runbooks. I can import the new Az modules into the Automation Account for use with my PowerShell code. From the Automation Account, navigate to Shared Resources > Modules gallery. The first module I need to import is the Az.Accounts module so I can use the Connect-AzAccount cmdlet in my runbook. Search for "Az.Accounts", then select the resulting module.

From the module page, I can search the module for the cmdlets and functions to verify it has what I need. From here, I can select the Import action at the top. Once the import is successful, I need to navigate the Modules gallery and perform the same steps for the Az.Resources module so I can use the Get-AzResourceGroup in my runbook.

The imports can take a few minutes, but you can verify the status by navigating back to Shared Resources > Modules. In this list of modules, verify the module import progress in the Status column. From this Modules page, also note there are options to import a custom module. Select the + Add a module and choose a .zip file that contains the module code. Note that the module code's file name must match the file name of the zip file. Importing custom written module is a fantastic feature of Azure Automation that allows you to write a runbook to fit any scenario.

Connect to Azure from PowerShell Runbook

Back in the Automation Account, I will create a new runbook that will connect to Azure and retrieve my resource groups. In the Automation Account, navigate to Process Automation > Runbooks, then select + Create a runbook. From here, input a name for the runbook, select the PowerShell runbook type, then select Create.

In the Edit PowerShell Runbook window, I need to write code that will retrieve the information stored in AzureRunAsConnection. For this, I use the Get-AutomationConnection cmdlet and specify the name of the Run As connection. If I store the connection information to a variable, I can reference the tenant ID, application ID, and certificate thumbprint in the Connect-AzAccount cmdlet to authenticate to my Azure tenant.

$connection = Get-AutomationConnection -Name AzureRunAsConnection

Connect-AzAccount -ServicePrincipal `
    -Tenant $connection.TenantID `
    -ApplicationId $connection.ApplicationID `
    -CertificateThumbprint $connection.CertificateThumbprint

If you do not remember the cmdlet to retrieve the Run As connection asset, remember you can expand Assets on the left to view saved connections and other assets. Selecting Add to canvas will insert the necessary PowerShell code.

Once the runbook connects, I can now use other Az cmdlets to work with Azure resources. Since I imported the Az.Resources module, I can retrieve all my resource groups using the Get-AzResourceGroup cmdlet.

From here, I will save the runbook code, publish, and then execute it. When I view the runbook job status, the Output tab will show the runbook successfully authenticating to Azure. It will then start displaying my resource groups.

Retrieving resource groups is only the beginning of what is possible. Imagine what other tasks you could automate within a runbook, such as taking snapshots of virtual machine disks, turning off virtual machines, or automatically resizing resources based on a schedule.

Managing Runbook Authentication without Run As Accounts

You might be asking, "If I don't create a Run As account with the Automation Account, how can I authenticate to Azure?". There are a few options for managing authentication in this scenario, which I outline in the following sections. Remember, if you choose not to use the built-in Run As account, you will need to ensure that whichever account used has permissions to the Azure resources the script is trying to access. The built-in Run As account accomplishes this by being a Contributor at the subscription level, but you may want to apply more granular permissions.

Create the Run As Account

I can still enable the Run As account after the Automation Account has been created. In the account, navigate to Account Settings > Run as accounts. Previously in this screen, we viewed the existing account, but I can also create one if it doesn't exist already. No additional inputs or settings are needed to set up the account.

Create a Service Principal

Applications use a service principal to access resources secured by Azure AD. The service principle represents the application inside the tenant, and you can assign it permissions to resources (just like a user account).

To create a service principal, navigate to Azure Active Directory in the Azure portal. In the Manage section, select App registrations. Select + New registration, then input the application's name, support account type (for now, leave at the default), and redirect URI (this can be blank).

After you create the app registration, on the Overview page, take note of the application ID and tenant ID. You will need this information later to create a new connection or credentials asset (see following sections). In the Manage section, you can navigate to Certificates & secrets to upload a certificate or generate a secret (essentially a password for the account). You can then use either of these to authenticate out to Azure.

Create a New Connection Asset

You can create your own connection asset that includes an ApplicationId, TenantId, Certificate Thumbprint, and Subscription Id. If you created a service principal in the previous section, you could use it for this purpose.

Create a connection asset in the Automation Account by navigating to Shared Resources > Connections, then select + Add a connection. Give a name to the connection asset, select AzureServicePrincipal as the type, and enter the required information from the service principal. Once the connection is created, I can use it just like the AzureRunAsConnection asset in my PowerShell code from earlier.

Create a Credentials Asset

Finally, you can store security credentials as a shared resource. The credentials asset includes a username and password, and you can use these on cmdlets that accept a PSCredential object. In the Automation Account, navigate to Shared Resources > Credentials and select + Add a credential. Name the credential and enter the username and password.

Once you create the asset, you can retrieve the credentials using Get-AutomationPSCredential and store it in a variable. You then pass the credentials to the Connect-AzAccount cmdlet, like so:

$creds = Get-AutomationPSCredential -Name '{CredentialAssetName}'

Connect-AzAccount -Credentials $creds

Don't forget, you can use the Asset explorer on the left to input the correct code and asset name into your script.

Conclusion

In this post, you learned how to configure authentication so your runbooks can access Azure resources. Being able to authenticate to Azure without storing usernames and passwords in the runbook code is a security best practice. Now that you can connect to Azure, start thinking about what tasks you can automate using runbooks. You will need to be sure to import any modules required by your code.

Check back soon for my next post on Azure Automation where I will show how to configure a hybrid worker so you can execute a runbook anywhere.

Jeff Brown is a Systems Engineer and Cloud Administrator with over a decade of experience in server and application administration. In his career, he has managed a wide range of technologies including Windows Server, Exchange Server, Skype for Business, Azure, and Microsoft 365. Jeff enjoys writing about technology topics and creating content for the community. You can find more of his content over at jeffbrown.tech.

Azure Automation: Creating a PowerShell Runbook

TeamCloudSkills — Tue, 02 Feb 2021 11:08:50 +0000

Azure Automation is a cloud-based automation and configuration service that you can use for process automation through runbooks. You can author runbooks using a graphical interface or in PowerShell or Python programming languages. Think of these runbooks as replacing scripts you have scheduled to run on a server.

In this guide, you will set up an Azure Automation Account and deploy your first PowerShell runbook. When you're finished, you will have the necessary skills to get started deploying runbooks in your Azure tenant.

Prerequisites

Before you begin this guide, you'll need the following:

Azure tenant and subscription
Administrator account with sufficient permissions on a subscription, such as Owner or Contributor
PowerShell knowledge

Create an Azure Automation Account

Before creating your first runbook, you need to create an Azure Automation Account. This account is responsible for executing runbooks and authenticating to Azure resources required by the runbook. The account groups together Automation resources, runbooks, and configuration settings. You can create multiple accounts to separate their functionality, such as accounts for development and production.

To get started creating your first Azure Automation Account, log into the Azure portal at https://portal.azure.com. In the Search bar, enter Azure Automation, and select Automation Accounts from the results.

Here on the Automation Accounts resource page, you can view and manage any existing Automation Accounts. Click on + Add to create your Automation Account. In the Add Automation Account page, you need to define some information for your account:

Name: Enter a descriptive name for the account. Following Microsoft recommendations, I will name mine based on the resource type, its purpose, environment, Azure region, and instance. For example, aa-cloudskills-prod-westus-001.
Subscription: Select a valid Azure subscription.
Resource Group: Select an existing resource group or create a new one. For this demo, I am creating a new resource group named azacct-rg.
Location: Select a location to host the Automation Account.
Create Azure Run As account: Enabling this option will automatically create an Azure Run As account for authenticating to other Azure resources. For now, configure this to Yes.

Once you have entered the account information, click on Create. Once Azure creates the account successfully, select the account in the Automation Account list (this may require a refresh before it appears).

Create a PowerShell Runbook

Now that the Automation Account has been created, you can author the runbook that hosts your PowerShell code. Using the left menu in the Automation Account resource, scroll down to Process Automation and select Runbooks. Here you will see some examples of each type of runbook you can create: Graphical, Python, and PowerShell. You can view each of these runbooks to learn how to perform different actions in runbooks, such as using variables or connecting to Azure resources. You can also import a runbook or browse the PowerShell Gallery and Azure Automation GitHub organization for resources created by Microsoft and the community.

Let's get started creating a runbook by selecting Create a runbook. In the form, enter a runbook name, select the runbook type, and enter a description. This demo is using a PowerShell runbook type. Once you have entered all the runbook information, select the Create button.

After Azure creates the runbook, it should redirect you to the Edit PowerShell Runbook page. This page is where you can enter in the PowerShell code that the Automation Account executes. The menu actions include the ability to save the runbook, publish a new version of the runbook, revert to a previously published version, or run a test of the runbook. On the left, you can view the modules and cmdlets available to use in the runbook, import references to other runbooks, or view assets that you can use in the script, such as variables or certificates for authentication.

For this runbook, I am keeping the code simple and displaying the phrase "Hello, Azure Runbooks!" to the console.

"Hello, Azure Runbooks!"

Once you have entered the code, select the Save button, then the Publish button. You will receive a warning that publishing the runbook will override the existing published version. Select Yes to this prompt. Once the runbook is successfully published, the Azure portal will redirect to the Overview page.

Execute the Runbook

With the runbook created and published, you can now execute the runbook and view the output. From the Overview page, select the Start icon. It will prompt you to make sure you want to start the runbook, go ahead and select Yes. Once Azure begins executing the runbook, the portal will redirect to the overview page for this runbook job instance. Here, you can view the instance ID, the status, and the input and output streams of the runbook. From here, select the Output tab to view the "Hello, Azure Runbooks!" message to the console.

Add Warning and Error Output

In the above example, the PowerShell runbook output the string "Hello, Azure Runbooks!". You can also use the cmdlets Write-Warning and Write-Error to output warning and error messages to the console logs.

Back on the runbook Overview page, select the Edit icon at the top to go back to the Edit PowerShell Runbook page with the existing code. In the code editor, add the following lines of code:

Write-Warning -Message "This is the warning message."

Write-Error -Message "This is the error message."

Save and publish this version of the runbook. Back in the Overview page for the runbook, select the Start icon to execute the runbook again, just as you did previously. In the job results window, select the Errors and Warnings tabs to view the custom messages outputted from the script. You can also select All Logs to view all output from the script in one place.

Using the appropriate PowerShell cmdlets, you can create a runbook that shows regular, warning, and error messages. Customizing this output can quickly ascertain if the script has any issues by correctly displaying warnings and errors.

Enhance Runbook Execution with Parameters

PowerShell parameters enable passing information to a script to use during execution. Parameters allow PowerShell scripts to be more dynamic instead of setting static variables. Azure Automation PowerShell runbooks can also use parameters when you define them in the script code. Let's examine this functionality now.

Follow the instructions from earlier in this post to edit the runbook code. In the code editor, add a parameter that will accept a name to display in the greeting message. Since this parameter is not mandatory, I'm defining the parameter with a default value of "CloudSkills." Here is the new runbook code.

param (
    [Parameter()]
    [string]
    $Name = "CloudSkills"
)

"Hello, $Name"

After saving and publishing the runbook, execute the runbook just as you have done previously. However, this time Azure will display a Start Runbook window to allow you to input a value for the Name parameter. It also indicates that "CloudSkills" will be used as the default if you don't enter another value. Enter your name and select OK.

In the job results window, the Input tab will show the value of the Name parameter passed to the runbook, and the Output tab will show the output message using the value of the parameter.

Creating a Variable Asset

While you can define variables within the runbook code, you can also define variables within the Automation Account to be used by multiple runbooks. Back in the Automation Account, navigate to Shared Resources > Variables. From here, select Add a variable. In the New Variable window, enter a variable name, description, data type, value, and encryption type. Once completed, select Create.

With the variable create, you can now reference it in a runbook. Navigate back to the runbook and edit the code. Inside the script, you can retrieve the variable's value by using the Get-AutomationVariable with the variable name and storing it into a script-level variable.

$congratsMessage = Get-AutomationVariable -Name 'congratsMessage'

You can now use the defined variable as needed in the script. Suppose you don't remember the name of the variable asset you defined in the Automation Account. In that case, you can view variable assets under Assets and use the context menu to auto-generate the PowerShell command.

Save, publish, and then execute the runbook to verify the variable output in the job results window.

Conclusion

In this post, you learned how to create an Azure Automation Account to host your first PowerShell runbook. You saw how to view the runbook output and use Write-Warning and Write-Error to customize the output. Finally, you extended the functionality of your runbook with parameters and variable assets.

Check back soon for my next post on Azure Automation where I will show how to configure authentication to access and manage Azure resources.

Windows Virtual Desktop with Travis Roberts

TeamCloudSkills — Tue, 02 Feb 2021 10:55:17 +0000

In this episode we're catching up with Travis Roberts to chat about all things Windows Virtual Desktop, Azure, and a lot more.

In part due to the COVID-19 Pandemic, 2020 saw the use of Windows Virtual Desktop soar. Many companies are in the process of switching their networks over to the Cloud. Mike’s guest today is Travis Roberts, the Senior Networking Systems Administrator at RBA Consulting. Travis has a background of working in corporate IT for over 20 years, but he made a switch when he realized he wanted to focus less on management and more on consulting. He has lots of experience with Windows Virtual Desktop (and more) and creates content online to help others learn how to better utilize this technology.

In this episode, we talk about…

Travis’s background, how he got into consulting, and what the transition was like coming to that from corporate jobs.
How Azure has been ramping up and is currently neck and neck with AWS.
Why, at this point, most Systems Administrators are essentially Cloud Developers, as well.
How you have to think a bit differently when using ARM templates and PowerShell.
Why moving to the Cloud can save a business a lot of overhead expenses.
The mindset shift involved in maintaining a server rack with manual switches and buttons, versus working within Azure.
Why setting up a virtual network within Windows Virtual Desktop is so much faster than the traditional means.
Why you need to continuously learn given the way technology is shifting now -and how if you learn it sooner, you can help others as they shift to the Cloud during the next decade.
How building a brand can help you, and if you’re interested, you should start writing a blog or making Youtube videos.
The importance of Source Control and how Travis has been using Github.
The switch from using JSON to using HCL.
How Travis has been seeing that he’s been needing to learn more about Continuous Integration.

Resources from this episode:

Travis on Twitter
Travis onYouTube
Travis on LinkedIn
Udemy Course Discount: Zero to Hero with Windows Virtual Desktop

AWS for Azure Pros: The Ultimate AWS to Azure Service Comparison

TeamCloudSkills — Tue, 02 Feb 2021 10:52:28 +0000

Already know Azure but need to learn AWS? In this CloudSkills Community Call replay, MSFT MVP Mike Pfeiffer delivers a one-hour training that maps what you already know in Azure to comparable services in AWS.

Note: Throughout the video Mike mentions an upcoming AWS class at CloudSkills.io; it ended up becoming the Cloud Native DevOps Bootcamp:

https://cloudskills.io/cloudnative

Cloud Career Tips & Strategy for 2021

Mike Pfeiffer — Sat, 23 Jan 2021 11:09:26 +0000

In this episode I’m sharing by best career tips & strategy for 2021. What should you focus on? What do you need to think about to start building a successful career in the cloud? Those are some of the questions we answer in this episode, along with Q&A with a live audience.

In this episode, we talk about…

2021 industry predictions from Forester & Gartner
How to become multi-dimensional as an engineer
Soft skills you need to be building, in addition to hard skills
How to run experiments to gather data
How to get more hands-on experience
Q&A with a live audience

Getting Started with Terraform on Azure: Tips and Tricks

Luke Orellana — Sun, 16 Aug 2020 19:46:27 +0000

Modules
Remote State
Source Control
Keeping Designs Simple and Reusable
Conclusion

Infrastructure development is complex, and there can be many hoops to jump through. Making changes to live infrastructure code always involves some risk and can feel like a game of Jenga. While Terraform is relatively new (initial release in 2014), several proven practices are known in the Terraform community that help deal with some hurdles and complexities. Understanding the trial and errors of those who used Terraform early on allows us to learn from them and be more efficient when we are just starting. This knowledge increases the chance of success in implementing and using Terraform.

In this guide, we will review some practical tips and tricks to be mindful of when developing with Terraform. Although these are community proven practices, keep in mind that there is more than one way to do something, and it doesn't necessarily mean that's the best and most efficient way for you.

Modules

In the software development world, we break up reusable segments of our code into parameterized functions and reuse them. This practice allows us to write tests for these functions and maintain them. In Terraform, we use modules in the same manner. We make templates of infrastructure and convert them into modules, which allows the code in each module to be reusable, maintainable, and testable.

Do not create Terraform configurations that are thousands of lines of code. It reduces code quality and clarity when debugging or making changes. Splitting up your infrastructure code into modules will also prevent you from copying and pasting code between environments, which can introduce many errors.

Version Providers and Modules

The Azure Terraform provider is changing extremely fast. Check out the change log for the Azure provider. The amount of changes made every month is extreme, and many code-breaking changes appear in many updates. To guard yourself against this, version your provider and save yourself the headache:

provider "azurerm" {
  version = "1.38.0"
}

Additionally, version your modules, especially ones from the Terraform Registry. If you're developing private modules, version those as well. Versioning modules allow for introducing module changes without affecting the infrastructure that is currently using them. For example, let's say my current environment uses version 1.1 of my server module, which is stored in a repo and tagged with v1.1:

#Create Server
module "server" {
  source    = "git::https://allanore@dev.azure.com/allanore/terraform-azure-server/_git/terraform-azure-server?ref=v1.1"

  servername    = "myserver123"
  rgname    = azurerm_resource_group.rg.name
  location  = azurerm_resource_group.rg.location
}

I need to add a new feature to the module that includes Private Link functionality. In this case, I can use module versioning to safely deploy infrastructure using the new version without affecting infrastructure using version 1.1 by tagging it as version 1.2 and sourcing the specific module version:

#Create Server
module "server" {
  source    = "git::https://allanore@dev.azure.com/allanore/terraform-azure-server/_git/terraform-azure-server?ref=v1.2"

  servername    = "myserver211"
  rgname    = azurerm_resource_group.rg.name
  location  = azurerm_resource_group.rg.location
  private_link = true
}

Using versioning for both providers and modules is a must in Terraform, and you will quickly find out why if your not using them.

Use Dependency Injections

When reusing modules throughout different environments, some environments may contain required components that already exist. For example, if I write a module that requires a storage account for the service that it's deploying, there may be some environments where this storage account already exists. This scenario may cause some people to attempt to write logic into their code to check if a resource exists or not and perform X action if it does. Introducing complex logic like this is not in line with the declarative methodology that Terraform uses. The resource either exists or not.

Instead, use dependency injections. Create the module to allow input from resources that either already exist or are created in the configuration.
Take a look at the code below, for example. We have a Network Security Group module that requires a subnet ID to associate the NSG to a subnet. In this example, we are creating the subnet within the same configuration and passing it along. The subnet does not exist prior, so we are creating one to assign to the NSG:

# Subnet is directly managed in the Terraform configuration

resource "azurerm_subnet" "snet" {
  name                 = "snet-cloudapp-1"
  resource_group_name  = azurerm_resource_group.rg.name
  virtual_network_name = azurerm_virtual_network.vnet.name
  address_prefix       = "10.0.2.0/24"
}

module "nsg" {
  source                = "./modules/nsg"
  resource_group_name   = azurerm_resource_group.rg.name
  nsg_name              = "nsg-${var.system}-httpsallow"
  source_address_prefix = ["VirtualNetwork"]
  predefined_rules = [
    {
      name     = "HTTPS"
      priority = "500"
    },
    {
      name     = "RDP"
      priority = "501"
    }
  ]

  subnet_id = azurerm_subnet.snet.id

Alternatively, we have another environment where a subnet is already existing. We would use the azurerm_subnet data source to collect the subnet id information and pass it through to our module using data.arurerm_subnet.snet.id:

#Subnet already exists and is called with a data source block

data "azurerm_subnet" "snet" {
  name                 = "snet-coudapp-1"
  virtual_network_name = "production"
  resource_group_name  = "rg-networking"
}

module "nsg" {
  source                = "../../modules/nsg"
  resource_group_name   = azurerm_resource_group.rg.name
  nsg_name              = "nsg-${var.system}-httpsallow"
  source_address_prefix = ["VirtualNetwork"]
  predefined_rules = [
    {
      name     = "HTTPS"
      priority = "500"
    },
    {
      name     = "RDP"
      priority = "501"
    }
  ]

  subnet_id = data.azurerm_subnet.snet.id
}

We are not hard coding logic into the module to check for an existing subnet in these two examples. Instead, we take the declarative approach that Terraform is designed for and state in our configuration if it already exists or if it doesn't. Our module can now be reusable in different situations, and we are not complicating the module. We also have better visibility in the module code. Another co-worker on the team can look at the module and get a clear distinction between the two environments.

Remote State

Try to use remote state as soon as possible in your Terraform development. It can save many headaches later on, especially when multiple people become involved with deploying and managing the same Terraform code.

Using remote state allows us to secure sensitive variables in our configurations. The Terraform state file is not encrypted, so keeping it on a local workstation may quickly become a security issue. Also, don't make a habit of storing Terraform state files in source control. It increases the chance of exposing sensitive variables, especially if the repository is public. Instead, use a gitignore file to omit any tf.state files from accidentally getting committed automatically.

Split Up Terraform States

Terraservices is a popular term coined a few years ago which involves splitting up Terraform state into different environments to reduce the blast radius on changes made. You don't want to keep all your eggs in one basket. Let's say a team member makes a change to resize a VM. They end up fat fingering the resource group name, and their pipeline workflow auto applies the incorrect change. Terraform rebuilds the resource group and deletes all items causing catastrophic failures to the environment. This situation is not uncommon.

Also, be aware that your Terraform plan becomes longer and longer if you don't split up a reasonably large environment into separate states. It introduces a new type of risk. Now, the Terraform plan can take longer to run and become harder to read as there are more resources affected by the change. It also means unwanted changes can be easily missed. It's easier to catch a mistake in a few lines of code vs. 10000 lines.

Ideally, you want to separate high-risk components from components that are typically changed and modified. Don't keep all the eggs in one basket. Below is a Terraform project folder structure inspired by Gruntwork's recommended setup:

prod
  └ rg
    └ main.tf
    └ variables.tf
    └ output.tf
  └ networking
  └ services
      └ frontend-app
          └ main.tf
          └ variables.tf
          └ output.tf
      └ backend-app
  └ data-storage
      └ sql
      └ redis

In the folder structure above, each folder separates out the Terraform states. The resource group has its own state, limiting the risk of daily changes made to the resource group. Services like SQL and Redis are also separated to reduce the risk of accidentally modifying the databases on any change. Splitting up environment states like this reduces a lot of risks. However, it adds a lot of complexity to the infrastructure code. We now have to design ways to feed information between each state and deal with dependencies. Terraform currently doesn't allow for an easy way to manage this. But, tools like Terragrunt, developed by Gruntwork, address handling the complexities with splitting up Terraform state.

Source Control

Terraform and source control go together hand in hand. If you're not storing your Terraform code in source control, you're missing out on the following benefits:

Change Tracking: The historical data of all infrastructure changes is extremely powerful and a great bonus for auditors or compliance requirements.
Rollback: One of the major benefits of infrastructure as code is the ability to "rollback" to the previous configuration or state. However, depending on the environment, that rollback may mean a rebuild. Storing the Terraform configuration in source control makes it easier to re-deploy a pre-existing working state of the environment.
Collaboration Among Teams: Most source control tools like Azure DevOps, Github, or Bitbucket provide a form of access control. This role-based access allows for separate teams to manage their infrastructure code or provide read-only access to other teams for increased visibility of how the environment works. No more guessing if a firewall port is open or not; look at the code and see if it is.
Automation: There are many CI/CD tools available that hook into source control. These tools amplify the development and deployment of Terraform.

There is also the concept of GitOps, where processes are automated through Git workflows like submitting a pull request. There are community tools out there like Atlantis that are amazing for GitOps with Terraform and can increase efficiency among teams.

Structure Repo to Business Needs

Designing the source control repo structure for infrastructure can be an intimidating task, especially for those making the jump from a traditional systems engineer to an infrastructure developer role. There are various strategies for storing Terraform code. Some companies put all their Terraform configurations into a single repository, some store configurations with each project's application source code. So which one should I pick?

This short answer is, it depends on your environment. Large environments are going to have a completely different set up than start-up environments. Also, team structure comes largely into play here. Do you have a team that manages all the infrastructure, or is it the developers and DevOps engineers who manage the infrastructure for their application? You will see many DevOps experts and thought leaders in the community talk about Conway's Law, which states that the communication structure of organizations is the limiter on the way that they develop and design software. This concept is pretty evident when implementing Terraform into your organization. Analyze how your teams are structured and structure your Terraform configuration repos in a way that compliments that structure.

Here are several common repo strategies:

Single Repo:: All live infrastructure code is in one single repository managed by a governing team.
One Repo Per Project: Every application has its own Terraform folder, and code is stored in a folder of the application source code.
One Repo Per Environment: Environments are split up into their own repository and managed by separate teams. For example, code managing the company firewalls are in a separate repo and managed by the security or networking team. This strategy allows each team to own and manage their infrastructure responsibilities and delegate out lesser permissions for other teams to request changes or view the environment.

Don't stress out over getting your Terraform repo structure right when your first starting out. This will most likely change several times due to business needs, scaling up, or finding a better solution for your environment. Starbucks changed up its repo structure three times over several years and ended up settling on a repo per component strategy.

Keep All Live Infrastructure in the Master Branch

All live infrastructure changes should always stay in the master branch. Storing the same infrastructure code in multiple branches can cause conflicts and create headaches. For example, let's say a team member branches off of master and adjusts the Terraform configuration to change a VM's size. They make their change and deploy it, but don't merge their branch back into master because they are still making changes. A few minutes later, someone else modifies the same VM's tags but creates a different branch off of master that hasn't been updated yet with the new VM size. The change to the tags is deployed, and now the VM size is reverted back to its original size because it didn't contain the VM resize code. This is why it's important to make sure the master branch is always a live representation of the environment.

Execute Terraform Code Through a Pipeline

When first starting on Terraform, it is typical to have each infrastructure developer manage the infrastructure by authenticating locally on their machine with the Azure provider (either with AZ Cli or some environment variables). They execute the Terraform code with their local install of Terraform. Long term, this can cause a few headaches like inconsistent Terraform versions among developers. It's best to shift to deploying code with a pipeline by storing Terraform configurations in source control and running a Continuous Integration process that executes the Terraform code on pull requests. A pipeline significantly increases automation capabilities and has a few advantages:

Terraform code is run on the same platform every time, reducing errors due to inconsistent dependencies like Terraform versions.
Pipelines can introduce configuration error checking and Terraform policy, preventing insecure or destructive configurations changes from being made.
Automated testing can run to perform regression tests against modules when a new change is made to the modules.
Many pipeline tools provide some sort of secret store functionality that makes it easy to securely pass variables through to Terraform configurations.

Keeping Designs Simple and Reusable

It's essential to keep the right balance between creating conditional logic and introducing too many complexities. For example, it may be useful to add logic into a networking module that will automatically choose the next available subnet space on a Virtual Network and create a subnet. While this logic prevents a user from having to specify a subnet address when they use the module, it also adds more complexity and can make the module more brittle. It may be better to design the module to contain an argument to take in input for the subnet address, requiring the user to calculate a subnet address for the module input beforehand. These are trade-offs with pros and cons to each.

A code review is a software development practice where multiple developers check each other's code for mistakes. With infrastructure development, this is starting to become a more common practice. Complex Terraform code will take away from the benefits of code reviews. When peers cannot easily understand the code to review, errors can be easily missed.

Complex Terraform code will also make it harder to troubleshoot issues and onboard new people to the team. One of the benefits of IaC is the living documentation that it provides. Don't put in logic that makes infrastructure code too complex to use for documentation.

Connecting inputs and outputs between modules and states can introduce many complexities and can grow to become a dependency nightmare. When passing data between modules or state files, be mindful of the purpose and limit the dependencies involved in your design.

Use Provisioners Sparingly

Most provisioners introduce platform or network constraints into our Terraform code. For example, using a provisioner to SSH into a server once it's provisioned and run a script will now require the node executing the Terraform code to have network access to the VM during deployment.

Instead, take advantage of Azure's custom script extension for VMs to pass a script through to the VM without any network constraints.

The goal is to create infrastructure code that you can execute from anywhere. Aim to achieve this as much as possible to give your design even more reusability.

Use Terraform Graph to Troubleshoot Dependency Issues

During Terraform development, you may run into resource timing errors where a resource is deployed but relies on another resource that hasn't completed provisioning yet. Maybe a disk or a storage account provisions too fast half of the time or a subnet isn't deployed before a network interface. Typically this is due to a dependency issue in the configuration and is usually solved using interpolation between the proper resources or using a "depends on" block. However, these can be difficult to track down. With terraform graph, you can run this command against a configuration directory, and it will produce a DOT format output. You can then copy and paste the output into a website like WebGraphViz to generate a visual representation of the configuration dependencies to help troubleshoot.

Use the Terraform Registry

Especially when first starting out, don't try to reinvent the wheel. The State of the DevOps report shows that highly efficient teams re-use other people's code. There are many Azure modules already created on the Terraform Registry. If you need to deploy a specific Azure service, take the time to search the registry and see if a module has already been created for the service you need. If the modules that are in the Terraform registry don't meet your needs, you can fork these modules and customize them to your own.

Conclusion

When getting started with Terraform, don't try to do everything all at once. Start small and try to make minor improvements to your infrastructure little by little. Only focus on making one quality change at a time, instead of building one big massive project from the start with pipelines, modules, tests, and remote state storage. In the end, you will achieve faster results and create a higher quality design overall.

Also, keep in mind that every environment is different. Not all of these tips will fit every Terraform use case. For example, if your environment is very simple and extremely small, it may not be worth it to split up the Terraform state files. Having good judgment and design for your infrastructure code comes into play. Learn the different concepts in the community and explore how other people are using Terraform, and then do what works best for your environment.

Infrastructure as code has not yet reached its maturity and has yet to become the standard way of operating for most companies. Over the years, research has shown that companies adopting infrastructure as code are functioning at significantly higher speeds than those that are still running on traditional methods. This research is making skillsets with tools like Terraform high in demand for companies. Taking the time to learn it is well worth it. Terraform is still in its infancy stage, and the game will continue to evolve and always get better each year. Enjoy the creativity and embrace the complexity and learning that comes with infrastructure development.

Getting Started with Terraform on Azure: Testing

Luke Orellana — Sun, 16 Aug 2020 19:41:30 +0000

Prerequisites
Step 1 — Module Repo Folder Structure
Step 2 — Types of Testing
Step 3 — Static Analysis
Step 4— Unit Testing
Step 5 — Integration Testing
Step 6 — End-to-End Testing
Conclusion

In software development, testing code is a common practice. Software developers need to be able to validate parts of their code to ensure it is working in an automated fashion. The realm of infrastructure development takes software best practices to create and manage infrastructure code, and with that comes testing. You should be writing tests for your Terraform code.

Writing tests for Terraform provides many benefits that make life easier as an infrastructure developer. Automated tests provide faster loop feedback. No more making a change to a Terraform configuration and manually running terraform apply and then checking the Azure portal to ensure that the change is there. Instead, we can use tools like Terratest to perform these steps for us and allow us to test our modules much faster than we could manually. Not only do we get faster feedback, but also fewer bugs. Automating tests for every possible scenario in a Terraform configuration provides better code coverage and can catch bugs much quicker. Tests give us increased confidence in our changes and provide us with greater predictability for our change. We can now accurately predict that our code deploys what we designed it to deploy without destroying other resources.

One common misconception is that because Terraform is declarative, we don't need to write tests for it. We are already declaring the resource that needs to exist. If there is an issue with provisioning that resource, Terraform automatically provides the error. This is a valid point, which is why when we talk about testing our Terraform code, we want to write tests for sanity checks, conditional logic, and variable outcomes in our code. For example, writing a test for the following code to create a resource group would add minimal benefit:

resource "azurerm_resource_group" "rg" {
    name     = "rg-myrg"
    location = var.location
}

If we wrote in a check to ensure that the resource group deploys to the proper location, this would be a redundant check. The resource group will automatically be built in the location we specify, and if it's not successful, an error event occurs natively through Terraform. Writing hundreds of tests in this way could become more of a maintenance burden since we would have to continually modify the test to keep up with changes to the module.

On the other hand, writing a test for the example below would be more beneficial since it contains more variance in the outcome and could potentially become altered when changes are made to the module:

resource "azurerm_resource_group" "rg" {
    name     = "rg-myrg"
    location = var.environment != "Production" ? "southcentralus" : "northcentralus"
}

In this guide, we are going to clone a module repository and walk through writing and running tests for it.

Prerequisites

Before you begin, you'll need to set up the following:

Azure subscription.

Since we will be writing tests in GO, we will need an environment set up to write these tests. We are going to use Visual Studio Codespaces to walk through this guide. Visual Studio Codespaces is an online version of Visual Studio Code. It allows us to automatically deploy an environment with a code repository so we can dive into creating tests with minimal setup.

Note: We will be using the basic sized environment for our Visual Studio Codespace. The compute for this service will be hosted in your Azure tenant, so there will be some charges associated. The average cost for a basic environment is around $0.08 per hour. Also, environments can be in a "suspended" and "active" state, which reduces pricing even further. For more information on VSC billing, check out the pricing page.

To create the Codespaces environment, navigate to the Visual Studio Codespaces login page and sign in with your Azure credentials. Make sure to use Google Chrome as FireFox and Edge are not yet supported. Once logged in, we will be presented with the following page below. Select Create Codespace:

Next, we need to create a billing plan. The billing plan connects the Visual Studio Codespace environment to our Azure subscription. Select a location that makes sense for you. Also, you can input a plan name according to your Azure naming standards. The plan name is the name of the Azure resource that deploys to your subscription. Next, we need to specify the resource group to host the Visual Studio Codespace resource. When done configuring these settings select Create:

Now we can set up our Codespace; this is the Visual Studio environment. We could have multiple Codespaces in our plan if we wanted to. Input a Codespace Name for the Codespace. Under Git Repository paste in the following GitHub repo:

https://github.com/allanore/terraform-azure-testing

The GitHub repo contains the code for the Terraform module that we will create tests for in this guide. There is also a post-create.sh script in this repo that automatically installs the tools we want for our environment, like Go and Terraform. Under Instance Type, select the Basic type. Next, select Create to build out our VSC environment finally:

We should see our environment starting to build and the post-create.sh script automatically executes and installs our tools and extensions. We are installing GO, Terraform, and a few other tools:

Note: You may need to refresh your browser at some point to get this screen to show up.

Once the Configure Codespace section shows complete, we are ready to move on to reviewing the folder structure of this repository:

Step 1 — Module Repo Folder Structure

Before we can write our tests, we need to know a little more about what this module does and the structure of the repo. The function of this Terraform module is to deploy a virtual network. There are also submodules for creating a network security group and virtual network peer. In Visual Studio Codespaces, you should see the following folder structure on the left-hand side:

At the root of this repo we can see several files, we have our .gitignore file, which contains a list of file types that we don't want to save into source control, like .tfstate. Next, we have our .pre-commit-config.yaml file, which contains a list of tools to execute on each git commit. We will go deeper into this in a later step. Last, we have our Terraform configuration files main.tf, output.tf, and variables.tf. These are the root Terraform files and perform the base function of our module, which is to create a virtual network and subnet.

Now that we've gone over the files in the root folder of this module, let's go over each folder so we have a better understanding:

.devcontainer - This folder is only used to automate the Visual Studio Codespace environment. It does not affect our terraform module.
.azuredevops - Contains our CI pipeline for Azure DevOps. We won't be going over Azure DevOps in this guide, but if you wanted to take this guide a step further and add this repository into an Azure DevOps pipeline, this is the yml file with all the steps needed.
examples - The examples folder serves two purposes. First, it serves as documentation on how to use the module. Second, it serves as Terraform code that we can use for testing. We can execute these examples in our test files to stand up resources that we can test against. There are two subfolders in the examples folder. Each one has code for performing different tasks of the module. The network folder contains code for standing up a Virtual Network and Network Security Group. The vnet-peering folder contains code for standing up two virtual networks and then peering them together.
modules - The modules folder contains our sub-modules or helper modules that provide additional features like creating a Network Security Group or Virtual Network Peer. These are optional modules that provide more flexibility and options for those that are using the module.
test - This is where our test files will live.

It is best practice in Terraform to split up tasks or services into modules. We want to use our modules as building blocks to build infrastructure one piece at a time. From a developer perspective, one might think of modules like functions. Where each module is performing the heavy lifting of a specific task:

Having our infrastructure built in smaller units like modules allows us to write tests for them. You can't write a test for a Terraform configuration that is thousands of lines of code. This also provides us with a smaller blast radius when making changes to code. If I make a change to my web app module, I don't put the entire application at risk.

Even though there is a smaller blast radius, there is still potential to destroy infrastructure when making changes to modules, which is why there needs to be a thorough automated way to test our modules and test them often. Next, we will go over the different types of tests we can write.

Step 2 — Types of Testing

There are four basic types of testing. These terms are loosely categorized in the infrastructure as code world. We are still in the infant stages, and there hasn't been a standardized definition for each category. We will be going over the way that Gruntwork defines testing in Terraform. Gruntwork is a company that provides Terraform modules to companies that desire to have IaC in their environment but don't have the skillset or time to create their own. They have years of experience developing infrastructure in Terraform and are also the creators of Terratest, which is the tool we will be using for some of our tests.

These are the four basic types of tests:

Static Analysis - Testing code without running it.
Unit Testing - Testing a single unit.
Integration Testing - Testing the functionality between two or more units.
End-to-End Testing - Testing an entire application infrastructure from the ground up.

Below is a diagram demonstrating the cost of each test. We want to run most of our tests at the bottom because that is the quickest and least costly to run. Each test will also catch different types of bugs. If we aim to catch most bugs with static analysis and unit tests, we will gain much more speed in development than if we are testing for the same bug in an end-to-end test.

Step 3 — Static Analysis

Static analysis tests involve testing our code without running it. We want to run a tool that can look at our code and analyze if there is a bug in it. A great way to perform static analysis testing is by using a tool called pre-commit. Pre-commit packages git hooks together to allow for tools to be run after each commit. If we look at the contents of the .pre-commit-config.yaml file in our repo, we can see it's configured to run several hooks. We can also see the repository URL, which contains all the git hook scripts for these hooks. This allows us to manage our git hooks and distribute them amongst team members in a much more manageable fashion. This pre-commit repo is from Gruntwork, they've done all the work to create the hooks and bundle them up into a pre-commit repository for community use:

repos:
  - repo: https://github.com/gruntwork-io/pre-commit
    rev: v0.1.4
    hooks:
      - id: terraform-fmt
      - id: terraform-validate
      - id: gofmt
      - id: golint

In the .precommit-config.yaml, there are two hooks for Terraform and two for GO. Terraform-fmt is a hook that runs the terraform fmt command, which automatically formats code to look pretty with proper spacing. Terraform-validate runs the terraform validate command against our code to ensure it is syntactically correct by checking for no misplaced { } or invalid Terraform syntax.

Let's give these two hooks a test by modifying some Terraform code. Open the variables.tf file in the root of the repo and add a description to the system variable. Let's purposely use the argument descriptions instead of description in our variable to catch the error in the pre-commit hook. Copy the snippet below and overwrite the content currently there for the system variable:

variable "system" {
  type         = string
  descriptions = "Name of the system or environment"
  default      = "terratest"
}

Save the changes by entering CTRL + S on the keyboard. Before pre-commit can run, we need to configure the hooks for this repository. Open up the terminal by entering CTRL + ~ on the keyboard and run the following command:

pre-commit install

Now let's try to commit our change we made to the system variable in the variables.tf file. When we run our commit, the pre-commit hooks for terraform fmt and terraform validate are triggered:

git add .
git commit -m "this is a test commit to trigger our pre-commit hooks"

We should see in the output that terraform validate has run and failed. We should also see the error message describing why it failed, which is because we used the argument descriptions instead of description which is the correct argument:


Terraform has installed the required providers to support the configuration
upgrade process. To begin upgrading your configuration, run the following:
    terraform 0.12upgrade

To see the full set of errors that led to this message, run:
    terraform validate

Error: Unsupported argument

  on variables.tf line 3, in variable "system":
   3:   descriptions = "Name of the system or environment"

An argument named "descriptions" is not expected here. Did you mean
"description"?

To fix the change, rename thedescriptions argument to description, which should clear our invalid syntax error. But this time, add a large number of spaces in the default argument. This unsightly formatting will trigger our terraform fmt pre-commit hook:

variable "system" {
  type         = string
  description = "Name of the system or environment"
  default      =                        "terratest"
}

Now, let's add and commit the changes again in git:

git add .
git commit -m "this is a test commit to trigger our pre-commit hooks"

This time we see that terraform fmt failed. We added that additional spaces in there which goofed up the formatting in our code. Terraform fmt automatically runs and corrects these changes when the pre-commit hook runs, if it detects any formatting changes made, it will cause a failure like so:

Note: The gofmt and golint hooks display as skipped. This is because we did not modify any GO files. The pre-commit hooks only run against the files that have been modified and will only trigger against each one's respective file type.

Terraform fmt............................................................Failed
- hook id: terraform-fmt
- files were modified by this hook

variables.tf

Terraform validate.......................................................Passed
gofmt................................................(no files to check)Skipped
golint...............................................(no files to check)Skipped

If we look at our variables.tf file, we can see that terraform fmt has corrected our spaces. Now we can run our add and commit again to save all our changes finally. In the output we can see that both checks pass this time:

vsonline:~/workspace/terraform-azure-testing$ git add .
vsonline:~/workspace/terraform-azure-testing$ git commit -m "this is a test commit to trigger our pre-commit hooks"
Terraform fmt............................................................Passed
Terraform validate.......................................................Passed
gofmt................................................(no files to check)Skipped
golint...............................................(no files to check)Skipped
[master 9b67894] this is a test commit to trigger our pre-commit hooks
 1 file changed, 3 insertions(+), 2 deletions(-)

Now our commit is complete. With pre-commit hooks, we can catch bugs before they are committed to code. This process makes our commits much cleaner and prevents silly mistakes from getting committed to source control. It also helps out with code reviews by weeding out syntactical mistakes. We can catch errors quicker in development, where if we just made a change and ran Terraform apply to test, we would have to wait for that process to kick-off before we realized our configuration wasn't syntactically correct. We can iterate through our code quicker, which speeds up development. We could also perform static analysis testing within a CI/CD pipeline to analyze our Terraform plan.

Terraform validate is a basic static analysis test that we can perform. There are many other static analysis tools in the community that provide great benefits. Below are a few to note:

TFlint - Catch provider specific bugs like incorrect Azure VM sizes.
ConfTest - Analyze TF plan files and enforces defined policies and governance.
CheckOV - Security and compliance on the Terraform configuration level.

Step 4— Unit Testing

A unit test involves testing a single unit or individual component. This is the smallest testable piece of code that can be achieved. In Terraform, we could write tests that check the resource blocks in our Terraform configuration, however many in the Terraform community agree that it offers very little value. To write a valuable unit test, we need to communicate with the provider and stand up infrastructure, which by software development testing standards is technically not a true unit test. Its an integration test. In infrastructure development with Terraform, Gruntwork defines a unit test as testing a single module by itself.

We are going to write a unit test for our networking module. We will create a test that uses Terratest. Terratest is a GO library, built by Gruntwork, for testing Terraform. Our unit test will automatically deploy the Terraform code from the examples/network folder, test to ensure the desired outcome is achieved in Azure using the Azure API, then run a terraform destroy and tear down our test infrastructure at the end. The process is the same as if we were manually testing the module, except we are automating it.

First, we need to create a GO test file called terraform_azure_network_test.go. To make this file, right-click on the test folder in Visual Studio Codespace and select new file. Then name the file terraform_azure_network_test.go. Notice that file ends in _test.go. This format indicates that the file is a GO test file. Go will automatically see this file as a test file and execute it when we run our test command later. Now we will create the foundational code for our unit test.

Base Setup

Below is the code for a base test setup. I typically use this as a starting point for creating a test and then expand from there. Copy this code to the terraform_azure_network_test.go file:

package test

import (
  "github.com/gruntwork-io/terratest/modules/terraform"
  "testing"
)


func TestTerraformAzureNetworkingExample(t *testing.T) {
    t.Parallel()

    terraformOptions := &terraform.Options{
    }

    // At the end of the test, run `terraform destroy` to clean up any resources that were created
    defer terraform.Destroy(t, terraformOptions)

    // This will run `terraform init` and `terraform apply` and fail the test if there are any errors
    terraform.InitAndApply(t, terraformOptions)

}

Let's review all the parts and pieces of the code. Starting from the top we have package test declaring that the name of our package is test (which describes the purpose of our package):

package test

Next, we have our import declaration. The import declaration contains libraries or packages used in the Golang code. In Golang, libraries and packages are similar to modules in PowerShell. We can reference packages native to GO, or we can reference ones from source control repos like GitHub. We will be adding more libraries as we build out our unit test, for now, we are using the testing GO package and the github.com/gruntwork-io/terratest/modules/terraform library created by Gruntwork, which allows us to automate deploying code with Terraform during the test:

import (
  "github.com/gruntwork-io/terratest/modules/terraform"
  "testing"
)

After our import declaration, we have our testing function, which we called TestTerraformAzureNetworkingExample. Testing functions in GO have the following format; they also need to start with the word Test with a capital T followed by a capitalized letter after Test. We also are using t.Parallel() which indicates that we want to run this test in parallel with other tests. This parallel statement is a big deal because we can run multiple tests at once to test our module in several different ways:

func TestTerraformAzureNetworkingExample(t *testing.T) {
    t.Parallel()

Inside our function is a variable called terraformOptions. In GO, we can declare variables by using :=, which is different than in PowerShell, where we would use $variables = somevalue to declare a variable. Inside our variable declaration, we are using the github.com/gruntwork-io/terratest/modules/terraform library by referencing the package name of our library terraform. Then we are referencing the object inside the library called Options. This object is called a struct in Golang. A struct is similar to an object in PowerShell. We are essentially making an options object that we can add a collection of settings to and pass them through to Terraform. For now, we have no options defined in our struct, but in the next step, we will add them:

    terraformOptions := &terraform.Options{
    }

To finish out our testing function, we have two more lines of code. We are using the Terratest library again by referencing terraform. However, this time we are using the Destroy and InitAndApply functions from the Terratest library to perform the standard terraform init, apply, and destroy commands using our defined options in the terraformOptions variables. Note, the defer in GO is similar to a finally in PowerShell. The defer means GO will run this function at the end and will always run it even if the test were to error out:

defer terraform.Destroy(t, terraformOptions)

terraform.InitAndApply(t, terraformOptions)

Configure Terraform Options

Let's add some options to our terraformOptions variable. Our Terraform code in the examples/network folder has a variables.tf file that allows us to input several parameters and customize our network infrastructure when deployed:

variable "system" {
  type        = string
  description = "Name of the system or environment"
  default     = "terratest"
}
variable "location" {
  type        = string
  description = "Azure location of terraform server environment"
  default     = "westus2"
}
variable "vnet_address_space" {
  description = "Address space for Virtual Network"
}

variable "subnet_prefix" {
  type = string
  description = "Prefix of subnet address"
}

We need to define the values for these variables in our unit test and then pass them through to Terraform using the terraformOptions variable.

If you notice in our variables.tf file, we have a variable for location. For the location variable value, we want to be able to randomly test deploying into different regions that could be a possibility for us to use. This randomization allows us to have a thorough test since each test can deploy infrastructure into one of the listed regions. We will do this by providing a list of possible regions to deploy to in our test and then randomly pick one when the test runs. Doing this can also help sniff out any region-specific incidents occurring in Azure when we run our tests.

To create a list of regions, we are declaring a variable called regions and setting the variable type to []string which stands for a list of strings. Then, we are filling out that list with various regions in Azure that we want to test in:

    var regions = []string{
        "centralus",
        "eastus",
        "eastus2",
        "northcentralus",
        "southcentralus",
        "westcentralus",
        "westus",
        "westus2",
    }

Next, we create a variable for our regions that uses the function RandomString to pick a region from our list of regions randomly:

azureRegion := random.RandomString(regions)

Now that we have a variable created for the Terraform location input variable, we can configure the values for the rest of the input variables. For the system variable, we are going to use a similar concept that we used for the Azure region. We are going to generate a random name for the system name.

systemName := strings.ToLower(random.UniqueId())

This random name generation allows us to run this test several times at the same time without overlapping within the same resource name. It is useful when multiple people are adding features to a module on their branches and are running the tests. Next, we have hardcoded values for our virtual network address and subnet prefix:

vnetAddress := "10.0.0.0/16"
subnetPrefix := "10.0.0.0/24"

Now that we have values for our input variables, we need to pass them into terraformOptions. We add the TerraformDir argument to specify the directory of the code we want to execute is the code in the examples/network folder of our repo. Next, we are importing a map of variables, which allows us to pass values through to Terraform as if we were using the -var option in the command line. We are passing through all four variables that we just set up in GO:

terraformOptions := &terraform.Options{

        TerraformDir: "../examples/network",

        Vars: map[string]interface{}{
            "system":             systemName,
            "location":           azureRegion,
            "vnet_address_space": vnetAddress,
            "subnet_prefix":      subnetPrefix,
        },
    }

We need to add two more packages and libraries to our import declaration since we are now using them to create a random string for the system name and to choose our Azure region randomly:

import (
    "strings"
    "testing"


    "github.com/gruntwork-io/terratest/modules/random"
    "github.com/gruntwork-io/terratest/modules/terraform"
)

Now we have our test configured to run our Terraform code in the examples/network folder with values for the variables.tf file. At this point, our unit test in terraform_azure_network_test.go should look like the following:

package test

import (
    "strings"
    "testing"

    "github.com/gruntwork-io/terratest/modules/random"
    "github.com/gruntwork-io/terratest/modules/terraform"
)

// An example of how to test the Terraform module in examples/terraform-azure-example using Terratest.
func TestTerraformAzureNetworkingExample(t *testing.T) {
    t.Parallel()

    var regions = []string{
        "centralus",
        "eastus",
        "eastus2",
        "northcentralus",
        "southcentralus",
        "westcentralus",
        "westus",
        "westus2",
    }

    // Pick a random Azure region to test in.
    azureRegion := random.RandomString(regions)

    // Network Settings for Vnet and Subnet
    systemName := strings.ToLower(random.UniqueId())
    vnetAddress := "10.0.0.0/16"
    subnetPrefix := "10.0.0.0/24"

    terraformOptions := &terraform.Options{

        // The path to where our Terraform code is located
        TerraformDir: "../examples/network",

        // Variables to pass to our Terraform code using -var options
        Vars: map[string]interface{}{
            "system":             systemName,
            "location":           azureRegion,
            "vnet_address_space": vnetAddress,
            "subnet_prefix":      subnetPrefix,
        },
    }

    // At the end of the test, run `terraform destroy` to clean up any resources that were created
    defer terraform.Destroy(t, terraformOptions)

    // This will run `terraform init` and `terraform apply` and fail the test if there are any errors
    terraform.InitAndApply(t, terraformOptions)
}

Add In The Tests

Now we are ready to add in some tests. We want to write tests that are meaningful and don't want the process to become a burden to maintain. Determining if a test is meaningful depends on the situation and environment. A meaningful test for someone else doesn't mean it is meaningful for your case. For this example, we are going to keep things simple. We want to test that our virtual network subnet is truly associated with an NSG after our Terraform example is deployed. This test ensures that any change to our module in the future won't interrupt this desired outcome, which could result in a potential security risk if the NSG was not assigned to the subnet.

Our Terraform code in the examples/network folder contains the following in the output.tf file. These are values we want to use to perform our tests:

output "vnet_rg" {
  description = "Location of vnet"
  value       = module.vnet.vnet_rg
}

output "subnet_id" {
  description = "Subnet ID"
  value       = module.vnet.subnet_id
}

output "nsg_name" {
  description = "Name of vnet Security Group"
  value       = module.nsg.nsg_name
}

Note: We want to make sure our modules are not too large to be tested. We don't want a 10,000 line module because it's not possible to unit test. The more you write tests for your modules, the more structured your modules become for testing. This practice becomes a great benefit as it allows for a more stable and better structured Terraform code.

The terraform.Output function allows us to collect output values from our Terraform deployment after the init and apply has completed. We are referencing the terraformOptions variable which contains our Terraform environment settings. Also we include each output value from output.tf. Then we save each output value into a variable in GO:

vnetRG := terraform.Output(t, terraformOptions, "vnet_rg")
subnetID := terraform.Output(t, terraformOptions, "subnet_id")
nsgName := terraform.Output(t, terraformOptions, "nsg_name")

Now we will use the output variables we created to directly check our Azure environment using the Azure API and confirm that the NSG we create is assigned to the subnet. We perform a lookup of all subnet IDs assigned to the NSG using the azure.GetAssociationsforNSG function, which requires the virtual network resource group and NSG name. Then we run a test using the assert GO package, which allows us to compare all the resources IDs in our nsgAssociations variable with the subnetID variable, which contains the output information from our Terraform code. This comparison allows us to take the subnet ID output from Terraform and look into Azure using the API and verify that it's assigned to the NSG we created:

    // Look up Subnet and NIC ID associations of NSG
    nsgAssociations := azure.GetAssociationsforNSG(t, vnetRG, nsgName, "")

    //Check if subnet is associated with NSG
    assert.Contains(t, nsgAssociations, subnetID)

If the subnet ID is in the list of NSG associations, our test will pass, if it is missing, the test will fail.

Lastly, we will need to add two more libraries to our import declaration. We are using assert to perform a comparison and validate our subnet ID is associated with the NSG, and we are using the function azure.GetAssociationsforNSG from the GO library aztest. The azure.GetAssociationsforNSG function allows us to quickly authenticate with our Azure environment and look up assigned resources to an NSG. It is just a helper function for working with the Azure GO SDK which communicates with the Azure API:

Note: The Azure test library in Terratest right now is fairly limited compared to AWS. Gruntwork has been heavily focused on building out the AWS and GCP modules. In the current state, most companies are just making their own private libraries for testing their resources in Azure. To help people get started writing tests for Terraform code in Azure, I have expanded upon the Terratest Azure testing functions and created a public GO library called AzTest, feel free to use it.

import (
    "strings"
    "testing"

    "github.com/allanore/aztest/modules/azure"
    "github.com/gruntwork-io/terratest/modules/random"
    "github.com/gruntwork-io/terratest/modules/terraform"
    "github.com/stretchr/testify/assert"
)

Now that we have our test written, our entire unit test is as follows. Copy the following to terraform_azure_network_test.go:

package test

import (
    "strings"
    "testing"

    "github.com/allanore/aztest/modules/azure"
    "github.com/gruntwork-io/terratest/modules/random"
    "github.com/gruntwork-io/terratest/modules/terraform"
    "github.com/stretchr/testify/assert"
)

// An example of how to test the Terraform module in examples/terraform-azure-example using Terratest.
func TestTerraformAzureNetworkingExample(t *testing.T) {
    t.Parallel()

    var regions = []string{
        "centralus",
        "eastus",
        "eastus2",
        "northcentralus",
        "southcentralus",
        "westcentralus",
        "westus",
        "westus2",
    }

    // Pick a random Azure region to test in.
    azureRegion := random.RandomString(regions)

    // Network Settings for Vnet and Subnet
    systemName := strings.ToLower(random.UniqueId())
    vnetAddress := "10.0.0.0/16"
    subnetPrefix := "10.0.0.0/24"

    terraformOptions := &terraform.Options{

        // The path to where our Terraform code is located
        TerraformDir: "../examples/network",

        // Variables to pass to our Terraform code using -var options
        Vars: map[string]interface{}{
            "system":             systemName,
            "location":           azureRegion,
            "vnet_address_space": vnetAddress,
            "subnet_prefix":      subnetPrefix,
        },
    }

    // At the end of the test, run `terraform destroy` to clean up any resources that were created
    defer terraform.Destroy(t, terraformOptions)

    // This will run `terraform init` and `terraform apply` and fail the test if there are any errors
    terraform.InitAndApply(t, terraformOptions)

    // Run `terraform output` to get the value of an output variable
    vnetRG := terraform.Output(t, terraformOptions, "vnet_rg")
    subnetID := terraform.Output(t, terraformOptions, "subnet_id")
    nsgName := terraform.Output(t, terraformOptions, "nsg_name")

    // Look up Subnet and NIC ID associations of NSG
    nsgAssociations := azure.GetAssociationsforNSG(t, vnetRG, nsgName, "")

    //Check if subnet is associated with NSG
    assert.Contains(t, nsgAssociations, subnetID)

}

Whew! We just built our first unit test in GO. Now, let's run it. First, we need to authenticate to Azure. The easiest way is to use Azure CLI. Type in the following command in the terminal while in the ~/workspace/terraform-azure-testing/test directory. Log in with your Azure account:

az login

Now, we need to set the ARM_SUBSCRIPTION_ID environment variable which is used for several functions in Terratest when deploying to Azure:

export ARM_SUBSCRIPTION_ID=$(az account show | jq '.id' -r)

Once logged in with Azure CLI, we need to download all of our dependencies for our tests. The dependencies include the packages that we specified during the import declaration. This concept is similar to running install-module in PowerShell to install all the external modules used in a script. Type the following command using go get while in the test directory:

go get -t -v

We see the libraries and packages download. This process may take a minute. Once complete, we are ready to run our test. To kick off the test, type in the following command. We are using the go test command with -v to specify verbose output. Also, we are specifying the GO test file that we just created:

go test -v terraform_azure_network_test.go

We will start to see Terraform executing our example code in the output display:

=== RUN   TestTerraformAzureNetworkingExample
=== PAUSE TestTerraformAzureNetworkingExample
=== CONT  TestTerraformAzureNetworkingExample
TestTerraformAzureNetworkingExample 2020-05-09T14:30:17Z retry.go:72: terraform [init -upgrade=false]
TestTerraformAzureNetworkingExample 2020-05-09T14:30:17Z command.go:86: Running command terraform with args [init -upgrade=false]
TestTerraformAzureNetworkingExample 2020-05-09T14:30:17Z command.go:168: Initializing modules...
TestTerraformAzureNetworkingExample 2020-05-09T14:30:17Z command.go:168: 
TestTerraformAzureNetworkingExample 2020-05-09T14:30:17Z command.go:168: Initializing the backend...
TestTerraformAzureNetworkingExample 2020-05-09T14:30:17Z command.go:168: 
TestTerraformAzureNetworkingExample 2020-05-09T14:30:17Z command.go:168: Initializing provider plugins...
TestTerraformAzureNetworkingExample 2020-05-09T14:30:19Z command.go:168: 
TestTerraformAzureNetworkingExample 2020-05-09T14:30:19Z command.go:168: Terraform has been successfully initialized!
TestTerraformAzureNetworkingExample 2020-05-09T14:30:19Z command.go:168:

Don't hit CTRL + C during the test; this will prevent resources from being cleaned up in Azure. If the test should error out, the defer stage runs and executes Terraform destroy to remove anything that was provisioned.

The test is executing the Terraform code in the examples/network folder, running a test to ensure that the NSG is associated with the subnet, and running Terraform destroy at the end. Once the test run completes, we see the result like below:

TestTerraformAzureNetworkingExample 2020-05-09T14:32:01Z command.go:168: azurerm_resource_group.rg: Destruction complete after 47s
TestTerraformAzureNetworkingExample 2020-05-09T14:32:01Z command.go:168: 
TestTerraformAzureNetworkingExample 2020-05-09T14:32:01Z command.go:168: Destroy complete! Resources: 7 destroyed.
--- PASS: TestTerraformAzureNetworkingExample (103.78s)
PASS
ok      command-line-arguments  103.783s

Now our unit test is complete! In the next step, we will add an integration test.

Step 5 — Integration Testing

An integration test with infrastructure code is defined as testing the functionality of two components interacting together. This could be a Webapp with a SQL database or two microservices interacting with each other. For demonstration purposes, we are going to keep it very simple and stand up two virtual networks and test that we can peer them together. The example code for each vnet is in the examples/vnet-peering directory. Our integration test will execute the Terraform code in vnet1 to deploy the first virtual network. Once complete, the test will execute the code in vnet2 to deploy a second virtual network and peer them together. We will then write a test that validates that the peering was successful:

examples
    └──networking
    └──vnet-peering
      └─vnet1
          └─main.tf
          └─output.tf
          └─variables.tf
      └─vnet2
          └─main.tf
          └─output.tf
          └─variables.tf

In our test directory, let's create another GO test file called terraform_azure_network_peering_test.go.

Base Test

We will copy the following code below and paste it in as our base test configuration. Notice we now have two sets of terraform.options as well as two sets of the destroy and apply steps:

package test

import (

    "testing"


    "github.com/gruntwork-io/terratest/modules/terraform"
)

// An example of how to test the Terraform module in examples/terraform-azure-example using Terratest.
func TestTerraformAzureNetworkingPeeringExample(t *testing.T) {
    t.Parallel()


    vnet1Opts := &terraform.Options{

    }

    // Deploy VNet1
    defer terraform.Destroy(t, vnet1Opts)
    terraform.InitAndApply(t, vnet1Opts)

    vnet2Opts := &terraform.Options{

    }

    // Deploy VNet2
    defer terraform.Destroy(t, vnet2Opts)
    terraform.InitAndApply(t, vnet2Opts)
}

Add in Terraform Options

Next, we will add in the Terraform options. We include the steps for randomized Azure regions as well as using random system names for our virtual networks. The big difference from our unit test is that we are passing the Terraform output values after deploying VNet1 to the terraform.options of VNet2, this allows us to configure the peering between them:

package test

import (
    "strings"
    "testing"

    "github.com/gruntwork-io/terratest/modules/random"
    "github.com/gruntwork-io/terratest/modules/terraform"
)

// An example of how to test the Terraform module in examples/terraform-azure-example using Terratest.
func TestTerraformAzureNetworkingPeeringExample(t *testing.T) {
    t.Parallel()

    var regions = []string{
        "centralus",
        "eastus",
        "eastus2",
        "northcentralus",
        "southcentralus",
        "westcentralus",
        "westus",
        "westus2",
    }

    // Pick a random Azure region to test in.
    azureRegion := random.RandomString(regions)

    // Network Settings for Vnet and Subnet
    vnet1Sysname := strings.ToLower(random.UniqueId())
    vnet1Address := "10.0.0.0/16"
    vnet1SubnetPrefix := "10.0.0.0/24"
    vnet2Sysname := strings.ToLower(random.UniqueId())
    vnet2Address := "10.1.0.0/16"
    vnet2SubnetPrefix := "10.1.0.0/24"

    vnet1Opts := &terraform.Options{

        // The path to where our Terraform code is located
        TerraformDir: "../examples/vnet-peering/vnet1",

        // Variables to pass to our Terraform code using -var options
        Vars: map[string]interface{}{
            "system":             vnet1Sysname,
            "location":           azureRegion,
            "vnet_address_space": vnet1Address,
            "subnet_prefix":      vnet1SubnetPrefix,
        },
    }

    // Deploy VNet1
    defer terraform.Destroy(t, vnet1Opts)
    terraform.InitAndApply(t, vnet1Opts)
    vnetOutRG := terraform.Output(t, vnet1Opts, "vnet_rg")
    vnetOutName := terraform.Output(t, vnet1Opts, "vnet_name")

    vnet2Opts := &terraform.Options{

        // The path to where our Terraform code is located
        TerraformDir: "../examples/vnet-peering/vnet2",

        // Variables to pass to our Terraform code using -var options
        Vars: map[string]interface{}{
            "system":             vnet2Sysname,
            "location":           azureRegion,
            "vnet_address_space": vnet2Address,
            "subnet_prefix":      vnet2SubnetPrefix,
            "peer_vnet_rg":       vnetOutRG,
            "peer_vnet_name":     vnetOutName,
        },
    }

    // Deploy VNet2
    defer terraform.Destroy(t, vnet2Opts)
    terraform.InitAndApply(t, vnet2Opts)
}

Add In The tests

Next, we will add in the tests. We are collecting the resource group and virtual network name from the output of deploying VNet2. Then we are using those values to look up the virtual network with the azure.GetVnetbyName function and storing them in the vnet2Properties variable. We are taking the virtual network peering properties from the vnet2Properties variable and using a for loop in GO to loop through all of the values within the VirtualNetworkPeerings property, which contains a list of all peerings made on the virtual network. We are then validating that all peerings in that property are in a Succeeded state, ensuring that they peered properly:

    // Collect RG and Virtual Network name from VNet2 Output
    vnet2RG := terraform.Output(t, vnet2Opts, "vnet_rg")
    vnet2Name := terraform.Output(t, vnet2Opts, "vnet_name")

    // Look up Virtual Network 2 by Name
    vnet2Properties := azure.GetVnetbyName(t, vnet2RG, vnet2Name, "")

    //Check if VNet Peering in VNet2 Provisioned Successfully
    for _, vnet := range *vnet2Properties.VirtualNetworkPeerings {
        assert.Equal(t, "Succeeded", string(vnet.VirtualNetworkPeeringPropertiesFormat.ProvisioningState), "Check if Peerings provisioned successfully")
    }

Our final integration test file should look like the following:

package test

import (
    "strings"
    "testing"

    "github.com/allanore/aztest/modules/azure"
    "github.com/gruntwork-io/terratest/modules/random"
    "github.com/gruntwork-io/terratest/modules/terraform"
    "github.com/stretchr/testify/assert"
)

// An example of how to test the Terraform module in examples/terraform-azure-example using Terratest.
func TestTerraformAzureNetworkingPeeringExample(t *testing.T) {
    t.Parallel()

    var regions = []string{
        "centralus",
        "eastus",
        "eastus2",
        "northcentralus",
        "southcentralus",
        "westcentralus",
        "westus",
        "westus2",
    }

    // Pick a random Azure region to test in.
    azureRegion := random.RandomString(regions)

    // Network Settings for Vnet and Subnet
    vnet1Sysname := strings.ToLower(random.UniqueId())
    vnet1Address := "10.0.0.0/16"
    vnet1SubnetPrefix := "10.0.0.0/24"
    vnet2Sysname := strings.ToLower(random.UniqueId())
    vnet2Address := "10.1.0.0/16"
    vnet2SubnetPrefix := "10.1.0.0/24"

    vnet1Opts := &terraform.Options{

        // The path to where our Terraform code is located
        TerraformDir: "../examples/vnet-peering/vnet1",

        // Variables to pass to our Terraform code using -var options
        Vars: map[string]interface{}{
            "system":             vnet1Sysname,
            "location":           azureRegion,
            "vnet_address_space": vnet1Address,
            "subnet_prefix":      vnet1SubnetPrefix,
        },
    }

    // Deploy VNet1
    defer terraform.Destroy(t, vnet1Opts)
    terraform.InitAndApply(t, vnet1Opts)
    vnetOutRG := terraform.Output(t, vnet1Opts, "vnet_rg")
    vnetOutName := terraform.Output(t, vnet1Opts, "vnet_name")

    vnet2Opts := &terraform.Options{

        // The path to where our Terraform code is located
        TerraformDir: "../examples/vnet-peering/vnet2",

        // Variables to pass to our Terraform code using -var options
        Vars: map[string]interface{}{
            "system":             vnet2Sysname,
            "location":           azureRegion,
            "vnet_address_space": vnet2Address,
            "subnet_prefix":      vnet2SubnetPrefix,
            "peer_vnet_rg":       vnetOutRG,
            "peer_vnet_name":     vnetOutName,
        },
    }

    // Deploy VNet2
    defer terraform.Destroy(t, vnet2Opts)
    terraform.InitAndApply(t, vnet2Opts)

    // Collect RG and Virtual Network name from VNet2 Output
    vnet2RG := terraform.Output(t, vnet2Opts, "vnet_rg")
    vnet2Name := terraform.Output(t, vnet2Opts, "vnet_name")

    // Look up Virtual Network 2 by Name
    vnet2Properties := azure.GetVnetbyName(t, vnet2RG, vnet2Name, "")

    //Check if VNet Peering in VNet2 Provisioned Successfully
    for _, vnet := range *vnet2Properties.VirtualNetworkPeerings {
        assert.Equal(t, "Succeeded", string(vnet.VirtualNetworkPeeringPropertiesFormat.ProvisioningState), "Check if Peerings provisioned successfully")
    }
}

Now, let's run our integration test. No need to download the dependencies because we downloaded them already when we ran the unit test. Run the following command in the terminal specifying the terraform_azure_network_peering_test.go file:

go test -v terraform_azure_network_peering_test.go

We should see both virtual networks get deployed, followed by our test to verify the peering state between them. Then a terraform destroy is ran to tear down our test infrastructure. At the end we should see that our test has passed:

TestTerraformAzureNetworkingPeeringExample 2020-05-10T13:22:40Z command.go:168: azurerm_resource_group.rg: Destruction complete after 48s
TestTerraformAzureNetworkingPeeringExample 2020-05-10T13:22:41Z command.go:168: 
TestTerraformAzureNetworkingPeeringExample 2020-05-10T13:22:41Z command.go:168: Destroy complete! Resources: 7 destroyed.
--- PASS: TestTerraformAzureNetworkingPeeringExample (347.89s)
PASS
ok      command-line-arguments  347.890s

For an extra challenge, we could run both tests at the same time using the following command. Because we have t.Parallel() in our test functions, each test can be run in parallel. This is incredibly powerful because we can test our modules in several different ways at the same time:

Note: In a typical continuous integration pipeline for our module, we would ideally be running all tests in our test folder at the same time when we commit our changes to the module repo. This allows us to get a full amount of test coverage against our module.

go test -v

In the next step we go over how to perform end to end testing.

Step 6 — End-to-End Testing

End-to-end testing involves standing up the entire application composed of multiple modules. This can take hours, depending on how big the application is, which can make it incredibly time-consuming to run end-to-end tests. If the application takes a significant amount of time to deploy, it is recommended to deploy a copy of the entire application in a separate test environment and keep it deployed for a specific amount of time. Then, when we make a change to any of the modules in the application, we can re-deploy that module out to the application and then test the application functionality as a whole with automated tests.

Conclusion

As you can see, writing tests can take a bit of work. Because IaC is such a newly adopted concept, the tooling and concepts for writing tests can be awkward and complex. However, the rewards are worth it. A module with thorough tests will have much more stability and provides greater confidence when teams are executing that code.

Infrastructure code typically "rots" quickly. There are constantly new updates made to Azure, Terraform providers, and Terraform itself, which can make it a full-time task to ensure modules are always working as they should. To help with this, consider scheduling tests to run nightly to catch these types of bugs as early as possible.

It is strongly encouraged to run your tests in an Azure subscription separate from production and even development. When developing and testing modules, there is always a risk of destroying other resources. Also, this allows for safely configuring automated cleanup on the testing subscription to ensure any tests that bombed-out arent leaving remnants of infrastructure.

There is also the concept of test-driven development (TDD), which is a software development practice where tests are written first before the code is written. This is not very common in the infrastructure development world yet because of its infancy stage. However, IaC veterans like Kief Morris are huge advocates for TDD and describe that performing TDD for infrastructure code drives better design as it requires one to think through the outcome and function of their infrastructure when developing.

Tests for infrastructure code are critical to the stability of the infrastructure. Jacob Kaplan-Moss, software developer and co-creator of Django said it best, "Code without tests is broken as designed". Writing tests for IaC can be time-consuming and difficult because of the immaturity of the tooling; however, it is an essential piece of infrastructure development that shouldn't be overlooked.

In the next article, we will complete out this series by reviewing best practices when using Terraform.

Forem: CloudSkills.io

The Beginners Guide to Running Docker Containers on AWS

AWS Quick Tip: Working with EC2 and IAM Roles

AKS Virtual Nodes with Chad Crowell

Packer and Terraform with Immutable Infrastructure

Learning Application Security with Tanya Janca

Azure Automation: Managing Runbook Authentication and Modules

Prerequisites

Azure Automation Run As Account

Automation Account Modules

Connect to Azure from PowerShell Runbook

Managing Runbook Authentication without Run As Accounts

Create the Run As Account

Create a Service Principal

Create a New Connection Asset

Create a Credentials Asset

Conclusion

Azure Automation: Creating a PowerShell Runbook

Prerequisites

Create an Azure Automation Account

Create a PowerShell Runbook

Execute the Runbook

Add Warning and Error Output

Enhance Runbook Execution with Parameters

Creating a Variable Asset

Conclusion

Windows Virtual Desktop with Travis Roberts

AWS for Azure Pros: The Ultimate AWS to Azure Service Comparison

Cloud Career Tips & Strategy for 2021

Getting Started with Terraform on Azure: Tips and Tricks

Table Of Contents

Modules

Version Providers and Modules

Use Dependency Injections

Remote State

Split Up Terraform States

Source Control

Structure Repo to Business Needs

Keep All Live Infrastructure in the Master Branch

Execute Terraform Code Through a Pipeline

Keeping Designs Simple and Reusable

Use Provisioners Sparingly

Use Terraform Graph to Troubleshoot Dependency Issues

Use the Terraform Registry

Conclusion

Getting Started with Terraform on Azure: Testing

Table Of Contents

Prerequisites

Step 1 — Module Repo Folder Structure

Step 2 — Types of Testing

Step 3 — Static Analysis

Step 4— Unit Testing

Base Setup

Configure Terraform Options

Add In The Tests

Step 5 — Integration Testing

Base Test

Add in Terraform Options

Add In The tests

Step 6 — End-to-End Testing

Conclusion