Working on a project where we are starting to use Deployment Slots in our App Services.
All our Prod apps are located behind Application Gateway, and we would like to also have our Slots located behind Application Gateway.
I understand we can not do this using "App Services" as target type in the Backend Pools as of now, but wondered if it is doable using "IP Address or FQDN" as target type.
I have tried to set it up, with various changes in the "HTTP Settings", Probe and so, but haven´t gotten it up spinning.
Can anyone confirm if this is possible, and have any tips on how this should be configured?
Thanks!
I was able to get this working on one of my slots.
Basically setup the listener with your necessary protocol, port cert, hostname, etc... I'm using multi-site listeners so I can have multiple URLs for the one AppGW/Public IP.
The rule points to the listenter, backend pool and appropriate http setting.
The HTTP setting should be configured to connect to your app service URL accordingly. I'm using the azurewebsite.net URL, so I use well known CA cert & override hostname from backend target:
The backend pool then points to the azurewebsites.net URL:
Make sure that GET / works on your app service and returns 200-399 HTTP status codes. Anything outside that range is a failure and the backend pool will be removed. If you need to create a custom health probe to a URL that will respond properly, or adjust the acceptable HTTP status code (if 401 or 403 due to required auth, then just override it with that for testing purposes for now).
I'm trying to do it again with a second slot and running into 502 errors from the App Gateway... However, I'm also waiting on DNS changes from my network team. My first one with my company domain works via hosts file edit, but the 2nd slot (which has 2 different URLs/listeners configured in the AppGW) doesn't want to work the same way for some reason.
Related
Is it possible to include a separate Azure App Service as part of another App Service?
For example lets say that I have a website called www.mycompany.com hosted in its own Azure App Service. I have another Azure App Service that I want to make it accessible by going to a specific URL in the first App Service.
So in other words when a request comes to www.mycompany.com/eu/ I want the content of this endpoint (/eu) to be served from the other app service. Would a load balancer work? The reason I want to do this is because the /eu endpoint has grown too big and I would like to separate that from the main site and host it on a separate app service. I hope my question is clear.
Thanks in advance.
For this purpose you could use Application Gateway.
In a certain sense it resembles a load balancer (it is a L7 LB indeed) as you indicated, but the product provides many additional features.
The following image, extracted from the product documentation, explains how it works:
Basically, as outlined in the aforementioned docs, when describing how an Application Gateway accepts a request (note they mention WAF in the explanation, an optional security threat prevention system):
Before a client sends a request to an application gateway, it
resolves the domain name of the application gateway by using a Domain
Name System (DNS) server. Azure controls the DNS entry because all
application gateways are in the azure.com domain.
The Azure DNS returns the IP address to the client, which is the
frontend IP address of the application gateway.
The application gateway accepts incoming traffic on one or more
listeners. A listener is a logical entity that checks for
connection requests. It's configured with a frontend IP address,
protocol, and port number for connections from clients to the
application gateway.
If a web application firewall (WAF) is in use, the application
gateway checks the request headers and the body, if present,
against WAF rules. This action determines if the request is valid
request or a security threat. If the request is valid, it's routed
to the backend. If the request isn't valid and WAF is in Prevention
mode, it's blocked as a security threat. If it's in Detection mode,
the request is evaluated and logged, but still forwarded to the
backend server.
The routing to one backend or another can be based on URL Paths:
You can find an example of this configuration in this related Microsoft article.
In your use case, you will need to define two backends, one for every App Service, and define routing rules as appropriate.
As indicated before, your DNS should point to the Application Gateway: it will handle the routing to one or other App Service based on the route, /eu/* or /*, provided by the client.
The order of the routes is important: once a rule is matched, it will be the one processed.
Application Gateway is a regional service: Azure Front Door leverages a similar functionality (and much more) globally.
Please, consider review the associated costs of these services.
I am answering my own question to hopefully help others in the same situation. This was simply done using a reverse proxy. This article explains everything you need to set it up - https://ruslany.net/2014/05/using-azure-web-site-as-a-reverse-proxy/
I have an Azure App Gateway connected to 3 different App Service apps all running as part of the same App Service Plan (3 different back-end pools). In the Backend Health section of the AG, one of the app/pool is constantly flipping between Healthy and Unknown states. I have checked the entire network configuration according to this article and everything seems to be configured properly.
I have configured ip restrictions on the app services according to this article specifying the subnet the AG resides in as allowed. I have also temporarily allowed my ip address and every time the health for the 1 app goes to "unknown", I am still able to access the app service using its native .azurewebsites.net url locally on my machine.
Any ideas how I can troubleshoot this?
Please check if below points help to work around the issue.
As a workaround initially,try to restart the application gateway after the backend is deployed .
Also check this discussion on github issue
Sometimes Appgateway will cache the response indefinitely and the fix
maybe "Dynamic DNS" which ensures that the "no existing domain" is not
cached on the Appgw.Also check for the fix using v16.
Also check this > similar issue which says to use custom domain names as the request looks for some domain.
I am trying to use azure frontdoor to access a nginx running in a kubernetes cluster.
I can reach the nginx instance on the public IP, but when trying trough azure front door i get a "The request URI is invalid" error.
The health probes also seem to be failing, even though i did not change any settings and can access nginx via the public IP.
Looking at the time where the backend is availible, i don't see any request to the backend:
I have setup my forwarding rules like this:
EDIT:
It seems that i get a different error message when visiting www.1234h.azurefd.net as opposed to 1234h.azurefd.net (no www).
no www gives a "The request URI is invalid" while the one with www gives "Our services aren't available right now".
I guess this was an issue in azure.
A partial fix was:
wait for a couple of hours
Add a web app to the backend, and change routing rules
After about 10 minutes the http domain started working (still no https)
Changing the forward rule back to kubernetes (with no changes to the backend) gave http access.
I guess the steps are not needed, but the issue was resolved around the same time i did the steps.
If i get https access without changing any settings i will report back to confirm if this were a problem in azure and not with my settings.
Other symptoms that lead me to believe this was an azure issue:
There were a few hours were my connection attemps were not registered in the metrics
After the http magically worked, i see my request at the backend graph mathing the frontend requests
Logging does not work properly (i see "Failed to resolve table or column expression named 'AzureActivity'" even though the column are shown in the tables overview)
EDIT:
Https started working while i wrote this answer.
Again, i did not change anything.
I was getting "The request URI is invalid" only when hitting FD via HTTPS. It worked fine for HTTP.
My FD routing rule was configured as such:
But given that I don't care about HTTP, I just configured my app service to be "HTTPS only" and things started working:
I'm migrating a complete infrastructure over to Azure; it's been slow going as there's so much to learn and for every two steps forward, there seems to be one step back.
After what seems like an eternity, I think I've got it all sorted with one exception.
The architecture is as follows:
Azure Traffic Manager ==> 2 Azure Application Gateways (geo separated) ==> Azure App Service
A custom domain is used for the traffic manager and the gateways are listening for the same domain and, when the route matches, passing on the requests down to the app service.
The actual app itself is a ASP.NET MVC application and it uses forms authentication; and this is where the challenge happens.
When navigating to the public address: client.domain.com and hitting the website, it determines that the user is not authenticated and sends the browser to the login page... so far so good but, rather than using client.domain.com/login it uses the web-server dns name, so client.azurewebsites.com/login
How do I go about changing the behaviour so that it uses the external DNS name rather than the website name?
I can't setup custom domains on the app service as the only route into the site is via the gateway as this is also the firewall.
Is there some Web Config setting I can make? I'm looking at the outbound rewrite rules but these seem to only work on tags rather than 302 redirects.
Any thoughts would be most welcome.
You need to setup custom dns names on your webapp (you can use TXT record to verify dns name, so i dont see a reason why you can add it to the webapp). or you can alter the code.
In order to solve this problem, I had to make a code change to the web app itself. Not ideal but it worked.
What I had to do was to extend the code that redirects an unauthenticated request to the login page by sniffing for the X-Original-Host HTTP Header that the App Gateway forwards on. This contains the public facing DNS name. If the header is present and it is on a pre-approved white-list (so as to prevent any hijacking), then redirect the user to the login page for this domain, rather than the one the server is listening on directly (so use client.domain.com rather than client.azurewebsites.com)
What am I trying to do
I have to azure apps deployed as App services. To make rest post easy let's call them "blog" and "landing_page". Both of them are hosted, so they URL are blog.azurewebsites.net and landing_page.azurewebsites.net.
I want to configure "something" in Azure with following rules:
if user access http://mydomain/ - content of landing_page.azurewebsites.net
if user access http://mydomain/blog - content of blog.azurewebsites.net
What I tried
After reading documentation, I have to reject Traffic Manager because it works on DNS level. From the other two I decided to use Application Gateway, because it should work on eny Endpoint (Any Azure internal IP address, public internet IP address, Azure VM, or Azure Cloud Service).
I configured my Application Gateway setting backend to: landing_page.azurewebsites.net. But in "Backend health" the app status is unhealthy. I tried also:
blog.azurewebsites.net - unhealthy
www.wp.pl (polish news portal) - is working
gazeta.pl (polish news portal) - is working
stapp.space (my blog) - this is same as piotrstapp.azurewebsites.net and status is unhealthy
Question :)
What did I wrong? Maybe should I use something else on Azure? Or am I missing something?
Make sure that custom probes is turned on and configured in the HTTP settings of the WAF for your site. If you don't the Application Gateway will try to go to the IP of the App Service Environment without passing a Host header, which won't work and will throw the probe into an unhealthy state resulting in a "502 Gateway Proxy" error.
There is a great article here
You may want to check out Azure's application gateway path-based rules function:
Create a path-based rule for an application gateway by using the Azure portal