For our hello world application to be deployed to a Azure VM we need to make sure it exists. We can of course do that bij going to the azure portal and provision a VM for each of our environment but that would be repetitive work and very high maintenance. Instead we are going to provision it by using Infrastructure as Code.
This kind of provisioning we don’t want to have in our CI build because it would take to long, the right place for this is in our release pipeline. When the environment exists its ok we can skip this step, but when it doesn’t exists we create one so we can deploy to it. We can manage this by the Azure Resource Manager which we can address by a .json file.
Add these files to your repository in a folder “Deploy”. To make sure it is copied to your artifact folder add a Copy Files task to your CI Build to copy the Deploy folder from your repository.
The machine created by the WindowsVirtualMachine.json is a “Standard_DS1_v2” it will take up to 15 minutes the first time it is created, when it already exists it’s left alone. When you have the resources you can change “vmSize”: “Standard_DS1_v2” into a higher tier machine which can be found on the portal.azure.com
- Resource group can be any name you prefer, when it doesn’t exists it will create it. Just keep it each environment in it’s own resource group. It’s easier to clean up later by deleting resource groups.
- Template should be pointing to the location of your vm.json
- Template parameters should be pointing to the location of your vm.parameters.json
- The template uses 3 parameters that needs to be overridden:
- adminUsername (username for the vm)
- adminPassword (you can guess that one, include Capitals, Numbers, Special Characters)
- dnsNameForPublicIp (just try abcmyspecialworkshopyourname)
As you probably noticed the parameters refer to environment variables, because you don’t want your password in clear text nor will you have to change your deployment step between each environment. To manage these variables you can go to your environment and press configure variables set your vmpassword to encripted.
Now the environment is provisioned we can use the “AzureVMs File Copy” to deploy our binaries to the VM
Make sure the RM Storage Account is in the same resource group as the VM you are deploying to. Otherwise you could end up with
[error]Failed to enable copy prerequisites. ExceptionMessage: The remote server returned an error: (409) Conflict. (in function: Remove-AzRmVmCustomScriptExtension)
Your RM Storage Account and ResourceGroup can be different then shown beneath. The resourcegroup should be the same that u used in the previous create or update task. This task will accomplish two things first it will send your artifacts to a blob storage on the given storage account. It will user the AzureArmEnpoint credentials for that. After that is will use the Admin username and password given in at the machine creation to copy from the blob storage into the VM. This makes the use configurable account data preferrable.
Thats all your release pipeline dev stage should look something like this, run and sit back and watch your log.