I recently discovered that one of my server machines had the same service under different Web Sites and they were managed by different app pools. Something like this:
Custom Web Site
MyWebSite (Managed by CustomAppPool v4)
Default Web Site
MyWebSite (Managed by Default App Pool v4)
The CustomWebSite version is hit on http 28000 port. The default one is just set up on 80 (this is not really hit)
Both the Web Sites are pointing to C:\inetpub\wwwroot. The Default Web Site version should not have been converted to an application in the first place. My question is how bad is it? Should I be separating the service asap?
My understanding is that IIS will handle the requests independently, so there should not be any danger in sharing code files. Other than it being untidy and allowing potential process issues, I don't think you have to remove it. On the same token, I believe you would be fine to remove it.
Related
I have a .net web application, I want to host the app into more than one IIS web servers. The web servers must synchronized so if one web server is down than the others should respond to user requests.
Check out tools like:
gtg.dk
deploybot.com
Check out also deployplace it is very similar to DeployBot, but much more powerful and allows to deploy complicated application. It's still in beta, but there is a free plan.
Scenario: The login page for a host of web applications lives on an internally hosted server. When this server gets rebooted we need this login page to remain accessible, even if it just displays a friendly message.
The thought I am having is rendering this login page on a different app hosted in the cloud. When our server then gets rebooted the cloud hosted app will instead render a different message.
Is this even a viable option?
What are the pitfalls of this approach?
Are there any cleaner and better alternatives? (And "host the login page in the cloud" has already been considered but I'm looking for alternatives to that as well)
this is totally possible, what your describing is a reverse proxy or load balancer have a look at configuring apache as a reverse proxy server
I have a web role that hosts 4 MVC 4 sites. One of the sites (let's call it the API site from now on) uses both MVC and Web API. When I upgrade the web role, the Web API controllers from the API Site returns a 500 Internal Server Error to all requests. The MVC controllers work as expected and I know the request is getting at least as far as the Application_BeginRequest method of the global.asax. I'm not seeing anything logged in my Elmah log. The only hint I have of anything being wrong is the following in the event log:
The application '/' belonging to site '1' has an invalid AppPoolId 'DefaultAppPool' set. Therefore, the application will be ignored.
As web roles use App Pools with guids as identifiers I don't know where this is coming from.
What is most confusing is that once I recycle the app pool for the API site (which is a guid) everything starts working correctly.
I've tried recyling the app pools as part of a startup task on the role, but that doesn't seem to make any difference.
Any suggestions about what I can do to get Web API to start correctly?
I never did find what was causing this issue.
It got to a point where I could deploy from my machine and not get the problem, but my colleague could not.
We tried comparing the contents of the .cspkg files that were produced, but didn't find any differences.
We are now both able to deploy the project with no problems.
My suspicion is that this was resolved when we upgraded the Azure SDK and tools on our machines.
I currently have a VPS with another provider. On that VPS, I have IIS running with multiple app pools and web sites. I would like to get out of the "server management business", so it would seem that Azure Web Sites (Reserved) would be a great fit. I'm able to get the Azure Web Sites set up, including the custom domain piece. The problem that I can't seem to figure out is how to get the same URLs and behavior that I currently have on my VPS.
For example, I have URLs that look like this right now:
www.foo.com/bar
www.foo.com/baz
wildcard.foo.com/bla
I can't find a way to mimic that in Azure.
Things I've thought of/tried:
Go with one Azure Web Site and have separate virtual directories/app pools in Azure, but googling tells me that isn't supported.
Create 3 Azure Web Sites, one for each of the above. The problem there as I see it is I would need to change to use bar.foo.com, baz.foo.com, and bla.foo.com/wildcard (i.e. lose wildcard subdomain mapping and rework things to have a custom route at the end).
Maybe have one Azure Web Site with a rewrite URL? The problem I think I'd run into there is that it all runs in one app pool, so deploying one piece will affect all 3, and obviously a fault in one app would impact the other 2.
Has anyone else gone down this path and solved it? If the answer is spin up a virtual server, I'll probably just stay where I'm at.
Considering www.foo.com/bar, www.foo.com/baz and wildcard.foo.com/bla are 3 independent web applications that share a domain (foo.com):
Create a Windows Azure Website for each web application. You don't necessarily need to assign custom domain names to them.
Create another, separate website and assign to it the *.foo.com domain using an A record. Refer to Configuring a custom domain name for a Windows Azure web site for instructions. As documented, "With an A record, you map a domain (e.g., contoso.com or www.contoso.com) or a wildcard domain (e.g., *.contoso.com) to the single public IP address of a deployment within a Windows Azure web site. The main benefit of this approach over using CNAMEs is that you can map root domains (e.g., contoso.com) and wildcard domains (e.g., *.contoso.com), in addition to subdomains (e.g., www.contoso.com)."
In this "master" website, set up URL redirection (possibly with status code 307 Temporary Redirect) so that requests go to the appropriate applications.
Alternatively, to avoid the delay of the additional request caused by the redirection, set up the "master" website as a reverse proxy that transparently forwards the request to the "inner" web application and sends the response back to the user.
As yet another alternative, use a custom DNS service to do the routing at the DNS layer.
This way, each web application is independent and you solve the issue of routing requests to the appropriate application.
just starting to explore Azure and I am still a bit confused regarding the purposes of web roles vs worker roles. In the solution I'm working on mobile apps (iPhone, Android, Windows etc) will be accessing our server product via a REST api. So there is really no public facing web site for our service (as in web pages).
This made me think that I don't need a web role but instead have one or worker roles listening on our http endpoints. I have created a prototype along these lines. When from a mobile device I do I an http post to the endpoint, I get no response back. And I see nothing in the Azure logs that indicate that indeed my worker role was started or is running and responding to it.
Is this an appropriate approach? Is there something I need to do in setup code because I don't have a web role? I read in another thread that web roles run in IIS but worker roles don't.
Thanks for bearing with me. I am still getting to grips with Azure and so have a little difficulty formulating the right question.
You don't need to have a web role in your azure deployment. As you read, a web role has IIS, and your web site is hosted in it. A worker role is basically a plain old W2K8 server without IIS. Honestly, I haven't RDP'd to a worker role instance, so I'm not 100% sure that you don't have IIS or not.
But you don't need a web role in order to expose a WCF service. Here's a nice example (although the background color needs some work) that shows you how to do this.
Good luck! I hope this helps.
Adding to what David Hoerster said: You can host up to 25 externally-facing endpoints (each with its own port number) on any role type, with each endpoint being http, https, or tcp. With a Web Role and IIS, a web application typically grabs an endpoint mapped to port 80. In your case, you'll be creating your own endpoints on your specific ports. You're responsible for creating your ServiceHost (or whatever you're using to host your service) and binding it to one of your endpoints. To do this, you'll need to either map each endpoint explicitly to a specific internally-facing port, or inspect the endpoint's properties to discover which port has been dynamically assigned to it, for you to bind to (might this be the issue you're running into with your prototype code?).
If you're looking for the benefits IIS offers when hosting your endpoint, you're better off with a Web Role, as it's going to be much easier for you to do this since a Web Role enables IIS by default (and it's easy to add WCF services to a Web Role from Visual Studio).
Even if you were to self-host your endpoints, you could still use a Web Role, but now you'd be carrying the extra memory baggage of a running, yet unused, IIS service.