Ralf und die Cloud

Deploy VMs from custom image

RalfWi — Wed, 11 Oct 2017 14:07:38 GMT

Back in the old times, you might have used CDs to deploy a new desktop or server on premise. Or maybe System Center or any other tools. You might have created a "Golden Image" fully prepared and customized, or you used a basic image and tools like System Center, DSC, Puppet or Chef to customize your image after deployment. Well, good news is that most of those options are available in the cloud, too. If you go for the later one, just use a base image provided by Azure and include an extension for DSC or other tools to customize. If you want to use your own image, here is how to do it... I published already an article touching this for Azure Service Manager deployments (see here (in German, I'm afraid), but meanwhile you should plan with the Azure Resource Manager for deployments and that's what I will show here:

we use an existing VM and customize it (just a little bit, feel free to experiment further)
we prepare the VM to be used as an image
we deploy a new VM based on that image by using a template

We will do this with Windows, but it works for Linux in nearly the same way. Watch the end of this article for the differences! Ready? Let's go!

Customize Image

As said we will use an existing VM, for this example the VM is named "golden" and is in the resourcegroup "winvm-rg". Best practice is to build a new VM from scratch and customize it. For your first tests you might just change some registry keys, add a folder or install a feature (I always use the telnet client for tests). Iterate your way and use the experience you already have from your on-premise history...

Prepare VM

Good news is that you can use good, old sysprep.exe (located in %windir%\system32\sysprep). Once you are finished with customization, start it, choose (as usual) the "out-of-box-experience", click "generalize", and "shutdown". Or use this commandline after switching to the directory: [code] sysprep.exe /generalize /oobe /shutdown [/code] Your customized VM will be prepared and shut down. Remember: If you restart that VM again, you have to go through that process again. This was the first part, what comes next is to prepare the VM as image. There are two ways to do this. One is to create an "unmanaged image", the other is - you guess it - a "managed image". We will start with the "managed image" and have a short look on the "unmanaged image" later. First, stop the VM (yes, the VM is in a shutdown state, but is not stopped!): [code] Stop-AzureRmVM -ResourceGroupName winvm-rg -Name golden [/code] Second, generalize the OS disk: [code] Set-AzureRmVm -ResourceGroupName winvm-rg -Name golden -Generalized [/code] Verify that the VM is in a generalized state: [code] Get-AzureRmVm -ResourceGroupName winvm-rg -Name golden -Status [/code] You should see something like this: [code highlight="4"] (...) Code : OSState/generalized Level : Info DisplayStatus : VM generalized (...) [/code] We will go on from here creating a managed image. For information how to create an unmanaged image (and what's the difference) see further down. For the next steps, we first need some information.

the region where the image will be available, we will use germanycentral
the OSType, we will use Windows
the URI of the VHD of our "golden" VM
a (new?) resourcegroup to store the image reference

Let's look at no. 3. How do we get this information? Well, the URI is part of the storage profile of the VM, and we find it there under OSDisk and Vhd: [code] $temp = Get-AzureRmVm -ResourceGroupName winvm-rg -Name golden $uri = $temp.StorageProfile.OSDisk.Vhd.Uri [/code] Copy the Uri or save it in a variable like we did. If you want to use a central resource group for all images, create it: [code] New-AzureRmResourceGroup -name "goldenimages" -location germanycentral [/code] And now bring it all together to create the image: [code] $imgConf = New-AzureRmImageConfig -Location germanycentral $imgConf = Set-AzureRmImageOsDisk -Image $imgConf -OSType Windows -OSState Generalized -BlobUri $uri $image=New-AzureRmImage -ImageName "TestImage" -ResourceGroupName goldenimages -Image $imgConf [/code] Needless to say that you should choose a better name then "TestImage". If you look at $image, you see the Id of the new image, or use Get-AzureRmImage for a list of your images. We need this Id for our image reference in the template.

Deploy a new VM

Time to use it in a template. Very simple, just use a normal VM deployment template and change two things: Define a variable with the Id from above ($image.Id), this will look someting like: [code highlight="3"] (...) "variables": { "imageID": "/subscriptions/{...}/resourceGroups/goldenimages/providers/Microsoft.Compute/images/TestImage", (...) [/code] Use this variable in the Microsoft.Compute/virtualMachines resource definition: [code highlight="4"] (...) "storageProfile": { "imageReference": { "id": "[variables('ImageId')]" } } (...) [/code] and there we go. If you combine this with a deployment link like explained in this blog article you can build your own internal marketplace. Since I published the template used for this example on GitHub, you can see (but not deploy) all of this for copy&paste. The reason you cannot deploy is that you don't have access to my resources, especially the resourcegroup "goldenimages". To give access to a resourcegroup is left as an exercise to the reader :-).

Unmanaged Images

Unmanaged images are stored in a storage blob. The way to create them is similar to the one used above. Customize and sysprep the VM, stop it and generalize it. Then create the image: [code] Save-AzureRmVmImage -ResourceGroupName winvm-rg -Name golden -DestinationContainerName "winimages" -VHDNamePrefix "prefix" -path c:\temp\filename.json [/code] This will copy the VHD from the VM into a new container inside the same storage account. After the command finished, you find a JSON file at the location you entered (here c:\temp\filename.json) with some information, and under "resources"-"storageProfile"-"osDisk"-"image"-"uri" is the path to that image. The path is contructed like this: [code] https://{storageaccount}.blob.core.cloudapi.de/system/Microsoft.Compute/Images/{DestinationContainer}/{prefix}-osDisk... [/code] To use that image in a deployment, make sure that the container has appropriate Read Permissions, maybe copy the image to another container/storageaccount and modify your template as shown: [code highlight="3,4,5,33,38"] (...) "variables": { "srcImageUri": "https://goldenimages.blob.core.cloudapi.de/windows/master-Win2012R2-v3.vhd", "srcImageOS": "Windows", "ImageResourceName": "myImage", (...) "resources": [ { "type": "Microsoft.Compute/images", "apiVersion": "2016-04-30-preview", "name": "[variables('ImageResourceName')]", "location": "[resourceGroup().location]", "properties": { "storageProfile": { "osDisk": { "osType": "[variables('srcImageOS')]", "osState": "Generalized", "blobUri": "[variables('srcImageUri')]", "storageAccountType": "Standard_LRS" } } } }, (...) { "apiVersion": "2017-03-30", "type": "Microsoft.Compute/virtualMachines", "name": "[variables('vmName')]", "location": "[resourceGroup().location]", "dependsOn": [ "[resourceId('Microsoft.Storage/storageAccounts/', variables('storageAccountName'))]", "[resourceId('Microsoft.Network/networkInterfaces/', variables('nicName'))]", "[resourceId('Microsoft.Compute/images/', variables('ImageResourceName'))]" ], "properties": { "storageProfile": { "imageReference": { "id": "[resourceId('Microsoft.Compute/images/', variables('ImageResourceName'))]" } }, (...) [/code] To explain this: We create an additional resource, the image, and use this resource later for the VM. Notice that I moved the image to a new location in another storage account. You find the full template also on GitHub.

Additions

Linux

As promised, here is in short what to do with Linux. It is nearly identical, just replace the sysprep stuff with waagent. [code] sudo waagent -deprovision+user -force [/code] and replace "Windows" with "Linux" when creating the image. See further down unter "Links" for more information.

Preparations

Another thing is where you customize your VM. I prefer Azure, but using a Hyper-V image is also possible of course. You have to do some adoptions, especially watch out for using a fixed disk and a .vhd instead of a .vhdx, but after uploading the VHD into Azure storage the rest of the steps are the same. For preparation see further down under "Links".

Post-deployment tasks

Of course you can add extensions to the VM for DSC etc to customize the VM even further. Sometimes it's a thin line between putting everything into the image or keep some customizations for DSC. Discussions about this is far beyond the scope of this article...

Links

Here are some links to really good AzureDocs articles about image creation, including PowerShell and CLI creation of VMs from managed and unmanaged images. Check them out, they are worth it...

All examples are tested in Azure Germany. Here is where you get a free Azure Germany trial!

Adding tags to resources

RalfWi — Thu, 05 Oct 2017 03:08:41 GMT

Adding tags to resources helps us to organize our resources and to automate some tasks. Here is a small intro on how to use tags in the Azure portal, in templates, or with PowerShell. In this article we will use tags only for virtual machines, but you can add tags to any resource created with the Azure Resource Manager (including resourcegroups). Tags are simple name-value pairs that we can define the way we like it. An (often used) example is the tagging of a resource with the appropriate cost center (like "Department" = "Sales"), or to separate development from production ("Environment" = "Test"), or whatever else we have in mind to organize.

Portal

If you look at the resource in the portal, there is a "Tags" entry. Click on it (1), enter a name-value pair (2) and hit "Save" (3). That's it. You can choose from previously used tags by selecting from the dropdown menu. [caption id="attachment_686" align="alignnone" width="1024"] Using tags in the Azure portal[/caption] Here we use the name "purpose" and the value "blog-example" to make it easier to delete resources that we needed for screenshots... :-) We can add more tags to a resource, up to 15 per resource. And there is a main "Tags" menu (1) that we can use to search across all our resources for special tags (2):

Templates

When using templates to deploy resources (which is a very good idea by the way...) simply add them (as a list) into the template: [code gutter="false"] ... "resources": [ { "apiVersion": "2016-01-01", "type": "Microsoft.Storage/storageAccounts", "name": "[concat('storage', uniqueString(resourceGroup().id))]", "location": "[resourceGroup().location]", "tags": { "Dept": "Finance", "Environment": "Production" }, ... [/code] Here we set two tags, "Dept" and "Environment", at a storage resource. This is really simple... and of course those resources and tags can be found via the portal also. If you use parameters for the tags, you will be - as usual - prompted before the deployment to enter values for those tags. [code gutter="false"] ... "resources": [ { "apiVersion": "2016-01-01", "type": "Microsoft.Storage/storageAccounts", "name": "[concat('storage', uniqueString(resourceGroup().id))]", "location": "[resourceGroup().location]", "tags": { "Dept": "[parameters('DepartmentTag')]", "Environment": "[parameters('EnvironmentTag')]" }, ... [/code] Note that it is not possible to set tags on resourcegroups with a template, only to resources. If you want to add tags to resourcegroups, you must do this via the portal or PowerShell.

PowerShell

Tags are a property of a resource or a resourcegroup object. To list them, simply enter Get-AzureRmResourceGroup and you might get something like this: [code gutter="false"] C:> Get-AzureRmResourceGroup -Name test01-rg ResourceGroupName : test01-rg Location : germanycentral ProvisioningState : Succeeded Tags : Name Value ======= =============== purpose unknown status unknown/unknown ResourceId : /subscriptions/06(...)/resourceGroups/test01-rg [/code] Similar for a resource inside a resourcegroup: [code gutter="false"] C:> Get-AzureRmResource -ResourceGroupName test01-rg -ResourceName rw01-vm1 Name : rw01-vm1 ResourceId : /subscriptions/06(...)/virtualMachines/rw01-vm1 ResourceName : rw01-vm1 ResourceType : Microsoft.Compute/virtualMachines ResourceGroupName : test01-rg Location : germanycentral SubscriptionId : 06d(...) Tags : {purpose} [/code] Tags are dictionary objects, so we can work with them once we saved the object: [code gutter="false"] C:> $tags = (Get-AzureRmResource -ResourceGroupName test01-rg -ResourceName rw01-vm1).Tags C:> $tags Name Value ---- ----- purpose VM [/code] We can add name/value pairs: [code gutter="false"] C:> $tags.Add("status","active") C:> $tags Name Value ---- ----- purpose VM status active [/code] We can modify them (like adding some text): [code gutter="false"] C:> $tags.Item("status") += " (do not delete)" C:> $tags Name Value ---- ----- purpose VM status active (do not delete) [/code] or we can delete pairs: [code gutter="false"] C:> $tags.Remove("status") [/code] Once we are finished with modifying the dictionary object, we can write it back by using the "Set- instead of the "Get-" cmdlet: [code gutter="false"] C:> Set-AzureRmResource -ResourceGroupName test01-rg -ResourceName rw01-vm1 -Tags $tags C:> Set-AzureRmResourceGroup -Name test01-rg -Tags $tags [/code]

Summary

Tags are a great way to organize resources just the way you like it. And if you think further, it is easy to assign tasks to all resources with a special value for a key, like garbage collection for all resources with "Status" = "delete me". To be consequent, use Azure policies to make sure that all your resources or resourcegroups at least have a tag.

Azure Instance Metadata

RalfWi — Tue, 22 Aug 2017 21:31:13 GMT

There is a great new feature Azure provides, called Azure Instance Metadata. It gives you information about the metadata of a VM from within the VM. And here is how... At the time of this writing Azure Instance Metadata is GA already in global Azure, and it's in preview in all the other clouds (and therefore available). Let's see how it works by using one of those others, the Azure German Cloud in this case. Log into your VM (Windows or Linux is both supported, I'm using a Windows VM here). Now start a PowerShell, and enter: [code light="true" autolinks="false"] curl –H @{‘Metadata’=’true’} https://169.254.169.254/metadata/instance?api-version=2017-04-02 [/code] We are using curl here (which is by the way an alias for Invoke-WebRequest). You might also use this syntax: [code light="true" autolinks="false"] Invoke-RestMethod -Headers @{"Metadata"="true"} ` -URI https://169.254.169.254/metadata/instance?api-version=2017-04-02 [/code] There are a couple of things in this request. Let's see them one by one:

The request must include the header "Metadata"="true"
The address is always 169.254.169.254 and is accessible only from within the VM. There is no need to assign that address to your VM, this is done automatically.
Metadata format is versioned, here we use version 2017-04-02. Other version will come, but you can still use the older versions

The output has a "Content" field with a json string containing the metadata. Json is the default output format, text is also possible, example see further down. [code autolinks="false"] { "compute":{ "location":"GermanyCentral", "name":"myVM", "offer":"WindowsServer", "osType":"Windows", "platformFaultDomain":"0", "platformUpdateDomain":"0", "publisher":"MicrosoftWindowsServer", "sku":"2016-Datacenter", "version":"2016.127.20170630", "vmId":"ef2aa96c-e3a7-5432-b42f-d31fc94a3cec", "vmSize":"Standard_DS2_v2" }, "network":{ "interface":[ { "ipv4":{ "ipAddress":[ { "privateIpAddress":"192.168.1.4", "publicIpAddress":"51.4.201.56" } ], "subnet":[ { "address":"192.168.1.0", "prefix":"24" } ] }, "ipv6":{ "ipAddress":[] }, "macAddress":"0017FA104DA4" } ] } } [/code] The meaning of the most of the fields should be clear, see the complete description on the Azure Documentation website. You can access parts of this output in different ways, here are some examples... [code light="true" autolinks="false"] (Invoke-RestMethod -Headers @{"Metadata"="true"} ` -URI "https://169.254.169.254/metadata/instance?api-version=2017-04-02).compute.location" [/code] This will retrieve the metadata as an object and access the nodes "Compute" and "Location" under it directly. So the output is as expected: [code light="true" autolinks="false"] GermanyCentral [/code] Or save the output to a variable first and then access the properties for the same result [code] $md = Invoke-RestMethod -Headers @{"Metadata"="true"} ` -URI "https://169.254.169.254/metadata/instance?api-version=2017-04-02" $md.Compute.Location [/code] Or put it directly in the request (when you expect a single property you have to use the "text" format by appending "format=text"): [code light="true" autolinks="false"] Invoke-RestMethod -Headers @{"Metadata"="true"} ` -URI "https://169.254.169.254/metadata/instance/compute/location?api-version=2017-04-02&format=text" [/code] Furthermore, there is not only metadata about the environment, but also about upcoming maintenance events. Simply replace "instance" with "scheduledevents": [code light="true" autolinks="false"] Invoke-RestMethod -Headers @{"Metadata"="true"} ` -URI "https://169.254.169.254/metadata/scheduledevents?api-version=2017-04-02" [/code] Please remember that in some regions this service is still in preview, and watch out for announcements for example in the Azure Germany Teamblog (see link on the right menue) or in the Azure blog. If you want to test it in Azure Germany, why not sign up for a free trial account?

Bedingte Verzweigungen Teil 2

RalfWi — Tue, 15 Aug 2017 12:19:30 GMT

(also available in english) Wie angekündigt in meinem letzten Artikel zu ARM Templates folgt hier eine weitere Möglichkeit, in einem ARM Template zu verzweigen, basierend auf einer Bedingung. Wir verwenden wieder die Idee mit den verschachtelten Deployments, aber diesmal füllen wir einen Array mit alternativen URLs und entscheiden uns - mit etwas Mathe-Magie - für eines der Arrayelemente. Für unser Beispiel möchten wir uns zwischen einem Availability Set (bei mehr als einer VM) oder keinem Availability Set (bei nur einer VM) entscheiden. Die Bedingung ist also klar. Aber leider gibt es sowas wie if (vmCount -gt 1) then... hier nicht. Ok, hier ist der Trick (und Danke an AzureCAT für die Demonstration in den buildingblock templates ). Es gibt eine Funktion namens "mod", steht für das lateinische "modulo", und liefert den Rest bei einer Division zweier ganzer Zahlen. Wenn man zum Beispiel "8" durch "5" teilt, dann ergibt das "1" und ein Rest von "3", eben mod(8,5)=3. Wie uns das hilft? Ganz einfach. Teilt man eine Zahl durch die nächstkleinere, dann ergibt das immer einen Rest von "1", außer die erste Zahl ist eine "2". Wie man hier sehen kann: [code gutter="false"] mod(2,1)=0 mod(3,2)=1 mod(4,3)=1 mod(5,4)=1 ... [/code] Also ganz egal, was unsere Zahl ist, wir bekommen entweder eine "0" oder eine "1". Und jetzt? Na, bitte mitdenken! Ich hab doch oben schon verraten, dass wir mit einem Array arbeiten wollen, und hier haben wir etwas, dass sich prima als Index eignet... Hier mal der erste Teil des Templates (gibt es auch auf GitHub mit dem Rest für diese Demo): [code] { "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#", "contentVersion": "1.0.0.0", "parameters": { "vmCount": { "type": "int" } }, "variables": { "index": "[mod(add(parameters('vmCount'), 1), parameters('vmCount'))]", "avSetTemplates": [ "[uri(deployment().properties.templateLink.uri, 'availabilitySet-empty.json')]", "[uri(deployment().properties.templateLink.uri, 'availabilitySet-new.json')]" ], "avSetTemplate": "[variables('avSetTemplates')[variables('index')]]", "templateNamePart": [ "nop", "new" ], "deploymentName": "[variables('templateNamePart')[variables('index')]]" }, [/code] Keine Panik! Wir schauen uns das im Einzelnen an, dieser nette Trick ist es wert... Wir haben einen Parameter "vmCount" als Integer (Zeilen 5-7). Geben wir eine "1" vor, dann brauchen wir kein Availability Set, aber für alles größer als "1" wollen wir das. Die erste Variable, die wir definieren, ist "index" (Zeile 11), und die regelt das. Wir addieren "1" zu "vmCount", teilen durch "vmCount", und erhalten als Rest (wir erinnern uns an unserer Tabelle von oben) eine "0" bei "vmCount" von "1" (mod(1+1,1)=0) oder eine "1", wenn "vmCount" größer als "1" ist (mod(2+1,2)=1). Als nächstes definieren wir einen Array mit den alternativen URLs, basierend auf der aktuellen URL. Für unser Beispiel verwenden wir das Template "availabilitySet-empty.json" (ein leeres Template, wir wollen ja nix tun) und "availabilitySet-new.json" (hier würde dann die Definition für das Availability Set stehen - in unserem Beispiel ist das aber ebenfalls leer). Jetzt fügen wir alles zusammen (Zeile 16) und definieren das nächste zu verwendende Template als das Element aus dem Array mit dem Index, den wir gerade ausgerechnet haben. Wir speichern das in der Variable "avSetTemplate" (ohne "s" am Ende). Und (Zeilen 17-21) dann definieren wir noch einen Deployment Namen, der auf dem gleichen Index basiert. Hier ist der Rest des Templates: [code firstline="24"] "resources": [ { "type": "Microsoft.Resources/deployments", "apiVersion": "2015-01-01", "name": "[variables('deploymentName')]", "properties": { "mode": "Incremental", "templateLink": { "uri": "[variables('avSetTemplate')]" }, "parameters": { } } } ], "outputs": { } } [/code] Zeit für einen (verbose) Test... [code gutter="false" highlight="1,2,8"] PS C:\temp> New-AzureRmResourceGroupDeployment -vmcount 1 -verbose -Name "conditional11" -ResourceGroupName vstest1-mcd -TemplateUri "https://raw.githubusercontent.com/gitralf/templates/master/test-conditional-2/azuredeploy.json" AUSFÜHRLICH: Ausführen des Vorgangs "Creating Deployment" für das Ziel "vstest1-mcd". AUSFÜHRLICH: 10:45:40 - Template is valid. AUSFÜHRLICH: 10:45:40 - Create template deployment 'conditional11' AUSFÜHRLICH: 10:45:40 - Checking deployment status in 5 seconds AUSFÜHRLICH: 10:45:45 - Resource Microsoft.Resources/deployments 'nop' provisioning status is running AUSFÜHRLICH: 10:45:45 - Checking deployment status in 5 seconds AUSFÜHRLICH: 10:45:51 - Checking deployment status in 5 seconds AUSFÜHRLICH: 10:45:56 - Resource Microsoft.Resources/deployments 'nop' provisioning status is succeeded DeploymentName : conditional11 ResourceGroupName : vstest1-mcd ProvisioningState : Succeeded Timestamp : 15.08.2017 08:45:52 Mode : Incremental TemplateLink : Uri : https://raw.githubusercontent.com/gitralf/templates/master/test-conditional-2/azuredeploy.json ContentVersion : 1.0.0.0 Parameters : Name Type Value =============== ========================= ========== vmCount Int 1 [/code] "vmCount" haben wir in der Kommandozeile auf "1" gesetzt, wir brauchen also kein Availability Set (Deployment "nop"). Setzen wir "vmCount" auf "2", erhalten wir: [code gutter="false" highlight="1,2,8"] PS C:\temp> New-AzureRmResourceGroupDeployment -vmcount 2 -verbose -Name "conditional11" -ResourceGroupName vstest1-mcd -TemplateUri "https://raw.githubusercontent.com/gitralf/templates/master/test-conditional-2/azuredeploy.json" AUSFÜHRLICH: Ausführen des Vorgangs "Creating Deployment" für das Ziel "vstest1-mcd". AUSFÜHRLICH: 10:46:11 - Template is valid. AUSFÜHRLICH: 10:46:12 - Create template deployment 'conditional11' AUSFÜHRLICH: 10:46:12 - Checking deployment status in 5 seconds AUSFÜHRLICH: 10:46:17 - Resource Microsoft.Resources/deployments 'new' provisioning status is running AUSFÜHRLICH: 10:46:17 - Checking deployment status in 5 seconds AUSFÜHRLICH: 10:46:22 - Checking deployment status in 5 seconds AUSFÜHRLICH: 10:46:28 - Resource Microsoft.Resources/deployments 'new' provisioning status is succeeded DeploymentName : conditional11 ResourceGroupName : vstest1-mcd ProvisioningState : Succeeded Timestamp : 15.08.2017 08:46:27 Mode : Incremental TemplateLink : Uri : https://raw.githubusercontent.com/gitralf/templates/master/test-conditional-2/azuredeploy.json ContentVersion : 1.0.0.0 Parameters : Name Type Value =============== ========================= ========== vmCount Int 2 [/code] Wie erwartet wird das Deployment "new" verwendet. Das war's auch schon. Ich bin mir sicher, dass - zusammen mit meinem anderen Artikel zu Bedingten Verzweigungen in ARM Templates - der Weg offen steht für neue Templates und Deployments. Und nochmal Danke an AzureCAT! Wer das testen möchte und zu den wenigen gehört, die noch kein Azure Account haben, hier ist zum Beispiel ein Link zu einem kostenlosen Testabo für Azure Deutschland.

another if...then in ARM templates

RalfWi — Tue, 15 Aug 2017 11:47:04 GMT

(auch verfügbar in Deutsch) As promised in my last article about ARM templates here is another way to trigger a deployment based on a condition. We again use the idea of having nested deployments, but this time we fill an array with alternative template links and decide - based on math - which one to use. In this example we want to decide if an availability set should be created or not. This obviously only makes sense when we have more than one VM, so this will be our condition. But how to use it? There is nothing like if (vmCount -gt 1) then.... Well, here is the trick (and thanks to the AzureCAT buildingblock templates for the idea). There is a function called "mod", which stands for the latin "modulo" and returns the rest when you divide two numbers. For example, when you divide "8" by "5", you get "1" and a rest of "3", so mod(8,5)=3. How does this help us? Easy. When you divide a number by the next smaller one, you always get a rest of "1", except when the first number is a "2". See here: [code gutter="false"] mod(2,1)=0 mod(3,2)=1 mod(4,3)=1 mod(5,4)=1 ... [/code] No matter what your number is, when you use the "mod" function with the next smaller number, you either get "0" or "1". Any idea, how to go on? You should! I already taked about using an array, and here we have something that we can use as an index... Have a look at this part of a template (available on GitHub with the rest for this demo): [code] { "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#", "contentVersion": "1.0.0.0", "parameters": { "vmCount": { "type": "int" } }, "variables": { "index": "[mod(add(parameters('vmCount'), 1), parameters('vmCount'))]", "avSetTemplates": [ "[uri(deployment().properties.templateLink.uri, 'availabilitySet-empty.json')]", "[uri(deployment().properties.templateLink.uri, 'availabilitySet-new.json')]" ], "avSetTemplate": "[variables('avSetTemplates')[variables('index')]]", "templateNamePart": [ "nop", "new" ], "deploymentName": "[variables('templateNamePart')[variables('index')]]" }, [/code] Don't be shocked when you don't understand it first, we go through it here. This awesome trick is worth it... We have a parameter "vmCount" as an integer (line 5-7). When we enter "1" as number of VMs, we don't need an availability set, but for "vmCount" greater than "1" we want it. The first variable we create is "index" (line 11). We add "1" to "vmCount" and divide it by "vmCount". According to our table this gives us a "0" when vmCount is "1" (mod(1+1,1)=0) or "1" (mod(2+1,2)=1) when "vmCount" is greater than "1". Next step (lines 12-15) is to define an array of alternative URLs, based on the current URL. For our example we (like in the last article) use two empty templates and name them "availabilitySet-empty.json" (this would be the empty template to do nothing) and "availabilitySet-new.json" (which would normally hold the definition for the availability set - in our example it is empty, too). Now we put it together (line 16) and define the next template where the deployment should continue as the element in this array with the index that we calculated, and store it in variable "avSetTemplate" (without the "s" at the end). And (line 17-21) we define a deployment name also based on an array using the same index again. Here is the rest of the template: [code firstline="24"] "resources": [ { "type": "Microsoft.Resources/deployments", "apiVersion": "2015-01-01", "name": "[variables('deploymentName')]", "properties": { "mode": "Incremental", "templateLink": { "uri": "[variables('avSetTemplate')]" }, "parameters": { } } } ], "outputs": { } } [/code] Time for a (verbose) test... [code gutter="false" highlight="1,2,8"] PS C:\temp> New-AzureRmResourceGroupDeployment -vmcount 1 -verbose -Name "conditional11" -ResourceGroupName vstest1-mcd -TemplateUri "https://raw.githubusercontent.com/gitralf/templates/master/test-conditional-2/azuredeploy.json" AUSFÜHRLICH: Ausführen des Vorgangs "Creating Deployment" für das Ziel "vstest1-mcd". AUSFÜHRLICH: 10:45:40 - Template is valid. AUSFÜHRLICH: 10:45:40 - Create template deployment 'conditional11' AUSFÜHRLICH: 10:45:40 - Checking deployment status in 5 seconds AUSFÜHRLICH: 10:45:45 - Resource Microsoft.Resources/deployments 'nop' provisioning status is running AUSFÜHRLICH: 10:45:45 - Checking deployment status in 5 seconds AUSFÜHRLICH: 10:45:51 - Checking deployment status in 5 seconds AUSFÜHRLICH: 10:45:56 - Resource Microsoft.Resources/deployments 'nop' provisioning status is succeeded DeploymentName : conditional11 ResourceGroupName : vstest1-mcd ProvisioningState : Succeeded Timestamp : 15.08.2017 08:45:52 Mode : Incremental TemplateLink : Uri : https://raw.githubusercontent.com/gitralf/templates/master/test-conditional-2/azuredeploy.json ContentVersion : 1.0.0.0 Parameters : Name Type Value =============== ========================= ========== vmCount Int 1 [/code] We set the "vmCount" to "1", so no availability set was needed (deployment "nop"). Using a "vmCount" of "2" (or "42") gives us: [code gutter="false" highlight="1,2,8"] PS C:\temp> New-AzureRmResourceGroupDeployment -vmcount 2 -verbose -Name "conditional11" -ResourceGroupName vstest1-mcd -TemplateUri "https://raw.githubusercontent.com/gitralf/templates/master/test-conditional-2/azuredeploy.json" AUSFÜHRLICH: Ausführen des Vorgangs "Creating Deployment" für das Ziel "vstest1-mcd". AUSFÜHRLICH: 10:46:11 - Template is valid. AUSFÜHRLICH: 10:46:12 - Create template deployment 'conditional11' AUSFÜHRLICH: 10:46:12 - Checking deployment status in 5 seconds AUSFÜHRLICH: 10:46:17 - Resource Microsoft.Resources/deployments 'new' provisioning status is running AUSFÜHRLICH: 10:46:17 - Checking deployment status in 5 seconds AUSFÜHRLICH: 10:46:22 - Checking deployment status in 5 seconds AUSFÜHRLICH: 10:46:28 - Resource Microsoft.Resources/deployments 'new' provisioning status is succeeded DeploymentName : conditional11 ResourceGroupName : vstest1-mcd ProvisioningState : Succeeded Timestamp : 15.08.2017 08:46:27 Mode : Incremental TemplateLink : Uri : https://raw.githubusercontent.com/gitralf/templates/master/test-conditional-2/azuredeploy.json ContentVersion : 1.0.0.0 Parameters : Name Type Value =============== ========================= ========== vmCount Int 2 [/code] As expected the deployment "new" was used, since we want an availability set here. That's it. I'm sure that - together with the last article about if...then in ARM templates - you will find ways to use this nice little trick, and again thanks to the AzureCAT team for demonstrating it. If you want to test it and you are one of the few guys out there without an Azure subscription, here for example is where you get a free Azure Germany trial!

Bedingte Verzweigungen mit ARM Templates

RalfWi — Thu, 10 Aug 2017 16:39:24 GMT

(also available in english) Wer häufiger mit ARM Templates arbeitet, der kommt früher oder später an eine Stelle, wo ein if...then sinnvoll wäre, oder, mit anderen Worten, eine bedingte Verzweigung. Nun, es gibt ein paar Möglichkeiten, und in diesem Beitrag werden wir uns welche davon ansehen.

Condition

Der wahrscheinlich einfachste Weg ist die Verwendung von condition für eine Ressource. Bei der Definition einer Ressource wird die Direktive einfach irgendwo innerhalb des Ressourcenblocks eingefügt, der besseren Lesbarkeit wegen hier am Anfang: [code] "condition": "", "type": "", "apiVersion": "", ... [/code] Es ist so einfach wie es aussieht: Falls der Ausdruck hinter dem condition-Element ein True ergibt, wird die Ressource verteilt (natürlich nur, wenn de Rest der Syntax stimmt...), oder eben nicht. Hier ein oft verwendetes Beispiel: [code] "condition": "[equals(parameters('sshOrPW'),'password')]", "apiVersion": "2016-03-30", "type": "Microsoft.Compute/virtualMachines", ... }, { "condition": "[equals(parameters('sshOrPW'),'ssh')]", "apiVersion": "2016-03-30", "type": "Microsoft.Compute/virtualMachines", ... }, [/code] Wir brauchen nur einen Parameter mit den zwei möglichen Eingaben password oder ssh. Der entsprechende Parameter-Abschnitt sei dem Leser zur Übung überlassen... Die hier verwendete Template Funktion equals ergibt True, wenn beide Argumente gleich sind (wer hätte das gedacht?), ansonsten False. Wenn wir also den Parameter sshOrPW mit "password" belegen, dann wird nur die erste Ressource ausgebracht, die zweite wird ignoriert. Und umgekehrt natürlich. Total einfach, oder? Aber Achtung: Gerade mit mehreren bedingten Ressourcen wird das schnell unübersichtlich, besonders wenn dann auch noch Abhängigkeiten definiert sind. Zum Glück gibt es noch eine Alternative, und zwar mit verschachtelten Templates.

Verschachtelte Templates

Vielleicht hat das der ein oder andere noch nie verwendet, aber man kann tatsächlich mehr als ein Template definieren und dann das eine vom anderen aus aufrufen. Das nennt man dann verschachtelte Templates, und man verwendet dafür den Ressourcentyp Microsoft.Resources/deployments. Einfach ein Name, ein paar Eigenschaften, und in den Eigenschaften steckt die URI zum nächsten Template drin, templatelink. Mehr dazu auf AzureDocs. [code] { "apiVersion": "2017-05-10", "name": "linkedTemplate", "type": "Microsoft.Resources/deployments", "properties": { "mode": "incremental", "templateLink": { "uri": "[variables('subnetTemplate')]", "contentVersion": "1.0.0.0" }, "parameters": { ... } } } [/code] Die Idee, um das zu einer bedingten Verzweigung zu machen, ist wieder ganz einfach: Wir rufen Template A oder Template B auf, in Abhängigkeit von einer Variablen oder einem Parameter. Klar? Vielleicht ein Beispiel? Das gibt es auch als Download auf GitHub oder kann - wie unten gezeigt - auch direkt aufgerufen werden. Zuerst brauchen wir einen Parameter, um zu entscheiden, ob wir ein Subnetz anlegen oder nicht: [code] { "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#", "contentVersion": "1.0.0.0", "parameters": { "subnetYesNo":{ "type": "string", "defaultValue": "Yes", "allowedValues": [ "Yes", "No" ] } }, [/code] Dann brauchen wir die Links zu den alternativen Templates, und speichern das in einer Variable. Wir definieren auch gleich noch den passenden Namen für das Sub-Deployment, das macht das Debugging übersichtlicher... [code firstline="15"] "variables": { "subnetTemplate": "[concat('https://raw.githubusercontent.com/gitralf/templates/master/test-conditional/deploysubnet-',toLower(parameters('subnetYesNo')),'.json')]", "subnetTemplateName": "[concat('Subnet-',parameters('subnetYesNo'))]", }, [/code] Die entscheidende Stelle nochmal in Großaufnahme: [code gutter="false"] "[concat('https://.../test-conditional/deploysubnet-',toLower(parameters('subnetYesNo')),'.json')]" [/code] Wir verwenden hier die Funktionen concat und toLower. Ich denke, jeder weiß, was die tun (oder schaut hier nach). Wir bauen also den Dateinamen auf, indem wir den übergebenen Parameter integrieren. Wir könnten auch vorher eine entsprechende Variable zusammenbauen und dann hier verwenden. Abhängig von der Eingabe rufen wir jetzt also das Template subnetTemplate auf, das entweder auf deploysubnet-yes.json oder deploysubnet-no.json endet: [code firstline="19"] "resources": [ { "type": "Microsoft.Resources/deployments", "apiVersion": "2015-01-01", "name": "[variables('subnetTemplateName')]", "properties": { "mode": "Incremental", "templateLink": { "uri": "[variables('subnetTemplate')]" }, } } ], "outputs": { } } [/code] Für dieses einfache Beispiel verwenden wir zwei identische (leere) Templates (mit den oben zusammengebauten Namen) und starten das Deployment mit dem -Verbose Switch. Wir sehen so was ähnliches wie das hier: [code gutter="false"] PS C:\temp> New-AzureRmResourceGroupDeployment -Name "conditional02" -ResourceGroupName vstest1-mcd -verbose -subnetYesNo No -TemplateUri "https://raw.githubusercontent.com/gitralf/templates/master/test-conditional/azuredeploy.json" AUSFÜHRLICH: Ausführen des Vorgangs "Creating Deployment" für das Ziel "vstest1-mcd". AUSFÜHRLICH: 14:37:04 - Template is valid. AUSFÜHRLICH: 14:37:05 - Create template deployment 'conditional02' AUSFÜHRLICH: 14:37:05 - Checking deployment status in 5 seconds AUSFÜHRLICH: 14:37:10 - Resource Microsoft.Resources/deployments 'Subnet-No' provisioning status is running AUSFÜHRLICH: 14:37:10 - Checking deployment status in 5 seconds AUSFÜHRLICH: 14:37:15 - Resource Microsoft.Resources/deployments 'Subnet-No' provisioning status is succeeded DeploymentName : conditional02 ResourceGroupName : vstest1-mcd ProvisioningState : Succeeded Timestamp : 10.08.2017 12:37:14 Mode : Incremental TemplateLink : Parameters : Name Type Value =============== ========================= ========== subnetYesNo String No Outputs : DeploymentDebugLogLevel : [/code] Es wurde also wie zu sehen ist das zweite Deployment "Subnet-No" aufgerufen, wie erwartet.

Ausblick

Es gibt noch andere Wege, um zu entscheiden, ob ein Template aufgerufen werden soll oder nicht. Zum Beispiel kann man einen Array füllen mit den alternativen URLs, und dann etwas Mathe-Magie nutzen, um einen Index zu ermitteln, und übergibt dann das entsprechende Array-Element (wie in meinem nächsten Artikel beschrieben). Der Grundgedanke ist aber immer gleich: Man ruft über ein verschachteltes Template weitere Deployments mit verschiedenen URLs auf. Für heute genug. Aber da werden noch ein paar weitere Artikel zu Azure Resource Manager Templates folgen. Dranbleiben! Warum nicht in der Zwischenzeit mit einem kostenlosen Azure Testaccount anfangen? Hier der Link für die Microsoft Cloud Deutschland...

if...then in ARM Templates

RalfWi — Thu, 10 Aug 2017 15:35:02 GMT

(auch verfügbar in Deutsch) When working with ARM Templates you sometimes hit a point where you wish to have something like if...then, or, in other words, conditional deployments. Well, actually there are ways to do this, and here is how

Condition

The probably easiest way is to use the condition element for a resource. When you describe a resource in your JSON template file, simply place it somewhere inside the resource definition, like here: [code] "condition": "", "type": "", "apiVersion": "", ... [/code] It is as simple as it looks: Whenever the expression after the condition-element expands to true, the resource defined in this block will be deployed (well, if the rest of the template syntax is correct etc...), or not deployed. Here is an often used example: [code] "condition": "[equals(parameters('sshOrPW'),'password')]", "apiVersion": "2016-03-30", "type": "Microsoft.Compute/virtualMachines", ... }, { "condition": "[equals(parameters('sshOrPW'),'ssh')]", "apiVersion": "2016-03-30", "type": "Microsoft.Compute/virtualMachines", ... }, [/code] All we need now is a parameter named sshOrPW with two possible values. The correct parameter section is left as an exercise to the reader... We are using here a template function, equals. This function expands to True if both arguments are equal (whow, who would have thought that?), otherwise to False. So when we fill the parameter sshOrPW with "password", only the first resource is deployed, the second is ignored. And the other way round, of course. Pretty easy, or? But be warned: Watch out if you have more then one conditionally deployed resource, especially when there is a dependency between. It might be hard to track your template design. Luckily, there is a second way, especially when you have a set of resources to be deployed depending on a condition, and that is with nested templates.

Nested templates

You might have never used it, but you can use more then one template and call them from within another template. That's called nested templates, and uses the resource type Microsoft.Resources/deployments. You define a name and some properties, and within the properties there is the link to the other template, templatelink. Find more about this on AzureDocs. [code] { "apiVersion": "2017-05-10", "name": "linkedTemplate", "type": "Microsoft.Resources/deployments", "properties": { "mode": "incremental", "templateLink": { "uri": "[variables('subnetTemplate')]", "contentVersion": "1.0.0.0" }, "parameters": { ... } } } [/code] The idea to make this conditional is to call template A or template B, depending on the value of a variable or parameter. Got it? Let's make an example, again with subnets. You find the templates for download in my GitHub repository or use it directly from there (as shown below). First we need a parameter to decide if we should deploy a subnet or not: [code] { "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#", "contentVersion": "1.0.0.0", "parameters": { "subnetYesNo":{ "type": "string", "defaultValue": "Yes", "allowedValues": [ "Yes", "No" ] } }, [/code] We need the links to the alternative templates, and we store them in a variable. We also name our deployment depending on the parameter input, that looks nicer. [code firstline="15"] "variables": { "subnetTemplate": "[concat('https://raw.githubusercontent.com/gitralf/templates/master/test-conditional/deploysubnet-',toLower(parameters('subnetYesNo')),'.json')]", "subnetTemplateName": "[concat('Subnet-',parameters('subnetYesNo'))]", }, [/code] Here a closer look at the main part: [code gutter="false"] "[concat('https://.../test-conditional/deploysubnet-',toLower(parameters('subnetYesNo')),'.json')]" [/code] We used the functions concat and toLower here. I'm pretty sure you know what they do (if not, read here). So we build the template URI by integrating the parameter into the filename. Depending on the input we are now calling a template subnetTemplate, which is either ending in deploysubnet-yes.json or deploysubnet-no.json: [code firstline="19"] "resources": [ { "type": "Microsoft.Resources/deployments", "apiVersion": "2015-01-01", "name": "[variables('subnetTemplateName')]", "properties": { "mode": "Incremental", "templateLink": { "uri": "[variables('subnetTemplate')]" }, } } ], "outputs": { } } [/code] For this simple test we create identical (empty) templates with the names created above and start the deployment with the -Verbose commandline switch. We see something like this: [code gutter="false" highlight="1,2,7"] PS C:\temp> New-AzureRmResourceGroupDeployment -subnetYesNo No -verbose -Name "conditional02" -ResourceGroupName vstest1-mcd -TemplateUri "https://raw.githubusercontent.com/gitralf/templates/master/test-conditional/azuredeploy.json" AUSFÜHRLICH: Ausführen des Vorgangs "Creating Deployment" für das Ziel "vstest1-mcd". AUSFÜHRLICH: 14:37:04 - Template is valid. AUSFÜHRLICH: 14:37:05 - Create template deployment 'conditional02' AUSFÜHRLICH: 14:37:05 - Checking deployment status in 5 seconds AUSFÜHRLICH: 14:37:10 - Resource Microsoft.Resources/deployments 'Subnet-No' provisioning status is running AUSFÜHRLICH: 14:37:10 - Checking deployment status in 5 seconds AUSFÜHRLICH: 14:37:15 - Resource Microsoft.Resources/deployments 'Subnet-No' provisioning status is succeeded DeploymentName : conditional02 ResourceGroupName : vstest1-mcd ProvisioningState : Succeeded Timestamp : 10.08.2017 12:37:14 Mode : Incremental TemplateLink : Parameters : Name Type Value =============== ========================= ========== subnetYesNo String No [/code] As we see, the nested deployment "Subnet-No" was called as expected.

To be continued...

There are other ways to decide wether or not to call a template. For example, fill an array with the alternative URIs, and then use some math tricks to calculate the index and use that array element (see my next article). But the basic idea is always the same: call a nested template with different URLs. Enough for today. But stay tuned for other articles from the world of Azure Resource Manager Templates! Coming soon. Meanwhile why not signing up for a free trial to Azure? Here is the link to Azure Germany...

Anmelden am Azure Resource Manager mit Zertifikat

RalfWi — Mon, 07 Aug 2017 14:56:24 GMT

Im alten Azure Portal gab es ja die Möglichkeit, sich ein Management-Zertifikat herunterzuladen und dieses für Logins zum Beispiel in PowerShell zu nutzen (.publishsettings hieß das Zauberwort). Mit dem Azure Resource Manager und dem neuen Azure Portal ist das nicht mehr möglich, hier kommt eine alternative Anmeldemöglichkeit über einen sogenannten "ServicePrincipal" ins Spiel, und so einen wollen wir hier mal anlegen, um uns künftig auch von PowerShell aus per Zertifikat anmelden zu können. Mit dem Azure Resource Manager können wir Benutzer oder Gruppen, oder eben auch Applikationen oder Skripten Rechte an Ressourcen zuweisen. Hierzu müssen wir eine Identität erzeugen und dafür sorgen, dass sich die App mit den Credentials dieser Identität authentifiziert. In unserem Fall wäre die App quasi PowerShell, und die Identität eben der genannte ServicePrincipal. Das Gute an diesem Prinzip ist, dass wir diesem "ServicePrincipal" (also dem Skript oder der Shell) ganz genau Rechte zuweisen können an Subscriptions, Ressourcengruppen oder Ressourcen, basierend auf RBAC, und auch das schauen wir uns an. Wir brauchen für unser Vorhaben 3 Zutaten:

ein Zertifikat
eine ApplicationID für den ServicePrincipal, und
notwendige Berechtigungen.

Fangen wir mal mit ein paar Voraussetzungen an…

Voraussetzungen

Applikationsregistrierungen können unter Umständen nur vom Tenant-Admin angelegt werden. Im Portal findet man diese Einstellung wie folgt:

Azure Active Directory wählen
User Settings
App Registrations

Ist diese Einstellung auf "No", dann kann nur ein Admin eine Applikation registrieren, und wenn wir keiner sind, dann müssen wir betteln gehen (ich mein natürlich, einen Change Request stellen und begründen). Nehmen wir mal an, wir dürfen oder wir sind sogar Admin, dann können wir weitermachen.

Zutat 1: Das Zertifikat

Wir brauchen ein Zertifikat, am einfachsten ein selbstsigniertes, es gehen aber auch offizielle. Auch hier der Einfachheit halber (wir wollen hier ja kein PKI Tutorial draus machen) erzeugen wir ein selbstsigniertes (selfsigned) Zertifikat. Als Profils machen wir das direkt in PowerShell: [code gutter="false"] $cert = New-SelfSignedCertificate -CertStoreLocation "cert:\CurrentUser\My" -Subject "CN=myServicePrincipalCert" -KeySpec KeyExchange $keyValue = [System.Convert]::ToBase64String($cert.GetRawCertData()) [/code] Wir haben gerade lokal im Zertifikatsspeicher "My" (oder "Eigene Zertifikate") ein Zertifikat samt Schlüssel erstellt. Das können wir uns übrigens auch anschauen, entweder über den Zertifikatsmanager (certmgr.msc) oder wieder über PowerShell: [code gutter="false"] get-childitem -Path "Cert:\CurrentUser\My" [/code] Unsere erste Zutat ist damit erledigt. Weiter geht's:

Zutat 2: Eine ApplicationID

Wie gelernt brauchen wir eine Applikationsregistrierung. Das können wir entweder via Portal oder auch wieder in der PowerShell machen: [code gutter="false"] $sp = New-AzureRMADServicePrincipal -DisplayName "myServicePrincipal" -CertValue $keyValue -EndDate $cert.NotAfter -StartDate $cert.NotBefore [/code] Das verwendet Variablen, die wir beim Anlegen des Zertifikats benutzt haben. Falls ein schon vorhandenes Zertifikat verwendet werden soll, dann müssen die Werte entsprechend ausgelesen werden. Als DisplayName bitte irgendwas Aussagekräftigeres wählen als ich hier, eventuell werden das im Laufe der Zeit ein paar mehr ServicePrincipals, und dann findet man die zum Beispiel wieder mittels: [code gutter="false"] Get-AzureADServicePrincipal -SearchString "myServicePrin" [/code] Um Rechte zuweisen zu können, benötigen wir später die ApplicationID. Die bekommen wir mit: [code gutter="false"] $appID=$sp.ApplicationID [/code]

Zutat 3: Berechtigungen

Erstmal hat die Applikation bzw. der ServicePrincipal keine Rechte. Aber das können wir ändern, natürlich immer vorausgesetzt, wir selber haben die notwendigen Rechte… So detailliert müssen wir RBAC (Role Bases Access Control) hier nicht betrachten, da gibt es eine prima Doku dazu. Wir nehmen uns einfach die aktuelle SubscriptionID (und die Tenant-ID können wir uns auch bei der Gelegenheit gleich merken, die brauchen wir unten noch für's Login). [code gutter="false"] Get-AzureRmContext [/code] Noch ein kleiner Hinweis: Zwischen dem Anlegen des ServicePrincipals und der Sichtbarkeit des Selbigen im AAD können ein paar Sekunden vergehen, also lieber mal ne Minute oder so warten. Dann aber geht's ab: [code gutter="false"] New-AzureRmRoleAssignment -Scope "/subscriptions/" -RoleDefinitionName Contributor -ServicePrincipalName $appID [/code] So. Jetzt hat die Applikation bzw. der ServicePrinzipal "Contributor"-Rechte auf der Subscription. Soll es ein anderer Scope sein, einfach die entsprechende ResourceID verwenden, zum Beispiel für eine Resourcengruppe: [code gutter="false"] Get-AzureRmResourceGroup [/code]

Login per Zertifikat

Alle Zutaten wurden gut verrührt und bei 42 Grad gebacken. Dann können wir jetzt probieren. Wir brauchen die folgenden Angaben:

Den Thumbprint des Zertifikats
Die ApplicationID
Die TenantID

Ok, statt einem Passwort brauchen wir jetzt 3 Angaben, und das auch noch recht komplizierte. Wo liegt jetzt nochmal der Vorteil? Nun, diese Angaben bleiben immer gleich, also kein Problem, die in einem Skript zu verwenden. Niemand, der nicht auch gleichzeitig Zugriff auf das Zertifikat (genauer den privaten Schlüssel) hat, kann sich damit anmelden. In der Umkehrung heißt das auch, dass das Login erstmal nur auf dem Computer möglich ist, auf dem das Zertifikat erzeugt wurde. Nach einem Export (mit private Key) und Import auf einem anderen Computer würde es dann auch dort gehen. Den Thumbprint bekommen wir ganz einfach: [code gutter="false"] $Thumbprint = (Get-ChildItem cert:\CurrentUser\My\ | Where-Object {$_.Subject -match "myServicePrincipalCert" }).Thumbprint [/code] Als Subject verwenden wir hier die Angabe bei der Erstellung, siehe oben bei Zutat 1. Das Login sieht dann so aus: [code gutter="false"] Login-AzureRmAccount -ServicePrincipal -CertificateThumbprint -ApplicationId -TenantId [/code] Oder mit einem realen Beispiel: [code gutter="false"] Login-AzureRmAccount -ServicePrincipal -CertificateThumbprint B007B51B911914E6CA5630137374A08648D02C8F -ApplicationId 919e6448-9c30-4481-ab5f-be29aa9021e4 -TenantId afa16547-9d30-4591-ac6f-be29aa9031e3 [/code] Zukünftig könnten wir also einfach beim Starten der PowerShell diese Zeile ausführen, und schon wären wir eingeloggt. Ganz ohne Passwort, denn das Zertifikat befindet sich ja in unserem Zertifikatsspeicher, und mit dem Windows-Login wird auch der Zugriff darauf erst freigegeben. Das heißt aber auch, wer das Zertifikat bekommt (mit dem privaten Schlüssel), und sich die restlichen Angaben beschafft, der kann sich solange anmelden, bis wir die Applikationsregistrierung wieder löschen (oder das Zertifikat abgelaufen ist). Also Aufpassen bei einem eventuellen Kopieren des Zertifikats auf andere Computer!

Microsoft Azure Deutschland

Für Azure Deutschland steht das alte Portal ja nicht mehr zur Verfügung, der hier beschriebene Weg ist damit der einzige (und auch generell der empfohlene) Weg, um sich mit Zertifikat anzumelden. Allerdings benötigt das Login noch zusätzlich die Angabe des Environments. Vollständig sieht das also so aus: [code gutter="false"] Login-AzureRmAccount -EnvironmentName "AzureGermanCloud" -ServicePrincipal -CertificateThumbprint -ApplicationId -TenantId [/code] Für Azure Deutschland gibt es übrigens hier ein kostenloses Testaccount… Eine ausführlichere Beschreibung der Möglichkeiten gibt es übrigens bei AzureDocs.

Azure Quickstart Templates besser nutzen

RalfWi — Thu, 27 Jul 2017 17:34:07 GMT

Wer sich mit dem Azure Resource Manager beschäftigt, der landet früher (hoffentlich) oder später bei den Azure Quickstart Templates auf GitHub. Da findet man für ganz viele Ressourcen Beispiele, die man dann an eigene Bedürfnisse anpassen kann. Heute wollen wir uns mal damit beschäftigen, wie man diese Vorlagen noch besser nutzen kann, insbesondere auch (aber nicht nur) mit Blick auf Microsoft Azure Deutschland.

Download

Klar ist die neueste Version immer nur online verfügbar, aber Git bietet ja von Hause aus schon Möglichkeiten, das offline verfügbar zu machen. Also entweder man lädt sich einfach das komplette Repository runter, oder man fork't und sync't lokal. Ist aber nicht Thema hier, daher bitte bei Git nachlesen, wie das mit fork geht. Download ist einfach, da steht rechts oben ein "Clone or Download" und dort kann man mit "Downlaod ZIP" alles einfach runterladen. Aufpassen, ist eine Menge!

Übersicht

Ein Problem ist immer wieder, ein Template zu finden, in dem eine bestimmte Ressource verwendet wird. Dafür habe ich mir mal einen PowerShell-Script (was sonst?) geschrieben, der folgendes macht:

geht alle JSON-Dateien im Dateibaum durch (nach dem Download, siehe oben). Dabei war es mir egal, ob die JSON Datei auch wirklich verwendet wird (azuredeploy.json) oder nicht (metadata.json), ich durchsuche einfach alle.
wenn die JSON-Datei einen Ressourceneintrag hat, dann wird der Typ ausgelesen
Template-Name und Ressourcentyp wird in eine Exceltabelle geschrieben (mit Link auf das Raw-Format der Github-Version, kann man aber auch umbauen auf den lokalen Pfad (Zeilen sind auskommentiert)
am Ende des Scripts kann man mit dem Excel weiterarbeiten (filtern, sortieren, speichern, was auch immer)

Nun kann man in der Excel-Tabelle einfach nach einem bestimmten Ressourcetyp suchen und bekommt alle Templates, die ihn verwenden, per Mausklick präsentiert. Praktisch, oder? Hier der Skript (ja, ich weiß, quick&dirty, wir gehen ihn aber im Anschluß durch): [code] $AQSpath="C:\woauchimmer\azure-quickstart-templates-master" $xlo = New-Object -comobject Excel.Application $xlo.Visible = $true $xlw = $xlo.Workbooks.Add() $xlw.Worksheets.Item(1).Name = "RP" $xl1 = $xlo.Worksheets.Item(1) $xl1.Cells.Item(1,1).value2 = "TemplateName" $xl1.Cells.Item(1,2).value2 = "ResourceProvider" write-host " --checking "+$strpath -ForegroundColor "yellow" $folders=get-childitem -path $AQSpath -directory $xl1counter=0 $folders| foreach-object { $folder=$_.fullname $templatename=$_.Name $jsons=get-childitem -path $folder -filter "*.json" -recurse if ($jsons.count -gt 0){ $jsons | foreach-object { $json=$_ write-host " ----checking "+$json.fullname -foregroundColor "yellow" $template=get-content -Path $json.fullname | ConvertFrom-Json $resources=$template.resources if ($resources.count -gt 0){ $resources | foreach-object { $xl1counter++ # $text='=HYPERLINK("file://'+$json.fullname+'","'+$templatename+'")' $text='=HYPERLINK("https://raw.githubusercontent.com/Azure/azure-quickstart-templates/master/'+$templatename+'/'+$json.Name+'","'+$templatename+'")' $xl1.Cells.Item($xl1counter,1).formula = $text $xl1.Cells.Item($xl1counter,2).value2 = $_.type } } } } } [/code] Die ersten Zeilen definieren den Pfad zum lokalen Repository, danach wird ein Excel geöffnet und Spaltenüberschriften gesetzt. Ab Zeile 16 geht der Script dann alle Verzeichnisse durch und sucht (rekursiv) nach JSON-Dateien. Sehr praktisch ist eine der tollen PowerShell-Funktionen, die hier in Zeile 24 verwendet wird, ConvertFrom-Json. Dieses Cmdlet erlaubt anschließend den einfachsten Zugriff auf alle JSON-Knoten (nennt man das so?). Folgerichtig stecken in $resources alle Ressourcen drin, die das Template enthält, und $resources[x].type liefert den Typ der xten Ressource (oder eben innerhalb einer foreach-Schleife). Ich glaub, da schreib ich gleich noch einen Artikel dazu... Hat ein bisschen gedauert, herauszufinden, warum Excel die Formel nicht wollte (hier Komma als Trennzeichen verwenden im Hyperlink). Entweder Zeile 29 oder Zeile 30 verwenden, je nachdem ob auf die lokale Datei (29 aktiv) oder auf GitHub (30 aktiv) verlinkt werden soll. Die Variante mit beiden Links sei dem Leser als Übungsaufgabe überlassen...

Anpassen an Microsoft Azure Deutschland

Damit die Templates auch in Azure Deutschland laufen, sind meistens nur noch wenige Anpassungen zu machen. Hier die wichtigsten.

Region

Die wenigsten Templates sollten eine fest eingetragene Region (location) verwenden. Meistens wird hier die gleiche Region wie die zugehörige Ressourcengruppe verwendet und man findet hoffentlich sowas wie: [code gutter="false"] "location": "[resourceGroup().location]", [/code]

Resource Provider

Ist der Resource Provider in Azure Deutschland verfügbar? Die meisten sind verfügbar, wer es vorher prüfen möchte, der kann alle RPs bzw. Types im Template ganz einfach testen. Anmelden in PowerShell und die Resourcetypen für einen Namespace auflisten: [code gutter="false"] Login-AzureRmAccount -Environment AzureGermanCloud (Get-AzureRmResourceProvider -ProviderNamespace Microsoft.Compute)|Select-Object Resourcetypes [/code] Die ganz Mutigen können das ja auch in eine Excel-Tabelle schieben und dann mit SVERWEIS arbeiten... uuhhhh....

Image

Insbesondere ältere VM Images sind nicht alle in Azure Deutschland verfügbar (und eventuell auch nicht in beiden Regionen!). Auch hier bringt PowerShell Klarheit: [code gutter="false"] #Liste der Image Publisher Get-AzureRmVMImagePublisher -Location germanycentral | Select-Object PublisherName #Liste der Offers für einen bestimmten Publisher Get-AzureRmVMImageOffer -Location germanycentral -PublisherName SUSE | Select-Object Offer #Liste der Skus für Publisher und Offer Get-AzureRmVMImageSku -Location germanycentral -PublisherName SUSE -Offer SLES | Select-Object Skus [/code]

VM Größen

Die früher verwendeten (und noch häufig in den Templates hinterlegten) VM Größen wurden zum Teil durch eine neuere Version (v2) ersetzt. Während in Azure beide Größen zur Verfügung stehen, sind auch hier für Azure Deutschland die Älteren weggefallen, d.h. die Templates müssen angepasst werden. Blöderweise hat jeder so seine eigene Vorstellung, wo "vmSize" im Template definiert werden soll. Entweder als Parameter, Variable, oder direkt in der Microsoft.Compute-Ressource (.properties.hardwareProfile.VmSize: "Standard_D2"). Meist reicht das Anfügen von "_v2" ans Ende, also "Standard_D2_v2". Die Liste der VM Größen liefert uns - Überraschung! - wieder PowerShell, und auch hier ist die Angabe der Region wichtig: [code gutter="false"] Get-AzureRmVMSize -Location germanycentral [/code]

Hardcoded Strings

In einigen wenigen Templates sind noch feste Strings drin mit falschen Endpunkten ("windows.net" meistens). Das hab ich aber schon mal in einem anderen Blog beschrieben. Noch Fragen? Fragen! Hier geht's zum kostenlosen Testabo für Azure Deutschland!

Site-to-Site VPN zwischen Clouds

RalfWi — Thu, 02 Feb 2017 15:17:49 GMT

(this article is also available in english) Nachdem Microsoft Azure Deutschland ja eine separate Instanz der Azure Cloud ist, mit unterschiedlichen Subscriptions, Rechenzentren, und auch ohne Verbindung zum Backbone, stellt sich die Frage, ob und wie man eine Azure Umgebung netztechnisch mit Azure Deutschland verknüpfen kann. Und genau das soll Thema dieses Blogposts sein. Um Netze nach und in Azure zu koppeln gibt es grundsätzlich mal 4 Verfahren:

VNet Peering
VNet-to-VNet (V2V)
Site-to-Site (S2S)
ExpressRoute(s) (nur der Vollständigkeit halber hier, würde aber zu weit führen)

Schauen wir uns also die Möglichkeiten mal an...

VNet-Peering

Eine Voraussetzung für VNet-Peering ist, dass sich beide VNets in derselben Region befinden. Da dies bei AZure und AZure Deutschland offensichtlich nicht der Fall ist, müssen wir das hier auch nicht weiter betrachten. Wen VNet-Peering trotzdem interessiert, der findet hier einen tollen Artikel dazu.

VNet-to VNet (V2V)

VNet-toVnet (V2V) ähnelt dem im folgenden Abschnitt beschriebenen S2S, nur liegen hier beide VNets mit ihren Endpunkten in Azure. Man kann also V2V zum Beispiel verwenden, um Netze in unterschiedlichen Azure-Regionen verbinden zu können, selbst wenn diese in unterschiedlichen Subscriptions angelegt sind (dann halt nur via PowerShell, aber wen stört das schon...). Das Aufsetzen ist super einfach und hier prima beschrieben, aber leider müssen für V2V beide Subscriptions innerhalb der gleichen Azure Umgebung liegen, also beide in Azure oder beide in Azure Deutschland. Damit scheidet V2V für unsere geplanten Zwecke auch aus...

Site-to-Site (S2S)

Normalerweise verwendet man S2S, um zwischen Azure und der lokalen (on-premise) Netzwerkumgebung einen verschlüsselten Tunnel herzustellen. Man vereint beide Netzwerke also zu einem, indem man jeweils ein Gateway definiert und beide mit den Infos versorgt, wo sich der andere Endpunkt befindet und wie man miteinander redet (IPSec Parameter, Adressen etc). Auch hier gibt es eine einfach nachzuvollziehende Anleitung, von der wir hier nur in Stichworten die Reihenfolge der notwendigen Schritte betrachten:

Virtuelles Netzwerk erstellen
Adressraum definieren
Subnetze erstellen
Gateway-Subnetz erstellen
Gateway für VNet erstellen
Gateway für lokales Netz erstellen (quasi der Platzhalter für ihr lokales Gerät)
lokales VPN-Gerät konfigurieren
Verbindung herstellen

Um VNets zwischen Azure und Azure Deutschland zu koppeln, bereitet man in beiden Umgebungen alles vor (Schritt 1-5 aus obiger Liste), um das VNet mit einem normalen VPN-Gerät zu verbinden, und gibt dann einfach die beiden Gateways bei der jeweils anderen Konfiguration als Partner an (Schritt 6). Oder anders ausgedrückt: Statt Schritt 7 wird einfach nochmal Schritt 1-6 in der anderen Umgebung durchgeführt. Man tut also quasi so, als ob der andere Endpunkt ein on-premise Gateway ist. Nachdem beide angelegt sind, führt man Schritt 6 in Azure aus und gibt als Adresse die öffentliche IP des Gateways in Azure Deutschland an, und noch einmal Schritt 6 in Azure Deutschland mit Angabe der öffentlichen IP des Azure-Gateways. Und dann direkt noch Schritt 8, und das war's. ALles klar? Nein? ok, dann hier nochmal:

Schritt 1-5 für Azure durchführen
Schritt 1-5 für Azure Deutschland durchführen
Schritt 6 in Azure mit Eingabe der öffentlichen IP des Gateways in Azure Deutschland (aus dem vorherigen Schritt)
Schritt 6 in Azure Deutschland mit Eingabe der öffentlichen IP Adresse des Gateways in Azure
verbinden mit Schritt 8 (und Schritt 7 entfällt)

Ab sofort können dann VMs, die man in einem der beiden VNets anlegt, über den IPSec-Tunnel mit ihren IP-Adressen miteinander kommunizieren.

Caveat

Zwischen V2V und S2S gibt es Unterschiede bei den Preisen für Netzwerkverkehr. Bitte unbedingt vorher nachlesen! Der Tunnel selbst führt über das normale Internet, daher sind Ausfälle oder schwankende Bandbreiten nicht auszuschließen, also genau wie bei S2S-Verbindungen zwischen Azure und on-premise.