I'm looking to set up two web roles or websites on my Azure Cloud Service.
The websites need to share the same database schema. I use NHibernate ORM, so I have to make sure that both projects are always using the same data model, or else it will cause major problems.
I've researched setting up multiple websites on a single web role (which seems odd to me, can't I just run multiple web roles, each with a single site)?
http://msdn.microsoft.com/en-us/library/windowsazure/gg433110.aspx
Like any good developer, I use a staging server. If I have to manually set the domain name is configuration files, how will azure know not to be sending people who visit that domain to the staging server?! I.E. If they visit blah.foo.com and I have two deployments (staging and production), is IIS going to be able to know only to send people to the production environment?
Please advise on the best way to go about doing this.
First, you can certainly have multiple web roles, each with a single site; however, each role instance will be deployed to different virtual machines. For example, if you do set up two web roles when you deploy this with one instance each then there are two virtual machines you'll be paying for. If you want the SLA to apply to your deployment you'd need to actually set the instance count to 2 for each web role, which now means you have four virtual machines running. By combining web sites onto the same web role you'll cut down on the number of instances you need to run and still get the SLA; however, that option is not without some considersations. The link you provided is how you can set up multiple websites to run on the same virtual machine when deployed. Note that there are some gotchas with using that method. I'd suggest reading Michael Collier's Tips for Publishing Multiple Sites in a Web Role.
Second, if you do NOT need to have a lot of control over the virtual machine (such as registering special components, etc.) you might want to look at Windows Azure Web Sites as an option. You can elect to take one of the paid levels of Web Sites and still have dedicated machines, but you can deploy the websites separately. I will say though, that your requirement of having both sites in lock step because they share the underlying database schema means that it will be less likely you will want to deploy separate changes, but it is still possible.
Finally, regarding the staging server. If you are testing locally you'll want to modify your hosts file to get the host names to point to your local address. Wade Wegner has a post on Running Multiple Websites in a Windows Azure Web Role. Once you deploy to Windows Azure you'd want to change your hosts file back, or comment them out. If you are using the actual idea of the Staging deployment slot you can use the same trick with the hosts file to point to the IP address of the staging deployment when testing.
Related
We develop a website that our customer is using internally, we host the application in 3 - 10 windows servers for them. If we want to modify the content of our application, we are forced to access all the servers manually and deploy in all of them. We have decided to deploy the files to one location that will be accessible without needing our customer's internal network access(we've asked them to setup a DMZ) and from there synchronize the contents to all servers.
From just browsing through, I've come across IIS Web Farms and Web Deploy which does something similar to this, my question is, we want the deployment so happen to all servers one by one, or all at once and on demand. Is it possible to configure WebFarms/Web Deploy to work like this? Also if synchronize fails, restoring backups, pulling reports. Is this all doable with Web Deploy/WebFarms?
I've got a rather unwieldy legacy intranet app that does a lot of file manipulations across multiple network shares (file reads, moves, deletes, creates directories, etc) and I want to set up a preproduction instance. Currently the app pool is running under a domain account that has been granted access to all these scattered directories. I'm wondering if running a second instance of the site (different server) using the same domain account would be an issue.
This doesn't seem to be an easy question to formulate in a way to get a useful answer out of google. Anyone have any experience doing this? I would rather not have to create more accounts and track down all the locations that would require added permissions if I don't have to.
The aim to set different application pool identity for different application pools is to restrict the limit for application pool. Independent application pool will isolation NTFS permission from accessing the files that the web app shouldn't reach. Just in case the server are under vulnerability attack.
Of course, if you are hosting your web apps in a isolated network environment, you could share your domain account for multiple application pools.
As Lex said, consult your network administrator would get more practical answer.
I am new to Azure and website deployment, and I am trying to make sure I understand how things work. As far as I understand, once I create a website, a web application is created and begins to run in the cloud before publishing my own site even.
I know that the cloud provides scalability, load-balancing (among multiple datacenters), ease of publishing/testing, etc...things that don't exist in traditional web hosting.
So my question is since my website is in the cloud/Azure now, would my website be replicated globally in MS datacenters? If yes, is it something different from load-balancing? in other words, is the idea behind it is to get my site replicated to provide faster access from all over the world. And if all these are correct, I suppose traditional web hosting doesn't support replication.
Sorry for the simple questions, but I really need to understand, and I would appreciate any details you could provide.
Q: So my question is since my website is in the cloud/Azure now, would my website be replicated globally in MS datacenters?
A: Your website won't be automatically replicated globally to all MS datacenters. Each azure service, whether it is an cloud-service, sql-azure, storage, website or VM is located at a location of your choice. Within a location you can scale some of the services to run in multiple instances. If you spawn a new instance your website gets replicated. But it still runs at the same geo-location.
Q: If yes, is it something different from load-balancing?
A: In Azure you need to distinguish between load-balancing and traffic-management. If you run multiple instances within one location, there is only one external URL to reach it. The load-balancer distributes traffic equally to every running service instance.
The Traffic Manager allows you to control the distribution of user traffic to Windows Azure hosted services. The hosted services can be running in the same data center or in different centers across the world. Traffic Manager works by applying an policy engine to the Domain Name Service (DNS) queries on your domain name(s).
So in general, if you want to spread your application all over the world, you have to do it by yourself.
Create your service on all the location of your choice and use Traffic Manager to connect them.
We are looking to host a website (some css,js, one html file but not aspx, one generic handler).
We deployed in as:
1) Azure Web Site
2) Azure Cloud Service
Both solutions work. There is a question though: which way of hosting it is better and why? Second thing: as there might be a lot of traffic - which solution would be cheaper?
Thanks in advance,
Krzysztofuncjusz
You may want to review this article that explains the primary differences. Web Sites are best for running web applications that are relatively isolated (that do not require elevated security, remote desktop, network isolation...). Cloud services are more advanced because they give you more control over web sites while still remaining flexible. And VMs are for full control over applications that need to be installed and configured (like running SQL Server for example).
I think that main difference in abilities to modify VM and possibility to configure scalability. Web sites is something like classic hosting, without ability to login by rdp. Cloud Services allows you to configure VM and if necessary setup scalability and availability.
when deploying azure websites to a farm of lets say 10 instances, how is the deployment of the new version propagated?
is there a time where different users could hit diffident version of the site based on where the load balancer sends them? or does azure spin up a whole new set and does an ip swap when they are all ready?
You are thinking azure websites a lot more like "Windows Azure Web Role" which is not true. With Windows Azure Website your website (shared) is sharing resources without hundreds of other website so there is not such ip swap, and update domains etc.
Websites are stored on a content share which is accessible from all the "web servers" in the farm so there is no replication or anything like that required. So with shared and reserved website the update will be instant for all instances. With larger package update it may take some time for file system change notification however once the file system update notification is available all the instances will pickup the updated code instantly.
With Windows Azure website, the content is located at "content share" and all instances are getting data from there so there is never a chance where multiple instances have different version of data.