So a little while ago (while I was using AWS with a global radio company) Microsoft made it possible to push up Azure content directly using Git. Project Kudu was cool but not really appropriate to what I needed.
Boy, has that changed. Turns out Kudu is a really useful debugging tool.
I’m using Azure to host a ten-year-old application using a PaaS Web app. The application is probably as simple as they get: a dozen or so Web pages that display pictures owned by the firm’s founder. A great application, as it happens, to get our teeth into how we might move bigger systems into Azure using immutable infrastructure, infrastructure-as-code, and group collaboration systems.
And yes, I’d love to rewrite the system. Indeed, apologies to colleague Paul for winding him up royally in a standup a couple of days ago saying I’d done just that over the weekend using NodeJS on the backend with Angular 2.0 at the front through a responsive SPA. Alas, not to be, we’d rather ‘lift-and-shift’ what we can.
We’re using Azure Resource Manager templates to do the deployments. These rather neatly encapsulate everything needed to host the application in a bunch of hierarchical JSON files.
The application itself is a *spit* Visual Basic front-end with some C# hiding behind it. Getting that to run in Azure turned out to be a Friday afternoon’s work: it’s a tribute to Microsoft and the good people on the Visual Studio team that a fairly poorly written application came right into .NET 4.6 without a hitch. A bit of PowerShell to create an msdeploy package ready for the ARM template and we were away.
That is, until we came to change application settings.
An Azure Web app is really an IIS instance hosted on what might be a virtual machine somewhere in the bowels of an Azure data centre. Time was when you could use Remote Desktop to connect to that virtual machine. Those days are gone.
So what’s a developer to do when they find that the Azure portal doesn’t appear to let them see the configuration settings in the application?
Project Kudu to the rescue!
So Kudu was originally designed, it seems, as a useful add-on to Azure that allowed direct access from Git to the file-system of a PaaS Web app. But it’s now grown up to have a UI of its own, hosted as part of every PaaS instance itself.
And it gives all kinds of useful and interesting metadata and debugging information about the PaaS site. Here’s a few things I’ve been using that have made me happy that I’ve got control of my Azure PaaS site. Because, after all, don’t developers just like control of their technology?
Getting to Kudu
Add ‘.scm’ before the ‘.azurewebsites.net’ in the URI for the PaaS Web site. Or, if you prefer, in the Portal, choose Tools from the Web app blade:
Get to Kudu from the Web app’s Tools blade thingy.
The Kudu UI itself is a bit “My First ASP.NET Bootstrap Themed Application” but what it offers is awesome. So don’t be put off.
For Web apps deployed (as mine is) through the msdeploy extension to ARM this isn’t terribly useful. It just confirms what we’ve seen already which is that the Azure ‘Web app configuration’ settings are Something Else other than the configuration settings we’d expect in our Web application. Where’s my lovely web.config settings? Not here.
Now we’re getting somewhere. Under System Info we have the line
IIS command line: D:\Windows\SysWOW64\inetsrv\w3wp.exe -ap "~1%%%-%%-%%-0-0-240" -v "v4.0" -a "\\.\pipe\iisipmd9631bf6-828f-4517-a658-3d77ad7b9a91" -h "C:\DWASFiles\Sites\#1%%%-%%-%%-0-0-240\Config\applicationhost.config" -w "C:\DWASFiles\Sites\#1%%%-%%-%%-0-0-240\Config\rootweb.config" -m 0 -t 20
The IIS worker process takes command line options? Yes: and -w specifies an alternate root Web configuration. As we can see this is buried away off in the c: drive; it’s explicitly not the one we’re using. (-a, -ap and-v aren’t documented, some day I’ll figure those out.)
Let’s try to read that alternate rootweb.config. The Debug Console lets us spawn up – a console session! We even get a choice of traditional CMD or PowerShell. And a neat little tree view where we can navigate graphically through the filesystem, download files, even remove them. And upload with drag-and-drop. Even edit in place in the browser.
But I can’t cd to the c: drive at all; it’s protected. However the “world” icon takes me to the LocalSiteRoot, which looks like the right place. And yes, in /config, there’s rootweb.config, with the settings as specified by Azure.
So it seems we have a hierarchical configuration.
And, sure enough, if I specify an application setting in Azure that has the same name as a setting in my web.config, the Azure setting takes precedence. So I can inject my application setting through an ARM template. Hurrah!
There’s loads more we can do with Kudu. For instance, we get better logging. That’s a subject for another post.
What have we found? Not least, Kudu is a great tool for finding out about Azure’s implementation under the hood. And we’ve figured out that we can alter Web site configuration on the fly by adding ‘duplicate’ application settings that have the same keys as our Web.config in the application.