Azure WebApp : Checking the deployed WebApp file system

 

So at work we are using Azure a lot, one of things we use a heck of a lot are web apps. We have a lot of these, some full blown web sites, some simple Service Stack REST APIs. We orchestrate the deployment of these Azure WebApps via the use of standard VSTS build/release steps, and the use of some custom ARM templates.

 

Just for a quick diversion this is what ARM templates are if you have not heard of them

 

What is Azure Resource Manager

Azure Resource Manager (ARM) allows you to provision your applications using a declarative template. In a single template, you can deploy multiple services along with their dependencies. You use the same template to repeatedly deploy your application during every stage of the application life cycle.

 

This post is NOT about ARM templates, but I just thought it worth calling out what they were, incase you have not heard of them before.

 

So what is this post about?

Well as I say we have a bunch of WebApps that we deploy to Azure, which most of the time is just fine, and we rarely need to check up on this automated deployment mechanism, it just works. However as most engineers will attest to, the shit fairy does occasionally come to town, and when she does she is sure to stop by and sprinkle a little chaos on your lovely deployment setup.

 

Now I don’t really believe in fairies, but I have certainly witnessed first hand that things have ended up deployed all wrong, and I have found myself in a situation where I needed to check the following things to make sure what I think I have configured is what is actually happening when I deploy

 

1. VSTS steps are correct
2. VSTS variables are correct
3. Web.Config/AppSettings.json have the correct values in them when deployed

 

Items 1 AND 2 from that list are easy as we can check that inside VSTS, that is fairly ok. However item 3 requires us to get onto the actual deployment file system of the VM running the Azure WebApp that we tried to deploy. This is certainly not possible (to my knowledge) from VSTS.

 

So how can we see what was deployed for our Azure WebApp?

So it would seem we need to get access to the filesystem of the VM running the Azure WebApp. Now if you know anything about scale sets, and how Azure deals with WebApps you will know that you can’t really trust that what is there right now in terms of VMs is guaranteed to be the exact same VMs tomorrow. Azure just doesn’t work that way. If a VM is deemed unhealthy, it can and will be taken away, and a new on will be provisioned under the covers.

 

You generally don’t have to care about this, Azure just does its magic and we are blissfully unaware. Happy days.

 

However if we do need to do something like check a deployment, how do we do that? What VM should I try and gain access too? Will that VM be the same one tomorrow? Maybe/Maybe not. So we cant really write any funky scripts with set VM host names in them, as we may not be getting the same VM to host our WebApp from one day to the next. So how do we deal with this exactly?

 

Luckily there is a magic button in the Azure Portal that allows us to do just what we want.

 

Say we have a WebApp that we have created via some automated VSTS deployment setup

 

 

We can open the web app, and drill into its blade and look for the Advanced Tools

 

 

Then select the “Go” option from the panel that is displayed in the portal. Once you have done that a new tab will open in your browser that shows something like this

 

 

It can be seen that opens up a Kudu portal for the selected Azure WebApp.

 

But just what is Kudu?

Kudu is the engine behind git/hg deployments, WebJobs, and various other features in Azure Web Sites. It can also run outside of Azure.

 

Anyway once we have this Kudu portal open for our selected WebApp we can do various things, the one that we are interested in for this post is the Debug Console –> PowerShell

 

 

So lets launch that, we then get something like this

 

 

Aha a file system for the WebApp. Cool. So now all we need to do is explore this say by changing directories to site\wwwroot. Then from there we could say have a look at the Web.Config (this is a standard .NET web site so no AppSettings.json for this one)

 

We could examine the Web.Config content like this say where we use the Get-Content PowerShell commandlet

 

 

 

 

Conclusion

So that’s it. This was a small post, but I hope it showed you that even though the VMs you may be running on from one day to the next may change, you still have the tools you need to get in there and have a look around. Until next time then….