Using Kudu and deploying apps into Azure

First published on MSDN on May 15, 2017

There are a number of ways to deploy your applications to Microsoft Azure Web Sites, there are also a number of ways to tie into the deployment process to aid you in Automation, Configuration, or Diagnosing issues with your deployment.

One of the super fast ways of deploying your development to pre production or testing is using Kudu.

Every Azure web site has an associated 'scm' service site, which runs both Kudu and other Site Extensions . Kudu is the central nervous system of a Microsoft Azure Web Site; it handles the Git integration to a Web Site as well as provides an API endpoint for programmatic access to app settings, deployment information, files, active processes, runtime versions, source control information, web hooks and web jobs. Kudu, itself, is a Site Extension which is provided with ever Web Site, you can access it by using the Source Control Management entry point

If your web site has URL http://mysite.azurewebsites.net/ , then the root URL of the Kudu service is https://mysite.scm.azurewebsites.net/ . Note the added scm token.

For mobile services, the site URL looks like https://myservice.azure-mobile.net/ , and the Kudu root URL is https://myservice.scm.azure-mobile.net/default.aspx .

Kudu isn't exclusively for Microsoft Azure. Read the docs on How to Deploy Kudu on Windows Server 2012 .

Kudu custom install

Have you forked kudu for your own purposes? Here's how you can deploy your custom fork of Kudu to Azure

Dashboard

The Kudu dashboard is the first page you will encounter on the SCM entry point, it displays information pertaining to your Web Site such as the build number of Kudu which is running, the current uptime of your site (this could display a value as low as a couple of seconds as your site may have been deallocated due to inactivity, unless the site has Always-On enabled).

Environment

The Environment tab in Kudu Dash shows some very valuable information including System Information, App Settings, Connection Strings, Environment Variables, PATH, HTTP Headers and Server Variables.

Debug Console

The Debug Console gives file explorer and graphical KuduExec experience which enables you to run command line tools against the Web Site.

Diagnostic Dump

Diagnostic Dump provides a zip file of all of the Diagnostic Data which is enabled under the Application Diagnostics header in the CONFIGURE tab of the Web Site.

Log Stream

Web Server Logging must be enabled for the Microsoft Azure Web Site or this page will fail to load.

Log Stream long-polling process which provides logging data from your Web Site if Web Server Logging is enabled under the Site Diagnostics header in the CONFIGURE tab of the Web Site.

Web Hooks

Allows URLs to be registered as Web Hooks. Information will be posted to the URL when events occur.

Command Line KuduExec

Prerequisites : Node.js

npm install kuduexec -g

Microsoft Azure Web Sites is a shared environment. The context of command line access is contained within a sandbox.

KuduExec enables command-line access to a Microsoft Azure Web Site. Simply call KuduExec and pass in the Source Control Management (scm) endpoint of the website as the first parameter.

kuduexec https://[site-name].scm.azurewebsites.net
Username: [deployment-user]
Password: [deployment-pass]

KuduSync

npm install kudusync -g

KuduSync is a tool for syncing files for deployment, will only copy changed files and delete files that doesn’t exists in the destination but only if they were part of the previous deployment.

KuduSync is responsible for file synchronization during deployment. It is called at the end of the default deployment process (you can customize the deployment script ) to move files between the %DEPLOYMENT_SOURCE% folder and the %DEPLOYMENT_TARGET% .

websites-dev$ kudusync [options]

-h, --help
output usage information
-V, --version
output the version number
-f, --fromDir <dir path>
Source directory to sync
-t, --toDir <dir path>
Destination directory to sync
-n, --nextManifest <manifest file path>
Next manifest file path
-p, --previousManifest [manifest file path]
Previous manifest file path
-i, --ignore [patterns]
List of files/directories to ignore
-q, --quiet
No logging
-v, --verbose [maxLines]
Verbose logging with maximum number of output lines
-w, --whatIf
only log without actual copy/remove of files
--perf
Print out the time it took to complete KuduSync operation

Notes:

• The scm service host name is not affected by the presence of custom host names in your site. It always has the pattern above.
  
• The scm site uses single sign on, so if you're already logged on to the Azure portal, you will be able to go directly to it without typing additional credentials.
  
• If you prefer not to use Single Sign On and instead use basic auth, you can go to http://mysite.scm.azurewebsites.net/basicauth ( https://myservice.scm.azure-mobile.net/basicauth for mobile services). The scm service will prompt you for credentials. Here, you can use either the user publishing credentials (same as you use for git), or the site level credentials. See Deployment-credentials for details.

Once you're in the Kudu service

The root of the Kudu service has links to various things that can be done from there, and are discussed elsewhere in this wiki. e.g., you can:

• Get the Kudu diagnostic dump
  
• Launch the diagnostic console
  
• See info about the runtime environment
  
• Navigate the REST API

Additional Resources

Azure Deployment Options http://azure.microsoft.com/en-us/documentation/articles/web-sites-deploy

Kudu Github https://github.com/projectkudu/kudu/wiki/Acce

Azure WebSite Cheat Sheet http://microsoftazurewebsitescheatsheet.info/