I am attempting to host multiple websites in a single Azure WebApp rather than having multiple web apps each hosting a site. Each of these sites is rather small, but in order to meet the requirements of the SLA with Azure, we need to have the server scaled with more than one instance for our Production environment, thus the reasoning for combining sites.
After researching this topic, I have got the following setup with our Azure account.
Created the proper CNAME DNS records in our zone manager (complete and works).
Setup the Azure WebApp to respond to the subdomains (complete and works).
Setup a virtual directory for the second web application (complete and works)
At this point, both web applications function correctly and both subdomains are pointing at our Azure instance. We now have the following setup:
both www.mydomain.com and app.mydomain.com bring up the root application that I deployed.
going to www.mydomain.com/app2 and app.mydomain.com/app2 bring up the second application that I deployed to the virtual directory
What I would like to achieve:
Going to app.mydomain.com would bring up the application in the virtual directory.
Going to www.mydomain.com would bring up the application at the root of the azure instance.
However, what I cannot figure out is how to map a subdomain to a specific virtual directory. I have tried to update the Site URL to be the subdomain I want the application to respond to, however, the subdomain still brings up whatever I have in the root of the WebApp deployment.
Should I have some HttpHandler that sits in the site root and directs traffic to the proper virtual directory? Is there a setting in the portal that I am missing? Previously, we did this with Web Roles and tinkering with the ServiceDefinition file, but the tool sets for the Azure Web Apps in regards to publishing, integration with Source Control, etc seem to be a bit further along.
The answer posted by RuslanY will work (with some modifications to the rules slightly) however, after understanding more of the Azure portal and Web App configurations, it is not needed to host multiple sites within a single Web App (Its technically multiple web apps all sharing the resource plan you define, such as 2 instances of Standard Level 0 (S0))*.
As of today's Azure service offerings, the following is true. When you create a new Web App, you pecify the "App Service Plan" that the app falls into. If you have an App Service plan, lets say Standard with 2 instances, any Web App you deploy to that App Service plan shares those resources with other web apps in the same service plan, meaning you are not paying additional costs to host the additional web app if it is in the same App Service plan. I had assumed each web app was its own set of resources (it can be, but doesn't have to be). Given this, to accomplish what I need, I simply create a web app for each sub domain and place them all into the same App Service plan. I now am hosting multiple sites, not paying for 2 servers per site (what I wanted to avoid) and I don't have to use URL rewrites or HTTP Handlers.
I hope this write-up helps others understand the structure of the Azure Web Apps a little bit better. The current online documentation, from what I can tell, doesn't make this exactly clear.
This may be possible to do with URL rewrite rule which takes the hostname of the request and rewrites the request URL to start with the subdomain extracted from the hostname:
<system.webServer>
<rewrite>
<rules>
<rule name="Rewrite Subdomain To Directory">
<match url=".*" />
<conditions>
<add input="{HTTP_HOST}" pattern="^www\.mydomain\.com$" negate="true" />
<add input="{HTTP_HOST}" pattern="^(.+)\.mydomain.\com$" />
</conditions>
<action type="Rewrite" url="{C:1}/{R:0}" />
</rule>
</rules>
</rewrite>
</system.webServer>
To understand the syntax of the rewrite rules you can refer to the IIS.net documentation about URL rewrite module.
Related
We have several APIs running as Azure App Services and have been experiencing intermittent service outages where 10-25% of the calls to those App Services return a 503.64 while the other calls (often to the same endpoint) return normal responses. None of the 503 failing requests appear in App Insights or in the App Service's web server logs, and we can only see them through tracing and logging from the calling services (App Gateway logging or other App Services making internal REST calls).
We haven't been able to determine a pattern to when this problem occurs. Between disruptions, we have seen as little as an hour and as much as 2-3 days. The issue has lasted anywhere from 2-30 minutes at a time. There is no correlation with traffic or system load, and it happens at any time of day or night. We have seen this on both I1 and I2 tier plans. We have tried scaling out our services well beyond necessary capacity, but the problem still occurred.
Looking at the 64 sub-status code, it suggests a rewrite issue.
<!-- Antares Rewrite provider codes-->
<error id ="64" description="Exception in rewrite provider (probably SQL)" />
However, I'm confused by the fact that some of the rewritten calls succeed during the same period that others fail.
For completeness, here is the rewrite for one of the failing services. A public API endpoint is being rewritten to an internal request address, and all other APIs are to remain as-is and pass through to the Controller:
<rewrite>
<rules>
<rule name="LegacyGetStatus">
<match url="Mapping/fw/1.0/Status(.*)" />
<action type="Rewrite" url="api/Status{R:1}" />
</rule>
</rules>
</rewrite>
We submitted a support ticket a week ago, and in the meantime we are trying to figure out what could be causing this and what we can do to mitigate the issue.
The 503.64 response seems to have been a red herring. It appears that there was required outbound network traffic that was being blocked by our network firewall. The advice from Azure was to double check the settings and allowed traffic according to the Azure documentation or to migrate from App Service Environment v2 to v3 where this traffic appears to be allowed automatically (or not needed).
I have developed a new website using a CMS named Kentico.
After being published on my web server named web3, it consists of 2 folders: a folder for the live site (named live) and one server for the admin site (named admin).
My folder structure looks like:
For the time being, my IIS installation looks like:
So i have created an application for the live site pointing to the live folder and an application for the admin site pointing to the admin folder in the Default Web Site of IIS.
Therefore, the URLs to access the websites are http://web3.domain.org/Live and http://web3.domain.org/Admin.
It works fine but I want to access the live site at http://web3.domain.org/ and the admin site as it is now: http://web3.domain.org/Admin.
One solution I found was to create a new website in IIS pointing to the live folder and add a new application inside it pointing to the admin folder:
It works fine, the live site is accessible at http://web3.domain.org/ and the admin site at http://web3.domain.org/Admin.
However, I am not sure if it is the best option as the admin site is now dependent of the live site. If the live site is down, I won't have access to the admin site while they are technically independent (2 distinct folders).
I also tried to keep using the Default web site with some rewrite rules in a web.config under wwwrooot like :
<rules>
<rule name="Root_URL_Rewrite" stopProcessing="true">
<match url="^(.*)" />
<action type="Rewrite" url="/Live/{R:0}" />
</rule>
</rules>
but it didn't work.
Your help would be welcome.
I would recommend creating two separate IIS sites. One for the admin app (e.g. admin.something.com) and second IIS site for the live app (something.com). Or, if you want to have both apps on the same domain name and the admin app in a subfolder, then you need to use one IIS site - this will be set to the live app and then create a virtual application subfolder and point it to the admin app. So, you will have basically nested admin app - this is not recommended as in some cases IIS can detect two web.config files as nested and it could cause issues. Or, IIS will take the live site's config file as master and ignore the nested one, etc. I would vote for two separate IIS sites.
We have a Web App hosted in Azure. We have a staging deployment slot that the web app is on and the URL provided is a .internal link that is not accessible. How do we create an accessible URL for the deployment slot. Thank you!
The staging site deployed would have a separate URL on the slot's resource page. The deployment slot has its own host name and is also a live app. Which is publicly accessible by default, however, we have ways to limit public access to the deployment slot, for this checkout 'Azure App Service IP restrictions' – For it to work, IPv4 address ranges that start with 10. and 100. are internal to your deployment. You should allow them to connect to your app.
You have stated that the staging site is inaccessible, please do share more details on the error you may be receiving and how exactly are you accessing the site.
Some common issues and ways to mitigate:
During custom warm-up, the HTTP requests are made internally (without going through the external URL). They can fail with certain URL rewrite rules in Web.config. For example, rules for redirecting domain names or enforcing HTTPS can prevent warm-up requests from reaching the app code. To work around this issue, modify your rewrite rules by adding the following two conditions:
<conditions>
<add input="{WARMUP_REQUEST}" pattern="1" negate="true" />
<add input="{REMOTE_ADDR}" pattern="^100?\." negate="true" />
...
</conditions>
Without a custom warm-up, the URL rewrite rules can still block HTTP requests. To work around this issue, modify your rewrite rules by adding the following condition:
<conditions>
<add input="{REMOTE_ADDR}" pattern="^100?\." negate="true" />
...
</conditions>
Checkout the doc setting up App Service staging environment for more details on this topic.
i have a problem with a custom domain in azure, i created a webapps and configurate the custom domain, the only https is disable
the hosting of domain is azure dns zone
when i try go to my page, always redirect to https
i did step by step from https://learn.microsoft.com/en-us/azure/app-service/app-service-web-tutorial-custom-domain
Azure Web Apps do not automatically redirect http to https by default. It may be caused by some logic in your specific app.
Here is a similar issue, you could refer to it.
Azure Web Apps do not automatically redirect http to https by default, so it may be caused by some logic in your specific app, or some other non-default step that you took.
To see this, simply create a new empty Web App, and verify that you are able to browse to it using http.
its probaly that you have in your config this line
<action type="Redirect" url="https://{HTTP_HOST}{REQUEST_URI}" redirectType="Permanent" appendQueryString="false" />
We're developing a new website running in azure. We are currently developing against the local azure dev environment. But now we need to publish and test the site in the real Azure world. But we would like to run in a "closed" environment, where only know users have access, as the site should not go live yet. Any suggestions to accomplish this?
/Rasmus
Windows Azure has something called 'staging mode', see this post: http://sevans.info/2010/10/10/windows-azure-staging-model/
It's very powerful, and exactly what you need as far as I can see.
You could remove the endpoints of your instance configuration, so there will be no forwarding through the load balancer. After that you could use the Remote Desktop to log into your azure instance and test your web application.
Above suggestions are great and I would also like to add two more in this list as well:
Using production deployment and having a dummy index/default page with directory browsing disabled (already set as default) So when someone come you your site there is nothing they will see. And as there is no directory browsing so they can not guess the page*.aspx to visit your site. This will keep your production site running and you can test it from outside.
Removing your instance form Load Balancer while keeping your instance healthy. This will require you to test the Azure Application by RDP to your instance and then launch internally. If you wish to do so here is the Powershell based trick.
You could restrict the IP addresses that are allowed to access your app if you have a static IP address. As per this link: https://azure.microsoft.com/en-us/blog/ip-and-domain-restrictions-for-windows-azure-web-sites/
Developers can use IP and Domain Restrictions to control the set of IP addresses, and address ranges, that are either allowed or denied access to their websites. With Windows Azure Web Sites developers can enable/disable the feature, as well as customize its behavior, using web.config files located in their website.
Here's the code:
<system.webServer>
<security>
<ipSecurity allowUnlisted="false" denyAction="NotFound">
<add allowed="true" ipAddress="123.456.0.0" subnetMask="255.255.0.0"/>
</ipSecurity>
</security>
</system.webServer>