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
Related
I want to deploy multiple .net core API application in single linux based azure app service. I can't find any documentation for that. Can any one give any suggestion or idea how to achieve that.
I have thing one option but don't know is it possible or not? Can I mount azure blob storage space in configuration/ Path mapping in app service and run application from their? is it possible or any other proper way. Please suggest.
Thank you
It doesn't seem possible.
You can refer to the answer in the post below.
Hosting Two Website Under one Web App - Azure Services
IIS can handler mappings and virtual applications and directories, you can't use virtual applications and directories in linux.
If you have more questions about azure web app, you can raise a support ticket on portal. You can also put forward your ideas and suggestions in the feedback, and optimize the product together with Microsoft official.
Hope this can help you.
We are trying to migrate an intranet site to azure scheduled job (like Trigger or function etc).
Basically this intranet site pulls record(data) in desired format.
As expected when i tried to Invoke the site in azure function it is throwing 'unknown host error'. We came to know its possible through gateway or VNET and wanted to know if any other options than this.
Please do share your thoughts & inputs on this.
If you'd like to run functions in the public cloud but have them access on-prem resources, then the main options you'll want to look at are:
Hybrid Connections
Virtual Networks
However note that as of right now, neither of these options are available to function apps configured to run in the consumption plan.
Another possible option is to run functions on premise, using Azure Functions Runtime.
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.
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'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.