Intro

I want to deploy some network services to my environment in this part of the blog series. I first need to update my peerings to use the VPN gateway. The VPN requires a slight change in both ends of the current peering. I also want to add an Azure Firewall, which means using route tables, and finally, I want to add network security groups to my subnets in the AVD virtual network. Below is a design diagram for this part of the series.

Intro

In this part of the blog series, I want to deploy a new virtual network for my Azure Virtual Desktop environment. I also want to create a network peering between the new network and the one I already deployed named vnet-connectivity-001.

Azure Virtual Desktop network

As I created a virtual network already in the blogs series, I will make a copy of the code for the network and adjust it to fit this new network I am creating. I will copy the three files I have in the “rg-connectivity-network-001” folder and paste them into a new folder called “rg-avd-network-001.”

Intro

In this part of the blog series, I want to deploy my VPN connection to my on-premises environment and the log analytics workspace.

Azure key vault

Before I can start with my VPN connection I need to create an Azure key vault to store my VPN shared secret. The variables file for my key vault is shown below.

variable "Location" {
    type                        = string
    default                     = "WestEurope"  
}

variable "ResourceGroup" {
    type                        = string
    default                     = "rg-keyvault-001"   
}

The main.tf file used for key vault is shown below. I will give my GitHub Action service principal permissions to get and list secrets from my key vault and also make sure that the key vault is enabled for deployments and template deployments.

Intro

In this part of the blog series, I want to focus on the GitHub Actions I created in the first part and explain what the Action performs. I will also add the vNet resources to my deployments.

GitHub Actions explained

To explain what is going on in the GitHub Action, I have added comments to each code section.

# Name of the action
name: rg-connectivity-001

# Controls when the workflow will run
on:
  # Triggers the workflow on changes to the terraform files in the path
  # Subscriptions/Sub-MVP-Sponsorship/rg-connectivity-001/
  # Action will only trigger on the main branch
  push:
    paths:
      - 'Subscriptions/Sub-MVP-Sponsorship/rg-connectivity-001/*.tf'
  branches:
      - main
  # Allows you to run this workflow manually from the Actions tab
  workflow_dispatch:

# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
  # This action only has one job called Connectivity
  Connectivity:
    # The type of runner that the job will run on
    runs-on: ubuntu-latest
        
    # Setting environment variables
    # Variables are used by Terraform to authenticate to Azure
    env:
      ARM_CLIENT_ID: ${{ secrets.AZURE_CLIENT_ID }}
      ARM_CLIENT_SECRET: ${{ secrets.AZURE_CLIENT_SECRET }}
      ARM_SUBSCRIPTION_ID: ${{ secrets.MVP_SUBSCRIPTION }}
      ARM_TENANT_ID: ${{ secrets.AZURE_TENANT_ID }}
      
    # Steps represent a sequence of tasks that will be executed as part of the job
    steps:
      # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
      - uses: actions/checkout@v3

      # Initialize Terraform
      - name: 'Terraform init'
        id: init
        run: |
          cd Subscriptions/Sub-MVP-Sponsorship/rg-connectivity-001
          terraform init

      # Create Terraform plan
      - name: 'Terraform plan'
        id: plan
        run: |
          cd Subscriptions/Sub-MVP-Sponsorship/rg-connectivity-001
          terraform plan
      
      # Deploy the planned resources to Azure using Terraform
      - name: 'Terraform apply'
        id: apply
        run: |
          cd Subscriptions/Sub-MVP-Sponsorship/rg-connectivity-001
          terraform apply -auto-approve

You might have noticed that I have added a few things to the actions since part 1, but please update your Actions with these changes if you haven’t. The main difference is adding the filter “braches: main,” the rest is cosmetic and only comments.

Intro

This blog series will create and maintain Azure resources using GitHub repositories, GitHub Actions, and Terraform. I will use this blog series to build out a new Azure tenant that I have created, and I thought I might share what I was doing along the way. If you have any questions about this blog series, please reach out to me.

The design I am working on right now is outlined below. I want to create a vNet with access to my home network, a vNet containing an Azure Virtual Desktop environment with a storage account that will have a private endpoint. I also have a log analytics workspace that will gather events from AVD, storage, and network.

Intro

One of the questions I have gotten from customers is, what happens if I run my deployment script of a VM multiple times? For instance, if the customer has a script that runs an ARM or Bicep template with multiple virtual machines, what will happen to the already running machine if they add a new one? Let us have a look at that in this blog post.

I have used the Microsoft documentation as a guideline for this blog post. You can find all the information on this Microsoft site.