This is an ongoing series on Window’s Azure. The series starts here, and all code is located on GitHub: https://github.com/mmooney/MMDB.AzureSample.

So in some previous posts we covered how to deploy Azure Cloud Services via Powershell and also via C# code using the MMDB.Azure.Management library.

Now, we’ll cover a quick and easy way to configure and push Azure Cloud Service projects with a single command and configuration file.

Sriracha v2.0

First, to give you some context, we been rebuilding large parts of our Sriracha Deployment System to make it more modular, so you can more easily leverage individual pieces without having to install the whole system. It’s still very much a work in progress, but our goal is to steady release chunks of useful functionality as they become available.

One things I’ve needed for a while is a quick command line interface to deploy whatever I want whenever I want. Sure, the traditional Sriracha/Octopus/BuildMaster model is great for scenarios when I can set up a server to catalog out releases, but sometimes you just need a script to push something somewhere and you want it to be as simple as possible.

There is a major design change in the new Sriracha system. Previously, you couldn’t use anything in Sriracha unless you installed the whole system, but there was a lot of great functionality trapped in there. This time around, we are building each type of deployment task as standalone libraries that can be executed through a simple command line tool first, and then the broader Sriracha system will then leverage these standalone libraries.

Deploying To Azure In 3 Steps

First, you’ll need an Management Certificate for your Azure account to be able to connect through their REST APIs. If you don’t have that yet, check out the Authentication section of the last Azure post for steps to get your Subscription Identifier and Management Certificate values from the Azure publish settings.

The idea is pretty simple:

We’ll download a command line tool into our solution from Nuget

We’ll update a configuration file with the info specific to our project

We’ll run the command line tool to execute the deployment.

For this demonstration, we’ll be using the MMDB.AzureSample project we’ve used in earlier Azure posts. Feel free to pull down the code if you’d like to follow along.

Now we have our solution open, the first thing we’ll do is pull down the Sriracha.DeployTask.Azure package from NuGet.

PM> Install-Package Sriracha.DeployTask.Azure

This will create a SrirachaTools\Runners\Azure directory under your solution. In there will be sriracha.runner.exe, along with a bunch of DLLs.

You’ll notice of those files is “Sample.DeployCloudService.json”. Let’s put a copy of that named “MyDeployCloudService.json” and put it in the root of our solution and open it up:

You’ll see a whole bunch of settings in here. Some of them are required, but most of them are optional. We’ll add the bare minimum for now:

{ "AzureSubscriptionIdentifier": "ThisIsYourAzureSubscriptionIdentifier", "AzureManagementCertificate" : "ThisIsYourAzureManagementCertificate", "ServiceName" : "AzureViaSriracha", "StorageAccountName" : "srirachademo", "AzurePackagePath": ".\\MMDB.AzureSample.Web.Azure\\bin\\Release\\app.publish\\MMDB.AzureSample.Web.Azure.cspkg", "AzureConfigPath": ".\\MMDB.AzureSample.Web.Azure\\bin\\Release\\app.publish\\ServiceConfiguration.Cloud.cscfg" }

These values are:

AzureSubscriptionIdentifier and AzureManagementCertificate are the credentials you got from the Azure publish settings above.

ServiceName is the name of your service in Azure. If this service does not yet exist, it will be created. When we’re done, the cloud service will have the url http://[servicename].cloudapp.net/. Note: as you would guess with the URL, this service name must be unique, not just within your account, but also throughout all of Azure cloud services, so be creative.

StorageAccountName is an Azure storage account that we need to to hold the Azure package binary during the deployment. If this account doesn’t exist, it will be created. Note: the storage account name must be between 3 and 24 characters, and can only contain lower case letters and numbers.

AzurePackagePath is the location of your Azure Cloud Service package (*.cspkg). This can be created by right-clicking your Cloud Service in Visual Studio and selecting Publish

AzureConfigPath is the location of the Azure configuration file (*.cscfg) to deploy with your project, also created when you package your Azure Cloud Service. By default it will use the values from this file, but those values can be overridden during deployment using the configFile paramater below. We’ll cover the values in the configFile in the next post.

(Make sure you enter your own Azure Subscription Identifier and Management Certificate)

Then from a command line (or a batch file or NAnt script or whatever floats your boat), run the following:

.\SrirachaTools\Runners\Azure\sriracha.run.exe --taskBinary=Sriracha.DeployTask.Azure.dll --taskName=DeployCloudServiceTask --configFile=.\MyDeployCloudService.json --outputFormat text

The breakdown here is:

Run the Sriracha command line tool (sriracha.run.exe)

Use the taskBinary parameter to tell it which assembly has the deployment task implementation (Sriracha.DeployTask.Azure.dll)

Use the taskName parameter to tell it what actual task to use (DeployCloudServiceTask)

Use the configFile parameter to tell it where our config file lives (MyDeployCloudService.json)

Optionally use the outputFormat parameter tell it what type of output format we want back. Normally you’d want text, but you can use json if are piping it somewhere you want a parseable response.

You can find the full documentation of calling the Sriracha deployment runner here: https://github.com/mmooney/Sriracha2/wiki/Deployment-Runner

That’s it. Just run that command, and then sit back and watch the bits fly:

Now let’s go check out out the site, which again will be at http://[servicename].cloudapp.net, and there we go:

Now there are also some other cool things you can do with configuring your cloud service settings, instance counts, and certificates, which we will cover in the next post.