I am beginning to implement Application Insights against an ASP.NET web app with multiple deployments; Prod, Staging, Dev, Dev2. Currently the production slot is sitting empty with deployments in staging, dev and dev2.
The application health tile is showing requests made to the home page of Prod but really I want to see the telemetry for staging, dev and dev2. Is it possible to use 1 Application Insights resource for all slots within my Web App or do I have to create a separate Application Insights for each slot?
You can extend your telemetry with custom properties which will indicate your environment, and then slice and dice according to that property, using either Metric Explorer or Analytics.
You can read more here: Application Insights support for Multiple Environments, Stamps and App Versions, specifically the 'Multi Stamp Support'.
I have resolved the issue. I was enabling Application Insights through the portal for an already deployed application, which only seems to enable telemetry collections for what is deployed in the 'main' production slot. In my case this was the default 'This web app has been successfully created' blue landing screen. Despite my 3 other deployment slots having apps deployed, no data was collected for these.
In order to allow collection for all slots, return to Visual Studio and configure Application Insights through there. You can then redeploy the application to whichever deployment slot you wish and the OOTB telemetry collection will happen.
Related
There is something that I cannot really understand during the AWS CodeStar development flow. Let's say I am developing a web app (MVC) locally, it works and now I want to test it remotely before deploying to the final production environment.
CodeStar has created a Git repository for pushing the changes and it automatically starts the building, testing and deployment tasks. I have few questions:
How can I deploy a change to verify that it works BEFORE doing any sort of commit (avoiding to put dirty commits in the case there are some errors) to the remote environment?
How can I DEBUG a remotely ASP.NET application (breakpoints, etc...)?
How can I tell the application to use a different development database (or any other AWS service) while it is in the development "status" ?
Thank you for your delucidations.
We have two App Services which both appear to be configured identically. Both appear to be using the same service plan, in the same location, and are on the same Pay-As-You-Go subscription. Both are running the same ASP.NET Web Application, pointing to the same database. Both Web Applications also have identical directory structures outside of the Web Application (wwwroot) where required. The only difference between the two is that 'App Service A' has been assigned a custom domain and SSL certificate (which is the user's primary method of access).
We've noticed two fundamental differences however in the way these App Services behave, and cannot understand why -
a) On 'App Service B', when making changes to the Web.Config via the Azure App Service editor, the changes are applied instantally. However, on 'App Service A', a restart of the App Service is required.
However, and more importantly -
a) On 'App Service B', any files uploaded by the user via the Web Application appear in the correct place under the application directory structure (D:\Home\AppSubDir...), and are visible when accessing the site via FTP. However, on 'App Service A', while the Web Application appears to be able to access the uploaded files, they are not visible via FTP or the Kudu tools. When the App Service is restarted, the Web Application then also cannot see the files.
Re-implementing the application using Azure Files/Blob Services is not an option available to us right now given current deadlines. Also, we cannot fathom why if the existing functionality works correctly on one site, why should it differ on another.
We also need files to be preserved outside of the "wwwsite" structure for the sake of application logging (being stored in D:\Home\LogFiles\AppSubDir..). Again, on 'App Service A', these files are not visible.
It seems there's a difference on configuration somewhere between the two sites, but haven't trouble trying to identify exactly what that/those configuation option(s) within Azure could be. Any guidance much appreciated.
David Ebbo (above) has kindly answered this, for anybody else who experiences the same issue. It was simply a case of removing the "WEBSITE_LOCAL_CACHE_SETTING" Application Setting in the Azure Portal, under the "Application Settings" section. After which, reset the App Service and normal behaviour returns.
/Edit - more documentation on the Azure "Local Cache" can be found here - https://learn.microsoft.com/en-us/azure/app-service/app-service-local-cache-overview
I am trying to minimize the cost of running my web app in Azure App Service. I have a Visual Studio 2017 solution with two Web Projects: Web and API (both .NET Core). The entire solution is part of a single GitHub Repo. Before adding the API project, the build and deployment to Azure App Service was automated. My goal is to deploy both projects under the same App Service (to minimize cost) with two subdomains (e.g. www.example.com and api.example.com) and keep everything automated.
Is this something that can be done? Can somebody please help me understand how this can be done? Can those settings be commited?
An Azure App Service Plan can contain multiple web apps. Normally when you use the Azure portal to connect it to source control, Kudu (the tool behind App Service Plans), will create a deployment script for that site.
In case you want to deploy two projects of a single solution (and git repo) to different Web Apps you have to do the following:
Create two web apps under the same App Service Plan
Connect both of them to the same git repo for automated deployments
Modify the deployment parameters
I'm going to suppose you know how to do the first two steps.
To modify the deployment parameters, you could either modify the deployment script by downloading it through Kudu and adapting it or, much simpler, configure it through the portal:
Go the App1 => Application Settings => Add setting PROJECT with value
<path>\<path-to-app1>.csproj
Go the App2 => Application Settings => Add setting PROJECT with value <path>\<path-to-app2>.csproj
Every time you push up a change, both web apps will receive an update, but they will deploy a different part to the web site.
More information can be found here (see last paragraph): https://github.com/projectkudu/kudu/wiki/Customizing-deployments
We have multiple clients and we use Azure web sites to host our web application. When we upgrade a client to a newer version of our software we have to upgrade all of our clients to the latest version.
We would like to be able to upgrade a subset of clients when we release a new version. This would give us the ability to test that the new solution is working properly before we bring all of our clients to the new version. We would like to offer a beta version option to selected clients so that they can access new features of our software and are aware that the version they are using is still in a 'beta' mode.
When we deploy a new version we would like to create a web site just for this new version whilst leaving the other clients on the more stable previous version. To do this we are thinking of writing a reverse proxy that directs traffic to the different versioned web sites depending on the client.
Can we host multiple versions of the web site using the same Azure web site. (IIS directories) The documentation I have read relating to this does not mention being able to build multiple versions of the web site based on different code bases.
Is there a way to set up the build so that each new version is deployed to a directory on the Azure same web site so we can effectively host multiple versions of our app under the same azure web site?
We could do every versioned build to a new Azure web site but this could get quite expensive as we run two instances so as to maintain a good SLA. It is feasible that we could end up with ten versions in the wild at once, running 20 Azure web sites to support these versions could get expensive. How can we save on costs and give our clients a good experience?
You can have up to 5 deployment slots including production on azure web apps. Each slot can use a different branch of your source control system like git or tfs. If you use any of these two, deploy is also automatic (continuous deployment) and you can swap slots any time very fast with minimium to none downtime. Each slot has it's own url for external access.
To save costs, you can run multiple web apps on the same hosting plan. There's no limit for the number of web apps running on the same hosting plan. For each hosting plan it's possible to have 10 small/medium/large instances.
Set up staging environments for web apps in Azure App Service
https://azure.microsoft.com/en-us/documentation/articles/web-sites-staged-publishing/
Azure App Service plans in-depth overview
https://azure.microsoft.com/en-us/documentation/articles/azure-web-sites-web-hosting-plans-in-depth-overview/
Yes this is possible. In management portal, You need to configure the details for the IIS virtual directory or application in the website’s configuration.
Ref - http://blogs.msdn.com/b/tomholl/archive/2014/09/22/deploying-multiple-virtual-directories-to-a-single-azure-website.aspx
Is there a way I can deploy my entire website/webapp to an Azure WebRole without the need of Visual Studio?
Context: We have a test environment where there's an IIS hosted web app where our testers test (of course). The thing is, we want to grab that exact tested web app folder and deploy it "as is" to a WebRole.
Please avoid commenting on our procedure, we have been looking at it and we will eventually change it if we have to, I just need a 'simple' yes(how)/no answer.
IIS Web Deploy can be used to package/migrate/restore IIS applications. It can be enabled while deploying a web role as described in this article and allows to update the web role with the application as deployed in your test environment.
Be aware that only single instance cloud services are supported and that in case of a maintenance operation by the fabric controller, your service will be rolled back to the state created by the initial azure package deployment. (There once was a tool for syncing between multi-instance web deployments but sadly that did not work out too well and is no longer supported. Do not attempt to use or rebuild it.)
Installing and Configuring Web Deploy shows the steps to get web deploy for your local testing IIS while articles on using web deploy like this one show examples for calling the tool.
Another option to evaluate are azure websites and git deployment. This could provide you with a documented and reproducible form of deployment that is not prone to unwanted rollbacks while allowing the service to scale to multiple instances. This option might not work out if the application it too tied to the web roles infrastructure or contains code not suitable for the more restricted web sites environment.
A third option to look at is using CSPack as presented in this article. You basically create a service definition and package up the webapp manually without building it in Visual Studio or TFS.
Yes - make sure you have enabled Remote Access on your webrole. Then copy your web app from your local IIS folder to F:\sitesroot\0 (NOTE - may be E:\sitesroot\0 on same web roles).
Yes, you can write a programmatic interface against Web Deploy from your C# code. If you're deploying to Azure Web Sites, you could also use the Windows Azure Management Libraries to spin up new web sites or clouand deploy them.