Skip to main content

5 posts tagged with "azure"

View All Tags

· 3 min read
Jeffrey Aven

The Azure Static Web App feature is relatively new in the Azure estate which has recently become generally available, I thought I would take it for a test drive and discuss my findings.

I am a proponent of the JAMStack architecture for front end applications and a user of CD enabled CDN services like Netlify, so this Azure feature was naturally appealing to me.

Azure SWAs allow you to serve static assets (like JavaScript) without a origin server, meaning you don’t need a web server, are able to streamline content distribution and web app performance, and reduce the attack surface area of your application.

The major advantage to using is simplicity, no scaffolding or infra requirements and it is seamlessly integrated into your CI/CD processes (natively if you are using GitHub).

Deploying Static Web Apps in Azure#

Pretty simple to setup, aside from a name and a resource group, you just need to supply:

  • a location (Azure region to be used for serverless back end APIs via Azure Function Apps) note that this is not a location where the static web is necessarily running
  • a GitHub or GitLab repo URL
  • the branch you wish to use to trigger production deployments (e.g. main)
  • a path to your code within your app (e.g. where your package.json file is located)
  • an output folder (e.g. dist) this should not exist in your repo
  • a project or personal access token for your GitHub account (alternatively you can perform an interactive OAuth2.0 consent if using the portal)

An example is shown here:

GitHub Actions#

Using the consent provided (either using the OAuth flow or by providing a token), Azure Static Web Apps will automagically create the GitHub Actions workflow to deploy your application on a push or merge event to your repo. This includes providing scoped API credentials to Azure to allow access to the Static Web App resource using secrets in GitHub (which are created automagically as well). An example workflow is shown here:

Preview or Staging Releases#

Similar to the functionality in analogous services like Netlify, you can configure preview releases of your application to be deployed from specified branches on pull request events.

Routes and Authorization#

Routes (for SPAs) need to be provided to Azure by using a file named staticwebapp.config.json located in the application root of your repo (same level as you package.json file). You can also specify response codes and whether the rout requires authentication as shown here:


  • Globally distributed CDN
  • Increased security posture, reduced attack surface area
  • Simplified architecture and deployment
  • No App Service Plan required – cost reduction
  • Enables Continuous Deployment – incl preview/staging environments
  • TLS and DNS can be easily configured for your app


  • Serverless API locations are limited
  • Integration with other VCS/CI/CD systems like GitLab would need to be custom built (GitHub and Azure DevOps is integrated)

Overall, this is a good feature for deploying SPAs or PWAs in Azure.

· 2 min read
Jeffrey Aven

Function Apps, Logic Apps and App Services can be used to expose APIs within Azure API Management which is an easy way to deploy serverless microservices. You can see this capability in the Azure portal below within API Management:

Add a new API using a Function App as a back end

Like most readers, I like to script everything, so I was initially frustrated when I couldn’t replicate this operation in the Azure cli, REST, PowerShell, or any of the other SDKs or IaC tools. Others shared my frustration as seen here.

I was nearly resigned to using click ops in the portal (arrrgh) before I worked out this workaround.

The Solution#

There is a bit more prep work required to automate this process, but it is well worth it.

  1. Create an OpenApi (or Swagger spec or WADL) specification document, as seen below (use the absolute URL for your Function App in the url parameter):
  1. Use the az apim api import function (not the az apim api create function), as shown here:
  1. Associate the API with a product (which is how you can rate limit APIs)

That’s it! You can now access your function via the API gateway using the gateway url or via the developer portal as seen below:

Function App API in API Management in the Azure Portal

Function App API in the Dev Portal

· One min read
Jeffrey Aven

Following on from the recent post GCP Templates for C4 Diagrams using PlantUML, cloud architects are often challenged with producing diagrams for architectures spanning multiple cloud providers, particularly as you elevate to enterprise level diagrams.

In this post, with the magic of !includeurl we have brought PlantUML template libraries together for AWS, Azure and GCP icon sets, allowing us to produce multi cloud C4 diagrams using PlantUML like this one:

Multi Cloud Architecture Diagram using PlantUML

Creating a multi cloud diagram is simple, start by adding the following include statements after the @startuml label in a new PlantUML C4 diagram:

Then add references to the required services from different providers…

Then include the predefined resources from your different cloud providers in your diagram as shown here (describing a client server application over a cloud to cloud VPN between Azure and GCP)...

Happy multi-cloud diagramming!

Full source code is available at:

· 12 min read
Jeffrey Aven

This article demonstrates creating a site to site IPSEC VPN connection between a GCP VPC network and an Azure Virtual Network, enabling private RFC1918 network connectivity between virtual networks in both clouds. This is done using a single PowerShell script leveraging Azure PowerShell and gcloud commands in the Google SDK.

Additionally, we will use Azure Private DNS to enable private access between Azure hosts and GCP APIs (such as Cloud Storage or Big Query).

An overview of the solution is provided here:

Azure to GCP VPN Design

One note before starting - site to site VPN connections between GCP and Azure currently do not support dynamic routing using BGP, however creating some simple routes on either end of the connection will be enough to get going.

Let’s go through this step by step:

Step 1 : Authenticate to Azure#

Azure’s account equivalent is a subscription, the following command from Azure Powershell is used to authenticate a user to one or more subscriptions.


This command will open a browser window prompting you for Microsoft credentials, once authenticated you will be returned to the command line.

Step 2 : Create a Resource Group (Azure)#

A resource group is roughly equivalent to a project in GCP. You will need to supply a Location (equivalent to a GCP region):

New-AzResourceGroup `  -Name "azure-to-gcp" `  -Location "Australia Southeast"

Step 3 : Create a Virtual Network with Subnets and Routes (Azure)#

An Azure Virtual Network is the equivalent of a VPC network in GCP (or AWS), you must define subnets before creating a Virtual Network. In this example we will create two subnets, one Gateway subnet (which needs to be named accordingly) where the VPN gateway will reside, and one subnet named ‘default’ where we will host VMs which will connect to GCP services over the private VPN connection.

Before defining the default subnet we must create and attach a Route Table (equivalent of a Route in GCP), this particular route will be used to route ‘private’ requests to services in GCP (such as Big Query).

# define route table and route to GCP private access$azroutecfg = New-AzRouteConfig `  -Name "google-private" `  -AddressPrefix "" `  -NextHopType "VirtualNetworkGateway" 
$azrttbl = New-AzRouteTable `  -ResourceGroupName "azure-to-gcp" `  -Name "google-private" `  -Location "Australia Southeast" `  -Route $azroutecfg
# define gateway subnet$gatewaySubnet = New-AzVirtualNetworkSubnetConfig  `  -Name "GatewaySubnet" `  -AddressPrefix ""
# define default subnet$defaultSubnet  = New-AzVirtualNetworkSubnetConfig `  -Name "default" `  -AddressPrefix "" `  -RouteTable $azrttbl
# create virtual network and subnets$vnet = New-AzVirtualNetwork  `  -Name "azure-to-gcp-vnet" `  -ResourceGroupName "azure-to-gcp" `  -Location "Australia Southeast" `  -AddressPrefix "" `  -Subnet $gatewaySubnet,$defaultSubnet

Step 4 : Create Network Security Groups (Azure)#

Network Security Groups in Azure are stateful firewalls much like Firewall Rules in VPC networks in GCP. Like GCP, the lower priority overrides higher priority rules.

In the example we will create several rules to allow inbound ICMP, TCP and UDP traffic from our Google VPC and RDP traffic from the Internet (which we will use to logon to a VM in Azure to test private connectivity between the two clouds):

# create network security group$rule1 = New-AzNetworkSecurityRuleConfig `  -Name rdp-rule `  -Description "Allow RDP" `  -Access Allow `  -Protocol Tcp `  -Direction Inbound `  -Priority 100 `  -SourceAddressPrefix Internet `  -SourcePortRange * `  -DestinationAddressPrefix * `  -DestinationPortRange 3389
$rule2 = New-AzNetworkSecurityRuleConfig `  -Name icmp-rule `  -Description "Allow ICMP" `  -Access Allow `  -Protocol Icmp `  -Direction Inbound `  -Priority 101 `  -SourceAddressPrefix * `  -SourcePortRange * `  -DestinationAddressPrefix * `  -DestinationPortRange *
$rule3 = New-AzNetworkSecurityRuleConfig `  -Name gcp-rule `  -Description "Allow GCP" `  -Access Allow `  -Protocol Tcp `  -Direction Inbound `  -Priority 102 `  -SourceAddressPrefix "" `  -SourcePortRange * `  -DestinationAddressPrefix * `  -DestinationPortRange *
$nsg = New-AzNetworkSecurityGroup `  -ResourceGroupName "azure-to-gcp" `  -Location "Australia Southeast" `  -Name "nsg-vm" `  -SecurityRules $rule1,$rule2,$rule3

Step 5 : Create Public IP Addresses (Azure)#

We need to create two Public IP Address (equivalent of an External IP in GCP) which will be used for our VPN gateway and for the VM we will create:

# create public IP address for VM$vmpip = New-AzPublicIpAddress `  -Name "vm-ip" `  -ResourceGroupName "azure-to-gcp" `  -Location "Australia Southeast" `  -AllocationMethod Dynamic
# create public IP address for NW gateway $ngwpip = New-AzPublicIpAddress `  -Name "ngw-ip" `  -ResourceGroupName "azure-to-gcp" `  -Location "Australia Southeast" `  -AllocationMethod Dynamic

Step 6 : Create Virtual Network Gateway (Azure)#

The Virtual Network Gateway in Azure is the VPN Gateway equivalent in Azure which will be used to create a VPN tunnel between Azure and a GCP VPN Gateway. This gateway will be placed in the Gateway subnet created previously and one of the Public IP addresses created in the previous step will be assigned to this gateway.

# create virtual network gateway$ngwipconfig = New-AzVirtualNetworkGatewayIpConfig `  -Name "ngw-ipconfig" `  -SubnetId $gatewaySubnet.Id `  -PublicIpAddressId $ngwpip.Id
# use the AsJob switch as this is a long running process$job = New-AzVirtualNetworkGateway -Name "vnet-gateway" `  -ResourceGroupName "azure-to-gcp" `  -Location "Australia Southeast" `  -IpConfigurations $ngwipconfig `  -GatewayType "Vpn" `  -VpnType "RouteBased" `  -GatewaySku "VpnGw1" `  -VpnGatewayGeneration "Generation1" `  -AsJob
$vnetgw = Get-AzVirtualNetworkGateway `  -Name "vnet-gateway" `  -ResourceGroupName "azure-to-gcp"

Step 7 : Create a VPC Network and Subnetwork(s) (GCP)#

A VPC network and subnet need to be created in GCP, the subnet defines the VPC address space. This address space must not overlap with the Azure Virtual Network CIDR. For all GCP steps it is assumed that the project is set for client config (e.g. gcloud config set project your_project) so it does not need to be specified for each operation. Private Google access should be enabled on all subnets created.

# creating VPC network and subnetsgcloud compute networks create "azure-to-gcp-vpc" `  --subnet-mode=custom `  --bgp-routing-mode=regional
gcloud compute networks subnets create "aus-subnet" `  --network  "azure-to-gcp-vpc" `  --range "" `  --region "australia-southeast1" `  --enable-private-ip-google-access

Step 8 : Create an External IP (GCP)#

An external IP address will need to be created in GCP which will be used for the external facing interface of the VPN Gateway.

# create external IPgcloud compute addresses create "ext-gw-ip" `  --region "australia-southeast1"
$gcp_ipaddr_obj = gcloud compute addresses describe "ext-gw-ip" `  --region "australia-southeast1" `  --format json | ConvertFrom-Json
$gcp_ipaddr = $gcp_ipaddr_obj.address

Step 9 : Create Firewall Rules (GCP)#

VPC firewall rules will need to be created in GCP to allow VPN traffic as well as SSH traffic from the internet (which allows you to SSH into VM instances using Cloud Shell).

# create VPN firewall rulesgcloud compute firewall-rules create "vpn-rule1" `  --network "azure-to-gcp-vpc" `  --allow tcp,udp,icmp `  --source-ranges ""
gcloud compute firewall-rules create "ssh-rule1" `  --network "azure-to-gcp-vpc" `  --allow tcp:22

Step 10 : Create VPN Gateway and Forwarding Rules (GCP)#

Create a VPN Gateway and Forwarding Rules in GCP which will be used to create a tunnel between GCP and Azure.

# create cloud VPN gcloud compute target-vpn-gateways create "vpn-gw" `  --network "azure-to-gcp-vpc" `  --region "australia-southeast1" `  --project "azure-to-gcp-project"
# create forwarding rule ESPgcloud compute forwarding-rules create "fr-gw-name-esp" `  --ip-protocol ESP `  --address "ext-gw-ip" `  --target-vpn-gateway "vpn-gw" `  --region "australia-southeast1" `  --project "azure-to-gcp-project"
# creating forwarding rule UDP500gcloud compute forwarding-rules create "fr-gw-name-udp500" `  --ip-protocol UDP `  --ports 500 `  --address "ext-gw-ip" `  --target-vpn-gateway "vpn-gw" `  --region "australia-southeast1" `  --project "azure-to-gcp-project"
# creating forwarding rule UDP4500gcloud compute forwarding-rules create "fr-gw-name-udp4500" `  --ip-protocol UDP `  --ports 4500 `  --address "ext-gw-ip" `  --target-vpn-gateway "vpn-gw" `  --region "australia-southeast1" `  --project "azure-to-gcp-project"

Step 10 : Create VPN Tunnel (GCP Side)#

Now we will create the GCP side of our VPN tunnel using the Public IP Address of the Azure Virtual Network Gateway created in a previous step. As this example uses a route based VPN the traffic selector values need to be set at A PSK (Pre Shared Key) needs to be supplied which will be the same key used when we configure a VPN Connection on the Azure side of the tunnel.

# get peer public IP address of Azure gateway$azpubip = Get-AzPublicIpAddress `  -Name "ngw-ip" `  -ResourceGroupName "azure-to-gcp"
# create VPN tunnel gcloud compute vpn-tunnels create "vpn-tunnel-to-azure" `  --peer-address $azpubip.IpAddress `  --local-traffic-selector "" `  --remote-traffic-selector "" `  --ike-version 2 `  --shared-secret << Pre-Shared Key >> `  --target-vpn-gateway "vpn-gw" `  --region  "australia-southeast1" `  --project "azure-to-gcp-project"

Step 11 : Create Static Routes (GCP Side)#

As we are using static routing (as opposed to dynamic routing) we will need to define all of the specific routes on the GCP side. We will need to setup routes for both outgoing traffic to the Azure network as well as incoming traffic for the restricted Google API range (

# create static route (VPN)gcloud compute routes create "route-to-azure" `  --destination-range "" `  --next-hop-vpn-tunnel "vpn-tunnel-to-azure" `  --network "azure-to-gcp-vpc" `  --next-hop-vpn-tunnel-region "australia-southeast1" `  --project "azure-to-gcp-project"
# create static route (Restricted APIs)gcloud compute routes create apis `  --network  "azure-to-gcp-vpc" `  --destination-range "" `  --next-hop-gateway default-internet-gateway `  --project "azure-to-gcp-project"

Step 12 : Create a Local Gateway (Azure)#

A Local Gateway in Azure is an object that represents the remote gateway (GCP VPN gateway).

# create local gateway$azlocalgw = New-AzLocalNetworkGateway `  -Name "local-gateway" `  -ResourceGroupName "azure-to-gcp" `  -Location "Australia Southeast" `  -GatewayIpAddress $gcp_ipaddr `  -AddressPrefix ""

Step 13 : Create a VPN Connection (Azure)#

Now we can setup the Azure side of the VPN Connection which is accomplished by associating the Azure Virtual Network Gateway with the Local Network Gateway. A PSK (Pre Shared Key) needs to be supplied which is the same key used for the GCP VPN Tunnel in step 10.

# create connection$azvpnconn = New-AzVirtualNetworkGatewayConnection `  -Name "vpn-connection" `  -ResourceGroupName "azure-to-gcp" `  -VirtualNetworkGateway1 $vnetgw `  -LocalNetworkGateway2 $azlocalgw `  -Location "Australia Southeast" `  -ConnectionType IPsec `  -SharedKey  << Pre-Shared Key >>  `  -ConnectionProtocol "IKEv2"

VPN Tunnel Established!

At this stage we have created an end to end connection between the virtual networks in both clouds. You should see this reflected in the respective consoles in each provider.

GCP VPN Tunnel to a Azure Virtual Network
GCP VPN Tunnel to a Azure Virtual Network
Azure VPN Connection to a GCP VPC Network
Azure VPN Connection to a GCP VPC Network

Congratulations! You have just setup a multi cloud environment using private networking. Now let’s setup Google Private Access for Azure hosts and create VMs on each side to test our setup.

Step 14 : Create a Private DNS Zone for (Azure)#

We will now need to create a Private DNS zone in Azure for the domain which will host records to redirect Google API requests to the Restricted API range.

# create private DNS zoneNew-AzPrivateDnsZone `  -ResourceGroupName "azure-to-gcp" `  -Name ""
# Add A Records   $Records = @()$Records += New-AzPrivateDnsRecordConfig `  -IPv4Address$Records += New-AzPrivateDnsRecordConfig `  -IPv4Address$Records += New-AzPrivateDnsRecordConfig `  -IPv4Address$Records += New-AzPrivateDnsRecordConfig `  -IPv4Address
New-AzPrivateDnsRecordSet `  -Name "restricted" `  -RecordType A `  -ResourceGroupName "azure-to-gcp" `  -TTL 300 `  -ZoneName "" `  -PrivateDnsRecords $Records
# Add CNAME Records   $Records = @()$Records += New-AzPrivateDnsRecordConfig `  -Cname ""
New-AzPrivateDnsRecordSet `  -Name "*" `  -RecordType CNAME `  -ResourceGroupName "azure-to-gcp" `  -TTL 300 `  -ZoneName "" `  -PrivateDnsRecords $Records
# Create VNet LinkNew-AzPrivateDnsVirtualNetworkLink `  -ResourceGroupName "azure-to-gcp" `  -ZoneName "" `  -Name "dns-zone-link" `  -VirtualNetworkId $vnet.Id

Step 15 : Create a Virtual Machine (Azure)#

We will create a VM in Azure which we can use to test the VPN tunnel as well as to test Private Google Access over our VPN tunnel.

# create VM$az_vmlocaladminpwd = ConvertTo-SecureString << Password Param >> `  -AsPlainText -Force$Credential = New-Object System.Management.Automation.PSCredential  ("LocalAdminUser", $az_vmlocaladminpwd);
$nic = New-AzNetworkInterface `  -Name "vm-nic" `  -ResourceGroupName "azure-to-gcp" `  -Location "Australia Southeast" `  -SubnetId $defaultSubnet.Id `  -NetworkSecurityGroupId $nsg.Id `  -PublicIpAddressId $vmpip.Id `  -EnableAcceleratedNetworking `  -Force
$VirtualMachine = New-AzVMConfig `  -VMName "windows-desktop" `  -VMSize "Standard_D4_v3"
$VirtualMachine = Set-AzVMOperatingSystem `  -VM $VirtualMachine `  -Windows `  -ComputerName  "windows-desktop" `  -Credential $Credential `  -ProvisionVMAgent `  -EnableAutoUpdate
$VirtualMachine = Add-AzVMNetworkInterface `  -VM $VirtualMachine `  -Id $nic.Id
$VirtualMachine = Set-AzVMSourceImage `  -VM $VirtualMachine `  -PublisherName 'MicrosoftWindowsDesktop' `  -Offer 'Windows-10' `  -Skus 'rs5-pro' `  -Version latest
New-AzVM `  -ResourceGroupName "azure-to-gcp" `  -Location "Australia Southeast" `  -VM $VirtualMachine `  -Verbose

Step 16 : Create a VM Instance (GCP)#

We will create a Linux VM in GCP to test connectivity to hosts in Azure using the VPN tunnel we have established.

# create VM instancegcloud compute instances create "gcp-instance" `  --zone "australia-southeast1-b" `  --machine-type "f1-micro" `  --subnet "aus-subnet" `  --network-tier PREMIUM `  --maintenance-policy MIGRATE `  --image=debian-9-stretch-v20200309 `  --image-project=debian-cloud `  --boot-disk-size 10GB `  --boot-disk-type pd-standard `  --boot-disk-device-name instance-1 `  --reservation-affinity any

Test Connectivity#

Now we are ready to test connectivity from both sides of the tunnel.

Azure to GCP#

Establish a remote desktop (RDP) connection to the Azure VM created in Step 15. Ping the GCP VM instance using its private IP address.

Test Private IP Connectivity from Azure to GCP

GCP to Azure#

Now SSH into the GCP Linux VM instance and ping the Azure host using its private IP address.

Test Private IP Connectivity from GCP to Azure

Test Private Google Access from Azure#

Now that we have established bi-directional connectivity between the two clouds, we can test private access to Google APIs from our Azure host. Follow the steps below to test private access:

  1. RDP into the Azure VM
  2. Install the Google Cloud SDK (
  3. Perform an nslookup to ensure that calls to resolve to the restricted API range (e.g. nslookup You should see a response showing the A records from the Private DNS Zone created in step 14.
  4. Now test connectivity to Google APIs, for example to test access to Google Cloud Storage using gsutil, or test access to Big Query using the bq command

Congratulations! You are now a multi cloud ninja!

· 5 min read
Chris Ottinger

A few years back, before the rise of the hyper-scalers, I had my first infracode 'aha moment' with OpenStack. The second came with Kitchen.

I had already been using test driven development for application code and configuration automation for infrastructure but Kitchen brought the two together. Kitchen made it possible to write tests, spin up infrastructure, and then tear everything down again - the Red/Green/Refactor cycle for infrastructure. What made this even better was that it wasn't a facsimile of a target environment, it was the same - same VM's, same OS, same network.

Coming from a Chef background for configuration automation, Kitchen is a great fit to the Ruby ecosystem. Kitchen works with Ansible and Azure, but a Ruby environment and at least a smattering of Ruby coding skills are required.

Molecule provides a similar red-green development cycle to Kitchen, but without the need to step outside of the familiar Python environment.

Out of the box, Molecule supports development of Ansible roles using either a Docker or Virtual Box infrastructure provider. Molecule also leverages the Ansible drivers for private and public cloud platforms.

Molecule can be configured to test an individual role or collections of roles in Ansible playbooks.

This tutorial demonstrates how to use Molecule with Azure to develop and test an individual Ansible role following the red/green/refactor infracode workflow, which can be generalised as:

  • Red- write a failing infrastructure test
  • Green - write the Ansible tasks needed to pass the test
  • Refactor - repeat the process

The steps required for this tutorial are as follows:

Azure setup#

Ensure there is an existing Azure Resource Group that will be used for infracode development and testing. Within the resource group, ensure there is a single virtual network (vnet) with a single subnet. Ansible will use these for the default network setup.

Setup a working environment#

There are a number of options for setting up a Python environment for Ansible and Molecule, including Python virtualenv or a Docker container environment.

Create a Docker image for Ansible+Molecule+Azure#

This tutorial uses a Docker container environment. A Dockerfile for the image can be found in ./molecule-azure-image/Dockerfile. The image sets up a sane Python3 environment with Ansible, Ansible[azure], and Molecule pip modules installed.

Create a Docker workspace#

Setup a working environment using the Docker image with Ansible, Molecule, and the azure-cli installed.

This example assumes the following:

  • a resource group already exists with access rights to create virtual machines; and
  • the resource group contains a single vnet with a single subnet

Log into an Azure subcription#

Ansible supports a number of different methods for authenticating with Azure. This example uses the azure-cli to login interactively.

Create an empty Ansible role with Molecule#

Molecule provides an init function with defaults for various providers. The molecule-azure-role-template creates an empty role with scaffolding for Azure.

Check that the environment is working by running the following code:

The output should look be similar to…

Spin up an Azure VM#

Spin up a fresh VM to be used for infra-code development.

Molecule provides a handy option for logging into the new VM:

There is now a fresh Ubuntu 18.04 virtual machine ready for infra-code development. For this example, a basic Nginx server will be installed and verified.

Write a failing test#

Testinfra provides a pytest based framework for verifying server and infrastructure configuration. Molecule then manages the execution of those testinfra tests. The Molecule template provides a starting point for crafting tests of your own. For this tutorial, installation of the nginx service is verified. Modify the tests file using vi molecule/default/tests/

Execute the failing test#

The Ansible task needed to install and enable nginx has not yet been written, so the test should fail:

If the initial sample tests in are kept, then 3 tests should fail and 2 tests should pass.

Write a task to install nginx#

Add a task to install the nginx service using vi tasks/main.yml:

Apply the role#

Apply the role to the instance created using Molecule.

The nginx package should now be installed, both enabled and started, and listening on port 80. Note that the nginx instance will not be accessible from the Internet due to the Azure network security rules. The nginx instance can be confirmed manually by logging into the instance and using curl to make a request to the nginx service.

Execute the passing test#

After applying the Ansible task to the instance, the testinfra tests should now pass.


Now that the Ansible role works as defined in the test specification, the development environment can be cleaned up.

Molecule removes the Azure resources created to develop and test the configuration role. Note that deletion may take a few minutes.

Finally, once you are done, exit the container environment. If the container was started with the --rm switch, the container will also be removed, leaving you with a clean workspace and newly minted Ansible role with automated test cases.