A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://learn.microsoft.com/azure/app-service/configure-language-python below:

Configure Linux Python apps - Azure App Service

This article describes how Azure App Service runs Python apps, how you can migrate existing apps to Azure, and how you can customize the behavior of App Service when you need to. Python apps must be deployed with all the required pip modules.

The App Service deployment engine automatically activates a virtual environment and runs pip install -r requirements.txt for you when you deploy a Git repository, or when you deploy a zip package with build automation enabled.

This guide provides key concepts and instructions for Python developers who use a built-in Linux container in App Service. If you've never used Azure App Service, first follow the Python quickstart and Flask, Django, or FastAPI with PostgreSQL tutorial.

You can use either the Azure portal or the Azure CLI for configuration:

Note

Linux is the only operating system option for running Python apps in App Service. Python on Windows is no longer supported. You can however build your own custom Windows container image and run that in App Service. For more information, see use a custom Docker image.

Configure Python version

You can run an unsupported version of Python by building your own container image instead. For more information, see use a custom Docker image.

What happens to outdated runtimes in App Service?

Outdated runtimes are deprecated by the maintaining organization or found to have significant vulnerabilities. Accordingly, they're removed from the create and configure pages in the portal. When an outdated runtime is hidden from the portal, any app that's still using that runtime continues to run.

If you want to create an app with an outdated runtime version that's no longer shown on the portal, use the Azure CLI, ARM template, or Bicep. These deployment alternatives let you create deprecated runtimes that have been removed in the portal, but are still being supported.

If a runtime is fully removed from the App Service platform, your Azure subscription owner receives an email notice before the removal.

Customize build automation

Note

When Python applications are deployed with build automation, content will be deployed to and served from /tmp/<uid>, not under /home/site/wwwroot. This content directory can be access through the APP_PATH environment variable. Any additional files created at runtime should be written to a location under /home or using Bring Your Own Storage for persistence. More information on this behavior can be found here.

App Service's build system, called Oryx, performs the following steps when you deploy your app, if the app setting SCM_DO_BUILD_DURING_DEPLOYMENT is set to 1:

  1. Run a custom pre-build script, if that step is specified by the PRE_BUILD_COMMAND setting. (The script can itself run other Python and Node.js scripts, pip and npm commands, and Node-based tools like yarn, for example, yarn install and yarn build.)

  2. Run pip install -r requirements.txt. The requirements.txt file must be present in the project's root folder. Otherwise, the build process reports the error: "Could not find setup.py or requirements.txt; Not running pip install."

  3. If manage.py is found in the root of the repository (indicating a Django app), run manage.py collectstatic. However, if the DISABLE_COLLECTSTATIC setting is true, this step is skipped.

  4. Run custom post-build script, if that step is specified by the POST_BUILD_COMMAND setting. (Again, the script can run other Python and Node.js scripts, pip and npm commands, and Node-based tools.)

By default, the PRE_BUILD_COMMAND, POST_BUILD_COMMAND, and DISABLE_COLLECTSTATIC settings are empty.

For other settings that customize build automation, see Oryx configuration.

To access the build and deployment logs, see Access deployment logs.

For more information on how App Service runs and builds Python apps in Linux, see How Oryx detects and builds Python apps.

Note

The PRE_BUILD_SCRIPT_PATH and POST_BUILD_SCRIPT_PATH settings are identical to PRE_BUILD_COMMAND and POST_BUILD_COMMAND and are supported for legacy purposes.

A setting named SCM_DO_BUILD_DURING_DEPLOYMENT, if it contains true or 1, triggers an Oryx build that happens during deployment. The setting is true when you deploy by using Git, the Azure CLI command az webapp up, and Visual Studio Code.

Note

Always use relative paths in all pre- and post-build scripts because the build container in which Oryx runs is different from the runtime container in which the app runs. Never rely on the exact placement of your app project folder within the container (for example, that it's placed under site/wwwroot).

Generate requirements.txt from pyproject.toml

App Service does not directly support pyproject.toml at the moment. If you're using tools like Poetry or uv, the recommended approach is to generate a compatible requirements.txt before deployment in your project's root:

Using Poetry

Using Poetry with the export plugin:


poetry export -f requirements.txt --output requirements.txt --without-hashes
Using uv

Using uv:


uv export --format requirements-txt --no-hashes --output-file requirements.txt
Migrate existing applications to Azure

Existing web applications can be redeployed to Azure as follows:

  1. Source repository: Maintain your source code in a suitable repository like GitHub, which enables you to set up continuous deployment later in this process.

  2. Database: If your app depends on a database, create the necessary resources on Azure as well.

  3. App service resources: Create a resource group, App Service plan, and App Service web app to host your application. You can do this easily by running the Azure CLI command az webapp up. Or, you can create and deploy resources as shown in the Flask, Django, or FastAPI with PostgreSQL tutorial. Replace the names of the resource group, App Service plan, and web app to be more suitable for your application.

  4. Environment variables: If your application requires any environment variables, create equivalent App Service application settings. These App Service settings appear to your code as environment variables, as described in Access environment variables.

  5. App startup: Review the section Container startup process later in this article to understand how App Service attempts to run your app. App Service uses the Gunicorn web server by default, which must be able to find your app object or wsgi.py folder. If you need to, you can Customize the startup command.

  6. Continuous deployment: Set up continuous deployment from GitHub Actions, Bitbucket, or Azure Repos as described in the article Continuous deployment to Azure App Service. Or, set up continuous deployment from Local Git as described in the article Local Git deployment to Azure App Service.

  7. Custom actions: To perform actions within the App Service container that hosts your app, such as Django database migrations, you can connect to the container through SSH. For an example of running Django database migrations, see Tutorial: Deploy a Django web app with PostgreSQL - generate database schema.

With these steps completed, you should be able to commit changes to your source repository and have those updates automatically deployed to App Service.

Production settings for Django apps

For a production environment like Azure App Service, Django apps should follow Django's Deployment checklist.

The following table describes the production settings that are relevant to Azure. These settings are defined in the app's setting.py file.

Django setting Instructions for Azure SECRET_KEY Store the value in an App Service setting as described on Access app settings as environment variables. You can alternatively store the value as a secret in Azure Key Vault. DEBUG Create a DEBUG setting on App Service with the value 0 (false), then load the value as an environment variable. In your development environment, create a DEBUG environment variable with the value 1 (true). ALLOWED_HOSTS In production, Django requires that you include the app's URL in the ALLOWED_HOSTS array of settings.py. You can retrieve this URL at runtime with the code os.environ['WEBSITE_HOSTNAME']. App Service automatically sets the WEBSITE_HOSTNAME environment variable to the app's URL. DATABASES Define settings in App Service for the database connection and load them as environment variables to populate the DATABASES dictionary. You can alternatively store the values (especially the username and password) as Azure Key Vault secrets. Serve static files for Django apps

If your Django web app includes static front-end files, first follow the instructions on managing static files in the Django documentation.

For App Service, you then make the following modifications:

  1. Consider using environment variables (for local development) and App Settings (when deploying to the cloud) to dynamically set the Django STATIC_URL and STATIC_ROOT variables. For example:

    STATIC_URL = os.environ.get("DJANGO_STATIC_URL", "/static/")
STATIC_ROOT = os.environ.get("DJANGO_STATIC_ROOT", "./static/")

    DJANGO_STATIC_URL and DJANGO_STATIC_ROOT can be changed as necessary for your local and cloud environments. For example, if the build process for your static files places them in a folder named django-static, then you can set DJANGO_STATIC_URL to /django-static/ to avoid using the default.

  2. If you have a pre-build script that generates static files in a different folder, include that folder in the Django STATICFILES_DIRS variable so that Django's collectstatic process finds them. For example, if you run yarn build in your front-end folder, and yarn generates a build/static folder containing static files, then include that folder as follows:

    FRONTEND_DIR = "path-to-frontend-folder" 
STATICFILES_DIRS = [os.path.join(FRONTEND_DIR, 'build', 'static')]

    Here, FRONTEND_DIR is used to build a path to where a build tool like yarn is run. You can again use an environment variable and App Setting as desired.

  3. Add whitenoise to your requirements.txt file. WhiteNoise (whitenoise.evans.io) is a Python package that makes it simple for a production Django app to serve its own static files. WhiteNoise specifically serves those files that are found in the folder specified by the Django STATIC_ROOT variable.

  4. In your settings.py file, add the following line for WhiteNoise:

    STATICFILES_STORAGE = ('whitenoise.storage.CompressedManifestStaticFilesStorage')

  5. Also modify the MIDDLEWARE and INSTALLED_APPS lists to include WhiteNoise:

    MIDDLEWARE = [                                                                   
    'django.middleware.security.SecurityMiddleware',
    # Add whitenoise middleware after the security middleware                             
    'whitenoise.middleware.WhiteNoiseMiddleware',
    # Other values follow
]

INSTALLED_APPS = [
    "whitenoise.runserver_nostatic",
    # Other values follow
]
Serve static files for Flask apps

If your Flask web app includes static front-end files, first follow the instructions on managing static files in the Flask documentation. For an example of serving static files in a Flask application, see the sample Flask application on GitHub.

To serve static files directly from a route on your application, you can use the send_from_directory method:

from flask import send_from_directory

@app.route('/reports/<path:path>')
def send_report(path):
    return send_from_directory('reports', path)
Container characteristics

When deployed to App Service, Python apps run within a Linux Docker container that's defined in the App Service Python GitHub repository. You can find the image configurations inside the version-specific directories.

This container has the following characteristics:

Container startup process

During startup, the App Service on Linux container runs the following steps:

  1. Use a custom startup command, if one is provided.
  2. Check for the existence of a Django app, and launch Gunicorn for it if one is detected.
  3. Check for the existence of a Flask app, and launch Gunicorn for it if one is detected.
  4. If no other app is found, start a default app that's built into the container.

The following sections provide extra details for each option.

Django app

For Django apps, App Service looks for a file named wsgi.py within your app code, and then runs Gunicorn using the following command:

# <module> is the name of the folder that contains wsgi.py
gunicorn --bind=0.0.0.0 --timeout 600 <module>.wsgi

If you want more specific control over the startup command, use a custom startup command, replace <module> with the name of folder that contains wsgi.py, and add a --chdir argument if that module isn't in the project root. For example, if your wsgi.py is located under knboard/backend/config from your project root, use the arguments --chdir knboard/backend config.wsgi.

To enable production logging, add the --access-logfile and --error-logfile parameters as shown in the examples for custom startup commands.

Flask app

For Flask, App Service looks for a file named application.py or app.py and starts Gunicorn as follows:

# If application.py
gunicorn --bind=0.0.0.0 --timeout 600 application:app

# If app.py
gunicorn --bind=0.0.0.0 --timeout 600 app:app

If your main app module is contained in a different file, use a different name for the app object. If you want to provide other arguments to Gunicorn, use a custom startup command.

Default behavior

If the App Service doesn't find a custom command, a Django app, or a Flask app, then it runs a default read-only app, located in the opt/defaultsite folder and shown in the following image.

If you deployed code and still see the default app, see Troubleshooting - App doesn't appear.

Customize startup command

You can control the container's startup behavior by providing either a custom startup command or multiple commands in a startup command file. A startup command file can use whatever name you choose, such as startup.sh, startup.cmd, startup.txt, and so on.

All commands must use relative paths to the project root folder.

To specify a startup command or command file:

App Service ignores any errors that occur when processing a custom startup command or file, then continues its startup process by looking for Django and Flask apps. If you don't see the behavior you expect, check that your startup command or file is error-free, and that a startup command file is deployed to App Service along with your app code. You can also check the diagnostic logs for more information. Also check the app's Diagnose and solve problems page on the Azure portal.

Example startup commands Access app settings as environment variables

App settings are values stored in the cloud specifically for your app, as described in Configure app settings. These settings are available to your app code as environment variables and accessed using the standard os.environ pattern.

For example, if you've created an app setting called DATABASE_SERVER, the following code retrieves that setting's value:

db_server = os.environ['DATABASE_SERVER']
Detect HTTPS session

In App Service, TLS/SSL termination happens at the network load balancers, so all HTTPS requests reach your app as unencrypted HTTP requests. If your app logic needs to check if the user requests are encrypted or not, inspect the X-Forwarded-Proto header.

if 'X-Forwarded-Proto' in request.headers and request.headers['X-Forwarded-Proto'] == 'https':
# Do something when HTTPS is used

Popular web frameworks let you access the X-Forwarded-* information in your standard app pattern. For example, in Django you can use the SECURE_PROXY_SSL_HEADER to tell Django to use the X-Forwarded-Proto header.

Access diagnostic logs

You can access the console logs generated from inside the container.

To turn on container logging, run the following command:

az webapp log config --name <app-name> --resource-group <resource-group-name> --docker-container-logging filesystem

Replace <app-name> and <resource-group-name> with names that are appropriate for your web app.

After you turn on container logging, run the following command to see the log stream:

az webapp log tail --name <app-name> --resource-group <resource-group-name>

If console logs don't appear immediately, check again in 30 seconds.

To stop log streaming at any time, select Ctrl+C.

To access logs through the Azure portal, select Monitoring > Log stream on the left side menu for your app.

Access deployment logs

When you deploy your code, App Service performs the build process described earlier in the section Customize build automation. Because the build runs in its own container, build logs are stored separately from the app's diagnostic logs.

Use the following steps to access the deployment logs:

  1. On the Azure portal for your web app, select Deployment > Deployment Center on the left menu.
  2. On the Logs tab, select the Commit ID for the most recent commit.
  3. On the Log details page that appears, select the Show Logs link that appears next to "Running oryx build...".

Build issues such as incorrect dependencies in requirements.txt and errors in pre- or post-build scripts will appear in these logs. Errors also appear if your requirements file isn't named requirements.txt or doesn't appear in the root folder of your project.

Open SSH session in browser

To open a direct SSH session with your container, your app should be running.

Use the az webapp ssh command.

If you're not yet authenticated, you're required to authenticate with your Azure subscription to connect. Once authenticated, you see an in-browser shell, where you can run commands inside your container.

Note

Any changes that you make outside the /home directory are stored in the container itself and don't persist beyond an app restart.

To open a remote SSH session from your local machine, see Open SSH session from remote shell.

When you're successfully connected to the SSH session, you should see the message "SSH CONNECTION ESTABLISHED" at the bottom of the window. If you see errors such as "SSH_CONNECTION_CLOSED" or a message that the container is restarting, an error might be preventing the app container from starting. See Troubleshooting for steps to investigate possible issues.

URL rewrites

When deploying Python applications on Azure App Service for Linux, you might need to handle URL rewrites within your application. This is particularly useful for ensuring specific URL patterns are redirected to the correct endpoints without relying on external web server configurations. For Flask applications, URL processors and custom middleware can be used to achieve this. In Django applications, the robust URL dispatcher allows for efficient management of URL rewrites.

Troubleshooting

In general, the first step in troubleshooting is to use App Service diagnostics:

  1. In the Azure portal for your web app, select Diagnose and solve problems from the left menu.
  2. Select Availability and Performance.
  3. Examine the information in the Application Logs, Container Crash, and Container Issues options, where the most common issues will appear.

Next, examine both the deployment logs and the app logs for any error messages. These logs often identify specific issues that can prevent app deployment or app startup. For example, the build can fail if your requirements.txt file has the wrong filename or isn't present in your project root folder.

The following sections provide guidance for specific issues.

App doesn't appear Could not find setup.py or requirements.txt ModuleNotFoundError when app starts

If you see an error like ModuleNotFoundError: No module named 'example', then Python couldn't find one or more of your modules when the application started. This error most often occurs if you deploy your virtual environment with your code. Virtual environments aren't portable, so a virtual environment shouldn't be deployed with your application code. Instead, let Oryx create a virtual environment and install your packages on the web app by creating an app setting, SCM_DO_BUILD_DURING_DEPLOYMENT, and setting it to 1. This setting will force Oryx to install your packages whenever you deploy to App Service. For more information, see this article on virtual environment portability.

Database is locked

When attempting to run database migrations with a Django app, you might see "sqlite3. OperationalError: database is locked." The error indicates that your application is using a SQLite database, for which Django is configured by default, rather than using a cloud database such as Azure Database for PostgreSQL.

Check the DATABASES variable in the app's settings.py file to ensure that your app is using a cloud database instead of SQLite.

If you're encountering this error with the sample in Tutorial: Deploy a Django web app with PostgreSQL, check that you completed the steps in Verify connection settings.

Other issues

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4