Per article below web app has an option to either auto or manual scale:
https://azure.microsoft.com/en-us/documentation/articles/insights-how-to-scale/
Would appreciate if I can get clarification on below:
Scenario:
I've ASP.NET Sitecore CMS which uses Lucene behind the scene for search. Lucene index gets rebuilt upon publish of new pages.
Lets say I manually or auto scale to 2 instances:
What exactly happens behind the scene i.e. copies all the website folder to new VM and sets up IIS etc?
Web App has functionality to FTP and view website folders. Is it possible to FTP to both of these instances? From what I know I can only FTP to one of them.
Update:
Problem we are facing:
We use lucene index for our web applications. Looks like the index is built on one web app and not other (website works for some user and not for others). We would like to FTP or RDP and see to make sure this is the case.
Thanks.
The FTP or the GIT provided by the Azure is not on the same instance when you use WebApps, So if you do FTP its not to one of the instances - its somewhere else, but when you change files in the FTP or push to GIT, the triggers kick in and a continuous deployment to the Webapp instance/s is done. You can be very well assured that when you upload new files to your FTP that comes with WebApp the build will be updated on both instances. In fact that's one of the driving forces behind webapps that you don't need to think about a VM.
We used once Lucene on Web Apps with multiple instances. What we did back then was use Azure Blob Storage to keep the index files, no matter the number of instances, all had the same index information.
The only problem was that when new instances would come up (autoscale), they had to load the index on memory and that lead to some cold-starts.
We moved to Azure Search afterwards and never looked back :)
Related
In IIS you can create an Application on a site so now I want to try and accomplish the same on Azure Cloud Service:
tenant.mysite.com - One Cloud Service
tenant.mysite.com/api - Another Cloud Service
The reason I want it done like this is cause this is a multi-tenant site and the api needs to be called with the tenants URL.
Is there any way out the box to do this with Azure? Am I looking at the whole solution wrong or do I have to look into doing a proxy of sorts?
I did host the application similar to what you have did.
There are a few points that you will need to take care of
1. Overlapping sections of web.config file should be locked using <location path='.'.... > tags
2. Proper references for the dlls to be given
This is easily achieved in both the Azure websites and Azure Cloud Services. The link that explains how you can get started is given below. Post questions if you have tried this and run into some issues.
http://blogs.msdn.com/b/tomholl/archive/2014/09/22/deploying-multiple-virtual-directories-to-a-single-azure-website.aspx
Quick question. I'm looking to deploy a website to Azure using websites.
I read a comment that stated that the file system is shared across multiple instances of the website?
Is this true?
Does this mean if I upload an image to the file system
on one instance, all requests on the second instance will have
access to the file?
Are the files synced across the instances or do
they all point to a single drive i.e. in the blob storage somewhere?
We will be deploying an Umbraco 7 site, so I still need to test for any issue this might have on the lucene indexing etc. Does anyone know of any complications with Umbraco 7 and this method of deployment?
Thanks in advance
Gordon
The answer from bedane is incorrect. This question is about Azure Web Sites (not about Azure Web Roles)
1) Yes it is true. Azure Web Sites stores your content using Azure Storage blobs that are mounted and presented to the web site as a common share that is read/writable.
2) By virtue of 1), when you upload the file you are uploading it to the common share and therefore all instances will see the upload immediately.
3) The instances all point to a single drive (just repeating point 1)
This architecture for Azure Web Sites was designed specifically to enable applications like Umbraco, Wordpress, etc. that install plugins and make changes directly to the site content directory. This design point fixes the problem that currently exists in Azure Web Roles.
I'm currently investigating the possibility of my company using Azure.
Our current hosting situation that we run ourselves involves a separate site in IIS for each of our clients, each one having a virtual directory to the CMS we've built with ASP.Net web forms. We can update the contents of that virtual directory, which then provides the latest version of our CMS to all our clients at once.
I'm not looking to recreate that exact situation in Azure, but I am instead interested in figuring out how to create a single Web application in Visual Studio, publish that application to Azure in such a way that multiple sites (that I've specified) are created on Azure. Then I would like to be able to make changes to that application, and publish it again in a such a way that all the sites for it get updated all together, without requiring something be done manually per site/client.
The closest explanation I've found is this one:
http://www.wadewegner.com/2011/02/running-multiple-websites-in-a-windows-azure-web-role/
That gets me close, but what I don't understand is that when I publish this application to Azure, I still only see one application / URL available in the Azure management console. Shouldn't the extra "Site" node result in a different site being available when I publish it? Why doesn't it? Is there a completely separate way to accomplish this that I'm not using?
When you look at the management console you're seeing the web roles that you have deployed, not the sites that are part of that web role which is why you're only seeing one. As long as you've followed the instructions correctly, then yes, you do have two sites running. The catch is that you can only access the main site through that default URL. Presuming you have urls that look like customer1.mysite.com and customer2.mysite.com, you need to make sure you've set these as the host headers in the sub sites and then change your DNS so both of these domains point to URL you can see in the portal (e.g. mysite.cloudapp.net).
When considering a multi-tenant solution, ideally you should design your web-application as a single website that is capable of responding to multiple tenants (each of your customers), as opposed to creating a website/web-application for each one of them. This makes updates across the system manageable.
Your web-application can partition and identity different tenants based on several options such as part of the url (e.g myapp/tenant1 vs myapp/tenant2) or via a host header (e.g. tenant1.myapp.cloudapp.net vs tenant2.myapp.cloudapp.net)
HTH
I am looking at migrating a dotnetnuke website to Azure. I need both staging and production versions of the site to be running.
I have looked at using Azure Websites, but at the moment there is no support for SSL on custom domains so this can't be used for the production website. I have migrated the staging site to an Azure Website and now have numerous options for publishing updates (ftp, git, using web matrix).
Due to the constraints of Azure Websites, I used the DNN Accelerator to create a cloud service for the production environment. This set up will allow me to have control over IIS and therefore manage SSL certificates (I think).
The problem I have with this is there does not seem to be any publishing options. The only way I can publish is by connecting to the Azure instance via RDP and then copying the website files onto the files system.
Are there any other ways of publishing? I have looked at converting the website to a WAP, but I believe this has implications when it comes to updating to new DNN versions.
You should never publish your application through RDP since these changes are non-persistent (meaning what you published might disappear after a hardware failure / ...). Adding new instances would also mean that these instances don't have the files you published before.
I suggest you start by looking at the DotNetNuke Azure Accelerator first. If this doesn't fit your needs you might always try to build something yourself, but if you want to say with a regular website and not a web application I wouldn't count on Visual Studio support. In that case you might want to look at creating a package from the command line and using startup scripts to add your website in IIS.
Sounds like you need to use a Start-up task to install the files in the correct place for a Web Role (Cloud Service) Smarx has a nice overview here, MSDN has a wealth of info too http://blog.smarx.com/posts/introduction-to-windows-azure-startup-tasks
Another option is IAAS for Azure with a persisted VM, more work mind you, Cloud Service would be the most efficient and correct solution...
I'm looking into moving an existing app to Azure. It will have an MVC app in one web role and some WCF services in another web role. When live, the site will live at http://www.myapp.com and the services will be at http://api.myapp.com with the MVC app configured to point to the services at http://api.myapp.com.
The problem is when pushing the app to the "stage" configuration on Azure. My understanding is that each push to stage will cause the services to live at a new url (something random like http://4aa5ae2071324585ba5a902f4242a98c.cloudapp.net/). In this case, what is the best way for my MVC app to discover the url of the services?
One option would be to setup a dns entry like http://stage.api.myapp.com and update my DNS CNAME record to point to the new Azure staging url every time I push to stage, but... yuck.
Another option would be to push to stage, get the new urls for the services, RDC to each instance of the MVC role and manually update the configurations. Also yuck.
Is there a simple way to do this? I know I could automate some of the steps above with something like PowerShell, but I'm really hoping there's something baked into the Azure framework that makes this easy. It seems like it would be such a standard scenario.
The only way to dynamically discover what the staging URL will be is to have the instance check its own deploymentID. I am assuming here that the MVC website and the WCF service are in the same deployment. If you check the RoleEnvironment.DeploymentID, you will find that this corresponds exactly to the 'random' URL used in staging (i.e. http://[deploymentID].cloudapp.net).
As long as you are dynamically creating the ChannelFactory on the clientside, it should be able to take its own DeploymentID and find the staging URL.
Of course, this is only useful when deployed in staging. Why don't you simply use the Production slot? That name is stable and you can rely on it or the CNAME (more likely) that you set for it. You can always have multiple hosted services (dev, QA, prod, etc.) and just use the production slot on them.
Don't do what #dunnry is suggesting! Azure has a really good concept of endpoints that solve your problem. And you have access to this info from your RoleEnvironment class.
You can take a look at my blog post on how to get the endpoint from the client. The key part is to create an internal endpoint at which your WCF service is listening. Keep in mind though, you don't necessarily need a new role for this, and personally, I would rather host it in IIS alongide the original Web role & have two of these roles for improved reliability.
This way, it doesn't matter what the deployment is, because the service communication will take place inside that deployment, be it staging or production.