Document Details

In PowerShell:

In PowerShell:

In PowerShell:

::: zone-end > [!NOTE] > You can also [configure your own persistent storage](configure-connect-to-azure-storage.md). ## Detect HTTPS session App Service terminates TLS at the front ends. That means that TLS requests never get to your app. You don't need to, and shouldn't, implement any support for TLS into your app. The front ends are located inside Azure data centers. If you use TLS with your app, your traffic across the Internet is always safely encrypted. ::: zone pivot="container-windows" ## Customize ASP.NET machine key injection During the container start, automatically generated keys are injected into the container as the machine keys for ASP.NET cryptographic routines. You can [find these keys in your container](#connect-to-the-container) by looking for the following environment variables: `MACHINEKEY_Decryption`, `MACHINEKEY_DecryptionKey`, `MACHINEKEY_ValidationKey`, `MACHINEKEY_Validation`. The new keys at each restart might reset ASP.NET forms authentication and view state, if your app depends on them. To prevent the automatic regeneration of keys, [set them manually as App Service app settings](#configure-environment-variables). ## Connect to the container To connect to your Windows container directly for diagnostic tasks, navigate to `https://<app-name>.scm.azurewebsites.net/` and choose the SSH option. This option establishes direct SSH session in which you can run commands inside your container. - It functions separately from the graphical browser above it, which only shows the files in your [shared storage](#use-persistent-shared-storage). - In a scaled-out app, the SSH session is connected to one of the container instances. You can select a different instance from the **Instance** dropdown list in the top Kudu menu. - Except for changes in the shared storage, any change you make to the container from within the SSH session **doesn't** persist when your app is restarted. Such changes aren't part of the Docker image. To persist your changes, such as registry settings and software installation, make them part of the Dockerfile. ## Access diagnostic logs App Service logs actions by the Docker host and activities from within the container. Logs from the Docker host (platform logs) are enabled by default. You need to manually enable application logs or web server logs from within the container. For more information, see [Enable application logging](troubleshoot-diagnostic-logs.md#enable-application-logging-linuxcontainer) and [Enable web server logging](troubleshoot-diagnostic-logs.md#enable-web-server-logging). There are several ways to access Docker logs: - [The Azure portal](#in-the-azure-portal) - [Kudu](#from-kudu) - [Kudu API](#with-the-kudu-api) - [Azure monitor](troubleshoot-diagnostic-logs.md#send-logs-to-azure-monitor) ### In the Azure portal Docker logs are displayed in the Azure portal, in the **Container Settings** page of your app. The logs are truncated. To download all the logs, select **Download**. ### From Kudu To see the individual log files, navigate to `https://<app-name>.scm.azurewebsites.net/DebugConsole` and select the **LogFiles** folder. To download the entire **LogFiles** directory, select the **Download** icon to the left of the directory name. You can also access this folder using an FTP client. In the SSH terminal, you can't access the *C:\home\LogFiles* folder by default because persistent shared storage isn't enabled. To enable this behavior in the console terminal, [enable persistent shared storage](#use-persistent-shared-storage). If you try to download the Docker log that is currently in use by using an FTP client, you might get an error because of a file lock. ### With the Kudu API Navigate directly to `https://<app-name>.scm.azurewebsites.net/api/logs/docker` to see metadata for the Docker logs. You might see more than one log file listed. The `href` property lets you download the log file directly. To download all the logs together in one ZIP file, access `https://<app-name>.scm.azurewebsites.net/api/logs/docker/zip`. ## Customize container memory By default, all Windows Containers deployed in Azure App Service have a memory limit configured. The following table lists the default settings per App Service Plan SKU. | App Service Plan SKU | Default memory limit per app in MB | |:-----|:-----| | P1v3 | 1024 | | P1Mv3 | 1024 | | P2v3 | 1536 | | P2Mv3 | 1536 | | P3v3 | 2048 | | P3Mv3 | 2048 | | P4Mv3 | 2560 | | P5Mv3 | 3072 | You can change this value by providing the `WEBSITE_MEMORY_LIMIT_MB` app setting by using the [Cloud Shell](https://shell.azure.com). In Bash:

In PowerShell:

In PowerShell:

In PowerShell:

Replace the following values: - *\<principal-id>* with the service principal ID from the `az webapp identity assign` command - *\<registry-resource-id>* with the ID of your container registry from the `az acr show` command For more information about these permissions, see [What is Azure role-based access control](../role-based-access-control/overview.md). 1. Configure your app to use the managed identity to pull from Azure Container Registry.

Replace the following values: - *\<app-name>* with the name of your web app. > [!TIP] > If you use PowerShell console to run the commands, escape the strings in the `--generic-configurations` argument in this step and the next step. For example: `--generic-configurations '{\"acrUseManagedIdentityCreds\": true'` 1. (Optional) If your app uses a [user-assigned managed identity](overview-managed-identity.md#add-a-user-assigned-identity), make sure the identity is configured on the web app and then set the `acrUserManagedIdentityID` property to specify its client ID:

In PowerShell:

When your app runs, the App Service app settings are injected into the process as environment variables automatically. You can verify container environment variables with the URL `https://<app-name>.scm.azurewebsites.net/Env`. If your app uses images from a private registry or from Docker Hub, credentials for accessing the repository are saved in environment variables: `DOCKER_REGISTRY_SERVER_URL`, `DOCKER_REGISTRY_SERVER_USERNAME`, and `DOCKER_REGISTRY_SERVER_PASSWORD`. Because of security risks, none of these reserved variable names are exposed to the application. ::: zone pivot="container-windows" For IIS or .NET Framework (4.0 or later) based containers, credentials are injected into `System.ConfigurationManager` as .NET app settings and connection strings automatically by App Service. For all other language or framework, they're provided as environment variables for the process, with one of the following prefixes: - `APPSETTING_` - `SQLCONTR_` - `MYSQLCONTR_` - `SQLAZURECOSTR_` - `POSTGRESQLCONTR_` - `CUSTOMCONNSTR_` ::: zone-end ::: zone pivot="container-linux" This method works both for single-container apps or multi-container apps, where the environment variables are specified in the *docker-compose.yml* file. ::: zone-end ## Use persistent shared storage ::: zone pivot="container-windows" You can use the *C:\home* directory in your custom container file system to persist files across restarts and share them across instances. The *C:\home* directory is provided to enable your custom container to access persistent storage. When persistent storage is disabled, writes to the *C:\home* directory aren't persisted across app restarts or across multiple instances. When persistent storage is enabled, all writes to the *C:\home* directory persist. All instances of a scaled-out app can access them. Any existing files already present on the persistent storage when the container starts overwrite any contents in the *C:\home* directory of the container. The only exception is the *C:\home\LogFiles* directory. This directory stores the container and application logs. This folder always persists upon app restarts if [application logging is enabled](troubleshoot-diagnostic-logs.md?#enable-application-logging-windows) with the **File System** option, whether or not persistent storage is enabled. In other words, enabling or disabling the persistent storage doesn't affect the application logging behavior. By default, persistent storage is *enabled* on Windows custom containers. To disable it, set the `WEBSITES_ENABLE_APP_SERVICE_STORAGE` app setting value to `false` by using the [Cloud Shell](https://shell.azure.com). In Bash:

The value is defined in MB and must be less and equal to the total physical memory of the host. For example, in an App Service plan with 8 GB of RAM, the cumulative total of `WEBSITE_MEMORY_LIMIT_MB` for all the apps must not exceed 8 GB. For more information on how much memory is available, see the **Premium v3 service plan** section of [App Service pricing](https://azure.microsoft.com/pricing/details/app-service/windows/). ## Customize the number of compute cores By default, a Windows container runs with all available cores for your chosen pricing tier. You might want to reduce the number of cores that your staging slot uses. To reduce the number of cores used by a container, set the `WEBSITE_CPU_CORES_LIMIT` app setting to the preferred number of cores. You can set it by using the [Cloud Shell](https://shell.azure.com). In Bash:

> [!TIP] > Updating the app setting triggers automatic restart, which causes minimal downtime. For a production app, consider swapping it into a staging slot, change the app setting in the staging slot, and then swap it back into production. To verify your adjusted number, open an SSH session from the Azure portal or use the Kudu portal (`https://<app-name>.scm.azurewebsites.net/webssh/host`). Enter the following commands using PowerShell. Each command returns a number.