Tuesday, 29 March 2016

Auto deploy Azure Web Job with ASP.Net 5 and source control deploy


An updated version of this post that targets ASP.Net Core RTM is now available.

The content below here refers to RC1 which is not supported on Azure

At the time of this writing, there is no tooling to auto publish Azure Web Jobs with an ASP.Net 5 (DNX) website. You can do it with old-style websites, but not yet the new ones. The tooling is highly likely to appear as we get closer to release, but as of right now you have to take a few steps to set it up yourself, which is what I describe in this post. For clarity, what I am describing works only with source control deploy (git etc), not with publishing from Visual Studio.

This information will become obsolete nearer to the release of ASP.Net 5. If that has happened and I have not updated the post, please post a comment and I'll get on it.
Note that for very simple, self-contained web jobs, there may be a simpler approach (see http://stackoverflow.com/a/33291097/11534 for some thoughts). In this post I am catering for the scenario where your webjob references another project in your solution - though it'll work just as well if it doesn't.

In summary

You have to use a custom deployment script and insert an action to publish your webjob to the path that Azure looks for webjobs in; App_Data/Jobs/Continuous for continuous jobs. Azure will automatically pick up on content in that folder. And yes, it will happily overwrite a running webjob.

The reason we are publishing, using DNU Publish, is to effectively build the web job and get all it's dependencies. Of course, once RC2 is out we'll probably have to change the syntax.
If we had a very simple webjob that was self contained, you could just copy the files, as long as you added a run.cmd (see link above).

In detail

Full example on Github.

Prepare a site

  1. Set up a solution with an ASP.Net 5 Web site and a webjob written as a ASP.Net 5 / Core console app.
  2. Set up source control deploy to an Azure website. It shouldn't matter which type.
  3. Wait for the initial deploy of the site. 

Set up a custom deployment script

In this example, we will download the deployment script that Azure has created. There are ways to also do this with the Azure CLI, but the generated script is not quite the same at this point in time - which may or may not matter.
  1. Get the auto generated script
    1. Log in to the web app console at https://[yoursite].scm.azurewebsites.net
    2. Select Debug Console -> Powershell
    3. Navigate to site/deployments/tools
    4. Download the file deploy.cmd to the root of your solution folder
  2. Create a file in the root of your solution folder called .deployment with the following content
    command = deploy.cmd
  3. Modify your deploy.cmd file in the following ways
    1. Add a line like this near the top - just to make it easier to check that your custom script is being used (whatever you put after echo will be output in the log file)
      echo CUSTOM SCRIPT Start
    2. Near the middle of the file you will find a series of steps that are numbered. One of the steps will look like this;
      NOTE: The indented lines will be on a single line, the line breaks are only added here for readability
      :: 4. Run DNU Bundle
      call %DNX_RUNTIME%\bin\dnu publish
        --runtime %DNX_RUNTIME% 
        --out "%DEPLOYMENT_TEMP%" 
      IF !ERRORLEVEL! NEQ 0 goto error
    3. Below that insert these lines (updating the path with the actual path to your webjob in the solution)
      NOTE: The indented lines need to put on a single line, the line breaks are only here for readability
      :: 4.1 build web job
      echo Starting to build webjob
      call %DNX_RUNTIME%\bin\dnu publish 
        --runtime %DNX_RUNTIME% 
        --out "%DEPLOYMENT_TEMP%\wwwroot\App_Data\Jobs\Continuous\MyWebJob" 
      IF !ERRORLEVEL! NEQ 0 goto error

Check that it worked

Push your changes and wait for Azure to deploy, then look at the webjobs in the Azure portal. You should see your job there. In case you don't, have a look at the publish log file to see if there are any errors in there.