In my previous post, I spoke about the deployment aspects of the Azure App Service, and how in conjunction with Kudu, F# and FAKE, we can utilise a SCM-based solution for deployment that can essentially follow the exact same build process as is performed locally.

In this post I want to discuss the process behind hosting Suave (or indeed any application that listens to HTTP traffic) in the Azure App Service.

What is Azure App Service?

The Azure App Service is a broad service that contains multiple “sub services”: –

Web apps

Logic apps

Mobile apps

API apps

We’re interested in Web Apps in the post. If you’ve used Azure before, and had an ASP .NET web application, it was an easy decision to pick the Azure App Service as the service to host your app. What’s not so well known – and I admit that until I spent some time looking into it I just assumed that it wasn’t possible – is that you can use the service to host any executable application within the IIS process, and have the app service simply act as a passthru, routing HTTP requests through to your application and back again.

Why would you want to do this though? Why not just use a Cloud Service or raw VM? I would direct you to my previous post on Azure services but in a nutshell, the app service provides a higher-level service than either of the others – think of it as IIS-as-a-service – with support for: –

SCM-based deployment e.g. GitHub, BitBucket etc.

Metrics and alerting services

Scale up application size on demand

Automatic load balancing with scale out on demand or based on metrics such as CPU

Turn-key authentication features

Slots – deploy different versions of code to test before flipping to live

A/B testing support

Web jobs

So, basically a lot of things that you’d need to manage yourself in a production web application all come out of the box. And the good thing is that you can get all of these features with e.g. a Suave web application as well – it’s not just for ASP .NET.

Creating an Azure Web App

To create a web app, simply log into the Azure portal, select New from the left hand side menu, choose Web and Mobile and finally Web App. Fill in the details, confirm, and you’ll end up with an empty website that you can browse to and receive a stock Azure Website page. So now we have an empty application, how do we put our code into the app?

Binding Suave to an Azure Web App

The first thing you’ll need to do is get your code into the Azure web app that you’ve just created. There are a number of ways that you can achieve this.

Firstly, you can use SCM-based deployment, which I detailed in my previous post. But a quicker way to go for a “one-off” deployment is simply to FTP in and copy the files across. To do this, in the Portal, navigate to your empty web application and hit the Get Publish Settings option from the menu bar of the web app pane. This will give you an xml file, inside of which are the FTP address and credentials. You can then FTP in and simply copy up your application into the wwwroot folder.

Note that you can also use HTTP as well as MS Web Deploy (either through the command line or Visual Studio), although I suspect that that would require making your Suave application appear as a web app through custom project GUIDs.

Configuring the Azure App Service

A standard Suave application (at least, all the examples I’ve seen) run as either .fsx scripts or executables. Indeed there are already a few examples of running Suave within an Azure website – and I should give credit to Scott Hanselman and Steffen Forkmann for getting the basic Suave example up and running here. The majority of what I’ve done from here is based on that work – the difference is that rather than hosting FAKE itself which runs a simple Suave application within an .fsx file, I’m not using FAKE as a host at all (although I do use FAKE for the build stage as per my previous blog post). Instead, all I’m doing is hosting an .NET executable that launches Suave.

So how do we do it? Bear in mind that the Azure App Service is essentially just IIS as a managed service. It’s actually rather straightforward once you know what’s required, which is simply to instruct IIS to redirect all traffic to our Suave application. How do we do that?

Adding a custom web.config

In addition to your standard executable app.config which contains all the config and binding redirects etc., you need a slimline web.config which is used by IIS to startup and then redirect traffic to your Suave application. It doesn’t contain much: –

<?xml version="1.0" encoding="UTF-8"?> <configuration> <system.webServer> <handlers> <remove name="httpplatformhandler" /> <add name="httpplatformhandler" path="*" verb="*" modules="httpPlatformHandler" resourceType="Unspecified"/> </handlers> <httpPlatform stdoutLogEnabled="true" stdoutLogFile="suave.log" startupTimeLimit="20" processPath="%HOME%\site\wwwroot\SuaveHost.exe" arguments="%HTTP_PLATFORM_PORT%"/> </system.webServer> </configuration>

The key parts to take away from this are: –

Remove the standard HTTP Platform Handler and replace with another one. Specify to use SuaveHost.exe (my application name) as the application in the processPath attribute. Pass in an argument to the application – the internal port that traffic will come in on using the %HTTP_PLATFORM_PORT% variable. You can pass in multiple arguments here, just ensure they are space separated.

Handling arguments in Suave

Now that we have hooked our application into IIS, in Suave we simply run our application and take in the port number as an argument: –

[<EntryPoint>] let main [| port |] = let config = { defaultConfig with bindings = [ HttpBinding.mk HTTP IPAddress.Loopback (uint16 port) ] listenTimeout = TimeSpan.FromMilliseconds 3000. } // rest of application

That’s it!

Managing Suave through Azure App Service

Now that you have your application up and running in Azure, what can you do? Well, you can log into the Azure portal and get some metrics of your website immediately as a configurable dashboard: –

The charts are configurable, so you can select which metrics you’d like to show e.g. which HTTP codes etc. over what time period. We can also look at the process explorer – and sure enough, there’s our SuaveHost.exe application: –

And we can even drill into the process: –

Conclusion

Of course, what I’ve shown you above is just scratching the surface of what you can do with Azure. It’s possible to do all the other things I mentioned at the start of this post, such as scale up the size of the web server, scale out to multiple instances, create multiple deployment slots etc., all from within the portal. Or perhaps you’d like to set up custom alerts based on any of the dashboard metrics over a certain period of time e.g. “> 50 HTTP 404s in the last 5 minutes” and send an email / hit an HTTP endpoint etc.? No problem – that’s supported out of the box.

It’s actually all incredibly easy and really allows you to simply focus on the work of developing an application and let Azure manage the infrastructural challenges. In fact, I can’t imagine self-hosting (or self-managing) any web-facing application when you have a service like this available. Hopefully I’ve shown though, that’s it’s not just the stock ASP .NET website that can be run through Azure web apps – we can host Suave as well without much effort at all.

The source code that was used for this post is available here.