Setting Up Kudu On IIS

Question

A couple of days ago, Microsoft released the engine they're using to do git deployments to Azure. I've had a task on my TODO list for a while to get that kind of functionality set up on my DEV IIS server, so I'm interested in trying out Kudu for that purpose.

The "Getting Started" document shows how to run the web front-end, but everything in there uses "http://localhost:PORTNUMBER" type URL's for git repositories, site URL's, etc.

I realize this is probably getting too far ahead of them, but I'm wondering if anyone has pointers for how to set it up using real domains on "regular" IIS instead of all of the localhost bits?

Answer 1

This is an old question, so I'm giving an updated answer with more current info since I just worked through setting up Kudu on an internal deployment server. The currently selected answer only deals with if you are directly running Kudu from within a development environment.

If you are deploying to a "production" type environment and don't want to install Visual Studio on the target server, there is a good guide on the project website on github.

https://github.com/projectkudu/kudu/wiki/Deploying-to-a-server

On the target server, you will need to install:

• MSBuild ( http://go.microsoft.com/fwlink/?LinkId=309745 ) - comes with Visual Studio
• NodeJS ( http://nodejs.org )
• Git ( http://git-scm.com/downloads )

Back on your development machine, clone the git repo and build using the "build.cmd" file, following instructions in the above link.

In running build.cmd I got several test failures which blocked the build from producing artifacts. These were all related to Mercurial, which we don't use. Installing a Mercurial client didn't make them magically go away, so I disabled the tests rather than sink a bunch of time into debugging my environment.

Your build output will indicate the failures. I disabled by commenting out the [Fact] attribute. These are the tests I disabled:

• tests/Kudu.Core.Test/HgRepositoryFacts.cs (all tests)

Once you have a successful build that has created all the items in the artifacts you can move to deploying the Kudu website and web service code. The below instructions are for setting up a distinct web application instance, rather than dumping everything in c:\inetpub\wwwroot, which is how the instructions read.

1. Copy "artifacts\Release\KuduWeb" to the target area on the server where your website will run from. I run my kudu install with a separate host header, but you could as easily use a separate port or run as the root website. This directory will be the root for your web application.

2. Create an empty "App_Data" folder immediately under the KuduWeb folder.

3. Copy "artifacts\Release\SiteExtensions\Kudu" to the same level as the folder in step 1 and rename to "Kudu.Services.Web". This location is set as a relative path in the KuduWeb web.config file - setting serviceSitePath.

4. Open IIS Admin and create a website pointing to the "KuduWeb" folder from step 1.

5. Configure the app pool from step 4 to run as "LocalSystem". This is required to manage IIS Sites.

6. Create a new folder "apps" at the same level as KuduWeb. This is where deployments will be sent. Note: this location is controlled in the KuduWeb web.config file - setting "sitesPath"

7. Change filesystem permissions to grant "Users" full access to the "apps" folder created in the above step.

On starting my Kudu website, I got the following error.

Parser Error Message: Could not load file or assembly 'System.Web.Mvc, Version=5.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.

For some reason it didn't copy the appropriate MVC version into the deployment artifacts.

If you hit this error, the MVC 5 file can be obtained via NuGet. I found that my source code was built against 5.1.0, so this is the appropriate link:

https://www.nuget.org/packages/Microsoft.AspNet.Mvc/5.1.0

In order to extract the dll, I set up a new dummy project and used NuGet to pull down the dll via the package manager console.

Install-Package Microsoft.AspNet.Mvc -Version 5.1.0

Once you get the binary, copy it from package directory ( .\packages\Microsoft.AspNet.Mvc.5.1.0\lib\net45\System.Web.Mvc.dll ) to the website bin directory on the target machine.

At this point you are up and running. Use the web interface to create your application. It will create a subfolder under the "apps" directory with a tree that should be self explanatory. It will also have created two new websites for your application:

• kudu_{your-app-name}
• kudu_service_{your-app-name}

In a production situation, you should create an additional website running on appropriate port/host header that points to: .\apps\\site\wwwroot

Now you can add a git remote for your deployment. Go to your source location in a git console (ex: Git Bash) and add the remote as identified by Kudu. Note: you may need to change localhost in the url to be the appropriate server name.

git remote add deploy http://:52711/your-app-name.git

Push your code to the new "deploy" remote and see what happens. You should see all the normal push messages, plus the build output.

git push deploy master

My initial push failed to build and deploy due to "node" not being recognized. It was in the path, so a server reset convinced the path environment variable to be refreshed. You may find additional errors to work through. For instance, I had an issue with MSBuild being imported and causing a hiccup.

error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\Visual Studio\v11.0\WebApplications\Microsoft.WebApplication.targets" was not found.

YMMV, but these are all solvable problems now. Good continuous deploying!

Answer 2

The project automatically sets up two websites on IIS for each application you add using the web front end. Kudu doesn't automatically map the bindings for them but it's relatively easy to open IIS and find the two sites named "kudu_appname" and "kudu_appname_service". The service website is the one that you point GIT too and the other one is the site itself. Just add public bindings to them by right-clicking and "edit bindings". You can then add public hostnames to them.

This is the easy part. The hard part that I'm still working on is getting authentication working so any random Joe isn't able to push to my kudu repository!