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
Related
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 :)
In azure I have a few web apps running using the same database.
But the data never clashes or anything; it's like azure has partitioned the database somehow.
I would like two web apps under different domains to access the same data with a separate api project.
What is the best way to configure this project in azure?
And in visual studio? Can I have them all in the same solution and publish them to the right place?
In Azure, you should setup one Azure SQL Database and multiple API Apps / Web Apps that all use the same connection string pointing to that database.
In Visual Studio, the best way to configure it depends on a couple of things.
If the WebAPIs are exactly the same just with a different domain
You can setup multiple publish profiles for a single Web Application Project. These publish profiles can tie to different release configurations which can transform things in your web.config to account for the differing domains. This is particularly important when using SSL, authentication or something like that.
If the WebAPIs are different for each domain
In this case, you will likely have different projects for each distinct WebAPI. You can have them all in one solution or separate solutions. It might be easier to setup different solutions if you want to enable automated build using Visual Studio Online or something as the Visual Studio build task keys off the *.sln file and if you have multiple Web Application projects in one solution your build outputs will be mixed up which can cause some issues when deploying.
I have an Azure Website. For the sake of this question, the production version of the website runs on example.com, and a test version of the website runs on sandbox.example.com.
The only difference between the two is that they have different configuration.
At present, they are running under different websites, and I deploy the same website to each azure website via git.
I'd like to separate out the Application Insights data. Is there a technique or process that anyone uses - apart from editing the ApplicationInsights.config file in the sandbox environment post deploy?
Or would using a deployment slot handle this in some way?
There was a new blog post about exactly this today: Application Insights Support for Multiple Environments, Stamps and App Versions.
The destination of the telemetry is determined by the instrumentation
key (iKey), which is sent along with every telemetry message. In the
Application Insights portal, similar events and metrics with the same
iKey are aggregated to give you charts of average durations, event
counts, the sum of users, and so on. The iKey appears in two places in
your project. One is in ApplicationInsights.config:
<InstrumentationKey>94843456-2345-3456-4567-324562759284</InstrumentationKey>
If your application has web pages, the iKey also appears in a script
in the head of every web page. Usually, it’s only coded once in a
master page such as Views\Shared\_Layout.cshtml.
To direct telemetry to different application resources, we can create
several resources with different iKeys. Then we only have to change
the iKeys in the application at each transition in its lifecycle –
along with other configuration data such as connection strings,
certificates, and subscriptions.
The article then goes on how to do this in code, confg, etc:
1) Add iKey as a property in Web.config:
2) Instead of using the iKey from ApplicationInsights.config, we’ll
set it in the code. In global.asax.cs.
To avoid confusion, remove the <InstrumentationKey> node from
ApplicationInsights.config.
3) Configure the web pages to pick up instrumentationKey: "#Microsoft.ApplicationInsights.Extensibility.TelemetryConfiguration.Active.InstrumentationKey". This is
the script usually found in View\Shared\_Layout.cshtml.
4) Don’t forget to update your Web.config with appropriate iKey
configuration during the deployment process. You might devise a way of
setting it appropriately as part of your build, but I’ll leave that to
you.
Found this semi-related question: How to support multiple Azure subscriptions for a single application with application insights this is for using by cloud services, and it works!
Microsoft.ApplicationInsights.Extensibility.TelemetryConfiguration.Active.InstrumentationKey = ConfigurationManager.AppSettings["appInsightsKey"];
I have done this in my unity registertypes method, it works there.
In the Azure portal for websites, on the config tab there is a section called App Settings. You can put your different configuration settings here. When publishing, azure will inject those settings into web.config.
Then just use WebConfigurationManager.AppSettings as you would normally and it will pull the injected values.
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 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...