In this series so far, we looked at building ARM templates by example. The focus was not really on the resource types or how to use resource definitions. Instead, our focus was on learning the basics of template language. To that extent, we have a scenario that we want to deploy and we are incrementally building the template for it. While building an ARM template for this, we looked at how to use parameters and variables. We looked at using copy object to create multiple instances of a resource type without really writing the resource definition multiple times. We went on to find out how we can define dependencies between different resource types so they are orchestrated in the right order. We looked at how we can decompose the template into purpose-specific external templates and how to link them together. While learning these concepts, we created a template that almost built the scenario we started with. We will now add the remaining VMs based on the environmentType selected by the user. So, based on the VM instance count we need, we …
One of the ARM template authoring best practices is to decompose the JSON template, if applicable, into multiple target-specific templates. Think of this as creating re-usable code. You can leverage the re-usable parts of your code within multiple aspects of your application or the deployment. For linking different external templates within the main template, we need to define the Microsoft.Resources/deployments resource instance. Before we proceed let us look at the scenario for which we are building an ARM template. So far in this series, we have looked at building an ARM template that deploys the following components of this scenario: A storage account A virtual network A public IP address A load balancer Virtual network interfaces for the DC and other VMs based on the environment type. Finally, a VM with DNS and Directory Services running in it. By default, the Azure based IaaS deployments use the Azure DNS. If you have deployed the template that we built in the previous part of this series, you will notice that the virtual network us configured to use Azure DNS. Since we …
I just released an update to my Hyper-V Networking DSC resource module (version 2.6 at present). This module contains six resources at the moment and I plan to add a few more in the near future. cVMSwitch is used to create virtual machine switches. cSwitchEmbeddedTeam is used to create switch embedded team VM switches on Server 2014 TP4 and above. cNatSwitch is used to deploy a VM switch of NAT type. cVMNetworkAdapter is used to create VM network adapters to attach to either management OS or the virtual machines. cVMNetworkAdapterSettings is used to configure VM network adapter settings such as bandwidth weights, port mirroring, DHCP guard, MAC address spoofing, etc. cVMNetworkAdapterVlan is used to configure VLANs on virtual network adapters either in the management OS or virtual machines. The cSwitchEmbeddedTeam and cNatSwitch resources are new in this release and are applicable only from Windows Server 2016 onwards. The cVMNetworkAdapter, cVMNetworkAdapterVlan, and cVMNetworkAdapterSettings modules have two breaking changes. There was no Id property earlier and the Name property was used as a key. This resulted in an issue where …
We will continue learning about building ARM templates by looking at how we can define dependencies between resources. To recap, here is the scenario we are working on. In the earlier parts of this series, we created the storage account, virtual network, a public IP, a load balancer, and added all inbound NAT rules required for the virtual machine RDP access. If you notice, we have components that depend on others. For example, the inbound NAT rules depend on the load balancer. Similarly, VMs depend on network interfaces which in turn depend on the virtual network. In the absence of dependencies, ARM will attempt to deploy these resources in parallel which may result in errors. So, within the resource template, we need to define these dependencies so that ARM can make decisions about the deployment sequence. There are multiple ways of doing this. Using DependsOn If you have noticed in the earlier parts of this series, we have used DependsOn property within the resource element.
"name": "[concat('/loadbalancer/','VM-', copyIndex(1),'-RDP')]",
"frontendPort": "[add(3389, copyIndex(1))]",
If you look at line number 11, we added DependsOn property …