Here is a short „lessons learned“ blog post about a thing which: a) seems not have an updated blog post, stack overflow etc, b) wasted a day of my life and c) turned to be quite trivial once I figured out how to do it.
Basically, as Scott Hanselman blogged about a long time ago you might have users distributed around the globe in which case you would like them to use resources which are close to them and improve their perf. Or another use case is that auto-scale up/out capabilities of the single App Service are not enough and you would like to use multiple app services supporting your website.
Well if this sounds interesting, I have good news – like many other things with Azure this one turns out to be quite simple so let me show you how to set up SSL balancing with custom names using Azure Trafic manager.
Step 1 – create app services which will distribute the load
For the purpose of this blog post, I will create two app service: one in US and one in Europe data center with the idea that all of the users who are in US will be hitting the US app service and all the other users will use the EU app service.
There are many other use cases other than the typical geo distribution one like for example auto scale-out capabilities of a single app service are not sufficient, getting phased rollouts without using the slots, a/b tests, complying with the data sovereignty mandates etc…
Step 2 – create azure traffic manager endpoint
We need a single URL address which will then route traffic to the app services and one way to achieve that in Azure is by using the Azure Traffic Manager.
Hit that little plus, search for Traffic and – voila!
Two important things on this screen:
- name – defines the unique public URL which will be called by service consumers and which will then go to individual app services
- routing method – there are 4 different ways how the app service routing can be driven where the most commonly used is the performance one but just for the kicks, I am going to use in my post Geographic one.
Now open traffic manager endpoint and do yourself a favor, open configuration and enable https only traffic
Step 3 – map the app services to the traffic manager
We need to inform traffic manager where it can redirect the traffic – go to the Endpoints/Add
And there define what app service should be used by which geographical area.
As we said for this example US service will handle North America traffic and EU service the rest of the world.
This definition is specific to Geographic routing and it can be specified to smaller geographic areas – for example, you can have app service for the state of New York
Now quickly the other app service which should take all the traffic which is not from North America
And that’s it – if you would hit the traffic manager endpoint from different parts of the world you would see that different app services are handling the traffic
Is that it?
Well on most of the blogs this will be sufficient but as I always take care of both of my blog subscribers I will explain here how to take the things explained so far and elevate them to something really usefull in real world 🙂
Step 4 – Define CNAME mapping for the traffic manager
While you can use the url with its trafficmanager.net domain for demos, it is totally lame to use it in production for your product so we are going to define a CNAME mapping which will allow us to access it through our domain.
Here is how that setting looks like with my DNS provider
So everyone hitting blog-api.papiri.rs will be hitting the papiri-tm.trafficmanager.net which will then route traffic to the app services.
Step 5 – magic (define custom names for all of the app services)
In this step, we are going open all of the app services which are mapped to traffic manager and set their custom names to the same one mapped through DNS in step #5
The fact this works is magical as there were no DNS mapping defined for the app service itself but the validation passes. This works due to the fact that traffic manager is not a real load balancer but more of another DNS entry so the DNS mappings defined for the manager are valid also for the app services mapped to it!
Step 6 – add SSL bindings to the app service
We then go through each one of the app services and upload SSL certificate (Scott Hanselman recently blogged on how to get a free SSL cert for your site)
Once the SSL certificate is uploaded to the app service, we can define app service SSL binding
Step 7 – a final test that everything works fine
If you did all the steps, you should be done and you can hit your custom domain using https and verify the app service balancing of your custom domain using the www.whatsmydns.net
That’s it folks!