As your Azure usage increased you will inevitably need to grant rights to other users to create and manage resources. Often you need to apply limits to what these user can do with their Azure subscription. Role Based Access Control allows you to put users into roles which grant them access to specific top level resources (virtual machines, storage, SQL etc.), what RBAC doesn’t do however is limit what you can do with those resources.
I previously wrote about using VS Code for authoring Azure Resource Manger templates, in particular about using the snippets from the cross platform toolkit to create skeletons for many ARM resources. In this post I documented the manual installation process for these snippets, as there was not a VS Code extension to install these automatically. This is no longer the case, I have recently published a VS Code extension that takes these snippets (with attribution) and packages them up and makes them available in the VS Code marketplace for easy installation and updating.
Azure Resource Manager (ARM) templates are a great resource for deploying Azure infrastructure, including virtual machines, in a declarative manner. However, using an ARM template to deploy a VM will only get you as far as having a VM deployed and the operating system installed and running. The next step is to get any applications and supporting software installed on those machines. Of course you can RDP to machine and do this manually, but this breaks down quickly if you have lots of machines or need to regularly deploy VM’s.
At this months Build conference there where lot’s of new Azure announcements and in particular lots of new features for Azure Resource Manager (ARM) templates. Ryan Jones. PM on ARM templates, did a breakout session talking about all this new functionality which is available now on channel 9. I want to focus on one of the big improvements, at least from perspective, and that is we now have proper conditional logic in ARM templates!
Last week at build Microsoft announced a preview of MYSQL and PostgreSQL databases as a PaaS service running in Azure. Since then, we’ve not yet seen full documentation of the ARM templates required to deploy these, however some example templates did appear on Github a few days ago that provide enough information to begin creating templates that use these two database services.
Both databases look to follow the same design, with just a variation in type name.
Microsoft have now added first class conditions to the language so this workaround is no longer required. See this article on how to use this feature.**
ARM Templates are a great tool for deploying complex sets of resources in Azure, however as it currently stands there is no concept of an “If” statement in a template. This can make it much more difficult to support the re-use of code and to avoid duplication in your templates, if you have to create a whole new set of templates which are 95% the same but with one section being different.
Resource Manager Locks provide a way for administrators to lock down Azure resources to prevent deletion or changing of a resource. These locks sit outside of the Role Based Access Controls (RBAC) hierarchy and when applied will place the restriction on the resource for all users. These are very useful when you have an important resource in your subscription which users should not be able to delete or change and can help prevent accidental and malicious changes or deletion.
Since writing this article I’ve released a VS Code Extension that installs these snippets with a single click, see here.
In my previous post on using VS Code for authoring ARM templates I recommended using an ARM Snippets from the plugin gallery. However since then I have come to realise this plugin is fairly limited in the amount of plugins, and difficult to extend. Given this I would now recommend utilising the set of snippets provided by the Azure Cross Platform Tooling Samples
If your writing ARM templates for Azure you’ll have found that the amount of tooling available for authoring templates is fairly limited. The default solution seems to be Visual Studio but this can be very heavyweight and resource intensive without gaining any of the real benefits of VS such as debugging. I’ve recently switched over from using Visual Studio to use Visual Studio Code, for a much more light weight experience.
Back in the days of cloud services every VM created got a set of default endpoints that let in traffic for RDP and Remoting on a random port, and if you wanted ingress on other ports you just created more endpoints. In the V2 world cloud services don’t exist, and endpoints are now primary configured as inbound NAT rules on a load balancer, with the default being no NAT rules. This is ultimately a much better and more secure way of doing it, however it did make it a pain when you needed to add one or more NAT rule for each VM in your deployment, especially when you had lots of VM’s.
