Managed Identity support for WordPress on App Service
WordPress on App Service now supports Managed Identity. This means your WordPress site can securely access other Azure resources, like Azure Database for MySQL Flexible Server and Azure Communication Service Email, without the hassle of managing connection strings and secrets.Using TensorFlow on Azure Web App
TOC Introduction to OpenAI System Architecture Architecture Focus of This Tutorial Setup Azure Resources File and Directory Structure Bicep Template Running Locally Training Models and Training Data Predicting with the Model Publishing the Project to Azure Code Commit to Azure DevOps Publish to Azure Web App via Pipeline Running on Azure Web App Training the Model Using the Model for Prediction Troubleshooting docker.log freeze after deployment Others Conclusion References 1. Introduction to OpenAI TensorFlow is an open-source machine learning framework developed by Google. It provides tools for building and deploying machine learning models, with a focus on flexibility and scalability. TensorFlow supports deep learning, classical machine learning, and neural network models, enabling tasks like image recognition, natural language processing, and time series forecasting. At its core, TensorFlow uses computational graphs to model mathematical operations, allowing efficient computation on CPUs, GPUs, and TPUs. It features a high-level API, Keras, for easy model building, as well as lower-level APIs for advanced customization. TensorFlow also supports distributed training for large-scale datasets and diverse deployment options, including cloud services, mobile devices, and edge computing. TensorFlow’s ecosystem includes TensorFlow Hub (pre-trained models), TensorFlow Lite (for mobile and IoT), and TensorFlow.js (for JavaScript applications). Its integration with visualization tools like TensorBoard simplifies debugging and performance monitoring. TensorFlow excels in production environments, offering features like TensorFlow Extended (TFX) for end-to-end ML pipelines. With its versatile capabilities and large community, TensorFlow is widely used in industries like healthcare, finance, and technology, making it one of the most powerful tools for modern machine learning development. 2. System Architecture Architecture Development Environment OS: macOS Version: Sonoma 14.1.1 Python Version: 3.9.20 Azure Resources App Service Plan: SKU - Premium Plan 0 V3 App Service: Platform - Linux (Python 3.9, Version 3.9.19) Storage Account: SKU - General Purpose V2 File Share: No backup plan Focus of This Tutorial This tutorial walks you through the following stages: Setting up Azure resources Running the project locally Publishing the project to Azure Running the application on Azure Troubleshooting common issues Each of the mentioned aspects has numerous corresponding tools and solutions. The relevant information for this session is listed in the table below. Local OS Windows Linux Mac V How to setup Azure resources Portal (i.e., REST api) ARM Bicep Terraform V How to deploy project to Azure VSCode CLI Azure DevOps GitHub Action V 3. Setup Azure Resources File and Directory Structure Please open a terminal and enter the following commands: git clone https://github.com/theringe/azure-appservice-ai.git cd azure-appservice-ai bash ./tensorflow/tools/add-venv.sh If you are using a Windows platform, use the following alternative PowerShell commands instead: git clone https://github.com/theringe/azure-appservice-ai.git cd azure-appservice-ai .\tensorflow\tools\add-venv.cmd After completing the execution, you should see the following directory structure: File and Path Purpose tensorflow/tools/add-venv.* The script executed in the previous step (cmd for Windows, sh for Linux/Mac) to create all Python virtual environments required for this tutorial. .venv/tensorflow-webjob/ A virtual environment specifically used for training models (i.e., tokenize text, construct a neuron network for training). tensorflow/webjob/requirements.txt The list of packages (with exact versions) required for the tensorflow-webjob virtual environment. .venv/tensorflow/ A virtual environment specifically used for the Flask application, enabling API endpoint access for querying predictions (i.e., MBTI). tensorflow/requirements.txt The list of packages (with exact versions) required for the tensorflow virtual environment. tensorflow/ The main folder for this tutorial. tensorflow/tools/bicep-template.bicep The Bicep template to setup all the Azure resources related to this tutorial, including an App Service Plan, a Web App, and a Storage Account. tensorflow/tools/create-folder.* A script to create all directories required for this tutorial in the File Share, including train, model, and test. tensorflow/tools/download-sample-training-set.* A script to download a sample training set from MBTI text classifer trained on the Kaggle MBTI dataset, containing MBTI and post data from social media platforms, into the train directory of the File Share. tensorflow/webjob/train_mbti_model.py A script for tokenizing the posts from each record, training an LSTM-based model for MBTI classification, and saves the embedding vectors in the model directory of the File Share. tensorflow/App_Data/jobs/triggered/train-mbti-model/train_mbti_model.sh A shell script for Azure App Service web jobs. It activates the tensorflow-webjob virtual environment and starts the train_mbti_model.py script. tensorflow/api/app.py Code for the Flask application, including routes, port configuration, input parsing, vectors loading, predictions, and output generation. tensorflow/start.sh A script executed after deployment (as specified in the Bicep template startup command I will introduce it later). It sets up the virtual environment and starts the Flask application to handle web requests. tensorflow/pipeline.yml A process document for an Azure DevOps pipeline, detailing the steps to deploy code to an Azure Web App. Bicep Template We need to create the following resources or services: Manual Creation Required Resource/Service App Service Plan No Resource (plan) App Service Yes Resource (app) Storage Account Yes Resource (storageAccount) File Share Yes Service Let’s take a look at the tensorflow/tools/bicep-template.bicep file. Refer to the configuration section for all the resources. Since most of the configuration values don’t require changes, I’ve placed them in the variables section of the ARM template rather than the parameters section. This helps keep the configuration simpler. However, I’d still like to briefly explain some of the more critical settings. As you can see, I’ve adopted a camelCase naming convention, which combines the [Resource Type] with [Setting Name and Hierarchy]. This makes it easier to understand where each setting will be used. The configurations in the diagram are sorted by resource name, but the following list is categorized by functionality for better clarity. Configuration Name Value Purpose storageAccountFileShareName data-and-model [Purpose 1: Link File Share to Web App] Use this fixed name for File Share storageAccountFileShareShareQuota 5120 [Purpose 1: Link File Share to Web App] The value is in GB storageAccountFileShareEnabledProtocols SMB [Purpose 1: Link File Share to Web App] appSiteConfigAzureStorageAccountsType AzureFiles [Purpose 1: Link File Share to Web App] appSiteConfigAzureStorageAccountsProtocol Smb [Purpose 1: Link File Share to Web App] planKind linux [Purpose 2: Specify platform and stack runtime] Select Linux (default if Python stack is chosen) planSkuTier Premium0V3 [Purpose 2: Specify platform and stack runtime] Choose at least Premium Plan to ensure enough memory for your AI workloads planSkuName P0v3 [Purpose 2: Specify platform and stack runtime] Same as above appKind app,linux [Purpose 2: Specify platform and stack runtime] Same as above appSiteConfigLinuxFxVersion PYTHON|3.9 [Purpose 2: Specify platform and stack runtime] Select Python 3.9 to avoid dependency issues appSiteConfigAppSettingsWEBSITES_CONTAINER_START_TIME_LIMIT 1800 [Purpose 3: Deploying] The value is in seconds, ensuring the Startup Command can continue execution beyond the default timeout of 230 seconds. This tutorial’s Startup Command typically takes around 1200 seconds, so setting it to 1800 seconds (i.e., it is the max value) provides a safety margin and accommodates future project expansion (e.g., adding more packages) appSiteConfigAppCommandLine [ -f /home/site/wwwroot/start.sh ] && bash /home/site/wwwroot/start.sh || GUNICORN_CMD_ARGS=\"--timeout 600 --access-logfile '-' --error-logfile '-' -c /opt/startup/gunicorn.conf.py --chdir=/opt/defaultsite\" gunicorn application:app [Purpose 3: Deploying] This is the Startup Command, which can be break down into 3 parts: First (-f /home/site/wwwroot/start.sh): Checks whether start.sh exists. This is used to determine whether the app is in its initial state (just created) or has already been deployed. Second (bash /home/site/wwwroot/start.sh): If the file exists, it means the app has already been deployed. The start.sh script will be executed, which installs the necessary packages and starts the Flask application. Third (GUNICORN_CMD_ARGS=\"--timeout 600 --access-logfile '-' --error-logfile '-' -c /opt/startup/gunicorn.conf.py --chdir=/opt/defaultsite\" gunicorn application:app): If the file does not exist, the command falls back to the default HTTP server (gunicorn) to start the web app. Since the command is enclosed in double quotes within the ARM template, during actual execution, replace \" with " appSiteConfigAppSettingsSCM_DO_BUILD_DURING_DEPLOYMENT false [Purpose 3: Deploying] Since we have already defined the handling for different virtual environments in start.sh, we do not need to initiate the default build process of the Web App appSiteConfigAppSettingsWEBSITES_ENABLE_APP_SERVICE_STORAGE true [Purpose 4: Webjobs] This setting is required to enable the App Service storage feature, which is necessary for using web jobs (e.g., for model training) storageAccountPropertiesAllowSharedKeyAccess true [Purpose 5: Troubleshooting] This setting is enabled by default. The reason for highlighting it is that certain enterprise IT policies may enforce changes to this configuration after a period, potentially causing a series of issues. For more details, please refer to the Troubleshooting section below. Return to terminal and execute the following commands (their purpose has been described earlier). # Please change <ResourceGroupName> to your prefer name, for example: azure-appservice-ai # Please change <RegionName> to your prefer region, for example: eastus2 # Please change <ResourcesPrefixName> to your prefer naming pattern, for example: tensorflow-bicep (it will create tensorflow-bicep-asp as App Service Plan, tensorflow-bicep-app for web app, and tensorflowbicepsa for Storage Account) az group create --name <ResourceGroupName> --location <RegionName> az deployment group create --resource-group <ResourceGroupName> --template-file ./tensorflow/tools/bicep-template.bicep --parameters resourcePrefix=<ResourcesPrefixName> If you are using a Windows platform, use the following alternative PowerShell commands instead: # Please change <ResourceGroupName> to your prefer name, for example: azure-appservice-ai # Please change <RegionName> to your prefer region, for example: eastus2 # Please change <ResourcesPrefixName> to your prefer naming pattern, for example: tensorflow-bicep (it will create tensorflow-bicep-asp as App Service Plan, tensorflow-bicep-app for web app, and tensorflowbicepsa for Storage Account) az group create --name <ResourceGroupName> --location <RegionName> az deployment group create --resource-group <ResourceGroupName> --template-file .\tensorflow\tools\bicep-template.bicep --parameters resourcePrefix=<ResourcesPrefixName> After execution, please copy the output section containing 3 key-value pairs from the result like this. Return to terminal and execute the following commands: # Please setup 3 variables you've got from the previous step OUTPUT_STORAGE_NAME="<outputStorageName>" OUTPUT_STORAGE_KEY="<outputStorageKey>" OUTPUT_SHARE_NAME="<outputShareName>" # URL encode the storage key ENCODED_OUTPUT_STORAGE_KEY=$(python3 -c " import urllib.parse key = '''$OUTPUT_STORAGE_KEY''' encoded_key = urllib.parse.quote(key, safe='') # No safe characters, encode everything print(encoded_key) ") # Mount open smb://$OUTPUT_STORAGE_NAME:$ENCODED_OUTPUT_STORAGE_KEY@$OUTPUT_STORAGE_NAME.file.core.windows.net/$OUTPUT_SHARE_NAME Or you could simply go to Azure Portal, navigate to the File Share you just created, and refer to the diagram below to copy the required command. You can choose Linux or Windows if you are using such OS in your dev environment. After executing the command, the network drive will be successfully mounted. 4. Running Locally Training Models and Training Data Return to terminal and execute the following commands (their purpose has been described earlier). source .venv/tensorflow-webjob/bin/activate bash ./tensorflow/tools/create-folder.sh bash ./tensorflow/tools/download-sample-training-set.sh python ./tensorflow/webjob/train_mbti_model.py If you are using a Windows platform, use the following alternative PowerShell commands instead: .\.venv\tensorflow-webjob\Scripts\Activate.ps1 .\tensorflow\tools\create-folder.cmd .\tensorflow\tools\download-sample-training-set.cmd python .\tensorflow\webjob\train_mbti_model.py After execution, the File Share will now include the following directories and files. Let’s take a brief detour to examine the structure of the training data downloaded from the GitHub. The dataset used in this project focuses on MBTI (Myers-Briggs Type Indicator) personality types. Each record in the dataset contains a user’s MBTI type and a collection of their social media posts, separated by |||. This tutorial repurposes the dataset to classify personality types based on textual data. This image represents the raw data, where each line includes an MBTI type and its associated text. For training, the posts are tokenized and transformed into numerical sequences using TensorFlow's preprocessing tools. This step involves converting each word into a corresponding token based on a fixed vocabulary size. These sequences are then padded to a uniform length, ensuring consistency in the input data. During training, the performance is heavily influenced by factors like data balancing and hyperparameter tuning. The MBTI dataset is inherently imbalanced, with certain personality types appearing far more frequently than others. To address this, only 30 samples per type are used in training to ensure balance. However, this approach simplifies the task and may lead to suboptimal results. The inference step involves tokenizing a new input post and passing it through the trained model to predict the MBTI type. It is important to note that with the current setup, the inference results may often return the same prediction. This is due to the limited dataset size, imbalanced data handling, and the need for further tuning of training parameters such as the number of epochs, batch size, and learning rate. This tutorial introduces an approach to train and infer MBTI personality types using TensorFlow. While the process highlights key steps like data preprocessing, model training, and inference, it does not delve deeply into AI-specific topics like advanced model optimization or deployment. To achieve better results, we could setup the dataset can be expanded to include more samples per personality type. Or setup hyperparameters like the learning rate, number of epochs, and embedding dimensions should be fine-tuned. Predicting with the Model Return to terminal and execute the following commands. First, deactivate the virtual environment, then activate the virtual environment for the Flask application, and finally, start the Flask app. Commands for Linux or Mac: deactivate source .venv/tensorflow/bin/activate python ./tensorflow/api/app.py Commands for Windows: deactivate .\.venv\tensorflow\Scripts\Activate.ps1 python .\tensorflow\api\app.py When you see a screen similar to the following, it means the server has started successfully. Press Ctrl+C to stop the server if needed. Before conducting the actual test, let’s construct some sample query data: I am happy Next, open a terminal and use the following curl commands to send requests to the app: curl -X GET "http://0.0.0.0:8000/api/detect" -H "Content-Type: application/json" -d '{"post": "I am happy"}' You should see the prediction results. PS: Your results may differ from mine due to variations in the sampling of your training dataset compared to mine. 5. Publishing the Project to Azure Code Commit to Azure DevOps First, create a new and empty repository (referred to as repo) under your Azure DevOps project and get its URL. Open a terminal in the cloned azure-appservice-ai project directory and run the following commands to add the new repo as a push/pull target. Then, verify the associated git repos for the directory. git remote add azure https://<organization>@dev.azure.com/<organization>/<project>/_git/azure-appservice-ai git remote -v Next, run the following commands in the terminal to push the entire project to the Azure DevOps repo. git push azure --all The following steps need to be performed only once.These configurations ensure that the pipeline can automatically deploy the tensorflow portion of the azure-appservice-ai project to the newly created Azure Web App. Setup Service Connection: Go to Project Settings in Azure DevOps and perform the necessary operations. Specify the Service connection name as "azure-appservice-ai-tensorflow" (you can use any name for easy identification). Create Pipeline YAML File: Navigate to the tensorflow subdirectory and create a new file named azure-pipeline.yml Copy the contents of another file named pipeline.yml (in the same directory) into azure-pipeline.yml Modify the variables section as indicated by the comments, then save and commit the changes. Setup the Pipeline: Navigate to the Pipelines section and create a new pipeline. Follow the prompts to select the newly created azure-pipeline.yml as the pipeline script file. Save the configuration (do not run it yet). The above setup steps only need to be done once. Next, you can deploy the project to the Azure Web App using the pipeline in different ways. Publish to Azure Web App via Pipeline Manual Trigger: Navigate to the newly created pipeline. Click Run Pipeline to start the deployment process. Click on the deployment to monitor its progress. Below is an example of a successful deployment screen. Trigger on Push: Alternatively, you can configure the pipeline to run automatically whenever new code is pushed to the Azure DevOps repo: Open a terminal and run the following commands (after code updates): git push azure --all This will trigger a new pipeline deployment process. 6. Running on Azure Web App Training the Model Return to terminal and execute the following commands to invoke the WebJobs. Commands for Linux or Mac: # Please change <subscription_id> <resourcegroup_name> and <webapp_name> to your own token=$(az account get-access-token --resource https://management.azure.com --query accessToken -o tsv) ; curl -X POST -H "Authorization: Bearer $token" -H "Content-Type: application/json" -d '{}' "https://management.azure.com/subscriptions/<subscription_id>/resourceGroups/<resourcegroup_name>/providers/Microsoft.Web/sites/<webapp_name>/triggeredwebjobs/train-mbti-model/run?api-version=2024-04-01" Commands for Windows: # Please change <subscription_id> <resourcegroup_name> and <webapp_name> to your own $token=$(az account get-access-token --resource https://management.azure.com --query accessToken -o tsv) ; Invoke-RestMethod -Uri "https://management.azure.com/subscriptions/<subscription_id>/resourceGroups/<resourcegroup_name>/providers/Microsoft.Web/sites/<webapp_name>/triggeredwebjobs/train-mbti-model/run?api-version=2024-04-01" -Headers @{Authorization = "Bearer $token"; "Content-type" = "application/json"} -Method POST -Body '{}' You could see the training status by execute the following commands. Commands for Linux or Mac: # Please change <subscription_id> <resourcegroup_name> and <webapp_name> to your own token=$(az account get-access-token --resource https://management.azure.com --query accessToken -o tsv) ; response=$(curl -s -H "Authorization: Bearer $token" "https://management.azure.com/subscriptions/<subscription_id>/resourceGroups/<resourcegroup_name>/providers/Microsoft.Web/sites/<webapp_name>/webjobs?api-version=2024-04-01") ; echo "$response" | jq Commands for Windows: # Please change <subscription_id> <resourcegroup_name> and <webapp_name> to your own $token=$(az account get-access-token --resource https://management.azure.com --query accessToken -o tsv); $response = Invoke-RestMethod -Uri "https://management.azure.com/subscriptions/<subscription_id>/resourceGroups/<resourcegroup_name>/providers/Microsoft.Web/sites/<webapp_name>/webjobs?api-version=2024-04-01" -Headers @{Authorization = "Bearer $token"} -Method GET ; $response | ConvertTo-Json -Depth 10 Processing Complete And you can get the latest detail log by execute the following commands. Commands for Linux or Mac: # Please change <subscription_id> <resourcegroup_name> and <webapp_name> to your own token=$(az account get-access-token --resource https://management.azure.com --query accessToken -o tsv) ; history_id=$(az webapp webjob triggered log --resource-group <resourcegroup_name> --name <webapp_name> --webjob-name train-mbti-model --query "[0].id" -o tsv | sed 's|.*/history/||') ; response=$(curl -X GET -H "Authorization: Bearer $token" -H "Content-Type: application/json" "https://management.azure.com/subscriptions/<subscription_id>/resourceGroups/<resourcegroup_name>/providers/Microsoft.Web/sites/<webapp_name>/triggeredwebjobs/train-mbti-model/history/$history_id/?api-version=2024-04-01") ; log_url=$(echo "$response" | jq -r '.properties.output_url') ; curl -X GET -H "Authorization: Bearer $token" "$log_url" Commands for Windows: # Please change <subscription_id> <resourcegroup_name> and <webapp_name> to your own $token = az account get-access-token --resource https://management.azure.com --query accessToken -o tsv ; $history_id = az webapp webjob triggered log --resource-group <resourcegroup_name> --name <webapp_name> --webjob-name train-mbti-model --query "[0].id" -o tsv | ForEach-Object { ($_ -split "/history/")[-1] } ; $response = Invoke-RestMethod -Uri "https://management.azure.com/subscriptions/<subscription_id>/resourceGroups/<resourcegroup_name>/providers/Microsoft.Web/sites/<webapp_name>/triggeredwebjobs/train-mbti-model/history/$history_id/?api-version=2024-04-01" -Headers @{ Authorization = "Bearer $token" } -Method GET ; $log_url = $response.properties.output_url ; Invoke-RestMethod -Uri $log_url -Headers @{ Authorization = "Bearer $token" } -Method GET Once you see the report in the Logs, it indicates that the training is complete, and the Flask app is ready for predictions. You can also find the newly trained models in the File Share mounted in your local environment. Using the Model for Prediction Just like in local testing, open a terminal and use the following curl commands to send requests to the app: # Note: Replace the instance of tensorflow-bicep-app with the name of your web app. curl -X GET "https://tensorflow-bicep-app.azurewebsites.net/api/detect" -H "Content-Type: application/json" -d '{"post": "I am happy"}' As with the local environment, you should see the expected results. 7. Troubleshooting docker.log freeze after deployment Symptom:I cannot get the latest deployment status after Azure DevOps publish the code to Web App via kudu site and frontpage getting error 504 Cause:This project includes two virtual environments, each containing a TensorFlow package. During the start.sh process of creating these environments, each environment takes approximately 10 minutes to set up. As a result, the docker.log or Log Stream might temporarily stall for about 20 minutes at a certain stage. Resolution: After roughly 20 minutes, once all the packages are downloaded, the logs will resume recording. Others Using Scikit-learn on Azure Web App Using OpenAI on Azure Web App 8. Conclusion TensorFlow, much like a Swiss Army knife, encompasses a wide range of training algorithms. While Azure Web App is not typically used for training models, it can still serve as a platform for inference. In the future, I plan to introduce how pre-trained models can be directly loaded using JavaScript. This approach allows the inference workload for non-sensitive models to be offloaded to the client side. 9. References TensorFlow MBTI text classifer trained on the Kaggle MBTI dataset (MBTI) Myers-Briggs Personality Type DatasetUsing Scikit-learn on Azure Web App
TOC Introduction to Scikit-learn System Architecture Architecture Focus of This Tutorial Setup Azure Resources Web App Storage Running Locally File and Directory Structure Training Models and Training Data Predicting with the Model Publishing the Project to Azure Deployment Configuration Running on Azure Web App Training the Model Using the Model for Prediction Troubleshooting Missing Environment Variables After Deployment Virtual Environment Resource Lock Issues Package Version Dependency Issues Default Binding Missing System Commands in Restricted Environments Conclusion References 1. Introduction to Scikit-learn Scikit-learn is a popular open-source Python library for machine learning, built on NumPy, SciPy, and matplotlib. It offers an efficient and easy-to-use toolkit for data analysis, data mining, and predictive modeling. Scikit-learn supports a variety of machine learning algorithms, including classification, regression, clustering, and dimensionality reduction (e.g., SVM, Random Forest, K-means). Its preprocessing utilities handle tasks like scaling, encoding, and missing data imputation. It also provides tools for model evaluation (e.g., accuracy, precision, recall) and pipeline creation, enabling users to chain preprocessing and model training into seamless workflows. 2. System Architecture Architecture Development Environment OS: Windows 11 Version: 24H2 Python Version: 3.7.3 Azure Resources App Service Plan: SKU - Premium Plan 0 V3 App Service: Platform - Linux (Python 3.9, Version 3.9.19) Storage Account: SKU - General Purpose V2 File Share: No backup plan Focus of This Tutorial This tutorial walks you through the following stages: Setting up Azure resources Running the project locally Publishing the project to Azure Running the application on Azure Troubleshooting common issues Each of the mentioned aspects has numerous corresponding tools and solutions. The relevant information for this session is listed in the table below. Local OS Windows Linux Mac V How to setup Azure resources Portal (i.e., REST api) ARM Bicep Terraform V How to deploy project to Azure VSCode CLI Azure DevOps GitHub Action V 3. Setup Azure Resources Web App We need to create the following resources or services: Manual Creation Required Resource/Service App Service Plan No Resource App Service Yes Resource Storage Account Yes Resource File Share Yes Service Go to the Azure Portal and create an App Service. Important configuration: OS: Select Linux (default if Python stack is chosen). Stack: Select Python 3.9 to avoid dependency issues. SKU: Choose at least Premium Plan to ensure enough memory for your AI workloads. Storage Create a Storage Account in the Azure Portal. Create a file share named data-and-model in the Storage Account. Mount the File Share to the App Service: Use the name data-and-model for consistency with tutorial paths. At this point, all Azure resources and services have been successfully created. Let’s take a slight detour and mount the recently created File Share to your Windows development environment. Navigate to the File Share you just created, and refer to the diagram below to copy the required command. Before copying, please ensure that the drive letter remains set to the default "Z" as the sample code in this tutorial will rely on it. Return to your development environment. Open a PowerShell terminal (do not run it as Administrator) and input the command copied in the previous step, as shown in the diagram. After executing the command, the network drive will be successfully mounted. You can open File Explorer to verify, as illustrated in the diagram. 4. Running Locally File and Directory Structure Please use VSCode to open a PowerShell terminal and enter the following commands: git clone https://github.com/theringe/azure-appservice-ai.git cd azure-appservice-ai .\scikit-learn\tools\add-venv.cmd If you are using a Linux or Mac platform, use the following alternative commands instead: git clone https://github.com/theringe/azure-appservice-ai.git cd azure-appservice-ai bash ./scikit-learn/tools/add-venv.sh After completing the execution, you should see the following directory structure: File and Path Purpose scikit-learn/tools/add-venv.* The script executed in the previous step (cmd for Windows, sh for Linux/Mac) to create all Python virtual environments required for this tutorial. .venv/scikit-learn-webjob/ A virtual environment specifically used for training models. scikit-learn/webjob/requirements.txt The list of packages (with exact versions) required for the scikit-learn-webjob virtual environment. .venv/scikit-learn/ A virtual environment specifically used for the Flask application, enabling API endpoint access for querying predictions. scikit-learn/requirements.txt The list of packages (with exact versions) required for the scikit-learn virtual environment. scikit-learn/ The main folder for this tutorial. scikit-learn/tools/create-folder.* A script to create all directories required for this tutorial in the File Share, including train, model, and test. scikit-learn/tools/download-sample-training-set.* A script to download a sample training set from the UCI Machine Learning Repository, containing heart disease data, into the train directory of the File Share. scikit-learn/webjob/train_heart_disease_model.py A script for training the model. It loads the training set, applies a machine learning algorithm (Logistic Regression), and saves the trained model in the model directory of the File Share. scikit-learn/webjob/train_heart_disease_model.sh A shell script for Azure App Service web jobs. It activates the scikit-learn-webjob virtual environment and starts the train_heart_disease_model.py script. scikit-learn/webjob/train_heart_disease_model.zip A ZIP file containing the shell script for Azure web jobs. It must be recreated manually whenever train_heart_disease_model.sh is modified. Ensure it does not include any directory structure. scikit-learn/api/app.py Code for the Flask application, including routes, port configuration, input parsing, model loading, predictions, and output generation. scikit-learn/.deployment A configuration file for deploying the project to Azure using VSCode. It disables the default Oryx build process in favor of custom scripts. scikit-learn/start.sh A script executed after deployment (as specified in the Portal's startup command). It sets up the virtual environment and starts the Flask application to handle web requests. Training Models and Training Data Return to VSCode and execute the following commands (their purpose has been described earlier). .\.venv\scikit-learn-webjob\Scripts\Activate.ps1 .\scikit-learn\tools\create-folder.cmd .\scikit-learn\tools\download-sample-training-set.cmd python .\scikit-learn\webjob\train_heart_disease_model.py If you are using a Linux or Mac platform, use the following alternative commands instead: source .venv/scikit-learn-webjob/bin/activate bash ./scikit-learn/tools/create-folder.sh bash ./scikit-learn/tools/download-sample-training-set.sh python ./scikit-learn/webjob/train_heart_disease_model.py After execution, the File Share will now include the following directories and files. Let’s take a brief detour to examine the structure of the training data downloaded from the public dataset website. The right side of the figure describes the meaning of each column in the dataset, while the left side shows the actual training data (after preprocessing). This is a predictive model that uses an individual’s physiological characteristics to determine the likelihood of having heart disease. Columns 1-13 represent various physiological features and background information of the patients, while Column 14 (originally Column 58) is the label indicating whether the individual has heart disease. The supervised learning process involves using a large dataset containing both features and labels. Machine learning algorithms (such as neural networks, SVMs, or in this case, logistic regression) identify the key features and their ranges that differentiate between labels. The trained model is then saved and can be used in services to predict outcomes in real time by simply providing the necessary features. Predicting with the Model Return to VSCode and execute the following commands. First, deactivate the virtual environment used for training the model, then activate the virtual environment for the Flask application, and finally, start the Flask app. Commands for Windows: deactivate .\.venv\scikit-learn\Scripts\Activate.ps1 python .\scikit-learn\api\app.py Commands for Linux or Mac: deactivate source .venv/scikit-learn/bin/activate python ./scikit-learn/api/app.py When you see a screen similar to the following, it means the server has started successfully. Press Ctrl+C to stop the server if needed. Before conducting the actual test, let’s construct some sample human feature data: [63, 1, 3, 145, 233, 1, 0, 150, 0, 2.3, 0, 0, 1] [63, 1, 3, 305, 233, 1, 0, 150, 0, 2.3, 0, 0, 1] Referring to the feature description table from earlier, we can see that the only modified field is Column 4 ("Resting Blood Pressure"), with the second sample having an abnormally high value. (Note: Normal resting blood pressure ranges are typically 90–139 mmHg.) Next, open a PowerShell terminal and use the following curl commands to send requests to the app: curl -X GET http://127.0.0.1:8000/api/detect -H "Content-Type: application/json" -d '{"info": [63, 1, 3, 145, 233, 1, 0, 150, 0, 2.3, 0, 0, 1]}' curl -X GET http://127.0.0.1:8000/api/detect -H "Content-Type: application/json" -d '{"info": [63, 1, 3, 305, 233, 1, 0, 150, 0, 2.3, 0, 0, 1]}' You should see the prediction results, confirming that the trained model is working as expected. 5. Publishing the Project to Azure Deployment In the VSCode interface, right-click on the target App Service where you plan to deploy your project. Manually select the local project folder named scikit-learn as the deployment source, as shown in the image below. Configuration After deployment, the App Service will not be functional yet and will still display the default welcome page. This is because the App Service has not been configured to build the virtual environment and start the Flask application. To complete the setup, go to the Azure Portal and navigate to the App Service. The following steps are critical, and their execution order must be correct. To avoid delays, it’s recommended to open two browser tabs beforehand, complete the settings in each, and apply them in sequence. Refer to the following two images for guidance. You need to do the following: Set the Startup Command: Specify the path to the script you deployed bash /home/site/wwwroot/start.sh Set Two App Settings: WEBSITES_CONTAINER_START_TIME_LIMIT=600 The value is in seconds, ensuring the Startup Command can continue execution beyond the default timeout of 230 seconds. This tutorial’s Startup Command typically takes around 300 seconds, so setting it to 600 seconds provides a safety margin and accommodates future project expansion (e.g., adding more packages). WEBSITES_ENABLE_APP_SERVICE_STORAGE=1 This setting is required to enable the App Service storage feature, which is necessary for using web jobs (e.g., for model training). Step-by-Step Process: Before clicking Continue, switch to the next browser tab and set up all the app settings. In the second tab, apply all app settings, then switch back to the first tab. Click Continue in the first tab and wait for several seconds for the operation to complete. Once completed, switch to the second tab and click Continue within 5 seconds. Ensure to click Continue promptly within 5 seconds after the previous step to finish all settings. After completing the configuration, wait for about 10 minutes for the settings to take effect. Then, navigate to theWebJobs section in the Azure Portal and upload the ZIP file mentioned in the earlier sections. Set its trigger type to Manual. At this point, the entire deployment process is complete. For future code updates, you only need to redeploy from VSCode; there is no need to reconfigure settings in the Azure Portal. 6. Running on Azure Web App Training the Model Go to the Azure Portal, locate your App Service, and navigate to the WebJobs section. Click on Start to initiate the job and wait for the results. During this process, you may need to manually refresh the page to check the status of the job execution. Refer to the image below for guidance. Once you see the model report in the Logs, it indicates that the model training is complete, and the Flask app is ready for predictions. You can also find the newly trained model in the File Share mounted in your local environment. Using the Model for Prediction Just like in local testing, open a PowerShell terminal and use the following curl commands to send requests to the app: # Note: Replace both instances of scikit-learn-portal-app with the name of your web app. curl -X GET https://scikit-learn-portal-app.azurewebsites.net/api/detect -H "Content-Type: application/json" -d '{"info": [63, 1, 3, 145, 233, 1, 0, 150, 0, 2.3, 0, 0, 1]}' curl -X GET https://scikit-learn-portal-app.azurewebsites.net/api/detect -H "Content-Type: application/json" -d '{"info": [63, 1, 3, 305, 233, 1, 0, 150, 0, 2.3, 0, 0, 1]}' As with the local environment, you should see the expected results. 7. Troubleshooting Missing Environment Variables After Deployment Symptom: Even after setting values in App Settings (e.g., WEBSITES_CONTAINER_START_TIME_LIMIT), they do not take effect. Cause: App Settings (e.g., WEBSITES_CONTAINER_START_TIME_LIMIT, WEBSITES_ENABLE_APP_SERVICE_STORAGE) are reset after updating the startup command. Resolution: Use Azure CLI or the Azure Portal to reapply the App Settings after deployment. Alternatively, set the startup command first, and then apply app settings. Virtual Environment Resource Lock Issues Symptom: The app fails to redeploy, even though no configuration or code changes were made. Cause: The virtual environment folder cannot be deleted due to active resource locks from the previous process. Files or processes from the previous virtual environment session remain locked. Resolution: Deactivate processes before deletion and use unique epoch-based folder names to avoid conflicts. Refer to scikit-learn/start.sh in this tutorial for implementation. Package Version Dependency Issues Symptom: Conflicts occur between package versions specified in requirements.txt and the versions required by the Python environment. This results in errors during installation or runtime. Cause: Azure deployment environments enforce specific versions of Python and pre-installed packages, leading to mismatches when older or newer versions are explicitly defined. Additionally, the read-only file system in Azure App Service prevents modifying global packages like typing-extensions. Resolution: Pin compatible dependency versions. For example, follow the instructions for installing scikit-learn from the scikit-learn 1.5.2 documentation. Refer to scikit-learn/requirements.txtin this tutorial. Default Binding Symptom: Despite setting the WEBSITES_PORT parameter in App Settings to match the port Flask listens on (e.g., Flask's default 5000), the deployment still fails. Cause: The Flask framework's default settings are not overridden to bind to 0.0.0.0 or the required port. Resolution: Explicitly bind Flask to 0.0.0.0:8000 in app.py . To avoid additional issues, it’s recommended to use the Azure Python Linux Web App's default port (8000), as this minimizes the need for extra configuration. Missing System Commands in Restricted Environments Symptom: In the WebJobs log, an error is logged stating that the ls command is missing. Cause: This typically occurs in minimal environments, such as Azure App Services, containers, or highly restricted shells. Resolution: Use predefined paths or variables in the script instead of relying on system commands. Refer to scikit-learn/webjob/train_heart_disease_model.shin this tutorial for an example of handling such cases. 8. Conclusion Azure App Service, while being a PaaS product with less flexibility compared to a VM, still offers several powerful features that allow us to fully leverage the benefits of AI frameworks. For example, the resource-intensive model training phase can be offloaded to a high-performance local machine. This approach enables the App Service to focus solely on loading models and serving predictions. Additionally, if the training dataset is frequently updated, we can configure WebJobs with scheduled triggers to retrain the model periodically, ensuring the prediction service always uses the latest version. These capabilities make Azure App Service well-suited for most business scenarios. 9. References Scikit-learn Documentation UCI Machine Learning Repository Azure App Service DocumentationUnlock New AI and Cloud Potential with .NET 9 & Azure: Faster, Smarter, and Built for the Future
.NET 9, now available to developers, marks a significant milestone in the evolution of the .NET platform, pushing the boundaries of performance, cloud-native development, and AI integration. This release, shaped by contributions from over 9,000 community members worldwide, introduces thousands of improvements that set the stage for the future of application development. With seamless integration withAzure and a focus on cloud-native development and AI capabilities, .NET 9 empowers developers to build scalable, intelligent applications with unprecedented ease. Expanding Azure PaaS Support for .NET 9 With the release of .NET 9, a comprehensive range of Azure Platform as a Service (PaaS) offerings now fully support the platform’s new capabilities, including the latest .NET SDK for any Azure developer. This extensive support allows developers to build, deploy, and scale .NET 9 applications with optimal performance and adaptability on Azure. Additionally, developers can access a wealth of architecture references and sample solutions to guide them in creating high-performance .NET 9 applications on Azure’s powerful cloud services: Azure App Service: Run, manage, and scale .NET 9 web applications efficiently. Check out this blog to learn more about what's new in Azure App Service. Azure Functions: Leverage serverless computing to build event-driven .NET 9 applications with improved runtime capabilities. Azure Container Apps: Deploy microservices and containerized .NET 9 workloads with integrated observability. Azure Kubernetes Service (AKS): Run .NET 9 applications in a managed Kubernetes environment with expanded ARM64 support. Azure AI Services and Azure OpenAI Services: Integrate advanced AI and OpenAI capabilities directly into your .NET 9 applications. Azure API Management, Azure Logic Apps, Azure Cognitive Services, and Azure SignalR Service: Ensure seamless integration and scaling for .NET 9 solutions. These services provide developers with a robust platform to build high-performance, scalable, and cloud-native applications while leveraging Azure’s optimized environment for .NET. Streamlined Cloud-Native Development with .NET Aspire .NET Aspire is a game-changer for cloud-native applications, enabling developers to build distributed, production-ready solutions efficiently. Available in preview with .NET 9, Aspire streamlines app development, with cloud efficiency and observability at its core. The latest updates in Aspire include secure defaults, Azure Functions support, and enhanced container management. Key capabilities include: Optimized Azure Integrations: Aspire works seamlessly with Azure, enabling fast deployments, automated scaling, and consistent management of cloud-native applications. Easier Deployments to Azure Container Apps: Designed for containerized environments, .NET Aspire integrates with Azure Container Apps (ACA) to simplify the deployment process. Using the Azure Developer CLI (azd), developers can quickly provision and deploy .NET Aspire projects to ACA, with built-in support for Redis caching, application logging, and scalability. Built-In Observability: A real-time dashboard provides insights into logs, distributed traces, and metrics, enabling local and production monitoring with Azure Monitor. With these capabilities, .NET Aspire allows developers to deploy microservices and containerized applications effortlessly on ACA, streamlining the path from development to production in a fully managed, serverless environment. Integrating AI into .NET: A Seamless Experience In our ongoing effort to empower developers, we’ve made integrating AI into .NET applications simpler than ever. Our strategic partnerships, including collaborations with OpenAI, LlamaIndex, and Qdrant, have enriched the AI ecosystem and strengthened .NET’s capabilities. This year alone, usage of Azure OpenAI services has surged to nearly a billion API calls per month, illustrating the growing impact of AI-powered .NET applications. Real-World AI Solutions with .NET: .NET has been pivotal in driving AI innovations. From internal teams like Microsoft Copilot creating AI experiences with .NET Aspireto tools like GitHub Copilot, developed with .NET to enhance productivity in Visual Studio and VS Code, the platform showcases AI at its best. KPMG Clara is a prime example, developed to enhance audit quality and efficiency for 95,000 auditors worldwide. By leveraging .NET and scaling securely on Azure, KPMG implemented robust AI features aligned with strict industry standards, underscoring .NET and Azure as the backbone for high-performing, scalable AI solutions. Performance Enhancements in .NET 9: Raising the Bar for Azure Workloads .NET 9 introduces substantial performance upgrades with over 7,500 merged pull requests focused on speed and efficiency, ensuring .NET 9 applications run optimally on Azure. These improvements contribute to reduced cloud costs and provide a high-performance experience across Windows, Linux, and macOS. To see how significant these performance gains can be for cloud services, take a look at what past .NET upgrades achieved for Microsoft’s high-scale internal services: Bing achieved a major reduction in startup times, enhanced efficiency, and decreased latency across its high-performance search workflows. Microsoft Teams improved efficiency by 50%, reduced latency by 30–45%, and achieved up to 100% gains in CPU utilization for key services, resulting in faster user interactions. Microsoft Copilot and other AI-powered applications benefited from optimized runtime performance, enabling scalable, high-quality experiences for users. Upgrading to the latest .NET version offers similar benefits for cloud apps, optimizing both performance and cost-efficiency. For more information on updating your applications, check out the .NET Upgrade Assistant. For additional details on ASP.NET Core, .NET MAUI, NuGet, and more enhancements across the .NET platform, check out the full Announcing .NET 9 blog post. Conclusion: Your Path to the Future with .NET 9 and Azure .NET 9 isn’t just an upgrade—it’s a leap forward, combining cutting-edge AI integration, cloud-native development, and unparalleled performance. Paired with Azure’s scalability, these advancements provide a trusted, high-performance foundation for modern applications. Get started by downloading .NET 9 and exploring its features. Leverage .NET Aspire for streamlined cloud-native development, deploy scalable apps with Azure, and embrace new productivity enhancements to build for the future. For additional insights on ASP.NET, .NET MAUI, NuGet, and more, check out the full Announcing .NET 9 blog post. Explore the future of cloud-native and AI development with .NET 9 and Azure—your toolkit for creating the next generation of intelligent applications.
What's New in Azure App Service at Ignite 2024
Learn about the GA of sidecar extensibility on Linux and see team members demonstrating the latest tools for AI assisted web application migration and modernization as well as the latest updates to Java JBoss EAP on Azure App Service. Team members will also demonstrate integrating the Phi-3 small language model with a web application via the new sidecar extensibility using existing App Service hardware! Also new for this year’s Ignite, many topics that attendees see in App Service related sessions are also available for hands-on learning across multiple hands-on labs (HoLs). Don’t just watch team members demonstrating concepts on-stage, drop by one of the many HoL sessions and test drive the functionality yourself! Azure App Service team members will also be in attendance at the Expert Meetup area on the third floor in the Hub – drop by and chat if you are attending in-person! Additional demos, presentations and hands-on labs covering App Service are listed at the end of this blog post for easy reference. Sidecar Extensibility GA for Azure App Service on Linux Sidecar extensibility for Azure App Service on Linux is now GA! Linux applications deployed from source-code as well as applications deployed using custom containers can take advantage of sidecar extensibility. Sidecars enable developers to attach additional capabilities like third-party application monitoring providers, in-memory caches, or even local SLM (small language model) support to their applications without having to bake that functionality directly into their applications. Developers can configure up to four sidecar containers per application, with each sidecar being associated with its own container registry and (optional) startup command. Examples of configuring an OpenTelemetry collector sidecar are available in the documentation for both container-based applications and source-code based applications. There are also several recent blog posts demonstrating additional sidecar scenarios. One example walks through using a Redis cache sidecar as an in-memory cache to accelerate data retrieval in a web application (sample code here). Another example demonstrates adding a sidecar containing the Phi-3 SLM to a custom container web application (sample code here). Once the web app is running with the SLM sidecar, Phi-3 processes text prompts directly on the web server without the need to call remote LLMs or host models on scarce GPU hardware. Similar examples for source deployed applications are available in the Ignite 2024 hands on lab demonstrating sidecars. Exercise three walks through attaching an OTel sidecar to a source-code based application, and exercise four shows how to attach a Phi-3 sidecar to a source-code based application. Looking ahead to the future, App Service will be adding “curated sidecars” to the platform to make it easier for developers to integrate common sidecar scenarios. Development is already underway to include options for popular third-party application monitoring providers, Redis cache support, as well as a curated sidecar encapsulating the Phi-3 SLM example mentioned earlier. Stay tuned for these enhancements in the future! If you are attending Microsoft Ignite 2024 in person, drop by the theater session “Modernize your apps with AI without completely rewriting your code” (session code:THR 614) which demonstrates using sidecar extensibility to add Open Telemetry monitoring as well as Phi-3 SLM support to applications on App Service for Linux! .NET 9 GA, JBoss EAP and More Language Updates! With the recent GA of .NET 9 last week developers can deploy applications running .NET 9 GA on both Windows and Linux variants of App Service! Visual Studio, Visual Studio Code, Azure DevOps and GitHub Actions all support building and deploying .NET 9 applications onto App Service. Start a new project using .NET 9 or upgrade your existing .NET applications in-place and take advantage of .NET 9! For JBoss EAP on App Service for Linux, customers will soon be able to bring their existing JBoss licenses with them when moving JBoss EAP workloads onto App Service for Linux. This change will make it easier and more cost effective than ever for JBoss EAP customers to migrate existing workloads to App Service, including JBoss versions 7.3, 7.4 and 8.0! As a quick reminder, last month App Service also announced reduced pricing for JBoss EAP licenses (for net-new workloads) as well as expanded hardware support (both memory-optimized and Free tier are now supported for JBoss EAP applications). App Service is planning to release both Node 22 and Python 3.13 onto App Service for Linux with expected availability in December! Python 3.13 is the latest stable Python release which means developers will be able to leverage this version with confidence given long term support runs into 2029. Node 22 is the latest active LTS release of Node and is a great version for developers to adopt with its long-term support lasting into 2026. A special note for Linux Python developers, App Service now supports “auto-instrumentation” in public preview for Python versions 3.8 through 3.12.This makes it trivial for source-code based Python applications to enable Application Insights monitoring for their applications by simply turning the feature “on” in the Azure Portal. If you ever thought to yourself that it can be a hassle setting up application monitoring and hence find yourself procrastinating, this is the monitoring feature for you! Looking ahead just a few short weeks until December, App Service also plans to release PHP 8.4 for developers on App Service for Linux. This will enable PHP developers to leverage the latest fully supported PHP release with an expected support cycle stretching into 2028. For WordPress customers Azure App Service has added support for managed identities when connecting to MySQL database as well as storage accounts. The platform has also transitioned WordPress from Alpine Linux to Debian, aligning with App Service for Linux to offer a more secure platform. Looking ahead, App Service is excited to introduce some new features by the end of the year, including an App Service plugin for WordPress! This plugin will enable users to manage WordPress integration with Azure Communication Services email, set up Single Sign-On using Microsoft Entra ID, and diagnose performance bottlenecks. Stay tuned for upcoming WordPress announcements! End-to-End TLS & Min TLS Cipher Suite are now GA End-to-end TLS encryption for public multi-tenant App Service is now GA! When E2E TLS is configured, traffic between the App Service frontends and individual workers is secured using a platform supplied TLS certificate. This additional level of security is available for both Windows and Linux sites using Standard SKU and above as well as Isolatedv2 SKUs. You can enable this feature easily in the Azure Portal by going to your resource, clicking the “Configuration” blade and turning the feature “On” as shown below: Configuration of the minimum TLS cipher suite for a web application is also GA! With this feature developers can choose from a pre-determined list of cipher suites. When a minimum cipher suite is selected, the App Service frontends will reject any incoming requests that use a cipher suite weaker than the selected minimum cipher suite. This feature is supported for both Windows and Linux applications using Basic SKU and higher as well as Isolatedv2 SKUs. You configure a minimum TLS cipher suite in the Azure Portal by going to the “Configuration” blade for a website and selecting “Change” for the Minimum Inbound TLS Cipher Suite setting. In the resulting blade (shown below) you can select the minimum cipher suite for your application: To learn more about these and other TLS features on App Service, please refer to the App Service TLS overview. AI-Powered Conversational Diagnostics Building on the Conversational Diagnostics AI-powered tool and the guided decision making path introduced in Diagnostic Workflows, the team has created a new AI-driven natural language-based diagnostics solution for App Service on Linux. The new solution brings together previous functionality to create an experience that comprehends user intent, selects the appropriate Diagnostic Workflow, and keeps users engaged by providing real-time updates and actionable insights through chat. Conversational Diagnostics also provides the grounding data that the generative AI back-end uses to produce recommendations thus empowering users to check the conclusions. The integration of Conversational Diagnostics and Diagnostic Workflows marks a significant advancement in the platform’s diagnostic capabilities. Stay tuned for more updates and experience the transformative power of Generative AI-driven diagnostics firsthand! App Service Migration and Modernization The team just recently introduced new architectural guidance around evolving and modernizing web applications with the Modern Web Application pattern for .NET andJava! This guidance builds on the Reliable Web App pattern for .NET and Java as well as the Azure Migrate application and code assessment tool. With the newly released Modern Web Application guidance, there is a well-documented path for migrating web applications from on-premises/VM deployments using the application and code assessment tool, iterating and evolving web applications with best practices using guidance from the Reliable Web App pattern, and subsequently going deeper on modernization and re-factoring following guidance from the Modern Web Application pattern. Best of all customers can choose to “enter” this journey at any point and progress as far down the modernization path as needed based on their unique business and technical requirements! As a quick recap on the code assessment tool, it is a guided experience inside of Visual Studio with GitHub Copilot providing actionable guidance and feedback on recommended changes needed to migrate applications to a variety of Azure services including Azure App Service. Combined with AI-powered Conversational Diagnostics (mentioned earlier), developers now have AI-guided journeys supporting them from migration all the way through deployment and runtime operation on App Service! Networking and ASE Updates As of November 1, 2024, we are excited to announce that App Service multi-plan subnet join is generally available across all public Azure regions! Multi-plan subnet join eases network management by reducing subnet sprawl, enabling developers to connect multiple app service plans to a single subnet. There is no limit to the number of app service plans that connect to a single subnet. However, developers should keep in mind the number of available IPs since tasks such as changing the SKU for an app service plan will temporarily double the number of IP addresses used in a connected subnet. For more information as well as examples on using multi-plan subnet join see the documentation! App Service also recently announced GA of memory optimized options for Isolatedv2 on App Service Environment v3. The new memory-optimized options range from two virtual cores with 16 GB RAM in I1mv2 (compared to two virtual cores, 8 GB RAM in I1v2) all the way up to 32 virtual cores with 256 GB RAM in I5mv2. The new plansare available in most regions. Check back regularly to see if your preferred region is supported. For more details on the technical specifications of these plans, as well as information on the complete range of tiers and plans forMicrosoft Azure App Service, visit ourpricing page. Using services such as Application Gateway and Azure Front Door with App Service as entry points for client traffic is a common scenario that many of our customers implement. However, when using these services together, there are integration challenges around the default cookie domain for HTTP cookies, including the ARRAffinity cookie used for session affinity. App Service collaborated with the Application Gateway team to introduce a simple solution that addresses the session affinity problem. App Service introduced a new session affinity proxy configuration setting in October which tells App Service to always set the hostname for outbound cookies based on the upstream hostname seen by Application Gateway or Azure Front Door. This simplifies integration with a single-click experience for App Service developers who front-end their websites using one of Azure’s reverse proxies, and it solves the challenge of round-tripping the ArrAffinity cookie when upstream proxies are involved. Looking ahead to early 2025, App Service will shortly be expanding support for IPv6 to include both inbound and outbound connections (currently only inbound connections are supported). The current public preview includes dual-stack support for both IPv4 and IPv6, allowing for a smooth transition and compatibility with existing systems. Read more about the latest status of the IPv6 public preview on App Service here ! Lastly, the new application naming and hostname convention that was rolled out a few months earlier for App Service is now GA for App Service. The platform has also extended this new naming convention to Azure Functions where it is now available in public preview for newly created functions. To learn more about the new naming convention and the protection it provides against subdomain takeover take a look at the introductory blog post about the unique default hostname feature. Upcoming Availability Zone Improvements New Availability Zone features are currently rolling out that will make zone redundant App Service deployments more cost efficient and simpler to manage in early 2025! The platform will be changing the minimum requirement for enabling Availability Zones to two instances instead of three, while still maintaining a 99.99% SLA. Many existing app service plans with two or more instances will also automatically become capable of supporting Availability Zones without requiring additional setup. Additionally, the zone redundant setting will be mutable throughout the life of an app service plan. This upcoming improvement will allow customers on Premium V2, Premium V3, or Isolated V2 plans, to toggle zone redundancy on or off as needed. Customers will also gain enhanced visibility into Availability Zone information, including physical zone placement and counts. As a sneak peek into the future, the screenshot below shows what the new experience will look like in the Azure Portal: Stay tuned for Availability Zone updates coming to App Service in early 2025! Next Steps Developers can learn more about Azure App Service at Getting Started with Azure App Service. Stay up to date on new features and innovations on Azure App Service via Azure Updatesas well as the Azure App Service (@AzAppService) X feed. There is always a steady stream of great deep-dive technical articles about App Service as well as the breadth of developer focused Azure services over on the Apps on Azure blog. Azure App Service (virtually!) attended the recently completed November .Net Conf 2024. App Service functionality was featured showing a .NET 9.0 app using Azure Sql’s recently releasednative vector data type support that enables developers to perform hybrid text searches on Azure Sql data using vectors generated via Azure OpenAI embeddings! And lastly take a look at Azure App Service Community Standups hosted on the Microsoft Azure Developers YouTube channel. The Azure App Service Community Standup series regularly features walkthroughs of new and upcoming features from folks that work directly on the product! Ignite 2024 Session Reference (Note: some sessions/labs have more than one timeslot spanning multiple days). (Note: all times below are listed in Chicago time - Central Standard Time). Modernize your apps with AI without completely rewriting your code Modernize your apps with AI without completely rewriting your code [Note: this session includes a demonstration of the Phi-3 sidecar scenario] Wednesday, November 20 th 1:00 PM - 1:30 PM Central Standard Time Theater Session – In-Person Only (THR614) McCormick Place West Building – Level 3, Hub, Theater C Unlock AI: Assess your app and data estate for AI-powered innovation Unlock AI: Assess your app and data estate for AI-powered innovation Wednesday, November 20 th 1:15 PM – 2:00 PM Central Time McCormick Place West Building – Level 1, Room W183c Breakout and Recorded Session (BRK137) Modernize and scale enterprise Java applications on Azure Modernize and scale enterprise Java applications on Azure Thursday, November 21 st 8:30 AM - 9:15 AM Central Time McCormick Place West Building – Level 1, Room W183c Breakout and Recorded Session (BRK147) Assess apps with Azure Migrate and replatform to Azure App Service Assess apps with Azure Migrate and replatform to Azure App Service Tuesday, November 19 th 1:15 PM - 2:30 PM Central Time McCormick Place West Building – Level 4, Room W475 Hands on Lab – In-Person Only (LAB408) Integrate GenAI capabilities into your .NET apps with minimal code changes Integrate GenAI capabilities into your .NET apps with minimal code changes [Note: Lab participants will be able to try out the Phi-3 sidecar scenario in this lab.] Wednesday, November 20 th 8:30 AM - 9:45 AM Central Time McCormick Place West Building – Level 4, Room W475 Hands on Lab – In-Person Only (LAB411) Assess apps with Azure Migrate and replatform to Azure App Service Assess apps with Azure Migrate and replatform to Azure App Service Wednesday, November 20 th 6:30 PM - 7:45 PM Central Time McCormick Place West Building – Level 4, Room W470b Hands on Lab – In-Person Only (LAB408-R1) Integrate GenAI capabilities into your .NET apps with minimal code changes Integrate GenAI capabilities into your .NET apps with minimal code changes [Note: Lab participants will be able to try out the Phi-3 sidecar scenario in this lab.] Thursday, November 21 st 10:15 AM - 11:30 AM Central Time McCormick Place West Building – Level 1, Room W180 Hands on Lab – In-Person Only (LAB411-R1) Assess apps with Azure Migrate and replatform to Azure App Service Assess apps with Azure Migrate and replatform to Azure App Service Friday, November 22 nd 9:00 AM – 10:15 AM Central Time McCormick Place West Building – Level 4, Room W474 Hands on Lab – In-Person Only (LAB408-R2)Deploy secure App Service resources to prevent dangling DNS entries and avoid subdomain takeover
Back in May 2024, we announced the Public Preview of Secure Unique Default Hostnames on Web Apps. We are excited to announce that this feature is now in General Availability on Web Apps and is now in Public Preview for Functions! This feature works similarly for both Web Apps and Functions, so you can refer to the Public Preview announcement for more in-depth information regarding this feature. Secure unique default hostname feature is a long-term solution to protect your resources fromdangling DNS entries and subdomain takeover. If you have this feature enabled for your App Service resources, then no one outside of your organization would be able to recreate resources with the same default hostname. This means that malicious actors can no longer take advantage of your dangling DNS entries and takeover your subdomains. We highly encourage everyone to enable secure unique default hostnames on their net-new App Service deployments. Addressing pre-existing resources without secure unique default hostnames enabled Since this feature can only be enabled upon resource creation, if you’d like to use this feature for your pre-existing resources, you can: Clone a pre-existing app to a new app with secure unique default hostname enabled Screenshot of cloning pre-existing app to an app that's about to be created with secure unique default hostname enabled. Use a backup of a pre-existing app to restore to a new app with secure unique default hostname enabled Screenshot of using a backup of a pre-existing app to restore to an app that's about to be created with secure unique default hostname enabled. Looking ahead We highly encourage everyone to enable secure unique default hostnames on all net-new App Service deployments. This is the time to integrate and to adopt this feature to your testing and production environments so that you can build more secure App Service resources to prevent dangling DNS entries and avoid subdomain takeover. Keep an eye out for future announcements where we will launch secure unique default hostnames in Public Preview for Logic Apps (Standard)!
