다음을 통해 공유

Getting a dashboard for local development with the WebJobs SDK

  • 아티클

This blog post describes how developers can do local development using the recently announced an alpha release of WebJobs SDK (aka SimpleBatch). The client side code is just pulling down JobHost class from the Microsoft.WindowsAzure.Jobs.Host nuget package, so you can develop inside a console app and run them locally. In fact, since the SDK is just a nuget package, you can include it in any type of application, such as a console app, class library, ASP.Net webpage (useful for your background processing!), or even an Azure Worker Role.  The ideal flow here is that you start with local development and then publish your code to run in Azure.

Although the client framework can be run anywhere, the SimpleBatch dashboard (eg, the cool website that gives you the awesome diagnostics) currently only runs as an Azure Websites Site Extension.  However, all communication between your app and the corresponding dashboard is done entire through an azure storage account, to which you provide the “AzureJobsRuntime” connection string or via the JobHosts ctor.

clip_image002

That means there’s a decoupling between where your JobHost runs and where the dashboard runs. You can run your JobHost locally while developing it, and still use the same dashboard from your site extension.

Multiple JobHosts can share the same logging storage account, so you can have a single SimpleBatch dashboard service multiple programs. However, be careful about multiple instances of your jobhost running when you use [QueueInput] attributes since the queue message will only go to the one instance that dequeues the message. Normally, that’s exactly what you want. But it can backfire if you’re trying to do local development of a [QueueInput] function and you have a cloud instance running that’s stealing all your messages.

 

How to get a “SimpleBatch” Dashboard for a given storage account?

This is just an Alpha release, and I’m expecting getting to the dashboard will get much easier in our Beta. But I wanted to share out a tip to use in the meantime.

 

1) Get the storage connection string you are using for JobHost to log to. This could be from “AzureJobsRuntime” connection string in your app.config or via the “runtimeConnectionString” parameter explicitly passed into the JobHost ctor.

The connection string is a single string that will include both the account name and password, and it looks something like this:

DefaultEndpointsProtocol=https;AccountName=???;AccountKey=???

 

2) Create a new Azure Web Site (that lives in the same datacenter as your storage account).

3) Point the site to that storage account by setting the “AzureJobsRuntime” connection string in the site’s “Configure” tab.

image

 

Save connection string

 

4) Get the site’s publish credentials (username and password) . Access to the SimpleBatch dashboard is protected using your site’s publish credentials. Get these credentials so you can log into the site.

You can get the credentials form the publish profile. Some steps from the tutorial:

 

  • Click the site’s Dashboard tab in the Azure Portal .
  • Under Quick glance, click Download the publish profile.
  • After you download the .publishsettings file, open it in Notepad or another text editor.
  • Find the first instance of userName= and userPWD=. These are the credentials you need. For example: <publishData><publishProfile profileName="webjobssite - Web Deploy" publishMethod="MSDeploy" . . . msdeploySite="webjobssite" userName="$webjobssite" userPWD="StjxBlJXnrfahHvbWs92MA6HKlvvLEZznr1EFA6kzSGKbY4v" . . .

Note that the publish file may have multiple username and passwords in it.

 

5) Go to the dashboard URL.  You can manually get this URL based on your site’s URL. If your site URL is:

     https://MYSITE.azurewebsites.net

Then the dashboard is a site extension that lives at:

     https://MYSITE.scm.azurewebsites.net/azurejobs

The transform here is:
    a. HTTP –> HTTPS
    b. The “.scm” in the URL
    c. The “/azurejobs”  suffix

This URL will also show up in the webjobs page. However, when doing local development, you won’t have a WebJob so it can be useful to know how to jump to the SimpleBatch dashboard directly. Save this URL for future usage.

Comments

  • Anonymous
    January 27, 2014
    The comment has been removed
  • Anonymous
    January 28, 2014
    Blake - Thanks for the feedback; we want to improve all of those.
  1. How did you end up diagnosing the non-public issue.
  2. Can you elaborate on what does Native PowerShell support mean?
  • Anonymous
    January 28, 2014
    I figured out that the methods needed to be public after grabbing the samples from CodePlex, confirming they'd build and run properly on my instance, then mutating them step by step till they matched my previous code.  The design requiring public methods makes sense - they are being invoked by another class.  It should have been obvious, but it wasn't.  Just surfacing a warning in the dashboard about inaccessible but attributed methods would seem a sufficient fix. The minimal PowerShell case that I was surprised to find wasn't already supported would be parity with bash and node.  Uploading a bare .ps1 should get it executed.  Given PowerShell's .NET base, better still would be a custom host that supports the same attributes on PowerShell functions that are currently used with compiled assemblies.  (Heck, if there aren't already plans for that, I might implement it myself.  It appear all the necessary bits to do so are public.)