The next couple of blog posts will focus on a few changes we had to make to get the module running correctly for us and a few customizations we made.
Since we're located in Sydney, right off the bat the first thing we had to do was add the Australian datacenters to the XML.
In Website\App_Config\AzureVendors\Microsoft.xml
<datacenter name="Australia East">
<coordinates left="88%" top="81%" />
</datacenter>
<datacenter name="Australia Southeast">
<coordinates left="86%" top="84%" />
</datacenter>
We found later that we kept getting the error:
Validation Errors: Total requested resources are too large for the specified VM size. The long running operation tracking ID was: <our_id>
The XML is by default configured to use up the entire local storage resources space, and after contacting Azure support we were told that (due to a change in Azure) some space needed to be reserved for system use. They advised 5-10GB. For example for A3 (Large) which is initially marked as 800GB:
<size sortorder="3" value="Large" cores="4" siteStorageSize="790">A3: 4 cores / 7 GB RAM</size>
Finally, we found that the naming for the 'optimized compute' VMs (the D-series) were named incorrectly. To fix, the value attribute should start with "Standard_".
<size sortorder="12" value="Standard_D1" cores="1" siteStorageSize="20">D1: 1 core / 3.5 GB RAM</size>
<size sortorder="13" value="Standard_D2" cores="2" siteStorageSize="70">D2: 2 cores / 7 GB RAM</size>
<size sortorder="14" value="Standard_D3" cores="4" siteStorageSize="170">D3: 4 cores / 14 GB RAM</size>
... etc.
The Azure module is great to get up and running quickly, but certainly not the most efficient way of doing continuous deployment. If you're running multiple environments and doing more than a couple of deployments a week, it's certainly worth looking into a few of the alternatives or asking around on the forum.
No comments:
Post a Comment