I want to migrate my server from azure app service to kubernetes with zero downtime. How is it possible? I have a custom domain. Website is containerized using docker. And i want to seamlessly redirect the web requests from app service to kubernetes.
I am sorry, its really easy, one just has to make the configure the new resouce accept incoming request from the custom domain and then make the custom domain point to the new resource.
I was confusued because I thought one has to validate domain ownership everytime one configures custom domain in azure.
Related
I need to have the same Azure App Service Custom Domain running in different App Services on the same region. Is that possible?
Custom domians are based in DNS, only one record should be pointing to one App Service, so I think it would not be recommended to have same custom domain in multiple App Services in the same region. Being said that, it works for different regions and it is common to see this deployments for instance behind Traffic Manager or Azure Frontdoor.
In order to do this in the same region is a bit more challenging as the only way is to make sure your App Service goes to a different webspace (https://learn.microsoft.com/en-us/azure/app-service/app-service-plan-manage#move-an-app-to-another-app-service-plan). So basically to make sure it goes to a different webspace you need to create a new Resource Group and a new App service Plan, then you can create the specific App Service and add the custom domain. In order to make sure they are in different webspaces, check if the Inbound IP is different.
I am getting to the point of my project where I am ready to deploy it online with my custom domain via Azure once I make the upgrade from my Free Subscription.
So a little context, I have 1 web app service and 4 api services and each one is hosted in a separate app service such as:
www.sitename.azurewebsites.net
www.sitename-api1.azurewebsites.net
www.sitename-api2.azurewebsites.net
www.sitename-api3.azurewebsites.net
www.sitename-api4.azurewebsites.net
And the above web app communicates to all 4 api's and some api's may or may not talk to another. (Would have loved an application gateway so hopefully I'll be changing this architecture later down the road).
So as I get ready to associate my domain to the services, the web container seems pretty straight forward to me as it just becomes www.sitename.com, but I am a little confused about the api services. The way I am thinking about this is that each api service will be in it's own subdomain, such as:
www.api1.sitename.net
www.api2.sitename.net
www.api3.sitename.net
www.api4.sitename.net
where I believe I can register my SSL and domain to each app service somehow, but this leaves me with a few questions.
Do I host each api in a subdomain using the same domain as the web
app, or is there a different way preferred like where I host them
all on the same domain with different exposed ports per API and web
listening 80/443, or maybe just use the IP address of the api app
service and allow www.sitename.com as the origin for CORS?
I am assuming that since I am associating my SSL cert to the web
service, I will need to do the following on the api services?
Would it be better (and still affordable) if I just had a VNET
associated to the app services and the domain only registered with
the web app?
Any insight into this would be greatly appreciated on how I can establish communication between my app services with my custom domain and SSL as I am fairly new to this part of the stack, but excited about learning!
As I known, on Azure cloud, there are two services can help to manage your APIs deployed on multiple app service containers: API Management and Application Gateway.
The Premium tier of API Management has the feature for multiple custom domain names, please see the offical document Feature-based comparison of the Azure API Management tiers as the figure below.
You can refer to the quick start tutorial of Create a new Azure API Management service instance and other related documents to kown how to.
"Azure Application Gateway is a web traffic load balancer that enables you to manage traffic to your web applications." said in the introduce What is Azure Application Gateway?. And as the figure of its architecture below, "With Application Gateway, you can make routing decisions based on additional attributes of an HTTP request, such as URI path or host headers. For example, you can route traffic based on the incoming URL. So if /images is in the incoming URL, you can route traffic to a specific set of servers (known as a pool) configured for images. If /video is in the URL, that traffic is routed to another pool that's optimized for videos."
I recommended to use Azure Application Gateway which be a good choice to manage multiple app services and expose the unified urls of APIs.
I have two app services. One for UI and one for web api. I need to create a DNS so that I should be able to access like www.example.com/ui and www.example.com/api. Please let me know anyone how to achieve this without virtual directory concept.
Thanks
You cannot achieve this purely with DNS. DNS knows nothing about routes, only domain names. So www.example.com must resolve to one service, which should be your reverse proxy, maybe Application Gateway?
Here's the tutorial on hosting two apps behind Application Gateway: Tutorial: Create an application gateway that hosts multiple web sites using the Azure CLI.
Multiple-site hosting enables you to configure more than one web site on the same application gateway instance. This feature allows you to configure a more efficient topology for your deployments by adding up to 20 web sites to one application gateway. Each web site can be directed to its own pool. For example, application gateway can serve traffic for contoso.com and fabrikam.com from two server pools called ContosoServerPool and FabrikamServerPool.
How can I maintain users to get redirected to the same Server in a Load-Balanced Web Apps
Your answer will be very helpful
Traffic Manager directs the user to the appropriate region, but assuming you have your web app scaled out to at least two instances, ARR (Application Request Routing) is what directs each request to a specific instance of the app.
ARR has a feature called Session Affinity which is enabled by default. It uses an ARRAffinity cookie to attempt to route all requests from a client to the same instance of your application. I say "attempt" because, the cloud being what it is, instances of your app can come and go due to autoscaling or maintenance activities.
Your best bet is to use Azure Traffic manager. When setup correctly it will route users to the proper cloud service in their region and provide them with the best possible experience.
More information can be found here
Azure Traffic Manager
Azure Traffic Manager Documentation
Traffic Routing Methods
I have a custom domain www.abc.com configured for web app webapp-a, and I'd like to transfer it to webapp-b without downtime.
If I try to add the domain to webapp-b, I am getting
The host name www.abc.com is already assigned to another Azure website: webapp-a
It there a way to let webapp-a continues to serve the requests, until the DNS cache expires?
Edit: The domain has IP based SSL binding, and the DNS is caching the virtual IP.
I faced the same issue, and was able to solve it in a tricky way.
I created new App Service Plan (previously known as Web Hosting Plan), and assigned "new" Web App to it (you can do it via new portal, or you can create Service Plan during Web App creation).
Then, I was able to assign the same host name to Web Apps in different hosting plans.
Thinking about this, I feel it logical: most probably Service Plan is mapped to physical IIS machine, and you cannot have two sites with the same host name in the same IIS for the obvious reason.
After migration from one DNS to another is done, you can remove unused Service Plan (as you basically pay for each separately).
According to a blog post by the Azure App Service Team in June 2017, it would appear that Azure now supports adding the same custom domain to multiple web apps:
There are scenarios where a customer would like to add the same hostname to multiple web apps in the same subscription, having a geo distributed website is one example. Our custom hostname feature allows you to bypass validation for hostnames that have already been validated. You only need to verify domain ownership when you add a hostname for the first time. For all other apps in the same subscription, you can add the same hostname without creating any DNS records.
You can read the entire blog post at https://blogs.msdn.microsoft.com/appserviceteam/2017/06/21/custom-hostnames-with-app-service/. The quote above was taken from the Adding the same custom hostname to multiple web apps section.
This should help in scenarios such as this where you want to transfer a custom domain name from one web app to another. You can simply add the same custom domain name to both web apps, add any required SSL bindings, and then change the DNS to point to the new web app. As the DNS change propagates, traffic should gradually move over to the new web app without any downtime.
I've tested this myself in the North Europe region and had no problems. Both web apps were in different App Service Plans. I have not tested this scenario with both web apps in the same App Service Plan. Bear in mind that if you're using IP addresses/A records in your DNS, you'd need both web apps to have different IP addresses for the DNS to be able to differentiate between your web apps.
Try assigning the domain to Azure Traffic Manager and have the traffic manager forward the request to the second site. Azure Traffic Manager and Web Apps are two different systems so you might be able to assign the same domain name to a web app and a traffic manager.
Once the DNS cache has expired remove the domain from the old Azure web app and add it to the new one, then finally delete the Traffic Manager account.
Option 2
Set the TTL to something very small, say 5 seconds (I believe your hostname provider should let you set that up), wait for the new TTL to propagate through all the caches. Then switch the custom domain from one app to another, and set the TTL back to it's original value.
This will result in just a few seconds of downtime for any customers, but if you do it at a low-traffic time the effect shouldn't be too bad.