For our current project our client has a production Sitecore environment and DR environment which are almost identical. Production is always up and running, however DR is spun-up on demand, in a secondary region, when the production region goes down for any reason. The only difference between the two environments is the data: the SQL servers are using Azure's
active geo-replication and failover groups so that the secondary region's data is
always up and ready to go, and to fails over automatically. This is more costly, but enables us to meet the client's RPO and RTO (as opposed to the backup and restore method), and specify the
grace period with data loss if the RTO isn't going to be met.
As a side-note, the secondary SQL servers, DBs, and failover groups are located in the primary resource group, not the DR resource group. This is so that the DR resource group can simply be deleted when the primary region comes back on-line. Don't forget point 1 of resource groups: the resources inside should share the same lifecycle.
But moving on to the topic of the title: the DR environment is identical to prod
minus the SQL servers and databases. There's no point scripting up two ARM templates when things are this similar, and fortunately Azure has us covered with
ARM template conditions. This is the best use for them that I've found so far, but you could also use it for any other environments/deployments which are quite similar.
First, in the Powershell script (we're using a modified version of the Sitecore Azure toolkit's
Sitecore.Cloud.Cmdlets.psm1 Start-SitecoreAzureDeployment function), we dynamically set the template property based on a flag:
if($IsDR) {
$paramJson | Add-Member -NotePropertyName "Environment" -NotePropertyValue @{ "value" = "DR" } -Force
}
Then in the template we add our Environment property:
"Environment": {
"type": "string",
"allowedValues": [
"Prod",
"DR"
],
"defaultValue": "Prod",
"metadata": {
"description": "Select whether this environment is prod (requires SQL) or DR (no SQL required)."
}
}
Finally, in the resource itself we add the condition to only create SQL servers if it's not DR:
{
"condition": "[not(equals(parameters('Environment'), 'DR'))]",
"type": "Microsoft.Sql/servers",
"name": "[variables('dbServerNameTidy')]",
... etc.
}
You can also use the conditions in your properties, which is required in the DR deployment to get the old FQDN of the original prod SQL servers.
"sqlServerFqdn": "[reference(if(equals(parameters('Environment'), 'DR'), resourceId(parameters('prodResourceGroup'), 'Microsoft.Sql/servers', variables('oldDbServerNameTidy')), resourceId('Microsoft.Sql/servers', variables('dbServerNameTidy'))), variables('dbApiVersion')).fullyQualifiedDomainName]",
Easy as that! Now you have one ARM template which can be used for both environments, just by passing the
-IsDr parameter to your powershell deployment script.
You could easily modify the Environment parameter to contain more values for different environments if you have more which are similar. However if they're more than a little different it's probably worth having a different nested template, or entire set of templates, for each environment.
