I have a webapp setup with Wordpress with a specific IP address (which is also pointed towards a custom domain).
The problem is, when I add a new webapp (also with Wordpress), it also gets allocated the same IP address as the first webapp causing it to redirect to the first webapp.
I have setup the second webapp with the same subscription plan and am using the same database for both.
Also, the first time I made a second (ever) webapp, it has its own seperate IP, but due to some issue, I deleted it and made a new webapp with the same name. Now whatever I do and no matter how many new webapps I make, they all have the allocated IP the same as the first webapp. Any solutions?
Thanks!
Azure Web Apps are created behind a set of load balancers that differentiate between Web Apps based on the incoming request.
if your two Web Apps are located at example.com and example.org and you have configured both in DNS to point to the same IP address, then the load balancers at the front should decide where to send the request based on what is requested.
This is going to be a problem of using the same backend database for two different wordpress sites. (unfortunately I'm not a wordpress expert, so I can't comment on what that might be - but this answer will hopefully help those who do know about wordpress, to clear up that this is not likely to be an Azure issue)
As Michael indicated the Azure Web Apps site behind Load Balancer or ARR Front ends. However there is more to this.
When you create a site in Web App, you actually create an App Service Plan as well (this corresponds to a VM)
So when you create the second site you will get an option to either choose the same or a new app service plan.
If you choose the same app service plan, then both of your sites will sit on the same VM and as a result will be behind the same ARR FE.
If you choose to create a new app service plan, there might be a possibility that the VM will be allocated either behind the same or a different Front end. This cannot be controlled. The Fabric controller makes the allocation based on availability.
Eitherways, this shouldn't be a problem. It is okay for 2 sites to share the IP Addresses. However if you wish to have separate IP Addresses for your sites, then you can use one of the options:
Create the site in a different data centre
Create the second site under new app service plan. There is a high chance that the app service plan might be allocated under a different ARR FE.
Scale the site to Standard or higher tier and use IP Based SSL. This will allocate a dedicated IP for your site. There is additional cost associated with getting a dedicated IP. Refer the Azure App Service pricing for this.
Related
We have a few services running on our internal server, named cpweb2.
The Default Web Site is accessed locally by browsing to http://cpweb2/.
To enable browsing to other applications, the other sites are assigned a different port number.
For example:
CapacityTracker is configured to use port 8081: http://cpweb2:8081/
AcpWcfTool is configured to use port 8093: http://cpweb2:8093/
ProductionScoreboard is configured to use port 8082: http://cpweb2:8082/
ShopServices is configured to use port 8095: http://cpweb2:8095/
As you can imagine, not many people simply remember the web address for these sites.
I am currently creating a new service called AcpMainframe. I would like to give it a more user friendly URL like http://cpweb2/mainframe or http://mainframe.cpweb2/, but I don't know how exactly to do that if Default Web Site is not one of my projects.
I guess this question is two parts.
Can I get my new AcpMainframe service added to the root level Default Web Site if I do not have the code for that root level website?
If so, how do I go about that?
If you can use other hostnames in addition to the one you have, you can set bindings in IIS that will allow multiple sites to run on port 80. Examples can be found here.
I want to be able to deploy a new version of my asp.net/mvc website without loosing client session state or causing any downtime. The way I'm thinking of accomplishing this is by creating a Windows Network Load Balancing server so that clients can reach it via a single url such as https://mysite.org/. It would then redirect traffic to one of two other sites (A.mysite.org or B.mysite.org). I'll set the NLB's affinity to Single, and disable site B so that all sessions are are directed to site A. When I need to deploy a new version of the website, I'll deploy to site B, enable site B, and disable site A. So, everybody that was on site A can stay there (using version 1) until they log off. All new sessions will connect to site B and run version 2. The next time I deploy, I'll do the reverse.
I've never used NLB. Is this appropriate? Is there a simpler, easier way?
How does NLB know when a request from client X already has a session on A or B? Ie. when they log off the website, and try to login again, will the nlb send them to the same site they were on before?
There are quite a few considerations here
Firstly, rather than juggling the affinity on your NLB, you will probably be better storing your ASP.NET Sessions in StateServer or SQL based Session management to allow web clients (or web service clients) to access your site without 'sticky' affinity. Once you've set up the StateServer or created the SQL Session DB, it should be a simple change to your app's web config.
NLB itself works great for keeping your site up while you upgrade your site. You will typically drainstop a server in the cluster before reinstalling your app to it, test it, and then bring it back into the NLB cluster, before repeating the process with the next server etc.
AFAIK, NLB Single Affinity works at TCP/IP level and is does not interrogate ASP.NET sessions. Basically any connection from the same client IP to the same server IP:Port combination will be directed to the same server. Also AFAIK, both servers will be sharing the NLB IP (In addition to any existing IP's they have).
Since it seems your site uses SSL, it seems that unless you have affinity, that the SSL session keys will need to be renegotiated on each request, which could have performance implications.
I am currently building an web app which also utilizes websockets. (Rails for webserver and Nodejs for socket.io)
I have structured my application to use subdomains to separate between connection to the Nodejs server and the Rails webserver. I have "socket.mysite.com" redirected to the Node server and everything else to the webserver.
I am able to test this functionality on localhost. I simply modified my /etc/hosts to include the following:
127.0.0.1 socket.mysite.com
127.0.0.1 mysite.com
I know that on production I simply have to generate a CNAME record for socket.mysite.com and this will also work on my users' computers.
However, I am accustomed to testing my application by passing an IP address around. My team typically set up the server on our own machines and do development. When we want to test our individual servers, we just pass around an IP like "http://123.45.123.45".
With the new subdomain hack, this is no longer possible without modifying each of my tester's /etc/hosts. I honestly don't expect my testers to modify their /etc/hosts on the spot. What I can do is have each member of my team have their own domain and create the appropriate CNAME records for each individual team member.
Is there an easier way to allow me to run my app on an IP and just pass that IP around?
It sounds like your needs have scaled beyond the days of just simply editing a host file. While you could continue to have everyone on your team continue to edit host files, there are two main risks that I see here:
For your idea to just use IP Addresses, you risk missing something in testing that you wouldn't see unless you were on production, as the issue may be dependent on something in the domain configuration.
For using host entries, you introduce a lot of complexity and unnecessary changes to each developer and tester's configuration, which of course leaves the door open for mistakes, and it also takes time that will add-up over the long term.
Setting up a DNS server may be helpful in your case. You could map a set of domains for each developer that match a certain pattern so that your application will still run correctly. This would allow you to share the URLS without having to constantly reconfigure each person's computer. Additionally, marketing and sales stakeholders can easily view product demos as well, without needing to learn what the elusive host file is for.
If you have an IT department, they can help you setup the DNS. However, if you are a small team without a real IT department, some users have found success using DNS systems designed for home or small office networks.
I am writing a small c# app to run at startup when a new machine is booted, connected to our corporate network.
I have some code which checks whether a machine account for the machine already exists on the domain, and if so deletes it, prior to joining the machine to the domain.
This works fine on my computer, which already has the trust set up to the domain, but doesn't from a test machine which is not yet joined.
Is there a way round this? Not sure if this is one for Serverfault or Stackoverflow - so hedging my bets!
Yes you can, via LDAP, as long as you can connect to a domain controller via your underlying network transports (ie- TCP/IP). You'll need to bind to Active Directory under the context of a domain user who has at least read access to the directory. You'll also need to specifically call out which domain controller you want to connect to as autodiscovery relies on a domain connection.
I would like to know if it is possible using IIS and ASP.NET (and ideally something that might be employed on a shared hosting account, but this isn't required) to mimic WordPress.com's ability to allow end users to use their own domain names.
WordPress has users who own their own domains change the domain's DNS settings to point to WordPress's own DNS. My guess is this is not something that would be able to be done on a shared hosting account since it would involve adding an entry to the DNS server's table for each custom user domain.
However, for future reference, is this something that might be automated programmatically on perhaps a VPS?
My guess is this is not something that would be able to be done on a shared hosting account
You're nearly correct. The default site in IIS listens to all connections on port 80 for the default IP address.
You can add more sites in 3 ways:
Add new sites listening on different ports. This is not entirely practical if you want "ordinary" sites litening on port 80.
Add more IP addresses to the box (not too eaisly done) and set up new IIS sites to listen to the new IP addresses independently.
Add new sites to the server listening to different "host headers" (domain names to you and I) but on the same (default) IP address .
So called "Shared hosting" usually uses options 3, because a hosting company can get away with only using a single IP address for possibly hundreds of sites.
Therefore you would have to go through the tedious process of adding each host header to the box, and while I'm almost certian this could be done with Wscript, I'm no expert in that area.
If you really wanted to get into it, you could write an ISAPI module to intercept the calls and set up some clever (ish) database/hash table of domain names and target folders to server as the different sites.
Bottom line is, there are various ways to achieve this on Windows. Probably none quite as easy as on a *nix platform where everything is super-scriptable.
What we do is have a wildcard DNS entry set up for our domain. That way, whatever domain the user types will resolve to our website as long as it ends with ".mydomain.com". Then our .Net code just looks at the "HOST" header coming in and serves up the content that matches that domain name.