Deploy vMX in Azure via Bicep

JimmyPhelan
Getting noticed

Deploy vMX in Azure via Bicep

Hello There,

 

Has anyone successfully deployed a vMX in Azure using some form of automation from DevOps? I am examining how to achieve this using Bicep and the Dashboard API. Currently I am at a point where I have manually deployed a vMX to grab the ARM Template, ive converted this as much as possible to Bicep, and I am placing a deployment script in the Bicep in order to go to the Meraki API and retrieve the Authentication Token.

 

Why would I do this? It is a requirement from a client that all changes to their Azure Environment originate from DevOps and they want to use Bicep to achieve this.

 

Anyone run into any major challenges or issues?

1 Reply 1
Dantrac
New here

Hi @JimmyPhelan - bit late to the party, but someone might benefit!  I achieved an automated deployment from Azure Devops using terraform that looked a bit like this:

resource "azurerm_managed_application" "vmx" {
  name                        = var.application_resource_name
  location                    = var.location
  resource_group_name         = data.azurerm_resource_group.vnet.name
  kind                        = "MarketPlace"
  managed_resource_group_name = var.managed_resource_group_name

  plan {
    name      = "cisco-meraki-vmx"
    product   = "cisco-meraki-vmx"
    publisher = "cisco"
    version   = "18.2.11"
  }

  parameter_values = jsonencode({
    lan                         = { value = var.lan }
    location                    = { value = var.location }
    vmName                      = { value = var.vm_name }
    merakiAuthToken             = { value = data.azurerm_key_vault_secret.auth_token.value }
    zone                        = { value = var.zone }
    virtualNetworkName          = { value = var.virtual_network_name }
    virtualNetworkNewOrExisting = { value = var.virtual_network_new_or_existing }
    virtualNetworkAddressPrefix = { value = var.virtual_network_address_prefix }
    virtualNetworkResourceGroup = { value = data.azurerm_resource_group.vnet.name }
    virtualMachineSize          = { value = var.virtual_machine_size }
    subnetName                  = { value = var.subnet_name }
    subnetAddressPrefix         = { value = var.subnet_address_prefix }
    adminUsername               = { value = var.admin_username }
  })

  lifecycle {
    ignore_changes = [parameter_values]
  }
}

 

The benefit being that we can redeploy to another Availability Zone within a few mins in the event of a vMX or AZ failure...

Get notified when there are additional replies to this discussion.