+
+
+
+
+
+
+ 10 minute read
+
+
+
+ • By Mathew Charles
+
+ • April 27, 2016
+
+
+
+
+
+
+
+
+
Our team was excited to recently release a preview of the new Azure Functions service at //build. We’ve done some blogging about the service already (e.g. Introducing Azure Functions), but in this post we’d like to delve a bit behind the scenes and discuss how the project started and the journey we’ve taken to arrive at where we are today. We’ll discuss the Functions Runtime, the Dynamic Compute layer (“Serverless”) as well as the Functions Portal, and see at a high level how all those pieces evolved and came together into a cohesive product. It’s been a fun ride for the team, and it’s only just begun :)
+
+
The evolution of this project is a great example of identifying synergies across a bunch of existing platform pieces, and connecting them together into a new product offering. In Azure App Service we already had many of the building blocks in place to enable us to rather quickly execute on the Azure Functions vision. By leveraging these existing assets and bringing in new innovations and functionality we were able to pull the project together pretty quickly.
+
+
WebJobs SDK
+
+
In Chris’s //build talk Introducing Azure Functions he explained how Azure Functions is built on the Azure WebJobs SDK. The WebJobs SDK has existed for a couple years now, and we have many customers happily using it to build backend processing jobs that trigger on a wide variety of event sources. The WebJobs SDK has a simple declarative programming model that makes it very easy to write sophisticated job functions with a minimal amount of code. Here’s an example:
+
+
publicstaticvoidProcessOrder(
+[QueueTrigger("orders")]Orderorder,
+[Blob("processed/{Id}")]outstringreceipt,
+TraceWriterlog)
+{
+ log.Verbose(string.Format("Processing Order {0}",order.Id));
+ // business logic
+ receipt="<some value>";
+}
+
+
+
When hosted by the WebJobs SDK JobHost in a vanilla .NET Console application, this function will be automatically triggered whenever a new queue message is added to Azure Queue “orders” and the queue payload will be deserialized into an instance of the Order POCO. The function also automatically binds to an output Blob using the “Id” property from the incoming message as part of the blob path. With this programming model, your job function just focuses on its business logic and doesn’t have to take care of any of the storage operations. Awesome!
+
+
The hosting model for such functions using the WebJobs SDK is to deploy them as Azure WebJobs. This works great and offers a lot of flexibility, and continues to be a very popular feature of Azure App Service.
+
+
Functions Runtime
+
+
Around the middle of last year, we started discussing what it would take to bring this simple programming model to other languages – we’d had customers ask us for this as well. Not everyone is a .NET C# programmer, yet many would like to use these WebJobs SDK patterns. So we started some prototyping efforts on this and came up with a model that allowed us to leverage the existing tried and true .NET WebJobs SDK runtime, layering on a new JSON description model for the metadata. The result is that you can write the same function as above in Node.js (or other languages):
You’ll notice that this function is structurally the same as the C# function above. That’s because it maps to the same runtime implementation. Declarative code attributes are just one way of specifying metadata. We realized that we could capture the same information in a simple JSON description file. Here’s the corresponding metadata file describing the bindings for this function (i.e. all the bits that are in the declarative attributes in the C# example):
The basic idea is that we can use this metadata to generate an in memory adaptor between various languages and the .NET WebJobs SDK runtime. We effectively generate the C# function you see above, and the method body of that function simply delegates to the actual user function (i.e. the Node.js function you wrote). An Azure Function can then just be a simple function.json metadata file describing the function bindings, along with a collection of one or more script files implementing the function. Here’s the same example as above, using the same metadata file, with the function written as a Windows BAT file:
+
+
SET /p order=<%order%>
+echo Processing order '%order%'
+echo'<some value>'> %receipt%
+
+
+
That same metadata file can be used to describe a function in any of our 7 supported languages. Of course each language has its own quirks and capabilities, and some are more suited than others for various tasks. The main point here is that we can have the same triggering/binding runtime for all of these languages, allowing each language to map to that model in its own way. BAT files are somewhat limited, but through environment variables and file streams, they can both receive inputs and write outputs, which the Functions runtime automatically maps to the underlying Azure Storage artifacts.
+
+
Having Azure Functions build on the core WebJobs SDK means we don’t have to write and maintain different versions of the WebJobs SDK per language, which is a huge engineering win. We have a single core runtime that handles all our binding/triggering logic, and investments we make in that core benefit functions as well as all our WebJobs SDK customers. It also means that all the trigger/binding Extensions that people write for the core SDK can also be used in Functions. We’ll continue investing heavily in the core WebJobs SDK and Extensions both for our traditional customers as well as for Azure Functions.
+
+
WebHook Support
+
+
Another important area we started focusing on was our WebHooks story. The ability for functions to be triggered on Azure Storage events is great, but we’ve had WebJobs customers asking us for the ability to trigger their job functions via WebHook requests as well. We had already experimented with this last year by writing a WebHooks Extension which worked well, but had a big drawback stemming from the fact that WebJobs run under the Kudu SCM site, which means that basic auth credentials are required to make requests. That’s a deal breaker for most WebHook integration scenarios, since you want the ability to hand out a URL with a simple auth code that is restricted to allowing only that endpoint to be reached.
+
+
To address this, we decided to package the Functions Runtime as a site extension that runs in root of a WebApp. This means that it is NOT behind the SCM endpoint, allowing us to achieve the auth patterns required. This enabled us to expose a simple set of authenticated endpoints for WebHook functions. We also integrated the ASP.NET WebHooks library into this, allowing us to leverage the large number of WebHook providers that library supports, giving us first class support for providers like GitHub, Slack, DropBox, Instagram, etc.
+
+
So at this point we had a flexible Functions Runtime that supported the full WebJobs SDK triggering/binding model for 7 languages (Node.js, C#, F#, Bash, BAT, Python, PHP), that also had an HTTP head supporting a wide array of WebHook integration scenarios.
+
+
Dynamic Compute
+
+
In parallel with the above runtime work, we were also having discussions about Serverless Computing and what we wanted to do in that space. We realized that this work we were doing for WebJobs was highly synergistic. We were developing a flexible, multi-language function runtime that could run user code in a sandboxed environment at high scale. However, the traditional WebJobs model requires users to create and manage the WebApp host that those WebJobs run on. What if we were able to abstract that portion of things away so users only had to write the functions themselves, and we’d handle all the deployment and scale concerns? Basically we’d have the WebJobs SDK as a Service. Eureka!
+
+
We spun up a team to go off and investigate that portion of the plan – “Dynamic Compute”. This was the point in the project where we grew quickly from a small handful of people into a much larger team – our scrum meetings were growing daily by 2-3 people it seemed :) Our Dynamic Compute layer is responsible for automatically scaling functions out as load increases, and scaling back when it decreases. The result for the end user is that they don’t have to worry about this at all, and they only get billed for the compute time they actually use. The Dynamic Compute area of the project is large and also includes other service aspects like monitoring and diagnostics, telemetry, etc. This area deserves its own blog post in the future.
+
+
Functions Portal
+
+
The next thing we started focusing on was a portal experience to make it really easy to author and manage these functions. In the traditional WebJobs SDK model, you compile and deploy a .NET Console application (JobHost) that contains all your precompiled job functions. For Azure Functions the deployment model is much simpler. The Functions Runtime was designed to have a very simple file system layout. That facilitates a straight forward Portal UI that operates on those files via the Kudu APIs. We could have a simple portal editor that allowed you to create/edit these files and push them into the function container (the WebApp running the functions). The simple file system model also makes it possible to deploy Azure Functions via ARM templates. That is actually possible today, but not documented well yet.
+
+
The team was able to get a Portal up and running pretty quickly and we were all very excited to be able to start using it to play with the nascent product. With the Portal in place things really started feeling like they were coming together! We were able to start having the wider team play with the product which drove lots of usability discussions/improvements and also helped us start working the bugs out. When the Portal work started, as with the Functions Runtime we had one or two people working on it, but as that early work gained traction and our scope/plans increased, we on-boarded more people. Scrum meetings got larger still :)
+
+
+
+
Templates
+
+
The simple file system model for functions also allowed us to develop the awesome template model you see today in the Functions Portal. We started churning out simple metadata/script templates for common scenarios across the various languages: “QueueTrigger – Node”, “GitHub WebHook C#”, etc. The idea is to have simple “recipes” or starting points for your functions that run immediately out of the box, that you can then customize and extend to your needs. In the future we hope to allow the community to also author such templates to drive an ecosystem.
+
+
+
+
Extensibility
+
+
Another area we focused a lot on leading up to our //build announcement of Azure Functions was a new set of WebJobs SDK Extensions that we made available in Functions. We released the WebJobs SDK Extensibility model last fall, which opened the programming model up to new trigger/binding sources. Our team had already seeded the community with some new useful extensions (e.g. TimerTrigger, FileTrigger, SendGrid binding, etc.) in the WebJobs SDK Exensions repo. We’ve also had community members start authoring their own extensions. Since Functions is built on the SDK, all these extensions can be made available to Azure Functions as well. There were many extensions we knew we wanted to write but didn’t have the time, and with our new larger team we had the resources to start cranking some of those out. In the last couple months we’ve added the following additional extensions and made them first class in Functions: EventHub, DocumentDb, NotificationHub, MobileApps, and ApiHub. This is only the beginning – there are many more extensions planned, and we expect the community to author more as well. We’re also working on an easy model for allowing 3rd parties to onboard their extensions into Functions. Stay tuned for that.
+
+
Another cool thing is that we decided early that we wanted to do all our work open source, just as we have with the core WebJobs SDK and WebJobs SDK Extensions repos. So we created the WebJobs SDK Script containing the Functions Runtime. Similarly, the Functions Portal is also open source: AzureFunctionsPortal.
+
+
In closing, all of the above has been a pretty high level overview of the various pieces of the project and how they came together: the Functions Runtime, Functions Portal, and Dynamic Compute. In future posts, we’ll delve more into the details of these various areas :)
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Chris Anderson
+
+ • May 6, 2016
+
+
+
+
+
+
+
We’re happy to announce that Azure App Service supports Node.js v6.0.0. Node.js v6.0.0 is a major step forward for the Node.js community thanks to the efforts of so many to increase the ES6 compatibility coverage, as well as many performance and security improvements. We’ll follow the developments of v6 closely (including v6.1.0 which came out last night) as it moves towards a new v6 LTS version, at which point we’ll plan on recommending developers creating new apps on App Service use that version, as we currently do for the v4 LTS version. Get started with Node.js on Azure App Service here. Using Node.js v6.0.0 on Azure App Service
+
+
To use Node.js v6.0.0, you can specify your version in your package.json file, as detailed on our Node.js documentation page. It’s as simple as adding the following JSON to the file: "engines": { "node": "6.0.0" }, Once you’ve done that and you redeploy your code via git/CI, our deployment process will select the v6.0.0 Node.js version. We default to using npm version v3.8.6 for Node.js v6.0.0. Getting started with Node.js on Azure App Service
+
+
If you haven’t yet tried using Node.js on Azure App Service, it is one of the easiest ways of hosting a Node.js application in the cloud. Azure App Service makes it easy to create a Node.js website hosting whichever framework you like, using the developer tools you prefer, and all with little to no management overhead. This awesome doc written by Cephas Lin walks you through creating a Node MVC site via Yeoman, creating an Azure Web App via the x-plat cli (npm i -g azure-cli), modifying the port setting to use the environment variable provided by the App Service runtime, creating a git commit with all those changes, and then pushing it to Azure via git. If you have an existing Node.js website that you’d like to try moving to Azure, just try following the steps starting from #4. If you don’t have an Azure subscription, you can get a free trial or get a temporary one for an hour via “Try App Service”.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Every website for a company or personal wants to engage their customers , but if your website takes too long to load then you lose your users. For different types of applications, there are different options to prevent this from happening . In the blog post below we are going to discuss how we can improve Joomla web app fast and respond to users quickly by just making some or all the tweaks mentioned below.
+
+
Enable Joomla Caching
+
+
Caching is not enabled by default when you set up Joomla web app. Joomla does the following when displaying a page:
+
+
+
get the content from its database
+
loads all the plugins, components and/or modules
+
loads your template file
+
finally brings this all together in a single page rendered in visitor’s browser
+
+
+
This workflow of tasks can take time. Joomla has built-in caching mechanism that can help to load the page faster. Joomla supports two types of caching well explained here.
+
+
+
+
Conservative caching is the standard type of caching. The caching process work as described below:
+
+
When a page is requested by a user, Joomla checks if there is a version of that page requested that is in its cache directory. If the page exists and hasn’t expired , Joomla will serve it to the visitor. Otherwise, a cached version of the page is created, and that cached version will be served to the visitor, and to every other consequent visitor, as long as the page is not expired.
+
+
+
Progressive caching process is different from conservation caching. The caching process works as described below:
+
+
When a page is requested by a user , Joomla checks if a cached version of that page exists for that visitor . If its exists and hasn’t expired then it’ll be served to the visitor, otherwise, Joomla will create the cached page for that specific visitor and then will serve it to the user. If another visitor who had visited that same page previously and visits that page the second time, then Joomla will not serve the cached page of the previous visitor, instead, it will create a cached version of that page specifically for that user, and then serves it to him.
+
+
+
+
To enable the Joomla caching,
+
+
+
Go to System -> Global Configuration
+
Click on the System tab and find the Cache Settings
+
+
Select ON - Conservative caching option with cache handle being Windows Cache ( Wincache) and Click on Save
+
+
+
Go to Extensions -> Plugin Manager and Enable the System - Page Cache core plugin.
+
+
Note if this plugin is not enabled, caching will not work even though Global configuration settings is set to use Conservative caching
+
+
+
+
+
You can use additional caching extensions to improve the caching capability of Joomla such as JotCache and Cache Cleaner.
+
+
Use Joomla Memcache caching
+
+
+
You can opt for using Joomla Memcache caching mechanism instead of built-in caching feature. Azure web app supports Memcache protocol with Azure Redis cache. To lean more , read this article.
+
+
Enable Joomla Compression
+
+
Gzip Compression is enabled by default on web app at the server level. But for the application to use the GZip compression , you need to enable it within Joomla configuration. Login to the Joomla web app admin dashboard and go to System -> Global Configuration. Click on the Server tab and enable GZip page compression. Click on Save to save your changes. Use IIS output caching
+
+
The IIS Output Caching feature targets semi-dynamic content. It allows you to cache static responses for dynamic requests and to gain tremendous scalability. Update your web.config and add the following section to cache your content.
To learn more , check out this article. Remove extensions not in use
+
+
Since Joomla would need to identify which extensions to use it has to scan through all the extensions. This can cause your page to take longer to load. If you have any extensions not in use , please remove them from your production app.Note You can have those extensions in your development or testing environment sites to identify the best extension that fits your needs.
+
+
Minify CSS and JS
+
+
Use extensions like JCH Optimize which minifies , compresses Javascript to improve page response time. Use CDN
+
+
Enable Azure CDN with your Azure web app to improve performance. For details , check out this video. Stay up-to-date
+
+
Joomla and its extensions may have updates that can impact the performance of your web application. Make sure you have the latest bits of Joomla CMS , Latest PHP version and the Joomla extensions you have installed within your Joomla app. Optimize your tables
+
+
Optimize your Joomla app database using phpMyAdmin . If you have never used PHPMyadmin with Azure web apps , check out this article first. Select all or some of the tables and Select Optimize Table operation to execute.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Azure app service allows you to auto scale your web app by dynamically adding web server instances to handle the traffic to your web app. Azure app service uses Application Request Routing IIS Extension to distribute your connecting users between your active instances serving up the content. ARR cleverly identifies the user by assigning them a special cookie (known as an affinity cookie), which allows the service to choose the right instance the user was using to serve subsequent requests made by that user. This means, a client establishes a session with an instance and it will keep talking to the same instance until his session has expired. If you already have a web app on Azure app service , just browse the app and use browser debugger ( click on F12) to see the list of cookies. In the list of cookie you will see ARRAffinity Cookie.
+
+
+
+
There are situations where in keeping the affinity is not desired. For example, if you are getting way too many requests from a single user and the requests going to the same web server instance can overload it. If maintaining session affinity is not important and you want better load balancing , it is recommended to disable session affinity cookie. Follow the steps for either Azure portal or Azure resource Explorer to disable the session affinity cookie:
Click on your azure subscription in which your web app is located. Click on resourcegroups
+
+
+
+
+
Click on the resource group where the web app is located. Click on Microsoft.Web. Click on sites **and Select your web app . Click on **Edit to make your changes .
+
+
+
+
+
Search for clientAffinityCookie and set it to false
+
+
+
+
+
Click on PUT to save your changes.
+
+
+
+
+
+
That’s it! You have now disabled the session affinity cookie. You can browse your web app and click on F12 key to access the browser debugger and view the cookies. For an app without Session affinity cookie you will not see ARRAffinity in the list of cookies.
+
+
+
+
Without the cookie the requests for your web app, will be distributed evenly across all the instances serving your web app content. You can achieve better load balancing for your web app.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
I have been fortunate to have an opportunity to Build/Ship/Support on premise products as well as cloud services for Microsoft. One of my biggest take aways from this experience is, “You ship an on-premises product and make it’s issues/bugs your CUSTOMER’S problem. You ship a service in the cloud and now the same issues/bugs are YOUR problem!” Azure App Service Web App team aggress to this philosophy and has been aggressively investing in troubleshooting and diagnostic tools. I highly recommend watching this one hour “short” video (short from troubleshooting standards) from my //Build 2015 session, When bad things happen to good apps. It all started as an experiment outside of the Azure portal, we called it Support Portal. It was a success and was ready to be first-class citizen inside Azure portal. It found a place inside SUPPORT + TROUBLESHOOTING section of your Web App settings. We soon realized that while these tools are great ingredients which are better served as a recipe. In another words, Please tell me what tools to use when and how? This is where Troubleshoot Blade comes handy.
+
+
Troubleshoot blade
+
+
Troubleshoot blade is part of SUPPORT + TROUBLESHOOTING section of key Azure Services like Web Apps, Virtual Machine, SQL. etc. Every participating Azure Service populates this blade with their most common and usually top support issues.
+
+
This blade has three top level sections which we will cover in detail soon.
Ability to submit support request to Azure Customer Support
+
+
+
Resource health check for Web Apps
+
+
Resource Health Check for Web Apps is like a doctor that attempts to diagnose an issue (runtime issues) with your application to be either service level outage or application specific issue. It makes this determination mainly by reading two distinct signals. First signal is health of Canary Web App (static web page running under every VM instance) and second signal is active live site incident (service issue). - Scenario 1:IF Canary Web App signal IS healthy (HTTP 200 OK) and there IS NO active live site incident impacting your Web App THEN it will say Healthy, meaning we think life is good, but if you think otherwise then it is most likely an application issue.
+
+
+
Scenario 2: IF Canary Web App signal ISNOT healthy (HTTP 200 NOT OK) and there IS an active live site incident impacting your Web App THEN it will say Unhealthy, meaning we think life is not good and someone in Redmond is actively working to resolve this issue.
+
Scenario 3: IF Canary Web App signal ISNOT healthy (HTTP 200 NOT OK) and there ISNO active live site incident impacting your Web App THEN it will say Unhealthy meaning we think life could be better and doctor needs to perform more diagnostics.
+
+
NOTE: Resource Health Check for Web Apps is NOT available to FREE and Shared offerings (as there is no SLA for these offerings and hence no canary web app). Putting an analogy here would be recipe for disaster, so I would stop right here.
+
+
+
+
+
Common solutions
+
+
This is the place where we put together a recipe (step-by-step troubleshooting guide) to resolve a specific issue using some of the ingredients (troubleshooting tools). Here we list out our common supportability issues based on symptoms or scenarios. In this blog post I will pick one scenario and explain the steps in detail. #### My App is returning HTTP 5xx errors
+
+
You are here because resource health check told you it is Scenario 1 or Scenario 3.
+
+
Assess the HTTP errors impact using Live HTTP traffic chart
+
+
When my Web App starts giving HTTP 5xx errors my 1st instinct is to try and asses the impact. Are all requests failing? What percent of requests are failing? etc. “Live HTTP traffic” chart is a great way to assess the impact. This tools shows you aggregated live traffic for the selected Web App across different hostnames. There is hardly 10 seconds delay in charting. It basically aggregates your HTTP server logs from all the instances, including multi region deployments behind traffic manager. It then splits our success vs. failures and charts them. Image above shows about 30% of my requests are failing and it is not entire Web app down situation. (Blue represent success, Red represents failures). I can choose to filter the graph by hostnames etc.
Now we know that about 30% of my requests are failing, would not it be nice to know if these failures are tied to single instance (if my web app is running multi-instances) or distributed across all? Or I just want to check the load distribution across various instances, or may be check CPU/Memory usage for last one hour across various instances. All of above mysteries can be solved by clicking on this view. This view provides you critical statistics about your Web App (site) per instances over span of Last 1 hour, Last 24 hours and Last 5 days Image above shows I have two instances (RD0003FF451561 and RD0003FF454F62) in last one hours. If I had more or less instances in last 24 hours or five days, it would show them all regardless of current configuration. I think that’s kind of cool, especially when investigating past issues. The mage above also confirms my load was equally distributed across both the machines and both of them were giving HTTP 5xx, so this issue is not tied to a single instance. I can also check the CPU/Memory/Network IO etc. by scrolling down the charts.
+
+
Attempt to resolve the issue by using Advanced Application restart
+
+
If the previous step helped you identify an instance that is “bad” then this blade is a pure blessing. Just select the “bad” instance and click on Restart. If it is all of them then you can select them all with Restart Sleep Timer of 90 seconds and click away the Restart button. Yep, it’s that easy! ]
+
+
Let’s see what the “Restart button” does in background.
+
+
+
For start, this is NOT same as Restarting your Web App. Web App Restart is ruthless beast that goes out and fires restart across all instances at the same time. (If you have single instance then the impact is the same).
+
This is NOT same as Rebooting your VM. Well in Azure App Service, you can’t reboot your VM (yet), at least by choice. (If you really want to reboot the VM instance, then simply trick the system by changing the scale Up or Down. That is switch to medium from small or large etc.)
+
This is simply graceful restart of your Web App process (w3wp.exe) in an overlapped recycling manner. Similar to Costco registers where they open new lane for check out before closing the old one. If you happen to be in the old one (existing requests to your web app) you get 90 seconds to finish your business (well not quite like Costco, but you get the point), while all new checkouts (new incoming requests) goes to the new open lane. Thus minimizing the impact down to few handful requests.
+
“Restart Sleep timer” of 90 seconds adds additional layer of protection by waiting for 90 seconds before going to other instances.
+
If you have multiple Web Apps running on same instance then it does not impact other Web Apps. It only restarts Web App you initiated this operation from.
+
+
+
Identify highest CPU/Memory consuming Web app(s) within your App Service Plan
+
+
Let’s refresh our memory little bit and bring back Resource Health Check Scenario 3. This blade helps you find out the offending Web App in the App Service Plan. We named this blade “App Service plan Metric per Instance”. It does exactly what it says. This view will help you quickly identify highest CPU/Memory consuming Web App (Site) in your Plan. Above image indicates that I have 2 Web Apps (Sites) in the App Service Plan. DemoDaas seems to be the one using all CPU and Memory in this case. At the same note, you can also observe that PHPDemo could be taking all CPU and Memory, hence impacting performance for DemoDaas. You can use this view to separate out the culprits from victims and go to Step 3 to click on “Restart Button” for culprit Web App. Finally, Restart is really not an answer to all the problems and that’s where the Restart button is not that glorious. If HTTP 5xx is because a bug in your application and not the hostile surrounding it found itself in, then restarts are not really going to help. This is where we move to next Step.
+
+
Check out the application event logs to understand the potential root cause
+
+
This is really old school event viewer logs. The beauty of this feature here is that, these logs are aggregated across multiple instances (if you have multiple instances) into single view. You can filter them per instance or other attributes of your choice. It only contains logs are that specific to this Web App and it’s life cycle, so they are pre filtered for your need.
+
+
Enable FREB Logging
+
+
This step will help you identify source of HTTP 5xx errors or Slow Performance. It won’t really tell you exact root cause (unless you are the developer who check-in had the bug then knowing the source is usually enough). Please watch this short video by Felipe Barreiros that explains the feature. #### Recommended documents, Profilers like App Insight, New Relic etc.
+
+
It finally provides links to some recommended documentations to will help peel the onion even further. Application bug that are easily reproducible are best root caused using some sort of profiler or remote debugging inside stage/QA environment.
+
+
Need help?
+
+
If none of above helped and you want to engage Microsoft Azure Support team then journey begins by clicking on open a Support request.
+
+
+
+
Do try out other common scenarios and let us know the feedback by simply clicking on Feedback smiley at the top of the blade.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
As part of App Service Certificate (ASC) offering, we now support certificate deployment through Azure Key Vault (AKV). ASC stores the private certificate into a user provided Key Vault Secret (KVS). When an ASC is deployed into a Web App, Web App Resource Provider (RP) actually deploys it from the KVS associated with ASC. Essentially, ASC and Web App are loosely connected through Azure Key Vault. If you manually upload a private certificate into a KVS then you can use the same feature for deploying your own certificate into Web App through AKV.
+
+
Prerequisites
+
+
In order to use this feature, first you need an Azure Key Vault. This Key Vault needs to be in the same subscription as your web app but it need not be in the same region as your Web App. Web App doesn’t have a runtime dependency on Key Vault. When you deploy a certificate, Web App RP reads it from the KV and caches it in its management database. It need not even be in the same resource group. If you don’t have a KV then you can use the following PowerShell command to create a new one:
By default, the Web App RP doesn’t have access to customer KV. In order to use a KV for certificate deployment, you need to authorize the RP by executing the following PowerShell command:
The RP requires read access to KV. abfa0a7c-a6b6-4736-8310-5855508787cd is the RP service principal name and it remains same for all Azure subscriptions. Note for Azure Gov cloud environment you will need to use 6a02c803-dafd-4136-b4c3-5a6f318b4714 as the RP service principal name in the above command instead of ‘abfa0a7c-a6b6-4736-8310-5855508787cd’. Last thing you need is a KVS that contains the PFX certificate you would like to deploy. Before deploying a certificate, the RP performs the following checks on KVS:
+
+
+
It actually contains a PFX certificate that’s not password protected
+
Content type of the secret should be ‘application/x-pkcs12’
+
+
+
You can use the following PowerShell snippet to upload a PFX certificate from your machine into a Key Vault secret:
+
+
$pfxFilePath="F:\KeyVault\PrivateCertificate.pfx"
+$pwd="[2+)t^BgfYZ2C0WAu__gw["
+$flag=[System.Security.Cryptography.X509Certificates.X509KeyStorageFlags]::Exportable
+$collection=New-ObjectSystem.Security.Cryptography.X509Certificates.X509Certificate2Collection
+$collection.Import($pfxFilePath,$pwd,$flag)
+$pkcs12ContentType=[System.Security.Cryptography.X509Certificates.X509ContentType]::Pkcs12
+$clearBytes=$collection.Export($pkcs12ContentType)
+$fileContentEncoded=[System.Convert]::ToBase64String($clearBytes)
+$secret=ConvertTo-SecureString-String$fileContentEncoded-AsPlainText–Force
+$secretContentType='application/x-pkcs12'
+Set-AzureKeyVaultSecret-VaultNameakurmitestvault-NamekeyVaultCert-SecretValue$Secret-ContentType$secretContentType# Change the Key Vault name and secret name
+
+
+
Deploying Key Vault Certificate into Web App
+
+
After completing all prerequisites, now we are ready to deploy the certificate into a Web App. Currently, Azure portal doesn’t support deploying external certificate from Key Vault, you need to call Web App ARM APIs directly using ArmClient, Resource Explorer, or Template Deployment Engine. I will be using ARMClient for the rest of this blogpost. You can also use Resource Explorer to do everything described below.
+
+
We need to find the resource group for certificate resource before calling the ARM APIs as it ideally we should use App Service Plan’s resource group, you can find this from ‘serverFarmId’ property of the site resource:
+
+
ARMClient GET /subscriptions/fb2c25dc-6bab-45c4-8cc9-cece7c42a95a/resourceGroups/Default-Web-EastAsia/providers/Microsoft.Web/sites/appservicecertificatedemo?api-version=2016-03-01`
+
Once you have these values, you can use the following ARMClient command to upload the certificate into your Web App. Note that in order to call this API, the caller needs to have write access to the Key Vault account specified in the request body.
After executing this command, the certificate would be listed under ‘Custom Domains and SSL’ blade in Azure portal. Now you can use this certificate to create SSL bindings just like a regular certificate as described in this article. You can also use the following ARMClient command to create SSL binding for custom hostname ‘appservicecertificatedemo.com’. If the custom hostname you want to use in this call is not already added to the website, then you should also create the DNS records required for verification as described here.
+
+
Command:
+
+
ARMClient.exe PUT /subscriptions/fb2c25dc-6bab-45c4-8cc9-cece7c42a95a/resourceGroups/Default-Web-EastAsia/providers/Microsoft.Web/sites/appservicecertificatedemo/hostnameBindings/appservicecertificatedemo.com?api-version=2016-03-01 "{'Location':'East Asia','properties':{'sslState':'SniEnabled','thumbprint':'F454D4277D449D8CD2384B63D7AA2F2F7F3766E4'}}"
+
If you want to create an IP-based SSL binding instead of SNI then replace ‘SniEnabled’ with ‘IpBasedEnabled’ in the ARMClient command. You can also access this certificate from your Web App once it’s uploaded instead of creating SSL binding as described in this blog.
+
+
Rotating Certificate
+
+
Once a certificate has been deployed through KVS, follow these steps to rotate it:
+
+
+
Update the KVS with a new certificate
+
Call the Create Certificate API again with the same body. This would update the certificate resource and migrate all Web Apps that are using it to the new certificate The Web App RP has a batch job that periodically syncs all Web App certificate resources with the associated Key Vault secret so if you don’t call the Create Certificate API after updating the KVS, then this periodic job would eventually migrate the Web Apps to the new certificate.
+
+
+
Deploying other secrets from Key Vault
+
+
You may ask, deploying a certificate from KVS is fine. But what about deploying other secrets from KV such as connection strings? Currently, our platform only supports certificate deployment through Key Vault. You can however, use this feature and write some custom code to deploy generic Key Vault secrets into your Web App. Say your application requires a symmetric encryption key and a SQL connection string. You can follow these steps to deploy your app secrets through Key Vault:
+
+
+
Store the connection string and symmetric key in a Key Vault as individual secrets
+
Create a self-signed certificate and authorize it to read Key Vault Secrets as described here
+
Store this certificate in the Key Vault
+
Deploy the certificate through KVS and create the required App Setting so that it would be available locally for your Web App to use
+
In the Application_Start event, use this certificate to read secrets from Key Vault and update web.config if required
+
+
+
ARM Template to deploy and Assign KV Certificate
+
+
You can use the following ARM template to deploy a certificate through KVS and create SSL bindings for a custom hostname: https://azure.microsoft.com/en-us/documentation/templates/201-web-app-certificate-from-key-vault/
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
“Why was my Web App down?” is the million-dollar question that usually follows with more questions than answer, for example: “Was it cloud provider issue?”, “Was it a deployment I rolled out?”“Was it just abnormal increase in traffic? etc. Getting to the bottom of the issue requires tedious activities like pulling off few logs, aligning them with correct times or even calling Support for help, and this is just first layer of investigation a.k.a “Isolation” or “Peeling the onion”. This process should not take hours and we agree! Introducing Failure History (appLens) for Azure App Service Web App: A tool to visualize various data points in few seconds!
+
+
What is Failure History?
+
+
Let me start with little background on the project. Project’s code name is MDH (Make David Happy). David is our rock star engineer (@Lamboin) who spends his day working on customer reported issues. He is the one who tries to answer the million-dollar question for our customers (“Why was my Web App down?”). We watched him pull variety of logs, overlay them and then align the time frames to get the 1st level of isolation. This process was MDS (Making David Sad), and that was one of the inspirations to kick start this project. Failure History (appLens) is an attempt to solve problem described above. It is self-service RCA tool that helps you visualize variety of data points in your web app life cycle in matter of seconds. This visualization helps answer the questions that usually follow our million-dollar question.
+
+
How it works
+
+
Failure History (now known as AppLens) can be accessed from “Settings” blade for your Web App.
+
+
+
+
With current release Failure History (appLens) focus on 3 core data points, which are
+
+
+
Availability
+
Requests and Failures
+
Deployments
+
+
+
Let’s drill down on each of them with a real life examples.
+
+
Availability
+
+
This an overlay chart of 2 distinct data points, Organic availability and Container Health (Canary Web App).
+
+
Organic availability is an aggregated data points of successful HTTP requests vs. Failed HTTP requests to your web app. On the other hand Container Health (Canary Web App) is an aggregated data points of successful HTTP requests vs. Failed HTTP requests to a static page that resides inside same VM (container) as your web app. Both of them are weighted number in percentage. To learn more about the Canary Web App, please read “Resource Health Check” section of my previous blog.
+
+
I call this chart “Is it me? vs. Is it you?” chart. This literally is best way to isolate application issues vs. platform issues. This chart tries to answer “Was it cloud provider issue?” question.
+
+
+
If you see Organic availability chart taking a dip while Container Health chart is at 100% then it surely is an application issue.
+
If you see Organic availability chart taking a dip as well as Container Health chart taking a dip then it is most likely platform issue (App Service issue). The reason I say “most likely” is because, a bad web app in app service plan can potentially freeze the container and cause Container health chart to take a dive.
+
+
+
+
To see individual charts at appropriate scale I recommend you filter out an individual graphs by selecting them using radio buttons. Canary Web App concept is NOT applicable to FREE and SHARED web apps and hence that data will be missing for them.
+
+
+
Scenario 1: Platform issue
+
+
]
+
+
Scenario 2: High load freezing VM
+
+
+
+
Requests/Failures
+
+
This is an aggregated data points of total incoming HTTP requests vs. Failed HTTP requests to your web app. This chart can be used to answer “Was it just abnormal increase in traffic?” question. If you see drop in Organic availability chart (right above this chart) following large increase in Total incoming HTTP requests (HTTP Requests counter) then you can conclude that downtime could be related to increase in traffic and maybe I should consider turning on Auto Scale. You can also use this chart to answer “What % of my traffic was failing?” question.
+
+
+
To see individual charts at appropriate scale I recommend you filter out an individual graphs by selecting them using radio buttons
+
+
+
Scenario 3: Increased traffic causing scale out
+
+
+
+
Deployments
+
+
This is simple data point indicating time frames when you or someone in your organization did deployment to your web app. This chart tries to answer “Was it a deployment I rolled out?” question.
+
+
+
This only shows deployments done via web deploy or Kudu endpoint. It does not cover deployments done using FTP. This is a great data point to co-relate with availability charts and see if Organic availability tanked right after the deployment? This way you can be sure if availability drop is related to your deployment or not.
+
+
+
Scenario 4: Bad deployment
+
+
+
+
Finally, few disclaimers for this version of Failure History (appLens):
+
+
+
Failure History (appLens) data is at least 15 minutes behind. For issues that are currently happening and you need help then please use our troubleshoot blade.
+
Failure History (appLens) data can go back 7 days to RCA (root cause analysis) issues that happened in past
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Chris Anderson
+
+ • June 6, 2016
+
+
+
+
+
+
+
+
+
We’ve recently made updates to the WebJobs Portal experience in the Azure Portal designed to make it easier to set up a scheduled triggered WebJob, access the trigger URL for triggered WebJobs, and other operations like viewing your logs.
+
+
Creating a scheduled WebJob
+
+
+
+
As you can see in the screenshot, to create a scheduled WebJob requires 3 steps, in addition to the usual steps of naming and uploading your code.
+
+
+
Select “triggered” as the WebJob type option
+
Select “Scheduled” as the WebJob triggers option
+
Add a cron tab expression
+
+
+
To create a scheduled WebJob in the new experience, you just provide a cron tab expression as part of the creation of your triggered WebJob. This will add a schedule property to your setting.job file which Kudu will then use to call your WebJob. Importantly, this requires “always on” to be enabled. If you wish to have a triggered WebJob called on a schedule without “always on” being required or if the schedule you require is too complicated to be expressed as a cron tab expression, you can continue to use Azure Scheduler by choosing the “WebHook” option for “Triggers”, and then providing the trigger URL to an Azure Scheduler job. This is a departure from how we previously did scheduled jobs, where we’d automatically create a Azure Scheduler job for you. We had a lot of feedback that this wasn’t optimal for all scenarios, so we’ve moved to this new model.
+
+
Updates to browse WebJobs experience
+
+
In addition to the triggered WebJobs updates, we’ve redone the browse experience to both bring it in line with the other browse experiences in the portal, as well as expose the trigger URL for triggered WebJobs in an easier to access way. One major experience change is that the logs, delete, and run buttons at the top of the blade correspond with the selected row. You can see this experience in the picture below.
+
+
+
+
We’re always looking for more feedback on the WebJobs experience. You can leave feedback on the WebJobs UX experience at our feedback site or in the comments section down below.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Adrian Hall
+
+ • June 16, 2016
+
+
+
+
+
+
+
+
+
Azure Mobile Apps provides an awesome client SDK for dealing with common mobile client problems - data access, offline sync, Notification Hubs registration and authentication. Sometimes, you want to be able to do something extra in the client. Perhaps you need to adjust the headers that are sent, or perhaps you want to understand the requests by doing diagnostic logging. Whatever the reason, Azure Mobile Apps is extensible and can easily handle these requirements.
+
+
Android (Native)
+
+
You can implement a ServiceFilter to manipulate requests and responses in the HTTP pipeline. The general recipe is as follows:
+
+
ServiceFilterfilter=newServiceFilter(){
+ @OverridepublicListenableFuturehandleRequest(ServiceFilterRequestrequest,NextServiceFilterCallbacknext){
+ // Do pre-HTTP request requirements here
+ request.addHeader("X-Custom-Header","Header Value");// Example: Adding a Custom Header
+ Log.d("Request to ",request.getUrl());// Example: Logging the request ListenableFuture
+ responseFuture=next.onNext(request);
+
+ Futures.addCallback(responseFuture,newFutureCallback(){
+ @Override
+ publicvoidonFailure(Throwableexception){
+ // Do post-HTTP response requirements for failures here
+ Log.d("Exception: ",exception.getMessage());// Example: Logging an error
+ }
+
+ @OverridepublicvoidonSuccess(ServiceFilterResponseresponse){
+ // Do post-HTTP response requirements for success here
+ if(response!=null&&response.getContent()!=null){
+ Log.d("Response: ",response.getContent());
+ }
+ }
+ });
+ returnresponseFuture;
+ }
+};
+
+MobileServiceClientclient=newMobileServiceClient("https://xxx.azurewebsites.net",this).withFilter(filter);
+
+
+
You can think of the ServiceFilter as a piece of middleware that wraps the existing request/response from the server.
+
+
iOS (Native)
+
+
Similar to the Android case, you can wrap the request in a filter. For iOS, the same code (once translated) works in both Swift and Objective-C. Here is the Swift version:
As you might exepct given the Android and iOS implementations, the JavaScript client (and hence the Apache Cordova implementation) also uses a filter - this is just a function that the request gets passed through:
+
+
functionfilter(request,next,callback){
+ // Do any pre-request requirements here
+ console.log('request = ',request);// Example: Logging
+ request.headers['X-Custom-Header']="Header Value";// Example: Adding a custom here
+
+ next(request,callback);
+}
+
+varclient=newWindowsAzure.MobileServiceClient("https://xxx.azurewebsites.net").withFilter(filter);
+
+
+
Xamarin / .NET
+
+
The equivalent functionality in the .NET world is a Delegating Handler. The implementation and functionality are basically the same as the others:
+
+
publicclassMyHandler:DelegatingHandler
+{
+ protectedoverrideasyncTaskSendAsync(HttpRequestMessagemessage,CancellationTokentoken)
+ {
+ // Do any pre-request requirements here
+ request.Headers.Add("X-Custom-Header","Header Value");
+
+ // Request happens here
+ varresponse=awaitbase.SendAsync(request,cancellationToken);
+
+ // Do any post-request requirements here
+
+ returnresponse;
+ }
+}
+
+// In your mobile client code:
+varclient=newMobileServiceClient("https://xxx.azurewebsites.net",newMyHandler());
+
+
+
General Notes
+
+
There are some HTTP requests that never go through the filters you have defined. A good example for this is the login process. However, all requests to custom APIs and/or tables get passed through the filters. You can also wrap the client multiple times. For example, you can use two separate filters - one for logging and one for the request. In this case, the filters are executed in an onion-like fashion - The last one added is the outer-most. The request goes through each filter in turn until it gets to the actual client, then the response is passed through each filter on its way out to the requestor. Finally, note that this is truly a powerful method allowing you to change the REST calls that Azure Mobile Apps makes - including destroying the protocol that the server and client rely on. Certain headers are required for Azure Mobile Apps to work, including tokens for authentication and API versioning. Use wisely. (Cross-posted to My Personal Blog)
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
An exciting new preview feature which was recently added to Azure Active Directory is Azure Active Directory B2C. “B2C” stands for “Business to Consumer” and allows a developer to add user and login management to their application with very little (if any) coding. This also includes login integration with social identity providers like Facebook, Amazon, LinkedIn, etc. Check out their documentation and blog posts for more details. My colleague Swaroop from the Azure AD team also has a nice //Build video where you can see it in action. From my perspective, App Service Authentication / Authorization (Easy Auth) shares a similar goal of B2C, which is to make it really easy to build identity into your application. We saw a great opportunity to make these features work well together, giving you both an identity management system as well as login and OAuth token management without requiring a single line of code. In this post, I’ll describe how you can use Easy Auth to add Azure AD B2C capabilities to your App Service Web App.
+
+
Creating an App Service Web App
+
+
Hopefully you know how to do this by now. Go ahead and create a web app (or an API/mobile/function app – they all work the same way) and make a note of the URL. For example, when drafting this blog post and walking through the steps, I created https://cgillum-b2c-preview.azurewebsites.net. Use your own web app URL in place of mine wherever you see it in these instructions. However, don’t configure Authentication / Authorization yet. We’ll do that in a later step.
+
+
Creating the Azure AD B2C Tenant and Application
+
+
We don’t currently support an “Express” setup of B2C like we do for classic Azure AD, so these steps will need to be done manually. You can find detailed instructions for this below:
Note that in step 2, you’ll need to use the https address of the web app you previously created as the Reply URL and you must suffix it with “/.auth/login/aad/callback” (again, in my case this is https://cgillum-b2c-preview.azurewebsites.net/.auth/login/aad/callback). Once this is done, you should have an application in the B2C portal which looks something like the following:
+
+
+
+
Make a note of the Application Client ID that you see in the Application blade. You’ll need this in a later step.
+
+
Adding a Sign-Up/Sign-In Policy
+
+
For simplicity, we’ll create a single B2C “policy” which allows the user to sign in or sign up if they don’t already have an account. In the portal, this is the Sign-up or sign-in policies selection. Add a new policy (assuming you don’t have one already). The details of the policy don’t matter too much, so I won’t provide any specific guidance here. There are a lot of options, including whether to configure social identity providers. In my case, I set up email login as well as Google and Facebook. To get started quickly, I suggest you use the email sign-up policy. When you’re done, make a note of the Metadata Endpoint for this policy URL which gets generated, like in the screenshot below:
+
+
+
+
Azure AD B2C supports other policy types as well, but the combination sign-up/sign-in is currently the one best suited for Easy Auth login integration.
+
+
Configure Easy Auth
+
+
Now let’s go back to the web app we previously created. We’ll configure Easy Auth with Azure AD using the Advanced configuration option. The steps are:
+
+
+
In the portal in the context of your web app, click the Settings icon.
+
Set App Service Authentication to On
+
Configure Azure Active Directory
+
Select the Advanced management mode
+
Set the Client ID to be the Application Client ID from before.
+
Set the Issuer URL to be the Metadata Endpoint for this policy URL value that was generated from your sign-in/sign-on B2C policy.
+
Click OK and then the Save icon to save your changes.
+
+
+
Your Authentication / Authorization settings blade should look something like the following:
+
+
Now if you navigate to your site, you should see the B2C login page that you configured previously. Depending on how it was configured, you can sign up using social identity credentials or you can sign up using username (or email) and password. You will also be prompted for additional registration information, such as your name, etc (again, all dictated by the policies you configured). Here is an example of what your initial sign-in page might look like. Notice the link on the bottom of the image which allows users to register:
+
+
+
+
Below is an example of what your “sign-up” registration page will look like. If you selected the email option, Azure AD B2C will even implement the email verification workflow for you.
+
+
+
+
That’s it! You’ve now created a skeleton B2C web application that allows users to sign-up and sign-in without writing any code or deploying any databases! I’ve used all the defaults in terms of styling, but Azure AD B2C does allow you to customize the look and feel of these pages to match your own application branding, if you choose. See the B2C UI customization documentation for more information. Once signed in, you can write code which inspects the inbound HTTP headers and/or the /.auth/me endpoint (both described in my earlier Token Store post) to get more information about the user. If you’re running an ASP.NET application, you can also enumerate the claims on the current ClaimsPrincipal. Specifically, you should be able to see all the claims that you configured in your B2C policy. This is great because you don’t need to provision your own database which contains this information – it’s built into the B2C directory and can be accessed using the features of Easy Auth.
+
+
Azure AD B2C Social Providers vs. Easy Auth Social Providers
+
+
One thing you may have noticed is that there are now two ways to incorporate social logins into your web app: using B2C policies or configuring them directly in the Authentication / Authorization settings. Ideally, there would be just one which is common between the two technologies. Unfortunately we’re not there yet. Until then, here are some important differences between social providers in Azure AD B2C and Easy Auth:
+
+
+
Different identity providers: B2C and Easy Auth support different providers. At the time of writing, B2C supports MSA, Facebook, Google, LinkedIn, and Amazon identities. Easy Auth, however, supports MSA, Facebook, Google, and Twitter.
+
Client-Directed Login: Both B2C and Easy Auth support server-directed social logins where the login flow is controlled by the browser. However, only Easy Auth supports client-directed logins where the login flow is controlled by the client operating system (typically a mobile OS or a JavaScript client).
+
User Claims: B2C provides a somewhat normalized set of user claims for each login. These claims are similar to what you’d see in an ordinary AAD login. The claims are also configurable. With Easy Auth, however, the claims are static and in many cases are different for each identity provider.
+
OAuth Tokens: With Easy Auth, the application code has direct access to the provider-specific OAuth tokens. This is useful if you want to make graph API calls on behalf of the logged-in user (for example, calling the Facebook Graph to post a photo to the user’s timeline). B2C, however, does not expose the provider OAuth tokens to your application code.
+
+
+
If social identity integration is important to your app, then consider these differences very carefully when deciding between the two options. Note that these limitations will certainly change as both Easy Auth and Azure AD B2C evolve over time, hopefully in a way that better aligns them together (this is certainly our goal, internally).
+
+
Taking it to the Next Level
+
+
This post demonstrated using a single, global B2C policy within a web app in a way that doesn’t require any code or database setup. If you are a mobile, API, or SPA app developer, I have written a followup post which goes into more details about how to use code to dynamically select B2C policies, how to set up token refresh, and even included a sample SPA app which demonstrates these capabilities. Check it out in Part 2 of the App Service + Azure AD B2C series.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
The release of ASP.NET Core 1.0 was announced today! ASP.NET Core 1.0 supports modern web development with its lightweight and modular design. ASP.NET Core is also cross-platform ready and open source. You can read all the details for the release in this announcement. Visual Studio 2015 Update 3 was also announced today with support to build .NET Core apps in Visual Studio. Azure App Service is ready to welcome your ASP.NET Core 1.0 apps. Please see the ASP.NET Core 1.0 announcement for pointers on getting started. Great resources are also available on the ASP.NET Core documentation page. To get started bring your own ASP.NET Core repo or select a sample from Visual Studio. To get started in Visual Studio 2015 navigate to New -> Project -> Web and select an ASP.NET Core sample. Request a Git repo on sample creation
+
+
+
+
Create a web app in Azure App Service and configure Local Git as the deployment source as described in documentation here. Copy the Git URL from the Settings -> Properties blade of your app in the Azure Portal. From your ASP.NET Core app Git repo push the content to Azure App Service using the Git URL copied. The Kudu deployment engine running in Azure App Service is able to detect ASP.NET Core apps and generate a custom deployment script for these apps. If you would like to explore and customize the deployment script generated for Azure App Service deployment you can easily access this script. Navigate to the Kudu SCM management app running alongside the web app from the Tools -> Kudu blade of your app in the Azure Portal.
+
+
+
+
The first step in the deployment script is a NuGet restore with the home drive of the app as the restore location. Restore will be revisited for subsequent deployment only if new dependencies are detected. The next step in the deployment script detects the type of project. If the project originated from Visual Studio and a .sln file is available the deployment engine will run msbuild and then use the new dotnet.exe utility to publish with a no build flag. Otherwise use the new dotnet.exe utility to build and publish. All build actions are completed on the target Azure App Service hosting environment. An alternate Visual Studio deployment option bypassing source control is using the Publish action which will leverage WebDeploy to deploy to Azure App Service instead of leveraging the Kudu deployment engine. With this option build actions would be completed in the source development environment as opposed to build actions being completed in the target Azure App Service hosting environment.
+
+
+
+
If you don’t have an Azure account you can still try ASP.NET Core 1.0 on Azure App Service free of charge and commitment with our Azure App Service free trial. Looking forward to feedback and questions on the Azure App Service forum.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Offline Sync with Azure Mobile Apps and Apache Cordova
+
+
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Adrian Hall
+
+ • June 29, 2016
+
+
+
+
+
+
+
+
+
In the past, I’ve introduced you to a TodoList application built in Apache Cordova so that it is available for iOS, Android or any other platform that Apache Cordova supports. You can find the QuickStart for Apache Cordova from within the Azure Portal, and read about it within our documentation. Recently, we released a new beta for the Azure Mobile Apps Cordova SDK that supports offline sync, which is a feature we didn’t have. Underneath, the Cordova offline sync functionality uses SQLite - this means it isn’t an option at this point for HTML/JS applications. We’ll have to work out how to do this with IndexDB or something similar, but for now that isn’t an option without a lot of custom work. Let’s take a look at the differences.
+
+
Step 1: New variables
+
+
Just like other clients, I need a local store reference and a sync context that is used to keep track of the operational aspects for synchronization:
+
+
varclient,// Connection to the Azure Mobile App backend
+ store,// Sqlite store to use for offline data sync
+ syncContext,// Offline data sync context
+ todoItemTable;// Reference to a table endpoint on backend
+
+
+
Step 2: Initialization
+
+
All the initialization is done in the onDeviceReady() method. I have to set up a model so that the SQLite database is set up to match what is on the server:
+
+
functiononDeviceReady(){
+
+ // Create the connection to the backend
+ client=newWindowsAzure.MobileServiceClient('https://yoursite.azurewebsites.net');
+
+ // Set up the SQLite database
+ store=newWindowsAzure.MobileServiceSqliteStore();
+
+ // Define the table schema
+ store.defineTable({
+ name:'todoitem',
+ columnDefinitions:{
+ // sync interface
+ id:'string',
+ deleted:'boolean',
+ version:'string',
+ // Now for the model
+ text:'string',
+ complete:'boolean'
+ }
+ }).then(function(){
+ // Initialize the sync context
+ syncContext=client.getSyncContext();
+ syncContext.pushHandler={
+ onConflict:function(serverRecord,clientRecord,pushError){
+ window.alert('TODO: onConflict');
+ },
+ onError:function(pushError){
+ window.alert('TODO: onError');
+ }
+ };
+ returnsyncContext.initialize(store);
+ }).then(function(){
+ // I can now get a reference to the table
+ todoItemTable=client.getSyncTable('todoitem');
+
+ refreshData();
+
+ $('#add-item').submit(addItemHandler);
+ $('#refresh').on('click',refreshData);
+ });
+}
+
+
+
There are three distinct areas here, separated by promises. The first promise defines the tables. If you are using multiple tables, you must ensure that all promises are complete before progressing to the next section. You can do this with Promise.all() as an example. The second section initializes the sync context. You need to define two sections for the push handler - the conflict handler and the error handler. I’ll go into the details of a conflict handler at a later date, but this is definitely something you will want to spend some time thinking about. Do you want the last one in to be the winner, or the current client edition to be the winner, or do you want to prompt the user on conflicts? It’s all possible. Once I have created a sync context, I can get a reference to the local SQLite database table, which is used instead of the getTable() call that it replaces. The rest of the code is identical - I refresh the data and add the event handlers.
+
+
Step 3: Adjusting the Refresh
+
+
In the past, refresh was just a query to the backend. Now I need to do something a bit different. When refresh is clicked, I want to do the push/pull cycle for synchronizing the data.
Just like the initialization, the SDK uses promises to proceed asynchronously. First push (which resolves as a promise), then pull (which also resolves as a promise) and finally you do EXACTLY THE SAME THING AS BEFORE - you query the table, read the results and then build the todo list. Seriously - this bit really didn’t change. That means you can add offline to your app without changing your existing code - just add the initialization and something to trigger the push/pull.
+
+
Wrap Up
+
+
This is still a beta, which means a work-in-progress. Feel free to try it out and give us feedback. You can file issues and ideas at our GitHub repository.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+Using Azure App Service and Azure Active Directory (AAD), it's possible to create a MediaWiki-based web app for use within your organization with minimal setup and for little or no cost. If you're not familiar with MediaWiki, it's the same open source platform which powers Wikipedia. A few folks within Microsoft surprised me when they created internal wikis using my Easy Auth feature (Authentication / Authorization) so I thought I'd try it out for myself and do a quick write-up on it.
+
+Note that I'm assuming you're already familiar with Azure Active Directory and that you have an Azure Subscription that is associated with your organization. If not, you can find more information here: https://azure.microsoft.com/en-us/documentation/articles/sign-up-organization/.
+
Creating a Web App
+The first step is to create a new web app. If you already know how to do this, you can skip this section. The easiest way is to simply navigate to https://portal.azure.com, log in with your Azure Subscription (the one for your organization), and go to New --> Web and Mobile --> Web App. This can also be done using the Azure PowerShell or Cross-Platform CLI Tools, though I won't cover those details here. In this example, let's suppose you named the web app easyauth-wiki (all my examples and screenshots will use this name, but you can replace it with your own app name).
+
+IMPORTANT: If you want to create custom hostnames for your web app, you should set that up now.
+
Enabling AAD Authentication
+As I hinted to before, this can be done in the portal via Easy Auth, Azure App Service's integrated authentication feature. For simplicity, we'll use the Express configuration, which automatically creates an AAD application and configures it for your site.
+
Select Settings and navigate down to Authentication / Authorization.
+
Set App Service Authentication to On.
+
Under Authentication Providers, select Azure Active Directory
+
For Management mode, select Express and then click OK.
+
Back in the Authentication / Authorization blade, click Save.
+
+
+
+At this point, your new web app is now protected using Azure Active Directory authentication and only users in your organization will be able to access the site.
+
Installing MediaWiki
+It's possible to create a MediaWiki app using the Marketplace gallery in the Azure management portal, but for this write-up I'm going to configure it from scratch. This also allows me to use a local SQLite database (instead of paying for a ClearDB MySQL database), which is convenient for testing and is free. If you're expecting your wiki to be used by a large number of users, then you should definitely consider using MySQL instead of SQLite, though I won't cover the MySQL setup here.
+
Download MediaWiki
+There are multiple ways to get MediaWiki installed on your web app. I'm going to show you the quick-and-dirty way which doesn't involve any 3rd party tools or source control. Start by navigating to the debug console on the SCM endpoint for the site you just created: https://{appname}.scm.azurewebsites.net/DebugConsole. You can log in using your Azure Subscription credentials if you're not already logged in. Then do the following:
+
+The last step might take a while due to the large number of files to extract. This will get all the MediaWiki bits onto your web app. I chose MediaWiki 1.26.3 since that was the latest when I started writing this post, but a newer version is probably available by the time you read this (in fact, 1.27.0 was released shortly after I finished putting together my sample). You can find available versions of MediaWiki on the MediaWiki download page. Be sure to adjust my instructions accordingly depending on which version you decide to use.
+
Configure MediaWiki
+Now that MediaWiki is installed, let's configure it with a simple SQLite database backend.
+
+
Navigate to https://{appname}.azurewebsites.net/mediawiki-1.26.3/mw-config/index.php
+
Click through the first two pages.
+
In the Connect to database page, select Database type: SQLite and click Continue.
+
Configure your wiki with a name and an administrator account and click Continue.
+
For User rights profile, select Private wiki.
+
Feel free to mess with additional settings on this page as necessary. Under Advanced configuration, you may want to enable PHP object caching for improved performance (internally we use WinCache). When all done, click Continue and then Continue two more times to complete the installation.
+
+At this point, you should see a Complete! screen and a LocalSettings.php file should have been downloaded by your browser. You'll need to upload this file to your MediaWiki installation directory (D:\home\site\wwwroot\mediawiki-1.26.3) to complete the installation. The easiest way is to simply drag/drop it from your file system to the browser window which shows the Debug Console in the D:\home\site\wwwroot\mediawiki-1.26.3 directory.
+
Configuring Integrated Authentication
+The final required step is to connect the user accounts in your Azure Active Directory to the user accounts in your wiki. This can be done using the Auth_remoteuser extension, as I'll describe here. The great thing about this extension is that it can also be used for on-premises Active Directory, making it very easy to do on-premises to Azure migrations.
+
+Once again, let's take the simple route of installing it directly onto the web app using the Kudu Debug console (otherwise you can follow the instructions on the extension page).
+
+
Use cURL to download the extension, e.g. curl https://extdist.wmflabs.org/dist/extensions/Auth_remoteuser-REL1_26-6103d19.tar.gz > Auth_remoteuser-REL1_26-6103d19.tar.gz (the actual URL will be different for you depending on which version is the latest by the time you read this).
+
Extract the downloaded extension into the MediaWiki extensions directory - e.g. tar -xzvf Auth_remoteuser-REL1_26-6103d19.tar.gz -C D:\home\site\wwwroot\mediawiki-1.26.3\extensions (again, your exact path may differ).
+
Open your LocalSettings.php for editing (e.g. D:\home\site\wwwroot\mediawiki-1.26.3\LocalSettings.php) and make the following changes:
+
+[php]
+require_once "$IP/extensions/Auth_remoteuser/Auth_remoteuser.php";
+$wgAuth = new Auth_remoteuser();
+[/php]
+At this point your identity setup is now complete! MediaWiki automatically recognizes your login. No registration required. You can test it by browsing to the root of your MediaWiki installation - e.g. https://{appname}.azurewebsites.net/mediawiki-1.26.3.
+
+The last step is to add a URL rewrite rule to fix your URLs so that you don't need to include the MediaWiki installation directory in your URL.
+
Configuring URL Rewrite Rules (Optional)
+The final step involves configuring IIS rewrite rules on your app to remove the installation directory as well as to "prettify" your URLs. Without doing this, your URLs are quite ugly and hard to discover.
+
+
+
+There are many ways to configure this so consider the below just one of many examples.
+
+
In the Kudu console, navigate to D:\home\site\wwwroot.
+
Create a web.config file by entering the following command: touch web.config
+
Open the file for editing and add the following content (replacing the MediaWiki version numbers as necessary):
Open the LocalSettings.php file and ensure the following variables are set as shown here (again, you may need to fix up the MediaWiki version number):
+
+[php]
+$wgScriptPath = "/mediawiki-1.26.3";
+$wgArticlePath = "/wiki/$1";
+$wgUsePathInfo = true;
+[/php]
+
+Now, if you navigate to your site root, you'll get redirected to https://{appname}.azurewebsites.net/wiki and you will see your wiki content. If you click on a page, you'll get a friendly /wiki/PageTitle URL.
+
+
+
+This is a big improvement from before!
+
Linking to Anchors (Optional)
+It's common for people to create links to certain sections of their wiki pages which contain URL fragments. For example, you might have a URL which looks like /wiki/Main_Page#SectionZ. This ensures that when you share the link with someone and they click it, the browser will automatically scroll to wherever "SectionZ" is located on the page. More information on anchors in MediaWiki can be found here.
+
+There is one problem that occurs when you introduce login to your web app, however. If you're familiar with URL fragments (the #SectionZ part of the URL) then you'll know that they are never sent to the server. By default, the Easy Auth module handles the login entirely on the server, so if one of your colleagues clicks on a link to the wiki with a URL fragment in it and they are not yet logged in, the URL fragment will be lost by the time they finish logging in and get redirected back to the page they tried to visit. This is a pain because then they have to manually scroll to find the location that they were supposed to be directly linked to. Note that this problem is not unique to MediaWiki or Easy Auth. There are many other server-side authentication solutions which suffer from the same issue.
+
+One potential workaround is to have people complete the login and then click the link again in order to be navigated to the correct location in the target page. Obviously, this is not a very good solution. Several teams internally at Microsoft have run into this problem and reported it to me, so I thought it would be a good idea to find a way to solve it in a way that didn't require users to know about the problem. To that end, we recently added a new feature in Easy Auth which solves this by using some JavaScript to ensure URL fragments are correctly preserved. Currently it's an opt-in feature which you can enable by setting the WEBSITE_AUTH_PRESERVE_URL_FRAGMENT app setting to true in the Azure management portal.
+
+
+
+With this setting in place, when users click on your links which contain URL fragments, the login process will ensure that the URL fragment part of your URL does not get lost in the login redirect process. Let us know in the comments if you found this feature helpful for you, we'd love to know about it. If it helps out enough folks, we'll likely turn on this capability by default.
+
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Episerver CMS, a platform to build web content management solutions, is now available in the Azure Marketplace.This gives you the ability to get a 30-day free evaluation of Episerver CMS running on Azure App Service. Please note that you will be charged for the Azure resources consumed by the application in your Azure subscription. This solution uses a BOYL (bring your own license) model, to continue its use after the evaluation period you can purchase a license from Episerver website. You can learn more at the Episerver CMS web site.
+
+In this tutorial you'll learn how to create an Episerver CMS application in Azure App Service.
+
+1. Click on this link to open Create workflow to Episerver in the Azure portal. Check out the details on Episerver app in the Azure Marketplace.
+
+2. Enter your Application name and Select your subscription. You can choose to create the application in a new or existing resource group.
+
+
+
+3. Click on App Service plan/Location to choose an existing App Service plan or create a new App Service plan as shown in the image below
+
+
+
+4. Click on SQL Database to choose and existing or new SQL Azure database. You can create a new database in an existing SQL Azure server if the web app and SQL Azure server are in the same location.
+
+
+
+5. Click on Create to start deployment of the Episerver application. You can check the “Pin to dashboard” checkbox to pin the resource group in Azure portal dashboard for easy access.
+
+
+
+6. Check for the deployment status, by clicking on notification button as shown below
+
+
+
+
+
+
+7. Once the deployment has been completed, you can access the resource group you created. Select your web app and click on Browse to view your web app.
+
+
+
+8. The Episerver application installer wizard will walk you through the installation.
+
+
+
+9. Once the wizard completes, you can access the CMS in edit mode, by appending /episerver/cms/edit to the site URL. For example, the URL would look like http://episerverapp1.azurewebsites.net/episerver/cms/edit/
+
+
+10. Note that Episerver CMS is available for a 30-day trial. You will see a message on the web application that it is currently in trial period. Buy Episerver license to continue using the application past the 30-day evaluation period you can
+
+
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+When creating web, mobile, API, or Function apps for use by members of your organization, it's often the case that you're using Azure Active Directory and you want to remove the option to log in with non-organizational credentials. For example, you want to prevent users from accidentally logging in with MSA credentials (hotmail.com, live.com, outlook.com, etc.). This can be done by leveraging what's known as a domain hint when navigating users to the Azure AD login page.
+
+Domain hints will do two things for you: 1) remove the home realm discovery page from the login flow and 2) ensure that users can't accidentally auto-log into your app using wrong credential types (for example, MSA credentials). More background information on Azure AD's support for domain hints can be found on the Microsoft Enterprise Mobility blog:
+
+https://blogs.technet.microsoft.com/enterprisemobility/2015/02/11/using-azure-ad-to-land-users-on-their-custom-login-page-from-within-your-app/
+
+Vittorio Bertocci also talks about domain hints in his post on Skipping the Home Realm Discovery Page in Azure AD., demonstrating how to use them when using ADAL and the OpenID Connect Middleware to build your web app. In this post, however, I'll describe how enable domain hints when using App Service's integrated Easy Auth feature.
+
Default Login Parameters
+Most web apps will want to configure domain hints to be used for all logins. Unfortunately you cannot configure default domain hints in this way using the Azure portal today. Instead, you must use the App Service Management API. Until we get around to building a portal experience, I recommend that most people configure default domain hints in Azure Resource Explorer. This can be done using the following steps:
+
+
Search for your web, mobile or API app using the search bar. Alternatively, you can navigate directly to your app if you click on the Resource Explorer link in the tools section of the portal.
+
Under your site node, navigate to /config/authsettings.
+
Click Edit to enable making changes.
+
Set additionalLoginParams to the following (This is a JSON array value): ["domain_hint=microsoft.com"]
+
Click the Read/Write button at the top of the page to enable making changes.
+
Click the PUT button to save your changes.
+
+The JSON configuration for your auth settings should look something like the screenshot below. In my case, I specified domain_hint=microsoft.com since the app shown here is intended to be used by Microsoft employees.
+
+
+
+Once this is done, users will no longer see the home realm discovery page when logging into the app. Instead, users will be immediately directed to the organizational login page, ensuring they cannot intentionally or accidentally log in with the wrong credentials.
+
Using the Login API
+If you're building an app that invokes the built-in /.auth/login/aad REST API, you can alternatively specify domain_hint={domain} as a query string parameter to get the same effect.
+
+For example, if I'm writing a mobile client and using the App Service .NET SDK, I could write the following code to initiate a login using a domain hint for contoso.com.
+
+[csharp]
+ var user = App.MobileClient.LoginAsync(
+ MobileServiceAuthenticationProvider.WindowsAzureActiveDirectory,
+ new Dictionary<string, string>
+ {
+ { "domain_hint": "contoso.com" }
+ }
+[/csharp]
+
+Similarly, I could create a login link in a web page using HTML that includes a domain_hint parameter.
+
+[html]<a href="/.auth/login/aad?domain_hint=contoso.com">Login</a>[/html]
+
+This allows me to specify login hints without changing the auth settings of the app as I showed in the first part of this post. In theory, this would also allow me to create multiple login links, one for each domain that my Azure AD application supports. Note that if an app is already configured with a default domain hint, the query string parameter will override that default.
+
Conclusion
+In conclusion, most single-tenant applications will want to use domain hints to optimize the login experience. These hints allows you to skip the home realm discovery page in the Azure AD login sequence and mitigates the common problem where the browser will try to log into the app using MSA credentials via SSO. Depending on the type of application you are building, you can use either the default login parameter method or you can explicitly specify login hints via the built-in /.auth/login/aad endpoint.
+
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Azure Mobile Apps provides an offline sync feature that makes it easy to build mobile apps that work without a network connection. When apps use this feature, end users can still create and modify data, even when the app is in an offline mode. The changes are saved to a local store and can be synced to your Mobile App backend when the app is back online. See Offline Data Sync in Azure Mobile Apps for more details.
+
+Offline sync uses a local store to persist data on the client device, where the specific storage implementation can be customized. The Mobile Apps client SDK provides local stores based on SQLite (Windows, Xamarin, and Android) and Core Data (iOS native). SQLite does not have any built-in encryption support, but there are a number of extensions that provide encryption. One such extension is the SQLite Encryption Extension (SEE). SEE is an add-on to the public domain version of SQLite and does not require a custom local store implementation. Note that SEE is not the only encryption option for Mobile Apps; For instance, you can define a local store that uses SQLCipher for encryption.
+
+This sample requires you to purchase a license for SEE. This is not included as part of the Azure Mobile Apps Client SDK.
+
+In this article I will walk through a sample to show how to create an encrypted local store using SEE in a Xamarin.Android app - this can be done in three parts:
+
+
Build the Quickstart for Xamarin.Android and enable offline sync
+
Build sqlite3.dll with SEE for Android
+
Update the Quickstart to use custom version of sqlite3
+The SQLite Encryption Extension is a commercial encryption product and you must buy a license for SEE before continuing. After purchase, you may download the code for building SQLite for Android and build the native SQLite3 library with SEE. By default, the native library is build for the armeabi platform - common for actual Android devices. You will need to build the native app for an x86 platform if you wish to run your modified app on the Visual Studio Emulator for Android. To do this, open a Visual Studio command prompt and do the following:
+
cd SQLite_Android_Bindings\sqlite3\src\main
+ndk-build.cmd APP_ABI=x86
+Adjust the paths above as appropriate for your environment. Once built, you can open your Quickstart project in Visual Studio and copy the generated native library for x86 from SQLite_Android_Bindings\sqlite3\src\main\libs\x86 to YourQuickstartProject\lib\x86. Finally, update the build action for the copied libsqliteX.so file to be AndroidNativeLibrary:
+
+
+
Build and Run the Quickstart
+Before we can build the Quickstart, we need to configure the build environment to include the modified sqliteX DLL instead of the normal sqlite3.dll system library that is a part of the Android platform. Add an app.config file to your project with the following:
+
+Any P/Invoke operations that would normally load the sqlite3.dll will now be mapped to load the libsqliteX.so file that we provide. The SQLitePCL library that is used by the Azure Mobile Apps Offline Client SDK uses P/Invoke to call the native methods within sqlite3.dll, so this will now automatically reference the sqliteX library.
+
+This configuration file needs to be included in the APK package. This only happens when the EmbedAssembliesIntoApk is set to true in your csproj file. This property is set to false by default when using a debug build. When debugging the app, ensure you set the EmbedAssembliesIntoApk to true. Edit the csproj file and add the following to it:
+
+It's a good idea to do this edit from a normal text editor and then load it into Visual Studio. For an example, see the sample on GitHub.
+
+We can now create a local encrypted SQLite database protected by a password for use with offline sync. Create a MobileServiceSQLiteStore as normal, but specify a file Uri with a query parameter that includes the password. Here is the modified code that initialized the local store:
+
/// <summary>
+/// Converts a string to a hex key
+// </summary>
+private string StringToHex(string hexstring)
+{
+ var sb = new StringBuilder();
+ foreach (char t in hexstring)
+ {
+ sb.Append(Convert.ToInt32(t).ToString("x") + " ");
+ }
+ return sb.ToString();
+}
+
+private async Task InitLocalStoreAsync()
+{
+ // WARNING: Do not hard code passwords in your application!
+ var password = "Hello";
+
+ if (!Utils.MobileService.SyncContext.IsInitialized)
+ {
+ // Generate the URI to the offline cache file
+ var hexkey = StringToHex(password);
+ var offlineCacheUri = new System.Uri(Path.Combine(ApplicationData.Current.LocalFolder.Path,"testSee.db"));
+ string offlineCache = $"{offlineCacheUri.AbsoluteUri}?hexkey={hexkey}";
+
+ // Set up the encrypted SQLite Store as normal
+ var store = new MobileServiceSQLiteStore(offlineCache);
+ store.DefineTable<TodoItem>();
+ await Utils.MobileService.SyncContext.InitializeAsync(store);
+ }
+
+ // Synchronize the offline cache with the server
+ await SyncAsync();
+}
+
+
+Once the local database is created with a password, it is encrypted. If you try to use that database without providing a valid password, it would fail (throwing an Exception) with the error message ‘Error: file is encrypted or is not a database’.
+
+We've created a sample on GitHub that includes a solution for Xamarion.iOS and Universal Windows (UWP). The same technique will also work with Xamarin.Forms applications.
+
+The Android Debug Log shows detailed logs on location of the assemblies being loaded into the application. You can use this to verify the sqliteX that you built is loaded into the app.
+
+For Xamarin.Android, set the build configuration to match the native library architecture. A mismatch in the architecture will cause dll not found errors.
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Apple announced in September 2015 that from the 1st of June, all apps submitted to the iOS App Store for review must support IPv6 only networks. TL;DR – your app submissions will likely work just fine as long as you are not embedding IPv4 addresses or using IPv4 specific communication methods in your apps. For more information, keep reading.
+
+
Why IPv6
+IPv4 address are exhausted, and carriers are deploying IPv6 only which make it critical that our apps continue to work on IPv6 only networks. Fortunately for us, most apps will continue to work on an IPv6 only network without modification.
+
+To ensure your apps continue to work on an IPv6 only work, you'll want to make sure you're using a network library (for example NSUrlSession or CFNetwork). You'll also want to avoid the use of IPv4 APIs and hard-coded IP addresses. Essentially if your app is using a higher level API and framework for the network rather than the IP layer, your app should continue to work on top of either IPv4 or IPv6. For more information, check out the Apple Documentation.
+
+
+
+As part of the carriers upgrade to IPv6, they have deployed both DNS64 and NAT64 on their network which allows IPv6 clients (your app) to communicate with existing IPv4 infrastructure. If we take an App Service running in Azure as an example, it currently supports IPv4, but we still wish to communicate with it on the IPv6 carrier network. When our iOS app attempts to contact the REST endpoint we have set up, it will use a host name rather than a hard-coded IPv4 address. The DNS64 server will synthesize an IPv6 address and pass this back to the client. Any packets get routed to the NAT64 engine, which will then translate IPv6 traffic to IPv4 and vice versa. Through using DNS64 and NAT64, our IPv4 only App Service now appears (to our connecting client) to be an IPv6 service.
+
+
Testing
+
+If you wish to test if your app supports IPv6 only networks without submitting your app for review, you can use a handy addition to MacOS network settings. Apple have provided a DNS64 and NAT64 implementation in MacOS 10.11. This can be enabled by option clicking on the Share pane in System Preferences and then option-clicking the Internet Sharing service. After that, you'll see the Create NAT64 Network option appears.
+
+
+
Find out More
+
+iOS developers should take the time to watch Apple's video from WWDC in order to learn more about the new app store requirement to support IPv6. Most developers will not experience any issues with the new requirement as long as they've followed best practices; even if their existing infrastructure has no support for IPv6.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
We recently announced that Azure Mobile Services will be deprecated and all services will be migrated to Azure App Service. At this point, you will become responsible for the code running your app. You may want to upgrade your site to take advantage of the additional facilities that Azure App Service provides you, such as staging slots and picking the Node version that is run when you run your site. The Azure Mobile Apps compatibility package allows you to convert older Azure Mobile Services applications written for the Node platform so that they can utilize the latest Azure Mobile Apps Node SDK.
+
+
How Does it Work?
+
+The package takes the raw source code from a Node-based Azure Mobile Service and generates the equivalent set of table and custom API definitions that will work with the Azure Mobile Apps Server SDK for Node. You will have a new project at the end that you can deploy as a
+new site to Azure App Service. Both platforms offer a similar set of functionality, but with different APIs. The compatibility package maps the Mobile Services API to the newer Mobile Apps API.
+
+The generated app is ready to deploy to an Azure App Service and should work for most applications. It's important to review the code afterwards as some common scenarios (such as authentication) will require specific configuration or code changes in addition to the conversion.
+
+
+
+Open the Debug Console in your browser (it's at http://yourMobileService.scm.azure-mobile.net/DebugConsole). Navigate by clicking on the directory names to site/wwwroot/App_Data/config. Download the scripts directory in ZIP format by clicking on the download icon next to the folder name.
+
+
Create the Azure Mobile App
+
+First, install the compatibility package by executing the following with elevated privileges:
+
+
npm i -g azure-mobile-apps-compatibility
+
+This installs a command line utility with the following usage:
+
+
scaffold-mobile-app <inputPath> <outputPath>
+
+For example,
+
+
scaffold-mobile-app scripts out
+
+This reads the Azure Mobile Service definition from the scripts directory located in the current working directory and creates a directory called out with a scaffolded Mobile App. Once the app has been created, check the target folder to make sure it contains files for the tables and custom APIs you defined in your mobile service.
+
+Your app is almost ready to deploy!
+
+
Deploying and Testing
+
+During deployment, you will need to update your database and create a new App Service, linking the updated SQL database to the new App Service.
+
+
Create Database Compatibility Views
+
+Mobile Services created a specific schema to hold the Mobile Services data and had system column names preceded by a double-underscore. Mobile Apps has changed these requirements. We can map one to the other using SQL Views. The scaffolded app includes a SQL script called createViews.sql. This script must be executed against the target database. The connection string for the target database can be obtained from your Mobile Service or migrated Mobile App from the Settings blade under the Connection Strings section. The connection string name is MS_TableConnectionString. This script creates read / write views in the dbo database schema that map older reserved column names to new column names. This script can also be obtained from our GitHub repository.
+
+
Create the Target Mobile App
+
+Create a new App Service Mobile App using the Azure portal and perform the following tasks:
+
+
+
Take note of the URL for your Mobile App. You will need it later.
+
Configure a data connection that points to the Mobile Service database.
+
Configure push settings to use the same configuration as the Mobile Service.
+
+
+If you previously used one of the built in authentication providers, there are additional steps that you must take. Read about these changes in the .NET documentation - they are valid to all migrations.
+
+
Deploy your new Mobile App
+
+The simplest way to get your app onto Azure is using FTP. The URL, username and password can be obtained from the portal. Before copying the files, you must run npm install in a console window from the output folder created above. Copy the entire contents of the output folder to the site/wwwroot folder of the FTP host. Alternatively, if you are familiar with git, we recommend you follow publish from source control. You can also use WebDeploy or hook up continuous deployment.
+
+After you have deployed your app, open your browser and navigate to the URL of your Mobile App. You should see the home page for your app. Additionally, the Easy Tables and Easy API sections for your app in the portal should now be functional.
+
+
Update Your Client
+
+The client application must be updated to use the latest version of the Azure Mobile Apps SDK. In many cases, this may simply be a matter of updating the Azure Mobile Apps libraries to the latest version. Note that some libraries changed names:
+
+
+
+However, in some cases, additional code changes may be required. You also need to update the URL that is passed to the constructor of the Mobile App client object to the URL of the mobile app you created above and remove the API Key, which is no longer required. Each client SDK has a new HOWTO document to aid in development:
+
+
+
+Consult these documents for your client platform if you run into problems with the client SDK.
+
+
Troubleshooting
+
+If you run into a problem, you should debug the issue just like you would any other development issue. Generally, this means you should enable diagnostic logs for your app. Explicitly, you should turn on Application Logs (Filesystem) to see most of the issues with the code. Here are some of the more common errors you may encounter with their solutions.
+
+
Cannot find module 'xxx'
+
+Dependencies on external modules such as async have not been included by default to reduce the size of the application. If you are using any external modules, you will need to install them by opening a browser to https://_yourMobileService_.scm.azurewebsites.net/DebugConsole , navigating to the site/wwwroot folder and executing:
+
+
npm i <module name>
+
+You can also add an options @<version> - this is recommended to install the same package versions that were used in your original Mobile Service.
+
+
The table 'xxx' does not exist
+
+The getTable function is now case-sensitive. Check to ensure the appropriate case is being used.
+
+
Invalid column name '__createdAt'
+
+The double underscore notation for createdAt, updatedAt, version and deleted columns have been removed. You will need to update any explicit column references manually within your code. The SQL script createViews.sql will take care of these columns in your database.
+
+
Can't set headers after they are sent
+
+Calling request.respond or response.send more than once per request will result in this error. Older versions of the web framework used by Mobile Services, express, allowed this behavior, but the current version does not. Use the generated stack trace to identify the offending module and change the code to ensure these functions are only called once.
+
+
Error in sideband demultiplexer
+
+This usually indicates a corrupt git repository. You can fix this by running:
+
+
git remote set-head origin master
+
+This assumes your remote repository uses the default name origin and the branch you are pushing to is called master.
+
+
Caveats
+
+There are a couple of areas that require additional changes. For example, if you are using Mobile Services authentication, you need to update redirect URLs on your identity provider as they have changed. Read this article for more information. Custom authentication (i.e. not using an identity provider such as facebook) should not be affected.
+
+
Other issues
+
+Our github repository will be updated with new troubleshooting steps as common cases are uncovered.
+
+It's important to note that this package is experimental. We need your help to make the experience as seamless as possible. Join the conversation on gitter and let us know about your experiences. Post any issues within our GitHub repository, and ask questions on Azure Forums or Stack Overflow.
+
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 9 minute read
+
+
+
+ • By Steve Dower
+
+ • August 4, 2016
+
+
+
+
+
+
+
App Service is Microsoft Azure’s platform-as-a-service offering for web apps, whether they are sites accessed through a browser, REST APIs used by your own clients, or event-triggered processing. Many of you are already using Python to implement your apps on App Service (and rightly so!).
+
+
When we first enabled Python on App Service we wanted to make it as easy as possible. So we went and installed the latest available versions on every host, so that you could just assume it was going to be present. Unfortunately, this did not turn out to be a great long-term solution.
+
+
Happily though, we found a better approach! While it isn’t quite polished yet, we know that people want the solution now. Rather than waiting until we’ve finished all the scripts, documentation, videos etc. that will come in the future, we decided to give out early details in this blog post.
+
+
This post will start by outlining some of the problems, why we couldn’t do the “obvious” fix, and how to use the new approach. Feedback is welcome as we continue to improve the user experience around it, but hopefully the information here will be sufficient to get everyone moving again.
+
+
What went wrong?
+
+
Having Python installed on every App Service machine sounds like a great idea, right? And so we went ahead and installed the most up-to-date Python 2.7.8 and Python 3.4.1… oh yeah, they’re not the latest versions of Python any more.
+
+
The obvious solution here is to simply upgrade Python so that everyone has the latest improvements, bug and security fixes. But unfortunately, there were changes made between 2.7.8 and 2.7.9 and between 3.4 and 3.5 that meant upgrading would break existing users. Stability of the platform had to outweigh these improvements, so we were stuck. (The SSL improvements in 2.7.9 had workarounds that customers could implement themselves, so weren’t sufficient to justify breaking other customers.)
+
+
We had also chosen to install the 32-bit versions of Python. This adds an extra restriction on users who may have been deploying pre-built binaries targeting 64-bit versions, or other micro versions of Python.
+
+
Since users want to be able to choose their version of Python, the fix is to let everyone choose. We also wanted to improve package installation and make it easier to avoid IIS details.
+
+
Choosing your version of Python
+
+
Azure App Service has support for site extensions, which allow you to add features to your site. These can be deployed as part of an ARM template, using a REST API, or manually through the portal. The main part of our improved Python support is a set of site extensions containing the Python runtime, broken down by the exact version so that you can choose which one to install. (Obviously we recommend using the latest Python 3 version, but when you need an older version, you really need it so you can choose it.)
+
+
If your site is already deployed and running, it is easiest to install through the portal. Navigate to your App Service blade, select Tools, Extensions and then Add.
+
+
+
+
From the list of extensions, scroll down until you spot the Python logos, then choose the version you need. (Improvements to this UI are coming in the future; right now you just need to search manually.)
+
+
However, if you are deploying your site with an Azure Resource Manager (ARM) template, it is much simpler to add the site extension as a resource. It will appear as a nested resource of your site, with a type siteextensions and the name can be found from siteextensions.net.
+
+
For example, after adding a reference to python352x64, your template may look like this:
Regardless of how you choose to install the site extension, after installing you will have a version of Python installed at a path like C:\home\Python35\python.exe (see the description of the extension for the exact path).
+
+
Configuring your site
+
+
Once Python is installed on your site, you will need to reference it. Previously our tooling has been able to do this automatically, since we knew where Python was, but now the control is in your hands. Luckily, configuring your site is mostly a matter of knowing where to find python.exe.
+
+
Since App Service apps all run behind IIS, the configuration file is known as web.config (if you’re used to httpd servers, web.config is the equivalent of .htaccess), and there are two request handlers available: FastCGI, and Http Platform.
+
+
Using the FastCGI handler
+
+
FastCGI is an interface that works at the request level. IIS will receive incoming connections and forward the request details to a WSGI app running in one or more persistent Python processes. The wfastcgi package is pre-installed and configured, so you can easily enable it.
+
+
Your web.config configuration should include the following:
The value for PYTHONPATH may be freely extended, but must include the root of your website. WSGI_HANDLER should be updated to point to a WSGI app importable from your website. WSGI_LOG is optional but recommended while debugging your site. All app settings are made available to the app as environment variables.
+
+
The path to python.exe and wfastcgi.py will need to be customized if you are using a different version of Python. See the description of the site extension to find out where it will be installed and update these paths accordingly.
As for the previous configuration, the path to python.exe may need to be customized depending on the version of Python you are using. See the description of the site extension to find out where it will be installed and update these paths accordingly.
+
+
Arguments may be freely customized for your app. The HTTP_PLATFORM_PORT environment variable contains the port your local server should listen on for connections from localhost. In this example, I created another environment variable SERVER_PORT that isn’t really required. You can add or remove environment variables as necessary for your app.
+
+
Installing packages
+
+
Once you’ve installed Python onto your server, the next thing you’ll need is any packages your app depends on. This is the area we’re currently focusing on, so expect new announcements in the coming weeks as we simplify this process, but here are a few ways you can do it right now.
+
+
Kudu Console
+
+
Even after you have installed your packages, you will likely find this is an invaluable debugging tool. Once your website is created, for example at http://trywebsites.azurewebsites.net/, you can get into the Kudu console by adding .scm after your site name: https://trywebsites.scm.azurewebsites.net/. You will need to log in with your Azure account (so that example URL probably isn’t going to work) but can then directly access files and run commands on your site. The Kudu documentation contains the most up-to-date information about the console.
+
+
+
+
Once you are in the console and have added the site extension, you can freely install any packages you like (well, almost - more on this later). The one trick is that you’ll have to specify the full path to Python. We also suggest including a requirements file as part of your site so that it is easy to reproduce the set of packages both locally and on the server. For example:
There’s no C compiler on your web server, so if any packages have native extension modules you’ll need to install the wheel. Many popular packages provide their own wheels, so installing them will work just fine, but for those that don’t you will need to use pip wheel [package] on a development machine and then upload the wheel with your site. (The end of our page on managing requirements shows an example.)
+
+
Kudu REST API
+
+
If you don’t want to manually log into the Kudu portal to install packages, you can also trigger these commands remotely via the REST API. The command command behaves identically to typing into the console, except you can POST the command to https://yoursite.scm.azurewebsites.net/api/command.
+
+
See the documentation for other commands and information about authentication. There is a helper class in this sample project that obtains the credentials using the Azure SDK for Python and will let you submit the same command as above via the exec() method. (Remember how I mentioned that we’re working on better ways to do all of these? Yep, there’s a lot of manual work required right now, but soon we’ll have install-on-deploy automation available.)
+
+
Vendor everything
+
+
A final option for deploying your packages is to “vendor” them. This essentially means copying the entire library into your own source code and copying it as part of your site. Depending on how many dependencies you have and how frequently you update them, this may be the easiest way to get a working deployment going. The one catch is that you need to ensure that you copy libraries from a version of Python that precisely matches the version you are installing on the server. If you take extensions from Python 3.5 32-bit and try and use them with 64-bit Python, you will see obscure import errors after deployment. However, as the versions of Python we make available on Azure are exactly the same as those released on python.org, you can easily obtain a compatible version for local development.
+
+
Aside: what about virtual environments?
+
+
While we recommend working in a virtual environment locally, to ensure you fully understand the dependencies needed by your site, once you have published there should not be multiple projects using the same Python install at all. (If there are, you really want to avoid having conflicting dependencies!) As a result, it’s easier and more efficient to just install into the main Python directory.
+
+
Summary
+
+
We hope you appreciate this information at this time. While there is still a lot of ongoing work to improve Python on Azure App Service, we have reached a point where there is enough for people to benefit from being able to use parts of it. In particular, we know that many of you will be unblocked by the new ability to install newer versions of Python onto your app service servers.
+<If you have any feedback, suggestions, or want to deploy or manage your web site in a way you think we may not have considered, feel free to leave a comment on this post or email python@microsoft.com directly. While we can’t respond to every piece of feedback or need for assistance (we suggest creating support requests for those), we’re happy to hear what you need.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 9 minute read
+
+
+
+ • By Steve Dower
+
+ • August 4, 2016
+
+
+
App Service is Microsoft Azure’s platform-as-a-service offering for web apps, whether they are sites accessed through a browser, REST APIs used by your own c...
The traditional Azure Mobile Apps process has been somewhat long winded. Aside from creating a Mobile App, you have to create a SQL Azure server and database, link the two up, deploy some code, and then you are ready to actually develop a mobile client. This can take 15 minutes even in the best case scenario. Today, we are introducing a new method of creating a Mobile backend via the Mobile Apps Quickstart.
+
+The Mobile Apps Quickstart is a pre-configured mobile backend suitable for development purposes and learning about mobile backends. It provides a base mobile backend using a SQLite database for data storage. This means that you can immediately start using it without hooking up an external database. You can still access features like Easy Tables and Easy APIs, hook up authentication and push notifications - in fact, anything that does not rely on a SQL Azure instance.
+
+Setting up a Mobile Apps Quickstart is a breeze. Log into the Azure Portal. Click on the big + NEW in the top left corner, and enter "Mobile Apps Quickstart" in the search box:
+
+
+
+Click on the **Create** button at the bottom of the blade.
+
+
+
+The App name, Subscription, Resource group and App Service plan/Location fields are identical to those required by the standard Mobile App flow. Just fill in the information. However, ensure you always check the **Pin to dashboard** box. Finally, click on **Create**.
+
+The deployment takes approximately 3-4 minutes and is ready for going through one of the client walk-throughs immediately after the deployment is completed.
+
+Along with the quicker deployment, you also get access to a new simplified management experience. Clicking on the dashboard app tile (the one that you pinned) brings you to a new blade:
+
+
+
+You can always get to the underlying Mobile App (click on the middle card).
+
+
Limitations
+
+Because this template provides a SQLite database, it does not scale. Do not run more than one instance of the Mobile App. If you wish to run this Mobile App in a scalable manner, then connect a SQL Azure database instance through the **Data Connections** blade.
+
+The Mobile Apps Quickstart is available on the Azure Marketplace right now.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
ALERT: Some Mobile Apps (a feature of Azure App Service) deployments may be vulnerable to phishing attacks because of how current and older versions of swagger-ui are installed. Please take steps to determine if your deployments are at risk, and then mitigate, if necessary.
+
+Our Microsoft Azure Security team is following reports of multiple high risk vulnerabilities present in current and older versions of swagger-ui. These are third-party vulnerabilities and not related to the Azure platform. However, some Mobile Apps deployments may have swagger-ui installed in a manner that makes those deployments vulnerable to phishing attacks.
+
+
How the vulnerability is exploited
+
+The swagger-ui component allows loading of arbitrary swagger definition files by passing the URL of the swagger definition as a querystring parameter. Malicious swagger definitions can be constructed that execute arbitrary code within the browser. An attacker can then send a URL containing a reference to the malicious swagger definition that is then executed by simply opening the URL in a browser (for example, clicking on the link in an email).
+
+
How the vulnerability is mitigated
+
+The Mobile Apps server SDKs now validate the URL of the swagger definition that is passed as a querystring parameter. Additionally, a Content Security Policy (CSP) header is sent which prevents the browser from communicating with servers that may host malicious swagger definitions.
+
+
How to determine if your deployment is at risk
+
+First determine whether your Mobile Apps deployment is based on Node.js (this includes all Easy Tables users) or .NET.
+
+
+
For Node.js, you can determine if your deployment is vulnerable by looking at the code in your app.js file (if you are using Easy Tables, you can do this by using the Edit Script option in the Azure portal; this will open App Service Editor and allow you to browse the files). If you see the line "swagger: true" then swagger-ui is enabled and your deployment is potentially vulnerable.
+
For .NET, your deployment is potentially vulnerable if the application you publish includes the Azure Mobile .NET Server Swagger package (the vulnerabilities aren‘t in this package itself but one of its dependencies).
+
+
Steps to perform mitigation actions
+For Node.js, updated packages are available. We recommend that Node.js users complete one of the following actions:
+
+
+
Edit your application code (for example, app.js) to disable the configuration setting that enables our swagger UI functionality (use swagger: false).
+
Or update to swagger-ui 2.1.5, and then update to the latest version of the Azure Mobile Apps Node.js SDK. Here are a couple of ways to do this:
+
+
Sign in to the kudu debug console by opening https://.scm.azurewebsites.net/DebugConsole (update to your mobile app name), change directory to D:\home\site\wwwroot, and then run npm update -save azure-mobile-apps swagger-ui. When this completes, go to the Azure portal, open your mobile app, and then select the Restart option.
+
Update package version numbers in package.json (azure-mobile-apps should be version 2.2.3; swagger-ui should be 2.1.5) and deploy using git.
+
+
+
+
+We strongly recommend the following steps for .NET customers:
+
+
Confirm that your application code no longer includes a reference to the Swashbuckle.Core package.
+
Republish your application.
+
+
+For more information on the open source component swagger-ui vulnerabilities, please visit the following webpages on the Node Security Platform website:
+
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Note: This post was cross-posted from CGillum Dev Blog.
+EDIT 1/23/2017: Updated token refresh section with simplified instructions and added code snippets.
+This post is a continuation of my previous post on App Service Auth and Azure AD B2C, where I demonstrated how you can create a web app that uses Azure AD B2C without writing any code. If you haven't done so already, be sure to read that post to get proper context for this one.
+
+In a recent service update, we've improved our overall support for B2C in Azure App Service. This includes enhancing our existing web app support, but more importantly includes adding full support for leveraging B2C in mobile, API and function apps. More specifically, support has been added for the Easy Auth Token Refresh API. Additionally, the Login API has been updated to support specifying specific B2C policies as arguments. If you're a Mobile app developer, these improvements will make using Azure AD B2C in your mobile app significantly easier.
+
+This post will go into more details about these improvements, show a few code snippets, and conclude by demonstrating these B2C capabilities in a simple demo web app.
+
Pick Your Policy
+Specific B2C policies can be invoked using the built-in Easy Auth login API for AAD. If you're not familiar with the Easy Auth login API, it works by allowing you to initiate a server-directed login by sending a GET request to your web, mobile, API, or function app's built-in {root}/.auth/login/aad endpoint. This endpoint supports the standard sign-in query string parameters for AAD, including the newly added p={policy} query string parameter which allows you to specify a B2C policy by name.
+
+For example, one could use the following HTML in a web app to create hyperlinks that invoke specific B2C policy workflows, such as editing the user profile or resetting the password:
+
+[html]
+<a href="/.auth/login/aad?p=B2C_1_EditProfile&post_login_redirect_uri=/">Edit Profile</a>
+<a href="/.auth/login/aad?p=B2C_1_ResetPassword&post_login_redirect_uri=/">Reset Password</a>
+[/html]
+
+Clicking one of these links will automatically redirect the user to the corresponding B2C policy page and allow the user to edit their user profile or reset their password accordingly.
+
+If you're writing a native client which uses one of the App Service Mobile Client SDK flavors, you could write something similar in platform-specific code. The example below shows how a mobile client app written in C# can invoke a B2C sign-in policy that requires MFA:
+
+[csharp]
+App.MobileClient.LoginAsync(
+ MobileServiceAuthenticationProvider.WindowsAzureActiveDirectory,
+ new Dictionary<string, string>
+ {
+ { "p", "B2C_1_SignInWithMFA" }
+ }
+[/csharp]
+
+In this case, the user will presented with a native web view dialog which allows the end user to sign in using MFA (phone authentication, etc.). The primary thing to keep in mind about this experience is that these B2C policies can be easily invoked with just a few simple lines of client-side code. No platform-specific middleware or server-side code is required.
+
+One important note of caution: the claims associated with the signed-in user will be updated every time you invoke a B2C policy. If your app depends on the presence of specific claims, make sure they are explicitly configured in each of your B2C policies.
+
Refreshing Tokens (Optional)
+Easy Auth also has a built-in API for refreshing both provider-specific OAuth tokens and the app-specific authentication tokens. It works similar to the login API, in that it requires a GET request to the app's built-in {root}/.auth/refresh endpoint. More information on token refresh (and our token management story all-up) can be found in my earlier App Service Token Store blog post.
+
+This token refresh support also extends to Azure AD B2C apps and is completely optional. However, leveraging token refresh is very important if you're building a native app to ensure a smooth user experience. In order to set this up, you will need to do the following:
+
Create an app key for your B2C application
+Creating app keys can be done in the Azure management portal for B2C.
+
+[caption id="attachment_198" align="aligncenter" width="951"] Generating an App Key in the B2C Management Portal[/caption]
+
+Make a note of the app key that gets auto-generated by the portal. We'll need it to configure Easy Auth in the next step.
+
Update the Easy Auth Settings
+Easy Auth doesn't require an app key by default and instead relies on the OpenID Connect Implicit Flow to implement secure logins. In order to get refresh tokens, however, we need to switch to the Hybrid Flow (Don't worry if you don't understand what these mean, Easy Auth will take care of the protocol details for you).
+
+To make this protocol switch, you need to update the App Service Auth settings for your app with the key from the previous step. This can be done in the Advanced tab in the Azure Active Directory portal.
+
+[caption id="attachment_2865" align="alignnone" width="1190"] Setting the B2C app key as the Easy Auth client secret.[/caption]
+
+Now that you’ve enabled the hybrid flow, your app needs to start requesting refresh tokens from B2C. This can be done by updating the login parameters in your app code to include the offline_access scope.
+
+Updated HTML Example
+
+[html]
+<a href="/.auth/login/aad?p=B2C_1_EditProfile&post_login_redirect_uri=/&scope=openid+offline_access">Edit Profile</a>
+
+<a href="/.auth/login/aad?p=B2C_1_ResetPassword&post_login_redirect_uri=/&scope=openid+offline_access">Reset Password</a>
+[/html]
+
+Updated Mobile App SDK C# Example
+
+[csharp]
+App.MobileClient.LoginAsync(
+ MobileServiceAuthenticationProvider.WindowsAzureActiveDirectory,
+ new Dictionary<string, string>
+ {
+ { "p", "B2C_1_SignInWithMFA" },
+ { "scope", "openid+offline_access" }
+ }
+[/csharp]
+
+Once this is done, all future logins should result in refresh tokens in the app's built-in token store. You can then write client code which invokes the {root}/.auth/refresh API (or use the corresponding Mobile Client SDK method) to periodically refresh these tokens, which allows your app to function for longer periods of time without requiring a re-auth.
+
Demo App
+To demonstrate all of this, I've created a single-page application (aka a SPA app) written using HTML, jQuery, and Bootstrap. It's a trivial app written by someone who is clearly not a UI designer (me) and demonstrates the various patterns described in this blog post. You can browse to it here and play around with it (I promise not to give out your information if you decide to provide it), or simply copy the source code and host it yourself in your own App Service web app. Note that I theoretically could have also built this using the iOS, Android, UWP/Xamarin, or one of the other mobile SDKs that are provided, but it was simpler for me to build a plain-old HTML web app. :)
+
+The important thing to keep in mind is that there is absolutely no auth code in this sample (in fact, no backend code at all). All of this is implemented on the client and in the App Service platform with the help of Azure AD B2C. No SDKs required.
+
+When you first visit the demo page, you will be given two login options. One is a standard email-based login and the other is an MFA login which requires you to register a phone number for phone authentication.
+
+[caption id="attachment_183" align="aligncenter" width="510"] Demo app starting page when unauthenticated[/caption]
+
+The phone authentication provided by B2C allows you to do phone calls or SMS in my case. You can enter the provided code to complete the authentication.
+
+[caption id="attachment_182" align="aligncenter" width="419"] Phone authentication when using Azure AD B2C[/caption]
+
+Once signed-in, you will see a few B2C policy actions that you can invoke as well as a set of user claims displayed on the page. There's also a sign-out button which uses Easy Auth's built-in Logout API to clear the session.
+
+[caption id="attachment_185" align="aligncenter" width="992"] This B2C demo app supports updating the user profile and resetting the password used for logging in.[/caption]
+
+[caption id="attachment_189" align="aligncenter" width="1003"] This B2C policy is configured to return the object ID, postal code, name and email address.[/caption]
+
+Note that one of the claims, https://schemas.microsoft.com/claims/authnclassreference, contains the name of the B2C policy that the user logged-in with. Your application code can take advantage of this if, for example, you want to grant special permissions to users who log in using a higher-privilege B2C policy.
+
+Again, it's a very simple app to quickly demonstrate some of the powerful capabilities of the App Service "Easy Auth" platform when combined with Azure AD B2C. My hope is that this is enough to give you some ideas about how you can leverage the Azure AD B2C platform in your own App Service apps.
+
Following Up
+Have a technical questions about Azure App Service and/or Azure AD B2C? Head over to StackOverflow.com and tag your questions with azure-app-service and/or azure-ad-b2c accordingly. We monitor posts with these tags and are happy to help.
+
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
MySQL in-app feature enables running MySql natively on Azure App Service platform.You don’t need to provision a database explicitly as during the creation of the web app when using this feature, we take care of enabling it if you select “MySQL in-app ” during creation or if the feature is turned ON for existing web app. To understand what MySQL in-app means , I have highlighted core functionality supported with the preview release of the feature:
+
+
Support PHP , MYSQL applications like WordPress, Joomla , Drupal etc .
+
MySQL server running on the same instance side by side with your web server hosting the site. This will boost performance of your application
+
Storage is shared between both MySQL and your web app files. Note with Free and Shared plans you may hit our quota limits when using the site based on the actions you perform . Check out quota limitations for Free and Shared plans.
+
You can turn on Slow query logging and general logging for MySQL . Note that this can impact the site performance and should NOT always be turned ON . The logging feature will help investigation any application issues .
+
+
+
+Note : This MySQL in-app is specific to Windows version of Azure app service. If you are looking for local mysql on Linux MySQL app service , click here.
+
Create new Web App with MySQL in-app
+Login to Azure portal and launch Web App + MySQL template by clicking here .Enter the Site name and select MySQL in-app as the database provider. Click on Create to deploy a web app using MySQL in-app.
+
+
+
+You may also create a WordPress application with MySQL in-app from Azure marketplace. Test drive our demo site here using MySQL in-app.You can login with username : demo and password: demopassword .
+
Limitations
+For preview release the feature has some limitations that to keep in mind.
+
+
Auto scale feature is not supported since MySQL currently runs on on a single instance .
MySQL database cannot be accessed remotely. You can only access your database content using PHPMyadmin or using MySQL utilities in KUDU debug console. This is described in detail below.
+
WordPress and Web App + MySQL templates currently support MySQL in-app in the create experience.We are working on bringing this feature in for other MySQL based applications in Web category for Azure marketplace.
+
+
+
Manage MySQL in-app
+Go to your web app and select MySQL in-app in the Menu blade on the right. You can use the setting here to manage your MySQL in-app feature , turn on logging , access PHPmyadmin etc.
+
+
+
+
+
Access database content
+The database is protected by our sandbox environment and hence cannot be accessed remotely through MySQL workbench or MySQL command line tools (running on remote machine) . There are two ways you can manage your database content :
+
+
+
+
Using PHPMyAdmin: With MySQL in-app , the MySQL process ( mysqld.exe) must be ready for connections before using PHPmyadmin tool to access the database. This means your web app has to open the mysql connection. You can use the sample code mentioned in section Get database connection string to open mysql connection.
+Go to your web app and select MySQL in-app in the Menu blade on the right . Click on the Browse button to open PHPmyadmin.
+
+
+
+
+
+The database enabled with your web app is "localdb". You are now ready to import your database schema or create a new one for your web app.
+
+
+
Run the following command to run your query (remember to update the port number to your web app’s MySQL port since this feature does not use 3306 port)
D:\Program Files (x86)\mysql\5.7.9.0\bin\mysql.exe -e "USE localdb;Select * from tasks;" --user=azure --password=password --port=49175 --bind-address=127.0.0.1
+mysql: [Warning] Using a password on the command line interface can be insecure.
+mysql: Unknown OS character set 'cp0'.
+mysql: Switching to the default character set 'latin1'.
+task_id subject start_date end_date description
+1 task1 2016-02-18 2016-02-19 sample task
+
+The mysql warning statements can be ignored in the output. You can use mysqladmin.exe and mysqld.exe as well , in the similar format as above .Please review the password and database information from D:\home\data\mysql\MYSQLCONNSTR_localdb.ini before entering the connection information in the commands below. Here is an example to flush logs
+
+Turn on slow query logs or general logs for MySQL . Once turned on , you can find these logs in D:\home\logfiles\mysql folder. Note if these settings are always on , then this can impact your web app performance
+
+
+
How to deploy your web app to using MySQL in-app
+
Get the database connection string
+
Before you deploy your web app code , the key thing to note when using this feature is to use ENVIRONMENT VARIABLES since the database connection information is not accessible directly. You can get the database connection information using MYSQLCONNSTR_localdb environment variable . You can also get the connection string from D:\home\data\mysql\MYSQLCONNSTR_localdb.ini .Here is a sample code snippet that you can use in your application to get the database host, port, database name , database user, database password.
+As an example , if you are running a WordPress site you need to update wp-config.php such that it reads the connection string from the environment variable .
+
/*Add at the begining of the file*/
+
+$connectstr_dbhost = '';
+$connectstr_dbname = '';
+$connectstr_dbusername = '';
+$connectstr_dbpassword = '';
+
+foreach ($_SERVER as $key => $value) {
+ if (strpos($key, "MYSQLCONNSTR_localdb") !== 0) {
+ continue;
+ }
+
+ $connectstr_dbhost = preg_replace("/^.*Data Source=(.+?);.*$/", "\\1", $value);
+ $connectstr_dbname = preg_replace("/^.*Database=(.+?);.*$/", "\\1", $value);
+ $connectstr_dbusername = preg_replace("/^.*User Id=(.+?);.*$/", "\\1", $value);
+ $connectstr_dbpassword = preg_replace("/^.*Password=(.+?)$/", "\\1", $value);
+}
+
+// ** MySQL settings - You can get this info from your web host ** //
+/** The name of the database for WordPress */
+define('DB_NAME', $connectstr_dbname);
+
+/** MySQL database username */
+define('DB_USER', $connectstr_dbusername);
+
+/** MySQL database password */
+define('DB_PASSWORD', $connectstr_dbpassword);
+
+/** MySQL hostname : this contains the port number in this format host:port . Port is not 3306 when using this feature*/
+define('DB_HOST', $connectstr_dbhost);
+
+As a BEST PRACTICE when using MySQL in-app, we recommend to ALWAYS use Environment variables for the database information to prevent database connection issues with your web app. If your application requires a separate variable for port , you can use WEBSITE_MYSQL_PORT environment variable. The port number selected can vary if the instance is recycled and hence ALWAYS use environment variables.
+
Deploy you code
+Deploy your web app code using GIT or FTP or any one of the supported deployment processes with Azure Web Apps . Refer Deploy to Azure app service web apps for details .
+
Deploy your database
+You cannot directly deploy you database . Hence , export your local database into a SQL script . Access your web app MySQL in-app database using PHPmyAdmin ( https://sitename.scm.azurewebsites.net/phpmyadmin) and click on the IMPORT tab to import your script into the localdbdatabase . For example:
+
USE localdb;
+
+CREATE TABLE IF NOT EXISTS tasks (
+ task_id INT(11) NOT NULL AUTO_INCREMENT,
+ subject VARCHAR(45) DEFAULT NULL,
+ start_date DATE DEFAULT NULL,
+ end_date DATE DEFAULT NULL,
+ description VARCHAR(200) DEFAULT NULL,
+ PRIMARY KEY (task_id)
+) ENGINE=InnoDB
+Remember to include USE localdb; statement in your script so that the your schema and data are imported into the correct database.
+
How to turn on MySQL for existing Web Apps
+Go to your web app and select MySQL in-app in the Menu blade on the right . Turn ON MySQL in-app feature.
+
+
+
+Browse your web app and Check the process explorer to verify if mysqld.exe is running. If the process is running, then MySQL server is ready to use. Remember to open the MySQL connection to your MySQL in-app database , localdb in your web app.
+
+
+
Migration to production database
+You can easily migrate this database when ready for production to
+
When using Web app with MySQL in-app provider with Basic, Standard or Premium app service plans, turn on ALWAYS ON setting as described here. By default, web apps are unloaded if they are idle for some period of time which means both the web app and MySQL in-app server will be take a longer time to load from an idle state. PHPMyadmin may not be accessible during the idle state. With ALWAYS ON feature, you can keep your web app from getting into an idle state.
+
When using this feature with Free and Shared Web App pricing plans, add the app setting WEBSITE_FASTCGI_MAXINSTANCES and set its value to 3 if your web app is likely to get traffic from a few users say between 10-20. This setting will prevent creating too many PHP FastCGI instances which will consume all the memory causing your web app to hit the quota too early. Checkout benchmarking blog post for more information.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Azure app service just launched a new feature, MySQL in-app to support MySQL natively. MySQL in-app is recommended for development and testing (DEV/TEST) scenarios to quickly spin up PHP+ MYSQL applications on Azure to start developing and understanding the Azure app service platform. You can easily migrate this database when ready for production to
+
+We conducted a benchmarking experiment with MySQL in-app to understand its performance compared to other MySQL solutions offered on Azure. We conducted two tests as described below:
+
+We conducted a benchmarking experiment with MySQL in-app to understand its performance compared to other MySQL solutions offered on Azure. We conducted two tests as described below :
+
Test Configuration
+We used simple testing methodology for both scenarios to understand the performance of the feature. The baseline configuration for both tests mentioned below are:
+
+
+
Two test clients (one is the same region as web app and one in a different region)
+
added application insights to web app to gather telemetry data
+
using MySQL in-app database
+
constant user load on the web app
+
+
+
Test Scenario with Vanilla WordPress :
+We deployed a vanilla word press web app on various pricing plans for Azure App service. No caching layer was used with the web app configuration. Note: Keep in mind that Free and Shared hosting have quota limitations that impacted the result of the tests.
+
+During this test , we set a limit on how many PHP FastCGI processes created on Free and Shared pricing plan. To learn more about limiting PHP FastCGI process , check out this article.In Azure app service , this can be done by using enabling the app setting WEBSITE_FASTCGI_MAXINSTANCES . For this test the value was set to 3.
+
+Try out the demo site
+
+
+
+
Web App SKu
+
User Load
+
Server Response Time
+
CPU Time
+
Requests
+
HTTP Server Errors
+
Average Memory Working Set
+
+
+
Free
+
10
+
248.14 ms
+
127.69
+
440
+
0
+
524.12 MB
+
+
+
Free
+
25
+
245.56 ms
+
278.01
+
903
+
0
+
597.17 MB
+
+
+
Shared
+
10
+
269.19 ms
+
166.53
+
445
+
0
+
515.6 MB
+
+
+
Shared
+
20
+
217.23 ms
+
255.81
+
960
+
0
+
537.05 MB
+
+
+
Basic Small
+
15
+
369.8 ms
+
675.81
+
2.24 k
+
0
+
421.83 MB
+
+
+
Basic Small
+
30
+
531.97 ms
+
773.88
+
2.51 k
+
0
+
285.67 MB
+
+
+
Basic Medium
+
25
+
270.54 ms
+
1.01 k
+
3.74 k
+
0
+
607.58 MB
+
+
+
Basic Medium
+
50
+
453.78 ms
+
1.59 k
+
5.47 k
+
0
+
444.87 MB
+
+
+
+
Test scenario with customized WordPress application with popularly used plugins
+After modifying the above vanilla WordPress with a few plugins to WordPress app as listed below:
+
+
MotoPress Editor lite
+
Jetpack
+
Yoast SEO
+
+This configuration is similar to a production web application and we did not include include any caching layer to understand the performance of MySQL server running locally on the azure app service instance.
+
+Demo site:
+
+
+
+
Web App Sku
+
User Load
+
Server Response Time
+
CPU Time
+
Requests
+
HTTP Server Errors
+
Average Memory Working Set
+
Memory Working Set
+
+
+
Standard Small
+
30
+
1.87 s
+
751.76
+
1.29 k
+
0
+
490.03 MB
+
7.47 GB
+
+
+
Standard Small
+
50
+
2.23 s
+
762.9
+
1.23 k
+
0
+
489.14 MB
+
7.28 GB
+
+
+
+You can make the application load even more faster , by using one or more of the options below :
+
Minify JS and CSS files as per your application framework documentation
+
Reducing HTTP requests per page
+
Compress images as per your application framework documentation
+
Optimize your database and perform regular clean up of your content
+
+
Conclusion
+MySQL in-app feature is recommended for development and testing purposes. Based on the data above you can see that this feature improves the performance of your PHP application since both the Web server and MySQL server are co-located on the same instance.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
This blog post will guide you through the process of exporting your current website's database to local MySQL. Follow the process below to export your database:
+
Locate and access your current database:
+
Your database must be remotely accessible. Check your existing hosting provider on how to access your MySQL database. Most common tool used is PHPmyadmin for accessing your database. Check out this article on How to setup PHPmyadmin for your Azure Web App if your app is already running on Azure. PHPmyadmin is browser based tool that can be used to manipulate and manage your database.
+Access your database using PHPmyadmin and click on Export tab.
+
+
+
+Select Custom export method to have the ability to modify how the script should be generated. Click on GO to generate the script and save the file locally .
+
+
+
MySQLDump.exe
+If you have MySQL installed on your local machine you can using mysqldump.exe utility usually found in the bin folder within MySQL folder. To export a remote database run the command in this format
+
+This tool offers an export wizard as shown below to export your database content. Check out the documentation for using the Export wizard to export the database
+
+
+Once you have successfully exported the database, then inspect your MySQL database script to check if your application stores the site URL in the database. If yes, then update the URL to use Azure app service web app URL or custom domain if the custom domain is already pre-configured on your Azure web app. Your script is ready to be imported.
+
Import your database
+Go to your web app Settings->Feature -> MySQL in-app to access the management settings for this feature.
+
+
Import Feature in Azure portal : Select MySQL in App setting , under Data Import and Export select "Import" to import a remote database into MySQL In App database . Enter the remote database connection information to import the database. Note that MySQL In App uses MySQL 5.7.9 version and make sure your remote database is compatible with this version of MySQL .
+
Using PHPmyadmin : To open PHPmyadmin for your MySQL in-app database . Check your SQL script and make sure the USE statement is using the database name “azuredb” . This is the database used with the connection string we provide with MySQL in-app. If the USE statement has a different database name, update it to use azuredb database. Then Click Import in the top menu in PHPmyadmin .Under File to Import, click Browse and select the script your exported from your source database. Then click Go to complete the import.
+
+
+
+When the import is completed and successful, you can update your web app to connect to azuredb database with the imported database schema. That's it and your database migration is completed.
+
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
In an upcoming release, we are making some changes to the available runtimes and PHP extensions on the Azure App Service workers. We suggest that you review your sites to ensure that these changes do not cause any downtime of your applications or tooling.
+
PHP Runtime Updates
+Due to some recent high priority security updates, we are adjusting the runtimes that are available on Azure App Service workers. For more details on the changes, please review the links to the specific version changelogs available in the After Update column of the table below.
+
Note: PHP 5.4 will soon be retired on Azure App Service as it is no longer receiving security updates. See more details about the retirement on the Azure Blog.
+Recently the SQL Server team released the Microsoft drivers 4.0 for PHP,which includes support for PHP 7. Now that this driver is no longer in preview, we are including the driver on the workers by default. If you have been loading your own version of this driver, you will need to remove the statements which are loading the driver as having a duplicate reference will cause errors.
+
XDebug
+We are updating the version of XDebug which is available on the workers by default. Currently, we have version 2.2.4 available in d:\devtools\xdebug which is being replaced by version 2.4.0. If you are referencing XDebug for profiling or remote debugging purposes, the extension will no longer be available on the workers and the references will need to be updated to point to 2.4.0.
+
+The good news is that XDebug version 2.4.0 supports PHP 5.5, 5.6 & 7.0, which means all supported runtimes now have the ability to take advantage of XDebug for debugging and profiling purposes.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Apps hosted in Free and Shared App Service plans get access to certain amounts of resources based on their quotas. You can learn more about app service quotas and how the apply to your apps here: How to: Monitor Apps in Azure App Service
+
+The new quota UX let’s get an at a glance view of the quotas applicable to your app.
+
+
+
+Each quota contains basic information about (1) the current utilization, (2) the limit for this specific quota, (3) when will the quota re-set and (4) the quota name.
+
+
+
+You can manually refresh the view by clicking on the refresh button in the action bar or provide us feedback directly about this new UX.
+
+This new UX makes it easier to understand the resource usage for your apps and what resources are being exhausted.
+
+If you have any questions about this UX or App Service in general be sure to check our forums in MSDN and Stack Overflow and for any feature requests or ideas check out our User Voice
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Azure Marketplace is a hub of solutions for users to create different types of resources. Each category of resource such as Data services, Virtual machines, Web have different on-boarding processes for ISVs to publish their solutions in Azure marketplace. In this article we will discuss the process to on-board Web Apps to Web Marketplace in Azure.
+
+To showcase your application in Web Azure marketplace , you need to get your application certified. The certification process is a 5 Step process.
+
+
+
+
+
+
+
+
+
APPLICATION
+
+
+
Step 1: Apply by providing basic information about your business and solution
+
Step 2: Share solution-specific information and wait for approval
+
+
+
+
+
ONBOARDING
+
Build your Azure package and provide the marketing content for your application . See details below.
+
+
+
CERTIFICATION
+
We’ll run tests to verify compatibility with our platform or service
+
+
+
PUBLISHING
+
+
+
Step 1: Showcase the Azure certified logo for your application
+
Step 2: Publish your application on Azure Marketplace/Azure pages
+
+
+
+
+
MARKETING
+
Promote and market your application taking advantage of Microsoft go-to-marketing resources
+
+
+
+
+
On-boarding New applications to the Web Azure Marketplace
+
For new applications:
+The on-boarding process is a gated approach and the application will be reviewed by our team. Click here to request for certification. Leverage the benefits of this program from being showcased in the Azure Marketplace but also advantages of being part of Microsoft partner network.
+
+Follow the guidelines mentioned below to build your template and test your application on App service. If accepted we will enable it in the Azure portal.
+
Existing Applications:
+We will continue to maintain existing applications in the Azure Web Marketplace. Please reach outappgal@microsoft.comif you haven't already to get details on updated process for managing updates to your application.
+
Azure Web Marketplace Principles
+Users can browse and view applications for different types of Web sites, ranging from photo galleries to blogs to e-commerce sites. To be part of the Azure Web Marketplace, developers should follow these principles, which establish a consistent, quality user experience:
+
+
Be Current: The application you provide a link to must be the latest, stable final release version available, hosted on a publicly available Web URL.
+
Application License: The application Azure Web Marketplace may provide an entry point free of charge or use Bring your own license model (BOYL) where users can purchase a license from the application publisher's website.
+
Be Compatible: The generated and configured application deployed from Azure Web Marketplace must also run on any Windows OS.The application should support running on cloud infrastructure by providing an option to make the application stateless.
+
Be Hostable: The application to which you provide a link must run well in a shared hosted environment as well as when the user has administrative rights for the computer.
+
Be Deployable: Your application code must be available on a public repository on Github.com . Azure users should be able to fork the repository and deploy to Azure web app.
+
Be Supported: You must provide a publicly available Web site where end users can download your application, find documentation and/or get free on a best effort basis support through a forum.
+
Be Platform Independent: The application to which you provide a link must be able to run on all Windows platforms x86, and x64.
+
Be Inclusive: If your application is included in the Gallery, you should include a statement of availability in the Azure App Gallery on the application community’s Web site.
+
Be Safe: The application to which you provide a link must not harm customers or be malicious, dishonest, destructive, invasive, or act in any manner restricted by the Web Gallery Application Submission agreement.
+
Be a Web App: The application to which you provide a link must be a Web application that can be used to generate a working, usable Web site after deployment without requiring code or customization.
+
Support Database Dependencies: Currently our create experience supports Web App with Database ( MySQL and/or SQL DB). If your application has other dependencies , Web Marketplace may not be an option.You may want to look into Azure solution templates.
+
+
Package your application code
+Using Git Deploy: Create a public Github repository with your application code as it would be deployed under wwwroot in the Azure web app. You may include custom post deployment scripts with a deploy.cmd file in the root of your repository, see details on how to add custom scripts.
+
+This packaging method makes managing updates to your application easier without having to go through the entire certification process. For future updates to your application , you need to update the code in the repository with appropriate commit message for users to pull in to latest bits of your application. When code changes are committed to your repo , the code is not automatically pulled in for users using your application to prevent breaking their application. Users using your application must perform a manual sync to pull in the latest committed changes from your repository.
+
Note: We are no longer supporting Web deploy method of application packaging for NEW applications in the Web marketplace.
+
Building an Azure Package for Marketplace
+Azure Package has a special folder structure to be consumed by Azure Marketplace service. Each folder at the root level approximately represents a publisher. A folder contains one or more .json files, called package manifests, each of which contains the metadata for an Azure Gallery package. Every folder also includes a set of deployment templates, strings , icons and screenshots which can be referenced by the package manifests. See the folder structure shown below :
+
Manifest.json: The manifest file contains all of the metadata for your gallery item. For a visual representation of where each metadata value is used , view the schema for Manifest.json. Add the paths to the Icons , Screenshots and links to articles that can help customers get more information about your application.
+
+
+
UIDefinition.json :Use the UIDefintion.json schema to build appropriate UIDefinition.json for your application. You can use "parameters" properties which is optional , if your application needs to ask the user for information for the deployment of your app. These parameters become AppSettings for your web app and can be consumed within your app as environment variables.To hide a parameter from the portal UI , set "hidden":true as show here . To mark a parameter as required for the create experience , set "required":true as shown here.
+
Icons : The relative path specified by iconPath in a package manifest must point to a folder that includes the following four images with these dimensions mentioned below:
+
+
Small.png (40x40 px)
+
Medium.png (90x90 px)
+
Large.png (115x115 px)
+
Wide.png (255x115 px)
+
+You can group icons under sub-folders if you have different ones per product. Just be sure to include the sub-folder in the iconPath for the package manifest that uses them.
+
Screenshots : Images must be exactly 533px by 324px and in PNG format. Specifying a screenshot for a gallery package is completely optional, so do not feel compelled to include one unless it makes sense for your offering.
+
Deployment Templates : Include an ARM template that allows Azure users to deploy the application via PowerShell. To learn how to build an ARM template , read the guidelines stated here .
Run these tests in at least 3 different Azure regions.
+
Save the results of these deployment in an Excel or Word document. The excel document should have the following columns:
+
+
Resource group
+
Web app name
+
Region
+
Subscription ID
+
Time of deployment
+
Web app Pricing Tier or Sku
+
Tested with Auto-scale feature[ Values : Pass/Fail]
+
+
Test your application with auto-scaling feature turned on and under a heavy load . For example you can choose to run a 5 min load test of 50 users on Web App Standard Small (S1) Pricing tier
+
+
+
Tested with Continuous Integration[ Values : Pass/Fail]
+
+
In this test , publish changes to your application and see if you changes are being picked up by your application linked to the Github repository .
+
+
+
Tested with Deployment slots [ Values : Pass/Fail]
+
+
In this test , create a deployment slot. Connect to the application Github repository to the deployment slot.
+
Push changes to the github repository and then complete to Swap your application slot with production slot.
+
+
+
Tested with Backup and restore [ Values : Pass/Fail]
+
+
In this test configure and setup Backup for your application code and database (optional) to be backed up.
+
restore from the backup ZIP file to an existing site
+
+
+
+
+
+There are some limitations with the Azure create in the portal and power shell . If your application requires these configurations mentioned below , we will not be able to on board the application.
+
+
+
+
+
+
+
+
You web app need Virtual application setting to be configured for web app
+
Your web app need a dependency that is not supported by App Service create scenario. We currently support ONLY SQL DB , MySQL and Azure Storage dependencies.
+
+
+
+
+
+
+
+
Submit your application
+Submit a certification request here . Please do provide information about your application during submission . Here is the kind of information we are looking for to learn about your application
+
+
What is current Usage statistics of your application
+
Do you have customers using your application on the Cloud ( Azure or other hosting providers). If yes share at least 2 customer stories.
+
How active is the community engaged , primarily for Free applications this information is required
+
+You will receive a response in 3-5 business days with a request for more information or with next steps to move forward.
+
Post publishing
+We recommend to maintain documentation and support for your application on your website. This is key to help get new users started with using your application and follow best practices based on your guidance.
+
Marketing
+Once approved your application will be visible in the Azure portal under "Web + Mobile" category. Users can view your application on Azure website in the Marketplace page.
+
FAQ
+Check out the frequently asked questions here . If you don't see the answer to your question , contact us at appgal@microsoft.com
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 9 minute read
+
+
+
+ • By Steve Dower
+
+ • August 4, 2016
+
+
+
App Service is Microsoft Azure’s platform-as-a-service offering for web apps, whether they are sites accessed through a browser, REST APIs used by your own c...
We're happy to announce we've officially released Azure Functions host version 0.5 into our Public Preview, as well as some updates to our Portal experience. The host version does include several breaking changes, so please read the release notes before upgrading. We will also be updating our default version in create to ~0.5 as well, so new deployments that don't specify a version will be on the latest.
+
F# support now in preview
+
Thanks to the excellent work by the F# team including Don Syme and Tomas Petricek, we're happy to announce we finally support F# in a first-class fashion in Azure Functions. Previously, we just invoked your F# script via fsi. Today, it now running hot in our runtime, with support for input and output bindings. Note that this new F# experience is incompatible with the previous versions.
+
Here's a quick sample that would work off of a Queue trigger.
+
let Run (input: string, log: TraceWriter) =
+ log.Info(sprintf "F# script processed queue message '%s'" input)
+
+
If you are familiar with the C# experience, you'll remember the TraceWriter. This is because we support all the same types that C# supports. We haven't finished updating the documentation yet, but we'll be soon updating the C# docs to be the .NET docs.
+
For those curious in how it was built, feel free to check out PR #577.
+
Other breaking changes & improvements
+
In addition to F# support, we have a few other breaking changes and notable improvements. You can read our full release notes on 0.5 release on GitHub.
Event Hub trigger can now configure maxBatchSize and prefetchCount for advanced scenarios.
+
C# Package Restore automatic restore improvements
+
Logging improvements for performance and usability
+
File Watcher can now be configured for where to look for changes.
+
context.bindingData property casing is now lower camel cased (previously upper camel cased)
+
Twilio is now supported as a binding by the host.
+
+
Portal updates
+
We also have some large updates to the portal experience rolling out today. Below are some highlights:
+
+
Localization is now available for many languages
+
Tabs have all been moved to the left nav, rather than left and top. This change happened to improve usability in understanding Functions vs Function Apps.
+
Actions for certain output bindings on Integrate tab. We found it was common to copy+paste settings from an output binding to a new trigger, so we added a button to do it for you.
+
Dropdown pickers for connections - if you have an existing connection to Storage/etc., we'll show you those in a dropdown menu, rather than always having to choose from the picker blade (which can have LOTS of choices for large, shared subscriptions).
+
Documentation is now available in the Integrate tab. This will hopefully make it more obvious how to use the bindings when you add them/modify them, rather than knowing where in the main docs site to look.
+
You can now delete/rename files from the file explorer menu on the Develop Tab.
+
Better whitespace usage on Integrate tab
+
App Settings, Kudu, and Console now available from the Function App Settings menu, rather than having to jump through Advanced Settings.
+
+
What comes next?
+
With this release complete, we'll be starting our next wave of planning. We need and look forward to your feedback. You can submit general feedback on feedback.azure.com or, if you feel familiar with our host or portal, you can submit issues directly on GitHub (Host GitHub & Portal GitHub). Most of our planning happens on GitHub, so you can see things coming as they are in progress.
+
Feel free to ask questions below or reach out to us on Twitter via @AzureFunctions. We hope you have fun with the new changes. We're looking forward to seeing what you do!
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Here are some troubleshooting guidelines for MySQL in-app feature:
+
+
1. I cannot to access the database using Phpmyadmin
+When you access PHPmyadmin for MySQL in-app and the page returns a login page or “cannot connect: invalid settings” error. There can be two causes for this issue:
+
+
MySQL process may not be running.
+
+Check process explorer if MySQL is running for your web app. You can access the process explorer in the portal. Select your web app -> Tools -> Process explorer
+
+
+There will be mysqld.exe process visible in the process explorer.
+
+If the process mysqld.exe is not visible in the process explorer, then browse the web app or ping your web app which would trigger mysqld.exe process to run. Check process explorer again to verify that mysql process is running and browse phpmyadmin.
+
+
You have two instances of PHPmyadmin installed
+
+With MySQL in-app we already preconfigure and setup PHPmyadmin. If you install PHPmyadmin from Site extensions gallery, then you will end up having two instances of PHPmyadmin. To identify if you have two instances both the conditions below will be true:
+
+
PHPmyadmin folder exists in D:\home\siteextensions folder
+
web app is using MySQL in-app feature
+
+To resolve this, remove the site extension. Access the site extension gallery and click on remove button. Restart your web app and access your database with PHPmyadmin .
+
+
There may be a connection strings in application settings.
+
+Check in your web app application settings if there is a connection string. PHPmyadmin uses MYSQLCONNSTR_ to connect to the MySQL server. If you have a connection string in application setting change the connection string type to Custom , so you can still have the information if needed or delete it. This will force PHPmyadmin to access MYSQLCONNSTR_localdb and connect to the MySQL in-app server.
+
+
+
+
File server storage is in read only mode
+Click here to learn more
+
+
2. My application cannot connect to MySQL in-app database
+If your web app is unable to connect to MySQL in-app database, it could result from :
+
+
MySQL process is not running for your application: You can access the process explorer in the portal. Select your web app -> Tools -> Process explorer. There will be exe process visible in the process explorer. If the process mysqld.exe is not visible in the process explorer, then restart the web app and browse the web app. Now check process explorer again to verify mysqld.exe loads and check if your web app is functioning correctly.
+
Your web app is not configured correctly to use MySQL in-app: MySQL in-app does not use port 3306 for MySQL server and hence DO NOT hard code the database information in your application configuration file. If the MySQL port used by your web app as using in not available during the situations mentioned below, the MySQL port will change:during an upgrade of azure app service
+
+
when your web app is scaled up/down
+
when your app is moved to a different app service plan
+
when you migrate your app from one subscription to another subscription
+
+
+
+To make your app resilient, use environment variables as shown here.
+
3. I cannot import my database with PHPmyadmin
+PHPmyadmin allows your to import a database , but this may fail due to:
+
+
MySQL server used when exporting the database is different than the MySQL version used in MySQL in-app and the schema changes are not supported in the version of destination MySQL server.The version on MySQL in-app is 5.7.9.0. You verify this check by checking the version number folder in MySQL folder "D:\Program Files (x86)\mysql\5.7.9.0"
+
PHPmyadmin version used for exporting the database varies with PHPmyadmin version used to import the database schema. The PHPmyadmin version that is used with MySQL in-app is 4.5.1. During export make sure the schema is supported. A workaround is to use mysqlimport.exe found in D:\Program Files (x86)\mysql\5.7.9.0\bin on the Kudu Debug console
+
The exported database file is greater than 8MB. PHPmyadmin is a php application , and the max_upload_size is 8MB for PHP on Azure app service. You can either modify the max_upload_size to your desired value before doing an import as per instructions mentioned here or use mysql utilities in Kudu debug console to do the import with this sample command
+
+Note: When using mysqlimport.exe via Kudu debug console , the browser session timesout after 10 mins. If you have a large file then add the app setting SCM_COMMAND_IDLE_TIMEOUT=3600 for your web app prior to running mysqlimport.exe.
+
4. I cannot write to the database OR I cannot create a comment or post on WordPress application
+
Turn on PHP error logs and if the error log states that the "InnoDB is in read only mode". This means file server storage is in READ ONLY mode , note that the file server is shared by your web app and MySQL database. The file server can be in read only mode due to
+
+
an upgrade on the service : Once the upgrade is completed you should be able to write to the database. This usually does not take more than a few minutes.
+
Platform issues : Check the Azure status to see if there are any ongoing issues that could be resulting in this.
+
Network blips : This could impact the site for a couple of seconds if there was network connection loss.
+
+It is recommended to code your application to detect if the storage is in read only mode when using MySQL in-app. This can be done using a simple check to see if the folder wwwroot is writable using is_writable() in PHP before executing any INSERT / UPDATE / DELETE /CREATE Sql queries in your application.
+
5. How can I change MySQL server configuration
+Click on your web app -> application setting , under app settings add the Key/Value pair , for example to increase max allowed packet to 16MB
+
+WEBSITE_MYSQL_ARGUMENTS = --max_allowed_packet=16M
+
+
+
+
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Here is a troubleshooting guide for PHP errors on Azure app service.
+
5xx Errors
+
+
+
Multiple loaded extension: You might notice an error in php_errors.log when a extension is not loading. It could be that there is another extension already pre-configured on the platform. Install PHP manager ( extension as shown in the image) from the portal to check which extension are available and/or enable before bringing in your custom php extension.
+
+
MySQL gone away: This error can occurs due to various reasons as listed below:
+
+
• A query was executed after closing the connection to the server. This is a logic error in your application. Review your code and make changes.
+
• The connection may have timed-out. You can use mysqli_options() to increase the timeout.
+
• Long running query especially using INSERT or REPLACE commands can cause this issue.
+
• Since ClearDB is different service, there could have been a networking blip connecting to ClearDB database. To work around this, you can add a retry logic to connect to your database.
+
• If you are using ClearDB shared hosting, note that it is shared hosted service and if another user is using up all the resources you might get this error. To work around this, you can add a retry logic to connect to your database.
+
• MySQL server may have crashed due to an incorrect query. Review your code to identify the query.
+
+
Redis gone away: This can happen due to network blips or if the server is down. As best practice include a retry logic to connect to your Redis server. For further troubleshooting, check this article.
+
+
Database deadlock error: Deadlocks occur when are there are multiple requests to write to the same table/ same record (based on the lock configuration on your database) at the same time. To avoid this, you need to include some logic in your app to manage deadlock scenario.
+
Error connecting to database: Check if your database is accessible. You can use MySQL workbench or mysql command line
+
+
Deprecated warning: It is recommended to notices and deprecated errors to reduce the stress on PHP process when writing to the logs especially if you app does generate too many notices and warning. These should b enabled on your staging or dev sites but on your production site it should be disabled. Read this article on how to change the way error is logged in PHP.
+Best way to identify your application performance issues, is to profile your application. Use Xdebug profiler to profile your application. The most common reasons that could impact performance are:
+
+
PHP error reporting is turned on. If your application is returning too many warnings that is causing PHP process to write to php_errors.log. This can impact performance.
+
Your app is making too many I/O operations. Note that the file storage is Azure Storage linked to your web app like a network drive. Too many calls to read or write can impact performance. You can reduce the read operations by using Wincache filecache and Wincache reroute settings.
+
App may be causing an overhead on the database by making too many calls to the database. Use Wincache or Redis cache to reduce the stress on your database.
+
+
Security Issues
+
+
Using mysql extension: MySQL extension has been officially deprecated . It does not support SSL and does not support for many MySQL features. Using this is a security risk and users can look for the php warning "The mysql extension is deprecated and will be removed in the future" and identify if a site is using mysql extension. Upgrade your mysql driver to use mysqli instead of mysql extension.
Disable development configurations: Disabling all your development environment configuration such as debug configuration. This opens your application to security risk allowing access to malicious users to information on your web app.
+
+
Using "admin" username for your web app administration dashboard : All CMSs like WordPress, Drupal etc. provide you're with an administration dashboard. admin is the most common username used for a super administrator user and can be easily hacked by malicious users. Hence NEVER use admin as a username for your super administrator for your web application. It is recommended to enforce a strong username and password for a super administrator users.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
If you are reading this blog, you have most likely heard the term Serverless once or twice in the past few months. In a nutshell, Serverless means a fully managed platform capable of running your code (in the form of functions), at almost any given scale while paying only for the time when your code is running. Serverless is sometimes categorized as ‘reactive’ compute, where functions are executed (react) when specific events occur. For the purpose of this blog, I will focus on the developer experience.
+
+There are several options to get firsthand experience with Serverless development, but all options require creating an account (typically providing credit card information) with a vendor. This changes today. Now you you can get a peek into the world of Serverless for free (no credit card required) with no commitment. If you have a Microsoft, Google, or Facebook account you can get started immediately. To get an hour of free Azure Functions experience browse to https://functions.azure.com and click the big green Try-It-For-Free button. Azure Functions is a Serverless compute, event driven experience that extends the existing Azure App Service platform. Azure Functions can scale based on demand and are billed only for resources consumed.
+
+Try Azure Function experience gives you the ability to create Azure functions and run them, even without an Azure account. Since this a “Try” experience, you don’t have access to all binding and triggers supported by Azure Functions, and you only have one hour each time you log-in. However, even with these limitations you can create cool Serverless examples.
+
+Ready? let’s get started
+
+Let’s start out by using the Try Azure Functions experience to create a simple HTTP trigger function..
+
+Here is a very simple HTTP trigger “Hello World” example. Try it yourself:
+
+
Choose Webhook + API scenario (many other templates are available for other scenarios)
+
Choose your programming language between C# or JavaScript (node.js). Azure Functions support additional languages like F#, Python, PowerShell and CMD.
+
Click “Create this function” button, which will prompt you to login
+
Login with your selected social identity, wait for few seconds… and you have an HTTP trigger function ready for use
+
+
+
+
+
+You can copy the Azure Function URL (highlighted below) and paste it into your browser. You should receive a response. You might want to add &name=YourName to the Function URL as the default http trigger template expects name query parameter. Just like that, you created a fully working HTTP endpoint in the cloud.
+
+
+
+While this was is an impressive example of how easy it is to create an HTTP endpoint in the cloud, it turns out you can do quite a lot more! Let’s put together the following scenario. Upload an image that includes some text in it, run an OCR on the image to extract the text, store the text, and finally retrieve both image and text. For small images or for a low volume of image uploads, you can probably do it all in a single Function. However, we want to leverage the Serverless nature of Azure Functions to create a scalable and highly performant design. To do so, we will create three functions:
+
+
An HTTP trigger function exposing simple REST API to upload an image.
+
A blob trigger function that will extract the text from the image when it id uploaded to the blob storage.
+
Another HTTP trigger function exposing simple REST API to query the results of the text extraction.
+
+
+
+
+
First Function – a simple REST API uploading an image to Azure Blob
+You can imagine a scenario in which you have a web or mobile app that needs to upload images for processing. A function receiving the uploaded image can expect an HTTP POST from an HTML form that might look like this:
+
+ <label>
+ Using JQuery
+ </label>
+ <input name="file" type="file" id="me" />
+ <input type="button" id="Upload" value="Upload" />
+</form>
+
+
+
+We want our function to receive an image and store it in Azure Blob Storage. This is a classic reader/writer pattern, where you want your API layer to do as little complex computing as possible. The Azure Functions concept of Bindings enables developers to directly interact with the input and output values of Functions data sources. Those include Azure Storage Queue, Tables, and Blobs as well as Azure Event Hubs, Azure DocumentDB and more. Click here for full list of binding.
+
+Let’s add an Azure Blob output binding. On the Integrate tab, click New Output and choose Azure Storage Blob.
+
+
+
+The Blob parameter name, is an input argument (parameter) passed to your Function. Just like you would expect when programing any regular function. Azure Functions takes it one step further, enabling to use such bindings without knowing anything about the underlying infrastructure. This means that you don’t need to know how Azure Storage works or install Storage SDKs to use Azure Blob as your function output. You just use the outputBlob object in your function, save the image to that blob and the uploaded image will appear in your Storage Blob. In the try experience you don’t have a direct access to the underline storage account powering your Functions. However, you will see it in action by the time you complete the 3rd function. Make sure you update the Path to include “.jpg”, and hit Save.
+
+
+
+In the function code, we refer to outputBlob as an object that is ready to be used. This function is implemented in C# and uses StreamProvider to read the image data from the HTTP request and store it to an Azure Blob. I don’t have any idea how Azure Storage works. Behind the scenes Azure Functions takes care of moving data in to and out from my functions. It is like magic, quick and easy to use.
+
#r "Microsoft.WindowsAzure.Storage"
+
+using System.Net;
+using Microsoft.WindowsAzure.Storage.Blob;
+
+public static HttpResponseMessage Run(HttpRequestMessage req, Stream outputBlob, TraceWriter log)
+{
+ log.Info($"C# HTTP trigger function processed a request. RequestUri={req.RequestUri}");
+
+ HttpResponseMessage result = null;
+
+ if (req.Content.IsMimeMultipartContent())
+ {
+ // memory stream of the incomping request
+ var streamProvider = new MultipartMemoryStreamProvider ();
+
+ log.Info($" ***\t before await on ReadMultpart...");
+ req.Content.ReadAsMultipartAsync(streamProvider);
+ log.Info($" ***\t after await on ReadMultpart...");
+
+ //using a stream saves the 'last' iamge if multiple are uplaoded
+ foreach (HttpContent ctnt in streamProvider.Contents)
+ {
+ // You would get hold of the inner memory stream here
+ Stream stream = ctnt.ReadAsStreamAsync().Result;
+ log.Info($"stream length = {stream.Length}"); // just to verify
+
+ // save the stream to output blob, which will save it to Azure stroage blob
+ stream.CopyTo(outputBlob);
+
+ result = req.CreateResponse(HttpStatusCode.OK, "great ");
+ }
+ }
+ else
+ {
+ log.Info($" ***\t ERROR!!! bad format request ");
+ result = req.CreateResponse(HttpStatusCode.NotAcceptable,"This request is not properly formatted");
+ }
+ return result;
+}
+
+
+
Second Function – Performs OCR
+Let’s create the second function, called ImageOCR. This function will be triggered every time a new image file is uploaded to the blob storage container (named outcontainer) by the first function. Then the function will run OCR on that image to extract text embedded in it. Note, this function will run only when a new image (or any other file…) is uploaded to the blob. Again, this is Serverless in its best form, your code will run only when needed and you will pay only for that time.
+
+
+
+Make sure the Azure Storage Blob container name you use to trigger is the same as the Blob container name used to write the image from the first function. If you have not changed the default, the container name of the first function is outcontainer.
+
#r "System.IO"
+#r "System.Runtime"
+#r "System.Threading.Tasks"
+#r "Microsoft.WindowsAzure.Storage"
+
+using System;
+using System.IO;
+using System.Text;
+using System.Threading.Tasks;
+using Microsoft.WindowsAzure.Storage.Blob;
+using Microsoft.ProjectOxford.Vision;
+using Microsoft.ProjectOxford.Vision.Contract;
+using Microsoft.WindowsAzure.Storage.Table;
+
+public class ImageText : TableEntity
+{
+ public string Text { get; set; }
+ public string Uri {get; set; }
+}
+
+public static void Run( ICloudBlob myBlob, ICollector outputTable, TraceWriter log)
+{
+ try
+ {
+ using (Stream imageFileStream = new MemoryStream())
+ {
+
+ myBlob.DownloadToStream(imageFileStream);
+ log.Info($"stream length = {imageFileStream.Length}"); // just to verify
+
+ //
+ var visionClient = new VisionServiceClient("YOUR_KEY_GOES_HERE");
+
+ // reset stream position to begining
+ imageFileStream.Position = 0;
+ // Upload an image and perform OCR
+ var ocrResult = visionClient.RecognizeTextAsync(imageFileStream, "en");
+ //log.Info($"ocrResult");
+
+ string OCRText = LogOcrResults(ocrResult.Result);
+ log.Info($"image text = {OCRText}");
+
+ outputTable.Add(new ImageText()
+ {
+ PartitionKey = "TryFunctions",
+ RowKey = myBlob.Name,
+ Text = OCRText,
+ Uri = myBlob.Uri.ToString()
+ });
+ }
+
+ }
+ catch (Exception e)
+ {
+ log.Info(e.Message);
+ }
+}
+
+// helper function to parse OCR results
+static string LogOcrResults(OcrResults results)
+{
+ StringBuilder stringBuilder = new StringBuilder();
+ if (results != null && results.Regions != null)
+ {
+ stringBuilder.Append(" ");
+ stringBuilder.AppendLine();
+ foreach (var item in results.Regions)
+ {
+ foreach (var line in item.Lines)
+ {
+ foreach (var word in line.Words)
+ {
+ stringBuilder.Append(word.Text);
+ stringBuilder.Append(" ");
+ }
+ stringBuilder.AppendLine();
+ }
+ stringBuilder.AppendLine();
+ }
+ }
+ return stringBuilder.ToString();
+}
+
+The function is triggered by any file uploaded to the blob container. The default input parameter type of the function is string, but I will be using ICloudBlob, as I want to read the image as a stream and I want to get the image file name and URI. As you can see, Azure Functions binding provides a very rich experience.
+
+To perform the OCR on a given image, I am going to use using Microsoft Cognitive Services , also known as Project Oxford. I could use any 3rd party tool, bring a dll that implements the algorithm, or write my own. However, leveraging other services as much as possible is a core tenant of Serverless architecture. If you don’t have a Cognitive Services account, sign up for free at https://www.microsoft.com/cognitive-services
+
+Using the Cognitive Services is very easy, it comes down to two lines of code:
+
var visionClient = new VisionServiceClient("YOUR_KEY_GOES_HERE");
+ // reset stream position to begining
+ imageFileStream.Position = 0;
+ // Upload an image and perform OCR
+ var ocrResult = visionClient.RecognizeTextAsync(imageFileStream, "en");
+
+In order to make the ImageOCR function code work, you’ll need to import ProjectOxford assemblies. Azure functions support project.json files to identify nuget packages (for C#) to be automatically restore with the function. For node.js Azure Functions support npm.
+
+In the Functions UI, click on View files and add project.json with the following text. once you save this file, Azure Functions will automatically restore the ProjectOxford package.
+
+
+
+
+
+In order to make the ImageOCR fFunction code work, you’ll need to import Project Oxford assemblies. Azure Ffunctions supports a project.json files to identify nuget NuGet packages (for C#) to be automatically restored with the functionFunction. For node.js, Azure Functions supports npm.
+
+In the Functions UI, click on View files and add project.json with the following text. Oonce you save this file, Azure Functions will automatically restore the Project Oxford packages.
+
+
+
+We want to save the results somewhere. In this Try Functions example we are using Azure Storage Table. Note – if you have an Azure Subscription, you can use many other Data Services provided by Azure to store and process the results.
+
+Let’s add an output binding to Azure Table Store
+
+
+
+
+
+Next, change the Table name from the default to ImagesText. The Table parameter name, outputTable will be used in the function code.
+
+
+
+
+
+And again, just like with the blob, I don’t need to know a lot about how Azure Storage Tables work. Azure Functions is doing all the heavy lifting. We are using the ImageText table to store the image Uri (pointer to the blob storing the image), the OCR results, and the table keys in the form of a GUID.
+
+You have now completed the creation of a function that scans an image, extracts text from it and stores the results into persistent storage.
+
Third Function – simple REST API to query OCR results
+The last function we are going to create is of type HTTP trigger and will be used to return list of images and the text we extracted from the images in the second function.
+
+This time we will add an Azure Storage table as an input binding, because you would expect your function to receive the table store object to work with and extract the data. As before, make sure you are using the same table name you used in the second function. Note the Partition Key, which is optional was hard-coded for TryFunctions.
+
+
+
+The function input argument is of type IQueryable<ImageText>, which represent a collection of results queried from Table Storage. Its ready to use without any knowledge of how Azure Table Storage works, I get a list I can work with. We create a SimpleImageText object representing the response and return a JSON representation of the data.
+
#r "System.IO"
+ #r "System.Runtime"
+ #r "System.Threading.Tasks"
+ #r "Microsoft.WindowsAzure.Storage"
+ #r "Newtonsoft.Json"
+
+ using System;
+ using System.Net;
+ using System.IO;
+ using System.Text;
+ using System.Threading.Tasks;
+ using Microsoft.WindowsAzure.Storage.Table;
+ using Newtonsoft.Json;
+
+ public static async Task Run(HttpRequestMessage req, IQueryable inputTable, TraceWriter log)
+ {
+ log.Info($"C# HTTP trigger function processed a request. RequestUri={req.RequestUri}");
+
+ var result = new List();
+
+ var query = from ImageText in inputTable select ImageText;
+ //log.Info($"original query --> {JsonConvert.SerializeObject(query)}");
+
+ foreach (ImageText imageText in query)
+ {
+ result.Add( new SimpleImageText(){Text = imageText.Text, Uri = imageText.Uri});
+ //log.Info($"{JsonConvert.SerializeObject()}");
+ }
+// log.Info($"list of results --> {JsonConvert.SerializeObject(result)}");
+
+ return req.CreateResponse(HttpStatusCode.OK, JsonConvert.SerializeObject(result));
+ }
+
+ // used to get rows from table
+ public class ImageText : TableEntity
+ {
+ public string Text { get; set; }
+ public string Uri {get; set; }
+ }
+
+ public class SimpleImageText
+ {
+ public string Text { get; set; }
+ public string Uri {get; set; }
+ }
+
+
+
We created three functions, it is time to test them.
+You can use any of your favorite tools to generate HTTP calls, including CURL, writing a simple html / Java script, or anything else. To test both HTTP functions I’ll use Postman, using form-data as a Body to POST to the first function URL. You should receive “great” as a response and if you look at the first function log, in the Try Azure Function UI, you will notice traces from your function. If something went wrong, try debugging it… or ping me on Twitter (@yochayk)
+
+
+
+
+
+Assuming your first function worked, go to the OCR image function and upload another image. You will notice that the OCR function got triggered, which means your first function successfully saved the image to storage and your second function picked it up. Again, you should see in the log traces from your function.
+
+Use Postman to call the last function and you should see JSON array including two images and the text extracted from them.
+
+
+
+
+
+here is repo with the function. Note, my solution is a little more complex and includes handling multiple uploaded files and adding a SAS token to the container.
+
+One small note: if you want to view the images, you will need to generate a SAS token for the container, as by default, an Azure Blob Storage container permission blocks public read access. I’ve added the required code, which generates a 24 access token to images, to the ImageViewText functions. You will also need to pass the blob container as input argument for the functions.
+
// IQueryable return list of image text objects
+ // CloudBlobContainer used to generate SAS token to allow secure access to image file
+ public static async Task Run(HttpRequestMessage req, IQueryable inputTable, CloudBlobContainer inputContainer, TraceWriter log)
+ {
+ log.Info($"C# HTTP trigger function processed a request. RequestUri={req.RequestUri}");
+
+ //get container sas token
+ var st = GetContainerSasToken(inputContainer);
+ //log.Info($"token --> {st}");
+ var result = new List();
+
+ var query = from ImageText in inputTable select ImageText;
+ //log.Info($"original query --> {JsonConvert.SerializeObject(query)}");
+
+ foreach (ImageText imageText in query)
+ {
+ result.Add( new SimpleImageText(){Text = imageText.Text, Uri = imageText.Uri + st});
+ //log.Info($"{JsonConvert.SerializeObject()}");
+ }
+
+ return req.CreateResponse(HttpStatusCode.OK, JsonConvert.SerializeObject(result));
+ }
+
+ // used to get rows from table
+ public class ImageText : TableEntity
+ {
+ public string Text { get; set; }
+ public string Uri {get; set; }
+ }
+
+ public class SimpleImageText
+ {
+ public string Text { get; set; }
+ public string Uri {get; set; }
+ }
+
+ // generate 24 hour SAS token for the container. Will allow read for all images
+ // TBD - shoudl be done once every 24 hours via timer, rather than each time in the funciton
+ static string GetContainerSasToken(CloudBlobContainer container)
+ {
+ //Set the expiry time and permissions for the container.
+ //In this case no start time is specified, so the shared access signature becomes valid immediately.
+ SharedAccessBlobPolicy sasConstraints = new SharedAccessBlobPolicy();
+ sasConstraints.SharedAccessExpiryTime = DateTime.UtcNow.AddHours(24);
+ sasConstraints.Permissions = SharedAccessBlobPermissions.Read;
+
+ //Generate the shared access signature on the container, setting the constraints directly on the signature.
+ string sasContainerToken = container.GetSharedAccessSignature(sasConstraints);
+
+ //Return the URI string for the container, including the SAS token.
+ return sasContainerToken;
+ }
+
+
+
+With the updated ImageViewText function you can now test your application with a simple Single Page Application I host on Azure Storage http://tryfunctionsdemo.blob.core.windows.net/static-site/test-try-functions.html
+
+
+This simple HTML application has two text box for you to paste the URL of your function. You upload an image by dragging and dropping. You can get images by clinking the GetImages button. The screen capture shows the network calls and console for getting images. You can see on the console, the get images return array of images, with respective URIs and each image text, which we use to then display. Note the images have SAS tokens.
+
+Hope you enjoy trying Azure Functions as much as I enjoyed writing this little demo. If you have any issues ping me on Twitter (@yochayk).
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
This Mobile Client SDK release is out of 3.0.0-beta!
+
The previous Mobile SQLiteStore 2.x.x libraries depending on SQLitePCL, which uses the Android system SQLiteStore, no longer works with Android Level 24/Android N. Starting with Android Level 24/Android N, the Android system SQLiteStore cannot be accessed expect through the android.database.sqlite Java wrapper (Eric Sink has a great blog post here detailing the issue). This enforcement from Android impacts customers working with native Android, Xamarin.Android, and Xamarin.Forms Android. This 3.0.1 release updates the Mobile SQLiteStore library to take dependency on SQLitePCLRaw.bundle_green and SQLitePCLRaw.Core to resolve this problem.
+
We unified versions across .NET Client SDK and SQLiteStore library to make dependencies and developer experience more straightforward.
+
+To take advantage of the releases, simply uninstall dependencies to your client project and grab the latest versions with Visual Studio package manager. Let us know if you bump into any issues!
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
ClearDB MySQL database now supports single step upgrade in Azure portal. If you using a ClearDB database you may at some point in time hit quota limitations on ClearDB such as max connections or storage limits . For more details in pricing tiers and quota limits click here.
+
Click on All resources and select your ClearDB MySQL database
+
Click on Settings->Scale up your database
+
+
+
+4. Select the pricing tier. Currently on single step upgrade is supported , which means if the current pricing tier is Mercury , you can upgrade to Titan . You cannot upgrade from Mercury pricing tier to Venus pricing tier at the skipping other pricing tiers during the upgrade.
+
+Key things to remember:
+
+
Currently this feature does not support downgrade from higher pricing tier to a lower pricing tier.
+
If you are using a database on Jupiter tier. You will not see scale up database setting in the Azure portal .
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
UPDATE: Azure App Service companion is now available in the Apple App Store for your iOS devices
+
+
+Today when you are managing your existing Azure App Service assets you have two options, the Azure Portal, or Azure CLI both of these experiences are great when used in your laptop/desktop regardless of what operating system you are using. However, neither of them are tailored for use in mobile scenarios. This is where Azure App Service Companion comes into play.
+
+The goal for Azure App Service Companion is to provide the basic functionality that you need when you are on the go, without requiring you to use your laptop. All in a native experience for your device.
+
+
+Azure App Service Companion allows you to:
+
+
Monitor your App Service instances
+
View custom alerts based on site status
+
Troubleshoot sites from anywhere
+
+
+
+
+
+
+
+
+
+
+The initial preview release for the app is now available in Google Play, we will be adding more functionality and new features in the coming weeks.
+
+If you have any questions about this app or App Service in general be sure to check our forums in MSDN and Stack Overflow. For any feature requests or ideas check out our User Voice
+
+In order to use the full capabilities of this application, you need to have an active Microsoft Azure subscription. To learn more about Azure subscriptions, see http://aka.ms/AzureSubscriptions.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Application Insightshelps you detect and diagnose quality issues in your web apps and services, and enables you to understand what users actually do with them. We believe that Application Insights provides great value to Azure App Service users and that’s why we have made it super easy to enable this for your app from within the Azure portal.
+
+
The new Application Insights experience can be started form the Application Insights menu item in the monitoring section for any Web, Api or Mobile app.
+
+
If your app is not already configured to use Application Insights, the UX will allow you to link it to an existing Application Insights resource or create a new one on the fly.
+
+
Once the Application Insights resource has been created and the link between it and your app is in place, you will start to see data stream into the UX, assuming there is currently traffic on your app.
+
You can get even more data, customize views, queries and a lot more by going to the Application Insights resource blade:
If you have any questions about this UX or App Service in general be sure to check our forums in MSDN and Stack Overflow and for any feature requests or ideas check out our User Voice
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Today, we released a patch version of the Azure Mobile Apps .NET SDK. If you have already adjusted your clients to use v3.0.1, then this update does not provide any benefit. However, if you are upgrading from v2.x to get support for Android Nougat, you should use v3.0.2.
+
+Here are the improvements:
+
+
+
(#233, #235, #240) The .NET SDK v3.0.1 required iOS and Android developers to create the offline database file prior to its use. This is no longer a requirement.
+
(#236) The SQLitePCL.Batteries.Init() initialization code was called multiple times. We also suggested that you call it yourself. You no longer have to call it yourself, and it is only called once.
+
(#231, #232) We have updated documentation. The documentation now clarifies our supported platforms, and the HOWTO includes the new instructions for working with offline data.
+
+
+In addition, we've updated the quick start projects that you can download from the Azure portal to use the new SDK.
+
+As always, we encourage you to post on Stack Overflow if you are running into problems. If you find a bug or want a feature, please file an issue on our GitHub repository.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
We extended support for RefreshToken for all of our iOS customers. This feature was previously only captured in our Managed SDK 2.1.0 and later versions to enable a smoother development experience around identity provider token expiry. For more information on this feature, see the Refreshing User Logins in App Service Mobile Apps blog post.
+
We added support for the latest iOS environments iOS 10. It also works with Xcode 8.1 and Swift 3.
+
We optimized network performance by reusing NSURLSession objects. This is particularly apparent in long-running async operations like data pulls. (Shout out to Damien Pontifex for his continuous support in helping to improve our iOS SDK through open source contributions).
+
+The latest Mobile Apps iOS Quickstart is also available and compatible with this release of the iOS SDK.
+
+Try these out and let us know what you think!
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
On October 10 we released the preview for Azure App Service companion to the Google Play Store and today we are expanding the preview to iOS devices as well.
+
+As with the Android version of the app the focus is to provide the basic functionality that you need when you are on the go, without requiring you to use your laptop. All in a native experience for your device.
+
+
+Azure App Service Companion allows you to:
+
+
Monitor your App Service instances
+
View custom alerts based on site status
+
Troubleshoot sites from anywhere
+
+
+
+
+
+
+
+
+
+
+If you have any questions about this app or App Service in general be sure to check our forums in MSDN and Stack Overflow. For any feature requests or ideas check out our User Voice
+
+In order to use the full capabilities of this application, you need to have an active Microsoft Azure subscription. To learn more about Azure subscriptions, see http://aka.ms/AzureSubscriptions.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Based on lots of great customer feedback, we've redesigned the Azure Functions portal experience. Now you can see more of your code and see your logs and the Run window at the same time. The Run window has new features for HTTP-triggered functions: you can now specify the HTTP verb and add query parameters and request headers. This makes it easy to test these functions without leaving the Functions portal.
+
+Aside from the visual improvements, we've released a lot of great new functionality in the Azure Functions 0.7 host and 0.8 host, including support for custom routes and route templates.
+
Portal
+You can now view the editor in a classic three-pane view, where your code is at the top, logs are at the bottom, and the Run tab is on the right. You can show and hide the logs and the Run tab to allow more room for editing code. Check out the new buttons on the right (highlighted with a purple rectangle in the screenshot below).
+
+
+
+Clicking on the Run button will pull up the test harness, which will let you easily craft HTTP calls without having to launch a new tool. Just choose your verb and add query parameters and headers. (Note that we're not trying to reinvent other great HTTP tools like Fiddler or Postman, but we've heard from customers that it's convenient to quickly run HTTP triggered functions without leaving the Azure portal.)
+
+
+
+HTTP and Webhook triggers now have richer options in the Integrate tab. You can now easily restrict the permitted HTTP verbs by choosing "Selected methods" and checking off the appropriate options.
+
+
+
API Routing
+The portal is not the only place we've made changes--the Azure Functions Host is now at version 0.8. By popular request, we've added the following:
+
+
Custom route support. You can now specify complex route constraints, such as "route": "products/{Category:alpha}/{Id:int}". The supported constraints are the same as those in ASP.NET Web API Attribute Routing.
+
Route prefix customization. Customize the api route prefix (or remove it completely) in host.json.
+Our development is done in the open, so we encourage you to watch issues, ask questions and see our progress. You can submit issues directly on GitHub (Functions Host repo and Functions Portal repo). If you're not sure where an issue belongs, you can file it on the Azure-Functions GitHub repo.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
One of the principles we believe in most for Azure Functions is that we want you to be solving business and application problems, not infrastructure problems. That’s why we’ve invested so much in the functions runtime (language abstractions, bindings to services, and lightweight programming model) as well as our dynamically scaling, serverless compute model. Given that goal, one thing has always stuck out in our experience: the memory setting you set for each of your Function Apps. The memory setting always felt out of place. Finding the optimal setting required lots of trial and error on the part of our users, and we’ve heard a lot of feedback from users that it’s not something which people want to; that it doesn’t feel very serverless. That is why today, we’re announcing that we’re no longer requiring you to set the memory setting; Azure Functions, in the Consumption Plan, will automatically decide the right resources to have available and only charge you for what you use, not just time but also memory/cpu.
+
How does Azure Functions manage my resources?
+The Azure Functions platform collects a lot of data about how much utilization and resources your functions take when they execute. This enables us to make very accurate estimations of what you’ll need and distribute the work behind the scenes. The first time you run your Function, we’ll place it in the best a place possible, and should it appear to need more resources, we’ll find and allocate them automatically. We’ll continually be improving our algorithms to make sure that you have the best experience and that we do it as cost effectively as possible on our side.
+
+We have confidence that we can do this effectively because we’ve been modeling it with real data for a while now. Below is a graph with the actual numbers redacted, but y-axis is in linear GB-sec, and the base is 0; the x-axis is time. The blue line, on top, is the current amount of billable GB-sec. The red line, on bottom, is the new amount of billable GB-sec in our system. This means, overall, our customers are now paying for 5 times less GB-sec than they were before. Today, users can confidently write Functions without worrying about the right memory setting, knowing they’ll pay the least for their functions.
+
+
+
Do I need to rethink how I write my functions?
+Overall, no, things work pretty much the same as before, with just one less setting to worry about. The same limits that applied before still apply: 1.5GB max memory and a 5-minute max execution time. The biggest impact that this change has is that you now are assured to be getting the right amount of resources and paying the least amount possible for your function executions.
+
How to think about serverless computing
+To help understand the impact of this change, let’s look at computing through an analogy. Imagine that compute works like shipping. Hosting your compute on prem is like buying a truck and paying the drivers yourself; you’re responsible for the hardware and the operational costs of operating that vehicle and the personnel. Infrastructure as a Service (IaaS - aka VMs) are like renting a truck, but still employing your own drivers; you’re no longer responsible for the hardware, but some operational costs (gas, maintenance, etc.) and the personnel costs still fall on you. Moving further up the hierarchy of compute, you can go with a fully managed Platform as a Service (such as Azure App Service) is like hiring a full-service company who will bring their truck and crew for you; you’re not responsible for the hardware or operational costs.
+But what if I want to just ship a bunch of small packages? Often it doesn’t make sense to pay by the truck, but rather by the package. This is where serverless computing stands to be transformative for how we build applications. We don’t have to focus on how shipping works because it’s not core to our business; we can focus instead on just getting the product to our customers. Each execution is like a package, and we pay for the size of the box.
+
+The change we’re making today, by removing set memory sizes, is made because compute while compute has similarities, it isn’t exactly like shipping physical objects. Knowing how much work is going to come in or what the right amount of compute (CPU/memory/IO) is not as simple as how tall and wide an object is; your resources required can change on each execution or even throughout an execution. Instead, we’ll now trigger your event and find the right size “package” for it, and only charge you for use, both time and resources.
+
The future is even brighter, together
+We’re committed to building the best serverless compute with the easiest experience and most powerful features. We want to know what we can make smoother. What questions do you have to ask yourself as you build functions? How can we make things easier, faster, better when you’re building your applications?
+
+Reach out to us in whatever way you prefer with issues, ideas, or questions:
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Cron is a time-based job scheduler and WordPress uses a file called wp-cron.php as a cron job to run scheduled tasks like publishing scheduled posts, managing updates to plugins and themes etc. WordPress is configured to wp-cron.php every time a user visits your WordPress web app to check if a scheduled task is to be executed.
+
+If your web app does get hundreds of users or more simultaneously , this adds significant overhead to your web app slowly it down for the users visiting it. For such cases it would be beneficial to isolate the wp-cron.php execution from the request made to your web app. Azure app service offers Web Jobs or Azure functions to build make a call to wp-cron.php file when it needs to be executed.
+
Advantages of Functions over Web Jobs for your WordPress app
+Few things to understand about your application before you make the choice :
+
+
If the cron job is CPU intensive and takes a long time to execute , it may put a large burden on your existing resources on the App service plan causing overhead. In such cases it would be more beneficial to use Azure Functions.
+
Cost is the second criteria . With Azure functions you get 400,000 GB-s execution time for Free which might be sufficient for WordPress app. Even if the execution is higher than 400,000 GB-s , the cost is 0.20 cents for million executions. Functions is still cost effective and it does not add overhead on your web app compute resources.
+
+For this blog post I will show you how to use Azure Functions so you can leverage server less architecture and low cost since you pay for the number of times the code is executed due to the event based model.
+
+You can use the same sample script for Web jobs if you intend to use the resources on your we app's app service plan. Click here to learn more about Web Jobs.
+
+Follow the steps below to isolate wp-cron.php execution for your WordPress web app.
+
STEP 1: Disable WordPress cron
+Update wp-config.php file and add this setting shown below to disable wp-cron.php from being executed at every user request.
+
define('DISABLE_WP_CRON', 'true');
+
STEP 2 : Create a Function App using Timer trigger
+Refer to instructions here to create a Function app or use this sample function app to run WordPress cron on Github . Azure function supports continuous deployment with Github .
+
+Traditionally wp-cron.php executes at every request to check if a task is scheduled to run. You can alternatively use the timer triggers which calls the azure functions based on a schedule, one time or recurring. For example if you want the wp-cron.php to run every 15 mins you can use the following schedule which is Unix Cron like expression.
+
"schedule": "0 */15 * * * *"
+To learn more about Timer trigger binding , click here.
+
+There are two primary files :
+
+
function.json: This file specified the bindings for the function app. In this case its a timer trigger as seen below which is scheduled to run every 15 minutes. You can view the json file here.
+
run.php : This script just make a HTTP call using PHP CURL and gets a response . Click here to view the script. The logs will display the information of function starting , completing and the response received from the CURL call to wp-cron.php. In this example with the sample function app return a message "Running WordPress CRON .."
+
+
Note: PHP support is still experiment for Azure Functions. You can use C# or Node.js or F# languages to make a HTTP call to the wordpress app wp-cron.php file , for example the URL would be like http://wordpress3295.azurewebsites.net/wp-cron.php?doing_wp_cron. This will trigger the cron to kickoff any scheduled tasks for WordPress app.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Today, we are releasing the Azure Mobile Apps SDK for Apache Cordova as a GA product. This completes the suite of mobile platforms that Azure Mobile Apps supports. You can read more about this release:
+
+
Universal Windows (.NET, Xamarin.Forms, Apache Cordova)
+
Windows Phone 8.1 (.NET, Xamarin.Forms, Apache Cordova)
+
+
+You can also integrate the same backend into your web and API applications using the Azure Mobile Apps HTML/JavaScript SDK or by integrating Azure Mobile Apps server-side SDKs into your ASP.NET MVC or Node/Express applications.
+
+All the SDKs support similar feature sets:
+
+
+
Data Access of SQL data with an OData v3 query structure.
+
Offline Sync of any SQL table exposed via data access.
+
Social authentication with client-side and server-side code to Facebook, Google, Microsoft and Twitter services.
+
Enterprise authentication using client-side and server-side code via Azure Active Directory.
+
Cross-platform push registration to APNS, FCM, WNS and MPNS using Notification Hubs.
+
+
+With this release, we are looking to the future. Some of the things we are looking at right now:
+
+
+
+As always, please feel free to leave us feedback. We listen on Azure Forums and Stack Overflow. Our SDKs are all open-source, so you can file issues for questions, feature requests and bugs.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Continuing the partnership between App Service and Visual Studio Team Services, we have a new preview experience for setting up a continuous delivery pipeline to automate the source control, build, test and deployment of your solutions to App Service.
+
+The new experience is accessible through the settings menu under App Deployment > Continuous Delivery (Preview)
+
+
+Some of the highlights features include:
+
+
Ability to host your code in GitHub or Visual Studio Team Services
+
Ability to create, deploy and execute load tests against an independent App Service plan.
+
Deployment directly to deploymetn slots following App Service deployment best practices.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
App Service provides you with many options for deploying your code to the cloud. The new Quickstart experience is designed to guide you through the steps to deploy your app using the deployment stack and deployment method of your choice.
+
+To get started go to Quickstart under the App Deployment section of the settings menu:
+
+Chose the development stack you are interested in:
+
+Select a deployment method:
+
+and follow the details instructions provided.
+
+You can start a different scenario by clicking on “Choose another stack”.
+
+If you have any questions about this feature or App Service in general be sure to check our forums in MSDN and Stack Overflow. For any feature requests or ideas check out our User Voice
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Update 5/31: We now have official documentation for the Azure Functions Core Tools and this blog post is now out of date. See Develop and debug Azure functions locally.
+
+After our General Availability release of Azure Functions on November 15, lots of customers have been asking how to develop Azure Functions on a local development machine, before pushing working code to Azure.
+
+I’m happy to announce that we have some great new functionality to share on this front. You can now use your favorite editor and local development tools and trigger from events in your Azure resources. You can use Visual Studio 2015, Visual Studio Code, or just a command line and any code editor.
+
Visual Studio 2015
+Customers who use Visual Studio should check out the preview Azure Functions Tools for Visual Studio 2015. This allows you to create local Functions projects, add new Functions from templates within Visual Studio, run functions locally, and debug C# functions. Get the tools and learn more on the Web Tools team blog.
+
+
+
VS Code and azure-functions-cli
+If you prefer VS Code or want to debug JavaScript functions, you can use the Azure Functions CLI. Note that currently the Azure Functions CLI only works on Windows, but we’re working on support for other platforms. (Note that C# debugging support is currently only available in Visual Studio, not VS Code.)
+
Installing
+Make sure you’re using Node version 6.x LTS or later (required by the Yeoman dependency), then do:
+
npm i -g azure-functions-cli
+The Azure Functions CLI is actually the Azure Functions “host” packaged with a command line interface and some other utilities. This is the exact same runtime that’s used in Azure, it’s not an emulator or simulator. It is distributed through npm because it uses Yeoman for scaffolding, but the core functionality is just a .NET 4.6 executable. (That’s why it currently only works on Windows.)
+
Creating a function project
+When running locally, a function project (the equivalent of a Function App in Azure) is just a directory with the files host.json and appsettings.json. See the product documentation for more about the Azure Functions folder structure.
+
+From a command prompt, do the following:
+
+Notice the file appsettings.json, which is where you set local environment variables and connection strings (more on this later).
+
Creating a simple function
+Now, let’s create a simple HTTP triggered Node function via func new
+
+
+I chose HttpTrigger-JavaScript and named it HttpTrigger-JS.
+
+
+
Running the function
+This HTTP triggered function is very simple, it just takes in a “name” argument as either a query parameter or JSON body content, and outputs “Hello name”. To edit the function code, let’s open up VS Code:
+
code .
+In Visual Studio Code, go to View -> Integrated Terminal
+
func run .\HttpTrigger-JS\ -c "{\"name\": \"Donna\"}"
+
+
+You’ll see that a separate window launches, which is the Functions host. By default, it will listen on http://localhost:7071.
+
+In the Functions host window, you’ll see that the URL of HTTP triggers is listed. You can then use a web debugging tool like Fiddler or Postman to create more complex requests.
+
+
+
Debugging the function in Visual Studio Code
+Running a function is great, but debugging is where the magic happens. To run the code and attach the JavaScript debugger, do the following:
+
+
In a command prompt (either the Integrated Terminal or a regular command prompt), run the function as before and add the --debug flag:
+
func run .\HttpTrigger-JS\ -c "{\"name\": \"Debugging!\"}" --debug
+
+
Add a breakpoint to index.js.
+
In the Debug tab, select F5 or the play button
+
In the terminal or command prompt, press any character and you’ll see your breakpoint being hit!
+
+
+
+
Running a queue-triggered function
+Now let’s create a function that triggers from a queue in Azure. First, run func new and select QueueTrigger-JavaScript. Name the function QueueTriggerJS.
+
+Setting a connection string
+Next, we need a value for a storage account connection string. You can either do this by editing appsettings.json manually or by using the Azure Functions CLI.
+
+To edit manually:
+
+
To go Azure Storage Explorer or the Azure Portal and copy your storage connection string
+Using the Azure Functions CLI:
+
+Log in to Azure, then set the active subscription. You can list your Function Apps in Azure and pull down connection strings for a particular app:
+
func azure login
+func azure account set
+func azure functionapp list
+func azure functionapp fetch
+
+You’ll see the following output. Settings will be encrypted by default and stored in appsettings.json.
+
+To view settings values on the command line, run:
+
func settings list -a
+If you want edit the file in an unencrypted form, run:
+
func settings decrypt
+Editing the Function configuration
+If you haven’t already, open the Functions directory in Visual Studio Code by running code .
+
+Now, edit QueueTriggerJS/function.json and set the value AzureWebJobsStorage for the value for connection. Your function.json will look like the following:
+
+Now it’s time to run the function. There are two ways to trigger it: add new items to a queue named js-queue-items or use the Functions CLI to trigger the function directly.
+
Triggering a function using “func run”
+To trigger directly, run the following in the Functions CLI:
+
func run .\QueueTriggerJS\ --debug -c "I love this CLI!"
+You’ll see the following output:
+
Executing: 'Functions.QueueTriggerJS' - Reason: 'This function was programmatically called via the host APIs.'
+Function started (Id=c2603348-a0c5-4d7a-b938-5d3e66ed35fd)
+JavaScript queue trigger function processed work item I love this CLI!
+Function completed (Success, Id=c2603348-a0c5-4d7a-b938-5d3e66ed35fd)
+Executed: 'Functions.QueueTriggerJS' (Succeeded)
+Note: if you this error, it means you haven’t set a value for AzureWebJobsStorage in appsettings.json: Microsoft.Azure.WebJobs.Host: Error indexing method 'Functions.QueueTriggerJS'. Microsoft.Azure.WebJobs.Host: Object reference not set to an instance of an object. Error indexing method 'Functions.QueueTriggerJS'.
+
+Now, let’s run and attach a debugger, the same as before:
+
func run .\QueueTriggerJS --debug -c "Foo"
+
Triggering a function with a queue message
+The cool thing about the local development experience is that you can trigger off of Azure resources directly, rather than just simulating via func run.
+
+By default, the Functions CLI will poll for new queue items every minute. For development purposes, it’s helpful to poll more frequently. Add the following to your host.json file, to poll every 2 seconds:
+
+Launch Azure Storage Explorer and create a queue js-queue-items in storage account you’ve specified in the AzureWebJobsStorage connection string:
+
+
+
+
+Then, in Visual Studio Code, we see out breakpoint being hit:
+
+
+This is just a taste of what you can accomplish with the Azure Functions CLI. Try it out today and let us know what you think!
+
Provide feedback
+The Azure Functions CLI is still in preview and under active development. If you find any issues, please post a GitHub issue and include the title “CLI:”. The CLI is open source and can be found in a branch of the azure-webjobs-script repo. You can also reach out to me on Twitter @lindydonna.
+
+For general feedback and questions about Azure Functions:
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Imagine programprovides special Azure access rights to students that are validated through the Microsoft Imagine program. If you are not enrolled , please enroll here.
+
+Azure subscriptions enrolled in this program previously had access to a Free MySQL Database from ClearDB. Moving forward ClearDB FreeDatabase will no longer be supported as part of Imagine program. You can still leverage MySQL from MySQL in-app(Preview) feature.
+
+What Imagine offer students get with MySQL in-app(Preview):
+
+
MySQL in-app gives you an experience of native MySQL running locally alongside the web server.
+
One database for One web app . It is not restricted on App service plan.
+
Storage of 1 GB shared by the your web app's files and database content
+
RAM of 1 GB
+
Phpmyadmin access to manage your database from Azure portal
+
Supports logging for MySQL server logs and Slow query logs. Note these are turned off by default.
+
+Here is a FAQ to help answer common question due to this change in service for Imagine program.
+
+1.Can I continue to use, my existing ClearDB Free MySQL database?
+
+Yes. You can continue to use your existing ClearDB Free MySQL database.
+
+2. Can I create a new ClearDB MySQL database on my Imgaine program subscription?
+
+No you cannot create a new Free ClearDB MySQL database on your Imagine program subscription. You can purchase a new Azure subscription such as Pay-as-you-go etc. to be able to create ClearDB MySQL database
+
+3. How can I export my ClearDB database to MySQL in-app(Preview) database?
+
+Check out this article to learn how to export the database and import it in MySQL in-app(Preview) database.
+
+4. How can I access phpmyadmin for MySQL in-app(Preview) database ?
+
+In the Azure portal , under your web app settings menu you have an option to manage your MySQL in-app(Preview) settings. To learn more , click here.
+
+5. What applications can I install with MySQL from Azure Web Marketplace?
+
+The following application will be available for Imagine program :
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Today, in our final Azure Mobile Apps release of the year, we are releasing a new version of the server-side Azure Mobile Apps Node.js SDK. It's labelled v4.0 because of important breaking changes, but does not introduce any new features.
+
+
Breaking Changes
+
+If dynamic schema was enabled, inserting an item with new columns would also create a deleted column which was unnecessary if the soft delete option was turned off for the table. With v4.0, the deleted column is not created when it is unnecessary. This may affect automated clean-up scripts that don't take into account the soft delete setting on the table. (Issue #504)
+
+If an update or delete was performed against soft-deleted records, the server would return a 409 HTTP status code. This was in contrast with the ASP.NET server that returned a 404 HTTP status code. The Node.js SDK has been updated to return a 404 HTTP static code. (Issue #497)
+
+Finally, our documentation was out of line with our code with respect to paging options. Previously, the server would place a hard limit on the number of records returned (the pageSize option), despite the maxTop option being higher. The pageSize option now only affects the number of records returned if a $top expression is not provided, and the maximum number of records returned is correctly determined by the maxTop option. (Issue #480)
+
+
Other Fixes
+
+An issue existed whereby a custom API whose access level was set to 'authenticated' would allow unauthenticated requests. This only affected apps where the access level was applied to the entire API and not individual methods within the API and who were also using a custom authentication scheme. Using the App Service Authentication / Authorization mitigated this issue. With the v4.0 release, this issue has been corrected. (Issue #514)
+
+
User Impact
+
+Any user who is using the server via an Azure Mobile Apps client SDK should not be impacted by any of these changes. If you use the server directly through the OData interface, then you should review the changes carefully before upgrading.
+
+As always, our team is ready to assist should you have questions. Please contact us through Azure Forums or Stack Overflow.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Azure App Service has a facility called "Authentication / Authorization" and it assists primarily with the authentication requirements of Azure Mobile Apps. However, you can also use this in your web applications to abstract away the authentication needs. This makes it easy to integrate Facebook, Google, Microsoft Account, Twitter and Azure AD authentication schemes. This blog post will go through the process of configuring an ASP.NET MVC application to use Azure App Service Authentication.
+
+
Step 1: Configure Azure App Service Authentication / Authorization
+
+You can follow our documentation to configure the actual service:
+
+
+
+Once you have followed the documentation, you should be able to browse to https://yoursite.azurewebsites.net/.auth/login/provider (where provider is one of aad, facebook, google, microsoftaccount or twitter) to ensure it is working.
+
+
Add Azure Mobile Apps to your ASP.NET MVC application
+
+The Azure Mobile Apps .NET Server SDK does a lot of the hard work in handling claims. To configure authentication, first add the Microsoft.Azure.Mobile.Server.Quickstart NuGet package. Then add or create a Startup.cs file with the following:
+
+
+
+Some parts of this will already be available to you. Make sure the loginUrl in the authentication section matches the provider login URL for the provider that you configured.
+
+You should now be able to attach the [Authorize] attribute to any controller to enable the redirect to the authentication system. The authentication will happen and then the user will be prompted to "return to the website". Once the link is clicked, the user will be redirected back to your application with authentication. Your application can use any of the claims available through the /.auth/me endpoint of your application. They are available in the httpContext.User.Identity.Claims object.
+
+
Dealing with Anti-Forgery Tokens
+
+One thing that will break is anti-forgery tokens. This is because Azure App Service Authentication does not provide the appropriate identityprovider claim that anti-forgery tokens use for configuration. You have to explicitly set a claim to use. This can be done anywhere in the application start. I place mine in the MVC RegisterRoutes() method in App_Start\RouteConfig.cs. Add the following line:
+
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 9 minute read
+
+
+
+ • By Steve Dower
+
+ • August 4, 2016
+
+
+
App Service is Microsoft Azure’s platform-as-a-service offering for web apps, whether they are sites accessed through a browser, REST APIs used by your own c...
With Azure Functions recently becoming generally available and making the 1.0 Azure Functions host available, we are now announcing that preview versions of the Azure Functions host (0.x) are deprecated and we're preparing to begin removal of these versions beginning February 1st, 2017. All Azure Functions users should upgrade their version setting to ~1. If you are using preview features, such as PowerShell or F# support, there are additional things to consider around how we will manage versions in 1.x versions.
+
Deprecation of preview (0.x) versions of Azure Functions host
+
All preview (0.x) versions of the Azure Functions host are now deprecated. We will be begin removing those versions from the available feed of versions starting February 1st, 2017. Since we've released 1.0, we've been monitoring which versions users are actively using and are happy with the adoption rate of our latest version. We will start by removing the earliest versions, which have the fewest users still active. If you still haven't upgraded to ~1, we strongly recommend that you upgrade as soon as possible.
+
Any non-security related issues related to these versions, including the runtime, portal, templates, or docs, will generally be closed. Support cases for users still using preview versions of the host will be directed to first upgrade to the latest version of the host. We encourage you to ask any questions you might have about any issues you experience while upgrading, either via Azure Support or via the forums and Stack Overflow. If you have any critical need to keep a preview version around past February 1st, 2017, please reach out to chrande@microsoft.com.
+
Versioning for preview features in 1.x
+
Previously, before 1.0, we would introduce breaking changes every minor version. Now that we've introduced 1.0, all "released" features, such as JavaScript and C# language support, will not have any breaking changes for all ~1 versions. If you don't plan on using preview features, you don't need to worry about any version updates until we have another major version update. Preview features, such as PowerShell and F# language support, will continue to potentially incur breaking changes between minor versions. We recommend that if you're using preview features, you continue to set your minor version explicitly (i.e. ~1.0), rather than just the major version(~1).
+
Additionally, we will not be supporting every 1.x version for the lifetime of 1.x. We will deprecate some ~1 minor versions over time. Later this month, we will provide a tentative schedule for how that will work, as well as some additional means for folks using preview features to provide us feedback. We'll also be building some special portal experiences which will make version management even easier for those of you using preview features.
+
We also really want to thank each and every one of you who gave us a try during our preview and those of you who will continue to use preview features now that we've released 1.0. It means a lot to us and we wouldn't be successful without it. We hope you have as much fun using our preview features as we do making them.
+
FAQ
+
When will version "0.x" (0.5, 0.6, etc.) be removed?
+
It will be removed sometime after February 1st, 2017.
+
What if the preview version I'm using is removed before I perform the upgrade?
+
Azure Functions will use a newer version automatically. If your Functions are impacted by any breaking changes between host versions, you may experience issues, including downtime that does not count against your SLA, since it is user controlled.
+
How do I know if I need to upgrade?
+
If your FUNCTIONS_EXTENSION_VERSION application setting is set not set to a ~1 version (i.e. it is set to 0.9), you need to upgrade. Our portal will provide warning on the top of the screen if it detects you're behind the latest version.
+
How do I upgrade?
+
The easiest way to upgrade is to open the Azure Functions portal and click on the upgrade notice. You can also go to your Function App Settings menu and click on the upgrade version next to where it displays your current version. You can also directly set your Application Setting via the portal, any Azure CLI, or the Azure Resource Management APIs.
+
If I'm using ~1 today, do I need to worry?
+
As long as you're not using any preview features (like PowerShell or F# language support), you can rest easy. If you're using preview features, you'll want to manage your minor versions directly. Keep an eye out for some more information on this early next year.
+
What's the difference between ~1 and ~1.0 for the FUNCTIONS_EXTENSION_VERSION application setting?
+
When we resolve which Functions host to start up for you, we use the FUNCTIONS_EXTENSION_VERSION application setting to choose the best version for you. If you set your setting to ~1, you'll use the latest version of the host with major version of 1. If you set your setting to ~1.0, you'll only receive patch updates to 1.1. We'll update the minor version every time we have a new version of the host which has breaking changes for preview features.
+
If I desperately need to stay on a preview version, is there an option for me?
+
We believe that upgrading to ~1 is the best thing for everyone, but we can work with you to help you upgrade, if you reach out to us. If you're committed to staying on a preview version, we don't offer any official support for this, but you can deploy your own functions extension on App Service plans (not supported on Consumption plans).
+
Is there a way for me to know if I'll be impacted by a change?
+
The best way to get an idea of the impact is to read the release notes for any versions between your current version and the targeted upgrade version.
+
How do I revert to another version (just in case)?
+
In your app settings in the Functions portal, you'll find a setting for the runtime FUNCTIONS_EXTENSION_VERSION. You can change this to any version, including a previous version. You can learn more about this here.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Today, we are releasing two new .NET SDK releases - v2.0.0 on the server side and v3.1.0 on the client side. The NuGet packages are available from the main NuGet repository and the symbols have been updated on symbolsource.
+
+
Azure Mobile Apps ASP.NET Server SDK v2.0.0
+
+It's been a while since we updated the ASP.NET Server SDK. We've updated the base framework that we use to .NET Framework 4.6 and updated all the dependencies so that we are using the latest versions that we can while maintaining compatibility as a protocol level. In addition, we have deprecated the Azure Notification Hubs push registration endpoint. This is still included in the package, but marked as Obsolete and will be removed in a future version. You should use the App Service Push endpoint instead. In your ASP.NET Owin Startup class, you can remove the reference to .AddPushNotifications() from the configuration.
+
+App Service Push has been significantly enhanced over the last couple of months. It now supports white-listing of tags and automatic addition of tags based on authenticated claims available from the authentication provider. This lays the groundwork for re-introducing tag support into the client SDKs in a future release. In the interim, you can build your own Notification Hub Installation class and submit that via the .InvokeApiAsync() method. For examples on this, check out Chapter 5 of my Azure Mobile Apps book.
+
+We are also releasing the Swagger and Custom Authentication packages as generally available. You can read about the Swagger customization on our Wiki. Finally, we've also been working behind the scenes on updating the Azure Storage SDK, updating our testing and build processes so that those are more aptly done in the public, publishing more topics to our Wiki and adding information to our documentation.
+
+
Azure Mobile Apps Client SDK v3.1.0
+
+The Client SDK has had the following updates since the last update:
+
+
+
(#266) A bug that caused problems when two libraries both used SQLite. This was fixed by updating the dependency on the SQLitePCL.raw to the latest version. Thanks to Eric Sink for the fast turnaround on the fix for this, and for providing an awesome open source project that we can leverage here.
+
(#215) We were inconsistent in the generation of GUID style primary keys between the client and server. We've standardized the production of keys to a hyphen-less version.
+
(#196) We had a method for querying the underlying SQLite store that was not exposed. Sometimes, it's good to do queries against the raw tables stored in SQLite. We now expose the SQLiteStore.ExecuteQueryAsync() method that does the appropriate locking to ensure the operation is safe.
+
+
+We've also done numerous documentation updates and will be updating the SDK documentation on the MSDN site soon.
+
+As always, you can ask questions on both of these SDKs on Stack Overflow or Azure Forums, or file questions and issues at the GitHub repositories (Server and Client).
+
+
Read the Book
+
+On the "more documentation" front, I've been hard at work writing the Azure Mobile Apps book for C#, covering the ASP.NET server and Xamarin cross-platform development. It is nearing completion and all the "development" topics have been completed. You can find the book at http://aka.ms/zumobook. I would appreciate your feedback on the topics, especially where information is missing. You can file issues at the GitHub repository.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
We are excited to share some of the recent updates the Notification Hubs team has made to its Java Server SDK.
+
+
We have added a cancelScheduledNotification API that lets you delete scheduled notifications provided the scheduled notification ID.
+
We have added sendDirectNotification that can directly push any type of notifications (APNS, GCM, WNS, etc) to a list of device tokens without any device registrations needed with Notification Hubs service.
+
Lastly, getNotificationTelemetry is enabled for customers to easily see telemetry details around each send request.
+
+You will need the following dependencies with the correct versions:
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
The open-source Parse Server project has moved on since we first published the Marketplace resource for running your own version of Parse Server on Azure App Service. The Azure version of Parse Server uses all Azure resources - DocumentDb, Storage, Notification Hubs and App Service. Recently, Parse Server got updated to v2.3.0.
+
+If you wish to deploy a new Parse Server and use the new v2.3.0 codebase, then you can simply deploy the Marketplace resource. In the Azure Portal, click on the + NEW resource. Use the search box to search for Parse Server and create the Parse Server on managed Azure services resource. All the relevant resources will be created for you. This allows you to get up and running quickly.
+
+If you have an existing Parse Server running with managed Azure services, you will need to upgrade your server rather than deploy a new server. To do this:
+
+
+
Click Resource Groups and find the resource group containing your parse server resources.
+
Click the App Service that has the same name as your parse server.
+
+This will install the latest 2.3.x release of parse-server (currently 2.3.2).
+
+If you notice any red text in the console, then an error has occurred. You should analyze the error message. Please report any problems through Azure Forums or Stack Overflow.
+
+Upgrading your Parse Server is identical to upgrading any other server code - try it on a non-production service first and ensure all your client-server communications still work properly. Things change between Parse Server versions. You should reach out to the Parse Server project directly if you are experiencing problems in your code.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Affected Product: Azure Preview API Apps (v1)
+Deprecation Date: January 18th, 2017
+Removal Date: March 14th, 2017
+Mitigation: Redeploy workload to App Service API Apps (v2)
+
+Today we are announcing the deprecation of Preview API Apps, referred to as v1 API Apps for this article. v1 API Apps are deprecated immediately and will be removed from Azure on March 14th. App Service API Apps, referred to as v2 API Apps for this article, are a GA product and still under active development. Redeploy all v1 API App workloads to v2 API Apps by March 14th to avoid a service interruption.
+
+We are excited at the growth we have seen since upgrading v1 API Apps to the App Service infrastructure and announcing general availability of v2 API Apps over a year and a half ago. Read the original announcement for all the improvements introduced in v2 API Apps.
+
+Logic App Impact
+Logic Apps had moved away from using the preview API Apps v1 based connectors almost 1 year ago and has since become generally available with over 100 managed connectors.
+
+Please migrate your preview Logic Apps to our GA schema and discontinue use of the preview API APP v1 based connectors, as those connectors will be removed on March 14th, 2017.
+
+API Gateway
+API Gateway resources are also deprecated and will also be removed following the API App removal timeline. API Gateway resources are created in each resource group that contains a v1 API App and have the resource type "Gateway" in the portal.
+
+Identifying Preview API Apps (v1)
+v1 API Apps are only visible in the "All Resources" page of the Azure Portal, and on the page of the resource group they belong to. They are not visible in the "App Services" page of the Azure Portal by design.
+v1 API Apps have the App Type "API App" and the Resource Type "Microsoft.AppService/apiapps" in the Azure portal
+
+
+Opening the App settings blade on a v1 API App will show an upgrade notice as well.
+
+Identifying App Service API Apps (v2)
+v2 API Apps have the App Type "App Service" and the Resource Type "Microsoft.Web/sites" in the Azure portal, and are still under active support and development.
+
+Upgrading Preview API Apps (v1)
+Follow this guide to redeploy your v1 API App workload to a v2 API App.
+
+Upgrading Logic Apps v1 Connectors
+Use the GA release of Logic Apps with equivalent managed connectors in place of the v1 preview Connectors.
+
+To check that you are no longer consuming a v1 connector, stop all of your v1 API Apps from the portal and check that your logic apps run successfully.
+
+All v1 connectors will be classified as preview API Apps in the portal, shown above.
+
+Preview (v1) API App Not Accessible in Portal
+The portal experience for some v1 API Apps and connectors may be unavailable. We recommend you use Azure Resource Explorer or the Azure Resource Manager REST APIs directly to manage these v1 API Apps.
+
+In the Azure Resource Explorer navigate to your subscription, then your resource group. Note that your v1 sites will have both a core site, under Microsoft.AppService, as well as a container site under Microsoft.Web > Sites. The core site contains your business logic, and the container contains your Azure configuration, such as deployment slots and networking settings.
+
+Deprecation Timeline
+March 14th: v1 API Apps stop running on Azure
+March 28th: v1 API App data deleted from Azure
+
+Additional Support
+If you have any issues moving to v2 API Apps please check our MSDN forums, or contact support directly
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Today we are releasing the Azure Mobile Apps iOS SDK to CocoaPods and other online properties. This is a drop-in replacement for the existing SDK. We only have one feature fix in this release. We updated the authentication code to support the SFSafariViewController.
+
+This release affects you if you use Google Authentication and a server-flow. If your code looks like this (Objective-C):
+
+
+
+Then you are affected by this change. Late last year, Google made changes to their OAuth authentication scheme. The net effect was that a mobile client could no longer use a WebView to deliver the authentication flow to the user. A secure web flow would be needed. The supported method on iOS is the SFSafariViewController and this release changes the underlying web view capabilities for authentication to this new mechanism. This wasn't just a client-side code change. It involved changing the server-side authentication code worldwide in Azure App Service.
+
+As with any release, we have done numerous small changes to make the experience for the developer better, particularly as it pertains to warnings that are delivered during the development process. We are also in the process of moving all our examples to Swift 3.0. The new SDK fully supports Swift 3.0 and XCode 8.2. We will be deprecating the support for Swift 2.x in the next release. Although we support XCode 7.0 for Objective-C usage, you will need XCode 8.2 for Swift support.
+
+You can download the SDK from Cocoapods, take a look at the API directly or reference our tutorials and HOWTO documentation. We're also active on Azure Forums and Stack Overflow.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Windows Azure Pack Web Sites V2 is an on-premises, high density, multi-tenant web hosting for service providers and enterprise IT and provides an experience similar to the predecessor to Azure App Service, Azure Web Sites. The product is deployed on top of Windows Server 2012 R2 and is an optional add-on to Windows Azure Pack.
+
+With the release of Windows Server 2016, the Windows Azure Pack team amended the support lifecycle to reflect that Windows Azure Pack V2 from Update Rollup 11 is supported on Windows Server 2016, however this is not the case for Windows Azure Pack Web Sites. Windows Azure Pack Web Sites is only supported on Windows Server 2012 R2 and is subject to the same support lifecycle dates that were previously published for Windows Azure Pack running on Windows Server 2012 R2. We understand this is causing some confusion and concern amongst customers so this blog post is intended to clarify the position for users of Windows Azure Pack Web Sites.
+
Windows Azure Pack Web Sites v2 Mainstream support ends on 11th July 2017
+Windows Azure Pack Web Sites has a direct dependency on Windows Server 2012 R2 and as such will adhere to the following support lifecycle dates:
+
+
+
+
Lifecycle Start date
+
14th January 2014
+
+
+
Mainstream Support End Date
+
11th July 2017
+
+
+
Extended Support End Date
+
12th July 2022
+
+
+
+Guidance on what is covered under Extended Support can be found at https://support.microsoft.com/en-us/help/17140/general-lifecycle-policy-questions
+But Windows Azure Pack can be deployed on Windows Server 2016, what about Web Sites?
+
+Windows Azure Pack Web Sites does not support deployment on top of Windows Server 2016. Windows Azure Pack can be deployed on Windows Server 2012 R2 and with Update Rollup 11 can be deployed on Windows Server 2016 but Windows Azure Pack Web Sites is ONLY supported on Windows Server 2012 R2.
+What about Updates?
+
+Update Rollups for Windows Azure Pack Web Sites will continue to be published until July 2017, after that date no regular updates will be published.
+
+Questions?
+
+If you have any questions or feedback around this clarification and Windows Azure Pack Web Sites please add them to the comments on this post and I will respond.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
We are conducting an assessment on ClearDB MySQL databases associated with Azure customers. We have found several instances where subscriptions are deployed in ClearDB but have no corresponding Azure account associated with them.
+
+To synchronize the ClearDB and Azure services, any MySQL database that does not have a valid Azure account will be frozen on January 25. This may impact some Azure users.
+
+If your account is frozen and you wish to sustain the ClearDB MySQL database services from Azure, please take the following steps:
+
+
Provision a new, empty ClearDB database in Azure to restore your data into.
The database name that was newly created with Azure subscription ID
+
Old database name , ClearDB database hostname and the associated Azure subscription ID
+
Our support teams will work will provide you a back up of your database. Please import the database content using MySQL workbench into the newly created database .
+
+
+
+The reason behind these steps being taken is due to inconsistency in purchase order records for these databases and their subscriptions. The steps above will help resolve this. We apologize for any inconvenience you have incurred.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
We have just released an update for our App Service Companion app for iOS
+
Some of the key new features include:
+
+
Ability to “favorite” apps for quick access
+
New grouping option in the app list to quickly navigate through large app collections.
+
Support for Push notifications for recomendations
+
New native UI built specially for iOS
+
+
If you have already installed App Service Companion you should soon see the update from the App Store or you can click on the banners below to install it now for your respective platform
The application list lets you view all apps or a filtered view of just your favorites.
+
You can add or remove items to the favorite list by swiping left in the application list or from the app actions menu.
+
You can now group applications in the app list by:
+
+
Subscription
+
Resource Group
+
Region
+
App type
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
App actions and Metrics
+
Application actions are grouped under the action menu, application actions include:
+
+
Start
+
Stop
+
Restart
+
Browse
+
Favorite
+
+
Metrics graphs under the app’s monitoring view now let you select different time grains to get a better view of your app’s activity
+
+
1 hour
+
1 day
+
1 week
+
+
+
+
+
+
+
+
+
+
+
If you have any questions about this app or App Service in general be sure to check our forums in MSDN and Stack Overflow. For any feature requests or ideas check out our User Voice
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Since we first released Azure Functions, we've seen a lot of customers using the service to build APIs. Functions is a fantastic way to quickly express an action, and the consumption plan is a great billing model for many types of applications.
+
+However, we've also heard that dealing with multiple functions could be easier. It's often difficult to manage large solutions within a single function app. There are also quite a few customers that want to use microservices architectures, with deployment isolation between individual components. Splitting the work into multiple function apps works for most triggers, but it's a bit trickier for APIs. Each function app has its own hostname, so there can be many hosts to keep track of, without a unified API surface. This can make things difficult for client applications, especially when the client needs to switch between environments for testing.
+
+Today, we are pleased to announce the public preview of Azure Functions Proxies, a new capability that makes it easier to develop APIs using Azure Functions. Proxies lets you define a single API surface for multiple function apps. Any function app can now define an endpoint that serves as a reverse proxy to another API, be that another function app, an API app, or anything else.
+
+You can learn more about Azure Functions Proxies by going to our documentation page. The feature is free while in preview, but standard Functions billing applies to proxy executions. See the Azure Functions pricing page for more information.
+
Creating your first proxy
+To create a proxy, head to any function app. In the left-hand navigation, you should now see a Proxies section. Select "New proxy" to get started. You will need to provide a name for the proxy, the endpoint you wish to expose, and the backend endpoint that will serve the request.
+
+
+
+Proxies exist as peers to functions in a function app. They are configured just like HTTP-triggered functions, and from a client perspective, they look the same. However, the proxy behavior is independently enabled and versioned. If this is the first proxy you've created for a function app, you will need to enable the feature in function app settings.
+
Getting in touch with the team
+Please give Azure Functions Proxies a try and let us know what you think! We have some additional capabilities planned for this scenario, but as always, we'd love to hear what matters most to you.
+
+If you run into any problems, let us know on the forums, ask a question on StackOverFlow, or file an issue on GitHub. If you have any additional features you would like to see, please let us know on Uservoice.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Today we’ve officially announced preview support for the Azure Functions Serverless Framework plugin. The Serverless Framework is an open source tool which allows you to deploy auto-scaling, pay-per-execution, event-driven functions to any cloud. It helps abstract away the details of your Serverless resources and lets you focus on the important part – your application. With the release of our new plugin, it’s one of the fastest ways to deploy a serverless application, ever.
+
+You can learn more about the plugin in the Azure Functions Serverless Framework documentation.
+
+You can also check out our npm package serverless-azure-functions.
+
Getting started
+Now let’s see a quick hello world example
+
1. Set up boilerplate
+To setup the boilerplate, follow these instructions:
+
+
Recommend using Node v6.5.0
+
Install the serverless tooling - npm i -g serverless
+We'll set up an Azure Subscription and our service principal. You can learn more in the credentials doc.
+
+
Set up an Azure SubscriptionSign up for a free account @ https://azure.com.
+
+Azure comes with a free trial that includes $200 of free credit.
+
+
+
. Get the Azure CLI
+
npm i -g azure-cli
+
+
+
Login to Azure
+
azure login
+
+This will give you a code and prompt you to visit aka.ms/devicelogin. Provide the code and then login with your Azure identity (this may happen automatically if you're already logged in). You'll then be able to access your account via the CLI.
+
Get your subcription and tenant id
+
azure account show
+
+Save the subcription and tenant id for later
+
Create a service principal for a given <name> and <password> and add contributor role.
+
azure ad sp create -n <name> -p <password>
+
+This should return an object which has the servicePrincipalNames property on it and an ObjectId. Save the Object Id and one of the names in the array and the password you provided for later. If you need to look up your service principal later, you can use azure ad sp -c <name> where <name> is the name provided originally. Note that the <name> you provided is not the name you'll provide later, it is a name in the servicePrincipalNames array.
+
+Then grant the SP contributor access with the ObjectId
+
azure role assignment create --objectId <objectIDFromCreateStep> -o Contributor
+
+
+
Set up environment variablesYou need to set up environment variables for your subscription id, tenant id, service principal name, and password.
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Azure App Service and Azure Functions are both commonly used for building organizational APIs. These might include important business logic needed by many apps and activities. Traditionally, most of these clients are written by professional developers, but Microsoft also offers solutions that enable anyone in an organization to build solutions.
+
+PowerApps and Microsoft Flow are services that enable power users within an organization to get more done. Without writing any code, users can easily create apps and custom automated workflows that interact with a variety of enterprise data and services. While they can leverage a wide variety of built-in SaaS integrations, users often find the need to incorporate company-specific business logic.
+
+We've now extended the API Definition feature of App Service and Azure Functions to include an "Export to PowerApps and Microsoft Flow" gesture. This walks you through all the steps needed to make any API in App Service or Azure Functions available to PowerApps and Microsoft Flow users. To learn more, see our documentation.
+
+We're hoping to make this experience even easier over time. Please let us know what you think in the Forums (App Service, Functions) or UserVoice (App Service, Functions).
+
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+Last year, we introduced ‘App Service Certificate’, a certificate lifecycle management offering. Azure portal provides a user-friendly experience for creating App Service Certificates and using them with App Service Apps. You can read more about this service here. While the portal provides first class experience for deploying App Service Certificate through Key Vault to App Service Apps, we have been receiving customer requests where they would like to use these certificates outside of App Service platform, say with Azure Virtual Machines. In this blogpost, I am going to describe how to create a local PFX copy of App Service Certificate so that you can use it anywhere you want.
+
Prerequisites
+Before making a local copy, make sure that:
+1. The App Service Certificate is in ‘Issued’ state
+2. It’s assigned to a Key Vault (Step 1 in the link shared above).
+
Creating a local copy of the issued SSL certificate using PowerShell
+You can use the following PowerShell script to create a local PFX copy.
+
+You need to first install Azure PowerShell and have the required modules installed. Follow this blog to install the Azure PowerShell commandlets.
+
+To use the script, open a PowerShell window, copy the entire script below (uncomment Remove-AzKeyVaultAccessPolicy line if you want to remove Access policies after export, check your permissions to see if you want to remove the policy) and paste it on the PowerShell window and hit enter.
+
+ Function Export-AppServiceCertificate
+ {
+ ###########################################################
+
+ Param(
+ [Parameter(Mandatory=$true,Position=1,HelpMessage="ARM Login Url")]
+ [string]$loginId,
+
+ [Parameter(Mandatory=$true,HelpMessage="Subscription Id")]
+ [string]$subscriptionId,
+
+ [Parameter(Mandatory=$true,HelpMessage="Resource Group Name")]
+ [string]$resourceGroupName,
+
+ [Parameter(Mandatory=$true,HelpMessage="Name of the App Service Certificate Resource")]
+ [string]$name
+ )
+
+ ###########################################################
+
+ Connect-AzAccount
+ Set-AzContext -Subscription $subscriptionId
+
+ ## Get the KeyVault Resource Url and KeyVault Secret Name were the certificate is stored
+ $ascResource= Get-AzResource -ResourceId "/subscriptions/$subscriptionId/resourceGroups/$resourceGroupName/providers/Microsoft.CertificateRegistration/certificateOrders/$name"
+ $certProps = Get-Member -InputObject $ascResource.Properties.certificates[0] -MemberType NoteProperty
+ $certificateName = $certProps[0].Name
+ $keyVaultId = $ascResource.Properties.certificates[0].$certificateName.KeyVaultId
+ $keyVaultSecretName = $ascResource.Properties.certificates[0].$certificateName.KeyVaultSecretName
+
+ ## Split the resource URL of KeyVault and get KeyVaultName and KeyVaultResourceGroupName
+ $keyVaultIdParts = $keyVaultId.Split("/")
+ $keyVaultName = $keyVaultIdParts[$keyVaultIdParts.Length - 1]
+ $keyVaultResourceGroupName = $keyVaultIdParts[$keyVaultIdParts.Length - 5]
+
+ ## --- !! NOTE !! ----
+ ## Only users who can set the access policy and has the the right RBAC permissions can set the access policy on KeyVault, if the command fails contact the owner of the KeyVault
+ Set-AzKeyVaultAccessPolicy -ResourceGroupName $keyVaultResourceGroupName -VaultName $keyVaultName -UserPrincipalName $loginId -PermissionsToSecrets get
+ Write-Host "Get Secret Access to account $loginId has been granted from the KeyVault, please check and remove the policy after exporting the certificate"
+
+ ## Getting the secret from the KeyVault
+ $secret = Get-AzKeyVaultSecret -VaultName $keyVaultName -Name $keyVaultSecretName -AsPlainText
+ $pfxCertObject= New-Object System.Security.Cryptography.X509Certificates.X509Certificate2 -ArgumentList @([Convert]::FromBase64String($secret),"",[System.Security.Cryptography.X509Certificates.X509KeyStorageFlags]::Exportable)
+ $pfxPassword = -join ((65..90) + (97..122) + (48..57) | Get-Random -Count 50 | % {[char]$_})
+ $currentDirectory = (Get-Location -PSProvider FileSystem).ProviderPath
+ [Environment]::CurrentDirectory = (Get-Location -PSProvider FileSystem).ProviderPath
+ [io.file]::WriteAllBytes(".\appservicecertificate.pfx",$pfxCertObject.Export([System.Security.Cryptography.X509Certificates.X509ContentType]::Pkcs12,$pfxPassword))
+
+ ## --- !! NOTE !! ----
+ ## Remove the Access Policy required for exporting the certificate once you have exported the certificate to prevent giving the account prolonged access to the KeyVault
+ ## The account will be completely removed from KeyVault access policy and will prevent to account from accessing any keys/secrets/certificates on the KeyVault,
+ ## Run the following command if you are sure that the account is not used for any other access on the KeyVault or login to the portal and change the access policy accordingly.
+ # Remove-AzKeyVaultAccessPolicy -ResourceGroupName $keyVaultResourceGroupName -VaultName $keyVaultName -UserPrincipalName $loginId
+ # Write-Host "Access to account $loginId has been removed from the KeyVault"
+
+ # Print the password for the exported certificate
+ Write-Host "Created an App Service Certificate copy at: $currentDirectory\appservicecertificate.pfx"
+ Write-Warning "For security reasons, do not store the PFX password. Use it directly from the console as required."
+ Write-Host "PFX password: $pfxPassword"
+
+ }
+
+Now you will have a new command called Export-AppServiceCertificate, use the command as follows
+
+Once the command is executed, you would see a new file in the current directory called ‘appservicecertificate.pfx’. This is a password protected PFX, the PowerShell console would display the corresponding password. For security reasons, do not store this password in a text file. You can use the password directly from the console as required. Also, don’t forget to delete the local PFX file once you no longer need it.
+
Exporting the certificate with the chain included for App Service Web App consumption.
+The pfx created by the above commands will not include certificates from the chain. Services like Azure App Services expect the certificates that are being uploaded to have all the certificates in the chain included as part of the pfx file.
+
+To get the certificates of the chain to be part of the pfx, you will need to install the exported certificate on your machine first using the password that is provided by the script, make sure you mark the certificate as exportable.
+
+
+
+Once you have installed the exported certificate open the certificate from your certificate store and navigate to the Certification Path tab, it would look something like below,
+
+
+
+Now go to https://certs.godaddy.com/repository and download the intermediate certificates and the root certificate. Install all of the certificates downloaded to the same store as your certificate. Once you confirmed that all the certificates in the chain have been installed we can export the certificate with the chain by going to the certificate store, right clicking on the SSL certificate we exported and installed and clicking of All Tasks -> Export ...
+
+In the wizard, make sure you select the option, "Yes, export the private key"
+
+And then under the Personal Information Exchange property, make sure the option "Include all certificates in the certification path if possible" is checked.
+
+
+
+Once exported into a new pfx file we can check if the new pfx has the certificate chain included in it by running the command,
+
certutil -dump <path of the certificate file>
+You will see the list of the certificates that are part of the pfx from the root to your certificate. A pfx file created with the above steps with all the certificates of the chain contained is well formed and can be uploaded to App Service Web Apps with confidence. Note the CA part of the uploaded pfx file will be discarded when we process the uploaded certificate, we store all the intermediate certificates associated with the certificate to enable the chain to be remade properly in the runtime.
+Once all the export operation is complete and you have successfully uploaded your certificate clean your machine of any trace of the SSL certificate by deleting the certificate from the store to secure your certificate.
+
Things to note
+If you create a copy of App Service Certificate this way, it won’t have any impact on existing App Service SSL bindings that were created using the portal experience. It also won’t affect any such SSL bindings you may create in the future. You can still Rekey and Renew an App Service Certificate with one click even after making a copy but you would be responsible for creating a new local copy with the new certificate and updating all services that are using the old certificate.
+
Tips
+This section compares this method of certificate deployment with the built-in Azure portal experience for Web Apps. It also contains recommendations you should follow when you use the PFX copy elsewhere.
+
+
+
+
+
Title
+
+
+
Azure portal Deployment
+
+
+
Deploying local PFX copy
+
+
+
Recommendations
+
+
+
+
+
Auto/Manual Renew
+
+
+
When an App Service Certificate is renewed, all the corresponding App Service SSL bindings are updated automatically
+
+
+
When a certificate is renewed, you would need to manually update all the services that are using a local copy.
+
+
+
Turn off Auto renew as you won’t know when exactly an App Service Certificate gets renewed with Auto renew and this would end up breaking your SSL endpoints. Manually renew such App Service Certificates before they expire
+
+
+
+
+
Rekey
+
+
+
Just like renewal, the corresponding SSL bindings are updated automatically
+
+
+
Just like renewal, you would need to manually update all such services.
+
+
+
+
+
+
+
+
Deployment
+
+
+
When deploying certificate this way, you don’t need any file locally and there won’t be any secrets to clean up
+
+
+
When deploying certificate this way, you would have the PFX certificate on local disk.
+
+
+
Always delete the local copy once you no longer need it as you can create a PFX copy as many times as you want. Also, never store the password shown in PowerShell console locally. This way, even if somehow an adversary gets hold of your local disk, he still won’t be able to use the PFX certificate as it’s protected by a strong password
+
+
+
+
+
Getting in touch
+If you have an App Service Certificate that you would like to use outside of App Service ecosystem, then give this a try and let us know how it goes. If you run into any issues, please let us know on the App Service forum.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
MySQL in-app was a preview feature launched last year in August. The feature primary objective was to make it easier to build and test MySQL based applications on App Service. Today, I am excited to announce general availability of MySQL in-app feature.
+
+Note : This MySQL in-app is specific to Windows version of Azure app service. If you are looking for local mysql on Linux MySQL app service , click here.
+
+We have rolled out a database migration feature from MySQL in-app that allows you to export your database content from localdb database provided by MySQL in-app and import it into a production database. A production database can be managed MySQL service or your custom MySQL server solution. See options for production MySQL database in Azure.
+
+This feature will be continue to accelerate your development and testing scenarios . Here are key benefits of using this feature :
+
+
It supports any runtime stack that is available in App Service (Windows) applications such as Node JS , .NET , Python , PHP etc. For Python, Node JS , .NET do make sure you have the appropriate libraries or drivers with your code in order to connect to MySQL database provided with MySQL in-app
+
It’s cost-effective since there’s no additional cost to use this feature and you only pay for the App Service plan (since resources are shared).
+
The MySQL and Web processes are co-located in the same environment (hence the term in-app) which means storage is shared.
+
Includes support for slow query logging and general logging, which you’ll need to turn on as needed (this feature impacts performance, so you shouldn’t use it all the time).
+
One click migration of your database from MySQL in-app to a production MySQL database solution. Azure offers many solutions for MySQL , including:
+
+
+If you intend to use this feature for PRODUCTION web application , your web application must meet one or more of the criteria below :
+
+
your application is read only web site [ when file server is in read only mode , the database is read only as well ]
+
your application does not need auto scale
+
File servers may go into read only mode from 1 to 6 mins depending on whether an upgrade is occurring or any intermittent storage connectivity issue occurs. For example if you use wordpress and during this time you cannot write a post or edit content. You can retry in a few minutes and it will work. If this is okay for your production app then use MySQL inapp
+
Review your user traffic on your application and test to see if your application can run on one instance. If it can manage the load , you can use MySQL inapp for production.
+
+The reason for the criteria mentioned above is due to the lack of support for auto scale on App service with MySQL in-app.
+
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
MySQL in-app feature on App service has announced general availability today. The feature has been keen on improve the experience of developing MySQL based applications on Azure App Service. Once your application is ready to go live , you need to migrate the database content to your production database. This can be tedious task when done manually .
+
+In the MySQL in-app management settings , we now have, we have an option for easily exporting your localdb database from MySQL in-app to a production MySQL database. This blog will discuss how to perform this migration of your database. Follow the steps below :
+
+
+
+
+1. Create a production MySQL database using any one these options. For this blog post I am using a production Azure database for MySQL(Preview). For details , refer to How to create MySQL database from Portal or How to create MySQL database using CLI.
+
+2. Copy the connection string for the Azure database for MySQL(Preview) database. If you are using a different database solution for production , collect the database connection information for your production database.
+
+
+
+3. Login to the Azure portal . Click on your web app using MySQL in-app. Select MySQL in-app setting for your web app and Click on Export button under MySQL in App Export
+
+
+4. You have a choice of using a connections string for your production database or enter the credentials manually. Once the production database connection information has been entered , click on Save to start the process of export. During the export a connection string will be added to the connection string setting in the portal.
+
+
+
+During the export , you cannot make any changes to MySQL in-app configuration in the portal. All options will be disabled to manage MySQL in-app during export process .You must wait until the export is completed.
+
+
+
+8. Once the export is successful , review your production database to make sure all the content was successfully updated. Note we do not turn off the MySQL in-app feature since your production application may still be using it.
+
+Update your application to connect to the production database and test your application before going live with your application. After successful testing , you can now turn off MySQL in-app feature for your web app to continue using production database.
+
+
+
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+App Service has a new experience for Diagnose and solve problems. With this new UI we make it easier to distinguish between application issues (your code) and platform issues (App Service). We also provide quick solutions (Fix it!) tailored to the problems you might be experiencing.
+
+The UI provides a view of the health of your application, health of the platform as well as traffic over the last 24 hours. If any availability issues are detected in that time window, they are listed below the graphs. You can drill down into more detail from there.
+
+If the issue is currently ongoing we try to provide a custom solution specific to the issue we detected. This should point you in the right direction to fix your problem and help get your application back into a healthy state.
+
+You can reach the new experience by clicking on the Diagnose and solve problems item in the general section of any Web, Mobile or API app.
+
+
+
GA for MySQL in App
+The MySQL in-app feature enables running MySQL natively on the Azure App Service platform. While this feature is ideal for small applications running on a single instance, or for development scenarios, you will need a full fledged MySQL resource that you can manage and scale independently for any production scenario.
+
+To ease the migration from your MySQL in App to an external MySQL database we have added Export functionality in the portal to make this a turnkey experience.
+
+You can read more about MySQL in App in the MySql-in-app general availability announcement, and learn how to Migrate development database on MySQL in-app to production MySQL database using the export experience.
+
+
+
+
+
Improved integration with PowerApps and PowerFlows
+Under the API definition feature for any Web, API or Mobile app you will find the new Export to PowerApps + Micosoft Flow button:
+
+Clicking on it will provide the necessary instructions based on your API metadata to allow your PowerApps + Microsoft Flow apps to consume it:
+
+
+
+
+
Export App Service certificates to use with other Azure Resources
+Certificates purchased through App Service certificates can now be exported to use with other Azure Resources:
+
+
App Service on Linux
+We released a few new built-in containers including support for Node 6.9.3 as well as Ruby 2.3:
+
+Bitbucket has also been added as a supported Deployment source under Deployment options:
+
+
+
App service Companion
+We have a new App Service Companion for iOS update that includes new functionality such as support for Push Notifications and ability to Favorite apps for quick access.
+
+
+
+If you have any questions about any of this features or App Service in general be sure to check our forums in MSDN and Stack Overflow.
+
+For any feature requests or ideas check out our User Voice
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Today, we’re happy to announce that F# is now generally available for all users of Azure Functions. Now that the API is stable, anyone can build production applications with Functions written in F#. You can get started today by using one of the F# templates in the portal today.
+
Getting started with F# and HTTP triggers
+Whether you need to expose a new HTTP endpoint for an API or WebHook, or process items from a queue, now F# developers can take full advantage of these Azure Functions capabilities.
+
+Here’s a quick sample of how easy it is to set up an HTTP Trigger:
+
+
Create a new Function App (if you don’t have one already):
+
+
Then, you can create a new F# Function from the “+ New Function” menu
+
+
Once you click on create, you’ll have your Function shortly appear. You can copy the URL to invoke it (1) and click on the Logs button (2) to view your streaming logs from your Function.
+
+
+
Next Steps
+You can continue to learn about F# on Azure Functions by following some of the links below:
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Update #1: The Azure Functions CLI has been renamed to Azure Functions Core Tools.
+
+Update #2: We now have Visual Studio 2017 tooling for Azure Functions! You can use WebJobs attributes to configure triggers and bindings, so there is no need to manually author function.json. For more information, see the following:
+
+With our new Azure Functions runtime support for precompiled functions, you can now use familiar Visual Studio features such IntelliSense and unit testing. These features were among the top requests after we launched the preview Visual Studio Tools for Azure Functions. This also enables an improved development workflow for customers who feel that that class libraries are a better fit for their application.
+
+Azure Functions now supports publishing a class library as the implementation for one or more functions in a Function App. We’ve also recently made several runtime improvements to make assemblies much more useful, such as shadow-copying managed assemblies to avoid file locking issues and restarting the Functions runtime to pick up newly deployed binaries.
+
+Using Visual Studio 2015 or 2017, you can try precompiled functions today with a few manual tweaks to your project. The manual steps are needed because the existing Functions project type (.funproj) has no build action, since it contains only script files. With the setup below, you'll instead use a web project which will provide the full development experience of IntelliSense, local debugging, and publishing to Azure.
+
+The next version of Visual Studio tooling for Azure Functions won’t require this manual configuration, as it will be directly based on class libraries. In fact, the Visual Studio experience will be optimized around class libraries, while the Functions portal will continue to use script files.
+
+
+
Performance benefits of class libraries
+Aside from the tooling experience, another advantage of using a class library is that you’ll see improvements to “cold start,” particularly when running on a Consumption plan. Cold start occurs on the first request to a Function App after it has gone idle, which happens after 5 minutes of inactivity. When a Function App starts up, it indexes all functions and compiles C# and F# scripts into an assembly in memory. So, compilation time will add to cold start time. Customers aren’t charged for cold start since function execution hasn’t started, but it does cause a delay in event processing.
+
Use a Web Application project with a customized start action
+A Web Application project is really a special kind of class library, which means it produces an executable .dll as the build output. To enable local running and debugging, modify the start action of the web project to launch the Azure Functions Core Tools.
+
+Here are some sample projects set up this way:
+
OR, if you've installed the Visual Studio Functions Tooling, the path will look something like C:\Users\USERNAME\AppData\Local\Azure.Functions.Cli\1.0.0-beta.93\func.exe
+
If you've installed the Azure Functions Core Tools through NPM, the path will be something like C:\Users\USERNAME\AppData\Roaming\npm\node_modules\azure-functions-core-tools\bin\func.exe
+
+
+
For Command line arguments, set host start
+
For Working directory, specify the root of the web project on your machine (unfortunately, this isn’t set automatically.)
If you’ve installed the Visual Studio Tools for Azure Functions, just add func.exe to your path from %USERPROFILE%\AppData\Local\Azure.Functions.Cli\1.0.0-beta.93 (or the latest version on your machine).
+
+
+
Go to the Kudu console for your Function App in Function App Settings -> Kudu. Navigate to site and click on the download icon to the left of wwwroot (click on the animated gif below). Or, from an authenticated session, go to https://your-function-app.scm.azurewebsites.net/api/zip/site/wwwroot/.
+
Unzip the file wwwroot.zip on your local machine. From that directory, run the following:
+
+[sourcecode language="plain" light="true" gutter="false"]
+func azure login
+(optional) func azure account list
+(optional) func azure account set
+func azure functionapp list
+func azure functionapp fetch-app-settings [name]
+[/sourcecode]
+
+
+
+This will create a local file called appsettings.json. These settings are only used locally by the Functions Core Tools. Since this file contains secrets, be sure not to check this file in to source control! (The Azure Functions Core Tools adds appsettings.json to .gitignore for you.)
+
+Animated gif:
+
+
+
Project content
+
+
Copy your downloaded files to the web project folder (including appsettings.json). Include the script files and function.json in the project.
+
F5 should now work and successfully attach a debugger. But, you’re still using script files.
+
+
Converting to class files
+To convert script files to C# class files, most changes are straightforward. The one manual step is to modify function.json to point to a class library instead of a script file (step #7 below). The next version of the Visual Studio tooling will eliminate this manual step.
+
+
Rename .csx to .cs and add a class declaration and optional namespace declaration. Remove #load and replace #r with assembly references.
+
If you’re using TraceWriter, add the NuGet package Microsoft.Azure.WebJobs and the statement: using Microsoft.Azure.WebJobs.Host
For each function, modify function.json and specify the scriptFile and entryPoint properties. scriptFile is a path to the assembly and entryPoint is the qualified name of the method. Make sure that function.json is in a directory that matches the function name. See documentation on precompiled functions.
+
+[sourcecode language="plain" light="true" gutter="false"]
+"scriptFile": "..\\bin\\Assembly.dll",
+"entryPoint": "Namespace.ClassName.Run"
+[/sourcecode]
+
+See sample function.json.
+
+Once you compile and run, you should see your class library functions being loaded by the Functions Runtime.
+
+
+
Publish from Visual Studio
+You can publish the project to a Function App using the same experience as App Service publish. The project template generates web.config, but publishing this file has no effect (it is not used by the Functions runtime). Each web project maps to one Function App. If you need to publish functions independently of one another, we recommend that you use separate Function Apps.
+
+To create a new Function App, choose Function App in the Create App Service dialog. To publish to an existing Function App, download your publish profile from the Azure Portal and import in the Visual Studio publish dialog.
+
+You can use the Azure portal to run precompiled functions and view execution logs. To make code changes, you should re-publish from Visual Studio.
+
Publish from Azure Functions Core Tools
+The Azure Functions Core Tools also provides a publish command, via the following:
+
+[sourcecode language="plain" light="true" gutter="false"]
+func azure login
+func azure functionapp publish [name]
+[/sourcecode]
+
+
Building on the server using continuous integration and deployment
+There’s another big advantage to using a web project—continuous integration with build on the server just works! Just follow the same steps as continuous deployment for Azure Functions. Your project will be built whenever there is a sync from source control. This will only work if you’re using a Web Application project, but not if you’re using a Functions Project (.funproj).
+
+To see this in action, just fork the HttpTrigger sample projectand set up GitHub as your continuous integration source.
+
Provide feedback
+Ask questions in the comments section below or reach out to me on Twitter @lindydonna. For general feedback and questions about Azure Functions:
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
App Service has come a very long way in the nearly 5 years it has been a service in Azure. Along the way, we've added a number of features, changed the pricing model, we've even gone as far as to make App Service available in an isolated capacity with App Service Environment and with the recent addition of Azure Functions a new type of hosting plan.
+
With all of these changes it's become clear to us that we need to provide a clear breakdown as to which features are available in which tiers because that enables you, our beloved customers, to be successful on our platform.
+
In an attempt to clarify which features are available where, we have created the below matrix. We are posting this to our blog first, as we would like to hear your feedback if this is effective way of relaying this information to you. For Example, should we merge the below matrix with the App Service Plan limits page.
+
Please leave your feedback in the comments below and we will work on getting a more formal piece of documentation together that will provide you with all of the details you need to get to market in the quickest way possible using Azure App Service.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Today we are announcing preview support for editing and hosting OpenAPI 2.0 (Swagger) metadata in Azure Functions. API authoring is a popular application of Functions, and Swagger metadata allows a whole network of Swagger compliant software to easily integrate with those APIs.
+
+
+
+We are adding a Swagger template generator to create a quickstart Swagger file from the existing metadata in your HTTP Trigger Functions. You just fill in the operation objects for each of your HTTP verbs and you’re off!
+
+We host a version of the swagger editor to provide rich inline editing of your Swagger file from within the Function UI. Once you save your Swagger file we’ll host it for you at a url in your Function App's domain.
+
+Head on over to the documentation to learn more
+
To create your first OpenAPI (Swagger) definition you must first have a function App with at least one HTTP Trigger Function. Instructions.
+
Next head over to the "API Definition (preview)" tab in the lower left hand corner of your Function App.
+
Toggle your Swagger source to "Internal." This will enable hosting and inline editing of an OpenAPI definition for this Function App.
+
Click "Load Generated API Definition" to populate the Swagger editor with a quickstart OpenAPI definition.
+
+
This definition uses your function.json, represented as the settings in the "Integrate tab," for each Function to populate the definition.
+
+
+
Add an operation object for the POST operation of your function with the expected type of input.
+
+
For the HTTP Trigger sample code you can use the following Operation object:
+
+
+
+
Remove the entries under Paths/api/<yourFunctionName> for every verb except POST. (get, delete, head, etc)
+
+
For the default HTTP Trigger, all HTTP verbs are allowed, so our quickstart will have a blank entry for all 8 possible verbs. We want our definition to only contain the available functionality of our API.
+
+
+
Test your Swagger definition
+
+
In the right-hand pane of the swagger editor add your API key as Authentication info, click "try this operation," and enter a name to test your Swagger.
+
+
+
+
Provide Preview Feedback
+Try out Swagger support in Functions and let us know how you like it! We are continuing to develop this set of features and would love to know what matters most to you.
+
+If you run into any problems, let us know on the forums, ask a question on StackOverFlow, or file an issue on GitHub. If you have any additional features you would like to see, please let us know on Uservoice.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
If you use a combination of Azure Mobile Services and Facebook authentication, then you will have noticed that the Facebook authentication stopped working yesterday. This was due to the deprecation of an underlying Facebook OAuth protocol that the service relied on.
+
+If your Azure Mobile Services site has not been migrated yet, we have made changes in the backend to fix the protocol, so no action is required on your part. We apologize for the downtime that this caused.
+
+If your Azure Mobile Services site has been migrated, then you are in charge of the code that runs your site. If your site is a .NET site, we have updated the Katana middleware that runs authentication within the site extension. You need to update an App Setting within your site:
+
+
Find your Azure App Service site and click it. The easiest way to do this is to click All Resources then use the Filter by name... box to find your site.
+
Click Application settings (under Settings) in the left-hand menu.
+
Scroll down until you find App settings.
+
Update the MOBILESERVICESDOTNET_EXTENSION_VERSION value from 1.0.478 to 1.0.481.
+
Click Save at the top of the Application settings blade.
+
+
+If you are running a Node site, then you will need to update the Azure Mobile Services package that is an integral part of the site code to pick up the changes. To do this:
+
+
Find your Azure App Service site and click it. The easiest way to do this is to click All Resources then use the Filter by name... box to find your site.
+
Click Console (under Development Tools) in the left-hand menu.
+
Run the command npm install azure-mobile-services@1.0.1 to update the package. Let this process complete.
+
Click Overview in the left-hand menu.
+
Click Restart to restart your site.
+
+
+After the changes, please test the Facebook authentication to ensure it is working. You can reach out to us on Stack Overflow or Azure Forums to get additional help.
+
+We would like to also take this opportunity to encourage you to update your site to Azure Mobile Apps. This is the v2 edition of the same service, but contains a different client SDK and server SDK. If you are a .NET developer, lots of information about developing the service is available in the Azure Mobile Apps Documentation (for Client and Server) and my book. For Node developers, you can use the Compatibility package to convert your Mobile Services server to a Mobile Apps server. Again, please reach out to us if you run into trouble. As a reminder, the Azure Mobile Services reaches its end of life in May, 2017.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+App Service now supports remote debugging your app form Visual Studio 2017. Remote debugging can be enabled form Application Settings in the menu:
+
+
+
+If you want to learn more about remote debugging you apps in App Service and other troubleshooting tools supported by the platform check out this article: Troubleshoot a web app in Azure App Service using Visual Studio
+
+You can get Visual Studio 2017 here: https://www.visualstudio.com/downloads/
+
+
WordPress on Linux (preview)
+App Service has always supported running WordPress on Windows based App Service plans, but now you have the option to also run it on Linux. This version of WordPress leverages the App Service on Linux support for container and it’s implemented as acustom Docker imagepublicly available onDocker hub.
+
+
+
+You can read more about App Service on Linux here: Introduction to App Service on Linux and how to Create WordPress using Web Apps on Linux
+
+
+If you have any questions about any of this features or App Service in general be sure to check our forums in MSDN and Stack Overflow.
+
+For any feature requests or ideas check out our User Voice
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Today we're encouraging everyone to go give Azure Functions' Application Insights integration a try. You can find full instructions and notes on how it works at https://aka.ms/func-ai. Now it takes (nearly) zero effort to add Application Insights to your Azure Functions and immediately unlock a powerful tool for monitoring your applications.
+
+Application Insights is now available for all Functions users on "~1". If you're on "beta" now, please switch back to "~1" which has the latest version. If you stay on "beta", it's very likely you'll be broken by something at some point.
+
Getting Started
+It’s fairly simple to get started – there is just two steps.
+
+
+
+Once you’ve done this, your App should start automatically sending information on your Function App to Application Insights, without any code changes.
+
Using Application Insights to the fullest
+Now that your Function Apps are hooked up to Application Insights, let's take a quick look at some of the key things you'll want to try.
+
Live Stream
+If you open your Application Insights resource in the portal, you should see the option for “Live Metrics Stream” in the menu. Click on it and you’ll see a near-live view of what’s coming from your Function App. For executions, it has info on #/second, average duration, and failures/second. It also has information on resource consumption. You can pivot all of these by the “instance” your functions are on; providing you insight on whether a specific instance might be having an issue or all of your Functions.
+
+
+
Analytics
+The analytics portal provides you the ability to write custom queries against your data. This is one of the most powerful tools in your tool box. Currently, the following tables are full of data from the Functions runtime:
+
+
Requests – one of these is logged for each execution
+
Exceptions – tracks any exceptions thrown by the runtime
+
Traces – any traces written to context.log or ILogger show up here
+
PerformanceMetrics – Auto collected info about the performance of the servers the functions are running on
+
CustomEvents – Custom events from your functions and anything that the host sees that may or may not be tied to a specific request
+
CustomMetrics – Custom metrics from your functions and general performance and throughput info on your Functions. This is very helpful for high throughput scenarios where you might not capture every request message to save costs, but you still want a full picture of your throughput/etc. as the host will attempt to aggregate these client side, before sending to Application Insights
+
+The other tables are from availability tests and client/browser telemetry, which you can also add. The only thing that’s currently missing is dependencies. There is also more metrics/events we’ll add over the course of the preview (based off your generous feedback on what you need to see).
+
+Example:
+
+This will show us the median, p95, and p99 over the last 30 minutes graphed in a timeplot.
+
+
+
+While you can copy+paste this query, I'd recommend trying to type it out yourself to get a sense of the amazing intellisense features that the editor has. You can learn about all the language features with some amazing examples from the Analytics reference page.
+
+You can also pin these graphs to your dashboard, which makes for a really powerful tool for having a way to know how your application is behaving at a glance.
+
+
+
Alerts
+While it's great that I can see what's happening and what happened, what's even better is being told what's happening. That's where alerts come into play. From the main Application Insights blade, you can click on the alerts section and define alerts based on a variety of metrics. For example, you could have an alert fire when you've had more than 5 errors in 5 minutes, which sends you an email. You can then create another one which detects more than 50 errors in 5 minutes, and triggers a Logic App to send you a text message or PagerDuty alert.
+
Next steps
+Application Insights is now GA'd and ready for production workloads. We're also listening for any feedback you have. Please file it on our GitHub. We'll be adding some new features like better sampling controls and automatic dependency tracking soon. We hope you'll give it a try and start to gain more insight into how your Functions are behaving. You can read more about how it works at docs.microsoft.com
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
I’m excited to announce a new integrated portal experience for Azure Functions. Previously, there was somewhat disjoint experience between Function Apps and App Service. For many management operations, customers had to navigate to the App Service resource blade, and we heard feedback that customers wanted a more integrated and streamlined experience. In addition, we want to provide an easier way to manage multiple Function Apps from within one view.
+
+We’ve made several enhancements to the experience, including:
+
+
A dedicated browse blade for Function Apps. Function Apps are still listed in the App Service blade, but that’s no longer the only way to find Function Apps
+
A tree view that allows viewing and managing multiple Function Apps
+
Filters on subscription and app name, as well as an option to scope the view to just one app
+
One-click access to all App Service platform features
+
A convenient way to manage features that have already been configured
+
Overall UI enhancements to be more consistent with the rest of the Azure portal
+
+For a visual introduction, the short video below walks through the main features. The video is also available on YouTube.
+
+[video width="1920" height="866" mp4="media/2017/04/function-navigation-full.mp4"][/video]
+
Function App browse and management
+There is now a new browse blade for Function Apps that you can pin to the left-hand service menu. Under More services, search for Functions.
+
+
+
+Once you’re on the browse blade, you’ll see all Function Apps in your active subscription in a tree view on the left. You can filter on one or more subscriptions or search for an app name. In the list view on the right, apps are listed in a grid view that includes the subscription, resource group, and location.
+
+If you select an app in the grid view, you’ll see a scoped view for just that Function App. Clearing the search box at the top will show all Function Apps in the selected subscriptions. See animated gif below.
+
+
+
+You can also scope to a particular Function App by selecting the chevron to the right of the app name. The refresh button will update the function and proxies list. On a Consumption plan, the refresh button also synchronizes triggers with the central listener. (This is required if you FTP or Kudu to modify your function.json files.)
+
Function App management
+Once you’ve selected a Function App, the Overview tab on the right displays information about your app and is similar to the App Service resource blade. From here, you can stop, restart and delete your app, download the publish profile, and reset publish credentials.
+
+The Configured features section lists any platform features that you’ve customized. For instance, if you have configured a deployment option, you can navigate to the settings directly from the overview page.
+
+
+
+The Settings tab includes Function App level settings, such as the runtime version, proxies configuration, and host keys. The Platform features tab lists all relevant App Service settings. If you miss the App Service resource blade, you can still get to it from General Settings -> All settings. Features that are not available for your app are still displayed, but include a tooltip on why they are not available. You can also search settings based on either exact name or a descriptive tag. For instance, searching on “git” will highlight the option Deployment source.
+
+
+
+The API definition tab allows you to configure a Swagger API definition. For more information on the feature, see the blog post Announcing Azure Functions OpenAPI (Swagger) support preview.
+
Function navigation
+Navigating to an individual function is also much easier. If you select the Functions or Proxies node within a Function App, you’ll see a list of items you can use to navigate. We’ll be making more improvements to the Functions list, including the ability to search functions, change the enabled state, and delete functions. (For more details, see the GitHub issue AzureFunctionsPortal #1062.)
+
+
+
+See animated gif below.
+
+
+
New Function page
+The New Function page has a few changes. Since the main Function App page now shows the Overview tab, that displaced the Quickstart experience. We’ve incorporated it as part of the New Function page. If a Function App has no functions, you’ll see the quickstart below. To get to the full template view, select Create custom function at the bottom of the page. To get to the quickstart view below from the template view, select “go to the quickstart.”
+
+
+
+
Upcoming improvements
+Today’s release is just the start of the improvements to the Functions portal. Here’s a list of some of the other improvements we have planned:
+
+
Option to create a new Function App from the navigation blade. Currently, you have to go to the top-level +New option to create a Function App (AzureFunctionsPortal #986)
+As this is a big change to the Azure Functions portal, we’d love to hear your feedback. Help improve the product by filling out a 2-minute survey: https://aka.ms/functions-portal-survey.
+
Provide feedback
+Ask questions in the comments section below or reach out to me on Twitter @lindydonna. For general feedback and questions about Azure Functions:
+
+Acknowledgements
+
+We’d like to thank our Azure MVPs and Azure Advisors for trying out an early version of the portal and providing feedback. Functions team members @bktv99, @crandycodes, and @phaseshake filed the most bugs during the bug bash.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Today we are very excited to announce the addition of Azure API Apps to Try App Service. You can now create free trial API Apps with no credit card in a matter of seconds!
+
+API Apps provide a streamlined PaaS experience for hosting APIs. Leverage turnkey security, rich Visual Studio integration, and Swagger support to make the process of developing, hosting, and growing your API easy. To learn more about API Apps check out our docs!
+
+
Templates
+We have two available to showcase API Apps:
+
+
API Todo List: A simple REST API that would host the data for a todo list application. Read the Swagger document and then use the built in testing tools, or a 3rd party API testing suite like postman, to play with the API.
+
+
API Contacts List: A combination single page application and backend API. Experiment with adding and removing contacts from your list, and then use the Swagger doc to experiment with the underlying API calls.Swagger UI showing the underlying API in the contacts list API
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Web Apps on Linux allows running web apps natively on Linux. WordPress is popular blogging platform primarily used on Linux distributions. Today we have released WordPress for App Service on Linux in the Azure marketplace that helps you quickly create a WordPress application on Web apps (Linux) .
+
+This docker image enables you to run a WordPress site on Azure Web App on Linux using either :
+
+
+
+
Azure Database for MySQL: It is a Microsoft solution for MySQL service on Azure that provides a managed database service for app development and deployment that allows you to stand up a MySQL database in minutes and scale on the fly .
+
Local Database : You can manually setup your web app to use Local database. This option is not provided from Azure portal for WordPress on Linux template.
+
+
+
+
Before you begin
+If you don't have an Azure subscription, create a free account before you begin.
+
Deploy from Marketplace
+Log in to the Azure portal.Click here to create the WordPress application.
+
+
+
+
Name
+
Description
+
+
+
+
+
App Name
+
+
+
Enter a unique app name for your **Web App Name**. This name is used as part of the default DNS name for your app <app_name>.azurewebsites.net, so it needs to be unique across all apps in Azure. You can later map a custom domain name to your app before you expose it to your users
+
+
+
+
Subscription
+
Select a Subscription. If you have multiple subscriptions, choose the appropriate subscription.
+
+
+
Resource group
+
+
+
Enter a resource group. A resource group is a logical container into which Azure resources like web apps, databases that is deployed and managed. You can create a resource group or use an existing one
+
+
+
+
App Service Plan
+
+
+
App Service plans represent the collection of physical resources used to host your apps. Select the Location and the Pricing tier. For more information on pricing, see App service pricing tier
+
+
+
+
Database Provider
+
Use Azure Database for MySQL for database solution
+
+
+
+This will deploy a WordPress custom image on to Web Apps on Linux . Note there might be cold start for the first request to the site created.
+
Using GIT repo for WordPress code
+Version 0.3 pulls wordpress code from our GIT repo when you create a when app using this Docker image . If you have custom code on Github as well , you can edit GIT_REPO after the app is created and GIT_BRANCH values in app settings.
+
+
+
+Note: GIT directory: /home/site/wwwroot. When you deploy it first time, Sometimes need to check wp-config.php. RM it and re-config DB information is necessary. Before restart web app, need to store your changes by "git push", it will be pulled again after restart.
+
How to configure to use Local Database with web app
+
+
Create a Web App for Containers
+
Update App SettingWEBSITES_ENABLE_APP_SERVICE_STORAGE= true (If you like to keep you DB after restart.)
+
Add new App Settings
+
+
+
+
+
Name
+
Default Value
+
+
+
+
+
DATABASE_TYPE
+
local
+
+
+
DATABASE_USERNAME
+
wordpress
+
+
+
DATABASE_PASSWORD
+
some-string
+
+
+
+Note: We create a database "azurelocaldb" when using local mysql . Hence use this name when setting up the app
+
+
Browse your site
+
Complete WordPress install
+
+Note: Do not use the app setting DATABASE_TYPE=local if using Azure database for MySQL
+
How to update WordPress core , theme or plugins
+
If WEBSITES_ENABLE_APP_SERVICE_STORAGE= false ( which is the default setting ) , we recommend you DO NOT update the WordPress core version , themes or files from WordPress admin dashboard.
+
+
There is a trade off between file server stability and file persistence . Choose either one option to updated your files :
+
+
OPTION 1 :
+
Since we are using local storage for better stability for the web app , you will not get file persistence. In this case , we recommend to follow these steps to update WordPress Core or a theme or a Plugins version :
Clone your repo locally and make sure to use ONLY linux-appservice branch
+
Download the latest version of WordPress , plugin or theme being used locally
+
Commit the latest version bits into local folder of your cloned repo
+
Push your changes to the your forked repo
+
Login to Azure portal and select your web app
+
Click on Application Settings -> App Settings and change GIT_REPO to use your repository from step #1. If you have changed the branch name , you can continue to use linux-apservice . If you wish to use a different branch , update GIT_BRANCH setting as well.
+
+
+
OPTION 2 : You can update WEBSITES_ENABLE_APP_SERVICE_STORAGE =true to enable app service storage to have file persistence . Note when there are issues with storage due to networking or when app service platform is being updated , your app can be impacted .
+
How to turn on Xdebug
+
+
By default Xdebug is turned off as turning it on impacts performance.
+
Connect by SSH.
+
Go to/usr/local/php/etc/conf.d, Updatexdebug.inias wish, don't modify the path of below line.zend_extension=/usr/local/php/lib/php/extensions/no-debug-non-zts-20170718/xdebug.so
+
Savexdebug.ini, Restart apache by below cmd:apachectl restart
+
Xdebug is turned on.
+
+
Limitations
+
+
Some unexpected issues may happen after you scale out your site to multiple instances, if you deploy a WordPress site on Azure with this docker image and use the MariaDB built in this docker image as the database.
+
The phpMyAdmin built in this docker image is available only when you use the MariaDB built in this docker image as the database.
+
Please Include App SettingWEBSITES_ENABLE_APP_SERVICE_STORAGE= true when use built in MariaDB since we need files to be persisted.
+
+
Change Log
+
+
Version 0.3
+
+
Use Git to deploy wordpress.
+
Update version of PHP/Apache/Mariadb/Phpmyadmin.
+
Add Xdebug extenstion of PHP.
+
Use supervisord to keep SSHD and Apache.
+
This is NOT compatible with tag 0.2 and tag 0.1 for Docker image wordpress-alpine-php
+
+
+
+
Migrating an existing WordPress site
+This image creates a new WordPress application every time it is deployed. If you are migrating your application to this site , please follow directions to export and import as mentioned on Wordpress Codex.
+
+If you have a complex WordPress application where the above mentioned export and import options are not effective, Web Apps on Linux supports git deployment and you use FTP or GIT deployment to replace the file system on the site created with this template to bring your own content. You can use PHPmyadmin available with this solution to import your application database content.
+
Troubleshooting
+The docker image has been updated from this docker image to using a new format where the docker image only contains the server components. The application code for WordPress is deployed via GIT from github repo .
+
Update your application to use the new image appsvc/apps:apache-php-mysql-0.1
+
+
If you have an existing application created using the WordPress image , check the Application setting to verfiy which image is being used with DOCKER_CUSTOM_IMAGE setting .
+
If the setting value is apache-php-mysql-0.1 , no changes needed .
+
If the value is wordpress-0.2 or wordpress-0.1 or wordpress and follow the steps below based on the database being used :
+
+
Azure Database for MySQL
+
+
Create a new web app with WordPress from the Azure marketplace.
+
Select "Existing resource group" and choose the resource group in which your Azure Database for MySQL database exists.
+
Select the same app service plan in which the current site assigned to.
+
If using Azure Database for MySQL , select your existing database that is being used by your web app. Test the new site to make sure it is working as expected before deleting the older app.
+
+
+
Local database
+
+
Backup your web app and database manually.
+
Create a new web app with WordPress from the Azure marketplace and choose Azure database for MySQL
+
Migrate your database to the new database and your files to newly created web app.
+
Note : There is bug with Local database causing the application to break once the app is provisioned which will be fixed in early August 2017 . If you wish to use Local database , wait until Local database is support for WordPress template next month.
+
+
+
+
+
+Using App Service Storage
+
+If you using a web app that was created from Azure marketplace for Web App on Linux using WordPress , Drupal , Mediawiki and Joomla , please add the following app setting WEBSITES_ENABLE_APP_SERVICE_STORAGE app setting to true to continue using App service Storage (platform SMB share i.e /home/ folder ) . Use the platform file storage in these two scenarios :
+
+
When you scale out using the autoscale feature in Web app for Linux.
+
If your application modifies the the files system and you need this new changes to the file system to be persistent . For example , with a WordPress app if you install a plugin , Wordpress adds a few files to the files system for the plugin and modifies the database. If you scale up or the instance your app is running on is recycled you will loose the plugin files which can break your production application. Hence in such cases it is recommended to set the app setting to true.
+
+
NOTE: If the setting is not set to true the changes to the file system are not persisted.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
We recently made a change to the way that we manage the Azure Mobile Apps quickstarts. In the past, when you created a Mobile App, you could go to the Quickstart blade and download a client. This mechanism is still available to you. However, we have also made these quickstart projects available as GitHub repositories. This allows you to fork the repository and start developing without going to the Quickstart blade first. The project that you download from the Quickstart blade is almost the same as the project you can retrieve from the GitHub repository. In the case of the GitHub repository version, you will need to set the URI of your Azure Mobile App backend.
+
+The repositories are:
+
+
+
+In each case, look for the ZUMOAPPURL string in the code and replace it with the name of your Mobile App backend. For the C# projects, this has been placed in a file called `Locations.cs`. In the other projects, it is embedded in the service handler file, so search for the string. There will be one match.
+
+There are other great samples using Azure Mobile Apps for you to check out as well:
+
+
+
FieldEngineer is a project for handling field-workers logistics.
+
MyDriving brings together IoT and Mobile to analyze car telemetry.
+
ContosoInsurance demonstrates an example customer-side insurance car claim service.
+
+
+We are always expanding the samples we offer, so check back often!
+
+
+
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Azure App Service, hybrid connections can be used to access application resources in other networks. It provides access FROM your app TO an application endpoint. Hybrid connections does not know or care what the application protocol is or what you are accessing. It is simply providing network access. Learn more about Hybrid Connections
The new experience makes it easier to create, connect and manage hybrid connections within your web app.
To access this feature go to Settings > Network > Hybrid Connections
New Azure CDN integration
Azure CDN lets you dramatically improve the performance of your application by caching and geo-distributing static content. You can read more about Azure CND here.
Now adding Azure CDN to your web apps is only a few clicks away.
To access this feature go to Settings > Network > Azure CDN
New location for troubleshooting tools
Tools to help you diagnose and debug your app have been moved into Diagnose and Solve problems, the items moved include:
Metrics per Instance (Apps)
Metrics per Instance ( App Service Plans)
Live HTTP Traffic
Application Events
Failed Request Tracing logs
Diagnostics as a Service
Mitigate
PHP Debugging (Zend Z-Ray)
Security Scanning (Tinfoil)
If you have any questions about any of this features or App Service in general be sure to check our forums in MSDN and Stack Overflow.
For any feature requests or ideas check out our User Voice
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
By default PHP error logging is turned off. When your application experiences issues , it would be beneficial to turn the logging on to investigate to root cause of the issue and mitigate it. There are different ways to do this based on whether you are using App Service on Windows or Linux.
+
+Follow the steps below to turn on PHP error logging:
+
+
App Service on Windows: Create .user.ini or modify an existing .user.ini file under your web app root directory D:\home\site\wwwroot.You can do this by updating your root directory via FTP , GIT , or Kudu with this change. In this file add the following line
+
log_errors = On
+
+
App Service on Linux: Create a .htaccess file or modify an existing .htaccess file under web app root directory /home/site/wwwroot. You can do this by updating your root directory via FTP or GIT with this change.In this file add the following line
+
log_errors = On
+
+
+
+
Note
+Remember to turn OFF your PHP error logging when you have completed your investigation. By leaving the setting ON can have big impact on your web app performance.
+
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Web App on Linux is now available for Try App Service. You can now create free trial Web App running on Linux App Service without credit card. All you need is an MSA account.
+
+App Service Web App on Linux (Preview) enables developers to run their cloud apps natively on Docker Containers for Linux. It makes it easier to migrate existing apps hosted and optimized for the Linux platform into Azure App Service. Furthermore, with custom Docker Container support, developers can implement applications in many programming languages and stacks while taking advantage of Docker tooling as well as the industry leading PaaS capabilities of Azure App Service.
+
+
+
Templates
+With the initial release, there are two templates available for Web App on Linux.
+
+
NodeJS Web App on Linux
+
PHP Web App on Linux
+
+These templates deploys a container with respective runtime, where you can choose to deploy your NodeJS or PHP Web App and give Web App on Linux a try using your MSA account.
+
+Once your trial Web App is created, you can simply manage it using Azure Portal by clicking on “Manage in Azure Portal” option or using CLI option. Once you are logged into the portal it gives you full access to Azure App Service Web App on Linux, where you can test out all the features like slots, SSH, Auto Scale as well as bringing your own container.
+
+Your trial Web App will expire in 30 minutes, but you can sign up for 30 day free trial.
+
+Click Here to Get Started
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Azure Functions support for Application Insights has moved out of limited beta and into a wider public preview. We’ve also added support to add Application Insights on create, as well as, a direct link from Azure Functions’ portal to the Application Insights blade. We’ve also added additional settings to help control what data get sent and how much to send, helping you to control the volume of data that is sent.
+
Getting Started
+To get started with Azure Functions and Azure Application Insights, you can create a new Function App and set the Application Insights toggle to “On”, which will create an Application Insights resource for you, automatically.
+
+
+
+If you want to use add an existing Application Insights resource or you have an existing Azure Function App, you can add Application Insights by adding an App Setting with your instrumentation key.
+
+
+
+
+
+Once you’ve done this, you can navigate to your Application Insights resource from the “Configured Features” page of your Function App.
+
+
+
Using Application Insights
+
Live Stream
+If you open your Application Insights resource in the portal, you should see the option for “Live Metrics Stream” in the menu. Click on it and you’ll see a near-live view of what’s coming from your Function App. For executions, it has info on #/second, average duration, and failures/second. It also has information on resource consumption. You can pivot all of these by the “instance” your functions are on; providing you insight on whether a specific instance might be having an issue or all of your Functions.
+
+Known issues: there are no dependencies being tracked right now, so the middle section is mostly useless for now. If you send your own custom dependencies, it’s not likely to show up here since they won’t be going through the Live Stream API since you’re normally using a different client, today.
+
+
+
Metrics Explorer
+This view gives you insights on your metrics coming from your Function App. You can add new charts for your Dashboards and set up new Alert rules from this page.
+
Failures
+This view gives you insights on which things are failing. It has pivots on “Operation” which are your Functions, Dependencies, and exception messages.
+
+Known issues: Dependencies will be blank unless you add custom dependency metrics.
+
Performance
+Shows information on the count, latency, and more of Function executions. You can customize this pretty aggressively to make it more useful.
+
Servers
+Shows resource utilization and throughput per server. Useful for debugging Functions that might be bogging down your underlying resources. Putting the servers back in Serverless. J
+
Analytics
+The analytics portal provides you the ability to write custom queries against your data. This is one of the most powerful tools in your tool box. Currently, the following tables are full of data from the Functions runtime:
+
+
Requests – one of these is logged for each execution
+
Exceptions – tracks any exceptions thrown by the runtime
+
Traces – any traces written to context.log or ILogger show up here
+
PerformanceMetrics – Auto collected info about the performance of the servers the functions are running on
+
CustomEvents – Custom events from your functions and anything that the host sees that may or may not be tied to a specific request
+
CustomMetrics – Custom metrics from your functions and general performance and throughput info on your Functions. This is very helpful for high throughput scenarios where you might not capture every request message to save costs, but you still want a full picture of your throughput/etc. as the host will attempt to aggregate these client side, before sending to Application Insights
+
+The other tables are from availability tests and client/browser telemetry, which you can also add. The only thing that’s currently missing is dependencies. There is also more metrics/events we’ll add over the course of the preview (based off your generous feedback on what you need to see).
+
+Example:
+
+This will show us the distribution of requests/worker over the last 30 minutes.
+
+
+
+
+
Configuring the telemetry pipeline
+We wanted to be sure you can still control what data and how much gets sent, so we’ve exposed a handful of configuration settings for your host.json which allows you to finely control how we send data. We our latest updates to the configuration, you can now control the verbosity levels of the various telemetry pieces, as well as enable and configure aggregation and sampling.
+
+
+
Limitations during preview
+Now that we’ve moved out of beta, we don’t have any planned breaking changes, but we’ll still consider the feature in preview from a supportability point of view. Once we’ve had a wider set of users using Application Insights and we complete some missing features like automatic dependency tracking, we’ll remove the preview flag. This means if you should avoid using our Application Insights integration for business critical applications, and instead continuing to instrument your code yourself with Application Insights.
+
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
From HTTP triggers to proxies, Azure Functions provides a variety of tools to make developing serverless APIs quick and easy. The team has been hard at work on improvements to the API development story, including new capabilities for Azure Functions Proxies, as well as a faster way to get your APIs into PowerApps and Microsoft Flow.
+
+
Request and response transforms for Azure Functions Proxies
+Azure Functions Proxies now allows you to modify requests to and responses from the backend. A new feature of proxies.json allows you to set properties of the HTTP message, including headers, query string parameters, request methods, and response status codes. This can be used to more easily integrate with existing backends or to create mock APIs. As a part of this update, you are also now able to bind parameters from the request/response. For example, you could reference {request.querystring.name} as a part of your backend URL or map them into a new header. To learn more about request and response transforms, see the Proxies documentation.
+
+
Express export to PowerApps and Microsoft Flow
+App Service and Azure Functions now let you leverage your API from PowerApps and Microsoft Flow with just a few clicks. The Export to PowerApps + Microsoft Flow gesture has been expanded to include an express option, allowing you to do everything right within the Azure portal.
+
+
+
+The new gesture will prompt you to select an environment in which the API should be created. You will only be able to use this capability for environments in which you have create API permissions. If you don't have the right permissions, you can still use the "Manual" option to get your metadata and provide it to an environment administrator, who can create the API for you.
+
+As part of the express flow, you will also need to provide any security properties that are defined in your OpenAPI (Swagger) document. Note that API keys are currently not supported. If your API does require a key to be provided, you will need to configure this within PowerApps or Flow after exporting.
+
+Beyond that, it's as simple as clicking "OK" and seeing your custom API created instantly. This is a great complement to the recent preview of Swagger support for Functions. Now you can create, document, and publish an API to PowerApps and Flow all as a part of your normal Functions workflow.
+
+
Providing feedback
+As always, we love getting feedback. Let us know how these features work for you, and if there are other parts of API development that could use improvement. You can always reach us in the Forums (App Service, Functions) or on UserVoice (App Service, Functions).
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Azure Database for MySQL (Preview) and Azure Database for PostgreSQL (Preview), both services support Secure Sockets Layer (SSL) encryption. By default if you create a MySQL or PostgreSQL server using this server SSL is required to connect to all databases on that server. With Web Apps , the application needs to provide the certificate authority (CA) is one that the client trusts for the connection to succeed. This involves a few steps .
+
+Follow the steps below to add SSL to an existing application on Azure App Service.
+
Note: These instructions are same whether you are using Windows or Linux based Azure App Service.
+
+
Follow the steps in this article on configuring SSL on Azure database for MySQL or PostgreSQL.
+
Create a bin folder under D:/home/site/wwwroot and place the certificate (.pem file generated from step #1) in bin folder. You can do this directly by accessing the file server for web app using FTP or Git or Kudu .
Select your existing Web app and click on Application settings. Add the following app setting for your web app:
+For MYSQL :
+For PostgreSQL :
+
Now SSL certificate is added to your web application . Your application code needs to be updated to use this certificate authority when connecting to the database.
+
+Please refer to the documentation of your application framework on how to consume the certificate authority to connect to the database via SSL.
+
+Here are a few examples below.
+
Connect to MySQL server with SSL for WordPress app
+Add the following to wp-config.php to connect to the MySQL database via SSL
+
+If you are using PHP 7.X version , you need another flag MYSQLI_CLIENT_SSL_DONT_VERIFY_SERVER_CERT for any PHP based application. For example with WordPress , you need to update MYSQL_CLIENT_FLAGS as shown below
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+If you don't have an Azure subscription, create a free account before you begin.
+
Deploy from Marketplace
+This blog post describes how to get started running a Django app with postgresql from Azure marketplace . This marketplace solution creates the following resources : Web Apps on Windows and Azure Database for PostgreSQL (Preview).
+
+Log in to the Azure Portal. Launch the Django + PostgreSQL template in the Azure marketplace to get started. Provide the necessary information for web app and database to be deployed.
+
+
+
+
+
+
+
Name
+
Description
+
+
+
+
+
App Name
+
+
+
Enter a unique app name for your **Web App Name**. This name is used as part of the default DNS name for your app <app_name>.azurewebsites.net, so it needs to be unique across all apps in Azure. You can later map a custom domain name to your app before you expose it to your users
+
+
+
+
Subscription
+
Select a Subscription. If you have multiple subscriptions, choose the appropriate subscription.
+
+
+
Resource group
+
+
+
Enter a resource group. A resource group is a logical container into which Azure resources like web apps, databases that is deployed and managed. You can create a resource group or use an existing one
+
+
+
+
App Service Plan
+
+
+
App Service plans represent the collection of physical resources used to host your apps. Select the Location and the Pricing tier. For more information on pricing, see App service pricing tier
+
+
+
+
Server Name
+
Enter a postgresql database servername
+
+
+
Server admin login name
+
Enter a postgresql database administrator username
+
+
+
Server admin password
+
Enter a postgresql database administrator password
+
+
+
Version
+
Azure database for PostgreSQL(Preview) currenlty supports PostgreSQL 9.5 version
+
+
+
Pricing tier
+
Choose Basic or Standard pricing tier. For more information on pricing, see App service pricing tier
+
+
+
Database Name
+
Enter a database name for your web app
+
+
+
+You can watch the progress by clicking the bell icon at the top of the portal page while the app is being deployed.
+
+
+
+When the web app creation is finished, navigate in the Azure portal to the resource group to view the web app and PostgreSQL server.
+
+
+Select the web app line and then click Browse.
+
+
+
Develop your application
+The Django + PostgreSQL template contains the Django framework on top of which you can build your application. You can create an Django app using Kudu.
+
+To access Kudu , select your web app in the portal and click Advanced Tools -> Go .
+
+Click on Debug Console to access the CMD prompt. In the console run the following commands under wwwroot folder.
+
+
+
+This will create myapp folder with starter Django app . For more details in Django app, see Get started with Django .
+
+
+
Database configuration
+You can access the database information within Azure portal by clicking in Application settings -> Connection strings. It is best practice to use App Settings for storing your database information instead of hard coding it in your settings.py file. Create these app settings in Azure portal for your web app.
+
+
+
+Update DATABASES setting in local settings.py file in your application. to read from App Settings environment variables.
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+These are the common questions with no easy answers. Wouldn’t it be nice if solutions on what to do next are readily available? The Azure App Service Support Center is the answer. You can access it via “Diagnose and solve problems” in the web app settings blade.
+
+
+
+There are many reasons why a web app could experience a downtime – for instance, platform service outages, application code bugs, CPU or memory exhaustion, new deployment having unknown bugs, app crashes, faulty VM instances, abnormal recycles, port or socket exhaustions, exceptions in code, thread exhaustions and many more.
+
+In this initial release of Azure App Service Support Center, we are optimizing for the following scenarios
+
+
Service outages, platform health issues
+
Abnormal CPU usage
+
Abnormal memory usage
+
Application code issues
+
+
Platform Incidents
+In the case of a platform incident, your app may be affected. In such cases, Microsoft engineers will have already been engaged to resolve the issue. The “Diagnose and Solve problems” blade will highlight this scenario right away making isolating the issue obvious. Screenshot below is an example of such an incident.
+
+
+
CPU and Memory Issues
+High CPU or Memory usage can cause your web app to have downtime. In this case, you can identify the specific instances and web apps consuming resources. Solutions for these issues include
+
+
Advanced application restart – restart a specific web app process on a specific instance
+
Restarting the web app – restart the web app on all instances
+
Scale up – scale up to instances with larger memory and more CPU
+
+Screenshot below is an example of such an incident.
+
+
+
Application code issue
+Often, issues within the application code are the cause of downtime. These could include bugs, race conditions, external dependencies or your web app throwing exceptions. The failed requests log analysis, threads analysis detectors can determine when failures are a result of an application issue or a result of a platform issue. As instructed in the screenshot below, remote profiling is the best way to troubleshoot application specific issues.
+
+Screenshot below is an example of such an incident.
+
+
+
+
How does it all work?
+Under the covers, the user experience is powered by a big data solution, where we mine large amounts of platform and application data to perform intelligent pattern analysis algorithms and surface most relevant observations and problems. Internally we refer to these algorithms that perform analysis as “detectors”. Each detector analyzes the data and determines the appropriate solutions to fix your problem when it is happening.
+
+The “Solution” option will be displayed when our detectors have determined that there is a mitigation step you could take to recover your web app. In addition, the troubleshoot section contains other mitigation options as well as specific troubleshooting tools.
+
+The goal of this new self-service diagnostics blade is to answer the questions Why was my Web App down? and How do I fix it? The detectors will provide insights and solutions that enable users to quickly mitigate and diagnose any issues. As you continue to use self-serve diagnostics, we will be adding new detectors and improving the existing ones with richer data and solutions that are more precise.
+
Full List of Detectors
+
+
Service Health - This detector looks at ongoing and past service incidents. Whenever this happens, Microsoft engineers are engage very quickly and start working to solve the problem
+
CPU Analysis - This detector can identify instances where there is high CPU usage. It can also determine the specific site process within the app service plan that is using the most CPU.
+
Memory Analysis: This detector can identify instances where there is high Memory usage. It can also determine the specific site process within the app service plan that is using the most Memory.
+
Failed Requests Analysis: This detector looks for requests with 5xx http status code, detailed error codes and win32 status codes. It tracks the request’s journey all the way to your application code. If errors are happening purely in application layer (not in platform pipeline) this detector provides suggestions on debugging application code
+
Site deployments: This detector looks for web and kudu deployments as a possible cause for downtime.
+
Site Crashes: This detector looks for abnormal terminations (crashes) of w3wp (application code) processes.
+
Worker Availability: This detector gives you insights into whether the problem is happening on a specific instance, which could point to a resource constraint or another problem with that instance alone.
+
Process Restarts: This detector considers possible reasons that could have caused the application code to restart (w3wp process). Process restarts can cause transient availability issues. Reasons for process restart include: user initiated, config updates, auto heal, resource contentions, etc.
+
Site quota exceeded: This detector indicates when failures are a result of a site in Free or Shared SKU exceeding a quota. When sites exceeded quota limits, the platform turns it off temporarily.
+
Port and Socket Exhaustion: This detector figures when an outbound network connection is rejected because of port exhaustion.
+
Thread and Handle usage: This detector detects if there is abnormally high usage of threads or handles that could affect application’s uptime.
+
+We hope this initiative helps you isolate and root cause issues with your web apps easily. As always, please provide feedback by simply clicking on the smiley - feedback icon at top left corner of the blade.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
The following steps show how to connect your existing web app on Azure App Service running on MySQL in-app or other MySQL solutions in Azure to Azure database for MySQL (Preview).
+
+Azure database for MySQL provides tighter security using Firewall to protect your data. When using this service with App Service Web Apps , you need to keep in mind that the outbound IPs are dynamic in nature .
+
+
To make sure the availability of your web app is not compromised , we recommend to all the rule to allow ALL IPs as shown in the image below. Note: We are working with Azure database for MySQL (Preview) team for a long term solution to avoid allowing all IPs.
App service infrastructure tries to keep the outbound IPs the same as best as we can , but when recycle or scale operation occurs it may change since we add new machines on every region frequently to increase our capacity to server customers. If this changes , the app will experience downtime since it can no longer connect to the database. Keep this mind when choosing one of the option mentioned above.
+
SSL configuration
+Azure database for MySQL (Preview) has SSL Enabled . If your application is not using SSL to connect to the database , then you need to Disable SSL on MySQL server. For details on how to configure SSL , See using SSL with Azure database for MySQL (Preview).
+
+
+
+Note that some applications frameworks may not support SSL , hence check your application framework documentation on whether to disable or enable SSL.
+
Migrating from MySQL in-app database to Azure Database for MySQL (Preview)
+You can migrate MySQL in-app database to Azure database for MySQL (Preview) using Export feature. Note in order to use this feature to export the database , you need to :
+
+
Disable SSL since the feature does not work with MySQL database connected via SSL.
+
Allow all IPs is configured on your MySQL server
+
+
App Service Back up and Restore features
+Currently backup and restore feature does not work with SSL enabled for Azure Database for MySQL (Preview). Disable SSL if you are planning to backup/restore the database using App service backup feature . Azure database for MySQL (Preview) also offers backup feature , for more details see here.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
The Azure Marketplace provides a wide range of popular web apps developed by open source software communities, for example WordPress. The following table of content below will get started on running WordPress on App Service from creating , managing , configuring , performance and troubleshooting WordPress app.
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
With the new Visual Studio 2017 support for Azure Functions, you can now author functions using C# class libraries. With the new project type, triggers and bindings are defined using attributes, which are then converted to function.json as a build task.
+
+To build the project on the server with continuous integration, you have two options: 1) the Continuous Integration feature of Functions, or 2) Visual Studio Team Services (VSTS). The code can be hosted on VSTS or an external service such as GitHub or Bitbucket.
+
+The process is quite easy, thanks to a new build template: ASP.NET Core on .NET Framework. If you’re not familiar with VSTS build definitions, read CI/CD for newbies.
+
+To create a build definition, do the following:
+
+
From the Build Definitions view in VSTS, select +New.
+
Choose the template NET Core (.NET Framework). Even though we’re not deploying an ASP.NET Core app, this template has the correctly configured tasks for a Functions project.
+
Add a build task for Azure App Service Deploy.
+
+
Ensure you use a VS2017 build agent
+
+
+
Choose an Azure subscription and select your Function App under App Service name.
+
Modify the Package or folder setting to use $(build.artifactstagingdirectory)/**/*.zip
+
Save and queue the build.
+
+Here’s an animated GIF that walks through the VSTS configuration steps:
+
+
+
+
+
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Deployment Slot support for Azure Functions (preview)
+Azure functions now support creation of deployment slots, just like apps on App Service you can create slots and perform swap operations between slots.
+
+
+
New Backup experience for apps on App Service
+We have revamped the backup experience to make it more streamlined and easier to configure.
+
+
+
New Delete experience for apps on App Service
+The new Delete experience provides more information about what will be deleted and allows you to opt out of deleting the App Service plan when deleting the last app hosted in it.
+
+
+
+
+
App Service support for Azure Database for MySQL and Azure Database for PostgreSQL
+If you have any questions about any of this features or App Service in general be sure to check our forums in MSDN and Stack Overflow.
+
+For any feature requests or ideas check out our User Voice
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
MySQL in-app for Linux Web App is not the same as MySQL in-app feature for Windows Azure Web App . This applies to WordPress , Drupal , Joomla and Mediawiki Templates on Linux Web App . For Linux web apps , we leverage the docker container to build MySQL as part of the image used to deploy in the Azure portal, for example WordPress on Linux.
+
These custom images are available on github. The image uses MariaDB 10.0+ server with the default port 3306 and is installed , configured when the docker image runs on the Linux web app.
+
Get Database connection
+You can get the database information from the Azure portal. Select your web app , then select Application Settings -> App settings. This will list out the database information needed for your web application.
+
+
+
Manage your Local database
+
You can access and manage the database using PHPmyadmin that is enabled and configured as part of deployment of the docker image. To view PHPmyadmin tool ,use the URL in this format http://hostname/phpmyadmin and enter the credentials to connect.
+
You can find the credentials for PHPmyadmin in the Azure portal . Select your web app , then select Application Settings -> App settings
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
App Service makes building data driven solutions easier via the Azure portal. Azure app service supports various data solutions like SQL , MySQL etc. To help understand how these data solutions work with App Service (Web Apps, Mobile Apps, Functions) and pick the right solution based on your needs, view the table below.
+
+* Free Azure SQL DB offers one SQL Database per subscriptions limited to 32 MB for free for one year.
+** Both Linux and Windows App service platforms support use of these data solutions , but based on your application framework you may require additional libraries in your application code to connect to the database.
+*** Currently App Service backup and restore feature does not support database connections over SSL.
+**** Azure Functions supports Azure SQL DB , MySQL and PostgreSQL via the .NET SDK of these respective data services. For cosmos DB you can use binding or the SDK.
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
The Azure Functions Consumption Plan now includes a preview of deployment slots. Deployment slots are a valuable component of a cloud ready application development lifecycle. The feature enables development and production environment separation to isolate critical production workloads. At the same time deployment slots create a natural bridge between development and production where the next version of a Function App staged in a deployment slot can become the production version with a simple platform managed swap action. For more information on the deployment slots concept as used in the context of the broader App Service platform please see this documentation article.
+
+You can explore the deployment slots preview via Azure Portal. Each Function App includes a view of deployment slots. The preview requires a one-time opt-in for each Function App available under the Function App's Settings tab. Opt-out is not available, simply delete deployment slots if no longer necessary.
+
+
+
+After preview opt-in the Function App secrets will be updated. Please copy the new secrets under the Manage node for each function. You can add a deployment slot under the Slots view. For the Consumption Plan you can include 1 other slot in addition to production.
+
+
+
+Each deployment slot can be treated as a standalone Function App with its own URL, its own content, and differentiated configuration. That means even input and output bindings can be different and the non-production version can be evolved independently without production dependencies if this is a requirement for your specific workload. You can designate configuration elements such as App Settings or Connection Strings as slot specific to make sure they will continue to be associated with the same slot after swap: e.g. a production slot will continue to point to the same production specific storage account.
+
+
+
+To swap a non-production deployment slot to production use the Swap action under the Overview tab for your Function App.
+
+
+
+You can select the swap type as direct swap or a swap with preview where destination slot configuration is applied to the source deployment slot to allow validation before the swap is finalized. You can also see a configuration diff to make sure you are aware and can react to how configuration elements are impacted by the swap action.
+
+
+
+The deployment slots preview will continue to evolve in the journey to general availability. There are some current limitations such as a single instance scale for non-production deployment slots. If your production Function App is running at large scale this limitation may result in a timeframe where throughput is decreased as the platform re-adjusts the scale after swap. For any questions or issues to share with the engineering team regarding the deployment slots preview please use the Azure Functions MSDN forum.
+
+Follow us on Twitter for product updates and community news @AzureFunctions.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+App Service has been supporting custom hostnames for a while now, you can read about this feature here. App Service has a shared front-end so before you can use a custom hostname with your app, you need to verify domain ownership by creating the required DNS records. This is done to prevent hostname squatting vulnerability. To add a custom hostname to your app, you need to create DNS records for ownership verification and routing.
+
+
Details
+There are a few ways to add custom hostnames, most commonly used methods are given below:
+
+
CNAME: This is the recommended approach and easier of the two as it requires only one DNS record. To add a custom hostname using CNAME method, you need to create a CNAME record on the custom hostname pointing to the default hostname of the App. For example, if you want to add ‘support.api.contoso.com’ to a web app named ‘contoso’ then you should create a CNAME record on ‘support.api.contoso.com’ pointing to ‘contoso.azurewebsites.net’. In this case, the CNAME record is used for both, verification and routing.
+
+
+
+
DNS Record Type
+
Sub-domain
+
Value
+
+
+
CNAME
+
support.api
+
contoso.azurewebsites.net
+
+
+
+
+
+
+
A with TXT: In certain scenarios, a customer may not able to create the required CNAME record. For example, a lot of DNS providers don’t allow CNAME record on the root hostname. In that case, a customer can use this verification method. This requires creating two DNS records on the hostname being added. For example, if a customer wants to add ‘contoso.com’ to a web app named ‘contoso’ then he should create:
+
+
An A record on ‘contoso.com’ pointing to web app’s IP address. You can get this IP address from Azure portal or by resolving the default hostname locally. One of the convenient ways to resolve hostname is to simply ping it: ping contoso.azurewebsites.net. A record is used for routing traffic to your app.
+
A TXT record on ‘contoso.com’ with value set to the default hostname. In this case, the value should be contoso.azurewebsites.net. TXT record is used for verification.
+
+
+
+
+
DNS Record Type
+
Sub-domain
+
Value
+
+
+
A
+
@
+
<IP Address>
+
+
+
TXT
+
@
+
contoso.azurewebsites.net
+
+
+
+
+
+
+
Recent updates
+We recently made the following two changes in our hostname management model:
+
+
One to many associations between hostname and Azure subscription: Earlier, a hostname could only be used with one subscription on App Service platform. With this change, now a hostname can be shared by multiple subscriptions. Each subscription needs to validate the domain ownership separately by creating the required DNS records.
+
Allowing a subscription to reclaim a hostname by validating domain ownership: App Service platform consists of multiple scale units. A hostname can only be associated with one app on a scale unit. Even two apps in the same subscription cannot share the same hostname on a scale unit. This is by design as App Service runtime should be able to resolve a custom hostname to an App uniquely. We have received multiple customer reported incidents in the past where a customer had a custom hostname in his old subscription that he could not access anymore for some reason and wanted to use the same hostname with another app on the scale unit. This was not allowed earlier even though the customer could revalidate domain ownership. With this change, now App Service customers can do this themselves.
+
+Apart from these two changes, I would also like to cover some of the most common domain related questions we receive our customers:
+
Migrating a live custom hostname without any downtime
+If you would like to move a live custom hostname to App Service, then following the typical verification method would cause downtime between updating the DNS records and adding the corresponding hostname to your web app. If you would like to prevent the downtime, then you can use the alternate ‘awverify’ subdomain instead for verification. Say you would like to add ‘www.contoso.com’ to a web app named ‘contoso’ without any downtime. You can follow these steps to achieve this objective.
+
+
Create a TXT record on awverify.www.contoso.com with value set to ‘contoso.azurewebsites.net’ for verification
+
+
+
+
+
DNS Record Type
+
Sub-domain
+
Value
+
+
+
TXT
+
awverify.www
+
contoso.azurewebsites.net
+
+
+
+
+
+
+
Add the custom hostname through Azure portal. Once this is done, you can delete the TXT record created in step 1 if you want.
+
Create a CNAME/A record on www.contoso.com to point it to ‘contoso.azurewebsites.net’. This would start routing traffic to your App Service App.
+
+
+
+
+
+
DNS Record Type
+
Subdomain
+
Value
+
+
+
CNAME
+
www
+
contoso.azurewebsites.net
+
+
+
+Or
+
+
+
+
DNS Record Type
+
Subdomain
+
Value
+
+
+
A
+
www
+
<IP Address>
+
+
+
+
+
+
+
Adding the same custom hostname to multiple web apps
+There are scenarios where a customer would like to add the same hostname to multiple web apps in the same subscription, having a geo distributed website is one example. Our custom hostname feature allows you to bypass validation for hostnames that have already been validated. You only need to verify domain ownership when you add a hostname for the first time. For all other apps in the same subscription, you can add the same hostname without creating any DNS records.
+
+
+
Programmatically manage custom hostnames
+We have updated our API surface to expose each custom hostname as a separate resource, giving App Service customers the ability to manage each hostname individually. A custom hostname is represented as ‘Microsoft.Web/site/hostnameBindings’ resource. For example, if you want to add ‘www.contoso.com’ to a web app called ‘contoso’ then first you need to create a CNAME record on this hostname pointing to ‘contoso.azurewebsites.net’. After that, you can add the hostname by calling the following ARM API:
+
+ARMClient PUT /subscriptions/fb2c25dc-6bab-45c4-8cc9-cece7c42a95a/resourceGroups/Default-Web-EastAsia/providers/Microsoft.Web/sites/contoso/hostnameBindings/www.contoso.com?api-version=2016-03-01 "{'Location':'West US','Properties':{}}"
+
+You can also use the following ARM template for adding custom hostnames:
+
+https://github.com/Azure/azure-quickstart-templates/tree/master/201-web-app-custom-domain
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+Today, we are announcing the support for installing public certificates in personal certificate stores. We are currently building a user-friendly experience to expose this functionality via Azure portal. In the meantime, you can use ARMClient/Azure Resource Explorer/Azure PowerShell/Azure CLI for calling the corresponding backend APIs to use this feature right away. For this blogpost, I will be using ARMClient to demo these APIs.
+
Details
+To support public certificates, we have created a new ARM resource type called ‘sites/publicCertificates’ under ‘Microsoft.Web’ resource provider. Each instance of this resource represents a certificate installed in your App Service. To install a public certificate, you can call the following PUT API on an existing App Service:
+
+ARMClient PUT https://management.azure.com/subscriptions/fb2c25dc-6bab-45c4-8cc9-cece7c42a95a/resourcegroups/publiccertificaterg/providers/Microsoft.Web/sites/publiccertificatedemo/publicCertificates/currentuser1?api-version=2016-02-01 "{'Properties':{'Blob':'MIIC/zCCAeugAwIBAgIQjngbV7+4eppN1YUvFh8guDAJBgUrDgMCHQUAMBgxFjAUBgNVBAMTDXRlc3RjZXJ0MS5jb20wHhcNMTcwNDAzMjIyMTI1WhcNMzkxMjMxMjM1OTU5WjAYMRYwFAYDVQQDEw10ZXN0Y2VydDEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAiq+O7aP68Q5uCr0u0fRlOCXpIYw498Yk2sxdR3ElgF+nD8pmgdrAbGaGlBcxO0i/YrITgD5n73BBL17QPFNx7Y8mHl3U7vOAYkYHVZQlJVc8XPmjmgL6ZGSquPkJhev9vg1U26mJHdjoOprN2dSZIKw7VB+DbBgHipjFsaxe99GocQeQxNoa93wu7uWRgI0foKgYgDBEWbyMSgT6ZXQUwoQVNTDSPmQ8PlNrAOJz3cLM6jp0e0ZKDPJEqRXm3UX6F7DcOR0G7OvUil56Ze9ANNcF2bTwTpdCLPx2OImnKCeb5Vyxg9Ymtu3aAm9U5qX8pXAZu+oU5NAiJx1TvlJkPQIDAQABo00wSzBJBgNVHQEEQjBAgBCqtQL/bkUvJkvip2NwKuuPoRowGDEWMBQGA1UEAxMNdGVzdGNlcnQxLmNvbYIQjngbV7+4eppN1YUvFh8guDAJBgUrDgMCHQUAA4IBAQA9y0GjiioOMjKFLJAqFoePeW2/MH+8QAJYvsmchZ5J8gq4TrpKbw2xrIuHmRmHv+hNAGGMGNoPg9JHHk8YuHCvaNM/10HGu0xHzgG7sEui/3MA7jAbMHQOaE54G4HiBVVFabo6li7WjSsx+RjlxNPtb+GMcBoDBAXcbzBmj/1BPNyrlwdBZHpwwnZBJpH+xHWXwIyyqBBAtQiXv7SSV79bwxPRhvCH6rhF8e0qXNGFHIDTiuDol8+eBBiGOEDwB79zDWLlvbXxKxxtQq2KqKhiLntLs1f9tohF6ad7HN5nK1RLPmqC/hoYA+/Fx5jpoX/pQo3Vlf3KMsr1280JSqq8','publicCertificateLocation':'CurrentUserMy'}}"
+
+Parameters:
+/subscriptions/…/sites/publiccertificatedemo: Resource Id of the App Service that would be using the public certificate. This App Service needs to be in a dedicated App Service Plan.
+publicCertificates/currentuser1: User friendly name of the ‘sites/publicCertificates’ resource that represents this public certificate.
+blob: Base 64 encoded .cer file that contains a public certificate.
+publicCertificateLocation: Location in Windows certificate store where this certificates would be installed. We only support 'CurrentUserMy' for public scale units. If your site is inside an App Service Environment, then you can also use ‘LocalMachineMy’.
+
+I have written a simply asp.net page that lists all certificates in CurrentUser-Personal certificate store.
+
+
+protected void Page_Load(object sender, EventArgs e)
+{
+ var store = new X509Store(StoreName.My, StoreLocation.CurrentUser);
+ store.Open(OpenFlags.ReadOnly);
+ foreach (var certificate in store.Certificates)
+ {
+ Response.Write(string.Format("Subject:{0} Thumbprint:{1} SerialNumber:{2} HasPrivateKey:{3} <br />", certificate.Subject, certificate.Thumbprint, certificate.SerialNumber, certificate.HasPrivateKey));
+ }
+ store.Close();
+}
+
+Here is a screenshot of this App Service after executing the ARM client command shared above.
+
+
+Similarly, we can execute the following ARMClient command to install another public certificate in CurrentUser-Personal certificate store:
+
+ARMClient PUT https://management.azure.com/subscriptions/fb2c25dc-6bab-45c4-8cc9-cece7c42a95a/resourcegroups/publiccertificaterg/providers/Microsoft.Web/sites/publiccertificatedemo/publicCertificates/currentuser2?api-version=2016-02-01 "{'Properties':{'Blob':'MI…nc','publicCertificateLocation':'CurrentUserMy'}}"
+
+
+Since ‘sites/publicCertificates’ is an ARM resource, you can call other standard ARM APIs to perform CRUD operations.
+
+List all public certificates inside an App Service:
+ARMClient GET https://management.azure.com/subscriptions/fb2c25dc-6bab-45c4-8cc9-cece7c42a95a/resourcegroups/publiccertificaterg/providers/Microsoft.Web/sites/publiccertificatedemo/publicCertificates?api-version=2016-02-01
+
+Remove a specific public certificate:
+ARMClient DELETE https://management.azure.com/subscriptions/fb2c25dc-6bab-45c4-8cc9-cece7c42a95a/resourcegroups/publiccertificaterg/providers/Microsoft.Web/sites/publiccertificatedemo/publicCertificates/currentuser2?api-version=2016-02-01
+
+Please give this feature a try and let us know your thoughts. If you run into any issues or have any comments then please let us know on the App Service forum.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Here is a list of frequently asked questions designed to provide a better understanding of the Azure marketplace for Web
+
+
How do I submit my Web Application to Windows Web Application Gallery?
+A. You can submit your application here. Before you submit the application please read through the guidelines and process for submission in this article.
+
Why is Deployment option connected to a github repository when I deploy an application like WordPress from the marketplace?
+A. The deployment process for application from the marketplace uses a GIT deployment method. This makes it easier for app owners to push updates to the application as quickly as possible and have it available to Azure users. Hence we use a github repository configured by the app owner with the application code that is deployed during provisioning of the application.
+
How long does it take for the Web Application Gallery Team to validate the application?
+A. Once the application is submitted, it will take 3-5 business days for us to validate the application and send you the status.
+
How do I build a package for Web Application Gallery?
+A. Please refer to this article on how to to build a package for Azure marketplace.
+
How do I test my application for Windows App Gallery?
+A. Find the process to test your application in the following article.
+
Can I on-board a commercial application to the Azure marketplace?
+A. Yes. Commercial application are supported with Bring your own License model (BOYL). Here are two approaches on how to allow an azure user to acquire a license:
+
+
Approach 1 :
+
+
Ask customer to purchase an license from solution partner website directly.
+
Provision the application solution from the Azure Marketplace
+
When user views the app in the browser ask user to enter the license information
+
Solution partner API are called to validate the license key and allow the user to use the application solution as documented by the solution partner
+
+
+
Approach 2 :
+
+
Provision the application solution from the Azure Marketplace
+
When user views the app in the browser the app ask the user to provide the information needed to procure a license key from the run time experience using solution partners APIs.
+
+
+
+
+
An application was removed from the marketplace and how do I deploy the same solution?
+A. If an application is removed from the marketplace , this means it is no longer supported by the application owner in the marketplace. In such cases we remove the application if it does have support from the application owner to maintain fixes or issues. If you want to deploy the same application , you can. Follow these steps to do so :
+
+
Create an empty Web App and any additional resources such as MySQL , SQL DB etc that the application may need.
+
Access the web application file storage and deploy the code via FTP or GIT.
+
Browse the application and complete the installation of the application based on the documentation provided in the application framework documentation.
+
If you run into issues , please report these issues in the community forums for the application being used .
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
This month we shipped improvements to the overview blade, a new unified create experience for both Windows and Linux based apps as well a new recommendation history UX.
+
New App Service Overview blade
+The overview blade for Web, Mobile and API apps has been overhauled with new charting controls and performance improvements, this should make browsing through your apps faster. The new charts integrate nicely with Azure Monitor and are perfect for pinning into custom dashboards.
+
+
+
Integrated create experience for Windows and Linux based apps
+With this update you can now choose the OS of the App Service plan used to host your app. Learn more about Web App on Linux.
+
+
+
App Service Advisor recommendation history
+App Service Advisor provides proactive recommendations on how to solve problems with your application. We have revamped this UI to also include a history of the recommendations that have triggered in the past.
+
+
+
+If you have any questions about any of this features or App Service in general be sure to check our forums in MSDN and Stack Overflow.
+
+For any feature requests or ideas check out our User Voice
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Last week, we open sourced an early preview version of our new Durable Task Framework extension for Azure Functions (also referred to as Durable Functions) and we now have instructions on how to set it up to test both locally and on Azure. We’re really excited about this binding and expect it to make a difference a lot of scenarios including complex chaining scenarios, fan in/fan out patterns, stateful actors, and scenarios with long callbacks.
+
Introducing Durable Functions
+Durable Functions is actually just us doing the work of setting up the Durable Task Framework and managing it for you, at scale. Durable Task Framework was designed to allow you to write code based orchestrations based on async/await in C#. This enabled the following:
+
+
Definition of code in simple C# code
+
Automatic persistence and check-pointing of program state
+
Versioning of orchestrations and activities
+
Async timers, orchestration composition,
+
+With Durable Functions, we let you write orchestrators and activities as Functions. Orchestrators can call Activity Functions and wait for an external event. Activity Functions can be written in any language and don’t have any restrictions on them that normal functions don’t have. Combined, this functionality allows a lot of complex patterns to be expressed via code. For instance, the code below will fan out and call various Activity Functions, wait for them all to complete, and then allow you to sum the results (fan in). This pattern was possible before, but involved a lot more code that was unrelated to the business logic.
+
+[code lang="csharp" highlight="18,23"]#r "Microsoft.Azure.WebJobs.Extensions.DurableTask"
+
+public static async Task<long> Run(DurableOrchestrationContext backupContext)
+{
+ string rootDirectory = backupContext.GetInput<string>();
+ if (string.IsNullOrEmpty(rootDirectory))
+ {
+ rootDirectory = Environment.CurrentDirectory;
+ }
+
+ string[] files = await backupContext.CallFunctionAsync<string[]>(
+ "E2_GetFileList",
+ rootDirectory);
+
+ var tasks = new Task<long>[files.Length];
+ for (int i = 0; i < files.Length; i++)
+ {
+ tasks[i] = backupContext.CallFunctionAsync<long>(
+ "E2_CopyFileToBlob",
+ files[i]);
+ }
+
+ await Task.WhenAll(tasks);
+
+ long totalBytes = tasks.Sum(t => t.Result);
+ return totalBytes;
+}
+[/code]
+
+In the above code, you can see the highlighted lines fanning out and calling many Functions (18), and then waiting for them all to complete on the second highlighted line (23).
+
+
Getting started
+This is not a feature for everyone to try. It involves quite a lot of set up and is not very user-friendly yet. We recommend using VS and the local tooling to get started as it is the easiest way, but it requires installing the latest update from VS and the newest Functions tooling, which can take some time to set up. You can find the full instructions on how to get started on the documentation page. Note that the documentation is currently on GitHub but will move to docs.microsoft.com very soon.
+
+If you encounter any issues or have any feedback, please submit it on the github repo.
+
Roadmap
+There are a few things we’re still working on before it will be available for a beta quality preview. We’ll blog again once it’s available for a wider preview. Mainly, we are already planning on adding:
+
+
Templates for all the primary scenarios
+
Scaling support in Consumption Plan (will not scale properly today)
+
Automatic installation (no dragging/dropping zip files)
+
+We hope to make progress on this during the rest of the summer.
+
What’s next?
+For the brave, please try it out. Your feedback will shape the future of this feature. We think having built in support for Functions to call other Functions and orchestrate a set of Functions is a very big step forward for Azure Functions and serverless in general, but want to take our time to make sure we get the model right and the experience of managing it nice and polished.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+Azure App Service has updated the PHP stacks to the latest available versions. For information on the changes in the new versions, please see the change logs on the PHP website.
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
I am unable to purchase an SSL certificate or App Service certificate ?
+This could be caused due to one of the following reasons:
+
+
App Service plan is Free or Shared pricing plans. We do not support SSL for these pricing tiers.
+
Subscription does not have a valid credit card
+
Subscription offer does not support purchase an App Service certificate such as Microsoft Student offer
+
Subscription has hit the maximum limit of purchases allowed on a subscription
+
App Service certificate was marked as fraud. You will see this error “Your certificate has been flagged for possible fraud. The request is currently under review. If the certificate does not become usable within 24 hours”
+
+
+Try any of these solutions based on the cause
+
+
Upgrade App Service plan to Standard Pricing tier for Web App
+
Add a valid credit card to your subscription if you don’t have one
+
If you are using Microsoft Student subscription or other Azure subscriptions where App Service certificate is not supported, please upgrade your subscription
+
App Service Certificates has a limit of 10 certificate purchases for Pay-As-Go and EA subscriptions types and for other subscription types the limit is 3. To increase the limit Kindly share the following details with us if you want to increase the purchase limit on your subscription for certificates:
+
+
Please articulate the business reason for increasing the purchase limit on your subscription.
+
Monthly spending cap on this subscription if any
+
Does the subscription have a valid credit card associated with the subscription
+
+
+
+We shall review and evaluate your business needs internally to either approve or reject your request provided there are no other constraints to meet these needs for you.
+
+
If the certificate is marked as Fraud and has not been resolved after 24 hours , then follow the steps below :
+
Click on Email Instructions which will send an email to GoDaddy to resolve the issue
+
+
+
+
When does my certificate get renewed?
+App Service certificates are valid for one year. If Auto Renew is on for an ASC then it will be renewed automatically before it expires and just like ReKey operation, the linked App Service Apps will be moved to the new certificate. You can change this setting by clicking on ‘Auto Renew Settings’ which is on by default. You can also manually renew a certificate by clicking on Manual Renew irrespective of the current Auto Renew setting if the certificate expiration is within 90 days.
+
How can I Rekey and/or ReSync my app service certificate?
+In order to stay compliant, many web companies need to rotate their certificates periodically. Also if a customer believes that his certificate has been compromised then he should rotate the certificate as soon as possible to minimize likelihood of the stolen certificate being used for malicious purposes. Traditionally, this requires obtaining a new certificate from the CA which is as complicated as buying a new one. Once a new certificate is created, you need to update all App Service Apps one by one manually. With ASC, we support one click ReKey. ASC allows you to ReKey a certificate unlimited number of times during its lifetime for free.
+
+ Using Rekey and Sync option in the portal : This blade displays the current sync state. You can see the thumbprint of ASC along with the thumbprints of all App Service linked certificates. When these certificates are in sync, all thumbprints will match and when they are out of sync, one or more linked certificate thumbprints will be different from the ASC thumbprint. In order to rotate the certificate, click ReKey at the top. The ASC status will move to Rekey Certificate which may take 5-10 minutes. You dont have to click on Sync since a background task runs every 8 hours to sync the changes in the certificate. To force a sync , you can click on the Sync button .
+
+
I see certificate errors shown when enforcing HTTPS?
+
If your web app gives you certificate validation errors, it could be due to :
+
+
Using a self-signed certificate : In this case avoid using Self signed certificate since we cannot verify the domain ownership . This is not supported with Azure web apps
+
Missing intermediate certificates when you export your certificate to the PFX file : In this case , recreate the PFX file and follow guidance here to make sure intermediate certiificates are also included when exporting it in PFX format.
+
Domain host name is not added to the Web app: Please add the domain hostname to your web app as per instructions here
+
If using App Service certificate domain verification is not completed : In this case , your certificate is not ready to be used. Please complete domain verification step as described here.
+
+
Can I get the intermediate certificates for mysite.azurewebsites.net
+We support HTTPS on *.azurewebsites.net domain name. Since this domain is owned by App Service Team , we do not share the certificate information with users for security reasons. We recommend to use a custom domain and bring your own certificate for a production application.
+
Domain verification is not working for App service certificate ?
+We provide alternate solution to manually verify your domain . Manual verification lets you verify domain ownership through your DNS configuration by adding a TXT record.
+
+Follow these steps to complete Manual verification :
+
+
Go to the Domain Name Service (DNS) provider for your domain name
+
+
+
Add a Txt record for your domain with value of the domain token showed in the portal .
+
+Wait a few minutes for DNS propagation to take place and click on Refresh button to trigger the verification.
+
+Alternate method to manually verify is the Html Web Page method which can be used to allow the certificate authority to confirm the domain ownership of the domain the certificate is issued for.
+
+
Create an HTML filenamed {Domain Verification Token}.html.
+
Content of this file should be the value of Domain Verification Token.
+
Upload this fileat the root of the web server hosting your domain
+
Click on Refresh button to check the Certificate status. It might take few minutes for verification to complete.
+
+For example, if you are buying a standard certificate for azure.com with Domain Verification Token ‘1234abcd’ then a web request made to http://azure.com/1234abcd.html should return 1234abcd.
+
+Important notice : A certificate order has only 15 days to complete domain verification operation, after 15 days the certificate is denied by the certificate authority, you are not charged for the certificate. Please delete this certificate and try again.
+
My SSL certificate is not being auto-renewed ?
+All App Service certificates issued prior to March 31st 2017 will receive an email to re-verify their domain at the time of renewal even if the auto-renewal is enabled for your certificate.This is a result of change in GoDaddy policy. Please check your email and complete this one-time domain verification to continue to auto-renew the SSL certificate. Also , note that GoDaddy does require you to verify your domain once every three years and you will receive a email once every three years to verify your domain.
+
Can I bring my own SSL certificate and how do I upload/configure it for my web app?
My App Service certificate is flagged for fraud. How do I resolve this?
+
During the domain verification of an App Service certificate purchase, you might see the following message:
+
“Your certificate has been flagged for possible fraud. The request is currently under review. If the certificate does not become usable within 24 hours, please contact Azure Support.”
+
As the message indicates, this fraud verification process might take up to 24 hours to complete. During this time, you'll continue to see the message. If the certificate is marked as Fraud and has not been resolved after 24 hours , then follow the steps below :
Click on Email Instructions which will send an email to GoDaddy to resolve the issue .
+
+
My App Service Certificate is still showing old secret value. How can I force a sync with the new secret in my Key Vault’ ?
+You can rekey your certificate using a new private key by following the details instructions in this article.
+
How do I buy EV SSL for using with Azure web app
+App Service certificate does not support purchasing EV SSL from Azure portal. But there are other options to use EV SSL with Web apps. For details , click here
+
Can I export my App Service certificate for use with other Azure services such as Cloud Services and so forth?
+We've gotten a lot of feedback from customers asking for this ability, so we now allow you to export your certificate as a PFX file so that you can use it across multiple subscriptions and Azure services. Seethis blog postfor more information.
+
Can I export my App Service certificate to be used outside of Azure, such as for a website hosted elsewhere?
+App Service Certificates can be used for any Azure or non-Azure Services and is not limited to App Services. To do so , you need to create a local PFX copy of an App Service certificate that you can use it anywhere you want. For more information, read Creating a local PFX copy of an App Service Certificate.
+
Can I use my App Service certificate in a different subscription in Azure?
+You can migrate your App Service Certificate within the Azure portal. You can also export it as a PFX file for use in another subscription. Seethis blog postfor more information.
+
I have a Free or a DreamSpark Azure subscription. Can I purchase an App Service certificate with my credits?
+Because Free and DreamSpark Azure credits are free credits, they cannot be used to purchase App Service certificates.
+
Can I get a refund if I purchase an SSL certificate and then decide that I no longer need it?
+Unfortunately, we cannot refund you on the purchase of an SSL certificate.
+
How do I update an SNI or IP based SSL binding on web app ?
+Note : When the binding is updated , please wait for 24 hours for the change to reflect in the Azure portal . To avoid downtime with your web app , make sure you updated the binding for SSL at least a week prior to the expiration of your current SSL certificate.
+Login to the Azure portal and select your web app. To update and SSL binding :
+
+
Upload a new certificate
+
Click "Add binding" in SSL certificates setting for your web app
+
Select your domain
+
Select your certificate
+
Click Add binding. Note that by adding an SSL binding with a hostname used in another binding will override the existing binding.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
App Service domains (preview) simplifies to create and manage domains for various Azure services. App Service domains leverages Azure DNS for hosting the domain and GoDaddy as the domain registrar.In addition to the domain registration fee, usage charges for Azure DNS apply. For information, seeAzure DNS Pricing.
+
This tutorial shows you how to buy an App Service domain and assign DNS names a Virtual machine and Azure Storage
+
Sign in to Azure
+
Open theAzure portaland sign in with your Azure account.
+
Navigate to the app in the Azure portal
+
From the left menu, selectNew -> Everything -> App Service Domain (preview)
+
+
Purchase a domain
+
In theApp Service Domainpage, in theSearch for domainbox, type the domain name you want to buy and typeEnter. The suggested available domains are shown just below the text box. Select one or more domains you want to buy.
+
+
Click theContact Informationand fill out the domain's contact information form. When finished, clickOKto return to the App Service Domain page. Next, select the desired options for your domain. See the following table for explanations:
+
+
+
+
Setting
+
Suggested Value
+
Description
+
+
+
+
+
Subscription
+
Pay-As-You-Go
+
Select aSubscription. If you have multiple subscriptions, choose the appropriate subscription.
+
+
+
Contact Information
+
Enter your contact information such as address, phone number etc ..
+
Fill out the domain's contact information form. When finished, click OK to return to the App Service Domain page.
+
+
+
Resource Group
+
myprojectgroup
+
Enter aresource group. A resource group is a logical container into which Azure resources like web apps, databases that is deployed and managed. You can create a resource group or use an existing one
+
+
+
Auto renew
+
Enable
+
Renews your App Service Domain automatically every year. Your credit card is charged the same purchase price at the time of renewal.
+
+
+
Privacy protection
+
Enable
+
Opt in to "Privacy protection", which is included in the purchase pricefor free(except for top-level domains whose registry do not support privacy protection, such as.co.in,.co.uk, and so on).
+
+
+
Accept terms and purchase
+
Accept
+
Click Legal Terms to review the terms and the charges, then click Buy.
+
+
+
+
Assign domain to Azure Virtual machine
+Resource Manager VMs can have a Public IP. A VM with a Public IP address may also be behind a load balancer. You can create a DNS A or CNAME record for the Public address. This custom name can be used to bypass the VIP on the load balancer.
+
+To verify if you VM has a public IP , go the resource group used by the VM to see if you have a resource "Public IP address" .
+
+
+
+You can get the IP address by selecting the Public IP address resource or select your Virtual machine to get the IP address
+
+
+
+Select your domain and choose DNS Zone setting
+
+
+
+Click on Add a Record Set . Add an A record for your Public IP configured to a subdomain alias such as www or blog asshown below. Configure your TTL setting on when your domain should resolve to the new domain hosting service.
+
+Enter your domain in a browser address bar based on your TTL configuration.
+
Add Custom domain for Azure storage
+Create an App Service Domain . Once provisioned , select DNS Zone setting and Add a record set .
+
+Create a new CNAME record and provide a subdomain alias such aswwworimages. Then provide a host name, which is your Blob service endpoint, in the formatmy-storage-account-name.blob.core.windows.net(wheremy-storage-account-nameis the name of your storage account).
+
+
+
+Go to your storage resource in the Azure portal and select Custom Domain setting. In the text box on theCustom domainblade in theAzure portal, enter the name of your custom domain, including the subdomain. For example, if your domain isexample.comand your subdomain alias iswww, enterwww.example.com. If your subdomain isimages, enterimages.contoso.com. The subdomain isrequired.
+
+
+
+Click on Save. Access your files on Azure storage using the custom domain.
+
Auto Renew your Domain
+You can change your billing setup for your domain registration anytime to either enable or disable auto-renew by selecting Domain Renewal setting
+
+
+
+App Service domains can be used to setup domain for other Azure services as stated in this article.
+
+Note : The hostname bindings setting only shows Web Apps and Traffic Manager if confugred to your domain for now. Your VM or Storage or any other Azure service using this domain will not show up in hostname binding setting. We will continue to work on improving this experience to display other services assigned to the domain.
+
+
+Submit your ideas/feedback in UserVoice. Please add [Domain] at the beginning of the title.
+
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+The ability to buy and assign custom domains to you App Service apps has existed in the portal for some time, however we have now extended those domain to be full on managed resources with their own UX independent of the app.
+
+App Service Domains are now also backed by Azure DNS making it easier to use App Service Domains with IaaS instances, Traffic Manager Azure CDN. Learn more about App Service Domains
+
+
+
+
+If you have any questions about any of this features or App Service in general be sure to check our forums inMSDNandStack Overflow.
+
+For any feature requests or ideas check out ourUser Voice
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Here are most frequent questions asked about App Service domains .
+
Custom Domains
+
How do I resolve 404 error "Web Site not found" when I browse my site ?
+You are seeing this error due to one of the reasons listed below :
+
+
The custom domain configured is missing a CNAME and/or A record . To configure the domain to your app, see how to map an existing domain .
+
+
If you added an A record , make sure a TXT record is also added. For more details , see here
+
+
+
The browser client might still be caching the old IP address for your domain. Clear the cache by running the command ipconfig /flushdns . Verify your domain is pointing to the web app IP address using WhatsmyDNS.net .
+
+
I am unable to add a new sub-domain ?
+One of the following reasons might be preventing you from purchasing a domain
+
+
Check you have permissions to modify the web app and add a sub domain hostname
+
You may have reached the max limit for subdomains . You can add max of 500 hostnames to your web app.
+
+
You may have reached max limit for sub-domains if you are using GoDaddy domain hosting. The current limitation if using GoDaddy is 100. If you need more sub-domains , you may choose to migrate to Azure DNS
+
+
+
+
Can I move my web app with a custom domain to another subscription or from ASE V1 to ASE V2?
+Yes you can move your web app across subscriptions . Follow the guidance in How to move resources in Azure . There are a few limitations when moving the web app , click here to view the limitations.
+
+For domains attached to your web app , if they are already added to your web app with a hostname binding then after moving the web app you should see the same host name binding within custom domains setting. No additional steps needed here.
+
Unable to add custom domain to my Web app ?
+This could be due one of the following reasons:
+
+
You don’t have permission to add a hostname : Check with subscription admin to make sure you have a permissions to add a hostname
+
Your domain ownership could not be verified : If domain ownership is failing , verify if your CNAME or A record are configured correctly . To map custom domain to web app , create either a CNAME or A Record . If you want to use root domain , you must use A and TXT records as well
+
Your domain is not available to use : You can use the custom domain with one web app , say for example www.mydomain.com can be added to one azure web app . In order to use the same the domain with another web app , you need to use another subdomain say xyz.mydomain.com but you CANNOT use www.mydomain.com .
+
+
+
You see the error "The DNS record could not be located"
+One of the reasons could be causing the issue:
+
+
TTL live has not expired. Check you DNS configuration for your domain what TTL is and wait it out.
+
DNS configuration is not right
+
+Try one of these solutions to resolve the issue
+
+
Wait for 48 hours and this should automatically resolve.
+
If you can modify the TTL setting in your DNS configuration , go ahead and make the change to 5 minutes or so to see if this resolves the issue
+
Verify your domain is pointing to the web app IP address using net. If not fix the A record to be configured to the right IP address of the web app
+
+
App Service Domains
+
+
I am unable to purchase a new Domain ?
+One of the following reasons might be preventing you from purchasing a domain
+
+
Check you credit card on the Azure subscription is still valid
+
If you are not the subscription owner , check you have permissions to purchase a new domain. (i.e Contributor or Owner roles )
+
You may have reached the limit to purchasing domains on your subscription. The current limit is 20.
+
+
Do I have to configure my custom domain for my website once I buy it?
+When you purchase a domain from the Azure portal, the App Service application is automatically configured to use that custom domain. You don't have to take any additional steps. Watch how to configure domain on Channel9.
+
You domain is no longer visible in the Azure portal or Domain was accidentally deleted
+The domain may have been accidentally deleted by the owner of the subscription. If your domain was deleted less than 7 days ago , the domain has not yet started the deletion process. Hence you can buy the same domain again on Azure portal under the same subscription (make sure to type the exact domain name in search text box). You will not be charged again for this domain.
+
+If the domain was deleted more than 7 days ago , please contact Microsoft Azure support for assistance to restore the domain.
+
Can I use a domain purchased in the Azure portal to point to an Azure IaaS VM instead?
+You domain is registered with GoDaddy service but hosted on Azure DNS
+
I have auto-renew enabled but still received a renewal notice for my domain via email . What should I do ?
+You do not need to take any action in this case if you have auto -renew enabled . The notice email if to just inform you that the domain is close to expiring and to renew manually if auto-renew is not enabled.
+
Will I be charged for Azure DNS hosting my domain ?
+The initial cost of domain purchase applies to domain registration only. In addition to the registration cost , there will be incurring charges for Azure DNS based on your usage. See Azure DNS pricing for more details.
+
I purchased my domain earlier from the Azure portal and want to move from GoDaddy hosting to Azure DNS hosting . How can I do this ?
+It is not mandatory to migrate to Azure DNS hosting. If you do wish to migrate to Azure DNS , you will see a message in domain management experience within the Azure portal about next steps to move to Azure DNS. Migration from GoDaddy hosting to Azure DNS is a few clicks away and seamless as long as the domain was purchased from App Service.
+
I would like to purchase my domain from App Service Domain but can I host my domain on GoDaddy instead of Azure DNS?
+For every new App Service domain purchased in the portal since July 24 2017 , will be hosted on Azure DNS. If you prefer to choose a different hosting provider , you need to go to their website to procure domain hosting solution.
+
Do I have to pay for privacy protection for my domain?
+When you purchase a domain through the Azure portal, you can choose to add privacy at no additional cost. This is one of the benefits of purchasing your domain through Azure App Service.
+
If I decide I no longer want my domain, can I get my money back?
+When you purchase a domain, you are not charged for a period of 5 days, during which time you can decide that you do not want the domain. If you do decide you don't want the domain within that 5-day period, you will not be charged. (.uk domains are an exception to this. If you purchase a .uk domain, you will be charged immediately and you cannot be refunded.)
+
Can I use the domain in another Azure App Service app in my subscription?
+Yes. When you access the Custom Domains and SSL blade in the Azure portal, you will see any domains that you have purchased and you can configure your app to use any of those domains.
+
Can I transfer a domain from one subscription to another subscription?
+You can move a domain to another subscription/resource group by using 'Move-AzureRmResource' PowerShell cmdlet.
+
How can I manage my custom domain if I don't currently have an Azure App Service app that is not a free app?
+You can manage your domain even if you don't have an App Service Web App. Domains can be used for Azure services like Virtual machine, Storage etc . If you intend to use the domain for App Service Web Apps , then you need to include a Web App that is not on the Free App Service plan in order to bind the domain to your web app.
+
How can I transfer my domain out of Azure
+Follow the steps below to transfer out the domain
+
+
Login to Azure portal
+
Select your App Service domain that you wish to transfer out
+
Go to Advance management for the domain
+
Click your domain -> manage
+
Under "Additional Settings"
+a. Unlock your domain . Click on Edit for "Domain lock" and turn it Off.
+b. Click on Transfer domains away from Azure to follow instructions to transfer out .
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Today we are releasing a new tabbed experience for Azure Functions that lets you quickly navigate between multiple features when you are configuring your application.
This new experience was developed as part of the Azure Functions UX open source project with input from Azure Functions MVP community.
As part of the efforts to be more customer driven we also opened this feature up in preview through @azurefunctions
This feature is currently enabled for Function app settings, and API definition feature. We will be adding more items to this experience in the coming months.
Features that will open in a tab have a small decorator to indicate they will open in this tabbed experience.
If you have any questions about any of this features or App Service in general be sure to check our forums in MSDN and Stack Overflow.
For any feature requests or ideas check out our User Voice
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
We're excited to announce that Azure Functions tools for Visual Studio are out of preview! The tools are now included in the Azure workload of Visual Studio 2017 Update 3. Just update your existing VS 2017 installation to Update 3--there's no need to use the preview channel or manually install the Functions tooling extension.
+
+The tools support building and publishing a class library as the implementation of your functions. Configure bindings and triggers using attributes in your code, rather than a separate metadata file.
+
+To get started with the tools, check out these articles:
+
+Along with this release is the 1.0 version of the Azure Functions Core Tools. These are used by the Visual Studio tools when you run or debug a Function App locally. You can also use the Core Tools directly to retrieve app settings from Azure or publish your Function App. To learn more, see Run locally using the Azure Functions Core Tools.
+
+
+
What's new in this release
+If you've used the preview tooling, you've probably seen the package Microsoft.NET.Sdk.Functions. This package is automatically added by the New Function project template and ensures that generated files are always in sync with your code.
+
+In this release, only triggers are generated in function.json. There is a new property in function.json that tells the runtime to use .NET attributes for input and output bindings, rather than function.json configuration:
+
+[sourcecode language="plain"]
+"configurationSource": "attributes" // possible values are "attributes" or "config"
+[/sourcecode]
+
+If the value of configurationSource is attributes, then the contents of function.json cannot be changed after it is generated. That is because the Functions runtime uses attributes in the assembly to configure bindings and triggers. (If you’re wondering why some properties are still in function.json, it’s because the Scale Controller uses it to make scaling decisions on the Consumption plan.)
+
Functions project type
+The Functions project type is a .NET Standard class library though it currently targets net461. This is because the Azure Functions runtime does not yet take a dependency on the .NET Standard 2.0 facades that enable full framework support. Now that .NET Standard 2.0 is RTM, we will make this update in a future release. See Support .NET Standard 2.0 class libraries #1792.
+
+Once we have completed the Azure Functions port to .NET Core 2.0, the .NET Standard 2.0 target will become much more important. At that time, we will change the default in the Visual Studio New Project dialog.
+
Learn more
+We’ve seen a great response to our preview tooling and we’re excited to release this version.
+
To report bugs or file feature requests, please open an issue on the Azure-Functions GitHub repo. Please include “Visual Studio” in the issue title.
+
For technical questions, please post on the MSDN forums or StackOverflow. The entire Functions engineering team monitors these questions, so you’re sure to get an expert answer.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Many of you may be familiar with the Auto Heal feature which allows you to configure limits on your Web App for request count, slow requests, Http status codes, and memory usage. Many times when you are experiencing problems with your Web App that can include slow responses or a non-responsive site, a simple restart of the Web App can solve the problem.
+
+As a result, we are introducing Proactive Auto Heal to expand on the Auto Heal offering. Proactive Auto Heal will only take corrective actions for the sites that we have deemed to be in a bad state for which the best way to recover is to simply restart the Web App. In many situations, your site may go into a bad state, so we are taking this preventative action on your behalf so that ideally your customers will not experience any downtime.
+
+Let’s say you are running your site on multiple instances and one of your instances has a memory leak and is consuming most of the memory on that instance.
+
+
This could result in high latencies or unresponsiveness.
+
If you have another Web App running in the same server farm (sharing memory and CPU), the Web App that is hogging those underlying resources may cause problems for other Web Apps running on that instance.
+
With Proactive Auto Heal, the Web App that is taking up a lot of memory for example, would be restarted. If you have multiple instances, only the one in the bad state would be restarted.
+
+It will be automatically enabled for every site, but this will not affect Auto Heal rules that you have already set yourself, as those will take priority.
+
How does Proactive Auto Heal know when to restart my Web App?
+Curious about how this feature works behind the scenes? Proactive Auto Heal looks for Web Apps that breaks either of these rules:
+
+
Percent Memory Rule: This rule monitors the Web App’s process' private bytes to see if it exceeds 90% of the limit for over 30 seconds. The limit is determined from the amount of memory available for the process as outlined in the chart below. For example, for a 64 bit process on a Medium worker, it would be recycled if the private bytes went above 3.5GB * 90% = 3.15 GB for over 30 seconds.
+
+
+
+
+
Instance Size
+
Small
+
Small
+
Medium
+
Medium
+
Large
+
Large
+
+
+
Process Bitness
+
32
+
64
+
32
+
64
+
32
+
64
+
+
+
+
1.75GB
+
1.75GB
+
3.5GB
+
3.5GB
+
4GB
+
7GB
+
+
+
+
+
Percent Request Rule: This rule monitors requests that have taken longer than the time limit. It is broken when 80% (or more) of total number of requests have taken 200+ seconds. The rule only triggers when there have been at least 5 requests in a rolling time window of 120 seconds during which the rule is broken. To account for slow application starts (which can be mitigated with our Application Initialization Feature with Slots!), this rule is not active during the process warm up time.
+
+If either of the rules are broken, then the Web App will undergo a overlapped restart of the process. This is NOT an instance restart or an entire Web App restart. In the case when there are multi-instances, the rules are ONLY triggered for the particular instance on which the process breached the rule, leaving the rest of the instances unaffected.
+
+Additionally, to prevent too many restarts (due to the application itself or service related bugs), both rules will be auto-disabled for 3 hours if there are too many restarts detected in a small time window.
+
Opting Out
+Because we believe that most customers can benefit from Proactive Auto Heal, we have automatically enabled it by default, so you don’t have to worry about turning this on yourself or early wake up calls perform a manual restart of the process. However, we understand that some of you may be saying, “I don’t want you restarting my Web App!”. For example, this could be because you keep a lot of data in memory and do not want to unknowingly lose this data, which would happen when the process restarts. Here’s how you can opt out:
+
+
Go to portal.azure.com and go to your Web App for which you would like to disable the feature.
+
Under Settings go to Application Settings.
+
Under App Settings add “WEBSITE_PROACTIVE_AUTOHEAL_ENABLED” and set it to “False.”
+
That’s it! Proactive Auto Heal is disabled.
+
+
+
+If you later decide you would like to enable it again then you can either remove this App Setting or set it to “True”.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
With our latest UX deployment we introduced a new user experience to easily choose Docker images that are stored in an Azure Container Registry (ACR) repo. Moreover we offer you a single click continuous deployment experience using webhooks with the Preview SKUs of ACR.
+
+
+
+
+
+For more information please check our intro doc at https://aka.ms/webapp-linux, for more information about continuous deployment for containers check the following article https://docs.microsoft.com/en-us/azure/app-service-web/app-service-linux-ci-cd
+
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
With both App Service for Windows and Linux today , setting up and configuration of your WordPress app is different in some way based on whether you are using Linux vs Windows . The matrix below can help guide your the appropriate documentation and steps for your WordPress app
+
+
+
Use the Azure Marketplace Template for WordPress on Linux
+
+This template also creates a database for your Web App based on your database provider choice.
+
+
+
How do I modify PHP configuration
+
Add a .user.ini to site/wwwroot folder and update PHP configuration .
+
Use .htaccess to update PHP configuration if using PHP built-in image or custom image with Apache server
+
Use .htaccess to update PHP configuration if using PHP built-in image or custom image with Apache server
+
+If you are using your own docker image , make the appropriate changes based on your server for example ngnix
+
+
+
How do I debug WordPress
+
WordPress has debugging Capability . For more information , click here
Choose Linux if you are using built-in PHP . OR You can bring your own custom image using Web App for Containers
+
+
+
Create a database for your app based on the database provider you have selected
+
Migrate your database , for more information click this link
+
Copy all your files to Azure web app using FTP or Git
+
Update wp-config.php to point to the desired database for the azure web app
+
If your wp-config.php files has any hard-coded paths please remove them or update them to use
+
+
/home/site/wwwroot (Linux)
+
D:\home\site\wwwroot ( Windows)
+
+
+
WordPress stored the URL of your web app in the database. Make sure you update the database to use your-site-name.azurewebsites.net or configure the appropriate domain to your app
For more information , click this link . Here the continuous integration refers to only you application code.
+
For more information , click this link. This depends on how you image is built :
+
+
If your image has your application code included , then CI/CD refers to updates to your docker image
+
If your image has only server components like apache , php etc and application code is on VSTS/Github ; then there are two deployments that need to configured for CI/CD : one for your application code and one for your docker image. Refer to this article
For more information click this link
+Note:When using Web App for containers you must use the App Settings WEBSITES_ENABLE_APP_SERVICE_STORAGE = true in order to use App Service storage which will allows file changes to persists and be shared by all the instances
+
+
+
Performance Enhancements
+
+
+
WP Super cache:It significantly improves site throughput and correctly handles comments submissions and other visitors’ actions.
+
Azure Redis cache :Azure redis cachecan also be integrated with WordPress with the help ofWP redis pluginto get better performance.
+
Static content Caching : Cache JS, CSS files
+
Server level caching :
+
+
For Windows App Service , you can use IIS output caching, click here.
+
For App Service on Linux , use caching on Apache . Click here
+
For Web App for Containers , you can include different types of caching within your custom image from local redis to APC or additional caching based on the server you use ( Nginx, Apache etc )
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+On Sept 06 we announce the GA for App Service on Linux and Web App for Containers. This includes new UI integration with Azure Container Registry as well as enabling container based CI/CD deployments.
+
+
+
Azure Functions UX improvements
+Browse Azure Function UI now includes the ability to filter and group Function apps as well as the ability to refresh the list:
+
+We also have a new native App Settings experience that leverages the new Azure Functions tabbed experience
+
New File System Storage UX
+The new view for file system quota provides more granular information on how this quota is calculated and per app file system usage breakdown. This UI is available for both App and App Service plans and can be found in the menu under Quotas or File system storage respectively.
+
+
+
IP Restrictions
+IP Restrictions lets you define an allowlist of IP Address that are granted access to your app. You can find this new feature in the menu under Networking>IP Restrictions
+
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
I’m very happy to announce mock API and HTTP request/response overrides in the Azure functions portal. This feature allows a function proxy to return sample data through a mock API, enabling development against a functions API endpoint without writing any code. Request/response overrides allows API data to be transformed in flight, enabling new API schemas to be supported without modifying a backend API.
+
+This functionality mirrors the existing request/response overrides and mocks previously only accessible through proxies.json
+
Examples
+The following example shows a mock API that mimics the "hello serverless" example. The example returns a static response while also inserting text from a request parameter.
+
+
+
+The next example performs a transform on requests as they're sent to jsonplaceholder.typicode.com. It changes all HTTP verbs to HTTP GET, and appends the request's verb to the response header.
+
+
+
Learn more
+We’ve seen a great response to the proxies preview and we're excited to continue releasing updates
+
To report bugs or file feature requests, please open an issue on theAzure-FunctionsGitHub repo. Please include “Proxies” in the issue title.
+
For technical questions, please post on theMSDN forumsorStackOverflow. The entire Functions engineering team monitors these questions, so you’re sure to get an expert answer.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Customers often ask us about the scalability/throughput limits of the consumption plan for Azure Functions. The short answer is always "it depends, what does your workload look like?". Today I want to talk about running high scale Event Hub / IOT Hub workloads on Functions and some key points to be aware of in order to maximize the performance you get from the platform.
+
+We partnered with the Azure CAT team to build a simple but representative event processing pipeline using Functions and Event Hubs, with telemetry going into Application Insights:
+
+
+
+The load generator (also running on Functions) writes batched messages to an ingestion event hub. These messages represent a set of readings from a given sensor. Functions picks up messages from the ingestion event hub, extracts individual readings from the batch and writes them to the target event hub, augmenting the messages with additional telemetry along the way. Two more functions within the same function app (on the consumption plan) each process the individual readings and send aggregated telemetry to App Insights.
+
Performance
+We ran the system under a target load of 100,000 events per second for a total of 9 days. Over that time the system processed a total of 76 billion events. We measured the e2e latency of the pipeline i.e. amount of time taken between writing the message to the ingestion hub and processing the message in the weather/seismic function. Here are the results:
+
E2E Latency Percentiles
+
+
+
+
+
+
P50
+
+
+
P90
+
+
+
P95
+
+
+
P99
+
+
+
P99.9
+
+
+
P99.99
+
+
+
Max
+
+
+
+
+
1,102.42ms
+
+
+
2,755.56ms
+
+
+
3,788.30ms
+
+
+
11,894.12ms
+
+
+
50,367.23ms
+
+
+
111,240.50ms
+
+
+
239,890.10ms
+
+
+
+
+
+In simple terms:
+
+
half of the messages were processed within 1.2 seconds of being written to the ingestion hub
+
nine out of ten messages were processed in under 3 seconds
+
999 out of 1000 messages were processed in under 1 minute
+
all messages were processed in under 5 minutes
+
+
Monitoring
+Azure Functions has two built in monitoring solutions - the WebJobs dashboard and Application Insights (integration between Azure Functions and App Insights is currently in preview). The dashboard was designed with longer running jobs in mind and isn't optimized for scenarios where there are 10,000+ function executions happening per second. Fortunately, App Insights is an incredibly robust telemetry system and we've made sure that it works great with Azure Functions in high scale scenarios.
+
+Turning on App insights is really easy - just add your instrumentation key to your function app and Azure Functions will start sending data to App Insights automatically. For more info see here.
+
+The Azure dashboard is highly customizable and App Insights has great support for pinning its visual components. It only took an hour or two to put together a pretty useful monitoring dashboard for this scenario:
+
+
Configuration
+We made some notable configuration choices to achieve this result:
+
+
the functions process messages in batches
+
the WebJobs dashboard is disabled in favor of using Application Insights for monitoring and telemetry
+
each event hub is configured with 100 partitions
+
data is sent to the event hubs without partition keys
+
events are serialized using protocol buffers
+
+See below for additional details on each of these.
+
Batching
+An event hub triggered function can be written to process single messages or batches of messages. The latter has much better performance characteristics. Lets take the splitter function as an example:
+
An array of events are passed to the function in one execution
+
An exception handling block wraps the processing of each event
+
+The array based approach performs better primarily due to per function execution overhead. The system performs a number of actions when invoking your function and those actions will only happen once for an array of events rather than once per event. Note: for JavaScript functions you'll need to explicitly set the cardinality property in your function.json to many in order to enable batching (e.g. see here).
+
+This approach to exception handling is important if you want to ensure you don't lose/skip messages. Typically you'll write your exception handler so that it stores the event that failed for later processing/analysis. This is important because Azure Functions does not have any built in dead lettering for Event Hubs.
+
WebJobs Dashboard
+As mentioned above, because we were using App Insights for monitoring we disabled the dashboard. To do this simply go to your application setting and remove the AzureWebJobsDashboard setting.
+
Partition Configuration
+Azure Functions uses the EventProcessorHost (for more info see here) provided in the Event Hubs SDK to process event hub messages. The way EventProcessorHost works is that each VM running your app acquires leases to some of the partitions, allowing it to process messages on those partitions. This means that if your event hub has only two partitions, only two VMs can process messages at any given time i.e. the partition count puts an upper limit on the scalability of your function.
+
+The basic and standard tiers for Event Hubs have a default limit of 32 partitions per event hub, but this limit can be increased if you contact billing support. By setting the event hubs to have 100 partitions, each function was able to run on 100 VMs simultaneously. We can see this if we look at one minute of telemetry, counting the number of unique VMs that executed the weather function:
+
+
+
+We can get an idea of how evenly the work was distributed over those 94 VMs with another simple query:
+
+
+
+
Partition Keys
+The event hubs programming guide has a good summary of partition keys and when you might want to use them. This scenario had no ordering or statefulness requirements so events were generated without partition keys. This increased the overall throughput and availability for the run.
+
Protocol Buffers
+If you're writing and reading 100,000+ events a second, you want the serialization and deserialization of those events to be as efficient as possible, both from the perspective of time taken to do the serialization step and also size on the wire. Protocol Buffers is a high performance serialization format that is easy to work with. Here's some example code deserializing and processing a batch of weather readings from an event:
+
if (sensorType == SensorType.Weather)
+{
+ var batch = WeatherReadingBatch.Parser.ParseFrom(sensorData.GetBytes());
+ var messages = batch.SensorReadings
+ .Select(reading => EnrichData(enqueuedTime, reading));
+ await WriteOutput(messages, sensorData.PartitionKey, outputWeatherData);
+}
+If you'd like to see the .proto file used for this scenario see here.
+
Cost
+The total cost of running the function app and its dependencies for the 9 day run was approximately $1200 USD. Here's what the cost per hour looks like for each service:
+
+
+
+
+
+
Service
+
+
+
Cost per Hour (USD)
+
+
+
+
+
Functions
+
+
+
$2.71
+
+
+
+
+
Storage
+
+
+
$1.80
+
+
+
+
+
Application Insights
+
+
+
$1.03
+
+
+
+
+
+A few important points to note:
+
+
This data does not include the cost of the load generator and Event Hubs as no effort was spent on optimizing these.
+
The Azure Storage cost is based on approximately 50 million transactions per hour. Almost all of these transactions are related to Event Hubs checkpointing.
+
The Application Insights cost is based on 450mb of data ingestion per hour.
+
+We can dive into function app cost in more detail by using the execution count and execution units data available via the Azure Monitor REST API (see here for more info). Querying for one hour of data, we get the following:
+
+
Function Execution Count: 6,500,012
+
Function Execution Units: 90,305,037,184
+
+Note that the function execution units here are measured in mb-milliseconds. To convert these into gb-seconds, divide by 1024000. Putting it altogether (pricing details for functions are here, simple program I wrote to assist is here):
+
+Cost per hour = (6,500,012 executions * ( $0.20 / 1,000,000 )) + ((90,305,037,184 units / (1024 * 1000)) * $0.000016) = $2.71 USD
+
Summary
+The consumption plan for Azure Functions is capable of scaling your app to run on hundreds of VMs, enabling high performance scenarios without having to reserve and pay for huge amounts of compute capacity up front. To learn more about Azure Functions and building cloud applications on serverless technology, start here.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
I’m excited to announce that we have ported Azure Functions to .NET Core 2.0! Both the runtime and the Azure Functions Core Tools are now cross-platform. Now, you can debug C# and JavaScript functions on a Mac or Linux using the Core Tools and Visual Studio Code. Both the runtime and the Core Tools are still in preview and we welcome your feedback!
+
+As this is a preview release, there are still a number of feature gaps. For more information, see Azure Functions runtime 2.0 known issues.
+
Running on your local machine
+To get the new version of the core tools, pull down the @core tag on npm:
+
npm i -g azure-functions-core-tools@core
+If you’re using Ubuntu, prefix the command above with "sudo."
+
+If you have problems with the npm install on Mac, use the following:
+
sudo npm i -g azure-functions-core-tools@core --unsafe-perm
+For the easiest installation, you must be running Node version 8.5 or higher. See instructions below for how to target a lower version.
+
+To create a new JavaScript HTTP-triggered function, do the following:
+
+Run the host. This automatically enables debugging with the Node port 5858:
+
func host start
+
+
+Open the folder in Visual Studio Code: code .
+
+In VSCode, set a breakpoint at the first line of the function, and attach the debugger (via F5 or the debug toolbar). Then, in a browser, navigate to the URL http://localhost:7071/api/HttpTriggerJavaScript?name=Functions%20Everywhere!
+
+You’ll then see the breakpoint being hit in VSCode!
+
+
+
+
JavaScript (Node versions prior to 8)
+After installing azure-functions-core-tools, run the following commands:
+
npm i -g node-pre-gyp
+cd %userprofile%/.azurefunctions/bin/workers/node/grpc
+node-pre-gyp install
+
+Once these tools are installed, you can use the instructions in the previous section to run and debug JavaScript functions.
+
C# .NET Standard 2.0 class library
+You can now run and debug C# functions on a Mac or Linux. The Microsoft.NET.Sdk.Functions is the package that identifies a project as Functions project to Visual Studio and generates function.json from attributes during build. Templates for C# class libraries aren’t yet available in the Core Tools, but you can get a sample from GitHub.
+
+To debug your C# functions, open the folder containing your .csproj in VS Code. Make sure you have installed the C# extension.
+
+
In the debug toolbar next to the play button, select Add Configuration
+
Select .NET Core as the environment, then .NET: Attach to local .NET Core Console App.
+
+This will generate a launch.json configuration for your project. Then, press F5 and select .NET Core Attach. Select the dotnet process with the command line Azure.Functions.Cli.dll host start.
+
+Browse to the URL http://localhost:7071/api/HttpTriggerCSharp?name=CSharpEverywhere!. You’ll then see your breakpoint hit in VSCode.
+
+
+
Visual Studio
+First, ensure you have downloaded the @core version of azure-functions-core-tools: npm i -g azure-functions-core-tools@core
+
+Then, add a new launch configuration for the 2.0 version of the Core Tools:
+
+
In project properties -> Debug, change Launch to Executable
+
For Executable, use %APPDATA%\npm\func.cmd
+
For Application Arguments, use host start
+
For working directory, use $(TargetDir)
+
+F5 will now launch the new version of the Azure Functions Core Tools.
+
+
+
Running Functions 2.0 in Azure
+You can also use the .NET Core 2.0 port in Azure by targeting the new Functions 2.0 preview runtime. To use it, select "beta" in Function app settings -> Runtime version. Alternatively, you can the app setting FUNCTIONS_EXTENSION_VERSION to the value beta. You will then see a different set of templates available in the Add New Function page.
+
+
+
+Since the 2.0 runtime is in preview, there may be breaking changes even in minor releases. So, the 2.0 runtime should not be used for production workloads.
+
+If you navigate to the root of you function app, you’ll see that you’re running the new version:
+
+
+
Connect with us
+We've seen a lot of excitement and interest, so we're looking forward to getting your feedback as we finalize the Functions 2.0 runtime.
+
+
To report bugs or file feature requests, please open an issue on the Azure-Functions GitHub repo.
+
For technical questions, please post on the MSDN forums or StackOverflow. The entire Functions engineering team monitors these questions, so you’re sure to get an expert answer.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
The following is a blog post written by one of our many amazing summer interns, Glenna. I had the pleasure of mentoring Glenna this past summer as she worked on a very exciting internship project: The Microsoft Graph bindings for Azure Functions, which was recently announced at Microsoft Ignite 2017. Glenna worked tirelessly on this project and was responsible for large parts of the implementation as well as presenting the project to her peers and local executives (and she did an excellent job at both). Unfortunately she had to head back to school before we could publish this post, but now that it's been productized and announced we are finally free to unleash it. :)
+Thank you Glenna for your awesome contributions to our team and to our customers. We can't wait to have you come back and join us full-time after your graduation!
+As an aside, it's very important to us on the Azure App Service team that our interns get to work on projects that are fun, challenging, have a legitimate business impact, and actually ship to production. The Microsoft Graph bindings and associated Azure Functions portal work is just one example among many others, and we're really excited to be able to finally showcase it.
+Here is Glenna in her own words (with a few edits from the team based on some changes that were made after she returned to school). Consider the content of this post as supplementary to our official documentation.
+
Personal Introduction
+
+
+My name is Glenna and I am a software engineering intern on the Azure Functions team in Redmond, WA. As I write this, I am finishing up my last day on my twelfth and final week at Microsoft. My internship was a truly incredible experience. I learned a great deal not just about specific programming languages, but also about good engineering design practices. I got to work on both the nuts and bolts of my features as well as the Azure Functions Portal UX and UI.
+
+I attend the University of Virginia in Charlottesville, Virginia. In May of 2018, I will graduate with a Bachelor of Science in Computer Science.
+
Introduction
+Microsoft Graph bindings extend the existing Microsoft Graph SDK and WebJobs framework to allow users easy access to Microsoft Graph data (emails, OneDrive files, events, etc.) from Azure Functions.
+
+By using the Office input, output, and trigger bindings, users can bind to user-defined types, primitives, or directly to Microsoft Graph SDK objects like WorkbookTables and Messages. These bindings handle Azure AD authentication, Azure AD token exchange, and token refresh, allowing users to focus on writing code that utilizes Microsoft Graph data.
+
Features
+Currently, the bindings can be grouped into four main categories:Excel, Outlook, OneDrive, and Webhooks.
+
Excel [Input + Output]
+The Excel binding allows users to read/write Excel workbooks and tables using different data types, like lists of user-defined types or 2D string arrays.
+
Outlook [Output]
+The Outlook binding is an output only binding, and allows users to send emails from their Office 365 email accounts.
+
OneDrive [Input + Output]
+The OneDrive binding allows users to read/write files stored in their OneDrive using several different data types (e.g. DriveItems and Streams).
+
Graph Webhooks [Trigger + Input + Output]
+There are two bindings associated with Graph webhooks: GraphWebhookTrigger and GraphWebhookSubscription.
+
GraphWebhookSubscription [Input + Output]
+The GraphWebhookSubscriptioninput binding allows the retrieval of Microsoft Graph webhook subscriptions that the function app has created. The GraphWebhookSubscriptionoutput binding handles webhook subscription creation, as well as renewal and deletion. Without renewal, most Microsoft Graph webhooks expire in 3 days. Deleting a webhook subscription removes the subscription from the Microsoft Graph account, as well as all references to that subscription in your Function app. Both the refresh and delete output bindings are best used in conjunction with the input binding, as they operate on current webhook subscription ids.
+
GraphWebhookTrigger [Trigger]
+The GraphWebhookTrigger binding allows users to subscribe to notifications about supported Microsoft Graph resources, including email messages, OneDrive root, contacts, and events.
+
+If you examine the wire protocol, the notification payload from Microsoft Graph is very lightweight; it only contains a webhook subscription ID and the subscribed resource. In order to provide detailed information to the function code, the webhook trigger internally uses a local store of webhook subscription data (stored by the GraphWebhookSubscription binding at subscription creation), maps the webhook subscription ID to a user, performs a silent GET request for the specified resource and transforms that payload into either a JSON object or a Microsoft Graph SDK type (e.g. Message, Contact) which can then be accessed directly by the function code.
+
Identity
+Actions mentioned can be performed using the current Office 365 user's identity, or using the Azure AD service principal identity of the function app. Which identity is used is up to the Function author. In order to authenticate against the Microsoft Graph as a specific user, either an ID token or an Azure AD Principal ID must be given to the binding. This identifier can come from a number of different sources. Examples of these sources include the currently authenticated Azure AD user (which can be captured from a session cookie or a bearer token), the content of an HTTP request, a queue, or an app setting.
+
Examples
+An easily imagined scenario for these bindings is a business owner with customers who subscribe to their monthly newsletter. Customers provide their names and email addresses, which then must be added to an Excel file of customers.
+
+Using the Excel output binding, the business owner can select which Excel table to modify.
+
+[caption id="attachment_5996" align="alignnone" width="997"] Excel output binding[/caption]
+
+The function code to append the Excel row is only a few lines long. In this example, the function receives a POST request with a user's name and email address and converts it into a custom EmailRow (POCO) type using the runtime's dynamic binding capabilities to remove the need for JSON manipulation.
+
+
usingSystem.Net;
+
+publicstaticasyncTaskRun(
+ HttpRequestMessagereq,
+ IAsyncCollector<EmailRow> outputTable)
+{
+ // Get request body
+ dynamicdata = await req.Content.ReadAsAsync<object>();
+
+ // Use body data to set row data
+ varoutput = newEmailRow {
+ Name = data?.name,
+ Email = data?.email
+ };
+ await outputTable.AddAsync(output);
+}
+
+publicclassEmailRow {
+ public stringName {get; set;}
+ public stringEmail {get; set;}
+}
+
+Every month, a timer trigger (or some other trigger type) fires and an email, the contents of which are determined by a OneDrive file, is sent out to each customer.
+
+The business owner can select the same Customers Excel file (Excel input binding)...
+
+[caption id="attachment_5995" align="alignnone" width="984"] Excel input binding[/caption]
+
+...determine which OneDrive file to get the email contents from (OneDrive input binding)...
+
+[caption id="attachment_6015" align="alignnone" width="978"] OneDrive input binding[/caption]
+
+...and indicate that they would like to send emails via the Outlook output binding.
+
+[caption id="attachment_6026" align="alignnone" width="993"] Outlook mail output binding[/caption]
+
+The code below quickly scans the Excel table and sends out one email per row (customer).
+
+
#r "Microsoft.Graph"
+
+using System;
+usingMicrosoft.Graph;
+
+// Send one email per customer
+publicstaticvoidRun(TimerInfomyTimer, TraceWriterlog,
+ List<EmailRow> inputTable, stringfile, ICollector<Message> emails)
+{
+ // Iterate over the rows of customers
+ foreach(var row in inputTable) {
+ varemail = newMessage {
+ Subject = "Monthly newsletter",
+ Body = newItemBody {
+ Content = file, //contents of email determined by OneDrive file
+ ContentType = BodyType.Html
+ },
+ ToRecipients = newRecipient[] {
+ newRecipient {
+ EmailAddress = newEmailAddress {
+ Address = row.Email,
+ Name = row.Name
+ }
+ }
+ }
+ };
+ emails.Add(email);
+ }
+}
+
+publicclassEmailRow {
+ public stringName { get; set; }
+ public stringEmail { get; set; }
+}
+
+The aforementioned goals can be accomplished using just a few lines of code.No manual data entry, no hardwiring, and no additional services.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
“What’s wrong with my Web App? My Web App is down!”
+
+
+These are tough questions that we know are frustrating for you. It is our priority to make sure that we figure out how to keep your Web App healthy with minimal downtime. However, in the cases where things do go wrong, the problem is that there could be many reasons why.
+
How do you know which of these generic potential issues could be the reason why your Web App is down?
+
Where do you start your troubleshooting process for your specific Web App?
+Many of you may be familiar with the Diagnose and Solve Support Center, our self-serve diagnostic experience that allows you to get a glimpse of how your Web App is performing. Since releasing that experience, we’ve been able to add and improve the detectors that we use to analyze the health of your Web App to perform more precise pattern analyses in an effort to pinpoint Web App errors and provide troubleshooting advice.
+
+As a result, today we are excited to announce the release of our new Diagnose and Solve Support Center (Preview) to help point out what’s wrong with your Web App and guide you to the right information to troubleshoot and ideally resolve the issue easier and quicker than before.
+
Getting Started with the New App Service Support Center
+To open the new App Service Support Center, click on “Diagnose and Solve problems” on the left-hand menu. Once in the new App Service Support Center homepage, there are several options.
+
First, you should ask yourself this question: Do you already know what’s wrong with your Web App?
+
+(Note: in this blog post, images will be expanded when clicked).
+
Performing a Health Checkup (Highly Recommended)
+If you’re not sure what’s wrong with your Web App, run our new Health Checkup feature by selecting the blue “Yes” button. Health Checkup will analyze your Web App to give you a quick, interactive overview that points out what’s healthy and what’s wrong, telling you where to look to investigate the issue.
+
+Once the Health Checkup report is generated, you can get a quick overview of the status of four different problem categories: Requests and Errors, Performance, CPU Usage, Memory Usage.
+
+[video width="1912" height="1092" mp4="media/2017/09/2017-09-29_11h03_03-online-video-cutter.com_.mp4" poster="media/2017/09/App-Service-Genie-Blog-Post-2.png" loop="true" autoplay="true"][/video]
+
+Highlights:
+
+
Quick Overview: red, orange, and green icons appear on the left side of each problem category to indicate the healthiness of that area. You can click on each tab to open up a graph showing more details.
+
View Full Report: this opens up more observations about the issue and suggested solutions as seen in the image below. You can investigate further by selecting the orange bars corresponding with periods of unhealthiness and expanding on observations by clicking "View Details" below. Suggested solutions would show up below the observations.
+
+
+
Selecting Tile Shortcuts
+If you already know what’s wrong with your Web App, you can investigate further by selecting the tile shortcut that corresponds to the problem category that you’re interested in. Currently, we have five problem scenarios for our tile shortcuts. (Note: Web App Restarted is the only scenario not covered by Health Checkup at the moment):
+
+
Web App Down
+
Web App Slow
+
High CPU Usage
+
High Memory Usage
+
Web App Restarted
+
+Let’s say you want to figure out why your Web App restarted. In the homepage, select the “Web App Restarted” tile. This will open a new tab with our Web App Restarted analysis.
+
+
+
One-Stop Shop for Additional Resources
+Now, on the right-hand column, we have compiled a list of help links to give you all easy access to variety of different resources with content that can help you troubleshoot your Web App. Just select the + sign next to each title to expand that selection.
+
+
+
+Here is a quick overview of the different Additional Resources categories:
+
+
Support Tools: additional troubleshooting tools
+
Premium Tools: more additional troubleshooting tools
+
FAQs: links to App Service articles that guide you through common troubleshooting scenarios
+
Resource Center: links to how-to articles and video walkthroughs for those needing a quick-start for App Service
+
Community: links to forums and other locations where you can get help from members of the App Service team and other community members
+
Recent Updates: convenient links to updates to Microsoft Azure services as well as stack specific updates
+
Contribute: link to our Github repository to assemble feedback for Support Center and allow for open source contributions
+
+
We need your feedback!
+In the coming months, we are planning on adding additional features with a goal that Support Center can guide you step-by-step for a holistic Web App troubleshooting experience. This means that the feedback that you leave is critical for us to determine which features are most relevant for you.
+
+Once Health Checkup is complete, you can leave your feedback in the inline textbox as seen below.
+
+
+
+Note: currently, this experience is only for App Service on Windows. Stay tuned!
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+We have shipped a few behind the scenes improvement to the Azure Functions UX that improves performance up to 40% in some instances. This should result in snappier navigation and more responsive interactions.
+
+
+
+If you have any questions about any of this features or App Service in general be sure to check our forums in MSDN and Stack Overflow.
+
+For any feature requests or ideas check out our User Voice
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
We’re excited to announce two new preview features in Azure Functions:
+
+
Durable Functions: A framework that makes it easy to orchestrate multiple functions and manage state for your serverless apps.
+
Binding extensibility: A capability that allows you to create your own reusable serverless components that can be used from any supported language.
+
+
Durable Functions
+In serverless functions, as with many application frameworks, it’s commonly recommended to write your code to be stateless, and this is the best practice. What is often not discussed in detail, though, is how one should manage that state. For trivial scenarios like just standard user data, databases are an obvious option, or for messaging between applications, a queue service is sufficient. However, what if your application has need for a more complex, stateful orchestration of multiple components? Without better tools, you’re left to figure out the right way to combine those pieces. This is the problem that the Durable Functions feature seeks to solve; letting developers abstract away the management of state for complex, stateful orchestration. Today, we’re happy to announce that Durable Functions is now in preview.
+
+Durable Functions builds on the Durable Task Framework, which was designed to allow developers to write code based orchestrations using async/await pattern in C#. This enabled the following:
+
+
Expression of tasks in simple C# code
+
Automatic persistence and check-pointing of program state
+
Versioning of orchestrations and activities
+
Async timers, orchestration composition
+
+With Durable Functions, we let you write orchestrators and activities as Functions. Orchestrators can call Activity Functions, other sub-orchestrations, and wait for an external event. Combined, this functionality allows a lot of complex patterns to be expressed via code. For instance, the code below will fan out and call various Activity Functions, wait for them all to complete, and then allow you to sum the results (fan in). This pattern was possible before but involved a lot more setup and management code that was unrelated to the business logic.
+
+In the above code, you can see the first set of bold code fanning out and calling many Functions, and then the later bold line waiting for them all to complete.
+
What’s happened since alpha?
+Since we initially released the alpha preview we’ve seen lots of great community interest and folks experimenting with Durable Functions. In addition to all that feedback, we’ve also been working on a few important enhancements. You can see all the work highlighted on the GitHub repo for Durable Functions extension. Here are some highlights:
+
+Developers are building increasingly complex serverless applications and need better mechanisms for code reuse. Triggers and bindings allow developers to focus on their code and let Azure Functions handle all the logistics of connecting to other services, in a way “reusing” the glue code that we have already written for you. We are now providing a mechanism using which you can author your own custom bindings for Azure Functions, providing more avenues for reuse. This mechanism (binding extensibility) is a feature of the 2.0 Functions runtime. In fact, Durable Functions is authored as a custom binding for Azure Functions.
+
+Bindings allow you to create reusable serverless components that can be used from any supported language. If you host a developer service, bindings will make it easy for Functions developers to use your product. Developers can also create reusable packages and host them in a central repository, just like a library or SDK.
+
+Binding extensibility allows you to provide a declarative interface for an SDK. For instance, we have a sample Slack output binding that sends a slack message when a customer uses a [Slack] attribute (or the equivalent in function.json):
+
+C#
+
module.exports = function (context, req) {
+ context.log('JS HTTP function processed a request: ' + req.body.text);
+
+ context.bindings.slackMessage = req.body;
+ context.done();
+};
+
+
Creating a custom binding
+Currently, extensions can only be authored in C# but can be consumed from any supported language. To get started, please check out the sample WebJobsExtensionSamples, which has a detailed readme on how to get started. There is also a Slack output binding sample.
+
+Reference documentation is available on our wiki: Creating custom input and output bindings.
+
Custom triggers
+For custom triggers, we plan to offer integration with Azure Event Grid. Stay tuned for more details on this.
+
Next steps
+Please try out Durable Functions and binding extensibility and provide feedback on the experience. We encourage you to try these features in all kinds of interesting ways and help us make them work even better when we GA. As always, we look forward to hearing from you through our Forums, StackOverFlow, or Uservoice.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Strongly Recommended to Upgrade to PHP 5.6, 7.0, or 7.1
+Because the PHP Group stated that PHP 5.5 is no longer supported, there won’t be any more updates to that version, including security fixes. To avoid the potential for security issues on App Service, we plan to retire our support of PHP 5.5 in January 2018. Currently, we support PHP 5.6, 7.0 and 7.1.
+This retirement will impact all customers who are running their Web App on the PHP 5.5 runtime (unless you are using a custom PHP runtime). We strongly recommend that you upgrade to a supported version of PHP because your Web App will be auto-moved to PHP 5.6. For more information on how to migrate from PHP 5.5 to another version of PHP, please review the documentation on the Appendices webpage on PHP.net.
+Although we’re removing the PHP 5.5 runtime from the platform, we’re aware that some applications are complex and may be tied to a specific PHP runtime version. In order to continue to support your PHP 5.5 applications, it’s possible to remain on PHP 5.5 runtime. For more information, please visit the "How to: Use a custom PHP runtime" section of the Configure PHP in Azure App Service Web Apps documentation webpage.
+
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+With our most recent release of Kudu, we have introduced a new deployment option for web apps, Azure Functions and WebJobs: zip push deployment. Zipdeploy combines the simplicity of Kudu’s zip API with the flexibility and robustness of Kudu’s deployment features, like deletion of unused files from old deployments, history tracking and Auto Swap support.
+
Why a new API?
+Since App Service and Kudu were first introduced, the deployment needs of developers have evolved.
+
+
Availability and adoption of mature continuous integration and delivery (CI/CD) tools and services like VSTS have grown significantly. Developers are increasingly looking to deploy tested, ready-to-run apps from these services instead of from source code.
+
The ability of many app stacks to enable rapid iteration has improved. Many contemporary developer workflows require the ability to quickly deploy directly from a development environment.
+
The introduction of Azure Functions has further driven the popularity of rapid-iteration workflows. The nature of Functions encourages developers to repeatedly prototype and deploy small packages of functionality.
+
+Kudu features a variety of mechanisms for deploying code to App Service that make use of its underlying deployment platform, which provides for safe, tracked deployments. But despite its relative lack of features, feedback has indicated that many developers favor using Kudu’s zip API for deployments, especially in the above scenarios. For many workflows, the pure simplicity and cross-platform availability of the push-based zip API and of zip files themselves wins out over the features of other available deployment mechanisms:
+
+
Git deployment restricts your site contents to files that are in the repository and requires a commit to deploy. Triggering deployments with pushes to hosted providers like GitHub requires some setup before getting started. Git deployment also engages Kudu's CI build system by default, which detects your app's runtime stack and generates scripts to do things like restore packages or compile code. This is undesirable when deploying an app that's already been built by your CI/CD service or deploying a working app from your local environment.
+
Web Deploy (aka msdeploy) is extremely powerful but challenging to configure. It's not supported on App Service on Linux and can't be used from non-Windows clients.
+
FTP requires tools that many developers don't have handy or aren't familiar with. Many of them require scripting to achieve the desired result.
+
+Zips are simple and ubiquitous, but without a connection to Kudu's deployment features, the zip API is only fit for general-purpose file transfers and is not robust enough for deployments. Deploying via the zip API can leave old files lying around that can break your application or Function unless you completely erase the existing files first. It doesn't create any deployment history, and there is no first-class way of verifying that deployment operations performed via the zip API are 100% successful.
+
+Why not combine the ease of pushing a zip file up to your site with Kudu's comprehensive deployment features? Enter zipdeploy!
+
Usage
+Create a zip file containing the files you want deployed to wwwroot and POST it as binary data to /api/zipdeploy on your site’s Kudu instance.
+
+Here’s how to do it with curl:
+
curl -X POST -u <publishing-user> --data-binary @<zipfile> https://{sitename}.scm.azurewebsites.net/api/zipdeploy
+Be aware that this operation may delete files currently in your site depending on the contents of your deployment! See Features below for more information.
+
+Add ?isAsync=true to the URL to perform an async deployment. A response will be returned as soon as the file is uploaded, and the deployment will continue on the server. The response will include a Location header with a URL that can be queried for realtime deployment status.
+
+By default, Kudu assumes that zip deployments do not require any build-related actions like npm install or dotnet publish. This can be overridden by setting the SCM_DO_BUILD_DURING_DEPLOYMENT deployment setting to true to enable Kudu’s detection logic and build script generation process.
+
+As with all web app deployments, modifying the files of a running app is a potentially dangerous operation that exposes your app to clients in a partially-deployed state. Apps that need atomic, zero-downtime deployments, smoke testing and/or rollback support should always use a staging environment and a slot swap as part of deployment.
+
Features
+
+
Flexibility: Push-based zip deployment eliminates the need to host your build output on the web or create a git commit. Zip deployments do not require any setup in Kudu or the Azure portal and can be run at any time with nothing but an HTTP client, regardless of whether your application is already synced with a source control provider.
+
Deletion of files left over from the previous deployment: Deployments use the KuduSync utility to track and delete files and directories that were created by a previous deployment if they’re not included in the new deployment. Any other files and directories found in the site that aren't being overwritten by the deployment will be preserved, such as files deployed via FTP, created in the Functions portal or created by your app during runtime.
+
Function trigger sync: If you are running Functions on a Consumption plan, modifying their triggers requires a synchronization process that doesn't occur with file-based deployment methods like FTP or the zip API. Zipdeploy will perform this synchronization for you.
+
Efficient file copy: KuduSync will only overwrite an existing file if its last-modified timestamp doesn’t match what’s in the deployment. You can speed up your deployments by using a build process that preserves timestamps on files that do not change across builds.
+
Logging, status tracking and history: Zipdeploy generates live status, deployment logs and recorded history in Kudu's deployment API. However, zip deployments cannot be redeployed.
+
Async support: By adding ?isAsync=true to the URL, a response will be returned as soon as the zip has been uploaded to the site. Deployment will continue asynchronously on the server. The Location header of the response will contain the deployment URL that can be polled for deployment status. Webhooks can be used for fully asynchronous notification of completion.
+
Customization:Deployment-related settings will be respected, including those in app settings as well as configuration placed in a .deployment file located in the root of the zip.
+
Build script support: By default, zipdeploy assumes that the zip contains a ready-to-run app. Kudu's continuous integration build process can be enabled via the SCM_DO_BUILD_DURING_DEPLOYMENT deployment setting, or by providing a custom build command with the COMMAND setting.
+
Safe deployment: Zipdeploy engages Kudu's deployment locks, preventing multiple simultaneous deployments from clobbering your site.
+
Auto Swap and container restart support: A zip deployment will trigger an Auto Swap if your site is configured for it. On App Service on Linux, zip deployment will trigger a restart of the app container.
+
+
Feedback
+Please give zipdeploy a try and let us know what you think, especially if you're currently using the zip API for deployments. We’d love to hear your feedback – we’ll be watching the Issues tab on Kudu’s GitHub page, as well as the MSDN forums, Stack Overflow and Uservoice.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
App Service Certificate can be used for other Azure service and not just App Service Web App. This tutorial shows you how to secure your web app by purchasing an SSL certificate using App Service Certificates , securely storing it inAzure Key Vault , domain verification and configuring it your virtual machine . Before your begin log in to the Azure portal athttps://portal.azure.com
+
Step 1 : Create an Azure Virtual machine with IIS web server
Step 2 : Add a Custom domain to your virtual machine
+Purchase a new domain and assign it your Azure virtual machine. For more details , click here .
+
Step 3 : Place an SSL Certificate order
+
You can place an SSL Certificate order by creating a newApp Service CertificateIn the Azure portal. Enter a friendly Name for your SSL certificate and enter the Domain Name in Step 1 . DO NOT append the Host name with WWW.
+
+
Step 4 - Store the certificate in Azure Key Vault
+
+
Key Vaultis an Azure service that helps safeguard cryptographic keys and secrets used by cloud applications and services. Once the SSL Certificate purchase is complete, you need to open theApp Service Certificates page. The current status of the certificate is“Pending Issuance” . Complete the steps below to have an active certificate ready to use.
+
ClickCertificate Configurationinside the Certificate Properties page and Click onStep 1: Store to store this certificate in Azure Key Vault.
+
+
+
+From theKey Vault Statuspage, clickKey Vault Repositoryto choose an existing Key Vault to store this certificateOR Create New Key Vaultto create new Key Vault inside same subscription and resource group.
+
+
Note : Azure Key Vault has minimal charges for storing this certificate. For more information, see Azure Key Vault Pricing Details.
+
+
Once you have selected the Key Vault Repository to store this certificate in, theStoreoption should show success.
+
+
+
+
Step 5 : Verify the domain ownership
+
From the sameCertificate Configurationpage you used in Step 3, clickStep 2: Verify. Choose the preferred domain verification method.
+
There are four types of domain verification supported by App Service Certificates: App Service, Domain, Mail, and Manual Verification. These verification types are explained in more details in theAdvanced section.
+
Step 6 : Assign certificate to Virtual machine
+
Before performing the steps in this section dedicated for Virtual machine , you must have :
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
App Service certificates now enables you to upload public certificate . Previously you had to use Azure resource manage template to upload a public certificate or use ARM client to do the same as described in this article. Today , we have made this experience more user friendly to allows user to install their public certificates in the personal certificate store.
+
+You can easily add a public Certificate for your App service web app using the Azure Portal. Follow the steps below to upload a public certificate :
+
Click on SSL Certificates setting -> Upload Certificate. Select Public and upload your public certificate . The .CER file contains information about the certificate ownership and public key.
+
+
+
+If you are using an App Service Environment you will be given the option to store either in Current User or Local Machine Store .
+
+
Once upload you can see your public certificate installed on your app as shown below
+
+Note SSL certificates is supported only on dedicated App Service Plans and App Service Environments.
+
Things to remember
+
+
If your App Service is hosted on a public scale unit then you can only install certificates in CurrentUser Personal Store certificate.
+
If your web app is hosted on an App Service Environments, CurrentUser or LocalMachine-Personal certificate store is only supported.
+
When using Deployment slots with your application , keep in mind that the certificates are not sticky and will also get swapped when you perform a slot swap operation. Either user your application code to check for multiple public certificates or make sure the correct certificate is upload for slot as well before you swap a slot with production app.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+This month we focused on fundamentals including performance improvements for the overview blade. This resulted in slicing the load time for the menu and overview blade to roughly half of what it was before the improvements.
+
Function + Logic apps
+Functions and Logic apps work great together and are often developed side by side. We’ve made it easier to move from Functions to Logic apps by including it in the platform features for functions. This will open an new tab where you can quickly switch between resources.
+
+
+
Supports public key certificates (.cer)
+Support for public key certificates was one of our most requested user voice features. Public key certificates let you use self-signed certificates for test/development scenarios amongst other things. You can read more about App Service support for Public Key Certificates here:
+
+
+
+If you have any questions about any of this features or App Service in general be sure to check our forums in MSDN and Stack Overflow.
+
+For any feature requests or ideas check out our User Voice
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
There are multiple options to hosting your Content management solutions (CMS) like WordPress , Drupal , Magento etc. with Linux App Service . The blog post below will cover the key decisions and implementation guidelines when using Web App for Containers for a CMS solution like WordPress or Drupal.
+
Built images :
+
App Service team provides your bare bone docker images for PHP , and other frameworks. These images are very basic and help you quickly get started but as your apps grows , these images may be limited to your needs as you are limited from making any changes to these images .
+
Custom images :
+
Custom docker images provides you with more flexibility to grow as your apps grows. You have more control on the docker image itself and can modify it with new modules or extensions if and when your app needs these changes . This option make lift and shift of your application more easy since you can replicate you current dependencies as close as possible in the cloud. Checkout an example of using a Python Application with a Custom image.
+The recommended approach is using custom images with Web App for Containers when using a CMS solution.
+
File Storage
+
App Service come with a shared file storage . You must use this storage if :
+
+
The application writes to the file system frequently and needs these files to be persisted.
+
You want to use auto-scaling features and you want all the instances to share the same file storage
+
+
In order to use the App Service Storage , explicitly include an app setting
+
WEBSITES_ENABLE_APP_SERVICE_STORAGE = true
+
To better understand this , let me elaborate with an example : If you have a WordPress app , note that WordPress CMS installs minor version updates to make sure your app has any important fixes needed. This means new files being added or existing files being modified to your application. In such cases , the application needs the files to persist so that you have the latest patches/fixes for WordPress hence this scenario requires the use of App Service Storage .
+
Most CMS solutions have a variation of this type of application updates . Have a better understating of your application to decide if you want to use App Service storage.
+
Can I use local storage instead of App Service Storage for CMS solutions
+
By using the local storage rather than App Service Storage you do get better stability and there is less impact if the app service storage has issues. To use local storage , set the app setting
+
WEBSITES_ENABLE_APP_SERVICE_STORAGE = false
+
Lets use WordPress as an example here again. You can use local storage for WordPress app , but this requires a few changes in your code and how the application is used. Here are a few things you would need to do :
+
+
Turn off auto update for WordPress
+
Manually deploy the latest WordPress code updates with your docker image
+
Do not install plugins , themes etc. from production site’s WordPress administration dashboard
+
+
For other CMS solutions like Drupal , Joomla etc ; you need to understand if there are options on turn on auto-update . The steps #2 and #3 mentioned above will still apply to any other application. This is a key decision to make before taking the next step.
+
Deployment
+
There are many deployment options available for your custom images:
There are two common terms with deployment as seen above :
+
+
Continuous Deployment : Every change made to your docker image is pushed out to production automatically.
+
Continuous Delivery: Provides you with a deployment release pipeline. This solution does not mean your code is pushed to production automatically . The goal here is to build a process that can allow code to be deployed any time . Most Continuous Delivery processes include automated tests and criteria that needs to be met before the changes go to production.
+
+
Based on your needs , pick either Continuous Delivery which we provide using VSTS or Continuous Deployment with ACR/DockerHub.
+
Can I deploy my code via GIT
+
You can have your application source code as part of the docker image or you can have the application code on a git based repository and your docker image on ACR or Docker Hub . Continuous Delivery with VSTS supports both these scenarios.
+
If you are not using Continuous Delivery with VSTS , the other option you have is Continuous Deployment feature that support GitHub, Bitbucket, Local GIT etc.
+
Note :You must use App Service Storage for your files if your application code is separate from your docker image and you choose to deploy the source code separately than the docker image. If your application code is large , there may be some issues with Git deployment for such apps. In those cases use Zip deploy API
+
Planning Migration or setting up a new site
+The question listed below should help you make the key decisions before implementing a migration of an existing site or setting up a new site:
+
+
Should I use a built in image or customer image ? Review your dependencies or requirements to answer this question
+
Should I use App Service Storage or Local Storage ? Does the app need file persistence ?
+
Do I need to run the app on multiple instances with auto-scale or Can I run the app on single instance ? When running in single instance , you can include local mysql , local redis etc without having to use a cloud service for MySQL and Redis . Note to use Local mysql you need file persistence
+
What deployment strategy works best for this application ? Keep in mind to choose an option that helps make deployment even after the site is in production. This will provide a stable , repeatable deployment process.
+
What external dependencies are needed ? Do I need a cloud based service for my database , twitter/Facebook API etc .
+
+
Migration
+Migration of an application from On-premise or other cloud solution providers can be challenging tasks. Here is migration process that is articulated for Web App for Containers.
+
+
Identify your application dependencies on premise or local development machine . Such as , webserver , php version , php extensions , web server modules etc . If you are using apache server with say php , you can build a custom image with apache server , php etc to run on Web app for containers. If you are using nginx in your current architecture , you can build a custom image with nginx for web app for containers.
+
Identify external dependencies like Database , Redis cache , CDN etc. Find appropriate solutions for these external dependencies in Azure
+
For CMS solutions always build a Custom docker image based on the dependencies you identified from the above step. You can find many samples here to help get started . Enable SSH in your docker image which can help as a tool to debug your app.
Create your external dependencies with the appropriate solutions available in Azure . For example , if your app needs MySQL you can use Azure database for MySQL for better reliability and performance
+
Make the decision to use Local storage or App Service Storage. To use App Service Storage , edit the app setting WEBSITES_ENABLE_APP_SERVICE_STORAGE = true
+
Select a deployment option for your application : Continuous Delivery or Continuous Deployment or Git Deployment. Deploy your code to the application and make sure the application code is updated appropriately to use the new dependencies for database , cdn etc in Azure
+
Browse your application once deployed
+
Turn on Diagnostic logs to view your docker logs to investigate any issues if you don’t get the expected results. Troubleshoot your application further using SSH .
+
Tweak your Docker image as needed to resolve any issues . Reiterate the process from step 7 .
+
+
If you are still unable to resolve any issues for a given step or have questions , reach out via support forums to get help.
+
Setting up CMS solution on Web App for Containers
+
In the steps below , using Drupal CMS as an example for the CMS solution to be setup and configured on Web App for Containers :
+
üCreate a Web App using Web App for Containers using Nginx-fpm and Drush CLI toolor your own custom Drupal Image. This image does not have Drupal source code as part of the image. Note : When using your custom docker image , make sure it is available in either Docker Hub or Azure Container registry as a private or public repository . Make sure you application has SSH enabled which can help in troubleshooting.
+
üUse App Service Storage since Drupal requires files to persist when you do install a module or update Drupal modules or Drupal core . Go to your app , select Application Settings -> App Settings. Now set WEBSITES_ENABLE_APP_SERVICE_STORAGE =true
+
üDesign and then implement your deployment strategy for your application .
+
üCreate a MySQL or PostgreSQL database depending on what database driver your application is using with Azure database for MySQL .
+
oIf you are migrating an existing application from on-premise or other cloud service provider , import your database content in the database.
üFix the docker image based on your investigation and update your Docker image.
+If you are planning to migrate a WordPress or Joomla or Moodle CMS solution , the process is exactly the same except for the custom image you plan to use . Here are some samples you can use :
+
+
Using Compression , for example including mod_deflate apache module helps with boosting performance on your application running on Apache web server by reducing the bandwidth on the file and reduces load on the server . This differs based on your web server
+
Enable back-end database caching using Azure Redis Cache service. If you are not using auto-scale feature with web app for containers , you can run a local redis baked into your docker image. Note this will only work if your app is running on one instance
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Functions Proxies is an API toolkit built into Functions to enable you to build APIs faster! Proxies makes it easy to perform simple API operations, like nesting multiple Functions together under one API, as well as API fundamentals, like mock APIs, OpenAPI definitions, and monitoring.
+
+Since preview we’ve gotten a lot of awesome feedback and responded with some new functionality to make Proxies even better. We’re now releasing Proxies under General Availability today, November 15th. Check out what’s new in Proxies at Connect()
+
+New Portal Experience for Proxies
+
+
Request and response overrides can now be set in the portal
+
Modify input request to send different HTTP verbs, headers, or query parameters to a backend service
+
Replace backend response status code, headers, and body
+
+Mock API support in Proxies
+
+
+Using the new editor, you can create mock APIs. You do this by using only response overrides and no backend URL. Mock APIs allow you to create a simple API at your real REST endpoint, allowing developers to start testing API integrations while the API is still under development.
+
+Functions Core Tools (CLI) Support for Proxies
+
+The Functions Core Tools are our set of CLI tools for locally developing Functions, and they now support authoring and running Proxies!
+
+Get started with a new proxy using
+
Function proxy create --name <yourproxyname>
+When prompted for a template, choosing SampleProxy will create a simple proxy to call httpbin.org/ip and returns your public IP address. Choosing RequestResponseOverride will create a simple mock API that returns a sample body and header. Note that the template uses “localhost” to reference a local function. This will allow the same Proxy to work in the cloud, once the Function App has a different hostname.
+
+
+
+Read more about developing locally in our docs.
+Application Insights Support
+Proxies will now publish telemetry to Azure Application Insights when App Insights is enabled for your function App. This allows for real time analytics steaming, as well as rich historical analysis. With Proxies you can not only measure your serverless API, but also proxy a legacy API and leverage App Insights to measure that API. Read more about our Application Insights support in Functions in the docs.
+
+OpenAPI Support
+
+Proxy rules will now show up in OpenAPI definition templates generated in Functions! A completed OpenAPI definition allows you to import APIs defined in Proxies into a wide range of tools and services, like Logic Apps, Visual Studio solutions, Power Apps, Flow, and Azure API Management.
+
+Read more about Functions OpenAPI support here in the docs.
+
+On by Default
+
+As a part of the GA release, Proxies will now be enabled by default on all Function Apps! We have also baked in some performance improvements to Proxies.
+
+Get Started Now!
+We’re very excited to release Proxies to the world! We’ve already seen the community build awesome widgets for single page applications, serverless URL shorteners, and much more with Proxies, and we’re excited to see what you build next!
+
For technical questions, please post on the MSDN forums or StackOverflow. The entire Functions engineering team monitors these questions, so you’re sure to get an expert answer.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+Today, we’re very excited to have released the public preview of Azure IoT Edge at our yearly developer conference, Connect();. This adds to the Azure IoT Suite the ability to write code which executes directly on IoT devices, allowing devices to react more quickly to events and spend less time sending messages to the cloud. The simplicity of Azure Functions fits extremely well as a programming model for these scenarios, and from day one users of IoT Edge will be able to write a Function to implement business logic right on their IoT devices. IoT devices are a great addition to the already robust list of places you can run a Function.
+
When Would IoT Edge be Useful?
+To best answer this question, let’s consider a simple example. Imagine you’re a factory administrator who oversees thousands of machines. With Azure IoT Hub, you can track the status of all your devices, send messages to those devices, receive messages from those devices, and more. Let’s assume you have a system in place receiving telemetry data about the temperature of your machines. To prevent damage due to overheating, you’re running a Function which is listening on all device to cloud messages (through the underlying EventHub.) The result of this is that you get a notification any time a device gets too hot, so you can mitigate and avoid disaster.
+
+Since you have thousands of machines sending temperature readings constantly, this is getting expensive and is taking up all your bandwidth. Here’s where IoT Edge comes in – by running your business logic directly on the devices, you only have to send messages to the cloud when an anomaly is detected. So, you augment your current system by adding the IoT Edge Runtime to your devices, writing a Function module deciding whether a message is necessary, and deploying this module to all your devices. You now have the same end system without the massive amount of message passing, and you can sit back and relax knowing your machines will tell you if they are overheating.
+
How do I Run Functions on a Device?
+
Azure IoT Edge is made up of three main components: IoT Edge modules, the IoT Edge runtime, and the cloud based interface. Modules are the units of execution that are pushed to your devices and run your custom code. The runtime is deployed to each device and manages these modules, which are implemented as Docker containers.
+
+
Figure 1: IoT Edge Experience Illustrated
+When a user writes a Function they’d like to run on the Edge, we package it up as one of these modules and deploy to your devices for you. We’ve released a Visual Studio Code extension to help you with this – no advanced knowledge of containers is needed, even though it’s a container under the hood. Follow the more detailed instruction set here in order to set up an edge enabled device, write a sample function, get it up and running on said device, and monitor the results.
+
+
Looking Forward
+The ability to write code which executes on IoT devices is an exciting addition for Azure users. For public preview, only C# Functions are supported, but we’re looking to add the ability to write Functions in more languages as we move towards GA. Also note that for public preview Functions won’t run on devices with ARM distributions of Linux.
+
+Be sure to visit the more detailed IoT Edge preview documentation, and try running a Function on the Edge! Also, please feel free to engage either me or the overall Functions team on Twitter with any questions:
+
@ColbyTresness
+
@AzureFunctions
+
Reference Code
+
The below code is an example of a Function reacting to IoT Edge events – parsing a message to find a machine’s temperature, checking if its over a threshold, and appending an alert if it is.
+
+
Code Sample 1: The Run Method of a Function Reacting to IoT Edge Events
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
The new Azure Functions on Linux preview enables local Azure Functions development on Linux and Mac platforms to seamlessly translate to cloud hosting on Linux across a broader choice of hosting options. The Linux hosting model for Azure Functions is based on Docker containers which brings greater flexibility in terms of packaging and leveraging app specific dependencies. This is another stepping stone in the journey to run Azure Functions anywhere and to enable reuse of your Function App code assets.
+
+Functions on Linux can be hosted in a dedicated App Service tier in 2 different modes:
+
+
You bring the Function App code and we provide and manage the container, no specific Docker related knowledge required.
+
You bring your own Docker container including the Azure Functions runtime 2.0, specific dependencies, and Function App code.
+
+Please note that charges for the dedicated App Service Plan you select will apply to the preview as published on the App Service pricing page.
+
+With the Azure Functions on Linux preview you should be able to run any Azure Functions scenarios supported by the Azure Functions runtime 2.0. Notes for known Azure Functions runtime 2.0 limitations are available at this link. Support for the Azure Functions on Linux preview is available with the Azure Portal and the Azure CLI. This blog post will focus on the Azure CLI for creating Azure Functions resources. The following steps are required regardless of the hosting mode selected:
+
+
# Create a Resource Group
+az group create -n rg-name -l "South Central US"
+
+# Create a Linux App Service Plan (use S2 or S3 as the sku value for larger VMs)
+az appservice plan create -n plan-name -g rg-name --is-linux -l "South Central US" --sku S1 --number-of-workers 1
+
+# Create a storage account
+az storage account create -n storage-name --location "South Central US" --resource-group rg-name --sku Standard_LRS
+
Host Function App content via an App Service managed container
+To host Function App content via an App Service managed container first create a Linux Function App:
+
# Create a Linux Function App
+az functionapp create -n fun-app-name -g rg-name -p plan-name -s storage-name
+To create a Function App pointing to a specific container image use the example below (referencing the latest Azure Functions on Linux starter image):
+
# Create a Linux Function App pointing to a specific container image
+az functionapp create -n fun-app-name -g rg-name -p plan-name -i microsoft/azure-functions-runtime:2.0.0-jessie -s storage-name
+You can manage the Function App in the Azure Portal. The Function App content however is not editable in the Azure Portal when using a custom container.
+
+To create your own container image, you must install a few prerequisites:
+
+Please note that app specific configuration can be included in the Dockerfile or managed as App Settings for the Function App. Once the prerequisites are installed you can follow these steps:
+
+
Create a Function App directory locally.
+
Generate a Dockerfile and optionally a sample function:
+
+
func init . --docker --sample
+func start
+
+
Build your container image and optionally test your Function App running in a container locally:
+
+
docker build -t my-functions.
+docker run -p 8080:80 my-functions
+
+
Publish your container image to an online registry such as Docker Hub:
+
+
docker login
+docker tag my-functions my-repo/my-functions
+docker push my-repo/my-functions
+Known issues for this preview are listed on the Azure Functions wiki. To ask questions or share issues with the engineering team for the Azure Functions on Linux preview please use the Azure Functions MSDN forum.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+As of December 2017, Azure App Service has updated the PHP stacks to the latest available versions. For information on the changes in the new versions, please see the change logs on the PHP website.
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Customers have embraced Azure Functions because it allows them to focus on application innovation rather than infrastructure management. The simplicity of the Functions programming model that underpins the service, has been key to enable this. This model that allows developers to build event-driven solutions and easily bind their code to other services while using their favorite developer tools, has good utility even outside the cloud.
+
+[caption id="attachment_6595" align="aligncenter" width="800"] Azure Functions Runtime preview 2 portal showing an Azure Function running against the V2 runtime.[/caption]
+
+Today we are excited to announce the second preview of Azure Functions Runtime, building on the first preview and feedback from customers, which brings the simplicity and power of Azure Functions to on-premises.
+
Azure Functions Runtime Recap
+The Azure Functions Runtime provides a method for customers to take advantage of the Functions Programming model on-premises within their own organization or datacenter.
+
+Offering a consistent development experience with the public cloud service, customers can use the Functions portal or Visual Studio to develop and publish Function Applications on-premises.
+
+This also enables customers to experience Functions-as-a-Service before committing to the cloud and also enabling customers to easily translate their code assets to the cloud when they move.
+
+Azure Functions Runtime consists of two pieces, the Management Role and the Worker Role. As the names suggest, these two are for managing and executing functions code respectively. You can scale out your Functions by installing the Worker Role on multiple machines and take advantage of spare computing power.
+
+What’s New?
+
+This release brings further improvements and features to our on-premises audience:
+
+
Support for Azure Functions runtime 2.0, known limitations of the v2.0 runtime are available at this link. This enables you to write functions in C# (.NET Standard) or JavaScript
+
Hosting of v2 Functions on Windows Nano containers, providing a streamlined, lightweight experience.
+
+[caption id="attachment_6585" align="aligncenter" width="800"] Create new function app in Azure Functions Runtime preview 2[/caption]
+
Updates to v1 Functions including language support for C#, F#, JavaScript and PowerShell, which are still executed within Windows Server Core containers.
+
+[caption id="attachment_6605" align="aligncenter" width="800"] Templates available to v1 functions in Azure Functions Runtime preview 2[/caption]
+
Updated Portal experience
+
Support for multi-tenancy, enable multiple users to use the same infrastructure and portal to work on their own function apps in isolation
+
Customers can specify their own custom DNS name for the Azure Functions Runtime portal and can work behind a load balancer
+
The ability to run alongside additional versions of Docker for Windows already deployed
+
Ability to reset installation to factory defaults
+
+Requirements
+
+The Azure Functions Runtime Worker Role is deployed in a Windows Container. As such it requires that the host machine is running Windows Server 2016 or Windows 10 Creators Update. If deployed in a virtual machine, it must have nested virtualization support.
+
Looking Forward
+We are continuing to shape the direction of our on-premises offering of Azure Functions, based on customer feedback during preview. We are interested in hearing your feedback and use cases as we move towards a GA Release. We’re excited to see the types of applications you are building and the types of workloads you envisage running in Azure Functions Runtime.
+
+Please feel free to engage with me via the comments or Twitter regarding your needs and feature requests for Azure Functions Runtime in on-premises scenarios.
+
+@apwestgarth
+
+How do I get started?
+
+Please download the Azure Functions Runtime preview 2 installer.
+
+For details, please see the Azure Functions Runtime documentation.
+
+We would love to hear your feedback, questions, comments about this runtime through our regular channels including Forums, StackOverFlow, or Uservoice.
+
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+We have a brand new function creation experience that includes among other improvements the ability to search templates by keywords as well as filtering templates by language and scenario.
+
+
+
Functions on Linux App Service Plans
+You can now select Linux App Service plans to host your Function apps. You can read more about this scenario here: The Azure Functions on Linux Preview
+
+
+
Support for HTTPS Only
+This was one of the most requested features in our Uservoice forum and it is now available in production.
+
+This feature can be found under Custom Domain in the left menu and works for apps hosted on Windows as well as Linux App Service Plans.
+
+When this feature is enabled all traffic reaching an HTTP hostname in your app will be redirected to it’s HTTPS equivalent. Make sure all custom hostnames have a valid SSL binding to avoid browser validation errors.
+
+This feature also includes the ability to add bindings to existing hostnames directly from this blade.
+
+
+
+
Quick Start refresh
+We have updated the App Service Quickstart for Windows and Linux based apps, scenario cards now link to existing scenario documentation on https://docs.microsoft.com/azure/app-service/ where they are frequently updated and provide a lot more content and more advanced scenarios.
+
+
+
+If you have any questions about any of this features or App Service in general be sure to check our forums in MSDN and Stack Overflow.
+
+For any feature requests or ideas check out our User Voice
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+In January 2018, Azure App Service will update the PHP stacks to the latest available versions. For information on the changes in the new versions, please see the change logs on the PHP website.
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+A big percentage of the backup failures (More than 42%) can be fixed in minutes, and more importantly without even opening a support ticket.
+
+Step 1: Figure out what is the failure.
+
+From the backup blade, click on the failing backup and check the Log Details
+
+Step 2: Check the following table.
+
+
+
+
Error
+
Fix
+
+
+
Storage access failed. {0}
+
Delete backup schedule and reconfigure it
+
+
+
The website + database size exceeds the {0} GB limit for backups. Your content size is {1} GB.
+
Use a backup.filter file to exclude some files from the backup, or remove the database portion of the backup and use externally offered backups instead https://aka.ms/partial-backup
+
+
+
Error occurred while connecting to the database {0} on server {1}: Authentication to host '{1}' for user '<username>' using method 'mysql_native_password' failed with message: Unknown database '<db name>'
Create Database copy of {0} ({1}) threw an exception. Could not create Database copy
+
Use admin user in connection string
+
+
+
The server principal "<name>" is not able to access the database "master" under the current security context. Cannot open database "master" requested by the login. The login failed. Login failed for user '<name>'.
+
Use admin user in connection string
+
+
+
A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)
+
Check that the connection string is valid, whitelist site’s outbound IPs in database server settings
+
+
+
Cannot open server "<name>" requested by the login. The login failed.
+
Check that the connection string is valid
+
+
+
Missing mandatory parameters for valid Shared Access Signature
+
Delete backup schedule and reconfigure it
+
+
+
SSL connection is required. Please specify SSL options and retry. when trying to connect
+
Please use the built in backup feature in Azure MySQL or Azure Postgressql.
+
+
+
+
+Step 3: The failure is not in the table
+
+
+Well ... Please open a support ticket.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+In February 2018, Azure App Service will update the PHP stacks to the latest available versions. For information on the changes in the new versions, please see the change logs on the PHP website.
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
If the registrant of the domain contact information has changed and needs to be updated , follow the guidance below to make the necessary changes to make sure there is continuity of your use of the domain or any certificates associated with that domain.
+
+Follow these steps to update the contact information of your domain:
+
+
Login to Azure portal . Go to your domain within the Azure portal. Click on Advance management to go to advance management portal.
+
Select your domain that needs to be updated and Click on Manage
+
Click on view personal information if it is hidden .
+
Click on Edit to modify the contact information for the registrant of the domain.
+
Click on Save to save the changes .
+
When the email of the contact information is updated , you will receive an approval request to the new email address updated in the contact information for the domain . Please complete this process to use the new email address with the domain.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Well, that’s a loaded title for a blog post! But here’s the thing, we’ve been asked many times about what actually goes on behind the scenes when App Service updates the resources hosting App Service apps.
+
+First, we need to mention briefly what is App Service. App Service is a PaaS (Platform as a Service) offering that allows customers to focus on their code, rather than having to worry about managing the underlying Virtual Machines and other resources with the latest security updates, OS patches and so on.
+
+Still, those resources don’t get magically updated, do they? That is the beauty in a managed platform — we do that for our customers! App Service applies monthly updates to the resources, making sure our customers’ code is always running on the most recent security patches and OS versions available. As an example, this was extremely useful for our customers when the latest Spectre and Meltdown vulnerabilities were announced. Customers did not have to take any action because the service was updated automatically.
+
+To give some additional technical details and demystify the process, we’ll outline here what happens when the App Service updates takes place , but first we’ll go through some key concepts:
+
+
App (or site) – the structure that manages the code that is deployed for users.
+
Instance – The Virtual Machine hosting the code. It can be in variations of memory allocation, CPU etc.
+
Upgrade Domain – Collections of VMs in a given Scale Unit that are taken offline at the time of an update.
+
Scale unit / Stamp – The collection of Virtual Machines in a given region.
+
Region (or datacenter) – An area in the world where there is a collection of Virtual Machines managed by Microsoft. As of writing this blog, Azure is deployed in 42 regions worldwide.
+
Paired Regions – Two Azure regions which within the same geography which Azure guarantees not to update simultaneously.
+
+
App Service update cycle:
+First and foremost, it’s important to note that App Service assures and maintains its SLA at all times, even during updates. Though we try our best, the upgrade process can sometimes run for over 18hrs which causes the upgrade activity to spill over into business hours. Following our robust best practices, which can be found under the Diagose & Solve blade for your resource or in this article, will ensure minimal SLA impact even during platform upgrades.
+
+Before beginning worldwide updates, we deploy first to a private region which is not commonly accessible. Only after testing is validated there, we begin to roll out to datacenters across the globe.
+
+Our typical time for completing updates worldwide is about 10 business days, which allows us to deploy during each region’s off hours and also avoid deploying to Paired Regions at the same time (for example, East US and West US). When you are planning your app’s infrastructure for high availability and looking to deploy in multiple regions, it’s always a good idea to deploy to the paired region of your target region, since if there is a platform issue in the update, it won’t affect the paired region. After mitigating any issue, we will only then continue to the paired region, after the first is complete.
+
+As a managed service, we always leave a buffer in our capacity for new resources, for scaling operations on existing resources, in case instances become unhealthy and force us to move apps to other instances and of course for our OS update process, detailed here.
+
+
+
+When the update reaches a specific region, we update available instances without apps on them, then move the apps to the updated instances, then update the offloaded instances.
+
+
+
+This move results in a cold start, and there may be a performance hit associated with this. Application binaries are loaded to the new Virtual Machine, and libraries are loaded from the disk. Externally the user will see a one-time delay in responses to requests to the app, after which the site will run normally. The delay is dependent on many things, mainly on the complexity of the app, the framework it’s built on, and dependencies. You can reduce the impact of cold starts on your application by properly configuring the App Initialization model, as detailed in this blog.
+
+Thanks for reading and if you’d like to try App Service yourself, create your first app using one of our quickstarts and see how easily you can deploy your app and change your code right away.
+
+If you have questions about App Service, please reach out to us through the developer forums, on MSDN or Stack Overflow.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Have you checked out App Service diagnostics yet? In November 2017, we announced the general availability of App Service diagnostics, our new self-service diagnostic and troubleshooting experiencing to help you resolve issues with your web app.
+
+Since then, based on your feedback, we’ve enabled several exciting features in the past few months.
+
TCP Connections
+
+
+We added a new tile shortcut! The “TCP Connections” tile shortcut allows you to investigate:
+
+
Outbound TCP Connections: Graphed over time per instance
+
Connection Rejections: Detects issues with port rejections
+
Open Socket Handles: Open socket count when outbound TCP connections crosses 95% of the machine-wide TCP connection limit.
+
+
+
App Service Diagnostics for Linux
+For all our App Service on Linux users, you can now also use App Service diagnostics to run a health checkup and use the tile shortcuts to analyze issues in performance and availability, such as “Web App Down,” Web App Slow,” and “Container Initialization.”
+
+
+
Integration with Application Insights
+For .NET applications, we have added integration with Application Insights to help you look for relevant exceptions correlating to downtime occurring on your web app. These features are:
+
+
Application Insights Enabled: Easily check if you have Application Insights enabled (and if you don’t, you can enable it right there).
+
Inside the “Web App Down” tile, if there are exceptions available, you will be able to see the exceptions thrown from Application Insights, sorted by count so you know which ones are most important.
+
+
+
Open App Service Diagnostics
+To access App Service diagnostics, navigate to your App Service web app in the Azure portal. In the left navigation, click on Diagnose and solve problems.
+
+
+
+To learn more, check out these links:
+
+
Connect() Video: Want to see a demo of App Service diagnostics? Check out this video to learn more about "What's New with App Service" (where I demo App Service diagnostics starting at 1:50).
+
Azure Friday Video: One of our App Service diagnostics engineers, Steve Ernst, joins Scott Hanselman to diagnose and troubleshoot a real case of a web app having issues.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
This blog post has old info, the new version is here.
+The App Service team have been hard at work creating a new experimental create and deploy experience for Azure App Service.
+
+We released a new Azure CLI extension that adds a new command called new (have you seen what we did there!?).
+
+The new command (Which is currently in Preview) enables the user to create and deploy their Node.js or .NET Core app using a single command. For Node.js we check for the existence of a package.json file in the code root path to indicate it is a Node.js app. For .NET Core we check for the existence of a *.csproj file with netcoreapp as the TargetFramework
+
+[caption id="attachment_7095" align="alignnone" width="586"] Click on the gif to see the command in action[/caption]
+
+In the case of Node.js app the command does the following:
+
+
Create a new resource group (in Central US, you can use the --location to change the region)
+
Create a new Linux single VM small App Service plan in the Standard SKU (in Central US)
+
Create a Linux webapp
+
Deploy the content of the current working directory to the webapp using Zip Deployment
+
+In the case of .NET Core app the command does the following:
+
+
Create a new resource group (in Central US, you can use the --location to change the region)
+
Create a new free Windows App Service plan (in Central US)
+
Create a Windows webapp
+
Deploy the content of the current working directory to the webapp using Zip Deployment
+
+To Install the Azure CLI tools refer to their documentation.
+
+To Install the extension:
+
az extension add --name webapp
+To update the extension with the latest fixes and new languages support (Current version is 0.1.0):
+
az extension update --name webapp
+To know what the command will do without creating anything:
+
az webapp new --name [app name] --location [optional Azure region name] --dryrun
+[caption id="attachment_7115" align="alignnone" width="626"] Click to see --dryrun in action[/caption]
+
+To use the new command:
+
az webapp new --name [app name] --location [optional Azure region name]
+To update your app content - Just rerun the command you used to create the app (including the --location argument):
+
az webapp new --name [app name] --location [optional Azure region name]
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
“Cold start” is a large discussion point for serverless architectures and is a point of ambiguity for many users of Azure Functions. The goal of this post is to help you understand what cold start is, why it happens, and how you can architect your solutions around it. To provide this explanation, we’ll be going deep into some technical details of how Azure Functions works behind the scenes.
+
Consumption Plan vs. Dedicated Plan
+Azure Functions comes in two main flavors – consumption and dedicated. The difference between the two is important – choosing one over the other not only dictates the behavior of your application, but also how you’re billed. The consumption plan is our “serverless” model – your code reacts to events, effectively scales out to meet whatever load you’re seeing, scales down when code isn’t running, and you’re billed only for what you use. Plus, all of this happens without you thinking about what Azure is doing behind the scenes. The dedicated plan, on the other hand, involves renting control of a Virtual Machine. This control means you can do whatever you like on that machine – it’s always available and might make more sense financially if you have a function which needs to run 24/7. If you’re curious and want a more detailed explanation, check out our documentation.
+
What is Cold Start?
+Broadly speaking, cold start is a term used to describe the phenomenon that applications which haven’t been used a while take longer to start up. In the context of Azure Functions, latency is the total time a user must wait for their function – from when an event happens to start up a function until that function completes responding to the event. So, more precisely, a cold start is an increase in latency for functions which haven’t been called recently. When using Azure Functions in the dedicated plan, the functions host is always running, which means that cold start isn’t really an issue. So, our scope is narrowed to functions running the serverless consumption model. Let’s go deeper.
+
What Happens When I Write a Function?
+Suppose you’re writing your first function. You’ve provisioned a function app, created your function based on one of our templates, and are modifying it to fit your business needs. You save, and now wait for your specified trigger to initiate your function. Later, your function triggers. When this process begins, since you haven’t yet executed anything, all your code and config exist only as files in Azure Storage. Let’s pause and think through broadly what still needs to happen for your code to run:
+
+
Azure must allocate your application to a server with capacity
+
The Functions runtime must then start up on that server
+
Your code then needs to execute
+
+Steps 1 and 2, if done unintelligently, can take a while - spinning up and configuring a server takes time. To make this experience better for users, instead of starting from scratch every time, we’ve implemented a way to keep a pool of servers warm and draw workers from that pool. What this means is that at any point in time there are idle workers that have been preconfigured with the Functions runtime up and running. Making these “pre-warmed sites” happen has given us measurable improvements on our cold start times – things are now on the order of 3-4 times faster. Now, let’s go back and walk through a more detailed view of what happens when you trigger the execution of a function when resources haven’t yet been allocated.
+
What Happens During a Cold Start
+
+
+
Azure allocates a preconfigured server from the pool of warm workers to your app. This server already has the Functions runtime running on it, but it is unspecialized.
+
This worker becomes specialized by configuring the Functions runtime in ways that are specific to your app. A few things happen to do this specialization, including:
+
+
The Azure Functions infrastructure mounts your Azure Files content to the worker you’ve been assigned
+
App settings specific to your function app are applied to the worker
+
+
+
The Functions runtime resets, and any required extensions are loaded onto the worker. To figure out which extensions to load, the runtime reads the function.json files of any function in the function app. For instance, this happens if you’re using Durable Functions, or if you have input or output bindings.
+
The functions themselves are loaded into memory by language providers. This will take a varying amount of time based on the size of your application.
+
Your code runs.
+
+If you’ve executed your function recently, #1-4 have already happened – the resources are already allocated, and your site is “warm.” As you can imagine, in this scenario things are considerably faster. We deallocate resources after roughly 20 minutes of inactivity, after which your next call will be a cold start and this entire process will happen again. This is illustrated above.
+
Is the team making any more improvements?
+Yes! This post is simply a point in time (February 2018) analysis of how things work, and many specifics are subject to change. As evidence, we recently released an update to the runtime and for our GA languages we’re seeing a further 50% improvement on cold start times. I won’t go super deep on it here, but this update fixed a regression in our native image generation. For more details, read up on NGEN or check out the release itself (we’re fully open source!)
+
How Can I Improve My Code to Help Avoid Long Cold Starts?
+Now that we have a baseline understanding of what’s happening behind the scenes to cause cold start, we can start to address how to architect your solutions to avoid it.
+
+Language: First and foremost, use our generally available languages – C#, F#, and JavaScript. We have several experimental languages which aren’t fully supported and optimized – most of them actually spin up a new process on every execution, which impacts latency a great deal. Also, it’s important to note that any language running in our 2.0 runtime is in preview and also hasn’t been optimized fully. We expect these languages to perform better in the future, but for now, stick to the GA languages mentioned above. For more specifics, see our documentation.
+
Write Lightweight Code
+Dependencies: When you deploy your code, your dependencies are added as files to your application. As outlined in step 4 above, all code needed by your app eventually gets loaded into memory, which takes longer with a larger application. So, if you have a ton of dependencies, you’ll get a longer cold start due to a) increased time for I/O operations from Azure Files, and b) longer time needed to load a bigger app into memory. This is a thing we see all the time for folks writing functions in JavaScript – npm trees can get huge. Not only does this increase the size of your app, but also increases the number of files that Azure Files has to handle, which causes further slowdown. For this scenario in particular, we’ve released a tool to help: check out Funcpack to learn more!
+
+Efficient Code: Sometimes the answer is simply writing more efficient code. There are a few approaches to note here – first, try to make as much processing as possible asynchronous. Functions won’t perform well if you have a heavyweight synchronous call blocking your code from completing. Along this vein, try to minimize the amount of work that has to happen before your code starts up and avoid code which consumes a lot of CPU. If you’re concerned about this yourself, we recommend trying out Application Insights – it’s a fantastic monitoring tool and can help isolate application slowdown from platform slowdown.
+
Avoiding Cold Start Altogether
+Dedicated Mode: As mentioned before, running Functions in an App Service Plan alleviates these issues since you control what happens on your VM. This is slightly more expensive, and isn’t serverless, but if your solution has a hard requirement for low latency on every individual call, consider using the Dedicated mode.
+
+
+
Feedback
+Feedback is always welcome – if you want to tell us what you think or reach out to the product team directly for any other reason, engage with us on Twitter or GitHub!
+
+@AzureFunctions@ColbyTresnessAzure Functions
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Welcome to a new and exciting year of App Service updates, December 2017 was a quality milestone for the App Service team and over the break we delivered over 60 general quality of life and performance improvements for both the App Service and Functions experience in the Azure portal.
+
+Now that we are in February it’s time to share some of the improvements and new features we delivered in January 2018
+
Application Settings UX refresh
+The new application settings ux uses the same code base across App Service, Azure Functions and Web Apps for Containers. It provides a consistent look and feel, improves performance and allows us to deliver improvements and new features across all 3 products with less duplicated work.
+
+
+
+
+
+
+
+
+
My SQL in-app data import
+My SQL in-app now lets you import as well as export the database content. This makes it easy to migrate existing databases in and out of MySQL in-app.
+
+
+
New FAQ UI
+We have a new experience that provides in context help content filtered to the specific feature you are using. The content is driven by the App Service documentation and it lets you get straight to what you need without having to search for it.
+
+
+
+
+
+If you have any questions about any of this features or App Service in general be sure to check our forums in MSDN and Stack Overflow.
+
+For any feature requests or ideas check out our User Voice
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
This blog post describes the various tools available to you to debug any issues with App Service Certificates resources that you may be using with Web App or other Azure Services. SSL is a critical part of your application and when configuring the certificate or renewing the certificate there can be a few issues you might run into . These tools listed below can help provide you information to self-debug the issue in most cases.
+
+
+
+
Verify Status of your Certificate : Check if the Status of your certificate is ready for use. Sometimes the certificate might have Domain verification step pending and this status tile can help provide information on what steps you need to take
+
+
+
+There are many different states the certificate can be in :
+
+
+
+
Certificate Denied : Domain verification was not completed in 15 days causing the certificate to be in denied state. Certificate will not be billed. Purchase a new certificate with same domain to resolve this . Certificate cannot be restored.
+
Certificate Expired : Certificate has expired . If auto renew was enabled and the certificate still expired , then credit card payment may have failed for the subscription. In this case , you need purchase a new certificate with the desired domain to resolve the issue.Certificate cannot be restored.
+
Domain verification required : Domain verification is pending . Click on "Certificate Configuration" and complete STEP 2 for domain verification. If Domain verification option is not working , select Manual verification to complete this step. If Domain verification is not completed in 15 days , certificate will be in denied state
+
Key Vault out of sync: Key vault can be out of sync if it was deleted , moved to another subscription or if the subscription was in suspended/canceled state. Choose your app service certificate in the Azure portal , click on Certificate Configuration and complete STEP 1 to assign a new Key Vault resource to app service certificate. Note if you are bringing you external certificate via Key Vault using this blog post , you must reconfigured to use the correct secret with the app service certificate. App service certificate looks for secret name and does not support using "certificate object" in key vault. This is a limitation and we are working in fixing it
+
+
+
Debug using Resource Explorer : You can look at the certificate order state in resource explorer https://resources.azure.com . Select your subscription -> Providers -> Microsoft.CertificateRegistration->Certificateorders . This lists all the certificate orders within the subscription.
+
+
Search for a given certificate and look at the "provisioingstate" property . If Succeeded , it will be ready to use state. If not , resolve the issues based on the states mentioned earlier in this post.
+
+
+
Debug using Timeline : View the list of historical activities or operations that have occurred on App Service Certificate resource using the Timeline feature to help debug the issue
+
Sync a Certificate :The Web App service runs a background job that periodically (once a day ) that syncs all App Service certificate. Hence when you rotate or update a certificate, sometimes the application is still retrieving the old certificate and not the newly updated certificate. This is because the job has not run to sync the certificate resource. To force a sync of the certificate , you can click on Rekey and Sync setting and then click on Sync button .
+
Refer to FAQs documentation : Get access to appropriate documentation to App Service certificates to help resolve the issue with Configuration , Rekey and Sync , Renewal etc .
+
+
+
+If the above tools dont help you resolve the certificate related issues , then please contact Microsoft Azure Support.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Note: This information below only applies to Windows web apps on App Service.
+
+Recently, we released the TCP Connections tile shortcut in App Service diagnostics. In this blog, we will walk through the implications of having unhealthy TCP Connections and how you can analyze them using App Service diagnostics.
+
Why should you care about TCP Connections?
+Let's say that you have created two web apps on the App Service Plan, and both are breaking. An example of when TCP Connections can cause this behavior in your web apps could be that one app is leaking a lot of socket handles and ends up hitting the machine wide TCP Connection limit. App Service enforces limits on the number of outbound connections that can be outstanding at any given point in time. When web apps run into these connection limits, they will start intermittently failing because calls to those remote endpoints will fail, causing downtime. You’ll frequently see errors like the following: “An attempt was made to access a socket in a way forbidden by its access permissions aaa.bbb.ccc.ddd.”
+
+The maximum connection limits are the following:
+
+To examine your TCP Connections more closely, click on the "Diagnose and solve problems" tab in the left hand menu. Then, select the "TCP Connections" tile shortcut.
+
+
+
+Upon opening the TCP Connections, you can quickly see three levels of data: TCP Connections, Connections Rejections, Open Socket Handles. If it’s healthy, there will be a green checkmark. If it’s unhealthy, there will be an orange exclamation mark.
+
TCP Connections
+Here, you can monitor the total connections on your instances and the state of the connections, which include TIME_WAIT, ESTABLISHED etc.
+
+If your web app has high outbound connections (> 1500 outbound connections), you will see the IP addresses’ first three octets and the port number in the Summary. By examining the port number, you can determine what type of remote service is causing the high outbound connections.
+
+
+
+
Port Number
+
Service
+
+
+
1433
+
SQL
+
+
+
80 or 433
+
Web Service
+
+
+
+
+Connections Rejections
+
+Check if there are any port rejections. If your web app failed to make an outbound TCP connection because the machine-wide TCP Connection limit was hit, we will highlight that in the Summary and associated graph.
+
+
+Open Socket Handles
+
+Here, you can determine which web app is causing a socket leak if you have multiple web apps in your App Service Plan.
+
+If your web app has leaking connections, you will see the process name, process ID, site name, and number of open handles. We will highlight the process that is causing the maximum damage in the Summary.
+
+
+
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
We've recently released new versions to Node and PHP on App Service on Linux!
+For Node, we have added:
+
+
9.4
+
8.9
+
8.8
+
8.2
+
+For PHP, we have added:
+
+
7.2
+
+If you already have an existing web app that you would like to update to the new versions, navigate to the "Application Settings" from the left-hand menu of your web app and select the new version in the "Stack" dropdown.
+
+
+
+If you're creating a new web app, check them out in the "Runtime Stack" dropdown.
+
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+This morning we released the first update to Azure App Service on Azure Stack. This release updates the resource provider and brings the following key capabilities:
+
+
Support for Highly Available deployments of Azure App Service on Azure Stack
+
+
The Azure Stack 1802 update enabled workloads to be deployed across fault domains. Therefore App Service infrastructure is able to be fault tolerant as it will be deployed across fault domains. By default all new deployments of Azure App Service will have this capability however for deployments completed prior to Azure Stack 1802 update being applied refer to the App Service Fault Domain documentation
+
+
+
Deploy in existing virtual network
+
+
As a result of customer feedback post release we have now added this capability enabling customers to deploy Azure App Service and communicate with their SQL and File Server resources over a private network.
+
+
+
Update the App Service Tenant, App Service Admin and Azure Functions portals.
+
Updates to add .Net Core 2.0 support, additional versions of NodeJS, NPM, PHP, new versions of Git and Mercurial
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
At Build 2014, Azure announced RESTful API for resource management called Azure Resource Manager and a shiny new Azure portal. In the years since Azure App Service has implemented support for Azure Resource Manager. If you manage your App Service resources through the portal or through automation against the REST API or any of these SDKs, clients or tools or deploy resources through deployment templates, you are already using Azure Resource Manager. If, however, you also have automation built against the legacy Azure Service Management APIs, this announcement affects you.
+
+Azure App Service resource management will be supported only through Azure Resource Manager. Azure Service Management support will be retired on June 30, 2018. The Service Management APIs are archaic and not well suited for the modern cloud. Supporting Service Management APIs any longer will hold us back from delivering premium developer experience and control plane scale. Customers currently using the Service Management APIs will be better served by moving to Resource Manager. Azure Resource Manager has many benefits over Service Management like robust deployment model, role-based access and better API support for existing and new features. For more information, see Difference between Azure Service Manager and Azure Resource Manager.
+
+Determining if you are using Azure Service Management APIs
+
+A good way to tell if your automation (SDK/tool/client) uses Service Management APIs is to see if that automation uses Web Spaces or Resource Groups to manage (deploy/create/update/start/stop/configure etc.) resources. To uniquely identify and manage resources, automation needs a logical grouping mechanism that is also the uniqueness scope for the resources. For Service Management APIs for Azure App Service that grouping is Web Spaces, while for Azure Resource Manager it is Resource Groups. If your automation (SDK/tool/client) uses Web Spaces to manage resources you are using Azure Service Management and we recommend that you switch to the Azure Resource Manager.
+
+UPDATE::
+
+App Service diagnostics now has a detector that can identify any soon to be deprecated APIs called within the last 24 hours on your web app or associated resources. Once the API in question is no longer called, the detector will let show 'green' for that API within 24 hours.
+
+
From the app service overview blade click on "Diagnose and solve problems".
+
+
+
+
+
+
Once the detectors have loaded click on "Deprecating APIs" under the section "Management and Configuration". This will open up a new tab "Deprecating APIs"
+
+
+
+
Once the detector execution completes, you will have names of all the API clients/tools used to call the deprecating APIs and the actual calls.
+
+
+Authentication
+
+Service Management supports authentication using Azure Active Directory or management certificates. For Resource Manager authentication is built around Azure Active Directory apps and interactive user access. To learn more, see Resource Manager API Authentication. If your automation must use certificates for management, you can achieve that by Authenticating to Azure Resource Manager using AAD and certificates.
+
+Resource Deployment
+
+Resource Manager has a robust deployment engine with declarative resource description. To understand how the resource deployment differences between the two, see Resource Manager Deployment Model. Resource manager supports resource deployment via deployment templates. Additionally, starting from Microsoft Azure SDK for .NET 2.9, resource deployment via Visual Studio is also supported. For more information, see Deploying resources and code through Visual Studio.
+Directly calling the API
+
+If you want to code against the Resource Manager REST API directly, refer to Azure App Service REST API documentation. ARMClient and Azure Resource Explorer are great tools to play with and discover the shape of the App Service Resource Manager API. For more information on ARMClient, see ARMClient: a command line tool for the Azure API.
+
+SDKs and tools
+
+Resource Manager offers SDKs and tools in a large set of languages, frameworks and platforms. These include but are not limited to .NET, Node, Java, Ruby, Python, Go, PowerShell and Azure CLI. Detailed documentation, tutorials and examples are available here.
+
+App Service Resource Metrics
+
+If your automation consumed the App Service resource metrics API, we recommend that you switch over to the Azure Resource Manager Monitoring APIs. While we still offer App Service specific metrics API, we plan on deprecating them soon. The Resource Manager Monitoring APIs are the common way of interacting with metrics across any resource on any service within Azure. For more information, see metrics supported by Azure Monitor.
+
+Please make sure to move all your automation and deployment tools to use new API’s before June 30th 2018 so that you do not experience any service interruptions and benefit from superior deployment and management capabilities of Azure Resource Manager.
+
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Azure App Service has two features named Hybrid Connections. There is the original BizTalk Hybrid Connections and the newer Azure Relay based App Service Hybrid Connections.
+BizTalk Hybrid Connections is going end of life May 31, 2018.
+
+To avoid problems, you should migrate from BizTalk Hybrid Connections to the new Azure Relay based Hybrid Connections. You can read more about them in Azure App Service Hybrid Connections To migrate your BizTalk Hybrid Connections to the new Hybrid Connections, you need to:
+
+
Make sure the apps you want to use Hybrid Connections with are running in a Basic, Standard, Premium, Premiumv2, or Isolated App Service plan.
+
Create a new Hybrid Connection using the information in Add and Create Hybrid Connections in your app. The name of the new Hybrid Connection does not have to match the old one but the endpoints should be the same between the new and the old Hybrid Connection.
+
Add the new Hybrid Connection to the apps that are using the BizTalk Hybrid Connection.
+
Upgrade all of your Hybrid Connection Managers to the newest version. The installer for the new Hybrid Connection Manager will upgrade your older instances. You can read more about the new Hybrid Connection Manager here and can download it from the Azure portal in the App Service Hybrid Connections portal.
+
Add your new Hybrid Connections to all of the Hybrid Connection Managers you want to use.
+
After the new Hybrid Connection shows a status of Connected in the portal, delete the older BizTalk Hybrid Connection.
+
+The new Relay based Hybrid Connections exist as a service outside of Azure App Service. You can find more details starting with the Overview on Azure Relay.
+
+Relay based Hybrid Connections does have a number of improvements over the BizTalk Hybrid Connections. The newer feature uses TLS 1.2, communicates to Azure only over port 443, creates connections based on a DNS name, and has a much easier user experience.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
We listened to feedback, we decided to change our previously released experimental "new" command to be now "up".
+
+With version 0.2.0 of the extension, "new" is no longer available, and you will have to use "up" instead.
+
+
+
+The command (Which is still in Preview) enables the user to create and deploy their Node.js, .NET Core, ASP.NET, Java, or Static HTML apps using a single command. For Node.js we check for the existence of a package.json file in the code root path to indicate it is a Node.js app. For ASP.NET and .NET Core we check for the existence of a *.csproj file with netcoreapp as the TargetFramework. For static HTML we check the existence of a *.html file.
+
+The command check for languages in the following order:
+
+
Node.js
+
.NET Core and ASP.NET
+
Static HTML
+
+In the case of Node.js and Java apps the command does the following:
+
+
Create a new resource group (in Central US, you can use the --location to change the region)
+
Create a new Linux single VM small App Service plan in the Standard SKU (in Central US)
+
Create a Linux webapp
+
Deploy the content of the current working directory to the webapp using Zip Deployment
+
+In the case of an ASP.NET, .NET Core, Static HTML app the command does the following:
+
+
Create a new resource group (in Central US, you can use the --location to change the region)
+
Create a new free Windows App Service plan (in Central US)
+
Create a Windows webapp
+
Deploy the content of the current working directory to the webapp using Zip Deployment
+
+To Install the Azure CLI tools refer to their documentation.
+
+To Install the extension:
+
az extension add --name webapp
+To update the extension with the latest fixes and new languages support (Current version is 0.2.0):
+
az extension update --name webapp
+To know what the command will do without creating anything:
+
az webapp up --name [app name] --location [optional Azure region name] --dryrun
+To use the new command:
+
az webapp up --name [app name] --location [optional Azure region name]
+To update your app content - Just rerun the command you used to create the app (including the --location argument):
+
az webapp up --name [app name] --location [optional Azure region name]
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
To further our commitment of providing the latest in cloud innovation for each and every one of our customers, we're excited to announce the availability of Azure Functions in three separatenational clouds- China, Germany and United States Government.
+National or sovereign clouds are physically and logically network-isolated instances of Microsoft's cloud service, which are confined within the geographic boundaries of specific countries and operated by local personnel. These clouds offer a unique model for local regulations on service delivery, data residency, access and control.
+Functions in the national clouds provides the same functionality and features as globalAzure. The rich portal experience allows youto create, manage and monitoryour functions. You can develop using C#, F#orJavaScript and integrate with a wide variety of servicesusingtriggers and bindings.
+
+As always, you can pick from a range of tools such as the cross platform CLI, Visual Studio IDEand VS Code to develop, debugand test locally, before deploying your apps to Azure.
+Known Limitations
+
+
Currently, Functions in the national cloudscan only be hosted in an App Service Plan. Each plan requires you to defineaspecific region, number of VM instances in that region and size of the VMs that must be dedicated to your apps. If your scenario requires the consumption plan, please let us know by submitting a feature request onUserVoice.
+
Basic monitoring is available through the functions logs and the monitoring tab in the portal. A richer experience with more analytics options will be available once Azure Application Insights is available in the national cloud regions.
+
+Next Steps
+Here are some resources to help you get up and running with Functions:
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+In May 2018, Azure App Service will update the PHP stacks to the latest available versions (including MSSQL Drivers for PHP 7.2). For information on the changes in the new versions, please see the change logs on the PHP website.
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Free and Shared apps now support HTTPS only configuration
+Last year we enabled the ability to force HTTPS connection for your apps hosted on app service and we are now extending support to also cover apps hosted in free and shared App Service plans.
+
+
+
Quality of life improvements for App Service Certificates and App Service Domains
+Over the last 2 months we have fixed over a dozen issues both in UX and back-end to improve reliability and reduce the incidence of most common user issues in these areas.
+
Azure Function on National Clouds
+Azure functions is now available for National Clouds
+
+
+
+
+
+
+
+If you have any questions about any of this features or App Service in general be sure to check our forums in MSDN and Stack Overflow.
+
+For any feature requests or ideas check out our User Voice
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
The App Service Environment, with Isolated pricing plans, is now available in the US Government regions. The App Service Environment is a deployment of the Azure App Service and runs in your Azure Virtual Network. With an App Service Environment you have more options for:
+
+
High scale
+
Network isolation
+
High memory utilization
+
+The App Service Environment can be deployed with an internet accessible endpoint or with an endpoint on a private address in your Azure Virtual Network. This makes the App Service Environment a great solution to host your line of business applications or those applications that you want to only expose through a web application firewall such as the Azure Application Gateway.
+
+To learn more about the App Service Environment start with the Introduction to the App Service Environment
+
+To create an internet accessible App Service Environment you can start with Creating an External App Service Environment To create an App Service Environment with a private address you should use Create and use an internal load balancer with an App Service Environment
+
+If you are interested in how to couple an App Service Environment with a web application firewall, we have a write up on Integrating your App Service Environment with an Application Gateway
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
You can use EV SSL with Azure web apps. There are many CA that provide EV SSL for your web applications and the two options you have to use EV SSL with azure web app :
+
+
Option 1 : Bring your own certificate and upload to web app
+Contact your CA to get instructions on how to export your EV SSL into PFX format . Then follow the instructions to upload this certificate into your web app . Once the certificate is uploaded , add an SSL binding to your web app .
+
Option 2 : Buy a certificate via Key Vault and import to Web App
+Azure Key Vault supports both DigiCert and GlobalSign CA providers to purchase ORG SSL and EV SSL. You can purchase a EV SSL from either of these providers . Follow instructons on how to purchase and configure a EV SSL from these providers into Key Vault
+
+Place the certificate (PFX format ) in Key Vault and then follow the instructions here to import the Key Vault as an App Service Certificate .
+
Troubleshooting Issues
+In the Azure portal , go to your App Service Certificate using this Key Vault resource for your EV SSL certificate . Follow the steps below to troubleshoot issues :
+
+
Key Vault may have moved to another subscription or deleted or in a suspended state : In the portal , when you open your App Service certificate you will see the status "Key Vault out of Sync " . In this case , click on the status tile which will prompt you to reconfigure your Key Vault to App Service certificate to a valid Key Vault . Note the Key Vault must be in the same subscription as the App Service certificate
+
Key Vault secret was updated but I still see the old secret in App Service certificate : Web App service runs a background job that periodically (once a day ) that syncs all App Service certificate. Hence when you rotate or update a certificate, sometimes the application is still retrieving the old certificate and not the newly updated certificate. This is because the job has not run to sync the certificate resource. To force a sync of the certificate , you can click on Rekey and Sync setting and then click on Sync button .
+
+
+
+
Documentation Support : Checkout our FAQs for more details if you run into any issues managing your App Service Certificate
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
The Azure App Service team is happy to announce the global deployment of support for the HTTP/2 protocol for all apps hosted on App Service. HTTP/2 has been the top customer request we have received, and we are excited to light up support!
+
+
+
What is HTTP/2?
+HTTP/2 is a rework of how HTTP semantics flow over TCP connections, and HTTP/2 support is present in Windows 10 and Windows Server 2016. HTTP/2 is a major upgrade after nearly two decades of HTTP/1.1 use and reduces the impact of latency and connection load on web servers.
+
+The major advance of HTTP/1.1 was the use of persistent connections to service multiple requests in a row. In HTTP/2, a persistent connection can be used to service multiple simultaneous requests. In the process, HTTP/2 introduces several additional features that improve the efficiency of HTTP over the network.
+
One connection for multiple requests
+Every TCP connection requires a round trip to set up. If you're using encryption, the TLS handshake takes another 1-2 round trips. All this happens before the first byte of the first response can be sent. By reusing an existing connection instead of setting up a new one, this overhead can be shared by many requests. HTTP/2 sharply reduces the need for a request to wait while a new connection is established, or wait for an existing connection to become idle. Because a single connection is multiplexed between many requests, the request can usually be sent immediately without waiting for other requests to finish.
+
Header compression with HPACK
+HTTP has supported compression of data for ages. Headers, however, are sent as uncompressed text, with a lot of redundancy between requests. (Many of the longest headers are sent with exactly the same value on every request!) HTTP/2 introduces HPACK, a compression scheme for HTTP headers which reduces the redundancy between requests.
+
+Compression also helps multiplexing, because requests are smaller. This enables clients to make many requests in their first packets on a connection, while TCP flow control windows are still small.
+
+What are the key differences from HTTP/1.x?
+
+
HTTP/2 is binary
+
Fully multiplexed, instead of ordered and blocking
+
Ability to use one connection for parallelism
+
Has one TCP/IP connection
+
Uses header compression to reduce overhead
+
+
+
What action do App Service users need to take?
+All you need is a just a simple configuration! HTTP/2 is disabled by default for all customers. However, if you would like to opt-in and apply HTTP/2 for your site, follow the steps below:
+
+Through the Azure Portal, browse to your app and search for the "Application settings", where you will find the setting called "HTTP Version". Select 1.1 or 2.0 by your needs.
+
+
+
+You may also browse to the Azure Resource Explorer using one of the following steps:
+
+
In the Azure Portal, select “Resource explorer” in your App Service app’s menu.
+
+The advantage of going through the Azure Portal route is that the browser will be automatically navigated to your requested app’s configuration, then you just have to navigate to config > web, where you will find the needed value to update.
+
+If browsing directly to Resource Explorer, drill down through the tree hierarchy to your site using the following path:
+
+Subscription > Resource Group > your site name > Providers > Microsoft.Web > sites > your site name > config > web
+
+
+
+On the top of the page make sure you’re in Read/Write mode:
+
+
+
+Select Edit:
+
+
+
+Find the parameter for HTTP/2:
+
+
+
+Type in ‘true’ in place of ‘false’:
+
+
+
+On the top, select ‘PUT’:
+
+
+
+You’re done!
+
+
Support for HTTP/2 in App Service Environments and the Azure National Clouds is available as well!
+
+
HTTP/2 Browser Support Requires SSL
+Most modern browsers only support using the HTTP/2 protocol over SSL, while non-SSL traffic continues to use HTTP/1.1. App Service makes it easy to get up and running with SSL. Learn how to configure a new SSL cert for your app, or learn how to bind an existing SSL cert to your app. App Service also provides a default level of SSL functionality for all apps via a common wildcard SSL certificate bound to the *.azurewebsites.net domain. Regardless of which approach you choose, your apps will need to run over SSL to enjoy the benefits of HTTP/2 with modern browsers.
+
What if I encounter an issue?
+If you find an issue you suspect is stemming from the update to HTTP/2 you can alert us through the following methods:
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Following our communication earlier in the year, the App Service team is happy to announce that the ability to explicitly configure the TLS version for individual applications, is now available.
+
+
+
What is TLS?
+Transport Layer Security (TLS) is a protocol that provides privacy and data integrity between two communicating applications. It's the most widely deployed security protocol used today, and is used for web browsers and other applications that require data to be securely exchanged over a network, such as file transfers, VPN connections, instant messaging and voice over IP.
+
+Multiple versions of TLS are available, with each being released at a different time and mitigating different vulnerabilities. TLS 1.2 is the most current version available for apps running on Azure App Service.
+
Why should I update my TLS version?
+The PCI Security Standards Council has stated that June 30th, 2018, is the compliance deadline for disabling early TLS/SSL versions and implementing more secure protocols for your applications’ traffic. Customers requiring PCI compliance should move away from TLS 1.0, and onto TLS 1.1, though it is highly recommended to instead move directly to TLS 1.2.
+
How can I test my connection and assess my risk?
+Most traffic going to apps hosted on Azure App Service is originating from modern Web Browsers updated to recent versions. SSL traffic originating from out-of-date browsers may not support newer TLS versions like TLS 1.2. In order to test your app’s compatibility with updated TLS versions, we suggest testing with one of the various 3rd party solutions to test traffic to your apps like SSLLabs. After updating the TLS setting for your app, you may use SSLLabs to test and see if lower versions of TLS are not accepted any more.
+
What’s next for App Service hosted apps?
+At the time of releasing this blog, all applications running on public multi-tenant App Service hosted platform, including Azure Functions, apps hosted on the Azure National Clouds and App Service Environments (ASE), can update settings to select the TLS version that is required.
+
+From June 30th, 2018, all newly created App Service apps will automatically have TLS 1.2 selected as the default configuration. Though not recommended, we are allowing users to downgrade the TLS version if desired.
+
How can I update the setting to select my required TLS version?
+In the Azure Portal, go to your App Service app’s menu, select SSL Setting and select the toggle to the version you require. Auto-save of the selection is enabled. Please allow a few minutes for the setting to be reflected in the monitoring tools.
+
+
+
+
TLS configuration through CLI and PoweShell will be coming soon.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
I usually find myself looking for the bookmarks I have for different command line docs and issues pages. Here is the one place for all the resources for our command line tools, this includes our new "az webapp up" experience, Azure CLI experience, and Azure PowerShell experience.
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+Azure app service is a multitenant infrastructure. When web apps are created on azure app service, we provide a default hostname which is sitename.azurewebsites.net. Clients can make requests over HTTP or HTTPs to these hostnames. When using HTTPs against the default hostname for the site, a certificate with subject name *.azurewebsites.net is returned to the client for SSL.
+
+When customers configure an app service with a custom domain name, by default the system allows you to pick between an SNI-SSL binding type or IP-SSL binding type.
+
+SNI-SSL bindings are free of cost. For an SNI binding to be in use, clients making requests to this host will need to include an SNI header in the TLS initial handshake message. From a specification standpoint, TLS 1.0 supports SNI header extension, and all modern browsers includes the SNI header by default.
+
+In contrast, there can be older versions of browser clients or legacy library clients. For custom domains to work correctly for these clients, the site must be configured to have IPSSL bindings.
+
What is SNI and IP-SSL really and why does it matter?
+When the initial SSL handshake request arrives at a web server, the mandatory parameters like the version of SSL being negotiated, the cipher suites the client supports are included in the clear text CLIENT HELLO message. From the server standpoint, with this information, the server needs to select the appropriate certificate to use for this request. For a web server with a single site/hostname, the matter is easy, you can configure the server with just one binding/certificate on a single port and all is fine.
+
+However, in a webserver which hosts multiple sites or hostnames, based on the version + cipher suites alone, the server cannot pick the correct certificate. Hence, this requires the bindings on the server to be configured based on a different IP for each of the hostname the server wishes to support.
+
How does SNI help?
+To solve the problem of not requiring unique IP address on the server side to support multiple hostnames with SSL, the concept of an SNI extension was introduced in RFC 3546 [https://tools.ietf.org/html/rfc3546], back in 2003.
+
+Per this spec a client can include the destination host name in the clear text CLIENT HELLO message as an additional server name extension. Now, at the server, based on this information, the server can select the appropriate certificate to use for the handshake, thus solving the problem of not requiring unique IP addresses.
+
Why does Azure App Service support both SNI-SSL and IP-SSL bindings?
+While the RFC for SNI was introduced in 2003, and all major browsers added support shortly after that, there are still legacy HTTPs clients which doesn’t include the SNI header extension in the client hello. If an azure app service customer anticipates such a client to use their site hosted in azure app service, it is recommended to add an IP-SSL binding, so that this site now has a dedicated IP Address. This allows us to pick the correct certificate for that hostname.
+
What are the breaking changes with TLS 1.2 compliance initiative?
+We now enforce TLS 1.2 for clients which arrive without SNI header. Note that these are typically old browser clients which do not support SNI or programmatic clients which were written long ago and not updated to include the SNI header name.
+
+
For sites which did not have a custom domain name configured:
+
+These hostnames are always SNI-SSL (or more like SNI-Required).
+
+For these sites, the hostnames used is the default sitename.azurewebsites.net. Customers can configure the minimum required TLS version on this site to be 1.0 and above, and we will honor it.
+
+However, if a request arrives without the SNI extension in the CLIENT HELLO message, we are unable to identify the exact site the request is eventually destined to, and hence we require this request to be at least of TLS 1.2 for compliance reasons.
+
+
Sites with custom domain configured:
+
+
+
SNI -SSL:
+
+For these sites just like default host name, the configuration for the minimum required TLS version can be set and will be honored by the system. However, if a request arrives without the SNI extension in the CLIENT HELLO, we require this client to at least negotiate TLS 1.2, just like the case of default hostname.
+
+
IP-SSL: No breaking change, everything should continue to work as is.
+
+For IP-SSL bindings, since there is a dedicated IP for the hostname, our system can correctly determine the destination site based on the incoming IP address, and hence there is no requirement of SNI header or minimum TLS version requirement on requests without the SNI header. The minimum configured TLS version for the web app will take effect.
+
I'm currently using SNI-SSL bindings: What do I do if I'm impacted?
+For browser clients, upgrade browser clients to modern browsers. For security best practices, it is highly recommended to use modern up to date browsers to protect the site and the user.
+
+For programmatic scenarios, update application code to either use TLS 1.2, or explicitly include the hostname in the client hello handshake if using TLS 1.0
+
+To update the TLS version in a .NET app using HttpWebRequest or HttpClient, update the SecurityProtocol in the ServicePointManager as shown below.
+
+
+
// To update the TLS version in a .NET C# app using HttpClient/HttpWebRequest,
+
+ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
+
+
+
Note that when using HttpWebRequest/HttpClient class to make SSL requests, SNI header is automatically added.
+
+
+
+If both a) and b) are not an option, the last resort and the least preferred option, would be to use IP-SSL bindings.
+
+
If you are using the default hostname, then you will need to add a custom domain name with IP-SSL.
+
If you are already using a custom domain name, you'll need to change the binding to IP-SSL.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Recently, we released a collection of over 50 tips and tricks for Azure Functions that we're calling "Functions Recipes". Each recipe demonstrates a single, useful concept for working with Azure Functions.
+
+They include patterns and practices, integrations with other services, and tips that you may have overlooked when reading the documentation. With every recipe, you get a short code sample, key takeaways, and links to detailed documentation to learn more.
+
+Our goal is to create a comprehensive collection of recipes that you can quickly reference when you're working on your serverless projects with Azure Functions. If you want to see how triggers and bindings work, set up proxies, integrate with Cosmos DB, or even collect telemetry with Application insights, we want to be a resource that adds value to your workflow.
+
+
+We're only getting started. We'll be expanding the collection with even more recipes (we just added 11 new ones on Durable Functions). We launched with recipes in C#, but we are starting to add other languages such as JavaScript, Java, F#, Python, and more.
+
We need your help!
+If you have a recipe idea or updates to suggest, create an issue or submit a pull request at the Microsoft Docs Sandbox repository on GitHub. Contributing is as easy as clicking the "edit" button on any of the pages.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Today, we are excited to announce the public preview of Linux on App Service Environment (ASE). Finally, our Linux customers will be able to take advantage of deploying Linux web apps into an App Service Environment, which is perfect for deploying applications into a VNet for secure network access or apps running at a high scale.
+
What can you do with Linux on ASE?
+With Linux on ASE, you can deploy your Linux web applications into an Azure virtual network (VNet), by bringing your own custom container or just bring your code by using one of our built-in images. Additionally, both Windows and Linux/containerized web applications can be deployed into the same ASE, sharing the same VNet. You will be using the Isolated SKU with Dv2 VMs and additional scaling capabilities (up to 100 total App Service plan instances, between Windows and Linux, in one ASE), previously not offered in Linux.
+
+
+There are two different kinds of ASEs that you can create: an external ASE with an internet accessible endpoint or an internal ASE with a private IP address in the VNet with an internal load balancer (ILB). Steps to get started are provided here.
+Currently, Linux on ASE is available in these 6 regions: West US, East US, West Europe, North Europe, Australia East, Southeast Asia
+Public Preview Pricing
+
+
During the public preview, you will receive a 50% discount on the Isolated SKU prices on the pricing card that applies to your App Service Plan (ASP). There is no discount on the ASE itself (it will still cost ~$1000/month USD for the ASE, regardless the size of the ASE).
+
+
Things You Should Know
+
+
Please create a new ASE to try out this feature. Because deploying Linux apps in an ASE is a preview feature, deploying a Linux app in an ASE that you previously made before this preview may have some performance impacts.
+
You will be able to deploy both Windows and Linux web apps into the same ASE. Remember that even though Windows and Linux web apps can be in the same App Service Environment, Windows and Linux web apps have to be in separate App Service Plans.
+
Because this feature is in public preview, please do NOT deploy a Linux app or container into an ASE you want fully supported. Adding a Linux app to an ASE means that the ASE will be in preview mode.
+
Especially for those new to App Service Environment, how long will everything take to deploy?
+
+
Because an ASE gives you a fully isolated and dedicated environment for securely running App Service apps at high scale, there are many different parts that we provision for you upon creating a web app in an ASE. Instead of sharing front ends, you will have dedicated front ends that are responsible for HTTP/HTTPS termination and automatic load balancing of app requests within the ASE.
+
Therefore, when deploying a web app into an ASE or performing a scaling operation, the operation can take a couple of hours or more. This is not a promised SLA.
+
We recommend that you scheduling your scaling operations to account for the time it takes for any extended scaling processes.
+
+
+
+
How to Get Started
+You can create a Linux web app into a new ASE by simply creating a new web app and selecting Linux as the OS (built-in image) or Docker (custom container) or creating a new Web App for Containers (custom container). When creating a new App Service Plan, remember to select one of the 6 supported regions and select one of the Isolated SKUs.
+
+
+
+Because Linux on ASE is now in public preview, we would love to hear all of your feedback and questions about the product here. Start creating your first Linux/containerized web app into an ASE by following these instructions.
+
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Following our communication earlier in the year, the App Service team is happy to announce that the App ServiceAuthentication/Authorization featureis now available to Linux apps.
+
What’s App Service authentication/authorization feature?
+Azure App Service provides built-in authentication and authorization support, so you can sign in users and access data by writing minimal or no code in your web app. The same authentication and authorizationfeature support for Windows apps is now available to App Service on Linux including Web App for Containers. This overview article describes how App Service helps simplify authentication and authorization for your app.
+
Is the feature behavior different on Linux?
+No. The authentication and authorization works the same way on Linux apps as Windows. The configuration experience on Azure portal and CLI is exactlythe same, if you’re familiar with how to configure a Windows app for this feature, you’re ready to go and can do the same for a Linux app.
+
I’m a Linux customer new to this feature, how do I configure it for my Linux app?
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Have you ever had issues with an unhealthy web app? Last year, we launched App Service Diagnostics, an intelligent and guided troubleshooting experience that points you and the right direction to diagnose and solve issues of your web app (without having to configuring anything special to enable this feature!). Since then, we’ve read all the feedback that you all have given, and have added new capabilities to make this feature even more robust and insightful, all without you have to configure anything special.
+
New Tile Shortcuts for Management and Configuration
+When you visit App Service Diagnostics (by clicking on Diagnose and solve problems in the left-hand menu), you will be greeted by Genie, who will point you in the right direction to start troubleshooting your issue. If you have some experience or know a little bit about the nature of the issue, you should select one of the tile shortcuts that match your problem category. We have now added parent problem categories, such as Availability and Performance, to help keep the tile shortcuts organized.
+
+If you don’t know where to start, Genie will also allow you to run a health checkup, which will run several checks on our backend and intelligently highlight where you’re experiencing an issue.
+
+
+
+Our newest tile shortcuts are in the Management and Configuration problem category. You can now validate your swap operations, use our "Check Best Practices for Prod Apps" tile shortcut to make sure that you're configuring everything optimally for production workloads, and even check if your autoscaling operation is running correctly.
+
App Service Diagnostics is now live for…
+Before, only web app users could get help from App Service Diagnostics. Today, we are excited to announce that you can now leverage App Service Diagnostics to diagnose and troubleshoot issues with not only your Windows web apps, but also your web apps on Linux, App Service Environment, and even Azure Functions.
+
+For each service, we have tailored the troubleshooting problem categories to cater to the most common scenarios that customers have been looking to diagnose and troubleshoot. For example, for Functions, you can now identify scaling issues and analyze functions in error. For App Service Environment, we know that our customers have quite a few questions about networking, so we added a network security group verifier and also a tile shortcut to validate outbound connectivity from your ASE.
+
+For Windows and Linux web apps, navigate to the App Service Portal. Click on Diagnose and solve problems on the left-hand menu.
+
+For App Service Environments, navigate to the App Service Environment Portal. Click on Diagnose and solve problems on the left hand menu.
+
+
+For Azure Functions, navigate to the Functions Portal. Click on the Platform Overview tab, and then click on Diagnose and solve problems under the Resource Management category.
+
+
+
New Diagnostic Tools
+For our more advanced users who are familiar with troubleshooting web app issues, we released a new set of tile shortcuts under Diagnostic Tools (a new parent problem category). These Diagnostic Tools are stack specific and are here to help you dive deeper in investigating issues related to your application code, root causes for slowness, connection strings, and even issues with connecting to a remote server. As always, all of these tools have actionable documentation, which means not only do we tell you a little bit about what the tool does, but also allow you to perform that action right in App Service Diagnostics.
+
+
+Click on Change Stack to view the Diagnostic Tools relevant to your stack of interest.
+
Integration with Application Insights
+Another insight that we’ve heard from our App Service Diagnostics users is about troubleshooting issues in their application code. To help with this beyond distinguishing between platform and application issues, we have integrated with Application Insights to provide code-level insights in context to availability downtimes. Application Insights is Azure’s application performance management and analytics tool that allows you to monitor your application.
+
+Although you do need to configure Application Insights to enable it for your application, once you do, you will be able to see common exceptions that your app is throwing and dependencies that are causing issues under Web App Down and Web App Slow. These are all correlated to the downtimes that you’ve selected via the orange bar. Hopefully, you’ll be able to recognize your application code issues from the commonly occurring exceptions, but if not, we deep link into Application Insights for more context.
+
+
+
+Next time you’re having issues with an unhealthy web app, App Service Environment, or Function, try out App Service Diagnostics to talk to Genie to get guidance on how to cure for your unhealthy web app. If you haven’t already, definitely leverage App Service Diagnostics to run a health checkup for piece-of-mind or drill-down to your specific issue that’s happening to your app.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+Today we are announcing the public preview release of Azure App Service Snapshots. Snapshots are automatic periodic backups available for Premium SKU web apps. Snapshots are managed internally by Azure App Service and provide reliable, hassle-free backups of your web apps.
+
+Snapshots contain both the contents of a web app and the web app configuration. At least 1 snapshot will be available every 6 hours for the past 30 days. Within the past 7 days, usually 1 snapshot will be available per hour.
+
Accessing snapshots in the Azure Portal
+Snapshots can be listed and restored in the Azure Portal from the Backups settings of the web app.
+
+
+
How to list snapshots
+
Azure CLI
+
az webapp config snapshot list -g <resource group> -n <app name>
+Snapshots can be restored to the original web app, a slot of the web app, or any other web app in the same App Service Plan. While the restore operation is in progress, the web app will be stopped. It is strongly recommended to restore snapshots to a new slot instead of overwriting an existing slot in order to prevent data loss if the restore operation is unsuccessful.
+
+Snapshots contain both web app files and web app settings. You can choose to restore files only, or to restore the settings as well. All settings contained in regular backups are also contained in snapshots. However, some settings, like hostnames, certificates, and backup schedules, will not be restored with a snapshot.
+
Azure CLI
+Snapshot commands for Azure CLI are currently available as extensions. To install the extension, run
+
az extension add -n webapp
+If the extension is already installed, update it with
+
az extension update -n webapp
+Restore a snapshot from the production slot to a new slot named SnapshotSlot
+
$snapshotRgName = <resource group>
+$snapshotAppName = <app name>
+$snapshotAppSlot = <slot name>
+$snapshots = Get-AzureRmWebAppSnapshot -ResourceGroupName $snapshotRgName -Name $snapshotAppName -Slot $snapshotAppSlot
+# Create a new slot for the restore operation - highly recommended to prevent data loss!
+$targetSlotName = "SnapshotSlot"
+New-AzureRmWebAppSlot -ResourceGroupName $snapshotRgName -Name $snapshotAppName -Slot $targetSlotName
+# Restore the first snapshot in the list to the new slot. Restore both the configuration and files.
+$snapshots[0] | Restore-AzureRmWebAppSnapshot -ResourceGroupName $snapshotRgName -Name $snapshotAppName -Slot $targetSlotName -RecoverConfiguration -Force
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
The App Service team is happy to announce the public preview of Multi-container support in Web App for Containers.
+
Multi-container Web App Concept
+App Service Linux community has repeatedly asked for the capability to deploy multiple containers for a single App. Customers want to have additional containers to complement the primary container and have these containers form an “operable” unit. The benefits for Multi-container are: 1. customer can separate capabilities such as proxies, cache and storage into additional containers and manage the source code and container images independently following the “separation of concerns” design pattern in containerization; 2. customer can operate those containers as an atomic unit and leverage App Service’s rich feature set for application life-cycle management, scaling and diagnosis, without the needs to stand up a container Orchestrator and to manage the hosting infrastructure by themselves. Today we're happy to announce the public preview of Multi-container support in Web App for Containers!
+
Primary Use Case
+In App Service Linux community, the primary multi-container use case is that customer deploy a stateless web app with multiple containers (Web, Proxy, Cache or Git-mirror) to a single App Service plan. For example: customer can have one container for web frontend and have another container for session cache using Redis, all deployed to the same App Service plan. All containers can communicate to each other through a Docker Bridge network using internal IP addresses.
+
Supported Configurations
+In Public Preview, we support Docker-Compose and Kubernetes configuration format as they’re the “standard” ways to describe multi-container applications. We don’t want to invent another format. It’s also convenient for the customers because the formats are well documented and widely used by Docker community.
+
+Customer can create or configure a Multi-container app from Azure Portal or through Azure CLI. Customer can describe a multi-container app using Docker Compose and Kubernetes configuration format in a yaml file. Customer can upload the multi-container config file through portal UI or point to the URL if the config file is hosted elsewhere (note: URL link support will come soon after announcement), portal screenshot as below.
+
+
+
+For example, customer can use Docker-Compose format to describe a multi-container app:
+
docker-compose.yml
+
+version: '3'
+services:
+web:
+image: "appsvcsample/flaskapp"
+# this image repo's source code come from "Get started with Docker Compose" on docker.com
+ports:
+- "80:80"
+redis:
+image: "redis:alpine"
+CLI command to create a multi-container app:
+
$ az webapp create --resource-group [resource group] --plan [service plan] --name [app name] --multicontainer-config-type "compose" --multicontainer-config-file [path to "docker-compose.yml"]
+CLI command to configure a multi-container app:
+
$ az webapp config container set --resource-group [resource group] --name [app name] --multicontainer-config-type "compose" --multicontainer-config-file [path to "docker-compose.yml"]
+Customer can also use Kubernetes configuration format to describe a multi-container app:
+
my-kube.yml
+
+apiVersion: v1
+kind: Pod
+metadata:
+name: python
+spec:
+containers:
+- name: web
+image: appsvcsample/flaskapp
+# this image repo's source code come from "Get started with Docker Compose" on docker.com
+ports:
+- containerPort: 80
+- name: redis
+image: redis:alpine
+CLI command to create a multi-container app:
+
$ az webapp create --resource-group [resource group] --plan [service plan] --name [app name] --multicontainer-config-type "kube" --multicontainer-config-file [path to "my-kube.yml"]
+CLI command to configure a multi-container app:
+
$ az webapp config container set --resource-group [resource group] --name [app name] --multicontainer-config-type "kube" --multicontainer-config-file [path to "my-kube.yml"]
+
Samples
+We're working to add more Multi-container web app samples. To get you started quickly, please feel free to copy the samples provided in this blog post, or download more from Github.
+
Scaling Multi-container Web App
+Customer can scale up and / or out a stateless multi-container app just as any web apps hosted on App Service, using the same scaling features provided by App Service.
+
+If you would like to use a database in container for dev/testing purposes in a single-host app, please make sure to use the persisted shared storage to store your database files, so the database files can be persisted during app restarts. First, you should enable the App Service shared storage following the instructions at here. Then, you should mount the shared storage to a directory within the Docker container where you store the database files, a MySQL example in docker-compose.yml:
+
+If you would like to scale out a multi-container app to multiple hosts in an App Service plan and use the app for production purpose, we strongly recommend you use Azure Database services instead of putting the database in a container. For example, for a WordPress app you can move the database to an Azure Database for MySQL. To do that, please follow the following steps:
+
Modify your docker-compose.yml to use Azure MySQL instead of local MySQL server, for example, if you have a WordPress app connect to a MySQL database, you can pass the following environment variables in docker-compose.yml:
+
+
WORDPRESS_DB_HOST: [mysql server name].mysql.database.azure.com
+ WORDPRESS_DB_USER: [db user name]@[mysql server name]
+ WORDPRESS_DB_PASSWORD: [database password]
+
+
Test the configuration locally with docker-compose up before you push it to App Service.
+
+
Limitations in Public Preview
+We wanted to put this feature out as soon as possible so customer can validate and provide more feedbacks during Preview. There are certain limitations in this Public Preview release.
+
+We support Docker-Compose and Kubernetes format to describe a multi-container app, but we don’t support all their configuration objects during Public Preview. Our goal is to support any configuration objects that are meaningful to App Service during this release. The supported objects and limitations are as follows:
+
Docker-Compose
+Supported configuration in Public Preview:
+
+services
+
+A service definition contains configuration that is applied to each container started for that service, much like passing command-line parameters to docker container create.
+
+image
+
+Specify the image to start the container from. Can either be a repository/tag or a partial image ID.
+
+ports
+
+Expose ports by mapping ports in the HOST:CONTAINER pattern, recommend explicitly specifying your port mapping as string. App Service specific, we would only expose one service port to external, we would identify a single service port to expose to external based on the HOST port provided for each service, we're looking for port 80 or port 8080.
+
+environment
+
+Add environment variables. You can use an array as input. The dictionary format is not supported in current release, we will add support for dictionary format in next release.
+
+volumes
+
+Mount host paths or named volumes, specified as sub-options to a service. We support both persisted volume and non-persisted volume. To use the persisted volume, please enable the shared storage by set WEBSITES_ENABLE_APP_SERVICE_STORAGE=TRUE. You can reference the shared storage using ${WEBAPP_STORAGE_HOME}.
+
+For example, you can mount the shared storage to /tmp in the container:
+
+command
+
+Override the default command. Currently we support the collection format, for example: command: ["bundle", "exec", "thin", "-p", "3000"]. We will add support for a single string after public preview.
+
+entrypoint
+
+Override the default entrypoint.
+
+restart
+
+“no” is the default restart policy, and it does not restart a container under any circumstance. When “always” is specified, the container always restarts. More info at https://docs.docker.com/compose/compose-file/#restart.
+
+Configuration not supported in Public Preview:
+
+(besides the list below, any other Docker-Compose syntax not explicitly called out in the “Supported Configuration” section will not be supported in Public Preview)
+
+build
+
+Configuration options that are applied at build time. We don’t support “build” image locally as we need an explicit image to start the container with.
+
+depends_on
+
+Express dependency between services. we don’t currently support “depends_on” to specify the dependencies among containers, but we plan to support this shortly after Public Preview.
+
+networks
+
+Networks to join. We don’t support additional “networks” as we run all containers on one Bridge network.
+
+secrets
+
+Grant access to secrets on a per-service basis using the per-service secrets configuration. We don’t currently support it, but we plan to support this shortly after Public Preview.
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
The App Service team is happy to announce the Public Preview of a new SSH experience and the remote debugging capability for Linux app developers. In this release, we're also enabling SFTP (Secure File Transfer Protocol) for Linux web app content management.
+
What’s new?
+We’re introducing a new TCP tunneling technology for Azure App Service, which enables SSH/SFTP access and remote debugging for Linux Web Apps.
+
+We’re enabling Linux app developers to SSH into an app container using any SSH client at your choice. Previously we only enabled the SSH access through a Kudu web client. Based on Linux customer’s feedbacks, we’re adding support for any SSH clients to connect to app container.
+
+We’re also enabling SFTP for managing web app content and downloading logs, in addition to the already supported FTP and FTPS protocols.
+
+With the new remote debugging capability for Linux Web Apps, developers can now set break points in a code editor and live debug an web app running in App Service on Linux or Web App for Containers. We will publish additional blogs for know-how on remote debugging in the next several weeks.
+
How do I configure my dev machine for SSH/SFTP and remote debugging?
+We use TCP tunneling technology to create a network connection between your dev machine and App Service over an authenticated WebSocket connection. We included the TCP tunneling technology in Azure CLI. First, make sure you have the latest Azure CLI installed. To enable the tunneling from your dev machine, you need to install Azure CLI "webapp" extension. If you install the extension for the first time, use this command:
+
az extension add --name webapp.
+If you have an existing webapp extension, use this command to upgrade:
+
az extension update --name webapp.
+Once the extension is installed, run the following CLI command to create a TCP tunnel to App Service:
+
az webapp remote-connection create –g [resource group] -n [app name] -p [local port to open]
+The command line output on a Linux terminal will be something like this:
+
Port [number] is open
+Tunnel is ready! Creating on port [number]
+Starting local server...
+Now, your dev machine is configured for any general purposed remote debugging and SSH/SFTP access for the web app as you specified in the remote-connection create command.
+
+Please note: in the Public Preview, for a given app we only support a single TCP tunnel at any given time. We plan to remove this limitation in future releases after Public Preview.
+
+How do I SSH into app container from a Linux terminal?
+
+First, please make sure your web app is enabled for SSH. If you use App Service on Linux (blessed images), the SSH is enabled by default. If you use Web App for Containers (custom images), please follow the instructions here to enable SSH access in app container.
+
+Tips for SSH to work correctly in your container:
+
+
Make sure you remember the pre-defined SSH password that is set in your Dockerfile. We recommend that you install SSH server and set the user/password in Dockerfile as follows:
Please remember to start the SSH service in your container startup script.
+
+Second, make sure you create a TCP tunnel to the remote web app, if not, please run the CLI command provided in “configure my dev machine” section.
+
+Once the TCP tunnel is established, you can simply run the following command in Linux terminal:
+
$ ssh root@127.0.0.1 -p [local port created for TCP tunnel]
+Similarly, you can SSH to app container from a Mac or Windows machine.
+
+Now, you can go party with SSH!
+
How do I use SFTP to manage web app content?
+Like SSH, please make sure your app container is enabled for SSH access, refer to the SSH section above for instructions. And run the same remote-connection create command to establish a TCP tunnel.
+
+If you don’t have one, install a SFTP client such as WinSCP, connect the client to localhost at 127.0.0.1 and a port number that is created for TCP tunnel, use the SSH user name and password to login. Now you can manage the site content stored in /home/site/wwwroot using the SFTP client.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
The App Service team is delighted to announce a revised scaling experience between Basic, Standard, and Premium App Service plans that will make it easier for customers to scale up to more performant VMs at the same price point.
+
+Central to this announcement is a 20% price reduction for Pv2 App Service plans.
+
+This change makes the P1v2 App Service plan the same price as the current S2 App Service plan, making it possible for customers to scale directly from S2 to P1v2. Giving them a more performant Dv2 based instance with 2X memory and an SSD drive at the same price as the S2 offering.
+
+With the 20% Premium V2 price reduction we also have a new scaling experience which highlights the ability to move directly from S2 to P1v2. Pricing tiers are now grouped by their target workload into Dev/Test, Production, and Isolated with recommended scale guidance provided.
+
+
Dev/Test includes the Free, Shared and Basic App Service plan options
+
Production includes Standard, Premium and Premium v2
+
Isolated includes the scale options for App Service plans hosted in an App Service environment.
+
+
+If you have any questions about any of this features or App Service in general be sure to check our forums in MSDN and Stack Overflow.
+
+For any feature requests or ideas check out our User Voice
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
We are continuously taking steps to improve Azure Platform security. As part of this ongoing effort an upgrade of App Service is planned for all regions during the first part of May.
+
Changes to deployment options
+When this upgrade is complete Web Apps will provide the following configurations with the option to change your default setting.
+
+Today your apps can be accessed through the legacy FTP protocol (using credentials over plain text) as well as the more secure FTPS protocol (not to be confused with SFTP). Once the upgrade is complete you will be able to configure your apps to continue to use FTP and FTPS, limit access only over FTPS or completely disable FTP access.
+
+
+
+
+
+You can find these options in the Azure Portal under your app's menu: Application Settings > FTP Access
+
Whats next
+In early July all new apps will default to FTPS only access. Users will continue to have the option to configure this as needed. Any previously created apps will retain their existing FTP/FTPS configuration with the option to change as needed.
+
Best practice
+As a best practice we recommend using FTPS for deployments. Doing so will ensure that your data transmissions are encrypted which helps address regulatory guidelines for security.
+
+If you have any questions about this feature or App Service in general be sure to check our forums in MSDNand Stack Overflow. For any feature requests or ideas check out our User Voice
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+In June 2018, Azure App Service will update the PHP stacks to the latest available versions. For information on the changes in the new versions, please see the change logs on the PHP website.
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+Now you can bring your Kubernetes Pod Definitions or Docker Compose files to App Service and run multi container solutions in a fully managed PaaS solution with all the App Service features and ease of use you are already familiar with. Learn more about these scenarios in our announcement blog.
+
+
Linux and Docker on App Service Environments
+You can now create Linux and Docker apps in your App Service Environment to take advantage of the advanced scaling and networking features. Learn more in the announcement blog.
+
New App Service plan options for Linux and Docker on App Service
+Now you can get started with Linux and Docker on App Service with a free B1 App Service plan for 30 days.
+
+
+As well as access to the more powerful and cost effective PV2 Instances for production workloads.
+
+
+
App Service Authentication/Authorization for Linux Apps
+You can now enable Authentication/Authorization on your Linux App Service Apps just as easy as you do for Windows hosted apps. Learn more in our announcement blog.
+
Docker Logs in portal
+You can now access your Docker logs directly form the portal under Container Settings.
+
+
Azure Functions on Linux and Docker
+Earlier in the year we started the preview of Azure Functions on Linux, we are now extending this by including Docker as another hosting option.
+
+
New Functions Monitoring powered by Application Insights
+Application Insights is the preferred monitoring solution for Azure Functions and we have made enabling it super easy.
+
+
TLS configuration
+You can now define the minimum TLS version for your apps. You can find this setting under SSL Settings. This feature applies to Windows, Linux and Docker Web apps, Mobile apps and API apps as well as Azure Functions. Learn more in our announcement blog.
+
+
Fine grain FTP configuration
+You can now configure FTP to enforce connections over FTPS or disable this publishing endpoint completely. This feature applies to Windows, Linux and Docker Web apps, Mobile apps and API apps as well as Azure Functions. Learn more in our announcement blog.
+
+
+
+
+
Snapshots: a new way to back up your App
+Snapshots is a new premium feature for backing up the content of your app. You can find it under Backup in the left menu. Learn more in our announcement blog.
+
+
New pricing options and scale up experience
+We have revised the pricing for App Service instances and re-vamped the experience to provide more information and make it easier to choose the right size for your app. Read more in our announcement blog.
+
+
App Settings now sorted alphabetically
+This feature was one of the top 10 most requested features in our UserVoice forum and we are happy to deliver.
+
+
+
+
+If you have any questions about any of this features or App Service in general be sure to check our forums inMSDNandStack Overflow.
+
+For any feature requests or ideas check out ourUser Voice
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
This morning we released the second update to Azure App Service on Azure Stack. This release updates the resource provider and brings the following key capabilities:
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+We are happy to announce a new preview experience for setting up deployments to Azure App Service.
+
+Deployment Center is a centralized overview for all of the deployment options available to you. It also provides a guided experience to set up your deployments.
+
+With the new UX you can now search and filter through your repositories and branches making navigation through large code repositories easier.
+
+
+
+We have also revamped the access to log files making them easier to find and consume.
+
+
+
+Other improvements include:
+
+
+
+All of these improvements are geared to help developers understand what version of their code is currently deployed in their app.
+
+
+
+Deployment credential management is now contextualized to your deployment provider/method of choice.
+
+It is now easier to set and re-set credentials from the deployment center without having to visit another UI or abandon the flow.
+
+
+
Preview Limitations
+
+
This preview is currently available for Windows hosted apps and we plan to extend this to Linux and Functions in the coming months.
+
You must be part of the Owner role in the subscription to use this feature, we plan to remove this limitation in future releases.
+
+If you find any issues with the preview you can report a bug here
+
+For any questions about any of this features or App Service be sure to check our forums inMSDNandStack Overflow.
+
+For any feature requests or ideas check out ourUser Voice
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
The Diagnostic Tools options under the Diagnose and Solve blade for Azure App Services has been live for a few months now and has many tools that help you troubleshoot apps based on their application stack. In this post, we are going to cover the Collect .NET Profiler Trace option in detail and how you can use it to troubleshoot a slow or a failing ASP.NET based Web App.
+
+
+
+Profiler tool helps in collecting an on-demand trace that lets you identify the underlying .NET exceptions, time taken in the various request processing pipeline stages and even lets you drill down into exact methods within the application code that are taking time. It is extremely useful in situations where the problem is happening right now and you want to collect some data to identify the root cause of the issue. Profiling is designed for production scenarios and is based on ETW (Event tracing for Windows) . The analysis component of the profiler uses the TraceEvent library to generate a report that helps you drill down in to the problems in matter of a few minutes. It should be noted that no changes are made to your Web App code or your configuration during the collection or the analysis phase. In fact, the web app is not even restarted as a result of capturing this trace. The captured trace has ETW events emitted by the IIS and the ASP.NET providers along with stack traces captured at the CPU level. You can use this tool to efficiently troubleshoot delays which are relatively small (less than a second too) without impacting the run-time performance of the application. The profiler works for both ASP.NET and ASP.NET core applications.
+
How to Collect the Trace
+To collect the trace, go to Diagnose and Solve Problems and choose the Collect .NET Profiler Trace option under Diagnostic Tools option and click on Collect Profiler Trace. Unless you have isolated that only a specific instance is failing, it is best to just select all the instances on which your Web App is running.
+
+
+Add thread report option - With this option enabled, a thread report of all the threads in the process is also collected at the end of the profiler trace. This is useful especially if you are troubleshooting totally hung processes, deadlocks or requests taking more than 60 seconds. This will pause your process for a few seconds until the thread dump is generated. This option is NOT recommended if you are experiencing high CPU on the instance because if the instance is under stress, it might take a long time to even start a new process to collect the thread dumps.
+
+Clicking the Collect Profiler Trace will start profiling the Web App and the wizard will show progress of various steps involved.
+
+
+
+Once the profiler trace is started, reproduce the issue by browsing the Web App. If you have a Web App running on multiple instances, make sure to browse a few more times to ensure that the requests to the web app get captured in the profiler trace. The default duration for which the profiler trace runs is 60 seconds and during this 60 seconds, all the requests that were made to the Web App get captured in the profiler trace. It is important to note that the profiler trace only has information about the requests that were captured in these 60 seconds (It is possible to increase this duration as mentioned below in this article)
+
+After 60 seconds, the profiler automatically stops, and an analysis component gets triggered that starts analyzing the profiler trace that just got captured. After the analysis finishes, a link to view the profiler report for every instance serving the web app is generated and you click on the Open Report button to view the Analysis report.
+
+
+
Understanding the Analysis Report
+The analysis report provides some basic information about the number of requests captured, successful and failed requests, CPU usage of the instance, CPU usage of the web app and request execution information that helps you identify how fast your Web App was responding when the trace was getting captured. This can be used to validate if the trace is useful and if the right set of requests got captured in the trace and if the cause of slowness is related to high CPU on the instance serving the web app or not. The trace file section also has a link to download the trace file.
+
+
+
+For troubleshooting slow or slow or hung web applications, click on Slow Requests tab. This view shows you the top 100 slowest requests that got captured in the trace. It also breaks down the time spent in various modules of request execution in IIS and tries to categorize them in to Platform, Network and Application code to give you a quick indication on where the problem might be.
+
+
+
+
Application Code - represents the time spent in handlers or modules that get invoked either while executing application code (for e.g ManagedPipelineHandler) or those that are closely related to any explicit configuration done for the application (for e.g. RewriteModule). Any external or third party handlers, modules fall in this category. Anything which does not fall in the native IIS handlers or modules is classified as Application.
+
Network - represents the time spent in reading the request entity body from the client or time spent in flushing the response buffer back to the client. Time spent in waiting on external outbound network calls made from the application (like Database, cache, external HTTP requests etc.) is not countedhere and is grouped under Application Code. If requests are spending a lot of time in this category, then it means that there is either a network issue between the client and the web app, the network might be slow or the request and response body is big.
+
Platform - represents the time a request spends in core native modules or handlers of IIS which are pre-installed in Azure App Service (for e.g. DefautlDocumentModule, StaticFileHandler etc.). A request spending too much time in these modules might indicate an overall platform issue so you can contact Microsoft Support to get more details.
+
+The chart also plots the Top 5 handlers or modules in the IIS processing pipeline where the requests spent most of their time and this can give a quick indication as to where the problem might be. In the above example, we see that 83% of the time was spent in PageLoad and 15% of the time was spent waiting in the CLR thread pool queue waiting for the request to be picked up and assigned to a thread pool thread.
+
+In the same section, if you scroll below, you find a list of Top 100 Slow requests with the time taken in request execution and the slowest module for these requests. Note that stack traces will be captured if the request execution delay is on the same thread or if the application code uses Tasks class (from System.Net.Threading) to perform asynchronous IO in the request. There are lot of ways in .NET Framework to achieve asynchronous execution behavior and not all of them can be tracked so it is possible that for those scenarios, there are no stack traces captured for the request. Even for those scenarios, at least the Module name should help in identifying where the delay might be happening and is good indication of where the problem lies.
+
+
+
+So the above information tells us that the slowest request in this trace took around 30 seconds and 99.79% of the time was spent in the the Page_Load event of ASP.NET which tells us that something in the Page_Load caused the request to slow down hence narrowing the issue down to Application Code.
+
+The Profiler tries its best to correlate the stack trace of thread to the slow requests and if it manages to find this information, a light bulb icon is displayed next to the Details view to illustrate that there are stack traces captured for this request. You can click on the Details button to get the stack trace captured.
+
Stack Traces - Thread View
+For a request, the Thread View is shown for requests where the profiler is able to determine that the request execution happened on the same thread and where the delay in request processing happened on the same very thread. It is however possible that the thread view is shown even for ASYNC requests if the .NET Task Scheduler decides to run them on the same thread. It is best advised to look at both the Thread View and Activity view for requests that executed on the same thread to get an idea of methods taking the longest time because at times one view may have more accurate information than the other and might help you go one more step closer to the code that is introducing the delay.
+
+
+
+The stack trace helps us identify the delay is happening while trying to open a SqlConnection from a page named SlowSql.aspx and the function name is demomvp.SlowSql.Page_Load. There is also a toggle button for showing the full .NET Framework stack which shows time spent in all the functions that got executed on this thread and at times is helpful if you want to drill down further within the .NET Framework code to identify methods where time is being spent.
+
+Profiler is able to show the stack traces accurately for requests that have completed in the trace. For requests that started in the trace and have not finished before the trace is stopped, the profiler tries its best to show the time taken but it may not be 100% accurate. Incomplete requests would have a warning icon next to the slow request report and it is suggested to look all the complete requests in the trace to get a better picture of request execution.
+
Stack Traces - Activity View
+If the request has switched multiple threads, you will notice an icon next to the list of requests in the slow request report indicating the request is an async request.
+
+
+
+For asynchronous requests, the profiler report shows you the Activity View and the thread view is not shown. Activity view groups method execution by the activity information which is passed by CLR when using Tasks and the profiler groups similar tasks originating with the same Activity Id and stitches them together to show you this view. Here is an example of an asynchronous request's activity view.
+
+
+
+In the above stack trace, we can see that the method demomvp.AsyncThreadDelaySleep.WaitForSomeTime invoked a new Delay Task and spent 8 seconds awaiting on it. As you can see, by the nature of asynchronous execution, understanding ASYNC tasks is slightly more trickier than synchronous threads but still the profiler report has grouped the right functions together by grouping .NET Activity. To know more about .NET Activities and how they are flown, check out this detailed post - https://blogs.msdn.microsoft.com/vancem/2015/09/14/exploring-eventsource-activity-correlation-and-causation-features/
+
Failed Requests
+For requests, that failed with a HTTP error, the Failed Requests view highlights the HTTP Module or the handler that was responsible for setting the error status code. Clicking on Details will show more information about the failure and will highlight the underlying exception for the request. The profiler tries its best to correlate a request with an exception, however if a request has switched multiple threads (either due to multiple tasks or due to different threading primitives), then the profiler may not be able to correlate the exception with the request.
+
+
+
.NET Exceptions View
+This view shows all .NET exceptions that happened in the process during the trace. The difference in this view vs. the Failed Requests view is that this can include all the exceptions that might have happened on background threads , IO threads or on threads that could not be associated to a request directly.
+
CPU Stacks
+If the process traced also consumed high CPU, then the profiler report would also show you the call-stack of the thread that consumed the maximum CPU and this should help in identifying the function that need to be optimized.
+
+
+
+
+
+In the above example, we can see that there is a ProfilerClassTest.CalculateDiscounts method is taking 4 seconds on the CPU
+
Increasing the duration for the Profiler Trace
+It is possible to increase the default profiling duration by setting an application setting IIS_PROFILING_TIMEOUT_IN_SECONDS with a maximum value of 900 (i.e. 15 minutes). If you configure this application setting to a number more than 900, it defaults to the 60 second value.
+
How to Analyze the trace further ?
+If the profiler report is not able to identify the issue easily, you can use the PerfView tool or Visual Studio to analyze the trace . The trace file generated by the profiler is a *.diagsession file that is supported by these tools. The link to download the trace file is also present in the analysis report in the top section.
+
+We hope this tool helps you identify issues in production easily and lets you optimize your code to better serve your Web Apps.
+
+Happy Debugging !!!
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
We recently announced that all App Service and Functions apps could update TLS configuration. However, after deployment, an edge case scenario was identified involving SNI-SSL which led to SSL analyzing tools such as SSL Labs, showing that TLS 1.0 was still accepted, while higher versions were selected.
+
+We have now completed the deployment which solves the issue for SSI-SSL and will also translate to the reporting tool indicating correctly that lower versions of TLS, mainly TLS 1.0, are indeed blocked.
+
+
+
+To update your TLS configuration, follow one of the methods below:
+
+
In the Azure Portal, in the app's menu, browse to SSL Settings option and select which version of SSL you require.
+
+
+
+
Through CLI, details for the commands are in our documentation.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Securing access between resources is an important part of modern cloud architectures, and we want to make that as simple as possible in Azure. Managed Service Identity (MSI) lets you securely connect to AAD-protected resources without needing to manage or rotate any secrets. If you need to work with a service that doesn't support AAD, MSI makes it easy to work with Azure Key Vault for secure secret management. This gives you secure access to resources without your application needing any bootstrapping secrets.
+
+Today, we are pleased to announce that App Service and Azure Functions support of MSI is now generally available! We are also lighting up support in Azure China, Azure Germany, and Azure Government. Users in those sovereign clouds can get started with the APIs today, and updates to the portal, CLI, and PowerShell for those environments will become available over the next few weeks.
+
+You can get started using MSI today using any app in App Service and Azure Functions by checking out our documentation. Be sure to also check out the new preview support in Visual Studio for using Key Vault with Connected Services. While Key Vault is the most common use case, MSI has also proven a powerful tool for automation tasks, allowing you to easily start working with Azure Resource Manager APIs. You can also connect directly to a variety of services including Azure SQL and Azure Service Bus.
+
+Please note that App Service on Linux and Web App for Containers do not yet support MSI. We are working on this and look forward to giving Linux users the same great turnkey identity story soon.
+
+
UX behavior change
+If you used the feature during preview, you may have noticed that turning MSI off in the portal, CLI, or PowerShell actually just set an app setting: WEBSITE_DISABLE_MSI. This app setting disables the local token service but does not remove the identity itself. Going forward, the "off" indication will change the identity type to "None" which will also remove the identity from AAD. The WEBSITE_DISABLE_MSI app setting will no longer be affected by the enablement/disablement behaviors. We encourage users to move away from this setting if possible, as your site will now show MSI as "on" even if this setting is present. CLI and PowerShell commands will be updated in the coming weeks to remove the preview tag and reflect this behavior change.
+
+
Try it out!
+We're very excited to make our MSI support generally available. It's an extremely powerful tool that dramatically simplifies connecting your application to other resources. Give it a try, and please be sure to share your feedback. As always, you can reach us in the Forums (App Service, Functions) or on UserVoice (App Service, Functions).
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
I'm very excited to announce the availability of Function Proxies in Functions Version 2.x! Function Proxies enable multiple HTTP Functions to be composited together, mock APIs and single page apps to be hosted in Functions, and HTTP requests to be modified in transit. All that functionality is now available alongside Java Functions, .NET Core Functions, and any other 2.x workloads!
+To learn about all the differences and improvements with 2.x going forward, check out our docs
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Back in May at Microsoft Build, we announced the public preview of Multi-Container Web App, which supports the ability for you to deploy multiple Docker images to Web App for Containers. All you have to do is bring your Docker Compose or Kubernetes Config file when creating a new web app. (Here are instructions to get started with Multi-Container Web App).
+
+Since we launched public preview, one of the most frequently asked questions that we've received is: "How do I configure Azure Container Registry with Multi-Container?"
+
+Let me walk you through a quick tutorial that uses Azure Container Registry with Multi-Container.
+
Configure Your Docker Compose/Kubernetes File
+To create a Multi-Container web app, you first need a Docker Compose or Kubernetes Config yml file. This is basically a definition file that describes a Multi-Container web app. Because we will be using Azure Container Registry (ACR), notice that the Docker Compose file has the ACR image repos in the file. The image with "ports: - 80:80" is the main container that exposed to Internet.
+
+Here is a sample Docker Compose file:
+
+If this Docker Compose file looks familiar, it is actually the same as the Docker Compose file in the Quickstart that you can use when creating a Multi-Container app (with DockerHub), with the exception of the ACR modifications.
+
+
+
Adding the App Settings
+After you uploaded your Docker Compose file and clicked create, you will have to make sure App Service can access Azure Container Registry by adding the following App settings in the App Service portal:
+
+Note: please make sure to enable admin access in the Azure Container Registry Server settings.
+
Limitations
+All Docker images in the same Docker Compose or Kubernetes Config yml file need to come from the same Azure Container Registryserver. This means that you may have to pull down popular images (such as nginx and Redis) from DockerHub, and tag it for ACR then push to your ACR registry server.
+
+Further limitations on Docker Compose/Kube Config configuration options are documented here.
+
Checking Your Logs
+After the web app is restarted, you should see logs similar to the ones below in Container settings or in Kudu. (Kudu is where you can view all your Docker logs and is your source control management site. Kudu can be accessed via [your web app name].SCM.azurewebsites.net or under "Advanced Tools" in the left-hand menu).
+
2018-06-19 19:26:33.419 ERROR – multi-container unit was not started successfully
+2018-06-19 19:26:33.422 INFO – Container logs from yili-multicontainer-acr-01_web_0 =
+2018-06-19 19:29:42.691 INFO – Starting multi-container app, configuration =
+version: '3'
+
+services:
+# this image repo’s source come from “Get started with Docker Compose” on docker.com
+web:
+image: [azure-container-registry-name].azurecr.io/flaskapp
+ports:
+– 80:80
+
+redis:
+image: [azure-container-registry-name].azurecr.io/redis:alpine
+2018-06-19 19:30:14.621 INFO – Starting container for site
+2018-06-19 19:30:14.622 INFO – docker run -d -p 55955:80 –name yili-multicontainer-acr-01_web_0 -e WEBSITE_SITE_NAME=yili-multicontainer-acr-01 -e WEBSITE_AUTH_ENABLED=False -e WEBSITE_ROLE_INSTANCE_ID=0 -e WEBSITE_INSTANCE_ID=6cc2f742b7330fbd63a5e79967ed9ee7904bb9d93c7ca7843312788a4c2bc622 yiliacr05.azurecr.io/flaskapp
+2018-06-19 19:30:14.622 INFO – Logging is not enabled for this container.
+Please usehttps://aka.ms/linux-diagnosticsto enable logging to see container logs here.
+2018-06-19 19:30:22.542 INFO – Starting container for site
+2018-06-19 19:30:22.543 INFO – docker run -d -p 0:6379 –name yili-multicontainer-acr-01_redis_0 -e WEBSITE_SITE_NAME=yili-multicontainer-acr-01 -e WEBSITE_AUTH_ENABLED=False -e WEBSITE_ROLE_INSTANCE_ID=0 -e WEBSITE_INSTANCE_ID=6cc2f742b7330fbd63a5e79967ed9ee7904bb9d93c7ca7843312788a4c2bc622 yiliacr05.azurecr.io/redis:alpine
+2018-06-19 19:30:22.544 INFO – Logging is not enabled for this container.
+Please usehttps://aka.ms/linux-diagnosticsto enable logging to see container logs here.
+2018-06-19 19:30:30.750 INFO – Started multi-container app
+2018-06-19 19:30:30.778 INFO – Container yili-multicontainer-acr-01_web_0 for site yili-multicontainer-acr-01 initialized successfully.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+In August 2018, Azure App Service will update the PHP stacks to the latest available versions. For information on the changes in the new versions, please see the change logs on the PHP website.
+
+
+
+Please note that the paths for the xdebug.dll will be changing to the paths in the chart above. This means that the old Xdebug paths will be removed. These old paths include:
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Interested in deploying your Linux or containerized web app in an Azure Virtual Network? Today, we are excited to announce the general availability of Linux on App Service Environment, which combines the features from App Service on Linux and App Service Environment. As we announced in our public preview, our Linux customers will be able to take advantage of deploying Linux and containerized apps in an App Service Environment, which is ideal for deploying applications into a VNet for secure network access or apps running at a high scale.
+
What can I do with Linux on ASE?
+With Linux on ASE, you can deploy your Linux web applications into an Azure virtual network (VNet), by bringing your own custom container or just bring your code by using one of our built-in images.
+
+
If you want bring your own custom Docker container, you can bring your image from:
+
+
DockerHub
+
Azure Container Registry
+
Your own private registry
+
+
+
If you want to use one of our built-in images, we support many popular stacks, such as:
+
+
Node
+
PHP
+
Java
+
.NET Core
+
And more to come
+
+
+
+Additionally, both Windows, Linux, and containerized web applications can be deployed into the same ASE, sharing the same VNet. Remember that even though Windows and Linux web apps can be in the same App Service Environment, Windows and Linux web apps have to be in separate App Service Plans. With Linux on ASE, you will be using the Isolated SKU with Dv2 VMs and additional scaling capabilities (up to 100 total App Service plan instances, between Windows and Linux, in one ASE).
+
+Depending on whether you want an internet accessible endpoint, there are two different kinds of ASEs that you can create:
+
+
An external ASE with an internet accessible endpoint or,
+
An internal ASE with a private IP address in the VNet with an internal load balancer (ILB).
+
+The consideration here is what kind of IP do you want to expose your apps hosted in your ASE. Steps to get started are provided here. More context about how to configure networking for your ASE can be found here.
+
+
Pricing Changes from Preview
+Linux and containerized apps deployed in an App Service Environment will return to regular App Service on Linux and App Service Environment pricing, as the 50% discount on the Linux App Service Plan from public preview is removed for GA.
+
New Regions Added
+Since public preview, we have now expanded Linux on ASE to all App Service on Linux’s 20+ regions, which include:
+
+
+
Australia East
+
Australia Southeast
+
Brazil South
+
Canada Central
+
Canada East
+
Central India
+
Central US
+
East Asia
+
East US
+
+
+
+
+
East US 2
+
Japan East
+
Japan West
+
Korea Central
+
Korea South
+
North Central US
+
North Europe
+
South Central US
+
South India
+
+
+
+
+
Southeast Asia
+
UK South
+
UK West
+
West Central US
+
West Europe
+
West India
+
West US
+
West US 2
+
+
+
+
+
How to Get Started
+You can create a Linux web app into a new ASE by simply creating a new web app and selecting Linux as the OS (built-in image), selecting Docker (custom container), or creating a new Web App for Containers (custom container). When creating a new App Service Plan, remember to select one of the Isolated SKUs.
+
+
+If you need more detailed instructions, get started with creating your first Linux/containerized web app into an ASE by following these instructions.
+
+We’d love to hear what you think! Please leave your feedback on Linux on ASE here.
+
Frequently Asked Questions (FAQ)
+Q: Especially for those new to App Service Environment, how long will everything take to deploy?
+
+A: Because an ASE gives you a fully isolated and dedicated environment for securely running App Service apps at high scale, there are many different parts that we provision for you upon creating a web app in an ASE. Instead of sharing front ends, you will have dedicated front ends that are responsible for HTTP/HTTPS termination and automatic load balancing of app requests within the ASE.
+
+Therefore, when deploying a web app into an ASE or performing a scaling operation, the operation can take a couple of hours or more. This is not a promised SLA. We recommend that you schedule your scaling operations to account for the time it takes for any extended scaling processes. Improving scaling and deployment time for apps in an ASE is definitely a top priority item for our team to improve on.
+
+Q: What should I keep in mind if I want to lock down my ASE with NSG and routing rules?
+
+A: Using an App Service Environment is a great use case for controlling network access and locking down access to your applications. This can be done using:
+
Routes, where you can control the outbound traffic to not go directly to the internet (such as an ExpressRoute gateway or a virtual appliance)
+
+This is done at the ASE level, and not the app level, which is important to keep in mind (because in the App Service portal, there is an option on the left-hand menu named “Networking” that is grayed out for Linux and container apps. This is unrelated to controlling your network access via NSGs and routes).
+
+Additionally, for ASE management purposes, there are some domains and IPs of network resources that the ASE requires to function. For Windows-only ASEs, these are documented here and also are surfaced in the ASE Portal. In additional to these inbound and outbound access dependencies, Linux/containers has other dependencies, such as:
+
+
docker.io
+
ubuntu.com
+
docker.com
+
treasuredata.com
+
mono-project.com
+
+Q: Can I deploy a Multi-Container app with Docker Compose/Kubernetes Config in an ASE?
+
+A: You can deploy a Multi-Container app in an ASE, but the Multi-Container offering on App Service on Linux is still in preview. Learn more about how to deploy a Multi-Container app here.
+Q: Can I deploy a Function app in a container in an ASE?
+
+A: You can deploy a Function app in a container in an ASE, but the Function on Linux feature is still in preview. Learn more about how to deploy a Functions on Linux app here.
+
+
+
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+In September 2018, Azure App Service will update the PHP stacks to the latest available versions. For information on the changes in the new versions, please see the change logs on the PHP website.
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
The project I'm working on requires me to retrieve information from multiple sources like the NuGet and GitHub API. Let's bring into focus how I'm downloading data from the GitHub API. If you follow me on Twitter, you've probably already heard me talk about it.
+
Ever ended up on a sample that should be covering the problem you're having, but it just doesn't work? Then, you check the last commit date only to realize that it's been 2 years since the last commit. The way the cloud is evolving, that sample is almost no good to you.
+
Well, some of the repositories on the Azure-Samples organization have those exact issues, and it's one of the many problems that I'm trying to solve.
+
There are tons of samples on the Azure-Samples organization on GitHub, and I want to be able to check them out to see which ones are "too old." What does a user consider a valid sample? For me, a valid sample is an up to date sample.
+
We need a way to retrieve those over 900 samples and validate their last commit date.
+
However, we first need to be able to retrieve all that information.
+
File -> New Project -> Console Application
+
Our first instinct as programmers is to try to do it once through a console application. It's the minimum amount of complexity. If you can't make it work in a console, there's no hope of making it work anywhere else.
+
So, I went ahead and started by consulting the GitHub API documentation, created a GitHub token and started hunting for the information I need.
+
I ended up using the Octokit library to do all of my API access. The code to retrieve the last commit date is below.
+
var github = new GitHubClient(new ProductHeaderValue("AzureSampleChecker")) { Credentials = new Credentials("") };
+
+var lastCommit = await github.Repository.Commit.GetAll(repositoryId, new ApiOptions { PageSize = 1, PageCount = 1 });
+var commit = lastCommit.FirstOrDefault()?.Commit;
+var lastCommitDate = commit.Committer.Date;
+
+//snipped: saving to the database
+
First problem: Running locally
+
Everything was running fine, but the problem for me at that point was it was just a single console application running locally. I could have just taken the application as-is to containers, but I saw another way to solve this. I saw another way to scale it up. Azure Functions would help me scale it up.
+
By migrating the existing code into an Azure Function, the problem now was that it was still just a console application running inside an Azure Functions. This will just not cut it. We're just running the same workflow in sequence. We need to execute this workflow in parallel and be able to scale out.
+
Once you know all the repositories that you want to query, it becomes a distributed problem. How many repositories can I hit at once without having any state to correlate between them? The answer is all of them.
+
I needed to refactor to make this process more sturdy. I needed it to be durable.
+
Introducing Durable Functions
+
If you are new to serverless, there's an excellent book by Jeremy Likness that can bring you up to speed. Azure Functions is Microsoft's implementation of the serverless architecture. If you need a refresher, you can review the Azure Functions Overview on what is possible.
+
What is a Durable Function? With durable, it's all about orchestration. Just like in music, the orchestrator ensures that everyone is following the melody, but it's the responsibility of each musician to play their instrument.
+
Regarding Durable Functions, an orchestrator is in charge of starting and tracking a series of functions, but it's the responsibility of each activities to execute their part. Think of the orchestrator as a workflow written in code and activities as the steps of the workflow. An orchestrator and an activity are still Azure Functions.
+
Let's introduce two patterns that I'm using in my code.
+
Function Chaining
+
A pattern I want to cover quickly is function chaining. It's the most straightforward and most commonly used pattern.
+
+
+[caption id="attachment_9105" align="aligncenter" width="825"] Function Chaining[/caption]
+
+Everytime that your orchestrator awaits a function before running another one, you're doing function chaining. Here's the above image visualized in a code example.
+
Fanning out means that your orchestrator function (F1) starts as many functions (F2) as necessary in parallel with some initial parameters like the repository I want. Once all those functions have finished executing, we need a way to return the requested data to our orchestrator (F3). Keep in mind that, all those functions may not be executing on the same server. It is not as simple as a multi-threaded application. It's a multi-threaded, multi-server, highly parallel execution workflow.
+
How would you do that in a local data center? A console application would retrieve the list of items on which you want to fan-out. Then, it would queue that list into a messaging system. Once queued up, you would have to have dequeue those messages asynchronously by other console applications that are on different servers. Each console applications would then be responsible for storing the result of their execution on shared storage. Once completed, you'd have to find a way to get the first console application to finish the workflow. Finishing the workflow would involve fanning in all the results back, and saving it to a database.
+
With Azure Functions, it's as easy as returning an object. All the necessary work of storing the results of individual functions and aggregating them together is done automatically for you.
+
This scenario is a hard problem. Durable Functions just saved me easily one week of work and more days of testing, debugging, and refining the process.
+
Now that the introduction is complete let's jump back to our scenario.
Its behaviors are incredibly different than other Functions. It is called multiple times at different moment to orchestrate the execution of those functions. It is of the utmost importance that you do not calculate time and access external resources (e.g., SQL, Storage, API) in that context. The orchestrator is tasked to execute and track the status of those functions we started by executing itself repeatedly when something changes. You want the orchestrator function to be deterministic, meaning the same code executed at a different time need to give the same result. So no DateTime, no Math.Random or Guid.NewGuid() should be in an orchestrator.
+
It's also important to note that every call that you make using CallActivityAsync won't be executed more than once for the same orchestrator instance. Results are cached and handled by the Durable Functions.
+
CallActivityAsync is part of the concept that we call checkpoint and replay. In simpler terms, this allows resuming the execution of the orchestrator while remembering the state of the execution of previous activities we ran in a reliable way across servers.
+
Web Scraping scenario
+
Here's the code for my sample orchestrator.
+
[FunctionName("DownloadSamples_Orchestrator")]
+public static async Task RunOrchestrator([OrchestrationTrigger] DurableOrchestrationContext context, TraceWriter log)
+{
+ var repositories = await context.CallActivityAsync<List>("DownloadSamples_GetAllPublicRepositories", null);
+
+ var tasks = new Task[repositories.Count];
+ for (int i = 0; i < repositories.Count; i++)
+ {
+ tasks[i] = context.CallActivityAsync("DownloadSamples_UpdateRepositoryData", repositories[i]);
+ }
+ await Task.WhenAll(tasks);
+
+ var samplesToAdd = tasks.Select(x => x.Result).ToList();
+ await context.CallActivityAsync("DownloadSamples_SaveAllToDatabase", samplesToAdd);
+}
+
So let's decompose this together. First, I call a function to retrieve the list of over 900 Public Repositories available on Azure-Samples and await for the results before going any further. Then, we create an array of Tasks and go through our samples and start a function without an await for each of them. We're fanning out the execution of those functions to be run and scaled by the cloud automatically. We're not using await here. Otherwise, they would run sequentially instead of in parallel.
+
Then task then need to be awaited till completion. Finally, we aggregate the Samples object that has been returned by those functions into a list. Finally, we send it to a function to save them in a database. We've successfully fanned-in the results of 100s of functions. There is no need for a third-party system. No other configurations. No complex messaging architecture. Just code.
+
Just like that, we've made a complex parallel problem easy.
+
Advanced Scenario: Orchestrating Orchestrators with Sub Orchestrators
+
Isn't it amazing? Now, I have an Orchestrator that instantiates over 900 DownloadSamples_UpdateRepositoryData functions to download data from the GitHub API. What would happen if I have multiple orchestrators of data ingestion that I want to make?
+
How do I orchestrate the orchestrators? We need another orchestrator of course! Here's a simplified version of my code.
What does it do? Create a single run that is going to be used to invoke every other data ingestion orchestrator.
+
All those orchestrators are all going to start at 7 am every day at the same time. They are all going to run as described before. Only this time, they also report back to another orchestrator.
+
Once you start implementing simple workflows, it becomes effortless to build complex scenarios out of simple ones. The same patterns we approached that were used to build a single orchestrator can be used to orchestrate multiple sub-orchestrators.
+
Why do I want this?
+
Imagine working on a team with many different processes that need to run in parallel. Maybe one team is working on the shipping process, the other on the payment process. With a single orchestrator to manage multiple sub orchestrators, it makes team collaboration easier.
+
In my case, what if someone else wants to add the parsing of another API? They can work on their orchestrator and plug it in my MainDownloadOrchestrator function, and that's it.
+
Scraping data from an API is just a single scenario. Whether you are building an order processing system, a conference organization tool or the next revolution in IoT data processing, we know that you need a way to organize complexity within your solution. We know that you want to reuse more significant part of your system than a single function.
+
Durable Functions is how you build complex systems with serverless.
+
What is missing
+
What you haven't seen implemented is how to handle rate limiting. GitHub API has a limit of 5000 (at the time of writing) API calls per hour which is more than enough for the use that I make of it.
+
However, if other teams were to query GitHub some more, I'd need to look into implementing it. I still don't have an elegant solution for this, but it's going to be something I'm looking to implement next.
+
Try it out
+
If you want to try it out, Azure Functions comes with a free quota even with a trial account. If you need an account, you can create one for free.
+
Contribute
+
Azure Functions is also open source. Look at these repositories if you want to contribute or just want to know what's going on with the project.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Create a new or open an existing ASP.Net Web Forms application in Visual Studio 2017
+
Select the Web Forms project, go to the Project Menu and select "Docker Support". If you do not see this option check that you have the .Net Core workload installed with the Visual Studio Installer
+
+[caption id="attachment_9135" align="aligncenter" width="300"] Add Docker Support to existing project[/caption]
+
Visual Studio will have created a new docker-compose project and added a Dockerfile to the Web Forms Project. Open the Dockerfile:
+
FROM microsoft/aspnet:4.7.1-windowsservercore-1709
+ARG source
+WORKDIR /inetpub/wwwroot
+COPY ${source:-obj/Docker/publish} .
+
+
Change the FROM argument in the Dockerfile to point to a Windows Server 2016 Core base image from the Long Term Servicing Channel. Should you wish to publish a .Net Core application in a Windows Container, use a Windows Server 2016 Nano base image from the Long Term Servicing Channel. We cache certain images as listed in the announcement blog post to enable faster container deployment, for example here specify microsoft/aspnet:4.7.2-windowsservercore-ltsc2016:
+
FROM microsoft/aspnet:4.7.2-windowsservercore-ltsc2016
+ARG source
+WORKDIR /inetpub/wwwroot
+COPY ${source:-obj/Docker/publish} .
+
+
Build the project.
+
Select the Web Application and right click Publish.
+
As we are publishing the application in a container we need to publish to a Container Registry. Visual Studio 2017 enables the publishing of containers to an Azure Container Registry, a private registry or Docker Hub. In this example we're going to publish to Docker Hub, so select Container Registry, then choose Docker Hub and click Publish:
+
+
When prompted enter your Docker Hub account username and password and click Save
+
Once published take a note of the container image name and tag from the Output window.
+
Go to the Azure portal and sign in with your Azure subscription credentials
+
Choose to Create a resourcein the upper left-hand corner of the Azure portal.
+
In the search box above the list of Azure Marketplace resources, search for and selectWeb App for Containers.
+
Provide an app name, such as WindowsContainerHelloWorld, accept the defaults to create a new resource group, and clickWindows (Preview)in theOSbox.
+
Create an App Service plan by clicking App Service plan/Location > Create new. Give the new plan a name, accept the defaults, and click OK
+
Click Configure container, type the username/image:tag that you noted in the output window earlier, for example, mydockerhub/myimage:latest in Image and optional tag, and click OK.
+
Click Create and wait for Azure to create the required resources, you will be notified when the operation completes. Click Go to resource in the notification box.
+
In the application overview click Browse, you will see a page showing the container is starting up
+
Refresh the page after a few minutes and you will see your ASP.Net Web Forms application running!
+
+
We want to hear from you!
+Windows Container support for Azure App Service provides you with even more ways to build, migrate, deploy, and scale enterprise grade web and API applications running on the Windows platform. We are planning to add even more capabilities during the public preview and we are very interested in your feedback as we move towards general availability.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
The Azure App service team will host a special Ask Me Anything (AMA) session on Twitter, Wednesday, August 22, 2018 from 9 AM to 11 AM PST. You can tweet to @AzureSupport with #AppServiceAMA with your questions about the service.
+
What's an AMA session?
+We'll have folks from across the Azure App Service engineering team available to answer any questions you have. You can ask us anything about our products, services, roadmap, new features or even about our team!
+
Why are you doing an AMA?
+We love reaching out and learning from our customers and community. We want to know how you use Azure in general and App Service specifically and how your experience has been. Your questions provide insights into how we can make the service even better.
+
How do I ask questions on Twitter?
+Just use the hashtag #AppServiceAMA in your tweet to @AzureSupport and we will record the rest. The doors open to the community to start posting questions to the #AppServiceAMA 24 hours prior to the AMA (Tues Aug 21st at 9am PST). The questions will be recorded, and will be answered on the day of the AMA. This is to allow customers in different time zones or who can’t attend the event to ask their questions and get answers directly from the Azure App Service team. You can catch us for a live conversation on Aug 22, 2018 from 9am to 11am PST. If there are follow-ups, we will continue the dialogue post AMA. Go ahead and tweet to us!
+
Who will be there?
+You, of course! We'll also have Program Managers and Developers from the App Service engineering team participating, pulling in specific people depending on the topics.
+Have any questions about the following topics? Bring them to the AMA.
+
+
App Service Environment
+
App Service on Linux / Web App for Containers
+
Multi-Containers in App Service
+
App Service Diagnostics
+
Best practice for high traffic resiliency
+
Scaling App Service Plans / Autoscale
+
Networking and Isolation
+
Deploying App Service
+
Deployment slots, when to use and how
+
Much, much more!
+
+
Why should I ask questions here instead of StackOverflow or MSDN? Can I really ask anything?
+An AMA is a great place to ask us anything. StackOverflow and MSDN have restrictions on which questions can be asked. With an AMA, you’ll get answers directly from the team and have a conversation with the people who build these products and services.
+
+Here are some question ideas:
+
+
What is App Service?
+
What are the benefits of PaaS in comparison with IaaS?
+
How do I manage access control to my resources?
+
How many apps can I host on each App Service Plan?
+
How do I monitor the health of the traffic to my apps?
+
How do I solve issues that may happen with my app and its resources?
+
How can I isolate the traffic to my app?
+
How do I autoscale my app and how does affect billing?
+
How is life in Seattle? Does it really rain all the time?
+
+Go ahead, ask us anything about our public products or the team. Please note, we cannot comment on unreleased features and future plans and issues which require deep level debugging.
+
+We're looking forward to having a conversation with you!
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
This afternoon we released the third update to Azure App Service on Azure Stack. This release updates the resource provider and brings the following key capabilities:
+
+
Support for use of SQL Server Always On for Azure App Service Resource Provider databases.
+
Updates toApp Service Tenant, Admin, Functions portals and Kudu tools.
+
Updates to ASP.Net Core, NodeJS, Zulu OpenJDK, Tomcat, PHP, Wincache and Git
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Summary
+Docker has scheduled a maintenance window for Docker Hub on Saturday August 25th, which has potential impacts to App Service customers.
+For Web App for Containers (using custom Docker image), customers will not be able to create new web apps using a Docker container image from Docker Hub during the maintenance window. Customers can still create new apps using Docker images hosted on Azure Container Registry or a private Docker registry. For App Service on Linux (using non-preview built-in stacks), customers will not be impacted as we have Docker container images cached on our Linux workers.
+Recommendation
+To avoid unnecessary service interruptions, we recommend Web App for Containers customers not make any changes or restart your apps, or use an alternative Docker registry during the Docker Hub maintenance window.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
App Service SSL settings experience is one of the most used features in App Service. Based on customer feedback we are making the following changes to the UX to address and improve the overall experience of managing certificates in Azure App Service.
+
Tabs
+The new SSL settings experience divides the features into 3 tabs. Namely SSL Bindings, Private certificates (.pfx), and Public certificates (.cer). The Bindings tab allows the user to configure the protocol settings and add/edit/delete SSL bindings, the private certificates tab allows the user to upload and manage private certificates (.pfx) used in SSL bindings and the public certificates tab allows the user to upload and manage public certificates (.cer). We also call out what type of certificate type the customer needs to use for each feature.
+
+
+
+
+
+
+
Editing SSL Bindings
+SSL Settings didn't have a way to update an existing SSL binding, the feature to edit was present but unfortunately hidden under the Add Binding flow. We enabled the ability to edit a few sprints ago, we polished the feature further and now the customer is free to edit any binding by clicking on the row. When you change the thumbprint for the IP Based SSL binding the IP will not be lost, but if you change out from IP Based SSL to SNI and back you will lose the IP. The ability to change the certificate without removing and adding back the binding was an issue in the past we are addressing with this release. For more details on adding SSL Bindings click here.
+
+
+
+
Private Certificate Details
+Private certificates used in App Service required a facelift to show the information we already gather when the certificate is uploaded, imported from App Service Certificate or imported from KeyVault. The driving reason was when we saw hundreds of private certificates configured on their app and had a tough time browsing through the certificates, the revamp allows the customer to now to get details of the certificates uploaded and imported. We added a new status column to the grid showing three possible states. Healthy, Warning and Expired. Warning being a certificate about to expire in the next 60 days. We also explicitly mention that you will need to upload a .pfx file to add a private certificate.
+
+[caption id="attachment_9355" align="aligncenter" width="1429"] Showing a test certificate that is valid.[/caption]
+
+We also show the KeyVault details and the sync status of the certificates pulled from KeyVault like certificates imported from App Service Certificate.
+
+
+
+
+
Uploading certificates
+The Upload Certificate experience overall is more consistent in showing that private certificates only accept .pfx file and you need a valid pfx to add a private certificate to your App Service. Addressing another feedback, we stopped showing both upload path. Now upload certificates from the private certificates opens the UX where you can only upload the private certificates to avoid the confusion about uploading .cer or .pfx file. When the Upload certificate flow is opened from the public certificate tab we show only the public certificate option.
+
+
+
+We updated the upload certificate UX (and the underlying way it is implemented) to show errors while trying to upload a certificate without leaving the upload blade.
+
+
+
+
+
+
+
Public Certificates
+Public certificates can only be used by your app and they cannot be used for making SSL bindings. We are working out a way to move it to a place where it will make more sense. For now, SSL Setting is the place where Public certificates will reside. Private certificates require app settings to enable that feature (it's covered in this very old but reliable blog here) and now public certificates add another dimension to that feature by allowing you to upload (.cer) files and get the certificates in runtime.
+
+
+
+
+
+Thanks for reading! I am writing this blog to showcase the changes we made to improve the overall certificate management experience for customers using App Service day in and day out. We are always open to feedback and looking forward to your comments.
+
+Feel free to reach out to us for any feature request or issues.
+
+App Service MSDN forum
+Feature Requests
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Note: Currently, this new experience is only for Windows web apps for now.
+
+Hopefully, most of the time your apps are running healthily and happily. However, sometimes your app may run into issues, resulting in downtimes, slowness, or other unexpected behaviors. We’ve built App Service Diagnostics to help you diagnose and solve issues with your web app with recommended troubleshooting and next steps. You can learn more about App Service Diagnostics here.
+
+However, these unexpected behaviors may be temporarily resolved with some simple mitigation steps, such as restarting the process or starting another executable, or require additional data collection, so that you can better troubleshoot the ongoing issue at a later time.
+
+Today, we’re excited to announce our new Auto Healing experience in App Service Diagnostics. With our new Auto Healing tile shortcut, you can set up custom mitigation actions to run when certain conditions (that you define as unexpected or a sign of unhealthy behavior) are met.
+
+
+Click Diagnostic Tools from the App Service Diagnostics homepage.
+
+Then, click Auto-Heal.
+
How to Get Started
+
+Step 1: Define conditions
+
+Select the tile that best matches the condition that you want to set for your mitigation rule.
+
+The conditions that are supported with the new Mitigate/Auto Heal experience in App Service Diagnostics are:
+
+
Request Duration: examines slow requests
+
Memory Limit: examines process memory in private bytes
+
Request Count: examines number of requests
+
Status Codes: examines number of requests and their HTTP status code
+
+After reading the description, select the blue button to configure the rule parameters. Parameters that have a red asterisk next to it are required fields.
+
+
+Step 2: Configure actions
+
+Select the tile that best matches the auto heal mitigation action that you want to perform under your mitigation rule conditions. When the graphic is blue, it means that action has been selected. (For custom actions, be sure to fill out the parameters required).
+
+The custom mitigation actions that are supported are:
+
+
Recycle Process
+
Log an Event
+
Custom Action
+
+
Run Diagnostics: runs
+
Run Any Executable: runs specified executable
+
+
+
+
+Step 3: Override when action executes (optional)
+
+Sometimes when an app has a long startup time, depending on the mitigation rule conditions that are set, it may kick off the mitigation action during app startup, which is not the intended use case. By modifying the startup time, you can specify how much time the mitigation rule should wait after the process startup before the mitigation rule kicks off.
+
+
+Step 4: Review and save your settings
+
+Here, you can review the rules that you just created and save them. If you have previously defined rules, they will show up under Current Settings (no rules will show up under Current Settings until they are saved).
+
+Saving mitigation settings will restart the application domain for the web app and this can cause logged-in user information, sessions, and in-memory cache to be cleared. Hence, it is advised to make these changes during non-business hours.
+
+Two things to keep in mind:
+
+
These mitigation actions should only be considered a temporary workaround until you find the real cause for the issue causing the unexpected behavior. For the latter, you can start with App Service Diagnostics to figure out what actually went wrong.
+
The feature in this blog post is in addition to Proactive Auto Heal, which is automatically restarts your web app based on our percent memory and percent request rules. Learn more about Proactive Auto Heal here.
+
+How to Delete a Mitigation Rule
+
+For the mitigation rule that you want to delete, select the condition that the rule is set on. Then, click on the trash can next to the rule that you configured.
+
+
+
+Get ahead of your issues and automatically mitigate these unexpected behaviors by trying out Mitigate and Auto Heal in App Service Diagnostics.
+
+
+
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Have you tried bringing your code or bringing your container to App Service on Linux yet? App Service on Linux is a fully managed platform that allows you to quickly build, deploy, and globally scale your apps. You can bring your code to App Service on Linux and take advantage of the built-in images for popular supported language stacks, such as Node, Java, PHP, etc, or bring your Docker container to easily deploy to Web App for Containers. We have seen strong adoption since the General Availability of App Service on Linux and Web App for Containers in September 2017.
+
+
+Basic and Premium Price Drop
+
+To encourage further adoption, we’re happy to announce a 30% price drop for the Basic App Service Plan for Linux, and a 20% price drop for the Premium App Service Plan for Linux. The price change takes effect on October 1st, 2018. Learn about more details on the App Service Pricing page.
+
+Please note the price change applies to any existing Linux Basic and Premium App Service Plans as well as new Basic and Premium App Service Plans created on or after the effective date.
+
+
+
+Linux on ASE GA Price Offering
+
+As some of you may know, we announced that Linux on App Service Environment (ASE) is now generally available. Because Linux on App Service Environment combines the features from App Service on Linux and App Service Environment, Linux customers will be able to take advantage of deploying Linux and containerized apps in an App Service Environment. This is ideal for deploying applications into an Azure Virtual Network for secure network access or apps running at a high scale.
+
+
+
🔒Lock down your app in an Azure Virtual Network (VNet)
+
🎨Run Windows, Linux, and containerized apps in the same ASE
+
📈Use the Isolated SKU with Dv2 VMs and scale up to 100 VMs
+Linux on ASE saw healthy adoption during preview, and we’d like to encourage further adoption now that we’re in General Availability. Taking that into consideration, we’re extending the preview price (for Linux on ASE, which is the Linux Isolated App Service Plan SKU) for a limited time through GA!
+
+Please note that when this limited time GA price offering ends, the final Linux on ASE price will be approximately twice the price of our Premium SKU. (Once the price offering ends, the prices will be closer to Windows on ASE.)
+
+While the date for the GA price change is TBD, a 30-day notice will be given and announced here on our App Service Team Blog as well.
+
+
+
+Now is the time to bring your code or bring your Docker container to App Service on Linux!
+
+
+
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Microsoft Ignite is taking place between September 24-28 and we can't wait for it to finally arrive! We are looking forward to all the great interactions with our customers, learning about the various new scenarios being solved with Serverless and of course announcing all the exciting news we've been keeping under the wraps!
+
+Can't make it to Ignite? No worries, we've got you covered! Log in to the Microsoft Ignite site to tune in to the keynotes live. We'll also publish recordings of all the sessions presented a few days later.
+
+If you're at Ignite, please join us for these following sessions which will give you the very best of what Azure Functions has to offer at Ignite! Just log in to your session scheduler to save these sessions and attend them all.
+
+
+
+
Build real-time serverless apps with Azure Functions and SignalR Service
+In this session, learn how the Azure Functions integration with Azure SignalR Service works, so you can work with it using all languages supported by Functions and integrate different Azure services for real-time tasks to build an entirely serverless web application.
+
+Speaker: Anthony Chu. Code: THR2195. Time: Monday at 6:25pm.
+
+
+
Azure Functions for the enterprise
+Serverless solutions are a common developer’s choice these days, due to clear productivity benefits. However, when using such solutions in the enterprise, many other important aspects come to mind, such as security, monitoring, scalability and DevOps. In this session we explore how serverless development with the Azure platform helps you get to market faster while still fulfilling all your administration policies. We dive deeply into the features Azure Functions provides to delight both developers and IT, as well as best practices for using them in your enterprise-grade serverless solutions.
+
+Speakers: Jeff Hollan, Matthew Henderson. Code: BRK3348. Time: Tuesday at 9:00am.
+
+
+
Build intelligent serverless applications
+From data ingestion, processing, model training, model updates to prediction - machine learning is hard! Join us to learn how serverless makes it all easier so you can stop worrying about managing the underlying infrastructure and focus on getting the most value out of your data, whether you're running in the cloud or on an IoT device.
+
+Speakers: Asavari Tayal, Colby Tresness. Code: BRK3352. Time: Wednesday at 9:00am.
+
+
+
Build microservices applications with a serverless architecture
+When you learn how to build your cloud-native applications using a PaaS architecture, infrastructure management or scaling based on demand isn't a problem anymore. In this session, we discuss how to go all serverless on microservices-based applications with a reference architecture, including data storage, endpoints management, and compute services.
+
+Speaker: Gorka Madariaga Nuñez. Code: BRK2027. Time: Wednesday at 3:15pm.
+
+
+
Machine Learning using Python in Azure Functions
+Learn how to build smarter serverless workloads with Azure Functions powering machine learning and data analysis models using Python.
+
+Speaker: Asavari Tayal. Code: THR2201. Time: Wednesday at 5:05pm.
+
+
+
Azure Functions internals
+Join our product engineering team on a technically deep lap around Azure Functions. Learn how Azure Functions enables you to quickly and easily deploy application services that scale massively in a cost-effective way, without having to worry about infrastructure and server management. This session goes beyond the basics to show you behind the scenes details on the latest advancements made by the product team. Azure Functions users learn new concepts in a demo-driven session covering topics like deployment, service management, and monitoring.
+
+Speakers: Eduardo Laureano, Fabio Cavalcante. Code: BRK4020. Time: Thursday at 9:00am.
+
+
+
Serverless real use cases and best practices
+Let's take a look at real cases from our customers worldwide, to learn how they solved their problems through our serverless platform, as well as best practices (and some caveats) from the architectures used developing these solutions.
+Speakers: Eduardo Laureano,Thiago Almeida, Nick Lizotte. Code: BRK2202. Time: Thursday at 12:45pm.
+
+
+
Automate your cloud infrastructure with Azure Functions, Azure Automation, and more
+Companies are constantly increasing their cloud footprint, creating a wealth of resources that need to managed. IT professionals are looking for the most efficient ways to automate management operations on those resources. Learn in this session the multiple ways in which you can simplify your life by using Azure Functions, Azure Automation, Logic Apps and Event Grid. After this session, you will be armed with choices that fit your preferences and needs.
+
+Speakers: Colby Tresness, Eamon O'Reilly. Code: BRK2208. Time: Friday at 10:45am.
+
+
+
Even more!
+In addition to these fantastic sessions, we are also holding a live webcast on Thursday, September 27th at 2:15pm EST. Tune in to aka.ms/AzureFunctionsLive to hear a recap of all our announcements and get an opportunity to ask Jeff and Eduardo live questions!
+
+Lastly, if you want to score a special prize, check out the questions here, write them down and come to our booth with the correct answers for a surprise. Of course, you can always stop by our booth regardless, meet the team, get your most burning questions answered and score some swag!
+
+
+
+See you all soon at Microsoft Ignite in Orlando!
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
We're getting excited leading up to Microsoft Ignite happening between September 24-28! As usual, there are many amazing sessions, announcements, demos, interactions and content planned.
+
+Can't make it to Ignite? No worries, we've got you covered! Log in to the Microsoft Ignite site to tune in to the keynotes live. We'll also publish recordings of all the sessions presented a few days later.
+
+As an attendee, it's always challenging to figure out which sessions to attend. Whether you are an advanced user of PaaS and App Service, or just getting started, we know you'll find the following sessions useful in planning your Ignite learning. Just log in to your session scheduler to save these sessions and attend them all.
+
+
+
+
+
Your web apps from code to deployed in a minute!
+Web developers want to focus on code, not be held back by the pain of getting an app deployed to Azure App Service. In this session, learn how to use Azure CLI to deploy your code to App Service with a single command, regardless of your language.
+Speaker: Nick King. Code: THR1110. Time: Monday, 12:45pm.
+
+
+
Best practices for mission critical apps on Azure App Service
+Azure App Service provides 99.95% SLA even for apps running on only a single instance. However, there are steps you should take as a developer to insulate your customers from perceived cold start latencies incurred when deploying a new version of an app. This session walks through using a combination of multi-phase deployment slots (swap with preview), local cache for disk resiliency, application initialization for warmup, and proper app service plan configuration to minimize cold start performance hits.
+Speaker: Stefan Schackow. Code: THR3105. Time: Monday, 1:20pm.
+
+
+
Oops, I deleted my web app! What now?
+Sometimes, intentionally or accidentally, an Azure App Service web app get deleted. Up to now, the only way to restore that app was to open a support ticket. Introducing Azure App Service Web App Undelete, where you can restore your app without the need to have a support plan. In this session, learn how to use the different Azure management tools to restore your deleted app.
+
+Speakers: Nick King, Oded Dvoskin. Code: THR2204. Time: Monday, 5:45pm.
+
+
+
What is new in Azure App Service networking
+The Azure App Service has had multiple features to enable application isolation and virtual network access. Some of these capabilities required the use of an App Service Environment (ASE). New features have been developed to enable numerous use cases without the use of an ASE such as hosting line-of-business applications, accessing resources across ExpressRoute and also accessing resources that are secured with service endpoints. At the same time we are also making major improvements to the ASE and are enabling greater isolation than previously.
+
+Speaker: Christina Compy. Code: BRK2386. Time: Tuesday, 2:00pm.
+
+
+
Fundamentals of Windows containers and Windows container-based web apps on Azure App Service
+Join us to learn why containers are a paradigm shift to a modern DevOps workflow! Container isolation empowers developers and IT to collaborate effectively with clear boundaries of configuration and execution. In this session we show real-life examples, covering how to dockerize your web and API apps, how to run Windows-server based containers on Azure App Service, and how to perform container customizations for scenarios such as image generation, custom font installation, GAC assemblies, and calling native DLLs from your web apps. Learn how to get direct access into running containers to run PowerShell commands. If you want to achieve new levels of collaboration, you can’t miss this session!
+
+Speaker: Andrew Westgarth. Code: BRK2045. Time: Tuesday, 2:15pm.
+
+
+
Keep your PaaS and serverless apps healthy and happy
+Working on an web app on Azure App Service or Azure Functions? Join us to learn tips and tricks that will help you quickly and easily diagnose and resolve issues with your web app, Functions app, or App Service environment. In this session, learn how to effectively leverage App Service diagnostics for troubleshooting in both proactive and problem-first scenarios. We walk through real-world scenarios that guide you to a cure for common app issues.
+
+Speaker: Jennifer Lee. Code: BRK3344. Time: Tuesday, 4:30pm.
+
+
+
Bring your container or code to easily deploy to App Service on Linux
+Are you interested in our newest container and OSS offerings in Azure App Service on Linux? In this session, we walkthrough how easy it is to bring your containerized Linux app to Web App for Containers and take advantage of the PaaS environment for increased efficiency. We also show you how to modernize classic app architecture with multi-containers, new OSS announcements, and how to diagnose and keep your app running healthily. With simplicity at scale, learn about how you can operate at a global scale by utilizing the latest features to make your app production ready.
+
+Speakers: Jennifer Lee, Jenny Lawrance. Code: BRK2390. Time: Friday, 12:30pm.
+
+
+
+Last, but not least, be sure to drop by our booth for some good conversation, get your technical questions answered and stock up on cool swag!
+
+See you in Orlando!
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Bring your own Storage to App Service now in Public Preview
+We’re excited to announce the “Bring Your Own Storage” feature to App Service on Linux and Web App for Containers. Available in public preview, “Bring Your Own Storage” supports mounting Azure Blobs and Azure Files into your Azure App Service. You can configure up to five Azure storage accounts for a given App Service.
+
+“Bring your own storage” for example, enables the following scenarios:
+
+
Bring your own content and have it readily available for your web application hosted on App Service. This avoids the need to copy the content which could take a lot of time depending on the number and size of the files.
+
Use the azure blob storage or azure files to write content or Log files which can be shared across different services you might have. For example, you can use any log management service like splunk with your app service writing logs to the azure files or blob storage and the log management service can consume the logs from the storage.
+
+
Configure azure storage account on App Service
+With this public preview annoucement, Azure CLI will have support for “Bring your own storage”. The UX experience is coming soon.
+
+Login to the CLI and ensure you have selected the right subscription:
+
+$ az login
+$ az account list
+$ az account set –subscription “YourSubscriptionName”
+
+To get help on the command to manage storage accounts on your app service, use the -h option:
+
+az webapp config storage-account -h
+
+Group
+az webapp config storage-account : Manage a web app's Azure storage account configurations.
+
+Commands:
+add : Add an Azure storage account configuration to a web app.
+delete : Delete a web app's Azure storage account configuration.
+list : Get a web app's Azure storage account configurations.
+update : Update an existing Azure storage account configuration on a web app.
+
Add a storage account to your app service
+To add a new storage account, you will need an Azure Storage (blob or azure files). If you haven’t created one yet, please follow the steps mentioned here to create one.
+
+Also, to learn more about how to create App Service, please follow the steps here.
+
+To link a storage account with your App Service (assumes you have already created the app service and the storage account), use the following command:
+
+$ az webapp config storage-account add -g RESOURCE_GROUP -n APP_NAME \
+--custom-id CustomId [Unique identifier for this storage mapping] \
+--storage-type [Azure storage type: AzureFiles or AzureBlob] \
+--account-name [Azure storage account name] \
+--share-name [Azure storage share/file name] \
+--access-key [storage access key] \
+--mount-path [/path/to/mount within the container]
+
+Sample:
+
+$ az webapp config storage-account add -g AppSvcBYOSDemoSite -n AppSvcBYOSDemoSite --custom-id MediaVolume --storage-type AzureBlob --account-name appsvcbyosdemo --share-name mediablob --access-key <youraccesskey> --mount-path /var/media
+
+Output:
+
+{
+"MediaVolume": {
+"accessKey": "youraccesskey",
+"accountName": "appsvcbyosdemo",
+"mountPath": "/var/media",
+"shareName": "mediablob",
+"state": "Ok",
+"type": "AzureBlob"
+}
+}
+
+At this point, your web application will have the storage mounted at /var/media and your web application has full access to this storage.
+If you want to use the mounted storage account in a Multi-container web app, you need to specify the custom-id of your storage account in the volumes block of your container definition in the Docker-Compose or Kubernetes yaml file, for example:
+
+version: '3'
+services:
+web:
+image: "mydocker/image:latest"
+ports:
+- "80:80"
+volumes:
+- <custom-id>:/var/media
+redis:
+image: "redis:alpine"
+
List storage accounts associated with the App Service
+To list the storage accounts associated with your app service, use the list command:
+
+$ az webapp config storage-account list -g RESOURCE_GROUP -n NAME
+
+Sample:
+
+$ az webapp config storage-account list -g AppSvcBYOSDemoSite -n AppSvcBYOSDemoSite
+
+Output:
+
+[
+{
+"name": "MediaVolume",
+"slotSetting": false,
+"value": {
+"accessKey": "youraccesskey",
+"accountName": "appsvcbyosdemo",
+"mountPath": "/var/media",
+"shareName": "mediablob",
+"state": "Ok",
+"type": "AzureBlob"
+}
+}
+]
+
Update storage account associated with the App Service
+To update the storage accounts associated with your app service, use the update command:
+
+$ az webapp config storage-account update -g RESOURCE_GROUP -n APP_NAME \
+--custom-id CustomId [Unique identifier for this storage mapping] \
+--storage-type [Azure storage type: AzureFiles or AzureBlob] \
+--account-name [Azure storage account name] \
+--share-name [Azure storage share/file name] \
+--access-key [storage access key] \
+--mount-path [/path/to/mount within the container]
+
+Sample:
+
+$ az webapp config storage-account update -g AppSvcBYOSDemoSite -n AppSvcBYOSDemoSite --custom-id MediaVolume --storage-type AzureBlob --account-name appsvcbyosdemo --share-name mediablob --access-key <youraccesskey> --mount-path /var/media
+
+Output:
+
+{
+"MediaVolume": {
+"accessKey": "youraccesskey",
+"accountName": "appsvcbyosdemo",
+"mountPath": "/var/media",
+"shareName": "mediablob",
+"state": "Ok",
+"type": "AzureBlob"
+}
+}
+
Remove storage account associated with the App Service
+To remove the storage account from the Azure App Service, use the delete command.
+
+$ az webapp config storage-account delete -g RESOURCE_GROUP -n APP_NAME --custom-id CustomId
+
+Sample:
+
+az webapp config storage-account delete -g AppSvcBYOSDemoSite -n AppSvcBYOSDemoSite --custom-id MediaVolume
+
+Output:
+
+{}
+
Sample Web Application that uses external Azure Storage for static files
+Here is a sample dotnetcore web application that shows how you easy it is to use an Azure Storage account to store your content and reference it in your web application.
+
+Useful Links
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+Today we are announcing the public preview release of Azure App Service Undelete. Undelete is available for all App Service Plans, from Basic and up. Only sites deleted in the past 30 days can be restored.
+
+A user can undelete a deleted web app, and restore the following:
+
+
The content of the deleted app.
+
The configuration of the app (the commands allows to skip the restoration of the app configuration).
+
The undelete commands will also to restore the *.azurewebsites.net host name if still available.
+
+Currently the undelete commands support the restoration of apps deleted from the multi-tenant using Windows and Linux, other services like App Service Environments and Azure Functions will be supported in later releases.
+
+To get started, install the PowerShell module or install Azure CLI.
+
+
+
+You can list deleted apps using the following command, you can use the optional parameters to filter the apps with a specific name, belong to a specific resource group or App Service plan. Record the id of the deleted site as that will be used to restore the app.
+
az webapp deleted list --name <name of the deleted app>
+In CLI you need to have an existing app or an app slot to restore your app to
+
az webapp deleted restore --deleted-id <id of the deleted app> --name <name of the app to restore to> --resource-group <resource group of the app to restore to>
+
+You can list deleted apps using the following command, you can use the optional parameters to filter the apps with a specific name, belonging to a specific resource group.
+
Get-AzureRmDeletedWebApp -name <name of the deleted app>
+
+In PowerShell, you can specify the name and resource group of the deleted app, and provide the information of the target app. You can specify an App Service plan name to restore to, and the command will try and restore the app with the same *.azurewebsites.net hostname as the deleted app.
+
Restore-AzureRmDeletedWebApp -ResourceGroupName <deleted app rg> -Name <deleted app name> -TargetAppServicePlanName <App Service plan name to create an app to restore to>
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Today, we’re excited to announce our new user experience for App Service Diagnostics. App Service Diagnostics is our intelligent and interactive experience to help you diagnose and troubleshoot issues with your app. You can use Genie to guide you through the different ways to troubleshoot a variety of potential issues, since sometimes bad things happen to good apps. You can learn more about App Service Diagnostics in these other blog posts.
+
+Since we’ve first started with helping you with availability and performance issues, the coverage of issues that App Service Diagnostics has grown. To accommodate for a variety of problem categories and to more closely integrate with other troubleshooting content, we have revamped the user experience for App Service Diagnostics.
+
+
+
How to Get Started
+As always, without any additional configuration, you can access App Service Diagonstics by:
+
+
Go to the Azure Portal.
+
Select your app (Windows, Linux, or Functions) or App Service Environment.
+
Click on “Diagnose and solve problems."
+
+You can still access the old experience by selecting the blue bar at the top.
+
Problem Categories
+In the new App Service Diagnostics homepage, the guided diagnostics experience is now separated into different problem categories to help you be more focused on the specific issue that you’re facing. Each problem category will have a description and keywords to help describe what types of problems would fall underneath that category.
+
+
+
+If you’re new to diagnosing issues with your app or new to App Service, it’s a good idea to click around these tiles to investigate your issue.
+
+The health checkup from our old experience will be under Availability and Performance.
+
+
+
Genie and Tiles for Each Problem Category
+Once you have selected a problem category, you are introduced to Genie, who will guide you through the troubleshooting experience for that category. In this new iteration, Genie is specific to the problem category that you’ve selected.
+
+
+The blue buttons that show up are tiles; you should select those that best match your issue. These tiles run analyses on our end and output insights that show up within Genie. You should click on these insights to get more data, the full report, and actual suggestions on what to do next.
+
+
+
+Insights are arranged in terms of severity:
+
+
Red: critical
+
Orange: warning
+
Green: success
+
Blue: informational
+
+Once you click on the insight, there may be more insights and next steps to follow. Make sure you select each insight to expand to show more details. Also, there is a new time picker on the top right to help to navigate between different time periods of interest.
+
+
+
+At any time, select Show Tile Menu to show all the tiles for that problem category.
+
Search Documentation
+Also new to Genie’s flow is our Search Documentation. If the tiles weren’t of help, you can enter in your issue in the inline search bar that appears after you select Search Documentation. This will do a web search of the issue you’ve written about to find relevant content that might help you with your “how do I…?” questions. It brings up the most relevant results if you include “App Service” or “web app” in your search terms.
+
+
+
Search App Service Diagnostics
+Now, in the new App Service Diagnostics home page, we have a search bar in the top left-hand corner. This search bar allows you to search within App Service Diagnostics to find the relevant tiles or tools that fit the search term.
+
+Therefore, the search bar is great when you are more experienced with App Service Diagnostics and know specifically what problem category, tile, or diagnostic tool you’re looking for. You can just type in the search term and quickly get to the tile that you’re interested in, which is great when showing your troubleshooting methods to other members on your team.
+
+
+
Diagnostic Tools
+The Diagnostic Tools problem category is where our advanced tools are now. These include all the Support Tools that were on the right-hand side of the page as well our new Auto Healing feature. This is a great option for our advanced users who want to collect a profiler trace, memory dump, network trace, and more.
+
+
+
Best Practices
+The Best Practices problem category is where our suggestions for running production apps in the cloud are. These suggestions are app-specific recommendations for optimizing your app configurations for production.
+
+
+
+As before, App Service Diagnostics is a great first step in guiding you through the troubleshooting experience on App Service, App Service Environment, or Azure Functions. Please try out the new experience and let us know about your feedback!
+
+
+
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
The Azure Functions team will host a special Ask Me Anything (AMA) session on Twitter, Thursday, October 11, 2018 from 9 AM to 11 AM PST. You can tweet to @AzureFunctions or @AzureSupport with #FunctionsAMA with your questions about the service.
+
What's an AMA session?
+We'll have folks from across the Azure Functions engineering team available to answer any questions you have. You can ask us anything about our products, services, roadmap, new features or even about our team!
+
Why are you doing an AMA?
+We love reaching out and learning from our customers and community. We want to know how you use Azure in general and Functions specifically and how your experience has been. Your questions provide insights into how we can make the service even better.
+
How do I ask questions on Twitter?
+
Just use the hashtag #FunctionsAMA in your tweet to @AzureFunctions or @AzureSupport and we will record the rest. The doors open to the community to start posting questions to the #FunctionsAMA 24 hours prior to the AMA (Wednesday Oct 10th at 9am PST). The questions will be recorded, and will be answered on the day of the AMA. This is to allow customers in different time zones or who can’t attend the event to ask their questions and get answers directly from the Azure Functions team. You can catch us for a live conversation on Oct 11th, 2018 from 9am to 11am PST. If there are follow-ups, we will continue the dialogue post AMA. Go ahead and tweet to us!
+
Who will be there?
+You, of course! We'll also have Program Managers and Developers from the Functions engineering team participating, pulling in specific people depending on the topics.
+Have any questions about the following topics? Bring them to the AMA.
+
+
Getting started with Serverless.
+
Deciding between hosting Functions in a consumption or dedicated plan.
Bindings and Triggers connecting to other services.
+
Scaling operations.
+
Monitoring and debugging Functions.
+
Where to develop Functions.
+
Best practice.
+
Much, much more!
+
+
Why should I ask questions here instead of StackOverflow or MSDN? Can I really ask anything?
+An AMA is a great place to ask us anything. StackOverflow and MSDN have restrictions on which questions can be asked. With an AMA, you’ll get answers directly from the team and have a conversation with the people who build these products and services.
+
+Here are some question ideas:
+
+
What is Serverless? What is Functions?
+
What are the benefits of Serverless in comparison with IaaS?
+
How do I manage access control to my resources?
+
How many functions should I host in each Function app?
+
How do I monitor the health of my functions?
+
How do I diagnose issues that I suspect are happening with my functions' health?
+
What is the Azure Functions Premium plan?
+
When to choose between Durable Functions and Logic Apps? Between Functions and Logic Apps?
+
Does Serverless really mean the lack or Servers? What is this madness??
+
+Go ahead, ask us anything about our public products or the team. Please note, we cannot comment on unreleased features and future plans and issues which require deep level debugging.
+
+We're looking forward to having a conversation with you!
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+In November 2018, Azure App Service will update the PHP stacks to the latest available versions. For information on the changes in the new versions, please see the change logs on the PHP website.
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
We are happy to announce a new version of the VNet Integration capability that enables access to resources across Service Endpoints or ExpressRoute connections.
+
+Like the pre-existing VNet Integration feature, this only enables your app to make calls into your VNet. It does not affect inbound traffic to your app.
+
+This feature is in Preview in all public regions.
+
+The new VNet Integration capability has the following characteristics.
+
+
No gateway is required to use the new VNet Integration feature
+
You can access resources across ExpressRoute connections without any additional configuration beyond integrating with the ExpressRoute connected VNet.
+
The app and the VNet must be in the same region
+
The new feature requires an unused subnet in your Resource Manager VNet.
+
Your App Service plan must be a Standard, Premium or PremiumV2 plan
+
The new capability is only available from newer Azure App Service scale units. The VNet Integration UI in the portal will tell you if your app can use the new VNet Integration feature.
+
Production workloads are not supported on the new feature while it is in Preview
+
Your app must be in an Azure App Service deployment that is capable of scaling up to Premium v2.
+
The new VNet Integration feature does not work for apps in an App Service Environment.
+
The new VNet Integration feature currently works just with Windows apps.
+
+One address is used for each App Service plan instance. Since subnet size cannot be changed after assignment, use a subnet that can more than cover your maximum scale size. A /27 with 32 addresses is the recommended size as that would accommodate an App Service plan that is scaled to 20 instances. You can consume Service Endpoint secured resources using the new VNet Integration capability. To do so, enable service endpoints on the subnet used for VNet Integration.
+
+To use the feature, go to the Networking UI in the portal. If your app is able to use the new feature then you will see a capability to use the new preview feature. Simply select the Resource Manager VNet that you want to integrate with and then either create a new subnet or pick an empty pre-existing subnet.
+
+Initially there are some things that will not work initially against the subnet used for VNet Integration. They include peering, network security groups, and route tables. These capabilities will be gradually enabled during the preview period. Also not initially available is the ability for your web app to pick up the VNet DNS setting. If you want your app to use your VNet DNS server then create an Application setting for your app where the name is WEBSITE_DNS_SERVER and the value is the IP address of the server. If you have a secondary DNS server then create another Application setting where the name is WEBSITE_DNS_ALT_SERVER and the value is the IP address of the server.
+
+You can read more about the feature in the documentation on Integrate an app with a VNet
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Starting on November 13th 2018, and running approximately through December 14th 2018, Azure App Service will be updating the version of Git deployed on the service to version 2.19.1. This is expected to be a non-breaking update.
+For information on the changes contained in the new version please see the Git release notes here: https://raw.githubusercontent.com/git/git/master/Documentation/RelNotes/2.19.1.txt
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
This morning we released the fourth update to Azure App Service on Azure Stack. This release updates the resource provider and brings the following key capabilities and fixes:
+
+
Resolution forCVE 2018-8600Cross Site Scripting Vulnerability.
+
Added support for App Service 2018-02-01 API version
+
Updates toApp Service Tenant, Admin, Functions portals and Kudu tools. Consistent with Azure Stack Portal SDK version.
+
Updates to NodeJs, NPM, Zulu OpenJDK, Tomcat, PHP and Python
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+We have recently updated the WordPress on Linux offering on Azure Marketplace. In this version we have replaced Apache/mod_php with Nginx/PHP-FPM, we've seen the improved performance in our internal testing. Customers can use the WordPress on Linux image from the Azure Marketplace to create a new WordPress site and get the latest image automatically.
+
Upgrade WordPress on Linux
+If you have an existing WordPress site running on the previous version of the Marketplace template, you may upgrade to the new image following the steps below. Before you begin, we recommend you backup the database and WordPress site (details in Migrate section).
+
+Upgrade steps:
+
+
In the Azure Portal, find your Web App and go to "Container Settings"
+
Update the "image:tag" setting to 'appsvcorg/wordpress-alpine-php:0.61'
+
Click Save and wait for the Web App to restart
+
+
Migrate your site to WordPress on Linux
+For customers who plan to migrate their WordPress site to Azure App Service, while the Marketplace image comes with a fresh install of WordPress, customers can replace the code on the Web App and bring their own WordPress codebase (for example during migrations from on-premises or other hosting platforms).
+
+
Connect to the Web App using FTPS and replace the contents of the '/home/site/wwwroot' directory. Alternatively, you can create a zip file for your codebase and deploy it to the Web App using App Service zipdeploy.
+
Verify that 'wp-config.php' contains the correct database connection string, using the wp-config.php file from Azure Marketplace for reference.
+
For WordPress database, you can use tools such as mysqldump or MySQL Workbench to backup the MySQL database from the original server and restore it to Azure Database for MySQL.
+
+
Customization
+For cases in which additional customization is needed for plugins or themes, we recommend customers to modify the Docker image used in the Marketplace (source on GitHub), and run it on Web App for Containers. Once completed, migrate the site so that you don’t have to start from scratch.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Python 2.7 Now Available for App Service on Linux
+
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • January 4, 2019
+
+
+
+
+
+
+
+
+
+
+
+
+
Python 2.7 has been added to the public preview of Python on Azure App Service (Linux). With this recent addition developers can enjoy the productivity benefits and easy scaling features of Azure App Service using Python 2.7, 3.6 or 3.7. More details on the public preview of Python support on Azure App Service (Linux) are available here: https://azure.microsoft.com/en-us/blog/native-python-support-on-azure-app-service-on-linux-new-public-preview/
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • January 4, 2019
+
+
+
+
+
+
+
+
+Python 2.7 has been added to the public preview of Python on Azure App Service (Linux). With this recent addition developers can enjoy the productivit...
In the next release of Azure Web Apps, we will update the PHP stacks on Windows to the latest available versions. For information on the changes in the new versions, please see the change logs on the PHP website.
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
App Service Environment (ASE) support for Availability Zones (AZ) is now in preview. Customers can deploy internal load balancer (ILB) ASEs into a specific AZ (Zone 1, 2 or 3) within an Azure region, and the runtime resources used by that ILB ASE will be deployed into the specified AZ.
+
+An ILB ASE is deployed in a zonal manner which means the ILB ASE is pinned to a specific zone. This means all of the following runtime ILB ASE resources will be located in the specified zone: the internal load balancer IP address of the ASE, the compute resources used by the ASE to run web applications, and the underlying file content storage for all of the web applications deployed on the ASE.
+
+Currently ILB ASEs can be deployed into AZs in the Central US region. The set of available regions for the ASE AZ preview will be expanded over the course of January and February to include all AZ enabled Azure regions. Note that only ILB ASEs support availability zones - there are no plans at this time to enable AZ support for external facing ASEs (i.e. ASEs that have a public IP address for accepting website traffic).
+
+Customers can deploy an ASE into an availability zone using ARM templates. The ARM template snippet below shows the new properties and values in bold that tell the platform to deploy the ASE into an availability zone:
+
+
+
+There are only two minor changes needed in an ILB ASE ARM template to enable zonal deployment. The apiVersion property must be set to 2018-05-01-preview in order for the zones property to be processed. The zones property can be set as shown above with a value of 1, 2 or 3 depending on which zone you want to deploy the ASE into.
+
+In order to attain zone resiliency for apps created on AZ deployed ILB ASEs, customers will need to deploy at least two ILB ASEs - one per zone. Customers should then create and publish copies of their application onto each of the AZ deployed ASEs.
+
+Customers will additionally need to deploy a load balancing solution upstream of the AZ deployed ASEs so that traffic bound for an application is distributed across all instances of the ASEs. For example a zone-redundant Application Gateway could be deployed upstream, and then configured to route requests for a given application across all of the application instances created on the AZ deployed ASEs. More details on zone-redundant Application Gateway are available here: Autoscaling and Zone-redundant Application Gateway (Public Preview).
+
+Once an ASE and its applications are running inside of a specific zone, the applications will continue to run and serve traffic on that ASE even if other zones in the same region suffer an outage. However it is possible that non-runtime behavior including application service plan scaling as well as application creation/configuration/publishing may be impacted in the event of a region outage. Future investments into availability zone support for App Service will eventually extend zone resiliency to these non-runtime behaviors.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+App Service Environment (ASE) support for Availability Zones (AZ) is now in preview. Customers can deploy internal load balancer (ILB) ASEs into a spe...
+
+
+
+
+
+App Service Environment (ASE) support for Availability Zones (AZ) is now in preview. Customers can deploy internal load balancer (ILB) ASEs into a spe...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • January 4, 2019
+
+
+
+
+
+
+
+
+Python 2.7 has been added to the public preview of Python on Azure App Service (Linux). With this recent addition developers can enjoy the productivit...
The Z-Ray PHP debugging feature will soon be discontinued in App Service. This shouldn’t affect the App Service service-level agreement (SLA) or the runtime behavior of your applications.
+
+
Beginning March 9, 2019, Z-Ray will no longer be available for purchase in the Azure portal. If you already have applications configured with Z-Ray, you may continue to use it until June 7, 2019. After that date, the Z-Ray feature will be removed from all applications and you’ll no longer be charged for it.
+
+
Have you configured Zend Z-Ray for your app?
+
+
Even though no action is required for customers that have configured Zend Z-Ray for the app, you can look for instances of Zend Z-Ray using the Azure Cloud Shell and one of the following sample scripts:
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
The Z-Ray PHP debugging feature will soon be discontinued in App Service. This shouldn’t affect the App Service service-level agreement (SLA) or the runtime ...
Data connections provides a guided experience to easily add a connection string to a new or existing SQL Azure Database or Azure Storage Account.
+
+
To simplify the user experience, the data connections feature will be removed from the Web Apps menu on April 15, 2019. The feature has a limited audience, and you can easily create connection strings manually, as we describe below.
+
+
How can I add a connection string manually?
+
+
Use a new or existing data source
+
+
First determine whether you’ll create a data store or use an existing one.
+
+
If you’re going to create a data store, use one of the following quickstarts:
If you are using an existing data source, then your next step is to create the connection string.
+
+
Create the connection string
+
+
Depending on what data store you use, the connection string will have a different format:
+
+
SQL Database Connection String format
+
+
Data Source=tcp:{your_SQLServer},{port};Initial Catalog={your_catalogue};User ID={your_username};Password={your_password}
+
+
+
+
{your_SQLServer} Name of the server, this can be found in the overview page for your database and is usually in the form of “server_name.database.windows.net”.
+
{port} usually 1433.
+
{your_catalogue} Name of the database.
+
{your_username} User name to access your database.
In App Service, you can manage connection strings for your application by using the Configuration option in the menu.
+
+
To add a connection string:
+
+
+
+
Click on the Application settings tab.
+
+
+
Click on [+] New connection string.
+
+
+
You will need to provide Name, Value and Type for your connection string.
+
+
+
+
If your are adding a connection string to a SQL Azure database choose SQLAzure under type.
+
+
+
If your are adding a connection to an Azure Storage account, chose Custom under type.
+
+
+
+
+
+
+
+
+
NOTE If you are adding a connection string because you are planning on using the Easy API or Easy Table features, then the connection strings used by this features expect the following specific names:
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Azure App Service on Azure Stack Update 5 Released
+
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Andrew Westgarth
+
+ • February 28, 2019
+
+
+
+
+
+
+
This morning we released the fifth update to Azure App Service on Azure Stack. This release updates the resource provider and brings the following key capabilities and fixes:
+
+
+
Updates to App Service Tenant, Admin, Functions portals and Kudu tools. Consistent with Azure Stack Portal SDK version.
+
Updates to Kudu tools to resolve issues with styling and functionality for customers operating disconnected Azure Stack.
+
Updates to core service to improve reliability and error messaging enabling easier diagnosis of common issues.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Andrew Westgarth
+
+ • February 28, 2019
+
+
+
This morning we released the fifth update to Azure App Service on Azure Stack. This release updates the resource provider and brings the following key capab...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Andrew Westgarth
+
+ • February 28, 2019
+
+
+
This morning we released the fifth update to Azure App Service on Azure Stack. This release updates the resource provider and brings the following key capab...
The Z-Ray PHP debugging feature will soon be discontinued in App Service. This shouldn’t affect the App Service service-level agreement (SLA) or the runtime ...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Jason Freeberg
+
+ • March 18, 2019
+
+
+
We will soon be rolling out a series of UX and ARM API changes that will alter the behavior of routing rules for testing in production. After May 22nd, you w...
App Service Certificates have been a very popular feature among App Service customers. However, our customers often get confused about the sync scenarios bet...
App Service Certificates have been a very popular feature among App Service customers. However, our customers often get confused about the sync scenarios bet...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Jason Freeberg
+
+ • March 18, 2019
+
+
+
We will soon be rolling out a series of UX and ARM API changes that will alter the behavior of routing rules for testing in production. After May 22nd, you w...
In a fast-paced development environment, sometimes it is difficult to keep track of all the changes made to your app… let alone pinpoint a change that caused an unhealthy behavior. Change Analysis can help you narrow down on changes made to your app to facilitate the trouble-shooting experience.
+
+
Finding Change Analysis
+
+
Change Analysis is embedded in App Service Diagnostics’ tiles such as Application Changes and Application Crashes so you can use it concurrently with information from other tiles. For more information on how to navigate to App Service Diagnostics, please visit Azure App Service diagnostics overview.
+
+
How to enable Change Analysis
+
+
Upon opening a diagnostic report, you will see a message to enable Change Analysis. You can access the Change Analysis Settings by clicking on the Enable Now button.
+
+
+
+
Turn on Change Analysis and click Save to get property changes and code changes for your main web app. [Note: If you are using Change Analysis for the first time, enabling this setting will register Change Analysis Resource Provider on your subscription.] By enabling Change Analysis, your app’s Kudu will trigger a snapshot every 4 hours to capture the changes made between those time intervals.
+
+
+
+
To disable Change Analysis on your web app, click on Go to Change Analysis Settings in the upper right corner of Change Analysis in the diagnostic report. [Note: Change Analysis Resource Provider is still registered on the subscription of your web app.] To unregister Change Analysis Resource Provider from your subscription, navigate to your subscription, click Resource providers in the left navigation, select Microsoft.ChangeAnalysis, and click Unregister.
+
+
Navigating through the change timeline
+
+
Once Change Analysis is enabled, you will see a change timeline embedded in the diagnostic reports. The change timeline is populated by changes made in the past 24 hours, represented by square boxes on the timeline. You can click on each box to filter for corresponding change(s) in the change chart below. You can also use the search bar to filter for changes that have your search term.
+
+
+
+
You can also expand each row of change to view the difference between the old values and the new values.
+
+
+
+
Above the timeline is the last scanned time stamp that shows the last time the timeline was updated. If you wish to find out about changes made after the last scanned time, click Scan changes now. (This process may take few minutes)
+
+
+
+
After scanning is complete, you can update the timeline by clicking on View changes now.
+
+
+
+
Change Analysis in Practice
+
+
Now, let’s walk through a scenario where Change Analysis can be helpful. Suppose you have noticed some downtime in your app caused by a changed App Setting, but you do not know what has caused the issue. First, open a diagnostic report with Change Analysis like Application Crashes. Browse through the change timeline to see if there were any changes made before the app started crashing. If you do not find any changes on the timeline that could be related to the issue, click Scan changes now to update the timeline with the most recent changes. After the scanning completes, click View changes now to populate the timeline with the new changes. You notice there is one change that occurred right before the app started crashing. Expand the new change to view the differences. You may find that you accidentally deleted the connection string when you last made your code changes.
+
+
Used in tandem with other information, Change Analysis can serve as a powerful tool for diagnosing and solving problems with your web app.
+
+
Feel free to post any questions about Change Analysis on the MSDN Forum.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
In a fast-paced development environment, sometimes it is difficult to keep track of all the changes made to your app… let alone pinpoint a change that caused...
App Service plan defines the compute resource assigned to run your App Service. The pricing tier of your App Service plan determines the compute power and features you get, the higher the tier, the more features and compute power are available. To find out which features are supported in each pricing tier, see App Service plan details.
+
+
When you deploy multiple App Services in the same App Service plan, they all share the underlying compute resources. If your App Service plan has more than the recommended number of apps, the apps will compete for the same set of resources. This will cause high CPU & memory that could result in availability and performance issues.
+
+
How to verify the App Service plan density
+
+
In order to verify if your apps are possibly competing for resources, run the App Service plan Density check detector by following these steps:
+ 1) From the Azure Portal, go to on of your Apps
+ 2) Go to the “Diagnose and solve problems” blade
+ 3) Then either select the ‘Risk Assessments’ category or you can search for “Best Practices for Availability & Performance” in the search bar
+
+
You will see one of the following:
+ 1) Your plan is within the recommended value
+
+
2) Your plan is nearing exhaustion
+
+
+
Recommended Solutions
+
1) Stop apps to decrease load
+In the description, the detector will recommend stopping a number of apps to be within the recommended number of apps on the respective pricing tier. The number may actually be lower depending on how resource intensive the hosted applications are, however as a general guidance, you may refer to the table below.
+
+
+
+
+
App Service Plan SKU
+
Max Apps
+
+
+
+
+
B1, S1, P1v2, I1v1
+
8
+
+
+
B2, S2, P2v2, I2v1
+
16
+
+
+
B3, S3, P3v2, I3v1
+
32
+
+
+
P1v3, I1v2
+
16
+
+
+
P2v3, I2v2
+
32
+
+
+
P3v3, I3v2
+
64
+
+
+
+
+
Note : An active slot is also classified as an active app as it too is competing for resources on the same App Service Plan.
+
+2) Scale up your App Service plan
+If your App Service plan is on a Small/Medium tier, scaling up the plan will move the apps to a higher compute power with better CPU and memory. If you are not running on a Pv2 plan, Pv2 features Dv2-series VMs with faster processors, SSD storage, and double memory-to-core ratio compared to Standard.
+
+
+3) Split Apps in multiple App Service plans
+If you have other App Service plans that have been created in the same Resource Group and Region, you can move your app to one of those plans and decrease the load.
+
+
+
Alternatively, you can follow these steps to create an App Service plan that will be able to move your app to:
+ a) Create a new App Service Plan in the same resource group and location
+ b) Select a pricing tier that fits the performance and feature needs for your application.
+ c) Navigate to the application in the Azure Portal whose app service plan you want to change.
+ d) Select the “Change App Service Plan” tab from the left sidebar menu.
+ e) Choose the newly created App Service Plan (created in Step 2).
+
+
Feel free to post any questions about App Service plan density check on the MSDN Forum.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
App Service plan defines the compute resource assigned to run your App Service. The pricing tier of your App Service plan determines the compute power and fe...
Azure App Service on Azure Stack Update 6 Released
+
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Andrew Westgarth
+
+ • May 28, 2019
+
+
+
+
+
+
+
This afternoon we released the sixth update to Azure App Service on Azure Stack. This release updates the resource provider and brings the following key capabilities and fixes:
+
+
+
Updates to App Service Tenant, Admin, Functions portals and Kudu tools. Consistent with Azure Stack Portal SDK version.
+
Updates to Kudu tools to resolve issues with styling and functionality for customers operating disconnected Azure Stack.
+
Updates to core service to improve reliability and error messaging enabling easier diagnosis of common issues.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Andrew Westgarth
+
+ • May 28, 2019
+
+
+
This afternoon we released the sixth update to Azure App Service on Azure Stack. This release updates the resource provider and brings the following key cap...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Andrew Westgarth
+
+ • May 28, 2019
+
+
+
This afternoon we released the sixth update to Azure App Service on Azure Stack. This release updates the resource provider and brings the following key cap...
App Service plan defines the compute resource assigned to run your App Service. The pricing tier of your App Service plan determines the compute power and fe...
In a fast-paced development environment, sometimes it is difficult to keep track of all the changes made to your app… let alone pinpoint a change that caused...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Eric Stenson
+
+ • June 18, 2019
+
+
+
+
+
+
+
Latest version updates to PHP
+
+
In August 2019, Azure App Service will update the PHP stacks to the latest available versions. For information on the changes in the new versions, please see the change logs on the PHP website.
+
+
+
+
+
PHP Version
+
Change Log
+
+
+
+
+
5.6.401
+
http://www.php.net/ChangeLog-5.php#5.6.40 + security fixes from https://github.com/microsoft/php-src/commits/PHP-5.6-security-backports
+
+
+
7.0.331
+
http://www.php.net/ChangeLog-7.php#7.0.33 + security fixes from https://github.com/microsoft/php-src/commits/PHP-7.0-security-backports
+
+
+
7.1.30
+
http://www.php.net/ChangeLog-7.php#7.1.30
+
+
+
7.2.20
+
http://www.php.net/ChangeLog-7.php#7.2.20
+
+
+
7.3.6
+
http://www.php.net/ChangeLog-7.php#7.3.6
+
+
+
+
+
Feel free to post any questions about PHP Minor Version Update for August 2019 on the MSDN Forum.
+
+
+
1 - Both PHP v5.6 and v7.0 are past End-Of-Life, and are no longer receiving security updates from the community. However, to ensure our customers have the most secure PHP builds available, we have arranged to have relevant security fixes from supported versions of PHP backported to PHP v5.6 and v7.0.
+
+
+
Edit: Due to an issue with the Zend Opcache extension in PHP 7.2.19, we will move to 7.2.20 for this update.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Eric Stenson
+
+ • July 17, 2019
+
+
+
+
+
+
+
Latest version updates to PHP
+
+
In July 2019, Azure App Service will update the PHP stacks to the latest available versions. For information on the changes in the new versions, please see the change logs on the PHP website.
+
+
+
+
+
PHP Version
+
Change Log
+
+
+
+
+
7.1.28
+
http://www.php.net/ChangeLog-7.php#7.1.28
+
+
+
7.2.17
+
http://www.php.net/ChangeLog-7.php#7.2.17
+
+
+
7.3.4
+
http://www.php.net/ChangeLog-7.php#7.3.4
+
+
+
+
+
Feel free to post any questions about PHP Minor Version Update for July 2019 on the MSDN Forum.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Removing Easy Tables and Easy APIs from Azure App Service
+
+
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Ela Malani
+
+ • July 25, 2019
+
+
+
+
+
+
+
+
+
+
Integrating mobile services in your application? Sign up with App Center
+
+
+
Visual Studio App Center is the next generation solution for mobile application developers. It offers integrated end-to-end services central to mobile development. If you are integrating Microsoft cloud services in your mobile application, sign up with App Center today.
+
+
Removing Easy Tables and Easy APIs from Azure App Service
+
Azure App Service provides specific features for Node developers to easily get started with mobile backend services by leveraging Easy Tables and Easy APIs in the Azure portal. Easy Tables provides a portal experience for Node developers to create and manage their tables, their schema, and appropriate permissions. Easy APIs lets developers build and consume custom APIs in the backend.
+
+
Easy Tables and Easy APIs, along with the Mobile menu in the Azure portal will be removed on November 11, 2019 as these features have a limited audience and the existing functionality can be leveraged in alternate ways.
+
+
Developers that have mobile apps with a Node.js backend can leverage the existing functionality from Easy API and Easy Tables by following the guidance below.
+
+
Easy API
+
+
Existing API
+
+
Your existing APIs will continue to work as the backend is already deployed on App Services.
+
+
Create a new API or make changes to existing API
+
+
You can either make changes right in the Azure portal or modify the code locally in your development environment and then publish to Azure. Click on the App Service Editor (Preview) under Development Tools menu which provides an in-browser editing experience for your app code.
+
+
+
+
Click on Go and once the App Service Editor opens, you have full control over the source code. Assuming you have already installed express and azure-mobile-apps package with npm install command, click on the api folder under WWWROOT to create or edit custom API. Make your changes to the code file and the changes are saved automatically.
+
+
+
+
Easy Tables
+
+
You have full control on the Azure SQL Database used to store the application data. Your existing tables will continue to work without any required changes. For the existing portal features, below are the alternatives:
In App Service Editor or locally, click on wwwroot/tables directly to create new files, {tablename}.js and {tablename}.json where {tablename} refers to the name of the table you created in Step 1. Sample code can be found at todoitem.js and todoitem.json.
+
+
+
Edit the files locally and deploy the changes to Azure App Service.
+
+
+
+
Change permission
+
+
In order to change access permissions on tables, you can either use the portal to change the code or modify it locally in your development environment. Click on the App Service Editor (Preview) under Development Tools menu which provides an in-browser editing experience for your app code.
+
+
Assuming you have already installed express and azure-mobile-apps package with npm install command, click on “Go” to open the App Service Editor. Once open, click on the tables folder under WWWROOT and open the json file for the table that you want the permissions to change. This will let you modify the access permissions for insert, update, delete, read and undelete operations for that table. You can also do this locally in the app code and deploy back to App Services.
+
+
Edit script
+
+
You can edit your table script by either using the App Service Editor or modifying the code locally and deploying it back to App Services.
+
+
Delete table
+
+
Since you own your SQL database, you can delete the table by executing a SQL query against the database.
+
+
Clear table
+
+
Since you own your SQL database, you can clear contents of the table by executing a SQL query against the database.
+
+
Streaming logs
+
+
You can use Log stream under the Monitoring menu to stream your application and Web Server logs.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+ Azure Key Vault References with Spring Apps
+
+
+
+
+
Securely store and access your connection strings with minimal code changes.
+
+
+
+
+
+
+
+
+
+ 5 minute read
+ | By Jason Freeberg
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Azure Key Vault provides a centralized service for managing secrets and certificates with full control over access policies and auditing capabilities. This article will show how to wire up a Spring Boot application on App Service to read a database username, password, and URL from Key Vault. Using Key Vault references requires no code changes, but we will need to do some configuration acrobatics.
+
+
+
See the previous article for instructions on setting up the Postgres server and deploying the starter app to App Service.
+
+
+
Set up a Managed Identity
+
+
A managed identity acts as a user in your Active Directory for automation purposes. It is inherently tied to your web app and will be deleted if the web app is deleted. For this scenario, the identity will be used to retrieve the secrets from Key Vault when the app starts. Run the following command to create a manged identity:
+
+
az webapp identity assign --name <app_from_last_article> --resource-group <resource_group_of_app>
+
+
+
In the console output, save the principalId for later.
+
+
Provision the Key Vault
+
+
+
+
Let’s spin up a Key Vault named java-app-key-vault. For information about the parameters specified below, run az keyvault create --help.
Now we will grant the managed identity get and list access to the Key Vault.
+
+
az keyvault set-policy --name java-app-key-vault \
+ --secret-permission get list \
+ --object-id <the principal ID from earlier>
+
+
+
+
Finally, we will add the Postgres username, password, and URL to the Key Vault. If you followed the tutorial on data sources, you should still have the secrets saved as environment variables on your machine. (If you are using Powershell, use the $env:ENV_VAR syntax to inject the environment variables into the following command).
The following instructions assume you have completed the previous tutorial.
+
+
Key Vault References
+
+
When our Spring app is running on App Service, the secrets will be exposed as environment variables or “Application Settings”. We will now create these app settings using the Azure CLI.
+
+
+
+
First, we need the URI’s of our three secrets. Run the commands below and copy the id value in the console output.
+
+
az keyvault secret show --vault-name java-app-key-vault --name POSTGRES-URL
+ az keyvault secret show --vault-name java-app-key-vault --name POSTGRES-USERNAME
+ az keyvault secret show --vault-name java-app-key-vault --name POSTGRES-PASSWORD
+
+
+
+
Now we will create the app settings with the Key Vault references. For each setting, replace “YOUR_SECRET_URI” with the corresponding id’s from the previous step.
A Key Vault reference is of the form @Microsoft.KeyVault(SecretUri=<SecretURI>), where <SecretURI> is data-plane URI of a secret in Key Vault, including a version. There is an alternate syntax documented here.
+
+
Environment Configuration
+
+
The Key Vault references will be replaced with the actual secrets when our App Service boots up. This means our Spring application needs to resolve the connection strings at runtime. (It currently resolves these strings at build time.) We also want to be able to use our H2 database for development, and optionally connect to the production DB from our local machine to run tests. To fill all these requirements, we will create two new configuration files: application-dev.properties, and application-prod.properties.
+
+
+
+
Create a file under src/main/resources named application-dev.properties. Copy/paste the following into the file:
+
+
# ===============================
+ # = DATA SOURCE
+ # ===============================
+ # Set here configurations for the database connection
+ spring.datasource.url=jdbc:h2:mem:testdb
+ spring.datasource.username=sa
+ spring.datasource.password=
+ spring.datasource.driver-class-name=org.h2.Driver
+
+ # ===============================
+ # = JPA / HIBERNATE
+ # ===============================
+
+ # Allows Hibernate to generate SQL optimized for a particular DBMS
+ spring.jpa.properties.hibernate.dialect=org.hibernate.dialect.H2Dialect
+
+ # App Service
+ server.port=8080
+
+
+
+
Create a file under src/main/resources named application-dev.properties. Copy/paste the following into the file. Notice that we do not set the connection strings here. Instead, Spring will resolve them at runtime by looking for the uppercase and underscored versions of spring.datasource.url, spring.datasource.username, and spring.datasource.password.
+
+
# ===============================
+ # = DATA SOURCE
+ # ===============================
+
+ # The connection URL, username, and password will be sourced from environment variables
+ # on App Service
+
+ # Set here configurations for the database connection
+ spring.datasource.driver-class-name=org.postgresql.Driver
+
+ # ===============================
+ # = JPA / HIBERNATE
+ # ===============================
+
+ # Allows Hibernate to generate SQL optimized for a particular DBMS
+ spring.jpa.properties.hibernate.dialect=org.hibernate.dialect.PostgreSQLDialect
+
+ # App Service
+ server.port=80
+
+
+
+
Now we can slim-down our original application.properties file. Replace the contents of application.properties with the following:
+
+
# Active profile is set by Maven
+ spring.profiles.active=@spring.profiles.active@
+
+ # ===============================
+ # = DATA SOURCE
+ # ===============================
+
+ # Keep the connection alive if idle for a long time (needed in production)
+ spring.datasource.testWhileIdle=true
+ spring.datasource.validationQuery=SELECT 1
+
+ # ===============================
+ # = JPA / HIBERNATE
+ # ===============================
+ # Show or not log for each sql query
+ spring.jpa.show-sql=true
+
+ # Hibernate ddl auto (create, create-drop, update):with "create-drop" the database
+ # schema will be automatically created afresh for every start of application
+ spring.jpa.hibernate.ddl-auto=create
+
+ # Naming strategy
+ spring.jpa.hibernate.naming.implicit-strategy=org.hibernate.boot.model.naming.ImplicitNamingStrategyLegacyHbmImpl
+ spring.jpa.hibernate.naming.physical-strategy=org.springframework.boot.orm.jpa.hibernate.SpringPhysicalNamingStrategy
+
+
+
+
Finally, we can also slim down our Maven profiles because we have moved th information to the new properties files. The profile section of your pom.xml should now be the following:
+
+
<profiles>
+ <profile>
+ <!-- This profile will configure Spring to use an in-memory database for local development and testing. -->
+ <id>dev</id>
+ <activation>
+ <activeByDefault>true</activeByDefault>
+ </activation>
+ <properties>
+ <spring.profiles.active>dev</spring.profiles.active>
+ </properties>
+ </profile>
+ <profile>
+ <!-- This profile will configure the application to use our Azure PostgreSQL server. -->
+ <id>prod</id>
+ <properties>
+ <spring.profiles.active>prod</spring.profiles.active>
+ </properties>
+ </profile>
+ </profiles>
+
+
+
+
+
See this article for more information on Spring configurations and precedence.
+
+
Deploy and Test
+
+
Check that the development profile works as expected by running the following commands and opening a browser to http://localhost:8080/.
Before deploying to App Service, build your application with the production profile and test against your PostgreSQL DB from your local machine. To do so, rename the three environment variables beginning with POSTGRES_ to SPRING_DATASOURCE_URL, SPRING_DATASOURCE_USERNAME, and SPRING_DATASOURCE_PASSWORD respectively. Run the following commands to build and start your app. Thanks to our new configuration, Spring will resolve the connection strings in the environment variables at runtime.
Finally, deploy the production app to App Service with mvn azure-webapp:deploy. Browse to the application and test that it works properly.
+
+
Next Steps
+
+
See the Java Developer Guide for more documentation and best practices for Java on App Service. Check back in the future for more articles. Thanks for reading!
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Application downtime can be dreadful, especially when the app is handling mission-critical load. There could be countless causes for your app’s downtime ranging from the app’s code to the misconfiguration of its dependencies. Fast troubleshooting is the key to minimizing the production impact. However, the complex nature of today’s applications makes narrowing down the cause a lengthy and difficult process. Sometimes it requires thorough investigation of changes made to each dependent resource.
+
+
We are excited to announce Navigator, a new feature offering for Windows apps in App Service Diagnostics, an intelligent and guided experience that helps you troubleshoot your web app with little to no configuration. Navigator is a new diagnostic feature that provides a centralized view of a web app and its dependencies as well as the changes made to those dependencies. The feature can automatically render dependencies in the same subscription as a dependency map and display the changes made to each resource, leveraging Change Analysis. With the new experience, you can easily identify the dependencies of your web app and explore the changes as part of your troubleshooting experience.
+
+
Paired with information from existing diagnostics information in App Service Diagnostics, Navigator can supplement your troubleshooting experience by providing a timeline of the changes made by your web app and its dependencies. Correlating this information with other information offered in App Service Diagnostics can help you further understand the changes and narrow down on potential causes for unhealthy behavior.
+
+
Finding Navigator
+
+
Navigator can be accessed through App Service Diagnostics’ homepage tile called Navigator so you can use it concurrently with information from other tiles. For more information on how to navigate to App Service Diagnostics, please visit Azure App Service diagnostics overview.
+
+
+
+
How to enable Change Analysis
+
+
Upon opening the tool, you will see a message to enable Change Analysis. You can access the Change Analysis Settings by clicking on the Enable Now button.
+
+
+
+
Turn on Change Analysis and click Save to get property changes and code changes for your main web app as well as property changes for your dependent resources. [Note: If you are using Change Analysis for the first time, enabling this setting will register Change Analysis Resource Provider on your subscription.] By enabling Change Analysis, your app’s Kudu will trigger a snapshot every 4 hours to capture the changes made between those time intervals.
+
+
+
+
To disable Change Analysis on your web app, click on Go to Change Analysis Settings in the upper right corner of Navigator view. [Note: Change Analysis Resource Provider is still registered on the subscription of your web app.] To unregister Change Analysis Resource Provider from your subscription, navigate to your subscription, click Resource providers in the left navigation, select Microsoft.ChangeAnalysis, and click Unregister.
+
+
Navigating through the change timeline
+
+
Once Change Analysis is enabled, you will see a dependency map of your web app and its dependencies in the same subscription. You can check the inner workings of your app using this view. Also, if you click on a resource supported by Change Analysis, you can view the recent changes made to the selected resource. See Change Analysis service to view the list of dependencies supported by Change Analysis service.
+
+
+
+
Once you click on each resource on the map, you will see a timeline with square boxes and a list of changes detected over the last 24 hours. These square boxes represent change(s) made during the 24 hours. You can click on each box to filter for corresponding change(s) in the list of changes below. You can also use the search bar to filter for changes that have your search term.
+
+
+
+
You can also expand each row of change to view the difference between the old values and the new values.
+
+
+
+
Above the timeline is the last scanned time stamp that shows the last time the timeline was updated. If you wish to find out about changes made after the last scanned time, click Scan changes now. (This process may take few minutes)
+
+
+
+
After scanning is complete, you can update the timeline by clicking on View changes now.
+
+
+
+
Navigator in Practice
+
+
Now, let’s explore a scenario where Navigator can come in handy. Suppose you have noticed a spike in the database connection errors in your app caused by a firewall rule, but you do not know what has caused the issue. First, click on Navigator in App Service Diagnostics. Take a look at the dependency map. Select a resource to explore the changes made to the resource. Browse through the timeline to see if there were any changes made before you observed unexpected behavior. If you do not find any changes on the timeline that could be related to the issue, click Scan changes now to update the timeline with the most recent changes. After the scanning completes, click View changes now to populate the timeline with the new changes. You notice there is one change that occurred right before the app started giving you database connection errors. Expand the new change to view the differences. You may find that you accidentally changed the firewall rules.
+
+
Used in tandem with other information from App Service Diagnostics, Navigator can serve as a powerful tool for diagnosing and solving problems with your web app.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Elle Tojaroon
+
+ • August 6, 2019
+
+
+
+
+
+
+
If you deleted your App Service Domain resource within the past 30 days, you can easily restore it by purchasing it again with the same Domain Registration Subscription and resource group. Unlike trying to purchase the domain name from other subscriptions or resource groups, the validation will allow you to purchase the same domain name.
+
+
Clarifications
+
+
+
+
App Service Domains are domains that were purchased from Azure App Service. Domains added to App Service websites are custom domains. These are different resources.
+
+
+
If your App Service Domain was deleted because you deleted the domain registration subscription, we do not support restoring the domain in any circumstance.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Application downtime can be dreadful, especially when the app is handling mission-critical load. There could be countless causes for your app’s downtime rang...
+
+
+
+
+
+
+ 4 minute read
+
+
+
+ • By Jason Freeberg
+
+ • August 10, 2019
+
+
+
+
+
+
+
+
+
Last week GitHub announced the preview of GitHub Actions with built-in CI/CD; watch the announcement here. These actions, defined in YAML files, allow you to trigger an automated workflow process on any GitHub event. Today the App Service team is happy to share our own action, allowing you to deploy to App Service following a push or pull request.
+
+
With the App Service Action, you can deploy your code to any of our managed language stacks. Simply specify your source code folder, zip file, JAR or WAR. If you prefer to deploy a Docker container instead, there’s an action for that!
+
+
Getting Started
+
+
+
GitHub Actions are currently in Beta. Request access here.
+
+
+
Configure the repository
+
+
+
Open the Azure Portal and navigate to your web app.
+
In the toolbar, select Get publish profile. This will trigger a download.
+
+
Open the downloaded file and copy the contents
+
Open GitHub and navigate to your repository
+
Select Settings > Secrets. On the Secrets page, select Add a new secret and paste your publish profile XML.
+
+
+
+
Now you’re ready to create the workflow file.
+
+
Create the action
+
+
If you do not have any workflows defined, select the Actions tab and follow the prompts to create a new workflow. This will create a new directory an file in the root of your repository, /.github/workflows/workflow.yml.
+
+
In the editor for workflow.yml, define the build steps for your application. For example, a Node application is typically built using npm install followed by npm run build. Below is an example workflow file that installs the dependencies, builds the project, and runs tests on the latest Ubuntu version.
+
+
on:push
+
+jobs:
+ build:
+ runs-on:ubuntu-latest
+ steps:
+ # This checks out the repository so your workflow operates from root of repository
+ -uses:actions/checkout@master
+
+ # Install dependencies, build, and test
+ -name:npm install, build, and test# Name is optional
+ run:|
+ npm install
+ npm run build --if-present
+ npm run test --if-present
+
+
+
See the examples at the end of this article for specific language examples.
+
+
Add the App Service Action
+
+
After your build action, add the App Service action with uses: azure/appservice-actions/webapp@master. This action has the following required arguments. These should be listed under a with: key:
+
+
+
app-name: Your application name
+
package: The path to the deployment file or folder (relative from the root)
+
publish-profile: The publish profile that you pasted into the GitHub Secrets earlier
+
+
+
# Deploy to App Service
+-name:'RunAzurewebappdeployactionusingpublishprofilecredentials'
+ uses:azure/webapps-deploy@v1
+ with:
+ app-name:node-rn# Replace with your app name
+ publish-profile:${{ secrets.azureWebAppPublishProfile }}# Replace with the name of your publish profile
+ package:<path to artifact># Specify the folder or file to deploy
+
+
+
Deploy to a slot
+
+
The App Service Action deploys to the production slot by default. To deploy to a staging slot, redo the publish profile steps with the publish profile from your desired staging slot.
+
+
Other Azure Actions
+
+
In addition to this action, there are actions for other common Azure scenarios such as deploying to Azure Kubernetes Service, logging into Azure with a service principal, or signing into Docker. See the links below.
+
+
Examples
+
+
Containers
+
+
To deploy a container, you will need to create an Azure Service Principal via the Azure CLI, then paste the details of the principal as a GitHub Secret.
+
+
+
Install the Azure CLI
+
+
Run the following command, replacing {subscription} and {resource-group} with the subscription and resource group of your application
+
+
az ad sp create-for-rbac --name"myServicePrincipal"--role contributor \
+ --scopes /subscriptions/{subscription}/resourceGroups/{resource-group}\
+ --sdk-auth
+
+
+
Open GitHub and navigate to your repository
+
Select Settings > Secrets. On the Secrets page, select Add a new secret and paste the JSON output from the earlier az ad sp command.
+
+
Finally, add your Docker username and password as GitHub Secrets
+
+
+
Here is a full example:
+
+
on:push
+
+jobs:
+ deploy-container:
+ runs-on:ubuntu-latest
+ steps:
+ -uses:actions/checkout@master
+
+ # Unlike code deployment, you will authenticate using a Service Principal
+ -uses:azure/actions/login@master
+ with:
+ creds:${{ secrets.AZURE_SP }}
+
+ # These creds are used to push your new image
+ -uses:azure/container-actions/docker-login@master
+ with:
+ username:${{ secrets.DOCKER_USERNAME }}
+ password:${{ secrets.DOCKER_PASSWORD }}
+ #loginServer: '<login server>' # default: index.docker.io
+
+ # Tag the image with the git commit hash
+ -run:|
+ docker build . -t contoso/demo:${{ github.sha }}
+ docker push contoso/demo:${{ github.sha }}
+
+ -uses:azure/appservice-actions/webapp-container@master
+ with:
+ app-name:'<yourappname>'
+ images:'contoso/demo:${{github.sha}}'
+ #configuration-file: 'Optional path to a docker compose file'
+ #container-command: 'Optional startup command for the app (dotnet run, java -jar app.jar)'
+
+
+
Java
+
+
When deploying Java apps, make sure you specify the package name relative from the root directory. Most likely, your deployment artifact will be in the target/ directory.
+
+
on:push
+
+jobs:
+ java-build-and-deploy:
+ runs-on:ubuntu-latest
+ steps:
+
+ -uses:actions/checkout@master
+
+ -name:Set up JDK 1.8
+ uses:actions/setup-java@v1
+ with:
+ java-version:1.8
+
+ # install dependencies, build, and test
+ -name:Maven build phase
+ run:|
+ mvn clean package
+
+ -uses:azure/webapps-deploy@v1
+ with:
+ app-name:<your-app-name>
+ publish-profile:${{ secrets.<publish-profile> }}
+ package:target/app.war# Can also be a jar
+
+
+
Node
+
+
on:push
+
+jobs:
+ build-and-deploy:
+ runs-on:ubuntu-latest
+ steps:
+ -uses:actions/checkout@master
+
+ -name:Set Node.js version
+ uses:actions/setup-node@v1
+ with:
+ node-version:'10.x'
+
+ # install dependencies, build, and test
+ -name:npm install, build, and test
+ run:|
+ npm install
+ npm run build --if-present
+ npm run test --if-present
+
+ -uses:azure/webapps-deploy@v1
+ with:
+ app-name:<your-app-name>
+ publish-profile:${{ secrets.<publish-profile> }}
+ package:'.'
+
+
+
Python
+
+
on:push
+
+jobs:
+ build-and-deploy:
+ runs-on:ubuntu-latest
+ steps:
+ -uses:actions/checkout@master
+
+ -uses:actions/setup-python@v1
+ with:
+ python-version:'3.7.4'
+
+ -name:install dependencies, and zip the app to use ZipDeploy
+ run:|
+ pip install -r requirements.txt
+
+ -uses:azure/appservice-actions/webapp@master
+ with:
+ app-name:<your-app-name>
+ publish-profile:${{ secrets.<publish-profile> }}
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 4 minute read
+
+
+
+ • By Jason Freeberg
+
+ • August 10, 2019
+
+
+
Last week GitHub announced the preview of GitHub Actions with built-in CI/CD; watch the announcement here. These actions, defined in YAML files, allow you to...
Azure App Service on Azure Stack Update 7 Released
+
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Andrew Westgarth
+
+ • August 29, 2019
+
+
+
+
+
+
+
This afternoon we released the seventh update to Azure App Service on Azure Stack. This release updates the resource provider and brings the following key capabilities and fixes:
+
+
+
Updates to App Service Tenant, Admin, Functions portals and Kudu tools. Consistent with Azure Stack Portal SDK version.
+
Updates to core service to improve reliability and error messaging enabling easier diagnosis of common issues.
+
Access Restrictions now enabled in User Portal
+As of this release Users can configure Access Restrictions for their Web/Api/Functions applications according to the documentation published - Azure App Service Access Restrictions, NOTE: Azure App Service on Azure Stack does not support Service Endpoints.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Andrew Westgarth
+
+ • August 29, 2019
+
+
+
This afternoon we released the seventh update to Azure App Service on Azure Stack. This release updates the resource provider and brings the following key c...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Andrew Westgarth
+
+ • August 29, 2019
+
+
+
This afternoon we released the seventh update to Azure App Service on Azure Stack. This release updates the resource provider and brings the following key c...
+
+
+
+
+
+
+ 4 minute read
+
+
+
+ • By Jason Freeberg
+
+ • August 10, 2019
+
+
+
Last week GitHub announced the preview of GitHub Actions with built-in CI/CD; watch the announcement here. These actions, defined in YAML files, allow you to...
Application downtime can be dreadful, especially when the app is handling mission-critical load. There could be countless causes for your app’s downtime rang...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Eric Stenson
+
+ • September 4, 2019
+
+
+
+
+
+
+
Latest version updates to PHP
+
+
In September 2019, Azure App Service will update the PHP stacks to the latest available versions. For information on the changes in the new versions, please see the change logs on the PHP website.
+
+
+
+
+
PHP Version
+
Change Log
+
+
+
+
+
5.6.401
+
http://www.php.net/ChangeLog-5.php#5.6.40 + security fixes from https://github.com/microsoft/php-src/commits/PHP-5.6-security-backports
+
+
+
7.0.331
+
http://www.php.net/ChangeLog-7.php#7.0.33 + security fixes from https://github.com/microsoft/php-src/commits/PHP-7.0-security-backports
+
+
+
7.1.32
+
http://www.php.net/ChangeLog-7.php#7.1.32
+
+
+
7.2.22
+
http://www.php.net/ChangeLog-7.php#7.2.22
+
+
+
7.3.9
+
http://www.php.net/ChangeLog-7.php#7.3.9
+
+
+
+
+
+
1 - Both PHP v5.6 and v7.0 are past End-Of-Life, and are no longer receiving security updates from the community. However, to ensure our customers have the most secure PHP builds available, we have arranged to have relevant security fixes from supported versions of PHP backported to PHP v5.6 and v7.0.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Azure Resource Manager (ARM) templates are used to automate deployment and configuration of Azure resources. With the templates you can define the infrastructure to be deployed via a JSON file and then use that file to repeatedly deploy new resources or update existing ones. ARM templates are widely used to release new versions of the Azure web apps and function apps. During a release the new version of an app is deployed to a staging slot and then it is swapped into production. This blog post explains how to automate the App Service deployment slot swap operation with an ARM template.
+
+
Let’s assume you have a web app with production and staging deployment slots. When you release a new version of that web app you first would deploy it to the staging slot and then swap it into production slot. To define the swap operation via ARM template you’ll need to use two properties on the “Microsoft.Web/sites” and “Microsoft.Web/sites/slots” resources:
+
+
+
buildVersion – this is a string property which can be set to any arbitrary value that would represent the current version of the app deployed in the slot. For example: “v1“, “1.0.0.1“, “2019-09-20T11:53:25.2887393-07:00“.
+
targetBuildVersion – this is a string property that is used to specify what version of the app the current slot should have. If the targetBuildVersion is different from the buildVersion then this will trigger the swap operation by finding a slot that has the expected build version and then swapping the site from that slot into the current slot.
+
+
+
With that the process of deploying a new version of an app can be done as follows:
+
+
+
Deploy a new version of an app into a staging slot
+
Execute ARM template to update the buildVersion of the app in staging slot
+
Execute ARM template to set the targetBuildVersion on the production slot
+
Here is an example ARM template that demonstrates how to perform steps #2 and #3:
This ARM template is idempotent, meaning that it can be executed repeatedly and produce the same state of the slots. In other words if you re-run the same template with the same parameters after the swap has been performed and targetBuildVersion on production slot matches the buildVersion then it will not trigger another swap.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Currently offered in App Service Diagnostics for Windows web apps.
+
+
+
Imagine there is a CPU spike in your cloud application at 2:00 in the morning, would you like to be woken up to mitigate and troubleshoot the issue or would you rather have the issue mitigated automatically and troubleshoot after a good night’s sleep? For those of us that enjoy a good night’s sleep, Proactive CPU monitoring is an easy, proactive way to take an action when your app or its child process is consuming too much CPU. You can configure CPU rules to temporarily mitigate a high CPU issue until the real cause for the unexpected issue is found.
+
+
Finding Proactive CPU Monitoring
+
+
To access Proactive CPU Monitoring, browse to your App Service web app in Azure portal and click Diagnose and solve problems in the left navigation panel. Then, click on the homepage tile named Diagnostic Tools. Once you are inside Diagnostic Tools, click Proactive CPU Monitoring.
+
+
+
+
Configuring Proactive CPU Monitoring
+
+
Proactive CPU monitoring operates based on 5 conditions and 4 modes of action by checking w3wp.exe process of the site or any child processes.
+
+
Conditions
+
+
There are five conditions you can configure to tailor to your needs.
+
+
+
CPU Threshold: the CPU threshold at which the rule will be triggered
+
Threshold Seconds: the duration of the CPU exceeding the CPU threshold. The rule will be triggered at the end of the duration.
+
Monitor Frequency: defines how often the condition will be evaluated
+
Maximum Actions: the maximum number of memory dumps that the rule collects, ensuring no dumps are collected beyond the set amount
+
Maximum Duration: the maximum duration of the rule until it becomes deactivated
+
+
+
Actions
+
+
Once the conditions are met, your selected action is triggered. Proactive CPU Monitoring offers 4 different modes listed below.
+
+
+
+
Collect: In this mode, a memory dump is collected whenever any process consumes CPU greater than the CPU Threshold for longer than the allowed Threshold Seconds. (Monitor Duration should always be lower than Threshold Seconds) Memory dump is collected via ProcDump.exe, and the number of dumps (or actions) are controlled by Maximum Actions. Once Maximum Duration is met, the rule becomes deactivated.
+
+
When the memory dump is collected, the process is frozen until the dump generation completes. The time the process is frozen depends directly on the memory consumed by the process. The size of the dump generated is also directly proportional to the memory consumed by the process.
+
+
+
Kill: In this mode, the process is killed when the condition is met. The Maximum Actions is not honored and monitoring stops automatically after Maximum Duration. Kill is a forceful termination of the process and not a graceful exit. All requests that the current worker process is processing will be terminated, and end users may see 502 errors. If system terminates the child process, the error message may even be 500 or some form of application exception based on the stack.
+
+
+
Collect and Kill: In this mode, a memory dump is collected and the process consuming high CPU is killed when the site’s process (or child process) consumes CPU greater than CPU threshold for more than Threshold Seconds. No analysis is performed but after the session finishes, you have an option to analyze the memory dump after the session ends by clicking the Analyze button.
+
+
+
Collect, Kill, and Analyze: In this mode, a memory dump is collected and the process consuming high CPU is killed when a site’s process (or child process) consumes CPU greater than the CPU threshold for longer than the allowed Threshold Seconds. In addition, CPU dumps are analyzed by DumpAnalyzer tool, and an analysis report is generated. Analyzing a dump with this tool has some CPU impact on the instance and takes roughly 5-7 minutes at minimum to analyze one dump file. Analysis can take longer if the dump size is larger and depending upon what is captured in the dump.
+
+
To prevent CPU overhead, only one dump is analyzed by the instance at a time. For example, if there are 10 instances and say the monitoring collected 5 dumps, all instances in parallel can analyze memory dumps. If there is 1 instance and 5 dumps are collected, the dump analysis will happen one after the other.
+
+
+
+
+
+
Watch a Demo
+
+
Watch this video to learn more about the feature and analyzing the dumps and memory analysis report generated by this tool.
+
+
+
+
+
+
What’s Next
+
+
Once you set the rule that best suits your app’s need, you can get ahead of your CPU issues, automatically mitigate CPU spikes, and save yourself from a dreadful 2:00am call.
+
+
Feel free to share your feedback or questions about Proactive CPU Monitoring by emailing diagnostics@microsoft.com or posting on UserVoice with “[Diag]” in the title.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
App Service Integration with Azure Monitor (Preview)
+
+
+
+
+
+
+
+
+ 4 minute read
+
+
+
+ • By Jason Freeberg and Yutang Lin
+
+ • November 1, 2019
+
+
+
+
+
+
+
+
+
We are happy to announce that App Service has new and improved integration with Azure Monitor (preview). You can now send your logs from Windows or Linux App Service to Storage Accounts, Event Hubs, or Log Analytics.
+
+
Increased visibility into your web apps
+
+
Azure Monitor is the central observability service to collect, analyze, and act on telemetry from your other Azure resources. You can use Azure Monitor to set up rule-based alerts, create dashboards, export to third-party services with Event Hubs, or archive logs and metrics for compliance needs.
+
+
App Service’s improved integration with Monitor enables new observability scenarios for development and operations teams. Developers can set up automatic emails with full stack traces when an exception is thrown. Operations teams can create dashboards to view the overall performance and stability of their applications. Compliance teams can monitor login attempts and file changes.
+
+
+
App Service integration with Azure Monitor is currently in preview.
+
+
+
Six brand new log types
+
+
App Service now outputs the following log types into Azure Monitor.
+
+
+
AppServiceConsoleLogs: Any logs or output written to the console (also known as standard output or standard error)
+
AppServiceHTTPLogs: Access logs from the web server (IIS for Windows web apps, Nginx for Linux)
+
AppServiceEnvironmentPlatformLogs: Logs for visibility into ASE operations such as scaling, configuration changes, and status
+
AppServiceAuditLogs: Logs for any user login via FTP or Kudu
+
AppServiceFileAuditLogs: Logs for file changes (add, delete, or update) via FTP or Kudu
+
AppServiceAppLogs: Any logs or exceptions written to the stack’s logging utility. Supports multi-line logs and exceptions
+
AppServiceIPSecLogs: Logs request made to the web app with IP info if there were IP access restriction rules set up
+
AppServicePlatformLogs: Logs from containers (ie. “docker run”)
+
AppServiceAntivirusScanAuditLogs: Logs from the anti-virus scan using Windows Defender (see blog for more information)
+
+
+
The table below shows the current availability for the log categories.
+
+
+
+
+
Log type
+
Windows
+
Windows Container
+
Linux
+
Linux Container
+
Description
+
+
+
+
+
AppServiceConsoleLogs
+
Java SE & Tomcat
+
Yes
+
Yes
+
Yes
+
Standard output and standard error
+
+
+
AppServiceHTTPLogs
+
Yes
+
Yes
+
Yes
+
Yes
+
Web server logs
+
+
+
AppServiceEnvironmentPlatformLogs
+
Yes
+
N/A
+
Yes
+
Yes
+
App Service Environment: scaling, configuration changes, and status logs
+
+
+
AppServiceAuditLogs
+
Yes
+
Yes
+
Yes
+
Yes
+
Login activity via FTP and Kudu
+
+
+
AppServiceFileAuditLogs
+
Yes
+
Yes
+
TBA
+
TBA
+
File changes made to the site content; only available for Premium tier and above
Create a Storage Account, Event Hub Namespace, or Log Analytics workspace to send your logs to
+
+
+
Create a Diagnostic setting
+
+
In the Azure portal, navigate to your App Service. Under Monitoring, select Diagnostic settings > Add diagnostic setting.
+
+
+
+
Enter the following information to create the Diagnostic setting.
+
+
+
+
Provide a name for the Diagnostic setting
+
+
Select your desired destination(s) for the logs. There are three possible destinations:
+
+
Storage Account: Archive your logs for auditing or backup
+
+
Needs to be in the same region as your web app
+
Configure the retention days for the storage account
+
+
+
Event Hub: Stream the logs to third-party logging and telemetry systems
+
Log Analytics Workspace: Analyze the logs with other monitoring data and leverage Azure Monitor features such as log queries and log alerts
+
+
+
+
Select the desired log categories to export. There are six log categories in addition to your metrics. The table below lists the log types with its description and availability per OS. The earlier section shows the availability of each log type
+
+
+
Select Save at the top. This will trigger App Service to begin sending your logs to the chosen destinations.
+
+
+
+
+
+
View logs in a Storage account
+
+
Open the Storage account you configured in the diagnostic setting. Then select Containers.
+
+
+
+
You will see a list of containers that have been automatically created for the logs categories you enabled.
+
+
+
+
Query logs in a Log Analytics Workspace
+
+
Open the Log Analytics Workspace you configured in the diagnostic setting. Select Logs, then select LogManagement. (You will see log categories that you have not enabled.)
+
+
+
+
The App Service log categories are all prefixed with AppService*. Select an App Service log category, this will copy the table name into the query editor. Select Run above the editor, this will execute a simple query to show all columns of the table.
+
+
+
+
See this article for more information on the Kusto Query Language.
+
+
Stream logs from Event Hubs
+
+
Event Hubs allows you to stream your logs and metrics to 3rd party logging and telemetry systems or to Power BI. To get started, please see the Event Hubs documentation.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 4 minute read
+
+
+
+ • By Jason Freeberg and Yutang Lin
+
+ • November 1, 2019
+
+
+
We are happy to announce that App Service has new and improved integration with Azure Monitor (preview). You can now send your logs from Windows or Linux App...
Secure your Custom Domains at no cost with App Service Managed Certificates (preview)
+
+
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Yutang Lin
+
+ • November 4, 2019
+
+
+
+
+
+
+
Free Transport Layer Security (TLS) for Azure App Service is now in preview! This has been one of the most highly requested features of the service since its inception. The feature is named App Service Managed Certificates and it will let you secure custom domains on your Windows and Linux apps at no additional charge. This provides developers a zero-cost option to work on their dev, test, and production sites. This feature is available for customers on an App Service Plan of Basic and above (free and shared tiers are not supported). The certificate issued will be a standard certificate and not a wildcard certificate. Each certificate will be valid for six months, and about 45 days before the certificate’s expiration date, App Service will renew the certificate.
+
+
App Service Managed Certificates VS App Service Certificates
+
+
The offering for App Service Certificates will still be available with the launch of App Service Managed Certificates as these two features have their differences and are better suited for different scenarios. Aside from the main difference of pricing, a major difference between the two is that you will not be able to export your App Service Managed Certificates as they are managed by the platform. If you’re planning to do a live site migration with TXT record, need support for apex domains, or need a wildcard certificate, then use App Service Certificates or bring your own certificate.
+
+
Getting started
+
+
To get started, add a CNAME record for the domain to your web app. In the Azure Portal, head to your web app and from the left navigation of your app, select TLS/SSL settings > Private Key Certificates (.pfx) > Create App Service Managed Certificate.
+
+
+
+
Once you’ve successfully created your App Service Managed certificate, you’ll see it on the list of Private Key Certificates.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Linux based Web Application Deployment made Easy on App Service
+
Fri 8th November
+
10:30am-11:15am
+
+
+
+
+
Members of our engineering team are also attending the event and would love to talk with any attendees, hear feedback and answer any questions you may have.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Yutang Lin
+
+ • November 4, 2019
+
+
+
Free Transport Layer Security (TLS) for Azure App Service is now in preview! This has been one of the most highly requested features of the service since its...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Eric Stenson
+
+ • November 13, 2019
+
+
+
+
+
+
+
Latest version updates to PHP
+
+
In January 2020, Azure App Service will update the PHP stacks to the latest available versions. For information on the changes in the new versions, please see the change logs on the PHP website.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Yutang Lin
+
+ • November 4, 2019
+
+
+
Free Transport Layer Security (TLS) for Azure App Service is now in preview! This has been one of the most highly requested features of the service since its...
+
+
+
+
+
+
+ 4 minute read
+
+
+
+ • By Jason Freeberg and Yutang Lin
+
+ • November 1, 2019
+
+
+
We are happy to announce that App Service has new and improved integration with Azure Monitor (preview). You can now send your logs from Windows or Linux App...
Based on customer requests we have added support for automating App Service Environment operations using the Azure CLI. With the 2.0.77 release you can create, list, update, and delete ASEs as well as create App Service Plans for an ASE. You can verify your installed version using az --version
+
+
The create command has a number of options to make provisioning easy. In the default configuration, the command will create the necessary NSG and UDR rules and associate them with the designated subnet.
+
+
az appservice ase create --resource-group myResourceGroup --name myAse --vnet-name myVNet --subnet myAseSubnet
+
+
+
You can configure the Virtual IP type, Frontend SKU and scale, and much more. The commands also support --no-wait if you want to continue scripting while a command is running in the background. Give it a try and let us know through the Azure CLI git repo, if you find any issues.
+
+
We also added commands for working with access restrictions. Access restrictions can be used to restrict access to specific IP addresses or to subnets using service endpoints. To control these restrictions with Azure CLI, you can now use the commands found in this group:
+
+
az webapp config access-restriction
+
+
+
Access restriction commands also allow you to control inheritance of restrictions for the scm site and control individual entries for the scm site. Access restriction commands are available in PowerShell as well:
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Based on customer requests we have added support for automating App Service Environment operations using the Azure CLI. With the 2.0.77 release you can creat...
App Service has GA’d App Service Environment (ASE) support for deploying into Availability Zones (AZ). Customers can choose to optionally deploy internal load balancer (ILB) ASEs into a specific AZ (Zone 1, 2 or 3) within an Azure region, and the resources used by that ILB ASE will either be pinned to the specified AZ, or deployed in a zone redundant manner.
+
+
An ILB ASE that is explicitly deployed into an AZ is considered a zonal resource because the ILB ASE is pinned to a specific zone. The following ILB ASE dependencies will be located (pinned) in the specified zone:
+
+
+
the internal load balancer IP address of the ASE
+
the compute resources used by the ASE to manage and run web applications
+
+
+
The remote file storage for web applications deployed on a zonal ILB ASE uses Zone Redundant Storage (ZRS), though this is an internal implementation detail of zonal ILB ASEs.
+
+
Note that unless the steps described in this article are followed, ILB ASEs are not automatically deployed in a zonal manner. Furthermore only ILB ASEs support availability zones - external facing ASEs (i.e. ASEs that have a public IP address for accepting website traffic) currently do not support zone pinning.
+
+
Zonal ILB ASEs can be created in any of the following regions:
+
+
+
Central US
+
East US
+
East US 2
+
East US 2 (EUAP)
+
France Central
+
Japan East
+
North Europe
+
West Europe
+
Southeast Asia
+
UK South
+
West US 2
+
+
+
Applications deployed on a zonal ILB ASE will continue to run and serve traffic on that ASE even if other zones in the same region suffer an outage. However it is possible that non-runtime behaviors, including application service plan scaling, as well as application creation, configuration and publishing may still be impacted in the event of an outage in other availability zones. The zone-pinned deployment of a zonal ILB ASE only ensures continued uptime for already deployed applications and the underlying network infrastructure and virtual machines running those applications.
+
+
Zonal ILB ASEs must be created using ARM templates. Once a zonal ILB ASE is created via an ARM template, it can be viewed and interacted with via the Azure Portal as well as CLI tooling. An ARM template is only needed for the initial creation of a zonal ILB ASE.
+
+
The only change needed in an ARM template to specify a zonal ILB ASE is the new zones property. The zones property should be set to a value of 1, 2 or 3 depending on the logical availability zone that the ILB ASE should be pinned to.
+
+
The ARM template snippet below shows the new zones property specifying that the ILB ASE should be pinned to zone 2.
In order to attain end-to-end zone resiliency for apps created on a zonal ILB ASE, customers need to deploy at least two zonal ILB ASEs - with each ILB ASE being pinned to a different zone. Customers must then create and publish copies of their application onto each of the zonal ILB ASEs.
+
+
Customers will also need to deploy a load balancing solution upstream of the zonal ILB ASEs so that traffic bound for an application is load-balanced and distributed across all of the zonal ILB ASEs. The recommended solution is to deploy a zone redundant Application Gateway upstream of the zonal ILB ASEs. More details on Application Gateway v2 and its zone redundant configuration is available here.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Stefan Schackow
+
+ • December 12, 2019
+
+
+
+ NOTE! As of March 2023, the content in this post may be outdated. For the latest information on Availability Zone support for App Service Environment, see...
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Stefan Schackow
+
+ • December 12, 2019
+
+
+
+ NOTE! As of March 2023, the content in this post may be outdated. For the latest information on Availability Zone support for App Service Environment, see...
Based on customer requests we have added support for automating App Service Environment operations using the Azure CLI. With the 2.0.77 release you can creat...
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Stefan Schackow
+
+ • December 12, 2019
+
+
+
+ NOTE! As of March 2023, the content in this post may be outdated. For the latest information on Availability Zone support for App Service Environment, see...
Based on customer requests we have added support for automating App Service Environment operations using the Azure CLI. With the 2.0.77 release you can creat...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Yutang Lin
+
+ • November 4, 2019
+
+
+
Free Transport Layer Security (TLS) for Azure App Service is now in preview! This has been one of the most highly requested features of the service since its...
+
+
+
+
+
+
+ 4 minute read
+
+
+
+ • By Jason Freeberg and Yutang Lin
+
+ • November 1, 2019
+
+
+
We are happy to announce that App Service has new and improved integration with Azure Monitor (preview). You can now send your logs from Windows or Linux App...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Andrew Westgarth
+
+ • August 29, 2019
+
+
+
This afternoon we released the seventh update to Azure App Service on Azure Stack. This release updates the resource provider and brings the following key c...
+
+
+
+
+
+
+ 4 minute read
+
+
+
+ • By Jason Freeberg
+
+ • August 10, 2019
+
+
+
Last week GitHub announced the preview of GitHub Actions with built-in CI/CD; watch the announcement here. These actions, defined in YAML files, allow you to...
Application downtime can be dreadful, especially when the app is handling mission-critical load. There could be countless causes for your app’s downtime rang...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Andrew Westgarth
+
+ • May 28, 2019
+
+
+
This afternoon we released the sixth update to Azure App Service on Azure Stack. This release updates the resource provider and brings the following key cap...
App Service plan defines the compute resource assigned to run your App Service. The pricing tier of your App Service plan determines the compute power and fe...
In a fast-paced development environment, sometimes it is difficult to keep track of all the changes made to your app… let alone pinpoint a change that caused...
App Service Certificates have been a very popular feature among App Service customers. However, our customers often get confused about the sync scenarios bet...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Jason Freeberg
+
+ • March 18, 2019
+
+
+
We will soon be rolling out a series of UX and ARM API changes that will alter the behavior of routing rules for testing in production. After May 22nd, you w...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Andrew Westgarth
+
+ • February 28, 2019
+
+
+
This morning we released the fifth update to Azure App Service on Azure Stack. This release updates the resource provider and brings the following key capab...
The Z-Ray PHP debugging feature will soon be discontinued in App Service. This shouldn’t affect the App Service service-level agreement (SLA) or the runtime ...
+
+
+
+
+
+App Service Environment (ASE) support for Availability Zones (AZ) is now in preview. Customers can deploy internal load balancer (ILB) ASEs into a spe...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • January 4, 2019
+
+
+
+
+
+
+
+
+Python 2.7 has been added to the public preview of Python on Azure App Service (Linux). With this recent addition developers can enjoy the productivit...
Azure App Service on Azure Stack Hub Update 8 Released
+
+
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Andrew Westgarth
+
+ • January 13, 2020
+
+
+
+
+
+
+
This afternoon we released the eighth update to Azure App Service on Azure Stack Hub. This release updates the resource provider and brings the following key capabilities and fixes:
+
+
+
Updates to App Service Tenant, Admin, Functions portals and Kudu tools. Consistent with Azure Stack Portal SDK version.
+
Updates to core service to improve reliability and error messaging enabling easier diagnosis of common issues.
+
Managed disk support for all new deployments – All new deployments of Azure App Service on Azure Stack Hub will make use of managed disks for all Virtual Machines and Virtual Machine Scale Sets. All existing deployments will continue to use unmanaged disks.
+
+
TLS 1.2 Enforced by Front End load Balancers
+
+
All other fixes and updates are detailed in the App Service on Azure Stack Update Eight Release Notes
+
+
+
The App Service on Azure Stack Hub Update 8 build number is 86.0.2.13
+
+
You can download the new installer and helper scripts:
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Andrew Westgarth
+
+ • January 13, 2020
+
+
+
This afternoon we released the eighth update to Azure App Service on Azure Stack Hub. This release updates the resource provider and brings the following key...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Eric Stenson
+
+ • January 25, 2020
+
+
+
+
+
+
+
Latest version updates to PHP
+
+
In February 2020, Azure App Service will update the Windows PHP stacks to the latest available versions. For information on the changes in the new versions, please see the change logs on the PHP website.
+
+
+
+
+
PHP Version
+
Change Log
+
+
+
+
+
7.2.27
+
https://www.php.net/ChangeLog-7.php#7.2.27
+
+
+
7.3.14
+
https://www.php.net/ChangeLog-7.php#7.3.14
+
+
+
+
+
Additionally, the Windows build of PHP 7.4 will be available with the February 2020 update.
+
+
NOTE: Both PHP versions 7.0 and 7.1 are past End-Of-Life, and are no longer receiving security updates from the community. These versions will be removed with the February 2020 update. All sites configured with either PHP 7.0 or 7.1 will have their configuration changed to PHP 7.3.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Jason Freeberg
+
+ • January 31, 2020
+
+
+
+
+
+
+
Wildfly is an open-source application runtime for Java applications, and the upstream project of JBoss EAP. We recently added a new Azure Sample that shows how to deploy Wildfly as a custom container onto Webapps for Containers.
+
+
The container image in the sample is already configured to support web-SSH and wardeploy. The image also uses the Azul Zulu Enterprise build of the OpenJDK, which receives free support on Azure. (This support does not extend to the Wildfly runtime.)
+
+
If your Java application only requires the servlet and JSP APIs, you can deploy your application onto Tomcat for App Service, which is supported on both Windows and Linux.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Jason Freeberg
+
+ • January 31, 2020
+
+
+
Wildfly is an open-source application runtime for Java applications, and the upstream project of JBoss EAP. We recently added a new Azure Sample that shows h...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Jason Freeberg
+
+ • January 31, 2020
+
+
+
Wildfly is an open-source application runtime for Java applications, and the upstream project of JBoss EAP. We recently added a new Azure Sample that shows h...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Andrew Westgarth
+
+ • January 13, 2020
+
+
+
This afternoon we released the eighth update to Azure App Service on Azure Stack Hub. This release updates the resource provider and brings the following key...
Announcing general availability of VNet Integration with Windows Web Apps
+
+
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Christina Compy
+
+ • February 27, 2020
+
+
+
+
+
+
+
App Service customers often need to access resources in their Azure Virtual Networks. We launched VNet Integration to address this issue in 2014, but our customers wanted to use networking features like Network Security Groups (NSGs), Route Tables (UDRs) and Service Endpoints. Today we are announcing Regional VNet Integration to solve these problems and improve usability.
Regional VNet Integration has been in preview for some time, but only supported calls to RFC1918 addresses (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) and service endpoints. The feature now supports outbound calls into the VNet on non-RFC1918 addresses as well. You can now use features like Network NSGs and UDRs against all of the outbound traffic from your web app. Regional VNet Integration will only work with VNets in the same Azure region as the Webapp.
+
+
By default, if you use regional VNet Integration, your app will still only route RFC1918 traffic into your VNet. By setting the app setting WEBSITE_VNET_ROUTE_ALL to 1, your app will then enable all of the outbound traffic from your app to be subject to NSGs and UDRs.
+
+
These new changes enable you to:
+
+
+
Access non-RFC1918 endpoints through your VNet
+
Secure all outbound traffic leaving your web app
+
Force tunnel all outbound traffic to a network appliance of your own choosing
+
+
+
+
+
Regional VNet integration is available in all public regions for Windows Webapps. Regional VNet Integration for Linux Webapps is currently in public preview. To use Regional VNet Integration, your Webapp must be in a Standard, Premium, PremiumV2 or Elastic Premium App Service plan. Regional VNet Integration only applies to outbound calls made by your Webapps, it does not enable private access to your apps. The older, gateway-required VNet Integration will continue to be supported. It integrates with VNets in other regions and Classic VNets.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Christina Compy
+
+ • February 27, 2020
+
+
+
App Service customers often need to access resources in their Azure Virtual Networks. We launched VNet Integration to address this issue in 2014, but our cus...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Christina Compy
+
+ • February 27, 2020
+
+
+
App Service customers often need to access resources in their Azure Virtual Networks. We launched VNet Integration to address this issue in 2014, but our cus...
The core Azure Functions features are grouped in the menu bar under the Functions (preview) heading:
+
+
+
+
Functions
+
+
Functions lets you list the individual functions within your Function App. From here you can also:
+
+
+
Add a new function.
+
Delete an existing function
+
Enable / disable individual functions
+
Search / filter through your list of functions
+
Drill into a specific function.
+
+
+
+
+
App Keys
+
+
App Keys lets you interact with the Function App Keys at the Host and System level. from here you can:
+
+
+
View the values for Host & System keys
+
Add / Remove Host & System keys
+
Renew values for Host & System keys
+
+
+
+
+
App Files
+
+
App Files lets you view and modify files like host.json that are scoped to the Function app and not individual functions.
+
+
+
+
Function Overview
+
+
Once you drill into a specific Function within your Function App there is a new overview page scoped to this specific function.
+
+
One of the added benefits of this overview is that folks can now deep link to this page.
+
+
The body of the overview page is currently empty for the public preview, but we are working on adding metrics that are scoped to the execution of this specific function.
+
+
+
+
Code + Test
+
+
Code + Test menu item lets you view and modify the code of this specific function.
+
+
You can browse to individual files:
+
+
+
+
Test your function and see the execution logs:
+
+
+
+
+
PRO TIP you can collapse the menu to maximize your code editor:
+
+
+
+
Integration
+
+
Integration menu item give you a graphical representation of your function. From here you can add / remove / edit all your Triggers, Inputs and Outputs bindings.
+
+
+
+
Function Keys
+
+
Function Keys provides similar functionality to Function App Keys, except it’s scoped to this specific function level.
+
+
+
+
Wrapping up
+
+
The new preview experience for Azure functions in the Azure Portal provides all the functionality of the existing UX but with better performance, accessibility and consistency with the rest of the Azure Portal. It also offers new functionality like RBAC support and improved code editor and integration UX.
+
+
If you want to see the UX in action you can watch a demo from @bktv99 during monthly February 2020 Azure Functions webcast:
+
+
+
+
If you find issues during the preview, you can file a bug.
+
+
You can also request features using our User Voice.
+
+
The Azure Functions team can also be reach through twitter: @AzureFunctions
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Byron Tardif
+
+ • March 16, 2020
+
+
+
+
+
+
+
We’re announcing that Tinfoil Security addon will no longer be available through App Service.
+
+
Over the next few months, we’ll start transitioning out this offer starting by disabling new sign ups at the end of April 2020.
+
+
Existing Tinfoil enabled apps can continue to use the existing addon until May 2020.
+
+
At any point during this transition period and through September 2020 you can migrate your account along with all of your scan settings and history to Tinfoil standalone service on tinfoilsecurity.com.
+
+
By going through with this migration, you will get access to some features that were not available in the Azure integration at no additional cost including:
+
+
+
More detailed scan reports such as an additional statistics page
+
Access to Tinfoil API for easier automation
+
The ability to add additional collaborators for read-only access to your Tinfoil scan results
+
+
+
Instructions for this migration will be sent out via email to existing customers, and will also appear on your Tinfoil Security addon dashboard.
+
+
Tinfoil is looking forward to continuing to help you keep your sites safe and secure!
+
+
If you have any question you can reach out to Tinfoil support .
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 2 minute read
+
+
+
+ • By Christina Compy
+
+ • March 16, 2020
+
+
+
+
+
+
+
We are happy to announce the public preview of Private Link for Azure App Service. This preview is available in limited regions for all PremiumV2 Windows and Linux web apps. It is also now available for Elastic Premium Functions plans. Private Link enables you to host your apps on an address in your Azure Virtual Network (VNet) rather than on a shared public address. By moving the endpoint for your app into your VNet you can:
+
+
+
Isolate your apps from the internet. Configuring a Private Endpoint with your app, you can securely host line-of-business applications and other intranet applications.
+
Prevent data exfiltration. Since the Private Endpoint only goes to one app, you don’t need to worry about data exfiltration situations.
+
+
+
+
+
The feature is currently available in all public regions.
+
+
Using Private Link or Service Endpoints
+
+
There is another networking feature called Service Endpoints which enables you to secure workloads to your VNet. There is a difference between Private Link and Service Endpoints. Service Endpoints enables you to secure your app to select set of subnets. It is used to secure the service to only being reachable from the select subnets. Private Link exposes your app on an address in your VNet and removes it from public access. This not only secures the app but can also be combined with Network Security Groups to secure your network.
+
+
Private Link vs App Service Environment
+
+
Having your app only accessible on a private address in your VNet is something that was previously only possible by using an ILB App Service Environment or an Application Gateway with an internal inbound address. The difference between using Private Link and an ILB ASE is that with an ILB ASE you have single tenant system that can host many apps behind one VNet address. With Private Link, your app runs in the public App service and you have one app behind one address. If you want to apply network security external to your application, then you still only get that with an ILB ASE. If you only need a private address in your VNet, then Private Link can give you that.
+
+
Putting your app in your VNet
+
+
Private Link provides a private address for inbound traffic only to your app. It does not enable your app to make outbound calls into your VNet. If you want to have all inbound and outbound in your VNet, then you need to use both Private Link and Regional VNet Integration. With Private Link you can secure the inbound and with VNet Integration you can secure the outbound.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 2 minute read
+
+
+
+ • By Christina Compy
+
+ • March 16, 2020
+
+
+
We are happy to announce the public preview of Private Link for Azure App Service. This preview is available in limited regions for all PremiumV2 Windows and...
The new experience is currently available for select Windows web apps. We are gradually rolling it out to all subscriptions in the coming weeks.
+
+
+
App Service Diagnostics is an intelligent and interactive experience to help you troubleshoot your app with no configuration required. When you run into issues with your app, App Service Diagnostics points out what’s wrong to guide you to the right information to more easily troubleshoot and resolve issues.
+
+
To make it easier for you to discover your application’s issues and helpful insights, we are launching a new experience in App Service Diagnostics.
+
+
Discover Issues Faster
+
+
The new experience allows you quickly discover issues that your application might be encountering by running health checks for each problem category upfront. Upon clicking on each problem category in the homepage, a series of checks are run, and the results are presented in the overview page.
+
+
+
+
+
+
The cards at the top of the overview page show the status of your app by performing pre-selected checks on your application’s backend telemetry. You can click on these cards to further investigate the issue.
+
+
If you already know the problem you want to drill down to, choose a relevant item in the left navigation where you will find more comprehensive checks on different topics.
+
+
+
+
Interactive Interface: Genie
+
+
When you are not sure where to begin, or you cannot find the information you are looking for, App Service Diagnostics’ interactive interface, Genie, can help guide you through diagnosing and solving problems of your app.
+
+
Click the Ask Genie button at the top of the page to start a chat with our interactive interface, Genie. Type in the issue you are experiencing, and Genie will automatically fetch relevant diagnostics available in App Service Diagnostics and return the results along with relevant documentation found on the web. Genie will share its observation on the issue and list out checks that have succeeded. You can click on More Info to see additional information for each check.
+
+
+
+
Command Bar
+
+
The new experience introduces a command bar control at the top where you will find buttons and controls you often interact with. Below controls are now available in every page with diagnostics.
+
+
+
+
+
Search: Search is now available in every page for you to quickly find and navigate to different diagnostics of your choice.
+
Ask Genie: Ask Genie button is available in every page for you to get analysis and documentation results tailored to your issue.
+
Refresh: Refresh button is available in every page for you to reload the diagnostics.
+
Feedback: Feedback button is available in every page for you to share feedback with the App Service Diagnostics Product team.
+
Time Filter: The new time filter now gives options to choose from predefined time range and custom time range using date picker and time picker to more easily filter the diagnostics to your desired time range. The time you select will be honored when you switch to another page. (Current limitations: The end time cannot be more than (current time - 15 minutes) due to limitations on data ingestion; The time range will reset to a 24-hour range once you go back to the homepage.)
Feel free to share your feedback or questions about App Service Diagnostics by emailing diagnostics@microsoft.com or posting on UserVoice with “[Diag]” in the title.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
PremiumV2 tier for older App Service deployments
+
+
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Christina Compy
+
+ • March 23, 2020
+
+
+
+
+
+
+
The PremiumV2 hardware tier is now available for older deployments of App Service where it was not previously available. A few years ago Azure App Service began to offer the PremiumV2 App Service plan. The benefits of this new tier were tied to the new hardware that was used for it. The same hardware is used for Free to Standard App Service plans. The new hardware required some changes to the system architecture and was not compatible with our older deployments. This unfortunately left many customers unable to upgrade their plans to PremiumV2. To solve this problem we developed a different way to attach the new PremiumV2 compute just for our older App Service deployments. This solution is now slowly rolling out and is adding the PremiumV2 option where it was previously unavailable.
+
+
Changing IP Addresses
+
+
When you scale to PremiumV2 while in a newer App Service deployment, your outbound addresses will change. To help customers that are sensitive to that, the app property called Additional Outbound IP Addresses contains all of the outbound addresses that your app can have. This field holds the outbound addresses your app can have while in Free through Standard as well as the addresses it would have while in PremiumV2.
+
+
With the new ability to offer PremiumV2 to older deployments of the Azure App Service, both your inbound and outbound IP addresses will change when you scale from Standard or lower to PremiumV2 and back. This means that if you have A records for your app, you will need to update them after you scale. Your app will still be accessible for at least five days from the original address as we relay the inbound traffic to the new address. When you go to scale your app from Standard or lower to PremiumV2, you will be told the new addresses for your app. The same will be true if you scale from PremiumV2 to a lower tier.
+
+
In order to select the PremiumV2, you need to acknowledge that your inbound and outbound addresses will change as you scale up your App Service plan.
+
+
Features gained and lost
+
+
There is a feature lost and another gained when you scale to PremiumV2 in these older App Service deployments.
+
+
+
Remote debugging: When you scale your app to PremiumV2, you will no longer be able to use remote debugging for your apps. If you scale your App Service plan to a lower tier, you will be able to use remote debug again.
+
Regional VNet Integration: When your app is in a PremiumV2 App Service plan, you will be able to use regional VNet Integration. When you scale back down to Standard tier or lower, you will lose the ability to use the feature. This is different from the newer App Service deployments where you can use regional VNet Integration from Standard and PremiumV2.
+
+
+
How to scale to PremiumV2
+
+
To scale up to PremiumV2, or just to see if you can scale up to PremiumV2, navigate to the Scale up (App Service plan) page in your app portal. If you can select any of the PremiumV2 options, you are able to scale to PremiumV2. The user experience will show you your new addresses and request your acknowledgement. If you opt out at this point and come back later, the addresses you would see would be the same for the same app.
+
+
+
+
Benefits of PremiumV2
+
+
It is important to highlight some of the other benefits of using a PremiumV2 App Service plan. Those benefits include:
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Christina Compy
+
+ • March 23, 2020
+
+
+
The PremiumV2 hardware tier is now available for older deployments of App Service where it was not previously available. A few years ago Azure App Service be...
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Christina Compy
+
+ • March 23, 2020
+
+
+
The PremiumV2 hardware tier is now available for older deployments of App Service where it was not previously available. A few years ago Azure App Service be...
+
+
+
+
+
+
+ 2 minute read
+
+
+
+ • By Christina Compy
+
+ • March 16, 2020
+
+
+
We are happy to announce the public preview of Private Link for Azure App Service. This preview is available in limited regions for all PremiumV2 Windows and...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Jason Freeberg
+
+ • April 14, 2020
+
+
+
+
+
+
+
Last year we shared an article that demonstrated how to deploy your application to App Service using GitHub Actions. We are excited to share that we have added GitHub Actions as a build provider in the Deployment Center. This means it is even easier for developers to set up a continuous delivery pipeline with GitHub Actions. Follow the video or instructions below to get started.
+
+
+
+
+
+
+
+
+
Getting started
+
+
+
+
First, create an Azure Webapp if you do not already have one. Follow one of these quick start guides.
+
+
+
Once the Webapp is created, open the Azure Portal and navigate to your Webapp. On the left side, click Deployment Center.
+
+
+
In the Deployment Center, Select GitHub. You will be prompted to authenticate with GitHub if this is your first time using the Deployment Center. Click Continue at the bottom.
+
+
+
+
+
On the next screen, choose GitHub Actions (Preview) as your build provider. Click Continue at the bottom.
+
+
+
+
+
On the following panel, use the dropdowns to select your repository and branch. The branch you choose will be deployed to the Webapp. Next, choose your language and version. When you are done, click Continue at the bottom.
+
+
+
+
+
The final screen shows a preview of the workflow file that will be committed into your repository under .github/workflows/. The workflow file will check out your branch, set your language and version, build your application, and deploy it to your Webapp. The workflow will run any time there is a commit on your specified branch.
+
+
+
+
Click Finish after reviewing your selections. The Portal will commit this to the repository, which will trigger the the workflow to run.
+
+
+
You will be forwarded to the Deployment Center Dashboard, where you can see a list of your recent deployments. You can use the buttons at the top to disconnect the dashboard.
+
+
+
+
+
+
Next steps
+
+
Congratulations! You now have an automated workflow that will build and deploy your app whenever new commits are pushed to the branch. As your application grows in complexity, so too can your workflows. There are plenty of other GitHub Actions to interact with the rest of your Azure Services as well.
+
+
As always, don’t forget to use UserVoice to suggest enhancements and vote for other suggestions.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Jason Freeberg
+
+ • April 14, 2020
+
+
+
Last year we shared an article that demonstrated how to deploy your application to App Service using GitHub Actions. We are excited to share that we have add...
Announcing .NET Core 3.1 LTS General Availability on App Service
+
+
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Jeff Martinez
+
+ • April 16, 2020
+
+
+
+
+
+
+
App Service is announcing GA of .NET Core 3.1 LTS on Linux & Windows today. If you are running .NET Core 3.0 applications, which had its end-of-life date on March 3rd, 2020 you can update to and create .NET Core 3.1 applications in the Azure App Service portal now. You can also view this map to see available regions running .NET Core 3.1 (Windows Only).
+
+
.NET Core 3.1 Long-term support
+
+
.NET Core 3.1 is the Long-term support release which is supported by Microsoft for three years from it’s release date (December 2019). The release focuses on minor improvements to .NET Core 3.0 and is the recommended way to prepare for .NET 5. More information about end of life dates and the new release can be found here.
+
+
Web App Development
+
+
When creating your Web App in the portal, you can choose .NET Core 3.1 LTS as your runtime stack with your choice of Linux or Windows for your operating system and deploy the application as you usually would.
+
+
If using Windows, you can check your version using the Console under Development Tools in your Web App blade. Running the dotnet --list-runtimes command will show your app including 3.1.
+
+
+
+
For Linux, you will run the same command dotnet --list-runtimes using the SSH tool under Development Tools in your Web App blade to view 3.1 running on your app.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Jeff Martinez
+
+ • April 16, 2020
+
+
+
App Service is announcing GA of .NET Core 3.1 LTS on Linux & Windows today. If you are running .NET Core 3.0 applications, which had its end-of-life dat...
App Services Diagnostics is a powerful tool that allows you to troubleshoot and mitigate issues within your application. The rich set of tools under the App Services Diagnostics carefully analyze all the telemetry emitted by App Services platform and suggests recommendations and troubleshooting steps that help in keeping your apps up and healthy. We are happy to announce that App Services Diagnostics has now deeper and better integration with Application Insights.
+
+
With the click of a button, you can connect an Application Insights resource with App Service diagnostics and bring together the best of both worlds, allowing you to troubleshoot and debug your applications more effectively. With the rich information about the platform and application telemetry combined together, you are presented with a streamlined view of the issues encountered and this enables you to identify problems easily. Should you open a support case with Microsoft and consent to share diagnostics, this will also enable Microsoft support engineers to review the information from both the platform and App Insights to help you swiftly resolve your case.
+
+
How to Enable Application Insights integration with App Service Diagnostics
+
+
Enabling Application insights integration is as easy as clicking a button in App Services Diagnostics. To enable this feature, visit the Diagnose and Solve blade for your app and choose Availability and Performance.
+
+
+
+
If Application Insights is not integrated for your app already, you will see an option to Enable Application Insights right from this view.
+
+
+
+
And if Application Insights is already enabled, then you will get an option to Connect it with App Services Diagnostics.
+
+
+
+
This connects the Application Insights resource for the app to App Service Diagnostics and allows you to view the exceptions and dependency information for the app within App Service Diagnostics. At the same time, any engineers engaged with you from Microsoft Support are enabled to leverage this information, provided you have given consent to share diagnostics information while creating a Support case.
+
+
+
+
What to expect after enabling Application Insights Integration
+
+
After enabling App Insights Integration feature, App Service Diagnostics starts leveraging App Insights telemetry and points you to exceptions and dependency slowness information in different views that you typically use to diagnose issues. Here is an example of the HTTP Server Errors view changes with Application Insights information.
+
+
+
+
And drilling down into the HTTP Server Errors view, you can find all details about the failed requests corresponding to the Exceptions in the same view. As you can see below, the table shows you the exception information, exception message, and the method in the code that was responsible for causing the exception. With the help of this integration, you can not only view the platform issues but also correlate any application issues that caused availability drops to the app.
+
+
+
+
What happens after you Integrate Application Insights with App Service Diagnostics
+
+
When you click Connect, an API key for your Application Insights is generated with read-only access to the telemetry and this API key along with the AppId for the Application Insights resource are stored as a hidden tag in ARM at the Azure App Service app level. At the App Insights Resource level, you may see something like this.
+
+
+
+
On the App Services side, you should see a new tag created at the app level with the name hidden-related:diagnostics/applicationInsightsSettings. You can view this tag by going to Azure Resource Explorer (https://resources.azure.com). The AppId is stored as is, but the API Key is encrypted using an internal key, so it is kept protected and not left as clear text.
+
+
Using this information, App Services Diagnostics can query the Application Insights resource and is able to merge both the experiences together. For Microsoft support and engineering teams, an equivalent internal tool is available and engineers and engineering teams assisting you on your incidents opened with Microsoft can access this information in similar unified troubleshooting experience.
+
+
How to disable App Insights Integration
+
+
We are working on a user interface that allows you to disable this feature easily under Diagnose and Solve problems. Until then, you can use a PowerShell Script example like this to simple disable the AppInsights integration feature.
So, what are you waiting for ? Integrate your application with Application Insights and get the unified experience that brings the best of both worlds. We just want to close by sharing some articles around Application Insights.
Feel free to share your feedback or questions about App Service Diagnostics by emailing diagnostics@microsoft.com or posting on UserVoice with “[Diag]” in the title.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
App Services Diagnostics is a powerful tool that allows you to troubleshoot and mitigate issues within your application. The rich set of tools under the App ...
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Jeff Martinez
+
+ • April 24, 2020
+
+
+
+
+
+
+
.NET 5 is the latest version to expand the capabilities of .NET by taking the best of Core, Framework, Xamarin, and Mono to create a unified platform for improving developer scenarios. .NET 5 is currently in preview and available for use in existing or new applications. Find more information on the release and how to upgrade an existing project here.
+
+
To get started with .NET 5 on App Service you can use one of two deployment methods. A Self-Contained deployment will allow you to deploy your app on machines that don’t have the runtime installed. You can also deploy your application with a more portable solution using a Container which will package your app and dependencies to run on App Service.
+
+
Local Setup
+
+
In order to setup .NET 5 in your application you need to first install the .NET 5.0 SDK. There are a number of preview versions of .NET 5 SDK’s available. We recommend using the latest SDK v5.0.0-rc.1, a feature complete Release Candidate SDK. If you’re on Windows using Visual Studio, you will also need to download the latest Visual Studio Preview version here.
+
+
Self-Contained Deployment
+
+
A Self-Contained deployment enables you to run .NET 5 because it doesn’t rely on the presence of shared components on the target system and all components including Core libraries and runtime are with the application and isolated from other apps. This way you have sole control of which version your application is running. Self-contained deployments are supported for both Windows and Linux apps. Note that with self-contained applications you should be aware of large deployments and managing updates as this will take up more hard drive space and cause you to be responsible for supplying updated versions of your app with new security patches.
+
+
+
+
To complete a self-contained deployment in .NET you would first create your project as usual then choose ASP.NET Core 5.0 for your apps version after selecting your application template. Select Create and modify your application as needed.
+
+
+
+
+
To publish, simply Right-Click your project and select publish. In the latest version of Visual Studio you can choose where your target publish is from a new menu.
+
+
+
+
+
Then select Azure App Service (Windows) or Azure App Service (Linux) depending on your preference on the following screen.
+
+
+
+
+
Next, choose a previously created App Service or create one from Visual Studio and fill out the required information as you normally would when publishing. When you reach the publish screen click the pencil icon to edit your Deployment Mode for publishing your application.
+
+
+
+
+
Next, Choose the Deployment Mode option and make sure Self-Contained is chosen.
+
+
+
+
+
+
After you select the Self-Contained option your Target Runtime will auto-populate to linux-x64 or win-x86 depending on your operating system selection. Save your new settings and click Publish on the preceding screen to publish to App Service and launch your application using .NET 5. More information on self-contained deployment can be found here.
+
+
Container Deployment
+
+
The other option for running your .NET 5 application is to deploy a Docker container to App Service on Linux or Windows (Premium SKU only). When deploying a container, you are packaging the application and its dependencies into a Linux or Windows based image to run on the App Service platform. This enables your application to be more portable in nature as it is not reliant on the host operating system and has the runtime and SDK added into the image.
+
+
Once you have your application setup for .NET 5, the steps to deploy a containerized application would be the same as any other container deployment. Right-click your project, Add -> Docker Support . Your .NET 5 project will have a new Dockerfile added with the .NET 5.0 base image and SDK ready for you to publish.
+
+
+
+
After you have added Docker support, you will publish it to a registry, and create your App Service as usual. See our documentation for more detail on deploying a containerized application.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Jeff Martinez
+
+ • April 24, 2020
+
+
+
.NET 5 is the latest version to expand the capabilities of .NET by taking the best of Core, Framework, Xamarin, and Mono to create a unified platform for imp...
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Jeff Martinez
+
+ • April 24, 2020
+
+
+
.NET 5 is the latest version to expand the capabilities of .NET by taking the best of Core, Framework, Xamarin, and Mono to create a unified platform for imp...
App Services Diagnostics is a powerful tool that allows you to troubleshoot and mitigate issues within your application. The rich set of tools under the App ...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Jeff Martinez
+
+ • April 16, 2020
+
+
+
App Service is announcing GA of .NET Core 3.1 LTS on Linux & Windows today. If you are running .NET Core 3.0 applications, which had its end-of-life dat...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Jason Freeberg
+
+ • April 14, 2020
+
+
+
Last year we shared an article that demonstrated how to deploy your application to App Service using GitHub Actions. We are excited to share that we have add...
Reduce costs and increase agility with App Service and API Management
+
+
+
+
+
+
+
+
+ 2 minute read
+
+
+
+ • By Mike Budzynski, Jason Freeberg
+
+ • May 1, 2020
+
+
+
+
+
+
+
+
+
In times of rapid change, developers and IT decision-makers must quickly adjust to a drastically evolving landscape. Successful organizations use managed cloud services to reduce operating costs by increasing developer efficiency, and seize new business opportunities by accelerating delivery of innovation.
+
+
+
Try this tutorial to get started with App Service, GitHub Actions, and API Management.
+
+
+
Host applications with App Service
+
+
App Service is a proven managed service for hosting your web apps and mobile backends with deployment APIs, networking integration, and built-in monitoring.
+
+
Use your preferred technology stack to increase the speed-to-market. Build your applications with .NET, .NET Core, Java, Node.js, Python or PHP. Deploy them as code or Docker containers and integrate with API management in Visual Studio Code or the Azure Portal.
+
+
Simplify operations with GitHub Actions. Use GitHub Actions to automate the testing and deployment of your applications onto App Service’s global infrastructure. The Azure Portal makes it easy to get started with a guided developer experience. Then use deployment slots to coordinate your QA, staging, and production deployments.
+
+
Isolate and secure applications with enterprise-grade global datacenter network. Once your applications are deployed, isolate and secure them in a Virtual Network or in an App Service Environment. Get more secure, high-speed connections to resources on premises or in the cloud and maintain fine-grained control over network traffic.
+
+
Manage, protect, and publish APIs with API Management
+
+
API Management lets you manage and protect APIs throughout their lifecycle and publish them to consumers.
+
+
Increase the speed to market with one-click API import. Design the API from scratch or generate it automatically from an API definition file (OpenAPI, WSDL, WADL) or an Azure service (App Service, Functions, Logic Apps).
+
+
Simplify management of APIs. API Management abstracts the APIs from their implementation, allowing you to transform and iterate on your backend services without impacting API consumers. As the backends evolve and API traffic increases, create new API revisions and versions and monitor the usage with Azure Application Insights, Azure Monitor, or custom solutions.
+
+
Protect and secure your APIs from abusive users with policies. Apply the rate-limit-by-key policy to throttle API calls based on any key – for example, IP address or user credentials. Set long-term quotas with the quota-by-key policy to limit the allowed number of calls or data transfer. Secure your APIs with built-in API subscription keys mechanism, client certificates, or JWT tokens. The most convenient way to author policies is to use the Azure portal or the official Visual Studio Code extension with the autocomplete feature. Examples of more advanced policies are located in this GitHub repository.
+
+
Seize new business opportunities by publishing your APIs in the developer portal. Azure API Management comes with a built-in developer portal. It is an automatically generated, fully customizable website where visitors can discover your APIs, learn how to use them, try them out interactively, and sign up to acquire access. By publishing your APIs, you can scale your operations and build an ecosystem around your services. You may also monetize them to create new revenue streams.
+
+
Try the sample
+
+
To get started with App Service and API Management, clone this sample application and follow the instructions. By the end of the tutorial, you will have set up continuous delivery with GitHub Actions and exposed your backend API with API Management.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 2 minute read
+
+
+
+ • By Mike Budzynski, Jason Freeberg
+
+ • May 1, 2020
+
+
+
In times of rapid change, developers and IT decision-makers must quickly adjust to a drastically evolving landscape. Successful organizations use managed clo...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Eric Stenson
+
+ • May 4, 2020
+
+
+
+
+
+
+
Latest version updates to PHP
+
+
In June/July 2020, Azure App Service will update the PHP stacks to the latest available versions. For information on the changes in the new versions, please see the change logs on the PHP website.
+
+
+
+
+
PHP Version
+
Change Log
+
+
+
+
+
5.6.401
+
http://www.php.net/ChangeLog-5.php#5.6.40 + security fixes from https://github.com/microsoft/php-src/commits/PHP-5.6-security-backports + OpenSSL 1.1
+
+
+
7.2.22
+
http://www.php.net/ChangeLog-7.php#7.2.30
+
+
+
7.3.9
+
http://www.php.net/ChangeLog-7.php#7.3.17
+
+
+
7.4.5
+
http://www.php.net/ChangeLog-7.php#7.4.5
+
+
+
+
+
+
1 - PHP v5.6 is past End-Of-Life, and is no longer receiving security updates from the community. However, to ensure our customers have the most secure PHP builds available, we have arranged to temporarily have relevant security fixes from supported versions of PHP backported to PHP v5.6.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Azure App Service and Azure Functions on Azure Stack Hub 2020 Q2 Released
+
+
+
+
+
+
+
+
+ 2 minute read
+
+
+
+ • By Andrew Westgarth
+
+ • May 6, 2020
+
+
+
+
+
+
+
We have released the 2020 Q2 update to Azure App Service on Azure Stack Hub. This release updates the resource provider and brings the following key capabilities and fixes:
+
+
+
Updates to App Service Tenant, Admin, Functions portals and Kudu tools. Consistent with Azure Stack Portal SDK version.
+
Updates Azure Functions runtime to v1.0.13021.
+
Updates to core service to improve reliability and error messaging enabling easier diagnosis of common issues.
+
Updates to the following application frameworks and tools:
+
+
ASP.NET Framework 4.7.2
+
ASP.NET Core 3.1.3
+
ASP.NET Core Module v2 13.1.19331.0
+
PHP 7.4.2
+
Updated Kudu to 86.20224.4450
+
NodeJS
+
+
8.17.0
+
10.19.0
+
12.13.0
+
12.15.0
+
+
+
NPM
+
+
5.6.0
+
6.1.0
+
6.12.0
+
6.13.4
+
+
+
+
+
Updates to underlying operating system of all roles:
+
Cumulative Updates for Windows Server are now applied to Controller roles as part of deployment and upgrade
+
+
+
Updated default Virtual Machine and Scale set skus for new deployments:
+To maintain consistency with our public cloud service, new deployments of Azure App Service on Azure Stack Hub will use the following SKUs for the underlying machines and scale sets used to operate the resource provider
+
+
+
+
+
Role
+
Minimum SKU
+
+
+
+
+
Controller
+
Standard_A4_v2 - (4 cores, 8192 MB)
+
+
+
Management
+
Standard_D3_v2 - (4 cores, 14336 MB)
+
+
+
Publisher
+
Standard_A2_v2 - (2 cores, 4096 MB)
+
+
+
FrontEnd
+
Standard_A4_v2 - (4 cores, 8192 MB)
+
+
+
Shared Worker
+
Standard_A4_v2 - (4 cores, 8192 MB)
+
+
+
Small dedicated worker
+
Standard_A1_v2 - (1 core, 2048 MB)
+
+
+
Medium dedicated worker
+
Standard_A2_v2 - (2 cores, 4096 MB)
+
+
+
Large dedicated worker
+
Standard_A4_v2 - (4 cores, 8192 MB)
+
+
+
+
+
+
+
For ASDK deployments, you can scale the instances down to lower SKUs to reduce the core and memory commit but you will experience a performance degradation.
+
+
+
All other fixes and updates are detailed in the App Service on Azure Stack Hub 2020 Q2 Release Notes
+
+
+
The App Service on Azure Stack Hub Update 8 build number is 87.0.2.10
+
+
Please review the release notes and all Known issues prior to updating your installation of Azure App Service on Azure Stack Hub.
+
+
Documentation Updates
+
+
All of the documentation for Azure App Service and Azure Functions on Azure Stack Hub has been reviewed and edited to support this release, to address feedback from customers and to improve the quality of the documentation to support cloud operators. In addition the articles covering Azure App Service and Azure Functions on Azure Stack Hub have been reclassified under the table of contents to better classify the documentation and to maintain consistency with other resource providers on Azure Stack Hub:
+
+
+
+
+
You can download the new installer and helper scripts:
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 2 minute read
+
+
+
+ • By Andrew Westgarth
+
+ • May 6, 2020
+
+
+
We have released the 2020 Q2 update to Azure App Service on Azure Stack Hub. This release updates the resource provider and brings the following key capabili...
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Jason Freeberg, Yutang Lin
+
+ • May 11, 2020
+
+
+
+
+
+
+
+
+
We are happy to announce the Public Preview of App Service’s integration with Azure Event Grid. Event Grid is a publish/subscribe messaging service that allows you to easily build event-based architectures. Event Grid is heavily integrated into Azure services, allowing you to react to events coming from your resources.
App Service now emits 13 events to Event Grid. These events span configuration changes, slot swaps, restarts, backups, and more. If you have an idea for an event type that you would like to see added, let us know on UserVoice.
This quickstart will walk through how to get started with a simple event handler, but we are excited to see what you can build with the newly integrated events from App Service.
+
+
Create a Function with an Event Grid trigger
+
+
First, create a new Azure Function with an Event Grid trigger. If you do not already have a Function App in your subscription, follow these instructions to create a new Function App. Once you have your Function App, browse to it in the Portal.
+
+
+
+
In the list of Functions, select the “+” to add a new Function.
+
+
+
In the following screen, filter the triggers by searching for “event grid”. Select “Azure Event Grid trigger” and enter a name for the Function. Finally, click “Create”.
+
+
+
+
+
+
Add the Function as an endpoint
+
+
Now that the Event Grid triggered Function is created, we will add it as a handler for events from our Azure Webapp. Navigate to one of your Azure Webapps in the Portal.
+
+
+
+
Select the “Events” button in the toolbar on the left side of the blade.
+
+
+
+
+
This will open a new blade where you can register event handlers. If you have used Event Grid before with other Azure services, this blade will look familiar.
+
+
+
+
+
Click “+ Event Subscription” at the top of the blade. In the following screen, enter a name for the event subscription and select “Azure Function” as the Endpoint Type. Next, click “Select an endpoint” and find your Event Grid triggered Function using the filters in the context menu. Finally, click “Create”.
+
+
+
+
+
+
Summary
+
+
You have now set up an Azure Function as an event handler for your Event Grid subscription. Whenever events are emitted from your web app, this Function will execute. Click back to the “Events” tab to see a timeline of your events.
+
+
+
+
Next steps
+
+
This quickstart covered only a sliver of Event Grid’s capabilities. You can also use Logic Apps, Hybrid Connections, and web hooks as your event handlers. You can use these handlers to send yourself an email if a backup fails, send information to an on-premises resource, and much more!
+
+
If you have suggestions for events that App Service should emit, let us know on UserVoice.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Jason Freeberg, Yutang Lin
+
+ • May 11, 2020
+
+
+
We are happy to announce the Public Preview of App Service’s integration with Azure Event Grid. Event Grid is a publish/subscribe messaging service that allo...
Modern-day data centers are extremely complex and have many moving parts. VMs can restart or move, systems are upgraded, and file servers are scaled up and down. All these events are to be expected in a cloud environment. However, you can make your cloud application resilient to these events by following best practices. This document outlines 13 crucial steps that you can take to ensure that your app is cloud ready. By taking these steps, you will ensure that any events in the data center will have negligible effects on your app and that your app will be more resilient and future proof.
+
+
As mentioned above, your instances are expected to and will restart. They will be upgraded and will sometimes suffer from file server movements. However you can make your app resilient to all these incidents. In order to guarantee the maximum uptime for your app, please ensure that you follow all practices.
+
+
Use Multiple Instances
+
+
Running your app on only one VM instance is an immediate single point-of-failure. By ensuring that you have multiple instances allocated to your app, if something goes wrong with any particular instance, your app will still be able to respond to requests going to the other instances. Keep in mind that your app code should be able to handle multiple instances without synchronization issues when reading from or writing to data sources. You can allocate multiple instances to your app using the “Scale out (App Service Plan)” blade:
+
+
+
+
To avoid a single point-of-failure, run your app with at least 2-3 instances. This is especially important if your app takes considerable time to start (known as cold start). Running more than one instance ensures that your application is available when App Service moves or upgrades the underlying VM instances. You can also configure rules to automatically scale out based on predefined rules such as:
App Service has many settings for developers to configure the web app to their use case. Always-On keeps your VM instances alive even when no requests have been received in the last 20 minutes. By default, Always-On is disabled; enabling Always-On will limit application cold starts.
+
+
ARR Affinity creates sticky sessions so that clients will connect to the same app instance on subsequent requests. However, ARR Affinity can cause unequal distribution of requests between your instances and possibly overload an instance. Disabling ARR Affinity assumes that your application is either stateless, or the session state is stored on a remote service such as a cache or database.
+
+
Lastly, please set the Platform setting from 32 Bit to 64 Bit. The maximum available amount of memory for a 32-bit process (even on a 64-bit operating system) is 2 GB. By default, the worker process is set to 32-bit in App Service (for compatibility with legacy web applications). Consider switching to 64-bit processes so you can take advantage of the additional memory available in your Web Worker role.
+
+
For production apps that are aiming to be robust, it is recommended to set Always on to On, ARR Affinity to Off and Platform to 64 Bit.
+
+
You can change these settings in the configurations section of the Azure Portal, under the General Settings tab:
App Service offers a variety of hardware tiers (also known as SKUs) to suit different customer needs. When creating a new App Service Plan, you have an option to select a different hardware tier for your plan:
+
+
+
+
If your App Service Plan is used for production, please ensure that your App Service Plan is running on one of the recommended “production” pricing tiers. Moreover, if your application is resource intensive, make sure to select the appropriate pricing tier within the recommended ones according to the need of your app. For example, if your application consumes a lot of CPU cycles, running on an S1 pricing tier will not be ideal as it could potentially cause high CPU that would cause downtime or slowness on your app.
Before deploying your new code to production, you can leverage the Deployment Slots feature in App Services to test your changes. Deployment slots are live apps with their own host names. App content and configurations elements can be swapped between two deployment slots, including the production slot.
+
+
Deploying your application to a non-production slot has the following benefits:
+
+
+
You can validate app changes in a staging environment before swapping it into the production slot.
+
Deploying an app to a slot first and swapping it into production makes sure that all instances of the staging slot are warmed up before swapping into production. This eliminates downtime when you deploy your app. The traffic redirection is seamless, and no requests are dropped because of swap operations. You can automate this entire workflow by configuring auto swap.
+
After a swap, the slot with previously staged app now has the previous production app. If the changes swapped into the production slot aren’t as you expect, you can perform the same swap immediately to get your “last known good site” back.
+
+
+
+
+
+
Please note that Deployment Slots are only available for Standard, Premium, or Isolated App Service plan tiers
+
+
+
We highly recommend using Swap with Preview. Swap with Preview allows you to test the app in your staging slots against your production settings and also warm up the app. After doing your tests and warming up all the necessary paths, you can then complete the swap and the app will start receiving production traffic without restarting. This has a high impact on your app’s availability & performance.
App Service allows you to specify a health check path on your apps. The platform pings this path to determine if your application is healthy and responding to requests. When your site is scaled out to multiple instances, App Service will exclude any unhealthy instance(s) from serving requests, improving your overall availability. Your app’s health check path should poll the critical components of your application, such as your database, cache, or messaging service. This ensures that the status returned by the health check path is an accurate picture of the overall health of your application.
+
+
+
+
Go to Monitoring > Health Check on the Web App blade for Azure portal:
+
+
+
+
+
Set the value of the path that our service will ping.
+
+
+
Hit save to save the configuration.
+
+
+
+
+
Please note that the Health Check feature works only when you have two or more instances, which is a very strong recommendation. For a single instance web app, the traffic is never blocked even if that single instance is encountering issues.
Application Initialization ensures that your app instances have fully started before they are added to they start serving requests. Application Initialization is used during site restarts, auto scaling, and manual scaling. This is a critical feature where hitting the site’s root path is not sufficient to start the application. For this purpose a warm-up path must be created on the app which should be unauthenticated and App Init should be configured to use this url path.
+
+
Try to make sure that the method implemented by the warm-up url takes care of touching the functions of all important routes and it returns a response only when warm-up is complete. The site will be put into production only when it returns a response (success or failure) and app initialization will assume “everything is fine with the app”. App Initialization can be configured for your app within web.config file.
When this feature is enabled, the site content is read, written from the local virtual machine instance instead of fetching from Azure storage (where site content is stored). This will reduce the number of recycles required for the app. It can be enabled through Azure portal from the “General -> Application settings”. On this page under the App settings section add WEBSITE_LOCAL_CACHE_OPTION as key and "Always" as value. Also add the WEBSITE_LOCAL_CACHE_SIZEINMB with a desired local cache size value up to 2000MB (if not provided, it defaults to 300 MB). It helps to provide the cache size specially when the site contents are more than 300 MB. Ensure that site contents are less than 2000MB for this feature to work. Also it is a good practice to keep it as a slot setting so that it does not get removed with a swap.
+The most important thing to keep in mind here is that app should not be doing local disk writes for state persistence of its data/transactions.
+External storage like storage containers, db or cosmosDB should be used for storage purposes.
+
+
+
Please note that the behavior of Local Cache depends on the language and CMS you are using. For best results, we recommend using it for .net and .netcore apps as long as local writes are not being done by the app.
Sometimes your application might experience unexpected behaviors that could be resolved by a simple restart. The Auto-Heal features allows you to do exactly that! It allows you to define the ‘condition’ that would trigger Auto-Heal and the ‘action’ that Auto-Heal will initiate when the condition is met.
+
+
You can create an Auto-Heal mitigation rule by going to “Diagnose and Solve problems” section -> “Diagnostic Tools” tile and then “Auto-Heal” under Proactive Tools section.
+
+
+
+
Below are example filter values to set up, however if some other value of error code and frequency suits your application, please modify accordingly:
+
+
+
+
+
Condition
+
Value
+
+
+
+
+
Request Count
+
70
+
+
+
Status Code
+
500
+
+
+
Sub-status code
+
0
+
+
+
Win32-status code
+
0
+
+
+
Frequency in seconds
+
60
+
+
+
+
+
Once the condition above is met, we recommend configuring an action to:
+
+
+
Recycle Process
+
+
+
and add an ‘Override when Action Executes’:
+
+
+
Startup Time for process before auto heal executes: 3600 seconds (1 hour)
Running too many Apps in an App Service Plan can have a negative impact performance. All the apps running on the App Service Plan can be seen on “Apps” under “Settings” section in your App Service Plan on Azure portal.
+
+
You can verify the App Service Plan density with the App Service Plan Density Check. Learn more here:
Ensure that the disk space used by www folder should be less than 1GB. It is a very healthy practice in reducing downtime during app restarts and hence improve the application performance. File system usage can be tracked from “App Service Plan -> Quotas” section in Azure portal.
+
+
+
+
Enable Application Insights
+
+
Application Insights offers a suite of features that empower you to troubleshoot incidents that happen on your app. You can use it to debug code errors, diagnose performance degradations caused by dependencies and more.
+
+
One of the powerful features of Application Insights is the App Insights Profiler. Enabling Application Insights Profiler provides you with performance traces for your applications that are running in production in Azure. Profiler captures the data automatically at scale without negatively affecting your users. Profiler helps you identify the “hot” code paths that take the longest when handling a web request. Profiler works with .NET applications. To enable it, go to your Application Insights in Azure portal. Click on Performance under Investigate.
+
+
+
+
In the Performance pane click on “Configure Profiler”
+
+
+
+
+
In the pane that opens after that, click on “Profile Now” to start profiling.
+
+
+
+
+
When Profiler is running, it profiles randomly about once per hour and for a duration of two minutes. If your application is handling a steady stream of requests, Profiler uploads traces every hour.
+To view traces, in the Performance pane, select Take Actions, and then select the Profiler Traces button.
+
+
+
+
+
App Insights also allows you to track dependencies in your application. You can leverage this feature to troubleshoot slow requests. To automatically track dependencies from .NET console apps, install the Nuget package Microsoft.ApplicationInsights.DependencyCollector, and initialize DependencyTrackingTelemetryModule as follows:
Each request event is associated with the dependency calls, exceptions, and other events that are tracked while your app is processing the request. So if some requests are doing badly, you can find out whether it’s because of slow responses from a dependency. You can see a waterfall view of the requests in the performance blade as well under the “Dependencies” tab:
You can deploy Azure Front Door or Azure Traffic Manager to intercept traffic before they hit your site. They help in routing & distributing traffic between your instances/regions. In the event that a catastrophic incident happens in one of the Azure Datacenters, you can still guarantee that your app will run and serve requests by investing in one of them.
+
+There are additional benefits to using Front Door or Traffic Manager, such as routing incoming requests based the customers’ geography to provide the shortest respond time to customers and distribute the load among your instances in order not to overload one of them with requests.
Finally, you can check the progress you’ve accomplished in making your app resilient by leverage the “Risk Assessments” section available in App Service Diagnostics here:
+
+
+
+
You’ll be presented by 2 options:
+
+
+
Best Practices for Availability & Performance
+
Best Practices for Optimal Configuration
+
+
+
We recommend that you follow all the best practices listed in those detectors and get them all to green!
+
+
+
+
Finally, we also recommend that you take a look at the Cloud Design Patterns document to minimize the application start time and follow more resiliency recommendations.
+
+
Feel free to post any questions about App Resiliency on the MSDN Forum.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Modern-day data centers are extremely complex and have many moving parts. VMs can restart or move, systems are upgraded, and file servers are scaled up and d...
+
+
+
+
+
+
+ 2 minute read
+
+
+
+ • By Jason Freeberg
+
+ • May 19, 2020
+
+
+
+
+
+
+
+
+
This year, Microsoft Build is entirely online. Live and pre-recorded sessions are available for anyone to view. This article is a recap of the sessions from the App Service team, along with links to more information.
+
+
Building and Managing .NET Core with App Service
+
+
Building web apps with .NET Core? Check out the latest from the App Service team including how to build a continuous delivery pipeline using GitHub Actions, how to use Event Grid to subscribe and act on deployment events and how to monitor your production apps with Health Checks.
GitHub Actions is a flexible automation framework that allows developers to (among other things) continuously deploy their applications to App Service.
Event Grid is a high performance publish/subscribe messaging system. App Service now emits events that can be handled with Functions, Logic Apps, and more.
See how Azure is making it easy to quickly get your application running on App Service. We’ll show you how to use Migration Assistant for moving IIS sites and Linux containers to the cloud.
Many of you attended our “Ask the Experts” live session and sent us your questions. Here are some common questions you asked, along with their answers.
+
+
+
Can you use LetsEncrypt certificates with Azure App Services? You’re still able to use Let’s Encrypt certs with App Service, however there is no official support when it comes to integrating it with auto-renew. We have App Service Managed Certificates, which is our free certificate offering that supports auto-renew. This feature is currently in preview and only currently supports CNAME Records. Documentation.
+
What is the status for App Service Managed Certificates supporting apex/naked domains? This is the next milestone for this feature that we are currently working on. We don’t have an ETA to provide as of now.
+
Is it a good strategy to use deployment slots to define environments (eg. myapp, myapp/uat, myapp/qa) or would it be better to have different resources for each environment? Would it affect the performance of the main prod “myapp” service? You can certainly use slots to stage your test, QA, and other environments. This works especially well if your team uses the Gitflow branching strategy, as each branch can be continuously deployed to a staging slot. If you are worried about the extra slots consuming too many resources, you can actually host the production slot on it’s own, independent App Service Plan.
+
What is the status for the different logs with the Azure Monitor integration? We will be releasing AppServiceAppLogs for Windows soon – estimating the next two/three months. We don’t have an ETA for the other logs as of now.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 2 minute read
+
+
+
+ • By Jason Freeberg
+
+ • May 19, 2020
+
+
+
This year, Microsoft Build is entirely online. Live and pre-recorded sessions are available for anyone to view. This article is a recap of the sessions from ...
+
+
+
+
+
+
+ 2 minute read
+
+
+
+ • By Jason Freeberg
+
+ • May 19, 2020
+
+
+
This year, Microsoft Build is entirely online. Live and pre-recorded sessions are available for anyone to view. This article is a recap of the sessions from ...
Modern-day data centers are extremely complex and have many moving parts. VMs can restart or move, systems are upgraded, and file servers are scaled up and d...
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Jason Freeberg, Yutang Lin
+
+ • May 11, 2020
+
+
+
We are happy to announce the Public Preview of App Service’s integration with Azure Event Grid. Event Grid is a publish/subscribe messaging service that allo...
+
+
+
+
+
+
+ 2 minute read
+
+
+
+ • By Andrew Westgarth
+
+ • May 6, 2020
+
+
+
We have released the 2020 Q2 update to Azure App Service on Azure Stack Hub. This release updates the resource provider and brings the following key capabili...
+
+
+
+
+
+
+ 2 minute read
+
+
+
+ • By Mike Budzynski, Jason Freeberg
+
+ • May 1, 2020
+
+
+
In times of rapid change, developers and IT decision-makers must quickly adjust to a drastically evolving landscape. Successful organizations use managed clo...
Continuous Deployment for Windows Containers with GitHub Actions
+
+
+
+
+
+
+
+
+ 11 minute read
+
+
+
+ • By Jeff Martinez
+
+ • June 9, 2020
+
+
+
+
+
+
+
+
+
Github Actions enables you to easily automate any part of your development workflow. GitHub Actions are defined as YAML files in the .github/workflows directory of your repository. The workflows are triggered by an event, such as a push to a specific branch, a commit or comment on a pull request, or on a CRON schedule.
+
+
In this article, we will use GitHub Actions for Azure to deploy a Windows Container application to App Service. The sample application is already configured to be used in a Windows Container, pushed to a registry, and deployed to App Service. Of course, you can use this guide to add the correct deployment tasks to work with your own applications.
+
+
Sample Application
+
+
+
If you would like to get started with your own application, you can skip to the next section.
+
+
+
The sample application is a simple task-tracking app built with .NET Framework using Azure SQL for storage. The project has a workflow file, main.yaml, that is set up for continuous deployment. You have your choice of using Azure Container Registry (ACR) or Docker Hub for your registry needs (the difference in syntax will be explained below).
+
+
Find the full repository samples for .NET Framework and .NET Core at these highlighted links.
+
+
Create Resources
+
+
Create the following resources. You will need information from each resource that will be used in the file and stored in your secrets. Create your choice of registry (Azure Container Registry or Docker Hub) first since you will need information from there before you can create your App Service.
+
+
+
Azure Container Registry OR Docker Hub repository
+
App Service (Web App for Container)
+
.NET Framework application with supporting dockerfile in a GitHub repository
+
Azure SQL Database (Optional)
+
+
+
Create a Service Principal (optional) or use Publish Profile
+
+
In this step you have the choice of using a Service Principal or Publish Profile for authentication. If you would like to use your publish profile credentials instead, please skip this section and see Deploy to Azure App Service to see how. To use a Service Principal, please continue here:
+
+
Our workflow will use a Service Principal to authenticate with Azure when deploying the container to App Service. A service principal is an Active Directory Identity created for use with automation scenarios, such as GitHub Actions.
+
+
+
+
Run the following command in Azure CLI in powershell to get the credentials needed to run the login action. The output of this command will be a collection of key value pairs that you’ll need to add to your GitHub secrets.
+
+
az ad sp create-for-rbac --name"<appservice-name>"--role contributor \
+ --scopes /subscriptions/{subscription-id}/resourceGroups/{resource-group}\
+ --sdk-auth
+
+
+
+
Copy the output into your GitHub secrets to use as your AZURE_CREDENTIALS secret.
Since we are using sensitive information that you don’t want others to access, we will use GitHub secrets to protect our information. Create a secret by following the directions here. Add the github secrets variables below with your own secrets appropriate from each resource.
+
+
+
APP_NAME: web-app-name
+
AZURE_CREDENTIALS: the JSON output of the az ad sp create-for-rbac command
+
PUBLISH_PROFILE: content of your publish profile (optional)
+
IMAGE_NAME: name-of-image
+
CONTAINER_REGISTRY_USERNAME: Your container registry username
+
CONTAINER_REGISTRY_PASSWORD: Your container registry password
+
CONTAINER_NAME: The hostname of the container registry (ACR only)
The samples below explain the associated Dockerfiles for the .NET Framework and .NET Core sample applications linked above. If creating your own application, use the appropriate Dockerfile below and replace the directory paths to match your application.
+
+
.NET Framework
+
+
.NET Framework applications will work best with a multi-stage build. This example copies over the necessary project files and packages before it creates the publish files for deployment to Azure.
+
+
# Set the base image
+FROMmcr.microsoft.com/dotnet/framework/sdk:4.8asbuild
+WORKDIR "/src"
+
+# Copy packages to your image and restore them
+COPY taskapp/taskapp.sln .
+COPY taskapp/taskapp/taskapp.csproj taskapp/taskapp/taskapp.csproj
+COPY taskapp/taskapp/packages.config taskapp/taskapp/packages.config
+RUN nuget restore taskapp/taskapp/packages.config -PackagesDirectory taskapp/packages
+
+# Add files from source to the current directory and publish the deployment files to the folder profile
+COPY . .
+WORKDIR /src/taskapp/taskapp
+RUN msbuild taskapp.csproj /p:Configuration=Release /m /p:DeployOnBuild=true /p:PublishProfile=FolderProfile
+
+# Layer the production runtime image
+FROMmcr.microsoft.com/dotnet/framework/aspnet:4.8-windowsservercore-ltsc2019asdeploy
+
+# Add the publish files into the right directory
+WORKDIR /inetpub/wwwroot
+COPY --from=build /src/taskapp/taskapp/bin/Release/Publish .
+
+
+
.NET Core
+
+
For .NET Core, the nano server base image must be “1809” to be compatible with what Azure currently supports. Keep in mind this may change in the future.
+
+
# Set the base image
+FROMmcr.microsoft.com/dotnet/core/aspnet:3.1-nanoserver-1809ASbase
+WORKDIR /app
+EXPOSE 80
+
+# Add the sdk so you can run the dotnet restore and build commands
+FROMmcr.microsoft.com/dotnet/core/sdk:3.1-nanoserver-1809ASbuild
+WORKDIR /src
+COPY *.csproj ./
+RUN dotnet restore "taskapp.csproj"
+COPY . .
+WORKDIR "/src"
+RUN dotnet build "taskapp.csproj"-c Release -o /app/build
+
+# Create the publish files
+FROMbuildASpublish
+RUN dotnet publish "taskapp.csproj"-c Release -o /app/publish
+
+# Copy the publish files into the container
+FROMbaseASfinal
+WORKDIR /app
+COPY --from=publish /app/publish .
+ENTRYPOINT ["dotnet", "taskapp.dll"]
+
+
+
+
Create the GitHub Workflow
+
+
Now that we have our resources created, secrets secured, and dockerfile in order we can start building our workflow file for continuous deployment. The workflow file is a yaml file in .github/workflows/. It contains a collection of actions that run when triggered. Add the workflow file by going to the Actions tab in your repository and click Set up a workflow yourself.
+
+
+
+
After choosing this option, you will see a starter worklfow that explains how GitHub Actions work. If you are new to this I recommend you read the comments, but we won’t be needing any of the starting code so you can remove it.
+
+
Add the workflow trigger
+
+
First, specify the trigger that starts the workflow. For our example, we are simply triggering the build whenever there is a push into the master branch If you would like to change this behavior, there are many other triggers for Github Actions.
+
+
name:Build and Deploy Windows Container App to Azure App Service
+
+# Trigger the build on commits into the master branch
+on:
+ push:
+ branches:
+ -master
+
+# Starts jobs and sets the type of runner (Windows) they will run on
+jobs:
+ build-and-deploy-to-azure:
+ runs-on:windows-latest
+
+ steps:
+
+ # Checks out repository so your workflow can access it
+ -uses:actions/checkout@v1
+
+
+
Log into your container registry
+
+
In order for the workflow to access our registry, we need to add our Docker login action. This action can login to both Azure Container Registry or Docker Hub. If logging into Docker Hub, you can get away with not using the login-server parameter. If using ACR, you can grab the server name, username, and password from the Access Keys tab in your Azure Container Registry Resource.
+
+
Add the following secrets if you have not already:
+
+
+
CONTAINER_REGISTRY_USERNAME: Your container registry username
+
CONTAINER_REGISTRY_PASSWORD: Your container registry password
+
+
CONTAINER_NAME: The hostname of the container registry (ACR only)
+
+
+
+
+
+
Azure Container Registry
+
+
# Use docker login to log into ACR
+-name:Docker login to ACR
+ uses:azure/docker-login@v1
+ with:
+ login-server:${{ secrets.CONTAINER_REGISTRY_NAME }}
+ username:${{ secrets.CONTAINER_REGISTRY_USERNAME }}
+ password:${{ secrets.CONTAINER_REGISTRY_PASSWORD }}
+
Next, we will add a command to build and push the container image to the registry. We are using the $ to tag the container with the commit id. This makes it easy to track what each image contains.
+
+
Add the following secrets if you have not already:
+
+
+
IMAGE_NAME: The name of the image (can be any name)
+
CONTAINER_REGISTRY_NAME: The hostname of the container registry (ACR only)
+
+
+
# Build and push the image to Container Registry
+-name:Build and Push container to registry
+ run:|
+ docker build --file=taskapp/taskapp/Dockerfile -t ${{ secrets.CONTAINER_REGISTRY_NAME }}/${{ secrets.IMAGE_NAME }}:${{ github.sha }} .
+ docker push ${{ secrets.CONTAINER_REGISTRY_NAME }}/${{ secrets.IMAGE_NAME }}:${{ github.sha }}
+
+
+
Authenticate with Azure
+
+
In the earlier section you created an Azure Service Principal and added it as a GitHub Secret. You can now add the Azure login action to the workflow. This action will use the Service Principal to authenticate with Azure. If you are using a publish profile to deploy your application instead of using a Service Principal, please skip this section.
+
+
Add the following secrets if you have not already:
+
+
+
AZURE_CREDENTIALS: The output of the earlier command that generated the Service Principal
+
+
+
-name:Azure Service Principal Authentication
+ uses:azure/login@v1
+ with:
+ creds:${{ secrets.AZURE_CREDENTIALS }}
+
+
+
Deploy to Azure App Service
+
+
If you haven’t already created your App Service, now is the time to do so before you can proceed. Remember that Windows Containers deployment is only available on the Premium tier App Service Plans. Be mindful of the tier capacity, as you may need to scale up if your container is too large.
+
+
The final step to setting up the continuous deployment is to add the webapps container deploy action.
+
+
Add the following secrets if you have not already:
+
+
+
APP_NAME: The webapp name
+
CONTAINER_REGISTRY_NAME: The container registry name
Adding Azure SQL to the workflow is optional of course, as you might have other plans for storage. To deploy your SQL database to Azure, you will use a dacpac file or SQL scripts, and a connection string. The connection string can be found in the overview page of your Azure SQL database and you can create your dacpac by extracting the data using something like SQL Server Object Explorer in Visual Studio.
+
+
Add the following secrets if you have not already:
+
+
+
DATABASE_SERVER_NAME: The resource name of the database
+
+
AZURE_SQL_CONNECTION_STRING: The full connection string for the database
+
+
+
+
+
+
Both your server name and connection string are found in the Azure database resource in the portal. Copy the connection string, making sure your password and user ID are correct, and paste into your GitHub secrets.
+
+
Create a dacpac file in your project
+
+
As mentioned before, you’ll need to use either a dacpac file or set of SQL scripts to deploy your database schema. If you are using Visual Studio, it’s easy to create and add the needed dacpac file to run the action.
+
+
+
Connect your SQL Azure Database to Visual Studio
+
Right-click the data base and choose Extract Data-tier application
+
+
On the following window, choose the location at the same level of your github workflow file and click create.
+
+
+
+
+
+
# Deploy a dacpac file to a pre-provisioned Azure SQL Server
+-name:Azure SQL Deploy
+ uses:Azure/sql-action@v1
+ with:
+ server-name:${{ secrets.DATABASE_SERVER_NAME }}.database.windows.net
+ connection-string:${{ secrets.AZURE_SQL_CONNECTION_STRING }}
+ dacpac-package:'./data.dacpac'
+
+
+
Your dacpac file should have been created and added to your project. The action finds your file under the dacpac-package parameter seen above.
+
+
Summary
+
+
From here you are setup to continuously build your Windows Container application through github actions. Below you’ll see the final result of the workflow yaml file.
+
+
Full workflow file
+
+
The previous sections showed how to assemble the workflow step-by-step. The full main.yaml is below.
+
+
name:Build and Deploy Windows Container App to Azure App Service
+
+# Trigger the build on commits into the master branch
+on:
+ push:
+ branches:
+ -master
+
+# Starts jobs and sets the type of runner (Windows) they will run on
+jobs:
+ build-and-deploy-to-azure:
+ runs-on:windows-latest
+
+ steps:
+
+ # Checks out repository so your workflow can access it
+ -uses:actions/checkout@v1
+
+ # Authenticate a Service Principal to deploy to your Web App
+ -name:Azure Service Principal Authentication
+ uses:azure/login@v1
+ with:
+ creds:${{ secrets.AZURE_CREDENTIALS }}
+
+ # Use docker login to log into ACR
+ -name:Docker login to ACR
+ uses:azure/docker-login@v1
+ with:
+ # comment out the login-server parameter if using docker hub
+ login-server:${{ secrets.CONTAINER_REGISTRY_NAME }}
+ username:${{ secrets.CONTAINER_REGISTRY_USERNAME }}
+ password:${{ secrets.CONTAINER_REGISTRY_PASSWORD }}
+
+ # Build and push your image to Azure Container Registry
+ -name:Build and Push container to ACR
+ run:|
+ docker build --file=taskapp/taskapp/Dockerfile -t ${{ secrets.CONTAINER_REGISTRY_NAME }}/${{ secrets.IMAGE_NAME }}:${{ github.sha }} .
+ docker push ${{ secrets.CONTAINER_REGISTRY_NAME }}/${{ secrets.IMAGE_NAME }}:${{ github.sha }}
+
+ # Deploy your container to App Service
+ -name:Deploy Container to Azure App Service
+ uses:azure/webapps-container-deploy@v1
+ with:
+ app-name:${{ secrets.APP_NAME }}
+ images:${{ secrets.CONTAINER_REGISTRY_NAME }}/${{ secrets.IMAGE_NAME }}:${{ github.sha }}
+
+ # Deploy a dacpac file to your SQL server
+ -name:Azure SQL Deploy
+ uses:Azure/sql-action@v1
+ with:
+ server-name:${{ secrets.DATABASE_SERVER_NAME }}
+ connection-string:${{ secrets.AZURE_SQL_CONNECTION_STRING }}
+ dacpac-package:'./data.dacpac'
+
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Jeff Martinez
+
+ • June 9, 2020
+
+
+
+
+
+
+
+
+
+
The .NET Framework 4.8 update is a non-breaking in-place upgrade on App Service. No updates are required to existing applications.
+
+
+
An update is coming for App Service to support .NET Framework 4.8. You will soon be able to take advantage of the updated .NET Framework toolset, bug fixes, and key improvements in accessibility and runtime. For the full list of updates and changes see the announcement and release notes. The update will come to App Service starting in July 14, 2020 and completing by September 15, 2020. For sovereign clouds the update will start on August 11, 2020 completing by October 15, 2020. In preparation for the platform upgrade to .NET Framework 4.8, customers can choose to test applications locally in advance.
+
+
To track progress during the deployment, we will be posting periodic updates on this GitHub Issue.
+
+
Testing your applications locally
+
+
Test your application locally by completing the following steps:
+
+
Download & install .NET Framework 4.8 for your appropriate scenario here.
+
Run your application in your local browser and verify the application features.
+
If you have issues with your application, feedback can be given on GitHub.
+
+
+
—Optional steps if you plan to re-target your application in the future to explicitly require .NET Framework 4.8—
+
+
If you choose to re-target your application to 4.8 in the future:
+
+
Re-test your application in your local browser and verify the application features.
+
+
+
+
+
Confirming the update on App Service
+
+
You can confirm your webapp’s current .NET Framework version by following these quick steps.
+
+
To see if your apps have been updated after we begin the platform update, check which .NET Framework version is in use by using the console.
+
+
+
+
Open the Console feature under Development Tools in the App Service blade of your Azure Portal.
+
+
+
+
+
Run the following command: cd "\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework".
+
+
+
Run the dir command to list out the installed versions of .NET Framework.
+
+
+
+
+
If .NET Framework 4.8 is installed, it will be located at D:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.8
+
+
+
+
Changes in the portal
+
+
When the deployment is complete across all regions, your Azure App Service portal will update to ASP.NET V4.8 replacing ASP.NET V4.7 in the .NET Framework version drop down under General Settings in the Configuration blade.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 11 minute read
+
+
+
+ • By Jeff Martinez
+
+ • June 9, 2020
+
+
+
Github Actions enables you to easily automate any part of your development workflow. GitHub Actions are defined as YAML files in the .github/workflows direct...
General Availability of Linux Hybrid Connections
+
+
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Christina Compy
+
+ • June 17, 2020
+
+
+
+
+
+
+
We are happy to announce Hybrid Connections for Linux apps is now Generally Available. Hybrid Connections have been available for Windows apps for a few years and is now available for Linux apps as well. Hybrid Connections enables your apps to access TCP endpoints in any network that can make outbound calls to Azure.
+
+
+
+
Hybrid Connections don’t enable an alternate capability to access your application (for that you should look at Private Endpoints). As used in App Service, each Hybrid Connection matches to a single TCP host and port combination. This means that the Hybrid Connection endpoint can be a TCP endpoint on any operating system and any application. There is no awareness in the feature for any application protocols that are used, it simply provides network access. You can make calls to SQL, a web service, or any other TCP socket.
+
+
Other integration technologies rely on VPN solutions to connect on-premises systems to the cloud. Hybrid Connections reduce overhad and provide direct access to resources without an inbound firewall hole or gateway. The feature is built on top of Azure Relay. It works by you installing a relay agent on a Windows server 2012 or better host. This relay agent, the Hybrid Connection Manager (HCM), must be able to make outbound calls to Azure over port 443 and be able to reach the desired endpoint.
+
+
The feature depends on DNS name lookups to work. In order to ensure that things work, you should use domain names in your Hybrid Connections rather than IP addresses. The DNS name does not need to be in public DNS. It only needs to resolve from the hosts where the HCM is running.
+
+
Due to the nature of how Hybrid Connections works, it is a great solution when others do not fit directly. It provides the fastest way to do dev/test from on-premises in the cloud. The feature is supported in Basic, Standard, Premiumv2 and Isolated App Service plans. For more details around Hybrid Connections, start with App Service Hybrid Connections
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
General Availability of VNet Integration for Linux Web Apps
+
+
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Christina Compy
+
+ • June 17, 2020
+
+
+
+
+
+
+
Regional VNet Integration is now Generally Available for both Linux and Windows apps. The feature behaves the same for apps on either operating system. This means that your Linux apps can make calls into Resource Manager VNets in the same region. You can filter outbound calls with Network Security Groups (NSGs). You can route traffic with Route Tables (UDRs). You can also access resources that are secured with Service Endpoints or Private Endpoints. Regional VNet Integration supports hub-and-spoke configurations and reaching across ExpressRoute.
The public preview for Regional VNet Integration on Linux had a problem with port conflicts and custom containers. That problem has been solved in the GA release. You no longer need to worry about port conflicts with custom containers.
+
+
If you integrate your app with your VNet, the default behavior remains as it was. You would only be able to reach RFC1918 addresses (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) and service endpoints. Just like with Windows, the feature now supports outbound calls into the VNet on non-RFC1918 addresses as well. To reach all addresses you need to set the app setting WEBSITE_VNET_ROUTE_ALL to 1, your app will then enable all of the outbound traffic from your app to be subject to NSGs and UDRs. This is the same behavior as seen with Windows web apps.
+
+
These new changes enable you to:
+
+
+
Access non-RFC1918 endpoints through your VNet
+
Secure all outbound traffic leaving your web app
+
Force tunnel all outbound traffic to a network appliance of your own choosing
+
+
+
+
+
Regional VNet integration is available in all public regions now for for Windows Webapps and Linux Webapps. To use Regional VNet Integration, your Webapp must be in a Standard, Premium, PremiumV2 or Elastic Premium App Service plan. Regional VNet Integration only applies to outbound calls made by your Webapps, it does not enable private access to your apps. The older, gateway-required VNet Integration is not supported for Linux apps. This does mean that there isn’t a solution to integrate your Linux apps directly with VNets in other regions or with Classic VNets
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Christina Compy
+
+ • June 17, 2020
+
+
+
Regional VNet Integration is now Generally Available for both Linux and Windows apps. The feature behaves the same for apps on either operating system. This ...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Christina Compy
+
+ • June 17, 2020
+
+
+
We are happy to announce Hybrid Connections for Linux apps is now Generally Available. Hybrid Connections have been available for Windows apps for a few year...
Continuous Deployment for Windows Containers with Azure DevOps
+
+
+
+
+
+
+
+
+ 12 minute read
+
+
+
+ • By Jeff Martinez
+
+ • June 25, 2020
+
+
+
+
+
+
+
+
+
Azure DevOps enables you to host, build, plan and test your code with complimentary workflows. Using Azure Pipelines as one of these workflows allows you to deploy your application with CI/CD that works with any platform and cloud. A pipeline is defined as a YAML file in the root directory of your repository.
+
+
In this article, we will use Azure Pipelines to deploy a Windows Container application to App Service. The sample application is already configured to be used in a Windows Container, pushed to a registry, and deployed to App Service. Of course, you can use this guide to add the correct deployment tasks to work with your own application.
+
+
Sample Application
+
+
+
If you would like to get started with your own application, you can skip to the next section.
+
+
+
The sample application is a simple task-tracking app built with .NET Framework using Azure SQL for storage. The project has a workflow file, azure-pipelines.yaml, that is set up for continuous deployment. You have your choice of using Azure Container Registry (ACR) or Docker Hub for your registry needs (the difference in syntax will be explained below).
+
+
Find the full repository samples for .NET Framework and .NET Core at these highlighted links.
+
+
Create Resources
+
+
Create the following resources. You will need information from each resource that will be used in the pipeline file and stored as a variable. Create your choice of registry (Azure Container Registry or Docker Hub) first since you will need information from there before you can create your App Service.
.NET Framework application with supporting dockerfile in a GitHub repository
+
Azure SQL Database (Optional)
+
+
+
Add a Service Connection
+
+
Before you create your pipeline, you should first create your Service Connection since you will be asked to choose and verify your connection when creating your template. A Service Connection will allow you to connect to your registry of choice (ACR or Docker Hub) when using the task templates. When adding a new service connection, choose the Docker Registry option. The following form will ask you to choose Docker Hub or Azure Container Registry along with pertaining information. You can create a new Service Connection following the directions here.
+
+
The Dockerfile
+
+
The samples below explain the associated Dockerfiles for the .NET Framework and .NET Core sample applications linked above. If creating your own application, use the appropriate Dockerfile below and replace the directory paths to match your application.
+
+
.NET Framework
+
+
Your .NET Framework application will work best with a multi-stage build. This example copies over the necessary project files and packages before it creates the publish files for deployment to Azure.
+
+
# Set the base image
+FROMmcr.microsoft.com/dotnet/framework/sdk:4.8asbuild
+WORKDIR "/src"
+
+# Copy packages to your image and restore them
+COPY taskapp/taskapp.sln .
+COPY taskapp/taskapp/taskapp.csproj taskapp/taskapp/taskapp.csproj
+COPY taskapp/taskapp/packages.config taskapp/taskapp/packages.config
+RUN nuget restore taskapp/taskapp/packages.config -PackagesDirectory taskapp/packages
+
+# Add files from source to the current directory and publish the deployment files to the folder profile
+COPY . .
+WORKDIR /src/taskapp/taskapp
+RUN msbuild taskapp.csproj /p:Configuration=Release /m /p:DeployOnBuild=true /p:PublishProfile=FolderProfile
+
+# Layer the production runtime image
+FROMmcr.microsoft.com/dotnet/framework/aspnet:4.8-windowsservercore-ltsc2019asdeploy
+
+# Add the publish files into the right directory
+WORKDIR /inetpub/wwwroot
+COPY --from=build /src/taskapp/taskapp/bin/Release/Publish .
+
+
+
.NET Core
+
+
For .NET Core, the nano server base image must be “1809” to be compatible with what Azure currently supports. Keep in mind this may change in the future.
+
+
# Set the base image
+FROMmcr.microsoft.com/dotnet/core/aspnet:3.1-nanoserver-1809ASbase
+WORKDIR /app
+EXPOSE 80
+
+# Add the SDK so you can run the dotnet restore and build commands
+FROMmcr.microsoft.com/dotnet/core/sdk:3.1-nanoserver-1809ASbuild
+WORKDIR /src
+COPY *.csproj ./
+RUN dotnet restore "taskapp.csproj"
+COPY . .
+WORKDIR "/src/"
+RUN dotnet build "taskapp.csproj"-c Release -o /app/build
+
+# Create the publish files
+FROMbuildASpublish
+RUN dotnet publish "taskapp.csproj"-c Release -o /app/publish
+
+# Copy the publish files into the container
+FROMbaseASfinal
+WORKDIR /app
+COPY --from=publish /app/publish .
+ENTRYPOINT ["dotnet", "taskapp.dll"]
+
+
+
+
Create the Pipeline
+
+
Once you have your repository created in Azure DevOps, or imported from GitHub, you can create your pipeline. On the left menu bar go to Pipelines and click the Create Pipeline button. The next screen will ask you where the code is to create the pipeline from. We already have our code imported, so we can choose Azure Repos Git to select your current repository.
+
+
Since we are using Docker containers we can choose the Docker template that allows us to build and push an image to Azure Container Registry or Docker Hub.
+
+
+
+
Choose your subscription that you will be pushing your resources to, then pick your Container registry on the following screen. You will notice your Image Name and Dockerfile are pre-populated with a suggested name and path to your Dockerfile. You can leave those as is, and click on the Validate and configure button to generate your azure-pipeline.yaml file.
+
+
Secure Secrets with Variables
+
+
+
Variables are only accessible after your create the pipeline.
+
+
+
Since we are using sensitive information that you don’t want others to access, we will use variables to protect our information. Create a variable by following the directions here.
+
+
To add a Variable, you click the Variables button next to the Save button in the top-right of the editing view for your pipeline. Select the New Variable button and enter your information. Add the variables below with your own secrets appropriate from each resource.
+
+
+
imageRepository: image-name
+
containerRegistry: ‘your-registry-name.azurecr.io’ OR ‘your-docker-hub-registry-name’
Once you have the necessary variables, you can start to add the tasks you need to complete the pipeline. Below is an explanation of the Docker tasks that were added to your pipeline from the Docker template with the addition of using Docker Hub instead of ACR. The additional tasks to deploy to your App Service and optional Azure SQL follow.
+
+
Build and push your image to a registry
+
+
After your pipeline is generated from choosing the Docker configured template, you’ll notice a few things in the YAML build. The first is the trigger, which determines what sets off the build. We are using any push or change to master as a trigger here, but you can change it to trigger on another branch as well.
+The resource is anything used by the pipeline that lives outside of it like a repository or container registry. You can leave this as self since we are using our own repository. Your image type is included and the build stages & task follow.
+
+
# The branch that triggers the pipeline to start building
+trigger:
+-master
+
+# The source used by the pipeline
+resources:
+-repo:self
+
+# Variables used in the Azure Container Registry deployment
+variables:
+ # Container registry service connection established during pipeline creation
+ dockerRegistryServiceConnection:'<your-service-connection-number'
+ dockerfilePath:'$(Build.SourcesDirectory)/taskapp/taskapp/Dockerfile'
+ tag:'$(Build.BuildId)'
+
+ # Agent VM image name
+ vmImageName:'windows-latest'
+
+# Build stage to build your application and push it to a registry
+stages:
+-stage:Build
+ displayName:Build and push stage
+ jobs:
+ -job:Build
+ displayName:Build
+ pool:
+ vmImage:$(vmImageName)
+ steps:
+ -task:Docker@2
+ displayName:Build and push an image to container registry
+ inputs:
+ command:buildAndPush
+ repository:$(imageRepository)
+ dockerfile:$(dockerfilePath)
+ containerRegistry:$(dockerRegistryServiceConnection)
+ tags:|
+ $(tag)
+
+
+
Double check that your vmImageName = ‘windows-latest’ as it might default to ‘ubuntu-latest’.
+
+
Next, add the buildContext below to make sure that necessary application files are being copied over to the image file system. If you forget this line, you will run into an error that can’t find the path inside of your Dockerfile build.
+
+
Azure Container Registry
+
+
-task:Docker@2
+ displayName:Build and push an image to container registry
+ inputs:
+ command:buildAndPush
+ repository:$(imageRepository)
+ dockerfile:$(dockerfilePath)
+ containerRegistry:$(dockerRegistryServiceConnection)
+ buildContext:'.'
+ tags:|
+ $(tag)
+
+
+
Docker Hub
+
+
If you are using Docker Hub, your parameters will already have the buildContext added. However, you may want to add the tags parameter at the end to keep track of which build was sent
You can now hit Save and Run to start the pipeline build. Head over to the Azure portal, where your container registry is, and verify that your image repository name is in the registry repository.
+
+
Setup the Deploy Stage
+
+
Our first stage was pre-populated by the Docker task assistant as our Build stage. We can split the deployment process in half here by adding our Deploy stage. This is done by using the first part of our yaml file and repurposing it to include our deployment tasks. Add in the following code to define a second stage in your pipeline.
+
+
# Deploy stage to your App Service and Azure SQL Database
+-stage:Deploy
+ displayName:Deploy to App Service and Azure SQL
+ jobs:
+ -job:Deploy
+ displayName:Deploy
+ pool:
+ vmImage:$(vmImageName)
+ steps:
+
+
+
Deploy to Azure App Service
+
+
Now that you have your image pushed to your registry and your deploy stage setup. You can push the container to App Service. If you haven’t already created your App Service in the Azure portal, you’ll need to do so now before you can proceed.
+
+
Once you have your App Service created in Azure, you can edit your pipeline to include the deployment to your App Service. Click the assistant in the top right corner of the file and search for Azure Web App for Containers. This task enables you to push a Windows or Linux container to your Azure App Service. You can learn more about how the task works here.
+
+
+
+
Choose your subscription from the drop down menu and click the authorize button (Note: if authorize returns an error, you may need to add a Service Connection as stated before). Now you can add your App name, which should be populated in the drop down, and Image name, which is in the format of “.azurecr.io/:$(tag)". Do not fill out the bottom two parameters Configuration File and Startup command. These are not necessary for what is needed.
+
+
+
+
+
Parameter
+
Value
+
+
+
+
+
Azure subscription:
+
your-subscription-name
+
+
+
App name:
+
your-app-name
+
+
+
Image name:
+
registryname.azurecr.io/imagename:$(tag)
+
+
+
Configuration File:
+
X
+
+
+
Startup command:
+
X
+
+
+
+
+
The registry name information can be found in the Overview tab of you registry resource blade, and the image name can be found in the Repositories tab in the registry resource as well. We are using the DevOps variable $(tag) so it builds with the latest buildId everytime the task is ran.
+
+
+
+
Now you can save your edited pipeline and get the following output below. You can test that it works by pushing up a change from your code and checking that your App Service will have an updated tag number in the Container Settings tab as well as your application changes in your deployed application.
If you run into the following error during your build: “This pipeline needs permissions to access a resource before this run can continue to Build and push stage”. Click the View button on the error and Permit button on the following screen to allow the build to continue.
+
+
Deploy to an Azure SQL Databse (Optional)
+
+
Adding Azure SQL to the workflow is optional of course, as you might have other plans for storage. To deploy your SQL database to Azure, you will use a dacpac file or SQL scripts, and a connection string. The connection string can be found in the overview page of your Azure SQL database and you can create your dacpac by extracting the data using something like SQL Server Object Explorer in Visual Studio.
+
+
If you need to import a SQL database that you’d like to host on Azure, you have the option to add in the Azure SQL Database deployment task which can be found in the assistant we used earlier. Enter the following values for the parameters.
+
+
+
+
+
Parameter
+
Value
+
+
+
+
+
Azure Service Connection Type:
+
Azure Resource Manager
+
+
+
Azure Subscription:
+
your-subscription-name
+
+
+
SQL Database
+
+
+
+
Authentication Type:
+
Connection String
+
+
+
Connection String:
+
your-connection-string
+
+
+
Deployment Package
+
+
+
+
Deploy Type:
+
SQL DACPAC File
+
+
+
Action:
+
Publish
+
+
+
DACPAC File:
+
$(Build.SourcesDirectory)/your-file-name.dacpac
+
+
+
Additional SQLPackage.exe Arguments:
+
X
+
+
+
+
+
Once created with the above parameters, the output should show as below.
Our sample app has a dummy connection string in the web.config that will need to be changed for local testing or can be added into your application settings from your App Service as a Connection String setting in the Configuration tab. Make sure the connection string name in the web.config file matches the connection string name in your App Service setting, with the actual connection string added as the value in your settings. For more information on how to do this see this link.
+
+
When adding the values for the SQL Database parameters, you’ll want to choose Connection String as your Authentication Type and add in your connection string. We’ll use Variables in DevOps to hide our connection string in safe keeping.
+
+
Creating a dacpac file in your project
+
+
As mentioned before, you’ll need to use either a dacpac file or set of SQL scripts to deploy your database schema. If you are using Visual Studio, it’s easy to create and add the needed dacpac file to run the action.
+
+
+
Connect your SQL Azure Database to Visual Studio
+
Right-click the data base and choose Extract Data-tier application
+
+
On the following window, choose the location at the same level of your github workflow file and click create.
+
+
+
+
+
+
Your dacpac file should have been created and added to your project. The action finds your file under the dacpac-package parameter seen above.
+
+
Summary
+
+
From here you are setup to continuously build your Windows Container application through Azure DevOps. Below you’ll see the final result of the workflow yaml file.
+
+
Full workflow file
+
The previous sections showed how to assemble the workflow step-by-step. The full azure-pipelines.yaml is below.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
This log will show requests made to an web app if there were any IP access restriction rules created. It will provide information such as the host, client IP, result, and the matching rule. This is available for both Linux and Windows web apps.
+
+
As an example, if a user created an IP rule to only allow access from a certain IP range, and there was a request made to the app from an IP outside of the allowed IP range, the log will show the IP of the request and which rule denied the request. Similar results will show for requests made from allowed IP ranges.
+
+
+
At the time of writing, this log type can only be sent to a Storage Account. Future updates will be made to allow this log type to go to Log Analytics.
+
+
+
AppServicePlatformLogs (Linux only)
+
+
This log type shows the output of the Docker commands used to manage your container. If you look at your Linux web app’s file system, the LogFiles directory contains two kinds of log files with the following formats:
+
+
+
YYYY_MM_DD_RDXXXXXXXXX_default_docker.log: This is the equivalent of AppServiceConsoleLogs on the file system
+
YYYY_MM_DD_RDXXXXXXXX_docker.log: This is the equivalent of AppServicePlatformLogs on the file system
+
+
+
This log will have the contents of the YYYY_MM_DD_RDXXXXXXXX_docker.log. It will contain logs such as starting container for site..., docker run..., output from the docker pull command, etc.
+
+
Current State of All Logs Types
+
+
The table below shows the latest availability for the log categories on Windows and Linux.
+
+
+
+
+
Log type
+
Windows
+
Windows Container
+
Linux
+
Linux Container
+
Description
+
+
+
+
+
AppServiceConsoleLogs
+
Java SE & Tomcat
+
Yes
+
Yes
+
Yes
+
Standard output and standard error
+
+
+
AppServiceHTTPLogs
+
Yes
+
Yes
+
Yes
+
Yes
+
Web server logs
+
+
+
AppServiceEnvironmentPlatformLogs
+
Yes
+
N/A
+
Yes
+
Yes
+
App Service Environment: scaling, configuration changes, and status logs
+
+
+
AppServiceAuditLogs
+
Yes
+
Yes
+
Yes
+
Yes
+
Login activity via FTP and Kudu
+
+
+
AppServiceFileAuditLogs
+
Yes
+
Yes
+
TBA
+
TBA
+
File changes made to the site content; only available for Premium tier and above
+
+
+
AppServiceAppLogs
+
ASP .NET
+
ASP .NET
+
Java SE & Tomcat 1
+
Java SE & Tomcat Blessed Images 1
+
Application logs
+
+
+
AppServiceIPSecAuditLogs
+
Yes
+
Yes
+
Yes
+
Yes
+
Requests from IP Rules
+
+
+
AppServicePlatformLogs
+
TBA
+
Yes
+
Yes
+
Yes
+
Container operation logs
+
+
+
+
+
1 For Java SE apps, add the app setting WEBSITE_AZMON_PREVIEW_ENABLED and set it to 1true.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 12 minute read
+
+
+
+ • By Jeff Martinez
+
+ • June 25, 2020
+
+
+
Azure DevOps enables you to host, build, plan and test your code with complimentary workflows. Using Azure Pipelines as one of these workflows allows you to ...
+
+
+
+
+
+
+ 5 minute read
+
+
+
+ • By Jason Freeberg
+
+ • June 29, 2020
+
+
+
This is the second article in our Zero to Hero with App Service series. This article assumes you have completed Part 1. In the last article you created an Ap...
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Jason Freeberg
+
+ • June 29, 2020
+
+
+
In times of rapid change, developers and IT decision-makers must quickly adjust to a drastically evolving landscape. Successful organizations use managed clo...
Zero to Hero with App Service, Part 1: Setting Up
+
+
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Jason Freeberg
+
+ • June 29, 2020
+
+
+
+
+
+
+
+
+
In times of rapid change, developers and IT decision-makers must quickly adjust to a drastically evolving landscape. Successful organizations use managed cloud services to reduce operating costs by increasing developer efficiency and seize new business opportunities by accelerating delivery of innovation. App Service is a proven, high-productivity Platform-as-a-Service for hosting web apps and mobile backends. The service provides deployment APIs, networking integration, and built-in monitoring.
+
+
This is the first article in a multi-part series on moving applications to App Service. The series will cover how to continuously deploy your applications, register your site with a custom domain and certificate, securely access other cloud services, and how to properly scale and configure your site. Following this guide will help you get started with App Service and put you on excellent foundation for more advanced uses in the future.
+
+
Prerequisites
+
+
You will need an Azure subscription to complete this guide. You can create a subscription for free. Some parts of this blog series will use the Azure CLI. You can install the CLI locally by following this guide, or you can use the Azure Cloud Shell. The Cloud Shell is a virtual terminal associated with your Azure Subscription, allowing you to run Bash or PowerShell commands to create and update Azure resources.
+
+
You will also need to create a GitHub account if you do not have one already. Once you have a GitHub account, fork one of the repositories below and clone it to your local computer. Make sure you fork the repository. The next article will show how to set up Continuous Integration and Delivery with GitHub Actions.
Now that you have an Azure Subscription, the CLI, and the repository, it's time to create the cloud resources we need. First, open the Azure Portal and click Create a Resource in the top-left dropdown. In the menu, select Web App. This will open the blade to create a web app.
+
+
+
+
The form will ask for the following inputs:
+
+
+
Resource Group : This is a group for all the resources for your project. Create a new resource group and name it zero_to_hero.
+
Name : The name used for the web app. This name will also be used for the default domain name, so it must be globally unique. Try using your own name and some combination of numbers. For example, john-doe-1.
+
Publish : Leave this as code , since we are deploying application code. App Service also supports deploying Docker containers, which is not covered in this guide.
+
Runtime stack : Choose the runtime based on the repo you cloned earlier. If you chose the .NET Core repo, then you should choose .NET Core 2.1. For Node.js, select Node 12 LTS. For Spring, select Java 8 SE. (If you are following this guide using your own application, choose an appropriate runtime and version for your app.)
+
Region : Select a region close to you or leave this as the default.
+
+
+
When you are ready, click Review + create , and complete the creation after reviewing your inputs.
+
+
+
The Azure CLI has commands to create and configure your web apps. For more information, see this guide
+
+
+
The App Service Plan
+
+
The App Service Plan represents the underlying Virtual Machine and can host multiple App Services. As you might expect, the higher hardware tiers have more compute resources and features. The plan is also responsible for scaling, which will be covered in a future article. You can always change the hardware tier after creation.
+
+
Wrapping Up
+
+
Congratulations! You have created an App Service Plan and a web app. You are one step closer to cloud hero status. In the next article you will set up a Continuous Integration and Delivery pipeline to build and deploy your code onto the web app. If you ran into any issues, please comment on this article.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Zero to Hero with App Service, Part 2: Continuous Integration and Delivery
+
+
+
+
+
+
+
+
+ 5 minute read
+
+
+
+ • By Jason Freeberg
+
+ • June 29, 2020
+
+
+
+
+
+
+
+
+
This is the second article in our Zero to Hero with App Service series. This article assumes you have completed Part 1. In the last article you created an App Service Plan, a web app, and forked one of the sample applications. In this article, you will set up a Continuous Integration and Delivery (CI/CD) pipeline using GitHub Actions.
+
+
What is CI/CD?
+
+
Continuous Integration and Delivery is not specific to App Service or Azure. It is a modern software development best-practice to automate the testing and deployment of your application. App Service integrates directly with GitHub Actions and Azure Pipelines, so setting up CI/CD with App Service is easy.
+
+
Continuous Integration
+
+
Continuous Integration is the first step of a CI/CD pipeline. In this phase, the pipeline builds and tests the application. This is usually run for any new pull requests targeting the main tracking branch (formerly known as the master branch). You can also enforce coding style guides or lint the Pull Request during this phase.
+
+
Continuous Delivery
+
+
Assuming the application builds correctly and passes the tests, the new build will be automatically deployed (or delivered) to a staging or production server. Advanced development teams may deploy directly to production, but that requires considerable investment in development operations and automated testing. Teams that are just starting with CI/CD can deploy their builds to a staging environment that mirrors production, then manually release the new build once they feel confident.
+
+
In the next article, you will learn how to route a percentage of your production traffic to a staging environment to test your new build with “real” traffic.
+
+
Create a Staging Environment
+
+
App Service allows you to create and delete independent staging environments, known as slots. You can deploy code or containers to a slot, validate your new build, then swap the staging slot with your production slot. The swap will effectively release the new build to your users. Using the CLI command below, create a staging slot. You will need to replace the <name> parameter with the web app’s name from the previous article.
Staging slots also get their own default domain names. The domain name follows a similar pattern as the production slot, http://mycoolapp.azurewebsites.net except the slot name is appended to the app’s name: http://mycoolapp-staging.azurewebsites.net.
Next, you will create a CI/CD pipeline to connect your GitHub repository to the staging slot. App Service has built-in integration with GitHub Actions and Azure Pipelines. Since the sample apps are hosted in GitHub repos, we will use GitHub Actions for our pipeline.
+
+
About GitHub Actions
+
+
GitHub Actions is an automation framework that has CI/CD built in. You can run automation tasks whenever there is a new commit in the repo, a comment on a pull request, when a pull request is merged, or on a CRON schedule. Your automation tasks are organized into workflow files, which are YAML files in the repository’s .github/workflows/ directory. This keeps your automation tasks tracked in source control along with your application code.
+
+
The workflow file defines when the automation is executed. Workflows consist of one or more jobs , and jobs consist of one or more steps. The jobs define the operating system that the steps are executed on. If you are publishing a library and want to test it on multiple operating systems, you can use multiple jobs. The steps are the individual automation tasks, you can write your own or import actions created by the GitHub community.
+
+
An example “Hello World” workflow file is shown below. It runs any time there is a push to the repository and prints “Hello Keanu Reeves” with the current time. If you read the YAML carefully, you can see how the last step references the output from the earlier “Hello world” command using the dotted syntax.
+
+
name:Greet Everyone
+on:[push]# This workflow is triggered on pushes to the repository.
+
+jobs:
+ build:
+ name:Greeting# Job name is Greeting
+ runs-on:ubuntu-latest# This job runs on Linux
+ steps:
+ # This step uses GitHub's hello-world-javascript-action: https://github.com/actions/hello-world-javascript-action
+ -name:Hello world
+ uses:actions/hello-world-javascript-action@v1
+ with:
+ who-to-greet:'KeanuReeves'
+ id:hello
+ # This step prints an output (time) from the previous step's action.
+ -name:Echo the greeting's time
+ run:echo 'The time was $.'
+
In the Azure Portal, find and click the App Service you created in the previous article. Once you have the App Service open in the portal, select Deployment Center on the left side under the Deployment header. This will open the App Service Deployment Center. The deployment center will guide you through the CI/CD setup process.
+
+
Next, select GitHub and click Continue at the bottom. In the following page, select GitHub Actions (Preview) and click Continue at the bottom. In the next screen, select your repository using the dropdowns. (You do not need to edit the language and language version dropdowns.)
+
+
+
+
On the final page you will see a preview of the GitHub Actions workflow file that will be committed into your repository. Click Complete to commit the workflow file to the repository. This commit will also trigger the workflow.
If you go to your GitHub repository you will see a new file in the .github/workflows/ directory on the master branch. Click on the Actions tab in the GitHub repository to see a historical view of all previous GitHub Actions runs. Once the workflow run completes, browse to your staging slot to confirm that the deployment was successful.
+
+
Summary
+
+
Congratulations! You now have a CI/CD pipeline to continuously build and deploy your app to your staging environment. In the next article you will learn how to swap the staging and production slots to release new builds to your production users. The next article will also explain how to route a small percentage of your users to a staging slot so you can validate new builds against production traffic or do A/B testing.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 5 minute read
+
+
+
+ • By Jason Freeberg
+
+ • June 29, 2020
+
+
+
This is the second article in our Zero to Hero with App Service series. This article assumes you have completed Part 1. In the last article you created an Ap...
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Jason Freeberg
+
+ • June 29, 2020
+
+
+
In times of rapid change, developers and IT decision-makers must quickly adjust to a drastically evolving landscape. Successful organizations use managed clo...
+
+
+
+
+
+
+ 12 minute read
+
+
+
+ • By Jeff Martinez
+
+ • June 25, 2020
+
+
+
Azure DevOps enables you to host, build, plan and test your code with complimentary workflows. Using Azure Pipelines as one of these workflows allows you to ...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Christina Compy
+
+ • June 17, 2020
+
+
+
Regional VNet Integration is now Generally Available for both Linux and Windows apps. The feature behaves the same for apps on either operating system. This ...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Christina Compy
+
+ • June 17, 2020
+
+
+
We are happy to announce Hybrid Connections for Linux apps is now Generally Available. Hybrid Connections have been available for Windows apps for a few year...
+
+
+
+
+
+
+ 11 minute read
+
+
+
+ • By Jeff Martinez
+
+ • June 9, 2020
+
+
+
Github Actions enables you to easily automate any part of your development workflow. GitHub Actions are defined as YAML files in the .github/workflows direct...
+
+
+
+
+
+
+ 4 minute read
+
+
+
+ • By Jason Freeberg
+
+ • July 7, 2020
+
+
+
+ This is the third article in the Zero to Hero with App Service series. This article assumes you have already completed the previous two articles.
+
+
Zero to Hero with App Service, Part 3: Releasing to Production
+
+
+
+
+
+
+
+
+ 4 minute read
+
+
+
+ • By Jason Freeberg
+
+ • July 7, 2020
+
+
+
+
+
+
+
+
+
+
This is the third article in the Zero to Hero with App Service series. This article assumes you have already completed the previous two articles.
+
+
+
At this point, you have a CI/CD pipeline built on GitHub Actions that deploys
+your code into a staging slot whenever a commit is pushed to the main branch. In
+this article, you will learn how to release your new build to your production
+traffic by swapping the production and staging slots. You will also learn how
+to route a percentage of your production traffic to the staging environment to
+test the next build before it is fully released.
+
+
Swap the slots
+
+
Open the Azure Portal to your web app. On the left side menu, select
+Deployment slots. This will open a new blade showing a list of your site’s
+slots. You will see a production and staging slot. Click the Swap
+button at the top.
+
+
+
+
The Swap button will open a context menu with a table to preview any changes
+configuration changes that will occur after the swap. App
+settings
+are key-value configurations that are exposed to your app as environment
+variables. A future article will cover app settings in more detail. Click
+swap at the bottom of the menu to swap the slots.
+
+
+
+
When the operation completes, browse to the production site and you should see
+the sample application! The staging slot should now have the sample application,
+and the staging slot will have the placeholder HTML page with help text.
Up to now, you have a GitHub repository that will trigger a GitHub Action
+workflow whenever there is a push to the main branch. The workflow builds and
+deploys the application to the staging slot of the site. You can use the staging
+site to validate your latest changes. When you’re ready, use the swap button (or
+CLI
+command)
+to swap the slots.
+
+
+
+
If you work in a large team, you can create slots for testing, quality
+assurance, canary testing, A/B testing, and more. Here is an example use case
+for multiple slots:
+
+
+
Continuously deploy the master branch into a “testing” slot for developers
+ to easily validate changes without pulling the branch and run it locally.
+
Swap the build into a QA slot where the configuration more closely resembles
+ the production slot. The new build is thoroughly tested by a QA or
+ acceptance team.
+
Swap into a staging slot where the build is tested against a fraction of the
+ production traffic. The configuration here should match the production slot.
+
Fully release the new build by swapping into the production slot.
+
+
+
+
There is an implicit distinction between deploying and releasing. For more
+information on this distinction, see this article.
+
+
+
Testing in Production
+
+
Testing in Production is the general practice of utilizing production traffic to
+test a new deployment before fully releasing it. This is an umbrella term for
+activities such as traffic shadowing, mirroring, or canarying. Traffic shadowing
+and mirroring are interesting topics, but they are outside the scope of this
+article. The remaining sections will explain how to canary your new
+deployments with App Service before releasing them to production.
+
+
Configuration
+
+
In the Azure Portal, go to the Deployment Slots menu. In the table of your
+slots, you will see a column for Traffic %. By default, all your traffic is
+routed to the production slot. Try setting the traffic percentage to 10% on
+the staging slot. Then click Save. With that simple change, a tenth of your
+production traffic will now go to the new build! This practice is known as a
+“canary deployment” or “canarying a build”.
Now that some of your production traffic is routed to the new build, it is
+prudent to monitor the success of your deployment to catch errors, slow code
+paths, or other unforeseen issues. If you are using an application monitoring
+tool like Application Insights,
+Splunk, or Dynatrace, you will want to tag the metrics and logs coming from your
+staging slot so you can appropriately split the data in your reports and
+dashboards.
+
+
For your client-side code, the slot will expose a cookie, x-ms-routing-name,
+with the slot’s name. You can retrieve this cookie and tag any outgoing metrics
+or logs. In your monitoring service’s dashboard, you can filter or split the
+data on this tag.
+
+
For server-side code, the slot will expose an environment variable,
+WEBSITE_HOSTNAME, which contains the hostname and slot name. Much like the
+client-side cookie, you can grab the value of the environment variable and tag
+your logs or metrics.
Congratulations! Now you know how to release your latest deployments. You can
+also route a percentage of your production traffic to canary test the new build
+before fully releasing it. The next articles will cover certificates,
+domains, network security, and advanced configuration… so stay tuned for more!
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Certificate Authorities revoking non-compliant certificates, potentially impacting your App Service
+
+
+
+
+
+
+
+
+ 2 minute read
+
+
+
+ • By Yutang Lin
+
+ • July 14, 2020
+
+
+
+
+
+
+
+
+
If you have received a notification from Azure about potentially being impacted by the certificate revocation issue, follow these steps to avoid application interruption.
+
+
Certificate Authority (CA) Browser forum recently published reports of multiple certificates issued by CA vendors that are used by our customers, Microsoft, and the greater technology community that were out-of-compliance with industry standards for publicly trusted CAs. The reports regarding the non-compliant CAs can be found here:
As per the industry’s compliance requirements, CA vendors began revoking non-compliant CAs and issuing compliant CAs. This requires customers to have their certificates re-issued. Microsoft is partnering closely with these vendors to minimize the potential impact to Azure Services. However, your self-issued certificates or certificates used with “Bring Your Own Certificate” (BYOC) are still at risk of being unexpectedly revoked.
+
+
If you have been notified about using a self-acquired certificate or using the BYOC feature on App Service that is potentially impacted by this issue, check if certificates utilized by your application have been revoked by referencing DigiCert’s Announcement and the Certificate Revocation Tracker. New certificates need to be requested from the CA vendor utilized in your applications.
+
+
NOTE: This issue will not affect App Service Managed Certificates
+
+
Avoiding Application Interruptions
+
+
To avoid your application’s availability being interrupted due to certificates being unexpectedly revoked, or to update a certificate which has been revoked, follow the steps below:
+
+
+
Reissue your certificate (contact your certificate provider for more information).
+
Once your new certificate has been reissued, add the new certificate to your web app by either uploading the new certificate to your web app or by updating the new certificate in your Key Vault
+
Once you have added your certificate to your web app, you will need to update your bindings refer to the next section.
+
+
+
How to safely update your bindings
+
+
Certificate Imported from Key Vault to App Service
+
+
If you are importing your certificate from Key Vault, App Service has a background job that will automatically update your bindings with the new version of your certificate within 48 hours.
+
+
If you’re using Key Vault and you would like to immediately update your bindings and not wait for the background job, follow these steps below:
+
+
NOTE: If you are using IP SSL bindings – *do not delete* your bindings as your inbound IP can change. It is recommended to wait for the platform’s background job to update the bindings with the new version of your certificate to avoid losing your IP address.
+
+
+
Upload the new certificate in Key Vault using a new certificate name
If you are uploading a certificate to your app web, you will need to update the bindings with your new certificate following the steps below:
+
+
Note: If you are using IP SSL bindings – *do not delete* your bindings as your IP inbound IP can change. Instead you must only *update* the IP SSL bindings.
On Azure portal, go to “TLS/SSL settings” under “Settings” on the left navigation of your resource, select the binding you would like to update, and look for the new certificate from the dropdown.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 2 minute read
+
+
+
+ • By Yutang Lin
+
+ • July 14, 2020
+
+
+
If you have received a notification from Azure about potentially being impacted by the certificate revocation issue, follow these steps to avoid application ...
In this installment of Zero to Hero with App Service, learn how to migrate your existing applications to App Service. If you followed parts one, two, and thr...
In this installment of Zero to Hero with App Service, learn how to migrate your existing applications to App Service. If you followed parts one, two, and three then you already have an application on App Service, and you can continue to the next article.
+
+
+
+
+
+
+
+
+
Overview
+
+
There are multiple ways to migrate a web application to Azure App Service:
+
+
+
Redeploy code using CI/CD Pipelines, Web Deploy, or the REST APIs
Use App Service Migration Assessment Tool to migrate your ASP.NET, PHP web applications and Linux containers
+
+
+
App Service Migration Assessment Tool assesses whether your web site can be moved to Azure App Service. If your web site is public, you can simply provide your URL on this website to run the assessment. You can also download and run the assistant if your web site is hosted in a private environment. Post assessment App service Migration Assessment tool allows quick and easy migration of ASP.NET and PHP web applications running on IIS, and containerized web applications running on Linux operating systems to Azure App Service.
Tool based assessment of internal web applications using the version of tool available for Windows OS and Linux OS. (Download the tool at https://appmigration.microsoft.com/readiness)
+
Based on outcome of assessment (readiness checks) you may proceed further to migrate your web application to Azure App service using App Service Migration Assessment Tool
The App Service Migration Assessment Tool runs multiple readiness checks. The results of the readiness checks are used to decide if your app can migrate to Azure App Service. A comprehensive list of the checks is shown below.
+
+
IIS Server Site Checks
+
+
+
Port Bindings
+
Protocol
+
Certificates
+
Location Tags
+
ISAPI Filters
+
Application Pools
+
Application Pool Identity
+
Authentication Type
+
Application Settings
+
Connection Strings
+
Framework
+
Virtual Directories
+
+
+
+
For detailed information on readiness checks and possible remediation steps, see this article.
+
+
+
Linux Container Checks
+
+
+
Linux Platform
+
Container Volume
+
Exposed Ports
+
HTTP Traffic
+
+
+
+
Please read Linux Container Checks for detailed information on readiness checks and possible remediation steps.
+
+
+
Database Migration and Hybrid Connections
+
+
App Service Migration Assistant migrates the web application and associated configurations only, it does not migrate databases. There are multiple ways to migrate databases to Azure. Some options are listed below.
Your web application on Azure App service can also connect to an existing, on-premises database using Hybrid Connections.
+
+
Hybrid Connections allow your web application to securely access resources in other networks – in this case, an on-premises database. The migration tool configures and sets up Hybrid Connections for you, allowing you to migrate your site while keeping your database on-premises. You can then migrate your database later.
+
+
Azure Migrate Hub Integration
+
+
Azure Migrate provides a centralized hub to assess and migrate on-premises servers, infrastructure, applications, and data. The Migration assessment tool allows you to sync assessment data with Azure Migrate Hub for both successful migrations and migrations with blockers.
+
+
+
+
Summary
+
+
Using these resources, you can easily assess the migration feasibility of your .NET, PHP, and Linux containers. Once your migration assessment is complete, use the assistant's step-by-step instructions to complete the migration to App Service. For more information, see the links below.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Eric Stenson
+
+ • July 26, 2020
+
+
+
+
+
+
+
Latest version updates to PHP
+
+
In August 2020, Azure App Service will update the PHP Windows stacks to the latest available versions. For information on the changes in the new versions, please see the change logs on the PHP website.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
If you would like to customize your web app with a domain name other than “azurewebsites.net”, you can add a custom domain to your web app. Moreover, you can secure your custom domain with a free certificate from App Service Managed Certificates, which will give your customers peace of mind when browsing your website.
App Service Domains lets you create and manage domains hosted on Azure DNS through the Azure portal. The domain can be used for services such as Web Apps, Traffic Manager, and etc.. Purchasing an App Service Domain also provides the added benefit of privacy protection: your personal data will be protected from the WHOIS public database for free. This is often costs extra with other domain registrars. This product can auto-renew your domains and it integrates easily with your web apps.
+
+
To create your App Service Domain, you can click on this link here or you can head to the Azure portal and search for “App Service Domain”.
+
+
+
+
In the domain search bar, type the domain name you would like to purchase. If you don’t see the name in the list of available domains, then the domain isn’t available for purchase. However, you can choose from the suggested list of available domains or enter a new domain you would like to purchase. In the “Contact information” tab, enter your personal information. Then in the “Advanced” tab, choose whether you want to set up auto-renew for the domain. Domain auto-renew prevents accidental loss of domain ownership after expiration. Lastly, decide whether you would like to add privacy protection at no extra charge. Go to “Review + create” to review the legal terms, verify the domain information, and click “Create”. Once your domain has successfully been created, you can now add your custom domain to your web app.
+
+
Adding a custom domain to your web app
+
+
To add a custom domain to your web app, you will need to update your domain’s DNS records. If you purchased an App Service Domain, the DNS records will be updated for you automatically and you can proceed to verifying and adding custom domain. Otherwise, you will need to update your DNS records.
+
+
Updating DNS records
+
+
You will need to get the custom domain verification ID of your web app. This token will be used to verify the domain ownership. You can get this value in the “Custom domains” tab of your web app.
+
+
+
+
Once you have the ID, go to the domain provider of your domain. In the DNS records, create a CNAME and a TXT Record. As an example, if you want to map your ‘www’ subdomain, refer to the chart below:
+
+
+
+
+
Record Type
+
Host
+
Value
+
+
+
+
+
CNAME
+
www
+
.azurewebsites.net
+
+
+
TXT
+
asuid.www
+
Custom Domain Verification ID
+
+
+
+
+
Your DNS records page should look something like the following example:
+
+
+
+
Verifying and adding custom domain
+
+
After updating your DNS records (if not using App Service Domain):
+
+
Go to your App Service and navigate to the “Custom domain” section under “Settings”.
+
Click on the “Add custom domain” button
+
Enter the domain that you would like to use
+
Click “Validate”
+
If you correctly updated your DNS records and the DNS changes have propagated, you will see the option to “add custom domain”. Otherwise, return to the previous section to make sure that you have updated your DNS records properly. Click “add custom domain”.
+
+
+
+
+
Once the custom domain has successfully been added to your web app, you will see it under the list of “Assigned Custom Domains”. You can navigate to your web app using these domain names.
If you would like to secure your custom domain at no cost, you can create an App Service Managed Certificate and bind it to your domain. With Managed Certificates, you don’t have to worry about renewals, as the certificate is automatically renewed for you!
+
+
+
Go to your web app resource and navigate to the “TLS/SSL settings” section under “Settings”
+
Click on the “Private Key Certificates” blade
+
Click the “Create App Service Managed Certificate” button
+
+
+
+
+
Select the domain from the dropdown menu that you would like to create a certificate for and click “Create”.
+
+
+
+
Once the certificate has been created, you will see that it in the list of your private certificates on the “TLS/SSL Settings” blade. In order to use this certificate to secure your domain, you will need to bind this certificate to your domain, which will be explained in the next section of binding your certificate to your web app.
+
+
+
+
Binding Your Certificate to Your Web App
+
+
The final step to securing your domain is to bind your certificate to the domain. In the Portal, go to your web app and navigate to the “Custom domain” section under “Settings”. Look for the domain you want to secure from the list of “Assigned Custom Domains” and click “Add binding”.
+
+
+
+
In the following blade…
+
+
Select the correct custom domain
+
Select the App Service Managed Certificate you’ve just created from the dropdown menu
+
Select “SNI SLL” for the TLS/SSL Type
+
Click “Add Binding”
+
+
+
+
+
Once the binding has successfully been created, you will see a green checkmark and the word “Secure” beside your custom domain under the “Assigned Custom Domains” list.
+
+
Summary
+
+
Congratulations! In this article, you have successfully added and secured a custom domain for your App Service! Your users can now reach your web site at the new domain, and their browser will let them know that the site is secured.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
In this installment of Zero to Hero with App Service, learn how to migrate your existing applications to App Service. If you followed parts one, two, and thr...
+
+
+
+
+
+
+ 2 minute read
+
+
+
+ • By Yutang Lin
+
+ • July 14, 2020
+
+
+
If you have received a notification from Azure about potentially being impacted by the certificate revocation issue, follow these steps to avoid application ...
+
+
+
+
+
+
+ 4 minute read
+
+
+
+ • By Jason Freeberg
+
+ • July 7, 2020
+
+
+
+ This is the third article in the Zero to Hero with App Service series. This article assumes you have already completed the previous two articles.
+
+
A/B Testing with App Service, Part 1: Client-side configuration
+
+
+
+
+
+
+
+
+ 8 minute read
+
+
+
+ • By Jason Freeberg, Shubham Dhond
+
+ • August 3, 2020
+
+
+
+
+
+
+
+
+
In software development, A/B testing is the process of comparing two versions of a webpage or application to determine which version improves a metric or KPI. Depending on your role, there a few reasons why you should start A/B testing your applications.
+
+
+
A frontend developer can test if a refactor improves page load time under real-world conditions
+
A backend developer can deploy two versions of an API to determine any performance gains of a new implementation
+
A designer can check if a new UI layout improves usability metrics
+
A product manager can test different product landing pages to see how different value propositions affect click-through and average time-on-page
+
+
+
A/B testing is a powerful technique for software professionals of all types, but it is not without its complexities. For example, how does one deploy two versions of the application? How is user traffic split between the versions? And most importantly… how is the data tracked, tagged, and analyzed? This blog series will show how to accomplish all these tasks. This first article explains how to instrument your client-side code with a monitoring agent and tag the metrics with the version. The following articles will show how to instrument your backend services and how to analyze the results.
To do A/B testing with App Service, we will use App Service’s deployment slots and Application Insights. Deployment slots allow developers to deploy their new application builds to independent staging environments. Once a new build is deployed to a slot, you can route a percentage of your production traffic to the slot. Once the traffic is split, Application Insights will capture usage and performance metrics tagged with the slot name. The Application Insights blade in the Portal allows you to filter, visualize, and compare data from the different versions.
+
+
Prerequisites
+
+
You will need to have an Azure Subscription and an App Service before starting this guide. You should also have CI/CD (Continuous Integration and Delivery) set up for the App Service. All these steps are covered in parts one, two, and three of our Zero to Hero with App Service series. Please refer to those articles to create an App Service and set up CI/CD. Once you have that set up, continue to the next section to create an App Insights resource.
+
+
Create an Application Insights Resource
+
+
Application Insights is a Application Performance Management (APM) service for client-side and backend apps. App Insights (AI) has SDKs for JavaScript, .NET, Java, Python, Node, and more. You will use AI to capture metrics, tag the data, and analyze the results.
+
+
Create an App Insights resource in the Portal by following these instructions. If you prefer using the Azure CLI, you can run the following command instead. Replace <name> and <group> with your desired name for the AI resource, and name for the resource group.
You will now add App Insights to your client-side code. Jump to the section for your app’s frontend framework.
+
+
React
+
+
App Insights has purpose-built plugins for React and React Native. Follow the linked instructions to add the plugins to your React project.
+
+
Vue.js
+
+
The Vue.js community has created a wrapper for App Insights to register it as a Vue plugin, vue-app-insights. You can install the package with npm install vue-application-insights --save. Once the package is installed, register it as a plugin on the root Vue instance (this is usually in your main.js file). An example is shown below.
Since Vue is a framework for Single Page Applications (SPA’s), the snippet above also passes the Vue router to App Insights so that it can record view changes as proper page views.
+
+
Other JS Frameworks
+
+
If you are using a different JavaScript framework, you can install the Application Insights SDK using NPM, as shown below.
+
+
npm i --save @microsoft/applicationinsights-web
+
+
+
Once the package is installed, declare the App Insights object and provide your instrumentation key from the previous section.
+
+
import{ApplicationInsights}from'@microsoft/applicationinsights-web'
+
+constappInsights=newApplicationInsights({config:{
+ instrumentationKey:'YOUR_INSTRUMENTATION_KEY_GOES_HERE';
+ /* ...Other Configuration Options... */
+}});
+appInsights.loadAppInsights();
+appInsights.trackPageView();// Manually call trackPageView to establish the current user/session/pageview
+
+
+
Next, you will need to register this object with your chosen framework. Most client-side frameworks provide an initialization hook where you can register objects with the root object or module. For Angular apps, follow this blog guide. For Ember.js, you can register the appInsights object in the Application Instance Initializer. Configurations for all other frameworks are left as an exercise to the reader.
+
+
HTML Templates
+
+
If you are using an HTML template engine (like Django, Thymeleaf, or Jekyll) add the following <script> snippet to the <head> of your base template. This will add AI to each of your app’s web pages.
+
+
<script type="text/javascript">
+!function(T,l,y){varS=T.location,u="script",k="instrumentationKey",D="ingestionendpoint",C="disableExceptionTracking",E="ai.device.",I="toLowerCase",b="crossOrigin",w="POST",e="appInsightsSDK",t=y.name||"appInsights";(y.name||T[e])&&(T[e]=t);varn=T[t]||function(d){varg=!1,f=!1,m={initialize:!0,queue:[],sv:"4",version:2,config:d};functionv(e,t){varn={},a="Browser";returnn[E+"id"]=a[I](),n[E+"type"]=a,n["ai.operation.name"]=S&&S.pathname||"_unknown_",n["ai.internal.sdkVersion"]="javascript:snippet_"+(m.sv||m.version),{time:function(){vare=newDate;functiont(e){vart=""+e;return1===t.length&&(t="0"+t),t}returne.getUTCFullYear()+"-"+t(1+e.getUTCMonth())+"-"+t(e.getUTCDate())+"T"+t(e.getUTCHours())+":"+t(e.getUTCMinutes())+":"+t(e.getUTCSeconds())+"."+((e.getUTCMilliseconds()/1e3).toFixed(3)+"").slice(2,5)+"Z"}(),iKey:e,name:"Microsoft.ApplicationInsights."+e.replace(/-/g,"")+"."+t,sampleRate:100,tags:n,data:{baseData:{ver:2}}}}varh=d.url||y.src;if(h){functiona(e){vart,n,a,i,r,o,s,c,p,l,u;g=!0,m.queue=[],f||(f=!0,t=h,s=function(){vare={},t=d.connectionString;if(t)for(varn=t.split(";"),a=0;a<n.length;a++){vari=n[a].split("=");2===i.length&&(e[i[0][I]()]=i[1])}if(!e[D]){varr=e.endpointsuffix,o=r?e.location:null;e[D]="https://"+(o?o+".":"")+"dc."+(r||"services.visualstudio.com")}returne}(),c=s[k]||d[k]||"",p=s[D],l=p?p+"/v2/track":config.endpointUrl,(u=[]).push((n="SDK LOAD Failure: Failed to load Application Insights SDK script (See stack for details)",a=t,i=l,(o=(r=v(c,"Exception")).data).baseType="ExceptionData",o.baseData.exceptions=[{typeName:"SDKLoadFailed",message:n.replace(/\./g,"-"),hasFullStack:!1,stack:n+"\nSnippet failed to load ["+a+"] -- Telemetry is disabled\nHelp Link: https://go.microsoft.com/fwlink/?linkid=2128109\nHost: "+(S&&S.pathname||"_unknown_")+"\nEndpoint: "+i,parsedStack:[]}],r)),u.push(function(e,t,n,a){vari=v(c,"Message"),r=i.data;r.baseType="MessageData";varo=r.baseData;returno.message='AI (Internal): 99 message:"'+("SDK LOAD Failure: Failed to load Application Insights SDK script (See stack for details) ("+n+")").replace(/\"/g,"")+'"',o.properties={endpoint:a},i}(0,0,t,l)),function(e,t){if(JSON){varn=T.fetch;if(n&&!y.useXhr)n(t,{method:w,body:JSON.stringify(e),mode:"cors"});elseif(XMLHttpRequest){vara=newXMLHttpRequest;a.open(w,t),a.setRequestHeader("Content-type","application/json"),a.send(JSON.stringify(e))}}}(u,l))}functioni(e,t){f||setTimeout(function(){!t&&m.core||a()},500)}vare=function(){varn=l.createElement(u);n.src=h;vare=y[b];return!e&&""!==e||"undefined"==n[b]||(n[b]=e),n.onload=i,n.onerror=a,n.onreadystatechange=function(e,t){"loaded"!==n.readyState&&"complete"!==n.readyState||i(0,t)},n}();y.ld<0?l.getElementsByTagName("head")[0].appendChild(e):setTimeout(function(){l.getElementsByTagName(u)[0].parentNode.appendChild(e)},y.ld||0)}try{m.cookie=l.cookie}catch(p){}functiont(e){for(;e.length;)!function(t){m[t]=function(){vare=arguments;g||m.queue.push(function(){m[t].apply(m,e)})}}(e.pop())}varn="track",r="TrackPage",o="TrackEvent";t([n+"Event",n+"PageView",n+"Exception",n+"Trace",n+"DependencyData",n+"Metric",n+"PageViewPerformance","start"+r,"stop"+r,"start"+o,"stop"+o,"addTelemetryInitializer","setAuthenticatedUserContext","clearAuthenticatedUserContext","flush"]),m.SeverityLevel={Verbose:0,Information:1,Warning:2,Error:3,Critical:4};vars=(d.extensionConfig||{}).ApplicationInsightsAnalytics||{};if(!0!==d[C]&&!0!==s[C]){method="onerror",t(["_"+method]);varc=T[method];T[method]=function(e,t,n,a,i){varr=c&&c(e,t,n,a,i);return!0!==r&&m["_"+method]({message:e,url:t,lineNumber:n,columnNumber:a,error:i}),r},d.autoExceptionInstrumented=!0}returnm}(y.cfg);(T[t]=n).queue&&0===n.queue.length&&n.trackPageView({})}(window,document,{
+src:"https://az416426.vo.msecnd.net/scripts/b/ai.2.min.js",// The SDK URL Source
+//name: "appInsights", // Global SDK Instance name defaults to "appInsights" when not supplied
+//ld: 0, // Defines the load delay (in ms) before attempting to load the sdk. -1 = block page load and add to head. (default) = 0ms load after timeout,
+//useXhr: 1, // Use XHR instead of fetch to report failures (if available),
+//crossOrigin: "anonymous", // When supplied this will add the provided value as the cross origin attribute on the script tag
+cfg:{// Application Insights Configuration
+ instrumentationKey:"YOUR_INSTRUMENTATION_KEY_GOES_HERE"
+ /* ...Other Configuration Options... */
+}});
+</script>
+
+
+
+
More information on the snippet-based setup can be found here.
+
+
+
Tag the telemetry
+
+
You now have AppInsights installed. However, the outgoing data needs to be tagged with the slot name so you can correctly filter and analyze the data in the Portal. To do this, add a TelemetryInitializer to your project and register it with the AI object. The telemetry intializer below will get the name of the slot from the x-ms-routing-name cookie and add it as a property on the outgoing data object.
+
+
NPM-based applications
+
+
If you are using React, Angular, Vue, or another NPM-based framework, copy and paste the following method definitions into your project.
+
+
/**
+ * Tags the outgoing telemetry with the slot name taken from the cookie.
+ * @param {object} envelope The outgoing AI telemetry object
+ */
+vartelemetryInitializer=(envelope)=>{
+ constenvironment=getCookieValue('x-ms-routing-name')||'production';
+ envelope.data['slot']=environment;
+}
+
+
+
/**
+ * Returns the value of the specified cookie. If the cookie cannot be found, returns null;
+ * @param {string} key The key of the cookie
+ */
+exportfunctiongetCookieValue(key){
+ constcookie=document.cookie
+ .split('; ')
+ .find(cookie=>cookie.startsWith(key));
+
+ returncookie?cookie.split('=')[1]:null;
+}
+
+
+
Finally, register the telemetryInitializer method with the AppInsights instance.
If you installed App Insights using the HTML snippet from the previous section, you will need to add the following <script> to your root HTML template. This script will add the TelemetryInitializer and register it with App Insights. This script should be pasted after the script that installs App Insights.
Your client-side code is now instrumented with App Insights and will tag any outgoing telemetry with the slot’s name. Now all that is left to do is deploy the application. If you followed parts two and three of Zero to Hero with App Service, then you can simply commit your changes to the master branch and let the CI/CD pipeline deploy the new build to your staging slot.
+
+
+
+
Once your instrumented code is deployed to the staging slot, it is time to start routing some production traffic to the staging slot. In the Azure Portal, go to the Deployment Slots menu. In the table of your slots, you will see a column for Traffic %. By default, all your traffic is routed to the production slot. Try setting the traffic percentage to 10% on the staging slot. Then click Save. With that simple change, a tenth of your production traffic will now go to the new build!
+
+
+
+
(Optional) Deploy PR’s to staging slots
+
+
To do A/B testing with App Service, you need at least two slots: production and staging (which map to the A and B versions). However, you can also spin up a staging slot for Pull Requests to your main tracking branch. This allows your teammates to see the requested changes deployed to a staging server and makes it easy to try the changes live. Even more powerful, you can route a percentage of your traffic to these deployed PR’s as well.
+
+
You can set up the automation for this process using GitHub Actions. It requires two workflow files: one to create the slot and deploy the Pull Request contents, and another to delete the slot once the PR has been closed. We put together example workflows for this, check them out in this repository.
+
+
Summary
+
+
In this article, you instrumented your client-side code or HTML templates. In the next article you will instrument your backend code. We are considering building this functionality into the default behavior of the App Insights SDK (so you don’t have to create your own TelemetryInitializer). If you have thoughts on this guide, please comment below and share! Your input will help us improve this whole story.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 8 minute read
+
+
+
+ • By Jason Freeberg, Shubham Dhond
+
+ • August 3, 2020
+
+
+
In software development, A/B testing is the process of comparing two versions of a webpage or application to determine which version improves a metric or KPI...
+
+
+
+
+
+
+ 4 minute read
+
+
+
+ • By Jason Freeberg and Shubham Dhond
+
+ • August 10, 2020
+
+
+
App Service provides access for FTP and WebDeploy clients to connect using the basic auth credentials found in the site’s publish profile. These APIs are gre...
+
+
+
+
+
+
+ 4 minute read
+
+
+
+ • By Jason Freeberg and Shubham Dhond
+
+ • August 10, 2020
+
+
+
+
+
+
+
+
+
App Service provides access for FTP and WebDeploy clients to connect using the basic auth credentials found in the site’s publish profile. These APIs are great for browsing your site’s file system, uploading drivers and utilities, and deploying with MsBuild. However, enterprises often need to meet security requirements and would rather disable this basic auth access, so that employees can only access the organization’s App Services through API’s that are backed by Azure Active Directory (AAD).
+
+
This article shows how to disable basic authorization, monitor any attempted or successful logins, and how to use Azure Policy to ensure any new sites have basic authentication disabled. Also, the API to disable or enable basic auth is backed by AAD and RBAC, so you can narrow which users or roles are able to re-enable basic auth for a site.
+
+
Disabling Access
+
+
The following sections assume you have owner-level access to the site. The corresponding CLI commandlet is under development at the time of writing.
+
+
FTP
+
+
To disable FTP access to the site, run the following CLI command. Replace the placeholders with your resource group and site name.
Once you have replaced the placeholders, select the text and press Ctrl + S (for Send). On the right side panel, you can see the response code and body. To confirm that FTP access is blocked, you can try to authenticate using an FTP client like FileZilla. To retrieve the publishing credentials, go to the overview blade of your site and click Download Publish Profile. Use the file’s FTP hostname, username, and password to authenticate, and you will get a 401 Unauthenticted.
+
+
WebDeploy and SCM
+
+
To disable basic auth access to the WebDeploy port and SCM site, run the following CLI command. Replace the placeholders with your resource group and site name.
The API in the previous section is backed Azure Role-Based Access Control (RBAC), which means you can create a custom role to block users from using the API and assign lower-priveldged users to the role so they cannot enable basic auth on any sites. To configure the custom role, follow the instructions below.
Open the subscription that you want to create the custom role in
+
On the left navigation panel, click Access Control (IAM)
+
Click + Add and click Add custom role in the dropdown
+
Provide a name and description for the role.
+
For Baseline permissions you can clone one of your organization’s existing roles, or one of the default roles
+
Click the Permissions tab, and click Exclude permissions
+
In the context blade, click the Microsoft Web Apps. This will open a list of all the RBAC actions for App Service
+
+
Search for the microsoft.web/sites/basicPublishingCredentialsPolicies/ftp and microsoft.web/sites/basicPublishingCredentialsPolicies/scm operations. Under these, check the box for Write. This will add the actions as NotActions for the role.
+
+
You can disable this for slots as well. See the microsoft.web/sites/slots/basicPublishingCredentialsPolicies/ftp and microsoft.web/sites/slots/basicPublishingCredentialsPolicies/scm actions
+
+
+
+
+
Click Review + create at the bottom. Under Permissions, you will see the basicPublishingCredentialsPolicies APIs listed as NotActions.
+
+
+
+
Finally, click Create. You can now assign this role to your organization’s users.
All successful and attempted logins are logged to the Azure Monitor AppServiceAuditLogs log type. This means you can use all of Azure Monitor’s features to store, query, and alert based on the log contents.
To audit the attempted and successful logins on FTP and WebDeploy, click the Diagnostic Settings tab on your web app. This will open a blade to select your desired log types, and the destination for the logs. The logs can be sent to Log Analytics, a Storage Account, or an Event Hub.
+
+
+
Provide a name for the Diagnostic Setting
+
Select the log types you want to capture
+
Select the services you want to send the logs to. (The service(s) must already be created, you can’t create them from this blade.)
+
Click Save.
+
+
+
To confirm that the logs are sent to your selected service(s), try logging in via FTP or WebDeploy. An example Storage Account log is shown below.
Azure Policy can help you enforce organizational standards and to assess compliance at-scale. Using Azure Policy, you can define JSON-formatted policies to alter or deny the creation of Azure services. In this scenario, you can use Azure Policy to audit for any sites which have basic authentication disabled, and remediate any non-compliant resources. Azure has built-in policies for auditing and remediating basic authentication on App Service:
In this article you learned how to disable basic authentication to the FTP and WebDeploy ports for your sites. Additionally, you can audit any attempted logins with Azure Monitor and use an Azure Policy to esnure any new sites are compliant with your enterprise’s security requirements.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Application crashes happen. A crash is when an exception in your code goes un-handled and terminates the process. These unhandled exceptions are also known as second chance exceptions. When your application crashes, all the in-flight requests (request that are currently being processed by the app) are aborted. An end user may experience an HTTP 502 error for those requests. When the app restarts, availability of the app is still impacted due to the cold start which makes things worse.
+
+
When you are running production applications, it is important to quickly identify the root cause of an application crash to troubleshoot and minimize the business impact. Having the right set of logs is key to a quick resolution. However, it could be difficult to capture these logs at the time of the crash.
+
+
With App Service Diagnostics’ Crash Monitoring, you can collect memory dumps and call stack information at the time of the crash to identify the root cause. Crash Monitoring works by enabling an agent on your application hosted on App Service. The agent attaches a debugger (procdump.exe in this case) when process starts. If the process crashes with an unhandled exception, the debugger captures a memory dump.
+
+
+
Currently offered in App Service Diagnostics for Windows web apps.
+
+
+
Enabling Crash Monitoring
+
+
If you are using Remote Debugging on your app, Remote Debugging takes preference over Crash Monitoring, and Crash Monitoring will not run.
+
+
Using the Azure Portal
+
+
To access Crash Monitoring, browse to your App Service in the Azure Portal and click Diagnose and Solve problems in the left navigation panel. Then, click on the home page tile named Diagnostic Tools. Once you are inside Diagnostic Tools, click Crash Monitoring.
+
+
Configuration
+
+
Crash Monitoring operates based on 4 conditions that you can configure to your needs. Enabling crash monitoring might incur slight performance impact on your app because a debugger is always attached to your process. The delay would vary depending upon the number of exceptions that your application code is throwing.
+
+
+
Storage account: The selected storage account will store the memory dumps captured via Crash Monitoring. Avoid changing the storage account for your app if there is an active crash monitoring session in progress.
+
Start time: Crash Monitoring session will begin at the selected time.
+
Stop time: Crash Monitoring session will end at the selected time regardless of the maximum of memory dumps captured. To completely disable the agent after the Crash Monitoring session, click on the Disable Agent link.
+
Max No. of memory dump: The Crash Monitoring session concludes once the maximum number of dumps has been gathered. If you want to fully deactivate the agent after the Crash Monitoring session, simply click the Disable Agent link. Before connecting the debugger to the process, the crash monitoring agent verifies the current number of dumps in the storage account. Once the necessary amount of memory dumps has been created, the agent will cease to gather more unless you remove the current dumps from storage or relocate them to another location.
+
+
+
+
The Crash Monitoring configurations are saved in your app’s app settings. Each time a new configuration is saved, your app will restart.
+
+
+
+
+
Once you click Start Monitor, the configuration will be saved, and the monitoring session will begin.
+
+
+
+
+
Deleting a memory dump from a storage account while the tool is still running may cause the tool to collect additional data than desired. Please ensure the session is completed before you delete the memory dumps from the storage account.
+
+
+
Analyzing the Data
+
+
Once you configure and start the Crash Monitoring session, the tool will automatically collect memory dumps and stack trace as your application crashes. You can view the memory dumps and stack trace information grouped by the exit code in the Analyze section. Memory dumps and stack trace information become available as your application crashes though you may experience 15 minutes of delay for complete logs to show.
+
+
You can click on the View details link to expand the details of the crash.
+
+
+
+
Then, you can click on the View link under Callstack to view the call stack for the crash.
+
+
+
+
+
+
Also, there is an option to download the dump file directly. Click on the Download file link next to download the dump file. Once downloaded, open it in Visual Studio.
+
+
+
+
Not only this, you can also launch the call stack window by navigating to the Debug menu and then selecting Windows and then choosing Call Stack.
+
+
+
+
Clicking on Debug with Managed Only will attempt to load the PDB files and open the exact source code of the function if Visual Studio and symbols are lined up properly. Even if they are not, the Visual Studio Debugger will show exception details like below. In this way, you can identify the call stack and exception message directly from the memory dump file.
+
+
+
+
View Historical Data
+
+
You can view up to past 15 days of data in the View History section. If you delete the memory dumps from your storage accounts, they will no longer show in this section.
+
+
+
+
Disable Crash Monitoring
+
+
To disable Crash Monitoring, click Disable agent in the Analyze section. This will remove the app settings for Crash Monitoring and restart your app.
+
+
+
+
Watch a Demo
+
+
Watch this video to learn more about the feature and analyzing the report generated by this tool.
+
+
+
+
+
+
Feel free to share your feedback or questions about Crash Monitoring by emailing diagnostics@microsoft.com
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Application crashes happen. A crash is when an exception in your code goes un-handled and terminates the process. These unhandled exceptions are also known a...
+
+
+
+
+
+
+ 6 minute read
+
+
+
+ • By Christina Compy
+
+ • August 14, 2020
+
+
+
The Azure App Service is offered as two deployment types: the multi-tenant service and the App Service Environment. In the multi-tenant service there are tho...
Zero to Hero with App Service, Part 6: Securing your web app
+
+
+
+
+
+
+
+
+ 6 minute read
+
+
+
+ • By Christina Compy
+
+ • August 14, 2020
+
+
+
+
+
+
+
+
+
The Azure App Service is offered as two deployment types: the multi-tenant service and the App Service Environment. In the multi-tenant service there are thousands of customers on the same infrastructure. Your apps are always secured but the network, the address space and some other components are shared. In an App Service Environment you have a single tenant version of App Service that runs in your Azure Virtual Network. The next two articles are focused on how to configure network security in the multi-tenant App Service.
+
+
In this article, you will learn how to secure your standalone app in the multi-tenant App Service. In the next article, we will cover how to build a secure multi-tier web application.
+
+
Networking overview
+
+
There are two aspects that need to be secured for a web app, inbound traffic and outbound traffic. Inbound traffic are visitors going to your web page, or clients sending requests to your API. Outbound traffic is when your web app makes an outbound call to a database, cache, message queue, or other service. The inbound traffic passes through a load balancer to a set of shared front end servers before reaching the workers which your apps run on. The outbound traffic leaves those workers and goes out through one of the outbound load balancers used by the scale unit. In the diagram below, the inbound and outbound load balancers are shown in green.
+
+
+
+
All traffic to and from the components inside App Service is strictly locked down and secured to prevent malicious actions. This includes preventing any worker-to-worker communication. This means users just need to secure the networking path to and from their apps–all other traffic is secured for you.
+
+
Features and Services
+
+
The following tutorial uses a number of Azure Networking features and services. Here is a quick breakdown of the features used in this article.
+
+
+
Web Application Firewall: The Web Application Firewall (or WAF for short) sits between your applications and your end users. It protects your applications against common attacks like cross-site-scripting or SQL injection.
+
Virtual Network: The Azure Virtual Network (VNet) is the building block for creating your network in Azure. A VNet is similar to a physical network that you would have in an on-premises network: you can assign an address space for a VNet and apply subnets to organize the network.
+
Application Gateway: An Application Gateway acts as a load balancer for your application(s) and allows you to route requests based on the requested hostname or URL path. Learn more about Azure Application Gateway features
+
Service endpoints: Some Azure resources are deployed into virtual networks by default. Other resources, such as the multi-tenant App Service, can gain access to the VNet using Service Endpoints. This means you can use Service Endpoints to only allow inbound traffic to your web app from a subnet within a VNet.
+
Private Endpoints: Private Endpoints enable exposing the inbound traffic to a service on an address in a selected VNet.
+
Azure Front Door: Front Door (AFD) provides many of the same features and benefits of an Application Gateway. It improves application performance by routing users to the nearest Point of Presence (POP).
+
+
+
Securing your web app
+
+
To secure the network access around your web app you will need to secure…
To secure inbound request traffic to your app, use a WAF enabled Application Gateway with Service Endpoints. To secure inbound publishing traffic to your app, use a build agent with service endpoints on the publishing endpoint. Lastly, to secure outbound traffic from your web app, use VNet Integration and an Azure Firewall.
+
+
+
+
Securing inbound traffic
+
+
+
Select or create an Azure Virtual Network (VNet). To secure your inbound traffic to your app you will need to have a VNet. If you have one already, you do not need to create another. It should be in the same region as your web app. If you do not have a VNet, you can create one following these instructions Creating an Azure Virtual Network.
Once you have the VNet, App Gateway, and Service Endpoints set up, you need to add a custom domain name for your app that should point to your Application Gateway. Your web app needs to be configured with the new domain name. To add a custom domain name to your web app, follow the guidance here.
+
+
+
The end result is that your web app will have all inbound traffic routed through your Application Gateway to your app. You can, and should, enable Web Application Firewall (WAF) support on your Application Gateway.
+
+
Alternate Configuration
+
+
There are two alternative services that are in preview that should be noted. One is using Private Endpoints rather than Service Endpoints and the other is using Azure Front Door instead of an Application Gateway.
+
+
If you use Private Endpoints instead of Service Endpoints, you would create your Private Endpoint in a subnet other than the GatewaySubnet. This Private Endpoint would be configured against your app. This is a great solution as it also hosts the HTTPS publishing endpoint for your app. When you add Private Endpoints to your app, the app is no longer accessible from the internet. Traffic to your app must only go through the private endpoints on your app.
+
+
If you use Azure Front Door (AFD) with your app, you would need to set an IP address access restriction to secure your app to only being accessible through AFD. There are some additional changes that will soon be available that will enable you to lock you app down to specific AFD profiles. If you use AFD, you can enable a mix of capabilities such as WAF protection just like with an Application Gateway.
+
+
Secure publishing inbound traffic
+
+
Publishing is the process by which you upload your web app content to your app service instance. Unless you are using FTP, all publishing actions are performed against the scm site for your app. For every app there exists the app url and there also exists the publishing url. The publishing url is <app name>.scm.azurewebsites.net. Secure publishing is not too different from secure app access. For secure publishing you need to publish from inside your VNet. To have a secure publishing story you need to follow one of the following patterns:
+
+
Use Access Restrictions to secure traffic to the publishing endpoint for your app
+
Use service endpoints to secure traffic from a jump box being used to publish
+
Use a relay agent, such as the Azure Pipeline build agent deployed on a VM in your VNet and then use service endpoints to secure your scm site to the subnet that the build agent is in.
Configure service endpoints for your app scm site against the subnet that your VM is in.
+
+
+
Secure outbound traffic from your web app
+
+
To secure outbound traffic from your web app you need to use the regional VNet Integration feature. This feature enables you to make calls into your VNet and have all outbound traffic subject to Network Security Groups (NSGs) and Route Tables (UDRs). With NSGs you can restrict outbound traffic to address blocks of your choosing. With UDRs you can route traffic as you see fit. If you route the outbound traffic to an Azure Firewall device, you can restrict your outbound internet traffic to only the FQDN’s you want it to reach.
+
+
To secure your outbound traffic from your web app, enable VNet Integration. By default, your app outbound traffic will only be affected by NSGs and UDRs if you are going to a private address (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). To ensure that all of your outbound traffic is affected by the NSGs and UDRs on your integration subnet, set the application setting WEBSITE_VNET_ROUTE_ALL to 1.
+
+
Summary
+
+
Congratulations! In this article you learned how to secure your inbound and outbound networking traffic. You are now able to assemble App Service and Networking features to create a secure internet facing web application.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Netflix Eureka is a REST based middleware designed for discovery and load balancing of web applications. For those who already have a Netflix Eureka app, this article explains the configurations required to get a Netflix Eureka based app running correctly in App Service. For readers starting from scratch, we have prepared a demo project with a working example of Netflix Eureka based services working together on Azure App Service.
+
+
Configure Netflix Eureka for App Service
+
+
In Azure, there are several configurations that must be performed on Eureka clients to get them working correctly in App Service. These settings can be included in an application.yml file, application.properties file, or as arguments to the JVM in the JAVA_OPTS app setting.
+
+
Note: These configurations are for Windows Web Apps. For configuration on Linux, see Linux Configuration
+
+
Example configuration files
+
+
If you are using .properties files, the required configurations are below.
Configure your web app to only accept HTTPS traffic.
+
+
+
Go to your App Service in the Azure Portal
+
Find Settings on the left-side navigation menu
+
Click TLS/SSL settings
+
Toggle HTTPS only to “On”
+
+
+
+
+
Explanation of Properties
+
+
spring.application.name=[YOUR APP NAME]
+
+
+
Setting the application name is important for discovery by other services, which will look for the app by spring.application.name. For a Spring Boot based Netflix Eureka app, this is spring.application.name
+
+
eureka.client.serviceUrl.defaultZone=https://[YOUR SERVER HOSTNAME]:443/eureka
+
+
+
This is the default server the client will broadcast to, allowing communication between the client, server, and discovery of all services known by the server. In App Service, the server URL might look like: my-eureka-server.azurewebsites.net.
+
+
eureka.instance.hostname=[YOUR CLIENT HOSTNAME]
+
+
+
The url of the client itself. This should look like my-eureka-client.azurewebsites.net
It is recommended to use secure communication (HTTPS). In the case you do not want to use secure communication, set eureka.instance.secure-port-enabled to false and eureka.instance.nonsecure-port-enabled=true. If you do that, ensure that HTTPS Only setting (under TLS/SSL settings) is set to “Off”.
If using a service such as Spring Actuator, the management server port must be defined as the same port as server.port. This is because the platform assigns a random port to server.port, which the platform then exposes as port 80 and port 443. As such, the Actuator must also communicate on the port which is chosen by the platform to be exposed to the internet.
+
+
Server Configuration
+
+
In Eureka, applications can be clients, servers, or both. In the case where an application is just a server and not a client, add the following configuration in application.properties.
If you are planning on hosting your Netflix Eureka application as a Linux Web App, the port information specified in Windows Web Apps is not required. This is because Windows Web Apps can only expose port 80 and port 443 externally, whereas a Linux Web App can expose other ports.
+
+
An example application.properties file for a Netflix Eureka client on a Linux Web App:
By default the ports 80 and 443 are used for http and https traffic respectively. Notably, management.server.port can be set to any arbitrary port. This may be useful for security or administrative purposes.
+
+
management.server.port=888
+
+
+
Tutorial
+
+
If you do not have a Netflix Eureka project, you can get the example project files here and follow the instructions below to get started.
+
+
If you prefer to use Linux App Service Plans, the example project for Linux is available here. The instructions for the Linux project are the same.
+
+
NOTE: the Linux version of this project will be hosted on premium (P1v2) App Service Plans, which may incur costs.
+
+
Prerequisites
+
+
Building and deploying the example project will require the following technologies.
You will also need an active Azure Subscription to create the web apps.
+
+
An Overview of the Project
+
+
The project is composed of the following four web apps.
+
+
+
2 services which provide data: ratings-data-service, movie-info-service
+
1 service which consumes data from the others: movie-catalog-service
+
1 discovery server to allow the services discover each other: discovery-server
+
+
+
The utility of Netflix Eureka for discovery is showcased in the catalog service, which consumes the ratings data and movie info in this block. The discovery server handles registering the movie info service and ratings data service such that they can be hosted on many machines at many URLS and be consumed by name. As you can see, the code simply calls the services by their app names: ratings-data-service and movie-info-service.
Then, run mvn azure-webapp:deploy -Dprefix=yourPrefix, replacing yourPrefix with a string that is unique to you or your organization. The domain names on App Service must be unique, so this prevents name collisions with other applications. If a prefix is not set this way, a timestamp will used as the prefix.
+
+
+
The application.properties file of each of the services is generated based on client.application.properties.template. The application.properties file of the discovery server is generated from server.application.properties.template. This is to apply the prefix and ensure each application has the same properties. This happens in the prepare-package step of the build process.
After deployment, the project will be hosted on four Azure web apps. The individual apps are at the following four URLs, where “yourPrefix” is the string you provided in the previous step.
Your URLS are in output of the Maven command, and in the Azure Portal in the auto-generated resource group, yourPrefix-example-netflix-eureka-rg.
+
+
+
By default, this project is configured to use a free tier App Service Plan. These app service plans are not “always on” by default, which means they must be visited after deployment to start up. Additionally, they will stop after 20 minutes of inactivity.
+
+
+
Ensure that you visit the discovery server first. This allows the services register with it and discover each other. Then visit the movie info and ratings data services before the movie catalog service. This is because the movie catalog service requires data from the movie info service and ratings data service. Querying the movie catalog service before the movie info and ratings data services results in a 500 error.
+
+
A PowerShell script which performs the requests in correct order:
+
+
#Replace with your prefix
+$prefix=microsoft-example
+
+Invoke-Webrequest-URIhttps://$prefix-discovery-server.azurewebsites.net
+Invoke-Webrequest-URIhttps://$prefix-movie-info-service.azurewebsites.net
+Invoke-Webrequest-URIhttps://$prefix-ratings-data-service.azurewebsites.net
+Invoke-Webrequest-URIhttps://$prefix-movie-catalog-service.azurewebsites.net
+
+
+
The same can be done on bash using curl:
+
+
#Replace with your prefix
+$prefix=microsoft-example
+
+curl -s https://$prefix-discovery-server.azurewebsites.net
+curl -s https://$prefix-movie-info-service.azurewebsites.net
+curl -s https://$prefix-ratings-data-service.azurewebsites.net
+curl -s https://$prefix-movie-catalog-service.azurewebsites.net
+
+
+
Querying the Services
+
+
Data from the services can be accessed directly on each site. Data can also be retrieved as PowerShell objects through the Invoke-RestMethod command:
+
+
#Replace with your prefix
+$prefix=microsoft-example
+
+Invoke-RestMethod-URIhttps://$prefix-movie-info-service.azurewebsites.net/movies/12-ContentType"application/json"
+Invoke-RestMethod-URIhttps://$prefix-ratings-data-service.azurewebsites.net/ratingsdata/movies/12-ContentType"application/json"
+Invoke-RestMethod-URIhttps://$prefix-movie-catalog-service.azurewebsites.net/catalog/12-ContentType"application/json"
+
+
+
Or in bash:
+
+
#Replace with your prefix
+$prefix=microsoft-example
+
+curl -s https://$prefix-discovery-server.azurewebsites.net
+curl -s https://$prefix-movie-info-service.azurewebsites.net/movies/12
+curl -s https://$prefix-ratings-data-service.azurewebsites.net/ratingsdata/movies/12
+curl -s https://$prefix-movie-catalog-service.azurewebsites.net/catalog/12
+
+
+
Querying the Discovery Server
+
+
The discovery server can be queried to provide information about the services registered with it. The following command gets the applications registered with the discovery server:
This means that services and discovery servers hosted on Azure can be accessed and consumed by other Eureka servers, including those hosted on other cloud service providers and local servers. While Netflix Eureka is designed for Java, it is possible to use this data to implement a Netflix Eureka client in any language.
+
+
Securing Eureka
+
+
Without requiring authorization, any user can access the discovery server. This means that a malicious user has all of the information about every service and server registered, and can register their own malicious applications to your discovery server, potentially accessing sensitive information.
+
+
Basic Auth
+
+
Since our example application is based on Spring Boot, it can use Spring Boot’s security to require credentials from clients before registering them.
+
+
+
+
In the pom.xml of the discovery server project, add this dependency:
Note:: if you’re adding this to the example project, add the username and password to client.application.properties.template
+
+
+
+
The client will now be able to successfully register with the Eureka server.
+
+
Security Options for Azure and Spring Boot
+
+
Azure App Service provides built-in authentication and authorization support, so you can sign in users and access data by writing minimal or no code in your web app. This feature, EasyAuth, allows Azure Web Apps to authenticate though identity providers, including Azure Active Directory, Google, Microsoft Account, Facebook, Twitter, and OpenID Connect.
The Spring Boot Starter for Azure provides auto-configuration for a number of Azure Services. These include Azure Active Directory, an authorization and identity service, and Key Vault, a service for storing and retrieving secrets securely across Azure.
Aside from Basic Auth, our example application can use the security features of Spring Security for other types of authorization (Including OAuth2) and protection from exploits such as CSRF attacks.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Netflix Eureka is a REST based middleware designed for discovery and load balancing of web applications. For those who already have a Netflix Eureka app, thi...
GitHub Actions integration is now Generally Available
+
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Jason Freeberg and Mitren Chinoy
+
+ • August 19, 2020
+
+
+
+
+
+
+
A year ago we announced a GitHub Action to deploy your web apps to Azure App Service. In April, we added GitHub Actions as an option in the Deployment Center. We are excited to share that the GitHub Actions integration with Azure App Service is now Generally Available and ready for production workloads.
+
+
+
The current GitHub Actions option in the Deployment Center does not yet support deploying Docker containers. You can still set up Continuous Integration and Delivery (CI/CD) with Docker containers and GitHub Actions by following this tutorial.
+
+
+
The Deployment Center helps you build a CI/CD pipeline on GitHub Actions. This saves time, and simplifies the process if you are new to GitHub Actions or CI/CD. Watch the video below to get started.
+
+
+
+
+
+
+
+
+
If you are new to App Service, see our Zero to Hero series to go from zero to cloud hero with Azure. The articles cover CI/CD, deployment slots, certificates, domains, network security, and advanced configuration!
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Jason Freeberg and Mitren Chinoy
+
+ • August 19, 2020
+
+
+
A year ago we announced a GitHub Action to deploy your web apps to Azure App Service. In April, we added GitHub Actions as an option in the Deployment Center...
A/B Testing with App Service, Part 2: Server-side configuration
+
+
+
+
+
+
+
+
+ 4 minute read
+
+
+
+ • By Jason Freeberg and Shubham Dhond
+
+ • August 24, 2020
+
+
+
+
+
+
+
+
+
This is the second article in our guide for A/B testing with App Service. See the first article for more information about A/B testing and how to set up your client-side project Share your thoughts in the comments section).
+
+
Add the slot name
+
+
First, you will need to add the name of the slot as an app setting. For example, if you have a slot named staging, create an app setting named SLOT_NAME and set its value to staging. If you have a slot named dev, create an app setting named SLOT_NAME with a value of dev. In the next section, the telemetry initializer will use this app setting to tag the outgoing telemetry.
+
+
For example, here is an Azure CLI command to set the app setting and value for a slot named “staging” on a webapp named “my-webapp” in a resource group called “my-resource-group”.
Like in the first article, you will need to add a telemetry initializer to your project and register it with the Application Insights SDK. The telemetry initializer will tag all outgoing events and metrics with the slot’s name, so you can split and filter the data during analysis later. In some cases, you will need to register the initializer with the App Insights SDK. Instructions are below for common backend languages; please jump to the section for your language.
+
+
.NET
+
+
For .NET Core apps, follow the instructions shown here to add App Insights to your project. if you are using ASP.NET, follow these instructions instead. Once you have added the SDK, copy and paste the custom telemetry initializer below.
Create a new class and paste the following definition. The initialize() method will retrieve the name of the current slot from the app setting and attach it to the outgoing telemetry. If you are not using Lombok, you can remove the import and log statement for Lombok.
+
+
importcom.microsoft.applicationinsights.extensibility.TelemetryInitializer;
+ importcom.microsoft.applicationinsights.telemetry.Telemetry;
+ importlombok.extern.slf4j.Slf4j;
+ importorg.springframework.stereotype.Component;
+
+ @Component
+ @Slf4j
+ publicclassCustomTelemetryInitializerimplementsTelemetryInitializer{
+
+ /**
+ * Get the slot name from the env var and attach it to the outgoing telemetry.
+ * @param telemetry Outgoing telemetry
+ */
+ @Override
+ publicvoidinitialize(Telemetrytelemetry){
+ finalStringSLOT_ENV_VAR="SLOT_NAME";
+ finalStringslot=System.getenv(SLOT_ENV_VAR);
+ if(slot!=null){
+ log.info("Tagging telemetry with slot name: "+slot);
+ telemetry.getProperties().put(SLOT_ENV_VAR,slot);
+ }
+ }
+ }
+
+
+
+
+
Other frameworks
+
+
For other Java frameworks you can install the core SDK, coordinates shown below. Once the SDK is added to your dependency list, create an ApplicationInsights.xml file in your app’s classpath. Copy the file contents from here.
+
+
+
+
Add the Application Insights SDK to the dependencies of your pom.xml.
Create an ApplicationInsights.xml file in your app’s classpath. Copy the file contents from here.
+
+
+
Create a new class and paste the following definition. The initialize() method will retrieve the name of the current slot from the app setting and attach it to the outgoing telemetry. If you are not using Lombok, you can remove the import and log statement for Lombok.
+
+
importcom.microsoft.applicationinsights.extensibility.TelemetryInitializer;
+ importcom.microsoft.applicationinsights.telemetry.Telemetry;
+ importlombok.extern.slf4j.Slf4j;
+
+ @Slf4j
+ publicclassCustomTelemetryInitializerimplementsTelemetryInitializer{
+
+ /**
+ * Get the slot name from the env var and attach it to the outgoing telemetry.
+ * @param telemetry Outgoing telemetry
+ */
+ @Override
+ publicvoidinitialize(Telemetrytelemetry){
+ finalStringSLOT_ENV_VAR="SLOT_NAME";
+ finalStringslot=System.getenv(SLOT_ENV_VAR);
+ if(slot!=null){
+ log.info("Tagging telemetry with slot name: "+slot);
+ telemetry.getProperties().put(SLOT_ENV_VAR,slot);
+ }
+ }
+ }
+
+
+
+
Register the telemetry initializer with the App Insights SDK by adding the following line to your ApplicationInsights.xml file. Replace the example package name with your project’s package name.
In this article you added Application Insights and a custom telemetry initializer to your backend project. The custom initializer reads the slot name from the app setting and tags all outgoing telemetry with it. This process is similar to the process in the first article, but applied to the server-side code. The next article will show how to split and analyze the data.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 2 minute read
+
+
+
+ • By Jason Freeberg and Suwat Bodin
+
+ • August 24, 2020
+
+
+
+
+
+
+
+
+
App Service makes it easy to automatically scale your apps to multiple instances when traffic increases. This increases your app’s throughput, but what if there is an uncaught exception on one of the instances? To address this situation, we began previewing Health Check last year. The Health Check feature allows you to specify a path on your application for App Service to ping. If an instance fails to respond to the ping, the system determines it is unhealthy and removes it from the load balancer rotation. This increases your application’s average availability and resiliency.
+
+
Health Check is now Generally Available and ready for production applications. Set up Health Check on your applications today in the Azure Portal. Go to your web app and find Health Check under Monitoring in the left-side navigation menu. You may see “(Preview)” on the Portal blade. This is because the Portal blade uses the latest React libraries, but the feature itself is Generally Available.
+
+
+
+
Overview
+
+
Once you specify a path on your site, App Service will ping it at regular intervals. If the path responds with an error HTTP status code or does not respond, then the instance is determined to be unhealthy and it is removed from the load balancer rotation. This prevents the load balancer from routing requests to the unhealthy instances.
When the instance is unhealthy and removed from the load balancer, the service continues to ping it. If it begins responding with successful response codes then the instance is returned to the load balancer. If it continues to respond unsuccessfully, App Service will restart the underlying VM in an effort to return the instance to a healthy state.
+
+
Health Check integrates with App Service’s authentication and authorization features, so the system will reach the endpoint even if these security features are enabled. If you are using your own authentication system, the health check path must allow anonymous access.
+
+
+
+
The health check path should check the critical components of your application. For example, if your application depends on a database and a messaging system, the health check endpoint should connect to those components. If the application cannot connect to a critical component, then the path should return a HTTP error response code to indicate that the app is unhealthy.
+
+
+
+
Alerts
+
+
After providing your application’s health check path, you can monitor the health of your site using Azure Monitor. From the Health check blade in the Portal, click Metrics in the top toolbar. This will open a new blade where you can see the site’s historical health status and create a new alert rule. For more information on monitoring your sites, see the guide on Azure Monitor.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 2 minute read
+
+
+
+ • By Jason Freeberg and Suwat Bodin
+
+ • August 24, 2020
+
+
+
App Service makes it easy to automatically scale your apps to multiple instances when traffic increases. This increases your app’s throughput, but what if th...
+
+
+
+
+
+
+ 4 minute read
+
+
+
+ • By Jason Freeberg and Shubham Dhond
+
+ • August 24, 2020
+
+
+
This is the second article in our guide for A/B testing with App Service. See the first article for more information about A/B testing and how to set up your...
AppServiceAppLogs is now available for ASP .NET apps on Windows
+
+
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Yutang Lin
+
+ • August 31, 2020
+
+
+
+
+
+
+
+
+
We have added a new log type for ASP .NET web apps on Windows (ASP .NET Core support is not yet supported). The log type, AppServiceAppLogs, captures your app’s log and error statements. This log type is part of the preview of App Service’s integration with Azure Monitor.
Add the following snippet to your Web.config file in order to declare usage of our Trace Listener. This will configure your application to direct its tracing outputs to our listener.. Logs will not show up if you don’t add this to the Web.config.
How to filter log trace levels sent to Log Analytics/Storage account/Event hub
+
+
If you have various trace levels in your web app but are only interested in having certain levels of logs sent to the logging endpoint, you can set a filter for the minimum level in your application settings under Configuration. By default, even without the app setting, the minimum trace level is set to Warning.
+
+
How to set App setting for AppServiceAppLogs level
+
+
The application setting name will be APPSERVICEAPPLOGS_TRACE_LEVEL and the value will be the minimum level (ie. Error, Warning, Verbose, etc.). Refer to TraceLevel for more info.
+
+
+
The trace level value is case sensitive. Make sure the first letter is uppercase and the rest is lowercase (ie. Error, Warning, etc.)
+
+
+
For example, if you are only interested in seeing logs that are of level Error and higher, you will set your application setting APPSERVICEAPPLOGS_TRACE_LEVEL to Error.
+
+
+
+
How logs show up in Log Analytics
+
+
The texts of your logs will generally show up in the “Message” field in Log Analytics, but if you have an Error log, you will find the text in the “StackTrace” field. Look at the samples below and note the difference in the fields.
+
+
Below is a sample result from an Error log:
+
+
+
+
Below is a sample result from an Warning log:
+
+
+
+
Sample queries in Log Analytics
+
+
You can use the different levels of logging such as Error, Information, and etc. in your application and this will show up in your logs in Log Analytics under the “Level” field. You are able to filter out logs based on the level. The example below shows how you can filter for only Error Level logs:
+
+
AppServiceAppLogs
+| where Level == "Error"
+
+
+
FAQ
+
+
Q: I’m not seeing any logs on my Storage account/Log Analytics/Event Hub
+
+
A: On Windows, this log is currently only supported for ASP .NET applications. If your application isn’t an ASP .NET application, you won’t be seeing the logs. However, if your application is an ASP .NET application, there are a couple of possible reasons why your logs aren’t showing:
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Yutang Lin
+
+ • August 31, 2020
+
+
+
We have added a new log type for ASP .NET web apps on Windows (ASP .NET Core support is not yet supported). The log type, AppServiceAppLogs, captures your ap...
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Yutang Lin
+
+ • August 31, 2020
+
+
+
We have added a new log type for ASP .NET web apps on Windows (ASP .NET Core support is not yet supported). The log type, AppServiceAppLogs, captures your ap...
+
+
+
+
+
+
+ 2 minute read
+
+
+
+ • By Jason Freeberg and Suwat Bodin
+
+ • August 24, 2020
+
+
+
App Service makes it easy to automatically scale your apps to multiple instances when traffic increases. This increases your app’s throughput, but what if th...
+
+
+
+
+
+
+ 4 minute read
+
+
+
+ • By Jason Freeberg and Shubham Dhond
+
+ • August 24, 2020
+
+
+
This is the second article in our guide for A/B testing with App Service. See the first article for more information about A/B testing and how to set up your...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Jason Freeberg and Mitren Chinoy
+
+ • August 19, 2020
+
+
+
A year ago we announced a GitHub Action to deploy your web apps to Azure App Service. In April, we added GitHub Actions as an option in the Deployment Center...
Netflix Eureka is a REST based middleware designed for discovery and load balancing of web applications. For those who already have a Netflix Eureka app, thi...
+
+
+
+
+
+
+ 6 minute read
+
+
+
+ • By Christina Compy
+
+ • August 14, 2020
+
+
+
The Azure App Service is offered as two deployment types: the multi-tenant service and the App Service Environment. In the multi-tenant service there are tho...
Application crashes happen. A crash is when an exception in your code goes un-handled and terminates the process. These unhandled exceptions are also known a...
+
+
+
+
+
+
+ 4 minute read
+
+
+
+ • By Jason Freeberg and Shubham Dhond
+
+ • August 10, 2020
+
+
+
App Service provides access for FTP and WebDeploy clients to connect using the basic auth credentials found in the site’s publish profile. These APIs are gre...
+
+
+
+
+
+
+ 8 minute read
+
+
+
+ • By Jason Freeberg, Shubham Dhond
+
+ • August 3, 2020
+
+
+
In software development, A/B testing is the process of comparing two versions of a webpage or application to determine which version improves a metric or KPI...
ASP.NET Framework has fusion Assembly Binding logging (aka Fusion Logging) which allows you to debug assembly load failures in your .NET applications. Fusion logging comes handy when your application is referencing assemblies or external nuget packages and you are encountering assembly binding failures.
+
+
We are pleased to announce that you can enable Fusion logging in Azure App Service on a per-app basis and troubleshoot assembly failures easily.
+
+
+
Currently offered in App Service for Windows web apps only and applies to classic ASP.NET Framework apps. This logging does not apply to ASP.NET Core apps.
Under the Application Settings section, add a new application setting with the name WEBSITE_FUSIONLOGGING_ENABLED and a value of 1.
+
Click the Save button.
+
+
+
+
Saving the application setting causes a restart of the app on all instances, so perform this step during low-usage hours.
+
+
+
After you save this app setting, fusion logging will be enabled for your app. All processes launched for your app (w3wp.exe, w3wp.exe for the Kudu site, and any child processes of these processes) will have fusion logging enabled. This means you can use this feature to troubleshooting assembly binding issues even in WebJobs. Enabling fusion logging on one app does not enable it for other apps in the App Service Plan.
+
+
After fusion logging is enabled, if you browse to the page that was failing to load an assembly, you will now see detailed fusion logs emitted in the actual error message itself. An example is shown below.
+
+
+
+
Using fusion logging you can identify the exact assembly, the version, the location and other information about the whereabouts of the assembly. After you have diagnosed the root cause of the issue, be sure to remove the app setting. Fusion logging incurs some performance impact on the runtime of the application and leaving it enabled is not recommended in production.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
ASP.NET Framework has fusion Assembly Binding logging (aka Fusion Logging) which allows you to debug assembly load failures in your .NET applications. Fusion...
App Service Environment v3 (ASEv3) public preview pre-announcement
+
+
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Christina Compy
+
+ • September 22, 2020
+
+
+
+
+
+
+
+
+
The App Service Environment v3 (ASEv3) project is a realization of several years of infrastructure development to enable a best-in-class, network isolated application hosting PaaS service. Today we are happy to pre-announce the upcoming public preview of ASEv3. The ASEv3 platform is expected to land in public preview in early November in a limited set of regions.
+
+
ASEv3 Overview
+
+
The App Service Environment (ASE) is a single tenant instance of the Azure App Service that runs in a customers Azure Virtual Network (VNet). It solves many isolation scenarios for some of our top customers in a way you cannot with the multi-tenant service. While the service is used widely and is well received, there are some areas we wanted to improve.
+
+
In ASEv3, the underlying technology is based on Virtual Machine Scale Sets (VMSS) instead of Cloud Services. This opens the door to a number of improvements including better load balancers, zone redundancy and multiple other things. Also in ASEv3, we have eliminated the challenge of managing the ASE dependency traffic. With ASEv3, you no longer have any inbound or outbound management traffic in the customer VNet. This vastly simplifies ASE deployment and management.
+
+
+
+
The end result is a single tenant system that has no internet hosted dependencies being called from the customer network. Customers can secure their workloads to their heart’s content and Microsoft can better secure the infrastructure without any impact on customer workloads.
+
+
In addition to operational improvements, we’re also making this new ASE more cost-effective for customers. As part of our Isolated v2 plan, we’re reducing the PAYG rates and eliminating the per instance stamp fee for ASE v3, reducing the cost of deployment by up to 80%.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 2 minute read
+
+
+
+ • By Christina Compy and Jason Freeberg
+
+ • September 22, 2020
+
+
+
For several years, Red Hat and Microsoft have partnered to create cloud solutions that enable enterprises to achieve more. Today, we are happy to announce th...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Christina Compy
+
+ • September 22, 2020
+
+
+
The App Service Environment v3 (ASEv3) project is a realization of several years of infrastructure development to enable a best-in-class, network isolated ap...
+
+
+
+
+
+
+ 2 minute read
+
+
+
+ • By Christina Compy and Jason Freeberg
+
+ • September 22, 2020
+
+
+
+
+
+
+
For several years, Red Hat and Microsoft have partnered to create cloud solutions that enable enterprises to achieve more. Today, we are happy to announce that Red Hat JBoss Enterprise Application Platform (EAP) is now in Public Preview on Azure App Service. App Service has supported Tomcat and Java SE applications on Linux since 2018. Since then, our customers made it clear that they wanted an equivalent service for their Jakarta EE applications.
+
+
+
JBoss EAP on App Service is now generally available! Read more here
Whether your organization is running a heavily customized, clustered JBoss EAP deployment or has embraced container technologies, Azure has a cloud service to fit your needs. With Red Hat Enterprise Linux on Azure Virtual Machine Scale Sets (VMSS), you can easily lift-and-shift your on-prem JBoss EAP deployments. Azure Red Hat Openshift combines the innovation of enterprise Kubernetes with the world’s leading enterprise Linux platform, Red Hat Enterprise Linux.
+
+
App Service gives organizations the option to leverage a managed Platform-as-a-Service (PaaS) for their cloud migrations. App Service provides APIs for deployment, features for network isolation, and auto scaling.
+
+
JBoss EAP on App Service
+
+
To create a JBoss EAP instance, head to the Azure Portal and create a new web app. In the stack selector, choose JBoss EAP 7.2 (Preview). JBoss EAP on App Service is jointly developed and supported by Red Hat and Azure. At General Availability, any support cases concerning the JBoss server will be handled by the experts at Red Hat. Any cases concerning the App Service platform will be resolved by Azure support. Developer tooling for JBoss EAP will be released during the Public Preview release. Subscribe to the App Service Blog to stay up-to-date on news regarding Maven plugins, GitHub Actions, and IDE plugins.
+
+
Public Preview release notes
+
+
You can create a JBoss EAP 7.2 instance on App Service in the Azure Portal. Simply select “JBoss EAP 7.2 (Preview)” in the language stack dropdown. JBoss EAP on App Service is available on all hardware tiers at current prices. As a preview release, there is no commercial support offering and use of the preview is limited to development and testing of your applications. The General Availability release of JBoss EAP on App Service will include a service fee for the integrated technical support. If you create a JBoss EAP instance on App Service, you will receive an email notice prior to the GA release with more details on the pricing changes. Azure will resolve all support cases until the service fee is added at General Availability.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Jason Freeberg, Mitren Chinoy, Byron Tardif
+
+ • September 23, 2020
+
+
+
+
+
+
+
The first version of the App Service Deployment Center has been generally available since late 2018. The Deployment Center gives a centralized view of all the deployment methods for your web app. It also has a guided experience for setting up continuous integration and delivery (CI/CD) pipelines from source control or container registries.
+
+
Today, we are happy to announce that a new version of the App Service Deployment Center is available for technical preview in the Azure Portal. The new experience was built with usability and clarity in mind, especially for developers that are new to App Service. Whether you’re deploying code or containers, the new App Service Deployment Center makes it easy.
+
+
Easy CI/CD for Code
+
+
The Deployment Center makes it easy to create a CI/CD pipeline from your GitHub, BitBucket, or an external Git repository. If you’re using GitHub, the Deployment Center can also create a GitHub Actions workflow for you! See our previous article for more information. If you’re not using GitHub, you can still create a CI/CD pipeline using the Kudu build service.
+
+
+
+
Continuously deploy containers
+
+
With the new Deployment Center, you can easily set up a CI/CD pipeline with GitHub Actions for your containerized applications as well. Before today, you would have to create the GitHub Actions CI/CD workflow file yourself. Now you can go to the Deployment Center in the Portal and follow the on-screen, step-by-step instructions to set up the CI/CD automation. No more YAML indentation errors! The Portal will guide you through setting up a GitHub Actions workflow to build your container, push it to a registry, and pull it to the web app whenever there is a new commit on your specified branch.
+
+
+
+
GitHub Actions is free for public repositories. For private repositories, please see the GitHub pricing page.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Jason Freeberg, Mitren Chinoy, Byron Tardif
+
+ • September 23, 2020
+
+
+
The first version of the App Service Deployment Center has been generally available since late 2018. The Deployment Center gives a centralized view of all th...
Security for Windows containers using Hyper-V Isolation
+
+
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Jeff Martinez
+
+ • September 29, 2020
+
+
+
+
+
+
+
+
+
Windows containers on App Service enable you to modernize your Windows applications so you can bring along dependencies or lift-and-shift your current application. To make sure that your container applications are safe and secure in App Service’s multi-tenant architecture, we use Hyper-V isolation to provide a security boundary around your Windows container apps.
+
+
What is Hyper-V?
+
+
Hyper-V is an isolation mode for Windows containers featuring hardware-level isolation. This virtual isolation mode allows for multiple container instances to concurrently run in a secure manner on a single host. Hyper-V isolation effectively gives each container its own kernel while providing hardware isolation and a security boundary around the containers, as opposed to process isolation which shares the kernel with other containers.
+
+
+
+
Why App Service uses Hyper-V Isolation
+
+
App Service runs on a multi-tenant architecture and uses Hyper-V isolation for running Windows Containers. Hyper-V runs your containers within independent security boundaries, where your container’s resources are isolated from other containers as well as the underlying VM. When creating an App Service Plan for Windows containers, the underlying VM is also dedicated to a single customer providing another level of security between applications. With Windows containers on App Service you can also install and run custom software and dependencies inside of your container.
+
+
The other benefit obtained from using Hyper-V isolation includes broader compatibility between the underlying VM host and the container versions so you can run your choice of base images with compatibility across Windows Server 2019, 2004, 1909, and 1903.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Jeff Martinez
+
+ • September 29, 2020
+
+
+
Windows containers on App Service enable you to modernize your Windows applications so you can bring along dependencies or lift-and-shift your current applic...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Jeff Martinez
+
+ • September 29, 2020
+
+
+
Windows containers on App Service enable you to modernize your Windows applications so you can bring along dependencies or lift-and-shift your current applic...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Jason Freeberg, Mitren Chinoy, Byron Tardif
+
+ • September 23, 2020
+
+
+
The first version of the App Service Deployment Center has been generally available since late 2018. The Deployment Center gives a centralized view of all th...
+
+
+
+
+
+
+ 2 minute read
+
+
+
+ • By Christina Compy and Jason Freeberg
+
+ • September 22, 2020
+
+
+
For several years, Red Hat and Microsoft have partnered to create cloud solutions that enable enterprises to achieve more. Today, we are happy to announce th...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Christina Compy
+
+ • September 22, 2020
+
+
+
The App Service Environment v3 (ASEv3) project is a realization of several years of infrastructure development to enable a best-in-class, network isolated ap...
ASP.NET Framework has fusion Assembly Binding logging (aka Fusion Logging) which allows you to debug assembly load failures in your .NET applications. Fusion...
Deploy your resources on the new Premium v3 SKU with an ARM template
+
+
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Jeff Martinez
+
+ • October 2, 2020
+
+
+
+
+
+
+
+
+
The Premium v3 hardware tier, previously announced at Microsoft Ignite 2020, is now available for you to deploy your applications to. This new hardware tier introduces new CPU and memory options, enabling deployment of more apps per App Service Plan and better support for large enterprise applications and content management systems. With additional price points for dev/test and production workloads and Reserved Instance Pricing starting November 1st*, Premium v3 is our most cost-effective and performant offering ever.
+
+
Portal updates are rolling out now to enable the new hardware option, but you can still deploy resources via ARM templates, Azure CLI and PowerShell. This tutorial walks you through creating a new Resource Group, Pv3 App Service Plan and a Windows Container Web App using an Azure Resource Manager (ARM) template.
+
+
+
Premium v3 is the only hardware option that will be available for Windows container apps as it supports Hyper-V, the chosen security mode for a multi-tenant architecture.
+
+
+
Premium v3 is an option in the regions below. Premium v3 will be available in more regions in the future.
+
+
+
West US 2
+
South Central US
+
UK South
+
Southeast Asia
+
West Europe
+
East US
+
East US 2
+
Australia East
+
North Europe
+
Central US
+
East Asia
+
West US
+
Japan East
+
Brazil South
+
Canada Central
+
Austrailia Southeast
+
West Central US
+
UK West
+
Korea Central
+
France Central
+
+
+
Create your JSON template
+
+
For those not familiar with ARM Templates, they amount to a JSON file which will define the necessary parameters and resources. The following template creates a Premium v3 App Service Plan and Windows container Web App.
+
+
+
Open a New File in Visual Studio Code or your IDE of choice
+
Create a JSON file named azuredeploy.json
+
+
Copy the below template in its entirety and replace any existing brackets in your new file
ARM deployments can be managed through the Azure CLI or Powershell. In this example, we will be using the Azure CLI. If you’d rather use Powershell, please see the instructions here.
+
+
+
First, open Powershell and run az login to login to your Azure account
+
Use the az account set –subscriptionyour-subscription-id to set your desired subscription for your resources
+
Then, create your resource group using az group create –namemy-resources-group-name–location“West Central US”
+
Once you have created the resource group in the correct location, you can then deploy your ARM template
+
Enter az deployment group create –namemy-template-name–resource-groupmy-resource-group-name–template-file“path\to\azuredeploy.json”
+
+
+
You will then be prompted to enter string values for the following parameters:
+
+
+
appServiceWebAppName: web-app-name
+
appServicePlanName: app-service-plan-name
+
+
+
These two values will be the names of the two artifacts of the ARM template, which is creating both your Pv3 App Service Plan and your Web App.
+
+
Verify Deployment
+
Once you have completed the steps above, you can head over to the portal and search for the resource group you just created to verify the resources deployed from the ARM template. You have now successfully deployed to the new Premium v3 SKU creating the following resources:
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Jeff Martinez
+
+ • October 2, 2020
+
+
+
The Premium v3 hardware tier, previously announced at Microsoft Ignite 2020, is now available for you to deploy your applications to. This new hardware tier...
This is part one of our deep dive on Diagnosing CPU utilization issues in Azure App Service. In this post, you will learn about measuring CPU utilization for all apps hosted in an App Service Plan and identifying apps that are consuming maximum CPU resources.
+
+
+
This post applies to Windows web apps on Azure App Service.
+
+
+
First, we will cover troubleshooting tools for debugging Web Apps running on Azure App Services for Windows. These steps can be applied to apps built using any framework such as ASP.NET, Node, PHP, or Java running on a dedicated hardware tier (Basic or higher).
On the left navigation bar, click the Diagnose and Solve Problems tab
+
Select Availability and Performance section on the portal.
+
+
+
+
+
On this page, you can see an overview of your app’s health as well as various topics related to availability and performance. The time duration for the graph’s defaults is the last 24 hours, but you can modify it if needed.
+
+
+
+
The main topics presented are as follows:
+
+
+
Failed Requests: Percentage of requests that have failed within the specified time range.
+
Performance: Response time at the 90th percentile for the specified time range.
+
CPU Usage: Maximum percentage of CPU Usage per instance over the specified time range.
+
Memory Usage: Maximum Private bytes of memory usage for the current app.
+
+
+
Analyze high CPU usage
+
+
High CPU Analysis helps with troubleshooting issues related to the CPU.
+
+
+
Click on the High CPU Analysis on the left-hand menu.
+
Click the App Service Plan Density. This check will ensure the App Service Plan is not over the safe limit or overstuffed due to many apps in the service plan. In the post, we are only running three apps in the App Service Plan which is within safe limits for the SKU.
+
+
+
+
+
+
Expand the insight for One Web App Causing High CPU Usage. This will identify the app consuming the maximum CPU resource on the App Service Plan.
+
+
+
Notice the app demohighcpu is consuming the highest CPU. This is different from the app we are currently looking at demotroubleshootingapp. The tool suggests to further debug the app demohighcpu.
+
+
+
+
Inspect CPU usage by instance
+
+
Below you can see the overall CPU usage for all the instances associated with the App Service Plan. In this example the app is running in two instances that are consuming high CPU.
+
+
+
Click on the drop-down arrow for Overall CPU Usage per Instance.
+
Hover over the graph of Overall CPU Usage Per Instance.
+
You can see CPU consumption of each instance.
+
+
+
+
+
CPU Drill Down
+
+
Below the graph you can see a drill down view that displays the App-level CPU consumption for the app running on the same App Service plan. This tool identifies each individual apps running in the instance. By default, the instance with the maximum CPU usage will display first. In this example we can see the CPU maximum usage and average of demohighcpu.
+
+
+
+
App Level CPU Consumption
+
+
Next, you can see a process level breakdown of each app. By default, the app with the maximum CPU is preselected.
+
+
+
Next to Select the app, click on the app name.
+
+
+
A drop-down view appears. You can switch between apps running on the same app service plan. In the example, you can see a breakdown of the process name and process ID.
+
+
+
+
What’s Next?
+
+
After identifying the app causing high CPU, debug the app to identify why the CPU is high. The next article will go over the techniques you can use to debug the app. Some possible mitigations you can apply are:
+
+
+
Restart the App as that may reduce the high CPU usage temporarily.
+
Upgrading to the next tier can give you more resources if the app is consuming high CPU and you are on a lower tier.
+
If multiple apps are experiencing high CPU due to an increase in requests, upgrading your App Service Plan to the next tier will allow it to benefit from an increase in scale.
+
Isolating some apps to a dedicated app service plan can reduce the impact of other essential apps.
+
+
+
In the example, we saw demohighcpu is consuming the maximum CPU. Next, we will debug the app further to identify the cause of the high CPU in the next post. If you want to watch an in-depth tutorial on this topic, click on the video below!
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
This is part one of our deep dive on Diagnosing CPU utilization issues in Azure App Service. In this post, you will learn about measuring CPU utilization for...
+
+
+
+
+
+
+ 5 minute read
+
+
+
+ • By Christina Compy
+
+ • October 5, 2020
+
+
+
The Azure App Service is offered as two deployment types: the multi-tenant service and the App Service Environment. In the multi-tenant service there are tho...
Zero to Hero with App Service, Part 7: Multi-tier web applications
+
+
+
+
+
+
+
+
+ 5 minute read
+
+
+
+ • By Christina Compy
+
+ • October 5, 2020
+
+
+
+
+
+
+
+
+
The Azure App Service is offered as two deployment types: the multi-tenant service and the App Service Environment. In the multi-tenant service there are thousands of customers on the same infrastructure. Your apps are always secured but they share the network, address space, front ends, and some other components. In an App Service Environment you get a single tenant version of App Service that runs in your Azure Virtual Network. In this article, you will learn how to build network-secured, multi-tier web applications in the multi-tenant App Service.
+
+
Multi-tier web applications
+
+
The obvious question to start with is, what is a multi-tier web application? A multi-tier web application is an application with a front end that makes calls to one or more API applications behind it. By itself this is not a complex concept, but when a user wants to secure the API applications so they are not internet accessible the architecture becomes more complex.
+
+
There are multiple ways to secure your API applications so that they can only be reached from your front end applications. They all involve securing your API application’s inbound traffic. There are multiple features that could be used for this purpose:
+
+
+
Service endpoints secure the listening service. With Service Endpoints, the source address must be in an Azure Virtual Network subnet.
+
Private endpoints prevent data exfiltration and secure the listening service. With private endpoints, you can reach the web app from anywhere that has network access to the private endpoint address.
+
Access restrictions can lock down your inbound traffic to a set of address blocks.
+
+
+
Each of those features satisfies a specific situation and there are trade offs. Access restrictions are useful if you have public address access points like NAT devices or perhaps a virtual network device with a dedicated public address. If you use service endpoints, you do not add any new resources to your subscription and are able to use one subnet. If you use private endpoints you will add a new top level resource, add Azure DNS private zones to your VNet and will require two subnets. Let’s now dicsuss each of these options in greater detail.
+
+
Service endpoints
+
+
To configure a multi-tier application using service endpoints to secure your API application, you need to use VNet Integration with your front end app and service endpoints with your API app. Set service endpoints on the integration subnet used by your Front End application. This solution is fast to set up and easy as well.
+
+
+
+
If you have multiple front end apps, the configuration is the same if all of the front end apps are in the same App Service plan. With VNet Integration, the apps in the same App Service plan can use the same integration subnet. If you have additional front end applications in separate App Service plans, you will need to use multiple integration subnets. In this situation, service endpoints must be configured against each of the integration subnets. With VNet Integration, you cannot have more than one App Service plan configured with a subnet.
+
+
+
+
If you have multiple API apps and multiple front end apps from separate App Service plans, you need to configure VNet Integration from each front end app and then service endpoints on each API app against the integration subnets.
+
+
+
+
As you add front end applications, you need to configure service endpoints with each dependent API application. This means service endpoints are great at smaller scale. It can quickly get out of hand if you have many–or an ever increasing number of–front end applications with multiple API applications. Managing the configuration can be confusing as the number of front ends grows.
+
+
Private endpoints
+
+
With private endpoints, the configuration is both easier and harder. It is easier in that when you place a private endpoint in your VNet for an app, you are done managing the inbound traffic to your API app. Unlike with service endpoints, there is no additional configuration to your API app as you add new front end consumers. It is harder because setting up private endpoints creates a new, top-level resource and Azure DNS private zones.
+
+
If you have one front end app or more than that, the configuration is the same. You set up VNet Integration with the same VNet that your API app has a private endpoint in. You also have private endpoints configured on your API application.
+
+
+
+
If you have more than one front end app, the only difference is that this second front end app needs VNet Integration to be configured with it. If this additional front end application is in a different App Service plan, it will use a separate subnet. Each time you use VNet Integration from another App Service plan, you will need another subnet for integration.
+
+
+
+
If you have multiple API applications, you will need multiple private endpoints. Those private endpoints can be in the same subnet, or not. Private endpoints are more flexible in this regard than VNet Integration. Once your API application has exposed itself with a private endpoint, any front end app that integrates with that VNet should be able to reach it.
+
+
+
+
At a small scale, private endpoints incurs more overhead. You will have more to manage and maintain than with service endpoints. On the other hand, private endpoints are a solution for data exfiltration concerns. They also do better at scale as it is easy to add more front end applications.
+
+
Access restrictions
+
+
With access restrictions you can secure inbound traffic to a set of IP address blocks. This is useful when you want to lock your traffic to a set of egress devices. You can also use it with other edge protection services such as Azure Front Door. With respect to using it directly with multi-tier applications, you can secure your API applications to the egress addresses used by your front end applications. The problem with this approach is that the outbound addresses are shared with all of the other customers in the same scale unit. From a security review perspective it doesn’t look as secure as service endpoint or private endpoint based solutions. So while it is possible and worth noting, it is not recommended to use access restrictions to create multi-tier web applications.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 2 minute read
+
+
+
+ • By Eric Grenon
+
+ • October 6, 2020
+
+
+
We are happy to announce Private Endpoint for Web App is now Generally Available in all Azure public regions, for both Windows and Linux apps, containerized ...
General Availability of Private Endpoint for Web App
+
+
+
+
+
+
+
+
+ 2 minute read
+
+
+
+ • By Eric Grenon
+
+ • October 6, 2020
+
+
+
+
+
+
+
We are happy to announce Private Endpoint for Web App is now Generally Available in all Azure public regions, for both Windows and Linux apps, containerized or not. To use Private Endpoint your app must be hosted on PremiumV2, PremiumV3, or Function Premium plan.
+
+
Private Endpoint enables you to consume your app through a specific IP address located in your Azure Virtual Network (VNet), eliminating the exposure of your app to the public Internet.
+Private Endpoint provides at the same time a solution to remove the data exfiltration risk. You can secure your VNet with NSG denying any outbound flow and a Private Endpoint will let you go only to the specified app linked to this endpoint.
+
+
+
+
Private Endpoint vs Service Endpoints
+
+
Service Endpoints are used to secure the app to only being reachable from specific subnets.
+Private Endpoint provides a way to expose your app on an IP address in your VNet and removes all other public access. This not only provides security for the app but can also be combined with Network Security Groups (NSG) to secure your network and prevent data leakage.
+
+
Private Endpoint vs App Service Environment
+
+
Having your app only accessible on a private address in your VNet is something that was previously only possible by using an ILB App Service Environment or an Application Gateway with an internal inbound address. The difference between using Private Endpoint and an ILB ASE is that with an ILB ASE you have single tenant system that can host many apps behind one IP address in your VNet. With Private Endpoint, your app runs in the public App service and you have only one app behind one IP address. If you want to apply network security external to your application, then you still only get that with an ILB ASE. If you only need a private address in your VNet, then Private Endpoint can give you that.
+
+
Private Endpoint combined with VNet integration
+
+
Private Endpoint provides a private IP address for inbound traffic only to your app. It does not enable your app to make outbound calls into your network. If you want to have all inbound and outbound in your VNet, then you need to use both Private Endpoint and Regional VNet Integration in two separate subnets. With Private Endpoint you can secure the inbound and with VNet Integration you can secure the outbound.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Jeff Martinez
+
+ • October 15, 2020
+
+
+
+
+
+
+
+
+
Starting November 1st, 2020. Docker will be introducing rate limits on unauthenticated pull requests from Docker Hub. These limits are based on the account type of your personal or organizations Docker Hub account. In preparation of the incoming rate limits, App Service recommends that you authenticate your Docker Hub pull requests by updating your Public Repository Access containers on App Service to Private to mitigate any potential impact or move your container images to Azure Container Registry (ACR) as the source of your pulls.
+
+
+
To learn more about Docker Hubs rate limits, see the Docker announcement.
+
+
+
+
For additional info on container pulls and its overall impact, see this
+Open Container Initiative blog for Consuming Public Content.
+
+
+
Authenticate Docker Hub pull requests
+
+
To make sure your pull requests from Docker Hub are authenticated first, set your Docker Hub repository to Private to require your username and password for pulls from the registry. Then, follow the instructions below to authenticate your pulls from Azure:
+
+
+
+
+
Go to Container Settings
+
Under Repository Access, set your access level to Private
+
Enter your Docker Hub Login and Password
+
Click Save at the bottom of the screen.
+
Go to the Overview page of your resource and Restart your container
+
+
+
Now you should be able to successfully pull from your Private Docker Hub repository with an authenticated pull.
+
+
Azure Container Registry
+
+
Another option available is to import your images from Docker Hub to Azure Container Registry (ACR) as the source of your container pulls. ACR enables you to build, store, and manage your Docker containers on Azure. To create a new ACR resource, follow the instructions in this doc.
+
+
Once you have created your ACR resource, you can import your Docker Hub containers to ACR using the following Azure CLI commands in Powershell:
+
+
+
Use az login to connect to Azure
+
Run az acr import –namemy-registry–sourcedocker.io/registryname/image-name:tag–imageimage-name:tag
+
+
+
Once this runs, you can validate that your image has been imported to ACR by going to your Azure Container Registry resource and viewing your Repositories. To learn more, please see the ACR documentation to import from docker hub and consuming public content with ACR tasks.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Jeff Martinez
+
+ • October 15, 2020
+
+
+
Starting November 1st, 2020. Docker will be introducing rate limits on unauthenticated pull requests from Docker Hub. These limits are based on the account ...
A/B Testing with App Service, Part 3: Analyzing the telemetry
+
+
+
+
+
+
+
+
+ 4 minute read
+
+
+
+ • By Jason Freeberg and Shubham Dhond
+
+ • October 20, 2020
+
+
+
+
+
+
+
+
+
This is the third article in our guide for A/B testing with App Service. The first article shows how to set up your client-side project. The second article shows how to configure your backend.
Now that our client-side and backend projects are configured, we can analyze the data and compare results using Application Insights. Open the Azure Portal and open your Application Insights resource that you created in the first article. On the left side, open Logs under Monitoring.
+
+
+
+
Example 1: Comparing request duration
+
+
This example will show three slots. The staging slot is where our main branch is deployed to every time there is a push to the main branch. The other two slots, labeled 219 and 230, are both pull requests targeting the main branch. We are using App Service’s deployment slots as a staging environment to deploy the pull requests on so we can test them before merging.
+
+
Our goal in this example is to compare the average request durations for an important API call in the application. If we identify that one of the pull requests regresses the performance of that API, then we can investigate the PR’s changes more closely so we don’t regress performance in production.
+
+
The query
+
+
Let’s walk through the query step-by-step. We will use the dependencies table which shows outbound calls from our client-side application. Next, create two columns using the extends command. The first column, time_bin, bins the timestamp into 5 minute windows which makes our data less noisy. The other column, slot, parses the slot name from the customDimension column.
We will also specify a time window of 24 hours, and filter the rows to show only POST calls to /api/flights/reserve. You can expand or narrow the time window depending on the amount of telemetry your application emits. And you should also change the API path to a valid request in your application. On the last line, project drops all columns except for slot, time_bin, and duration.
+
+
| where timestamp > ago(24h)
+ and name == "POST /api/flights/reserve"
+| project slot, time_bin, duration
+
+
+
Before we render the timechart, use the evaluate pivot(..) command to rotate the table by turning the unique values in the slot column into multiple columns. This command will also take the average request duration by each time_bin and slot.
+
+
| evaluate pivot(slot, avg(duration))
+| render timechart with ( title="Request duration by slot")
+
+
+
The graph
+
+
When the query is executed, you should get a graph similar to the one shown below. Each line represents a deployment slot. The y-axis shows the request duration, and the x-axis shows the time. In the example shown below, we can see that customers that are routed to the slot “230” are experiencing very long request durations. Knowing this, we can investigate the changes in that Pull Request and fix the problem before merging.
+
+
+
+
Example 2: Comparing custom metrics
+
+
You can use Application Insight’s telemetryClient.trackMetric() and telemetryClient.trackEvent() methods to track custom metrics and events. In this scenario, we are emitting a custom metric to track the average duration of a database query in milliseconds. You could also track the time spent for other backend operations, such as heavy data processing or I/O operations.
+
+
The query
+
+
Your custom metrics are tracked in the customMetrics table. The first step is to filter the custom metric rows to the metric of interest, which is query_time in this case. Like before, create a new column, slot, from the customDimensions table. Next, take the average value for each slot.
+
+
customMetrics
+| where name == "query_time"
+| extend slot = tostring(parse_json(customDimensions).SLOT_NAME)
+| summarize avg(value) by slot
+
+
+
The final step is to render a bar chart and clean up the labels. The order by slot ensures that the bars of the bar chart are always rendered in the same order.
+
+
| order by slot
+| render barchart with ( title="Average query time by slot", ytitle="Query time in ms", xtitle="Slot name")
+
+
+
The graph
+
+
Similar to the previous example, this chart shows us that Pull Request 232 is greatly improving the query performance under real-world traffic. This is a good sign, and gives developers or QA teams another data point for the PR review process.
+
+
+
+
Monitoring dashboards
+
+
You can use Azure Monitor Workbooks to monitor your experiments and quickly gauge results across your queries. To get started, open your Application Insights resource in the Portal and open the Workbooks blade. Then click + New.
+
+
+
+
The workbook will open with a default Markdown section and graph. Click the Edit button below the graph and paste one of the earlier queries. Click Done Editing at the bottom to save the query. You can also annotate your workbook with notes, links, and lists using Markdown.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 4 minute read
+
+
+
+ • By Jason Freeberg and Shubham Dhond
+
+ • October 20, 2020
+
+
+
This is the third article in our guide for A/B testing with App Service. The first article shows how to set up your client-side project. The second article s...
+
+
+
+
+
+
+ 4 minute read
+
+
+
+ • By Jason Freeberg and Shubham Dhond
+
+ • October 20, 2020
+
+
+
This is the third article in our guide for A/B testing with App Service. The first article shows how to set up your client-side project. The second article s...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Jeff Martinez
+
+ • October 15, 2020
+
+
+
Starting November 1st, 2020. Docker will be introducing rate limits on unauthenticated pull requests from Docker Hub. These limits are based on the account ...
+
+
+
+
+
+
+ 2 minute read
+
+
+
+ • By Eric Grenon
+
+ • October 6, 2020
+
+
+
We are happy to announce Private Endpoint for Web App is now Generally Available in all Azure public regions, for both Windows and Linux apps, containerized ...
This is part one of our deep dive on Diagnosing CPU utilization issues in Azure App Service. In this post, you will learn about measuring CPU utilization for...
+
+
+
+
+
+
+ 5 minute read
+
+
+
+ • By Christina Compy
+
+ • October 5, 2020
+
+
+
The Azure App Service is offered as two deployment types: the multi-tenant service and the App Service Environment. In the multi-tenant service there are tho...
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Jeff Martinez
+
+ • October 2, 2020
+
+
+
The Premium v3 hardware tier, previously announced at Microsoft Ignite 2020, is now available for you to deploy your applications to. This new hardware tier...
We are happy to announce that App Service now supports .NET 5 applications across all public regions and scenarios on both Windows and Linux App Service plans.
+
+
The App Service and .NET teams worked closely together to deliver this functionality on the same day as .NET 5 reached GA (see .NET 5 GA announcement). Going forward every new preview release of .Net 6 and beyond will be available on App Service on DAY 0 of it’s release.
+
+
This is a first for the App Service platform and was achieved through a new Early Access feature (learn more about App Service Early Access). App Service Early Access was developed in close cooperation with the .NET team and we are very excited to have .NET 5 GA release be the first runtime deliver through this feature.
+
+
While we are starting with .NET 5 early access we plan to use the Early Access mechanism to deliver faster and more frequent updates for all the App Service supported languages including Node and Python and others.
+
+
If you want to learn more, be sure to checkout our session during .NET Conf 2020 where we’ll talk about how to modernize .NET Framework Apps, by migrating to App Service and 5 ways to get started with .NET 5 on App Service.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
We are happy to announce that App Service now supports .NET 5 applications across all public regions and scenarios on both Windows and Linux App Service plans.
+
Azure App Service and Azure Functions on Azure Stack Hub 2020 Q3 Released
+
+
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Andrew Westgarth
+
+ • November 12, 2020
+
+
+
+
+
+
+
The 2020 Q3 update to Azure App Service on Azure Stack Hub is now available. This release updates the resource provider and brings the following key capabilities and fixes:
+
+
+
Updates to App Service Tenant, Admin, Functions portals and Kudu tools. Consistent with Azure Stack Portal SDK version.
+
Updates Azure Functions runtime to v1.0.13154.
+
Updates to core service to improve reliability and error messaging enabling easier diagnosis of common issues.
+
Updates to the following application frameworks and tools:
+
+
ASP.NET Core 2.1.22
+
ASP.NET Core 2.2.14
+
ASP.NET Core 3.1.8
+
ASP.NET Core Module v2 13.1.19331.0
+
Azul OpenJDK
+
+
8.42.0.23
+
8.44.0.11
+
11.35.15
+
11.37.17
+
+
+
Curl 7.55.1
+
Git for Windows 2.28.0.1
+
MSDeploy 3.5.90702.36
+
NodeJS
+
+
14.10.1
+
+
+
NPM
+
+
6.14.8
+
+
+
PHP 7.4.5
+
Tomcat
+
+
8.5.47
+
8.5.51
+
9.0.273
+
9.0.31
+
+
+
Updated Kudu to 90.21005.4823
+
+
+
Updates to underlying operating system of all roles:
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Andrew Westgarth
+
+ • November 12, 2020
+
+
+
The 2020 Q3 update to Azure App Service on Azure Stack Hub is now available. This release updates the resource provider and brings the following key capabili...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Christina Compy
+
+ • November 15, 2020
+
+
+
The Azure App Service has quite a few networking integration capabilities but, until now, did not support a dedicated outbound address. We are very happy to ...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Christina Compy
+
+ • November 15, 2020
+
+
+
+
+
+
+
The Azure App Service has quite a few networking integration capabilities but, until now, did not support a dedicated outbound address. We are very happy to say that now you can use a NAT Gateway with your web app in the Azure App Service.
+
+
The NAT Gateway solves another problem beyond providing a dedicated internet address. You can also now have 64k outbound SNAT ports usable by your apps. One of the challenges in the App Service is the limit on the number of connections you can have to the same address and port. There are more details on this problem in the Troubleshooting intermittent outbound connection errors guide.
Route all the outbound traffic into your Azure virtual network
+
Provision a NAT Gateway in the same virtual network and configure it with the subnet used for VNet Integration
+
+
+
+
+
After these changes have been made, the calls made by your app to the internet will go out the NAT Gateway. You can alternatively use an Azure Firewall if you want to control egress by FQDN but it won’t give you the 64k outbound SNAT ports.
+
+
To use a NAT Gateway you need to use Regional VNet Integration. To use Regional VNet Integration your app needs to be in a Standard, Premium V2 or Premium V3 App Service plan. This feature will work with Function apps as well as web or API apps. There are some Standard App Service plans that can’t use Regional VNet Integration as they are in older App Service deployments.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Hosting .NET 5 Applications on Azure App Service
+
+
+
+
+
+
+
+
+ 9 minute read
+
+
+
+ • By Jeff Martinez
+
+ • November 16, 2020
+
+
+
+
+
+
+
+
+
With the newly announced launch of .NET 5 General Availability, App Service is offering immediate support for .NET 5 via Early Access stack. The new Early Access stack feature on app service enables faster and more frequent updates for new versions of supported languages. To learn more about Early Access, please visit the Early Access Runtime document. .NET 5 (Early Access) applications are supported across all public regions for both Windows and Linux scenarios. The following outlines how you can use .NET 5 with App Service via the Azure Portal, GitHub Actions, Azure DevOps, and custom containers.
+
+
+
For Sovereign cloud deployment progress, follow this GitHub issue for periodic updates
+
+
+
Local Setup
+
In order to develop with .NET 5 locally you will first need the newly released .NET 5 SDK . If you are using Visual Studio you will need to download and use the latest Visual Studio 2019 version(16.8) which will allow you to create a .NET 5 application from the Visual Studio UI and publish your code to your web app.
+
+
+
+
+
If you would like to upgrade an existing project to .NET 5, please see this announcement to get started.
+
+
+
Create a .NET 5 Web App in the Portal
+
The first option you must create and deploy a .NET 5 application is directly through the portal for both Windows and Linux apps. You will create a Web App like you normally would (see our Quickstart for details).
+
+
When selecting the runtime stack you will see an option to choose .NET 5 (Early Access).
+
+
+
+
Choose this option when creating your application, review your web app configuration and create the .NET 5 web app. When your web app is published you are now ready to deploy code to your application through Visual Studio or with continuous deployment via GitHub Actions and Azure DevOps. If deploying with Visual Studio using right-click Publish, you’ll need to create the web app in the portal first using the directions above. Full support with Visual Studio will be available by the end of the month.
+
+
Deploying via CLI
+
Another option to create a Web App with a .NET 5 runtime is through the Azure CLI with the az webapp create and az webapp up commands. Before you run these commands, make sure you are up to date on the most recent version of the Azure CLI first.
+
+
+
Once you are on the latest version, you can run az webapp list-runtimes -linux or az webapp list-runtimes (for windows) and you will find “DOTNET|5.0” in the list of available runtimes.
+
+
Next run the follwing command to create a web app with a .NET 5 runtime.
Verify that your web app was created on the Azure portal
+
+
+
You may also use the az webapp up command to deploy to App Service, which allows you to deploy your code quickly from a local workspace where the code is present.
+
+
Use the az login command to login into Azure
+
+
Go to the source of where your code is and run the command where your code is located (for .NET apps, this is where the .csproj is located).
+
+
az webapp up -n myUniqueAppName
+
+
+
+
+
This will deploy your .NET 5 application directly to App Service. For more arguments and examples of az webapp up, please see the documentation.
+
+
Continuous deployment with GitHub Actions
+
GitHub Actions enables you to automate your deployment workflows through a defined YAML file added to your repository containing a collection of actions that run when triggered. Before the workflow file is setup, you will need to grab azure credentials by creating a service principal and save them as a secret in GitHub to add to your workflow file.
+
+
+
If you would like to setup GitHub Actions through the App Service Deployment Center to automatically generate a workflow file, see our documentation.
+
+
+
Create a Service Principal
+
Our workflow will use a Service Principal to authenticate with Azure when deploying the container to App Service. A service principal is an Active Directory Identity created for use with automation scenarios, such as GitHub Actions.
+
+
+
+
Run the following command in Azure CLI in PowerShell to get the credentials needed to run the login action. The output of this command will be a collection of key value pairs that you’ll need to add to your GitHub secrets.
+
+
az ad sp create-for-rbac --name"<appservice-name>"--role contributor \
+ --scopes /subscriptions/{subscription-id}/resourceGroups/{resource-group}\
+ --sdk-auth
+
+
+
+
Copy the output into your GitHub secrets to use as your AZURE_CREDENTIALS secret.
Since we are using sensitive information that you don’t want others to access, we will use GitHub secrets to protect our information. Create a secret by following the directions here. Add the GitHub secrets variables below with your own secrets appropriate from each resource.
+
+
+
AZURE_WEBAPP_NAME: web-app-name
+
AZURE_CREDENTIALS: the JSON output of the az ad sp create-for-rbac command
+
+
+
Setup Workflow file
+
To setup your GitHub workflow file, go to the Actions tab in your repository and set up a workflow yourself. This will lead you to an editing page where you can add a workflow. At this point you can save and commit the code. Remove the default code in the workflow file and replace it with the yaml sample below.
+
+
name:.NET Core
+on:[push]
+env:
+ AZURE_WEBAPP_PACKAGE_PATH:'.'# set this to the path to your web app project, defaults to the repository root
+ DOTNET_VERSION:'5.0.100'# this is set to the GA version of .NET 5
+jobs:
+ build:
+ runs-on:windows-latest
+ steps:
+ # Checkout the repo
+ -uses:actions/checkout@master
+ -uses:azure/login@v1
+ with:
+ creds:$
+
+ # Setup .NET Core SDK
+ -name:Setup .NET Core
+ uses:actions/setup-dotnet@v1
+ with:
+ dotnet-version:$
+
+ # Run dotnet build and publish
+ -name:dotnet build and publish
+ run:|
+ dotnet restore
+ dotnet build --configuration Release
+ dotnet publish -c Release -o '$/myapp'
+
+ # Deploy to Azure Web apps
+ -name:'RunAzurewebappdeployactionusingazurecredentials'
+ uses:azure/webapps-deploy@v2
+ with:
+ app-name:$# Replace with your app name
+ package:'$/myapp'
+
+ -name:logout
+ run:|
+ az logout
+
+
+
Before you save and commit the code you will need to adjust the ‘runs-on:’ argument to either ‘windows-latest’ or ‘ubuntu-latest’ depending on your application. Once that is done you can hit Save and commit. The workflow file will use the secret you created earlier from ‘secrets.AZURE_CREDENTIALS’ and secrets.AZURE_WEBAPP_NAME’ to run the actions and deploy your code. Verify that it has deployed by going to your Web App in the Azure Portal and launching your application.
+
+
Continuous deployment with Azure DevOps
+
Azure DevOps is another option for deploying your code with continuous deployment to your .NET 5 Web App enabling you to host, build, plan and test your code through Azure Pipelines. To get started, you will need to first Create a new project and Import a Git repo. Once you have your code uploaded to your DevOps project, you can start building your Pipeline to deploy to your Web App.
+
+
+
Go to Pipelines in the left menu and click the Create Pipeline button on the following page
+
Connect to your Azure Repos Git, Select your repository and Configure your pipeline choosing the ASP.NET option. Azure DevOps will suggest a pipeline configuration, but we will be replacing it with the example below
+
+
After the above step you will be taken to the Review tab. Replace the suggested code with the template below:
+
+
If you are using Windows, replace the vmImage: value with windows-latest
+
+
trigger:
+ -master
+
+ pool:
+ vmImage:'ubuntu-latest'
+
+ variables:
+ buildConfiguration:'Release'
+
+ steps:
+ -task:UseDotNet@2
+ inputs:
+ packageType:'sdk'
+ version:'5.0.100'
+ includePreviewVersions:true
+
+ -task:DotNetCoreCLI@2
+ displayName:Build
+ inputs:
+ command:build
+ projects:'**/*.csproj'
+ arguments:'--configuration$(buildConfiguration)'# Update this to match your need)'
+
+ -task:DotNetCoreCLI@2
+ inputs:
+ command:publish
+ publishWebProjects:True
+ arguments:'--configuration$(BuildConfiguration)--output$(Build.ArtifactStagingDirectory)'
+ zipAfterPublish:True
+
+ # this code takes all the files in $(Build.ArtifactStagingDirectory) and uploads them as an artifact of your build.
+ -task:PublishBuildArtifacts@1
+ inputs:
+ pathtoPublish:'$(Build.ArtifactStagingDirectory)'
+ artifactName:'myWebsiteName'
+
+
+
Now Save and run your build pipeline. This will build your application and create an artifact that will be used for your release pipeline. After the run, you can create your release pipeline.
+
Go to Releases in the left menu area and click the New Pipeline button on the following page
+
Next, select the Azure App Service deployment template and hit Apply
+
+
In the following page, select the +Add an artifact box on the left to add the artifact we previously created in the Build pipeline
+
+
+
+
Choose your Source(build pipeline) and hit the Add button
+
Once that is set you’ll want to setup the trigger by clicking the lightning bolt icon in the top right of your artifact
+
+
A new window will pop up. Switch the Continuous deployment trigger to Enabled and close the window
+
+
+
+
Next, you can click on the 1 job, 1 task link to setup your deployment stage
+
Fill in your Parameters under “Stage 1”
+
+
Azure subscription: your azure subscription
+
App type: Web App on Linux OR Web App on Windows
+
App service name: your App Service name
+
+
+
After your “Stage 1” parameters are filled in, click the Run on agent box and modify the Agent Specification to run the appropriate ubuntu or windows agent
+
Now you can click the Deploy Azure App Service box and review the pre-filled parameters. Update any parameters if needed
+
Click on the Save icon on the top right menu
+
Click OK for the folder location and Create release
+
+
Select the “Stage 1” trigger from the drop down menu and click Create
+
+
+
+
Once the release is created it will be named “Release-1” and you will be able to see a similar screen as above. Click Deploy under the Stage 1 and Deploy again on the next screen to start your deployment to your Azure App Service Web App.
+
Verify that your application has been published by launching your Web App in the Azure Portal.
+
+
+
Container Deployment with .NET 5
+
.NET 5 applications are easily deployable to a custom container on App Service using Linux or Windows. When deploying a container, you are packaging the application and its dependencies into a Linux or Windows based image to run on the App Service platform enabling your application to be more portable.
+
+
The steps for containerizing a .NET 5 application are the same as it would be for other applications.
+
+
Right-click your project
+
Add -> Docker Support
+
+
+
Your .NET 5 project will have a new Dockerfile added with the .NET 5.0 base image and SDK ready for you to publish.
If you are using Windows your base image will be FROM mcr.microsoft.com/dotnet/aspnet:5.0 AS base using the FROM mcr.microsoft.com/dotnet/sdk:5.0 AS build SDK.
+
+
For Linux applications, your base image will be FROM mcr.microsoft.com/dotnet/aspnet:5.0-buster-slim AS base using the FROM mcr.microsoft.com/dotnet/sdk:5.0-buster-slim AS build SDK.
+
+
FROMmcr.microsoft.com/dotnet/aspnet:5.0ASbase # For Windows apps
+# FROM mcr.microsoft.com/dotnet/aspnet:5.0-buster-slim AS base # For Linux apps
+WORKDIR /app
+EXPOSE 80
+EXPOSE 443
+
+FROMmcr.microsoft.com/dotnet/sdk:5.0ASbuild # For Windows apps
+# FROM mcr.microsoft.com/dotnet/sdk:5.0-buster-slim AS build # For Linux apps
+WORKDIR /src
+COPY ["dotnet5app/dotnet5app.csproj", "dotnet5app/"]
+RUN dotnet restore "dotnet5app/dotnet5app.csproj"
+COPY . .
+WORKDIR "/src/dotnet5containerwindows"
+RUN dotnet build "dotnet5app.csproj"-c Release -o /app/build
+
+FROMbuildASpublish
+RUN dotnet publish "dotnet5app.csproj"-c Release -o /app/publish
+
+FROMbaseASfinal
+WORKDIR /app
+COPY --from=publish /app/publish .
+ENTRYPOINT ["dotnet", "dotnet5app.dll"]
+
+
+
After you have added Docker support, you will publish it to a registry, and create your App Service as usual. See our documentation for more detail on deploying a containerized application.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 9 minute read
+
+
+
+ • By Jeff Martinez
+
+ • November 16, 2020
+
+
+
With the newly announced launch of .NET 5 General Availability, App Service is offering immediate support for .NET 5 via Early Access stack. The new Early A...
+
+
+
+
+
+
+ 2 minute read
+
+
+
+ • By Christina Compy
+
+ • November 18, 2020
+
+
+
+
+
+
+
We are happy to announce the public preview of the App Service Environment v3 (ASEv3). The ASEv3 project is a realization of several years of infrastructure development to enable a best in class Isolated application hosting PaaS service. This release has been driven directly by customer feedback and satisfies multiple situations that were not covered by ASEv2.
+
+
The App Service Environment (ASE) is a single tenant instance of the Azure App Service that injects into a customers Azure Virtual Network (VNet). Until now, the ASE has required many networking dependencies that must be allowed in the customer VNet in order for the ASE to operate properly. ASEv3 has several major changes in the system architecture that serve to remove all management traffic from the customer VNet. The end result is a single tenant system that has no internet hosted dependencies in the customer network. Customers can secure their workloads to their heart’s content without hurting the ASE and Microsoft can secure the infrastructure without hurting customer workloads. This system enables both parties to apply all of the security they want to without affecting each other.
+
+
The pricing for ASEv3 is changed from ASEv2. With ASEv3 you just pay for the Isolated V2 SKU rates for your App Service plans. There is no stamp fee. If your ASEv3 is totally empty, you are charged as if you had one App Service plan with one instance of I1v2. The hosts used in ASEv3 are the same type used with Premium V3. The size options in ASEv3 are: 2 core 8 GB RAM, 4 core 16 GB RAM, 8 core 32 GB RAM.
+
+
With respect to networking dependencies it should be reiterated that there are no required Network Security Groups, no required route tables and no required service endpoints. You can route and filter things with an eye centered on just what your apps need. If you want to configure your apps to force tunnel all outbound traffic on-premises, you can do so. If you want to send all outbound traffic through an NVA, no problem. And if you want to put a WAF device to monitor all inbound traffic to your ASEv3, you can add that without any limitations.
+
+
+
+
There are a number of limitations as this preview starts off. Some features that are available in ASEv2 are not available in the current form of ASEv3. Missing features will be added as the preview goes on. To get a more complete overview on ASEv3, read the ASEv3 focused App Service Environment overview. If you want to create a new ASEv3, read Creating an App Service Environment v3.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 2 minute read
+
+
+
+ • By Christina Compy
+
+ • November 18, 2020
+
+
+
We are happy to announce the public preview of the App Service Environment v3 (ASEv3). The ASEv3 project is a realization of several years of infrastructure ...
+
+
+
+
+
+
+ 2 minute read
+
+
+
+ • By Christina Compy
+
+ • November 18, 2020
+
+
+
We are happy to announce the public preview of the App Service Environment v3 (ASEv3). The ASEv3 project is a realization of several years of infrastructure ...
+
+
+
+
+
+
+ 9 minute read
+
+
+
+ • By Jeff Martinez
+
+ • November 16, 2020
+
+
+
With the newly announced launch of .NET 5 General Availability, App Service is offering immediate support for .NET 5 via Early Access stack. The new Early A...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Christina Compy
+
+ • November 15, 2020
+
+
+
The Azure App Service has quite a few networking integration capabilities but, until now, did not support a dedicated outbound address. We are very happy to ...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Andrew Westgarth
+
+ • November 12, 2020
+
+
+
The 2020 Q3 update to Azure App Service on Azure Stack Hub is now available. This release updates the resource provider and brings the following key capabili...
We are happy to announce that App Service now supports .NET 5 applications across all public regions and scenarios on both Windows and Linux App Service plans.
+
New App Service Anti-virus Logs in Public Preview
+
+
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Yutang Lin
+
+ • December 9, 2020
+
+
+
+
+
+
+
+
+
App Service has added support for anti-virus scans which can send logs to a Storage account, Log Analytics workspace, and Even Hubs for better application monitoring. The new log support, available in Diagnostic settings as “AppServiceAntivirusScanAuditLogs”, helps customers better monitor the site content of their web app. This logging feature is available for both Windows and Linux based web apps using our Premium App Service plans. This feature is currently in public preview and has certain feature limitations and known issues which will be covered in this blog and will be updated accordingly.
+
+
The anti-virus scan leverages Microsoft Defender and will run once daily on your website content. There will be a log regardless of if there are any infected files detected. If there are infected files detected, the log will provide a list of infected files. If there are no infected files detected, the log will show an empty list of infected files.
+
+
Feature Limitations
+
+
The feature has a few limitations (see list below). Should you meet any of the limitations, the logs will show an error message explaining why it didn’t scan your web app. The following limitations are:
+
+
+
Will scan your files once a day (currently can’t control when the scan runs)
+
Will not scan web apps with more than 1GB of site content
+
Will not scan web apps with more than 10,000 files in the site content
+
+
+
If your web app has more than 1GB of content or more than 10,000 files the scan will not run and your logs will show an error message explaining that the pre-requisite was not met.
+
+
Known Issues
+
+
For web apps with more than 10,000 files you will see the following error message in your logs: “Internal service error occurred. Please contact support.”. In the next release, the logs will reflect the correct error message.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Yutang Lin
+
+ • December 9, 2020
+
+
+
App Service has added support for anti-virus scans which can send logs to a Storage account, Log Analytics workspace, and Even Hubs for better application mo...
+
+
+
+
+
+
+ 7 minute read
+
+
+
+ • By Jason Freeberg
+
+ • December 11, 2020
+
+
+
+
+
+
+
+
+
GitHub announced CI/CD support through GitHub Actions which became generally available at GitHub Universe in November 2019. Since then, many Azure services have released actions and integrations to make developers’ workflows more efficient. The App Service Deployment Center guides developers to set up GitHub Actions to deploy their web apps. Since then, our teams have received requests for guidance and best practices when setting up CI/CD (Continuous Integration and Delivery) for deploying Python apps to App Service.
+
+
+
This article assumes you are familiar with CI/CD pipelines. If you are not familiar, read this article for an overview.
+
+
+
Building and deploying Python apps
+
+
A simple CI pipeline for a Python application might have three steps: pip install the packages, run tests, and send the application to the server. This seems like a sound approach… right? That pattern might work for simple applications, but if the application uses packages that rely on the Operating System (such as database drivers, scipy, or scikit-learn), you may run into problems once the application starts on the server. This is because Python will make absolute references to the OS libraries, and if there are any differences between the libraries installed on the CI machine and the server, then the application will not run correctly.
+
+
This may seem like an excellent opportunity to leverage Docker. With Docker, you can build a container image with the Python application’s dependencies already installed. From there, you ship the image to a host with Docker installed and “just run it”. However, this option is not without its drawbacks. You will need to manage a container registry and configure your network such that the CI and production servers can securely access it. The Dockerfile also becomes part of the application repository, so you or your team will be responsible for updating the base OS and configuring the container. Fun fact: Docker was publicly announced at PyCon in 2013
+
+
Nylas wrote an excellent article on this topic last year. Their article covers even more deployment technologies for Python applications. Check their article to learn about your other options. Now let’s learn more about deploying Python applications to App Service without managing Docker images.
+
+
Deploying to App Service
+
+
For those not familiar with Azure App Service, it is a platform-as-a-service (PaaS) for hosting web and API applications. You can deploy your application code or a container image. The service has managed runtimes for Python, .NET, Node, Java, PHP, and Ruby. This gives developers the choice to use containers or to simply deploy their code and let the service manage the runtime for them.
+
+
If you are setting up a CI/CD pipeline for your Python apps to App Service without using containers, you cannot simply pip install and deploy your app and packages to App Service (or any server) because the OS on your build server will most likely not match the runtime on Azure. To address this, simply create an app setting on your App Service named SCM_DO_BUILD_DURING_DEPLOYMENT with a value of true. This app setting will trigger the Oryx build pipeline to re-install your packages during deployment. Oryx is an open-source utility by Microsoft that automatically builds source code. Oryx runs in your web app’s SCM (site control manager) site. By setting this app setting, Oryx will pip install your dependencies on the runtime image so that the packages can take the appropriate dependencies on the OS libraries.
+
+
Examples
+
+
The sections below show example GitHub Actions workflows for building and deploying Python apps to App Service. Although the samples use GitHub Actions, you can use the same pattern on other CI/CD providers such as Azure DevOps or Jenkins.
+
+
Prerequisites
+
+
Before following the examples below, make sure you have done the following.
Create an Azure Service Principal. Follow this guide to create a Service Principal. A Service Principal is an identity in Azure Active Directory that is typically used for automation and accessing secrets. You will need to create a Service Principal so the GitHub Actions workflow
Once the virtual environment is activated, the dependencies are installed from the requirements.txt file. Next, we use manage.py to collect the static assets and run our unit tests.
Assuming all those previous steps succeed, the files are uploaded for the next job. The virtual environment is not uploaded since it is not compatible with the runtime OS. A nice side-effect of uploading the files at the end of the job is that you can download the files from the Actions tab to debug or inspect the contents if a deployment fails.
+
+
-name:Upload artifact for deployment jobs
+ uses:actions/upload-artifact@v2
+ with:
+ name:python-app
+ path:|
+ .
+ !venv/
+
+
+
The second job begins by downloading the files we uploaded in the previous job, then logs into the Azure CLI using a Service Principal that you set as a secret earlier.
Once the Azure CLI is authenticated, the job sets the SCM_DO_BUILD_DURING_DEPLOYMENT setting mentioned earlier. It also sets app settings to disable static collection (since that was done in the previous job), to run migrations on the database, and to set the Django environment to “production”. The POST_BUILD_COMMAND is a hook where you can execute commands following the runtime build. In this case, we’re running manage.py makemigrations && python migrate. You could apply database migrations as part of the CI workflow, but you would need to set the connection string as a secret, and if you have networking rules securing your database you will need to make the database accessible from the CI pipeline. In this case, migration will be applied from the Django app on App Service, so this assumes you have set the database credentials on the web app.
-name:Disable static collection and set migration command on App Service
+ uses:Azure/appservice-settings@v1
+ with:
+ app-name:${{ env.WEBAPP_NAME }}
+ app-settings-json:'[{"name":"DISABLE_COLLECTSTATIC","value":"true"},{"name":"POST_BUILD_COMMAND","value":"pythonmanage.pymakemigrations&&pythonmanage.pymigrate"},{"name":"SCM_DO_BUILD_DURING_DEPLOYMENT","value":"true"},{"name":"DJANGO_ENV","value":"production"}]'
+
+-name:Deploy to App Service
+ uses:azure/webapps-deploy@v2
+ with:
+ app-name:${{ env.WEBAPP_NAME}}
+
+
+
+
By default, the appservice-settings action will mask the inputs and obfuscate any occurences of those strings in logs. Set mask-inputs: false to disable this.
This workflow begins similarly to the Django example by setting the Python version, creating a virtual environment, and installing the Python packages. Unique to this example, it also sets Node.js to the desired version since the job will need to install the Vue project’s dependencies and build it.
Once the Flask and Vue.js apps are built and tested the files are uploaded for the second job… except for the node_modules/ and venv/ directories. We want to exclude these directories and allow Oryx to install the dependencies on the runtime image like in the Django example.
+
+
-name:Upload artifact for deployment jobs
+ uses:actions/upload-artifact@v2
+ with:
+ name:python-app
+ path:|
+ .
+ !node_modules/
+ !venv/
+
+
+
The second job downloads the artifact, logs into the Azure CLI, and sets the SCM_DO_BUILD_DURING_DEPLOYMENT flag and FLASK_ENV to “production”. Unlike the Django example, the workflow sets the “startup-file” command to gunicorn --bind=0.0.0.0 --timeout 600 app:app. (Gunicorn is a WSGI HTTP Server commonly used for Python applications. Learn more about custom startup commands on App Service.
+
+
-uses:actions/download-artifact@v2
+ with:
+ name:python-app
+ path:.
+
+-name:Log in to Azure CLI
+ uses:azure/login@v1
+ with:
+ creds:${{ secrets.AZURE_SERVICE_PRINCIPAL }}
+
+-name:Configure deployment and runtime settings on the webapp
+ run:|
+ az configure --defaults ${{ env.RESOURCE_GROUP }}
+ az webapp config appsettings --name ${{ env.WEBAPP_NAME }} --settings \
+ SCM_DO_BUILD_DURING_DEPLOYMENT=true \
+ FLASK_ENV=production
+
+ az webapp config set --name ${{ env.WEBAPP_NAME }} \
+ --startup-file "gunicorn --bind=0.0.0.0 --timeout 600 app:app"
+
+
+
Finally, the application is deployed with the webapps-deploy action.
+
+
-name:Deploy to App Service
+ uses:azure/webapps-deploy@v2
+ with:
+ app-name:${{ env.WEBAPP_NAME}}
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 7 minute read
+
+
+
+ • By Jason Freeberg
+
+ • December 11, 2020
+
+
+
GitHub announced CI/CD support through GitHub Actions which became generally available at GitHub Universe in November 2019. Since then, many Azure services h...
+
+
+
+
+
+
+ 7 minute read
+
+
+
+ • By Jason Freeberg
+
+ • December 11, 2020
+
+
+
GitHub announced CI/CD support through GitHub Actions which became generally available at GitHub Universe in November 2019. Since then, many Azure services h...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Yutang Lin
+
+ • December 9, 2020
+
+
+
App Service has added support for anti-virus scans which can send logs to a Storage account, Log Analytics workspace, and Even Hubs for better application mo...
+
+
+
+
+
+
+ 7 minute read
+
+
+
+ • By Jason Freeberg
+
+ • December 11, 2020
+
+
+
GitHub announced CI/CD support through GitHub Actions which became generally available at GitHub Universe in November 2019. Since then, many Azure services h...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Yutang Lin
+
+ • December 9, 2020
+
+
+
App Service has added support for anti-virus scans which can send logs to a Storage account, Log Analytics workspace, and Even Hubs for better application mo...
+
+
+
+
+
+
+ 2 minute read
+
+
+
+ • By Christina Compy
+
+ • November 18, 2020
+
+
+
We are happy to announce the public preview of the App Service Environment v3 (ASEv3). The ASEv3 project is a realization of several years of infrastructure ...
+
+
+
+
+
+
+ 9 minute read
+
+
+
+ • By Jeff Martinez
+
+ • November 16, 2020
+
+
+
With the newly announced launch of .NET 5 General Availability, App Service is offering immediate support for .NET 5 via Early Access stack. The new Early A...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Christina Compy
+
+ • November 15, 2020
+
+
+
The Azure App Service has quite a few networking integration capabilities but, until now, did not support a dedicated outbound address. We are very happy to ...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Andrew Westgarth
+
+ • November 12, 2020
+
+
+
The 2020 Q3 update to Azure App Service on Azure Stack Hub is now available. This release updates the resource provider and brings the following key capabili...
We are happy to announce that App Service now supports .NET 5 applications across all public regions and scenarios on both Windows and Linux App Service plans.
+
+
+
+
+
+
+
+ 4 minute read
+
+
+
+ • By Jason Freeberg and Shubham Dhond
+
+ • October 20, 2020
+
+
+
This is the third article in our guide for A/B testing with App Service. The first article shows how to set up your client-side project. The second article s...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Jeff Martinez
+
+ • October 15, 2020
+
+
+
Starting November 1st, 2020. Docker will be introducing rate limits on unauthenticated pull requests from Docker Hub. These limits are based on the account ...
+
+
+
+
+
+
+ 2 minute read
+
+
+
+ • By Eric Grenon
+
+ • October 6, 2020
+
+
+
We are happy to announce Private Endpoint for Web App is now Generally Available in all Azure public regions, for both Windows and Linux apps, containerized ...
This is part one of our deep dive on Diagnosing CPU utilization issues in Azure App Service. In this post, you will learn about measuring CPU utilization for...
+
+
+
+
+
+
+ 5 minute read
+
+
+
+ • By Christina Compy
+
+ • October 5, 2020
+
+
+
The Azure App Service is offered as two deployment types: the multi-tenant service and the App Service Environment. In the multi-tenant service there are tho...
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Jeff Martinez
+
+ • October 2, 2020
+
+
+
The Premium v3 hardware tier, previously announced at Microsoft Ignite 2020, is now available for you to deploy your applications to. This new hardware tier...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Jeff Martinez
+
+ • September 29, 2020
+
+
+
Windows containers on App Service enable you to modernize your Windows applications so you can bring along dependencies or lift-and-shift your current applic...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Jason Freeberg, Mitren Chinoy, Byron Tardif
+
+ • September 23, 2020
+
+
+
The first version of the App Service Deployment Center has been generally available since late 2018. The Deployment Center gives a centralized view of all th...
+
+
+
+
+
+
+ 2 minute read
+
+
+
+ • By Christina Compy and Jason Freeberg
+
+ • September 22, 2020
+
+
+
For several years, Red Hat and Microsoft have partnered to create cloud solutions that enable enterprises to achieve more. Today, we are happy to announce th...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Christina Compy
+
+ • September 22, 2020
+
+
+
The App Service Environment v3 (ASEv3) project is a realization of several years of infrastructure development to enable a best-in-class, network isolated ap...
ASP.NET Framework has fusion Assembly Binding logging (aka Fusion Logging) which allows you to debug assembly load failures in your .NET applications. Fusion...
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Yutang Lin
+
+ • August 31, 2020
+
+
+
We have added a new log type for ASP .NET web apps on Windows (ASP .NET Core support is not yet supported). The log type, AppServiceAppLogs, captures your ap...
+
+
+
+
+
+
+ 2 minute read
+
+
+
+ • By Jason Freeberg and Suwat Bodin
+
+ • August 24, 2020
+
+
+
App Service makes it easy to automatically scale your apps to multiple instances when traffic increases. This increases your app’s throughput, but what if th...
+
+
+
+
+
+
+ 4 minute read
+
+
+
+ • By Jason Freeberg and Shubham Dhond
+
+ • August 24, 2020
+
+
+
This is the second article in our guide for A/B testing with App Service. See the first article for more information about A/B testing and how to set up your...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Jason Freeberg and Mitren Chinoy
+
+ • August 19, 2020
+
+
+
A year ago we announced a GitHub Action to deploy your web apps to Azure App Service. In April, we added GitHub Actions as an option in the Deployment Center...
Netflix Eureka is a REST based middleware designed for discovery and load balancing of web applications. For those who already have a Netflix Eureka app, thi...
+
+
+
+
+
+
+ 6 minute read
+
+
+
+ • By Christina Compy
+
+ • August 14, 2020
+
+
+
The Azure App Service is offered as two deployment types: the multi-tenant service and the App Service Environment. In the multi-tenant service there are tho...
Application crashes happen. A crash is when an exception in your code goes un-handled and terminates the process. These unhandled exceptions are also known a...
+
+
+
+
+
+
+ 4 minute read
+
+
+
+ • By Jason Freeberg and Shubham Dhond
+
+ • August 10, 2020
+
+
+
App Service provides access for FTP and WebDeploy clients to connect using the basic auth credentials found in the site’s publish profile. These APIs are gre...
+
+
+
+
+
+
+ 8 minute read
+
+
+
+ • By Jason Freeberg, Shubham Dhond
+
+ • August 3, 2020
+
+
+
In software development, A/B testing is the process of comparing two versions of a webpage or application to determine which version improves a metric or KPI...
In this installment of Zero to Hero with App Service, learn how to migrate your existing applications to App Service. If you followed parts one, two, and thr...
+
+
+
+
+
+
+ 2 minute read
+
+
+
+ • By Yutang Lin
+
+ • July 14, 2020
+
+
+
If you have received a notification from Azure about potentially being impacted by the certificate revocation issue, follow these steps to avoid application ...
+
+
+
+
+
+
+ 4 minute read
+
+
+
+ • By Jason Freeberg
+
+ • July 7, 2020
+
+
+
+ This is the third article in the Zero to Hero with App Service series. This article assumes you have already completed the previous two articles.
+
+
+
+
+
+
+
+
+ 5 minute read
+
+
+
+ • By Jason Freeberg
+
+ • June 29, 2020
+
+
+
This is the second article in our Zero to Hero with App Service series. This article assumes you have completed Part 1. In the last article you created an Ap...
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Jason Freeberg
+
+ • June 29, 2020
+
+
+
In times of rapid change, developers and IT decision-makers must quickly adjust to a drastically evolving landscape. Successful organizations use managed clo...
+
+
+
+
+
+
+ 12 minute read
+
+
+
+ • By Jeff Martinez
+
+ • June 25, 2020
+
+
+
Azure DevOps enables you to host, build, plan and test your code with complimentary workflows. Using Azure Pipelines as one of these workflows allows you to ...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Christina Compy
+
+ • June 17, 2020
+
+
+
Regional VNet Integration is now Generally Available for both Linux and Windows apps. The feature behaves the same for apps on either operating system. This ...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Christina Compy
+
+ • June 17, 2020
+
+
+
We are happy to announce Hybrid Connections for Linux apps is now Generally Available. Hybrid Connections have been available for Windows apps for a few year...
+
+
+
+
+
+
+ 11 minute read
+
+
+
+ • By Jeff Martinez
+
+ • June 9, 2020
+
+
+
Github Actions enables you to easily automate any part of your development workflow. GitHub Actions are defined as YAML files in the .github/workflows direct...
+
+
+
+
+
+
+ 2 minute read
+
+
+
+ • By Jason Freeberg
+
+ • May 19, 2020
+
+
+
This year, Microsoft Build is entirely online. Live and pre-recorded sessions are available for anyone to view. This article is a recap of the sessions from ...
Modern-day data centers are extremely complex and have many moving parts. VMs can restart or move, systems are upgraded, and file servers are scaled up and d...
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Jason Freeberg, Yutang Lin
+
+ • May 11, 2020
+
+
+
We are happy to announce the Public Preview of App Service’s integration with Azure Event Grid. Event Grid is a publish/subscribe messaging service that allo...
+
+
+
+
+
+
+ 2 minute read
+
+
+
+ • By Andrew Westgarth
+
+ • May 6, 2020
+
+
+
We have released the 2020 Q2 update to Azure App Service on Azure Stack Hub. This release updates the resource provider and brings the following key capabili...
+
+
+
+
+
+
+ 2 minute read
+
+
+
+ • By Mike Budzynski, Jason Freeberg
+
+ • May 1, 2020
+
+
+
In times of rapid change, developers and IT decision-makers must quickly adjust to a drastically evolving landscape. Successful organizations use managed clo...
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Jeff Martinez
+
+ • April 24, 2020
+
+
+
.NET 5 is the latest version to expand the capabilities of .NET by taking the best of Core, Framework, Xamarin, and Mono to create a unified platform for imp...
App Services Diagnostics is a powerful tool that allows you to troubleshoot and mitigate issues within your application. The rich set of tools under the App ...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Jeff Martinez
+
+ • April 16, 2020
+
+
+
App Service is announcing GA of .NET Core 3.1 LTS on Linux & Windows today. If you are running .NET Core 3.0 applications, which had its end-of-life dat...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Jason Freeberg
+
+ • April 14, 2020
+
+
+
Last year we shared an article that demonstrated how to deploy your application to App Service using GitHub Actions. We are excited to share that we have add...
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Christina Compy
+
+ • March 23, 2020
+
+
+
The PremiumV2 hardware tier is now available for older deployments of App Service where it was not previously available. A few years ago Azure App Service be...
+
+
+
+
+
+
+ 2 minute read
+
+
+
+ • By Christina Compy
+
+ • March 16, 2020
+
+
+
We are happy to announce the public preview of Private Link for Azure App Service. This preview is available in limited regions for all PremiumV2 Windows and...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Christina Compy
+
+ • February 27, 2020
+
+
+
App Service customers often need to access resources in their Azure Virtual Networks. We launched VNet Integration to address this issue in 2014, but our cus...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Jason Freeberg
+
+ • January 31, 2020
+
+
+
Wildfly is an open-source application runtime for Java applications, and the upstream project of JBoss EAP. We recently added a new Azure Sample that shows h...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Andrew Westgarth
+
+ • January 13, 2020
+
+
+
This afternoon we released the eighth update to Azure App Service on Azure Stack Hub. This release updates the resource provider and brings the following key...
+
+
+
+
+
+
+ 5 minute read
+
+
+
+ • By Jason Freeberg
+
+ • January 4, 2021
+
+
+
+
+
+
+
+
+
With the recently-announced Private Endpoints integration you can block inbound access from the internet to your web app. Before this integration, developers would need to use an App Service Environment (ASE) if they wanted to host their network-secured applications on App Service. With the combination of the Virtual Network (VNet) and Private Endpoint integrations on App Service, you can secure your site’s inbound and outbound requests respectively.
+
+
This is great for organizations that want the network security without the added cost of an ASE. However, if inbound access to your site is blocked, that can disrupt your existing delivery pipeline if you were not using Private Endpoints before. This article will walk through the process of installing an Azure DevOps agent on a Virtual Machine (VM) to deploy to a site secured with VNet and Private Endpoints. This solution works for ILB ASEs as well.
+
+
+
This article assumes some familiarity with Virtual Networks. If you are new to Azure Networking, please see this Microsoft Learning Path.
+
+
+
Solution Overview
+
+
This guide will walk through the process of deploying a Virtual Machine Scale Set (VMSS) and web app into two subnets of the same virtual network. You wil use Azure DevOps to install a build agent on the virtual machines and configure your DevOps Pipeline to run on those agents. Finally, you will enable private endpoints so the site cannot be reached from the public internet.
+
+
Prerequisites
+
+
To follow this guide you will need the following:
+
+
+
A valid Azure subscription
+
An Azure DevOps organization and project
+
A DevOps repository with a web application we can deploy to App Service
+
+
+
Part 1: Set up resources
+
+
First, let’s set up the Azure DevOps project and VM that will host the agent.
+
+
+
Create a Virtual Machine Scale Set with Ubuntu Server 18.04 LTS. This process will automatically create a VNet as well.
+
Once the VM Scale Set is created, open Azure DevOps and navigate to Project settings > Pipelines > Agent pools.
+
Click Add pool and this will open a context menu. Under Pool type select “Azure virtual machine scale set”. Choose your subscription and the VM Scale Set you just created. You can configure the max number of machines for the scale set, the number to keep on standby, and more. Read more information here.
+
Click Create to set up the agent pool. You can monitor the process under Diagnostics.
+
+
+
Part 2: Configure networking features
+
+
You now have a VM Scale Set with DevOps agents installed, all deployed within a VNet. Now you will create the web app and confirm that the VM’s and webapp can communicate over the virtual network.
+
+
+
Create an Azure Webappin the same region as the VM. Choose whatever runtime and operating system fit your application.
+
+
Once the web app is created, go to Networking > VNet Integration. Add the site to the same virtual network as the VM. The VM and webapp cannot be in the same subnet, so you may need to create another subnet.
+
+
With VNet integration enabled, the web app and VM can communicate over the virtual network. To test this, go to the web console for your site at https://my-linux-site.scm.azurewebsites.net/webssh/host on Linux apps, or https://my-windows-site.scm.azurewebsites.net/DebugConsole/?shell=powershell for Windows. Once the console is open, run the following command to ping the VM’s private IP. You can find your VM’s private IP from the Networking blade on the VM resource. It’s shown under “NIC Private IP”.
+
+
root@87d2385265ad$ ping 10.0.0.5 # replace with your VM's private IP
+
+
+
Now that the resources are in the same Virtual Network and can communicate over that network, let’s enable Private Endpoints on the web app. This will block inbound access to the web app from the public internet.
+
+
In the Portal, go to your web app > Networking > Private Endpoint connections > Configure your private endpoint connections > + Add. This will open a context blade to configure the Private Endpoint. Provide a name, subscription, and Virtual network. Check the box to allow the service to integrate with Azure Private DNS zones. This will create a private DNS zone if one does not already exist, and set up the correct domain entries for your web app. Click OK to create the resources.
+
+
Once the private link and DNS resources are created, open an SSH connection to your VM. Run the command below to ping the web app and confirm that you can reach the site from the VM. If you cannot reach the site from the VM, the DevOps agent won’t be able to either!
+
+
curl your-site-name.azurewebsites.net
+
+
+
You can also use nslookup to see how the private DNS entries ultimately map to the web app.
+
+
+
+
Installing build tools on your VMs
+
+
The virtual machines in your scale set may not come with the build tools that your pipeline will need (like Maven, NPM, or dotnet). To install these tools, you can add the Custom Script for Linux Extension. This extension allows you to upload a shell script that is executed whenever a new VM is provisioned in the scale set. So in this case, the shell script could install your necessary build tools.
+
+
Part 3: Create the CI pipeline
+
+
At this point the web app cannot be reached from the public internet but our VM can reach the site through the virtual network. Now let’s set up a DevOps Pipeline to build and deploy your application from the VM.
+
+
+
Head back to Azure DevOps and go to Pipelines > New pipeline. Then select the location of your project.
+
+
Once you choose your project, Azure DevOps will show some templates based on your stack. For example, I was given a starter pipeline to build my Java app with Maven and deploy it to App Service Linux. Click Show more if you don’t immediately see a good starter template.
+
+
If you are not given a good template to deploy your app to App Service, use the generic starter template and add the Deploy to Azure Web App action.
+
+
+
Next, specify the VMSS agent pool by adding the pool keyword on the pipeline. The value should be the name of your VMSS agent pool that you created earlier.
+
+
trigger:
+ -main
+
+ pool:'VMSSforprivateendpointsdeployment'# This is the name of your agent pool
+
+ steps:
+ -task:AzureWebApp@1
+ displayName:'AzureWebAppDeploy:priv-endpoints-webapp'
+ inputs:
+ azureSubscription:'aaaaaa-bbbb-cccc-dddd-eeeeeeeeee'
+ appType:webAppLinux
+ appName:'priv-endpoints-webapp'
+ package:'app.jar'
+
+
+
Finally, save and run the workflow! See the pipeline’s logs to monitor progress and check for any errors.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 5 minute read
+
+
+
+ • By Jason Freeberg
+
+ • January 4, 2021
+
+
+
With the recently-announced Private Endpoints integration you can block inbound access from the internet to your web app. Before this integration, developers...
Migrate from Windows Azure Pack Websites to Azure App Service
+
+
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Andrew Westgarth
+
+ • January 6, 2021
+
+
+
+
+
+
+
+
+
As Windows Azure Pack Web Sites v2 heads towards the end of extended support in 2022, it is important for customers to plan to migrate their workloads from the platform. Windows Azure Pack Web Sites V2 is an on-premises, high density, multi-tenant web hosting for service providers and enterprise IT and provides an experience similar to the predecessor to Azure App Service, Azure Web Sites. The product is deployed on top of Windows Server 2012 R2 and is an optional add-on to Windows Azure Pack.
+
+
+
+
Benefits of migrating to Azure App Service
+
+
Azure App Service is a rich, fully managed enterprise grade service built for hosting web applications, REST APIs and mobile back ends. Azure App Service builds on the capabilities within Windows Azure Pack Web Sites. Developers can develop in your favorite language, for example .NET, .NET Core, Java, Node.js, PHP or Python; deploy code or containers; can run and scale with ease of both Windows AND Linux based environments.
+
+
App Service is a managed platform powered by Microsoft Azure, offering security, load balancing, automated management, rich DevOps capabilities - continuous deployment from Azure Dev Ops. GitHubs, Container registries such as Docker Hub, staging environments, custom domains and TLS/SSL Certificates.
+
+
App Service also provides many networking options for enabling hybrid workloads and isolation for both the multi-tenant service and also the single tenant App Service Environment product offering.
+
+
In addition to App Service once workloads have been migrated to Azure, customers can also take advantage of a whole plethora of services such as Azure Functions, Azure Logic Apps and Azure Monitor to name just a few, all of which are not available on Windows Azure Pack.
+
+
Migrating from Windows Azure Pack Web Sites
+
+
Azure App Service is a natural option for customers operating Windows Azure Pack Web Sites and for tenants who have deployed workloads to Windows Azure Pack Web Sites. There are no automated procedures for migrating workloads from WAP Web Sites to Azure App Service.
+
+
Customers should assess their workloads for migration to Azure App Service and plan to create new Apps in Microsoft Azure, configure and deploy their application content to the new Web App in Azure App Service. Applications can be created using the Azure Portal, CLI or ARM Template. Application content can be deployed using FTP, Zip or Continuous Deployment from Source Control, Container Registries or using GitHub Actions.
+
+
Key Considerations when migrating from Windows Azure Pack Web Sites to Azure App Service
+
+
Supported Authentication Methods
+
+
Windows Azure Pack Web Sites allows customers to use Windows Authentication to restrict access to applications and to secure access from their applications to other resources such as SQL Server, customers were able to define custom application pool identities and choose to use this authentication method within their applications. This was possible as Windows Azure Pack Web Sites is deployed inside a customer’s own organization, network and all underlying infrastructure could be domain joined.
+
+
Azure App Service does ot support Windows Authentication, therefore Customers need to look to alternative authentication methods to authenticate access to other resources, for example SQL Authentication when connecting to SQL Server Databases on-premises or Managed Identity when connecting to Azure SQL DB instances.
+
+
For application developers looking to authenticate users, they can make use of App Service authentication capabilities targeting multiple identity providers such as:
Windows Azure Pack Web Sites offers two different hosting options - shared and dedicated; Azure App Service expands on this and offers few categories of pricing tiers each with different capabilities and limits:
+
+
+
Shared compute - Free and Shared;
+
Dedicated compute - Basic, Standard, Premium, PremiumV2 and PremiumV3;
+
Isolated compute
+
+
+
App Service Plans
+
+
All applications in Azure App Service always run in an App Service Plan. The App Service Plan defines the Azure Region in which the app is deployed, number of worker instances the plan is scaled out to, the size of the instances and the pricing tier.
+
+
The wider range of options provided in Azure App Service enable customers to run a wider range of workloads, achieve differing levels of density and isolation dependent on their specific needs.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Andrew Westgarth
+
+ • January 6, 2021
+
+
+
As Windows Azure Pack Web Sites v2 heads towards the end of extended support in 2022, it is important for customers to plan to migrate their workloads from t...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Jason Freeberg
+
+ • January 6, 2021
+
+
+
+
+
+
+
The latest App Service releases included new Java, Tomcat and JBoss EAP versions.
+
+
Windows
+
+
+
New Tomcat versions
+
+
9.0.38
+
8.5.58
+
+
+
New Java versions
+
+
11.0.8
+
8.0.265
+
7.0.272
+
+
+
+
+
Eclipse Foundation has deprecated Jetty 9.1 and 9.3 (source), so these runtimes are no longer shown on the Portal. You can still create sites with these versions. Tomcat 8.0 has reached End-Of-Life and will also be hidden in an upcoming Portal update. Web apps using these outdated runtimes will continue to run, but using the latest versions ensures that your apps are running on the most secure and performant runtimes.
+
+
Linux
+
+
+
JBoss EAP is now available with Java 11
+
+
JBoss EAP now has an “auto-update” option. This option currently uses JBoss 7.2 but will automatically use the latest JBoss versions as they are added.
+
+
+
New Java versions
+
+
8u252
+
11.0.7
+
+
+
New Tomcat versions
+
+
9.0.37
+
8.5.57
+
+
+
+
+
How to upgrade your Java or Tomcat version
+
+
To upgrade your Java or Tomcat version, open the Azure Portal to your web app and open the Configuration blade. Under the General settings tab you can select a new Java and Tomcat version using the dropdowns for Java minor version and Java web server version.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Byron Tardif, Elliott Hamai
+
+ • January 26, 2021
+
+
+
We are happy to share a new resource create blade for App Service and Azure databases. This new experience, currently in preview, deploys a PostgreSQL or Azu...
New App Service + Database create blade (preview)
+
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Byron Tardif, Elliott Hamai
+
+ • January 26, 2021
+
+
+
+
+
+
+
We are happy to share a new resource create blade for App Service and Azure databases. This new experience, currently in preview, deploys a PostgreSQL or Azure SQL database and automatically connects it to your web app.
+
+
This new create flow was built with simplicity in mind. You only need to provide a name and runtime stack for the web app, and choose between Azure SQL or PostgreSQL. Once the resources are created the database connection strings are automatically added as app settings on the web app. The username and password are automatically generated, or you can choose to overwrite these with your own strings.
+
+
+
+
You can get to the new blade using this link, or by searching “web app database” in the Azure Portal. By default, the blade will create a new PremiumV2 App Service plan and either a serverless Azure SQL server or General Purpose PostgreSQL flexible server depending on you choice of database. Once created, you can scale these services up or down to fit your needs.
+
+
+
Azure Database for PostgreSQL is currently in preview.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Byron Tardif, Elliott Hamai
+
+ • January 26, 2021
+
+
+
We are happy to share a new resource create blade for App Service and Azure databases. This new experience, currently in preview, deploys a PostgreSQL or Azu...
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Andrew Westgarth
+
+ • January 6, 2021
+
+
+
As Windows Azure Pack Web Sites v2 heads towards the end of extended support in 2022, it is important for customers to plan to migrate their workloads from t...
+
+
+
+
+
+
+ 5 minute read
+
+
+
+ • By Jason Freeberg
+
+ • January 4, 2021
+
+
+
With the recently-announced Private Endpoints integration you can block inbound access from the internet to your web app. Before this integration, developers...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Gaurav Seth
+
+ • February 5, 2021
+
+
+
+
+
+
+
Join our upcoming webinar on Tuesday, February 23 from 1:00 to 2:00pm Pacific Time! Learn how Azure can help you to innovate with your .NET web apps and SQL databases with native capabilities such as AI and analytics. In addition, you’ll learn how to build smarter and faster applications using functions, APIM, and auto deployment. Lastly, we’ll show you how GitHub actions can be used to help automate your workflows.
+
+
We will also cover:
+
+
+
Leveraging deployment slots and enabling autoscaling
+
Using Azure Monitor Logs and App Insights to gain insights into log and performance data
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
.NET 5 NuGet package restore Incident: App Service Response
+
+
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Jason Freeberg
+
+ • February 5, 2021
+
+
+
+
+
+
+
+
+
Last week an incident occurred that caused .NET 5 NuGet package operations to fail on some Debian-family distributions. Specifically, Debian and Ubuntu maintainers published an update (for at least some distro versions) that distrusted the Symantec certificate entirely. This change was later rolled back, but patched packages were not available on the package repositories prior to the Microsoft NuGet author signing certificate expiring. Please see this NuGet announcement for more information.
+
+
Impact to App Service users
+
+
This incident affected any users running a .NET 5 application on App Service and using App Service’s built-in build service, known as Oryx. If you are building your .NET 5 applications locally or on a CI system, this incident will not affect your .NET 5 applications.
We have updated the root certificates used in the .NET 5 runtime and build image (also known as the Oryx image) and will begin rolling out the updated image as soon as possible. We will update this article as new information becomes available.
+
+
Workaround
+
+
To work around this limitation, please build your .NET 5 applications locally or on a build system (such as GitHub Actions or AzureDevops) and deploy the built application to App Service. You can set up a GitHub Actions workflow from the Deployment Center in the App Service blade in the Portal. If you would rather build locally, you can use the az webapp deployment source config-zip command to deploy your app from a .zip file.
+
+
Once the root certifactes have been updated on your site, you can return to using the Oryx build service. We will update this article as new information becomes available.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Jason Freeberg
+
+ • February 5, 2021
+
+
+
Last week an incident occurred that caused .NET 5 NuGet package operations to fail on some Debian-family distributions. Specifically, Debian and Ubuntu maint...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Gaurav Seth
+
+ • February 5, 2021
+
+
+
Join our upcoming webinar on Tuesday, February 23 from 1:00 to 2:00pm Pacific Time! Learn how Azure can help you to innovate with your .NET web apps and SQL ...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Jason Freeberg
+
+ • February 5, 2021
+
+
+
Last week an incident occurred that caused .NET 5 NuGet package operations to fail on some Debian-family distributions. Specifically, Debian and Ubuntu maint...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Gaurav Seth
+
+ • February 5, 2021
+
+
+
Join our upcoming webinar on Tuesday, February 23 from 1:00 to 2:00pm Pacific Time! Learn how Azure can help you to innovate with your .NET web apps and SQL ...
A crash of a process happens when the process terminates due to an unhandled exception within the application code. A crash leads to a restart and all the in-flight requests (requests currently being handled by the process) are aborted abruptly and may fail with an HTTP 502 error. The process restart causes the application startup code to kick in and the result might be observed as slowness in the application for end-users. Hence, crashes should be avoided as much as possible! Proactive Crash Monitoring is a feature of Azure App Service that checks for process crashes and collects diagnostic data that helps you determine the root cause of the crash.
+
+
+
Currently offered in App Service Diagnostics for Windows web apps.
+
+
+
How does Proactive Crash Monitoring work?
+
+
Whenever the worker process (w3wp.exe) corresponding to your app crashes due to an unhandled exception for more than 3 times in 24 hours on the same instance, the feature is enabled automatically and a debugger process is attached to your site’s main worker process. This debugger process then waits for your process to crash again and, assuming it does crash again, a memory dump is collected. This memory dump is then analyzed and the call stack of the thread that caused the crash is logged in your App Service’s logs.
+
+
Viewing Crashing thread information
+
+
Folow these steps to view the crashing thread’s call-stack.
+
+
+
Open the Diagnose and Solve blade for the app (in the left-side navigation menu)
+
Choose Availability and Performance category
+
Choose Application Crashes tool
+
+
If this feature has collected a crashing thread stack trace, you will find an insight like in the image below
+
+
+
+
+
+
+
+
FAQ
+
+
How frequently are the crash dumps recorded?
+
+
Once a memory dump is captured on an instance, further memory dumps on the same instance may not be captured for the next 8 hours even if the process keeps crashing.
+
+
What happens to the memory dump that is collected?
+
+
Since the memory dump contains PII data, the memory dump is deleted once the call stack and exception information is recorded. There is no way to retrieve this dump later as this dump is not stored or persisted anywhere. If you need to capture a memory dump for further investigation and a call stack alone is not sufficient, then leverage the Crash Monitoring feature of Azure App Service that allows you to collect memory dumps on process crashes.
+
+
Is the original exception message logged somewhere?
+
+
The exception message may contain PII data due to which the exception message is not logged in Azure App Services Platform telemetry. There is a log file created in d:\home\logfiles\crashdumps folder for each crash and this log file contains the exception type and full exception message. Information about the last 10 crashes only is saved and older files are deleted. You can view this log file by going to the KUDU console (available at yoursitename.scm.azurewebsites.net) for your app.
+
+
Which processes are monitored by this feature?
+
+
This feature only monitors the w3wp.exe corresponding to the main app. Any processes that are spun up for out-of-process hosting scenarios (like PHP, CGI, Java, or .Net Core OutProc) are not monitored by this feature. Also, any processes that belong to the SCM site (for e.g. Webjobs) are not monitored by this feature.
+
+
Are there additional processes started as a result of this feature?
+
+
When this feature is trying to capture a crash dump of your process, you may see CrashMon.exe, procdump.exe, or dbghost.exe running in the Kudu Console for your app.
+
+
Are we notified for unhandled exceptions recorded by this feature?
+
+
We notify by sending emails to the “ServiceAdmin”, “AccountAdmin” and “Owner” roles for the subscription when a crash is recorded by this feature.
+
+
+
+
What is the performance overhead introduced by the feature?
+
+
There might be slight performance impact to your app because a debugger process is attached till the worker process crashes once. The overhead introduced should be negligible but only for apps that have very high exceptions per second rate, some delay may be observed.
+
+
Can this feature be disabled?
+
+
You can opt-out of this feature by adding the APP SETTING WEBSITE_PROACTIVE_CRASHMONITORING_ENABLED and setting it to FALSE.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 4 minute read
+
+
+
+ • By Jason Freeberg
+
+ • March 1, 2021
+
+
+
+
+
+
+
+
+
An earlier article explained how to use self-hosted Azure DevOps agents to build and deploy your applications to a web app that has Private Endpoints enabled, or an ILB ASE. If you didn’t read that article, the TL;DR is that Private Endpoints blocks inbound access to your web app from the public internet. Private Endpoints is great for securing internal-facing applications without deploying an App Service Environment, but it means that you cannot directly publish your code to the web app from your local machine or Continuous Integration pipeline because that traffic is blocked. The earlier article shows how to deploy Azure DevOps build agents onto Virtual Machine Scale Sets in your Azure VNet. Those agents can publish to the web app since the deployment is sent from within the virtual network, not over the public internet.
+
+
Solution Overview
+
+
This article shows how to deploy to a Private Endpoint-enabled site from a Continuous Integration pipeline (such as GitHub Actions, Circle CI, Jenkins, or Travis CI) without having to self-host the CI service on a VM. Since Private Endpoints disables all inbound traffic from the internet, our CI pipeline will publish the files to a storage account and give the web app a SAS URL to files. Once the web app is given this SAS URL, it will pull the files from the storage account.
+
+
We will use GitHub Actions as the CI system to demonstrate this solution, but the same pattern can be applied to other CI providers as well. If you are not familiar with GitHub Actions, please refer to the docs. If you are using a different CI system, simply copy the Azure CLI commands at the bottom, and use them in your CI provider.
+
+
GitHub Actions workflow
+
+
The workflow has two jobs. The first builds and tests the application and uploads the artifact for the second job. Once the artifact is built, tested and uploaded, the second job pulls the artifact and runs an Azure CLI script to publish the files to an Azure Storage Account. Once the files are uploaded, we generate a SAS URL for the storage container with an expiration of 30-minutes. (This means the URL will be invalid 10 minutes after creation.) The web app then pulls the application from the storage account and deploys it. Behind the scenes, the Azure CLI commands are using ZIP deploy to publish the application. Once your code is deployed to the web app, a final CLI command deletes the storage container that contained the ZIP file.
+
+
Note: A bug has been identified in the CLI command used in the GitHub Actions workflow below and a fix is underway. In the meantime, you can accomplish the same result by using az rest to send the deployment request directly to the ARM API. Example:
name:Deploy web app via Storage Account
+
+on:
+ push:
+ branches:[main,master]
+ workflow_dispatch:
+
+env:
+ WEBAPP:your-webapp-name
+ GROUP:your-resource-group-name
+ ACCOUNT:name-for-storage-acct# Does not have to exist, this will be created for you
+ CONTAINER:name-for-storage-container
+ EXPIRY_TIME:10 minutes
+
+jobs:
+ build:
+ runs-on:ubuntu-latest
+
+ steps:
+ -uses:actions/checkout@v2
+
+ -name:Set up JDK 1.8
+ uses:actions/setup-java@v1
+ with:
+ java-version:1.8
+
+ -name:Build with Maven
+ run:mvn package
+
+ -name:Upload artifact for deployment jobs
+ uses:actions/upload-artifact@v2
+ with:
+ name:app
+ path:target/app.jar
+
+ publish:
+ runs-on:ubuntu-latest
+ needs:build
+
+ steps:
+ -name:Azure Login
+ uses:azure/login@v1
+ with:
+ creds:${{ secrets.AZURE_CREDENTIALS }}
+
+ -name:Download artifact
+ uses:actions/download-artifact@v2
+ with:
+ name:app
+
+ -name:Zip the app contents
+ uses:papeloto/action-zip@v1
+ with:
+ files:app.jar
+ dest:app.zip
+
+ -name:Set SAS token expiration
+ run:echo "expiry=`date -u -d "$EXPIRY_TIME" '+%Y-%m-%dT%H:%MZ'`" >> $GITHUB_ENV
+
+ -name:Azure CLI script
+ uses:azure/CLI@v1
+ with:
+ azcliversion:2.19.1
+ inlineScript:|
+ az extension add --name webapp
+
+ az storage account create -n $ACCOUNT -g $GROUP -l westus
+ az storage container create -n $CONTAINER --account-name $ACCOUNT
+ az storage blob upload -f app.zip --account-name $ACCOUNT -c $CONTAINER -n $ACCOUNT
+
+ ZIP_URL=$(az storage blob generate-sas --full-uri --permissions r --expiry ${{ env.expiry }} --account-name $ACCOUNT -c $CONTAINER -n $ACCOUNT | xargs)
+
+ az webapp deploy --name $WEBAPP --resource-group $GROUP --type zip --src-url $ZIP_URL --async false
+
+ az storage container delete -n $CONTAINER --account-name $ACCOUNT
+
+
+
To use this workflow in your GitHub project, simply create an Azure Service Principal and save it as a secret named AZURE_CREDENTIALS in your repository. Finally, update the WEBAPP, CONTAINER, GROUP, and ACCOUNT environment variables with your desired resource names. By default, this workflow will run whenever a commit is pushed to the main or master branch. You can change this by updating the workflow triggers at the top of the yaml file. You can change the SAS token expiration time by changing the value of the EXPIRY_TIME variable at the top of the workflow.
+
+
+
The az webapp deploy command is in the webapps extension as of March 2021, it will be included in the core CLI in future release.
+
+
+
Notes for other CI services
+
+
Not using GitHub Actions? No problem! You can log into the Azure CLI using a Service Principal, just like on GitHub Actions, and use the Azure CLI commands at the bottom of the yaml file. We have compiled some helpful resources for common CI providers below.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 4 minute read
+
+
+
+ • By Jason Freeberg
+
+ • March 1, 2021
+
+
+
An earlier article explained how to use self-hosted Azure DevOps agents to build and deploy your applications to a web app that has Private Endpoints enabled...
A crash of a process happens when the process terminates due to an unhandled exception within the application code. A crash leads to a restart and all the in...
Using Azure Functions with Azure Virtual Network NAT to Avoid SNAT Port Exhaustion
+
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Jeff Martinez
+
+ • March 2, 2021
+
+
+
+
+
+
+
Source Network Address Translation (SNAT) ports are used by App Service to translate outbound connections to public IP addresses. However, there are limitations to the number of SNAT port connections you can use at once and if your application runs out of SNAT ports it will cause intermittent connectivity issues. To avoid SNAT port exhaustion issues you will need to make sure that no new connections are created repetitively on the same host and port. Follow this sample for further detail on how this can be accomplished using Azure Functions, Regional VNET Integration, Private Endpoints and NAT Gateway.
+
+
To learn more about Troubleshooting outbound connection errors, see the documentation.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
App Service Managed Certificate (Preview) Now Supports Apex Domains
+
+
+
+
+
+
+
+
+ 4 minute read
+
+
+
+ • By Yutang Lin
+
+ • March 2, 2021
+
+
+
+
+
+
+
+
+
App Service Managed Certificate (preview) now lets you secure your apex domains on your web apps at no additional charge. This feature is similar to the current App Service Managed Certificate sub-domain support where you can create a standard certificate valid for six months which will automatically renew around 45 days before expiration. Your TLS/SSL bindings will also be automatically updated. If you have several domains, you will need to separately create an App Service Managed Certificate for each of them; wildcard certificate is not supported for this feature.
+
+
Getting started
+
+
Pre-requisites
+
App Service Managed Certificates for apex domains are validated with HTTP token validation which App Service will set up on your behalf. However, to ensure a successful create and renewal validation, you want to make sure that you have the following set up, otherwise your certificate validation will fail.
Your web app must be accessible from the public network and does not have any IP restrictions set up. You cannot validate your certificate if your web app is not accessible from the public network. Adding IP restrictions after creating a certificate will cause renewal to fail.
+
+
+
Creating an App Service Managed Certificate
+
Before creating a managed certificate, make sure you have met the pre-requisites. In the Azure Portal, head to your web app and from the left navigation menu of your app, select TLS/SSL settings > Private Key Certificates (.pfx) > Create App Service Managed Certificate.
+
+
+
+
A blade will show up on the right side of the page. In that blade, select an apex domain from the drop down menu and click “Create”. It may take up to a few minutes to create a managed certificate for your apex domain.
+
+
+
+
Once you get a notification that the managed certificate was created successfully, you will see the certificate on the list of “Private Key Certificates”. If you close the blade before getting a successful notification or if you do not see the newly created managed certificate, refresh the page and you should see the new certificate on the list.
+
+
FAQ
+
+
+
+
Q: I’m getting “Web app is not accessible by public network” error. What does this mean?
+
+
A: In order to pass the HTTP token validation, your web app needs to be accessible from public network. If your web app has network restrictions, the HTTP token validation will fail.
+
+
+
Q: I am getting the following error on portal when validating my domain with a country code top-level domain (ccTLD): Properties.CanonicalName is invalid. Canonical name XXXXX is not a subdomain. This validation method only supports subdomains. How can I fix this?
+
+
A: If you are encountering this error with your apex domain, try creating a certificate with the script below.
+
+
+
Q: Does this have CLI or Powershell support? How can I automate the create process?
+
+
A: Currently, there is no first class CLI and Powershell support to create a managed certificate for apex domains. However, if you need to automate the process, you can try using ARM template. Refer to the automate with scripts section of the article.
+
+
+
Q: Is this supported when using alias record for my apex domain referencing Traffic Manager?
+
+
A: This scenario is not supported. Since managed certificates for apex domain uses HTTP token validation, the validation can fail if the web app itself isn’t reached during certificate create/renew validation. Do not create a managed certificate for this scenario.
+
+
+
Q: Is it expected that the managed certificate for apex domain to take a bit longer to create than for sub-domain?
+
+
A: Yes, your App Service Managed Certificate for apex domain will take a bit longer to create than for sub-domain because it uses a different validation method.
+
+
+
+
Automate with scripts
+
+
You can create an App Service Managed Certificate for your apex domain using ARM Template. Below is a sample of using a Powershell script to run your ARM template. This script will only create an App Service Managed Certificate for a custom domain that has already been added to your web app. If you run this script before adding a custom domain to the web app, the script will fail.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 4 minute read
+
+
+
+ • By Yutang Lin
+
+ • March 2, 2021
+
+
+
App Service Managed Certificate (preview) now lets you secure your apex domains on your web apps at no additional charge. This feature is similar to the curr...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Jeff Martinez
+
+ • March 2, 2021
+
+
+
Source Network Address Translation (SNAT) ports are used by App Service to translate outbound connections to public IP addresses. However, there are limitat...
When enabling private endpoint for a web app, both the web app and the Source Control Manager (SCM) site, also sometimes referred to as kudu, are locked down to only receive traffic from the private IP. If you are in the internal network and have setup proper private DNS resolution, you can access both sites by browsing to https://appname[.scm].azurewebsites.net.
+
+
Externally public DNS for appname[.scm].azurewebsites.net will still resolve and route you to the public endpoint in which case you will be met with the blue Forbidden page.
+To route external traffic to the site or if you prefer to use a custom domain internally, you can setup a reverse proxy like Azure Application Gateway. In a reverse proxy you can override the custom domain with an internal hostname like appname[.scm].azurewebsites.net. All of this has been possible for a while and you can use the SCM APIs by providing the deployment credentials in the request, but what has not been possible is to access the SCM site in the browser and using all the tools available here.
+
+
Previously when setting this up and browsing to https://[scm.mydomain.com]/basicauth the browser would challenge you for your deployment credentials, but after validating your credentials, it would redirect you to appname.scm.azurewebsites.net, which would be blocked. What you can now do, is to use https://[scm.mydomain.com]/basicauthviaproxy. When accessing this link, the backend will look for the originating address in X-Forwarded-Host or X-Original-Host and redirect you to the appropriate address upon successful login.
+
+
A few notes:
+
+
+
It only works with deployment credentials. SSO is not possible
+
SCM site does not have an unauthenticated health endpoint, so health probes should either be disabled or accept 401 and 403
+
Some response payloads from the SCM APIs contain absolute references defaulting to the incoming host (appname.scm.azurewebsites.net). To override this and honor the originating address, configure the following App Setting on the web app: SCM_USE_ORIGINALHOST_FOR_REFERENCE = 1
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
When enabling private endpoint for a web app, both the web app and the Source Control Manager (SCM) site, also sometimes referred to as kudu, are locked down...
How-to Host a Python application with Windows containers on App Service
+
+
+
+
+
+
+
+
+ 5 minute read
+
+
+
+ • By Jeff Martinez
+
+ • March 4, 2021
+
+
+
+
+
+
+
+
+
Windows containers on App Service can help you easily modernize your application by making it easier to Lift-and-Shift to App Service and install custom dependencies that would otherwise not be available on App Service. If your application is built with a language other than .NET, you can still create a custom container and take advantage of Windows cotnainers! In this tutorial we will be using a Visual Studio templated Python 3.6 Flask application, containerizing it with Docker and publishing the image to Azure Container Registry so it can be deployed on App Service.
+
+
Create and configure your Python app
+
+
Open Visual Studio and click on Create a new project. Find the Flask Web Project template, name it and click Create.
+
+
Once you have created your application find the runserver.py file and replace the existing code with the following:
+
+
from os import environ
+from FlaskWebProject1 import app
+
+if __name__ == '__main__':
+# Run the app server with default Flask port
+app.run(port=5555, host='0.0.0.0')
+
+
+
This code runs the local development server which defines the default Flask port that it will be using along with the host to use IP addresses on the local machine. This will be utilized later for developing in your local browser. In the next step we will be creating a Dockerfile for the application so we can containerize it.
+
+
Adding the Dockerfile
+
+
To containerize your application you will need to add a Dockerfile, which includes instructions on how to build the container. If you are using Visual Studio you may have to add the Dockerfile manually. To add the Dockerfile manually, Right-Click the project and add a New Item. Then, choose Text file and name it Dockerfile.txt and click Add to add the file. However, Dockerfiles have no extensions so you’ll need to remove the “.txt” from the name and save it to create the Dockerfile.
+
+
Once you have your Dockerfile created copy and paste the following:
+
# first layer is our python base image enabling us to run pip
+FROM python:3.7-windowsservercore-1809
+
+# create directory in the container for adding your files
+WORKDIR /user/src/app
+
+# copy over the requirements file and run pip install to install the packages into your container at the directory defined above
+COPY requirements.txt ./
+RUN pip install--no-cache-dir-r requirements.txt --user
+COPY . .
+
+# enter entry point parameters executing the container
+ENTRYPOINT ["python", "./runserver.py"]
+
+# exposing the port to match the port in the runserver.py file
+EXPOSE 5555
+
+
+
This Dockerfile includes instructions that will build your container on a Windows Server base image, add your application files over to the container and build your packages using your requirements.txt file as you normally would with a Python app. The port exposed must match the port that is previously defined in the runserver.py file.
+
+
Create the Docker Image
+
+
When using Docker, you need to build and create the image first before you can run the container. Open your local Command Prompt, go to the directory where your Dockerfile lives and run this command:
+
+
docker build -t mypythonapp .
+
+
+
Running this command will take each step defined in the Dockerfile from above and build your image. Once your image is successfully built and tagged, you can then run it locally to test the application.
+
+
Run your application locally
+
+
Before you push your image to a registry, you’ll want to make sure your local version runs as expected. Once your Docker image is built run the following command to start your container:
+
+
docker run -d --isolation hyperv mypythonapp:latest
+
+
+
Running this command will start your application and give you a Container ID in the form of a long string. Confirm that your container is running by using the docker ps command next. This will output all containers currently running. Locate and copy the string under Container ID to be used later. This is a shorthand version of the long string from before.
+
+
After you have confirmed that your container is running locally with docker ps you can use docker inspect to find the IP Address that you will need to use to view your application.
+
+
Use the following command to output json that will include your IP Address that you will need:
+
+
docker inspect <Container-ID>
+
+
+
Find your IP Address at the bottom of the output and paste it in the browser with your exposed port number after the IP Address. It should look similar to http://172.00.000.000:5555. Hit enter and your application should show up in the browser. If everything looks good and your application is ready to publish, the next step is to push your image to a container registry where it will live prior to being deployed to App Service.
+
+
Push your container image to a registry
+
Now that we’ve tested the application locally in a container we can push it to a container registry where the image will live. This will prepare us and satisfy the requirements for creating and publishing the application to App Service. First you must have a registry created before you can push the image to it. Once that is complete, you can continue with these instructions. For this example, we will be using Azure Container Registry, but you can use Docker Hub as well by swapping out the registry-name.azurecr.io with your-docker-hub-registry-name.
+
+
Before you attempt to tag and push the image, make sure you are logged in by using docker login in the command prompt
+
+
docker login <registry-name>.azurecr.io
+
+
This will prompt you to enter your username and password from your registry. You can find these under Access keys in your Container registry resource in the Azure portal.
+
+
After you’ve logged in, run the following commands to tag and push your Docker image:
+
+
docker tag mypythonapp:latest <registry-name>.azurecr.io/mypythonapp:latest
+
Once the image is pushed you can verify that it is in your Azure Container Registry by viewing the Repositories in your Container registry resource. Next, we will use the image from our registry to create our Web App on App Service.
+
+
Create the Web App using Premium v3
+
+
When you are creating the Web App that you will publish your container to be sure to choose the correct options shown below. Name your site, choose Docker Container under Publishing type and Windows for the Operating System. Choose an available Region and then choose your SKU and size. Premium V3 is the only SKU that supports Windows containers. Learn more about the Premium V3 SKU here.
+
+
+
+
Next, click the Next:Docker > button to pull your container image from Azure Container Registry.
+
+
Choose Azure Container Registry as your Image Source and the registry options will show up for you to select. The registry you selected earlier should show up in the Registry drop-down along with the created Images and Tags.
+
+
+
+
Once you have the correct options selected you can hit Review + create to start your deployment and verify your deployed app on App Service.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 5 minute read
+
+
+
+ • By Jeff Martinez
+
+ • March 4, 2021
+
+
+
Windows containers on App Service can help you easily modernize your application by making it easier to Lift-and-Shift to App Service and install custom depe...
+
+
+
+
+
+
+ 13 minute read
+
+
+
+ • By Yutang Lin
+
+ • March 11, 2021
+
+
+
+
+
+
+
+
+
In this article, we will review different App Service offerings with side-by-side comparisons to show how you can save more with App Service. The offerings we will be covering in this article are:
+
+
+
Free App Service Plan on Linux and Windows
+
Basic App Service Plan on Linux
+
Premium V3 App Service Plan on Linux and Windows
+
Reserved Instances
+
Dev/Test Pricing
+
+
+
At the end of the article, we will also go through how you can estimate your cost savings using the Azure Pricing Calculator.
+
+
Free App Service Plan on Linux and Windows
+
App Service provides Free App Service Plans on both Linux and Windows. This is a great option if you are starting out in your journey to host web apps in the cloud. This tier comes with its own limits on what features it supports, so if your traffic increases significantly, you will likely need to scale up to Basic or Standard (covered later in this article).
+
+
Basic App Service Plan on Linux
+
Linux developers who are starting out on App Service and are hosting a smaller web app with lower traffic requirements that don’t need auto scale, virtual network integration and deployment slots features should take note of the discounted prices for Linux Basic App Service Plan. The chart below will show you a comparison between a Linux B1 and S1 instance so you can see the significant price difference between the two.
+
+
+
+
+
OS
+
Instance
+
Cores
+
RAM
+
Storage
+
Cost
+
+
+
+
+
Linux
+
B1
+
1 core
+
1.75 GB
+
10 GB
+
~$13.14/month
+
+
+
S1
+
1 core
+
1.75 GB
+
50 GB
+
~$69.35/month
+
+
+
+
+
* Prices are based on App Service pricing with the following configurations as of 03/10/2021: Linux OS, Central US region, USD currency, and displayed by month
+
+
Before moving from Standard to Basic, please refer to App Service limits page and App Service pricing page for more information on the feature support for the different plans. If your workload does not need the Standard feature set, moving to Basic will help optimize your costs.
+
+
Premium V3 App Service Plan
+
+
Customers who are currently running bigger production workloads on App Service should be aware of the new App Service Premium V3 (Pv3) offering announced in November 2020, which is our most performant and cost effective offering yet. The PV3 tier offers enhanced performance for a competitive price. To give an example, let’s compare the P1v2 to P1v3 for both Linux and Windows:
+
+
+
+
+
OS
+
Instance
+
Cores
+
RAM
+
Storage
+
Cost
+
+
+
+
+
Linux
+
P1v2
+
1 core
+
3.50 GB
+
250 GB
+
~$81.03/month
+
+
+
P1v3
+
2 cores
+
8 GB
+
250 GB
+
~$124.10/month
+
+
+
Windows
+
P1v2
+
1 core
+
3.50 GB
+
250 GB
+
~$146.00/month
+
+
+
P1v3
+
2 cores
+
8 GB
+
250 GB
+
~$240.90/month
+
+
+
+
+
* Prices are based on App Service pricing for Linux and Windows with the following configurations as of 03/10/2021: Linux OS and Windows OS, Central US region, USD currency, and displayed by month
+
+
P1v3 provides double the cores and more than double the RAM compared to P1v2. If you look at the table above, for Linux P1v3, you get double the cores and more than double the RAM for an additional ~53% of the cost, while for Windows P1v3, you get double the cores and more than double the RAM for an additional ~65% of the cost. Also note that the comparative price/performance difference is even larger when reserved instances or dev/test pricing are used (both are covered later in this article). For example, with a one year reserved instances price, Linux customers can run a P1v3 instance at roughly the same price as a P1v2 instance. And with a three year reserved instances price, Linux customers can run a P1v3 instance at a lower price than a P1v2!
+
+
Scaling Up to PV3
+
+
Note that some customers who are on pre-existing App Service footprints may not be able to scale up to PV3. This will be the case if you notice the option greyed out on the portal when they try to scale up. You will be guaranteed to get support for PV3 if you create a new app in a new resource group in the region of your choice, and you pick a PV3 SKU when creating the new app service plan. You can subsequently scale down your app to a different SKU with the confidence that you can scale back up to Pv3 in the future. You can read more about the option to scale up from an unsupported resource group and region combination for PV3.
+
+
Long Term Cost Savings for PV3
+
+
If you are planning to run your PV3 instances in the long term, you should consider purchasing reserved instances as it can greatly increase your savings. The following section will go through it in more detail.
+
+
Reserved Instances
+
+
Customers who are running high scale productions on App Service and are looking for long term cost saving options can consider purchasing reserved instances for App Service. Purchasing reserved instances lets customers save 35% to 55% on costs compared to pay-as-you-go if they buy reserved instances for a one-to-three-year commitment. The reserved instances options for App Service are available for Premium V3 Tiers and Isolated stamp fees for ASE V2. You can learn more about this on:
We will go through a few examples from our pricing page to show you the savings you can get with reserved instances. If you would like more information, our pricing page shows a breakdown of the prices for the different options on both Linux and Windows.
+
+
The chart below shows the comparison between the prices for P1v3 instance for pay-as-you-go, one-year reserved instance, and three-year reserved instance on both Linux and Windows.
+
+
+
+
+
OS
+
Instance
+
Pay as You Go
+
1 Year Reserved
+
3 Year Reserved
+
+
+
+
+
Linux
+
P1v3
+
~$124.100/month
+
~$81.001/month (~35% savings)
+
~$56.247/month (~55% savings)
+
+
+
Windows
+
P1v3
+
~$240.90/month
+
~$180.332/month (~25% savings)
+
~$145.249/month (~40% savings)
+
+
+
+
+
* Prices are based on App Service pricing Linux and Windows with the following configurations as of 03/10/2021: Linux OS and Windows OS, Central US region, USD currency, and displayed by month
+
+
As you can see from the chart above, you can get significant savings from purchasing reserved instances. On Linux, a three-year commitment will save you ~55% compared to if you opt for pay as you go. While on Windows, a three-year commitment will save you ~40% compared if you opt for pay as you go. The longer the term commitment, the more savings you will get with reserved instances. Across both Linux and Windows, reserved instances pricing for Pv3 enables you to run at a lower price than equivalent Pv2 instances!
+
+
How to Buy Reserved Instances
+
+
Purchasing reserved instances is very convenient. You can purchase it through the Azure portal. To get started, head to the Azure portal, search for “Reservations” on the search bar, and then select the “Reservations” services.
+
+
+
+
You will be redirected to a page similar to a resource view page, but it will say “Reservations” on the top left corner. Click on the “+ Add” button to purchase reserved instances.
+
+
+
+
You will see a page that lists a range of products that you can purchase reservations for. Search for and select “App Service” from the list.
+
+
+
+
A blade will appear on the right side showing options for App Service reserved instances for PV3 and for Isolated App Service Plan. If you don’t see the region, term, or billing frequency that you are interested in, try adjusting the filters by clicking on the blue bubble. For the term, you can choose between a one-year and three-year option. Once you select an instance, you can view the price and the savings at the bottom right corner. In the image below, I selected the P1v3 option for Linux in Central US region for a three-year term billed monthly.
+
+
+
+
* The reserved instance price is based on the following configurations as of 03/10/2021: Linux P1v3, Central US region, and a three-year term that is billed monthly.
+
+
And another example below, I selected the P1v3 option for Windows in Central US region for a three-year term billed monthly.
+
+
+
+
* The reserved instance price is based on the following configurations as of 03/10/2021: Windows P1v3, Central US region, and a three-year term that is billed monthly.
+
+
Once you’ve decided on your choice, click on “Add to cart”. You may choose several plans in the same page, and when you’re done, click on “Close”. You will see a new page on the “Products” tab that will show you a list of products that you have chosen. In this page, you can set the name of your reservations and the quantities (which corresponds to the number of Pv3 instances being purchased with a reservation) that you would like to purchase for your products. If you are unsure of how many instances to reserve, refer to the how many Reserved Instances should I buy section of the article. You can also delete products and edit your purchases. You can also see the breakdown of the total costs and of your immediate charges at the bottom right corner of the page.
+
+
+
+
* The reserved instance price is based on the following configurations as of 03/10/2021: Linux P1v3, Central US region, and a three-year term that is billed monthly.
+
+
When you are satisfied with your selections, make sure to head to “Review + buy” to finalize your purchase of the reserved instances.
+
+
How Many Reserved Instances Should I Buy?
+
+
If you are unsure of the quantity to buy, we recommend purchasing enough quantity to cover your steady state baseload. In other words, use the number of App Service Plan instances running for your baseload as a starting point for the quantity specified in the reserved instances purchase. For many customers, the baseload would be one or two instances. You can still use an auto-scale rule to increase the number of running App Service Plan instances above the baseload. Reserved instances pricing will cover the baseload and any additional compute from auto-scaling will be charged at the regular price.
+
+
Dev/Test Pricing
+
+
Dev/Test Pricing is a great option for customers who are looking to have discounted rates for the development and testing environments for their web apps. This option is available for Basic, Standard, Premium v2, and Premium v3 App Service Plans. For more information, you can look at the Azure Dev/Test Pricing page and scroll towards the bottom of the page where “App Service” is listed. If you are interested in getting an estimated price for your dev/test pricing, refer to next section under pricing calculator.
+
+
Pricing Calculator
+
+
The pricing calculator can be a handy tool to calculate the estimated monthly costs of running your services. In this section we will show you how to use the pricing calculator to calculate the estimated price for your reserved instances and for your dev/test pricing.
+
+
Getting Started
+
+
In the pricing calculator page, select “App Service” from the list of products and you will get a notification on the right side of the page.
+
+
+
+
When you’ve successfully added App Service in the calculator, you will see a section in the UX showing App Service information when you scroll down the page. You can configure values such as region, OS, pricing tier, and etc. to get an estimate for the cost. The next few sections in the article will go over how you can use this tool to calculate an estimate for your reserved instances savings and for your dev/test pricing.
+
+
Calculating Reserved Instances
+
+
Once you have selected “App Service” from the list of products and properly selected your configurations, look for the “Saving Options” and select from the reserved instances options. On the pricing calculator, it will also show the percentage of your savings for all the reserved instances options. The price will adjust accordingly after you have selected a reserved instances option.
+
+
The example below will show you how the savings options will look like for a P1v3 with a three-year reserved instance on Linux.
+
+
+
+
* Price is based on pricing calculator with the following configurations as of 03/10/2021: Central US region, Linux OS, and Premium V3 for one P1v3 instance for three-year reserved instances. Price is in USD and is displayed per month.
+
+
For another example, the image below will show you how the savings options will look like for a P1v3 with a three-year reserved instance on Windows.
+
+
+
+
* Price is based on pricing calculator with the following configurations as of 03/10/2021: Central US region, Windows OS, and Premium V3 for one P1v3 instance for three-year reserved instances. Price is in USD and is displayed per month.
+
+
As you can see from the examples above, the pricing calculator makes it convenient for you to calculate your estimated savings percentage with the reserved instances.
+
+
Calculating Dev/Test Pricing
+
+
Once you have selected “App Service” from the list of products and properly selected your configurations, scroll to the very bottom of the calculator web page and look for the “Show Dev/Test Pricing” slider. When you enable the slider to show dev/test pricing, you will notice that your price estimates will have changed to reflect dev/test pricing if supported for the selected pricing tier.
+
+
+
+
The set of examples below show an estimate using the pricing calculator for a P1v3 instance when you apply Dev/Test Pricing on Linux. The first screenshot shows the regular price for a Linux P1v3 instance. The second screenshot shows the discounted Dev/Test price. You will notice a $30.66 price difference which is ~24% less for dev/test pricing.
+
+
+
+
* Price is based on pricing calculator with the following configurations as of 03/10/2021: Central US region, Linux OS, and Premium V3 for one P1v3 instance for pay as you go without dev/test pricing. Price is in USD and is displayed per month.
+
+
+
+
* Price is based on pricing calculator with the following configurations as of 03/10/2021: Central US region, Linux OS, and Premium V3 for one P1v3 instance for pay as you go with dev/test pricing. Price is in USD and is displayed per month.
+
+
Another set of examples below show an estimate using the pricing calculator for a P1v3 instance when you apply Dev/Test Pricing on Windows. The first screenshot shows the regular price for a Windows P1v3 instance. The second screenshot shows the discounted Dev/Test price. There is a $147.46 price difference which is ~61% less for dev/test pricing.
+
+
+
+
* Price is based on pricing calculator with the following configurations as of 03/10/2021: Central US region, Windows OS, and Premium V3 for one P1v3 instance for pay as you go without dev/test pricing. Price is in USD and is displayed per month.
+
+
+
+
* Price is based on pricing calculator with the following configurations as of 03/10/2021: Central US region, Windows OS, and Premium V3 for one P1v3 instance for pay as you go with dev/test pricing. Price is in USD and is displayed per month.
+
+
From the two sets of examples above, you can see the savings you can get for using the dev/test pricing for your development and testing environments. This is a great option for hosting your development and testing environments with the same amount of performance and capacity as your production environments, but at a lower cost.
+
+
Summary
+
+
There are several ways for you to increase savings when running App Service . This article has described several App Service Plan offerings that help you save on prices, including reserved instances, and dev/test pricing options. We hope this article has equipped you with more information and presented you with a guide on how you can increase your savings when running App Service.
+
+
All prices in this article are all estimates during the time noted. Your final price would depend on your configurations for your App Service.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 13 minute read
+
+
+
+ • By Yutang Lin
+
+ • March 11, 2021
+
+
+
In this article, we will review different App Service offerings with side-by-side comparisons to show how you can save more with App Service. The offerings w...
How to use gRPC-Web with Blazor WebAssembly on App Service
+
+
+
+
+
+
+
+
+ 6 minute read
+
+
+
+ • By Jeff Martinez
+
+ • March 15, 2021
+
+
+
+
+
+
+
+
+
gRPC is a modern protocol which uses HTTP/2 to streamline messaging between clients and back-end servers and is an efficient way to connect services that require high-performance communication. However, HTTP/2 gRPC is not compatible with modern browsers and requires the use of gRPC-Web to communicate between a browser application and a gRPC server. gRPC-Web enables this scenario by having the browser send normal HTTP requests and acting as a proxy in front of the gRPC server to translate the requests to the browser. With gRPC-Web, you can create a .NET server app hosted on App Service using gRPC-Web middleware which operates as a translator between the browser application and the .NET server app. This translation maps incoming gRPC-Web requests to the appropriate .NET classes in the server app, and translates the server app’s return values into gRPC-Web responses that are sent back to the browser. If you would like to learn more about gRPC-Web, visit the gRPC blog.
+
+
In the following example, we’ll be using a .NET 5 Blazor WebAssembly application and replacing the existing JSON calls with gRPC-Web by enabling the gRPC-Web middleware in the startup configuration.
+
+
Create Blazor WebAssembly App
+
In Visual Studio, you will create a Blazor WebAssembly application that we can add gRPC-Web to.
+
+
Open Visual Studio and Create a new project and search for Blazor app. Highlight Blazor app, click Next, name your application and click Create.
+
+
Choose .NET 5.0 in the drop-down, highlight the Blazor WebAssembly App option and check the ASP.NET Core hosted option under the Advanced column before clicking the Create button.
+
+
+
+
Once your application is created, you will have a Client, Server, and Shared project under your solution.
+
+
Install packages
+
Before you add any code to your projects, you need to make sure the correct packages are installed on your Client, Server, and Shared projects.
+
+
Starting on the Shared project Right-click the project and go to Manage Nuget packages. Browse for and install the following packages in the Shared project:
+
+
Google.Protobuf
+
Grpc.Net.Client
+
Grpc.Tools
+
+
+
Next, follow the same process for the Shared project and go to your Server project to install these packages:
+
+
Grpc.AspNetCore
+
Grpc.AspNetCore.Web
+
+
+
Then, go to your Client project and install the following:
+
+
Grpc.Net.Client.Web
+
+
+
You can verify that each of the packages are installed by viewing the .csproj file of each project. You should see an added package reference for the ones you’ve installed.
+
+
Add Proto file and Service to the Shared project
+
Grpc works with Proto files which are written in protocol buffer language that define your messaging. To learn more about the language please visit this guide.
+
+
To add a proto file, Right-click the Shared project and go to Add, then New item. You can choose a Class file and name it weather.proto and hit Add. Visual Studio will pick up that it is a gRPC file as you will see a gRPC icon next to the file.
+
+
Remove the boiler plate code in the file and replace it with the following:
Next we will add the Weather Service class. This class will contain the same code and logic that is currently in the WeatherForecastController.cs file, which provides us with our weather data. Right-click the project and add a new class item naming it WeatherService.cs.
+
+
Add the following using statements and code to the class:
Now that you have your WeatherService added, you will notice that some of the objects won’t be recognized from the proto file. To remedy this, we’ll need to include a reference to the proto file in the Shared .cproj file ItemGroup so it can be recongized. Add the following to your ItemGroup in the .csproj file:
To configure the application to take advantage of gRPC-Web you need to register the gRPC service in your Startup.cs file. This enables you to use dependency injection to consume the service across the app. Add the following code to your ConfigureServices method in the Server Startup.cs file:
Next, you’ll add the gRPC-Web middleware to the apps configuration and register the gRPC service. This must be added after UseRouting and before UseEndpoints in the Configure method.
+
+
app.UseRouting();
+
+// must be added after UseRouting and before UseEndpoints
+app.UseGrpcWeb();
+
+app.UseEndpoints(endpoints=>
+{
+ // map to and register the gRPC service
+ endpoints.MapGrpcService<WeatherService>().EnableGrpcWeb();
+ endpoints.MapRazorPages();
+ endpoints.MapControllers();
+ endpoints.MapFallbackToFile("index.html");
+});
+
+
+
+
Configure gRPC-Web with the .NET client
+
In order to configure gRPC-Web to use in our Client project, you’ll need to add a gRPC channel that provides a connection to a gRPC server using the HttpClient object.
+
+
Add the following code to the Program.cs file in your Client project:
Now that gRPC-Web is configured in the client project, we need to adjust the code in the FetchData.razor file so we can test the gRPC calls. The injected HttpClient will no longer be needed, but we will replace that with the Weather Forecasts Client so we can retrieve the weather data. Replace the current code in the FetchData.Razor with the code below.
Once the FetchData.razor file is updated to output the weather data we can verify that we are using gRPC-Web by running our application locally Right-click anywhere on the application and go to Inspect. Find the Network tab and then visit the Fetch data page. The Weather forecast data will load and you will see the name of our method GetWeather show up. Click on the GetWeather name to view the Response Headers which show the content-type being application/grpc-web.
+
+
+
+
Deploying to App Service
+
Since we are using a Blazor WebAssembly application that is hosted on ASP.NET Core the deployment process is slightly different. You can still deploy to App Service as you typically would, but you’ll need to Publish the Server project. The hosted deployment serves the Blazor app to browsers from its hosted ASP.NET Core app that runs on a web server. Your Server app will have reference to the Client app DLLs as the apps are deployed together with the Client app being published in the wwwroot folder. Learn more about hosted deployments in the Blazor documentation.
+
+
Once your application is published you can verify that gRPC-Web is working using the same process from above by inspecting the Network in the browse. Your Request URL will now point to your App Service URL (myappname.azurewebsites.net) and the content-type: will still be application/grpc-web.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 6 minute read
+
+
+
+ • By Jeff Martinez
+
+ • March 15, 2021
+
+
+
gRPC is a modern protocol which uses HTTP/2 to streamline messaging between clients and back-end servers and is an efficient way to connect services that req...
In this article I will walk you through setting up a secure, resilient site with Azure App Service using some new features that have recently been released or are very close to release. The image below shows the basic architecture. One or more instances of your Web App in multiple regions with Azure AD authentication. Azure Front Door (AFD) will provide global load balancing and custom domain with certificates, and the Web Apps will be isolated to only receive traffic from the specific AFD instance.
+
+
+
+
This guide is organized into five steps:
+
+
+
Create a basic Web App with Azure AD Authentication
+
Add Azure Front Door
+
Add Custom Domain and Certificate
+
Restrict traffic from Front Door to Web App
+
Increase resiliency with multiple geo-distributed Web Apps
+
+
+
In closing, there are sections on alternative approaches, advanced scenarios, and an FAQ section.
+
+
Getting started
+
+
You can complete most of this guide using the Azure portal, but there are some advanced features that require scripting. I will be using Azure CLI throughout the walk-through, however Azure PowerShell or Azure Resource Manager templates will work as well. I am using bash through Windows Subsystem for Linux (WSL) to run the commands. If you are using a PowerShell or Cmd prompt, small syntax tweaks may be needed.
First, setup a Resource Group and a Web App with Azure AD Authentication. Choose a unique name for your Web App and feel free to change name of the resource group and location. If you have preferences for App Service Plan or other options, you can configure this as well.
+
+
az group create --name securewebsetup --location westeurope
+az appservice plan create --resource-group securewebsetup --name securewebplan --sku B1
+az webapp create --resource-group securewebsetup --plan securewebplan --name securewebapp2021 --https-only# Web App name must be globally unique
+
+
+
Debug page (optional)
+
+
To help debug the application, you can create a file called default.cshtml with the following content
App Service provides a simple way to setup authentication. The feature is sometimes referred to as Easy Auth. There is a new version just released and for this setup some of the new options are needed. The new Authentication feature is available in the Azure portal, but a few advanced configuration options are not yet exposed in the portal, so let’s look under the hood using the REST API.
+
+
You have to get the Resource ID of the Web App. It was returned when you created the Web App in the previous steps, and you can also find it in the portal under Properties. This goes for any resource.
+
+
+
+
Ensure that you can read the settings first. Pay attention to the api-version. You should see a lot of json returned when running this command:
+
+
az rest --uri /subscriptions/REPLACE-ME-SUBSCRIPTIONID/resourceGroups/REPLACE-ME-RESOURCEGROUP/providers/Microsoft.Web/sites/REPLACE-ME-APPNAME?api-version=2020-09-01 --method get
+
+
+
All the Authentication settings are defined in a json structure. There are many options to fine tune the configuration, but the snippet below is an extraction of the required settings needed for this scenario. Copy this into a file called auth.json:
The file has some placeholders that you need to fill in with your own values. You will generate these values in the next few steps. You have already come across the first two REPLACE-ME-WEBAPP-NAME occurrences. This value should be replaced with the name of your Web App (in my case this was “securewebapp2021”).
+
+
You can find the value for REPLACE-ME-TENANTID by running az account show and looking in the homeTenantId property.
+
+
Next, create an App registration in Azure AD. An App registration is a way to tell Azure AD that this Web App is allowed to authenticate users in the directory and that it can do so only using specific urls. The display name can be anything. The reply-url is your base url combined with a special callback path: https://securewebapp2021.azurewebsites.net/.auth/login/aad/callback
+
+
az ad app create --display-name securewebapp2021 --reply-urls https://securewebapp2021.azurewebsites.net/.auth/login/aad/callback
+
+
+
Replace REPLACE-ME-APPID in auth.json with the the appId from the returned output.
+
+
For the last placeholder REPLACE-ME-SECRETNAME, this will be the name of an App Setting in your Web App that contains the secret. The App Setting can reference a Key Vault secret if you prefer. You can pick any name. I will choose AAD_CLIENT_SECRET. To add the secret, run the following command (with the AppId from the previous step). If you leave out the password parameter, it will auto-generate a complex password:
+
+
az ad app credential reset --id REPLACE-ME-APPID --password"reP!@ce-w!th.VeRys3cr3tC0d!"
+
+
+
Add the value of the generated password to the App Settings of the Web App:
+
+
az webapp config appsettings set--resource-group securewebsetup --name securewebapp2021 --settings"AAD_CLIENT_SECRET=reP!@ce-w!th.VeRys3cr3tC0d!"
+
+
+
Finally, let’s update the Web App with the Authentication configuration (make sure you save your auth.json file and append /config/authsettingsV2 to the Resource ID):
+
+
az rest --uri /subscriptions/REPLACE-ME-SUBSCRIPTIONID/resourceGroups/REPLACE-ME-RESOURCEGROUP/providers/Microsoft.Web/sites/REPLACE-ME-APPNAME/config/authsettingsV2?api-version=2020-09-01 --method put --body @auth.json
+
+
+
If you browse to the site now, you should be redirected to consent to the App permissions and login to your Azure AD tenant. If you deployed the debug site, you will notice some extra headers prefixed with X-MS-CLIENT-PRINCIPAL.
+
+
2. Add Azure Front Door
+
+
Azure Front Door is a global, scalable entry-point that uses the Microsoft global edge network to create fast, secure, and widely scalable web applications. With Front Door, you can transform your global consumer and enterprise applications into robust, high-performing personalized modern applications with contents that reach a global audience through Azure.
+
+
Azure Front Door (Standard and Premium) combines the existing features of Front Door (Classic) with integrated CDN and WAF capabilities as well as some new advanced options to use private endpoints as origin (backend) and onboard Managed Certificates using TXT records, which can be helpful in a migration scenario.
+
+
+
+
Open the Azure portal. Create a new resource, search for Front Door, and select “Front Door and CDN profiles”
+
+
+
+
Use the Quick Create and under Basics, use the existing resource group. Give it a name and endpoint name, and select your App Service Web App. If you want to try out the private endpoint feature or WAF capabilities later, you should select the Premium tier. Once it is created, it typically takes 5-10 minutes to replicate globally. Go grab a coffee and come back when this is complete.
+
+
+
+
Alter authentication settings
+
+
After a good coffee, try to browse to the Front Door URL. In my case: https://secureweb.z01.azurefd.net. It appears to be working, but notice the address bar. It redirected you directly back to your Web App. To fix that you need to do a few things. First, update the App registration in Azure AD to allow authentication request coming from the new url. You can add multiple reply-urls by separating them with a space, but if you only want to allow authentication through Front Door, you can just replace it.
+
+
az ad app update --id REPLACE-ME-APPID --reply-urls https://secureweb.z01.azurefd.net/.auth/login/aad/callback https://securewebapp2021.azurewebsites.net/.auth/login/aad/callback
+
+
+
Second, it is time to look at one of the new features of Authentication in App Service. Open up the auth.json file again and in the login section under allowedExternalRedirectUrls, add the Azure Front Door url. You should also add it in the AAD validation section under allowedAudiences (remember the comma in both settings).
+
+
Finally, in auth.json, configure the Authentication framework to look for the original address. In forward proxies like Front Door, the address is typically sent in an http header called X-Forwarded-Host, which is covered by the Standard convention. The forwardProxy section goes to httpSettings. The final json file looks like this:
Save the file and run the az rest command again to update the settings:
+
+
az rest --uri /subscriptions/REPLACE-ME-SUBSCRIPTIONID/resourceGroups/REPLACE-ME-RESOURCEGROUP/providers/Microsoft.Web/sites/REPLACE-ME-APPNAME/config/authsettingsV2?api-version=2020-09-01 --method put --body @auth.json
+
+
+
You should now be able to access the Web App through Front Door and be authenticated. If you added the debug page, you should also see a few additional headers. One being X-Forwarded-Host that contains the url of the Front Door and the other being X-Azure-FDID which contains the unique ID of your Front Door instance (make a note of this as it will be used in step 4).
+
+
3. (Optional) Add Custom Domain and Certificate
+
+
+
+
With Azure Front Door, it’s easy to add a custom domain and certificate. If you do not already have a custom domain, you can purchase one from Azure App Service Domains. For this demo, I will be using a domain called reddoglabs.com purchased through App Service Domains and I will be using Azure DNS to host the public DNS records. Note that any domain registrar and public DNS provider can be used. If you are using an Azure DNS Zone in the same subscription, you have the added benefit of having Front Door add the needed records for you.
+
+
For the certificate, you can bring your own certificate or you can use the Managed Certificate option. With the latter, Front Door will take care of enrolling and renewing the certificate - I like that so I do not forget to update my certificate when it expires.
+
+
My DNS is in another subscription, so I will have to add it myself, but it will also explicitly show the steps needed.
+
+
+
+
After you added the domain, you need to prove that you own it. The new Front Door gives you a nice overview of the steps needed.
+
+
+
+
When clicking the Pending link in the Validation state column, you will get instruction for adding a TXT record to validate your domain ownership.
+
+
+
+
Time for another cup of coffee. The validation of the TXT record and the replication of the settings can take 5-10 minutes again.
+
+
Alter authentication settings
+
+
Azure AD App registration and App Service Authentication need to be aware of the new url. You can either append or overwrite with the new url depending on whether you want the other urls to work as well. Update the App registration with the this command (here I am appending):
+
+
az ad app update --id REPLACE-ME-APPID --reply-urls https://secure.reddoglabs.com/.auth/login/aad/callback https://secureweb.z01.azurefd.net/.auth/login/aad/callback https://securewebapp2021.azurewebsites.net/.auth/login/aad/callback
+
+
+
Modify the auth.json file and update the Authentication settings.
az rest --uri /subscriptions/REPLACE-ME-SUBSCRIPTIONID/resourceGroups/REPLACE-ME-RESOURCEGROUP/providers/Microsoft.Web/sites/REPLACE-ME-APPNAME/config/authsettingsV2?api-version=2020-09-01 --method put --body @auth.json
+
+
+
Associate and map custom domain
+
+
The final steps are to go back to the Domains overview in Front Door and associate the custom domain with the endpoint,
+
+
+
+
and add a CNAME DNS record to map the actual domain:
+
+
+
+
Allow another 5-10 minutes to replicate the settings globally, and you should now be able to access an authenticated Web App through Front Door using a custom domain and certificate.
+
+
4. Restrict traffic from Front Door to Web App
+
+
+
+
At this point, you are still able to access the Web App directly. In this step, you will restrict access to the Web App so traffic will only be allowed through Front Door. To do this, another new feature will be used. Access restrictions in App Service recently added the ability to create rules based on Service Tags and filter by http headers. Azure CLI support for the new features is still under construction, but since you are familiar with using REST calls by now, let’s do that.
+
+
Create a json file named restrictions.json with the the following content and replace the placeholder with the specific Front Door ID found in step 2. It is also visible in the Overview section of the Front Door instance in the Azure portal:
After you added the Front Door ID in the json file, run the following script to deploy the restriction (notice the change in the URI: /web instead of /authsettingsV2):
+
+
az rest --uri /subscriptions/REPLACE-ME-SUBSCRIPTIONID/resourceGroups/REPLACE-ME-RESOURCEGROUP/providers/Microsoft.Web/sites/REPLACE-ME-APPNAME/config/web?api-version=2020-09-01 --method put --body @restrictions.json
+
+
+
Now, if you access the site directly, you should immediately see the blue 403 - Forbidden error.
+
+
5. Increase resiliency with multiple geo-distributed Web Apps
+
+
+
+
To improve resiliency of your App and protect against regional outages, you can deploy your app to multiple regions. Let’s add an instance in West US. You can reuse most of the scripts, but of course you need to change the name in all lines. Since direct access to the Web App is already blocked, you can either remove or ignore the direct Web App url reference in auth.json.
+
+
To make it easier to notice which site is accessed, you can change the background color of the debug page in the alternative site by changing the last two digits of the body background-color to FF (light blue) and create a new zip file:
After the Web App is configured, open the Front Door instance in the Azure portal and add the new Web App as origin (backend) in the current origin group and update it:
+
+
+
+
Front Door default load balancing behavior is to round robin traffic between the fastest and the next fastest origins within the configured latency sensitivity, but you can modify that. If you refresh enough times, you should be seeing the page change color (and the Request url in the debug page change).
+
+
Alternative approaches and advanced scenarios
+
+
In this section, I will discuss some alternative approaches and advanced scenarios.
+
+
Application Gateway
+
+
Instead of Front Door, or in addition to Front Door, you can use Azure Application Gateway to add WAF capabilities and advanced routing and rewrite logic. It can also be used to provide regional load balancing. Application Gateway currently does not support Managed Certificate, so you will have to bring your own certificate.
+
+
Application Gateway deviates from the standard http header used for the forwarded host. It uses a header called X-Original-Host. For the Authentication configuration in auth.json, you will have to change the convention to Custom and specify X-Original-Host as the customHostHeaderName. The rest of the settings and steps should be identical.
To secure the incoming traffic to the Web App(s), the access restriction feature was used. If you prefer private endpoints, this is also possible. The next generation Azure Front Door supports setting up a private endpoint from your Front Door instance directly to your Web App. For App Service, private endpoints require the Premium tier, so you need to scale up the App Service Plan. Besides that, the only change will be the setup of origin in Front Door, which is where you can request the creation of a private endpoint, and then from the Web App(s) you can approve it.
+
+
The step of uploading the debug page will require some additional setup. The SCM site will also only be available through the private endpoint. You will have to run the script from within a network with line-of-sight and proper DNS resolution for the private endpoint.
+
+
Custom domain for SCM Site
+
+
While not directly related to the Authentication part, you may want/need to expose the SCM site through a proxy if you want access through a custom domain or if you want to expose a private endpoint enabled SCM site externally. A post on how to do that was recently published.
+
+
Custom health probe path
+
+
If you have a custom health probe path, you can configure the Authentication layer in App Service to allow unauthenticated traffic on specific paths. These paths are configured in the auth.json file in excludedPaths under globalValidation. An example of excluding the debug page if accessed directly will look like this:
You can now browse directly to that page (but will be asked for authentication if you just go to /)
+
+
FAQ
+
+
Q: On sign in, I get error AADSTS50011: The reply URL specified … What is wrong?
+
+
Most likely this is because the address does not match the reply-url configured for the Azure AD App registration.
+
+
+
+
Q: I am using custom routing rules in Front Door. Anything I should pay attention to?
+
+
Make sure you have a routing rule for .auth/* in addition to your content rules.
+
+
Q: I do not have permissions to create App registrations in my Azure AD tenant, what to do?
+
+
If your organization locked down the ability to create App registrations, you will need to find someone in your organization with these permissions. It can either be the tenant admin or delegated with the built-in Application developer og Application administrator roles; or a custom Application registration creator role specific for this purpose.
+
+
Alternatively you can use another identity provider such as Facebook, GitHub, Twitter or any custom provider using the OpenIdConnect specification.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
In this article I will walk you through setting up a secure, resilient site with Azure App Service using some new features that have recently been released o...
We are happy to announce the General Availability of a number of improvements to the access restriction feature in App Service.
+
+
Service tag-based rules
+
+
Networking service tags define the set of IP CIDR ranges used for a given Azure service. As these ranges change, the tags will be automatically updated to reflect the change with no change needed from the customer side.
+
+
The tags cover different scopes such as data plane and management plane, and different directions like inbound, outbound and both. Service tags can be global or regional. For example, AzureCloud covers all ranges used in Azure public cloud and AzureCloud.WestEurope covers the subset of these ranges used in the West Europe region.
+
+
Service tag-based rules can be used to allow or deny inbound traffic to App Service. Common use cases include:
+
+
+
Azure Traffic Manager health probes, which are covered by the AzureTrafficManager service tag
+
Logic Apps, where an API call hosted in an App Service is part of the flow. These can also be regional like LogicApps.SouthEastAsia
+
Azure Front Door backend traffic. Used to isolate traffic between the Front Door infrastructure and your App Service. Tag name is AzureFrontDoor.Backend
+
Application Insight availability probes using ApplicationInsightsAvailability
+
+
+
Azure portal supports the most common scenarios and for advanced configuration, you can use Azure PowerShell.
+
+
Multi-source rules
+
+
Multi-source rules allow you to define multiple IP address ranges as part of a rule. Each rule can support up to 8 ranges. Use cases for multi-source rules include:
+
+
+
You need to specify more than 512 ranges for an App Service
+
You want to logically group ranges in a rule. For example, both the IPv4 and IPv6 ranges of an internal service
+
You want to combine a logical group of ranges with a http header filter
+
+
+
Multi-source rules are currently supported through PowerShell.
+
+
Http header filters
+
+
In addition to specifying an IP range or service tag, you can also define specific values of http headers that must also be evaluated. Common cases are:
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
In this article I will walk you through setting up a secure, resilient site with Azure App Service using some new features that have recently been released o...
+
+
+
+
+
+
+ 6 minute read
+
+
+
+ • By Jeff Martinez
+
+ • March 15, 2021
+
+
+
gRPC is a modern protocol which uses HTTP/2 to streamline messaging between clients and back-end servers and is an efficient way to connect services that req...
+
+
+
+
+
+
+ 13 minute read
+
+
+
+ • By Yutang Lin
+
+ • March 11, 2021
+
+
+
In this article, we will review different App Service offerings with side-by-side comparisons to show how you can save more with App Service. The offerings w...
+
+
+
+
+
+
+ 5 minute read
+
+
+
+ • By Jeff Martinez
+
+ • March 4, 2021
+
+
+
Windows containers on App Service can help you easily modernize your application by making it easier to Lift-and-Shift to App Service and install custom depe...
When enabling private endpoint for a web app, both the web app and the Source Control Manager (SCM) site, also sometimes referred to as kudu, are locked down...
+
+
+
+
+
+
+ 4 minute read
+
+
+
+ • By Yutang Lin
+
+ • March 2, 2021
+
+
+
App Service Managed Certificate (preview) now lets you secure your apex domains on your web apps at no additional charge. This feature is similar to the curr...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Jeff Martinez
+
+ • March 2, 2021
+
+
+
Source Network Address Translation (SNAT) ports are used by App Service to translate outbound connections to public IP addresses. However, there are limitat...
+
+
+
+
+
+
+ 4 minute read
+
+
+
+ • By Jason Freeberg
+
+ • March 1, 2021
+
+
+
An earlier article explained how to use self-hosted Azure DevOps agents to build and deploy your applications to a web app that has Private Endpoints enabled...
A crash of a process happens when the process terminates due to an unhandled exception within the application code. A crash leads to a restart and all the in...
Troubleshooting networking & connectivity issues when running on App Services just became easier. We are happy to announce the release of our new diagnostic tool ‘Network/Connectivity Troubleshooter’ available now in the Diagnose & Solve Problems blade.
+
+
You can access the tool by going to the Diagnose & Solve Problems blade and either use the search bar to search for it or use the quick link available under popular troubleshooting tools section:
+
+
+
This guided troubleshooter takes you step by step to understand your issue and provide curated solutions based on your inputs:
+
+
Unable to connect to a resource, such as SQL or Redis or on-prem, in my Virtual Network
+
+
This flow will start by running the following checks on your app:
+
+
VNet integration health
+
Networking configuration checks
+
+
+
If an issue is found, the troubleshooter will display the issue along with the recommended next steps to you:
+
+
+
If everything looks healthy or just a warning insights was discovered, the flow will continue to ask for an endpoint to test connectivity to. You can use a hostname:port or IP:port combination to test the connectivity.
+
+
Please note that this is just a tcpping from your app’s instance to the specific endpoint. The connection could succeed on a tcp level, but you might still be facing issues executing http requests for example.
+
+
+
The troubleshooter will show you the results clearly along with recommendations:
+
+
+
Tried to configure VNet integration via Azure Portal or ARM template, but it failed
+
+
If you attempted to connect your app to a subnet and it failed and would like to get more information, this flow will help you with this. You can select the VNet/subnet combo that you’re attempting to connect to, and the tool will give you an insight if the integration will succeed or not along with a detailed explanation.
+
+
+
Learn more about VNet integration
+
Finally, if you are new to VNet integration with App Services and would like to learn more, this flow will show you common docs that help our customers learn about general VNets in Azure as well as how to integrate an App Service with a VNet.
+
+
+
What’s next?
+
+
Within the next few months, we will be adding new flows to allow you to diagnose & solve more networking related issues with this troubleshooter. If you have any questions or feedback, please reach out to our team at diagnostics@microsoft.com
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Troubleshooting networking & connectivity issues when running on App Services just became easier. We are happy to announce the release of our new diagnos...
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Jeff Martinez
+
+ • April 14, 2021
+
+
+
+
+
+
+
+
+
.NET 5 is the first major release in the .NET unification journey bringing together the best of Core, Framework, Xamarin, and Mono to provide an improved developer experience. Although .NET 6 (Preview) is currently available, it is recommended that you migrate your .NET 3.1 applications to .NET 5 prior to migrating to .NET 6 (LTS).
+
+
This article outlines what needs to be addressed in an existing .NET 3.1 application when migrating to .NET 5 before publishing it to App Service. For information on hosting .NET 5 applications on App Service please visit our blog.
+
+
Update your application
+
+
The first step to updating your application to .NET 5 is to go to the project file and update the Target Framework Moniker. Setting the Target Framework tells your application which version you’d like to target by specifying the set of APIs that you want to be made available to your application or library.
+
+
In your .csproj file, replace netcoreapp3.1 with net5.0 to update the targeted version
After you’ve updated the Target Framework and saved the application. You will notice that your bin is populated with .NET 5 Debug and Release folders, these will include necessary .json, .exe and .dll files that are needed when publishing to App Service.
+
+
+
+
These folders will remain empty until you Build your solution locally. Go to Build in the top menu bar in Visual Studio and select Build Solution to populate the net5.0 folder. Your Release folder will populate when you Publish your application.
+
+
Package References
+
+
Depending on your application, you may have a number of package references that you rely on. You will need to update each package references Version to match the new version.
+
+
In your .csproj file, update the Version from “3.x.x” to “5.0.0”
If you are using the global.json file to specify which SDK version you want to use in your application, then you will need to update this as well. If you are not using a global.json file then you can skip this step.
+
+
Replace the SDK version from 3.1.200 to 5.0.100
+
+
{
+ "sdk":{
+ "version":"3.1.200"
+ }
+}
+
+
+
{
+ "sdk":{
+ "version":"5.0.100"
+ }
+}
+
+
+
Docker
+
+
If you are using Docker to containerize your .NET applications you will need to update your Dockerfile FROM statements for your base image and SDK version. See below for examples for both Windows and Linux.
+
+
Before
+
+
# .NET 3.1
+FROM mcr.microsoft.com/dotnet/aspnet:3.1 AS base # Windows
+# FROM mcr.microsoft.com/dotnet/aspnet:3.1-buster-slim # Linux
+
+WORKDIR /app
+EXPOSE 80
+
+FROM mcr.microsoft.com/dotnet/sdk:3.1 AS build # Windows
+# FROM mcr.microsoft.com/dotnet/sdk:3.1-buster-slim AS build # Linux
+WORKDIR /src
+COPY ["mydotnetapp/mydotnetapp.csproj", "mydotnetapp/"]
+RUN dotnet restore "mydotnetapp/mydotnetapp.csproj"
+COPY . .
+WORKDIR "/src/mydotnetapp"
+
+RUN dotnet build "mydotnetapp.csproj" -c Release -o /app/build
+FROM build AS publish
+RUN dotnet publish "mydotnetapp.csproj" -c Release -o /app/publish
+FROM base AS final
+
+WORKDIR /app
+COPY --from=publish /app/publish .
+ENTRYPOINT ["dotnet", "mydotnetapp.dll"]
+
+
+
+
After
+
+
# .NET 5.0
+FROM mcr.microsoft.com/dotnet/aspnet:5.0 AS base # Windows
+# FROM mcr.microsoft.com/dotnet/aspnet:5.0-buster-slim AS base # Linux
+
+WORKDIR /app
+EXPOSE 80
+EXPOSE 443
+
+FROM mcr.microsoft.com/dotnet/sdk:5.0 AS build # Windows
+# FROM mcr.microsoft.com/dotnet/sdk:5.0-buster-slim AS build # Linux
+
+WORKDIR /src
+COPY ["mydotnetapp/mydotnetapp.csproj", "mydotnetapp/"]
+RUN dotnet restore "mydotnetapp/mydotnetapp.csproj"
+COPY . .
+WORKDIR "/src/mydotnetapp"
+
+RUN dotnet build "mydotnetapp.csproj" -c Release -o /app/build
+FROM build AS publish
+RUN dotnet publish "mydotnetapp.csproj" -c Release -o /app/publish
+FROM base AS final
+WORKDIR /app
+
+COPY --from=publish /app/publish .
+ENTRYPOINT ["dotnet", "mydotnetapp.dll"]
+
+
+
+
After you’ve completed the updates in your application to .NET 5 you are now ready to publish to App Service as you normally would. While the publish is ongoing it will populate the Release files mentioned above in the net5.0 reference folder equipping your application with the necessary files to run on App Service.
+
+
Update Stack Settings
+
+
After you’ve published your application to App Service you may choose to update your Stack settings (this sets the language and SDK version used to run the app) in your applications Configuration to match the newer version. While this step is not required to successfully run your updated application on Windows App Service, it is recommended to prevent confusion in the future when looking at the Configuration settings.
+
+
Go to Configuration under Settings, click the General settings tab and update the Stack settings .NET Version to .NET 5. Then click the Save icon above.
+
+
+
+
Once it is saved, your application will restart. If you are using Linux, your Major and Minor version will auto-populate to .NET 5 upon publishing.
+
+
From here your application is now updated and configured to use .NET 5. For more information on migrating your .NET 3.1 apps to .NET 5, please visit the documentation.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 4 minute read
+
+
+
+ • By Michimune Kohno and Sanghmitra Gite
+
+ • April 14, 2021
+
+
+
The Azure App Service is a PaaS solution offering in Azure which constantly updates the platform. One of the top requests from customers is to receive a noti...
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Jeff Martinez
+
+ • April 14, 2021
+
+
+
.NET 5 is the first major release in the .NET unification journey bringing together the best of Core, Framework, Xamarin, and Mono to provide an improved dev...
+
+
+
+
+
+
+ 4 minute read
+
+
+
+ • By Michimune Kohno and Sanghmitra Gite
+
+ • April 14, 2021
+
+
+
+
+
+
+
+
+
The Azure App Service is a PaaS solution offering in Azure which constantly updates the platform. One of the top requests from customers is to receive a notification before an upgrade operation happens.
+
+
We are happy to announce that notifications for scheduled maintenance on App Service Environments is now available in Preview. With these notifications, you will be able to receive email or SMS text alerts before a platform upgrade starts. You can also invoke Azure Functions or Logic Apps based on these notifications. This feature has been rolled out for App Service Environments (ASEs) across our regions. This article shows how to set up email and SMS alerts, as well as Function and Logic Apps to consume the events.
+
+
+
Support for the multi-tenant version of App Service will be coming soon.
+
+
+
Overview
+
+
Our maintenance notification for App Service is an event in Azure Monitor. This means that you can set up your email address and/or SMS phone number when a notification is generated. You can also set up a trigger for your custom Azure Function or Logic App, which allows you to automatically take action to your resources. For example, you can automatically divert all the traffic from your ASE in one region which will be upgraded to ASE in another region in order to avoid any potential impact. Then you can automatically change the traffic back to normal when an upgrade completes. Please refer to Logic App sample for automatic traffic diversion for Azure App Service for more details.
+
+
Viewing upgrade notifications
+
+
On the Azure portal, go to Home > Monitor > Service Health > Planned maintenance. Here you can see all active (including upcoming or in-progress) notifications for the selected subscriptions. To make it easy to find App Service upgrade events, click Service box, check all App Service types and uncheck everything else. To see past notifications, navigate to Health history and filter Planned maintenance from the Health Event Type box.
+
+
+
+
Setting up alerts
+
+
+
Open Azure portal, sign in with your credentials.
+
Search an icon named Monitor and click it. If you cannot see it, click the big right arrow on the right to show All services, then search Monitor.
+
In the left menu items, click Alerts.
+
Click Service Health.
+
Click Add service health alert at the top center.
+
In the Condition section, choose the subscription that owns your ASEs.
+
At the Service(s) box, choose all items starting with App Service:
+
+
App Service
+
App Service \ Web Apps
+
App Service (Linux)
+
App Service (Linux) \ Web App for Containers
+
App Service (Linux) \ Web App.
+
+
+
At the Region(s) box, make sure to check the regions of the ASEs.
+
At the Event type box, check Planned maintenance.
+
In the Actions section, click Add action groups.
+
Click Create alert rule.
+
Select a subscription that your ASE belongs to.
+
Choose a resource group and name an action group. Set Display name to something you can easily identify the action (IMPORTANT: The display name will be shown in every email/SMS/post of the notifications.)
+
If you want to receive text notifications: In the Notifications section, choose Email/SMS message/Push/Voice at the Notification type. Then choose output channels you need (For example, Email or SMS.) Put email addresses or phone number as necessary.
+
If you want to hook up your custom automation: In the Actions section, choose Azure Function or Logic App at the Action type. Put a name into the Name. Select your app.
+
Press Save changes. The page will go back to the Rules management page.
The first notifications will be created about 60 to 90 minutes before an actual upgrade operation starts. We don’t create notifications anything earlier due to some limitations at this moment.
+
+
Once the upgrade starts, we send in-progress notifications every 12 hours until the operation completes. After it’s finished we send a notification of completion.
+
+
Is it in preview now?
+
+
Yes, it’s currently in preview. We are collecting feedback and usage telemetry. We will announce a date for General Availability as one becomes available.
+
+
Can we get notifications earlier, like one day before?
+
+
At this time, 60 minutes to 90 minutes is the earliest notification lead-time.
+
+
Is it only available for ASEs?
+
+
Yes, currently it is only available for ASEs. We are actively working on enabling it for the multi-tenant version of App Service.
+
+
Can I invoke my Azure Function when a notification comes?
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Jeff Martinez
+
+ • April 15, 2021
+
+
+
+
+
+
+
+
+
.NET 6 is the latest release version that will include the final pieces bringing the best of Core, Framework, Xamarin, and Mono to a unified platform that started with .NET 5. This version is currently available as a preview version for use in new or existing applications with a planned GA date of November 2021. The final release of .NET 6 will be the Long-Term Support (LTS) version of the new .NET to be supported for 3-years. Find more information on the release here.
+
+
To get started with .NET 6 (Preview) on App Service you can use one of two deployment methods. A Self-Contained deployment will allow you to deploy your app on machines that don’t have the runtime installed. You can also deploy your application with a more portable solution using a Container which will package your app and dependencies to run on App Service.
+
+
+
Migrating your .NET 3.1 apps to .NET 6? We recommend going to .NET 5 before jumping to 6, see our previous article.
+
+
+
Local Setup
+
+
In order to setup .NET 6 in your application you need to first install the .NET 6 SDK. For our examples below we will be using the latest .NET SDK 6 Preview 2. If you’re on Windows using Visual Studio, you will also need to download the latest Visual Studio Preview version here.
+
+
Self-Contained Deployment
+
+
A Self-Contained deployment enables you to run .NET 6 because it doesn’t rely on the presence of shared components on the target system and all components including Core libraries and runtime are with the application and isolated from other apps. This way you have sole control of which version your application is running. Self-contained deployments are supported for both Windows and Linux apps. Note that with self-contained applications you should be aware of large deployments and managing updates as this will take up more hard drive space and cause you to be responsible for supplying updated versions of your app with new security patches.
+
+
+
+
To complete a self-contained deployment in .NET you would first create your project as usual then choose .NET 6 (Preview) for your apps version after selecting your application template. Select Create and modify your application as needed.
+
+
+
+
+
To publish, Right-Click your project and select publish. In the latest version of Visual Studio you can choose where your target publish is from a new menu. Select Azure.
+
+
+
+
+
Then select Azure App Service (Windows) or Azure App Service (Linux) depending on your preference on the following screen.
+
+
+
+
+
Next, choose a previously created App Service or create one from Visual Studio and fill out the required information as you normally would when publishing. When you reach the publish screen click the pencil icon to edit your Deployment Mode for publishing your application.
+
+
+
Then, Choose the Deployment Mode option and make sure Self-Contained is chosen.
+
+
+
+
+
+
After you select the Self-Contained option your Target Runtime will auto-populate to linux-x64 or win-x86 depending on your operating system selection. Save your new settings and click Publish on the preceding screen to publish to App Service and launch your application using .NET 6. More information on self-contained deployment can be found here.
+
+
Container Deployment
+
+
The other option for running your .NET 6 (Preview) application is to deploy a Docker container to App Service on Linux or Windows. When deploying a container, you are packaging the application and its dependencies into a Linux or Windows based image to run on the App Service platform. This enables your application to be more portable in nature as it is not reliant on the host operating system and has the runtime and SDK added into the image.
+
+
Once you have your application setup for .NET 6, the steps to deploy a containerized application would be the same as any other container deployment. Right-click your project, Add -> Docker Support, then choose Linux or Windows. Your .NET 6 project will have a new Dockerfile added with the .NET 6.0 base image and SDK ready for you to publish.
+
+
+
+
After you have added Docker support, you will publish it to a registry, and create your App Service as usual. See our documentation for more detail on deploying a containerized application.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Jeff Martinez
+
+ • April 15, 2021
+
+
+
.NET 6 is the latest release version that will include the final pieces bringing the best of Core, Framework, Xamarin, and Mono to a unified platform that st...
We are happy to announce the availability of Auto Heal feature for Linux apps on Azure App Service. Auto Heal allows you to mitigate your apps when it runs into unexpected situations like HTTP server errors, resource exhaustion, etc. You can configure different triggers based on your need and choose to recycle the app to recover it from a bad state. This functionality has been a part of Azure App Service Windows for quite some time and today we are happy to announce the availability for apps running on the Linux stack.
+
+
Enabling Auto Heal in the Portal
+
+
On your Linux app, click Diagnose and Solve problems > Diagnostic Tools > Auto-Heal.
+
+
+
+
Supported Triggers
+
+
Auto Heal for Linux supports the following triggers:
+
+
+
+
Request Duration - This trigger can help you mitigate an app that is slow to respond to requests. You can even specify the mitigation to kick in if specific URLs take longer than the expected duration.
+
+
+
+
+
Request Count - If you want to recycle your container after a fixed number of requests, you can configure the request count rule.
+
+
+
Status Codes - If the app starts failing unexpectedly, this trigger can help you recover it by restarting the container. You can choose either a range of status codes or a single HTTP status code. The trigger also allows you to specify specific request paths.
+
+
+
+
+
+
+
Note: The only supported action is to Recycle the container. More actions will be supported in the future.
+
+
+
Finalize Configuration
+
+
Overriding the Startup Time (optional) - It is a good practice to specify a startup time greater than the average startup time for your app. By modifying the startup time, you can specify how much time the mitigation rule should wait after the container startup before the mitigation rule triggers again.
+
+
Once the rules are configured, review them to ensure they are configured correctly and click the Save button.
+
+
+
+
Get ahead of your app’s issues and automatically mitigate these unexpected behaviors with Auto Heal in App Service Diagnostics.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
We are happy to announce the availability of Auto Heal feature for Linux apps on Azure App Service. Auto Heal allows you to mitigate your apps when it runs i...
“Rød grød med fløde” - hmm, what language is that? Keep reading if you want to find out.
+
+
In this article I will walk you through setting up a Web App with secure, network-isolated communication to backend services. The Web App will allow you to type in a text, and using Cognitive Services Language Detection, you can detect the language of the given text. The authentication key for Cognitive Services will be stored in Key Vault, and App Service will authenticate with Key Vault using Managed Identity. All traffic will be isolated within your Virtual Network using virtual network integration and private endpoints.
+
+
The scenario is intentionally kept simple to focus on the architecture and configuration; but with a practical purpose I find it more easy to relate to. The backend services can be extended with the many other services supporting Private Endpoint like Azure SQL, Cosmos DB, App Configuration, and even other App Service Web Apps or Functions by following the same pattern.
+
+
+
+
This guide is organized into four steps:
+
+
+
Create network infrastructure
+
Set up backend services
+
Create network integrated Web App
+
Connect “the dots”
+
+
+
In closing, there are sections on alternative approaches, advanced scenarios, and FAQ.
+
+
Getting Started
+
+
This is the second article in a series focusing on network security. If you missed the first one, you can find it here, and it includes a more detailed getting started section covering setting up the scripting environment.
+
+
This article will also use the Azure CLI executed in bash shell on WSL to set up the environment. It could be done using teh Azure portal, Resource Manager templates or Azure PowerShell. CLI was chosen as I find it easier to follow and explain the individual steps and configurations needed.
+
+
Remember in the scripts to replace all the resource names that need to be unique. This would be the name of the Web App, Key Vault, Cognitive Services account, and custom domain. You may also change location if you want something closer to home. All other changes are optional.
+
+
1. Create Network Infrastructure
+
+
First, set up a Resource Group with a Virtual Network. The virtual network should have at least two subnets: one for the virtual network integration and one for the private endpoints. The address-prefix size must be at least /28 for both subnets; small subnets can affect scaling limits and the number of private endpoints. Go with /24 for both subnets if you are not under constraints.
+
+
az group create --name securebackendsetup --location westeurope
+az network vnet create --resource-group securebackendsetup --location westeurope --name securebackend-vnet --address-prefixes 10.0.0.0/16
+
+
+
For the subnets, there are two settings that we need to pay attention to. This is often set by the portal or scripts, but here it is called out directly. Delegation “Microsoft.Web/serverfarms” informs the subnet that it is reserved for virtual network integration:
… and now the core network setup is done. We can now create our backend resources.
+
+
2. Set Up Backend Services
+
+
In this section, we will set up the Key Vault and the Cognitive Services (CS) account and store the access key for CS in Key Vault. We will also create the private endpoints and configure the services to block public traffic. First create the services:
Then we need to add the access key from CS as a secret in Key Vault. There are several ways to do this: directly in the Portal or using the CLI. What matters here is that the Identity (in this case, you) must have permissions to write secrets to Key Vault. We are using a new permission model in Key Vault, where the data plane permissions are set as RBAC permissions. In this mode, no default data plane permissions are set when creating the Key Vault.
+
+
I am storing properties in variables for reuse in later steps. The --output tsv will ensure that the values do not have quotes. The --query parameter will allow me to return only a specific property.
+
+
+
Note: The syntax for using variables depends on your choice of OS, shell and scripting language.
+
+
+
Assign permissions for you (the signed in user) to write secrets. You can optionally use a service principal or other users if you have delegated responsibility:
+
+
my_id=$(az ad signed-in-user show --query objectId --output tsv)
+kv_resource_id=$(az keyvault show --name securekeyvault2021 --queryid--output tsv)
+az role assignment create --role"Key Vault Secrets Officer"--assignee-object-id$my_id--scope$kv_resource_id
+
+
+
Then get the key from CS and store as a secret in Key Vault. We extract the URI of the secret as we need this in a later step. You can perhaps copy the secret in your notes if you plan on finishing later. The secret set command will display the secret in the shell if you are not querying a specific property. An alternative to tsv is to use --output none.
+
+
+
Tip: In bash shell, which I am using, you can see the values of a variable by using the echo command, e.g. echo $kv_secret_uri
Next, let’s create the Private Endpoints to connect the backend services to the virtual network. We already have the needed Key Vault Resource ID $kv_resource_id in a variable from a previous step:
… and create a DNS Zone Group. This will create the DNS record for the private endpoint in the DNS Zone (and remove it if the private endpoint is deleted):
Finally, let’s block public traffic. For CS, this property is not exposed in the official command, but we know our way around. You may need to fiddle a bit with the syntax for the az rest command if you are using an alternative shell/OS combination:
Everything is locked down now and you cannot even get to the Key Vault secrets through the Azure portal. In the Key Vault Networking blade, you can add the public IP of your client if you need to view or update the secrets.
+
+
3. Create Network Integrated Web App
+
+
Now we get to creating the actual Web App. To use virtual network integration, we need at least the Basic SKU. The virtual network integration feature allows outbound traffic to flow directly into the virtual network:
Now, store the name of your CS account for the code to query. Replace securecstext2021 with the name of your account:
+
+
az webapp config appsettings set--resource-group securebackendsetup --name securebackend2021 --settingsCS_ACCOUNT_NAME=securecstext2021
+
+
+
As a last step in this section, we need to generate a Managed Identity, grant this identity read secrets permissions on the Key Vault, and reference the secret in an App Setting. We will reuse the Resource ID variable from a previous step. Go back up if you missed that. The identity command can directly assign permissions as part of the command, so we will grant the Web App “Key Vault Secrets User” (read) permissions:
You can now browse to the Web App and all outbound traffic from the Web App will be routed through the virtual network.
+
+
4. Connect “The Dots”
+
+
All the infrastructure is now in place and we just need a bit of code to glue it all together.
+
+
I will be using php as it can run on both Windows and Linux App Service Plans, is easy to read, and allows for a single-file solution. Please do not mind the missing error handling, retry logic, etc. as this is a proof-of-concept. Copy the following code into a file called index.php and run these commands:
<?php
+if(!empty($_GET['text'])){
+ $text=urldecode($_GET['text']);
+ $payload=[
+ 'documents'=>array([
+ 'id'=>'1',
+ 'text'=>$text
+ ])
+ ];
+ $json_payload=json_encode($payload);
+ $cs_key=getenv('CS_ACCOUNT_KEY');
+ $cs_name=getenv('CS_ACCOUNT_NAME');
+
+ $options=array(
+ 'http'=>array(
+ 'method'=>"POST",
+ 'header'=>"Ocp-Apim-Subscription-Key: ".$cs_key."\r\n".
+ "Content-Type: application/json\r\n".
+ "Accept: application/json\r\n".
+ "Connection: close\r\n".
+ "Content-length: ".strlen($json_payload)."\r\n",
+ 'content'=>$json_payload
+ )
+ );
+
+ $context=stream_context_create($options);
+ $cs_text_api_url='https://'.$cs_name.'.cognitiveservices.azure.com/text/analytics/v3.0/languages';
+ $detection_result=file_get_contents($cs_text_api_url,false,$context);
+}
+?>
+<!DOCTYPE html>
+<htmllang="en">
+<head>
+ <metacharset="utf-8"/>
+ <title>Language detector</title>
+ <script src="https://ajax.googleapis.com/ajax/libs/jquery/2.1.3/jquery.min.js"></script>
+ <script src="script.js"></script>
+</head>
+<body>
+<h3>Language detector</h3>
+<formaction=""method="get">
+ <inputtype="text"name="text"value="<?phpecho$text;?>"/>
+ <buttontype="submit">Detect</button>
+</form>
+<br/>
+<?php
+ if(!empty($detection_result)){
+ $json_result=json_decode($detection_result);
+ $detected_language=$json_result->documents[0]->detectedLanguage->name;
+ $confidence_score=$json_result->documents[0]->detectedLanguage->confidenceScore;
+ if($confidence_score>0.9){
+ echo'<div><strong>I am quite sure this is: '.$detected_language.'</strong></div><br/>';
+ }elseif($confidence_score==0){
+ echo'<div><strong>I have no clue - type in some more text</strong></div><br/>';
+ }elseif($confidence_score<0.3){
+ echo'<div><strong>Here is a wild guess: '.$detected_language.'</strong></div><br/>';
+ }else
+ {
+ echo'<div><strong>I could be wrong, but it sounds a bit like: '.$detected_language.'</strong></div><br/>';
+ }
+
+ echo'<span style="color:white">Raw: '.$detection_result.'</span><br/>';
+ }
+?>
+</body>
+</html>
+
+
+
You are now ready to test the service.
+
+
In Closing
+
+
What language is “Rød grød med fløde”? With this new solution, you should be able to use the AI engine to determine that it is Danish - my native language. It is a well known challenge for foreigners to pronounce, and you can probably find videos of this online. You may also have noticed in the code, that I added the “classic” same font color debug output for convenience.
+
+
+
+
As a bonus challenge, you can try to extend the solution to be able to translate into English and find out what it means. You should find what you need for that here.
+
+
Alternative Approaches and Advanced Scenarios
+
+
In this section, I will discuss some alternative approaches and advanced scenarios.
+
+
Service endpoints
+
+
Service endpoint is an alternative Azure Networking technology you can use to secure your network traffic. Essentially, you register specific service endpoints like Microsoft.KeyVault on the subnet where traffic originates from - in this case the virtual network integration subnet. With this registration, Azure will append metadata to the traffic towards the specific service to allow the service to restrict which subnet to accept traffic from, and block all other traffic. Unlike private endpoint, it still uses the public IP of the service for routing, and therefore doesn’t need the setup of Azure Private DNS Zones.
+
+
FAQ
+
+
Q: Can I apply the same steps to a Function App?
+
+
You will need a Premium Elastic plan to use virtual network integration with Function Apps. Further, if you would like to also have the storage account that Functions uses for code and state, you will need to initially create it with the storage publicly available. The steps and limitations for that are documented here.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
We are happy to announce the availability of Auto Heal feature for Linux apps on Azure App Service. Auto Heal allows you to mitigate your apps when it runs i...
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Jeff Martinez
+
+ • April 15, 2021
+
+
+
.NET 6 is the latest release version that will include the final pieces bringing the best of Core, Framework, Xamarin, and Mono to a unified platform that st...
+
+
+
+
+
+
+ 4 minute read
+
+
+
+ • By Michimune Kohno and Sanghmitra Gite
+
+ • April 14, 2021
+
+
+
The Azure App Service is a PaaS solution offering in Azure which constantly updates the platform. One of the top requests from customers is to receive a noti...
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Jeff Martinez
+
+ • April 14, 2021
+
+
+
.NET 5 is the first major release in the .NET unification journey bringing together the best of Core, Framework, Xamarin, and Mono to provide an improved dev...
Troubleshooting networking & connectivity issues when running on App Services just became easier. We are happy to announce the release of our new diagnos...
Auto-instrumentation Monitoring for Java and Node.js on App Service (Preview)
+
+
+
+
+
+
+
+
+ 2 minute read
+
+
+
+ • By Jason Freeberg and Julia Goloshubina
+
+ • May 10, 2021
+
+
+
+
+
+
+
+
+
We are happy to share that Azure Monitor Application Insights monitoring is now available for Java and Node.js apps on App Service for both Windows and Linux! To try it out, create a new Web App from the Portal and click the Monitoring tab to enable App Insights. If you already have a Java or Node.js app on App Service, then go to Application Insights on the web app menu to turn it on. Keep reading for instructions on how to get started!
+
+
+
This integration is currently in technical preview.
+
+
+
Auto-instrumentation from Azure Monitor application insights
+
+
Azure Monitor application insights is a cloud native application monitoring service which enables customers to observe failures, bottlenecks, and usage patterns to improve application performance and reduce mean time to resolution (MTTR). With a few clicks, you can enable monitoring for your Node.js or Java apps, auto-collecting logs, metrics, and distributed traces, eliminating the need for including an SDK in your app.
+
+
Enabling application insights for your Azure web app will auto-instrument your Java or Node.js application, and you will see the telemetry in Azure Portal no code changes required! Application insights will help you better understand and monitor your applications with features like…
Select Node.js or Java as your runtime stack (Java SE, Tomcat, and JBoss EAP are all applicable)
+
+
Enter your resource group, region, and App Service Plan
+
+
Select the monitoring tab at the top, and select Yes for “Enable Application Insights”
+
+
+
+
Go to Review + Create, review your selections, and click Create!
+
+
+
The deployment will create the Web App and Azure Monitor application insights resources. Once the deployment completes, your application telemetry will be visible in the Application Insights resource.
+
+
Existing Web App
+
+
If you already have a Node.js or Java web app, navigate to it from the Portal.
+
+
+
+
On the left side, scroll down to the Application Insights menu item and click “Turn on Application Insights”.
+
+
+
+
+
By default, a new application insights resource of the same name as your Web App will be used. You can choose to use an existing application insights resource, or change the name.
+
+
+
+
+
Click Apply at the bottom.
+
+
+
+
Your application telemetry will be visible in the Application Insights resource.
+
+
Azure Monitor application insights support on App Service
+
+
App Service has supported auto-instrumentation monitoring for other languages and operating systems. As of May 10th, this is the current support matrix for App Insights on App Service:
+
+
+
+
+
Language
+
Windows
+
Linux
+
+
+
+
+
ASP.NET
+
✔️
+
N/A
+
+
+
.NET 2.1, 3.1, 5
+
✔️
+
❌
+
+
+
Java
+
✔️
+
✔️
+
+
+
Node.js
+
✔️
+
✔️
+
+
+
Python
+
❌
+
❌
+
+
+
Ruby
+
❌
+
❌
+
+
+
PHP
+
❌
+
❌
+
+
+
+
+
✔️ Application insights auto-instrumentation monitoring is supported
+
+
❌ Application insights auto-instrumentation monitoring is not currently supported
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 2 minute read
+
+
+
+ • By Jason Freeberg and Julia Goloshubina
+
+ • May 10, 2021
+
+
+
We are happy to share that Azure Monitor Application Insights monitoring is now available for Java and Node.js apps on App Service for both Windows and Linux...
App Service Managed Certificate now in General Availability
+
+
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Yutang Lin
+
+ • May 25, 2021
+
+
+
+
+
+
+
+
+
App Service Managed Certificate is now in General Availability for both apex domains and sub-domains. This feature allows customers to secure their custom domains on Linux and on Windows with an SSL certificate at no additional cost. This provides developers a zero-cost option to work on their dev, test, and production sites. This certificate offering is a managed experience that allows customers to just set-and-forget as the automatic certificate renewal and the binding update will be handled by App Service. App Service Managed Certificate is not meant to be used as a client certificate and it is only available for customers on multi-tenant App Service Plan of Basic and above (free, shared, and isolated tiers are not supported).
+
+
App Service Managed Certificate VS App Service Certificate
+
+
+
+
+
+
App Service Managed Certificate
+
App Service Certificate
+
+
+
+
+
Certificate offering
+
Standard certificate
+
Standard and wildcard certificate
+
+
+
Certificate offering
+
No cost
+
$69.99/year for standard and $299.99/year for wildcard
+
+
+
Apex domain support
+
Yes
+
Yes
+
+
+
Sub-domain support
+
Yes
+
Yes
+
+
+
Auto-renew
+
Yes; cannot opt out
+
Yes; can opt out during create or anytime afterwards
+
+
+
Auto-update SSL binding after renew
+
Yes
+
Yes
+
+
+
+
+
What to expect post GA?
+
+
There is an upcoming plan to remove thumbprint information from both portal and API to provide our customers a more managed experience for certificates without having to worry about all the details. Also, App Service Managed Certificate is not meant to be used as a client certificate.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Christina Compy
+
+ • May 25, 2021
+
+
+
+
+
+
+
The App Service Environment v3 (ASEv3) has been in preview since November 2020. During this time it was made available across most regions, received numerous small improvements and was generally very well received. Before GA (General Availability) we will be releasing the GA version into preview. After that update completes, you will be able to make new preview ASEv3’s that replace the private endpoint with an address in the ASE subnet. Also before GA, the preview versions that already exist will be upgraded.
+
+
Upcoming changes
+
+
The GA version of ASEv3 has a few enhancements that were not available earlier in preview. To be clear, this release is not available at the time of this blog but it is planned to be released soon. Some of the feature improvement highlights include:
+
+
+
You can deploy an external VIP ASE. This would be an ASE with a public address for inbound traffic.
+
Maximum ASE instance count is 200. This is the same as ASEv2 where the maximum App Service plan instance count is 100 and that the total number of instances across all App Service plans is 200
+
You can deploy a zone redundant ASEv3.
+
Scaling times are improved from earlier in the preview
+
Your ASE only requires use of one subnet
+
+
+
That leads to the question then on how do you know you are making an ASEv3 that is on the GA version? You can easily tell the difference during the ASEv3 creation flow where you will not be prompted for two subnets anymore. That should be the clearest indicator you are using the newest version.
+
+
Upgrade of preview ASEv3 instances
+
+
If you have a preview version of ASEv3 before the upgrade to the GA version, you need to know that the upgrade to the final GA version will:
+
+
+
Cause downtime to your ASEv3
+
Change the inbound address to your ASEv3
+
+
+
The downtime to your ASEv3 happens as we switch from using the private endpoint provisioned with your ASEv3 and redeploy the ASEv3 with an internal load balancer. The use of the load balancer is completely internal to the ASE. This is a one time event and there are no other expected system downtime events. The private endpoint that was originally provisioned with your preview ASEv3 will still be there and should be deleted after the upgrade.
+
+
With the removal of the private endpoint to your ASEv3, your inbound address will change from the current private endpoint address to an address in your ASE subnet. You will need to update DNS to reflect this. Even if you are using Azure DNS private zones, it will not automatically pick this change up and it must be done manually. After your ASEv3 is upgraded to the load balancer version:
+
+
+
Go into your ASE portal page and select the IP addresses UI
+
Change your DNS records that pointed to the private endpoint address to instead point to the new inbound address shown in the portal.
+
+
+
To tell if your preview ASEv3 was upgraded to the GA release candidate, go into the ASE portal and look at the IP addresses UI. You will no longer see private endpoint listed for the inbound address. You will see the Virtual IP is set to internal.
+
+
+
+
GA limitations
+
+
While there are numerous improvements with ASEv3 over earlier versions, there are a few things that are not available at GA that were available in ASEv2. Those items that are not available include:
+
+
+
IP based SSL
+
Remote debug
+
FTP
+
SMTP
+
Network Watcher and NSG Flow
+
+
+
Upgrade from ASEv2
+
+
Upgrade from ASEv2 will come after GA. In the first version of the upgrade you will be able to upgrade an ASEv2 that is either an external VIP ASEv2 or an internal VIP ASEv2 that has a domain suffix of .appserviceenvironment.net. Initially the upgrade capability won’t support internal ASEs with custom domain suffixes nor will it offer the ability initially to upgrade your ASEv2 to being a zone redundant ASEv3.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Christina Compy
+
+ • May 25, 2021
+
+
+
The App Service Environment v3 (ASEv3) has been in preview since November 2020. During this time it was made available across most regions, received numerous...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Yutang Lin
+
+ • May 25, 2021
+
+
+
App Service Managed Certificate is now in General Availability for both apex domains and sub-domains. This feature allows customers to secure their custom do...
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Christina Compy
+
+ • May 25, 2021
+
+
+
The App Service Environment v3 (ASEv3) has been in preview since November 2020. During this time it was made available across most regions, received numerous...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Yutang Lin
+
+ • May 25, 2021
+
+
+
App Service Managed Certificate is now in General Availability for both apex domains and sub-domains. This feature allows customers to secure their custom do...
+
+
+
+
+
+
+ 2 minute read
+
+
+
+ • By Jason Freeberg and Julia Goloshubina
+
+ • May 10, 2021
+
+
+
We are happy to share that Azure Monitor Application Insights monitoring is now available for Java and Node.js apps on App Service for both Windows and Linux...
Preventing crashes due to DiagnosticMonitorTraceListener
+
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Puneet Gupta
+
+ • June 9, 2021
+
+
+
+
+
+
+
Azure App Services has the proactive crash monitoring feature, which checks for process crashes and collects diagnostic data that helps you determine the root cause of the crash. After looking at this feature’s telemetry, we identified a common exception that is causing a lot of apps hosted on Azure App Service to crash with this call-stack:
The underlying exception message is Couldn’t find type for class Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener, Microsoft.WindowsAzure.Diagnostics, Culture=neutral, PublicKeyToken=31bf3856ad364e35
+
+
This issue can happen if you have migrated your application from Azure Cloud Services. Azure Cloud services uses the DiagnosticMonitorTraceListener class and this class is designed for cloud services and is not compabtible with Azure App Services. To address this issue, please follow these steps :
+
+
+
Remove references to Microsoft.WindowsAzure.Diagnostics.dll from the project.
+
+
Remove the following section from the application web.config file (if it exists)
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Byron Tardif
+
+ • June 9, 2021
+
+
+
+
+
+
+
+
+
We are happy to announce that App Service now supports apps targeting .NET 6 Preview 4 across all public regions and scenarios on both Windows and Linux App Service plans through (App Service Early Access).
+
+
Azure Functions has also added initial support for .NET 6 Preview.
+
+
This is the first time that a pre-release stack is publicly available in the platform ahead of GA release and it makes good on our promise to accelerate FX availability made during the .NET 5 GA release announcement.
+
+
Any app targeting the .NET 6 Early Access on App Service will be automatically updated to the latest .NET 6 Preview releases as they become available all the way up to RC and GA.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Puneet Gupta
+
+ • June 9, 2021
+
+
+
Azure App Services has the proactive crash monitoring feature, which checks for process crashes and collects diagnostic data that helps you determine the roo...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Byron Tardif
+
+ • June 9, 2021
+
+
+
We are happy to announce that App Service now supports apps targeting .NET 6 Preview 4 across all public regions and scenarios on both Windows and Linux App ...
Azure App Service and Azure Functions on Azure Stack Hub 2021 Q1 Released
+
+
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Andrew Westgarth
+
+ • June 11, 2021
+
+
+
+
+
+
+
The 2021 Q1 update to Azure App Service on Azure Stack Hub is now available. This release updates the resource provider and brings the following key capabilities and fixes:
+
+
+
Updates to App Service Tenant, Admin, Functions portals and Kudu tools. Consistent with Azure Stack Portal SDK version.
+
Updates Azure Functions runtime to v1.0.13154.
+
Updates to core service to improve reliability and error messaging enabling easier diagnosis of common issues.
+
Updates to the following application frameworks and tools:
+
+
ASP.NET Core 5.0.4
+
.NET Framework 4.8
+
NodeJS
+
+
14.10.1
+
+
+
Updated Kudu to 90.21106.4900
+
+
+
Updates to underlying operating system of all roles:
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Andrew Westgarth
+
+ • June 11, 2021
+
+
+
The 2021 Q1 update to Azure App Service on Azure Stack Hub is now available. This release updates the resource provider and brings the following key capabili...
App Service has a list of Trusted Root Certificates which you cannot modify in the multi-tenant variant version of App Service, but you can load your own CA certificate in the Trusted Root Store in an App Service Environment (ASE), which is a single-tenant environment in App Service. (The Free, Basic, Standard, and Premium App Service Plans are all multi-tenant, and the Isolated Plans are single-tenant.)
+
+
When an app hosted on Azure App Service, tries to connect to a remote endpoint over SSL, it is important that the certificate on remote endpoint service is issued by a Trusted Root CA. If the certificate on the remote service is a self-signed certificate or a private CA certificate, then it will not be trusted by the instance hosting your app and the SSL handshake will fail with this error:
+
+
"Could not establish trust relationship for the SSL/TLS secure channel".
+
+
+
In this situtation, there are two solutions:
+
+
+
Use a certificate that is issued by one of the Trusted Root Certificate Authorities in App Service on the remote server.
+
If the remote service endpoint certificate could not be changed or there is a need to use a private CA certificate, host your app on an App Service Environment (ASE) and load your own CA certificate in the Trusted Root Store
+
How to get a list of Trusted Root CA on App Service using Kudu
+
+
How to get to Kudu
+
+
Go to your web app on the Azure portal and look for Development Tools > Advanced Tools and click on “Go ->”. A new tab will open for the Kudu tool. The next steps will depend on if you have a Linux or Windows app.
+
+
Windows
+
+
Go to Debug console > Powershell and a Powershell window will appear. Issue the following command in the console:
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
App Service has a list of Trusted Root Certificates which you cannot modify in the multi-tenant variant version of App Service, but you can load your own CA ...
Any app targeting the .NET 6 Early Access on App Service will be automatically updated to the latest .NET 6 Preview releases as they become available all the way up to RC and GA.
+
+
If you are creating a new .NET 6 app on App Service today, you will have Preview 5 available on the platform. If your app was created earlier this week, it will be automatically updated to Preview 5 the next time it cold starts. If you want to trigger the update, you just start/stop the app.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
App Service has a list of Trusted Root Certificates which you cannot modify in the multi-tenant variant version of App Service, but you can load your own CA ...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Andrew Westgarth
+
+ • June 11, 2021
+
+
+
The 2021 Q1 update to Azure App Service on Azure Stack Hub is now available. This release updates the resource provider and brings the following key capabili...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Puneet Gupta
+
+ • June 9, 2021
+
+
+
Azure App Services has the proactive crash monitoring feature, which checks for process crashes and collects diagnostic data that helps you determine the roo...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Byron Tardif
+
+ • June 9, 2021
+
+
+
We are happy to announce that App Service now supports apps targeting .NET 6 Preview 4 across all public regions and scenarios on both Windows and Linux App ...
Securing access to your site is important, but securing access to the source of your site is often equally important.
+
+
In this article, I will walk you through setting up a Linux web app with secure, network-isolated access to a container registry. The scenario is intentionally kept simple to focus on the architecture and configuration.
+
+
+
+
This guide is organized into four steps:
+
+
+
Create network infrastructure
+
Set up Azure Container Registry
+
Create network integrated web app
+
Pull from private registry
+
+
+
In closing, there are sections on advanced scenarios and FAQ.
+
+
+
The default scenario for the article is using system-assigned managed identity. An “Alternative scenarios” section with step for using credentials, user-assigned managed identity, and custom registries has been added.
+Notes:
+
+
+
App Service Environment v2 (Isolated SKU) do not support pulling images from a registry url that needs to be resolved using custom DNS servers
+
+
+
+
Getting started
+
+
This is the third article in a series focusing on network security. If you missed the first two, you can find them here:
This article will also use the Azure CLI executed in bash shell on WSL to set up the environment. It could be done using the Azure portal, Resource Manager templates, or Azure PowerShell. CLI was chosen as I find it easier to follow and explain the individual steps and configurations needed.
+
+
Remember in the scripts to replace all the resource names that need to be unique. This would be the name of the web app and Azure Container Registry. You may also change location if you want something closer to home. All other changes are optional.
+
+
+
Tip: You can search/replace the word “secureacr” with something unique to make all the scripts unique.
+
+
+
1. Create network infrastructure
+
+
First, set up a Resource Group with a Virtual Network. The virtual network should have at least two subnets: one for the regional virtual network integration and one for the private endpoints. The address-prefix size must be at least /28 for both subnets; small subnets can affect scaling limits and the number of private endpoints. Go with /24 for both subnets if you are not under constraints.
+
+
az group create --name secureacrsetup --location westcentralus
+az network vnet create --resource-group secureacrsetup --location westcentralus --name secureacr-vnet --address-prefixes 10.0.0.0/16
+
+
+
For the subnets, there are two settings that we need to pay attention to. This is often set by the portal or scripts, but here it is called out directly. Delegation “Microsoft.Web/serverfarms” informs the subnet that it is reserved for virtual network integration:
az network private-dns zone create --resource-group secureacrsetup --name privatelink.azurecr.io
+
+
+
Link the zone to the virtual network:
+
+
az network private-dns link vnet create --resource-group secureacrsetup --name acr-zonelink --zone-name privatelink.azurecr.io --virtual-network secureacr-vnet --registration-enabledfalse
+
+
+
… and now the core network setup is done.
+
+
2. Set up Azure Container Registry
+
+
In this section, we will set up the Azure Container Registry account. We will also create the private endpoint and configure the service to block public traffic. First create the service. We need Premium SKU to enable private endpoint:
Before we lock the registry down, let’s push a few images to it for testing. After you lock it down, you might get a conflict with the ACR firewall. If you are using docker locally, you will need to allow your local IP. If you are running the build from somewhere else, this location will also need access to the registry.
+
+
I will create a simple static html site, add it to an nginx container, and use ACR Tasks to build the container. You can of course also use native docker commands on your local machine:
Next, let’s create the private endpoints to connect the backend services to the virtual network. Get the Resource ID of the registry and store it in a variable:
+
+
acr_resource_id=$(az acr show --name secureacr2021 --queryid--output tsv)
+
… and create a DNS Zone Group. This will create the DNS record for the private endpoint in the DNS Zone (and remove it if the private endpoint is deleted):
az acr update --resource-group secureacrsetup --name secureacr2021 --public-network-enabledfalse
+
+
+
Everything is locked down now and you cannot even get to the ACR repositories through the Azure portal. In the ACR Networking section in Azure portal, you can add the public IP of your client if you need to view the registries (images) and other IPs needed to to push an image from remote clients. This will allow your local machine to access the registry:
Now we get to creating the actual web app. To use virtual network integration, we need at least the Basic SKU, and then there are a few commands to secure the app and add the integration:
You can now browse to the web app and outbound traffic from the web app will be routed through the virtual network.
+
+
4. Pull from private registry
+
+
All the infrastructure is now in place and we just need to glue it all together. The web app needs some configuration values from the registry.
+
+
Images will by default be pulled over public route, but by setting vnetImagePullEnabled site property to true, you tell the platform to use the virtual network integration for pulling the image:
+
+
az resource update --resource-group secureacrsetup --name secureacrweb2021 --set properties.vnetImagePullEnabled=true--resource-type'Microsoft.Web/sites'
+
+
+
Configure the container image and set image pull to use managed identity:
Note: The app might attempt to pull the image before the configuration is complete which will show up as failed attempts in the logs. Give it a minute or two and the pull will retry with the correct configuration.
+
+
+
Advanced scenarios
+
+
Using user-assigned managed identity
+
+
System-assigned managed identity is convenient as you do not have any additional resources to manage and it is uniquely associated with your web app. However, there are scenarios where user-assigned managed identity is preferred. It can be configured ahead of the web app and assigning permissions can be delegated. You can also reuse the same managed identity across multiple web apps.
+
+
Create a user-assigned managed identity and assign permissions to pull from ACR:
+
+
az identity create --resource-group secureacrsetup --name secureacr-identity
+identity_principal_id=$(az identity show --resource-group secureacrsetup --name secureacr-identity --query principalId --output tsv)
+az role assignment create --role"AcrPull"--assignee-object-id$identity_principal_id--scope$acr_resource_id--assignee-principal-type ServicePrincipal
+
Instead of using managed identity, you can use admin credentials or an Azure AD Service Principal. These values can optionally be stored in Key Vault and configured as Key Vault referenced app settings.
+
+
Configure ACR to enable admin credentials:
+
+
az acr update --resource-group secureacrsetup --name secureacr2021 --admin-enabled
+
+
+
Set the registry credentials and disable using managed identity (remember to ensure the vnetImagePullEnabled is configured if you want to pull the image over the virtual network integration).
App Service also support pulling from a custom private registry using the v2 API. If you are using a custom private registry such as Docker Registry, there are no specific changes you need to make except ensure that the registry is reachable and DNS resolvable from the integration virtual network. Setting up a custom private registry depends on the chosen product and platform. A simple test configuration can be setup using App Service to actually host the registry and protect it with a private endpoint. Other apps can then pull from this registry.
+
+
To set up a custom private registry in the existing setup:
After about a minute, you should see the new image served from the web app.
+
+
Deploy from secure registry with ARM template using credentials
+
+
In this scenario, you will deploy an app with an ARM template from a registry that uses credentials (username/password) for authentication. If you are using ACR, you can use either Admin credentials or a Service Principal. Pulling over virtual network is optional, but if you are using Azure Container Registry with private endpoint, you will have to pull over virtual network.
+
+
The template also assumes the App Service plan and the virtual network exist. If not, you can add this to the template as well.
Deploy from secure registry with ARM template using managed identity
+
+
As an alternative to using credentials, you can use Managed Identity when pulling images from Azure Container Registry. Pulling over virtual network is again optional and is configured using the vnetImagePullEnabled site config, but is of course required if your registry is only visible from the virtual network.
+
+
Since we need to grant the permissions ahead of creating the app, only User-Assigned Managed Identity will work, and you have to grant the identity AcrPull permissions on the registry. See the section on using user-managed identity.
+
+
Even though the managed identity exists when deploying the template, the resource must be in the template to use the reference method to fetch the clientId. You can work around this by inserting the clientId manually.
Yes, but you will need a Premium Elastic plan or an App Service plan to use virtual network integration with Function apps.
+
+
Q: Can I apply the same steps to a Windows container app?
+
+
Windows container apps do not yet support pulling containers over virtual network, but you can use managed identity to pull from Azure Container Registry and you can pull from custom registries that are accessible from the internet.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
How to create a Blazor WebAssembly gRPC-Web app using App Service on an Azure Arc Enabled Kubernetes Cluster
+
+
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Jeff Martinez
+
+ • July 8, 2021
+
+
+
+
+
+
+
+
+
With the release of the App Service on Kubernetes preview, you can now run App Service on Kubernetes deploying your web apps to Azure Kubernetes Service, or the cluster of your choosing. This enables you to utilize App Service features including continuous deployment with GitHub Actions and deployment slots.
+
+
In this tutorial, we’ll be deploying a .NET 5 gRPC-Web app to a Custom Location (App Service deployed on an Arc-enabled AKS cluster) with App Service on Kubernetes using the same gRPC-Web app we created in this blog. This example assumes you already have your resource group, connected Arc cluster, custom location, and App Service Kubernetes environment setup. Follow the steps in the documentation if you do not have these resources created.
+
+
Creating your Web App
+
Creating your web app resource in the Azure portal should look very familiar to what you’ve seen before. When selecting your Resource Group, make sure it is the resource group you’ve created with all of your Azure Arc resources in them. Once the correct resource group is selected, as well as the operating system (Linux) you will find your Arc custom location in the Region drop-down menu.
+
+
If you would like to use the CLI to create your App Service resource, please see the documentation.
+
+
To create your web app using the portal:
+
+
Choose the Subscription where the Resource Group lives containing your Azure Arc resources
+
Choose the correct Resource Group that contains your Azure Arc resources (cluster, custom location, Kube environment, etc.)
+
Give your site a unique Name
+
Choose .NET 5 for your Runtime stack
+
The Operating System will need to be Linux since App Service on Kubernetes is currently Linux only.
+
+
Go to the Region drop down menu and choose your custom location under Custom Locations (Preview). You may notice when you choose your custom location, the appended domain under the Name option is updated to include your Kube environment name and Arc region. Where you typically would see azurewebsites.net, you now see k4apps.io. Keep in mind the custom location is the abstracted layer on top of your Azure Arc enabled cluster that enables you to use Azure services.
+
+
+
+
+
Next, click Review + create to create your resource. Once your resource is created, you can view that it is deployed to your custom location by visiting the custom location resource.
+
+
+
+
+
+
Deploy your application
+
Once your web app resource is created you can use the Zip Deploy method to push your application code to your web app.
+
+
+
+
Using the command line, navigate to the publish files. These will be the publish files in your Server project. The path should look similar to this:
Select all of the files in the publish directory using ctl+a, then Right-click, navigate to Send to, select Compressed (zipped) folder. Name the file blazorgrpcwebapp.zip and save it. This will create the .zip file that you will use in the next step.
+
+
Using the command line, navigate to the directory including the blazorgrpcwebapp.zip file you just created and run the following command
This command will publish your code to the web app and you’ll be able to re-visit your resource my-arc-app and select Browse to view your application in the browser. Notice your URL is appended with the .k4app.io domain. This deployment may take a few minutes so you may see the default deployment screen while you wait.
+
+
Once it’s complete you can view the application and verify that grpc-web calls are still being made.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Jeff Martinez
+
+ • July 8, 2021
+
+
+
With the release of the App Service on Kubernetes preview, you can now run App Service on Kubernetes deploying your web apps to Azure Kubernetes Service, or ...
One of the tools that Azure provides to enforce governance and controls is Azure Policies. By employing Azure policies, IT organizations are able to enforce controls around provisioning Azure resources to ensure adherence to security and compliance standards. Along with the ability to allow users to create custom Azure policies, Azure platform provides built-in policies around the use of each Azure service which can be employed as it is or could be further customized based on the requirements.
+
+
App Service provides many such built-in policies which help secure applications and promote best practices. In recent days, new built-in policies have been released which could be used to improve the security posture of the apps deployed and also help streamline the deployment standards. Some of these policies with Audit or AuditIfNotExists effect result in creation of audit records for all applications that do not comply with the controls and others with DeployIfNotExists results in execution of remediation tasks that makes changes to the configuration of the application to implement the desired controls. Policies with Deny effect cause a create or update request to fail if that request results in creation or update of an application that does not match the defined standards.
+
+
Following table lists the new built-in policies categorized by the area of control that they address :
+
+
+
+
+
Area of Concern
+
Policy
+
Effect
+
Application SKU
+
+
+
+
+
Network Security
+
App Service should disable public network access
+
AuditIfNotExists, Disabled
+
All except IsolatedV1 & IsolatedV2
+
+
+
Network Security
+
Configure App Service to disable public network access
+
DeployIfNotExists, Disabled
+
All except IsolatedV1 & IsolatedV2
+
+
+
Network Security
+
App Service Environment apps should not be reachable over public internet
+
AuditIfNotExists, Disabled
+
IsolatedV1, IsolatedV2
+
+
+
Network Routing
+
App Service should use private link
+
AuditIfNotExists, Disabled
+
PremiumV2, PremiumV3, Functions Premium
+
+
+
Network Routing
+
App Service apps should use a SKU that supports private link
+
AuditIfNotExists, Deny, Disabled
+
PremiumV2, PremiumV3, Functions Premium
+
+
+
Network Routing
+
Configure App Service to use private DNS zones
+
DeployIfNotExists, Disabled
+
PremiumV2, PremiumV3, Functions Premium
+
+
+
Network Routing
+
App Service apps should enable outbound non-RFC 1918 traffic to Azure Virtual Network
+
AuditIfNotExists, Disabled
+
All except IsolatedV1 & IsolatedV2
+
+
+
Application Security
+
App Service Environment should enable internal encryption
+
Audit, Disabled
+
IsolatedV1, IsolatedV2
+
+
+
Application Security
+
App Service Environment should disable TLS 1.0 and 1.1
+
Audit, Disabled
+
IsolatedV1, IsolatedV2
+
+
+
Application Security
+
App Service Environment should be configured with strongest TLS Cipher Suites
+
Audit, Disabled
+
IsolatedV1, IsolatedV2
+
+
+
Service Governance
+
App Service Environment should be provisioned with latest versions
+
Audit, Disabled
+
IsolatedV1, IsolatedV2
+
+
+
+
+
Network Security
+
+
App Service should disable public network access
+
+
Internal user facing applications should ensure that they are not accessible over public internet. Disabling inbound public network access improves security by ensuring that the app isn’t exposed on public internet. For applications deployed in the multi-tenant App Service, use this policy to flag all applications that are accessible over public network. If the organization mandates that applications should not be accessible over public internet, one could use “Configure App Service to disable public network access” policy to automatically disable the inbound public network access following the policy run.
+
+
App Service Environment apps should not be reachable over public internet
+
+
Applications deployed in App Service Environment where the access from public internet is not desired, should be deployed in a private IP address inside the VNET. The internal endpoint is an internal load balancer. This policy could be used to audit applications that violate this control and are accessible over public internet.
+
+
Network Routing
+
+
App Service should use private link
+
To ensure that applications deployed in multi-tenant app service are only accessible privately on a non-public route, one should create private link to provide private access to them. This could be done by creating a private link to the apps deployed in App Service, as described here. Policy “App Service should use private link” creates an audit record for all apps that do not provide private link. These records can then be used to identify such applications to determine if a corrective action is required.
+
+
App Service apps should use a SKU that supports private link
+
To ensure private access to applications deployed in multi-tenant app service, one requires to provision a private link to the application. Not all App Service SKUs support private link. Private Link is supported only on the following App Service Plans : PremiumV2, PremiumV3, Functions Premium (sometimes referred to as the Elastic Premium plan). This policy provides ability to audit or deny deployment of applications on App Service Plans that do not support private link.
+
+
Configure App Service to use private DNS zones
+
+
On the creation of a private endpoint to a webapp, a DNS entry is required to be created to resolve the name of private endpoint IP address to the fully qualified domain name(FQDN) of the connection string. The network interface associated with the private endpoint contains information to configure DNS, that is FQDN and private IP address to the private link resource i.e. the app. It is recommended to setup a private DNS zone to override the DNS resolution for a private endpoint. A private DNS zone can be linked to the one’s virtual network to resolve specific domains. Policy “Configure App Service to use private DNS zones” automatically configures apps accessible over private endpoints to use a private DNS zone.
+
+
App Service apps should enable outbound non-RFC 1918 traffic to Azure Virtual Network
+
App Service provides a feature called Regional VNet Integration to enable apps deployed in multi-tenant service to access resources in or through a VNET. The feature allows application routing to be controlled at the individual app level. When Route All is not enabled, the app only routes RFC1918 traffic into VNet. Enabling Route All allows NSGs and UDRs to be used for all outbound traffic from the App Service app. Steps to set up that setting are described here. Policy “App Service apps should enable outbound non-RFC 1918 traffic to Azure Virtual Network” creates an audit record and thus helps identify applications that don’t have Route All enabled.
+
+
Application Security
+
+
App Service Environment should enable internal encryption
+
By default, to enable higher throughput, internal components of App Service Environment do not use encryption while communicating among themselves. If one has a compliance requirement that requires complete encryption of the end to end data path, encryption could be enabled by setting a custom setting. Policy “App Service Environment should enable internal encryption” creates an audit record for all App Service Environments that do not use internal encryption.
+
+
App Service Environment should disable TLS 1.0 and 1.1
+
TLS 1.0 and 1.1 are out-of-date protocols that do not support modern cryptographic algorithms and thus are deemed vulnerable to attacks. To disable TLS 1.0 and 1.1 for all the apps in an ASE, one could set custom setting on the ASE as described here. Policy “App Service Environment should disable TLS 1.0 and 1.1” help identify and create a record for all ASEs that have TLS 1.0 and 1.1 enabled.
+
+
App Service Environment should be configured with strongest TLS Cipher Suites
+
By default, ASE supports changing the TLS cipher suite by using custom setting as defined here. Changing the cipher suite affects an entire App Service Environment. For ASE to function, there are two cipher suites required;
+TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, and TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. Default setting for ASE also has weaker ciphers included in the suite, if you wish to operate your ASE with the strongest and most minimal set of cipher suites, then one should use just the two required ciphers. “App Service Environment should be configured with strongest TLS Cipher Suites” creates an audit record for all those ASEs which do not use these required cipher suites or use cipher suites other than just these two.
+
+
Service Governance
+
+
App Service Environment should be provisioned with latest versions
+
Older version of App Service Environment requires manual management of Azure’s resources and have greater scaling limitations. It is recommended that one uses ASEv2 or ASEv3(in preview) while creating new App Service Environment. This policy identifies all App Service Environments that are ASEv1.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
One of the tools that Azure provides to enforce governance and controls is Azure Policies. By employing Azure policies, IT organizations are able to enforce ...
+
+
+
+
+
+
+ 8 minute read
+
+
+
+ • By Jordan Selig
+
+ • July 23, 2021
+
+
+
+
+
+
+
+
+
Get started with Azure App Service by deploying an app to the cloud using a Bicep file and Azure CLI in Cloud Shell. Because you use a free App Service tier, you incur no costs to complete this quickstart.
+
+
Bicep is a domain-specific language (DSL) that uses declarative syntax to deploy Azure resources. It provides concise syntax, reliable type safety, and support for code reuse. You can use Bicep instead of JSON to develop your Azure Resource Manager templates (ARM templates). The JSON syntax to create an ARM template can be verbose and require complicated expressions. Bicep syntax reduces that complexity and improves the development experience. Bicep is a transparent abstraction over ARM template JSON and doesn’t lose any of the JSON template capabilities. During deployment, the Bicep CLI transpiles a Bicep file into ARM template JSON.
In order to effectively create resources with Bicep, you will need to install Bicep. The Bicep extension for Visual Studio Code provides language support and resource autocompletion. The extension helps you create and validate Bicep files and is recommended for those that will continue to create resources using Bicep upon completing this quickstart.
+
+
Review the template
+
+
The template used in this quickstart is shown below. It deploys an App Service plan, an App Service app on Linux, and a sample Node.js “Hello World” app from the Azure Samples repo.
+
+
paramwebAppNamestring=uniqueString(resourceGroup().id)// Generate unique String for web app name
+paramskustring='P1V2'// The SKU of App Service Plan
+paramlinuxFxVersionstring='node|14-lts'// The runtime stack of web app
+paramlocationstring=resourceGroup().location// Location for all resources
+paramrepositoryUrlstring='https://github.com/Azure-Samples/nodejs-docs-hello-world'
+parambranchstring='master'
+
+varappServicePlanName=toLower('AppServicePlan-${webAppName}')
+varwebSiteName=toLower('wapp-${webAppName}')
+
+resourceappServicePlan'Microsoft.Web/serverfarms@2020-06-01'={
+ name:appServicePlanName
+ location:location
+ properties:{
+ reserved:true
+ }
+ sku:{
+ name:sku
+ }
+ kind:'linux'
+}
+
+resourceappService'Microsoft.Web/sites@2020-06-01'={
+ name:webSiteName
+ location:location
+ properties:{
+ serverFarmId:appServicePlan.id
+ siteConfig:{
+ linuxFxVersion:linuxFxVersion
+ }
+ }
+}
+
+resourcesrcControls'Microsoft.Web/sites/sourcecontrols@2021-01-01'={
+ name:'${appService.name}/web'
+ properties:{
+ repoUrl:repositoryUrl
+ branch:branch
+ isManualIntegration:true
+ }
+}
+
+
+
Three Azure resources are defined in the template:
Copy and paste the template to your preferred editor/IDE and save the file to your local working directory.
+
+
Azure CLI is used here to deploy the template. You can also use the Azure portal, Azure PowerShell, or REST API. To learn other deployment methods, see Bicep Deployment Commands.
+
+
The following code creates a resource group, an App Service plan, and a web app. A default resource group, App Service plan, and location have been set for you. Replace <app-name> with a globally unique app name (valid characters are a-z, 0-9, and -).
+
+
Open up a terminal where the Azure CLI has been installed and run the code below to create a Node.js app on Linux.
+
+
az group create --name myResourceGroup --location"southcentralus"&&
+az deployment group create --resource-group myResourceGroup --template-file <path-to-template>
+
+
+
To deploy a different language stack, update linuxFxVersion with appropriate values. Samples are shown below. To show current versions, run the following command in the Cloud Shell: az webapp config show --resource-group myResourceGroup --name <app-name> --query linuxFxVersion
+
+
+
+
+
Language
+
Example
+
+
+
+
+
.NET
+
linuxFxVersion=”DOTNETCORE|3.0”
+
+
+
PHP
+
linuxFxVersion=”PHP|7.4”
+
+
+
Node.js
+
linuxFxVersion=”NODE|10.15”
+
+
+
Java
+
linuxFxVersion=”JAVA|1.8|TOMCAT|9.0”
+
+
+
Python
+
linuxFxVersion=”PYTHON|3.7”
+
+
+
Ruby
+
linuxFxVersion=”RUBY|2.6”
+
+
+
+
+
+
+
Validate the deployment
+
+
Browse to http://<app_name>.azurewebsites.net/ and verify it’s been created.
If you would like to continue learning about Bicep and App Service, below are additional samples you can review and deploy following the same process described above. Note that if you did not already delete the previously created resources, updating your existing template and redeploying will update the current app. Optionally, you can start from scratch and create new resources for the next part of this quickstart.
This app uses Microsoft Azure Cosmos DB service to store and access data from an ASP.NET Core MVC application hosted on Azure App Service. More details for this app can be found here. Most of the parameters and resources are the same, but you now additionally have resources for the Cosmos DB account and you set the app settings as part of the “sites” (web app) resource.
+
+
Webapp with custom DNS name with a TLS/SSL binding
+
+
If you would like to continue with this app by adding a SSL binding and a custom domain, the sample bicep files will be given below. Please note that you will need to purchase a custom domain and input the relevant info into the dnsZone parameter of the template. For more information about custom domains and SSL bindings, please see Secure a custom DNS name with a TLS/SSL binding in Azure App Service.
+
+
In order to complete this sample, you will need to modify the above file or create a new Bicep file as well as create an additional Bicep file in the same directory for sni enablement. This is due to an ARM limitation that forbids using resources with this same type-name combination twice in one deployment.
+
+
Create another bicep file named sni-enable.bicep in the same directory with the contents below.
The following highlight the changes to the webapp-cosmosdb file for reference. Making these updates to your existing file will update your existing deployment if you did not already delete your app.
+
+
+
Add a parameter for dnsZone where you input your custom domain (i.e. “customdomain.com”)
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 8 minute read
+
+
+
+ • By Jordan Selig
+
+ • July 23, 2021
+
+
+
Get started with Azure App Service by deploying an app to the cloud using a Bicep file and Azure CLI in Cloud Shell. Because you use a free App Service tier,...
Overview of the Various Methods for Deploying Your Infrastructure to App Service
+
+
+
+
+
+
+
+
+ 23 minute read
+
+
+
+ • By Jordan Selig
+
+ • July 29, 2021
+
+
+
+
+
+
+
+
+
There are a number of ways to deploy infrastructure to Azure, what you pick depends on a number of factors including skill level, experience, job requirement, or perhaps company policy. In the end, they’ll essentially get you to the same place - infrastructure deployed to the cloud. This article will cover infrastructure deployment methods including using the Azure Portal, Azure CLI in Cloud Shell or on your local machine, PowerShell, an Azure Resource Manager (ARM) template, Bicep, and Terraform by HashiCorp. Feel free to follow along with the samples as step-by-step guidance will be provided.
+
+
General Prerequisites
+
+
Since there are a number of deployment methods in this article, prerequisites will be given on a case by case basis. However to start, if you would like to follow along and you don’t have an Azure subscription, create a free account before you begin. Be mindful when creating and deleting resources as some of the samples in this article may incur charges if you choose certain deployment settings or if you keep your app running for an extended period of time. If you are trying to prevent racking up an charges, please be sure to review the documentation and billing pages closely prior to any deployments.
+
+
App Overview
+
+
You will be creating a to-do-list app that uses Microsoft Azure Cosmos DB service to store and access data from an ASP.NET Core MVC application hosted on Azure App Service. More details for this app can be found here.
+
+
We will be creating the following primary resources:
+
+
+
Cosmos DB account to act as the database to store the data from our app
+
App Service Plan which defines the set of compute resources for the web app to run
+
App Service which is an HTTP-based service for hosting web applications, REST APIs, and mobile back ends
+
+
+
Code deployment in App Service is another topic that will not be covered in depth in this article, but feel free to browse the docs to understand the various methods. For the purpose of this article, you will stick to one method (External Git) to keep things as consistent as possible.
+
+
Azure Portal
+
+
Prerequisites
+
No additional prerequisites for this tutorial.
+
+
Tutorial
+
+
In my opinion, the Azure Portal is the most user friendly method for infrastructure deployment, especially for those who are just starting with Azure or do not have much experience with the cloud or infrastructure-as-code. It provides a user interface where you will get to explore the various available services and see step-by-step what is happening as you move through the infrastructure creation process.
To start, you will need to create a resource group to hold and manage the resources related to this app. From the home page, click “Create a resource” and search for “resource group.” Select and fill in the following details:
+
+
Subscription: the name of the subscription you created (or already had if you were an existing Azure user)
+
Resource Group: give your resource group a name that is unique to your Subscription
+
Region: select your preferred region for where you would like the resource group to be located. (Typically you choose a region that is physically close to you to reduce latency, or sometimes certain features/services are only available in certain regions - for the purposes of this article, it does not matter which region you choose.)
+
+
+
Select “Review + create” at the bottom left of your screen and wait for validation to complete. If you get an error, review and address as needed.
+
Select “Create” at the bottom left and your resource group will be created
+
Next, you will need to create a Cosmos DB account. For more details on how to do this, see this doc. For this article, I will give quick step-by-step guidance. Navigate back to the “Create a resource” page and search for Cosmos DB. Select “Create” under “Azure Cosmos DB” ane then select “Azure Cosmos DB” again.
+
On the following page, select create under “Core (SQL) - Recommended” as the account type
+
Fill in the following details for your Cosmos DB account:
+
+
Subscription: the name of the subscription you created (or already had if you were an existing Azure user)
+
Resource Group: the resource group you created earlier
+
Account Name: a unique name to identify the account. The name can only contain lowercase letters, numbers, and the hyphen (-) character. It must be between 3-44 characters in length.
+
Location: a geographic location to host your Azure Cosmos DB account. Use the location that is closest to your users to give them the fastest access to the data. You can use the same or different location as you selected for your resource group since this is only a tutorial, however if you were to put this into production, you would want to think more carefully about this location as well as geo-redundancy options.
+
To keep things as cheap as possible, for “Capacity mode”, select “Provisioned throughput” which gives you the option to “Apply Free Tier Discount.” Select “Apply” if this is your intention.
+
+
+
Feel free to browse the remaining settings, but this tutorial will leave them as defaults
+
Select “Review + create” at the bottom left of your screen and wait for validation to complete. If you get an error, review and address as needed.
+
Select “Create” at the bottom left and your Cosmos DB account will be created after a couple minutes
+
While the Cosmos DB account is being provisioned, which can take 5-10 minutes, you can move on to creating the App Service. Navigate back to the “Create a resource” page and search for “Web App.” Make sure you don’t select any of the recommended options and just hit enter to search.
+
Review the results and select “Create” under “Web App.” This will take you to the Web App creation page.
+
Fill in the following details for your Web App:
+
+
Subscription: the name of the subscription you created (or already had if you were an existing Azure user)
+
Resource Group: the resource group you created earlier
+
Name: a unique name to identify the web app. This will become part of the domain for the app.
+
Publish: “Code” - we will cover this in the next step
+
Runtime stack: “.NET Core 3.1”
+
Operating System: “Windows”
+
Region: a geographic location close to your Azure Cosmos DB account.
+
You will now be selecting the details for the App Service Plan (ASP). Pay close attention here to avoid incurring any unwanted costs.
+
+
Windows Plan: select “Create new” and give the A**: a name
+
Sku and size: select “Change size” and choose the**:ier that fits your budget. “F1” is the free tier and should be sufficient for this tutorial. I would recommend using “S1” or higher for this however since it gives you more features to experiment with. Select your tier and hit “Apply.”
+
+
+
+
+
Feel free to browse the remaining settings, but this tutorial will leave them as defaults.
+
Select “Review + create” at the bottom left of your screen and wait for validation to complete. If you get an error, review and address as needed.
+
Select “Create” at the bottom left and your web app will be created after a couple minutes
+
While the web app is being provisioned, navigate to your newly created Cosmos DB account. The easiest way to do this is to go to your Resource Group to view all of the resources you have created so far.
+
You will now create the container in the Cosmos DB account that will hold the data for our app
+
+
Make sure you are on the “Overview” page and select “Add Container” at the top left
+
Fill in the following values, leaving the remaining as default:
+
+
Database id: select “Create new” and call it Tasks
+
Database throughput: select “Manual” and change the value to 400 which should be sufficient for this tutorial
+
Container id: Items
+
Partition key: /id
+
+
+
Select “OK” to close out the dialog. Your container and empty table will get provisioned after a couple seconds
+
+
+
Now it is time to connect your database to your web app. Under “Settings” on the left hand side, select “Keys” to show the various keys and connection strings associated with your database. Copy and paste the following into a text editor:
+
+
URI
+
Primary Key
+
+
+
Once you have these values, navigate to your Web App. You can do this by retuning to your Resource Group and selecting the Web App from there. Make sure you select the resource with the type “App Service.”
+
Under “Settings” on the left hand side, select “Configuration” to add the connection to your database
+
Under “Application settings” select “New application setting” and create the following (you will need to hit “New application setting” for each one)
+
+
Name = CosmosDb:Account, Value = <database URI>
+
Name = CosmosDb:Key, Value = <database Primary key>
+
Name = CosmosDb:DatabaseName, Value = Tasks
+
Name = CosmosDb:ContainerName, Value = Items
+
+
+
Hit “Save” at the top and then “Continue” for the notification saying your app will be restarted
+
Finally, your app is configured and you can upload your code. Head over to “Deployment Center” under “Deployment” on the left hand side
Hit “Save” at the top and give your app time to build and deploy the code. You can review the status by selecting “Logs” next to the “Settings” tab in the Deployment Center. When Status says “Success (Active)” your app should be up and running!
+
Navigate to the “Overview” tab on the left hand side and find your app’s URL. Hit that and it should open your app in a new tab. Feel free to play around with it and see what you’ve created! If your app doesn’t open immediately or you get a generic landing page, wait a couple minutes and try again. If needed, restart your app by hitting “Restart” at the top of the “Overview” tab.
Congratulations! You just deployed a web app connected to a database on Azure. Continue to the next section to learn about another deployment method.
+
+
Azure CLI
+
+
Prerequisites
+
+
Azure hosts Azure Cloud Shell, an interactive shell environment that you can use through your browser. You can use either Bash or PowerShell with Cloud Shell to work with Azure services. You can use the Cloud Shell preinstalled commands to run the code in this article without having to install anything on your local environment. If you prefer to use your local environment, follow the steps here to install the latest version.
+
+
If you are using the Azure CLI from your local environment, you will need to login first with the az login command. Proceed to the tutorial once logged in. If you would like to use the Azure Cloud Shell either navigate to the Azure portal and select the Cloud Shell button on the menu bar at the upper right, or just navigate to https://shell.azure.com/. Confirm you have a Bash shell opened by checking the top left of the Cloud Shell and select “Bash” from the drop down.
+
+
Tutorial
+
+
The Azure CLI is a cross-platform command-line tool to connect to Azure and execute administrative commands on Azure resources. It allows the execution of commands through a terminal using interactive command-line prompts or a script. It is a great tool for those who have experience working from a command line and are comfortable with either bash or PowerShell. For those with less experience, there is an interactive mode which can be activated by running the az interactive command.
+
+
Below is a script which if you copy and paste into your CLI/shell will run all of the commands and deploy the application in one shot. I recommend however that you copy and paste each of the commands one at a time to get a better understanding of what is happening during each step. You can navigate between your CLI and the portal to see the resources in your resource group as they get created.
+
+
Comments have provided throughout the script to identify what each of the commands is doing.
+
+
# Variables
+resourceGroupName="myResourceGroup"
+appName="webappwithcosmosdb$RANDOM"
+location="eastus"
+appServicePlanName="$appName-ASP"
+# Do not change these
+databaseName="Tasks"
+containerName="Items"
+
+# Create a Resource Group
+az group create --name$resourceGroupName--location$location
+
+# Create an App Service Plan
+az appservice plan create --resource-group$resourceGroupName--name$appServicePlanName--sku S1 --location$location
+
+# Create a Web App in the App Service Plan
+az webapp create --name$appName--plan$appServicePlanName--resource-group$resourceGroupName
+
+# Create a Cosmos DB account
+az cosmosdb create --name$appName--resource-group$resourceGroupName--kind GlobalDocumentDB
+
+# Get the database connection details and store them as variables. Make sure there is only one Cosmos DB account in your resource group. Otherwise, you will need to further parse the response from the below command to obtain the needed info.
+databaseUri=$(az cosmosdb list --resource-group$resourceGroupName--query[0].documentEndpoint --output tsv)
+primaryMasterKey=$(az cosmosdb keys list --name$appName--resource-group$resourceGroupName--type keys --query primaryMasterKey --output tsv)
+
+# Assign the database details to App Settings in the Web App
+az webapp config appsettings set--name$appName--resource-group$resourceGroupName--settings"CosmosDb:Account=$databaseUri"
+az webapp config appsettings set--name$appName--resource-group$resourceGroupName--settings"CosmosDb:Key=$primaryMasterKey"
+az webapp config appsettings set--name$appName--resource-group$resourceGroupName--settings"CosmosDb:DatabaseName=$databaseName"
+az webapp config appsettings set--name$appName--resource-group$resourceGroupName--settings"CosmosDb:ContainerName=$containerName"
+
+# Upload the code using External Git
+az webapp deployment source config --resource-group$resourceGroupName--name$appName--repo-url https://github.com/Azure-Samples/cosmos-dotnet-core-todo-app.git --branch main --manual-integration
+
+
+
And that’s it! Give your app a couple minutes to deploy, and then navigate to your app’s URL (<https://APP-NAME.azurewebsites.net>) to validate everything was created as intended. When you are done, delete the resource group to delete the resources.
+
+
PowerShell
+
+
The Az PowerShell module is a set of cmdlets for managing Azure resources directly from PowerShell. PowerShell provides powerful features for automation that can be leveraged for managing your Azure resources for examples in the context of a CI/CD pipeline.
+
+
You can use the Az PowerShell module with one of the following methods:
If needed, install the Azure PowerShell using the instruction found in the Azure PowerShell guide, and then run Connect-AzAccount to create a connection with Azure. If you would like to use the Azure Cloud Shell either navigate to the Azure portal and select the Cloud Shell button on the menu bar at the upper right, or just navigate to https://shell.azure.com/. Ensure you have a PowerShell type shell opened (not Bash) by selecting PowerShell from the top left corner of the Cloud Shell.
+
+
Tutorial
+
+
Below is a commented script that will deploy the necessary resources for this application. Take some time to go through each cmdlet to understand what each is doing. You will notice that this script is very similar to the CLI script given previously.
+
+
# Generates a Random Value
+$Random=(New-Guid).ToString().Substring(0,8)
+
+# Variables
+$ResourceGroup="MyResourceGroup$Random"
+$AppName="webappwithcosmosdb$Random"
+$Location="East US"
+$ServerName="$AppName-ASP"
+# Do not change these
+$DatabaseName="Tasks"
+$ContainerName="Items"
+
+# Create a Resource Group
+New-AzResourceGroup-Name$ResourceGroup-Location$Location
+
+# Create an App Service Plan
+New-AzAppservicePlan-Name$ServerName-ResourceGroupName$ResourceGroup-Location$Location-TierBasic
+
+# Create a Web App in the App Service Plan
+New-AzWebApp-Name$AppName-ResourceGroupName$ResourceGroup-Location$Location-AppServicePlan$ServerName
+
+# Create a Cosmos DB account
+New-AzCosmosDBAccount-ResourceGroupName$ResourceGroup-Name$AppName-Location$Location-ApiKindGlobalDocumentDB
+
+# Get the database connection details and store them as variables. Make sure there is only one Cosmos DB account in your resource group. Otherwise, you will need to further parse the response from the below command to obtain the needed info.
+$DatabaseUri=(Get-AzCosmosDBAccount-ResourceGroupName$ResourceGroup).DocumentEndpoint
+$PrimaryMasterKey=(Get-AzCosmosDBAccountKey-ResourceGroupName$ResourceGroup-Name$AppName-TypeKeys).PrimaryMasterKey
+
+# Assign the database details to App Settings in the Web App
+$hashtable=@{
+ "CosmosDb:Account"=$DatabaseUri
+ "CosmosDb:Key"=$PrimaryMasterKey
+ "CosmosDb:DatabaseName"=$DatabaseName
+ "CosmosDb:ContainerName"=$ContainerName
+}
+Set-AzWebApp-ResourceGroupName$ResourceGroup-Name$AppName-AppSettings$hashtable
+
+# Upload the code using External Git
+$PropertiesObject=@{
+ repoUrl="https://github.com/Azure-Samples/cosmos-dotnet-core-todo-app.git";
+ branch="main";
+ isManualIntegration="true";
+}
+Set-AzResource-Properties$PropertiesObject-ResourceGroupName$ResourceGroup-ResourceTypeMicrosoft.Web/sites/sourcecontrols-ResourceName$AppName/web-ApiVersion2015-08-01-Force
+
+
+
Give your app a couple minutes to deploy, and then navigate to your app’s URL (<https://APP-NAME.azurewebsites.net>) to validate everything was created as intended. When you are done, delete the resource group to delete the resources.
+
+
Azure Resource Manager (ARM) Template
+
+
An ARM template is a JavaScript Object Notation (JSON) file that defines the infrastructure and configuration for your project. This is also known as “Infrasture as Code (IaC).” The template uses declarative syntax. In declarative syntax, you describe your intended deployment without writing the sequence of programming commands to create the deployment.
+
+
ARM templates are great for companies or people that need reusable templates to manage their infrastructure in a secure and consistent manner. For example, if a development team from a company requires a VM with a database to deploy a certain application, the approved ARM template for this configuration can be used which ensures this team is given approved and secure infrastructure and prevents the team from configuring something that can potentially lead to a hack or unidentified vulnerability. There are numerous linters and scanners that can review templates to ensure they are following certain security and regulatory standards as well which further adds to the sense of security companies can have when they use this deployment method.
+
+
Prerequisites
+
+
You will need a text editor or IDE to carry out this tutorial. I would recommend Visual Studio Code. You will also need to install the Azure CLI. You have the option of using the Azure Cloud Shell which does not require any additional installation. The Azure Cloud Shell has a built in editor which can be opened by clicking the button that looks like “{ }” at the top of the screen.
+
+
Tutorial
+
+
Review the below template. You will recognize that all of the resources in the template, including the settings, are what you created previously.
The template starts with the parameters for the infrastructure.
+
+
Following the parameters are the resources. I will not repeat what these resources are since they are the same as those created before. Feel free to browse here to learn more about the various resources.
+
+
In order to deploy this template, follow these steps:
+
+
+
Copy and paste the template to your preferred editor/IDE/Cloud Shell and save the file to your working directory
+
+
Open up a terminal where the Azure CLI has been installed and run the code below to create a resource group
+
+
az group create --name myResourceGroup --location"eastus"
+
+
+
+
Deploy the template using the following:
+
+
az deployment group create --resource-group myResourceGroup --template-file <path-to-template>
+
+
+
And that’s it! Wait for a success message and navigate to your web app URL to prove that everything was created as intended.
Bicep is a domain-specific language (DSL) that uses declarative syntax to deploy Azure resources. It provides concise syntax, reliable type safety, and support for code reuse. You can use Bicep instead of JSON to develop your Azure Resource Manager templates (ARM templates). The JSON syntax to create an ARM template can be verbose and require complicated expressions. Bicep syntax reduces that complexity and improves the development experience. Bicep is a transparent abstraction over ARM template JSON and doesn’t lose any of the JSON template capabilities. During deployment, the Bicep CLI transpiles a Bicep file into ARM template JSON.
+
+
I would recommend Bicep to developers who are looking to create reusable templates for their infrastructure. If you have used ARM templates previously, it would be good to take a look at Bicep to see how it simplifies and speeds up template creation. Click here if you are interested in learning more about Bicep.
+
+
Prerequisites
+
+
The Azure CLI is used here to deploy the template. You can also use the Azure portal, Azure PowerShell, or REST API. To learn about other deployment methods, see Bicep Deployment Commands.
+
+
In order to effectively create resources with Bicep, you will need to set up a Bicep development environment. Feel free to use the Azure Cloud Shell or your IDE of choice (this requires installing the Azure CLI locally). The Bicep extension for Visual Studio Code provides language support and resource autocompletion. The extension helps you create and validate Bicep files and is recommended for those that will continue to create resources using Bicep upon completing this tutorial.
+
+
Tutorial
+
+
I’ll start off by giving you the file. You will recognize that all of the resources in the template, including the settings, are what you created previously. Compared to the ARM template, we reduced the number of lines and complexity significantly.
The file starts with the parameters for the infrastructure. They are defined in the template itself, but you are free to leave them as inputs which can be added during deployment.
+
+
Following the parameters are the resources. Feel free to browse here to learn more about the various resources. There are tabs for ARM and Bicep.
+
+
In order to deploy this template follow these steps:
+
+
+
Copy and paste the template to your preferred editor/IDE/Cloud Shell and save the file to your working directory
+
+
Open up a terminal where the Azure CLI has been installed and run the code below to create a resource group
+
+
az group create --name myResourceGroup --location"eastus"
+
+
+
+
Deploy the template using the following:
+
+
az deployment group create --resource-group myResourceGroup --template-file <path-to-template>
+
+
+
And that’s it! Wait for a success message and navigate to your web app URL to prove that everything was created as intended.
Terraform by Hashicorp is an open source tool that codifies APIs into declarative configuration files that can be used to create, manage, and update infrastructure resources such as virtual machines (VMs), networks, and containers. It is becoming the deployment method of choice for many large enterprises since it can provision infrastructure across 300+ public clouds and services using a single workflow and consistent syntax. For this reason, many companies that are choosing multi-cloud leverage Terraform.
+
+
Prerequisites
+
+
I would recommend going to the Terraform documentation for getting started on Azure to learn more about Terraform and understand how to configure your environment as they will do a much better job than I can here.
+
+
Once you have reviewed their materials, the below template is all you need!
+
+
Tutorial
+
+
Follow the guidance as provided by this doc to deploy this template. Replace the contents of their “main.tf” with the below.
+
+
For a quick summary of what is needed to get this deployed (ignoring many of the great features Terraform has to offer which I do recommend reviewing at some point):
+
+
+
Open up your IDE of choice where Terraform has been installed
+
Created a new directory and cd into it
+
Create a main.tf file and copy and paste the below template into there
+
Run terraform init
+
Run terraform apply
+
Once complete, navigate to the web app URL to view your app
Thanks for taking the time to go through this tutorial. Again, please ensure you have deleted any resources you do not intend to keep. I hope you learned something about the various ways the App Service team has worked to create a platform that meets as many of your web app needs as possible and reach a variety of customers. If you have any questions, feedback, or requests, feel free to share using the links below. Also note that App Service is constantly updated to improve functionality and usability. If anything from the article no longer applies or if you get stuck, always feel free to reach out!
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 23 minute read
+
+
+
+ • By Jordan Selig
+
+ • July 29, 2021
+
+
+
There are a number of ways to deploy infrastructure to Azure, what you pick depends on a number of factors including skill level, experience, job requirement...
+
+
+
+
+
+
+ 23 minute read
+
+
+
+ • By Jordan Selig
+
+ • July 29, 2021
+
+
+
There are a number of ways to deploy infrastructure to Azure, what you pick depends on a number of factors including skill level, experience, job requirement...
+
+
+
+
+
+
+ 8 minute read
+
+
+
+ • By Jordan Selig
+
+ • July 23, 2021
+
+
+
Get started with Azure App Service by deploying an app to the cloud using a Bicep file and Azure CLI in Cloud Shell. Because you use a free App Service tier,...
One of the tools that Azure provides to enforce governance and controls is Azure Policies. By employing Azure policies, IT organizations are able to enforce ...
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Jeff Martinez
+
+ • July 8, 2021
+
+
+
With the release of the App Service on Kubernetes preview, you can now run App Service on Kubernetes deploying your web apps to Azure Kubernetes Service, or ...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Jason Freeberg
+
+ • August 9, 2021
+
+
+
With GitHub Actions you can set up a workflow to build and deploy your applications whenever there’s a commit on your main branch, or a PR is merged, or even...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Jason Freeberg
+
+ • August 9, 2021
+
+
+
+
+
+
+
+
+
With GitHub Actions you can set up a workflow to build and deploy your applications whenever there’s a commit on your main branch, or a PR is merged, or even on a schedule! If getting started with GitHub Actions sounds daunting, the Deployment Center in the Azure Portal makes it easy. The guided experience will put a curated workflow file in your chosen repository to build and deploy your application.
+
+
+
+
+
+
+
+
+
If you’re more comfortable on the command line, you can now use the Azure CLI to set up GitHub Actions for your web apps. Just like the Deployment Center, this CLI command will put a curated workflow file in your target repository.
+
+
CLI Instructions
+
+
+
+
First, make sure you are using version 2.27.0 or greater.
+
+
az --version
+
+
+
The first line in the output will show the CLI version:
Next, run the following CLI command to set up GitHub Actions. Replace <app-name>, <group-name>, and <owner>/<repository-name> with your Web App name, resource group, and repository respectively.
In the command output there will be a login URL and user code. Open the URL in the command output, https://github.com/login/device, and enter the user code shown in the output.
+
+
Command group 'webapp deployment github-actions' is in preview and under development. Reference and support levels: https://aka.ms/CLI_refstatus
+ Please navigate to https://github.com/login/device and enter the user code 985C-11BD to activate and retrieve your github personal access token
+ Waiting up to '14' minutes for activation
+
+
+
+
+
+
Once you log in, the CLI command will continue, committing GitHub Actions workflow file to your repository under .github/workflows, setting the deployment credentials in your repository’s secrets, and registering the repository with your Web App so you can view deployment logs in the Deployment Center.
+
+
+
+
With a few CLI commands you’re up-and-running with GitHub Actions. Keep in mind that every application is unique, so you may need to update the curated workflow file to correctly build your app if you’re doing multi-step builds or using non-standard testing libraries. See the GitHub Actions Reference Documentation for more information.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
An Availability Zone is a high-availability offering that protects your applications and data from datacenter failures. Availability Zones are unique physical locations within an Azure region. Each zone is made up of one or more datacenters equipped with independent power, cooling, and networking. To ensure resiliency, there’s a minimum of three separate zones in all enabled regions. Build high-availability into your application architecture by co-locating your compute, storage, networking, and data resources within a zone and replicating in other zones. To learn more about Availability Zones, continue reading here.
+
+
Requirements
+
+
AZ support, otherwise known as zone redundancy, is a property of the App Service Plan (ASP). The following are the current requirements/limitations for enabling zone redundancy:
+
+
+
Both Windows and Linux are supported
+
Requires either Premium v2 or Premium v3 App Service Plans
+
Minimum instance count of 3
+
+
The platform will enforce this minimum count behind the scenes if you specify an instance count fewer than 3. This is due to the platform automatically spreading these VMs across 3 zones when zone redundancy is enabled.
+
+
+
Can be enabled in any of the following regions:
+
+
West US 2
+
West US 3
+
Central US
+
East US
+
East US 2
+
Canada Central
+
Brazil South
+
North Europe
+
West Europe
+
Germany West Central
+
France Central
+
UK South
+
Japan East
+
Southeast Asia
+
Australia East
+
+
+
Zone redundancy can only be specified when creating a new App Service Plan
+
+
Currently you can not convert pre-existing App Service Plan. See next bullet for details on how to create a new App Service Plan that supports zone redundancy.
+
+
+
AZ is only supported in the newer portion of the App Service footprint
+
+
Currently if you are running on Pv3 then you are already on the footprint that supports AZ and all you need to do is create a new App Service Plan
+
If you are not using Pv3 or a scale unit that supports AZ, are in a region that isn’t supported, or are unsure, follow the steps below:
+
+
Create a new resource group in a region that is supported
+
Create a new App Service Plan (and app) in a region of your choice using the new resource group
Currently, you need to use an ARM templates to create a zone redundant App Service. Once created via an ARM template, the App Service Plan can be viewed and interacted with via the Azure Portal as well as CLI tooling. An ARM template is only needed for the initial creation of the App Service Plan.
+
+
The only changes needed in an ARM template to specify a zone redundant App Service are the new zoneRedundant property (required) and optionally the App Service Plan instance count (i.e. capacity) on the Microsoft.Web/serverfarms resource. If you don’t specify a capacity, the platform defaults to 3. The zoneRedundant property should be set to true and capacity should be set based on the workload requirement, but no less than 3. Choosing the right capacity varies based on a number of factors as well as high availability/fault tolerance strategies, however a good rule of thumb is to ensure sufficient instances for the application such that losing one zone of instances leaves sufficient capacity to handle expected load.
+
+
+
TIP
+To decide instance capacity, you can use the following calculation:
+
+
Since the platform spreads VMs across 3 zones and you need to account for at least the failure of 1 zone, multiply peak workload instance count by a factor of zones/(zones-1), or 3/2. For example, if your typical peak workload requires 4 instances, you should provision 6 instances: (2/3 * 6 instances) = 4 instances.
+
+
+
+
In the case when a zone goes down, the App Service platform will detect lost instances and automatically attempt to find new instances to replace the ones that were lost. Note that if auto-scale is also configured, and if it decides more instances are needed, auto-scale will also issue a request to App Service to add more instances (auto-scale behavior is independent of App Service platform behavior). It is important to note that there is no guarantee that requests for additional instances in a zone-down scenario will succeed since back filling lost instances occurs on a best-effort basis. The recommended solution is to provision your App Service Plans to account for losing a zone as described previously in this article.
+
+
The ARM template snippet below shows the new zoneRedundant property and capacity specification.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 4 minute read
+
+
+
+ • By Jordan Selig
+
+ • August 25, 2021
+
+
+
+ NOTE! As of March 2023, the content in this post may be outdated. For the latest information on Availability Zone support for App Service, see Azure App S...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Jordan Selig
+
+ • August 31, 2021
+
+
+
+
+
+
+
We get a lot of questions on the App Service kind property, so we are sharing some information to help you understand what it is, what it does, and how to use it.
+
+
In general, kind is an ARM envelop property so almost every resource in Azure has one. See Resources - Get for more information on Azure resource properties. The way in which resources use this property varies service by service.
+
+
There are several different offerings in the Azure portal that use the same underlying Microsoft.Web\Sites resource. App Service at this time only uses the value of the kind property to specialize the UX of a Microsoft.Web\Sites resource in the Azure Portal. The value isn’t used for anything in the management plane.
+
+
The kind property of an app is set during the create flow and can’t be modified thereafter. The portal does this based on the create flow of your choice and/or the configuration you enter. This is also true of the App Service CLI and other clients like Visual Studio Code. You will need to manually set the kind property if you are creating resources through ARM templates, or using the ARM API directly.
+
+
Note that the kind property also shows up in App Service Plans (ASP). At this time, the value of this property for the ASP is meaningless and has no impact on your resource. For example, you can set kind to “Linux” for the ASP, but that won’t make your ASP a Linux ASP; the reserved property is what makes this distinction (if reserved = true, it’s a Linux ASP, otherwise it’s a Windows ASP).
+
+
For more information on how App Service uses the kind property as well as the current list of recommended values, visit the App Service Linux docs repo.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Jordan Selig
+
+ • August 31, 2021
+
+
+
We get a lot of questions on the App Service kind property, so we are sharing some information to help you understand what it is, what it does, and how to us...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Jordan Selig
+
+ • August 31, 2021
+
+
+
We get a lot of questions on the App Service kind property, so we are sharing some information to help you understand what it is, what it does, and how to us...
+
+
+
+
+
+
+ 4 minute read
+
+
+
+ • By Jordan Selig
+
+ • August 25, 2021
+
+
+
+ NOTE! As of March 2023, the content in this post may be outdated. For the latest information on Availability Zone support for App Service, see Azure App S...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Jason Freeberg
+
+ • August 9, 2021
+
+
+
With GitHub Actions you can set up a workflow to build and deploy your applications whenever there’s a commit on your main branch, or a PR is merged, or even...
This document covers some common operations that can be performed in an App Service and the effects in terms of availability and restart operations. Restarts on an App Service can be triggered either manually or by configuration changes. This document describes the effects only in App Services running on Windows operating system.
+
+
User-Initiated Restart Operations
+
+
From a user perspective, a restart can be initiated by using any of the following methods:
+
+
App Service Restart in Portal/Powershell/Azure CLI
+
+
This action will restart all the processes in every instance where your App Service is running. This will essentially restart your application fully, therefore expect some HTTP 503 errors during the process and a possible increase of resource consumption such as CPU during the operation. If settings such as Application Initialization are applied, the application won’t be fully available until the initialization completes as expected.
+
+
Kudu process is also restarted, so some operations can fail until the process is restarted.
+
+
Other App Services running on the same App Service Plan will not be restarted
+
+
Advanced Application Restart of instance
+
+
When restarting using the Advanced Application Restart feature in Diagnostic tools, the process of the specific instance selected will be restarted, and all the requests will be redirected to the other active instances if there were any. If settings such as Application Initialization are applied, the application won’t be fully available until the initialization completes as expected.
+
+
Soft Restart
+
+
When applying soft restart, which you can learn about here: Web Apps - Restart, the process will be recycled but it won’t go through a full re-load Slowness in requests can be expected. All the instances will be restarted when this operation is applied.
+
+
Restart of Specific App Service Plan worker node
+
+
Restarting a specific worker node of a specific App Service Plan is possible through API. The consequences of restarting the worker node are that all those App Services running on that instance will get their processes restarted. All the other instances will remain up and running. You can learn more about this operation here: App Service Plans - Reboot Worker
+
+
Deployment Slots Restarts
+
+
Restarting any deployment slot won’t affect any of the other deployment slots available for the app.
+
+
On the other hand, restarting an application could cause a possible increase in resource consumption, and depending on the application sometimes those extra resources can be high, so be aware that even though restarting a slot should not affect the other slots, resources are still shared, so it can indirectly affect the other slots if the App Service Plan does not have enough resources.
+
+
Swap Operations
+
+
Swapping between slots will trigger restarts of the source and destination slots as described here:
It is important to mention the use of Swap with preview. While this won’t stop the service from restarting, it will help make sure that the service is ready before the swap executes, so the swap will not be confirmed until the user confirms it, giving the opportunity to test it before swapping slots, therefore reducing downtime too.
+
+
Scaling Operations
+
+
Scaling out/in operations does not trigger a start or stop operation apart from the newly added instance or the instance that is going to be removed. Some slowness can be experienced in these operations on requests directed to the specific instance that is being added or removed.
+
+
Scaling up operations will trigger a full restart of the application as it will be fully moved to new instances. This involves all the processes expected from a cold start, so operations such as Application Initialization will be triggered. Another side effect of scaling up operations is that all the App Services hosted in the specific App Service Plan will be restarted as well. As all the apps restart at the same time, it is very common that the resource usage at that time will be higher than normal.
+
+
Auto-Heal
+
+
App Services provides two options to Auto-Heal your application:
These two options will restart the specific instance of your application if it matches the conditions. In the case of Custom Auto-heal, it will depend on the custom action that has been selected to be triggered, as some actions don’t really recycle the process. The restart applied will be a full restart cycle, so operations as Application Initialization will be expected. If the App Service only has one instance, 503 errors could be expected as well.
+
+
Enabling/Disabling Auto-Heal rules (proactive or custom) will have a full restart effect, including processes such as Application Initialization. Errors such as 503 can be expected.
+
+
Health Check Feature
+
Enabling HealthCheck will restart the application, so slowness can be expected.
+
+
HealthCheck feature also has some restart effects by design, as if a specific instance is having problems, it will try to restart the instance as explained in Health Check Feature. Additionally, if an instance becomes unavailable for a long time, HealthCheck will replace the unhealthy instances, up to a maximum of 3 per day.
+
+
Configuration changes effects on Availability
+
+
Most of the configuration changes trigger some sort of restart. It is important to be aware that any config changes in sections such as the ones listed below can trigger a restart, so it is recommended to plan accordingly before any change.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
This document covers some common operations that can be performed in an App Service and the effects in terms of availability and restart operations. Restarts...
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Yutang Lin
+
+ • September 22, 2021
+
+
+
+
+
+
+
+
+
App Service Domain is a domain resource on Azure which integrates with Azure DNS. This allows you to manage all your resources on Azure for when you need to get your web app up and running.
An Azure DNS resource also gets created with your App Service Domain by default. You can use your Azure DNS to manage the DNS of your domain.
+
+
You can look for the Azure DNS resource by either searching for the Azure DNS with the same domain name or go to it through your App Service Domain via “Manage DNS records”.
+
+
Transfering domain out
+
+
Transfering of domain out of Azure (not a registrar) to another registrar is supported and you may currently do so via API and PowerShell. You will need to get an authorization code which you can take to the registrar of choice to proceed with transfering out of your domain.
+
+
Exceptions for transfering domain out
+
+
You won’t be able to transfer your domain within 60 days of these events:
+
+
+
New domain registration
+
Transfer between different registrars
+
Change to registrant contact information
+
+
+
Special case for “.uk” domains
+
+
For any “.uk” domains, you’ll need the new registrar’s IPS tag. Create a support case and provide us the IPS tag. We will assist with updating the IPS tag on your domain to your new registrar and then you can complete the transfer out process with your new registrar.
+
+
What is an authorization code?
+
+
The authorization code is a unique string of characters consisting of letters, numbers, and special characters (ie. ? ! ^) that is required to transfer a domain from one registrar to another.
+
+
Getting authorization code with transfer out API
+
+
You can use the transfer out API:
+
+
PUT https://management.azure.com/subscriptions/<SUBSCRIPTION-ID>/resourceGroups/<RESOURCE-GROUP-NAME>/providers/Microsoft.DomainRegistration/domains/<DOMAIN-NAME>/transferout?api-version=2021-02-01
+
+
+
You may be able to run this API on Azure Resource Explorer. Fill out the necessary information in between the “<” and “>” from the above, then paste the API call to you Azure Resource Explorer. Highlight the entire line from “PUT” until “api-version=2021-02-01” and hit Ctrl+S to run the command. You would expect similar results from the image below.
+
+
+
+
Refer to the “authCode” value without the double quotes (“). This will be the authorization code you will need to provide the new domain registrar to transfer your domain out.
+
+
Getting authorization code with Powershell
+
+
There currently is no first class Powershell support for domain transfer out. However, you can use the following call below to get your authorization code:
+
+
Invoke-AzRestMethod -Path "/subscriptions/<SUBSCRIPTION-ID>/resourceGroups/<RESOURCE-GROUP-NAME>/providers/Microsoft.DomainRegistration/domains/<DOMAIN-NAME>/transferout?api-version=2021-02-01" -Method PUT
+
+
Refer to the “authCode” value without the double quotes (“). This will be the authorization code you will need to provide the new domain registrar to transfer your domain out.
+
+
Using Cloudshell
+
If you are having issues running the command in your local PowerShell, try using Cloud Shell on Azure Portal instead. You can access Cloud Shell on the top right navigation on Azure Portal. Once the Cloud Shell windows appear, check the top left corner of the window and make sure it says “PowerShell” and not “Bash”; otherwise, switch to “PowerShell”. Copy paste the command above and fill out the necessary information in between the “<” and “>”, then press enter.
+
+
+
+
Refer to the “authCode” value without the double quotes (“). This will be the authorization code you will need to provide the new domain registrar to transfer your domain out.
+
+
Transfering domain in
+
+
Transfering of domain into Azure is currently not supported. Any attempts made to transfer the domain into Azure risks getting the domain into a broken state. We will not be providing support to fix domains caught in this broken state due to unsupported transfer in scenario.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Yutang Lin
+
+ • September 22, 2021
+
+
+
App Service Domain is a domain resource on Azure which integrates with Azure DNS. This allows you to manage all your resources on Azure for when you need to ...
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Yutang Lin
+
+ • September 22, 2021
+
+
+
App Service Domain is a domain resource on Azure which integrates with Azure DNS. This allows you to manage all your resources on Azure for when you need to ...
This document covers some common operations that can be performed in an App Service and the effects in terms of availability and restart operations. Restarts...
How to Create a Web App with a Hybrid Connection
+
+
+
+
+
+
+
+
+ 9 minute read
+
+
+
+ • By Jordan Selig
+
+ • October 15, 2021
+
+
+
+
+
+
+
+
+
Hybrid Connections is a feature in App Service that provides access from your app to a TCP endpoint allowing your app to access application resources in any network that can make outbound calls to Azure over port 443. For those that want their apps in App Service to securely access other resources (typically outside of Azure - within Azure you would use Private Endpoints for example) but don’t want to set up an Azure ExpressRoute or connection via the public internet, Hybrid Connections can be an efficient and simple solution.
+
+
If you have decided to go down the route of using an App Service Hybrid Connection to connect your web app in App Service to a resource in another network, this tutorial will walk you through setting up the connection and demonstrate how you would connect to a database on your local machine. If you are unfamiliar with Hybrid Connections, take a look at the documentation for Azure Relay Hybrid Connections and App Service Hybrid Connections.
For this tutorial, a Node.js app with a MySQL database will be used. It is important to review the How-To guides specifically for configuring an app on the App Service Docs site to ensure you are configuring your app appropriately based on your app’s runtime. For more information on how to build apps with a database, see the tutorials posted on the App Service Docs site. The Node.js and MySQL app used for this tutorial was created by Atauba Prince. Check out his post to learn more about how it works and how to build it from scratch.
+
+
Prepare local MySQL
+
+
In this step, you create a database in your local MySQL server. If you don’t have a local MySQL server, install and start MySQL.
+
+
For this tutorial on Hybrid Connections, you will be connecting to your database as root. This is only being done for simplicity due to this being a Hybrid Connections focused tutorial. Connecting as root is not best practice and it’s recommended to use fine grained access control and to follow security best practices when accessing resources.
+
+
Connect to local MySQL server
+
+
In a terminal window, connect to your local MySQL server.
+
+
mysql -u root -p
+
+
+
If you’re prompted for a password, enter the password for the root account. If you don’t remember your root account password, see MySQL: How to Reset the Root Password.
+
+
If your command runs successfully, then your MySQL server is running. If not, make sure that your local MySQL server is started by following the MySQL post-installation steps.
At this point, your database is fully configured and you can move on to configuring the app.
+
+
Create a Node.js app locally
+
+
In this step, you will create a local Node.js app to connect to your database to ensure the app and database function as intended. It is good practice to ensure your app functions locally prior to deploying to App Service.
+
+
Clone the sample
+
+
In a terminal window, cd to a working directory.
+
+
+
+
Clone the sample repository and change to the repository root.
+
+
git clone https://github.com/achowba/node-mysql-crud-app
+ cd node-mysql-crud-app
+
+
+
+
Install the required packages.
+
+
npm install
+
+
+
+
+
Configure MySQL connection
+
+
In the repository root, open up the app.js file. If you are following along with the tutorial, you should not need to change anything. If you created a user to access your database, you will need to update the mysql.createConnection function with the appropriate parameters.
+
+
Run the application
+
+
Ensure that your MySQL server is up and running and go ahead and start the application.
+
+
node app.js
+
+
+
Check your terminal to ensure your code has no errors, then head over to your browser and open http://localhost:2000. Feel free to play around with the app by adding, editing, and deleting players. All updates that you make will be stored in the local database. Later on, when you create the app in App Service, since you will be connecting to this same database, you will see the same values.
+
+
Configure the app for App Service
+
+
Depending on the runtime of your app, you may need to make minor changes to ensure your App will run on App Service. For Node.js applications, review this guidance. For this tutorial, you will be modifying the database connection parameters to use app settings rather than hard-coded values. This is more secure and allows you to make updates without having to modify the source code and then wait for the app to re-build and re-deploy.
+
+
Go back to the app.js file and find the mysql.createConnection function. Replace the values for the parameters with environment variables. The function should look like the below. The names for the values of the settings are arbitrary, but note what they are as you will need them a little later on.
At this point, you are ready to deploy the app to App Service. Ensure you are in the root directory of your app and deploy your code using the az webapp up command. Pick a unique name for your app. You will be prompted if the name you choose is already in use. Note the addition of the os-type parameter. This is included here to create the app on App Service on Windows. If you want to create it on Linux, be aware that you need to modify the host parameter in your connection string to something other than “localhost” (i.e. if using Linux, don’t use “localhost” and instead use a different host or try your machine name). On Linux, “localhost” is an entity in the hosts file of basically any Linux entity which means it never actually resolves the hybrid connection as it would on Windows.
+
+
az webapp up --sku B1 --name <app-name> --os-type Windows
+
+
+
The command may take a few minutes to complete. When finished, navigate to your App Service in the Azure portal. At this point, you will have an App Service with deployed code, however your app will not function until you connect the database.
+
+
Configure database settings
+
+
In App Service, you set environment variables as app settings by using the az webapp config appsettings set command (you can also do this directly in the portal).
+
+
Execute the following command. Note the values for the app settings are what were previously used in the mysql.createConnection function. If you had different values, be sure to substitute them accordingly. Also be sure to fill in the placeholders for app name and resource group. These values can be found by navigating to your app in the portal or by executing the az webapp show command.
+
+
az webapp config appsettings set--name <app-name> --resource-group <resource-group> --settingsDB_HOST="localhost"DB_DATABASE="socka"DB_USERNAME="root"DB_PASSWORD=""DB_PORT="3306"
+
+
+
Create Hybrid Connection
+
+
The final step is to create the Hybrid Connection from your App Service to your local database. Be sure to review the system requirements for the Hybrid Connection Manager to ensure your scenario is eligible for this feature.
+
+
To create a Hybrid Connection, go to the Azure portal and select your app. Select Networking from the left-hand side then Hybrid connections under Outbound Traffic.
+
+
Towards the top of the screen, you should see a button to “Download connection manager.” Download and install the Hybrid Connection Manager (HCM) on your local machine. You will need that after configuring the connection in the portal.
+
+
To add a new Hybrid Connection, select [+] Add hybrid connection.
+
+
You’ll see a list of the Hybrid Connections that you already created if you have used Hybrid Connections before. To add one or more of them to your app, select the ones you want, and then select Add selected Hybrid Connection. If you are new to Hybrid Connections, you will need to create a one that connects to the MySQL database on your local machine. To do this, select Create new hybrid connection and input the required values. For this tutorial, the values are as follows:
+
+
+
+
+
Setting
+
Value
+
+
+
+
+
Hybrid connection Name
+
(create a name)
+
+
+
Endpoint Host
+
localhost
+
+
+
Endpoint Port
+
3306
+
+
+
Servicebus namespace
+
Create new (or use an existing one if you have one already)
+
+
+
Location
+
(pick a location close to you, I recommend using the same one as your resource group)
+
+
+
Name
+
(create a name)
+
+
+
+
+
Select Ok and your Hybrid Connection will get created and you will get re-directed to the Hybrid connections blade. You should see the Hybrid Connection you just created in the list with a status of “Not connected.”
+
+
The Hybrid Connections feature requires a relay agent in the network that hosts your Hybrid Connection endpoint. That relay agent is called the Hybrid Connection Manager (what you downloaded earlier). After installing the Hybrid Connection Manager, you can run HybridConnectionManagerUi.exe to use the UI for the tool. This file is in the Hybrid Connection Manager installation directory. In Windows 10, you can also just search for Hybrid Connection Manager UI in your search box.
+
+
To add one or more Hybrid Connections:
+
+
+
Select Add a new Hybrid Connection.
+
Sign in with your Azure account to get your Hybrid Connections available with your subscriptions. The Hybrid Connection Manager does not continue to use your Azure account beyond that.
+
Choose a subscription.
+
Select the Hybrid Connections that you want to relay.
+
Select Save.
+
You can now see the Hybrid Connections you added. You can also select the configured Hybrid Connection to see details.
+
Under Azure Status, ensure that you are “Connected”. If you are not, open up Task Manager on your Windows machine, go to the “Services” tab, and find the HybridConnectionManager service. Right click it and select Restart. Head back over to the Hybrid Connection Manager and select Refresh to update the Azure connection status. You should now see a “Connected” status. If not, have a look at the troubleshooting info for App Service Hybrid Connections.
+
+
+
Browse to the Azure app
+
+
Browse to http://<app-name>.azurewebsites.net and see your app exactly how it was running locally, but this time with the app in Azure connected to your local database!
+
+
Clean up resources
+
+
In the preceding steps, you created Azure resources in a resource group. The resource group has a name like “appsvc_rg_Linux_CentralUS” depending on your location. If you keep the web app running, you will incur some ongoing costs (see App Service pricing).
+
+
If you don’t expect to need these resources in the future, delete the resource group by running the following command:
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 9 minute read
+
+
+
+ • By Jordan Selig
+
+ • October 15, 2021
+
+
+
Hybrid Connections is a feature in App Service that provides access from your app to a TCP endpoint allowing your app to access application resources in any ...
Introduction to Azure Resource Graph for App Service
+
+
+
+
+
+
+
+
+ 5 minute read
+
+
+
+ • By Jordan Selig
+
+ • October 29, 2021
+
+
+
+
+
+
+
+
+
Azure Resource Graph (ARG) is an Azure service that gives you the ability to query and explore your Azure resources across a given set of subscriptions so that you can effectively govern your environments, especially if you manage multiple large scale environments. Azure Resource Graph powers Azure portal’s search bar, the new browse ‘All resources’ experience, and Azure Policy’s Change history visual diff.
+
+
With Azure Resource Graph, you can:
+
+
+
Query resources with complex filtering, grouping, and sorting by resource properties
+
Iteratively explore resources based on governance requirements
+
Assess the impact of applying policies in a vast cloud environment
For more details on how to use Azure Resource Graph, see the documentation.
+
+
Benefits of Azure Resource Graph
+
+
Prior to Azure Resource Graph, you had access to services like Azure Resource Manager (ARM) to query your resources. Resource Manager only supports queries over basic resource fields and provides the ability for calling individual resource providers for detailed properties one resource at a time. With Azure Resource Graph, you can access these properties the resource providers return without needing to make individual calls to each resource provider. This increases investigation efficiency and simplifies escalation paths for monitoring, incident response, and investigation teams.
+
+
Azure Resource Graph and App Service
+
+
Limitations
+
+
As of publishing this post, the following Microsoft.web resource types are supported by Azure Resource Graph:
+
+
+
microsoft.web/apimanagementaccounts
+
microsoft.web/apimanagementaccounts/apis
+
microsoft.web/certificates
+
Microsoft.Web/connectionGateways (On-premises Data Gateways)
Azure Resource Graph is currently receiving notifications for all resources tracked by ARM. If a resource or resource property changes outside of ARM (i.e. for resources not tracked by ARM), the team is currently working on onboarding these resources to enable users to have access to them using ARG. This is an ongoing process the ARG team is working through. Refer to the table and resource type reference for updates as additional resources gain support.
+
+
Querying resources
+
+
There are a number of quickstarts provided by the ARG team to help you get started with running queries. The Portal is a good place to start as it gives you a GUI based experience and formatted results that link to the queried resources for easy navigation. The query structure is based on Kusto Query Language (KQL).
+
+
To get you started with ARG for App Service, below are basic queries to give you an idea of what you can query as well as what these queries can be used for.
+
+
To see all sites across all subscriptions and resources groups:
+
+
resources
+| where type == "microsoft.web/sites"
+
+
+
Below is a sample of the output. If you have more sites in your account, they will all be listed.
+
+
+
+
You can select “See details” at the end of the row to view additional information about your resources.
+
+
You can query on any of the available fields for the specific resource. For example, if you want to see all your sites that are located in Central US:
+
+
resources
+| where type == "microsoft.web/sites"
+| where location == "centralus"
+
+
+
Or if you want to see all of your running sites, you can drill into the “properties” object:
+
+
resources
+| where type == "microsoft.web/sites"
+| where properties.state == "Running"
+
+
+
Many of the fields, specifically in the “properties” object, at this time will be showing as “null.” For example, if you are looking for details about the “siteConfig” object, the resource provider does not expose them at this time. This is due to these properties not being tracked by ARM and not being onboarded to ARG yet. Review the limitations to understand what properties are currently available.
+
+
Additionally, you can use ARG to do analytics and create dashboards to monitor your resources.
+
+
To get a sites count by region:
+
+
resources
+| where type == "microsoft.web/sites"
+| summarize count() by location
+
+
+
And to create a visual, you can select “Charts” under the query box and choose from the given visualization options. Below is a map of the distribution of sites in a demo account.
+
+
+
+
Change detection (preview)
+
+
Change detection is now in public preview for all resources that support complete mode deletion. For App Service, as of writing this article, the relevant resources that are supported include Microsoft.web/sites, Microsoft.web/sites/slots, Microsoft.Web/serverFarms as well as a couple additional resources that can be found here.
+
+
With change detection, the last 14 days of change history (properties that are added, removed, or altered) for the supported resources are available and can be accessed from the APIs directly or from the Portal which provides a visual diff for each change. Change history can assist in determining causes of non-compliance and help you determine when a change was made and by who so further investigation can be conducted.
+
+
For example, if you want to see when an app setting was modified, head over to the “Activity log” for your App Service and filter to your resource. Select the relevant “Operation name” and then “Change detection (preview)” in the flyout on the right. Double clicking into the operation in the list will take you to a visual diff so you can see exactly what changed in the json config of the resource.
+
+
+
+
Or if you want to see when someone modifies access restrictions for an app, you can see all changes to your firewall rules:
+
+
+
+
Change detection should enable you to view changes for any field in the json config of the supported resources as long as the field does not have a “null” value. A value of “null” indicates the resource provider is either not exposing this information at this time, or the field does not apply for your resource.
+
+
Wrapping up
+
+
The Azure Resource Graph team is continuously adding additional support for App Service to give users access to more information about their resources. Make sure to continuously check the table and resource type reference for updates as additional resource types get supported.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 5 minute read
+
+
+
+ • By Jordan Selig
+
+ • October 29, 2021
+
+
+
Azure Resource Graph (ARG) is an Azure service that gives you the ability to query and explore your Azure resources across a given set of subscriptions so th...
+
+
+
+
+
+
+ 5 minute read
+
+
+
+ • By Jordan Selig
+
+ • October 29, 2021
+
+
+
Azure Resource Graph (ARG) is an Azure service that gives you the ability to query and explore your Azure resources across a given set of subscriptions so th...
+
+
+
+
+
+
+ 9 minute read
+
+
+
+ • By Jordan Selig
+
+ • October 15, 2021
+
+
+
Hybrid Connections is a feature in App Service that provides access from your app to a TCP endpoint allowing your app to access application resources in any ...
General availability of Diagnostics tools for App Service on Linux .NET core apps
+
+
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Mark Downie, Puneet Gupta
+
+ • November 1, 2021
+
+
+
+
+
+
+
+
+
We are pleased to announce the public availability of Diagnostic tools for App Services Linux for .NET Core apps. With this capability, we now offer built-in support for collecting deep diagnostic artifacts that can help you debug application code issues. These artifacts include memory dumps and profiler traces. These tools empower developers to diagnose a variety of .NET code scenarios on Linux including:
+
+
+
Slow performance
+
High memory
+
High CPU
+
Runtime errors and exceptions
+
+
+
These tools enable you to self-diagnose your apps to identify if application code is contributing to the problem.
+
+
+
This tools are enabled with the latest Azure App Service platform update (96). To check the current platform version for you linux app, please check the environment variable PLATFORM_VERSION from the kudu console for your app.
+
+
+
Collection in Diagnose and Solve
+
+
To access these new capabilities on your .NET Core apps hosted in Linux, navigate to the Diagnose and Solve Blade > Diagnostics Tools and select either Collect .NET Profiler Trace or Collect Memory Dump.
+
+
+
+
Collection in Kudu
+
+
The Kudu console for Linux app services has been updated to include new collection options for memory dumps and profiles on the Process Explorer page.
+
+
To navigate to this new Kudu experience use the following (update <mysite> with your app name): https://<mysite>.scm.azurewebsites.net/newui to check out the new experience.
+
+
+
+
When you select the Process Explorer page, you can identify the process you want to debug. Use the drop-downs to select the type of memory dump and click Collect Dump. Alternatively, you can select the length of a profile from the drop-down and click Start Profiling.
+
+
Analyzing the problem
+
+
With the latest version of Visual Studio, you now have the ability to open and analyze managed dumps collected on Linux and use the best in class debugging tools available in Visual Studio!
+
+
Opening managed Linux Core dumps in Visual Studio
+
+
Memory dumps created on Windows machines have well-known extension (*.dmp) and thus have a straightforward association with your favorite memory analysis tools. By default, core dumps produced on Linux machines are created without an extension.
+
+
If your managed core dump doesn’t have an extension you can use the Open File dialogue, or drag and drop the file into your IDE, and Visual Studio will automatically identify and open it as a Linux core managed memory dump.
+
+
However, if the file was renamed to include the Windows dump extension (*.dmp) then use Visual Studio’s “Open with” feature in the “Open File” dialogue box, more details here.
+
+
Linux Core Dump File Summary
+
+
Once opened the Managed Linux Core Dump File Summary window shows a summary and module information for the dump file, and a list of Actions you can take, this remains consistent with existing dump handling experiences in Visual Studio.
+
+
+
To start debugging, select Debug with Managed Only from the Actions section of the summary page and start using the awesome debugging tools you have become accustomed to.
+
+
You could, for example, start by reviewing the list of Threads or Tasks using the Parallel Stacks window. Or dig a bit deeper by switching between threads and examining the most interesting frames from the Calls Stacks view. You might then examine the value and state of variables using the Locals or Autos window. Essentially you get to examine every detail of the process just as if you set a breakpoint in your managed code on Linux.
+
+
Diagnostics Analysis
+
+
Visual Studio has also developed a set of analyzers to help identify the key signals in your memory dump that might indicate a problem with your production service. Visual Studio currently supports the following Analyzers with new and improved analysis coming in the very near future:
In our Azure PaaS offerings, we continue to invest in a comprehensive diagnostics experience that helps you maximize your investment in Azure PaaS. We are excited to open up new debugging opportunities for deep diagnostics artifacts that will help you analyze the health of a broad and complex range of services.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
How-to setup Continuous Deployment using ACR Tasks with Windows containers
+
+
+
+
+
+
+
+
+ 5 minute read
+
+
+
+ • By Jeff Martinez
+
+ • November 1, 2021
+
+
+
+
+
+
+
+
+
ACR Tasks are a set of Azure CLI command features in Azure Container Registry that can help you automate container image builds. This can be integrated as part of your continuous deployment work flow to quickly update your container images. It will automate the process of building and pushing your images to your Azure Container Registry based on a set of triggers.
+
+
The following tutorial walks you through setting up an ACR Task with a Windows container app in a GitHub repository that will automate a build to your App Service upon code commit. Prerequisites include having your code available in a GitHub repository, an Azure Container Registry and a Windows container App Service provisioned.
+
+
Create a GitHub Access Token
+
+
In order for you to create the task you will need to include a GitHub Personal Access Token (PAT) from the repository your code lives in. This PAT acts as authentication to access your repository.
+
+
+
In the upper-right corner of your repository, click your profile photo, and click Settings.
+
On the left-hand side menu, find and click on Developer Settings.
+
On the following page, click on Personal access tokens.
+
Then click Generate new token on the upper-right hand side of the page.
+
+
To generate a new token you will first need to fill out the required form.
+
+
Fill in the following:
+
+
+
Note: name your token
+
Expiration: 90 days
+
Scope: repo
+
+
+
+
+
Then, you can scroll to the bottom of the page and click Generate token.
+
Copy your token on the next page and put it somewhere safe. You will not be shown this token again and we’ll need to use it when we create the task in a later step
+
+
+
For more information on creating a Personal Access Token, see this GitHub doc.
+
+
Enable Admin User in Azure Container Registry
+
+
Before we create our task, we need to enable Admin user in your Container Registry. Enabling this will allow resource access when we add the webhook in a later step.
+
+
Go to your Container Registry resource
+
Go to Access Keys under Settings
+
Go to Admin user and click on the toggle to enable Admin user
+
+
+
+
+
Build and Deploy with ACR build
+
+
Now that we have our container registry and GitHub repo setup, we can run the acr build command. This will require the use of the Azure CLI. Make sure you are on the latest version of az cli before starting.
+
+
The ACR Task uses both docker build and docker push to build your images. Using this command you will create your image name and tag, which will build from your GitHub repo Dockerfile, then push it to your container registry.
+
+
To run the command you will need the following:
+
+
Azure Container Registry Name
+
GitHub repository URL
+
+
+
+
+
Open Command Prompt or Azure Cloud Shell and enter the command below. Keep in mind, this is where you will define your image name and tag.
+
+
az acr build -r myacrregistry https://github.com/myusername/pdfsample.git -f PDFSample/Dockerfile --platform windows --image mypdfsample:latest
+
+
+
+
+
Once the command is finished running you’ll notice a set of dependencies are found in the output. This includes your image and runtime information. You can now visit your container registry resource to verify that your repository has been pushed to ACR.
+
+
+
+
Create the ACR Task
+
+
Next, we will create our Task. This task will setup an automated trigger on code commit which will run a docker build and push the container to your registry.
+
+
To run the command you will need the following:
+
+
Azure Container Registry Name
+
GitHub repository URL
+
GitHub Personal Access Token
+
+
+
+
+
In your Command Prompt or Azure Cloud Shell enter the command below. Keep in mind, this is where you will define the name of your task.
+
+
az acr task create --registry myacrtaskregistry --name taskmypdfsample --image mypdfsample:latest --context
+https://github.com/myusername/pdfsample.git
+--file PDFSample/Dockerfile --git-access-token <access-token> --platform windows
+
+
+
+
+
Once you create the task you’ll notice the json output has information about which triggers are enabled. By default, the base image trigger and the commit triggers are enabled.
+
+
+
+
At this point you can verify that your task will run. We can run a manual test trigger by using the following command:
+
+
az acr task run --registry myacrtaskregistry --name taskmypdfsample
+
+
+
This will run a manual test to trigger your build. Since our task is configured to trigger on code commit by default, you can also test triggering the task by committing code to your GitHub repository.
+
+
To verify that your tasks have run successfully use the below command
+
+
az acr task list-runs --registry acrtaskreg2 --output table
+
+
+
In this table you can verify the source of the Trigger, Platform, and Duration of the task.
+
+
+
+
Now that we know our task is working, we can setup continuous deployment in our next step.
+
+
Enable Continuoud deployment in your Web App
+
+
At this point if you haven’t already created your Web App, you can do that now with the container you pushed previously to ACR as your image source. Once your Web App is created or if you are working with an existing Web App, you can go through the following steps to setup continuous deployment between your container registry and web app.
+
+
+
Go to your resource and click Deployment Center under Deployment
+
+
In the Settings tab, go to Continuous deployment and click On
+
+
+
+
Click Save at the top of the screen
+
+
+
Once it’s saved, a webhook will be added to your container registry resource. You can verify that it’s enabled by going to Webhooks under Services in your container registry resource.
+
+
+
+
Now that your webhook is enabled, you can create a code commit to your repository which will trigger your task and run the webhook. Once the task has finished running you can click on the webhook name to view the latest push.
+
+
+
+
Since your webhook is scoped to your image, it will recognize changes made to the repository with the same tag. If you use a different tag than the one that is scoped, it will not recognize the change.
+
+
Another way to verify that your webhook has worked is to view your container logs in the Deployment Center. Go to the Deployment Center and view the Logs tab. Here you will see that it has downloaded a newer image and is creating the container.
+
+
+
+
Once the newer image is downloaded and the container has started, you can browse to your application and view the code changes that you’ve committed from GitHub. You have now setup continuous deployment via ACR Task that triggers a build and updates your container image on code commit. Your scoped webhook to your specific image and tag will then continually update the image in App Service when a new image is recognized.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 5 minute read
+
+
+
+ • By Jeff Martinez
+
+ • November 1, 2021
+
+
+
ACR Tasks are a set of Azure CLI command features in Azure Container Registry that can help you automate container image builds. This can be integrated as p...
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Mark Downie, Puneet Gupta
+
+ • November 1, 2021
+
+
+
We are pleased to announce the public availability of Diagnostic tools for App Services Linux for .NET Core apps. With this capability, we now offer built-in...
We are happy to announce that App Service is rolling out day 0 support for .NET 6.0 applications across all public regions and scenarios on both Windows and Linux App Service plans.
+
+
The App Service and .NET teams worked closely together to deliver this functionality on the same day as .NET 6.0 reached GA (see .NET 6.0 GA announcement). Day 0 support for .NET 6.0 GA delivers on the promise made last year during .NET 5.0 GA announcement.
+
+
Joining the party this year with day 0 support are:
+
+
+
Azure Functions where you can host serverless functions using Functions Runtime v4.
+
Azure Static Web Apps that supports full-stack .NET 6.0 applications with Blazor WebAssembly frontends and Azure Functions APIs.
+
+
+
To achieve day 0 support across all scenarios we continue to leverage the Early Access mechanism to seed and distribute the new runtime globally: Learn more about App Service Early Access.. The early access release will be followed by additional deployments to fully integrate the new bits across our fleet expecting to be fully done by the end of the week.
+
+
If you already have an app targeting and earlier preview of .NET 6.0 on the platform, there is no need to take action as the new runtime will be picked up on the next application restart once the update is available for your app. You can trigger this manually by starting and stopping your app.
+
+
If you want to learn more, be sure to checkout our session during .NET Conf 2021. Wednesday 11/10 @ 9:30am PST @bktv99 will be taking the stage to show you “6 ways to get started with .NET 6.0 and App Service”.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
We are happy to announce that App Service is rolling out day 0 support for .NET 6.0 applications across all public regions and scenarios on both Windows and ...
Upcoming Change to App Service Certificate on November 30 2021
+
+
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Yutang Lin
+
+ • November 22, 2021
+
+
+
+
+
+
+
+
+
Starting November 30 2021, GoDaddy will no longer be issuing certificates for the additional ‘www’ domain when validating domain ownership through HTML web page verification (AKA token verification) method or the App Service verification, which automates token verification method. This change will affect all certificates (new, renew, rekey) that require validation.
+
+
This article will go through the following sections to provide you more information on how to handle your certificate renewals to avoid any possible downtime for your web app when using an App Service Certificate.
If you renew your certificate without a ‘www’ domain, this may affect your SSL bindings if you use an App Service Certificate for your ‘www’ domain.
+
+
Let’s say you already added a ‘www’ custom domain to your web app and have already added an SSL binding with an App Service Certificate that secures a ‘www’ domain. If you renewed your certificate without a ‘www’ domain, your SSL bindings CANNOT be updated/synced with that new certificate. Thus you are risking your SSL bindings to keep using the old certificate.
+
+
To avoid this issue, do NOT use HTML web page verification or App Service Verification. Use either the mail verification or the manual DNS verification instead. Refert to how to get certificate issued for a ‘www’ domain section of the article.
+
+
How to get certificate issued for a ‘www’ domain
+
+
You may still get a certificate with ‘www’ domain when you verify your domain ownership with DNS manual verification or mail verification.
+
+
DNS manual verification
+
+
You will need to create a TXT record using the token verification token in your domain name’s zone (DNS) records.
+
+
Mail verification
+
+
An email will be sent to the domain administrators with instructions on how to verify domain ownership for your certificate.
+
+
For example, if the certificate is for domain.com, emails will be sent to:
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Yutang Lin
+
+ • November 22, 2021
+
+
+
Starting November 30 2021, GoDaddy will no longer be issuing certificates for the additional ‘www’ domain when validating domain ownership through HTML web p...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Yutang Lin
+
+ • November 22, 2021
+
+
+
Starting November 30 2021, GoDaddy will no longer be issuing certificates for the additional ‘www’ domain when validating domain ownership through HTML web p...
We are happy to announce that App Service is rolling out day 0 support for .NET 6.0 applications across all public regions and scenarios on both Windows and ...
+
+
+
+
+
+
+ 5 minute read
+
+
+
+ • By Jeff Martinez
+
+ • November 1, 2021
+
+
+
ACR Tasks are a set of Azure CLI command features in Azure Container Registry that can help you automate container image builds. This can be integrated as p...
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Mark Downie, Puneet Gupta
+
+ • November 1, 2021
+
+
+
We are pleased to announce the public availability of Diagnostic tools for App Services Linux for .NET Core apps. With this capability, we now offer built-in...
Azure App Service and Azure Functions on Azure Stack Hub 2021 Q3 Released
+
+
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Andrew Westgarth
+
+ • December 10, 2021
+
+
+
+
+
+
+
The 2021 Q3 update to Azure App Service on Azure Stack Hub is now available. This release updates the resource provider and brings the following key capabilities and fixes:
+
+
+
Updates to App Service Tenant, Admin, Functions portals and Kudu tools. Consistent with Azure Stack Portal SDK version.
+
Updates to core service to improve reliability and error messaging enabling easier diagnosis of common issues.
+
Updates to the following application frameworks and tools:
+
+
ASP.NET Core
+
+
3.1.16
+
5.0.7
+
6.0.0
+
+
+
Azul OpenJDK
+
+
8.52.0.23
+
11.44.13
+
+
+
Git 2.33.1.1
+
NodeJS
+
+
10.15.2
+
10.16.3
+
10.19.0
+
12.21.0
+
14.15.1
+
14.16.0
+
+
+
NPM
+
+
6.14.11
+
+
+
PHP
+
+
7.2.34
+
7.3.27
+
7.14.15
+
+
+
Tomcat
+
+
8.5.58
+
9.0.38
+
+
+
Updated Kudu to 94.30524.5227
+
+
+
Updates to underlying operating system of all roles:
+
The App Service on Azure Stack Hub 2021.Q3 build number is 95.1.1.539 and requires Azure Stack Hub to be updated with 2108 prior to deployment/upgrade.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Andrew Westgarth
+
+ • December 10, 2021
+
+
+
The 2021 Q3 update to Azure App Service on Azure Stack Hub is now available. This release updates the resource provider and brings the following key capabili...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Andrew Westgarth
+
+ • December 10, 2021
+
+
+
The 2021 Q3 update to Azure App Service on Azure Stack Hub is now available. This release updates the resource provider and brings the following key capabili...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Andrew Westgarth
+
+ • December 10, 2021
+
+
+
The 2021 Q3 update to Azure App Service on Azure Stack Hub is now available. This release updates the resource provider and brings the following key capabili...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Yutang Lin
+
+ • November 22, 2021
+
+
+
Starting November 30 2021, GoDaddy will no longer be issuing certificates for the additional ‘www’ domain when validating domain ownership through HTML web p...
We are happy to announce that App Service is rolling out day 0 support for .NET 6.0 applications across all public regions and scenarios on both Windows and ...
+
+
+
+
+
+
+ 5 minute read
+
+
+
+ • By Jeff Martinez
+
+ • November 1, 2021
+
+
+
ACR Tasks are a set of Azure CLI command features in Azure Container Registry that can help you automate container image builds. This can be integrated as p...
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Mark Downie, Puneet Gupta
+
+ • November 1, 2021
+
+
+
We are pleased to announce the public availability of Diagnostic tools for App Services Linux for .NET Core apps. With this capability, we now offer built-in...
+
+
+
+
+
+
+ 5 minute read
+
+
+
+ • By Jordan Selig
+
+ • October 29, 2021
+
+
+
Azure Resource Graph (ARG) is an Azure service that gives you the ability to query and explore your Azure resources across a given set of subscriptions so th...
+
+
+
+
+
+
+ 9 minute read
+
+
+
+ • By Jordan Selig
+
+ • October 15, 2021
+
+
+
Hybrid Connections is a feature in App Service that provides access from your app to a TCP endpoint allowing your app to access application resources in any ...
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Yutang Lin
+
+ • September 22, 2021
+
+
+
App Service Domain is a domain resource on Azure which integrates with Azure DNS. This allows you to manage all your resources on Azure for when you need to ...
This document covers some common operations that can be performed in an App Service and the effects in terms of availability and restart operations. Restarts...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Jordan Selig
+
+ • August 31, 2021
+
+
+
We get a lot of questions on the App Service kind property, so we are sharing some information to help you understand what it is, what it does, and how to us...
+
+
+
+
+
+
+ 4 minute read
+
+
+
+ • By Jordan Selig
+
+ • August 25, 2021
+
+
+
+ NOTE! As of March 2023, the content in this post may be outdated. For the latest information on Availability Zone support for App Service, see Azure App S...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Jason Freeberg
+
+ • August 9, 2021
+
+
+
With GitHub Actions you can set up a workflow to build and deploy your applications whenever there’s a commit on your main branch, or a PR is merged, or even...
+
+
+
+
+
+
+ 23 minute read
+
+
+
+ • By Jordan Selig
+
+ • July 29, 2021
+
+
+
There are a number of ways to deploy infrastructure to Azure, what you pick depends on a number of factors including skill level, experience, job requirement...
+
+
+
+
+
+
+ 8 minute read
+
+
+
+ • By Jordan Selig
+
+ • July 23, 2021
+
+
+
Get started with Azure App Service by deploying an app to the cloud using a Bicep file and Azure CLI in Cloud Shell. Because you use a free App Service tier,...
One of the tools that Azure provides to enforce governance and controls is Azure Policies. By employing Azure policies, IT organizations are able to enforce ...
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Jeff Martinez
+
+ • July 8, 2021
+
+
+
With the release of the App Service on Kubernetes preview, you can now run App Service on Kubernetes deploying your web apps to Azure Kubernetes Service, or ...
App Service has a list of Trusted Root Certificates which you cannot modify in the multi-tenant variant version of App Service, but you can load your own CA ...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Andrew Westgarth
+
+ • June 11, 2021
+
+
+
The 2021 Q1 update to Azure App Service on Azure Stack Hub is now available. This release updates the resource provider and brings the following key capabili...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Puneet Gupta
+
+ • June 9, 2021
+
+
+
Azure App Services has the proactive crash monitoring feature, which checks for process crashes and collects diagnostic data that helps you determine the roo...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Byron Tardif
+
+ • June 9, 2021
+
+
+
We are happy to announce that App Service now supports apps targeting .NET 6 Preview 4 across all public regions and scenarios on both Windows and Linux App ...
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Christina Compy
+
+ • May 25, 2021
+
+
+
The App Service Environment v3 (ASEv3) has been in preview since November 2020. During this time it was made available across most regions, received numerous...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Yutang Lin
+
+ • May 25, 2021
+
+
+
App Service Managed Certificate is now in General Availability for both apex domains and sub-domains. This feature allows customers to secure their custom do...
+
+
+
+
+
+
+ 2 minute read
+
+
+
+ • By Jason Freeberg and Julia Goloshubina
+
+ • May 10, 2021
+
+
+
We are happy to share that Azure Monitor Application Insights monitoring is now available for Java and Node.js apps on App Service for both Windows and Linux...
We are happy to announce the availability of Auto Heal feature for Linux apps on Azure App Service. Auto Heal allows you to mitigate your apps when it runs i...
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Jeff Martinez
+
+ • April 15, 2021
+
+
+
.NET 6 is the latest release version that will include the final pieces bringing the best of Core, Framework, Xamarin, and Mono to a unified platform that st...
+
+
+
+
+
+
+ 4 minute read
+
+
+
+ • By Michimune Kohno and Sanghmitra Gite
+
+ • April 14, 2021
+
+
+
The Azure App Service is a PaaS solution offering in Azure which constantly updates the platform. One of the top requests from customers is to receive a noti...
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Jeff Martinez
+
+ • April 14, 2021
+
+
+
.NET 5 is the first major release in the .NET unification journey bringing together the best of Core, Framework, Xamarin, and Mono to provide an improved dev...
Troubleshooting networking & connectivity issues when running on App Services just became easier. We are happy to announce the release of our new diagnos...
In this article I will walk you through setting up a secure, resilient site with Azure App Service using some new features that have recently been released o...
+
+
+
+
+
+
+ 6 minute read
+
+
+
+ • By Jeff Martinez
+
+ • March 15, 2021
+
+
+
gRPC is a modern protocol which uses HTTP/2 to streamline messaging between clients and back-end servers and is an efficient way to connect services that req...
+
+
+
+
+
+
+ 13 minute read
+
+
+
+ • By Yutang Lin
+
+ • March 11, 2021
+
+
+
In this article, we will review different App Service offerings with side-by-side comparisons to show how you can save more with App Service. The offerings w...
+
+
+
+
+
+
+ 5 minute read
+
+
+
+ • By Jeff Martinez
+
+ • March 4, 2021
+
+
+
Windows containers on App Service can help you easily modernize your application by making it easier to Lift-and-Shift to App Service and install custom depe...
When enabling private endpoint for a web app, both the web app and the Source Control Manager (SCM) site, also sometimes referred to as kudu, are locked down...
+
+
+
+
+
+
+ 4 minute read
+
+
+
+ • By Yutang Lin
+
+ • March 2, 2021
+
+
+
App Service Managed Certificate (preview) now lets you secure your apex domains on your web apps at no additional charge. This feature is similar to the curr...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Jeff Martinez
+
+ • March 2, 2021
+
+
+
Source Network Address Translation (SNAT) ports are used by App Service to translate outbound connections to public IP addresses. However, there are limitat...
+
+
+
+
+
+
+ 4 minute read
+
+
+
+ • By Jason Freeberg
+
+ • March 1, 2021
+
+
+
An earlier article explained how to use self-hosted Azure DevOps agents to build and deploy your applications to a web app that has Private Endpoints enabled...
A crash of a process happens when the process terminates due to an unhandled exception within the application code. A crash leads to a restart and all the in...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Jason Freeberg
+
+ • February 5, 2021
+
+
+
Last week an incident occurred that caused .NET 5 NuGet package operations to fail on some Debian-family distributions. Specifically, Debian and Ubuntu maint...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Gaurav Seth
+
+ • February 5, 2021
+
+
+
Join our upcoming webinar on Tuesday, February 23 from 1:00 to 2:00pm Pacific Time! Learn how Azure can help you to innovate with your .NET web apps and SQL ...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Byron Tardif, Elliott Hamai
+
+ • January 26, 2021
+
+
+
We are happy to share a new resource create blade for App Service and Azure databases. This new experience, currently in preview, deploys a PostgreSQL or Azu...
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Andrew Westgarth
+
+ • January 6, 2021
+
+
+
As Windows Azure Pack Web Sites v2 heads towards the end of extended support in 2022, it is important for customers to plan to migrate their workloads from t...
+
+
+
+
+
+
+ 5 minute read
+
+
+
+ • By Jason Freeberg
+
+ • January 4, 2021
+
+
+
With the recently-announced Private Endpoints integration you can block inbound access from the internet to your web app. Before this integration, developers...
NOTE
+At this time, the public preview supports a subset of possible ASE configurations. Be sure to review the supported scenarios to see if you can migrate at this time using the feature and stay tuned for updates as we release additional capabilities.
+
+
+
+
An Azure portal experience for migration will be available at the start of February, 2022. Be on the lookout for additional announcements.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Jordan Selig
+
+ • January 18, 2022
+
+
+
We are happy to announce the availability of the public preview of the App Service Environment (ASE) v3 migration feature. With this feature, you’ll be able ...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Jordan Selig
+
+ • January 18, 2022
+
+
+
We are happy to announce the availability of the public preview of the App Service Environment (ASE) v3 migration feature. With this feature, you’ll be able ...
Routine Planned Maintenance Notifications for Azure App Service
+
+
+
+
+
+
+
+
+ 6 minute read
+
+
+
+ • By James Mulvey
+
+ • February 1, 2022
+
+
+
+
+
+
+
Azure App Service is regularly updated to provide new features, new runtime versions, performance improvements, and bug fixes. One of the top feature requests from our customers is the ability to receive notifications before one of the platform updates occurs. We are happy to announce that, starting early March 2022, notifications for scheduled maintenance on Azure App Service will be available for App Service Environments V3 (ASEv3) and multi-tenant applications.
+
+
With these notifications, you will be able to receive email or SMS text alerts before a platform upgrade starts, while it is in progress, and when the upgrade completes. For multi-tenant applications, we have also included a more advanced 7-day notification option allowing for more time to prepare for an upgrade. This 7-day notification will alert customers to an upcoming platform upgrade approximately 1 week before the event begins. You can also invoke Azure Functions or Logic Apps based on these notifications. This 7-day addition has been rolled out for multi-tenant environments across our regions with App Service Environments V3 coming soon. This article shows how to set up email and SMS alerts, as well as Function and Logic Apps, to consume these events. For critical security or livesite updates, we may not be able to send notifications as these updates are time sensitive. You may receive just pre-start, in-progress, and completion notifcations but not 7-day notifications if there is not sufficient lead time.
+
+
Overview
+
+
The maintenance notifications for App Service are surfaced as events in Azure Monitor. This means that you can set up your email address and/or SMS phone number when a notification is generated. You can also set up a trigger for your custom Azure Function or Logic App, which allows you to automatically take action to your resources. For example, you can automatically divert all the traffic from your App Service Environment in one region which will be upgraded to an App Service Environment in another region in order to avoid any potential impact. Then, you can automatically change the traffic back to normal when an upgrade completes. Please refer to the Logic App sample for automatic traffic diversion for Azure App Service for more details.
+
+
Viewing upgrade notifications
+
+
From the Azure portal, go to Home > Monitor > Service Health > Planned maintenance. Here you can see all active (including upcoming or in-progress) notifications for the selected subscriptions. To make it easy to find App Service upgrade events, click the Service box, check all App Service types and uncheck everything else. To see past notifications, navigate to Health history and filter Planned maintenance from the Health Event Type box.
+
+
+
+
Setting up alerts
+
+
+
Open Azure portal, sign in with your credentials.
+
Search for the icon named Monitor and click it. If you cannot see it, click the arrow on the right to show All services, then search Monitor.
+
In the left menu items, click Alerts.
+
Click Service Health.
+
Click Add service health alert at the top center.
+
In the Condition section, choose the subscription that owns your App Service Environment(s).
+
At the Service(s) box, choose all items starting with App Service:
+
+
App Service
+
App Service \ Web Apps
+
App Service (Linux)
+
App Service (Linux) \ Web App for Containers
+
App Service (Linux) \ Web App
+
+
+
At the Region(s) box, make sure to check the regions of the App Service Environment(s).
+
At the Event type box, check Planned maintenance.
+
In the Actions section, click Add action groups.
+
Click Create alert rule.
+
Select a subscription that your App Service Environment belongs to.
+
Choose a resource group and name an action group. Set Display name to something you can easily identify the action for (IMPORTANT: The display name will be shown in every email/SMS/post of the notifications).
+
If you want to receive text notifications, in the Notifications section, choose Email/SMS message/Push/Voice at the Notification type. Then choose output channels you need (For example, Email or SMS.) Put email addresses or phone numbers as necessary.
+
If you want to hook up your custom automation, in the Actions section, choose Azure Function or Logic App at the Action type. Put a name into the Name. Select your app.
+
Press Save changes. The page will go back to the Rules management page.
When do you send the upgrade notifications?
+For App Service Plans, the first notifications will be created about 7 days before an actual upgrade operation starts. A notification is then sent, to both ASEs and App Service Plans, 60-90 minutes before maintenance starts and then again once upgrades are underway.
+
+
Once the upgrade starts, we send in-progress notifications every 12 hours until the operation completes. After it has finished, we send a notification of completion.
+
+
Will the upgrade happen in exactly 7 days?
+The exact timing of the maintenance may vary depending on several factors, but will not be before 7 days. You will still receive a notification shortly before maintenance begins.
+
+
When will 7-day notifications be available for ASE?
+While the 7-day notifications will not be applicable for ASEs, ASEv3 Customers will have the option to manually upgrade their resources on-demand via manual deployment preferences starting end of Q1 2023.
+
+
How long do App service Upgrades take?
+Our typical time for completing updates worldwide is about 10 business days, which allows us to deploy during each region’s off hours and also avoid deploying to Paired Regions at the same time (for example, East US and West US). Throughout this duration, you may receive multiple in-progress notifications - this is expected.
+
+
Why did I not receive a notification when my App Service was upgraded?
+There are two main reasons why customers may not receive notification of an upgrade. The first reason is that customers may not have followed the opt-in steps listed above. The second reason for not receiving upgrade notifications is the maintenance performed was part of a security patch or hotfix that may not have had enough lead time to provide notifications. These events should not cause any impact to current resources.
+
+
Why did I not receive a 7-day advance notification before receiving in-progress notifications
+This upgrade was likely an unplanned maintenance event, either a hotfix or critical security patch. As Microsoft commits to ensuring security of resources, we may not always have 7 days lead time when pushing an update to address these concerns. These notifications will specify unplanned maintenance in the title.
+
+
We received notification for upgrade, but we do not see Application restarts/instance movements on the App service. What did we receive an alert for?
+Usually, this happens when upgrades are still working their way through a given region and not yet reached your App Service. App Service follows safe deployment practices, requiring segmented deployment of upgrades.
+
+
Why did I not receive a notification when my App Service was upgraded?
+There are two main reasons why customers may not receive notification of an upgrade. The first reason is that customers may not have followed the opt-in steps listed above. The second reason for not receiving upgrade notifications is the maintenance performed was part of a security patch or hotfix that may not have had enough lead time to provide notifications. These events should not cause any impact to current resources.
+
+
Can I invoke my Azure Function when a notification comes?
+Yes, you can set up action to trigger your Azure Function or Logic App. It is recommended to not trigger automation based on the 7-day notiifcation as exact times may vary. The 7 day notification is for awareness and using the follow on notifications of before, during, and after completion will be more precise. Please see Logic App sample for automatic traffic diversion for Azure App Service as an example.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 6 minute read
+
+
+
+ • By James Mulvey
+
+ • February 1, 2022
+
+
+
Azure App Service is regularly updated to provide new features, new runtime versions, performance improvements, and bug fixes. One of the top feature request...
We are happy to announce the public preview of the WordPress offering on App Service. This offering will enable you to deploy and host new WordPress websites with ease.
In the preview period, WP installation may take up to 10 minutes. We’re working to improve the deployment time.
+
+
+
WordPress Linux Hosting Plans
+
The latest update provides you with four hosting plans. Hosting plans and SKUs are detailed below:
+
+
+
+
+
Hosting plan
+
Web app
+
Database (MySQL Flexible Server)
+
+
+
+
+
Basic
+
B1
+
Burstable, B1s
+
+
+
Development
+
S1
+
Burstable, B1ms
+
+
+
Standard
+
P1V2
+
Burstable, B2s
+
+
+
Premium
+
P1V3
+
Gen Purpose, D2ds_v4
+
+
+
+
+
Plugins
+
The new experience ships with two pre-installed plugins, W3TC and WP Smush.
+W3TC plugin pre-installed. It uses Redis cache to process requests faster. WordPress pages, objects, and DB objects are cached to improve performance.
+WP Smush will compress images while retaining optimal quality. This will improve load times and increase WordPress performance.
+
+
Changing MySQL Database Password
+
WordPress deployment creates an AppService and a MySQL database server, under the same resource group. Login credentials for the MySQL server are generated randomly during deployment process.
+
+
Database connection details are configured into WordPress via ‘Application Settings’ option available in the AppService. Note that you can retrieve the database connection details from Application Setting section in case you forgot to note them down during the creation time.
+
+
First, go to the MySQL resource corresponding to your WordPress deployment, and click on ‘Reset Password’ option as shown below. Now enter the new password and click on Save. Wait until the action is completed.
+
+
Then navigate to the Configuration section of your AppService and update the Application Settings corresponding to the database connection details. Once you update the values, click on Save and wait for app to get restarted. The settings are as follows
+
+
+
DATABASE_HOST
+
DATABASE_NAME
+
DATABASE_USERNAME
+
DATABASE_PASSWORD
+
+
+
Changing WordPress Admin Password
+
+
WordPress is installed on the AppService with the admin credentials provided by the user during the create process. These details are also added to the Application Settings of the AppService for initial deployment purpose. You can retrieve the credentials from here in case you forgot to note them during the creation time.
+
+
Note that changing the admin credentials values in Application Settings after the deployment doesn’t update the same in WordPress, meaning that it does not actually changes the credentials. These App Settings only meant for initial deployment purpose and, also to help the users note them down for the first time.
+
+
Actual update of admin credentials must be done via WordPress Admin dashboard. And this process doesn’t update the values back in the Application Settings of the AppService, as those parameters are out of sync once the app is created.
+
+
Go to the admin dashboard of your WordPress site by using the following link format https://.azurewebsites.net/wp-admin. It will prompt you to login. Use the credentials you have entered during the create process to login to the dashboard.
+
+
Then navigate to Users section as shown below and move your cursor over the user entry you want to make changes to and click Edit option which appears there.
+
+
Set the new password using the option provided there and click on “Update Profile” to save the changes.
+
+
Environment variables
+
+
+
+
+
Application Setting
+
Scope
+
Value
+
Max
+
Description
+
+
+
+
+
WEBSITES_CONTAINER_START_TIME_LIMIT
+
Web app
+
900
+
-
+
The amount of time the platform will wait (for the site to come up) before it restarts your container. WP installation takes around 5-10 mins after the AppService is deployed. By default, timeout limit for Linux AppService is 240 seconds. So, overriding this value to 900 seconds for WordPress deployments to avoid container restarts during the setup process. This is a required setting, and it is recommended to not change this value.
+
+
+
WEBSITES_ENABLE_APP_SERVICE_STORAGE
+
Web App
+
true
+
-
+
When set to TRUE, file contents are preserved during restarts.
+
+
+
WP_MEMORY_LIMIT
+
WordPress
+
128M
+
512M
+
Frontend or general wordpress PHP memory limit (per script). Can’t be more than PHP_MEMORY_LIMIT
+
+
+
WP_MAX_MEMORY_LIMIT
+
WordPress
+
256M
+
512M
+
Admin dashboard PHP memory limit (per script). Generally Admin dashboard/ backend scripts takes lot of memory compared to frontend scripts. Can’t be more than PHP_MEMORY_LIMIT.
+
+
+
PHP_MEMORY_LIMIT
+
PHP
+
512M
+
512M
+
Memory limits for general PHP script. It can only be decreased.
+
+
+
FILE_UPLOADS
+
PHP
+
On
+
-
+
Can be either On or Off. Note that values are case sensitive. Enables or disables file uploads.
+
+
+
UPLOAD_MAX_FILESIZE
+
PHP
+
50M
+
256M Max file upload size limit. Can be increased up to 256M.
+
+
+
+
POST_MAX_SIZE
+
PHP
+
128M
+
256M
+
Can be increased up to 256M. Generally should be more than UPLOAD_MAX_FILESIZE.
+
+
+
MAX_EXECUTION_TIME
+
PHP
+
120
+
120
+
Can only be decreased. Please break down the scripts if it is taking more than 120 seconds. Added to avoid bad scripts from slowing the system.
+
+
+
MAX_INPUT_TIME
+
PHP
+
120
+
120
+
Max time limit for parsing the input requests. Can only be decreased.
+
+
+
MAX_INPUT_VARS
+
PHP
+
10000
+
10000
+
-
+
+
+
DATABASE_HOST
+
Database
+
-
+
-
+
Database host used to connect to WordPress.
+
+
+
DATABASE_NAME
+
Database
+
-
+
-
+
Database name used to connect to WordPress.
+
+
+
DATABASE_USERNAME
+
Database
+
-
+
-
+
Database username used to connect to WordPress.
+
+
+
DATABASE_PASSWORD
+
Database
+
-
+
-
+
Database password used to connect to WordPress.
+
+
+
+
+
WordPress installation simple, just provide the desired admin email, username, and password and everything else is taken care of. The latest update also brings significant performance enhancements like integrated caching and image compression.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
We are happy to announce the public preview of the WordPress offering on App Service. This offering will enable you to deploy and host new WordPress websites...
We are happy to announce the public preview of the WordPress offering on App Service. This offering will enable you to deploy and host new WordPress websites...
+
+
+
+
+
+
+ 6 minute read
+
+
+
+ • By James Mulvey
+
+ • February 1, 2022
+
+
+
Azure App Service is regularly updated to provide new features, new runtime versions, performance improvements, and bug fixes. One of the top feature request...
Migrating your Windows container apps from the Premium Container SKU (Preview) to Premium V3 SKU
+
+
+
+
+
+
+
+
+ 2 minute read
+
+
+
+ • By Jeff Martinez
+
+ • March 2, 2022
+
+
+
+
+
+
+
+
+
The Premium Container SKU will not be moving out of preview status and will be retired on 30th June 2022. Please move your applications to the Premium V3 SKU ahead of this date if you want to continue running your Windows container workloads. The Premium V3 SKU is SLA-backed and supports Windows containers. In addition to general availabilty of support for Windows containers, Premium V3 provides enhanced performance for production applications, virtual network connectivity and new pricing options including Dev / Test, Pay-as-you-Go, 1-year and 3-year reserved instance pricing. See additional details here.
+
+
If you have an application that is using the Premium Container SKU (Preview) and you would like to move to the new Premium V3 SKU, you will need to copy and re-deploy your application to a Premium V3 App Service Plan. The following is an example on how to do this using the clone functionality via Azure CLI in PowerShell.
+
+
Tutorial
+
+
Prerequisites
+
+
This tutorial uses Az.Accounts and Az.Websites PowerShell modules. Follow the instructions here before starting to install the modules.
+
+
You will need your:
+
+
Subscription ID: “< subscription-id >”
+
Resource Group: “my-pc-resource-group”
+
Web App Name: “my-pc-web-app”
+
+
+
Prepare your environment
+
+
+
+
To get started you will first need to connect your Azure account
+
+
Connect-AzAccount
+
+
+
+
Then, set your subscription in PowerShell to the context of your Web App
+
+
Set-AzContext -Subscription"<subscription_id>"
+
+
+
+
+
Copy your Premium Container site
+
+
Next, copy the Premium Container site information into a PowerShell variable. You will use this variable when you clone the app
Create the new App Service Plan that your site will be cloned to. Be sure to use the ‘’–hyper-v’’ parameter so it will support your Windows container workload. Here you will also define your new resource group and app name.
+
+
az appservice plan create --resource-group"my-pv3-resource-group"--name"my-pv3-app-service-plan"--hyper-v--location"East US"--sku p1v3 --subscription
+<subscription-id>
+
+
Clone your Premium Container application to the new Premium V3 App Service Plan
+
+
Use the following PowerShell command to clone your existing Premium Container app to your Hyper-V enabled Premium V3 App Service Plan. Here you will use the $myPCApp variable defined earlier as your -SourceWebApp value.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 2 minute read
+
+
+
+ • By Jeff Martinez
+
+ • March 2, 2022
+
+
+
The Premium Container SKU will not be moving out of preview status and will be retired on 30th June 2022. Please move your applications to the Premium V3 SK...
App Service Web Apps, Functions, and Logic Apps (Standard) *.azurewebsites.net TLS certificate changes and what you need to know
+
+
+
+
+
+
+
+
+ 2 minute read
+
+
+
+ • By Yutang Lin
+
+ • March 22, 2022
+
+
+
+
+
+
+
+
+
This blog contains information about *.azurewebsites.net TLS certificate changes for web apps, functions, and logic apps (standard). Customers should not be impacted by this change. The scope of services affected includes web apps, functions, and logic apps (standard); logic apps (consumption) are not impacted. This change is limited to public Azure cloud; government clouds are not affected.
+
+
Every web app, function, or logic app (standard) has its own default hostname that goes by “<resource-name>.azurewebsites.net” where App Service secures it with a wildcard *.azurewebsites.net TLS certificate. The current TLS certificate issued by Baltimore CyberTrust Root CA is set to expire on July 7th, 2022. Starting April 2022, App Service will begin renewing these TLS certificates and instead use certificates issued by DigiCert Global Root G2 CA. Due to the distributed asynchronous nature of the renewal process, there isn’t an exact date when the certificate will be rotated and visible to individual web apps, functions, and logic apps (standard).
+
+
We expect that this change will be a non-event and will not impact customers. However, you may be impacted if an application has incorrectly taken a hard dependency on the *.azurewebsites.net TLS certificate, for example by way of “certificate pinning”. Certificate pinning is a practice where an application only allows a specific list of acceptable Certificate Authorities (CAs), public keys, thumbprints, etc. Applications should never pin to the *.azurewebsites.net TLS certificate. Applications requiring certificate stability should use custom domains in conjunction with custom TLS certificates for those domains. You can refer to the recommended best practices section of this article for more information.
+
+
Recommended best practices
+
+
Certificate pinning of *.azurewebsites.net TLS certificates is not recommended because the *.azurewebsites.net TLS certificate could be rotated anytime given the nature of App Service as a Platform as a Service (PaaS). In the event that the service rotates the App Service default wildcard TLS certificate, certificate pinned applications will break and disrupt the connectivity for applications that are hardcoded to a specific set of certificate attributes. The periodicity with which the *.azurewebsites.net TLS certificate is rotated is also not guaranteed since the rotation frequency can change at any time.
+
+
If an application needs to rely on certificate pinning behavior, it is recommended to add a custom domain to a web app, function, or logic app (standard) and provide a custom TLS certificate for the domain which can then be relied on for certificate pinning.
+
+
Note that applications which rely on certificate pinning should also not have a hard dependency on an App Service Managed Certificate. App Service Managed Certificates could be rotated anytime, leading to similar problems for applications that rely on stable certificate properties. It is best practice to provide a custom TLS certificate for applications that rely on certificate pinning.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 2 minute read
+
+
+
+ • By Yutang Lin
+
+ • March 22, 2022
+
+
+
This blog contains information about *.azurewebsites.net TLS certificate changes for web apps, functions, and logic apps (standard). Customers should not be ...
+
+
+
+
+
+
+ 2 minute read
+
+
+
+ • By Yutang Lin
+
+ • March 22, 2022
+
+
+
This blog contains information about *.azurewebsites.net TLS certificate changes for web apps, functions, and logic apps (standard). Customers should not be ...
+
+
+
+
+
+
+ 2 minute read
+
+
+
+ • By Jeff Martinez
+
+ • March 2, 2022
+
+
+
The Premium Container SKU will not be moving out of preview status and will be retired on 30th June 2022. Please move your applications to the Premium V3 SK...
Auto-healing is a heavily used diagnostic feature of Azure App Service that allows end-users to configure a rich set of triggers that can be used to mitigate an app once it starts misbehaving. It not only allows you to mitigate the app from a bad situation but it also allows customers to capture diagnostic data that helps them debug the issues later.
+
+
Crash Monitoring and Proactive Crash Monitoring allow end-users to effectively diagnose and debug application crashes (process exits due to unhandled exceptions) easily.
+
+
One of the most asked features for both these features was the ability to view historical information about when these tools were triggered and what conditions cause them to trigger. Customers have also asked us to be able to view this information for a longer duration as by default the views available in Diagnose and Solve blade show you a maximum of 24 hours of information.
+
+
Announcing Auto-healing and Crash Monitoring integration with Azure Monitor
+
+
We are happy to announce the integration of App Services Auto-Healing and Crash Monitoring feature with Azure Monitor. With this integration, you can identify when an app was recycled, the number of times it was recycled and due to what condition. You can also identify application code that leads to a crash for your app. Azure Monitor integration allows you to configure alerts and actions to be taken when any of these events are triggered. You can choose for how long you want this data to be retained and use Log Analytics to query this data and setup alerts as per your requirement.
+
+
Integrating Auto-Healing and Crash Monitoring with Azure Monitor
+
+
+
To integrate Azure Monitor with these diagnostic tools, navigate to Diagnostic Settings for your App in the Azure Portal and click on Add Diagnostic Setting.
+
Give a descriptive setting name and make sure AppServicePlatformLogs category is selected
+
Choose the destination per your choice. In the below example, I choosing to send the data to a Log Analytics workspace and I chose an existing Log Analytics workspace in my subscription.
+
+
+
+
+
And that’s it !!!
+
+
Viewing Auto-Healing events in Log Analytics
+
+
Whenever Auto-Healing takes action based on the configured triggers, the events can be viewed in AppServicePlatformLogs table in log analytics workspace. To view the data, just click on Logs for your App and run a query like below
+
+
AppServicePlatformLogs
+| where TimeGenerated > ago(1d)
+| where OperationName startswith "AutoHealing"
+| project TimeGenerated, OperationName, Level, Message, _ResourceId
+
+
+
+
+
+
+
The Message column helps identifying the action invoked and the trigger. For e.g. in the above event, we see this
+
+
+
Worker Process successfully launched custom action ‘D:\home\data\DaaS\bin\DaasConsole.exe’ due to ‘Total Requests’ limit
+
+
+
The OperationName column will have one of the three values based on the action chosen in the Auto-Healing configuration.
+
+
+
AutoHealingCustomAction
+
AutoHealingRecycle
+
AutoHealingLogEvent
+
+
+
Viewing Crash Monitoring events in Log Analytics
+
+
Whenever crash monitoring or proactive crash monitoring captures a memory dump or records a call-stack of the crashing thread, records will be generated in the AppServicePlatformLogs table in Log Analytics workspace. Information about the dump file and the time the dump file is copied to storage will also be logged. To view the data, just click on Logs for your App and use a query like below
+
+
AppServicePlatformLogs
+| where TimeGenerated > ago(1d)
+| where OperationName =~ 'CrashMonitoring' or OperationName =~ 'ProactiveCrashMonitoring'
+| project TimeGenerated, OperationName, ActivityId, Level, Message, Exception, StackTrace, _ResourceId
+
+
+
+
You may have to choose the ActivityId, Exception and StackTrace columns from the Columns side panel to see all the above information
+
+
+
+
+
+
+
Configuring alerts on these Events
+
+
To configure an alert, write the Log Analytics query as per your requirement and choose New Alert Rule from the ribbon and follow the rest of the configuration. For more information, refer to Create, view, and manage log alerts using Azure Monitor
+
+
We hope this helps in identifying auto-healing and crash monitoring invocations easily and set up alerts around these events which will help you effectively diagnose and troubleshoot your apps hosted on App Service.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Auto-healing is a heavily used diagnostic feature of Azure App Service that allows end-users to configure a rich set of triggers that can be used to mitigate...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Jason Freeberg
+
+ • April 11, 2022
+
+
+
We are happy to share that Auto-Instrumentation of Application Insights for Windows Container applications is now in public preview! Auto-Instrumentation all...
Public Preview: Codeless Monitoring for Windows Containers
+
+
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Jason Freeberg
+
+ • April 11, 2022
+
+
+
+
+
+
+
+
+
We are happy to share that Auto-Instrumentation of Application Insights for Windows Container applications is now in public preview! Auto-Instrumentation allows you to monitor your applications with Application Insights without changing your code. When enabled, the App Service platform will configure and attach the agent to the application in your container. Once attached, metrics such as requests, dependencies, latency, and stack traces will flow into your Application Insights resource where you can analyze the data and set up alerts.
+
+
Note: Auto-Instrumentation for Windows Containers on App Service currently supports .NET and Java applications. Node.js support is planned. For other stacks, consider adding the Application Insights SDK to your application.
+
+
Enable Auto-Instrumentation
+
+
You can enable Auto-Instrumentation from the Create blade, or from the Application Insights blade.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Generally available: Enhanced network security features for App Service Basic SKU
+
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Jordan Selig
+
+ • April 14, 2022
+
+
+
+
+
+
+
App Service now supports VNet integration (outbound) and private endpoints (inbound) all the way down to the Basic SKU. The App Service VNet integration feature enables your apps to access resources in or through a virtual network but doesn’t grant inbound private access to your apps. For inbound access, you need private endpoints, which allow clients located in your private network to securely access your apps over Private Link, which eliminates exposure from the public internet.
+
+
With this update, you can use our lower-cost tiers and achieve the same level of security that you could previously only achieve with our high-end SKUs. Note that if you want to downgrade an existing App Service Plan and still use VNet integration, you need to be on the newer App Service footprint to ensure you’re App Service Plan supports VNet integration for Basic SKU. For more details, see the VNet integration limitations.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Jordan Selig
+
+ • April 14, 2022
+
+
+
We are happy to announce that you can now enable Virtual Network integration as well as private endpoints for inbound access when creating Web Apps using the...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Jordan Selig
+
+ • April 14, 2022
+
+
+
App Service now supports VNet integration (outbound) and private endpoints (inbound) all the way down to the Basic SKU. The App Service VNet integration feat...
Public preview: Networking configuration options during Web App creation in the Azure Portal
+
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Jordan Selig
+
+ • April 14, 2022
+
+
+
+
+
+
+
We are happy to announce that you can now enable Virtual Network integration as well as private endpoints for inbound access when creating Web Apps using the Azure Portal. Previously, you had to use the Azure CLI/PowerShell or ARM to configure these features when creating your apps.
+
+
Web Apps can be provisioned with an inbound address that is public to the internet or isolated to an Azure virtual network. Web Apps can also be provisioned with outbound traffic that is able to reach endpoints in a virtual network, be governed by network security groups, or be restricted by virtual network routes. Use the new Networking tab to configure these features when creating your apps so you can ensure a secure configuration from the start!
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Jordan Selig
+
+ • April 14, 2022
+
+
+
We are happy to announce that you can now enable Virtual Network integration as well as private endpoints for inbound access when creating Web Apps using the...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Jordan Selig
+
+ • April 14, 2022
+
+
+
App Service now supports VNet integration (outbound) and private endpoints (inbound) all the way down to the Basic SKU. The App Service VNet integration feat...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Jason Freeberg
+
+ • April 11, 2022
+
+
+
We are happy to share that Auto-Instrumentation of Application Insights for Windows Container applications is now in public preview! Auto-Instrumentation all...
Auto-healing is a heavily used diagnostic feature of Azure App Service that allows end-users to configure a rich set of triggers that can be used to mitigate...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Jeff Martinez
+
+ • May 23, 2022
+
+
+
+
+
+
+
We are pleased to announce that gRPC is coming to Azure App Service for Linux workloads.
+
+
Using gRPC, you can utilize the remote procedure call framework to streamline messages between your client and server over HTTP/2. Using gRPC protocol over HTTP/2 enables the use of features like multiplexing to send multiple parallel requests over the same connection.
+
+
gRPC is currently available in EUAP with Private Preview for use with .NET Core 3.1 and .NET 6.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Scala is an object-oriented programming language that can be compiled to run on the Java Virtual Machine (JVM). Using the Java runtime allows you to integrate with the enormous Java ecosystem and execute Scala programs anywhere the JVM is available. This includes Azure App Service with the Java SE runtime. The Play Framework is a lightweight web application framework for Java and Scala that integrates all components and APIs needed for modern web application development.
+
+
Follow the tutorial below to deploy a Play framework Scala app onto Azure App Service.
+
+
Prerequisites
+
+
To follow the steps in this tutorial you will need the following tools installed locally. (You can use either the Azure CLI or the Maven plugin. You don’t need both to complete this tutorial.)
To check your sbt version, enter the following in a command window:
+
+
sbt sbtVersion
+
+
+
Build and Run the Project
+
+
This example Play project was created from a seed template. It includes all Play components and an Akka HTTP server. The project is also configured with filters for Cross-Site Request Forgery (CSRF) protection and security headers.
+
+
To build and run the project:
+
+
+
+
First clone the Scala on App Service repository with the following command: git clone https://github.com/Azure-Samples/scala-on-app-service
+
+
+
Change directory into the example project directory: cd scala-on-app-service
+
+
+
Build the project by running sbt run. The command builds and starts the embedded HTTP server. Since this downloads libraries and dependencies, the amount of time required depends partly on your internet connection speed.
+
+
+
After the message Server started, ... displays, enter the following URL in a browser: http://localhost:9000. The Play application will respond with: Welcome to the Hello World Scala POC Tutorial!.
+
+
+
+
Now that the application is working locally, let’s package the application into an executable .jar file that we can deploy onto Azure App Service.
+
+
Assemble and Test JAR Locally
+
+
Follow these steps to build a .jar file executable for a Java 11 runtime using sbt assembly.
+
+
+
+
From the project root, run:
+
+
sbt assembly
+
+
+
This command produces an executable .jar file in the scala-on-app-service/target/scala-2.14/ directory.
+
+
+
To test the app locally, run the previously created .jar file:
The application should now be running at http://localhost:80. (Note that the port is now 80, as this is the default HTTP port expected on App Service when we deploy it in the next section.)
+
+
+
Open the application in your browser to ensure it works locally as an executable .jar.
+
+
+
+
Something interesting to note about creating an executable .jar using sbt assembly is that it will inject all necessary Scala dependencies according to the assemblyMergeStrategy defined in build.sbt. This allows a native Scala app like this one to be executed in a Java-only environment. This also means that your production environment only needs to be running Java 11 and doesn’t need any Scala runtime dependencies since they’ve all been injected into the .jar file.
+
+
Deploy to Azure App Service
+
+
You can deploy the .jar using either the Azure CLI or the Maven plugin. Follow the instructions below for your preferred tool.
+
+
Deploy as JAR using Azure CLI
+
+
To deploy with the Azure CLI, run the following command from the project root:
+
+
az webapp deploy --type jar --src-path target/scala-2.13/<project-name>-assembly-<version>.jar --name <app-name> --resource-group <resource-group>
+
+
+
Once complete, you should be able to access your Play Framework app at https://<app-name>.azurewebsites.net
+
+
Deploy as JAR using Maven
+
+
+
+
To use Maven, you’ll need a pom file. The last line of scala-on-app-service/build.sbt handles maven repo creation for publishing. After assembling your .jar file with sbt assembly, run the following command from the project root to generate a pom file:
+
+
sbt publish
+
+
+
+
Copy the newly created pom file to the project root:
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Resiliency Score report is a downloadable report that checks whether your Azure Web App is implementing the best practices to make it less susceptible to availability issues.
+
+
The report doesn’t review your Web App’s code, instead it focuses on the recommended settings and the features available to make your App Service more resilient to failures.
+
+
Currently, it’s only available for Web App (Windows) running on Standard plans or higher. More products will be included in the future.
+
+
Accessing the report
+
+
You can access the report through the Diagnose and solve problems blade of your Azure App Service:
Click on any Web App (Windows) running in a Standard app service plan or higher
+
Click on Diagnose and solve problems
+
Click on any of the Troubleshooting categories. For these instructions we’ll use Availability and Performance
+
In Availability and Performance look for the command bar in the center and towards the top of the blade. Then, click on the button. This will generate the report and download it after a few seconds.
+
+
+
Report structure
+
+
The report is structured in 3 main sections:
+
+
Resiliency Score
+
+
The score is a number between 0 and 100, where less than 59, means the Web App is rated as poor and more than 80 is rated as excellent. Each feature has different weights, so each will have a different impact on your score.
+A score of 100% doesn’t mean that the Web App will never be down, but rather that it has implemented 100% of our resiliency best practices.
+
+
+
+
Contributing factors table
+
+
This is a general overview of all the features and how well they have been implemented. If the feature is implemented but there are improvements that can be done, it will be marked as “Partially implemented”.
+This table also works as a Table of contents of sorts, as it has links to jump to the details on each feature.
+
+
+
+
Detailed scores and instructions
+
+
This section intends to explain why this feature is important for you, the current state and provide details on how to implement it.
+Each feature is divided in the following 4 sections:
+
+
Description
+
+
This is an explanation of why this feature is necessary.
+
+
+
+
Status of verified Web Apps
+
+
This table includes the Grade (Fail, N/A (Not Applicable) or Pass) and Comments specific to the implementation of this feature.
+
+
+
+
Solution
+
+
In here you can find steps to implement the solution through the Azure Portal and when available, through PowerShell and/or Azure CLI.
+We include the steps even if the solution is implemented already, just in case you need them to implement it on other Web Apps.
+
+
+
+
More information
+
+
These are links to documents where you can find more details about this feature.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 5 minute read
+
+
+
+ • By Jordan Selig
+
+ • June 16, 2022
+
+
+
+
+
+
+
+
+
If you’re an Azure portal user with App Service, you’ve most likely seen the Security item in the left-hand menu. This item comes from our partners from the recently re-branded Microsoft Defender for Cloud. If you aren’t familiar with Microsoft Defender for Cloud (formerly Azure Security Center and Azure Defender), it’s a tool for security posture management and threat protection. It aggregates compliance data and continually assesses your environments to give you a summary view of your security posture and allow you to streamline security management not just for your resources in Azure, but also for your resources and environments on-premises as well as in other cloud platforms (Defender for Cloud currently supports integration with AWS and GCP). For more information about Microsoft Defender for Cloud, check out the documentation.
+
+
+
+
Microsoft Defender for App Service
+
+
Without enhanced security features (Free)
+
+
Microsoft Defender for Cloud is offered in two modes. Without enhanced security features (Free) is enabled for free on all your Azure subscriptions when you visit the workload protection dashboard in the Azure portal for the first time, or if enabled programmatically via API. The free version will not be enabled until you complete one of those actions. Using the free mode provides the secure score and its related features: security policy, continuous security assessment, and actionable security recommendations to help you protect your Azure resources. The below screenshot is a sample of what the free version gives you. As you can see on the left-hand side, there are a number of features that aren’t selectable since they aren’t available with the free version. However, even though they are not selectable from the TOC, you can access the Regulatory Compliance and Inventory blades by clicking on the respective widgets in the dashboard.
+
+
+
+
The free mode gives you access to your compliance status based on the Azure Security Benchmark. For example, the Azure Security Baseline states that sensitive data should be encrypted in transit. The below screenshot shows where this control, specifically for App Service, shows up in the Defender for Cloud compliance dashboard. The Azure Security Baseline includes standards for services other than App Service as well to give you full compliance status of your account. To track compliance with other standards, you’ll need to enable the enhanced security features.
+
+
+
+
From the compliance dashboard in Defender, you’ll see exactly which benchmarks your environment fails to meet. Selecting one of the controls will show you which resources are failing the compliance check as well as in many cases give you a “Quick Fix” to make your resources compliant.
+
+
Heading back to the Security blade for your App Service, after enabling Defender, and therefore the Azure Security Benchmark, under Recommendations, you’ll now see the App Service specific controls from the Azure Security Benchmark where your app fails to be compliant. If you don’t see any recommendations, your app is either fully compliant with the Azure Security Benchmark or you haven’t given the platform enough time to complete its assessment and update the portal (this can take up to 24 hours). You’ll additionally see a severity recommendation for each control based on the priority the Azure Security Benchmark, which gives you a good sense of which controls you should most likely enable. Note that if you have enabled any custom policies in Azure Policy based off of the controls associated with the Azure Security Benchmark, they won’t show up in the Recommendations or in the Defender compliance dashboard. At this time, only “built-in” policies are supported. Additionally, you won’t see any alerts under “Security incidents and alerts” in the Security blade since that is a not a feature of the free version.
+
+
+
+
With enhanced security features
+
+
Defender for Cloud with all enhanced security features extends the capabilities of the free mode and allows you to include workloads running in private and other public clouds, providing unified security management and threat protection across your hybrid cloud workloads. For more information on the two modes, see the enhanced security features documentation.
+
+
If you choose to use the enhanced security features, Defender for Cloud offers specific plans dedicated to various Azure services including one for App Service called Microsoft Defender for App Service. In addition to the benefits you get from the enhanced security features, enabling Defender for App Service increases your security posture by assessing the resources covered by your App Service plan and generating security recommendations based on its findings. It also monitors the underlying logs and infrastructure that customers don’t typically have access to since App Service is a fully managed platform. To learn more about the benefits of Defender for App Service, see protecting your web apps and APIs.
+
+
Things to consider
+
+
If the built-in policies that make up the Azure Security Benchmark and other compliance standards don’t meet your compliance standards, you can create custom policies in Azure Policy. Custom policies however will not show up under the recommendations in the Security blade and in your Defender compliance dashboard.
+
+
You must visit the Microsoft Defender for Cloud dashboard in the portal or enable Defender programmatically via API for it to start monitoring your resources. Even if you are just using the free version, you still need complete one of those actions to see your recommendations in the Security blade.
+
+
Defender for App Service costs $15/month per instance. If cost is a limiting factor for you, take this into consideration when enabling the enhanced security features. Defender gives you the ability to select which resources you want to be in scope and therefore charged for, which can help you reduce costs as needed. If you don’t enable Defender for App Service, you can still use the free version and have access to compliance against the Azure Security Benchmark.
+
+
If you choose to not enable the enhanced security features, that doesn’t mean your App Service isn’t secure or that you don’t have options to secure your apps. App Service as well as Azure have a number of built-in features and services that you can leverage to lock down and protect your apps based on your requirements. To learn more about App Service security, start with the security recommendations for App Service.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 5 minute read
+
+
+
+ • By Jordan Selig
+
+ • June 16, 2022
+
+
+
If you’re an Azure portal user with App Service, you’ve most likely seen the Security item in the left-hand menu. This item comes from our partners from the ...
Resiliency Score report is a downloadable report that checks whether your Azure Web App is implementing the best practices to make it less susceptible to ava...
+
+
+
+
+
+
+ 5 minute read
+
+
+
+ • By Jordan Selig
+
+ • June 16, 2022
+
+
+
If you’re an Azure portal user with App Service, you’ve most likely seen the Security item in the left-hand menu. This item comes from our partners from the ...
Resiliency Score report is a downloadable report that checks whether your Azure Web App is implementing the best practices to make it less susceptible to ava...
+
+
+
+
+
+
+ 2 minute read
+
+
+
+ • By Jordan Selig
+
+ • July 6, 2022
+
+
+
+
+
+
+
+
+
Regulatory Compliance in Azure Policy provides Microsoft created and managed initiative definitions, known as built-ins, for the compliance domains and security controls related to different compliance standards. A subset of those initiatives contains compliance domains and security controls specifically for Azure App Service. You can assign the built-in initiatives to verify your compliance status against common standards or you can assign the built-ins for a control individually to help make your Azure resources compliant with a specific standard. To see the built-in policies for App Service, see Azure Policy Regulatory Compliance controls for Azure App Service. To learn more about applying and managing policies, see Tutorial: Create and manage policies to enforce compliance.
+
+
Latest updates
+
+
The App Service team recently underwent an effort to clean-up the App Service built-in policies. This effort included the following updates:
+
+
+
Deprecation of policies that no longer require dedicated policy definitions to simplify overall management of policy inventory.
+
Rename of policies to follow a standard naming convention. The naming convention is as follows:
+
+
Lead with the affected service, resource type, or feature.
+
Include “should” to explain the unsecured element (“[A] should [B]”).
+
For example, a policy name that follows the naming convention would be “App Service apps should only be accessible over HTTPS”.
+
+
+
Removal of Logic Apps from the scope of all App Service policy definitions.
+
+
Logic Apps have their own dedicated policies.
+
+
+
Re-scope of policies to clearly distinguish Function app policies from App Service policies.
+
+
All Function app policies now include the condition {"field": "kind", "contains": "functionapp"}.
+
All App Service policies now include the condition {"field": "kind", "notContains": "functionapp"} which scopes them to include all app types except Function apps and Logic Apps.
Addition of App Service slots in policy’s scope where applicable.
+
+
+
For the full list of detailed updates, see the release notes.
+
+
Action needed
+
+
There’s no action required if you already have the updated policies assigned to your resources. The policies updates will automatically be applied. Be sure to review your new overall compliance status as the scope of some of the policies has been modified, which means additional resources may now be in scope for policy evaluation.
+
+
Deprecated policies will no longer show up in the definitions list in the Azure portal. They’ll still be available via APIs. They’ll also still be evaluated if individually assigned. You won’t receive a notification that these policies have been deprecated however you’ll see that their display names have changed to be prefixed with “[Deprecated]”. If you no longer want these policies to be evaluated, you can unassign them. If you’ve assigned any of the initiatives which include these policies, they’ll automatically be removed from the initiative and will no longer be evaluated.
+
+
If you use the specific policy display names in any reporting, upstream metrics, or alerting mechanisms, you’ll need to update these values to the latest versions. Policy display name changes can be found in the release notes.
+
+
What’s next?
+
+
The clean-up effort is ongoing. The release notes will continue to be updated as changes are rolled out.
+
+
We are continuously assessing the App Service policy inventory to ensure our built-in list includes policies that meet the latest security best practices and recommendations. We’ll also continue to add new policies to keep up with the latest App Service features.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 2 minute read
+
+
+
+ • By Jordan Selig
+
+ • July 6, 2022
+
+
+
Regulatory Compliance in Azure Policy provides Microsoft created and managed initiative definitions, known as built-ins, for the compliance domains and secur...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Byron Tardif
+
+ • July 18, 2022
+
+
+
+
+
+
+
We are happy to announce that App Service now supports apps targeting .NET 7 Preview 5 across all public regions on both Windows and Linux App Service Plans through the App Service Early Access feature.
+
+
Azure Functions has also added initial support for .NET 7 Preview 5.
+
+
Any app targeting the .NET 7 on App Service during the preview stages will be automatically updated to the latest .NET 7 Preview release as newer releases become available. This update process will continue all the way up to the RC and GA releases.
+
+
Self-contained .NET apps will not be auto-updated since they have no dependency on the runtime provided by App Service.
+
+
Want to get started with .NET 7? Follow these guides:
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Byron Tardif
+
+ • July 18, 2022
+
+
+
We are happy to announce that App Service now supports apps targeting .NET 7 Preview 5 across all public regions on both Windows and Linux App Service Plans ...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Byron Tardif
+
+ • July 18, 2022
+
+
+
We are happy to announce that App Service now supports apps targeting .NET 7 Preview 5 across all public regions on both Windows and Linux App Service Plans ...
+
+
+
+
+
+
+ 2 minute read
+
+
+
+ • By Jordan Selig
+
+ • July 6, 2022
+
+
+
Regulatory Compliance in Azure Policy provides Microsoft created and managed initiative definitions, known as built-ins, for the compliance domains and secur...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Abhishek Reddy
+
+ • August 8, 2022
+
+
+
+
+
+
+
We are thrilled to announce that WordPress on App Service that was under public preview since February 15, 2022, is now generally available. With advanced features and revised hosting plans, you can now deploy and manage WordPress websites with ease. We have continued to make improvements in performance and security so that you can deliver a great experience to your customers.
+
+
We recommend that you use Linux for your WordPress server. PHP on Windows will not be officially supported on App Service Platform after November 25, 2022.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Abhishek Reddy
+
+ • August 8, 2022
+
+
+
We are thrilled to announce that WordPress on App Service that was under public preview since February 15, 2022, is now generally available. With advanced fe...
gRPC support on App Service now in Public Preview
+
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Jeff Martinez
+
+ • August 11, 2022
+
+
+
+
+
+
+
We are pleased to announce that gRPC (public preview) is now available in most regions. gRPC is supported for Linux applications using .NET Core 3.1 or .NET 6. Node support is coming soon (9/1/22).
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Jeff Martinez
+
+ • August 11, 2022
+
+
+
We are pleased to announce that gRPC (public preview) is now available in most regions. gRPC is supported for Linux applications using .NET Core 3.1 or .NET...
A Heavy Lift: Bringing Kestrel + YARP to Azure App Services
+
+
+
+
+
+
+
+
+ 8 minute read
+
+
+
+ • By David Fowler, Suwat Bodin, Chris Rosenblatt, Jenny Lawrance, Stephen Kou, Chris Ross, Miha Zupan, Aditya Mandaleeka, Bilal Alam
+
+ • August 16, 2022
+
+
+
+
+
+
+
In this post, we get a behind-the-scenes look at the engineering work required to change a critical platform component with code paths that are exercised billions of times a day while minimizing service disruptions and maintaining SLA for our customers. We provide a brief introduction to help cover the basics, go over motivations for doing this work, explain some of the more interesting challenges, issues, and bugs encountered along the way, and close with the results and the new customers scenarios enabled.
+
+
The challenge was huge, but we’re excited about the benefits this brings to Azure App Services and our customers:
+
+
+
Almost 80% improvement in throughput in performance tests designed to isolate the benefits.
+
Greener Azure data centers from significantly decreased per-request CPU usage.
+
Support for modern protocols like HTTP/3.
+
Support for new customer scenarios such as gRPC applications, per-host cipher suite configuration, custom error pages, and more.
+
+
+
Introduction
+
+
In 2021, a group of engineers across multiple teams, including .NET and Azure, got together to transition the App Service Frontend fleet to Kestrel + YARP. As we celebrate the completion of this major lift and collaboration, we decided to write down the journey and describe some of the challenges of completing such a change to a live service, the wins we achieved, and the future work enabled by this transition. We hope you enjoy it.
+
+
Azure App Service in a nutshell
+
+
Azure App Service recently celebrated its 10 year anniversary (we launched it on June 7th, 2012). We are grateful and humbled by our customers who have helped us grow into a big service (affectionately called an XXL service in Azure internally, a designation only shared with 3 other services). Here are some numbers that provide a glimpse into our scale:
+
+
+
160B+ daily HTTP requests served by applications
+
14M+ host names
+
1.5K+ multi-tenant scale units and an additional 10K+ dedicated scale units (App Service Environments aka App Service Isolated SKU)
+
+
+
One of the key architectural pieces of this system is our FrontEndRole. The FrontEndRole main purposes are:
+
+
+
Receiving traffic on HTTP/HTTPS from public virtual IP addresses associated with a scale unit
+
Terminating SSL if required
+
Determining which set of VMs are the origin-servers for the application (called Workers) and then routing to them
+
+
+
+
+
App Service was originally built as a Cloud Service and this role is just called FrontEndRole. With our transition to VM Scale Sets, the FrontEndRole is a separate scale set which is part of each scale unit.
+
+
The original App Service FrontEndRole, which runs on Windows Server, consisted of:
+
+
+
IIS running on HTTP.sys, both operating system components of Windows Server
The first release of .NET Core introduced the Kestrel webserver: an open-source, cross-platform, and fast webserver implementation built using modern .NET. Performance is a key focus for the .NET team, and with each .NET release, Kestrel has gotten ever faster and more full-featured. As an example, recent changes made to Kestrel include:
+
+
+
Significant scalability improvements on many-core machines
+
Significant HTTP/2 performance enhancements when running with many concurrent streams
+
Support for new standards like HTTP/3
+
+
+
YARP (“Yet Another Reverse Proxy”) is a reverse proxy toolkit that enables building fast proxy servers using infrastructure from ASP.NET and .NET, focusing on easy customization. It is developed in the open at https://github.com/microsoft/reverse-proxy. YARP’s toolkit/extensibility model made it easy for us to incorporate our routing and TLS handling with its request forwarding capabilities. YARP includes support for modern protocols like HTTP/2 & HTTP/3, which App Service customers can now expose.
+In addition, being based on the fast-evolving .NET platform means that every release, Kestrel and YARP benefit from improvements up and down the .NET stack, including everything from networking libraries all the way down to JIT compiler improvements that improve the quality of generated code. For a sampling of the types of improvements that went into just the .NET 6 release in 2021, see Performance Improvements in .NET 6.
+
+
Betting on Kestrel + YARP for App Service: Why?
+
+
The previous FrontEndRole architecture of App Service built on IIS/HTTP.SYS has served us well, but the promise of a modern HTTP stack in Kestrel + YARP could deliver new benefits to all App Service customers. Specifically:
+
+
+
Performance improvements, including significantly decreased per-request CPU cost and per-connection memory cost.
+
More flexible extensibility points into SSL termination path, allowing for easier dynamic SNI host selection.
+
Enable new customer scenarios like support for gRPC, per-host cipher suite configuration, custom error pages, and more.
+
+
+
With all that context and motivation, the goal of the V-Team was clear:
+
+
“Transition the 200K+ dedicated cores running FrontEndRole to use Kestrel + YARP (and thus move away from IIS/HTTP.SYS/ARR)”
+
+
+
Challenge: Server Framework Diversity
+
+
App Service is not the first Microsoft service to transition to Kestrel and YARP. Microsoft has already documented the journeys of Bing, Azure Active Directory (AAD), and Dynamics 365 to .NET; these efforts have proven out the stability and performance of .NET for critical service workloads.
The unique challenge that App Service adds to the mix is the diversity of server implementations. The previously mentioned Microsoft services are written by server engineers working for … Microsoft. This is definitely not the case for App Service, which enables customers to bring their own server frameworks and write their own applications with varying levels of standards compliance. Hosting customer applications brings a unique set of challenges described below.
+
+
Challenge: Platform versus Organic Health
+
+
Because App Service enables customers to write their own applications, the concept of “service health” is a nuanced discussion. App Service measures the health of the platform; we ensure that customers have a running VM which can connect to storage and can execute a simple canary request. But App Service cannot easily measure the organic health (HTTP request success rate) since we do not control the application. As a result, we primarily focused on platform health as our main metric.
+
+
For our transition to Kestrel + YARP, we needed to broaden our measurement to include organic health. Rather than looking for an absolute bar (say >99.99% success), we needed to compare “before Kestrel + YARP” and “after Kestrel + YARP” organic success and look for anomalies that would point out potential problems.
+
+
Challenge: Quick Rollback in Production
+
+
With a broadened approach to assessing organic health anomalies caused by a diverse set of applications/frameworks on our platform, we required fast mechanisms to undo our Kestrel + YARP transition on a per scale-unit basis; in other words, we needed to be able to “break glass” quickly when we encountered problems and return to using IIS/HTTP.SYS.
+
+
The Journey: 100% FrontEndRoles using Kestrel/YARP
+
+
With all the context and challenges described, here is how the journey looked like in a picture.
+
+
+
+
As you can see this journey took a lot of time. 6 months passed between the first Kestrel/YARP deployment and 100%.
+
+
The Bugs Encountered
+
+
We encountered multiple bugs on our journey to Kestrel + YARP. Apart from bugs in our business logic, one of the interesting classes of issue we encountered was the treatment of edge-cases in the HTTP specification. A diversity of clients hit our FrontEndRole. We need to be generous in accepting behavior that may not be exactly the HTTP spec’s letter and intent.
+
+
A simple example of one of these cases is when a request has leading newline characters (CR and/or LF). Strictly speaking, this isn’t allowed, but it turns out that there are some clients that send requests that start like:
+
+
\rGET / HTTP/1.1\r\n
+...
+
+
+
This is a case that IIS (and some other servers) allow, but because Kestrel historically has taken a fairly strict stance, we saw its parser rejecting requests like this with a BadHttpRequestException. Working closely with the ASP.NET Core team, we were able to make Kestrel a bit more generous in what it accepts (the example above now works in Kestrel in .NET 6.0.5 and newer releases).
+
+
Some other interesting issues uncovered can be found here, here and here.
+
+
As a result of investigating and addressing this class of issues, we’ve made Kestrel a more capable server without compromising the core principle of security.
+
+
The Payoff: Performance and New Features, Now and in the Future
+
+
Now that we have moved our FrontEndRoles to Kestrel + YARP we have realized multiple benefits in production.
+
+
Performance tests designed to isolate the benefits of our FrontEndRole change showed an almost 80% improvement in throughput (tested using a simple 1K helloworld response from a single dedicated worker in a test environment). App Service over-provisions FrontEndRole instances, so the realized benefit across our aggregate fleet is a large decrease in CPU% which provides more CPU headroom for the fleet. We are still in the early days of monitoring the fleet post-move; we may eventually be able to decrease our cores assigned to this role to reduce operating costs and data center energy usage. More investigation to follow.
+
+
With our move to Kestrel + YARP on our FrontEndRoles, we were also able to move our Linux worker VMs to use Kestrel+YARP. This change allows us to replace nginx, commonize the codebase, and light up gRPC for our App Service Linux SKUs. gRPC support has been a popular feature request from Azure App Services users and we’re excited to add this capability.
+
+
With this platform work complete we are now working on enabling two of the most frequently requested features in App Service; more news coming soon as we complete these improvements:
+
+
Ability to configure custom error pages for requests that terminate on the front end (Specifically: HTTP 503, HTTP 502 and HTTP 403).
+
Ability to specify TLS cipher suite allowed per given application. Today customers can only configure allowed cipher suites on our Isolated SKUs.
+
+
+
A Great Partnership
+
+
Once you have a live multi-tenant service running with millions of VMs globally, you learn to be very careful with how and when you advance it. That said, the innovations with Kestrel + YARP being developed by the .NET core team were just too valuable to pass up. At the same time, the .NET team would tell you the experience of supporting this migration was a whole new challenge for that team as they experienced the breadth and diversity of App Service scenarios. This was a great journey for both teams and we landed it. Now that we have this new platform in place, we look forward to continued innovation between our teams.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 8 minute read
+
+
+
+ • By David Fowler, Suwat Bodin, Chris Rosenblatt, Jenny Lawrance, Stephen Kou, Chris Ross, Miha Zupan, Aditya Mandaleeka, Bilal Alam
+
+ • August 16, 2022
+
+
+
In this post, we get a behind-the-scenes look at the engineering work required to change a critical platform component with code paths that are exercised bil...
+
+
+
+
+
+
+ 4 minute read
+
+
+
+ • By Hugo Girard
+
+ • August 18, 2022
+
+
+
+
+
+
+
+
+
When deploying App Service Environment, one requirement you will probably want is to monitor and limit your egress traffic from the ASE.
+
+
This blog post walks you through how to achieve this using Azure Firewall, this assumes you have a hub and spoke network topology in place in Azure with more than one landing zone.
+
+
A full implementation example is available in Github. This GitHub repository will create all the resources discussed in this article.
+
+
This article focus on the configuration of the Azure Firewall and won’t go into the step to create all the Azure resources, those are described in the provided Github repository.
+
+
What the architecture look like
+
+
+
+
In the provided implementation you have in place one hub and two spokes deployed in your Azure subscription. All ingress will come into Application Gateway that is deployed with a Web Application Firewall. All egress traffic will be routed to the Azure Firewall. Keep in mind, by default Azure Firewall blocks all traffic, this give you the possibility to be really granular with which flow you want to allow.
+
+
In this scenario, you have two APIs, the Weather API and the Fibonacci API. The Weather API return fake data, this means it doesn’t communicate to the outside world and doesn’t need to egress to the Azure Firewall even if a User-Defined route is present.
+
+
The Fibonnacci API receive a Len in parameters and calculates a Fibonnacci sequence. Before doing the calculation, the API tries to retrieve the result in Azure Redis Cache - if the result is not found the sequence is calculated, saved in the Redis Cache, and returned to the caller.
+
+
The cache reside in another spoke from the ASE, this means the traffic will be routed to the Azure Firewall and filtered at this level. You will need to allow the traffic coming from the ASE to reach the subnet where the Redis Cache resides.
+
+
User Defined Route on ASE Subnet
+
+
To route all the egress traffic from the ASE to the Azure Firewall, a User Defined route was created. The route is associated to the subnet of the ASE.
+
+
+
+
By default, we redirect all traffic to the Azure Firewall private IP address.
+
+
+
+
Testing the Weather API
+
+
As mentioned before, the Weather API doesn’t communicate to any other Azure resources or the Internet. It receives an HTTP request and sends fake weather data.
+
+
Even with the route in place, calling the Weather API will work without any problems.
+
+
+
+
We receive a status code 200 and some fake weather data as expected.
+
+
Testing the Fibonacci API
+
+
Let’s take a look of the JSON schema of the result returned from the Fibonacci API.
+
+
+
+
You have a property called valueFromCache indicating if the value is retrieved from Redis Cache. The first time you call the API the value will be FALSE. If you call the API again with the same parameter the next time, the value should be TRUE if the saved value is not expired.
+
+
Right now, the value will always be false because the egress traffic to reach the Azure Redis Cache is blocked at the Azure Firewall level.
+
+
Here, call the API with the value of 5 for the len parameter.
+
+
+
+
You can see the property valueFromCache return the value FALSE like expected. Now let’s try it again and the result should be the same because the traffic is blocked at the firewall level. In this case the API will always work but won’t ever be able to communicate with the cache.
+
+
+
+
Adding network rule in Azure Firewall
+
+
Now, before adding the network rule in Azure Firewall let’s take a look at the log. To consult the log go to your Azure Log Analytics associated with your firewall. Execute the following Kusto query in log analytics.
+
+
AzureDiagnostics
+| where ResourceGroup == 'RG-HUB-ASE-DEMO'
+| where Category == 'AzureFirewallNetworkRule'
+| order by TimeGenerated desc
+
+
This should return the cause why the ASE was not able to communicate with the Azure Redis Cache.
+
+
+
+
As you can see, the TCP request from 10.1.1.254 to 11.0.1.4 was denied.
+
+
The 10.1.1.254 IP corresponds to the IP address of the Fibonacci Web App, you can see here the CIDR of the subnet allocated for the App Service Environment.
+
+
+
+
The 11.0.1.4 IP corresponds to the private endpoint used for the Azure Redis Cache.
+
+
Now, you need to create a Network Rule in the Azure firewall to allow the communication between the ASE subnet and the private endpoint of the Azure Redis Cache.
+
+
+
+
Try the Fibonacci API again
+
+
Now, you should restart the Fibonacci API, if the connection to Redis cache is not possible the Fibonacci won’t try again.
+
+
The first time you try with a len of 5 you will have the property valueFromCache with a value of FALSE.
+
+
Now try again with the same parameter, this time you will see the result will come faster and the valueFromCache property will be TRUE.
+
+
+
+
Conclusion
+
+
As you can see, adding Azure Firewall in Azure App Service Environment is really easy with version 3. You can control all egress going out from your ASE with the good old hub and spoke pattern.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Clojure is a dynamic, general-purpose programming language from the Lisp family that runs on the Java Virtual Machine. You can build web apps in Clojure and deploy them to Azure App Service as a JAR file.
+
+
This article uses an example web app written in Clojure based on the guestbook app from the Luminus framework, updated to use PostgreSQL and ready to deploy to Azure App Service in a few simple steps.
+
+
The guestbook application
+
+
The example application is a simple guestbook app where visitors can write messages about a site they visited. The data is stored and read from a PostgreSQL database on Azure which is created by a helper script.
+
+
+
+
Prerequisites
+
+
+
Java 8 or Java 11 (Java 11 is used as the default in this project)
Docker, used to run PostgreSQL locally in a Docker container
+
GNU sed, used for text replacement on the command line before deploying (you can edit the file in a text/code editor though). Note that sed comes pre-installed by default in most Linux distributions, and also in Git for Windows
+
+
+
Differences with the original guestbook application
The start-app function from core.clj file has been updated to run the database migrations on the application startup, as explained in the deployment documentation.
+
+
+
The migration file has been renamed to reflect that the file creates the guestbook table, instead of an users table.
+
+
+
The table definition (DDL) uses the PostgreSQL syntax instead of the original (H2). There are some minor differences on the definition of primary keys and timestamps, but this is expected.
+
+
+
+
Clone the repo
+
+
+
+
Clone the Clojure on App Service repository with: git clone https://github.com/Azure-Samples/clojure-on-app-service.git
+
+
+
Change directory with: cd clojure-on-app-service
+
+
+
+
Build and run the application locally
+
+
If you want to test this application locally before deploying to App Service, follow the steps on this section, otherwise you can skip to the Deployment on Azure section.
+
+
Run a PostgreSQL database for development
+
+
you can also run a PostgreSQL instance with Docker:
+
+
docker run --name postgres -ePOSTGRES_PASSWORD=pgpassword -d-p 5432:5432 postgres
+
+
+
Then connect to it from another container on the same network:
You can create a database just for the guestbook application and grant all permissions to a new user specific for the guestbook application.
+
+
postgres=# create database guestbook;
+postgres=# create user guestbookuser with encrypted password 'guestbookpass';
+postgres=# grant all privileges on database guestbook to guestbookuser;
+postgres=# \q
+
+
+
In order to tell our application where to access our database, you need to use the DATABASE_URL environment variable. In
+our example from the previous section, we started a container running PostgreSQL, so you’ll set the environment variable
+like this:
Now, let’s make sure the database’s tables are using the most recent definition by running the following command:
+
+
lein run migrate
+
+
+
This will apply any changes to the database definition that could be pending, such as creating or modifying tables.
+
+
You can use the psql utility to confirm the tables were created:
+
+
docker run -it --rm --network host postgres psql -h localhost -d guestbook -U guestbookuser
+Password for user guestbookuser:
+psql (14.5 (Debian 14.5-1.pgdg110+1))
+Type "help" for help.
+
+guestbook=> select * from guestbook;
+ id | name | message | timestamp
+----+------+---------+-----------
+(0 rows)
+
+guestbook=> select * from schema_migrations;
+ id | applied | description
+----------------+-------------------------+---------------------
+ 20190317085139 | 2022-08-24 16:28:02.528 | add-guestbook-table
+(1 row)
+
+guestbook=> \q
+
+
+
Launching the application
+
+
In order to run the application locally, you’ll need to provide some configuration for your dev environment. Since each developer
+could have a different setup, this file is generally not checked-in with the rest of the source code. Copy the contents below
+and save them in a file called dev-config.edn on the root of the project:
+
+
{
+ :devtrue
+ :port3000
+}
+
+
+
Finally, you can run the application locally with:
+
+
lein run
+
+
+
The server will start and after a while you should be able to access the application on http://localhost:3000/ and see
+guestbook form. If you need to use another port, you can use the PORT environment variable or pass it as a parameter
+in the command line as shown below:
+
+
lein run -p 8000
+
+
+
This is just the beginning. Clojure leans towards an interactive development style, so it’s enjoyed best when using
+a live REPL console attached to the project. To learn more about it, see REPL Driven Development in the Luminus framework docs.
+
+
Deployment on Azure
+
+
Creating cloud resources
+
+
This step needs to be run only once to create the required resources in Azure.
+
+
If you haven’t logged in before, login into your Azure account with az login and follow the prompts.
+
+
The example application has a script, create-resources.sh. The beginning of the file contains a configuration section where you can adjust some parameters such as the deployment region, and the database username and password. Set enviornment variables for the keys in the script to your desired values, or edit the script.
+
+
The script will create the following resources for you:
+
+
+
A resource group which will contain every other resource for this application
+
A server to run a PostgreSQL instance
+
A database in the PostgreSQL host
+
A configuration entry to allow connections from services hosted in Azure to the database server
+
An App Service Plan that can deploy Linux hosts
+
A definition for the guestbook web application
+
A configuration entry with the JDBC URL to connect from the guestbook web app to the database
+
+
+
Run the script from Bash:
+
+
./create-resources.sh
+
+
+
Once all the resources are created correctly, it should print All Azure resources created in the console.
+
+
Configure the deployment
+
+
Generate a Maven pom.xml file by running lein pom:
+
+
$ lein pom
+Wrote .../guestbook/pom.xml
+
+
+
Run the following command line to use a Maven plugin which will detect and configure most of the parameters required for deployment:
The command above will prompt you to create a new Web App or to use an existing one. Choose the option to use the existing Web App that you created using the script in the previous step:
+
+
$ mvn com.microsoft.azure:azure-webapp-maven-plugin:2.5.0:config
+[INFO] Scanning for projects...
+...
+[INFO] Auth Type : AZURE_CLI, Auth Files : [/home/user/.azure/azureProfile.json, /home/user/.azure/accessTokens.json]
+...
+[INFO] It may take a few minutes to load all Java Web Apps, please be patient.
+Java SE Web Apps in subscription My Subscription:
+* 1: <create>
+ 2: guestbook-2048 (linux, java 11-java11)
+Please choose a Java SE Web App [<create>]: 2 <== CHOOSE TO USE EXISTING APP
+Please confirm webapp properties
+Subscription Id : (...redacted...)
+AppName : guestbook-2048
+ResourceGroup : guestbook-2048-rg
+Region : westus2
+PricingTier : Free_F1
+OS : Linux
+Java : Java 11
+Web server stack: Java SE
+Deploy to slot : false
+Confirm (Y/N)[Y]: Y <== CONFIRM THAT YOU WANT TO USE THE CURRENT SETTINGS
+[INFO] Saving configuration to pom.
+[INFO] ------------------------------------------------------------------------
+[INFO] BUILD SUCCESS
+[INFO] ------------------------------------------------------------------------
+[INFO] Total time: 19.405 s
+[INFO] Finished at: 2022-08-24T14:18:36-08:00
+[INFO] ------------------------------------------------------------------------
+
+
+
Update the POM file
+
+
The file pom.xml generated by the azure-webapp-maven-plugin needs a minor tweak for deploying an Uberjar package.
+
+
You will need to edit the file pom.xml and replace the values in the following section:
After a few seconds, it will show the deployment status and the URL of the application
+
+
$ mvn azure-webapp:deploy
+[INFO] Scanning for projects...
+[INFO]
+[INFO] ------------------------< guestbook:guestbook >-------------------------
+[INFO] Building guestbook 0.1.0-SNAPSHOT
+[INFO] --------------------------------[ jar ]---------------------------------
+[INFO]
+[INFO] --- azure-webapp-maven-plugin:2.5.0:deploy (default-cli) @ guestbook ---
+...
+[INFO] Trying to deploy artifact to guestbook-2048...
+[INFO] Deploying (/.../guestbook/target/uberjar/guestbook.jar)[jar] ...
+[INFO] Successfully deployed the artifact to https://guestbook-2048.azurewebsites.net
+[INFO] ------------------------------------------------------------------------
+[INFO] BUILD SUCCESS
+[INFO] ------------------------------------------------------------------------
+[INFO] Total time: 27.655 s
+[INFO] Finished at: 2022-08-24T23:49:22-07:00
+[INFO] ------------------------------------------------------------------------
+
+
+
Give it a minute for the application to deploy and warm up. The first time you visit the application you may see an error 500 if the database migrations have not completed, but after refreshing the page it will work fine.
+
+
If you want to delete the application and all the related resources, go to your Resource Groups in the Azure Portal, then select the appropriate guestbook resource group and delete it.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 8 minute read
+
+
+
+ • By David Fowler, Suwat Bodin, Chris Rosenblatt, Jenny Lawrance, Stephen Kou, Chris Ross, Miha Zupan, Aditya Mandaleeka, Bilal Alam
+
+ • August 16, 2022
+
+
+
In this post, we get a behind-the-scenes look at the engineering work required to change a critical platform component with code paths that are exercised bil...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Jeff Martinez
+
+ • August 11, 2022
+
+
+
We are pleased to announce that gRPC (public preview) is now available in most regions. gRPC is supported for Linux applications using .NET Core 3.1 or .NET...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Abhishek Reddy
+
+ • August 8, 2022
+
+
+
We are thrilled to announce that WordPress on App Service that was under public preview since February 15, 2022, is now generally available. With advanced fe...
This is part 1 of a 2-part series about automation for planned maintenance in App Service Environment v3. In this 2-part series, I will walk you through building a demo environment, setting up manual upgrade preference option for App Service Environment and configure automation using Logic App. In the first scenario you will deploy a simple environment, in the second scenario the environment will be more complex.
+
+
The first article uses one Azure App Service Environment, which will be configured with the manual upgrade preference option. When an update is ready, an alert will be triggered that will start your Logic App. The Logic App will send you an email asking you to confirm the upgrade process.
+
+
The second article uses two Azure App Service Environments in two different regions. The first App Service Environment will be for the production workload, and the second for disaster recovery purposes. The Web App will be published using Azure Front Door Standard service. When an update is ready, an alert will be triggered that will start your Logic App. The Logic App will send you an email asking you to confirm traffic redirection from the primary region to the disaster recovery region, when you accept this workflow, Logic App will redirect the traffic and start the upgrade process of your production Azure App Service Environment. Using this approach you can avoid cold start of the applications. Usually the upgrade process should be invisible for your application but if you have an application that needs more time to start or you want to decide when the upgrade should start then this approach will be perfect for you.
+
+
+
Remember Now you can change Upgrade preference option to Manual and decide for yourself when you want to upgrade App Service Environment v3. After an update is available, you’ll have 15 days to start the upgrade process. If you don’t start the upgrade within the 15 days, the upgrade will be processed with the remaining automatic upgrades in the region. You can find more information about upgrade preference for App Service Environments v3 on this site upgrade preference for App Service Environments
+
+
+
Requirements:
+
+
+
Access to Azure Subscription
+
Access to Office 365 account
+
+
+
First scenario is organized into four steps:
+
+
+
Deploy App Service Environment using Azure CLI
+
Deploy sample app using Azure CLI
+
Deploy Logic App using ARM template
+
Create Alert in Monitor
+
+
+
Decide where you will execute commands
+
+
The best option to walk through this guide and execute commands would be to use Azure Cloud Shell with Bash environment. Azure Cloud Shell is an interactive, authenticated, browser-accessible shell for managing Azure resources. It provides the flexibility of choosing the shell experience that best suits the way you work, either Bash or PowerShell. For information on how to use Azure Cloud Shell, please visit this page Azure Cloud Shell. You can also install Azure CLI on your machine. The Azure CLI is available to install in Windows, macOS and Linux environments. It can also be run in a Docker container and Azure Cloud Shell. For information on how to install
+the Azure CLI, please visit this page Azure Cli
+
+
If you decide to use Azure Cloud Shell, please use Bash environment.
+
+
Getting Started with the first scenario
+
+
Create folder for you data
+
+
You can use the name below for your folder. You just need to replace asedemo with your environment name.
If you have many subscriptions you must select the subscription to which you want to deploy the resources.
+
+
Using this command you can find and copy the SubscriptionId on which you want to create resources for this scenario.
+
+
az account list -o table
+
+
+
Using this command you can set a subscription to be the current active subscription.
+
+
az account set-s YourSubscriptionID
+
+
+
You can find more information about az account command on this site az account.
+
+
Prepare parameters
+
+
When you construct your naming convention, identify the key pieces of information that you want to reflect in the resource names. Different information is relevant for different resource types. The following sites are useful when you construct resource names Define your naming convention and Recommended abbreviations for Azure resource types
+
+
You can use the names below. You just need to replace asedemo with your environment name, change SubscriptionId, EmailAddress and change LocationRegionPROD parameters.
+
+
Please copy and paste your parameters to your shell.
The demo environment will be organized using two resource groups. The first resource group is for App Service Environment, the second is for Logic App Automation.
+
+
az group create -l$LocationRegionPROD-n$ASEResourceGroupNamePROD
+az group create -l$LocationRegionPROD-n$ResourceGroupNameSHARED
+
+
+
Create virtual network with subnet for App Service Environment
+
+
A virtual network is required to create an App Service Environment. This command will create a virtual network with a subnet.
+
+
az network vnet create -g$ASEResourceGroupNamePROD-n$VirtualNetworkNamePROD--address-prefix$VnetPrefixPROD--subnet-name$SubnetNameVnetPROD--subnet-prefix$SubnetVnetPrefixPROD
+
+
+
Create App Service Environment - This process may take a while
+
+
An App Service Environment is a single-tenant deployment of Azure App Service that runs in your virtual network. This command will create an App Service Environment.
+
+
az appservice ase create -n$ASENamePROD-g$ASEResourceGroupNamePROD--vnet-name$VirtualNetworkNamePROD--subnet$SubnetNameVnetPROD--kind asev3 --virtual-ip-type External
+
+
+
More information about Azure CLI for App Service Environment, visit Azure CLI ASE Create.
+
+
Create App Service Plan in App Service Environment - This process may take a while
+
+
Applications are hosted in App Service plans, which are created in an App Service Environment. An App Service plan is essentially a provisioning profile for an application host. This command will create an App Service plan.
+
+
az appservice plan create -g$ASEResourceGroupNamePROD-n$ASEPlanNamePROD--app-service-environment$ASENamePROD--is-linux--sku I1v2
+
In the next step you will use ZIP Deploy to deploy the application. You need a ZIP utility for this. Fortunately, ZIP utility is pre-installed in Azure Cloud Shell.
+
+
zip primaryapp.zip index.php
+
+
+
Deploy sample app
+
+
To deploy a sample application using ZIP Deploy, use this command:
+
+
az webapp deployment source config-zip --resource-group$ASEResourceGroupNamePROD--name$WEBAPPNamePROD--src ./primaryapp.zip
+
+
+
Check if your app is running
+
+
Use your browser or use curl command to check if your app is working correctly.
+
+
curl https://$URLofYourPrimaryWebsite
+
+
+
Planned maintenance - Change the upgrade preference
+
+
To change the Upgrade preference setting to Manual on your App Service Environment v3, use this command:
+
+
az resource update --name$ASENamePROD-g$ASEResourceGroupNamePROD--resource-type"Microsoft.Web/hostingEnvironments"--set properties.upgradePreference=Manual
+
+
+
Deploy Logic App
+
+
This sample code is intended to show you what the Logic App can do to automate your processes. This sample Logic App shows how to use various connectors and functions that you can use to build you own Logic App in production environment.
+
+
Logic App ARM Template
+
+
You can use the curl command in Azure Cloud Shell to download the template_scenario_1.json file from the github repository.
You can use the code editor in Azure Cloud Shell to check parameters_scenario_1.json file.
+
+
code parameters_scenario_1.json
+
+
+
Use ctrl + q to close code editor.
+
+
Deploy Logic App template
+
+
To start the deployment, execute the command below.
+
+
az deployment group create --name$LogicAppName--resource-group$ResourceGroupNameSHARED--template-file template_scenario_1.json --parameters parameters_scenario_1.json
+
+
+
Authorize Office 365 connection
+
+
Before you can use Office 365 connector in Logic App you must authorize Office365 connection.
Go to your Logic App using for example the search box at the top
+
Click Logic app designer
+
Familiarize yourself with the individual steps of Logic App workflow
+
+
+
Steps in Azure Logic App:
+
+
+
The Logic App starts when an alert occurs. You will configure the alert later in this article.
+
The Logic App verifies that the alert applies to the Azure App Service Environment.
+
Using functions such as split, json and action such as Filter array, the Logic App will extract from the text, the information about the name of App Service Environment to which the alert relates and the URL of the App Service Environment.
+
In the next step, the approval email is sent.
+
If the Approve option is selected, the Logic App will go further. If the Reject option is selected the Logic App will stop working.
+
After selecting Approve, the Logic App will check for an upgrade for the App Service Environment.
+
If an upgrade is available, a http request will be sent which initiates the upgrade. As well, an e-mail will be sent with the information The update of ase-asedemo-prod-01 has started
+
If the update is not available, an e-mail will be sent with the information App Service Environment ase-asedemo-prod-01 does not currently have an upgrade available.
Steps to assign an Azure role contributor to App Service Environment instance:
+
+
Your Logic App will be deployed with system assigned managed identity. Before you can use your Logic App you must give your Logic App identity permission to your App Service Environment. Permissions are required to check if an update is available and to start the update process. If you want to know more about managed identities please go to this page Managed identities for Azure resources. Information about permissions that you need to configure managed identity you can find on this page Managed identities for Azure resources frequently asked questions.
+
+
Step 1: Determine who needs access
+
+
LogicAppIdentity=$(az resource show --name$LogicAppName--resource-group$ResourceGroupNameSHARED--resource-type"Microsoft.Logic/workflows"--query identity.principalId -o tsv)
+
+
+
Step 2: Assign contributor role
+
+
az role assignment create --assignee$LogicAppIdentity--role"Contributor"--scope /subscriptions/$ASEsubscriptionID/resourceGroups/$ASEResourceGroupNamePROD/providers/Microsoft.Web/hostingEnvironments/$ASENamePROD
+
+
+
If you are at this stage, you have successfully created the demo environment. Now we need to create an alert that will trigger the Logic App.
Go to Monitor using for example the search box at the top
+
From the menu, click Service Health
+
Click Planned maintenance
+
Click Add service health alert
+
In the Condition section, select Azure Subscription where you deployed your App Service Environment
+
At the Services box, select only App Service item
+
At the Regions box, select region of your App Service Environment
+
At the Event types filed, select only Planned maintenance
+
In the Action section, click Select action groups
+
Click Create action group
+
In the Basic section:
+
+
select Subscription where you deployed you App Service Environment
+
select Resource group with shared in the name (rg-asedemo-shared-01)
+
Select Global Region
+
Fill the fields Action group name and Display name for example using this name ag-asedemo - please change asedemo to your environment name
+
+
+
In the Actions section, click Action type and select Logic App
+
Fill the fields with information about Subscription (select Azure Subscription where you deployed your App Service Environment), Resource group (select Azure Resource group with shared in the name (rg-asedemo-shared-01)) and Select a logic app that you deployed in previous steps
+
Enable the common alert schema
+
Click “OK”
+
Fill the Name filed for example using the name action-logic-asedemo-prod-01 - please change asedemo to your environment name
+
Click Review + create
+
Click Create
+
Fill Alert rule details section, fill Alert rule name for example using the name alert-asedemo-planned-maintenance - please change asedemo to your environment name
+
Make sure that checkbox Enable alert rule upon creation is selected
+
Click Create alert rule
+
+
+
Send test notifications
+
+
As you build your automation and notification logic, you may want to test it before the actual upgrade is available. The Azure portal and rest api has the ability to send a special test upgrade available notification, which you can use to verify your automation logic. The message will be similar to the real notification, but the title will be prefixed with “[Test]” and the description will be different. You can send test notifications after you’ve configured your upgrade preference to Manual. The test notifications are sent in batches every 15 minutes.
+
+
To send a special test upgrade available notification please use this command:
+
+
ASEidPROD=$(az appservice ase show --name$ASENamePROD--resource-group$ASEResourceGroupNamePROD--queryid--output tsv)
+az rest --method POST --uri"${ASEidPROD}/testUpgradeAvailableNotification?api-version=2022-03-01"
+
+
+
You can also use Azure portal to send test notifications. You can find more information about test notifications on this site Send test notifications
+
+
Check your mailbox and approve the upgrade process
+
+
+
+
Because this is test notification your Logic app will send you an email with information that App Service Environment NameOfYourASE does not currently have an upgrade available. In a real-world scenario when an upgrade will be available your Logic App will send you information that The update of NameOfYourASE has started.
+
+
Logic App run history blade
+
+
Familiarize yourself with the Logic App run using Run history blade.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
This is part 2 of a 2-part series about automation for planned maintenance in App Service Environment v3. In this 2-part series, I will walk you through building a demo environment, setting up manual upgrade preference option for App Service Environment and configure automation using Logic App. In the first scenario you have deployed a simple environment, in the second scenario the environment will be more complex.
+
+
The first article uses one Azure App Service Environment, which will be configured with the manual upgrade preference option. When an upgrade is ready, an alert will be triggered that will start your Logic App. The Logic App will send you an email asking you to confirm the upgrade process.
+
+
The second article uses two Azure App Service Environments in two different regions. The first App Service Environment will be for the production workload, and the second for disaster recovery purposes. The Web App will be published using Azure Front Door Standard service. When an upgrade is ready, an alert will be triggered that will start your Logic App. The Logic App will send you an email asking you to confirm traffic redirection from the primary region to the disaster recovery region, when you accept this workflow, Logic App will redirect the traffic and start the upgrade process of your production Azure App Service Environment. Using this approach you can avoid cold start of the applications. Usually the upgrade process should be invisible for your application but if you have an application that needs more time to start or you want to decide when the upgrade should start then this approach will be perfect for you.
+
+
+
Info You can also use the Logic App from this article to redirect the traffic before migrating from App Service Environment v2 to App Service Environment v3. When Logic App does not detect an available upgrade, it will send you an email asking you to confirm only the traffic redirection from the primary region to the secondary region without starting upgrade process of the App Service Environment. Another place where you can use this example to build a production version of your Logic App may be the disaster recovery procedure.
+
+
+
+
Remember Now you can change Upgrade preference option to Manual and decide for yourself when you want to upgrade App Service Environment v3. After an update is available, you’ll have 15 days to start the upgrade process. If you don’t start the upgrade within the 15 days, the upgrade will be processed with the remaining automatic upgrades in the region. You can find more information about upgrade preference for App Service Environments v3 on this site upgrade preference for App Service Environments
Deploy second App Service Environment using Azure CLI
+
Deploy second sample app using Azure CLI
+
Deploy Azure Front Door using CLI
+
Deploy new version of Logic App using ARM template
+
Change Alert rules in Monitor
+
+
+
Decide where you will execute commands
+
+
The best option to walk through this guide and execute commands would be to use Azure Cloud Shell with Bash environment. Azure Cloud Shell is an interactive, authenticated, browser-accessible shell for managing Azure resources. It provides the flexibility of choosing the shell experience that best suits the way you work, either Bash or PowerShell. For information on how to use Azure Cloud Shell, please visit this page Azure Cloud Shell. You can also install Azure CLI on your machine. The Azure CLI is available to install in Windows, macOS and Linux environments. It can also be run in a Docker container. For information on how to install the Azure CLI, please visit this page Azure CLI.
+
+
If you decide to use Azure Cloud Shell, please use Bash environment.
If you have many subscriptions you must select the subscription in which you want to deploy the resources.
+
+
Using this command you can find and copy the SubscriptionId in which you want to create resources for this scenario.
+
+
az account list -o table
+
+
+
Using this command you can set a subscription to be the current active subscription.
+
+
az account set-s YourSubscriptionID
+
+
+
You can find more information about the az account command on this site az account.
+
+
Prepare parameters
+
+
When you construct your naming convention, identify the key pieces of information that you want to reflect in the resource names. Different information is relevant for different resource types. The following sites are useful when you construct resource names Define your naming convention and Recommended abbreviations for Azure resource types.
+
+
You can use the names below. You just need to replace asedemo with your environment name (please use the same environment name that you used in scenario 1), change SubscriptionId, EmailAddress, LocationRegionPROD and change LocationRegionDR parameters.
The demo environment will be organized using three resource groups. The first resource group is for App Service Environment in primary region, the second is for App Service Environment in secondary region and the third resource group is for the Logic App automation. Two resource groups were created during the first scenario, now you need to create a resource group for Azure App Service Environment is the secondary region.
+
+
az group create -l$LocationRegionDR-n$ASEResourceGroupNameDR
+
+
+
Create virtual network with subnet for App Service Environment
+
+
A virtual network is required to create an App Service Environment. This command will create a virtual network with a subnet.
+
+
az network vnet create -g$ASEResourceGroupNameDR-n$VirtualNetworkNameDR--address-prefix$VnetPrefixDR--subnet-name$SubnetNameVnetDR--subnet-prefix$SubnetVnetPrefixDR
+
+
+
Create App Service Environment - this process may take a while
+
+
An App Service Environment is a single-tenant deployment of Azure App Service that runs in your virtual network. This command will create an App Service Environment.
+
+
az appservice ase create -n$ASENameDR-g$ASEResourceGroupNameDR--vnet-name$VirtualNetworkNameDR--subnet$SubnetNameVnetDR--kind asev3 --virtual-ip-type External
+
+
+
For more information about Azure CLI for App Service Environment, visit Azure CLI ASE Create.
+
+
Create App Service Plan in App Service Environment - this process may take a while
+
+
Applications are hosted in App Service plans, which are created in an App Service Environment. An App Service plan is essentially a provisioning profile for an application host. This command will create an App Service plan.
+
+
az appservice plan create -g$ASEResourceGroupNameDR-n$ASEPlanNameDR--app-service-environment$ASENameDR--is-linux--sku I1v2
+
+
+
For more information about Azure CLI for App Service Environment Plan, visit Azure CLI ASE Plan Create
+
+
Create and deploy sample application
+
+
Create a web app
+
+
To create a PHP app in your App Service Environment, use this command.
+
+
az webapp create -g$ASEResourceGroupNameDR-p$ASEPlanNameDR-n$WEBAPPNameDR--runtime"PHP:8.0"
+
+
+
+
Tip: To check the list of available runtimes in format Framework:Version, use the command az webapp list-runtimes.
+
+
+
Create variables with the URLs of your websites. You will use these variables later with the curl command to check if your websites is working correctly.
+
+
URLofYourPrimaryWebsite=$(az webapp show --name$WEBAPPNamePROD--resource-group$ASEResourceGroupNamePROD--query defaultHostName -o tsv)
+URLofYourSecondaryWebsite=$(az webapp show --name$WEBAPPNameDR--resource-group$ASEResourceGroupNameDR--query defaultHostName -o tsv)
+
In the next step you will use ZIP Deploy to deploy the application. You need a ZIP utility for this. Fortunately, ZIP utility is pre-installed in Azure Cloud Shell.
+
+
zip secondaryapp.zip index.php
+
+
+
Deploy sample app
+
+
To deploy a sample application using ZIP Deploy, use this command:
+
+
az webapp deployment source config-zip --resource-group$ASEResourceGroupNamePROD--name$WEBAPPNamePROD--src ./secondaryapp.zip
+
+
+
Check if your app is running
+
+
Use your browser or use curl command to check if your secondary app is working correctly.
+
+
curl https://$URLofYourSecondaryWebsite
+
+
+
Planned maintenance - Change the upgrade preference
+
+
To change the Upgrade preference setting to Manual on your App Service Environment v3, use this command:
+
+
az resource update --name$ASENameDR-g$ASEResourceGroupNameDR--resource-type"Microsoft.Web/hostingEnvironments"--set properties.upgradePreference=Manual
+
+
+
Deploy Azure Front Door
+
+
Create Azure Front Door profile
+
+
Run az afd profile create to create an Azure Front Door profile.
Create a variable with the URL of your Azure Front Door endpoint. You will use this variable later with the curl command to check if your Azure Front Door endpoint is working correctly.
For more information about Azure CLI for Azure Front Door, visit Front Door CLI.
+
+
In a production environment you will probably need to implement a WAF policy for you application. For more information about Azure CLI for Azure Front Door WAF Policy, visit Front Door WAF Policy.
+
+
Check if your Azure Front Door Endpoint is running - this process may take a while
+
+
Use your browser or use curl command to check if your app is working correctly.
+
+
curl https://$URLofYourFrontDoorEndpoint
+
+
+
Deploy Logic App
+
+
This sample code is intended to show you what the Logic App can do to automate your processes. This sample Logic App shows how to use various connectors and functions to build you own Logic App in a production environment.
+
+
Logic App ARM Template
+
+
You can use the curl command in Azure Cloud Shell to download the template_scenario_2.json file from the GitHub repository.
You can use the code editor in Azure Cloud Shell to check parameters_scenario_2.json file.
+
+
code parameters_scenario_2.json
+
+
+
Use ctrl + q to close code editor.
+
+
Deploy Logic App template
+
+
To start the deployment, execute the command below.
+
+
az deployment group create --name$LogicAppName--resource-group$ResourceGroupNameSHARED--template-file template_scenario_2.json --parameters parameters_scenario_2.json
+
+
+
Authorize Office 365 connection
+
+
Before you can use the Office 365 connector in your Logic App you must authorize the Office365 connection.
Go to your Logic App using for example the search box at the top, search for logic-asedemo-prod-02 - change asedemo to your environment name
+
Click Logic app designer
+
Familiarize yourself with the individual steps of the Logic App workflow
+
+
+
Steps in Azure Logic App:
+
+
+
The Logic App starts when an alert occurs. You will configure the alert later in this article.
+
The Logic App verifies that the alert applies to the Azure App Service Environment.
+
Using functions such as split, json and action such as Filter array, the Logic App will extract from the text, the information about the name of App Service Environment to which the alert relates and the URL of the App Service Environment.
+
In the next step, the approval email is sent.
+
If the Approve option is selected, the Logic App will go further. If the Reject option is selected the Logic App will send second approval email, more information about this in point 8.
+
After selecting Approve, the Logic App will check for an upgrade for the App Service Environment.
+
If an upgrade is available, a http requests will be sent which redirect the traffic from the primary region to the secondary region and initiates the upgrade. As well, an e-mail will be sent with the information that the traffic has been redirected and the upgrade has started.
+
If the upgrade is not available, the second approval email is sent.
+
If the Approve option is selected, the Logic App will continue. If the Reject option is selected the Logic App will stop working.
+
After selecting Approve, the Logic App will only redirect the traffic from the primary region to the secondary region without starting upgrade process of App Service Environment. As well, an e-mail will be sent with the information that traffic has been redirected.
Steps to assign a contibutor RBAC role to App Service Environment instance:
+
+
Your Logic App will be deployed with system assigned managed identity. Before you can use your Logic App you must give your Logic App identity permission to your App Service Environment and Azure Front Door. Permissions are required to:
+
+
+
Checking if an upgrade is available
+
Starting the upgrade process
+
Redirect traffic from the primary region to the secondary region
Go to Monitor using for example the search box at the top.
+
From the menu, click Alerts.
+
Click Alert rules.
+
Search for your alert alert-asedemo-planned-maintenance - please change asedemo to your environment name, open the alert rules.
+
Click Edit button.
+
In the Action section, click name of your Action group nameag-asedemo - please change asedemo to your environment name.
+
In the Action section, change Selected logic app to you new Logic App using edit button.
+
In field Select a logic app choose your new Logic App with name logic-asedemo-prod-02 - please change asedemo to your environment name.
+
Click OK.
+
Click Save changes.
+
+
+
Send test notifications
+
+
As you build your automation and notification logic, you may want to test it before the actual upgrade is available. The Azure portal and rest api has the ability to send a special test upgrade available notification, which you can use to verify your automation logic. The message will be similar to the real notification, but the title will be prefixed with “[Test]” and the description will be different. You can send test notifications after you’ve configured your upgrade preference to Manual. The test notifications are sent in batches every 15 minutes.
+
+
To send a special test upgrade available notification, use this command:
+
+
ASEidPROD=$(az appservice ase show --name$ASENamePROD--resource-group$ASEResourceGroupNamePROD--queryid--output tsv)
+az rest --method POST --uri"${ASEidPROD}/testUpgradeAvailableNotification?api-version=2022-03-01"
+
+
+
You can also use Azure portal to send test notifications. You can find more information about test notifications at Send test notifications.
+
+
Check your mailbox and approve the redirection traffic from the primary region to the secondary region and upgrade process
+
+
+
+
Because this is a test notification your Logic App will send you a second email asking you to confirm only the traffic redirection. Information from email App Service Environment NameOfYourASE does not currently have an upgrade available but you can redirect the traffic without upgrade using approve button. In a real-world scenario when an upgrade will be available your Logic App will send you information that The traffic from NameOfYourWebAppPrimaryRegion to the NameOfYourWebAppSecondaryRegion has been redirected and the upgrade of NameOfYourASE has started.
+
+
+
Tip: You can also send a test notification from the App Service Environment in the second region, the Logic App will redirect traffic from the second region to the primary region.
+
+
+
Logic App run history blade
+
+
Familiarize yourself with the Logic App run using Run history blade.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Public Preview: Disabling Weaker TLS Cipher Suites for Web Apps on Multi-tenant Premium App Service Plans
+
+
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Yutang Lin
+
+ • October 11, 2022
+
+
+
+
+
+
+
+
+
For a few years, the only way to disable weaker TLS Cipher Suites for web apps is to host these web apps in an App Service Environment (ASE). The recent update to the App Service front-ends mentioned earlier has allowed the capability to bring this type of TLS cipher suite customization to customers running on the public multi-tenant footprint. We are excited to announce a public preview of the minimum TLS cipher suite feature that allows web apps in multi-tenant premium App Service Plans to disable weaker cipher suites! This feature enables our security conscious customers to trim off older cipher suites that the App Service platform supports for client compatibility.
+
+
What are cipher suites and how do they work on App Service?
+
+
A cipher suite is a set of instructions that contains algorithms and protocols to help secure network connections between clients and servers. By default, the front-end’s OS would pick the most secure cipher suite that is supported by both the front-end and the client. However, if the client only supports weak cipher suites, then the front-end’s OS would end up picking a weak cipher suite that is supported by them both.
+
+
If a customer’s organization has restrictions on what cipher suites are not be allowed, they may update their web app’s minimum TLS cipher suite property to ensure that the weaker cipher suites would be disabled for their web app. The next part of the article will go through the new minimum TLS cipher suite feature that is currently in public preview.
+
+
Minimum TLS Cipher Suite Feature
+
+
The minimum TLS cipher suite feature comes with a pre-determined list of cipher suites that cannot be reordered nor reprioritized. Since the service is already using the ideal priority order, it is not recommended for customers to reprioritize the the cipher suite order. Customers can potentially leave their web apps exposed if weaker cipher suites are prioritized over the stronger ones. Customers also cannot add newer or different cipher suites to the list of supported cipher suites. When a minimum cipher suite is selected, all the cipher suites that are less secure than the selected minimum one would be disabled for the web app. There is no support to make exceptions and to disable only some of the cipher suites that are weaker than the selected minimum cipher suite.
+
+
What cipher suites are supported and how are they prioritized?
+
+
Refer to below for the list of supported cipher suites. These cipher suites are listed in order from most secure to the least secure. The service may update the list of supported cipher suite later on, though not very frequently.
Minimum TLS cipher suite is a property that resides in the site’s config and customers can make changes to disable weaker cipher suites by updating the site config through API calls. The minimum TLS cipher suite feature is currently not yet supported on the Azure Portal.
+
+
Sample API call
+
+
This part of the article will show an example on how to select a minimum TLS cipher suite in order to disable weaker cipher suites.
+
+
Let’s say, based from the list of supported TLS cipher suites, we would like to disable all the cipher suites that are weaker than TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA. In order to do this, we can call the Update Config API to set the property minTlsCipherSuite to TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA. Refer to the sample API call below.
+
+
Take note that the API parameter for minTlsCipherSuite is case sensitive.
After successfully updating the site config, we will see the value of the property minTlsCipherSuite change to the selected cipher suite, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA from the example above.
+
+
We will also see the value of the property supportedTlsCipherSuites show a list of all the cipher suites that are enabled for the web app. In this case, the cipher suites that are weaker than the selected minimum cipher suite, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, will not show up in the supportedTlsCipherSuites property because they have been disabled for the web app.
+
+
What is the default behavior?
+
+
By default, without making any changes to the minimum TLS cipher suite property, the web app will support all the cipher suites the front-end supports. The minTlsCipherSuite property would be null and the supportedTlsCipherSuites property would also be null; this just means that the web app will allow all the supported cipher suites as the default behavior.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
WordPress on Azure App Service supports Azure Front Door Integration
+
+
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Radhika Bollineni
+
+ • October 12, 2022
+
+
+
+
+
+
+
We are happy to announce the preview of WordPress on Azure App Service powered by Azure Front Door which enables faster page loads, enhanced security, and increased reliability for your global apps with no configuration or additional code required. This integration help improve the site performance by delivering your content using Microsoft’s global edge network with hundreds of global and local points of presence. Access to the static and dynamic content of your WordPress application is accelerated by caching static content at the edge server and using split TCP method to reduce connection establishment time among others.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • October 12, 2022
+
+
+
+
+
+
+
We are happy to announce that App Service now supports apps targeting Go 1.18 and 1.19 across all public regions on Linux App Service Plans through the App Service Early Access feature. By introducing native support for Go on App Services, we are making one of the top 10 best loved web app development languages available for our developers.
+
+
Support for Go is being added as an Experimental feature. Experimental features are work in progress and can radically change or completely disappear at any time. You can use it if you’re an early adopter, see something useful to you, and would like to help test the feature.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • October 12, 2022
+
+
+
We are happy to announce that App Service now supports apps targeting Node 18, PHP 8.1 and Python 3.10 across all public regions on Linux App Service Plans t...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • October 12, 2022
+
+
+
We are happy to announce that App Service now supports apps targeting Go 1.18 and 1.19 across all public regions on Linux App Service Plans through the App S...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Radhika Bollineni
+
+ • October 12, 2022
+
+
+
We are happy to announce the preview of WordPress on Azure App Service powered by Azure Front Door which enables faster page loads, enhanced security, and in...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Denver Brittain
+
+ • October 28, 2022
+
+
+
App Service free SKU has been around for over 10 years, and we continue to improve on it with every release. Today, we are pleased to announce that App Servi...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Denver Brittain
+
+ • October 28, 2022
+
+
+
App Service free SKU has been around for over 10 years, and we continue to improve on it with every release. Today, we are pleased to announce that App Servi...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • October 12, 2022
+
+
+
We are happy to announce that App Service now supports apps targeting Node 18, PHP 8.1 and Python 3.10 across all public regions on Linux App Service Plans t...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • October 12, 2022
+
+
+
We are happy to announce that App Service now supports apps targeting Go 1.18 and 1.19 across all public regions on Linux App Service Plans through the App S...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Radhika Bollineni
+
+ • October 12, 2022
+
+
+
We are happy to announce the preview of WordPress on Azure App Service powered by Azure Front Door which enables faster page loads, enhanced security, and in...
Azure App Service and Azure Functions on Azure Stack Hub 2022 H1 Released
+
+
+
+
+
+
+
+
+ 2 minute read
+
+
+
+ • By Andrew Westgarth
+
+ • November 2, 2022
+
+
+
+
+
+
+
The 2022 H1 update to Azure App Service on Azure Stack Hub is now available. This release is a major update in terms of underlying infrastructure and topology. We highly recommend operators read through the release notes for further details and review the operational documentation in order to be aware of all changes.
+
+
What’s New?
+
+
+
All roles are now powered by Windows Server 2022 Datacenter.
+
Administrators can isolate the platform image for use by App Service on Azure Stack Hub, by setting the SKU to AppService.
+
Networking design update for all worker virtual machine scale sets, addressing customers faced with SNAT port exhaustion issues.
+
Increase number of outbound address for all applications.
+
Administrators can set a three character deployment prefix for the individual instances in each Virtual Machine Scale Set that are deployed as part of the App Service on Azure Stack Hub Resource provider.
+
+
Deployment Center is enabled for tenants, replacing the Deployment Options experience - IMPORTANT - Operators will need to reconfigure their deployment sources as the redirect urls have changed with this update.
+
+
Updates to App Service Tenant, Admin, Functions portals and Kudu tools. Consistent with Azure Stack Portal SDK version.
+
Updates to core service to improve reliability and error messaging enabling easier diagnosis of common issues.
+
+
+
Updates to the following application frameworks and tools:
+
+
Azure Functions runtime to v1.0.13154
+
ASP.NET Core
+
+
3.1.18
+
3.1.23
+
6.0.2
+
6.0.3
+
+
+
Eclipse Temurin OpenJDK 8
+
+
8u302
+
8u312
+
8u322
+
+
+
Microsoft OpenJDK 11
+
+
11.0.12.7.1
+
11.0.13.8
+
11.0.14.1
+
17.0.1.12
+
17.0.2.8
+
+
+
MSBuild
+
+
16.7.0
+
17.1.0
+
+
+
NodeJS
+
+
14.18.1
+
16.9.1
+
16.13.0
+
+
+
NPM
+
+
6.14.15
+
7.21.1
+
8.1.0
+
+
+
Tomcat
+
+
8.5.69
+
8.5.72
+
8.5.78
+
9.0.52
+
9.0.54
+
9.0.62
+
10.0.12
+
10.0.20
+
+
+
Updated Kudu to 97.40427.5713
+
Updates to underlying operating system of all roles:
+
+
2022-09 Cumulative Update for Windows Server 2022 for x64-based Systems (KB5017316)
+
Defender Definition 1.373,353.0
+ Cumulative Updates for Windows Server are now applied to Controller roles as part of deployment and upgrade
+
+
+
+
+
All other fixes and updates are detailed in the App Service on Azure Stack Hub 2022 H2 Release Notes
+The App Service on Azure Stack Hub 2022.H! build number is 98.0.1.699 and requires Azure Stack Hub to be updated with 1.2108.2.127 or 1.2206.2.52 prior to deployment/upgrade.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 2 minute read
+
+
+
+ • By Andrew Westgarth
+
+ • November 2, 2022
+
+
+
The 2022 H1 update to Azure App Service on Azure Stack Hub is now available. This release is a major update in terms of underlying infrastructure and topolog...
We have completed the initial rollout for .NET 7 GA support on App Service. Like in previous years we are using the App Service Early Access feature to enable day-0 support on the platform across all public regions on both Windows and Linux App Service Plans. The early access release will be followed by additional deployments to fully integrate the new bits across our fleet expecting to be fully done by the end of the week.
+
+
If you already have an app targeting and earlier preview of .NET 7.0 on the platform, there is no need to take action as the new runtime will be picked up on the next application restart once the update is available for your app. You can trigger this manually by starting and stopping your app.
+
+
Self-contained .NET apps will not be auto-updated since they have no dependency on the runtime provided by App Service.
If you want to learn more, be sure to checkout our session during .NET Conf 2022:
+
+
+
Tuesday 11/09 @ 11:00am PST Join Scott Hunter to talk about the latest happening in the world of building cloud native applications with .NET and Azure
+
Thursday 11/10 @ 1:00am PST Join @bktv99 and @segaurav will be taking the stage talk about “.NET 7.0 and bulk migration of ASP.Net web apps to App Services”.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
We have completed the initial rollout for .NET 7 GA support on App Service. Like in previous years we are using the App Service Early Access feature to enabl...
Currently, you can use two options when configuring Azure App Service access restrictions. The preview feature provides some new scenarios that you should know.
+
+
This article will walk you through building a demo environment where you will test advanced access restriction scenarios in Azure App Service.
+
+
+
+
Access restriction advanced scenarios:
+
+
+
Filter by http header
+
Multi-source rules
+
Block a single IP address
+
Restrict access to the SCM site
+
+
+
For more information about App Service access restrictions, visit this page
+
+
Requirements:
+
+
Access to an Azure subscription.
+
+
Decide where you will execute commands
+
+
The best option to walk through this guide and execute commands would be using Azure Cloud Shell with Bash environment. Azure Cloud Shell is an interactive, authenticated, browser-accessible shell for managing Azure resources. It provides the flexibility of choosing the shell experience that best suits the way you work, either Bash or PowerShell. For information on how to use Azure Cloud Shell, visit Azure Cloud Shell. You can also install Azure CLI on your machine. The Azure CLI is available to install in Windows, macOS and Linux environments. It can also be run in a Docker container and Azure Cloud Shell. For information on how to install the Azure CLI, please visit Azure CLI installation.
+
+
If you decide to use Azure Cloud Shell, please use Bash environment.
+
+
Getting Started
+
+
Create folder for your data
+
+
You can use the name below for your folder. You just need to replace ardemo with your environment name.
+
+
mkdir ardemo
+cd ardemo
+
+
+
Choosing the right subscription
+
+
If you have many subscriptions, you must select the subscription to which you want to deploy the resources.
+
+
Using this command you can find and copy the SubscriptionId on which you want to create resources for this scenario.
+
+
az account list -o table
+
+
+
Using this command you can set a subscription to be the current active subscription.
+
+
az account set-s YourSubscriptionID
+
+
+
You can find more information about az account command on this site az account.
+
+
Prepare parameters
+
+
When you construct your naming convention, identify the key pieces of information that you want to reflect in the resource names. Different information is relevant for different resource types. The following sites are useful when you construct resource names - Define your naming convention and Recommended abbreviations for Azure resource types.
+
+
You can use the names below. You just need to replace ardemo with your environment name and change LocationRegion parameter.
+
+
Please copy and paste your parameters to your shell.
In the next step you will use ZIP Deploy to deploy the application. You need a ZIP utility for this. If you’re using Azure Cloud Shell, ZIP utility is pre-installed and already available.
+
+
zip YourWebSite.zip index.php
+
+
+
Deploy sample app
+
+
To deploy a sample application using ZIP Deploy, use this command:
+
+
az webapp deployment source config-zip --resource-group$ResourceGroupName--name$WebAppName--src ./YourWebSite.zip
+
+
+
Check if your app is running
+
+
Use your browser or use curl command to check if your app is working correctly.
+
+
curl https://$URLofYourWebsite
+
+
+
Create the Private Endpoint
+
+
A private endpoint is a network interface that uses a private IP address from your virtual network. This network interface connects you privately and securely to a service that’s powered by Azure Private Link. By enabling a private endpoint, you’re bringing the service into your virtual network.
+
+
For more information about private endpoint, visit this page.
az network private-dns zone create --name privatelink.azurewebsites.net --resource-group$ResourceGroupName
+az network private-dns link vnet create --name myDNSLink --resource-group$ResourceGroupName--registration-enabledfalse--virtual-network$VirtualNetworkName--zone-name privatelink.azurewebsites.net
+az network private-endpoint dns-zone-group create --name myZoneGroup --resource-group$ResourceGroupName--endpoint-name$PrivateEndpointName--private-dns-zone privatelink.azurewebsites.net --zone-name privatelink.azurewebsites.net
+
+
+
Check if your website is unavailable
+
+
After enabling private endpoint, the web app should not be reachable from the Internet.
+
+
Use your browser or use curl command to check if your app is not reachable.
+
+
curl https://$URLofYourWebsite
+
+
+
The result should look similar to this.
+
+
+
+
Optional test
+
+
You can create a VM in the same virtual network as the private endpoint for Azure App Service and run a network connection test using private IP address. The name of the Azure App Service should resolve to a private IP address. You can check this using the ping or nslookup command. To check if the website is working properly by using the private IP address, use curl command or a browser on a VM that you will deploy.
+
+
+
Remember to use the standard App Service URL. Thanks to the integration with private DNS zone, the name will be translated into a private IP address.
+For more information about Azure App Service private endpoint DNS, visit this page.
+
+
+
First advanced scenario - Filter by http header
+
+
Currently, you can run Azure App Service with a private endpoint as well as allow traffic from the Internet to Azure App Service. Thanks to this, you can use, for example, Azure Front Door Standard SKU to make Azure App Service available from the Internet. Previously, when using a private endpoint for Azure App Service, it was required to use the Azure Front Door Premium SKU.
+
+
For more information about Secure Origin with Private Link in Azure Front Door Premium, visit this page.
+
+
In this guide you will add a rule that will allow access from Azure Front Door Standard instance to your Azure App Service using X-Azure-FDID.
+
+
+
Tip Access restrictions can use the following headers:
+
+
X-Forwarded-Host - You can specify hostnames of the originating request to limit traffic if a load balancer or HTTP proxy supports hostname forwarding. Enter up to 8 hostnames separated by a comma.
+
X-Forwarded-For - You can specify IP addresses of the originating client if a load balancer or HTTP proxy supports IP forwarding when the traffic is passing >through. Enter up to 8 CIDR addresses separated by a comma.
+
X-Azure-FDID - You can specify a unique instance id of Azure Front Door or reverse proxies supporting unique header identification. Enter up to 8 ids >separated by a comma.
+
X-FD-HealthProbe - You can specify health probe identification to allow probe traffic. Enter up to 8 health probe ids separated by a comma.
+
+
+
+
Enable public access
+
+
To allow traffic from the Internet, use this command.
+
+
az resource update --resource-group$ResourceGroupName--name$WebAppName--resource-type"Microsoft.Web/sites"--set properties.publicNetworkAccess=Enabled
+
+
+
You can also enable Allow public access from the GUI.
+
+
+
+
Check if your website is available
+
+
After enabling public access, the webapp should be available from the Internet and from the private endpoint.
+
+
Use your browser or curl command to check if your app is working correctly.
+
+
curl https://$URLofYourWebsite
+
+
+
Secure Access using Front Door Standard SKU
+
+
Azure Front Door is Microsoft’s modern cloud Content Delivery Network (CDN) that provides fast, reliable, and secure access between your users and your applications’ static and dynamic web content across the globe. Azure Front Door delivers your content using the Microsoft’s global edge network with hundreds of global and local POPs distributed around the world close to both your enterprise and consumer end users.
+
+
For more information about Azure Front Door, visit this page.
+
+
Create Azure Front Door profile
+
+
Run az afd profile create to create an Azure Front Door profile.
Create a variable with the URL of your Azure Front Door endpoint. You will use this variable later with the curl command to check if your Azure Front Door endpoint is working correctly.
For more information about Azure CLI for Azure Front Door, visit Front Door CLI.
+
+
In a production environment you will probably need to implement a WAF policy for you application. For more information about Azure CLI for Azure Front Door WAF Policy, visit Front Door WAF Policy.
+
+
Check if your Azure Front Door Endpoint is running - this process may take a while
+
+
Use your browser or curl command to check if your app is working correctly. It may take 10-15 minutes for your app to be accessible using Front Door.
+
+
curl https://$URLofYourFrontDoorEndpoint
+
+
+
Add X-Azure-FDID rule
+
+
Create a variable with the ID of your Azure Front Door profile.
Check if your app allow connections using Azure Front Door URL
+
+
Use your browser or curl command to check if your app is working correctly using Azure Front Door URL.
+
+
curl https://$URLofYourFrontDoorEndpoint
+
+
+
Check if your app is blocked by network restrictions
+
+
Use your browser or curl command to check if your app is not available via direct URL access.
+
+
curl https://$URLofYourWebsite
+
+
+
Second advanced scenario - Multi-source rules
+
+
Multi-source rules allow you to combine up to eight IP ranges or eight Service Tags in a single rule. You might use this if you have more than 512 IP ranges or you want to create logical rules where multiple IP ranges are combined with a single http header filter.
+
+
First example - add multiple ip ranges to rule
+
+
In example 1, you will add several ip ranges to one rule.
+
+
Prepare to run the first scenario
+
+
To remove the policy from the previous scenario, please run the command below.
+
+
az webapp config access-restriction remove --resource-group$ResourceGroupName--name$WebAppName--rule-name FrontDoor
+
+
+
To change the default behavior Unmatched rule action to Deny, please run the command below.
+
+
az resource update --resource-group$ResourceGroupName--name$WebAppName--resource-type"Microsoft.Web/sites"--set properties.siteConfig.ipSecurityRestrictionsDefaultAction=Deny
+
+
+
Check if your app is blocked by network restrictions
+
+
Use your browser or curl command to check if your app is blocked by network restrictions.
+
+
curl https://$URLofYourWebsite
+
+
+
Check your public IP addresses and create variable
+
+
+
Remember If you are using Azure Cloud Shell, remember that you will have a different public IP address every time you restart your console.
+
+
+
YourPublicIPaddress=$(curl icanhazip.com)
+
+
+
+
TIP You can also use a Powershell command to check your public IP address.
Use your browser or curl command to check if your app is working correctly.
+
+
curl https://$URLofYourWebsite
+
+
+
Second example - add multiple service tags to a network restriction rule
+
+
This example show you how you can add multiple service tags to a network restriction rule. In this example we will allow connections from Logic Apps, Application Insights and API Management from West Europe. In this example you will test this rule using Application Insights availability test.
+
+
Prepare to run the second example
+
+
The following command will create Application Insights and Log Analytics Workspace for you.
+
+
az monitor log-analytics workspace create --resource-group$ResourceGroupName--workspace-name$LogAnalyticsName
+LogAnalyticsId=$(az monitor log-analytics workspace show --resource-group$ResourceGroupName--workspace-name$LogAnalyticsName--queryid-o tsv)
+LogAnalyticsWorkspaceId=$(az monitor log-analytics workspace show --resource-group$ResourceGroupName--workspace-name$LogAnalyticsName--query customerId -o tsv)
+az monitor app-insights component create --app$ApplicationInsightsName--location$LocationRegion--kind web -g$ResourceGroupName--application-type web --workspace$LogAnalyticsId
+ApplicationInsightId=$(az monitor app-insights component show --app$ApplicationInsightsName-g$ResourceGroupName--queryid-o tsv)
+az monitor app-insights web-test create --web-test-kind"standard"--enabledtrue--location$LocationRegion--resource-group$ResourceGroupName--name$ApplicationInsightsWebTestName--defined-web-test-name$ApplicationInsightsWebTestName--tags"hidden-link:$ApplicationInsightId=Resource"--http-verb"GET"--request-url"https://$URLofYourWebsite"--timeout 30 --frequency 300 --retry-enabledtrue--locationsId="emea-nl-ams-azr"--locationsId="us-fl-mia-edge"
+
+
+
Show Application Insights availability test result
+
+
After running the command below, you should get a result from Application Insights that the tests failed.
+
+
+
Tip Please wait 5-10 minutes before you run this command. Availability tests are run every 5 minutes.
+
+
+
az monitor log-analytics query -w$LogAnalyticsWorkspaceId--analytics-query"AppAvailabilityResults | project TimeGenerated, Message, Location | order by TimeGenerated desc"-t P0DT1H -o table
+
+
+
Tip If you have multiple availability tests in one Application Insight, you can use the Name field for filtering.
+
+
+
The result should look similar to this.
+
+
+
+
Add service tags to multi-source rule
+
+
To add a rule that will allow traffic from several service tags, run the following command.
Check if your app is blocked by network restrictions
+
+
Use your browser or curl command to check if your app is blocked by network restriction.
+
+
curl https://$URLofYourWebsite
+
+
+
Fourth advanced scenario - Restrict access to the SCM site
+
+
You can use the same access restriction rules from the Main site or create your own rule for the SCM (Advanced tool) site. The SCM site is responsible for Web Deploy and Kudu console.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Currently, you can use two options when configuring Azure App Service access restrictions. The preview feature provides some new scenarios that you should kn...
Currently, you can use two options when configuring Azure App Service access restrictions. The preview feature provides some new scenarios that you should kn...
We have completed the initial rollout for .NET 7 GA support on App Service. Like in previous years we are using the App Service Early Access feature to enabl...
+
+
+
+
+
+
+ 2 minute read
+
+
+
+ • By Andrew Westgarth
+
+ • November 2, 2022
+
+
+
The 2022 H1 update to Azure App Service on Azure Stack Hub is now available. This release is a major update in terms of underlying infrastructure and topolog...
Our engineering teams have been hard at work to deliver the new larger SKUs on App Service Environment v3. While it seems simple, as it is multiples of the existing SKU sizes, we took the opportunity to make some major adjustments, and build a more flexible backend to allow us to introduce more compute options in the future.
+
+
With the addition of these new Isolated V2 SKUs, these are the SKUs available for App Service Environment v3.
+
+
+
+
+
SKU Name
+
vCPUs
+
Memory
+
+
+
+
+
I1v2
+
2 vCPUs
+
8 GB
+
+
+
I2v2
+
4 vCPUs
+
16 GB
+
+
+
I3v2
+
8 vCPUs
+
32 GB
+
+
+
I4v2
+
16 vCPUs
+
64 GB
+
+
+
I5v2
+
32 vCPUs
+
128 GB
+
+
+
I6v2
+
64 vCPUs
+
256 GB
+
+
+
+
+
You can create new plans and scale in the Azure portal with the new SKUs. The new SKUs are not available if you create both App Service Environment and plan as part of creating a new app in the portal, but you can scale up after creating it. Prices may also not be visible in all regions, but are 2x increments as shown in this screenshot.
+
+
+
+
Download the latest Azure CLI to have support for the new SKUs using az appservice create/update. Note that the command will take about 40 minutes for Windows and 15 minutes for Linux to complete the create/update operation (use the --no-wait parameter to avoid having to wait for the command to finish in the console):
+
+
az appservice plan create/update --name <plan name> --sku I5v2 -g <resource-group-name> -e <ase-name or resource-id> --no-wait
+
+
+
To deploy a new plan or update an existing plan using ARM, you can simply just specify the new SKU names. If you use the template below, just replace the values prefixed with REPLACE. For the reserved property, true = Linux, false = Windows.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Our engineering teams have been hard at work to deliver the new larger SKUs on App Service Environment v3. While it seems simple, as it is multiples of the e...
+
+
+
+
+
+
+ 24 minute read
+
+
+
+ • By Jordan Selig
+
+ • December 2, 2022
+
+
+
Many applications will consist of more than just a single component. For example, you may have a frontend which is publicly accessible that connects to a bac...
+
+
+
+
+
+
+ 32 minute read
+
+
+
+ • By Jordan Selig
+
+ • December 2, 2022
+
+
+
High availability and fault tolerance are key components of a well-architected solution. It’s always best to prepare for the unexpected and having an emergen...
How to deploy a highly available multi-region web app
+
+
+
+
+
+
+
+
+ 32 minute read
+
+
+
+ • By Jordan Selig
+
+ • December 2, 2022
+
+
+
+
+
+
+
+
+
High availability and fault tolerance are key components of a well-architected solution. It’s always best to prepare for the unexpected and having an emergency plan that can shorten downtime and keep your systems up an running automatically when something fails can help you do that.
+
+
When you deploy your application to the cloud, you choose a region in that cloud where your application infrastructure is based. Regions are essentially data centers is various parts of the world. In a world where unpredictable severe weather events, natural disasters, or human errors are inevitable, there’s the imminent possibility of events that may disturb the functionality of a region or take it down altogether for a period of time. If your application is deployed to a single region, and the region becomes unavailable, your application will also be unavailable. This may be unacceptable under the terms of your application’s SLA. If so, deploying your application and its services across multiple regions is a good idea. A multi-region deployment can use an active-active or active-passive configuration. An active-active configuration distributes requests across multiple active regions. An active-passive configuration keeps warm instances in the secondary region, but doesn’t send traffic there unless the primary region fails. For multi-region deployments, we recommend deploying to paired regions. For more information on this topic, see Architect Azure applications for resiliency and availability.
+
+
In this blog post, we’ll walk through deploying a highly available multi-region web app. We’ll start with deploying the necessary infrastructure, and then move into managing the application source code. We’ll have a look at some of the different offerings Azure provides to enable this architecture as well as go over best practices and recommendations. We’ll keep the scenario simple by restricting our application components to just a web app, but the info shared here can definitely be expanded and applied to many other infrastructure patterns. For example, if your application connects to an Azure database offering or storage account, a quick search through the Azure docs will reveal built-in solutions as active geo-replication for SQL databases and redundancy options for storage accounts. For a reference architecture for a more detailed scenario, see Highly available multi-region web application.
+
+
Architecture
+
+
+
+
Workflow
+
+
The architecture is shown in the diagram above.
+
+
+
Primary and secondary regions. This architecture uses two regions to achieve higher availability. The application is deployed to each region. During normal operations, network traffic is routed to the primary region. If the primary region becomes unavailable, traffic is routed to the secondary region.
+
Front Door. Front Door routes incoming requests to the primary region. If the application running in that region becomes unavailable, Front Door fails over to the secondary region.
+
+
+
There are several general approaches to achieve high availability across regions. This reference focuses on active/passive with hot standby. It replicates the infrastructure in the secondary region, however traffic only goes to the primary region. If something happens in the primary region, traffic will automatically divert to the secondary region.
+
+
Recommendations and considerations
+
+
Your requirements might differ from the architecture described here, however you can use the recommendations and considerations in this section as a starting point as they apply to almost all multi-region scenarios. The considerations come from the Microsoft Azure Well-Architected Framework, which is a set of guiding tenets that can be used to improve the quality of a workload.
+
+
Regional pairing
+
+
Deciding on your primary region is relatively straightforward - pick the region that supports the features you’re using and is closest to you/your customers to reduce latency. When deciding on your secondary region, consider using the region Azure paired with your primary.
+
+
Resource groups
+
+
Consider placing the primary region, secondary region, and Front Door into separate resource groups. This lets you manage the resources deployed to each region as a single collection.
+
+
Front Door configuration
+
+
+
Routing. Front Door supports several routing mechanisms. We will be using priority routing in the scenario here as described in the workflow. Other routing mechanisms can direct traffic based on pre-defined weighting or lowest latency. Consider cost when choosing a routing mechanism because for example if you decide to use priority routing, you can scale down your application in your secondary region and only scale up when traffic is directed to it.
+
Tier. Azure Front Door is offered in a variety of flavors including the Standard and Premium tiers as well as Azure Front Door (classic). For a comparison of the various tiers, see the Front Door tier overview. We will be using the standard tier in the scenario here.
+
Load balancing options. Azure provides multiple load balancing options to help direct traffic for your applications. Choosing the most appropriate one for your scenario can be based on a number of factors including traffic type, cost, features, and limitations. To help you decide, see the Decision tree for load balancing in Azure. We will be using Azure Front Door for this scenario because we are deploying an internet facing web application (HTTP/HTTPS) deployed to multiple regions hosted on App Service.
+
Reliability. Azure Front Door automatically fails over if the primary region becomes unavailable. When Front Door fails over, there is a period of time (usually about 20-60 seconds) when clients cannot reach the application. The duration is affected by the frequency of health probes and sample size configuration. For more information on Front Door reliability, see Azure Front Door reliability.
+
+
+
Infrastructure deployment
+
+
Consider configuring a continuous deployment mechanism to manage your application source code as well as application infrastructure. Since you’re deploying resources in different regions, you’ll need to independently manage those resources. To ensure the resources are in sync and assuming you want essentially identical applications and infrastructures in each region, infrastructure as code (IaC) such as Azure Resource Manager templates or Terraform should be used with deployment pipelines such as Azure DevOps pipelines or GitHub Actions. This way, if configured appropriately, any change to resources or source code would trigger updates across all regions you’re deployed to. See Continuous deployment to Azure App Service for recommendations on how to manage your source code. We’ll go over in detail how to do this for a multi-region deployment later on in this post.
+
+
Security
+
+
For this scenario, you’ll want to ensure the only principal that can access your applications is Front Door. Front Door’s features work best when traffic only flows through Front Door. You should configure your origin to block traffic that hasn’t been sent through Front Door. Otherwise, traffic might bypass Front Door’s web application firewall, DDoS protection, and other security features. We’ll configure this as part of the tutorial later on in this post.
+
+
Additionally, for scenarios using App Services, consider locking down the SCM/advanced tools site as this site will not likely need to be reached through Front Door. You’ll likely want to set up access restrictions that only allow you to conduct your testing as well as enable continuous deployment from your tool of choice. We’ll go into more detail on how to do this during the tutorial later on in this post.
+
+
Lastly, for scenarios using App Services, consider disabling basic auth on App Service, which limits access to the FTP and SCM endpoints to users that are backed by Azure Active Directory (AAD). Disabling basic auth will require additional steps to configure continuous deployment. We’ll go through this as well later on in this post.
+
+
Cost optimization
+
+
Choose the Azure Front Door tier that meets your data transfer, routing, and security requirements. See Azure Front Door pricing for more details.
+
+
Additionally, if you’re using an active/passive multi-region deployment, consider scaling down your App Services in the secondary region and configuring autoscale rules to handle the traffic when traffic is re-directed there. For more details, see the App Service scaling docs.
+
+
Infrastructure deployment tutorial
+
+
In this tutorial, you’ll deploy the scenario shown in the workflow which includes two web apps behind Azure Front Door with access restrictions that only give Front Door direct access to the apps. We’ll use the Azure CLI to create the initial web apps and we’ll use the portal to create the Azure Front Door.
You’ll need two instances of a web app that run in different Azure regions for this tutorial. We’ll use the region pair East US/West US as our two regions and create two quick empty web apps. Feel free to choose you’re own regions or use existing web apps if you already have some deployed.
+
+
I’m going to use a single resource group for all resources to make management and clean-up simpler, however consider using separate resource groups for each region/resource as this will further isolate your resources.
+
+
Run the following command to create your resource group. Replace the placeholder for “resource-group-name”.
+
+
az group create --name <resource-group-name> --location eastus
+
+
+
Run the following commands to create the App Service plans. Replace the placeholders for App Service plan name and resource group name.
+
+
az appservice plan create --name <app-service-plan-east-us> --resource-group <resource-group-name> --is-linux--location eastus
+az appservice plan create --name <app-service-plan-west-us> --resource-group <resource-group-name> --is-linux--location westus
+
+
+
Once the App Service plans are created, run the following commands to create the web apps. Replace the placeholders and be sure to pay attention to the --plan parameter so that you place one app in each plan (and therefore each region).
Make note of the default host name of each web app so you can define the backend addresses when you deploy the Front Door in the next step. It should be in the format <web-app-name>.azurewebsites.net. This can be found by running the following command or by navigating to the app’s Overview page in the Azure portal.
+
+
az webapp show --name <web-app-name> --resource-group <resource-group-name> --query"hostNames"
+
+
+
Disable basic auth for the web apps
+
+
To disable FTP access to the site, run the following CLI command. Replace the placeholders with your resource group and site name. Be sure to run this command for each of your apps.
To disable basic auth access to the WebDeploy port and SCM site, run the following CLI command. Replace the placeholders with your resource group and site name.
I’m going to use the portal to create the Front Door since it will help us visualize the various components, however the CLI or templates can just as easily be used.
+
+
Front Door will be configured with priority routing where East US will be our primary region and West US will be the secondary. We’ll use the standard tier which gives us the option to use a Web Application Firewall (WAF) policy for enhanced security.
+
+
+
From the home page or the Azure menu in the portal, select + Create a resource. Search for ”Front Door and CDN profiles”. Then select Create.
+
+
On the Compare offerings page, select Custom create. Then select Continue to create a Front Door.
+
+
+
+
+
On the ”Basics” tab, enter the following information:
+
+
+
+
+
Setting
+
Description
+
+
+
+
+
Subscription
+
select your subscription
+
+
+
Resource group
+
<resource-group-name>
+
+
+
Name
+
<unique-name>
+
+
+
Tier
+
Standard
+
+
+
+
+
In the “Endpoint” tab, select Add an endpoint and give your endpoint a globally unique name.
+
Next, select + Add a route to configure routing to your Web App origin.
+
+
On the Add a route page, enter the following information and select Add to add the route to the endpoint configuration.
+
+
+
+
+
+
+
Setting
+
Description
+
+
+
+
+
Name
+
Enter a name to identify the mapping between domains and origin group.
+
+
+
Domains
+
A domain name has been auto-generated for you to use. If you want to add a custom domain, select Add a new domain. This example will use the default.
+
+
+
Patterns to match
+
Set all the URLs this route will accept. This example will use the default, and accept all URL paths.
+
+
+
Accepted protocols
+
Select the protocol the route will accept. This example will accept both HTTP and HTTPS requests.
+
+
+
Redirect
+
Enable this setting to redirect all HTTP traffic to the HTTPS endpoint.
+
+
+
Origin group
+
Select Add a new origin group. For the origin group name, enter myOriginGroup. Then select + Add an origin. For the first origin (primary region), enter the name of one of the web apps you’re using for this tutorial for the Name and then for the Origin Type select App Services. For the Host name, select the hostname you queried/found in the portal earlier. Leave the rest of the default values the same. Select Add to add the origin to the origin group. Repeat the steps to add the second web app as an origin, however when adding the second origin, set the Priority to “2”. This will direct all traffic to the primary origin unless the primary goes down. Once both web app origins have been added, select Add to save the origin group configuration.
+
+
+
Origin path
+
Leave blank.
+
+
+
Forwarding protocol
+
Select the protocol that will be forwarded to the origin group. This example will match the incoming requests to origins.
+
+
+
Caching
+
Select the check box if you want to cache contents closer to your users globally using Azure Front Door’s edge POPs and the Microsoft network.
+
+
+
Rules
+
Once you’ve deployed the Azure Front Door profile, you can configure Rules to apply to your route.
+
+
+
+
+
Select + Add a policy to apply a Web Application Firewall (WAF) policy to one or more domains in the Azure Front Door profile.
+
On the Add security policy page, enter a name to identify this security policy. Then select domains you want to associate the policy with. For WAF Policy, you can select a previously created policy or select Create New to create a new policy. Select Save to add the security policy to the endpoint configuration.
+
Select Review + Create, and then Create to deploy the Azure Front Door profile. It will take a few minutes for configurations to be propagated to all edge locations.
+
+
+
Restrict access to web apps to the Azure Front Door instance
+
+
Traffic from Azure Front Door to your application originates from a well known set of IP ranges defined in the AzureFrontDoor.Backend service tag. By using a service tag restriction rule, you can restrict traffic to only originate from Azure Front Door.
+
+
Before setting up the App Service access restriction, take note of the Front Door ID which can be found on the Overview page for the Front Door instance in the Essentials section. This will be needed to ensure traffic only originates from your specific Front Door instance by further filtering the incoming requests based on the unique http header that your Azure Front Door sends.
+
+
For your first web app, navigate to the Access restriction (preview) page.
+
+
+
+
For the Main site add the following rule. Insert the Front Door ID which you copied earlier under X-Azure-FDID.
+
+
+
+
Be sure to repeat these same steps for the other web app.
+
+
Lock down SCM/advanced tool site
+
+
Earlier on when you were creating the web apps, you disabled basic authentication to the WebDeploy port and SCM site. You’ll want to also disable all public access to the SCM site. Doing this, however, limits how code can be deployed to your app. Later on, we’ll walk through how to give a service principal access to deploy your source code. To disable public access, navigate to the Access restriction (preview) page for your app and select the Advanced tool site tab. For the Unmatched rule action, select “Deny” and then Save. Repeat this process for the other app.
+
+
You can optionally configure access restrictions to the SCM site as well for the app if you need to give other principals access. To do so, navigate to the Advanced tool site tab and add any needed rules. The access restrictions you apply to the SCM site will depend on how you’re managing and deploying your source code and conducting your testing.
+
+
Verify Azure Front Door
+
+
To confirm access to your apps is restricted to Front Door, try navigating to your apps directly using their endpoints. If you are able to access them, review their access restrictions and ensure access is limited to only Front Door.
+
+
Now that a couple minutes have passed since the Front Door instance has been created, it should be ready and deployed globally. In a browser, enter the endpoint hostname for the Front Door. This endpoint can be found on the Overview page for your Front Door. If everything has been configured correctly, you should be reaching your app in your primary region.
+
+
You can test failover by stopping the app in your primary region and then navigating to your Front Door endpoint again. Note that there may be a delay between when the traffic will be directed to the second web app depending on your health probe frequency. You may need to refresh the page a couple times. Try stopping the second web app as well and you should see an error page. This proves it redirected to the secondary region.
+
+
Managing source code
+
+
At this point, you’ve provisioned all of the resources you need to run a highly available multi-region web app. All that’s left is deploying the actual web app source code as well as understanding how to keep the app updated across the various regions over time as changes and updates are made. As mentioned in the infrastructure deployment section, just like for your infrastructure, it’s a good idea to use a CI/CD tool to manage your source code as well so any changes you make can automatically get deployed across all instances of your app. If you don’t configure continuous deployment, you’ll need to manually update each app in each region every time there is a code change.
Select the Fork button in the upper right on the GitHub page.
+
Select the Owner and leave the default Repository name.
+
Select Create fork.
+
+
+
At this point, your source code is all set up and ready to be deployed to your apps.
+
+
Configure the deployment source
+
+
You’ll need to update your app’s stack settings to match the source code if you’ve been following along in this tutorial.
+
+
+
Go to one of your apps.
+
In the left pane, select Configuration and then select the General settings tab.
+
Under Stack settings, set the Stack to “.NET” and the .NET version to “.NET 6 (LTS)”.
+
Select Save and then Continue to confirm the update.
+
Repeat the above steps for your other app.
+
+
+
As mentioned earlier, since you locked down the SCM site and disabled basic auth, the default method for deploying code with GitHub Actions isn’t going to work. This is because the default method uses a publishing profile. Instead, you have two options to authenticate with App Service for GitHub Actions - using a service principal or OpenID Connect. We have a detailed doc that goes through how to do this for each of your options - Deploy to App Service using GitHub Actions. We also have guidance for Azure DevOps using Azure Pipelines. Additionally, for more info on this topic as well as additional examples, we have a series of blog posts that walk through scenarios you may be interested in.
For this blog post, we’ll walk through how to authenticate with App Service for GitHub Actions with the most secure option, which is OpenID Connect. You can choose to use a service principal which follows the same general process but omits a couple steps.
+
+
Configure authentication with App Service for GitHub Actions with OpenID Connect
+
+
+
+
Run the following command to create the Active Directory application.
+
+
az ad app create --display-name myApp
+
+
+
This command will output JSON with an appId. Copy this, you’ll need it in the next step.
+
+
+
Run the following command to create a service principal. Replace the appId placeholder with the value you copied in the previous step.
+
+
az ad sp create --id <appId>
+
+
+
You’ll now need to create a new role assignment for your newly created service principal so that it has access to your resources. You’ll need to grant access at the subscription level and give it the “Contributor” role. You can scope the role assignment down further based on your use case. To create this role assignment, search for “Subscriptions” in the search box at the top of the portal and select your subscription.
+
Select Access Control (IAM) in the left-hand menu.
+
Select + Add at the top and then Add role assignment.
+
Select the Contributor role and then go to the Members tab.
+
Select + Select members and then find your service principal.
In the portal, search for in the search box and then go to App Registrations and then select the app you created earlier.
+
Select Certificates & secrets in the left-hand menu.
+
In the Federated credentials tab, select Add credential.
+
+
Select the credential scenario GitHub Actions deploying Azure resources. Generate your credential by entering your credential details.
+
+
+
+
+
Field
+
Description
+
Example
+
+
+
+
+
Organization
+
Your GitHub organization name or GitHub username.
+
contoso
+
+
+
Repository
+
Your GitHub Repository name.
+
dotnetcore-docs-hello-world
+
+
+
Entity type
+
The filter used to scope the OIDC requests from GitHub workflows. This field is used to generate the subject claim.
+
Branch
+
+
+
GitHub branch name
+
The name of the environment, branch, or tag.
+
master
+
+
+
Name
+
Identifier for the federated credential.
+
myCredential
+
+
+
+
+
+
+
You need to provide your application’s Client ID, Tenant ID, and Subscription ID to the login action as part of the GitHub Action workflow we will be working on. These values can either be provided directly in the workflow or can be stored in GitHub secrets and referenced in your workflow. Saving the values as GitHub secrets is the more secure option.
+
+
Open your GitHub repository and go to Settings > Security > Secrets and variables > Actions > New repository secret.
+
+
Create the following secrets. To find the values for Client ID and Tenant ID, go back to App Registrations in the portal and select the app you created earlier. The values will be under the Essentials on the Overview page.
+
+
+
+
+
Name
+
Value
+
+
+
+
+
AZURE_CLIENT_ID
+
<application/client-id>
+
+
+
AZURE_TENANT_ID
+
<directory/tenant-id>
+
+
+
AZURE_SUBSCRIPTION_ID
+
<subscription-id>
+
+
+
+
+
+
+
+
+
Deploy the code
+
+
You’re now ready to deploy the code. However, configuring continuous deployment for production apps is not recommended because it makes testing and validation more complicated. Instead, use a combination of staging slots and slot swap to move code from your testing environment to production.
+
+
We’ll create deployment slots for each instance of our app and then walk through how to slot swap to get the code into production.
+
+
+
Go to one of your apps.
+
In the left pane, select Deployment slots.
+
Select + Add Slot.
+
Input “stage” for Name and to keep things simple, we’ll clone the settings from the production slot by selecting the app’s name from the Clone settings from: dropdown.
+
Select Close at the bottom of the slot configuration pane.
+
Select the newly created stage slot.
+
+
In the left pane, select Deployment Center and make sure you’re on the Settings tab.
+
+
+
+
For Source, select “GitHub”.
+
If you’re deploying from GitHub for the first time, select Authorize and follow the authorization prompts.
+
+
After you authorize your Azure account with GitHub, select the Organization, Repository, and Branch to configure CI/CD as shown below. If you can’t find an organization or repository, you might need to enable more permissions on GitHub. For more information, see Managing access to your organization’s repositories.
+
+
+
+
+
Setting
+
Description
+
+
+
+
+
Organization
+
<your GitHub username>
+
+
+
Repository
+
dotnetcore-docs-hello-world
+
+
+
Branch
+
master
+
+
+
+
+
Leave the remaining defaults and select Save. You can track the deployment and commits in the Logs tab in the Deployment Center to monitor progress.
+
Repeat the above steps for your other app.
+
+
+
Create the GitHub Actions workflow
+
+
If you wait a couple minutes and review the deployment logs, you’ll see that the deployment to your apps failed. This is happening for two reasons - the default workflow created in the previous step when you were configuring continuous deployment with GitHub Actions uses a publishing profile to authenticate and you disabled this level of access, and the access restrictions for the SCM site for your staging slot deny all traffic. You first need to update the unmatched rule action for the Advanced tool site just for your staging slots to “Allow”. You’ve already disabled basic auth to your SCM site so access to it is already restricted to Azure AD authenticated principals. Allowing traffic using the access restrictions allows GitHub to reach your app and deploy your code. If you’re using GitHub Enterprise or another privately hosted source code repo, you can define specific access restrictions for your IP ranges instead. You then need to edit the GitHub Actions workflow as shown below so that it uses your OpenID Connect credentials instead of the publish profile. For sample workflows, see the OpenID Connect tab in Deploy to App Service. If you’ve been following along, use the below workflow.
+
+
+
Open your GitHub repository and go to the dotnetcore-docs-hello-world/.github/workflows/ directory. You’ll see two autogenerated workflows, one for each app you created. Repeat the next step for each of them.
+
+
Select the “pencil” button in the top right to edit the file. Replace the contents with the below, which assumes you created the GitHub secrets earlier, update the placeholder for AZURE_WEBAPP_NAME for your apps, and then commit directly to the master branch. This commit will trigger the GitHub Action to run again and deploy your code, this time using OpenID Connect to authenticate.
+
+
name:.NET Core
+
+ on:
+ push:
+ branches:
+ -master
+ workflow_dispatch:
+
+ permissions:
+ id-token:write
+ contents:read
+
+ env:
+ AZURE_WEBAPP_NAME:<web-app-name># set this to your application's name
+ AZURE_WEBAPP_PACKAGE_PATH:'.'# set this to the path to your web app project, defaults to the repository root
+ DOTNET_VERSION:'6.0.x'# set this to the dot net version to use
+
+ jobs:
+ build:
+ runs-on:ubuntu-latest
+
+ steps:
+ # Checkout the repo
+ -uses:actions/checkout@main
+ -uses:azure/login@v1
+ with:
+ client-id:${{ secrets.AZURE_CLIENT_ID }}
+ tenant-id:${{ secrets.AZURE_TENANT_ID }}
+ subscription-id:${{ secrets.AZURE_SUBSCRIPTION_ID }}
+
+ # Setup .NET Core SDK
+ -name:Setup .NET Core
+ uses:actions/setup-dotnet@v1
+ with:
+ dotnet-version:${{ env.DOTNET_VERSION }}
+
+ # Run dotnet build and publish
+ -name:dotnet build and publish
+ run:|
+ dotnet restore
+ dotnet build --configuration Release
+ dotnet publish -c Release -o '${{ env.AZURE_WEBAPP_PACKAGE_PATH }}/myapp'
+
+ # Deploy to Azure Web apps
+ -name:'RunAzurewebappdeployactionusingpublishprofilecredentials'
+ uses:azure/webapps-deploy@v2
+ with:
+ app-name:${{ env.AZURE_WEBAPP_NAME }}
+ slot-name:'stage'# replace with your slot name
+ package:'${{env.AZURE_WEBAPP_PACKAGE_PATH}}/myapp'
+
+ -name:logout
+ run:|
+ az logout
+
+
+
+
+
After a couple minutes, once the deployments to the staging slots complete, if you try accessing your slot’s endpoint directly, you’ll receive an “Error 403 - Forbidden” because the access restrictions were cloned from the production site. There are a couple strategies that can be used to review the staging site and then eventually get it into production. To quickly validate that your staging site is working, you can temporarily update its access restrictions by adding your IP to the allow list for example and then attempt to reach it’s endpoint again. Be sure to remove that rule once you are done validating. Alternatively, if you don’t plan on using slot traffic routing as described in the next section, you can update the access restrictions to meet your testing specifications.
+
+
Since your Front Door is still pointing to your production apps, if you go to your Front Door’s endpoint now, you’ll still see the initial empty apps that were created earlier. You have a couple options here - you can either slot swap and your new code will move into production all at once, or you can try a variation of A/B testing using slot traffic routing. We’ll go over both of these features.
+
+
Slot traffic routing
+
+
Traffic routing with slots allows you to direct a pre-defined portion of your user traffic to each slot. Initially, 100% of traffic is directed to the production site. However, you have the ability, for example, to send 10% of your traffic to your staging slot. So when users try to access your app, 10% of them will automatically be routed there. No changes are needed on your Front Door instance to accomplish this. To learn more about slot swaps and staging environments in App Service see Set up staging environments in Azure App Service.
+
+
+
+
If you want to validate this feature as part of this tutorial, it will take some trial and error. The best way to validate it would be to send 100% of the traffic to the staging slot and then go the Front Door endpoint. You may need to clear your browser’s cache, refresh the page, or purge Front Door’s cache if you’re still not seeing your deployed changes.
+
+
+
+
Slot swap
+
+
Once you’re done testing and validating, you can perform a slot swap from your staging site to your production site. You’ll need to do this for both instances of you app. During a slot swap, the App Service platform ensures the target slot doesn’t experience downtime.
+
+
To perform the swap:
+
+
+
+
Go to your app’s Deployment slots page and select Swap. The Swap dialog box shows settings in the selected source and target slots that will be changed.
+
+
+
+
+
Select the desired Source and Target slots. Also, select the Source Changes and Target Changes tabs and verify that the configuration changes are expected. When you’re finished, you can swap the slots immediately by selecting Swap.
+
+
+
+
+
Repeat the process for your other app.
+
+
+
+
After a few minutes, you can navigate to your Front Door’s endpoint to validate the slot swap succeeded. Ensure you reset the slot traffic routing if needed. You may need to clear your browser’s cache, refresh the page, or purge Front Door’s cache if you’re still not seeing your deployed changes.
+
+
At this point, your apps are up and running and any changes you make to your source code will automatically trigger an update to both of your staging apps. You can then repeat the slot swap process described above when you’re ready to move that code into production.
+
+
Additional guidance
+
+
If you’re concerned about potential disruptions or issues with continuity across regions, as in some customers seeing one version of your app while others see another, or if you’re making significant changes to your apps, you can temporarily remove the site that’s undergoing the slot swap from your Front Door’s origin group and all traffic will be directed to the other origin. To do this, navigate to the Update origin group pane as shown below and Delete the origin that is undergoing the change. Once you’ve made all of your changes and are ready to serve traffic there again, you can return to the same pane and select + Add an origin to re-add the origin.
+
+
+
+
If you’d prefer to not delete and then add re-add origins, you can create additional origin groups for your Front Door instance. You can then associate the route to the origin group pointing to the intended origin. For example, you can create two new origin groups, one for your primary region and one for your secondary region. When your primary region is undergoing a change, associate the route with your secondary region and vice versa when your secondary region is undergoing a change. When all changes are complete, you can associate the route with your original origin group which contains both regions. This method works because a route can only be associated with one origin group at a time. However, if you have many regions and apps, it will get messy since you’ll need one origin group per region and potentially additional origin groups if you have multiple apps.
+
+
To demonstrate working with multiple origins, in the screenshot below, there are three origin groups. “MyOriginGroup” consists of both web apps, and the other two origin groups each consist of the web app in their respective region. In the example here, the app in the primary region is undergoing a change, so before I started that change, I associated the route with “MySecondaryRegion” so all traffic would be sent to the app in my secondary region during the change period. You can update the route by selecting “Unassociated” which will bring up the Associate routes pane.
+
+
+
+
Clean up resources
+
+
After you’re done, you can remove all the items you created. Deleting a resource group also deletes its contents. If you don’t intend to use this Azure Front Door, you should remove these resources to avoid unnecessary charges.
+
+
Next steps
+
+
If you’re interested in learning about another web app pattern for n-tier web applications, see the next post in this series called How to deploy a secure n-tier web app.
+
+
Zone redundancy is another infrastructure pattern that can provide high availability by replicating your services and data across availability zones to protect against single points of failure. For a detailed reference architecture on this for App Service, see Highly available zone-redundant web application.
+
+
Deploy from ARM/Bicep
+
+
All of the resources in this post can be deployed using an ARM/Bicep template. A sample template is shown below, which creates empty apps and staging slots behind Front Door following the security best practices outlined in this post. You’ll need to configure the deployment source as well as the service principal once the template resources are created. To learn how to deploy ARM/Bicep templates, see How to deploy resources with Bicep and Azure CLI.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 24 minute read
+
+
+
+ • By Jordan Selig
+
+ • December 2, 2022
+
+
+
+
+
+
+
+
+
Many applications will consist of more than just a single component. For example, you may have a frontend which is publicly accessible that connects to a backend database, storage account, key vault, another VM, or a combination of these, which make up what’s known as an n-tier application. It’s important that applications like this are architected so that access is limited to privileged individuals and any component that is not intended for public consumptions is locked down to the greatest extent available for your use case.
+
+
In this blog post, we’ll walk through setting up a web app with a secure, network-isolated communication to a backend web app. All traffic will be isolated within your virtual network using virtual network integration and private endpoints. This configuration can be used for a number of use cases and it’s architecture can be extended or modified, for example in this blog post where a web app securely connects to a backend cognitive service that detects the language of input text. For more information on n-tier applications including additional scenarios and multi-region considerations, see Multi-region N-tier application. Also, see the Reliable Web App Pattern for additional context and details on deploying more complex scenarios.
+
+
This scenario is intentionally kept simple to focus on the key concepts of the architecture and configuration since they are reusable and can easily be replicated across many application patterns. We’ll also be diving into secure source code deployment best practices which is a key part of web app management.
+
+
This post is organized into the following steps:
+
+
+
Create network infrastructure
+
Create backend web app
+
Create frontend web app
+
Deploy application source code
+
+
+
Architecture
+
+
+
+
Workflow
+
+
The architecture is shown in the diagram above.
+
+
+
Frontend web app. This architecture uses two web apps - a frontend that is accessible over the public internet, and a private backend web app. The frontend web app is integrated into the virtual network in the subnet with the feature regional VNet integration and it is configured to consume a DNS private zone.
+
Backend web app. The backend web app is only exposed through a private endpoint via another subnet in the virtual network. Direct communication to the backend web app is explicitly blocked. The only resource or principal that is allowed to connect to the backend is the frontend web app using the private endpoint.
+
+
+
Note that virtual network integration and private endpoints are now available all the way down to the Basic SKU. App Services using the Free tier don’t support this at this time.
+
+
Getting started
+
+
This is the second article in a series focusing on App Service patterns. If you missed the first one on secure multi-region deployments, you can find it here.
+
+
This guide will use the Azure CLI to set up the environment and deploy the web apps. Additional configurations will be done using the Azure portal as it is easier to demonstrate what is going on there. Keep in mind that everything that is being done in this blog post can be done using the Azure CLI, Azure PowerShell, Azure portal, and Azure Resource Manager (ARM) templates. A complete ARM template that deploys the core resources in this post is given at the end of this post.
First, set up a Resource Group with a Virtual Network. The virtual network should have at least two subnets: one for the virtual network integration and one for the private endpoint. The address-prefix size must be at least /28 for both subnets; small subnets can affect scaling limits and the number of private endpoints. Go with /24 for both subnets if you are not under constraints. Be sure to replace the placeholders for resource group name and virtual network name.
+
+
az group create --name <resource-group-name> --location eastus
+az network vnet create --resource-group <resource-group-name> --location eastus --name <vnet-name> --address-prefixes 10.0.0.0/16
+
+
+
For the subnets, there are two settings that you need to pay attention to. This is often set by the portal or scripts, but here it is called out directly. A delegation of “Microsoft.Web/serverfarms” informs the subnet that it’s reserved for virtual network integration.
The last part of the network infrastructure is the Private DNS Zone. Private DNS Zones are used to host the DNS records for private endpoints allowing clients to find the backend services by name. We’ll be creating the private endpoint using the portal, so the Private DNS Zone will be created automatically for us. Go here for a primer on Azure Private Endpoints and go here for how DNS Zones are used with private endpoints.
+
+
Create two instances of a web app
+
+
You’ll need two instances of a web app for this tutorial. You’ll need to use at least the Basic SKU in order to be able to use virtual network integration and private endpoints. You’ll take care of the vnet integration and additional configurations later on - first you’ll get the apps deployed. You’ll first deploy a single App Service plan. You’ll then deploy two web apps in that App Service plan.
+
+
Run the following command to create the App Service plan. Replace the placeholders for App Service plan name and resource group name.
+
+
az appservice plan create --name <app-service-plan-name> --resource-group <resource-group-name> --is-linux--location eastus --sku P1V2
+
+
+
Once the App Service plan is created, run the following commands to create the web apps. Replace the placeholders with your globally distinct web app names and your App Service plan name. If you’re following along in this tutorial, you’ll be deploying a Node.js app later on, so we’ll set the runtime now. Feel free to change this value based on the app you want to deploy. Run az webapp list-runtimes for a list of the possible runtimes you can choose from.
Consider disabling basic auth on App Service, which limits access to the FTP and SCM endpoints to users that are backed by Azure Active Directory (AAD). Disabling basic auth will require additional steps to configure continuous deployment. We’ll go through this as well later on in this post.
+
+
To disable FTP access to the site, run the following CLI command. Replace the placeholders with your resource group and site name. Be sure to run this command for each of your apps.
To disable basic auth access to the WebDeploy port and SCM site, run the following CLI command. Replace the placeholders with your resource group and site name.
Configure virtual network integration for the frontend web app
+
+
The virtual network integration feature allows outbound traffic to flow directly into the virtual network. We’ll use the portal to configure this as well as the private endpoint in the next step.
+
+
+
In the Azure portal, go to your frontend web app and then go to the Networking page.
+
+
Select VNet Integration.
+
+
+
+
Select + Add VNet.
+
Select the virtual network you created earlier.
+
For Subnet, select “Select Existing” and then select the “vnet-integration-subnet”.
+
Select OK to save your configuration.
+
+
+
You can now browse to the web app and all outbound traffic from the frontend web app will be routed through the virtual network.
+
+
Create the private endpoint for the backend web app
+
+
The last part of the core infrastructure setup is to create the private endpoint to allow secure communication between your frontend and your backend. Adding a private endpoint by default disables all public access to your app. By enabling a private endpoint on your backend web app, all inbound traffic will therefore use the private endpoint to reach it. The only resources that are allowed to use the private endpoint to connect to your backend web app are the ones in your virtual network.
+
+
+
In the Azure portal, go to your backend web app and then go to the Networking page. Under Inbound address, you’ll see the public IP that was automatically delegated to your web app. Note that when you add the private endpoint, this will change to a private IP from your Azure virtual network address space.
+
+
Select Private endpoints.
+
+
+
+
Select + Add.
+
Give your private endpoint a name, select the virtual network you created earlier, and select the “private-endpoint-subnet”.
+
Make sure Integrate with private DNS zone is set to “Yes”. If you want to set up your own Private DNS Zone, you can find details for that here.
+
Select OK to save your configuration.
+
+
+
Creating the private endpoint from the portal is the simplest method as it does a number of actions in the background for you including linking the zone to your virtual network. If you create the Private DNS Zone manually, you will need to create the link manually.
+
+
If you go back to the Networking page for your backend web app, you’ll see that the inbound address has changed to a private IP address from your virtual network. You’ll also see that access restrictions have turned on. If you view the Access restriction (preview), you see public access has been disabled. Disabling public network access blocks all incoming traffic except the traffic that comes from private endpoints.
+
+
+
+
+
+
Lock down SCM/advanced tool site
+
+
Earlier on when you were creating the web apps, you disabled basic authentication to the WebDeploy port and SCM site. You’ll want to also disable all public access to the SCM site. This has already been done for the backend web app when you added the private endpoint. You will only need to do this for the frontend web app. Doing this, however, limits how code can be deployed to your app. Later on, we’ll walk through how to give a service principal access to deploy your source code. To disable public access, navigate to the Access restriction (preview) page for your frontend web app and select the Advanced tool site tab. For the Unmatched rule action, select “Deny”, then Save, and Continue. You can’t deny all public access using the checkbox at the top because that will deny public access to your frontend’s main site as well. Doing this would prevent your users from being able to access your frontend which is not what we want.
+
+
+
+
Checkpoint
+
+
At this point, all of the baseline infrastructure has been deployed and you are ready to deploy your source code. We’ll walk through how to do that securely in the next part of the blog post, but first, let’s validate our connections and app access.
+
+
Starting with the backend, try navigating directly to your backend’s endpoint. This can be found on the Overview page for the backend web app and should be in the format https://backend-web-app-name.azurewebsites.net. If you’ve configured things correctly, public access should be blocked and you should get an error page.
To validate the frontend, we’ll need to ensure it is publicly accessible and that it can reach the backend only using the private endpoint.
+
+
Try navigating to your frontend’s endpoint. You should see content similar to what is shown below. This means your frontend is publicly accessible and ready for your source code as intended. Try navigating to your frontend’s SCM site as well and confirm that access is denied.
+
+
+
+
To validate the connection between the frontend and the backend, you’ll need access to the SCM site. For this, the simplest method if you’ve been following along is you can add a temporary rule to your frontend’s access restrictions that allows access from your IP. See the below screenshot for an example. For source, use your IP address.
+
+
+
+
Navigate to the SCM site for your frontend by going to https://frontend-web-app-name.scm.azurewebsites.net/. If you can’t access it, make sure you’ve added the rule for your IP as shown above. Select SSH from the menu bar at the top. Doing this creates an SSH session on your frontend’s instances. Once that loads, you’re going to do an “nslookup” on your backend to confirm that it can be reached from the frontend using the private endpoint. Type “nslookup backend-web-app-name.azurewebsites.net”. Under the “Non-authoritative answer”, it should resolve the private IP address you noted earlier. You can also do a “curl” on your backend’s endpoint to display the backend’s current site contents. For now, curl will display the HTML for the empty web app.
+
+
+
+
Repeat the same nslookup and curl commands from another terminal (one that is not an SSH session from your frontend’s instances). The nslookup will return the public IP for the backend web app. Since we blocked public access to the backend web app, if you try to reach the public IP, you will get an access denied error which means this site will not be accessible from the public internet, which is what we want. The nslookup doesn’t resolve the private IP because that can only be reached from within the virtual network using the private endpoint and only the frontend web app is within the virtual network. If you try to do a curl on the backend from an external terminal, you’ll see the HTML returns “Web App - Unavailable”, which is the HTML for the error page you saw earlier when you tried navigating to the backend in your browser.
+
+
+
+
Now that you’ve validated your connections, you’re all set to deploy some code. Make sure you remove the rule that allows access to your frontend’s SCM site if you no longer need it.
+
+
Source code management
+
+
A number of best practices were described in the previous blog post, which went over how to manage source code across multiple regions. Those same concepts can be applied here. For completeness, we’ll go over the important parts to get your n-tier app up and running.
+
+
Prerequisites for source code deployment
+
+
We’ll be using a two Node.js apps hosted on GitHub. If you don’t already have a GitHub account, create an account for free.
Select the Fork button in the upper right on the GitHub page.
+
Select the Owner and leave the default Repository name.
+
Select Create fork.
+
Repeat the same process for the Node.js frontend sample app. This is a basic web scraping app that I built specifically for this blog post.
+
+
+
At this point, your source code is all set up and ready to be deployed to your apps.
+
+
Create staging slots and configure continuous deployment
+
+
Configuring continuous deployment for production apps is not recommended because it makes testing and validation more complicated. Instead, use a combination of staging slots and slot swap to move code from your testing/staging environment to production.
+
+
We’ll create deployment slots for each of our apps and then walk through how to slot swap to get the code into production.
+
+
+
Go to one of your apps.
+
In the left pane, select Deployment slots.
+
Select + Add Slot.
+
Input “stage” for Name and to keep things simple, we’ll clone the settings from the production slot by selecting the app’s name from the Clone settings from: dropdown.
+
Select Close at the bottom of the slot configuration pane.
+
Select the newly created stage slot.
+
+
+
Cloning settings to a slot doesn’t clone every possible setting. In this case, depending on how you’ll be using the slots, you’ll need to disable basic auth for both app slots, create another private endpoint for the backend slot, and implement virtual network integration for the frontend slot. The process for this is the same as before. Pay attention to the access restrictions on the SCM sites if you do recreate the private endpoint as that will disable public access to it and prevent GitHub from reaching your staging slots. You’ll need to allow public access to the Advanced tools site as was done in the previous blog post.
+
+
To disable basic auth for the slots, make sure you update the --parent parameter as shown in the below example. Repeat the same command for “ftp” and for your other app as you did previously.
Now that the staging slots are properly configured and locked down, you can configure continuous deployment.
+
+
+
+
In the left pane, select Deployment Center and make sure you’re on the Settings tab.
+
+
+
+
For Source, select “GitHub”.
+
If you’re deploying from GitHub for the first time, select Authorize and follow the authorization prompts.
+
+
After you authorize your Azure account with GitHub, select the Organization, Repository, and Branch to configure CI/CD as shown below. If you can’t find an organization or repository, you might need to enable more permissions on GitHub. For more information, see Managing access to your organization’s repositories.
+
+
+
+
+
Setting
+
Description
+
+
+
+
+
Organization
+
<your GitHub username>
+
+
+
Repository
+
nodejs-backend
+
+
+
Branch
+
main
+
+
+
+
+
Leave the remaining defaults and select Save. You can track the deployment and commits in the Logs tab in the Deployment Center to monitor progress.
+
Repeat the above steps for your other app.
+
+
+
Since you locked down the SCM sites and disabled basic auth for your apps, the default method for deploying code with GitHub Actions isn’t going to work. You’ll see that the deployment failed if you review the logs. This is because the default method uses a publishing profile. Instead, you have two options to authenticate with App Service for GitHub Actions - using a service principal or OpenID Connect. We have a detailed doc that goes through how to do this for each of your options - Deploy to App Service using GitHub Actions. We also have guidance for Azure DevOps using Azure Pipelines. Additionally, for more info on this topic as well as additional examples, we have a series of blog posts that walk through scenarios you may be interested in.
For this blog post, we’ll walk through how to authenticate with App Service for GitHub Actions using a service principal.
+
+
Configure authentication with App Service for GitHub Actions with a service principal
+
+
+
+
Run the following command to create the service principal. Replace the placeholders with your subscription ID, resource group name, and frontend and backend app names. The output is a JSON object with the role assignment credentials that provide access to your App Service apps. Copy this JSON object for the next step. It will include your client secret which will only be visible at this time. It is always a good practice to grant minimum access. The scope in this example is limited to the specific frontend and backend web apps and not the entire resource group.
+
+
az ad sp create-for-rbac --name"myApp"--role contributor --scopes /subscriptions/<subscription-id>/resourceGroups/<group-name>/providers/Microsoft.Web/sites/<frontend-web-app-name> /subscriptions/<subscription-id>/resourceGroups/<group-name>/providers/Microsoft.Web/sites/<backend-web-app-name> --sdk-auth
+
+
+
+
You need to provide your service principal’s credentials to the login action as part of the GitHub Action workflow you will be using. These values can either be provided directly in the workflow or can be stored in a GitHub secret and referenced in your workflow. Saving the values as GitHub secrets is the more secure option.
+
+
Open one of your GitHub repositories and go to Settings > Security > Secrets and variables > Actions > New repository secret.
+
Paste the entire JSON output from the Azure CLI command from the initial step into the secret’s value field. Give the secret the name AZURE_CREDENTIALS. When you configure the workflow file later, you use the secret for the input creds of the Azure Login action.
+
+
Create the following secrets.
+
+
+
+
+
Name
+
Value
+
+
+
+
+
AZURE_APP_ID
+
<application/client-id>
+
+
+
AZURE_PASSWORD
+
<client-secret>
+
+
+
AZURE_TENANT_ID
+
<tenant-id>
+
+
+
AZURE_SUBSCRIPTION_ID
+
<subscription-id>
+
+
+
+
+
Repeat this process for your other repository.
+
+
+
+
+
Create the GitHub Actions workflow
+
+
Now that you have a service principal that can access your App Services, you need to edit the default workflow that was created for your apps when you configured continuous deployment so that it uses your service principal to authenticate instead of the publishing profile. For sample workflows, see the “Service principal” tab in Deploy to App Service. If you’ve been following along, use the below workflow.
+
+
+
Open your backend app’s GitHub repository and go to the nodejs-backend/.github/workflows/ directory. You’ll see the autogenerated workflow.
+
+
Select the “pencil” button in the top right to edit the file. Replace the contents with the below, which assumes you created the GitHub secrets earlier for your credential, update the placeholders under “env”, and then commit directly to the main branch. This commit will trigger the GitHub Action to run again and deploy your code, this time using the service principal to authenticate.
+
+
+ name:Build and deploy Node.js app to Azure Web App
+
+ on:
+ push:
+ branches:
+ -main
+ workflow_dispatch:
+
+ env:
+ AZURE_WEBAPP_NAME:<web-app-name># set this to your application's name
+ NODE_VERSION:'18.x'# set this to the node version to use
+ AZURE_WEBAPP_PACKAGE_PATH:'.'# set this to the path to your web app project, defaults to the repository root
+ AZURE_WEBAPP_SLOT_NAME:stage# set this to your application's slot name
+
+ jobs:
+ build:
+ runs-on:ubuntu-latest
+
+ steps:
+ -uses:actions/checkout@v2
+
+ -name:Set up Node.js version
+ uses:actions/setup-node@v1
+ with:
+ node-version:${{ env.NODE_VERSION }}
+
+ -name:npm install, build
+ run:|
+ npm install
+ npm run build --if-present
+
+ -name:Upload artifact for deployment job
+ uses:actions/upload-artifact@v2
+ with:
+ name:node-app
+ path:.
+
+ deploy:
+ runs-on:ubuntu-latest
+ needs:build
+ environment:
+ name:'stage'
+ url:${{ steps.deploy-to-webapp.outputs.webapp-url }}
+
+ steps:
+ -name:Download artifact from build job
+ uses:actions/download-artifact@v2
+ with:
+ name:node-app
+
+ -uses:azure/login@v1
+ with:
+ creds:|
+ {
+ "clientId": "${{ secrets.AZURE_APP_ID }}",
+ "clientSecret": "${{ secrets.AZURE_PASSWORD }}",
+ "subscriptionId": "${{ secrets.AZURE_SUBSCRIPTION_ID }}",
+ "tenantId": "${{ secrets.AZURE_TENANT_ID }}"
+ }
+
+ -name:'DeploytoAzureWebApp'
+ id:deploy-to-webapp
+ uses:azure/webapps-deploy@v2
+ with:
+ app-name:${{ env.AZURE_WEBAPP_NAME }}
+ slot-name:${{ env.AZURE_WEBAPP_SLOT_NAME }}
+ package:${{ env.AZURE_WEBAPP_PACKAGE_PATH }}
+
+ -name:logout
+ run:|
+ az logout
+
+
+
Repeat this process for for the frontend app. The workflow can be found in nodejs-frontend/.github/workflows/.
+
+
+
After a couple minutes, the deployments to the two app’s staging slots will finish. Your backend web app slot is locked down, but you can update the access restrictions for it if you want to validate that the code was deployed. Alternatively, you can skip that and go straight to the frontend app slot and test from there.
+
+
Navigate to your frontend in a browser. The URL should look like https://frontend-web-app-name-stage.azurewebsites.net. The frontend app is a simple web scraper that will display the HTML body of a website. All it’s doing is calling the backend app and if it can reach the backend, it will display the site contents of the backend web app. I designed this site to work specifically with the provided backend web app. The web scraper will work with other sites, but the HTML it will return will be messy. Get your backend slot’s URL and paste that into the textbox. Hit “Go”, and after a couple seconds, you should see “Hello from the backend web app!” which is the site contents for the backend. If the app crashes, that means your access restrictions or private endpoint are misconfigured. If you didn’t set up the private endpoint and virtual network infrastructure for your slots, you can skip this testing as you’ve already validated it works in production. If all goes well, you’re ready to slot swap into production.
Go to your app’s Deployment slots page and select Swap. The Swap dialog box shows settings in the selected source and target slots that will be changed.
+
+
+
+
+
Select the desired Source and Target slots. Also, select the Source Changes and Target Changes tabs and verify that the configuration changes are expected. When you’re finished, you can swap the slots immediately by selecting Swap.
+
+
+
+
+
Repeat the process for your other app.
+
+
+
+
After a few minutes, you can navigate to your production frontend app to validate the slot swap succeeded. You should copy and paste your production backend app’s URL into the textbox and confirm you get the message “Hello from the backend web app!”. If you do, congrats, you completed the tutorial! If the app crashes, go back through this post to ensure your connections are configured properly.
+
+
At this point, your apps are up and running and any changes you make to your source code will automatically trigger an update to both of your staging apps. You can then repeat the slot swap process described above when you’re ready to move that code into production.
+
+
Clean up resources
+
+
After you’re done, you can remove all the items you created. Deleting a resource group also deletes its contents.
+
+
Deploy from ARM/Bicep
+
+
All of the resources in this post can be deployed using an ARM/Bicep template. A sample template is shown below, which creates empty apps following the security best practices outlined in this post. You’ll need to configure the slots and deployment source as well as the service principal once the template resources are created. To learn how to deploy ARM/Bicep templates, see How to deploy resources with Bicep and Azure CLI.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Improving the dump analysis journey in Diagnose and Solve
+
+
+
+
+
+
+
+
+ 4 minute read
+
+
+
+ • By Mark Downie, Puneet Gupta
+
+ • December 5, 2022
+
+
+
+
+
+
+
+
+
We are happy to announce that our most recent improvements to Diagnose and Solve Problems allow you to begin the analysis on a collected memory dump immediately in the Azure portal!
+
+
For problems that do not manifest in logs or that you cannot investigate by debugging locally, you might attempt to capture a diagnostics artifact, like a memory dump, while the issue is active in your production environment. Diagnostics tools found under Diagnose and Solve Problems have enabled you to capture artifacts like memory dumps on demand or by using Custom Auto Heal for both Linux and Windows.
+
+
However, capturing the right memory dump at the right time is only half the battle, you also have to have the right tools and experience to interpret the memory dump. Thankfully Diagnostics Analysis can be configured to run immediately following the capture of a memory dump. The analysis report will provide a summary of the most pertinent information in the memory dump, and will also highlight several important data points and even potential red flags that might require a code fix.
+
+
Analysis Report: The dump summary
+
+
The first step in the analysis is confirming the fundamentals. In the following image, you can see the summary presented by the analysis report, highlighting common helpful information like the process name, process architecture, or how long the process has been running. It also includes information on the platform version as well as the reason for the collection.
+
+
+
+
In future versions of the report, we will also support opening the memory dump in Visual Studio with one click (will require the appropriate permissions to the Azure storage location).
+
+
Analysis Report: Dump analyzers
+
+
In addition to this initial summary you also have the results of the analyzers that were run against the dump, today these include:
+
+
+
Thread pool analysis
+
Sync over async anti-pattern detection
+
Deadlock detection
+
Exception on the heap
+
Managed heap summary
+
Large + pinned objects on the heap
+
SQL connections analysis
+
Inbound HTTP request
+
Outbound HTTP requests
+
Socket connections
+
Unique call stacks
+
Symbol detection
+
Source Link detection
+
Synchronization objects that are blocking threads
+
+
+
+
+
Analysis Report: Advanced call stacks
+
+
One of the most important diagnostics artifacts for production debugging is the call stack. During a typical dump debugging session, reviewing the list of threads and the associated call stacks is a great way to understand what was happening at the moment the dump was captured.
+
+
Given the importance of the call stack, the Diagnostics Analysis report provides an improved in-browser experience for call stack analysis. The advanced call stacks are explicitly designed to accurately reflect the call stack names and layout you have become accustomed to in Visual Studio.
+
+
You can initiate the advanced call stack view by clicking on any of the stack frame hyperlinks. It then also allows you to filter larger call stacks using method or namespace names, as well as quickly switch between viewing Just My Code and the entire framework call stack.
+
+
+
+
Getting to source code with Source Link
+
+
For many scenarios, the call stack provides enough clues to the source of the problem, however, by taking advantage of Source Link your analysis can be even more precise.
+
+
What is Source Link? Source Link is a set of packages and a specification for describing source control metadata that can be embedded in symbols, binaries, and packages. Once Source Link is set up your analysis reports will produce active links that navigate directly to your source code. In the following example, an active link in the call stack is pointing directly at a specific file, line, and commit on GitHub.
+
+
+
+
While Source Link is on by default for .NET source, enabling this for your code today requires a couple of additional steps.
+
+
Setting up Source Link
+
+
Debugging and diagnostics tools work best when symbols are available, typically the way to do that would be to ensure the PDBs are alongside the DLLs or, as I prefer, use embedded PDBs so they’re quite literally in the DLL already. You can enable Source Link experiences in your own .NET project by adding the following optional items to the property group:
+
+
<PropertyGroup>
+ <!-- Optional: Publish the repository URL in the built .nupkg (in the NuSpec <Repository> element) -->
+ <PublishRepositoryUrl>true</PublishRepositoryUrl>
+
+ <!-- Optional: Embed source files that are not tracked by the source control manager in the PDB -->
+ <EmbedUntrackedSources>true</EmbedUntrackedSources>
+
+ <!-- Optional: Build symbol package (.snupkg) to distribute the PDB containing Source Link -->
+ <IncludeSymbols>true</IncludeSymbols>
+ <SymbolPackageFormat>snupkg</SymbolPackageFormat>
+</PropertyGroup>
+
+
+
For source code hosted by GitHub or GitHub Enterprise you also need to include the following Nuget package:
Please check out the improved Diagnose and Solve Problem experiences for App Services for Windows and App Services for Linux! We are actively working on Diagnostics Analysis for traces and we are always interested in your feedback.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 4 minute read
+
+
+
+ • By Mark Downie, Puneet Gupta
+
+ • December 5, 2022
+
+
+
We are happy to announce that our most recent improvements to Diagnose and Solve Problems allow you to begin the analysis on a collected memory dump immediat...
+
+
+
+
+
+
+ 4 minute read
+
+
+
+ • By Mark Downie, Puneet Gupta
+
+ • December 5, 2022
+
+
+
We are happy to announce that our most recent improvements to Diagnose and Solve Problems allow you to begin the analysis on a collected memory dump immediat...
+
+
+
+
+
+
+ 24 minute read
+
+
+
+ • By Jordan Selig
+
+ • December 2, 2022
+
+
+
Many applications will consist of more than just a single component. For example, you may have a frontend which is publicly accessible that connects to a bac...
+
+
+
+
+
+
+ 32 minute read
+
+
+
+ • By Jordan Selig
+
+ • December 2, 2022
+
+
+
High availability and fault tolerance are key components of a well-architected solution. It’s always best to prepare for the unexpected and having an emergen...
Our engineering teams have been hard at work to deliver the new larger SKUs on App Service Environment v3. While it seems simple, as it is multiples of the e...
+
+
+
+
+
+
+ 4 minute read
+
+
+
+ • By Mark Downie, Puneet Gupta
+
+ • December 5, 2022
+
+
+
We are happy to announce that our most recent improvements to Diagnose and Solve Problems allow you to begin the analysis on a collected memory dump immediat...
+
+
+
+
+
+
+ 24 minute read
+
+
+
+ • By Jordan Selig
+
+ • December 2, 2022
+
+
+
Many applications will consist of more than just a single component. For example, you may have a frontend which is publicly accessible that connects to a bac...
+
+
+
+
+
+
+ 32 minute read
+
+
+
+ • By Jordan Selig
+
+ • December 2, 2022
+
+
+
High availability and fault tolerance are key components of a well-architected solution. It’s always best to prepare for the unexpected and having an emergen...
Our engineering teams have been hard at work to deliver the new larger SKUs on App Service Environment v3. While it seems simple, as it is multiples of the e...
Currently, you can use two options when configuring Azure App Service access restrictions. The preview feature provides some new scenarios that you should kn...
We have completed the initial rollout for .NET 7 GA support on App Service. Like in previous years we are using the App Service Early Access feature to enabl...
+
+
+
+
+
+
+ 2 minute read
+
+
+
+ • By Andrew Westgarth
+
+ • November 2, 2022
+
+
+
The 2022 H1 update to Azure App Service on Azure Stack Hub is now available. This release is a major update in terms of underlying infrastructure and topolog...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Denver Brittain
+
+ • October 28, 2022
+
+
+
App Service free SKU has been around for over 10 years, and we continue to improve on it with every release. Today, we are pleased to announce that App Servi...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • October 12, 2022
+
+
+
We are happy to announce that App Service now supports apps targeting Node 18, PHP 8.1 and Python 3.10 across all public regions on Linux App Service Plans t...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • October 12, 2022
+
+
+
We are happy to announce that App Service now supports apps targeting Go 1.18 and 1.19 across all public regions on Linux App Service Plans through the App S...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Radhika Bollineni
+
+ • October 12, 2022
+
+
+
We are happy to announce the preview of WordPress on Azure App Service powered by Azure Front Door which enables faster page loads, enhanced security, and in...
+
+
+
+
+
+
+ 8 minute read
+
+
+
+ • By David Fowler, Suwat Bodin, Chris Rosenblatt, Jenny Lawrance, Stephen Kou, Chris Ross, Miha Zupan, Aditya Mandaleeka, Bilal Alam
+
+ • August 16, 2022
+
+
+
In this post, we get a behind-the-scenes look at the engineering work required to change a critical platform component with code paths that are exercised bil...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Jeff Martinez
+
+ • August 11, 2022
+
+
+
We are pleased to announce that gRPC (public preview) is now available in most regions. gRPC is supported for Linux applications using .NET Core 3.1 or .NET...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Abhishek Reddy
+
+ • August 8, 2022
+
+
+
We are thrilled to announce that WordPress on App Service that was under public preview since February 15, 2022, is now generally available. With advanced fe...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Byron Tardif
+
+ • July 18, 2022
+
+
+
We are happy to announce that App Service now supports apps targeting .NET 7 Preview 5 across all public regions on both Windows and Linux App Service Plans ...
+
+
+
+
+
+
+ 2 minute read
+
+
+
+ • By Jordan Selig
+
+ • July 6, 2022
+
+
+
Regulatory Compliance in Azure Policy provides Microsoft created and managed initiative definitions, known as built-ins, for the compliance domains and secur...
+
+
+
+
+
+
+ 5 minute read
+
+
+
+ • By Jordan Selig
+
+ • June 16, 2022
+
+
+
If you’re an Azure portal user with App Service, you’ve most likely seen the Security item in the left-hand menu. This item comes from our partners from the ...
Resiliency Score report is a downloadable report that checks whether your Azure Web App is implementing the best practices to make it less susceptible to ava...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Jordan Selig
+
+ • April 14, 2022
+
+
+
We are happy to announce that you can now enable Virtual Network integration as well as private endpoints for inbound access when creating Web Apps using the...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Jordan Selig
+
+ • April 14, 2022
+
+
+
App Service now supports VNet integration (outbound) and private endpoints (inbound) all the way down to the Basic SKU. The App Service VNet integration feat...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Jason Freeberg
+
+ • April 11, 2022
+
+
+
We are happy to share that Auto-Instrumentation of Application Insights for Windows Container applications is now in public preview! Auto-Instrumentation all...
Auto-healing is a heavily used diagnostic feature of Azure App Service that allows end-users to configure a rich set of triggers that can be used to mitigate...
+
+
+
+
+
+
+ 2 minute read
+
+
+
+ • By Yutang Lin
+
+ • March 22, 2022
+
+
+
This blog contains information about *.azurewebsites.net TLS certificate changes for web apps, functions, and logic apps (standard). Customers should not be ...
+
+
+
+
+
+
+ 2 minute read
+
+
+
+ • By Jeff Martinez
+
+ • March 2, 2022
+
+
+
The Premium Container SKU will not be moving out of preview status and will be retired on 30th June 2022. Please move your applications to the Premium V3 SK...
We are happy to announce the public preview of the WordPress offering on App Service. This offering will enable you to deploy and host new WordPress websites...
+
+
+
+
+
+
+ 6 minute read
+
+
+
+ • By James Mulvey
+
+ • February 1, 2022
+
+
+
Azure App Service is regularly updated to provide new features, new runtime versions, performance improvements, and bug fixes. One of the top feature request...
+
+
+
+
+
+
+ 1 minute read
+
+
+
+ • By Jordan Selig
+
+ • January 18, 2022
+
+
+
We are happy to announce the availability of the public preview of the App Service Environment (ASE) v3 migration feature. With this feature, you’ll be able ...
Anyone running App Service Plan, or App Service Environment at scale should consider if they are running it efficiently. An App Service Plan is so easy to use that we often throw more and more applications at one, without stopping to think about the impact that might have.
+
+
Different App Service Plan SKUs have different limits. Running an app that consumes 1GB of ram on one SKU could be a concern, but maybe not on another.
+
+
What about CPU? If you have 16 v-cores then it might not be important to run a CPU intensive app. But run that same app on an App Service plan with fewer cores and you could start to impact other applications on the same plan.
+
+
Even IO heavy applications that use little RAM and CPU can have impacts. Different App Service Plan SKUs have different amounts of outbound sockets available to them. Every time you make an outbound call you may consume these ports. An app that doesn’t have a connection pool and makes lots of tiny outbound calls could cause another well-behaved app to start throwing errors. There are also specific limits on outbound connections to Public IP addresses that consume SNAT ports. This information isn’t exposed via metrics though.
+
+
All of these are members of a phenomenon known as Noisy Neighbour Syndrome. They look obvious but it’s not always easy to work out which app is misbehaving.
+
+
That’s individual applications - there are also constraint limits on the platform. An App Service Plan can have a maximum of 100 instances attached to it. If it’s in an App Service Environment then you’ve got a maximum of 200 instances that can spread across plans. When you’re running at scale it’s easy to start to come close to these limits. But it’s not easy to see how many instances are used across all an App Service Environment.
+
+
App Services can also have varying amounts of Hybrid connections. Knowing how many are currently in use against an ASP can help you decide which ASP to place new Apps in that use Hybrid Connections.
+
+
Monitor your metrics with Azure Workbooks
+
+
All this data is available in various forms, but it’s not been brought together to make it simple to consume. Azure Metrics can capture CPU / RAM / SNAT ports. The resource graph can tell you the SKU of your ASP’s, how many instances are attached to them, and which ASE they belong to.
+
+
To make it easy to consume we can build an Azure Workbook to surface all this information. Workbooks are awesome – they allow us to build a dashboard which can pull data from a multitude of sources in Azure and present it in a simple clean interface.
+
+
I’ve built a workbook to present a “single pane of glass” that can give you visibility into your ASE’s and ASP’s. Having insights into the limits will hopefully make it easier for you to run ASP and ASE at scale.
And then from a CLI run the following. Be sure to replace the placeholder with your resource group name.
+
+
az deployment group create --resource-group <rg> --template-file .\infra\deploy.bicep
+
+
+
You can then access the workbook from the Resource Group you deployed to in the Azure Portal.
+
+
You’ll need to select some subscriptions from the Subscription parameter box to get going:
+
+
+
+
Once you’ve done that the Workbook will load some summary data for all the ASP’s in the subscription:
+
+
+
+
This will show you how many instances / how many apps are associated with the ASP, the tiering, and how many Hybrid Connections are available in total for the ASP.
+
+
Selecting one of the rows will populate more insights into the ASP:
+
+
+
+
You’ll see the overall CPU / Memory Percentage used across the ASP, along with the total Hybrid Connections active on it.
+
+
To the right is a summary of all the Apps in the ASP, and the average CPU / Private Bytes / Requests Per Minute, and App Connections being made by them.
+
+
The final element is a set of charts showing some metrics against each app in the ASP. CPU / Private Bytes. It’s similar data as shown above, but represented visually to allow you to spot anything unusual.
+
+
+
+
Hopefully these insights allow you to ‘right-size’ your App Service Plans and Environments, making them more efficient, more scalable, and more cost effective to run.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
Anyone running App Service Plan, or App Service Environment at scale should consider if they are running it efficiently. An App Service Plan is so easy to us...
Anyone running App Service Plan, or App Service Environment at scale should consider if they are running it efficiently. An App Service Plan is so easy to us...
Updates to App Service Overview Blade for Custom Domains
+
+
+
+
+
+
+
+
+ 2 minute read
+
+
+
+ • By Jordan Selig
+
+ • February 3, 2023
+
+
+
+
+
+
+
You may have noticed that we recently rolled out a change in the “Essentials” section of the App Service “Overview” blade in the Azure portal where the URL that is displayed is the default URL for your app. Previously, under certain conditions, there was logic that would display the custom domain you added to your app. For example, if you added the custom domain “app.contoso.com” to your app, the URL displayed on the “Overview” blade would show “https://app.contoso.com” instead of the default URL. If your app was hosted on an App Service Environment, and you added a custom domain suffix to your App Service Environment, the “Overview” blade would show the corresponding URL with that custom domain suffix.
+
+
We decided to change that behavior to only show the default URL because we were finding that the logic for deciding which URL to show was not meeting the needs of all customers. For example, if a customer added more than one custom domain to an app, which one should be displayed? Showing the default domain ensures consistency for all customers. Additionally, we can’t ensure that when adding a custom domain that that domain will immediately function as intended - there may be additional DNS changes required. We have more confidence that providing a link to the default domain on the “Overview” blade will lead to more successful attempts to reach an app.
+
+
+
+
We were also made aware that some customers have created alerts based on the URL that is displayed in the “Essentials” section of the “Overview” blade - they use the value that is given to determine whether the custom domain they have added to their app has been applied. If this alert/check is a requirement for customers, the recommendation is to use the “Custom domains” blade to validate the domains added to their apps. That blade will show all domains added to the app and should be considered the source of truth. It also gives additional information that will help validate the security of the custom domains. In the following screenshot, the app shown is hosted in an App Service Environment with the custom domain suffix “antares-test.net”. You can see the default domain for this app as well as the domain using the custom domain suffix. If we were to add a custom domain at the app level, for example “app.contoso.com”, that would also be displayed in this blade.
+
+
+
+
Upcoming changes
+
+
We have an update to the “Overview” blade rolling out in the next few weeks that should help customers quickly identify the custom domains they’ve added to their apps directly from the “Overview” blade. The following is a UX mock of the “Overview” blade showing the upcoming changes that we are implementing.
+
+
+
+
+
“URL” in the “Essentials” section will be renamed “Default domain” and the default domain will be displayed.
+
A new section under the “Properties” tab will be added called “Domains”, which will list the default domain, the App Service Environment domain if the app is hosted in an App Service Environment with a custom domain suffix, and the custom domain if one is added at the app level. If more than one custom domain is added at the app level, the number of custom domains will be given with a link to the “Custom domains” blade.
+
+
+
We hope these changes will provide more clarity for customers. Feedback is welcome as we are always looking to improve our user experience.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 2 minute read
+
+
+
+ • By Jordan Selig
+
+ • February 3, 2023
+
+
+
You may have noticed that we recently rolled out a change in the “Essentials” section of the App Service “Overview” blade in the Azure portal where the URL t...
+
+
+
+
+
+
+ 2 minute read
+
+
+
+ • By Jordan Selig
+
+ • February 3, 2023
+
+
+
You may have noticed that we recently rolled out a change in the “Essentials” section of the App Service “Overview” blade in the Azure portal where the URL t...
Estimate your cost savings by migrating to App Service Environment v3
+
+
+
+
+
+
+
+
+ 11 minute read
+
+
+
+ • By Jordan Selig
+
+ • March 2, 2023
+
+
+
+
+
+
+
+
+
If you weren’t already aware, App Service Environment v1 and v2 is retiring on 31 August, 2024. There are many reasons to migrate to App Service Environment v3 including better performance, faster scaling, and reduced overhead since networking dependency management has been greatly simplified. One benefit that stands out that we understand might need some additional explanation is that App Service Environment v3 is often cheaper than previous versions. With the removal of the stamp fee and larger instance sizes per respective SKU with previous versions, App Service Environment v3 can help you do more with less and reduce your monthly spend if you’re familiar with the updates.
+
+
In this post, we’ll go over a couple common scenarios that will help you better understand App Service Environment v3 pricing and how it compares to your pricing model on App Service Environment v1 or v2. We know there are many scenarios out there, so hopefully one of the ones shared here can be used as an example for you to better understand your situation. The Azure Pricing Calculator is a great resource and will be referenced throughout this post for each scenario. Note that estimates here are based on the prices applicable on the day the estimate was created. Actual total estimates may vary. For the most up-to-date estimate, click the link for each scenario. Refer to the App Service pricing page for more information.
+
+
+
NOTE: Unless otherwise indicated, all scenarios are calculated using costs based on Linux $USD pricing in East US. The payment option is set to monthly to simplify cost comparisons.
+
+
+
Basic scenarios
+
+
Scenario 1: Scale down your App Service plans with pay-as-you-go pricing
+
+
The App Service plan SKUs available for App Service Environment v3 run on the Isolated v2 tier. This is not to be confused with the tier used by App Service Environment v2, which is the Isolated tier. Below are the corresponding service plans for each available tier. Notice that for the Isolated v2 tier, the number of cores and amount of RAM is effectively doubled. We’ll use this information in this scenario. Additionally, there are new larger SKUs available with the Isolated v2 tier that were not previously available with the older version.
+
+
+
+
+
Isolated
+
Cores
+
RAM (GB)
+
+
Isolated v2
+
Cores
+
RAM (GB)
+
+
+
+
+
I1
+
1
+
3.5
+
→
+
I1v2
+
2
+
8
+
+
+
I2
+
2
+
7
+
→
+
I2v2
+
4
+
16
+
+
+
I3
+
4
+
14
+
→
+
I3v2
+
8
+
32
+
+
+
+
+
+
+
I4v2
+
16
+
64
+
+
+
+
+
+
+
I5v2
+
32
+
128
+
+
+
+
+
+
+
I6v2
+
64
+
256
+
+
+
+
+
In this scenario, you are using an App Service Environment v2 with 1 I2 plan. You require 2 cores and 7 GB RAM. You are using pay-as-you-go pricing.
+
+
On App Service Environment v2, your monthly cost is:
If you were to migrate this exact workload to App Service Environment v3, you would be able to scale down from I2 to I1v2 since the Isolated v2 equivalent tier has double the cores and RAM. Your monthly cost on App Service Environment v3 would be:
As you can see, this is a significant cost savings since you were able to use a smaller tier and the stamp fee is no longer applicable. If you don’t scale down after migrating to v3, you will be over-provisioned and incur unnecessary charges, some of which may make your App Service Environment v3 more expensive than your old environment.
+
+
Scenario 2: 3 year reserved instance pricing and savings plan
+
+
Reservations or reserved instance pricing is a discount you can receive if you know what your usage will look like for the next 1 to 3 years. On App Service Environment v2, reservations are supported for the stamp fee. On App Service Environment v3, there is no stamp fee and reservations are supported on the instances themselves.
+
+
The following scenario will use the same requirements as Scenario 1, but instead of using pay-as-you-go pricing, you will now use 3 year reserved instance pricing since you know your requirements will stay relatively flat over the next 3 years. With reservations, you can pay upfront or monthly. For ease of comparison between the scenarios, monthly payments will be used.
+
+
On App Service Environment v2 with a 3 year reservation, your monthly cost would be:
There’s a 55% reduction in the monthly cost as a result of using reserved instance pricing.
+
+
Azure savings plan for compute is another option that is only available on App Service Environment v3. Azure savings plan for compute is a flexible pricing model that provides savings up to 65 percent off pay-as-you-go pricing when you commit to spend a fixed hourly amount on compute services for one or three years.
+
+
For this scenario, your cost on App Service Environment v3 with a 3 year savings plan would be:
So far we’ve demonstrated the ways migrating to App Service Environment v3 can save you money. However, there are some cases where this may not be the case. Let’s take for example you have an App Service Environment v2 with a single I1 instance and you’re using pay-as-you-go pricing. Your monthly cost would be:
This is a significant cost reduction, just know that you’re now over-provisioned since you now have double the cores and RAM, which you may not need. This is not an issue since the new environment is so much cheaper. However, when you start to have many I1 instances in a single App Service Environment, for example because you use this environment for dev or test workloads across multiple different apps and teams, you need to consider the break even point if you migrate to App Service Environment v3.
+
+
For this scenario, your App Service Environment v2 has 14 I1 instances. Because of how your environment is being used by your team, you can not reduce the number of instances or use a larger instance that has the same effective capacity. Your monthly cost is:
As you can see, your App Service Environment v3 is slightly more expensive than your v2. As you start adding more I1 instances, and therefore need more I1v2 instances when you migrate, the difference in price becomes even more significant and your v3 will get more and more expensive than your v2. Unfortunately, if you’re in this situation, you may have to plan for a higher monthly cost.
+
+
+
NOTE: This calculation was done with Linux $USD prices in East US. Break even points will vary due to price variances in the various regions. For an estimate that reflects your situation, see the Azure Pricing Calculator.
+
+
+
The following chart visually depicts the break even point at the time of releasing this blog post using the selected region and price offering where App Service Environment v3 becomes more expensive than v2. If you need more than 13 of our smallest instance offering, you fall into this scenario. There may be other scenarios where this is also the case.
+
+
+
+
Advanced scenarios
+
+
The first three scenarios were basic and were intended to give you a quick sense of how pricing works on App Service Environment v3. Realistically, you’ll have many more instances and probably be using a combination of the SKUs. The following scenarios will give you a better sense of the cost saving opportunities for these use cases.
+
+
Scenario 4: SKU mix
+
+
To accommodate various app types in your App Service Environment v2, you use a combination of the tiers in various quantities. The first estimate will be using pay-as-you-go pricing, and the second will use a 3 year reservation on the stamp fee.
You can start to see here that as you consume more resources, the reservations available on App Service Environment v2 don’t significantly reduce monthly costs since they only apply to the stamp fee.
+
+
On App Service Environment v3, you require the same respective core and RAM capacity. There are various paths you can take here depending on your specific requirements - you can keep the same number of instances and just scale them down, or you can reduce the total number instance you are using. For this scenario, we’ll do the following:
At this point, you’re reducing your costs by over 70%. This is where the cost saving benefits of App Service Environment v3 really start to become significant. Even if you were to use pay-as-you-go pricing, you still see cost savings in the form of thousands of dollars per month.
+
+
+
+
Scenario 5: Migration to App Service Environment v3 using the migration feature
+
+
The migration feature was developed to automate the migration of App Service Environments to v3. It’s an in-place migration, meaning it uses the same subnet your current environment is in. During the migration, your current environment is deleted and an App Service Environment v3 is spun up. All of your instances are automatically converted to their Isolated v2 counterparts (for example I2 is converted to I2v2). Since the Isolated v2 instances are larger, you’ll be over-provisioned if you’re still expecting the same traffic volume. This is a direct scenario where you have the opportunity to scale your instances down similar to what was done in Scenario 4.
+
+
To keep things consistent, we’ll keep the requirements for this scenario the same as Scenario 4. Your capacity requirements will not change after migration. Prior to migrating, your monthly pay-as-you-go cost is:
Immediately after migrating using the migration feature, your instances have been converted and you have the following leading to a higher monthly cost than what you had on App Service Environment v2.
You should plan how you will scale down prior to migrating to ensure you don’t get hit with unexpected costs due to being over-provisioned. You’ll be able to scale down immediately after the migration finishes.
+
+
+
+
Scenario 6: Reduce total number of App Service Environments
+
+
App Service Environments are a great choice for customers that need to scale beyond the limits of the App Service public multi-tenant offering of 30 App Service plan instances. But even the 200 instance limit with App Service Environments may not be enough for some customers. In that case, they need to create multiple App Service Environments.
+
+
For this scenario, you have 3 App Service Environment v2s all at max capacity with 200 I3 instances in each. Your monthly cost with pay-as-you-go pricing is:
With App Service Environment v3, you have a couple options for how to proceed. You can continue using 3 App Service Environment v3s and just scale down to a smaller SKU, or you can reduce the number of environments by taking advantage of the new larger SKUs.
+
+
Keeping the same number of environments and scaling down would lead to a monthly cost with pay-as-you-go pricing of:
This would be further reduced if you were to use a reservation or savings plan.
+
+
If you wanted to reduce the total number of App Service Environments, this would be possible by using the larger SKUs that are only offered on App Service Environment v3. In addition to the potential cost savings you would see by reducing your instance counts and number of environments, you would also realize additional cost savings in the form of overhead since management would be over fewer resources.
+
+
For this scenario, the requirement is to have the equivalent of 600 I3 instances, or 2400 cores and 8,400 GB RAM. With App Service Environment v3, this can be accomplished with a single App Service Environment with 38 I6v2 instances. The pay-as-you-go monthly cost would be:
This is just over the cost of the maintaining 3 App Service Environment v3s, but this doesn’t take into account the extra overhead involved in managing multiple resources. With 3 year reserved instance pricing, this monthly cost would be reduced significantly.
Zone redundant App Service Environment deployments are only supported on App Service Environment v3. There is no additional charge for enabling zone redundancy if you have 9 or more instances. These 9 instances can be made up of any combination of the available SKUs. For example, you can have 9 I1v2s or 3 I1v2s, 3 I2v2s, and 3 I3v2s. You will only be charged for those 9 instances.
+
+
If you enable zone redundancy, and if your environment has fewer than 9 total instances, you’ll be charged the difference if the form of a minimum instance fee which uses the Windows I1v2 instance price. For example, if you have a zone redundant App Service Environment v3 with 3 Linux I3v2 instances, you will be charged for those 3 I3v2 instances at the standard Linux rate, plus 6 Windows I1v2 instances.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 11 minute read
+
+
+
+ • By Jordan Selig
+
+ • March 2, 2023
+
+
+
If you weren’t already aware, App Service Environment v1 and v2 is retiring on 31 August, 2024. There are many reasons to migrate to App Service Environment ...
+
+
+
+
+
+
+ 11 minute read
+
+
+
+ • By Jordan Selig
+
+ • March 2, 2023
+
+
+
If you weren’t already aware, App Service Environment v1 and v2 is retiring on 31 August, 2024. There are many reasons to migrate to App Service Environment ...
Updates to App Service Azure Policies that monitor language versions
+
+
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Jordan Selig
+
+ • April 24, 2023
+
+
+
+
+
+
+
+
+
Azure Policy for App Service has the following built-in policies that ensure you are using the latest versions of certain languages that are available on the platform.
+
+
+
App Service apps that use Java should use the latest ‘Java version’
+
App Service apps that use Python should use the latest ‘Python version’
+
App Service apps that use PHP should use the latest ‘PHP version’
+
Function apps that use Java should use the latest ‘Java version’
+
Function apps that use Python should use the latest ‘Python version’
+
+
+
Updates
+
+
We know that for certain customers, using the latest version of a language or runtime isn’t always possible. Additionally, with the variations and possible language versions available, we want to provide a way for our customers to have more flexibility when monitoring the compliance of languages used by their apps. For these reasons, the above policies have been modified. The following changes have been implemented and will be visible in the Azure portal in the next few weeks.
+
+
+
The policies no longer have a hard-coded value for the language version they’re monitoring. Instead, the user must specify a version that aligns with their requirements when assigning these policies.
+
+
When assigning these policies, users will be prompted to specify a language version.
+
+
+
The policies have been renamed to align with this updated scope. Below are the new names.
+
+
App Service apps that use Java should use a specified ‘Java version’
+
App Service apps that use Python should use a specified ‘Python version’
+
App Service apps that use PHP should use a specified ‘PHP version’
+
Function apps that use Java should use a specified ‘Java version’
+
Function apps that use Python should use a specified ‘Python version’
+
+
+
The policies have been removed from the Azure Security Baseline and Microsoft Defender for Cloud initiatives.
+
+
The policies can still be assigned and even added to a Microsoft Defender for Cloud initiative, however they won’t be automatically assigned as they previously were.
+
+
+
Equivalent policies have been created to monitor compliance for slots. These must be assigned in addition to the policies that monitor the main site in order to ensure monitoring is in place for all App Service resources.
+
+
App Service app slots that use Python should use a specified ‘Python version’
+
Function app slots that use Python should use a specified ‘Python version’
+
App Service app slots that use PHP should use a specified ‘PHP version’
+
App Service app slots that use Java should use a specified ‘Java version’
+
Function app slots that use Java should use a specified ‘Java version’
+
+
+
+
+
There are also a couple limitations to be aware of when using these policies.
+
+
+
They’re scoped to apps on Linux App Service only.
+
+
If you require monitoring for Windows apps, you can use the existing policies as a reference to create Windows specific custom policies. For more information on building and assigning custom policies, see Tutorial: Create a custom policy definition.
+
+
+
These policies use text based matching on a “free-text” field to monitor compliance. Ensure you have proper controls in place to prevent unexpected changes to language versions.
+
+
+
Required actions
+
+
These policy updates will have no impact on existing policy assignments. If you have the old version of these policies assigned, they will continue to function without interruption. In order to use the new versions of these policies, you must create new policy assignments. We encourage you to take this action as soon as possible as the old versions of these policies are prone to false negatives.
+
+
How to use the new policies
+
+
The new policies can be assigned in the Azure portal. For more information on how to assign policies, see Assign a policy to a resource group.
+
+
When assigning these policies in the Azure portal, you won’t automatically be prompted to specify a language version. You must go to the Parameters tab and uncheck the box “Only show parameters that need input or review” in order to see the language version parameter. This is a required parameter that defaults to an empty string so if you don’t specify a value, the policy will always evaluate to non-compliant.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Jordan Selig
+
+ • April 24, 2023
+
+
+
Azure Policy for App Service has the following built-in policies that ensure you are using the latest versions of certain languages that are available on the...
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Jordan Selig
+
+ • April 24, 2023
+
+
+
Azure Policy for App Service has the following built-in policies that ensure you are using the latest versions of certain languages that are available on the...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Jordan Selig
+
+ • April 24, 2023
+
+
+
Azure Policy for App Service has the following built-in policies that ensure you are using the latest versions of certain languages that are available on the...
We are excited to announce that we have released the public preview of free hosting plan for WordPress on App Service.
+
+
We announced the General Availability of WordPress on App Service one year ago, in August 2022 with 3 paid hosting plans. We learnt that sometimes you might need to try out the service before you migrate your production applications. So, we are offering you a playground for a limited period - a free hosting plan to and explore and experiment with WordPress on App Service. This will help you understand the offering better before you make a long-term investment.
+
+
+
+
+
Note: This hosting plan is not suitable for Production workloads. So, it is highly recommended that you do not use this plan for production setup.
+
+
+
+
+
Updated Hosting Plans:
+
+
+
+
+
Hosting Plan
+
WebApp Server
+
Database Server
+
+
+
+
+
Free
+
F1 Free Tier (60 CPU minutes per day, 1 GB RAM, 1 GB Storage)
General Purpose, D2ds_v4 (2 vCores, 16 GB RAM, 256 GB storage, Auto IOPS)
+
+
+
+
+
Eligibility:
+
+
The free hosting plan take advantage of App Service F1 free tier and Azure Database for MySQL free trial. Your eligibility depends on your subscription type:
The free hosting plan takes advantage of multiple optimizations and features we built for WordPress on App Service on top of the inbuilt features for App Service and Azure Database for MySQL.
+
+
+
Easy and Automated deployments from the Azure Portal
+
Inbuilt Redis cache
+
Accelerated WP Admin using local storage caching
+
PhpMyAdmin for database management
+
+
+
However, there are certain points that you need to keep in mind.
Integration with Paid services such as CDN, Front Door, Blob Storage, and Email Service is not included in the free hosting plan.
+
Local storage caching is limited to 500 MB. We recommend that you do not exceed 500 MB in content, themes, and plugins.
+
+
+
Limitations:
+
+
+
Since you are running on Free Tier, for App Service there is no support for Scale out capability and ‘Always on’ feature. They are disabled for F1 SKU.
When running on Azure App Service F1 SKU, it is not supported to scale-out to multiple instances. You can scale-up your App Service to next highest SKU that suits your workloads. Upgrade your WordPress site to higher SKUs based on your workloads. You can refer to the guidance described here: Price reduction in Hosting Plans for WordPress on Azure App Service - Microsoft Community Hub
+
+
Monitor and track free service usage:
+
+
You’re not charged for Azure App Service F1 SKU as this SKU is forever free. You’re not charged for Azure Database for MySQL - Flexible Server services included for free with your Azure free account unless you exceed the free service limits. To remain within the limits, use the Azure portal to track and monitor your free services usage. For tracking and monitoring your free services usage, refer to this document: Monitor and track Azure free service usage - Microsoft Cost Management | Microsoft Learn
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Jordan Selig
+
+ • April 24, 2023
+
+
+
Azure Policy for App Service has the following built-in policies that ensure you are using the latest versions of certain languages that are available on the...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
+
+
+
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for both Windows and Linux App Service Plans.
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Jordan Selig
+
+ • April 24, 2023
+
+
+
Azure Policy for App Service has the following built-in policies that ensure you are using the latest versions of certain languages that are available on the...
If you’re running distributed applications on JBoss EAP, you know that clustering is essential for data consistency and fault tolerance. We’ve taken this a step further on Azure App Service. Now, when you integrate JBoss EAP with an Azure Virtual Network (VNet), clustering isn’t just an option; it’s a built-in feature that kicks in automatically.
+
+
What does this mean for your apps? For starters, it improves fault tolerance and enables more efficient data sharing across multiple instances. Your application can now handle traffic spikes and server failures better. The service scales based on your configured settings in Azure App Service, providing both vertical and horizontal options.
+
+
One key update in this release is the automatic enablement of clustering when you activate VNet Integration for your web application. This results in a high-availability setup right from the get-go. We’ll delve into the technical specifics below.
+
+
+
+
Enabling VNet integration is required for communication between servers that form the cluster. Clustering is enabled automatically but can be disabled using an Application Setting (WEBSITE_DISABLE_CLUSTERING).
You can configure the behavior of the clustering-related features using these Application Settings:
+
+
+
+
WEBSITE_JBOSS_SERVER_DIR defines the parent location of the JBoss state and transaction files. If customers use a location mounted from Azure Storage, this setting improves the availability of the application by avoiding using the /home directory, which becomes read-only during platform upgrades.
+
+
+
WEBSITE_JBOSS_CLUSTER_DIR defines the location of the cluster definition files. Similar to the previous setting, if you use a location mounted from Azure Storage, this setting improves the availability of the application by avoiding using the /home directory which becomes read-only during platform upgrades.
+
+
+
JBOSS_LAUNCHER_OPTS passes options directly to the JBoss launcher script (standalone.sh) to allow changes such as enabling the JBoss web administration interface.
+
+
+
WEBSITE_DISABLE_CLUSTERING prevents the clustering behavior from starting, even if the application is used with VNet integration enabled.
+
+
+
WEBSITES_CONTAINER_STOP_TIME_LIMIT sets how long to wait for pending transactions before stopping the server forcefully (in seconds). Its default value is 120 seconds.
+
+
+
+
How to Get Started
+
+
Get started with Clustering Support on App Service for JBOSS EAP today! It is now generally available. To get your hands on it, go through our detailed guide: Clustered JBoss EAP on Azure App Service Quickstart. This guide walks you through the deployment of a basic distributed application to JBoss EAP, demonstrating how clustering operates seamlessly on Azure App Service.
+
+
Additional Information
+
+
Auto-scale rules
+
+
When configuring auto-scale rules for horizontal scaling it is important to remove instances one at a time to ensure each removed instance transfers its activity (for example, handling a database transaction) to another member of the cluster. When configuring your auto-scale rules in the Portal to scale down, use the following options:
+
+
+
+
Operation: “Decrease count by”
+
+
+
Cool down: “5 minutes” or greater
+
+
+
Instance count: 1
+
+
+
+
When scaling out though, you can add multiple instances to the cluster simultaneously.
+
+
Limitations on Clustering
+
+
+
+
The App Service platform waits up to 120 seconds before stopping a server, not indefinitely for transactions to complete. Any pending transactions remaining after stopping the server are recovered when a new server is added, according to the number of instances defined in the Scale Out configuration.
+
+
+
If a customer manually resizes down a cluster, there’s a potential for nodes to be stopped before they complete their transactions. In that case a warning is emitted, and manual intervention is needed to commit the transactions from that node. The process is documented in section 5.2. “Migrating Logs to a New JBoss EAP Server” of the guide Managing Transactions - Red Hat Customer Portal.
+
+
+
In the case of a movement to different hardware (for example, scaling up or hardware faults), when a cluster node cannot complete its transactions, a warning will be emitted, and manual intervention is needed to commit any transactions that were not committed.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Jordan Selig
+
+ • April 24, 2023
+
+
+
Azure Policy for App Service has the following built-in policies that ensure you are using the latest versions of certain languages that are available on the...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
+
+
+
+
+
+
+ 3 minute read
+
+
+
+ • By Jordan Selig
+
+ • April 24, 2023
+
+
+
Azure Policy for App Service has the following built-in policies that ensure you are using the latest versions of certain languages that are available on the...
+
+
+
+
+
+
+ 11 minute read
+
+
+
+ • By Jordan Selig
+
+ • March 2, 2023
+
+
+
If you weren’t already aware, App Service Environment v1 and v2 is retiring on 31 August, 2024. There are many reasons to migrate to App Service Environment ...
+
+
+
+
+
+
+ 2 minute read
+
+
+
+ • By Jordan Selig
+
+ • February 3, 2023
+
+
+
You may have noticed that we recently rolled out a change in the “Essentials” section of the App Service “Overview” blade in the Azure portal where the URL t...
Anyone running App Service Plan, or App Service Environment at scale should consider if they are running it efficiently. An App Service Plan is so easy to us...
Sorry, but the page you were trying to view does not exist. Try searching for it using the search icon above.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
new file mode 100644
index 0000000000..f472a25ed6
--- /dev/null
+++ b/CONTRIBUTING.md
@@ -0,0 +1,168 @@
+# Instructions for publishing content
+
+Table of contents:
+
+- [Instructions for publishing content](#instructions-for-publishing-content)
+ - [Publishing an article](#publishing-an-article)
+ - [What content can I publish here?](#what-content-can-i-publish-here)
+ - [Get access](#get-access)
+ - [Set up your environment](#set-up-your-environment)
+ - [Author your post](#author-your-post)
+ - [Writing Tips](#writing-tips)
+ - [Add digital content](#add-digital-content)
+ - [Publish the article](#publish-the-article)
+ - [The team pages](#the-team-pages)
+ - [Edit a team page](#edit-a-team-page)
+ - [Add a team page](#add-a-team-page)
+ - [Notes](#notes)
+
+## Publishing an article
+
+### What content can I publish here?
+
+The App Service Team Blog is a great place to share content with our users. Before you start writing, make sure that your content fits within one of these categories:
+
+- Advanced usages of App Service, or How-To guides for specific language frameworks
+- Feature announcements, runtime version updates, etc.
+ - Any major feature updates (such as a GA release) should be cross-posted on [Azure Updates](https://azure.microsoft.com/updates/) and/or the [Azure Blog](https://azure.microsoft.com/blog/)
+- Deep-dive content into our service, such as architecture or development/deployment processes
+- Announcements about upcoming events, or recaps of past events
+- Best practices
+
+### Get access
+
+1. Get contributor access to the repository. Email Jeff Martinez with your GitHub username. This will allow you to submit pull requests without creating and maintaining your own fork of the repository.
+
+### Set up your environment
+
+1. Download and install the [Ruby development kit](https://jekyllrb.com/docs/installation/)
+
+1. Clone the project
+
+ ```bash
+ git clone https://github.com/Azure/AppService.git
+ ```
+
+1. Install any missing Ruby gems:
+
+ ```bash
+ bundle install
+ ```
+
+1. Install [GitHub Desktop](https://desktop.github.com/) for making branches, pull requests, etc.
+
+1. We suggest using VS Code to author your blog post. Install [Markdown Linting extension](https://marketplace.visualstudio.com/items?itemName=DavidAnson.vscode-markdownlint) to make your life easier.
+
+### Author your post
+
+1. Run the local Jekyll server. From the project directory, run the following command:
+
+ ```bash
+ bundle exec jekyll serve --limit_posts=50 --incremental --future
+ ```
+
+ The blog will be running at . (The `--limit_posts=5` arg only builds the latest 5 articles. This speeds up the time-to-refresh.)
+
+1. Create a new branch for your article(s). If you are not using GitHub Desktop, run the command `git checkout -b [name_of_your_new_branch]`
+
+1. Create a markdown file under the `_posts` directory with the following file name format: `YYYY-MM-DD-Your Article Title.md`
+
+1. Add the following to the top of your posts (this is called the "front matter").
+
+ ```yaml
+ ---
+ title: "Title should be the same (or similar to) your filename"
+ author_name: "Your Name" # required
+ category: 'your team's category' # optional
+ tags: # tags are optional
+ - example
+ - multiple words
+ - no more than 3 tags
+ ---
+ ```
+
+ You can configure our post to have a table of contents or have a wide layout. See the [config guide](https://mmistakes.github.io/minimal-mistakes/docs/layouts/) for more info.
+
+1. Now you can author your markdown-formatted post. When you save the file, the local server will update the file in the browser.
+
+ - For Markdown syntax, please see the [Markdown cheat-sheet](https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet).
+ - For Jekyll-related formatting, please see these [Jekyll Docs](https://jekyllrb.com/docs/posts/).
+ - Our blog uses the popular [Minimal Mistakes](https://github.com/mmistakes) theme. If you would like to do advanced markup for your post, please see the [theme's utility classes](https://mmistakes.github.io/minimal-mistakes/docs/utility-classes/).
+
+#### Writing Tips
+
+Here are some quick tips to make your blog post clear, concise, and more effective:
+
+1. **Write an outline**. Before you jump into writing the article, outline the article using a bulleted list. Doing this will help you organize the content from top-to-bottom.
+1. [**Avoid using Passive Voice**](https://www.wikihow.com/Avoid-Using-the-Passive-Voice). In most cases, the subject of the sentence should come before the verb. This is good: _"John hit the ball"_. This is bad: _"The ball was hit by John"_. The object precedes the verb in the second example. Excessive use of the passive voice will make your article longer, less clear, and awkward to read.
+1. **Avoid run-on sentences**. Your article is likely going to cover a technical concept. Make things easy for the reader. Use short, concise sentences.
+1. **Don't narrate with the first person**. Whenever possible, avoid "we" or "I". In instructional articles, avoid using phrases like _"we will now deploy they app"_ or _"we will move to the next topic"_. These phrases don't serve any instructional purpose, and lengthen the article unnecessarily.
+ 1. It is OK to refer directly to the reader as "you". For example, "Your web app is ready to deploy", or "You can now proceed to the next step".
+
+For more best practices, please see [this deck from ACOM](https://microsoft.sharepoint.com/:p:/t/cloudosdigital/EYElo_4ScDZCqBNEHs6P7q0BD7Vl-6jnb8vaOfxhmAmE_w?e=g43Da6).
+
+#### Add digital content
+
+You can add images, GIFs, or other digital content to your post by adding it to the `/media/` directory and referencing the file from the post.
+
+1. Add the file under the `/media/YEAR/MONTH/` directory.
+ - Where `YEAR` and `MONTH` are the year and month in your article's filename. If the directory for the year or month does not yet exist, please create them.
+1. Once the file is added, you can link to the file in your markdown using the path `{{ site.baseurl }}/media/YEAR/MONTH/your_file_name.jpg`. For example, to insert an image in Markdown you would use the following syntax
+
+ ```text
+ 
+ ```
+
+ For more information on `baseurl`, please see [this post](https://byparker.com/blog/2014/clearing-up-confusion-around-baseurl/).
+
+### Publish the article
+
+1. Proofread your post for spelling and grammar. Ask a friend or coworker to proof-read it as well.
+
+ - If you are using VSCode, please install: [Markdown Linting extension](https://marketplace.visualstudio.com/items?itemName=DavidAnson.vscode-markdownlint) and fix all linting issues.
+ - Install the [Code Spell checker extension](https://marketplace.visualstudio.com/items?itemName=streetsidesoftware.code-spell-checker) this should help catch spelling mistakes and typos.
+
+1. Submit a pull request. You can use [GitHub Desktop](https://help.github.com/en/desktop/contributing-to-projects/creating-a-pull-request) or the command line.
+
+1. Assign `jeffwmartinez` as a reviewer for your pull request. Send an email to Jeff if it is high priority.
+
+## The team pages
+
+There are team pages in the left sidebar to help organize content from that team. Each Antares team can set up a team page **if they have published at least 5 relevant articles**.
+
+### Edit a team page
+
+1. Find your team's page under `_pages/team_pages/`
+1. Edit the markdown content as you wish. You can use in-line HTML as well, see the [theme's utility classes](https://mmistakes.github.io/minimal-mistakes/docs/utility-classes/) for more information.
+1. Any images should be placed under `media/pages/team_pages/your-team-name/`. See [adding digital content](#adding-digital-content) for more information on adding these images to your post.
+1. When you're done making changes, submit a Pull Request and add `jeffwmartinez` as a reviewer
+
+### Add a team page
+
+1. Create a markdown file under `_pages/team_pages/`.
+1. Add the following front matter to the markdown document (without the inline comments).
+
+ ```yaml
+ ---
+ permalink: "/your-category-name/" # Chose your own permalink
+ layout: home # Don't change this
+ title: "My team's name" # Short title for the page
+ sidebar:
+ nav: "default" # Don't change this
+ pagination:
+ enabled: true
+ category: your-category-name # Same string as your permalink, w/o the slashes
+ sort_reverse: true
+ ---
+ ```
+
+1. Add an entry for the team page in [`navigation.yaml`](_data/navigation.yml)
+3. Add content about your team, any relevant links, or team member photos to the body of the markdown document. See the other team pages for ideas.
+4. To add articles to your team's page like the others, go back to your team's articles and add `category: your-category-name` to the articles' front matter. This will add them to your team page's paginator.
+
+---------
+
+#### Notes
+
+- [/media](/media): All images and digital content from the old MSDN blog
+- [/resource](/resource): All the CSS and JS content from the old MSDN blog
diff --git a/SECURITY.md b/SECURITY.md
new file mode 100644
index 0000000000..869fdfe2b2
--- /dev/null
+++ b/SECURITY.md
@@ -0,0 +1,41 @@
+
+
+## Security
+
+Microsoft takes the security of our software products and services seriously, which includes all source code repositories managed through our GitHub organizations, which include [Microsoft](https://github.com/Microsoft), [Azure](https://github.com/Azure), [DotNet](https://github.com/dotnet), [AspNet](https://github.com/aspnet), [Xamarin](https://github.com/xamarin), and [our GitHub organizations](https://opensource.microsoft.com/).
+
+If you believe you have found a security vulnerability in any Microsoft-owned repository that meets [Microsoft's definition of a security vulnerability](https://aka.ms/opensource/security/definition), please report it to us as described below.
+
+## Reporting Security Issues
+
+**Please do not report security vulnerabilities through public GitHub issues.**
+
+Instead, please report them to the Microsoft Security Response Center (MSRC) at [https://msrc.microsoft.com/create-report](https://aka.ms/opensource/security/create-report).
+
+If you prefer to submit without logging in, send email to [secure@microsoft.com](mailto:secure@microsoft.com). If possible, encrypt your message with our PGP key; please download it from the [Microsoft Security Response Center PGP Key page](https://aka.ms/opensource/security/pgpkey).
+
+You should receive a response within 24 hours. If for some reason you do not, please follow up via email to ensure we received your original message. Additional information can be found at [microsoft.com/msrc](https://aka.ms/opensource/security/msrc).
+
+Please include the requested information listed below (as much as you can provide) to help us better understand the nature and scope of the possible issue:
+
+ * Type of issue (e.g. buffer overflow, SQL injection, cross-site scripting, etc.)
+ * Full paths of source file(s) related to the manifestation of the issue
+ * The location of the affected source code (tag/branch/commit or direct URL)
+ * Any special configuration required to reproduce the issue
+ * Step-by-step instructions to reproduce the issue
+ * Proof-of-concept or exploit code (if possible)
+ * Impact of the issue, including how an attacker might exploit the issue
+
+This information will help us triage your report more quickly.
+
+If you are reporting for a bug bounty, more complete reports can contribute to a higher bounty award. Please visit our [Microsoft Bug Bounty Program](https://aka.ms/opensource/security/bounty) page for more details about our active programs.
+
+## Preferred Languages
+
+We prefer all communications to be in English.
+
+## Policy
+
+Microsoft follows the principle of [Coordinated Vulnerability Disclosure](https://aka.ms/opensource/security/cvd).
+
+
diff --git a/appservicecertificate/2019/03/19/DevTalk-App-Service-Certificate-sync-improvements-and-design.html b/appservicecertificate/2019/03/19/DevTalk-App-Service-Certificate-sync-improvements-and-design.html
new file mode 100644
index 0000000000..69065a75aa
--- /dev/null
+++ b/appservicecertificate/2019/03/19/DevTalk-App-Service-Certificate-sync-improvements-and-design.html
@@ -0,0 +1,940 @@
+
+
+
+
+
+
+//DevTalk - App Service Certificate - New Sync and Export experiences - Azure App Service
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
//DevTalk - App Service Certificate - New Sync and Export experiences
+
App Service Certificates have been a very popular feature among App Service customers. However, our customers often get confused about the sync scenarios between App Service Certificates and Linked Private certificates. Specifically during the Manual Renew, Manual Rekey, and Auto Renew operations. This blog will showcase recent UX improvements to give you control over the sync scenarios. We will also talk about the internals of the automatic sync tasks running in the background to keep your certificates and SSL bindings synced up automatically.
+
+
App Service Certificate Overview experience
+
+
When you open the App Service Certificate UX you will see the list of Linked Private certificates that are referenced in your App Service Apps.
+
+
+
+
Note the sync button top, it will be disabled if all Linked Private certificates are in-sync. If any Linked Private certificates are not synced, the sync button will be enabled as shown above.
+
+
The Sync operation performs the following tasks:
+
+
+
Updates the Linked Private certificate with the current active App Service Certificate.
+
Updates all SSL Bindings in all apps used by the Linked Private certificate to use the new certificate.
+
+
+
You can sync all Linked Private certificates from the main sync experience in one click.
+
+
+
+
Manual Rekey and Renew experience
+
+
Previously, during rekey and renew scenarios we would show the certificates references. Now we show the status of the Linked Private certificate and the difference between the thumbprints between them to give a clear view of the certificate state. We also allow you to sync the certificate with the sync command directly.
+
+
This model allows you to perform a rekey or a renew and leave the UI and continue with your work in the portal. When you return to the App Service Certificate blade, you will see the out-of-sync certificates. At this point, you can either let the automatic sync task take care of it, or sync it manually using the button.
+
+
Manual Renew Scenario
+
+
+
+
Manual Rekey Scenario
+
+
+
+
Auto Renew and Sync internals
+
+
Our customers are sometimes confused by how the auto renew operation works and how it affects the Linked Private certificates. In an attempt to demystify the process, let me explain how our renew and syncs happen.
+
+
As we know by now, App Service Certificate uses GoDaddy APIs to issue your SSL certificates. Once a certificate is issued, we store the certificates in the KeyVault you configured during the KeyVault configuration step. We have a AutoRenew background task that runs every 8 hours in the App Service Certificate backend to look at all the certificates that are up for renewal and renew them if you have turned on Auto Renew. Once renewed the background task updates the KeyVault with the new certificate.
+
+
Meanwhile, in the App Service backend we have another task that runs every 48 hours to sync all certificates that have a KeyVault reference (you can import a certificate from KeyVault secret into a App Service Web App following this blog). The background tasks has to run through a lot of private certificates which have KeyVault references and check if they have changed and update the certificate if needed, during this sync we also need to update the SSL Bindings on all the apps that are using this private certificate to maintain a working configuration.
+
+
We have put in a lot of work to make these background task run at maximum efficiency and fall back properly on error cases. So when an Auto Renew happens, the new certificate will automatically be synced when 48-hour background task picks up the certificate to sync. We are aware that 48 hours is too long for some customers and we are working on improving the timings. Until then, you can do a manual sync with the experience provided above. You can rest assured that the certificate used in your app at any point of the scenario will be valid during the auto renew process as we give a buffer of 60 days when both the newly renewed certificate and the old are valid.
+
+
Looking forward to hearing more on whether the internal details shed some light on how the auto renew and sync works and if you need more details feel free to drop a comment with your ask.
+
+
Export Scenario
+
+
When you go to the export experience on App Service Certificate, you will see a new link to open the KeyVault Secret directly. In order to open the KeyVault secret you need to have GET permissions on the KeyVault Access Policy. Once you open the secret UI, you can navigate to the current version and download the certificate directly from the portal. The certificate will be in pfx format and may need further processing to add a password or prepare it for Linux/Mac usage. But for now, you do not need any PowerShell magic to get the pfx. Note that KeyVault secret UI does not add a password for the downloaded pfx. Once you downloaded the pfx, we advise you to install it on your Windows machine and export it with the password and delete the other occurrences to keep the pfx save (or as save as it can be now that it is out in the wild file system frontier). If you using mac or linux you will need to use openssl to secure it with a key.
+
+
Use it only when you want to take the pfx out of Azure and use it somewhere else. You can also use KeyVault APIs (which can run in any platform) to directly pull the secret when you need it in your code which is much more safer than keeping a file around.
+
+
Export experience - Click the “Open KeyVault Secret”
+
+
+
+
KeyVault Secret UI - Click the Current version
+
+
+
+
Download Pfx - Click “Download as a certificate” button
+
+
+
+
Epilogue
+
+
Looking forward to hearing more from you, we like to keep our //DevTalk series a quick informal blog series that bring you direct updates from us on improvements across App Service that we keep tinkering out in the service. We drive these changes based on customer feedback, support cases, user voice, internal DLs and posts like these. We look forward to feedback, asks and comments on the new improvements and old to help us develop the service you love to use 💖.
+
+
+
+
+
+
+ less than 1 minute read
+
+
+
+ • By Tulika Chaudharie
+
+ • September 22, 2023
+
+
+
We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for bo...
';
+ }
+ resultdiv.append(searchitem);
+ }
+ });
+});
diff --git a/assets/js/lunr/lunr-store.js b/assets/js/lunr/lunr-store.js
new file mode 100644
index 0000000000..8a15872039
--- /dev/null
+++ b/assets/js/lunr/lunr-store.js
@@ -0,0 +1,1841 @@
+var store = [{
+ "title": "Azure Functions The Journey",
+ "excerpt":"Our team was excited to recently release a preview of the new Azure Functions service at //build. We’ve done some blogging about the service already (e.g. Introducing Azure Functions), but in this post we’d like to delve a bit behind the scenes and discuss how the project started and the journey we’ve taken to arrive at where we are today. We’ll discuss the Functions Runtime, the Dynamic Compute layer (“Serverless”) as well as the Functions Portal, and see at a high level how all those pieces evolved and came together into a cohesive product. It’s been a fun ride for the team, and it’s only just begun :) The evolution of this project is a great example of identifying synergies across a bunch of existing platform pieces, and connecting them together into a new product offering. In Azure App Service we already had many of the building blocks in place to enable us to rather quickly execute on the Azure Functions vision. By leveraging these existing assets and bringing in new innovations and functionality we were able to pull the project together pretty quickly. WebJobs SDK In Chris’s //build talk Introducing Azure Functions he explained how Azure Functions is built on the Azure WebJobs SDK. The WebJobs SDK has existed for a couple years now, and we have many customers happily using it to build backend processing jobs that trigger on a wide variety of event sources. The WebJobs SDK has a simple declarative programming model that makes it very easy to write sophisticated job functions with a minimal amount of code. Here’s an example: public static void ProcessOrder( [QueueTrigger(\"orders\")] Order order, [Blob(\"processed/{Id}\")] out string receipt, TraceWriter log) { log.Verbose(string.Format(\"Processing Order {0}\", order.Id)); // business logic receipt = \"<some value>\"; } When hosted by the WebJobs SDK JobHost in a vanilla .NET Console application, this function will be automatically triggered whenever a new queue message is added to Azure Queue “orders” and the queue payload will be deserialized into an instance of the Order POCO. The function also automatically binds to an output Blob using the “Id” property from the incoming message as part of the blob path. With this programming model, your job function just focuses on its business logic and doesn’t have to take care of any of the storage operations. Awesome! The hosting model for such functions using the WebJobs SDK is to deploy them as Azure WebJobs. This works great and offers a lot of flexibility, and continues to be a very popular feature of Azure App Service. Functions Runtime Around the middle of last year, we started discussing what it would take to bring this simple programming model to other languages – we’d had customers ask us for this as well. Not everyone is a .NET C# programmer, yet many would like to use these WebJobs SDK patterns. So we started some prototyping efforts on this and came up with a model that allowed us to leverage the existing tried and true .NET WebJobs SDK runtime, layering on a new JSON description model for the metadata. The result is that you can write the same function as above in Node.js (or other languages): module.exports = function (context, order) { context.log('Processing order', order.id); // business logic context.bindings.receipt = \"<some value\"; context.done(); } You’ll notice that this function is structurally the same as the C# function above. That’s because it maps to the same runtime implementation. Declarative code attributes are just one way of specifying metadata. We realized that we could capture the same information in a simple JSON description file. Here’s the corresponding metadata file describing the bindings for this function (i.e. all the bits that are in the declarative attributes in the C# example): { \"bindings\": [{ \"type\": \"queueTrigger\", \"name\": \"order\", \"direction\": \"in\", \"queueName\": \"orders\" }, { \"type\": \"blob\", \"name\": \"receipt\", \"direction\": \"out\", \"path\": \"processed/{id}\" }] } The basic idea is that we can use this metadata to generate an in memory adaptor between various languages and the .NET WebJobs SDK runtime. We effectively generate the C# function you see above, and the method body of that function simply delegates to the actual user function (i.e. the Node.js function you wrote). An Azure Function can then just be a simple function.json metadata file describing the function bindings, along with a collection of one or more script files implementing the function. Here’s the same example as above, using the same metadata file, with the function written as a Windows BAT file: SET /p order=<%order%> echo Processing order '%order%' echo '<some value>' > %receipt% That same metadata file can be used to describe a function in any of our 7 supported languages. Of course each language has its own quirks and capabilities, and some are more suited than others for various tasks. The main point here is that we can have the same triggering/binding runtime for all of these languages, allowing each language to map to that model in its own way. BAT files are somewhat limited, but through environment variables and file streams, they can both receive inputs and write outputs, which the Functions runtime automatically maps to the underlying Azure Storage artifacts. Having Azure Functions build on the core WebJobs SDK means we don’t have to write and maintain different versions of the WebJobs SDK per language, which is a huge engineering win. We have a single core runtime that handles all our binding/triggering logic, and investments we make in that core benefit functions as well as all our WebJobs SDK customers. It also means that all the trigger/binding Extensions that people write for the core SDK can also be used in Functions. We’ll continue investing heavily in the core WebJobs SDK and Extensions both for our traditional customers as well as for Azure Functions. WebHook Support Another important area we started focusing on was our WebHooks story. The ability for functions to be triggered on Azure Storage events is great, but we’ve had WebJobs customers asking us for the ability to trigger their job functions via WebHook requests as well. We had already experimented with this last year by writing a WebHooks Extension which worked well, but had a big drawback stemming from the fact that WebJobs run under the Kudu SCM site, which means that basic auth credentials are required to make requests. That’s a deal breaker for most WebHook integration scenarios, since you want the ability to hand out a URL with a simple auth code that is restricted to allowing only that endpoint to be reached. To address this, we decided to package the Functions Runtime as a site extension that runs in root of a WebApp. This means that it is NOT behind the SCM endpoint, allowing us to achieve the auth patterns required. This enabled us to expose a simple set of authenticated endpoints for WebHook functions. We also integrated the ASP.NET WebHooks library into this, allowing us to leverage the large number of WebHook providers that library supports, giving us first class support for providers like GitHub, Slack, DropBox, Instagram, etc. So at this point we had a flexible Functions Runtime that supported the full WebJobs SDK triggering/binding model for 7 languages (Node.js, C#, F#, Bash, BAT, Python, PHP), that also had an HTTP head supporting a wide array of WebHook integration scenarios. Dynamic Compute In parallel with the above runtime work, we were also having discussions about Serverless Computing and what we wanted to do in that space. We realized that this work we were doing for WebJobs was highly synergistic. We were developing a flexible, multi-language function runtime that could run user code in a sandboxed environment at high scale. However, the traditional WebJobs model requires users to create and manage the WebApp host that those WebJobs run on. What if we were able to abstract that portion of things away so users only had to write the functions themselves, and we’d handle all the deployment and scale concerns? Basically we’d have the WebJobs SDK as a Service. Eureka! We spun up a team to go off and investigate that portion of the plan – “Dynamic Compute”. This was the point in the project where we grew quickly from a small handful of people into a much larger team – our scrum meetings were growing daily by 2-3 people it seemed :) Our Dynamic Compute layer is responsible for automatically scaling functions out as load increases, and scaling back when it decreases. The result for the end user is that they don’t have to worry about this at all, and they only get billed for the compute time they actually use. The Dynamic Compute area of the project is large and also includes other service aspects like monitoring and diagnostics, telemetry, etc. This area deserves its own blog post in the future. Functions Portal The next thing we started focusing on was a portal experience to make it really easy to author and manage these functions. In the traditional WebJobs SDK model, you compile and deploy a .NET Console application (JobHost) that contains all your precompiled job functions. For Azure Functions the deployment model is much simpler. The Functions Runtime was designed to have a very simple file system layout. That facilitates a straight forward Portal UI that operates on those files via the Kudu APIs. We could have a simple portal editor that allowed you to create/edit these files and push them into the function container (the WebApp running the functions). The simple file system model also makes it possible to deploy Azure Functions via ARM templates. That is actually possible today, but not documented well yet. The team was able to get a Portal up and running pretty quickly and we were all very excited to be able to start using it to play with the nascent product. With the Portal in place things really started feeling like they were coming together! We were able to start having the wider team play with the product which drove lots of usability discussions/improvements and also helped us start working the bugs out. When the Portal work started, as with the Functions Runtime we had one or two people working on it, but as that early work gained traction and our scope/plans increased, we on-boarded more people. Scrum meetings got larger still :) Templates The simple file system model for functions also allowed us to develop the awesome template model you see today in the Functions Portal. We started churning out simple metadata/script templates for common scenarios across the various languages: “QueueTrigger – Node”, “GitHub WebHook C#”, etc. The idea is to have simple “recipes” or starting points for your functions that run immediately out of the box, that you can then customize and extend to your needs. In the future we hope to allow the community to also author such templates to drive an ecosystem. Extensibility Another area we focused a lot on leading up to our //build announcement of Azure Functions was a new set of WebJobs SDK Extensions that we made available in Functions. We released the WebJobs SDK Extensibility model last fall, which opened the programming model up to new trigger/binding sources. Our team had already seeded the community with some new useful extensions (e.g. TimerTrigger, FileTrigger, SendGrid binding, etc.) in the WebJobs SDK Exensions repo. We’ve also had community members start authoring their own extensions. Since Functions is built on the SDK, all these extensions can be made available to Azure Functions as well. There were many extensions we knew we wanted to write but didn’t have the time, and with our new larger team we had the resources to start cranking some of those out. In the last couple months we’ve added the following additional extensions and made them first class in Functions: EventHub, DocumentDb, NotificationHub, MobileApps, and ApiHub. This is only the beginning – there are many more extensions planned, and we expect the community to author more as well. We’re also working on an easy model for allowing 3rd parties to onboard their extensions into Functions. Stay tuned for that. Another cool thing is that we decided early that we wanted to do all our work open source, just as we have with the core WebJobs SDK and WebJobs SDK Extensions repos. So we created the WebJobs SDK Script containing the Functions Runtime. Similarly, the Functions Portal is also open source: AzureFunctionsPortal. In closing, all of the above has been a pretty high level overview of the various pieces of the project and how they came together: the Functions Runtime, Functions Portal, and Dynamic Compute. In future posts, we’ll delve more into the details of these various areas :) ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2016/04/27/Azure-Functions-The-Journey.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "App Service supports Node.js v6",
+ "excerpt":"We’re happy to announce that Azure App Service supports Node.js v6.0.0. Node.js v6.0.0 is a major step forward for the Node.js community thanks to the efforts of so many to increase the ES6 compatibility coverage, as well as many performance and security improvements. We’ll follow the developments of v6 closely (including v6.1.0 which came out last night) as it moves towards a new v6 LTS version, at which point we’ll plan on recommending developers creating new apps on App Service use that version, as we currently do for the v4 LTS version. Get started with Node.js on Azure App Service here. Using Node.js v6.0.0 on Azure App Service To use Node.js v6.0.0, you can specify your version in your package.json file, as detailed on our Node.js documentation page. It’s as simple as adding the following JSON to the file: \"engines\": { \"node\": \"6.0.0\" }, Once you’ve done that and you redeploy your code via git/CI, our deployment process will select the v6.0.0 Node.js version. We default to using npm version v3.8.6 for Node.js v6.0.0. Getting started with Node.js on Azure App Service If you haven’t yet tried using Node.js on Azure App Service, it is one of the easiest ways of hosting a Node.js application in the cloud. Azure App Service makes it easy to create a Node.js website hosting whichever framework you like, using the developer tools you prefer, and all with little to no management overhead. This awesome doc written by Cephas Lin walks you through creating a Node MVC site via Yeoman, creating an Azure Web App via the x-plat cli (npm i -g azure-cli), modifying the port setting to use the environment variable provided by the App Service runtime, creating a git commit with all those changes, and then pushing it to Azure via git. If you have an existing Node.js website that you’d like to try moving to Azure, just try following the steps starting from #4. If you don’t have an Azure subscription, you can get a free trial or get a temporary one for an hour via “Try App Service”. Next steps Learn about Node.js on Azure App Service Try App Service Get an Azure Subscription ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2016/05/06/App-Service-supports-Node.js-v6.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Speed up your Joomla Web App on Azure Web Apps",
+ "excerpt":"Every website for a company or personal wants to engage their customers , but if your website takes too long to load then you lose your users. For different types of applications, there are different options to prevent this from happening . In the blog post below we are going to discuss how we can improve Joomla web app fast and respond to users quickly by just making some or all the tweaks mentioned below. Enable Joomla Caching Caching is not enabled by default when you set up Joomla web app. Joomla does the following when displaying a page: get the content from its database loads all the plugins, components and/or modules loads your template file finally brings this all together in a single page rendered in visitor’s browser This workflow of tasks can take time. Joomla has built-in caching mechanism that can help to load the page faster. Joomla supports two types of caching well explained here. Conservative caching is the standard type of caching. The caching process work as described below: When a page is requested by a user, Joomla checks if there is a version of that page requested that is in its cache directory. If the page exists and hasn’t expired , Joomla will serve it to the visitor. Otherwise, a cached version of the page is created, and that cached version will be served to the visitor, and to every other consequent visitor, as long as the page is not expired. Progressive caching process is different from conservation caching. The caching process works as described below: When a page is requested by a user , Joomla checks if a cached version of that page exists for that visitor . If its exists and hasn’t expired then it’ll be served to the visitor, otherwise, Joomla will create the cached page for that specific visitor and then will serve it to the user. If another visitor who had visited that same page previously and visits that page the second time, then Joomla will not serve the cached page of the previous visitor, instead, it will create a cached version of that page specifically for that user, and then serves it to him. To enable the Joomla caching, Go to System -> Global Configuration Click on the System tab and find the Cache Settings Select ON - Conservative caching option with cache handle being Windows Cache ( Wincache) and Click on Save Go to Extensions -> Plugin Manager and Enable the System - Page Cache core plugin. Note if this plugin is not enabled, caching will not work even though Global configuration settings is set to use Conservative caching You can use additional caching extensions to improve the caching capability of Joomla such as JotCache and Cache Cleaner. Use Joomla Memcache caching You can opt for using Joomla Memcache caching mechanism instead of built-in caching feature. Azure web app supports Memcache protocol with Azure Redis cache. To lean more , read this article. Enable Joomla Compression Gzip Compression is enabled by default on web app at the server level. But for the application to use the GZip compression , you need to enable it within Joomla configuration. Login to the Joomla web app admin dashboard and go to System -> Global Configuration. Click on the Server tab and enable GZip page compression. Click on Save to save your changes. Use IIS output caching The IIS Output Caching feature targets semi-dynamic content. It allows you to cache static responses for dynamic requests and to gain tremendous scalability. Update your web.config and add the following section to cache your content. <?xml version=\"1.0\" encoding=\"UTF-8\"?> <configuration> <system.webServer> <caching> <profiles> <add extension=\".php\" policy=\"CacheUntilChange\" /> </profiles> </caching> </system.webServer> </configuration> To learn more , check out this article. Remove extensions not in use Since Joomla would need to identify which extensions to use it has to scan through all the extensions. This can cause your page to take longer to load. If you have any extensions not in use , please remove them from your production app.Note You can have those extensions in your development or testing environment sites to identify the best extension that fits your needs. Minify CSS and JS Use extensions like JCH Optimize which minifies , compresses Javascript to improve page response time. Use CDN Enable Azure CDN with your Azure web app to improve performance. For details , check out this video. Stay up-to-date Joomla and its extensions may have updates that can impact the performance of your web application. Make sure you have the latest bits of Joomla CMS , Latest PHP version and the Joomla extensions you have installed within your Joomla app. Optimize your tables Optimize your Joomla app database using phpMyAdmin . If you have never used PHPMyadmin with Azure web apps , check out this article first. Select all or some of the tables and Select Optimize Table operation to execute. This post also appears on Sunitha Muthukrishna Blog. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2016/05/09/Speed-up-your-Joomla-Web-App-on-Azure-Web-Apps.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Disable Session affinity cookie (ARR cookie) for Azure web apps",
+ "excerpt":"Azure app service allows you to auto scale your web app by dynamically adding web server instances to handle the traffic to your web app. Azure app service uses Application Request Routing IIS Extension to distribute your connecting users between your active instances serving up the content. ARR cleverly identifies the user by assigning them a special cookie (known as an affinity cookie), which allows the service to choose the right instance the user was using to serve subsequent requests made by that user. This means, a client establishes a session with an instance and it will keep talking to the same instance until his session has expired. If you already have a web app on Azure app service , just browse the app and use browser debugger ( click on F12) to see the list of cookies. In the list of cookie you will see ARRAffinity Cookie. There are situations where in keeping the affinity is not desired. For example, if you are getting way too many requests from a single user and the requests going to the same web server instance can overload it. If maintaining session affinity is not important and you want better load balancing , it is recommended to disable session affinity cookie. Follow the steps for either Azure portal or Azure resource Explorer to disable the session affinity cookie: Disable using the Azure Portal Login to the Azure portal Browse App Services and select your web application. Click on Settings > Application Settings. You will find the ARR affinity setting under General Settings Select off Disable using Azure Resource Explorer Go to Azure resource explorer. Click on subscriptions Click on your azure subscription in which your web app is located. Click on resourcegroups Click on the resource group where the web app is located. Click on Microsoft.Web. Click on sites **and Select your web app . Click on **Edit to make your changes . Search for clientAffinityCookie and set it to false Click on PUT to save your changes. That’s it! You have now disabled the session affinity cookie. You can browse your web app and click on F12 key to access the browser debugger and view the cookies. For an app without Session affinity cookie you will not see ARRAffinity in the list of cookies. Without the cookie the requests for your web app, will be distributed evenly across all the instances serving your web app content. You can achieve better load balancing for your web app. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2016/05/16/Disable-Session-affinity-cookie-(ARR-cookie)-for-Azure-web-apps.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Azure App Service Web App troubleshooting blade and tools",
+ "excerpt":"I have been fortunate to have an opportunity to Build/Ship/Support on premise products as well as cloud services for Microsoft. One of my biggest take aways from this experience is, “You ship an on-premises product and make it’s issues/bugs your CUSTOMER’S problem. You ship a service in the cloud and now the same issues/bugs are YOUR problem!” Azure App Service Web App team aggress to this philosophy and has been aggressively investing in troubleshooting and diagnostic tools. I highly recommend watching this one hour “short” video (short from troubleshooting standards) from my //Build 2015 session, When bad things happen to good apps. It all started as an experiment outside of the Azure portal, we called it Support Portal. It was a success and was ready to be first-class citizen inside Azure portal. It found a place inside SUPPORT + TROUBLESHOOTING section of your Web App settings. We soon realized that while these tools are great ingredients which are better served as a recipe. In another words, Please tell me what tools to use when and how? This is where Troubleshoot Blade comes handy. Troubleshoot blade Troubleshoot blade is part of SUPPORT + TROUBLESHOOTING section of key Azure Services like Web Apps, Virtual Machine, SQL. etc. Every participating Azure Service populates this blade with their most common and usually top support issues. This blade has three top level sections which we will cover in detail soon. Resource health check Common support issues and solutions Ability to submit support request to Azure Customer Support Resource health check for Web Apps Resource Health Check for Web Apps is like a doctor that attempts to diagnose an issue (runtime issues) with your application to be either service level outage or application specific issue. It makes this determination mainly by reading two distinct signals. First signal is health of Canary Web App (static web page running under every VM instance) and second signal is active live site incident (service issue). - Scenario 1: IF Canary Web App signal IS healthy (HTTP 200 OK) and there IS NO active live site incident impacting your Web App THEN it will say Healthy, meaning we think life is good, but if you think otherwise then it is most likely an application issue. Scenario 2: IF Canary Web App signal IS NOT healthy (HTTP 200 NOT OK) and there IS an active live site incident impacting your Web App THEN it will say Unhealthy, meaning we think life is not good and someone in Redmond is actively working to resolve this issue. Scenario 3: IF Canary Web App signal IS NOT healthy (HTTP 200 NOT OK) and there IS NO active live site incident impacting your Web App THEN it will say Unhealthy meaning we think life could be better and doctor needs to perform more diagnostics. NOTE: Resource Health Check for Web Apps is NOT available to FREE and Shared offerings (as there is no SLA for these offerings and hence no canary web app). Putting an analogy here would be recipe for disaster, so I would stop right here. Common solutions This is the place where we put together a recipe (step-by-step troubleshooting guide) to resolve a specific issue using some of the ingredients (troubleshooting tools). Here we list out our common supportability issues based on symptoms or scenarios. In this blog post I will pick one scenario and explain the steps in detail. #### My App is returning HTTP 5xx errors You are here because resource health check told you it is Scenario 1 or Scenario 3. Assess the HTTP errors impact using Live HTTP traffic chart When my Web App starts giving HTTP 5xx errors my 1st instinct is to try and asses the impact. Are all requests failing? What percent of requests are failing? etc. “Live HTTP traffic” chart is a great way to assess the impact. This tools shows you aggregated live traffic for the selected Web App across different hostnames. There is hardly 10 seconds delay in charting. It basically aggregates your HTTP server logs from all the instances, including multi region deployments behind traffic manager. It then splits our success vs. failures and charts them. Image above shows about 30% of my requests are failing and it is not entire Web app down situation. (Blue represent success, Red represents failures). I can choose to filter the graph by hostnames etc. Identify instance(s) exhibiting poor application performance Now we know that about 30% of my requests are failing, would not it be nice to know if these failures are tied to single instance (if my web app is running multi-instances) or distributed across all? Or I just want to check the load distribution across various instances, or may be check CPU/Memory usage for last one hour across various instances. All of above mysteries can be solved by clicking on this view. This view provides you critical statistics about your Web App (site) per instances over span of Last 1 hour, Last 24 hours and Last 5 days Image above shows I have two instances (RD0003FF451561 and RD0003FF454F62) in last one hours. If I had more or less instances in last 24 hours or five days, it would show them all regardless of current configuration. I think that’s kind of cool, especially when investigating past issues. The mage above also confirms my load was equally distributed across both the machines and both of them were giving HTTP 5xx, so this issue is not tied to a single instance. I can also check the CPU/Memory/Network IO etc. by scrolling down the charts. Attempt to resolve the issue by using Advanced Application restart If the previous step helped you identify an instance that is “bad” then this blade is a pure blessing. Just select the “bad” instance and click on Restart. If it is all of them then you can select them all with Restart Sleep Timer of 90 seconds and click away the Restart button. Yep, it’s that easy! ] Let’s see what the “Restart button” does in background. For start, this is NOT same as Restarting your Web App. Web App Restart is ruthless beast that goes out and fires restart across all instances at the same time. (If you have single instance then the impact is the same). This is NOT same as Rebooting your VM. Well in Azure App Service, you can’t reboot your VM (yet), at least by choice. (If you really want to reboot the VM instance, then simply trick the system by changing the scale Up or Down. That is switch to medium from small or large etc.) This is simply graceful restart of your Web App process (w3wp.exe) in an overlapped recycling manner. Similar to Costco registers where they open new lane for check out before closing the old one. If you happen to be in the old one (existing requests to your web app) you get 90 seconds to finish your business (well not quite like Costco, but you get the point), while all new checkouts (new incoming requests) goes to the new open lane. Thus minimizing the impact down to few handful requests. “Restart Sleep timer” of 90 seconds adds additional layer of protection by waiting for 90 seconds before going to other instances. If you have multiple Web Apps running on same instance then it does not impact other Web Apps. It only restarts Web App you initiated this operation from. Identify highest CPU/Memory consuming Web app(s) within your App Service Plan Let’s refresh our memory little bit and bring back Resource Health Check Scenario 3. This blade helps you find out the offending Web App in the App Service Plan. We named this blade “App Service plan Metric per Instance”. It does exactly what it says. This view will help you quickly identify highest CPU/Memory consuming Web App (Site) in your Plan. Above image indicates that I have 2 Web Apps (Sites) in the App Service Plan. DemoDaas seems to be the one using all CPU and Memory in this case. At the same note, you can also observe that PHPDemo could be taking all CPU and Memory, hence impacting performance for DemoDaas. You can use this view to separate out the culprits from victims and go to Step 3 to click on “Restart Button” for culprit Web App. Finally, Restart is really not an answer to all the problems and that’s where the Restart button is not that glorious. If HTTP 5xx is because a bug in your application and not the hostile surrounding it found itself in, then restarts are not really going to help. This is where we move to next Step. Check out the application event logs to understand the potential root cause This is really old school event viewer logs. The beauty of this feature here is that, these logs are aggregated across multiple instances (if you have multiple instances) into single view. You can filter them per instance or other attributes of your choice. It only contains logs are that specific to this Web App and it’s life cycle, so they are pre filtered for your need. Enable FREB Logging This step will help you identify source of HTTP 5xx errors or Slow Performance. It won’t really tell you exact root cause (unless you are the developer who check-in had the bug then knowing the source is usually enough). Please watch this short video by Felipe Barreiros that explains the feature. #### Recommended documents, Profilers like App Insight, New Relic etc. It finally provides links to some recommended documentations to will help peel the onion even further. Application bug that are easily reproducible are best root caused using some sort of profiler or remote debugging inside stage/QA environment. Need help? If none of above helped and you want to engage Microsoft Azure Support team then journey begins by clicking on open a Support request. Do try out other common scenarios and let us know the feedback by simply clicking on Feedback smiley at the top of the blade. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2016/05/18/Azure-App-Service-Web-App-troubleshooting-blade-and-tools.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Deploying Azure Web App Certificate through Key Vault",
+ "excerpt":"As part of App Service Certificate (ASC) offering, we now support certificate deployment through Azure Key Vault (AKV). ASC stores the private certificate into a user provided Key Vault Secret (KVS). When an ASC is deployed into a Web App, Web App Resource Provider (RP) actually deploys it from the KVS associated with ASC. Essentially, ASC and Web App are loosely connected through Azure Key Vault. If you manually upload a private certificate into a KVS then you can use the same feature for deploying your own certificate into Web App through AKV. Prerequisites In order to use this feature, first you need an Azure Key Vault. This Key Vault needs to be in the same subscription as your web app but it need not be in the same region as your Web App. Web App doesn’t have a runtime dependency on Key Vault. When you deploy a certificate, Web App RP reads it from the KV and caches it in its management database. It need not even be in the same resource group. If you don’t have a KV then you can use the following PowerShell command to create a new one: New-AzureRmKeyVault -VaultName akurmitestvault -ResourceGroupName keyvaulttestrg -Location \"eastus2\" -Sku standard By default, the Web App RP doesn’t have access to customer KV. In order to use a KV for certificate deployment, you need to authorize the RP by executing the following PowerShell command: Set-AzureRmKeyVaultAccessPolicy -VaultName akurmitestvault -ServicePrincipalName abfa0a7c-a6b6-4736-8310-5855508787cd -PermissionsToSecrets get The RP requires read access to KV. abfa0a7c-a6b6-4736-8310-5855508787cd is the RP service principal name and it remains same for all Azure subscriptions. Note for Azure Gov cloud environment you will need to use 6a02c803-dafd-4136-b4c3-5a6f318b4714 as the RP service principal name in the above command instead of ‘abfa0a7c-a6b6-4736-8310-5855508787cd’. Last thing you need is a KVS that contains the PFX certificate you would like to deploy. Before deploying a certificate, the RP performs the following checks on KVS: It actually contains a PFX certificate that’s not password protected Content type of the secret should be ‘application/x-pkcs12’ You can use the following PowerShell snippet to upload a PFX certificate from your machine into a Key Vault secret: $pfxFilePath = \"F:\\KeyVault\\PrivateCertificate.pfx\" $pwd = \"[2+)t^BgfYZ2C0WAu__gw[\" $flag = [System.Security.Cryptography.X509Certificates.X509KeyStorageFlags]::Exportable $collection = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2Collection $collection.Import($pfxFilePath, $pwd, $flag) $pkcs12ContentType = [System.Security.Cryptography.X509Certificates.X509ContentType]::Pkcs12 $clearBytes = $collection.Export($pkcs12ContentType) $fileContentEncoded = [System.Convert]::ToBase64String($clearBytes) $secret = ConvertTo-SecureString -String $fileContentEncoded -AsPlainText –Force $secretContentType = 'application/x-pkcs12' Set-AzureKeyVaultSecret -VaultName akurmitestvault -Name keyVaultCert -SecretValue $Secret -ContentType $secretContentType # Change the Key Vault name and secret name Deploying Key Vault Certificate into Web App After completing all prerequisites, now we are ready to deploy the certificate into a Web App. Currently, Azure portal doesn’t support deploying external certificate from Key Vault, you need to call Web App ARM APIs directly using ArmClient, Resource Explorer, or Template Deployment Engine. I will be using ARMClient for the rest of this blogpost. You can also use Resource Explorer to do everything described below. We need to find the resource group for certificate resource before calling the ARM APIs as it ideally we should use App Service Plan’s resource group, you can find this from ‘serverFarmId’ property of the site resource: ARMClient GET /subscriptions/fb2c25dc-6bab-45c4-8cc9-cece7c42a95a/resourceGroups/Default-Web-EastAsia/providers/Microsoft.Web/sites/appservicecertificatedemo?api-version=2016-03-01` And here is the response: { \"id\": \"/subscriptions/fb2c25dc-6bab-45c4-8cc9-cece7c42a95a/resourceGroups/Default-Web-EastAsia/providers/Microsoft.Web/sites/appservicecertificatedemo\", \"name\": \"appservicecertificatedemo\", \"type\": \"Microsoft.Web/sites\", \"location\": \"<strong>East Asia</strong>\", ... \"serverFarmId\": \"<strong>/subscriptions/fb2c25dc-6bab-45c4-8cc9-cece7c42a95a/resourceGroups/Default-Web-EastAsia/providers/Microsoft.Web/serverfarms/appservicecertificatedemoplan</strong>\", ... } } Also note the following properties from this response: Location since certificate resource needs be created in the same location as server farm. ServerFarmId as it would be required to create certificate resource. We would also use the resource group name specified in this resource id. We also need Key Vault resource URI to deploy the certificate. You can get this value by executing the following PowerShell command: Get-AzureRmKeyVault -VaultName akurmitestvault Vault Name : akurmitestvault Resource Group Name : keyvaulttestrg Location : eastus2 Resource ID : <strong>/subscriptions/fb2c25dc-6bab-45c4-8cc9-cece7c42a95a/resourceGroups/keyvaulttestrg/providers/Microsoft.KeyVault/vaults/akurmitestvault</strong> Vault URI : https://akurmitestvault.vault.azure.net/ ... Once you have these values, you can use the following ARMClient command to upload the certificate into your Web App. Note that in order to call this API, the caller needs to have write access to the Key Vault account specified in the request body. ARMClient.exe PUT /subscriptions/<Subscription Id>/resourceGroups/<Server Farm Resource Group>/providers/Microsoft.Web/certificates/<User Friendly Resource Name>?api-version=2016-03-01 \"{'Location':'<Web App Location>','Properties':{'KeyVaultId':'<Key Vault Resource Id>', 'KeyVaultSecretName':'<Secret Name>', 'serverFarmId':'<Server Farm (App Service Plan) resource Id>'}}\" Here is an example wil my values, yours will be different. ARMClient.exe PUT /subscriptions/fb2c25dc-6bab-45c4-8cc9-cece7c42a95a/resourceGroups/Default-Web-EastAsia/providers/Microsoft.Web/certificates/keyvaultcertificate?api-version=2016-03-01 \"{'Location':'East Asia','Properties':{'KeyVaultId':'/subscriptions/fb2c25dc-6bab-45c4-8cc9-cece7c42a95a/resourceGroups/keyvaulttestrg/providers/Microsoft.KeyVault/vaults/akurmitestvault', 'KeyVaultSecretName':'keyVaultCert', 'serverFarmId': '/subscriptions/fb2c25dc-6bab-45c4-8cc9-cece7c42a95a/resourceGroups/Default-Web-EastAsia/providers/Microsoft.Web/serverfarms/appservicecertificatedemoplan'}}\" And here is the response: { \"id\":\"/subscriptions/fb2c25dc-6bab-45c4-8cc9-cece7c42a95a/resourceGroups/Default-Web-EastAsia/providers/Microsoft.Web/certificates/keyvaultcertificate\", \"name\":\"keyvaultcertificate\", \"type\":\"Microsoft.Web/certificates\", \"location\":\"East Asia\", \"tags\":null, \"properties\":{ \"friendlyName\":\"\", \"subjectName\":\"appservicecertificatedemo.com\", \"hostNames\":[ \"appservicecertificatedemo.com\" ], \"pfxBlob\":null, \"siteName\":null, \"selfLink\":null, \"issuer\":\"appservicecertificatedemo.com\", \"issueDate\":\"2016-05-02T21:09:24-07:00\", \"expirationDate\":\"2017-05-02T00:00:00-07:00\", \"password\":null, \"thumbprint\":\"**F454D4277D449D8CD2384B63D7AA2F2F7F3766E4**\", \"valid\":null, \"toDelete\":null, \"cerBlob\":null, \"publicKeyHash\":null, \"hostingEnvironment\":null, \"hostingEnvironmentProfile\":null, \"keyVaultId\":\"/subscriptions/fb2c25dc-6bab-45c4-8cc9-cece7c42a95a/resourcegroups/keyvaulttestrg/providers/microsoft.keyvault/vaults/akurmitestvault\", \"keyVaultSecretName\":\"keyvaultcert\", \"webSpace\":\"eastasiawebspace\", \"tags\":null } } After executing this command, the certificate would be listed under ‘Custom Domains and SSL’ blade in Azure portal. Now you can use this certificate to create SSL bindings just like a regular certificate as described in this article. You can also use the following ARMClient command to create SSL binding for custom hostname ‘appservicecertificatedemo.com’. If the custom hostname you want to use in this call is not already added to the website, then you should also create the DNS records required for verification as described here. Command: ARMClient.exe PUT /subscriptions/fb2c25dc-6bab-45c4-8cc9-cece7c42a95a/resourceGroups/Default-Web-EastAsia/providers/Microsoft.Web/sites/appservicecertificatedemo/hostnameBindings/appservicecertificatedemo.com?api-version=2016-03-01 \"{'Location':'East Asia','properties':{'sslState':'SniEnabled','thumbprint':'F454D4277D449D8CD2384B63D7AA2F2F7F3766E4'}}\" Response: { \"id\": \"/subscriptions/fb2c25dc-6bab-45c4-8cc9-cece7c42a95a/resourceGroups/Default-Web-EastAsia/providers/Microsoft.Web/sites/appservicecertificatedemo/hostNameBindings/appservicecertificatedemo.com\", \"name\": \"appservicecertificatedemo/appservicecertificatedemo.com\", \"type\": \"Microsoft.Web/sites/hostNameBindings\", \"location\": \"East Asia\", \"tags\": null, \"properties\": { \"siteName\": \"appservicecertificatedemo\", \"domainId\": null, \"azureResourceName\": \"appservicecertificatedemo\", \"azureResourceType\": \"Website\", \"customHostNameDnsRecordType\": \"A\", \"hostNameType\": \"Managed\", \"sslState\": \"SniEnabled\", \"thumbprint\": \"F454D4277D449D8CD2384B63D7AA2F2F7F3766E4\" } } If you want to create an IP-based SSL binding instead of SNI then replace ‘SniEnabled’ with ‘IpBasedEnabled’ in the ARMClient command. You can also access this certificate from your Web App once it’s uploaded instead of creating SSL binding as described in this blog. Rotating Certificate Once a certificate has been deployed through KVS, follow these steps to rotate it: Update the KVS with a new certificate Call the Create Certificate API again with the same body. This would update the certificate resource and migrate all Web Apps that are using it to the new certificate The Web App RP has a batch job that periodically syncs all Web App certificate resources with the associated Key Vault secret so if you don’t call the Create Certificate API after updating the KVS, then this periodic job would eventually migrate the Web Apps to the new certificate. Deploying other secrets from Key Vault You may ask, deploying a certificate from KVS is fine. But what about deploying other secrets from KV such as connection strings? Currently, our platform only supports certificate deployment through Key Vault. You can however, use this feature and write some custom code to deploy generic Key Vault secrets into your Web App. Say your application requires a symmetric encryption key and a SQL connection string. You can follow these steps to deploy your app secrets through Key Vault: Store the connection string and symmetric key in a Key Vault as individual secrets Create a self-signed certificate and authorize it to read Key Vault Secrets as described here Store this certificate in the Key Vault Deploy the certificate through KVS and create the required App Setting so that it would be available locally for your Web App to use In the Application_Start event, use this certificate to read secrets from Key Vault and update web.config if required ARM Template to deploy and Assign KV Certificate You can use the following ARM template to deploy a certificate through KVS and create SSL bindings for a custom hostname: https://azure.microsoft.com/en-us/documentation/templates/201-web-app-certificate-from-key-vault/ ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2016/05/24/Deploying-Azure-Web-App-Certificate-through-Key-Vault.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Introducing Failure History (appLens) for Azure App Service Web App",
+ "excerpt":"“Why was my Web App down?” is the million-dollar question that usually follows with more questions than answer, for example: “Was it cloud provider issue?”, “Was it a deployment I rolled out?” “Was it just abnormal increase in traffic? etc. Getting to the bottom of the issue requires tedious activities like pulling off few logs, aligning them with correct times or even calling Support for help, and this is just first layer of investigation a.k.a “Isolation” or “Peeling the onion”. This process should not take hours and we agree! Introducing Failure History (appLens) for Azure App Service Web App: A tool to visualize various data points in few seconds! What is Failure History? Let me start with little background on the project. Project’s code name is MDH (Make David Happy). David is our rock star engineer (@Lamboin) who spends his day working on customer reported issues. He is the one who tries to answer the million-dollar question for our customers (“Why was my Web App down?”). We watched him pull variety of logs, overlay them and then align the time frames to get the 1st level of isolation. This process was MDS (Making David Sad), and that was one of the inspirations to kick start this project. Failure History (appLens) is an attempt to solve problem described above. It is self-service RCA tool that helps you visualize variety of data points in your web app life cycle in matter of seconds. This visualization helps answer the questions that usually follow our million-dollar question. How it works Failure History (now known as AppLens) can be accessed from “Settings” blade for your Web App. With current release Failure History (appLens) focus on 3 core data points, which are Availability Requests and Failures Deployments Let’s drill down on each of them with a real life examples. Availability This an overlay chart of 2 distinct data points, Organic availability and Container Health (Canary Web App). Organic availability is an aggregated data points of successful HTTP requests vs. Failed HTTP requests to your web app. On the other hand Container Health (Canary Web App) is an aggregated data points of successful HTTP requests vs. Failed HTTP requests to a static page that resides inside same VM (container) as your web app. Both of them are weighted number in percentage. To learn more about the Canary Web App, please read “Resource Health Check” section of my previous blog. I call this chart “Is it me? vs. Is it you?” chart. This literally is best way to isolate application issues vs. platform issues. This chart tries to answer “Was it cloud provider issue?” question. If you see Organic availability chart taking a dip while Container Health chart is at 100% then it surely is an application issue. If you see Organic availability chart taking a dip as well as Container Health chart taking a dip then it is most likely platform issue (App Service issue). The reason I say “most likely” is because, a bad web app in app service plan can potentially freeze the container and cause Container health chart to take a dive. To see individual charts at appropriate scale I recommend you filter out an individual graphs by selecting them using radio buttons. Canary Web App concept is NOT applicable to FREE and SHARED web apps and hence that data will be missing for them. Scenario 1: Platform issue ] Scenario 2: High load freezing VM Requests/Failures This is an aggregated data points of total incoming HTTP requests vs. Failed HTTP requests to your web app. This chart can be used to answer “Was it just abnormal increase in traffic?” question. If you see drop in Organic availability chart (right above this chart) following large increase in Total incoming HTTP requests (HTTP Requests counter) then you can conclude that downtime could be related to increase in traffic and maybe I should consider turning on Auto Scale. You can also use this chart to answer “What % of my traffic was failing?” question. To see individual charts at appropriate scale I recommend you filter out an individual graphs by selecting them using radio buttons Scenario 3: Increased traffic causing scale out Deployments This is simple data point indicating time frames when you or someone in your organization did deployment to your web app. This chart tries to answer “Was it a deployment I rolled out?” question. This only shows deployments done via web deploy or Kudu endpoint. It does not cover deployments done using FTP. This is a great data point to co-relate with availability charts and see if Organic availability tanked right after the deployment? This way you can be sure if availability drop is related to your deployment or not. Scenario 4: Bad deployment Finally, few disclaimers for this version of Failure History (appLens): Failure History (appLens) data is at least 15 minutes behind. For issues that are currently happening and you need help then please use our troubleshoot blade. Failure History (appLens) data can go back 7 days to RCA (root cause analysis) issues that happened in past Failure History (appLens) defaults to UTC time ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2016/06/02/Introducing-Failure-History-(appLens)-for-Azure-App-Service-Web-App.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Updates to WebJobs Portal experience",
+ "excerpt":"We’ve recently made updates to the WebJobs Portal experience in the Azure Portal designed to make it easier to set up a scheduled triggered WebJob, access the trigger URL for triggered WebJobs, and other operations like viewing your logs. Creating a scheduled WebJob As you can see in the screenshot, to create a scheduled WebJob requires 3 steps, in addition to the usual steps of naming and uploading your code. Select “triggered” as the WebJob type option Select “Scheduled” as the WebJob triggers option Add a cron tab expression To create a scheduled WebJob in the new experience, you just provide a cron tab expression as part of the creation of your triggered WebJob. This will add a schedule property to your setting.job file which Kudu will then use to call your WebJob. Importantly, this requires “always on” to be enabled. If you wish to have a triggered WebJob called on a schedule without “always on” being required or if the schedule you require is too complicated to be expressed as a cron tab expression, you can continue to use Azure Scheduler by choosing the “WebHook” option for “Triggers”, and then providing the trigger URL to an Azure Scheduler job. This is a departure from how we previously did scheduled jobs, where we’d automatically create a Azure Scheduler job for you. We had a lot of feedback that this wasn’t optimal for all scenarios, so we’ve moved to this new model. Updates to browse WebJobs experience In addition to the triggered WebJobs updates, we’ve redone the browse experience to both bring it in line with the other browse experiences in the portal, as well as expose the trigger URL for triggered WebJobs in an easier to access way. One major experience change is that the logs, delete, and run buttons at the top of the blade correspond with the selected row. You can see this experience in the picture below. We’re always looking for more feedback on the WebJobs experience. You can leave feedback on the WebJobs UX experience at our feedback site or in the comments section down below. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2016/06/06/Updates-to-WebJobs-Portal-experience.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Adjusting the HTTP call with Azure Mobile Apps",
+ "excerpt":"Azure Mobile Apps provides an awesome client SDK for dealing with common mobile client problems - data access, offline sync, Notification Hubs registration and authentication. Sometimes, you want to be able to do something extra in the client. Perhaps you need to adjust the headers that are sent, or perhaps you want to understand the requests by doing diagnostic logging. Whatever the reason, Azure Mobile Apps is extensible and can easily handle these requirements. Android (Native) You can implement a ServiceFilter to manipulate requests and responses in the HTTP pipeline. The general recipe is as follows: ServiceFilter filter = new ServiceFilter() { @Override public ListenableFuture handleRequest(ServiceFilterRequest request, NextServiceFilterCallback next) { // Do pre-HTTP request requirements here request.addHeader(\"X-Custom-Header\", \"Header Value\"); // Example: Adding a Custom Header Log.d(\"Request to \", request.getUrl());// Example: Logging the request ListenableFuture responseFuture = next.onNext(request); Futures.addCallback(responseFuture, new FutureCallback() { @Override public void onFailure(Throwable exception) { // Do post-HTTP response requirements for failures here Log.d(\"Exception: \", exception.getMessage()); // Example: Logging an error } @Override public void onSuccess(ServiceFilterResponse response) { // Do post-HTTP response requirements for success here if (response != null && response.getContent() != null) { Log.d(\"Response: \", response.getContent()); } } }); return responseFuture; } }; MobileServiceClient client = new MobileServiceClient(\"https://xxx.azurewebsites.net\", this).withFilter(filter); You can think of the ServiceFilter as a piece of middleware that wraps the existing request/response from the server. iOS (Native) Similar to the Android case, you can wrap the request in a filter. For iOS, the same code (once translated) works in both Swift and Objective-C. Here is the Swift version: class CustomFilter: NSObject, MSFilter { func handleRequest(request: NSURLRequest, next: MSFilterNextBlock, response: MSFilterResponseBlock) { var mutableRequest: NSMutableURLRequest = request.mutableCopy() // Do pre-request requirements here if !mutableRequest.allHTTPHeaderFields[\"X-Custom-Header\"] { mutableRequest.setValue(\"X-Custom-Header\", forHTTPHeaderField: \"Header Value\") } // Invoke next filter next(customRequest, response) } } let client = MSClient(applicationURLString: \"https://xxx.azurewebsites.net\").clientWithFilter(CustomFilter()) JavaScript & Apache Cordova As you might exepct given the Android and iOS implementations, the JavaScript client (and hence the Apache Cordova implementation) also uses a filter - this is just a function that the request gets passed through: function filter(request, next, callback) { // Do any pre-request requirements here console.log('request = ', request); // Example: Logging request.headers['X-Custom-Header'] = \"Header Value\"; // Example: Adding a custom here next(request, callback); } var client = new WindowsAzure.MobileServiceClient(\"https://xxx.azurewebsites.net\").withFilter(filter); Xamarin / .NET The equivalent functionality in the .NET world is a Delegating Handler. The implementation and functionality are basically the same as the others: public class MyHandler: DelegatingHandler { protected override async Task SendAsync(HttpRequestMessage message, CancellationToken token) { // Do any pre-request requirements here request.Headers.Add(\"X-Custom-Header\", \"Header Value\"); // Request happens here var response = await base.SendAsync(request, cancellationToken); // Do any post-request requirements here return response; } } // In your mobile client code: var client = new MobileServiceClient(\"https://xxx.azurewebsites.net\", new MyHandler()); General Notes There are some HTTP requests that never go through the filters you have defined. A good example for this is the login process. However, all requests to custom APIs and/or tables get passed through the filters. You can also wrap the client multiple times. For example, you can use two separate filters - one for logging and one for the request. In this case, the filters are executed in an onion-like fashion - The last one added is the outer-most. The request goes through each filter in turn until it gets to the actual client, then the response is passed through each filter on its way out to the requestor. Finally, note that this is truly a powerful method allowing you to change the REST calls that Azure Mobile Apps makes - including destroying the protocol that the server and client rely on. Certain headers are required for Azure Mobile Apps to work, including tokens for authentication and API versioning. Use wisely. (Cross-posted to My Personal Blog) ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2016/06/16/Adjusting-the-HTTP-call-with-Azure-Mobile-Apps.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Cross-Post App Service Auth and Azure AD B2C",
+ "excerpt":" This post was cross-posted from CGillum Dev Blog. An exciting new preview feature which was recently added to Azure Active Directory is Azure Active Directory B2C. “B2C” stands for “Business to Consumer” and allows a developer to add user and login management to their application with very little (if any) coding. This also includes login integration with social identity providers like Facebook, Amazon, LinkedIn, etc. Check out their documentation and blog posts for more details. My colleague Swaroop from the Azure AD team also has a nice //Build video where you can see it in action. From my perspective, App Service Authentication / Authorization (Easy Auth) shares a similar goal of B2C, which is to make it really easy to build identity into your application. We saw a great opportunity to make these features work well together, giving you both an identity management system as well as login and OAuth token management without requiring a single line of code. In this post, I’ll describe how you can use Easy Auth to add Azure AD B2C capabilities to your App Service Web App. Creating an App Service Web App Hopefully you know how to do this by now. Go ahead and create a web app (or an API/mobile/function app – they all work the same way) and make a note of the URL. For example, when drafting this blog post and walking through the steps, I created https://cgillum-b2c-preview.azurewebsites.net. Use your own web app URL in place of mine wherever you see it in these instructions. However, don’t configure Authentication / Authorization yet. We’ll do that in a later step. Creating the Azure AD B2C Tenant and Application We don’t currently support an “Express” setup of B2C like we do for classic Azure AD, so these steps will need to be done manually. You can find detailed instructions for this below: Create an Azure AD B2C tenant Register your application Note that in step 2, you’ll need to use the https address of the web app you previously created as the Reply URL and you must suffix it with “/.auth/login/aad/callback” (again, in my case this is https://cgillum-b2c-preview.azurewebsites.net/.auth/login/aad/callback). Once this is done, you should have an application in the B2C portal which looks something like the following: Make a note of the Application Client ID that you see in the Application blade. You’ll need this in a later step. Adding a Sign-Up/Sign-In Policy For simplicity, we’ll create a single B2C “policy” which allows the user to sign in or sign up if they don’t already have an account. In the portal, this is the Sign-up or sign-in policies selection. Add a new policy (assuming you don’t have one already). The details of the policy don’t matter too much, so I won’t provide any specific guidance here. There are a lot of options, including whether to configure social identity providers. In my case, I set up email login as well as Google and Facebook. To get started quickly, I suggest you use the email sign-up policy. When you’re done, make a note of the Metadata Endpoint for this policy URL which gets generated, like in the screenshot below: Azure AD B2C supports other policy types as well, but the combination sign-up/sign-in is currently the one best suited for Easy Auth login integration. Configure Easy Auth Now let’s go back to the web app we previously created. We’ll configure Easy Auth with Azure AD using the Advanced configuration option. The steps are: In the portal in the context of your web app, click the Settings icon. Set App Service Authentication to On Configure Azure Active Directory Select the Advanced management mode Set the Client ID to be the Application Client ID from before. Set the Issuer URL to be the Metadata Endpoint for this policy URL value that was generated from your sign-in/sign-on B2C policy. Click OK and then the Save icon to save your changes. Your Authentication / Authorization settings blade should look something like the following: Now if you navigate to your site, you should see the B2C login page that you configured previously. Depending on how it was configured, you can sign up using social identity credentials or you can sign up using username (or email) and password. You will also be prompted for additional registration information, such as your name, etc (again, all dictated by the policies you configured). Here is an example of what your initial sign-in page might look like. Notice the link on the bottom of the image which allows users to register: Below is an example of what your “sign-up” registration page will look like. If you selected the email option, Azure AD B2C will even implement the email verification workflow for you. That’s it! You’ve now created a skeleton B2C web application that allows users to sign-up and sign-in without writing any code or deploying any databases! I’ve used all the defaults in terms of styling, but Azure AD B2C does allow you to customize the look and feel of these pages to match your own application branding, if you choose. See the B2C UI customization documentation for more information. Once signed in, you can write code which inspects the inbound HTTP headers and/or the /.auth/me endpoint (both described in my earlier Token Store post) to get more information about the user. If you’re running an ASP.NET application, you can also enumerate the claims on the current ClaimsPrincipal. Specifically, you should be able to see all the claims that you configured in your B2C policy. This is great because you don’t need to provision your own database which contains this information – it’s built into the B2C directory and can be accessed using the features of Easy Auth. Azure AD B2C Social Providers vs. Easy Auth Social Providers One thing you may have noticed is that there are now two ways to incorporate social logins into your web app: using B2C policies or configuring them directly in the Authentication / Authorization settings. Ideally, there would be just one which is common between the two technologies. Unfortunately we’re not there yet. Until then, here are some important differences between social providers in Azure AD B2C and Easy Auth: Different identity providers: B2C and Easy Auth support different providers. At the time of writing, B2C supports MSA, Facebook, Google, LinkedIn, and Amazon identities. Easy Auth, however, supports MSA, Facebook, Google, and Twitter. Client-Directed Login: Both B2C and Easy Auth support server-directed social logins where the login flow is controlled by the browser. However, only Easy Auth supports client-directed logins where the login flow is controlled by the client operating system (typically a mobile OS or a JavaScript client). User Claims: B2C provides a somewhat normalized set of user claims for each login. These claims are similar to what you’d see in an ordinary AAD login. The claims are also configurable. With Easy Auth, however, the claims are static and in many cases are different for each identity provider. OAuth Tokens: With Easy Auth, the application code has direct access to the provider-specific OAuth tokens. This is useful if you want to make graph API calls on behalf of the logged-in user (for example, calling the Facebook Graph to post a photo to the user’s timeline). B2C, however, does not expose the provider OAuth tokens to your application code. If social identity integration is important to your app, then consider these differences very carefully when deciding between the two options. Note that these limitations will certainly change as both Easy Auth and Azure AD B2C evolve over time, hopefully in a way that better aligns them together (this is certainly our goal, internally). Taking it to the Next Level This post demonstrated using a single, global B2C policy within a web app in a way that doesn’t require any code or database setup. If you are a mobile, API, or SPA app developer, I have written a followup post which goes into more details about how to use code to dynamically select B2C policies, how to set up token refresh, and even included a sample SPA app which demonstrates these capabilities. Check it out in Part 2 of the App Service + Azure AD B2C series. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2016/06/22/Cross-Post-App-Service-Auth-and-Azure-AD-B2C.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Azure App Service and ASP.NET Core",
+ "excerpt":"The release of ASP.NET Core 1.0 was announced today! ASP.NET Core 1.0 supports modern web development with its lightweight and modular design. ASP.NET Core is also cross-platform ready and open source. You can read all the details for the release in this announcement. Visual Studio 2015 Update 3 was also announced today with support to build .NET Core apps in Visual Studio. Azure App Service is ready to welcome your ASP.NET Core 1.0 apps. Please see the ASP.NET Core 1.0 announcement for pointers on getting started. Great resources are also available on the ASP.NET Core documentation page. To get started bring your own ASP.NET Core repo or select a sample from Visual Studio. To get started in Visual Studio 2015 navigate to New -> Project -> Web and select an ASP.NET Core sample. Request a Git repo on sample creation Create a web app in Azure App Service and configure Local Git as the deployment source as described in documentation here. Copy the Git URL from the Settings -> Properties blade of your app in the Azure Portal. From your ASP.NET Core app Git repo push the content to Azure App Service using the Git URL copied. The Kudu deployment engine running in Azure App Service is able to detect ASP.NET Core apps and generate a custom deployment script for these apps. If you would like to explore and customize the deployment script generated for Azure App Service deployment you can easily access this script. Navigate to the Kudu SCM management app running alongside the web app from the Tools -> Kudu blade of your app in the Azure Portal. The first step in the deployment script is a NuGet restore with the home drive of the app as the restore location. Restore will be revisited for subsequent deployment only if new dependencies are detected. The next step in the deployment script detects the type of project. If the project originated from Visual Studio and a .sln file is available the deployment engine will run msbuild and then use the new dotnet.exe utility to publish with a no build flag. Otherwise use the new dotnet.exe utility to build and publish. All build actions are completed on the target Azure App Service hosting environment. An alternate Visual Studio deployment option bypassing source control is using the Publish action which will leverage WebDeploy to deploy to Azure App Service instead of leveraging the Kudu deployment engine. With this option build actions would be completed in the source development environment as opposed to build actions being completed in the target Azure App Service hosting environment. If you don’t have an Azure account you can still try ASP.NET Core 1.0 on Azure App Service free of charge and commitment with our Azure App Service free trial. Looking forward to feedback and questions on the Azure App Service forum. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2016/06/27/Azure-App-Service-and-ASP.NET-Core.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Offline Sync with Azure Mobile Apps and Apache Cordova",
+ "excerpt":"In the past, I’ve introduced you to a TodoList application built in Apache Cordova so that it is available for iOS, Android or any other platform that Apache Cordova supports. You can find the QuickStart for Apache Cordova from within the Azure Portal, and read about it within our documentation. Recently, we released a new beta for the Azure Mobile Apps Cordova SDK that supports offline sync, which is a feature we didn’t have. Underneath, the Cordova offline sync functionality uses SQLite - this means it isn’t an option at this point for HTML/JS applications. We’ll have to work out how to do this with IndexDB or something similar, but for now that isn’t an option without a lot of custom work. Let’s take a look at the differences. Step 1: New variables Just like other clients, I need a local store reference and a sync context that is used to keep track of the operational aspects for synchronization: var client, // Connection to the Azure Mobile App backend store, // Sqlite store to use for offline data sync syncContext, // Offline data sync context todoItemTable; // Reference to a table endpoint on backend Step 2: Initialization All the initialization is done in the onDeviceReady() method. I have to set up a model so that the SQLite database is set up to match what is on the server: function onDeviceReady() { // Create the connection to the backend client = new WindowsAzure.MobileServiceClient('https://yoursite.azurewebsites.net'); // Set up the SQLite database store = new WindowsAzure.MobileServiceSqliteStore(); // Define the table schema store.defineTable({ name: 'todoitem', columnDefinitions: { // sync interface id: 'string', deleted: 'boolean', version: 'string', // Now for the model text: 'string', complete: 'boolean' } }).then(function () { // Initialize the sync context syncContext = client.getSyncContext(); syncContext.pushHandler = { onConflict: function (serverRecord, clientRecord, pushError) { window.alert('TODO: onConflict'); }, onError: function(pushError) { window.alert('TODO: onError'); } }; return syncContext.initialize(store); }).then(function () { // I can now get a reference to the table todoItemTable = client.getSyncTable('todoitem'); refreshData(); $('#add-item').submit(addItemHandler); $('#refresh').on('click', refreshData); }); } There are three distinct areas here, separated by promises. The first promise defines the tables. If you are using multiple tables, you must ensure that all promises are complete before progressing to the next section. You can do this with Promise.all() as an example. The second section initializes the sync context. You need to define two sections for the push handler - the conflict handler and the error handler. I’ll go into the details of a conflict handler at a later date, but this is definitely something you will want to spend some time thinking about. Do you want the last one in to be the winner, or the current client edition to be the winner, or do you want to prompt the user on conflicts? It’s all possible. Once I have created a sync context, I can get a reference to the local SQLite database table, which is used instead of the getTable() call that it replaces. The rest of the code is identical - I refresh the data and add the event handlers. Step 3: Adjusting the Refresh In the past, refresh was just a query to the backend. Now I need to do something a bit different. When refresh is clicked, I want to do the push/pull cycle for synchronizing the data. function refreshData() { updateSummaryMessage('Loading data from Azure'); syncContext.push().then(function () { return syncContext.pull(new WindowsAzure.Query('todoitem')); }).then(function () { todoItemtable .where({ complete: false }) .read() .then(createTodoItemList, handleError); }); } Just like the initialization, the SDK uses promises to proceed asynchronously. First push (which resolves as a promise), then pull (which also resolves as a promise) and finally you do EXACTLY THE SAME THING AS BEFORE - you query the table, read the results and then build the todo list. Seriously - this bit really didn’t change. That means you can add offline to your app without changing your existing code - just add the initialization and something to trigger the push/pull. Wrap Up This is still a beta, which means a work-in-progress. Feel free to try it out and give us feedback. You can file issues and ideas at our GitHub repository. Cross-posted to my personal blog ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2016/06/29/Offline-Sync-with-Azure-Mobile-Apps-and-Apache-Cordova.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Cross-Post Creating a Corporate Wiki in Azure",
+ "excerpt":" Chris Gillum (MSFT) 7/5/2016 9:42:35 AM Note: This post was cross-posted from CGillum Dev Blog. Using Azure App Service and Azure Active Directory (AAD), it's possible to create a MediaWiki-based web app for use within your organization with minimal setup and for little or no cost. If you're not familiar with MediaWiki, it's the same open source platform which powers Wikipedia. A few folks within Microsoft surprised me when they created internal wikis using my Easy Auth feature (Authentication / Authorization) so I thought I'd try it out for myself and do a quick write-up on it. Note that I'm assuming you're already familiar with Azure Active Directory and that you have an Azure Subscription that is associated with your organization. If not, you can find more information here: https://azure.microsoft.com/en-us/documentation/articles/sign-up-organization/. Creating a Web App The first step is to create a new web app. If you already know how to do this, you can skip this section. The easiest way is to simply navigate to https://portal.azure.com, log in with your Azure Subscription (the one for your organization), and go to New --> Web and Mobile --> Web App. This can also be done using the Azure PowerShell or Cross-Platform CLI Tools, though I won't cover those details here. In this example, let's suppose you named the web app easyauth-wiki (all my examples and screenshots will use this name, but you can replace it with your own app name). IMPORTANT: If you want to create custom hostnames for your web app, you should set that up now. Enabling AAD Authentication As I hinted to before, this can be done in the portal via Easy Auth, Azure App Service's integrated authentication feature. For simplicity, we'll use the Express configuration, which automatically creates an AAD application and configures it for your site. In https://portal.azure.com, select the web app you previously created. Select Settings and navigate down to Authentication / Authorization. Set App Service Authentication to On. Under Authentication Providers, select Azure Active Directory For Management mode, select Express and then click OK. Back in the Authentication / Authorization blade, click Save. At this point, your new web app is now protected using Azure Active Directory authentication and only users in your organization will be able to access the site. Installing MediaWiki It's possible to create a MediaWiki app using the Marketplace gallery in the Azure management portal, but for this write-up I'm going to configure it from scratch. This also allows me to use a local SQLite database (instead of paying for a ClearDB MySQL database), which is convenient for testing and is free. If you're expecting your wiki to be used by a large number of users, then you should definitely consider using MySQL instead of SQLite, though I won't cover the MySQL setup here. Download MediaWiki There are multiple ways to get MediaWiki installed on your web app. I'm going to show you the quick-and-dirty way which doesn't involve any 3rd party tools or source control. Start by navigating to the debug console on the SCM endpoint for the site you just created: https://{appname}.scm.azurewebsites.net/DebugConsole. You can log in using your Azure Subscription credentials if you're not already logged in. Then do the following: cd D:\\home\\site\\wwwroot del hostingstart.html curl https://releases.wikimedia.org/mediawiki/1.26/mediawiki-1.26.3.tar.gz > mediawiki.tar.gz tar -xzvf mediawiki.tar.gz The last step might take a while due to the large number of files to extract. This will get all the MediaWiki bits onto your web app. I chose MediaWiki 1.26.3 since that was the latest when I started writing this post, but a newer version is probably available by the time you read this (in fact, 1.27.0 was released shortly after I finished putting together my sample). You can find available versions of MediaWiki on the MediaWiki download page. Be sure to adjust my instructions accordingly depending on which version you decide to use. Configure MediaWiki Now that MediaWiki is installed, let's configure it with a simple SQLite database backend. Navigate to https://{appname}.azurewebsites.net/mediawiki-1.26.3/mw-config/index.php Click through the first two pages. In the Connect to database page, select Database type: SQLite and click Continue. Configure your wiki with a name and an administrator account and click Continue. For User rights profile, select Private wiki. Feel free to mess with additional settings on this page as necessary. Under Advanced configuration, you may want to enable PHP object caching for improved performance (internally we use WinCache). When all done, click Continue and then Continue two more times to complete the installation. At this point, you should see a Complete! screen and a LocalSettings.php file should have been downloaded by your browser. You'll need to upload this file to your MediaWiki installation directory (D:\\home\\site\\wwwroot\\mediawiki-1.26.3) to complete the installation. The easiest way is to simply drag/drop it from your file system to the browser window which shows the Debug Console in the D:\\home\\site\\wwwroot\\mediawiki-1.26.3 directory. Configuring Integrated Authentication The final required step is to connect the user accounts in your Azure Active Directory to the user accounts in your wiki. This can be done using the Auth_remoteuser extension, as I'll describe here. The great thing about this extension is that it can also be used for on-premises Active Directory, making it very easy to do on-premises to Azure migrations. Once again, let's take the simple route of installing it directly onto the web app using the Kudu Debug console (otherwise you can follow the instructions on the extension page). Use cURL to download the extension, e.g. curl https://extdist.wmflabs.org/dist/extensions/Auth_remoteuser-REL1_26-6103d19.tar.gz > Auth_remoteuser-REL1_26-6103d19.tar.gz (the actual URL will be different for you depending on which version is the latest by the time you read this). Extract the downloaded extension into the MediaWiki extensions directory - e.g. tar -xzvf Auth_remoteuser-REL1_26-6103d19.tar.gz -C D:\\home\\site\\wwwroot\\mediawiki-1.26.3\\extensions (again, your exact path may differ). Open your LocalSettings.php for editing (e.g. D:\\home\\site\\wwwroot\\mediawiki-1.26.3\\LocalSettings.php) and make the following changes: [php] require_once \"$IP/extensions/Auth_remoteuser/Auth_remoteuser.php\"; $wgAuth = new Auth_remoteuser(); [/php] At this point your identity setup is now complete! MediaWiki automatically recognizes your login. No registration required. You can test it by browsing to the root of your MediaWiki installation - e.g. https://{appname}.azurewebsites.net/mediawiki-1.26.3. The last step is to add a URL rewrite rule to fix your URLs so that you don't need to include the MediaWiki installation directory in your URL. Configuring URL Rewrite Rules (Optional) The final step involves configuring IIS rewrite rules on your app to remove the installation directory as well as to \"prettify\" your URLs. Without doing this, your URLs are quite ugly and hard to discover. There are many ways to configure this so consider the below just one of many examples. In the Kudu console, navigate to D:\\home\\site\\wwwroot. Create a web.config file by entering the following command: touch web.config Open the file for editing and add the following content (replacing the MediaWiki version numbers as necessary): [xml] <?xml version=\"1.0\" encoding=\"utf-8\"?> <configuration> <system.webServer> <rewrite> <rules> <rule name=\"wikiRule1\" stopProcessing=\"true\"> <match url=\"^wiki/(.*)$\" /> <action type=\"Rewrite\" url=\"/mediawiki-1.26.3/index.php?title={UrlEncode:{R:1}}\" /> </rule> <rule name=\"wikiRule2\" stopProcessing=\"true\"> <match url=\"^wiki/$\" /> <action type=\"Rewrite\" url=\"/mediawiki-1.26.3/index.php\" /> </rule> <rule name=\"wikiRule4\" stopProcessing=\"true\"> <match url=\"^/*$\" /> <action type=\"Rewrite\" url=\"/mediawiki-1.26.3/index.php\" /> </rule> </rules> </rewrite> </system.webServer> </configuration> [/xml] Open the LocalSettings.php file and ensure the following variables are set as shown here (again, you may need to fix up the MediaWiki version number): [php] $wgScriptPath = \"/mediawiki-1.26.3\"; $wgArticlePath = \"/wiki/$1\"; $wgUsePathInfo = true; [/php] Now, if you navigate to your site root, you'll get redirected to https://{appname}.azurewebsites.net/wiki and you will see your wiki content. If you click on a page, you'll get a friendly /wiki/PageTitle URL. This is a big improvement from before! Linking to Anchors (Optional) It's common for people to create links to certain sections of their wiki pages which contain URL fragments. For example, you might have a URL which looks like /wiki/Main_Page#SectionZ. This ensures that when you share the link with someone and they click it, the browser will automatically scroll to wherever \"SectionZ\" is located on the page. More information on anchors in MediaWiki can be found here. There is one problem that occurs when you introduce login to your web app, however. If you're familiar with URL fragments (the #SectionZ part of the URL) then you'll know that they are never sent to the server. By default, the Easy Auth module handles the login entirely on the server, so if one of your colleagues clicks on a link to the wiki with a URL fragment in it and they are not yet logged in, the URL fragment will be lost by the time they finish logging in and get redirected back to the page they tried to visit. This is a pain because then they have to manually scroll to find the location that they were supposed to be directly linked to. Note that this problem is not unique to MediaWiki or Easy Auth. There are many other server-side authentication solutions which suffer from the same issue. One potential workaround is to have people complete the login and then click the link again in order to be navigated to the correct location in the target page. Obviously, this is not a very good solution. Several teams internally at Microsoft have run into this problem and reported it to me, so I thought it would be a good idea to find a way to solve it in a way that didn't require users to know about the problem. To that end, we recently added a new feature in Easy Auth which solves this by using some JavaScript to ensure URL fragments are correctly preserved. Currently it's an opt-in feature which you can enable by setting the WEBSITE_AUTH_PRESERVE_URL_FRAGMENT app setting to true in the Azure management portal. With this setting in place, when users click on your links which contain URL fragments, the login process will ensure that the URL fragment part of your URL does not get lost in the login redirect process. Let us know in the comments if you found this feature helpful for you, we'd love to know about it. If it helps out enough folks, we'll likely turn on this capability by default. Note: This post was cross-posted from CGillum Dev Blog. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2016/07/05/Cross-Post-Creating-a-Corporate-Wiki-in-Azure.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Create digital experiences with Episerver CMS in Azure",
+ "excerpt":" mksunitha 7/7/2016 8:53:12 PM Episerver CMS, a platform to build web content management solutions, is now available in the Azure Marketplace.This gives you the ability to get a 30-day free evaluation of Episerver CMS running on Azure App Service. Please note that you will be charged for the Azure resources consumed by the application in your Azure subscription. This solution uses a BOYL (bring your own license) model, to continue its use after the evaluation period you can purchase a license from Episerver website. You can learn more at the Episerver CMS web site. In this tutorial you'll learn how to create an Episerver CMS application in Azure App Service. 1. Click on this link to open Create workflow to Episerver in the Azure portal. Check out the details on Episerver app in the Azure Marketplace. 2. Enter your Application name and Select your subscription. You can choose to create the application in a new or existing resource group. 3. Click on App Service plan/Location to choose an existing App Service plan or create a new App Service plan as shown in the image below 4. Click on SQL Database to choose and existing or new SQL Azure database. You can create a new database in an existing SQL Azure server if the web app and SQL Azure server are in the same location. 5. Click on Create to start deployment of the Episerver application. You can check the “Pin to dashboard” checkbox to pin the resource group in Azure portal dashboard for easy access. 6. Check for the deployment status, by clicking on notification button as shown below 7. Once the deployment has been completed, you can access the resource group you created. Select your web app and click on Browse to view your web app. 8. The Episerver application installer wizard will walk you through the installation. 9. Once the wizard completes, you can access the CMS in edit mode, by appending /episerver/cms/edit to the site URL. For example, the URL would look like http://episerverapp1.azurewebsites.net/episerver/cms/edit/ 10. Note that Episerver CMS is available for a 30-day trial. You will see a message on the web application that it is currently in trial period. Buy Episerver license to continue using the application past the 30-day evaluation period you can References Getting started with Episerver Learn how to build complex integration Episerver resources on Github ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2016/07/07/Create-digital-experiences-with-Episerver-CMS-in-Azure.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Cross-Post App Service Auth and Azure AD Domain Hints",
+ "excerpt":" Chris Gillum (MSFT) 7/13/2016 6:33:50 AM Note: This post was cross-posted from CGillum Dev Blog. When creating web, mobile, API, or Function apps for use by members of your organization, it's often the case that you're using Azure Active Directory and you want to remove the option to log in with non-organizational credentials. For example, you want to prevent users from accidentally logging in with MSA credentials (hotmail.com, live.com, outlook.com, etc.). This can be done by leveraging what's known as a domain hint when navigating users to the Azure AD login page. Domain hints will do two things for you: 1) remove the home realm discovery page from the login flow and 2) ensure that users can't accidentally auto-log into your app using wrong credential types (for example, MSA credentials). More background information on Azure AD's support for domain hints can be found on the Microsoft Enterprise Mobility blog: https://blogs.technet.microsoft.com/enterprisemobility/2015/02/11/using-azure-ad-to-land-users-on-their-custom-login-page-from-within-your-app/ Vittorio Bertocci also talks about domain hints in his post on Skipping the Home Realm Discovery Page in Azure AD., demonstrating how to use them when using ADAL and the OpenID Connect Middleware to build your web app. In this post, however, I'll describe how enable domain hints when using App Service's integrated Easy Auth feature. Default Login Parameters Most web apps will want to configure domain hints to be used for all logins. Unfortunately you cannot configure default domain hints in this way using the Azure portal today. Instead, you must use the App Service Management API. Until we get around to building a portal experience, I recommend that most people configure default domain hints in Azure Resource Explorer. This can be done using the following steps: Search for your web, mobile or API app using the search bar. Alternatively, you can navigate directly to your app if you click on the Resource Explorer link in the tools section of the portal. Under your site node, navigate to /config/authsettings. Click Edit to enable making changes. Set additionalLoginParams to the following (This is a JSON array value): [\"domain_hint=microsoft.com\"] Click the Read/Write button at the top of the page to enable making changes. Click the PUT button to save your changes. The JSON configuration for your auth settings should look something like the screenshot below. In my case, I specified domain_hint=microsoft.com since the app shown here is intended to be used by Microsoft employees. Once this is done, users will no longer see the home realm discovery page when logging into the app. Instead, users will be immediately directed to the organizational login page, ensuring they cannot intentionally or accidentally log in with the wrong credentials. Using the Login API If you're building an app that invokes the built-in /.auth/login/aad REST API, you can alternatively specify domain_hint={domain} as a query string parameter to get the same effect. For example, if I'm writing a mobile client and using the App Service .NET SDK, I could write the following code to initiate a login using a domain hint for contoso.com. [csharp] var user = App.MobileClient.LoginAsync( MobileServiceAuthenticationProvider.WindowsAzureActiveDirectory, new Dictionary<string, string> { { \"domain_hint\": \"contoso.com\" } } [/csharp] Similarly, I could create a login link in a web page using HTML that includes a domain_hint parameter. [html]<a href=\"/.auth/login/aad?domain_hint=contoso.com\">Login</a>[/html] This allows me to specify login hints without changing the auth settings of the app as I showed in the first part of this post. In theory, this would also allow me to create multiple login links, one for each domain that my Azure AD application supports. Note that if an app is already configured with a default domain hint, the query string parameter will override that default. Conclusion In conclusion, most single-tenant applications will want to use domain hints to optimize the login experience. These hints allows you to skip the home realm discovery page in the Azure AD login sequence and mitigates the common problem where the browser will try to log into the app using MSA credentials via SSO. Depending on the type of application you are building, you can use either the default login parameter method or you can explicitly specify login hints via the built-in /.auth/login/aad endpoint. Note: This post was cross-posted from CGillum Dev Blog. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2016/07/13/Cross-Post-App-Service-Auth-and-Azure-AD-Domain-Hints.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Implementing Client-side Encryption with Azure Mobile Apps",
+ "excerpt":" Adrian Hall (MSFT) 7/15/2016 11:09:26 AM Azure Mobile Apps provides an offline sync feature that makes it easy to build mobile apps that work without a network connection. When apps use this feature, end users can still create and modify data, even when the app is in an offline mode. The changes are saved to a local store and can be synced to your Mobile App backend when the app is back online. See Offline Data Sync in Azure Mobile Apps for more details. Offline sync uses a local store to persist data on the client device, where the specific storage implementation can be customized. The Mobile Apps client SDK provides local stores based on SQLite (Windows, Xamarin, and Android) and Core Data (iOS native). SQLite does not have any built-in encryption support, but there are a number of extensions that provide encryption. One such extension is the SQLite Encryption Extension (SEE). SEE is an add-on to the public domain version of SQLite and does not require a custom local store implementation. Note that SEE is not the only encryption option for Mobile Apps; For instance, you can define a local store that uses SQLCipher for encryption. This sample requires you to purchase a license for SEE. This is not included as part of the Azure Mobile Apps Client SDK. In this article I will walk through a sample to show how to create an encrypted local store using SEE in a Xamarin.Android app - this can be done in three parts: Build the Quickstart for Xamarin.Android and enable offline sync Build sqlite3.dll with SEE for Android Update the Quickstart to use custom version of sqlite3 The Quickstart for Azure Mobile Apps builds a simple task list. You can follow the Getting Started tutorial for Xamarin.Android and then Enable Offline Sync in your quickstart app. Build SQLite with SEE Support for Android The SQLite Encryption Extension is a commercial encryption product and you must buy a license for SEE before continuing. After purchase, you may download the code for building SQLite for Android and build the native SQLite3 library with SEE. By default, the native library is build for the armeabi platform - common for actual Android devices. You will need to build the native app for an x86 platform if you wish to run your modified app on the Visual Studio Emulator for Android. To do this, open a Visual Studio command prompt and do the following: cd SQLite_Android_Bindings\\sqlite3\\src\\main ndk-build.cmd APP_ABI=x86 Adjust the paths above as appropriate for your environment. Once built, you can open your Quickstart project in Visual Studio and copy the generated native library for x86 from SQLite_Android_Bindings\\sqlite3\\src\\main\\libs\\x86 to YourQuickstartProject\\lib\\x86. Finally, update the build action for the copied libsqliteX.so file to be AndroidNativeLibrary: Build and Run the Quickstart Before we can build the Quickstart, we need to configure the build environment to include the modified sqliteX DLL instead of the normal sqlite3.dll system library that is a part of the Android platform. Add an app.config file to your project with the following: <?xml version=\"1.0\" encoding=\"utf-8\"?> <configuration> <dllmap dll=\"sqlite3\" target=\"libsqliteX.so\" /> </configuration> Any P/Invoke operations that would normally load the sqlite3.dll will now be mapped to load the libsqliteX.so file that we provide. The SQLitePCL library that is used by the Azure Mobile Apps Offline Client SDK uses P/Invoke to call the native methods within sqlite3.dll, so this will now automatically reference the sqliteX library. This configuration file needs to be included in the APK package. This only happens when the EmbedAssembliesIntoApk is set to true in your csproj file. This property is set to false by default when using a debug build. When debugging the app, ensure you set the EmbedAssembliesIntoApk to true. Edit the csproj file and add the following to it: <EmbedAssembliesIntoApk>True</EmbedAssembliesIntoApk> It's a good idea to do this edit from a normal text editor and then load it into Visual Studio. For an example, see the sample on GitHub. We can now create a local encrypted SQLite database protected by a password for use with offline sync. Create a MobileServiceSQLiteStore as normal, but specify a file Uri with a query parameter that includes the password. Here is the modified code that initialized the local store: /// <summary> /// Converts a string to a hex key // </summary> private string StringToHex(string hexstring) { var sb = new StringBuilder(); foreach (char t in hexstring) { sb.Append(Convert.ToInt32(t).ToString(\"x\") + \" \"); } return sb.ToString(); } private async Task InitLocalStoreAsync() { // WARNING: Do not hard code passwords in your application! var password = \"Hello\"; if (!Utils.MobileService.SyncContext.IsInitialized) { // Generate the URI to the offline cache file var hexkey = StringToHex(password); var offlineCacheUri = new System.Uri(Path.Combine(ApplicationData.Current.LocalFolder.Path,\"testSee.db\")); string offlineCache = $\"{offlineCacheUri.AbsoluteUri}?hexkey={hexkey}\"; // Set up the encrypted SQLite Store as normal var store = new MobileServiceSQLiteStore(offlineCache); store.DefineTable<TodoItem>(); await Utils.MobileService.SyncContext.InitializeAsync(store); } // Synchronize the offline cache with the server await SyncAsync(); } Once the local database is created with a password, it is encrypted. If you try to use that database without providing a valid password, it would fail (throwing an Exception) with the error message ‘Error: file is encrypted or is not a database’. We've created a sample on GitHub that includes a solution for Xamarion.iOS and Universal Windows (UWP). The same technique will also work with Xamarin.Forms applications. Useful links How to compile and use SEE. Build and use the CLI for SEE for additional options. For example, You can update/remove password for encrypted database using the rekey option. How to Interop with Native Libraries in Xamarin. Tips The Android Debug Log shows detailed logs on location of the assemblies being loaded into the application. You can use this to verify the sqliteX that you built is loaded into the app. For Xamarin.Android, set the build configuration to match the native library architecture. A mismatch in the architecture will cause dll not found errors. Getting in touch As always, you can ask questions of the team via Stack Overflow or the Azure Forums. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2016/07/15/Implementing-Client-side-Encryption-with-Azure-Mobile-Apps.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Azure Mobile Supporting IPv6 and the Apple Submission Process",
+ "excerpt":" Adrian Hall (MSFT) 7/18/2016 9:00:26 AM Apple announced in September 2015 that from the 1st of June, all apps submitted to the iOS App Store for review must support IPv6 only networks. TL;DR – your app submissions will likely work just fine as long as you are not embedding IPv4 addresses or using IPv4 specific communication methods in your apps. For more information, keep reading. Why IPv6 IPv4 address are exhausted, and carriers are deploying IPv6 only which make it critical that our apps continue to work on IPv6 only networks. Fortunately for us, most apps will continue to work on an IPv6 only network without modification. To ensure your apps continue to work on an IPv6 only work, you'll want to make sure you're using a network library (for example NSUrlSession or CFNetwork). You'll also want to avoid the use of IPv4 APIs and hard-coded IP addresses. Essentially if your app is using a higher level API and framework for the network rather than the IP layer, your app should continue to work on top of either IPv4 or IPv6. For more information, check out the Apple Documentation. As part of the carriers upgrade to IPv6, they have deployed both DNS64 and NAT64 on their network which allows IPv6 clients (your app) to communicate with existing IPv4 infrastructure. If we take an App Service running in Azure as an example, it currently supports IPv4, but we still wish to communicate with it on the IPv6 carrier network. When our iOS app attempts to contact the REST endpoint we have set up, it will use a host name rather than a hard-coded IPv4 address. The DNS64 server will synthesize an IPv6 address and pass this back to the client. Any packets get routed to the NAT64 engine, which will then translate IPv6 traffic to IPv4 and vice versa. Through using DNS64 and NAT64, our IPv4 only App Service now appears (to our connecting client) to be an IPv6 service. Testing If you wish to test if your app supports IPv6 only networks without submitting your app for review, you can use a handy addition to MacOS network settings. Apple have provided a DNS64 and NAT64 implementation in MacOS 10.11. This can be enabled by option clicking on the Share pane in System Preferences and then option-clicking the Internet Sharing service. After that, you'll see the Create NAT64 Network option appears. Find out More iOS developers should take the time to watch Apple's video from WWDC in order to learn more about the new app store requirement to support IPv6. Most developers will not experience any issues with the new requirement as long as they've followed best practices; even if their existing infrastructure has no support for IPv6. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2016/07/18/Azure-Mobile-Supporting-IPv6-and-the-Apple-Submission-Process.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Transition from Mobile Services to Mobile Apps Node.js Edition",
+ "excerpt":" Adrian Hall (MSFT) 7/18/2016 1:20:30 PM We recently announced that Azure Mobile Services will be deprecated and all services will be migrated to Azure App Service. At this point, you will become responsible for the code running your app. You may want to upgrade your site to take advantage of the additional facilities that Azure App Service provides you, such as staging slots and picking the Node version that is run when you run your site. The Azure Mobile Apps compatibility package allows you to convert older Azure Mobile Services applications written for the Node platform so that they can utilize the latest Azure Mobile Apps Node SDK. How Does it Work? The package takes the raw source code from a Node-based Azure Mobile Service and generates the equivalent set of table and custom API definitions that will work with the Azure Mobile Apps Server SDK for Node. You will have a new project at the end that you can deploy as a new site to Azure App Service. Both platforms offer a similar set of functionality, but with different APIs. The compatibility package maps the Mobile Services API to the newer Mobile Apps API. The generated app is ready to deploy to an Azure App Service and should work for most applications. It's important to review the code afterwards as some common scenarios (such as authentication) will require specific configuration or code changes in addition to the conversion. Performing a Conversion Because the conversion produces a new site, there is a natural process to the conversion. If you run into problems, please get live help - we listen in on Stack Overflow, the Azure Forums and have a Gitter channel for live assistance during normal (West US) working hours. Note that this process cannot be attempted until AFTER you have migrated the site from Azure Mobile Services to Azure App Service. Obtain your Azure Mobile Services Scripts Open the Debug Console in your browser (it's at http://yourMobileService.scm.azure-mobile.net/DebugConsole). Navigate by clicking on the directory names to site/wwwroot/App_Data/config. Download the scripts directory in ZIP format by clicking on the download icon next to the folder name. Create the Azure Mobile App First, install the compatibility package by executing the following with elevated privileges: npm i -g azure-mobile-apps-compatibility This installs a command line utility with the following usage: scaffold-mobile-app <inputPath> <outputPath> For example, scaffold-mobile-app scripts out This reads the Azure Mobile Service definition from the scripts directory located in the current working directory and creates a directory called out with a scaffolded Mobile App. Once the app has been created, check the target folder to make sure it contains files for the tables and custom APIs you defined in your mobile service. Your app is almost ready to deploy! Deploying and Testing During deployment, you will need to update your database and create a new App Service, linking the updated SQL database to the new App Service. Create Database Compatibility Views Mobile Services created a specific schema to hold the Mobile Services data and had system column names preceded by a double-underscore. Mobile Apps has changed these requirements. We can map one to the other using SQL Views. The scaffolded app includes a SQL script called createViews.sql. This script must be executed against the target database. The connection string for the target database can be obtained from your Mobile Service or migrated Mobile App from the Settings blade under the Connection Strings section. The connection string name is MS_TableConnectionString. This script creates read / write views in the dbo database schema that map older reserved column names to new column names. This script can also be obtained from our GitHub repository. Create the Target Mobile App Create a new App Service Mobile App using the Azure portal and perform the following tasks: Take note of the URL for your Mobile App. You will need it later. Configure a data connection that points to the Mobile Service database. Configure push settings to use the same configuration as the Mobile Service. If you previously used one of the built in authentication providers, there are additional steps that you must take. Read about these changes in the .NET documentation - they are valid to all migrations. Deploy your new Mobile App The simplest way to get your app onto Azure is using FTP. The URL, username and password can be obtained from the portal. Before copying the files, you must run npm install in a console window from the output folder created above. Copy the entire contents of the output folder to the site/wwwroot folder of the FTP host. Alternatively, if you are familiar with git, we recommend you follow publish from source control. You can also use WebDeploy or hook up continuous deployment. After you have deployed your app, open your browser and navigate to the URL of your Mobile App. You should see the home page for your app. Additionally, the Easy Tables and Easy API sections for your app in the portal should now be functional. Update Your Client The client application must be updated to use the latest version of the Azure Mobile Apps SDK. In many cases, this may simply be a matter of updating the Azure Mobile Apps libraries to the latest version. Note that some libraries changed names: The C#/.NET/Xamarin library is now Microsoft.Azure.Mobile.Client The JavaScript library is now azure-mobile-apps-client The Apache Cordova library is now cordova-plugin-ms-azure-mobile-apps However, in some cases, additional code changes may be required. You also need to update the URL that is passed to the constructor of the Mobile App client object to the URL of the mobile app you created above and remove the API Key, which is no longer required. Each client SDK has a new HOWTO document to aid in development: C#/.NET/Xamarin JavaScript Apache Cordova iOS: Swift or Objective-C Android: Java Consult these documents for your client platform if you run into problems with the client SDK. Troubleshooting If you run into a problem, you should debug the issue just like you would any other development issue. Generally, this means you should enable diagnostic logs for your app. Explicitly, you should turn on Application Logs (Filesystem) to see most of the issues with the code. Here are some of the more common errors you may encounter with their solutions. Cannot find module 'xxx' Dependencies on external modules such as async have not been included by default to reduce the size of the application. If you are using any external modules, you will need to install them by opening a browser to https://_yourMobileService_.scm.azurewebsites.net/DebugConsole , navigating to the site/wwwroot folder and executing: npm i <module name> You can also add an options @<version> - this is recommended to install the same package versions that were used in your original Mobile Service. The table 'xxx' does not exist The getTable function is now case-sensitive. Check to ensure the appropriate case is being used. Invalid column name '__createdAt' The double underscore notation for createdAt, updatedAt, version and deleted columns have been removed. You will need to update any explicit column references manually within your code. The SQL script createViews.sql will take care of these columns in your database. Can't set headers after they are sent Calling request.respond or response.send more than once per request will result in this error. Older versions of the web framework used by Mobile Services, express, allowed this behavior, but the current version does not. Use the generated stack trace to identify the offending module and change the code to ensure these functions are only called once. Error in sideband demultiplexer This usually indicates a corrupt git repository. You can fix this by running: git remote set-head origin master This assumes your remote repository uses the default name origin and the branch you are pushing to is called master. Caveats There are a couple of areas that require additional changes. For example, if you are using Mobile Services authentication, you need to update redirect URLs on your identity provider as they have changed. Read this article for more information. Custom authentication (i.e. not using an identity provider such as facebook) should not be affected. Other issues Our github repository will be updated with new troubleshooting steps as common cases are uncovered. It's important to note that this package is experimental. We need your help to make the experience as seamless as possible. Join the conversation on gitter and let us know about your experiences. Post any issues within our GitHub repository, and ask questions on Azure Forums or Stack Overflow. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2016/07/18/Transition-from-Mobile-Services-to-Mobile-Apps-Node.js-Edition.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Upgrading Python on Azure App Service",
+ "excerpt":"App Service is Microsoft Azure’s platform-as-a-service offering for web apps, whether they are sites accessed through a browser, REST APIs used by your own clients, or event-triggered processing. Many of you are already using Python to implement your apps on App Service (and rightly so!). When we first enabled Python on App Service we wanted to make it as easy as possible. So we went and installed the latest available versions on every host, so that you could just assume it was going to be present. Unfortunately, this did not turn out to be a great long-term solution. Happily though, we found a better approach! While it isn’t quite polished yet, we know that people want the solution now. Rather than waiting until we’ve finished all the scripts, documentation, videos etc. that will come in the future, we decided to give out early details in this blog post. This post will start by outlining some of the problems, why we couldn’t do the “obvious” fix, and how to use the new approach. Feedback is welcome as we continue to improve the user experience around it, but hopefully the information here will be sufficient to get everyone moving again. What went wrong? Having Python installed on every App Service machine sounds like a great idea, right? And so we went ahead and installed the most up-to-date Python 2.7.8 and Python 3.4.1… oh yeah, they’re not the latest versions of Python any more. The obvious solution here is to simply upgrade Python so that everyone has the latest improvements, bug and security fixes. But unfortunately, there were changes made between 2.7.8 and 2.7.9 and between 3.4 and 3.5 that meant upgrading would break existing users. Stability of the platform had to outweigh these improvements, so we were stuck. (The SSL improvements in 2.7.9 had workarounds that customers could implement themselves, so weren’t sufficient to justify breaking other customers.) We had also chosen to install the 32-bit versions of Python. This adds an extra restriction on users who may have been deploying pre-built binaries targeting 64-bit versions, or other micro versions of Python. Since users want to be able to choose their version of Python, the fix is to let everyone choose. We also wanted to improve package installation and make it easier to avoid IIS details. Choosing your version of Python Azure App Service has support for site extensions, which allow you to add features to your site. These can be deployed as part of an ARM template, using a REST API, or manually through the portal. The main part of our improved Python support is a set of site extensions containing the Python runtime, broken down by the exact version so that you can choose which one to install. (Obviously we recommend using the latest Python 3 version, but when you need an older version, you really need it so you can choose it.) If your site is already deployed and running, it is easiest to install through the portal. Navigate to your App Service blade, select Tools, Extensions and then Add. From the list of extensions, scroll down until you spot the Python logos, then choose the version you need. (Improvements to this UI are coming in the future; right now you just need to search manually.) However, if you are deploying your site with an Azure Resource Manager (ARM) template, it is much simpler to add the site extension as a resource. It will appear as a nested resource of your site, with a type siteextensions and the name can be found from siteextensions.net. For example, after adding a reference to python352x64, your template may look like this: \"resources\": [ { \"apiVersion\": \"2015-08-01\", \"name\": \"[parameters('siteName')]\", \"type\": \"Microsoft.Web/sites\", ... \"resources\": [ { \"apiVersion\": \"2015-08-01\", \"name\": \"python352x64\", \"type\": \"siteextensions\", \"properties\": { }, \"dependsOn\": [ \"[resourceId('Microsoft.Web/sites', parameters('siteName'))]\" ] }, ... Regardless of how you choose to install the site extension, after installing you will have a version of Python installed at a path like C:\\home\\Python35\\python.exe (see the description of the extension for the exact path). Configuring your site Once Python is installed on your site, you will need to reference it. Previously our tooling has been able to do this automatically, since we knew where Python was, but now the control is in your hands. Luckily, configuring your site is mostly a matter of knowing where to find python.exe. Since App Service apps all run behind IIS, the configuration file is known as web.config (if you’re used to httpd servers, web.config is the equivalent of .htaccess), and there are two request handlers available: FastCGI, and Http Platform. Using the FastCGI handler FastCGI is an interface that works at the request level. IIS will receive incoming connections and forward the request details to a WSGI app running in one or more persistent Python processes. The wfastcgi package is pre-installed and configured, so you can easily enable it. Your web.config configuration should include the following: <?xml version=\"1.0\" encoding=\"utf-8\"?> <configuration> <appSettings> <add key=\"PYTHONPATH\" value=\"D:\\home\\site\\wwwroot\"/> <add key=\"WSGI_HANDLER\" value=\"app.wsgi_app\"/> <add key=\"WSGI_LOG\" value=\"D:\\home\\LogFiles\\wfastcgi.log\"/> </appSettings> <system.webServer> <handlers> <add name=\"PythonHandler\" path=\"*\" verb=\"*\" modules=\"FastCgiModule\" scriptProcessor=\"D:\\home\\Python35\\python.exe|D:\\home\\Python35\\wfastcgi.py\" resourceType=\"Unspecified\" requireAccess=\"Script\"/> </handlers> </system.webServer> </configuration> The value for PYTHONPATH may be freely extended, but must include the root of your website. WSGI_HANDLER should be updated to point to a WSGI app importable from your website. WSGI_LOG is optional but recommended while debugging your site. All app settings are made available to the app as environment variables. The path to python.exe and wfastcgi.py will need to be customized if you are using a different version of Python. See the description of the site extension to find out where it will be installed and update these paths accordingly. Using the Http Platform handler <?xml version=\"1.0\" encoding=\"utf-8\"?> <configuration> <system.webServer> <handlers> <add name=\"PythonHandler\" path=\"*\" verb=\"*\" modules=\"httpPlatformHandler\" resourceType=\"Unspecified\"/> </handlers> <httpPlatform processPath=\"D:\\home\\Python35\\python.exe\" arguments=\"D:\\home\\site\\wwwroot\\runserver.py --port %HTTP_PLATFORM_PORT%\" stdoutLogEnabled=\"true\" stdoutLogFile=\"D:\\home\\LogFiles\\python.log\" startupTimeLimit=\"60\" processesPerApplication=\"16\"> <environmentVariables> <environmentVariable name=\"SERVER_PORT\" value=\"%HTTP_PLATFORM_PORT%\" /> </environmentVariables> </httpPlatform> </system.webServer> </configuration> As for the previous configuration, the path to python.exe may need to be customized depending on the version of Python you are using. See the description of the site extension to find out where it will be installed and update these paths accordingly. Arguments may be freely customized for your app. The HTTP_PLATFORM_PORT environment variable contains the port your local server should listen on for connections from localhost. In this example, I created another environment variable SERVER_PORT that isn’t really required. You can add or remove environment variables as necessary for your app. Installing packages Once you’ve installed Python onto your server, the next thing you’ll need is any packages your app depends on. This is the area we’re currently focusing on, so expect new announcements in the coming weeks as we simplify this process, but here are a few ways you can do it right now. Kudu Console Even after you have installed your packages, you will likely find this is an invaluable debugging tool. Once your website is created, for example at http://trywebsites.azurewebsites.net/, you can get into the Kudu console by adding .scm after your site name: https://trywebsites.scm.azurewebsites.net/. You will need to log in with your Azure account (so that example URL probably isn’t going to work) but can then directly access files and run commands on your site. The Kudu documentation contains the most up-to-date information about the console. Once you are in the console and have added the site extension, you can freely install any packages you like (well, almost - more on this later). The one trick is that you’ll have to specify the full path to Python. We also suggest including a requirements file as part of your site so that it is easy to reproduce the set of packages both locally and on the server. For example: D:\\home>D:\\home\\Python35\\python.exe -m pip install --upgrade -r D:\\home\\site\\wwwroot\\requirements.txt There’s no C compiler on your web server, so if any packages have native extension modules you’ll need to install the wheel. Many popular packages provide their own wheels, so installing them will work just fine, but for those that don’t you will need to use pip wheel [package] on a development machine and then upload the wheel with your site. (The end of our page on managing requirements shows an example.) Kudu REST API If you don’t want to manually log into the Kudu portal to install packages, you can also trigger these commands remotely via the REST API. The command command behaves identically to typing into the console, except you can POST the command to https://yoursite.scm.azurewebsites.net/api/command. See the documentation for other commands and information about authentication. There is a helper class in this sample project that obtains the credentials using the Azure SDK for Python and will let you submit the same command as above via the exec() method. (Remember how I mentioned that we’re working on better ways to do all of these? Yep, there’s a lot of manual work required right now, but soon we’ll have install-on-deploy automation available.) Vendor everything A final option for deploying your packages is to “vendor” them. This essentially means copying the entire library into your own source code and copying it as part of your site. Depending on how many dependencies you have and how frequently you update them, this may be the easiest way to get a working deployment going. The one catch is that you need to ensure that you copy libraries from a version of Python that precisely matches the version you are installing on the server. If you take extensions from Python 3.5 32-bit and try and use them with 64-bit Python, you will see obscure import errors after deployment. However, as the versions of Python we make available on Azure are exactly the same as those released on python.org, you can easily obtain a compatible version for local development. Aside: what about virtual environments? While we recommend working in a virtual environment locally, to ensure you fully understand the dependencies needed by your site, once you have published there should not be multiple projects using the same Python install at all. (If there are, you really want to avoid having conflicting dependencies!) As a result, it’s easier and more efficient to just install into the main Python directory. Summary We hope you appreciate this information at this time. While there is still a lot of ongoing work to improve Python on Azure App Service, we have reached a point where there is enough for people to benefit from being able to use parts of it. In particular, we know that many of you will be unblocked by the new ability to install newer versions of Python onto your app service servers. <If you have any feedback, suggestions, or want to deploy or manage your web site in a way you think we may not have considered, feel free to leave a comment on this post or email python@microsoft.com directly. While we can’t respond to every piece of feedback or need for assistance (we suggest creating support requests for those), we’re happy to hear what you need. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2016/08/04/Upgrading-Python-on-Azure-App-Service.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Introducing a Quicker Mobile App Quickstart",
+ "excerpt":" Adrian Hall (MSFT) 8/11/2016 2:00:06 PM The traditional Azure Mobile Apps process has been somewhat long winded. Aside from creating a Mobile App, you have to create a SQL Azure server and database, link the two up, deploy some code, and then you are ready to actually develop a mobile client. This can take 15 minutes even in the best case scenario. Today, we are introducing a new method of creating a Mobile backend via the Mobile Apps Quickstart. The Mobile Apps Quickstart is a pre-configured mobile backend suitable for development purposes and learning about mobile backends. It provides a base mobile backend using a SQLite database for data storage. This means that you can immediately start using it without hooking up an external database. You can still access features like Easy Tables and Easy APIs, hook up authentication and push notifications - in fact, anything that does not rely on a SQL Azure instance. Setting up a Mobile Apps Quickstart is a breeze. Log into the Azure Portal. Click on the big + NEW in the top left corner, and enter \"Mobile Apps Quickstart\" in the search box: Click on the **Create** button at the bottom of the blade. The App name, Subscription, Resource group and App Service plan/Location fields are identical to those required by the standard Mobile App flow. Just fill in the information. However, ensure you always check the **Pin to dashboard** box. Finally, click on **Create**. The deployment takes approximately 3-4 minutes and is ready for going through one of the client walk-throughs immediately after the deployment is completed. Along with the quicker deployment, you also get access to a new simplified management experience. Clicking on the dashboard app tile (the one that you pinned) brings you to a new blade: You can always get to the underlying Mobile App (click on the middle card). Limitations Because this template provides a SQLite database, it does not scale. Do not run more than one instance of the Mobile App. If you wish to run this Mobile App in a scalable manner, then connect a SQL Azure database instance through the **Data Connections** blade. The Mobile Apps Quickstart is available on the Azure Marketplace right now. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2016/08/11/Introducing-a-Quicker-Mobile-App-Quickstart.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Patching Swagger-UI Vulnerabilities in Azure Mobile Apps",
+ "excerpt":" Adrian Hall (MSFT) 8/11/2016 3:00:58 PM ALERT: Some Mobile Apps (a feature of Azure App Service) deployments may be vulnerable to phishing attacks because of how current and older versions of swagger-ui are installed. Please take steps to determine if your deployments are at risk, and then mitigate, if necessary. Our Microsoft Azure Security team is following reports of multiple high risk vulnerabilities present in current and older versions of swagger-ui. These are third-party vulnerabilities and not related to the Azure platform. However, some Mobile Apps deployments may have swagger-ui installed in a manner that makes those deployments vulnerable to phishing attacks. How the vulnerability is exploited The swagger-ui component allows loading of arbitrary swagger definition files by passing the URL of the swagger definition as a querystring parameter. Malicious swagger definitions can be constructed that execute arbitrary code within the browser. An attacker can then send a URL containing a reference to the malicious swagger definition that is then executed by simply opening the URL in a browser (for example, clicking on the link in an email). How the vulnerability is mitigated The Mobile Apps server SDKs now validate the URL of the swagger definition that is passed as a querystring parameter. Additionally, a Content Security Policy (CSP) header is sent which prevents the browser from communicating with servers that may host malicious swagger definitions. How to determine if your deployment is at risk First determine whether your Mobile Apps deployment is based on Node.js (this includes all Easy Tables users) or .NET. For Node.js, you can determine if your deployment is vulnerable by looking at the code in your app.js file (if you are using Easy Tables, you can do this by using the Edit Script option in the Azure portal; this will open App Service Editor and allow you to browse the files). If you see the line \"swagger: true\" then swagger-ui is enabled and your deployment is potentially vulnerable. For .NET, your deployment is potentially vulnerable if the application you publish includes the Azure Mobile .NET Server Swagger package (the vulnerabilities aren‘t in this package itself but one of its dependencies). Steps to perform mitigation actions For Node.js, updated packages are available. We recommend that Node.js users complete one of the following actions: Edit your application code (for example, app.js) to disable the configuration setting that enables our swagger UI functionality (use swagger: false). Or update to swagger-ui 2.1.5, and then update to the latest version of the Azure Mobile Apps Node.js SDK. Here are a couple of ways to do this: Sign in to the kudu debug console by opening https://.scm.azurewebsites.net/DebugConsole (update to your mobile app name), change directory to D:\\home\\site\\wwwroot, and then run npm update -save azure-mobile-apps swagger-ui. When this completes, go to the Azure portal, open your mobile app, and then select the Restart option. Update package version numbers in package.json (azure-mobile-apps should be version 2.2.3; swagger-ui should be 2.1.5) and deploy using git. We strongly recommend the following steps for .NET customers: Uninstall the Azure Mobile .NET Server Swagger package as a mitigation. Confirm that your application code no longer includes a reference to the Swashbuckle.Core package. Republish your application. For more information on the open source component swagger-ui vulnerabilities, please visit the following webpages on the Node Security Platform website: XSS in Consumes/Produces Parameter XSS in key names XSS via Content-type header As always, if you run into problems, please contact us. We listen on the Azure Forums and Stack Overflow. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2016/08/11/Patching-Swagger-UI-Vulnerabilities-in-Azure-Mobile-Apps.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Cross-Post App Service Auth and Azure AD B2C (Part 2)",
+ "excerpt":" Chris Gillum (MSFT) 8/15/2016 8:44:05 AM Note: This post was cross-posted from CGillum Dev Blog. EDIT 1/23/2017: Updated token refresh section with simplified instructions and added code snippets. This post is a continuation of my previous post on App Service Auth and Azure AD B2C, where I demonstrated how you can create a web app that uses Azure AD B2C without writing any code. If you haven't done so already, be sure to read that post to get proper context for this one. In a recent service update, we've improved our overall support for B2C in Azure App Service. This includes enhancing our existing web app support, but more importantly includes adding full support for leveraging B2C in mobile, API and function apps. More specifically, support has been added for the Easy Auth Token Refresh API. Additionally, the Login API has been updated to support specifying specific B2C policies as arguments. If you're a Mobile app developer, these improvements will make using Azure AD B2C in your mobile app significantly easier. This post will go into more details about these improvements, show a few code snippets, and conclude by demonstrating these B2C capabilities in a simple demo web app. Pick Your Policy Specific B2C policies can be invoked using the built-in Easy Auth login API for AAD. If you're not familiar with the Easy Auth login API, it works by allowing you to initiate a server-directed login by sending a GET request to your web, mobile, API, or function app's built-in {root}/.auth/login/aad endpoint. This endpoint supports the standard sign-in query string parameters for AAD, including the newly added p={policy} query string parameter which allows you to specify a B2C policy by name. For example, one could use the following HTML in a web app to create hyperlinks that invoke specific B2C policy workflows, such as editing the user profile or resetting the password: [html] <a href=\"/.auth/login/aad?p=B2C_1_EditProfile&post_login_redirect_uri=/\">Edit Profile</a> <a href=\"/.auth/login/aad?p=B2C_1_ResetPassword&post_login_redirect_uri=/\">Reset Password</a> [/html] Clicking one of these links will automatically redirect the user to the corresponding B2C policy page and allow the user to edit their user profile or reset their password accordingly. If you're writing a native client which uses one of the App Service Mobile Client SDK flavors, you could write something similar in platform-specific code. The example below shows how a mobile client app written in C# can invoke a B2C sign-in policy that requires MFA: [csharp] App.MobileClient.LoginAsync( MobileServiceAuthenticationProvider.WindowsAzureActiveDirectory, new Dictionary<string, string> { { \"p\", \"B2C_1_SignInWithMFA\" } } [/csharp] In this case, the user will presented with a native web view dialog which allows the end user to sign in using MFA (phone authentication, etc.). The primary thing to keep in mind about this experience is that these B2C policies can be easily invoked with just a few simple lines of client-side code. No platform-specific middleware or server-side code is required. One important note of caution: the claims associated with the signed-in user will be updated every time you invoke a B2C policy. If your app depends on the presence of specific claims, make sure they are explicitly configured in each of your B2C policies. Refreshing Tokens (Optional) Easy Auth also has a built-in API for refreshing both provider-specific OAuth tokens and the app-specific authentication tokens. It works similar to the login API, in that it requires a GET request to the app's built-in {root}/.auth/refresh endpoint. More information on token refresh (and our token management story all-up) can be found in my earlier App Service Token Store blog post. This token refresh support also extends to Azure AD B2C apps and is completely optional. However, leveraging token refresh is very important if you're building a native app to ensure a smooth user experience. In order to set this up, you will need to do the following: Create an app key for your B2C application Creating app keys can be done in the Azure management portal for B2C. [caption id=\"attachment_198\" align=\"aligncenter\" width=\"951\"] Generating an App Key in the B2C Management Portal[/caption] Make a note of the app key that gets auto-generated by the portal. We'll need it to configure Easy Auth in the next step. Update the Easy Auth Settings Easy Auth doesn't require an app key by default and instead relies on the OpenID Connect Implicit Flow to implement secure logins. In order to get refresh tokens, however, we need to switch to the Hybrid Flow (Don't worry if you don't understand what these mean, Easy Auth will take care of the protocol details for you). To make this protocol switch, you need to update the App Service Auth settings for your app with the key from the previous step. This can be done in the Advanced tab in the Azure Active Directory portal. [caption id=\"attachment_2865\" align=\"alignnone\" width=\"1190\"] Setting the B2C app key as the Easy Auth client secret.[/caption] Now that you’ve enabled the hybrid flow, your app needs to start requesting refresh tokens from B2C. This can be done by updating the login parameters in your app code to include the offline_access scope. Updated HTML Example [html] <a href=\"/.auth/login/aad?p=B2C_1_EditProfile&post_login_redirect_uri=/&scope=openid+offline_access\">Edit Profile</a> <a href=\"/.auth/login/aad?p=B2C_1_ResetPassword&post_login_redirect_uri=/&scope=openid+offline_access\">Reset Password</a> [/html] Updated Mobile App SDK C# Example [csharp] App.MobileClient.LoginAsync( MobileServiceAuthenticationProvider.WindowsAzureActiveDirectory, new Dictionary<string, string> { { \"p\", \"B2C_1_SignInWithMFA\" }, { \"scope\", \"openid+offline_access\" } } [/csharp] Once this is done, all future logins should result in refresh tokens in the app's built-in token store. You can then write client code which invokes the {root}/.auth/refresh API (or use the corresponding Mobile Client SDK method) to periodically refresh these tokens, which allows your app to function for longer periods of time without requiring a re-auth. Demo App To demonstrate all of this, I've created a single-page application (aka a SPA app) written using HTML, jQuery, and Bootstrap. It's a trivial app written by someone who is clearly not a UI designer (me) and demonstrates the various patterns described in this blog post. You can browse to it here and play around with it (I promise not to give out your information if you decide to provide it), or simply copy the source code and host it yourself in your own App Service web app. Note that I theoretically could have also built this using the iOS, Android, UWP/Xamarin, or one of the other mobile SDKs that are provided, but it was simpler for me to build a plain-old HTML web app. :) The important thing to keep in mind is that there is absolutely no auth code in this sample (in fact, no backend code at all). All of this is implemented on the client and in the App Service platform with the help of Azure AD B2C. No SDKs required. When you first visit the demo page, you will be given two login options. One is a standard email-based login and the other is an MFA login which requires you to register a phone number for phone authentication. [caption id=\"attachment_183\" align=\"aligncenter\" width=\"510\"] Demo app starting page when unauthenticated[/caption] The phone authentication provided by B2C allows you to do phone calls or SMS in my case. You can enter the provided code to complete the authentication. [caption id=\"attachment_182\" align=\"aligncenter\" width=\"419\"] Phone authentication when using Azure AD B2C[/caption] Once signed-in, you will see a few B2C policy actions that you can invoke as well as a set of user claims displayed on the page. There's also a sign-out button which uses Easy Auth's built-in Logout API to clear the session. [caption id=\"attachment_185\" align=\"aligncenter\" width=\"992\"] This B2C demo app supports updating the user profile and resetting the password used for logging in.[/caption] [caption id=\"attachment_189\" align=\"aligncenter\" width=\"1003\"] This B2C policy is configured to return the object ID, postal code, name and email address.[/caption] Note that one of the claims, https://schemas.microsoft.com/claims/authnclassreference, contains the name of the B2C policy that the user logged-in with. Your application code can take advantage of this if, for example, you want to grant special permissions to users who log in using a higher-privilege B2C policy. Again, it's a very simple app to quickly demonstrate some of the powerful capabilities of the App Service \"Easy Auth\" platform when combined with Azure AD B2C. My hope is that this is enough to give you some ideas about how you can leverage the Azure AD B2C platform in your own App Service apps. Following Up Have a technical questions about Azure App Service and/or Azure AD B2C? Head over to StackOverflow.com and tag your questions with azure-app-service and/or azure-ad-b2c accordingly. We monitor posts with these tags and are happy to help. Note: This post was cross-posted from CGillum Dev Blog. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2016/08/15/Cross-Post-App-Service-Auth-and-Azure-AD-B2C-(Part-2).html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Announcing MySQL in-app for Web Apps (Windows)",
+ "excerpt":" mksunitha 8/18/2016 4:26:55 PM MySQL in-app feature enables running MySql natively on Azure App Service platform.You don’t need to provision a database explicitly as during the creation of the web app when using this feature, we take care of enabling it if you select “MySQL in-app ” during creation or if the feature is turned ON for existing web app. To understand what MySQL in-app means , I have highlighted core functionality supported with the preview release of the feature: Support PHP , MYSQL applications like WordPress, Joomla , Drupal etc . MySQL server running on the same instance side by side with your web server hosting the site. This will boost performance of your application Storage is shared between both MySQL and your web app files. Note with Free and Shared plans you may hit our quota limits when using the site based on the actions you perform . Check out quota limitations for Free and Shared plans. You can turn on Slow query logging and general logging for MySQL . Note that this can impact the site performance and should NOT always be turned ON . The logging feature will help investigation any application issues . Note : This MySQL in-app is specific to Windows version of Azure app service. If you are looking for local mysql on Linux MySQL app service , click here. Create new Web App with MySQL in-app Login to Azure portal and launch Web App + MySQL template by clicking here .Enter the Site name and select MySQL in-app as the database provider. Click on Create to deploy a web app using MySQL in-app. You may also create a WordPress application with MySQL in-app from Azure marketplace. Test drive our demo site here using MySQL in-app.You can login with username : demo and password: demopassword . Limitations For preview release the feature has some limitations that to keep in mind. Auto scale feature is not supported since MySQL currently runs on on a single instance . Enabling Local cache is not supported. MySQL database cannot be accessed remotely. You can only access your database content using PHPMyadmin or using MySQL utilities in KUDU debug console. This is described in detail below. WordPress and Web App + MySQL templates currently support MySQL in-app in the create experience.We are working on bringing this feature in for other MySQL based applications in Web category for Azure marketplace. Manage MySQL in-app Go to your web app and select MySQL in-app in the Menu blade on the right. You can use the setting here to manage your MySQL in-app feature , turn on logging , access PHPmyadmin etc. Access database content The database is protected by our sandbox environment and hence cannot be accessed remotely through MySQL workbench or MySQL command line tools (running on remote machine) . There are two ways you can manage your database content : Using PHPMyAdmin: With MySQL in-app , the MySQL process ( mysqld.exe) must be ready for connections before using PHPmyadmin tool to access the database. This means your web app has to open the mysql connection. You can use the sample code mentioned in section Get database connection string to open mysql connection. Go to your web app and select MySQL in-app in the Menu blade on the right . Click on the Browse button to open PHPmyadmin. The database enabled with your web app is \"localdb\". You are now ready to import your database schema or create a new one for your web app. Using Kudu Debug console: Access your Kudu debug console from the portal , go to your web app and Select Advanced Tools or use use a URL in this format https://sitename.scm.azurewebsites.net/debugconsole (replace sitename with your web app name). Run the following command to run your query (remember to update the port number to your web app’s MySQL port since this feature does not use 3306 port) D:\\Program Files (x86)\\mysql\\5.7.9.0\\bin\\mysql.exe -e \"ENTER SQL STATEMENTS\" --user=azure --password=password --port=49175 --bind-address=127.0.0.1 Example: D:\\Program Files (x86)\\mysql\\5.7.9.0\\bin\\mysql.exe -e \"USE localdb;Select * from tasks;\" --user=azure --password=password --port=49175 --bind-address=127.0.0.1 mysql: [Warning] Using a password on the command line interface can be insecure. mysql: Unknown OS character set 'cp0'. mysql: Switching to the default character set 'latin1'. task_id subject start_date end_date description 1 task1 2016-02-18 2016-02-19 sample task The mysql warning statements can be ignored in the output. You can use mysqladmin.exe and mysqld.exe as well , in the similar format as above .Please review the password and database information from D:\\home\\data\\mysql\\MYSQLCONNSTR_localdb.ini before entering the connection information in the commands below. Here is an example to flush logs mysqladmin.exe flush-logs --user=azure --password=password --port=49175 --bind-address=127.0.0.1 Logging Turn on slow query logs or general logs for MySQL . Once turned on , you can find these logs in D:\\home\\logfiles\\mysql folder. Note if these settings are always on , then this can impact your web app performance How to deploy your web app to using MySQL in-app Get the database connection string Before you deploy your web app code , the key thing to note when using this feature is to use ENVIRONMENT VARIABLES since the database connection information is not accessible directly. You can get the database connection information using MYSQLCONNSTR_localdb environment variable . You can also get the connection string from D:\\home\\data\\mysql\\MYSQLCONNSTR_localdb.ini .Here is a sample code snippet that you can use in your application to get the database host, port, database name , database user, database password. $connectstr_dbhost = ''; $connectstr_dbname = ''; $connectstr_dbusername = ''; $connectstr_dbpassword = ''; foreach ($_SERVER as $key => $value) { if (strpos($key, \"MYSQLCONNSTR_localdb\") !== 0) { continue; } $connectstr_dbhost = preg_replace(\"/^.*Data Source=(.+?);.*$/\", \"\\\\1\", $value); $connectstr_dbname = preg_replace(\"/^.*Database=(.+?);.*$/\", \"\\\\1\", $value); $connectstr_dbusername = preg_replace(\"/^.*User Id=(.+?);.*$/\", \"\\\\1\", $value); $connectstr_dbpassword = preg_replace(\"/^.*Password=(.+?)$/\", \"\\\\1\", $value); } $link = mysqli_connect($connectstr_dbhost, $connectstr_dbusername, $connectstr_dbpassword,$connectstr_dbname); if (!$link) { echo \"Error: Unable to connect to MySQL.\" . PHP_EOL; echo \"Debugging errno: \" . mysqli_connect_errno() . PHP_EOL; echo \"Debugging error: \" . mysqli_connect_error() . PHP_EOL; exit; } echo \"Success: A proper connection to MySQL was made! The my_db database is great.\" . PHP_EOL; echo \"Host information: \" . mysqli_get_host_info($link) . PHP_EOL; mysqli_close($link); As an example , if you are running a WordPress site you need to update wp-config.php such that it reads the connection string from the environment variable . /*Add at the begining of the file*/ $connectstr_dbhost = ''; $connectstr_dbname = ''; $connectstr_dbusername = ''; $connectstr_dbpassword = ''; foreach ($_SERVER as $key => $value) { if (strpos($key, \"MYSQLCONNSTR_localdb\") !== 0) { continue; } $connectstr_dbhost = preg_replace(\"/^.*Data Source=(.+?);.*$/\", \"\\\\1\", $value); $connectstr_dbname = preg_replace(\"/^.*Database=(.+?);.*$/\", \"\\\\1\", $value); $connectstr_dbusername = preg_replace(\"/^.*User Id=(.+?);.*$/\", \"\\\\1\", $value); $connectstr_dbpassword = preg_replace(\"/^.*Password=(.+?)$/\", \"\\\\1\", $value); } // ** MySQL settings - You can get this info from your web host ** // /** The name of the database for WordPress */ define('DB_NAME', $connectstr_dbname); /** MySQL database username */ define('DB_USER', $connectstr_dbusername); /** MySQL database password */ define('DB_PASSWORD', $connectstr_dbpassword); /** MySQL hostname : this contains the port number in this format host:port . Port is not 3306 when using this feature*/ define('DB_HOST', $connectstr_dbhost); As a BEST PRACTICE when using MySQL in-app, we recommend to ALWAYS use Environment variables for the database information to prevent database connection issues with your web app. If your application requires a separate variable for port , you can use WEBSITE_MYSQL_PORT environment variable. The port number selected can vary if the instance is recycled and hence ALWAYS use environment variables. Deploy you code Deploy your web app code using GIT or FTP or any one of the supported deployment processes with Azure Web Apps . Refer Deploy to Azure app service web apps for details . Deploy your database You cannot directly deploy you database . Hence , export your local database into a SQL script . Access your web app MySQL in-app database using PHPmyAdmin ( https://sitename.scm.azurewebsites.net/phpmyadmin) and click on the IMPORT tab to import your script into the localdbdatabase . For example: USE localdb; CREATE TABLE IF NOT EXISTS tasks ( task_id INT(11) NOT NULL AUTO_INCREMENT, subject VARCHAR(45) DEFAULT NULL, start_date DATE DEFAULT NULL, end_date DATE DEFAULT NULL, description VARCHAR(200) DEFAULT NULL, PRIMARY KEY (task_id) ) ENGINE=InnoDB Remember to include USE localdb; statement in your script so that the your schema and data are imported into the correct database. How to turn on MySQL for existing Web Apps Go to your web app and select MySQL in-app in the Menu blade on the right . Turn ON MySQL in-app feature. Browse your web app and Check the process explorer to verify if mysqld.exe is running. If the process is running, then MySQL server is ready to use. Remember to open the MySQL connection to your MySQL in-app database , localdb in your web app. Migration to production database You can easily migrate this database when ready for production to Azure database for MySQL(Preview) ClearDB database MySQL on virtual machine on Linux or Windows OS Best practices When using Web app with MySQL in-app provider with Basic, Standard or Premium app service plans, turn on ALWAYS ON setting as described here. By default, web apps are unloaded if they are idle for some period of time which means both the web app and MySQL in-app server will be take a longer time to load from an idle state. PHPMyadmin may not be accessible during the idle state. With ALWAYS ON feature, you can keep your web app from getting into an idle state. When using this feature with Free and Shared Web App pricing plans, add the app setting WEBSITE_FASTCGI_MAXINSTANCES and set its value to 3 if your web app is likely to get traffic from a few users say between 10-20. This setting will prevent creating too many PHP FastCGI instances which will consume all the memory causing your web app to hit the quota too early. Checkout benchmarking blog post for more information. References Exporting your MySQL database to MySQL in-app database Benchmarking MySQL in-app performance ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2016/08/18/Announcing-MySQL-in-app-for-Web-Apps-(Windows).html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Benchmarking MySQL in-app performance",
+ "excerpt":" mksunitha 8/18/2016 4:26:30 PM Azure app service just launched a new feature, MySQL in-app to support MySQL natively. MySQL in-app is recommended for development and testing (DEV/TEST) scenarios to quickly spin up PHP+ MYSQL applications on Azure to start developing and understanding the Azure app service platform. You can easily migrate this database when ready for production to ClearDB database ClearDB Clusters MySQL on virtual machine on Linux or Windows OS We conducted a benchmarking experiment with MySQL in-app to understand its performance compared to other MySQL solutions offered on Azure. We conducted two tests as described below: We conducted a benchmarking experiment with MySQL in-app to understand its performance compared to other MySQL solutions offered on Azure. We conducted two tests as described below : Test Configuration We used simple testing methodology for both scenarios to understand the performance of the feature. The baseline configuration for both tests mentioned below are: Two test clients (one is the same region as web app and one in a different region) added application insights to web app to gather telemetry data using MySQL in-app database constant user load on the web app Test Scenario with Vanilla WordPress : We deployed a vanilla word press web app on various pricing plans for Azure App service. No caching layer was used with the web app configuration. Note: Keep in mind that Free and Shared hosting have quota limitations that impacted the result of the tests. During this test , we set a limit on how many PHP FastCGI processes created on Free and Shared pricing plan. To learn more about limiting PHP FastCGI process , check out this article.In Azure app service , this can be done by using enabling the app setting WEBSITE_FASTCGI_MAXINSTANCES . For this test the value was set to 3. Try out the demo site Web App SKu User Load Server Response Time CPU Time Requests HTTP Server Errors Average Memory Working Set Free 10 248.14 ms 127.69 440 0 524.12 MB Free 25 245.56 ms 278.01 903 0 597.17 MB Shared 10 269.19 ms 166.53 445 0 515.6 MB Shared 20 217.23 ms 255.81 960 0 537.05 MB Basic Small 15 369.8 ms 675.81 2.24 k 0 421.83 MB Basic Small 30 531.97 ms 773.88 2.51 k 0 285.67 MB Basic Medium 25 270.54 ms 1.01 k 3.74 k 0 607.58 MB Basic Medium 50 453.78 ms 1.59 k 5.47 k 0 444.87 MB Test scenario with customized WordPress application with popularly used plugins After modifying the above vanilla WordPress with a few plugins to WordPress app as listed below: MotoPress Editor lite Jetpack Yoast SEO This configuration is similar to a production web application and we did not include include any caching layer to understand the performance of MySQL server running locally on the azure app service instance. Demo site: Web App Sku User Load Server Response Time CPU Time Requests HTTP Server Errors Average Memory Working Set Memory Working Set Standard Small 30 1.87 s 751.76 1.29 k 0 490.03 MB 7.47 GB Standard Small 50 2.23 s 762.9 1.23 k 0 489.14 MB 7.28 GB You can make the application load even more faster , by using one or more of the options below : Using Wincache object cache or using Azure Redis cache Caching static content using browser caching Minify JS and CSS files as per your application framework documentation Reducing HTTP requests per page Compress images as per your application framework documentation Optimize your database and perform regular clean up of your content Conclusion MySQL in-app feature is recommended for development and testing purposes. Based on the data above you can see that this feature improves the performance of your PHP application since both the Web server and MySQL server are co-located on the same instance. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2016/08/18/Benchmarking-MySQL-in-app-performance.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Exporting your database to MySQL in-app database",
+ "excerpt":" mksunitha 8/18/2016 4:27:45 PM This blog post will guide you through the process of exporting your current website's database to local MySQL. Follow the process below to export your database: Locate and access your current database: Your database must be remotely accessible. Check your existing hosting provider on how to access your MySQL database. Most common tool used is PHPmyadmin for accessing your database. Check out this article on How to setup PHPmyadmin for your Azure Web App if your app is already running on Azure. PHPmyadmin is browser based tool that can be used to manipulate and manage your database. You may also use MySQL workbench to access your database . Check out this article on how to access your database using MySQL workbench. Export your database and Save it locally PHPmyadmin Access your database using PHPmyadmin and click on Export tab. Select Custom export method to have the ability to modify how the script should be generated. Click on GO to generate the script and save the file locally . MySQLDump.exe If you have MySQL installed on your local machine you can using mysqldump.exe utility usually found in the bin folder within MySQL folder. To export a remote database run the command in this format D:\\Program Files (x86)\\mysql\\5.7.9.0\\bin>mysqldump -P port_number -h host_name -u mysql_user -p database_name > result_file.sql Example: D:\\Program Files (x86)\\mysql\\5.7.9.0\\bin>mysqldump -P 48926 -h mysqlserver.cloudapp.net -u root -p mywordpressdb > mydatabaseexport.sql MySQL workbench This tool offers an export wizard as shown below to export your database content. Check out the documentation for using the Export wizard to export the database Once you have successfully exported the database, then inspect your MySQL database script to check if your application stores the site URL in the database. If yes, then update the URL to use Azure app service web app URL or custom domain if the custom domain is already pre-configured on your Azure web app. Your script is ready to be imported. Import your database Go to your web app Settings->Feature -> MySQL in-app to access the management settings for this feature. Import Feature in Azure portal : Select MySQL in App setting , under Data Import and Export select \"Import\" to import a remote database into MySQL In App database . Enter the remote database connection information to import the database. Note that MySQL In App uses MySQL 5.7.9 version and make sure your remote database is compatible with this version of MySQL . Using PHPmyadmin : To open PHPmyadmin for your MySQL in-app database . Check your SQL script and make sure the USE statement is using the database name “azuredb” . This is the database used with the connection string we provide with MySQL in-app. If the USE statement has a different database name, update it to use azuredb database. Then Click Import in the top menu in PHPmyadmin .Under File to Import, click Browse and select the script your exported from your source database. Then click Go to complete the import. When the import is completed and successful, you can update your web app to connect to azuredb database with the imported database schema. That's it and your database migration is completed. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2016/08/18/Exporting-your-database-to-MySQL-in-app-database.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "PHP runtime and extension updates including potentially breaking changes",
+ "excerpt":" Cory Fowler (MSFT) 8/22/2016 10:04:49 AM In an upcoming release, we are making some changes to the available runtimes and PHP extensions on the Azure App Service workers. We suggest that you review your sites to ensure that these changes do not cause any downtime of your applications or tooling. PHP Runtime Updates Due to some recent high priority security updates, we are adjusting the runtimes that are available on Azure App Service workers. For more details on the changes, please review the links to the specific version changelogs available in the After Update column of the table below. Note: PHP 5.4 will soon be retired on Azure App Service as it is no longer receiving security updates. See more details about the retirement on the Azure Blog. Runtime Version Currently Supported After Update 5.4 5.4.45 5.4.45 5.5 5.5.36 5.5.38 5.6 5.6.22 5.6.24 7.0 7.0.7 7.0.9 PHP Extension Updates SQL Server Driver for PHP 7 Recently the SQL Server team released the Microsoft drivers 4.0 for PHP,which includes support for PHP 7. Now that this driver is no longer in preview, we are including the driver on the workers by default. If you have been loading your own version of this driver, you will need to remove the statements which are loading the driver as having a duplicate reference will cause errors. XDebug We are updating the version of XDebug which is available on the workers by default. Currently, we have version 2.2.4 available in d:\\devtools\\xdebug which is being replaced by version 2.4.0. If you are referencing XDebug for profiling or remote debugging purposes, the extension will no longer be available on the workers and the references will need to be updated to point to 2.4.0. The good news is that XDebug version 2.4.0 supports PHP 5.5, 5.6 & 7.0, which means all supported runtimes now have the ability to take advantage of XDebug for debugging and profiling purposes. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2016/08/22/PHP-runtime-and-extension-updates-including-potentially-breaking-changes.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "New App Service quota UX",
+ "excerpt":" Byron Tardif 8/26/2016 12:37:00 PM Apps hosted in Free and Shared App Service plans get access to certain amounts of resources based on their quotas. You can learn more about app service quotas and how the apply to your apps here: How to: Monitor Apps in Azure App Service The new quota UX let’s get an at a glance view of the quotas applicable to your app. Each quota contains basic information about (1) the current utilization, (2) the limit for this specific quota, (3) when will the quota re-set and (4) the quota name. You can manually refresh the view by clicking on the refresh button in the action bar or provide us feedback directly about this new UX. This new UX makes it easier to understand the resource usage for your apps and what resources are being exhausted. If you have any questions about this UX or App Service in general be sure to check our forums in MSDN and Stack Overflow and for any feature requests or ideas check out our User Voice ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2016/08/26/New-App-Service-quota-UX.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Onboarding to Azure Web Marketplace and Certification",
+ "excerpt":" mksunitha 8/26/2016 2:28:03 PM Azure Marketplace is a hub of solutions for users to create different types of resources. Each category of resource such as Data services, Virtual machines, Web have different on-boarding processes for ISVs to publish their solutions in Azure marketplace. In this article we will discuss the process to on-board Web Apps to Web Marketplace in Azure. To showcase your application in Web Azure marketplace , you need to get your application certified. The certification process is a 5 Step process. APPLICATION Step 1: Apply by providing basic information about your business and solution Step 2: Share solution-specific information and wait for approval ONBOARDING Build your Azure package and provide the marketing content for your application . See details below. CERTIFICATION We’ll run tests to verify compatibility with our platform or service PUBLISHING Step 1: Showcase the Azure certified logo for your application Step 2: Publish your application on Azure Marketplace/Azure pages MARKETING Promote and market your application taking advantage of Microsoft go-to-marketing resources On-boarding New applications to the Web Azure Marketplace For new applications: The on-boarding process is a gated approach and the application will be reviewed by our team. Click here to request for certification. Leverage the benefits of this program from being showcased in the Azure Marketplace but also advantages of being part of Microsoft partner network. Follow the guidelines mentioned below to build your template and test your application on App service. If accepted we will enable it in the Azure portal. Existing Applications: We will continue to maintain existing applications in the Azure Web Marketplace. Please reach out appgal@microsoft.com if you haven't already to get details on updated process for managing updates to your application. Azure Web Marketplace Principles Users can browse and view applications for different types of Web sites, ranging from photo galleries to blogs to e-commerce sites. To be part of the Azure Web Marketplace, developers should follow these principles, which establish a consistent, quality user experience: Be Current: The application you provide a link to must be the latest, stable final release version available, hosted on a publicly available Web URL. Application License: The application Azure Web Marketplace may provide an entry point free of charge or use Bring your own license model (BOYL) where users can purchase a license from the application publisher's website. Be Compatible: The generated and configured application deployed from Azure Web Marketplace must also run on any Windows OS.The application should support running on cloud infrastructure by providing an option to make the application stateless. Be Hostable: The application to which you provide a link must run well in a shared hosted environment as well as when the user has administrative rights for the computer. Be Deployable: Your application code must be available on a public repository on Github.com . Azure users should be able to fork the repository and deploy to Azure web app. Be Supported: You must provide a publicly available Web site where end users can download your application, find documentation and/or get free on a best effort basis support through a forum. Be Platform Independent: The application to which you provide a link must be able to run on all Windows platforms x86, and x64. Be Inclusive: If your application is included in the Gallery, you should include a statement of availability in the Azure App Gallery on the application community’s Web site. Be Safe: The application to which you provide a link must not harm customers or be malicious, dishonest, destructive, invasive, or act in any manner restricted by the Web Gallery Application Submission agreement. Be a Web App: The application to which you provide a link must be a Web application that can be used to generate a working, usable Web site after deployment without requiring code or customization. Support Database Dependencies: Currently our create experience supports Web App with Database ( MySQL and/or SQL DB). If your application has other dependencies , Web Marketplace may not be an option.You may want to look into Azure solution templates. Package your application code Using Git Deploy: Create a public Github repository with your application code as it would be deployed under wwwroot in the Azure web app. You may include custom post deployment scripts with a deploy.cmd file in the root of your repository, see details on how to add custom scripts. This packaging method makes managing updates to your application easier without having to go through the entire certification process. For future updates to your application , you need to update the code in the repository with appropriate commit message for users to pull in to latest bits of your application. When code changes are committed to your repo , the code is not automatically pulled in for users using your application to prevent breaking their application. Users using your application must perform a manual sync to pull in the latest committed changes from your repository. Note: We are no longer supporting Web deploy method of application packaging for NEW applications in the Web marketplace. Building an Azure Package for Marketplace Azure Package has a special folder structure to be consumed by Azure Marketplace service. Each folder at the root level approximately represents a publisher. A folder contains one or more .json files, called package manifests, each of which contains the metadata for an Azure Gallery package. Every folder also includes a set of deployment templates, strings , icons and screenshots which can be referenced by the package manifests. See the folder structure shown below : /MyPackage/ /MyPackage/Manifest.json /MyPackage/UIDefinition.json /MyPackage/Icons/ /MyPackage/Screenshots/ /MyPackage/Strings/ /MyPackage/DeploymentTemplates/ You can find sample packages on GitHub . Manifest.json: The manifest file contains all of the metadata for your gallery item. For a visual representation of where each metadata value is used , view the schema for Manifest.json. Add the paths to the Icons , Screenshots and links to articles that can help customers get more information about your application. UIDefinition.json :Use the UIDefintion.json schema to build appropriate UIDefinition.json for your application. You can use \"parameters\" properties which is optional , if your application needs to ask the user for information for the deployment of your app. These parameters become AppSettings for your web app and can be consumed within your app as environment variables.To hide a parameter from the portal UI , set \"hidden\":true as show here . To mark a parameter as required for the create experience , set \"required\":true as shown here. Icons : The relative path specified by iconPath in a package manifest must point to a folder that includes the following four images with these dimensions mentioned below: Small.png (40x40 px) Medium.png (90x90 px) Large.png (115x115 px) Wide.png (255x115 px) You can group icons under sub-folders if you have different ones per product. Just be sure to include the sub-folder in the iconPath for the package manifest that uses them. Screenshots : Images must be exactly 533px by 324px and in PNG format. Specifying a screenshot for a gallery package is completely optional, so do not feel compelled to include one unless it makes sense for your offering. Deployment Templates : Include an ARM template that allows Azure users to deploy the application via PowerShell. To learn how to build an ARM template , read the guidelines stated here . Strings: Include resources.resjson and description.md files to include the description about your application. Here is a sample description.md and sample resources.resjson. Update your application version When there is a new version of your existing application, update the following : Change the packageURL property in UIdefinition.json file to point to HTTP URL for your application. Change the packageURL in Deployments/Website_NewHostingPlan_SQL_NewDB-Default.json file with the HTTP url for your application. [Optional] Update icons or screenshots , strings if needed Build a new azure package in ZIP format and submit a request to certify. Test your application Follow the criteria below Build an ARM (Azure resource manager) template as per guidelines stated here . You can find a sample here Use the Azure resource manager templates and deploy using PowerShell. Run these tests in at least 3 different Azure regions. Save the results of these deployment in an Excel or Word document. The excel document should have the following columns: Resource group Web app name Region Subscription ID Time of deployment Web app Pricing Tier or Sku Tested with Auto-scale feature[ Values : Pass/Fail] Test your application with auto-scaling feature turned on and under a heavy load . For example you can choose to run a 5 min load test of 50 users on Web App Standard Small (S1) Pricing tier Tested with Continuous Integration[ Values : Pass/Fail] In this test , publish changes to your application and see if you changes are being picked up by your application linked to the Github repository . Tested with Deployment slots [ Values : Pass/Fail] In this test , create a deployment slot. Connect to the application Github repository to the deployment slot. Push changes to the github repository and then complete to Swap your application slot with production slot. Tested with Backup and restore [ Values : Pass/Fail] In this test configure and setup Backup for your application code and database (optional) to be backed up. restore from the backup ZIP file to an existing site There are some limitations with the Azure create in the portal and power shell . If your application requires these configurations mentioned below , we will not be able to on board the application. You web app need Virtual application setting to be configured for web app Your web app need a dependency that is not supported by App Service create scenario. We currently support ONLY SQL DB , MySQL and Azure Storage dependencies. Submit your application Submit a certification request here . Please do provide information about your application during submission . Here is the kind of information we are looking for to learn about your application What is current Usage statistics of your application Do you have customers using your application on the Cloud ( Azure or other hosting providers). If yes share at least 2 customer stories. How active is the community engaged , primarily for Free applications this information is required You will receive a response in 3-5 business days with a request for more information or with next steps to move forward. Post publishing We recommend to maintain documentation and support for your application on your website. This is key to help get new users started with using your application and follow best practices based on your guidance. Marketing Once approved your application will be visible in the Azure portal under \"Web + Mobile\" category. Users can view your application on Azure website in the Marketplace page. FAQ Check out the frequently asked questions here . If you don't see the answer to your question , contact us at appgal@microsoft.com ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2016/08/26/Onboarding-to-Azure-Web-Marketplace-and-Certification.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Azure Functions 0.5 release & August portal update",
+ "excerpt":" Chris Anderson (Azure) 9/1/2016 11:20:33 AM We're happy to announce we've officially released Azure Functions host version 0.5 into our Public Preview, as well as some updates to our Portal experience. The host version does include several breaking changes, so please read the release notes before upgrading. We will also be updating our default version in create to ~0.5 as well, so new deployments that don't specify a version will be on the latest. F# support now in preview Thanks to the excellent work by the F# team including Don Syme and Tomas Petricek, we're happy to announce we finally support F# in a first-class fashion in Azure Functions. Previously, we just invoked your F# script via fsi. Today, it now running hot in our runtime, with support for input and output bindings. Note that this new F# experience is incompatible with the previous versions. Here's a quick sample that would work off of a Queue trigger. let Run (input: string, log: TraceWriter) = log.Info(sprintf \"F# script processed queue message '%s'\" input) If you are familiar with the C# experience, you'll remember the TraceWriter. This is because we support all the same types that C# supports. We haven't finished updating the documentation yet, but we'll be soon updating the C# docs to be the .NET docs. For those curious in how it was built, feel free to check out PR #577. Other breaking changes & improvements In addition to F# support, we have a few other breaking changes and notable improvements. You can read our full release notes on 0.5 release on GitHub. Now using Node v6.4.0 (previously v5.9.1) - next update will be to Node v6 LTS sometime October. HTTP Trigger now supports binding to body/querystring properties. Event Hub trigger can now configure maxBatchSize and prefetchCount for advanced scenarios. C# Package Restore automatic restore improvements Logging improvements for performance and usability File Watcher can now be configured for where to look for changes. context.bindingData property casing is now lower camel cased (previously upper camel cased) Twilio is now supported as a binding by the host. Portal updates We also have some large updates to the portal experience rolling out today. Below are some highlights: Localization is now available for many languages Tabs have all been moved to the left nav, rather than left and top. This change happened to improve usability in understanding Functions vs Function Apps. Actions for certain output bindings on Integrate tab. We found it was common to copy+paste settings from an output binding to a new trigger, so we added a button to do it for you. Dropdown pickers for connections - if you have an existing connection to Storage/etc., we'll show you those in a dropdown menu, rather than always having to choose from the picker blade (which can have LOTS of choices for large, shared subscriptions). Documentation is now available in the Integrate tab. This will hopefully make it more obvious how to use the bindings when you add them/modify them, rather than knowing where in the main docs site to look. You can now delete/rename files from the file explorer menu on the Develop Tab. Better whitespace usage on Integrate tab App Settings, Kudu, and Console now available from the Function App Settings menu, rather than having to jump through Advanced Settings. What comes next? With this release complete, we'll be starting our next wave of planning. We need and look forward to your feedback. You can submit general feedback on feedback.azure.com or, if you feel familiar with our host or portal, you can submit issues directly on GitHub (Host GitHub & Portal GitHub). Most of our planning happens on GitHub, so you can see things coming as they are in progress. Feel free to ask questions below or reach out to us on Twitter via @AzureFunctions. We hope you have fun with the new changes. We're looking forward to seeing what you do! ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2016/09/01/Azure-Functions-0.5-release-and-August-portal-update.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Troubleshooting FAQ for MySQL in-app",
+ "excerpt":" mksunitha 9/8/2016 1:09:42 PM Here are some troubleshooting guidelines for MySQL in-app feature: 1. I cannot to access the database using Phpmyadmin When you access PHPmyadmin for MySQL in-app and the page returns a login page or “cannot connect: invalid settings” error. There can be two causes for this issue: MySQL process may not be running. Check process explorer if MySQL is running for your web app. You can access the process explorer in the portal. Select your web app -> Tools -> Process explorer There will be mysqld.exe process visible in the process explorer. If the process mysqld.exe is not visible in the process explorer, then browse the web app or ping your web app which would trigger mysqld.exe process to run. Check process explorer again to verify that mysql process is running and browse phpmyadmin. You have two instances of PHPmyadmin installed With MySQL in-app we already preconfigure and setup PHPmyadmin. If you install PHPmyadmin from Site extensions gallery, then you will end up having two instances of PHPmyadmin. To identify if you have two instances both the conditions below will be true: PHPmyadmin folder exists in D:\\home\\siteextensions folder web app is using MySQL in-app feature To resolve this, remove the site extension. Access the site extension gallery and click on remove button. Restart your web app and access your database with PHPmyadmin . There may be a connection strings in application settings. Check in your web app application settings if there is a connection string. PHPmyadmin uses MYSQLCONNSTR_ to connect to the MySQL server. If you have a connection string in application setting change the connection string type to Custom , so you can still have the information if needed or delete it. This will force PHPmyadmin to access MYSQLCONNSTR_localdb and connect to the MySQL in-app server. File server storage is in read only mode Click here to learn more 2. My application cannot connect to MySQL in-app database If your web app is unable to connect to MySQL in-app database, it could result from : MySQL process is not running for your application: You can access the process explorer in the portal. Select your web app -> Tools -> Process explorer. There will be exe process visible in the process explorer. If the process mysqld.exe is not visible in the process explorer, then restart the web app and browse the web app. Now check process explorer again to verify mysqld.exe loads and check if your web app is functioning correctly. Your web app is not configured correctly to use MySQL in-app: MySQL in-app does not use port 3306 for MySQL server and hence DO NOT hard code the database information in your application configuration file. If the MySQL port used by your web app as using in not available during the situations mentioned below, the MySQL port will change:during an upgrade of azure app service when your web app is scaled up/down when your app is moved to a different app service plan when you migrate your app from one subscription to another subscription To make your app resilient, use environment variables as shown here. 3. I cannot import my database with PHPmyadmin PHPmyadmin allows your to import a database , but this may fail due to: MySQL server used when exporting the database is different than the MySQL version used in MySQL in-app and the schema changes are not supported in the version of destination MySQL server.The version on MySQL in-app is 5.7.9.0. You verify this check by checking the version number folder in MySQL folder \"D:\\Program Files (x86)\\mysql\\5.7.9.0\" PHPmyadmin version used for exporting the database varies with PHPmyadmin version used to import the database schema. The PHPmyadmin version that is used with MySQL in-app is 4.5.1. During export make sure the schema is supported. A workaround is to use mysqlimport.exe found in D:\\Program Files (x86)\\mysql\\5.7.9.0\\bin on the Kudu Debug console \"D:\\Program Files (x86)\\mysql\\5.7.9.0\\bin\\mysql.exe\" --user=azure --password=password --port=PORT --bind-address=127.0.0.1 DATABASE_NAME < exportedfile.sql The exported database file is greater than 8MB. PHPmyadmin is a php application , and the max_upload_size is 8MB for PHP on Azure app service. You can either modify the max_upload_size to your desired value before doing an import as per instructions mentioned here or use mysql utilities in Kudu debug console to do the import with this sample command \"D:\\Program Files (x86)\\mysql\\5.7.9.0\\bin\\mysql.exe\" --user=azure --password=password --port=PORT --bind-address=127.0.0.1 DATABASE_NAME < exportedfile.sql Note: When using mysqlimport.exe via Kudu debug console , the browser session timesout after 10 mins. If you have a large file then add the app setting SCM_COMMAND_IDLE_TIMEOUT=3600 for your web app prior to running mysqlimport.exe. 4. I cannot write to the database OR I cannot create a comment or post on WordPress application Turn on PHP error logs and if the error log states that the \"InnoDB is in read only mode\". This means file server storage is in READ ONLY mode , note that the file server is shared by your web app and MySQL database. The file server can be in read only mode due to an upgrade on the service : Once the upgrade is completed you should be able to write to the database. This usually does not take more than a few minutes. Platform issues : Check the Azure status to see if there are any ongoing issues that could be resulting in this. Network blips : This could impact the site for a couple of seconds if there was network connection loss. It is recommended to code your application to detect if the storage is in read only mode when using MySQL in-app. This can be done using a simple check to see if the folder wwwroot is writable using is_writable() in PHP before executing any INSERT / UPDATE / DELETE /CREATE Sql queries in your application. 5. How can I change MySQL server configuration Click on your web app -> application setting , under app settings add the Key/Value pair , for example to increase max allowed packet to 16MB WEBSITE_MYSQL_ARGUMENTS = --max_allowed_packet=16M Additional References Troubleshooting Wiki ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2016/09/08/Troubleshooting-FAQ-for-MySQL-in-app.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "PHP troubleshooting guide for common errors",
+ "excerpt":" mksunitha 9/14/2016 12:37:03 PM Here is a troubleshooting guide for PHP errors on Azure app service. 5xx Errors Multiple loaded extension: You might notice an error in php_errors.log when a extension is not loading. It could be that there is another extension already pre-configured on the platform. Install PHP manager ( extension as shown in the image) from the portal to check which extension are available and/or enable before bringing in your custom php extension. MySQL gone away: This error can occurs due to various reasons as listed below: • A query was executed after closing the connection to the server. This is a logic error in your application. Review your code and make changes. • The connection may have timed-out. You can use mysqli_options() to increase the timeout. • Long running query especially using INSERT or REPLACE commands can cause this issue. • Since ClearDB is different service, there could have been a networking blip connecting to ClearDB database. To work around this, you can add a retry logic to connect to your database. • If you are using ClearDB shared hosting, note that it is shared hosted service and if another user is using up all the resources you might get this error. To work around this, you can add a retry logic to connect to your database. • MySQL server may have crashed due to an incorrect query. Review your code to identify the query. Redis gone away: This can happen due to network blips or if the server is down. As best practice include a retry logic to connect to your Redis server. For further troubleshooting, check this article. Database deadlock error: Deadlocks occur when are there are multiple requests to write to the same table/ same record (based on the lock configuration on your database) at the same time. To avoid this, you need to include some logic in your app to manage deadlock scenario. Error connecting to database: Check if your database is accessible. You can use MySQL workbench or mysql command line Deprecated warning: It is recommended to notices and deprecated errors to reduce the stress on PHP process when writing to the logs especially if you app does generate too many notices and warning. These should b enabled on your staging or dev sites but on your production site it should be disabled. Read this article on how to change the way error is logged in PHP. Checkout additional articles on PHP troubleshooting. Performance Issues Best way to identify your application performance issues, is to profile your application. Use Xdebug profiler to profile your application. The most common reasons that could impact performance are: PHP error reporting is turned on. If your application is returning too many warnings that is causing PHP process to write to php_errors.log. This can impact performance. Your app is making too many I/O operations. Note that the file storage is Azure Storage linked to your web app like a network drive. Too many calls to read or write can impact performance. You can reduce the read operations by using Wincache filecache and Wincache reroute settings. App may be causing an overhead on the database by making too many calls to the database. Use Wincache or Redis cache to reduce the stress on your database. Security Issues Using mysql extension: MySQL extension has been officially deprecated . It does not support SSL and does not support for many MySQL features. Using this is a security risk and users can look for the php warning \"The mysql extension is deprecated and will be removed in the future\" and identify if a site is using mysql extension. Upgrade your mysql driver to use mysqli instead of mysql extension. <?php $mysqli = new mysqli(\"localhost\", \"user\", \"password\", \"database\"); if ($mysqli->connect_errno) { echo \"Failed to connect to MySQL: (\" . $mysqli->connect_errno . \") \" . $mysqli->connect_error; } echo $mysqli->host_info . \"\\n\"; ?> Disable development configurations: Disabling all your development environment configuration such as debug configuration. This opens your application to security risk allowing access to malicious users to information on your web app. Using \"admin\" username for your web app administration dashboard : All CMSs like WordPress, Drupal etc. provide you're with an administration dashboard. admin is the most common username used for a super administrator user and can be easily hacked by malicious users. Hence NEVER use admin as a username for your super administrator for your web application. It is recommended to enforce a strong username and password for a super administrator users. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2016/09/14/PHP-troubleshooting-guide-for-common-errors.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Get some hands-on time with Serverless development right now, for free",
+ "excerpt":" Yochay Kiriaty 10/4/2016 4:38:07 PM If you are reading this blog, you have most likely heard the term Serverless once or twice in the past few months. In a nutshell, Serverless means a fully managed platform capable of running your code (in the form of functions), at almost any given scale while paying only for the time when your code is running. Serverless is sometimes categorized as ‘reactive’ compute, where functions are executed (react) when specific events occur. For the purpose of this blog, I will focus on the developer experience. There are several options to get firsthand experience with Serverless development, but all options require creating an account (typically providing credit card information) with a vendor. This changes today. Now you you can get a peek into the world of Serverless for free (no credit card required) with no commitment. If you have a Microsoft, Google, or Facebook account you can get started immediately. To get an hour of free Azure Functions experience browse to https://functions.azure.com and click the big green Try-It-For-Free button. Azure Functions is a Serverless compute, event driven experience that extends the existing Azure App Service platform. Azure Functions can scale based on demand and are billed only for resources consumed. Try Azure Function experience gives you the ability to create Azure functions and run them, even without an Azure account. Since this a “Try” experience, you don’t have access to all binding and triggers supported by Azure Functions, and you only have one hour each time you log-in. However, even with these limitations you can create cool Serverless examples. Ready? let’s get started Let’s start out by using the Try Azure Functions experience to create a simple HTTP trigger function.. Here is a very simple HTTP trigger “Hello World” example. Try it yourself: Login to Try Functions (go to https://functions.azure.com and click the green Try-It-For-Free button) Choose Webhook + API scenario (many other templates are available for other scenarios) Choose your programming language between C# or JavaScript (node.js). Azure Functions support additional languages like F#, Python, PowerShell and CMD. Click “Create this function” button, which will prompt you to login Login with your selected social identity, wait for few seconds… and you have an HTTP trigger function ready for use You can copy the Azure Function URL (highlighted below) and paste it into your browser. You should receive a response. You might want to add &name=YourName to the Function URL as the default http trigger template expects name query parameter. Just like that, you created a fully working HTTP endpoint in the cloud. While this was is an impressive example of how easy it is to create an HTTP endpoint in the cloud, it turns out you can do quite a lot more! Let’s put together the following scenario. Upload an image that includes some text in it, run an OCR on the image to extract the text, store the text, and finally retrieve both image and text. For small images or for a low volume of image uploads, you can probably do it all in a single Function. However, we want to leverage the Serverless nature of Azure Functions to create a scalable and highly performant design. To do so, we will create three functions: An HTTP trigger function exposing simple REST API to upload an image. A blob trigger function that will extract the text from the image when it id uploaded to the blob storage. Another HTTP trigger function exposing simple REST API to query the results of the text extraction. First Function – a simple REST API uploading an image to Azure Blob You can imagine a scenario in which you have a web or mobile app that needs to upload images for processing. A function receiving the uploaded image can expect an HTTP POST from an HTML form that might look like this: <label> Using JQuery </label> <input name=\"file\" type=\"file\" id=\"me\" /> <input type=\"button\" id=\"Upload\" value=\"Upload\" /> </form> We want our function to receive an image and store it in Azure Blob Storage. This is a classic reader/writer pattern, where you want your API layer to do as little complex computing as possible. The Azure Functions concept of Bindings enables developers to directly interact with the input and output values of Functions data sources. Those include Azure Storage Queue, Tables, and Blobs as well as Azure Event Hubs, Azure DocumentDB and more. Click here for full list of binding. Let’s add an Azure Blob output binding. On the Integrate tab, click New Output and choose Azure Storage Blob. The Blob parameter name, is an input argument (parameter) passed to your Function. Just like you would expect when programing any regular function. Azure Functions takes it one step further, enabling to use such bindings without knowing anything about the underlying infrastructure. This means that you don’t need to know how Azure Storage works or install Storage SDKs to use Azure Blob as your function output. You just use the outputBlob object in your function, save the image to that blob and the uploaded image will appear in your Storage Blob. In the try experience you don’t have a direct access to the underline storage account powering your Functions. However, you will see it in action by the time you complete the 3rd function. Make sure you update the Path to include “.jpg”, and hit Save. In the function code, we refer to outputBlob as an object that is ready to be used. This function is implemented in C# and uses StreamProvider to read the image data from the HTTP request and store it to an Azure Blob. I don’t have any idea how Azure Storage works. Behind the scenes Azure Functions takes care of moving data in to and out from my functions. It is like magic, quick and easy to use. #r \"Microsoft.WindowsAzure.Storage\" using System.Net; using Microsoft.WindowsAzure.Storage.Blob; public static HttpResponseMessage Run(HttpRequestMessage req, Stream outputBlob, TraceWriter log) { log.Info($\"C# HTTP trigger function processed a request. RequestUri={req.RequestUri}\"); HttpResponseMessage result = null; if (req.Content.IsMimeMultipartContent()) { // memory stream of the incomping request var streamProvider = new MultipartMemoryStreamProvider (); log.Info($\" ***\\t before await on ReadMultpart...\"); req.Content.ReadAsMultipartAsync(streamProvider); log.Info($\" ***\\t after await on ReadMultpart...\"); //using a stream saves the 'last' iamge if multiple are uplaoded foreach (HttpContent ctnt in streamProvider.Contents) { // You would get hold of the inner memory stream here Stream stream = ctnt.ReadAsStreamAsync().Result; log.Info($\"stream length = {stream.Length}\"); // just to verify // save the stream to output blob, which will save it to Azure stroage blob stream.CopyTo(outputBlob); result = req.CreateResponse(HttpStatusCode.OK, \"great \"); } } else { log.Info($\" ***\\t ERROR!!! bad format request \"); result = req.CreateResponse(HttpStatusCode.NotAcceptable,\"This request is not properly formatted\"); } return result; } Second Function – Performs OCR Let’s create the second function, called ImageOCR. This function will be triggered every time a new image file is uploaded to the blob storage container (named outcontainer) by the first function. Then the function will run OCR on that image to extract text embedded in it. Note, this function will run only when a new image (or any other file…) is uploaded to the blob. Again, this is Serverless in its best form, your code will run only when needed and you will pay only for that time. Make sure the Azure Storage Blob container name you use to trigger is the same as the Blob container name used to write the image from the first function. If you have not changed the default, the container name of the first function is outcontainer. #r \"System.IO\" #r \"System.Runtime\" #r \"System.Threading.Tasks\" #r \"Microsoft.WindowsAzure.Storage\" using System; using System.IO; using System.Text; using System.Threading.Tasks; using Microsoft.WindowsAzure.Storage.Blob; using Microsoft.ProjectOxford.Vision; using Microsoft.ProjectOxford.Vision.Contract; using Microsoft.WindowsAzure.Storage.Table; public class ImageText : TableEntity { public string Text { get; set; } public string Uri {get; set; } } public static void Run( ICloudBlob myBlob, ICollector outputTable, TraceWriter log) { try { using (Stream imageFileStream = new MemoryStream()) { myBlob.DownloadToStream(imageFileStream); log.Info($\"stream length = {imageFileStream.Length}\"); // just to verify // var visionClient = new VisionServiceClient(\"YOUR_KEY_GOES_HERE\"); // reset stream position to begining imageFileStream.Position = 0; // Upload an image and perform OCR var ocrResult = visionClient.RecognizeTextAsync(imageFileStream, \"en\"); //log.Info($\"ocrResult\"); string OCRText = LogOcrResults(ocrResult.Result); log.Info($\"image text = {OCRText}\"); outputTable.Add(new ImageText() { PartitionKey = \"TryFunctions\", RowKey = myBlob.Name, Text = OCRText, Uri = myBlob.Uri.ToString() }); } } catch (Exception e) { log.Info(e.Message); } } // helper function to parse OCR results static string LogOcrResults(OcrResults results) { StringBuilder stringBuilder = new StringBuilder(); if (results != null && results.Regions != null) { stringBuilder.Append(\" \"); stringBuilder.AppendLine(); foreach (var item in results.Regions) { foreach (var line in item.Lines) { foreach (var word in line.Words) { stringBuilder.Append(word.Text); stringBuilder.Append(\" \"); } stringBuilder.AppendLine(); } stringBuilder.AppendLine(); } } return stringBuilder.ToString(); } The function is triggered by any file uploaded to the blob container. The default input parameter type of the function is string, but I will be using ICloudBlob, as I want to read the image as a stream and I want to get the image file name and URI. As you can see, Azure Functions binding provides a very rich experience. To perform the OCR on a given image, I am going to use using Microsoft Cognitive Services , also known as Project Oxford. I could use any 3rd party tool, bring a dll that implements the algorithm, or write my own. However, leveraging other services as much as possible is a core tenant of Serverless architecture. If you don’t have a Cognitive Services account, sign up for free at https://www.microsoft.com/cognitive-services Using the Cognitive Services is very easy, it comes down to two lines of code: var visionClient = new VisionServiceClient(\"YOUR_KEY_GOES_HERE\"); // reset stream position to begining imageFileStream.Position = 0; // Upload an image and perform OCR var ocrResult = visionClient.RecognizeTextAsync(imageFileStream, \"en\"); In order to make the ImageOCR function code work, you’ll need to import ProjectOxford assemblies. Azure functions support project.json files to identify nuget packages (for C#) to be automatically restore with the function. For node.js Azure Functions support npm. In the Functions UI, click on View files and add project.json with the following text. once you save this file, Azure Functions will automatically restore the ProjectOxford package. In order to make the ImageOCR fFunction code work, you’ll need to import Project Oxford assemblies. Azure Ffunctions supports a project.json files to identify nuget NuGet packages (for C#) to be automatically restored with the functionFunction. For node.js, Azure Functions supports npm. In the Functions UI, click on View files and add project.json with the following text. Oonce you save this file, Azure Functions will automatically restore the Project Oxford packages. project.json { \"frameworks\": { \"net46\":{ \"dependencies\": { \"Microsoft.ProjectOxford.Vision\": \"1.0.370\" } } } } We want to save the results somewhere. In this Try Functions example we are using Azure Storage Table. Note – if you have an Azure Subscription, you can use many other Data Services provided by Azure to store and process the results. Let’s add an output binding to Azure Table Store Next, change the Table name from the default to ImagesText. The Table parameter name, outputTable will be used in the function code. And again, just like with the blob, I don’t need to know a lot about how Azure Storage Tables work. Azure Functions is doing all the heavy lifting. We are using the ImageText table to store the image Uri (pointer to the blob storing the image), the OCR results, and the table keys in the form of a GUID. You have now completed the creation of a function that scans an image, extracts text from it and stores the results into persistent storage. Third Function – simple REST API to query OCR results The last function we are going to create is of type HTTP trigger and will be used to return list of images and the text we extracted from the images in the second function. This time we will add an Azure Storage table as an input binding, because you would expect your function to receive the table store object to work with and extract the data. As before, make sure you are using the same table name you used in the second function. Note the Partition Key, which is optional was hard-coded for TryFunctions. The function input argument is of type IQueryable<ImageText>, which represent a collection of results queried from Table Storage. Its ready to use without any knowledge of how Azure Table Storage works, I get a list I can work with. We create a SimpleImageText object representing the response and return a JSON representation of the data. #r \"System.IO\" #r \"System.Runtime\" #r \"System.Threading.Tasks\" #r \"Microsoft.WindowsAzure.Storage\" #r \"Newtonsoft.Json\" using System; using System.Net; using System.IO; using System.Text; using System.Threading.Tasks; using Microsoft.WindowsAzure.Storage.Table; using Newtonsoft.Json; public static async Task Run(HttpRequestMessage req, IQueryable inputTable, TraceWriter log) { log.Info($\"C# HTTP trigger function processed a request. RequestUri={req.RequestUri}\"); var result = new List(); var query = from ImageText in inputTable select ImageText; //log.Info($\"original query --> {JsonConvert.SerializeObject(query)}\"); foreach (ImageText imageText in query) { result.Add( new SimpleImageText(){Text = imageText.Text, Uri = imageText.Uri}); //log.Info($\"{JsonConvert.SerializeObject()}\"); } // log.Info($\"list of results --> {JsonConvert.SerializeObject(result)}\"); return req.CreateResponse(HttpStatusCode.OK, JsonConvert.SerializeObject(result)); } // used to get rows from table public class ImageText : TableEntity { public string Text { get; set; } public string Uri {get; set; } } public class SimpleImageText { public string Text { get; set; } public string Uri {get; set; } } We created three functions, it is time to test them. You can use any of your favorite tools to generate HTTP calls, including CURL, writing a simple html / Java script, or anything else. To test both HTTP functions I’ll use Postman, using form-data as a Body to POST to the first function URL. You should receive “great” as a response and if you look at the first function log, in the Try Azure Function UI, you will notice traces from your function. If something went wrong, try debugging it… or ping me on Twitter (@yochayk) Assuming your first function worked, go to the OCR image function and upload another image. You will notice that the OCR function got triggered, which means your first function successfully saved the image to storage and your second function picked it up. Again, you should see in the log traces from your function. Use Postman to call the last function and you should see JSON array including two images and the text extracted from them. here is repo with the function. Note, my solution is a little more complex and includes handling multiple uploaded files and adding a SAS token to the container. One small note: if you want to view the images, you will need to generate a SAS token for the container, as by default, an Azure Blob Storage container permission blocks public read access. I’ve added the required code, which generates a 24 access token to images, to the ImageViewText functions. You will also need to pass the blob container as input argument for the functions. // IQueryable return list of image text objects // CloudBlobContainer used to generate SAS token to allow secure access to image file public static async Task Run(HttpRequestMessage req, IQueryable inputTable, CloudBlobContainer inputContainer, TraceWriter log) { log.Info($\"C# HTTP trigger function processed a request. RequestUri={req.RequestUri}\"); //get container sas token var st = GetContainerSasToken(inputContainer); //log.Info($\"token --> {st}\"); var result = new List(); var query = from ImageText in inputTable select ImageText; //log.Info($\"original query --> {JsonConvert.SerializeObject(query)}\"); foreach (ImageText imageText in query) { result.Add( new SimpleImageText(){Text = imageText.Text, Uri = imageText.Uri + st}); //log.Info($\"{JsonConvert.SerializeObject()}\"); } return req.CreateResponse(HttpStatusCode.OK, JsonConvert.SerializeObject(result)); } // used to get rows from table public class ImageText : TableEntity { public string Text { get; set; } public string Uri {get; set; } } public class SimpleImageText { public string Text { get; set; } public string Uri {get; set; } } // generate 24 hour SAS token for the container. Will allow read for all images // TBD - shoudl be done once every 24 hours via timer, rather than each time in the funciton static string GetContainerSasToken(CloudBlobContainer container) { //Set the expiry time and permissions for the container. //In this case no start time is specified, so the shared access signature becomes valid immediately. SharedAccessBlobPolicy sasConstraints = new SharedAccessBlobPolicy(); sasConstraints.SharedAccessExpiryTime = DateTime.UtcNow.AddHours(24); sasConstraints.Permissions = SharedAccessBlobPermissions.Read; //Generate the shared access signature on the container, setting the constraints directly on the signature. string sasContainerToken = container.GetSharedAccessSignature(sasConstraints); //Return the URI string for the container, including the SAS token. return sasContainerToken; } With the updated ImageViewText function you can now test your application with a simple Single Page Application I host on Azure Storage http://tryfunctionsdemo.blob.core.windows.net/static-site/test-try-functions.html This simple HTML application has two text box for you to paste the URL of your function. You upload an image by dragging and dropping. You can get images by clinking the GetImages button. The screen capture shows the network calls and console for getting images. You can see on the console, the get images return array of images, with respective URIs and each image text, which we use to then display. Note the images have SAS tokens. Hope you enjoy trying Azure Functions as much as I enjoyed writing this little demo. If you have any issues ping me on Twitter (@yochayk). ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2016/10/04/Get-some-hands-on-time-with-Serverless-development-right-now,-for-free.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "App Service Mobile Apps .NET Client SDK 3.0.1 Release",
+ "excerpt":" Mimi Xu (Azure) 10/6/2016 1:53:07 PM We just rolled out Azure Mobile Client SDK 3.0.1 and Azure Mobile SQLiteStore 3.0.1! Here are the updates we made: This Mobile Client SDK release is out of 3.0.0-beta! The previous Mobile SQLiteStore 2.x.x libraries depending on SQLitePCL, which uses the Android system SQLiteStore, no longer works with Android Level 24/Android N. Starting with Android Level 24/Android N, the Android system SQLiteStore cannot be accessed expect through the android.database.sqlite Java wrapper (Eric Sink has a great blog post here detailing the issue). This enforcement from Android impacts customers working with native Android, Xamarin.Android, and Xamarin.Forms Android. This 3.0.1 release updates the Mobile SQLiteStore library to take dependency on SQLitePCLRaw.bundle_green and SQLitePCLRaw.Core to resolve this problem. We unified versions across .NET Client SDK and SQLiteStore library to make dependencies and developer experience more straightforward. To take advantage of the releases, simply uninstall dependencies to your client project and grab the latest versions with Visual Studio package manager. Let us know if you bump into any issues! ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2016/10/06/App-Service-Mobile-Apps-.NET-Client-SDK-3.0.1-Release.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Upgrade ClearDB MySQL database in Azure portal",
+ "excerpt":" mksunitha 10/6/2016 10:52:42 AM ClearDB MySQL database now supports single step upgrade in Azure portal. If you using a ClearDB database you may at some point in time hit quota limitations on ClearDB such as max connections or storage limits . For more details in pricing tiers and quota limits click here. How to upgrade your ClearDB MySQL database Login to Azure portal Click on All resources and select your ClearDB MySQL database Click on Settings->Scale up your database 4. Select the pricing tier. Currently on single step upgrade is supported , which means if the current pricing tier is Mercury , you can upgrade to Titan . You cannot upgrade from Mercury pricing tier to Venus pricing tier at the skipping other pricing tiers during the upgrade. Key things to remember: Currently this feature does not support downgrade from higher pricing tier to a lower pricing tier. If you are using a database on Jupiter tier. You will not see scale up database setting in the Azure portal . ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2016/10/06/Upgrade-ClearDB-MySQL-database-in-Azure-portal.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Announcing Azure App Service Companion preview",
+ "excerpt":" Byron Tardif 10/10/2016 12:04:17 PM UPDATE: Azure App Service companion is now available in the Apple App Store for your iOS devices Today when you are managing your existing Azure App Service assets you have two options, the Azure Portal, or Azure CLI both of these experiences are great when used in your laptop/desktop regardless of what operating system you are using. However, neither of them are tailored for use in mobile scenarios. This is where Azure App Service Companion comes into play. The goal for Azure App Service Companion is to provide the basic functionality that you need when you are on the go, without requiring you to use your laptop. All in a native experience for your device. Azure App Service Companion allows you to: Monitor your App Service instances View custom alerts based on site status Troubleshoot sites from anywhere The initial preview release for the app is now available in Google Play, we will be adding more functionality and new features in the coming weeks. If you have any questions about this app or App Service in general be sure to check our forums in MSDN and Stack Overflow. For any feature requests or ideas check out our User Voice In order to use the full capabilities of this application, you need to have an active Microsoft Azure subscription. To learn more about Azure subscriptions, see http://aka.ms/AzureSubscriptions. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2016/10/10/Announcing-Azure-App-Service-Companion-preview.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Streamlined integration of App Service and Application Insights",
+ "excerpt":" Byron Tardif 10/10/2016 9:34:51 AM Application Insights helps you detect and diagnose quality issues in your web apps and services, and enables you to understand what users actually do with them. We believe that Application Insights provides great value to Azure App Service users and that’s why we have made it super easy to enable this for your app from within the Azure portal. The new Application Insights experience can be started form the Application Insights menu item in the monitoring section for any Web, Api or Mobile app. If your app is not already configured to use Application Insights, the UX will allow you to link it to an existing Application Insights resource or create a new one on the fly. Once the Application Insights resource has been created and the link between it and your app is in place, you will start to see data stream into the UX, assuming there is currently traffic on your app. You can get even more data, customize views, queries and a lot more by going to the Application Insights resource blade: You can learn more about Application Insights here If you have any questions about this UX or App Service in general be sure to check our forums in MSDN and Stack Overflow and for any feature requests or ideas check out our User Voice ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2016/10/10/Streamlined-integration-of-App-Service-and-Application-Insights.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Azure Mobile Apps .NET SDK v3.0.2 Released",
+ "excerpt":" Adrian Hall (MSFT) 10/11/2016 1:42:04 PM Today, we released a patch version of the Azure Mobile Apps .NET SDK. If you have already adjusted your clients to use v3.0.1, then this update does not provide any benefit. However, if you are upgrading from v2.x to get support for Android Nougat, you should use v3.0.2. Here are the improvements: (#233, #235, #240) The .NET SDK v3.0.1 required iOS and Android developers to create the offline database file prior to its use. This is no longer a requirement. (#236) The SQLitePCL.Batteries.Init() initialization code was called multiple times. We also suggested that you call it yourself. You no longer have to call it yourself, and it is only called once. (#231, #232) We have updated documentation. The documentation now clarifies our supported platforms, and the HOWTO includes the new instructions for working with offline data. In addition, we've updated the quick start projects that you can download from the Azure portal to use the new SDK. As always, we encourage you to post on Stack Overflow if you are running into problems. If you find a bug or want a feature, please file an issue on our GitHub repository. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2016/10/11/Azure-Mobile-Apps-.NET-SDK-v3.0.2-Released.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Azure Mobile Apps iOS SDK 3.2.0 – Refresh Token, iOS 10Swift 3 Support, and Performance Improvement",
+ "excerpt":" Mimi Xu (Azure) 10/12/2016 8:54:25 AM We are excited to bring you the latest release of our Mobile Apps iOS client SDK 3.2.0 (CocoaPods). There are a few updates in this release: We extended support for Refresh Token for all of our iOS customers. This feature was previously only captured in our Managed SDK 2.1.0 and later versions to enable a smoother development experience around identity provider token expiry. For more information on this feature, see the Refreshing User Logins in App Service Mobile Apps blog post. We added support for the latest iOS environments iOS 10. It also works with Xcode 8.1 and Swift 3. We optimized network performance by reusing NSURLSession objects. This is particularly apparent in long-running async operations like data pulls. (Shout out to Damien Pontifex for his continuous support in helping to improve our iOS SDK through open source contributions). The latest Mobile Apps iOS Quickstart is also available and compatible with this release of the iOS SDK. Try these out and let us know what you think! ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2016/10/12/Azure-Mobile-Apps-iOS-SDK-3.2.0-Refresh-Token,-iOS-10Swift-3-Support,-and-Performance-Improvement.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Azure App Service Companion preview now available for iOS",
+ "excerpt":" Byron Tardif 10/19/2016 9:29:46 AM On October 10 we released the preview for Azure App Service companion to the Google Play Store and today we are expanding the preview to iOS devices as well. As with the Android version of the app the focus is to provide the basic functionality that you need when you are on the go, without requiring you to use your laptop. All in a native experience for your device. Azure App Service Companion allows you to: Monitor your App Service instances View custom alerts based on site status Troubleshoot sites from anywhere If you have any questions about this app or App Service in general be sure to check our forums in MSDN and Stack Overflow. For any feature requests or ideas check out our User Voice In order to use the full capabilities of this application, you need to have an active Microsoft Azure subscription. To learn more about Azure subscriptions, see http://aka.ms/AzureSubscriptions. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2016/10/19/Azure-App-Service-Companion-preview-now-available-for-iOS.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Azure Functions portal and host improvements",
+ "excerpt":" Donna Malayeri 10/26/2016 2:00:59 AM Based on lots of great customer feedback, we've redesigned the Azure Functions portal experience. Now you can see more of your code and see your logs and the Run window at the same time. The Run window has new features for HTTP-triggered functions: you can now specify the HTTP verb and add query parameters and request headers. This makes it easy to test these functions without leaving the Functions portal. Aside from the visual improvements, we've released a lot of great new functionality in the Azure Functions 0.7 host and 0.8 host, including support for custom routes and route templates. Portal You can now view the editor in a classic three-pane view, where your code is at the top, logs are at the bottom, and the Run tab is on the right. You can show and hide the logs and the Run tab to allow more room for editing code. Check out the new buttons on the right (highlighted with a purple rectangle in the screenshot below). Clicking on the Run button will pull up the test harness, which will let you easily craft HTTP calls without having to launch a new tool. Just choose your verb and add query parameters and headers. (Note that we're not trying to reinvent other great HTTP tools like Fiddler or Postman, but we've heard from customers that it's convenient to quickly run HTTP triggered functions without leaving the Azure portal.) HTTP and Webhook triggers now have richer options in the Integrate tab. You can now easily restrict the permitted HTTP verbs by choosing \"Selected methods\" and checking off the appropriate options. API Routing The portal is not the only place we've made changes--the Azure Functions Host is now at version 0.8. By popular request, we've added the following: Custom route support. You can now specify complex route constraints, such as \"route\": \"products/{Category:alpha}/{Id:int}\". The supported constraints are the same as those in ASP.NET Web API Attribute Routing. Route prefix customization. Customize the api route prefix (or remove it completely) in host.json. To learn more, see Route support in the Azure Functions triggers and bindings developer reference. Provide feedback As always, we're interested in your feedback. There are a lot of channels available: Ask questions below! Ask product questions on the Azure Functions MSDN forum and StackOverflow, where you'll get answers directly from the engineering team. Submit general feedback on feedback.azure.com. Reach out to us on Twitter via @Azure with the hashtag #AzureFunctions. Our development is done in the open, so we encourage you to watch issues, ask questions and see our progress. You can submit issues directly on GitHub (Functions Host repo and Functions Portal repo). If you're not sure where an issue belongs, you can file it on the Azure-Functions GitHub repo. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2016/10/26/Azure-Functions-portal-and-host-improvements.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Making Azure Functions more “serverless”",
+ "excerpt":" Chris Anderson (Azure) 11/15/2016 10:00:07 AM One of the principles we believe in most for Azure Functions is that we want you to be solving business and application problems, not infrastructure problems. That’s why we’ve invested so much in the functions runtime (language abstractions, bindings to services, and lightweight programming model) as well as our dynamically scaling, serverless compute model. Given that goal, one thing has always stuck out in our experience: the memory setting you set for each of your Function Apps. The memory setting always felt out of place. Finding the optimal setting required lots of trial and error on the part of our users, and we’ve heard a lot of feedback from users that it’s not something which people want to; that it doesn’t feel very serverless. That is why today, we’re announcing that we’re no longer requiring you to set the memory setting; Azure Functions, in the Consumption Plan, will automatically decide the right resources to have available and only charge you for what you use, not just time but also memory/cpu. How does Azure Functions manage my resources? The Azure Functions platform collects a lot of data about how much utilization and resources your functions take when they execute. This enables us to make very accurate estimations of what you’ll need and distribute the work behind the scenes. The first time you run your Function, we’ll place it in the best a place possible, and should it appear to need more resources, we’ll find and allocate them automatically. We’ll continually be improving our algorithms to make sure that you have the best experience and that we do it as cost effectively as possible on our side. We have confidence that we can do this effectively because we’ve been modeling it with real data for a while now. Below is a graph with the actual numbers redacted, but y-axis is in linear GB-sec, and the base is 0; the x-axis is time. The blue line, on top, is the current amount of billable GB-sec. The red line, on bottom, is the new amount of billable GB-sec in our system. This means, overall, our customers are now paying for 5 times less GB-sec than they were before. Today, users can confidently write Functions without worrying about the right memory setting, knowing they’ll pay the least for their functions. Do I need to rethink how I write my functions? Overall, no, things work pretty much the same as before, with just one less setting to worry about. The same limits that applied before still apply: 1.5GB max memory and a 5-minute max execution time. The biggest impact that this change has is that you now are assured to be getting the right amount of resources and paying the least amount possible for your function executions. How to think about serverless computing To help understand the impact of this change, let’s look at computing through an analogy. Imagine that compute works like shipping. Hosting your compute on prem is like buying a truck and paying the drivers yourself; you’re responsible for the hardware and the operational costs of operating that vehicle and the personnel. Infrastructure as a Service (IaaS - aka VMs) are like renting a truck, but still employing your own drivers; you’re no longer responsible for the hardware, but some operational costs (gas, maintenance, etc.) and the personnel costs still fall on you. Moving further up the hierarchy of compute, you can go with a fully managed Platform as a Service (such as Azure App Service) is like hiring a full-service company who will bring their truck and crew for you; you’re not responsible for the hardware or operational costs. But what if I want to just ship a bunch of small packages? Often it doesn’t make sense to pay by the truck, but rather by the package. This is where serverless computing stands to be transformative for how we build applications. We don’t have to focus on how shipping works because it’s not core to our business; we can focus instead on just getting the product to our customers. Each execution is like a package, and we pay for the size of the box. The change we’re making today, by removing set memory sizes, is made because compute while compute has similarities, it isn’t exactly like shipping physical objects. Knowing how much work is going to come in or what the right amount of compute (CPU/memory/IO) is not as simple as how tall and wide an object is; your resources required can change on each execution or even throughout an execution. Instead, we’ll now trigger your event and find the right size “package” for it, and only charge you for use, both time and resources. The future is even brighter, together We’re committed to building the best serverless compute with the easiest experience and most powerful features. We want to know what we can make smoother. What questions do you have to ask yourself as you build functions? How can we make things easier, faster, better when you’re building your applications? Reach out to us in whatever way you prefer with issues, ideas, or questions: Feedback portal: azure.com GitHub: azure/azure-functions Twitter: #AzureFunctions Stack Overflow: azure-functions tag ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2016/11/15/Making-Azure-Functions-more-serverless.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Use Azure Functions to run WordPress Cron",
+ "excerpt":" mksunitha 11/29/2016 12:32:02 PM Cron is a time-based job scheduler and WordPress uses a file called wp-cron.php as a cron job to run scheduled tasks like publishing scheduled posts, managing updates to plugins and themes etc. WordPress is configured to wp-cron.php every time a user visits your WordPress web app to check if a scheduled task is to be executed. If your web app does get hundreds of users or more simultaneously , this adds significant overhead to your web app slowly it down for the users visiting it. For such cases it would be beneficial to isolate the wp-cron.php execution from the request made to your web app. Azure app service offers Web Jobs or Azure functions to build make a call to wp-cron.php file when it needs to be executed. Advantages of Functions over Web Jobs for your WordPress app Few things to understand about your application before you make the choice : If the cron job is CPU intensive and takes a long time to execute , it may put a large burden on your existing resources on the App service plan causing overhead. In such cases it would be more beneficial to use Azure Functions. Cost is the second criteria . With Azure functions you get 400,000 GB-s execution time for Free which might be sufficient for WordPress app. Even if the execution is higher than 400,000 GB-s , the cost is 0.20 cents for million executions. Functions is still cost effective and it does not add overhead on your web app compute resources. For this blog post I will show you how to use Azure Functions so you can leverage server less architecture and low cost since you pay for the number of times the code is executed due to the event based model. You can use the same sample script for Web jobs if you intend to use the resources on your we app's app service plan. Click here to learn more about Web Jobs. Follow the steps below to isolate wp-cron.php execution for your WordPress web app. STEP 1: Disable WordPress cron Update wp-config.php file and add this setting shown below to disable wp-cron.php from being executed at every user request. define('DISABLE_WP_CRON', 'true'); STEP 2 : Create a Function App using Timer trigger Refer to instructions here to create a Function app or use this sample function app to run WordPress cron on Github . Azure function supports continuous deployment with Github . Traditionally wp-cron.php executes at every request to check if a task is scheduled to run. You can alternatively use the timer triggers which calls the azure functions based on a schedule, one time or recurring. For example if you want the wp-cron.php to run every 15 mins you can use the following schedule which is Unix Cron like expression. \"schedule\": \"0 */15 * * * *\" To learn more about Timer trigger binding , click here. There are two primary files : function.json: This file specified the bindings for the function app. In this case its a timer trigger as seen below which is scheduled to run every 15 minutes. You can view the json file here. { \"bindings\": [ { \"type\": \"timerTrigger\", \"name\": \"timerInfo\", \"direction\": \"in\", \"schedule\": \"0 */15 * * * *\" } ] } run.php : This script just make a HTTP call using PHP CURL and gets a response . Click here to view the script. The logs will display the information of function starting , completing and the response received from the CURL call to wp-cron.php. In this example with the sample function app return a message \"Running WordPress CRON ..\" Note: PHP support is still experiment for Azure Functions. You can use C# or Node.js or F# languages to make a HTTP call to the wordpress app wp-cron.php file , for example the URL would be like http://wordpress3295.azurewebsites.net/wp-cron.php?doing_wp_cron. This will trigger the cron to kickoff any scheduled tasks for WordPress app. References Developer Reference for Azure Functions Best practices for Azure fuctions ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2016/11/29/Use-Azure-Functions-to-run-WordPress-Cron.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Azure Mobile Apps for Apache Cordova reaches GA",
+ "excerpt":" Adrian Hall (MSFT) 11/30/2016 3:00:50 PM Today, we are releasing the Azure Mobile Apps SDK for Apache Cordova as a GA product. This completes the suite of mobile platforms that Azure Mobile Apps supports. You can read more about this release: Tutorials (Getting Started, Authentication, Offline Data Sync, Push Notifications) HOWTO API Documentation The full suite of SDKs for Azure Mobile Apps is: iOS (Objective-C, Swift 2.2, Swift 2.3, Swift 3.0, Xamarin.iOS, Xamarin.Forms, Apache Cordova) Android (Java, Xamarin.Android, Xamarin.Forms, Apache Cordova) Universal Windows (.NET, Xamarin.Forms, Apache Cordova) Windows Phone 8.1 (.NET, Xamarin.Forms, Apache Cordova) You can also integrate the same backend into your web and API applications using the Azure Mobile Apps HTML/JavaScript SDK or by integrating Azure Mobile Apps server-side SDKs into your ASP.NET MVC or Node/Express applications. All the SDKs support similar feature sets: Data Access of SQL data with an OData v3 query structure. Offline Sync of any SQL table exposed via data access. Social authentication with client-side and server-side code to Facebook, Google, Microsoft and Twitter services. Enterprise authentication using client-side and server-side code via Azure Active Directory. Cross-platform push registration to APNS, FCM, WNS and MPNS using Notification Hubs. With this release, we are looking to the future. Some of the things we are looking at right now: Integration with the Visual Studio Mobile Center SDK. Support for React Native. Support for File Sync to Azure Storage. You can find details for our various platforms, including quickstart tutorials, HOWTO documentation and in-depth API documentation: iOS (Swift and Xamarin) Android (Java and Xamarin) Universal Windows Cross-platform C# with Xamarin Forms Cross-platform JavaScript with Apache Cordova As always, please feel free to leave us feedback. We listen on Azure Forums and Stack Overflow. Our SDKs are all open-source, so you can file issues for questions, feature requests and bugs. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2016/11/30/Azure-Mobile-Apps-for-Apache-Cordova-reaches-GA.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "App Service Continuous Delivery Preview",
+ "excerpt":" Byron Tardif 12/1/2016 10:00:09 AM Continuing the partnership between App Service and Visual Studio Team Services, we have a new preview experience for setting up a continuous delivery pipeline to automate the source control, build, test and deployment of your solutions to App Service. The new experience is accessible through the settings menu under App Deployment > Continuous Delivery (Preview) Some of the highlights features include: Ability to host your code in GitHub or Visual Studio Team Services Ability to create, deploy and execute load tests against an independent App Service plan. Deployment directly to deploymetn slots following App Service deployment best practices. You can learn more about App Service Continuous Delivery preview from the announcement in the Visual Studio Application Lifecycle Management blog If you have any questions about this feature or App Service in general be sure to check our forums in MSDN and Stack Overflow. For any feature requests or ideas check out our User Voice ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2016/12/01/App-Service-Continuous-Delivery-Preview.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "New Quickstart experience for App Service Web App",
+ "excerpt":" Byron Tardif 12/1/2016 4:41:39 PM App Service provides you with many options for deploying your code to the cloud. The new Quickstart experience is designed to guide you through the steps to deploy your app using the deployment stack and deployment method of your choice. To get started go to Quickstart under the App Deployment section of the settings menu: Chose the development stack you are interested in: Select a deployment method: and follow the details instructions provided. You can start a different scenario by clicking on “Choose another stack”. If you have any questions about this feature or App Service in general be sure to check our forums in MSDN and Stack Overflow. For any feature requests or ideas check out our User Voice ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2016/12/01/New-Quickstart-experience-for-App-Service-Web-App.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Running Azure Functions Locally with the CLI and VS Code",
+ "excerpt":" Donna Malayeri 12/1/2016 9:00:47 AM Update 5/31: We now have official documentation for the Azure Functions Core Tools and this blog post is now out of date. See Develop and debug Azure functions locally. After our General Availability release of Azure Functions on November 15, lots of customers have been asking how to develop Azure Functions on a local development machine, before pushing working code to Azure. I’m happy to announce that we have some great new functionality to share on this front. You can now use your favorite editor and local development tools and trigger from events in your Azure resources. You can use Visual Studio 2015, Visual Studio Code, or just a command line and any code editor. Visual Studio 2015 Customers who use Visual Studio should check out the preview Azure Functions Tools for Visual Studio 2015. This allows you to create local Functions projects, add new Functions from templates within Visual Studio, run functions locally, and debug C# functions. Get the tools and learn more on the Web Tools team blog. VS Code and azure-functions-cli If you prefer VS Code or want to debug JavaScript functions, you can use the Azure Functions CLI. Note that currently the Azure Functions CLI only works on Windows, but we’re working on support for other platforms. (Note that C# debugging support is currently only available in Visual Studio, not VS Code.) Installing Make sure you’re using Node version 6.x LTS or later (required by the Yeoman dependency), then do: npm i -g azure-functions-cli The Azure Functions CLI is actually the Azure Functions “host” packaged with a command line interface and some other utilities. This is the exact same runtime that’s used in Azure, it’s not an emulator or simulator. It is distributed through npm because it uses Yeoman for scaffolding, but the core functionality is just a .NET 4.6 executable. (That’s why it currently only works on Windows.) Creating a function project When running locally, a function project (the equivalent of a Function App in Azure) is just a directory with the files host.json and appsettings.json. See the product documentation for more about the Azure Functions folder structure. From a command prompt, do the following: mkdir MyAwesomeFunctionProj cd MyAwesomeFunctionProj func init You’ll see the following output: Writing .gitignore Writing host.json Writing appsettings.json Initialized empty Git repository in C:/CDriveCode/MyAwesomeFunctionProj/.git/ Notice the file appsettings.json, which is where you set local environment variables and connection strings (more on this later). Creating a simple function Now, let’s create a simple HTTP triggered Node function via func new I chose HttpTrigger-JavaScript and named it HttpTrigger-JS. Running the function This HTTP triggered function is very simple, it just takes in a “name” argument as either a query parameter or JSON body content, and outputs “Hello name”. To edit the function code, let’s open up VS Code: code . In Visual Studio Code, go to View -> Integrated Terminal func run .\\HttpTrigger-JS\\ -c \"{\\\"name\\\": \\\"Donna\\\"}\" You’ll see that a separate window launches, which is the Functions host. By default, it will listen on http://localhost:7071. In the Functions host window, you’ll see that the URL of HTTP triggers is listed. You can then use a web debugging tool like Fiddler or Postman to create more complex requests. Debugging the function in Visual Studio Code Running a function is great, but debugging is where the magic happens. To run the code and attach the JavaScript debugger, do the following: In a command prompt (either the Integrated Terminal or a regular command prompt), run the function as before and add the --debug flag: func run .\\HttpTrigger-JS\\ -c \"{\\\"name\\\": \\\"Debugging!\\\"}\" --debug Add a breakpoint to index.js. In the Debug tab, select F5 or the play button In the terminal or command prompt, press any character and you’ll see your breakpoint being hit! Running a queue-triggered function Now let’s create a function that triggers from a queue in Azure. First, run func new and select QueueTrigger-JavaScript. Name the function QueueTriggerJS. Setting a connection string Next, we need a value for a storage account connection string. You can either do this by editing appsettings.json manually or by using the Azure Functions CLI. To edit manually: To go Azure Storage Explorer or the Azure Portal and copy your storage connection string Add the value to appsettings.json: { \"IsEncrypted\": false, \"Values\": { \"AzureWebJobsStorage\": \"DefaultEndpointsProtocol=https;AccountName=youraccountname;AccountKey=XXX\" } } Using the Azure Functions CLI: Log in to Azure, then set the active subscription. You can list your Function Apps in Azure and pull down connection strings for a particular app: func azure login func azure account set func azure functionapp list func azure functionapp fetch You’ll see the following output. Settings will be encrypted by default and stored in appsettings.json. Loading AzureWebJobsStorage = ***** Loading AzureWebJobsDashboard = ***** To view settings values on the command line, run: func settings list -a If you want edit the file in an unencrypted form, run: func settings decrypt Editing the Function configuration If you haven’t already, open the Functions directory in Visual Studio Code by running code . Now, edit QueueTriggerJS/function.json and set the value AzureWebJobsStorage for the value for connection. Your function.json will look like the following: { \"disabled\": false, \"bindings\": [ { \"name\": \"myQueueItem\", \"type\": \"queueTrigger\", \"direction\": \"in\", \"queueName\": \"js-queue-items\", \"connection\":\"AzureWebJobsStorage\" } ] } Now it’s time to run the function. There are two ways to trigger it: add new items to a queue named js-queue-items or use the Functions CLI to trigger the function directly. Triggering a function using “func run” To trigger directly, run the following in the Functions CLI: func run .\\QueueTriggerJS\\ --debug -c \"I love this CLI!\" You’ll see the following output: Executing: 'Functions.QueueTriggerJS' - Reason: 'This function was programmatically called via the host APIs.' Function started (Id=c2603348-a0c5-4d7a-b938-5d3e66ed35fd) JavaScript queue trigger function processed work item I love this CLI! Function completed (Success, Id=c2603348-a0c5-4d7a-b938-5d3e66ed35fd) Executed: 'Functions.QueueTriggerJS' (Succeeded) Note: if you this error, it means you haven’t set a value for AzureWebJobsStorage in appsettings.json: Microsoft.Azure.WebJobs.Host: Error indexing method 'Functions.QueueTriggerJS'. Microsoft.Azure.WebJobs.Host: Object reference not set to an instance of an object. Error indexing method 'Functions.QueueTriggerJS'. Now, let’s run and attach a debugger, the same as before: func run .\\QueueTriggerJS --debug -c \"Foo\" Triggering a function with a queue message The cool thing about the local development experience is that you can trigger off of Azure resources directly, rather than just simulating via func run. By default, the Functions CLI will poll for new queue items every minute. For development purposes, it’s helpful to poll more frequently. Add the following to your host.json file, to poll every 2 seconds: { \"queues\": { \"maxPollingInterval\": 2000 } } Launch Azure Storage Explorer and create a queue js-queue-items in storage account you’ve specified in the AzureWebJobsStorage connection string: Then, in Visual Studio Code, we see out breakpoint being hit: This is just a taste of what you can accomplish with the Azure Functions CLI. Try it out today and let us know what you think! Provide feedback The Azure Functions CLI is still in preview and under active development. If you find any issues, please post a GitHub issue and include the title “CLI:”. The CLI is open source and can be found in a branch of the azure-webjobs-script repo. You can also reach out to me on Twitter @lindydonna. For general feedback and questions about Azure Functions: Ask product questions on the Azure Functions MSDN forum and StackOverflow, where you’ll get answers directly from the engineering team. Submit feature requests on feedback.azure.com. Reach out to us on Twitter via @Azure with the hashtag #AzureFunctions. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2016/12/01/Running-Azure-Functions-Locally-with-the-CLI-and-VS-Code.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Update Changes to MySQL support for Azure Imagine Offer",
+ "excerpt":" mksunitha 12/12/2016 10:45:29 AM Imagine program provides special Azure access rights to students that are validated through the Microsoft Imagine program. If you are not enrolled , please enroll here. Azure subscriptions enrolled in this program previously had access to a Free MySQL Database from ClearDB. Moving forward ClearDB FreeDatabase will no longer be supported as part of Imagine program. You can still leverage MySQL from MySQL in-app(Preview) feature. What Imagine offer students get with MySQL in-app(Preview): MySQL in-app gives you an experience of native MySQL running locally alongside the web server. One database for One web app . It is not restricted on App service plan. Storage of 1 GB shared by the your web app's files and database content RAM of 1 GB Phpmyadmin access to manage your database from Azure portal Supports logging for MySQL server logs and Slow query logs. Note these are turned off by default. Here is a FAQ to help answer common question due to this change in service for Imagine program. 1.Can I continue to use, my existing ClearDB Free MySQL database? Yes. You can continue to use your existing ClearDB Free MySQL database. 2. Can I create a new ClearDB MySQL database on my Imgaine program subscription? No you cannot create a new Free ClearDB MySQL database on your Imagine program subscription. You can purchase a new Azure subscription such as Pay-as-you-go etc. to be able to create ClearDB MySQL database 3. How can I export my ClearDB database to MySQL in-app(Preview) database? Check out this article to learn how to export the database and import it in MySQL in-app(Preview) database. 4. How can I access phpmyadmin for MySQL in-app(Preview) database ? In the Azure portal , under your web app settings menu you have an option to manage your MySQL in-app(Preview) settings. To learn more , click here. 5. What applications can I install with MySQL from Azure Web Marketplace? The following application will be available for Imagine program : Web app + MySQL WordPress Joomla Drupal 8 MediaWiki PHP starter site PHPBB (with MYSQL ) You can turn on MySQL in-app(Preview) for your web app and bring your own custom PHP code or CMS solution. References Get started with MySQL in-app (Preview) Importing MySQL database in MySQL in-app(Preview) database Performance benchmarking for MySQL in-app(Preview) database ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2016/12/12/Update-Changes-to-MySQL-support-for-Azure-Imagine-Offer.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Azure Mobile Apps Node.js SDK v4.0",
+ "excerpt":" Adrian Hall (MSFT) 12/19/2016 7:56:48 PM Today, in our final Azure Mobile Apps release of the year, we are releasing a new version of the server-side Azure Mobile Apps Node.js SDK. It's labelled v4.0 because of important breaking changes, but does not introduce any new features. Breaking Changes If dynamic schema was enabled, inserting an item with new columns would also create a deleted column which was unnecessary if the soft delete option was turned off for the table. With v4.0, the deleted column is not created when it is unnecessary. This may affect automated clean-up scripts that don't take into account the soft delete setting on the table. (Issue #504) If an update or delete was performed against soft-deleted records, the server would return a 409 HTTP status code. This was in contrast with the ASP.NET server that returned a 404 HTTP status code. The Node.js SDK has been updated to return a 404 HTTP static code. (Issue #497) Finally, our documentation was out of line with our code with respect to paging options. Previously, the server would place a hard limit on the number of records returned (the pageSize option), despite the maxTop option being higher. The pageSize option now only affects the number of records returned if a $top expression is not provided, and the maximum number of records returned is correctly determined by the maxTop option. (Issue #480) Other Fixes An issue existed whereby a custom API whose access level was set to 'authenticated' would allow unauthenticated requests. This only affected apps where the access level was applied to the entire API and not individual methods within the API and who were also using a custom authentication scheme. Using the App Service Authentication / Authorization mitigated this issue. With the v4.0 release, this issue has been corrected. (Issue #514) User Impact Any user who is using the server via an Azure Mobile Apps client SDK should not be impacted by any of these changes. If you use the server directly through the OData interface, then you should review the changes carefully before upgrading. As always, our team is ready to assist should you have questions. Please contact us through Azure Forums or Stack Overflow. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2016/12/19/Azure-Mobile-Apps-Node.js-SDK-v4.0.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Using Azure App Service Authentication with ASP.NET (Classic) MVC Applications",
+ "excerpt":" Adrian Hall (MSFT) 12/21/2016 11:49:17 AM Azure App Service has a facility called \"Authentication / Authorization\" and it assists primarily with the authentication requirements of Azure Mobile Apps. However, you can also use this in your web applications to abstract away the authentication needs. This makes it easy to integrate Facebook, Google, Microsoft Account, Twitter and Azure AD authentication schemes. This blog post will go through the process of configuring an ASP.NET MVC application to use Azure App Service Authentication. Step 1: Configure Azure App Service Authentication / Authorization You can follow our documentation to configure the actual service: Azure AD Facebook Google Microsoft Twitter Once you have followed the documentation, you should be able to browse to https://yoursite.azurewebsites.net/.auth/login/provider (where provider is one of aad, facebook, google, microsoftaccount or twitter) to ensure it is working. Add Azure Mobile Apps to your ASP.NET MVC application The Azure Mobile Apps .NET Server SDK does a lot of the hard work in handling claims. To configure authentication, first add the Microsoft.Azure.Mobile.Server.Quickstart NuGet package. Then add or create a Startup.cs file with the following: using Microsoft.Owin; using Owin; [assembly: OwinStartup(typeof(Backend.Startup))] namespace Backend { public partial class Startup { public void Configuration(IAppBuilder app) { ConfigureMobileApp(app); } } } Add a suitable App_Start\\Startup.MobileApp.cs file: using System; using System.Collections.Generic; using System.Configuration; using System.Data.Entity; using System.Data.Entity.Migrations; using System.Web.Http; using Backend.DataObjects; using Backend.Models; using Microsoft.Azure.Mobile.Server.Authentication; using Microsoft.Azure.Mobile.Server.Config; using Owin; namespace Backend { public partial class Startup { public static void ConfigureMobileApp(IAppBuilder app) { var config = new HttpConfiguration(); new MobileAppConfiguration() .ApplyTo(config); config.MapHttpAttributeRoutes(); var settings = config.GetMobileAppSettingsProvider().GetMobileAppSettings(); if (string.IsNullOrEmpty(settings.HostName)) { app.UseAppServiceAuthentication(new AppServiceAuthenticationOptions { SigningKey = ConfigurationManager.AppSettings[\"SigningKey\"], ValidAudiences = new[] { ConfigurationManager.AppSettings[\"ValidAudience\"] }, ValidIssuers = new[] { ConfigurationManager.AppSettings[\"ValidIssuer\"] }, TokenHandler = config.GetAppServiceTokenHandler() }); } app.UseWebApi(config); } } } Finally, add the following to your Web.config file: <appSettings> <add key=\"webpages:Enabled\" value=\"false\" /> <add key=\"PreserveLoginUrl\" value=\"true\" /> <add key=\"MS_SigningKey\" value=\"Overridden by portal settings\" /> <add key=\"EMA_RuntimeUrl\" value=\"Overridden by portal settings\" /> <add key=\"MS_NotificationHubName\" value=\"Overridden by portal settings\" /> <add key=\"SigningKey\" value=\"Overridden by portal settings\" /> <add key=\"ValidAudience\" value=\"https://chapter6.azurewebsites.net/\" /> <add key=\"ValidIssuer\" value=\"https://chapter6.azurewebsites.net/\" /> </appSettings> <system.web> <compilation debug=\"true\" targetFramework=\"4.5.2\"/> <httpRuntime targetFramework=\"4.5.2\"/> <authentication mode=\"Forms\"> <forms loginUrl=\"/.auth/login/aad\" timeout=\"2880\"/> </authentication> </system.web> Some parts of this will already be available to you. Make sure the loginUrl in the authentication section matches the provider login URL for the provider that you configured. You should now be able to attach the [Authorize] attribute to any controller to enable the redirect to the authentication system. The authentication will happen and then the user will be prompted to \"return to the website\". Once the link is clicked, the user will be redirected back to your application with authentication. Your application can use any of the claims available through the /.auth/me endpoint of your application. They are available in the httpContext.User.Identity.Claims object. Dealing with Anti-Forgery Tokens One thing that will break is anti-forgery tokens. This is because Azure App Service Authentication does not provide the appropriate identityprovider claim that anti-forgery tokens use for configuration. You have to explicitly set a claim to use. This can be done anywhere in the application start. I place mine in the MVC RegisterRoutes() method in App_Start\\RouteConfig.cs. Add the following line: AntiForgeryConfig.UniqueClaimTypeIdentifier = ClaimTypes.NameIdentifier; ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2016/12/21/Using-Azure-App-Service-Authentication-with-ASP.NET-(Classic)-MVC-Applications.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Azure Functions preview versioning update",
+ "excerpt":" Chris Anderson (Azure) 1/3/2017 11:45:39 AM Azure Functions deprecating preview versions With Azure Functions recently becoming generally available and making the 1.0 Azure Functions host available, we are now announcing that preview versions of the Azure Functions host (0.x) are deprecated and we're preparing to begin removal of these versions beginning February 1st, 2017. All Azure Functions users should upgrade their version setting to ~1. If you are using preview features, such as PowerShell or F# support, there are additional things to consider around how we will manage versions in 1.x versions. Deprecation of preview (0.x) versions of Azure Functions host All preview (0.x) versions of the Azure Functions host are now deprecated. We will be begin removing those versions from the available feed of versions starting February 1st, 2017. Since we've released 1.0, we've been monitoring which versions users are actively using and are happy with the adoption rate of our latest version. We will start by removing the earliest versions, which have the fewest users still active. If you still haven't upgraded to ~1, we strongly recommend that you upgrade as soon as possible. Any non-security related issues related to these versions, including the runtime, portal, templates, or docs, will generally be closed. Support cases for users still using preview versions of the host will be directed to first upgrade to the latest version of the host. We encourage you to ask any questions you might have about any issues you experience while upgrading, either via Azure Support or via the forums and Stack Overflow. If you have any critical need to keep a preview version around past February 1st, 2017, please reach out to chrande@microsoft.com. Versioning for preview features in 1.x Previously, before 1.0, we would introduce breaking changes every minor version. Now that we've introduced 1.0, all \"released\" features, such as JavaScript and C# language support, will not have any breaking changes for all ~1 versions. If you don't plan on using preview features, you don't need to worry about any version updates until we have another major version update. Preview features, such as PowerShell and F# language support, will continue to potentially incur breaking changes between minor versions. We recommend that if you're using preview features, you continue to set your minor version explicitly (i.e. ~1.0), rather than just the major version(~1). Additionally, we will not be supporting every 1.x version for the lifetime of 1.x. We will deprecate some ~1 minor versions over time. Later this month, we will provide a tentative schedule for how that will work, as well as some additional means for folks using preview features to provide us feedback. We'll also be building some special portal experiences which will make version management even easier for those of you using preview features. We also really want to thank each and every one of you who gave us a try during our preview and those of you who will continue to use preview features now that we've released 1.0. It means a lot to us and we wouldn't be successful without it. We hope you have as much fun using our preview features as we do making them. FAQ When will version \"0.x\" (0.5, 0.6, etc.) be removed? It will be removed sometime after February 1st, 2017. What if the preview version I'm using is removed before I perform the upgrade? Azure Functions will use a newer version automatically. If your Functions are impacted by any breaking changes between host versions, you may experience issues, including downtime that does not count against your SLA, since it is user controlled. How do I know if I need to upgrade? If your FUNCTIONS_EXTENSION_VERSION application setting is set not set to a ~1 version (i.e. it is set to 0.9), you need to upgrade. Our portal will provide warning on the top of the screen if it detects you're behind the latest version. How do I upgrade? The easiest way to upgrade is to open the Azure Functions portal and click on the upgrade notice. You can also go to your Function App Settings menu and click on the upgrade version next to where it displays your current version. You can also directly set your Application Setting via the portal, any Azure CLI, or the Azure Resource Management APIs. If I'm using ~1 today, do I need to worry? As long as you're not using any preview features (like PowerShell or F# language support), you can rest easy. If you're using preview features, you'll want to manage your minor versions directly. Keep an eye out for some more information on this early next year. What's the difference between ~1 and ~1.0 for the FUNCTIONS_EXTENSION_VERSION application setting? When we resolve which Functions host to start up for you, we use the FUNCTIONS_EXTENSION_VERSION application setting to choose the best version for you. If you set your setting to ~1, you'll use the latest version of the host with major version of 1. If you set your setting to ~1.0, you'll only receive patch updates to 1.1. We'll update the minor version every time we have a new version of the host which has breaking changes for preview features. If I desperately need to stay on a preview version, is there an option for me? We believe that upgrading to ~1 is the best thing for everyone, but we can work with you to help you upgrade, if you reach out to us. If you're committed to staying on a preview version, we don't offer any official support for this, but you can deploy your own functions extension on App Service plans (not supported on Consumption plans). Is there a way for me to know if I'll be impacted by a change? The best way to get an idea of the impact is to read the release notes for any versions between your current version and the targeted upgrade version. How do I revert to another version (just in case)? In your app settings in the Functions portal, you'll find a setting for the runtime FUNCTIONS_EXTENSION_VERSION. You can change this to any version, including a previous version. You can learn more about this here. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/01/03/Azure-Functions-preview-versioning-update.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Azure Mobile Apps .NET SDK Releases",
+ "excerpt":" Adrian Hall (MSFT) 1/10/2017 5:03:53 PM Today, we are releasing two new .NET SDK releases - v2.0.0 on the server side and v3.1.0 on the client side. The NuGet packages are available from the main NuGet repository and the symbols have been updated on symbolsource. Azure Mobile Apps ASP.NET Server SDK v2.0.0 It's been a while since we updated the ASP.NET Server SDK. We've updated the base framework that we use to .NET Framework 4.6 and updated all the dependencies so that we are using the latest versions that we can while maintaining compatibility as a protocol level. In addition, we have deprecated the Azure Notification Hubs push registration endpoint. This is still included in the package, but marked as Obsolete and will be removed in a future version. You should use the App Service Push endpoint instead. In your ASP.NET Owin Startup class, you can remove the reference to .AddPushNotifications() from the configuration. App Service Push has been significantly enhanced over the last couple of months. It now supports white-listing of tags and automatic addition of tags based on authenticated claims available from the authentication provider. This lays the groundwork for re-introducing tag support into the client SDKs in a future release. In the interim, you can build your own Notification Hub Installation class and submit that via the .InvokeApiAsync() method. For examples on this, check out Chapter 5 of my Azure Mobile Apps book. We are also releasing the Swagger and Custom Authentication packages as generally available. You can read about the Swagger customization on our Wiki. Finally, we've also been working behind the scenes on updating the Azure Storage SDK, updating our testing and build processes so that those are more aptly done in the public, publishing more topics to our Wiki and adding information to our documentation. Azure Mobile Apps Client SDK v3.1.0 The Client SDK has had the following updates since the last update: (#266) A bug that caused problems when two libraries both used SQLite. This was fixed by updating the dependency on the SQLitePCL.raw to the latest version. Thanks to Eric Sink for the fast turnaround on the fix for this, and for providing an awesome open source project that we can leverage here. (#215) We were inconsistent in the generation of GUID style primary keys between the client and server. We've standardized the production of keys to a hyphen-less version. (#196) We had a method for querying the underlying SQLite store that was not exposed. Sometimes, it's good to do queries against the raw tables stored in SQLite. We now expose the SQLiteStore.ExecuteQueryAsync() method that does the appropriate locking to ensure the operation is safe. We've also done numerous documentation updates and will be updating the SDK documentation on the MSDN site soon. As always, you can ask questions on both of these SDKs on Stack Overflow or Azure Forums, or file questions and issues at the GitHub repositories (Server and Client). Read the Book On the \"more documentation\" front, I've been hard at work writing the Azure Mobile Apps book for C#, covering the ASP.NET server and Xamarin cross-platform development. It is nearing completion and all the \"development\" topics have been completed. You can find the book at http://aka.ms/zumobook. I would appreciate your feedback on the topics, especially where information is missing. You can file issues at the GitHub repository. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/01/10/Azure-Mobile-Apps-.NET-SDK-Releases.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Notification Hubs Java SDK Improvements - Direct Send, Cancel Scheduled Pushes, Get Telemetry",
+ "excerpt":" Mimi Xu (Azure) 1/18/2017 10:11:01 AM We are excited to share some of the recent updates the Notification Hubs team has made to its Java Server SDK. We have added a cancelScheduledNotification API that lets you delete scheduled notifications provided the scheduled notification ID. We have added sendDirectNotification that can directly push any type of notifications (APNS, GCM, WNS, etc) to a list of device tokens without any device registrations needed with Notification Hubs service. Lastly, getNotificationTelemetry is enabled for customers to easily see telemetry details around each send request. You will need the following dependencies with the correct versions: Apache HttpClient Mime 4.5.2 Apache HttpCore 4.4.5 Give them a try and let us know what you think! ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/01/18/Notification-Hubs-Java-SDK-Improvements-Direct-Send,-Cancel-Scheduled-Pushes,-Get-Telemetry.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Parse Server on Azure App Service Updated",
+ "excerpt":" Adrian Hall (MSFT) 1/18/2017 5:19:01 PM The open-source Parse Server project has moved on since we first published the Marketplace resource for running your own version of Parse Server on Azure App Service. The Azure version of Parse Server uses all Azure resources - DocumentDb, Storage, Notification Hubs and App Service. Recently, Parse Server got updated to v2.3.0. If you wish to deploy a new Parse Server and use the new v2.3.0 codebase, then you can simply deploy the Marketplace resource. In the Azure Portal, click on the + NEW resource. Use the search box to search for Parse Server and create the Parse Server on managed Azure services resource. All the relevant resources will be created for you. This allows you to get up and running quickly. If you have an existing Parse Server running with managed Azure services, you will need to upgrade your server rather than deploy a new server. To do this: Click Resource Groups and find the resource group containing your parse server resources. Click the App Service that has the same name as your parse server. Click the Application settings node in the menu. Add the following App Settings: WEBSITE_NODE_DEFAULT_VERSION = 4.4.0 WEBSITE_NPM_DEFAULT_VERSION = 3.8.3 You can set these values by scrolling to the App settings section and filling in the key/value fields appropriately, then press Enter. Click Console to open a management console. Type the following: npm install -s buffer-shims npm install -s parse-server@2.3.x Restart your App Service. This will install the latest 2.3.x release of parse-server (currently 2.3.2). If you notice any red text in the console, then an error has occurred. You should analyze the error message. Please report any problems through Azure Forums or Stack Overflow. Upgrading your Parse Server is identical to upgrading any other server code - try it on a non-production service first and ensure all your client-server communications still work properly. Things change between Parse Server versions. You should reach out to the Parse Server project directly if you are experiencing problems in your code. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/01/18/Parse-Server-on-Azure-App-Service-Updated.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Preview API Apps Deprecation",
+ "excerpt":" Alex Karcher 1/18/2017 10:46:13 AM Affected Product: Azure Preview API Apps (v1) Deprecation Date: January 18th, 2017 Removal Date: March 14th, 2017 Mitigation: Redeploy workload to App Service API Apps (v2) Today we are announcing the deprecation of Preview API Apps, referred to as v1 API Apps for this article. v1 API Apps are deprecated immediately and will be removed from Azure on March 14th. App Service API Apps, referred to as v2 API Apps for this article, are a GA product and still under active development. Redeploy all v1 API App workloads to v2 API Apps by March 14th to avoid a service interruption. We are excited at the growth we have seen since upgrading v1 API Apps to the App Service infrastructure and announcing general availability of v2 API Apps over a year and a half ago. Read the original announcement for all the improvements introduced in v2 API Apps. Logic App Impact Logic Apps had moved away from using the preview API Apps v1 based connectors almost 1 year ago and has since become generally available with over 100 managed connectors. Please migrate your preview Logic Apps to our GA schema and discontinue use of the preview API APP v1 based connectors, as those connectors will be removed on March 14th, 2017. API Gateway API Gateway resources are also deprecated and will also be removed following the API App removal timeline. API Gateway resources are created in each resource group that contains a v1 API App and have the resource type \"Gateway\" in the portal. Identifying Preview API Apps (v1) v1 API Apps are only visible in the \"All Resources\" page of the Azure Portal, and on the page of the resource group they belong to. They are not visible in the \"App Services\" page of the Azure Portal by design. v1 API Apps have the App Type \"API App\" and the Resource Type \"Microsoft.AppService/apiapps\" in the Azure portal Opening the App settings blade on a v1 API App will show an upgrade notice as well. Identifying App Service API Apps (v2) v2 API Apps have the App Type \"App Service\" and the Resource Type \"Microsoft.Web/sites\" in the Azure portal, and are still under active support and development. Upgrading Preview API Apps (v1) Follow this guide to redeploy your v1 API App workload to a v2 API App. Upgrading Logic Apps v1 Connectors Use the GA release of Logic Apps with equivalent managed connectors in place of the v1 preview Connectors. To check that you are no longer consuming a v1 connector, stop all of your v1 API Apps from the portal and check that your logic apps run successfully. All v1 connectors will be classified as preview API Apps in the portal, shown above. Preview (v1) API App Not Accessible in Portal The portal experience for some v1 API Apps and connectors may be unavailable. We recommend you use Azure Resource Explorer or the Azure Resource Manager REST APIs directly to manage these v1 API Apps. In the Azure Resource Explorer navigate to your subscription, then your resource group. Note that your v1 sites will have both a core site, under Microsoft.AppService, as well as a container site under Microsoft.Web > Sites. The core site contains your business logic, and the container contains your Azure configuration, such as deployment slots and networking settings. Deprecation Timeline March 14th: v1 API Apps stop running on Azure March 28th: v1 API App data deleted from Azure Additional Support If you have any issues moving to v2 API Apps please check our MSDN forums, or contact support directly ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/01/18/Preview-API-Apps-Deprecation.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Azure Mobile Apps iOS SDK v3.3.0 Released",
+ "excerpt":" Adrian Hall (MSFT) 1/19/2017 3:19:29 PM Today we are releasing the Azure Mobile Apps iOS SDK to CocoaPods and other online properties. This is a drop-in replacement for the existing SDK. We only have one feature fix in this release. We updated the authentication code to support the SFSafariViewController. This release affects you if you use Google Authentication and a server-flow. If your code looks like this (Objective-C): [client loginWithProvider:@\"google\" controller:self animated:YES completion:^(MSUser *user, NSError *error) { [self refresh]; }]; Or the Swift equivalent: client.loginWithProvider(\"google\", controller: self, animated: true) { (user, error) in self.refreshControl?.beginRefreshing() self.onRefresh(self.refreshControl) } Then you are affected by this change. Late last year, Google made changes to their OAuth authentication scheme. The net effect was that a mobile client could no longer use a WebView to deliver the authentication flow to the user. A secure web flow would be needed. The supported method on iOS is the SFSafariViewController and this release changes the underlying web view capabilities for authentication to this new mechanism. This wasn't just a client-side code change. It involved changing the server-side authentication code worldwide in Azure App Service. As with any release, we have done numerous small changes to make the experience for the developer better, particularly as it pertains to warnings that are delivered during the development process. We are also in the process of moving all our examples to Swift 3.0. The new SDK fully supports Swift 3.0 and XCode 8.2. We will be deprecating the support for Swift 2.x in the next release. Although we support XCode 7.0 for Objective-C usage, you will need XCode 8.2 for Swift support. You can download the SDK from Cocoapods, take a look at the API directly or reference our tutorials and HOWTO documentation. We're also active on Azure Forums and Stack Overflow. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/01/19/Azure-Mobile-Apps-iOS-SDK-v3.3.0-Released.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Revisiting Windows Azure Pack Web Sites V2 Support Lifecycle Dates",
+ "excerpt":" Andrew Westgarth 1/19/2017 10:00:00 AM Windows Azure Pack Web Sites V2 is an on-premises, high density, multi-tenant web hosting for service providers and enterprise IT and provides an experience similar to the predecessor to Azure App Service, Azure Web Sites. The product is deployed on top of Windows Server 2012 R2 and is an optional add-on to Windows Azure Pack. With the release of Windows Server 2016, the Windows Azure Pack team amended the support lifecycle to reflect that Windows Azure Pack V2 from Update Rollup 11 is supported on Windows Server 2016, however this is not the case for Windows Azure Pack Web Sites. Windows Azure Pack Web Sites is only supported on Windows Server 2012 R2 and is subject to the same support lifecycle dates that were previously published for Windows Azure Pack running on Windows Server 2012 R2. We understand this is causing some confusion and concern amongst customers so this blog post is intended to clarify the position for users of Windows Azure Pack Web Sites. Windows Azure Pack Web Sites v2 Mainstream support ends on 11th July 2017 Windows Azure Pack Web Sites has a direct dependency on Windows Server 2012 R2 and as such will adhere to the following support lifecycle dates: Lifecycle Start date 14th January 2014 Mainstream Support End Date 11th July 2017 Extended Support End Date 12th July 2022 Guidance on what is covered under Extended Support can be found at https://support.microsoft.com/en-us/help/17140/general-lifecycle-policy-questions But Windows Azure Pack can be deployed on Windows Server 2016, what about Web Sites? Windows Azure Pack Web Sites does not support deployment on top of Windows Server 2016. Windows Azure Pack can be deployed on Windows Server 2012 R2 and with Update Rollup 11 can be deployed on Windows Server 2016 but Windows Azure Pack Web Sites is ONLY supported on Windows Server 2012 R2. What about Updates? Update Rollups for Windows Azure Pack Web Sites will continue to be published until July 2017, after that date no regular updates will be published. Questions? If you have any questions or feedback around this clarification and Windows Azure Pack Web Sites please add them to the comments on this post and I will respond. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/01/19/Revisiting-Windows-Azure-Pack-Web-Sites-V2-Support-Lifecycle-Dates.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "ClearDB maintenance for Mercury databases on Microsoft Azure",
+ "excerpt":" mksunitha 1/25/2017 9:01:25 AM We are conducting an assessment on ClearDB MySQL databases associated with Azure customers. We have found several instances where subscriptions are deployed in ClearDB but have no corresponding Azure account associated with them. To synchronize the ClearDB and Azure services, any MySQL database that does not have a valid Azure account will be frozen on January 25. This may impact some Azure users. If your account is frozen and you wish to sustain the ClearDB MySQL database services from Azure, please take the following steps: Provision a new, empty ClearDB database in Azure to restore your data into. Once created, please open a Support ticket with Azure Support or ClearDB support with the following infromation: The database name that was newly created with Azure subscription ID Old database name , ClearDB database hostname and the associated Azure subscription ID Our support teams will work will provide you a back up of your database. Please import the database content using MySQL workbench into the newly created database . The reason behind these steps being taken is due to inconsistency in purchase order records for these databases and their subscriptions. The steps above will help resolve this. We apologize for any inconvenience you have incurred. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/01/25/ClearDB-maintenance-for-Mercury-databases-on-Microsoft-Azure.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "App Service Companion for iOS update",
+ "excerpt":" Byron Tardif 2/22/2017 10:43:11 AM We have just released an update for our App Service Companion app for iOS Some of the key new features include: \t Ability to “favorite” apps for quick access New grouping option in the app list to quickly navigate through large app collections. Support for Push notifications for recomendations New native UI built specially for iOS If you have already installed App Service Companion you should soon see the update from the App Store or you can click on the banners below to install it now for your respective platform Favorites & Application Grouping The application list lets you view all apps or a filtered view of just your favorites. You can add or remove items to the favorite list by swiping left in the application list or from the app actions menu. You can now group applications in the app list by: \t Subscription Resource Group Region App type App actions and Metrics Application actions are grouped under the action menu, application actions include: \t Start Stop Restart Browse Favorite Metrics graphs under the app’s monitoring view now let you select different time grains to get a better view of your app’s activity \t 1 hour 1 day 1 week If you have any questions about this app or App Service in general be sure to check our forums in MSDN and Stack Overflow. For any feature requests or ideas check out our User Voice ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/02/22/App-Service-Companion-for-iOS-update.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Azure Functions Proxies public preview",
+ "excerpt":" Matthew Henderson - MSFT 2/22/2017 9:00:13 AM Since we first released Azure Functions, we've seen a lot of customers using the service to build APIs. Functions is a fantastic way to quickly express an action, and the consumption plan is a great billing model for many types of applications. However, we've also heard that dealing with multiple functions could be easier. It's often difficult to manage large solutions within a single function app. There are also quite a few customers that want to use microservices architectures, with deployment isolation between individual components. Splitting the work into multiple function apps works for most triggers, but it's a bit trickier for APIs. Each function app has its own hostname, so there can be many hosts to keep track of, without a unified API surface. This can make things difficult for client applications, especially when the client needs to switch between environments for testing. Today, we are pleased to announce the public preview of Azure Functions Proxies, a new capability that makes it easier to develop APIs using Azure Functions. Proxies lets you define a single API surface for multiple function apps. Any function app can now define an endpoint that serves as a reverse proxy to another API, be that another function app, an API app, or anything else. You can learn more about Azure Functions Proxies by going to our documentation page. The feature is free while in preview, but standard Functions billing applies to proxy executions. See the Azure Functions pricing page for more information. Creating your first proxy To create a proxy, head to any function app. In the left-hand navigation, you should now see a Proxies section. Select \"New proxy\" to get started. You will need to provide a name for the proxy, the endpoint you wish to expose, and the backend endpoint that will serve the request. Proxies exist as peers to functions in a function app. They are configured just like HTTP-triggered functions, and from a client perspective, they look the same. However, the proxy behavior is independently enabled and versioned. If this is the first proxy you've created for a function app, you will need to enable the feature in function app settings. Getting in touch with the team Please give Azure Functions Proxies a try and let us know what you think! We have some additional capabilities planned for this scenario, but as always, we'd love to hear what matters most to you. If you run into any problems, let us know on the forums, ask a question on StackOverFlow, or file an issue on GitHub. If you have any additional features you would like to see, please let us know on Uservoice. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/02/22/Azure-Functions-Proxies-public-preview.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Announcing Azure Functions support for Serverless Framework",
+ "excerpt":" Chris Anderson (Azure) 2/23/2017 8:00:44 AM Today we’ve officially announced preview support for the Azure Functions Serverless Framework plugin. The Serverless Framework is an open source tool which allows you to deploy auto-scaling, pay-per-execution, event-driven functions to any cloud. It helps abstract away the details of your Serverless resources and lets you focus on the important part – your application. With the release of our new plugin, it’s one of the fastest ways to deploy a serverless application, ever. You can learn more about the plugin in the Azure Functions Serverless Framework documentation. You can also check out our npm package serverless-azure-functions. Getting started Now let’s see a quick hello world example 1. Set up boilerplate To setup the boilerplate, follow these instructions: Recommend using Node v6.5.0 Install the serverless tooling - npm i -g serverless Create boilerplate (change my-app to whatever you'd prefer) -serverless install --url https://github.com/azure/boilerplate-azurefunctions --name my-app cd my-app npm install 2. Set up credentials We'll set up an Azure Subscription and our service principal. You can learn more in the credentials doc. Set up an Azure SubscriptionSign up for a free account @ https://azure.com. Azure comes with a free trial that includes $200 of free credit. . Get the Azure CLI npm i -g azure-cli Login to Azure azure login This will give you a code and prompt you to visit aka.ms/devicelogin. Provide the code and then login with your Azure identity (this may happen automatically if you're already logged in). You'll then be able to access your account via the CLI. Get your subcription and tenant id azure account show Save the subcription and tenant id for later Create a service principal for a given <name> and <password> and add contributor role. azure ad sp create -n <name> -p <password> This should return an object which has the servicePrincipalNames property on it and an ObjectId. Save the Object Id and one of the names in the array and the password you provided for later. If you need to look up your service principal later, you can use azure ad sp -c <name> where <name> is the name provided originally. Note that the <name> you provided is not the name you'll provide later, it is a name in the servicePrincipalNames array. Then grant the SP contributor access with the ObjectId azure role assignment create --objectId <objectIDFromCreateStep> -o Contributor Set up environment variablesYou need to set up environment variables for your subscription id, tenant id, service principal name, and password. # bash export azureSubId='<subscriptionId>' export azureServicePrincipalTenantId='<tenantId>' export azureServicePrincipalClientId='<servicePrincipalName>' export azureServicePrincipalPassword='<password>' # PowerShell $env:azureSubId='<subscriptionId>' $env:azureServicePrincipalTenantId='<tenantId>' $env:azureServicePrincipalClientId='<servicePrincipalName>' $env:azureServicePrincipalPassword='<password>' 3. Deploy to Azure Run the deploy command serverless deploy 4. Test Run the invoke command serverless invoke function -f httpjs ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/02/23/Announcing-Azure-Functions-support-for-Serverless-Framework.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Making your APIs available to PowerApps and Microsoft Flow",
+ "excerpt":" Matthew Henderson - MSFT 2/23/2017 8:00:36 AM Azure App Service and Azure Functions are both commonly used for building organizational APIs. These might include important business logic needed by many apps and activities. Traditionally, most of these clients are written by professional developers, but Microsoft also offers solutions that enable anyone in an organization to build solutions. PowerApps and Microsoft Flow are services that enable power users within an organization to get more done. Without writing any code, users can easily create apps and custom automated workflows that interact with a variety of enterprise data and services. While they can leverage a wide variety of built-in SaaS integrations, users often find the need to incorporate company-specific business logic. We've now extended the API Definition feature of App Service and Azure Functions to include an \"Export to PowerApps and Microsoft Flow\" gesture. This walks you through all the steps needed to make any API in App Service or Azure Functions available to PowerApps and Microsoft Flow users. To learn more, see our documentation. We're hoping to make this experience even easier over time. Please let us know what you think in the Forums (App Service, Functions) or UserVoice (App Service, Functions). ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/02/23/Making-your-APIs-available-to-PowerApps-and-Microsoft-Flow.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Creating a local PFX copy of App Service Certificate",
+ "excerpt":" akurmi 2/24/2017 3:04:03 PM Introduction Last year, we introduced ‘App Service Certificate’, a certificate lifecycle management offering. Azure portal provides a user-friendly experience for creating App Service Certificates and using them with App Service Apps. You can read more about this service here. While the portal provides first class experience for deploying App Service Certificate through Key Vault to App Service Apps, we have been receiving customer requests where they would like to use these certificates outside of App Service platform, say with Azure Virtual Machines. In this blogpost, I am going to describe how to create a local PFX copy of App Service Certificate so that you can use it anywhere you want. Prerequisites Before making a local copy, make sure that: 1. The App Service Certificate is in ‘Issued’ state 2. It’s assigned to a Key Vault (Step 1 in the link shared above). Creating a local copy of the issued SSL certificate using PowerShell You can use the following PowerShell script to create a local PFX copy. You need to first install Azure PowerShell and have the required modules installed. Follow this blog to install the Azure PowerShell commandlets. To use the script, open a PowerShell window, copy the entire script below (uncomment Remove-AzKeyVaultAccessPolicy line if you want to remove Access policies after export, check your permissions to see if you want to remove the policy) and paste it on the PowerShell window and hit enter. Function Export-AppServiceCertificate { ########################################################### Param( [Parameter(Mandatory=$true,Position=1,HelpMessage=\"ARM Login Url\")] [string]$loginId, [Parameter(Mandatory=$true,HelpMessage=\"Subscription Id\")] [string]$subscriptionId, [Parameter(Mandatory=$true,HelpMessage=\"Resource Group Name\")] [string]$resourceGroupName, [Parameter(Mandatory=$true,HelpMessage=\"Name of the App Service Certificate Resource\")] [string]$name ) ########################################################### Connect-AzAccount Set-AzContext -Subscription $subscriptionId ## Get the KeyVault Resource Url and KeyVault Secret Name were the certificate is stored $ascResource= Get-AzResource -ResourceId \"/subscriptions/$subscriptionId/resourceGroups/$resourceGroupName/providers/Microsoft.CertificateRegistration/certificateOrders/$name\" $certProps = Get-Member -InputObject $ascResource.Properties.certificates[0] -MemberType NoteProperty $certificateName = $certProps[0].Name $keyVaultId = $ascResource.Properties.certificates[0].$certificateName.KeyVaultId $keyVaultSecretName = $ascResource.Properties.certificates[0].$certificateName.KeyVaultSecretName ## Split the resource URL of KeyVault and get KeyVaultName and KeyVaultResourceGroupName $keyVaultIdParts = $keyVaultId.Split(\"/\") $keyVaultName = $keyVaultIdParts[$keyVaultIdParts.Length - 1] $keyVaultResourceGroupName = $keyVaultIdParts[$keyVaultIdParts.Length - 5] ## --- !! NOTE !! ---- ## Only users who can set the access policy and has the the right RBAC permissions can set the access policy on KeyVault, if the command fails contact the owner of the KeyVault Set-AzKeyVaultAccessPolicy -ResourceGroupName $keyVaultResourceGroupName -VaultName $keyVaultName -UserPrincipalName $loginId -PermissionsToSecrets get Write-Host \"Get Secret Access to account $loginId has been granted from the KeyVault, please check and remove the policy after exporting the certificate\" ## Getting the secret from the KeyVault $secret = Get-AzKeyVaultSecret -VaultName $keyVaultName -Name $keyVaultSecretName -AsPlainText $pfxCertObject= New-Object System.Security.Cryptography.X509Certificates.X509Certificate2 -ArgumentList @([Convert]::FromBase64String($secret),\"\",[System.Security.Cryptography.X509Certificates.X509KeyStorageFlags]::Exportable) $pfxPassword = -join ((65..90) + (97..122) + (48..57) | Get-Random -Count 50 | % {[char]$_}) $currentDirectory = (Get-Location -PSProvider FileSystem).ProviderPath [Environment]::CurrentDirectory = (Get-Location -PSProvider FileSystem).ProviderPath [io.file]::WriteAllBytes(\".\\appservicecertificate.pfx\",$pfxCertObject.Export([System.Security.Cryptography.X509Certificates.X509ContentType]::Pkcs12,$pfxPassword)) ## --- !! NOTE !! ---- ## Remove the Access Policy required for exporting the certificate once you have exported the certificate to prevent giving the account prolonged access to the KeyVault ## The account will be completely removed from KeyVault access policy and will prevent to account from accessing any keys/secrets/certificates on the KeyVault, ## Run the following command if you are sure that the account is not used for any other access on the KeyVault or login to the portal and change the access policy accordingly. # Remove-AzKeyVaultAccessPolicy -ResourceGroupName $keyVaultResourceGroupName -VaultName $keyVaultName -UserPrincipalName $loginId # Write-Host \"Access to account $loginId has been removed from the KeyVault\" # Print the password for the exported certificate Write-Host \"Created an App Service Certificate copy at: $currentDirectory\\appservicecertificate.pfx\" Write-Warning \"For security reasons, do not store the PFX password. Use it directly from the console as required.\" Write-Host \"PFX password: $pfxPassword\" } Now you will have a new command called Export-AppServiceCertificate, use the command as follows Export-AppServiceCertificate -loginId yourarmemail@domain.com -subscriptionId yoursubid -resourceGroupName resourceGroupNameOfYourAppServiceCertificate -name appServiceCertificateName Once the command is executed, you would see a new file in the current directory called ‘appservicecertificate.pfx’. This is a password protected PFX, the PowerShell console would display the corresponding password. For security reasons, do not store this password in a text file. You can use the password directly from the console as required. Also, don’t forget to delete the local PFX file once you no longer need it. Exporting the certificate with the chain included for App Service Web App consumption. The pfx created by the above commands will not include certificates from the chain. Services like Azure App Services expect the certificates that are being uploaded to have all the certificates in the chain included as part of the pfx file. To get the certificates of the chain to be part of the pfx, you will need to install the exported certificate on your machine first using the password that is provided by the script, make sure you mark the certificate as exportable. Once you have installed the exported certificate open the certificate from your certificate store and navigate to the Certification Path tab, it would look something like below, Now go to https://certs.godaddy.com/repository and download the intermediate certificates and the root certificate. Install all of the certificates downloaded to the same store as your certificate. Once you confirmed that all the certificates in the chain have been installed we can export the certificate with the chain by going to the certificate store, right clicking on the SSL certificate we exported and installed and clicking of All Tasks -> Export ... In the wizard, make sure you select the option, \"Yes, export the private key\" And then under the Personal Information Exchange property, make sure the option \"Include all certificates in the certification path if possible\" is checked. Once exported into a new pfx file we can check if the new pfx has the certificate chain included in it by running the command, certutil -dump <path of the certificate file> You will see the list of the certificates that are part of the pfx from the root to your certificate. A pfx file created with the above steps with all the certificates of the chain contained is well formed and can be uploaded to App Service Web Apps with confidence. Note the CA part of the uploaded pfx file will be discarded when we process the uploaded certificate, we store all the intermediate certificates associated with the certificate to enable the chain to be remade properly in the runtime. Once all the export operation is complete and you have successfully uploaded your certificate clean your machine of any trace of the SSL certificate by deleting the certificate from the store to secure your certificate. Things to note If you create a copy of App Service Certificate this way, it won’t have any impact on existing App Service SSL bindings that were created using the portal experience. It also won’t affect any such SSL bindings you may create in the future. You can still Rekey and Renew an App Service Certificate with one click even after making a copy but you would be responsible for creating a new local copy with the new certificate and updating all services that are using the old certificate. Tips This section compares this method of certificate deployment with the built-in Azure portal experience for Web Apps. It also contains recommendations you should follow when you use the PFX copy elsewhere. Title Azure portal Deployment Deploying local PFX copy Recommendations Auto/Manual Renew When an App Service Certificate is renewed, all the corresponding App Service SSL bindings are updated automatically When a certificate is renewed, you would need to manually update all the services that are using a local copy. Turn off Auto renew as you won’t know when exactly an App Service Certificate gets renewed with Auto renew and this would end up breaking your SSL endpoints. Manually renew such App Service Certificates before they expire Rekey Just like renewal, the corresponding SSL bindings are updated automatically Just like renewal, you would need to manually update all such services. Deployment When deploying certificate this way, you don’t need any file locally and there won’t be any secrets to clean up When deploying certificate this way, you would have the PFX certificate on local disk. Always delete the local copy once you no longer need it as you can create a PFX copy as many times as you want. Also, never store the password shown in PowerShell console locally. This way, even if somehow an adversary gets hold of your local disk, he still won’t be able to use the PFX certificate as it’s protected by a strong password Getting in touch If you have an App Service Certificate that you would like to use outside of App Service ecosystem, then give this a try and let us know how it goes. If you run into any issues, please let us know on the App Service forum. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/02/24/Creating-a-local-PFX-copy-of-App-Service-Certificate.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Announcing general availability for MySQL in-app",
+ "excerpt":" mksunitha 3/6/2017 11:00:24 PM MySQL in-app was a preview feature launched last year in August. The feature primary objective was to make it easier to build and test MySQL based applications on App Service. Today, I am excited to announce general availability of MySQL in-app feature. Note : This MySQL in-app is specific to Windows version of Azure app service. If you are looking for local mysql on Linux MySQL app service , click here. We have rolled out a database migration feature from MySQL in-app that allows you to export your database content from localdb database provided by MySQL in-app and import it into a production database. A production database can be managed MySQL service or your custom MySQL server solution. See options for production MySQL database in Azure. This feature will be continue to accelerate your development and testing scenarios . Here are key benefits of using this feature : It supports any runtime stack that is available in App Service (Windows) applications such as Node JS , .NET , Python , PHP etc. For Python, Node JS , .NET do make sure you have the appropriate libraries or drivers with your code in order to connect to MySQL database provided with MySQL in-app It’s cost-effective since there’s no additional cost to use this feature and you only pay for the App Service plan (since resources are shared). The MySQL and Web processes are co-located in the same environment (hence the term in-app) which means storage is shared. Includes support for slow query logging and general logging, which you’ll need to turn on as needed (this feature impacts performance, so you shouldn’t use it all the time). One click migration of your database from MySQL in-app to a production MySQL database solution. Azure offers many solutions for MySQL , including: Azure database for MySQL(Preview) Marketplace solutions for MySQL, MariaDB, and other MySQL-compatible solutions from partners like Bitnamiand MariaDB Community-contributed Azure Resource Manager (ARM) templatesdeploying on VMs MySQL on virtual machine on Linuxor Windows OS If you intend to use this feature for PRODUCTION web application , your web application must meet one or more of the criteria below : your application is read only web site [ when file server is in read only mode , the database is read only as well ] your application does not need auto scale File servers may go into read only mode from 1 to 6 mins depending on whether an upgrade is occurring or any intermittent storage connectivity issue occurs. For example if you use wordpress and during this time you cannot write a post or edit content. You can retry in a few minutes and it will work. If this is okay for your production app then use MySQL inapp Review your user traffic on your application and test to see if your application can run on one instance. If it can manage the load , you can use MySQL inapp for production. The reason for the criteria mentioned above is due to the lack of support for auto scale on App service with MySQL in-app. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/03/06/Announcing-general-availability-for-MySQL-in-app.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Migrate development database on MySQL in-app to production MySQL database",
+ "excerpt":" mksunitha 3/6/2017 10:56:56 PM MySQL in-app feature on App service has announced general availability today. The feature has been keen on improve the experience of developing MySQL based applications on Azure App Service. Once your application is ready to go live , you need to migrate the database content to your production database. This can be tedious task when done manually . In the MySQL in-app management settings , we now have, we have an option for easily exporting your localdb database from MySQL in-app to a production MySQL database. This blog will discuss how to perform this migration of your database. Follow the steps below : 1. Create a production MySQL database using any one these options. For this blog post I am using a production Azure database for MySQL(Preview). For details , refer to How to create MySQL database from Portal or How to create MySQL database using CLI. 2. Copy the connection string for the Azure database for MySQL(Preview) database. If you are using a different database solution for production , collect the database connection information for your production database. 3. Login to the Azure portal . Click on your web app using MySQL in-app. Select MySQL in-app setting for your web app and Click on Export button under MySQL in App Export 4. You have a choice of using a connections string for your production database or enter the credentials manually. Once the production database connection information has been entered , click on Save to start the process of export. During the export a connection string will be added to the connection string setting in the portal. During the export , you cannot make any changes to MySQL in-app configuration in the portal. All options will be disabled to manage MySQL in-app during export process .You must wait until the export is completed. 8. Once the export is successful , review your production database to make sure all the content was successfully updated. Note we do not turn off the MySQL in-app feature since your production application may still be using it. Update your application to connect to the production database and test your application before going live with your application. After successful testing , you can now turn off MySQL in-app feature for your web app to continue using production database. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/03/06/Migrate-development-database-on-MySQL-in-app-to-production-MySQL-database.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "JanuaryFebruary 2017 App Service Update",
+ "excerpt":" Byron Tardif 3/9/2017 4:00:58 PM Diagnose and solve problems App Service has a new experience for Diagnose and solve problems. With this new UI we make it easier to distinguish between application issues (your code) and platform issues (App Service). We also provide quick solutions (Fix it!) tailored to the problems you might be experiencing. The UI provides a view of the health of your application, health of the platform as well as traffic over the last 24 hours. If any availability issues are detected in that time window, they are listed below the graphs. You can drill down into more detail from there. If the issue is currently ongoing we try to provide a custom solution specific to the issue we detected. This should point you in the right direction to fix your problem and help get your application back into a healthy state. You can reach the new experience by clicking on the Diagnose and solve problems item in the general section of any Web, Mobile or API app. GA for MySQL in App The MySQL in-app feature enables running MySQL natively on the Azure App Service platform. While this feature is ideal for small applications running on a single instance, or for development scenarios, you will need a full fledged MySQL resource that you can manage and scale independently for any production scenario. To ease the migration from your MySQL in App to an external MySQL database we have added Export functionality in the portal to make this a turnkey experience. You can read more about MySQL in App in the MySql-in-app general availability announcement, and learn how to Migrate development database on MySQL in-app to production MySQL database using the export experience. Improved integration with PowerApps and PowerFlows Under the API definition feature for any Web, API or Mobile app you will find the new Export to PowerApps + Micosoft Flow button: Clicking on it will provide the necessary instructions based on your API metadata to allow your PowerApps + Microsoft Flow apps to consume it: Export App Service certificates to use with other Azure Resources Certificates purchased through App Service certificates can now be exported to use with other Azure Resources: App Service on Linux We released a few new built-in containers including support for Node 6.9.3 as well as Ruby 2.3: Bitbucket has also been added as a supported Deployment source under Deployment options: App service Companion We have a new App Service Companion for iOS update that includes new functionality such as support for Push Notifications and ability to Favorite apps for quick access. If you have any questions about any of this features or App Service in general be sure to check our forums in MSDN and Stack Overflow. For any feature requests or ideas check out our User Voice ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/03/09/JanuaryFebruary-2017-App-Service-Update.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Azure Functions F# support is now generally available",
+ "excerpt":" Chris Anderson (Azure) 3/16/2017 10:00:21 AM Today, we’re happy to announce that F# is now generally available for all users of Azure Functions. Now that the API is stable, anyone can build production applications with Functions written in F#. You can get started today by using one of the F# templates in the portal today. Getting started with F# and HTTP triggers Whether you need to expose a new HTTP endpoint for an API or WebHook, or process items from a queue, now F# developers can take full advantage of these Azure Functions capabilities. Here’s a quick sample of how easy it is to set up an HTTP Trigger: Create a new Function App (if you don’t have one already): Then, you can create a new F# Function from the “+ New Function” menu Once you click on create, you’ll have your Function shortly appear. You can copy the URL to invoke it (1) and click on the Logs button (2) to view your streaming logs from your Function. Next Steps You can continue to learn about F# on Azure Functions by following some of the links below: Try Functions for free! Azure Functions F# Developer Reference Running Azure Functions Locally Reach out to the team on GitHub ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/03/16/Azure-Functions-F-support-is-now-generally-available.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Publishing a .NET class library as a Function App",
+ "excerpt":" Donna Malayeri 3/16/2017 1:00:00 PM Update #1: The Azure Functions CLI has been renamed to Azure Functions Core Tools. Update #2: We now have Visual Studio 2017 tooling for Azure Functions! You can use WebJobs attributes to configure triggers and bindings, so there is no need to manually author function.json. For more information, see the following: Visual Studio 2017 Tools for Azure Functions Azure Functions Visual Studio Tooling video With our new Azure Functions runtime support for precompiled functions, you can now use familiar Visual Studio features such IntelliSense and unit testing. These features were among the top requests after we launched the preview Visual Studio Tools for Azure Functions. This also enables an improved development workflow for customers who feel that that class libraries are a better fit for their application. Azure Functions now supports publishing a class library as the implementation for one or more functions in a Function App. We’ve also recently made several runtime improvements to make assemblies much more useful, such as shadow-copying managed assemblies to avoid file locking issues and restarting the Functions runtime to pick up newly deployed binaries. Using Visual Studio 2015 or 2017, you can try precompiled functions today with a few manual tweaks to your project. The manual steps are needed because the existing Functions project type (.funproj) has no build action, since it contains only script files. With the setup below, you'll instead use a web project which will provide the full development experience of IntelliSense, local debugging, and publishing to Azure. The next version of Visual Studio tooling for Azure Functions won’t require this manual configuration, as it will be directly based on class libraries. In fact, the Visual Studio experience will be optimized around class libraries, while the Functions portal will continue to use script files. Performance benefits of class libraries Aside from the tooling experience, another advantage of using a class library is that you’ll see improvements to “cold start,” particularly when running on a Consumption plan. Cold start occurs on the first request to a Function App after it has gone idle, which happens after 5 minutes of inactivity. When a Function App starts up, it indexes all functions and compiles C# and F# scripts into an assembly in memory. So, compilation time will add to cold start time. Customers aren’t charged for cold start since function execution hasn’t started, but it does cause a delay in event processing. Use a Web Application project with a customized start action A Web Application project is really a special kind of class library, which means it produces an executable .dll as the build output. To enable local running and debugging, modify the start action of the web project to launch the Azure Functions Core Tools. Here are some sample projects set up this way: HttpTrigger sample CoderCards – trading card generator with blob trigger Project setup – Visual Studio 2015 or 2017 From the New Project dialog, choose ASP.NET Web Application (.NET Framework) with the empty site template. Open the project properties. In the Web tab, choose Start External Program For the program path, enter the path to func.exe for the Azure Functions Core Tools. OR, if you've installed the Visual Studio Functions Tooling, the path will look something like C:\\Users\\USERNAME\\AppData\\Local\\Azure.Functions.Cli\\1.0.0-beta.93\\func.exe If you've installed the Azure Functions Core Tools through NPM, the path will be something like C:\\Users\\USERNAME\\AppData\\Roaming\\npm\\node_modules\\azure-functions-core-tools\\bin\\func.exe For Command line arguments, set host start For Working directory, specify the root of the web project on your machine (unfortunately, this isn’t set automatically.) Here's a YouTube video that walks through these steps. Downloading existing function code If you’ve already developed your functions in the Azure Portal, you can download your code and settings with the following steps. Install the Azure Functions Core Tools from npm. If you’ve installed the Visual Studio Tools for Azure Functions, just add func.exe to your path from %USERPROFILE%\\AppData\\Local\\Azure.Functions.Cli\\1.0.0-beta.93 (or the latest version on your machine). Go to the Kudu console for your Function App in Function App Settings -> Kudu. Navigate to site and click on the download icon to the left of wwwroot (click on the animated gif below). Or, from an authenticated session, go to https://your-function-app.scm.azurewebsites.net/api/zip/site/wwwroot/. Unzip the file wwwroot.zip on your local machine. From that directory, run the following: [sourcecode language=\"plain\" light=\"true\" gutter=\"false\"] func azure login (optional) func azure account list (optional) func azure account set func azure functionapp list func azure functionapp fetch-app-settings [name] [/sourcecode] This will create a local file called appsettings.json. These settings are only used locally by the Functions Core Tools. Since this file contains secrets, be sure not to check this file in to source control! (The Azure Functions Core Tools adds appsettings.json to .gitignore for you.) Animated gif: Project content Copy your downloaded files to the web project folder (including appsettings.json). Include the script files and function.json in the project. F5 should now work and successfully attach a debugger. But, you’re still using script files. Converting to class files To convert script files to C# class files, most changes are straightforward. The one manual step is to modify function.json to point to a class library instead of a script file (step #7 below). The next version of the Visual Studio tooling will eliminate this manual step. Rename .csx to .cs and add a class declaration and optional namespace declaration. Remove #load and replace #r with assembly references. If you’re using TraceWriter, add the NuGet package Microsoft.Azure.WebJobs and the statement: using Microsoft.Azure.WebJobs.Host If you're using timer triggers, add the NuGet package Microsoft.Azure.WebJobs.Extensions. Add NuGet package references for the packages that are automatically referenced, such as Newtonsoft.Json and Microsoft.ServiceBus. Add explicit namespace import statements if you’re using any of the automatically imported namespaces, such as System.Threading.Tasks. Add any other NuGet packages specified in project.json using NuGet package manager. For each function, modify function.json and specify the scriptFile and entryPoint properties. scriptFile is a path to the assembly and entryPoint is the qualified name of the method. Make sure that function.json is in a directory that matches the function name. See documentation on precompiled functions. [sourcecode language=\"plain\" light=\"true\" gutter=\"false\"] \"scriptFile\": \"..\\\\bin\\\\Assembly.dll\", \"entryPoint\": \"Namespace.ClassName.Run\" [/sourcecode] See sample function.json. Once you compile and run, you should see your class library functions being loaded by the Functions Runtime. Publish from Visual Studio You can publish the project to a Function App using the same experience as App Service publish. The project template generates web.config, but publishing this file has no effect (it is not used by the Functions runtime). Each web project maps to one Function App. If you need to publish functions independently of one another, we recommend that you use separate Function Apps. To create a new Function App, choose Function App in the Create App Service dialog. To publish to an existing Function App, download your publish profile from the Azure Portal and import in the Visual Studio publish dialog. You can use the Azure portal to run precompiled functions and view execution logs. To make code changes, you should re-publish from Visual Studio. Publish from Azure Functions Core Tools The Azure Functions Core Tools also provides a publish command, via the following: [sourcecode language=\"plain\" light=\"true\" gutter=\"false\"] func azure login func azure functionapp publish [name] [/sourcecode] Building on the server using continuous integration and deployment There’s another big advantage to using a web project—continuous integration with build on the server just works! Just follow the same steps as continuous deployment for Azure Functions. Your project will be built whenever there is a sync from source control. This will only work if you’re using a Web Application project, but not if you’re using a Functions Project (.funproj). To see this in action, just fork the HttpTrigger sample project and set up GitHub as your continuous integration source. Provide feedback Ask questions in the comments section below or reach out to me on Twitter @lindydonna. For general feedback and questions about Azure Functions: Ask product questions on the Azure Functions MSDN forum and StackOverflow, where you’ll get answers directly from the engineering team. Submit feature requests on feedback.azure.com or the Azure Functions GitHub repo. Reach out to us on Twitter via @Azure with the hashtag #AzureFunctions. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/03/16/Publishing-a-.NET-class-library-as-a-Function-App.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Azure App Service (Web, API, Mobile, ASE) & Azure Functions SKU Comparison Matrix",
+ "excerpt":" Cory Fowler (MSFT) 3/23/2017 6:27:19 PM App Service has come a very long way in the nearly 5 years it has been a service in Azure. Along the way, we've added a number of features, changed the pricing model, we've even gone as far as to make App Service available in an isolated capacity with App Service Environment and with the recent addition of Azure Functions a new type of hosting plan. With all of these changes it's become clear to us that we need to provide a clear breakdown as to which features are available in which tiers because that enables you, our beloved customers, to be successful on our platform. In an attempt to clarify which features are available where, we have created the below matrix. We are posting this to our blog first, as we would like to hear your feedback if this is effective way of relaying this information to you. For Example, should we merge the below matrix with the App Service Plan limits page. Please leave your feedback in the comments below and we will work on getting a more formal piece of documentation together that will provide you with all of the details you need to get to market in the quickest way possible using Azure App Service. Features SKU App Deployment Free Shared Basic Standard Premium ASE ILB ASE App Service Linux Consumption Plan (Functions) Continuous Delivery ✓ ✓ ✓ ✓ ✓ ✓ ✓ Continuous Deployment ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ Deployment Slots ✓ ✓ ✓ ✓ Docker (Containers) ✓ 1 Development Tools Free Shared Basic Standard Premium ASE ILB ASE App Service Linux Consumption Plan (Functions) Clone App ✓ ✓ ✓ Kudu ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ 2 ✓ PHP Debugging 3 ✓ ✓ ✓ ✓ ✓ ✓ Site Extensions ✓ ✓ ✓ ✓ ✓ ✓ ✓ Testing in Production ✓ ✓ ✓ ✓ Monitoring Free Shared Basic Standard Premium ASE ILB ASE App Service Linux Consumption Plan (Functions) Log Stream ✓ ✓ ✓ ✓ ✓ ✓ ✓ 4 ✓ Process Explorer ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ Networking Free Shared Basic Standard Premium ASE ILB ASE App Service Linux Consumption Plan (Functions) Hybrid Connections ✓ ✓ ✓ ✓ ✓ ✓ ✓ VNET Integration ✓ ✓ ✓ ✓ Programming Languages Free Shared Basic Standard Premium ASE ILB ASE App Service Linux Consumption Plan (Functions) .NET ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ .NET Core ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ Java ✓ ✓ ✓ ✓ ✓ ✓ ✓ alpha Node.js ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ PHP ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ alpha Python ✓ ✓ ✓ ✓ ✓ ✓ ✓ alpha Ruby ✓ Scale Free Shared Basic Standard Premium ASE ILB ASE App Service Linux Consumption Plan (Functions) Auto-scale ✓ ✓ ✓ ✓ ✓ Integrated Load Balancer ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ Traffic Manager ✓ ✓ ✓ ✓ Settings Free Shared Basic Standard Premium ASE ILB ASE App Service Linux Consumption Plan (Functions) 64-bit ✓ ✓ ✓ ✓ ✓ ✓ ✓ Always On ✓ ✓ ✓ ✓ ✓ Session Affinity ✓ ✓ ✓ ✓ ✓ ✓ ✓ Authentication &Authorization ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ Backup/Restore ✓ ✓ ✓ ✓ ✓ Custom Domains ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ FTP/FTPS ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ Local Cache ✓ ✓ ✓ ✓ MySQL in App ✓ ✓ ✓ ✓ ✓ ✓ ✓ 4 Remote Debugging (.NET) ✓ ✓ ✓ ✓ ✓ ✓ ✓ Security Scanning ✓ ✓ ✓ ✓ ✓ ✓ SSL (IP/SNI) ✓ ✓ ✓ ✓ ✓ ✓ SNI SSL Web Sockets 5 ✓ ✓ ✓ ✓ ✓ ✓ ✓ 1 Supports a one-time pull model from Docker Hub, Azure Container Registry or a private Docker Registry.2 Kudu on Linux doesn’t have the same feature set as Kudu on Windows.3 PHP Debugging is currently only supported on Windows. PHP Debugging for version 7.x is unavailable.4 ILB ASE has no public connectivity to the internet. Management actions on ILB ASE must be performed using the Kudu Console.5 The number of Web Socket ports are limited by the sku, review the App Service Constraints, Service Limits and Quotas. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/03/23/Azure-App-Service-(Web,-API,-Mobile,-ASE)-&-Azure-Functions-SKU-Comparison-Matrix.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Announcing Azure Functions OpenAPI (Swagger) support preview",
+ "excerpt":" Alex Karcher 3/30/2017 12:00:37 PM Today we are announcing preview support for editing and hosting OpenAPI 2.0 (Swagger) metadata in Azure Functions. API authoring is a popular application of Functions, and Swagger metadata allows a whole network of Swagger compliant software to easily integrate with those APIs. We are adding a Swagger template generator to create a quickstart Swagger file from the existing metadata in your HTTP Trigger Functions. You just fill in the operation objects for each of your HTTP verbs and you’re off! We host a version of the swagger editor to provide rich inline editing of your Swagger file from within the Function UI. Once you save your Swagger file we’ll host it for you at a url in your Function App's domain. Head on over to the documentation to learn more Integrations These features integrate with the existing Azure App Service API definition support to allow you to consume your API on a variety of 1st party services, including PowerApps, Flow, and Logic Apps, as well as the ability to generate SDKs for your API in Visual Studio. Creating your first Open API definition Check out our getting started guide for in-depth instructions To create your first OpenAPI (Swagger) definition you must first have a function App with at least one HTTP Trigger Function. Instructions. Next head over to the \"API Definition (preview)\" tab in the lower left hand corner of your Function App. Toggle your Swagger source to \"Internal.\" This will enable hosting and inline editing of an OpenAPI definition for this Function App. Click \"Load Generated API Definition\" to populate the Swagger editor with a quickstart OpenAPI definition. This definition uses your function.json, represented as the settings in the \"Integrate tab,\" for each Function to populate the definition. Add an operation object for the POST operation of your function with the expected type of input. For the HTTP Trigger sample code you can use the following Operation object: Remove the entries under Paths/api/<yourFunctionName> for every verb except POST. (get, delete, head, etc) For the default HTTP Trigger, all HTTP verbs are allowed, so our quickstart will have a blank entry for all 8 possible verbs. We want our definition to only contain the available functionality of our API. Test your Swagger definition In the right-hand pane of the swagger editor add your API key as Authentication info, click \"try this operation,\" and enter a name to test your Swagger. Provide Preview Feedback Try out Swagger support in Functions and let us know how you like it! We are continuing to develop this set of features and would love to know what matters most to you. If you run into any problems, let us know on the forums, ask a question on StackOverFlow, or file an issue on GitHub. If you have any additional features you would like to see, please let us know on Uservoice. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/03/30/Announcing-Azure-Functions-OpenAPI-(Swagger)-support-preview.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Updating Migrated Azure Mobile Services Sites for Facebook Auth",
+ "excerpt":" Adrian Hall (MSFT) 3/30/2017 11:30:35 AM If you use a combination of Azure Mobile Services and Facebook authentication, then you will have noticed that the Facebook authentication stopped working yesterday. This was due to the deprecation of an underlying Facebook OAuth protocol that the service relied on. If your Azure Mobile Services site has not been migrated yet, we have made changes in the backend to fix the protocol, so no action is required on your part. We apologize for the downtime that this caused. If your Azure Mobile Services site has been migrated, then you are in charge of the code that runs your site. If your site is a .NET site, we have updated the Katana middleware that runs authentication within the site extension. You need to update an App Setting within your site: Log on to the Azure portal. Find your Azure App Service site and click it. The easiest way to do this is to click All Resources then use the Filter by name... box to find your site. Click Application settings (under Settings) in the left-hand menu. Scroll down until you find App settings. Update the MOBILESERVICESDOTNET_EXTENSION_VERSION value from 1.0.478 to 1.0.481. Click Save at the top of the Application settings blade. If you are running a Node site, then you will need to update the Azure Mobile Services package that is an integral part of the site code to pick up the changes. To do this: Log on to the Azure portal. Find your Azure App Service site and click it. The easiest way to do this is to click All Resources then use the Filter by name... box to find your site. Click Console (under Development Tools) in the left-hand menu. Run the command npm install azure-mobile-services@1.0.1 to update the package. Let this process complete. Click Overview in the left-hand menu. Click Restart to restart your site. After the changes, please test the Facebook authentication to ensure it is working. You can reach out to us on Stack Overflow or Azure Forums to get additional help. We would like to also take this opportunity to encourage you to update your site to Azure Mobile Apps. This is the v2 edition of the same service, but contains a different client SDK and server SDK. If you are a .NET developer, lots of information about developing the service is available in the Azure Mobile Apps Documentation (for Client and Server) and my book. For Node developers, you can use the Compatibility package to convert your Mobile Services server to a Mobile Apps server. Again, please reach out to us if you run into trouble. As a reminder, the Azure Mobile Services reaches its end of life in May, 2017. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/03/30/Updating-Migrated-Azure-Mobile-Services-Sites-for-Facebook-Auth.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "March 2017 App Service Update",
+ "excerpt":" Byron Tardif 4/4/2017 10:56:04 AM This month we shipped a pair of new features: Remote debugging support for Visual Studio 2017 App Service now supports remote debugging your app form Visual Studio 2017. Remote debugging can be enabled form Application Settings in the menu: If you want to learn more about remote debugging you apps in App Service and other troubleshooting tools supported by the platform check out this article: Troubleshoot a web app in Azure App Service using Visual Studio You can get Visual Studio 2017 here: https://www.visualstudio.com/downloads/ WordPress on Linux (preview) App Service has always supported running WordPress on Windows based App Service plans, but now you have the option to also run it on Linux. This version of WordPress leverages the App Service on Linux support for container and it’s implemented as a custom Docker image publicly available on Docker hub. You can read more about App Service on Linux here: Introduction to App Service on Linux and how to Create WordPress using Web Apps on Linux If you have any questions about any of this features or App Service in general be sure to check our forums in MSDN and Stack Overflow. For any feature requests or ideas check out our User Voice ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/04/04/March-2017-App-Service-Update.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Azure Functions now has direct integration with Application Insights",
+ "excerpt":" Donna Malayeri 4/6/2017 12:56:15 PM Today we're encouraging everyone to go give Azure Functions' Application Insights integration a try. You can find full instructions and notes on how it works at https://aka.ms/func-ai. Now it takes (nearly) zero effort to add Application Insights to your Azure Functions and immediately unlock a powerful tool for monitoring your applications. Application Insights is now available for all Functions users on \"~1\". If you're on \"beta\" now, please switch back to \"~1\" which has the latest version. If you stay on \"beta\", it's very likely you'll be broken by something at some point. Getting Started It’s fairly simple to get started – there is just two steps. Create an Application Insights instance. Application type should be set to General Grab the instrumentation key Update your Function App’s settings Add App Setting – APPINSIGHTS_INSTRUMENTATIONKEY = {Instrumentation Key} Once you’ve done this, your App should start automatically sending information on your Function App to Application Insights, without any code changes. Using Application Insights to the fullest Now that your Function Apps are hooked up to Application Insights, let's take a quick look at some of the key things you'll want to try. Live Stream If you open your Application Insights resource in the portal, you should see the option for “Live Metrics Stream” in the menu. Click on it and you’ll see a near-live view of what’s coming from your Function App. For executions, it has info on #/second, average duration, and failures/second. It also has information on resource consumption. You can pivot all of these by the “instance” your functions are on; providing you insight on whether a specific instance might be having an issue or all of your Functions. Analytics The analytics portal provides you the ability to write custom queries against your data. This is one of the most powerful tools in your tool box. Currently, the following tables are full of data from the Functions runtime: Requests – one of these is logged for each execution Exceptions – tracks any exceptions thrown by the runtime Traces – any traces written to context.log or ILogger show up here PerformanceMetrics – Auto collected info about the performance of the servers the functions are running on CustomEvents – Custom events from your functions and anything that the host sees that may or may not be tied to a specific request CustomMetrics – Custom metrics from your functions and general performance and throughput info on your Functions. This is very helpful for high throughput scenarios where you might not capture every request message to save costs, but you still want a full picture of your throughput/etc. as the host will attempt to aggregate these client side, before sending to Application Insights The other tables are from availability tests and client/browser telemetry, which you can also add. The only thing that’s currently missing is dependencies. There is also more metrics/events we’ll add over the course of the preview (based off your generous feedback on what you need to see). Example: This will show us the median, p95, and p99 over the last 30 minutes graphed in a timeplot. While you can copy+paste this query, I'd recommend trying to type it out yourself to get a sense of the amazing intellisense features that the editor has. You can learn about all the language features with some amazing examples from the Analytics reference page. You can also pin these graphs to your dashboard, which makes for a really powerful tool for having a way to know how your application is behaving at a glance. Alerts While it's great that I can see what's happening and what happened, what's even better is being told what's happening. That's where alerts come into play. From the main Application Insights blade, you can click on the alerts section and define alerts based on a variety of metrics. For example, you could have an alert fire when you've had more than 5 errors in 5 minutes, which sends you an email. You can then create another one which detects more than 50 errors in 5 minutes, and triggers a Logic App to send you a text message or PagerDuty alert. Next steps Application Insights is now GA'd and ready for production workloads. We're also listening for any feedback you have. Please file it on our GitHub. We'll be adding some new features like better sampling controls and automatic dependency tracking soon. We hope you'll give it a try and start to gain more insight into how your Functions are behaving. You can read more about how it works at docs.microsoft.com ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/04/06/Azure-Functions-now-has-direct-integration-with-Application-Insights.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "New integrated portal for Azure Functions",
+ "excerpt":" Donna Malayeri 4/10/2017 10:30:44 AM I’m excited to announce a new integrated portal experience for Azure Functions. Previously, there was somewhat disjoint experience between Function Apps and App Service. For many management operations, customers had to navigate to the App Service resource blade, and we heard feedback that customers wanted a more integrated and streamlined experience. In addition, we want to provide an easier way to manage multiple Function Apps from within one view. We’ve made several enhancements to the experience, including: A dedicated browse blade for Function Apps. Function Apps are still listed in the App Service blade, but that’s no longer the only way to find Function Apps A tree view that allows viewing and managing multiple Function Apps Filters on subscription and app name, as well as an option to scope the view to just one app One-click access to all App Service platform features A convenient way to manage features that have already been configured Overall UI enhancements to be more consistent with the rest of the Azure portal For a visual introduction, the short video below walks through the main features. The video is also available on YouTube. [video width=\"1920\" height=\"866\" mp4=\"media/2017/04/function-navigation-full.mp4\"][/video] Function App browse and management There is now a new browse blade for Function Apps that you can pin to the left-hand service menu. Under More services, search for Functions. Once you’re on the browse blade, you’ll see all Function Apps in your active subscription in a tree view on the left. You can filter on one or more subscriptions or search for an app name. In the list view on the right, apps are listed in a grid view that includes the subscription, resource group, and location. If you select an app in the grid view, you’ll see a scoped view for just that Function App. Clearing the search box at the top will show all Function Apps in the selected subscriptions. See animated gif below. You can also scope to a particular Function App by selecting the chevron to the right of the app name. The refresh button will update the function and proxies list. On a Consumption plan, the refresh button also synchronizes triggers with the central listener. (This is required if you FTP or Kudu to modify your function.json files.) Function App management Once you’ve selected a Function App, the Overview tab on the right displays information about your app and is similar to the App Service resource blade. From here, you can stop, restart and delete your app, download the publish profile, and reset publish credentials. The Configured features section lists any platform features that you’ve customized. For instance, if you have configured a deployment option, you can navigate to the settings directly from the overview page. The Settings tab includes Function App level settings, such as the runtime version, proxies configuration, and host keys. The Platform features tab lists all relevant App Service settings. If you miss the App Service resource blade, you can still get to it from General Settings -> All settings. Features that are not available for your app are still displayed, but include a tooltip on why they are not available. You can also search settings based on either exact name or a descriptive tag. For instance, searching on “git” will highlight the option Deployment source. The API definition tab allows you to configure a Swagger API definition. For more information on the feature, see the blog post Announcing Azure Functions OpenAPI (Swagger) support preview. Function navigation Navigating to an individual function is also much easier. If you select the Functions or Proxies node within a Function App, you’ll see a list of items you can use to navigate. We’ll be making more improvements to the Functions list, including the ability to search functions, change the enabled state, and delete functions. (For more details, see the GitHub issue AzureFunctionsPortal #1062.) See animated gif below. New Function page The New Function page has a few changes. Since the main Function App page now shows the Overview tab, that displaced the Quickstart experience. We’ve incorporated it as part of the New Function page. If a Function App has no functions, you’ll see the quickstart below. To get to the full template view, select Create custom function at the bottom of the page. To get to the quickstart view below from the template view, select “go to the quickstart.” Upcoming improvements Today’s release is just the start of the improvements to the Functions portal. Here’s a list of some of the other improvements we have planned: Option to create a new Function App from the navigation blade. Currently, you have to go to the top-level +New option to create a Function App (AzureFunctionsPortal #986) On Functions grid page, add options for search, enable/disable, and delete (AzureFunctionsPortal #1062) Include pricing tier in Function App list (AzureFunctionsPortal #1030) Add list of keys to Get Function URL dialog (AzureFunctionsPortal #850) Sort templates by scenario, rather than alphabetical (AzureFunctionsPortal #405) Feedback survey As this is a big change to the Azure Functions portal, we’d love to hear your feedback. Help improve the product by filling out a 2-minute survey: https://aka.ms/functions-portal-survey. Provide feedback Ask questions in the comments section below or reach out to me on Twitter @lindydonna. For general feedback and questions about Azure Functions: Ask product questions on the Azure Functions MSDN forum and StackOverflow, where you’ll get answers directly from the engineering team. Submit feature requests on the Azure Functions GitHub repo or feedback.azure.com. For portal bugs and feature requests, post in AzureFunctionsPortal. Reach out to us on Twitter via @AzureFunctions or use the the hashtag #AzureFunctions. Acknowledgements We’d like to thank our Azure MVPs and Azure Advisors for trying out an early version of the portal and providing feedback. Functions team members @bktv99, @crandycodes, and @phaseshake filed the most bugs during the bug bash. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/04/10/New-integrated-portal-for-Azure-Functions.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Announcing Try App Service API Apps",
+ "excerpt":" Alex Karcher 4/14/2017 12:11:52 PM Today we are very excited to announce the addition of Azure API Apps to Try App Service. You can now create free trial API Apps with no credit card in a matter of seconds! API Apps provide a streamlined PaaS experience for hosting APIs. Leverage turnkey security, rich Visual Studio integration, and Swagger support to make the process of developing, hosting, and growing your API easy. To learn more about API Apps check out our docs! Templates We have two available to showcase API Apps: API Todo List: A simple REST API that would host the data for a todo list application. Read the Swagger document and then use the built in testing tools, or a 3rd party API testing suite like postman, to play with the API. API Contacts List: A combination single page application and backend API. Experiment with adding and removing contacts from your list, and then use the Swagger doc to experiment with the underlying API calls.Swagger UI showing the underlying API in the contacts list API Click here to go try API Apps! ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/04/14/Announcing-Try-App-Service-API-Apps.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "WordPress on Web app for Containers",
+ "excerpt":" mksunitha 4/16/2017 9:23:18 PM Web Apps on Linux allows running web apps natively on Linux. WordPress is popular blogging platform primarily used on Linux distributions. Today we have released WordPress for App Service on Linux in the Azure marketplace that helps you quickly create a WordPress application on Web apps (Linux) . This docker image enables you to run a WordPress site on Azure Web App on Linux using either : Azure Database for MySQL : It is a Microsoft solution for MySQL service on Azure that provides a managed database service for app development and deployment that allows you to stand up a MySQL database in minutes and scale on the fly . Local Database : You can manually setup your web app to use Local database. This option is not provided from Azure portal for WordPress on Linux template. Before you begin If you don't have an Azure subscription, create a free account before you begin. Deploy from Marketplace Log in to the Azure portal.Click here to create the WordPress application. Name Description App Name Enter a unique app name for your **Web App Name**. This name is used as part of the default DNS name for your app <app_name>.azurewebsites.net, so it needs to be unique across all apps in Azure. You can later map a custom domain name to your app before you expose it to your users Subscription Select a Subscription. If you have multiple subscriptions, choose the appropriate subscription. Resource group Enter a resource group. A resource group is a logical container into which Azure resources like web apps, databases that is deployed and managed. You can create a resource group or use an existing one App Service Plan App Service plans represent the collection of physical resources used to host your apps. Select the Location and the Pricing tier. For more information on pricing, see App service pricing tier Database Provider Use Azure Database for MySQL for database solution This will deploy a WordPress custom image on to Web Apps on Linux . Note there might be cold start for the first request to the site created. Using GIT repo for WordPress code Version 0.3 pulls wordpress code from our GIT repo when you create a when app using this Docker image . If you have custom code on Github as well , you can edit GIT_REPO after the app is created and GIT_BRANCH values in app settings. Create a Web App for Containers Add new App Settings Name Default Value GIT_REPO https://github.com/azureappserviceoss/wordpress-azure GIT_BRANCH linux_appservice Browse your site Note: GIT directory: /home/site/wwwroot. When you deploy it first time, Sometimes need to check wp-config.php. RM it and re-config DB information is necessary. Before restart web app, need to store your changes by \"git push\", it will be pulled again after restart. How to configure to use Local Database with web app Create a Web App for Containers Update App Setting WEBSITES_ENABLE_APP_SERVICE_STORAGE = true (If you like to keep you DB after restart.) Add new App Settings Name Default Value DATABASE_TYPE local DATABASE_USERNAME wordpress DATABASE_PASSWORD some-string Note: We create a database \"azurelocaldb\" when using local mysql . Hence use this name when setting up the app Browse your site Complete WordPress install Note: Do not use the app setting DATABASE_TYPE=local if using Azure database for MySQL How to update WordPress core , theme or plugins If WEBSITES_ENABLE_APP_SERVICE_STORAGE= false ( which is the default setting ) , we recommend you DO NOT update the WordPress core version , themes or files from WordPress admin dashboard. There is a trade off between file server stability and file persistence . Choose either one option to updated your files : OPTION 1 : Since we are using local storage for better stability for the web app , you will not get file persistence. In this case , we recommend to follow these steps to update WordPress Core or a theme or a Plugins version : Fork the repo https://github.com/azureappserviceoss/wordpress-azure Clone your repo locally and make sure to use ONLY linux-appservice branch Download the latest version of WordPress , plugin or theme being used locally Commit the latest version bits into local folder of your cloned repo Push your changes to the your forked repo Login to Azure portal and select your web app Click on Application Settings -> App Settings and change GIT_REPO to use your repository from step #1. If you have changed the branch name , you can continue to use linux-apservice . If you wish to use a different branch , update GIT_BRANCH setting as well. OPTION 2 : You can update WEBSITES_ENABLE_APP_SERVICE_STORAGE =true to enable app service storage to have file persistence . Note when there are issues with storage due to networking or when app service platform is being updated , your app can be impacted . How to turn on Xdebug By default Xdebug is turned off as turning it on impacts performance. Connect by SSH. Go to /usr/local/php/etc/conf.d, Update xdebug.ini as wish, don't modify the path of below line.zend_extension=/usr/local/php/lib/php/extensions/no-debug-non-zts-20170718/xdebug.so Save xdebug.ini, Restart apache by below cmd: apachectl restart Xdebug is turned on. Limitations Some unexpected issues may happen after you scale out your site to multiple instances, if you deploy a WordPress site on Azure with this docker image and use the MariaDB built in this docker image as the database. The phpMyAdmin built in this docker image is available only when you use the MariaDB built in this docker image as the database. Please Include App Setting WEBSITES_ENABLE_APP_SERVICE_STORAGE = true when use built in MariaDB since we need files to be persisted. Change Log Version 0.3 Use Git to deploy wordpress. Update version of PHP/Apache/Mariadb/Phpmyadmin. Add Xdebug extenstion of PHP. Use supervisord to keep SSHD and Apache. This is NOT compatible with tag 0.2 and tag 0.1 for Docker image wordpress-alpine-php Migrating an existing WordPress site This image creates a new WordPress application every time it is deployed. If you are migrating your application to this site , please follow directions to export and import as mentioned on Wordpress Codex. If you have a complex WordPress application where the above mentioned export and import options are not effective, Web Apps on Linux supports git deployment and you use FTP or GIT deployment to replace the file system on the site created with this template to bring your own content. You can use PHPmyadmin available with this solution to import your application database content. Troubleshooting The docker image has been updated from this docker image to using a new format where the docker image only contains the server components. The application code for WordPress is deployed via GIT from github repo . Update your application to use the new image appsvc/apps:apache-php-mysql-0.1 If you have an existing application created using the WordPress image , check the Application setting to verfiy which image is being used with DOCKER_CUSTOM_IMAGE setting . If the setting value is apache-php-mysql-0.1 , no changes needed . If the value is wordpress-0.2 or wordpress-0.1 or wordpress and follow the steps below based on the database being used : Azure Database for MySQL Create a new web app with WordPress from the Azure marketplace. Select \"Existing resource group\" and choose the resource group in which your Azure Database for MySQL database exists. Select the same app service plan in which the current site assigned to. If using Azure Database for MySQL , select your existing database that is being used by your web app. Test the new site to make sure it is working as expected before deleting the older app. Local database Backup your web app and database manually. Create a new web app with WordPress from the Azure marketplace and choose Azure database for MySQL Migrate your database to the new database and your files to newly created web app. Note : There is bug with Local database causing the application to break once the app is provisioned which will be fixed in early August 2017 . If you wish to use Local database , wait until Local database is support for WordPress template next month. Using App Service Storage If you using a web app that was created from Azure marketplace for Web App on Linux using WordPress , Drupal , Mediawiki and Joomla , please add the following app setting WEBSITES_ENABLE_APP_SERVICE_STORAGE app setting to true to continue using App service Storage (platform SMB share i.e /home/ folder ) . Use the platform file storage in these two scenarios : When you scale out using the autoscale feature in Web app for Linux. If your application modifies the the files system and you need this new changes to the file system to be persistent . For example , with a WordPress app if you install a plugin , Wordpress adds a few files to the files system for the plugin and modifies the database. If you scale up or the instance your app is running on is recycled you will loose the plugin files which can break your production application. Hence in such cases it is recommended to set the app setting to true. NOTE: If the setting is not set to true the changes to the file system are not persisted. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/04/16/WordPress-on-Web-app-for-Containers.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Azure Mobile Apps Quickstart Samples available as GitHub repositories",
+ "excerpt":" Adrian Hall (MSFT) 4/24/2017 8:57:35 AM We recently made a change to the way that we manage the Azure Mobile Apps quickstarts. In the past, when you created a Mobile App, you could go to the Quickstart blade and download a client. This mechanism is still available to you. However, we have also made these quickstart projects available as GitHub repositories. This allows you to fork the repository and start developing without going to the Quickstart blade first. The project that you download from the Quickstart blade is almost the same as the project you can retrieve from the GitHub repository. In the case of the GitHub repository version, you will need to set the URI of your Azure Mobile App backend. The repositories are: Android Apache Cordova iOS (Swift) iOS (Objective-C) Universal Windows (UWP) Xamarin Android Xamarin Forms Xamarin iOS In each case, look for the ZUMOAPPURL string in the code and replace it with the name of your Mobile App backend. For the C# projects, this has been placed in a file called `Locations.cs`. In the other projects, it is embedded in the service handler file, so search for the string. There will be one match. There are other great samples using Azure Mobile Apps for you to check out as well: FieldEngineer is a project for handling field-workers logistics. MyDriving brings together IoT and Mobile to analyze car telemetry. ContosoInsurance demonstrates an example customer-side insurance car claim service. We are always expanding the samples we offer, so check back often! ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/04/24/Azure-Mobile-Apps-Quickstart-Samples-available-as-GitHub-repositories.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "April 2017 App Service update",
+ "excerpt":" Byron Tardif 5/1/2017 1:28:42 PM This month we rolled out a new experience for Azure Functions, new Hybrid Connections UX and new integration with Azure CDN. New experience for Azure Functions We have fully re-vamped the portal experience for Azure functions, some of the improvements include: A dedicated browse blade for Function Apps. A tree view that allows viewing and managing multiple Function Apps Filters on subscription and app name, as well as an option to scope the view to just one app One-click access to all App Service platform features A convenient way to manage features that have already been configured Overall UI enhancements to be more consistent with the rest of the Azure portal You can read more about this in the announcement blog. New experience for Hybrid Connections Azure App Service, hybrid connections can be used to access application resources in other networks. It provides access FROM your app TO an application endpoint. Hybrid connections does not know or care what the application protocol is or what you are accessing. It is simply providing network access. Learn more about Hybrid Connections The new experience makes it easier to create, connect and manage hybrid connections within your web app. To access this feature go to Settings > Network > Hybrid Connections New Azure CDN integration Azure CDN lets you dramatically improve the performance of your application by caching and geo-distributing static content. You can read more about Azure CND here. Now adding Azure CDN to your web apps is only a few clicks away. To access this feature go to Settings > Network > Azure CDN New location for troubleshooting tools Tools to help you diagnose and debug your app have been moved into Diagnose and Solve problems, the items moved include: Metrics per Instance (Apps) Metrics per Instance ( App Service Plans) Live HTTP Traffic Application Events Failed Request Tracing logs Diagnostics as a Service Mitigate PHP Debugging (Zend Z-Ray) Security Scanning (Tinfoil) If you have any questions about any of this features or App Service in general be sure to check our forums in MSDN and Stack Overflow. For any feature requests or ideas check out our User Voice ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/05/01/April-2017-App-Service-update.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Enable PHP error logging in App Service",
+ "excerpt":" mksunitha 5/4/2017 11:03:36 AM By default PHP error logging is turned off. When your application experiences issues , it would be beneficial to turn the logging on to investigate to root cause of the issue and mitigate it. There are different ways to do this based on whether you are using App Service on Windows or Linux. Follow the steps below to turn on PHP error logging: App Service on Windows: Create .user.ini or modify an existing .user.ini file under your web app root directory D:\\home\\site\\wwwroot.You can do this by updating your root directory via FTP , GIT , or Kudu with this change. In this file add the following line log_errors = On App Service on Linux: Create a .htaccess file or modify an existing .htaccess file under web app root directory /home/site/wwwroot. You can do this by updating your root directory via FTP or GIT with this change. In this file add the following line log_errors = On Note Remember to turn OFF your PHP error logging when you have completed your investigation. By leaving the setting ON can have big impact on your web app performance. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/05/04/Enable-PHP-error-logging-in-App-Service.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Announcing Try App Service Web App on Linux (Containers)",
+ "excerpt":" Apurva Joshi (AJ) 5/10/2017 9:06:33 AM Web App on Linux is now available for Try App Service. You can now create free trial Web App running on Linux App Service without credit card. All you need is an MSA account. App Service Web App on Linux (Preview) enables developers to run their cloud apps natively on Docker Containers for Linux. It makes it easier to migrate existing apps hosted and optimized for the Linux platform into Azure App Service. Furthermore, with custom Docker Container support, developers can implement applications in many programming languages and stacks while taking advantage of Docker tooling as well as the industry leading PaaS capabilities of Azure App Service. Templates With the initial release, there are two templates available for Web App on Linux. NodeJS Web App on Linux PHP Web App on Linux These templates deploys a container with respective runtime, where you can choose to deploy your NodeJS or PHP Web App and give Web App on Linux a try using your MSA account. Once your trial Web App is created, you can simply manage it using Azure Portal by clicking on “Manage in Azure Portal” option or using CLI option. Once you are logged into the portal it gives you full access to Azure App Service Web App on Linux, where you can test out all the features like slots, SSH, Auto Scale as well as bringing your own container. Your trial Web App will expire in 30 minutes, but you can sign up for 30 day free trial. Click Here to Get Started ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/05/10/Announcing-Try-App-Service-Web-App-on-Linux-(Containers).html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Application Insights integration with Functions now in preview",
+ "excerpt":" Chris Anderson (Azure) 5/10/2017 8:00:44 AM Azure Functions support for Application Insights has moved out of limited beta and into a wider public preview. We’ve also added support to add Application Insights on create, as well as, a direct link from Azure Functions’ portal to the Application Insights blade. We’ve also added additional settings to help control what data get sent and how much to send, helping you to control the volume of data that is sent. Getting Started To get started with Azure Functions and Azure Application Insights, you can create a new Function App and set the Application Insights toggle to “On”, which will create an Application Insights resource for you, automatically. If you want to use add an existing Application Insights resource or you have an existing Azure Function App, you can add Application Insights by adding an App Setting with your instrumentation key. Create an Application Insights instance. Application type should be set to General Grab the instrumentation key Update your Function App’s settings Add App Setting – APPINSIGHTS_INSTRUMENTATIONKEY = {Instrumentation Key} Once you’ve done this, you can navigate to your Application Insights resource from the “Configured Features” page of your Function App. Using Application Insights Live Stream If you open your Application Insights resource in the portal, you should see the option for “Live Metrics Stream” in the menu. Click on it and you’ll see a near-live view of what’s coming from your Function App. For executions, it has info on #/second, average duration, and failures/second. It also has information on resource consumption. You can pivot all of these by the “instance” your functions are on; providing you insight on whether a specific instance might be having an issue or all of your Functions. Known issues: there are no dependencies being tracked right now, so the middle section is mostly useless for now. If you send your own custom dependencies, it’s not likely to show up here since they won’t be going through the Live Stream API since you’re normally using a different client, today. Metrics Explorer This view gives you insights on your metrics coming from your Function App. You can add new charts for your Dashboards and set up new Alert rules from this page. Failures This view gives you insights on which things are failing. It has pivots on “Operation” which are your Functions, Dependencies, and exception messages. Known issues: Dependencies will be blank unless you add custom dependency metrics. Performance Shows information on the count, latency, and more of Function executions. You can customize this pretty aggressively to make it more useful. Servers Shows resource utilization and throughput per server. Useful for debugging Functions that might be bogging down your underlying resources. Putting the servers back in Serverless. J Analytics The analytics portal provides you the ability to write custom queries against your data. This is one of the most powerful tools in your tool box. Currently, the following tables are full of data from the Functions runtime: Requests – one of these is logged for each execution Exceptions – tracks any exceptions thrown by the runtime Traces – any traces written to context.log or ILogger show up here PerformanceMetrics – Auto collected info about the performance of the servers the functions are running on CustomEvents – Custom events from your functions and anything that the host sees that may or may not be tied to a specific request CustomMetrics – Custom metrics from your functions and general performance and throughput info on your Functions. This is very helpful for high throughput scenarios where you might not capture every request message to save costs, but you still want a full picture of your throughput/etc. as the host will attempt to aggregate these client side, before sending to Application Insights The other tables are from availability tests and client/browser telemetry, which you can also add. The only thing that’s currently missing is dependencies. There is also more metrics/events we’ll add over the course of the preview (based off your generous feedback on what you need to see). Example: This will show us the distribution of requests/worker over the last 30 minutes. Configuring the telemetry pipeline We wanted to be sure you can still control what data and how much gets sent, so we’ve exposed a handful of configuration settings for your host.json which allows you to finely control how we send data. We our latest updates to the configuration, you can now control the verbosity levels of the various telemetry pieces, as well as enable and configure aggregation and sampling. Limitations during preview Now that we’ve moved out of beta, we don’t have any planned breaking changes, but we’ll still consider the feature in preview from a supportability point of view. Once we’ve had a wider set of users using Application Insights and we complete some missing features like automatic dependency tracking, we’ll remove the preview flag. This means if you should avoid using our Application Insights integration for business critical applications, and instead continuing to instrument your code yourself with Application Insights. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/05/10/Application-Insights-integration-with-Functions-now-in-preview.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Azure Functions API development updates",
+ "excerpt":" Matthew Henderson - MSFT 5/10/2017 12:00:32 PM From HTTP triggers to proxies, Azure Functions provides a variety of tools to make developing serverless APIs quick and easy. The team has been hard at work on improvements to the API development story, including new capabilities for Azure Functions Proxies, as well as a faster way to get your APIs into PowerApps and Microsoft Flow. Request and response transforms for Azure Functions Proxies Azure Functions Proxies now allows you to modify requests to and responses from the backend. A new feature of proxies.json allows you to set properties of the HTTP message, including headers, query string parameters, request methods, and response status codes. This can be used to more easily integrate with existing backends or to create mock APIs. As a part of this update, you are also now able to bind parameters from the request/response. For example, you could reference {request.querystring.name} as a part of your backend URL or map them into a new header. To learn more about request and response transforms, see the Proxies documentation. Express export to PowerApps and Microsoft Flow App Service and Azure Functions now let you leverage your API from PowerApps and Microsoft Flow with just a few clicks. The Export to PowerApps + Microsoft Flow gesture has been expanded to include an express option, allowing you to do everything right within the Azure portal. The new gesture will prompt you to select an environment in which the API should be created. You will only be able to use this capability for environments in which you have create API permissions. If you don't have the right permissions, you can still use the \"Manual\" option to get your metadata and provide it to an environment administrator, who can create the API for you. As part of the express flow, you will also need to provide any security properties that are defined in your OpenAPI (Swagger) document. Note that API keys are currently not supported. If your API does require a key to be provided, you will need to configure this within PowerApps or Flow after exporting. Beyond that, it's as simple as clicking \"OK\" and seeing your custom API created instantly. This is a great complement to the recent preview of Swagger support for Functions. Now you can create, document, and publish an API to PowerApps and Flow all as a part of your normal Functions workflow. Providing feedback As always, we love getting feedback. Let us know how these features work for you, and if there are other parts of API development that could use improvement. You can always reach us in the Forums (App Service, Functions) or on UserVoice (App Service, Functions). ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/05/10/Azure-Functions-API-development-updates.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Connect Azure App Service to Azure database for MySQL and PostgreSQL via SSL",
+ "excerpt":" mksunitha 5/10/2017 8:10:26 AM Azure Database for MySQL (Preview) and Azure Database for PostgreSQL (Preview), both services support Secure Sockets Layer (SSL) encryption. By default if you create a MySQL or PostgreSQL server using this server SSL is required to connect to all databases on that server. With Web Apps , the application needs to provide the certificate authority (CA) is one that the client trusts for the connection to succeed. This involves a few steps . Follow the steps below to add SSL to an existing application on Azure App Service. Note: These instructions are same whether you are using Windows or Linux based Azure App Service. Follow the steps in this article on configuring SSL on Azure database for MySQL or PostgreSQL. Create a bin folder under D:/home/site/wwwroot and place the certificate (.pem file generated from step #1) in bin folder. You can do this directly by accessing the file server for web app using FTP or Git or Kudu . Log in to Azure portal. Select your existing Web app and click on Application settings. Add the following app setting for your web app: For MYSQL : For PostgreSQL : Now SSL certificate is added to your web application . Your application code needs to be updated to use this certificate authority when connecting to the database. Please refer to the documentation of your application framework on how to consume the certificate authority to connect to the database via SSL. Here are a few examples below. Connect to MySQL server with SSL for WordPress app Add the following to wp-config.php to connect to the MySQL database via SSL define('MYSQL_CLIENT_FLAGS', MYSQL_CLIENT_SSL); define( 'MYSQL_SSL_CA', getenv('MYSQL_SSL_CA')); Note: If you are using PHP 7.X version , you need another flag MYSQLI_CLIENT_SSL_DONT_VERIFY_SERVER_CERT for any PHP based application. For example with WordPress , you need to update MYSQL_CLIENT_FLAGS as shown below define( 'MYSQL_CLIENT_FLAGS', MYSQLI_CLIENT_SSL | MYSQLI_CLIENT_SSL_DONT_VERIFY_SERVER_CERT ); Connect to PostgreSQL server with SSL for Drupal app Add the following to site/default/settings.php and add PDO options for SSL $databases = array ( 'default' => array ( 'default' = array ( 'database' => 'databasename', 'username' => 'username', 'password' => 'password', 'host' => 'hostname', 'port' => '3306', 'driver' => 'mysql', 'prefix' => '', 'pdo' => array( PDO::PGSQL_ATTR_SSL_CA => getenv('POSTGRESQL_SSL_CA'), ), ), ); Connect to MySQL server with SSL for Drupal app Add the following to site/default/settings.php and add PDO options for SSL $databases = array ( 'default' => array ( 'default' => array ( 'database' => 'databasename', 'username' => 'username', 'password' => 'password', 'host' => 'hostname', 'port' => '3306', 'driver' => 'mysql', 'prefix' => '', 'pdo' => array( PDO::MYSQL_ATTR_SSL_CA => getenv('MYSQL_SSL_CA'), ), ), ); Connect to PostgreSQL server with SSL for Django app Add the following to settings.py and the options for SSL DATABASES = { 'default': { 'ENGINE': 'django.db.backends.postgresql_psycopg2', 'NAME': 'dbname', 'USER': 'dbuser', 'PASSWORD': 'dbpassword', 'HOST': 'dbhost', 'OPTIONS': { 'sslmode': 'require', 'ca':os.environ.get('POSTGRESQL_SSL_CA', '') }, }, } ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/05/10/Connect-Azure-App-Service-to-Azure-database-for-MySQL-and-PostgreSQL-via-SSL.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Create Django Web app with PostgreSQL",
+ "excerpt":" mksunitha 5/10/2017 8:00:57 AM This tutorial describes how to get started running Django on Azure Web Apps with Azure Database for PostgreSQL(Preview). Web Apps provides limited free hosting and rapid deployment, and you can use Python. Before you begin If you don't have an Azure subscription, create a free account before you begin. Deploy from Marketplace This blog post describes how to get started running a Django app with postgresql from Azure marketplace . This marketplace solution creates the following resources : Web Apps on Windows and Azure Database for PostgreSQL (Preview). Log in to the Azure Portal. Launch the Django + PostgreSQL template in the Azure marketplace to get started. Provide the necessary information for web app and database to be deployed. Name Description App Name Enter a unique app name for your **Web App Name**. This name is used as part of the default DNS name for your app <app_name>.azurewebsites.net, so it needs to be unique across all apps in Azure. You can later map a custom domain name to your app before you expose it to your users Subscription Select a Subscription. If you have multiple subscriptions, choose the appropriate subscription. Resource group Enter a resource group. A resource group is a logical container into which Azure resources like web apps, databases that is deployed and managed. You can create a resource group or use an existing one App Service Plan App Service plans represent the collection of physical resources used to host your apps. Select the Location and the Pricing tier. For more information on pricing, see App service pricing tier Server Name Enter a postgresql database servername Server admin login name Enter a postgresql database administrator username Server admin password Enter a postgresql database administrator password Version Azure database for PostgreSQL(Preview) currenlty supports PostgreSQL 9.5 version Pricing tier Choose Basic or Standard pricing tier. For more information on pricing, see App service pricing tier Database Name Enter a database name for your web app You can watch the progress by clicking the bell icon at the top of the portal page while the app is being deployed. When the web app creation is finished, navigate in the Azure portal to the resource group to view the web app and PostgreSQL server. Select the web app line and then click Browse. Develop your application The Django + PostgreSQL template contains the Django framework on top of which you can build your application. You can create an Django app using Kudu. To access Kudu , select your web app in the portal and click Advanced Tools -> Go . Click on Debug Console to access the CMD prompt. In the console run the following commands under wwwroot folder. env\\scripts\\python.exe env\\scripts\\django-admin.exe startapp myapp This will create myapp folder with starter Django app . For more details in Django app, see Get started with Django . Database configuration You can access the database information within Azure portal by clicking in Application settings -> Connection strings. It is best practice to use App Settings for storing your database information instead of hard coding it in your settings.py file. Create these app settings in Azure portal for your web app. Update DATABASES setting in local settings.py file in your application. to read from App Settings environment variables. DATABASES = { 'default': { 'ENGINE': 'django.db.backends.postgresql_psycopg2', 'NAME': os.environ.get('DATABASENAME', ''), 'USER': os.environ.get('DATABASEUSER', ''), 'PASSWORD': os.environ.get('DATABASEPASSWORD', ''), 'HOST': os.environ.get('DATABASEHOST', ''), 'PORT': '5432', } } Database Management Use PgAdmin PostgreSQL Client to manage your PostgreSQL server and database remotely. Django Poll application sample You can deploy your own app via GIT or use this sample Django-poll application. Fork this sample repository or download to locally to start using the sample. For more information to setup GIT, see Local Git Deployment to Azure App Service. Next Steps Django Documentation Python Tools for Visual Studio Documentation ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/05/10/Create-Django-Web-app-with-PostgreSQL.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Introducing Azure App Service Support Center",
+ "excerpt":" Apurva Joshi (AJ) 5/10/2017 8:35:13 AM “Why was my Web App down?” “How do I fix it?” These are the common questions with no easy answers. Wouldn’t it be nice if solutions on what to do next are readily available? The Azure App Service Support Center is the answer. You can access it via “Diagnose and solve problems” in the web app settings blade. There are many reasons why a web app could experience a downtime – for instance, platform service outages, application code bugs, CPU or memory exhaustion, new deployment having unknown bugs, app crashes, faulty VM instances, abnormal recycles, port or socket exhaustions, exceptions in code, thread exhaustions and many more. In this initial release of Azure App Service Support Center, we are optimizing for the following scenarios Service outages, platform health issues Abnormal CPU usage Abnormal memory usage Application code issues Platform Incidents In the case of a platform incident, your app may be affected. In such cases, Microsoft engineers will have already been engaged to resolve the issue. The “Diagnose and Solve problems” blade will highlight this scenario right away making isolating the issue obvious. Screenshot below is an example of such an incident. CPU and Memory Issues High CPU or Memory usage can cause your web app to have downtime. In this case, you can identify the specific instances and web apps consuming resources. Solutions for these issues include Advanced application restart – restart a specific web app process on a specific instance Restarting the web app – restart the web app on all instances Scale up – scale up to instances with larger memory and more CPU Screenshot below is an example of such an incident. Application code issue Often, issues within the application code are the cause of downtime. These could include bugs, race conditions, external dependencies or your web app throwing exceptions. The failed requests log analysis, threads analysis detectors can determine when failures are a result of an application issue or a result of a platform issue. As instructed in the screenshot below, remote profiling is the best way to troubleshoot application specific issues. Screenshot below is an example of such an incident. How does it all work? Under the covers, the user experience is powered by a big data solution, where we mine large amounts of platform and application data to perform intelligent pattern analysis algorithms and surface most relevant observations and problems. Internally we refer to these algorithms that perform analysis as “detectors”. Each detector analyzes the data and determines the appropriate solutions to fix your problem when it is happening. The “Solution” option will be displayed when our detectors have determined that there is a mitigation step you could take to recover your web app. In addition, the troubleshoot section contains other mitigation options as well as specific troubleshooting tools. The goal of this new self-service diagnostics blade is to answer the questions Why was my Web App down? and How do I fix it? The detectors will provide insights and solutions that enable users to quickly mitigate and diagnose any issues. As you continue to use self-serve diagnostics, we will be adding new detectors and improving the existing ones with richer data and solutions that are more precise. Full List of Detectors Service Health - This detector looks at ongoing and past service incidents. Whenever this happens, Microsoft engineers are engage very quickly and start working to solve the problem CPU Analysis - This detector can identify instances where there is high CPU usage. It can also determine the specific site process within the app service plan that is using the most CPU. Memory Analysis: This detector can identify instances where there is high Memory usage. It can also determine the specific site process within the app service plan that is using the most Memory. Failed Requests Analysis: This detector looks for requests with 5xx http status code, detailed error codes and win32 status codes. It tracks the request’s journey all the way to your application code. If errors are happening purely in application layer (not in platform pipeline) this detector provides suggestions on debugging application code Site deployments: This detector looks for web and kudu deployments as a possible cause for downtime. Site Crashes: This detector looks for abnormal terminations (crashes) of w3wp (application code) processes. Worker Availability: This detector gives you insights into whether the problem is happening on a specific instance, which could point to a resource constraint or another problem with that instance alone. Process Restarts: This detector considers possible reasons that could have caused the application code to restart (w3wp process). Process restarts can cause transient availability issues. Reasons for process restart include: user initiated, config updates, auto heal, resource contentions, etc. Site quota exceeded: This detector indicates when failures are a result of a site in Free or Shared SKU exceeding a quota. When sites exceeded quota limits, the platform turns it off temporarily. Port and Socket Exhaustion: This detector figures when an outbound network connection is rejected because of port exhaustion. Thread and Handle usage: This detector detects if there is abnormally high usage of threads or handles that could affect application’s uptime. We hope this initiative helps you isolate and root cause issues with your web apps easily. As always, please provide feedback by simply clicking on the smiley - feedback icon at top left corner of the blade. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/05/10/Introducing-Azure-App-Service-Support-Center.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Connecting existing Web App to Azure Database for MySQL (Preview)",
+ "excerpt":" mksunitha 5/16/2017 9:11:12 AM The following steps show how to connect your existing web app on Azure App Service running on MySQL in-app or other MySQL solutions in Azure to Azure database for MySQL (Preview). Before your begin Log in to the Azure portal . Create a MySQL database on Azure Database for MySQL (Preview) service . For details , refer to How to create MySQL database from Portal or How to create MySQL database using CLI. Firewall configuration Azure database for MySQL provides tighter security using Firewall to protect your data. When using this service with App Service Web Apps , you need to keep in mind that the outbound IPs are dynamic in nature . To make sure the availability of your web app is not compromised , we recommend to all the rule to allow ALL IPs as shown in the image below. Note: We are working with Azure database for MySQL (Preview) team for a long term solution to avoid allowing all IPs. You can explicitly add all the outbound IPs for your web app to MySQL server configuration . To learn more , see how to get outbound IPs for App Service. App service infrastructure tries to keep the outbound IPs the same as best as we can , but when recycle or scale operation occurs it may change since we add new machines on every region frequently to increase our capacity to server customers. If this changes , the app will experience downtime since it can no longer connect to the database. Keep this mind when choosing one of the option mentioned above. SSL configuration Azure database for MySQL (Preview) has SSL Enabled . If your application is not using SSL to connect to the database , then you need to Disable SSL on MySQL server. For details on how to configure SSL , See using SSL with Azure database for MySQL (Preview). Note that some applications frameworks may not support SSL , hence check your application framework documentation on whether to disable or enable SSL. Migrating from MySQL in-app database to Azure Database for MySQL (Preview) You can migrate MySQL in-app database to Azure database for MySQL (Preview) using Export feature. Note in order to use this feature to export the database , you need to : Disable SSL since the feature does not work with MySQL database connected via SSL. Allow all IPs is configured on your MySQL server App Service Back up and Restore features Currently backup and restore feature does not work with SSL enabled for Azure Database for MySQL (Preview). Disable SSL if you are planning to backup/restore the database using App service backup feature . Azure database for MySQL (Preview) also offers backup feature , for more details see here. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/05/16/Connecting-existing-Web-App-to-Azure-database-for-MySQL-(Preview).html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Wiki WordPress on App Service",
+ "excerpt":" mksunitha 5/16/2017 9:19:59 AM The Azure Marketplace provides a wide range of popular web apps developed by open source software communities, for example WordPress. The following table of content below will get started on running WordPress on App Service from creating , managing , configuring , performance and troubleshooting WordPress app. WordPress and Azure App Service What is WordPress? Create WordPress on App Service Managed MySQL solutions for WordPress How to purchase Azure Database for MySQL service MySQL in-app (local mysql) for App Service Connecting Existing web app to Azure database for MySQL Connect to Azure database for MySQL using SSL MySQL on Virtual machines (IaaS) Deploy a WordPress web app backed with MySQL replication cluster Build your own Master-Master MySQL Cluster using Percona Clusterand learn more on how to manage the cluster Deploy WordPress backed by MySQL replication cluster with master-slave configuration Migrating and Configuring WordPress Application Migrating WordPress Deploy your files to Azure web apps Export and Import MySQL Database to Azure database for MySQL (Preview) Use MySQL Workbench to export and importdatabase Export and Import to MySQL in-app database Custom domain for WordPress multisite Use Azure CDN with WordPress Troubleshooting WordPress Application How to troubleshoot your WordPress app Gather usage telemetry using Azure Application Insights service Run Zend Zray profiler against your web app to diagnose issues and performance Use Kudu Support portal to diagnose and mitigate issues in real time How to backup your web appand How to restore your web app Secure WordPress Enable WordPress logs WordPress tools for App service : WordPress Buddy+ Performance How to speed up WordPress web app How to enabled redis cacheusing redis cache plugin How to enable memcached object cache for WordPressusing memcached plugin Enable wincache with W3 total cache plugin How to use supercache plugin to speed up WordPress app How to server caching using IIS output caching How to enabled browser caching for static content WordPress Cron slowing down the app ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/05/16/Wiki-WordPress-on-App-Service.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Deploying Visual Studio 2017 Function Projects with VSTS",
+ "excerpt":" Donna Malayeri 6/1/2017 9:00:28 AM With the new Visual Studio 2017 support for Azure Functions, you can now author functions using C# class libraries. With the new project type, triggers and bindings are defined using attributes, which are then converted to function.json as a build task. To build the project on the server with continuous integration, you have two options: 1) the Continuous Integration feature of Functions, or 2) Visual Studio Team Services (VSTS). The code can be hosted on VSTS or an external service such as GitHub or Bitbucket. The process is quite easy, thanks to a new build template: ASP.NET Core on .NET Framework. If you’re not familiar with VSTS build definitions, read CI/CD for newbies. To create a build definition, do the following: From the Build Definitions view in VSTS, select +New. Choose the template NET Core (.NET Framework). Even though we’re not deploying an ASP.NET Core app, this template has the correctly configured tasks for a Functions project. Add a build task for Azure App Service Deploy. Ensure you use a VS2017 build agent Choose an Azure subscription and select your Function App under App Service name. Modify the Package or folder setting to use $(build.artifactstagingdirectory)/**/*.zip Save and queue the build. Here’s an animated GIF that walks through the VSTS configuration steps: ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/06/01/Deploying-Visual-Studio-2017-Function-Projects-with-VSTS.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "May 2017 App Service update",
+ "excerpt":" Byron Tardif 6/1/2017 5:01:06 PM Deployment Slot support for Azure Functions (preview) Azure functions now support creation of deployment slots, just like apps on App Service you can create slots and perform swap operations between slots. New Backup experience for apps on App Service We have revamped the backup experience to make it more streamlined and easier to configure. New Delete experience for apps on App Service The new Delete experience provides more information about what will be deleted and allows you to opt out of deleting the App Service plan when deleting the last app hosted in it. App Service support for Azure Database for MySQL and Azure Database for PostgreSQL App Service fully supports the new Azure Database for MySQL and Azure Database for PostgreSQL. You can get started using one of the following templates: Web App + PostgreSQL Web App + MySQL Web App On Linux + MySQL Web App on Linux + PostgreSQL If you have any questions about any of this features or App Service in general be sure to check our forums in MSDN and Stack Overflow. For any feature requests or ideas check out our User Voice ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/06/01/May-2017-App-Service-update.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "MySQL in-app feature for Web Apps on Linux",
+ "excerpt":" mksunitha 6/7/2017 11:10:51 AM MySQL in-app for Linux Web App is not the same as MySQL in-app feature for Windows Azure Web App . This applies to WordPress , Drupal , Joomla and Mediawiki Templates on Linux Web App . For Linux web apps , we leverage the docker container to build MySQL as part of the image used to deploy in the Azure portal, for example WordPress on Linux. These custom images are available on github. The image uses MariaDB 10.0+ server with the default port 3306 and is installed , configured when the docker image runs on the Linux web app. Get Database connection You can get the database information from the Azure portal. Select your web app , then select Application Settings -> App settings. This will list out the database information needed for your web application. Manage your Local database You can access and manage the database using PHPmyadmin that is enabled and configured as part of deployment of the docker image. To view PHPmyadmin tool ,use the URL in this format http://hostname/phpmyadmin and enter the credentials to connect. You can find the credentials for PHPmyadmin in the Azure portal . Select your web app , then select Application Settings -> App settings ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/06/07/MySQL-in-app-feature-for-Web-Apps-on-Linux.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Pick the right data solution for Azure App Service",
+ "excerpt":" mksunitha 6/8/2017 10:02:11 AM App Service makes building data driven solutions easier via the Azure portal. Azure app service supports various data solutions like SQL , MySQL etc. To help understand how these data solutions work with App Service (Web Apps, Mobile Apps, Functions) and pick the right solution based on your needs, view the table below. * Free Azure SQL DB offers one SQL Database per subscriptions limited to 32 MB for free for one year. ** Both Linux and Windows App service platforms support use of these data solutions , but based on your application framework you may require additional libraries in your application code to connect to the database. *** Currently App Service backup and restore feature does not support database connections over SSL. **** Azure Functions supports Azure SQL DB , MySQL and PostgreSQL via the .NET SDK of these respective data services. For cosmos DB you can use binding or the SDK. Azure SQL DB MySQL in-app Azure Database for MySQL Azure Database for PostgreSQL Cosmos DB Generally available ✓ ✓ Public Preview Public Preview ✓ Free Database Tier * ✓ ✓ Managed Database as a Service ✓ ✓ ✓ ✓ Remotely access database ✓ ✓ ✓ ✓ ✓ Documentation link link link link link Scalability ✓ ✓ ✓ ✓ Geo Replication ✓ ✓ SSL ✓ ✓ ✓ ✓ Firewall Configuration ✓ ✓ ✓ ✓ Database Sharding /Partitioning ✓ ✓ Pricing link link link link Region Availability link Linux Azure Web Apps ** ✓ link ✓ ✓ ✓ Windows Azure Web Apps ** ✓ link ✓ ✓ ✓ App service Backup and Restore *** ✓ ✓ ✓ ✓ Azure Mobile App ✓ ✓ Azure Functions **** ✓ ✓ ✓ ✓ ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/06/08/Pick-the-right-data-solution-for-Azure-App-Service.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Deployment Slots Preview for Azure Functions",
+ "excerpt":" Daria Grigoriu 6/13/2017 11:06:52 AM The Azure Functions Consumption Plan now includes a preview of deployment slots. Deployment slots are a valuable component of a cloud ready application development lifecycle. The feature enables development and production environment separation to isolate critical production workloads. At the same time deployment slots create a natural bridge between development and production where the next version of a Function App staged in a deployment slot can become the production version with a simple platform managed swap action. For more information on the deployment slots concept as used in the context of the broader App Service platform please see this documentation article. You can explore the deployment slots preview via Azure Portal. Each Function App includes a view of deployment slots. The preview requires a one-time opt-in for each Function App available under the Function App's Settings tab. Opt-out is not available, simply delete deployment slots if no longer necessary. After preview opt-in the Function App secrets will be updated. Please copy the new secrets under the Manage node for each function. You can add a deployment slot under the Slots view. For the Consumption Plan you can include 1 other slot in addition to production. Each deployment slot can be treated as a standalone Function App with its own URL, its own content, and differentiated configuration. That means even input and output bindings can be different and the non-production version can be evolved independently without production dependencies if this is a requirement for your specific workload. You can designate configuration elements such as App Settings or Connection Strings as slot specific to make sure they will continue to be associated with the same slot after swap: e.g. a production slot will continue to point to the same production specific storage account. To swap a non-production deployment slot to production use the Swap action under the Overview tab for your Function App. You can select the swap type as direct swap or a swap with preview where destination slot configuration is applied to the source deployment slot to allow validation before the swap is finalized. You can also see a configuration diff to make sure you are aware and can react to how configuration elements are impacted by the swap action. The deployment slots preview will continue to evolve in the journey to general availability. There are some current limitations such as a single instance scale for non-production deployment slots. If your production Function App is running at large scale this limitation may result in a timeframe where throughput is decreased as the platform re-adjusts the scale after swap. For any questions or issues to share with the engineering team regarding the deployment slots preview please use the Azure Functions MSDN forum. Follow us on Twitter for product updates and community news @AzureFunctions. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/06/13/Deployment-Slots-Preview-for-Azure-Functions.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Custom hostnames with App Service",
+ "excerpt":" akurmi 6/21/2017 11:47:11 AM Introduction App Service has been supporting custom hostnames for a while now, you can read about this feature here. App Service has a shared front-end so before you can use a custom hostname with your app, you need to verify domain ownership by creating the required DNS records. This is done to prevent hostname squatting vulnerability. To add a custom hostname to your app, you need to create DNS records for ownership verification and routing. Details There are a few ways to add custom hostnames, most commonly used methods are given below: CNAME: This is the recommended approach and easier of the two as it requires only one DNS record. To add a custom hostname using CNAME method, you need to create a CNAME record on the custom hostname pointing to the default hostname of the App. For example, if you want to add ‘support.api.contoso.com’ to a web app named ‘contoso’ then you should create a CNAME record on ‘support.api.contoso.com’ pointing to ‘contoso.azurewebsites.net’. In this case, the CNAME record is used for both, verification and routing. DNS Record Type Sub-domain Value CNAME support.api contoso.azurewebsites.net A with TXT: In certain scenarios, a customer may not able to create the required CNAME record. For example, a lot of DNS providers don’t allow CNAME record on the root hostname. In that case, a customer can use this verification method. This requires creating two DNS records on the hostname being added. For example, if a customer wants to add ‘contoso.com’ to a web app named ‘contoso’ then he should create: An A record on ‘contoso.com’ pointing to web app’s IP address. You can get this IP address from Azure portal or by resolving the default hostname locally. One of the convenient ways to resolve hostname is to simply ping it: ping contoso.azurewebsites.net. A record is used for routing traffic to your app. A TXT record on ‘contoso.com’ with value set to the default hostname. In this case, the value should be contoso.azurewebsites.net. TXT record is used for verification. DNS Record Type Sub-domain Value A @ <IP Address> TXT @ contoso.azurewebsites.net Recent updates We recently made the following two changes in our hostname management model: One to many associations between hostname and Azure subscription: Earlier, a hostname could only be used with one subscription on App Service platform. With this change, now a hostname can be shared by multiple subscriptions. Each subscription needs to validate the domain ownership separately by creating the required DNS records. Allowing a subscription to reclaim a hostname by validating domain ownership: App Service platform consists of multiple scale units. A hostname can only be associated with one app on a scale unit. Even two apps in the same subscription cannot share the same hostname on a scale unit. This is by design as App Service runtime should be able to resolve a custom hostname to an App uniquely. We have received multiple customer reported incidents in the past where a customer had a custom hostname in his old subscription that he could not access anymore for some reason and wanted to use the same hostname with another app on the scale unit. This was not allowed earlier even though the customer could revalidate domain ownership. With this change, now App Service customers can do this themselves. Apart from these two changes, I would also like to cover some of the most common domain related questions we receive our customers: Migrating a live custom hostname without any downtime If you would like to move a live custom hostname to App Service, then following the typical verification method would cause downtime between updating the DNS records and adding the corresponding hostname to your web app. If you would like to prevent the downtime, then you can use the alternate ‘awverify’ subdomain instead for verification. Say you would like to add ‘www.contoso.com’ to a web app named ‘contoso’ without any downtime. You can follow these steps to achieve this objective. Create a TXT record on awverify.www.contoso.com with value set to ‘contoso.azurewebsites.net’ for verification DNS Record Type Sub-domain Value TXT awverify.www contoso.azurewebsites.net Add the custom hostname through Azure portal. Once this is done, you can delete the TXT record created in step 1 if you want. Create a CNAME/A record on www.contoso.com to point it to ‘contoso.azurewebsites.net’. This would start routing traffic to your App Service App. DNS Record Type Subdomain Value CNAME www contoso.azurewebsites.net Or DNS Record Type Subdomain Value A www <IP Address> Adding the same custom hostname to multiple web apps There are scenarios where a customer would like to add the same hostname to multiple web apps in the same subscription, having a geo distributed website is one example. Our custom hostname feature allows you to bypass validation for hostnames that have already been validated. You only need to verify domain ownership when you add a hostname for the first time. For all other apps in the same subscription, you can add the same hostname without creating any DNS records. Programmatically manage custom hostnames We have updated our API surface to expose each custom hostname as a separate resource, giving App Service customers the ability to manage each hostname individually. A custom hostname is represented as ‘Microsoft.Web/site/hostnameBindings’ resource. For example, if you want to add ‘www.contoso.com’ to a web app called ‘contoso’ then first you need to create a CNAME record on this hostname pointing to ‘contoso.azurewebsites.net’. After that, you can add the hostname by calling the following ARM API: ARMClient PUT /subscriptions/fb2c25dc-6bab-45c4-8cc9-cece7c42a95a/resourceGroups/Default-Web-EastAsia/providers/Microsoft.Web/sites/contoso/hostnameBindings/www.contoso.com?api-version=2016-03-01 \"{'Location':'West US','Properties':{}}\" You can also use the following ARM template for adding custom hostnames: https://github.com/Azure/azure-quickstart-templates/tree/master/201-web-app-custom-domain ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/06/21/Custom-hostnames-with-App-Service.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Installing public certificates in App Service",
+ "excerpt":" akurmi 6/27/2017 2:10:45 PM Introduction Today, we are announcing the support for installing public certificates in personal certificate stores. We are currently building a user-friendly experience to expose this functionality via Azure portal. In the meantime, you can use ARMClient/Azure Resource Explorer/Azure PowerShell/Azure CLI for calling the corresponding backend APIs to use this feature right away. For this blogpost, I will be using ARMClient to demo these APIs. Details To support public certificates, we have created a new ARM resource type called ‘sites/publicCertificates’ under ‘Microsoft.Web’ resource provider. Each instance of this resource represents a certificate installed in your App Service. To install a public certificate, you can call the following PUT API on an existing App Service: ARMClient PUT https://management.azure.com/subscriptions/fb2c25dc-6bab-45c4-8cc9-cece7c42a95a/resourcegroups/publiccertificaterg/providers/Microsoft.Web/sites/publiccertificatedemo/publicCertificates/currentuser1?api-version=2016-02-01 \"{'Properties':{'Blob':'MIIC/zCCAeugAwIBAgIQjngbV7+4eppN1YUvFh8guDAJBgUrDgMCHQUAMBgxFjAUBgNVBAMTDXRlc3RjZXJ0MS5jb20wHhcNMTcwNDAzMjIyMTI1WhcNMzkxMjMxMjM1OTU5WjAYMRYwFAYDVQQDEw10ZXN0Y2VydDEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAiq+O7aP68Q5uCr0u0fRlOCXpIYw498Yk2sxdR3ElgF+nD8pmgdrAbGaGlBcxO0i/YrITgD5n73BBL17QPFNx7Y8mHl3U7vOAYkYHVZQlJVc8XPmjmgL6ZGSquPkJhev9vg1U26mJHdjoOprN2dSZIKw7VB+DbBgHipjFsaxe99GocQeQxNoa93wu7uWRgI0foKgYgDBEWbyMSgT6ZXQUwoQVNTDSPmQ8PlNrAOJz3cLM6jp0e0ZKDPJEqRXm3UX6F7DcOR0G7OvUil56Ze9ANNcF2bTwTpdCLPx2OImnKCeb5Vyxg9Ymtu3aAm9U5qX8pXAZu+oU5NAiJx1TvlJkPQIDAQABo00wSzBJBgNVHQEEQjBAgBCqtQL/bkUvJkvip2NwKuuPoRowGDEWMBQGA1UEAxMNdGVzdGNlcnQxLmNvbYIQjngbV7+4eppN1YUvFh8guDAJBgUrDgMCHQUAA4IBAQA9y0GjiioOMjKFLJAqFoePeW2/MH+8QAJYvsmchZ5J8gq4TrpKbw2xrIuHmRmHv+hNAGGMGNoPg9JHHk8YuHCvaNM/10HGu0xHzgG7sEui/3MA7jAbMHQOaE54G4HiBVVFabo6li7WjSsx+RjlxNPtb+GMcBoDBAXcbzBmj/1BPNyrlwdBZHpwwnZBJpH+xHWXwIyyqBBAtQiXv7SSV79bwxPRhvCH6rhF8e0qXNGFHIDTiuDol8+eBBiGOEDwB79zDWLlvbXxKxxtQq2KqKhiLntLs1f9tohF6ad7HN5nK1RLPmqC/hoYA+/Fx5jpoX/pQo3Vlf3KMsr1280JSqq8','publicCertificateLocation':'CurrentUserMy'}}\" Parameters: /subscriptions/…/sites/publiccertificatedemo: Resource Id of the App Service that would be using the public certificate. This App Service needs to be in a dedicated App Service Plan. publicCertificates/currentuser1: User friendly name of the ‘sites/publicCertificates’ resource that represents this public certificate. blob: Base 64 encoded .cer file that contains a public certificate. publicCertificateLocation: Location in Windows certificate store where this certificates would be installed. We only support 'CurrentUserMy' for public scale units. If your site is inside an App Service Environment, then you can also use ‘LocalMachineMy’. I have written a simply asp.net page that lists all certificates in CurrentUser-Personal certificate store. protected void Page_Load(object sender, EventArgs e) { var store = new X509Store(StoreName.My, StoreLocation.CurrentUser); store.Open(OpenFlags.ReadOnly); foreach (var certificate in store.Certificates) { Response.Write(string.Format(\"Subject:{0} Thumbprint:{1} SerialNumber:{2} HasPrivateKey:{3} <br />\", certificate.Subject, certificate.Thumbprint, certificate.SerialNumber, certificate.HasPrivateKey)); } store.Close(); } Here is a screenshot of this App Service after executing the ARM client command shared above. Similarly, we can execute the following ARMClient command to install another public certificate in CurrentUser-Personal certificate store: ARMClient PUT https://management.azure.com/subscriptions/fb2c25dc-6bab-45c4-8cc9-cece7c42a95a/resourcegroups/publiccertificaterg/providers/Microsoft.Web/sites/publiccertificatedemo/publicCertificates/currentuser2?api-version=2016-02-01 \"{'Properties':{'Blob':'MI…nc','publicCertificateLocation':'CurrentUserMy'}}\" Since ‘sites/publicCertificates’ is an ARM resource, you can call other standard ARM APIs to perform CRUD operations. List all public certificates inside an App Service: ARMClient GET https://management.azure.com/subscriptions/fb2c25dc-6bab-45c4-8cc9-cece7c42a95a/resourcegroups/publiccertificaterg/providers/Microsoft.Web/sites/publiccertificatedemo/publicCertificates?api-version=2016-02-01 Remove a specific public certificate: ARMClient DELETE https://management.azure.com/subscriptions/fb2c25dc-6bab-45c4-8cc9-cece7c42a95a/resourcegroups/publiccertificaterg/providers/Microsoft.Web/sites/publiccertificatedemo/publicCertificates/currentuser2?api-version=2016-02-01 ARM Template You can use the following ARM template for installing a public certificate inside an existing App Service. https://github.com/Azure/azure-quickstart-templates/tree/master/201-web-app-public-certificate Getting in touch Please give this feature a try and let us know your thoughts. If you run into any issues or have any comments then please let us know on the App Service forum. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/06/27/Installing-public-certificates-in-App-Service.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "FAQ Azure marketplace for Web Apps",
+ "excerpt":" mksunitha 6/29/2017 6:36:46 PM Here is a list of frequently asked questions designed to provide a better understanding of the Azure marketplace for Web How do I submit my Web Application to Windows Web Application Gallery? A. You can submit your application here. Before you submit the application please read through the guidelines and process for submission in this article. Why is Deployment option connected to a github repository when I deploy an application like WordPress from the marketplace? A. The deployment process for application from the marketplace uses a GIT deployment method. This makes it easier for app owners to push updates to the application as quickly as possible and have it available to Azure users. Hence we use a github repository configured by the app owner with the application code that is deployed during provisioning of the application. How long does it take for the Web Application Gallery Team to validate the application? A. Once the application is submitted, it will take 3-5 business days for us to validate the application and send you the status. How do I build a package for Web Application Gallery? A. Please refer to this article on how to to build a package for Azure marketplace. How do I test my application for Windows App Gallery? A. Find the process to test your application in the following article. Can I on-board a commercial application to the Azure marketplace? A. Yes. Commercial application are supported with Bring your own License model (BOYL). Here are two approaches on how to allow an azure user to acquire a license: Approach 1 : Ask customer to purchase an license from solution partner website directly. Provision the application solution from the Azure Marketplace When user views the app in the browser ask user to enter the license information Solution partner API are called to validate the license key and allow the user to use the application solution as documented by the solution partner Approach 2 : Provision the application solution from the Azure Marketplace When user views the app in the browser the app ask the user to provide the information needed to procure a license key from the run time experience using solution partners APIs. An application was removed from the marketplace and how do I deploy the same solution? A. If an application is removed from the marketplace , this means it is no longer supported by the application owner in the marketplace. In such cases we remove the application if it does have support from the application owner to maintain fixes or issues. If you want to deploy the same application , you can. Follow these steps to do so : Create an empty Web App and any additional resources such as MySQL , SQL DB etc that the application may need. Access the web application file storage and deploy the code via FTP or GIT. Browse the application and complete the installation of the application based on the documentation provided in the application framework documentation. If you run into issues , please report these issues in the community forums for the application being used . ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/06/29/FAQ-Azure-marketplace-for-Web-Apps.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "June 2017 App Service update",
+ "excerpt":" Byron Tardif 6/30/2017 3:14:58 PM This month we shipped improvements to the overview blade, a new unified create experience for both Windows and Linux based apps as well a new recommendation history UX. New App Service Overview blade The overview blade for Web, Mobile and API apps has been overhauled with new charting controls and performance improvements, this should make browsing through your apps faster. The new charts integrate nicely with Azure Monitor and are perfect for pinning into custom dashboards. Integrated create experience for Windows and Linux based apps With this update you can now choose the OS of the App Service plan used to host your app. Learn more about Web App on Linux. App Service Advisor recommendation history App Service Advisor provides proactive recommendations on how to solve problems with your application. We have revamped this UI to also include a history of the recommendations that have triggered in the past. If you have any questions about any of this features or App Service in general be sure to check our forums in MSDN and Stack Overflow. For any feature requests or ideas check out our User Voice ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/06/30/June-2017-App-Service-update.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Alpha Preview for Durable Functions",
+ "excerpt":" Chris Anderson (Azure) 7/6/2017 9:13:39 AM Last week, we open sourced an early preview version of our new Durable Task Framework extension for Azure Functions (also referred to as Durable Functions) and we now have instructions on how to set it up to test both locally and on Azure. We’re really excited about this binding and expect it to make a difference a lot of scenarios including complex chaining scenarios, fan in/fan out patterns, stateful actors, and scenarios with long callbacks. Introducing Durable Functions Durable Functions is actually just us doing the work of setting up the Durable Task Framework and managing it for you, at scale. Durable Task Framework was designed to allow you to write code based orchestrations based on async/await in C#. This enabled the following: Definition of code in simple C# code Automatic persistence and check-pointing of program state Versioning of orchestrations and activities Async timers, orchestration composition, With Durable Functions, we let you write orchestrators and activities as Functions. Orchestrators can call Activity Functions and wait for an external event. Activity Functions can be written in any language and don’t have any restrictions on them that normal functions don’t have. Combined, this functionality allows a lot of complex patterns to be expressed via code. For instance, the code below will fan out and call various Activity Functions, wait for them all to complete, and then allow you to sum the results (fan in). This pattern was possible before, but involved a lot more code that was unrelated to the business logic. [code lang=\"csharp\" highlight=\"18,23\"]#r \"Microsoft.Azure.WebJobs.Extensions.DurableTask\" public static async Task<long> Run(DurableOrchestrationContext backupContext) { string rootDirectory = backupContext.GetInput<string>(); if (string.IsNullOrEmpty(rootDirectory)) { rootDirectory = Environment.CurrentDirectory; } string[] files = await backupContext.CallFunctionAsync<string[]>( \"E2_GetFileList\", rootDirectory); var tasks = new Task<long>[files.Length]; for (int i = 0; i < files.Length; i++) { tasks[i] = backupContext.CallFunctionAsync<long>( \"E2_CopyFileToBlob\", files[i]); } await Task.WhenAll(tasks); long totalBytes = tasks.Sum(t => t.Result); return totalBytes; } [/code] In the above code, you can see the highlighted lines fanning out and calling many Functions (18), and then waiting for them all to complete on the second highlighted line (23). Getting started This is not a feature for everyone to try. It involves quite a lot of set up and is not very user-friendly yet. We recommend using VS and the local tooling to get started as it is the easiest way, but it requires installing the latest update from VS and the newest Functions tooling, which can take some time to set up. You can find the full instructions on how to get started on the documentation page. Note that the documentation is currently on GitHub but will move to docs.microsoft.com very soon. If you encounter any issues or have any feedback, please submit it on the github repo. Roadmap There are a few things we’re still working on before it will be available for a beta quality preview. We’ll blog again once it’s available for a wider preview. Mainly, we are already planning on adding: Templates for all the primary scenarios Scaling support in Consumption Plan (will not scale properly today) Automatic installation (no dragging/dropping zip files) We hope to make progress on this during the rest of the summer. What’s next? For the brave, please try it out. Your feedback will shape the future of this feature. We think having built in support for Functions to call other Functions and orchestrate a set of Functions is a very big step forward for Azure Functions and serverless in general, but want to take our time to make sure we get the model right and the experience of managing it nice and polished. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/07/06/Alpha-Preview-for-Durable-Functions.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Azure Web App PHP updates",
+ "excerpt":" Donna Malayeri 7/10/2017 1:16:26 PM PHP updated to latest versions Azure App Service has updated the PHP stacks to the latest available versions. For information on the changes in the new versions, please see the change logs on the PHP website. PHP Version Change log 5.6.31 http://www.php.net/ChangeLog-5.php#5.6.31 7.0.21 http://www.php.net/ChangeLog-7.php#7.0.21 7.1.7 http://www.php.net/ChangeLog-7.php#7.1.7 ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/07/10/Azure-Web-App-PHP-updates.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "FAQ SSL certificates for Web Apps and App Service Certificates",
+ "excerpt":" mksunitha 7/24/2017 11:06:00 PM Here is a list of commonly asked questions for App Service Certificates. How do I purchase and configure a new SSL certificate in Azure for my web app? To learn how to purchase and set up an SSL certificate for your App Service web app, see Add an SSL certificate to your App Service app. I am unable to purchase an SSL certificate or App Service certificate ? This could be caused due to one of the following reasons: App Service plan is Free or Shared pricing plans. We do not support SSL for these pricing tiers. Subscription does not have a valid credit card Subscription offer does not support purchase an App Service certificate such as Microsoft Student offer Subscription has hit the maximum limit of purchases allowed on a subscription App Service certificate was marked as fraud. You will see this error “Your certificate has been flagged for possible fraud. The request is currently under review. If the certificate does not become usable within 24 hours” Try any of these solutions based on the cause Upgrade App Service plan to Standard Pricing tier for Web App Add a valid credit card to your subscription if you don’t have one If you are using Microsoft Student subscription or other Azure subscriptions where App Service certificate is not supported, please upgrade your subscription App Service Certificates has a limit of 10 certificate purchases for Pay-As-Go and EA subscriptions types and for other subscription types the limit is 3. To increase the limit Kindly share the following details with us if you want to increase the purchase limit on your subscription for certificates: Please articulate the business reason for increasing the purchase limit on your subscription. Monthly spending cap on this subscription if any Does the subscription have a valid credit card associated with the subscription We shall review and evaluate your business needs internally to either approve or reject your request provided there are no other constraints to meet these needs for you. If the certificate is marked as Fraud and has not been resolved after 24 hours , then follow the steps below : Go to App Service certificate in Azure portal Click on Certificate Configuration -> Step 2 : Verify -> Domain Verification Click on Email Instructions which will send an email to GoDaddy to resolve the issue When does my certificate get renewed? App Service certificates are valid for one year. If Auto Renew is on for an ASC then it will be renewed automatically before it expires and just like ReKey operation, the linked App Service Apps will be moved to the new certificate. You can change this setting by clicking on ‘Auto Renew Settings’ which is on by default. You can also manually renew a certificate by clicking on Manual Renew irrespective of the current Auto Renew setting if the certificate expiration is within 90 days. How can I Rekey and/or ReSync my app service certificate? In order to stay compliant, many web companies need to rotate their certificates periodically. Also if a customer believes that his certificate has been compromised then he should rotate the certificate as soon as possible to minimize likelihood of the stolen certificate being used for malicious purposes. Traditionally, this requires obtaining a new certificate from the CA which is as complicated as buying a new one. Once a new certificate is created, you need to update all App Service Apps one by one manually. With ASC, we support one click ReKey. ASC allows you to ReKey a certificate unlimited number of times during its lifetime for free. Using Rekey and Sync option in the portal : This blade displays the current sync state. You can see the thumbprint of ASC along with the thumbprints of all App Service linked certificates. When these certificates are in sync, all thumbprints will match and when they are out of sync, one or more linked certificate thumbprints will be different from the ASC thumbprint. In order to rotate the certificate, click ReKey at the top. The ASC status will move to Rekey Certificate which may take 5-10 minutes. You dont have to click on Sync since a background task runs every 8 hours to sync the changes in the certificate. To force a sync , you can click on the Sync button . I see certificate errors shown when enforcing HTTPS? If your web app gives you certificate validation errors, it could be due to : Using a self-signed certificate : In this case avoid using Self signed certificate since we cannot verify the domain ownership . This is not supported with Azure web apps Missing intermediate certificates when you export your certificate to the PFX file : In this case , recreate the PFX file and follow guidance here to make sure intermediate certiificates are also included when exporting it in PFX format. Domain host name is not added to the Web app: Please add the domain hostname to your web app as per instructions here If using App Service certificate domain verification is not completed : In this case , your certificate is not ready to be used. Please complete domain verification step as described here. Can I get the intermediate certificates for mysite.azurewebsites.net We support HTTPS on *.azurewebsites.net domain name. Since this domain is owned by App Service Team , we do not share the certificate information with users for security reasons. We recommend to use a custom domain and bring your own certificate for a production application. Domain verification is not working for App service certificate ? We provide alternate solution to manually verify your domain . Manual verification lets you verify domain ownership through your DNS configuration by adding a TXT record. Follow these steps to complete Manual verification : Go to the Domain Name Service (DNS) provider for your domain name Add a Txt record for your domain with value of the domain token showed in the portal . Wait a few minutes for DNS propagation to take place and click on Refresh button to trigger the verification. Alternate method to manually verify is the Html Web Page method which can be used to allow the certificate authority to confirm the domain ownership of the domain the certificate is issued for. Create an HTML filenamed {Domain Verification Token}.html. Content of this file should be the value of Domain Verification Token. Upload this fileat the root of the web server hosting your domain Click on Refresh button to check the Certificate status. It might take few minutes for verification to complete. For example, if you are buying a standard certificate for azure.com with Domain Verification Token ‘1234abcd’ then a web request made to http://azure.com/1234abcd.html should return 1234abcd. Important notice : A certificate order has only 15 days to complete domain verification operation, after 15 days the certificate is denied by the certificate authority, you are not charged for the certificate. Please delete this certificate and try again. My SSL certificate is not being auto-renewed ? All App Service certificates issued prior to March 31st 2017 will receive an email to re-verify their domain at the time of renewal even if the auto-renewal is enabled for your certificate.This is a result of change in GoDaddy policy. Please check your email and complete this one-time domain verification to continue to auto-renew the SSL certificate. Also , note that GoDaddy does require you to verify your domain once every three years and you will receive a email once every three years to verify your domain. Can I bring my own SSL certificate and how do I upload/configure it for my web app? Yes , you can bring your own SSL certificate. To learn how to upload and set up an existing custom SSL certificate, see Bind an existing custom SSL certificate to an Azure web app. My App Service certificate is flagged for fraud. How do I resolve this? During the domain verification of an App Service certificate purchase, you might see the following message: “Your certificate has been flagged for possible fraud. The request is currently under review. If the certificate does not become usable within 24 hours, please contact Azure Support.” As the message indicates, this fraud verification process might take up to 24 hours to complete. During this time, you'll continue to see the message. If the certificate is marked as Fraud and has not been resolved after 24 hours , then follow the steps below : Go to App Service certificate in Azure portal Click on Certificate Configuration -> Step 2 : Verify -> Domain Verification Click on Email Instructions which will send an email to GoDaddy to resolve the issue . My App Service Certificate is still showing old secret value. How can I force a sync with the new secret in my Key Vault’ ? You can rekey your certificate using a new private key by following the details instructions in this article. How do I buy EV SSL for using with Azure web app App Service certificate does not support purchasing EV SSL from Azure portal. But there are other options to use EV SSL with Web apps. For details , click here Can I export my App Service certificate for use with other Azure services such as Cloud Services and so forth? We've gotten a lot of feedback from customers asking for this ability, so we now allow you to export your certificate as a PFX file so that you can use it across multiple subscriptions and Azure services. See this blog post for more information. Can I export my App Service certificate to be used outside of Azure, such as for a website hosted elsewhere? App Service Certificates can be used for any Azure or non-Azure Services and is not limited to App Services. To do so , you need to create a local PFX copy of an App Service certificate that you can use it anywhere you want. For more information, read Creating a local PFX copy of an App Service Certificate. Can I use my App Service certificate in a different subscription in Azure? You can migrate your App Service Certificate within the Azure portal. You can also export it as a PFX file for use in another subscription. See this blog post for more information. I have a Free or a DreamSpark Azure subscription. Can I purchase an App Service certificate with my credits? Because Free and DreamSpark Azure credits are free credits, they cannot be used to purchase App Service certificates. Can I get a refund if I purchase an SSL certificate and then decide that I no longer need it? Unfortunately, we cannot refund you on the purchase of an SSL certificate. How do I update an SNI or IP based SSL binding on web app ? Note : When the binding is updated , please wait for 24 hours for the change to reflect in the Azure portal . To avoid downtime with your web app , make sure you updated the binding for SSL at least a week prior to the expiration of your current SSL certificate. Login to the Azure portal and select your web app. To update and SSL binding : Upload a new certificate Click \"Add binding\" in SSL certificates setting for your web app Select your domain Select your certificate Click Add binding. Note that by adding an SSL binding with a hostname used in another binding will override the existing binding. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/07/24/FAQ-SSL-certificates-for-Web-Apps-and-App-Service-Certificates.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Assign App Service domain to Azure VM or Azure Storage",
+ "excerpt":" mksunitha 7/31/2017 10:16:06 AM App Service domains (preview) simplifies to create and manage domains for various Azure services. App Service domains leverages Azure DNS for hosting the domain and GoDaddy as the domain registrar.In addition to the domain registration fee, usage charges for Azure DNS apply. For information, see Azure DNS Pricing. This tutorial shows you how to buy an App Service domain and assign DNS names a Virtual machine and Azure Storage Sign in to Azure Open the Azure portal and sign in with your Azure account. Navigate to the app in the Azure portal From the left menu, select New -> Everything -> App Service Domain (preview) Purchase a domain In the App Service Domain page, in the Search for domain box, type the domain name you want to buy and type Enter. The suggested available domains are shown just below the text box. Select one or more domains you want to buy. Click the Contact Information and fill out the domain's contact information form. When finished, click OK to return to the App Service Domain page. Next, select the desired options for your domain. See the following table for explanations: Setting Suggested Value Description Subscription Pay-As-You-Go Select a Subscription. If you have multiple subscriptions, choose the appropriate subscription. Contact Information Enter your contact information such as address, phone number etc .. Fill out the domain's contact information form. When finished, click OK to return to the App Service Domain page. Resource Group myprojectgroup Enter a resource group. A resource group is a logical container into which Azure resources like web apps, databases that is deployed and managed. You can create a resource group or use an existing one Auto renew Enable Renews your App Service Domain automatically every year. Your credit card is charged the same purchase price at the time of renewal. Privacy protection Enable Opt in to \"Privacy protection\", which is included in the purchase price for free(except for top-level domains whose registry do not support privacy protection, such as .co.in, .co.uk, and so on). Accept terms and purchase Accept Click Legal Terms to review the terms and the charges, then click Buy. Assign domain to Azure Virtual machine Resource Manager VMs can have a Public IP. A VM with a Public IP address may also be behind a load balancer. You can create a DNS A or CNAME record for the Public address. This custom name can be used to bypass the VIP on the load balancer. To verify if you VM has a public IP , go the resource group used by the VM to see if you have a resource \"Public IP address\" . You can get the IP address by selecting the Public IP address resource or select your Virtual machine to get the IP address Select your domain and choose DNS Zone setting Click on Add a Record Set . Add an A record for your Public IP configured to a subdomain alias such as www or blog as shown below. Configure your TTL setting on when your domain should resolve to the new domain hosting service. Enter your domain in a browser address bar based on your TTL configuration. Add Custom domain for Azure storage Create an App Service Domain . Once provisioned , select DNS Zone setting and Add a record set . Create a new CNAME record and provide a subdomain alias such as www or images. Then provide a host name, which is your Blob service endpoint, in the format my-storage-account-name.blob.core.windows.net (where my-storage-account-name is the name of your storage account). Go to your storage resource in the Azure portal and select Custom Domain setting. In the text box on the Custom domain blade in the Azure portal, enter the name of your custom domain, including the subdomain. For example, if your domain is example.com and your subdomain alias is www, enter www.example.com. If your subdomain is images, enter images.contoso.com. The subdomain is required. Click on Save. Access your files on Azure storage using the custom domain. Auto Renew your Domain You can change your billing setup for your domain registration anytime to either enable or disable auto-renew by selecting Domain Renewal setting App Service domains can be used to setup domain for other Azure services as stated in this article. Note : The hostname bindings setting only shows Web Apps and Traffic Manager if confugred to your domain for now. Your VM or Storage or any other Azure service using this domain will not show up in hostname binding setting. We will continue to work on improving this experience to display other services assigned to the domain. Submit your ideas/feedback in UserVoice. Please add [Domain] at the beginning of the title. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/07/31/Assign-App-Service-domain-to-Azure-VM-or-Azure-Storage.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "July 2017 App Service update",
+ "excerpt":" Byron Tardif 7/31/2017 3:47:02 PM This month we rolled out a few major releases for App Service: Public preview for new App Service Environments (ASEv2) New app service environments offer: faster scale operations, simplified management, more powerful instances (backed by Dv2-series VMs ) amongst may other improvements. Learn more about App Service Environments v2 Public preview for new App Service Premium tier (Premium V2) The new Premium V2 tier features Dv2-series VMs with even faster processors, SSD storage, and double the memory-to-core ratio compared to the previous compute iteration. Learn more about App Service Premium v2 Preview New App Service Domains Experience The ability to buy and assign custom domains to you App Service apps has existed in the portal for some time, however we have now extended those domain to be full on managed resources with their own UX independent of the app. App Service Domains are now also backed by Azure DNS making it easier to use App Service Domains with IaaS instances, Traffic Manager Azure CDN. Learn more about App Service Domains If you have any questions about any of this features or App Service in general be sure to check our forums in MSDN and Stack Overflow. For any feature requests or ideas check out our User Voice ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/07/31/July-2017-App-Service-update.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "FAQ App Service Domain and Custom Domains",
+ "excerpt":" mksunitha 8/8/2017 11:58:41 PM Here are most frequent questions asked about App Service domains . Custom Domains How do I resolve 404 error \"Web Site not found\" when I browse my site ? You are seeing this error due to one of the reasons listed below : The custom domain configured is missing a CNAME and/or A record . To configure the domain to your app, see how to map an existing domain . If you added an A record , make sure a TXT record is also added. For more details , see here The browser client might still be caching the old IP address for your domain. Clear the cache by running the command ipconfig /flushdns . Verify your domain is pointing to the web app IP address using WhatsmyDNS.net . I am unable to add a new sub-domain ? One of the following reasons might be preventing you from purchasing a domain Check you have permissions to modify the web app and add a sub domain hostname You may have reached the max limit for subdomains . You can add max of 500 hostnames to your web app. You may have reached max limit for sub-domains if you are using GoDaddy domain hosting. The current limitation if using GoDaddy is 100. If you need more sub-domains , you may choose to migrate to Azure DNS Can I move my web app with a custom domain to another subscription or from ASE V1 to ASE V2? Yes you can move your web app across subscriptions . Follow the guidance in How to move resources in Azure . There are a few limitations when moving the web app , click here to view the limitations. For domains attached to your web app , if they are already added to your web app with a hostname binding then after moving the web app you should see the same host name binding within custom domains setting. No additional steps needed here. Unable to add custom domain to my Web app ? This could be due one of the following reasons: You don’t have permission to add a hostname : Check with subscription admin to make sure you have a permissions to add a hostname Your domain ownership could not be verified : If domain ownership is failing , verify if your CNAME or A record are configured correctly . To map custom domain to web app , create either a CNAME or A Record . If you want to use root domain , you must use A and TXT records as well Your domain is not available to use : You can use the custom domain with one web app , say for example www.mydomain.com can be added to one azure web app . In order to use the same the domain with another web app , you need to use another subdomain say xyz.mydomain.com but you CANNOT use www.mydomain.com . You see the error \"The DNS record could not be located\" One of the reasons could be causing the issue: TTL live has not expired. Check you DNS configuration for your domain what TTL is and wait it out. DNS configuration is not right Try one of these solutions to resolve the issue Wait for 48 hours and this should automatically resolve. If you can modify the TTL setting in your DNS configuration , go ahead and make the change to 5 minutes or so to see if this resolves the issue Verify your domain is pointing to the web app IP address using net. If not fix the A record to be configured to the right IP address of the web app App Service Domains I am unable to purchase a new Domain ? One of the following reasons might be preventing you from purchasing a domain Check you credit card on the Azure subscription is still valid If you are not the subscription owner , check you have permissions to purchase a new domain. (i.e Contributor or Owner roles ) You may have reached the limit to purchasing domains on your subscription. The current limit is 20. Do I have to configure my custom domain for my website once I buy it? When you purchase a domain from the Azure portal, the App Service application is automatically configured to use that custom domain. You don't have to take any additional steps. Watch how to configure domain on Channel9. You domain is no longer visible in the Azure portal or Domain was accidentally deleted The domain may have been accidentally deleted by the owner of the subscription. If your domain was deleted less than 7 days ago , the domain has not yet started the deletion process. Hence you can buy the same domain again on Azure portal under the same subscription (make sure to type the exact domain name in search text box). You will not be charged again for this domain. If the domain was deleted more than 7 days ago , please contact Microsoft Azure support for assistance to restore the domain. Can I use a domain purchased in the Azure portal to point to an Azure IaaS VM instead? Yes you can point the domain to an IaaS VM , Storage etc . See How to assign domain to a Virtual machine or Azure Storage. Is my domain hosted by GoDaddy or Azure DNS? You domain is registered with GoDaddy service but hosted on Azure DNS I have auto-renew enabled but still received a renewal notice for my domain via email . What should I do ? You do not need to take any action in this case if you have auto -renew enabled . The notice email if to just inform you that the domain is close to expiring and to renew manually if auto-renew is not enabled. Will I be charged for Azure DNS hosting my domain ? The initial cost of domain purchase applies to domain registration only. In addition to the registration cost , there will be incurring charges for Azure DNS based on your usage. See Azure DNS pricing for more details. I purchased my domain earlier from the Azure portal and want to move from GoDaddy hosting to Azure DNS hosting . How can I do this ? It is not mandatory to migrate to Azure DNS hosting. If you do wish to migrate to Azure DNS , you will see a message in domain management experience within the Azure portal about next steps to move to Azure DNS. Migration from GoDaddy hosting to Azure DNS is a few clicks away and seamless as long as the domain was purchased from App Service. I would like to purchase my domain from App Service Domain but can I host my domain on GoDaddy instead of Azure DNS? For every new App Service domain purchased in the portal since July 24 2017 , will be hosted on Azure DNS. If you prefer to choose a different hosting provider , you need to go to their website to procure domain hosting solution. Do I have to pay for privacy protection for my domain? When you purchase a domain through the Azure portal, you can choose to add privacy at no additional cost. This is one of the benefits of purchasing your domain through Azure App Service. If I decide I no longer want my domain, can I get my money back? When you purchase a domain, you are not charged for a period of 5 days, during which time you can decide that you do not want the domain. If you do decide you don't want the domain within that 5-day period, you will not be charged. (.uk domains are an exception to this. If you purchase a .uk domain, you will be charged immediately and you cannot be refunded.) Can I use the domain in another Azure App Service app in my subscription? Yes. When you access the Custom Domains and SSL blade in the Azure portal, you will see any domains that you have purchased and you can configure your app to use any of those domains. Can I transfer a domain from one subscription to another subscription? You can move a domain to another subscription/resource group by using 'Move-AzureRmResource' PowerShell cmdlet. How can I manage my custom domain if I don't currently have an Azure App Service app that is not a free app? You can manage your domain even if you don't have an App Service Web App. Domains can be used for Azure services like Virtual machine, Storage etc . If you intend to use the domain for App Service Web Apps , then you need to include a Web App that is not on the Free App Service plan in order to bind the domain to your web app. How can I transfer my domain out of Azure Follow the steps below to transfer out the domain Login to Azure portal Select your App Service domain that you wish to transfer out Go to Advance management for the domain Click your domain -> manage Under \"Additional Settings\" a. Unlock your domain . Click on Edit for \"Domain lock\" and turn it Off. b. Click on Transfer domains away from Azure to follow instructions to transfer out . ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/08/08/FAQ-App-Service-Domain-and-Custom-Domains.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "New tabbed experience for Azure Functions UX",
+ "excerpt":" Byron Tardif 8/8/2017 4:19:41 PM Today we are releasing a new tabbed experience for Azure Functions that lets you quickly navigate between multiple features when you are configuring your application. This new experience was developed as part of the Azure Functions UX open source project with input from Azure Functions MVP community. As part of the efforts to be more customer driven we also opened this feature up in preview through @azurefunctions Provide feedback on a new #AzureFunctions portal feature! Survey has link to both UI options. https://t.co/oCUBaanQxK pic.twitter.com/YyVSQbId3c — Azure Functions (@AzureFunctions) July 17, 2017 This feature is currently enabled for Function app settings, and API definition feature. We will be adding more items to this experience in the coming months. Features that will open in a tab have a small decorator to indicate they will open in this tabbed experience. If you have any questions about any of this features or App Service in general be sure to check our forums in MSDN and Stack Overflow.For any feature requests or ideas check out our User Voice ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/08/08/New-tabbed-experience-for-Azure-Functions-UX.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Azure Functions Tools released for Visual Studio 2017 Update 3",
+ "excerpt":" Donna Malayeri 8/14/2017 11:00:16 AM We're excited to announce that Azure Functions tools for Visual Studio are out of preview! The tools are now included in the Azure workload of Visual Studio 2017 Update 3. Just update your existing VS 2017 installation to Update 3--there's no need to use the preview channel or manually install the Functions tooling extension. The tools support building and publishing a class library as the implementation of your functions. Configure bindings and triggers using attributes in your code, rather than a separate metadata file. To get started with the tools, check out these articles: Create your first function using Visual Studio Azure Functions Tools for Visual Studio Using .NET class libraries with Azure Functions Azure Functions Core Tools Along with this release is the 1.0 version of the Azure Functions Core Tools. These are used by the Visual Studio tools when you run or debug a Function App locally. You can also use the Core Tools directly to retrieve app settings from Azure or publish your Function App. To learn more, see Run locally using the Azure Functions Core Tools. What's new in this release If you've used the preview tooling, you've probably seen the package Microsoft.NET.Sdk.Functions. This package is automatically added by the New Function project template and ensures that generated files are always in sync with your code. In this release, only triggers are generated in function.json. There is a new property in function.json that tells the runtime to use .NET attributes for input and output bindings, rather than function.json configuration: [sourcecode language=\"plain\"] \"configurationSource\": \"attributes\" // possible values are \"attributes\" or \"config\" [/sourcecode] If the value of configurationSource is attributes, then the contents of function.json cannot be changed after it is generated. That is because the Functions runtime uses attributes in the assembly to configure bindings and triggers. (If you’re wondering why some properties are still in function.json, it’s because the Scale Controller uses it to make scaling decisions on the Consumption plan.) Functions project type The Functions project type is a .NET Standard class library though it currently targets net461. This is because the Azure Functions runtime does not yet take a dependency on the .NET Standard 2.0 facades that enable full framework support. Now that .NET Standard 2.0 is RTM, we will make this update in a future release. See Support .NET Standard 2.0 class libraries #1792. Once we have completed the Azure Functions port to .NET Core 2.0, the .NET Standard 2.0 target will become much more important. At that time, we will change the default in the Visual Studio New Project dialog. Learn more We’ve seen a great response to our preview tooling and we’re excited to release this version. For more product news, follow @AzureFunctions. To report bugs or file feature requests, please open an issue on the Azure-Functions GitHub repo. Please include “Visual Studio” in the issue title. For technical questions, please post on the MSDN forums or StackOverflow. The entire Functions engineering team monitors these questions, so you’re sure to get an expert answer. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/08/14/Azure-Functions-Tools-released-for-Visual-Studio-2017-Update-3.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Introducing Proactive Auto Heal",
+ "excerpt":" Jennifer Lee (MSFT) 8/17/2017 1:24:29 PM Many of you may be familiar with the Auto Heal feature which allows you to configure limits on your Web App for request count, slow requests, Http status codes, and memory usage. Many times when you are experiencing problems with your Web App that can include slow responses or a non-responsive site, a simple restart of the Web App can solve the problem. As a result, we are introducing Proactive Auto Heal to expand on the Auto Heal offering. Proactive Auto Heal will only take corrective actions for the sites that we have deemed to be in a bad state for which the best way to recover is to simply restart the Web App. In many situations, your site may go into a bad state, so we are taking this preventative action on your behalf so that ideally your customers will not experience any downtime. Let’s say you are running your site on multiple instances and one of your instances has a memory leak and is consuming most of the memory on that instance. This could result in high latencies or unresponsiveness. If you have another Web App running in the same server farm (sharing memory and CPU), the Web App that is hogging those underlying resources may cause problems for other Web Apps running on that instance. With Proactive Auto Heal, the Web App that is taking up a lot of memory for example, would be restarted. If you have multiple instances, only the one in the bad state would be restarted. It will be automatically enabled for every site, but this will not affect Auto Heal rules that you have already set yourself, as those will take priority. How does Proactive Auto Heal know when to restart my Web App? Curious about how this feature works behind the scenes? Proactive Auto Heal looks for Web Apps that breaks either of these rules: Percent Memory Rule: This rule monitors the Web App’s process' private bytes to see if it exceeds 90% of the limit for over 30 seconds. The limit is determined from the amount of memory available for the process as outlined in the chart below. For example, for a 64 bit process on a Medium worker, it would be recycled if the private bytes went above 3.5GB * 90% = 3.15 GB for over 30 seconds. Instance Size Small Small Medium Medium Large Large Process Bitness 32 64 32 64 32 64 1.75GB 1.75GB 3.5GB 3.5GB 4GB 7GB Percent Request Rule: This rule monitors requests that have taken longer than the time limit. It is broken when 80% (or more) of total number of requests have taken 200+ seconds. The rule only triggers when there have been at least 5 requests in a rolling time window of 120 seconds during which the rule is broken. To account for slow application starts (which can be mitigated with our Application Initialization Feature with Slots!), this rule is not active during the process warm up time. If either of the rules are broken, then the Web App will undergo a overlapped restart of the process. This is NOT an instance restart or an entire Web App restart. In the case when there are multi-instances, the rules are ONLY triggered for the particular instance on which the process breached the rule, leaving the rest of the instances unaffected. Additionally, to prevent too many restarts (due to the application itself or service related bugs), both rules will be auto-disabled for 3 hours if there are too many restarts detected in a small time window. Opting Out Because we believe that most customers can benefit from Proactive Auto Heal, we have automatically enabled it by default, so you don’t have to worry about turning this on yourself or early wake up calls perform a manual restart of the process. However, we understand that some of you may be saying, “I don’t want you restarting my Web App!”. For example, this could be because you keep a lot of data in memory and do not want to unknowingly lose this data, which would happen when the process restarts. Here’s how you can opt out: Go to portal.azure.com and go to your Web App for which you would like to disable the feature. Under Settings go to Application Settings. Under App Settings add “WEBSITE_PROACTIVE_AUTOHEAL_ENABLED” and set it to “False.” That’s it! Proactive Auto Heal is disabled. If you later decide you would like to enable it again then you can either remove this App Setting or set it to “True”. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/08/17/Introducing-Proactive-Auto-Heal.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Web App on Linux <3 Azure Container Registry",
+ "excerpt":" Ahmed Elnably 8/23/2017 2:26:23 PM With our latest UX deployment we introduced a new user experience to easily choose Docker images that are stored in an Azure Container Registry (ACR) repo. Moreover we offer you a single click continuous deployment experience using webhooks with the Preview SKUs of ACR. For more information please check our intro doc at https://aka.ms/webapp-linux, for more information about continuous deployment for containers check the following article https://docs.microsoft.com/en-us/azure/app-service-web/app-service-linux-ci-cd ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/08/23/Web-App-on-Linux-<3-Azure-Container-Registry.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "How-to For WordPress on App Service (WindowsLinux )",
+ "excerpt":" mksunitha 9/12/2017 3:36:04 PM With both App Service for Windows and Linux today , setting up and configuration of your WordPress app is different in some way based on whether you are using Linux vs Windows . The matrix below can help guide your the appropriate documentation and steps for your WordPress app Web App on Windows Web App on Linux (Built-in) Web App for Containers Overview Web App on Windows Web App on Linux (Built-in) Web App for Containers How do I create New WordPress app Use the Azure Marketplace Template for WordPress This template also creates a database for your Web App based on your database provider choice Use Web App on Linux with Built-in PHP runtime You need to create a database if creating the app using this method. Read this article to know whether to use built-in or custom docker image Use the Azure Marketplace Template for WordPress on Linux This template also creates a database for your Web App based on your database provider choice. How do I modify PHP configuration Add a .user.ini to site/wwwroot folder and update PHP configuration . Use .htaccess to update PHP configuration if using PHP built-in image or custom image with Apache server Use .htaccess to update PHP configuration if using PHP built-in image or custom image with Apache server If you are using your own docker image , make the appropriate changes based on your server for example ngnix How do I debug WordPress WordPress has debugging Capability . For more information , click here How do I add a domain to WordPress app STEP 1 : Buy a custom domain from Azure and configure your web app Or use an existing domain to configure your web app. STEP 2 : WordPress needs additional changes to resolve to the new domain Login to Wordpress dashboard Click Settings, and then click General. In the WordPress address (URL) and Site address (URL) fields, enter the new domain name or URL you want to use, and then click Save Changes. Now browse your site with the new domain If you are using permalinks and its not resolving with new domain you might need to reset your WordPress site's permalinks. To do this From the Settings menu, click Permalinks. Note which kind of Permalink you currently use. Select any Permalink setting other than the one you currently use, and then click Save Changes. Select your original Permalink setting, and then click Save Changes. How to add SSL certificate binding for my domain Bind an existing custom SSL certificate to Azure Web Apps Buy and Configure an SSL Certificate for your Azure App Service How do I connect WordPress app with a database using SSL For more information click this link How do I migrate my database to Azure database for MySQL (Preview) For more information , click this link Which database provider should I use with WordPress Click this link to help choose the appropriate database provider How do I migrate existing WordPress app Identify your app dependencies to understand whether Windows or Linux built-in or Web app for Containers is the right choice Create a Empty Web App on Azure Choose Windows OS for Windows App Service Choose Linux if you are using built-in PHP . OR You can bring your own custom image using Web App for Containers Create a database for your app based on the database provider you have selected Migrate your database , for more information click this link Copy all your files to Azure web app using FTP or Git Update wp-config.php to point to the desired database for the azure web app If your wp-config.php files has any hard-coded paths please remove them or update them to use /home/site/wwwroot (Linux) D:\\home\\site\\wwwroot ( Windows) WordPress stored the URL of your web app in the database. Make sure you update the database to use your-site-name.azurewebsites.net or configure the appropriate domain to your app Continuous Integration (CI)/Continuous Deployment(CD) For more information , click this link . Here the continuous integration refers to only you application code. For more information , click this link. This depends on how you image is built : If your image has your application code included , then CI/CD refers to updates to your docker image If your image has only server components like apache , php etc and application code is on VSTS/Github ; then there are two deployments that need to configured for CI/CD : one for your application code and one for your docker image. Refer to this article Troubleshooting Platform Issues For more information , click this link For more information click this link. Checkout the FAQ as well. Scaling Application For more information click this link For more information click this link For more information click this link Note: When using Web App for containers you must use the App Settings WEBSITES_ENABLE_APP_SERVICE_STORAGE = true in order to use App Service storage which will allows file changes to persists and be shared by all the instances Performance Enhancements WP Super cache :It significantly improves site throughput and correctly handles comments submissions and other visitors’ actions. Azure Redis cache : Azure redis cache can also be integrated with WordPress with the help of WP redis plugin to get better performance. Static content Caching : Cache JS, CSS files Server level caching : For Windows App Service , you can use IIS output caching, click here. For App Service on Linux , use caching on Apache . Click here For Web App for Containers , you can include different types of caching within your custom image from local redis to APC or additional caching based on the server you use ( Nginx, Apache etc ) ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/09/12/How-to-For-WordPress-on-App-Service-(WindowsLinux-).html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "August 2017 App Service update",
+ "excerpt":" Byron Tardif 9/13/2017 11:08:56 AM App Service on Linux and Web App for Containers On Sept 06 we announce the GA for App Service on Linux and Web App for Containers. This includes new UI integration with Azure Container Registry as well as enabling container based CI/CD deployments. Azure Functions UX improvements Browse Azure Function UI now includes the ability to filter and group Function apps as well as the ability to refresh the list: We also have a new native App Settings experience that leverages the new Azure Functions tabbed experience New File System Storage UX The new view for file system quota provides more granular information on how this quota is calculated and per app file system usage breakdown. This UI is available for both App and App Service plans and can be found in the menu under Quotas or File system storage respectively. IP Restrictions IP Restrictions lets you define an allow list of IP Address that are granted access to your app. You can find this new feature in the menu under Networking>IP Restrictions Azure Bot Service Azure Bot Service now provides the option to choose an App Service plan for a bot in Azure Bot Service. If you have any questions about any of this features or App Service in general be sure to check our forums in MSDN and Stack Overflow. For any feature requests or ideas check out our User Voice ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/09/13/August-2017-App-Service-update.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Function Proxies adds Mock APIs to the Portal",
+ "excerpt":" Alex Karcher 9/14/2017 8:20:46 AM I’m very happy to announce mock API and HTTP request/response overrides in the Azure functions portal. This feature allows a function proxy to return sample data through a mock API, enabling development against a functions API endpoint without writing any code. Request/response overrides allows API data to be transformed in flight, enabling new API schemas to be supported without modifying a backend API. This functionality mirrors the existing request/response overrides and mocks previously only accessible through proxies.json Examples The following example shows a mock API that mimics the \"hello serverless\" example. The example returns a static response while also inserting text from a request parameter. The next example performs a transform on requests as they're sent to jsonplaceholder.typicode.com. It changes all HTTP verbs to HTTP GET, and appends the request's verb to the response header. Learn more We’ve seen a great response to the proxies preview and we're excited to continue releasing updates For more product news, follow @AzureFunctions. To report bugs or file feature requests, please open an issue on the Azure-Functions GitHub repo. Please include “Proxies” in the issue title. For technical questions, please post on the MSDN forums or StackOverflow. The entire Functions engineering team monitors these questions, so you’re sure to get an expert answer. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/09/14/Function-Proxies-adds-Mock-APIs-to-the-Portal.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Processing 100,000 Events Per Second on Azure Functions",
+ "excerpt":" Paul Batum 9/19/2017 7:07:33 PM Customers often ask us about the scalability/throughput limits of the consumption plan for Azure Functions. The short answer is always \"it depends, what does your workload look like?\". Today I want to talk about running high scale Event Hub / IOT Hub workloads on Functions and some key points to be aware of in order to maximize the performance you get from the platform. We partnered with the Azure CAT team to build a simple but representative event processing pipeline using Functions and Event Hubs, with telemetry going into Application Insights: The load generator (also running on Functions) writes batched messages to an ingestion event hub. These messages represent a set of readings from a given sensor. Functions picks up messages from the ingestion event hub, extracts individual readings from the batch and writes them to the target event hub, augmenting the messages with additional telemetry along the way. Two more functions within the same function app (on the consumption plan) each process the individual readings and send aggregated telemetry to App Insights. Performance We ran the system under a target load of 100,000 events per second for a total of 9 days. Over that time the system processed a total of 76 billion events. We measured the e2e latency of the pipeline i.e. amount of time taken between writing the message to the ingestion hub and processing the message in the weather/seismic function. Here are the results: E2E Latency Percentiles P50 P90 P95 P99 P99.9 P99.99 Max 1,102.42ms 2,755.56ms 3,788.30ms 11,894.12ms 50,367.23ms 111,240.50ms 239,890.10ms In simple terms: half of the messages were processed within 1.2 seconds of being written to the ingestion hub nine out of ten messages were processed in under 3 seconds 999 out of 1000 messages were processed in under 1 minute all messages were processed in under 5 minutes Monitoring Azure Functions has two built in monitoring solutions - the WebJobs dashboard and Application Insights (integration between Azure Functions and App Insights is currently in preview). The dashboard was designed with longer running jobs in mind and isn't optimized for scenarios where there are 10,000+ function executions happening per second. Fortunately, App Insights is an incredibly robust telemetry system and we've made sure that it works great with Azure Functions in high scale scenarios. Turning on App insights is really easy - just add your instrumentation key to your function app and Azure Functions will start sending data to App Insights automatically. For more info see here. The Azure dashboard is highly customizable and App Insights has great support for pinning its visual components. It only took an hour or two to put together a pretty useful monitoring dashboard for this scenario: Configuration We made some notable configuration choices to achieve this result: the functions process messages in batches the WebJobs dashboard is disabled in favor of using Application Insights for monitoring and telemetry each event hub is configured with 100 partitions data is sent to the event hubs without partition keys events are serialized using protocol buffers See below for additional details on each of these. Batching An event hub triggered function can be written to process single messages or batches of messages. The latter has much better performance characteristics. Lets take the splitter function as an example: public static async Task Run( EventData[] sensorEvent, PartitionContext partitionContext, IAsyncCollector<EventData> outputWeatherData, IAsyncCollector<EventData> outputSeismicData, TraceWriter log) { foreach (var sensorData in sensorEvent) { SensorType sensorType = SensorType.Unknown; try { if (sensorData.Properties.ContainsKey(\"SensorType\")) { System.Enum.TryParse(sensorData.Properties[\"SensorType\"].ToString(), out sensorType); } await ProcessEvent(sensorData, sensorType, partitionContext, outputWeatherData, outputSeismicData); } catch(Exception ex) { telemetryHelper.PostException(ex, sensorData, partitionContext.Lease.PartitionId, sensorType.ToString()); } } } The main things to note about this code: An array of events are passed to the function in one execution An exception handling block wraps the processing of each event The array based approach performs better primarily due to per function execution overhead. The system performs a number of actions when invoking your function and those actions will only happen once for an array of events rather than once per event. Note: for JavaScript functions you'll need to explicitly set the cardinality property in your function.json to many in order to enable batching (e.g. see here). This approach to exception handling is important if you want to ensure you don't lose/skip messages. Typically you'll write your exception handler so that it stores the event that failed for later processing/analysis. This is important because Azure Functions does not have any built in dead lettering for Event Hubs. WebJobs Dashboard As mentioned above, because we were using App Insights for monitoring we disabled the dashboard. To do this simply go to your application setting and remove the AzureWebJobsDashboard setting. Partition Configuration Azure Functions uses the EventProcessorHost (for more info see here) provided in the Event Hubs SDK to process event hub messages. The way EventProcessorHost works is that each VM running your app acquires leases to some of the partitions, allowing it to process messages on those partitions. This means that if your event hub has only two partitions, only two VMs can process messages at any given time i.e. the partition count puts an upper limit on the scalability of your function. The basic and standard tiers for Event Hubs have a default limit of 32 partitions per event hub, but this limit can be increased if you contact billing support. By setting the event hubs to have 100 partitions, each function was able to run on 100 VMs simultaneously. We can see this if we look at one minute of telemetry, counting the number of unique VMs that executed the weather function: We can get an idea of how evenly the work was distributed over those 94 VMs with another simple query: Partition Keys The event hubs programming guide has a good summary of partition keys and when you might want to use them. This scenario had no ordering or statefulness requirements so events were generated without partition keys. This increased the overall throughput and availability for the run. Protocol Buffers If you're writing and reading 100,000+ events a second, you want the serialization and deserialization of those events to be as efficient as possible, both from the perspective of time taken to do the serialization step and also size on the wire. Protocol Buffers is a high performance serialization format that is easy to work with. Here's some example code deserializing and processing a batch of weather readings from an event: if (sensorType == SensorType.Weather) { var batch = WeatherReadingBatch.Parser.ParseFrom(sensorData.GetBytes()); var messages = batch.SensorReadings .Select(reading => EnrichData(enqueuedTime, reading)); await WriteOutput(messages, sensorData.PartitionKey, outputWeatherData); } If you'd like to see the .proto file used for this scenario see here. Cost The total cost of running the function app and its dependencies for the 9 day run was approximately $1200 USD. Here's what the cost per hour looks like for each service: Service Cost per Hour (USD) Functions $2.71 Storage $1.80 Application Insights $1.03 A few important points to note: This data does not include the cost of the load generator and Event Hubs as no effort was spent on optimizing these. The Azure Storage cost is based on approximately 50 million transactions per hour. Almost all of these transactions are related to Event Hubs checkpointing. The Application Insights cost is based on 450mb of data ingestion per hour. We can dive into function app cost in more detail by using the execution count and execution units data available via the Azure Monitor REST API (see here for more info). Querying for one hour of data, we get the following: Function Execution Count: 6,500,012 Function Execution Units: 90,305,037,184 Note that the function execution units here are measured in mb-milliseconds. To convert these into gb-seconds, divide by 1024000. Putting it altogether (pricing details for functions are here, simple program I wrote to assist is here): Cost per hour = (6,500,012 executions * ( $0.20 / 1,000,000 )) + ((90,305,037,184 units / (1024 * 1000)) * $0.000016) = $2.71 USD Summary The consumption plan for Azure Functions is capable of scaling your app to run on hundreds of VMs, enabling high performance scenarios without having to reserve and pay for huge amounts of compute capacity up front. To learn more about Azure Functions and building cloud applications on serverless technology, start here. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/09/19/Processing-100,000-Events-Per-Second-on-Azure-Functions.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Develop Azure Functions on any platform",
+ "excerpt":" Donna Malayeri 9/25/2017 6:00:20 AM I’m excited to announce that we have ported Azure Functions to .NET Core 2.0! Both the runtime and the Azure Functions Core Tools are now cross-platform. Now, you can debug C# and JavaScript functions on a Mac or Linux using the Core Tools and Visual Studio Code. Both the runtime and the Core Tools are still in preview and we welcome your feedback! As this is a preview release, there are still a number of feature gaps. For more information, see Azure Functions runtime 2.0 known issues. Running on your local machine To get the new version of the core tools, pull down the @core tag on npm: npm i -g azure-functions-core-tools@core If you’re using Ubuntu, prefix the command above with \"sudo.\" If you have problems with the npm install on Mac, use the following: sudo npm i -g azure-functions-core-tools@core --unsafe-perm To learn how to use the tools, see Code and test Azure functions locally. JavaScript (Node 8.5 or higher) For the easiest installation, you must be running Node version 8.5 or higher. See instructions below for how to target a lower version. To create a new JavaScript HTTP-triggered function, do the following: mkdir JavaScriptHttp cd JavaScriptHttp func init . func new --language JavaScript --template HttpTrigger --name HttpTriggerJavaScript Run the host. This automatically enables debugging with the Node port 5858: func host start Open the folder in Visual Studio Code: code . In VSCode, set a breakpoint at the first line of the function, and attach the debugger (via F5 or the debug toolbar). Then, in a browser, navigate to the URL http://localhost:7071/api/HttpTriggerJavaScript?name=Functions%20Everywhere! You’ll then see the breakpoint being hit in VSCode! JavaScript (Node versions prior to 8) After installing azure-functions-core-tools, run the following commands: npm i -g node-pre-gyp cd %userprofile%/.azurefunctions/bin/workers/node/grpc node-pre-gyp install Once these tools are installed, you can use the instructions in the previous section to run and debug JavaScript functions. C# .NET Standard 2.0 class library You can now run and debug C# functions on a Mac or Linux. The Microsoft.NET.Sdk.Functions is the package that identifies a project as Functions project to Visual Studio and generates function.json from attributes during build. Templates for C# class libraries aren’t yet available in the Core Tools, but you can get a sample from GitHub. Dotnet command line git clone https://github.com/lindydonna/CSharpHttpCore.git cd CSharpHttpCore dotnet build dotnet publish cd HttpTriggerCore/bin/Debug/netstandard2.0 func host start VS Code debugging To debug your C# functions, open the folder containing your .csproj in VS Code. Make sure you have installed the C# extension. In the debug toolbar next to the play button, select Add Configuration Select .NET Core as the environment, then .NET: Attach to local .NET Core Console App. This will generate a launch.json configuration for your project. Then, press F5 and select .NET Core Attach. Select the dotnet process with the command line Azure.Functions.Cli.dll host start. Browse to the URL http://localhost:7071/api/HttpTriggerCSharp?name=CSharpEverywhere!. You’ll then see your breakpoint hit in VSCode. Visual Studio First, ensure you have downloaded the @core version of azure-functions-core-tools: npm i -g azure-functions-core-tools@core Then, add a new launch configuration for the 2.0 version of the Core Tools: In project properties -> Debug, change Launch to Executable For Executable, use %APPDATA%\\npm\\func.cmd For Application Arguments, use host start For working directory, use $(TargetDir) F5 will now launch the new version of the Azure Functions Core Tools. Running Functions 2.0 in Azure You can also use the .NET Core 2.0 port in Azure by targeting the new Functions 2.0 preview runtime. To use it, select \"beta\" in Function app settings -> Runtime version. Alternatively, you can the app setting FUNCTIONS_EXTENSION_VERSION to the value beta. You will then see a different set of templates available in the Add New Function page. Since the 2.0 runtime is in preview, there may be breaking changes even in minor releases. So, the 2.0 runtime should not be used for production workloads. If you navigate to the root of you function app, you’ll see that you’re running the new version: Connect with us We've seen a lot of excitement and interest, so we're looking forward to getting your feedback as we finalize the Functions 2.0 runtime. To report bugs or file feature requests, please open an issue on the Azure-Functions GitHub repo. For technical questions, please post on the MSDN forums or StackOverflow. The entire Functions engineering team monitors these questions, so you’re sure to get an expert answer. For product news, follow @AzureFunctions. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/09/25/Develop-Azure-Functions-on-any-platform.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "My Intern Project Microsoft Graph Bindings for Azure Functions",
+ "excerpt":" Chris Gillum (MSFT) 9/25/2017 3:42:46 PM The following is a blog post written by one of our many amazing summer interns, Glenna. I had the pleasure of mentoring Glenna this past summer as she worked on a very exciting internship project: The Microsoft Graph bindings for Azure Functions, which was recently announced at Microsoft Ignite 2017. Glenna worked tirelessly on this project and was responsible for large parts of the implementation as well as presenting the project to her peers and local executives (and she did an excellent job at both). Unfortunately she had to head back to school before we could publish this post, but now that it's been productized and announced we are finally free to unleash it. :) Thank you Glenna for your awesome contributions to our team and to our customers. We can't wait to have you come back and join us full-time after your graduation! As an aside, it's very important to us on the Azure App Service team that our interns get to work on projects that are fun, challenging, have a legitimate business impact, and actually ship to production. The Microsoft Graph bindings and associated Azure Functions portal work is just one example among many others, and we're really excited to be able to finally showcase it. Here is Glenna in her own words (with a few edits from the team based on some changes that were made after she returned to school). Consider the content of this post as supplementary to our official documentation. Personal Introduction My name is Glenna and I am a software engineering intern on the Azure Functions team in Redmond, WA. As I write this, I am finishing up my last day on my twelfth and final week at Microsoft. My internship was a truly incredible experience. I learned a great deal not just about specific programming languages, but also about good engineering design practices. I got to work on both the nuts and bolts of my features as well as the Azure Functions Portal UX and UI. I attend the University of Virginia in Charlottesville, Virginia. In May of 2018, I will graduate with a Bachelor of Science in Computer Science. Introduction Microsoft Graph bindings extend the existing Microsoft Graph SDK and WebJobs framework to allow users easy access to Microsoft Graph data (emails, OneDrive files, events, etc.) from Azure Functions. By using the Office input, output, and trigger bindings, users can bind to user-defined types, primitives, or directly to Microsoft Graph SDK objects like WorkbookTables and Messages. These bindings handle Azure AD authentication, Azure AD token exchange, and token refresh, allowing users to focus on writing code that utilizes Microsoft Graph data. Features Currently, the bindings can be grouped into four main categories: Excel, Outlook, OneDrive, and Webhooks. Excel [Input + Output] The Excel binding allows users to read/write Excel workbooks and tables using different data types, like lists of user-defined types or 2D string arrays. Outlook [Output] The Outlook binding is an output only binding, and allows users to send emails from their Office 365 email accounts. OneDrive [Input + Output] The OneDrive binding allows users to read/write files stored in their OneDrive using several different data types (e.g. DriveItems and Streams). Graph Webhooks [Trigger + Input + Output] There are two bindings associated with Graph webhooks: GraphWebhookTrigger and GraphWebhookSubscription. GraphWebhookSubscription [Input + Output] The GraphWebhookSubscription input binding allows the retrieval of Microsoft Graph webhook subscriptions that the function app has created. The GraphWebhookSubscription output binding handles webhook subscription creation, as well as renewal and deletion. Without renewal, most Microsoft Graph webhooks expire in 3 days. Deleting a webhook subscription removes the subscription from the Microsoft Graph account, as well as all references to that subscription in your Function app. Both the refresh and delete output bindings are best used in conjunction with the input binding, as they operate on current webhook subscription ids. GraphWebhookTrigger [Trigger] The GraphWebhookTrigger binding allows users to subscribe to notifications about supported Microsoft Graph resources, including email messages, OneDrive root, contacts, and events. If you examine the wire protocol, the notification payload from Microsoft Graph is very lightweight; it only contains a webhook subscription ID and the subscribed resource. In order to provide detailed information to the function code, the webhook trigger internally uses a local store of webhook subscription data (stored by the GraphWebhookSubscription binding at subscription creation), maps the webhook subscription ID to a user, performs a silent GET request for the specified resource and transforms that payload into either a JSON object or a Microsoft Graph SDK type (e.g. Message, Contact) which can then be accessed directly by the function code. Identity Actions mentioned can be performed using the current Office 365 user's identity, or using the Azure AD service principal identity of the function app. Which identity is used is up to the Function author. In order to authenticate against the Microsoft Graph as a specific user, either an ID token or an Azure AD Principal ID must be given to the binding. This identifier can come from a number of different sources. Examples of these sources include the currently authenticated Azure AD user (which can be captured from a session cookie or a bearer token), the content of an HTTP request, a queue, or an app setting. Examples An easily imagined scenario for these bindings is a business owner with customers who subscribe to their monthly newsletter. Customers provide their names and email addresses, which then must be added to an Excel file of customers. Using the Excel output binding, the business owner can select which Excel table to modify. [caption id=\"attachment_5996\" align=\"alignnone\" width=\"997\"] Excel output binding[/caption] The function code to append the Excel row is only a few lines long. In this example, the function receives a POST request with a user's name and email address and converts it into a custom EmailRow (POCO) type using the runtime's dynamic binding capabilities to remove the need for JSON manipulation. using System.Net; public static async Task Run( HttpRequestMessage req, IAsyncCollector<EmailRow> outputTable) { // Get request body dynamic data = await req.Content.ReadAsAsync<object>(); // Use body data to set row data var output = new EmailRow { Name = data?.name, Email = data?.email }; await outputTable.AddAsync(output); } public class EmailRow { public string Name {get; set;} public string Email {get; set;} } Every month, a timer trigger (or some other trigger type) fires and an email, the contents of which are determined by a OneDrive file, is sent out to each customer. The business owner can select the same Customers Excel file (Excel input binding)... [caption id=\"attachment_5995\" align=\"alignnone\" width=\"984\"] Excel input binding[/caption] ...determine which OneDrive file to get the email contents from (OneDrive input binding)... [caption id=\"attachment_6015\" align=\"alignnone\" width=\"978\"] OneDrive input binding[/caption] ...and indicate that they would like to send emails via the Outlook output binding. [caption id=\"attachment_6026\" align=\"alignnone\" width=\"993\"] Outlook mail output binding[/caption] The code below quickly scans the Excel table and sends out one email per row (customer). #r \"Microsoft.Graph\" using System; using Microsoft.Graph; // Send one email per customer public static void Run(TimerInfo myTimer, TraceWriter log, List<EmailRow> inputTable, string file, ICollector<Message> emails) { // Iterate over the rows of customers foreach(var row in inputTable) { var email = new Message { Subject = \"Monthly newsletter\", Body = new ItemBody { Content = file, //contents of email determined by OneDrive file ContentType = BodyType.Html }, ToRecipients = new Recipient[] { new Recipient { EmailAddress = new EmailAddress { Address = row.Email, Name = row.Name } } } }; emails.Add(email); } } public class EmailRow { public string Name { get; set; } public string Email { get; set; } } The aforementioned goals can be accomplished using just a few lines of code. No manual data entry, no hardwiring, and no additional services. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/09/25/My-Intern-Project-Microsoft-Graph-Bindings-for-Azure-Functions.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Introducing the New App Service Support Center (Preview)",
+ "excerpt":" Jennifer Lee (MSFT) 9/28/2017 7:00:55 AM “What’s wrong with my Web App? My Web App is down!” These are tough questions that we know are frustrating for you. It is our priority to make sure that we figure out how to keep your Web App healthy with minimal downtime. However, in the cases where things do go wrong, the problem is that there could be many reasons why. How do you know which of these generic potential issues could be the reason why your Web App is down? Where do you start your troubleshooting process for your specific Web App? Many of you may be familiar with the Diagnose and Solve Support Center, our self-serve diagnostic experience that allows you to get a glimpse of how your Web App is performing. Since releasing that experience, we’ve been able to add and improve the detectors that we use to analyze the health of your Web App to perform more precise pattern analyses in an effort to pinpoint Web App errors and provide troubleshooting advice. As a result, today we are excited to announce the release of our new Diagnose and Solve Support Center (Preview) to help point out what’s wrong with your Web App and guide you to the right information to troubleshoot and ideally resolve the issue easier and quicker than before. Getting Started with the New App Service Support Center To open the new App Service Support Center, click on “Diagnose and Solve problems” on the left-hand menu. Once in the new App Service Support Center homepage, there are several options. First, you should ask yourself this question: Do you already know what’s wrong with your Web App? (Note: in this blog post, images will be expanded when clicked). Performing a Health Checkup (Highly Recommended) If you’re not sure what’s wrong with your Web App, run our new Health Checkup feature by selecting the blue “Yes” button. Health Checkup will analyze your Web App to give you a quick, interactive overview that points out what’s healthy and what’s wrong, telling you where to look to investigate the issue. Once the Health Checkup report is generated, you can get a quick overview of the status of four different problem categories: Requests and Errors, Performance, CPU Usage, Memory Usage. [video width=\"1912\" height=\"1092\" mp4=\"media/2017/09/2017-09-29_11h03_03-online-video-cutter.com_.mp4\" poster=\"media/2017/09/App-Service-Genie-Blog-Post-2.png\" loop=\"true\" autoplay=\"true\"][/video] Highlights: Quick Overview: red, orange, and green icons appear on the left side of each problem category to indicate the healthiness of that area. You can click on each tab to open up a graph showing more details. View Full Report: this opens up more observations about the issue and suggested solutions as seen in the image below. You can investigate further by selecting the orange bars corresponding with periods of unhealthiness and expanding on observations by clicking \"View Details\" below. Suggested solutions would show up below the observations. Selecting Tile Shortcuts If you already know what’s wrong with your Web App, you can investigate further by selecting the tile shortcut that corresponds to the problem category that you’re interested in. Currently, we have five problem scenarios for our tile shortcuts. (Note: Web App Restarted is the only scenario not covered by Health Checkup at the moment): Web App Down Web App Slow High CPU Usage High Memory Usage Web App Restarted Let’s say you want to figure out why your Web App restarted. In the homepage, select the “Web App Restarted” tile. This will open a new tab with our Web App Restarted analysis. One-Stop Shop for Additional Resources Now, on the right-hand column, we have compiled a list of help links to give you all easy access to variety of different resources with content that can help you troubleshoot your Web App. Just select the + sign next to each title to expand that selection. Here is a quick overview of the different Additional Resources categories: Support Tools: additional troubleshooting tools Premium Tools: more additional troubleshooting tools FAQs: links to App Service articles that guide you through common troubleshooting scenarios Resource Center: links to how-to articles and video walkthroughs for those needing a quick-start for App Service Community: links to forums and other locations where you can get help from members of the App Service team and other community members Recent Updates: convenient links to updates to Microsoft Azure services as well as stack specific updates Contribute: link to our Github repository to assemble feedback for Support Center and allow for open source contributions We need your feedback! In the coming months, we are planning on adding additional features with a goal that Support Center can guide you step-by-step for a holistic Web App troubleshooting experience. This means that the feedback that you leave is critical for us to determine which features are most relevant for you. Once Health Checkup is complete, you can leave your feedback in the inline textbox as seen below. Note: currently, this experience is only for App Service on Windows. Stay tuned! ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/09/28/Introducing-the-New-App-Service-Support-Center-(Preview).html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "September 2017 App Service Update",
+ "excerpt":" Byron Tardif 10/9/2017 2:23:30 PM Support for Azure Managed Service Identity (MSI) Managed Service Identity (MSI) let you assign your azure resources an automatically managed identity that can be used to access other Azure and Azure Active Directory managed resources without ever exposing credentials in code. Learn how to leverage MSI with App Service and Azure Functions. Performance improvements for Azure Functions UX We have shipped a few behind the scenes improvement to the Azure Functions UX that improves performance up to 40% in some instances. This should result in snappier navigation and more responsive interactions. If you have any questions about any of this features or App Service in general be sure to check our forums in MSDN and Stack Overflow. For any feature requests or ideas check out our User Voice ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/10/09/September-2017-App-Service-Update.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Durable Functions and Bindings Extensibility Preview Announcement",
+ "excerpt":" Chris Anderson (Azure) 10/10/2017 7:01:45 AM We’re excited to announce two new preview features in Azure Functions: Durable Functions: A framework that makes it easy to orchestrate multiple functions and manage state for your serverless apps. Binding extensibility: A capability that allows you to create your own reusable serverless components that can be used from any supported language. Durable Functions In serverless functions, as with many application frameworks, it’s commonly recommended to write your code to be stateless, and this is the best practice. What is often not discussed in detail, though, is how one should manage that state. For trivial scenarios like just standard user data, databases are an obvious option, or for messaging between applications, a queue service is sufficient. However, what if your application has need for a more complex, stateful orchestration of multiple components? Without better tools, you’re left to figure out the right way to combine those pieces. This is the problem that the Durable Functions feature seeks to solve; letting developers abstract away the management of state for complex, stateful orchestration. Today, we’re happy to announce that Durable Functions is now in preview. Durable Functions builds on the Durable Task Framework, which was designed to allow developers to write code based orchestrations using async/await pattern in C#. This enabled the following: Expression of tasks in simple C# code Automatic persistence and check-pointing of program state Versioning of orchestrations and activities Async timers, orchestration composition With Durable Functions, we let you write orchestrators and activities as Functions. Orchestrators can call Activity Functions, other sub-orchestrations, and wait for an external event. Combined, this functionality allows a lot of complex patterns to be expressed via code. For instance, the code below will fan out and call various Activity Functions, wait for them all to complete, and then allow you to sum the results (fan in). This pattern was possible before but involved a lot more setup and management code that was unrelated to the business logic. #r \"Microsoft.Azure.WebJobs.Extensions.DurableTask\" public static async Task<long> Run(DurableOrchestrationContext backupContext) { string rootDirectory = backupContext.GetInput<string>(); if (string.IsNullOrEmpty(rootDirectory)) { rootDirectory = Environment.CurrentDirectory; } string[] files = await backupContext.CallFunctionAsync<string[]>( \"E2_GetFileList\", rootDirectory); var tasks = new Task<long>[files.Length]; for (int i = 0; i < files.Length; i++) { tasks[i] = backupContext.CallFunctionAsync<long>( \"E2_CopyFileToBlob\", files[i]); } await Task.WhenAll(tasks); long totalBytes = tasks.Sum(t => t.Result); return totalBytes; } In the above code, you can see the first set of bold code fanning out and calling many Functions, and then the later bold line waiting for them all to complete. What’s happened since alpha? Since we initially released the alpha preview we’ve seen lots of great community interest and folks experimenting with Durable Functions. In addition to all that feedback, we’ve also been working on a few important enhancements. You can see all the work highlighted on the GitHub repo for Durable Functions extension. Here are some highlights: Elastic scaling support for consumption plan Cross platform support by porting to netcore2.0 Better traces and integration with Application Insights Retry support for Activities Improved error handling with timers Portal support and templates Moved to have support only on 2.x version of Azure Functions runtime Roadmap In the coming months, we’ll be working towards a GA of the current functionality and investigate the following enhancements: Support for other languages Improved monitoring and management of orchestrations Improve the underlying messaging/data layer to improve the maximum throughput Dynamic repartitioning of orchestrations Binding extensibility: goodbye SDKs, hello bindings Developers are building increasingly complex serverless applications and need better mechanisms for code reuse. Triggers and bindings allow developers to focus on their code and let Azure Functions handle all the logistics of connecting to other services, in a way “reusing” the glue code that we have already written for you. We are now providing a mechanism using which you can author your own custom bindings for Azure Functions, providing more avenues for reuse. This mechanism (binding extensibility) is a feature of the 2.0 Functions runtime. In fact, Durable Functions is authored as a custom binding for Azure Functions. Bindings allow you to create reusable serverless components that can be used from any supported language. If you host a developer service, bindings will make it easy for Functions developers to use your product. Developers can also create reusable packages and host them in a central repository, just like a library or SDK. Binding extensibility allows you to provide a declarative interface for an SDK. For instance, we have a sample Slack output binding that sends a slack message when a customer uses a [Slack] attribute (or the equivalent in function.json): C# using System.Net; using System.Net.Http; using Microsoft.Azure.WebJobs; using Microsoft.Azure.WebJobs.Host; using SampleExtension; namespace SampleFunctionApp { public static class HttpTriggerSlack { [FunctionName(\"HttpTriggerSlack\")] public static string Run( [HttpTrigger] SlackMessage message, [Slack(WebHookUrl = \"SlackWebHook\")] out SlackMessage slackMessage, TraceWriter log) { slackMessage = message; return \"Ok\"; } } } JavaScript module.exports = function (context, req) { context.log('JS HTTP function processed a request: ' + req.body.text); context.bindings.slackMessage = req.body; context.done(); }; Creating a custom binding Currently, extensions can only be authored in C# but can be consumed from any supported language. To get started, please check out the sample WebJobsExtensionSamples, which has a detailed readme on how to get started. There is also a Slack output binding sample. Reference documentation is available on our wiki: Creating custom input and output bindings. Custom triggers For custom triggers, we plan to offer integration with Azure Event Grid. Stay tuned for more details on this. Next steps Please try out Durable Functions and binding extensibility and provide feedback on the experience. We encourage you to try these features in all kinds of interesting ways and help us make them work even better when we GA. As always, we look forward to hearing from you through our Forums, StackOverFlow, or Uservoice. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/10/10/Durable-Functions-and-Bindings-Extensibility-Preview-Announcement.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Retirement of the PHP 5.5 runtime from App Service",
+ "excerpt":" Jennifer Lee (MSFT) 10/11/2017 7:58:58 AM Strongly Recommended to Upgrade to PHP 5.6, 7.0, or 7.1 Because the PHP Group stated that PHP 5.5 is no longer supported, there won’t be any more updates to that version, including security fixes. To avoid the potential for security issues on App Service, we plan to retire our support of PHP 5.5 in January 2018. Currently, we support PHP 5.6, 7.0 and 7.1. This retirement will impact all customers who are running their Web App on the PHP 5.5 runtime (unless you are using a custom PHP runtime). We strongly recommend that you upgrade to a supported version of PHP because your Web App will be auto-moved to PHP 5.6. For more information on how to migrate from PHP 5.5 to another version of PHP, please review the documentation on the Appendices webpage on PHP.net. Although we’re removing the PHP 5.5 runtime from the platform, we’re aware that some applications are complex and may be tied to a specific PHP runtime version. In order to continue to support your PHP 5.5 applications, it’s possible to remain on PHP 5.5 runtime. For more information, please visit the \"How to: Use a custom PHP runtime\" section of the Configure PHP in Azure App Service Web Apps documentation webpage. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/10/11/Retirement-of-the-PHP-5.5-runtime-from-App-Service.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Zip Push Deployment for Web Apps, Functions and WebJobs",
+ "excerpt":" Nick Walker 10/16/2017 10:20:11 AM With our most recent release of Kudu, we have introduced a new deployment option for web apps, Azure Functions and WebJobs: zip push deployment. Zipdeploy combines the simplicity of Kudu’s zip API with the flexibility and robustness of Kudu’s deployment features, like deletion of unused files from old deployments, history tracking and Auto Swap support. Why a new API? Since App Service and Kudu were first introduced, the deployment needs of developers have evolved. Availability and adoption of mature continuous integration and delivery (CI/CD) tools and services like VSTS have grown significantly. Developers are increasingly looking to deploy tested, ready-to-run apps from these services instead of from source code. The ability of many app stacks to enable rapid iteration has improved. Many contemporary developer workflows require the ability to quickly deploy directly from a development environment. The introduction of Azure Functions has further driven the popularity of rapid-iteration workflows. The nature of Functions encourages developers to repeatedly prototype and deploy small packages of functionality. Kudu features a variety of mechanisms for deploying code to App Service that make use of its underlying deployment platform, which provides for safe, tracked deployments. But despite its relative lack of features, feedback has indicated that many developers favor using Kudu’s zip API for deployments, especially in the above scenarios. For many workflows, the pure simplicity and cross-platform availability of the push-based zip API and of zip files themselves wins out over the features of other available deployment mechanisms: Git deployment restricts your site contents to files that are in the repository and requires a commit to deploy. Triggering deployments with pushes to hosted providers like GitHub requires some setup before getting started. Git deployment also engages Kudu's CI build system by default, which detects your app's runtime stack and generates scripts to do things like restore packages or compile code. This is undesirable when deploying an app that's already been built by your CI/CD service or deploying a working app from your local environment. Web Deploy (aka msdeploy) is extremely powerful but challenging to configure. It's not supported on App Service on Linux and can't be used from non-Windows clients. FTP requires tools that many developers don't have handy or aren't familiar with. Many of them require scripting to achieve the desired result. Zips are simple and ubiquitous, but without a connection to Kudu's deployment features, the zip API is only fit for general-purpose file transfers and is not robust enough for deployments. Deploying via the zip API can leave old files lying around that can break your application or Function unless you completely erase the existing files first. It doesn't create any deployment history, and there is no first-class way of verifying that deployment operations performed via the zip API are 100% successful. Why not combine the ease of pushing a zip file up to your site with Kudu's comprehensive deployment features? Enter zipdeploy! Usage Create a zip file containing the files you want deployed to wwwroot and POST it as binary data to /api/zipdeploy on your site’s Kudu instance. Here’s how to do it with curl: curl -X POST -u <publishing-user> --data-binary @<zipfile> https://{sitename}.scm.azurewebsites.net/api/zipdeploy Be aware that this operation may delete files currently in your site depending on the contents of your deployment! See Features below for more information. Add ?isAsync=true to the URL to perform an async deployment. A response will be returned as soon as the file is uploaded, and the deployment will continue on the server. The response will include a Location header with a URL that can be queried for realtime deployment status. By default, Kudu assumes that zip deployments do not require any build-related actions like npm install or dotnet publish. This can be overridden by setting the SCM_DO_BUILD_DURING_DEPLOYMENT deployment setting to true to enable Kudu’s detection logic and build script generation process. As with all web app deployments, modifying the files of a running app is a potentially dangerous operation that exposes your app to clients in a partially-deployed state. Apps that need atomic, zero-downtime deployments, smoke testing and/or rollback support should always use a staging environment and a slot swap as part of deployment. Features Flexibility: Push-based zip deployment eliminates the need to host your build output on the web or create a git commit. Zip deployments do not require any setup in Kudu or the Azure portal and can be run at any time with nothing but an HTTP client, regardless of whether your application is already synced with a source control provider. Deletion of files left over from the previous deployment: Deployments use the KuduSync utility to track and delete files and directories that were created by a previous deployment if they’re not included in the new deployment. Any other files and directories found in the site that aren't being overwritten by the deployment will be preserved, such as files deployed via FTP, created in the Functions portal or created by your app during runtime. Function trigger sync: If you are running Functions on a Consumption plan, modifying their triggers requires a synchronization process that doesn't occur with file-based deployment methods like FTP or the zip API. Zipdeploy will perform this synchronization for you. Efficient file copy: KuduSync will only overwrite an existing file if its last-modified timestamp doesn’t match what’s in the deployment. You can speed up your deployments by using a build process that preserves timestamps on files that do not change across builds. Logging, status tracking and history: Zipdeploy generates live status, deployment logs and recorded history in Kudu's deployment API. However, zip deployments cannot be redeployed. Async support: By adding ?isAsync=true to the URL, a response will be returned as soon as the zip has been uploaded to the site. Deployment will continue asynchronously on the server. The Location header of the response will contain the deployment URL that can be polled for deployment status. Webhooks can be used for fully asynchronous notification of completion. Customization: Deployment-related settings will be respected, including those in app settings as well as configuration placed in a .deployment file located in the root of the zip. Build script support: By default, zipdeploy assumes that the zip contains a ready-to-run app. Kudu's continuous integration build process can be enabled via the SCM_DO_BUILD_DURING_DEPLOYMENT deployment setting, or by providing a custom build command with the COMMAND setting. Safe deployment: Zipdeploy engages Kudu's deployment locks, preventing multiple simultaneous deployments from clobbering your site. Auto Swap and container restart support: A zip deployment will trigger an Auto Swap if your site is configured for it. On App Service on Linux, zip deployment will trigger a restart of the app container. Feedback Please give zipdeploy a try and let us know what you think, especially if you're currently using the zip API for deployments. We’d love to hear your feedback – we’ll be watching the Issues tab on Kudu’s GitHub page, as well as the MSDN forums, Stack Overflow and Uservoice. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/10/16/Zip-Push-Deployment-for-Web-Apps,-Functions-and-WebJobs.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Configure App Service Certificate to Azure Virtual machines",
+ "excerpt":" mksunitha 10/26/2017 2:34:38 PM App Service Certificate can be used for other Azure service and not just App Service Web App. This tutorial shows you how to secure your web app by purchasing an SSL certificate using App Service Certificates , securely storing it in Azure Key Vault , domain verification and configuring it your virtual machine . Before your begin log in to the Azure portal at https://portal.azure.com Step 1 : Create an Azure Virtual machine with IIS web server Create an Azure virtual machine with IIS from Azure marketplace or with Azure CLI . Step 2 : Add a Custom domain to your virtual machine Purchase a new domain and assign it your Azure virtual machine. For more details , click here . Step 3 : Place an SSL Certificate order You can place an SSL Certificate order by creating a new App Service Certificate In the Azure portal. Enter a friendly Name for your SSL certificate and enter the Domain Name in Step 1 . DO NOT append the Host name with WWW. Step 4 - Store the certificate in Azure Key Vault Key Vault is an Azure service that helps safeguard cryptographic keys and secrets used by cloud applications and services. Once the SSL Certificate purchase is complete, you need to open the App Service Certificates page. The current status of the certificate is “Pending Issuance” . Complete the steps below to have an active certificate ready to use. Click Certificate Configuration inside the Certificate Properties page and Click on Step 1: Store to store this certificate in Azure Key Vault. From the Key Vault Status page, click Key Vault Repository to choose an existing Key Vault to store this certificate OR Create New Key Vault to create new Key Vault inside same subscription and resource group. Note : Azure Key Vault has minimal charges for storing this certificate. For more information, see Azure Key Vault Pricing Details. Once you have selected the Key Vault Repository to store this certificate in, the Store option should show success. Step 5 : Verify the domain ownership From the same Certificate Configuration page you used in Step 3, click Step 2: Verify. Choose the preferred domain verification method. There are four types of domain verification supported by App Service Certificates: App Service, Domain, Mail, and Manual Verification. These verification types are explained in more details in the Advanced section. Step 6 : Assign certificate to Virtual machine Before performing the steps in this section dedicated for Virtual machine , you must have : associated a custom domain name with your app on the virtual machine. For more information, see Configuring a custom domain name for a web app. Make sure Key Vault has appropriate permissions to be used with Virtual machine . For more information , see Using MSI with Key Vault on Virtual machine Here are the instructions to assign the certificate to the virtual machine An issued App Service certificate may be used on any App Service Web App. Follow the steps below to assign the certificate to an App Service App. Get the Key Vault information for your SSL certificate resource under certificate configuration. Prepare and Configure the virtual machine to add the Certificate. An App Service Certificate can be used on multiple Azure Virtual Machines.Learn more References Internals of App Service Certificates Get started with Azure Key Vault ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/10/26/Configure-App-Service-Certificate-to-Azure-Virtual-machines.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "App Service Certificates now supports public certificates (.cer)",
+ "excerpt":" mksunitha 11/1/2017 3:11:17 PM App Service certificates now enables you to upload public certificate . Previously you had to use Azure resource manage template to upload a public certificate or use ARM client to do the same as described in this article. Today , we have made this experience more user friendly to allows user to install their public certificates in the personal certificate store. You can easily add a public Certificate for your App service web app using the Azure Portal. Follow the steps below to upload a public certificate : Login to the Azure portal and select your web app Click on SSL Certificates setting -> Upload Certificate. Select Public and upload your public certificate . The .CER file contains information about the certificate ownership and public key. If you are using an App Service Environment you will be given the option to store either in Current User or Local Machine Store . Once upload you can see your public certificate installed on your app as shown below Note SSL certificates is supported only on dedicated App Service Plans and App Service Environments. Things to remember If your App Service is hosted on a public scale unit then you can only install certificates in CurrentUser Personal Store certificate. If your web app is hosted on an App Service Environments, CurrentUser or LocalMachine-Personal certificate store is only supported. When using Deployment slots with your application , keep in mind that the certificates are not sticky and will also get swapped when you perform a slot swap operation. Either user your application code to check for multiple public certificates or make sure the correct certificate is upload for slot as well before you swap a slot with production app. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/11/01/App-Service-Certificates-now-supports-public-certificates-(.cer).html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "October 2017 App Service Update",
+ "excerpt":" Byron Tardif 11/2/2017 2:17:51 PM Performance This month we focused on fundamentals including performance improvements for the overview blade. This resulted in slicing the load time for the menu and overview blade to roughly half of what it was before the improvements. Function + Logic apps Functions and Logic apps work great together and are often developed side by side. We’ve made it easier to move from Functions to Logic apps by including it in the platform features for functions. This will open an new tab where you can quickly switch between resources. Supports public key certificates (.cer) Support for public key certificates was one of our most requested user voice features. Public key certificates let you use self-signed certificates for test/development scenarios amongst other things. You can read more about App Service support for Public Key Certificates here: If you have any questions about any of this features or App Service in general be sure to check our forums in MSDN and Stack Overflow. For any feature requests or ideas check out our User Voice ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/11/02/October-2017-App-Service-Update.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Running a popular Content management solution on Web App for Containers",
+ "excerpt":" mksunitha 11/6/2017 1:34:21 PM There are multiple options to hosting your Content management solutions (CMS) like WordPress , Drupal , Magento etc. with Linux App Service . The blog post below will cover the key decisions and implementation guidelines when using Web App for Containers for a CMS solution like WordPress or Drupal. Built images : App Service team provides your bare bone docker images for PHP , and other frameworks. These images are very basic and help you quickly get started but as your apps grows , these images may be limited to your needs as you are limited from making any changes to these images . Custom images : Custom docker images provides you with more flexibility to grow as your apps grows. You have more control on the docker image itself and can modify it with new modules or extensions if and when your app needs these changes . This option make lift and shift of your application more easy since you can replicate you current dependencies as close as possible in the cloud. Checkout an example of using a Python Application with a Custom image. The recommended approach is using custom images with Web App for Containers when using a CMS solution. File Storage App Service come with a shared file storage . You must use this storage if : The application writes to the file system frequently and needs these files to be persisted. You want to use auto-scaling features and you want all the instances to share the same file storage In order to use the App Service Storage , explicitly include an app setting WEBSITES_ENABLE_APP_SERVICE_STORAGE = true To better understand this , let me elaborate with an example : If you have a WordPress app , note that WordPress CMS installs minor version updates to make sure your app has any important fixes needed. This means new files being added or existing files being modified to your application. In such cases , the application needs the files to persist so that you have the latest patches/fixes for WordPress hence this scenario requires the use of App Service Storage . Most CMS solutions have a variation of this type of application updates . Have a better understating of your application to decide if you want to use App Service storage. Can I use local storage instead of App Service Storage for CMS solutions By using the local storage rather than App Service Storage you do get better stability and there is less impact if the app service storage has issues. To use local storage , set the app setting WEBSITES_ENABLE_APP_SERVICE_STORAGE = false Lets use WordPress as an example here again. You can use local storage for WordPress app , but this requires a few changes in your code and how the application is used. Here are a few things you would need to do : Turn off auto update for WordPress Manually deploy the latest WordPress code updates with your docker image Do not install plugins , themes etc. from production site’s WordPress administration dashboard For other CMS solutions like Drupal , Joomla etc ; you need to understand if there are options on turn on auto-update . The steps #2 and #3 mentioned above will still apply to any other application. This is a key decision to make before taking the next step. Deployment There are many deployment options available for your custom images: Continuous Delivery with VSTS Continuous Deployment with Azure Container Registry (ACR) or Docker Hub Choose a deployment option There are two common terms with deployment as seen above : Continuous Deployment : Every change made to your docker image is pushed out to production automatically. Continuous Delivery: Provides you with a deployment release pipeline. This solution does not mean your code is pushed to production automatically . The goal here is to build a process that can allow code to be deployed any time . Most Continuous Delivery processes include automated tests and criteria that needs to be met before the changes go to production. Based on your needs , pick either Continuous Delivery which we provide using VSTS or Continuous Deployment with ACR/DockerHub. Can I deploy my code via GIT You can have your application source code as part of the docker image or you can have the application code on a git based repository and your docker image on ACR or Docker Hub . Continuous Delivery with VSTS supports both these scenarios. If you are not using Continuous Delivery with VSTS , the other option you have is Continuous Deployment feature that support GitHub, Bitbucket, Local GIT etc. Note :You must use App Service Storage for your files if your application code is separate from your docker image and you choose to deploy the source code separately than the docker image. If your application code is large , there may be some issues with Git deployment for such apps. In those cases use Zip deploy API Planning Migration or setting up a new site The question listed below should help you make the key decisions before implementing a migration of an existing site or setting up a new site: Should I use a built in image or customer image ? Review your dependencies or requirements to answer this question Should I use App Service Storage or Local Storage ? Does the app need file persistence ? Do I need to run the app on multiple instances with auto-scale or Can I run the app on single instance ? When running in single instance , you can include local mysql , local redis etc without having to use a cloud service for MySQL and Redis . Note to use Local mysql you need file persistence What deployment strategy works best for this application ? Keep in mind to choose an option that helps make deployment even after the site is in production. This will provide a stable , repeatable deployment process. What external dependencies are needed ? Do I need a cloud based service for my database , twitter/Facebook API etc . Migration Migration of an application from On-premise or other cloud solution providers can be challenging tasks. Here is migration process that is articulated for Web App for Containers. Identify your application dependencies on premise or local development machine . Such as , webserver , php version , php extensions , web server modules etc . If you are using apache server with say php , you can build a custom image with apache server , php etc to run on Web app for containers. If you are using nginx in your current architecture , you can build a custom image with nginx for web app for containers. Identify external dependencies like Database , Redis cache , CDN etc. Find appropriate solutions for these external dependencies in Azure For CMS solutions always build a Custom docker image based on the dependencies you identified from the above step. You can find many samples here to help get started . Enable SSH in your docker image which can help as a tool to debug your app. Create a Web App For Container from Azure portal Create your external dependencies with the appropriate solutions available in Azure . For example , if your app needs MySQL you can use Azure database for MySQL for better reliability and performance Make the decision to use Local storage or App Service Storage. To use App Service Storage , edit the app setting WEBSITES_ENABLE_APP_SERVICE_STORAGE = true Select a deployment option for your application : Continuous Delivery or Continuous Deployment or Git Deployment. Deploy your code to the application and make sure the application code is updated appropriately to use the new dependencies for database , cdn etc in Azure Browse your application once deployed Turn on Diagnostic logs to view your docker logs to investigate any issues if you don’t get the expected results. Troubleshoot your application further using SSH . Tweak your Docker image as needed to resolve any issues . Reiterate the process from step 7 . If you are still unable to resolve any issues for a given step or have questions , reach out via support forums to get help. Setting up CMS solution on Web App for Containers In the steps below , using Drupal CMS as an example for the CMS solution to be setup and configured on Web App for Containers : ü Create a Web App using Web App for Containers using Nginx-fpm and Drush CLI tool or your own custom Drupal Image. This image does not have Drupal source code as part of the image. Note : When using your custom docker image , make sure it is available in either Docker Hub or Azure Container registry as a private or public repository . Make sure you application has SSH enabled which can help in troubleshooting. ü Use App Service Storage since Drupal requires files to persist when you do install a module or update Drupal modules or Drupal core . Go to your app , select Application Settings -> App Settings. Now set WEBSITES_ENABLE_APP_SERVICE_STORAGE =true ü Design and then implement your deployment strategy for your application . ü Create a MySQL or PostgreSQL database depending on what database driver your application is using with Azure database for MySQL . o If you are migrating an existing application from on-premise or other cloud service provider , import your database content in the database. ü Browse your application ü If the application does not load as expected , turn on diagnostic logs. ü Fix the docker image based on your investigation and update your Docker image. If you are planning to migrate a WordPress or Joomla or Moodle CMS solution , the process is exactly the same except for the custom image you plan to use . Here are some samples you can use : Custom image with Alpine-PHP-MySQL Custom image with Apache-PHP-MySQL Performance There are multiple bake some caching into your docker image , such as using PHP 's caching options such as : Server level caching based on which web server you are using leverage any modules or configuration that can help boost performance. Framework level caching such as PHP supports various options for caching APC if using Apache (or APCu if using Nginx ) Opcache Using Compression , for example including mod_deflate apache module helps with boosting performance on your application running on Apache web server by reducing the bandwidth on the file and reduces load on the server . This differs based on your web server Enable back-end database caching using Azure Redis Cache service. If you are not using auto-scale feature with web app for containers , you can run a local redis baked into your docker image. Note this will only work if your app is running on one instance Add a CDN to boost performance of your app. Other Configurations Here are a few other configurations you can add to you application Add a Custom domain Bind an SSL certificate ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/11/06/Running-a-popular-Content-management-solution-on-Web-App-for-Containers.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Azure Functions Proxies is now Generally Available",
+ "excerpt":" Alex Karcher 11/15/2017 12:30:22 AM Functions Proxies is an API toolkit built into Functions to enable you to build APIs faster! Proxies makes it easy to perform simple API operations, like nesting multiple Functions together under one API, as well as API fundamentals, like mock APIs, OpenAPI definitions, and monitoring. Since preview we’ve gotten a lot of awesome feedback and responded with some new functionality to make Proxies even better. We’re now releasing Proxies under General Availability today, November 15th. Check out what’s new in Proxies at Connect() New Portal Experience for Proxies Request and response overrides can now be set in the portal Modify input request to send different HTTP verbs, headers, or query parameters to a backend service Replace backend response status code, headers, and body Mock API support in Proxies Using the new editor, you can create mock APIs. You do this by using only response overrides and no backend URL. Mock APIs allow you to create a simple API at your real REST endpoint, allowing developers to start testing API integrations while the API is still under development. Functions Core Tools (CLI) Support for Proxies The Functions Core Tools are our set of CLI tools for locally developing Functions, and they now support authoring and running Proxies! Get started with a new proxy using Function proxy create --name <yourproxyname> When prompted for a template, choosing SampleProxy will create a simple proxy to call httpbin.org/ip and returns your public IP address. Choosing RequestResponseOverride will create a simple mock API that returns a sample body and header. Note that the template uses “localhost” to reference a local function. This will allow the same Proxy to work in the cloud, once the Function App has a different hostname. Read more about developing locally in our docs. Application Insights Support Proxies will now publish telemetry to Azure Application Insights when App Insights is enabled for your function App. This allows for real time analytics steaming, as well as rich historical analysis. With Proxies you can not only measure your serverless API, but also proxy a legacy API and leverage App Insights to measure that API. Read more about our Application Insights support in Functions in the docs. OpenAPI Support Proxy rules will now show up in OpenAPI definition templates generated in Functions! A completed OpenAPI definition allows you to import APIs defined in Proxies into a wide range of tools and services, like Logic Apps, Visual Studio solutions, Power Apps, Flow, and Azure API Management. Read more about Functions OpenAPI support here in the docs. On by Default As a part of the GA release, Proxies will now be enabled by default on all Function Apps! We have also baked in some performance improvements to Proxies. Get Started Now! We’re very excited to release Proxies to the world! We’ve already seen the community build awesome widgets for single page applications, serverless URL shorteners, and much more with Proxies, and we’re excited to see what you build next! Get started at our docs at aka.ms/ProxiesDocs See a video of what’s new with Proxies at Connect() To report bugs, please open an issue on the Azure-FunctionsGitHub repo. Submit any feature requests on our UserVoice For technical questions, please post on the MSDN forums or StackOverflow. The entire Functions engineering team monitors these questions, so you’re sure to get an expert answer. For product news, follow @AzureFunctions For walkthroughs and live sessions, check out Azure Functions on Youtube ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/11/15/Azure-Functions-Proxies-is-now-Generally-Available.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Azure Functions on IoT Edge",
+ "excerpt":" Colby Tresness 11/15/2017 12:30:42 AM Running Azure Functions on IoT Edge Today, we’re very excited to have released the public preview of Azure IoT Edge at our yearly developer conference, Connect();. This adds to the Azure IoT Suite the ability to write code which executes directly on IoT devices, allowing devices to react more quickly to events and spend less time sending messages to the cloud. The simplicity of Azure Functions fits extremely well as a programming model for these scenarios, and from day one users of IoT Edge will be able to write a Function to implement business logic right on their IoT devices. IoT devices are a great addition to the already robust list of places you can run a Function. When Would IoT Edge be Useful? To best answer this question, let’s consider a simple example. Imagine you’re a factory administrator who oversees thousands of machines. With Azure IoT Hub, you can track the status of all your devices, send messages to those devices, receive messages from those devices, and more. Let’s assume you have a system in place receiving telemetry data about the temperature of your machines. To prevent damage due to overheating, you’re running a Function which is listening on all device to cloud messages (through the underlying EventHub.) The result of this is that you get a notification any time a device gets too hot, so you can mitigate and avoid disaster. Since you have thousands of machines sending temperature readings constantly, this is getting expensive and is taking up all your bandwidth. Here’s where IoT Edge comes in – by running your business logic directly on the devices, you only have to send messages to the cloud when an anomaly is detected. So, you augment your current system by adding the IoT Edge Runtime to your devices, writing a Function module deciding whether a message is necessary, and deploying this module to all your devices. You now have the same end system without the massive amount of message passing, and you can sit back and relax knowing your machines will tell you if they are overheating. How do I Run Functions on a Device? Azure IoT Edge is made up of three main components: IoT Edge modules, the IoT Edge runtime, and the cloud based interface. Modules are the units of execution that are pushed to your devices and run your custom code. The runtime is deployed to each device and manages these modules, which are implemented as Docker containers. Figure 1: IoT Edge Experience Illustrated When a user writes a Function they’d like to run on the Edge, we package it up as one of these modules and deploy to your devices for you. We’ve released a Visual Studio Code extension to help you with this – no advanced knowledge of containers is needed, even though it’s a container under the hood. Follow the more detailed instruction set here in order to set up an edge enabled device, write a sample function, get it up and running on said device, and monitor the results. Looking Forward The ability to write code which executes on IoT devices is an exciting addition for Azure users. For public preview, only C# Functions are supported, but we’re looking to add the ability to write Functions in more languages as we move towards GA. Also note that for public preview Functions won’t run on devices with ARM distributions of Linux. Be sure to visit the more detailed IoT Edge preview documentation, and try running a Function on the Edge! Also, please feel free to engage either me or the overall Functions team on Twitter with any questions: @ColbyTresness @AzureFunctions Reference Code The below code is an example of a Function reacting to IoT Edge events – parsing a message to find a machine’s temperature, checking if its over a threshold, and appending an alert if it is. Code Sample 1: The Run Method of a Function Reacting to IoT Edge Events ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/11/15/Azure-Functions-on-IoT-Edge.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "The Azure Functions on Linux Preview",
+ "excerpt":" Daria Grigoriu 11/15/2017 12:30:20 AM The new Azure Functions on Linux preview enables local Azure Functions development on Linux and Mac platforms to seamlessly translate to cloud hosting on Linux across a broader choice of hosting options. The Linux hosting model for Azure Functions is based on Docker containers which brings greater flexibility in terms of packaging and leveraging app specific dependencies. This is another stepping stone in the journey to run Azure Functions anywhere and to enable reuse of your Function App code assets. Functions on Linux can be hosted in a dedicated App Service tier in 2 different modes: You bring the Function App code and we provide and manage the container, no specific Docker related knowledge required. You bring your own Docker container including the Azure Functions runtime 2.0, specific dependencies, and Function App code. Please note that charges for the dedicated App Service Plan you select will apply to the preview as published on the App Service pricing page. With the Azure Functions on Linux preview you should be able to run any Azure Functions scenarios supported by the Azure Functions runtime 2.0. Notes for known Azure Functions runtime 2.0 limitations are available at this link. Support for the Azure Functions on Linux preview is available with the Azure Portal and the Azure CLI. This blog post will focus on the Azure CLI for creating Azure Functions resources. The following steps are required regardless of the hosting mode selected: Install the latest version of the Azure CLI. Run az login to access your Azure account. Create Azure resources: # Create a Resource Group az group create -n rg-name -l \"South Central US\" # Create a Linux App Service Plan (use S2 or S3 as the sku value for larger VMs) az appservice plan create -n plan-name -g rg-name --is-linux -l \"South Central US\" --sku S1 --number-of-workers 1 # Create a storage account az storage account create -n storage-name --location \"South Central US\" --resource-group rg-name --sku Standard_LRS Host Function App content via an App Service managed container To host Function App content via an App Service managed container first create a Linux Function App: # Create a Linux Function App az functionapp create -n fun-app-name -g rg-name -p plan-name -s storage-name You can manage the Function App in the Azure Portal and deploy Function App content using your preferred workflow. Read more about this hosting mode in our App Service managed container for Azure Functions documentation. Host a custom Azure Functions container To create a Function App pointing to a specific container image use the example below (referencing the latest Azure Functions on Linux starter image): # Create a Linux Function App pointing to a specific container image az functionapp create -n fun-app-name -g rg-name -p plan-name -i microsoft/azure-functions-runtime:2.0.0-jessie -s storage-name You can manage the Function App in the Azure Portal. The Function App content however is not editable in the Azure Portal when using a custom container. To create your own container image, you must install a few prerequisites: Docker .NET Core 2.0 The latest azure-functions-core-tools: npm i -g azure-functions-core-tools@core Please note that app specific configuration can be included in the Dockerfile or managed as App Settings for the Function App. Once the prerequisites are installed you can follow these steps: Create a Function App directory locally. Generate a Dockerfile and optionally a sample function: func init . --docker --sample func start Build your container image and optionally test your Function App running in a container locally: docker build -t my-functions. docker run -p 8080:80 my-functions Publish your container image to an online registry such as Docker Hub: docker login docker tag my-functions my-repo/my-functions docker push my-repo/my-functions Read more about this hosting mode in our custom Azure Functions containers documentation. You can also run your Function App in a container on other container-based hosting platforms such as Azure Container Instances: az container create --name <your name=\"\" container=\"\"> --image <your alias=\"\" hub=\"\" docker=\"\">/<your name=\"\" image=\"\"> --resource-group <your name=\"\" group=\"\" resource=\"\"> --ip-address public Known issues for this preview are listed on the Azure Functions wiki. To ask questions or share issues with the engineering team for the Azure Functions on Linux preview please use the Azure Functions MSDN forum. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/11/15/The-Azure-Functions-on-Linux-Preview.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "PHP updated to latest versions",
+ "excerpt":" Eric Stenson (Microsoft) 12/1/2017 12:55:27 PM PHP updated to latest versions As of December 2017, Azure App Service has updated the PHP stacks to the latest available versions. For information on the changes in the new versions, please see the change logs on the PHP website. PHP Version Change log 5.6.32 http://www.php.net/ChangeLog-5.php#5.6.32 7.0.25 http://www.php.net/ChangeLog-7.php#7.0.25 7.1.11 http://www.php.net/ChangeLog-7.php#7.1.11 ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/12/01/PHP-updated-to-latest-versions.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Announcing Azure Functions Runtime preview 2",
+ "excerpt":" Andrew Westgarth 12/5/2017 10:22:56 AM Customers have embraced Azure Functions because it allows them to focus on application innovation rather than infrastructure management. The simplicity of the Functions programming model that underpins the service, has been key to enable this. This model that allows developers to build event-driven solutions and easily bind their code to other services while using their favorite developer tools, has good utility even outside the cloud. [caption id=\"attachment_6595\" align=\"aligncenter\" width=\"800\"] Azure Functions Runtime preview 2 portal showing an Azure Function running against the V2 runtime.[/caption] Today we are excited to announce the second preview of Azure Functions Runtime, building on the first preview and feedback from customers, which brings the simplicity and power of Azure Functions to on-premises. Azure Functions Runtime Recap The Azure Functions Runtime provides a method for customers to take advantage of the Functions Programming model on-premises within their own organization or datacenter. Offering a consistent development experience with the public cloud service, customers can use the Functions portal or Visual Studio to develop and publish Function Applications on-premises. This also enables customers to experience Functions-as-a-Service before committing to the cloud and also enabling customers to easily translate their code assets to the cloud when they move. Azure Functions Runtime consists of two pieces, the Management Role and the Worker Role. As the names suggest, these two are for managing and executing functions code respectively. You can scale out your Functions by installing the Worker Role on multiple machines and take advantage of spare computing power. What’s New? This release brings further improvements and features to our on-premises audience: Support for Azure Functions runtime 2.0, known limitations of the v2.0 runtime are available at this link. This enables you to write functions in C# (.NET Standard) or JavaScript Hosting of v2 Functions on Windows Nano containers, providing a streamlined, lightweight experience. [caption id=\"attachment_6585\" align=\"aligncenter\" width=\"800\"] Create new function app in Azure Functions Runtime preview 2[/caption] Updates to v1 Functions including language support for C#, F#, JavaScript and PowerShell, which are still executed within Windows Server Core containers. [caption id=\"attachment_6605\" align=\"aligncenter\" width=\"800\"] Templates available to v1 functions in Azure Functions Runtime preview 2[/caption] Updated Portal experience Support for multi-tenancy, enable multiple users to use the same infrastructure and portal to work on their own function apps in isolation Customers can specify their own custom DNS name for the Azure Functions Runtime portal and can work behind a load balancer The ability to run alongside additional versions of Docker for Windows already deployed Ability to reset installation to factory defaults Requirements The Azure Functions Runtime Worker Role is deployed in a Windows Container. As such it requires that the host machine is running Windows Server 2016 or Windows 10 Creators Update. If deployed in a virtual machine, it must have nested virtualization support. Looking Forward We are continuing to shape the direction of our on-premises offering of Azure Functions, based on customer feedback during preview. We are interested in hearing your feedback and use cases as we move towards a GA Release. We’re excited to see the types of applications you are building and the types of workloads you envisage running in Azure Functions Runtime. Please feel free to engage with me via the comments or Twitter regarding your needs and feature requests for Azure Functions Runtime in on-premises scenarios. @apwestgarth How do I get started? Please download the Azure Functions Runtime preview 2 installer. For details, please see the Azure Functions Runtime documentation. We would love to hear your feedback, questions, comments about this runtime through our regular channels including Forums, StackOverFlow, or Uservoice. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/12/05/Announcing-Azure-Functions-Runtime-preview-2.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "November 2017 App Service Update",
+ "excerpt":" Byron Tardif 12/12/2017 12:20:36 PM New create function experience We have a brand new function creation experience that includes among other improvements the ability to search templates by keywords as well as filtering templates by language and scenario. Functions on Linux App Service Plans You can now select Linux App Service plans to host your Function apps. You can read more about this scenario here: The Azure Functions on Linux Preview Support for HTTPS Only This was one of the most requested features in our Uservoice forum and it is now available in production. This feature can be found under Custom Domain in the left menu and works for apps hosted on Windows as well as Linux App Service Plans. When this feature is enabled all traffic reaching an HTTP hostname in your app will be redirected to it’s HTTPS equivalent. Make sure all custom hostnames have a valid SSL binding to avoid browser validation errors. This feature also includes the ability to add bindings to existing hostnames directly from this blade. Quick Start refresh We have updated the App Service Quickstart for Windows and Linux based apps, scenario cards now link to existing scenario documentation on https://docs.microsoft.com/azure/app-service/ where they are frequently updated and provide a lot more content and more advanced scenarios. If you have any questions about any of this features or App Service in general be sure to check our forums in MSDN and Stack Overflow. For any feature requests or ideas check out our User Voice ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/12/12/November-2017-App-Service-Update.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "PHP Minor Version Update for January 2018",
+ "excerpt":" Jennifer Lee (MSFT) 12/14/2017 10:10:23 AM Latest version updates to PHP In January 2018, Azure App Service will update the PHP stacks to the latest available versions. For information on the changes in the new versions, please see the change logs on the PHP website. PHP Version Change log 7.0.26 http://www.php.net/ChangeLog-7.php#7.0.26 7.1.12 http://www.php.net/ChangeLog-7.php#7.1.12 ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2017/12/14/PHP-Minor-Version-Update-for-January-2018.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "My Backups are failing, Let's open a support ticket",
+ "excerpt":" Ahmed Elnably 1/2/2018 1:25:31 PM Actually wait! A big percentage of the backup failures (More than 42%) can be fixed in minutes, and more importantly without even opening a support ticket. Step 1: Figure out what is the failure. From the backup blade, click on the failing backup and check the Log Details Step 2: Check the following table. Error Fix Storage access failed. {0} Delete backup schedule and reconfigure it The website + database size exceeds the {0} GB limit for backups. Your content size is {1} GB. Use a backup.filter file to exclude some files from the backup, or remove the database portion of the backup and use externally offered backups instead https://aka.ms/partial-backup Error occurred while connecting to the database {0} on server {1}: Authentication to host '{1}' for user '<username>' using method 'mysql_native_password' failed with message: Unknown database '<db name>' Update database connection string Cannot resolve {0}. {1} (CannotResolveStorageAccount) Delete backup schedule and reconfigure it Login failed for user '{0}'. Update database connection string Create Database copy of {0} ({1}) threw an exception. Could not create Database copy Use admin user in connection string The server principal \"<name>\" is not able to access the database \"master\" under the current security context. Cannot open database \"master\" requested by the login. The login failed. Login failed for user '<name>'. Use admin user in connection string A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server) Check that the connection string is valid, whitelist site’s outbound IPs in database server settings Cannot open server \"<name>\" requested by the login. The login failed. Check that the connection string is valid Missing mandatory parameters for valid Shared Access Signature Delete backup schedule and reconfigure it SSL connection is required. Please specify SSL options and retry. when trying to connect Please use the built in backup feature in Azure MySQL or Azure Postgressql. Step 3: The failure is not in the table Well ... Please open a support ticket. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/01/02/My-Backups-are-failing,-Let's-open-a-support-ticket.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "PHP Minor Version Update for February 2018",
+ "excerpt":" Jennifer Lee (MSFT) 1/8/2018 10:07:20 AM Latest version updates to PHP In February 2018, Azure App Service will update the PHP stacks to the latest available versions. For information on the changes in the new versions, please see the change logs on the PHP website. PHP Version Change log 5.6.33 http://php.net/ChangeLog-5.php#5.6.33 7.0.27 http://www.php.net/ChangeLog-7.php#7.0.27 7.1.13 http://www.php.net/ChangeLog-7.php#7.1.13 ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/01/08/PHP-Minor-Version-Update-for-February-2018.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Change domain contact information for App Service Domain",
+ "excerpt":" mksunitha 1/10/2018 10:31:39 AM If the registrant of the domain contact information has changed and needs to be updated , follow the guidance below to make the necessary changes to make sure there is continuity of your use of the domain or any certificates associated with that domain. Follow these steps to update the contact information of your domain: Login to Azure portal . Go to your domain within the Azure portal. Click on Advance management to go to advance management portal. Select your domain that needs to be updated and Click on Manage Click on view personal information if it is hidden . Click on Edit to modify the contact information for the registrant of the domain. Click on Save to save the changes . When the email of the contact information is updated , you will receive an approval request to the new email address updated in the contact information for the domain . Please complete this process to use the new email address with the domain. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/01/10/Change-domain-contact-information-for-App-Service-Domain.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Demystifying the magic behind App Service OS updates",
+ "excerpt":" Oded Dvoskin 1/18/2018 12:10:09 PM Well, that’s a loaded title for a blog post! But here’s the thing, we’ve been asked many times about what actually goes on behind the scenes when App Service updates the resources hosting App Service apps. First, we need to mention briefly what is App Service. App Service is a PaaS (Platform as a Service) offering that allows customers to focus on their code, rather than having to worry about managing the underlying Virtual Machines and other resources with the latest security updates, OS patches and so on. Still, those resources don’t get magically updated, do they? That is the beauty in a managed platform — we do that for our customers! App Service applies monthly updates to the resources, making sure our customers’ code is always running on the most recent security patches and OS versions available. As an example, this was extremely useful for our customers when the latest Spectre and Meltdown vulnerabilities were announced. Customers did not have to take any action because the service was updated automatically. To give some additional technical details and demystify the process, we’ll outline here what happens when the App Service updates takes place , but first we’ll go through some key concepts: App (or site) – the structure that manages the code that is deployed for users. Instance – The Virtual Machine hosting the code. It can be in variations of memory allocation, CPU etc. Upgrade Domain – Collections of VMs in a given Scale Unit that are taken offline at the time of an update. Scale unit / Stamp – The collection of Virtual Machines in a given region. Region (or datacenter) – An area in the world where there is a collection of Virtual Machines managed by Microsoft. As of writing this blog, Azure is deployed in 42 regions worldwide. Paired Regions – Two Azure regions which within the same geography which Azure guarantees not to update simultaneously. App Service update cycle: First and foremost, it’s important to note that App Service assures and maintains its SLA at all times, even during updates. Though we try our best, the upgrade process can sometimes run for over 18hrs which causes the upgrade activity to spill over into business hours. Following our robust best practices, which can be found under the Diagose & Solve blade for your resource or in this article, will ensure minimal SLA impact even during platform upgrades. Before beginning worldwide updates, we deploy first to a private region which is not commonly accessible. Only after testing is validated there, we begin to roll out to datacenters across the globe. Our typical time for completing updates worldwide is about 10 business days, which allows us to deploy during each region’s off hours and also avoid deploying to Paired Regions at the same time (for example, East US and West US). When you are planning your app’s infrastructure for high availability and looking to deploy in multiple regions, it’s always a good idea to deploy to the paired region of your target region, since if there is a platform issue in the update, it won’t affect the paired region. After mitigating any issue, we will only then continue to the paired region, after the first is complete. As a managed service, we always leave a buffer in our capacity for new resources, for scaling operations on existing resources, in case instances become unhealthy and force us to move apps to other instances and of course for our OS update process, detailed here. When the update reaches a specific region, we update available instances without apps on them, then move the apps to the updated instances, then update the offloaded instances. This move results in a cold start, and there may be a performance hit associated with this. Application binaries are loaded to the new Virtual Machine, and libraries are loaded from the disk. Externally the user will see a one-time delay in responses to requests to the app, after which the site will run normally. The delay is dependent on many things, mainly on the complexity of the app, the framework it’s built on, and dependencies. You can reduce the impact of cold starts on your application by properly configuring the App Initialization model, as detailed in this blog. Thanks for reading and if you’d like to try App Service yourself, create your first app using one of our quickstarts and see how easily you can deploy your app and change your code right away. If you have questions about App Service, please reach out to us through the developer forums, on MSDN or Stack Overflow. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/01/18/Demystifying-the-magic-behind-App-Service-OS-updates.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Exciting New Features in App Service Diagnostics",
+ "excerpt":" Jennifer Lee (MSFT) 1/18/2018 10:10:47 AM Have you checked out App Service diagnostics yet? In November 2017, we announced the general availability of App Service diagnostics, our new self-service diagnostic and troubleshooting experiencing to help you resolve issues with your web app. Since then, based on your feedback, we’ve enabled several exciting features in the past few months. TCP Connections We added a new tile shortcut! The “TCP Connections” tile shortcut allows you to investigate: Outbound TCP Connections: Graphed over time per instance Connection Rejections: Detects issues with port rejections Open Socket Handles: Open socket count when outbound TCP connections crosses 95% of the machine-wide TCP connection limit. App Service Diagnostics for Linux For all our App Service on Linux users, you can now also use App Service diagnostics to run a health checkup and use the tile shortcuts to analyze issues in performance and availability, such as “Web App Down,” Web App Slow,” and “Container Initialization.” Integration with Application Insights For .NET applications, we have added integration with Application Insights to help you look for relevant exceptions correlating to downtime occurring on your web app. These features are: Application Insights Enabled: Easily check if you have Application Insights enabled (and if you don’t, you can enable it right there). Inside the “Web App Down” tile, if there are exceptions available, you will be able to see the exceptions thrown from Application Insights, sorted by count so you know which ones are most important. Open App Service Diagnostics To access App Service diagnostics, navigate to your App Service web app in the Azure portal. In the left navigation, click on Diagnose and solve problems. To learn more, check out these links: Connect() Video: Want to see a demo of App Service diagnostics? Check out this video to learn more about \"What's New with App Service\" (where I demo App Service diagnostics starting at 1:50). Azure Friday Video: One of our App Service diagnostics engineers, Steve Ernst, joins Scott Hanselman to diagnose and troubleshoot a real case of a web app having issues. Azure.com Blog Announcement Documentation ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/01/18/Exciting-New-Features-in-App-Service-Diagnostics.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "az webapp new - where new is always better!",
+ "excerpt":" Ahmed Elnably 2/6/2018 2:31:20 PM This blog post has old info, the new version is here. The App Service team have been hard at work creating a new experimental create and deploy experience for Azure App Service. We released a new Azure CLI extension that adds a new command called new (have you seen what we did there!?). The new command (Which is currently in Preview) enables the user to create and deploy their Node.js or .NET Core app using a single command. For Node.js we check for the existence of a package.json file in the code root path to indicate it is a Node.js app. For .NET Core we check for the existence of a *.csproj file with netcoreapp as the TargetFramework [caption id=\"attachment_7095\" align=\"alignnone\" width=\"586\"] Click on the gif to see the command in action[/caption] In the case of Node.js app the command does the following: Create a new resource group (in Central US, you can use the --location to change the region) Create a new Linux single VM small App Service plan in the Standard SKU (in Central US) Create a Linux webapp Deploy the content of the current working directory to the webapp using Zip Deployment In the case of .NET Core app the command does the following: Create a new resource group (in Central US, you can use the --location to change the region) Create a new free Windows App Service plan (in Central US) Create a Windows webapp Deploy the content of the current working directory to the webapp using Zip Deployment To Install the Azure CLI tools refer to their documentation. To Install the extension: az extension add --name webapp To update the extension with the latest fixes and new languages support (Current version is 0.1.0): az extension update --name webapp To know what the command will do without creating anything: az webapp new --name [app name] --location [optional Azure region name] --dryrun [caption id=\"attachment_7115\" align=\"alignnone\" width=\"626\"] Click to see --dryrun in action[/caption] To use the new command: az webapp new --name [app name] --location [optional Azure region name] To update your app content - Just rerun the command you used to create the app (including the --location argument): az webapp new --name [app name] --location [optional Azure region name] To submit feedback or submit an issue please open an issue in the Azure CLI extensions Github Project page. Road Map - also tracked here: Add better support to update the app with new changes Add more languages to the supported list Add support to Azure Functions ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/02/06/az-webapp-new-where-new-is-always-better!.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Understanding Serverless Cold Start",
+ "excerpt":" Colby Tresness 2/7/2018 6:00:42 AM “Cold start” is a large discussion point for serverless architectures and is a point of ambiguity for many users of Azure Functions. The goal of this post is to help you understand what cold start is, why it happens, and how you can architect your solutions around it. To provide this explanation, we’ll be going deep into some technical details of how Azure Functions works behind the scenes. Consumption Plan vs. Dedicated Plan Azure Functions comes in two main flavors – consumption and dedicated. The difference between the two is important – choosing one over the other not only dictates the behavior of your application, but also how you’re billed. The consumption plan is our “serverless” model – your code reacts to events, effectively scales out to meet whatever load you’re seeing, scales down when code isn’t running, and you’re billed only for what you use. Plus, all of this happens without you thinking about what Azure is doing behind the scenes. The dedicated plan, on the other hand, involves renting control of a Virtual Machine. This control means you can do whatever you like on that machine – it’s always available and might make more sense financially if you have a function which needs to run 24/7. If you’re curious and want a more detailed explanation, check out our documentation. What is Cold Start? Broadly speaking, cold start is a term used to describe the phenomenon that applications which haven’t been used a while take longer to start up. In the context of Azure Functions, latency is the total time a user must wait for their function – from when an event happens to start up a function until that function completes responding to the event. So, more precisely, a cold start is an increase in latency for functions which haven’t been called recently. When using Azure Functions in the dedicated plan, the functions host is always running, which means that cold start isn’t really an issue. So, our scope is narrowed to functions running the serverless consumption model. Let’s go deeper. What Happens When I Write a Function? Suppose you’re writing your first function. You’ve provisioned a function app, created your function based on one of our templates, and are modifying it to fit your business needs. You save, and now wait for your specified trigger to initiate your function. Later, your function triggers. When this process begins, since you haven’t yet executed anything, all your code and config exist only as files in Azure Storage. Let’s pause and think through broadly what still needs to happen for your code to run: Azure must allocate your application to a server with capacity The Functions runtime must then start up on that server Your code then needs to execute Steps 1 and 2, if done unintelligently, can take a while - spinning up and configuring a server takes time. To make this experience better for users, instead of starting from scratch every time, we’ve implemented a way to keep a pool of servers warm and draw workers from that pool. What this means is that at any point in time there are idle workers that have been preconfigured with the Functions runtime up and running. Making these “pre-warmed sites” happen has given us measurable improvements on our cold start times – things are now on the order of 3-4 times faster. Now, let’s go back and walk through a more detailed view of what happens when you trigger the execution of a function when resources haven’t yet been allocated. What Happens During a Cold Start Azure allocates a preconfigured server from the pool of warm workers to your app. This server already has the Functions runtime running on it, but it is unspecialized. This worker becomes specialized by configuring the Functions runtime in ways that are specific to your app. A few things happen to do this specialization, including: The Azure Functions infrastructure mounts your Azure Files content to the worker you’ve been assigned App settings specific to your function app are applied to the worker The Functions runtime resets, and any required extensions are loaded onto the worker. To figure out which extensions to load, the runtime reads the function.json files of any function in the function app. For instance, this happens if you’re using Durable Functions, or if you have input or output bindings. The functions themselves are loaded into memory by language providers. This will take a varying amount of time based on the size of your application. Your code runs. If you’ve executed your function recently, #1-4 have already happened – the resources are already allocated, and your site is “warm.” As you can imagine, in this scenario things are considerably faster. We deallocate resources after roughly 20 minutes of inactivity, after which your next call will be a cold start and this entire process will happen again. This is illustrated above. Is the team making any more improvements? Yes! This post is simply a point in time (February 2018) analysis of how things work, and many specifics are subject to change. As evidence, we recently released an update to the runtime and for our GA languages we’re seeing a further 50% improvement on cold start times. I won’t go super deep on it here, but this update fixed a regression in our native image generation. For more details, read up on NGEN or check out the release itself (we’re fully open source!) How Can I Improve My Code to Help Avoid Long Cold Starts? Now that we have a baseline understanding of what’s happening behind the scenes to cause cold start, we can start to address how to architect your solutions to avoid it. Language: First and foremost, use our generally available languages – C#, F#, and JavaScript. We have several experimental languages which aren’t fully supported and optimized – most of them actually spin up a new process on every execution, which impacts latency a great deal. Also, it’s important to note that any language running in our 2.0 runtime is in preview and also hasn’t been optimized fully. We expect these languages to perform better in the future, but for now, stick to the GA languages mentioned above. For more specifics, see our documentation. Write Lightweight Code Dependencies: When you deploy your code, your dependencies are added as files to your application. As outlined in step 4 above, all code needed by your app eventually gets loaded into memory, which takes longer with a larger application. So, if you have a ton of dependencies, you’ll get a longer cold start due to a) increased time for I/O operations from Azure Files, and b) longer time needed to load a bigger app into memory. This is a thing we see all the time for folks writing functions in JavaScript – npm trees can get huge. Not only does this increase the size of your app, but also increases the number of files that Azure Files has to handle, which causes further slowdown. For this scenario in particular, we’ve released a tool to help: check out Funcpack to learn more! Efficient Code: Sometimes the answer is simply writing more efficient code. There are a few approaches to note here – first, try to make as much processing as possible asynchronous. Functions won’t perform well if you have a heavyweight synchronous call blocking your code from completing. Along this vein, try to minimize the amount of work that has to happen before your code starts up and avoid code which consumes a lot of CPU. If you’re concerned about this yourself, we recommend trying out Application Insights – it’s a fantastic monitoring tool and can help isolate application slowdown from platform slowdown. Avoiding Cold Start Altogether Dedicated Mode: As mentioned before, running Functions in an App Service Plan alleviates these issues since you control what happens on your VM. This is slightly more expensive, and isn’t serverless, but if your solution has a hard requirement for low latency on every individual call, consider using the Dedicated mode. Feedback Feedback is always welcome – if you want to tell us what you think or reach out to the product team directly for any other reason, engage with us on Twitter or GitHub! @AzureFunctions @ColbyTresness Azure Functions ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/02/07/Understanding-Serverless-Cold-Start.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "January 2018 App Service update",
+ "excerpt":" Byron Tardif 2/8/2018 5:20:54 PM Welcome to a new and exciting year of App Service updates, December 2017 was a quality milestone for the App Service team and over the break we delivered over 60 general quality of life and performance improvements for both the App Service and Functions experience in the Azure portal. Now that we are in February it’s time to share some of the improvements and new features we delivered in January 2018 Application Settings UX refresh The new application settings ux uses the same code base across App Service, Azure Functions and Web Apps for Containers. It provides a consistent look and feel, improves performance and allows us to deliver improvements and new features across all 3 products with less duplicated work. My SQL in-app data import My SQL in-app now lets you import as well as export the database content. This makes it easy to migrate existing databases in and out of MySQL in-app. New FAQ UI We have a new experience that provides in context help content filtered to the specific feature you are using. The content is driven by the App Service documentation and it lets you get straight to what you need without having to search for it. Web App on Linux support for .NET Core 2.0 Web Apps on Linux now has built in support for .NET Core 2.0 If you have any questions about any of this features or App Service in general be sure to check our forums in MSDN and Stack Overflow. For any feature requests or ideas check out our User Voice Previous updates: November 2017 App Service Update October 2017 App Service Update September 2017 App Service Update August 2017 App Service update ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/02/08/January-2018-App-Service-update.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Troubleshooting Tools for App Service Certificate",
+ "excerpt":" mksunitha 2/20/2018 11:26:25 AM This blog post describes the various tools available to you to debug any issues with App Service Certificates resources that you may be using with Web App or other Azure Services. SSL is a critical part of your application and when configuring the certificate or renewing the certificate there can be a few issues you might run into . These tools listed below can help provide you information to self-debug the issue in most cases. Verify Status of your Certificate : Check if the Status of your certificate is ready for use. Sometimes the certificate might have Domain verification step pending and this status tile can help provide information on what steps you need to take There are many different states the certificate can be in : Certificate Denied : Domain verification was not completed in 15 days causing the certificate to be in denied state. Certificate will not be billed. Purchase a new certificate with same domain to resolve this . Certificate cannot be restored. Certificate Expired : Certificate has expired . If auto renew was enabled and the certificate still expired , then credit card payment may have failed for the subscription. In this case , you need purchase a new certificate with the desired domain to resolve the issue.Certificate cannot be restored. Domain verification required : Domain verification is pending . Click on \"Certificate Configuration\" and complete STEP 2 for domain verification. If Domain verification option is not working , select Manual verification to complete this step. If Domain verification is not completed in 15 days , certificate will be in denied state Key Vault out of sync: Key vault can be out of sync if it was deleted , moved to another subscription or if the subscription was in suspended/canceled state. Choose your app service certificate in the Azure portal , click on Certificate Configuration and complete STEP 1 to assign a new Key Vault resource to app service certificate. Note if you are bringing you external certificate via Key Vault using this blog post , you must reconfigured to use the correct secret with the app service certificate. App service certificate looks for secret name and does not support using \"certificate object\" in key vault. This is a limitation and we are working in fixing it Debug using Resource Explorer : You can look at the certificate order state in resource explorer https://resources.azure.com . Select your subscription -> Providers -> Microsoft.CertificateRegistration->Certificateorders . This lists all the certificate orders within the subscription. Search for a given certificate and look at the \"provisioingstate\" property . If Succeeded , it will be ready to use state. If not , resolve the issues based on the states mentioned earlier in this post. Debug using Timeline : View the list of historical activities or operations that have occurred on App Service Certificate resource using the Timeline feature to help debug the issue Sync a Certificate : The Web App service runs a background job that periodically (once a day ) that syncs all App Service certificate. Hence when you rotate or update a certificate, sometimes the application is still retrieving the old certificate and not the newly updated certificate. This is because the job has not run to sync the certificate resource. To force a sync of the certificate , you can click on Rekey and Sync setting and then click on Sync button . Refer to FAQs documentation : Get access to appropriate documentation to App Service certificates to help resolve the issue with Configuration , Rekey and Sync , Renewal etc . If the above tools dont help you resolve the certificate related issues , then please contact Microsoft Azure Support. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/02/20/Troubleshooting-Tools-for-App-Service-Certificate.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Deep Dive into TCP Connections in App Service Diagnostics",
+ "excerpt":" Jennifer Lee (MSFT) 3/1/2018 8:51:29 AM Note: This information below only applies to Windows web apps on App Service. Recently, we released the TCP Connections tile shortcut in App Service diagnostics. In this blog, we will walk through the implications of having unhealthy TCP Connections and how you can analyze them using App Service diagnostics. Why should you care about TCP Connections? Let's say that you have created two web apps on the App Service Plan, and both are breaking. An example of when TCP Connections can cause this behavior in your web apps could be that one app is leaking a lot of socket handles and ends up hitting the machine wide TCP Connection limit. App Service enforces limits on the number of outbound connections that can be outstanding at any given point in time. When web apps run into these connection limits, they will start intermittently failing because calls to those remote endpoints will fail, causing downtime. You’ll frequently see errors like the following: “An attempt was made to access a socket in a way forbidden by its access permissions aaa.bbb.ccc.ddd.” The maximum connection limits are the following: 1,920 connections per B1/S1/P1 instance 3,968 connections per B2/S2/P2 instance 8,064 connections per B3/S3/P3 instance 16,000 connections per I1/I2/I3 instance For more information, read the “Network Port Capacity for Outbound Network Calls” section of Azure - Inside the Azure App Service Architecture and the row, \"IP connections,\" in the \"App Service Limits\" section of Azure subscription and service limits, quotas, and constraints. TCP Connections Walkthrough To examine your TCP Connections more closely, click on the \"Diagnose and solve problems\" tab in the left hand menu. Then, select the \"TCP Connections\" tile shortcut. Upon opening the TCP Connections, you can quickly see three levels of data: TCP Connections, Connections Rejections, Open Socket Handles. If it’s healthy, there will be a green checkmark. If it’s unhealthy, there will be an orange exclamation mark. TCP Connections Here, you can monitor the total connections on your instances and the state of the connections, which include TIME_WAIT, ESTABLISHED etc. If your web app has high outbound connections (> 1500 outbound connections), you will see the IP addresses’ first three octets and the port number in the Summary. By examining the port number, you can determine what type of remote service is causing the high outbound connections. Port Number Service 1433 SQL 80 or 433 Web Service Connections Rejections Check if there are any port rejections. If your web app failed to make an outbound TCP connection because the machine-wide TCP Connection limit was hit, we will highlight that in the Summary and associated graph. Open Socket Handles Here, you can determine which web app is causing a socket leak if you have multiple web apps in your App Service Plan. If your web app has leaking connections, you will see the process name, process ID, site name, and number of open handles. We will highlight the process that is causing the maximum damage in the Summary. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/03/01/Deep-Dive-into-TCP-Connections-in-App-Service-Diagnostics.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Major Version Updates to Node and PHP on App Service on Linux",
+ "excerpt":" Jennifer Lee (MSFT) 3/5/2018 9:18:45 AM We've recently released new versions to Node and PHP on App Service on Linux! For Node, we have added: 9.4 8.9 8.8 8.2 For PHP, we have added: 7.2 If you already have an existing web app that you would like to update to the new versions, navigate to the \"Application Settings\" from the left-hand menu of your web app and select the new version in the \"Stack\" dropdown. If you're creating a new web app, check them out in the \"Runtime Stack\" dropdown. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/03/05/Major-Version-Updates-to-Node-and-PHP-on-App-Service-on-Linux.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Azure App Service on Azure Stack Update One Released",
+ "excerpt":" Andrew Westgarth 3/12/2018 3:52:20 PM This morning we released the first update to Azure App Service on Azure Stack. This release updates the resource provider and brings the following key capabilities: Support for Highly Available deployments of Azure App Service on Azure Stack The Azure Stack 1802 update enabled workloads to be deployed across fault domains. Therefore App Service infrastructure is able to be fault tolerant as it will be deployed across fault domains. By default all new deployments of Azure App Service will have this capability however for deployments completed prior to Azure Stack 1802 update being applied refer to the App Service Fault Domain documentation Deploy in existing virtual network As a result of customer feedback post release we have now added this capability enabling customers to deploy Azure App Service and communicate with their SQL and File Server resources over a private network. Update the App Service Tenant, App Service Admin and Azure Functions portals. Updates to add .Net Core 2.0 support, additional versions of NodeJS, NPM, PHP, new versions of Git and Mercurial All other fixes and updates detailed in the App Service on Azure Stack Update One Release Notes You can download the new installer and helper scripts: Installer – https://aka.ms/appsvcupdate1installer Helper Scripts - https://aka.ms/appsvconmashelpers Please read the updated documentation prior to getting started with deployment: Before you get started with App Service on Azure Stack Deploy the App Service Resource Provider for new deployments Update the App Service Resource Provider for updating existing deployments ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/03/12/Azure-App-Service-on-Azure-Stack-Update-One-Released.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Deprecating Service Management APIs support for Azure App Services",
+ "excerpt":" Naveed Aziz 3/12/2018 4:50:13 PM At Build 2014, Azure announced RESTful API for resource management called Azure Resource Manager and a shiny new Azure portal. In the years since Azure App Service has implemented support for Azure Resource Manager. If you manage your App Service resources through the portal or through automation against the REST API or any of these SDKs, clients or tools or deploy resources through deployment templates, you are already using Azure Resource Manager. If, however, you also have automation built against the legacy Azure Service Management APIs, this announcement affects you. Azure App Service resource management will be supported only through Azure Resource Manager. Azure Service Management support will be retired on June 30, 2018. The Service Management APIs are archaic and not well suited for the modern cloud. Supporting Service Management APIs any longer will hold us back from delivering premium developer experience and control plane scale. Customers currently using the Service Management APIs will be better served by moving to Resource Manager. Azure Resource Manager has many benefits over Service Management like robust deployment model, role-based access and better API support for existing and new features. For more information, see Difference between Azure Service Manager and Azure Resource Manager. Determining if you are using Azure Service Management APIs A good way to tell if your automation (SDK/tool/client) uses Service Management APIs is to see if that automation uses Web Spaces or Resource Groups to manage (deploy/create/update/start/stop/configure etc.) resources. To uniquely identify and manage resources, automation needs a logical grouping mechanism that is also the uniqueness scope for the resources. For Service Management APIs for Azure App Service that grouping is Web Spaces, while for Azure Resource Manager it is Resource Groups. If your automation (SDK/tool/client) uses Web Spaces to manage resources you are using Azure Service Management and we recommend that you switch to the Azure Resource Manager. UPDATE:: App Service diagnostics now has a detector that can identify any soon to be deprecated APIs called within the last 24 hours on your web app or associated resources. Once the API in question is no longer called, the detector will let show 'green' for that API within 24 hours. From the app service overview blade click on \"Diagnose and solve problems\". Once the detectors have loaded click on \"Deprecating APIs\" under the section \"Management and Configuration\". This will open up a new tab \"Deprecating APIs\" Once the detector execution completes, you will have names of all the API clients/tools used to call the deprecating APIs and the actual calls. Authentication Service Management supports authentication using Azure Active Directory or management certificates. For Resource Manager authentication is built around Azure Active Directory apps and interactive user access. To learn more, see Resource Manager API Authentication. If your automation must use certificates for management, you can achieve that by Authenticating to Azure Resource Manager using AAD and certificates. Resource Deployment Resource Manager has a robust deployment engine with declarative resource description. To understand how the resource deployment differences between the two, see Resource Manager Deployment Model. Resource manager supports resource deployment via deployment templates. Additionally, starting from Microsoft Azure SDK for .NET 2.9, resource deployment via Visual Studio is also supported. For more information, see Deploying resources and code through Visual Studio. Directly calling the API If you want to code against the Resource Manager REST API directly, refer to Azure App Service REST API documentation. ARMClient and Azure Resource Explorer are great tools to play with and discover the shape of the App Service Resource Manager API. For more information on ARMClient, see ARMClient: a command line tool for the Azure API. SDKs and tools Resource Manager offers SDKs and tools in a large set of languages, frameworks and platforms. These include but are not limited to .NET, Node, Java, Ruby, Python, Go, PowerShell and Azure CLI. Detailed documentation, tutorials and examples are available here. App Service Resource Metrics If your automation consumed the App Service resource metrics API, we recommend that you switch over to the Azure Resource Manager Monitoring APIs. While we still offer App Service specific metrics API, we plan on deprecating them soon. The Resource Manager Monitoring APIs are the common way of interacting with metrics across any resource on any service within Azure. For more information, see metrics supported by Azure Monitor. Please make sure to move all your automation and deployment tools to use new API’s before June 30th 2018 so that you do not experience any service interruptions and benefit from superior deployment and management capabilities of Azure Resource Manager. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/03/12/Deprecating-Service-Management-APIs-support-for-Azure-App-Services.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Updating PHP to latest versions",
+ "excerpt":" Eric Stenson (Microsoft) 3/14/2018 12:52:07 PM In the next release of Azure Web Apps, we will update the PHP stacks to the latest available versions. For information on the changes in the new versions, please see the change logs on the PHP website. PHP Version Change log 5.6.34 http://www.php.net/ChangeLog-5.php#5.6.34 7.0.28 http://www.php.net/ChangeLog-7.php#7.0.28 7.1.15 http://www.php.net/ChangeLog-7.php#7.1.15 7.2.3 http://www.php.net/ChangeLog-7.php#7.2.3 ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/03/14/Updating-PHP-to-latest-versions.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "BizTalk Hybrid Connections going end of life May 31, 2018",
+ "excerpt":" Christina Compy (MSFT) 3/20/2018 6:24:08 PM Azure App Service has two features named Hybrid Connections. There is the original BizTalk Hybrid Connections and the newer Azure Relay based App Service Hybrid Connections. BizTalk Hybrid Connections is going end of life May 31, 2018. To avoid problems, you should migrate from BizTalk Hybrid Connections to the new Azure Relay based Hybrid Connections. You can read more about them in Azure App Service Hybrid Connections To migrate your BizTalk Hybrid Connections to the new Hybrid Connections, you need to: Make sure the apps you want to use Hybrid Connections with are running in a Basic, Standard, Premium, Premiumv2, or Isolated App Service plan. Create a new Hybrid Connection using the information in Add and Create Hybrid Connections in your app. The name of the new Hybrid Connection does not have to match the old one but the endpoints should be the same between the new and the old Hybrid Connection. Add the new Hybrid Connection to the apps that are using the BizTalk Hybrid Connection. Upgrade all of your Hybrid Connection Managers to the newest version. The installer for the new Hybrid Connection Manager will upgrade your older instances. You can read more about the new Hybrid Connection Manager here and can download it from the Azure portal in the App Service Hybrid Connections portal. Add your new Hybrid Connections to all of the Hybrid Connection Managers you want to use. After the new Hybrid Connection shows a status of Connected in the portal, delete the older BizTalk Hybrid Connection. The new Relay based Hybrid Connections exist as a service outside of Azure App Service. You can find more details starting with the Overview on Azure Relay. Relay based Hybrid Connections does have a number of improvements over the BizTalk Hybrid Connections. The newer feature uses TLS 1.2, communicates to Azure only over port 443, creates connections based on a DNS name, and has a much easier user experience. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/03/20/BizTalk-Hybrid-Connections-going-end-of-life-May-31,-2018.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Renaming our new command to up",
+ "excerpt":" Ahmed Elnably 3/22/2018 5:12:33 PM We listened to feedback, we decided to change our previously released experimental \"new\" command to be now \"up\". With version 0.2.0 of the extension, \"new\" is no longer available, and you will have to use \"up\" instead. The command (Which is still in Preview) enables the user to create and deploy their Node.js, .NET Core, ASP.NET, Java, or Static HTML apps using a single command. For Node.js we check for the existence of a package.json file in the code root path to indicate it is a Node.js app. For ASP.NET and .NET Core we check for the existence of a *.csproj file with netcoreapp as the TargetFramework. For static HTML we check the existence of a *.html file. The command check for languages in the following order: Node.js .NET Core and ASP.NET Static HTML In the case of Node.js and Java apps the command does the following: Create a new resource group (in Central US, you can use the --location to change the region) Create a new Linux single VM small App Service plan in the Standard SKU (in Central US) Create a Linux webapp Deploy the content of the current working directory to the webapp using Zip Deployment In the case of an ASP.NET, .NET Core, Static HTML app the command does the following: Create a new resource group (in Central US, you can use the --location to change the region) Create a new free Windows App Service plan (in Central US) Create a Windows webapp Deploy the content of the current working directory to the webapp using Zip Deployment To Install the Azure CLI tools refer to their documentation. To Install the extension: az extension add --name webapp To update the extension with the latest fixes and new languages support (Current version is 0.2.0): az extension update --name webapp To know what the command will do without creating anything: az webapp up --name [app name] --location [optional Azure region name] --dryrun To use the new command: az webapp up --name [app name] --location [optional Azure region name] To update your app content - Just rerun the command you used to create the app (including the --location argument): az webapp up --name [app name] --location [optional Azure region name] To submit feedback or submit an issue please open an issue in the Azure CLI extensions Github Project page. Road Map - also tracked here: Add ASP.Net support Add Java support Add more languages to the supported list Add support to Azure Functions ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/03/22/Renaming-our-new-command-to-up.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Announcing the Availability of Azure Functions in National Clouds",
+ "excerpt":" Asavari Tayal 3/28/2018 9:15:53 AM To further our commitment of providing the latest in cloud innovation for each and every one of our customers, we're excited to announce the availability of Azure Functions in three separate national clouds - China, Germany and United States Government. National or sovereign clouds are physically and logically network-isolated instances of Microsoft's cloud service, which are confined within the geographic boundaries of specific countries and operated by local personnel. These clouds offer a unique model for local regulations on service delivery, data residency, access and control. Functions in the national clouds provides the same functionality and features as global Azure. The rich portal experience allows you to create, manage and monitor your functions. You can develop using C#, F# or JavaScript and integrate with a wide variety of services using triggers and bindings. As always, you can pick from a range of tools such as the cross platform CLI, Visual Studio IDE and VS Code to develop, debug and test locally, before deploying your apps to Azure. Known Limitations Currently, Functions in the national clouds can only be hosted in an App Service Plan. Each plan requires you to define a specific region, number of VM instances in that region and size of the VMs that must be dedicated to your apps. If your scenario requires the consumption plan, please let us know by submitting a feature request on UserVoice. Basic monitoring is available through the functions logs and the monitoring tab in the portal. A richer experience with more analytics options will be available once Azure Application Insights is available in the national cloud regions. Next Steps Here are some resources to help you get up and running with Functions: Get started using the docs – Create your first function in the Azure Portal For technical questions, please post on MSDN or StackOverflow. We actively monitor these forums and will be happy to help with your query. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/03/28/Announcing-the-Availability-of-Azure-Functions-in-National-Clouds.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "PHP Minor Version Update for May 2018",
+ "excerpt":" Jennifer Lee (MSFT) 4/7/2018 3:05:23 PM Latest version updates to PHP In May 2018, Azure App Service will update the PHP stacks to the latest available versions (including MSSQL Drivers for PHP 7.2). For information on the changes in the new versions, please see the change logs on the PHP website. PHP Version Change Log 5.6.35 http://www.php.net/ChangeLog-5.php#5.6.35 7.0.29 http://www.php.net/ChangeLog-7.php#7.0.29 7.1.16 http://www.php.net/ChangeLog-7.php#7.1.16 7.2.4 http://www.php.net/ChangeLog-7.php#7.2.4 ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/04/07/PHP-Minor-Version-Update-for-May-2018.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "March 2018 App Service update",
+ "excerpt":" Byron Tardif 4/10/2018 1:31:17 PM New tiles on overview blade Overview blade has been revamped to add quick links for Diagnose and Solve problems, Application Insights and App Service Advisor Free and Shared apps now support HTTPS only configuration Last year we enabled the ability to force HTTPS connection for your apps hosted on app service and we are now extending support to also cover apps hosted in free and shared App Service plans. Quality of life improvements for App Service Certificates and App Service Domains Over the last 2 months we have fixed over a dozen issues both in UX and back-end to improve reliability and reduce the incidence of most common user issues in these areas. Azure Function on National Clouds Azure functions is now available for National Clouds If you have any questions about any of this features or App Service in general be sure to check our forums in MSDN and Stack Overflow. For any feature requests or ideas check out our User Voice Previous updates: January 2018 App Service Update November 2017 App Service Update October 2017 App Service Update September 2017 App Service Update ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/04/10/March-2018-App-Service-update.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "App Service Environment is now available in US Government regions",
+ "excerpt":" Christina Compy (MSFT) 4/11/2018 1:37:03 PM The App Service Environment, with Isolated pricing plans, is now available in the US Government regions. The App Service Environment is a deployment of the Azure App Service and runs in your Azure Virtual Network. With an App Service Environment you have more options for: High scale Network isolation High memory utilization The App Service Environment can be deployed with an internet accessible endpoint or with an endpoint on a private address in your Azure Virtual Network. This makes the App Service Environment a great solution to host your line of business applications or those applications that you want to only expose through a web application firewall such as the Azure Application Gateway. To learn more about the App Service Environment start with the Introduction to the App Service Environment To create an internet accessible App Service Environment you can start with Creating an External App Service Environment To create an App Service Environment with a private address you should use Create and use an internal load balancer with an App Service Environment If you are interested in how to couple an App Service Environment with a web application firewall, we have a write up on Integrating your App Service Environment with an Application Gateway ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/04/11/App-Service-Environment-is-now-available-in-US-Government-regions.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Using EV SSL with Azure Web App",
+ "excerpt":" mksunitha 4/12/2018 12:33:21 PM You can use EV SSL with Azure web apps. There are many CA that provide EV SSL for your web applications and the two options you have to use EV SSL with azure web app : Option 1 : Bring your own certificate and upload to web app Contact your CA to get instructions on how to export your EV SSL into PFX format . Then follow the instructions to upload this certificate into your web app . Once the certificate is uploaded , add an SSL binding to your web app . Option 2 : Buy a certificate via Key Vault and import to Web App Azure Key Vault supports both DigiCert and GlobalSign CA providers to purchase ORG SSL and EV SSL. You can purchase a EV SSL from either of these providers . Follow instructons on how to purchase and configure a EV SSL from these providers into Key Vault Purchase and configure DigiCert with Azure Key Vault Purchase and configure GlobalSign with Azure Key Vault Place the certificate (PFX format ) in Key Vault and then follow the instructions here to import the Key Vault as an App Service Certificate . Troubleshooting Issues In the Azure portal , go to your App Service Certificate using this Key Vault resource for your EV SSL certificate . Follow the steps below to troubleshoot issues : Key Vault may have moved to another subscription or deleted or in a suspended state : In the portal , when you open your App Service certificate you will see the status \"Key Vault out of Sync \" . In this case , click on the status tile which will prompt you to reconfigure your Key Vault to App Service certificate to a valid Key Vault . Note the Key Vault must be in the same subscription as the App Service certificate Key Vault secret was updated but I still see the old secret in App Service certificate : Web App service runs a background job that periodically (once a day ) that syncs all App Service certificate. Hence when you rotate or update a certificate, sometimes the application is still retrieving the old certificate and not the newly updated certificate. This is because the job has not run to sync the certificate resource. To force a sync of the certificate , you can click on Rekey and Sync setting and then click on Sync button . Documentation Support : Checkout our FAQs for more details if you run into any issues managing your App Service Certificate ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/04/12/Using-EV-SSL-with-Azure-Web-App.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Announcing HTTP2 support in Azure App Service",
+ "excerpt":" Oded Dvoskin 4/13/2018 10:00:02 AM The Azure App Service team is happy to announce the global deployment of support for the HTTP/2 protocol for all apps hosted on App Service. HTTP/2 has been the top customer request we have received, and we are excited to light up support! What is HTTP/2? HTTP/2 is a rework of how HTTP semantics flow over TCP connections, and HTTP/2 support is present in Windows 10 and Windows Server 2016. HTTP/2 is a major upgrade after nearly two decades of HTTP/1.1 use and reduces the impact of latency and connection load on web servers. The major advance of HTTP/1.1 was the use of persistent connections to service multiple requests in a row. In HTTP/2, a persistent connection can be used to service multiple simultaneous requests. In the process, HTTP/2 introduces several additional features that improve the efficiency of HTTP over the network. One connection for multiple requests Every TCP connection requires a round trip to set up. If you're using encryption, the TLS handshake takes another 1-2 round trips. All this happens before the first byte of the first response can be sent. By reusing an existing connection instead of setting up a new one, this overhead can be shared by many requests. HTTP/2 sharply reduces the need for a request to wait while a new connection is established, or wait for an existing connection to become idle. Because a single connection is multiplexed between many requests, the request can usually be sent immediately without waiting for other requests to finish. Header compression with HPACK HTTP has supported compression of data for ages. Headers, however, are sent as uncompressed text, with a lot of redundancy between requests. (Many of the longest headers are sent with exactly the same value on every request!) HTTP/2 introduces HPACK, a compression scheme for HTTP headers which reduces the redundancy between requests. Compression also helps multiplexing, because requests are smaller. This enables clients to make many requests in their first packets on a connection, while TCP flow control windows are still small. What are the key differences from HTTP/1.x? HTTP/2 is binary Fully multiplexed, instead of ordered and blocking Ability to use one connection for parallelism Has one TCP/IP connection Uses header compression to reduce overhead What action do App Service users need to take? All you need is a just a simple configuration! HTTP/2 is disabled by default for all customers. However, if you would like to opt-in and apply HTTP/2 for your site, follow the steps below: Through the Azure Portal, browse to your app and search for the \"Application settings\", where you will find the setting called \"HTTP Version\". Select 1.1 or 2.0 by your needs. You may also browse to the Azure Resource Explorer using one of the following steps: In the Azure Portal, select “Resource explorer” in your App Service app’s menu. Then select ‘Go’ Alternatively, browse directly to Resource Explorer (https://resources.azure.com/). The advantage of going through the Azure Portal route is that the browser will be automatically navigated to your requested app’s configuration, then you just have to navigate to config > web, where you will find the needed value to update. If browsing directly to Resource Explorer, drill down through the tree hierarchy to your site using the following path: Subscription > Resource Group > your site name > Providers > Microsoft.Web > sites > your site name > config > web On the top of the page make sure you’re in Read/Write mode: Select Edit: Find the parameter for HTTP/2: Type in ‘true’ in place of ‘false’: On the top, select ‘PUT’: You’re done! Support for HTTP/2 in App Service Environments and the Azure National Clouds is available as well! HTTP/2 Browser Support Requires SSL Most modern browsers only support using the HTTP/2 protocol over SSL, while non-SSL traffic continues to use HTTP/1.1. App Service makes it easy to get up and running with SSL. Learn how to configure a new SSL cert for your app, or learn how to bind an existing SSL cert to your app. App Service also provides a default level of SSL functionality for all apps via a common wildcard SSL certificate bound to the *.azurewebsites.net domain. Regardless of which approach you choose, your apps will need to run over SSL to enjoy the benefits of HTTP/2 with modern browsers. What if I encounter an issue? If you find an issue you suspect is stemming from the update to HTTP/2 you can alert us through the following methods: Ask a question on the developer forums: MSDN or Stack Overflow Open a support ticket ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/04/13/Announcing-HTTP2-support-in-Azure-App-Service.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "App Service and Functions hosted apps can now update TLS versions!",
+ "excerpt":" Oded Dvoskin 4/17/2018 10:47:40 AM Following our communication earlier in the year, the App Service team is happy to announce that the ability to explicitly configure the TLS version for individual applications, is now available. What is TLS? Transport Layer Security (TLS) is a protocol that provides privacy and data integrity between two communicating applications. It's the most widely deployed security protocol used today, and is used for web browsers and other applications that require data to be securely exchanged over a network, such as file transfers, VPN connections, instant messaging and voice over IP. Multiple versions of TLS are available, with each being released at a different time and mitigating different vulnerabilities. TLS 1.2 is the most current version available for apps running on Azure App Service. Why should I update my TLS version? The PCI Security Standards Council has stated that June 30th, 2018, is the compliance deadline for disabling early TLS/SSL versions and implementing more secure protocols for your applications’ traffic. Customers requiring PCI compliance should move away from TLS 1.0, and onto TLS 1.1, though it is highly recommended to instead move directly to TLS 1.2. How can I test my connection and assess my risk? Most traffic going to apps hosted on Azure App Service is originating from modern Web Browsers updated to recent versions. SSL traffic originating from out-of-date browsers may not support newer TLS versions like TLS 1.2. In order to test your app’s compatibility with updated TLS versions, we suggest testing with one of the various 3rd party solutions to test traffic to your apps like SSLLabs. After updating the TLS setting for your app, you may use SSLLabs to test and see if lower versions of TLS are not accepted any more. What’s next for App Service hosted apps? At the time of releasing this blog, all applications running on public multi-tenant App Service hosted platform, including Azure Functions, apps hosted on the Azure National Clouds and App Service Environments (ASE), can update settings to select the TLS version that is required. From June 30th, 2018, all newly created App Service apps will automatically have TLS 1.2 selected as the default configuration. Though not recommended, we are allowing users to downgrade the TLS version if desired. How can I update the setting to select my required TLS version? In the Azure Portal, go to your App Service app’s menu, select SSL Setting and select the toggle to the version you require. Auto-save of the selection is enabled. Please allow a few minutes for the setting to be reflected in the monitoring tools. TLS configuration through CLI and PoweShell will be coming soon. What if I have questions about this change? Open a forum post on the App Service forum or on Stack Overflow. Open a support ticket. Refer to the document covering the feature and changes to the configurations. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/04/17/App-Service-and-Functions-hosted-apps-can-now-update-TLS-versions!.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "App Service Command Line Tools Resources",
+ "excerpt":" Ahmed Elnably 5/1/2018 11:14:38 AM I usually find myself looking for the bookmarks I have for different command line docs and issues pages. Here is the one place for all the resources for our command line tools, this includes our new \"az webapp up\" experience, Azure CLI experience, and Azure PowerShell experience. az webapp up: How to install: az extension add -n webapp Blog post: https://aka.ms/new-cli Reference Guide: https://docs.microsoft.com/en-us/cli/azure/ext/webapp Issues: https://aka.ms/webapp-extension-issues App Service Azure CLI: Reference Guides: https://docs.microsoft.com/en-us/cli/azure/appservice https://docs.microsoft.com/en-us/cli/azure/webapp Issues: https://github.com/Azure/azure-cli/issues Samples: https://docs.microsoft.com/en-us/azure/app-service/app-service-cli-samples Azure Power Shell: Reference Guide: https://docs.microsoft.com/en-us/powershell/module/azurerm.websites Issues: https://github.com/Azure/azure-powershell/issues Samples: https://docs.microsoft.com/en-us/azure/app-service/app-service-powershell-samples Functions Azure CLI: Reference Guide: https://docs.microsoft.com/en-us/cli/azure/functionapp Issues: https://github.com/Azure/azure-cli/issues Samples: https://docs.microsoft.com/en-us/azure/azure-functions/functions-cli-samples ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/05/01/App-Service-Command-Line-Tools-Resources.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Breaking change for SNI-SSL hostnames on Azure App Service",
+ "excerpt":" Oded Dvoskin 5/2/2018 1:36:23 PM SSL in Azure App Service Azure app service is a multitenant infrastructure. When web apps are created on azure app service, we provide a default hostname which is sitename.azurewebsites.net. Clients can make requests over HTTP or HTTPs to these hostnames. When using HTTPs against the default hostname for the site, a certificate with subject name *.azurewebsites.net is returned to the client for SSL. When customers configure an app service with a custom domain name, by default the system allows you to pick between an SNI-SSL binding type or IP-SSL binding type. SNI-SSL bindings are free of cost. For an SNI binding to be in use, clients making requests to this host will need to include an SNI header in the TLS initial handshake message. From a specification standpoint, TLS 1.0 supports SNI header extension, and all modern browsers includes the SNI header by default. In contrast, there can be older versions of browser clients or legacy library clients. For custom domains to work correctly for these clients, the site must be configured to have IPSSL bindings. What is SNI and IP-SSL really and why does it matter? When the initial SSL handshake request arrives at a web server, the mandatory parameters like the version of SSL being negotiated, the cipher suites the client supports are included in the clear text CLIENT HELLO message. From the server standpoint, with this information, the server needs to select the appropriate certificate to use for this request. For a web server with a single site/hostname, the matter is easy, you can configure the server with just one binding/certificate on a single port and all is fine. However, in a webserver which hosts multiple sites or hostnames, based on the version + cipher suites alone, the server cannot pick the correct certificate. Hence, this requires the bindings on the server to be configured based on a different IP for each of the hostname the server wishes to support. How does SNI help? To solve the problem of not requiring unique IP address on the server side to support multiple hostnames with SSL, the concept of an SNI extension was introduced in RFC 3546 [https://tools.ietf.org/html/rfc3546], back in 2003. Per this spec a client can include the destination host name in the clear text CLIENT HELLO message as an additional server name extension. Now, at the server, based on this information, the server can select the appropriate certificate to use for the handshake, thus solving the problem of not requiring unique IP addresses. Why does Azure App Service support both SNI-SSL and IP-SSL bindings? While the RFC for SNI was introduced in 2003, and all major browsers added support shortly after that, there are still legacy HTTPs clients which doesn’t include the SNI header extension in the client hello. If an azure app service customer anticipates such a client to use their site hosted in azure app service, it is recommended to add an IP-SSL binding, so that this site now has a dedicated IP Address. This allows us to pick the correct certificate for that hostname. What are the breaking changes with TLS 1.2 compliance initiative? We now enforce TLS 1.2 for clients which arrive without SNI header. Note that these are typically old browser clients which do not support SNI or programmatic clients which were written long ago and not updated to include the SNI header name. For sites which did not have a custom domain name configured: These hostnames are always SNI-SSL (or more like SNI-Required). For these sites, the hostnames used is the default sitename.azurewebsites.net. Customers can configure the minimum required TLS version on this site to be 1.0 and above, and we will honor it. However, if a request arrives without the SNI extension in the CLIENT HELLO message, we are unable to identify the exact site the request is eventually destined to, and hence we require this request to be at least of TLS 1.2 for compliance reasons. Sites with custom domain configured: SNI -SSL: For these sites just like default host name, the configuration for the minimum required TLS version can be set and will be honored by the system. However, if a request arrives without the SNI extension in the CLIENT HELLO, we require this client to at least negotiate TLS 1.2, just like the case of default hostname. IP-SSL: No breaking change, everything should continue to work as is. For IP-SSL bindings, since there is a dedicated IP for the hostname, our system can correctly determine the destination site based on the incoming IP address, and hence there is no requirement of SNI header or minimum TLS version requirement on requests without the SNI header. The minimum configured TLS version for the web app will take effect. I'm currently using SNI-SSL bindings: What do I do if I'm impacted? For browser clients, upgrade browser clients to modern browsers. For security best practices, it is highly recommended to use modern up to date browsers to protect the site and the user. For programmatic scenarios, update application code to either use TLS 1.2, or explicitly include the hostname in the client hello handshake if using TLS 1.0 To update the TLS version in a .NET app using HttpWebRequest or HttpClient, update the SecurityProtocol in the ServicePointManager as shown below. // To update the TLS version in a .NET C# app using HttpClient/HttpWebRequest, ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12; Note that when using HttpWebRequest/HttpClient class to make SSL requests, SNI header is automatically added. If both a) and b) are not an option, the last resort and the least preferred option, would be to use IP-SSL bindings. If you are using the default hostname, then you will need to add a custom domain name with IP-SSL. If you are already using a custom domain name, you'll need to change the binding to IP-SSL. /* Sample code */ using System; using System.Net; namespace SNIClient { class Program { static void Main(string[] args) { ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12; HttpWebRequest request = (HttpWebRequest)HttpWebRequest.Create(\"https://mysite.azurewebsites.net/\"); try { HttpWebResponse response = (HttpWebResponse)request.GetResponse(); response.Close(); } catch (WebException ex) { Console.WriteLine(ex.Message); } } } } What if I have questions? Open a forum post on the App Service forum or on Stack Overflow. Open a support ticket. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/05/02/Breaking-change-for-SNI-SSL-hostnames-on-Azure-App-Service.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Azure Functions Recipes",
+ "excerpt":" Anthony Chu - MSFT 5/3/2018 7:37:31 AM Recently, we released a collection of over 50 tips and tricks for Azure Functions that we're calling \"Functions Recipes\". Each recipe demonstrates a single, useful concept for working with Azure Functions. They include patterns and practices, integrations with other services, and tips that you may have overlooked when reading the documentation. With every recipe, you get a short code sample, key takeaways, and links to detailed documentation to learn more. Our goal is to create a comprehensive collection of recipes that you can quickly reference when you're working on your serverless projects with Azure Functions. If you want to see how triggers and bindings work, set up proxies, integrate with Cosmos DB, or even collect telemetry with Application insights, we want to be a resource that adds value to your workflow. We're only getting started. We'll be expanding the collection with even more recipes (we just added 11 new ones on Durable Functions). We launched with recipes in C#, but we are starting to add other languages such as JavaScript, Java, F#, Python, and more. We need your help! If you have a recipe idea or updates to suggest, create an issue or submit a pull request at the Microsoft Docs Sandbox repository on GitHub. Contributing is as easy as clicking the \"edit\" button on any of the pages. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/05/03/Azure-Functions-Recipes.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Announcing the Linux on App Service Environment Public Preview",
+ "excerpt":" Jennifer Lee (MSFT) 5/7/2018 8:26:10 AM Today, we are excited to announce the public preview of Linux on App Service Environment (ASE). Finally, our Linux customers will be able to take advantage of deploying Linux web apps into an App Service Environment, which is perfect for deploying applications into a VNet for secure network access or apps running at a high scale. What can you do with Linux on ASE? With Linux on ASE, you can deploy your Linux web applications into an Azure virtual network (VNet), by bringing your own custom container or just bring your code by using one of our built-in images. Additionally, both Windows and Linux/containerized web applications can be deployed into the same ASE, sharing the same VNet. You will be using the Isolated SKU with Dv2 VMs and additional scaling capabilities (up to 100 total App Service plan instances, between Windows and Linux, in one ASE), previously not offered in Linux. There are two different kinds of ASEs that you can create: an external ASE with an internet accessible endpoint or an internal ASE with a private IP address in the VNet with an internal load balancer (ILB). Steps to get started are provided here. Currently, Linux on ASE is available in these 6 regions: West US, East US, West Europe, North Europe, Australia East, Southeast Asia Public Preview Pricing During the public preview, you will receive a 50% discount on the Isolated SKU prices on the pricing card that applies to your App Service Plan (ASP). There is no discount on the ASE itself (it will still cost ~$1000/month USD for the ASE, regardless the size of the ASE). Things You Should Know Please create a new ASE to try out this feature. Because deploying Linux apps in an ASE is a preview feature, deploying a Linux app in an ASE that you previously made before this preview may have some performance impacts. You will be able to deploy both Windows and Linux web apps into the same ASE. Remember that even though Windows and Linux web apps can be in the same App Service Environment, Windows and Linux web apps have to be in separate App Service Plans. Because this feature is in public preview, please do NOT deploy a Linux app or container into an ASE you want fully supported. Adding a Linux app to an ASE means that the ASE will be in preview mode. Especially for those new to App Service Environment, how long will everything take to deploy? Because an ASE gives you a fully isolated and dedicated environment for securely running App Service apps at high scale, there are many different parts that we provision for you upon creating a web app in an ASE. Instead of sharing front ends, you will have dedicated front ends that are responsible for HTTP/HTTPS termination and automatic load balancing of app requests within the ASE. Therefore, when deploying a web app into an ASE or performing a scaling operation, the operation can take a couple of hours or more. This is not a promised SLA. We recommend that you scheduling your scaling operations to account for the time it takes for any extended scaling processes. How to Get Started You can create a Linux web app into a new ASE by simply creating a new web app and selecting Linux as the OS (built-in image) or Docker (custom container) or creating a new Web App for Containers (custom container). When creating a new App Service Plan, remember to select one of the 6 supported regions and select one of the Isolated SKUs. Because Linux on ASE is now in public preview, we would love to hear all of your feedback and questions about the product here. Start creating your first Linux/containerized web app into an ASE by following these instructions. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/05/07/Announcing-the-Linux-on-App-Service-Environment-Public-Preview.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "App Service AuthenticationAuthorization Coming to Linux Apps",
+ "excerpt":" Yi Liao MSFT 5/7/2018 8:25:00 AM Following our communication earlier in the year, the App Service team is happy to announce that the App Service Authentication/Authorization feature is now available to Linux apps. What’s App Service authentication/authorization feature? Azure App Service provides built-in authentication and authorization support, so you can sign in users and access data by writing minimal or no code in your web app. The same authentication and authorization feature support for Windows apps is now available to App Service on Linux including Web App for Containers. This overview article describes how App Service helps simplify authentication and authorization for your app. Is the feature behavior different on Linux? No. The authentication and authorization works the same way on Linux apps as Windows. The configuration experience on Azure portal and CLI is exactly the same, if you’re familiar with how to configure a Windows app for this feature, you’re ready to go and can do the same for a Linux app. I’m a Linux customer new to this feature, how do I configure it for my Linux app? This how-to article shows you how to customize authentication and authorization in App Service, and to manage identity from your application. To get started quickly, see one of the following tutorials: How to configure your app to use Azure Active Directory login How to configure your app to use Facebook login How to configure your app to use Google login How to configure your app to use Microsoft Account login How to configure your app to use Twitter login ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/05/07/App-Service-AuthenticationAuthorization-Coming-to-Linux-Apps.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "App Service Diagnostics Comes to Functions, ASE, and More!",
+ "excerpt":" Jennifer Lee (MSFT) 5/7/2018 8:27:58 AM Have you ever had issues with an unhealthy web app? Last year, we launched App Service Diagnostics, an intelligent and guided troubleshooting experience that points you and the right direction to diagnose and solve issues of your web app (without having to configuring anything special to enable this feature!). Since then, we’ve read all the feedback that you all have given, and have added new capabilities to make this feature even more robust and insightful, all without you have to configure anything special. New Tile Shortcuts for Management and Configuration When you visit App Service Diagnostics (by clicking on Diagnose and solve problems in the left-hand menu), you will be greeted by Genie, who will point you in the right direction to start troubleshooting your issue. If you have some experience or know a little bit about the nature of the issue, you should select one of the tile shortcuts that match your problem category. We have now added parent problem categories, such as Availability and Performance, to help keep the tile shortcuts organized. If you don’t know where to start, Genie will also allow you to run a health checkup, which will run several checks on our backend and intelligently highlight where you’re experiencing an issue. Our newest tile shortcuts are in the Management and Configuration problem category. You can now validate your swap operations, use our \"Check Best Practices for Prod Apps\" tile shortcut to make sure that you're configuring everything optimally for production workloads, and even check if your autoscaling operation is running correctly. App Service Diagnostics is now live for… Before, only web app users could get help from App Service Diagnostics. Today, we are excited to announce that you can now leverage App Service Diagnostics to diagnose and troubleshoot issues with not only your Windows web apps, but also your web apps on Linux, App Service Environment, and even Azure Functions. For each service, we have tailored the troubleshooting problem categories to cater to the most common scenarios that customers have been looking to diagnose and troubleshoot. For example, for Functions, you can now identify scaling issues and analyze functions in error. For App Service Environment, we know that our customers have quite a few questions about networking, so we added a network security group verifier and also a tile shortcut to validate outbound connectivity from your ASE. For Windows and Linux web apps, navigate to the App Service Portal. Click on Diagnose and solve problems on the left-hand menu. For App Service Environments, navigate to the App Service Environment Portal. Click on Diagnose and solve problems on the left hand menu. For Azure Functions, navigate to the Functions Portal. Click on the Platform Overview tab, and then click on Diagnose and solve problems under the Resource Management category. New Diagnostic Tools For our more advanced users who are familiar with troubleshooting web app issues, we released a new set of tile shortcuts under Diagnostic Tools (a new parent problem category). These Diagnostic Tools are stack specific and are here to help you dive deeper in investigating issues related to your application code, root causes for slowness, connection strings, and even issues with connecting to a remote server. As always, all of these tools have actionable documentation, which means not only do we tell you a little bit about what the tool does, but also allow you to perform that action right in App Service Diagnostics. Click on Change Stack to view the Diagnostic Tools relevant to your stack of interest. Integration with Application Insights Another insight that we’ve heard from our App Service Diagnostics users is about troubleshooting issues in their application code. To help with this beyond distinguishing between platform and application issues, we have integrated with Application Insights to provide code-level insights in context to availability downtimes. Application Insights is Azure’s application performance management and analytics tool that allows you to monitor your application. Although you do need to configure Application Insights to enable it for your application, once you do, you will be able to see common exceptions that your app is throwing and dependencies that are causing issues under Web App Down and Web App Slow. These are all correlated to the downtimes that you’ve selected via the orange bar. Hopefully, you’ll be able to recognize your application code issues from the commonly occurring exceptions, but if not, we deep link into Application Insights for more context. Next time you’re having issues with an unhealthy web app, App Service Environment, or Function, try out App Service Diagnostics to talk to Genie to get guidance on how to cure for your unhealthy web app. If you haven’t already, definitely leverage App Service Diagnostics to run a health checkup for piece-of-mind or drill-down to your specific issue that’s happening to your app. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/05/07/App-Service-Diagnostics-Comes-to-Functions,-ASE,-and-More!.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Introducing Restore from Snapshots (Preview)",
+ "excerpt":" Nick B. King 5/7/2018 10:54:00 AM Azure App Service Snapshots now in public preview Today we are announcing the public preview release of Azure App Service Snapshots. Snapshots are automatic periodic backups available for Premium SKU web apps. Snapshots are managed internally by Azure App Service and provide reliable, hassle-free backups of your web apps. Snapshots contain both the contents of a web app and the web app configuration. At least 1 snapshot will be available every 6 hours for the past 30 days. Within the past 7 days, usually 1 snapshot will be available per hour. Accessing snapshots in the Azure Portal Snapshots can be listed and restored in the Azure Portal from the Backups settings of the web app. How to list snapshots Azure CLI az webapp config snapshot list -g <resource group> -n <app name> Azure Powershell $snapshotRgName = <resource group> $snapshotAppName = <app name> $snapshotAppSlot = <slot name> Get-AzureRmWebAppSnapshot -ResourceGroupName $snapshotRgName -Name $snapshotAppName How to restore a snapshot Snapshots can be restored to the original web app, a slot of the web app, or any other web app in the same App Service Plan. While the restore operation is in progress, the web app will be stopped. It is strongly recommended to restore snapshots to a new slot instead of overwriting an existing slot in order to prevent data loss if the restore operation is unsuccessful. Snapshots contain both web app files and web app settings. You can choose to restore files only, or to restore the settings as well. All settings contained in regular backups are also contained in snapshots. However, some settings, like hostnames, certificates, and backup schedules, will not be restored with a snapshot. Azure CLI Snapshot commands for Azure CLI are currently available as extensions. To install the extension, run az extension add -n webapp If the extension is already installed, update it with az extension update -n webapp Restore a snapshot from the production slot to a new slot named SnapshotSlot az webapp deployment slot create -g <resource group> -n <name> -s SnapshotSlot az webapp config snapshot list -g <resource group> -n <app name> az webapp config snapshot restore -g <resource group> -n <name> -t <snapshot timestamp> -s SnapshotSlot --restore-config --source-resource-group <resource group> --source-name <name> Azure Powershell Snapshot cmdlets were added in Azure Powershell 6.0. Follow these instructions to update Azure Powershell if the snapshot cmdlets are not found. https://docs.microsoft.com/en-us/powershell/azure/install-azurerm-ps?view=azurermps-6.0.0 Restore a snapshot from the production slot to a new slot named SnapshotSlot $snapshotRgName = <resource group> $snapshotAppName = <app name> $snapshotAppSlot = <slot name> $snapshots = Get-AzureRmWebAppSnapshot -ResourceGroupName $snapshotRgName -Name $snapshotAppName -Slot $snapshotAppSlot # Create a new slot for the restore operation - highly recommended to prevent data loss! $targetSlotName = \"SnapshotSlot\" New-AzureRmWebAppSlot -ResourceGroupName $snapshotRgName -Name $snapshotAppName -Slot $targetSlotName # Restore the first snapshot in the list to the new slot. Restore both the configuration and files. $snapshots[0] | Restore-AzureRmWebAppSnapshot -ResourceGroupName $snapshotRgName -Name $snapshotAppName -Slot $targetSlotName -RecoverConfiguration -Force Learn More https://docs.microsoft.com/en-us/Azure/app-service/app-service-web-restore-snapshots ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/05/07/Introducing-Restore-from-Snapshots-(Preview).html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Multi-container Linux Web App",
+ "excerpt":" Yi Liao MSFT 5/7/2018 8:20:01 AM The App Service team is happy to announce the public preview of Multi-container support in Web App for Containers. Multi-container Web App Concept App Service Linux community has repeatedly asked for the capability to deploy multiple containers for a single App. Customers want to have additional containers to complement the primary container and have these containers form an “operable” unit. The benefits for Multi-container are: 1. customer can separate capabilities such as proxies, cache and storage into additional containers and manage the source code and container images independently following the “separation of concerns” design pattern in containerization; 2. customer can operate those containers as an atomic unit and leverage App Service’s rich feature set for application life-cycle management, scaling and diagnosis, without the needs to stand up a container Orchestrator and to manage the hosting infrastructure by themselves. Today we're happy to announce the public preview of Multi-container support in Web App for Containers! Primary Use Case In App Service Linux community, the primary multi-container use case is that customer deploy a stateless web app with multiple containers (Web, Proxy, Cache or Git-mirror) to a single App Service plan. For example: customer can have one container for web frontend and have another container for session cache using Redis, all deployed to the same App Service plan. All containers can communicate to each other through a Docker Bridge network using internal IP addresses. Supported Configurations In Public Preview, we support Docker-Compose and Kubernetes configuration format as they’re the “standard” ways to describe multi-container applications. We don’t want to invent another format. It’s also convenient for the customers because the formats are well documented and widely used by Docker community. Customer can create or configure a Multi-container app from Azure Portal or through Azure CLI. Customer can describe a multi-container app using Docker Compose and Kubernetes configuration format in a yaml file. Customer can upload the multi-container config file through portal UI or point to the URL if the config file is hosted elsewhere (note: URL link support will come soon after announcement), portal screenshot as below. For example, customer can use Docker-Compose format to describe a multi-container app: docker-compose.yml version: '3' services: web: image: \"appsvcsample/flaskapp\" # this image repo's source code come from \"Get started with Docker Compose\" on docker.com ports: - \"80:80\" redis: image: \"redis:alpine\" CLI command to create a multi-container app: $ az webapp create --resource-group [resource group] --plan [service plan] --name [app name] --multicontainer-config-type \"compose\" --multicontainer-config-file [path to \"docker-compose.yml\"] CLI command to configure a multi-container app: $ az webapp config container set --resource-group [resource group] --name [app name] --multicontainer-config-type \"compose\" --multicontainer-config-file [path to \"docker-compose.yml\"] Customer can also use Kubernetes configuration format to describe a multi-container app: my-kube.yml apiVersion: v1 kind: Pod metadata: name: python spec: containers: - name: web image: appsvcsample/flaskapp # this image repo's source code come from \"Get started with Docker Compose\" on docker.com ports: - containerPort: 80 - name: redis image: redis:alpine CLI command to create a multi-container app: $ az webapp create --resource-group [resource group] --plan [service plan] --name [app name] --multicontainer-config-type \"kube\" --multicontainer-config-file [path to \"my-kube.yml\"] CLI command to configure a multi-container app: $ az webapp config container set --resource-group [resource group] --name [app name] --multicontainer-config-type \"kube\" --multicontainer-config-file [path to \"my-kube.yml\"] Samples We're working to add more Multi-container web app samples. To get you started quickly, please feel free to copy the samples provided in this blog post, or download more from Github. Scaling Multi-container Web App Customer can scale up and / or out a stateless multi-container app just as any web apps hosted on App Service, using the same scaling features provided by App Service. If you would like to use a database in container for dev/testing purposes in a single-host app, please make sure to use the persisted shared storage to store your database files, so the database files can be persisted during app restarts. First, you should enable the App Service shared storage following the instructions at here. Then, you should mount the shared storage to a directory within the Docker container where you store the database files, a MySQL example in docker-compose.yml: services: mysql: image: mysql:5.7 volumes: - ${WEBAPP_STORAGE_HOME}/site:[/path/in/container/where/mysqlfiles/needs/to/be/mounted] If you would like to scale out a multi-container app to multiple hosts in an App Service plan and use the app for production purpose, we strongly recommend you use Azure Database services instead of putting the database in a container. For example, for a WordPress app you can move the database to an Azure Database for MySQL. To do that, please follow the following steps: Create a MySQL instance on Azure Database for MySQL servers. This can be easily done through Azure portal or CLI. Make sure to configure MySQL server for SSL following the instructions at https://docs.microsoft.com/en-us/azure/mysql/howto-configure-ssl, and also make sure to enable client access to MySQL server by configuring MySQL firewall rules: https://docs.microsoft.com/en-us/azure/mysql/concepts-firewall-rules. Modify your docker-compose.yml to use Azure MySQL instead of local MySQL server, for example, if you have a WordPress app connect to a MySQL database, you can pass the following environment variables in docker-compose.yml: WORDPRESS_DB_HOST: [mysql server name].mysql.database.azure.com WORDPRESS_DB_USER: [db user name]@[mysql server name] WORDPRESS_DB_PASSWORD: [database password] Test the configuration locally with docker-compose up before you push it to App Service. Limitations in Public Preview We wanted to put this feature out as soon as possible so customer can validate and provide more feedbacks during Preview. There are certain limitations in this Public Preview release. We support Docker-Compose and Kubernetes format to describe a multi-container app, but we don’t support all their configuration objects during Public Preview. Our goal is to support any configuration objects that are meaningful to App Service during this release. The supported objects and limitations are as follows: Docker-Compose Supported configuration in Public Preview: services A service definition contains configuration that is applied to each container started for that service, much like passing command-line parameters to docker container create. image Specify the image to start the container from. Can either be a repository/tag or a partial image ID. ports Expose ports by mapping ports in the HOST:CONTAINER pattern, recommend explicitly specifying your port mapping as string. App Service specific, we would only expose one service port to external, we would identify a single service port to expose to external based on the HOST port provided for each service, we're looking for port 80 or port 8080. environment Add environment variables. You can use an array as input. The dictionary format is not supported in current release, we will add support for dictionary format in next release. environment: #supported RACK_ENV: development SHOW: 'true' SESSION_SECRET: environment: #not supported - RACK_ENV=development - SHOW=true - SESSION_SECRET volumes Mount host paths or named volumes, specified as sub-options to a service. We support both persisted volume and non-persisted volume. To use the persisted volume, please enable the shared storage by set WEBSITES_ENABLE_APP_SERVICE_STORAGE=TRUE. You can reference the shared storage using ${WEBAPP_STORAGE_HOME}. For example, you can mount the shared storage to /tmp in the container: volumes: - ${WEBAPP_STORAGE_HOME}/site/wwwroot:/tmp command Override the default command. Currently we support the collection format, for example: command: [\"bundle\", \"exec\", \"thin\", \"-p\", \"3000\"]. We will add support for a single string after public preview. entrypoint Override the default entrypoint. restart “no” is the default restart policy, and it does not restart a container under any circumstance. When “always” is specified, the container always restarts. More info at https://docs.docker.com/compose/compose-file/#restart. Configuration not supported in Public Preview: (besides the list below, any other Docker-Compose syntax not explicitly called out in the “Supported Configuration” section will not be supported in Public Preview) build Configuration options that are applied at build time. We don’t support “build” image locally as we need an explicit image to start the container with. depends_on Express dependency between services. we don’t currently support “depends_on” to specify the dependencies among containers, but we plan to support this shortly after Public Preview. networks Networks to join. We don’t support additional “networks” as we run all containers on one Bridge network. secrets Grant access to secrets on a per-service basis using the per-service secrets configuration. We don’t currently support it, but we plan to support this shortly after Public Preview. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/05/07/Multi-container-Linux-Web-App.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "New SSH Experience and Remote Debugging for Linux Web Apps",
+ "excerpt":" Yi Liao MSFT 5/7/2018 8:27:27 AM The App Service team is happy to announce the Public Preview of a new SSH experience and the remote debugging capability for Linux app developers. In this release, we're also enabling SFTP (Secure File Transfer Protocol) for Linux web app content management. What’s new? We’re introducing a new TCP tunneling technology for Azure App Service, which enables SSH/SFTP access and remote debugging for Linux Web Apps. We’re enabling Linux app developers to SSH into an app container using any SSH client at your choice. Previously we only enabled the SSH access through a Kudu web client. Based on Linux customer’s feedbacks, we’re adding support for any SSH clients to connect to app container. We’re also enabling SFTP for managing web app content and downloading logs, in addition to the already supported FTP and FTPS protocols. With the new remote debugging capability for Linux Web Apps, developers can now set break points in a code editor and live debug an web app running in App Service on Linux or Web App for Containers. We will publish additional blogs for know-how on remote debugging in the next several weeks. How do I configure my dev machine for SSH/SFTP and remote debugging? We use TCP tunneling technology to create a network connection between your dev machine and App Service over an authenticated WebSocket connection. We included the TCP tunneling technology in Azure CLI. First, make sure you have the latest Azure CLI installed. To enable the tunneling from your dev machine, you need to install Azure CLI \"webapp\" extension. If you install the extension for the first time, use this command: az extension add --name webapp. If you have an existing webapp extension, use this command to upgrade: az extension update --name webapp. Once the extension is installed, run the following CLI command to create a TCP tunnel to App Service: az webapp remote-connection create –g [resource group] -n [app name] -p [local port to open] The command line output on a Linux terminal will be something like this: Port [number] is open Tunnel is ready! Creating on port [number] Starting local server... Now, your dev machine is configured for any general purposed remote debugging and SSH/SFTP access for the web app as you specified in the remote-connection create command. Please note: in the Public Preview, for a given app we only support a single TCP tunnel at any given time. We plan to remove this limitation in future releases after Public Preview. How do I SSH into app container from a Linux terminal? First, please make sure your web app is enabled for SSH. If you use App Service on Linux (blessed images), the SSH is enabled by default. If you use Web App for Containers (custom images), please follow the instructions here to enable SSH access in app container. Tips for SSH to work correctly in your container: Make sure you remember the pre-defined SSH password that is set in your Dockerfile. We recommend that you install SSH server and set the user/password in Dockerfile as follows: # ------------------------ # SSH Server support # ------------------------ RUN apt-get update \\ && apt-get install -y --no-install-recommends openssh-server \\ && echo \"root:Docker!\" | chpasswd Please remember to start the SSH service in your container startup script. Second, make sure you create a TCP tunnel to the remote web app, if not, please run the CLI command provided in “configure my dev machine” section. Once the TCP tunnel is established, you can simply run the following command in Linux terminal: $ ssh root@127.0.0.1 -p [local port created for TCP tunnel] Similarly, you can SSH to app container from a Mac or Windows machine. Now, you can go party with SSH! How do I use SFTP to manage web app content? Like SSH, please make sure your app container is enabled for SSH access, refer to the SSH section above for instructions. And run the same remote-connection create command to establish a TCP tunnel. If you don’t have one, install a SFTP client such as WinSCP, connect the client to localhost at 127.0.0.1 and a port number that is created for TCP tunnel, use the SSH user name and password to login. Now you can manage the site content stored in /home/site/wwwroot using the SFTP client. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/05/07/New-SSH-Experience-and-Remote-Debugging-for-Linux-Web-Apps.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Revised Scaling Experience for Standard and Premium",
+ "excerpt":" Byron Tardif 5/7/2018 2:11:01 PM The App Service team is delighted to announce a revised scaling experience between Basic, Standard, and Premium App Service plans that will make it easier for customers to scale up to more performant VMs at the same price point. Central to this announcement is a 20% price reduction for Pv2 App Service plans. This change makes the P1v2 App Service plan the same price as the current S2 App Service plan, making it possible for customers to scale directly from S2 to P1v2. Giving them a more performant Dv2 based instance with 2X memory and an SSD drive at the same price as the S2 offering. With the 20% Premium V2 price reduction we also have a new scaling experience which highlights the ability to move directly from S2 to P1v2. Pricing tiers are now grouped by their target workload into Dev/Test, Production, and Isolated with recommended scale guidance provided. Dev/Test includes the Free, Shared and Basic App Service plan options Production includes Standard, Premium and Premium v2 Isolated includes the scale options for App Service plans hosted in an App Service environment. If you have any questions about any of this features or App Service in general be sure to check our forums in MSDN and Stack Overflow. For any feature requests or ideas check out our User Voice ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/05/07/Revised-Scaling-Experience-for-Standard-and-Premium.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Web Apps making changes to FTP deployments",
+ "excerpt":" Thad Kittelson 5/8/2018 10:19:42 AM We are continuously taking steps to improve Azure Platform security. As part of this ongoing effort an upgrade of App Service is planned for all regions during the first part of May. Changes to deployment options When this upgrade is complete Web Apps will provide the following configurations with the option to change your default setting. Today your apps can be accessed through the legacy FTP protocol (using credentials over plain text) as well as the more secure FTPS protocol (not to be confused with SFTP). Once the upgrade is complete you will be able to configure your apps to continue to use FTP and FTPS, limit access only over FTPS or completely disable FTP access. You can find these options in the Azure Portal under your app's menu: Application Settings > FTP Access Whats next In early July all new apps will default to FTPS only access. Users will continue to have the option to configure this as needed. Any previously created apps will retain their existing FTP/FTPS configuration with the option to change as needed. Best practice As a best practice we recommend using FTPS for deployments. Doing so will ensure that your data transmissions are encrypted which helps address regulatory guidelines for security. If you have any questions about this feature or App Service in general be sure to check our forums in MSDN and Stack Overflow. For any feature requests or ideas check out our User Voice ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/05/08/Web-Apps-making-changes-to-FTP-deployments.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "PHP Minor Version Update for June 2018",
+ "excerpt":" Jennifer Lee (MSFT) 5/11/2018 1:30:57 PM Latest version updates to PHP In June 2018, Azure App Service will update the PHP stacks to the latest available versions. For information on the changes in the new versions, please see the change logs on the PHP website. PHP Version Change Log 5.6.36 http://www.php.net/ChangeLog-5.php#5.6.36 7.0.30 http://www.php.net/ChangeLog-7.php#7.0.30 7.1.17 http://www.php.net/ChangeLog-7.php#7.1.17 7.2.5 http://www.php.net/ChangeLog-7.php#7.2.5 ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/05/11/PHP-Minor-Version-Update-for-June-2018.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "April 2018 App Service update",
+ "excerpt":" Byron Tardif 5/13/2018 10:16:06 AM Kubernetes and Docker Compose come to App Service Now you can bring your Kubernetes Pod Definitions or Docker Compose files to App Service and run multi container solutions in a fully managed PaaS solution with all the App Service features and ease of use you are already familiar with. Learn more about these scenarios in our announcement blog. Linux and Docker on App Service Environments You can now create Linux and Docker apps in your App Service Environment to take advantage of the advanced scaling and networking features. Learn more in the announcement blog. New App Service plan options for Linux and Docker on App Service Now you can get started with Linux and Docker on App Service with a free B1 App Service plan for 30 days. As well as access to the more powerful and cost effective PV2 Instances for production workloads. App Service Authentication/Authorization for Linux Apps You can now enable Authentication/Authorization on your Linux App Service Apps just as easy as you do for Windows hosted apps. Learn more in our announcement blog. Docker Logs in portal You can now access your Docker logs directly form the portal under Container Settings. Azure Functions on Linux and Docker Earlier in the year we started the preview of Azure Functions on Linux, we are now extending this by including Docker as another hosting option. New Functions Monitoring powered by Application Insights Application Insights is the preferred monitoring solution for Azure Functions and we have made enabling it super easy. TLS configuration You can now define the minimum TLS version for your apps. You can find this setting under SSL Settings. This feature applies to Windows, Linux and Docker Web apps, Mobile apps and API apps as well as Azure Functions. Learn more in our announcement blog. Fine grain FTP configuration You can now configure FTP to enforce connections over FTPS or disable this publishing endpoint completely. This feature applies to Windows, Linux and Docker Web apps, Mobile apps and API apps as well as Azure Functions. Learn more in our announcement blog. Snapshots: a new way to back up your App Snapshots is a new premium feature for backing up the content of your app. You can find it under Backup in the left menu. Learn more in our announcement blog. New pricing options and scale up experience We have revised the pricing for App Service instances and re-vamped the experience to provide more information and make it easier to choose the right size for your app. Read more in our announcement blog. App Settings now sorted alphabetically This feature was one of the top 10 most requested features in our UserVoice forum and we are happy to deliver. If you have any questions about any of this features or App Service in general be sure to check our forums in MSDN and Stack Overflow. For any feature requests or ideas check out our User Voice Previous updates: March 2018 App Service update January 2018 App Service Update November 2017 App Service Update October 2017 App Service Update ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/05/13/April-2018-App-Service-update.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Azure App Service on Azure Stack Update Two Released",
+ "excerpt":" Andrew Westgarth 5/18/2018 10:00:43 AM This morning we released the second update to Azure App Service on Azure Stack. This release updates the resource provider and brings the following key capabilities: Auto Swap of deployment slots feature is now enabled - Configuring Auto Swap Testing in Production feature enabled - Introduction to Testing in Production Azure Functions Proxies enabled - Work with Azure Functions Proxies App Service Admin extensions UX support added to enable: Secret rotation Certificate rotation System credential rotation Connection string rotation Updates to App Service Tenant, Admin, Functions portal and Kudu tools. Updates to .Net Core support, additional versions of NodeJS and NPM All other fixes and updates detailed in the App Service on Azure Stack Update Two Release Notes You can download the new installer and helper scripts: Installer – https://aka.ms/appsvcupdate2installer Helper Scripts – https://aka.ms/appsvconmashelpers Please read the updated documentation prior to getting started with deployment: Before you get started with App Service on Azure Stack Deploy the App Service Resource Provider for new deployments Update the App Service Resource Provider for updating existing deployments ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/05/18/Azure-App-Service-on-Azure-Stack-Update-Two-Released.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "App Service Deployment Center (Preview)",
+ "excerpt":" Byron Tardif 6/4/2018 5:12:14 PM We are happy to announce a new preview experience for setting up deployments to Azure App Service. Deployment Center is a centralized overview for all of the deployment options available to you. It also provides a guided experience to set up your deployments. With the new UX you can now search and filter through your repositories and branches making navigation through large code repositories easier. We have also revamped the access to log files making them easier to find and consume. Other improvements include: Link back to source repository (as requested in our Uservoice) Displaying the branch information (as requested in our Uservoice) Information about the Commit ID and Author Surfacing the Check-in message All of these improvements are geared to help developers understand what version of their code is currently deployed in their app. Deployment credential management is now contextualized to your deployment provider/method of choice. It is now easier to set and re-set credentials from the deployment center without having to visit another UI or abandon the flow. Preview Limitations This preview is currently available for Windows hosted apps and we plan to extend this to Linux and Functions in the coming months. You must be part of the Owner role in the subscription to use this feature, we plan to remove this limitation in future releases. If you find any issues with the preview you can report a bug here For any questions about any of this features or App Service be sure to check our forums in MSDN and Stack Overflow. For any feature requests or ideas check out our User Voice ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/06/04/App-Service-Deployment-Center-(Preview).html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "App Service Diagnostics – Profiling an ASP.NET Web App on Azure App Service",
+ "excerpt":" PuneetG 6/6/2018 12:47:44 AM The Diagnostic Tools options under the Diagnose and Solve blade for Azure App Services has been live for a few months now and has many tools that help you troubleshoot apps based on their application stack. In this post, we are going to cover the Collect .NET Profiler Trace option in detail and how you can use it to troubleshoot a slow or a failing ASP.NET based Web App. Profiler tool helps in collecting an on-demand trace that lets you identify the underlying .NET exceptions, time taken in the various request processing pipeline stages and even lets you drill down into exact methods within the application code that are taking time. It is extremely useful in situations where the problem is happening right now and you want to collect some data to identify the root cause of the issue. Profiling is designed for production scenarios and is based on ETW (Event tracing for Windows) . The analysis component of the profiler uses the TraceEvent library to generate a report that helps you drill down in to the problems in matter of a few minutes. It should be noted that no changes are made to your Web App code or your configuration during the collection or the analysis phase. In fact, the web app is not even restarted as a result of capturing this trace. The captured trace has ETW events emitted by the IIS and the ASP.NET providers along with stack traces captured at the CPU level. You can use this tool to efficiently troubleshoot delays which are relatively small (less than a second too) without impacting the run-time performance of the application. The profiler works for both ASP.NET and ASP.NET core applications. How to Collect the Trace To collect the trace, go to Diagnose and Solve Problems and choose the Collect .NET Profiler Trace option under Diagnostic Tools option and click on Collect Profiler Trace. Unless you have isolated that only a specific instance is failing, it is best to just select all the instances on which your Web App is running. Add thread report option - With this option enabled, a thread report of all the threads in the process is also collected at the end of the profiler trace. This is useful especially if you are troubleshooting totally hung processes, deadlocks or requests taking more than 60 seconds. This will pause your process for a few seconds until the thread dump is generated. This option is NOT recommended if you are experiencing high CPU on the instance because if the instance is under stress, it might take a long time to even start a new process to collect the thread dumps. Clicking the Collect Profiler Trace will start profiling the Web App and the wizard will show progress of various steps involved. Once the profiler trace is started, reproduce the issue by browsing the Web App. If you have a Web App running on multiple instances, make sure to browse a few more times to ensure that the requests to the web app get captured in the profiler trace. The default duration for which the profiler trace runs is 60 seconds and during this 60 seconds, all the requests that were made to the Web App get captured in the profiler trace. It is important to note that the profiler trace only has information about the requests that were captured in these 60 seconds (It is possible to increase this duration as mentioned below in this article) After 60 seconds, the profiler automatically stops, and an analysis component gets triggered that starts analyzing the profiler trace that just got captured. After the analysis finishes, a link to view the profiler report for every instance serving the web app is generated and you click on the Open Report button to view the Analysis report. Understanding the Analysis Report The analysis report provides some basic information about the number of requests captured, successful and failed requests, CPU usage of the instance, CPU usage of the web app and request execution information that helps you identify how fast your Web App was responding when the trace was getting captured. This can be used to validate if the trace is useful and if the right set of requests got captured in the trace and if the cause of slowness is related to high CPU on the instance serving the web app or not. The trace file section also has a link to download the trace file. For troubleshooting slow or slow or hung web applications, click on Slow Requests tab. This view shows you the top 100 slowest requests that got captured in the trace. It also breaks down the time spent in various modules of request execution in IIS and tries to categorize them in to Platform, Network and Application code to give you a quick indication on where the problem might be. Application Code - represents the time spent in handlers or modules that get invoked either while executing application code (for e.g ManagedPipelineHandler) or those that are closely related to any explicit configuration done for the application (for e.g. RewriteModule). Any external or third party handlers, modules fall in this category. Anything which does not fall in the native IIS handlers or modules is classified as Application. Network - represents the time spent in reading the request entity body from the client or time spent in flushing the response buffer back to the client. Time spent in waiting on external outbound network calls made from the application (like Database, cache, external HTTP requests etc.) is not counted here and is grouped under Application Code. If requests are spending a lot of time in this category, then it means that there is either a network issue between the client and the web app, the network might be slow or the request and response body is big. Platform - represents the time a request spends in core native modules or handlers of IIS which are pre-installed in Azure App Service (for e.g. DefautlDocumentModule, StaticFileHandler etc.). A request spending too much time in these modules might indicate an overall platform issue so you can contact Microsoft Support to get more details. The chart also plots the Top 5 handlers or modules in the IIS processing pipeline where the requests spent most of their time and this can give a quick indication as to where the problem might be. In the above example, we see that 83% of the time was spent in PageLoad and 15% of the time was spent waiting in the CLR thread pool queue waiting for the request to be picked up and assigned to a thread pool thread. In the same section, if you scroll below, you find a list of Top 100 Slow requests with the time taken in request execution and the slowest module for these requests. Note that stack traces will be captured if the request execution delay is on the same thread or if the application code uses Tasks class (from System.Net.Threading) to perform asynchronous IO in the request. There are lot of ways in .NET Framework to achieve asynchronous execution behavior and not all of them can be tracked so it is possible that for those scenarios, there are no stack traces captured for the request. Even for those scenarios, at least the Module name should help in identifying where the delay might be happening and is good indication of where the problem lies. So the above information tells us that the slowest request in this trace took around 30 seconds and 99.79% of the time was spent in the the Page_Load event of ASP.NET which tells us that something in the Page_Load caused the request to slow down hence narrowing the issue down to Application Code. The Profiler tries its best to correlate the stack trace of thread to the slow requests and if it manages to find this information, a light bulb icon is displayed next to the Details view to illustrate that there are stack traces captured for this request. You can click on the Details button to get the stack trace captured. Stack Traces - Thread View For a request, the Thread View is shown for requests where the profiler is able to determine that the request execution happened on the same thread and where the delay in request processing happened on the same very thread. It is however possible that the thread view is shown even for ASYNC requests if the .NET Task Scheduler decides to run them on the same thread. It is best advised to look at both the Thread View and Activity view for requests that executed on the same thread to get an idea of methods taking the longest time because at times one view may have more accurate information than the other and might help you go one more step closer to the code that is introducing the delay. The stack trace helps us identify the delay is happening while trying to open a SqlConnection from a page named SlowSql.aspx and the function name is demomvp.SlowSql.Page_Load. There is also a toggle button for showing the full .NET Framework stack which shows time spent in all the functions that got executed on this thread and at times is helpful if you want to drill down further within the .NET Framework code to identify methods where time is being spent. Profiler is able to show the stack traces accurately for requests that have completed in the trace. For requests that started in the trace and have not finished before the trace is stopped, the profiler tries its best to show the time taken but it may not be 100% accurate. Incomplete requests would have a warning icon next to the slow request report and it is suggested to look all the complete requests in the trace to get a better picture of request execution. Stack Traces - Activity View If the request has switched multiple threads, you will notice an icon next to the list of requests in the slow request report indicating the request is an async request. For asynchronous requests, the profiler report shows you the Activity View and the thread view is not shown. Activity view groups method execution by the activity information which is passed by CLR when using Tasks and the profiler groups similar tasks originating with the same Activity Id and stitches them together to show you this view. Here is an example of an asynchronous request's activity view. In the above stack trace, we can see that the method demomvp.AsyncThreadDelaySleep.WaitForSomeTime invoked a new Delay Task and spent 8 seconds awaiting on it. As you can see, by the nature of asynchronous execution, understanding ASYNC tasks is slightly more trickier than synchronous threads but still the profiler report has grouped the right functions together by grouping .NET Activity. To know more about .NET Activities and how they are flown, check out this detailed post - https://blogs.msdn.microsoft.com/vancem/2015/09/14/exploring-eventsource-activity-correlation-and-causation-features/ Failed Requests For requests, that failed with a HTTP error, the Failed Requests view highlights the HTTP Module or the handler that was responsible for setting the error status code. Clicking on Details will show more information about the failure and will highlight the underlying exception for the request. The profiler tries its best to correlate a request with an exception, however if a request has switched multiple threads (either due to multiple tasks or due to different threading primitives), then the profiler may not be able to correlate the exception with the request. .NET Exceptions View This view shows all .NET exceptions that happened in the process during the trace. The difference in this view vs. the Failed Requests view is that this can include all the exceptions that might have happened on background threads , IO threads or on threads that could not be associated to a request directly. CPU Stacks If the process traced also consumed high CPU, then the profiler report would also show you the call-stack of the thread that consumed the maximum CPU and this should help in identifying the function that need to be optimized. In the above example, we can see that there is a ProfilerClassTest.CalculateDiscounts method is taking 4 seconds on the CPU Increasing the duration for the Profiler Trace It is possible to increase the default profiling duration by setting an application setting IIS_PROFILING_TIMEOUT_IN_SECONDS with a maximum value of 900 (i.e. 15 minutes). If you configure this application setting to a number more than 900, it defaults to the 60 second value. How to Analyze the trace further ? If the profiler report is not able to identify the issue easily, you can use the PerfView tool or Visual Studio to analyze the trace . The trace file generated by the profiler is a *.diagsession file that is supported by these tools. The link to download the trace file is also present in the analysis report in the top section. We hope this tool helps you identify issues in production easily and lets you optimize your code to better serve your Web Apps. Happy Debugging !!! ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/06/06/App-Service-Diagnostics-Profiling-an-ASP.NET-Web-App-on-Azure-App-Service.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "TLS Configuration now fixed to block 1.0",
+ "excerpt":" Oded Dvoskin 6/13/2018 8:57:33 AM We recently announced that all App Service and Functions apps could update TLS configuration. However, after deployment, an edge case scenario was identified involving SNI-SSL which led to SSL analyzing tools such as SSL Labs, showing that TLS 1.0 was still accepted, while higher versions were selected. We have now completed the deployment which solves the issue for SSI-SSL and will also translate to the reporting tool indicating correctly that lower versions of TLS, mainly TLS 1.0, are indeed blocked. To update your TLS configuration, follow one of the methods below: In the Azure Portal, in the app's menu, browse to SSL Settings option and select which version of SSL you require. Through CLI, details for the commands are in our documentation. az webapp config set --name [--min-tls-version] For any questions, please reach out over the App Service MSDN forum. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/06/13/TLS-Configuration-now-fixed-to-block-1.0.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Announcing General Availability and Sovereign Cloud Support of Managed Service Identity for App Service and Azure Functions",
+ "excerpt":" Matthew Henderson - MSFT 6/26/2018 8:00:10 AM Securing access between resources is an important part of modern cloud architectures, and we want to make that as simple as possible in Azure. Managed Service Identity (MSI) lets you securely connect to AAD-protected resources without needing to manage or rotate any secrets. If you need to work with a service that doesn't support AAD, MSI makes it easy to work with Azure Key Vault for secure secret management. This gives you secure access to resources without your application needing any bootstrapping secrets. Today, we are pleased to announce that App Service and Azure Functions support of MSI is now generally available! We are also lighting up support in Azure China, Azure Germany, and Azure Government. Users in those sovereign clouds can get started with the APIs today, and updates to the portal, CLI, and PowerShell for those environments will become available over the next few weeks. You can get started using MSI today using any app in App Service and Azure Functions by checking out our documentation. Be sure to also check out the new preview support in Visual Studio for using Key Vault with Connected Services. While Key Vault is the most common use case, MSI has also proven a powerful tool for automation tasks, allowing you to easily start working with Azure Resource Manager APIs. You can also connect directly to a variety of services including Azure SQL and Azure Service Bus. Please note that App Service on Linux and Web App for Containers do not yet support MSI. We are working on this and look forward to giving Linux users the same great turnkey identity story soon. UX behavior change If you used the feature during preview, you may have noticed that turning MSI off in the portal, CLI, or PowerShell actually just set an app setting: WEBSITE_DISABLE_MSI. This app setting disables the local token service but does not remove the identity itself. Going forward, the \"off\" indication will change the identity type to \"None\" which will also remove the identity from AAD. The WEBSITE_DISABLE_MSI app setting will no longer be affected by the enablement/disablement behaviors. We encourage users to move away from this setting if possible, as your site will now show MSI as \"on\" even if this setting is present. CLI and PowerShell commands will be updated in the coming weeks to remove the preview tag and reflect this behavior change. Try it out! We're very excited to make our MSI support generally available. It's an extremely powerful tool that dramatically simplifies connecting your application to other resources. Give it a try, and please be sure to share your feedback. As always, you can reach us in the Forums (App Service, Functions) or on UserVoice (App Service, Functions). ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/06/26/Announcing-General-Availability-and-Sovereign-Cloud-Support-of-Managed-Service-Identity-for-App-Service-and-Azure-Functions.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Function Proxies now Available in Functions Version 2.x!",
+ "excerpt":" Alex Karcher 6/26/2018 9:00:13 AM I'm very excited to announce the availability of Function Proxies in Functions Version 2.x! Function Proxies enable multiple HTTP Functions to be composited together, mock APIs and single page apps to be hosted in Functions, and HTTP requests to be modified in transit. All that functionality is now available alongside Java Functions, .NET Core Functions, and any other 2.x workloads! To learn about all the differences and improvements with 2.x going forward, check out our docs Run Proxies on MacOS and Linux! 2.x support enables cross platform local execution of Proxies across Mac, Linux, and Windows! To learn more about Proxies check out the getting started docs! To run Proxies locally you'll need the 2.x runtime, with instructions here Make feature requests and file issues on our github page. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/06/26/Function-Proxies-now-Available-in-Functions-Version-2.x!.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "How to use Azure Container Registry for a Multi-container Web App",
+ "excerpt":" Yi Liao MSFT 6/27/2018 12:10:43 PM Back in May at Microsoft Build, we announced the public preview of Multi-Container Web App, which supports the ability for you to deploy multiple Docker images to Web App for Containers. All you have to do is bring your Docker Compose or Kubernetes Config file when creating a new web app. (Here are instructions to get started with Multi-Container Web App). Since we launched public preview, one of the most frequently asked questions that we've received is: \"How do I configure Azure Container Registry with Multi-Container?\" Let me walk you through a quick tutorial that uses Azure Container Registry with Multi-Container. Configure Your Docker Compose/Kubernetes File To create a Multi-Container web app, you first need a Docker Compose or Kubernetes Config yml file. This is basically a definition file that describes a Multi-Container web app. Because we will be using Azure Container Registry (ACR), notice that the Docker Compose file has the ACR image repos in the file. The image with \"ports: - 80:80\" is the main container that exposed to Internet. Here is a sample Docker Compose file: version: '3' services: web: image: [azure-container-registry-name].azurecr.io/flaskapp ports: – 80:80 redis: image: [azure-container-registry-name].azurecr.io/redis:alpine If this Docker Compose file looks familiar, it is actually the same as the Docker Compose file in the Quickstart that you can use when creating a Multi-Container app (with DockerHub), with the exception of the ACR modifications. Adding the App Settings After you uploaded your Docker Compose file and clicked create, you will have to make sure App Service can access Azure Container Registry by adding the following App settings in the App Service portal: DOCKER_REGISTRY_SERVER_USERNAME = [azure-container-registry-name] DOCKER_REGISTRY_SERVER_URL = [azure-container-registry-name].azurecr.io DOCKER_REGISTRY_SERVER_PASSWORD = [password] Note: please make sure to enable admin access in the Azure Container Registry Server settings. Limitations All Docker images in the same Docker Compose or Kubernetes Config yml file need to come from the same Azure Container Registry server. This means that you may have to pull down popular images (such as nginx and Redis) from DockerHub, and tag it for ACR then push to your ACR registry server. Further limitations on Docker Compose/Kube Config configuration options are documented here. Checking Your Logs After the web app is restarted, you should see logs similar to the ones below in Container settings or in Kudu. (Kudu is where you can view all your Docker logs and is your source control management site. Kudu can be accessed via [your web app name].SCM.azurewebsites.net or under \"Advanced Tools\" in the left-hand menu). 2018-06-19 19:26:33.419 ERROR – multi-container unit was not started successfully 2018-06-19 19:26:33.422 INFO – Container logs from yili-multicontainer-acr-01_web_0 = 2018-06-19 19:29:42.691 INFO – Starting multi-container app, configuration = version: '3' services: # this image repo’s source come from “Get started with Docker Compose” on docker.com web: image: [azure-container-registry-name].azurecr.io/flaskapp ports: – 80:80 redis: image: [azure-container-registry-name].azurecr.io/redis:alpine 2018-06-19 19:30:14.621 INFO – Starting container for site 2018-06-19 19:30:14.622 INFO – docker run -d -p 55955:80 –name yili-multicontainer-acr-01_web_0 -e WEBSITE_SITE_NAME=yili-multicontainer-acr-01 -e WEBSITE_AUTH_ENABLED=False -e WEBSITE_ROLE_INSTANCE_ID=0 -e WEBSITE_INSTANCE_ID=6cc2f742b7330fbd63a5e79967ed9ee7904bb9d93c7ca7843312788a4c2bc622 yiliacr05.azurecr.io/flaskapp 2018-06-19 19:30:14.622 INFO – Logging is not enabled for this container. Please use https://aka.ms/linux-diagnostics to enable logging to see container logs here. 2018-06-19 19:30:22.542 INFO – Starting container for site 2018-06-19 19:30:22.543 INFO – docker run -d -p 0:6379 –name yili-multicontainer-acr-01_redis_0 -e WEBSITE_SITE_NAME=yili-multicontainer-acr-01 -e WEBSITE_AUTH_ENABLED=False -e WEBSITE_ROLE_INSTANCE_ID=0 -e WEBSITE_INSTANCE_ID=6cc2f742b7330fbd63a5e79967ed9ee7904bb9d93c7ca7843312788a4c2bc622 yiliacr05.azurecr.io/redis:alpine 2018-06-19 19:30:22.544 INFO – Logging is not enabled for this container. Please use https://aka.ms/linux-diagnostics to enable logging to see container logs here. 2018-06-19 19:30:30.750 INFO – Started multi-container app 2018-06-19 19:30:30.778 INFO – Container yili-multicontainer-acr-01_web_0 for site yili-multicontainer-acr-01 initialized successfully. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/06/27/How-to-use-Azure-Container-Registry-for-a-Multi-container-Web-App.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "PHP Minor Version + Xdebug Update for August 2018",
+ "excerpt":" Jennifer Lee (MSFT) 7/12/2018 10:10:50 AM Latest version updates to PHP In August 2018, Azure App Service will update the PHP stacks to the latest available versions. For information on the changes in the new versions, please see the change logs on the PHP website. PHP Version Change log 7.1.19 http://www.php.net/ChangeLog-7.php#7.1.19 7.2.7 http://www.php.net/ChangeLog-7.php#7.2.7 Additionally, the Xdebug binaries will be updated. This includes adding Xdebug support for PHP 7.1 and 7.2. PHP Version Xdebug path 5.6 D:\\devtools\\xdebug\\2.5.5\\php_5.6\\php_xdebug-2.5.5-5.6-vc11-nts.dll 7.0 x86 D:\\devtools\\xdebug\\2.6.0\\php_7.0\\php_xdebug-2.6.0-7.0-vc14-nts.dll 7.0 x64 D:\\devtools\\xdebug\\2.6.0\\php_7.0\\php_xdebug-2.6.0-7.0-vc14-nts-x86_64.dll 7.1 x86 (new) D:\\devtools\\xdebug\\2.6.0\\php_7.1\\php_xdebug-2.6.0-7.1-vc14-nts.dll 7.1 x64 (new) D:\\devtools\\xdebug\\2.6.0\\php_7.1\\php_xdebug-2.6.0-7.1-vc14-nts-x86_64.dll 7.2 x86 (new) D:\\devtools\\xdebug\\2.6.0\\php_7.2\\php_xdebug-2.6.0-7.2-vc15-nts.dll 7.2 x64 (new) D:\\devtools\\xdebug\\2.6.0\\php_7.2\\php_xdebug-2.6.0-7.2-vc15-nts-x86_64.dll Please note that the paths for the xdebug.dll will be changing to the paths in the chart above. This means that the old Xdebug paths will be removed. These old paths include: Xdebug path being removed D:\\devtools\\xdebug\\2.4.0\\php_5.4\\php_xdebug-2.4.0-5.4-vc9-nts.dll D:\\devtools\\xdebug\\2.4.0\\php_5.5\\php_xdebug-2.4.0-5.5-vc11-nts.dll D:\\devtools\\xdebug\\2.4.0\\php_5.6\\php_xdebug-2.4.0-5.6-vc11-nts.dll D:\\devtools\\xdebug\\2.4.0\\php_7.0\\php_xdebug-2.4.0-7.0-vc14-nts-x86_64.dll D:\\devtools\\xdebug\\2.4.0\\php_7.0\\php_xdebug-2.4.0-7.0-vc14-nts.dll See the Xdebug blog post for more information on how to use Xdebug for PHP. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/07/12/PHP-Minor-Version-+-Xdebug-Update-for-August-2018.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Announcing Linux on App Service Environment General Availability",
+ "excerpt":" Jennifer Lee (MSFT) 7/30/2018 10:00:16 AM Interested in deploying your Linux or containerized web app in an Azure Virtual Network? Today, we are excited to announce the general availability of Linux on App Service Environment, which combines the features from App Service on Linux and App Service Environment. As we announced in our public preview, our Linux customers will be able to take advantage of deploying Linux and containerized apps in an App Service Environment, which is ideal for deploying applications into a VNet for secure network access or apps running at a high scale. What can I do with Linux on ASE? With Linux on ASE, you can deploy your Linux web applications into an Azure virtual network (VNet), by bringing your own custom container or just bring your code by using one of our built-in images. If you want bring your own custom Docker container, you can bring your image from: DockerHub Azure Container Registry Your own private registry If you want to use one of our built-in images, we support many popular stacks, such as: Node PHP Java .NET Core And more to come Additionally, both Windows, Linux, and containerized web applications can be deployed into the same ASE, sharing the same VNet. Remember that even though Windows and Linux web apps can be in the same App Service Environment, Windows and Linux web apps have to be in separate App Service Plans. With Linux on ASE, you will be using the Isolated SKU with Dv2 VMs and additional scaling capabilities (up to 100 total App Service plan instances, between Windows and Linux, in one ASE). Depending on whether you want an internet accessible endpoint, there are two different kinds of ASEs that you can create: An external ASE with an internet accessible endpoint or, An internal ASE with a private IP address in the VNet with an internal load balancer (ILB). The consideration here is what kind of IP do you want to expose your apps hosted in your ASE. Steps to get started are provided here. More context about how to configure networking for your ASE can be found here. Pricing Changes from Preview Linux and containerized apps deployed in an App Service Environment will return to regular App Service on Linux and App Service Environment pricing, as the 50% discount on the Linux App Service Plan from public preview is removed for GA. New Regions Added Since public preview, we have now expanded Linux on ASE to all App Service on Linux’s 20+ regions, which include: Australia East Australia Southeast Brazil South Canada Central Canada East Central India Central US East Asia East US East US 2 Japan East Japan West Korea Central Korea South North Central US North Europe South Central US South India Southeast Asia UK South UK West West Central US West Europe West India West US West US 2 How to Get Started You can create a Linux web app into a new ASE by simply creating a new web app and selecting Linux as the OS (built-in image), selecting Docker (custom container), or creating a new Web App for Containers (custom container). When creating a new App Service Plan, remember to select one of the Isolated SKUs. If you need more detailed instructions, get started with creating your first Linux/containerized web app into an ASE by following these instructions. We’d love to hear what you think! Please leave your feedback on Linux on ASE here. Frequently Asked Questions (FAQ) Q: Especially for those new to App Service Environment, how long will everything take to deploy? A: Because an ASE gives you a fully isolated and dedicated environment for securely running App Service apps at high scale, there are many different parts that we provision for you upon creating a web app in an ASE. Instead of sharing front ends, you will have dedicated front ends that are responsible for HTTP/HTTPS termination and automatic load balancing of app requests within the ASE. Therefore, when deploying a web app into an ASE or performing a scaling operation, the operation can take a couple of hours or more. This is not a promised SLA. We recommend that you schedule your scaling operations to account for the time it takes for any extended scaling processes. Improving scaling and deployment time for apps in an ASE is definitely a top priority item for our team to improve on. Q: What should I keep in mind if I want to lock down my ASE with NSG and routing rules? A: Using an App Service Environment is a great use case for controlling network access and locking down access to your applications. This can be done using: Network Security Groups (NSGs), where you can set inbound and outbound security rules Routes, where you can control the outbound traffic to not go directly to the internet (such as an ExpressRoute gateway or a virtual appliance) This is done at the ASE level, and not the app level, which is important to keep in mind (because in the App Service portal, there is an option on the left-hand menu named “Networking” that is grayed out for Linux and container apps. This is unrelated to controlling your network access via NSGs and routes). Additionally, for ASE management purposes, there are some domains and IPs of network resources that the ASE requires to function. For Windows-only ASEs, these are documented here and also are surfaced in the ASE Portal. In additional to these inbound and outbound access dependencies, Linux/containers has other dependencies, such as: docker.io ubuntu.com docker.com treasuredata.com mono-project.com Q: Can I deploy a Multi-Container app with Docker Compose/Kubernetes Config in an ASE? A: You can deploy a Multi-Container app in an ASE, but the Multi-Container offering on App Service on Linux is still in preview. Learn more about how to deploy a Multi-Container app here. Q: Can I deploy a Function app in a container in an ASE? A: You can deploy a Function app in a container in an ASE, but the Function on Linux feature is still in preview. Learn more about how to deploy a Functions on Linux app here. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/07/30/Announcing-Linux-on-App-Service-Environment-General-Availability.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "PHP Minor Version Update for September 2018",
+ "excerpt":" Jennifer Lee (MSFT) 8/1/2018 10:40:29 AM Latest version updates to PHP In September 2018, Azure App Service will update the PHP stacks to the latest available versions. For information on the changes in the new versions, please see the change logs on the PHP website. PHP Version Change Log 5.6.37 http://www.php.net/ChangeLog-5.php#5.6.37 7.0.31 http://www.php.net/ChangeLog-7.php#7.0.31 7.1.20 http://www.php.net/ChangeLog-7.php#7.1.20 7.2.8 http://www.php.net/ChangeLog-7.php#7.2.8 ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/08/01/PHP-Minor-Version-Update-for-September-2018.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Learn how to orchestrate serverless functions by scraping APIs in 8 minutes",
+ "excerpt":" Maxime Rouiller 8/6/2018 9:00:33 AM Our scenario The project I'm working on requires me to retrieve information from multiple sources like the NuGet and GitHub API. Let's bring into focus how I'm downloading data from the GitHub API. If you follow me on Twitter, you've probably already heard me talk about it. Ever ended up on a sample that should be covering the problem you're having, but it just doesn't work? Then, you check the last commit date only to realize that it's been 2 years since the last commit. The way the cloud is evolving, that sample is almost no good to you. Well, some of the repositories on the Azure-Samples organization have those exact issues, and it's one of the many problems that I'm trying to solve. There are tons of samples on the Azure-Samples organization on GitHub, and I want to be able to check them out to see which ones are \"too old.\" What does a user consider a valid sample? For me, a valid sample is an up to date sample. We need a way to retrieve those over 900 samples and validate their last commit date. However, we first need to be able to retrieve all that information. File -> New Project -> Console Application Our first instinct as programmers is to try to do it once through a console application. It's the minimum amount of complexity. If you can't make it work in a console, there's no hope of making it work anywhere else. So, I went ahead and started by consulting the GitHub API documentation, created a GitHub token and started hunting for the information I need. I ended up using the Octokit library to do all of my API access. The code to retrieve the last commit date is below. var github = new GitHubClient(new ProductHeaderValue(\"AzureSampleChecker\")) { Credentials = new Credentials(\"\") }; var lastCommit = await github.Repository.Commit.GetAll(repositoryId, new ApiOptions { PageSize = 1, PageCount = 1 }); var commit = lastCommit.FirstOrDefault()?.Commit; var lastCommitDate = commit.Committer.Date; //snipped: saving to the database First problem: Running locally Everything was running fine, but the problem for me at that point was it was just a single console application running locally. I could have just taken the application as-is to containers, but I saw another way to solve this. I saw another way to scale it up. Azure Functions would help me scale it up. By migrating the existing code into an Azure Function, the problem now was that it was still just a console application running inside an Azure Functions. This will just not cut it. We're just running the same workflow in sequence. We need to execute this workflow in parallel and be able to scale out. Once you know all the repositories that you want to query, it becomes a distributed problem. How many repositories can I hit at once without having any state to correlate between them? The answer is all of them. I needed to refactor to make this process more sturdy. I needed it to be durable. Introducing Durable Functions If you are new to serverless, there's an excellent book by Jeremy Likness that can bring you up to speed. Azure Functions is Microsoft's implementation of the serverless architecture. If you need a refresher, you can review the Azure Functions Overview on what is possible. What is a Durable Function? With durable, it's all about orchestration. Just like in music, the orchestrator ensures that everyone is following the melody, but it's the responsibility of each musician to play their instrument. Regarding Durable Functions, an orchestrator is in charge of starting and tracking a series of functions, but it's the responsibility of each activities to execute their part. Think of the orchestrator as a workflow written in code and activities as the steps of the workflow. An orchestrator and an activity are still Azure Functions. Let's introduce two patterns that I'm using in my code. Function Chaining A pattern I want to cover quickly is function chaining. It's the most straightforward and most commonly used pattern. [caption id=\"attachment_9105\" align=\"aligncenter\" width=\"825\"] Function Chaining[/caption] Everytime that your orchestrator awaits a function before running another one, you're doing function chaining. Here's the above image visualized in a code example. [FunctionName(\"FunctionChaining\")] public static async Task RunFunctionChaining([OrchestrationTrigger]) DurableOrchestrationContext context) { await context.CallActivityAsync(\"F1\", null); await context.CallActivityAsync(\"F2\", null); await context.CallActivityAsync(\"F3\", null); await context.CallActivityAsync(\"F4\", null); } Fan-Out/Fan-In One of the Durable Functions design patterns I used is Fan-Out/Fan-In. [caption id=\"attachment_9095\" align=\"aligncenter\" width=\"577\"] Fan-Out/Fan-In Pattern[/caption] Fanning out means that your orchestrator function (F1) starts as many functions (F2) as necessary in parallel with some initial parameters like the repository I want. Once all those functions have finished executing, we need a way to return the requested data to our orchestrator (F3). Keep in mind that, all those functions may not be executing on the same server. It is not as simple as a multi-threaded application. It's a multi-threaded, multi-server, highly parallel execution workflow. How would you do that in a local data center? A console application would retrieve the list of items on which you want to fan-out. Then, it would queue that list into a messaging system. Once queued up, you would have to have dequeue those messages asynchronously by other console applications that are on different servers. Each console applications would then be responsible for storing the result of their execution on shared storage. Once completed, you'd have to find a way to get the first console application to finish the workflow. Finishing the workflow would involve fanning in all the results back, and saving it to a database. With Azure Functions, it's as easy as returning an object. All the necessary work of storing the results of individual functions and aggregating them together is done automatically for you. This scenario is a hard problem. Durable Functions just saved me easily one week of work and more days of testing, debugging, and refining the process. Now that the introduction is complete let's jump back to our scenario. Orchestrators are special functions Functions with the OrchestrationTrigger behaves widely differently than normal Azure Function. This trigger is what makes a normal Azure Function an Orchestrator Function. Just Its behaviors are incredibly different than other Functions. It is called multiple times at different moment to orchestrate the execution of those functions. It is of the utmost importance that you do not calculate time and access external resources (e.g., SQL, Storage, API) in that context. The orchestrator is tasked to execute and track the status of those functions we started by executing itself repeatedly when something changes. You want the orchestrator function to be deterministic, meaning the same code executed at a different time need to give the same result. So no DateTime, no Math.Random or Guid.NewGuid() should be in an orchestrator. It's also important to note that every call that you make using CallActivityAsync won't be executed more than once for the same orchestrator instance. Results are cached and handled by the Durable Functions. CallActivityAsync is part of the concept that we call checkpoint and replay. In simpler terms, this allows resuming the execution of the orchestrator while remembering the state of the execution of previous activities we ran in a reliable way across servers. Web Scraping scenario Here's the code for my sample orchestrator. [FunctionName(\"DownloadSamples_Orchestrator\")] public static async Task RunOrchestrator([OrchestrationTrigger] DurableOrchestrationContext context, TraceWriter log) { var repositories = await context.CallActivityAsync<List>(\"DownloadSamples_GetAllPublicRepositories\", null); var tasks = new Task[repositories.Count]; for (int i = 0; i < repositories.Count; i++) { tasks[i] = context.CallActivityAsync(\"DownloadSamples_UpdateRepositoryData\", repositories[i]); } await Task.WhenAll(tasks); var samplesToAdd = tasks.Select(x => x.Result).ToList(); await context.CallActivityAsync(\"DownloadSamples_SaveAllToDatabase\", samplesToAdd); } So let's decompose this together. First, I call a function to retrieve the list of over 900 Public Repositories available on Azure-Samples and await for the results before going any further. Then, we create an array of Tasks and go through our samples and start a function without an await for each of them. We're fanning out the execution of those functions to be run and scaled by the cloud automatically. We're not using await here. Otherwise, they would run sequentially instead of in parallel. Then task then need to be awaited till completion. Finally, we aggregate the Samples object that has been returned by those functions into a list. Finally, we send it to a function to save them in a database. We've successfully fanned-in the results of 100s of functions. There is no need for a third-party system. No other configurations. No complex messaging architecture. Just code. Just like that, we've made a complex parallel problem easy. Advanced Scenario: Orchestrating Orchestrators with Sub Orchestrators Isn't it amazing? Now, I have an Orchestrator that instantiates over 900 DownloadSamples_UpdateRepositoryData functions to download data from the GitHub API. What would happen if I have multiple orchestrators of data ingestion that I want to make? How do I orchestrate the orchestrators? We need another orchestrator of course! Here's a simplified version of my code. [FunctionName(\"MainDownloadOrchestrator_TimerStart\")] public static async Task TimerStart([TimerTrigger(\"0 0 7 * * *\")]TimerInfo myTimer, [OrchestrationClient]DurableOrchestrationClient starter, TraceWriter log) { string instanceId = await starter.StartNewAsync(\"MainDownloadOrchestrator\", null); log.Info($\"Started orchestration with ID = '{instanceId}'.\"); } [FunctionName(\"MainDownloadOrchestrator\")] public static async Task RunOrchestrator( [OrchestrationTrigger] DurableOrchestrationContext context) { var runId = await context.CallActivityAsync(\"CommonActivityFunctions_CreateRun\", null); var downloadPipelines = new List(); downloadPipelines.Add(context.CallSubOrchestratorAsync(\"DownloadSamples_Orchestrator\", runId)); downloadPipelines.Add(context.CallSubOrchestratorAsync(\"DownloadSomethingElse_Orchestration\", runId)); //todo: add more orchestrators await Task.WhenAll(downloadPipelines); return context.InstanceId; } What does it do? Create a single run that is going to be used to invoke every other data ingestion orchestrator. All those orchestrators are all going to start at 7 am every day at the same time. They are all going to run as described before. Only this time, they also report back to another orchestrator. Once you start implementing simple workflows, it becomes effortless to build complex scenarios out of simple ones. The same patterns we approached that were used to build a single orchestrator can be used to orchestrate multiple sub-orchestrators. Why do I want this? Imagine working on a team with many different processes that need to run in parallel. Maybe one team is working on the shipping process, the other on the payment process. With a single orchestrator to manage multiple sub orchestrators, it makes team collaboration easier. In my case, what if someone else wants to add the parsing of another API? They can work on their orchestrator and plug it in my MainDownloadOrchestrator function, and that's it. Scraping data from an API is just a single scenario. Whether you are building an order processing system, a conference organization tool or the next revolution in IoT data processing, we know that you need a way to organize complexity within your solution. We know that you want to reuse more significant part of your system than a single function. Durable Functions is how you build complex systems with serverless. What is missing What you haven't seen implemented is how to handle rate limiting. GitHub API has a limit of 5000 (at the time of writing) API calls per hour which is more than enough for the use that I make of it. However, if other teams were to query GitHub some more, I'd need to look into implementing it. I still don't have an elegant solution for this, but it's going to be something I'm looking to implement next. Try it out If you want to try it out, Azure Functions comes with a free quota even with a trial account. If you need an account, you can create one for free. Contribute Azure Functions is also open source. Look at these repositories if you want to contribute or just want to know what's going on with the project. Azure Function Runtime Azure Function CLI for local development Azure Function Portal Azure Functions templates for the portal and Visual Studio Resources to get you started Introduction to Azure Functions Creating your first function in the Azure Portal Running Azure Functions on a Timer Trigger Installing the Durable Functions extensions What is Durable Azure Functions? ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/08/06/Learn-how-to-orchestrate-serverless-functions-by-scraping-APIs-in-8-minutes.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Windows Containers on Azure App Service Public Preview",
+ "excerpt":" Andrew Westgarth 8/8/2018 11:55:52 AM This morning we announced the public preview of Windows Container support on Azure App Service Web App for Containers. You can read the announcement blog, which covers the new capabilities and Dv3 powered SKUs, here - https://azure.microsoft.com/blog/announcing-the-public-preview-of-windows-container-support-in-azure-app-service/ This public preview will enable new opportunities for customers looking to modernize their existing applications. For example here are the steps required to take an existing .Net Framework Web Forms application, containerise it, publish to Docker Hub and then deploy to App Service. Pre-Requisites: Visual Studio 2017 with .Net Core and Azure workloads installed Docker for Windows Docker Hub Account or an Azure Container Registry Create a new or open an existing ASP.Net Web Forms application in Visual Studio 2017 Select the Web Forms project, go to the Project Menu and select \"Docker Support\". If you do not see this option check that you have the .Net Core workload installed with the Visual Studio Installer [caption id=\"attachment_9135\" align=\"aligncenter\" width=\"300\"] Add Docker Support to existing project[/caption] Visual Studio will have created a new docker-compose project and added a Dockerfile to the Web Forms Project. Open the Dockerfile: FROM microsoft/aspnet:4.7.1-windowsservercore-1709 ARG source WORKDIR /inetpub/wwwroot COPY ${source:-obj/Docker/publish} . Change the FROM argument in the Dockerfile to point to a Windows Server 2016 Core base image from the Long Term Servicing Channel. Should you wish to publish a .Net Core application in a Windows Container, use a Windows Server 2016 Nano base image from the Long Term Servicing Channel. We cache certain images as listed in the announcement blog post to enable faster container deployment, for example here specify microsoft/aspnet:4.7.2-windowsservercore-ltsc2016: FROM microsoft/aspnet:4.7.2-windowsservercore-ltsc2016 ARG source WORKDIR /inetpub/wwwroot COPY ${source:-obj/Docker/publish} . Build the project. Select the Web Application and right click Publish. As we are publishing the application in a container we need to publish to a Container Registry. Visual Studio 2017 enables the publishing of containers to an Azure Container Registry, a private registry or Docker Hub. In this example we're going to publish to Docker Hub, so select Container Registry, then choose Docker Hub and click Publish: When prompted enter your Docker Hub account username and password and click Save Once published take a note of the container image name and tag from the Output window. Go to the Azure portal and sign in with your Azure subscription credentials Choose to Create a resource in the upper left-hand corner of the Azure portal. In the search box above the list of Azure Marketplace resources, search for and select Web App for Containers. Provide an app name, such as WindowsContainerHelloWorld, accept the defaults to create a new resource group, and click Windows (Preview) in the OS box. Create an App Service plan by clicking App Service plan/Location > Create new. Give the new plan a name, accept the defaults, and click OK Click Configure container, type the username/image:tag that you noted in the output window earlier, for example, mydockerhub/myimage:latest in Image and optional tag, and click OK. Click Create and wait for Azure to create the required resources, you will be notified when the operation completes. Click Go to resource in the notification box. In the application overview click Browse, you will see a page showing the container is starting up Refresh the page after a few minutes and you will see your ASP.Net Web Forms application running! We want to hear from you! Windows Container support for Azure App Service provides you with even more ways to build, migrate, deploy, and scale enterprise grade web and API applications running on the Windows platform. We are planning to add even more capabilities during the public preview and we are very interested in your feedback as we move towards general availability. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/08/08/Windows-Containers-on-Azure-App-Service-Public-Preview.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Twitter AMA with the App Service Team #AppServiceAMA!!",
+ "excerpt":" Oded Dvoskin 8/9/2018 10:09:35 AM The Azure App service team will host a special Ask Me Anything (AMA) session on Twitter, Wednesday, August 22, 2018 from 9 AM to 11 AM PST. You can tweet to @AzureSupport with #AppServiceAMA with your questions about the service. What's an AMA session? We'll have folks from across the Azure App Service engineering team available to answer any questions you have. You can ask us anything about our products, services, roadmap, new features or even about our team! Why are you doing an AMA? We love reaching out and learning from our customers and community. We want to know how you use Azure in general and App Service specifically and how your experience has been. Your questions provide insights into how we can make the service even better. How do I ask questions on Twitter? Just use the hashtag #AppServiceAMA in your tweet to @AzureSupport and we will record the rest. The doors open to the community to start posting questions to the #AppServiceAMA 24 hours prior to the AMA (Tues Aug 21st at 9am PST). The questions will be recorded, and will be answered on the day of the AMA. This is to allow customers in different time zones or who can’t attend the event to ask their questions and get answers directly from the Azure App Service team. You can catch us for a live conversation on Aug 22, 2018 from 9am to 11am PST. If there are follow-ups, we will continue the dialogue post AMA. Go ahead and tweet to us! Who will be there? You, of course! We'll also have Program Managers and Developers from the App Service engineering team participating, pulling in specific people depending on the topics. Have any questions about the following topics? Bring them to the AMA. App Service Environment App Service on Linux / Web App for Containers Multi-Containers in App Service App Service Diagnostics Best practice for high traffic resiliency Scaling App Service Plans / Autoscale Networking and Isolation Deploying App Service Deployment slots, when to use and how Much, much more! Why should I ask questions here instead of StackOverflow or MSDN? Can I really ask anything? An AMA is a great place to ask us anything. StackOverflow and MSDN have restrictions on which questions can be asked. With an AMA, you’ll get answers directly from the team and have a conversation with the people who build these products and services. Here are some question ideas: What is App Service? What are the benefits of PaaS in comparison with IaaS? How do I manage access control to my resources? How many apps can I host on each App Service Plan? How do I monitor the health of the traffic to my apps? How do I solve issues that may happen with my app and its resources? How can I isolate the traffic to my app? How do I autoscale my app and how does affect billing? How is life in Seattle? Does it really rain all the time? Go ahead, ask us anything about our public products or the team. Please note, we cannot comment on unreleased features and future plans and issues which require deep level debugging. We're looking forward to having a conversation with you! ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/08/09/Twitter-AMA-with-the-App-Service-Team-AppServiceAMA!!.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Azure App Service on Azure Stack Update 3 Released",
+ "excerpt":" Andrew Westgarth 8/15/2018 3:23:17 PM This afternoon we released the third update to Azure App Service on Azure Stack. This release updates the resource provider and brings the following key capabilities: Support for use of SQL Server Always On for Azure App Service Resource Provider databases. Updates to App Service Tenant, Admin, Functions portals and Kudu tools. Updates to ASP.Net Core, NodeJS, Zulu OpenJDK, Tomcat, PHP, Wincache and Git All other fixes and updates detailed in the App Service on Azure Stack Update Three Release Notes You can download the new installer and helper scripts: Installer – https://aka.ms/appsvcupdate3installer Helper Scripts – https://aka.ms/appsvconmashelpers Please read the updated documentation prior to getting started with deployment: Before you get started with App Service on Azure Stack Deploy the App Service Resource Provider for new deployments Update the App Service Resource Provider for updating existing deployments ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/08/15/Azure-App-Service-on-Azure-Stack-Update-3-Released.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Avoid downtime due to Docker Hub's scheduled maintenance window on August 25th",
+ "excerpt":" Yi Liao MSFT 8/20/2018 10:46:46 AM Summary Docker has scheduled a maintenance window for Docker Hub on Saturday August 25th, which has potential impacts to App Service customers. For Web App for Containers (using custom Docker image), customers will not be able to create new web apps using a Docker container image from Docker Hub during the maintenance window. Customers can still create new apps using Docker images hosted on Azure Container Registry or a private Docker registry. For App Service on Linux (using non-preview built-in stacks), customers will not be impacted as we have Docker container images cached on our Linux workers. Recommendation To avoid unnecessary service interruptions, we recommend Web App for Containers customers not make any changes or restart your apps, or use an alternative Docker registry during the Docker Hub maintenance window. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/08/20/Avoid-downtime-due-to-Docker-Hub's-scheduled-maintenance-window-on-August-25th.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "DevTalk App Service - SSL Settings Revamp",
+ "excerpt":" Chibi Chakaravarthi V 8/23/2018 2:00:40 PM App Service SSL settings experience is one of the most used features in App Service. Based on customer feedback we are making the following changes to the UX to address and improve the overall experience of managing certificates in Azure App Service. Tabs The new SSL settings experience divides the features into 3 tabs. Namely SSL Bindings, Private certificates (.pfx), and Public certificates (.cer). The Bindings tab allows the user to configure the protocol settings and add/edit/delete SSL bindings, the private certificates tab allows the user to upload and manage private certificates (.pfx) used in SSL bindings and the public certificates tab allows the user to upload and manage public certificates (.cer). We also call out what type of certificate type the customer needs to use for each feature. Editing SSL Bindings SSL Settings didn't have a way to update an existing SSL binding, the feature to edit was present but unfortunately hidden under the Add Binding flow. We enabled the ability to edit a few sprints ago, we polished the feature further and now the customer is free to edit any binding by clicking on the row. When you change the thumbprint for the IP Based SSL binding the IP will not be lost, but if you change out from IP Based SSL to SNI and back you will lose the IP. The ability to change the certificate without removing and adding back the binding was an issue in the past we are addressing with this release. For more details on adding SSL Bindings click here. Private Certificate Details Private certificates used in App Service required a facelift to show the information we already gather when the certificate is uploaded, imported from App Service Certificate or imported from KeyVault. The driving reason was when we saw hundreds of private certificates configured on their app and had a tough time browsing through the certificates, the revamp allows the customer to now to get details of the certificates uploaded and imported. We added a new status column to the grid showing three possible states. Healthy, Warning and Expired. Warning being a certificate about to expire in the next 60 days. We also explicitly mention that you will need to upload a .pfx file to add a private certificate. [caption id=\"attachment_9355\" align=\"aligncenter\" width=\"1429\"] Showing a test certificate that is valid.[/caption] We also show the KeyVault details and the sync status of the certificates pulled from KeyVault like certificates imported from App Service Certificate. Uploading certificates The Upload Certificate experience overall is more consistent in showing that private certificates only accept .pfx file and you need a valid pfx to add a private certificate to your App Service. Addressing another feedback, we stopped showing both upload path. Now upload certificates from the private certificates opens the UX where you can only upload the private certificates to avoid the confusion about uploading .cer or .pfx file. When the Upload certificate flow is opened from the public certificate tab we show only the public certificate option. We updated the upload certificate UX (and the underlying way it is implemented) to show errors while trying to upload a certificate without leaving the upload blade. Public Certificates Public certificates can only be used by your app and they cannot be used for making SSL bindings. We are working out a way to move it to a place where it will make more sense. For now, SSL Setting is the place where Public certificates will reside. Private certificates require app settings to enable that feature (it's covered in this very old but reliable blog here) and now public certificates add another dimension to that feature by allowing you to upload (.cer) files and get the certificates in runtime. Thanks for reading! I am writing this blog to showcase the changes we made to improve the overall certificate management experience for customers using App Service day in and day out. We are always open to feedback and looking forward to your comments. Feel free to reach out to us for any feature request or issues. App Service MSDN forum Feature Requests ","categories": ["certsdomains"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/08/23/DevTalk-App-Service-SSL-Settings-Revamp.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Announcing the New Auto Healing Experience in App Service Diagnostics",
+ "excerpt":" Jennifer Lee (MSFT) 9/10/2018 9:31:11 AM Note: Currently, this new experience is only for Windows web apps for now. Hopefully, most of the time your apps are running healthily and happily. However, sometimes your app may run into issues, resulting in downtimes, slowness, or other unexpected behaviors. We’ve built App Service Diagnostics to help you diagnose and solve issues with your web app with recommended troubleshooting and next steps. You can learn more about App Service Diagnostics here. However, these unexpected behaviors may be temporarily resolved with some simple mitigation steps, such as restarting the process or starting another executable, or require additional data collection, so that you can better troubleshoot the ongoing issue at a later time. Today, we’re excited to announce our new Auto Healing experience in App Service Diagnostics. With our new Auto Healing tile shortcut, you can set up custom mitigation actions to run when certain conditions (that you define as unexpected or a sign of unhealthy behavior) are met. Click Diagnostic Tools from the App Service Diagnostics homepage. Then, click Auto-Heal. How to Get Started Step 1: Define conditions Select the tile that best matches the condition that you want to set for your mitigation rule. The conditions that are supported with the new Mitigate/Auto Heal experience in App Service Diagnostics are: Request Duration: examines slow requests Memory Limit: examines process memory in private bytes Request Count: examines number of requests Status Codes: examines number of requests and their HTTP status code After reading the description, select the blue button to configure the rule parameters. Parameters that have a red asterisk next to it are required fields. Step 2: Configure actions Select the tile that best matches the auto heal mitigation action that you want to perform under your mitigation rule conditions. When the graphic is blue, it means that action has been selected. (For custom actions, be sure to fill out the parameters required). The custom mitigation actions that are supported are: Recycle Process Log an Event Custom Action Run Diagnostics: runs Run Any Executable: runs specified executable Step 3: Override when action executes (optional) Sometimes when an app has a long startup time, depending on the mitigation rule conditions that are set, it may kick off the mitigation action during app startup, which is not the intended use case. By modifying the startup time, you can specify how much time the mitigation rule should wait after the process startup before the mitigation rule kicks off. Step 4: Review and save your settings Here, you can review the rules that you just created and save them. If you have previously defined rules, they will show up under Current Settings (no rules will show up under Current Settings until they are saved). Saving mitigation settings will restart the application domain for the web app and this can cause logged-in user information, sessions, and in-memory cache to be cleared. Hence, it is advised to make these changes during non-business hours. Two things to keep in mind: These mitigation actions should only be considered a temporary workaround until you find the real cause for the issue causing the unexpected behavior. For the latter, you can start with App Service Diagnostics to figure out what actually went wrong. The feature in this blog post is in addition to Proactive Auto Heal, which is automatically restarts your web app based on our percent memory and percent request rules. Learn more about Proactive Auto Heal here. How to Delete a Mitigation Rule For the mitigation rule that you want to delete, select the condition that the rule is set on. Then, click on the trash can next to the rule that you configured. Get ahead of your issues and automatically mitigate these unexpected behaviors by trying out Mitigate and Auto Heal in App Service Diagnostics. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/09/10/Announcing-the-New-Auto-Healing-Experience-in-App-Service-Diagnostics.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "New Price Drops for App Service on Linux",
+ "excerpt":" Jennifer Lee (MSFT) 9/12/2018 10:53:36 AM Have you tried bringing your code or bringing your container to App Service on Linux yet? App Service on Linux is a fully managed platform that allows you to quickly build, deploy, and globally scale your apps. You can bring your code to App Service on Linux and take advantage of the built-in images for popular supported language stacks, such as Node, Java, PHP, etc, or bring your Docker container to easily deploy to Web App for Containers. We have seen strong adoption since the General Availability of App Service on Linux and Web App for Containers in September 2017. Basic and Premium Price Drop To encourage further adoption, we’re happy to announce a 30% price drop for the Basic App Service Plan for Linux, and a 20% price drop for the Premium App Service Plan for Linux. The price change takes effect on October 1st, 2018. Learn about more details on the App Service Pricing page. Please note the price change applies to any existing Linux Basic and Premium App Service Plans as well as new Basic and Premium App Service Plans created on or after the effective date. Linux on ASE GA Price Offering As some of you may know, we announced that Linux on App Service Environment (ASE) is now generally available. Because Linux on App Service Environment combines the features from App Service on Linux and App Service Environment, Linux customers will be able to take advantage of deploying Linux and containerized apps in an App Service Environment. This is ideal for deploying applications into an Azure Virtual Network for secure network access or apps running at a high scale. 🔒Lock down your app in an Azure Virtual Network (VNet) 🎨Run Windows, Linux, and containerized apps in the same ASE 📈Use the Isolated SKU with Dv2 VMs and scale up to 100 VMs 🌏GA and 20+ Azure regions available Linux on ASE saw healthy adoption during preview, and we’d like to encourage further adoption now that we’re in General Availability. Taking that into consideration, we’re extending the preview price (for Linux on ASE, which is the Linux Isolated App Service Plan SKU) for a limited time through GA! Please note that when this limited time GA price offering ends, the final Linux on ASE price will be approximately twice the price of our Premium SKU. (Once the price offering ends, the prices will be closer to Windows on ASE.) While the date for the GA price change is TBD, a 30-day notice will be given and announced here on our App Service Team Blog as well. Now is the time to bring your code or bring your Docker container to App Service on Linux! ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/09/12/New-Price-Drops-for-App-Service-on-Linux.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Azure Functions feeding your Serverless appetite at Microsoft Ignite 2018!",
+ "excerpt":" Oded Dvoskin 9/20/2018 11:38:55 AM Microsoft Ignite is taking place between September 24-28 and we can't wait for it to finally arrive! We are looking forward to all the great interactions with our customers, learning about the various new scenarios being solved with Serverless and of course announcing all the exciting news we've been keeping under the wraps! Can't make it to Ignite? No worries, we've got you covered! Log in to the Microsoft Ignite site to tune in to the keynotes live. We'll also publish recordings of all the sessions presented a few days later. If you're at Ignite, please join us for these following sessions which will give you the very best of what Azure Functions has to offer at Ignite! Just log in to your session scheduler to save these sessions and attend them all. Build real-time serverless apps with Azure Functions and SignalR Service In this session, learn how the Azure Functions integration with Azure SignalR Service works, so you can work with it using all languages supported by Functions and integrate different Azure services for real-time tasks to build an entirely serverless web application. Speaker: Anthony Chu. Code: THR2195. Time: Monday at 6:25pm. Azure Functions for the enterprise Serverless solutions are a common developer’s choice these days, due to clear productivity benefits. However, when using such solutions in the enterprise, many other important aspects come to mind, such as security, monitoring, scalability and DevOps. In this session we explore how serverless development with the Azure platform helps you get to market faster while still fulfilling all your administration policies. We dive deeply into the features Azure Functions provides to delight both developers and IT, as well as best practices for using them in your enterprise-grade serverless solutions. Speakers: Jeff Hollan, Matthew Henderson. Code: BRK3348. Time: Tuesday at 9:00am. Build intelligent serverless applications From data ingestion, processing, model training, model updates to prediction - machine learning is hard! Join us to learn how serverless makes it all easier so you can stop worrying about managing the underlying infrastructure and focus on getting the most value out of your data, whether you're running in the cloud or on an IoT device. Speakers: Asavari Tayal, Colby Tresness. Code: BRK3352. Time: Wednesday at 9:00am. Build microservices applications with a serverless architecture When you learn how to build your cloud-native applications using a PaaS architecture, infrastructure management or scaling based on demand isn't a problem anymore. In this session, we discuss how to go all serverless on microservices-based applications with a reference architecture, including data storage, endpoints management, and compute services. Speaker: Gorka Madariaga Nuñez. Code: BRK2027. Time: Wednesday at 3:15pm. Machine Learning using Python in Azure Functions Learn how to build smarter serverless workloads with Azure Functions powering machine learning and data analysis models using Python. Speaker: Asavari Tayal. Code: THR2201. Time: Wednesday at 5:05pm. Azure Functions internals Join our product engineering team on a technically deep lap around Azure Functions. Learn how Azure Functions enables you to quickly and easily deploy application services that scale massively in a cost-effective way, without having to worry about infrastructure and server management. This session goes beyond the basics to show you behind the scenes details on the latest advancements made by the product team. Azure Functions users learn new concepts in a demo-driven session covering topics like deployment, service management, and monitoring. Speakers: Eduardo Laureano, Fabio Cavalcante. Code: BRK4020. Time: Thursday at 9:00am. Serverless real use cases and best practices Let's take a look at real cases from our customers worldwide, to learn how they solved their problems through our serverless platform, as well as best practices (and some caveats) from the architectures used developing these solutions. Speakers: Eduardo Laureano, Thiago Almeida, Nick Lizotte. Code: BRK2202. Time: Thursday at 12:45pm. Automate your cloud infrastructure with Azure Functions, Azure Automation, and more Companies are constantly increasing their cloud footprint, creating a wealth of resources that need to managed. IT professionals are looking for the most efficient ways to automate management operations on those resources. Learn in this session the multiple ways in which you can simplify your life by using Azure Functions, Azure Automation, Logic Apps and Event Grid. After this session, you will be armed with choices that fit your preferences and needs. Speakers: Colby Tresness, Eamon O'Reilly. Code: BRK2208. Time: Friday at 10:45am. Even more! In addition to these fantastic sessions, we are also holding a live webcast on Thursday, September 27th at 2:15pm EST. Tune in to aka.ms/AzureFunctionsLive to hear a recap of all our announcements and get an opportunity to ask Jeff and Eduardo live questions! Lastly, if you want to score a special prize, check out the questions here, write them down and come to our booth with the correct answers for a surprise. Of course, you can always stop by our booth regardless, meet the team, get your most burning questions answered and score some swag! See you all soon at Microsoft Ignite in Orlando! ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/09/20/Azure-Functions-feeding-your-Serverless-appetite-at-Microsoft-Ignite-2018!.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Check out App Service sessions at Microsoft Ignite 2018!",
+ "excerpt":" Oded Dvoskin 9/20/2018 11:39:54 AM We're getting excited leading up to Microsoft Ignite happening between September 24-28! As usual, there are many amazing sessions, announcements, demos, interactions and content planned. Can't make it to Ignite? No worries, we've got you covered! Log in to the Microsoft Ignite site to tune in to the keynotes live. We'll also publish recordings of all the sessions presented a few days later. As an attendee, it's always challenging to figure out which sessions to attend. Whether you are an advanced user of PaaS and App Service, or just getting started, we know you'll find the following sessions useful in planning your Ignite learning. Just log in to your session scheduler to save these sessions and attend them all. Your web apps from code to deployed in a minute! Web developers want to focus on code, not be held back by the pain of getting an app deployed to Azure App Service. In this session, learn how to use Azure CLI to deploy your code to App Service with a single command, regardless of your language. Speaker: Nick King. Code: THR1110. Time: Monday, 12:45pm. Best practices for mission critical apps on Azure App Service Azure App Service provides 99.95% SLA even for apps running on only a single instance. However, there are steps you should take as a developer to insulate your customers from perceived cold start latencies incurred when deploying a new version of an app. This session walks through using a combination of multi-phase deployment slots (swap with preview), local cache for disk resiliency, application initialization for warmup, and proper app service plan configuration to minimize cold start performance hits. Speaker: Stefan Schackow. Code: THR3105. Time: Monday, 1:20pm. Oops, I deleted my web app! What now? Sometimes, intentionally or accidentally, an Azure App Service web app get deleted. Up to now, the only way to restore that app was to open a support ticket. Introducing Azure App Service Web App Undelete, where you can restore your app without the need to have a support plan. In this session, learn how to use the different Azure management tools to restore your deleted app. Speakers: Nick King, Oded Dvoskin. Code: THR2204. Time: Monday, 5:45pm. What is new in Azure App Service networking The Azure App Service has had multiple features to enable application isolation and virtual network access. Some of these capabilities required the use of an App Service Environment (ASE). New features have been developed to enable numerous use cases without the use of an ASE such as hosting line-of-business applications, accessing resources across ExpressRoute and also accessing resources that are secured with service endpoints. At the same time we are also making major improvements to the ASE and are enabling greater isolation than previously. Speaker: Christina Compy. Code: BRK2386. Time: Tuesday, 2:00pm. Fundamentals of Windows containers and Windows container-based web apps on Azure App Service Join us to learn why containers are a paradigm shift to a modern DevOps workflow! Container isolation empowers developers and IT to collaborate effectively with clear boundaries of configuration and execution. In this session we show real-life examples, covering how to dockerize your web and API apps, how to run Windows-server based containers on Azure App Service, and how to perform container customizations for scenarios such as image generation, custom font installation, GAC assemblies, and calling native DLLs from your web apps. Learn how to get direct access into running containers to run PowerShell commands. If you want to achieve new levels of collaboration, you can’t miss this session! Speaker: Andrew Westgarth. Code: BRK2045. Time: Tuesday, 2:15pm. Keep your PaaS and serverless apps healthy and happy Working on an web app on Azure App Service or Azure Functions? Join us to learn tips and tricks that will help you quickly and easily diagnose and resolve issues with your web app, Functions app, or App Service environment. In this session, learn how to effectively leverage App Service diagnostics for troubleshooting in both proactive and problem-first scenarios. We walk through real-world scenarios that guide you to a cure for common app issues. Speaker: Jennifer Lee. Code: BRK3344. Time: Tuesday, 4:30pm. Bring your container or code to easily deploy to App Service on Linux Are you interested in our newest container and OSS offerings in Azure App Service on Linux? In this session, we walkthrough how easy it is to bring your containerized Linux app to Web App for Containers and take advantage of the PaaS environment for increased efficiency. We also show you how to modernize classic app architecture with multi-containers, new OSS announcements, and how to diagnose and keep your app running healthily. With simplicity at scale, learn about how you can operate at a global scale by utilizing the latest features to make your app production ready. Speakers: Jennifer Lee, Jenny Lawrance. Code: BRK2390. Time: Friday, 12:30pm. Last, but not least, be sure to drop by our booth for some good conversation, get your technical questions answered and stock up on cool swag! See you in Orlando! ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/09/20/Check-out-App-Service-sessions-at-Microsoft-Ignite-2018!.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Announcing Bring your own Storage to App Service",
+ "excerpt":" Ranjith Ramachandra 9/24/2018 12:34:40 PM Bring your own Storage to App Service now in Public Preview We’re excited to announce the “Bring Your Own Storage” feature to App Service on Linux and Web App for Containers. Available in public preview, “Bring Your Own Storage” supports mounting Azure Blobs and Azure Files into your Azure App Service. You can configure up to five Azure storage accounts for a given App Service. “Bring your own storage” for example, enables the following scenarios: Bring your own content and have it readily available for your web application hosted on App Service. This avoids the need to copy the content which could take a lot of time depending on the number and size of the files. Use the azure blob storage or azure files to write content or Log files which can be shared across different services you might have. For example, you can use any log management service like splunk with your app service writing logs to the azure files or blob storage and the log management service can consume the logs from the storage. Configure azure storage account on App Service With this public preview annoucement, Azure CLI will have support for “Bring your own storage”. The UX experience is coming soon. Login to the CLI and ensure you have selected the right subscription: $ az login $ az account list $ az account set –subscription “YourSubscriptionName” To get help on the command to manage storage accounts on your app service, use the -h option: az webapp config storage-account -h Group az webapp config storage-account : Manage a web app's Azure storage account configurations. Commands: add : Add an Azure storage account configuration to a web app. delete : Delete a web app's Azure storage account configuration. list : Get a web app's Azure storage account configurations. update : Update an existing Azure storage account configuration on a web app. Add a storage account to your app service To add a new storage account, you will need an Azure Storage (blob or azure files). If you haven’t created one yet, please follow the steps mentioned here to create one. Also, to learn more about how to create App Service, please follow the steps here. To link a storage account with your App Service (assumes you have already created the app service and the storage account), use the following command: $ az webapp config storage-account add -g RESOURCE_GROUP -n APP_NAME \\ --custom-id CustomId [Unique identifier for this storage mapping] \\ --storage-type [Azure storage type: AzureFiles or AzureBlob] \\ --account-name [Azure storage account name] \\ --share-name [Azure storage share/file name] \\ --access-key [storage access key] \\ --mount-path [/path/to/mount within the container] Sample: $ az webapp config storage-account add -g AppSvcBYOSDemoSite -n AppSvcBYOSDemoSite --custom-id MediaVolume --storage-type AzureBlob --account-name appsvcbyosdemo --share-name mediablob --access-key <youraccesskey> --mount-path /var/media Output: { \"MediaVolume\": { \"accessKey\": \"youraccesskey\", \"accountName\": \"appsvcbyosdemo\", \"mountPath\": \"/var/media\", \"shareName\": \"mediablob\", \"state\": \"Ok\", \"type\": \"AzureBlob\" } } At this point, your web application will have the storage mounted at /var/media and your web application has full access to this storage. If you want to use the mounted storage account in a Multi-container web app, you need to specify the custom-id of your storage account in the volumes block of your container definition in the Docker-Compose or Kubernetes yaml file, for example: version: '3' services: web: image: \"mydocker/image:latest\" ports: - \"80:80\" volumes: - <custom-id>:/var/media redis: image: \"redis:alpine\" List storage accounts associated with the App Service To list the storage accounts associated with your app service, use the list command: $ az webapp config storage-account list -g RESOURCE_GROUP -n NAME Sample: $ az webapp config storage-account list -g AppSvcBYOSDemoSite -n AppSvcBYOSDemoSite Output: [ { \"name\": \"MediaVolume\", \"slotSetting\": false, \"value\": { \"accessKey\": \"youraccesskey\", \"accountName\": \"appsvcbyosdemo\", \"mountPath\": \"/var/media\", \"shareName\": \"mediablob\", \"state\": \"Ok\", \"type\": \"AzureBlob\" } } ] Update storage account associated with the App Service To update the storage accounts associated with your app service, use the update command: $ az webapp config storage-account update -g RESOURCE_GROUP -n APP_NAME \\ --custom-id CustomId [Unique identifier for this storage mapping] \\ --storage-type [Azure storage type: AzureFiles or AzureBlob] \\ --account-name [Azure storage account name] \\ --share-name [Azure storage share/file name] \\ --access-key [storage access key] \\ --mount-path [/path/to/mount within the container] Sample: $ az webapp config storage-account update -g AppSvcBYOSDemoSite -n AppSvcBYOSDemoSite --custom-id MediaVolume --storage-type AzureBlob --account-name appsvcbyosdemo --share-name mediablob --access-key <youraccesskey> --mount-path /var/media Output: { \"MediaVolume\": { \"accessKey\": \"youraccesskey\", \"accountName\": \"appsvcbyosdemo\", \"mountPath\": \"/var/media\", \"shareName\": \"mediablob\", \"state\": \"Ok\", \"type\": \"AzureBlob\" } } Remove storage account associated with the App Service To remove the storage account from the Azure App Service, use the delete command. $ az webapp config storage-account delete -g RESOURCE_GROUP -n APP_NAME --custom-id CustomId Sample: az webapp config storage-account delete -g AppSvcBYOSDemoSite -n AppSvcBYOSDemoSite --custom-id MediaVolume Output: {} Sample Web Application that uses external Azure Storage for static files Here is a sample dotnetcore web application that shows how you easy it is to use an Azure Storage account to store your content and reference it in your web application. Useful Links Hosting Web Applications on Azure App Service Creating Azure Storage Accounts and Azure Files Deploying web applications to Azure App Services ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/09/24/Announcing-Bring-your-own-Storage-to-App-Service.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Announcing Webapps Undelete (Preview)",
+ "excerpt":" Ahmed Elnably 9/24/2018 10:42:08 AM Azure App Service Undelete now in public preview Today we are announcing the public preview release of Azure App Service Undelete. Undelete is available for all App Service Plans, from Basic and up. Only sites deleted in the past 30 days can be restored. A user can undelete a deleted web app, and restore the following: The content of the deleted app. The configuration of the app (the commands allows to skip the restoration of the app configuration). The undelete commands will also to restore the *.azurewebsites.net host name if still available. Currently the undelete commands support the restoration of apps deleted from the multi-tenant using Windows and Linux, other services like App Service Environments and Azure Functions will be supported in later releases. To get started, install the PowerShell module or install Azure CLI. Azure CLI List deleted apps You can list deleted apps using the following command, you can use the optional parameters to filter the apps with a specific name, belong to a specific resource group or App Service plan. Record the id of the deleted site as that will be used to restore the app. az webapp deleted list --name <name of the deleted app> Restore a deleted app In CLI you need to have an existing app or an app slot to restore your app to az webapp deleted restore --deleted-id <id of the deleted app> --name <name of the app to restore to> --resource-group <resource group of the app to restore to> Azure PowerShell List deleted apps You can list deleted apps using the following command, you can use the optional parameters to filter the apps with a specific name, belonging to a specific resource group. Get-AzureRmDeletedWebApp -name <name of the deleted app> Restore a deleted app In PowerShell, you can specify the name and resource group of the deleted app, and provide the information of the target app. You can specify an App Service plan name to restore to, and the command will try and restore the app with the same *.azurewebsites.net hostname as the deleted app. Restore-AzureRmDeletedWebApp -ResourceGroupName <deleted app rg> -Name <deleted app name> -TargetAppServicePlanName <App Service plan name to create an app to restore to> ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/09/24/Announcing-Webapps-Undelete-(Preview).html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Announcing the New App Service Diagnostics Experience",
+ "excerpt":" Jennifer Lee (MSFT) 9/24/2018 2:00:51 AM Today, we’re excited to announce our new user experience for App Service Diagnostics. App Service Diagnostics is our intelligent and interactive experience to help you diagnose and troubleshoot issues with your app. You can use Genie to guide you through the different ways to troubleshoot a variety of potential issues, since sometimes bad things happen to good apps. You can learn more about App Service Diagnostics in these other blog posts. Since we’ve first started with helping you with availability and performance issues, the coverage of issues that App Service Diagnostics has grown. To accommodate for a variety of problem categories and to more closely integrate with other troubleshooting content, we have revamped the user experience for App Service Diagnostics. How to Get Started As always, without any additional configuration, you can access App Service Diagonstics by: Go to the Azure Portal. Select your app (Windows, Linux, or Functions) or App Service Environment. Click on “Diagnose and solve problems.\" You can still access the old experience by selecting the blue bar at the top. Problem Categories In the new App Service Diagnostics homepage, the guided diagnostics experience is now separated into different problem categories to help you be more focused on the specific issue that you’re facing. Each problem category will have a description and keywords to help describe what types of problems would fall underneath that category. If you’re new to diagnosing issues with your app or new to App Service, it’s a good idea to click around these tiles to investigate your issue. The health checkup from our old experience will be under Availability and Performance. Genie and Tiles for Each Problem Category Once you have selected a problem category, you are introduced to Genie, who will guide you through the troubleshooting experience for that category. In this new iteration, Genie is specific to the problem category that you’ve selected. The blue buttons that show up are tiles; you should select those that best match your issue. These tiles run analyses on our end and output insights that show up within Genie. You should click on these insights to get more data, the full report, and actual suggestions on what to do next. Insights are arranged in terms of severity: Red: critical Orange: warning Green: success Blue: informational Once you click on the insight, there may be more insights and next steps to follow. Make sure you select each insight to expand to show more details. Also, there is a new time picker on the top right to help to navigate between different time periods of interest. At any time, select Show Tile Menu to show all the tiles for that problem category. Search Documentation Also new to Genie’s flow is our Search Documentation. If the tiles weren’t of help, you can enter in your issue in the inline search bar that appears after you select Search Documentation. This will do a web search of the issue you’ve written about to find relevant content that might help you with your “how do I…?” questions. It brings up the most relevant results if you include “App Service” or “web app” in your search terms. Search App Service Diagnostics Now, in the new App Service Diagnostics home page, we have a search bar in the top left-hand corner. This search bar allows you to search within App Service Diagnostics to find the relevant tiles or tools that fit the search term. Therefore, the search bar is great when you are more experienced with App Service Diagnostics and know specifically what problem category, tile, or diagnostic tool you’re looking for. You can just type in the search term and quickly get to the tile that you’re interested in, which is great when showing your troubleshooting methods to other members on your team. Diagnostic Tools The Diagnostic Tools problem category is where our advanced tools are now. These include all the Support Tools that were on the right-hand side of the page as well our new Auto Healing feature. This is a great option for our advanced users who want to collect a profiler trace, memory dump, network trace, and more. Best Practices The Best Practices problem category is where our suggestions for running production apps in the cloud are. These suggestions are app-specific recommendations for optimizing your app configurations for production. As before, App Service Diagnostics is a great first step in guiding you through the troubleshooting experience on App Service, App Service Environment, or Azure Functions. Please try out the new experience and let us know about your feedback! ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/09/24/Announcing-the-New-App-Service-Diagnostics-Experience.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Twitter AMA with the Azure Functions team #FunctionsAMA!",
+ "excerpt":" Oded Dvoskin 10/1/2018 2:12:42 PM The Azure Functions team will host a special Ask Me Anything (AMA) session on Twitter, Thursday, October 11, 2018 from 9 AM to 11 AM PST. You can tweet to @AzureFunctions or @AzureSupport with #FunctionsAMA with your questions about the service. What's an AMA session? We'll have folks from across the Azure Functions engineering team available to answer any questions you have. You can ask us anything about our products, services, roadmap, new features or even about our team! Why are you doing an AMA? We love reaching out and learning from our customers and community. We want to know how you use Azure in general and Functions specifically and how your experience has been. Your questions provide insights into how we can make the service even better. How do I ask questions on Twitter? Just use the hashtag #FunctionsAMA in your tweet to @AzureFunctions or @AzureSupport and we will record the rest. The doors open to the community to start posting questions to the #FunctionsAMA 24 hours prior to the AMA (Wednesday Oct 10th at 9am PST). The questions will be recorded, and will be answered on the day of the AMA. This is to allow customers in different time zones or who can’t attend the event to ask their questions and get answers directly from the Azure Functions team. You can catch us for a live conversation on Oct 11th, 2018 from 9am to 11am PST. If there are follow-ups, we will continue the dialogue post AMA. Go ahead and tweet to us! Who will be there? You, of course! We'll also have Program Managers and Developers from the Functions engineering team participating, pulling in specific people depending on the topics. Have any questions about the following topics? Bring them to the AMA. Getting started with Serverless. Deciding between hosting Functions in a consumption or dedicated plan. Functions runtime 2.0. Consumption plan on Linux (preview). Hosting Functions in containers. Bindings and Triggers connecting to other services. Scaling operations. Monitoring and debugging Functions. Where to develop Functions. Best practice. Much, much more! Why should I ask questions here instead of StackOverflow or MSDN? Can I really ask anything? An AMA is a great place to ask us anything. StackOverflow and MSDN have restrictions on which questions can be asked. With an AMA, you’ll get answers directly from the team and have a conversation with the people who build these products and services. Here are some question ideas: What is Serverless? What is Functions? What are the benefits of Serverless in comparison with IaaS? How do I manage access control to my resources? How many functions should I host in each Function app? How do I monitor the health of my functions? How do I diagnose issues that I suspect are happening with my functions' health? What is the Azure Functions Premium plan? When to choose between Durable Functions and Logic Apps? Between Functions and Logic Apps? Does Serverless really mean the lack or Servers? What is this madness?? Go ahead, ask us anything about our public products or the team. Please note, we cannot comment on unreleased features and future plans and issues which require deep level debugging. We're looking forward to having a conversation with you! ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/10/01/Twitter-AMA-with-the-Azure-Functions-team-FunctionsAMA!.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "PHP Minor Version Update for November 2018",
+ "excerpt":" Jennifer Lee (MSFT) 10/4/2018 10:30:21 AM Latest version updates to PHP In November 2018, Azure App Service will update the PHP stacks to the latest available versions. For information on the changes in the new versions, please see the change logs on the PHP website. PHP Version Change Log 5.6.38 http://www.php.net/ChangeLog-5.php#5.6.38 7.0.32 http://www.php.net/ChangeLog-7.php#7.0.32 7.1.22 http://www.php.net/ChangeLog-7.php#7.1.22 7.2.10 http://www.php.net/ChangeLog-7.php#7.2.10 ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/10/04/PHP-Minor-Version-Update-for-November-2018.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "New App Service VNet Integration feature",
+ "excerpt":" Christina Compy (MSFT) 10/17/2018 11:47:30 AM We are happy to announce a new version of the VNet Integration capability that enables access to resources across Service Endpoints or ExpressRoute connections. Like the pre-existing VNet Integration feature, this only enables your app to make calls into your VNet. It does not affect inbound traffic to your app. This feature is in Preview in all public regions. The new VNet Integration capability has the following characteristics. No gateway is required to use the new VNet Integration feature You can access resources across ExpressRoute connections without any additional configuration beyond integrating with the ExpressRoute connected VNet. The app and the VNet must be in the same region The new feature requires an unused subnet in your Resource Manager VNet. Your App Service plan must be a Standard, Premium or PremiumV2 plan The new capability is only available from newer Azure App Service scale units. The VNet Integration UI in the portal will tell you if your app can use the new VNet Integration feature. Production workloads are not supported on the new feature while it is in Preview Your app must be in an Azure App Service deployment that is capable of scaling up to Premium v2. The new VNet Integration feature does not work for apps in an App Service Environment. The new VNet Integration feature currently works just with Windows apps. One address is used for each App Service plan instance. Since subnet size cannot be changed after assignment, use a subnet that can more than cover your maximum scale size. A /27 with 32 addresses is the recommended size as that would accommodate an App Service plan that is scaled to 20 instances. You can consume Service Endpoint secured resources using the new VNet Integration capability. To do so, enable service endpoints on the subnet used for VNet Integration. To use the feature, go to the Networking UI in the portal. If your app is able to use the new feature then you will see a capability to use the new preview feature. Simply select the Resource Manager VNet that you want to integrate with and then either create a new subnet or pick an empty pre-existing subnet. Initially there are some things that will not work initially against the subnet used for VNet Integration. They include peering, network security groups, and route tables. These capabilities will be gradually enabled during the preview period. Also not initially available is the ability for your web app to pick up the VNet DNS setting. If you want your app to use your VNet DNS server then create an Application setting for your app where the name is WEBSITE_DNS_SERVER and the value is the IP address of the server. If you have a secondary DNS server then create another Application setting where the name is WEBSITE_DNS_ALT_SERVER and the value is the IP address of the server. You can read more about the feature in the documentation on Integrate an app with a VNet ","categories": ["networking"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/10/17/New-App-Service-VNet-Integration-feature.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Git Version Update Planned for November and December 2018",
+ "excerpt":" Stefan Schackow (MSFT) 11/8/2018 12:33:19 PM Starting on November 13th 2018, and running approximately through December 14th 2018, Azure App Service will be updating the version of Git deployed on the service to version 2.19.1. This is expected to be a non-breaking update. For information on the changes contained in the new version please see the Git release notes here: https://raw.githubusercontent.com/git/git/master/Documentation/RelNotes/2.19.1.txt ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/11/08/Git-Version-Update-Planned-for-November-and-December-2018.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Azure App Service on Azure Stack Update 4 Released",
+ "excerpt":" Andrew Westgarth 11/13/2018 10:25:50 AM This morning we released the fourth update to Azure App Service on Azure Stack. This release updates the resource provider and brings the following key capabilities and fixes: Resolution for CVE 2018-8600 Cross Site Scripting Vulnerability. Added support for App Service 2018-02-01 API version Updates to App Service Tenant, Admin, Functions portals and Kudu tools. Consistent with Azure Stack Portal SDK version. Updates to NodeJs, NPM, Zulu OpenJDK, Tomcat, PHP and Python All other fixes and updates are detailed in the App Service on Azure Stack Update Four Release Notes You can download the new installer and helper scripts: Installer – https://aka.ms/appsvcupdate4installer Helper Scripts – https://aka.ms/appsvconmashelpers Please read the updated documentation prior to getting started with deployment: Before you get started with App Service on Azure Stack Deploy the App Service Resource Provider for new deployments Update the App Service Resource Provider for updating existing deployments ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/11/13/Azure-App-Service-on-Azure-Stack-Update-4-Released.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "WordPress on Linux Updated",
+ "excerpt":" Yi Liao MSFT 11/30/2018 2:30:16 PM Updated image for WordPress on Linux We have recently updated the WordPress on Linux offering on Azure Marketplace. In this version we have replaced Apache/mod_php with Nginx/PHP-FPM, we've seen the improved performance in our internal testing. Customers can use the WordPress on Linux image from the Azure Marketplace to create a new WordPress site and get the latest image automatically. Upgrade WordPress on Linux If you have an existing WordPress site running on the previous version of the Marketplace template, you may upgrade to the new image following the steps below. Before you begin, we recommend you backup the database and WordPress site (details in Migrate section). Upgrade steps: In the Azure Portal, find your Web App and go to \"Container Settings\" Update the \"image:tag\" setting to 'appsvcorg/wordpress-alpine-php:0.61' Click Save and wait for the Web App to restart Migrate your site to WordPress on Linux For customers who plan to migrate their WordPress site to Azure App Service, while the Marketplace image comes with a fresh install of WordPress, customers can replace the code on the Web App and bring their own WordPress codebase (for example during migrations from on-premises or other hosting platforms). Connect to the Web App using FTPS and replace the contents of the '/home/site/wwwroot' directory. Alternatively, you can create a zip file for your codebase and deploy it to the Web App using App Service zipdeploy. Verify that 'wp-config.php' contains the correct database connection string, using the wp-config.php file from Azure Marketplace for reference. For WordPress database, you can use tools such as mysqldump or MySQL Workbench to backup the MySQL database from the original server and restore it to Azure Database for MySQL. Customization For cases in which additional customization is needed for plugins or themes, we recommend customers to modify the Docker image used in the Marketplace (source on GitHub), and run it on Web App for Containers. Once completed, migrate the site so that you don’t have to start from scratch. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2018/11/30/WordPress-on-Linux-Updated.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Python 2.7 Now Available for App Service on Linux",
+ "excerpt":" Python 2.7 has been added to the public preview of Python on Azure App Service (Linux). With this recent addition developers can enjoy the productivity benefits and easy scaling features of Azure App Service using Python 2.7, 3.6 or 3.7. More details on the public preview of Python support on Azure App Service (Linux) are available here: https://azure.microsoft.com/en-us/blog/native-python-support-on-azure-app-service-on-linux-new-public-preview/ ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2019/01/04/Python-2.7-Now-Available-for-App-Service-on-Linux.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "PHP Minor Version Update for January 2019",
+ "excerpt":" Yi Liao MSFT 1/11/2019 12:57:33 PM In the next release of Azure Web Apps, we will update the PHP stacks on Windows to the latest available versions. For information on the changes in the new versions, please see the change logs on the PHP website. PHP Version Change log 5.6.39 http://www.php.net/ChangeLog-5.php#5.6.39 7.0.33 http://www.php.net/ChangeLog-7.php#7.0.33 7.1.25 http://www.php.net/ChangeLog-7.php#7.1.25 7.2.13 http://www.php.net/ChangeLog-7.php#7.2.13 ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2019/01/11/PHP-Minor-Version-Update-for-January-2019.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "App Service Environment Support for Availability Zones (Preview)",
+ "excerpt":" App Service Environment (ASE) support for Availability Zones (AZ) is now in preview. Customers can deploy internal load balancer (ILB) ASEs into a specific AZ (Zone 1, 2 or 3) within an Azure region, and the runtime resources used by that ILB ASE will be deployed into the specified AZ. An ILB ASE is deployed in a zonal manner which means the ILB ASE is pinned to a specific zone. This means all of the following runtime ILB ASE resources will be located in the specified zone: the internal load balancer IP address of the ASE, the compute resources used by the ASE to run web applications, and the underlying file content storage for all of the web applications deployed on the ASE. Currently ILB ASEs can be deployed into AZs in the Central US region. The set of available regions for the ASE AZ preview will be expanded over the course of January and February to include all AZ enabled Azure regions. Note that only ILB ASEs support availability zones - there are no plans at this time to enable AZ support for external facing ASEs (i.e. ASEs that have a public IP address for accepting website traffic). Customers can deploy an ASE into an availability zone using ARM templates. The ARM template snippet below shows the new properties and values in bold that tell the platform to deploy the ASE into an availability zone: \"resources\": [ { \"type\": \"Microsoft.Web/hostingEnvironments\", \"kind\": \"ASEV2\", \"name\": \"yourASENameHere\", \"apiVersion\": \"2018-05-01-preview\", \"location\": \"Central US\", \"zones\": [ \"2\" ], \"properties\": { \"name\": \"yourASENameHere\", \"location\": \"Central US\", \"ipSslAddressCount\": 0, \"internalLoadBalancingMode\": \"3\", \"dnsSuffix\": \"contoso-internal.com\", \"virtualNetwork\": { \"Id\": \"/subscriptions/your-subscription-id-here/resourceGroups/your-resource-group-here/providers/Microsoft.Network/virtualNetworks/your-vnet-name-here\", \"Subnet\": \"yourSubnetNameHere\" } } } ] There are only two minor changes needed in an ILB ASE ARM template to enable zonal deployment. The apiVersion property must be set to 2018-05-01-preview in order for the zones property to be processed. The zones property can be set as shown above with a value of 1, 2 or 3 depending on which zone you want to deploy the ASE into. In order to attain zone resiliency for apps created on AZ deployed ILB ASEs, customers will need to deploy at least two ILB ASEs - one per zone. Customers should then create and publish copies of their application onto each of the AZ deployed ASEs. Customers will additionally need to deploy a load balancing solution upstream of the AZ deployed ASEs so that traffic bound for an application is distributed across all instances of the ASEs. For example a zone-redundant Application Gateway could be deployed upstream, and then configured to route requests for a given application across all of the application instances created on the AZ deployed ASEs. More details on zone-redundant Application Gateway are available here: Autoscaling and Zone-redundant Application Gateway (Public Preview). Once an ASE and its applications are running inside of a specific zone, the applications will continue to run and serve traffic on that ASE even if other zones in the same region suffer an outage. However it is possible that non-runtime behavior including application service plan scaling as well as application creation/configuration/publishing may be impacted in the event of a region outage. Future investments into availability zone support for App Service will eventually extend zone resiliency to these non-runtime behaviors. ","categories": ["networking"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2019/01/16/App-Service-Environment-Support-for-Availability-Zones-(Preview).html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "The Zend Z-Ray debugging feature will be discontinued in Azure App Service on June 7, 2019",
+ "excerpt":"The Z-Ray PHP debugging feature will soon be discontinued in App Service. This shouldn’t affect the App Service service-level agreement (SLA) or the runtime behavior of your applications. Beginning March 9, 2019, Z-Ray will no longer be available for purchase in the Azure portal. If you already have applications configured with Z-Ray, you may continue to use it until June 7, 2019. After that date, the Z-Ray feature will be removed from all applications and you’ll no longer be charged for it. Have you configured Zend Z-Ray for your app? Even though no action is required for customers that have configured Zend Z-Ray for the app, you can look for instances of Zend Z-Ray using the Azure Cloud Shell and one of the following sample scripts: Azure Powershell Get-AzResource -ResourceType Microsoft.Web/sites/premieraddons ` | Where-Object {$_.name -like '*/zray*'} ` | Select-Object Name,ResourceGroupName,ResourceType Azure CLI az resource list --query \"[?contains(name, 'zray') && type=='Microsoft.Web/sites/premieraddons'].{Name:name, RG:resourceGroup, Type:type}\" --output table Manually Removing Zend Z-Ray debugging Once you have identified Zend Z-Ray instances in your subscription you can manually delete them using the portal. Browse to the Resource Group containing the Zend Z-Ray instance. Enable the Show Hidden Types option. Select the Zend Z-Ray instance using the checkbox associated with this item. Click on Delete in the Resource Group command bar Confirm the action. Once the Zend Z-Ray resource has been manually deleted any monthly charges associated with it will also stop. If you have questions, please contact Azure Support. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2019/02/05/Important-Update-for-Zend-Z-Ray-PHP-Debugging.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "The Data Connections will be removed from Web App menu",
+ "excerpt":"Data connections provides a guided experience to easily add a connection string to a new or existing SQL Azure Database or Azure Storage Account. To simplify the user experience, the data connections feature will be removed from the Web Apps menu on April 15, 2019. The feature has a limited audience, and you can easily create connection strings manually, as we describe below. How can I add a connection string manually? Use a new or existing data source First determine whether you’ll create a data store or use an existing one. If you’re going to create a data store, use one of the following quickstarts: Quickstart: Create a storage account Quickstart: Getting started with single databases in Azure SQL Database If you are using an existing data source, then your next step is to create the connection string. Create the connection string Depending on what data store you use, the connection string will have a different format: SQL Database Connection String format Data Source=tcp:{your_SQLServer},{port};Initial Catalog={your_catalogue};User ID={your_username};Password={your_password} {your_SQLServer} Name of the server, this can be found in the overview page for your database and is usually in the form of “server_name.database.windows.net”. {port} usually 1433. {your_catalogue} Name of the database. {your_username} User name to access your database. {your_password} Password to access your database. Learn more about SQL Connection String format Azure Storage Connection String format DefaultEndpointsProtocol=https;AccountName={your_storageAccount};AccountKey={your_storageAccountKey} {your_storageAccount} Name of your Azure Storage Account {your_storageAccountKey} Keys used to access your Azure Storage Account Where can I find my Azure Storage Account Access Keys Add the connection string to your Web App In App Service, you can manage connection strings for your application by using the Configuration option in the menu. To add a connection string: Click on the Application settings tab. Click on [+] New connection string. You will need to provide Name, Value and Type for your connection string. If your are adding a connection string to a SQL Azure database choose SQLAzure under type. If your are adding a connection to an Azure Storage account, chose Custom under type. NOTE If you are adding a connection string because you are planning on using the Easy API or Easy Table features, then the connection strings used by this features expect the following specific names: Azure SQL database: MS_TableConnectionString Azure Storage account: MS_AzureStorageAccountConnectionString ","categories": [],
+ "tags": ["Azure Portal"],
+ "url": "https://azure.github.io/AppService/2019/02/26/Changes-to-data-connections-UX.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Azure App Service on Azure Stack Update 5 Released",
+ "excerpt":"This morning we released the fifth update to Azure App Service on Azure Stack. This release updates the resource provider and brings the following key capabilities and fixes: Updates to App Service Tenant, Admin, Functions portals and Kudu tools. Consistent with Azure Stack Portal SDK version. Updates to Kudu tools to resolve issues with styling and functionality for customers operating disconnected Azure Stack. Updates to core service to improve reliability and error messaging enabling easier diagnosis of common issues. All other fixes and updates are detailed in the App Service on Azure Stack Update Five Release Notes You can download the new installer and helper scripts: Installer Helper Scripts Please read the updated documentation prior to getting started with deployment: Update 5 Release Notes Before you get started with App Service on Azure Stack Deploy the App Service Resource Provider for new deployments Update the App Service Resource Provider for updating existing deployments ","categories": [],
+ "tags": ["Azure Stack"],
+ "url": "https://azure.github.io/AppService/2019/02/28/Azure-App-Service-on-Azure-Stack-Update-5-Released.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Changes to Routing Rules UX",
+ "excerpt":"We will soon be rolling out a series of UX and ARM API changes that will alter the behavior of routing rules for testing in production. After May 22nd, you will no longer be able to create routing rules in staging slots from the Portal, and on August 21st we will remove routing rules from all non-production slots. You will still be able to route traffic from your production slot to your staging slots to do testing in production. Please follow the instructions below to remove the routing rules from your staging slots. The change We originally allowed traffic routing from staging slots to enable advanced testing scenarios. However, we later learned that our customers were often routing traffic incorrectly and running into circular routing loops and other problems. Testing in production quickly gets complicated when routing rules are applied to non-production slots. On August 21st we will remove all routing rules from staging slots. Rules on your production slot will not be changed. How to remove rules on staging sites Using the Portal Until May 22nd, you can remove your staging slot rules through the Azure portal. Go to your Web App in the portal. Under Deployment Slots you can select your staging slot(s). In your staging slot, go to the Deployment Slots panel and set the traffic percentages to 0. Click Save. Using ARM Until August 21st, you can remove your staging slot rules through the Resource Explorer. On August 21st we will remove all routing rules from staging slots. Go to your staging slot in the Portal and click Resource Explorer In the panel, click Go. This should open a new tab in your browser. The navigation menu will open to your staging slot. Go to staging slot > config > web Click Edit Scroll down to the routingRules attribute and set the child reroutePercentage’s to 0 for any other slots Set the reroutePercentage to 100 for the slot current slot Scroll back up and click “Put”. ","categories": ["deployment"],
+ "tags": ["Azure Portal"],
+ "url": "https://azure.github.io/AppService/update/2019/03/18/Changes-to-Testing-in-Production-UX.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "//DevTalk - App Service Certificate - New Sync and Export experiences",
+ "excerpt":"App Service Certificates have been a very popular feature among App Service customers. However, our customers often get confused about the sync scenarios between App Service Certificates and Linked Private certificates. Specifically during the Manual Renew, Manual Rekey, and Auto Renew operations. This blog will showcase recent UX improvements to give you control over the sync scenarios. We will also talk about the internals of the automatic sync tasks running in the background to keep your certificates and SSL bindings synced up automatically. App Service Certificate Overview experience When you open the App Service Certificate UX you will see the list of Linked Private certificates that are referenced in your App Service Apps. Note the sync button top, it will be disabled if all Linked Private certificates are in-sync. If any Linked Private certificates are not synced, the sync button will be enabled as shown above. The Sync operation performs the following tasks: Updates the Linked Private certificate with the current active App Service Certificate. Updates all SSL Bindings in all apps used by the Linked Private certificate to use the new certificate. You can sync all Linked Private certificates from the main sync experience in one click. Manual Rekey and Renew experience Previously, during rekey and renew scenarios we would show the certificates references. Now we show the status of the Linked Private certificate and the difference between the thumbprints between them to give a clear view of the certificate state. We also allow you to sync the certificate with the sync command directly. This model allows you to perform a rekey or a renew and leave the UI and continue with your work in the portal. When you return to the App Service Certificate blade, you will see the out-of-sync certificates. At this point, you can either let the automatic sync task take care of it, or sync it manually using the button. Manual Renew Scenario Manual Rekey Scenario Auto Renew and Sync internals Our customers are sometimes confused by how the auto renew operation works and how it affects the Linked Private certificates. In an attempt to demystify the process, let me explain how our renew and syncs happen. As we know by now, App Service Certificate uses GoDaddy APIs to issue your SSL certificates. Once a certificate is issued, we store the certificates in the KeyVault you configured during the KeyVault configuration step. We have a AutoRenew background task that runs every 8 hours in the App Service Certificate backend to look at all the certificates that are up for renewal and renew them if you have turned on Auto Renew. Once renewed the background task updates the KeyVault with the new certificate. Meanwhile, in the App Service backend we have another task that runs every 48 hours to sync all certificates that have a KeyVault reference (you can import a certificate from KeyVault secret into a App Service Web App following this blog). The background tasks has to run through a lot of private certificates which have KeyVault references and check if they have changed and update the certificate if needed, during this sync we also need to update the SSL Bindings on all the apps that are using this private certificate to maintain a working configuration. We have put in a lot of work to make these background task run at maximum efficiency and fall back properly on error cases. So when an Auto Renew happens, the new certificate will automatically be synced when 48-hour background task picks up the certificate to sync. We are aware that 48 hours is too long for some customers and we are working on improving the timings. Until then, you can do a manual sync with the experience provided above. You can rest assured that the certificate used in your app at any point of the scenario will be valid during the auto renew process as we give a buffer of 60 days when both the newly renewed certificate and the old are valid. Looking forward to hearing more on whether the internal details shed some light on how the auto renew and sync works and if you need more details feel free to drop a comment with your ask. Export Scenario When you go to the export experience on App Service Certificate, you will see a new link to open the KeyVault Secret directly. In order to open the KeyVault secret you need to have GET permissions on the KeyVault Access Policy. Once you open the secret UI, you can navigate to the current version and download the certificate directly from the portal. The certificate will be in pfx format and may need further processing to add a password or prepare it for Linux/Mac usage. But for now, you do not need any PowerShell magic to get the pfx. Note that KeyVault secret UI does not add a password for the downloaded pfx. Once you downloaded the pfx, we advise you to install it on your Windows machine and export it with the password and delete the other occurrences to keep the pfx save (or as save as it can be now that it is out in the wild file system frontier). If you using mac or linux you will need to use openssl to secure it with a key. Use it only when you want to take the pfx out of Azure and use it somewhere else. You can also use KeyVault APIs (which can run in any platform) to directly pull the secret when you need it in your code which is much more safer than keeping a file around. Export experience - Click the “Open KeyVault Secret” KeyVault Secret UI - Click the Current version Download Pfx - Click “Download as a certificate” button Epilogue Looking forward to hearing more from you, we like to keep our //DevTalk series a quick informal blog series that bring you direct updates from us on improvements across App Service that we keep tinkering out in the service. We drive these changes based on customer feedback, support cases, user voice, internal DLs and posts like these. We look forward to feedback, asks and comments on the new improvements and old to help us develop the service you love to use 💖. ","categories": ["certsdomains"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/appservicecertificate/2019/03/19/DevTalk-App-Service-Certificate-sync-improvements-and-design.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Announcing the new change analysis experience in App Service Diagnostics",
+ "excerpt":"In a fast-paced development environment, sometimes it is difficult to keep track of all the changes made to your app… let alone pinpoint a change that caused an unhealthy behavior. Change Analysis can help you narrow down on changes made to your app to facilitate the trouble-shooting experience. Finding Change Analysis Change Analysis is embedded in App Service Diagnostics’ tiles such as Application Changes and Application Crashes so you can use it concurrently with information from other tiles. For more information on how to navigate to App Service Diagnostics, please visit Azure App Service diagnostics overview. How to enable Change Analysis Upon opening a diagnostic report, you will see a message to enable Change Analysis. You can access the Change Analysis Settings by clicking on the Enable Now button. Turn on Change Analysis and click Save to get property changes and code changes for your main web app. [Note: If you are using Change Analysis for the first time, enabling this setting will register Change Analysis Resource Provider on your subscription.] By enabling Change Analysis, your app’s Kudu will trigger a snapshot every 4 hours to capture the changes made between those time intervals. To disable Change Analysis on your web app, click on Go to Change Analysis Settings in the upper right corner of Change Analysis in the diagnostic report. [Note: Change Analysis Resource Provider is still registered on the subscription of your web app.] To unregister Change Analysis Resource Provider from your subscription, navigate to your subscription, click Resource providers in the left navigation, select Microsoft.ChangeAnalysis, and click Unregister. Navigating through the change timeline Once Change Analysis is enabled, you will see a change timeline embedded in the diagnostic reports. The change timeline is populated by changes made in the past 24 hours, represented by square boxes on the timeline. You can click on each box to filter for corresponding change(s) in the change chart below. You can also use the search bar to filter for changes that have your search term. You can also expand each row of change to view the difference between the old values and the new values. Above the timeline is the last scanned time stamp that shows the last time the timeline was updated. If you wish to find out about changes made after the last scanned time, click Scan changes now. (This process may take few minutes) After scanning is complete, you can update the timeline by clicking on View changes now. Change Analysis in Practice Now, let’s walk through a scenario where Change Analysis can be helpful. Suppose you have noticed some downtime in your app caused by a changed App Setting, but you do not know what has caused the issue. First, open a diagnostic report with Change Analysis like Application Crashes. Browse through the change timeline to see if there were any changes made before the app started crashing. If you do not find any changes on the timeline that could be related to the issue, click Scan changes now to update the timeline with the most recent changes. After the scanning completes, click View changes now to populate the timeline with the new changes. You notice there is one change that occurred right before the app started crashing. Expand the new change to view the differences. You may find that you accidentally deleted the connection string when you last made your code changes. Used in tandem with other information, Change Analysis can serve as a powerful tool for diagnosing and solving problems with your web app. Feel free to post any questions about Change Analysis on the MSDN Forum. ","categories": ["diagnostics"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2019/05/07/Announcing-the-new-change-analysis-experience-in-App-Service-Diagnostics-Analysis.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "App Service plan Density Check",
+ "excerpt":"App Service plan defines the compute resource assigned to run your App Service. The pricing tier of your App Service plan determines the compute power and features you get, the higher the tier, the more features and compute power are available. To find out which features are supported in each pricing tier, see App Service plan details. When you deploy multiple App Services in the same App Service plan, they all share the underlying compute resources. If your App Service plan has more than the recommended number of apps, the apps will compete for the same set of resources. This will cause high CPU & memory that could result in availability and performance issues. How to verify the App Service plan density In order to verify if your apps are possibly competing for resources, run the App Service plan Density check detector by following these steps: 1) From the Azure Portal, go to on of your Apps 2) Go to the “Diagnose and solve problems” blade 3) Then either select the ‘Risk Assessments’ category or you can search for “Best Practices for Availability & Performance” in the search bar You will see one of the following: 1) Your plan is within the recommended value 2) Your plan is nearing exhaustion Recommended Solutions 1) Stop apps to decrease load In the description, the detector will recommend stopping a number of apps to be within the recommended number of apps on the respective pricing tier. The number may actually be lower depending on how resource intensive the hosted applications are, however as a general guidance, you may refer to the table below. App Service Plan SKU Max Apps B1, S1, P1v2, I1v1 8 B2, S2, P2v2, I2v1 16 B3, S3, P3v2, I3v1 32 P1v3, I1v2 16 P2v3, I2v2 32 P3v3, I3v2 64 Note : An active slot is also classified as an active app as it too is competing for resources on the same App Service Plan. 2) Scale up your App Service plan If your App Service plan is on a Small/Medium tier, scaling up the plan will move the apps to a higher compute power with better CPU and memory. If you are not running on a Pv2 plan, Pv2 features Dv2-series VMs with faster processors, SSD storage, and double memory-to-core ratio compared to Standard. 3) Split Apps in multiple App Service plans If you have other App Service plans that have been created in the same Resource Group and Region, you can move your app to one of those plans and decrease the load. Alternatively, you can follow these steps to create an App Service plan that will be able to move your app to: a) Create a new App Service Plan in the same resource group and location b) Select a pricing tier that fits the performance and feature needs for your application. c) Navigate to the application in the Azure Portal whose app service plan you want to change. d) Select the “Change App Service Plan” tab from the left sidebar menu. e) Choose the newly created App Service Plan (created in Step 2). Feel free to post any questions about App Service plan density check on the MSDN Forum. ","categories": ["diagnostics"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2019/05/21/App-Service-Plan-Density-Check.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Azure App Service on Azure Stack Update 6 Released",
+ "excerpt":"This afternoon we released the sixth update to Azure App Service on Azure Stack. This release updates the resource provider and brings the following key capabilities and fixes: Updates to App Service Tenant, Admin, Functions portals and Kudu tools. Consistent with Azure Stack Portal SDK version. Updates to Kudu tools to resolve issues with styling and functionality for customers operating disconnected Azure Stack. Updates to core service to improve reliability and error messaging enabling easier diagnosis of common issues. All other fixes and updates are detailed in the App Service on Azure Stack Update Six Release Notes The App Service on Azure Stack Update 6 build number is 82.0.1.50 You can download the new installer and helper scripts: Installer Helper Scripts Please read the updated documentation prior to getting started with deployment: Update 5 Release Notes Before you get started with App Service on Azure Stack Deploy the App Service Resource Provider for new deployments Update the App Service Resource Provider for updating existing deployments ","categories": [],
+ "tags": ["Azure Stack"],
+ "url": "https://azure.github.io/AppService/2019/05/28/App-Service-on-Azure-Stack-Update-6-Released.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "PHP Minor Version Update for August 2019",
+ "excerpt":"Latest version updates to PHP In August 2019, Azure App Service will update the PHP stacks to the latest available versions. For information on the changes in the new versions, please see the change logs on the PHP website. PHP Version Change Log 5.6.401 http://www.php.net/ChangeLog-5.php#5.6.40 + security fixes from https://github.com/microsoft/php-src/commits/PHP-5.6-security-backports 7.0.331 http://www.php.net/ChangeLog-7.php#7.0.33 + security fixes from https://github.com/microsoft/php-src/commits/PHP-7.0-security-backports 7.1.30 http://www.php.net/ChangeLog-7.php#7.1.30 7.2.20 http://www.php.net/ChangeLog-7.php#7.2.20 7.3.6 http://www.php.net/ChangeLog-7.php#7.3.6 Feel free to post any questions about PHP Minor Version Update for August 2019 on the MSDN Forum. 1 - Both PHP v5.6 and v7.0 are past End-Of-Life, and are no longer receiving security updates from the community. However, to ensure our customers have the most secure PHP builds available, we have arranged to have relevant security fixes from supported versions of PHP backported to PHP v5.6 and v7.0. Edit: Due to an issue with the Zend Opcache extension in PHP 7.2.19, we will move to 7.2.20 for this update. ","categories": [],
+ "tags": ["PHP"],
+ "url": "https://azure.github.io/AppService/2019/06/18/PHP-Minor-Version-Update-for-August-2019.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "PHP Minor Version Update for July 2019",
+ "excerpt":"Latest version updates to PHP In July 2019, Azure App Service will update the PHP stacks to the latest available versions. For information on the changes in the new versions, please see the change logs on the PHP website. PHP Version Change Log 7.1.28 http://www.php.net/ChangeLog-7.php#7.1.28 7.2.17 http://www.php.net/ChangeLog-7.php#7.2.17 7.3.4 http://www.php.net/ChangeLog-7.php#7.3.4 Feel free to post any questions about PHP Minor Version Update for July 2019 on the MSDN Forum. ","categories": [],
+ "tags": ["PHP"],
+ "url": "https://azure.github.io/AppService/2019/07/17/PHP-Minor-Version-Update-for-July-2019.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Removing Easy Tables and Easy APIs from Azure App Service",
+ "excerpt":" Integrating mobile services in your application? Sign up with App Center Visual Studio App Center is the next generation solution for mobile application developers. It offers integrated end-to-end services central to mobile development. If you are integrating Microsoft cloud services in your mobile application, sign up with App Center today. Removing Easy Tables and Easy APIs from Azure App Service Azure App Service provides specific features for Node developers to easily get started with mobile backend services by leveraging Easy Tables and Easy APIs in the Azure portal. Easy Tables provides a portal experience for Node developers to create and manage their tables, their schema, and appropriate permissions. Easy APIs lets developers build and consume custom APIs in the backend. Easy Tables and Easy APIs, along with the Mobile menu in the Azure portal will be removed on November 11, 2019 as these features have a limited audience and the existing functionality can be leveraged in alternate ways. Developers that have mobile apps with a Node.js backend can leverage the existing functionality from Easy API and Easy Tables by following the guidance below. Easy API Existing API Your existing APIs will continue to work as the backend is already deployed on App Services. Create a new API or make changes to existing API You can either make changes right in the Azure portal or modify the code locally in your development environment and then publish to Azure. Click on the App Service Editor (Preview) under Development Tools menu which provides an in-browser editing experience for your app code. Click on Go and once the App Service Editor opens, you have full control over the source code. Assuming you have already installed express and azure-mobile-apps package with npm install command, click on the api folder under WWWROOT to create or edit custom API. Make your changes to the code file and the changes are saved automatically. Easy Tables You have full control on the Azure SQL Database used to store the application data. Your existing tables will continue to work without any required changes. For the existing portal features, below are the alternatives: Add from CSV Follow the documentation link in order to load data from CSV into Azure SQL Database. Add Table The “+ Add” button lets you add tables to the database. There are four options for creating new tables in the database. Use SQL Server. This tutorial explains how to create tables in your database. From the SQL database in Azure portal, you can run the following query to add a table named TodoItems from Query editor (preview) CREATE TABLE TodoItems ( id NVARCHAR(36) PRIMARY KEY, createdAt DATETIMEOFFSET NOT NULL, updatedAt DATETIMEOFFSET, version TIMESTAMP NOT NULL, deleted BIT NOT NULL, complete BIT NOT NULL, text NVARCHAR(256) ); In App Service Editor or locally, click on wwwroot/tables directly to create new files, {tablename}.js and {tablename}.json where {tablename} refers to the name of the table you created in Step 1. Sample code can be found at todoitem.js and todoitem.json. Edit the files locally and deploy the changes to Azure App Service. Change permission In order to change access permissions on tables, you can either use the portal to change the code or modify it locally in your development environment. Click on the App Service Editor (Preview) under Development Tools menu which provides an in-browser editing experience for your app code. Assuming you have already installed express and azure-mobile-apps package with npm install command, click on “Go” to open the App Service Editor. Once open, click on the tables folder under WWWROOT and open the json file for the table that you want the permissions to change. This will let you modify the access permissions for insert, update, delete, read and undelete operations for that table. You can also do this locally in the app code and deploy back to App Services. Edit script You can edit your table script by either using the App Service Editor or modifying the code locally and deploying it back to App Services. Delete table Since you own your SQL database, you can delete the table by executing a SQL query against the database. Clear table Since you own your SQL database, you can clear contents of the table by executing a SQL query against the database. Streaming logs You can use Log stream under the Monitoring menu to stream your application and Web Server logs. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2019/07/25/Removing-Easy-Tables-and-Easy-APIs-from-Azure-App-Services.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Azure Key Vault References with Spring Apps",
+ "excerpt":"Azure Key Vault provides a centralized service for managing secrets and certificates with full control over access policies and auditing capabilities. This article will show how to wire up a Spring Boot application on App Service to read a database username, password, and URL from Key Vault. Using Key Vault references requires no code changes, but we will need to do some configuration acrobatics. See the previous article for instructions on setting up the Postgres server and deploying the starter app to App Service. Set up a Managed Identity A managed identity acts as a user in your Active Directory for automation purposes. It is inherently tied to your web app and will be deleted if the web app is deleted. For this scenario, the identity will be used to retrieve the secrets from Key Vault when the app starts. Run the following command to create a manged identity: az webapp identity assign --name <app_from_last_article> --resource-group <resource_group_of_app> In the console output, save the principalId for later. Provision the Key Vault Let’s spin up a Key Vault named java-app-key-vault. For information about the parameters specified below, run az keyvault create --help. az keyvault create --name java-app-key-vault \\ --resource-group <your_resource_group> \\ --location <location> \\ --enabled-for-deployment true \\ --enabled-for-disk-encryption true \\ --enabled-for-template-deployment true \\ --sku standard Now we will grant the managed identity get and list access to the Key Vault. az keyvault set-policy --name java-app-key-vault \\ --secret-permission get list \\ --object-id <the principal ID from earlier> Finally, we will add the Postgres username, password, and URL to the Key Vault. If you followed the tutorial on data sources, you should still have the secrets saved as environment variables on your machine. (If you are using Powershell, use the $env:ENV_VAR syntax to inject the environment variables into the following command). az keyvault secret set --name POSTGRES-USERNAME \\ --value $POSTGRES_USERNAME \\ --vault-name java-app-key-vault az keyvault secret set --name POSTGRES-PASSWORD \\ --value $POSTGRES_PASSWORD \\ --vault-name java-app-key-vault az keyvault secret set --name POSTGRES-URL \\ --value $POSTGRES_URL \\ --vault-name java-app-key-vault Configuring our App The following instructions assume you have completed the previous tutorial. Key Vault References When our Spring app is running on App Service, the secrets will be exposed as environment variables or “Application Settings”. We will now create these app settings using the Azure CLI. First, we need the URI’s of our three secrets. Run the commands below and copy the id value in the console output. az keyvault secret show --vault-name java-app-key-vault --name POSTGRES-URL az keyvault secret show --vault-name java-app-key-vault --name POSTGRES-USERNAME az keyvault secret show --vault-name java-app-key-vault --name POSTGRES-PASSWORD Now we will create the app settings with the Key Vault references. For each setting, replace “YOUR_SECRET_URI” with the corresponding id’s from the previous step. az webapp config appsettings set -n <your_app_name> -g <resource_group> --settings \\ SPRING_DATASOURCE_URL=@Microsoft.KeyVault(SecretUri=YOUR_SECRET_URI)\\ SPRING_DATASOURCE_USERNAME=@Microsoft.KeyVault(SecretUri=YOUR_SECRET_URI)\\ SPRING_DATASOURCE_PASSWORD=@Microsoft.KeyVault(SecretUri=YOUR_SECRET_URI) A Key Vault reference is of the form @Microsoft.KeyVault(SecretUri=<SecretURI>), where <SecretURI> is data-plane URI of a secret in Key Vault, including a version. There is an alternate syntax documented here. Environment Configuration The Key Vault references will be replaced with the actual secrets when our App Service boots up. This means our Spring application needs to resolve the connection strings at runtime. (It currently resolves these strings at build time.) We also want to be able to use our H2 database for development, and optionally connect to the production DB from our local machine to run tests. To fill all these requirements, we will create two new configuration files: application-dev.properties, and application-prod.properties. Create a file under src/main/resources named application-dev.properties. Copy/paste the following into the file: # =============================== # = DATA SOURCE # =============================== # Set here configurations for the database connection spring.datasource.url=jdbc:h2:mem:testdb spring.datasource.username=sa spring.datasource.password= spring.datasource.driver-class-name=org.h2.Driver # =============================== # = JPA / HIBERNATE # =============================== # Allows Hibernate to generate SQL optimized for a particular DBMS spring.jpa.properties.hibernate.dialect=org.hibernate.dialect.H2Dialect # App Service server.port=8080 Create a file under src/main/resources named application-dev.properties. Copy/paste the following into the file. Notice that we do not set the connection strings here. Instead, Spring will resolve them at runtime by looking for the uppercase and underscored versions of spring.datasource.url, spring.datasource.username, and spring.datasource.password. # =============================== # = DATA SOURCE # =============================== # The connection URL, username, and password will be sourced from environment variables # on App Service # Set here configurations for the database connection spring.datasource.driver-class-name=org.postgresql.Driver # =============================== # = JPA / HIBERNATE # =============================== # Allows Hibernate to generate SQL optimized for a particular DBMS spring.jpa.properties.hibernate.dialect=org.hibernate.dialect.PostgreSQLDialect # App Service server.port=80 Now we can slim-down our original application.properties file. Replace the contents of application.properties with the following: # Active profile is set by Maven spring.profiles.active=@spring.profiles.active@ # =============================== # = DATA SOURCE # =============================== # Keep the connection alive if idle for a long time (needed in production) spring.datasource.testWhileIdle=true spring.datasource.validationQuery=SELECT 1 # =============================== # = JPA / HIBERNATE # =============================== # Show or not log for each sql query spring.jpa.show-sql=true # Hibernate ddl auto (create, create-drop, update): with \"create-drop\" the database # schema will be automatically created afresh for every start of application spring.jpa.hibernate.ddl-auto=create # Naming strategy spring.jpa.hibernate.naming.implicit-strategy=org.hibernate.boot.model.naming.ImplicitNamingStrategyLegacyHbmImpl spring.jpa.hibernate.naming.physical-strategy=org.springframework.boot.orm.jpa.hibernate.SpringPhysicalNamingStrategy Finally, we can also slim down our Maven profiles because we have moved th information to the new properties files. The profile section of your pom.xml should now be the following: <profiles> <profile> <!-- This profile will configure Spring to use an in-memory database for local development and testing. --> <id>dev</id> <activation> <activeByDefault>true</activeByDefault> </activation> <properties> <spring.profiles.active>dev</spring.profiles.active> </properties> </profile> <profile> <!-- This profile will configure the application to use our Azure PostgreSQL server. --> <id>prod</id> <properties> <spring.profiles.active>prod</spring.profiles.active> </properties> </profile> </profiles> See this article for more information on Spring configurations and precedence. Deploy and Test Check that the development profile works as expected by running the following commands and opening a browser to http://localhost:8080/. mvn clean package -Pdev java -jar target/app.jar Before deploying to App Service, build your application with the production profile and test against your PostgreSQL DB from your local machine. To do so, rename the three environment variables beginning with POSTGRES_ to SPRING_DATASOURCE_URL, SPRING_DATASOURCE_USERNAME, and SPRING_DATASOURCE_PASSWORD respectively. Run the following commands to build and start your app. Thanks to our new configuration, Spring will resolve the connection strings in the environment variables at runtime. mvn clean package -Pprod java -jar target/app.jar Finally, deploy the production app to App Service with mvn azure-webapp:deploy. Browse to the application and test that it works properly. Next Steps See the Java Developer Guide for more documentation and best practices for Java on App Service. Check back in the future for more articles. Thanks for reading! ","categories": ["java"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2019/07/30/Key-Vault-References-with-Spring-Apps.html",
+ "teaser":"https://azure.github.io/AppService/media/2019/07/locks-header.jpg"},{
+ "title": "Get visibility into your app's dependencies with Navigator",
+ "excerpt":"Application downtime can be dreadful, especially when the app is handling mission-critical load. There could be countless causes for your app’s downtime ranging from the app’s code to the misconfiguration of its dependencies. Fast troubleshooting is the key to minimizing the production impact. However, the complex nature of today’s applications makes narrowing down the cause a lengthy and difficult process. Sometimes it requires thorough investigation of changes made to each dependent resource. We are excited to announce Navigator, a new feature offering for Windows apps in App Service Diagnostics, an intelligent and guided experience that helps you troubleshoot your web app with little to no configuration. Navigator is a new diagnostic feature that provides a centralized view of a web app and its dependencies as well as the changes made to those dependencies. The feature can automatically render dependencies in the same subscription as a dependency map and display the changes made to each resource, leveraging Change Analysis. With the new experience, you can easily identify the dependencies of your web app and explore the changes as part of your troubleshooting experience. Paired with information from existing diagnostics information in App Service Diagnostics, Navigator can supplement your troubleshooting experience by providing a timeline of the changes made by your web app and its dependencies. Correlating this information with other information offered in App Service Diagnostics can help you further understand the changes and narrow down on potential causes for unhealthy behavior. Finding Navigator Navigator can be accessed through App Service Diagnostics’ homepage tile called Navigator so you can use it concurrently with information from other tiles. For more information on how to navigate to App Service Diagnostics, please visit Azure App Service diagnostics overview. How to enable Change Analysis Upon opening the tool, you will see a message to enable Change Analysis. You can access the Change Analysis Settings by clicking on the Enable Now button. Turn on Change Analysis and click Save to get property changes and code changes for your main web app as well as property changes for your dependent resources. [Note: If you are using Change Analysis for the first time, enabling this setting will register Change Analysis Resource Provider on your subscription.] By enabling Change Analysis, your app’s Kudu will trigger a snapshot every 4 hours to capture the changes made between those time intervals. To disable Change Analysis on your web app, click on Go to Change Analysis Settings in the upper right corner of Navigator view. [Note: Change Analysis Resource Provider is still registered on the subscription of your web app.] To unregister Change Analysis Resource Provider from your subscription, navigate to your subscription, click Resource providers in the left navigation, select Microsoft.ChangeAnalysis, and click Unregister. Navigating through the change timeline Once Change Analysis is enabled, you will see a dependency map of your web app and its dependencies in the same subscription. You can check the inner workings of your app using this view. Also, if you click on a resource supported by Change Analysis, you can view the recent changes made to the selected resource. See Change Analysis service to view the list of dependencies supported by Change Analysis service. Once you click on each resource on the map, you will see a timeline with square boxes and a list of changes detected over the last 24 hours. These square boxes represent change(s) made during the 24 hours. You can click on each box to filter for corresponding change(s) in the list of changes below. You can also use the search bar to filter for changes that have your search term. You can also expand each row of change to view the difference between the old values and the new values. Above the timeline is the last scanned time stamp that shows the last time the timeline was updated. If you wish to find out about changes made after the last scanned time, click Scan changes now. (This process may take few minutes) After scanning is complete, you can update the timeline by clicking on View changes now. Navigator in Practice Now, let’s explore a scenario where Navigator can come in handy. Suppose you have noticed a spike in the database connection errors in your app caused by a firewall rule, but you do not know what has caused the issue. First, click on Navigator in App Service Diagnostics. Take a look at the dependency map. Select a resource to explore the changes made to the resource. Browse through the timeline to see if there were any changes made before you observed unexpected behavior. If you do not find any changes on the timeline that could be related to the issue, click Scan changes now to update the timeline with the most recent changes. After the scanning completes, click View changes now to populate the timeline with the new changes. You notice there is one change that occurred right before the app started giving you database connection errors. Expand the new change to view the differences. You may find that you accidentally changed the firewall rules. Used in tandem with other information from App Service Diagnostics, Navigator can serve as a powerful tool for diagnosing and solving problems with your web app. Feel free to share your feedback or questions about Navigator by emailing diagnostics@microsoft.com ","categories": ["diagnostics"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2019/08/06/Bring-visibility-to-your-app-and-its-dependencies-with-Navigator.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Restore App Service domains within 30 days",
+ "excerpt":"If you deleted your App Service Domain resource within the past 30 days, you can easily restore it by purchasing it again with the same Domain Registration Subscription and resource group. Unlike trying to purchase the domain name from other subscriptions or resource groups, the validation will allow you to purchase the same domain name. Clarifications App Service Domains are domains that were purchased from Azure App Service. Domains added to App Service websites are custom domains. These are different resources. If your App Service Domain was deleted because you deleted the domain registration subscription, we do not support restoring the domain in any circumstance. ","categories": ["certsdomains"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2019/08/06/How-to-restore-soft-delete-App-Service-domains.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Announcing GitHub Actions for App Service",
+ "excerpt":"Last week GitHub announced the preview of GitHub Actions with built-in CI/CD; watch the announcement here. These actions, defined in YAML files, allow you to trigger an automated workflow process on any GitHub event. Today the App Service team is happy to share our own action, allowing you to deploy to App Service following a push or pull request. With the App Service Action, you can deploy your code to any of our managed language stacks. Simply specify your source code folder, zip file, JAR or WAR. If you prefer to deploy a Docker container instead, there’s an action for that! Getting Started GitHub Actions are currently in Beta. Request access here. Configure the repository Open the Azure Portal and navigate to your web app. In the toolbar, select Get publish profile. This will trigger a download. Open the downloaded file and copy the contents Open GitHub and navigate to your repository Select Settings > Secrets. On the Secrets page, select Add a new secret and paste your publish profile XML. Now you’re ready to create the workflow file. Create the action If you do not have any workflows defined, select the Actions tab and follow the prompts to create a new workflow. This will create a new directory an file in the root of your repository, /.github/workflows/workflow.yml. In the editor for workflow.yml, define the build steps for your application. For example, a Node application is typically built using npm install followed by npm run build. Below is an example workflow file that installs the dependencies, builds the project, and runs tests on the latest Ubuntu version. on: push jobs: build: runs-on: ubuntu-latest steps: # This checks out the repository so your workflow operates from root of repository - uses: actions/checkout@master # Install dependencies, build, and test - name: npm install, build, and test # Name is optional run: | npm install npm run build --if-present npm run test --if-present See the examples at the end of this article for specific language examples. Add the App Service Action After your build action, add the App Service action with uses: azure/appservice-actions/webapp@master. This action has the following required arguments. These should be listed under a with: key: app-name: Your application name package: The path to the deployment file or folder (relative from the root) publish-profile: The publish profile that you pasted into the GitHub Secrets earlier # Deploy to App Service - name: 'Run Azure webapp deploy action using publish profile credentials' uses: azure/webapps-deploy@v1 with: app-name: node-rn # Replace with your app name publish-profile: ${{ secrets.azureWebAppPublishProfile }} # Replace with the name of your publish profile package: <path to artifact> # Specify the folder or file to deploy Deploy to a slot The App Service Action deploys to the production slot by default. To deploy to a staging slot, redo the publish profile steps with the publish profile from your desired staging slot. Other Azure Actions In addition to this action, there are actions for other common Azure scenarios such as deploying to Azure Kubernetes Service, logging into Azure with a service principal, or signing into Docker. See the links below. Examples Containers To deploy a container, you will need to create an Azure Service Principal via the Azure CLI, then paste the details of the principal as a GitHub Secret. Install the Azure CLI Run the following command, replacing {subscription} and {resource-group} with the subscription and resource group of your application az ad sp create-for-rbac --name \"myServicePrincipal\" --role contributor \\ --scopes /subscriptions/{subscription}/resourceGroups/{resource-group} \\ --sdk-auth Open GitHub and navigate to your repository Select Settings > Secrets. On the Secrets page, select Add a new secret and paste the JSON output from the earlier az ad sp command. Finally, add your Docker username and password as GitHub Secrets Here is a full example: on: push jobs: deploy-container: runs-on: ubuntu-latest steps: - uses: actions/checkout@master # Unlike code deployment, you will authenticate using a Service Principal - uses: azure/actions/login@master with: creds: ${{ secrets.AZURE_SP }} # These creds are used to push your new image - uses: azure/container-actions/docker-login@master with: username: ${{ secrets.DOCKER_USERNAME }} password: ${{ secrets.DOCKER_PASSWORD }} #loginServer: '<login server>' # default: index.docker.io # Tag the image with the git commit hash - run: | docker build . -t contoso/demo:${{ github.sha }} docker push contoso/demo:${{ github.sha }} - uses: azure/appservice-actions/webapp-container@master with: app-name: '<your app name>' images: 'contoso/demo:${{ github.sha }}' #configuration-file: 'Optional path to a docker compose file' #container-command: 'Optional startup command for the app (dotnet run, java -jar app.jar)' Java When deploying Java apps, make sure you specify the package name relative from the root directory. Most likely, your deployment artifact will be in the target/ directory. on: push jobs: java-build-and-deploy: runs-on: ubuntu-latest steps: - uses: actions/checkout@master - name: Set up JDK 1.8 uses: actions/setup-java@v1 with: java-version: 1.8 # install dependencies, build, and test - name: Maven build phase run: | mvn clean package - uses: azure/webapps-deploy@v1 with: app-name: <your-app-name> publish-profile: ${{ secrets.<publish-profile> }} package: target/app.war # Can also be a jar Node on: push jobs: build-and-deploy: runs-on: ubuntu-latest steps: - uses: actions/checkout@master - name: Set Node.js version uses: actions/setup-node@v1 with: node-version: '10.x' # install dependencies, build, and test - name: npm install, build, and test run: | npm install npm run build --if-present npm run test --if-present - uses: azure/webapps-deploy@v1 with: app-name: <your-app-name> publish-profile: ${{ secrets.<publish-profile> }} package: '.' Python on: push jobs: build-and-deploy: runs-on: ubuntu-latest steps: - uses: actions/checkout@master - uses: actions/setup-python@v1 with: python-version: '3.7.4' - name: install dependencies, and zip the app to use ZipDeploy run: | pip install -r requirements.txt - uses: azure/appservice-actions/webapp@master with: app-name: <your-app-name> publish-profile: ${{ secrets.<publish-profile> }} DotNet on: push jobs: build-and-deploy: runs-on: ubuntu-latest steps: - uses: actions/checkout@master - name: Setup .NET Core uses: actions/setup-dotnet@v1 with: dotnet-version: 2.2.108 - name: Build with dotnet run: dotnet build --configuration Release - name: dotnet publish run: | dotnet publish -c Release -o myapp - uses: azure/webapps-deploy@v1 with: app-name: <your-app-name> publish-profile: ${{ secrets.<publish-profile> }} package: './myapp' Helpful Resources Actions for Containers App Service Action source code Checkout Action Other Azure Actions ","categories": ["deployment"],
+ "tags": ["devops"],
+ "url": "https://azure.github.io/AppService/2019/08/10/Github-actions-for-webapps.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Azure App Service on Azure Stack Update 7 Released",
+ "excerpt":"This afternoon we released the seventh update to Azure App Service on Azure Stack. This release updates the resource provider and brings the following key capabilities and fixes: Updates to App Service Tenant, Admin, Functions portals and Kudu tools. Consistent with Azure Stack Portal SDK version. Updates to core service to improve reliability and error messaging enabling easier diagnosis of common issues. Access Restrictions now enabled in User Portal As of this release Users can configure Access Restrictions for their Web/Api/Functions applications according to the documentation published - Azure App Service Access Restrictions, NOTE: Azure App Service on Azure Stack does not support Service Endpoints. All other fixes and updates are detailed in the App Service on Azure Stack Update Seven Release Notes The App Service on Azure Stack Update 7 build number is 84.0.2.10 You can download the new installer and helper scripts: Installer Helper Scripts Please read the updated documentation prior to getting started with deployment: Update 7 Release Notes Before you get started with App Service on Azure Stack Deploy the App Service Resource Provider for new deployments Update the App Service Resource Provider for updating existing deployments ","categories": [],
+ "tags": ["Azure Stack"],
+ "url": "https://azure.github.io/AppService/2019/08/29/App-Service-on-Azure-Stack-Update-7-Released.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "PHP Minor Version Update for September 2019",
+ "excerpt":"Latest version updates to PHP In September 2019, Azure App Service will update the PHP stacks to the latest available versions. For information on the changes in the new versions, please see the change logs on the PHP website. PHP Version Change Log 5.6.401 http://www.php.net/ChangeLog-5.php#5.6.40 + security fixes from https://github.com/microsoft/php-src/commits/PHP-5.6-security-backports 7.0.331 http://www.php.net/ChangeLog-7.php#7.0.33 + security fixes from https://github.com/microsoft/php-src/commits/PHP-7.0-security-backports 7.1.32 http://www.php.net/ChangeLog-7.php#7.1.32 7.2.22 http://www.php.net/ChangeLog-7.php#7.2.22 7.3.9 http://www.php.net/ChangeLog-7.php#7.3.9 1 - Both PHP v5.6 and v7.0 are past End-Of-Life, and are no longer receiving security updates from the community. However, to ensure our customers have the most secure PHP builds available, we have arranged to have relevant security fixes from supported versions of PHP backported to PHP v5.6 and v7.0. ","categories": [],
+ "tags": ["PHP"],
+ "url": "https://azure.github.io/AppService/2019/09/04/PHP-Minor-Version-Update-for-September-2019.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Use ARM templates to swap deployment slots",
+ "excerpt":"A version of this article appeared on ruslany.net Azure Resource Manager (ARM) templates are used to automate deployment and configuration of Azure resources. With the templates you can define the infrastructure to be deployed via a JSON file and then use that file to repeatedly deploy new resources or update existing ones. ARM templates are widely used to release new versions of the Azure web apps and function apps. During a release the new version of an app is deployed to a staging slot and then it is swapped into production. This blog post explains how to automate the App Service deployment slot swap operation with an ARM template. Let’s assume you have a web app with production and staging deployment slots. When you release a new version of that web app you first would deploy it to the staging slot and then swap it into production slot. To define the swap operation via ARM template you’ll need to use two properties on the “Microsoft.Web/sites” and “Microsoft.Web/sites/slots” resources: buildVersion – this is a string property which can be set to any arbitrary value that would represent the current version of the app deployed in the slot. For example: “v1“, “1.0.0.1“, “2019-09-20T11:53:25.2887393-07:00“. targetBuildVersion – this is a string property that is used to specify what version of the app the current slot should have. If the targetBuildVersion is different from the buildVersion then this will trigger the swap operation by finding a slot that has the expected build version and then swapping the site from that slot into the current slot. With that the process of deploying a new version of an app can be done as follows: Deploy a new version of an app into a staging slot Execute ARM template to update the buildVersion of the app in staging slot Execute ARM template to set the targetBuildVersion on the production slot Here is an example ARM template that demonstrates how to perform steps #2 and #3: { \"$schema\": \"https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#\", \"contentVersion\": \"1.0.0.0\", \"parameters\": { \"sites_SwapAPIDemo_name\": { \"defaultValue\": \"SwapAPIDemo\", \"type\": \"String\" }, \"sites_buildVersion\": { \"defaultValue\": \"v1\", \"type\": \"String\" } }, \"resources\": [ { \"type\": \"Microsoft.Web/sites/slots\", \"apiVersion\": \"2018-02-01\", \"name\": \"[concat(parameters('sites_SwapAPIDemo_name'), '/staging')]\", \"location\": \"East US\", \"kind\": \"app\", \"properties\": { \"buildVersion\": \"[parameters('sites_buildVersion')]\" } }, { \"type\": \"Microsoft.Web/sites\", \"apiVersion\": \"2018-02-01\", \"name\": \"[parameters('sites_SwapAPIDemo_name')]\", \"location\": \"East US\", \"kind\": \"app\", \"dependsOn\": [ \"[resourceId('Microsoft.Web/sites/slots', parameters('sites_SwapAPIDemo_name'), 'staging')]\" ], \"properties\": { \"targetBuildVersion\": \"[parameters('sites_buildVersion')]\" } } ] } This ARM template is idempotent, meaning that it can be executed repeatedly and produce the same state of the slots. In other words if you re-run the same template with the same parameters after the swap has been performed and targetBuildVersion on production slot matches the buildVersion then it will not trigger another swap. Helpful links Documentation for swapping slots with ARM templates App Service quickstarts How to get started with slots ","categories": ["deployment"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2019/10/02/Swap-slots-with-arm-templates.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Mitigate your CPU problems before they happen",
+ "excerpt":" Currently offered in App Service Diagnostics for Windows web apps. Imagine there is a CPU spike in your cloud application at 2:00 in the morning, would you like to be woken up to mitigate and troubleshoot the issue or would you rather have the issue mitigated automatically and troubleshoot after a good night’s sleep? For those of us that enjoy a good night’s sleep, Proactive CPU monitoring is an easy, proactive way to take an action when your app or its child process is consuming too much CPU. You can configure CPU rules to temporarily mitigate a high CPU issue until the real cause for the unexpected issue is found. Finding Proactive CPU Monitoring To access Proactive CPU Monitoring, browse to your App Service web app in Azure portal and click Diagnose and solve problems in the left navigation panel. Then, click on the homepage tile named Diagnostic Tools. Once you are inside Diagnostic Tools, click Proactive CPU Monitoring. Configuring Proactive CPU Monitoring Proactive CPU monitoring operates based on 5 conditions and 4 modes of action by checking w3wp.exe process of the site or any child processes. Conditions There are five conditions you can configure to tailor to your needs. CPU Threshold: the CPU threshold at which the rule will be triggered Threshold Seconds: the duration of the CPU exceeding the CPU threshold. The rule will be triggered at the end of the duration. Monitor Frequency: defines how often the condition will be evaluated Maximum Actions: the maximum number of memory dumps that the rule collects, ensuring no dumps are collected beyond the set amount Maximum Duration: the maximum duration of the rule until it becomes deactivated Actions Once the conditions are met, your selected action is triggered. Proactive CPU Monitoring offers 4 different modes listed below. Collect: In this mode, a memory dump is collected whenever any process consumes CPU greater than the CPU Threshold for longer than the allowed Threshold Seconds. (Monitor Duration should always be lower than Threshold Seconds) Memory dump is collected via ProcDump.exe, and the number of dumps (or actions) are controlled by Maximum Actions. Once Maximum Duration is met, the rule becomes deactivated. When the memory dump is collected, the process is frozen until the dump generation completes. The time the process is frozen depends directly on the memory consumed by the process. The size of the dump generated is also directly proportional to the memory consumed by the process. Kill: In this mode, the process is killed when the condition is met. The Maximum Actions is not honored and monitoring stops automatically after Maximum Duration. Kill is a forceful termination of the process and not a graceful exit. All requests that the current worker process is processing will be terminated, and end users may see 502 errors. If system terminates the child process, the error message may even be 500 or some form of application exception based on the stack. Collect and Kill: In this mode, a memory dump is collected and the process consuming high CPU is killed when the site’s process (or child process) consumes CPU greater than CPU threshold for more than Threshold Seconds. No analysis is performed but after the session finishes, you have an option to analyze the memory dump after the session ends by clicking the Analyze button. Collect, Kill, and Analyze: In this mode, a memory dump is collected and the process consuming high CPU is killed when a site’s process (or child process) consumes CPU greater than the CPU threshold for longer than the allowed Threshold Seconds. In addition, CPU dumps are analyzed by DumpAnalyzer tool, and an analysis report is generated. Analyzing a dump with this tool has some CPU impact on the instance and takes roughly 5-7 minutes at minimum to analyze one dump file. Analysis can take longer if the dump size is larger and depending upon what is captured in the dump. To prevent CPU overhead, only one dump is analyzed by the instance at a time. For example, if there are 10 instances and say the monitoring collected 5 dumps, all instances in parallel can analyze memory dumps. If there is 1 instance and 5 dumps are collected, the dump analysis will happen one after the other. Watch a Demo Watch this video to learn more about the feature and analyzing the dumps and memory analysis report generated by this tool. What’s Next Once you set the rule that best suits your app’s need, you can get ahead of your CPU issues, automatically mitigate CPU spikes, and save yourself from a dreadful 2:00am call. Feel free to share your feedback or questions about Proactive CPU Monitoring by emailing diagnostics@microsoft.com or posting on UserVoice with “[Diag]” in the title. For more information on other diagnostic tools, please visit Azure App Service diagnostics overview. ","categories": ["diagnostics"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2019/10/07/Mitigate-your-CPU-problems-before-they-even-happen.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "App Service Integration with Azure Monitor (Preview)",
+ "excerpt":"We are happy to announce that App Service has new and improved integration with Azure Monitor (preview). You can now send your logs from Windows or Linux App Service to Storage Accounts, Event Hubs, or Log Analytics. Increased visibility into your web apps Azure Monitor is the central observability service to collect, analyze, and act on telemetry from your other Azure resources. You can use Azure Monitor to set up rule-based alerts, create dashboards, export to third-party services with Event Hubs, or archive logs and metrics for compliance needs. App Service’s improved integration with Monitor enables new observability scenarios for development and operations teams. Developers can set up automatic emails with full stack traces when an exception is thrown. Operations teams can create dashboards to view the overall performance and stability of their applications. Compliance teams can monitor login attempts and file changes. App Service integration with Azure Monitor is currently in preview. Six brand new log types App Service now outputs the following log types into Azure Monitor. AppServiceConsoleLogs: Any logs or output written to the console (also known as standard output or standard error) AppServiceHTTPLogs: Access logs from the web server (IIS for Windows web apps, Nginx for Linux) AppServiceEnvironmentPlatformLogs: Logs for visibility into ASE operations such as scaling, configuration changes, and status AppServiceAuditLogs: Logs for any user login via FTP or Kudu AppServiceFileAuditLogs: Logs for file changes (add, delete, or update) via FTP or Kudu AppServiceAppLogs: Any logs or exceptions written to the stack’s logging utility. Supports multi-line logs and exceptions AppServiceIPSecLogs: Logs request made to the web app with IP info if there were IP access restriction rules set up AppServicePlatformLogs: Logs from containers (ie. “docker run”) AppServiceAntivirusScanAuditLogs: Logs from the anti-virus scan using Windows Defender (see blog for more information) The table below shows the current availability for the log categories. Log type Windows Windows Container Linux Linux Container Description AppServiceConsoleLogs Java SE & Tomcat Yes Yes Yes Standard output and standard error AppServiceHTTPLogs Yes Yes Yes Yes Web server logs AppServiceEnvironmentPlatformLogs Yes N/A Yes Yes App Service Environment: scaling, configuration changes, and status logs AppServiceAuditLogs Yes Yes Yes Yes Login activity via FTP and Kudu AppServiceFileAuditLogs Yes Yes TBA TBA File changes made to the site content; only available for Premium tier and above AppServiceAppLogs ASP .NET ASP .NET Java SE & Tomcat 1 Java SE & Tomcat 1 Application logs AppServiceIPSecAuditLogs Yes Yes Yes Yes Requests from IP Rules AppServicePlatformLogs TBA Yes Yes Yes Container operation logs AppServiceAntivirusScanAuditLogs Yes Yes Yes Yes Anti-virus scan logs using Microsoft Defender; only available for Premium tier 1 For Java SE apps, add the app setting WEBSITE_AZMON_PREVIEW_ENABLED and set it to 1 true. Getting Started Prerequisites Before you start, make sure you have the following resources created. Create an App Service app Create a Storage Account, Event Hub Namespace, or Log Analytics workspace to send your logs to Create a Diagnostic setting In the Azure portal, navigate to your App Service. Under Monitoring, select Diagnostic settings > Add diagnostic setting. Enter the following information to create the Diagnostic setting. Provide a name for the Diagnostic setting Select your desired destination(s) for the logs. There are three possible destinations: Storage Account: Archive your logs for auditing or backup Needs to be in the same region as your web app Configure the retention days for the storage account Event Hub: Stream the logs to third-party logging and telemetry systems Log Analytics Workspace: Analyze the logs with other monitoring data and leverage Azure Monitor features such as log queries and log alerts Select the desired log categories to export. There are six log categories in addition to your metrics. The table below lists the log types with its description and availability per OS. The earlier section shows the availability of each log type Select Save at the top. This will trigger App Service to begin sending your logs to the chosen destinations. View logs in a Storage account Open the Storage account you configured in the diagnostic setting. Then select Containers. You will see a list of containers that have been automatically created for the logs categories you enabled. Query logs in a Log Analytics Workspace Open the Log Analytics Workspace you configured in the diagnostic setting. Select Logs, then select LogManagement. (You will see log categories that you have not enabled.) The App Service log categories are all prefixed with AppService*. Select an App Service log category, this will copy the table name into the query editor. Select Run above the editor, this will execute a simple query to show all columns of the table. See this article for more information on the Kusto Query Language. Stream logs from Event Hubs Event Hubs allows you to stream your logs and metrics to 3rd party logging and telemetry systems or to Power BI. To get started, please see the Event Hubs documentation. Helpful Links App Service quick start Tutorial for Log Analytics Azure Monitor log query examples. ","categories": [],
+ "tags": ["monitoring"],
+ "url": "https://azure.github.io/AppService/2019/11/01/App-Service-Integration-with-Azure-Monitor.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Secure your Custom Domains at no cost with App Service Managed Certificates (preview)",
+ "excerpt":"Free Transport Layer Security (TLS) for Azure App Service is now in preview! This has been one of the most highly requested features of the service since its inception. The feature is named App Service Managed Certificates and it will let you secure custom domains on your Windows and Linux apps at no additional charge. This provides developers a zero-cost option to work on their dev, test, and production sites. This feature is available for customers on an App Service Plan of Basic and above (free and shared tiers are not supported). The certificate issued will be a standard certificate and not a wildcard certificate. Each certificate will be valid for six months, and about 45 days before the certificate’s expiration date, App Service will renew the certificate. App Service Managed Certificates VS App Service Certificates The offering for App Service Certificates will still be available with the launch of App Service Managed Certificates as these two features have their differences and are better suited for different scenarios. Aside from the main difference of pricing, a major difference between the two is that you will not be able to export your App Service Managed Certificates as they are managed by the platform. If you’re planning to do a live site migration with TXT record, need support for apex domains, or need a wildcard certificate, then use App Service Certificates or bring your own certificate. Getting started To get started, add a CNAME record for the domain to your web app. In the Azure Portal, head to your web app and from the left navigation of your app, select TLS/SSL settings > Private Key Certificates (.pfx) > Create App Service Managed Certificate. Once you’ve successfully created your App Service Managed certificate, you’ll see it on the list of Private Key Certificates. For additional reference, see the documentation. For any feedback, please reach out by creating an entry on the developer forums. ","categories": ["certsdomains"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2019/11/04/Announcing-Managed-Certificates.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Azure App Service at Microsoft Ignite 2019",
+ "excerpt":"During Microsoft Ignite 2019, this week, these are the Azure App Service sessions to look out for in the session catalog. Code Title Date Time THR2153 Best Practices and Tips for Operating and Monitoring Apps on Azure App Service Mon 4th November 1:40pm-2:00pm WRK2008 Running WordPress Applications on Azure App Service (workshop) Mon 4th November 4:00pm-5:15pm BRK3137 Migrate your Apps with Azure App Service Migration Thur 7th November 9:15am-10:00am BRK3061 Web App Network Security made Easy Thur 7th November 11:45am-12:30pm BRK2183 Linux based Web Application Deployment made Easy on App Service Fri 8th November 10:30am-11:15am Members of our engineering team are also attending the event and would love to talk with any attendees, hear feedback and answer any questions you may have. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2019/11/04/Azure-App-Service-at-Microsoft-Ignite-2019.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "PHP Minor Version Update for January 2020",
+ "excerpt":"Latest version updates to PHP In January 2020, Azure App Service will update the PHP stacks to the latest available versions. For information on the changes in the new versions, please see the change logs on the PHP website. PHP Version Change Log 7.1.33 http://www.php.net/ChangeLog-7.php#7.1.33 7.2.24 http://www.php.net/ChangeLog-7.php#7.2.24 7.3.11 http://www.php.net/ChangeLog-7.php#7.3.11 ","categories": [],
+ "tags": ["PHP"],
+ "url": "https://azure.github.io/AppService/2019/11/13/PHP-Minor-Version-Update-for-January-2020.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Azure CLI for ASE and Access Restriction",
+ "excerpt":"Based on customer requests we have added support for automating App Service Environment operations using the Azure CLI. With the 2.0.77 release you can create, list, update, and delete ASEs as well as create App Service Plans for an ASE. You can verify your installed version using az --version The create command has a number of options to make provisioning easy. In the default configuration, the command will create the necessary NSG and UDR rules and associate them with the designated subnet. az appservice ase create --resource-group myResourceGroup --name myAse --vnet-name myVNet --subnet myAseSubnet You can configure the Virtual IP type, Frontend SKU and scale, and much more. The commands also support --no-wait if you want to continue scripting while a command is running in the background. Give it a try and let us know through the Azure CLI git repo, if you find any issues. We also added commands for working with access restrictions. Access restrictions can be used to restrict access to specific IP addresses or to subnets using service endpoints. To control these restrictions with Azure CLI, you can now use the commands found in this group: az webapp config access-restriction Access restriction commands also allow you to control inheritance of restrictions for the scm site and control individual entries for the scm site. Access restriction commands are available in PowerShell as well: Get-AzWebAppAccessRestrictionConfig Update-AzWebAppAccessRestrictionConfig Add-AzWebAppAccessRestrictionRule Remove-AzWebAppAccessRestrictionRule Helpful links Azure CLI App Service Environment commands Azure CLI access restriction commands Azure PowerShell access restriction commands ","categories": ["networking"],
+ "tags": ["devops"],
+ "url": "https://azure.github.io/AppService/2019/12/09/Azure-CLI-for-ASE-and-Access-Restriction.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "App Service Environment Support for Availability Zones",
+ "excerpt":" NOTE! As of March 2023, the content in this post may be outdated. For the latest information on Availability Zone support for App Service Environment, see Azure App Service and reliability and Migrate App Service Environment to availability zone support. App Service has GA’d App Service Environment (ASE) support for deploying into Availability Zones (AZ). Customers can choose to optionally deploy internal load balancer (ILB) ASEs into a specific AZ (Zone 1, 2 or 3) within an Azure region, and the resources used by that ILB ASE will either be pinned to the specified AZ, or deployed in a zone redundant manner. An ILB ASE that is explicitly deployed into an AZ is considered a zonal resource because the ILB ASE is pinned to a specific zone. The following ILB ASE dependencies will be located (pinned) in the specified zone: the internal load balancer IP address of the ASE the compute resources used by the ASE to manage and run web applications The remote file storage for web applications deployed on a zonal ILB ASE uses Zone Redundant Storage (ZRS), though this is an internal implementation detail of zonal ILB ASEs. Note that unless the steps described in this article are followed, ILB ASEs are not automatically deployed in a zonal manner. Furthermore only ILB ASEs support availability zones - external facing ASEs (i.e. ASEs that have a public IP address for accepting website traffic) currently do not support zone pinning. Zonal ILB ASEs can be created in any of the following regions: Central US East US East US 2 East US 2 (EUAP) France Central Japan East North Europe West Europe Southeast Asia UK South West US 2 Applications deployed on a zonal ILB ASE will continue to run and serve traffic on that ASE even if other zones in the same region suffer an outage. However it is possible that non-runtime behaviors, including application service plan scaling, as well as application creation, configuration and publishing may still be impacted in the event of an outage in other availability zones. The zone-pinned deployment of a zonal ILB ASE only ensures continued uptime for already deployed applications and the underlying network infrastructure and virtual machines running those applications. Zonal ILB ASEs must be created using ARM templates. Once a zonal ILB ASE is created via an ARM template, it can be viewed and interacted with via the Azure Portal as well as CLI tooling. An ARM template is only needed for the initial creation of a zonal ILB ASE. The only change needed in an ARM template to specify a zonal ILB ASE is the new zones property. The zones property should be set to a value of 1, 2 or 3 depending on the logical availability zone that the ILB ASE should be pinned to. The ARM template snippet below shows the new zones property specifying that the ILB ASE should be pinned to zone 2. \"resources\": [ { \"type\": \"Microsoft.Web/hostingEnvironments\", \"kind\": \"ASEV2\", \"name\": \"yourASENameHere\", \"apiVersion\": \"2015-08-01\", \"location\": \"your location here\", \"zones\": [ \"2\" ], \"properties\": { \"name\": \"yourASENameHere\", \"location\": \"your location here\", \"ipSslAddressCount\": 0, \"internalLoadBalancingMode\": \"3\", \"dnsSuffix\": \"contoso-internal.com\", \"virtualNetwork\": { \"Id\": \"/subscriptions/your-subscription-id-here/resourceGroups/your-resource-group-here/providers/Microsoft.Network/virtualNetworks/your-vnet-name-here\", \"Subnet\": \"yourSubnetNameHere\" } } } ] In order to attain end-to-end zone resiliency for apps created on a zonal ILB ASE, customers need to deploy at least two zonal ILB ASEs - with each ILB ASE being pinned to a different zone. Customers must then create and publish copies of their application onto each of the zonal ILB ASEs. Customers will also need to deploy a load balancing solution upstream of the zonal ILB ASEs so that traffic bound for an application is load-balanced and distributed across all of the zonal ILB ASEs. The recommended solution is to deploy a zone redundant Application Gateway upstream of the zonal ILB ASEs. More details on Application Gateway v2 and its zone redundant configuration is available here. ","categories": ["networking"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2019/12/12/App-Service-Environment-Support-for-Availability-Zones.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Azure App Service on Azure Stack Hub Update 8 Released",
+ "excerpt":"This afternoon we released the eighth update to Azure App Service on Azure Stack Hub. This release updates the resource provider and brings the following key capabilities and fixes: Updates to App Service Tenant, Admin, Functions portals and Kudu tools. Consistent with Azure Stack Portal SDK version. Updates to core service to improve reliability and error messaging enabling easier diagnosis of common issues. Managed disk support for all new deployments – All new deployments of Azure App Service on Azure Stack Hub will make use of managed disks for all Virtual Machines and Virtual Machine Scale Sets. All existing deployments will continue to use unmanaged disks. TLS 1.2 Enforced by Front End load Balancers All other fixes and updates are detailed in the App Service on Azure Stack Update Eight Release Notes The App Service on Azure Stack Hub Update 8 build number is 86.0.2.13 You can download the new installer and helper scripts: Installer Helper Scripts Please read the updated documentation prior to getting started with deployment: Update 8 Release Notes Before you get started with App Service on Azure Stack Deploy the App Service Resource Provider for new deployments Update the App Service Resource Provider for updating existing deployments ","categories": [],
+ "tags": ["Azure Stack"],
+ "url": "https://azure.github.io/AppService/2020/01/13/App-Service-on-Azure-Stack-Hub-Update-8-Released.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "PHP Minor Version Update for February 2020",
+ "excerpt":"Latest version updates to PHP In February 2020, Azure App Service will update the Windows PHP stacks to the latest available versions. For information on the changes in the new versions, please see the change logs on the PHP website. PHP Version Change Log 7.2.27 https://www.php.net/ChangeLog-7.php#7.2.27 7.3.14 https://www.php.net/ChangeLog-7.php#7.3.14 Additionally, the Windows build of PHP 7.4 will be available with the February 2020 update. NOTE: Both PHP versions 7.0 and 7.1 are past End-Of-Life, and are no longer receiving security updates from the community. These versions will be removed with the February 2020 update. All sites configured with either PHP 7.0 or 7.1 will have their configuration changed to PHP 7.3. ","categories": [],
+ "tags": ["PHP"],
+ "url": "https://azure.github.io/AppService/2020/01/25/PHP-Minor-Version-Update-for-February-2020.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Run Wildfly on App Service",
+ "excerpt":"Wildfly is an open-source application runtime for Java applications, and the upstream project of JBoss EAP. We recently added a new Azure Sample that shows how to deploy Wildfly as a custom container onto Webapps for Containers. The container image in the sample is already configured to support web-SSH and wardeploy. The image also uses the Azul Zulu Enterprise build of the OpenJDK, which receives free support on Azure. (This support does not extend to the Wildfly runtime.) If your Java application only requires the servlet and JSP APIs, you can deploy your application onto Tomcat for App Service, which is supported on both Windows and Linux. Helpful Links Java long-term support for Azure and Azure Stack Java Docker images for Azure Wildfly ","categories": ["java"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2020/01/31/Wildfly-on-App-Service.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Announcing general availability of VNet Integration with Windows Web Apps",
+ "excerpt":"App Service customers often need to access resources in their Azure Virtual Networks. We launched VNet Integration to address this issue in 2014, but our customers wanted to use networking features like Network Security Groups (NSGs), Route Tables (UDRs) and Service Endpoints. Today we are announcing Regional VNet Integration to solve these problems and improve usability. Try the new Regional VNet Integration today!. Regional VNet Integration has been in preview for some time, but only supported calls to RFC1918 addresses (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) and service endpoints. The feature now supports outbound calls into the VNet on non-RFC1918 addresses as well. You can now use features like Network NSGs and UDRs against all of the outbound traffic from your web app. Regional VNet Integration will only work with VNets in the same Azure region as the Webapp. By default, if you use regional VNet Integration, your app will still only route RFC1918 traffic into your VNet. By setting the app setting WEBSITE_VNET_ROUTE_ALL to 1, your app will then enable all of the outbound traffic from your app to be subject to NSGs and UDRs. These new changes enable you to: Access non-RFC1918 endpoints through your VNet Secure all outbound traffic leaving your web app Force tunnel all outbound traffic to a network appliance of your own choosing Regional VNet integration is available in all public regions for Windows Webapps. Regional VNet Integration for Linux Webapps is currently in public preview. To use Regional VNet Integration, your Webapp must be in a Standard, Premium, PremiumV2 or Elastic Premium App Service plan. Regional VNet Integration only applies to outbound calls made by your Webapps, it does not enable private access to your apps. The older, gateway-required VNet Integration will continue to be supported. It integrates with VNets in other regions and Classic VNets. For more information about regional VNet Integration, see App Service VNet Integration. For more information about App Service networking features in general, see App Service networking features. ","categories": ["networking"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2020/02/27/General-Availability-of-VNet-Integration-with-Windows-Web-Apps.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Announcing public preview for Azure Functions portal UX",
+ "excerpt":"Access the preview The new user experience for Azure Functions is now available for all users in the Azure Portal. You can try the new experience by clicking on the “Preview the new Azure Functions management experience” banner in your function apps. Function App Overview Once you are in the new experience, you will notice that the new Azure Functions UX is now consistent with the rest of the Azure Portal. This UX is powered by the same Azure Functions Runtime API except they are now exposed through ARM. This allows for better caching, as well as support for RBAC, and enables new scenarios like being able to manage Azure Functions hosted on an Internal Load Balancer App Service Environment ASE. The core Azure Functions features are grouped in the menu bar under the Functions (preview) heading: Functions Functions lets you list the individual functions within your Function App. From here you can also: Add a new function. Delete an existing function Enable / disable individual functions Search / filter through your list of functions Drill into a specific function. App Keys App Keys lets you interact with the Function App Keys at the Host and System level. from here you can: View the values for Host & System keys Add / Remove Host & System keys Renew values for Host & System keys App Files App Files lets you view and modify files like host.json that are scoped to the Function app and not individual functions. Function Overview Once you drill into a specific Function within your Function App there is a new overview page scoped to this specific function. One of the added benefits of this overview is that folks can now deep link to this page. The body of the overview page is currently empty for the public preview, but we are working on adding metrics that are scoped to the execution of this specific function. Code + Test Code + Test menu item lets you view and modify the code of this specific function. You can browse to individual files: Test your function and see the execution logs: PRO TIP you can collapse the menu to maximize your code editor: Integration Integration menu item give you a graphical representation of your function. From here you can add / remove / edit all your Triggers, Inputs and Outputs bindings. Function Keys Function Keys provides similar functionality to Function App Keys, except it’s scoped to this specific function level. Wrapping up The new preview experience for Azure functions in the Azure Portal provides all the functionality of the existing UX but with better performance, accessibility and consistency with the rest of the Azure Portal. It also offers new functionality like RBAC support and improved code editor and integration UX. If you want to see the UX in action you can watch a demo from @bktv99 during monthly February 2020 Azure Functions webcast: If you find issues during the preview, you can file a bug. You can also request features using our User Voice. The Azure Functions team can also be reach through twitter: @AzureFunctions ","categories": [],
+ "tags": ["Azure Portal"],
+ "url": "https://azure.github.io/AppService/2020/03/13/Azure-Functions-Portal-Preview.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Important update for Tinfoil security",
+ "excerpt":"We’re announcing that Tinfoil Security addon will no longer be available through App Service. Over the next few months, we’ll start transitioning out this offer starting by disabling new sign ups at the end of April 2020. Existing Tinfoil enabled apps can continue to use the existing addon until May 2020. At any point during this transition period and through September 2020 you can migrate your account along with all of your scan settings and history to Tinfoil standalone service on tinfoilsecurity.com. By going through with this migration, you will get access to some features that were not available in the Azure integration at no additional cost including: More detailed scan reports such as an additional statistics page Access to Tinfoil API for easier automation The ability to add additional collaborators for read-only access to your Tinfoil scan results Instructions for this migration will be sent out via email to existing customers, and will also appear on your Tinfoil Security addon dashboard. Tinfoil is looking forward to continuing to help you keep your sites safe and secure! If you have any question you can reach out to Tinfoil support . ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2020/03/16/Important-update-for-Tinfoil-security.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Public Preview of Private Link on App Service",
+ "excerpt":"We are happy to announce the public preview of Private Link for Azure App Service. This preview is available in limited regions for all PremiumV2 Windows and Linux web apps. It is also now available for Elastic Premium Functions plans. Private Link enables you to host your apps on an address in your Azure Virtual Network (VNet) rather than on a shared public address. By moving the endpoint for your app into your VNet you can: Isolate your apps from the internet. Configuring a Private Endpoint with your app, you can securely host line-of-business applications and other intranet applications. Prevent data exfiltration. Since the Private Endpoint only goes to one app, you don’t need to worry about data exfiltration situations. The feature is currently available in all public regions. Using Private Link or Service Endpoints There is another networking feature called Service Endpoints which enables you to secure workloads to your VNet. There is a difference between Private Link and Service Endpoints. Service Endpoints enables you to secure your app to select set of subnets. It is used to secure the service to only being reachable from the select subnets. Private Link exposes your app on an address in your VNet and removes it from public access. This not only secures the app but can also be combined with Network Security Groups to secure your network. Private Link vs App Service Environment Having your app only accessible on a private address in your VNet is something that was previously only possible by using an ILB App Service Environment or an Application Gateway with an internal inbound address. The difference between using Private Link and an ILB ASE is that with an ILB ASE you have single tenant system that can host many apps behind one VNet address. With Private Link, your app runs in the public App service and you have one app behind one address. If you want to apply network security external to your application, then you still only get that with an ILB ASE. If you only need a private address in your VNet, then Private Link can give you that. Putting your app in your VNet Private Link provides a private address for inbound traffic only to your app. It does not enable your app to make outbound calls into your VNet. If you want to have all inbound and outbound in your VNet, then you need to use both Private Link and Regional VNet Integration. With Private Link you can secure the inbound and with VNet Integration you can secure the outbound. To get started, read the documentation here ","categories": ["networking"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2020/03/16/Public-Preview-of-Private-Link-on-App-Service.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "A New Look for App Service Diagnostics",
+ "excerpt":" The new experience is currently available for select Windows web apps. We are gradually rolling it out to all subscriptions in the coming weeks. App Service Diagnostics is an intelligent and interactive experience to help you troubleshoot your app with no configuration required. When you run into issues with your app, App Service Diagnostics points out what’s wrong to guide you to the right information to more easily troubleshoot and resolve issues. To make it easier for you to discover your application’s issues and helpful insights, we are launching a new experience in App Service Diagnostics. Discover Issues Faster The new experience allows you quickly discover issues that your application might be encountering by running health checks for each problem category upfront. Upon clicking on each problem category in the homepage, a series of checks are run, and the results are presented in the overview page. The cards at the top of the overview page show the status of your app by performing pre-selected checks on your application’s backend telemetry. You can click on these cards to further investigate the issue. If you already know the problem you want to drill down to, choose a relevant item in the left navigation where you will find more comprehensive checks on different topics. Interactive Interface: Genie When you are not sure where to begin, or you cannot find the information you are looking for, App Service Diagnostics’ interactive interface, Genie, can help guide you through diagnosing and solving problems of your app. Click the Ask Genie button at the top of the page to start a chat with our interactive interface, Genie. Type in the issue you are experiencing, and Genie will automatically fetch relevant diagnostics available in App Service Diagnostics and return the results along with relevant documentation found on the web. Genie will share its observation on the issue and list out checks that have succeeded. You can click on More Info to see additional information for each check. Command Bar The new experience introduces a command bar control at the top where you will find buttons and controls you often interact with. Below controls are now available in every page with diagnostics. Search: Search is now available in every page for you to quickly find and navigate to different diagnostics of your choice. Ask Genie: Ask Genie button is available in every page for you to get analysis and documentation results tailored to your issue. Refresh: Refresh button is available in every page for you to reload the diagnostics. Feedback: Feedback button is available in every page for you to share feedback with the App Service Diagnostics Product team. Time Filter: The new time filter now gives options to choose from predefined time range and custom time range using date picker and time picker to more easily filter the diagnostics to your desired time range. The time you select will be honored when you switch to another page. (Current limitations: The end time cannot be more than (current time - 15 minutes) due to limitations on data ingestion; The time range will reset to a 24-hour range once you go back to the homepage.) What’s Next For more information on App Service Diagnostics, please visit Azure App Service diagnostics overview. Feel free to share your feedback or questions about App Service Diagnostics by emailing diagnostics@microsoft.com or posting on UserVoice with “[Diag]” in the title. ","categories": ["diagnostics"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2020/03/23/A-New-Look-for-App-Service-Diagnostics.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "PremiumV2 tier for older App Service deployments",
+ "excerpt":"The PremiumV2 hardware tier is now available for older deployments of App Service where it was not previously available. A few years ago Azure App Service began to offer the PremiumV2 App Service plan. The benefits of this new tier were tied to the new hardware that was used for it. The same hardware is used for Free to Standard App Service plans. The new hardware required some changes to the system architecture and was not compatible with our older deployments. This unfortunately left many customers unable to upgrade their plans to PremiumV2. To solve this problem we developed a different way to attach the new PremiumV2 compute just for our older App Service deployments. This solution is now slowly rolling out and is adding the PremiumV2 option where it was previously unavailable. Changing IP Addresses When you scale to PremiumV2 while in a newer App Service deployment, your outbound addresses will change. To help customers that are sensitive to that, the app property called Additional Outbound IP Addresses contains all of the outbound addresses that your app can have. This field holds the outbound addresses your app can have while in Free through Standard as well as the addresses it would have while in PremiumV2. With the new ability to offer PremiumV2 to older deployments of the Azure App Service, both your inbound and outbound IP addresses will change when you scale from Standard or lower to PremiumV2 and back. This means that if you have A records for your app, you will need to update them after you scale. Your app will still be accessible for at least five days from the original address as we relay the inbound traffic to the new address. When you go to scale your app from Standard or lower to PremiumV2, you will be told the new addresses for your app. The same will be true if you scale from PremiumV2 to a lower tier. In order to select the PremiumV2, you need to acknowledge that your inbound and outbound addresses will change as you scale up your App Service plan. Features gained and lost There is a feature lost and another gained when you scale to PremiumV2 in these older App Service deployments. Remote debugging: When you scale your app to PremiumV2, you will no longer be able to use remote debugging for your apps. If you scale your App Service plan to a lower tier, you will be able to use remote debug again. Regional VNet Integration: When your app is in a PremiumV2 App Service plan, you will be able to use regional VNet Integration. When you scale back down to Standard tier or lower, you will lose the ability to use the feature. This is different from the newer App Service deployments where you can use regional VNet Integration from Standard and PremiumV2. How to scale to PremiumV2 To scale up to PremiumV2, or just to see if you can scale up to PremiumV2, navigate to the Scale up (App Service plan) page in your app portal. If you can select any of the PremiumV2 options, you are able to scale to PremiumV2. The user experience will show you your new addresses and request your acknowledgement. If you opt out at this point and come back later, the addresses you would see would be the same for the same app. Benefits of PremiumV2 It is important to highlight some of the other benefits of using a PremiumV2 App Service plan. Those benefits include: Cores are over twice as powerful Twice the memory per core as Standard or lower Can scale up to 30 instances Will be able to use Private Endpoints Can use regional VNet Integration ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2020/03/23/PremiumV2-support-for-older-deployments.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Get started with GitHub Actions and App Service",
+ "excerpt":"Last year we shared an article that demonstrated how to deploy your application to App Service using GitHub Actions. We are excited to share that we have added GitHub Actions as a build provider in the Deployment Center. This means it is even easier for developers to set up a continuous delivery pipeline with GitHub Actions. Follow the video or instructions below to get started. Getting started First, create an Azure Webapp if you do not already have one. Follow one of these quick start guides. Once the Webapp is created, open the Azure Portal and navigate to your Webapp. On the left side, click Deployment Center. In the Deployment Center, Select GitHub. You will be prompted to authenticate with GitHub if this is your first time using the Deployment Center. Click Continue at the bottom. On the next screen, choose GitHub Actions (Preview) as your build provider. Click Continue at the bottom. On the following panel, use the dropdowns to select your repository and branch. The branch you choose will be deployed to the Webapp. Next, choose your language and version. When you are done, click Continue at the bottom. The final screen shows a preview of the workflow file that will be committed into your repository under .github/workflows/. The workflow file will check out your branch, set your language and version, build your application, and deploy it to your Webapp. The workflow will run any time there is a commit on your specified branch. Click Finish after reviewing your selections. The Portal will commit this to the repository, which will trigger the the workflow to run. You will be forwarded to the Deployment Center Dashboard, where you can see a list of your recent deployments. You can use the buttons at the top to disconnect the dashboard. Next steps Congratulations! You now have an automated workflow that will build and deploy your app whenever new commits are pushed to the branch. As your application grows in complexity, so too can your workflows. There are plenty of other GitHub Actions to interact with the rest of your Azure Services as well. As always, don’t forget to use UserVoice to suggest enhancements and vote for other suggestions. More information Documentation: GitHub Actions and App Service Webapps deploy action The workflow for Python uses the App Service Build Action to ensure the app is built correctly for App Service. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2020/04/14/Get-Started-with-GitHub-Actions-and-Azure-Webapps.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Announcing .NET Core 3.1 LTS General Availability on App Service",
+ "excerpt":"App Service is announcing GA of .NET Core 3.1 LTS on Linux & Windows today. If you are running .NET Core 3.0 applications, which had its end-of-life date on March 3rd, 2020 you can update to and create .NET Core 3.1 applications in the Azure App Service portal now. You can also view this map to see available regions running .NET Core 3.1 (Windows Only). .NET Core 3.1 Long-term support .NET Core 3.1 is the Long-term support release which is supported by Microsoft for three years from it’s release date (December 2019). The release focuses on minor improvements to .NET Core 3.0 and is the recommended way to prepare for .NET 5. More information about end of life dates and the new release can be found here. Web App Development When creating your Web App in the portal, you can choose .NET Core 3.1 LTS as your runtime stack with your choice of Linux or Windows for your operating system and deploy the application as you usually would. If using Windows, you can check your version using the Console under Development Tools in your Web App blade. Running the dotnet --list-runtimes command will show your app including 3.1. For Linux, you will run the same command dotnet --list-runtimes using the SSH tool under Development Tools in your Web App blade to view 3.1 running on your app. ","categories": [],
+ "tags": ["dotnet"],
+ "url": "https://azure.github.io/AppService/2020/04/16/Announcing-.NET-Core-3.1-LTS-Generally-Available-on-App-Service.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Announcing Application Insights integration with App Service Diagnostics",
+ "excerpt":"App Services Diagnostics is a powerful tool that allows you to troubleshoot and mitigate issues within your application. The rich set of tools under the App Services Diagnostics carefully analyze all the telemetry emitted by App Services platform and suggests recommendations and troubleshooting steps that help in keeping your apps up and healthy. We are happy to announce that App Services Diagnostics has now deeper and better integration with Application Insights. With the click of a button, you can connect an Application Insights resource with App Service diagnostics and bring together the best of both worlds, allowing you to troubleshoot and debug your applications more effectively. With the rich information about the platform and application telemetry combined together, you are presented with a streamlined view of the issues encountered and this enables you to identify problems easily. Should you open a support case with Microsoft and consent to share diagnostics, this will also enable Microsoft support engineers to review the information from both the platform and App Insights to help you swiftly resolve your case. How to Enable Application Insights integration with App Service Diagnostics Enabling Application insights integration is as easy as clicking a button in App Services Diagnostics. To enable this feature, visit the Diagnose and Solve blade for your app and choose Availability and Performance. If Application Insights is not integrated for your app already, you will see an option to Enable Application Insights right from this view. And if Application Insights is already enabled, then you will get an option to Connect it with App Services Diagnostics. This connects the Application Insights resource for the app to App Service Diagnostics and allows you to view the exceptions and dependency information for the app within App Service Diagnostics. At the same time, any engineers engaged with you from Microsoft Support are enabled to leverage this information, provided you have given consent to share diagnostics information while creating a Support case. What to expect after enabling Application Insights Integration After enabling App Insights Integration feature, App Service Diagnostics starts leveraging App Insights telemetry and points you to exceptions and dependency slowness information in different views that you typically use to diagnose issues. Here is an example of the HTTP Server Errors view changes with Application Insights information. And drilling down into the HTTP Server Errors view, you can find all details about the failed requests corresponding to the Exceptions in the same view. As you can see below, the table shows you the exception information, exception message, and the method in the code that was responsible for causing the exception. With the help of this integration, you can not only view the platform issues but also correlate any application issues that caused availability drops to the app. What happens after you Integrate Application Insights with App Service Diagnostics When you click Connect, an API key for your Application Insights is generated with read-only access to the telemetry and this API key along with the AppId for the Application Insights resource are stored as a hidden tag in ARM at the Azure App Service app level. At the App Insights Resource level, you may see something like this. On the App Services side, you should see a new tag created at the app level with the name hidden-related:diagnostics/applicationInsightsSettings. You can view this tag by going to Azure Resource Explorer (https://resources.azure.com). The AppId is stored as is, but the API Key is encrypted using an internal key, so it is kept protected and not left as clear text. Using this information, App Services Diagnostics can query the Application Insights resource and is able to merge both the experiences together. For Microsoft support and engineering teams, an equivalent internal tool is available and engineers and engineering teams assisting you on your incidents opened with Microsoft can access this information in similar unified troubleshooting experience. How to disable App Insights Integration We are working on a user interface that allows you to disable this feature easily under Diagnose and Solve problems. Until then, you can use a PowerShell Script example like this to simple disable the AppInsights integration feature. Login-AzureRmAccount $subId = \"<Azure_Subscription_ID>\" $rg =\"<ResourceGroupName>\" $appName = \"AppName\" $resourceId = \"/subscriptions/$subId/resourceGroups/$rg/providers/Microsoft.Web/sites/$appName\" $webApp = Get-AzureRmResource -ResourceId $resourceId $updatedTags = @{} foreach($t in $webApp.Tags.GetEnumerator()) { if ($t.Key -ne \"hidden-related:diagnostics/applicationInsightsSettings\") { $updatedTags.Add($t.Key, $t.Value) } } Set-AzureRmResource -ResourceId $resourceId -Tag $updatedTags Next steps So, what are you waiting for :smiley:? Integrate your application with Application Insights and get the unified experience that brings the best of both worlds. We just want to close by sharing some articles around Application Insights. What is Application Insights? Monitor Azure App Service performance Instrument Application Code to Track Exceptions For more information on App Service Diagnostics, please visit Azure App Service diagnostics overview. Feel free to share your feedback or questions about App Service Diagnostics by emailing diagnostics@microsoft.com or posting on UserVoice with “[Diag]” in the title. ","categories": ["diagnostics"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2020/04/21/Announcing-Application-Insights-Integration-with-App-Service-Diagnostics.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Running .NET 5 (preview) on App Service",
+ "excerpt":".NET 5 is the latest version to expand the capabilities of .NET by taking the best of Core, Framework, Xamarin, and Mono to create a unified platform for improving developer scenarios. .NET 5 is currently in preview and available for use in existing or new applications. Find more information on the release and how to upgrade an existing project here. To get started with .NET 5 on App Service you can use one of two deployment methods. A Self-Contained deployment will allow you to deploy your app on machines that don’t have the runtime installed. You can also deploy your application with a more portable solution using a Container which will package your app and dependencies to run on App Service. Local Setup In order to setup .NET 5 in your application you need to first install the .NET 5.0 SDK. There are a number of preview versions of .NET 5 SDK’s available. We recommend using the latest SDK v5.0.0-rc.1, a feature complete Release Candidate SDK. If you’re on Windows using Visual Studio, you will also need to download the latest Visual Studio Preview version here. Self-Contained Deployment A Self-Contained deployment enables you to run .NET 5 because it doesn’t rely on the presence of shared components on the target system and all components including Core libraries and runtime are with the application and isolated from other apps. This way you have sole control of which version your application is running. Self-contained deployments are supported for both Windows and Linux apps. Note that with self-contained applications you should be aware of large deployments and managing updates as this will take up more hard drive space and cause you to be responsible for supplying updated versions of your app with new security patches. To complete a self-contained deployment in .NET you would first create your project as usual then choose ASP.NET Core 5.0 for your apps version after selecting your application template. Select Create and modify your application as needed. To publish, simply Right-Click your project and select publish. In the latest version of Visual Studio you can choose where your target publish is from a new menu. Then select Azure App Service (Windows) or Azure App Service (Linux) depending on your preference on the following screen. Next, choose a previously created App Service or create one from Visual Studio and fill out the required information as you normally would when publishing. When you reach the publish screen click the pencil icon to edit your Deployment Mode for publishing your application. Next, Choose the Deployment Mode option and make sure Self-Contained is chosen. After you select the Self-Contained option your Target Runtime will auto-populate to linux-x64 or win-x86 depending on your operating system selection. Save your new settings and click Publish on the preceding screen to publish to App Service and launch your application using .NET 5. More information on self-contained deployment can be found here. Container Deployment The other option for running your .NET 5 application is to deploy a Docker container to App Service on Linux or Windows (Premium SKU only). When deploying a container, you are packaging the application and its dependencies into a Linux or Windows based image to run on the App Service platform. This enables your application to be more portable in nature as it is not reliant on the host operating system and has the runtime and SDK added into the image. Once you have your application setup for .NET 5, the steps to deploy a containerized application would be the same as any other container deployment. Right-click your project, Add -> Docker Support . Your .NET 5 project will have a new Dockerfile added with the .NET 5.0 base image and SDK ready for you to publish. After you have added Docker support, you will publish it to a registry, and create your App Service as usual. See our documentation for more detail on deploying a containerized application. ","categories": [],
+ "tags": ["dotnet"],
+ "url": "https://azure.github.io/AppService/2020/04/24/Running-.NET-5-Preview-on-App-Service.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Reduce costs and increase agility with App Service and API Management",
+ "excerpt":"In times of rapid change, developers and IT decision-makers must quickly adjust to a drastically evolving landscape. Successful organizations use managed cloud services to reduce operating costs by increasing developer efficiency, and seize new business opportunities by accelerating delivery of innovation. Try this tutorial to get started with App Service, GitHub Actions, and API Management. Host applications with App Service App Service is a proven managed service for hosting your web apps and mobile backends with deployment APIs, networking integration, and built-in monitoring. Use your preferred technology stack to increase the speed-to-market. Build your applications with .NET, .NET Core, Java, Node.js, Python or PHP. Deploy them as code or Docker containers and integrate with API management in Visual Studio Code or the Azure Portal. Simplify operations with GitHub Actions. Use GitHub Actions to automate the testing and deployment of your applications onto App Service’s global infrastructure. The Azure Portal makes it easy to get started with a guided developer experience. Then use deployment slots to coordinate your QA, staging, and production deployments. Isolate and secure applications with enterprise-grade global datacenter network. Once your applications are deployed, isolate and secure them in a Virtual Network or in an App Service Environment. Get more secure, high-speed connections to resources on premises or in the cloud and maintain fine-grained control over network traffic. Manage, protect, and publish APIs with API Management API Management lets you manage and protect APIs throughout their lifecycle and publish them to consumers. Increase the speed to market with one-click API import. Design the API from scratch or generate it automatically from an API definition file (OpenAPI, WSDL, WADL) or an Azure service (App Service, Functions, Logic Apps). Simplify management of APIs. API Management abstracts the APIs from their implementation, allowing you to transform and iterate on your backend services without impacting API consumers. As the backends evolve and API traffic increases, create new API revisions and versions and monitor the usage with Azure Application Insights, Azure Monitor, or custom solutions. Protect and secure your APIs from abusive users with policies. Apply the rate-limit-by-key policy to throttle API calls based on any key – for example, IP address or user credentials. Set long-term quotas with the quota-by-key policy to limit the allowed number of calls or data transfer. Secure your APIs with built-in API subscription keys mechanism, client certificates, or JWT tokens. The most convenient way to author policies is to use the Azure portal or the official Visual Studio Code extension with the autocomplete feature. Examples of more advanced policies are located in this GitHub repository. Seize new business opportunities by publishing your APIs in the developer portal. Azure API Management comes with a built-in developer portal. It is an automatically generated, fully customizable website where visitors can discover your APIs, learn how to use them, try them out interactively, and sign up to acquire access. By publishing your APIs, you can scale your operations and build an ecosystem around your services. You may also monetize them to create new revenue streams. Try the sample To get started with App Service and API Management, clone this sample application and follow the instructions. By the end of the tutorial, you will have set up continuous delivery with GitHub Actions and exposed your backend API with API Management. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2020/05/01/Reduce-costs-and-increase-agility-with-App-Service-and-API-Management.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "PHP Minor Version Update for July 2020",
+ "excerpt":"Latest version updates to PHP In June/July 2020, Azure App Service will update the PHP stacks to the latest available versions. For information on the changes in the new versions, please see the change logs on the PHP website. PHP Version Change Log 5.6.401 http://www.php.net/ChangeLog-5.php#5.6.40 + security fixes from https://github.com/microsoft/php-src/commits/PHP-5.6-security-backports + OpenSSL 1.1 7.2.22 http://www.php.net/ChangeLog-7.php#7.2.30 7.3.9 http://www.php.net/ChangeLog-7.php#7.3.17 7.4.5 http://www.php.net/ChangeLog-7.php#7.4.5 1 - PHP v5.6 is past End-Of-Life, and is no longer receiving security updates from the community. However, to ensure our customers have the most secure PHP builds available, we have arranged to temporarily have relevant security fixes from supported versions of PHP backported to PHP v5.6. ","categories": [],
+ "tags": ["PHP"],
+ "url": "https://azure.github.io/AppService/2020/05/04/PHP-Minor-Version-Update-for-July-2020.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Azure App Service and Azure Functions on Azure Stack Hub 2020 Q2 Released",
+ "excerpt":"We have released the 2020 Q2 update to Azure App Service on Azure Stack Hub. This release updates the resource provider and brings the following key capabilities and fixes: Updates to App Service Tenant, Admin, Functions portals and Kudu tools. Consistent with Azure Stack Portal SDK version. Updates Azure Functions runtime to v1.0.13021. Updates to core service to improve reliability and error messaging enabling easier diagnosis of common issues. Updates to the following application frameworks and tools: ASP.NET Framework 4.7.2 ASP.NET Core 3.1.3 ASP.NET Core Module v2 13.1.19331.0 PHP 7.4.2 Updated Kudu to 86.20224.4450 NodeJS 8.17.0 10.19.0 12.13.0 12.15.0 NPM 5.6.0 6.1.0 6.12.0 6.13.4 Updates to underlying operating system of all roles: 2020-04 Cumulative Update for Windows Server 2016 for x64-based Systems (KB4550929) 2020-04 Servicing Stack Update for Windows Server 2016 for x64-based Systems (KB4550994) Cumulative Updates for Windows Server are now applied to Controller roles as part of deployment and upgrade Updated default Virtual Machine and Scale set skus for new deployments: To maintain consistency with our public cloud service, new deployments of Azure App Service on Azure Stack Hub will use the following SKUs for the underlying machines and scale sets used to operate the resource provider Role Minimum SKU Controller Standard_A4_v2 - (4 cores, 8192 MB) Management Standard_D3_v2 - (4 cores, 14336 MB) Publisher Standard_A2_v2 - (2 cores, 4096 MB) FrontEnd Standard_A4_v2 - (4 cores, 8192 MB) Shared Worker Standard_A4_v2 - (4 cores, 8192 MB) Small dedicated worker Standard_A1_v2 - (1 core, 2048 MB) Medium dedicated worker Standard_A2_v2 - (2 cores, 4096 MB) Large dedicated worker Standard_A4_v2 - (4 cores, 8192 MB) For ASDK deployments, you can scale the instances down to lower SKUs to reduce the core and memory commit but you will experience a performance degradation. All other fixes and updates are detailed in the App Service on Azure Stack Hub 2020 Q2 Release Notes The App Service on Azure Stack Hub Update 8 build number is 87.0.2.10 Please review the release notes and all Known issues prior to updating your installation of Azure App Service on Azure Stack Hub. Documentation Updates All of the documentation for Azure App Service and Azure Functions on Azure Stack Hub has been reviewed and edited to support this release, to address feedback from customers and to improve the quality of the documentation to support cloud operators. In addition the articles covering Azure App Service and Azure Functions on Azure Stack Hub have been reclassified under the table of contents to better classify the documentation and to maintain consistency with other resource providers on Azure Stack Hub:  You can download the new installer and helper scripts: Installer Helper Scripts Please read the updated documentation prior to getting started with deployment: 2020 Q2 Update Release Notes Prerequisites for deploying App Service on Azure Stack Hub Deploy the App Service Resource Provider for new deployments Update the App Service Resource Provider for updating existing deployments ","categories": [],
+ "tags": ["Azure Stack"],
+ "url": "https://azure.github.io/AppService/2020/05/06/App-Service-on-Azure-Stack-Hub-2020-Q2-Update-Released.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "App Service integration with Event Grid",
+ "excerpt":"We are happy to announce the Public Preview of App Service’s integration with Azure Event Grid. Event Grid is a publish/subscribe messaging service that allows you to easily build event-based architectures. Event Grid is heavily integrated into Azure services, allowing you to react to events coming from your resources. Follow the quickstart below to get started! Integrated Events App Service now emits 13 events to Event Grid. These events span configuration changes, slot swaps, restarts, backups, and more. If you have an idea for an event type that you would like to see added, let us know on UserVoice. Event Type Description Microsoft.Web/sites.BackupOperationStarted Triggered when a backup has started Microsoft.Web/sites.BackupOperationCompleted Triggered when a backup has completed Microsoft.Web/sites.BackupOperationFailed Triggered when a backup has failed Microsoft.Web/sites.RestoreOperationStarted Triggered when a restoration from a backup has started Microsoft.Web/sites.RestoreOperationCompleted Triggered when a restoration from a backup has completed Microsoft.Web/sites.RestoreOperationFailed Triggered when a restoration from a backup has failed Microsoft.Web/sites.SlotSwapStarted Triggered when a slot swap has started Microsoft.Web/sites.SlotSwapCompleted Triggered when a slot swap has completed Microsoft.Web/sites.SlotSwapFailed Triggered when a slot swap has failed Microsoft.Web/sites.SlotSwapWithPreviewStarted Triggered when a slot swap with preview has started Microsoft.Web/sites.SlotSwapWithPreviewCancelled Triggered when a slot swap with preview has been cancelled Microsoft.Web/sites.AppUpdated Triggered when a site has been restarted, stopped, or the app settings have changed Microsoft.Web/serverfarms.AppServicePlanUpdated Triggered when an App Service Plan is updated More information about these events. Get started Event Grid is a flexible service that enables developers to architect cutting-edge, event-driven patterns. For example, you can resize images uploaded to Azure Storage, or get an email when your VM scales up. This quickstart will walk through how to get started with a simple event handler, but we are excited to see what you can build with the newly integrated events from App Service. Create a Function with an Event Grid trigger First, create a new Azure Function with an Event Grid trigger. If you do not already have a Function App in your subscription, follow these instructions to create a new Function App. Once you have your Function App, browse to it in the Portal. In the list of Functions, select the “+” to add a new Function. In the following screen, filter the triggers by searching for “event grid”. Select “Azure Event Grid trigger” and enter a name for the Function. Finally, click “Create”. Add the Function as an endpoint Now that the Event Grid triggered Function is created, we will add it as a handler for events from our Azure Webapp. Navigate to one of your Azure Webapps in the Portal. Select the “Events” button in the toolbar on the left side of the blade. This will open a new blade where you can register event handlers. If you have used Event Grid before with other Azure services, this blade will look familiar. Click “+ Event Subscription” at the top of the blade. In the following screen, enter a name for the event subscription and select “Azure Function” as the Endpoint Type. Next, click “Select an endpoint” and find your Event Grid triggered Function using the filters in the context menu. Finally, click “Create”. Summary You have now set up an Azure Function as an event handler for your Event Grid subscription. Whenever events are emitted from your web app, this Function will execute. Click back to the “Events” tab to see a timeline of your events. Next steps This quickstart covered only a sliver of Event Grid’s capabilities. You can also use Logic Apps, Hybrid Connections, and web hooks as your event handlers. You can use these handlers to send yourself an email if a backup fails, send information to an on-premises resource, and much more! If you have suggestions for events that App Service should emit, let us know on UserVoice. Helpful links Event Grid terminology Compare Azure messaging services Azure CLI for Event Grid Event Grid Pricing ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2020/05/11/event-grid-integration.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "The Ultimate Guide to Running Healthy Apps in the Cloud",
+ "excerpt":"Modern-day data centers are extremely complex and have many moving parts. VMs can restart or move, systems are upgraded, and file servers are scaled up and down. All these events are to be expected in a cloud environment. However, you can make your cloud application resilient to these events by following best practices. This document outlines 13 crucial steps that you can take to ensure that your app is cloud ready. By taking these steps, you will ensure that any events in the data center will have negligible effects on your app and that your app will be more resilient and future proof. As mentioned above, your instances are expected to and will restart. They will be upgraded and will sometimes suffer from file server movements. However you can make your app resilient to all these incidents. In order to guarantee the maximum uptime for your app, please ensure that you follow all practices. Use Multiple Instances Running your app on only one VM instance is an immediate single point-of-failure. By ensuring that you have multiple instances allocated to your app, if something goes wrong with any particular instance, your app will still be able to respond to requests going to the other instances. Keep in mind that your app code should be able to handle multiple instances without synchronization issues when reading from or writing to data sources. You can allocate multiple instances to your app using the “Scale out (App Service Plan)” blade: To avoid a single point-of-failure, run your app with at least 2-3 instances. This is especially important if your app takes considerable time to start (known as cold start). Running more than one instance ensures that your application is available when App Service moves or upgrades the underlying VM instances. You can also configure rules to automatically scale out based on predefined rules such as: Time of day (when the app has the most traffic) Resource utilization (memory, CPU, etc.) A combination of both! Learn More Get started with Autoscale in Azure App Service Warm-Up Demystified Update your default settings App Service has many settings for developers to configure the web app to their use case. Always-On keeps your VM instances alive even when no requests have been received in the last 20 minutes. By default, Always-On is disabled; enabling Always-On will limit application cold starts. ARR Affinity creates sticky sessions so that clients will connect to the same app instance on subsequent requests. However, ARR Affinity can cause unequal distribution of requests between your instances and possibly overload an instance. Disabling ARR Affinity assumes that your application is either stateless, or the session state is stored on a remote service such as a cache or database. Lastly, please set the Platform setting from 32 Bit to 64 Bit. The maximum available amount of memory for a 32-bit process (even on a 64-bit operating system) is 2 GB. By default, the worker process is set to 32-bit in App Service (for compatibility with legacy web applications). Consider switching to 64-bit processes so you can take advantage of the additional memory available in your Web Worker role. For production apps that are aiming to be robust, it is recommended to set Always on to On, ARR Affinity to Off and Platform to 64 Bit. You can change these settings in the configurations section of the Azure Portal, under the General Settings tab: Learn More Configure an App Service app in the Azure portal Disable Session affinity cookie (ARR cookie) for Azure web apps Use Production Hardware App Service offers a variety of hardware tiers (also known as SKUs) to suit different customer needs. When creating a new App Service Plan, you have an option to select a different hardware tier for your plan: If your App Service Plan is used for production, please ensure that your App Service Plan is running on one of the recommended “production” pricing tiers. Moreover, if your application is resource intensive, make sure to select the appropriate pricing tier within the recommended ones according to the need of your app. For example, if your application consumes a lot of CPU cycles, running on an S1 pricing tier will not be ideal as it could potentially cause high CPU that would cause downtime or slowness on your app. Learn More Scale up an app in Azure App Service Leverage Deployment Slots Before deploying your new code to production, you can leverage the Deployment Slots feature in App Services to test your changes. Deployment slots are live apps with their own host names. App content and configurations elements can be swapped between two deployment slots, including the production slot. Deploying your application to a non-production slot has the following benefits: You can validate app changes in a staging environment before swapping it into the production slot. Deploying an app to a slot first and swapping it into production makes sure that all instances of the staging slot are warmed up before swapping into production. This eliminates downtime when you deploy your app. The traffic redirection is seamless, and no requests are dropped because of swap operations. You can automate this entire workflow by configuring auto swap. After a swap, the slot with previously staged app now has the previous production app. If the changes swapped into the production slot aren’t as you expect, you can perform the same swap immediately to get your “last known good site” back. Please note that Deployment Slots are only available for Standard, Premium, or Isolated App Service plan tiers We highly recommend using Swap with Preview. Swap with Preview allows you to test the app in your staging slots against your production settings and also warm up the app. After doing your tests and warming up all the necessary paths, you can then complete the swap and the app will start receiving production traffic without restarting. This has a high impact on your app’s availability & performance. Learn More Set up staging environments in Azure App Service Azure Web App Deployment Slot Swap with Preview Deployment best practices Set your Health Check path App Service allows you to specify a health check path on your apps. The platform pings this path to determine if your application is healthy and responding to requests. When your site is scaled out to multiple instances, App Service will exclude any unhealthy instance(s) from serving requests, improving your overall availability. Your app’s health check path should poll the critical components of your application, such as your database, cache, or messaging service. This ensures that the status returned by the health check path is an accurate picture of the overall health of your application. Go to Monitoring > Health Check on the Web App blade for Azure portal: Set the value of the path that our service will ping. Hit save to save the configuration. Please note that the Health Check feature works only when you have two or more instances, which is a very strong recommendation. For a single instance web app, the traffic is never blocked even if that single instance is encountering issues. Learn More Health Check (Preview) Use Application Initialization Application Initialization ensures that your app instances have fully started before they are added to they start serving requests. Application Initialization is used during site restarts, auto scaling, and manual scaling. This is a critical feature where hitting the site’s root path is not sufficient to start the application. For this purpose a warm-up path must be created on the app which should be unauthenticated and App Init should be configured to use this url path. Try to make sure that the method implemented by the warm-up url takes care of touching the functions of all important routes and it returns a response only when warm-up is complete. The site will be put into production only when it returns a response (success or failure) and app initialization will assume “everything is fine with the app”. App Initialization can be configured for your app within web.config file. Learn More How to warm up Azure Web App during deployment slots swap Enable Local Cache When this feature is enabled, the site content is read, written from the local virtual machine instance instead of fetching from Azure storage (where site content is stored). This will reduce the number of recycles required for the app. It can be enabled through Azure portal from the “General -> Application settings”. On this page under the App settings section add WEBSITE_LOCAL_CACHE_OPTION as key and \"Always\" as value. Also add the WEBSITE_LOCAL_CACHE_SIZEINMB with a desired local cache size value up to 2000MB (if not provided, it defaults to 300 MB). It helps to provide the cache size specially when the site contents are more than 300 MB. Ensure that site contents are less than 2000MB for this feature to work. Also it is a good practice to keep it as a slot setting so that it does not get removed with a swap. The most important thing to keep in mind here is that app should not be doing local disk writes for state persistence of its data/transactions. External storage like storage containers, db or cosmosDB should be used for storage purposes. Please note that the behavior of Local Cache depends on the language and CMS you are using. For best results, we recommend using it for .net and .netcore apps as long as local writes are not being done by the app. Learn More Azure App Service Local Cache overview Auto-Heal Sometimes your application might experience unexpected behaviors that could be resolved by a simple restart. The Auto-Heal features allows you to do exactly that! It allows you to define the ‘condition’ that would trigger Auto-Heal and the ‘action’ that Auto-Heal will initiate when the condition is met. You can create an Auto-Heal mitigation rule by going to “Diagnose and Solve problems” section -> “Diagnostic Tools” tile and then “Auto-Heal” under Proactive Tools section. Below are example filter values to set up, however if some other value of error code and frequency suits your application, please modify accordingly: Condition Value Request Count 70 Status Code 500 Sub-status code 0 Win32-status code 0 Frequency in seconds 60 Once the condition above is met, we recommend configuring an action to: Recycle Process and add an ‘Override when Action Executes’: Startup Time for process before auto heal executes: 3600 seconds (1 hour) Learn More Azure App Service Auto-Heal Announcing the New Auto-Heal Experience in App Service Diagnostics Minimize App Service Plan Density Running too many Apps in an App Service Plan can have a negative impact performance. All the apps running on the App Service Plan can be seen on “Apps” under “Settings” section in your App Service Plan on Azure portal. You can verify the App Service Plan density with the App Service Plan Density Check. Learn more here: App Service Plan Density Check Monitor Disk Space usage Ensure that the disk space used by www folder should be less than 1GB. It is a very healthy practice in reducing downtime during app restarts and hence improve the application performance. File system usage can be tracked from “App Service Plan -> Quotas” section in Azure portal. Enable Application Insights Application Insights offers a suite of features that empower you to troubleshoot incidents that happen on your app. You can use it to debug code errors, diagnose performance degradations caused by dependencies and more. One of the powerful features of Application Insights is the App Insights Profiler. Enabling Application Insights Profiler provides you with performance traces for your applications that are running in production in Azure. Profiler captures the data automatically at scale without negatively affecting your users. Profiler helps you identify the “hot” code paths that take the longest when handling a web request. Profiler works with .NET applications. To enable it, go to your Application Insights in Azure portal. Click on Performance under Investigate. In the Performance pane click on “Configure Profiler” In the pane that opens after that, click on “Profile Now” to start profiling. When Profiler is running, it profiles randomly about once per hour and for a duration of two minutes. If your application is handling a steady stream of requests, Profiler uploads traces every hour. To view traces, in the Performance pane, select Take Actions, and then select the Profiler Traces button. App Insights also allows you to track dependencies in your application. You can leverage this feature to troubleshoot slow requests. To automatically track dependencies from .NET console apps, install the Nuget package Microsoft.ApplicationInsights.DependencyCollector, and initialize DependencyTrackingTelemetryModule as follows: DependencyTrackingTelemetryModule depModule = new DependencyTrackingTelemetryModule(); depModule.Initialize(TelemetryConfiguration.Active); Each request event is associated with the dependency calls, exceptions, and other events that are tracked while your app is processing the request. So if some requests are doing badly, you can find out whether it’s because of slow responses from a dependency. You can see a waterfall view of the requests in the performance blade as well under the “Dependencies” tab: You can also leverage our newly released App Insights integration with App Service Diagnostics, discussed in details here: Learn More Profile production applications in Azure with Application Insights Diagnose exceptions in your web apps with Application Insights Dependency Tracking in Azure Application Insights Deploy in Multiple Regions You can deploy Azure Front Door or Azure Traffic Manager to intercept traffic before they hit your site. They help in routing & distributing traffic between your instances/regions. In the event that a catastrophic incident happens in one of the Azure Datacenters, you can still guarantee that your app will run and serve requests by investing in one of them. There are additional benefits to using Front Door or Traffic Manager, such as routing incoming requests based the customers’ geography to provide the shortest respond time to customers and distribute the load among your instances in order not to overload one of them with requests. Learn More Controlling Azure App Service traffic with Azure Traffic Manager Quickstart: Create a Front Door for a highly available global web application Check App Service Diagnostics Finally, you can check the progress you’ve accomplished in making your app resilient by leverage the “Risk Assessments” section available in App Service Diagnostics here: You’ll be presented by 2 options: Best Practices for Availability & Performance Best Practices for Optimal Configuration We recommend that you follow all the best practices listed in those detectors and get them all to green! Finally, we also recommend that you take a look at the Cloud Design Patterns document to minimize the application start time and follow more resiliency recommendations. Feel free to post any questions about App Resiliency on the MSDN Forum. ","categories": [],
+ "tags": ["best practice"],
+ "url": "https://azure.github.io/AppService/2020/05/15/Robust-Apps-for-the-cloud.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "App Service //Build 2020 Recap",
+ "excerpt":"This year, Microsoft Build is entirely online. Live and pre-recorded sessions are available for anyone to view. This article is a recap of the sessions from the App Service team, along with links to more information. Building and Managing .NET Core with App Service Building web apps with .NET Core? Check out the latest from the App Service team including how to build a continuous delivery pipeline using GitHub Actions, how to use Event Grid to subscribe and act on deployment events and how to monitor your production apps with Health Checks. Watch the session here. GitHub Actions GitHub Actions is a flexible automation framework that allows developers to (among other things) continuously deploy their applications to App Service. Webapps deploy Action GitHub Actions for Azure GitHub Actions Marketplace App Service Health Checks App Service Health Checks will automatically remove and restart unhealthy instances of your application when you are scaled out. Documentation Event Grid Integration Event Grid is a high performance publish/subscribe messaging system. App Service now emits events that can be handled with Functions, Logic Apps, and more. Getting started guide Event Grid overview Comparison of Azure messaging services Migrate Applications to Azure App Service See how Azure is making it easy to quickly get your application running on App Service. We’ll show you how to use Migration Assistant for moving IIS sites and Linux containers to the cloud. Watch the session here FAQ Many of you attended our “Ask the Experts” live session and sent us your questions. Here are some common questions you asked, along with their answers. Can you use LetsEncrypt certificates with Azure App Services? You’re still able to use Let’s Encrypt certs with App Service, however there is no official support when it comes to integrating it with auto-renew. We have App Service Managed Certificates, which is our free certificate offering that supports auto-renew. This feature is currently in preview and only currently supports CNAME Records. Documentation. What is the status for App Service Managed Certificates supporting apex/naked domains? This is the next milestone for this feature that we are currently working on. We don’t have an ETA to provide as of now. Is it a good strategy to use deployment slots to define environments (eg. myapp, myapp/uat, myapp/qa) or would it be better to have different resources for each environment? Would it affect the performance of the main prod “myapp” service? You can certainly use slots to stage your test, QA, and other environments. This works especially well if your team uses the Gitflow branching strategy, as each branch can be continuously deployed to a staging slot. If you are worried about the extra slots consuming too many resources, you can actually host the production slot on it’s own, independent App Service Plan. What is the status for the different logs with the Azure Monitor integration? We will be releasing AppServiceAppLogs for Windows soon – estimating the next two/three months. We don’t have an ETA for the other logs as of now. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2020/05/19/App-Service-Build-2020-recap.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Continuous Deployment for Windows Containers with GitHub Actions",
+ "excerpt":"Github Actions enables you to easily automate any part of your development workflow. GitHub Actions are defined as YAML files in the .github/workflows directory of your repository. The workflows are triggered by an event, such as a push to a specific branch, a commit or comment on a pull request, or on a CRON schedule. In this article, we will use GitHub Actions for Azure to deploy a Windows Container application to App Service. The sample application is already configured to be used in a Windows Container, pushed to a registry, and deployed to App Service. Of course, you can use this guide to add the correct deployment tasks to work with your own applications. Sample Application If you would like to get started with your own application, you can skip to the next section. The sample application is a simple task-tracking app built with .NET Framework using Azure SQL for storage. The project has a workflow file, main.yaml, that is set up for continuous deployment. You have your choice of using Azure Container Registry (ACR) or Docker Hub for your registry needs (the difference in syntax will be explained below). Find the full repository samples for .NET Framework and .NET Core at these highlighted links. Create Resources Create the following resources. You will need information from each resource that will be used in the file and stored in your secrets. Create your choice of registry (Azure Container Registry or Docker Hub) first since you will need information from there before you can create your App Service. Azure Container Registry OR Docker Hub repository App Service (Web App for Container) .NET Framework application with supporting dockerfile in a GitHub repository Azure SQL Database (Optional) Create a Service Principal (optional) or use Publish Profile In this step you have the choice of using a Service Principal or Publish Profile for authentication. If you would like to use your publish profile credentials instead, please skip this section and see Deploy to Azure App Service to see how. To use a Service Principal, please continue here: Our workflow will use a Service Principal to authenticate with Azure when deploying the container to App Service. A service principal is an Active Directory Identity created for use with automation scenarios, such as GitHub Actions. Run the following command in Azure CLI in powershell to get the credentials needed to run the login action. The output of this command will be a collection of key value pairs that you’ll need to add to your GitHub secrets. az ad sp create-for-rbac --name \"<appservice-name>\" --role contributor \\ --scopes /subscriptions/{subscription-id}/resourceGroups/{resource-group} \\ --sdk-auth Copy the output into your GitHub secrets to use as your AZURE_CREDENTIALS secret. { \"clientId\": \"<GUID>\", \"clientSecret\": \"<GUID>\", \"subscriptionId\": \"<GUID>\", \"tenantId\": \"<GUID>\" } Secure Secrets Since we are using sensitive information that you don’t want others to access, we will use GitHub secrets to protect our information. Create a secret by following the directions here. Add the github secrets variables below with your own secrets appropriate from each resource. APP_NAME: web-app-name AZURE_CREDENTIALS: the JSON output of the az ad sp create-for-rbac command PUBLISH_PROFILE: content of your publish profile (optional) IMAGE_NAME: name-of-image CONTAINER_REGISTRY_USERNAME: Your container registry username CONTAINER_REGISTRY_PASSWORD: Your container registry password CONTAINER_NAME: The hostname of the container registry (ACR only) AZURE_SQL_CONNECTION_STRING: database-connection-string DATABASE_SERVER_NAME: server-name The Dockerfile The samples below explain the associated Dockerfiles for the .NET Framework and .NET Core sample applications linked above. If creating your own application, use the appropriate Dockerfile below and replace the directory paths to match your application. .NET Framework .NET Framework applications will work best with a multi-stage build. This example copies over the necessary project files and packages before it creates the publish files for deployment to Azure. # Set the base image FROM mcr.microsoft.com/dotnet/framework/sdk:4.8 as build WORKDIR \"/src\" # Copy packages to your image and restore them COPY taskapp/taskapp.sln . COPY taskapp/taskapp/taskapp.csproj taskapp/taskapp/taskapp.csproj COPY taskapp/taskapp/packages.config taskapp/taskapp/packages.config RUN nuget restore taskapp/taskapp/packages.config -PackagesDirectory taskapp/packages # Add files from source to the current directory and publish the deployment files to the folder profile COPY . . WORKDIR /src/taskapp/taskapp RUN msbuild taskapp.csproj /p:Configuration=Release /m /p:DeployOnBuild=true /p:PublishProfile=FolderProfile # Layer the production runtime image FROM mcr.microsoft.com/dotnet/framework/aspnet:4.8-windowsservercore-ltsc2019 as deploy # Add the publish files into the right directory WORKDIR /inetpub/wwwroot COPY --from=build /src/taskapp/taskapp/bin/Release/Publish . .NET Core For .NET Core, the nano server base image must be “1809” to be compatible with what Azure currently supports. Keep in mind this may change in the future. # Set the base image FROM mcr.microsoft.com/dotnet/core/aspnet:3.1-nanoserver-1809 AS base WORKDIR /app EXPOSE 80 # Add the sdk so you can run the dotnet restore and build commands FROM mcr.microsoft.com/dotnet/core/sdk:3.1-nanoserver-1809 AS build WORKDIR /src COPY *.csproj ./ RUN dotnet restore \"taskapp.csproj\" COPY . . WORKDIR \"/src\" RUN dotnet build \"taskapp.csproj\" -c Release -o /app/build # Create the publish files FROM build AS publish RUN dotnet publish \"taskapp.csproj\" -c Release -o /app/publish # Copy the publish files into the container FROM base AS final WORKDIR /app COPY --from=publish /app/publish . ENTRYPOINT [\"dotnet\", \"taskapp.dll\"] Create the GitHub Workflow Now that we have our resources created, secrets secured, and dockerfile in order we can start building our workflow file for continuous deployment. The workflow file is a yaml file in .github/workflows/. It contains a collection of actions that run when triggered. Add the workflow file by going to the Actions tab in your repository and click Set up a workflow yourself. After choosing this option, you will see a starter worklfow that explains how GitHub Actions work. If you are new to this I recommend you read the comments, but we won’t be needing any of the starting code so you can remove it. Add the workflow trigger First, specify the trigger that starts the workflow. For our example, we are simply triggering the build whenever there is a push into the master branch If you would like to change this behavior, there are many other triggers for Github Actions. name: Build and Deploy Windows Container App to Azure App Service # Trigger the build on commits into the master branch on: push: branches: - master # Starts jobs and sets the type of runner (Windows) they will run on jobs: build-and-deploy-to-azure: runs-on: windows-latest steps: # Checks out repository so your workflow can access it - uses: actions/checkout@v1 Log into your container registry In order for the workflow to access our registry, we need to add our Docker login action. This action can login to both Azure Container Registry or Docker Hub. If logging into Docker Hub, you can get away with not using the login-server parameter. If using ACR, you can grab the server name, username, and password from the Access Keys tab in your Azure Container Registry Resource. Add the following secrets if you have not already: CONTAINER_REGISTRY_USERNAME: Your container registry username CONTAINER_REGISTRY_PASSWORD: Your container registry password CONTAINER_NAME: The hostname of the container registry (ACR only) Azure Container Registry # Use docker login to log into ACR - name: Docker login to ACR uses: azure/docker-login@v1 with: login-server: ${{ secrets.CONTAINER_REGISTRY_NAME }} username: ${{ secrets.CONTAINER_REGISTRY_USERNAME }} password: ${{ secrets.CONTAINER_REGISTRY_PASSWORD }} Docker Hub # Use docker login - name: Docker Hub login uses: azure/docker-login@v1 with: username: ${{ secrets.CONTAINER_REGISTRY_USERNAME }} password: ${{ secrets.CONTAINER_REGISTRY_PASSWORD }} Build and Push Image to Registry Next, we will add a command to build and push the container image to the registry. We are using the $ to tag the container with the commit id. This makes it easy to track what each image contains. Add the following secrets if you have not already: IMAGE_NAME: The name of the image (can be any name) CONTAINER_REGISTRY_NAME: The hostname of the container registry (ACR only) # Build and push the image to Container Registry - name: Build and Push container to registry run: | docker build --file=taskapp/taskapp/Dockerfile -t ${{ secrets.CONTAINER_REGISTRY_NAME }}/${{ secrets.IMAGE_NAME }}:${{ github.sha }} . docker push ${{ secrets.CONTAINER_REGISTRY_NAME }}/${{ secrets.IMAGE_NAME }}:${{ github.sha }} Authenticate with Azure In the earlier section you created an Azure Service Principal and added it as a GitHub Secret. You can now add the Azure login action to the workflow. This action will use the Service Principal to authenticate with Azure. If you are using a publish profile to deploy your application instead of using a Service Principal, please skip this section. Add the following secrets if you have not already: AZURE_CREDENTIALS: The output of the earlier command that generated the Service Principal - name: Azure Service Principal Authentication uses: azure/login@v1 with: creds: ${{ secrets.AZURE_CREDENTIALS }} Deploy to Azure App Service If you haven’t already created your App Service, now is the time to do so before you can proceed. Remember that Windows Containers deployment is only available on the Premium tier App Service Plans. Be mindful of the tier capacity, as you may need to scale up if your container is too large. The final step to setting up the continuous deployment is to add the webapps container deploy action. Add the following secrets if you have not already: APP_NAME: The webapp name CONTAINER_REGISTRY_NAME: The container registry name IMAGE_NAME: The name of the container image PUBLISH_PROFILE: content of your publish profile - name: Deploy Container to Azure App Service uses: azure/webapps-container-deploy@v1 with: app-name: ${{ secrets.APP_NAME }} images: ${{ secrets.CONTAINER_REGISTRY_NAME }}/${{ secrets.IMAGE_NAME }}:${{ github.sha }} If you would like to deploy using your publish profile instead of using a Service Principal add the publish-profile line: - name: Deploy container to Azure App Service uses: Azure/webapps-deploy@v2 with: app-name: ${{ secrets.APP_NAME }} publish-profile: ${{ secrets.PUBLISH_PROFILE }} images: ${{ secrets.REGISTRY_USERNAME }}.azurecr.io/${{ secrets.IMAGE_NAME }}:${{ github.sha }} To obtain the contents of your publish profile: Go to the Overview page of your web app Click on the Get publish profile tab to download your publish profile Copy the entire contents of the xml file and add it to your GitHub secret PUBLISH-PROFILE See this documentation for an example. Deploy to Azure SQL Database (Optional) Adding Azure SQL to the workflow is optional of course, as you might have other plans for storage. To deploy your SQL database to Azure, you will use a dacpac file or SQL scripts, and a connection string. The connection string can be found in the overview page of your Azure SQL database and you can create your dacpac by extracting the data using something like SQL Server Object Explorer in Visual Studio. Add the following secrets if you have not already: DATABASE_SERVER_NAME: The resource name of the database AZURE_SQL_CONNECTION_STRING: The full connection string for the database Both your server name and connection string are found in the Azure database resource in the portal. Copy the connection string, making sure your password and user ID are correct, and paste into your GitHub secrets. Create a dacpac file in your project As mentioned before, you’ll need to use either a dacpac file or set of SQL scripts to deploy your database schema. If you are using Visual Studio, it’s easy to create and add the needed dacpac file to run the action. Connect your SQL Azure Database to Visual Studio Right-click the data base and choose Extract Data-tier application On the following window, choose the location at the same level of your github workflow file and click create. # Deploy a dacpac file to a pre-provisioned Azure SQL Server - name: Azure SQL Deploy uses: Azure/sql-action@v1 with: server-name: ${{ secrets.DATABASE_SERVER_NAME }}.database.windows.net connection-string: ${{ secrets.AZURE_SQL_CONNECTION_STRING }} dacpac-package: './data.dacpac' Your dacpac file should have been created and added to your project. The action finds your file under the dacpac-package parameter seen above. Summary From here you are setup to continuously build your Windows Container application through github actions. Below you’ll see the final result of the workflow yaml file. Full workflow file The previous sections showed how to assemble the workflow step-by-step. The full main.yaml is below. name: Build and Deploy Windows Container App to Azure App Service # Trigger the build on commits into the master branch on: push: branches: - master # Starts jobs and sets the type of runner (Windows) they will run on jobs: build-and-deploy-to-azure: runs-on: windows-latest steps: # Checks out repository so your workflow can access it - uses: actions/checkout@v1 # Authenticate a Service Principal to deploy to your Web App - name: Azure Service Principal Authentication uses: azure/login@v1 with: creds: ${{ secrets.AZURE_CREDENTIALS }} # Use docker login to log into ACR - name: Docker login to ACR uses: azure/docker-login@v1 with: # comment out the login-server parameter if using docker hub login-server: ${{ secrets.CONTAINER_REGISTRY_NAME }} username: ${{ secrets.CONTAINER_REGISTRY_USERNAME }} password: ${{ secrets.CONTAINER_REGISTRY_PASSWORD }} # Build and push your image to Azure Container Registry - name: Build and Push container to ACR run: | docker build --file=taskapp/taskapp/Dockerfile -t ${{ secrets.CONTAINER_REGISTRY_NAME }}/${{ secrets.IMAGE_NAME }}:${{ github.sha }} . docker push ${{ secrets.CONTAINER_REGISTRY_NAME }}/${{ secrets.IMAGE_NAME }}:${{ github.sha }} # Deploy your container to App Service - name: Deploy Container to Azure App Service uses: azure/webapps-container-deploy@v1 with: app-name: ${{ secrets.APP_NAME }} images: ${{ secrets.CONTAINER_REGISTRY_NAME }}/${{ secrets.IMAGE_NAME }}:${{ github.sha }} # Deploy a dacpac file to your SQL server - name: Azure SQL Deploy uses: Azure/sql-action@v1 with: server-name: ${{ secrets.DATABASE_SERVER_NAME }} connection-string: ${{ secrets.AZURE_SQL_CONNECTION_STRING }} dacpac-package: './data.dacpac' Helpful Resources Actions Checkout Action Azure Login Action Docker Login Action Azure SQL Deploy Action Azure WebApp Container Action Other resources Build 2020 Session Covering GitHub Actions App Service Docs for GitHub Actions ","categories": [],
+ "tags": ["dotnet","windows containers"],
+ "url": "https://azure.github.io/AppService/2020/06/09/App-Service-Continuous-Deployment-for-Windows-Containers-with-GitHub-Actions.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": ".NET Framework 4.8 is coming to App Service",
+ "excerpt":" The .NET Framework 4.8 update is a non-breaking in-place upgrade on App Service. No updates are required to existing applications. An update is coming for App Service to support .NET Framework 4.8. You will soon be able to take advantage of the updated .NET Framework toolset, bug fixes, and key improvements in accessibility and runtime. For the full list of updates and changes see the announcement and release notes. The update will come to App Service starting in July 14, 2020 and completing by September 15, 2020. For sovereign clouds the update will start on August 11, 2020 completing by October 15, 2020. In preparation for the platform upgrade to .NET Framework 4.8, customers can choose to test applications locally in advance. To track progress during the deployment, we will be posting periodic updates on this GitHub Issue. Testing your applications locally Test your application locally by completing the following steps: Download & install .NET Framework 4.8 for your appropriate scenario here. Run your application in your local browser and verify the application features. If you have issues with your application, feedback can be given on GitHub. —Optional steps if you plan to re-target your application in the future to explicitly require .NET Framework 4.8— If you choose to re-target your application to 4.8 in the future: Review the Migration Guide for Runtime changes and Retargeting Guide for application compatibility issues that may affect your application. Re-test your application in your local browser and verify the application features. Confirming the update on App Service You can confirm your webapp’s current .NET Framework version by following these quick steps. To see if your apps have been updated after we begin the platform update, check which .NET Framework version is in use by using the console. Open the Console feature under Development Tools in the App Service blade of your Azure Portal. Run the following command: cd \"\\Program Files (x86)\\Reference Assemblies\\Microsoft\\Framework\\.NETFramework\". Run the dir command to list out the installed versions of .NET Framework. If .NET Framework 4.8 is installed, it will be located at D:\\Program Files (x86)\\Reference Assemblies\\Microsoft\\Framework\\.NETFramework\\v4.8 Changes in the portal When the deployment is complete across all regions, your Azure App Service portal will update to ASP.NET V4.8 replacing ASP.NET V4.7 in the .NET Framework version drop down under General Settings in the Configuration blade. ","categories": [],
+ "tags": ["dotnet"],
+ "url": "https://azure.github.io/AppService/2020/06/09/NET-Framework-4.8-is-coming-to-App-Service.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "General Availability of Linux Hybrid Connections",
+ "excerpt":"We are happy to announce Hybrid Connections for Linux apps is now Generally Available. Hybrid Connections have been available for Windows apps for a few years and is now available for Linux apps as well. Hybrid Connections enables your apps to access TCP endpoints in any network that can make outbound calls to Azure. Hybrid Connections don’t enable an alternate capability to access your application (for that you should look at Private Endpoints). As used in App Service, each Hybrid Connection matches to a single TCP host and port combination. This means that the Hybrid Connection endpoint can be a TCP endpoint on any operating system and any application. There is no awareness in the feature for any application protocols that are used, it simply provides network access. You can make calls to SQL, a web service, or any other TCP socket. Other integration technologies rely on VPN solutions to connect on-premises systems to the cloud. Hybrid Connections reduce overhad and provide direct access to resources without an inbound firewall hole or gateway. The feature is built on top of Azure Relay. It works by you installing a relay agent on a Windows server 2012 or better host. This relay agent, the Hybrid Connection Manager (HCM), must be able to make outbound calls to Azure over port 443 and be able to reach the desired endpoint. The feature depends on DNS name lookups to work. In order to ensure that things work, you should use domain names in your Hybrid Connections rather than IP addresses. The DNS name does not need to be in public DNS. It only needs to resolve from the hosts where the HCM is running. Due to the nature of how Hybrid Connections works, it is a great solution when others do not fit directly. It provides the fastest way to do dev/test from on-premises in the cloud. The feature is supported in Basic, Standard, Premiumv2 and Isolated App Service plans. For more details around Hybrid Connections, start with App Service Hybrid Connections ","categories": ["networking"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2020/06/17/General-Availability-of-Linux-Hybrid-Connections.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "General Availability of VNet Integration for Linux Web Apps",
+ "excerpt":"Regional VNet Integration is now Generally Available for both Linux and Windows apps. The feature behaves the same for apps on either operating system. This means that your Linux apps can make calls into Resource Manager VNets in the same region. You can filter outbound calls with Network Security Groups (NSGs). You can route traffic with Route Tables (UDRs). You can also access resources that are secured with Service Endpoints or Private Endpoints. Regional VNet Integration supports hub-and-spoke configurations and reaching across ExpressRoute. Try the new Regional VNet Integration today! The public preview for Regional VNet Integration on Linux had a problem with port conflicts and custom containers. That problem has been solved in the GA release. You no longer need to worry about port conflicts with custom containers. If you integrate your app with your VNet, the default behavior remains as it was. You would only be able to reach RFC1918 addresses (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) and service endpoints. Just like with Windows, the feature now supports outbound calls into the VNet on non-RFC1918 addresses as well. To reach all addresses you need to set the app setting WEBSITE_VNET_ROUTE_ALL to 1, your app will then enable all of the outbound traffic from your app to be subject to NSGs and UDRs. This is the same behavior as seen with Windows web apps. These new changes enable you to: Access non-RFC1918 endpoints through your VNet Secure all outbound traffic leaving your web app Force tunnel all outbound traffic to a network appliance of your own choosing Regional VNet integration is available in all public regions now for for Windows Webapps and Linux Webapps. To use Regional VNet Integration, your Webapp must be in a Standard, Premium, PremiumV2 or Elastic Premium App Service plan. Regional VNet Integration only applies to outbound calls made by your Webapps, it does not enable private access to your apps. The older, gateway-required VNet Integration is not supported for Linux apps. This does mean that there isn’t a solution to integrate your Linux apps directly with VNets in other regions or with Classic VNets For more information about regional VNet Integration, see App Service VNet Integration. For more information about App Service networking features in general, see App Service networking features. ","categories": ["networking"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2020/06/17/General-Availability-of-VNet-Integration-with-Linux-Web-Apps.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Continuous Deployment for Windows Containers with Azure DevOps",
+ "excerpt":"Azure DevOps enables you to host, build, plan and test your code with complimentary workflows. Using Azure Pipelines as one of these workflows allows you to deploy your application with CI/CD that works with any platform and cloud. A pipeline is defined as a YAML file in the root directory of your repository. In this article, we will use Azure Pipelines to deploy a Windows Container application to App Service. The sample application is already configured to be used in a Windows Container, pushed to a registry, and deployed to App Service. Of course, you can use this guide to add the correct deployment tasks to work with your own application. Sample Application If you would like to get started with your own application, you can skip to the next section. The sample application is a simple task-tracking app built with .NET Framework using Azure SQL for storage. The project has a workflow file, azure-pipelines.yaml, that is set up for continuous deployment. You have your choice of using Azure Container Registry (ACR) or Docker Hub for your registry needs (the difference in syntax will be explained below). Find the full repository samples for .NET Framework and .NET Core at these highlighted links. Create Resources Create the following resources. You will need information from each resource that will be used in the pipeline file and stored as a variable. Create your choice of registry (Azure Container Registry or Docker Hub) first since you will need information from there before you can create your App Service. Azure Container Registry OR Docker Hub repository App Service (Web App for Container) .NET Framework application with supporting dockerfile in a GitHub repository Azure SQL Database (Optional) Add a Service Connection Before you create your pipeline, you should first create your Service Connection since you will be asked to choose and verify your connection when creating your template. A Service Connection will allow you to connect to your registry of choice (ACR or Docker Hub) when using the task templates. When adding a new service connection, choose the Docker Registry option. The following form will ask you to choose Docker Hub or Azure Container Registry along with pertaining information. You can create a new Service Connection following the directions here. The Dockerfile The samples below explain the associated Dockerfiles for the .NET Framework and .NET Core sample applications linked above. If creating your own application, use the appropriate Dockerfile below and replace the directory paths to match your application. .NET Framework Your .NET Framework application will work best with a multi-stage build. This example copies over the necessary project files and packages before it creates the publish files for deployment to Azure. # Set the base image FROM mcr.microsoft.com/dotnet/framework/sdk:4.8 as build WORKDIR \"/src\" # Copy packages to your image and restore them COPY taskapp/taskapp.sln . COPY taskapp/taskapp/taskapp.csproj taskapp/taskapp/taskapp.csproj COPY taskapp/taskapp/packages.config taskapp/taskapp/packages.config RUN nuget restore taskapp/taskapp/packages.config -PackagesDirectory taskapp/packages # Add files from source to the current directory and publish the deployment files to the folder profile COPY . . WORKDIR /src/taskapp/taskapp RUN msbuild taskapp.csproj /p:Configuration=Release /m /p:DeployOnBuild=true /p:PublishProfile=FolderProfile # Layer the production runtime image FROM mcr.microsoft.com/dotnet/framework/aspnet:4.8-windowsservercore-ltsc2019 as deploy # Add the publish files into the right directory WORKDIR /inetpub/wwwroot COPY --from=build /src/taskapp/taskapp/bin/Release/Publish . .NET Core For .NET Core, the nano server base image must be “1809” to be compatible with what Azure currently supports. Keep in mind this may change in the future. # Set the base image FROM mcr.microsoft.com/dotnet/core/aspnet:3.1-nanoserver-1809 AS base WORKDIR /app EXPOSE 80 # Add the SDK so you can run the dotnet restore and build commands FROM mcr.microsoft.com/dotnet/core/sdk:3.1-nanoserver-1809 AS build WORKDIR /src COPY *.csproj ./ RUN dotnet restore \"taskapp.csproj\" COPY . . WORKDIR \"/src/\" RUN dotnet build \"taskapp.csproj\" -c Release -o /app/build # Create the publish files FROM build AS publish RUN dotnet publish \"taskapp.csproj\" -c Release -o /app/publish # Copy the publish files into the container FROM base AS final WORKDIR /app COPY --from=publish /app/publish . ENTRYPOINT [\"dotnet\", \"taskapp.dll\"] Create the Pipeline Once you have your repository created in Azure DevOps, or imported from GitHub, you can create your pipeline. On the left menu bar go to Pipelines and click the Create Pipeline button. The next screen will ask you where the code is to create the pipeline from. We already have our code imported, so we can choose Azure Repos Git to select your current repository. Since we are using Docker containers we can choose the Docker template that allows us to build and push an image to Azure Container Registry or Docker Hub. Choose your subscription that you will be pushing your resources to, then pick your Container registry on the following screen. You will notice your Image Name and Dockerfile are pre-populated with a suggested name and path to your Dockerfile. You can leave those as is, and click on the Validate and configure button to generate your azure-pipeline.yaml file. Secure Secrets with Variables Variables are only accessible after your create the pipeline. Since we are using sensitive information that you don’t want others to access, we will use variables to protect our information. Create a variable by following the directions here. To add a Variable, you click the Variables button next to the Save button in the top-right of the editing view for your pipeline. Select the New Variable button and enter your information. Add the variables below with your own secrets appropriate from each resource. imageRepository: image-name containerRegistry: ‘your-registry-name.azurecr.io’ OR ‘your-docker-hub-registry-name’ applicationName: app-name azureSQLConnectionString: database-connection-string (Optional) Build the Pipeline Once you have the necessary variables, you can start to add the tasks you need to complete the pipeline. Below is an explanation of the Docker tasks that were added to your pipeline from the Docker template with the addition of using Docker Hub instead of ACR. The additional tasks to deploy to your App Service and optional Azure SQL follow. Build and push your image to a registry After your pipeline is generated from choosing the Docker configured template, you’ll notice a few things in the YAML build. The first is the trigger, which determines what sets off the build. We are using any push or change to master as a trigger here, but you can change it to trigger on another branch as well. The resource is anything used by the pipeline that lives outside of it like a repository or container registry. You can leave this as self since we are using our own repository. Your image type is included and the build stages & task follow. # The branch that triggers the pipeline to start building trigger: - master # The source used by the pipeline resources: - repo: self # Variables used in the Azure Container Registry deployment variables: # Container registry service connection established during pipeline creation dockerRegistryServiceConnection: '<your-service-connection-number' dockerfilePath: '$(Build.SourcesDirectory)/taskapp/taskapp/Dockerfile' tag: '$(Build.BuildId)' # Agent VM image name vmImageName: 'windows-latest' # Build stage to build your application and push it to a registry stages: - stage: Build displayName: Build and push stage jobs: - job: Build displayName: Build pool: vmImage: $(vmImageName) steps: - task: Docker@2 displayName: Build and push an image to container registry inputs: command: buildAndPush repository: $(imageRepository) dockerfile: $(dockerfilePath) containerRegistry: $(dockerRegistryServiceConnection) tags: | $(tag) Double check that your vmImageName = ‘windows-latest’ as it might default to ‘ubuntu-latest’. Next, add the buildContext below to make sure that necessary application files are being copied over to the image file system. If you forget this line, you will run into an error that can’t find the path inside of your Dockerfile build. Azure Container Registry - task: Docker@2 displayName: Build and push an image to container registry inputs: command: buildAndPush repository: $(imageRepository) dockerfile: $(dockerfilePath) containerRegistry: $(dockerRegistryServiceConnection) buildContext: '.' tags: | $(tag) Docker Hub If you are using Docker Hub, your parameters will already have the buildContext added. However, you may want to add the tags parameter at the end to keep track of which build was sent - task: Docker@2 displayName: Build and Push inputs: command: 'buildAndPush' repository: '$(containerRegistry)/$(imageRepository)' dockerfile: '$(Build.SourcesDirectory)/taskapp/taskapp/Dockerfile' containerRegistry: '$(dockerRegistryServiceConnection)' buildContext: '.' tags: | $(tag) You can now hit Save and Run to start the pipeline build. Head over to the Azure portal, where your container registry is, and verify that your image repository name is in the registry repository. Setup the Deploy Stage Our first stage was pre-populated by the Docker task assistant as our Build stage. We can split the deployment process in half here by adding our Deploy stage. This is done by using the first part of our yaml file and repurposing it to include our deployment tasks. Add in the following code to define a second stage in your pipeline. # Deploy stage to your App Service and Azure SQL Database - stage: Deploy displayName: Deploy to App Service and Azure SQL jobs: - job: Deploy displayName: Deploy pool: vmImage: $(vmImageName) steps: Deploy to Azure App Service Now that you have your image pushed to your registry and your deploy stage setup. You can push the container to App Service. If you haven’t already created your App Service in the Azure portal, you’ll need to do so now before you can proceed. Once you have your App Service created in Azure, you can edit your pipeline to include the deployment to your App Service. Click the assistant in the top right corner of the file and search for Azure Web App for Containers. This task enables you to push a Windows or Linux container to your Azure App Service. You can learn more about how the task works here. Choose your subscription from the drop down menu and click the authorize button (Note: if authorize returns an error, you may need to add a Service Connection as stated before). Now you can add your App name, which should be populated in the drop down, and Image name, which is in the format of “.azurecr.io/:$(tag)\". Do not fill out the bottom two parameters Configuration File and Startup command. These are not necessary for what is needed. Parameter Value Azure subscription: your-subscription-name App name: your-app-name Image name: registryname.azurecr.io/imagename:$(tag) Configuration File: X Startup command: X The registry name information can be found in the Overview tab of you registry resource blade, and the image name can be found in the Repositories tab in the registry resource as well. We are using the DevOps variable $(tag) so it builds with the latest buildId everytime the task is ran. Now you can save your edited pipeline and get the following output below. You can test that it works by pushing up a change from your code and checking that your App Service will have an updated tag number in the Container Settings tab as well as your application changes in your deployed application. - task: AzureWebAppContainer@1 inputs: azureSubscription: '<your-subscription-name>' appName: '$(applicationName)' containers: '$(containerRegistry)/$(imageRepository):$(tag)' If you run into the following error during your build: “This pipeline needs permissions to access a resource before this run can continue to Build and push stage”. Click the View button on the error and Permit button on the following screen to allow the build to continue. Deploy to an Azure SQL Databse (Optional) Adding Azure SQL to the workflow is optional of course, as you might have other plans for storage. To deploy your SQL database to Azure, you will use a dacpac file or SQL scripts, and a connection string. The connection string can be found in the overview page of your Azure SQL database and you can create your dacpac by extracting the data using something like SQL Server Object Explorer in Visual Studio. If you need to import a SQL database that you’d like to host on Azure, you have the option to add in the Azure SQL Database deployment task which can be found in the assistant we used earlier. Enter the following values for the parameters. Parameter Value Azure Service Connection Type: Azure Resource Manager Azure Subscription: your-subscription-name SQL Database Authentication Type: Connection String Connection String: your-connection-string Deployment Package Deploy Type: SQL DACPAC File Action: Publish DACPAC File: $(Build.SourcesDirectory)/your-file-name.dacpac Additional SQLPackage.exe Arguments: X Once created with the above parameters, the output should show as below. - task: SqlAzureDacpacDeployment@1 inputs: azureSubscription: 'your-subscription-name' AuthenticationType: 'connectionString' ConnectionString: '$(azureSQLConnectionString)' deployType: 'DacpacTask' DeploymentAction: 'Publish' DacpacFile: '$(Build.SourcesDirectory)/data.dacpac' IpDetectionMethod: 'AutoDetect' Connection String Our sample app has a dummy connection string in the web.config that will need to be changed for local testing or can be added into your application settings from your App Service as a Connection String setting in the Configuration tab. Make sure the connection string name in the web.config file matches the connection string name in your App Service setting, with the actual connection string added as the value in your settings. For more information on how to do this see this link. When adding the values for the SQL Database parameters, you’ll want to choose Connection String as your Authentication Type and add in your connection string. We’ll use Variables in DevOps to hide our connection string in safe keeping. Creating a dacpac file in your project As mentioned before, you’ll need to use either a dacpac file or set of SQL scripts to deploy your database schema. If you are using Visual Studio, it’s easy to create and add the needed dacpac file to run the action. Connect your SQL Azure Database to Visual Studio Right-click the data base and choose Extract Data-tier application On the following window, choose the location at the same level of your github workflow file and click create. Your dacpac file should have been created and added to your project. The action finds your file under the dacpac-package parameter seen above. Summary From here you are setup to continuously build your Windows Container application through Azure DevOps. Below you’ll see the final result of the workflow yaml file. Full workflow file The previous sections showed how to assemble the workflow step-by-step. The full azure-pipelines.yaml is below. trigger: - master resources: - repo: self variables: # Container registry service connection established during pipeline creation dockerRegistryServiceConnection: 'your-auto-populated-service-connection-number' azureSubscriptionName: 'your-azure-subscription-name' dockerfilePath: '$(Build.SourcesDirectory)/taskapp/taskapp/Dockerfile' tag: '$(Build.BuildId)' # Agent VM image name vmImageName: 'windows-latest' stages: - stage: Build displayName: Build and push stage jobs: - job: Build displayName: Build pool: vmImage: $(vmImageName) steps: - task: Docker@2 displayName: Build and push an image to container registry inputs: command: buildAndPush repository: '$(imageRepository)' dockerfile: $(dockerfilePath) containerRegistry: '$(dockerRegistryServiceConnection)' buildContext: . tags: | $(tag) - stage: Deploy displayName: Deploy to App Service and Azure SQL jobs: - job: Deploy displayName: Deploy pool: vmImage: $(vmImageName) steps: - task: AzureWebAppContainer@1 inputs: azureSubscription: '$(azureSubscriptionName)' appName: '$(applicationName)' containers: '$(containerRegistry)/$(imageRepository):$(tag)' - task: SqlAzureDacpacDeployment@1 inputs: azureSubscription: '$(azureSubscriptionName)' AuthenticationType: 'connectionString' ConnectionString: '$(azureSQLConnectionString)' deployType: 'DacpacTask' DeploymentAction: 'Publish' DacpacFile: '$(Build.SourcesDirectory)/data.dacpac' IpDetectionMethod: 'AutoDetect' Helpful Resources: Azure DevOps Overview Azure Pipelines Docs Creating a Web App for Container Creating an Azure Container Registry ","categories": [],
+ "tags": ["dotnet","windows containers"],
+ "url": "https://azure.github.io/AppService/2020/06/25/App-Service-Continuous-Deployment-for-Windows-Containers-with-Azure-DevOps.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "New Log Types for Azure Monitor Integration",
+ "excerpt":"We have recently added two new log types to our preview of App Service’s Integration with Azure Monitor. The two new log types are: AppServiceIPSecAuditLogs AppServicePlatformLogs To learn more about how to set up your Diagnostic Settings, refer to our previous announcement blog post. What are these new logs? AppServiceIPSecAuditLogs (Linux and Windows) This log will show requests made to an web app if there were any IP access restriction rules created. It will provide information such as the host, client IP, result, and the matching rule. This is available for both Linux and Windows web apps. As an example, if a user created an IP rule to only allow access from a certain IP range, and there was a request made to the app from an IP outside of the allowed IP range, the log will show the IP of the request and which rule denied the request. Similar results will show for requests made from allowed IP ranges. At the time of writing, this log type can only be sent to a Storage Account. Future updates will be made to allow this log type to go to Log Analytics. AppServicePlatformLogs (Linux only) This log type shows the output of the Docker commands used to manage your container. If you look at your Linux web app’s file system, the LogFiles directory contains two kinds of log files with the following formats: YYYY_MM_DD_RDXXXXXXXXX_default_docker.log: This is the equivalent of AppServiceConsoleLogs on the file system YYYY_MM_DD_RDXXXXXXXX_docker.log: This is the equivalent of AppServicePlatformLogs on the file system This log will have the contents of the YYYY_MM_DD_RDXXXXXXXX_docker.log. It will contain logs such as starting container for site..., docker run..., output from the docker pull command, etc. Current State of All Logs Types The table below shows the latest availability for the log categories on Windows and Linux. Log type Windows Windows Container Linux Linux Container Description AppServiceConsoleLogs Java SE & Tomcat Yes Yes Yes Standard output and standard error AppServiceHTTPLogs Yes Yes Yes Yes Web server logs AppServiceEnvironmentPlatformLogs Yes N/A Yes Yes App Service Environment: scaling, configuration changes, and status logs AppServiceAuditLogs Yes Yes Yes Yes Login activity via FTP and Kudu AppServiceFileAuditLogs Yes Yes TBA TBA File changes made to the site content; only available for Premium tier and above AppServiceAppLogs ASP .NET ASP .NET Java SE & Tomcat 1 Java SE & Tomcat Blessed Images 1 Application logs AppServiceIPSecAuditLogs Yes Yes Yes Yes Requests from IP Rules AppServicePlatformLogs TBA Yes Yes Yes Container operation logs 1 For Java SE apps, add the app setting WEBSITE_AZMON_PREVIEW_ENABLED and set it to 1 true. ","categories": [],
+ "tags": ["monitoring"],
+ "url": "https://azure.github.io/AppService/2020/06/25/New-Logs-Available-for-Azure-Monitor-Integration.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Zero to Hero with App Service, Part 1: Setting Up",
+ "excerpt":"In times of rapid change, developers and IT decision-makers must quickly adjust to a drastically evolving landscape. Successful organizations use managed cloud services to reduce operating costs by increasing developer efficiency and seize new business opportunities by accelerating delivery of innovation. App Service is a proven, high-productivity Platform-as-a-Service for hosting web apps and mobile backends. The service provides deployment APIs, networking integration, and built-in monitoring. This is the first article in a multi-part series on moving applications to App Service. The series will cover how to continuously deploy your applications, register your site with a custom domain and certificate, securely access other cloud services, and how to properly scale and configure your site. Following this guide will help you get started with App Service and put you on excellent foundation for more advanced uses in the future. Prerequisites You will need an Azure subscription to complete this guide. You can create a subscription for free. Some parts of this blog series will use the Azure CLI. You can install the CLI locally by following this guide, or you can use the Azure Cloud Shell. The Cloud Shell is a virtual terminal associated with your Azure Subscription, allowing you to run Bash or PowerShell commands to create and update Azure resources. You will also need to create a GitHub account if you do not have one already. Once you have a GitHub account, fork one of the repositories below and clone it to your local computer. Make sure you fork the repository. The next article will show how to set up Continuous Integration and Delivery with GitHub Actions. .NET Core Node.js Spring Boot New to Git and GitHub? Click here Create the resources Now that you have an Azure Subscription, the CLI, and the repository, it's time to create the cloud resources we need. First, open the Azure Portal and click Create a Resource in the top-left dropdown. In the menu, select Web App. This will open the blade to create a web app. The form will ask for the following inputs: Resource Group : This is a group for all the resources for your project. Create a new resource group and name it zero_to_hero. Name : The name used for the web app. This name will also be used for the default domain name, so it must be globally unique. Try using your own name and some combination of numbers. For example, john-doe-1. Publish : Leave this as code , since we are deploying application code. App Service also supports deploying Docker containers, which is not covered in this guide. Runtime stack : Choose the runtime based on the repo you cloned earlier. If you chose the .NET Core repo, then you should choose .NET Core 2.1. For Node.js, select Node 12 LTS. For Spring, select Java 8 SE. (If you are following this guide using your own application, choose an appropriate runtime and version for your app.) Region : Select a region close to you or leave this as the default. When you are ready, click Review + create , and complete the creation after reviewing your inputs. The Azure CLI has commands to create and configure your web apps. For more information, see this guide The App Service Plan The App Service Plan represents the underlying Virtual Machine and can host multiple App Services. As you might expect, the higher hardware tiers have more compute resources and features. The plan is also responsible for scaling, which will be covered in a future article. You can always change the hardware tier after creation. Wrapping Up Congratulations! You have created an App Service Plan and a web app. You are one step closer to cloud hero status. In the next article you will set up a Continuous Integration and Delivery pipeline to build and deploy your code onto the web app. If you ran into any issues, please comment on this article. Helpful Resources App Service Plan tiers and pricing information How many sites can I put in an App Service Plan? App Service Documentation App Service Team Blog ","categories": [],
+ "tags": ["zero to hero"],
+ "url": "https://azure.github.io/AppService/2020/06/29/zero_to_hero_pt1.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Zero to Hero with App Service, Part 2: Continuous Integration and Delivery",
+ "excerpt":"This is the second article in our Zero to Hero with App Service series. This article assumes you have completed Part 1. In the last article you created an App Service Plan, a web app, and forked one of the sample applications. In this article, you will set up a Continuous Integration and Delivery (CI/CD) pipeline using GitHub Actions. What is CI/CD? Continuous Integration and Delivery is not specific to App Service or Azure. It is a modern software development best-practice to automate the testing and deployment of your application. App Service integrates directly with GitHub Actions and Azure Pipelines, so setting up CI/CD with App Service is easy. Continuous Integration Continuous Integration is the first step of a CI/CD pipeline. In this phase, the pipeline builds and tests the application. This is usually run for any new pull requests targeting the main tracking branch (formerly known as the master branch). You can also enforce coding style guides or lint the Pull Request during this phase. Continuous Delivery Assuming the application builds correctly and passes the tests, the new build will be automatically deployed (or delivered) to a staging or production server. Advanced development teams may deploy directly to production, but that requires considerable investment in development operations and automated testing. Teams that are just starting with CI/CD can deploy their builds to a staging environment that mirrors production, then manually release the new build once they feel confident. In the next article, you will learn how to route a percentage of your production traffic to a staging environment to test your new build with “real” traffic. Create a Staging Environment App Service allows you to create and delete independent staging environments, known as slots. You can deploy code or containers to a slot, validate your new build, then swap the staging slot with your production slot. The swap will effectively release the new build to your users. Using the CLI command below, create a staging slot. You will need to replace the <name> parameter with the web app’s name from the previous article. az webapp deployment slot create --slot staging -n <name> -g zero_to_hero Staging slots also get their own default domain names. The domain name follows a similar pattern as the production slot, http://mycoolapp.azurewebsites.net except the slot name is appended to the app’s name: http://mycoolapp-staging.azurewebsites.net. Learn more about best practices for App Service staging slots. Create a CI/CD Pipeline Next, you will create a CI/CD pipeline to connect your GitHub repository to the staging slot. App Service has built-in integration with GitHub Actions and Azure Pipelines. Since the sample apps are hosted in GitHub repos, we will use GitHub Actions for our pipeline. About GitHub Actions GitHub Actions is an automation framework that has CI/CD built in. You can run automation tasks whenever there is a new commit in the repo, a comment on a pull request, when a pull request is merged, or on a CRON schedule. Your automation tasks are organized into workflow files, which are YAML files in the repository’s .github/workflows/ directory. This keeps your automation tasks tracked in source control along with your application code. The workflow file defines when the automation is executed. Workflows consist of one or more jobs , and jobs consist of one or more steps. The jobs define the operating system that the steps are executed on. If you are publishing a library and want to test it on multiple operating systems, you can use multiple jobs. The steps are the individual automation tasks, you can write your own or import actions created by the GitHub community. An example “Hello World” workflow file is shown below. It runs any time there is a push to the repository and prints “Hello Keanu Reeves” with the current time. If you read the YAML carefully, you can see how the last step references the output from the earlier “Hello world” command using the dotted syntax. name: Greet Everyone on: [push] # This workflow is triggered on pushes to the repository. jobs: build: name: Greeting # Job name is Greeting runs-on: ubuntu-latest # This job runs on Linux steps: # This step uses GitHub's hello-world-javascript-action: https://github.com/actions/hello-world-javascript-action - name: Hello world uses: actions/hello-world-javascript-action@v1 with: who-to-greet: 'Keanu Reeves' id: hello # This step prints an output (time) from the previous step's action. - name: Echo the greeting's time run: echo 'The time was $.' Learn more about the GitHub Actions terms and concepts. Create the Pipeline In the Azure Portal, find and click the App Service you created in the previous article. Once you have the App Service open in the portal, select Deployment Center on the left side under the Deployment header. This will open the App Service Deployment Center. The deployment center will guide you through the CI/CD setup process. Next, select GitHub and click Continue at the bottom. In the following page, select GitHub Actions (Preview) and click Continue at the bottom. In the next screen, select your repository using the dropdowns. (You do not need to edit the language and language version dropdowns.) On the final page you will see a preview of the GitHub Actions workflow file that will be committed into your repository. Click Complete to commit the workflow file to the repository. This commit will also trigger the workflow. Learn more about GitHub Actions and Azure Pipelines integration with App Service. Check the Pipeline’s Progress If you go to your GitHub repository you will see a new file in the .github/workflows/ directory on the master branch. Click on the Actions tab in the GitHub repository to see a historical view of all previous GitHub Actions runs. Once the workflow run completes, browse to your staging slot to confirm that the deployment was successful. Summary Congratulations! You now have a CI/CD pipeline to continuously build and deploy your app to your staging environment. In the next article you will learn how to swap the staging and production slots to release new builds to your production users. The next article will also explain how to route a small percentage of your users to a staging slot so you can validate new builds against production traffic or do A/B testing. Helpful resources Using GitHub Actions to deploy a Windows Container to App Service GitHub Workflows to create and delete a slot for Pull Requests ","categories": [],
+ "tags": ["zero to hero"],
+ "url": "https://azure.github.io/AppService/2020/06/29/zero_to_hero_pt2.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Zero to Hero with App Service, Part 3: Releasing to Production",
+ "excerpt":" This is the third article in the Zero to Hero with App Service series. This article assumes you have already completed the previous two articles. At this point, you have a CI/CD pipeline built on GitHub Actions that deploys your code into a staging slot whenever a commit is pushed to the main branch. In this article, you will learn how to release your new build to your production traffic by swapping the production and staging slots. You will also learn how to route a percentage of your production traffic to the staging environment to test the next build before it is fully released. Swap the slots Open the Azure Portal to your web app. On the left side menu, select Deployment slots. This will open a new blade showing a list of your site’s slots. You will see a production and staging slot. Click the Swap button at the top. The Swap button will open a context menu with a table to preview any changes configuration changes that will occur after the swap. App settings are key-value configurations that are exposed to your app as environment variables. A future article will cover app settings in more detail. Click swap at the bottom of the menu to swap the slots. When the operation completes, browse to the production site and you should see the sample application! The staging slot should now have the sample application, and the staging slot will have the placeholder HTML page with help text. You can also use slots with custom containers. Checkpoint Up to now, you have a GitHub repository that will trigger a GitHub Action workflow whenever there is a push to the main branch. The workflow builds and deploys the application to the staging slot of the site. You can use the staging site to validate your latest changes. When you’re ready, use the swap button (or CLI command) to swap the slots. If you work in a large team, you can create slots for testing, quality assurance, canary testing, A/B testing, and more. Here is an example use case for multiple slots: Continuously deploy the master branch into a “testing” slot for developers to easily validate changes without pulling the branch and run it locally. Swap the build into a QA slot where the configuration more closely resembles the production slot. The new build is thoroughly tested by a QA or acceptance team. Swap into a staging slot where the build is tested against a fraction of the production traffic. The configuration here should match the production slot. Fully release the new build by swapping into the production slot. There is an implicit distinction between deploying and releasing. For more information on this distinction, see this article. Testing in Production Testing in Production is the general practice of utilizing production traffic to test a new deployment before fully releasing it. This is an umbrella term for activities such as traffic shadowing, mirroring, or canarying. Traffic shadowing and mirroring are interesting topics, but they are outside the scope of this article. The remaining sections will explain how to canary your new deployments with App Service before releasing them to production. Configuration In the Azure Portal, go to the Deployment Slots menu. In the table of your slots, you will see a column for Traffic %. By default, all your traffic is routed to the production slot. Try setting the traffic percentage to 10% on the staging slot. Then click Save. With that simple change, a tenth of your production traffic will now go to the new build! This practice is known as a “canary deployment” or “canarying a build”. The term “canary deployment” originates from the “canary in a coal mine” idiom. Tagging telemetry Now that some of your production traffic is routed to the new build, it is prudent to monitor the success of your deployment to catch errors, slow code paths, or other unforeseen issues. If you are using an application monitoring tool like Application Insights, Splunk, or Dynatrace, you will want to tag the metrics and logs coming from your staging slot so you can appropriately split the data in your reports and dashboards. For your client-side code, the slot will expose a cookie, x-ms-routing-name, with the slot’s name. You can retrieve this cookie and tag any outgoing metrics or logs. In your monitoring service’s dashboard, you can filter or split the data on this tag. For server-side code, the slot will expose an environment variable, WEBSITE_HOSTNAME, which contains the hostname and slot name. Much like the client-side cookie, you can grab the value of the environment variable and tag your logs or metrics. You can manually route clients to a slot using the x-ms-routing-name query parameter. Summary Congratulations! Now you know how to release your latest deployments. You can also route a percentage of your production traffic to canary test the new build before fully releasing it. The next articles will cover certificates, domains, network security, and advanced configuration… so stay tuned for more! Helpful Links Testing in Production, the safe way Best Practices for App Service deployment slots ","categories": [],
+ "tags": ["zero to hero"],
+ "url": "https://azure.github.io/AppService/2020/07/07/zero_to_hero_pt3.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Certificate Authorities revoking non-compliant certificates, potentially impacting your App Service",
+ "excerpt":"If you have received a notification from Azure about potentially being impacted by the certificate revocation issue, follow these steps to avoid application interruption. Certificate Authority (CA) Browser forum recently published reports of multiple certificates issued by CA vendors that are used by our customers, Microsoft, and the greater technology community that were out-of-compliance with industry standards for publicly trusted CAs. The reports regarding the non-compliant CAs can be found here: Bug 1649951 Bug 1650910 As per the industry’s compliance requirements, CA vendors began revoking non-compliant CAs and issuing compliant CAs. This requires customers to have their certificates re-issued. Microsoft is partnering closely with these vendors to minimize the potential impact to Azure Services. However, your self-issued certificates or certificates used with “Bring Your Own Certificate” (BYOC) are still at risk of being unexpectedly revoked. If you have been notified about using a self-acquired certificate or using the BYOC feature on App Service that is potentially impacted by this issue, check if certificates utilized by your application have been revoked by referencing DigiCert’s Announcement and the Certificate Revocation Tracker. New certificates need to be requested from the CA vendor utilized in your applications. NOTE: This issue will not affect App Service Managed Certificates Avoiding Application Interruptions To avoid your application’s availability being interrupted due to certificates being unexpectedly revoked, or to update a certificate which has been revoked, follow the steps below: Reissue your certificate (contact your certificate provider for more information). Once your new certificate has been reissued, add the new certificate to your web app by either uploading the new certificate to your web app or by updating the new certificate in your Key Vault Once you have added your certificate to your web app, you will need to update your bindings refer to the next section. How to safely update your bindings Certificate Imported from Key Vault to App Service If you are importing your certificate from Key Vault, App Service has a background job that will automatically update your bindings with the new version of your certificate within 48 hours. If you’re using Key Vault and you would like to immediately update your bindings and not wait for the background job, follow these steps below: NOTE: If you are using IP SSL bindings – *do not delete* your bindings as your inbound IP can change. It is recommended to wait for the platform’s background job to update the bindings with the new version of your certificate to avoid losing your IP address. Upload the new certificate in Key Vault using a new certificate name Import the new certificate to your web app Update your binding Delete the old certificate from App Service Certificate Uploaded to App Service If you are uploading a certificate to your app web, you will need to update the bindings with your new certificate following the steps below: Note: If you are using IP SSL bindings – *do not delete* your bindings as your IP inbound IP can change. Instead you must only *update* the IP SSL bindings. Upload the new certificate to your web app Update your binding Delete the old certificate from App Service Updating bindings Through Azure Portal On Azure portal, go to “TLS/SSL settings” under “Settings” on the left navigation of your resource, select the binding you would like to update, and look for the new certificate from the dropdown. Through Scripts Refer to the documentation on sample scripts for Azure CLI and Powershell Note: You can run “New-AzWebAppSSLBinding” to add the new certificate to the existing hostname Refer to the blog to rotate you certificates with Key Vault using ARM ","categories": ["certsdomains"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2020/07/14/Cert-Revoke.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Zero to Hero with App Service, Part 4: Migrate Applications to Azure App Service",
+ "excerpt":"In this installment of Zero to Hero with App Service, learn how to migrate your existing applications to App Service. If you followed parts one, two, and three then you already have an application on App Service, and you can continue to the next article. Overview There are multiple ways to migrate a web application to Azure App Service: Redeploy code using CI/CD Pipelines, Web Deploy, or the REST APIs Containerize your web application and deploy from a container registry Use App Service Migration Assessment Tool to migrate your ASP.NET, PHP web applications and Linux containers App Service Migration Assessment Tool assesses whether your web site can be moved to Azure App Service. If your web site is public, you can simply provide your URL on this website to run the assessment. You can also download and run the assistant if your web site is hosted in a private environment. Post assessment App service Migration Assessment tool allows quick and easy migration of ASP.NET and PHP web applications running on IIS, and containerized web applications running on Linux operating systems to Azure App Service. Step by Step Guidance Please refer to Test Deployment and Migration Instructions for step-by-step instructions on migrating a sample ASP.NET web application to Azure App Service. You can also refer to the Microsoft learn module for more information on how to migrate an on-premises web application App Service. How the Tool Works Online assessment of publicly accessible web application using https://appmigration.microsoft.com/assessment Tool based assessment of internal web applications using the version of tool available for Windows OS and Linux OS. (Download the tool at https://appmigration.microsoft.com/readiness) Based on outcome of assessment (readiness checks) you may proceed further to migrate your web application to Azure App service using App Service Migration Assessment Tool Please read How the Assistant Works for detailed information. Readiness Checks The App Service Migration Assessment Tool runs multiple readiness checks. The results of the readiness checks are used to decide if your app can migrate to Azure App Service. A comprehensive list of the checks is shown below. IIS Server Site Checks Port Bindings Protocol Certificates Location Tags ISAPI Filters Application Pools Application Pool Identity Authentication Type Application Settings Connection Strings Framework Virtual Directories For detailed information on readiness checks and possible remediation steps, see this article. Linux Container Checks Linux Platform Container Volume Exposed Ports HTTP Traffic Please read Linux Container Checks for detailed information on readiness checks and possible remediation steps. Database Migration and Hybrid Connections App Service Migration Assistant migrates the web application and associated configurations only, it does not migrate databases. There are multiple ways to migrate databases to Azure. Some options are listed below. Use the SQL Server Migration Guidance Use Azure Database Migration Service Your web application on Azure App service can also connect to an existing, on-premises database using Hybrid Connections. Hybrid Connections allow your web application to securely access resources in other networks – in this case, an on-premises database. The migration tool configures and sets up Hybrid Connections for you, allowing you to migrate your site while keeping your database on-premises. You can then migrate your database later. Azure Migrate Hub Integration Azure Migrate provides a centralized hub to assess and migrate on-premises servers, infrastructure, applications, and data. The Migration assessment tool allows you to sync assessment data with Azure Migrate Hub for both successful migrations and migrations with blockers. Summary Using these resources, you can easily assess the migration feasibility of your .NET, PHP, and Linux containers. Once your migration assessment is complete, use the assistant's step-by-step instructions to complete the migration to App Service. For more information, see the links below. Helpful Resources App Service Migration Assistant Tool Website Migration checklist when moving to Azure App Service Linux Notes Release Notes Known Issues Azure CLI ","categories": [],
+ "tags": ["zero to hero"],
+ "url": "https://azure.github.io/AppService/2020/07/20/zero_to_hero_pt4.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "PHP Minor Version Update for August 2020",
+ "excerpt":"Latest version updates to PHP In August 2020, Azure App Service will update the PHP Windows stacks to the latest available versions. For information on the changes in the new versions, please see the change logs on the PHP website. PHP Version Change Log 7.2.31 http://www.php.net/ChangeLog-7.php#7.2.31 7.3.19 http://www.php.net/ChangeLog-7.php#7.3.19 7.4.7 http://www.php.net/ChangeLog-7.php#7.4.7 ","categories": [],
+ "tags": ["PHP"],
+ "url": "https://azure.github.io/AppService/2020/07/26/PHP-Minor-Version-Update-for-August-2020.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Zero to Hero with App Service, Part 5: Add and Secure a Custom Domain on Your Azure App Service Web App",
+ "excerpt":"This article is the fifth part of the Zero to Hero with App Service series. This article assumes you have completed the first article. If you would like to customize your web app with a domain name other than “azurewebsites.net”, you can add a custom domain to your web app. Moreover, you can secure your custom domain with a free certificate from App Service Managed Certificates, which will give your customers peace of mind when browsing your website. Prerequisite Before you can add a custom domain to your web app, you need to have purchased a custom domain already. If you don’t have a custom domain, you can buy one through App Service Domains, which you can get started with the App Service Domain section of the article. If you already have your own custom domain, proceed to the adding of custom domain to your web app section of the article. App Service Domains App Service Domains lets you create and manage domains hosted on Azure DNS through the Azure portal. The domain can be used for services such as Web Apps, Traffic Manager, and etc.. Purchasing an App Service Domain also provides the added benefit of privacy protection: your personal data will be protected from the WHOIS public database for free. This is often costs extra with other domain registrars. This product can auto-renew your domains and it integrates easily with your web apps. To create your App Service Domain, you can click on this link here or you can head to the Azure portal and search for “App Service Domain”. In the domain search bar, type the domain name you would like to purchase. If you don’t see the name in the list of available domains, then the domain isn’t available for purchase. However, you can choose from the suggested list of available domains or enter a new domain you would like to purchase. In the “Contact information” tab, enter your personal information. Then in the “Advanced” tab, choose whether you want to set up auto-renew for the domain. Domain auto-renew prevents accidental loss of domain ownership after expiration. Lastly, decide whether you would like to add privacy protection at no extra charge. Go to “Review + create” to review the legal terms, verify the domain information, and click “Create”. Once your domain has successfully been created, you can now add your custom domain to your web app. Adding a custom domain to your web app To add a custom domain to your web app, you will need to update your domain’s DNS records. If you purchased an App Service Domain, the DNS records will be updated for you automatically and you can proceed to verifying and adding custom domain. Otherwise, you will need to update your DNS records. Updating DNS records You will need to get the custom domain verification ID of your web app.\tThis token will be used to verify the domain ownership. You can get this value in the “Custom domains” tab of your web app. Once you have the ID, go to the domain provider of your domain. In the DNS records, create a CNAME and a TXT Record. As an example, if you want to map your ‘www’ subdomain, refer to the chart below: Record Type Host Value CNAME www .azurewebsites.net TXT asuid.www Custom Domain Verification ID Your DNS records page should look something like the following example: Verifying and adding custom domain After updating your DNS records (if not using App Service Domain): Go to your App Service and navigate to the “Custom domain” section under “Settings”. Click on the “Add custom domain” button Enter the domain that you would like to use Click “Validate” If you correctly updated your DNS records and the DNS changes have propagated, you will see the option to “add custom domain”. Otherwise, return to the previous section to make sure that you have updated your DNS records properly. Click “add custom domain”. Once the custom domain has successfully been added to your web app, you will see it under the list of “Assigned Custom Domains”. You can navigate to your web app using these domain names. If you are interested in securing your custom domain, proceed to the following section on Creating an App Service Managed Certificate. Creating an App Service Managed Certificate If you would like to secure your custom domain at no cost, you can create an App Service Managed Certificate and bind it to your domain. With Managed Certificates, you don’t have to worry about renewals, as the certificate is automatically renewed for you! Go to your web app resource and navigate to the “TLS/SSL settings” section under “Settings” Click on the “Private Key Certificates” blade Click the “Create App Service Managed Certificate” button Select the domain from the dropdown menu that you would like to create a certificate for and click “Create”. Once the certificate has been created, you will see that it in the list of your private certificates on the “TLS/SSL Settings” blade. In order to use this certificate to secure your domain, you will need to bind this certificate to your domain, which will be explained in the next section of binding your certificate to your web app. Binding Your Certificate to Your Web App The final step to securing your domain is to bind your certificate to the domain. In the Portal, go to your web app and navigate to the “Custom domain” section under “Settings”. Look for the domain you want to secure from the list of “Assigned Custom Domains” and click “Add binding”. In the following blade… Select the correct custom domain Select the App Service Managed Certificate you’ve just created from the dropdown menu Select “SNI SLL” for the TLS/SSL Type Click “Add Binding” Once the binding has successfully been created, you will see a green checkmark and the word “Secure” beside your custom domain under the “Assigned Custom Domains” list. Summary Congratulations! In this article, you have successfully added and secured a custom domain for your App Service! Your users can now reach your web site at the new domain, and their browser will let them know that the site is secured. Helpful Resources Tutorial: Map an existing custom DNS name to Azure App Service Add a TLS/SSL certificate in Azure App Service ","categories": [],
+ "tags": ["zero to hero"],
+ "url": "https://azure.github.io/AppService/2020/07/28/zero_to_hero_pt5.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "A/B Testing with App Service, Part 1: Client-side configuration",
+ "excerpt":"In software development, A/B testing is the process of comparing two versions of a webpage or application to determine which version improves a metric or KPI. Depending on your role, there a few reasons why you should start A/B testing your applications. A frontend developer can test if a refactor improves page load time under real-world conditions A backend developer can deploy two versions of an API to determine any performance gains of a new implementation A designer can check if a new UI layout improves usability metrics A product manager can test different product landing pages to see how different value propositions affect click-through and average time-on-page A/B testing is a powerful technique for software professionals of all types, but it is not without its complexities. For example, how does one deploy two versions of the application? How is user traffic split between the versions? And most importantly… how is the data tracked, tagged, and analyzed? This blog series will show how to accomplish all these tasks. This first article explains how to instrument your client-side code with a monitoring agent and tag the metrics with the version. The following articles will show how to instrument your backend services and how to analyze the results. Have any thoughts about this guide? Let us know in the comments below! Overview To do A/B testing with App Service, we will use App Service’s deployment slots and Application Insights. Deployment slots allow developers to deploy their new application builds to independent staging environments. Once a new build is deployed to a slot, you can route a percentage of your production traffic to the slot. Once the traffic is split, Application Insights will capture usage and performance metrics tagged with the slot name. The Application Insights blade in the Portal allows you to filter, visualize, and compare data from the different versions. Prerequisites You will need to have an Azure Subscription and an App Service before starting this guide. You should also have CI/CD (Continuous Integration and Delivery) set up for the App Service. All these steps are covered in parts one, two, and three of our Zero to Hero with App Service series. Please refer to those articles to create an App Service and set up CI/CD. Once you have that set up, continue to the next section to create an App Insights resource. Create an Application Insights Resource Application Insights is a Application Performance Management (APM) service for client-side and backend apps. App Insights (AI) has SDKs for JavaScript, .NET, Java, Python, Node, and more. You will use AI to capture metrics, tag the data, and analyze the results. Create an App Insights resource in the Portal by following these instructions. If you prefer using the Azure CLI, you can run the following command instead. Replace <name> and <group> with your desired name for the AI resource, and name for the resource group. az extension add -n application-insights az monitor app-insights component create --app <name> -resource-group <group> --location westus2 Once the AI resource is created, copy the instrumentation key from the Portal or CLI output. You will need this key in the next section. You may need to update your Azure CLI to install the application-insights module. Install Application Insights You will now add App Insights to your client-side code. Jump to the section for your app’s frontend framework. React App Insights has purpose-built plugins for React and React Native. Follow the linked instructions to add the plugins to your React project. Vue.js The Vue.js community has created a wrapper for App Insights to register it as a Vue plugin, vue-app-insights. You can install the package with npm install vue-application-insights --save. Once the package is installed, register it as a plugin on the root Vue instance (this is usually in your main.js file). An example is shown below. import Vue from 'vue' import router from './router'; import VueAppInsights from 'vue-application-insights'; Vue.use(VueAppInsights, { id: 'da2fab5d-c6fb-4688-8823-303dda0c7ad6', router }) Since Vue is a framework for Single Page Applications (SPA’s), the snippet above also passes the Vue router to App Insights so that it can record view changes as proper page views. Other JS Frameworks If you are using a different JavaScript framework, you can install the Application Insights SDK using NPM, as shown below. npm i --save @microsoft/applicationinsights-web Once the package is installed, declare the App Insights object and provide your instrumentation key from the previous section. import { ApplicationInsights } from '@microsoft/applicationinsights-web' const appInsights = new ApplicationInsights({ config: { instrumentationKey: 'YOUR_INSTRUMENTATION_KEY_GOES_HERE'; /* ...Other Configuration Options... */ } }); appInsights.loadAppInsights(); appInsights.trackPageView(); // Manually call trackPageView to establish the current user/session/pageview Next, you will need to register this object with your chosen framework. Most client-side frameworks provide an initialization hook where you can register objects with the root object or module. For Angular apps, follow this blog guide. For Ember.js, you can register the appInsights object in the Application Instance Initializer. Configurations for all other frameworks are left as an exercise to the reader. HTML Templates If you are using an HTML template engine (like Django, Thymeleaf, or Jekyll) add the following <script> snippet to the <head> of your base template. This will add AI to each of your app’s web pages. <script type=\"text/javascript\"> !function(T,l,y){var S=T.location,u=\"script\",k=\"instrumentationKey\",D=\"ingestionendpoint\",C=\"disableExceptionTracking\",E=\"ai.device.\",I=\"toLowerCase\",b=\"crossOrigin\",w=\"POST\",e=\"appInsightsSDK\",t=y.name||\"appInsights\";(y.name||T[e])&&(T[e]=t);var n=T[t]||function(d){var g=!1,f=!1,m={initialize:!0,queue:[],sv:\"4\",version:2,config:d};function v(e,t){var n={},a=\"Browser\";return n[E+\"id\"]=a[I](),n[E+\"type\"]=a,n[\"ai.operation.name\"]=S&&S.pathname||\"_unknown_\",n[\"ai.internal.sdkVersion\"]=\"javascript:snippet_\"+(m.sv||m.version),{time:function(){var e=new Date;function t(e){var t=\"\"+e;return 1===t.length&&(t=\"0\"+t),t}return e.getUTCFullYear()+\"-\"+t(1+e.getUTCMonth())+\"-\"+t(e.getUTCDate())+\"T\"+t(e.getUTCHours())+\":\"+t(e.getUTCMinutes())+\":\"+t(e.getUTCSeconds())+\".\"+((e.getUTCMilliseconds()/1e3).toFixed(3)+\"\").slice(2,5)+\"Z\"}(),iKey:e,name:\"Microsoft.ApplicationInsights.\"+e.replace(/-/g,\"\")+\".\"+t,sampleRate:100,tags:n,data:{baseData:{ver:2}}}}var h=d.url||y.src;if(h){function a(e){var t,n,a,i,r,o,s,c,p,l,u;g=!0,m.queue=[],f||(f=!0,t=h,s=function(){var e={},t=d.connectionString;if(t)for(var n=t.split(\";\"),a=0;a<n.length;a++){var i=n[a].split(\"=\");2===i.length&&(e[i[0][I]()]=i[1])}if(!e[D]){var r=e.endpointsuffix,o=r?e.location:null;e[D]=\"https://\"+(o?o+\".\":\"\")+\"dc.\"+(r||\"services.visualstudio.com\")}return e}(),c=s[k]||d[k]||\"\",p=s[D],l=p?p+\"/v2/track\":config.endpointUrl,(u=[]).push((n=\"SDK LOAD Failure: Failed to load Application Insights SDK script (See stack for details)\",a=t,i=l,(o=(r=v(c,\"Exception\")).data).baseType=\"ExceptionData\",o.baseData.exceptions=[{typeName:\"SDKLoadFailed\",message:n.replace(/\\./g,\"-\"),hasFullStack:!1,stack:n+\"\\nSnippet failed to load [\"+a+\"] -- Telemetry is disabled\\nHelp Link: https://go.microsoft.com/fwlink/?linkid=2128109\\nHost: \"+(S&&S.pathname||\"_unknown_\")+\"\\nEndpoint: \"+i,parsedStack:[]}],r)),u.push(function(e,t,n,a){var i=v(c,\"Message\"),r=i.data;r.baseType=\"MessageData\";var o=r.baseData;return o.message='AI (Internal): 99 message:\"'+(\"SDK LOAD Failure: Failed to load Application Insights SDK script (See stack for details) (\"+n+\")\").replace(/\\\"/g,\"\")+'\"',o.properties={endpoint:a},i}(0,0,t,l)),function(e,t){if(JSON){var n=T.fetch;if(n&&!y.useXhr)n(t,{method:w,body:JSON.stringify(e),mode:\"cors\"});else if(XMLHttpRequest){var a=new XMLHttpRequest;a.open(w,t),a.setRequestHeader(\"Content-type\",\"application/json\"),a.send(JSON.stringify(e))}}}(u,l))}function i(e,t){f||setTimeout(function(){!t&&m.core||a()},500)}var e=function(){var n=l.createElement(u);n.src=h;var e=y[b];return!e&&\"\"!==e||\"undefined\"==n[b]||(n[b]=e),n.onload=i,n.onerror=a,n.onreadystatechange=function(e,t){\"loaded\"!==n.readyState&&\"complete\"!==n.readyState||i(0,t)},n}();y.ld<0?l.getElementsByTagName(\"head\")[0].appendChild(e):setTimeout(function(){l.getElementsByTagName(u)[0].parentNode.appendChild(e)},y.ld||0)}try{m.cookie=l.cookie}catch(p){}function t(e){for(;e.length;)!function(t){m[t]=function(){var e=arguments;g||m.queue.push(function(){m[t].apply(m,e)})}}(e.pop())}var n=\"track\",r=\"TrackPage\",o=\"TrackEvent\";t([n+\"Event\",n+\"PageView\",n+\"Exception\",n+\"Trace\",n+\"DependencyData\",n+\"Metric\",n+\"PageViewPerformance\",\"start\"+r,\"stop\"+r,\"start\"+o,\"stop\"+o,\"addTelemetryInitializer\",\"setAuthenticatedUserContext\",\"clearAuthenticatedUserContext\",\"flush\"]),m.SeverityLevel={Verbose:0,Information:1,Warning:2,Error:3,Critical:4};var s=(d.extensionConfig||{}).ApplicationInsightsAnalytics||{};if(!0!==d[C]&&!0!==s[C]){method=\"onerror\",t([\"_\"+method]);var c=T[method];T[method]=function(e,t,n,a,i){var r=c&&c(e,t,n,a,i);return!0!==r&&m[\"_\"+method]({message:e,url:t,lineNumber:n,columnNumber:a,error:i}),r},d.autoExceptionInstrumented=!0}return m}(y.cfg);(T[t]=n).queue&&0===n.queue.length&&n.trackPageView({})}(window,document,{ src: \"https://az416426.vo.msecnd.net/scripts/b/ai.2.min.js\", // The SDK URL Source //name: \"appInsights\", // Global SDK Instance name defaults to \"appInsights\" when not supplied //ld: 0, // Defines the load delay (in ms) before attempting to load the sdk. -1 = block page load and add to head. (default) = 0ms load after timeout, //useXhr: 1, // Use XHR instead of fetch to report failures (if available), //crossOrigin: \"anonymous\", // When supplied this will add the provided value as the cross origin attribute on the script tag cfg: { // Application Insights Configuration instrumentationKey: \"YOUR_INSTRUMENTATION_KEY_GOES_HERE\" /* ...Other Configuration Options... */ }}); </script> More information on the snippet-based setup can be found here. Tag the telemetry You now have AppInsights installed. However, the outgoing data needs to be tagged with the slot name so you can correctly filter and analyze the data in the Portal. To do this, add a TelemetryInitializer to your project and register it with the AI object. The telemetry intializer below will get the name of the slot from the x-ms-routing-name cookie and add it as a property on the outgoing data object. NPM-based applications If you are using React, Angular, Vue, or another NPM-based framework, copy and paste the following method definitions into your project. /** * Tags the outgoing telemetry with the slot name taken from the cookie. * @param {object} envelope The outgoing AI telemetry object */ var telemetryInitializer = (envelope) => { const environment = getCookieValue('x-ms-routing-name') || 'production'; envelope.data['slot'] = environment; } /** * Returns the value of the specified cookie. If the cookie cannot be found, returns null; * @param {string} key The key of the cookie */ export function getCookieValue(key) { const cookie = document.cookie .split('; ') .find(cookie => cookie.startsWith(key)); return cookie ? cookie.split('=')[1] : null; } Finally, register the telemetryInitializer method with the AppInsights instance. appInsights.addTelemetryInitializer(telemetryInitializer); Snippet-based applications If you installed App Insights using the HTML snippet from the previous section, you will need to add the following <script> to your root HTML template. This script will add the TelemetryInitializer and register it with App Insights. This script should be pasted after the script that installs App Insights. <script> function getCookieValue(key) { const cookie = document.cookie .split('; ') .find(cookie => cookie.startsWith(key)); return cookie ? cookie.split('=')[1] : null; } var telemetryInitializer = (envelope) => { const environment = getCookieValue('x-ms-routing-name') || 'production'; envelope.data['slot'] = environment; } appInsights.addTelemetryInitializer(telemetryInitializer); </script> Deploy and split traffic Your client-side code is now instrumented with App Insights and will tag any outgoing telemetry with the slot’s name. Now all that is left to do is deploy the application. If you followed parts two and three of Zero to Hero with App Service, then you can simply commit your changes to the master branch and let the CI/CD pipeline deploy the new build to your staging slot. Once your instrumented code is deployed to the staging slot, it is time to start routing some production traffic to the staging slot. In the Azure Portal, go to the Deployment Slots menu. In the table of your slots, you will see a column for Traffic %. By default, all your traffic is routed to the production slot. Try setting the traffic percentage to 10% on the staging slot. Then click Save. With that simple change, a tenth of your production traffic will now go to the new build! (Optional) Deploy PR’s to staging slots To do A/B testing with App Service, you need at least two slots: production and staging (which map to the A and B versions). However, you can also spin up a staging slot for Pull Requests to your main tracking branch. This allows your teammates to see the requested changes deployed to a staging server and makes it easy to try the changes live. Even more powerful, you can route a percentage of your traffic to these deployed PR’s as well. You can set up the automation for this process using GitHub Actions. It requires two workflow files: one to create the slot and deploy the Pull Request contents, and another to delete the slot once the PR has been closed. We put together example workflows for this, check them out in this repository. Summary In this article, you instrumented your client-side code or HTML templates. In the next article you will instrument your backend code. We are considering building this functionality into the default behavior of the App Insights SDK (so you don’t have to create your own TelemetryInitializer). If you have thoughts on this guide, please comment below and share! Your input will help us improve this whole story. ","categories": ["deployment"],
+ "tags": ["A/B Testing"],
+ "url": "https://azure.github.io/AppService/2020/08/03/ab_testing_app_service.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Disabling basic auth on App Service",
+ "excerpt":"App Service provides access for FTP and WebDeploy clients to connect using the basic auth credentials found in the site’s publish profile. These APIs are great for browsing your site’s file system, uploading drivers and utilities, and deploying with MsBuild. However, enterprises often need to meet security requirements and would rather disable this basic auth access, so that employees can only access the organization’s App Services through API’s that are backed by Azure Active Directory (AAD). This article shows how to disable basic authorization, monitor any attempted or successful logins, and how to use Azure Policy to ensure any new sites have basic authentication disabled. Also, the API to disable or enable basic auth is backed by AAD and RBAC, so you can narrow which users or roles are able to re-enable basic auth for a site. Disabling Access The following sections assume you have owner-level access to the site. The corresponding CLI commandlet is under development at the time of writing. FTP To disable FTP access to the site, run the following CLI command. Replace the placeholders with your resource group and site name. az resource update --resource-group <resource-group> --name ftp --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<site-name> --set properties.allow=false Once you have replaced the placeholders, select the text and press Ctrl + S (for Send). On the right side panel, you can see the response code and body. To confirm that FTP access is blocked, you can try to authenticate using an FTP client like FileZilla. To retrieve the publishing credentials, go to the overview blade of your site and click Download Publish Profile. Use the file’s FTP hostname, username, and password to authenticate, and you will get a 401 Unauthenticted. WebDeploy and SCM To disable basic auth access to the WebDeploy port and SCM site, run the following CLI command. Replace the placeholders with your resource group and site name. az resource update --resource-group <resource-group> --name scm --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<site-name> --set properties.allow=false To confirm that the publish profile credentials are blocked on WebDeploy, try publishing a web app using Visual Studio 2019. Create a custom RBAC role The API in the previous section is backed Azure Role-Based Access Control (RBAC), which means you can create a custom role to block users from using the API and assign lower-priveldged users to the role so they cannot enable basic auth on any sites. To configure the custom role, follow the instructions below. Open the Azure portal Open the subscription that you want to create the custom role in On the left navigation panel, click Access Control (IAM) Click + Add and click Add custom role in the dropdown Provide a name and description for the role. For Baseline permissions you can clone one of your organization’s existing roles, or one of the default roles Click the Permissions tab, and click Exclude permissions In the context blade, click the Microsoft Web Apps. This will open a list of all the RBAC actions for App Service Search for the microsoft.web/sites/basicPublishingCredentialsPolicies/ftp and microsoft.web/sites/basicPublishingCredentialsPolicies/scm operations. Under these, check the box for Write. This will add the actions as NotActions for the role. You can disable this for slots as well. See the microsoft.web/sites/slots/basicPublishingCredentialsPolicies/ftp and microsoft.web/sites/slots/basicPublishingCredentialsPolicies/scm actions Click Review + create at the bottom. Under Permissions, you will see the basicPublishingCredentialsPolicies APIs listed as NotActions. Finally, click Create. You can now assign this role to your organization’s users. More information on setting up custom RBAC roles. Audit with Azure Monitor All successful and attempted logins are logged to the Azure Monitor AppServiceAuditLogs log type. This means you can use all of Azure Monitor’s features to store, query, and alert based on the log contents. Pricing information for Azure Monitor features and services. To audit the attempted and successful logins on FTP and WebDeploy, click the Diagnostic Settings tab on your web app. This will open a blade to select your desired log types, and the destination for the logs. The logs can be sent to Log Analytics, a Storage Account, or an Event Hub. Provide a name for the Diagnostic Setting Select the log types you want to capture Select the services you want to send the logs to. (The service(s) must already be created, you can’t create them from this blade.) Click Save. To confirm that the logs are sent to your selected service(s), try logging in via FTP or WebDeploy. An example Storage Account log is shown below. { \"time\": \"2020-07-16T17:42:32.9322528Z\", \"ResourceId\": \"/SUBSCRIPTIONS/EF90E930-9D7F-4A60-8A99-748E0EEA69DE/RESOURCEGROUPS/FREEBERGDEMO/PROVIDERS/MICROSOFT.WEB/SITES/FREEBERG-WINDOWS\", \"Category\": \"AppServiceAuditLogs\", \"OperationName\": \"Authorization\", \"Properties\": { \"User\": \"$freeberg-windows\", \"UserDisplayName\": \"$freeberg-windows\", \"UserAddress\": \"24.19.191.170\", \"Protocol\": \"FTP\" } } Enforce compliance with Azure Policy Azure Policy can help you enforce organizational standards and to assess compliance at-scale. Using Azure Policy, you can define JSON-formatted policies to alter or deny the creation of Azure services. In this scenario, you can use Azure Policy to audit for any sites which have basic authentication disabled, and remediate any non-compliant resources. Azure has built-in policies for auditing and remediating basic authentication on App Service: Audit policy for FTP Audit policy for SCM Remediation policy for FTP Remediation policy for SCM There are corresponding policies for slots as well: Audit policy for FTP Audit policy for SCM Remediation policy for FTP Remediation policy for SCM Summary In this article you learned how to disable basic authentication to the FTP and WebDeploy ports for your sites. Additionally, you can audit any attempted logins with Azure Monitor and use an Azure Policy to esnure any new sites are compliant with your enterprise’s security requirements. ","categories": ["deployment"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2020/08/10/securing-data-plane-access.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Crash Monitoring in Azure App Service",
+ "excerpt":"Application crashes happen. A crash is when an exception in your code goes un-handled and terminates the process. These unhandled exceptions are also known as second chance exceptions. When your application crashes, all the in-flight requests (request that are currently being processed by the app) are aborted. An end user may experience an HTTP 502 error for those requests. When the app restarts, availability of the app is still impacted due to the cold start which makes things worse. When you are running production applications, it is important to quickly identify the root cause of an application crash to troubleshoot and minimize the business impact. Having the right set of logs is key to a quick resolution. However, it could be difficult to capture these logs at the time of the crash. With App Service Diagnostics’ Crash Monitoring, you can collect memory dumps and call stack information at the time of the crash to identify the root cause. Crash Monitoring works by enabling an agent on your application hosted on App Service. The agent attaches a debugger (procdump.exe in this case) when process starts. If the process crashes with an unhandled exception, the debugger captures a memory dump. Currently offered in App Service Diagnostics for Windows web apps. Enabling Crash Monitoring If you are using Remote Debugging on your app, Remote Debugging takes preference over Crash Monitoring, and Crash Monitoring will not run. Using the Azure Portal To access Crash Monitoring, browse to your App Service in the Azure Portal and click Diagnose and Solve problems in the left navigation panel. Then, click on the home page tile named Diagnostic Tools. Once you are inside Diagnostic Tools, click Crash Monitoring. Configuration Crash Monitoring operates based on 4 conditions that you can configure to your needs. Enabling crash monitoring might incur slight performance impact on your app because a debugger is always attached to your process. The delay would vary depending upon the number of exceptions that your application code is throwing. Storage account: The selected storage account will store the memory dumps captured via Crash Monitoring. Avoid changing the storage account for your app if there is an active crash monitoring session in progress. Start time: Crash Monitoring session will begin at the selected time. Stop time: Crash Monitoring session will end at the selected time regardless of the maximum of memory dumps captured. To completely disable the agent after the Crash Monitoring session, click on the Disable Agent link. Max No. of memory dump: The Crash Monitoring session concludes once the maximum number of dumps has been gathered. If you want to fully deactivate the agent after the Crash Monitoring session, simply click the Disable Agent link. Before connecting the debugger to the process, the crash monitoring agent verifies the current number of dumps in the storage account. Once the necessary amount of memory dumps has been created, the agent will cease to gather more unless you remove the current dumps from storage or relocate them to another location. The Crash Monitoring configurations are saved in your app’s app settings. Each time a new configuration is saved, your app will restart. Once you click Start Monitor, the configuration will be saved, and the monitoring session will begin. Deleting a memory dump from a storage account while the tool is still running may cause the tool to collect additional data than desired. Please ensure the session is completed before you delete the memory dumps from the storage account. Analyzing the Data Once you configure and start the Crash Monitoring session, the tool will automatically collect memory dumps and stack trace as your application crashes. You can view the memory dumps and stack trace information grouped by the exit code in the Analyze section. Memory dumps and stack trace information become available as your application crashes though you may experience 15 minutes of delay for complete logs to show. You can click on the View details link to expand the details of the crash. Then, you can click on the View link under Callstack to view the call stack for the crash. Also, there is an option to download the dump file directly. Click on the Download file link next to download the dump file. Once downloaded, open it in Visual Studio. Not only this, you can also launch the call stack window by navigating to the Debug menu and then selecting Windows and then choosing Call Stack. Clicking on Debug with Managed Only will attempt to load the PDB files and open the exact source code of the function if Visual Studio and symbols are lined up properly. Even if they are not, the Visual Studio Debugger will show exception details like below. In this way, you can identify the call stack and exception message directly from the memory dump file. View Historical Data You can view up to past 15 days of data in the View History section. If you delete the memory dumps from your storage accounts, they will no longer show in this section. Disable Crash Monitoring To disable Crash Monitoring, click Disable agent in the Analyze section. This will remove the app settings for Crash Monitoring and restart your app. Watch a Demo Watch this video to learn more about the feature and analyzing the report generated by this tool. Feel free to share your feedback or questions about Crash Monitoring by emailing diagnostics@microsoft.com ","categories": ["Diagnostics"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2020/08/11/Crash-Monitoring-Feature-in-Azure-App-Service.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Zero to Hero with App Service, Part 6: Securing your web app",
+ "excerpt":"The Azure App Service is offered as two deployment types: the multi-tenant service and the App Service Environment. In the multi-tenant service there are thousands of customers on the same infrastructure. Your apps are always secured but the network, the address space and some other components are shared. In an App Service Environment you have a single tenant version of App Service that runs in your Azure Virtual Network. The next two articles are focused on how to configure network security in the multi-tenant App Service. In this article, you will learn how to secure your standalone app in the multi-tenant App Service. In the next article, we will cover how to build a secure multi-tier web application. Networking overview There are two aspects that need to be secured for a web app, inbound traffic and outbound traffic. Inbound traffic are visitors going to your web page, or clients sending requests to your API. Outbound traffic is when your web app makes an outbound call to a database, cache, message queue, or other service. The inbound traffic passes through a load balancer to a set of shared front end servers before reaching the workers which your apps run on. The outbound traffic leaves those workers and goes out through one of the outbound load balancers used by the scale unit. In the diagram below, the inbound and outbound load balancers are shown in green. All traffic to and from the components inside App Service is strictly locked down and secured to prevent malicious actions. This includes preventing any worker-to-worker communication. This means users just need to secure the networking path to and from their apps–all other traffic is secured for you. Features and Services The following tutorial uses a number of Azure Networking features and services. Here is a quick breakdown of the features used in this article. Web Application Firewall: The Web Application Firewall (or WAF for short) sits between your applications and your end users. It protects your applications against common attacks like cross-site-scripting or SQL injection. Virtual Network: The Azure Virtual Network (VNet) is the building block for creating your network in Azure. A VNet is similar to a physical network that you would have in an on-premises network: you can assign an address space for a VNet and apply subnets to organize the network. Application Gateway: An Application Gateway acts as a load balancer for your application(s) and allows you to route requests based on the requested hostname or URL path. Learn more about Azure Application Gateway features Service endpoints: Some Azure resources are deployed into virtual networks by default. Other resources, such as the multi-tenant App Service, can gain access to the VNet using Service Endpoints. This means you can use Service Endpoints to only allow inbound traffic to your web app from a subnet within a VNet. Private Endpoints: Private Endpoints enable exposing the inbound traffic to a service on an address in a selected VNet. Azure Front Door: Front Door (AFD) provides many of the same features and benefits of an Application Gateway. It improves application performance by routing users to the nearest Point of Presence (POP). Securing your web app To secure the network access around your web app you will need to secure… Inbound request traffic to your app Inbound publishing traffic to your app Outbound calls made from your app To secure inbound request traffic to your app, use a WAF enabled Application Gateway with Service Endpoints. To secure inbound publishing traffic to your app, use a build agent with service endpoints on the publishing endpoint. Lastly, to secure outbound traffic from your web app, use VNet Integration and an Azure Firewall. Securing inbound traffic Select or create an Azure Virtual Network (VNet). To secure your inbound traffic to your app you will need to have a VNet. If you have one already, you do not need to create another. It should be in the same region as your web app. If you do not have a VNet, you can create one following these instructions Creating an Azure Virtual Network. Create an Application Gateway as described here in Creating an Application Gateway. Enable Service Endpoints to your web app. Once you have the VNet, App Gateway, and Service Endpoints set up, you need to add a custom domain name for your app that should point to your Application Gateway. Your web app needs to be configured with the new domain name. To add a custom domain name to your web app, follow the guidance here. The end result is that your web app will have all inbound traffic routed through your Application Gateway to your app. You can, and should, enable Web Application Firewall (WAF) support on your Application Gateway. Alternate Configuration There are two alternative services that are in preview that should be noted. One is using Private Endpoints rather than Service Endpoints and the other is using Azure Front Door instead of an Application Gateway. If you use Private Endpoints instead of Service Endpoints, you would create your Private Endpoint in a subnet other than the GatewaySubnet. This Private Endpoint would be configured against your app. This is a great solution as it also hosts the HTTPS publishing endpoint for your app. When you add Private Endpoints to your app, the app is no longer accessible from the internet. Traffic to your app must only go through the private endpoints on your app. If you use Azure Front Door (AFD) with your app, you would need to set an IP address access restriction to secure your app to only being accessible through AFD. There are some additional changes that will soon be available that will enable you to lock you app down to specific AFD profiles. If you use AFD, you can enable a mix of capabilities such as WAF protection just like with an Application Gateway. Secure publishing inbound traffic Publishing is the process by which you upload your web app content to your app service instance. Unless you are using FTP, all publishing actions are performed against the scm site for your app. For every app there exists the app url and there also exists the publishing url. The publishing url is <app name>.scm.azurewebsites.net. Secure publishing is not too different from secure app access. For secure publishing you need to publish from inside your VNet. To have a secure publishing story you need to follow one of the following patterns: Use Access Restrictions to secure traffic to the publishing endpoint for your app Use service endpoints to secure traffic from a jump box being used to publish Use a relay agent, such as the Azure Pipeline build agent deployed on a VM in your VNet and then use service endpoints to secure your scm site to the subnet that the build agent is in. To use the Azure Pipeline relays agent: Create a VM in your VNet. Install and configure the Azure pipeline agent Configure service endpoints for your app scm site against the subnet that your VM is in. Secure outbound traffic from your web app To secure outbound traffic from your web app you need to use the regional VNet Integration feature. This feature enables you to make calls into your VNet and have all outbound traffic subject to Network Security Groups (NSGs) and Route Tables (UDRs). With NSGs you can restrict outbound traffic to address blocks of your choosing. With UDRs you can route traffic as you see fit. If you route the outbound traffic to an Azure Firewall device, you can restrict your outbound internet traffic to only the FQDN’s you want it to reach. To secure your outbound traffic from your web app, enable VNet Integration. By default, your app outbound traffic will only be affected by NSGs and UDRs if you are going to a private address (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). To ensure that all of your outbound traffic is affected by the NSGs and UDRs on your integration subnet, set the application setting WEBSITE_VNET_ROUTE_ALL to 1. Summary Congratulations! In this article you learned how to secure your inbound and outbound networking traffic. You are now able to assemble App Service and Networking features to create a secure internet facing web application. Helpful Resources App Service networking features App Service access restrictions App Service VNet Integration App Service Private endpoints App Service Hybrid Connections ","categories": [],
+ "tags": ["zero to hero"],
+ "url": "https://azure.github.io/AppService/2020/08/14/zero_to_hero_pt6.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Netflix Eureka on App Service",
+ "excerpt":"Netflix Eureka is a REST based middleware designed for discovery and load balancing of web applications. For those who already have a Netflix Eureka app, this article explains the configurations required to get a Netflix Eureka based app running correctly in App Service. For readers starting from scratch, we have prepared a demo project with a working example of Netflix Eureka based services working together on Azure App Service. Configure Netflix Eureka for App Service In Azure, there are several configurations that must be performed on Eureka clients to get them working correctly in App Service. These settings can be included in an application.yml file, application.properties file, or as arguments to the JVM in the JAVA_OPTS app setting. Note: These configurations are for Windows Web Apps. For configuration on Linux, see Linux Configuration Example configuration files If you are using .properties files, the required configurations are below. spring.application.name=example-client eureka.client.serviceUrl.defaultZone=https://example-server.azurewebsites.com:443/eureka eureka.instance.hostname=example-client.azurewebsites.com eureka.instance.secure-port-enabled=true eureka.instance.nonsecure-port-enabled=false eureka.instance.nonSecurePort=80 eureka.instance.securePort=443 management.server.port=${server.port} eureka.instance.instanceId=${eureka.instance.hostname}:${spring.application.name}:443 eureka.instance.statusPageUrl=https://${eureka.hostname}:443/actuator/info eureka.instance.healthCheckUrl=https://${eureka.hostname}:443/actuator/health eureka.instance.secureHealthCheckUrl=https://${eureka.hostname}:443/actuator/health Here are the same configurations for YAML users. spring: application: name: example-server management: server: port: ${server.port} eureka: client: serviceUrl: defaultZone: https://example-server.azurewebsites.com:443/eureka eureka: instance: hostname: example-client.azurewebsites.com secure-port-enabled: true nonsecure-port-enabled: false nonSecurePort: 80 securePort: 443 instanceId: ${eureka.instance.hostname}:${spring.application.name}:443 statusPageUrl: https://${eureka.hostname}:443/actuator/info healthCheckUrl: https://${eureka.hostname}:443/actuator/health secureHealthCheckUrl: https://${eureka.hostname}:443/actuator/health Enable HTTPS Only Configure your web app to only accept HTTPS traffic. Go to your App Service in the Azure Portal Find Settings on the left-side navigation menu Click TLS/SSL settings Toggle HTTPS only to “On” Explanation of Properties spring.application.name=[YOUR APP NAME] Setting the application name is important for discovery by other services, which will look for the app by spring.application.name. For a Spring Boot based Netflix Eureka app, this is spring.application.name eureka.client.serviceUrl.defaultZone=https://[YOUR SERVER HOSTNAME]:443/eureka This is the default server the client will broadcast to, allowing communication between the client, server, and discovery of all services known by the server. In App Service, the server URL might look like: my-eureka-server.azurewebsites.net. eureka.instance.hostname=[YOUR CLIENT HOSTNAME] The url of the client itself. This should look like my-eureka-client.azurewebsites.net eureka.instance.secure-port-enabled=true eureka.instance.nonsecure-port-enabled=false eureka.instance.nonSecurePort=80 eureka.instance.securePort=443 It is recommended to use secure communication (HTTPS). In the case you do not want to use secure communication, set eureka.instance.secure-port-enabled to false and eureka.instance.nonsecure-port-enabled=true. If you do that, ensure that HTTPS Only setting (under TLS/SSL settings) is set to “Off”. management.server.port=${server.port} eureka.instance.instanceId=${eureka.instance.hostname}:${spring.application.name}:443 eureka.instance.statusPageUrl=https://${eureka.hostname}:443/actuator/info eureka.instance.healthCheckUrl=https://${eureka.hostname}:443/actuator/health eureka.instance.secureHealthCheckUrl=https://${eureka.hostname}:443/actuator/health If using a service such as Spring Actuator, the management server port must be defined as the same port as server.port. This is because the platform assigns a random port to server.port, which the platform then exposes as port 80 and port 443. As such, the Actuator must also communicate on the port which is chosen by the platform to be exposed to the internet. Server Configuration In Eureka, applications can be clients, servers, or both. In the case where an application is just a server and not a client, add the following configuration in application.properties. eureka.client.register-with-eureka=false eureka.client.fetch-registry=false Linux Configuration If you are planning on hosting your Netflix Eureka application as a Linux Web App, the port information specified in Windows Web Apps is not required. This is because Windows Web Apps can only expose port 80 and port 443 externally, whereas a Linux Web App can expose other ports. An example application.properties file for a Netflix Eureka client on a Linux Web App: spring.application.name=example-client eureka.client.serviceUrl.defaultZone=https://example-server.azurewebsites.com:443/eureka eureka.instance.hostname=example-client.azurewebsites.com eureka.instance.secure-port-enabled=true eureka.instance.nonsecure-port-enabled=false By default the ports 80 and 443 are used for http and https traffic respectively. Notably, management.server.port can be set to any arbitrary port. This may be useful for security or administrative purposes. management.server.port=888 Tutorial If you do not have a Netflix Eureka project, you can get the example project files here and follow the instructions below to get started. If you prefer to use Linux App Service Plans, the example project for Linux is available here. The instructions for the Linux project are the same. NOTE: the Linux version of this project will be hosted on premium (P1v2) App Service Plans, which may incur costs. Prerequisites Building and deploying the example project will require the following technologies. Java JDK 1.8 Maven Azure CLI You will also need an active Azure Subscription to create the web apps. An Overview of the Project The project is composed of the following four web apps. 2 services which provide data: ratings-data-service, movie-info-service 1 service which consumes data from the others: movie-catalog-service 1 discovery server to allow the services discover each other: discovery-server The utility of Netflix Eureka for discovery is showcased in the catalog service, which consumes the ratings data and movie info in this block. The discovery server handles registering the movie info service and ratings data service such that they can be hosted on many machines at many URLS and be consumed by name. As you can see, the code simply calls the services by their app names: ratings-data-service and movie-info-service. @RequestMapping(\"/catalog/{userId}\") public List<CatalogItem> getCatalog(@PathVariable(\"userId\") String userId) { UserRating userRating = restTemplate.getForObject(\"http://ratings-data-service/ratingsdata/user/\" + userId, UserRating.class); return userRating.getRatings().stream() .map(rating -> { Movie movie = restTemplate.getForObject(\"http://movie-info-service/movies/\" + rating.getMovieId(), Movie.class); return new CatalogItem(movie.getName(), movie.getDescription(), rating.getRating()); }) .collect(Collectors.toList()); } Building Run mvn clean prepare-package package -DskipTests from the root of the project directory to build the applications. Deploying Deploying is similar to deploying a Spring Boot application using Maven. Make sure you are authenticated on the Azure CLI and have the correct subscription set. Then, run mvn azure-webapp:deploy -Dprefix=yourPrefix, replacing yourPrefix with a string that is unique to you or your organization. The domain names on App Service must be unique, so this prevents name collisions with other applications. If a prefix is not set this way, a timestamp will used as the prefix. The application.properties file of each of the services is generated based on client.application.properties.template. The application.properties file of the discovery server is generated from server.application.properties.template. This is to apply the prefix and ensure each application has the same properties. This happens in the prepare-package step of the build process. To build and run the project in one command, use: mvn clean prepare-package package azure-webapp:deploy -Dprefix=yourPrefix -DskipTests The Services After deployment, the project will be hosted on four Azure web apps. The individual apps are at the following four URLs, where “yourPrefix” is the string you provided in the previous step. http://yourPrefix-discovery-server.azurewebsites.net/ http://yourPrefix-movie-catalog-service.azurewebsites.net/ http://yourPrefix-movie-info-service.azurewebsites.net/ http://yourPrefix-ratings-data-service.azurewebsites.net/ Your URLS are in output of the Maven command, and in the Azure Portal in the auto-generated resource group, yourPrefix-example-netflix-eureka-rg. By default, this project is configured to use a free tier App Service Plan. These app service plans are not “always on” by default, which means they must be visited after deployment to start up. Additionally, they will stop after 20 minutes of inactivity. Ensure that you visit the discovery server first. This allows the services register with it and discover each other. Then visit the movie info and ratings data services before the movie catalog service. This is because the movie catalog service requires data from the movie info service and ratings data service. Querying the movie catalog service before the movie info and ratings data services results in a 500 error. A PowerShell script which performs the requests in correct order: #Replace with your prefix $prefix=microsoft-example Invoke-Webrequest -URI https://$prefix-discovery-server.azurewebsites.net Invoke-Webrequest -URI https://$prefix-movie-info-service.azurewebsites.net Invoke-Webrequest -URI https://$prefix-ratings-data-service.azurewebsites.net Invoke-Webrequest -URI https://$prefix-movie-catalog-service.azurewebsites.net The same can be done on bash using curl: #Replace with your prefix $prefix=microsoft-example curl -s https://$prefix-discovery-server.azurewebsites.net curl -s https://$prefix-movie-info-service.azurewebsites.net curl -s https://$prefix-ratings-data-service.azurewebsites.net curl -s https://$prefix-movie-catalog-service.azurewebsites.net Querying the Services Data from the services can be accessed directly on each site. Data can also be retrieved as PowerShell objects through the Invoke-RestMethod command: #Replace with your prefix $prefix=microsoft-example Invoke-RestMethod -URI https://$prefix-movie-info-service.azurewebsites.net/movies/12 -ContentType \"application/json\" Invoke-RestMethod -URI https://$prefix-ratings-data-service.azurewebsites.net/ratingsdata/movies/12 -ContentType \"application/json\" Invoke-RestMethod -URI https://$prefix-movie-catalog-service.azurewebsites.net/catalog/12 -ContentType \"application/json\" Or in bash: #Replace with your prefix $prefix=microsoft-example curl -s https://$prefix-discovery-server.azurewebsites.net curl -s https://$prefix-movie-info-service.azurewebsites.net/movies/12 curl -s https://$prefix-ratings-data-service.azurewebsites.net/ratingsdata/movies/12 curl -s https://$prefix-movie-catalog-service.azurewebsites.net/catalog/12 Querying the Discovery Server The discovery server can be queried to provide information about the services registered with it. The following command gets the applications registered with the discovery server: $response = Invoke-RestMethod -URI https://$prefix-discovery-server.azurewebsites.net/eureka/apps -ContentType \"application/json\" $response.applications versions__delta apps__hashcode application --------------- -------------- ----------- 1 UP_3_ {MOVIE-INFO-SERVICE, RATINGS-DATA-SERVICE, MOVIE-CATALOG-SERVICE} An individual service can then be queried as a PowerShell object: $catalogService = $response.applications.application | Where-Object {$_.name -eq \"MOVIE-CATALOG-SERVICE\"} $catalogService.instance instanceId : example-movie-catalog-service.azurewebsites.net:movie-catalog-service:443 hostName : example-movie-catalog-service.azurewebsites.net app : MOVIE-CATALOG-SERVICE ipAddr : 10.0.5.129 status : UP overriddenstatus : UNKNOWN port : port securePort : securePort countryId : 1 dataCenterInfo : dataCenterInfo leaseInfo : leaseInfo metadata : metadata homePageUrl : http://example-movie-catalog-service.azurewebsites.net:80/ statusPageUrl : https://example-movie-catalog-service.azurewebsites.net:443/actuator/info healthCheckUrl : http://example-movie-catalog-service.azurewebsites.net:443/actuator/health secureHealthCheckUrl : https://example-movie-catalog-service.azurewebsites.net:443/actuator/health vipAddress : movie-catalog-service secureVipAddress : movie-catalog-service isCoordinatingDiscoveryServer : false lastUpdatedTimestamp : 1596156385669 lastDirtyTimestamp : 1596156385326 actionType : ADDED This means that services and discovery servers hosted on Azure can be accessed and consumed by other Eureka servers, including those hosted on other cloud service providers and local servers. While Netflix Eureka is designed for Java, it is possible to use this data to implement a Netflix Eureka client in any language. Securing Eureka Without requiring authorization, any user can access the discovery server. This means that a malicious user has all of the information about every service and server registered, and can register their own malicious applications to your discovery server, potentially accessing sensitive information. Basic Auth Since our example application is based on Spring Boot, it can use Spring Boot’s security to require credentials from clients before registering them. In the pom.xml of the discovery server project, add this dependency: <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-security</artifactId> </dependency> In the application.properties of the discovery server, add the following: spring.security.user.name=your-eureka-user spring.security.user.password=your-eureka-password Note: if you are adding this to the example project, add the above properties to server.application.properties.template as well. Define a class in the discovery server project that extends WebSecurityConfigurerAdapter and overrides the configure() method package io.javabrains.discoveryserver; //Package of the example project, replace with yours import org.springframework.context.annotation.Configuration; import org.springframework.security.config.annotation.web.builders.HttpSecurity; import org.springframework.security.config.annotation.web.configuration.WebSecurityConfigurerAdapter; @Configuration public class SecurityConfig extends WebSecurityConfigurerAdapter { @Override protected void configure(HttpSecurity http) throws Exception { http.csrf().disable().authorizeRequests().anyRequest().authenticated().and().httpBasic(); } } When you run the discovery server and navigate to it, there should now be a pop-up requesting a username and password. Modify the application.properties file of the client to include the username and password in the discovery server URL eureka.client.serviceUrl.defaultZone=https://discovery-server.azurewebsites.net:443/eureka Should now be: eureka.client.serviceUrl.defaultZone=https://username:password@discovery-server.azurewebsites.net:443/eureka Note:: if you’re adding this to the example project, add the username and password to client.application.properties.template The client will now be able to successfully register with the Eureka server. Security Options for Azure and Spring Boot Azure App Service provides built-in authentication and authorization support, so you can sign in users and access data by writing minimal or no code in your web app. This feature, EasyAuth, allows Azure Web Apps to authenticate though identity providers, including Azure Active Directory, Google, Microsoft Account, Facebook, Twitter, and OpenID Connect. You can read more about EasyAuth and Authentication and Authorization in Azure here The Spring Boot Starter for Azure provides auto-configuration for a number of Azure Services. These include Azure Active Directory, an authorization and identity service, and Key Vault, a service for storing and retrieving secrets securely across Azure. You can read more about Spring Boot Starters for Azure here Aside from Basic Auth, our example application can use the security features of Spring Security for other types of authorization (Including OAuth2) and protection from exploits such as CSRF attacks. You can read more about Spring Security here ","categories": ["java"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2020/08/18/Netflix-Eureka-On-App-Service.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "GitHub Actions integration is now Generally Available",
+ "excerpt":"A year ago we announced a GitHub Action to deploy your web apps to Azure App Service. In April, we added GitHub Actions as an option in the Deployment Center. We are excited to share that the GitHub Actions integration with Azure App Service is now Generally Available and ready for production workloads. The current GitHub Actions option in the Deployment Center does not yet support deploying Docker containers. You can still set up Continuous Integration and Delivery (CI/CD) with Docker containers and GitHub Actions by following this tutorial. The Deployment Center helps you build a CI/CD pipeline on GitHub Actions. This saves time, and simplifies the process if you are new to GitHub Actions or CI/CD. Watch the video below to get started. If you are new to App Service, see our Zero to Hero series to go from zero to cloud hero with Azure. The articles cover CI/CD, deployment slots, certificates, domains, network security, and advanced configuration! Helpful Resources About GitHub Actions GitHub Actions for other Azure services ","categories": ["deployment"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2020/08/19/github-actions-code-ga.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "A/B Testing with App Service, Part 2: Server-side configuration",
+ "excerpt":"This is the second article in our guide for A/B testing with App Service. See the first article for more information about A/B testing and how to set up your client-side project Share your thoughts in the comments section). Add the slot name First, you will need to add the name of the slot as an app setting. For example, if you have a slot named staging, create an app setting named SLOT_NAME and set its value to staging. If you have a slot named dev, create an app setting named SLOT_NAME with a value of dev. In the next section, the telemetry initializer will use this app setting to tag the outgoing telemetry. For example, here is an Azure CLI command to set the app setting and value for a slot named “staging” on a webapp named “my-webapp” in a resource group called “my-resource-group”. az webapp config --name my-webapp -g my-resource-group -slot staging --settings SLOT_NAME=staging Configure your project Like in the first article, you will need to add a telemetry initializer to your project and register it with the Application Insights SDK. The telemetry initializer will tag all outgoing events and metrics with the slot’s name, so you can split and filter the data during analysis later. In some cases, you will need to register the initializer with the App Insights SDK. Instructions are below for common backend languages; please jump to the section for your language. .NET For .NET Core apps, follow the instructions shown here to add App Insights to your project. if you are using ASP.NET, follow these instructions instead. Once you have added the SDK, copy and paste the custom telemetry initializer below. using System; using Microsoft.ApplicationInsights.Channel; using Microsoft.ApplicationInsights.DataContracts; using Microsoft.ApplicationInsights.Extensibility; public class MyTelemetryInitializer : ITelemetryInitializer { public void Initialize(ITelemetry telemetry) { String SLOT_ENV_VAR = \"SLOT_NAME\"; var requestTelemetry = telemetry as RequestTelemetry; slot = Environment.GetEnvironmentVariable(SLOT_ENV_VAR); requestTelemetry.Properties[SLOT_ENV_VAR] = slot; } } For more information, see the Application Insights documentation for .NET Core and ASP.NET Java Spring Add the Spring Starter for Application Insights to the dependencies of your pom.xml. <dependency> <groupId>com.microsoft.azure</groupId> <artifactId>applicationinsights-spring-boot-starter</artifactId> <version>1.1.1</version> </dependency> Create a new class and paste the following definition. The initialize() method will retrieve the name of the current slot from the app setting and attach it to the outgoing telemetry. If you are not using Lombok, you can remove the import and log statement for Lombok. import com.microsoft.applicationinsights.extensibility.TelemetryInitializer; import com.microsoft.applicationinsights.telemetry.Telemetry; import lombok.extern.slf4j.Slf4j; import org.springframework.stereotype.Component; @Component @Slf4j public class CustomTelemetryInitializer implements TelemetryInitializer { /** * Get the slot name from the env var and attach it to the outgoing telemetry. * @param telemetry Outgoing telemetry */ @Override public void initialize(Telemetry telemetry) { final String SLOT_ENV_VAR = \"SLOT_NAME\"; final String slot = System.getenv(SLOT_ENV_VAR); if (slot != null) { log.info(\"Tagging telemetry with slot name: \"+slot); telemetry.getProperties().put(SLOT_ENV_VAR, slot); } } } Other frameworks For other Java frameworks you can install the core SDK, coordinates shown below. Once the SDK is added to your dependency list, create an ApplicationInsights.xml file in your app’s classpath. Copy the file contents from here. Add the Application Insights SDK to the dependencies of your pom.xml. <dependency> <groupId>com.microsoft.azure</groupId> <artifactId>applicationinsights-web-auto</artifactId> <version>2.5.0</version> </dependency> Create an ApplicationInsights.xml file in your app’s classpath. Copy the file contents from here. Create a new class and paste the following definition. The initialize() method will retrieve the name of the current slot from the app setting and attach it to the outgoing telemetry. If you are not using Lombok, you can remove the import and log statement for Lombok. import com.microsoft.applicationinsights.extensibility.TelemetryInitializer; import com.microsoft.applicationinsights.telemetry.Telemetry; import lombok.extern.slf4j.Slf4j; @Slf4j public class CustomTelemetryInitializer implements TelemetryInitializer { /** * Get the slot name from the env var and attach it to the outgoing telemetry. * @param telemetry Outgoing telemetry */ @Override public void initialize(Telemetry telemetry) { final String SLOT_ENV_VAR = \"SLOT_NAME\"; final String slot = System.getenv(SLOT_ENV_VAR); if (slot != null) { log.info(\"Tagging telemetry with slot name: \"+slot); telemetry.getProperties().put(SLOT_ENV_VAR, slot); } } } Register the telemetry initializer with the App Insights SDK by adding the following line to your ApplicationInsights.xml file. Replace the example package name with your project’s package name. <TelemetryInitializers> ... <Add type=\"org.example.package.CustomTelemetryInitializer\"/> </TelemetryInitializers> For more information, see the Application Insights documentation for Java and Spring. Node Install the App Insights package. npm install applicationinsights --save Create a telemetry initializer, just like in the other examples. var tagSlotName = (envelope) => { const SLOT_ENV_VAR = \"SLOT_NAME\"; let slot = process.env[SLOT_ENV_VAR]; if (slot != null) { envelope.data[SLOT_ENV_VAR] = slot; } }; Import the package, then register the telemetry initializer as shown below. let appInsights = require('applicationinsights'); appInsights.addTelemetryInitializer(tagSlotName); For more information, see the App Insights documentation for Node.js Python Please refer to the Python documentation for Application Insights for instructions on installation and configuration. Once App Insights is added to your Python app, you can tag the outgoing telemetry with the slot name using the OpenCensus Python telemetry processors. Summary In this article you added Application Insights and a custom telemetry initializer to your backend project. The custom initializer reads the slot name from the app setting and tags all outgoing telemetry with it. This process is similar to the process in the first article, but applied to the server-side code. The next article will show how to split and analyze the data. ","categories": ["deployment"],
+ "tags": ["A/B Testing"],
+ "url": "https://azure.github.io/AppService/2020/08/24/ab_testing_app_service2.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Health Check is now Generally Available",
+ "excerpt":"App Service makes it easy to automatically scale your apps to multiple instances when traffic increases. This increases your app’s throughput, but what if there is an uncaught exception on one of the instances? To address this situation, we began previewing Health Check last year. The Health Check feature allows you to specify a path on your application for App Service to ping. If an instance fails to respond to the ping, the system determines it is unhealthy and removes it from the load balancer rotation. This increases your application’s average availability and resiliency. Health Check is now Generally Available and ready for production applications. Set up Health Check on your applications today in the Azure Portal. Go to your web app and find Health Check under Monitoring in the left-side navigation menu. You may see “(Preview)” on the Portal blade. This is because the Portal blade uses the latest React libraries, but the feature itself is Generally Available. Overview Once you specify a path on your site, App Service will ping it at regular intervals. If the path responds with an error HTTP status code or does not respond, then the instance is determined to be unhealthy and it is removed from the load balancer rotation. This prevents the load balancer from routing requests to the unhealthy instances. Looking for more information? Head to the health check documentation When the instance is unhealthy and removed from the load balancer, the service continues to ping it. If it begins responding with successful response codes then the instance is returned to the load balancer. If it continues to respond unsuccessfully, App Service will restart the underlying VM in an effort to return the instance to a healthy state. Health Check integrates with App Service’s authentication and authorization features, so the system will reach the endpoint even if these security features are enabled. If you are using your own authentication system, the health check path must allow anonymous access. The health check path should check the critical components of your application. For example, if your application depends on a database and a messaging system, the health check endpoint should connect to those components. If the application cannot connect to a critical component, then the path should return a HTTP error response code to indicate that the app is unhealthy. Alerts After providing your application’s health check path, you can monitor the health of your site using Azure Monitor. From the Health check blade in the Portal, click Metrics in the top toolbar. This will open a new blade where you can see the site’s historical health status and create a new alert rule. For more information on monitoring your sites, see the guide on Azure Monitor. More resources See the Health check documentation for more information about this feature. Building and Managing .NET Core with App Service Skip to 11:28 for more information on App Service health checks and best practices. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2020/08/24/healthcheck-on-app-service.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "AppServiceAppLogs is now available for ASP .NET apps on Windows",
+ "excerpt":"We have added a new log type for ASP .NET web apps on Windows (ASP .NET Core support is not yet supported). The log type, AppServiceAppLogs, captures your app’s log and error statements. This log type is part of the preview of App Service’s integration with Azure Monitor. Enable AppSerivceAppLogs Refer to how to create Diagnostic settings and enable AppServiceAppLogs on the list. Add log message to your web app To start using this log type, you need to update the Web.config file and add log statements to your code. Then you can route logs to Log Analytics, Event Hubs, or a Storage Account. Update your Web.config file Add the following snippet to your Web.config file in order to declare usage of our Trace Listener. This will configure your application to direct its tracing outputs to our listener.. Logs will not show up if you don’t add this to the Web.config. <system.diagnostics> <trace> <listeners> <add name=\"AzureMonitorTraceListener\" type=\"Microsoft.WindowsAzure.WebSites.Diagnostics.AzureMonitorTraceListener, Microsoft.WindowsAzure.WebSites.Diagnostics, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35\" /> </listeners> </trace> </system.diagnostics> Add log statements to your code You can use the System.Diagnostics.Trace class to log information to the application diagnostic logs. For example: System.Diagnostics.Trace.TraceError(\"Error found\"); How to filter log trace levels sent to Log Analytics/Storage account/Event hub If you have various trace levels in your web app but are only interested in having certain levels of logs sent to the logging endpoint, you can set a filter for the minimum level in your application settings under Configuration. By default, even without the app setting, the minimum trace level is set to Warning. How to set App setting for AppServiceAppLogs level The application setting name will be APPSERVICEAPPLOGS_TRACE_LEVEL and the value will be the minimum level (ie. Error, Warning, Verbose, etc.). Refer to TraceLevel for more info. The trace level value is case sensitive. Make sure the first letter is uppercase and the rest is lowercase (ie. Error, Warning, etc.) For example, if you are only interested in seeing logs that are of level Error and higher, you will set your application setting APPSERVICEAPPLOGS_TRACE_LEVEL to Error. How logs show up in Log Analytics The texts of your logs will generally show up in the “Message” field in Log Analytics, but if you have an Error log, you will find the text in the “StackTrace” field. Look at the samples below and note the difference in the fields. Below is a sample result from an Error log: Below is a sample result from an Warning log: Sample queries in Log Analytics You can use the different levels of logging such as Error, Information, and etc. in your application and this will show up in your logs in Log Analytics under the “Level” field. You are able to filter out logs based on the level. The example below shows how you can filter for only Error Level logs: AppServiceAppLogs | where Level == \"Error\" FAQ Q: I’m not seeing any logs on my Storage account/Log Analytics/Event Hub A: On Windows, this log is currently only supported for ASP .NET applications. If your application isn’t an ASP .NET application, you won’t be seeing the logs. However, if your application is an ASP .NET application, there are a couple of possible reasons why your logs aren’t showing: Did you enable the AppServiceAppLogs? Did you update the Web.config file? Did you add logs to your code? Q: Why aren’t my logs that are lower than Warning showing up? A: By default, Warning logs and higher will be only be sent, however, you can set the minimum trace level of the logs you would like to see. Refer to how to filter log trace levels sent to Log Analytics/Storage account/Event hub. Note that the app setting is case sensitive. Q: Why can’t I see my Trace, Debug, or Info logs? A: By default, Warning logs and higher will be only be sent, however, you can set the minimum trace level of the logs you would like to see. Refer to how to filter log trace levels sent to Log Analytics/Storage account/Event hub. Note that the app setting is case sensitive. ","categories": [],
+ "tags": ["monitoring"],
+ "url": "https://azure.github.io/AppService/2020/08/31/AzMon-AppServiceAppLogs.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Troubleshoot ASP.NET assembly loading failures using Fusion Logging",
+ "excerpt":"ASP.NET Framework has fusion Assembly Binding logging (aka Fusion Logging) which allows you to debug assembly load failures in your .NET applications. Fusion logging comes handy when your application is referencing assemblies or external nuget packages and you are encountering assembly binding failures. We are pleased to announce that you can enable Fusion logging in Azure App Service on a per-app basis and troubleshoot assembly failures easily. Currently offered in App Service for Windows web apps only and applies to classic ASP.NET Framework apps. This logging does not apply to ASP.NET Core apps. Enabling Fusion Logging To enable fusion logging, follow these steps Go to the Azure Portal. Click on Configuration for your App. Under the Application Settings section, add a new application setting with the name WEBSITE_FUSIONLOGGING_ENABLED and a value of 1. Click the Save button. Saving the application setting causes a restart of the app on all instances, so perform this step during low-usage hours. After you save this app setting, fusion logging will be enabled for your app. All processes launched for your app (w3wp.exe, w3wp.exe for the Kudu site, and any child processes of these processes) will have fusion logging enabled. This means you can use this feature to troubleshooting assembly binding issues even in WebJobs. Enabling fusion logging on one app does not enable it for other apps in the App Service Plan. After fusion logging is enabled, if you browse to the page that was failing to load an assembly, you will now see detailed fusion logs emitted in the actual error message itself. An example is shown below. Using fusion logging you can identify the exact assembly, the version, the location and other information about the whereabouts of the assembly. After you have diagnosed the root cause of the issue, be sure to remove the app setting. Fusion logging incurs some performance impact on the runtime of the application and leaving it enabled is not recommended in production. ","categories": ["Diagnostics"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2020/09/16/Fusion-Logging-for-ASP.NET-Apps.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "App Service Environment v3 (ASEv3) public preview pre-announcement",
+ "excerpt":"The App Service Environment v3 (ASEv3) project is a realization of several years of infrastructure development to enable a best-in-class, network isolated application hosting PaaS service. Today we are happy to pre-announce the upcoming public preview of ASEv3. The ASEv3 platform is expected to land in public preview in early November in a limited set of regions. ASEv3 Overview The App Service Environment (ASE) is a single tenant instance of the Azure App Service that runs in a customers Azure Virtual Network (VNet). It solves many isolation scenarios for some of our top customers in a way you cannot with the multi-tenant service. While the service is used widely and is well received, there are some areas we wanted to improve. In ASEv3, the underlying technology is based on Virtual Machine Scale Sets (VMSS) instead of Cloud Services. This opens the door to a number of improvements including better load balancers, zone redundancy and multiple other things. Also in ASEv3, we have eliminated the challenge of managing the ASE dependency traffic. With ASEv3, you no longer have any inbound or outbound management traffic in the customer VNet. This vastly simplifies ASE deployment and management. The end result is a single tenant system that has no internet hosted dependencies being called from the customer network. Customers can secure their workloads to their heart’s content and Microsoft can better secure the infrastructure without any impact on customer workloads. In addition to operational improvements, we’re also making this new ASE more cost-effective for customers. As part of our Isolated v2 plan, we’re reducing the PAYG rates and eliminating the per instance stamp fee for ASE v3, reducing the cost of deployment by up to 80%. ","categories": ["networking"],
+ "tags": ["ASE"],
+ "url": "https://azure.github.io/AppService/2020/09/22/asev3-public-preview-preannouncement.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Public Preview of JBoss EAP on App Service",
+ "excerpt":"For several years, Red Hat and Microsoft have partnered to create cloud solutions that enable enterprises to achieve more. Today, we are happy to announce that Red Hat JBoss Enterprise Application Platform (EAP) is now in Public Preview on Azure App Service. App Service has supported Tomcat and Java SE applications on Linux since 2018. Since then, our customers made it clear that they wanted an equivalent service for their Jakarta EE applications. JBoss EAP on App Service is now generally available! Read more here Try JBoss EAP on App Service today and send us your feedback. JBoss EAP across Azure Whether your organization is running a heavily customized, clustered JBoss EAP deployment or has embraced container technologies, Azure has a cloud service to fit your needs. With Red Hat Enterprise Linux on Azure Virtual Machine Scale Sets (VMSS), you can easily lift-and-shift your on-prem JBoss EAP deployments. Azure Red Hat Openshift combines the innovation of enterprise Kubernetes with the world’s leading enterprise Linux platform, Red Hat Enterprise Linux. App Service gives organizations the option to leverage a managed Platform-as-a-Service (PaaS) for their cloud migrations. App Service provides APIs for deployment, features for network isolation, and auto scaling. JBoss EAP on App Service To create a JBoss EAP instance, head to the Azure Portal and create a new web app. In the stack selector, choose JBoss EAP 7.2 (Preview). JBoss EAP on App Service is jointly developed and supported by Red Hat and Azure. At General Availability, any support cases concerning the JBoss server will be handled by the experts at Red Hat. Any cases concerning the App Service platform will be resolved by Azure support. Developer tooling for JBoss EAP will be released during the Public Preview release. Subscribe to the App Service Blog to stay up-to-date on news regarding Maven plugins, GitHub Actions, and IDE plugins. Public Preview release notes You can create a JBoss EAP 7.2 instance on App Service in the Azure Portal. Simply select “JBoss EAP 7.2 (Preview)” in the language stack dropdown. JBoss EAP on App Service is available on all hardware tiers at current prices. As a preview release, there is no commercial support offering and use of the preview is limited to development and testing of your applications. The General Availability release of JBoss EAP on App Service will include a service fee for the integrated technical support. If you create a JBoss EAP instance on App Service, you will receive an email notice prior to the GA release with more details on the pricing changes. Azure will resolve all support cases until the service fee is added at General Availability. Try JBoss EAP on App Service today and send us your feedback. Helpful links Overview of Red Hat JBoss EAP on Azure Java on App Service documentation JBoss EAP on App Service Tutorial JBoss EAP on App Service Migration Guide ","categories": ["java"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2020/09/22/jboss-public-preview.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Public Preview of the new Deployment Center",
+ "excerpt":"The first version of the App Service Deployment Center has been generally available since late 2018. The Deployment Center gives a centralized view of all the deployment methods for your web app. It also has a guided experience for setting up continuous integration and delivery (CI/CD) pipelines from source control or container registries. Today, we are happy to announce that a new version of the App Service Deployment Center is available for technical preview in the Azure Portal. The new experience was built with usability and clarity in mind, especially for developers that are new to App Service. Whether you’re deploying code or containers, the new App Service Deployment Center makes it easy. Easy CI/CD for Code The Deployment Center makes it easy to create a CI/CD pipeline from your GitHub, BitBucket, or an external Git repository. If you’re using GitHub, the Deployment Center can also create a GitHub Actions workflow for you! See our previous article for more information. If you’re not using GitHub, you can still create a CI/CD pipeline using the Kudu build service. Continuously deploy containers With the new Deployment Center, you can easily set up a CI/CD pipeline with GitHub Actions for your containerized applications as well. Before today, you would have to create the GitHub Actions CI/CD workflow file yourself. Now you can go to the Deployment Center in the Portal and follow the on-screen, step-by-step instructions to set up the CI/CD automation. No more YAML indentation errors! The Portal will guide you through setting up a GitHub Actions workflow to build your container, push it to a registry, and pull it to the web app whenever there is a new commit on your specified branch. GitHub Actions is free for public repositories. For private repositories, please see the GitHub pricing page. ","categories": ["deployment"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2020/09/23/deployment-center-v2.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Security for Windows containers using Hyper-V Isolation",
+ "excerpt":"Windows containers on App Service enable you to modernize your Windows applications so you can bring along dependencies or lift-and-shift your current application. To make sure that your container applications are safe and secure in App Service’s multi-tenant architecture, we use Hyper-V isolation to provide a security boundary around your Windows container apps. What is Hyper-V? Hyper-V is an isolation mode for Windows containers featuring hardware-level isolation. This virtual isolation mode allows for multiple container instances to concurrently run in a secure manner on a single host. Hyper-V isolation effectively gives each container its own kernel while providing hardware isolation and a security boundary around the containers, as opposed to process isolation which shares the kernel with other containers. Why App Service uses Hyper-V Isolation App Service runs on a multi-tenant architecture and uses Hyper-V isolation for running Windows Containers. Hyper-V runs your containers within independent security boundaries, where your container’s resources are isolated from other containers as well as the underlying VM. When creating an App Service Plan for Windows containers, the underlying VM is also dedicated to a single customer providing another level of security between applications. With Windows containers on App Service you can also install and run custom software and dependencies inside of your container. The other benefit obtained from using Hyper-V isolation includes broader compatibility between the underlying VM host and the container versions so you can run your choice of base images with compatibility across Windows Server 2019, 2004, 1909, and 1903. Resources Windows container Isolation Modes Windows Server compatible versions ","categories": [],
+ "tags": ["Windows containers"],
+ "url": "https://azure.github.io/AppService/2020/09/29/Security-for-Windows-containers-using-Hyper-V-Isolation.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Deploy your resources on the new Premium v3 SKU with an ARM template",
+ "excerpt":"The Premium v3 hardware tier, previously announced at Microsoft Ignite 2020, is now available for you to deploy your applications to. This new hardware tier introduces new CPU and memory options, enabling deployment of more apps per App Service Plan and better support for large enterprise applications and content management systems. With additional price points for dev/test and production workloads and Reserved Instance Pricing starting November 1st*, Premium v3 is our most cost-effective and performant offering ever. Portal updates are rolling out now to enable the new hardware option, but you can still deploy resources via ARM templates, Azure CLI and PowerShell. This tutorial walks you through creating a new Resource Group, Pv3 App Service Plan and a Windows Container Web App using an Azure Resource Manager (ARM) template. Premium v3 is the only hardware option that will be available for Windows container apps as it supports Hyper-V, the chosen security mode for a multi-tenant architecture. Premium v3 is an option in the regions below. Premium v3 will be available in more regions in the future. West US 2 South Central US UK South Southeast Asia West Europe East US East US 2 Australia East North Europe Central US East Asia West US Japan East Brazil South Canada Central Austrailia Southeast West Central US UK West Korea Central France Central Create your JSON template For those not familiar with ARM Templates, they amount to a JSON file which will define the necessary parameters and resources. The following template creates a Premium v3 App Service Plan and Windows container Web App. Open a New File in Visual Studio Code or your IDE of choice Create a JSON file named azuredeploy.json Copy the below template in its entirety and replace any existing brackets in your new file { \"$schema\": \"https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#\", \"contentVersion\": \"1.0.0.0\", \"parameters\": { \"appServiceWebAppName\": { \"type\": \"String\" }, \"appServicePlanName\": { \"type\": \"String\" } }, \"resources\": [ { \"type\": \"Microsoft.Web/sites\", \"name\": \"[parameters('appServiceWebAppName')]\", \"apiVersion\": \"2016-03-01\", \"location\": \"[resourceGroup().location]\", \"tags\": { \"[concat('hidden-related:', subscription().id, '/resourcegroups/', resourceGroup().name, '/providers/Microsoft.Web/serverfarms/', parameters('appServicePlanName'))]\": \"empty\" }, \"properties\": { \"name\": \"[parameters('appServiceWebAppName')]\", \"siteConfig\": { \"appSettings\": [ { \"name\": \"WEBSITES_ENABLE_APP_SERVICE_STORAGE\", \"value\": \"false\" } ], \"appCommandLine\": \"\", \"windowsFxVersion\": \"DOCKER|microsoft/iis\" }, \"serverFarmId\": \"[concat(subscription().id, '/resourcegroups/', resourceGroup().name, '/providers/Microsoft.Web/serverfarms/', parameters('appServicePlanName'))]\", \"hostingEnvironment\": \"\" }, \"dependsOn\": [ \"[concat('Microsoft.Web/serverfarms/', parameters('appServicePlanName'))]\" ] }, { \"type\": \"Microsoft.Web/serverfarms\", \"sku\": { \"Name\": \"P1v3\", \"Tier\": \"PremiumV3\" }, //For Windows code apps, set the kind parameter to \"app\" \"kind\": \"windows\", \"name\": \"[parameters('appServicePlanName')]\", \"apiVersion\": \"2016-09-01\", \"location\": \"[resourceGroup().location]\", \"properties\": { \"name\": \"[parameters('appServicePlanName')]\", \"workerSizeId\": \"0\", \"numberOfWorkers\": \"1\", // For Windows code apps, set the hyperv parameter to false \"hyperv\": true, \"hostingEnvironment\": \"\" } } ] } Use Azure CLI to deploy your template ARM deployments can be managed through the Azure CLI or Powershell. In this example, we will be using the Azure CLI. If you’d rather use Powershell, please see the instructions here. First, open Powershell and run az login to login to your Azure account Use the az account set –subscription your-subscription-id to set your desired subscription for your resources Then, create your resource group using az group create –name my-resources-group-name –location “West Central US” Once you have created the resource group in the correct location, you can then deploy your ARM template Enter az deployment group create –name my-template-name –resource-group my-resource-group-name –template-file “path\\to\\azuredeploy.json” You will then be prompted to enter string values for the following parameters: appServiceWebAppName: web-app-name appServicePlanName: app-service-plan-name These two values will be the names of the two artifacts of the ARM template, which is creating both your Pv3 App Service Plan and your Web App. Verify Deployment Once you have completed the steps above, you can head over to the portal and search for the resource group you just created to verify the resources deployed from the ARM template. You have now successfully deployed to the new Premium v3 SKU creating the following resources: Resource Group App Service Plan Web App References Configure Pv3 tier for Azure App Service Reserved Instances are offered in 1 and 3 year options (Starting November 1st, 2020). ","categories": [],
+ "tags": ["windows containers"],
+ "url": "https://azure.github.io/AppService/2020/10/02/Deploy-your-resources-on-the-new-Premium-v3-SKU-with-an-ARM-template.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Zero to Hero with App Service, Part 7: Multi-tier web applications",
+ "excerpt":"The Azure App Service is offered as two deployment types: the multi-tenant service and the App Service Environment. In the multi-tenant service there are thousands of customers on the same infrastructure. Your apps are always secured but they share the network, address space, front ends, and some other components. In an App Service Environment you get a single tenant version of App Service that runs in your Azure Virtual Network. In this article, you will learn how to build network-secured, multi-tier web applications in the multi-tenant App Service. Multi-tier web applications The obvious question to start with is, what is a multi-tier web application? A multi-tier web application is an application with a front end that makes calls to one or more API applications behind it. By itself this is not a complex concept, but when a user wants to secure the API applications so they are not internet accessible the architecture becomes more complex. There are multiple ways to secure your API applications so that they can only be reached from your front end applications. They all involve securing your API application’s inbound traffic. There are multiple features that could be used for this purpose: Service endpoints secure the listening service. With Service Endpoints, the source address must be in an Azure Virtual Network subnet. Private endpoints prevent data exfiltration and secure the listening service. With private endpoints, you can reach the web app from anywhere that has network access to the private endpoint address. Access restrictions can lock down your inbound traffic to a set of address blocks. Each of those features satisfies a specific situation and there are trade offs. Access restrictions are useful if you have public address access points like NAT devices or perhaps a virtual network device with a dedicated public address. If you use service endpoints, you do not add any new resources to your subscription and are able to use one subnet. If you use private endpoints you will add a new top level resource, add Azure DNS private zones to your VNet and will require two subnets. Let’s now dicsuss each of these options in greater detail. Service endpoints To configure a multi-tier application using service endpoints to secure your API application, you need to use VNet Integration with your front end app and service endpoints with your API app. Set service endpoints on the integration subnet used by your Front End application. This solution is fast to set up and easy as well. If you have multiple front end apps, the configuration is the same if all of the front end apps are in the same App Service plan. With VNet Integration, the apps in the same App Service plan can use the same integration subnet. If you have additional front end applications in separate App Service plans, you will need to use multiple integration subnets. In this situation, service endpoints must be configured against each of the integration subnets. With VNet Integration, you cannot have more than one App Service plan configured with a subnet. If you have multiple API apps and multiple front end apps from separate App Service plans, you need to configure VNet Integration from each front end app and then service endpoints on each API app against the integration subnets. As you add front end applications, you need to configure service endpoints with each dependent API application. This means service endpoints are great at smaller scale. It can quickly get out of hand if you have many–or an ever increasing number of–front end applications with multiple API applications. Managing the configuration can be confusing as the number of front ends grows. Private endpoints With private endpoints, the configuration is both easier and harder. It is easier in that when you place a private endpoint in your VNet for an app, you are done managing the inbound traffic to your API app. Unlike with service endpoints, there is no additional configuration to your API app as you add new front end consumers. It is harder because setting up private endpoints creates a new, top-level resource and Azure DNS private zones. If you have one front end app or more than that, the configuration is the same. You set up VNet Integration with the same VNet that your API app has a private endpoint in. You also have private endpoints configured on your API application. If you have more than one front end app, the only difference is that this second front end app needs VNet Integration to be configured with it. If this additional front end application is in a different App Service plan, it will use a separate subnet. Each time you use VNet Integration from another App Service plan, you will need another subnet for integration. If you have multiple API applications, you will need multiple private endpoints. Those private endpoints can be in the same subnet, or not. Private endpoints are more flexible in this regard than VNet Integration. Once your API application has exposed itself with a private endpoint, any front end app that integrates with that VNet should be able to reach it. At a small scale, private endpoints incurs more overhead. You will have more to manage and maintain than with service endpoints. On the other hand, private endpoints are a solution for data exfiltration concerns. They also do better at scale as it is easy to add more front end applications. Access restrictions With access restrictions you can secure inbound traffic to a set of IP address blocks. This is useful when you want to lock your traffic to a set of egress devices. You can also use it with other edge protection services such as Azure Front Door. With respect to using it directly with multi-tier applications, you can secure your API applications to the egress addresses used by your front end applications. The problem with this approach is that the outbound addresses are shared with all of the other customers in the same scale unit. From a security review perspective it doesn’t look as secure as service endpoint or private endpoint based solutions. So while it is possible and worth noting, it is not recommended to use access restrictions to create multi-tier web applications. ","categories": [],
+ "tags": ["zero to hero"],
+ "url": "https://azure.github.io/AppService/2020/10/05/zero_to_hero_pt7.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "CPU Diagnostics Part 1: Identify and Diagnose High CPU issues",
+ "excerpt":"This is part one of our deep dive on Diagnosing CPU utilization issues in Azure App Service. In this post, you will learn about measuring CPU utilization for all apps hosted in an App Service Plan and identifying apps that are consuming maximum CPU resources. This post applies to Windows web apps on Azure App Service. First, we will cover troubleshooting tools for debugging Web Apps running on Azure App Services for Windows. These steps can be applied to apps built using any framework such as ASP.NET, Node, PHP, or Java running on a dedicated hardware tier (Basic or higher). Open a browser to the Azure Portal Navigate to one of oyur web apps On the left navigation bar, click the Diagnose and Solve Problems tab Select Availability and Performance section on the portal. On this page, you can see an overview of your app’s health as well as various topics related to availability and performance. The time duration for the graph’s defaults is the last 24 hours, but you can modify it if needed. The main topics presented are as follows: Failed Requests: Percentage of requests that have failed within the specified time range. Performance: Response time at the 90th percentile for the specified time range. CPU Usage: Maximum percentage of CPU Usage per instance over the specified time range. Memory Usage: Maximum Private bytes of memory usage for the current app. Analyze high CPU usage High CPU Analysis helps with troubleshooting issues related to the CPU. Click on the High CPU Analysis on the left-hand menu. Click the App Service Plan Density. This check will ensure the App Service Plan is not over the safe limit or overstuffed due to many apps in the service plan. In the post, we are only running three apps in the App Service Plan which is within safe limits for the SKU. Expand the insight for One Web App Causing High CPU Usage. This will identify the app consuming the maximum CPU resource on the App Service Plan. Notice the app demohighcpu is consuming the highest CPU. This is different from the app we are currently looking at demotroubleshootingapp. The tool suggests to further debug the app demohighcpu. Inspect CPU usage by instance Below you can see the overall CPU usage for all the instances associated with the App Service Plan. In this example the app is running in two instances that are consuming high CPU. Click on the drop-down arrow for Overall CPU Usage per Instance. Hover over the graph of Overall CPU Usage Per Instance. You can see CPU consumption of each instance. CPU Drill Down Below the graph you can see a drill down view that displays the App-level CPU consumption for the app running on the same App Service plan. This tool identifies each individual apps running in the instance. By default, the instance with the maximum CPU usage will display first. In this example we can see the CPU maximum usage and average of demohighcpu. App Level CPU Consumption Next, you can see a process level breakdown of each app. By default, the app with the maximum CPU is preselected. Next to Select the app, click on the app name. A drop-down view appears. You can switch between apps running on the same app service plan. In the example, you can see a breakdown of the process name and process ID. What’s Next? After identifying the app causing high CPU, debug the app to identify why the CPU is high. The next article will go over the techniques you can use to debug the app. Some possible mitigations you can apply are: Restart the App as that may reduce the high CPU usage temporarily. Upgrading to the next tier can give you more resources if the app is consuming high CPU and you are on a lower tier. If multiple apps are experiencing high CPU due to an increase in requests, upgrading your App Service Plan to the next tier will allow it to benefit from an increase in scale. Isolating some apps to a dedicated app service plan can reduce the impact of other essential apps. In the example, we saw demohighcpu is consuming the maximum CPU. Next, we will debug the app further to identify the cause of the high CPU in the next post. If you want to watch an in-depth tutorial on this topic, click on the video below! ","categories": ["Diagnostics"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2020/10/05/Diagnose-App-with-High-CPU.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "General Availability of Private Endpoint for Web App",
+ "excerpt":"We are happy to announce Private Endpoint for Web App is now Generally Available in all Azure public regions, for both Windows and Linux apps, containerized or not. To use Private Endpoint your app must be hosted on PremiumV2, PremiumV3, or Function Premium plan. Private Endpoint enables you to consume your app through a specific IP address located in your Azure Virtual Network (VNet), eliminating the exposure of your app to the public Internet. Private Endpoint provides at the same time a solution to remove the data exfiltration risk. You can secure your VNet with NSG denying any outbound flow and a Private Endpoint will let you go only to the specified app linked to this endpoint. Private Endpoint vs Service Endpoints Service Endpoints are used to secure the app to only being reachable from specific subnets. Private Endpoint provides a way to expose your app on an IP address in your VNet and removes all other public access. This not only provides security for the app but can also be combined with Network Security Groups (NSG) to secure your network and prevent data leakage. Private Endpoint vs App Service Environment Having your app only accessible on a private address in your VNet is something that was previously only possible by using an ILB App Service Environment or an Application Gateway with an internal inbound address. The difference between using Private Endpoint and an ILB ASE is that with an ILB ASE you have single tenant system that can host many apps behind one IP address in your VNet. With Private Endpoint, your app runs in the public App service and you have only one app behind one IP address. If you want to apply network security external to your application, then you still only get that with an ILB ASE. If you only need a private address in your VNet, then Private Endpoint can give you that. Private Endpoint combined with VNet integration Private Endpoint provides a private IP address for inbound traffic only to your app. It does not enable your app to make outbound calls into your network. If you want to have all inbound and outbound in your VNet, then you need to use both Private Endpoint and Regional VNet Integration in two separate subnets. With Private Endpoint you can secure the inbound and with VNet Integration you can secure the outbound. To get started, read the documentation here ","categories": ["networking"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2020/10/06/private-endpoint-app-service-ga.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Docker Hub authenticated pulls on App Service",
+ "excerpt":"Starting November 1st, 2020. Docker will be introducing rate limits on unauthenticated pull requests from Docker Hub. These limits are based on the account type of your personal or organizations Docker Hub account. In preparation of the incoming rate limits, App Service recommends that you authenticate your Docker Hub pull requests by updating your Public Repository Access containers on App Service to Private to mitigate any potential impact or move your container images to Azure Container Registry (ACR) as the source of your pulls. To learn more about Docker Hubs rate limits, see the Docker announcement. For additional info on container pulls and its overall impact, see this Open Container Initiative blog for Consuming Public Content. Authenticate Docker Hub pull requests To make sure your pull requests from Docker Hub are authenticated first, set your Docker Hub repository to Private to require your username and password for pulls from the registry. Then, follow the instructions below to authenticate your pulls from Azure: Go to Container Settings Under Repository Access, set your access level to Private Enter your Docker Hub Login and Password Click Save at the bottom of the screen. Go to the Overview page of your resource and Restart your container Now you should be able to successfully pull from your Private Docker Hub repository with an authenticated pull. Azure Container Registry Another option available is to import your images from Docker Hub to Azure Container Registry (ACR) as the source of your container pulls. ACR enables you to build, store, and manage your Docker containers on Azure. To create a new ACR resource, follow the instructions in this doc. Once you have created your ACR resource, you can import your Docker Hub containers to ACR using the following Azure CLI commands in Powershell: Use az login to connect to Azure Run az acr import –name my-registry –source docker.io/registryname/image-name:tag –image image-name:tag Once this runs, you can validate that your image has been imported to ACR by going to your Azure Container Registry resource and viewing your Repositories. To learn more, please see the ACR documentation to import from docker hub and consuming public content with ACR tasks. ","categories": [],
+ "tags": ["Docker"],
+ "url": "https://azure.github.io/AppService/2020/10/15/Docker-Hub-authenticated-pulls-on-App-Service.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "A/B Testing with App Service, Part 3: Analyzing the telemetry",
+ "excerpt":"This is the third article in our guide for A/B testing with App Service. The first article shows how to set up your client-side project. The second article shows how to configure your backend. Share your thoughts in the comments section. Now that our client-side and backend projects are configured, we can analyze the data and compare results using Application Insights. Open the Azure Portal and open your Application Insights resource that you created in the first article. On the left side, open Logs under Monitoring. Example 1: Comparing request duration This example will show three slots. The staging slot is where our main branch is deployed to every time there is a push to the main branch. The other two slots, labeled 219 and 230, are both pull requests targeting the main branch. We are using App Service’s deployment slots as a staging environment to deploy the pull requests on so we can test them before merging. Our goal in this example is to compare the average request durations for an important API call in the application. If we identify that one of the pull requests regresses the performance of that API, then we can investigate the PR’s changes more closely so we don’t regress performance in production. The query Let’s walk through the query step-by-step. We will use the dependencies table which shows outbound calls from our client-side application. Next, create two columns using the extends command. The first column, time_bin, bins the timestamp into 5 minute windows which makes our data less noisy. The other column, slot, parses the slot name from the customDimension column. dependencies | extend time_bin = bin(timestamp, 5m), slot = tostring(parse_json(customDimensions).slot) We will also specify a time window of 24 hours, and filter the rows to show only POST calls to /api/flights/reserve. You can expand or narrow the time window depending on the amount of telemetry your application emits. And you should also change the API path to a valid request in your application. On the last line, project drops all columns except for slot, time_bin, and duration. | where timestamp > ago(24h) and name == \"POST /api/flights/reserve\" | project slot, time_bin, duration Before we render the timechart, use the evaluate pivot(..) command to rotate the table by turning the unique values in the slot column into multiple columns. This command will also take the average request duration by each time_bin and slot. | evaluate pivot(slot, avg(duration)) | render timechart with ( title=\"Request duration by slot\") The graph When the query is executed, you should get a graph similar to the one shown below. Each line represents a deployment slot. The y-axis shows the request duration, and the x-axis shows the time. In the example shown below, we can see that customers that are routed to the slot “230” are experiencing very long request durations. Knowing this, we can investigate the changes in that Pull Request and fix the problem before merging. Example 2: Comparing custom metrics You can use Application Insight’s telemetryClient.trackMetric() and telemetryClient.trackEvent() methods to track custom metrics and events. In this scenario, we are emitting a custom metric to track the average duration of a database query in milliseconds. You could also track the time spent for other backend operations, such as heavy data processing or I/O operations. The query Your custom metrics are tracked in the customMetrics table. The first step is to filter the custom metric rows to the metric of interest, which is query_time in this case. Like before, create a new column, slot, from the customDimensions table. Next, take the average value for each slot. customMetrics | where name == \"query_time\" | extend slot = tostring(parse_json(customDimensions).SLOT_NAME) | summarize avg(value) by slot The final step is to render a bar chart and clean up the labels. The order by slot ensures that the bars of the bar chart are always rendered in the same order. | order by slot | render barchart with ( title=\"Average query time by slot\", ytitle=\"Query time in ms\", xtitle=\"Slot name\") The graph Similar to the previous example, this chart shows us that Pull Request 232 is greatly improving the query performance under real-world traffic. This is a good sign, and gives developers or QA teams another data point for the PR review process. Monitoring dashboards You can use Azure Monitor Workbooks to monitor your experiments and quickly gauge results across your queries. To get started, open your Application Insights resource in the Portal and open the Workbooks blade. Then click + New. The workbook will open with a default Markdown section and graph. Click the Edit button below the graph and paste one of the earlier queries. Click Done Editing at the bottom to save the query. You can also annotate your workbook with notes, links, and lists using Markdown. Resources Reference Documentation Kusto Query tutorial Parse JSON method ","categories": ["deployment"],
+ "tags": ["A/B Testing"],
+ "url": "https://azure.github.io/AppService/2020/10/20/ab_testing_app_service3.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": ".NET 5 on App Service",
+ "excerpt":"We are happy to announce that App Service now supports .NET 5 applications across all public regions and scenarios on both Windows and Linux App Service plans. The App Service and .NET teams worked closely together to deliver this functionality on the same day as .NET 5 reached GA (see .NET 5 GA announcement). Going forward every new preview release of .Net 6 and beyond will be available on App Service on DAY 0 of it’s release. This is a first for the App Service platform and was achieved through a new Early Access feature (learn more about App Service Early Access). App Service Early Access was developed in close cooperation with the .NET team and we are very excited to have .NET 5 GA release be the first runtime deliver through this feature. While we are starting with .NET 5 early access we plan to use the Early Access mechanism to deliver faster and more frequent updates for all the App Service supported languages including Node and Python and others. If you want to learn more, be sure to checkout our session during .NET Conf 2020 where we’ll talk about how to modernize .NET Framework Apps, by migrating to App Service and 5 ways to get started with .NET 5 on App Service. ","categories": [],
+ "tags": ["dotnet"],
+ "url": "https://azure.github.io/AppService/2020/11/10/Dot-Net-5-on-App-Service.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Azure App Service and Azure Functions on Azure Stack Hub 2020 Q3 Released",
+ "excerpt":"The 2020 Q3 update to Azure App Service on Azure Stack Hub is now available. This release updates the resource provider and brings the following key capabilities and fixes: Updates to App Service Tenant, Admin, Functions portals and Kudu tools. Consistent with Azure Stack Portal SDK version. Updates Azure Functions runtime to v1.0.13154. Updates to core service to improve reliability and error messaging enabling easier diagnosis of common issues. Updates to the following application frameworks and tools: ASP.NET Core 2.1.22 ASP.NET Core 2.2.14 ASP.NET Core 3.1.8 ASP.NET Core Module v2 13.1.19331.0 Azul OpenJDK 8.42.0.23 8.44.0.11 11.35.15 11.37.17 Curl 7.55.1 Git for Windows 2.28.0.1 MSDeploy 3.5.90702.36 NodeJS 14.10.1 NPM 6.14.8 PHP 7.4.5 Tomcat 8.5.47 8.5.51 9.0.273 9.0.31 Updated Kudu to 90.21005.4823 Updates to underlying operating system of all roles: 2020-10 Cumulative Update for Windows Server 2016 for x64-based Systems (KB4580346) 2020-09 Servicing Stack Update for Windows Server 2016 for x64-based Systems (KB4576750) Defender Definition 1.325.755.0 Cumulative Updates for Windows Server are now applied to Controller roles as part of deployment and upgrade All other fixes and updates are detailed in the App Service on Azure Stack Hub 2020 Q3 Release Notes The App Service on Azure Stack Hub Update 8 build number is 89.0.2.15 Please review the release notes and all known issues prior to updating your installation of Azure App Service on Azure Stack Hub. You can download the new installer and helper scripts: Installer Helper Scripts Please read the updated documentation prior to getting started with deployment: 2021 Q1 Update Release Notes Prerequisites for deploying App Service on Azure Stack Hub Deploy the App Service Resource Provider for new deployments Update the App Service Resource Provider for updating existing deployments ","categories": [],
+ "tags": ["Azure Stack"],
+ "url": "https://azure.github.io/AppService/2020/11/12/App-Service-on-Azure-Stack-Hub-2020-Q3-Update-Released.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "NAT Gateway and app integration",
+ "excerpt":"The Azure App Service has quite a few networking integration capabilities but, until now, did not support a dedicated outbound address. We are very happy to say that now you can use a NAT Gateway with your web app in the Azure App Service. The NAT Gateway solves another problem beyond providing a dedicated internet address. You can also now have 64k outbound SNAT ports usable by your apps. One of the challenges in the App Service is the limit on the number of connections you can have to the same address and port. There are more details on this problem in the Troubleshooting intermittent outbound connection errors guide. To use a NAT Gateway with your app, you need to Configure Regional Vnet Integration with your app as described in Integrate your app with an Azure virtual network Route all the outbound traffic into your Azure virtual network Provision a NAT Gateway in the same virtual network and configure it with the subnet used for VNet Integration After these changes have been made, the calls made by your app to the internet will go out the NAT Gateway. You can alternatively use an Azure Firewall if you want to control egress by FQDN but it won’t give you the 64k outbound SNAT ports. To use a NAT Gateway you need to use Regional VNet Integration. To use Regional VNet Integration your app needs to be in a Standard, Premium V2 or Premium V3 App Service plan. This feature will work with Function apps as well as web or API apps. There are some Standard App Service plans that can’t use Regional VNet Integration as they are in older App Service deployments. ","categories": ["networking"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2020/11/15/web-app-nat-gateway.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Hosting .NET 5 Applications on Azure App Service",
+ "excerpt":"With the newly announced launch of .NET 5 General Availability, App Service is offering immediate support for .NET 5 via Early Access stack. The new Early Access stack feature on app service enables faster and more frequent updates for new versions of supported languages. To learn more about Early Access, please visit the Early Access Runtime document. .NET 5 (Early Access) applications are supported across all public regions for both Windows and Linux scenarios. The following outlines how you can use .NET 5 with App Service via the Azure Portal, GitHub Actions, Azure DevOps, and custom containers. For Sovereign cloud deployment progress, follow this GitHub issue for periodic updates Local Setup In order to develop with .NET 5 locally you will first need the newly released .NET 5 SDK . If you are using Visual Studio you will need to download and use the latest Visual Studio 2019 version(16.8) which will allow you to create a .NET 5 application from the Visual Studio UI and publish your code to your web app. If you would like to upgrade an existing project to .NET 5, please see this announcement to get started. Create a .NET 5 Web App in the Portal The first option you must create and deploy a .NET 5 application is directly through the portal for both Windows and Linux apps. You will create a Web App like you normally would (see our Quickstart for details). When selecting the runtime stack you will see an option to choose .NET 5 (Early Access). Choose this option when creating your application, review your web app configuration and create the .NET 5 web app. When your web app is published you are now ready to deploy code to your application through Visual Studio or with continuous deployment via GitHub Actions and Azure DevOps. If deploying with Visual Studio using right-click Publish, you’ll need to create the web app in the portal first using the directions above. Full support with Visual Studio will be available by the end of the month. Deploying via CLI Another option to create a Web App with a .NET 5 runtime is through the Azure CLI with the az webapp create and az webapp up commands. Before you run these commands, make sure you are up to date on the most recent version of the Azure CLI first. Once you are on the latest version, you can run az webapp list-runtimes -linux or az webapp list-runtimes (for windows) and you will find “DOTNET|5.0” in the list of available runtimes. Next run the follwing command to create a web app with a .NET 5 runtime. az webapp create -g MyResourceGroup -p MyPlan -n MyUniqueAppName --runtime \"DOTNET |5.0\" --deployment-local-git Verify that your web app was created on the Azure portal You may also use the az webapp up command to deploy to App Service, which allows you to deploy your code quickly from a local workspace where the code is present. Use the az login command to login into Azure Go to the source of where your code is and run the command where your code is located (for .NET apps, this is where the .csproj is located). az webapp up -n myUniqueAppName This will deploy your .NET 5 application directly to App Service. For more arguments and examples of az webapp up, please see the documentation. Continuous deployment with GitHub Actions GitHub Actions enables you to automate your deployment workflows through a defined YAML file added to your repository containing a collection of actions that run when triggered. Before the workflow file is setup, you will need to grab azure credentials by creating a service principal and save them as a secret in GitHub to add to your workflow file. If you would like to setup GitHub Actions through the App Service Deployment Center to automatically generate a workflow file, see our documentation. Create a Service Principal Our workflow will use a Service Principal to authenticate with Azure when deploying the container to App Service. A service principal is an Active Directory Identity created for use with automation scenarios, such as GitHub Actions. Run the following command in Azure CLI in PowerShell to get the credentials needed to run the login action. The output of this command will be a collection of key value pairs that you’ll need to add to your GitHub secrets. az ad sp create-for-rbac --name \"<appservice-name>\" --role contributor \\ --scopes /subscriptions/{subscription-id}/resourceGroups/{resource-group} \\ --sdk-auth Copy the output into your GitHub secrets to use as your AZURE_CREDENTIALS secret. { \"clientId\": \"<GUID>\", \"clientSecret\": \"<GUID>\", \"subscriptionId\": \"<GUID>\", \"tenantId\": \"<GUID>\" } Secure Secrets Since we are using sensitive information that you don’t want others to access, we will use GitHub secrets to protect our information. Create a secret by following the directions here. Add the GitHub secrets variables below with your own secrets appropriate from each resource. AZURE_WEBAPP_NAME: web-app-name AZURE_CREDENTIALS: the JSON output of the az ad sp create-for-rbac command Setup Workflow file To setup your GitHub workflow file, go to the Actions tab in your repository and set up a workflow yourself. This will lead you to an editing page where you can add a workflow. At this point you can save and commit the code. Remove the default code in the workflow file and replace it with the yaml sample below. name: .NET Core on: [push] env: AZURE_WEBAPP_PACKAGE_PATH: '.' # set this to the path to your web app project, defaults to the repository root DOTNET_VERSION: '5.0.100' # this is set to the GA version of .NET 5 jobs: build: runs-on: windows-latest steps: # Checkout the repo - uses: actions/checkout@master - uses: azure/login@v1 with: creds: $ # Setup .NET Core SDK - name: Setup .NET Core uses: actions/setup-dotnet@v1 with: dotnet-version: $ # Run dotnet build and publish - name: dotnet build and publish run: | dotnet restore dotnet build --configuration Release dotnet publish -c Release -o '$/myapp' # Deploy to Azure Web apps - name: 'Run Azure webapp deploy action using azure credentials' uses: azure/webapps-deploy@v2 with: app-name: $ # Replace with your app name package: '$/myapp' - name: logout run: | az logout Before you save and commit the code you will need to adjust the ‘runs-on:’ argument to either ‘windows-latest’ or ‘ubuntu-latest’ depending on your application. Once that is done you can hit Save and commit. The workflow file will use the secret you created earlier from ‘secrets.AZURE_CREDENTIALS’ and secrets.AZURE_WEBAPP_NAME’ to run the actions and deploy your code. Verify that it has deployed by going to your Web App in the Azure Portal and launching your application. Continuous deployment with Azure DevOps Azure DevOps is another option for deploying your code with continuous deployment to your .NET 5 Web App enabling you to host, build, plan and test your code through Azure Pipelines. To get started, you will need to first Create a new project and Import a Git repo. Once you have your code uploaded to your DevOps project, you can start building your Pipeline to deploy to your Web App. Go to Pipelines in the left menu and click the Create Pipeline button on the following page Connect to your Azure Repos Git, Select your repository and Configure your pipeline choosing the ASP.NET option. Azure DevOps will suggest a pipeline configuration, but we will be replacing it with the example below After the above step you will be taken to the Review tab. Replace the suggested code with the template below: If you are using Windows, replace the vmImage: value with windows-latest trigger: - master pool: vmImage: 'ubuntu-latest' variables: buildConfiguration: 'Release' steps: - task: UseDotNet@2 inputs: packageType: 'sdk' version: '5.0.100' includePreviewVersions: true - task: DotNetCoreCLI@2 displayName: Build inputs: command: build projects: '**/*.csproj' arguments: '--configuration $(buildConfiguration)' # Update this to match your need)' - task: DotNetCoreCLI@2 inputs: command: publish publishWebProjects: True arguments: '--configuration $(BuildConfiguration) --output $(Build.ArtifactStagingDirectory)' zipAfterPublish: True # this code takes all the files in $(Build.ArtifactStagingDirectory) and uploads them as an artifact of your build. - task: PublishBuildArtifacts@1 inputs: pathtoPublish: '$(Build.ArtifactStagingDirectory)' artifactName: 'myWebsiteName' Now Save and run your build pipeline. This will build your application and create an artifact that will be used for your release pipeline. After the run, you can create your release pipeline. Go to Releases in the left menu area and click the New Pipeline button on the following page Next, select the Azure App Service deployment template and hit Apply In the following page, select the +Add an artifact box on the left to add the artifact we previously created in the Build pipeline Choose your Source(build pipeline) and hit the Add button Once that is set you’ll want to setup the trigger by clicking the lightning bolt icon in the top right of your artifact A new window will pop up. Switch the Continuous deployment trigger to Enabled and close the window Next, you can click on the 1 job, 1 task link to setup your deployment stage Fill in your Parameters under “Stage 1” Azure subscription: your azure subscription App type: Web App on Linux OR Web App on Windows App service name: your App Service name After your “Stage 1” parameters are filled in, click the Run on agent box and modify the Agent Specification to run the appropriate ubuntu or windows agent Now you can click the Deploy Azure App Service box and review the pre-filled parameters. Update any parameters if needed Click on the Save icon on the top right menu Click OK for the folder location and Create release Select the “Stage 1” trigger from the drop down menu and click Create Once the release is created it will be named “Release-1” and you will be able to see a similar screen as above. Click Deploy under the Stage 1 and Deploy again on the next screen to start your deployment to your Azure App Service Web App. Verify that your application has been published by launching your Web App in the Azure Portal. Container Deployment with .NET 5 .NET 5 applications are easily deployable to a custom container on App Service using Linux or Windows. When deploying a container, you are packaging the application and its dependencies into a Linux or Windows based image to run on the App Service platform enabling your application to be more portable. The steps for containerizing a .NET 5 application are the same as it would be for other applications. Right-click your project Add -> Docker Support Your .NET 5 project will have a new Dockerfile added with the .NET 5.0 base image and SDK ready for you to publish. For more information on .NET 5 Docker images, please see the official images for ASP.NET Core runtimes on docker. If you are using Windows your base image will be FROM mcr.microsoft.com/dotnet/aspnet:5.0 AS base using the FROM mcr.microsoft.com/dotnet/sdk:5.0 AS build SDK. For Linux applications, your base image will be FROM mcr.microsoft.com/dotnet/aspnet:5.0-buster-slim AS base using the FROM mcr.microsoft.com/dotnet/sdk:5.0-buster-slim AS build SDK. FROM mcr.microsoft.com/dotnet/aspnet:5.0 AS base # For Windows apps # FROM mcr.microsoft.com/dotnet/aspnet:5.0-buster-slim AS base # For Linux apps WORKDIR /app EXPOSE 80 EXPOSE 443 FROM mcr.microsoft.com/dotnet/sdk:5.0 AS build # For Windows apps # FROM mcr.microsoft.com/dotnet/sdk:5.0-buster-slim AS build # For Linux apps WORKDIR /src COPY [\"dotnet5app/dotnet5app.csproj\", \"dotnet5app/\"] RUN dotnet restore \"dotnet5app/dotnet5app.csproj\" COPY . . WORKDIR \"/src/dotnet5containerwindows\" RUN dotnet build \"dotnet5app.csproj\" -c Release -o /app/build FROM build AS publish RUN dotnet publish \"dotnet5app.csproj\" -c Release -o /app/publish FROM base AS final WORKDIR /app COPY --from=publish /app/publish . ENTRYPOINT [\"dotnet\", \"dotnet5app.dll\"] After you have added Docker support, you will publish it to a registry, and create your App Service as usual. See our documentation for more detail on deploying a containerized application. ","categories": [],
+ "tags": ["dotnet"],
+ "url": "https://azure.github.io/AppService/2020/11/16/Hosting-dotnet-five-Applications-on-Azure-App-Service.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "App Service Environment v3 public preview",
+ "excerpt":"We are happy to announce the public preview of the App Service Environment v3 (ASEv3). The ASEv3 project is a realization of several years of infrastructure development to enable a best in class Isolated application hosting PaaS service. This release has been driven directly by customer feedback and satisfies multiple situations that were not covered by ASEv2. The App Service Environment (ASE) is a single tenant instance of the Azure App Service that injects into a customers Azure Virtual Network (VNet). Until now, the ASE has required many networking dependencies that must be allowed in the customer VNet in order for the ASE to operate properly. ASEv3 has several major changes in the system architecture that serve to remove all management traffic from the customer VNet. The end result is a single tenant system that has no internet hosted dependencies in the customer network. Customers can secure their workloads to their heart’s content without hurting the ASE and Microsoft can secure the infrastructure without hurting customer workloads. This system enables both parties to apply all of the security they want to without affecting each other. The pricing for ASEv3 is changed from ASEv2. With ASEv3 you just pay for the Isolated V2 SKU rates for your App Service plans. There is no stamp fee. If your ASEv3 is totally empty, you are charged as if you had one App Service plan with one instance of I1v2. The hosts used in ASEv3 are the same type used with Premium V3. The size options in ASEv3 are: 2 core 8 GB RAM, 4 core 16 GB RAM, 8 core 32 GB RAM. With respect to networking dependencies it should be reiterated that there are no required Network Security Groups, no required route tables and no required service endpoints. You can route and filter things with an eye centered on just what your apps need. If you want to configure your apps to force tunnel all outbound traffic on-premises, you can do so. If you want to send all outbound traffic through an NVA, no problem. And if you want to put a WAF device to monitor all inbound traffic to your ASEv3, you can add that without any limitations. There are a number of limitations as this preview starts off. Some features that are available in ASEv2 are not available in the current form of ASEv3. Missing features will be added as the preview goes on. To get a more complete overview on ASEv3, read the ASEv3 focused App Service Environment overview. If you want to create a new ASEv3, read Creating an App Service Environment v3. ","categories": ["networking"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2020/11/18/asev3-public-preview-announcement.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "New App Service Anti-virus Logs in Public Preview",
+ "excerpt":"App Service has added support for anti-virus scans which can send logs to a Storage account, Log Analytics workspace, and Even Hubs for better application monitoring. The new log support, available in Diagnostic settings as “AppServiceAntivirusScanAuditLogs”, helps customers better monitor the site content of their web app. This logging feature is available for both Windows and Linux based web apps using our Premium App Service plans. This feature is currently in public preview and has certain feature limitations and known issues which will be covered in this blog and will be updated accordingly. The anti-virus scan leverages Microsoft Defender and will run once daily on your website content. There will be a log regardless of if there are any infected files detected. If there are infected files detected, the log will provide a list of infected files. If there are no infected files detected, the log will show an empty list of infected files. Feature Limitations The feature has a few limitations (see list below). Should you meet any of the limitations, the logs will show an error message explaining why it didn’t scan your web app. The following limitations are: Will scan your files once a day (currently can’t control when the scan runs) Will not scan web apps with more than 1GB of site content Will not scan web apps with more than 10,000 files in the site content If your web app has more than 1GB of content or more than 10,000 files the scan will not run and your logs will show an error message explaining that the pre-requisite was not met. Known Issues For web apps with more than 10,000 files you will see the following error message in your logs: “Internal service error occurred. Please contact support.”. In the next release, the logs will reflect the correct error message. Sample Logs Sample of log without scanned virus: { \"time\": \"2020-10-10T22:54:13.7712259Z\", \"ResourceId\": \"/SUBSCRIPTIONS/XXXXX-XXXXX-XXXXX-XXXXX-XXXXX/RESOURCEGROUPS/XXXXX/PROVIDERS/MICROSOFT.WEB/SITES/XXXXX\", \"Category\": \"AppServiceAntivirusScanAuditLogs\", \"OperationName\": \"AntivirusScan\", \"Properties\": { \"TimeStamp\": \"2020-10-10T22:54:13.7254874Z\", \"Category\": \"AppServiceAntivirusScanAuditLogs\", \"ScanStatus\": \"Succeeded\", \"TotalFilesScanned\": 358, \"NumberOfInfectedFiles\": 0, \"ListOfInfectedFiles\": [], \"ErrorMessage\": null } } Sample of log with scanned virus: { \"time\": \"2020-10-10T22:54:13.7712259Z\", \"ResourceId\": \"/SUBSCRIPTIONS/XXXXX-XXXXX-XXXXX-XXXXX-XXXXX/RESOURCEGROUPS/XXXXX/PROVIDERS/MICROSOFT.WEB/SITES/XXXXX\", \"Category\": \"AppServiceAntivirusScanAuditLogs\", \"OperationName\": \"AntivirusScan\", \"Properties\": { \"TimeStamp\": \"2020-10-10T22:54:13.7254874Z\", \"Category\": \"AppServiceAntivirusScanAuditLogs\", \"ScanStatus\": \"Succeeded\", \"TotalFilesScanned\": 358, \"NumberOfInfectedFiles\": 1, \"ListOfInfectedFiles\": [ \"/IAmVirus.txt\" ], \"ErrorMessage\": null } } ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2020/12/09/AzMon-AppServiceAntivirusScanAuditLogs.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Using GitHub Actions for Python Applications",
+ "excerpt":"GitHub announced CI/CD support through GitHub Actions which became generally available at GitHub Universe in November 2019. Since then, many Azure services have released actions and integrations to make developers’ workflows more efficient. The App Service Deployment Center guides developers to set up GitHub Actions to deploy their web apps. Since then, our teams have received requests for guidance and best practices when setting up CI/CD (Continuous Integration and Delivery) for deploying Python apps to App Service. This article assumes you are familiar with CI/CD pipelines. If you are not familiar, read this article for an overview. Building and deploying Python apps A simple CI pipeline for a Python application might have three steps: pip install the packages, run tests, and send the application to the server. This seems like a sound approach… right? That pattern might work for simple applications, but if the application uses packages that rely on the Operating System (such as database drivers, scipy, or scikit-learn), you may run into problems once the application starts on the server. This is because Python will make absolute references to the OS libraries, and if there are any differences between the libraries installed on the CI machine and the server, then the application will not run correctly. This may seem like an excellent opportunity to leverage Docker. With Docker, you can build a container image with the Python application’s dependencies already installed. From there, you ship the image to a host with Docker installed and “just run it”. However, this option is not without its drawbacks. You will need to manage a container registry and configure your network such that the CI and production servers can securely access it. The Dockerfile also becomes part of the application repository, so you or your team will be responsible for updating the base OS and configuring the container. Fun fact: Docker was publicly announced at PyCon in 2013 Nylas wrote an excellent article on this topic last year. Their article covers even more deployment technologies for Python applications. Check their article to learn about your other options. Now let’s learn more about deploying Python applications to App Service without managing Docker images. Deploying to App Service For those not familiar with Azure App Service, it is a platform-as-a-service (PaaS) for hosting web and API applications. You can deploy your application code or a container image. The service has managed runtimes for Python, .NET, Node, Java, PHP, and Ruby. This gives developers the choice to use containers or to simply deploy their code and let the service manage the runtime for them. If you are setting up a CI/CD pipeline for your Python apps to App Service without using containers, you cannot simply pip install and deploy your app and packages to App Service (or any server) because the OS on your build server will most likely not match the runtime on Azure. To address this, simply create an app setting on your App Service named SCM_DO_BUILD_DURING_DEPLOYMENT with a value of true. This app setting will trigger the Oryx build pipeline to re-install your packages during deployment. Oryx is an open-source utility by Microsoft that automatically builds source code. Oryx runs in your web app’s SCM (site control manager) site. By setting this app setting, Oryx will pip install your dependencies on the runtime image so that the packages can take the appropriate dependencies on the OS libraries. Examples The sections below show example GitHub Actions workflows for building and deploying Python apps to App Service. Although the samples use GitHub Actions, you can use the same pattern on other CI/CD providers such as Azure DevOps or Jenkins. Prerequisites Before following the examples below, make sure you have done the following. Create a Python web app on Azure. Follow this quickstart to create a site. Create an Azure Service Principal. Follow this guide to create a Service Principal. A Service Principal is an identity in Azure Active Directory that is typically used for automation and accessing secrets. You will need to create a Service Principal so the GitHub Actions workflow Django See the example workflow for building and deploying a Django app. Fork this repository and create a secret with the Service Principal. Name the secret AZURE_SERVICE_PRINCIPAL. The workflow starts by checking out the repository to the build VM, setting up the desired Python version, and creating a virtual environment. - uses: actions/checkout@v2 - name: Setup Python version uses: actions/setup-python@v2 with: python-version: 3.8 - name: Create and start virtual environment run: | python3 -m venv venv source venv/bin/activate Once the virtual environment is activated, the dependencies are installed from the requirements.txt file. Next, we use manage.py to collect the static assets and run our unit tests. - name: Install dependencies run: pip install -r requirements.txt - name: Collect static run: python manage.py collectstatic - name: Run tests run: python manage.py test Assuming all those previous steps succeed, the files are uploaded for the next job. The virtual environment is not uploaded since it is not compatible with the runtime OS. A nice side-effect of uploading the files at the end of the job is that you can download the files from the Actions tab to debug or inspect the contents if a deployment fails. - name: Upload artifact for deployment jobs uses: actions/upload-artifact@v2 with: name: python-app path: | . !venv/ The second job begins by downloading the files we uploaded in the previous job, then logs into the Azure CLI using a Service Principal that you set as a secret earlier. - uses: actions/download-artifact@v2 with: name: python-app path: . - name: Log in to Azure CLI uses: azure/login@v1 with: creds: ${{ secrets.AZURE_SERVICE_PRINCIPAL }} Once the Azure CLI is authenticated, the job sets the SCM_DO_BUILD_DURING_DEPLOYMENT setting mentioned earlier. It also sets app settings to disable static collection (since that was done in the previous job), to run migrations on the database, and to set the Django environment to “production”. The POST_BUILD_COMMAND is a hook where you can execute commands following the runtime build. In this case, we’re running manage.py makemigrations && python migrate. You could apply database migrations as part of the CI workflow, but you would need to set the connection string as a secret, and if you have networking rules securing your database you will need to make the database accessible from the CI pipeline. In this case, migration will be applied from the Django app on App Service, so this assumes you have set the database credentials on the web app. Finally, the job deploys the code using the webapps-deploy action. - name: Disable static collection and set migration command on App Service uses: Azure/appservice-settings@v1 with: app-name: ${{ env.WEBAPP_NAME }} app-settings-json: '[{ \"name\": \"DISABLE_COLLECTSTATIC\", \"value\": \"true\" }, { \"name\": \"POST_BUILD_COMMAND\", \"value\": \"python manage.py makemigrations && python manage.py migrate\" }, { \"name\": \"SCM_DO_BUILD_DURING_DEPLOYMENT\", \"value\": \"true\" }, { \"name\": \"DJANGO_ENV\", \"value\": \"production\"}]' - name: Deploy to App Service uses: azure/webapps-deploy@v2 with: app-name: ${{ env.WEBAPP_NAME}} By default, the appservice-settings action will mask the inputs and obfuscate any occurences of those strings in logs. Set mask-inputs: false to disable this. Flask and Vue.js See the example workflow for building and deploying a Flask app with Vue.js. Fork this repository and create a secret with the Service Principal. Name the secret AZURE_SERVICE_PRINCIPAL. You also need to replace the placeholder value for the RESOURCE_GROUP environment variable at the top of the workflow file. This workflow begins similarly to the Django example by setting the Python version, creating a virtual environment, and installing the Python packages. Unique to this example, it also sets Node.js to the desired version since the job will need to install the Vue project’s dependencies and build it. - uses: actions/checkout@v2 - name: Set up Python uses: actions/setup-python@v2 with: python-version: 3.6 - name: Set up Node.js uses: actions/setup-node@v1 with: node-version: 12 - name: Install and build Vue.js project run: | npm install npm run build - name: Create and start virtual environment run: | python3 -m venv venv source venv/bin/activate - name: Install dependencies run: pip install -r requirements.txt - name: test with PyTest run: pytest --cov=app --cov-report=xml Once the Flask and Vue.js apps are built and tested the files are uploaded for the second job… except for the node_modules/ and venv/ directories. We want to exclude these directories and allow Oryx to install the dependencies on the runtime image like in the Django example. - name: Upload artifact for deployment jobs uses: actions/upload-artifact@v2 with: name: python-app path: | . !node_modules/ !venv/ The second job downloads the artifact, logs into the Azure CLI, and sets the SCM_DO_BUILD_DURING_DEPLOYMENT flag and FLASK_ENV to “production”. Unlike the Django example, the workflow sets the “startup-file” command to gunicorn --bind=0.0.0.0 --timeout 600 app:app. (Gunicorn is a WSGI HTTP Server commonly used for Python applications. Learn more about custom startup commands on App Service. - uses: actions/download-artifact@v2 with: name: python-app path: . - name: Log in to Azure CLI uses: azure/login@v1 with: creds: ${{ secrets.AZURE_SERVICE_PRINCIPAL }} - name: Configure deployment and runtime settings on the webapp run: | az configure --defaults ${{ env.RESOURCE_GROUP }} az webapp config appsettings --name ${{ env.WEBAPP_NAME }} --settings \\ SCM_DO_BUILD_DURING_DEPLOYMENT=true \\ FLASK_ENV=production az webapp config set --name ${{ env.WEBAPP_NAME }} \\ --startup-file \"gunicorn --bind=0.0.0.0 --timeout 600 app:app\" Finally, the application is deployed with the webapps-deploy action. - name: Deploy to App Service uses: azure/webapps-deploy@v2 with: app-name: ${{ env.WEBAPP_NAME}} ","categories": [],
+ "tags": ["Python"],
+ "url": "https://azure.github.io/AppService/2020/12/11/cicd-for-python-apps.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Deploying to Network-secured sites",
+ "excerpt":"With the recently-announced Private Endpoints integration you can block inbound access from the internet to your web app. Before this integration, developers would need to use an App Service Environment (ASE) if they wanted to host their network-secured applications on App Service. With the combination of the Virtual Network (VNet) and Private Endpoint integrations on App Service, you can secure your site’s inbound and outbound requests respectively. This is great for organizations that want the network security without the added cost of an ASE. However, if inbound access to your site is blocked, that can disrupt your existing delivery pipeline if you were not using Private Endpoints before. This article will walk through the process of installing an Azure DevOps agent on a Virtual Machine (VM) to deploy to a site secured with VNet and Private Endpoints. This solution works for ILB ASEs as well. This article assumes some familiarity with Virtual Networks. If you are new to Azure Networking, please see this Microsoft Learning Path. Solution Overview This guide will walk through the process of deploying a Virtual Machine Scale Set (VMSS) and web app into two subnets of the same virtual network. You wil use Azure DevOps to install a build agent on the virtual machines and configure your DevOps Pipeline to run on those agents. Finally, you will enable private endpoints so the site cannot be reached from the public internet. Prerequisites To follow this guide you will need the following: A valid Azure subscription An Azure DevOps organization and project A DevOps repository with a web application we can deploy to App Service Part 1: Set up resources First, let’s set up the Azure DevOps project and VM that will host the agent. Create a Virtual Machine Scale Set with Ubuntu Server 18.04 LTS. This process will automatically create a VNet as well. Once the VM Scale Set is created, open Azure DevOps and navigate to Project settings > Pipelines > Agent pools. Click Add pool and this will open a context menu. Under Pool type select “Azure virtual machine scale set”. Choose your subscription and the VM Scale Set you just created. You can configure the max number of machines for the scale set, the number to keep on standby, and more. Read more information here. Click Create to set up the agent pool. You can monitor the process under Diagnostics. Part 2: Configure networking features You now have a VM Scale Set with DevOps agents installed, all deployed within a VNet. Now you will create the web app and confirm that the VM’s and webapp can communicate over the virtual network. Create an Azure Webapp in the same region as the VM. Choose whatever runtime and operating system fit your application. Once the web app is created, go to Networking > VNet Integration. Add the site to the same virtual network as the VM. The VM and webapp cannot be in the same subnet, so you may need to create another subnet. With VNet integration enabled, the web app and VM can communicate over the virtual network. To test this, go to the web console for your site at https://my-linux-site.scm.azurewebsites.net/webssh/host on Linux apps, or https://my-windows-site.scm.azurewebsites.net/DebugConsole/?shell=powershell for Windows. Once the console is open, run the following command to ping the VM’s private IP. You can find your VM’s private IP from the Networking blade on the VM resource. It’s shown under “NIC Private IP”. root@87d2385265ad$ ping 10.0.0.5 # replace with your VM's private IP Now that the resources are in the same Virtual Network and can communicate over that network, let’s enable Private Endpoints on the web app. This will block inbound access to the web app from the public internet. In the Portal, go to your web app > Networking > Private Endpoint connections > Configure your private endpoint connections > + Add. This will open a context blade to configure the Private Endpoint. Provide a name, subscription, and Virtual network. Check the box to allow the service to integrate with Azure Private DNS zones. This will create a private DNS zone if one does not already exist, and set up the correct domain entries for your web app. Click OK to create the resources. Once the private link and DNS resources are created, open an SSH connection to your VM. Run the command below to ping the web app and confirm that you can reach the site from the VM. If you cannot reach the site from the VM, the DevOps agent won’t be able to either! curl your-site-name.azurewebsites.net You can also use nslookup to see how the private DNS entries ultimately map to the web app. Installing build tools on your VMs The virtual machines in your scale set may not come with the build tools that your pipeline will need (like Maven, NPM, or dotnet). To install these tools, you can add the Custom Script for Linux Extension. This extension allows you to upload a shell script that is executed whenever a new VM is provisioned in the scale set. So in this case, the shell script could install your necessary build tools. Part 3: Create the CI pipeline At this point the web app cannot be reached from the public internet but our VM can reach the site through the virtual network. Now let’s set up a DevOps Pipeline to build and deploy your application from the VM. Head back to Azure DevOps and go to Pipelines > New pipeline. Then select the location of your project. Once you choose your project, Azure DevOps will show some templates based on your stack. For example, I was given a starter pipeline to build my Java app with Maven and deploy it to App Service Linux. Click Show more if you don’t immediately see a good starter template. If you are not given a good template to deploy your app to App Service, use the generic starter template and add the Deploy to Azure Web App action. Next, specify the VMSS agent pool by adding the pool keyword on the pipeline. The value should be the name of your VMSS agent pool that you created earlier. trigger: - main pool: 'VMSS for private endpoints deployment' # This is the name of your agent pool steps: - task: AzureWebApp@1 displayName: 'Azure Web App Deploy: priv-endpoints-webapp' inputs: azureSubscription: 'aaaaaa-bbbb-cccc-dddd-eeeeeeeeee' appType: webAppLinux appName: 'priv-endpoints-webapp' package: 'app.jar' Finally, save and run the workflow! See the pipeline’s logs to monitor progress and check for any errors. Resources Using Private Endpoints for Azure Web App Integrate your app with an Azure virtual network Azure Private Link documentation Azure virtual machine scale set DevOps agents ","categories": [],
+ "tags": ["Deployment","Networking"],
+ "url": "https://azure.github.io/AppService/2021/01/04/deploying-to-network-secured-sites.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Migrate from Windows Azure Pack Websites to Azure App Service",
+ "excerpt":"As Windows Azure Pack Web Sites v2 heads towards the end of extended support in 2022, it is important for customers to plan to migrate their workloads from the platform. Windows Azure Pack Web Sites V2 is an on-premises, high density, multi-tenant web hosting for service providers and enterprise IT and provides an experience similar to the predecessor to Azure App Service, Azure Web Sites. The product is deployed on top of Windows Server 2012 R2 and is an optional add-on to Windows Azure Pack. Benefits of migrating to Azure App Service Azure App Service is a rich, fully managed enterprise grade service built for hosting web applications, REST APIs and mobile back ends. Azure App Service builds on the capabilities within Windows Azure Pack Web Sites. Developers can develop in your favorite language, for example .NET, .NET Core, Java, Node.js, PHP or Python; deploy code or containers; can run and scale with ease of both Windows AND Linux based environments. App Service is a managed platform powered by Microsoft Azure, offering security, load balancing, automated management, rich DevOps capabilities - continuous deployment from Azure Dev Ops. GitHubs, Container registries such as Docker Hub, staging environments, custom domains and TLS/SSL Certificates. App Service also provides many networking options for enabling hybrid workloads and isolation for both the multi-tenant service and also the single tenant App Service Environment product offering. In addition to App Service once workloads have been migrated to Azure, customers can also take advantage of a whole plethora of services such as Azure Functions, Azure Logic Apps and Azure Monitor to name just a few, all of which are not available on Windows Azure Pack. Migrating from Windows Azure Pack Web Sites Azure App Service is a natural option for customers operating Windows Azure Pack Web Sites and for tenants who have deployed workloads to Windows Azure Pack Web Sites. There are no automated procedures for migrating workloads from WAP Web Sites to Azure App Service. Customers should assess their workloads for migration to Azure App Service and plan to create new Apps in Microsoft Azure, configure and deploy their application content to the new Web App in Azure App Service. Applications can be created using the Azure Portal, CLI or ARM Template. Application content can be deployed using FTP, Zip or Continuous Deployment from Source Control, Container Registries or using GitHub Actions. Key Considerations when migrating from Windows Azure Pack Web Sites to Azure App Service Supported Authentication Methods Windows Azure Pack Web Sites allows customers to use Windows Authentication to restrict access to applications and to secure access from their applications to other resources such as SQL Server, customers were able to define custom application pool identities and choose to use this authentication method within their applications. This was possible as Windows Azure Pack Web Sites is deployed inside a customer’s own organization, network and all underlying infrastructure could be domain joined. Azure App Service does ot support Windows Authentication, therefore Customers need to look to alternative authentication methods to authenticate access to other resources, for example SQL Authentication when connecting to SQL Server Databases on-premises or Managed Identity when connecting to Azure SQL DB instances. For application developers looking to authenticate users, they can make use of App Service authentication capabilities targeting multiple identity providers such as: Azure Active Directory Microsoft Account Facebook Google Twitter OpenID Connect (preview) Apple (preview) Hosting Options Windows Azure Pack Web Sites offers two different hosting options - shared and dedicated; Azure App Service expands on this and offers few categories of pricing tiers each with different capabilities and limits: Shared compute - Free and Shared; Dedicated compute - Basic, Standard, Premium, PremiumV2 and PremiumV3; Isolated compute App Service Plans All applications in Azure App Service always run in an App Service Plan. The App Service Plan defines the Azure Region in which the app is deployed, number of worker instances the plan is scaled out to, the size of the instances and the pricing tier. The wider range of options provided in Azure App Service enable customers to run a wider range of workloads, achieve differing levels of density and isolation dependent on their specific needs. ","categories": [],
+ "tags": ["Windows Azure Pack"],
+ "url": "https://azure.github.io/AppService/2021/01/06/Migrate-from-Windows-Azure-Pack-Websites-to-Azure-App-Service.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Java, Tomcat, and JBoss EAP version updates",
+ "excerpt":"The latest App Service releases included new Java, Tomcat and JBoss EAP versions. Windows New Tomcat versions 9.0.38 8.5.58 New Java versions 11.0.8 8.0.265 7.0.272 Eclipse Foundation has deprecated Jetty 9.1 and 9.3 (source), so these runtimes are no longer shown on the Portal. You can still create sites with these versions. Tomcat 8.0 has reached End-Of-Life and will also be hidden in an upcoming Portal update. Web apps using these outdated runtimes will continue to run, but using the latest versions ensures that your apps are running on the most secure and performant runtimes. Linux JBoss EAP is now available with Java 11 JBoss EAP now has an “auto-update” option. This option currently uses JBoss 7.2 but will automatically use the latest JBoss versions as they are added. New Java versions 8u252 11.0.7 New Tomcat versions 9.0.37 8.5.57 How to upgrade your Java or Tomcat version To upgrade your Java or Tomcat version, open the Azure Portal to your web app and open the Configuration blade. Under the General settings tab you can select a new Java and Tomcat version using the dropdowns for Java minor version and Java web server version. ","categories": [],
+ "tags": ["Java"],
+ "url": "https://azure.github.io/AppService/2021/01/06/java-stacks-update.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "New App Service + Database create blade (preview)",
+ "excerpt":"We are happy to share a new resource create blade for App Service and Azure databases. This new experience, currently in preview, deploys a PostgreSQL or Azure SQL database and automatically connects it to your web app. This new create flow was built with simplicity in mind. You only need to provide a name and runtime stack for the web app, and choose between Azure SQL or PostgreSQL. Once the resources are created the database connection strings are automatically added as app settings on the web app. The username and password are automatically generated, or you can choose to overwrite these with your own strings. You can get to the new blade using this link, or by searching “web app database” in the Azure Portal. By default, the blade will create a new PremiumV2 App Service plan and either a serverless Azure SQL server or General Purpose PostgreSQL flexible server depending on you choice of database. Once created, you can scale these services up or down to fit your needs. Azure Database for PostgreSQL is currently in preview. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2021/01/26/webapp-db-create.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Webinar: Build Smarter and Faster .NET Web Apps",
+ "excerpt":"Join our upcoming webinar on Tuesday, February 23 from 1:00 to 2:00pm Pacific Time! Learn how Azure can help you to innovate with your .NET web apps and SQL databases with native capabilities such as AI and analytics. In addition, you’ll learn how to build smarter and faster applications using functions, APIM, and auto deployment. Lastly, we’ll show you how GitHub actions can be used to help automate your workflows. We will also cover: Leveraging deployment slots and enabling autoscaling Using Azure Monitor Logs and App Insights to gain insights into log and performance data Azure SQL Hyperscale & Serverless CI/CD with GitHub Actions for Azure SQL JSON Support for simplified backend solutions Register for the webinar! ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2021/02/05/dotnet-webinar.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": ".NET 5 NuGet package restore Incident: App Service Response",
+ "excerpt":"Last week an incident occurred that caused .NET 5 NuGet package operations to fail on some Debian-family distributions. Specifically, Debian and Ubuntu maintainers published an update (for at least some distro versions) that distrusted the Symantec certificate entirely. This change was later rolled back, but patched packages were not available on the package repositories prior to the Microsoft NuGet author signing certificate expiring. Please see this NuGet announcement for more information. Impact to App Service users This incident affected any users running a .NET 5 application on App Service and using App Service’s built-in build service, known as Oryx. If you are building your .NET 5 applications locally or on a CI system, this incident will not affect your .NET 5 applications. For more information, please see this GitHub thread. Resolution for App Service We have updated the root certificates used in the .NET 5 runtime and build image (also known as the Oryx image) and will begin rolling out the updated image as soon as possible. We will update this article as new information becomes available. Workaround To work around this limitation, please build your .NET 5 applications locally or on a build system (such as GitHub Actions or AzureDevops) and deploy the built application to App Service. You can set up a GitHub Actions workflow from the Deployment Center in the App Service blade in the Portal. If you would rather build locally, you can use the az webapp deployment source config-zip command to deploy your app from a .zip file. Once the root certifactes have been updated on your site, you can return to using the Oryx build service. We will update this article as new information becomes available. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2021/02/05/dotnet5-cert-incident.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Proactive Crash Monitoring in Azure App Service",
+ "excerpt":"A crash of a process happens when the process terminates due to an unhandled exception within the application code. A crash leads to a restart and all the in-flight requests (requests currently being handled by the process) are aborted abruptly and may fail with an HTTP 502 error. The process restart causes the application startup code to kick in and the result might be observed as slowness in the application for end-users. Hence, crashes should be avoided as much as possible! Proactive Crash Monitoring is a feature of Azure App Service that checks for process crashes and collects diagnostic data that helps you determine the root cause of the crash. Currently offered in App Service Diagnostics for Windows web apps. How does Proactive Crash Monitoring work? Whenever the worker process (w3wp.exe) corresponding to your app crashes due to an unhandled exception for more than 3 times in 24 hours on the same instance, the feature is enabled automatically and a debugger process is attached to your site’s main worker process. This debugger process then waits for your process to crash again and, assuming it does crash again, a memory dump is collected. This memory dump is then analyzed and the call stack of the thread that caused the crash is logged in your App Service’s logs. Viewing Crashing thread information Folow these steps to view the crashing thread’s call-stack. Open the Diagnose and Solve blade for the app (in the left-side navigation menu) Choose Availability and Performance category Choose Application Crashes tool If this feature has collected a crashing thread stack trace, you will find an insight like in the image below FAQ How frequently are the crash dumps recorded? Once a memory dump is captured on an instance, further memory dumps on the same instance may not be captured for the next 8 hours even if the process keeps crashing. What happens to the memory dump that is collected? Since the memory dump contains PII data, the memory dump is deleted once the call stack and exception information is recorded. There is no way to retrieve this dump later as this dump is not stored or persisted anywhere. If you need to capture a memory dump for further investigation and a call stack alone is not sufficient, then leverage the Crash Monitoring feature of Azure App Service that allows you to collect memory dumps on process crashes. Is the original exception message logged somewhere? The exception message may contain PII data due to which the exception message is not logged in Azure App Services Platform telemetry. There is a log file created in d:\\home\\logfiles\\crashdumps folder for each crash and this log file contains the exception type and full exception message. Information about the last 10 crashes only is saved and older files are deleted. You can view this log file by going to the KUDU console (available at yoursitename.scm.azurewebsites.net) for your app. Which processes are monitored by this feature? This feature only monitors the w3wp.exe corresponding to the main app. Any processes that are spun up for out-of-process hosting scenarios (like PHP, CGI, Java, or .Net Core OutProc) are not monitored by this feature. Also, any processes that belong to the SCM site (for e.g. Webjobs) are not monitored by this feature. Are there additional processes started as a result of this feature? When this feature is trying to capture a crash dump of your process, you may see CrashMon.exe, procdump.exe, or dbghost.exe running in the Kudu Console for your app. Are we notified for unhandled exceptions recorded by this feature? We notify by sending emails to the “ServiceAdmin”, “AccountAdmin” and “Owner” roles for the subscription when a crash is recorded by this feature. What is the performance overhead introduced by the feature? There might be slight performance impact to your app because a debugger process is attached till the worker process crashes once. The overhead introduced should be negligible but only for apps that have very high exceptions per second rate, some delay may be observed. Can this feature be disabled? You can opt-out of this feature by adding the APP SETTING WEBSITE_PROACTIVE_CRASHMONITORING_ENABLED and setting it to FALSE. Happy Debugging! ","categories": ["Diagnostics"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2021/03/01/Proactive-Crash-Monitoring-in-Azure-App-Service.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Deploying to Network-secured sites, Part 2",
+ "excerpt":"An earlier article explained how to use self-hosted Azure DevOps agents to build and deploy your applications to a web app that has Private Endpoints enabled, or an ILB ASE. If you didn’t read that article, the TL;DR is that Private Endpoints blocks inbound access to your web app from the public internet. Private Endpoints is great for securing internal-facing applications without deploying an App Service Environment, but it means that you cannot directly publish your code to the web app from your local machine or Continuous Integration pipeline because that traffic is blocked. The earlier article shows how to deploy Azure DevOps build agents onto Virtual Machine Scale Sets in your Azure VNet. Those agents can publish to the web app since the deployment is sent from within the virtual network, not over the public internet. Solution Overview This article shows how to deploy to a Private Endpoint-enabled site from a Continuous Integration pipeline (such as GitHub Actions, Circle CI, Jenkins, or Travis CI) without having to self-host the CI service on a VM. Since Private Endpoints disables all inbound traffic from the internet, our CI pipeline will publish the files to a storage account and give the web app a SAS URL to files. Once the web app is given this SAS URL, it will pull the files from the storage account. We will use GitHub Actions as the CI system to demonstrate this solution, but the same pattern can be applied to other CI providers as well. If you are not familiar with GitHub Actions, please refer to the docs. If you are using a different CI system, simply copy the Azure CLI commands at the bottom, and use them in your CI provider. GitHub Actions workflow The workflow has two jobs. The first builds and tests the application and uploads the artifact for the second job. Once the artifact is built, tested and uploaded, the second job pulls the artifact and runs an Azure CLI script to publish the files to an Azure Storage Account. Once the files are uploaded, we generate a SAS URL for the storage container with an expiration of 30-minutes. (This means the URL will be invalid 10 minutes after creation.) The web app then pulls the application from the storage account and deploys it. Behind the scenes, the Azure CLI commands are using ZIP deploy to publish the application. Once your code is deployed to the web app, a final CLI command deletes the storage container that contained the ZIP file. Note: A bug has been identified in the CLI command used in the GitHub Actions workflow below and a fix is underway. In the meantime, you can accomplish the same result by using az rest to send the deployment request directly to the ARM API. Example: az storage blob upload --account-name $STORAGE_ACCOUNT -c $CONTAINER -f app.zip APP_URL=$(az storage blob generate-sas --full-uri --permissions r --expiry $EXPIRY --account-name $STORAGE_ACCOUNT -c $CONTAINER -n app.zip | xargs) az rest --method PUT \\ --uri https://management.azure.com/subscriptions/${SUBSCRIPTION}/resourceGroups/${RESOURCE_GROUP}/providers/Microsoft.Web/sites/${WEBAPP}/extensions/onedeploy?api-version=2020-12-01 \\ --body '{ \"properties\": { \"properties\": { \"packageUri\": \"'\"${APP_URL}\"'\" }, \"type\": \"zip\", } }' name: Deploy web app via Storage Account on: push: branches: [ main, master ] workflow_dispatch: env: WEBAPP: your-webapp-name GROUP: your-resource-group-name ACCOUNT: name-for-storage-acct # Does not have to exist, this will be created for you CONTAINER: name-for-storage-container EXPIRY_TIME: 10 minutes jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 - name: Set up JDK 1.8 uses: actions/setup-java@v1 with: java-version: 1.8 - name: Build with Maven run: mvn package - name: Upload artifact for deployment jobs uses: actions/upload-artifact@v2 with: name: app path: target/app.jar publish: runs-on: ubuntu-latest needs: build steps: - name: Azure Login uses: azure/login@v1 with: creds: ${{ secrets.AZURE_CREDENTIALS }} - name: Download artifact uses: actions/download-artifact@v2 with: name: app - name: Zip the app contents uses: papeloto/action-zip@v1 with: files: app.jar dest: app.zip - name: Set SAS token expiration run: echo \"expiry=`date -u -d \"$EXPIRY_TIME\" '+%Y-%m-%dT%H:%MZ'`\" >> $GITHUB_ENV - name: Azure CLI script uses: azure/CLI@v1 with: azcliversion: 2.19.1 inlineScript: | az extension add --name webapp az storage account create -n $ACCOUNT -g $GROUP -l westus az storage container create -n $CONTAINER --account-name $ACCOUNT az storage blob upload -f app.zip --account-name $ACCOUNT -c $CONTAINER -n $ACCOUNT ZIP_URL=$(az storage blob generate-sas --full-uri --permissions r --expiry ${{ env.expiry }} --account-name $ACCOUNT -c $CONTAINER -n $ACCOUNT | xargs) az webapp deploy --name $WEBAPP --resource-group $GROUP --type zip --src-url $ZIP_URL --async false az storage container delete -n $CONTAINER --account-name $ACCOUNT To use this workflow in your GitHub project, simply create an Azure Service Principal and save it as a secret named AZURE_CREDENTIALS in your repository. Finally, update the WEBAPP, CONTAINER, GROUP, and ACCOUNT environment variables with your desired resource names. By default, this workflow will run whenever a commit is pushed to the main or master branch. You can change this by updating the workflow triggers at the top of the yaml file. You can change the SAS token expiration time by changing the value of the EXPIRY_TIME variable at the top of the workflow. The az webapp deploy command is in the webapps extension as of March 2021, it will be included in the core CLI in future release. Notes for other CI services Not using GitHub Actions? No problem! You can log into the Azure CLI using a Service Principal, just like on GitHub Actions, and use the Azure CLI commands at the bottom of the yaml file. We have compiled some helpful resources for common CI providers below. Azure DevOps Circle CI Jenkins ","categories": [],
+ "tags": ["Deployment","Networking"],
+ "url": "https://azure.github.io/AppService/2021/03/01/deploying-to-network-secured-sites-2.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Using Azure Functions with Azure Virtual Network NAT to Avoid SNAT Port Exhaustion",
+ "excerpt":"Source Network Address Translation (SNAT) ports are used by App Service to translate outbound connections to public IP addresses. However, there are limitations to the number of SNAT port connections you can use at once and if your application runs out of SNAT ports it will cause intermittent connectivity issues. To avoid SNAT port exhaustion issues you will need to make sure that no new connections are created repetitively on the same host and port. Follow this sample for further detail on how this can be accomplished using Azure Functions, Regional VNET Integration, Private Endpoints and NAT Gateway. To learn more about Troubleshooting outbound connection errors, see the documentation. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2021/03/02/Using-Azure-Functions-with-Azure-Virtual-Network-NAT-to-Avoid-SNAT-Port-Exhaustion.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "App Service Managed Certificate (Preview) Now Supports Apex Domains",
+ "excerpt":"App Service Managed Certificate (preview) now lets you secure your apex domains on your web apps at no additional charge. This feature is similar to the current App Service Managed Certificate sub-domain support where you can create a standard certificate valid for six months which will automatically renew around 45 days before expiration. Your TLS/SSL bindings will also be automatically updated. If you have several domains, you will need to separately create an App Service Managed Certificate for each of them; wildcard certificate is not supported for this feature. Getting started Pre-requisites App Service Managed Certificates for apex domains are validated with HTTP token validation which App Service will set up on your behalf. However, to ensure a successful create and renewal validation, you want to make sure that you have the following set up, otherwise your certificate validation will fail. Add an apex domain to your web app by mapping an A record and TXT record to your web app. Your web app must be accessible from the public network and does not have any IP restrictions set up. You cannot validate your certificate if your web app is not accessible from the public network. Adding IP restrictions after creating a certificate will cause renewal to fail. Creating an App Service Managed Certificate Before creating a managed certificate, make sure you have met the pre-requisites. In the Azure Portal, head to your web app and from the left navigation menu of your app, select TLS/SSL settings > Private Key Certificates (.pfx) > Create App Service Managed Certificate. A blade will show up on the right side of the page. In that blade, select an apex domain from the drop down menu and click “Create”. It may take up to a few minutes to create a managed certificate for your apex domain. Once you get a notification that the managed certificate was created successfully, you will see the certificate on the list of “Private Key Certificates”. If you close the blade before getting a successful notification or if you do not see the newly created managed certificate, refresh the page and you should see the new certificate on the list. FAQ Q: I’m getting “Web app is not accessible by public network” error. What does this mean? A: In order to pass the HTTP token validation, your web app needs to be accessible from public network. If your web app has network restrictions, the HTTP token validation will fail. Q: I am getting the following error on portal when validating my domain with a country code top-level domain (ccTLD): Properties.CanonicalName is invalid. Canonical name XXXXX is not a subdomain. This validation method only supports subdomains. How can I fix this? A: If you are encountering this error with your apex domain, try creating a certificate with the script below. Q: Does this have CLI or Powershell support? How can I automate the create process? A: Currently, there is no first class CLI and Powershell support to create a managed certificate for apex domains. However, if you need to automate the process, you can try using ARM template. Refer to the automate with scripts section of the article. Q: Is this supported when using alias record for my apex domain referencing Traffic Manager? A: This scenario is not supported. Since managed certificates for apex domain uses HTTP token validation, the validation can fail if the web app itself isn’t reached during certificate create/renew validation. Do not create a managed certificate for this scenario. Q: Is it expected that the managed certificate for apex domain to take a bit longer to create than for sub-domain? A: Yes, your App Service Managed Certificate for apex domain will take a bit longer to create than for sub-domain because it uses a different validation method. Automate with scripts You can create an App Service Managed Certificate for your apex domain using ARM Template. Below is a sample of using a Powershell script to run your ARM template. This script will only create an App Service Managed Certificate for a custom domain that has already been added to your web app. If you run this script before adding a custom domain to the web app, the script will fail. Powershell script to run ARM template #Connect-AzureRmAccount $subscription = \"SUBSCRIPTION-ID\" $resourceGroupName = \"RESOURCE-GROUP-NAME\" $appServicePlanName = \"APP-SERVICE-PLAN-NAME\" $subjectName = \"DOMAIN-NAME\" Set-AzureRmContext -SubscriptionId $subscription $appServicePlan = Get-AzureRmResource ` | Where-Object {$_.ResourceGroupName -eq $resourceGroupName } ` | Where-Object {$_.Name -eq $appServicePlanName} New-AzureRMResourceGroupDeployment ` -ResourceGroupName $resourceGroupName ` -SubjectName $subjectName ` -AppServicePlanName $appServicePlanName ` -Location $appServicePlan.Location ` -TemplateFile \"CreateHttpFreeCert.json\" ARM template { \"$schema\": \"https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#\", \"contentVersion\": \"1.0.0.0\", \"parameters\": { \"SubjectName\": { \"type\": \"string\", \"metadata\": { \"description\": \"Subject name of the certificate.\" } }, \"AppServicePlanName\": { \"type\": \"string\", \"metadata\": { \"description\": \"App Service Plan Name where certificate will be imported to.\" } }, \"Location\": { \"type\": \"string\", \"metadata\": { \"description\": \"Location of app service plan.\" } } }, \"resources\": [ { \"apiVersion\": \"2019-08-01\", \"location\": \"[parameters('Location')]\", \"name\": \"[concat(parameters('SubjectName'), '-', parameters('AppServicePlanName'), '-', parameters('Location'))]\", \"type\": \"Microsoft.Web/certificates\", \"properties\": { \"serverFarmId\": \"[resourceId('Microsoft.Web/serverfarms/', parameters('AppServicePlanName'))]\", \"canonicalName\": \"[parameters('SubjectName')]\", \"domainValidationMethod\":\"http-token\" } } ] } ","categories": ["certsdomains"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2021/03/02/asmc-apex-domain.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Custom domain for SCM site",
+ "excerpt":"When enabling private endpoint for a web app, both the web app and the Source Control Manager (SCM) site, also sometimes referred to as kudu, are locked down to only receive traffic from the private IP. If you are in the internal network and have setup proper private DNS resolution, you can access both sites by browsing to https://appname[.scm].azurewebsites.net. Externally public DNS for appname[.scm].azurewebsites.net will still resolve and route you to the public endpoint in which case you will be met with the blue Forbidden page. To route external traffic to the site or if you prefer to use a custom domain internally, you can setup a reverse proxy like Azure Application Gateway. In a reverse proxy you can override the custom domain with an internal hostname like appname[.scm].azurewebsites.net. All of this has been possible for a while and you can use the SCM APIs by providing the deployment credentials in the request, but what has not been possible is to access the SCM site in the browser and using all the tools available here. Previously when setting this up and browsing to https://[scm.mydomain.com]/basicauth the browser would challenge you for your deployment credentials, but after validating your credentials, it would redirect you to appname.scm.azurewebsites.net, which would be blocked. What you can now do, is to use https://[scm.mydomain.com]/basicauthviaproxy. When accessing this link, the backend will look for the originating address in X-Forwarded-Host or X-Original-Host and redirect you to the appropriate address upon successful login. A few notes: It only works with deployment credentials. SSO is not possible SCM site does not have an unauthenticated health endpoint, so health probes should either be disabled or accept 401 and 403 Some response payloads from the SCM APIs contain absolute references defaulting to the incoming host (appname.scm.azurewebsites.net). To override this and honor the originating address, configure the following App Setting on the web app: SCM_USE_ORIGINALHOST_FOR_REFERENCE = 1 ","categories": ["networking"],
+ "tags": ["scm"],
+ "url": "https://azure.github.io/AppService/2021/03/03/Custom-domain-for-scm-site.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "How-to Host a Python application with Windows containers on App Service",
+ "excerpt":"Windows containers on App Service can help you easily modernize your application by making it easier to Lift-and-Shift to App Service and install custom dependencies that would otherwise not be available on App Service. If your application is built with a language other than .NET, you can still create a custom container and take advantage of Windows cotnainers! In this tutorial we will be using a Visual Studio templated Python 3.6 Flask application, containerizing it with Docker and publishing the image to Azure Container Registry so it can be deployed on App Service. Create and configure your Python app Open Visual Studio and click on Create a new project. Find the Flask Web Project template, name it and click Create. Once you have created your application find the runserver.py file and replace the existing code with the following: from os import environ from FlaskWebProject1 import app if __name__ == '__main__': # Run the app server with default Flask port app.run(port=5555, host='0.0.0.0') This code runs the local development server which defines the default Flask port that it will be using along with the host to use IP addresses on the local machine. This will be utilized later for developing in your local browser. In the next step we will be creating a Dockerfile for the application so we can containerize it. Adding the Dockerfile To containerize your application you will need to add a Dockerfile, which includes instructions on how to build the container. If you are using Visual Studio you may have to add the Dockerfile manually. To add the Dockerfile manually, Right-Click the project and add a New Item. Then, choose Text file and name it Dockerfile.txt and click Add to add the file. However, Dockerfiles have no extensions so you’ll need to remove the “.txt” from the name and save it to create the Dockerfile. Once you have your Dockerfile created copy and paste the following: # first layer is our python base image enabling us to run pip FROM python:3.7-windowsservercore-1809 # create directory in the container for adding your files WORKDIR /user/src/app # copy over the requirements file and run pip install to install the packages into your container at the directory defined above COPY requirements.txt ./ RUN pip install --no-cache-dir -r requirements.txt --user COPY . . # enter entry point parameters executing the container ENTRYPOINT [\"python\", \"./runserver.py\"] # exposing the port to match the port in the runserver.py file EXPOSE 5555 This Dockerfile includes instructions that will build your container on a Windows Server base image, add your application files over to the container and build your packages using your requirements.txt file as you normally would with a Python app. The port exposed must match the port that is previously defined in the runserver.py file. Create the Docker Image When using Docker, you need to build and create the image first before you can run the container. Open your local Command Prompt, go to the directory where your Dockerfile lives and run this command: docker build -t mypythonapp . Running this command will take each step defined in the Dockerfile from above and build your image. Once your image is successfully built and tagged, you can then run it locally to test the application. Run your application locally Before you push your image to a registry, you’ll want to make sure your local version runs as expected. Once your Docker image is built run the following command to start your container: docker run -d --isolation hyperv mypythonapp:latest Running this command will start your application and give you a Container ID in the form of a long string. Confirm that your container is running by using the docker ps command next. This will output all containers currently running. Locate and copy the string under Container ID to be used later. This is a shorthand version of the long string from before. After you have confirmed that your container is running locally with docker ps you can use docker inspect to find the IP Address that you will need to use to view your application. Use the following command to output json that will include your IP Address that you will need: docker inspect <Container-ID> Find your IP Address at the bottom of the output and paste it in the browser with your exposed port number after the IP Address. It should look similar to http://172.00.000.000:5555. Hit enter and your application should show up in the browser. If everything looks good and your application is ready to publish, the next step is to push your image to a container registry where it will live prior to being deployed to App Service. Push your container image to a registry Now that we’ve tested the application locally in a container we can push it to a container registry where the image will live. This will prepare us and satisfy the requirements for creating and publishing the application to App Service. First you must have a registry created before you can push the image to it. Once that is complete, you can continue with these instructions. For this example, we will be using Azure Container Registry, but you can use Docker Hub as well by swapping out the registry-name.azurecr.io with your-docker-hub-registry-name. Before you attempt to tag and push the image, make sure you are logged in by using docker login in the command prompt docker login <registry-name>.azurecr.io This will prompt you to enter your username and password from your registry. You can find these under Access keys in your Container registry resource in the Azure portal. After you’ve logged in, run the following commands to tag and push your Docker image: docker tag mypythonapp:latest <registry-name>.azurecr.io/mypythonapp:latest docker push <registry-name>.azurecr.io/mypythonapp:latest Once the image is pushed you can verify that it is in your Azure Container Registry by viewing the Repositories in your Container registry resource. Next, we will use the image from our registry to create our Web App on App Service. Create the Web App using Premium v3 When you are creating the Web App that you will publish your container to be sure to choose the correct options shown below. Name your site, choose Docker Container under Publishing type and Windows for the Operating System. Choose an available Region and then choose your SKU and size. Premium V3 is the only SKU that supports Windows containers. Learn more about the Premium V3 SKU here. Next, click the Next:Docker > button to pull your container image from Azure Container Registry. Choose Azure Container Registry as your Image Source and the registry options will show up for you to select. The registry you selected earlier should show up in the Registry drop-down along with the created Images and Tags. Once you have the correct options selected you can hit Review + create to start your deployment and verify your deployed app on App Service. ","categories": [],
+ "tags": ["windows containers"],
+ "url": "https://azure.github.io/AppService/2021/03/04/How-to-Host-a-Python-application-with-Windows-Containers-on-App-Service.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Increased Savings with App Service Offerings",
+ "excerpt":"In this article, we will review different App Service offerings with side-by-side comparisons to show how you can save more with App Service. The offerings we will be covering in this article are: Free App Service Plan on Linux and Windows Basic App Service Plan on Linux Premium V3 App Service Plan on Linux and Windows Reserved Instances Dev/Test Pricing At the end of the article, we will also go through how you can estimate your cost savings using the Azure Pricing Calculator. Free App Service Plan on Linux and Windows App Service provides Free App Service Plans on both Linux and Windows. This is a great option if you are starting out in your journey to host web apps in the cloud. This tier comes with its own limits on what features it supports, so if your traffic increases significantly, you will likely need to scale up to Basic or Standard (covered later in this article). Basic App Service Plan on Linux Linux developers who are starting out on App Service and are hosting a smaller web app with lower traffic requirements that don’t need auto scale, virtual network integration and deployment slots features should take note of the discounted prices for Linux Basic App Service Plan. The chart below will show you a comparison between a Linux B1 and S1 instance so you can see the significant price difference between the two. OS Instance Cores RAM Storage Cost Linux B1 1 core 1.75 GB 10 GB ~$13.14/month S1 1 core 1.75 GB 50 GB ~$69.35/month * Prices are based on App Service pricing with the following configurations as of 03/10/2021: Linux OS, Central US region, USD currency, and displayed by month Before moving from Standard to Basic, please refer to App Service limits page and App Service pricing page for more information on the feature support for the different plans. If your workload does not need the Standard feature set, moving to Basic will help optimize your costs. Premium V3 App Service Plan Customers who are currently running bigger production workloads on App Service should be aware of the new App Service Premium V3 (Pv3) offering announced in November 2020, which is our most performant and cost effective offering yet. The PV3 tier offers enhanced performance for a competitive price. To give an example, let’s compare the P1v2 to P1v3 for both Linux and Windows: OS Instance Cores RAM Storage Cost Linux P1v2 1 core 3.50 GB 250 GB ~$81.03/month P1v3 2 cores 8 GB 250 GB ~$124.10/month Windows P1v2 1 core 3.50 GB 250 GB ~$146.00/month P1v3 2 cores 8 GB 250 GB ~$240.90/month * Prices are based on App Service pricing for Linux and Windows with the following configurations as of 03/10/2021: Linux OS and Windows OS, Central US region, USD currency, and displayed by month P1v3 provides double the cores and more than double the RAM compared to P1v2. If you look at the table above, for Linux P1v3, you get double the cores and more than double the RAM for an additional ~53% of the cost, while for Windows P1v3, you get double the cores and more than double the RAM for an additional ~65% of the cost. Also note that the comparative price/performance difference is even larger when reserved instances or dev/test pricing are used (both are covered later in this article). For example, with a one year reserved instances price, Linux customers can run a P1v3 instance at roughly the same price as a P1v2 instance. And with a three year reserved instances price, Linux customers can run a P1v3 instance at a lower price than a P1v2! Scaling Up to PV3 Note that some customers who are on pre-existing App Service footprints may not be able to scale up to PV3. This will be the case if you notice the option greyed out on the portal when they try to scale up. You will be guaranteed to get support for PV3 if you create a new app in a new resource group in the region of your choice, and you pick a PV3 SKU when creating the new app service plan. You can subsequently scale down your app to a different SKU with the confidence that you can scale back up to Pv3 in the future. You can read more about the option to scale up from an unsupported resource group and region combination for PV3. Long Term Cost Savings for PV3 If you are planning to run your PV3 instances in the long term, you should consider purchasing reserved instances as it can greatly increase your savings. The following section will go through it in more detail. Reserved Instances Customers who are running high scale productions on App Service and are looking for long term cost saving options can consider purchasing reserved instances for App Service. Purchasing reserved instances lets customers save 35% to 55% on costs compared to pay-as-you-go if they buy reserved instances for a one-to-three-year commitment. The reserved instances options for App Service are available for Premium V3 Tiers and Isolated stamp fees for ASE V2. You can learn more about this on: What are Azure Reservations? Save costs with Azure App Service reserved instances How reservation discounts apply to Azure App Service Premium v3 instances and Isolated Stamps How to buy reserved instances section in this article If you would like to get a quick estimated percentage of your savings for using reserved instances, refer to the Pricing Calculator section in this article Cost Comparisons We will go through a few examples from our pricing page to show you the savings you can get with reserved instances. If you would like more information, our pricing page shows a breakdown of the prices for the different options on both Linux and Windows. The chart below shows the comparison between the prices for P1v3 instance for pay-as-you-go, one-year reserved instance, and three-year reserved instance on both Linux and Windows. OS Instance Pay as You Go 1 Year Reserved 3 Year Reserved Linux P1v3 ~$124.100/month ~$81.001/month (~35% savings) ~$56.247/month (~55% savings) Windows P1v3 ~$240.90/month ~$180.332/month (~25% savings) ~$145.249/month (~40% savings) * Prices are based on App Service pricing Linux and Windows with the following configurations as of 03/10/2021: Linux OS and Windows OS, Central US region, USD currency, and displayed by month As you can see from the chart above, you can get significant savings from purchasing reserved instances. On Linux, a three-year commitment will save you ~55% compared to if you opt for pay as you go. While on Windows, a three-year commitment will save you ~40% compared if you opt for pay as you go. The longer the term commitment, the more savings you will get with reserved instances. Across both Linux and Windows, reserved instances pricing for Pv3 enables you to run at a lower price than equivalent Pv2 instances! How to Buy Reserved Instances Purchasing reserved instances is very convenient. You can purchase it through the Azure portal. To get started, head to the Azure portal, search for “Reservations” on the search bar, and then select the “Reservations” services. You will be redirected to a page similar to a resource view page, but it will say “Reservations” on the top left corner. Click on the “+ Add” button to purchase reserved instances. You will see a page that lists a range of products that you can purchase reservations for. Search for and select “App Service” from the list. A blade will appear on the right side showing options for App Service reserved instances for PV3 and for Isolated App Service Plan. If you don’t see the region, term, or billing frequency that you are interested in, try adjusting the filters by clicking on the blue bubble. For the term, you can choose between a one-year and three-year option. Once you select an instance, you can view the price and the savings at the bottom right corner. In the image below, I selected the P1v3 option for Linux in Central US region for a three-year term billed monthly. * The reserved instance price is based on the following configurations as of 03/10/2021: Linux P1v3, Central US region, and a three-year term that is billed monthly. And another example below, I selected the P1v3 option for Windows in Central US region for a three-year term billed monthly. * The reserved instance price is based on the following configurations as of 03/10/2021: Windows P1v3, Central US region, and a three-year term that is billed monthly. Once you’ve decided on your choice, click on “Add to cart”. You may choose several plans in the same page, and when you’re done, click on “Close”. You will see a new page on the “Products” tab that will show you a list of products that you have chosen. In this page, you can set the name of your reservations and the quantities (which corresponds to the number of Pv3 instances being purchased with a reservation) that you would like to purchase for your products. If you are unsure of how many instances to reserve, refer to the how many Reserved Instances should I buy section of the article. You can also delete products and edit your purchases. You can also see the breakdown of the total costs and of your immediate charges at the bottom right corner of the page. * The reserved instance price is based on the following configurations as of 03/10/2021: Linux P1v3, Central US region, and a three-year term that is billed monthly. When you are satisfied with your selections, make sure to head to “Review + buy” to finalize your purchase of the reserved instances. How Many Reserved Instances Should I Buy? If you are unsure of the quantity to buy, we recommend purchasing enough quantity to cover your steady state baseload. In other words, use the number of App Service Plan instances running for your baseload as a starting point for the quantity specified in the reserved instances purchase. For many customers, the baseload would be one or two instances. You can still use an auto-scale rule to increase the number of running App Service Plan instances above the baseload. Reserved instances pricing will cover the baseload and any additional compute from auto-scaling will be charged at the regular price. Dev/Test Pricing Dev/Test Pricing is a great option for customers who are looking to have discounted rates for the development and testing environments for their web apps. This option is available for Basic, Standard, Premium v2, and Premium v3 App Service Plans. For more information, you can look at the Azure Dev/Test Pricing page and scroll towards the bottom of the page where “App Service” is listed. If you are interested in getting an estimated price for your dev/test pricing, refer to next section under pricing calculator. Pricing Calculator The pricing calculator can be a handy tool to calculate the estimated monthly costs of running your services. In this section we will show you how to use the pricing calculator to calculate the estimated price for your reserved instances and for your dev/test pricing. Getting Started In the pricing calculator page, select “App Service” from the list of products and you will get a notification on the right side of the page. When you’ve successfully added App Service in the calculator, you will see a section in the UX showing App Service information when you scroll down the page. You can configure values such as region, OS, pricing tier, and etc. to get an estimate for the cost. The next few sections in the article will go over how you can use this tool to calculate an estimate for your reserved instances savings and for your dev/test pricing. Calculating Reserved Instances Once you have selected “App Service” from the list of products and properly selected your configurations, look for the “Saving Options” and select from the reserved instances options. On the pricing calculator, it will also show the percentage of your savings for all the reserved instances options. The price will adjust accordingly after you have selected a reserved instances option. The example below will show you how the savings options will look like for a P1v3 with a three-year reserved instance on Linux. * Price is based on pricing calculator with the following configurations as of 03/10/2021: Central US region, Linux OS, and Premium V3 for one P1v3 instance for three-year reserved instances. Price is in USD and is displayed per month. For another example, the image below will show you how the savings options will look like for a P1v3 with a three-year reserved instance on Windows. * Price is based on pricing calculator with the following configurations as of 03/10/2021: Central US region, Windows OS, and Premium V3 for one P1v3 instance for three-year reserved instances. Price is in USD and is displayed per month. As you can see from the examples above, the pricing calculator makes it convenient for you to calculate your estimated savings percentage with the reserved instances. Calculating Dev/Test Pricing Once you have selected “App Service” from the list of products and properly selected your configurations, scroll to the very bottom of the calculator web page and look for the “Show Dev/Test Pricing” slider. When you enable the slider to show dev/test pricing, you will notice that your price estimates will have changed to reflect dev/test pricing if supported for the selected pricing tier. The set of examples below show an estimate using the pricing calculator for a P1v3 instance when you apply Dev/Test Pricing on Linux. The first screenshot shows the regular price for a Linux P1v3 instance. The second screenshot shows the discounted Dev/Test price. You will notice a $30.66 price difference which is ~24% less for dev/test pricing. * Price is based on pricing calculator with the following configurations as of 03/10/2021: Central US region, Linux OS, and Premium V3 for one P1v3 instance for pay as you go without dev/test pricing. Price is in USD and is displayed per month. * Price is based on pricing calculator with the following configurations as of 03/10/2021: Central US region, Linux OS, and Premium V3 for one P1v3 instance for pay as you go with dev/test pricing. Price is in USD and is displayed per month. Another set of examples below show an estimate using the pricing calculator for a P1v3 instance when you apply Dev/Test Pricing on Windows. The first screenshot shows the regular price for a Windows P1v3 instance. The second screenshot shows the discounted Dev/Test price. There is a $147.46 price difference which is ~61% less for dev/test pricing. * Price is based on pricing calculator with the following configurations as of 03/10/2021: Central US region, Windows OS, and Premium V3 for one P1v3 instance for pay as you go without dev/test pricing. Price is in USD and is displayed per month. * Price is based on pricing calculator with the following configurations as of 03/10/2021: Central US region, Windows OS, and Premium V3 for one P1v3 instance for pay as you go with dev/test pricing. Price is in USD and is displayed per month. From the two sets of examples above, you can see the savings you can get for using the dev/test pricing for your development and testing environments. This is a great option for hosting your development and testing environments with the same amount of performance and capacity as your production environments, but at a lower cost. Summary There are several ways for you to increase savings when running App Service . This article has described several App Service Plan offerings that help you save on prices, including reserved instances, and dev/test pricing options. We hope this article has equipped you with more information and presented you with a guide on how you can increase your savings when running App Service. All prices in this article are all estimates during the time noted. Your final price would depend on your configurations for your App Service. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2021/03/11/increased-savings-with-app-service-offerings.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "How to use gRPC-Web with Blazor WebAssembly on App Service",
+ "excerpt":"gRPC is a modern protocol which uses HTTP/2 to streamline messaging between clients and back-end servers and is an efficient way to connect services that require high-performance communication. However, HTTP/2 gRPC is not compatible with modern browsers and requires the use of gRPC-Web to communicate between a browser application and a gRPC server. gRPC-Web enables this scenario by having the browser send normal HTTP requests and acting as a proxy in front of the gRPC server to translate the requests to the browser. With gRPC-Web, you can create a .NET server app hosted on App Service using gRPC-Web middleware which operates as a translator between the browser application and the .NET server app. This translation maps incoming gRPC-Web requests to the appropriate .NET classes in the server app, and translates the server app’s return values into gRPC-Web responses that are sent back to the browser. If you would like to learn more about gRPC-Web, visit the gRPC blog. In the following example, we’ll be using a .NET 5 Blazor WebAssembly application and replacing the existing JSON calls with gRPC-Web by enabling the gRPC-Web middleware in the startup configuration. Create Blazor WebAssembly App In Visual Studio, you will create a Blazor WebAssembly application that we can add gRPC-Web to. Open Visual Studio and Create a new project and search for Blazor app. Highlight Blazor app, click Next, name your application and click Create. Choose .NET 5.0 in the drop-down, highlight the Blazor WebAssembly App option and check the ASP.NET Core hosted option under the Advanced column before clicking the Create button. Once your application is created, you will have a Client, Server, and Shared project under your solution. Install packages Before you add any code to your projects, you need to make sure the correct packages are installed on your Client, Server, and Shared projects. Starting on the Shared project Right-click the project and go to Manage Nuget packages. Browse for and install the following packages in the Shared project: Google.Protobuf Grpc.Net.Client Grpc.Tools Next, follow the same process for the Shared project and go to your Server project to install these packages: Grpc.AspNetCore Grpc.AspNetCore.Web Then, go to your Client project and install the following: Grpc.Net.Client.Web You can verify that each of the packages are installed by viewing the .csproj file of each project. You should see an added package reference for the ones you’ve installed. Add Proto file and Service to the Shared project Grpc works with Proto files which are written in protocol buffer language that define your messaging. To learn more about the language please visit this guide. To add a proto file, Right-click the Shared project and go to Add, then New item. You can choose a Class file and name it weather.proto and hit Add. Visual Studio will pick up that it is a gRPC file as you will see a gRPC icon next to the file. Remove the boiler plate code in the file and replace it with the following: syntax = \"proto3\"; // replace namespace with your own option csharp_namespace = \"BlazorGrpcWebApp.Shared\"; package WeatherForecast; import \"google/protobuf/timestamp.proto\"; service WeatherForecasts { \trpc GetWeather (WeatherForecast) returns (WeatherReply); } message WeatherReply { \trepeated WeatherForecast forecasts = 1; } message WeatherForecast { \tgoogle.protobuf.Timestamp dateTimeStamp = 1; \tint32 temperatureC = 2; \tstring summary = 3; } Next we will add the Weather Service class. This class will contain the same code and logic that is currently in the WeatherForecastController.cs file, which provides us with our weather data. Right-click the project and add a new class item naming it WeatherService.cs. Add the following using statements and code to the class: using Grpc.Core; using Google.Protobuf.WellKnownTypes; public class WeatherService : WeatherForecasts.WeatherForecastsBase { \tprivate static readonly string[] Summaries = new[] \t{ \t\t\"Freezing\", \"Bracing\", \"Chilly\", \"Cool\", \"Mild\", \"Warm\", \"Balmy\", \"Hot\", \"Sweltering\", \"Scorching\" \t}; \tpublic override Task<WeatherReply> GetWeather(WeatherForecast request, ServerCallContext context) \t{ \t\tvar reply = new WeatherReply(); \t\tvar rng = new Random(); \t\treply.Forecasts.Add(Enumerable.Range(1, 10).Select(index => new WeatherForecast \t\t{ \t\t\tDate = DateTime.Now.AddDays(index), \t\t\tTemperatureC = rng.Next(20, 55), \t\t\tSummary = Summaries[rng.Next(Summaries.Length)] \t\t})); \t\treturn Task.FromResult(reply); \t} } Now that you have your WeatherService added, you will notice that some of the objects won’t be recognized from the proto file. To remedy this, we’ll need to include a reference to the proto file in the Shared .cproj file ItemGroup so it can be recongized. Add the following to your ItemGroup in the .csproj file: <ItemGroup> \t<SupportedPlatform Include=\"browser\" /> \t// Add .proto file reference \t<Protobuf Include=\"weather.proto\" /> </ItemGroup> Configure gRPC-Web in the Server To configure the application to take advantage of gRPC-Web you need to register the gRPC service in your Startup.cs file. This enables you to use dependency injection to consume the service across the app. Add the following code to your ConfigureServices method in the Server Startup.cs file: public void ConfigureServices(IServiceCollection services) { \t// add gRPC service \tservices.AddGrpc(); \tservices.AddControllersWithViews(); \tservices.AddRazorPages(); } Next, you’ll add the gRPC-Web middleware to the apps configuration and register the gRPC service. This must be added after UseRouting and before UseEndpoints in the Configure method. app.UseRouting(); // must be added after UseRouting and before UseEndpoints app.UseGrpcWeb(); app.UseEndpoints(endpoints => { \t// map to and register the gRPC service \tendpoints.MapGrpcService<WeatherService>().EnableGrpcWeb(); \tendpoints.MapRazorPages(); \tendpoints.MapControllers(); \tendpoints.MapFallbackToFile(\"index.html\"); }); Configure gRPC-Web with the .NET client In order to configure gRPC-Web to use in our Client project, you’ll need to add a gRPC channel that provides a connection to a gRPC server using the HttpClient object. Add the following code to the Program.cs file in your Client project: using Grpc.Net.Client using Grpc.Net.Client.Web; using Microsoft.AspNetCore.Components; builder.Services.AddSingleton(services => { \tvar httpClient = new HttpClient(new GrpcWebHandler(GrpcWebMode.GrpcWeb, new HttpClientHandler())); \tvar baseUri = services.GetRequiredService<NavigationManager>().BaseUri; \tvar channel = GrpcChannel.ForAddress(baseUri, new GrpcChannelOptions { HttpClient = httpClient }); \treturn new WeatherForecasts.WeatherForecastsClient(channel); }); Now that gRPC-Web is configured in the client project, we need to adjust the code in the FetchData.razor file so we can test the gRPC calls. The injected HttpClient will no longer be needed, but we will replace that with the Weather Forecasts Client so we can retrieve the weather data. Replace the current code in the FetchData.Razor with the code below. @page \"/fetchdata\" // replace using statement with your namespace @using BlazorGrpcWebApp.Shared @inject WeatherForecasts.WeatherForecastsClient WeatherForecastsClient <h1>Weather forecast</h1> <p>This component demonstrates fetching data from the server.</p> @if (forecasts == null) { \t<p><em>Loading...</em></p> } else { \t<table class=\"table\"> \t<thead> \t<tr> \t<th>Date</th> \t<th>Temp. (C)</th> \t<th>Summary</th> \t</tr> \t</thead> \t<tbody> \t@foreach (var forecast in forecasts) \t{ \t\t<tr> \t\t<td>@forecast.Date.ToShortDateString()</td> \t\t<td>@forecast.TemperatureC</td> \t\t<td>@forecast.Summary</td> \t\t</tr> \t} \t</tbody> \t</table> } @code { \tprivate IList<WeatherForecast> forecasts; \tprotected override async Task OnInitializedAsync() \t{ \t\tforecasts = (await WeatherForecastsClient.GetWeatherAsync(new WeatherForecast())).Forecasts; \t} } Once the FetchData.razor file is updated to output the weather data we can verify that we are using gRPC-Web by running our application locally Right-click anywhere on the application and go to Inspect. Find the Network tab and then visit the Fetch data page. The Weather forecast data will load and you will see the name of our method GetWeather show up. Click on the GetWeather name to view the Response Headers which show the content-type being application/grpc-web. Deploying to App Service Since we are using a Blazor WebAssembly application that is hosted on ASP.NET Core the deployment process is slightly different. You can still deploy to App Service as you typically would, but you’ll need to Publish the Server project. The hosted deployment serves the Blazor app to browsers from its hosted ASP.NET Core app that runs on a web server. Your Server app will have reference to the Client app DLLs as the apps are deployed together with the Client app being published in the wwwroot folder. Learn more about hosted deployments in the Blazor documentation. Once your application is published you can verify that gRPC-Web is working using the same process from above by inspecting the Network in the browse. Your Request URL will now point to your App Service URL (myappname.azurewebsites.net) and the content-type: will still be application/grpc-web. Resources Use gRPC in browser apps gRPC-Web for .NET apps gRPC-Web documentation ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2021/03/15/How-to-use-gRPC-Web-with-Blazor-WebAssembly-on-App-Service.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Deploying a secure, resilient site with a custom domain",
+ "excerpt":"In this article I will walk you through setting up a secure, resilient site with Azure App Service using some new features that have recently been released or are very close to release. The image below shows the basic architecture. One or more instances of your Web App in multiple regions with Azure AD authentication. Azure Front Door (AFD) will provide global load balancing and custom domain with certificates, and the Web Apps will be isolated to only receive traffic from the specific AFD instance. This guide is organized into five steps: Create a basic Web App with Azure AD Authentication Add Azure Front Door Add Custom Domain and Certificate Restrict traffic from Front Door to Web App Increase resiliency with multiple geo-distributed Web Apps In closing, there are sections on alternative approaches, advanced scenarios, and an FAQ section. Getting started You can complete most of this guide using the Azure portal, but there are some advanced features that require scripting. I will be using Azure CLI throughout the walk-through, however Azure PowerShell or Azure Resource Manager templates will work as well. I am using bash through Windows Subsystem for Linux (WSL) to run the commands. If you are using a PowerShell or Cmd prompt, small syntax tweaks may be needed. If you are new to scripting, you will find overview and instructions on installing Azure CLI here. You can also use Azure Cloud Shell from the portal. It even has a nice file editor that you can use for some of the steps, so no local install is needed. 1. Basic Web App with Azure AD Authentication First, setup a Resource Group and a Web App with Azure AD Authentication. Choose a unique name for your Web App and feel free to change name of the resource group and location. If you have preferences for App Service Plan or other options, you can configure this as well. az group create --name securewebsetup --location westeurope az appservice plan create --resource-group securewebsetup --name securewebplan --sku B1 az webapp create --resource-group securewebsetup --plan securewebplan --name securewebapp2021 --https-only # Web App name must be globally unique Debug page (optional) To help debug the application, you can create a file called default.cshtml with the following content @using System.Web.Configuration @using System.Net; <html> <head> <title>Debug page</title> </head> <body style=\"background-color: #00E60A;\"> @{ var pubIp = new System.Net.WebClient().DownloadString(\"https://api.ipify.org\"); } <h3>Debug information</h3> <ul> <li><strong>Request Url</strong><span>: @Request.Url</span></li> <li><strong>Outbound public IP</strong><span>: @pubIp</span></li> <li><strong>Inbound client IP</strong><span>: @Request.ServerVariables[\"REMOTE_ADDR\"]</span></li> </ul> <strong>Headers</strong> <ul> @foreach (var h in Request.Headers) { <li><strong>@h</strong><span>: @Request.Headers[h.ToString()]</span></li> } </ul> </body> </html> Zip the file and push it to the Web App. Afterwards you should see a site with a green background and some Debug information: zip debug.zip default.cshtml az webapp deployment source config-zip --resource-group securewebsetup --name securewebapp2021 --src ./debug.zip Debug page on Linux (optional) If you are using App Service on Linux with Code deployment, you can use a php debug file. Create a file named index.php with the following content: <html> <head> <title>Debug page</title> </head> <body style=\"background-color: #00E60A;\"> <?php $requestPageUrl = (isset($_SERVER['HTTPS']) ? \"https\" : \"http\") . \"://\" . $_SERVER[\"HTTP_HOST\"] . $_SERVER[\"REQUEST_URI\"]; $pubIp = file_get_contents('https://api.ipify.org'); ?> <h3>Debug information</h3> <ul> <li><strong>Request Url</strong><span>: <?php echo $requestPageUrl; ?></span></li> <li><strong>Outbound public IP</strong><span>: <?php echo $pubIp ?></span></li> <li><strong>Inbound client IP</strong><span>: <?php echo $_SERVER['REMOTE_ADDR']; ?></span></li> </ul> <strong>Headers</strong> <ul> <?php foreach (getallheaders() as $name => $value) { echo \"<li><strong>$name</strong><span>: $value</span></li>\"; } ?> </ul> </body> </html> Zip the file and push it to the Web App. Afterwards you should see a site with a green background and some Debug information: zip debug.zip index.php az webapp deployment source config-zip --resource-group securewebsetup --name securewebapp2021 --src ./debug.zip Authentication setup App Service provides a simple way to setup authentication. The feature is sometimes referred to as Easy Auth. There is a new version just released and for this setup some of the new options are needed. The new Authentication feature is available in the Azure portal, but a few advanced configuration options are not yet exposed in the portal, so let’s look under the hood using the REST API. You have to get the Resource ID of the Web App. It was returned when you created the Web App in the previous steps, and you can also find it in the portal under Properties. This goes for any resource. Ensure that you can read the settings first. Pay attention to the api-version. You should see a lot of json returned when running this command: az rest --uri /subscriptions/REPLACE-ME-SUBSCRIPTIONID/resourceGroups/REPLACE-ME-RESOURCEGROUP/providers/Microsoft.Web/sites/REPLACE-ME-APPNAME?api-version=2020-09-01 --method get All the Authentication settings are defined in a json structure. There are many options to fine tune the configuration, but the snippet below is an extraction of the required settings needed for this scenario. Copy this into a file called auth.json: { \"properties\": { \"platform\": { \"enabled\": true }, \"globalValidation\": { \"unauthenticatedClientAction\": \"RedirectToLoginPage\", \"redirectToProvider\": \"azureActiveDirectory\" }, \"httpSettings\": { \"requireHttps\": true }, \"login\": { \"preserveUrlFragmentsForLogins\": true, \"allowedExternalRedirectUrls\": [ \"https://REPLACE-ME-WEBAPP-NAME.azurewebsites.net/\" ] }, \"identityProviders\": { \"azureActiveDirectory\": { \"enabled\": true, \"registration\": { \"openIdIssuer\": \"https://sts.windows.net/REPLACE-ME-TENANTID/v2.0\", \"clientId\": \"REPLACE-ME-APPID\", \"clientSecretSettingName\": \"REPLACE-ME-SECRETNAME\" }, \"validation\": { \"allowedAudiences\": [ \"https://REPLACE-ME-WEBAPP-NAME.azurewebsites.net\" ] } } } } } The file has some placeholders that you need to fill in with your own values. You will generate these values in the next few steps. You have already come across the first two REPLACE-ME-WEBAPP-NAME occurrences. This value should be replaced with the name of your Web App (in my case this was “securewebapp2021”). You can find the value for REPLACE-ME-TENANTID by running az account show and looking in the homeTenantId property. Next, create an App registration in Azure AD. An App registration is a way to tell Azure AD that this Web App is allowed to authenticate users in the directory and that it can do so only using specific urls. The display name can be anything. The reply-url is your base url combined with a special callback path: https://securewebapp2021.azurewebsites.net/.auth/login/aad/callback az ad app create --display-name securewebapp2021 --reply-urls https://securewebapp2021.azurewebsites.net/.auth/login/aad/callback Replace REPLACE-ME-APPID in auth.json with the the appId from the returned output. For the last placeholder REPLACE-ME-SECRETNAME, this will be the name of an App Setting in your Web App that contains the secret. The App Setting can reference a Key Vault secret if you prefer. You can pick any name. I will choose AAD_CLIENT_SECRET. To add the secret, run the following command (with the AppId from the previous step). If you leave out the password parameter, it will auto-generate a complex password: az ad app credential reset --id REPLACE-ME-APPID --password \"reP!@ce-w!th.VeRys3cr3tC0d!\" Add the value of the generated password to the App Settings of the Web App: az webapp config appsettings set --resource-group securewebsetup --name securewebapp2021 --settings \"AAD_CLIENT_SECRET=reP!@ce-w!th.VeRys3cr3tC0d!\" Finally, let’s update the Web App with the Authentication configuration (make sure you save your auth.json file and append /config/authsettingsV2 to the Resource ID): az rest --uri /subscriptions/REPLACE-ME-SUBSCRIPTIONID/resourceGroups/REPLACE-ME-RESOURCEGROUP/providers/Microsoft.Web/sites/REPLACE-ME-APPNAME/config/authsettingsV2?api-version=2020-09-01 --method put --body @auth.json If you browse to the site now, you should be redirected to consent to the App permissions and login to your Azure AD tenant. If you deployed the debug site, you will notice some extra headers prefixed with X-MS-CLIENT-PRINCIPAL. 2. Add Azure Front Door Azure Front Door is a global, scalable entry-point that uses the Microsoft global edge network to create fast, secure, and widely scalable web applications. With Front Door, you can transform your global consumer and enterprise applications into robust, high-performing personalized modern applications with contents that reach a global audience through Azure. Azure Front Door (Standard and Premium) combines the existing features of Front Door (Classic) with integrated CDN and WAF capabilities as well as some new advanced options to use private endpoints as origin (backend) and onboard Managed Certificates using TXT records, which can be helpful in a migration scenario. Open the Azure portal. Create a new resource, search for Front Door, and select “Front Door and CDN profiles” Use the Quick Create and under Basics, use the existing resource group. Give it a name and endpoint name, and select your App Service Web App. If you want to try out the private endpoint feature or WAF capabilities later, you should select the Premium tier. Once it is created, it typically takes 5-10 minutes to replicate globally. Go grab a coffee and come back when this is complete. Alter authentication settings After a good coffee, try to browse to the Front Door URL. In my case: https://secureweb.z01.azurefd.net. It appears to be working, but notice the address bar. It redirected you directly back to your Web App. To fix that you need to do a few things. First, update the App registration in Azure AD to allow authentication request coming from the new url. You can add multiple reply-urls by separating them with a space, but if you only want to allow authentication through Front Door, you can just replace it. az ad app update --id REPLACE-ME-APPID --reply-urls https://secureweb.z01.azurefd.net/.auth/login/aad/callback https://securewebapp2021.azurewebsites.net/.auth/login/aad/callback Second, it is time to look at one of the new features of Authentication in App Service. Open up the auth.json file again and in the login section under allowedExternalRedirectUrls, add the Azure Front Door url. You should also add it in the AAD validation section under allowedAudiences (remember the comma in both settings). Finally, in auth.json, configure the Authentication framework to look for the original address. In forward proxies like Front Door, the address is typically sent in an http header called X-Forwarded-Host, which is covered by the Standard convention. The forwardProxy section goes to httpSettings. The final json file looks like this: { \"properties\": { \"platform\": { \"enabled\": true }, \"globalValidation\": { \"unauthenticatedClientAction\": \"RedirectToLoginPage\", \"redirectToProvider\": \"azureActiveDirectory\" }, \"httpSettings\": { \"requireHttps\": true, \"forwardProxy\": { \"convention\": \"Standard\" } }, \"login\": { \"preserveUrlFragmentsForLogins\": true, \"allowedExternalRedirectUrls\": [ \"https://securewebapp2021.azurewebsites.net\", \"https://secureweb.z01.azurefd.net\" ] }, \"identityProviders\": { \"azureActiveDirectory\": { \"enabled\": true, \"registration\": { \"openIdIssuer\": \"https://sts.windows.net/REPLACE-ME-TENANTID/v2.0\", \"clientId\": \"REPLACE-ME-APPID\", \"clientSecretSettingName\": \"AAD_CLIENT_SECRET\" }, \"validation\": { \"allowedAudiences\": [ \"https://securewebapp2021.azurewebsites.net\", \"https://secureweb.z01.azurefd.net\" ] } } } } } Save the file and run the az rest command again to update the settings: az rest --uri /subscriptions/REPLACE-ME-SUBSCRIPTIONID/resourceGroups/REPLACE-ME-RESOURCEGROUP/providers/Microsoft.Web/sites/REPLACE-ME-APPNAME/config/authsettingsV2?api-version=2020-09-01 --method put --body @auth.json You should now be able to access the Web App through Front Door and be authenticated. If you added the debug page, you should also see a few additional headers. One being X-Forwarded-Host that contains the url of the Front Door and the other being X-Azure-FDID which contains the unique ID of your Front Door instance (make a note of this as it will be used in step 4). 3. (Optional) Add Custom Domain and Certificate With Azure Front Door, it’s easy to add a custom domain and certificate. If you do not already have a custom domain, you can purchase one from Azure App Service Domains. For this demo, I will be using a domain called reddoglabs.com purchased through App Service Domains and I will be using Azure DNS to host the public DNS records. Note that any domain registrar and public DNS provider can be used. If you are using an Azure DNS Zone in the same subscription, you have the added benefit of having Front Door add the needed records for you. For the certificate, you can bring your own certificate or you can use the Managed Certificate option. With the latter, Front Door will take care of enrolling and renewing the certificate - I like that so I do not forget to update my certificate when it expires. My DNS is in another subscription, so I will have to add it myself, but it will also explicitly show the steps needed. After you added the domain, you need to prove that you own it. The new Front Door gives you a nice overview of the steps needed. When clicking the Pending link in the Validation state column, you will get instruction for adding a TXT record to validate your domain ownership. Time for another cup of coffee. The validation of the TXT record and the replication of the settings can take 5-10 minutes again. Alter authentication settings Azure AD App registration and App Service Authentication need to be aware of the new url. You can either append or overwrite with the new url depending on whether you want the other urls to work as well. Update the App registration with the this command (here I am appending): az ad app update --id REPLACE-ME-APPID --reply-urls https://secure.reddoglabs.com/.auth/login/aad/callback https://secureweb.z01.azurefd.net/.auth/login/aad/callback https://securewebapp2021.azurewebsites.net/.auth/login/aad/callback Modify the auth.json file and update the Authentication settings. { \"properties\": { ... \"login\": { \"preserveUrlFragmentsForLogins\": true, \"allowedExternalRedirectUrls\": [ \"https://secure.reddoglabs.com\", \"https://securewebapp2021.azurewebsites.net\", \"https://secureweb.z01.azurefd.net\" ] }, \"identityProviders\": { ... \"validation\": { \"allowedAudiences\": [ \"https://secure.reddoglabs.com\", \"https://securewebapp2021.azurewebsites.net\", \"https://secureweb.z01.azurefd.net\" ] } } } } } az rest --uri /subscriptions/REPLACE-ME-SUBSCRIPTIONID/resourceGroups/REPLACE-ME-RESOURCEGROUP/providers/Microsoft.Web/sites/REPLACE-ME-APPNAME/config/authsettingsV2?api-version=2020-09-01 --method put --body @auth.json Associate and map custom domain The final steps are to go back to the Domains overview in Front Door and associate the custom domain with the endpoint, and add a CNAME DNS record to map the actual domain: Allow another 5-10 minutes to replicate the settings globally, and you should now be able to access an authenticated Web App through Front Door using a custom domain and certificate. 4. Restrict traffic from Front Door to Web App At this point, you are still able to access the Web App directly. In this step, you will restrict access to the Web App so traffic will only be allowed through Front Door. To do this, another new feature will be used. Access restrictions in App Service recently added the ability to create rules based on Service Tags and filter by http headers. Azure CLI support for the new features is still under construction, but since you are familiar with using REST calls by now, let’s do that. Create a json file named restrictions.json with the the following content and replace the placeholder with the specific Front Door ID found in step 2. It is also visible in the Overview section of the Front Door instance in the Azure portal: { \"properties\": { \"ipSecurityRestrictions\": [ { \"action\": \"Allow\", \"ipAddress\": \"AzureFrontDoor.Backend\", \"tag\": \"ServiceTag\", \"priority\": 100, \"headers\": { \"X-Azure-FDID\": [ \"REPLACE-ME-FRONTDOORID\" ] } } ] } } After you added the Front Door ID in the json file, run the following script to deploy the restriction (notice the change in the URI: /web instead of /authsettingsV2): az rest --uri /subscriptions/REPLACE-ME-SUBSCRIPTIONID/resourceGroups/REPLACE-ME-RESOURCEGROUP/providers/Microsoft.Web/sites/REPLACE-ME-APPNAME/config/web?api-version=2020-09-01 --method put --body @restrictions.json Now, if you access the site directly, you should immediately see the blue 403 - Forbidden error. 5. Increase resiliency with multiple geo-distributed Web Apps To improve resiliency of your App and protect against regional outages, you can deploy your app to multiple regions. Let’s add an instance in West US. You can reuse most of the scripts, but of course you need to change the name in all lines. Since direct access to the Web App is already blocked, you can either remove or ignore the direct Web App url reference in auth.json. To make it easier to notice which site is accessed, you can change the background color of the debug page in the alternative site by changing the last two digits of the body background-color to FF (light blue) and create a new zip file: az appservice plan create --resource-group securewebsetup --name securewebplan-westus --sku B1 --location westus az webapp create --resource-group securewebsetup --plan securewebplan-westus --name securewebapp2021-westus az webapp update --resource-group securewebsetup --name securewebapp2021-westus --https-only zip debug-blue.zip default.cshtml az webapp deployment source config-zip --resource-group securewebsetup --name securewebapp2021-westus --src ./debug-blue.zip az webapp config appsettings set --resource-group securewebsetup --name securewebapp2021-westus --settings \"AAD_CLIENT_SECRET=reP!@ce-w!th.VeRys3cr3tC0d!\" az rest --uri /subscriptions/REPLACE-ME-SUBSCRIPTIONID/resourceGroups/REPLACE-ME-RESOURCEGROUP/providers/Microsoft.Web/sites/REPLACE-ME-WESTUS-APPNAME/config/authsettingsV2?api-version=2020-09-01 --method put --body @auth.json az rest --uri /subscriptions/REPLACE-ME-SUBSCRIPTIONID/resourceGroups/REPLACE-ME-RESOURCEGROUP/providers/Microsoft.Web/sites/REPLACE-ME-WESTUS-APPNAME/config/web?api-version=2020-09-01 --method put --body @restrictions.json After the Web App is configured, open the Front Door instance in the Azure portal and add the new Web App as origin (backend) in the current origin group and update it: Front Door default load balancing behavior is to round robin traffic between the fastest and the next fastest origins within the configured latency sensitivity, but you can modify that. If you refresh enough times, you should be seeing the page change color (and the Request url in the debug page change). Alternative approaches and advanced scenarios In this section, I will discuss some alternative approaches and advanced scenarios. Application Gateway Instead of Front Door, or in addition to Front Door, you can use Azure Application Gateway to add WAF capabilities and advanced routing and rewrite logic. It can also be used to provide regional load balancing. Application Gateway currently does not support Managed Certificate, so you will have to bring your own certificate. Application Gateway deviates from the standard http header used for the forwarded host. It uses a header called X-Original-Host. For the Authentication configuration in auth.json, you will have to change the convention to Custom and specify X-Original-Host as the customHostHeaderName. The rest of the settings and steps should be identical. \"forwardProxy\": { \"convention\": \"Custom\", \"customHostHeaderName\": \"X-Original-Host\" } Private endpoint To secure the incoming traffic to the Web App(s), the access restriction feature was used. If you prefer private endpoints, this is also possible. The next generation Azure Front Door supports setting up a private endpoint from your Front Door instance directly to your Web App. For App Service, private endpoints require the Premium tier, so you need to scale up the App Service Plan. Besides that, the only change will be the setup of origin in Front Door, which is where you can request the creation of a private endpoint, and then from the Web App(s) you can approve it. The step of uploading the debug page will require some additional setup. The SCM site will also only be available through the private endpoint. You will have to run the script from within a network with line-of-sight and proper DNS resolution for the private endpoint. Custom domain for SCM Site While not directly related to the Authentication part, you may want/need to expose the SCM site through a proxy if you want access through a custom domain or if you want to expose a private endpoint enabled SCM site externally. A post on how to do that was recently published. Custom health probe path If you have a custom health probe path, you can configure the Authentication layer in App Service to allow unauthenticated traffic on specific paths. These paths are configured in the auth.json file in excludedPaths under globalValidation. An example of excluding the debug page if accessed directly will look like this: \"globalValidation\": { \"unauthenticatedClientAction\": \"RedirectToLoginPage\", \"redirectToProvider\": \"azureActiveDirectory\", \"excludedPaths\": [ \"/default.cshtml\" ] } You can now browse directly to that page (but will be asked for authentication if you just go to /) FAQ Q: On sign in, I get error AADSTS50011: The reply URL specified … What is wrong? Most likely this is because the address does not match the reply-url configured for the Azure AD App registration. Q: I am using custom routing rules in Front Door. Anything I should pay attention to? Make sure you have a routing rule for .auth/* in addition to your content rules. Q: I do not have permissions to create App registrations in my Azure AD tenant, what to do? If your organization locked down the ability to create App registrations, you will need to find someone in your organization with these permissions. It can either be the tenant admin or delegated with the built-in Application developer og Application administrator roles; or a custom Application registration creator role specific for this purpose. Alternatively you can use another identity provider such as Facebook, GitHub, Twitter or any custom provider using the OpenIdConnect specification. ","categories": ["networking"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2021/03/26/Secure-resilient-site-with-custom-domain.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "General Availability of new Access Restriction Features",
+ "excerpt":"We are happy to announce the General Availability of a number of improvements to the access restriction feature in App Service. Service tag-based rules Networking service tags define the set of IP CIDR ranges used for a given Azure service. As these ranges change, the tags will be automatically updated to reflect the change with no change needed from the customer side. The tags cover different scopes such as data plane and management plane, and different directions like inbound, outbound and both. Service tags can be global or regional. For example, AzureCloud covers all ranges used in Azure public cloud and AzureCloud.WestEurope covers the subset of these ranges used in the West Europe region. Service tag-based rules can be used to allow or deny inbound traffic to App Service. Common use cases include: Azure Traffic Manager health probes, which are covered by the AzureTrafficManager service tag Logic Apps, where an API call hosted in an App Service is part of the flow. These can also be regional like LogicApps.SouthEastAsia Azure Front Door backend traffic. Used to isolate traffic between the Front Door infrastructure and your App Service. Tag name is AzureFrontDoor.Backend Application Insight availability probes using ApplicationInsightsAvailability Azure portal supports the most common scenarios and for advanced configuration, you can use Azure PowerShell. Multi-source rules Multi-source rules allow you to define multiple IP address ranges as part of a rule. Each rule can support up to 8 ranges. Use cases for multi-source rules include: You need to specify more than 512 ranges for an App Service You want to logically group ranges in a rule. For example, both the IPv4 and IPv6 ranges of an internal service You want to combine a logical group of ranges with a http header filter Multi-source rules are currently supported through PowerShell. Http header filters In addition to specifying an IP range or service tag, you can also define specific values of http headers that must also be evaluated. Common cases are: Restrict traffic to specific Azure Front Door instance using X-Azure-FDID header Isolate traffic from forward proxy to specific client IPs or host names using X-Forwarded-For or X-Forwarded-Host header Http header filters can be added from Azure portal or through PowerShell. Putting it all together To see a good example of using some of these capabilities, you can follow this step-by-step guide setting up a secure resilient site. ","categories": ["networking"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2021/03/29/General-Availability-of-new-access-restriction-features.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Troubleshoot Network/Connectivity issues on App Service & Functions",
+ "excerpt":"Troubleshooting networking & connectivity issues when running on App Services just became easier. We are happy to announce the release of our new diagnostic tool ‘Network/Connectivity Troubleshooter’ available now in the Diagnose & Solve Problems blade. You can access the tool by going to the Diagnose & Solve Problems blade and either use the search bar to search for it or use the quick link available under popular troubleshooting tools section: This guided troubleshooter takes you step by step to understand your issue and provide curated solutions based on your inputs: Unable to connect to a resource, such as SQL or Redis or on-prem, in my Virtual Network This flow will start by running the following checks on your app: VNet integration health Networking configuration checks If an issue is found, the troubleshooter will display the issue along with the recommended next steps to you: If everything looks healthy or just a warning insights was discovered, the flow will continue to ask for an endpoint to test connectivity to. You can use a hostname:port or IP:port combination to test the connectivity. Please note that this is just a tcpping from your app’s instance to the specific endpoint. The connection could succeed on a tcp level, but you might still be facing issues executing http requests for example. The troubleshooter will show you the results clearly along with recommendations: Tried to configure VNet integration via Azure Portal or ARM template, but it failed If you attempted to connect your app to a subnet and it failed and would like to get more information, this flow will help you with this. You can select the VNet/subnet combo that you’re attempting to connect to, and the tool will give you an insight if the integration will succeed or not along with a detailed explanation. Learn more about VNet integration Finally, if you are new to VNet integration with App Services and would like to learn more, this flow will show you common docs that help our customers learn about general VNets in Azure as well as how to integrate an App Service with a VNet. What’s next? Within the next few months, we will be adding new flows to allow you to diagnose & solve more networking related issues with this troubleshooter. If you have any questions or feedback, please reach out to our team at diagnostics@microsoft.com ","categories": ["diagnostics"],
+ "tags": ["Network","Virtual Network","VNET","Connectivity"],
+ "url": "https://azure.github.io/AppService/2021/04/13/Network-and-Connectivity-Troubleshooting-Tool.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Migrating your .NET 3.1 Applications to .NET 5",
+ "excerpt":".NET 5 is the first major release in the .NET unification journey bringing together the best of Core, Framework, Xamarin, and Mono to provide an improved developer experience. Although .NET 6 (Preview) is currently available, it is recommended that you migrate your .NET 3.1 applications to .NET 5 prior to migrating to .NET 6 (LTS). This article outlines what needs to be addressed in an existing .NET 3.1 application when migrating to .NET 5 before publishing it to App Service. For information on hosting .NET 5 applications on App Service please visit our blog. Update your application The first step to updating your application to .NET 5 is to go to the project file and update the Target Framework Moniker. Setting the Target Framework tells your application which version you’d like to target by specifying the set of APIs that you want to be made available to your application or library. In your .csproj file, replace netcoreapp3.1 with net5.0 to update the targeted version <TargetFramework>netcoreapp3.1</TargetFramework> <TargetFramework>net5.0</TargetFramework> After you’ve updated the Target Framework and saved the application. You will notice that your bin is populated with .NET 5 Debug and Release folders, these will include necessary .json, .exe and .dll files that are needed when publishing to App Service. These folders will remain empty until you Build your solution locally. Go to Build in the top menu bar in Visual Studio and select Build Solution to populate the net5.0 folder. Your Release folder will populate when you Publish your application. Package References Depending on your application, you may have a number of package references that you rely on. You will need to update each package references Version to match the new version. In your .csproj file, update the Version from “3.x.x” to “5.0.0” <ItemGroup> <PackageReference Include=\"Microsoft.EntityFrameworkCore.Tools\" Version=\"3.1.6\"> <PackageReference Include=\"System.Net.Http.Json\" Version=\"3.2.1\" /> </ItemGroup> <ItemGroup> <PackageReference Include=\"Microsoft.EntityFrameworkCore.Tools\" Version=\"5.0.0\"> <PackageReference Include=\"System.Net.Http.Json\" Version=\"5.0.0\" /> </ItemGroup> global.json If you are using the global.json file to specify which SDK version you want to use in your application, then you will need to update this as well. If you are not using a global.json file then you can skip this step. Replace the SDK version from 3.1.200 to 5.0.100 { \"sdk\": { \"version\": \"3.1.200\" } } { \"sdk\": { \"version\": \"5.0.100\" } } Docker If you are using Docker to containerize your .NET applications you will need to update your Dockerfile FROM statements for your base image and SDK version. See below for examples for both Windows and Linux. Before # .NET 3.1 FROM mcr.microsoft.com/dotnet/aspnet:3.1 AS base # Windows # FROM mcr.microsoft.com/dotnet/aspnet:3.1-buster-slim # Linux WORKDIR /app EXPOSE 80 FROM mcr.microsoft.com/dotnet/sdk:3.1 AS build # Windows # FROM mcr.microsoft.com/dotnet/sdk:3.1-buster-slim AS build # Linux WORKDIR /src COPY [\"mydotnetapp/mydotnetapp.csproj\", \"mydotnetapp/\"] RUN dotnet restore \"mydotnetapp/mydotnetapp.csproj\" COPY . . WORKDIR \"/src/mydotnetapp\" RUN dotnet build \"mydotnetapp.csproj\" -c Release -o /app/build FROM build AS publish RUN dotnet publish \"mydotnetapp.csproj\" -c Release -o /app/publish FROM base AS final WORKDIR /app COPY --from=publish /app/publish . ENTRYPOINT [\"dotnet\", \"mydotnetapp.dll\"] After # .NET 5.0 FROM mcr.microsoft.com/dotnet/aspnet:5.0 AS base # Windows # FROM mcr.microsoft.com/dotnet/aspnet:5.0-buster-slim AS base # Linux WORKDIR /app EXPOSE 80 EXPOSE 443 FROM mcr.microsoft.com/dotnet/sdk:5.0 AS build # Windows # FROM mcr.microsoft.com/dotnet/sdk:5.0-buster-slim AS build # Linux WORKDIR /src COPY [\"mydotnetapp/mydotnetapp.csproj\", \"mydotnetapp/\"] RUN dotnet restore \"mydotnetapp/mydotnetapp.csproj\" COPY . . WORKDIR \"/src/mydotnetapp\" RUN dotnet build \"mydotnetapp.csproj\" -c Release -o /app/build FROM build AS publish RUN dotnet publish \"mydotnetapp.csproj\" -c Release -o /app/publish FROM base AS final WORKDIR /app COPY --from=publish /app/publish . ENTRYPOINT [\"dotnet\", \"mydotnetapp.dll\"] After you’ve completed the updates in your application to .NET 5 you are now ready to publish to App Service as you normally would. While the publish is ongoing it will populate the Release files mentioned above in the net5.0 reference folder equipping your application with the necessary files to run on App Service. Update Stack Settings After you’ve published your application to App Service you may choose to update your Stack settings (this sets the language and SDK version used to run the app) in your applications Configuration to match the newer version. While this step is not required to successfully run your updated application on Windows App Service, it is recommended to prevent confusion in the future when looking at the Configuration settings. Go to Configuration under Settings, click the General settings tab and update the Stack settings .NET Version to .NET 5. Then click the Save icon above. Once it is saved, your application will restart. If you are using Linux, your Major and Minor version will auto-populate to .NET 5 upon publishing. From here your application is now updated and configured to use .NET 5. For more information on migrating your .NET 3.1 apps to .NET 5, please visit the documentation. Resources Migrate from ASP.NET Core 3.1 to 5.0 Configure app settings Select the .NET version to use ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2021/04/14/Migrating-your-dotnet-31-applications-to-dotnet-5.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Upgrade Notifications for App Service (Preview)",
+ "excerpt":"The Azure App Service is a PaaS solution offering in Azure which constantly updates the platform. One of the top requests from customers is to receive a notification before an upgrade operation happens. We are happy to announce that notifications for scheduled maintenance on App Service Environments is now available in Preview. With these notifications, you will be able to receive email or SMS text alerts before a platform upgrade starts. You can also invoke Azure Functions or Logic Apps based on these notifications. This feature has been rolled out for App Service Environments (ASEs) across our regions. This article shows how to set up email and SMS alerts, as well as Function and Logic Apps to consume the events. Support for the multi-tenant version of App Service will be coming soon. Overview Our maintenance notification for App Service is an event in Azure Monitor. This means that you can set up your email address and/or SMS phone number when a notification is generated. You can also set up a trigger for your custom Azure Function or Logic App, which allows you to automatically take action to your resources. For example, you can automatically divert all the traffic from your ASE in one region which will be upgraded to ASE in another region in order to avoid any potential impact. Then you can automatically change the traffic back to normal when an upgrade completes. Please refer to Logic App sample for automatic traffic diversion for Azure App Service for more details. Viewing upgrade notifications On the Azure portal, go to Home > Monitor > Service Health > Planned maintenance. Here you can see all active (including upcoming or in-progress) notifications for the selected subscriptions. To make it easy to find App Service upgrade events, click Service box, check all App Service types and uncheck everything else. To see past notifications, navigate to Health history and filter Planned maintenance from the Health Event Type box. Setting up alerts Open Azure portal, sign in with your credentials. Search an icon named Monitor and click it. If you cannot see it, click the big right arrow on the right to show All services, then search Monitor. In the left menu items, click Alerts. Click Service Health. Click Add service health alert at the top center. In the Condition section, choose the subscription that owns your ASEs. At the Service(s) box, choose all items starting with App Service: App Service App Service \\ Web Apps App Service (Linux) App Service (Linux) \\ Web App for Containers App Service (Linux) \\ Web App. At the Region(s) box, make sure to check the regions of the ASEs. At the Event type box, check Planned maintenance. In the Actions section, click Add action groups. Click Create alert rule. Select a subscription that your ASE belongs to. Choose a resource group and name an action group. Set Display name to something you can easily identify the action (IMPORTANT: The display name will be shown in every email/SMS/post of the notifications.) If you want to receive text notifications: In the Notifications section, choose Email/SMS message/Push/Voice at the Notification type. Then choose output channels you need (For example, Email or SMS.) Put email addresses or phone number as necessary. If you want to hook up your custom automation: In the Actions section, choose Azure Function or Logic App at the Action type. Put a name into the Name. Select your app. Press Save changes. The page will go back to the Rules management page. In the Alert rule details section, set a name. Click Save. More resources Azure Monitor documentation Common alert schema definitions Logic App sample for automatic traffic diversion for Azure App Service FAQ When do you send the upgrade notifications? The first notifications will be created about 60 to 90 minutes before an actual upgrade operation starts. We don’t create notifications anything earlier due to some limitations at this moment. Once the upgrade starts, we send in-progress notifications every 12 hours until the operation completes. After it’s finished we send a notification of completion. Is it in preview now? Yes, it’s currently in preview. We are collecting feedback and usage telemetry. We will announce a date for General Availability as one becomes available. Can we get notifications earlier, like one day before? At this time, 60 minutes to 90 minutes is the earliest notification lead-time. Is it only available for ASEs? Yes, currently it is only available for ASEs. We are actively working on enabling it for the multi-tenant version of App Service. Can I invoke my Azure Function when a notification comes? Yes, you can set up action to trigger your Azure Function or Logic App. Please see Logic App sample for automatic traffic diversion for Azure App Service as example. To see the data format of the notifications, refer to Common alert schema definitions. ","categories": [],
+ "tags": ["Azure Monitor","App Service Environment"],
+ "url": "https://azure.github.io/AppService/2021/04/14/upgrade-notification-for-ase.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Running .NET 6 (Preview) on App Service",
+ "excerpt":".NET 6 is the latest release version that will include the final pieces bringing the best of Core, Framework, Xamarin, and Mono to a unified platform that started with .NET 5. This version is currently available as a preview version for use in new or existing applications with a planned GA date of November 2021. The final release of .NET 6 will be the Long-Term Support (LTS) version of the new .NET to be supported for 3-years. Find more information on the release here. To get started with .NET 6 (Preview) on App Service you can use one of two deployment methods. A Self-Contained deployment will allow you to deploy your app on machines that don’t have the runtime installed. You can also deploy your application with a more portable solution using a Container which will package your app and dependencies to run on App Service. Migrating your .NET 3.1 apps to .NET 6? We recommend going to .NET 5 before jumping to 6, see our previous article. Local Setup In order to setup .NET 6 in your application you need to first install the .NET 6 SDK. For our examples below we will be using the latest .NET SDK 6 Preview 2. If you’re on Windows using Visual Studio, you will also need to download the latest Visual Studio Preview version here. Self-Contained Deployment A Self-Contained deployment enables you to run .NET 6 because it doesn’t rely on the presence of shared components on the target system and all components including Core libraries and runtime are with the application and isolated from other apps. This way you have sole control of which version your application is running. Self-contained deployments are supported for both Windows and Linux apps. Note that with self-contained applications you should be aware of large deployments and managing updates as this will take up more hard drive space and cause you to be responsible for supplying updated versions of your app with new security patches. To complete a self-contained deployment in .NET you would first create your project as usual then choose .NET 6 (Preview) for your apps version after selecting your application template. Select Create and modify your application as needed. To publish, Right-Click your project and select publish. In the latest version of Visual Studio you can choose where your target publish is from a new menu. Select Azure. Then select Azure App Service (Windows) or Azure App Service (Linux) depending on your preference on the following screen. Next, choose a previously created App Service or create one from Visual Studio and fill out the required information as you normally would when publishing. When you reach the publish screen click the pencil icon to edit your Deployment Mode for publishing your application. Then, Choose the Deployment Mode option and make sure Self-Contained is chosen. After you select the Self-Contained option your Target Runtime will auto-populate to linux-x64 or win-x86 depending on your operating system selection. Save your new settings and click Publish on the preceding screen to publish to App Service and launch your application using .NET 6. More information on self-contained deployment can be found here. Container Deployment The other option for running your .NET 6 (Preview) application is to deploy a Docker container to App Service on Linux or Windows. When deploying a container, you are packaging the application and its dependencies into a Linux or Windows based image to run on the App Service platform. This enables your application to be more portable in nature as it is not reliant on the host operating system and has the runtime and SDK added into the image. Once you have your application setup for .NET 6, the steps to deploy a containerized application would be the same as any other container deployment. Right-click your project, Add -> Docker Support, then choose Linux or Windows. Your .NET 6 project will have a new Dockerfile added with the .NET 6.0 base image and SDK ready for you to publish. After you have added Docker support, you will publish it to a registry, and create your App Service as usual. See our documentation for more detail on deploying a containerized application. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2021/04/15/Running-dotnet-6-Preview-on-App-Service.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Announcing Auto Heal for Linux",
+ "excerpt":"We are happy to announce the availability of Auto Heal feature for Linux apps on Azure App Service. Auto Heal allows you to mitigate your apps when it runs into unexpected situations like HTTP server errors, resource exhaustion, etc. You can configure different triggers based on your need and choose to recycle the app to recover it from a bad state. This functionality has been a part of Azure App Service Windows for quite some time and today we are happy to announce the availability for apps running on the Linux stack. Enabling Auto Heal in the Portal On your Linux app, click Diagnose and Solve problems > Diagnostic Tools > Auto-Heal. Supported Triggers Auto Heal for Linux supports the following triggers: Request Duration - This trigger can help you mitigate an app that is slow to respond to requests. You can even specify the mitigation to kick in if specific URLs take longer than the expected duration. Request Count - If you want to recycle your container after a fixed number of requests, you can configure the request count rule. Status Codes - If the app starts failing unexpectedly, this trigger can help you recover it by restarting the container. You can choose either a range of status codes or a single HTTP status code. The trigger also allows you to specify specific request paths. Note: The only supported action is to Recycle the container. More actions will be supported in the future. Finalize Configuration Overriding the Startup Time (optional) - It is a good practice to specify a startup time greater than the average startup time for your app. By modifying the startup time, you can specify how much time the mitigation rule should wait after the container startup before the mitigation rule triggers again. Once the rules are configured, review them to ensure they are configured correctly and click the Save button. Get ahead of your app’s issues and automatically mitigate these unexpected behaviors with Auto Heal in App Service Diagnostics. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2021/04/21/Announcing-Autoheal-for-Azure-App-Service-Linux.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Deploying a site with secure backend communication",
+ "excerpt":"“Rød grød med fløde” - hmm, what language is that? Keep reading if you want to find out. In this article I will walk you through setting up a Web App with secure, network-isolated communication to backend services. The Web App will allow you to type in a text, and using Cognitive Services Language Detection, you can detect the language of the given text. The authentication key for Cognitive Services will be stored in Key Vault, and App Service will authenticate with Key Vault using Managed Identity. All traffic will be isolated within your Virtual Network using virtual network integration and private endpoints. The scenario is intentionally kept simple to focus on the architecture and configuration; but with a practical purpose I find it more easy to relate to. The backend services can be extended with the many other services supporting Private Endpoint like Azure SQL, Cosmos DB, App Configuration, and even other App Service Web Apps or Functions by following the same pattern. This guide is organized into four steps: Create network infrastructure Set up backend services Create network integrated Web App Connect “the dots” In closing, there are sections on alternative approaches, advanced scenarios, and FAQ. Getting Started This is the second article in a series focusing on network security. If you missed the first one, you can find it here, and it includes a more detailed getting started section covering setting up the scripting environment. This article will also use the Azure CLI executed in bash shell on WSL to set up the environment. It could be done using teh Azure portal, Resource Manager templates or Azure PowerShell. CLI was chosen as I find it easier to follow and explain the individual steps and configurations needed. Remember in the scripts to replace all the resource names that need to be unique. This would be the name of the Web App, Key Vault, Cognitive Services account, and custom domain. You may also change location if you want something closer to home. All other changes are optional. 1. Create Network Infrastructure First, set up a Resource Group with a Virtual Network. The virtual network should have at least two subnets: one for the virtual network integration and one for the private endpoints. The address-prefix size must be at least /28 for both subnets; small subnets can affect scaling limits and the number of private endpoints. Go with /24 for both subnets if you are not under constraints. az group create --name securebackendsetup --location westeurope az network vnet create --resource-group securebackendsetup --location westeurope --name securebackend-vnet --address-prefixes 10.0.0.0/16 For the subnets, there are two settings that we need to pay attention to. This is often set by the portal or scripts, but here it is called out directly. Delegation “Microsoft.Web/serverfarms” informs the subnet that it is reserved for virtual network integration: az network vnet subnet create --resource-group securebackendsetup --vnet-name securebackend-vnet --name vnet-integration-subnet --address-prefixes 10.0.0.0/24 --delegations Microsoft.Web/serverfarms az network vnet subnet create --resource-group securebackendsetup --vnet-name securebackend-vnet --name private-endpoint-subnet --address-prefixes 10.0.1.0/24 The last part of the network infrastructure is the Private DNS Zones. These zones are used to host the DNS records for private endpoints allowing the clients to find the backend services by name. We need a zone for Key Vault and a zone for Text Analytics (Cognitive Services). Go here for a primer on Azure Private Endpoints and go here for how DNS Zones fits into private endpoints. Create the Private DNS Zones for Key Vault and Cognitive Services: az network private-dns zone create --resource-group securebackendsetup --name privatelink.cognitiveservices.azure.com az network private-dns zone create --resource-group securebackendsetup --name privatelink.vaultcore.azure.net Link the zones to the virtual network: az network private-dns link vnet create --resource-group securebackendsetup --name cognitiveservices-zonelink --zone-name privatelink.cognitiveservices.azure.com --virtual-network securebackend-vnet --registration-enabled False az network private-dns link vnet create --resource-group securebackendsetup --name vaultcore-zonelink --zone-name privatelink.vaultcore.azure.net --virtual-network securebackend-vnet --registration-enabled False … and now the core network setup is done. We can now create our backend resources. 2. Set Up Backend Services In this section, we will set up the Key Vault and the Cognitive Services (CS) account and store the access key for CS in Key Vault. We will also create the private endpoints and configure the services to block public traffic. First create the services: az keyvault create --resource-group securebackendsetup --name securekeyvault2021 --location westeurope --sku standard --enable-rbac-authorization az cognitiveservices account create --resource-group securebackendsetup --name securecstext2021 --location westeurope --kind TextAnalytics --sku F0 --custom-domain securecstext2021 Then we need to add the access key from CS as a secret in Key Vault. There are several ways to do this: directly in the Portal or using the CLI. What matters here is that the Identity (in this case, you) must have permissions to write secrets to Key Vault. We are using a new permission model in Key Vault, where the data plane permissions are set as RBAC permissions. In this mode, no default data plane permissions are set when creating the Key Vault. I am storing properties in variables for reuse in later steps. The --output tsv will ensure that the values do not have quotes. The --query parameter will allow me to return only a specific property. Note: The syntax for using variables depends on your choice of OS, shell and scripting language. Assign permissions for you (the signed in user) to write secrets. You can optionally use a service principal or other users if you have delegated responsibility: my_id=$(az ad signed-in-user show --query objectId --output tsv) kv_resource_id=$(az keyvault show --name securekeyvault2021 --query id --output tsv) az role assignment create --role \"Key Vault Secrets Officer\" --assignee-object-id $my_id --scope $kv_resource_id Then get the key from CS and store as a secret in Key Vault. We extract the URI of the secret as we need this in a later step. You can perhaps copy the secret in your notes if you plan on finishing later. The secret set command will display the secret in the shell if you are not querying a specific property. An alternative to tsv is to use --output none. Tip: In bash shell, which I am using, you can see the values of a variable by using the echo command, e.g. echo $kv_secret_uri cs_key1=$(az cognitiveservices account keys list --resource-group securebackendsetup --name securecstext2021 --query key1 --output tsv) kv_secret_uri=$(az keyvault secret set --vault-name securekeyvault2021 --name cskey --value $cs_key1 --query id --output tsv) Next, let’s create the Private Endpoints to connect the backend services to the virtual network. We already have the needed Key Vault Resource ID $kv_resource_id in a variable from a previous step: az network private-endpoint create --resource-group securebackendsetup --name securekeyvault-pe --location westeurope --connection-name securekeyvault-pc --private-connection-resource-id $kv_resource_id --group-id vault --vnet-name securebackend-vnet --subnet private-endpoint-subnet … and create a DNS Zone Group. This will create the DNS record for the private endpoint in the DNS Zone (and remove it if the private endpoint is deleted): az network private-endpoint dns-zone-group create --resource-group securebackendsetup --endpoint-name securekeyvault-pe --name securekeyvault-zg --private-dns-zone privatelink.vaultcore.azure.net --zone-name privatelink.vaultcore.azure.net Do the same for the Cognitive Services account: cs_resource_id=$(az cognitiveservices account show --resource-group securebackendsetup --name securecstext2021 --query id --output tsv) az network private-endpoint create --resource-group securebackendsetup --name securecstext-pe --location westeurope --connection-name securecstext-pc --private-connection-resource-id $cs_resource_id --group-id account --vnet-name securebackend-vnet --subnet private-endpoint-subnet az network private-endpoint dns-zone-group create --resource-group securebackendsetup --endpoint-name securecstext-pe --name securecstext-zg --private-dns-zone privatelink.cognitiveservices.azure.com --zone-name privatelink.cognitiveservices.azure.com Finally, let’s block public traffic. For CS, this property is not exposed in the official command, but we know our way around. You may need to fiddle a bit with the syntax for the az rest command if you are using an alternative shell/OS combination: az rest --uri $cs_resource_id?api-version=2017-04-18 --method PATCH --body '{\"properties\":{\"publicNetworkAccess\":\"Disabled\"}}' --headers 'Content-Type=application/json' az keyvault update --name securekeyvault2021 --default-action Deny Everything is locked down now and you cannot even get to the Key Vault secrets through the Azure portal. In the Key Vault Networking blade, you can add the public IP of your client if you need to view or update the secrets. 3. Create Network Integrated Web App Now we get to creating the actual Web App. To use virtual network integration, we need at least the Basic SKU. The virtual network integration feature allows outbound traffic to flow directly into the virtual network: az appservice plan create --resource-group securebackendsetup --name securebackendplan --sku P1V2 az webapp create --resource-group securebackendsetup --plan securebackendplan --name securebackend2021 --https-only az webapp vnet-integration add --resource-group securebackendsetup --name securebackend2021 --vnet securebackend-vnet --subnet vnet-integration-subnet Now, store the name of your CS account for the code to query. Replace securecstext2021 with the name of your account: az webapp config appsettings set --resource-group securebackendsetup --name securebackend2021 --settings CS_ACCOUNT_NAME=securecstext2021 As a last step in this section, we need to generate a Managed Identity, grant this identity read secrets permissions on the Key Vault, and reference the secret in an App Setting. We will reuse the Resource ID variable from a previous step. Go back up if you missed that. The identity command can directly assign permissions as part of the command, so we will grant the Web App “Key Vault Secrets User” (read) permissions: az webapp identity assign --resource-group securebackendsetup --name securebackend2021 --scope $kv_resource_id --role \"Key Vault Secrets User\" az webapp config appsettings set --resource-group securebackendsetup --name securebackend2021 --settings CS_ACCOUNT_KEY=\"@Microsoft.KeyVault(SecretUri=$kv_secret_uri)\" You can now browse to the Web App and all outbound traffic from the Web App will be routed through the virtual network. 4. Connect “The Dots” All the infrastructure is now in place and we just need a bit of code to glue it all together. I will be using php as it can run on both Windows and Linux App Service Plans, is easy to read, and allows for a single-file solution. Please do not mind the missing error handling, retry logic, etc. as this is a proof-of-concept. Copy the following code into a file called index.php and run these commands: zip default.zip index.php az webapp deployment source config-zip --resource-group securebackendsetup --name securebackend2021 --src ./default.zip The code for index.php: <?php if (!empty($_GET['text'])) { $text = urldecode($_GET['text']); $payload = [ 'documents' => array([ 'id' => '1', 'text' => $text ]) ]; $json_payload = json_encode($payload); $cs_key = getenv('CS_ACCOUNT_KEY'); $cs_name = getenv('CS_ACCOUNT_NAME'); $options = array( 'http'=>array( 'method'=>\"POST\", 'header'=>\"Ocp-Apim-Subscription-Key: \" . $cs_key . \"\\r\\n\" . \"Content-Type: application/json\\r\\n\" . \"Accept: application/json\\r\\n\" . \"Connection: close\\r\\n\" . \"Content-length: \" . strlen($json_payload) . \"\\r\\n\", 'content'=>$json_payload ) ); $context = stream_context_create($options); $cs_text_api_url = 'https://' . $cs_name . '.cognitiveservices.azure.com/text/analytics/v3.0/languages'; $detection_result = file_get_contents($cs_text_api_url, false, $context); } ?> <!DOCTYPE html> <html lang=\"en\"> <head> <meta charset=\"utf-8\"/> <title>Language detector</title> <script src=\"https://ajax.googleapis.com/ajax/libs/jquery/2.1.3/jquery.min.js\"></script> <script src=\"script.js\"></script> </head> <body> <h3>Language detector</h3> <form action=\"\" method=\"get\"> <input type=\"text\" name=\"text\" value=\"<?php echo $text;?>\"/> <button type=\"submit\">Detect</button> </form> <br/> <?php if (!empty($detection_result)) { $json_result = json_decode($detection_result); $detected_language = $json_result->documents[0]->detectedLanguage->name; $confidence_score = $json_result->documents[0]->detectedLanguage->confidenceScore; if ($confidence_score > 0.9) { echo '<div><strong>I am quite sure this is: ' . $detected_language . '</strong></div><br/>'; } elseif ($confidence_score == 0) { echo '<div><strong>I have no clue - type in some more text</strong></div><br/>'; } elseif ($confidence_score < 0.3) { echo '<div><strong>Here is a wild guess: ' . $detected_language . '</strong></div><br/>'; } else { echo '<div><strong>I could be wrong, but it sounds a bit like: ' . $detected_language . '</strong></div><br/>'; } echo '<span style=\"color:white\">Raw: ' . $detection_result . '</span><br/>'; } ?> </body> </html> You are now ready to test the service. In Closing What language is “Rød grød med fløde”? With this new solution, you should be able to use the AI engine to determine that it is Danish - my native language. It is a well known challenge for foreigners to pronounce, and you can probably find videos of this online. You may also have noticed in the code, that I added the “classic” same font color debug output for convenience. As a bonus challenge, you can try to extend the solution to be able to translate into English and find out what it means. You should find what you need for that here. Alternative Approaches and Advanced Scenarios In this section, I will discuss some alternative approaches and advanced scenarios. Service endpoints Service endpoint is an alternative Azure Networking technology you can use to secure your network traffic. Essentially, you register specific service endpoints like Microsoft.KeyVault on the subnet where traffic originates from - in this case the virtual network integration subnet. With this registration, Azure will append metadata to the traffic towards the specific service to allow the service to restrict which subnet to accept traffic from, and block all other traffic. Unlike private endpoint, it still uses the public IP of the service for routing, and therefore doesn’t need the setup of Azure Private DNS Zones. FAQ Q: Can I apply the same steps to a Function App? You will need a Premium Elastic plan to use virtual network integration with Function Apps. Further, if you would like to also have the storage account that Functions uses for code and state, you will need to initially create it with the storage publicly available. The steps and limitations for that are documented here. ","categories": ["networking"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2021/04/22/Site-with-secure-backend-communication.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Auto-instrumentation Monitoring for Java and Node.js on App Service (Preview)",
+ "excerpt":"We are happy to share that Azure Monitor Application Insights monitoring is now available for Java and Node.js apps on App Service for both Windows and Linux! To try it out, create a new Web App from the Portal and click the Monitoring tab to enable App Insights. If you already have a Java or Node.js app on App Service, then go to Application Insights on the web app menu to turn it on. Keep reading for instructions on how to get started! This integration is currently in technical preview. Auto-instrumentation from Azure Monitor application insights Azure Monitor application insights is a cloud native application monitoring service which enables customers to observe failures, bottlenecks, and usage patterns to improve application performance and reduce mean time to resolution (MTTR). With a few clicks, you can enable monitoring for your Node.js or Java apps, auto-collecting logs, metrics, and distributed traces, eliminating the need for including an SDK in your app. Enabling application insights for your Azure web app will auto-instrument your Java or Node.js application, and you will see the telemetry in Azure Portal no code changes required! Application insights will help you better understand and monitor your applications with features like… Application Map Live Metrics Failure Analysis Get Started New Web App If you do not have a Java or Node.js web app, create a new one from the Azure Portal. Open the Web App create page Select Node.js or Java as your runtime stack (Java SE, Tomcat, and JBoss EAP are all applicable) Enter your resource group, region, and App Service Plan Select the monitoring tab at the top, and select Yes for “Enable Application Insights” Go to Review + Create, review your selections, and click Create! The deployment will create the Web App and Azure Monitor application insights resources. Once the deployment completes, your application telemetry will be visible in the Application Insights resource. Existing Web App If you already have a Node.js or Java web app, navigate to it from the Portal. On the left side, scroll down to the Application Insights menu item and click “Turn on Application Insights”. By default, a new application insights resource of the same name as your Web App will be used. You can choose to use an existing application insights resource, or change the name. Click Apply at the bottom. Your application telemetry will be visible in the Application Insights resource. Azure Monitor application insights support on App Service App Service has supported auto-instrumentation monitoring for other languages and operating systems. As of May 10th, this is the current support matrix for App Insights on App Service: Language Windows Linux ASP.NET ✔️ N/A .NET 2.1, 3.1, 5 ✔️ ❌ Java ✔️ ✔️ Node.js ✔️ ✔️ Python ❌ ❌ Ruby ❌ ❌ PHP ❌ ❌ ✔️ Application insights auto-instrumentation monitoring is supported ❌ Application insights auto-instrumentation monitoring is not currently supported ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2021/05/10/codeless-monitoring-for-java-node.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "App Service Managed Certificate now in General Availability",
+ "excerpt":"App Service Managed Certificate is now in General Availability for both apex domains and sub-domains. This feature allows customers to secure their custom domains on Linux and on Windows with an SSL certificate at no additional cost. This provides developers a zero-cost option to work on their dev, test, and production sites. This certificate offering is a managed experience that allows customers to just set-and-forget as the automatic certificate renewal and the binding update will be handled by App Service. App Service Managed Certificate is not meant to be used as a client certificate and it is only available for customers on multi-tenant App Service Plan of Basic and above (free, shared, and isolated tiers are not supported). App Service Managed Certificate VS App Service Certificate App Service Managed Certificate App Service Certificate Certificate offering Standard certificate Standard and wildcard certificate Certificate offering No cost $69.99/year for standard and $299.99/year for wildcard Apex domain support Yes Yes Sub-domain support Yes Yes Auto-renew Yes; cannot opt out Yes; can opt out during create or anytime afterwards Auto-update SSL binding after renew Yes Yes What to expect post GA? There is an upcoming plan to remove thumbprint information from both portal and API to provide our customers a more managed experience for certificates without having to worry about all the details. Also, App Service Managed Certificate is not meant to be used as a client certificate. ","categories": ["certsdomains"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2021/05/25/App-Service-Managed-Certificate-GA.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "App Service Environment v3 march to GA",
+ "excerpt":"The App Service Environment v3 (ASEv3) has been in preview since November 2020. During this time it was made available across most regions, received numerous small improvements and was generally very well received. Before GA (General Availability) we will be releasing the GA version into preview. After that update completes, you will be able to make new preview ASEv3’s that replace the private endpoint with an address in the ASE subnet. Also before GA, the preview versions that already exist will be upgraded. Upcoming changes The GA version of ASEv3 has a few enhancements that were not available earlier in preview. To be clear, this release is not available at the time of this blog but it is planned to be released soon. Some of the feature improvement highlights include: You can deploy an external VIP ASE. This would be an ASE with a public address for inbound traffic. Maximum ASE instance count is 200. This is the same as ASEv2 where the maximum App Service plan instance count is 100 and that the total number of instances across all App Service plans is 200 You can deploy a zone redundant ASEv3. Scaling times are improved from earlier in the preview Your ASE only requires use of one subnet That leads to the question then on how do you know you are making an ASEv3 that is on the GA version? You can easily tell the difference during the ASEv3 creation flow where you will not be prompted for two subnets anymore. That should be the clearest indicator you are using the newest version. Upgrade of preview ASEv3 instances If you have a preview version of ASEv3 before the upgrade to the GA version, you need to know that the upgrade to the final GA version will: Cause downtime to your ASEv3 Change the inbound address to your ASEv3 The downtime to your ASEv3 happens as we switch from using the private endpoint provisioned with your ASEv3 and redeploy the ASEv3 with an internal load balancer. The use of the load balancer is completely internal to the ASE. This is a one time event and there are no other expected system downtime events. The private endpoint that was originally provisioned with your preview ASEv3 will still be there and should be deleted after the upgrade. With the removal of the private endpoint to your ASEv3, your inbound address will change from the current private endpoint address to an address in your ASE subnet. You will need to update DNS to reflect this. Even if you are using Azure DNS private zones, it will not automatically pick this change up and it must be done manually. After your ASEv3 is upgraded to the load balancer version: Go into your ASE portal page and select the IP addresses UI Change your DNS records that pointed to the private endpoint address to instead point to the new inbound address shown in the portal. To tell if your preview ASEv3 was upgraded to the GA release candidate, go into the ASE portal and look at the IP addresses UI. You will no longer see private endpoint listed for the inbound address. You will see the Virtual IP is set to internal. GA limitations While there are numerous improvements with ASEv3 over earlier versions, there are a few things that are not available at GA that were available in ASEv2. Those items that are not available include: IP based SSL Remote debug FTP SMTP Network Watcher and NSG Flow Upgrade from ASEv2 Upgrade from ASEv2 will come after GA. In the first version of the upgrade you will be able to upgrade an ASEv2 that is either an external VIP ASEv2 or an internal VIP ASEv2 that has a domain suffix of .appserviceenvironment.net. Initially the upgrade capability won’t support internal ASEs with custom domain suffixes nor will it offer the ability initially to upgrade your ASEv2 to being a zone redundant ASEv3. ","categories": ["networking"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2021/05/25/asev3-march-to-ga.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": ".NET 6 Preview on App Service",
+ "excerpt":"We are happy to announce that App Service now supports apps targeting .NET 6 Preview 4 across all public regions and scenarios on both Windows and Linux App Service plans through (App Service Early Access). Azure Functions has also added initial support for .NET 6 Preview. This is the first time that a pre-release stack is publicly available in the platform ahead of GA release and it makes good on our promise to accelerate FX availability made during the .NET 5 GA release announcement. Any app targeting the .NET 6 Early Access on App Service will be automatically updated to the latest .NET 6 Preview releases as they become available all the way up to RC and GA. ","categories": [],
+ "tags": ["dotnet"],
+ "url": "https://azure.github.io/AppService/2021/06/09/Dot-Net-6-Preview-on-App-Service.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Preventing crashes due to DiagnosticMonitorTraceListener",
+ "excerpt":"Azure App Services has the proactive crash monitoring feature, which checks for process crashes and collects diagnostic data that helps you determine the root cause of the crash. After looking at this feature’s telemetry, we identified a common exception that is causing a lot of apps hosted on Azure App Service to crash with this call-stack: HelperMethodFrame System.Diagnostics.TraceUtils.GetRuntimeObject(System.String, System.Type, System.String) System.Diagnostics.TypedElement.BaseGetRuntimeObject() System.Diagnostics.ListenerElement.GetRuntimeObject() System.Diagnostics.ListenerElementsCollection.GetRuntimeObject() System.Diagnostics.TraceInternal.get_Listeners() System.Diagnostics.TraceInternal.WriteLine(System.String) System.Diagnostics.Debug.WriteLine(System.String) Microsoft.Web.Compilation.Snapshots.SnapshotHelper.TakeSnapshotTimerCallback(System.Object) System.Threading.TimerQueueTimer.CallCallbackInContext(System.Object) System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) System.Threading.TimerQueueTimer.CallCallback() System.Threading.TimerQueueTimer.Fire() System.Threading.TimerQueue.FireNextTimers() System.Threading.TimerQueue.AppDomainTimerCallback(Int32) DebuggerU2MCatchHandlerFrame ContextTransitionFrame DebuggerU2MCatchHandlerFrame The underlying exception message is Couldn’t find type for class Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener, Microsoft.WindowsAzure.Diagnostics, Culture=neutral, PublicKeyToken=31bf3856ad364e35 This issue can happen if you have migrated your application from Azure Cloud Services. Azure Cloud services uses the DiagnosticMonitorTraceListener class and this class is designed for cloud services and is not compabtible with Azure App Services. To address this issue, please follow these steps : Remove references to Microsoft.WindowsAzure.Diagnostics.dll from the project. Remove the following section from the application web.config file (if it exists) <system.diagnostics> <trace> <listeners> <add type=\"Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener, Microsoft.WindowsAzure.Diagnostics, Culture=neutral, PublicKeyToken=31bf3856ad364e35\" name=\"AzureDiagnostics\"> <filter type=\"\" /> </add> </listeners> </trace> </system.diagnostics> We hope this information helps in preventing crashes within your application. Happy Debugging ! ","categories": ["Diagnostics"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2021/06/09/Apps-on-App-Services-crash-due-to-DiagnosticMonitorTraceListener.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Azure App Service and Azure Functions on Azure Stack Hub 2021 Q1 Released",
+ "excerpt":"The 2021 Q1 update to Azure App Service on Azure Stack Hub is now available. This release updates the resource provider and brings the following key capabilities and fixes: Updates to App Service Tenant, Admin, Functions portals and Kudu tools. Consistent with Azure Stack Portal SDK version. Updates Azure Functions runtime to v1.0.13154. Updates to core service to improve reliability and error messaging enabling easier diagnosis of common issues. Updates to the following application frameworks and tools: ASP.NET Core 5.0.4 .NET Framework 4.8 NodeJS 14.10.1 Updated Kudu to 90.21106.4900 Updates to underlying operating system of all roles: 2021-06 Cumulative Update for Windows Server 2016 for x64-based Systems (KB5003638) 2021-04 Servicing Stack Update for Windows Server 2016 for x64-based Systems (KB5001402) Defender Definition 1.341.322.0 Cumulative Updates for Windows Server are now applied to Controller roles as part of deployment and upgrade All other fixes and updates are detailed in the App Service on Azure Stack Hub 2021 Q1 Release Notes The App Service on Azure Stack Hub 2021.Q1 build number is 91.0.2.20 Please review the release notes and all known issues prior to updating your installation of Azure App Service on Azure Stack Hub. You can download the new installer and helper scripts: Installer Helper Scripts Please read the updated documentation prior to getting started with deployment: 2020 Q3 Update Release Notes Prerequisites for deploying App Service on Azure Stack Hub Deploy the App Service Resource Provider for new deployments Update the App Service Resource Provider for updating existing deployments ","categories": [],
+ "tags": ["Azure Stack"],
+ "url": "https://azure.github.io/AppService/2021/06/11/App-Service-on-Azure-Stack-Hub-2021-Q1-Update-Released.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Root CA on App Service",
+ "excerpt":"App Service has a list of Trusted Root Certificates which you cannot modify in the multi-tenant variant version of App Service, but you can load your own CA certificate in the Trusted Root Store in an App Service Environment (ASE), which is a single-tenant environment in App Service. (The Free, Basic, Standard, and Premium App Service Plans are all multi-tenant, and the Isolated Plans are single-tenant.) When an app hosted on Azure App Service, tries to connect to a remote endpoint over SSL, it is important that the certificate on remote endpoint service is issued by a Trusted Root CA. If the certificate on the remote service is a self-signed certificate or a private CA certificate, then it will not be trusted by the instance hosting your app and the SSL handshake will fail with this error: \"Could not establish trust relationship for the SSL/TLS secure channel\". In this situtation, there are two solutions: Use a certificate that is issued by one of the Trusted Root Certificate Authorities in App Service on the remote server. How to get a list of Trusted Root CA on App Service using Kudu If the remote service endpoint certificate could not be changed or there is a need to use a private CA certificate, host your app on an App Service Environment (ASE) and load your own CA certificate in the Trusted Root Store How to load your own CA certificate to the Trusted Root Store in ASE How to get a list of Trusted Root CA on App Service using Kudu How to get to Kudu Go to your web app on the Azure portal and look for Development Tools > Advanced Tools and click on “Go ->”. A new tab will open for the Kudu tool. The next steps will depend on if you have a Linux or Windows app. Windows Go to Debug console > Powershell and a Powershell window will appear. Issue the following command in the console: dir cert:\\localmachine\\root Linux Go to SSH and issue the following commands: cd /etc/ssl/certs ls | find *.pem ","categories": ["certsdomains"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2021/06/22/Root-CA-on-App-Service-Guide.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": ".NET 6 Preview 5 on App Service",
+ "excerpt":"In case you missed it, we released support for .NET 6 Preview 4 about 2 weeks ago. Now we have rolled out support for .NET 6 Preview 5 across all public regions and scenarios on both Windows and Linux App Service plans as well as Azure Functions through (App Service Early Access). Any app targeting the .NET 6 Early Access on App Service will be automatically updated to the latest .NET 6 Preview releases as they become available all the way up to RC and GA. If you are creating a new .NET 6 app on App Service today, you will have Preview 5 available on the platform. If your app was created earlier this week, it will be automatically updated to Preview 5 the next time it cold starts. If you want to trigger the update, you just start/stop the app. ","categories": [],
+ "tags": ["dotnet"],
+ "url": "https://azure.github.io/AppService/2021/06/25/Dot-Net-6-Preview-5-on-App-Service.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Deploying Linux custom container from private Azure Container Registry",
+ "excerpt":"Securing access to your site is important, but securing access to the source of your site is often equally important. In this article, I will walk you through setting up a Linux web app with secure, network-isolated access to a container registry. The scenario is intentionally kept simple to focus on the architecture and configuration. This guide is organized into four steps: Create network infrastructure Set up Azure Container Registry Create network integrated web app Pull from private registry In closing, there are sections on advanced scenarios and FAQ. The default scenario for the article is using system-assigned managed identity. An “Alternative scenarios” section with step for using credentials, user-assigned managed identity, and custom registries has been added. Notes: App Service Environment v2 (Isolated SKU) do not support pulling images from a registry url that needs to be resolved using custom DNS servers Getting started This is the third article in a series focusing on network security. If you missed the first two, you can find them here: Deploying a secure, resilient site with a custom domain Deploying a site with secure backend communication This article will also use the Azure CLI executed in bash shell on WSL to set up the environment. It could be done using the Azure portal, Resource Manager templates, or Azure PowerShell. CLI was chosen as I find it easier to follow and explain the individual steps and configurations needed. Remember in the scripts to replace all the resource names that need to be unique. This would be the name of the web app and Azure Container Registry. You may also change location if you want something closer to home. All other changes are optional. Tip: You can search/replace the word “secureacr” with something unique to make all the scripts unique. 1. Create network infrastructure First, set up a Resource Group with a Virtual Network. The virtual network should have at least two subnets: one for the regional virtual network integration and one for the private endpoints. The address-prefix size must be at least /28 for both subnets; small subnets can affect scaling limits and the number of private endpoints. Go with /24 for both subnets if you are not under constraints. az group create --name secureacrsetup --location westcentralus az network vnet create --resource-group secureacrsetup --location westcentralus --name secureacr-vnet --address-prefixes 10.0.0.0/16 For the subnets, there are two settings that we need to pay attention to. This is often set by the portal or scripts, but here it is called out directly. Delegation “Microsoft.Web/serverfarms” informs the subnet that it is reserved for virtual network integration: az network vnet subnet create --resource-group secureacrsetup --vnet-name secureacr-vnet --name vnet-integration-subnet --address-prefixes 10.0.0.0/24 --delegations Microsoft.Web/serverfarms az network vnet subnet create --resource-group secureacrsetup --vnet-name secureacr-vnet --name private-endpoint-subnet --address-prefixes 10.0.1.0/24 The last part of the network infrastructure is the Private DNS Zone. The zone is used to host the DNS records for private endpoint allowing the web app to find the container registry by name. Go here for a primer on Azure Private Endpoints and go here for how DNS Zones fits into private endpoints. Create the Private DNS Zone: az network private-dns zone create --resource-group secureacrsetup --name privatelink.azurecr.io Link the zone to the virtual network: az network private-dns link vnet create --resource-group secureacrsetup --name acr-zonelink --zone-name privatelink.azurecr.io --virtual-network secureacr-vnet --registration-enabled false … and now the core network setup is done. 2. Set up Azure Container Registry In this section, we will set up the Azure Container Registry account. We will also create the private endpoint and configure the service to block public traffic. First create the service. We need Premium SKU to enable private endpoint: az acr create --resource-group secureacrsetup --name secureacr2021 --location westcentralus --sku Premium Before we lock the registry down, let’s push a few images to it for testing. After you lock it down, you might get a conflict with the ACR firewall. If you are using docker locally, you will need to allow your local IP. If you are running the build from somewhere else, this location will also need access to the registry. I will create a simple static html site, add it to an nginx container, and use ACR Tasks to build the container. You can of course also use native docker commands on your local machine: mkdir source cd source echo -e 'FROM nginx\\nCOPY index.html /usr/share/nginx/html' > Dockerfile echo '<html><head><title>Private ACR v1</title><link rel=\"shortcut icon\" href=\"https://appservice.azureedge.net/images/app-service/v4/favicon.ico\" type=\"image/x-icon\"/></head><body bgcolor=lightblue><h1>Hello Linux v1 from private Azure Container Registry</h1></body></html>' > index.html az acr build --registry secureacr2021 --platform Linux --image privatewebsite:lnx-v1 . echo '<html><head><title>Private ACR v2</title><link rel=\"shortcut icon\" href=\"https://appservice.azureedge.net/images/app-service/v4/favicon.ico\" type=\"image/x-icon\"/></head><body bgcolor=lightgreen><h1>Hello Linux v2 from private Azure Container Registry</h1></body></html>' > index.html az acr build --registry secureacr2021 --platform Linux --image privatewebsite:lnx-v2 . Next, let’s create the private endpoints to connect the backend services to the virtual network. Get the Resource ID of the registry and store it in a variable: acr_resource_id=$(az acr show --name secureacr2021 --query id --output tsv) Create the private endpoint: az network private-endpoint create --resource-group secureacrsetup --name secureacr-pe --location westcentralus --connection-name secureacr-pc --private-connection-resource-id $acr_resource_id --group-id registry --vnet-name secureacr-vnet --subnet private-endpoint-subnet … and create a DNS Zone Group. This will create the DNS record for the private endpoint in the DNS Zone (and remove it if the private endpoint is deleted): az network private-endpoint dns-zone-group create --resource-group secureacrsetup --endpoint-name secureacr-pe --name secureacr-zg --private-dns-zone privatelink.azurecr.io --zone-name privatelink.azurecr.io az acr update --resource-group secureacrsetup --name secureacr2021 --public-network-enabled false Everything is locked down now and you cannot even get to the ACR repositories through the Azure portal. In the ACR Networking section in Azure portal, you can add the public IP of your client if you need to view the registries (images) and other IPs needed to to push an image from remote clients. This will allow your local machine to access the registry: my_ip=$(curl https://ifconfig.me) az acr update --resource-group secureacrsetup --name secureacr2021 --public-network-enabled --default-action Deny az acr network-rule add --resource-group secureacrsetup --name secureacr2021 --ip-address $my_ip 3. Create the network integrated web app Now we get to creating the actual web app. To use virtual network integration, we need at least the Basic SKU, and then there are a few commands to secure the app and add the integration: az appservice plan create --resource-group secureacrsetup --name secureacrplan --sku P1V3 --is-linux az webapp create --resource-group secureacrsetup --plan secureacrplan --name secureacrweb2021 --https-only --deployment-container-image-name 'mcr.microsoft.com/appsvc/staticsite:latest' az webapp vnet-integration add --resource-group secureacrsetup --name secureacrweb2021 --vnet secureacr-vnet --subnet vnet-integration-subnet As the last configuration step, we will assign a managed identity to the web app and grant the app access to pull images from the registry. az webapp identity assign --resource-group secureacrsetup --name secureacrweb2021 --scope $acr_resource_id --role AcrPull You can now browse to the web app and outbound traffic from the web app will be routed through the virtual network. 4. Pull from private registry All the infrastructure is now in place and we just need to glue it all together. The web app needs some configuration values from the registry. Images will by default be pulled over public route, but by setting vnetImagePullEnabled site property to true, you tell the platform to use the virtual network integration for pulling the image: az resource update --resource-group secureacrsetup --name secureacrweb2021 --set properties.vnetImagePullEnabled=true --resource-type 'Microsoft.Web/sites' Configure the container image and set image pull to use managed identity: az webapp config set --resource-group secureacrsetup --name secureacrweb2021 --linux-fx-version 'DOCKER|secureacr2021.azurecr.io/privatewebsite:lnx-v1' az resource update --resource-group secureacrsetup --name secureacrweb2021/config/web --set properties.acrUseManagedIdentityCreds=true --resource-type 'Microsoft.Web/sites/config' Note: The app might attempt to pull the image before the configuration is complete which will show up as failed attempts in the logs. Give it a minute or two and the pull will retry with the correct configuration. Advanced scenarios Using user-assigned managed identity System-assigned managed identity is convenient as you do not have any additional resources to manage and it is uniquely associated with your web app. However, there are scenarios where user-assigned managed identity is preferred. It can be configured ahead of the web app and assigning permissions can be delegated. You can also reuse the same managed identity across multiple web apps. Create a user-assigned managed identity and assign permissions to pull from ACR: az identity create --resource-group secureacrsetup --name secureacr-identity identity_principal_id=$(az identity show --resource-group secureacrsetup --name secureacr-identity --query principalId --output tsv) az role assignment create --role \"AcrPull\" --assignee-object-id $identity_principal_id --scope $acr_resource_id --assignee-principal-type ServicePrincipal Assign the identity to the web app: identity_resource_id=$(az identity show --resource-group secureacrsetup --name secureacr-identity --query id --output tsv) az webapp identity assign --resource-group secureacrsetup --name secureacrweb2021 --identities $identity_resource_id Configure the web app to pull the image using the user-assigned managed identity: identity_client_id=$(az identity show --resource-group secureacrsetup --name secureacr-identity --query clientId --output tsv) az resource update --resource-group secureacrsetup --name secureacrweb2021/config/web --set properties.acrUserManagedIdentityID=$identity_client_id --resource-type 'Microsoft.Web/sites/config' az resource update --resource-group secureacrsetup --name secureacrweb2021/config/web --set properties.acrUseManagedIdentityCreds=true --resource-type 'Microsoft.Web/sites/config' az webapp config set --resource-group secureacrsetup --name secureacrweb2021 --linux-fx-version 'DOCKER|secureacr2021.azurecr.io/privatewebsite:lnx-v2' Using credentials to pull images Instead of using managed identity, you can use admin credentials or an Azure AD Service Principal. These values can optionally be stored in Key Vault and configured as Key Vault referenced app settings. Configure ACR to enable admin credentials: az acr update --resource-group secureacrsetup --name secureacr2021 --admin-enabled Set the registry credentials and disable using managed identity (remember to ensure the vnetImagePullEnabled is configured if you want to pull the image over the virtual network integration). acr_server_url=\"https://$(az acr show --name secureacr2021 --query loginServer --output tsv)\" acr_username=$(az acr credential show --name secureacr2021 --query username --output tsv) acr_password=$(az acr credential show --name secureacr2021 --query passwords[0].value --output tsv) az webapp config appsettings set --resource-group secureacrsetup --name secureacrweb2021 --settings DOCKER_REGISTRY_SERVER_URL=$acr_server_url DOCKER_REGISTRY_SERVER_USERNAME=$acr_username DOCKER_REGISTRY_SERVER_PASSWORD=$acr_password az resource update --resource-group secureacrsetup --name secureacrweb2021/config/web --set properties.acrUseManagedIdentityCreds=false --resource-type 'Microsoft.Web/sites/config' az webapp config set --resource-group secureacrsetup --name secureacrweb2021 --linux-fx-version 'DOCKER|secureacr2021.azurecr.io/privatewebsite:lnx-v1' Using a custom private registry App Service also support pulling from a custom private registry using the v2 API. If you are using a custom private registry such as Docker Registry, there are no specific changes you need to make except ensure that the registry is reachable and DNS resolvable from the integration virtual network. Setting up a custom private registry depends on the chosen product and platform. A simple test configuration can be setup using App Service to actually host the registry and protect it with a private endpoint. Other apps can then pull from this registry. To set up a custom private registry in the existing setup: az webapp create --resource-group secureacrsetup --plan secureacrplan --name secureacrwebregistry2021 --https-only --deployment-container-image-name 'registry:2' Push a few images to the registry using the docker client: echo -e 'FROM nginx\\nCOPY index.html /usr/share/nginx/html' > Dockerfile echo '<html><head><title>Custom registry v1</title><link rel=\"shortcut icon\" href=\"https://appservice.azureedge.net/images/app-service/v4/favicon.ico\" type=\"image/x-icon\"/></head><body bgcolor=lightblue><h1>Hello Linux v1 from custom registry</h1></body></html>' > index.html docker build -t customwebsite:lnx-v1 . docker tag customwebsite:lnx-v1 secureacrwebregistry2021.azurewebsites.net/customwebsite:lnx-v1 docker push secureacrwebregistry2021.azurewebsites.net/customwebsite:lnx-v1 echo '<html><head><title>Custom registry v2</title><link rel=\"shortcut icon\" href=\"https://appservice.azureedge.net/images/app-service/v4/favicon.ico\" type=\"image/x-icon\"/></head><body bgcolor=lightblue><h1>Hello Linux v2 from custom registry</h1></body></html>' > index.html docker build -t customwebsite:lnx-v2 . docker tag customwebsite:lnx-v2 secureacrwebregistry2021.azurewebsites.net/customwebsite:lnx-v2 docker push secureacrwebregistry2021.azurewebsites.net/customwebsite:lnx-v2 Secure the registry with a private endpoint and add a private DNS zone to ensure DNS resolution is working: az network private-dns zone create --resource-group secureacrsetup --name privatelink.azurewebsites.net az network private-dns link vnet create --resource-group secureacrsetup --name websites-zonelink --zone-name privatelink.azurewebsites.net --virtual-network secureacr-vnet --registration-enabled false webregistry_resource_id=$(az webapp show --resource-group secureacrsetup --name secureacrwebregistry2021 --query id --output tsv) az network private-endpoint create --resource-group secureacrsetup --name securewebregistry-pe --location westcentralus --connection-name securewebregistry-pc --private-connection-resource-id $webregistry_resource_id --group-id sites --vnet-name secureacr-vnet --subnet private-endpoint-subnet az network private-endpoint dns-zone-group create --resource-group secureacrsetup --endpoint-name securewebregistry-pe --name securewebregistry-zg --private-dns-zone privatelink.azurewebsites.net --zone-name privatelink.azurewebsites.net Finally, disable using managed identity and update the image the app is using: az resource update --resource-group secureacrsetup --name secureacrweb2021/config/web --set properties.acrUseManagedIdentityCreds=false --resource-type 'Microsoft.Web/sites/config' az webapp config set --resource-group secureacrsetup --name secureacrweb2021 --linux-fx-version 'DOCKER|secureacrwebregistry2021.azurewebsites.net/customwebsite:lnx-v1' After about a minute, you should see the new image served from the web app. Deploy from secure registry with ARM template using credentials In this scenario, you will deploy an app with an ARM template from a registry that uses credentials (username/password) for authentication. If you are using ACR, you can use either Admin credentials or a Service Principal. Pulling over virtual network is optional, but if you are using Azure Container Registry with private endpoint, you will have to pull over virtual network. The template also assumes the App Service plan and the virtual network exist. If not, you can add this to the template as well. { \"$schema\": \"https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#\", \"contentVersion\": \"1.0.0.0\", \"parameters\": { \"webAppName\": { \"defaultValue\": \"secureacrweb2021\", \"type\": \"string\" } }, \"variables\": { \"appServicePlanName\": \"secureacrplan\", \"virtualNetworkName\": \"secureacr-vnet\", \"subnetName\": \"vnet-integration-subnet\", \"location\": \"westcentralus\", \"webAppName\": \"[parameters('webAppName')]\" }, \"resources\": [ { \"name\": \"[variables('webAppName')]\", \"type\": \"Microsoft.Web/sites\", \"apiVersion\": \"2021-02-01\", \"location\": \"[variables('location')]\", \"properties\": { \"serverFarmId\": \"[resourceId('Microsoft.Web/serverfarms', variables('appServicePlanName'))]\", \"virtualNetworkSubnetId\": \"[resourceId('Microsoft.Network/virtualNetworks/subnets', variables('virtualNetworkName'), variables('subnetName'))]\", \"vnetImagePullEnabled\": true, \"siteConfig\": { \"linuxFxVersion\": \"DOCKER|secureacr2021.azurecr.io/privatewebsite:lnx-v1\", \"appSettings\": [ { \"name\":\"DOCKER_REGISTRY_SERVER_USERNAME\", \"value\": \"secureacr2021\" }, { \"name\":\"DOCKER_REGISTRY_SERVER_PASSWORD\", \"value\": \"[INSERT_REGISTRY_PASSWORD]\" } ] }, \"httpsOnly\": true } } ] } Deploy from secure registry with ARM template using managed identity As an alternative to using credentials, you can use Managed Identity when pulling images from Azure Container Registry. Pulling over virtual network is again optional and is configured using the vnetImagePullEnabled site config, but is of course required if your registry is only visible from the virtual network. Since we need to grant the permissions ahead of creating the app, only User-Assigned Managed Identity will work, and you have to grant the identity AcrPull permissions on the registry. See the section on using user-managed identity. Even though the managed identity exists when deploying the template, the resource must be in the template to use the reference method to fetch the clientId. You can work around this by inserting the clientId manually. { \"$schema\": \"https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#\", \"contentVersion\": \"1.0.0.0\", \"parameters\": { \"webAppName\": { \"defaultValue\": \"secureacrweb2021\", \"type\": \"string\" } }, \"variables\": { \"appServicePlanName\": \"secureacrplan\", \"virtualNetworkName\": \"secureacr-vnet\", \"subnetName\": \"vnet-integration-subnet\", \"userAssignedIdentityName\": \"secureacr-identity\", \"location\": \"westcentralus\", \"webAppName\": \"[parameters('webAppName')]\" }, \"resources\": [ { \"type\": \"Microsoft.ManagedIdentity/userAssignedIdentities\", \"name\": \"[variables('userAssignedIdentityName')]\", \"apiVersion\": \"2018-11-30\", \"location\": \"[variables('location')]\" }, { \"name\": \"[variables('webAppName')]\", \"type\": \"Microsoft.Web/sites\", \"apiVersion\": \"2021-02-01\", \"location\": \"[variables('location')]\", \"dependsOn\": [ \"[resourceId('Microsoft.ManagedIdentity/userAssignedIdentities', variables('userAssignedIdentityName'))]\" ], \"properties\": { \"serverFarmId\": \"[resourceId('Microsoft.Web/serverfarms', variables('appServicePlanName'))]\", \"virtualNetworkSubnetId\": \"[resourceId('Microsoft.Network/virtualNetworks/subnets', variables('virtualNetworkName'), variables('subnetName'))]\", \"siteConfig\": { \"acrUseManagedIdentityCreds\": true, \"acrUserManagedIdentityID\": \"[reference(resourceId('Microsoft.ManagedIdentity/userAssignedIdentities', variables('userAssignedIdentityName'))).clientId]\", \"linuxFxVersion\": \"DOCKER|secureacr2021.azurecr.io/privatewebsite:lnx-v2\" }, \"vnetImagePullEnabled\": true, \"httpsOnly\": true }, \"identity\": { \"type\": \"UserAssigned\", \"userAssignedIdentities\": { \"[resourceId('Microsoft.ManagedIdentity/userAssignedIdentities', variables('userAssignedIdentityName'))]\": {} } } } ] } FAQ Q: Can I apply the same steps to a Function app? Yes, but you will need a Premium Elastic plan or an App Service plan to use virtual network integration with Function apps. Q: Can I apply the same steps to a Windows container app? Windows container apps do not yet support pulling containers over virtual network, but you can use managed identity to pull from Azure Container Registry and you can pull from custom registries that are accessible from the internet. ","categories": ["networking"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2021/07/03/Linux-container-from-ACR-with-private-endpoint.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "How to create a Blazor WebAssembly gRPC-Web app using App Service on an Azure Arc Enabled Kubernetes Cluster",
+ "excerpt":"With the release of the App Service on Kubernetes preview, you can now run App Service on Kubernetes deploying your web apps to Azure Kubernetes Service, or the cluster of your choosing. This enables you to utilize App Service features including continuous deployment with GitHub Actions and deployment slots. In this tutorial, we’ll be deploying a .NET 5 gRPC-Web app to a Custom Location (App Service deployed on an Arc-enabled AKS cluster) with App Service on Kubernetes using the same gRPC-Web app we created in this blog. This example assumes you already have your resource group, connected Arc cluster, custom location, and App Service Kubernetes environment setup. Follow the steps in the documentation if you do not have these resources created. Creating your Web App Creating your web app resource in the Azure portal should look very familiar to what you’ve seen before. When selecting your Resource Group, make sure it is the resource group you’ve created with all of your Azure Arc resources in them. Once the correct resource group is selected, as well as the operating system (Linux) you will find your Arc custom location in the Region drop-down menu. If you would like to use the CLI to create your App Service resource, please see the documentation. To create your web app using the portal: Choose the Subscription where the Resource Group lives containing your Azure Arc resources Choose the correct Resource Group that contains your Azure Arc resources (cluster, custom location, Kube environment, etc.) Give your site a unique Name Choose .NET 5 for your Runtime stack The Operating System will need to be Linux since App Service on Kubernetes is currently Linux only. Go to the Region drop down menu and choose your custom location under Custom Locations (Preview). You may notice when you choose your custom location, the appended domain under the Name option is updated to include your Kube environment name and Arc region. Where you typically would see azurewebsites.net, you now see k4apps.io. Keep in mind the custom location is the abstracted layer on top of your Azure Arc enabled cluster that enables you to use Azure services. Next, click Review + create to create your resource. Once your resource is created, you can view that it is deployed to your custom location by visiting the custom location resource. Deploy your application Once your web app resource is created you can use the Zip Deploy method to push your application code to your web app. Using the command line, navigate to the publish files. These will be the publish files in your Server project. The path should look similar to this: BlazorGrpcWebApp/Server/bin/Release/net5.0/publish Select all of the files in the publish directory using ctl+a, then Right-click, navigate to Send to, select Compressed (zipped) folder. Name the file blazorgrpcwebapp.zip and save it. This will create the .zip file that you will use in the next step. Using the command line, navigate to the directory including the blazorgrpcwebapp.zip file you just created and run the following command az webapp deployment source config-zip --resource-group my-resource-group --name my-arc-app --src blazorgrpcwebapp.zip This command will publish your code to the web app and you’ll be able to re-visit your resource my-arc-app and select Browse to view your application in the browser. Notice your URL is appended with the .k4app.io domain. This deployment may take a few minutes so you may see the default deployment screen while you wait. Once it’s complete you can view the application and verify that grpc-web calls are still being made. Resources Set up an Azure Arc Enabled Kubernetes cluster to run App Service, Functions, and Logic Apps (Preview) How to use gRPC-Web with Blazor WebAssembly on App Service Deploy ZIP file with Azure CLI App Service on Kubernetes ","categories": [],
+ "tags": ["dotnet","kubernetes"],
+ "url": "https://azure.github.io/AppService/2021/07/08/How-to-create-a-blazor-webassembly-grpc-web-app-using-app-service-on-an-azure-arc-enabled-kubernetes-cluster.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "General Availability of new Azure App Service built-in policies",
+ "excerpt":"One of the tools that Azure provides to enforce governance and controls is Azure Policies. By employing Azure policies, IT organizations are able to enforce controls around provisioning Azure resources to ensure adherence to security and compliance standards. Along with the ability to allow users to create custom Azure policies, Azure platform provides built-in policies around the use of each Azure service which can be employed as it is or could be further customized based on the requirements. App Service provides many such built-in policies which help secure applications and promote best practices. In recent days, new built-in policies have been released which could be used to improve the security posture of the apps deployed and also help streamline the deployment standards. Some of these policies with Audit or AuditIfNotExists effect result in creation of audit records for all applications that do not comply with the controls and others with DeployIfNotExists results in execution of remediation tasks that makes changes to the configuration of the application to implement the desired controls. Policies with Deny effect cause a create or update request to fail if that request results in creation or update of an application that does not match the defined standards. Following table lists the new built-in policies categorized by the area of control that they address : Area of Concern Policy Effect Application SKU Network Security App Service should disable public network access AuditIfNotExists, Disabled All except IsolatedV1 & IsolatedV2 Network Security Configure App Service to disable public network access DeployIfNotExists, Disabled All except IsolatedV1 & IsolatedV2 Network Security App Service Environment apps should not be reachable over public internet AuditIfNotExists, Disabled IsolatedV1, IsolatedV2 Network Routing App Service should use private link AuditIfNotExists, Disabled PremiumV2, PremiumV3, Functions Premium Network Routing App Service apps should use a SKU that supports private link AuditIfNotExists, Deny, Disabled PremiumV2, PremiumV3, Functions Premium Network Routing Configure App Service to use private DNS zones DeployIfNotExists, Disabled PremiumV2, PremiumV3, Functions Premium Network Routing App Service apps should enable outbound non-RFC 1918 traffic to Azure Virtual Network AuditIfNotExists, Disabled All except IsolatedV1 & IsolatedV2 Application Security App Service Environment should enable internal encryption Audit, Disabled IsolatedV1, IsolatedV2 Application Security App Service Environment should disable TLS 1.0 and 1.1 Audit, Disabled IsolatedV1, IsolatedV2 Application Security App Service Environment should be configured with strongest TLS Cipher Suites Audit, Disabled IsolatedV1, IsolatedV2 Service Governance App Service Environment should be provisioned with latest versions Audit, Disabled IsolatedV1, IsolatedV2 Network Security App Service should disable public network access Internal user facing applications should ensure that they are not accessible over public internet. Disabling inbound public network access improves security by ensuring that the app isn’t exposed on public internet. For applications deployed in the multi-tenant App Service, use this policy to flag all applications that are accessible over public network. If the organization mandates that applications should not be accessible over public internet, one could use “Configure App Service to disable public network access” policy to automatically disable the inbound public network access following the policy run. App Service Environment apps should not be reachable over public internet Applications deployed in App Service Environment where the access from public internet is not desired, should be deployed in a private IP address inside the VNET. The internal endpoint is an internal load balancer. This policy could be used to audit applications that violate this control and are accessible over public internet. Network Routing App Service should use private link To ensure that applications deployed in multi-tenant app service are only accessible privately on a non-public route, one should create private link to provide private access to them. This could be done by creating a private link to the apps deployed in App Service, as described here. Policy “App Service should use private link” creates an audit record for all apps that do not provide private link. These records can then be used to identify such applications to determine if a corrective action is required. App Service apps should use a SKU that supports private link To ensure private access to applications deployed in multi-tenant app service, one requires to provision a private link to the application. Not all App Service SKUs support private link. Private Link is supported only on the following App Service Plans : PremiumV2, PremiumV3, Functions Premium (sometimes referred to as the Elastic Premium plan). This policy provides ability to audit or deny deployment of applications on App Service Plans that do not support private link. Configure App Service to use private DNS zones On the creation of a private endpoint to a webapp, a DNS entry is required to be created to resolve the name of private endpoint IP address to the fully qualified domain name(FQDN) of the connection string. The network interface associated with the private endpoint contains information to configure DNS, that is FQDN and private IP address to the private link resource i.e. the app. It is recommended to setup a private DNS zone to override the DNS resolution for a private endpoint. A private DNS zone can be linked to the one’s virtual network to resolve specific domains. Policy “Configure App Service to use private DNS zones” automatically configures apps accessible over private endpoints to use a private DNS zone. App Service apps should enable outbound non-RFC 1918 traffic to Azure Virtual Network App Service provides a feature called Regional VNet Integration to enable apps deployed in multi-tenant service to access resources in or through a VNET. The feature allows application routing to be controlled at the individual app level. When Route All is not enabled, the app only routes RFC1918 traffic into VNet. Enabling Route All allows NSGs and UDRs to be used for all outbound traffic from the App Service app. Steps to set up that setting are described here. Policy “App Service apps should enable outbound non-RFC 1918 traffic to Azure Virtual Network” creates an audit record and thus helps identify applications that don’t have Route All enabled. Application Security App Service Environment should enable internal encryption By default, to enable higher throughput, internal components of App Service Environment do not use encryption while communicating among themselves. If one has a compliance requirement that requires complete encryption of the end to end data path, encryption could be enabled by setting a custom setting. Policy “App Service Environment should enable internal encryption” creates an audit record for all App Service Environments that do not use internal encryption. App Service Environment should disable TLS 1.0 and 1.1 TLS 1.0 and 1.1 are out-of-date protocols that do not support modern cryptographic algorithms and thus are deemed vulnerable to attacks. To disable TLS 1.0 and 1.1 for all the apps in an ASE, one could set custom setting on the ASE as described here. Policy “App Service Environment should disable TLS 1.0 and 1.1” help identify and create a record for all ASEs that have TLS 1.0 and 1.1 enabled. App Service Environment should be configured with strongest TLS Cipher Suites By default, ASE supports changing the TLS cipher suite by using custom setting as defined here. Changing the cipher suite affects an entire App Service Environment. For ASE to function, there are two cipher suites required; TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, and TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. Default setting for ASE also has weaker ciphers included in the suite, if you wish to operate your ASE with the strongest and most minimal set of cipher suites, then one should use just the two required ciphers. “App Service Environment should be configured with strongest TLS Cipher Suites” creates an audit record for all those ASEs which do not use these required cipher suites or use cipher suites other than just these two. Service Governance App Service Environment should be provisioned with latest versions Older version of App Service Environment requires manual management of Azure’s resources and have greater scaling limitations. It is recommended that one uses ASEv2 or ASEv3(in preview) while creating new App Service Environment. This policy identifies all App Service Environments that are ASEv1. ","categories": ["networking"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2021/07/12/General-Availability-of-new-azure-built-in-policies.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Quickstart: Intro to Bicep with Web App and DB",
+ "excerpt":"Get started with Azure App Service by deploying an app to the cloud using a Bicep file and Azure CLI in Cloud Shell. Because you use a free App Service tier, you incur no costs to complete this quickstart. Bicep is a domain-specific language (DSL) that uses declarative syntax to deploy Azure resources. It provides concise syntax, reliable type safety, and support for code reuse. You can use Bicep instead of JSON to develop your Azure Resource Manager templates (ARM templates). The JSON syntax to create an ARM template can be verbose and require complicated expressions. Bicep syntax reduces that complexity and improves the development experience. Bicep is a transparent abstraction over ARM template JSON and doesn’t lose any of the JSON template capabilities. During deployment, the Bicep CLI transpiles a Bicep file into ARM template JSON. Prerequisites If you don’t have an Azure subscription, create a free account before you begin. In order to effectively create resources with Bicep, you will need to install Bicep. The Bicep extension for Visual Studio Code provides language support and resource autocompletion. The extension helps you create and validate Bicep files and is recommended for those that will continue to create resources using Bicep upon completing this quickstart. Review the template The template used in this quickstart is shown below. It deploys an App Service plan, an App Service app on Linux, and a sample Node.js “Hello World” app from the Azure Samples repo. param webAppName string = uniqueString(resourceGroup().id) // Generate unique String for web app name param sku string = 'P1V2' // The SKU of App Service Plan param linuxFxVersion string = 'node|14-lts' // The runtime stack of web app param location string = resourceGroup().location // Location for all resources param repositoryUrl string = 'https://github.com/Azure-Samples/nodejs-docs-hello-world' param branch string = 'master' var appServicePlanName = toLower('AppServicePlan-${webAppName}') var webSiteName = toLower('wapp-${webAppName}') resource appServicePlan 'Microsoft.Web/serverfarms@2020-06-01' = { name: appServicePlanName location: location properties: { reserved: true } sku: { name: sku } kind: 'linux' } resource appService 'Microsoft.Web/sites@2020-06-01' = { name: webSiteName location: location properties: { serverFarmId: appServicePlan.id siteConfig: { linuxFxVersion: linuxFxVersion } } } resource srcControls 'Microsoft.Web/sites/sourcecontrols@2021-01-01' = { name: '${appService.name}/web' properties: { repoUrl: repositoryUrl branch: branch isManualIntegration: true } } Three Azure resources are defined in the template: Microsoft.Web/serverfarms: create an App Service plan. Microsoft.Web/sites: create an App Service app. Microsoft.Web/sites/sourcecontrols: create an external git deployment configuration. This template contains several parameters that are predefined for your convenience. See the table below for parameter defaults and their descriptions: Parameters Type Default value Description webAppName string “webApp-<uniqueString>” App name location string “resourceGroup().location” App region sku string “P1V2” Instance size linuxFxVersion string “NODE|14-LTS” A two-part string defining the runtime and version: “language|Version” repositoryUrl string “https://github.com/Azure-Samples/nodejs-docs-hello-world” External Git repo (optional) branch string “master” Default branch for code sample Deploy the template Copy and paste the template to your preferred editor/IDE and save the file to your local working directory. Azure CLI is used here to deploy the template. You can also use the Azure portal, Azure PowerShell, or REST API. To learn other deployment methods, see Bicep Deployment Commands. The following code creates a resource group, an App Service plan, and a web app. A default resource group, App Service plan, and location have been set for you. Replace <app-name> with a globally unique app name (valid characters are a-z, 0-9, and -). Open up a terminal where the Azure CLI has been installed and run the code below to create a Node.js app on Linux. az group create --name myResourceGroup --location \"southcentralus\" && az deployment group create --resource-group myResourceGroup --template-file <path-to-template> To deploy a different language stack, update linuxFxVersion with appropriate values. Samples are shown below. To show current versions, run the following command in the Cloud Shell: az webapp config show --resource-group myResourceGroup --name <app-name> --query linuxFxVersion Language Example .NET linuxFxVersion=”DOTNETCORE|3.0” PHP linuxFxVersion=”PHP|7.4” Node.js linuxFxVersion=”NODE|10.15” Java linuxFxVersion=”JAVA|1.8|TOMCAT|9.0” Python linuxFxVersion=”PYTHON|3.7” Ruby linuxFxVersion=”RUBY|2.6” Validate the deployment Browse to http://<app_name>.azurewebsites.net/ and verify it’s been created. Clean up resources When no longer needed, delete the resource group. Optional additional sample apps If you would like to continue learning about Bicep and App Service, below are additional samples you can review and deploy following the same process described above. Note that if you did not already delete the previously created resources, updating your existing template and redeploying will update the current app. Optionally, you can start from scratch and create new resources for the next part of this quickstart. Webapp with CosmosDB @description('Application Name') @maxLength(30) param applicationName string = 'to-do-app${uniqueString(resourceGroup().id)}' @description('Location for all resources.') param location string = resourceGroup().location @description('App Service Plan\\'s pricing tier. Details at https://azure.microsoft.com/en-us/pricing/details/app-service/') param appServicePlanTier string = 'P1V2' @minValue(1) @maxValue(3) @description('App Service Plan\\'s instance count') param appServicePlanInstances int = 1 @description('The URL for the GitHub repository that contains the project to deploy.') param repositoryUrl string = 'https://github.com/Azure-Samples/cosmos-dotnet-core-todo-app.git' @description('The branch of the GitHub repository to use.') param branch string = 'main' @description('The Cosmos DB database name.') param databaseName string = 'Tasks' @description('The Cosmos DB container name.') param containerName string = 'Items' var cosmosAccountName = toLower(applicationName) var websiteName = applicationName var appServicePlanName = applicationName resource cosmosAccount 'Microsoft.DocumentDB/databaseAccounts@2021-04-15' = { name: cosmosAccountName kind: 'GlobalDocumentDB' location: location properties: { consistencyPolicy: { defaultConsistencyLevel: 'Session' } locations: [ { locationName: location failoverPriority: 0 isZoneRedundant: false } ] databaseAccountOfferType: 'Standard' } } resource appServicePlan 'Microsoft.Web/serverfarms@2021-01-01' = { name: appServicePlanName location: location sku: { name: appServicePlanTier capacity: appServicePlanInstances } kind: 'linux' } resource appService 'Microsoft.Web/sites@2021-01-01' = { name: websiteName location: location properties: { serverFarmId: appServicePlan.id httpsOnly: true siteConfig: { http20Enabled: true appSettings: [ { name: 'CosmosDb:Account' value: cosmosAccount.properties.documentEndpoint } { name: 'CosmosDb:Key' value: listKeys(cosmosAccount.id, cosmosAccount.apiVersion).primaryMasterKey } { name: 'CosmosDb:DatabaseName' value: databaseName } { name: 'CosmosDb:ContainerName' value: containerName } ] } } } resource srcControls 'Microsoft.Web/sites/sourcecontrols@2021-01-01' = { name: '${appService.name}/web' properties: { repoUrl: repositoryUrl branch: branch isManualIntegration: true } } This app uses Microsoft Azure Cosmos DB service to store and access data from an ASP.NET Core MVC application hosted on Azure App Service. More details for this app can be found here. Most of the parameters and resources are the same, but you now additionally have resources for the Cosmos DB account and you set the app settings as part of the “sites” (web app) resource. Webapp with custom DNS name with a TLS/SSL binding If you would like to continue with this app by adding a SSL binding and a custom domain, the sample bicep files will be given below. Please note that you will need to purchase a custom domain and input the relevant info into the dnsZone parameter of the template. For more information about custom domains and SSL bindings, please see Secure a custom DNS name with a TLS/SSL binding in Azure App Service. In order to complete this sample, you will need to modify the above file or create a new Bicep file as well as create an additional Bicep file in the same directory for sni enablement. This is due to an ARM limitation that forbids using resources with this same type-name combination twice in one deployment. Create another bicep file named sni-enable.bicep in the same directory with the contents below. param webAppName string param webAppHostname string param certificateThumbprint string resource webAppCustomHostEnable 'Microsoft.Web/sites/hostNameBindings@2020-06-01' = { name: '${webAppName}/${webAppHostname}' properties: { sslState: 'SniEnabled' thumbprint: certificateThumbprint } } The following highlight the changes to the webapp-cosmosdb file for reference. Making these updates to your existing file will update your existing deployment if you did not already delete your app. Add a parameter for dnsZone where you input your custom domain (i.e. “customdomain.com”) Add a Microsoft.Network/dnsZones/TXT resource Add a Microsoft.Network/dnsZones/CNAME resource Add a Microsoft.Web/sites/hostNameBindings resource Add a Microsoft.Web/certificates resource Chain the sni-enable module you created earlier The file should end up like the below. @description('Application Name') @maxLength(30) param applicationName string = 'to-do-app${uniqueString(resourceGroup().id)}' @description('Location for all resources.') param location string = resourceGroup().location @description('App Service Plan\\'s pricing tier. Details at https://azure.microsoft.com/en-us/pricing/details/app-service/') param appServicePlanTier string = 'P1V2' @minValue(1) @maxValue(3) @description('App Service Plan\\'s instance count') param appServicePlanInstances int = 1 @description('The URL for the GitHub repository that contains the project to deploy.') param repositoryUrl string = 'https://github.com/Azure-Samples/cosmos-dotnet-core-todo-app.git' @description('The branch of the GitHub repository to use.') param branch string = 'main' @description('Existing Azure DNS zone in target resource group') param dnsZone string = '<YOUR CUSTOM DOMAIN i.e. \"customdomain.com\">' @description('The Cosmos DB database name.') param databaseName string = 'Tasks' @description('The Cosmos DB container name.') param containerName string = 'Items' var cosmosAccountName = toLower(applicationName) var websiteName = applicationName var appServicePlanName = applicationName resource cosmosAccount 'Microsoft.DocumentDB/databaseAccounts@2021-04-15' = { name: cosmosAccountName kind: 'GlobalDocumentDB' location: location properties: { consistencyPolicy: { defaultConsistencyLevel: 'Session' } locations: [ { locationName: location failoverPriority: 0 isZoneRedundant: false } ] databaseAccountOfferType: 'Standard' } } resource appServicePlan 'Microsoft.Web/serverfarms@2021-01-01' = { name: appServicePlanName location: location sku: { name: appServicePlanTier capacity: appServicePlanInstances } kind: 'linux' } resource appService 'Microsoft.Web/sites@2021-01-01' = { name: websiteName location: location properties: { serverFarmId: appServicePlan.id httpsOnly: true siteConfig: { http20Enabled: true appSettings: [ { name: 'CosmosDb:Account' value: cosmosAccount.properties.documentEndpoint } { name: 'CosmosDb:Key' value: listKeys(cosmosAccount.id, cosmosAccount.apiVersion).primaryMasterKey } { name: 'CosmosDb:DatabaseName' value: databaseName } { name: 'CosmosDb:ContainerName' value: containerName } ] } } } resource srcControls 'Microsoft.Web/sites/sourcecontrols@2021-01-01' = { name: '${appService.name}/web' properties: { repoUrl: repositoryUrl branch: branch isManualIntegration: true } } resource dnsTxt 'Microsoft.Network/dnsZones/TXT@2018-05-01' = { name: '${dnsZone}/asuid.${applicationName}' properties: { TTL: 3600 TXTRecords: [ { value: [ '${appService.properties.customDomainVerificationId}' ] } ] } } resource dnsCname 'Microsoft.Network/dnsZones/CNAME@2018-05-01' = { name: '${dnsZone}/${applicationName}' properties: { TTL: 3600 CNAMERecord: { cname: '${appService.name}.azurewebsites.net' } } } // Enabling Managed certificate for a webapp requires 3 steps // 1. Add custom domain to webapp with SSL in disabled state // 2. Generate certificate for the domain // 3. enable SSL // The last step requires deploying again Microsoft.Web/sites/hostNameBindings - and ARM template forbids this in one deplyment, therefore we need to use modules to chain this. resource webAppCustomHost 'Microsoft.Web/sites/hostNameBindings@2020-06-01' = { name: '${appService.name}/${applicationName}.${dnsZone}' dependsOn: [ dnsTxt dnsCname ] properties: { hostNameType: 'Verified' sslState: 'Disabled' customHostNameDnsRecordType: 'CName' siteName: appService.name } } resource webAppCustomHostCertificate 'Microsoft.Web/certificates@2020-06-01' = { name: '${applicationName}.${dnsZone}' // name: dnsZone location: location dependsOn: [ webAppCustomHost ] properties: any({ serverFarmId: appServicePlan.id canonicalName: '${applicationName}.${dnsZone}' }) } // we need to use a module to enable sni, as ARM forbids using resource with this same type-name combination twice in one deployment. module webAppCustomHostEnable './sni-enable.bicep' = { name: '${deployment().name}-${applicationName}-sni-enable' params: { webAppName: appService.name webAppHostname: '${webAppCustomHostCertificate.name}' certificateThumbprint: webAppCustomHostCertificate.properties.thumbprint } } Clean up resources As before, when no longer needed, delete the resource group to prevent incurring any additional costs. ","categories": [],
+ "tags": ["Deployment","Bicep"],
+ "url": "https://azure.github.io/AppService/2021/07/23/Quickstart-Intro-to-Bicep-with-Web-App-plus-DB.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Overview of the Various Methods for Deploying Your Infrastructure to App Service",
+ "excerpt":"There are a number of ways to deploy infrastructure to Azure, what you pick depends on a number of factors including skill level, experience, job requirement, or perhaps company policy. In the end, they’ll essentially get you to the same place - infrastructure deployed to the cloud. This article will cover infrastructure deployment methods including using the Azure Portal, Azure CLI in Cloud Shell or on your local machine, PowerShell, an Azure Resource Manager (ARM) template, Bicep, and Terraform by HashiCorp. Feel free to follow along with the samples as step-by-step guidance will be provided. General Prerequisites Since there are a number of deployment methods in this article, prerequisites will be given on a case by case basis. However to start, if you would like to follow along and you don’t have an Azure subscription, create a free account before you begin. Be mindful when creating and deleting resources as some of the samples in this article may incur charges if you choose certain deployment settings or if you keep your app running for an extended period of time. If you are trying to prevent racking up an charges, please be sure to review the documentation and billing pages closely prior to any deployments. App Overview You will be creating a to-do-list app that uses Microsoft Azure Cosmos DB service to store and access data from an ASP.NET Core MVC application hosted on Azure App Service. More details for this app can be found here. We will be creating the following primary resources: Cosmos DB account to act as the database to store the data from our app App Service Plan which defines the set of compute resources for the web app to run App Service which is an HTTP-based service for hosting web applications, REST APIs, and mobile back ends Code deployment in App Service is another topic that will not be covered in depth in this article, but feel free to browse the docs to understand the various methods. For the purpose of this article, you will stick to one method (External Git) to keep things as consistent as possible. Azure Portal Prerequisites No additional prerequisites for this tutorial. Tutorial In my opinion, the Azure Portal is the most user friendly method for infrastructure deployment, especially for those who are just starting with Azure or do not have much experience with the cloud or infrastructure-as-code. It provides a user interface where you will get to explore the various available services and see step-by-step what is happening as you move through the infrastructure creation process. Navigate to the Azure Portal. At this point, you should have already created an Azure subscription and a free account. If not, navigate back to the General Prerequisites and complete those steps. To start, you will need to create a resource group to hold and manage the resources related to this app. From the home page, click “Create a resource” and search for “resource group.” Select and fill in the following details: Subscription: the name of the subscription you created (or already had if you were an existing Azure user) Resource Group: give your resource group a name that is unique to your Subscription Region: select your preferred region for where you would like the resource group to be located. (Typically you choose a region that is physically close to you to reduce latency, or sometimes certain features/services are only available in certain regions - for the purposes of this article, it does not matter which region you choose.) Select “Review + create” at the bottom left of your screen and wait for validation to complete. If you get an error, review and address as needed. Select “Create” at the bottom left and your resource group will be created Next, you will need to create a Cosmos DB account. For more details on how to do this, see this doc. For this article, I will give quick step-by-step guidance. Navigate back to the “Create a resource” page and search for Cosmos DB. Select “Create” under “Azure Cosmos DB” ane then select “Azure Cosmos DB” again. On the following page, select create under “Core (SQL) - Recommended” as the account type Fill in the following details for your Cosmos DB account: Subscription: the name of the subscription you created (or already had if you were an existing Azure user) Resource Group: the resource group you created earlier Account Name: a unique name to identify the account. The name can only contain lowercase letters, numbers, and the hyphen (-) character. It must be between 3-44 characters in length. Location: a geographic location to host your Azure Cosmos DB account. Use the location that is closest to your users to give them the fastest access to the data. You can use the same or different location as you selected for your resource group since this is only a tutorial, however if you were to put this into production, you would want to think more carefully about this location as well as geo-redundancy options. To keep things as cheap as possible, for “Capacity mode”, select “Provisioned throughput” which gives you the option to “Apply Free Tier Discount.” Select “Apply” if this is your intention. Feel free to browse the remaining settings, but this tutorial will leave them as defaults Select “Review + create” at the bottom left of your screen and wait for validation to complete. If you get an error, review and address as needed. Select “Create” at the bottom left and your Cosmos DB account will be created after a couple minutes While the Cosmos DB account is being provisioned, which can take 5-10 minutes, you can move on to creating the App Service. Navigate back to the “Create a resource” page and search for “Web App.” Make sure you don’t select any of the recommended options and just hit enter to search. Review the results and select “Create” under “Web App.” This will take you to the Web App creation page. Fill in the following details for your Web App: Subscription: the name of the subscription you created (or already had if you were an existing Azure user) Resource Group: the resource group you created earlier Name: a unique name to identify the web app. This will become part of the domain for the app. Publish: “Code” - we will cover this in the next step Runtime stack: “.NET Core 3.1” Operating System: “Windows” Region: a geographic location close to your Azure Cosmos DB account. You will now be selecting the details for the App Service Plan (ASP). Pay close attention here to avoid incurring any unwanted costs. Windows Plan: select “Create new” and give the A**: a name Sku and size: select “Change size” and choose the**:ier that fits your budget. “F1” is the free tier and should be sufficient for this tutorial. I would recommend using “S1” or higher for this however since it gives you more features to experiment with. Select your tier and hit “Apply.” Feel free to browse the remaining settings, but this tutorial will leave them as defaults. Select “Review + create” at the bottom left of your screen and wait for validation to complete. If you get an error, review and address as needed. Select “Create” at the bottom left and your web app will be created after a couple minutes While the web app is being provisioned, navigate to your newly created Cosmos DB account. The easiest way to do this is to go to your Resource Group to view all of the resources you have created so far. You will now create the container in the Cosmos DB account that will hold the data for our app Make sure you are on the “Overview” page and select “Add Container” at the top left Fill in the following values, leaving the remaining as default: Database id: select “Create new” and call it Tasks Database throughput: select “Manual” and change the value to 400 which should be sufficient for this tutorial Container id: Items Partition key: /id Select “OK” to close out the dialog. Your container and empty table will get provisioned after a couple seconds Now it is time to connect your database to your web app. Under “Settings” on the left hand side, select “Keys” to show the various keys and connection strings associated with your database. Copy and paste the following into a text editor: URI Primary Key Once you have these values, navigate to your Web App. You can do this by retuning to your Resource Group and selecting the Web App from there. Make sure you select the resource with the type “App Service.” Under “Settings” on the left hand side, select “Configuration” to add the connection to your database Under “Application settings” select “New application setting” and create the following (you will need to hit “New application setting” for each one) Name = CosmosDb:Account, Value = <database URI> Name = CosmosDb:Key, Value = <database Primary key> Name = CosmosDb:DatabaseName, Value = Tasks Name = CosmosDb:ContainerName, Value = Items Hit “Save” at the top and then “Continue” for the notification saying your app will be restarted Finally, your app is configured and you can upload your code. Head over to “Deployment Center” under “Deployment” on the left hand side Use the following settings: Source: “External Git” Repository: https://github.com/Azure-Samples/cosmos-dotnet-core-todo-app.git Branch: main Repository Type: “Public” Hit “Save” at the top and give your app time to build and deploy the code. You can review the status by selecting “Logs” next to the “Settings” tab in the Deployment Center. When Status says “Success (Active)” your app should be up and running! Navigate to the “Overview” tab on the left hand side and find your app’s URL. Hit that and it should open your app in a new tab. Feel free to play around with it and see what you’ve created! If your app doesn’t open immediately or you get a generic landing page, wait a couple minutes and try again. If needed, restart your app by hitting “Restart” at the top of the “Overview” tab. When you are done, you can delete your resources. You can do this by deleting the resource group. Congratulations! You just deployed a web app connected to a database on Azure. Continue to the next section to learn about another deployment method. Azure CLI Prerequisites Azure hosts Azure Cloud Shell, an interactive shell environment that you can use through your browser. You can use either Bash or PowerShell with Cloud Shell to work with Azure services. You can use the Cloud Shell preinstalled commands to run the code in this article without having to install anything on your local environment. If you prefer to use your local environment, follow the steps here to install the latest version. If you are using the Azure CLI from your local environment, you will need to login first with the az login command. Proceed to the tutorial once logged in. If you would like to use the Azure Cloud Shell either navigate to the Azure portal and select the Cloud Shell button on the menu bar at the upper right, or just navigate to https://shell.azure.com/. Confirm you have a Bash shell opened by checking the top left of the Cloud Shell and select “Bash” from the drop down. Tutorial The Azure CLI is a cross-platform command-line tool to connect to Azure and execute administrative commands on Azure resources. It allows the execution of commands through a terminal using interactive command-line prompts or a script. It is a great tool for those who have experience working from a command line and are comfortable with either bash or PowerShell. For those with less experience, there is an interactive mode which can be activated by running the az interactive command. Below is a script which if you copy and paste into your CLI/shell will run all of the commands and deploy the application in one shot. I recommend however that you copy and paste each of the commands one at a time to get a better understanding of what is happening during each step. You can navigate between your CLI and the portal to see the resources in your resource group as they get created. Comments have provided throughout the script to identify what each of the commands is doing. # Variables resourceGroupName=\"myResourceGroup\" appName=\"webappwithcosmosdb$RANDOM\" location=\"eastus\" appServicePlanName=\"$appName-ASP\" # Do not change these databaseName=\"Tasks\" containerName=\"Items\" # Create a Resource Group az group create --name $resourceGroupName --location $location # Create an App Service Plan az appservice plan create --resource-group $resourceGroupName --name $appServicePlanName --sku S1 --location $location # Create a Web App in the App Service Plan az webapp create --name $appName --plan $appServicePlanName --resource-group $resourceGroupName # Create a Cosmos DB account az cosmosdb create --name $appName --resource-group $resourceGroupName --kind GlobalDocumentDB # Get the database connection details and store them as variables. Make sure there is only one Cosmos DB account in your resource group. Otherwise, you will need to further parse the response from the below command to obtain the needed info. databaseUri=$(az cosmosdb list --resource-group $resourceGroupName --query [0].documentEndpoint --output tsv) primaryMasterKey=$(az cosmosdb keys list --name $appName --resource-group $resourceGroupName --type keys --query primaryMasterKey --output tsv) # Assign the database details to App Settings in the Web App az webapp config appsettings set --name $appName --resource-group $resourceGroupName --settings \"CosmosDb:Account=$databaseUri\" az webapp config appsettings set --name $appName --resource-group $resourceGroupName --settings \"CosmosDb:Key=$primaryMasterKey\" az webapp config appsettings set --name $appName --resource-group $resourceGroupName --settings \"CosmosDb:DatabaseName=$databaseName\" az webapp config appsettings set --name $appName --resource-group $resourceGroupName --settings \"CosmosDb:ContainerName=$containerName\" # Upload the code using External Git az webapp deployment source config --resource-group $resourceGroupName --name $appName --repo-url https://github.com/Azure-Samples/cosmos-dotnet-core-todo-app.git --branch main --manual-integration And that’s it! Give your app a couple minutes to deploy, and then navigate to your app’s URL (<https://APP-NAME.azurewebsites.net>) to validate everything was created as intended. When you are done, delete the resource group to delete the resources. PowerShell The Az PowerShell module is a set of cmdlets for managing Azure resources directly from PowerShell. PowerShell provides powerful features for automation that can be leveraged for managing your Azure resources for examples in the context of a CI/CD pipeline. You can use the Az PowerShell module with one of the following methods: Install the Az PowerShell module via PowerShellGet (recommended option). Install the Az PowerShell module with MSI. Use Azure Cloud Shell. Use the Az PowerShell Docker container. Prerequisites If needed, install the Azure PowerShell using the instruction found in the Azure PowerShell guide, and then run Connect-AzAccount to create a connection with Azure. If you would like to use the Azure Cloud Shell either navigate to the Azure portal and select the Cloud Shell button on the menu bar at the upper right, or just navigate to https://shell.azure.com/. Ensure you have a PowerShell type shell opened (not Bash) by selecting PowerShell from the top left corner of the Cloud Shell. Tutorial Below is a commented script that will deploy the necessary resources for this application. Take some time to go through each cmdlet to understand what each is doing. You will notice that this script is very similar to the CLI script given previously. # Generates a Random Value $Random=(New-Guid).ToString().Substring(0,8) # Variables $ResourceGroup=\"MyResourceGroup$Random\" $AppName=\"webappwithcosmosdb$Random\" $Location=\"East US\" $ServerName=\"$AppName-ASP\" # Do not change these $DatabaseName=\"Tasks\" $ContainerName=\"Items\" # Create a Resource Group New-AzResourceGroup -Name $ResourceGroup -Location $Location # Create an App Service Plan New-AzAppservicePlan -Name $ServerName -ResourceGroupName $ResourceGroup -Location $Location -Tier Basic # Create a Web App in the App Service Plan New-AzWebApp -Name $AppName -ResourceGroupName $ResourceGroup -Location $Location -AppServicePlan $ServerName # Create a Cosmos DB account New-AzCosmosDBAccount -ResourceGroupName $ResourceGroup -Name $AppName -Location $Location -ApiKind GlobalDocumentDB # Get the database connection details and store them as variables. Make sure there is only one Cosmos DB account in your resource group. Otherwise, you will need to further parse the response from the below command to obtain the needed info. $DatabaseUri=(Get-AzCosmosDBAccount -ResourceGroupName $ResourceGroup).DocumentEndpoint $PrimaryMasterKey=(Get-AzCosmosDBAccountKey -ResourceGroupName $ResourceGroup -Name $AppName -Type Keys).PrimaryMasterKey # Assign the database details to App Settings in the Web App $hashtable = @{ \"CosmosDb:Account\" = $DatabaseUri \"CosmosDb:Key\" = $PrimaryMasterKey \"CosmosDb:DatabaseName\" = $DatabaseName \"CosmosDb:ContainerName\" = $ContainerName } Set-AzWebApp -ResourceGroupName $ResourceGroup -Name $AppName -AppSettings $hashtable # Upload the code using External Git $PropertiesObject = @{ repoUrl = \"https://github.com/Azure-Samples/cosmos-dotnet-core-todo-app.git\"; branch = \"main\"; isManualIntegration = \"true\"; } Set-AzResource -Properties $PropertiesObject -ResourceGroupName $ResourceGroup -ResourceType Microsoft.Web/sites/sourcecontrols -ResourceName $AppName/web -ApiVersion 2015-08-01 -Force Give your app a couple minutes to deploy, and then navigate to your app’s URL (<https://APP-NAME.azurewebsites.net>) to validate everything was created as intended. When you are done, delete the resource group to delete the resources. Azure Resource Manager (ARM) Template An ARM template is a JavaScript Object Notation (JSON) file that defines the infrastructure and configuration for your project. This is also known as “Infrasture as Code (IaC).” The template uses declarative syntax. In declarative syntax, you describe your intended deployment without writing the sequence of programming commands to create the deployment. ARM templates are great for companies or people that need reusable templates to manage their infrastructure in a secure and consistent manner. For example, if a development team from a company requires a VM with a database to deploy a certain application, the approved ARM template for this configuration can be used which ensures this team is given approved and secure infrastructure and prevents the team from configuring something that can potentially lead to a hack or unidentified vulnerability. There are numerous linters and scanners that can review templates to ensure they are following certain security and regulatory standards as well which further adds to the sense of security companies can have when they use this deployment method. Prerequisites You will need a text editor or IDE to carry out this tutorial. I would recommend Visual Studio Code. You will also need to install the Azure CLI. You have the option of using the Azure Cloud Shell which does not require any additional installation. The Azure Cloud Shell has a built in editor which can be opened by clicking the button that looks like “{ }” at the top of the screen. Tutorial Review the below template. You will recognize that all of the resources in the template, including the settings, are what you created previously. { \"$schema\": \"https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#\", \"contentVersion\": \"1.0.0.0\", \"metadata\": { \"_generator\": { \"name\": \"bicep\", \"version\": \"dev\", \"templateHash\": \"108437092261803770\" } }, \"parameters\": { \"applicationName\": { \"type\": \"string\", \"defaultValue\": \"[format('to-do-app{0}', uniqueString(resourceGroup().id))]\", \"maxLength\": 30, \"metadata\": { \"description\": \"Application Name\" } }, \"location\": { \"type\": \"string\", \"defaultValue\": \"[resourceGroup().location]\", \"metadata\": { \"description\": \"Location for all resources.\" } }, \"appServicePlanTier\": { \"type\": \"string\", \"defaultValue\": \"S1\", \"metadata\": { \"description\": \"App Service Plan's pricing tier. Details at https://azure.microsoft.com/en-us/pricing/details/app-service/\" }, \"allowedValues\": [ \"F1\", \"D1\", \"B1\", \"B2\", \"B3\", \"S1\", \"S2\", \"S3\", \"P1V2\", \"P2V2\", \"P3V2\", \"P1V3\", \"P2V3\", \"P3V3\" ] }, \"appServicePlanInstances\": { \"type\": \"int\", \"defaultValue\": 1, \"metadata\": { \"description\": \"App Service Plan's instance count\" }, \"maxValue\": 3, \"minValue\": 1 }, \"repositoryUrl\": { \"type\": \"string\", \"defaultValue\": \"https://github.com/Azure-Samples/cosmos-dotnet-core-todo-app.git\", \"metadata\": { \"description\": \"The URL for the GitHub repository that contains the project to deploy.\" } }, \"branch\": { \"type\": \"string\", \"defaultValue\": \"main\", \"metadata\": { \"description\": \"The branch of the GitHub repository to use.\" } }, \"databaseName\": { \"type\": \"string\", \"defaultValue\": \"Tasks\", \"metadata\": { \"description\": \"The Cosmos DB database name.\" } }, \"containerName\": { \"type\": \"string\", \"defaultValue\": \"Items\", \"metadata\": { \"description\": \"The Cosmos DB container name.\" } } }, \"functions\": [], \"variables\": { \"cosmosAccountName\": \"[toLower(parameters('applicationName'))]\", \"websiteName\": \"[parameters('applicationName')]\", \"hostingPlanName\": \"[parameters('applicationName')]\" }, \"resources\": [ { \"type\": \"Microsoft.DocumentDB/databaseAccounts\", \"apiVersion\": \"2021-04-15\", \"name\": \"[variables('cosmosAccountName')]\", \"kind\": \"GlobalDocumentDB\", \"location\": \"[parameters('location')]\", \"properties\": { \"consistencyPolicy\": { \"defaultConsistencyLevel\": \"Session\" }, \"locations\": [ { \"locationName\": \"[parameters('location')]\", \"failoverPriority\": 0, \"isZoneRedundant\": false } ], \"databaseAccountOfferType\": \"Standard\" } }, { \"type\": \"Microsoft.Web/serverfarms\", \"apiVersion\": \"2020-06-01\", \"name\": \"[variables('hostingPlanName')]\", \"location\": \"[parameters('location')]\", \"sku\": { \"name\": \"[parameters('appServicePlanTier')]\", \"capacity\": \"[parameters('appServicePlanInstances')]\" } }, { \"type\": \"Microsoft.Web/sites\", \"apiVersion\": \"2020-06-01\", \"name\": \"[variables('websiteName')]\", \"location\": \"[parameters('location')]\", \"properties\": { \"serverFarmId\": \"[resourceId('Microsoft.Web/serverfarms', variables('hostingPlanName'))]\", \"siteConfig\": { \"appSettings\": [ { \"name\": \"CosmosDb:Account\", \"value\": \"[reference(resourceId('Microsoft.DocumentDB/databaseAccounts', variables('cosmosAccountName'))).documentEndpoint]\" }, { \"name\": \"CosmosDb:Key\", \"value\": \"[listKeys(resourceId('Microsoft.DocumentDB/databaseAccounts', variables('cosmosAccountName')), '2021-04-15').primaryMasterKey]\" }, { \"name\": \"CosmosDb:DatabaseName\", \"value\": \"[parameters('databaseName')]\" }, { \"name\": \"CosmosDb:ContainerName\", \"value\": \"[parameters('containerName')]\" } ] } }, \"dependsOn\": [ \"[resourceId('Microsoft.DocumentDB/databaseAccounts', variables('cosmosAccountName'))]\", \"[resourceId('Microsoft.Web/serverfarms', variables('hostingPlanName'))]\" ] }, { \"type\": \"Microsoft.Web/sites/sourcecontrols\", \"apiVersion\": \"2020-06-01\", \"name\": \"[format('{0}/web', variables('websiteName'))]\", \"properties\": { \"repoUrl\": \"[parameters('repositoryUrl')]\", \"branch\": \"[parameters('branch')]\", \"isManualIntegration\": true }, \"dependsOn\": [ \"[resourceId('Microsoft.Web/sites', variables('websiteName'))]\" ] } ] } The template starts with the parameters for the infrastructure. Following the parameters are the resources. I will not repeat what these resources are since they are the same as those created before. Feel free to browse here to learn more about the various resources. In order to deploy this template, follow these steps: Copy and paste the template to your preferred editor/IDE/Cloud Shell and save the file to your working directory Open up a terminal where the Azure CLI has been installed and run the code below to create a resource group az group create --name myResourceGroup --location \"eastus\" Deploy the template using the following: az deployment group create --resource-group myResourceGroup --template-file <path-to-template> And that’s it! Wait for a success message and navigate to your web app URL to prove that everything was created as intended. When you are done, delete the resource group to delete the resources Bicep File Bicep is a domain-specific language (DSL) that uses declarative syntax to deploy Azure resources. It provides concise syntax, reliable type safety, and support for code reuse. You can use Bicep instead of JSON to develop your Azure Resource Manager templates (ARM templates). The JSON syntax to create an ARM template can be verbose and require complicated expressions. Bicep syntax reduces that complexity and improves the development experience. Bicep is a transparent abstraction over ARM template JSON and doesn’t lose any of the JSON template capabilities. During deployment, the Bicep CLI transpiles a Bicep file into ARM template JSON. I would recommend Bicep to developers who are looking to create reusable templates for their infrastructure. If you have used ARM templates previously, it would be good to take a look at Bicep to see how it simplifies and speeds up template creation. Click here if you are interested in learning more about Bicep. Prerequisites The Azure CLI is used here to deploy the template. You can also use the Azure portal, Azure PowerShell, or REST API. To learn about other deployment methods, see Bicep Deployment Commands. In order to effectively create resources with Bicep, you will need to set up a Bicep development environment. Feel free to use the Azure Cloud Shell or your IDE of choice (this requires installing the Azure CLI locally). The Bicep extension for Visual Studio Code provides language support and resource autocompletion. The extension helps you create and validate Bicep files and is recommended for those that will continue to create resources using Bicep upon completing this tutorial. Tutorial I’ll start off by giving you the file. You will recognize that all of the resources in the template, including the settings, are what you created previously. Compared to the ARM template, we reduced the number of lines and complexity significantly. param appServicePlanTier string = 'S1' @minValue(1) @maxValue(3) @description('App Service Plan\\'s instance count') param appServicePlanInstances int = 1 @description('The URL for the GitHub repository that contains the project to deploy.') param repositoryUrl string = 'https://github.com/Azure-Samples/cosmos-dotnet-core-todo-app.git' @description('The branch of the GitHub repository to use.') param branch string = 'main' @description('The Cosmos DB database name.') param databaseName string = 'Tasks' @description('The Cosmos DB container name.') param containerName string = 'Items' var cosmosAccountName = toLower(applicationName) var websiteName = applicationName var appServicePlanName = applicationName resource cosmosAccount 'Microsoft.DocumentDB/databaseAccounts@2021-04-15' = { name: cosmosAccountName kind: 'GlobalDocumentDB' location: location properties: { consistencyPolicy: { defaultConsistencyLevel: 'Session' } locations: [ { locationName: location failoverPriority: 0 isZoneRedundant: false } ] databaseAccountOfferType: 'Standard' } } resource appServicePlan 'Microsoft.Web/serverfarms@2021-01-01' = { name: appServicePlanName location: location sku: { name: appServicePlanTier capacity: appServicePlanInstances } kind: 'linux' } resource appService 'Microsoft.Web/sites@2021-01-01' = { name: websiteName location: location properties: { serverFarmId: appServicePlan.id httpsOnly: true siteConfig: { http20Enabled: true appSettings: [ { name: 'CosmosDb:Account' value: cosmosAccount.properties.documentEndpoint } { name: 'CosmosDb:Key' value: listKeys(cosmosAccount.id, cosmosAccount.apiVersion).primaryMasterKey } { name: 'CosmosDb:DatabaseName' value: databaseName } { name: 'CosmosDb:ContainerName' value: containerName } ] } } } resource srcControls 'Microsoft.Web/sites/sourcecontrols@2021-01-01' = { name: '${appService.name}/web' properties: { repoUrl: repositoryUrl branch: branch isManualIntegration: true } } The file starts with the parameters for the infrastructure. They are defined in the template itself, but you are free to leave them as inputs which can be added during deployment. Following the parameters are the resources. Feel free to browse here to learn more about the various resources. There are tabs for ARM and Bicep. In order to deploy this template follow these steps: Copy and paste the template to your preferred editor/IDE/Cloud Shell and save the file to your working directory Open up a terminal where the Azure CLI has been installed and run the code below to create a resource group az group create --name myResourceGroup --location \"eastus\" Deploy the template using the following: az deployment group create --resource-group myResourceGroup --template-file <path-to-template> And that’s it! Wait for a success message and navigate to your web app URL to prove that everything was created as intended. When you are done, delete the resource group to delete the resources Terraform Terraform by Hashicorp is an open source tool that codifies APIs into declarative configuration files that can be used to create, manage, and update infrastructure resources such as virtual machines (VMs), networks, and containers. It is becoming the deployment method of choice for many large enterprises since it can provision infrastructure across 300+ public clouds and services using a single workflow and consistent syntax. For this reason, many companies that are choosing multi-cloud leverage Terraform. Prerequisites I would recommend going to the Terraform documentation for getting started on Azure to learn more about Terraform and understand how to configure your environment as they will do a much better job than I can here. Once you have reviewed their materials, the below template is all you need! Tutorial Follow the guidance as provided by this doc to deploy this template. Replace the contents of their “main.tf” with the below. For a quick summary of what is needed to get this deployed (ignoring many of the great features Terraform has to offer which I do recommend reviewing at some point): Open up your IDE of choice where Terraform has been installed Created a new directory and cd into it Create a main.tf file and copy and paste the below template into there Run terraform init Run terraform apply Once complete, navigate to the web app URL to view your app When you are done, delete the resource group to delete the resources You can also run a terraform destroy command here as an alternative variable \"failover_location\" { default = \"westus\" } terraform { required_providers { azurerm = { source = \"hashicorp/azurerm\" version = \"~>2.0\" } } } provider \"azurerm\" { features {} } resource \"azurerm_resource_group\" \"rg\" { name = \"myResourceGroup\" location = \"eastus\" } resource \"random_integer\" \"ri\" { min = 10000 max = 99999 } resource \"azurerm_cosmosdb_account\" \"db\" { name = \"webapp-cosmos-db-${random_integer.ri.result}\" location = azurerm_resource_group.rg.location resource_group_name = azurerm_resource_group.rg.name offer_type = \"Standard\" kind = \"GlobalDocumentDB\" consistency_policy { consistency_level = \"Session\" } geo_location { location = var.failover_location failover_priority = 1 } geo_location { location = azurerm_resource_group.rg.location failover_priority = 0 } } resource \"azurerm_app_service_plan\" \"appserviceplan\" { name = \"webapp-cosmos-db-${random_integer.ri.result}\" location = azurerm_resource_group.rg.location resource_group_name = azurerm_resource_group.rg.name sku { tier = \"Standard\" size = \"S1\" } } resource \"azurerm_app_service\" \"webapp\" { name = \"webapp-cosmos-db-${random_integer.ri.result}\" location = azurerm_resource_group.rg.location resource_group_name = azurerm_resource_group.rg.name app_service_plan_id = azurerm_app_service_plan.appserviceplan.id app_settings = { \"CosmosDb:Account\" : azurerm_cosmosdb_account.db.endpoint, \"CosmosDb:Key\" : azurerm_cosmosdb_account.db.primary_key, \"CosmosDb:DatabaseName\" : \"Tasks\", \"CosmosDb:ContainerName\" : \"Items\" } source_control { repo_url = \"https://github.com/Azure-Samples/cosmos-dotnet-core-todo-app.git\" branch = \"main\" manual_integration = true use_mercurial = false } } Wrapping Up Thanks for taking the time to go through this tutorial. Again, please ensure you have deleted any resources you do not intend to keep. I hope you learned something about the various ways the App Service team has worked to create a platform that meets as many of your web app needs as possible and reach a variety of customers. If you have any questions, feedback, or requests, feel free to share using the links below. Also note that App Service is constantly updated to improve functionality and usability. If anything from the article no longer applies or if you get stuck, always feel free to reach out! ","categories": [],
+ "tags": ["Deployment"],
+ "url": "https://azure.github.io/AppService/2021/07/29/Deploying-Your-Infrastructure-to-App-Service.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Set up GitHub Actions with the Azure CLI",
+ "excerpt":"With GitHub Actions you can set up a workflow to build and deploy your applications whenever there’s a commit on your main branch, or a PR is merged, or even on a schedule! If getting started with GitHub Actions sounds daunting, the Deployment Center in the Azure Portal makes it easy. The guided experience will put a curated workflow file in your chosen repository to build and deploy your application. If you’re more comfortable on the command line, you can now use the Azure CLI to set up GitHub Actions for your web apps. Just like the Deployment Center, this CLI command will put a curated workflow file in your target repository. CLI Instructions First, make sure you are using version 2.27.0 or greater. az --version The first line in the output will show the CLI version: azure-cli 2.27.0 core 2.27.0 telemetry 1.0.6 Next, run the following CLI command to set up GitHub Actions. Replace <app-name>, <group-name>, and <owner>/<repository-name> with your Web App name, resource group, and repository respectively. Bash: az webapp deployment github-actions add --name '<app-name>' \\ --resource-group '<group-name>' \\ --repo '<owner>/<repository-name>' \\ --login-with-github PowerShell: az webapp deployment github-actions add ` --name '<app-name>' ` --resource-group '<group-name>' ` --repo '<owner>/<repository-name>' ` --login-with-github In the command output there will be a login URL and user code. Open the URL in the command output, https://github.com/login/device, and enter the user code shown in the output. Command group 'webapp deployment github-actions' is in preview and under development. Reference and support levels: https://aka.ms/CLI_refstatus Please navigate to https://github.com/login/device and enter the user code 985C-11BD to activate and retrieve your github personal access token Waiting up to '14' minutes for activation Once you log in, the CLI command will continue, committing GitHub Actions workflow file to your repository under .github/workflows, setting the deployment credentials in your repository’s secrets, and registering the repository with your Web App so you can view deployment logs in the Deployment Center. With a few CLI commands you’re up-and-running with GitHub Actions. Keep in mind that every application is unique, so you may need to update the curated workflow file to correctly build your app if you’re doing multi-step builds or using non-standard testing libraries. See the GitHub Actions Reference Documentation for more information. ","categories": [],
+ "tags": ["Deployment"],
+ "url": "https://azure.github.io/AppService/2021/08/09/setup-github-actions-azurecli.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "App Service Support for Availability Zones",
+ "excerpt":" NOTE! As of March 2023, the content in this post may be outdated. For the latest information on Availability Zone support for App Service, see Azure App Service and reliability and Migrate App Service to availability zone support. Availability Zone (AZ) support for public multi-tenant App Service is now available. The official doc has been published to Microsoft Azure docs. AZ support for App Service Environments (ASEs) is also available, see Availability Zone support for App Service Environments. Additionally, AZ support for the Azure Functions Premium plan is now available, see Azure Functions support for availability zone redundancy. Availability Zone Overview An Availability Zone is a high-availability offering that protects your applications and data from datacenter failures. Availability Zones are unique physical locations within an Azure region. Each zone is made up of one or more datacenters equipped with independent power, cooling, and networking. To ensure resiliency, there’s a minimum of three separate zones in all enabled regions. Build high-availability into your application architecture by co-locating your compute, storage, networking, and data resources within a zone and replicating in other zones. To learn more about Availability Zones, continue reading here. Requirements AZ support, otherwise known as zone redundancy, is a property of the App Service Plan (ASP). The following are the current requirements/limitations for enabling zone redundancy: Both Windows and Linux are supported Requires either Premium v2 or Premium v3 App Service Plans Minimum instance count of 3 The platform will enforce this minimum count behind the scenes if you specify an instance count fewer than 3. This is due to the platform automatically spreading these VMs across 3 zones when zone redundancy is enabled. Can be enabled in any of the following regions: West US 2 West US 3 Central US East US East US 2 Canada Central Brazil South North Europe West Europe Germany West Central France Central UK South Japan East Southeast Asia Australia East Zone redundancy can only be specified when creating a new App Service Plan Currently you can not convert pre-existing App Service Plan. See next bullet for details on how to create a new App Service Plan that supports zone redundancy. AZ is only supported in the newer portion of the App Service footprint Currently if you are running on Pv3 then you are already on the footprint that supports AZ and all you need to do is create a new App Service Plan If you are not using Pv3 or a scale unit that supports AZ, are in a region that isn’t supported, or are unsure, follow the steps below: Create a new resource group in a region that is supported Create a new App Service Plan (and app) in a region of your choice using the new resource group Must be created using ARM templates How to Deploy a Zone Redundant App Service Currently, you need to use an ARM templates to create a zone redundant App Service. Once created via an ARM template, the App Service Plan can be viewed and interacted with via the Azure Portal as well as CLI tooling. An ARM template is only needed for the initial creation of the App Service Plan. The only changes needed in an ARM template to specify a zone redundant App Service are the new zoneRedundant property (required) and optionally the App Service Plan instance count (i.e. capacity) on the Microsoft.Web/serverfarms resource. If you don’t specify a capacity, the platform defaults to 3. The zoneRedundant property should be set to true and capacity should be set based on the workload requirement, but no less than 3. Choosing the right capacity varies based on a number of factors as well as high availability/fault tolerance strategies, however a good rule of thumb is to ensure sufficient instances for the application such that losing one zone of instances leaves sufficient capacity to handle expected load. TIP To decide instance capacity, you can use the following calculation: Since the platform spreads VMs across 3 zones and you need to account for at least the failure of 1 zone, multiply peak workload instance count by a factor of zones/(zones-1), or 3/2. For example, if your typical peak workload requires 4 instances, you should provision 6 instances: (2/3 * 6 instances) = 4 instances. In the case when a zone goes down, the App Service platform will detect lost instances and automatically attempt to find new instances to replace the ones that were lost. Note that if auto-scale is also configured, and if it decides more instances are needed, auto-scale will also issue a request to App Service to add more instances (auto-scale behavior is independent of App Service platform behavior). It is important to note that there is no guarantee that requests for additional instances in a zone-down scenario will succeed since back filling lost instances occurs on a best-effort basis. The recommended solution is to provision your App Service Plans to account for losing a zone as described previously in this article. The ARM template snippet below shows the new zoneRedundant property and capacity specification. \"resources\": [ { \"type\": \"Microsoft.Web/serverfarms\", \"apiVersion\": \"2018-02-01\", \"name\": \"your-appserviceplan-name-here\", \"location\": \"West US 3\", \"sku\": { \"name\": \"P1v3\", \"tier\": \"PremiumV3\", \"size\": \"P1v3\", \"family\": \"Pv3\", \"capacity\": 3 }, \"kind\": \"app\", \"properties\": { \"zoneRedundant\": true } } ] For details on how to deploy ARM templates, see this doc. For App Service ARM quickstarts, visit this GitHub repo. ","categories": ["networking"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2021/08/25/App-service-support-for-availability-zones.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Overview of the 'kind' property for App Service",
+ "excerpt":"We get a lot of questions on the App Service kind property, so we are sharing some information to help you understand what it is, what it does, and how to use it. In general, kind is an ARM envelop property so almost every resource in Azure has one. See Resources - Get for more information on Azure resource properties. The way in which resources use this property varies service by service. There are several different offerings in the Azure portal that use the same underlying Microsoft.Web\\Sites resource. App Service at this time only uses the value of the kind property to specialize the UX of a Microsoft.Web\\Sites resource in the Azure Portal. The value isn’t used for anything in the management plane. The kind property of an app is set during the create flow and can’t be modified thereafter. The portal does this based on the create flow of your choice and/or the configuration you enter. This is also true of the App Service CLI and other clients like Visual Studio Code. You will need to manually set the kind property if you are creating resources through ARM templates, or using the ARM API directly. Note that the kind property also shows up in App Service Plans (ASP). At this time, the value of this property for the ASP is meaningless and has no impact on your resource. For example, you can set kind to “Linux” for the ASP, but that won’t make your ASP a Linux ASP; the reserved property is what makes this distinction (if reserved = true, it’s a Linux ASP, otherwise it’s a Windows ASP). For more information on how App Service uses the kind property as well as the current list of recommended values, visit the App Service Linux docs repo. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2021/08/31/Kind-property-overview.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Web App (Windows) Restart Operations",
+ "excerpt":"This document covers some common operations that can be performed in an App Service and the effects in terms of availability and restart operations. Restarts on an App Service can be triggered either manually or by configuration changes. This document describes the effects only in App Services running on Windows operating system. User-Initiated Restart Operations From a user perspective, a restart can be initiated by using any of the following methods: App Service Restart in Portal/Powershell/Azure CLI This action will restart all the processes in every instance where your App Service is running. This will essentially restart your application fully, therefore expect some HTTP 503 errors during the process and a possible increase of resource consumption such as CPU during the operation. If settings such as Application Initialization are applied, the application won’t be fully available until the initialization completes as expected. Kudu process is also restarted, so some operations can fail until the process is restarted. Other App Services running on the same App Service Plan will not be restarted Advanced Application Restart of instance When restarting using the Advanced Application Restart feature in Diagnostic tools, the process of the specific instance selected will be restarted, and all the requests will be redirected to the other active instances if there were any. If settings such as Application Initialization are applied, the application won’t be fully available until the initialization completes as expected. Soft Restart When applying soft restart, which you can learn about here: Web Apps - Restart, the process will be recycled but it won’t go through a full re-load Slowness in requests can be expected. All the instances will be restarted when this operation is applied. Restart of Specific App Service Plan worker node Restarting a specific worker node of a specific App Service Plan is possible through API. The consequences of restarting the worker node are that all those App Services running on that instance will get their processes restarted. All the other instances will remain up and running. You can learn more about this operation here: App Service Plans - Reboot Worker Deployment Slots Restarts Restarting any deployment slot won’t affect any of the other deployment slots available for the app. On the other hand, restarting an application could cause a possible increase in resource consumption, and depending on the application sometimes those extra resources can be high, so be aware that even though restarting a slot should not affect the other slots, resources are still shared, so it can indirectly affect the other slots if the App Service Plan does not have enough resources. Swap Operations Swapping between slots will trigger restarts of the source and destination slots as described here: Set up staging environments - Azure App Service It is important to mention the use of Swap with preview. While this won’t stop the service from restarting, it will help make sure that the service is ready before the swap executes, so the swap will not be confirmed until the user confirms it, giving the opportunity to test it before swapping slots, therefore reducing downtime too. Scaling Operations Scaling out/in operations does not trigger a start or stop operation apart from the newly added instance or the instance that is going to be removed. Some slowness can be experienced in these operations on requests directed to the specific instance that is being added or removed. Scaling up operations will trigger a full restart of the application as it will be fully moved to new instances. This involves all the processes expected from a cold start, so operations such as Application Initialization will be triggered. Another side effect of scaling up operations is that all the App Services hosted in the specific App Service Plan will be restarted as well. As all the apps restart at the same time, it is very common that the resource usage at that time will be higher than normal. Auto-Heal App Services provides two options to Auto-Heal your application: Proactive Auto-Heal Custom Auto-Heal These two options will restart the specific instance of your application if it matches the conditions. In the case of Custom Auto-heal, it will depend on the custom action that has been selected to be triggered, as some actions don’t really recycle the process. The restart applied will be a full restart cycle, so operations as Application Initialization will be expected. If the App Service only has one instance, 503 errors could be expected as well. Enabling/Disabling Auto-Heal rules (proactive or custom) will have a full restart effect, including processes such as Application Initialization. Errors such as 503 can be expected. Health Check Feature Enabling HealthCheck will restart the application, so slowness can be expected. HealthCheck feature also has some restart effects by design, as if a specific instance is having problems, it will try to restart the instance as explained in Health Check Feature. Additionally, if an instance becomes unavailable for a long time, HealthCheck will replace the unhealthy instances, up to a maximum of 3 per day. Configuration changes effects on Availability Most of the configuration changes trigger some sort of restart. It is important to be aware that any config changes in sections such as the ones listed below can trigger a restart, so it is recommended to plan accordingly before any change. Configuration (general settings, application settings, default documents) Authentication/Authorization Application Insights – Any modification to the settings will cause an app restart Identity Backup Configuration Custom Domain Operations CORS Settings TLS Settings Networking Features App Service Logs ","categories": ["diagnostics"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2021/09/16/App-Service-Restarts.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Managing an App Service Domain",
+ "excerpt":"App Service Domain is a domain resource on Azure which integrates with Azure DNS. This allows you to manage all your resources on Azure for when you need to get your web app up and running. Purchasing an App Service Domain Refer to the docs on how to purchase an App Service Domain. Managing DNS An Azure DNS resource also gets created with your App Service Domain by default. You can use your Azure DNS to manage the DNS of your domain. You can look for the Azure DNS resource by either searching for the Azure DNS with the same domain name or go to it through your App Service Domain via “Manage DNS records”. Transfering domain out Transfering of domain out of Azure (not a registrar) to another registrar is supported and you may currently do so via API and PowerShell. You will need to get an authorization code which you can take to the registrar of choice to proceed with transfering out of your domain. Exceptions for transfering domain out You won’t be able to transfer your domain within 60 days of these events: New domain registration Transfer between different registrars Change to registrant contact information Special case for “.uk” domains For any “.uk” domains, you’ll need the new registrar’s IPS tag. Create a support case and provide us the IPS tag. We will assist with updating the IPS tag on your domain to your new registrar and then you can complete the transfer out process with your new registrar. What is an authorization code? The authorization code is a unique string of characters consisting of letters, numbers, and special characters (ie. ? ! ^) that is required to transfer a domain from one registrar to another. Getting authorization code with transfer out API You can use the transfer out API: PUT https://management.azure.com/subscriptions/<SUBSCRIPTION-ID>/resourceGroups/<RESOURCE-GROUP-NAME>/providers/Microsoft.DomainRegistration/domains/<DOMAIN-NAME>/transferout?api-version=2021-02-01 You may be able to run this API on Azure Resource Explorer. Fill out the necessary information in between the “<” and “>” from the above, then paste the API call to you Azure Resource Explorer. Highlight the entire line from “PUT” until “api-version=2021-02-01” and hit Ctrl+S to run the command. You would expect similar results from the image below. Refer to the “authCode” value without the double quotes (“). This will be the authorization code you will need to provide the new domain registrar to transfer your domain out. Getting authorization code with Powershell There currently is no first class Powershell support for domain transfer out. However, you can use the following call below to get your authorization code: Invoke-AzRestMethod -Path \"/subscriptions/<SUBSCRIPTION-ID>/resourceGroups/<RESOURCE-GROUP-NAME>/providers/Microsoft.DomainRegistration/domains/<DOMAIN-NAME>/transferout?api-version=2021-02-01\" -Method PUT Refer to the “authCode” value without the double quotes (“). This will be the authorization code you will need to provide the new domain registrar to transfer your domain out. Using Cloudshell If you are having issues running the command in your local PowerShell, try using Cloud Shell on Azure Portal instead. You can access Cloud Shell on the top right navigation on Azure Portal. Once the Cloud Shell windows appear, check the top left corner of the window and make sure it says “PowerShell” and not “Bash”; otherwise, switch to “PowerShell”. Copy paste the command above and fill out the necessary information in between the “<” and “>”, then press enter. Refer to the “authCode” value without the double quotes (“). This will be the authorization code you will need to provide the new domain registrar to transfer your domain out. Transfering domain in Transfering of domain into Azure is currently not supported. Any attempts made to transfer the domain into Azure risks getting the domain into a broken state. We will not be providing support to fix domains caught in this broken state due to unsupported transfer in scenario. ","categories": [],
+ "tags": ["certsdomains"],
+ "url": "https://azure.github.io/AppService/2021/09/22/2021-Managing-ASD.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "How to Create a Web App with a Hybrid Connection",
+ "excerpt":"Hybrid Connections is a feature in App Service that provides access from your app to a TCP endpoint allowing your app to access application resources in any network that can make outbound calls to Azure over port 443. For those that want their apps in App Service to securely access other resources (typically outside of Azure - within Azure you would use Private Endpoints for example) but don’t want to set up an Azure ExpressRoute or connection via the public internet, Hybrid Connections can be an efficient and simple solution. If you have decided to go down the route of using an App Service Hybrid Connection to connect your web app in App Service to a resource in another network, this tutorial will walk you through setting up the connection and demonstrate how you would connect to a database on your local machine. If you are unfamiliar with Hybrid Connections, take a look at the documentation for Azure Relay Hybrid Connections and App Service Hybrid Connections. Prerequisites If you don’t have an Azure subscription, create a free account before you begin. For this tutorial, a Node.js app with a MySQL database will be used. It is important to review the How-To guides specifically for configuring an app on the App Service Docs site to ensure you are configuring your app appropriately based on your app’s runtime. For more information on how to build apps with a database, see the tutorials posted on the App Service Docs site. The Node.js and MySQL app used for this tutorial was created by Atauba Prince. Check out his post to learn more about how it works and how to build it from scratch. Prepare local MySQL In this step, you create a database in your local MySQL server. If you don’t have a local MySQL server, install and start MySQL. For this tutorial on Hybrid Connections, you will be connecting to your database as root. This is only being done for simplicity due to this being a Hybrid Connections focused tutorial. Connecting as root is not best practice and it’s recommended to use fine grained access control and to follow security best practices when accessing resources. Connect to local MySQL server In a terminal window, connect to your local MySQL server. mysql -u root -p If you’re prompted for a password, enter the password for the root account. If you don’t remember your root account password, see MySQL: How to Reset the Root Password. If your command runs successfully, then your MySQL server is running. If not, make sure that your local MySQL server is started by following the MySQL post-installation steps. Create a database locally At the mysql prompt, create a database. CREATE DATABASE socka; CREATE TABLE IF NOT EXISTS `players` ( `id` int(5) NOT NULL AUTO_INCREMENT, `first_name` varchar(255) NOT NULL, `last_name` varchar(255) NOT NULL, `position` varchar(255) NOT NULL, `number` int(11) NOT NULL, `image` varchar(255) NOT NULL, `user_name` varchar(20) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=1; Exit your server connection by typing quit. quit At this point, your database is fully configured and you can move on to configuring the app. Create a Node.js app locally In this step, you will create a local Node.js app to connect to your database to ensure the app and database function as intended. It is good practice to ensure your app functions locally prior to deploying to App Service. Clone the sample In a terminal window, cd to a working directory. Clone the sample repository and change to the repository root. git clone https://github.com/achowba/node-mysql-crud-app cd node-mysql-crud-app Install the required packages. npm install Configure MySQL connection In the repository root, open up the app.js file. If you are following along with the tutorial, you should not need to change anything. If you created a user to access your database, you will need to update the mysql.createConnection function with the appropriate parameters. Run the application Ensure that your MySQL server is up and running and go ahead and start the application. node app.js Check your terminal to ensure your code has no errors, then head over to your browser and open http://localhost:2000. Feel free to play around with the app by adding, editing, and deleting players. All updates that you make will be stored in the local database. Later on, when you create the app in App Service, since you will be connecting to this same database, you will see the same values. Configure the app for App Service Depending on the runtime of your app, you may need to make minor changes to ensure your App will run on App Service. For Node.js applications, review this guidance. For this tutorial, you will be modifying the database connection parameters to use app settings rather than hard-coded values. This is more secure and allows you to make updates without having to modify the source code and then wait for the app to re-build and re-deploy. Go back to the app.js file and find the mysql.createConnection function. Replace the values for the parameters with environment variables. The function should look like the below. The names for the values of the settings are arbitrary, but note what they are as you will need them a little later on. const db = mysql.createConnection({ host: process.env.DB_HOST, user: process.env.DB_USER, password: process.env.DB_PASSWORD, database: process.env.DB_NAME, port: process.env.DB_PORT }); Deploy app to Azure Create a web app At this point, you are ready to deploy the app to App Service. Ensure you are in the root directory of your app and deploy your code using the az webapp up command. Pick a unique name for your app. You will be prompted if the name you choose is already in use. Note the addition of the os-type parameter. This is included here to create the app on App Service on Windows. If you want to create it on Linux, be aware that you need to modify the host parameter in your connection string to something other than “localhost” (i.e. if using Linux, don’t use “localhost” and instead use a different host or try your machine name). On Linux, “localhost” is an entity in the hosts file of basically any Linux entity which means it never actually resolves the hybrid connection as it would on Windows. az webapp up --sku B1 --name <app-name> --os-type Windows The command may take a few minutes to complete. When finished, navigate to your App Service in the Azure portal. At this point, you will have an App Service with deployed code, however your app will not function until you connect the database. Configure database settings In App Service, you set environment variables as app settings by using the az webapp config appsettings set command (you can also do this directly in the portal). Execute the following command. Note the values for the app settings are what were previously used in the mysql.createConnection function. If you had different values, be sure to substitute them accordingly. Also be sure to fill in the placeholders for app name and resource group. These values can be found by navigating to your app in the portal or by executing the az webapp show command. az webapp config appsettings set --name <app-name> --resource-group <resource-group> --settings DB_HOST=\"localhost\" DB_DATABASE=\"socka\" DB_USERNAME=\"root\" DB_PASSWORD=\"\" DB_PORT=\"3306\" Create Hybrid Connection The final step is to create the Hybrid Connection from your App Service to your local database. Be sure to review the system requirements for the Hybrid Connection Manager to ensure your scenario is eligible for this feature. To create a Hybrid Connection, go to the Azure portal and select your app. Select Networking from the left-hand side then Hybrid connections under Outbound Traffic. Towards the top of the screen, you should see a button to “Download connection manager.” Download and install the Hybrid Connection Manager (HCM) on your local machine. You will need that after configuring the connection in the portal. To add a new Hybrid Connection, select [+] Add hybrid connection. You’ll see a list of the Hybrid Connections that you already created if you have used Hybrid Connections before. To add one or more of them to your app, select the ones you want, and then select Add selected Hybrid Connection. If you are new to Hybrid Connections, you will need to create a one that connects to the MySQL database on your local machine. To do this, select Create new hybrid connection and input the required values. For this tutorial, the values are as follows: Setting Value Hybrid connection Name (create a name) Endpoint Host localhost Endpoint Port 3306 Servicebus namespace Create new (or use an existing one if you have one already) Location (pick a location close to you, I recommend using the same one as your resource group) Name (create a name) Select Ok and your Hybrid Connection will get created and you will get re-directed to the Hybrid connections blade. You should see the Hybrid Connection you just created in the list with a status of “Not connected.” The Hybrid Connections feature requires a relay agent in the network that hosts your Hybrid Connection endpoint. That relay agent is called the Hybrid Connection Manager (what you downloaded earlier). After installing the Hybrid Connection Manager, you can run HybridConnectionManagerUi.exe to use the UI for the tool. This file is in the Hybrid Connection Manager installation directory. In Windows 10, you can also just search for Hybrid Connection Manager UI in your search box. To add one or more Hybrid Connections: Select Add a new Hybrid Connection. Sign in with your Azure account to get your Hybrid Connections available with your subscriptions. The Hybrid Connection Manager does not continue to use your Azure account beyond that. Choose a subscription. Select the Hybrid Connections that you want to relay. Select Save. You can now see the Hybrid Connections you added. You can also select the configured Hybrid Connection to see details. Under Azure Status, ensure that you are “Connected”. If you are not, open up Task Manager on your Windows machine, go to the “Services” tab, and find the HybridConnectionManager service. Right click it and select Restart. Head back over to the Hybrid Connection Manager and select Refresh to update the Azure connection status. You should now see a “Connected” status. If not, have a look at the troubleshooting info for App Service Hybrid Connections. Browse to the Azure app Browse to http://<app-name>.azurewebsites.net and see your app exactly how it was running locally, but this time with the app in Azure connected to your local database! Clean up resources In the preceding steps, you created Azure resources in a resource group. The resource group has a name like “appsvc_rg_Linux_CentralUS” depending on your location. If you keep the web app running, you will incur some ongoing costs (see App Service pricing). If you don’t expect to need these resources in the future, delete the resource group by running the following command: az group delete --no-wait ","categories": ["networking"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2021/10/15/How-to-create-a-web-app-with-a-hybrid-connection.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Introduction to Azure Resource Graph for App Service",
+ "excerpt":"Azure Resource Graph (ARG) is an Azure service that gives you the ability to query and explore your Azure resources across a given set of subscriptions so that you can effectively govern your environments, especially if you manage multiple large scale environments. Azure Resource Graph powers Azure portal’s search bar, the new browse ‘All resources’ experience, and Azure Policy’s Change history visual diff. With Azure Resource Graph, you can: Query resources with complex filtering, grouping, and sorting by resource properties Iteratively explore resources based on governance requirements Assess the impact of applying policies in a vast cloud environment Detail changes made to resource properties (preview) For more details on how to use Azure Resource Graph, see the documentation. Benefits of Azure Resource Graph Prior to Azure Resource Graph, you had access to services like Azure Resource Manager (ARM) to query your resources. Resource Manager only supports queries over basic resource fields and provides the ability for calling individual resource providers for detailed properties one resource at a time. With Azure Resource Graph, you can access these properties the resource providers return without needing to make individual calls to each resource provider. This increases investigation efficiency and simplifies escalation paths for monitoring, incident response, and investigation teams. Azure Resource Graph and App Service Limitations As of publishing this post, the following Microsoft.web resource types are supported by Azure Resource Graph: microsoft.web/apimanagementaccounts microsoft.web/apimanagementaccounts/apis microsoft.web/certificates Microsoft.Web/connectionGateways (On-premises Data Gateways) Microsoft.Web/connections (API Connections) Microsoft.Web/customApis (Logic Apps Custom Connector) Microsoft.Web/HostingEnvironments (App Service Environments) Microsoft.Web/KubeEnvironments (App Service Kubernetes Environments) Microsoft.Web/serverFarms (App Service plans) Microsoft.Web/sites (App Services) microsoft.web/sites/premieraddons Microsoft.Web/sites/slots (App Service (Slots)) Microsoft.Web/StaticSites (Static Web Apps) Microsoft.Web/WorkerApps (Container Apps) For a full list of supported resource types, review the table and resource type reference. Azure Resource Graph is currently receiving notifications for all resources tracked by ARM. If a resource or resource property changes outside of ARM (i.e. for resources not tracked by ARM), the team is currently working on onboarding these resources to enable users to have access to them using ARG. This is an ongoing process the ARG team is working through. Refer to the table and resource type reference for updates as additional resources gain support. Querying resources There are a number of quickstarts provided by the ARG team to help you get started with running queries. The Portal is a good place to start as it gives you a GUI based experience and formatted results that link to the queried resources for easy navigation. The query structure is based on Kusto Query Language (KQL). To get you started with ARG for App Service, below are basic queries to give you an idea of what you can query as well as what these queries can be used for. To see all sites across all subscriptions and resources groups: resources | where type == \"microsoft.web/sites\" Below is a sample of the output. If you have more sites in your account, they will all be listed. You can select “See details” at the end of the row to view additional information about your resources. You can query on any of the available fields for the specific resource. For example, if you want to see all your sites that are located in Central US: resources | where type == \"microsoft.web/sites\" | where location == \"centralus\" Or if you want to see all of your running sites, you can drill into the “properties” object: resources | where type == \"microsoft.web/sites\" | where properties.state == \"Running\" Many of the fields, specifically in the “properties” object, at this time will be showing as “null.” For example, if you are looking for details about the “siteConfig” object, the resource provider does not expose them at this time. This is due to these properties not being tracked by ARM and not being onboarded to ARG yet. Review the limitations to understand what properties are currently available. Additionally, you can use ARG to do analytics and create dashboards to monitor your resources. To get a sites count by region: resources | where type == \"microsoft.web/sites\" | summarize count() by location And to create a visual, you can select “Charts” under the query box and choose from the given visualization options. Below is a map of the distribution of sites in a demo account. Change detection (preview) Change detection is now in public preview for all resources that support complete mode deletion. For App Service, as of writing this article, the relevant resources that are supported include Microsoft.web/sites, Microsoft.web/sites/slots, Microsoft.Web/serverFarms as well as a couple additional resources that can be found here. With change detection, the last 14 days of change history (properties that are added, removed, or altered) for the supported resources are available and can be accessed from the APIs directly or from the Portal which provides a visual diff for each change. Change history can assist in determining causes of non-compliance and help you determine when a change was made and by who so further investigation can be conducted. For example, if you want to see when an app setting was modified, head over to the “Activity log” for your App Service and filter to your resource. Select the relevant “Operation name” and then “Change detection (preview)” in the flyout on the right. Double clicking into the operation in the list will take you to a visual diff so you can see exactly what changed in the json config of the resource. Or if you want to see when someone modifies access restrictions for an app, you can see all changes to your firewall rules: Change detection should enable you to view changes for any field in the json config of the supported resources as long as the field does not have a “null” value. A value of “null” indicates the resource provider is either not exposing this information at this time, or the field does not apply for your resource. Wrapping up The Azure Resource Graph team is continuously adding additional support for App Service to give users access to more information about their resources. Make sure to continuously check the table and resource type reference for updates as additional resource types get supported. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2021/10/29/Intro-to-Azure-Resource-Graph-for-App-Service.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "General availability of Diagnostics tools for App Service on Linux .NET core apps",
+ "excerpt":"We are pleased to announce the public availability of Diagnostic tools for App Services Linux for .NET Core apps. With this capability, we now offer built-in support for collecting deep diagnostic artifacts that can help you debug application code issues. These artifacts include memory dumps and profiler traces. These tools empower developers to diagnose a variety of .NET code scenarios on Linux including: Slow performance High memory High CPU Runtime errors and exceptions These tools enable you to self-diagnose your apps to identify if application code is contributing to the problem. This tools are enabled with the latest Azure App Service platform update (96). To check the current platform version for you linux app, please check the environment variable PLATFORM_VERSION from the kudu console for your app. Collection in Diagnose and Solve To access these new capabilities on your .NET Core apps hosted in Linux, navigate to the Diagnose and Solve Blade > Diagnostics Tools and select either Collect .NET Profiler Trace or Collect Memory Dump. Collection in Kudu The Kudu console for Linux app services has been updated to include new collection options for memory dumps and profiles on the Process Explorer page. To navigate to this new Kudu experience use the following (update <mysite> with your app name): https://<mysite>.scm.azurewebsites.net/newui to check out the new experience. When you select the Process Explorer page, you can identify the process you want to debug. Use the drop-downs to select the type of memory dump and click Collect Dump. Alternatively, you can select the length of a profile from the drop-down and click Start Profiling. Analyzing the problem With the latest version of Visual Studio, you now have the ability to open and analyze managed dumps collected on Linux and use the best in class debugging tools available in Visual Studio! Opening managed Linux Core dumps in Visual Studio Memory dumps created on Windows machines have well-known extension (*.dmp) and thus have a straightforward association with your favorite memory analysis tools. By default, core dumps produced on Linux machines are created without an extension. If your managed core dump doesn’t have an extension you can use the Open File dialogue, or drag and drop the file into your IDE, and Visual Studio will automatically identify and open it as a Linux core managed memory dump. However, if the file was renamed to include the Windows dump extension (*.dmp) then use Visual Studio’s “Open with” feature in the “Open File” dialogue box, more details here. Linux Core Dump File Summary Once opened the Managed Linux Core Dump File Summary window shows a summary and module information for the dump file, and a list of Actions you can take, this remains consistent with existing dump handling experiences in Visual Studio. To start debugging, select Debug with Managed Only from the Actions section of the summary page and start using the awesome debugging tools you have become accustomed to. You could, for example, start by reviewing the list of Threads or Tasks using the Parallel Stacks window. Or dig a bit deeper by switching between threads and examining the most interesting frames from the Calls Stacks view. You might then examine the value and state of variables using the Locals or Autos window. Essentially you get to examine every detail of the process just as if you set a breakpoint in your managed code on Linux. Diagnostics Analysis Visual Studio has also developed a set of analyzers to help identify the key signals in your memory dump that might indicate a problem with your production service. Visual Studio currently supports the following Analyzers with new and improved analysis coming in the very near future: CLR thread pool Sync over async Deadlock detection More details on running analysis against managed Linux memory dump here. Conclusion In our Azure PaaS offerings, we continue to invest in a comprehensive diagnostics experience that helps you maximize your investment in Azure PaaS. We are excited to open up new debugging opportunities for deep diagnostics artifacts that will help you analyze the health of a broad and complex range of services. ","categories": ["networking"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2021/11/01/Diagnostic-Tools-for-ASP-NET-Core-Linux-apps-are-now-publicly-available.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "How-to setup Continuous Deployment using ACR Tasks with Windows containers",
+ "excerpt":"ACR Tasks are a set of Azure CLI command features in Azure Container Registry that can help you automate container image builds. This can be integrated as part of your continuous deployment work flow to quickly update your container images. It will automate the process of building and pushing your images to your Azure Container Registry based on a set of triggers. The following tutorial walks you through setting up an ACR Task with a Windows container app in a GitHub repository that will automate a build to your App Service upon code commit. Prerequisites include having your code available in a GitHub repository, an Azure Container Registry and a Windows container App Service provisioned. Create a GitHub Access Token In order for you to create the task you will need to include a GitHub Personal Access Token (PAT) from the repository your code lives in. This PAT acts as authentication to access your repository. In the upper-right corner of your repository, click your profile photo, and click Settings. On the left-hand side menu, find and click on Developer Settings. On the following page, click on Personal access tokens. Then click Generate new token on the upper-right hand side of the page. To generate a new token you will first need to fill out the required form. Fill in the following: Note: name your token Expiration: 90 days Scope: repo Then, you can scroll to the bottom of the page and click Generate token. Copy your token on the next page and put it somewhere safe. You will not be shown this token again and we’ll need to use it when we create the task in a later step For more information on creating a Personal Access Token, see this GitHub doc. Enable Admin User in Azure Container Registry Before we create our task, we need to enable Admin user in your Container Registry. Enabling this will allow resource access when we add the webhook in a later step. Go to your Container Registry resource Go to Access Keys under Settings Go to Admin user and click on the toggle to enable Admin user Build and Deploy with ACR build Now that we have our container registry and GitHub repo setup, we can run the acr build command. This will require the use of the Azure CLI. Make sure you are on the latest version of az cli before starting. The ACR Task uses both docker build and docker push to build your images. Using this command you will create your image name and tag, which will build from your GitHub repo Dockerfile, then push it to your container registry. To run the command you will need the following: Azure Container Registry Name GitHub repository URL Open Command Prompt or Azure Cloud Shell and enter the command below. Keep in mind, this is where you will define your image name and tag. az acr build -r myacrregistry https://github.com/myusername/pdfsample.git -f PDFSample/Dockerfile --platform windows --image mypdfsample:latest Once the command is finished running you’ll notice a set of dependencies are found in the output. This includes your image and runtime information. You can now visit your container registry resource to verify that your repository has been pushed to ACR. Create the ACR Task Next, we will create our Task. This task will setup an automated trigger on code commit which will run a docker build and push the container to your registry. To run the command you will need the following: Azure Container Registry Name GitHub repository URL GitHub Personal Access Token In your Command Prompt or Azure Cloud Shell enter the command below. Keep in mind, this is where you will define the name of your task. az acr task create --registry myacrtaskregistry --name taskmypdfsample --image mypdfsample:latest --context https://github.com/myusername/pdfsample.git --file PDFSample/Dockerfile --git-access-token <access-token> --platform windows Once you create the task you’ll notice the json output has information about which triggers are enabled. By default, the base image trigger and the commit triggers are enabled. At this point you can verify that your task will run. We can run a manual test trigger by using the following command: az acr task run --registry myacrtaskregistry --name taskmypdfsample This will run a manual test to trigger your build. Since our task is configured to trigger on code commit by default, you can also test triggering the task by committing code to your GitHub repository. To verify that your tasks have run successfully use the below command az acr task list-runs --registry acrtaskreg2 --output table In this table you can verify the source of the Trigger, Platform, and Duration of the task. Now that we know our task is working, we can setup continuous deployment in our next step. Enable Continuoud deployment in your Web App At this point if you haven’t already created your Web App, you can do that now with the container you pushed previously to ACR as your image source. Once your Web App is created or if you are working with an existing Web App, you can go through the following steps to setup continuous deployment between your container registry and web app. Go to your resource and click Deployment Center under Deployment In the Settings tab, go to Continuous deployment and click On Click Save at the top of the screen Once it’s saved, a webhook will be added to your container registry resource. You can verify that it’s enabled by going to Webhooks under Services in your container registry resource. Now that your webhook is enabled, you can create a code commit to your repository which will trigger your task and run the webhook. Once the task has finished running you can click on the webhook name to view the latest push. Since your webhook is scoped to your image, it will recognize changes made to the repository with the same tag. If you use a different tag than the one that is scoped, it will not recognize the change. Another way to verify that your webhook has worked is to view your container logs in the Deployment Center. Go to the Deployment Center and view the Logs tab. Here you will see that it has downloaded a newer image and is creating the container. Once the newer image is downloaded and the container has started, you can browse to your application and view the code changes that you’ve committed from GitHub. You have now setup continuous deployment via ACR Task that triggers a build and updates your container image on code commit. Your scoped webhook to your specific image and tag will then continually update the image in App Service when a new image is recognized. Resources Creating GitHub Personal Access Token Azure Container Registry CLI Reference Docs Quick container image build Create Azure Container Registry Create Windows container Web App Create GitHub Repository ","categories": [],
+ "tags": ["windows containers","docker"],
+ "url": "https://azure.github.io/AppService/2021/11/01/how-to-setup-continuous-deployment-using-acr-tasks-with-windows-containers.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": ".NET 6 on App Service",
+ "excerpt":"We are happy to announce that App Service is rolling out day 0 support for .NET 6.0 applications across all public regions and scenarios on both Windows and Linux App Service plans. The App Service and .NET teams worked closely together to deliver this functionality on the same day as .NET 6.0 reached GA (see .NET 6.0 GA announcement). Day 0 support for .NET 6.0 GA delivers on the promise made last year during .NET 5.0 GA announcement. Joining the party this year with day 0 support are: Azure Functions where you can host serverless functions using Functions Runtime v4. Azure Static Web Apps that supports full-stack .NET 6.0 applications with Blazor WebAssembly frontends and Azure Functions APIs. To achieve day 0 support across all scenarios we continue to leverage the Early Access mechanism to seed and distribute the new runtime globally: Learn more about App Service Early Access.. The early access release will be followed by additional deployments to fully integrate the new bits across our fleet expecting to be fully done by the end of the week. If you already have an app targeting and earlier preview of .NET 6.0 on the platform, there is no need to take action as the new runtime will be picked up on the next application restart once the update is available for your app. You can trigger this manually by starting and stopping your app. If you want to learn more, be sure to checkout our session during .NET Conf 2021. Wednesday 11/10 @ 9:30am PST @bktv99 will be taking the stage to show you “6 ways to get started with .NET 6.0 and App Service”. ","categories": [],
+ "tags": ["dotnet"],
+ "url": "https://azure.github.io/AppService/2021/11/08/Dot.Net6.on.App.Service.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Upcoming Change to App Service Certificate on November 30 2021",
+ "excerpt":"Starting November 30 2021, GoDaddy will no longer be issuing certificates for the additional ‘www’ domain when validating domain ownership through HTML web page verification (AKA token verification) method or the App Service verification, which automates token verification method. This change will affect all certificates (new, renew, rekey) that require validation. This article will go through the following sections to provide you more information on how to handle your certificate renewals to avoid any possible downtime for your web app when using an App Service Certificate. Understanding different validation methods What change can mean for SSL bindings How to get certificate issued for a ‘www’ domain Understanding different validation methods You can refer to the verify domain ownership documentation for the different methods to verify domain ownership for your App Service Certificate. What change can mean for SSL bindings If you renew your certificate without a ‘www’ domain, this may affect your SSL bindings if you use an App Service Certificate for your ‘www’ domain. Let’s say you already added a ‘www’ custom domain to your web app and have already added an SSL binding with an App Service Certificate that secures a ‘www’ domain. If you renewed your certificate without a ‘www’ domain, your SSL bindings CANNOT be updated/synced with that new certificate. Thus you are risking your SSL bindings to keep using the old certificate. To avoid this issue, do NOT use HTML web page verification or App Service Verification. Use either the mail verification or the manual DNS verification instead. Refert to how to get certificate issued for a ‘www’ domain section of the article. How to get certificate issued for a ‘www’ domain You may still get a certificate with ‘www’ domain when you verify your domain ownership with DNS manual verification or mail verification. DNS manual verification You will need to create a TXT record using the token verification token in your domain name’s zone (DNS) records. Mail verification An email will be sent to the domain administrators with instructions on how to verify domain ownership for your certificate. For example, if the certificate is for domain.com, emails will be sent to: admin@domain.com administrator@domain.com hostmaster@domain.com postmaster@domain.com webmaster@domain.com ","categories": [],
+ "tags": ["certsdomains"],
+ "url": "https://azure.github.io/AppService/2021/11/22/ASC-1130-Change.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Azure App Service and Azure Functions on Azure Stack Hub 2021 Q3 Released",
+ "excerpt":"The 2021 Q3 update to Azure App Service on Azure Stack Hub is now available. This release updates the resource provider and brings the following key capabilities and fixes: Updates to App Service Tenant, Admin, Functions portals and Kudu tools. Consistent with Azure Stack Portal SDK version. Updates to core service to improve reliability and error messaging enabling easier diagnosis of common issues. Updates to the following application frameworks and tools: ASP.NET Core 3.1.16 5.0.7 6.0.0 Azul OpenJDK 8.52.0.23 11.44.13 Git 2.33.1.1 NodeJS 10.15.2 10.16.3 10.19.0 12.21.0 14.15.1 14.16.0 NPM 6.14.11 PHP 7.2.34 7.3.27 7.14.15 Tomcat 8.5.58 9.0.38 Updated Kudu to 94.30524.5227 Updates to underlying operating system of all roles: 2021-11 Cumulative Update for Windows Server 2016 for x64-based Systems (KB5007192) 2021-09 Servicing Stack Update for Windows Server 2016 for x64-based Systems (KB5005698) Defender Definition 1.353.743.0 Cumulative Updates for Windows Server are now applied to Controller roles as part of deployment and upgrade All other fixes and updates are detailed in the App Service on Azure Stack Hub 2021 Q3 Release Notes The App Service on Azure Stack Hub 2021.Q3 build number is 95.1.1.539 and requires Azure Stack Hub to be updated with 2108 prior to deployment/upgrade. Please review the release notes and all known issues prior to updating your installation of Azure App Service on Azure Stack Hub. You can download the new installer and helper scripts: Installer Helper Scripts Please read the updated documentation prior to getting started with deployment: 2021 Q3 Update Release Notes Prerequisites for deploying App Service on Azure Stack Hub Deploy the App Service Resource Provider for new deployments Update the App Service Resource Provider for updating existing deployments ","categories": [],
+ "tags": ["Azure Stack"],
+ "url": "https://azure.github.io/AppService/2021/12/10/App-Service-on-Azure-Stack-Hub-2021-Q3-Update-Released.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "App Service Environment v3 Migration Feature Public Preview",
+ "excerpt":"We are happy to announce the availability of the public preview of the App Service Environment (ASE) v3 migration feature. With this feature, you’ll be able to migrate your existing ASE as well as the apps running on that ASE to ASEv3. ASEv3 provides a number of feature differences as well as performance enhancements and potential reduced overall costs compared to previous versions. To get a complete overview on ASEv3, read the ASEv3 focused App Service Environment overview. Check out the following docs to learn more about migrating to ASEv3: Migrate to App Service Environment v3 How to Migrate to ASEv3 NOTE At this time, the public preview supports a subset of possible ASE configurations. Be sure to review the supported scenarios to see if you can migrate at this time using the feature and stay tuned for updates as we release additional capabilities. An Azure portal experience for migration will be available at the start of February, 2022. Be on the lookout for additional announcements. If your ASE isn’t supported for migration using the migration feature and your ASE isn’t listed under one of the upcoming supported scenarios, you have the option to migrate to ASEv3 manually. See the migration alternatives for more details. ","categories": ["networking"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2022/01/18/ASE-migration-feature-public-preview.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Routine Planned Maintenance Notifications for Azure App Service",
+ "excerpt":"Azure App Service is regularly updated to provide new features, new runtime versions, performance improvements, and bug fixes. One of the top feature requests from our customers is the ability to receive notifications before one of the platform updates occurs. We are happy to announce that, starting early March 2022, notifications for scheduled maintenance on Azure App Service will be available for App Service Environments V3 (ASEv3) and multi-tenant applications. With these notifications, you will be able to receive email or SMS text alerts before a platform upgrade starts, while it is in progress, and when the upgrade completes. For multi-tenant applications, we have also included a more advanced 7-day notification option allowing for more time to prepare for an upgrade. This 7-day notification will alert customers to an upcoming platform upgrade approximately 1 week before the event begins. You can also invoke Azure Functions or Logic Apps based on these notifications. This 7-day addition has been rolled out for multi-tenant environments across our regions with App Service Environments V3 coming soon. This article shows how to set up email and SMS alerts, as well as Function and Logic Apps, to consume these events. For critical security or livesite updates, we may not be able to send notifications as these updates are time sensitive. You may receive just pre-start, in-progress, and completion notifcations but not 7-day notifications if there is not sufficient lead time. Overview The maintenance notifications for App Service are surfaced as events in Azure Monitor. This means that you can set up your email address and/or SMS phone number when a notification is generated. You can also set up a trigger for your custom Azure Function or Logic App, which allows you to automatically take action to your resources. For example, you can automatically divert all the traffic from your App Service Environment in one region which will be upgraded to an App Service Environment in another region in order to avoid any potential impact. Then, you can automatically change the traffic back to normal when an upgrade completes. Please refer to the Logic App sample for automatic traffic diversion for Azure App Service for more details. Viewing upgrade notifications From the Azure portal, go to Home > Monitor > Service Health > Planned maintenance. Here you can see all active (including upcoming or in-progress) notifications for the selected subscriptions. To make it easy to find App Service upgrade events, click the Service box, check all App Service types and uncheck everything else. To see past notifications, navigate to Health history and filter Planned maintenance from the Health Event Type box. Setting up alerts Open Azure portal, sign in with your credentials. Search for the icon named Monitor and click it. If you cannot see it, click the arrow on the right to show All services, then search Monitor. In the left menu items, click Alerts. Click Service Health. Click Add service health alert at the top center. In the Condition section, choose the subscription that owns your App Service Environment(s). At the Service(s) box, choose all items starting with App Service: App Service App Service \\ Web Apps App Service (Linux) App Service (Linux) \\ Web App for Containers App Service (Linux) \\ Web App At the Region(s) box, make sure to check the regions of the App Service Environment(s). At the Event type box, check Planned maintenance. In the Actions section, click Add action groups. Click Create alert rule. Select a subscription that your App Service Environment belongs to. Choose a resource group and name an action group. Set Display name to something you can easily identify the action for (IMPORTANT: The display name will be shown in every email/SMS/post of the notifications). If you want to receive text notifications, in the Notifications section, choose Email/SMS message/Push/Voice at the Notification type. Then choose output channels you need (For example, Email or SMS.) Put email addresses or phone numbers as necessary. If you want to hook up your custom automation, in the Actions section, choose Azure Function or Logic App at the Action type. Put a name into the Name. Select your app. Press Save changes. The page will go back to the Rules management page. In the Alert rule details section, set a name. Click Save. More resources Azure Monitor documentation Common alert schema definitions Logic App sample for automatic traffic diversion for Azure App Service FAQ When do you send the upgrade notifications? For App Service Plans, the first notifications will be created about 7 days before an actual upgrade operation starts. A notification is then sent, to both ASEs and App Service Plans, 60-90 minutes before maintenance starts and then again once upgrades are underway. Once the upgrade starts, we send in-progress notifications every 12 hours until the operation completes. After it has finished, we send a notification of completion. Will the upgrade happen in exactly 7 days? The exact timing of the maintenance may vary depending on several factors, but will not be before 7 days. You will still receive a notification shortly before maintenance begins. When will 7-day notifications be available for ASE? While the 7-day notifications will not be applicable for ASEs, ASEv3 Customers will have the option to manually upgrade their resources on-demand via manual deployment preferences starting end of Q1 2023. How long do App service Upgrades take? Our typical time for completing updates worldwide is about 10 business days, which allows us to deploy during each region’s off hours and also avoid deploying to Paired Regions at the same time (for example, East US and West US). Throughout this duration, you may receive multiple in-progress notifications - this is expected. Why did I not receive a notification when my App Service was upgraded? There are two main reasons why customers may not receive notification of an upgrade. The first reason is that customers may not have followed the opt-in steps listed above. The second reason for not receiving upgrade notifications is the maintenance performed was part of a security patch or hotfix that may not have had enough lead time to provide notifications. These events should not cause any impact to current resources. Why did I not receive a 7-day advance notification before receiving in-progress notifications This upgrade was likely an unplanned maintenance event, either a hotfix or critical security patch. As Microsoft commits to ensuring security of resources, we may not always have 7 days lead time when pushing an update to address these concerns. These notifications will specify unplanned maintenance in the title. We received notification for upgrade, but we do not see Application restarts/instance movements on the App service. What did we receive an alert for? Usually, this happens when upgrades are still working their way through a given region and not yet reached your App Service. App Service follows safe deployment practices, requiring segmented deployment of upgrades. Why did I not receive a notification when my App Service was upgraded? There are two main reasons why customers may not receive notification of an upgrade. The first reason is that customers may not have followed the opt-in steps listed above. The second reason for not receiving upgrade notifications is the maintenance performed was part of a security patch or hotfix that may not have had enough lead time to provide notifications. These events should not cause any impact to current resources. Can I invoke my Azure Function when a notification comes? Yes, you can set up action to trigger your Azure Function or Logic App. It is recommended to not trigger automation based on the 7-day notiifcation as exact times may vary. The 7 day notification is for awareness and using the follow on notifications of before, during, and after completion will be more precise. Please see Logic App sample for automatic traffic diversion for Azure App Service as an example. To see the data format of the notifications, refer to Common alert schema definitions. ","categories": ["diagnostics"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2022/02/01/App-Service-Planned-Notification-Feature.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "WordPress on App Service Public Preview",
+ "excerpt":"We are happy to announce the public preview of the WordPress offering on App Service. This offering will enable you to deploy and host new WordPress websites with ease. Check out the following docs to learn more about deploying a WordPress website on AppService: Quickstart: Create a WordPress site - Azure App Service For more details refer to our blog post on MS Techcommunity Known limitations In the preview period, WP installation may take up to 10 minutes. We’re working to improve the deployment time. WordPress Linux Hosting Plans The latest update provides you with four hosting plans. Hosting plans and SKUs are detailed below: Hosting plan Web app Database (MySQL Flexible Server) Basic B1 Burstable, B1s Development S1 Burstable, B1ms Standard P1V2 Burstable, B2s Premium P1V3 Gen Purpose, D2ds_v4 Plugins The new experience ships with two pre-installed plugins, W3TC and WP Smush. W3TC plugin pre-installed. It uses Redis cache to process requests faster. WordPress pages, objects, and DB objects are cached to improve performance. WP Smush will compress images while retaining optimal quality. This will improve load times and increase WordPress performance. Changing MySQL Database Password WordPress deployment creates an AppService and a MySQL database server, under the same resource group. Login credentials for the MySQL server are generated randomly during deployment process. Database connection details are configured into WordPress via ‘Application Settings’ option available in the AppService. Note that you can retrieve the database connection details from Application Setting section in case you forgot to note them down during the creation time. First, go to the MySQL resource corresponding to your WordPress deployment, and click on ‘Reset Password’ option as shown below. Now enter the new password and click on Save. Wait until the action is completed. Then navigate to the Configuration section of your AppService and update the Application Settings corresponding to the database connection details. Once you update the values, click on Save and wait for app to get restarted. The settings are as follows DATABASE_HOST DATABASE_NAME DATABASE_USERNAME DATABASE_PASSWORD Changing WordPress Admin Password WordPress is installed on the AppService with the admin credentials provided by the user during the create process. These details are also added to the Application Settings of the AppService for initial deployment purpose. You can retrieve the credentials from here in case you forgot to note them during the creation time. Note that changing the admin credentials values in Application Settings after the deployment doesn’t update the same in WordPress, meaning that it does not actually changes the credentials. These App Settings only meant for initial deployment purpose and, also to help the users note them down for the first time. Actual update of admin credentials must be done via WordPress Admin dashboard. And this process doesn’t update the values back in the Application Settings of the AppService, as those parameters are out of sync once the app is created. Go to the admin dashboard of your WordPress site by using the following link format https://.azurewebsites.net/wp-admin. It will prompt you to login. Use the credentials you have entered during the create process to login to the dashboard. Then navigate to Users section as shown below and move your cursor over the user entry you want to make changes to and click Edit option which appears there. Set the new password using the option provided there and click on “Update Profile” to save the changes. Environment variables Application Setting Scope Value Max Description WEBSITES_CONTAINER_START_TIME_LIMIT Web app 900 - The amount of time the platform will wait (for the site to come up) before it restarts your container. WP installation takes around 5-10 mins after the AppService is deployed. By default, timeout limit for Linux AppService is 240 seconds. So, overriding this value to 900 seconds for WordPress deployments to avoid container restarts during the setup process. This is a required setting, and it is recommended to not change this value. WEBSITES_ENABLE_APP_SERVICE_STORAGE Web App true - When set to TRUE, file contents are preserved during restarts. WP_MEMORY_LIMIT WordPress 128M 512M Frontend or general wordpress PHP memory limit (per script). Can’t be more than PHP_MEMORY_LIMIT WP_MAX_MEMORY_LIMIT WordPress 256M 512M Admin dashboard PHP memory limit (per script). Generally Admin dashboard/ backend scripts takes lot of memory compared to frontend scripts. Can’t be more than PHP_MEMORY_LIMIT. PHP_MEMORY_LIMIT PHP 512M 512M Memory limits for general PHP script. It can only be decreased. FILE_UPLOADS PHP On - Can be either On or Off. Note that values are case sensitive. Enables or disables file uploads. UPLOAD_MAX_FILESIZE PHP 50M 256M\tMax file upload size limit. Can be increased up to 256M. POST_MAX_SIZE PHP 128M 256M Can be increased up to 256M. Generally should be more than UPLOAD_MAX_FILESIZE. MAX_EXECUTION_TIME PHP 120 120 Can only be decreased. Please break down the scripts if it is taking more than 120 seconds. Added to avoid bad scripts from slowing the system. MAX_INPUT_TIME PHP 120 120 Max time limit for parsing the input requests. Can only be decreased. MAX_INPUT_VARS PHP 10000 10000 - DATABASE_HOST Database - - Database host used to connect to WordPress. DATABASE_NAME Database - - Database name used to connect to WordPress. DATABASE_USERNAME Database - - Database username used to connect to WordPress. DATABASE_PASSWORD Database - - Database password used to connect to WordPress. WordPress installation simple, just provide the desired admin email, username, and password and everything else is taken care of. The latest update also brings significant performance enhancements like integrated caching and image compression. ","categories": [],
+ "tags": ["PHP"],
+ "url": "https://azure.github.io/AppService/2022/02/23/WordPress-on-App-Service-Public-Preview.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Migrating your Windows container apps from the Premium Container SKU (Preview) to Premium V3 SKU",
+ "excerpt":"The Premium Container SKU will not be moving out of preview status and will be retired on 30th June 2022. Please move your applications to the Premium V3 SKU ahead of this date if you want to continue running your Windows container workloads. The Premium V3 SKU is SLA-backed and supports Windows containers. In addition to general availabilty of support for Windows containers, Premium V3 provides enhanced performance for production applications, virtual network connectivity and new pricing options including Dev / Test, Pay-as-you-Go, 1-year and 3-year reserved instance pricing. See additional details here. If you have an application that is using the Premium Container SKU (Preview) and you would like to move to the new Premium V3 SKU, you will need to copy and re-deploy your application to a Premium V3 App Service Plan. The following is an example on how to do this using the clone functionality via Azure CLI in PowerShell. Tutorial Prerequisites This tutorial uses Az.Accounts and Az.Websites PowerShell modules. Follow the instructions here before starting to install the modules. You will need your: Subscription ID: “< subscription-id >” Resource Group: “my-pc-resource-group” Web App Name: “my-pc-web-app” Prepare your environment To get started you will first need to connect your Azure account Connect-AzAccount Then, set your subscription in PowerShell to the context of your Web App Set-AzContext -Subscription \"<subscription_id>\" Copy your Premium Container site Next, copy the Premium Container site information into a PowerShell variable. You will use this variable when you clone the app $myPCApp = Get-AzWebApp -ResourceGroupName \"my-pc-resource-group\" --Name \"my-pc-web-app\" Create your Premium V3 App Service Plan Create the new App Service Plan that your site will be cloned to. Be sure to use the ‘’–hyper-v’’ parameter so it will support your Windows container workload. Here you will also define your new resource group and app name. az appservice plan create --resource-group \"my-pv3-resource-group\" --name \"my-pv3-app-service-plan\" --hyper-v --location \"East US\" --sku p1v3 --subscription <subscription-id> Clone your Premium Container application to the new Premium V3 App Service Plan Use the following PowerShell command to clone your existing Premium Container app to your Hyper-V enabled Premium V3 App Service Plan. Here you will use the $myPCApp variable defined earlier as your -SourceWebApp value. New-AzWebApp -ResourceGroupName \"my-pv3-resource-group\" -Name \"my-pv3-app\" -Location \"East US\" -AppServicePlan \"my-pv3-app-service-plan\" -SourceWebApp $myPCApp After running this command you should now have your cloned Premium Container application in a new Premium V3 App Service Plan. Resources Configure Premium V3 tier for Azure App Service Migrate .NET apps to Azure Windows Containers on ASEv3 Windows Containers GA ","categories": [],
+ "tags": ["windows containers"],
+ "url": "https://azure.github.io/AppService/2022/03/02/Migrating-your-Windows-conainer-apps-from-Premium-Container-SKU-(Preview)-to-Premium-V3-SKU.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "App Service Web Apps, Functions, and Logic Apps (Standard) *.azurewebsites.net TLS certificate changes and what you need to know",
+ "excerpt":"This blog contains information about *.azurewebsites.net TLS certificate changes for web apps, functions, and logic apps (standard). Customers should not be impacted by this change. The scope of services affected includes web apps, functions, and logic apps (standard); logic apps (consumption) are not impacted. This change is limited to public Azure cloud; government clouds are not affected. Every web app, function, or logic app (standard) has its own default hostname that goes by “<resource-name>.azurewebsites.net” where App Service secures it with a wildcard *.azurewebsites.net TLS certificate. The current TLS certificate issued by Baltimore CyberTrust Root CA is set to expire on July 7th, 2022. Starting April 2022, App Service will begin renewing these TLS certificates and instead use certificates issued by DigiCert Global Root G2 CA. Due to the distributed asynchronous nature of the renewal process, there isn’t an exact date when the certificate will be rotated and visible to individual web apps, functions, and logic apps (standard). We expect that this change will be a non-event and will not impact customers. However, you may be impacted if an application has incorrectly taken a hard dependency on the *.azurewebsites.net TLS certificate, for example by way of “certificate pinning”. Certificate pinning is a practice where an application only allows a specific list of acceptable Certificate Authorities (CAs), public keys, thumbprints, etc. Applications should never pin to the *.azurewebsites.net TLS certificate. Applications requiring certificate stability should use custom domains in conjunction with custom TLS certificates for those domains. You can refer to the recommended best practices section of this article for more information. Recommended best practices Certificate pinning of *.azurewebsites.net TLS certificates is not recommended because the *.azurewebsites.net TLS certificate could be rotated anytime given the nature of App Service as a Platform as a Service (PaaS). In the event that the service rotates the App Service default wildcard TLS certificate, certificate pinned applications will break and disrupt the connectivity for applications that are hardcoded to a specific set of certificate attributes. The periodicity with which the *.azurewebsites.net TLS certificate is rotated is also not guaranteed since the rotation frequency can change at any time. If an application needs to rely on certificate pinning behavior, it is recommended to add a custom domain to a web app, function, or logic app (standard) and provide a custom TLS certificate for the domain which can then be relied on for certificate pinning. Note that applications which rely on certificate pinning should also not have a hard dependency on an App Service Managed Certificate. App Service Managed Certificates could be rotated anytime, leading to similar problems for applications that rely on stable certificate properties. It is best practice to provide a custom TLS certificate for applications that rely on certificate pinning. ","categories": ["certsdomains"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2022/03/22/Default-Cert-Renew.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Auto-Healing and Crash Monitoring integration with Azure Monitor",
+ "excerpt":"Auto-healing is a heavily used diagnostic feature of Azure App Service that allows end-users to configure a rich set of triggers that can be used to mitigate an app once it starts misbehaving. It not only allows you to mitigate the app from a bad situation but it also allows customers to capture diagnostic data that helps them debug the issues later. Crash Monitoring and Proactive Crash Monitoring allow end-users to effectively diagnose and debug application crashes (process exits due to unhandled exceptions) easily. One of the most asked features for both these features was the ability to view historical information about when these tools were triggered and what conditions cause them to trigger. Customers have also asked us to be able to view this information for a longer duration as by default the views available in Diagnose and Solve blade show you a maximum of 24 hours of information. Announcing Auto-healing and Crash Monitoring integration with Azure Monitor We are happy to announce the integration of App Services Auto-Healing and Crash Monitoring feature with Azure Monitor. With this integration, you can identify when an app was recycled, the number of times it was recycled and due to what condition. You can also identify application code that leads to a crash for your app. Azure Monitor integration allows you to configure alerts and actions to be taken when any of these events are triggered. You can choose for how long you want this data to be retained and use Log Analytics to query this data and setup alerts as per your requirement. Integrating Auto-Healing and Crash Monitoring with Azure Monitor To integrate Azure Monitor with these diagnostic tools, navigate to Diagnostic Settings for your App in the Azure Portal and click on Add Diagnostic Setting. Give a descriptive setting name and make sure AppServicePlatformLogs category is selected Choose the destination per your choice. In the below example, I choosing to send the data to a Log Analytics workspace and I chose an existing Log Analytics workspace in my subscription. And that’s it !!! Viewing Auto-Healing events in Log Analytics Whenever Auto-Healing takes action based on the configured triggers, the events can be viewed in AppServicePlatformLogs table in log analytics workspace. To view the data, just click on Logs for your App and run a query like below AppServicePlatformLogs | where TimeGenerated > ago(1d) | where OperationName startswith \"AutoHealing\" | project TimeGenerated, OperationName, Level, Message, _ResourceId The Message column helps identifying the action invoked and the trigger. For e.g. in the above event, we see this Worker Process successfully launched custom action ‘D:\\home\\data\\DaaS\\bin\\DaasConsole.exe’ due to ‘Total Requests’ limit The OperationName column will have one of the three values based on the action chosen in the Auto-Healing configuration. AutoHealingCustomAction AutoHealingRecycle AutoHealingLogEvent Viewing Crash Monitoring events in Log Analytics Whenever crash monitoring or proactive crash monitoring captures a memory dump or records a call-stack of the crashing thread, records will be generated in the AppServicePlatformLogs table in Log Analytics workspace. Information about the dump file and the time the dump file is copied to storage will also be logged. To view the data, just click on Logs for your App and use a query like below AppServicePlatformLogs | where TimeGenerated > ago(1d) | where OperationName =~ 'CrashMonitoring' or OperationName =~ 'ProactiveCrashMonitoring' | project TimeGenerated, OperationName, ActivityId, Level, Message, Exception, StackTrace, _ResourceId You may have to choose the ActivityId, Exception and StackTrace columns from the Columns side panel to see all the above information Configuring alerts on these Events To configure an alert, write the Log Analytics query as per your requirement and choose New Alert Rule from the ribbon and follow the rest of the configuration. For more information, refer to Create, view, and manage log alerts using Azure Monitor We hope this helps in identifying auto-healing and crash monitoring invocations easily and set up alerts around these events which will help you effectively diagnose and troubleshoot your apps hosted on App Service. Happy Debugging! Resources App Service Integration with Azure Monitor Crash Monitoring in Azure App Service Proactive Crash Monitoring in Azure App Service Announcing the New Auto Healing Experience in App Service Diagnostics Create, view, and manage log alerts using Azure Monitor ","categories": ["diagnostics"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2022/04/05/Announcing-Azure-Monitor-Integration-with-Crash-Monitoring-copy.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Public Preview: Codeless Monitoring for Windows Containers",
+ "excerpt":"We are happy to share that Auto-Instrumentation of Application Insights for Windows Container applications is now in public preview! Auto-Instrumentation allows you to monitor your applications with Application Insights without changing your code. When enabled, the App Service platform will configure and attach the agent to the application in your container. Once attached, metrics such as requests, dependencies, latency, and stack traces will flow into your Application Insights resource where you can analyze the data and set up alerts. Note: Auto-Instrumentation for Windows Containers on App Service currently supports .NET and Java applications. Node.js support is planned. For other stacks, consider adding the Application Insights SDK to your application. Enable Auto-Instrumentation You can enable Auto-Instrumentation from the Create blade, or from the Application Insights blade. Create Blade Go to the Create Web App blade Provide a name for your web app, and select Docker Container as the Publish type, and Windows as the Operating System Go to the Monitoring tab, and select Yes to enable Application Insights Go to Review + Create and click Create That’s it! Once your container is deployed, Application Insights will attach automatically and begin sending metrics. Application Insights Blade If you already have a Windows Container web app, open it in the Azure Portal and go to the Application Insights (preview) menu item. Select Turn on Application Insights Select a Location for your Application Insights resource to be created. (It’s suggested to create the resource in the same region as the Web App.) (Optional) use the language tabs at the bottom for .NET, .NET Core, and Java to configure the agent Click Apply to save your changes And you’re done! Your web app will restart and Application Insights will attach automatically to begin sending metrics. Resources Quickstart: Windows Containers on App Service Overview of Application Insights ","categories": [],
+ "tags": ["windows containers"],
+ "url": "https://azure.github.io/AppService/2022/04/11/windows-containers-app-insights-preview.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Generally available: Enhanced network security features for App Service Basic SKU",
+ "excerpt":"App Service now supports VNet integration (outbound) and private endpoints (inbound) all the way down to the Basic SKU. The App Service VNet integration feature enables your apps to access resources in or through a virtual network but doesn’t grant inbound private access to your apps. For inbound access, you need private endpoints, which allow clients located in your private network to securely access your apps over Private Link, which eliminates exposure from the public internet. With this update, you can use our lower-cost tiers and achieve the same level of security that you could previously only achieve with our high-end SKUs. Note that if you want to downgrade an existing App Service Plan and still use VNet integration, you need to be on the newer App Service footprint to ensure you’re App Service Plan supports VNet integration for Basic SKU. For more details, see the VNet integration limitations. Learn how to enable virtual network integration. Learn how to connect to a web app using an Azure Private endpoint. ","categories": ["networking"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2022/04/14/Enhanced-security-for-basic-sku.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Public preview: Networking configuration options during Web App creation in the Azure Portal",
+ "excerpt":"We are happy to announce that you can now enable Virtual Network integration as well as private endpoints for inbound access when creating Web Apps using the Azure Portal. Previously, you had to use the Azure CLI/PowerShell or ARM to configure these features when creating your apps. Web Apps can be provisioned with an inbound address that is public to the internet or isolated to an Azure virtual network. Web Apps can also be provisioned with outbound traffic that is able to reach endpoints in a virtual network, be governed by network security groups, or be restricted by virtual network routes. Use the new Networking tab to configure these features when creating your apps so you can ensure a secure configuration from the start! ","categories": ["networking"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2022/04/14/networking-tab-web-app-service-create-preview.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "gRPC support on Azure App Service",
+ "excerpt":"We are pleased to announce that gRPC is coming to Azure App Service for Linux workloads. Using gRPC, you can utilize the remote procedure call framework to streamline messages between your client and server over HTTP/2. Using gRPC protocol over HTTP/2 enables the use of features like multiplexing to send multiple parallel requests over the same connection. gRPC is currently available in EUAP with Private Preview for use with .NET Core 3.1 and .NET 6. Please visit this tutorial How-To deploy a .NET 6 gRPC app on App Service to try out gRPC on App Service today. ","categories": ["gRPC"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2022/05/23/gRPC-support-on-App-Service.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Scala on App Service",
+ "excerpt":"Scala is an object-oriented programming language that can be compiled to run on the Java Virtual Machine (JVM). Using the Java runtime allows you to integrate with the enormous Java ecosystem and execute Scala programs anywhere the JVM is available. This includes Azure App Service with the Java SE runtime. The Play Framework is a lightweight web application framework for Java and Scala that integrates all components and APIs needed for modern web application development. Follow the tutorial below to deploy a Play framework Scala app onto Azure App Service. Prerequisites To follow the steps in this tutorial you will need the following tools installed locally. (You can use either the Azure CLI or the Maven plugin. You don’t need both to complete this tutorial.) Java 11 sbt v1.3.4 or greater Maven (Or install the Azure CLI) Azure CLI (Or use Maven) To check your sbt version, enter the following in a command window: sbt sbtVersion Build and Run the Project This example Play project was created from a seed template. It includes all Play components and an Akka HTTP server. The project is also configured with filters for Cross-Site Request Forgery (CSRF) protection and security headers. To build and run the project: First clone the Scala on App Service repository with the following command: git clone https://github.com/Azure-Samples/scala-on-app-service Change directory into the example project directory: cd scala-on-app-service Build the project by running sbt run. The command builds and starts the embedded HTTP server. Since this downloads libraries and dependencies, the amount of time required depends partly on your internet connection speed. After the message Server started, ... displays, enter the following URL in a browser: http://localhost:9000. The Play application will respond with: Welcome to the Hello World Scala POC Tutorial!. Now that the application is working locally, let’s package the application into an executable .jar file that we can deploy onto Azure App Service. Assemble and Test JAR Locally Follow these steps to build a .jar file executable for a Java 11 runtime using sbt assembly. From the project root, run: sbt assembly This command produces an executable .jar file in the scala-on-app-service/target/scala-2.14/ directory. To test the app locally, run the previously created .jar file: java -jar target/scala-2.13/scala-play-example-assembly-1.0.jar The application should now be running at http://localhost:80. (Note that the port is now 80, as this is the default HTTP port expected on App Service when we deploy it in the next section.) Open the application in your browser to ensure it works locally as an executable .jar. Something interesting to note about creating an executable .jar using sbt assembly is that it will inject all necessary Scala dependencies according to the assemblyMergeStrategy defined in build.sbt. This allows a native Scala app like this one to be executed in a Java-only environment. This also means that your production environment only needs to be running Java 11 and doesn’t need any Scala runtime dependencies since they’ve all been injected into the .jar file. Deploy to Azure App Service You can deploy the .jar using either the Azure CLI or the Maven plugin. Follow the instructions below for your preferred tool. Deploy as JAR using Azure CLI To deploy with the Azure CLI, run the following command from the project root: az webapp deploy --type jar --src-path target/scala-2.13/<project-name>-assembly-<version>.jar --name <app-name> --resource-group <resource-group> Once complete, you should be able to access your Play Framework app at https://<app-name>.azurewebsites.net Deploy as JAR using Maven To use Maven, you’ll need a pom file. The last line of scala-on-app-service/build.sbt handles maven repo creation for publishing. After assembling your .jar file with sbt assembly, run the following command from the project root to generate a pom file: sbt publish Copy the newly created pom file to the project root: cp maven-repo/com/example/scala-play-example_2.13/1.0/scala-play-example_2.13-1.0.pom pom.xml Configure the webapp using the appropriate azure plugin for maven: mvn com.microsoft.azure:azure-webapp-maven-plugin:2.5.0:config Update the app name and .jar file location in the newly modified pom.xml, for example: <appName>Scala-App-Name</appName> <deployment> <resources> <resource> <directory>${project.basedir}/target/scala-2.13</directory> <includes> <include><app-name>-assembly-1.0.jar</include> </includes> </resource> </resources> </deployment> Deploy to App Service with the following command: mvn azure-webapp:deploy Update the application by running sbt assembly followed by mvn azure-webapp:deploy after making & testing changes locally. Resources Config Guide for Java on Azure App Service Akka Server Settings ","categories": ["java"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2022/05/31/scala-on-app-service.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Announcing Resiliency Score Report for Azure Web Apps",
+ "excerpt":"Resiliency Score report is a downloadable report that checks whether your Azure Web App is implementing the best practices to make it less susceptible to availability issues. The report doesn’t review your Web App’s code, instead it focuses on the recommended settings and the features available to make your App Service more resilient to failures. Currently, it’s only available for Web App (Windows) running on Standard plans or higher. More products will be included in the future. Accessing the report You can access the report through the Diagnose and solve problems blade of your Azure App Service: In the Azure Portal, click on App Services Click on any Web App (Windows) running in a Standard app service plan or higher Click on Diagnose and solve problems Click on any of the Troubleshooting categories. For these instructions we’ll use Availability and Performance In Availability and Performance look for the command bar in the center and towards the top of the blade. Then, click on the button. This will generate the report and download it after a few seconds. Report structure The report is structured in 3 main sections: Resiliency Score The score is a number between 0 and 100, where less than 59, means the Web App is rated as poor and more than 80 is rated as excellent. Each feature has different weights, so each will have a different impact on your score. A score of 100% doesn’t mean that the Web App will never be down, but rather that it has implemented 100% of our resiliency best practices. Contributing factors table This is a general overview of all the features and how well they have been implemented. If the feature is implemented but there are improvements that can be done, it will be marked as “Partially implemented”. This table also works as a Table of contents of sorts, as it has links to jump to the details on each feature. Detailed scores and instructions This section intends to explain why this feature is important for you, the current state and provide details on how to implement it. Each feature is divided in the following 4 sections: Description This is an explanation of why this feature is necessary. Status of verified Web Apps This table includes the Grade (Fail, N/A (Not Applicable) or Pass) and Comments specific to the implementation of this feature. Solution In here you can find steps to implement the solution through the Azure Portal and when available, through PowerShell and/or Azure CLI. We include the steps even if the solution is implemented already, just in case you need them to implement it on other Web Apps. More information These are links to documents where you can find more details about this feature. Learn More The Ultimate Guide to Running Healthy Apps in the Cloud Questions/Feedback If you have any questions or feedback, please reach out to our team at diagnostics@microsoft.com ","categories": ["Diagnostics"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2022/06/16/Announcing-Resiliency-Score-Report-for-Azure-Web-Apps.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Intro to Microsoft Defender for App Service",
+ "excerpt":"If you’re an Azure portal user with App Service, you’ve most likely seen the Security item in the left-hand menu. This item comes from our partners from the recently re-branded Microsoft Defender for Cloud. If you aren’t familiar with Microsoft Defender for Cloud (formerly Azure Security Center and Azure Defender), it’s a tool for security posture management and threat protection. It aggregates compliance data and continually assesses your environments to give you a summary view of your security posture and allow you to streamline security management not just for your resources in Azure, but also for your resources and environments on-premises as well as in other cloud platforms (Defender for Cloud currently supports integration with AWS and GCP). For more information about Microsoft Defender for Cloud, check out the documentation. Microsoft Defender for App Service Without enhanced security features (Free) Microsoft Defender for Cloud is offered in two modes. Without enhanced security features (Free) is enabled for free on all your Azure subscriptions when you visit the workload protection dashboard in the Azure portal for the first time, or if enabled programmatically via API. The free version will not be enabled until you complete one of those actions. Using the free mode provides the secure score and its related features: security policy, continuous security assessment, and actionable security recommendations to help you protect your Azure resources. The below screenshot is a sample of what the free version gives you. As you can see on the left-hand side, there are a number of features that aren’t selectable since they aren’t available with the free version. However, even though they are not selectable from the TOC, you can access the Regulatory Compliance and Inventory blades by clicking on the respective widgets in the dashboard. The free mode gives you access to your compliance status based on the Azure Security Benchmark. For example, the Azure Security Baseline states that sensitive data should be encrypted in transit. The below screenshot shows where this control, specifically for App Service, shows up in the Defender for Cloud compliance dashboard. The Azure Security Baseline includes standards for services other than App Service as well to give you full compliance status of your account. To track compliance with other standards, you’ll need to enable the enhanced security features. From the compliance dashboard in Defender, you’ll see exactly which benchmarks your environment fails to meet. Selecting one of the controls will show you which resources are failing the compliance check as well as in many cases give you a “Quick Fix” to make your resources compliant. Heading back to the Security blade for your App Service, after enabling Defender, and therefore the Azure Security Benchmark, under Recommendations, you’ll now see the App Service specific controls from the Azure Security Benchmark where your app fails to be compliant. If you don’t see any recommendations, your app is either fully compliant with the Azure Security Benchmark or you haven’t given the platform enough time to complete its assessment and update the portal (this can take up to 24 hours). You’ll additionally see a severity recommendation for each control based on the priority the Azure Security Benchmark, which gives you a good sense of which controls you should most likely enable. Note that if you have enabled any custom policies in Azure Policy based off of the controls associated with the Azure Security Benchmark, they won’t show up in the Recommendations or in the Defender compliance dashboard. At this time, only “built-in” policies are supported. Additionally, you won’t see any alerts under “Security incidents and alerts” in the Security blade since that is a not a feature of the free version. With enhanced security features Defender for Cloud with all enhanced security features extends the capabilities of the free mode and allows you to include workloads running in private and other public clouds, providing unified security management and threat protection across your hybrid cloud workloads. For more information on the two modes, see the enhanced security features documentation. If you choose to use the enhanced security features, Defender for Cloud offers specific plans dedicated to various Azure services including one for App Service called Microsoft Defender for App Service. In addition to the benefits you get from the enhanced security features, enabling Defender for App Service increases your security posture by assessing the resources covered by your App Service plan and generating security recommendations based on its findings. It also monitors the underlying logs and infrastructure that customers don’t typically have access to since App Service is a fully managed platform. To learn more about the benefits of Defender for App Service, see protecting your web apps and APIs. Things to consider If the built-in policies that make up the Azure Security Benchmark and other compliance standards don’t meet your compliance standards, you can create custom policies in Azure Policy. Custom policies however will not show up under the recommendations in the Security blade and in your Defender compliance dashboard. You must visit the Microsoft Defender for Cloud dashboard in the portal or enable Defender programmatically via API for it to start monitoring your resources. Even if you are just using the free version, you still need complete one of those actions to see your recommendations in the Security blade. Defender for App Service costs $15/month per instance. If cost is a limiting factor for you, take this into consideration when enabling the enhanced security features. Defender gives you the ability to select which resources you want to be in scope and therefore charged for, which can help you reduce costs as needed. If you don’t enable Defender for App Service, you can still use the free version and have access to compliance against the Azure Security Benchmark. If you choose to not enable the enhanced security features, that doesn’t mean your App Service isn’t secure or that you don’t have options to secure your apps. App Service as well as Azure have a number of built-in features and services that you can leverage to lock down and protect your apps based on your requirements. To learn more about App Service security, start with the security recommendations for App Service. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2022/06/16/Into-to-microsoft-defender-for-app-service.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Azure Policy Updates for App Service",
+ "excerpt":"Regulatory Compliance in Azure Policy provides Microsoft created and managed initiative definitions, known as built-ins, for the compliance domains and security controls related to different compliance standards. A subset of those initiatives contains compliance domains and security controls specifically for Azure App Service. You can assign the built-in initiatives to verify your compliance status against common standards or you can assign the built-ins for a control individually to help make your Azure resources compliant with a specific standard. To see the built-in policies for App Service, see Azure Policy Regulatory Compliance controls for Azure App Service. To learn more about applying and managing policies, see Tutorial: Create and manage policies to enforce compliance. Latest updates The App Service team recently underwent an effort to clean-up the App Service built-in policies. This effort included the following updates: Deprecation of policies that no longer require dedicated policy definitions to simplify overall management of policy inventory. Rename of policies to follow a standard naming convention. The naming convention is as follows: Lead with the affected service, resource type, or feature. Include “should” to explain the unsecured element (“[A] should [B]”). For example, a policy name that follows the naming convention would be “App Service apps should only be accessible over HTTPS”. Removal of Logic Apps from the scope of all App Service policy definitions. Logic Apps have their own dedicated policies. Re-scope of policies to clearly distinguish Function app policies from App Service policies. All Function app policies now include the condition {\"field\": \"kind\", \"contains\": \"functionapp\"}. All App Service policies now include the condition {\"field\": \"kind\", \"notContains\": \"functionapp\"} which scopes them to include all app types except Function apps and Logic Apps. For more information on policy conditions, see Azure Policy definition structure. Addition of App Service slots in policy’s scope where applicable. For the full list of detailed updates, see the release notes. Action needed There’s no action required if you already have the updated policies assigned to your resources. The policies updates will automatically be applied. Be sure to review your new overall compliance status as the scope of some of the policies has been modified, which means additional resources may now be in scope for policy evaluation. Deprecated policies will no longer show up in the definitions list in the Azure portal. They’ll still be available via APIs. They’ll also still be evaluated if individually assigned. You won’t receive a notification that these policies have been deprecated however you’ll see that their display names have changed to be prefixed with “[Deprecated]”. If you no longer want these policies to be evaluated, you can unassign them. If you’ve assigned any of the initiatives which include these policies, they’ll automatically be removed from the initiative and will no longer be evaluated. If you use the specific policy display names in any reporting, upstream metrics, or alerting mechanisms, you’ll need to update these values to the latest versions. Policy display name changes can be found in the release notes. What’s next? The clean-up effort is ongoing. The release notes will continue to be updated as changes are rolled out. We are continuously assessing the App Service policy inventory to ensure our built-in list includes policies that meet the latest security best practices and recommendations. We’ll also continue to add new policies to keep up with the latest App Service features. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2022/07/06/azure-policy-updates-for-app-service.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": ".NET 7 Preview 5 available on App Service",
+ "excerpt":"We are happy to announce that App Service now supports apps targeting .NET 7 Preview 5 across all public regions on both Windows and Linux App Service Plans through the App Service Early Access feature. Azure Functions has also added initial support for .NET 7 Preview 5. Any app targeting the .NET 7 on App Service during the preview stages will be automatically updated to the latest .NET 7 Preview release as newer releases become available. This update process will continue all the way up to the RC and GA releases. Self-contained .NET apps will not be auto-updated since they have no dependency on the runtime provided by App Service. Want to get started with .NET 7? Follow these guides: Download .NET 7 Get Started with .NET 7 and Visual Studio Deploy a .NET application to App Service ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2022/07/18/dotnet7_preview5.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Announcing GA: WordPress on Azure App Service",
+ "excerpt":"We are thrilled to announce that WordPress on App Service that was under public preview since February 15, 2022, is now generally available. With advanced features and revised hosting plans, you can now deploy and manage WordPress websites with ease. We have continued to make improvements in performance and security so that you can deliver a great experience to your customers. We recommend that you use Linux for your WordPress server. PHP on Windows will not be officially supported on App Service Platform after November 25, 2022. Read the full announcement at Announcing the General Availability of WordPress on Azure App Service - Microsoft Tech Community. You can go ahead and start creating a WordPress website at Create WordPress on App Service - Microsoft Azure or go to QuickStart: Create a WordPress site - Azure App Service | Microsoft Docs for a how-to guide to build your WordPress website in Azure App Service. ","categories": [],
+ "tags": ["app service","php","wordpress"],
+ "url": "https://azure.github.io/AppService/2022/08/08/Announcing-GA-WordPress-on-Azure-App-Service.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "gRPC support on App Service now in Public Preview",
+ "excerpt":"We are pleased to announce that gRPC (public preview) is now available in most regions. gRPC is supported for Linux applications using .NET Core 3.1 or .NET 6. Node support is coming soon (9/1/22). Please visit this tutorial How-To deploy a .NET 6 gRPC app on App Service to try out gRPC on App Service today. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2022/08/11/gRPC-support-on-App-Service-now-in-Public-Preview.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "A Heavy Lift: Bringing Kestrel + YARP to Azure App Services",
+ "excerpt":"In this post, we get a behind-the-scenes look at the engineering work required to change a critical platform component with code paths that are exercised billions of times a day while minimizing service disruptions and maintaining SLA for our customers. We provide a brief introduction to help cover the basics, go over motivations for doing this work, explain some of the more interesting challenges, issues, and bugs encountered along the way, and close with the results and the new customers scenarios enabled. The challenge was huge, but we’re excited about the benefits this brings to Azure App Services and our customers: Almost 80% improvement in throughput in performance tests designed to isolate the benefits. Greener Azure data centers from significantly decreased per-request CPU usage. Support for modern protocols like HTTP/3. Support for new customer scenarios such as gRPC applications, per-host cipher suite configuration, custom error pages, and more. Introduction In 2021, a group of engineers across multiple teams, including .NET and Azure, got together to transition the App Service Frontend fleet to Kestrel + YARP. As we celebrate the completion of this major lift and collaboration, we decided to write down the journey and describe some of the challenges of completing such a change to a live service, the wins we achieved, and the future work enabled by this transition. We hope you enjoy it. Azure App Service in a nutshell Azure App Service recently celebrated its 10 year anniversary (we launched it on June 7th, 2012). We are grateful and humbled by our customers who have helped us grow into a big service (affectionately called an XXL service in Azure internally, a designation only shared with 3 other services). Here are some numbers that provide a glimpse into our scale: 160B+ daily HTTP requests served by applications 14M+ host names 1.5K+ multi-tenant scale units and an additional 10K+ dedicated scale units (App Service Environments aka App Service Isolated SKU) One of the key architectural pieces of this system is our FrontEndRole. The FrontEndRole main purposes are: Receiving traffic on HTTP/HTTPS from public virtual IP addresses associated with a scale unit Terminating SSL if required Determining which set of VMs are the origin-servers for the application (called Workers) and then routing to them App Service was originally built as a Cloud Service and this role is just called FrontEndRole. With our transition to VM Scale Sets, the FrontEndRole is a separate scale set which is part of each scale unit. The original App Service FrontEndRole, which runs on Windows Server, consisted of: IIS running on HTTP.sys, both operating system components of Windows Server Application Request Routing (ARR), which does request forwarding using WinHTTP Kestrel and YARP in a nutshell The first release of .NET Core introduced the Kestrel webserver: an open-source, cross-platform, and fast webserver implementation built using modern .NET. Performance is a key focus for the .NET team, and with each .NET release, Kestrel has gotten ever faster and more full-featured. As an example, recent changes made to Kestrel include: Significant scalability improvements on many-core machines Significant HTTP/2 performance enhancements when running with many concurrent streams Support for new standards like HTTP/3 YARP (“Yet Another Reverse Proxy”) is a reverse proxy toolkit that enables building fast proxy servers using infrastructure from ASP.NET and .NET, focusing on easy customization. It is developed in the open at https://github.com/microsoft/reverse-proxy. YARP’s toolkit/extensibility model made it easy for us to incorporate our routing and TLS handling with its request forwarding capabilities. YARP includes support for modern protocols like HTTP/2 & HTTP/3, which App Service customers can now expose. In addition, being based on the fast-evolving .NET platform means that every release, Kestrel and YARP benefit from improvements up and down the .NET stack, including everything from networking libraries all the way down to JIT compiler improvements that improve the quality of generated code. For a sampling of the types of improvements that went into just the .NET 6 release in 2021, see Performance Improvements in .NET 6. Betting on Kestrel + YARP for App Service: Why? The previous FrontEndRole architecture of App Service built on IIS/HTTP.SYS has served us well, but the promise of a modern HTTP stack in Kestrel + YARP could deliver new benefits to all App Service customers. Specifically: Performance improvements, including significantly decreased per-request CPU cost and per-connection memory cost. More flexible extensibility points into SSL termination path, allowing for easier dynamic SNI host selection. Enable new customer scenarios like support for gRPC, per-host cipher suite configuration, custom error pages, and more. With all that context and motivation, the goal of the V-Team was clear: “Transition the 200K+ dedicated cores running FrontEndRole to use Kestrel + YARP (and thus move away from IIS/HTTP.SYS/ARR)” Challenge: Server Framework Diversity App Service is not the first Microsoft service to transition to Kestrel and YARP. Microsoft has already documented the journeys of Bing, Azure Active Directory (AAD), and Dynamics 365 to .NET; these efforts have proven out the stability and performance of .NET for critical service workloads. Bing.com runs on .NET Core 2.1! Azure Active Directory’s gateway is on .NET 6.0! Dynamics 365 using YARP The unique challenge that App Service adds to the mix is the diversity of server implementations. The previously mentioned Microsoft services are written by server engineers working for … Microsoft. This is definitely not the case for App Service, which enables customers to bring their own server frameworks and write their own applications with varying levels of standards compliance. Hosting customer applications brings a unique set of challenges described below. Challenge: Platform versus Organic Health Because App Service enables customers to write their own applications, the concept of “service health” is a nuanced discussion. App Service measures the health of the platform; we ensure that customers have a running VM which can connect to storage and can execute a simple canary request. But App Service cannot easily measure the organic health (HTTP request success rate) since we do not control the application. As a result, we primarily focused on platform health as our main metric. For our transition to Kestrel + YARP, we needed to broaden our measurement to include organic health. Rather than looking for an absolute bar (say >99.99% success), we needed to compare “before Kestrel + YARP” and “after Kestrel + YARP” organic success and look for anomalies that would point out potential problems. Challenge: Quick Rollback in Production With a broadened approach to assessing organic health anomalies caused by a diverse set of applications/frameworks on our platform, we required fast mechanisms to undo our Kestrel + YARP transition on a per scale-unit basis; in other words, we needed to be able to “break glass” quickly when we encountered problems and return to using IIS/HTTP.SYS. The Journey: 100% FrontEndRoles using Kestrel/YARP With all the context and challenges described, here is how the journey looked like in a picture. As you can see this journey took a lot of time. 6 months passed between the first Kestrel/YARP deployment and 100%. The Bugs Encountered We encountered multiple bugs on our journey to Kestrel + YARP. Apart from bugs in our business logic, one of the interesting classes of issue we encountered was the treatment of edge-cases in the HTTP specification. A diversity of clients hit our FrontEndRole. We need to be generous in accepting behavior that may not be exactly the HTTP spec’s letter and intent. A simple example of one of these cases is when a request has leading newline characters (CR and/or LF). Strictly speaking, this isn’t allowed, but it turns out that there are some clients that send requests that start like: \\rGET / HTTP/1.1\\r\\n ... This is a case that IIS (and some other servers) allow, but because Kestrel historically has taken a fairly strict stance, we saw its parser rejecting requests like this with a BadHttpRequestException. Working closely with the ASP.NET Core team, we were able to make Kestrel a bit more generous in what it accepts (the example above now works in Kestrel in .NET 6.0.5 and newer releases). Some other interesting issues uncovered can be found here, here and here. As a result of investigating and addressing this class of issues, we’ve made Kestrel a more capable server without compromising the core principle of security. The Payoff: Performance and New Features, Now and in the Future Now that we have moved our FrontEndRoles to Kestrel + YARP we have realized multiple benefits in production. Performance tests designed to isolate the benefits of our FrontEndRole change showed an almost 80% improvement in throughput (tested using a simple 1K helloworld response from a single dedicated worker in a test environment). App Service over-provisions FrontEndRole instances, so the realized benefit across our aggregate fleet is a large decrease in CPU% which provides more CPU headroom for the fleet. We are still in the early days of monitoring the fleet post-move; we may eventually be able to decrease our cores assigned to this role to reduce operating costs and data center energy usage. More investigation to follow. With our move to Kestrel + YARP on our FrontEndRoles, we were also able to move our Linux worker VMs to use Kestrel+YARP. This change allows us to replace nginx, commonize the codebase, and light up gRPC for our App Service Linux SKUs. gRPC support has been a popular feature request from Azure App Services users and we’re excited to add this capability. With this platform work complete we are now working on enabling two of the most frequently requested features in App Service; more news coming soon as we complete these improvements: Ability to configure custom error pages for requests that terminate on the front end (Specifically: HTTP 503, HTTP 502 and HTTP 403). Ability to specify TLS cipher suite allowed per given application. Today customers can only configure allowed cipher suites on our Isolated SKUs. A Great Partnership Once you have a live multi-tenant service running with millions of VMs globally, you learn to be very careful with how and when you advance it. That said, the innovations with Kestrel + YARP being developed by the .NET core team were just too valuable to pass up. At the same time, the .NET team would tell you the experience of supporting this migration was a whole new challenge for that team as they experienced the breadth and diversity of App Service scenarios. This was a great journey for both teams and we landed it. Now that we have this new platform in place, we look forward to continued innovation between our teams. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2022/08/16/A-Heavy-Lift.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Configure Azure Firewall with ASEv3",
+ "excerpt":"When deploying App Service Environment, one requirement you will probably want is to monitor and limit your egress traffic from the ASE. This blog post walks you through how to achieve this using Azure Firewall, this assumes you have a hub and spoke network topology in place in Azure with more than one landing zone. A full implementation example is available in Github. This GitHub repository will create all the resources discussed in this article. This article focus on the configuration of the Azure Firewall and won’t go into the step to create all the Azure resources, those are described in the provided Github repository. What the architecture look like In the provided implementation you have in place one hub and two spokes deployed in your Azure subscription. All ingress will come into Application Gateway that is deployed with a Web Application Firewall. All egress traffic will be routed to the Azure Firewall. Keep in mind, by default Azure Firewall blocks all traffic, this give you the possibility to be really granular with which flow you want to allow. In this scenario, you have two APIs, the Weather API and the Fibonacci API. The Weather API return fake data, this means it doesn’t communicate to the outside world and doesn’t need to egress to the Azure Firewall even if a User-Defined route is present. The Fibonnacci API receive a Len in parameters and calculates a Fibonnacci sequence. Before doing the calculation, the API tries to retrieve the result in Azure Redis Cache - if the result is not found the sequence is calculated, saved in the Redis Cache, and returned to the caller. The cache reside in another spoke from the ASE, this means the traffic will be routed to the Azure Firewall and filtered at this level. You will need to allow the traffic coming from the ASE to reach the subnet where the Redis Cache resides. User Defined Route on ASE Subnet To route all the egress traffic from the ASE to the Azure Firewall, a User Defined route was created. The route is associated to the subnet of the ASE. By default, we redirect all traffic to the Azure Firewall private IP address. Testing the Weather API As mentioned before, the Weather API doesn’t communicate to any other Azure resources or the Internet. It receives an HTTP request and sends fake weather data. Even with the route in place, calling the Weather API will work without any problems. We receive a status code 200 and some fake weather data as expected. Testing the Fibonacci API Let’s take a look of the JSON schema of the result returned from the Fibonacci API. You have a property called valueFromCache indicating if the value is retrieved from Redis Cache. The first time you call the API the value will be FALSE. If you call the API again with the same parameter the next time, the value should be TRUE if the saved value is not expired. Right now, the value will always be false because the egress traffic to reach the Azure Redis Cache is blocked at the Azure Firewall level. Here, call the API with the value of 5 for the len parameter. You can see the property valueFromCache return the value FALSE like expected. Now let’s try it again and the result should be the same because the traffic is blocked at the firewall level. In this case the API will always work but won’t ever be able to communicate with the cache. Adding network rule in Azure Firewall Now, before adding the network rule in Azure Firewall let’s take a look at the log. To consult the log go to your Azure Log Analytics associated with your firewall. Execute the following Kusto query in log analytics. AzureDiagnostics | where ResourceGroup == 'RG-HUB-ASE-DEMO' | where Category == 'AzureFirewallNetworkRule' | order by TimeGenerated desc This should return the cause why the ASE was not able to communicate with the Azure Redis Cache. As you can see, the TCP request from 10.1.1.254 to 11.0.1.4 was denied. The 10.1.1.254 IP corresponds to the IP address of the Fibonacci Web App, you can see here the CIDR of the subnet allocated for the App Service Environment. The 11.0.1.4 IP corresponds to the private endpoint used for the Azure Redis Cache. Now, you need to create a Network Rule in the Azure firewall to allow the communication between the ASE subnet and the private endpoint of the Azure Redis Cache. Try the Fibonacci API again Now, you should restart the Fibonacci API, if the connection to Redis cache is not possible the Fibonacci won’t try again. The first time you try with a len of 5 you will have the property valueFromCache with a value of FALSE. Now try again with the same parameter, this time you will see the result will come faster and the valueFromCache property will be TRUE. Conclusion As you can see, adding Azure Firewall in Azure App Service Environment is really easy with version 3. You can control all egress going out from your ASE with the good old hub and spoke pattern. Resources Reference application Hub and spoke network topology Azure landing zone Azure App Service Environment Application Gateway with App Service Environment Azure Firewall ","categories": ["networking"],
+ "tags": ["azure app service environment","azure firewall"],
+ "url": "https://azure.github.io/AppService/2022/08/18/Configure-Azure-Firewall-With-ASEv3.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Clojure on App Service",
+ "excerpt":"Clojure is a dynamic, general-purpose programming language from the Lisp family that runs on the Java Virtual Machine. You can build web apps in Clojure and deploy them to Azure App Service as a JAR file. This article uses an example web app written in Clojure based on the guestbook app from the Luminus framework, updated to use PostgreSQL and ready to deploy to Azure App Service in a few simple steps. The guestbook application The example application is a simple guestbook app where visitors can write messages about a site they visited. The data is stored and read from a PostgreSQL database on Azure which is created by a helper script. Prerequisites Java 8 or Java 11 (Java 11 is used as the default in this project) Leinigen An Azure subscription (free trial) Azure CLI Apache Maven Optional packages for local development Visual Studio Code with the Calva extension for Clojure Docker, used to run PostgreSQL locally in a Docker container GNU sed, used for text replacement on the command line before deploying (you can edit the file in a text/code editor though). Note that sed comes pre-installed by default in most Linux distributions, and also in Git for Windows Differences with the original guestbook application The following changes have been made from the original guestbook app: The start-app function from core.clj file has been updated to run the database migrations on the application startup, as explained in the deployment documentation. The migration file has been renamed to reflect that the file creates the guestbook table, instead of an users table. The table definition (DDL) uses the PostgreSQL syntax instead of the original (H2). There are some minor differences on the definition of primary keys and timestamps, but this is expected. Clone the repo Clone the Clojure on App Service repository with: git clone https://github.com/Azure-Samples/clojure-on-app-service.git Change directory with: cd clojure-on-app-service Build and run the application locally If you want to test this application locally before deploying to App Service, follow the steps on this section, otherwise you can skip to the Deployment on Azure section. Run a PostgreSQL database for development you can also run a PostgreSQL instance with Docker: docker run --name postgres -e POSTGRES_PASSWORD=pgpassword -d -p 5432:5432 postgres Then connect to it from another container on the same network: docker run -it --rm --network host postgres psql -h localhost -U postgres You can create a database just for the guestbook application and grant all permissions to a new user specific for the guestbook application. postgres=# create database guestbook; postgres=# create user guestbookuser with encrypted password 'guestbookpass'; postgres=# grant all privileges on database guestbook to guestbookuser; postgres=# \\q In order to tell our application where to access our database, you need to use the DATABASE_URL environment variable. In our example from the previous section, we started a container running PostgreSQL, so you’ll set the environment variable like this: Using Bash: export DATABASE_URL=\"jdbc:postgresql://localhost:5432/guestbook?user=guestbookuser&password=guestbookpass\" Using PowerShell: $env:DATABASE_URL=\"jdbc:postgresql://localhost:5432/guestbook?user=guestbookuser&password=guestbookpass\" Now, let’s make sure the database’s tables are using the most recent definition by running the following command: lein run migrate This will apply any changes to the database definition that could be pending, such as creating or modifying tables. You can use the psql utility to confirm the tables were created: docker run -it --rm --network host postgres psql -h localhost -d guestbook -U guestbookuser Password for user guestbookuser: psql (14.5 (Debian 14.5-1.pgdg110+1)) Type \"help\" for help. guestbook=> select * from guestbook; id | name | message | timestamp ----+------+---------+----------- (0 rows) guestbook=> select * from schema_migrations; id | applied | description ----------------+-------------------------+--------------------- 20190317085139 | 2022-08-24 16:28:02.528 | add-guestbook-table (1 row) guestbook=> \\q Launching the application In order to run the application locally, you’ll need to provide some configuration for your dev environment. Since each developer could have a different setup, this file is generally not checked-in with the rest of the source code. Copy the contents below and save them in a file called dev-config.edn on the root of the project: { :dev true :port 3000 } Finally, you can run the application locally with: lein run The server will start and after a while you should be able to access the application on http://localhost:3000/ and see guestbook form. If you need to use another port, you can use the PORT environment variable or pass it as a parameter in the command line as shown below: lein run -p 8000 This is just the beginning. Clojure leans towards an interactive development style, so it’s enjoyed best when using a live REPL console attached to the project. To learn more about it, see REPL Driven Development in the Luminus framework docs. Deployment on Azure Creating cloud resources This step needs to be run only once to create the required resources in Azure. If you haven’t logged in before, login into your Azure account with az login and follow the prompts. The example application has a script, create-resources.sh. The beginning of the file contains a configuration section where you can adjust some parameters such as the deployment region, and the database username and password. Set enviornment variables for the keys in the script to your desired values, or edit the script. The script will create the following resources for you: A resource group which will contain every other resource for this application A server to run a PostgreSQL instance A database in the PostgreSQL host A configuration entry to allow connections from services hosted in Azure to the database server An App Service Plan that can deploy Linux hosts A definition for the guestbook web application A configuration entry with the JDBC URL to connect from the guestbook web app to the database Run the script from Bash: ./create-resources.sh Once all the resources are created correctly, it should print All Azure resources created in the console. Configure the deployment Generate a Maven pom.xml file by running lein pom: $ lein pom Wrote .../guestbook/pom.xml Run the following command line to use a Maven plugin which will detect and configure most of the parameters required for deployment: mvn com.microsoft.azure:azure-webapp-maven-plugin:2.5.0:config The command above will prompt you to create a new Web App or to use an existing one. Choose the option to use the existing Web App that you created using the script in the previous step: $ mvn com.microsoft.azure:azure-webapp-maven-plugin:2.5.0:config [INFO] Scanning for projects... ... [INFO] Auth Type : AZURE_CLI, Auth Files : [/home/user/.azure/azureProfile.json, /home/user/.azure/accessTokens.json] ... [INFO] It may take a few minutes to load all Java Web Apps, please be patient. Java SE Web Apps in subscription My Subscription: * 1: <create> 2: guestbook-2048 (linux, java 11-java11) Please choose a Java SE Web App [<create>]: 2 <== CHOOSE TO USE EXISTING APP Please confirm webapp properties Subscription Id : (...redacted...) AppName : guestbook-2048 ResourceGroup : guestbook-2048-rg Region : westus2 PricingTier : Free_F1 OS : Linux Java : Java 11 Web server stack: Java SE Deploy to slot : false Confirm (Y/N) [Y]: Y <== CONFIRM THAT YOU WANT TO USE THE CURRENT SETTINGS [INFO] Saving configuration to pom. [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 19.405 s [INFO] Finished at: 2022-08-24T14:18:36-08:00 [INFO] ------------------------------------------------------------------------ Update the POM file The file pom.xml generated by the azure-webapp-maven-plugin needs a minor tweak for deploying an Uberjar package. You will need to edit the file pom.xml and replace the values in the following section: <deployment> <resources> <resource> <directory>${project.basedir}/target/uberjar</directory><!-- new path --> <includes> <include>guestbook.jar</include><!-- single file --> </includes> </resource> </resources> </deployment> You can perform the text replacements described above from the command line using sed, using the following commands: sed -i 's/\\/target/\\/target\\/uberjar/' pom.xml sed -i 's/\\*\\.jar/guestbook\\.jar/' pom.xml Now, generate the JAR file to be deployed: lein uberjar The output will look like the following: $ lein uberjar Compiling guestbook.config Compiling guestbook.core Compiling guestbook.db.core Compiling guestbook.env Compiling guestbook.handler Compiling guestbook.layout Compiling guestbook.middleware Compiling guestbook.middleware.formats Compiling guestbook.nrepl Compiling guestbook.routes.home Created /home/user/Projects/azure/guestbook/target/uberjar/guestbook-0.1.0-SNAPSHOT.jar Created /home/user/Projects/azure/guestbook/target/uberjar/guestbook.jar Finally, you can deploy your app to App Service: mvn azure-webapp:deploy After a few seconds, it will show the deployment status and the URL of the application $ mvn azure-webapp:deploy [INFO] Scanning for projects... [INFO] [INFO] ------------------------< guestbook:guestbook >------------------------- [INFO] Building guestbook 0.1.0-SNAPSHOT [INFO] --------------------------------[ jar ]--------------------------------- [INFO] [INFO] --- azure-webapp-maven-plugin:2.5.0:deploy (default-cli) @ guestbook --- ... [INFO] Trying to deploy artifact to guestbook-2048... [INFO] Deploying (/.../guestbook/target/uberjar/guestbook.jar)[jar] ... [INFO] Successfully deployed the artifact to https://guestbook-2048.azurewebsites.net [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 27.655 s [INFO] Finished at: 2022-08-24T23:49:22-07:00 [INFO] ------------------------------------------------------------------------ Give it a minute for the application to deploy and warm up. The first time you visit the application you may see an error 500 if the database migrations have not completed, but after refreshing the page it will work fine. If you want to delete the application and all the related resources, go to your Resource Groups in the Azure Portal, then select the appropriate guestbook resource group and delete it. ","categories": ["java"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2022/08/24/Clojure-on-AppService.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Control and automate planned maintenance for App Service Environment v3",
+ "excerpt":"Introduction This is part 1 of a 2-part series about automation for planned maintenance in App Service Environment v3. In this 2-part series, I will walk you through building a demo environment, setting up manual upgrade preference option for App Service Environment and configure automation using Logic App. In the first scenario you will deploy a simple environment, in the second scenario the environment will be more complex. The first article uses one Azure App Service Environment, which will be configured with the manual upgrade preference option. When an update is ready, an alert will be triggered that will start your Logic App. The Logic App will send you an email asking you to confirm the upgrade process. The second article uses two Azure App Service Environments in two different regions. The first App Service Environment will be for the production workload, and the second for disaster recovery purposes. The Web App will be published using Azure Front Door Standard service. When an update is ready, an alert will be triggered that will start your Logic App. The Logic App will send you an email asking you to confirm traffic redirection from the primary region to the disaster recovery region, when you accept this workflow, Logic App will redirect the traffic and start the upgrade process of your production Azure App Service Environment. Using this approach you can avoid cold start of the applications. Usually the upgrade process should be invisible for your application but if you have an application that needs more time to start or you want to decide when the upgrade should start then this approach will be perfect for you. Remember Now you can change Upgrade preference option to Manual and decide for yourself when you want to upgrade App Service Environment v3. After an update is available, you’ll have 15 days to start the upgrade process. If you don’t start the upgrade within the 15 days, the upgrade will be processed with the remaining automatic upgrades in the region. You can find more information about upgrade preference for App Service Environments v3 on this site upgrade preference for App Service Environments Requirements: Access to Azure Subscription Access to Office 365 account First scenario is organized into four steps: Deploy App Service Environment using Azure CLI Deploy sample app using Azure CLI Deploy Logic App using ARM template Create Alert in Monitor Decide where you will execute commands The best option to walk through this guide and execute commands would be to use Azure Cloud Shell with Bash environment. Azure Cloud Shell is an interactive, authenticated, browser-accessible shell for managing Azure resources. It provides the flexibility of choosing the shell experience that best suits the way you work, either Bash or PowerShell. For information on how to use Azure Cloud Shell, please visit this page Azure Cloud Shell. You can also install Azure CLI on your machine. The Azure CLI is available to install in Windows, macOS and Linux environments. It can also be run in a Docker container and Azure Cloud Shell. For information on how to install the Azure CLI, please visit this page Azure Cli If you decide to use Azure Cloud Shell, please use Bash environment. Getting Started with the first scenario Create folder for you data You can use the name below for your folder. You just need to replace asedemo with your environment name. mkdir asedemo-upgrade-preference-ase cd asedemo-upgrade-preference-ase Choosing the right subscription If you have many subscriptions you must select the subscription to which you want to deploy the resources. Using this command you can find and copy the SubscriptionId on which you want to create resources for this scenario. az account list -o table Using this command you can set a subscription to be the current active subscription. az account set -s YourSubscriptionID You can find more information about az account command on this site az account. Prepare parameters When you construct your naming convention, identify the key pieces of information that you want to reflect in the resource names. Different information is relevant for different resource types. The following sites are useful when you construct resource names Define your naming convention and Recommended abbreviations for Azure resource types You can use the names below. You just need to replace asedemo with your environment name, change SubscriptionId, EmailAddress and change LocationRegionPROD parameters. Please copy and paste your parameters to your shell. ASEsubscriptionID=11111111-1111-1111-1111-111111111111 ASENamePROD=ase-asedemo-prod-01 ASEPlanNamePROD=plan-asedemo-linux-prod-01 WEBAPPNamePROD=app-asedemo-prod-01 LocationRegionPROD=northeurope ResourceGroupNameSHARED=rg-asedemo-shared-01 ASEResourceGroupNamePROD=rg-asedemo-prod-01 VirtualNetworkNamePROD=vnet-asedemo-prod-northeurope-01 SubnetNameVnetPROD=snet-asedemo-prod-northeurope-01 VnetPrefixPROD=192.168.10.0/24 SubnetVnetPrefixPROD=192.168.10.0/24 LogicAppName=logic-asedemo-prod-01 EmailAddress=YourEmailAddress Create basic infrastructure Create Resource Groups The demo environment will be organized using two resource groups. The first resource group is for App Service Environment, the second is for Logic App Automation. az group create -l $LocationRegionPROD -n $ASEResourceGroupNamePROD az group create -l $LocationRegionPROD -n $ResourceGroupNameSHARED Create virtual network with subnet for App Service Environment A virtual network is required to create an App Service Environment. This command will create a virtual network with a subnet. az network vnet create -g $ASEResourceGroupNamePROD -n $VirtualNetworkNamePROD --address-prefix $VnetPrefixPROD --subnet-name $SubnetNameVnetPROD --subnet-prefix $SubnetVnetPrefixPROD Create App Service Environment - This process may take a while An App Service Environment is a single-tenant deployment of Azure App Service that runs in your virtual network. This command will create an App Service Environment. az appservice ase create -n $ASENamePROD -g $ASEResourceGroupNamePROD --vnet-name $VirtualNetworkNamePROD --subnet $SubnetNameVnetPROD --kind asev3 --virtual-ip-type External More information about Azure CLI for App Service Environment, visit Azure CLI ASE Create. Create App Service Plan in App Service Environment - This process may take a while Applications are hosted in App Service plans, which are created in an App Service Environment. An App Service plan is essentially a provisioning profile for an application host. This command will create an App Service plan. az appservice plan create -g $ASEResourceGroupNamePROD -n $ASEPlanNamePROD --app-service-environment $ASENamePROD --is-linux --sku I1v2 More information about Azure CLI for App Service Environment Plan, visit Azure CLI ASE Plan Create Create and deploy sample application Create a web app To create a PHP app in your App Service Environment please use this command. az webapp create -g $ASEResourceGroupNamePROD -p $ASEPlanNamePROD -n $WEBAPPNamePROD --runtime \"PHP:8.0\" Tip: To check the list of available web runtime in format Framework:Version use this command bash az webapp list-runtimes Create a variable with the URL of your website. You will use this variable later with curl command to check if your webapp is working correctly. URLofYourPrimaryWebsite=$(az webapp show --name $WEBAPPNamePROD --resource-group $ASEResourceGroupNamePROD --query defaultHostName -o tsv) You can also write down URL of your website. Create index.php file for primary website Sample code for your primary website echo '<?php echo \"Primary Website\"; ?>' > index.php Create zip file for primary website In the next step you will use ZIP Deploy to deploy the application. You need a ZIP utility for this. Fortunately, ZIP utility is pre-installed in Azure Cloud Shell. zip primaryapp.zip index.php Deploy sample app To deploy a sample application using ZIP Deploy, use this command: az webapp deployment source config-zip --resource-group $ASEResourceGroupNamePROD --name $WEBAPPNamePROD --src ./primaryapp.zip Check if your app is running Use your browser or use curl command to check if your app is working correctly. curl https://$URLofYourPrimaryWebsite Planned maintenance - Change the upgrade preference To change the Upgrade preference setting to Manual on your App Service Environment v3, use this command: az resource update --name $ASENamePROD -g $ASEResourceGroupNamePROD --resource-type \"Microsoft.Web/hostingEnvironments\" --set properties.upgradePreference=Manual Deploy Logic App This sample code is intended to show you what the Logic App can do to automate your processes. This sample Logic App shows how to use various connectors and functions that you can use to build you own Logic App in production environment. Logic App ARM Template You can use the curl command in Azure Cloud Shell to download the template_scenario_1.json file from the github repository. curl https://raw.githubusercontent.com/bmis/azure-logic-app-upgrade-preference/main/templates/template_scenario_1.json --output template_scenario_1.json You can use the code editor in Azure Cloud Shell to check the template_scenario_1.json file. code template_scenario_1.json Use ctrl + q to close code editor. Logic App ARM Parameters file The echo command will create a parameters_scenario_1.json file for you. echo '{ \"$schema\": \"https://schema.management.azure.com/schemas/2015-01-01/deploymentParameters.json#\", \"contentVersion\": \"1.0.0.0\", \"parameters\": { \"logicapp_name\": { \"value\": \"'\"$LogicAppName\"'\" }, \"SubscriptionID\": { \"value\": \"'\"$ASEsubscriptionID\"'\" }, \"ResourceGroupName\": { \"value\": \"'\"$ResourceGroupNameSHARED\"'\" }, \"connections_office365_name\": { \"value\": \"office365\" }, \"EmailAddress\": { \"value\": \"'\"$EmailAddress\"'\" } } }' > parameters_scenario_1.json You can use the code editor in Azure Cloud Shell to check parameters_scenario_1.json file. code parameters_scenario_1.json Use ctrl + q to close code editor. Deploy Logic App template To start the deployment, execute the command below. az deployment group create --name $LogicAppName --resource-group $ResourceGroupNameSHARED --template-file template_scenario_1.json --parameters parameters_scenario_1.json Authorize Office 365 connection Before you can use Office 365 connector in Logic App you must authorize Office365 connection. Open Azure portal, sign in with your credentials Go to your Logic App using for example search box at the top Click API connections and then select office365 API Connection Check the status, if status is Connected everything is ok, if it’s Unauthorized, click Edit API connection and then click Authorize button Sign in to your account Click Save button Check out the app via Logic App designer: Open Azure portal, sign in with your credentials Go to your Logic App using for example the search box at the top Click Logic app designer Familiarize yourself with the individual steps of Logic App workflow Steps in Azure Logic App: The Logic App starts when an alert occurs. You will configure the alert later in this article. The Logic App verifies that the alert applies to the Azure App Service Environment. Using functions such as split, json and action such as Filter array, the Logic App will extract from the text, the information about the name of App Service Environment to which the alert relates and the URL of the App Service Environment. In the next step, the approval email is sent. If the Approve option is selected, the Logic App will go further. If the Reject option is selected the Logic App will stop working. After selecting Approve, the Logic App will check for an upgrade for the App Service Environment. If an upgrade is available, a http request will be sent which initiates the upgrade. As well, an e-mail will be sent with the information The update of ase-asedemo-prod-01 has started If the update is not available, an e-mail will be sent with the information App Service Environment ase-asedemo-prod-01 does not currently have an upgrade available. For more information about Logic Apps, visit Logic App Overview Steps to assign an Azure role contributor to App Service Environment instance: Your Logic App will be deployed with system assigned managed identity. Before you can use your Logic App you must give your Logic App identity permission to your App Service Environment. Permissions are required to check if an update is available and to start the update process. If you want to know more about managed identities please go to this page Managed identities for Azure resources. Information about permissions that you need to configure managed identity you can find on this page Managed identities for Azure resources frequently asked questions. Step 1: Determine who needs access LogicAppIdentity=$(az resource show --name $LogicAppName --resource-group $ResourceGroupNameSHARED --resource-type \"Microsoft.Logic/workflows\" --query identity.principalId -o tsv) Step 2: Assign contributor role az role assignment create --assignee $LogicAppIdentity --role \"Contributor\" --scope /subscriptions/$ASEsubscriptionID/resourceGroups/$ASEResourceGroupNamePROD/providers/Microsoft.Web/hostingEnvironments/$ASENamePROD If you are at this stage, you have successfully created the demo environment. Now we need to create an alert that will trigger the Logic App. Create an Alert Open Azure portal, sign in with your credentials Go to Monitor using for example the search box at the top From the menu, click Service Health Click Planned maintenance Click Add service health alert In the Condition section, select Azure Subscription where you deployed your App Service Environment At the Services box, select only App Service item At the Regions box, select region of your App Service Environment At the Event types filed, select only Planned maintenance In the Action section, click Select action groups Click Create action group In the Basic section: select Subscription where you deployed you App Service Environment select Resource group with shared in the name (rg-asedemo-shared-01) Select Global Region Fill the fields Action group name and Display name for example using this name ag-asedemo - please change asedemo to your environment name In the Actions section, click Action type and select Logic App Fill the fields with information about Subscription (select Azure Subscription where you deployed your App Service Environment), Resource group (select Azure Resource group with shared in the name (rg-asedemo-shared-01)) and Select a logic app that you deployed in previous steps Enable the common alert schema Click “OK” Fill the Name filed for example using the name action-logic-asedemo-prod-01 - please change asedemo to your environment name Click Review + create Click Create Fill Alert rule details section, fill Alert rule name for example using the name alert-asedemo-planned-maintenance - please change asedemo to your environment name Make sure that checkbox Enable alert rule upon creation is selected Click Create alert rule Send test notifications As you build your automation and notification logic, you may want to test it before the actual upgrade is available. The Azure portal and rest api has the ability to send a special test upgrade available notification, which you can use to verify your automation logic. The message will be similar to the real notification, but the title will be prefixed with “[Test]” and the description will be different. You can send test notifications after you’ve configured your upgrade preference to Manual. The test notifications are sent in batches every 15 minutes. To send a special test upgrade available notification please use this command: ASEidPROD=$(az appservice ase show --name $ASENamePROD --resource-group $ASEResourceGroupNamePROD --query id --output tsv) az rest --method POST --uri \"${ASEidPROD}/testUpgradeAvailableNotification?api-version=2022-03-01\" You can also use Azure portal to send test notifications. You can find more information about test notifications on this site Send test notifications Check your mailbox and approve the upgrade process Because this is test notification your Logic app will send you an email with information that App Service Environment NameOfYourASE does not currently have an upgrade available. In a real-world scenario when an upgrade will be available your Logic App will send you information that The update of NameOfYourASE has started. Logic App run history blade Familiarize yourself with the Logic App run using Run history blade. Open Azure portal, sign in with your credentials Go to your Logic App using for example using the search box at the top Click Overview Click Run history Select last Succeeded Logic App run Familiarize yourself with the Logic App run You successfully completed the first scenario. The second scenario will be published soon. ","categories": ["networking"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2022/09/15/Configure-automation-for-upgrade-preferences-in-App-Service-Environment.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Control and automate planned maintenance for App Service Environment v3 part 2",
+ "excerpt":"Introduction This is part 2 of a 2-part series about automation for planned maintenance in App Service Environment v3. In this 2-part series, I will walk you through building a demo environment, setting up manual upgrade preference option for App Service Environment and configure automation using Logic App. In the first scenario you have deployed a simple environment, in the second scenario the environment will be more complex. The first article uses one Azure App Service Environment, which will be configured with the manual upgrade preference option. When an upgrade is ready, an alert will be triggered that will start your Logic App. The Logic App will send you an email asking you to confirm the upgrade process. The second article uses two Azure App Service Environments in two different regions. The first App Service Environment will be for the production workload, and the second for disaster recovery purposes. The Web App will be published using Azure Front Door Standard service. When an upgrade is ready, an alert will be triggered that will start your Logic App. The Logic App will send you an email asking you to confirm traffic redirection from the primary region to the disaster recovery region, when you accept this workflow, Logic App will redirect the traffic and start the upgrade process of your production Azure App Service Environment. Using this approach you can avoid cold start of the applications. Usually the upgrade process should be invisible for your application but if you have an application that needs more time to start or you want to decide when the upgrade should start then this approach will be perfect for you. Info You can also use the Logic App from this article to redirect the traffic before migrating from App Service Environment v2 to App Service Environment v3. When Logic App does not detect an available upgrade, it will send you an email asking you to confirm only the traffic redirection from the primary region to the secondary region without starting upgrade process of the App Service Environment. Another place where you can use this example to build a production version of your Logic App may be the disaster recovery procedure. Remember Now you can change Upgrade preference option to Manual and decide for yourself when you want to upgrade App Service Environment v3. After an update is available, you’ll have 15 days to start the upgrade process. If you don’t start the upgrade within the 15 days, the upgrade will be processed with the remaining automatic upgrades in the region. You can find more information about upgrade preference for App Service Environments v3 on this site upgrade preference for App Service Environments Requirements: Access to Azure Subscription Access to Office 365 account Successful completion of the first article Second scenario is organized into five steps: Deploy second App Service Environment using Azure CLI Deploy second sample app using Azure CLI Deploy Azure Front Door using CLI Deploy new version of Logic App using ARM template Change Alert rules in Monitor Decide where you will execute commands The best option to walk through this guide and execute commands would be to use Azure Cloud Shell with Bash environment. Azure Cloud Shell is an interactive, authenticated, browser-accessible shell for managing Azure resources. It provides the flexibility of choosing the shell experience that best suits the way you work, either Bash or PowerShell. For information on how to use Azure Cloud Shell, please visit this page Azure Cloud Shell. You can also install Azure CLI on your machine. The Azure CLI is available to install in Windows, macOS and Linux environments. It can also be run in a Docker container. For information on how to install the Azure CLI, please visit this page Azure CLI. If you decide to use Azure Cloud Shell, please use Bash environment. Getting Started with the second scenario Remember To deploy the second scenario, you must first go through the first scenario - Control and automate planned maintenance for App Service Environment v3 part 1. Create folder for you data You can use the name below for your folder. You just need to replace asedemo with your environment name. mkdir asedemo-upgrade-preference-ase-s2 cd asedemo-upgrade-preference-ase-s2 Choose the right subscription If you have many subscriptions you must select the subscription in which you want to deploy the resources. Using this command you can find and copy the SubscriptionId in which you want to create resources for this scenario. az account list -o table Using this command you can set a subscription to be the current active subscription. az account set -s YourSubscriptionID You can find more information about the az account command on this site az account. Prepare parameters When you construct your naming convention, identify the key pieces of information that you want to reflect in the resource names. Different information is relevant for different resource types. The following sites are useful when you construct resource names Define your naming convention and Recommended abbreviations for Azure resource types. You can use the names below. You just need to replace asedemo with your environment name (please use the same environment name that you used in scenario 1), change SubscriptionId, EmailAddress, LocationRegionPROD and change LocationRegionDR parameters. Copy and paste your parameters to your shell. ASEsubscriptionID=11111111-1111-1111-1111-111111111111 EmailAddress=YourEmailAddress LocationRegionPROD=northeurope LocationRegionDR=westeurope ASENamePROD=ase-asedemo-prod-01 ASENameDR=ase-asedemo-dr-01 ASEPlanNamePROD=plan-asedemo-linux-prod-01 ASEPlanNameDR=plan-asedemo-linux-dr-01 WEBAPPNamePROD=app-asedemo-prod-01 WEBAPPNameDR=app-asedemo-dr-01 ResourceGroupNameSHARED=rg-asedemo-shared-01 ASEResourceGroupNamePROD=rg-asedemo-prod-01 ASEResourceGroupNameDR=rg-asedemo-dr-01 VirtualNetworkNamePROD=vnet-asedemo-prod-$LocationRegionPROD-01 VirtualNetworkNameDR=vnet-asedemo-dr-$LocationRegionDR-01 SubnetNameVnetPROD=snet-asedemo-prod-$LocationRegionPROD-01 SubnetNameVnetDR=snet-asedemo-dr-$LocationRegionDR-01 VnetPrefixPROD=192.168.10.0/24 SubnetVnetPrefixPROD=192.168.10.0/24 VnetPrefixDR=192.168.100.0/24 SubnetVnetPrefixDR=192.168.100.0/24 LogicAppName=logic-asedemo-prod-02 FDName=fd-asedemo-01 OriginGroup=origin-group-asedemo OriginNamePrimary=primary OriginNameSecondary=secondary Create basic infrastructure Create Resource Group The demo environment will be organized using three resource groups. The first resource group is for App Service Environment in primary region, the second is for App Service Environment in secondary region and the third resource group is for the Logic App automation. Two resource groups were created during the first scenario, now you need to create a resource group for Azure App Service Environment is the secondary region. az group create -l $LocationRegionDR -n $ASEResourceGroupNameDR Create virtual network with subnet for App Service Environment A virtual network is required to create an App Service Environment. This command will create a virtual network with a subnet. az network vnet create -g $ASEResourceGroupNameDR -n $VirtualNetworkNameDR --address-prefix $VnetPrefixDR --subnet-name $SubnetNameVnetDR --subnet-prefix $SubnetVnetPrefixDR Create App Service Environment - this process may take a while An App Service Environment is a single-tenant deployment of Azure App Service that runs in your virtual network. This command will create an App Service Environment. az appservice ase create -n $ASENameDR -g $ASEResourceGroupNameDR --vnet-name $VirtualNetworkNameDR --subnet $SubnetNameVnetDR --kind asev3 --virtual-ip-type External For more information about Azure CLI for App Service Environment, visit Azure CLI ASE Create. Create App Service Plan in App Service Environment - this process may take a while Applications are hosted in App Service plans, which are created in an App Service Environment. An App Service plan is essentially a provisioning profile for an application host. This command will create an App Service plan. az appservice plan create -g $ASEResourceGroupNameDR -n $ASEPlanNameDR --app-service-environment $ASENameDR --is-linux --sku I1v2 For more information about Azure CLI for App Service Environment Plan, visit Azure CLI ASE Plan Create Create and deploy sample application Create a web app To create a PHP app in your App Service Environment, use this command. az webapp create -g $ASEResourceGroupNameDR -p $ASEPlanNameDR -n $WEBAPPNameDR --runtime \"PHP:8.0\" Tip: To check the list of available runtimes in format Framework:Version, use the command az webapp list-runtimes. Create variables with the URLs of your websites. You will use these variables later with the curl command to check if your websites is working correctly. URLofYourPrimaryWebsite=$(az webapp show --name $WEBAPPNamePROD --resource-group $ASEResourceGroupNamePROD --query defaultHostName -o tsv) URLofYourSecondaryWebsite=$(az webapp show --name $WEBAPPNameDR --resource-group $ASEResourceGroupNameDR --query defaultHostName -o tsv) You can also write down the URL of your websites. Create index.php file for primary website Sample code for your secondary website: echo '<?php echo \"Secondary Website\"; ?>' > index.php Create zip file for primary website In the next step you will use ZIP Deploy to deploy the application. You need a ZIP utility for this. Fortunately, ZIP utility is pre-installed in Azure Cloud Shell. zip secondaryapp.zip index.php Deploy sample app To deploy a sample application using ZIP Deploy, use this command: az webapp deployment source config-zip --resource-group $ASEResourceGroupNamePROD --name $WEBAPPNamePROD --src ./secondaryapp.zip Check if your app is running Use your browser or use curl command to check if your secondary app is working correctly. curl https://$URLofYourSecondaryWebsite Planned maintenance - Change the upgrade preference To change the Upgrade preference setting to Manual on your App Service Environment v3, use this command: az resource update --name $ASENameDR -g $ASEResourceGroupNameDR --resource-type \"Microsoft.Web/hostingEnvironments\" --set properties.upgradePreference=Manual Deploy Azure Front Door Create Azure Front Door profile Run az afd profile create to create an Azure Front Door profile. az afd profile create \\ --profile-name $FDName \\ --resource-group $ResourceGroupNameSHARED \\ --sku Standard_AzureFrontDoor Add an endpoint Run az afd endpoint create to create an endpoint in your profile. az afd endpoint create \\ --resource-group $ResourceGroupNameSHARED \\ --endpoint-name endpoint-$FDName \\ --profile-name $FDName \\ --enabled-state Enabled Create a variable with the URL of your Azure Front Door endpoint. You will use this variable later with the curl command to check if your Azure Front Door endpoint is working correctly. URLofYourFrontDoorEndpoint=$(az afd endpoint show \\ --resource-group $ResourceGroupNameSHARED \\ --profile-name $FDName \\ --endpoint-name endpoint-$FDName \\ --query hostName -o tsv) You can also write down the URL of your Azure Front Door endpoint. Create an origin group Run az afd origin-group create to create an origin group that contains your two web apps. az afd origin-group create \\ --resource-group $ResourceGroupNameSHARED \\ --origin-group-name $OriginGroup \\ --profile-name $FDName \\ --probe-request-type GET \\ --probe-protocol Https \\ --probe-interval-in-seconds 60 \\ --probe-path / \\ --sample-size 4 \\ --successful-samples-required 3 \\ --additional-latency-in-milliseconds 50 Add an origin to the group - primary website Run az afd origin create to add an origin to your origin group. az afd origin create \\ --resource-group $ResourceGroupNameSHARED \\ --host-name $URLofYourPrimaryWebsite \\ --profile-name $FDName \\ --origin-group-name $OriginGroup \\ --origin-name primary \\ --origin-host-header $URLofYourPrimaryWebsite \\ --priority 1 \\ --weight 1000 \\ --enabled-state Enabled \\ --http-port 80 \\ --https-port 443 Repeat this step and add your second origin - secondary website. az afd origin create \\ --resource-group $ResourceGroupNameSHARED \\ --host-name $URLofYourSecondaryWebsite \\ --profile-name $FDName \\ --origin-group-name $OriginGroup \\ --origin-name secondary \\ --origin-host-header $URLofYourSecondaryWebsite \\ --priority 2 \\ --weight 1000 \\ --enabled-state Enabled \\ --http-port 80 \\ --https-port 443 Add a route Run az afd route create to map your endpoint to the origin group. This route forwards requests from the endpoint to your origin group. az afd route create \\ --resource-group $ResourceGroupNameSHARED \\ --profile-name $FDName \\ --endpoint-name endpoint-$FDName \\ --forwarding-protocol MatchRequest \\ --route-name route \\ --https-redirect Enabled \\ --origin-group $OriginGroup \\ --supported-protocols Http Https \\ --link-to-default-domain Enabled For more information about Azure CLI for Azure Front Door, visit Front Door CLI. In a production environment you will probably need to implement a WAF policy for you application. For more information about Azure CLI for Azure Front Door WAF Policy, visit Front Door WAF Policy. Check if your Azure Front Door Endpoint is running - this process may take a while Use your browser or use curl command to check if your app is working correctly. curl https://$URLofYourFrontDoorEndpoint Deploy Logic App This sample code is intended to show you what the Logic App can do to automate your processes. This sample Logic App shows how to use various connectors and functions to build you own Logic App in a production environment. Logic App ARM Template You can use the curl command in Azure Cloud Shell to download the template_scenario_2.json file from the GitHub repository. curl https://raw.githubusercontent.com/bmis/azure-logic-app-upgrade-preference/main/templates/template_scenario_2.json --output template_scenario_2.json You can use the code editor in Azure Cloud Shell to check the template_scenario_2.json file. code template_scenario_2.json Use ctrl + q to close code editor. Logic App ARM Parameters file The echo command will create a parameters_scenario_2.json file for you. echo '{ \"$schema\": \"https://schema.management.azure.com/schemas/2015-01-01/deploymentParameters.json#\", \"contentVersion\": \"1.0.0.0\", \"parameters\": { \"logicapp_name\": { \"value\": \"'\"$LogicAppName\"'\" }, \"SubscriptionID\": { \"value\": \"'\"$ASEsubscriptionID\"'\" }, \"ResourceGroupName\": { \"value\": \"'\"$ResourceGroupNameSHARED\"'\" }, \"webapp_name_primary_region\": { \"value\": \"'\"$URLofYourPrimaryWebsite\"'\" }, \"webapp_name_secondary_region\": { \"value\": \"'\"$URLofYourSecondaryWebsite\"'\" }, \"ase_name_primary_region\": { \"value\": \"'\"$ASENamePROD\"'\" }, \"ase_name_secondary_region\": { \"value\": \"'\"$ASENameDR\"'\" }, \"frontdoor_name\": { \"value\": \"'\"$FDName\"'\" }, \"frontdoor_OriginGroup_name\": { \"value\": \"'\"$OriginGroup\"'\" }, \"frontdoor_OriginNamePrimary\": { \"value\": \"'\"$OriginNamePrimary\"'\" }, \"frontdoor_OriginNameSecondary\": { \"value\": \"'\"$OriginNameSecondary\"'\" }, \"connections_office365_name\": { \"value\": \"office365\" }, \"EmailAddress\": { \"value\": \"'\"$EmailAddress\"'\" } } }' > parameters_scenario_2.json You can use the code editor in Azure Cloud Shell to check parameters_scenario_2.json file. code parameters_scenario_2.json Use ctrl + q to close code editor. Deploy Logic App template To start the deployment, execute the command below. az deployment group create --name $LogicAppName --resource-group $ResourceGroupNameSHARED --template-file template_scenario_2.json --parameters parameters_scenario_2.json Authorize Office 365 connection Before you can use the Office 365 connector in your Logic App you must authorize the Office365 connection. Open Azure portal, sign in with your credentials Go to your Logic App using for example the search box at the top, search for logic-asedemo-prod-02 - change asedemo to your environment name Click API connections and then select office365 API Connection Check the status, if status is Connected everything is ok, if it’s Unauthorized, click Edit API connection and then click Authorize Sign in to your account Click Save Check out the app via Logic App designer: Open Azure portal, sign in with your credentials Go to your Logic App using for example the search box at the top, search for logic-asedemo-prod-02 - change asedemo to your environment name Click Logic app designer Familiarize yourself with the individual steps of the Logic App workflow Steps in Azure Logic App: The Logic App starts when an alert occurs. You will configure the alert later in this article. The Logic App verifies that the alert applies to the Azure App Service Environment. Using functions such as split, json and action such as Filter array, the Logic App will extract from the text, the information about the name of App Service Environment to which the alert relates and the URL of the App Service Environment. In the next step, the approval email is sent. If the Approve option is selected, the Logic App will go further. If the Reject option is selected the Logic App will send second approval email, more information about this in point 8. After selecting Approve, the Logic App will check for an upgrade for the App Service Environment. If an upgrade is available, a http requests will be sent which redirect the traffic from the primary region to the secondary region and initiates the upgrade. As well, an e-mail will be sent with the information that the traffic has been redirected and the upgrade has started. If the upgrade is not available, the second approval email is sent. If the Approve option is selected, the Logic App will continue. If the Reject option is selected the Logic App will stop working. After selecting Approve, the Logic App will only redirect the traffic from the primary region to the secondary region without starting upgrade process of App Service Environment. As well, an e-mail will be sent with the information that traffic has been redirected. For more information about Logic Apps, visit Logic App Overview. Steps to assign a contibutor RBAC role to App Service Environment instance: Your Logic App will be deployed with system assigned managed identity. Before you can use your Logic App you must give your Logic App identity permission to your App Service Environment and Azure Front Door. Permissions are required to: Checking if an upgrade is available Starting the upgrade process Redirect traffic from the primary region to the secondary region If you want to know more about managed identities please go to this page Managed identities for Azure resources. Information about permissions that you need to configure managed identity can be found on this page Managed identities for Azure resources frequently asked questions. Step 1: Determine who needs access LogicAppIdentity=$(az resource show --name $LogicAppName --resource-group $ResourceGroupNameSHARED --resource-type \"Microsoft.Logic/workflows\" --query identity.principalId -o tsv) Step 2: Assign contributor role az role assignment create --assignee $LogicAppIdentity --role \"Contributor\" --scope /subscriptions/$ASEsubscriptionID/resourceGroups/$ASEResourceGroupNamePROD/providers/Microsoft.Web/hostingEnvironments/$ASENamePROD az role assignment create --assignee $LogicAppIdentity --role \"Contributor\" --scope /subscriptions/$ASEsubscriptionID/resourceGroups/$ASEResourceGroupNameDR/providers/Microsoft.Web/hostingEnvironments/$ASENameDR az role assignment create --assignee $LogicAppIdentity --role \"Contributor\" --scope /subscriptions/$ASEsubscriptionID/resourceGroups/$ResourceGroupNameSHARED/providers/Microsoft.Cdn/profiles/$FDName If you are at this stage, you have successfully created the demo environment. Now you need to change an alert that will trigger the new Logic App. Change an Alert Open Azure portal, sign in with your credentials. Go to Monitor using for example the search box at the top. From the menu, click Alerts. Click Alert rules. Search for your alert alert-asedemo-planned-maintenance - please change asedemo to your environment name, open the alert rules. Click Edit button. In the Action section, click name of your Action group name ag-asedemo - please change asedemo to your environment name. In the Action section, change Selected logic app to you new Logic App using edit button. In field Select a logic app choose your new Logic App with name logic-asedemo-prod-02 - please change asedemo to your environment name. Click OK. Click Save changes. Send test notifications As you build your automation and notification logic, you may want to test it before the actual upgrade is available. The Azure portal and rest api has the ability to send a special test upgrade available notification, which you can use to verify your automation logic. The message will be similar to the real notification, but the title will be prefixed with “[Test]” and the description will be different. You can send test notifications after you’ve configured your upgrade preference to Manual. The test notifications are sent in batches every 15 minutes. To send a special test upgrade available notification, use this command: ASEidPROD=$(az appservice ase show --name $ASENamePROD --resource-group $ASEResourceGroupNamePROD --query id --output tsv) az rest --method POST --uri \"${ASEidPROD}/testUpgradeAvailableNotification?api-version=2022-03-01\" You can also use Azure portal to send test notifications. You can find more information about test notifications at Send test notifications. Check your mailbox and approve the redirection traffic from the primary region to the secondary region and upgrade process Because this is a test notification your Logic App will send you a second email asking you to confirm only the traffic redirection. Information from email App Service Environment NameOfYourASE does not currently have an upgrade available but you can redirect the traffic without upgrade using approve button. In a real-world scenario when an upgrade will be available your Logic App will send you information that The traffic from NameOfYourWebAppPrimaryRegion to the NameOfYourWebAppSecondaryRegion has been redirected and the upgrade of NameOfYourASE has started. Tip: You can also send a test notification from the App Service Environment in the second region, the Logic App will redirect traffic from the second region to the primary region. Logic App run history blade Familiarize yourself with the Logic App run using Run history blade. Open Azure portal, sign in with your credentials. Go to your Logic App using for example the search box at the top, search for logic-asedemo-prod-02 - change asedemo to your environment name. Click Overview. Click Run history. Select last Succeeded Logic App run. Familiarize yourself with the Logic App run. You successfully completed the second scenario. ","categories": ["networking"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2022/10/07/Configure-automation-for-upgrade-preferences-in-App-Service-Environment-part2.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Public Preview: Disabling Weaker TLS Cipher Suites for Web Apps on Multi-tenant Premium App Service Plans",
+ "excerpt":"For a few years, the only way to disable weaker TLS Cipher Suites for web apps is to host these web apps in an App Service Environment (ASE). The recent update to the App Service front-ends mentioned earlier has allowed the capability to bring this type of TLS cipher suite customization to customers running on the public multi-tenant footprint. We are excited to announce a public preview of the minimum TLS cipher suite feature that allows web apps in multi-tenant premium App Service Plans to disable weaker cipher suites! This feature enables our security conscious customers to trim off older cipher suites that the App Service platform supports for client compatibility. What are cipher suites and how do they work on App Service? A cipher suite is a set of instructions that contains algorithms and protocols to help secure network connections between clients and servers. By default, the front-end’s OS would pick the most secure cipher suite that is supported by both the front-end and the client. However, if the client only supports weak cipher suites, then the front-end’s OS would end up picking a weak cipher suite that is supported by them both. If a customer’s organization has restrictions on what cipher suites are not be allowed, they may update their web app’s minimum TLS cipher suite property to ensure that the weaker cipher suites would be disabled for their web app. The next part of the article will go through the new minimum TLS cipher suite feature that is currently in public preview. Minimum TLS Cipher Suite Feature The minimum TLS cipher suite feature comes with a pre-determined list of cipher suites that cannot be reordered nor reprioritized. Since the service is already using the ideal priority order, it is not recommended for customers to reprioritize the the cipher suite order. Customers can potentially leave their web apps exposed if weaker cipher suites are prioritized over the stronger ones. Customers also cannot add newer or different cipher suites to the list of supported cipher suites. When a minimum cipher suite is selected, all the cipher suites that are less secure than the selected minimum one would be disabled for the web app. There is no support to make exceptions and to disable only some of the cipher suites that are weaker than the selected minimum cipher suite. What cipher suites are supported and how are they prioritized? Refer to below for the list of supported cipher suites. These cipher suites are listed in order from most secure to the least secure. The service may update the list of supported cipher suite later on, though not very frequently. TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA How to disable weaker cipher suites? Minimum TLS cipher suite is a property that resides in the site’s config and customers can make changes to disable weaker cipher suites by updating the site config through API calls. The minimum TLS cipher suite feature is currently not yet supported on the Azure Portal. Sample API call This part of the article will show an example on how to select a minimum TLS cipher suite in order to disable weaker cipher suites. Let’s say, based from the list of supported TLS cipher suites, we would like to disable all the cipher suites that are weaker than TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA. In order to do this, we can call the Update Config API to set the property minTlsCipherSuite to TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA. Refer to the sample API call below. Take note that the API parameter for minTlsCipherSuite is case sensitive. PATCH https://management.azure.com/subscriptions/<subscriptionId>/resourceGroups/<resourceGroup>/providers/Microsoft.Web/sites/<siteName>/config/web?api-version=2022-03-01 { \"properties\": { \"minTlsCipherSuite\": \"TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA\" } } After successfully updating the site config, we will see the value of the property minTlsCipherSuite change to the selected cipher suite, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA from the example above. We will also see the value of the property supportedTlsCipherSuites show a list of all the cipher suites that are enabled for the web app. In this case, the cipher suites that are weaker than the selected minimum cipher suite, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, will not show up in the supportedTlsCipherSuites property because they have been disabled for the web app. What is the default behavior? By default, without making any changes to the minimum TLS cipher suite property, the web app will support all the cipher suites the front-end supports. The minTlsCipherSuite property would be null and the supportedTlsCipherSuites property would also be null; this just means that the web app will allow all the supported cipher suites as the default behavior. ","categories": ["security"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2022/10/11/Public-preview-min-tls-cipher-suite.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "WordPress on Azure App Service supports Azure Front Door Integration",
+ "excerpt":"We are happy to announce the preview of WordPress on Azure App Service powered by Azure Front Door which enables faster page loads, enhanced security, and increased reliability for your global apps with no configuration or additional code required. This integration help improve the site performance by delivering your content using Microsoft’s global edge network with hundreds of global and local points of presence. Access to the static and dynamic content of your WordPress application is accelerated by caching static content at the edge server and using split TCP method to reduce connection establishment time among others. Try out the feature from Marketplace offering For more details on configuring WordPress site with AFD, refer to AFD integration with WordPress on Azure App Service. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2022/10/12/Announcing-Preview-of-Azure-Front-Door-integration-with-Azure-App-Service.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Go available on App Service",
+ "excerpt":"We are happy to announce that App Service now supports apps targeting Go 1.18 and 1.19 across all public regions on Linux App Service Plans through the App Service Early Access feature. By introducing native support for Go on App Services, we are making one of the top 10 best loved web app development languages available for our developers. Support for Go is being added as an Experimental feature. Experimental features are work in progress and can radically change or completely disappear at any time. You can use it if you’re an early adopter, see something useful to you, and would like to help test the feature. Want to get started with Go? Follow these guides: Download Go Get Started with Go on App Services Use websockets with Go ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2022/10/12/Go-on-AppService.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Node 18, PHP 8.1 and Python 3.10 now available on App Service",
+ "excerpt":"We are happy to announce that App Service now supports apps targeting Node 18, PHP 8.1 and Python 3.10 across all public regions on Linux App Service Plans through the App Service Early Access feature. Want to get started with building apps on Node, PHP and Python? Follow these guides: Create a Node.js web app in Azure Deploy a Node.js + MongoDB web app to Azure Create a PHP web app in Azure App Service Tutorial: Build a PHP and MySQL app in Azure App Service Quickstart: Deploy a Python (Django or Flask) web app to Azure App Service Deploy a Python (Django or Flask) web app with PostgreSQL in Azure ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2022/10/12/New-Language-Stacks-available-on-AppService.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "WebSockets Available on App Service Free Tier",
+ "excerpt":"App Service free SKU has been around for over 10 years, and we continue to improve on it with every release. Today, we are pleased to announce that App Service Linux Free SKU now supports up to 5 WebSocket connections. For additional information, check out the Built-in Linux Containers FAQs on WebSockets. To get started building WebSockets Applications on App Service Linux, check out our tutorials ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2022/10/28/WebSockets-Available-on-Free-Tier.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Azure App Service and Azure Functions on Azure Stack Hub 2022 H1 Released",
+ "excerpt":"The 2022 H1 update to Azure App Service on Azure Stack Hub is now available. This release is a major update in terms of underlying infrastructure and topology. We highly recommend operators read through the release notes for further details and review the operational documentation in order to be aware of all changes. What’s New? All roles are now powered by Windows Server 2022 Datacenter. Administrators can isolate the platform image for use by App Service on Azure Stack Hub, by setting the SKU to AppService. Networking design update for all worker virtual machine scale sets, addressing customers faced with SNAT port exhaustion issues. Increase number of outbound address for all applications. Administrators can set a three character deployment prefix for the individual instances in each Virtual Machine Scale Set that are deployed as part of the App Service on Azure Stack Hub Resource provider. Deployment Center is enabled for tenants, replacing the Deployment Options experience - IMPORTANT - Operators will need to reconfigure their deployment sources as the redirect urls have changed with this update. Updates to App Service Tenant, Admin, Functions portals and Kudu tools. Consistent with Azure Stack Portal SDK version. Updates to core service to improve reliability and error messaging enabling easier diagnosis of common issues. Updates to the following application frameworks and tools: Azure Functions runtime to v1.0.13154 ASP.NET Core 3.1.18 3.1.23 6.0.2 6.0.3 Eclipse Temurin OpenJDK 8 8u302 8u312 8u322 Microsoft OpenJDK 11 11.0.12.7.1 11.0.13.8 11.0.14.1 17.0.1.12 17.0.2.8 MSBuild 16.7.0 17.1.0 NodeJS 14.18.1 16.9.1 16.13.0 NPM 6.14.15 7.21.1 8.1.0 Tomcat 8.5.69 8.5.72 8.5.78 9.0.52 9.0.54 9.0.62 10.0.12 10.0.20 Updated Kudu to 97.40427.5713 Updates to underlying operating system of all roles: 2022-09 Cumulative Update for Windows Server 2022 for x64-based Systems (KB5017316) Defender Definition 1.373,353.0 Cumulative Updates for Windows Server are now applied to Controller roles as part of deployment and upgrade All other fixes and updates are detailed in the App Service on Azure Stack Hub 2022 H2 Release Notes The App Service on Azure Stack Hub 2022.H! build number is 98.0.1.699 and requires Azure Stack Hub to be updated with 1.2108.2.127 or 1.2206.2.52 prior to deployment/upgrade. Please review the release notes and all known issues prior to updating your installation of Azure App Service on Azure Stack Hub. You can download the new installer and helper scripts: You can download the new installer and helper scripts: Installer Helper Scripts Please read the updated documentation prior to getting started with deployment: 2022 H1 Update Release Notes Prerequisites for deploying App Service on Azure Stack Hub Deploy the App Service Resource Provider for new deployments Update the App Service Resource Provider for updating existing deployments Configure deployment sources for App Service on Azure Stack Hub ","categories": [],
+ "tags": ["Azure Stack"],
+ "url": "https://azure.github.io/AppService/2022/11/02/App-Service-on-Azure-Stack-Hub-2022-H1-Released.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": ".NET 7 GA available on App Service",
+ "excerpt":"We have completed the initial rollout for .NET 7 GA support on App Service. Like in previous years we are using the App Service Early Access feature to enable day-0 support on the platform across all public regions on both Windows and Linux App Service Plans. The early access release will be followed by additional deployments to fully integrate the new bits across our fleet expecting to be fully done by the end of the week. If you already have an app targeting and earlier preview of .NET 7.0 on the platform, there is no need to take action as the new runtime will be picked up on the next application restart once the update is available for your app. You can trigger this manually by starting and stopping your app. Self-contained .NET apps will not be auto-updated since they have no dependency on the runtime provided by App Service. Azure Functions and Azure Static Webapps are also enabling .NET 7 workloads across their scenarios. If you want to learn more, be sure to checkout our session during .NET Conf 2022: Tuesday 11/09 @ 11:00am PST Join Scott Hunter to talk about the latest happening in the world of building cloud native applications with .NET and Azure Thursday 11/10 @ 1:00am PST Join @bktv99 and @segaurav will be taking the stage talk about “.NET 7.0 and bulk migration of ASP.Net web apps to App Services”. Next steps: Download .NET 7 Anouncing .NET 7.0 ASP.NET Core in .NET 7 Deploy a .NET application to App Service You can also follow us on twitter for more updates and news: @AzAppService ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2022/11/08/dotnet7_ga.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Advanced access restriction scenarios in Azure App Service",
+ "excerpt":"Introduction Currently, you can use two options when configuring Azure App Service access restrictions. The preview feature provides some new scenarios that you should know. This article will walk you through building a demo environment where you will test advanced access restriction scenarios in Azure App Service. Access restriction advanced scenarios: Filter by http header Multi-source rules Block a single IP address Restrict access to the SCM site For more information about App Service access restrictions, visit this page Requirements: Access to an Azure subscription. Decide where you will execute commands The best option to walk through this guide and execute commands would be using Azure Cloud Shell with Bash environment. Azure Cloud Shell is an interactive, authenticated, browser-accessible shell for managing Azure resources. It provides the flexibility of choosing the shell experience that best suits the way you work, either Bash or PowerShell. For information on how to use Azure Cloud Shell, visit Azure Cloud Shell. You can also install Azure CLI on your machine. The Azure CLI is available to install in Windows, macOS and Linux environments. It can also be run in a Docker container and Azure Cloud Shell. For information on how to install the Azure CLI, please visit Azure CLI installation. If you decide to use Azure Cloud Shell, please use Bash environment. Getting Started Create folder for your data You can use the name below for your folder. You just need to replace ardemo with your environment name. mkdir ardemo cd ardemo Choosing the right subscription If you have many subscriptions, you must select the subscription to which you want to deploy the resources. Using this command you can find and copy the SubscriptionId on which you want to create resources for this scenario. az account list -o table Using this command you can set a subscription to be the current active subscription. az account set -s YourSubscriptionID You can find more information about az account command on this site az account. Prepare parameters When you construct your naming convention, identify the key pieces of information that you want to reflect in the resource names. Different information is relevant for different resource types. The following sites are useful when you construct resource names - Define your naming convention and Recommended abbreviations for Azure resource types. You can use the names below. You just need to replace ardemo with your environment name and change LocationRegion parameter. Please copy and paste your parameters to your shell. LocationRegion=westeurope ResourceGroupName=rg-ardemo WebAppName=app-ardemo-prod-01 AppServicePlanName=asp-ardemo-linux-prod-01 VirtualNetworkName=vnet-ardemo-prod-westeurope-01 SubnetNameVnet=snet-ardemo-prod-westeurope-01 VnetPrefix=192.168.10.0/24 SubnetVnetPrefix=192.168.10.0/25 PrivateEndpointName=pep-ardemo-prod-01 PrivateEndpointConnectionName=con-pep-ardemo-prod-01 FDName=fd-ardemo-01 OriginGroup=origin-group-ardemo OriginNamePrimary=primary LogAnalyticsName=log-ardemo-01 ApplicationInsightsName=appi-ardemo-01 ApplicationInsightsWebTestName=WebsiteTest-$WebAppName Create basic infrastructure Create Resource Groups The demo environment will be organized using one resource group. az group create -l $LocationRegion -n $ResourceGroupName Create virtual network with subnet for App Service Private Endpoint A virtual network will be required for Azure App Service Private Endpoint. This command will create a virtual network with a subnet. az network vnet create -g $ResourceGroupName -n $VirtualNetworkName --address-prefix $VnetPrefix --subnet-name $SubnetNameVnet --subnet-prefix $SubnetVnetPrefix Create an App Service Plan An App Service plan defines a set of compute resources for a web app to run. For more information about Azure App Service plan, visit this page. az appservice plan create -n $AppServicePlanName -g $ResourceGroupName --location $LocationRegion --sku P1V2 --is-linux --number-of-workers 1 Create a Web App To create a PHP app in your App Service plan please use this command. az webapp create -n $WebAppName -g $ResourceGroupName --plan $AppServicePlanName --runtime \"PHP:8.0\" Create a variable with the URL of your website. You will use this variable later with curl command to check if your webapp is working correctly. URLofYourWebsite=$(az webapp show --name $WebAppName --resource-group $ResourceGroupName --query defaultHostName -o tsv) Create index.php file for your web app Sample code for your web app: echo '<?php echo \"Azure App Service access restrictions demo\"; ?>' > index.php Create zip file for your web app code In the next step you will use ZIP Deploy to deploy the application. You need a ZIP utility for this. If you’re using Azure Cloud Shell, ZIP utility is pre-installed and already available. zip YourWebSite.zip index.php Deploy sample app To deploy a sample application using ZIP Deploy, use this command: az webapp deployment source config-zip --resource-group $ResourceGroupName --name $WebAppName --src ./YourWebSite.zip Check if your app is running Use your browser or use curl command to check if your app is working correctly. curl https://$URLofYourWebsite Create the Private Endpoint A private endpoint is a network interface that uses a private IP address from your virtual network. This network interface connects you privately and securely to a service that’s powered by Azure Private Link. By enabling a private endpoint, you’re bringing the service into your virtual network. For more information about private endpoint, visit this page. id=$(az webapp show --name $WebAppName --resource-group $ResourceGroupName --query '[id]' --output tsv) az network private-endpoint create -n $PrivateEndpointName -g $ResourceGroupName --vnet-name $VirtualNetworkName --subnet $SubnetNameVnet --connection-name $PrivateEndpointConnectionName --private-connection-resource-id $id --group-id sites Configure the private DNS zone az network private-dns zone create --name privatelink.azurewebsites.net --resource-group $ResourceGroupName az network private-dns link vnet create --name myDNSLink --resource-group $ResourceGroupName --registration-enabled false --virtual-network $VirtualNetworkName --zone-name privatelink.azurewebsites.net az network private-endpoint dns-zone-group create --name myZoneGroup --resource-group $ResourceGroupName --endpoint-name $PrivateEndpointName --private-dns-zone privatelink.azurewebsites.net --zone-name privatelink.azurewebsites.net Check if your website is unavailable After enabling private endpoint, the web app should not be reachable from the Internet. Use your browser or use curl command to check if your app is not reachable. curl https://$URLofYourWebsite The result should look similar to this. Optional test You can create a VM in the same virtual network as the private endpoint for Azure App Service and run a network connection test using private IP address. The name of the Azure App Service should resolve to a private IP address. You can check this using the ping or nslookup command. To check if the website is working properly by using the private IP address, use curl command or a browser on a VM that you will deploy. Remember to use the standard App Service URL. Thanks to the integration with private DNS zone, the name will be translated into a private IP address. For more information about Azure App Service private endpoint DNS, visit this page. First advanced scenario - Filter by http header Currently, you can run Azure App Service with a private endpoint as well as allow traffic from the Internet to Azure App Service. Thanks to this, you can use, for example, Azure Front Door Standard SKU to make Azure App Service available from the Internet. Previously, when using a private endpoint for Azure App Service, it was required to use the Azure Front Door Premium SKU. For more information about Secure Origin with Private Link in Azure Front Door Premium, visit this page. In this guide you will add a rule that will allow access from Azure Front Door Standard instance to your Azure App Service using X-Azure-FDID. Tip Access restrictions can use the following headers: X-Forwarded-Host - You can specify hostnames of the originating request to limit traffic if a load balancer or HTTP proxy supports hostname forwarding. Enter up to 8 hostnames separated by a comma. X-Forwarded-For - You can specify IP addresses of the originating client if a load balancer or HTTP proxy supports IP forwarding when the traffic is passing >through. Enter up to 8 CIDR addresses separated by a comma. X-Azure-FDID - You can specify a unique instance id of Azure Front Door or reverse proxies supporting unique header identification. Enter up to 8 ids >separated by a comma. X-FD-HealthProbe - You can specify health probe identification to allow probe traffic. Enter up to 8 health probe ids separated by a comma. Enable public access To allow traffic from the Internet, use this command. az resource update --resource-group $ResourceGroupName --name $WebAppName --resource-type \"Microsoft.Web/sites\" --set properties.publicNetworkAccess=Enabled You can also enable Allow public access from the GUI. Check if your website is available After enabling public access, the webapp should be available from the Internet and from the private endpoint. Use your browser or curl command to check if your app is working correctly. curl https://$URLofYourWebsite Secure Access using Front Door Standard SKU Azure Front Door is Microsoft’s modern cloud Content Delivery Network (CDN) that provides fast, reliable, and secure access between your users and your applications’ static and dynamic web content across the globe. Azure Front Door delivers your content using the Microsoft’s global edge network with hundreds of global and local POPs distributed around the world close to both your enterprise and consumer end users. For more information about Azure Front Door, visit this page. Create Azure Front Door profile Run az afd profile create to create an Azure Front Door profile. az afd profile create \\ --profile-name $FDName \\ --resource-group $ResourceGroupName \\ --sku Standard_AzureFrontDoor Add an endpoint Run az afd endpoint create to create an endpoint in your profile. az afd endpoint create \\ --resource-group $ResourceGroupName \\ --endpoint-name endpoint-$FDName \\ --profile-name $FDName \\ --enabled-state Enabled Create a variable with the URL of your Azure Front Door endpoint. You will use this variable later with the curl command to check if your Azure Front Door endpoint is working correctly. URLofYourFrontDoorEndpoint=$(az afd endpoint show \\ --resource-group $ResourceGroupName \\ --profile-name $FDName \\ --endpoint-name endpoint-$FDName \\ --query hostName -o tsv) You can also write down the URL of your Azure Front Door endpoint. Create an origin group Run az afd origin-group create to create an origin group that contains your web apps. az afd origin-group create \\ --resource-group $ResourceGroupName \\ --origin-group-name $OriginGroup \\ --profile-name $FDName \\ --probe-request-type GET \\ --probe-protocol Https \\ --probe-interval-in-seconds 60 \\ --probe-path / \\ --sample-size 4 \\ --successful-samples-required 3 \\ --additional-latency-in-milliseconds 50 Add an origin to the group - primary website Run az afd origin create to add an origin to your origin group. az afd origin create \\ --resource-group $ResourceGroupName \\ --host-name $URLofYourWebsite \\ --profile-name $FDName \\ --origin-group-name $OriginGroup \\ --origin-name $OriginNamePrimary \\ --origin-host-header $URLofYourWebsite \\ --priority 1 \\ --weight 1000 \\ --enabled-state Enabled \\ --http-port 80 \\ --https-port 443 Add a route Run az afd route create to map your endpoint to the origin group. This route forwards requests from the endpoint to your origin group. az afd route create \\ --resource-group $ResourceGroupName \\ --profile-name $FDName \\ --endpoint-name endpoint-$FDName \\ --forwarding-protocol MatchRequest \\ --route-name route \\ --https-redirect Enabled \\ --origin-group $OriginGroup \\ --supported-protocols Http Https \\ --link-to-default-domain Enabled For more information about Azure CLI for Azure Front Door, visit Front Door CLI. In a production environment you will probably need to implement a WAF policy for you application. For more information about Azure CLI for Azure Front Door WAF Policy, visit Front Door WAF Policy. Check if your Azure Front Door Endpoint is running - this process may take a while Use your browser or curl command to check if your app is working correctly. It may take 10-15 minutes for your app to be accessible using Front Door. curl https://$URLofYourFrontDoorEndpoint Add X-Azure-FDID rule Create a variable with the ID of your Azure Front Door profile. YourFrontDoorID=$(az afd profile show \\ --resource-group $ResourceGroupName \\ --profile-name $FDName \\ --query frontDoorId -o tsv) Add a rule that only allows communication from the specific Azure Front Door profile. az webapp config access-restriction add --resource-group $ResourceGroupName --name $WebAppName --rule-name FrontDoor --action Allow --priority 100 --service-tag AzureFrontDoor.Backend --http-header x-azure-fdid=$YourFrontDoorID Check if your app allow connections using Azure Front Door URL Use your browser or curl command to check if your app is working correctly using Azure Front Door URL. curl https://$URLofYourFrontDoorEndpoint Check if your app is blocked by network restrictions Use your browser or curl command to check if your app is not available via direct URL access. curl https://$URLofYourWebsite Second advanced scenario - Multi-source rules Multi-source rules allow you to combine up to eight IP ranges or eight Service Tags in a single rule. You might use this if you have more than 512 IP ranges or you want to create logical rules where multiple IP ranges are combined with a single http header filter. First example - add multiple ip ranges to rule In example 1, you will add several ip ranges to one rule. Prepare to run the first scenario To remove the policy from the previous scenario, please run the command below. az webapp config access-restriction remove --resource-group $ResourceGroupName --name $WebAppName --rule-name FrontDoor To change the default behavior Unmatched rule action to Deny, please run the command below. az resource update --resource-group $ResourceGroupName --name $WebAppName --resource-type \"Microsoft.Web/sites\" --set properties.siteConfig.ipSecurityRestrictionsDefaultAction=Deny Check if your app is blocked by network restrictions Use your browser or curl command to check if your app is blocked by network restrictions. curl https://$URLofYourWebsite Check your public IP addresses and create variable Remember If you are using Azure Cloud Shell, remember that you will have a different public IP address every time you restart your console. YourPublicIPaddress=$(curl icanhazip.com) TIP You can also use a Powershell command to check your public IP address. (Invoke-WebRequest -uri \"http://ifconfig.me/ip\").Content or you can use curl command (curl icanhazip.com).Content Add IP addresses to multi-source rule To add a rule that will block traffic from several IP ranges, run the below command. az webapp config access-restriction add --resource-group $ResourceGroupName --name $WebAppName --rule-name AllowBranchWarsawIPaddresses --action Allow --priority 200 --ip-address 192.168.1.0/24,192.168.10.0/24,192.168.100.0/24,$YourPublicIPaddress Check if your app allows connections Use your browser or curl command to check if your app is working correctly. curl https://$URLofYourWebsite Second example - add multiple service tags to a network restriction rule This example show you how you can add multiple service tags to a network restriction rule. In this example we will allow connections from Logic Apps, Application Insights and API Management from West Europe. In this example you will test this rule using Application Insights availability test. Prepare to run the second example The following command will create Application Insights and Log Analytics Workspace for you. az monitor log-analytics workspace create --resource-group $ResourceGroupName --workspace-name $LogAnalyticsName LogAnalyticsId=$(az monitor log-analytics workspace show --resource-group $ResourceGroupName --workspace-name $LogAnalyticsName --query id -o tsv) LogAnalyticsWorkspaceId=$(az monitor log-analytics workspace show --resource-group $ResourceGroupName --workspace-name $LogAnalyticsName --query customerId -o tsv) az monitor app-insights component create --app $ApplicationInsightsName --location $LocationRegion --kind web -g $ResourceGroupName --application-type web --workspace $LogAnalyticsId ApplicationInsightId=$(az monitor app-insights component show --app $ApplicationInsightsName -g $ResourceGroupName --query id -o tsv) az monitor app-insights web-test create --web-test-kind \"standard\" --enabled true --location $LocationRegion --resource-group $ResourceGroupName --name $ApplicationInsightsWebTestName --defined-web-test-name $ApplicationInsightsWebTestName --tags \"hidden-link:$ApplicationInsightId=Resource\" --http-verb \"GET\" --request-url \"https://$URLofYourWebsite\" --timeout 30 --frequency 300 --retry-enabled true --locations Id=\"emea-nl-ams-azr\" --locations Id=\"us-fl-mia-edge\" Show Application Insights availability test result After running the command below, you should get a result from Application Insights that the tests failed. Tip Please wait 5-10 minutes before you run this command. Availability tests are run every 5 minutes. az monitor log-analytics query -w $LogAnalyticsWorkspaceId --analytics-query \"AppAvailabilityResults | project TimeGenerated, Message, Location | order by TimeGenerated desc\" -t P0DT1H -o table Tip If you have multiple availability tests in one Application Insight, you can use the Name field for filtering. The result should look similar to this. Add service tags to multi-source rule To add a rule that will allow traffic from several service tags, run the following command. az webapp config access-restriction add --resource-group $ResourceGroupName --name $WebAppName --rule-name AllowMultipleServiceTags --action Allow --priority 300 --service-tag LogicApps,ApiManagement.WestEurope,ApplicationInsightsAvailability Show Application Insight availability test result After running the command below, you should get a result from Application Insight that the tests passed. Tip Please wait 5-10 minutes before you run this command. Availability tests are run every 5 minutes. az monitor log-analytics query -w $LogAnalyticsWorkspaceId --analytics-query \"AppAvailabilityResults | project TimeGenerated, Message, Location | order by TimeGenerated desc\" -t P0DT1H -o table The result should look similar to this. Third advanced scenario - Block a single IP address Remove previous rules To remove the rules from the previous scenario, run the command below. az webapp config access-restriction remove --resource-group $ResourceGroupName --name $WebAppName --rule-name AllowBranchWarsawIPaddresses az webapp config access-restriction remove --resource-group $ResourceGroupName --name $WebAppName --rule-name AllowMultipleServiceTags Change default behavior for Unmatched rule action to Allow To change the default behavior to Allow, run the command below. az resource update --resource-group $ResourceGroupName --name $WebAppName --resource-type \"Microsoft.Web/sites\" --set properties.siteConfig.ipSecurityRestrictionsDefaultAction=Allow Check if your app allow connections Use your browser or curl command to check if your app allows connections. curl https://$URLofYourWebsite Block your public IP address To add a rule that will block traffic from your IP address, run the command below. az webapp config access-restriction add --resource-group $ResourceGroupName --name $WebAppName --rule-name BlockSingleIpAddress --action Deny --priority 200 --ip-address $YourPublicIPaddress Check if your app is blocked by network restrictions Use your browser or curl command to check if your app is blocked by network restriction. curl https://$URLofYourWebsite Fourth advanced scenario - Restrict access to the SCM site You can use the same access restriction rules from the Main site or create your own rule for the SCM (Advanced tool) site. The SCM site is responsible for Web Deploy and Kudu console. For more information about Kudu, visit Kudu service overview. Verify that you can deploy your sample app To verify that you can deploy your sample app via Web Deploy, run the command below. az webapp deployment source config-zip --resource-group $ResourceGroupName --name $WebAppName --src ./YourWebSite.zip Use the same access restrictions rules from Main site in Advanced tool site To use the same rules from the Main site in the Advanced tool site, run this command. az webapp config access-restriction set --resource-group $ResourceGroupName --name $WebAppName --use-same-restrictions-for-scm-site true Verify that you can’t deploy your sample app To verify that you can’t deploy your sample app via Web Deploy, please run the command below. az webapp deployment source config-zip --resource-group $ResourceGroupName --name $WebAppName --src ./YourWebSite.zip Configure different rules for Advanced tool site To configure other rules for Advanced tool site, run below command. az webapp config access-restriction set --resource-group $ResourceGroupName --name $WebAppName --use-same-restrictions-for-scm-site false To add a rule that will allow traffic from your IP address to the SCM site, run the bellow command. az webapp config access-restriction add --resource-group $ResourceGroupName --name $WebAppName --rule-name BlockSingleIpAddress --action Allow --scm-site true --priority 200 --ip-address $YourPublicIPaddress Verify that you can deploy your sample app To verify that you can deploy your sample app via Web Deploy, please run the command below. az webapp deployment source config-zip --resource-group $ResourceGroupName --name $WebAppName --src ./YourWebSite.zip You successfully completed the article. ","categories": ["networking"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2022/11/24/Advanced-access-restriction-scenarios-in-Azure-App-Service.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Announcing Larger SKUs for App Service Environment v3",
+ "excerpt":"Our engineering teams have been hard at work to deliver the new larger SKUs on App Service Environment v3. While it seems simple, as it is multiples of the existing SKU sizes, we took the opportunity to make some major adjustments, and build a more flexible backend to allow us to introduce more compute options in the future. With the addition of these new Isolated V2 SKUs, these are the SKUs available for App Service Environment v3. SKU Name vCPUs Memory I1v2 2 vCPUs 8 GB I2v2 4 vCPUs 16 GB I3v2 8 vCPUs 32 GB I4v2 16 vCPUs 64 GB I5v2 32 vCPUs 128 GB I6v2 64 vCPUs 256 GB You can create new plans and scale in the Azure portal with the new SKUs. The new SKUs are not available if you create both App Service Environment and plan as part of creating a new app in the portal, but you can scale up after creating it. Prices may also not be visible in all regions, but are 2x increments as shown in this screenshot. Download the latest Azure CLI to have support for the new SKUs using az appservice create/update. Note that the command will take about 40 minutes for Windows and 15 minutes for Linux to complete the create/update operation (use the --no-wait parameter to avoid having to wait for the command to finish in the console): az appservice plan create/update --name <plan name> --sku I5v2 -g <resource-group-name> -e <ase-name or resource-id> --no-wait To deploy a new plan or update an existing plan using ARM, you can simply just specify the new SKU names. If you use the template below, just replace the values prefixed with REPLACE. For the reserved property, true = Linux, false = Windows. { \"$schema\": \"https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#\", \"contentVersion\": \"1.0.0.0\", \"variables\": { \"appServicePlanName\": \"REPLACE-PLAN-NAME\", \"appServicePlanSize\": \"I4v2\", \"appServicePlanInstanceCount\": 1, \"location\": \"[resourceGroup().location]\", \"appServiceEnvironmentResourceId\": \"/subscriptions/REPLACE-SUB-ID/resourceGroups/REPLACE-RG-NAME/providers/Microsoft.Web/hostingEnvironments/REPLACE-ASE-NAME\" }, \"resources\": [ { \"name\": \"[variables('appServicePlanName')]\", \"type\": \"Microsoft.Web/serverfarms\", \"apiVersion\": \"2021-03-01\", \"location\": \"[variables('location')]\", \"properties\": { \"reserved\": true, \"hostingEnvironmentProfile\" :{ \"id\": \"[variables('appServiceEnvironmentResourceId')]\" } }, \"sku\": { \"name\": \"[variables('appServicePlanSize')]\", \"capacity\": \"[variables('appServicePlanInstanceCount')]\" } } ] } Looking forward to see what you will do with all that power! Questions/Feedback If you have any questions or feedback, please reach out to our team at AppServiceEnvPM@microsoft.com ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2022/12/01/Announcing-Larger-Isolatedv2-SKUs.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "How to deploy a highly available multi-region web app",
+ "excerpt":"High availability and fault tolerance are key components of a well-architected solution. It’s always best to prepare for the unexpected and having an emergency plan that can shorten downtime and keep your systems up an running automatically when something fails can help you do that. When you deploy your application to the cloud, you choose a region in that cloud where your application infrastructure is based. Regions are essentially data centers is various parts of the world. In a world where unpredictable severe weather events, natural disasters, or human errors are inevitable, there’s the imminent possibility of events that may disturb the functionality of a region or take it down altogether for a period of time. If your application is deployed to a single region, and the region becomes unavailable, your application will also be unavailable. This may be unacceptable under the terms of your application’s SLA. If so, deploying your application and its services across multiple regions is a good idea. A multi-region deployment can use an active-active or active-passive configuration. An active-active configuration distributes requests across multiple active regions. An active-passive configuration keeps warm instances in the secondary region, but doesn’t send traffic there unless the primary region fails. For multi-region deployments, we recommend deploying to paired regions. For more information on this topic, see Architect Azure applications for resiliency and availability. In this blog post, we’ll walk through deploying a highly available multi-region web app. We’ll start with deploying the necessary infrastructure, and then move into managing the application source code. We’ll have a look at some of the different offerings Azure provides to enable this architecture as well as go over best practices and recommendations. We’ll keep the scenario simple by restricting our application components to just a web app, but the info shared here can definitely be expanded and applied to many other infrastructure patterns. For example, if your application connects to an Azure database offering or storage account, a quick search through the Azure docs will reveal built-in solutions as active geo-replication for SQL databases and redundancy options for storage accounts. For a reference architecture for a more detailed scenario, see Highly available multi-region web application. Architecture Workflow The architecture is shown in the diagram above. Primary and secondary regions. This architecture uses two regions to achieve higher availability. The application is deployed to each region. During normal operations, network traffic is routed to the primary region. If the primary region becomes unavailable, traffic is routed to the secondary region. Front Door. Front Door routes incoming requests to the primary region. If the application running in that region becomes unavailable, Front Door fails over to the secondary region. There are several general approaches to achieve high availability across regions. This reference focuses on active/passive with hot standby. It replicates the infrastructure in the secondary region, however traffic only goes to the primary region. If something happens in the primary region, traffic will automatically divert to the secondary region. Recommendations and considerations Your requirements might differ from the architecture described here, however you can use the recommendations and considerations in this section as a starting point as they apply to almost all multi-region scenarios. The considerations come from the Microsoft Azure Well-Architected Framework, which is a set of guiding tenets that can be used to improve the quality of a workload. Regional pairing Deciding on your primary region is relatively straightforward - pick the region that supports the features you’re using and is closest to you/your customers to reduce latency. When deciding on your secondary region, consider using the region Azure paired with your primary. Resource groups Consider placing the primary region, secondary region, and Front Door into separate resource groups. This lets you manage the resources deployed to each region as a single collection. Front Door configuration Routing. Front Door supports several routing mechanisms. We will be using priority routing in the scenario here as described in the workflow. Other routing mechanisms can direct traffic based on pre-defined weighting or lowest latency. Consider cost when choosing a routing mechanism because for example if you decide to use priority routing, you can scale down your application in your secondary region and only scale up when traffic is directed to it. Tier. Azure Front Door is offered in a variety of flavors including the Standard and Premium tiers as well as Azure Front Door (classic). For a comparison of the various tiers, see the Front Door tier overview. We will be using the standard tier in the scenario here. Load balancing options. Azure provides multiple load balancing options to help direct traffic for your applications. Choosing the most appropriate one for your scenario can be based on a number of factors including traffic type, cost, features, and limitations. To help you decide, see the Decision tree for load balancing in Azure. We will be using Azure Front Door for this scenario because we are deploying an internet facing web application (HTTP/HTTPS) deployed to multiple regions hosted on App Service. Reliability. Azure Front Door automatically fails over if the primary region becomes unavailable. When Front Door fails over, there is a period of time (usually about 20-60 seconds) when clients cannot reach the application. The duration is affected by the frequency of health probes and sample size configuration. For more information on Front Door reliability, see Azure Front Door reliability. Infrastructure deployment Consider configuring a continuous deployment mechanism to manage your application source code as well as application infrastructure. Since you’re deploying resources in different regions, you’ll need to independently manage those resources. To ensure the resources are in sync and assuming you want essentially identical applications and infrastructures in each region, infrastructure as code (IaC) such as Azure Resource Manager templates or Terraform should be used with deployment pipelines such as Azure DevOps pipelines or GitHub Actions. This way, if configured appropriately, any change to resources or source code would trigger updates across all regions you’re deployed to. See Continuous deployment to Azure App Service for recommendations on how to manage your source code. We’ll go over in detail how to do this for a multi-region deployment later on in this post. Security For this scenario, you’ll want to ensure the only principal that can access your applications is Front Door. Front Door’s features work best when traffic only flows through Front Door. You should configure your origin to block traffic that hasn’t been sent through Front Door. Otherwise, traffic might bypass Front Door’s web application firewall, DDoS protection, and other security features. We’ll configure this as part of the tutorial later on in this post. Additionally, for scenarios using App Services, consider locking down the SCM/advanced tools site as this site will not likely need to be reached through Front Door. You’ll likely want to set up access restrictions that only allow you to conduct your testing as well as enable continuous deployment from your tool of choice. We’ll go into more detail on how to do this during the tutorial later on in this post. Lastly, for scenarios using App Services, consider disabling basic auth on App Service, which limits access to the FTP and SCM endpoints to users that are backed by Azure Active Directory (AAD). Disabling basic auth will require additional steps to configure continuous deployment. We’ll go through this as well later on in this post. Cost optimization Choose the Azure Front Door tier that meets your data transfer, routing, and security requirements. See Azure Front Door pricing for more details. Additionally, if you’re using an active/passive multi-region deployment, consider scaling down your App Services in the secondary region and configuring autoscale rules to handle the traffic when traffic is re-directed there. For more details, see the App Service scaling docs. Infrastructure deployment tutorial In this tutorial, you’ll deploy the scenario shown in the workflow which includes two web apps behind Azure Front Door with access restrictions that only give Front Door direct access to the apps. We’ll use the Azure CLI to create the initial web apps and we’ll use the portal to create the Azure Front Door. Prerequisites An Azure account with an active subscription. Create an account for free. Create two instances of a web app You’ll need two instances of a web app that run in different Azure regions for this tutorial. We’ll use the region pair East US/West US as our two regions and create two quick empty web apps. Feel free to choose you’re own regions or use existing web apps if you already have some deployed. I’m going to use a single resource group for all resources to make management and clean-up simpler, however consider using separate resource groups for each region/resource as this will further isolate your resources. Run the following command to create your resource group. Replace the placeholder for “resource-group-name”. az group create --name <resource-group-name> --location eastus Run the following commands to create the App Service plans. Replace the placeholders for App Service plan name and resource group name. az appservice plan create --name <app-service-plan-east-us> --resource-group <resource-group-name> --is-linux --location eastus az appservice plan create --name <app-service-plan-west-us> --resource-group <resource-group-name> --is-linux --location westus Once the App Service plans are created, run the following commands to create the web apps. Replace the placeholders and be sure to pay attention to the --plan parameter so that you place one app in each plan (and therefore each region). az webapp create --name <web-app-east-us> --resource-group <resource-group-name> --plan <app-service-plan-east-us> az webapp create --name <web-app-west-us> --resource-group <resource-group-name> --plan <app-service-plan-west-us> Make note of the default host name of each web app so you can define the backend addresses when you deploy the Front Door in the next step. It should be in the format <web-app-name>.azurewebsites.net. This can be found by running the following command or by navigating to the app’s Overview page in the Azure portal. az webapp show --name <web-app-name> --resource-group <resource-group-name> --query \"hostNames\" Disable basic auth for the web apps To disable FTP access to the site, run the following CLI command. Replace the placeholders with your resource group and site name. Be sure to run this command for each of your apps. az resource update --resource-group <resource-group-name> --name ftp --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-east-us> --set properties.allow=false To disable basic auth access to the WebDeploy port and SCM site, run the following CLI command. Replace the placeholders with your resource group and site name. az resource update --resource-group <resource-group-name> --name scm --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-east-us> --set properties.allow=false For more information on disabling basic auth including how to test and monitor logins, see Disabling basic auth on App Service. Create Azure Front Door I’m going to use the portal to create the Front Door since it will help us visualize the various components, however the CLI or templates can just as easily be used. Front Door will be configured with priority routing where East US will be our primary region and West US will be the secondary. We’ll use the standard tier which gives us the option to use a Web Application Firewall (WAF) policy for enhanced security. From the home page or the Azure menu in the portal, select + Create a resource. Search for ”Front Door and CDN profiles”. Then select Create. On the Compare offerings page, select Custom create. Then select Continue to create a Front Door. On the ”Basics” tab, enter the following information: Setting Description Subscription select your subscription Resource group <resource-group-name> Name <unique-name> Tier Standard In the “Endpoint” tab, select Add an endpoint and give your endpoint a globally unique name. Next, select + Add a route to configure routing to your Web App origin. On the Add a route page, enter the following information and select Add to add the route to the endpoint configuration. Setting Description Name Enter a name to identify the mapping between domains and origin group. Domains A domain name has been auto-generated for you to use. If you want to add a custom domain, select Add a new domain. This example will use the default. Patterns to match Set all the URLs this route will accept. This example will use the default, and accept all URL paths. Accepted protocols Select the protocol the route will accept. This example will accept both HTTP and HTTPS requests. Redirect Enable this setting to redirect all HTTP traffic to the HTTPS endpoint. Origin group Select Add a new origin group. For the origin group name, enter myOriginGroup. Then select + Add an origin. For the first origin (primary region), enter the name of one of the web apps you’re using for this tutorial for the Name and then for the Origin Type select App Services. For the Host name, select the hostname you queried/found in the portal earlier. Leave the rest of the default values the same. Select Add to add the origin to the origin group. Repeat the steps to add the second web app as an origin, however when adding the second origin, set the Priority to “2”. This will direct all traffic to the primary origin unless the primary goes down. Once both web app origins have been added, select Add to save the origin group configuration. Origin path Leave blank. Forwarding protocol Select the protocol that will be forwarded to the origin group. This example will match the incoming requests to origins. Caching Select the check box if you want to cache contents closer to your users globally using Azure Front Door’s edge POPs and the Microsoft network. Rules Once you’ve deployed the Azure Front Door profile, you can configure Rules to apply to your route. Select + Add a policy to apply a Web Application Firewall (WAF) policy to one or more domains in the Azure Front Door profile. On the Add security policy page, enter a name to identify this security policy. Then select domains you want to associate the policy with. For WAF Policy, you can select a previously created policy or select Create New to create a new policy. Select Save to add the security policy to the endpoint configuration. Select Review + Create, and then Create to deploy the Azure Front Door profile. It will take a few minutes for configurations to be propagated to all edge locations. Restrict access to web apps to the Azure Front Door instance Traffic from Azure Front Door to your application originates from a well known set of IP ranges defined in the AzureFrontDoor.Backend service tag. By using a service tag restriction rule, you can restrict traffic to only originate from Azure Front Door. Before setting up the App Service access restriction, take note of the Front Door ID which can be found on the Overview page for the Front Door instance in the Essentials section. This will be needed to ensure traffic only originates from your specific Front Door instance by further filtering the incoming requests based on the unique http header that your Azure Front Door sends. For your first web app, navigate to the Access restriction (preview) page. For the Main site add the following rule. Insert the Front Door ID which you copied earlier under X-Azure-FDID. Be sure to repeat these same steps for the other web app. Lock down SCM/advanced tool site Earlier on when you were creating the web apps, you disabled basic authentication to the WebDeploy port and SCM site. You’ll want to also disable all public access to the SCM site. Doing this, however, limits how code can be deployed to your app. Later on, we’ll walk through how to give a service principal access to deploy your source code. To disable public access, navigate to the Access restriction (preview) page for your app and select the Advanced tool site tab. For the Unmatched rule action, select “Deny” and then Save. Repeat this process for the other app. You can optionally configure access restrictions to the SCM site as well for the app if you need to give other principals access. To do so, navigate to the Advanced tool site tab and add any needed rules. The access restrictions you apply to the SCM site will depend on how you’re managing and deploying your source code and conducting your testing. Verify Azure Front Door To confirm access to your apps is restricted to Front Door, try navigating to your apps directly using their endpoints. If you are able to access them, review their access restrictions and ensure access is limited to only Front Door. Now that a couple minutes have passed since the Front Door instance has been created, it should be ready and deployed globally. In a browser, enter the endpoint hostname for the Front Door. This endpoint can be found on the Overview page for your Front Door. If everything has been configured correctly, you should be reaching your app in your primary region. You can test failover by stopping the app in your primary region and then navigating to your Front Door endpoint again. Note that there may be a delay between when the traffic will be directed to the second web app depending on your health probe frequency. You may need to refresh the page a couple times. Try stopping the second web app as well and you should see an error page. This proves it redirected to the secondary region. Managing source code At this point, you’ve provisioned all of the resources you need to run a highly available multi-region web app. All that’s left is deploying the actual web app source code as well as understanding how to keep the app updated across the various regions over time as changes and updates are made. As mentioned in the infrastructure deployment section, just like for your infrastructure, it’s a good idea to use a CI/CD tool to manage your source code as well so any changes you make can automatically get deployed across all instances of your app. If you don’t configure continuous deployment, you’ll need to manually update each app in each region every time there is a code change. App Service supports continuous deployment from GitHub and Azure Repos. For this tutorial, we’ll use GitHub and a repo that already meets the requirements for continuous deployment with App Service. Feel free to use an app of your choosing, but be sure it meets the defined requirements. We’re going to go over the following concepts in this next section including: Configuring the deployment source for each app Keeping the apps updated over time across multiple regions Best practices for making source code updates by using deployment slots, slot swap, and updating Azure Front Door’s route/origin groups Prerequisites for source code deployment We’ll be using a .NET 6.0 sample app from GitHub. If you don’t already have a GitHub account, create an account for free. Go to the .NET 6.0 sample app. Select the Fork button in the upper right on the GitHub page. Select the Owner and leave the default Repository name. Select Create fork. At this point, your source code is all set up and ready to be deployed to your apps. Configure the deployment source You’ll need to update your app’s stack settings to match the source code if you’ve been following along in this tutorial. Go to one of your apps. In the left pane, select Configuration and then select the General settings tab. Under Stack settings, set the Stack to “.NET” and the .NET version to “.NET 6 (LTS)”. Select Save and then Continue to confirm the update. Repeat the above steps for your other app. As mentioned earlier, since you locked down the SCM site and disabled basic auth, the default method for deploying code with GitHub Actions isn’t going to work. This is because the default method uses a publishing profile. Instead, you have two options to authenticate with App Service for GitHub Actions - using a service principal or OpenID Connect. We have a detailed doc that goes through how to do this for each of your options - Deploy to App Service using GitHub Actions. We also have guidance for Azure DevOps using Azure Pipelines. Additionally, for more info on this topic as well as additional examples, we have a series of blog posts that walk through scenarios you may be interested in. Deploying to Network-secured sites Deploying to Network-secured sites, Part 2 For this blog post, we’ll walk through how to authenticate with App Service for GitHub Actions with the most secure option, which is OpenID Connect. You can choose to use a service principal which follows the same general process but omits a couple steps. Configure authentication with App Service for GitHub Actions with OpenID Connect Run the following command to create the Active Directory application. az ad app create --display-name myApp This command will output JSON with an appId. Copy this, you’ll need it in the next step. Run the following command to create a service principal. Replace the appId placeholder with the value you copied in the previous step. az ad sp create --id <appId> You’ll now need to create a new role assignment for your newly created service principal so that it has access to your resources. You’ll need to grant access at the subscription level and give it the “Contributor” role. You can scope the role assignment down further based on your use case. To create this role assignment, search for “Subscriptions” in the search box at the top of the portal and select your subscription. Select Access Control (IAM) in the left-hand menu. Select + Add at the top and then Add role assignment. Select the Contributor role and then go to the Members tab. Select + Select members and then find your service principal. Select Review + assign. Once the service principal has the needed role assignment, create a new federated identity credential for your active directory application. For detailed guidance, see Add federated credentials. In the portal, search for in the search box and then go to App Registrations and then select the app you created earlier. Select Certificates & secrets in the left-hand menu. In the Federated credentials tab, select Add credential. Select the credential scenario GitHub Actions deploying Azure resources. Generate your credential by entering your credential details. Field Description Example Organization Your GitHub organization name or GitHub username. contoso Repository Your GitHub Repository name. dotnetcore-docs-hello-world Entity type The filter used to scope the OIDC requests from GitHub workflows. This field is used to generate the subject claim. Branch GitHub branch name The name of the environment, branch, or tag. master Name Identifier for the federated credential. myCredential You need to provide your application’s Client ID, Tenant ID, and Subscription ID to the login action as part of the GitHub Action workflow we will be working on. These values can either be provided directly in the workflow or can be stored in GitHub secrets and referenced in your workflow. Saving the values as GitHub secrets is the more secure option. Open your GitHub repository and go to Settings > Security > Secrets and variables > Actions > New repository secret. Create the following secrets. To find the values for Client ID and Tenant ID, go back to App Registrations in the portal and select the app you created earlier. The values will be under the Essentials on the Overview page. Name Value AZURE_CLIENT_ID <application/client-id> AZURE_TENANT_ID <directory/tenant-id> AZURE_SUBSCRIPTION_ID <subscription-id> Deploy the code You’re now ready to deploy the code. However, configuring continuous deployment for production apps is not recommended because it makes testing and validation more complicated. Instead, use a combination of staging slots and slot swap to move code from your testing environment to production. We’ll create deployment slots for each instance of our app and then walk through how to slot swap to get the code into production. Go to one of your apps. In the left pane, select Deployment slots. Select + Add Slot. Input “stage” for Name and to keep things simple, we’ll clone the settings from the production slot by selecting the app’s name from the Clone settings from: dropdown. Select Close at the bottom of the slot configuration pane. Select the newly created stage slot. In the left pane, select Deployment Center and make sure you’re on the Settings tab. For Source, select “GitHub”. If you’re deploying from GitHub for the first time, select Authorize and follow the authorization prompts. After you authorize your Azure account with GitHub, select the Organization, Repository, and Branch to configure CI/CD as shown below. If you can’t find an organization or repository, you might need to enable more permissions on GitHub. For more information, see Managing access to your organization’s repositories. Setting Description Organization <your GitHub username> Repository dotnetcore-docs-hello-world Branch master Leave the remaining defaults and select Save. You can track the deployment and commits in the Logs tab in the Deployment Center to monitor progress. Repeat the above steps for your other app. Create the GitHub Actions workflow If you wait a couple minutes and review the deployment logs, you’ll see that the deployment to your apps failed. This is happening for two reasons - the default workflow created in the previous step when you were configuring continuous deployment with GitHub Actions uses a publishing profile to authenticate and you disabled this level of access, and the access restrictions for the SCM site for your staging slot deny all traffic. You first need to update the unmatched rule action for the Advanced tool site just for your staging slots to “Allow”. You’ve already disabled basic auth to your SCM site so access to it is already restricted to Azure AD authenticated principals. Allowing traffic using the access restrictions allows GitHub to reach your app and deploy your code. If you’re using GitHub Enterprise or another privately hosted source code repo, you can define specific access restrictions for your IP ranges instead. You then need to edit the GitHub Actions workflow as shown below so that it uses your OpenID Connect credentials instead of the publish profile. For sample workflows, see the OpenID Connect tab in Deploy to App Service. If you’ve been following along, use the below workflow. Open your GitHub repository and go to the dotnetcore-docs-hello-world/.github/workflows/ directory. You’ll see two autogenerated workflows, one for each app you created. Repeat the next step for each of them. Select the “pencil” button in the top right to edit the file. Replace the contents with the below, which assumes you created the GitHub secrets earlier, update the placeholder for AZURE_WEBAPP_NAME for your apps, and then commit directly to the master branch. This commit will trigger the GitHub Action to run again and deploy your code, this time using OpenID Connect to authenticate. name: .NET Core on: push: branches: - master workflow_dispatch: permissions: id-token: write contents: read env: AZURE_WEBAPP_NAME: <web-app-name> # set this to your application's name AZURE_WEBAPP_PACKAGE_PATH: '.' # set this to the path to your web app project, defaults to the repository root DOTNET_VERSION: '6.0.x' # set this to the dot net version to use jobs: build: runs-on: ubuntu-latest steps: # Checkout the repo - uses: actions/checkout@main - uses: azure/login@v1 with: client-id: ${{ secrets.AZURE_CLIENT_ID }} tenant-id: ${{ secrets.AZURE_TENANT_ID }} subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }} # Setup .NET Core SDK - name: Setup .NET Core uses: actions/setup-dotnet@v1 with: dotnet-version: ${{ env.DOTNET_VERSION }} # Run dotnet build and publish - name: dotnet build and publish run: | dotnet restore dotnet build --configuration Release dotnet publish -c Release -o '${{ env.AZURE_WEBAPP_PACKAGE_PATH }}/myapp' # Deploy to Azure Web apps - name: 'Run Azure webapp deploy action using publish profile credentials' uses: azure/webapps-deploy@v2 with: app-name: ${{ env.AZURE_WEBAPP_NAME }} slot-name: 'stage' # replace with your slot name package: '${{ env.AZURE_WEBAPP_PACKAGE_PATH }}/myapp' - name: logout run: | az logout After a couple minutes, once the deployments to the staging slots complete, if you try accessing your slot’s endpoint directly, you’ll receive an “Error 403 - Forbidden” because the access restrictions were cloned from the production site. There are a couple strategies that can be used to review the staging site and then eventually get it into production. To quickly validate that your staging site is working, you can temporarily update its access restrictions by adding your IP to the allow list for example and then attempt to reach it’s endpoint again. Be sure to remove that rule once you are done validating. Alternatively, if you don’t plan on using slot traffic routing as described in the next section, you can update the access restrictions to meet your testing specifications. Since your Front Door is still pointing to your production apps, if you go to your Front Door’s endpoint now, you’ll still see the initial empty apps that were created earlier. You have a couple options here - you can either slot swap and your new code will move into production all at once, or you can try a variation of A/B testing using slot traffic routing. We’ll go over both of these features. Slot traffic routing Traffic routing with slots allows you to direct a pre-defined portion of your user traffic to each slot. Initially, 100% of traffic is directed to the production site. However, you have the ability, for example, to send 10% of your traffic to your staging slot. So when users try to access your app, 10% of them will automatically be routed there. No changes are needed on your Front Door instance to accomplish this. To learn more about slot swaps and staging environments in App Service see Set up staging environments in Azure App Service. If you want to validate this feature as part of this tutorial, it will take some trial and error. The best way to validate it would be to send 100% of the traffic to the staging slot and then go the Front Door endpoint. You may need to clear your browser’s cache, refresh the page, or purge Front Door’s cache if you’re still not seeing your deployed changes. Slot swap Once you’re done testing and validating, you can perform a slot swap from your staging site to your production site. You’ll need to do this for both instances of you app. During a slot swap, the App Service platform ensures the target slot doesn’t experience downtime. To perform the swap: Go to your app’s Deployment slots page and select Swap. The Swap dialog box shows settings in the selected source and target slots that will be changed. Select the desired Source and Target slots. Also, select the Source Changes and Target Changes tabs and verify that the configuration changes are expected. When you’re finished, you can swap the slots immediately by selecting Swap. Repeat the process for your other app. After a few minutes, you can navigate to your Front Door’s endpoint to validate the slot swap succeeded. Ensure you reset the slot traffic routing if needed. You may need to clear your browser’s cache, refresh the page, or purge Front Door’s cache if you’re still not seeing your deployed changes. At this point, your apps are up and running and any changes you make to your source code will automatically trigger an update to both of your staging apps. You can then repeat the slot swap process described above when you’re ready to move that code into production. Additional guidance If you’re concerned about potential disruptions or issues with continuity across regions, as in some customers seeing one version of your app while others see another, or if you’re making significant changes to your apps, you can temporarily remove the site that’s undergoing the slot swap from your Front Door’s origin group and all traffic will be directed to the other origin. To do this, navigate to the Update origin group pane as shown below and Delete the origin that is undergoing the change. Once you’ve made all of your changes and are ready to serve traffic there again, you can return to the same pane and select + Add an origin to re-add the origin. If you’d prefer to not delete and then add re-add origins, you can create additional origin groups for your Front Door instance. You can then associate the route to the origin group pointing to the intended origin. For example, you can create two new origin groups, one for your primary region and one for your secondary region. When your primary region is undergoing a change, associate the route with your secondary region and vice versa when your secondary region is undergoing a change. When all changes are complete, you can associate the route with your original origin group which contains both regions. This method works because a route can only be associated with one origin group at a time. However, if you have many regions and apps, it will get messy since you’ll need one origin group per region and potentially additional origin groups if you have multiple apps. To demonstrate working with multiple origins, in the screenshot below, there are three origin groups. “MyOriginGroup” consists of both web apps, and the other two origin groups each consist of the web app in their respective region. In the example here, the app in the primary region is undergoing a change, so before I started that change, I associated the route with “MySecondaryRegion” so all traffic would be sent to the app in my secondary region during the change period. You can update the route by selecting “Unassociated” which will bring up the Associate routes pane. Clean up resources After you’re done, you can remove all the items you created. Deleting a resource group also deletes its contents. If you don’t intend to use this Azure Front Door, you should remove these resources to avoid unnecessary charges. Next steps If you’re interested in learning about another web app pattern for n-tier web applications, see the next post in this series called How to deploy a secure n-tier web app. Zone redundancy is another infrastructure pattern that can provide high availability by replicating your services and data across availability zones to protect against single points of failure. For a detailed reference architecture on this for App Service, see Highly available zone-redundant web application. Deploy from ARM/Bicep All of the resources in this post can be deployed using an ARM/Bicep template. A sample template is shown below, which creates empty apps and staging slots behind Front Door following the security best practices outlined in this post. You’ll need to configure the deployment source as well as the service principal once the template resources are created. To learn how to deploy ARM/Bicep templates, see How to deploy resources with Bicep and Azure CLI. @description('The location into which regionally scoped resources should be deployed. Note that Front Door is a global resource.') param location string = 'canadacentral' @description('The location into which regionally scoped resources for the secondary should be deployed.') param secondaryLocation string = 'canadaeast' @description('The name of the App Service application to create. This must be globally unique.') param appName string = 'myapp-${uniqueString(resourceGroup().id)}' @description('The name of the secondary App Service application to create. This must be globally unique.') param secondaryAppName string = 'mysecondaryapp-${uniqueString(resourceGroup().id)}' @description('The name of the SKU to use when creating the App Service plan.') param appServicePlanSkuName string = 'S1' @description('The number of worker instances of your App Service plan that should be provisioned.') param appServicePlanCapacity int = 1 @description('The name of the Front Door endpoint to create. This must be globally unique.') param frontDoorEndpointName string = 'afd-${uniqueString(resourceGroup().id)}' @description('The name of the SKU to use when creating the Front Door profile.') @allowed([ 'Standard_AzureFrontDoor' 'Premium_AzureFrontDoor' ]) param frontDoorSkuName string = 'Standard_AzureFrontDoor' var appServicePlanName = 'AppServicePlan' var secondaryAppServicePlanName = 'SecondaryAppServicePlan' var frontDoorProfileName = 'MyFrontDoor' var frontDoorOriginGroupName = 'MyOriginGroup' var frontDoorOriginName = 'MyAppServiceOrigin' var secondaryFrontDoorOriginName = 'MySecondaryAppServiceOrigin' var frontDoorRouteName = 'MyRoute' resource frontDoorProfile 'Microsoft.Cdn/profiles@2021-06-01' = { name: frontDoorProfileName location: 'global' sku: { name: frontDoorSkuName } } resource appServicePlan 'Microsoft.Web/serverFarms@2020-06-01' = { name: appServicePlanName location: location sku: { name: appServicePlanSkuName capacity: appServicePlanCapacity } properties: { reserved: true } kind: 'app' } resource secondaryAppServicePlan 'Microsoft.Web/serverFarms@2020-06-01' = { name: secondaryAppServicePlanName location: secondaryLocation sku: { name: appServicePlanSkuName capacity: appServicePlanCapacity } properties: { reserved: true } kind: 'app' } resource app 'Microsoft.Web/sites@2020-06-01' = { name: appName location: location kind: 'app' identity: { type: 'SystemAssigned' } properties: { serverFarmId: appServicePlan.id httpsOnly: true siteConfig: { detailedErrorLoggingEnabled: true httpLoggingEnabled: true requestTracingEnabled: true ftpsState: 'Disabled' minTlsVersion: '1.2' ipSecurityRestrictions: [ { tag: 'ServiceTag' ipAddress: 'AzureFrontDoor.Backend' action: 'Allow' priority: 100 headers: { 'x-azure-fdid': [ frontDoorProfile.properties.frontDoorId ] } name: 'Allow traffic from Front Door' } ] scmIpSecurityRestrictionsDefaultAction: 'Deny' } } } resource ftpPolicy 'Microsoft.Web/sites/basicPublishingCredentialsPolicies@2022-03-01' = { name: 'ftp' kind: 'string' parent: app location: location properties: { allow: false } } resource scmPolicy 'Microsoft.Web/sites/basicPublishingCredentialsPolicies@2022-03-01' = { name: 'scm' kind: 'string' parent: app location: location properties: { allow: false } } resource appSlot 'Microsoft.Web/sites/slots@2020-06-01' = { name: '${appName}/stage' location: location kind: 'app' identity: { type: 'SystemAssigned' } properties: { serverFarmId: appServicePlan.id httpsOnly: true siteConfig: { detailedErrorLoggingEnabled: true httpLoggingEnabled: true requestTracingEnabled: true ftpsState: 'Disabled' minTlsVersion: '1.2' ipSecurityRestrictions: [ { tag: 'ServiceTag' ipAddress: 'AzureFrontDoor.Backend' action: 'Allow' priority: 100 headers: { 'x-azure-fdid': [ frontDoorProfile.properties.frontDoorId ] } name: 'Allow traffic from Front Door' } ] } } dependsOn: [ app ] } resource ftpPolicySlot 'Microsoft.Web/sites/slots/basicPublishingCredentialsPolicies@2022-03-01' = { name: 'ftp' kind: 'string' parent: appSlot location: location properties: { allow: false } } resource scmPolicySlot 'Microsoft.Web/sites/slots/basicPublishingCredentialsPolicies@2022-03-01' = { name: 'scm' kind: 'string' parent: appSlot location: location properties: { allow: false } } resource secondaryApp 'Microsoft.Web/sites@2020-06-01' = { name: secondaryAppName location: secondaryLocation kind: 'app' identity: { type: 'SystemAssigned' } properties: { serverFarmId: secondaryAppServicePlan.id httpsOnly: true siteConfig: { detailedErrorLoggingEnabled: true httpLoggingEnabled: true requestTracingEnabled: true ftpsState: 'Disabled' minTlsVersion: '1.2' ipSecurityRestrictions: [ { tag: 'ServiceTag' ipAddress: 'AzureFrontDoor.Backend' action: 'Allow' priority: 100 headers: { 'x-azure-fdid': [ frontDoorProfile.properties.frontDoorId ] } name: 'Allow traffic from Front Door' } ] scmIpSecurityRestrictionsDefaultAction: 'Deny' } } } resource secondaryFtpPolicy 'Microsoft.Web/sites/basicPublishingCredentialsPolicies@2022-03-01' = { name: 'ftp' kind: 'string' parent: secondaryApp location: secondaryLocation properties: { allow: false } } resource secondaryScmPolicy 'Microsoft.Web/sites/basicPublishingCredentialsPolicies@2022-03-01' = { name: 'scm' kind: 'string' parent: secondaryApp location: secondaryLocation properties: { allow: false } } resource secondaryAppSlot 'Microsoft.Web/sites/slots@2020-06-01' = { name: '${secondaryAppName}/stage' location: secondaryLocation kind: 'app' identity: { type: 'SystemAssigned' } properties: { serverFarmId: secondaryAppServicePlan.id httpsOnly: true siteConfig: { detailedErrorLoggingEnabled: true httpLoggingEnabled: true requestTracingEnabled: true ftpsState: 'Disabled' minTlsVersion: '1.2' ipSecurityRestrictions: [ { tag: 'ServiceTag' ipAddress: 'AzureFrontDoor.Backend' action: 'Allow' priority: 100 headers: { 'x-azure-fdid': [ frontDoorProfile.properties.frontDoorId ] } name: 'Allow traffic from Front Door' } ] } } dependsOn: [ secondaryApp ] } resource secondaryFtpPolicySlot 'Microsoft.Web/sites/slots/basicPublishingCredentialsPolicies@2022-03-01' = { name: 'ftp' kind: 'string' parent: secondaryAppSlot location: secondaryLocation properties: { allow: false } } resource secondaryScmPolicySlot 'Microsoft.Web/sites/slots/basicPublishingCredentialsPolicies@2022-03-01' = { name: 'scm' kind: 'string' parent: secondaryAppSlot location: secondaryLocation properties: { allow: false } } resource frontDoorEndpoint 'Microsoft.Cdn/profiles/afdEndpoints@2021-06-01' = { name: frontDoorEndpointName parent: frontDoorProfile location: 'global' properties: { enabledState: 'Enabled' } } resource frontDoorOriginGroup 'Microsoft.Cdn/profiles/originGroups@2021-06-01' = { name: frontDoorOriginGroupName parent: frontDoorProfile properties: { loadBalancingSettings: { sampleSize: 4 successfulSamplesRequired: 3 } healthProbeSettings: { probePath: '/' probeRequestType: 'HEAD' probeProtocol: 'Http' probeIntervalInSeconds: 100 } } } resource frontDoorOrigin 'Microsoft.Cdn/profiles/originGroups/origins@2021-06-01' = { name: frontDoorOriginName parent: frontDoorOriginGroup properties: { hostName: app.properties.defaultHostName httpPort: 80 httpsPort: 443 originHostHeader: app.properties.defaultHostName priority: 1 weight: 1000 } } resource secondaryFrontDoorOrigin 'Microsoft.Cdn/profiles/originGroups/origins@2021-06-01' = { name: secondaryFrontDoorOriginName parent: frontDoorOriginGroup properties: { hostName: secondaryApp.properties.defaultHostName httpPort: 80 httpsPort: 443 originHostHeader: app.properties.defaultHostName priority: 2 weight: 1000 } } resource frontDoorRoute 'Microsoft.Cdn/profiles/afdEndpoints/routes@2021-06-01' = { name: frontDoorRouteName parent: frontDoorEndpoint dependsOn: [ frontDoorOrigin // This explicit dependency is required to ensure that the origin group is not empty when the route is created. ] properties: { originGroup: { id: frontDoorOriginGroup.id } supportedProtocols: [ 'Http' 'Https' ] patternsToMatch: [ '/*' ] forwardingProtocol: 'HttpsOnly' linkToDefaultDomain: 'Enabled' httpsRedirect: 'Enabled' } } output appServiceHostName string = app.properties.defaultHostName output secondaryAppServiceHostName string = secondaryApp.properties.defaultHostName output appServiceSlotHostName string = appSlot.properties.defaultHostName output secondaryAppServiceSlotHostName string = secondaryAppSlot.properties.defaultHostName output frontDoorEndpointHostName string = frontDoorEndpoint.properties.hostName ","categories": ["networking"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2022/12/02/multi-region-web-app.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "How to deploy a secure n-tier web app",
+ "excerpt":"Many applications will consist of more than just a single component. For example, you may have a frontend which is publicly accessible that connects to a backend database, storage account, key vault, another VM, or a combination of these, which make up what’s known as an n-tier application. It’s important that applications like this are architected so that access is limited to privileged individuals and any component that is not intended for public consumptions is locked down to the greatest extent available for your use case. In this blog post, we’ll walk through setting up a web app with a secure, network-isolated communication to a backend web app. All traffic will be isolated within your virtual network using virtual network integration and private endpoints. This configuration can be used for a number of use cases and it’s architecture can be extended or modified, for example in this blog post where a web app securely connects to a backend cognitive service that detects the language of input text. For more information on n-tier applications including additional scenarios and multi-region considerations, see Multi-region N-tier application. Also, see the Reliable Web App Pattern for additional context and details on deploying more complex scenarios. This scenario is intentionally kept simple to focus on the key concepts of the architecture and configuration since they are reusable and can easily be replicated across many application patterns. We’ll also be diving into secure source code deployment best practices which is a key part of web app management. This post is organized into the following steps: Create network infrastructure Create backend web app Create frontend web app Deploy application source code Architecture Workflow The architecture is shown in the diagram above. Frontend web app. This architecture uses two web apps - a frontend that is accessible over the public internet, and a private backend web app. The frontend web app is integrated into the virtual network in the subnet with the feature regional VNet integration and it is configured to consume a DNS private zone. Backend web app. The backend web app is only exposed through a private endpoint via another subnet in the virtual network. Direct communication to the backend web app is explicitly blocked. The only resource or principal that is allowed to connect to the backend is the frontend web app using the private endpoint. Note that virtual network integration and private endpoints are now available all the way down to the Basic SKU. App Services using the Free tier don’t support this at this time. Getting started This is the second article in a series focusing on App Service patterns. If you missed the first one on secure multi-region deployments, you can find it here. This guide will use the Azure CLI to set up the environment and deploy the web apps. Additional configurations will be done using the Azure portal as it is easier to demonstrate what is going on there. Keep in mind that everything that is being done in this blog post can be done using the Azure CLI, Azure PowerShell, Azure portal, and Azure Resource Manager (ARM) templates. A complete ARM template that deploys the core resources in this post is given at the end of this post. An Azure account with an active subscription is required. Create an account for free. Create network infrastructure First, set up a Resource Group with a Virtual Network. The virtual network should have at least two subnets: one for the virtual network integration and one for the private endpoint. The address-prefix size must be at least /28 for both subnets; small subnets can affect scaling limits and the number of private endpoints. Go with /24 for both subnets if you are not under constraints. Be sure to replace the placeholders for resource group name and virtual network name. az group create --name <resource-group-name> --location eastus az network vnet create --resource-group <resource-group-name> --location eastus --name <vnet-name> --address-prefixes 10.0.0.0/16 For the subnets, there are two settings that you need to pay attention to. This is often set by the portal or scripts, but here it is called out directly. A delegation of “Microsoft.Web/serverfarms” informs the subnet that it’s reserved for virtual network integration. az network vnet subnet create --resource-group <resource-group-name> --vnet-name <vnet-name> --name vnet-integration-subnet --address-prefixes 10.0.0.0/24 --delegations Microsoft.Web/serverfarms az network vnet subnet create --resource-group <resource-group-name> --vnet-name <vnet-name> --name private-endpoint-subnet --address-prefixes 10.0.1.0/24 The last part of the network infrastructure is the Private DNS Zone. Private DNS Zones are used to host the DNS records for private endpoints allowing clients to find the backend services by name. We’ll be creating the private endpoint using the portal, so the Private DNS Zone will be created automatically for us. Go here for a primer on Azure Private Endpoints and go here for how DNS Zones are used with private endpoints. Create two instances of a web app You’ll need two instances of a web app for this tutorial. You’ll need to use at least the Basic SKU in order to be able to use virtual network integration and private endpoints. You’ll take care of the vnet integration and additional configurations later on - first you’ll get the apps deployed. You’ll first deploy a single App Service plan. You’ll then deploy two web apps in that App Service plan. Run the following command to create the App Service plan. Replace the placeholders for App Service plan name and resource group name. az appservice plan create --name <app-service-plan-name> --resource-group <resource-group-name> --is-linux --location eastus --sku P1V2 Once the App Service plan is created, run the following commands to create the web apps. Replace the placeholders with your globally distinct web app names and your App Service plan name. If you’re following along in this tutorial, you’ll be deploying a Node.js app later on, so we’ll set the runtime now. Feel free to change this value based on the app you want to deploy. Run az webapp list-runtimes for a list of the possible runtimes you can choose from. az webapp create --name <frontend-web-app-name> --resource-group <resource-group-name> --plan <app-service-plan-name> --runtime \"NODE:18-lts\" az webapp create --name <backend-web-app-name> --resource-group <resource-group-name> --plan <app-service-plan-name> --runtime \"NODE:18-lts\" Disable basic auth for the web apps Consider disabling basic auth on App Service, which limits access to the FTP and SCM endpoints to users that are backed by Azure Active Directory (AAD). Disabling basic auth will require additional steps to configure continuous deployment. We’ll go through this as well later on in this post. To disable FTP access to the site, run the following CLI command. Replace the placeholders with your resource group and site name. Be sure to run this command for each of your apps. az resource update --resource-group <resource-group-name> --name ftp --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-name> --set properties.allow=false To disable basic auth access to the WebDeploy port and SCM site, run the following CLI command. Replace the placeholders with your resource group and site name. az resource update --resource-group <resource-group-name> --name scm --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-name> --set properties.allow=false For more information on disabling basic auth including how to test and monitor logins, see Disabling basic auth on App Service. Configure virtual network integration for the frontend web app The virtual network integration feature allows outbound traffic to flow directly into the virtual network. We’ll use the portal to configure this as well as the private endpoint in the next step. In the Azure portal, go to your frontend web app and then go to the Networking page. Select VNet Integration. Select + Add VNet. Select the virtual network you created earlier. For Subnet, select “Select Existing” and then select the “vnet-integration-subnet”. Select OK to save your configuration. You can now browse to the web app and all outbound traffic from the frontend web app will be routed through the virtual network. Create the private endpoint for the backend web app The last part of the core infrastructure setup is to create the private endpoint to allow secure communication between your frontend and your backend. Adding a private endpoint by default disables all public access to your app. By enabling a private endpoint on your backend web app, all inbound traffic will therefore use the private endpoint to reach it. The only resources that are allowed to use the private endpoint to connect to your backend web app are the ones in your virtual network. In the Azure portal, go to your backend web app and then go to the Networking page. Under Inbound address, you’ll see the public IP that was automatically delegated to your web app. Note that when you add the private endpoint, this will change to a private IP from your Azure virtual network address space. Select Private endpoints. Select + Add. Give your private endpoint a name, select the virtual network you created earlier, and select the “private-endpoint-subnet”. Make sure Integrate with private DNS zone is set to “Yes”. If you want to set up your own Private DNS Zone, you can find details for that here. Select OK to save your configuration. Creating the private endpoint from the portal is the simplest method as it does a number of actions in the background for you including linking the zone to your virtual network. If you create the Private DNS Zone manually, you will need to create the link manually. If you go back to the Networking page for your backend web app, you’ll see that the inbound address has changed to a private IP address from your virtual network. You’ll also see that access restrictions have turned on. If you view the Access restriction (preview), you see public access has been disabled. Disabling public network access blocks all incoming traffic except the traffic that comes from private endpoints. Lock down SCM/advanced tool site Earlier on when you were creating the web apps, you disabled basic authentication to the WebDeploy port and SCM site. You’ll want to also disable all public access to the SCM site. This has already been done for the backend web app when you added the private endpoint. You will only need to do this for the frontend web app. Doing this, however, limits how code can be deployed to your app. Later on, we’ll walk through how to give a service principal access to deploy your source code. To disable public access, navigate to the Access restriction (preview) page for your frontend web app and select the Advanced tool site tab. For the Unmatched rule action, select “Deny”, then Save, and Continue. You can’t deny all public access using the checkbox at the top because that will deny public access to your frontend’s main site as well. Doing this would prevent your users from being able to access your frontend which is not what we want. Checkpoint At this point, all of the baseline infrastructure has been deployed and you are ready to deploy your source code. We’ll walk through how to do that securely in the next part of the blog post, but first, let’s validate our connections and app access. Starting with the backend, try navigating directly to your backend’s endpoint. This can be found on the Overview page for the backend web app and should be in the format https://backend-web-app-name.azurewebsites.net. If you’ve configured things correctly, public access should be blocked and you should get an error page. You should see a similar error page when trying to navigate to the backend’s SCM site. The endpoint for that is in the format https://backend-web-app-name.scm.azurewebsites.net. To validate the frontend, we’ll need to ensure it is publicly accessible and that it can reach the backend only using the private endpoint. Try navigating to your frontend’s endpoint. You should see content similar to what is shown below. This means your frontend is publicly accessible and ready for your source code as intended. Try navigating to your frontend’s SCM site as well and confirm that access is denied. To validate the connection between the frontend and the backend, you’ll need access to the SCM site. For this, the simplest method if you’ve been following along is you can add a temporary rule to your frontend’s access restrictions that allows access from your IP. See the below screenshot for an example. For source, use your IP address. Navigate to the SCM site for your frontend by going to https://frontend-web-app-name.scm.azurewebsites.net/. If you can’t access it, make sure you’ve added the rule for your IP as shown above. Select SSH from the menu bar at the top. Doing this creates an SSH session on your frontend’s instances. Once that loads, you’re going to do an “nslookup” on your backend to confirm that it can be reached from the frontend using the private endpoint. Type “nslookup backend-web-app-name.azurewebsites.net”. Under the “Non-authoritative answer”, it should resolve the private IP address you noted earlier. You can also do a “curl” on your backend’s endpoint to display the backend’s current site contents. For now, curl will display the HTML for the empty web app. Repeat the same nslookup and curl commands from another terminal (one that is not an SSH session from your frontend’s instances). The nslookup will return the public IP for the backend web app. Since we blocked public access to the backend web app, if you try to reach the public IP, you will get an access denied error which means this site will not be accessible from the public internet, which is what we want. The nslookup doesn’t resolve the private IP because that can only be reached from within the virtual network using the private endpoint and only the frontend web app is within the virtual network. If you try to do a curl on the backend from an external terminal, you’ll see the HTML returns “Web App - Unavailable”, which is the HTML for the error page you saw earlier when you tried navigating to the backend in your browser. Now that you’ve validated your connections, you’re all set to deploy some code. Make sure you remove the rule that allows access to your frontend’s SCM site if you no longer need it. Source code management A number of best practices were described in the previous blog post, which went over how to manage source code across multiple regions. Those same concepts can be applied here. For completeness, we’ll go over the important parts to get your n-tier app up and running. Prerequisites for source code deployment We’ll be using a two Node.js apps hosted on GitHub. If you don’t already have a GitHub account, create an account for free. Go to the Node.js backend sample app. This is a simple Hello World app. Select the Fork button in the upper right on the GitHub page. Select the Owner and leave the default Repository name. Select Create fork. Repeat the same process for the Node.js frontend sample app. This is a basic web scraping app that I built specifically for this blog post. At this point, your source code is all set up and ready to be deployed to your apps. Create staging slots and configure continuous deployment Configuring continuous deployment for production apps is not recommended because it makes testing and validation more complicated. Instead, use a combination of staging slots and slot swap to move code from your testing/staging environment to production. We’ll create deployment slots for each of our apps and then walk through how to slot swap to get the code into production. Go to one of your apps. In the left pane, select Deployment slots. Select + Add Slot. Input “stage” for Name and to keep things simple, we’ll clone the settings from the production slot by selecting the app’s name from the Clone settings from: dropdown. Select Close at the bottom of the slot configuration pane. Select the newly created stage slot. Cloning settings to a slot doesn’t clone every possible setting. In this case, depending on how you’ll be using the slots, you’ll need to disable basic auth for both app slots, create another private endpoint for the backend slot, and implement virtual network integration for the frontend slot. The process for this is the same as before. Pay attention to the access restrictions on the SCM sites if you do recreate the private endpoint as that will disable public access to it and prevent GitHub from reaching your staging slots. You’ll need to allow public access to the Advanced tools site as was done in the previous blog post. To disable basic auth for the slots, make sure you update the --parent parameter as shown in the below example. Repeat the same command for “ftp” and for your other app as you did previously. az resource update --resource-group <resource-group-name> --name scm --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-name>/slots/<slot-name> --set properties.allow=false Now that the staging slots are properly configured and locked down, you can configure continuous deployment. In the left pane, select Deployment Center and make sure you’re on the Settings tab. For Source, select “GitHub”. If you’re deploying from GitHub for the first time, select Authorize and follow the authorization prompts. After you authorize your Azure account with GitHub, select the Organization, Repository, and Branch to configure CI/CD as shown below. If you can’t find an organization or repository, you might need to enable more permissions on GitHub. For more information, see Managing access to your organization’s repositories. Setting Description Organization <your GitHub username> Repository nodejs-backend Branch main Leave the remaining defaults and select Save. You can track the deployment and commits in the Logs tab in the Deployment Center to monitor progress. Repeat the above steps for your other app. Since you locked down the SCM sites and disabled basic auth for your apps, the default method for deploying code with GitHub Actions isn’t going to work. You’ll see that the deployment failed if you review the logs. This is because the default method uses a publishing profile. Instead, you have two options to authenticate with App Service for GitHub Actions - using a service principal or OpenID Connect. We have a detailed doc that goes through how to do this for each of your options - Deploy to App Service using GitHub Actions. We also have guidance for Azure DevOps using Azure Pipelines. Additionally, for more info on this topic as well as additional examples, we have a series of blog posts that walk through scenarios you may be interested in. Deploying to Network-secured sites Deploying to Network-secured sites, Part 2 For this blog post, we’ll walk through how to authenticate with App Service for GitHub Actions using a service principal. Configure authentication with App Service for GitHub Actions with a service principal Run the following command to create the service principal. Replace the placeholders with your subscription ID, resource group name, and frontend and backend app names. The output is a JSON object with the role assignment credentials that provide access to your App Service apps. Copy this JSON object for the next step. It will include your client secret which will only be visible at this time. It is always a good practice to grant minimum access. The scope in this example is limited to the specific frontend and backend web apps and not the entire resource group. az ad sp create-for-rbac --name \"myApp\" --role contributor --scopes /subscriptions/<subscription-id>/resourceGroups/<group-name>/providers/Microsoft.Web/sites/<frontend-web-app-name> /subscriptions/<subscription-id>/resourceGroups/<group-name>/providers/Microsoft.Web/sites/<backend-web-app-name> --sdk-auth You need to provide your service principal’s credentials to the login action as part of the GitHub Action workflow you will be using. These values can either be provided directly in the workflow or can be stored in a GitHub secret and referenced in your workflow. Saving the values as GitHub secrets is the more secure option. Open one of your GitHub repositories and go to Settings > Security > Secrets and variables > Actions > New repository secret. Paste the entire JSON output from the Azure CLI command from the initial step into the secret’s value field. Give the secret the name AZURE_CREDENTIALS. When you configure the workflow file later, you use the secret for the input creds of the Azure Login action. Create the following secrets. Name Value AZURE_APP_ID <application/client-id> AZURE_PASSWORD <client-secret> AZURE_TENANT_ID <tenant-id> AZURE_SUBSCRIPTION_ID <subscription-id> Repeat this process for your other repository. Create the GitHub Actions workflow Now that you have a service principal that can access your App Services, you need to edit the default workflow that was created for your apps when you configured continuous deployment so that it uses your service principal to authenticate instead of the publishing profile. For sample workflows, see the “Service principal” tab in Deploy to App Service. If you’ve been following along, use the below workflow. Open your backend app’s GitHub repository and go to the nodejs-backend/.github/workflows/ directory. You’ll see the autogenerated workflow. Select the “pencil” button in the top right to edit the file. Replace the contents with the below, which assumes you created the GitHub secrets earlier for your credential, update the placeholders under “env”, and then commit directly to the main branch. This commit will trigger the GitHub Action to run again and deploy your code, this time using the service principal to authenticate. name: Build and deploy Node.js app to Azure Web App on: push: branches: - main workflow_dispatch: env: AZURE_WEBAPP_NAME: <web-app-name> # set this to your application's name NODE_VERSION: '18.x' # set this to the node version to use AZURE_WEBAPP_PACKAGE_PATH: '.' # set this to the path to your web app project, defaults to the repository root AZURE_WEBAPP_SLOT_NAME: stage # set this to your application's slot name jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 - name: Set up Node.js version uses: actions/setup-node@v1 with: node-version: ${{ env.NODE_VERSION }} - name: npm install, build run: | npm install npm run build --if-present - name: Upload artifact for deployment job uses: actions/upload-artifact@v2 with: name: node-app path: . deploy: runs-on: ubuntu-latest needs: build environment: name: 'stage' url: ${{ steps.deploy-to-webapp.outputs.webapp-url }} steps: - name: Download artifact from build job uses: actions/download-artifact@v2 with: name: node-app - uses: azure/login@v1 with: creds: | { \"clientId\": \"${{ secrets.AZURE_APP_ID }}\", \"clientSecret\": \"${{ secrets.AZURE_PASSWORD }}\", \"subscriptionId\": \"${{ secrets.AZURE_SUBSCRIPTION_ID }}\", \"tenantId\": \"${{ secrets.AZURE_TENANT_ID }}\" } - name: 'Deploy to Azure Web App' id: deploy-to-webapp uses: azure/webapps-deploy@v2 with: app-name: ${{ env.AZURE_WEBAPP_NAME }} slot-name: ${{ env.AZURE_WEBAPP_SLOT_NAME }} package: ${{ env.AZURE_WEBAPP_PACKAGE_PATH }} - name: logout run: | az logout Repeat this process for for the frontend app. The workflow can be found in nodejs-frontend/.github/workflows/. After a couple minutes, the deployments to the two app’s staging slots will finish. Your backend web app slot is locked down, but you can update the access restrictions for it if you want to validate that the code was deployed. Alternatively, you can skip that and go straight to the frontend app slot and test from there. Navigate to your frontend in a browser. The URL should look like https://frontend-web-app-name-stage.azurewebsites.net. The frontend app is a simple web scraper that will display the HTML body of a website. All it’s doing is calling the backend app and if it can reach the backend, it will display the site contents of the backend web app. I designed this site to work specifically with the provided backend web app. The web scraper will work with other sites, but the HTML it will return will be messy. Get your backend slot’s URL and paste that into the textbox. Hit “Go”, and after a couple seconds, you should see “Hello from the backend web app!” which is the site contents for the backend. If the app crashes, that means your access restrictions or private endpoint are misconfigured. If you didn’t set up the private endpoint and virtual network infrastructure for your slots, you can skip this testing as you’ve already validated it works in production. If all goes well, you’re ready to slot swap into production. Slot swap Once you’re done testing and validating, you can perform a slot swap from your staging site to your production site for each of your apps. During a slot swap, the App Service platform ensures the target slot doesn’t experience downtime. To perform the swap: Go to your app’s Deployment slots page and select Swap. The Swap dialog box shows settings in the selected source and target slots that will be changed. Select the desired Source and Target slots. Also, select the Source Changes and Target Changes tabs and verify that the configuration changes are expected. When you’re finished, you can swap the slots immediately by selecting Swap. Repeat the process for your other app. After a few minutes, you can navigate to your production frontend app to validate the slot swap succeeded. You should copy and paste your production backend app’s URL into the textbox and confirm you get the message “Hello from the backend web app!”. If you do, congrats, you completed the tutorial! If the app crashes, go back through this post to ensure your connections are configured properly. At this point, your apps are up and running and any changes you make to your source code will automatically trigger an update to both of your staging apps. You can then repeat the slot swap process described above when you’re ready to move that code into production. Clean up resources After you’re done, you can remove all the items you created. Deleting a resource group also deletes its contents. Deploy from ARM/Bicep All of the resources in this post can be deployed using an ARM/Bicep template. A sample template is shown below, which creates empty apps following the security best practices outlined in this post. You’ll need to configure the slots and deployment source as well as the service principal once the template resources are created. To learn how to deploy ARM/Bicep templates, see How to deploy resources with Bicep and Azure CLI. @description('Name of the VNet') param virtualNetworkName string = 'vnet-ntier' @description('Name of the Web Farm') param serverFarmName string = 'serverfarm-ntier' @description('Backend name must be unique DNS name worldwide') param site1_Name string = 'backend-${uniqueString(resourceGroup().id)}' @description('Frontend name must be unique DNS name worldwide') param site2_Name string = 'frontend-${uniqueString(resourceGroup().id)}' @description('CIDR of your VNet') param virtualNetwork_CIDR string = '10.200.0.0/16' @description('Name of the subnet') param subnet1Name string = 'PrivateEndpointSubnet' @description('Name of the subnet') param subnet2Name string = 'VnetIntegrationSubnet' @description('CIDR of your subnet') param subnet1_CIDR string = '10.200.1.0/24' @description('CIDR of your subnet') param subnet2_CIDR string = '10.200.2.0/24' @description('Location for all resources.') param location string = resourceGroup().location @description('SKU name, must be minimum P1v2') @allowed([ 'P1v2' 'P2v2' 'P3v2' ]) param skuName string = 'P1v2' @description('SKU size, must be minimum P1v2') @allowed([ 'P1v2' 'P2v2' 'P3v2' ]) param skuSize string = 'P1v2' @description('SKU family, must be minimum P1v2') @allowed([ 'P1v2' 'P2v2' 'P3v2' ]) param skuFamily string = 'P1v2' @description('Name of your Private Endpoint') param privateEndpointName string = 'PrivateEndpoint1' @description('Link name between your Private Endpoint and your Web App') param privateLinkConnectionName string = 'PrivateEndpointLink1' var webapp_dns_name = '.azurewebsites.net' var privateDNSZoneName = 'privatelink.azurewebsites.net' var SKU_tier = 'PremiumV2' resource virtualNetwork 'Microsoft.Network/virtualNetworks@2020-06-01' = { name: virtualNetworkName location: location properties: { addressSpace: { addressPrefixes: [ virtualNetwork_CIDR ] } subnets: [ { name: subnet1Name properties: { addressPrefix: subnet1_CIDR privateEndpointNetworkPolicies: 'Disabled' } } { name: subnet2Name properties: { addressPrefix: subnet2_CIDR delegations: [ { name: 'delegation' properties: { serviceName: 'Microsoft.Web/serverfarms' } } ] privateEndpointNetworkPolicies: 'Enabled' } } ] } } resource serverFarm 'Microsoft.Web/serverfarms@2020-06-01' = { name: serverFarmName location: location sku: { name: skuName tier: SKU_tier size: skuSize family: skuFamily capacity: 1 } kind: 'app' properties: { reserved: true } } resource webApp1 'Microsoft.Web/sites@2020-06-01' = { name: site1_Name location: location kind: 'app' properties: { serverFarmId: serverFarm.id } } resource ftpPolicy1 'Microsoft.Web/sites/basicPublishingCredentialsPolicies@2022-03-01' = { name: 'ftp' kind: 'string' parent: webApp1 location: location properties: { allow: false } } resource scmPolicy1 'Microsoft.Web/sites/basicPublishingCredentialsPolicies@2022-03-01' = { name: 'scm' kind: 'string' parent: webApp1 location: location properties: { allow: false } } resource webApp2 'Microsoft.Web/sites@2020-06-01' = { name: site2_Name location: location kind: 'app' properties: { serverFarmId: serverFarm.id virtualNetworkSubnetId: resourceId('Microsoft.Network/virtualNetworks/subnets', virtualNetwork.name, subnet2Name) vnetRouteAllEnabled: true } } resource ftpPolicy2 'Microsoft.Web/sites/basicPublishingCredentialsPolicies@2022-03-01' = { name: 'ftp' kind: 'string' parent: webApp2 location: location properties: { allow: false } } resource scmPolicy2 'Microsoft.Web/sites/basicPublishingCredentialsPolicies@2022-03-01' = { name: 'scm' kind: 'string' parent: webApp2 location: location properties: { allow: false } } resource webApp1Config 'Microsoft.Web/sites/config@2020-06-01' = { parent: webApp1 name: 'web' properties: { ftpsState: 'AllAllowed' } } resource webApp2Config 'Microsoft.Web/sites/config@2020-06-01' = { parent: webApp2 name: 'web' properties: { ftpsState: 'AllAllowed' scmIpSecurityRestrictionsDefaultAction: 'Deny' } } resource webApp1Binding 'Microsoft.Web/sites/hostNameBindings@2019-08-01' = { parent: webApp1 name: '${webApp1.name}${webapp_dns_name}' properties: { siteName: webApp1.name hostNameType: 'Verified' } } resource webApp2Binding 'Microsoft.Web/sites/hostNameBindings@2019-08-01' = { parent: webApp2 name: '${webApp2.name}${webapp_dns_name}' properties: { siteName: webApp2.name hostNameType: 'Verified' } } resource privateEndpoint 'Microsoft.Network/privateEndpoints@2020-06-01' = { name: privateEndpointName location: location properties: { subnet: { id: resourceId('Microsoft.Network/virtualNetworks/subnets', virtualNetwork.name, subnet1Name) } privateLinkServiceConnections: [ { name: privateLinkConnectionName properties: { privateLinkServiceId: webApp1.id groupIds: [ 'sites' ] } } ] } } resource privateDnsZones 'Microsoft.Network/privateDnsZones@2018-09-01' = { name: privateDNSZoneName location: 'global' dependsOn: [ virtualNetwork ] } resource privateDnsZoneLink 'Microsoft.Network/privateDnsZones/virtualNetworkLinks@2018-09-01' = { parent: privateDnsZones name: '${privateDnsZones.name}-link' location: 'global' properties: { registrationEnabled: false virtualNetwork: { id: virtualNetwork.id } } } resource privateDnsZoneGroup 'Microsoft.Network/privateEndpoints/privateDnsZoneGroups@2020-03-01' = { parent: privateEndpoint name: 'dnsgroupname' properties: { privateDnsZoneConfigs: [ { name: 'config1' properties: { privateDnsZoneId: privateDnsZones.id } } ] } } ","categories": ["networking"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2022/12/02/n-tier-web-app.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Improving the dump analysis journey in Diagnose and Solve",
+ "excerpt":"We are happy to announce that our most recent improvements to Diagnose and Solve Problems allow you to begin the analysis on a collected memory dump immediately in the Azure portal! For problems that do not manifest in logs or that you cannot investigate by debugging locally, you might attempt to capture a diagnostics artifact, like a memory dump, while the issue is active in your production environment. Diagnostics tools found under Diagnose and Solve Problems have enabled you to capture artifacts like memory dumps on demand or by using Custom Auto Heal for both Linux and Windows. However, capturing the right memory dump at the right time is only half the battle, you also have to have the right tools and experience to interpret the memory dump. Thankfully Diagnostics Analysis can be configured to run immediately following the capture of a memory dump. The analysis report will provide a summary of the most pertinent information in the memory dump, and will also highlight several important data points and even potential red flags that might require a code fix. Analysis Report: The dump summary The first step in the analysis is confirming the fundamentals. In the following image, you can see the summary presented by the analysis report, highlighting common helpful information like the process name, process architecture, or how long the process has been running. It also includes information on the platform version as well as the reason for the collection. In future versions of the report, we will also support opening the memory dump in Visual Studio with one click (will require the appropriate permissions to the Azure storage location). Analysis Report: Dump analyzers In addition to this initial summary you also have the results of the analyzers that were run against the dump, today these include: Thread pool analysis Sync over async anti-pattern detection Deadlock detection Exception on the heap Managed heap summary Large + pinned objects on the heap SQL connections analysis Inbound HTTP request Outbound HTTP requests Socket connections Unique call stacks Symbol detection Source Link detection Synchronization objects that are blocking threads Analysis Report: Advanced call stacks One of the most important diagnostics artifacts for production debugging is the call stack. During a typical dump debugging session, reviewing the list of threads and the associated call stacks is a great way to understand what was happening at the moment the dump was captured. Given the importance of the call stack, the Diagnostics Analysis report provides an improved in-browser experience for call stack analysis. The advanced call stacks are explicitly designed to accurately reflect the call stack names and layout you have become accustomed to in Visual Studio. You can initiate the advanced call stack view by clicking on any of the stack frame hyperlinks. It then also allows you to filter larger call stacks using method or namespace names, as well as quickly switch between viewing Just My Code and the entire framework call stack. Getting to source code with Source Link For many scenarios, the call stack provides enough clues to the source of the problem, however, by taking advantage of Source Link your analysis can be even more precise. What is Source Link? Source Link is a set of packages and a specification for describing source control metadata that can be embedded in symbols, binaries, and packages. Once Source Link is set up your analysis reports will produce active links that navigate directly to your source code. In the following example, an active link in the call stack is pointing directly at a specific file, line, and commit on GitHub. While Source Link is on by default for .NET source, enabling this for your code today requires a couple of additional steps. Setting up Source Link Debugging and diagnostics tools work best when symbols are available, typically the way to do that would be to ensure the PDBs are alongside the DLLs or, as I prefer, use embedded PDBs so they’re quite literally in the DLL already. You can enable Source Link experiences in your own .NET project by adding the following optional items to the property group: <PropertyGroup> <!-- Optional: Publish the repository URL in the built .nupkg (in the NuSpec <Repository> element) --> <PublishRepositoryUrl>true</PublishRepositoryUrl> <!-- Optional: Embed source files that are not tracked by the source control manager in the PDB --> <EmbedUntrackedSources>true</EmbedUntrackedSources> <!-- Optional: Build symbol package (.snupkg) to distribute the PDB containing Source Link --> <IncludeSymbols>true</IncludeSymbols> <SymbolPackageFormat>snupkg</SymbolPackageFormat> </PropertyGroup> For source code hosted by GitHub or GitHub Enterprise you also need to include the following Nuget package: <ItemGroup> <PackageReference Include=\"Microsoft.SourceLink.GitHub\" Version=\"1.1.1\" PrivateAssets=\"All\"/> </ItemGroup> There is also source code link support for Azure Repos, Azure DevOps, GitLab, Bitbucket, gitweb, and gitea. Summary Please check out the improved Diagnose and Solve Problem experiences for App Services for Windows and App Services for Linux! We are actively working on Diagnostics Analysis for traces and we are always interested in your feedback. ","categories": ["diagnostics"],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2022/12/05/Making-diagnostics-analysis-easier-in-Diagnose-and-Solve.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Azure Workbook to help run App Service Plans and App Service Environments",
+ "excerpt":"Anyone running App Service Plan, or App Service Environment at scale should consider if they are running it efficiently. An App Service Plan is so easy to use that we often throw more and more applications at one, without stopping to think about the impact that might have. Different App Service Plan SKUs have different limits. Running an app that consumes 1GB of ram on one SKU could be a concern, but maybe not on another. What about CPU? If you have 16 v-cores then it might not be important to run a CPU intensive app. But run that same app on an App Service plan with fewer cores and you could start to impact other applications on the same plan. Even IO heavy applications that use little RAM and CPU can have impacts. Different App Service Plan SKUs have different amounts of outbound sockets available to them. Every time you make an outbound call you may consume these ports. An app that doesn’t have a connection pool and makes lots of tiny outbound calls could cause another well-behaved app to start throwing errors. There are also specific limits on outbound connections to Public IP addresses that consume SNAT ports. This information isn’t exposed via metrics though. All of these are members of a phenomenon known as Noisy Neighbour Syndrome. They look obvious but it’s not always easy to work out which app is misbehaving. That’s individual applications - there are also constraint limits on the platform. An App Service Plan can have a maximum of 100 instances attached to it. If it’s in an App Service Environment then you’ve got a maximum of 200 instances that can spread across plans. When you’re running at scale it’s easy to start to come close to these limits. But it’s not easy to see how many instances are used across all an App Service Environment. App Services can also have varying amounts of Hybrid connections. Knowing how many are currently in use against an ASP can help you decide which ASP to place new Apps in that use Hybrid Connections. Monitor your metrics with Azure Workbooks All this data is available in various forms, but it’s not been brought together to make it simple to consume. Azure Metrics can capture CPU / RAM / SNAT ports. The resource graph can tell you the SKU of your ASP’s, how many instances are attached to them, and which ASE they belong to. To make it easy to consume we can build an Azure Workbook to surface all this information. Workbooks are awesome – they allow us to build a dashboard which can pull data from a multitude of sources in Azure and present it in a simple clean interface. I’ve built a workbook to present a “single pane of glass” that can give you visibility into your ASE’s and ASP’s. Having insights into the limits will hopefully make it easier for you to run ASP and ASE at scale. Deploy the sample Workbook To try it out clone the repository from Github: App Service Azure Workbook. And then from a CLI run the following. Be sure to replace the placeholder with your resource group name. az deployment group create --resource-group <rg> --template-file .\\infra\\deploy.bicep You can then access the workbook from the Resource Group you deployed to in the Azure Portal. You’ll need to select some subscriptions from the Subscription parameter box to get going: Once you’ve done that the Workbook will load some summary data for all the ASP’s in the subscription: This will show you how many instances / how many apps are associated with the ASP, the tiering, and how many Hybrid Connections are available in total for the ASP. Selecting one of the rows will populate more insights into the ASP: You’ll see the overall CPU / Memory Percentage used across the ASP, along with the total Hybrid Connections active on it. To the right is a summary of all the Apps in the ASP, and the average CPU / Private Bytes / Requests Per Minute, and App Connections being made by them. The final element is a set of charts showing some metrics against each app in the ASP. CPU / Private Bytes. It’s similar data as shown above, but represented visually to allow you to spot anything unusual. Hopefully these insights allow you to ‘right-size’ your App Service Plans and Environments, making them more efficient, more scalable, and more cost effective to run. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2023/01/30/Azure-workbooks-to-help-run-App-Service.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Updates to App Service Overview Blade for Custom Domains",
+ "excerpt":"You may have noticed that we recently rolled out a change in the “Essentials” section of the App Service “Overview” blade in the Azure portal where the URL that is displayed is the default URL for your app. Previously, under certain conditions, there was logic that would display the custom domain you added to your app. For example, if you added the custom domain “app.contoso.com” to your app, the URL displayed on the “Overview” blade would show “https://app.contoso.com” instead of the default URL. If your app was hosted on an App Service Environment, and you added a custom domain suffix to your App Service Environment, the “Overview” blade would show the corresponding URL with that custom domain suffix. We decided to change that behavior to only show the default URL because we were finding that the logic for deciding which URL to show was not meeting the needs of all customers. For example, if a customer added more than one custom domain to an app, which one should be displayed? Showing the default domain ensures consistency for all customers. Additionally, we can’t ensure that when adding a custom domain that that domain will immediately function as intended - there may be additional DNS changes required. We have more confidence that providing a link to the default domain on the “Overview” blade will lead to more successful attempts to reach an app. We were also made aware that some customers have created alerts based on the URL that is displayed in the “Essentials” section of the “Overview” blade - they use the value that is given to determine whether the custom domain they have added to their app has been applied. If this alert/check is a requirement for customers, the recommendation is to use the “Custom domains” blade to validate the domains added to their apps. That blade will show all domains added to the app and should be considered the source of truth. It also gives additional information that will help validate the security of the custom domains. In the following screenshot, the app shown is hosted in an App Service Environment with the custom domain suffix “antares-test.net”. You can see the default domain for this app as well as the domain using the custom domain suffix. If we were to add a custom domain at the app level, for example “app.contoso.com”, that would also be displayed in this blade. Upcoming changes We have an update to the “Overview” blade rolling out in the next few weeks that should help customers quickly identify the custom domains they’ve added to their apps directly from the “Overview” blade. The following is a UX mock of the “Overview” blade showing the upcoming changes that we are implementing. “URL” in the “Essentials” section will be renamed “Default domain” and the default domain will be displayed. A new section under the “Properties” tab will be added called “Domains”, which will list the default domain, the App Service Environment domain if the app is hosted in an App Service Environment with a custom domain suffix, and the custom domain if one is added at the app level. If more than one custom domain is added at the app level, the number of custom domains will be given with a link to the “Custom domains” blade. We hope these changes will provide more clarity for customers. Feedback is welcome as we are always looking to improve our user experience. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2023/02/03/Custom-domain-ux-updates.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Estimate your cost savings by migrating to App Service Environment v3",
+ "excerpt":"If you weren’t already aware, App Service Environment v1 and v2 is retiring on 31 August, 2024. There are many reasons to migrate to App Service Environment v3 including better performance, faster scaling, and reduced overhead since networking dependency management has been greatly simplified. One benefit that stands out that we understand might need some additional explanation is that App Service Environment v3 is often cheaper than previous versions. With the removal of the stamp fee and larger instance sizes per respective SKU with previous versions, App Service Environment v3 can help you do more with less and reduce your monthly spend if you’re familiar with the updates. In this post, we’ll go over a couple common scenarios that will help you better understand App Service Environment v3 pricing and how it compares to your pricing model on App Service Environment v1 or v2. We know there are many scenarios out there, so hopefully one of the ones shared here can be used as an example for you to better understand your situation. The Azure Pricing Calculator is a great resource and will be referenced throughout this post for each scenario. Note that estimates here are based on the prices applicable on the day the estimate was created. Actual total estimates may vary. For the most up-to-date estimate, click the link for each scenario. Refer to the App Service pricing page for more information. NOTE: Unless otherwise indicated, all scenarios are calculated using costs based on Linux $USD pricing in East US. The payment option is set to monthly to simplify cost comparisons. Basic scenarios Scenario 1: Scale down your App Service plans with pay-as-you-go pricing The App Service plan SKUs available for App Service Environment v3 run on the Isolated v2 tier. This is not to be confused with the tier used by App Service Environment v2, which is the Isolated tier. Below are the corresponding service plans for each available tier. Notice that for the Isolated v2 tier, the number of cores and amount of RAM is effectively doubled. We’ll use this information in this scenario. Additionally, there are new larger SKUs available with the Isolated v2 tier that were not previously available with the older version. Isolated Cores RAM (GB) Isolated v2 Cores RAM (GB) I1 1 3.5 → I1v2 2 8 I2 2 7 → I2v2 4 16 I3 4 14 → I3v2 8 32 I4v2 16 64 I5v2 32 128 I6v2 64 256 In this scenario, you are using an App Service Environment v2 with 1 I2 plan. You require 2 cores and 7 GB RAM. You are using pay-as-you-go pricing. On App Service Environment v2, your monthly cost is: Stamp fee + 1(I2) = $991.34 + $416.10 = $1,407.44 If you were to migrate this exact workload to App Service Environment v3, you would be able to scale down from I2 to I1v2 since the Isolated v2 equivalent tier has double the cores and RAM. Your monthly cost on App Service Environment v3 would be: 1(I1v2) = $281.78 As you can see, this is a significant cost savings since you were able to use a smaller tier and the stamp fee is no longer applicable. If you don’t scale down after migrating to v3, you will be over-provisioned and incur unnecessary charges, some of which may make your App Service Environment v3 more expensive than your old environment. Scenario 2: 3 year reserved instance pricing and savings plan Reservations or reserved instance pricing is a discount you can receive if you know what your usage will look like for the next 1 to 3 years. On App Service Environment v2, reservations are supported for the stamp fee. On App Service Environment v3, there is no stamp fee and reservations are supported on the instances themselves. The following scenario will use the same requirements as Scenario 1, but instead of using pay-as-you-go pricing, you will now use 3 year reserved instance pricing since you know your requirements will stay relatively flat over the next 3 years. With reservations, you can pay upfront or monthly. For ease of comparison between the scenarios, monthly payments will be used. On App Service Environment v2 with a 3 year reservation, your monthly cost would be: Stamp fee + 1(I2) = $594.77 + $416.10 = $1,010.87 Notice the 40% reduction in the stamp fee by using reservations. On App Service Environment v3, your monthly cost would be: 1(I1v2) = $127.00 There’s a 55% reduction in the monthly cost as a result of using reserved instance pricing. Azure savings plan for compute is another option that is only available on App Service Environment v3. Azure savings plan for compute is a flexible pricing model that provides savings up to 65 percent off pay-as-you-go pricing when you commit to spend a fixed hourly amount on compute services for one or three years. For this scenario, your cost on App Service Environment v3 with a 3 year savings plan would be: 1(I1v2) = $154.98 Scenario 3: Break even point So far we’ve demonstrated the ways migrating to App Service Environment v3 can save you money. However, there are some cases where this may not be the case. Let’s take for example you have an App Service Environment v2 with a single I1 instance and you’re using pay-as-you-go pricing. Your monthly cost would be: Stamp fee + 1(I1) = $991.34 + $208.05 = $1,199.39 If you migrate this environment to v3, your monthly cost would be: 1(I1v2) = $281.78 This is a significant cost reduction, just know that you’re now over-provisioned since you now have double the cores and RAM, which you may not need. This is not an issue since the new environment is so much cheaper. However, when you start to have many I1 instances in a single App Service Environment, for example because you use this environment for dev or test workloads across multiple different apps and teams, you need to consider the break even point if you migrate to App Service Environment v3. For this scenario, your App Service Environment v2 has 14 I1 instances. Because of how your environment is being used by your team, you can not reduce the number of instances or use a larger instance that has the same effective capacity. Your monthly cost is: Stamp fee + 14(I1) = $991.34 + $2,912.70 = $3,904.04 A migration of this environment to v3 would lead to the following monthly cost: 14(I1v2) = $3,944.92 As you can see, your App Service Environment v3 is slightly more expensive than your v2. As you start adding more I1 instances, and therefore need more I1v2 instances when you migrate, the difference in price becomes even more significant and your v3 will get more and more expensive than your v2. Unfortunately, if you’re in this situation, you may have to plan for a higher monthly cost. NOTE: This calculation was done with Linux $USD prices in East US. Break even points will vary due to price variances in the various regions. For an estimate that reflects your situation, see the Azure Pricing Calculator. The following chart visually depicts the break even point at the time of releasing this blog post using the selected region and price offering where App Service Environment v3 becomes more expensive than v2. If you need more than 13 of our smallest instance offering, you fall into this scenario. There may be other scenarios where this is also the case. Advanced scenarios The first three scenarios were basic and were intended to give you a quick sense of how pricing works on App Service Environment v3. Realistically, you’ll have many more instances and probably be using a combination of the SKUs. The following scenarios will give you a better sense of the cost saving opportunities for these use cases. Scenario 4: SKU mix To accommodate various app types in your App Service Environment v2, you use a combination of the tiers in various quantities. The first estimate will be using pay-as-you-go pricing, and the second will use a 3 year reservation on the stamp fee. Stamp fee + 20(I1) + 10(I2) + 5(I3) = $991.34 + $12,483.00 = $13,474.34 With a 3 year reservation, this becomes: Stamp fee + 20(I1) + 10(I2) + 5(I3) = $594.77 + $12,483.00 = $13,077.77 You can start to see here that as you consume more resources, the reservations available on App Service Environment v2 don’t significantly reduce monthly costs since they only apply to the stamp fee. On App Service Environment v3, you require the same respective core and RAM capacity. There are various paths you can take here depending on your specific requirements - you can keep the same number of instances and just scale them down, or you can reduce the total number instance you are using. For this scenario, we’ll do the following: 20 I1 → 10 I1v2 10 I2 → 10 I1v2 5 I3 → 5 I2v2 With pay-as-you-go pricing, this would be: 20(I1v2) + 5(I2v2) = $8,453.40 And with a 3 year reservation: 20(I1v2) + 5(I2v2) = $3,809.98 At this point, you’re reducing your costs by over 70%. This is where the cost saving benefits of App Service Environment v3 really start to become significant. Even if you were to use pay-as-you-go pricing, you still see cost savings in the form of thousands of dollars per month. Scenario 5: Migration to App Service Environment v3 using the migration feature The migration feature was developed to automate the migration of App Service Environments to v3. It’s an in-place migration, meaning it uses the same subnet your current environment is in. During the migration, your current environment is deleted and an App Service Environment v3 is spun up. All of your instances are automatically converted to their Isolated v2 counterparts (for example I2 is converted to I2v2). Since the Isolated v2 instances are larger, you’ll be over-provisioned if you’re still expecting the same traffic volume. This is a direct scenario where you have the opportunity to scale your instances down similar to what was done in Scenario 4. To keep things consistent, we’ll keep the requirements for this scenario the same as Scenario 4. Your capacity requirements will not change after migration. Prior to migrating, your monthly pay-as-you-go cost is: Stamp fee + 20(I1) + 10(I2) + 5(I3) = $991.34 + $12,483.00 = $13,474.34 Immediately after migrating using the migration feature, your instances have been converted and you have the following leading to a higher monthly cost than what you had on App Service Environment v2. 20 I1 → 20 I1v2 10 I2 → 10 I2v2 5 I3 → 5 I3v2 20(I1v2) + 10(I2v2) + 5(I3v2) = $16,906.80 You’re significantly over-provisioned, so you scale down and immediately reduce your monthly cost by 50%. 20 I1v2 → 10 I1v2 10 I2v2 → 10 I1v2 5 I3v2 → 5 I2v2 20(I1v2) + 5(I2v2) = $8,453.40 You should plan how you will scale down prior to migrating to ensure you don’t get hit with unexpected costs due to being over-provisioned. You’ll be able to scale down immediately after the migration finishes. Scenario 6: Reduce total number of App Service Environments App Service Environments are a great choice for customers that need to scale beyond the limits of the App Service public multi-tenant offering of 30 App Service plan instances. But even the 200 instance limit with App Service Environments may not be enough for some customers. In that case, they need to create multiple App Service Environments. For this scenario, you have 3 App Service Environment v2s all at max capacity with 200 I3 instances in each. Your monthly cost with pay-as-you-go pricing is: 3(Stamp fee + 200(I3)) = $505,268.04 With App Service Environment v3, you have a couple options for how to proceed. You can continue using 3 App Service Environment v3s and just scale down to a smaller SKU, or you can reduce the number of environments by taking advantage of the new larger SKUs. Keeping the same number of environments and scaling down would lead to a monthly cost with pay-as-you-go pricing of: 3(200(I2v2)) = $338,136.00 This would be further reduced if you were to use a reservation or savings plan. If you wanted to reduce the total number of App Service Environments, this would be possible by using the larger SKUs that are only offered on App Service Environment v3. In addition to the potential cost savings you would see by reducing your instance counts and number of environments, you would also realize additional cost savings in the form of overhead since management would be over fewer resources. For this scenario, the requirement is to have the equivalent of 600 I3 instances, or 2400 cores and 8,400 GB RAM. With App Service Environment v3, this can be accomplished with a single App Service Environment with 38 I6v2 instances. The pay-as-you-go monthly cost would be: 38(I6v2) = 38($9,016.96) = $342,644.48 This is just over the cost of the maintaining 3 App Service Environment v3s, but this doesn’t take into account the extra overhead involved in managing multiple resources. With 3 year reserved instance pricing, this monthly cost would be reduced significantly. 38(I6v2) = 38($3,831.055) = $145,580.07 Zone redundant App Service Environment v3 pricing Zone redundant App Service Environment deployments are only supported on App Service Environment v3. There is no additional charge for enabling zone redundancy if you have 9 or more instances. These 9 instances can be made up of any combination of the available SKUs. For example, you can have 9 I1v2s or 3 I1v2s, 3 I2v2s, and 3 I3v2s. You will only be charged for those 9 instances. If you enable zone redundancy, and if your environment has fewer than 9 total instances, you’ll be charged the difference if the form of a minimum instance fee which uses the Windows I1v2 instance price. For example, if you have a zone redundant App Service Environment v3 with 3 Linux I3v2 instances, you will be charged for those 3 I3v2 instances at the standard Linux rate, plus 6 Windows I1v2 instances. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2023/03/02/App-service-environment-v3-pricing.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Updates to App Service Azure Policies that monitor language versions",
+ "excerpt":"Azure Policy for App Service has the following built-in policies that ensure you are using the latest versions of certain languages that are available on the platform. App Service apps that use Java should use the latest ‘Java version’ App Service apps that use Python should use the latest ‘Python version’ App Service apps that use PHP should use the latest ‘PHP version’ Function apps that use Java should use the latest ‘Java version’ Function apps that use Python should use the latest ‘Python version’ Updates We know that for certain customers, using the latest version of a language or runtime isn’t always possible. Additionally, with the variations and possible language versions available, we want to provide a way for our customers to have more flexibility when monitoring the compliance of languages used by their apps. For these reasons, the above policies have been modified. The following changes have been implemented and will be visible in the Azure portal in the next few weeks. The policies no longer have a hard-coded value for the language version they’re monitoring. Instead, the user must specify a version that aligns with their requirements when assigning these policies. When assigning these policies, users will be prompted to specify a language version. The policies have been renamed to align with this updated scope. Below are the new names. App Service apps that use Java should use a specified ‘Java version’ App Service apps that use Python should use a specified ‘Python version’ App Service apps that use PHP should use a specified ‘PHP version’ Function apps that use Java should use a specified ‘Java version’ Function apps that use Python should use a specified ‘Python version’ The policies have been removed from the Azure Security Baseline and Microsoft Defender for Cloud initiatives. The policies can still be assigned and even added to a Microsoft Defender for Cloud initiative, however they won’t be automatically assigned as they previously were. Equivalent policies have been created to monitor compliance for slots. These must be assigned in addition to the policies that monitor the main site in order to ensure monitoring is in place for all App Service resources. App Service app slots that use Python should use a specified ‘Python version’ Function app slots that use Python should use a specified ‘Python version’ App Service app slots that use PHP should use a specified ‘PHP version’ App Service app slots that use Java should use a specified ‘Java version’ Function app slots that use Java should use a specified ‘Java version’ There are also a couple limitations to be aware of when using these policies. They’re scoped to apps on Linux App Service only. If you require monitoring for Windows apps, you can use the existing policies as a reference to create Windows specific custom policies. For more information on building and assigning custom policies, see Tutorial: Create a custom policy definition. These policies use text based matching on a “free-text” field to monitor compliance. Ensure you have proper controls in place to prevent unexpected changes to language versions. Required actions These policy updates will have no impact on existing policy assignments. If you have the old version of these policies assigned, they will continue to function without interruption. In order to use the new versions of these policies, you must create new policy assignments. We encourage you to take this action as soon as possible as the old versions of these policies are prone to false negatives. How to use the new policies The new policies can be assigned in the Azure portal. For more information on how to assign policies, see Assign a policy to a resource group. When assigning these policies in the Azure portal, you won’t automatically be prompted to specify a language version. You must go to the Parameters tab and uncheck the box “Only show parameters that need input or review” in order to see the language version parameter. This is a required parameter that defaults to an empty string so if you don’t specify a value, the policy will always evaluate to non-compliant. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2023/04/24/App-service-language-version-policy-update.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": ".Net 8 Preview 7 now available on App Service",
+ "excerpt":"We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Linux App Service Plans. In the coming weeks, as our deployment progresses, .Net 8 Preview 7 would also be available on Windows App Service Plans. Want to get started with .Net 8? Follow these: Learn more about .Net 8 Preview 7 ASP.Net Core in .Net 8 Download .Net 8 Preview 7 Deploy a .Net app to App Service You can also follow us on twitter for more updates and news: @AzAppService ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2023/09/01/.Net-8-Preview-7-available-on-AppService.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Announcing Public Preview of Free Hosting Plan for WordPress on App Service",
+ "excerpt":"We are excited to announce that we have released the public preview of free hosting plan for WordPress on App Service. We announced the General Availability of WordPress on App Service one year ago, in August 2022 with 3 paid hosting plans. We learnt that sometimes you might need to try out the service before you migrate your production applications. So, we are offering you a playground for a limited period - a free hosting plan to and explore and experiment with WordPress on App Service. This will help you understand the offering better before you make a long-term investment. Note: This hosting plan is not suitable for Production workloads. So, it is highly recommended that you do not use this plan for production setup. Updated Hosting Plans: Hosting Plan WebApp Server Database Server Free F1 Free Tier (60 CPU minutes per day, 1 GB RAM, 1 GB Storage) Burstable, B1ms Free trial (1 vCores, 2 GB RAM, 32 GB storage, 396 IOPS) Basic B1 (1 vCores, 1.75 GB RAM, 10 GB Storage) Burstable, B1s (1 vCores, 1 GB RAM, 20 GB storage, Auto IOPS) Standard P1V2 (1 vCores, 3.5 GB RAM, 250 GB Storage) Burstable, B2s (2 vCores, 4 GB RAM, 128 GB storage, Auto IOPS) Premium P1V3 (2 vCores, 8 GB RAM, 250 GB Storage) General Purpose, D2ds_v4 (2 vCores, 16 GB RAM, 256 GB storage, Auto IOPS) Eligibility: The free hosting plan take advantage of App Service F1 free tier and Azure Database for MySQL free trial. Your eligibility depends on your subscription type: Subscription Type App Service F1 Azure Database for MySQL B1ms Free Account Free Forever 750 hours per month for 12 months Student Account Free Forever 750 hours per month for 12 months Pay as you go with Free MySQL Free Forever 750 hours per month for 12 months Pay as you go without Free MySQL Free Forever Chargeable Note: Please refer to this FAQ for more details on Free Account : Azure Free Account FAQ | Microsoft Azure Features and Limitations: The free hosting plan takes advantage of multiple optimizations and features we built for WordPress on App Service on top of the inbuilt features for App Service and Azure Database for MySQL. Easy and Automated deployments from the Azure Portal Inbuilt Redis cache Accelerated WP Admin using local storage caching PhpMyAdmin for database management However, there are certain points that you need to keep in mind. App Service F1 plan has limited capabilities compared to shared to Basic or Standard plans. Read Azure App Service Plans | Microsoft Learn Azure Database for MySQL has 750 hours of Burstable B1ms instance for this free hosting plan. Read Azure Database for MySQL Free Trial | Microsoft Learn Integration with Paid services such as CDN, Front Door, Blob Storage, and Email Service is not included in the free hosting plan. Local storage caching is limited to 500 MB. We recommend that you do not exceed 500 MB in content, themes, and plugins. Limitations: Since you are running on Free Tier, for App Service there is no support for Scale out capability and ‘Always on’ feature. They are disabled for F1 SKU. There is no VNET support, hence you cannot configure your WordPress site which is on Free trial within a VNET. However to secure your data, you can configure the database behind the private end point. Details on how to configure with private end point can be found here: Use an Azure free account to try Azure Database for MySQL - Flexible Server for free | Microsoft Learn Upgrading to higher SKUs: When running on Azure App Service F1 SKU, it is not supported to scale-out to multiple instances. You can scale-up your App Service to next highest SKU that suits your workloads. Upgrade your WordPress site to higher SKUs based on your workloads. You can refer to the guidance described here: Price reduction in Hosting Plans for WordPress on Azure App Service - Microsoft Community Hub Monitor and track free service usage: You’re not charged for Azure App Service F1 SKU as this SKU is forever free. You’re not charged for Azure Database for MySQL - Flexible Server services included for free with your Azure free account unless you exceed the free service limits. To remain within the limits, use the Azure portal to track and monitor your free services usage. For tracking and monitoring your free services usage, refer to this document: Monitor and track Azure free service usage - Microsoft Cost Management | Microsoft Learn Additional references: How to create student account for College students/teachers/profressors: Azure for Students – Free Account Credit | Microsoft Azure How to create Azure Free account: Create Your Azure Free Account Today | Microsoft Azure Support and Feedback: In case you need any support, you can open a support request at New support request - Microsoft Azure. For more details about the offering, please visit Azure/wordpress-linux-appservice (github.com) If you have any ideas about how we can make WordPress on Azure App Service better, please post your ideas at Post idea · Community (azure.com) or report an issue at Issues · Azure/wordpress-linux-appservice (github.com) or you could email us at wordpressonazure@microsoft.com to start a conversation. ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2023/09/05/WordPress-Free-Hosting-Plan-Public-Preview.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": ".Net 8 Preview 7 now available on App Service",
+ "excerpt":"We are happy to announce that App Service now supports apps targeting .Net 8 Preview 7 across all public regions on Azure App Service. It is available for both Windows and Linux App Service Plans. Want to get started with .Net 8? Follow these: Learn more about .Net 8 Preview 7 ASP.Net Core in .Net 8 Download .Net 8 Preview 7 Deploy a .Net app to App Service You can also follow us on twitter for more updates and news: @AzAppService ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2023/09/22/net-8-preview-7-available-on-app-service.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"},{
+ "title": "Recently Announced: Advanced Clustering Features for JBoss EAP on Azure App Service",
+ "excerpt":"A new era of high availability and scalability If you’re running distributed applications on JBoss EAP, you know that clustering is essential for data consistency and fault tolerance. We’ve taken this a step further on Azure App Service. Now, when you integrate JBoss EAP with an Azure Virtual Network (VNet), clustering isn’t just an option; it’s a built-in feature that kicks in automatically. What does this mean for your apps? For starters, it improves fault tolerance and enables more efficient data sharing across multiple instances. Your application can now handle traffic spikes and server failures better. The service scales based on your configured settings in Azure App Service, providing both vertical and horizontal options. One key update in this release is the automatic enablement of clustering when you activate VNet Integration for your web application. This results in a high-availability setup right from the get-go. We’ll delve into the technical specifics below. Enabling VNet integration is required for communication between servers that form the cluster. Clustering is enabled automatically but can be disabled using an Application Setting (WEBSITE_DISABLE_CLUSTERING). What’s Included Clustering of web applications, including HTTP session replication, HA (high availability), and Singleton Service. For more information, see Chapter 6. Clustering in Web Applications - Red Hat Customer Portal High-availability support Transaction recovery support Configuration You can configure the behavior of the clustering-related features using these Application Settings: WEBSITE_JBOSS_SERVER_DIR defines the parent location of the JBoss state and transaction files. If customers use a location mounted from Azure Storage, this setting improves the availability of the application by avoiding using the /home directory, which becomes read-only during platform upgrades. WEBSITE_JBOSS_CLUSTER_DIR defines the location of the cluster definition files. Similar to the previous setting, if you use a location mounted from Azure Storage, this setting improves the availability of the application by avoiding using the /home directory which becomes read-only during platform upgrades. JBOSS_LAUNCHER_OPTS passes options directly to the JBoss launcher script (standalone.sh) to allow changes such as enabling the JBoss web administration interface. WEBSITE_DISABLE_CLUSTERING prevents the clustering behavior from starting, even if the application is used with VNet integration enabled. WEBSITES_CONTAINER_STOP_TIME_LIMIT sets how long to wait for pending transactions before stopping the server forcefully (in seconds). Its default value is 120 seconds. How to Get Started Get started with Clustering Support on App Service for JBOSS EAP today! It is now generally available. To get your hands on it, go through our detailed guide: Clustered JBoss EAP on Azure App Service Quickstart. This guide walks you through the deployment of a basic distributed application to JBoss EAP, demonstrating how clustering operates seamlessly on Azure App Service. Additional Information Auto-scale rules When configuring auto-scale rules for horizontal scaling it is important to remove instances one at a time to ensure each removed instance transfers its activity (for example, handling a database transaction) to another member of the cluster. When configuring your auto-scale rules in the Portal to scale down, use the following options: Operation: “Decrease count by” Cool down: “5 minutes” or greater Instance count: 1 When scaling out though, you can add multiple instances to the cluster simultaneously. Limitations on Clustering The App Service platform waits up to 120 seconds before stopping a server, not indefinitely for transactions to complete. Any pending transactions remaining after stopping the server are recovered when a new server is added, according to the number of instances defined in the Scale Out configuration. If a customer manually resizes down a cluster, there’s a potential for nodes to be stopped before they complete their transactions. In that case a warning is emitted, and manual intervention is needed to commit the transactions from that node. The process is documented in section 5.2. “Migrating Logs to a New JBoss EAP Server” of the guide Managing Transactions - Red Hat Customer Portal. In the case of a movement to different hardware (for example, scaling up or hardware faults), when a cluster node cannot complete its transactions, a warning will be emitted, and manual intervention is needed to commit any transactions that were not committed. Learn more Red Hat Expands Capabilities of JBoss Enterprise Application Platform Offerings on Microsoft Azure Clustered JBoss EAP on Azure App Service Quickstart JBoss EAP on Azure App Service Clustering in Web Applications - Red Hat Customer Portal Recently Announced: Advanced Clustering Features for JBoss EAP on Azure App Service ","categories": [],
+ "tags": [],
+ "url": "https://azure.github.io/AppService/2023/09/28/JBoss-EAP-Clustering-on-Azure-App-Service.html",
+ "teaser":"https://azure.github.io/AppService/media/pages/new_app_service_logo_64.svg"}]
diff --git a/assets/js/lunr/lunr.js b/assets/js/lunr/lunr.js
new file mode 100644
index 0000000000..b37984ab68
--- /dev/null
+++ b/assets/js/lunr/lunr.js
@@ -0,0 +1,3484 @@
+/**
+ * lunr - http://lunrjs.com - A bit like Solr, but much smaller and not as bright - 2.3.5
+ * Copyright (C) 2018 Oliver Nightingale
+ * @license MIT
+ */
+
+;(function(){
+
+/**
+ * A convenience function for configuring and constructing
+ * a new lunr Index.
+ *
+ * A lunr.Builder instance is created and the pipeline setup
+ * with a trimmer, stop word filter and stemmer.
+ *
+ * This builder object is yielded to the configuration function
+ * that is passed as a parameter, allowing the list of fields
+ * and other builder parameters to be customised.
+ *
+ * All documents _must_ be added within the passed config function.
+ *
+ * @example
+ * var idx = lunr(function () {
+ * this.field('title')
+ * this.field('body')
+ * this.ref('id')
+ *
+ * documents.forEach(function (doc) {
+ * this.add(doc)
+ * }, this)
+ * })
+ *
+ * @see {@link lunr.Builder}
+ * @see {@link lunr.Pipeline}
+ * @see {@link lunr.trimmer}
+ * @see {@link lunr.stopWordFilter}
+ * @see {@link lunr.stemmer}
+ * @namespace {function} lunr
+ */
+var lunr = function (config) {
+ var builder = new lunr.Builder
+
+ builder.pipeline.add(
+ lunr.trimmer,
+ lunr.stopWordFilter,
+ lunr.stemmer
+ )
+
+ builder.searchPipeline.add(
+ lunr.stemmer
+ )
+
+ config.call(builder, builder)
+ return builder.build()
+}
+
+lunr.version = "2.3.5"
+/*!
+ * lunr.utils
+ * Copyright (C) 2018 Oliver Nightingale
+ */
+
+/**
+ * A namespace containing utils for the rest of the lunr library
+ * @namespace lunr.utils
+ */
+lunr.utils = {}
+
+/**
+ * Print a warning message to the console.
+ *
+ * @param {String} message The message to be printed.
+ * @memberOf lunr.utils
+ * @function
+ */
+lunr.utils.warn = (function (global) {
+ /* eslint-disable no-console */
+ return function (message) {
+ if (global.console && console.warn) {
+ console.warn(message)
+ }
+ }
+ /* eslint-enable no-console */
+})(this)
+
+/**
+ * Convert an object to a string.
+ *
+ * In the case of `null` and `undefined` the function returns
+ * the empty string, in all other cases the result of calling
+ * `toString` on the passed object is returned.
+ *
+ * @param {Any} obj The object to convert to a string.
+ * @return {String} string representation of the passed object.
+ * @memberOf lunr.utils
+ */
+lunr.utils.asString = function (obj) {
+ if (obj === void 0 || obj === null) {
+ return ""
+ } else {
+ return obj.toString()
+ }
+}
+
+/**
+ * Clones an object.
+ *
+ * Will create a copy of an existing object such that any mutations
+ * on the copy cannot affect the original.
+ *
+ * Only shallow objects are supported, passing a nested object to this
+ * function will cause a TypeError.
+ *
+ * Objects with primitives, and arrays of primitives are supported.
+ *
+ * @param {Object} obj The object to clone.
+ * @return {Object} a clone of the passed object.
+ * @throws {TypeError} when a nested object is passed.
+ * @memberOf Utils
+ */
+lunr.utils.clone = function (obj) {
+ if (obj === null || obj === undefined) {
+ return obj
+ }
+
+ var clone = Object.create(null),
+ keys = Object.keys(obj)
+
+ for (var i = 0; i < keys.length; i++) {
+ var key = keys[i],
+ val = obj[key]
+
+ if (Array.isArray(val)) {
+ clone[key] = val.slice()
+ continue
+ }
+
+ if (typeof val === 'string' ||
+ typeof val === 'number' ||
+ typeof val === 'boolean') {
+ clone[key] = val
+ continue
+ }
+
+ throw new TypeError("clone is not deep and does not support nested objects")
+ }
+
+ return clone
+}
+lunr.FieldRef = function (docRef, fieldName, stringValue) {
+ this.docRef = docRef
+ this.fieldName = fieldName
+ this._stringValue = stringValue
+}
+
+lunr.FieldRef.joiner = "/"
+
+lunr.FieldRef.fromString = function (s) {
+ var n = s.indexOf(lunr.FieldRef.joiner)
+
+ if (n === -1) {
+ throw "malformed field ref string"
+ }
+
+ var fieldRef = s.slice(0, n),
+ docRef = s.slice(n + 1)
+
+ return new lunr.FieldRef (docRef, fieldRef, s)
+}
+
+lunr.FieldRef.prototype.toString = function () {
+ if (this._stringValue == undefined) {
+ this._stringValue = this.fieldName + lunr.FieldRef.joiner + this.docRef
+ }
+
+ return this._stringValue
+}
+/*!
+ * lunr.Set
+ * Copyright (C) 2018 Oliver Nightingale
+ */
+
+/**
+ * A lunr set.
+ *
+ * @constructor
+ */
+lunr.Set = function (elements) {
+ this.elements = Object.create(null)
+
+ if (elements) {
+ this.length = elements.length
+
+ for (var i = 0; i < this.length; i++) {
+ this.elements[elements[i]] = true
+ }
+ } else {
+ this.length = 0
+ }
+}
+
+/**
+ * A complete set that contains all elements.
+ *
+ * @static
+ * @readonly
+ * @type {lunr.Set}
+ */
+lunr.Set.complete = {
+ intersect: function (other) {
+ return other
+ },
+
+ union: function (other) {
+ return other
+ },
+
+ contains: function () {
+ return true
+ }
+}
+
+/**
+ * An empty set that contains no elements.
+ *
+ * @static
+ * @readonly
+ * @type {lunr.Set}
+ */
+lunr.Set.empty = {
+ intersect: function () {
+ return this
+ },
+
+ union: function (other) {
+ return other
+ },
+
+ contains: function () {
+ return false
+ }
+}
+
+/**
+ * Returns true if this set contains the specified object.
+ *
+ * @param {object} object - Object whose presence in this set is to be tested.
+ * @returns {boolean} - True if this set contains the specified object.
+ */
+lunr.Set.prototype.contains = function (object) {
+ return !!this.elements[object]
+}
+
+/**
+ * Returns a new set containing only the elements that are present in both
+ * this set and the specified set.
+ *
+ * @param {lunr.Set} other - set to intersect with this set.
+ * @returns {lunr.Set} a new set that is the intersection of this and the specified set.
+ */
+
+lunr.Set.prototype.intersect = function (other) {
+ var a, b, elements, intersection = []
+
+ if (other === lunr.Set.complete) {
+ return this
+ }
+
+ if (other === lunr.Set.empty) {
+ return other
+ }
+
+ if (this.length < other.length) {
+ a = this
+ b = other
+ } else {
+ a = other
+ b = this
+ }
+
+ elements = Object.keys(a.elements)
+
+ for (var i = 0; i < elements.length; i++) {
+ var element = elements[i]
+ if (element in b.elements) {
+ intersection.push(element)
+ }
+ }
+
+ return new lunr.Set (intersection)
+}
+
+/**
+ * Returns a new set combining the elements of this and the specified set.
+ *
+ * @param {lunr.Set} other - set to union with this set.
+ * @return {lunr.Set} a new set that is the union of this and the specified set.
+ */
+
+lunr.Set.prototype.union = function (other) {
+ if (other === lunr.Set.complete) {
+ return lunr.Set.complete
+ }
+
+ if (other === lunr.Set.empty) {
+ return this
+ }
+
+ return new lunr.Set(Object.keys(this.elements).concat(Object.keys(other.elements)))
+}
+/**
+ * A function to calculate the inverse document frequency for
+ * a posting. This is shared between the builder and the index
+ *
+ * @private
+ * @param {object} posting - The posting for a given term
+ * @param {number} documentCount - The total number of documents.
+ */
+lunr.idf = function (posting, documentCount) {
+ var documentsWithTerm = 0
+
+ for (var fieldName in posting) {
+ if (fieldName == '_index') continue // Ignore the term index, its not a field
+ documentsWithTerm += Object.keys(posting[fieldName]).length
+ }
+
+ var x = (documentCount - documentsWithTerm + 0.5) / (documentsWithTerm + 0.5)
+
+ return Math.log(1 + Math.abs(x))
+}
+
+/**
+ * A token wraps a string representation of a token
+ * as it is passed through the text processing pipeline.
+ *
+ * @constructor
+ * @param {string} [str=''] - The string token being wrapped.
+ * @param {object} [metadata={}] - Metadata associated with this token.
+ */
+lunr.Token = function (str, metadata) {
+ this.str = str || ""
+ this.metadata = metadata || {}
+}
+
+/**
+ * Returns the token string that is being wrapped by this object.
+ *
+ * @returns {string}
+ */
+lunr.Token.prototype.toString = function () {
+ return this.str
+}
+
+/**
+ * A token update function is used when updating or optionally
+ * when cloning a token.
+ *
+ * @callback lunr.Token~updateFunction
+ * @param {string} str - The string representation of the token.
+ * @param {Object} metadata - All metadata associated with this token.
+ */
+
+/**
+ * Applies the given function to the wrapped string token.
+ *
+ * @example
+ * token.update(function (str, metadata) {
+ * return str.toUpperCase()
+ * })
+ *
+ * @param {lunr.Token~updateFunction} fn - A function to apply to the token string.
+ * @returns {lunr.Token}
+ */
+lunr.Token.prototype.update = function (fn) {
+ this.str = fn(this.str, this.metadata)
+ return this
+}
+
+/**
+ * Creates a clone of this token. Optionally a function can be
+ * applied to the cloned token.
+ *
+ * @param {lunr.Token~updateFunction} [fn] - An optional function to apply to the cloned token.
+ * @returns {lunr.Token}
+ */
+lunr.Token.prototype.clone = function (fn) {
+ fn = fn || function (s) { return s }
+ return new lunr.Token (fn(this.str, this.metadata), this.metadata)
+}
+/*!
+ * lunr.tokenizer
+ * Copyright (C) 2018 Oliver Nightingale
+ */
+
+/**
+ * A function for splitting a string into tokens ready to be inserted into
+ * the search index. Uses `lunr.tokenizer.separator` to split strings, change
+ * the value of this property to change how strings are split into tokens.
+ *
+ * This tokenizer will convert its parameter to a string by calling `toString` and
+ * then will split this string on the character in `lunr.tokenizer.separator`.
+ * Arrays will have their elements converted to strings and wrapped in a lunr.Token.
+ *
+ * Optional metadata can be passed to the tokenizer, this metadata will be cloned and
+ * added as metadata to every token that is created from the object to be tokenized.
+ *
+ * @static
+ * @param {?(string|object|object[])} obj - The object to convert into tokens
+ * @param {?object} metadata - Optional metadata to associate with every token
+ * @returns {lunr.Token[]}
+ * @see {@link lunr.Pipeline}
+ */
+lunr.tokenizer = function (obj, metadata) {
+ if (obj == null || obj == undefined) {
+ return []
+ }
+
+ if (Array.isArray(obj)) {
+ return obj.map(function (t) {
+ return new lunr.Token(
+ lunr.utils.asString(t).toLowerCase(),
+ lunr.utils.clone(metadata)
+ )
+ })
+ }
+
+ var str = obj.toString().trim().toLowerCase(),
+ len = str.length,
+ tokens = []
+
+ for (var sliceEnd = 0, sliceStart = 0; sliceEnd <= len; sliceEnd++) {
+ var char = str.charAt(sliceEnd),
+ sliceLength = sliceEnd - sliceStart
+
+ if ((char.match(lunr.tokenizer.separator) || sliceEnd == len)) {
+
+ if (sliceLength > 0) {
+ var tokenMetadata = lunr.utils.clone(metadata) || {}
+ tokenMetadata["position"] = [sliceStart, sliceLength]
+ tokenMetadata["index"] = tokens.length
+
+ tokens.push(
+ new lunr.Token (
+ str.slice(sliceStart, sliceEnd),
+ tokenMetadata
+ )
+ )
+ }
+
+ sliceStart = sliceEnd + 1
+ }
+
+ }
+
+ return tokens
+}
+
+/**
+ * The separator used to split a string into tokens. Override this property to change the behaviour of
+ * `lunr.tokenizer` behaviour when tokenizing strings. By default this splits on whitespace and hyphens.
+ *
+ * @static
+ * @see lunr.tokenizer
+ */
+lunr.tokenizer.separator = /[\s\-]+/
+/*!
+ * lunr.Pipeline
+ * Copyright (C) 2018 Oliver Nightingale
+ */
+
+/**
+ * lunr.Pipelines maintain an ordered list of functions to be applied to all
+ * tokens in documents entering the search index and queries being ran against
+ * the index.
+ *
+ * An instance of lunr.Index created with the lunr shortcut will contain a
+ * pipeline with a stop word filter and an English language stemmer. Extra
+ * functions can be added before or after either of these functions or these
+ * default functions can be removed.
+ *
+ * When run the pipeline will call each function in turn, passing a token, the
+ * index of that token in the original list of all tokens and finally a list of
+ * all the original tokens.
+ *
+ * The output of functions in the pipeline will be passed to the next function
+ * in the pipeline. To exclude a token from entering the index the function
+ * should return undefined, the rest of the pipeline will not be called with
+ * this token.
+ *
+ * For serialisation of pipelines to work, all functions used in an instance of
+ * a pipeline should be registered with lunr.Pipeline. Registered functions can
+ * then be loaded. If trying to load a serialised pipeline that uses functions
+ * that are not registered an error will be thrown.
+ *
+ * If not planning on serialising the pipeline then registering pipeline functions
+ * is not necessary.
+ *
+ * @constructor
+ */
+lunr.Pipeline = function () {
+ this._stack = []
+}
+
+lunr.Pipeline.registeredFunctions = Object.create(null)
+
+/**
+ * A pipeline function maps lunr.Token to lunr.Token. A lunr.Token contains the token
+ * string as well as all known metadata. A pipeline function can mutate the token string
+ * or mutate (or add) metadata for a given token.
+ *
+ * A pipeline function can indicate that the passed token should be discarded by returning
+ * null. This token will not be passed to any downstream pipeline functions and will not be
+ * added to the index.
+ *
+ * Multiple tokens can be returned by returning an array of tokens. Each token will be passed
+ * to any downstream pipeline functions and all will returned tokens will be added to the index.
+ *
+ * Any number of pipeline functions may be chained together using a lunr.Pipeline.
+ *
+ * @interface lunr.PipelineFunction
+ * @param {lunr.Token} token - A token from the document being processed.
+ * @param {number} i - The index of this token in the complete list of tokens for this document/field.
+ * @param {lunr.Token[]} tokens - All tokens for this document/field.
+ * @returns {(?lunr.Token|lunr.Token[])}
+ */
+
+/**
+ * Register a function with the pipeline.
+ *
+ * Functions that are used in the pipeline should be registered if the pipeline
+ * needs to be serialised, or a serialised pipeline needs to be loaded.
+ *
+ * Registering a function does not add it to a pipeline, functions must still be
+ * added to instances of the pipeline for them to be used when running a pipeline.
+ *
+ * @param {lunr.PipelineFunction} fn - The function to check for.
+ * @param {String} label - The label to register this function with
+ */
+lunr.Pipeline.registerFunction = function (fn, label) {
+ if (label in this.registeredFunctions) {
+ lunr.utils.warn('Overwriting existing registered function: ' + label)
+ }
+
+ fn.label = label
+ lunr.Pipeline.registeredFunctions[fn.label] = fn
+}
+
+/**
+ * Warns if the function is not registered as a Pipeline function.
+ *
+ * @param {lunr.PipelineFunction} fn - The function to check for.
+ * @private
+ */
+lunr.Pipeline.warnIfFunctionNotRegistered = function (fn) {
+ var isRegistered = fn.label && (fn.label in this.registeredFunctions)
+
+ if (!isRegistered) {
+ lunr.utils.warn('Function is not registered with pipeline. This may cause problems when serialising the index.\n', fn)
+ }
+}
+
+/**
+ * Loads a previously serialised pipeline.
+ *
+ * All functions to be loaded must already be registered with lunr.Pipeline.
+ * If any function from the serialised data has not been registered then an
+ * error will be thrown.
+ *
+ * @param {Object} serialised - The serialised pipeline to load.
+ * @returns {lunr.Pipeline}
+ */
+lunr.Pipeline.load = function (serialised) {
+ var pipeline = new lunr.Pipeline
+
+ serialised.forEach(function (fnName) {
+ var fn = lunr.Pipeline.registeredFunctions[fnName]
+
+ if (fn) {
+ pipeline.add(fn)
+ } else {
+ throw new Error('Cannot load unregistered function: ' + fnName)
+ }
+ })
+
+ return pipeline
+}
+
+/**
+ * Adds new functions to the end of the pipeline.
+ *
+ * Logs a warning if the function has not been registered.
+ *
+ * @param {lunr.PipelineFunction[]} functions - Any number of functions to add to the pipeline.
+ */
+lunr.Pipeline.prototype.add = function () {
+ var fns = Array.prototype.slice.call(arguments)
+
+ fns.forEach(function (fn) {
+ lunr.Pipeline.warnIfFunctionNotRegistered(fn)
+ this._stack.push(fn)
+ }, this)
+}
+
+/**
+ * Adds a single function after a function that already exists in the
+ * pipeline.
+ *
+ * Logs a warning if the function has not been registered.
+ *
+ * @param {lunr.PipelineFunction} existingFn - A function that already exists in the pipeline.
+ * @param {lunr.PipelineFunction} newFn - The new function to add to the pipeline.
+ */
+lunr.Pipeline.prototype.after = function (existingFn, newFn) {
+ lunr.Pipeline.warnIfFunctionNotRegistered(newFn)
+
+ var pos = this._stack.indexOf(existingFn)
+ if (pos == -1) {
+ throw new Error('Cannot find existingFn')
+ }
+
+ pos = pos + 1
+ this._stack.splice(pos, 0, newFn)
+}
+
+/**
+ * Adds a single function before a function that already exists in the
+ * pipeline.
+ *
+ * Logs a warning if the function has not been registered.
+ *
+ * @param {lunr.PipelineFunction} existingFn - A function that already exists in the pipeline.
+ * @param {lunr.PipelineFunction} newFn - The new function to add to the pipeline.
+ */
+lunr.Pipeline.prototype.before = function (existingFn, newFn) {
+ lunr.Pipeline.warnIfFunctionNotRegistered(newFn)
+
+ var pos = this._stack.indexOf(existingFn)
+ if (pos == -1) {
+ throw new Error('Cannot find existingFn')
+ }
+
+ this._stack.splice(pos, 0, newFn)
+}
+
+/**
+ * Removes a function from the pipeline.
+ *
+ * @param {lunr.PipelineFunction} fn The function to remove from the pipeline.
+ */
+lunr.Pipeline.prototype.remove = function (fn) {
+ var pos = this._stack.indexOf(fn)
+ if (pos == -1) {
+ return
+ }
+
+ this._stack.splice(pos, 1)
+}
+
+/**
+ * Runs the current list of functions that make up the pipeline against the
+ * passed tokens.
+ *
+ * @param {Array} tokens The tokens to run through the pipeline.
+ * @returns {Array}
+ */
+lunr.Pipeline.prototype.run = function (tokens) {
+ var stackLength = this._stack.length
+
+ for (var i = 0; i < stackLength; i++) {
+ var fn = this._stack[i]
+ var memo = []
+
+ for (var j = 0; j < tokens.length; j++) {
+ var result = fn(tokens[j], j, tokens)
+
+ if (result === void 0 || result === '') continue
+
+ if (Array.isArray(result)) {
+ for (var k = 0; k < result.length; k++) {
+ memo.push(result[k])
+ }
+ } else {
+ memo.push(result)
+ }
+ }
+
+ tokens = memo
+ }
+
+ return tokens
+}
+
+/**
+ * Convenience method for passing a string through a pipeline and getting
+ * strings out. This method takes care of wrapping the passed string in a
+ * token and mapping the resulting tokens back to strings.
+ *
+ * @param {string} str - The string to pass through the pipeline.
+ * @param {?object} metadata - Optional metadata to associate with the token
+ * passed to the pipeline.
+ * @returns {string[]}
+ */
+lunr.Pipeline.prototype.runString = function (str, metadata) {
+ var token = new lunr.Token (str, metadata)
+
+ return this.run([token]).map(function (t) {
+ return t.toString()
+ })
+}
+
+/**
+ * Resets the pipeline by removing any existing processors.
+ *
+ */
+lunr.Pipeline.prototype.reset = function () {
+ this._stack = []
+}
+
+/**
+ * Returns a representation of the pipeline ready for serialisation.
+ *
+ * Logs a warning if the function has not been registered.
+ *
+ * @returns {Array}
+ */
+lunr.Pipeline.prototype.toJSON = function () {
+ return this._stack.map(function (fn) {
+ lunr.Pipeline.warnIfFunctionNotRegistered(fn)
+
+ return fn.label
+ })
+}
+/*!
+ * lunr.Vector
+ * Copyright (C) 2018 Oliver Nightingale
+ */
+
+/**
+ * A vector is used to construct the vector space of documents and queries. These
+ * vectors support operations to determine the similarity between two documents or
+ * a document and a query.
+ *
+ * Normally no parameters are required for initializing a vector, but in the case of
+ * loading a previously dumped vector the raw elements can be provided to the constructor.
+ *
+ * For performance reasons vectors are implemented with a flat array, where an elements
+ * index is immediately followed by its value. E.g. [index, value, index, value]. This
+ * allows the underlying array to be as sparse as possible and still offer decent
+ * performance when being used for vector calculations.
+ *
+ * @constructor
+ * @param {Number[]} [elements] - The flat list of element index and element value pairs.
+ */
+lunr.Vector = function (elements) {
+ this._magnitude = 0
+ this.elements = elements || []
+}
+
+
+/**
+ * Calculates the position within the vector to insert a given index.
+ *
+ * This is used internally by insert and upsert. If there are duplicate indexes then
+ * the position is returned as if the value for that index were to be updated, but it
+ * is the callers responsibility to check whether there is a duplicate at that index
+ *
+ * @param {Number} insertIdx - The index at which the element should be inserted.
+ * @returns {Number}
+ */
+lunr.Vector.prototype.positionForIndex = function (index) {
+ // For an empty vector the tuple can be inserted at the beginning
+ if (this.elements.length == 0) {
+ return 0
+ }
+
+ var start = 0,
+ end = this.elements.length / 2,
+ sliceLength = end - start,
+ pivotPoint = Math.floor(sliceLength / 2),
+ pivotIndex = this.elements[pivotPoint * 2]
+
+ while (sliceLength > 1) {
+ if (pivotIndex < index) {
+ start = pivotPoint
+ }
+
+ if (pivotIndex > index) {
+ end = pivotPoint
+ }
+
+ if (pivotIndex == index) {
+ break
+ }
+
+ sliceLength = end - start
+ pivotPoint = start + Math.floor(sliceLength / 2)
+ pivotIndex = this.elements[pivotPoint * 2]
+ }
+
+ if (pivotIndex == index) {
+ return pivotPoint * 2
+ }
+
+ if (pivotIndex > index) {
+ return pivotPoint * 2
+ }
+
+ if (pivotIndex < index) {
+ return (pivotPoint + 1) * 2
+ }
+}
+
+/**
+ * Inserts an element at an index within the vector.
+ *
+ * Does not allow duplicates, will throw an error if there is already an entry
+ * for this index.
+ *
+ * @param {Number} insertIdx - The index at which the element should be inserted.
+ * @param {Number} val - The value to be inserted into the vector.
+ */
+lunr.Vector.prototype.insert = function (insertIdx, val) {
+ this.upsert(insertIdx, val, function () {
+ throw "duplicate index"
+ })
+}
+
+/**
+ * Inserts or updates an existing index within the vector.
+ *
+ * @param {Number} insertIdx - The index at which the element should be inserted.
+ * @param {Number} val - The value to be inserted into the vector.
+ * @param {function} fn - A function that is called for updates, the existing value and the
+ * requested value are passed as arguments
+ */
+lunr.Vector.prototype.upsert = function (insertIdx, val, fn) {
+ this._magnitude = 0
+ var position = this.positionForIndex(insertIdx)
+
+ if (this.elements[position] == insertIdx) {
+ this.elements[position + 1] = fn(this.elements[position + 1], val)
+ } else {
+ this.elements.splice(position, 0, insertIdx, val)
+ }
+}
+
+/**
+ * Calculates the magnitude of this vector.
+ *
+ * @returns {Number}
+ */
+lunr.Vector.prototype.magnitude = function () {
+ if (this._magnitude) return this._magnitude
+
+ var sumOfSquares = 0,
+ elementsLength = this.elements.length
+
+ for (var i = 1; i < elementsLength; i += 2) {
+ var val = this.elements[i]
+ sumOfSquares += val * val
+ }
+
+ return this._magnitude = Math.sqrt(sumOfSquares)
+}
+
+/**
+ * Calculates the dot product of this vector and another vector.
+ *
+ * @param {lunr.Vector} otherVector - The vector to compute the dot product with.
+ * @returns {Number}
+ */
+lunr.Vector.prototype.dot = function (otherVector) {
+ var dotProduct = 0,
+ a = this.elements, b = otherVector.elements,
+ aLen = a.length, bLen = b.length,
+ aVal = 0, bVal = 0,
+ i = 0, j = 0
+
+ while (i < aLen && j < bLen) {
+ aVal = a[i], bVal = b[j]
+ if (aVal < bVal) {
+ i += 2
+ } else if (aVal > bVal) {
+ j += 2
+ } else if (aVal == bVal) {
+ dotProduct += a[i + 1] * b[j + 1]
+ i += 2
+ j += 2
+ }
+ }
+
+ return dotProduct
+}
+
+/**
+ * Calculates the similarity between this vector and another vector.
+ *
+ * @param {lunr.Vector} otherVector - The other vector to calculate the
+ * similarity with.
+ * @returns {Number}
+ */
+lunr.Vector.prototype.similarity = function (otherVector) {
+ return this.dot(otherVector) / this.magnitude() || 0
+}
+
+/**
+ * Converts the vector to an array of the elements within the vector.
+ *
+ * @returns {Number[]}
+ */
+lunr.Vector.prototype.toArray = function () {
+ var output = new Array (this.elements.length / 2)
+
+ for (var i = 1, j = 0; i < this.elements.length; i += 2, j++) {
+ output[j] = this.elements[i]
+ }
+
+ return output
+}
+
+/**
+ * A JSON serializable representation of the vector.
+ *
+ * @returns {Number[]}
+ */
+lunr.Vector.prototype.toJSON = function () {
+ return this.elements
+}
+/* eslint-disable */
+/*!
+ * lunr.stemmer
+ * Copyright (C) 2018 Oliver Nightingale
+ * Includes code from - http://tartarus.org/~martin/PorterStemmer/js.txt
+ */
+
+/**
+ * lunr.stemmer is an english language stemmer, this is a JavaScript
+ * implementation of the PorterStemmer taken from http://tartarus.org/~martin
+ *
+ * @static
+ * @implements {lunr.PipelineFunction}
+ * @param {lunr.Token} token - The string to stem
+ * @returns {lunr.Token}
+ * @see {@link lunr.Pipeline}
+ * @function
+ */
+lunr.stemmer = (function(){
+ var step2list = {
+ "ational" : "ate",
+ "tional" : "tion",
+ "enci" : "ence",
+ "anci" : "ance",
+ "izer" : "ize",
+ "bli" : "ble",
+ "alli" : "al",
+ "entli" : "ent",
+ "eli" : "e",
+ "ousli" : "ous",
+ "ization" : "ize",
+ "ation" : "ate",
+ "ator" : "ate",
+ "alism" : "al",
+ "iveness" : "ive",
+ "fulness" : "ful",
+ "ousness" : "ous",
+ "aliti" : "al",
+ "iviti" : "ive",
+ "biliti" : "ble",
+ "logi" : "log"
+ },
+
+ step3list = {
+ "icate" : "ic",
+ "ative" : "",
+ "alize" : "al",
+ "iciti" : "ic",
+ "ical" : "ic",
+ "ful" : "",
+ "ness" : ""
+ },
+
+ c = "[^aeiou]", // consonant
+ v = "[aeiouy]", // vowel
+ C = c + "[^aeiouy]*", // consonant sequence
+ V = v + "[aeiou]*", // vowel sequence
+
+ mgr0 = "^(" + C + ")?" + V + C, // [C]VC... is m>0
+ meq1 = "^(" + C + ")?" + V + C + "(" + V + ")?$", // [C]VC[V] is m=1
+ mgr1 = "^(" + C + ")?" + V + C + V + C, // [C]VCVC... is m>1
+ s_v = "^(" + C + ")?" + v; // vowel in stem
+
+ var re_mgr0 = new RegExp(mgr0);
+ var re_mgr1 = new RegExp(mgr1);
+ var re_meq1 = new RegExp(meq1);
+ var re_s_v = new RegExp(s_v);
+
+ var re_1a = /^(.+?)(ss|i)es$/;
+ var re2_1a = /^(.+?)([^s])s$/;
+ var re_1b = /^(.+?)eed$/;
+ var re2_1b = /^(.+?)(ed|ing)$/;
+ var re_1b_2 = /.$/;
+ var re2_1b_2 = /(at|bl|iz)$/;
+ var re3_1b_2 = new RegExp("([^aeiouylsz])\\1$");
+ var re4_1b_2 = new RegExp("^" + C + v + "[^aeiouwxy]$");
+
+ var re_1c = /^(.+?[^aeiou])y$/;
+ var re_2 = /^(.+?)(ational|tional|enci|anci|izer|bli|alli|entli|eli|ousli|ization|ation|ator|alism|iveness|fulness|ousness|aliti|iviti|biliti|logi)$/;
+
+ var re_3 = /^(.+?)(icate|ative|alize|iciti|ical|ful|ness)$/;
+
+ var re_4 = /^(.+?)(al|ance|ence|er|ic|able|ible|ant|ement|ment|ent|ou|ism|ate|iti|ous|ive|ize)$/;
+ var re2_4 = /^(.+?)(s|t)(ion)$/;
+
+ var re_5 = /^(.+?)e$/;
+ var re_5_1 = /ll$/;
+ var re3_5 = new RegExp("^" + C + v + "[^aeiouwxy]$");
+
+ var porterStemmer = function porterStemmer(w) {
+ var stem,
+ suffix,
+ firstch,
+ re,
+ re2,
+ re3,
+ re4;
+
+ if (w.length < 3) { return w; }
+
+ firstch = w.substr(0,1);
+ if (firstch == "y") {
+ w = firstch.toUpperCase() + w.substr(1);
+ }
+
+ // Step 1a
+ re = re_1a
+ re2 = re2_1a;
+
+ if (re.test(w)) { w = w.replace(re,"$1$2"); }
+ else if (re2.test(w)) { w = w.replace(re2,"$1$2"); }
+
+ // Step 1b
+ re = re_1b;
+ re2 = re2_1b;
+ if (re.test(w)) {
+ var fp = re.exec(w);
+ re = re_mgr0;
+ if (re.test(fp[1])) {
+ re = re_1b_2;
+ w = w.replace(re,"");
+ }
+ } else if (re2.test(w)) {
+ var fp = re2.exec(w);
+ stem = fp[1];
+ re2 = re_s_v;
+ if (re2.test(stem)) {
+ w = stem;
+ re2 = re2_1b_2;
+ re3 = re3_1b_2;
+ re4 = re4_1b_2;
+ if (re2.test(w)) { w = w + "e"; }
+ else if (re3.test(w)) { re = re_1b_2; w = w.replace(re,""); }
+ else if (re4.test(w)) { w = w + "e"; }
+ }
+ }
+
+ // Step 1c - replace suffix y or Y by i if preceded by a non-vowel which is not the first letter of the word (so cry -> cri, by -> by, say -> say)
+ re = re_1c;
+ if (re.test(w)) {
+ var fp = re.exec(w);
+ stem = fp[1];
+ w = stem + "i";
+ }
+
+ // Step 2
+ re = re_2;
+ if (re.test(w)) {
+ var fp = re.exec(w);
+ stem = fp[1];
+ suffix = fp[2];
+ re = re_mgr0;
+ if (re.test(stem)) {
+ w = stem + step2list[suffix];
+ }
+ }
+
+ // Step 3
+ re = re_3;
+ if (re.test(w)) {
+ var fp = re.exec(w);
+ stem = fp[1];
+ suffix = fp[2];
+ re = re_mgr0;
+ if (re.test(stem)) {
+ w = stem + step3list[suffix];
+ }
+ }
+
+ // Step 4
+ re = re_4;
+ re2 = re2_4;
+ if (re.test(w)) {
+ var fp = re.exec(w);
+ stem = fp[1];
+ re = re_mgr1;
+ if (re.test(stem)) {
+ w = stem;
+ }
+ } else if (re2.test(w)) {
+ var fp = re2.exec(w);
+ stem = fp[1] + fp[2];
+ re2 = re_mgr1;
+ if (re2.test(stem)) {
+ w = stem;
+ }
+ }
+
+ // Step 5
+ re = re_5;
+ if (re.test(w)) {
+ var fp = re.exec(w);
+ stem = fp[1];
+ re = re_mgr1;
+ re2 = re_meq1;
+ re3 = re3_5;
+ if (re.test(stem) || (re2.test(stem) && !(re3.test(stem)))) {
+ w = stem;
+ }
+ }
+
+ re = re_5_1;
+ re2 = re_mgr1;
+ if (re.test(w) && re2.test(w)) {
+ re = re_1b_2;
+ w = w.replace(re,"");
+ }
+
+ // and turn initial Y back to y
+
+ if (firstch == "y") {
+ w = firstch.toLowerCase() + w.substr(1);
+ }
+
+ return w;
+ };
+
+ return function (token) {
+ return token.update(porterStemmer);
+ }
+})();
+
+lunr.Pipeline.registerFunction(lunr.stemmer, 'stemmer')
+/*!
+ * lunr.stopWordFilter
+ * Copyright (C) 2018 Oliver Nightingale
+ */
+
+/**
+ * lunr.generateStopWordFilter builds a stopWordFilter function from the provided
+ * list of stop words.
+ *
+ * The built in lunr.stopWordFilter is built using this generator and can be used
+ * to generate custom stopWordFilters for applications or non English languages.
+ *
+ * @function
+ * @param {Array} token The token to pass through the filter
+ * @returns {lunr.PipelineFunction}
+ * @see lunr.Pipeline
+ * @see lunr.stopWordFilter
+ */
+lunr.generateStopWordFilter = function (stopWords) {
+ var words = stopWords.reduce(function (memo, stopWord) {
+ memo[stopWord] = stopWord
+ return memo
+ }, {})
+
+ return function (token) {
+ if (token && words[token.toString()] !== token.toString()) return token
+ }
+}
+
+/**
+ * lunr.stopWordFilter is an English language stop word list filter, any words
+ * contained in the list will not be passed through the filter.
+ *
+ * This is intended to be used in the Pipeline. If the token does not pass the
+ * filter then undefined will be returned.
+ *
+ * @function
+ * @implements {lunr.PipelineFunction}
+ * @params {lunr.Token} token - A token to check for being a stop word.
+ * @returns {lunr.Token}
+ * @see {@link lunr.Pipeline}
+ */
+lunr.stopWordFilter = lunr.generateStopWordFilter([
+ 'a',
+ 'able',
+ 'about',
+ 'across',
+ 'after',
+ 'all',
+ 'almost',
+ 'also',
+ 'am',
+ 'among',
+ 'an',
+ 'and',
+ 'any',
+ 'are',
+ 'as',
+ 'at',
+ 'be',
+ 'because',
+ 'been',
+ 'but',
+ 'by',
+ 'can',
+ 'cannot',
+ 'could',
+ 'dear',
+ 'did',
+ 'do',
+ 'does',
+ 'either',
+ 'else',
+ 'ever',
+ 'every',
+ 'for',
+ 'from',
+ 'get',
+ 'got',
+ 'had',
+ 'has',
+ 'have',
+ 'he',
+ 'her',
+ 'hers',
+ 'him',
+ 'his',
+ 'how',
+ 'however',
+ 'i',
+ 'if',
+ 'in',
+ 'into',
+ 'is',
+ 'it',
+ 'its',
+ 'just',
+ 'least',
+ 'let',
+ 'like',
+ 'likely',
+ 'may',
+ 'me',
+ 'might',
+ 'most',
+ 'must',
+ 'my',
+ 'neither',
+ 'no',
+ 'nor',
+ 'not',
+ 'of',
+ 'off',
+ 'often',
+ 'on',
+ 'only',
+ 'or',
+ 'other',
+ 'our',
+ 'own',
+ 'rather',
+ 'said',
+ 'say',
+ 'says',
+ 'she',
+ 'should',
+ 'since',
+ 'so',
+ 'some',
+ 'than',
+ 'that',
+ 'the',
+ 'their',
+ 'them',
+ 'then',
+ 'there',
+ 'these',
+ 'they',
+ 'this',
+ 'tis',
+ 'to',
+ 'too',
+ 'twas',
+ 'us',
+ 'wants',
+ 'was',
+ 'we',
+ 'were',
+ 'what',
+ 'when',
+ 'where',
+ 'which',
+ 'while',
+ 'who',
+ 'whom',
+ 'why',
+ 'will',
+ 'with',
+ 'would',
+ 'yet',
+ 'you',
+ 'your'
+])
+
+lunr.Pipeline.registerFunction(lunr.stopWordFilter, 'stopWordFilter')
+/*!
+ * lunr.trimmer
+ * Copyright (C) 2018 Oliver Nightingale
+ */
+
+/**
+ * lunr.trimmer is a pipeline function for trimming non word
+ * characters from the beginning and end of tokens before they
+ * enter the index.
+ *
+ * This implementation may not work correctly for non latin
+ * characters and should either be removed or adapted for use
+ * with languages with non-latin characters.
+ *
+ * @static
+ * @implements {lunr.PipelineFunction}
+ * @param {lunr.Token} token The token to pass through the filter
+ * @returns {lunr.Token}
+ * @see lunr.Pipeline
+ */
+lunr.trimmer = function (token) {
+ return token.update(function (s) {
+ return s.replace(/^\W+/, '').replace(/\W+$/, '')
+ })
+}
+
+lunr.Pipeline.registerFunction(lunr.trimmer, 'trimmer')
+/*!
+ * lunr.TokenSet
+ * Copyright (C) 2018 Oliver Nightingale
+ */
+
+/**
+ * A token set is used to store the unique list of all tokens
+ * within an index. Token sets are also used to represent an
+ * incoming query to the index, this query token set and index
+ * token set are then intersected to find which tokens to look
+ * up in the inverted index.
+ *
+ * A token set can hold multiple tokens, as in the case of the
+ * index token set, or it can hold a single token as in the
+ * case of a simple query token set.
+ *
+ * Additionally token sets are used to perform wildcard matching.
+ * Leading, contained and trailing wildcards are supported, and
+ * from this edit distance matching can also be provided.
+ *
+ * Token sets are implemented as a minimal finite state automata,
+ * where both common prefixes and suffixes are shared between tokens.
+ * This helps to reduce the space used for storing the token set.
+ *
+ * @constructor
+ */
+lunr.TokenSet = function () {
+ this.final = false
+ this.edges = {}
+ this.id = lunr.TokenSet._nextId
+ lunr.TokenSet._nextId += 1
+}
+
+/**
+ * Keeps track of the next, auto increment, identifier to assign
+ * to a new tokenSet.
+ *
+ * TokenSets require a unique identifier to be correctly minimised.
+ *
+ * @private
+ */
+lunr.TokenSet._nextId = 1
+
+/**
+ * Creates a TokenSet instance from the given sorted array of words.
+ *
+ * @param {String[]} arr - A sorted array of strings to create the set from.
+ * @returns {lunr.TokenSet}
+ * @throws Will throw an error if the input array is not sorted.
+ */
+lunr.TokenSet.fromArray = function (arr) {
+ var builder = new lunr.TokenSet.Builder
+
+ for (var i = 0, len = arr.length; i < len; i++) {
+ builder.insert(arr[i])
+ }
+
+ builder.finish()
+ return builder.root
+}
+
+/**
+ * Creates a token set from a query clause.
+ *
+ * @private
+ * @param {Object} clause - A single clause from lunr.Query.
+ * @param {string} clause.term - The query clause term.
+ * @param {number} [clause.editDistance] - The optional edit distance for the term.
+ * @returns {lunr.TokenSet}
+ */
+lunr.TokenSet.fromClause = function (clause) {
+ if ('editDistance' in clause) {
+ return lunr.TokenSet.fromFuzzyString(clause.term, clause.editDistance)
+ } else {
+ return lunr.TokenSet.fromString(clause.term)
+ }
+}
+
+/**
+ * Creates a token set representing a single string with a specified
+ * edit distance.
+ *
+ * Insertions, deletions, substitutions and transpositions are each
+ * treated as an edit distance of 1.
+ *
+ * Increasing the allowed edit distance will have a dramatic impact
+ * on the performance of both creating and intersecting these TokenSets.
+ * It is advised to keep the edit distance less than 3.
+ *
+ * @param {string} str - The string to create the token set from.
+ * @param {number} editDistance - The allowed edit distance to match.
+ * @returns {lunr.Vector}
+ */
+lunr.TokenSet.fromFuzzyString = function (str, editDistance) {
+ var root = new lunr.TokenSet
+
+ var stack = [{
+ node: root,
+ editsRemaining: editDistance,
+ str: str
+ }]
+
+ while (stack.length) {
+ var frame = stack.pop()
+
+ // no edit
+ if (frame.str.length > 0) {
+ var char = frame.str.charAt(0),
+ noEditNode
+
+ if (char in frame.node.edges) {
+ noEditNode = frame.node.edges[char]
+ } else {
+ noEditNode = new lunr.TokenSet
+ frame.node.edges[char] = noEditNode
+ }
+
+ if (frame.str.length == 1) {
+ noEditNode.final = true
+ }
+
+ stack.push({
+ node: noEditNode,
+ editsRemaining: frame.editsRemaining,
+ str: frame.str.slice(1)
+ })
+ }
+
+ // deletion
+ // can only do a deletion if we have enough edits remaining
+ // and if there are characters left to delete in the string
+ if (frame.editsRemaining > 0 && frame.str.length > 1) {
+ var char = frame.str.charAt(1),
+ deletionNode
+
+ if (char in frame.node.edges) {
+ deletionNode = frame.node.edges[char]
+ } else {
+ deletionNode = new lunr.TokenSet
+ frame.node.edges[char] = deletionNode
+ }
+
+ if (frame.str.length <= 2) {
+ deletionNode.final = true
+ } else {
+ stack.push({
+ node: deletionNode,
+ editsRemaining: frame.editsRemaining - 1,
+ str: frame.str.slice(2)
+ })
+ }
+ }
+
+ // deletion
+ // just removing the last character from the str
+ if (frame.editsRemaining > 0 && frame.str.length == 1) {
+ frame.node.final = true
+ }
+
+ // substitution
+ // can only do a substitution if we have enough edits remaining
+ // and if there are characters left to substitute
+ if (frame.editsRemaining > 0 && frame.str.length >= 1) {
+ if ("*" in frame.node.edges) {
+ var substitutionNode = frame.node.edges["*"]
+ } else {
+ var substitutionNode = new lunr.TokenSet
+ frame.node.edges["*"] = substitutionNode
+ }
+
+ if (frame.str.length == 1) {
+ substitutionNode.final = true
+ } else {
+ stack.push({
+ node: substitutionNode,
+ editsRemaining: frame.editsRemaining - 1,
+ str: frame.str.slice(1)
+ })
+ }
+ }
+
+ // insertion
+ // can only do insertion if there are edits remaining
+ if (frame.editsRemaining > 0) {
+ if ("*" in frame.node.edges) {
+ var insertionNode = frame.node.edges["*"]
+ } else {
+ var insertionNode = new lunr.TokenSet
+ frame.node.edges["*"] = insertionNode
+ }
+
+ if (frame.str.length == 0) {
+ insertionNode.final = true
+ } else {
+ stack.push({
+ node: insertionNode,
+ editsRemaining: frame.editsRemaining - 1,
+ str: frame.str
+ })
+ }
+ }
+
+ // transposition
+ // can only do a transposition if there are edits remaining
+ // and there are enough characters to transpose
+ if (frame.editsRemaining > 0 && frame.str.length > 1) {
+ var charA = frame.str.charAt(0),
+ charB = frame.str.charAt(1),
+ transposeNode
+
+ if (charB in frame.node.edges) {
+ transposeNode = frame.node.edges[charB]
+ } else {
+ transposeNode = new lunr.TokenSet
+ frame.node.edges[charB] = transposeNode
+ }
+
+ if (frame.str.length == 1) {
+ transposeNode.final = true
+ } else {
+ stack.push({
+ node: transposeNode,
+ editsRemaining: frame.editsRemaining - 1,
+ str: charA + frame.str.slice(2)
+ })
+ }
+ }
+ }
+
+ return root
+}
+
+/**
+ * Creates a TokenSet from a string.
+ *
+ * The string may contain one or more wildcard characters (*)
+ * that will allow wildcard matching when intersecting with
+ * another TokenSet.
+ *
+ * @param {string} str - The string to create a TokenSet from.
+ * @returns {lunr.TokenSet}
+ */
+lunr.TokenSet.fromString = function (str) {
+ var node = new lunr.TokenSet,
+ root = node
+
+ /*
+ * Iterates through all characters within the passed string
+ * appending a node for each character.
+ *
+ * When a wildcard character is found then a self
+ * referencing edge is introduced to continually match
+ * any number of any characters.
+ */
+ for (var i = 0, len = str.length; i < len; i++) {
+ var char = str[i],
+ final = (i == len - 1)
+
+ if (char == "*") {
+ node.edges[char] = node
+ node.final = final
+
+ } else {
+ var next = new lunr.TokenSet
+ next.final = final
+
+ node.edges[char] = next
+ node = next
+ }
+ }
+
+ return root
+}
+
+/**
+ * Converts this TokenSet into an array of strings
+ * contained within the TokenSet.
+ *
+ * @returns {string[]}
+ */
+lunr.TokenSet.prototype.toArray = function () {
+ var words = []
+
+ var stack = [{
+ prefix: "",
+ node: this
+ }]
+
+ while (stack.length) {
+ var frame = stack.pop(),
+ edges = Object.keys(frame.node.edges),
+ len = edges.length
+
+ if (frame.node.final) {
+ /* In Safari, at this point the prefix is sometimes corrupted, see:
+ * https://github.com/olivernn/lunr.js/issues/279 Calling any
+ * String.prototype method forces Safari to "cast" this string to what
+ * it's supposed to be, fixing the bug. */
+ frame.prefix.charAt(0)
+ words.push(frame.prefix)
+ }
+
+ for (var i = 0; i < len; i++) {
+ var edge = edges[i]
+
+ stack.push({
+ prefix: frame.prefix.concat(edge),
+ node: frame.node.edges[edge]
+ })
+ }
+ }
+
+ return words
+}
+
+/**
+ * Generates a string representation of a TokenSet.
+ *
+ * This is intended to allow TokenSets to be used as keys
+ * in objects, largely to aid the construction and minimisation
+ * of a TokenSet. As such it is not designed to be a human
+ * friendly representation of the TokenSet.
+ *
+ * @returns {string}
+ */
+lunr.TokenSet.prototype.toString = function () {
+ // NOTE: Using Object.keys here as this.edges is very likely
+ // to enter 'hash-mode' with many keys being added
+ //
+ // avoiding a for-in loop here as it leads to the function
+ // being de-optimised (at least in V8). From some simple
+ // benchmarks the performance is comparable, but allowing
+ // V8 to optimize may mean easy performance wins in the future.
+
+ if (this._str) {
+ return this._str
+ }
+
+ var str = this.final ? '1' : '0',
+ labels = Object.keys(this.edges).sort(),
+ len = labels.length
+
+ for (var i = 0; i < len; i++) {
+ var label = labels[i],
+ node = this.edges[label]
+
+ str = str + label + node.id
+ }
+
+ return str
+}
+
+/**
+ * Returns a new TokenSet that is the intersection of
+ * this TokenSet and the passed TokenSet.
+ *
+ * This intersection will take into account any wildcards
+ * contained within the TokenSet.
+ *
+ * @param {lunr.TokenSet} b - An other TokenSet to intersect with.
+ * @returns {lunr.TokenSet}
+ */
+lunr.TokenSet.prototype.intersect = function (b) {
+ var output = new lunr.TokenSet,
+ frame = undefined
+
+ var stack = [{
+ qNode: b,
+ output: output,
+ node: this
+ }]
+
+ while (stack.length) {
+ frame = stack.pop()
+
+ // NOTE: As with the #toString method, we are using
+ // Object.keys and a for loop instead of a for-in loop
+ // as both of these objects enter 'hash' mode, causing
+ // the function to be de-optimised in V8
+ var qEdges = Object.keys(frame.qNode.edges),
+ qLen = qEdges.length,
+ nEdges = Object.keys(frame.node.edges),
+ nLen = nEdges.length
+
+ for (var q = 0; q < qLen; q++) {
+ var qEdge = qEdges[q]
+
+ for (var n = 0; n < nLen; n++) {
+ var nEdge = nEdges[n]
+
+ if (nEdge == qEdge || qEdge == '*') {
+ var node = frame.node.edges[nEdge],
+ qNode = frame.qNode.edges[qEdge],
+ final = node.final && qNode.final,
+ next = undefined
+
+ if (nEdge in frame.output.edges) {
+ // an edge already exists for this character
+ // no need to create a new node, just set the finality
+ // bit unless this node is already final
+ next = frame.output.edges[nEdge]
+ next.final = next.final || final
+
+ } else {
+ // no edge exists yet, must create one
+ // set the finality bit and insert it
+ // into the output
+ next = new lunr.TokenSet
+ next.final = final
+ frame.output.edges[nEdge] = next
+ }
+
+ stack.push({
+ qNode: qNode,
+ output: next,
+ node: node
+ })
+ }
+ }
+ }
+ }
+
+ return output
+}
+lunr.TokenSet.Builder = function () {
+ this.previousWord = ""
+ this.root = new lunr.TokenSet
+ this.uncheckedNodes = []
+ this.minimizedNodes = {}
+}
+
+lunr.TokenSet.Builder.prototype.insert = function (word) {
+ var node,
+ commonPrefix = 0
+
+ if (word < this.previousWord) {
+ throw new Error ("Out of order word insertion")
+ }
+
+ for (var i = 0; i < word.length && i < this.previousWord.length; i++) {
+ if (word[i] != this.previousWord[i]) break
+ commonPrefix++
+ }
+
+ this.minimize(commonPrefix)
+
+ if (this.uncheckedNodes.length == 0) {
+ node = this.root
+ } else {
+ node = this.uncheckedNodes[this.uncheckedNodes.length - 1].child
+ }
+
+ for (var i = commonPrefix; i < word.length; i++) {
+ var nextNode = new lunr.TokenSet,
+ char = word[i]
+
+ node.edges[char] = nextNode
+
+ this.uncheckedNodes.push({
+ parent: node,
+ char: char,
+ child: nextNode
+ })
+
+ node = nextNode
+ }
+
+ node.final = true
+ this.previousWord = word
+}
+
+lunr.TokenSet.Builder.prototype.finish = function () {
+ this.minimize(0)
+}
+
+lunr.TokenSet.Builder.prototype.minimize = function (downTo) {
+ for (var i = this.uncheckedNodes.length - 1; i >= downTo; i--) {
+ var node = this.uncheckedNodes[i],
+ childKey = node.child.toString()
+
+ if (childKey in this.minimizedNodes) {
+ node.parent.edges[node.char] = this.minimizedNodes[childKey]
+ } else {
+ // Cache the key for this node since
+ // we know it can't change anymore
+ node.child._str = childKey
+
+ this.minimizedNodes[childKey] = node.child
+ }
+
+ this.uncheckedNodes.pop()
+ }
+}
+/*!
+ * lunr.Index
+ * Copyright (C) 2018 Oliver Nightingale
+ */
+
+/**
+ * An index contains the built index of all documents and provides a query interface
+ * to the index.
+ *
+ * Usually instances of lunr.Index will not be created using this constructor, instead
+ * lunr.Builder should be used to construct new indexes, or lunr.Index.load should be
+ * used to load previously built and serialized indexes.
+ *
+ * @constructor
+ * @param {Object} attrs - The attributes of the built search index.
+ * @param {Object} attrs.invertedIndex - An index of term/field to document reference.
+ * @param {Object} attrs.fieldVectors - Field vectors
+ * @param {lunr.TokenSet} attrs.tokenSet - An set of all corpus tokens.
+ * @param {string[]} attrs.fields - The names of indexed document fields.
+ * @param {lunr.Pipeline} attrs.pipeline - The pipeline to use for search terms.
+ */
+lunr.Index = function (attrs) {
+ this.invertedIndex = attrs.invertedIndex
+ this.fieldVectors = attrs.fieldVectors
+ this.tokenSet = attrs.tokenSet
+ this.fields = attrs.fields
+ this.pipeline = attrs.pipeline
+}
+
+/**
+ * A result contains details of a document matching a search query.
+ * @typedef {Object} lunr.Index~Result
+ * @property {string} ref - The reference of the document this result represents.
+ * @property {number} score - A number between 0 and 1 representing how similar this document is to the query.
+ * @property {lunr.MatchData} matchData - Contains metadata about this match including which term(s) caused the match.
+ */
+
+/**
+ * Although lunr provides the ability to create queries using lunr.Query, it also provides a simple
+ * query language which itself is parsed into an instance of lunr.Query.
+ *
+ * For programmatically building queries it is advised to directly use lunr.Query, the query language
+ * is best used for human entered text rather than program generated text.
+ *
+ * At its simplest queries can just be a single term, e.g. `hello`, multiple terms are also supported
+ * and will be combined with OR, e.g `hello world` will match documents that contain either 'hello'
+ * or 'world', though those that contain both will rank higher in the results.
+ *
+ * Wildcards can be included in terms to match one or more unspecified characters, these wildcards can
+ * be inserted anywhere within the term, and more than one wildcard can exist in a single term. Adding
+ * wildcards will increase the number of documents that will be found but can also have a negative
+ * impact on query performance, especially with wildcards at the beginning of a term.
+ *
+ * Terms can be restricted to specific fields, e.g. `title:hello`, only documents with the term
+ * hello in the title field will match this query. Using a field not present in the index will lead
+ * to an error being thrown.
+ *
+ * Modifiers can also be added to terms, lunr supports edit distance and boost modifiers on terms. A term
+ * boost will make documents matching that term score higher, e.g. `foo^5`. Edit distance is also supported
+ * to provide fuzzy matching, e.g. 'hello~2' will match documents with hello with an edit distance of 2.
+ * Avoid large values for edit distance to improve query performance.
+ *
+ * Each term also supports a presence modifier. By default a term's presence in document is optional, however
+ * this can be changed to either required or prohibited. For a term's presence to be required in a document the
+ * term should be prefixed with a '+', e.g. `+foo bar` is a search for documents that must contain 'foo' and
+ * optionally contain 'bar'. Conversely a leading '-' sets the terms presence to prohibited, i.e. it must not
+ * appear in a document, e.g. `-foo bar` is a search for documents that do not contain 'foo' but may contain 'bar'.
+ *
+ * To escape special characters the backslash character '\' can be used, this allows searches to include
+ * characters that would normally be considered modifiers, e.g. `foo\~2` will search for a term "foo~2" instead
+ * of attempting to apply a boost of 2 to the search term "foo".
+ *
+ * @typedef {string} lunr.Index~QueryString
+ * @example
Simple single term query
+ * hello
+ * @example
Multiple term query
+ * hello world
+ * @example
term scoped to a field
+ * title:hello
+ * @example
term with a boost of 10
+ * hello^10
+ * @example
term with an edit distance of 2
+ * hello~2
+ * @example
terms with presence modifiers
+ * -foo +bar baz
+ */
+
+/**
+ * Performs a search against the index using lunr query syntax.
+ *
+ * Results will be returned sorted by their score, the most relevant results
+ * will be returned first. For details on how the score is calculated, please see
+ * the {@link https://lunrjs.com/guides/searching.html#scoring|guide}.
+ *
+ * For more programmatic querying use lunr.Index#query.
+ *
+ * @param {lunr.Index~QueryString} queryString - A string containing a lunr query.
+ * @throws {lunr.QueryParseError} If the passed query string cannot be parsed.
+ * @returns {lunr.Index~Result[]}
+ */
+lunr.Index.prototype.search = function (queryString) {
+ return this.query(function (query) {
+ var parser = new lunr.QueryParser(queryString, query)
+ parser.parse()
+ })
+}
+
+/**
+ * A query builder callback provides a query object to be used to express
+ * the query to perform on the index.
+ *
+ * @callback lunr.Index~queryBuilder
+ * @param {lunr.Query} query - The query object to build up.
+ * @this lunr.Query
+ */
+
+/**
+ * Performs a query against the index using the yielded lunr.Query object.
+ *
+ * If performing programmatic queries against the index, this method is preferred
+ * over lunr.Index#search so as to avoid the additional query parsing overhead.
+ *
+ * A query object is yielded to the supplied function which should be used to
+ * express the query to be run against the index.
+ *
+ * Note that although this function takes a callback parameter it is _not_ an
+ * asynchronous operation, the callback is just yielded a query object to be
+ * customized.
+ *
+ * @param {lunr.Index~queryBuilder} fn - A function that is used to build the query.
+ * @returns {lunr.Index~Result[]}
+ */
+lunr.Index.prototype.query = function (fn) {
+ // for each query clause
+ // * process terms
+ // * expand terms from token set
+ // * find matching documents and metadata
+ // * get document vectors
+ // * score documents
+
+ var query = new lunr.Query(this.fields),
+ matchingFields = Object.create(null),
+ queryVectors = Object.create(null),
+ termFieldCache = Object.create(null),
+ requiredMatches = Object.create(null),
+ prohibitedMatches = Object.create(null)
+
+ /*
+ * To support field level boosts a query vector is created per
+ * field. An empty vector is eagerly created to support negated
+ * queries.
+ */
+ for (var i = 0; i < this.fields.length; i++) {
+ queryVectors[this.fields[i]] = new lunr.Vector
+ }
+
+ fn.call(query, query)
+
+ for (var i = 0; i < query.clauses.length; i++) {
+ /*
+ * Unless the pipeline has been disabled for this term, which is
+ * the case for terms with wildcards, we need to pass the clause
+ * term through the search pipeline. A pipeline returns an array
+ * of processed terms. Pipeline functions may expand the passed
+ * term, which means we may end up performing multiple index lookups
+ * for a single query term.
+ */
+ var clause = query.clauses[i],
+ terms = null,
+ clauseMatches = lunr.Set.complete
+
+ if (clause.usePipeline) {
+ terms = this.pipeline.runString(clause.term, {
+ fields: clause.fields
+ })
+ } else {
+ terms = [clause.term]
+ }
+
+ for (var m = 0; m < terms.length; m++) {
+ var term = terms[m]
+
+ /*
+ * Each term returned from the pipeline needs to use the same query
+ * clause object, e.g. the same boost and or edit distance. The
+ * simplest way to do this is to re-use the clause object but mutate
+ * its term property.
+ */
+ clause.term = term
+
+ /*
+ * From the term in the clause we create a token set which will then
+ * be used to intersect the indexes token set to get a list of terms
+ * to lookup in the inverted index
+ */
+ var termTokenSet = lunr.TokenSet.fromClause(clause),
+ expandedTerms = this.tokenSet.intersect(termTokenSet).toArray()
+
+ /*
+ * If a term marked as required does not exist in the tokenSet it is
+ * impossible for the search to return any matches. We set all the field
+ * scoped required matches set to empty and stop examining any further
+ * clauses.
+ */
+ if (expandedTerms.length === 0 && clause.presence === lunr.Query.presence.REQUIRED) {
+ for (var k = 0; k < clause.fields.length; k++) {
+ var field = clause.fields[k]
+ requiredMatches[field] = lunr.Set.empty
+ }
+
+ break
+ }
+
+ for (var j = 0; j < expandedTerms.length; j++) {
+ /*
+ * For each term get the posting and termIndex, this is required for
+ * building the query vector.
+ */
+ var expandedTerm = expandedTerms[j],
+ posting = this.invertedIndex[expandedTerm],
+ termIndex = posting._index
+
+ for (var k = 0; k < clause.fields.length; k++) {
+ /*
+ * For each field that this query term is scoped by (by default
+ * all fields are in scope) we need to get all the document refs
+ * that have this term in that field.
+ *
+ * The posting is the entry in the invertedIndex for the matching
+ * term from above.
+ */
+ var field = clause.fields[k],
+ fieldPosting = posting[field],
+ matchingDocumentRefs = Object.keys(fieldPosting),
+ termField = expandedTerm + "/" + field,
+ matchingDocumentsSet = new lunr.Set(matchingDocumentRefs)
+
+ /*
+ * if the presence of this term is required ensure that the matching
+ * documents are added to the set of required matches for this clause.
+ *
+ */
+ if (clause.presence == lunr.Query.presence.REQUIRED) {
+ clauseMatches = clauseMatches.union(matchingDocumentsSet)
+
+ if (requiredMatches[field] === undefined) {
+ requiredMatches[field] = lunr.Set.complete
+ }
+ }
+
+ /*
+ * if the presence of this term is prohibited ensure that the matching
+ * documents are added to the set of prohibited matches for this field,
+ * creating that set if it does not yet exist.
+ */
+ if (clause.presence == lunr.Query.presence.PROHIBITED) {
+ if (prohibitedMatches[field] === undefined) {
+ prohibitedMatches[field] = lunr.Set.empty
+ }
+
+ prohibitedMatches[field] = prohibitedMatches[field].union(matchingDocumentsSet)
+
+ /*
+ * Prohibited matches should not be part of the query vector used for
+ * similarity scoring and no metadata should be extracted so we continue
+ * to the next field
+ */
+ continue
+ }
+
+ /*
+ * The query field vector is populated using the termIndex found for
+ * the term and a unit value with the appropriate boost applied.
+ * Using upsert because there could already be an entry in the vector
+ * for the term we are working with. In that case we just add the scores
+ * together.
+ */
+ queryVectors[field].upsert(termIndex, clause.boost, function (a, b) { return a + b })
+
+ /**
+ * If we've already seen this term, field combo then we've already collected
+ * the matching documents and metadata, no need to go through all that again
+ */
+ if (termFieldCache[termField]) {
+ continue
+ }
+
+ for (var l = 0; l < matchingDocumentRefs.length; l++) {
+ /*
+ * All metadata for this term/field/document triple
+ * are then extracted and collected into an instance
+ * of lunr.MatchData ready to be returned in the query
+ * results
+ */
+ var matchingDocumentRef = matchingDocumentRefs[l],
+ matchingFieldRef = new lunr.FieldRef (matchingDocumentRef, field),
+ metadata = fieldPosting[matchingDocumentRef],
+ fieldMatch
+
+ if ((fieldMatch = matchingFields[matchingFieldRef]) === undefined) {
+ matchingFields[matchingFieldRef] = new lunr.MatchData (expandedTerm, field, metadata)
+ } else {
+ fieldMatch.add(expandedTerm, field, metadata)
+ }
+
+ }
+
+ termFieldCache[termField] = true
+ }
+ }
+ }
+
+ /**
+ * If the presence was required we need to update the requiredMatches field sets.
+ * We do this after all fields for the term have collected their matches because
+ * the clause terms presence is required in _any_ of the fields not _all_ of the
+ * fields.
+ */
+ if (clause.presence === lunr.Query.presence.REQUIRED) {
+ for (var k = 0; k < clause.fields.length; k++) {
+ var field = clause.fields[k]
+ requiredMatches[field] = requiredMatches[field].intersect(clauseMatches)
+ }
+ }
+ }
+
+ /**
+ * Need to combine the field scoped required and prohibited
+ * matching documents into a global set of required and prohibited
+ * matches
+ */
+ var allRequiredMatches = lunr.Set.complete,
+ allProhibitedMatches = lunr.Set.empty
+
+ for (var i = 0; i < this.fields.length; i++) {
+ var field = this.fields[i]
+
+ if (requiredMatches[field]) {
+ allRequiredMatches = allRequiredMatches.intersect(requiredMatches[field])
+ }
+
+ if (prohibitedMatches[field]) {
+ allProhibitedMatches = allProhibitedMatches.union(prohibitedMatches[field])
+ }
+ }
+
+ var matchingFieldRefs = Object.keys(matchingFields),
+ results = [],
+ matches = Object.create(null)
+
+ /*
+ * If the query is negated (contains only prohibited terms)
+ * we need to get _all_ fieldRefs currently existing in the
+ * index. This is only done when we know that the query is
+ * entirely prohibited terms to avoid any cost of getting all
+ * fieldRefs unnecessarily.
+ *
+ * Additionally, blank MatchData must be created to correctly
+ * populate the results.
+ */
+ if (query.isNegated()) {
+ matchingFieldRefs = Object.keys(this.fieldVectors)
+
+ for (var i = 0; i < matchingFieldRefs.length; i++) {
+ var matchingFieldRef = matchingFieldRefs[i]
+ var fieldRef = lunr.FieldRef.fromString(matchingFieldRef)
+ matchingFields[matchingFieldRef] = new lunr.MatchData
+ }
+ }
+
+ for (var i = 0; i < matchingFieldRefs.length; i++) {
+ /*
+ * Currently we have document fields that match the query, but we
+ * need to return documents. The matchData and scores are combined
+ * from multiple fields belonging to the same document.
+ *
+ * Scores are calculated by field, using the query vectors created
+ * above, and combined into a final document score using addition.
+ */
+ var fieldRef = lunr.FieldRef.fromString(matchingFieldRefs[i]),
+ docRef = fieldRef.docRef
+
+ if (!allRequiredMatches.contains(docRef)) {
+ continue
+ }
+
+ if (allProhibitedMatches.contains(docRef)) {
+ continue
+ }
+
+ var fieldVector = this.fieldVectors[fieldRef],
+ score = queryVectors[fieldRef.fieldName].similarity(fieldVector),
+ docMatch
+
+ if ((docMatch = matches[docRef]) !== undefined) {
+ docMatch.score += score
+ docMatch.matchData.combine(matchingFields[fieldRef])
+ } else {
+ var match = {
+ ref: docRef,
+ score: score,
+ matchData: matchingFields[fieldRef]
+ }
+ matches[docRef] = match
+ results.push(match)
+ }
+ }
+
+ /*
+ * Sort the results objects by score, highest first.
+ */
+ return results.sort(function (a, b) {
+ return b.score - a.score
+ })
+}
+
+/**
+ * Prepares the index for JSON serialization.
+ *
+ * The schema for this JSON blob will be described in a
+ * separate JSON schema file.
+ *
+ * @returns {Object}
+ */
+lunr.Index.prototype.toJSON = function () {
+ var invertedIndex = Object.keys(this.invertedIndex)
+ .sort()
+ .map(function (term) {
+ return [term, this.invertedIndex[term]]
+ }, this)
+
+ var fieldVectors = Object.keys(this.fieldVectors)
+ .map(function (ref) {
+ return [ref, this.fieldVectors[ref].toJSON()]
+ }, this)
+
+ return {
+ version: lunr.version,
+ fields: this.fields,
+ fieldVectors: fieldVectors,
+ invertedIndex: invertedIndex,
+ pipeline: this.pipeline.toJSON()
+ }
+}
+
+/**
+ * Loads a previously serialized lunr.Index
+ *
+ * @param {Object} serializedIndex - A previously serialized lunr.Index
+ * @returns {lunr.Index}
+ */
+lunr.Index.load = function (serializedIndex) {
+ var attrs = {},
+ fieldVectors = {},
+ serializedVectors = serializedIndex.fieldVectors,
+ invertedIndex = Object.create(null),
+ serializedInvertedIndex = serializedIndex.invertedIndex,
+ tokenSetBuilder = new lunr.TokenSet.Builder,
+ pipeline = lunr.Pipeline.load(serializedIndex.pipeline)
+
+ if (serializedIndex.version != lunr.version) {
+ lunr.utils.warn("Version mismatch when loading serialised index. Current version of lunr '" + lunr.version + "' does not match serialized index '" + serializedIndex.version + "'")
+ }
+
+ for (var i = 0; i < serializedVectors.length; i++) {
+ var tuple = serializedVectors[i],
+ ref = tuple[0],
+ elements = tuple[1]
+
+ fieldVectors[ref] = new lunr.Vector(elements)
+ }
+
+ for (var i = 0; i < serializedInvertedIndex.length; i++) {
+ var tuple = serializedInvertedIndex[i],
+ term = tuple[0],
+ posting = tuple[1]
+
+ tokenSetBuilder.insert(term)
+ invertedIndex[term] = posting
+ }
+
+ tokenSetBuilder.finish()
+
+ attrs.fields = serializedIndex.fields
+
+ attrs.fieldVectors = fieldVectors
+ attrs.invertedIndex = invertedIndex
+ attrs.tokenSet = tokenSetBuilder.root
+ attrs.pipeline = pipeline
+
+ return new lunr.Index(attrs)
+}
+/*!
+ * lunr.Builder
+ * Copyright (C) 2018 Oliver Nightingale
+ */
+
+/**
+ * lunr.Builder performs indexing on a set of documents and
+ * returns instances of lunr.Index ready for querying.
+ *
+ * All configuration of the index is done via the builder, the
+ * fields to index, the document reference, the text processing
+ * pipeline and document scoring parameters are all set on the
+ * builder before indexing.
+ *
+ * @constructor
+ * @property {string} _ref - Internal reference to the document reference field.
+ * @property {string[]} _fields - Internal reference to the document fields to index.
+ * @property {object} invertedIndex - The inverted index maps terms to document fields.
+ * @property {object} documentTermFrequencies - Keeps track of document term frequencies.
+ * @property {object} documentLengths - Keeps track of the length of documents added to the index.
+ * @property {lunr.tokenizer} tokenizer - Function for splitting strings into tokens for indexing.
+ * @property {lunr.Pipeline} pipeline - The pipeline performs text processing on tokens before indexing.
+ * @property {lunr.Pipeline} searchPipeline - A pipeline for processing search terms before querying the index.
+ * @property {number} documentCount - Keeps track of the total number of documents indexed.
+ * @property {number} _b - A parameter to control field length normalization, setting this to 0 disabled normalization, 1 fully normalizes field lengths, the default value is 0.75.
+ * @property {number} _k1 - A parameter to control how quickly an increase in term frequency results in term frequency saturation, the default value is 1.2.
+ * @property {number} termIndex - A counter incremented for each unique term, used to identify a terms position in the vector space.
+ * @property {array} metadataWhitelist - A list of metadata keys that have been whitelisted for entry in the index.
+ */
+lunr.Builder = function () {
+ this._ref = "id"
+ this._fields = Object.create(null)
+ this._documents = Object.create(null)
+ this.invertedIndex = Object.create(null)
+ this.fieldTermFrequencies = {}
+ this.fieldLengths = {}
+ this.tokenizer = lunr.tokenizer
+ this.pipeline = new lunr.Pipeline
+ this.searchPipeline = new lunr.Pipeline
+ this.documentCount = 0
+ this._b = 0.75
+ this._k1 = 1.2
+ this.termIndex = 0
+ this.metadataWhitelist = []
+}
+
+/**
+ * Sets the document field used as the document reference. Every document must have this field.
+ * The type of this field in the document should be a string, if it is not a string it will be
+ * coerced into a string by calling toString.
+ *
+ * The default ref is 'id'.
+ *
+ * The ref should _not_ be changed during indexing, it should be set before any documents are
+ * added to the index. Changing it during indexing can lead to inconsistent results.
+ *
+ * @param {string} ref - The name of the reference field in the document.
+ */
+lunr.Builder.prototype.ref = function (ref) {
+ this._ref = ref
+}
+
+/**
+ * A function that is used to extract a field from a document.
+ *
+ * Lunr expects a field to be at the top level of a document, if however the field
+ * is deeply nested within a document an extractor function can be used to extract
+ * the right field for indexing.
+ *
+ * @callback fieldExtractor
+ * @param {object} doc - The document being added to the index.
+ * @returns {?(string|object|object[])} obj - The object that will be indexed for this field.
+ * @example
Extracting a nested field
+ * function (doc) { return doc.nested.field }
+ */
+
+/**
+ * Adds a field to the list of document fields that will be indexed. Every document being
+ * indexed should have this field. Null values for this field in indexed documents will
+ * not cause errors but will limit the chance of that document being retrieved by searches.
+ *
+ * All fields should be added before adding documents to the index. Adding fields after
+ * a document has been indexed will have no effect on already indexed documents.
+ *
+ * Fields can be boosted at build time. This allows terms within that field to have more
+ * importance when ranking search results. Use a field boost to specify that matches within
+ * one field are more important than other fields.
+ *
+ * @param {string} fieldName - The name of a field to index in all documents.
+ * @param {object} attributes - Optional attributes associated with this field.
+ * @param {number} [attributes.boost=1] - Boost applied to all terms within this field.
+ * @param {fieldExtractor} [attributes.extractor] - Function to extract a field from a document.
+ * @throws {RangeError} fieldName cannot contain unsupported characters '/'
+ */
+lunr.Builder.prototype.field = function (fieldName, attributes) {
+ if (/\//.test(fieldName)) {
+ throw new RangeError ("Field '" + fieldName + "' contains illegal character '/'")
+ }
+
+ this._fields[fieldName] = attributes || {}
+}
+
+/**
+ * A parameter to tune the amount of field length normalisation that is applied when
+ * calculating relevance scores. A value of 0 will completely disable any normalisation
+ * and a value of 1 will fully normalise field lengths. The default is 0.75. Values of b
+ * will be clamped to the range 0 - 1.
+ *
+ * @param {number} number - The value to set for this tuning parameter.
+ */
+lunr.Builder.prototype.b = function (number) {
+ if (number < 0) {
+ this._b = 0
+ } else if (number > 1) {
+ this._b = 1
+ } else {
+ this._b = number
+ }
+}
+
+/**
+ * A parameter that controls the speed at which a rise in term frequency results in term
+ * frequency saturation. The default value is 1.2. Setting this to a higher value will give
+ * slower saturation levels, a lower value will result in quicker saturation.
+ *
+ * @param {number} number - The value to set for this tuning parameter.
+ */
+lunr.Builder.prototype.k1 = function (number) {
+ this._k1 = number
+}
+
+/**
+ * Adds a document to the index.
+ *
+ * Before adding fields to the index the index should have been fully setup, with the document
+ * ref and all fields to index already having been specified.
+ *
+ * The document must have a field name as specified by the ref (by default this is 'id') and
+ * it should have all fields defined for indexing, though null or undefined values will not
+ * cause errors.
+ *
+ * Entire documents can be boosted at build time. Applying a boost to a document indicates that
+ * this document should rank higher in search results than other documents.
+ *
+ * @param {object} doc - The document to add to the index.
+ * @param {object} attributes - Optional attributes associated with this document.
+ * @param {number} [attributes.boost=1] - Boost applied to all terms within this document.
+ */
+lunr.Builder.prototype.add = function (doc, attributes) {
+ var docRef = doc[this._ref],
+ fields = Object.keys(this._fields)
+
+ this._documents[docRef] = attributes || {}
+ this.documentCount += 1
+
+ for (var i = 0; i < fields.length; i++) {
+ var fieldName = fields[i],
+ extractor = this._fields[fieldName].extractor,
+ field = extractor ? extractor(doc) : doc[fieldName],
+ tokens = this.tokenizer(field, {
+ fields: [fieldName]
+ }),
+ terms = this.pipeline.run(tokens),
+ fieldRef = new lunr.FieldRef (docRef, fieldName),
+ fieldTerms = Object.create(null)
+
+ this.fieldTermFrequencies[fieldRef] = fieldTerms
+ this.fieldLengths[fieldRef] = 0
+
+ // store the length of this field for this document
+ this.fieldLengths[fieldRef] += terms.length
+
+ // calculate term frequencies for this field
+ for (var j = 0; j < terms.length; j++) {
+ var term = terms[j]
+
+ if (fieldTerms[term] == undefined) {
+ fieldTerms[term] = 0
+ }
+
+ fieldTerms[term] += 1
+
+ // add to inverted index
+ // create an initial posting if one doesn't exist
+ if (this.invertedIndex[term] == undefined) {
+ var posting = Object.create(null)
+ posting["_index"] = this.termIndex
+ this.termIndex += 1
+
+ for (var k = 0; k < fields.length; k++) {
+ posting[fields[k]] = Object.create(null)
+ }
+
+ this.invertedIndex[term] = posting
+ }
+
+ // add an entry for this term/fieldName/docRef to the invertedIndex
+ if (this.invertedIndex[term][fieldName][docRef] == undefined) {
+ this.invertedIndex[term][fieldName][docRef] = Object.create(null)
+ }
+
+ // store all whitelisted metadata about this token in the
+ // inverted index
+ for (var l = 0; l < this.metadataWhitelist.length; l++) {
+ var metadataKey = this.metadataWhitelist[l],
+ metadata = term.metadata[metadataKey]
+
+ if (this.invertedIndex[term][fieldName][docRef][metadataKey] == undefined) {
+ this.invertedIndex[term][fieldName][docRef][metadataKey] = []
+ }
+
+ this.invertedIndex[term][fieldName][docRef][metadataKey].push(metadata)
+ }
+ }
+
+ }
+}
+
+/**
+ * Calculates the average document length for this index
+ *
+ * @private
+ */
+lunr.Builder.prototype.calculateAverageFieldLengths = function () {
+
+ var fieldRefs = Object.keys(this.fieldLengths),
+ numberOfFields = fieldRefs.length,
+ accumulator = {},
+ documentsWithField = {}
+
+ for (var i = 0; i < numberOfFields; i++) {
+ var fieldRef = lunr.FieldRef.fromString(fieldRefs[i]),
+ field = fieldRef.fieldName
+
+ documentsWithField[field] || (documentsWithField[field] = 0)
+ documentsWithField[field] += 1
+
+ accumulator[field] || (accumulator[field] = 0)
+ accumulator[field] += this.fieldLengths[fieldRef]
+ }
+
+ var fields = Object.keys(this._fields)
+
+ for (var i = 0; i < fields.length; i++) {
+ var fieldName = fields[i]
+ accumulator[fieldName] = accumulator[fieldName] / documentsWithField[fieldName]
+ }
+
+ this.averageFieldLength = accumulator
+}
+
+/**
+ * Builds a vector space model of every document using lunr.Vector
+ *
+ * @private
+ */
+lunr.Builder.prototype.createFieldVectors = function () {
+ var fieldVectors = {},
+ fieldRefs = Object.keys(this.fieldTermFrequencies),
+ fieldRefsLength = fieldRefs.length,
+ termIdfCache = Object.create(null)
+
+ for (var i = 0; i < fieldRefsLength; i++) {
+ var fieldRef = lunr.FieldRef.fromString(fieldRefs[i]),
+ fieldName = fieldRef.fieldName,
+ fieldLength = this.fieldLengths[fieldRef],
+ fieldVector = new lunr.Vector,
+ termFrequencies = this.fieldTermFrequencies[fieldRef],
+ terms = Object.keys(termFrequencies),
+ termsLength = terms.length
+
+
+ var fieldBoost = this._fields[fieldName].boost || 1,
+ docBoost = this._documents[fieldRef.docRef].boost || 1
+
+ for (var j = 0; j < termsLength; j++) {
+ var term = terms[j],
+ tf = termFrequencies[term],
+ termIndex = this.invertedIndex[term]._index,
+ idf, score, scoreWithPrecision
+
+ if (termIdfCache[term] === undefined) {
+ idf = lunr.idf(this.invertedIndex[term], this.documentCount)
+ termIdfCache[term] = idf
+ } else {
+ idf = termIdfCache[term]
+ }
+
+ score = idf * ((this._k1 + 1) * tf) / (this._k1 * (1 - this._b + this._b * (fieldLength / this.averageFieldLength[fieldName])) + tf)
+ score *= fieldBoost
+ score *= docBoost
+ scoreWithPrecision = Math.round(score * 1000) / 1000
+ // Converts 1.23456789 to 1.234.
+ // Reducing the precision so that the vectors take up less
+ // space when serialised. Doing it now so that they behave
+ // the same before and after serialisation. Also, this is
+ // the fastest approach to reducing a number's precision in
+ // JavaScript.
+
+ fieldVector.insert(termIndex, scoreWithPrecision)
+ }
+
+ fieldVectors[fieldRef] = fieldVector
+ }
+
+ this.fieldVectors = fieldVectors
+}
+
+/**
+ * Creates a token set of all tokens in the index using lunr.TokenSet
+ *
+ * @private
+ */
+lunr.Builder.prototype.createTokenSet = function () {
+ this.tokenSet = lunr.TokenSet.fromArray(
+ Object.keys(this.invertedIndex).sort()
+ )
+}
+
+/**
+ * Builds the index, creating an instance of lunr.Index.
+ *
+ * This completes the indexing process and should only be called
+ * once all documents have been added to the index.
+ *
+ * @returns {lunr.Index}
+ */
+lunr.Builder.prototype.build = function () {
+ this.calculateAverageFieldLengths()
+ this.createFieldVectors()
+ this.createTokenSet()
+
+ return new lunr.Index({
+ invertedIndex: this.invertedIndex,
+ fieldVectors: this.fieldVectors,
+ tokenSet: this.tokenSet,
+ fields: Object.keys(this._fields),
+ pipeline: this.searchPipeline
+ })
+}
+
+/**
+ * Applies a plugin to the index builder.
+ *
+ * A plugin is a function that is called with the index builder as its context.
+ * Plugins can be used to customise or extend the behaviour of the index
+ * in some way. A plugin is just a function, that encapsulated the custom
+ * behaviour that should be applied when building the index.
+ *
+ * The plugin function will be called with the index builder as its argument, additional
+ * arguments can also be passed when calling use. The function will be called
+ * with the index builder as its context.
+ *
+ * @param {Function} plugin The plugin to apply.
+ */
+lunr.Builder.prototype.use = function (fn) {
+ var args = Array.prototype.slice.call(arguments, 1)
+ args.unshift(this)
+ fn.apply(this, args)
+}
+/**
+ * Contains and collects metadata about a matching document.
+ * A single instance of lunr.MatchData is returned as part of every
+ * lunr.Index~Result.
+ *
+ * @constructor
+ * @param {string} term - The term this match data is associated with
+ * @param {string} field - The field in which the term was found
+ * @param {object} metadata - The metadata recorded about this term in this field
+ * @property {object} metadata - A cloned collection of metadata associated with this document.
+ * @see {@link lunr.Index~Result}
+ */
+lunr.MatchData = function (term, field, metadata) {
+ var clonedMetadata = Object.create(null),
+ metadataKeys = Object.keys(metadata || {})
+
+ // Cloning the metadata to prevent the original
+ // being mutated during match data combination.
+ // Metadata is kept in an array within the inverted
+ // index so cloning the data can be done with
+ // Array#slice
+ for (var i = 0; i < metadataKeys.length; i++) {
+ var key = metadataKeys[i]
+ clonedMetadata[key] = metadata[key].slice()
+ }
+
+ this.metadata = Object.create(null)
+
+ if (term !== undefined) {
+ this.metadata[term] = Object.create(null)
+ this.metadata[term][field] = clonedMetadata
+ }
+}
+
+/**
+ * An instance of lunr.MatchData will be created for every term that matches a
+ * document. However only one instance is required in a lunr.Index~Result. This
+ * method combines metadata from another instance of lunr.MatchData with this
+ * objects metadata.
+ *
+ * @param {lunr.MatchData} otherMatchData - Another instance of match data to merge with this one.
+ * @see {@link lunr.Index~Result}
+ */
+lunr.MatchData.prototype.combine = function (otherMatchData) {
+ var terms = Object.keys(otherMatchData.metadata)
+
+ for (var i = 0; i < terms.length; i++) {
+ var term = terms[i],
+ fields = Object.keys(otherMatchData.metadata[term])
+
+ if (this.metadata[term] == undefined) {
+ this.metadata[term] = Object.create(null)
+ }
+
+ for (var j = 0; j < fields.length; j++) {
+ var field = fields[j],
+ keys = Object.keys(otherMatchData.metadata[term][field])
+
+ if (this.metadata[term][field] == undefined) {
+ this.metadata[term][field] = Object.create(null)
+ }
+
+ for (var k = 0; k < keys.length; k++) {
+ var key = keys[k]
+
+ if (this.metadata[term][field][key] == undefined) {
+ this.metadata[term][field][key] = otherMatchData.metadata[term][field][key]
+ } else {
+ this.metadata[term][field][key] = this.metadata[term][field][key].concat(otherMatchData.metadata[term][field][key])
+ }
+
+ }
+ }
+ }
+}
+
+/**
+ * Add metadata for a term/field pair to this instance of match data.
+ *
+ * @param {string} term - The term this match data is associated with
+ * @param {string} field - The field in which the term was found
+ * @param {object} metadata - The metadata recorded about this term in this field
+ */
+lunr.MatchData.prototype.add = function (term, field, metadata) {
+ if (!(term in this.metadata)) {
+ this.metadata[term] = Object.create(null)
+ this.metadata[term][field] = metadata
+ return
+ }
+
+ if (!(field in this.metadata[term])) {
+ this.metadata[term][field] = metadata
+ return
+ }
+
+ var metadataKeys = Object.keys(metadata)
+
+ for (var i = 0; i < metadataKeys.length; i++) {
+ var key = metadataKeys[i]
+
+ if (key in this.metadata[term][field]) {
+ this.metadata[term][field][key] = this.metadata[term][field][key].concat(metadata[key])
+ } else {
+ this.metadata[term][field][key] = metadata[key]
+ }
+ }
+}
+/**
+ * A lunr.Query provides a programmatic way of defining queries to be performed
+ * against a {@link lunr.Index}.
+ *
+ * Prefer constructing a lunr.Query using the {@link lunr.Index#query} method
+ * so the query object is pre-initialized with the right index fields.
+ *
+ * @constructor
+ * @property {lunr.Query~Clause[]} clauses - An array of query clauses.
+ * @property {string[]} allFields - An array of all available fields in a lunr.Index.
+ */
+lunr.Query = function (allFields) {
+ this.clauses = []
+ this.allFields = allFields
+}
+
+/**
+ * Constants for indicating what kind of automatic wildcard insertion will be used when constructing a query clause.
+ *
+ * This allows wildcards to be added to the beginning and end of a term without having to manually do any string
+ * concatenation.
+ *
+ * The wildcard constants can be bitwise combined to select both leading and trailing wildcards.
+ *
+ * @constant
+ * @default
+ * @property {number} wildcard.NONE - The term will have no wildcards inserted, this is the default behaviour
+ * @property {number} wildcard.LEADING - Prepend the term with a wildcard, unless a leading wildcard already exists
+ * @property {number} wildcard.TRAILING - Append a wildcard to the term, unless a trailing wildcard already exists
+ * @see lunr.Query~Clause
+ * @see lunr.Query#clause
+ * @see lunr.Query#term
+ * @example
+ * query.term('foo', {
+ * wildcard: lunr.Query.wildcard.LEADING | lunr.Query.wildcard.TRAILING
+ * })
+ */
+
+lunr.Query.wildcard = new String ("*")
+lunr.Query.wildcard.NONE = 0
+lunr.Query.wildcard.LEADING = 1
+lunr.Query.wildcard.TRAILING = 2
+
+/**
+ * Constants for indicating what kind of presence a term must have in matching documents.
+ *
+ * @constant
+ * @enum {number}
+ * @see lunr.Query~Clause
+ * @see lunr.Query#clause
+ * @see lunr.Query#term
+ * @example
query term with required presence
+ * query.term('foo', { presence: lunr.Query.presence.REQUIRED })
+ */
+lunr.Query.presence = {
+ /**
+ * Term's presence in a document is optional, this is the default value.
+ */
+ OPTIONAL: 1,
+
+ /**
+ * Term's presence in a document is required, documents that do not contain
+ * this term will not be returned.
+ */
+ REQUIRED: 2,
+
+ /**
+ * Term's presence in a document is prohibited, documents that do contain
+ * this term will not be returned.
+ */
+ PROHIBITED: 3
+}
+
+/**
+ * A single clause in a {@link lunr.Query} contains a term and details on how to
+ * match that term against a {@link lunr.Index}.
+ *
+ * @typedef {Object} lunr.Query~Clause
+ * @property {string[]} fields - The fields in an index this clause should be matched against.
+ * @property {number} [boost=1] - Any boost that should be applied when matching this clause.
+ * @property {number} [editDistance] - Whether the term should have fuzzy matching applied, and how fuzzy the match should be.
+ * @property {boolean} [usePipeline] - Whether the term should be passed through the search pipeline.
+ * @property {number} [wildcard=lunr.Query.wildcard.NONE] - Whether the term should have wildcards appended or prepended.
+ * @property {number} [presence=lunr.Query.presence.OPTIONAL] - The terms presence in any matching documents.
+ */
+
+/**
+ * Adds a {@link lunr.Query~Clause} to this query.
+ *
+ * Unless the clause contains the fields to be matched all fields will be matched. In addition
+ * a default boost of 1 is applied to the clause.
+ *
+ * @param {lunr.Query~Clause} clause - The clause to add to this query.
+ * @see lunr.Query~Clause
+ * @returns {lunr.Query}
+ */
+lunr.Query.prototype.clause = function (clause) {
+ if (!('fields' in clause)) {
+ clause.fields = this.allFields
+ }
+
+ if (!('boost' in clause)) {
+ clause.boost = 1
+ }
+
+ if (!('usePipeline' in clause)) {
+ clause.usePipeline = true
+ }
+
+ if (!('wildcard' in clause)) {
+ clause.wildcard = lunr.Query.wildcard.NONE
+ }
+
+ if ((clause.wildcard & lunr.Query.wildcard.LEADING) && (clause.term.charAt(0) != lunr.Query.wildcard)) {
+ clause.term = "*" + clause.term
+ }
+
+ if ((clause.wildcard & lunr.Query.wildcard.TRAILING) && (clause.term.slice(-1) != lunr.Query.wildcard)) {
+ clause.term = "" + clause.term + "*"
+ }
+
+ if (!('presence' in clause)) {
+ clause.presence = lunr.Query.presence.OPTIONAL
+ }
+
+ this.clauses.push(clause)
+
+ return this
+}
+
+/**
+ * A negated query is one in which every clause has a presence of
+ * prohibited. These queries require some special processing to return
+ * the expected results.
+ *
+ * @returns boolean
+ */
+lunr.Query.prototype.isNegated = function () {
+ for (var i = 0; i < this.clauses.length; i++) {
+ if (this.clauses[i].presence != lunr.Query.presence.PROHIBITED) {
+ return false
+ }
+ }
+
+ return true
+}
+
+/**
+ * Adds a term to the current query, under the covers this will create a {@link lunr.Query~Clause}
+ * to the list of clauses that make up this query.
+ *
+ * The term is used as is, i.e. no tokenization will be performed by this method. Instead conversion
+ * to a token or token-like string should be done before calling this method.
+ *
+ * The term will be converted to a string by calling `toString`. Multiple terms can be passed as an
+ * array, each term in the array will share the same options.
+ *
+ * @param {object|object[]} term - The term(s) to add to the query.
+ * @param {object} [options] - Any additional properties to add to the query clause.
+ * @returns {lunr.Query}
+ * @see lunr.Query#clause
+ * @see lunr.Query~Clause
+ * @example
adding a single term to a query
+ * query.term("foo")
+ * @example
adding a single term to a query and specifying search fields, term boost and automatic trailing wildcard
We soon realized that while these tools are great ingredients which are better served as a recipe. In another words, Please tell me what tools to use when and how? This is where Troubleshoot Blade comes handy.
Image above shows about 30% of my requests are failing and it is not entire Web app down situation. (Blue represent success, Red represents failures). I can choose to filter the graph by hostnames etc.
]
Above image indicates that I have 2 Web Apps (Sites) in the App Service Plan. DemoDaas seems to be the one using all CPU and Memory in this case. At the same note, you can also observe that PHPDemo could be taking all CPU and Memory, hence impacting performance for DemoDaas. You can use this view to separate out the culprits from victims and go to Step 3 to click on “Restart Button” for culprit Web App. Finally, Restart is really not an answer to all the problems and that’s where the Restart button is not that glorious. If HTTP 5xx is because a bug in your application and not the hostile surrounding it found itself in, then restarts are not really going to help. This is where we move to next Step.
]
![traffic_Increase_thumb[1]](https://azurecomcdn.azureedge.net/mediahandler/acomblog/media/Default/blog/a14249d7-a391-4be3-9ba3-33b51b45f348.jpg)
+
+4. Click on SQL Database to choose and existing or new SQL Azure database. You can create a new database in an existing SQL Azure server if the web app and SQL Azure server are in the same location.
+
+
+
+5. Click on Create to start deployment of the Episerver application. You can check the “Pin to dashboard” checkbox to pin the resource group in Azure portal dashboard for easy access.
+
+
+
+8. The Episerver application installer wizard will walk you through the installation.
+
+
+
+9. Once the wizard completes, you can access the CMS in edit mode, by appending /episerver/cms/edit to the site URL. For example, the URL would look like 
+
+
+
+
+
+Select Custom export method to have the ability to modify how the script should be generated. Click on GO to generate the script and save the file locally .
+
+
+
+
+Once you have successfully exported the database, then inspect your MySQL database script to check if your application stores the site URL in the database. If yes, then update the URL to use Azure app service web app URL or custom domain if the custom domain is already pre-configured on your Azure web app. Your script is ready to be imported.
+
+
+
+
+
+
+
+3. Login to the Azure portal . Click on your web app using MySQL in-app. Select MySQL in-app setting for your web app and Click on Export button under MySQL in App Export
+
+
+4. You have a choice of using a connections string for your production database or enter the credentials manually. Once the production database connection information has been entered , click on Save to start the process of export. During the export a connection string will be added to the connection string setting in the portal.
+
+
+
+During the export , you cannot make any changes to MySQL in-app configuration in the portal. All options will be disabled to manage MySQL in-app during export process .You must wait until the export is completed.
+
+
+
+8. Once the export is successful , review your production database to make sure all the content was successfully updated. Note we do not turn off the MySQL in-app feature since your production application may still be using it.
+
+Update your application to connect to the production database and test your application before going live with your application. After successful testing , you can now turn off MySQL in-app feature for your web app to continue using production database.
+
+
+
+
+
+3. Login to the Azure portal . Click on your web app using MySQL in-app. Select MySQL in-app setting for your web app and Click on Export button under MySQL in App Export
+
+
+4. You have a choice of using a connections string for your production database or enter the credentials manually. Once the production database connection information has been entered , click on Save to start the process of export. During the export a connection string will be added to the connection string setting in the portal.
+
+
+
+During the export , you cannot make any changes to MySQL in-app configuration in the portal. All options will be disabled to manage MySQL in-app during export process .You must wait until the export is completed.
+
+
+
+8. Once the export is successful , review your production database to make sure all the content was successfully updated. Note we do not turn off the MySQL in-app feature since your production application may still be using it.
+
+Update your application to connect to the production database and test your application before going live with your application. After successful testing , you can now turn off MySQL in-app feature for your web app to continue using production database.
+
+
+
+
![clip_image002[6]](/AppService/media/2017/03/clip_image00261.png "clip_image002[6]")
![clip_image002[8]](/AppService/media/2017/03/clip_image00281.png "clip_image002[8]")
+For PostgreSQL :
+
+
+
+
+Update DATABASES setting in local settings.py file in your application. to read from App Settings environment variables.
+
+
+Note that some applications frameworks may not support SSL , hence check your application framework documentation on whether to disable or enable SSL.
+
+
+
+
+My name is Glenna and I am a software engineering intern on the Azure Functions team in Redmond, WA. As I write this, I am finishing up my last day on my twelfth and final week at Microsoft. My internship was a truly incredible experience. I learned a great deal not just about specific programming languages, but also about good engineering design practices. I got to work on both the nuts and bolts of my features as well as the Azure Functions Portal UX and UI.
+
+I attend the University of Virginia in Charlottesville, Virginia. In May of 2018, I will graduate with a Bachelor of Science in Computer Science.
+
+
+
+
+
+
+
+
+
+If you have any questions about any of this features or App Service in general be sure to check our forums in 
+
+Using the new editor, you can create mock APIs. You do this by using only response overrides and no backend URL. Mock APIs allow you to create a simple API at your real REST endpoint, allowing developers to start testing API integrations while the API is still under development.
+
+
+
+
? Integrate your application with Application Insights and get the unified experience that brings the best of both worlds. We just want to close by sharing some articles around Application Insights.
+ 
button. This will generate the report and download it after a few seconds.
Leave a comment
+ + +