If you prefer to use PowerShell to interact with Azure and you are working with Service Fabric, today is your lucky day! Technically, //Build held a couple weeks ago was your lucky day since that’s when these were released but today is when I’m getting around to writing this post.
Announced a couple weeks ago, there are some new cmdlets that allow you to do cluster management. Tasks such as creating a cluster, adding/removing a node, adding/removing a node type, changing reliability or durability, things like that, are now possible using PowerShell. As of today, here are the new commands, currently at v 0.1.1:
For the latest documentation, check out the docs.
Admittedly, I’m not a huge PowerShell user. But, I wanted to at least give these a quick test run. Especially focusing on the New-AzureRmServiceFabricCluster command as that lets us now create a new cluster without writing an ARM template! Pretty cool…for the scenarios where it supports the customizations we need. More on that later. I mentioned I wasn’t a huge PowerShell users, and by that I mean to say I didn’t even have the Azure PowerShell SDK installed on my main machine. So I went off to install it. Just my luck, the first install didn’t go so well as when I tried running some of these new commands I got an error saying I needed to run Import-Module on AzureRM.ServiceFabric. Well, when I did that I got this error:
Import-Module : The module to process ‘.\Microsoft.Azure.Commands.ServiceFabric.dll’, listed in field ‘NestedModules’ of module manifest ‘C:\Program Files (x86)\Microsoft SDKs\Azure\PowerShell\ResourceManager\AzureResourceManager\AzureRM.ServiceFabric\AzureRM.ServiceFabric.psd1′ was not processed because no valid module was found in any module directory.
Indeed, the dll it was looking for didn’t exist. After some unsuccessful troubleshooting I gave up and removed the SDK and reinstalled. That time it worked.
Create a New Cluster
Starting with Hello World, I wanted to create a new cluster. Nothing fancy, just following one of the examples given in the help documentation. Updating my script, I ended up with this (watch for wrapping if you copy/paste):
$pwd=“OneSuperSecret@99” | ConvertTo-SecureString -AsPlainText -Force
Write-Output “create cluster in ” $clusterloc “subject name for cert ” $subname “and output the cert into ” $pfxfolder
New-AzureRmServiceFabricCluster -ResourceGroupName $RGname -Location $clusterloc -ClusterSize 3 -VmPassword $pwd -CertificateSubjectName $subname -CertificateOutputFolder $pfxfolder -CertificatePassword $pwd -OS WindowsServer2016DatacenterwithContainers
That creates a 3 node cluster using the Server 2016 w/Containers OS and secures it by creating a new cert and storing it in Key Vault along with downloading it locally so I can use it. (Install it locally before trying to access Service Fabric Explorer.) It took around 10ish minutes and resulted in a usable cluster, all without writing a single line of JSON!
And here’s the Resource Group view, showing all of the artifacts it created for me:
A few things to point out:
- While this command does create a secure cluster, notice it created the Key Vault in the same Resource Group. Not really the best deployment scenario, but it gets the job done. If you’d prefer to use an existing Key Vault, use one of the other options of the same command to create a new Key Vault Resource Group. Examples are shown in the help.
- For some reason, it created the cluster with version 5.5.216 of the Service Fabric runtime, whereas the latest version is 5.6.210 (and preferred when using Windows containers). Hopefully this will get fixed soon.
- If you don’t like the naming scheme (does “l5nbd6qsesaeu100” mean anything to you?), you’ll need to create a JSON template.
- For control over many other options (such as deploying into an existing VNET), you’ll be back in JSON.
- Just because you’re back in JSON, you can still leverage this command by passing in your template file (see the other examples).
All-in-all, I think this is a great start and I like where the tooling is going. I can’t wait to see these capabilities grow and, hopefully, be adopted over in the CLI world.