Exercise 4: Configuring Applications in App Service

For Linux apps and custom containers, App Service uses the --env flag to pass the application settings as environment variables to that container. In this exercise, you will check these settings out:

1. Within the Azure portal, find and open your App Service app and navigate to the Configuration blade once more. Here, you will see the existing application setting previously mentioned.
2. Click on the Advanced edit button above the settings. This will bring up a JSON representation of the current application settings. This is where you can make additions or amendments in bulk, rather than making changes one by one.
3. Add two new settings (don’t forget to add a comma after the last one, but before the closing square bracket), one named ORIGINAL_SLOT with the value of Production, and the other named CURRENT_SLOT with the same value of Production, which has the slotSetting value set to true:

     {

       "name": "ORIGINAL_SLOT",

       "value": "Production",

       "slotSetting": false

     },

     {

       "name": "CURRENT_SLOT",

       "value": "Production",

       "slotSetting": true

     }

   Don’t worry about what slotSetting is for now; we’ll discuss this soon.

4. Click OK and then Save at the top of the page, followed by Continue when prompted.
5. Check out the General settings tab and then the Path mappings tab to see what configuration settings are available.

   If you were in this same area with a Windows App Service app, you would also have a Default documents tab, which would allow you to define a prioritized list of documents to display when navigating to the root URL for the website. The first file in the list that matches is used to display content to the user.

6. Browse to the URL of the web app to confirm nothing has changed. The app now has new app settings, but you’re not doing anything with them yet.
7. From the previously downloaded repository for this book, open the 02-appsettings-logging folder and then open the Pages\Index.cshtml file:

Figure 2.16: The Index.cshtml file within VS Code

You can see within this file that this app outputs the values for configuration settings with the names ORIGINAL_SLOT and CURRENT_SLOT:

    <h3>Original slot: @Configuration["ORIGINAL_SLOT"].</h3>
    <h3>Current slot: @Configuration["CURRENT_SLOT"].</h3>

8. Open a terminal session from the 02-appsettings-logging directory and run the app with the following command:

   dotnet run

9. Open a browser window and navigate to the URL of the local app: http: //localhost: 5000.

   You’ll notice that only Original slot: . and Current slot: . are displayed. This is because the settings don’t exist on the local machine yet.

10. Open the appsettings.json file and add the relevant settings and whatever values you’d like for them, as per the following example:

      "ORIGINAL_SLOT": "My computer",

      "CURRENT_SLOT": "Also my computer"

11. Save the file and run the app again with the following command:

    dotnet run

If you browse to the app again, you’ll see the values being displayed. So, what you’ve just done is configure some default settings that our web app can use. It was mentioned previously that App Service app settings will override the values defined in an appsettings.json file. Deploy this app to App Service and see it in action.

1. Publish your files, ready for deployment, by running the following command:

   dotnet publish -c Release -o out

2. If you have the Azure App Service VS Code extension installed (listed in the Technical Requirements section of this chapter), right-click on the newly created out folder and select Deploy to Web App.
3. When prompted, select your App Service and confirm by clicking on the Deploy button in the pop-up window that appears:

Figure 2.17: App Service deployment confirmation window

4. Once deployment has completed, browse to your App Service and you’ll see that the settings configured earlier have indeed taken priority over those configured in the appsettings.json file and are now being displayed.

One final configuration you should be aware of is cross-origin resource sharing (CORS), which comes supported for RESTful APIs with App Service. At a high level, CORS-supported browsers prevent web pages from making requests for restricted resources to a different domain from that which served the web page. By default, cross-domain requests (AJAX requests, for example) are forbidden by something called the same-origin policy, which prevents malicious code from accessing sensitive data on another site. There may be times when you want sites from other domains to access your app (such as if your App Service hosts an API). In this case, you can configure CORS to allow requests from one or more (or all) domains.

CORS can be configured from the CORS blade under the API section of your App Service.

You will explore the App Configuration feature in more detail in Chapter 8, Implementing Secure Azure Solutions. For now, you can move on to the topic of logging.

Logging

There are several types of logging available within the App Service. Some of them are Windows-specific while others are available for both Windows and Linux:

Windows Only

• Detailed error logging: When an application HTTP error code of 400 or greater occurs, App Service can store the .htm error pages, which otherwise would be sent to the client browser, within the App Service file system.
• Failed request tracing: Detailed tracing information on failed requests (including a trace of the IIS components used to process the request) is stored within the App Service file system.
• Web server logging: Raw HTTP request data is stored in the W3C extended log file format within the App Service file system or Azure Storage blobs.

Windows and Linux

• Application logging: Log messages that are generated by either the web framework being used or your application code directly (you’ll see this shortly) are stored within either the App Service filesystem (this is the only option available with Linux apps) or Azure Storage blobs (only available in Windows apps).
• Deployment logging: Upon publishing content to an app, deployment logging occurs automatically with no configurable settings, which helps determine reasons for a deployment failing. These logs are stored within the App Service filesystem.

For logs stored within the App Service filesystem, you can access them via their direct URLs. For Windows apps, the URL for the diagnostic dump is https: //<app-service>.scm .azurewebsites. net/api/dump. For Linux/container apps, the URL is https: //<app-service>.scm.azurewebsites. net/api/logs/docker/zip. Within the portal, you can use Advanced Tools to access further information and the links just mentioned.