Merge branch 'master' into dependabot/npm_and_yarn/multi-36e86be00e

.github/workflows/deploy-to-staging-site.yml

@@ -44,7 +44,7 @@ jobs:
       run: cd _site && zip -r ../blog.zip .
 
     - name: Upload artifact for deployment job
-      uses: actions/upload-artifact@v2
+      uses: actions/upload-artifact@v4
       with:
         name: jekyll-app
         path: blog.zip
@@ -106,7 +106,7 @@ jobs:
           az account show
 
     - name: Download artifact from build job
-      uses: actions/download-artifact@v2
+      uses: actions/download-artifact@v4
       with:
         name: jekyll-app
 

_posts/2021-06-22-Root-CA-on App-Service-Guide.md

@@ -6,21 +6,22 @@ toc_sticky: true
 category: certsdomains
 ---
 
-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.)
+App Service has a list of Trusted Root Certificates which you cannot modify in the multi-tenant Windows variant version of App Service, but you can load your own Certificate Authority (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:
+When an Windows app hosted on Azure App Service tries to connect to a remote endpoint over SSL, it is important that the certificate on the 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:
+In this situation, there are two solutions:
 
 1. 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](#how-to-get-a-list-of-trusted-root-ca-on-app-service-using-kudu)
 1. 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](https://docs.microsoft.com/en-us/azure/app-service/environment/certificates#private-client-certificate)
 
+In the multi-tenant Linux and Windows Container variant version of App Service you can [load certificates](https://learn.microsoft.com/en-us/azure/app-service/configure-ssl-certificate-in-code?tabs=linux#load-certificate-in-linuxwindows-containers) and leverage them following a typical approach depending on the image used to update the Trusted Root Store.
 
 ## How to get a list of Trusted Root CA on App Service using Kudu
 

_posts/2021-9-16-App-Service-Restarts.md

@@ -1,5 +1,5 @@
 ---
-title: "Web App (Windows) Restart Operations"
+title: "Web App (Windows) restart operations"
 author_name: "Ignacio Alvarez Arenas"
 category: diagnostics
 toc: true
@@ -9,46 +9,46 @@ toc_sticky: true
 
 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 
+## 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 
+### 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 
+### 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 
+### Soft restart 
 
-When applying soft restart, which you can learn about here: [Web Apps - Restart](https://docs.microsoft.com/en-us/rest/api/appservice/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.   
+When applying soft restart, which you can learn about here: [Web Apps - Restart](https://learn.microsoft.com/rest/api/appservice/web-apps/restart?view=rest-appservice-2024-04-01), 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 
+## 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](https://docs.microsoft.com/en-us/rest/api/appservice/app-service-plans/reboot-worker)
+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](https://learn.microsoft.com/rest/api/appservice/app-service-plans/reboot-worker?view=rest-appservice-2024-04-01)
 
 
-## Deployment Slots Restarts
+## 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 
+## Swap operations 
 
 Swapping between slots will trigger restarts of the source and destination slots as described here: 
 
-[Set up staging environments - Azure App Service](https://docs.microsoft.com/en-us/azure/app-service/deploy-staging-slots)
+[Set up staging environments - Azure App Service](https://learn.microsoft.com/azure/app-service/deploy-staging-slots?tabs=portal)
 
 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 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.  
 
@@ -65,12 +65,12 @@ These two options will restart the specific instance of your application if it m
 
 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
+## 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](https://docs.microsoft.com/en-us/azure/app-service/monitor-instances-health-check). Additionally, if an instance becomes unavailable for a long time, HealthCheck will replace the unhealthy instances, up to a maximum of 3 per day.  
+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](https://learn.microsoft.com/azure/app-service/monitor-instances-health-check?tabs=dotnet). 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 
+## 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. 
 

_posts/2022-11-02-App-Service-on-Azure-Stack-Hub-2022-H1-Released.md

@@ -20,6 +20,7 @@ The 2022 H1 update to Azure App Service on Azure Stack Hub is now available. Thi
 - 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

_posts/2023-01-30-Azure-workbooks-to-help-run-App-Service.md

@@ -40,24 +40,24 @@ You can then access the workbook from the Resource Group you deployed to in the
 
 You’ll need to select some subscriptions from the Subscription parameter box to get going:
 
-![]({{ site.baseurl }}/media/2023/01/workbook_sub_select.png)
+![Screenshot showing the subscription selection for the Azure workbook]({{site.baseurl}}/media/2023/01/workbook_sub_select.png)
 
 Once you’ve done that the Workbook will load some summary data for all the ASP’s in the subscription:
 
-![]({{ site.baseurl }}/media/2023/01/workbook_asp_summary.png)
+![Screenshot showing sample summary data for App Service plans in the workbook]({{site.baseurl}}/media/2023/01/workbook_asp_summary.png)
 
 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:
 
-![]({{ site.baseurl }}/media/2023/01/workbook_asp_details.png)
+![Screenshot showing the additional insights that are available in the workbook]({{site.baseurl}}/media/2023/01/workbook_asp_details.png)
 
 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.
 
-![]({{ site.baseurl }}/media/2023/01/workbook_asp_metrics.png)
+![Screenshot showing additional charts that are provided in the workbook]({{site.baseurl}}/media/2023/01/workbook_asp_metrics.png)
 
 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.