Transitioning from Non-managed to Managed WordPress on App Service Linux
Introduction We've received numerous queries about WordPress on App Service, and we love it! Your feedback helps us improve our offerings. A common theme is the challenges faced with non-managed WordPress setups. Our managed WordPress offering on App Service is designed to be highly performant, secure, and seamlessly integrated with Azure services like MySQL flexible server, CDN/Front Door, Blob Storage, VNET, and Azure Communication Services. While some specific cases might require a custom WordPress setup, most users benefit significantly from our managed service, enjoying better performance, security, easier management, and cost savings. If you're experiencing performance issues or problems with stack updates, you might be using a non-managed WordPress setup. This could happen if you didn't use our marketplace offering or if you replaced WordPress files via FTP after setup. In such cases, check if you're using the managed WordPress service. In this article, we'll explore how to check if you're using the managed offering and how to transition if you're not. Why Choose Managed WordPress on App Service? Under the Hood Optimized Container Image: We use a container image with numerous optimizations. Learn more: https://github.com/Azure/wordpress-linux-appservice Environment Variables: These configure WordPress and integrate various Azure resources. Learn more: https://github.com/Azure/wordpress-linux-appservice/blob/main/WordPress/wordpress_application_settings.md Azure resources: We integrate multiple Azure resources like App Service, MySQL flexible database, Entra ID, VNET, ACS Email, CDN/Front Door, and Blob storage, all configured via environment variables. Also, the resources individually are configured to best work with WordPress. Benefits of Managed Offering Managed Tech Stack: Our team handles updates for PHP, Nginx, WordPress, etc., ensuring you're always on the latest versions without performance or security concerns. Read more: https://techcommunity.microsoft.com/blog/appsonazureblog/how-to-keep-your-wordpress-website-stack-on-azure-app-service-up-to-date/3832193 Managed MySQL Instance: We use Azure Database for MySQL flexible server as the WordPress database. Many customers use in-App databases, which increase maintenance costs and require manual configurations. Our managed MySQL instance is optimized (server parameters) for performance and security, and you don't need to worry about upgrades. Azure Service Integrations: Our managed offering integrates seamlessly with Azure services like CDN, Front Door, Entra ID, VNET, and Communication Services for Email. These integrations are important for enhancing the WordPress experience. For example, without ACS Email, WordPress can't send emails, affecting tasks like password resets and user invitations. We handle these integrations through environment variables, simplifying the setup. Learn more: https://github.com/Azure/wordpress-linux-appservice/blob/main/WordPress/wordpress_application_settings.md Simplified creation: Creating WordPress site involves configuring various resources, which can be complex. Our managed service simplifies this process. See how to create a WordPress site: https://learn.microsoft.com/en-us/azure/app-service/quickstart-wordpress Simplified management: Managing multiple resources can be complex. We manage this by environment variables. We extend this capability to complex WordPress configurations as well. For example, WordPress multisite: https://github.com/Azure/wordpress-linux-appservice/blob/main/WordPress/wordpress_multisite_installation.md Security: We provide best in class security – like use of managed identities: https://techcommunity.microsoft.com/blog/appsonazureblog/managed-identity-support-for-wordpress-on-app-service/4241435. We ensure all resources are within a VNET and privde phpMyAdmin for database management: https://github.com/Azure/wordpress-linux-appservice/blob/main/WordPress/wordpress_phpmyadmin.md Performance improvements: We have optimized performance with the W3TC plugin, local storage caching, and efficient use of caching, content delivery, and storage. Others: There are a bunch of other interesting features that you might be interested in: https://learn.microsoft.com/en-us/azure/app-service/overview-wordpress https://learn.microsoft.com/en-us/azure/app-service/wordpress-faq How to Check if You're Using the Managed WordPress on App Service? To determine if you're using the managed offering, follow these steps: Check the Container Image: Go to the App Service overview page in the Azure portal. Look for the "Container image" in the properties tab. If the image matches one of our supported images(https://github.com/Azure/wordpress-linux-appservice), you're likely using the managed service. If not, you'll need to migrate to the managed offering, which we'll cover later. 2. Verify Environment Variables: Access the Kudo console and navigate to the File manager. Open the /home/site/wwwroot/wp-config.php file and check if it uses the environment variables correctly. 3. Check Deployment Status: In the File manager, locate the /home/wp-locks/wp_deployment_status.txt file WARNING: Do not edit this file as it may cause unintended issues. Simply check the entries. If the file is missing or its contents differ from the expected entries, you're using a non-managed WordPress site. If the file is present and the contents match, you're on the managed offering. How to transition to the managed offering? Transitioning to the managed WordPress on App Service can be done in two ways: Highly Recommended Approach: Follow these steps: Create a new managed WordPress site: Follow the steps in this setup guide to create a new managed WordPress site on App Service. https://techcommunity.microsoft.com/blog/appsonazureblog/how-to-set-up-a-new-wordpress-website-on-azure-app-service/3729150 Migrate Content Using All-in-One Migration Plugin: Use the All-in-One Migration plugin to transfer your content from the source site to the new managed site. This migration guide provides detailed instructions. Although it’s tailored for migrating from WP Engine, the steps are applicable to this scenario as well. Simply skip the WP Engine-specific steps. https://techcommunity.microsoft.com/blog/appsonazureblog/how-to-migrate-from-wp-engine-to-wordpress-on-app-service/4259573 Point Your Custom Domain to the New Site: Update your custom domain to point to the new managed WordPress site. Follow the instructions in this custom domain guide. https://techcommunity.microsoft.com/blog/appsonazureblog/how-to-use-custom-domains-with-wordpress-on-app-service/3886247 Not Recommended Approach: Some customers ask if they can simply apply the managed container image, add environment variables, and create the necessary resources manually. While this is technically possible, it often leads to numerous errors and involves many steps. If any step goes wrong, you might not achieve the desired outcome and could potentially break your existing site. The recommended approach ensures your existing site remains safe and intact until the new site is fully operational. We hope you transition to the managed WordPress on App Service and enjoy the best WordPress experience! Support and Feedback We’re here to help! If you need any assistance, feel free to open a support request through the Microsoft Azure portal. New support request - Microsoft Azure For more details about our offering, check out the announcement on the General Availability of WordPress on Azure App Service in the Microsoft Tech Community. Announcing the General Availability of WordPress on Azure App Service - Microsoft Tech Community. We value your feedback and ideas on how we can improve WordPress on Azure App Service. Share your thoughts and suggestions on our Community page Post idea · Community (azure.com) or report any issues on our GitHub repository Issues · Azure/wordpress-linux-appservice (github.com). Alternatively, you can start a conversation with us by emailing wordpressonazure@microsoft.com.Superfast using Web App and Managed Identity to invoke Function App triggers
TOC Introduction Setup References 1. Introduction Many enterprises prefer not to use App Keys to invoke Function App triggers, as they are concerned that these fixed strings might be exposed. This method allows you to invoke Function App triggers using Managed Identity for enhanced security. I will provide examples in both Bash and Node.js. 2. Setup 1. Create a Linux Python 3.11 Function App 1.1. Configure Authentication to block unauthenticated callers while allowing the Web App’s Managed Identity to authenticate. Identity Provider Microsoft Choose a tenant for your application and it's users Workforce Configuration App registration type Create Name [automatically generated] Client Secret expiration [fit-in your business purpose] Supported Account Type Any Microsoft Entra Directory - Multi-Tenant Client application requirement Allow requests from any application Identity requirement Allow requests from any identity Tenant requirement Use default restrictions based on issuer Token store [checked] 1.2. Create an anonymous trigger. Since your app is already protected by App Registration, additional Function App-level protection is unnecessary; otherwise, you will need a Function Key to trigger it. 1.3. Once the Function App is configured, try accessing the endpoint directly—you should receive a 401 Unauthorized error, confirming that triggers cannot be accessed without proper Managed Identity authorization. 1.4. After making these changes, wait 10 minutes for the settings to take effect. 2. Create a Linux Node.js 20 Web App and Obtain an Access Token and Invoke the Function App Trigger Using Web App (Bash Example) 2.1. Enable System Assigned Managed Identity in the Web App settings. 2.2. Open Kudu SSH Console for the Web App. 2.3. Run the following commands, making the necessary modifications: subscriptionsID → Replace with your Subscription ID. resourceGroupsID → Replace with your Resource Group ID. application_id_uri → Replace with the Application ID URI from your Function App’s App Registration. https://az-9640-faapp.azurewebsites.net/api/test_trigger → Replace with the corresponding Function App trigger URL. # Please setup the target resource to yours subscriptionsID="01d39075-XXXX-XXXX-XXXX-XXXXXXXXXXXX" resourceGroupsID="XXXX" # Variable Setting (No need to change) identityEndpoint="$IDENTITY_ENDPOINT" identityHeader="$IDENTITY_HEADER" application_id_uri="api://9c0012ad-XXXX-XXXX-XXXX-XXXXXXXXXXXX" # Install necessary tool apt install -y jq # Get Access Token tokenUri="${identityEndpoint}?resource=${application_id_uri}&api-version=2019-08-01" accessToken=$(curl -s -H "Metadata: true" -H "X-IDENTITY-HEADER: $identityHeader" "$tokenUri" | jq -r '.access_token') echo "Access Token: $accessToken" # Run Trigger response=$(curl -s -o response.json -w "%{http_code}" -X GET "https://az-9640-myfa.azurewebsites.net/api/my_test_trigger" -H "Authorization: Bearer $accessToken") echo "HTTP Status Code: $response" echo "Response Body:" cat response.json 2.4. If everything is set up correctly, you should see a successful invocation result. 3. Invoke the Function App Trigger Using Web App (nodejs Example) I have also provide my example, which you can modify accordingly and save it to /home/site/wwwroot/callFunctionApp.js and run it cd /home/site/wwwroot/ vi callFunctionApp.js npm init -y npm install azure/identity axios node callFunctionApp.js // callFunctionApp.js const { DefaultAzureCredential } = require("@azure/identity"); const axios = require("axios"); async function callFunctionApp() { try { const applicationIdUri = "api://9c0012ad-XXXX-XXXX-XXXX-XXXXXXXXXXXX"; // Change here const credential = new DefaultAzureCredential(); console.log("Requesting token..."); const tokenResponse = await credential.getToken(applicationIdUri); if (!tokenResponse || !tokenResponse.token) { throw new Error("Failed to acquire access token"); } const accessToken = tokenResponse.token; console.log("Token acquired:", accessToken); const apiUrl = "https://az-9640-myfa.azurewebsites.net/api/my_test_trigger"; // Change here console.log("Calling the API now..."); const response = await axios.get(apiUrl, { headers: { Authorization: `Bearer ${accessToken}`, }, }); console.log("HTTP Status Code:", response.status); console.log("Response Body:", response.data); } catch (error) { console.error("Failed to call the function", error.response ? error.response.data : error.message); } } callFunctionApp(); Below is my execution result: 3. References Tutorial: Managed Identity to Invoke Azure Functions | Microsoft Learn How to Invoke Azure Function App with Managed Identity | by Krizzia 🤖 | Medium Configure Microsoft Entra authentication - Azure App Service | Microsoft Learn
Getting Started with Linux WebJobs on App Service
WebJobs Intro WebJobs is a feature of Azure App Service that enables you to run a program or script in the same instance as a web app. All app service plans support WebJobs. There's no extra cost to use WebJobs. This sample uses a Triggered (scheduled) WebJob to output the system time once every 15 minutes. Create Web App Before creating our WebJobs, we need to create an App Service webapp. If you already have an App Service Web App, skip to the next step Otherwise, in the portal, select App Services > Create > Web App. After following the create instructions and selecting a runtime stack (does not matter for this example…we’ll do a more in-depth sample later), create your App Service Web App. Next, we’ll add a basic WebJob to our app. Create WebJob Script Before we do anything else, let’s write our WebJob script. This will execute every time our WebJob is triggered. WebJobs on App Service can be run on a Triggered (Scheduled) basis or Continuously. This example uses a Triggered WebJob. Sample code below: #!/bin/bash # This script outputs the system time to the console # Get the current system time current_time=$(date) # Output the current time to console echo "Current system time: $current_time" Save this as webjob.sh, next we’ll upload it to the portal. Create WebJob in Portal Start by entering your Web App overview page. Then, under Settings select WebJobs. Here we can create and manage our App Service WebJobs for this Web App. Click Add to create a new WebJob. Now we can name our WebJob, upload our script from the previous step, and choose our execution type. Under Type, select Triggered. Under CRON Expression, enter the following to trigger our WebJob once every 15 minutes. 0 */15 * * * * Note: These are NCRONTAB expressions, not standard Linux CRONTAB expressions. An important distinction. Now click Create WebJob to finish making our new WebJob. Let’s test it out now. Run Manually or Scheduled To manually test our WebJob, we can click the play button under Run. A status of Completed means that WebJob is finished. Confirm Results in Logs We can check the logs to confirm that the system time was output to the console. While this is a basic example, WebJobs are a powerful and easy to use feature that have incredible utility for running scheduled (or continuous) actions in conjunction with your App Service Web Apps at no additional cost. Learn more about WebJobs on App ServiceHow to set up subdirectory Multisite in WordPress on Azure App Service
WordPress Multisite is a feature of WordPress that enables you to run and manage multiple WordPress websites using the same WordPress installation. Follow these steps to setup Multisite in your WordPress website on App Service...Introducing a new curriculum: Generative AI with JavaScript
Introducing a new curriculum: Generative AI with JavaScript TLDR; This course on Generative AI with JavaScript aims to take you through a series of 5 lessons so that you can integrate Generative AI in your JavaScript apps. You can use eithe GitHub Models or Azure Open AI, see setup section in below repo/curriculum To the curriculum Read more here, Introducing a new curriculum: Generative AI with JavaScript | Microsoft Community HubImplement App Service Best Practices into your Azure ARM/Bicep Templates with GitHub Copilot
If you’re using VS code and you’re not using GitHub Copilot yet, you should definitely check it out. GitHub Copilot is your AI pair programmer tool in Visual Studio Code. Get code suggestions as you type or use Inline Chat in the editor to write code faster. Add new functionality or resolve bugs across your project with Copilot Edits or use natural language in chat to explore your codebase. You can definitely do what we’ll be doing in this blog post without GitHub Copilot and instead use a different Copilot implementation or other AI tool altogether, but using GitHub Copilot directly where you’re writing your code and building your ARM/Bicep templates is a great way to make your process quicker and more efficient. In this blog post, we’ll be discussing how to implement best practices, when it comes your Azure App Service resource, into your Azure ARM/Bicep templates with GitHub Copilot. There’s two entry points to this blog post. The first is that you’re new to ARM/Bicep templates or App Service and you’re looking to learn App Service best practices as you start writing your templates. The second is that you’re already writing ARM/Bicep templates and you’re looking to improve your templates by implementing best practices that the product group recommends. If either of these entry points apply to you, then this blog post is for you. For those of you who are looking for a sample Bicep template that includes what the Azure App Service product group recommends as best practices, you can find that here. This is a recently released Azure Developer CLI (azd) template that you can quickly deploy into your own subscription to get started with an implementation of App Service that is secure, scalable, and performant. The template not only includes a sample web app and the suggested configurations for it, but also includes resources such as a slot, logging and monitoring, and more. We won’t be going through the template in this blog post, but I highly recommend checking it out if you’re looking to learn more about what a best practice implementation of App Service looks like. Getting Started To get started, we’ll be using GitHub Copilot to help us write and review our ARM/Bicep templates. If you’re not already using GitHub Copilot in VS Code, you can install it from the Visual Studio Code Marketplace. Once you have GitHub Copilot installed, you can start writing your ARM/Bicep templates and GitHub Copilot will provide you with suggestions as you type. If you’re new to ARM/Bicep templates, you can find more information on the Azure documentation site. Implementing App Service Best Practices using GitHub Copilot To implement App Service best practices into your ARM/Bicep templates, you can use GitHub Copilot to help you write and edit the code. GitHub Copilot will provide you with suggestions as you type, and you can use these suggestions to implement the best practices that the product group recommends. For example, if you’re creating an App Service resource, you can use GitHub Copilot to help you configure the resource with the recommended settings. You can also use GitHub Copilot to help you create other resources that are required for the App Service, such as a storage account or a database. GitHub Copilot chat is the feature we will use here. Just like how you would prompt ChatGPT or ask questions to a colleague, you can do the same with GitHub Copilot. Here’s an example of how you can use GitHub Copilot chat to implement App Service best practices into your ARM/Bicep templates: In order to set some context, I would recommend setting the stage with a statement like: Act as a cloud solutions architect and use the sample.bicep template from https://github.com/Azure-Samples/app-service-web-app-best-practice/blob/main/sample.bicep as your reference for best practices and Azure App Service product group recommendations for a secure, performant, and reliable web app. I’m going to ask you a series of questions to help transform my current bicep template into a template that follows best practices. In that statement, we asked GitHub Copliot to be a Cloud Solutions Architect (CSA) and use our new sample Bicep template as its reference for best practices and Azure App Service product group recommendations. Telling it to act as a CSA is a way to set the stage for the conversation and let GitHub Copilot know how to shape its responses. In the screenshot, you can see on the left-hand side that I have a basic Bicep template that creates an App Service Plan and an App Service. It definitely needs some work to follow best practices, and hopefully GitHub Copilot can help us with that. On the right-hand side, you can see the chat window where I’ve prompted GitHub Copilot. Some follow-up questions you can ask GitHub Copilot include: Can you help me configure the App Service Plan with the recommended settings? Can you help me configure the App Service with the recommended settings? What properties should I set on the App Service to make it secure? What other resources should I include in my template to make the App Service reliable and performant? If you ask GitHub Copilot these questions, it will provide you with suggestions as well as code snippets that you can directly implement into your templates. If you’re used to Git or are just a visual learner and want to see how exactly your template differs from the sample template, you can ask GitHub Copilot to create an HTML diff. For example, I asked GitHub Copilot the following after making some initial changes to my template based on its suggestions: Output a diff between my template and the sample.bicep template. The diff file should be an HTML file, it should be color coded, and it should show the differences between the two files side by side. It may take some additional prompting and follow-up on your side to get to this same state. But eventually, you should be able to get something as clear as the following: Continuing to build out your template should now be just as easy as working with a real-world CSA or product group expert. You can even ask GitHub Copilot questions about why it’s suggesting certain things, or ask it to explain the reasoning behind a certain best practice. This can help you learn more about the best practices and why they are important, so you can apply them to your own templates in the future. For example, you can ask GitHub Copilot: Why is it important to enable zoneRedundant property? What does it do? If you ask about zone redundancy, it will tell you what it is, why it’s important, and how to enable it in your template. If you’re unfamiliar with a property or feature, you can also just ask GitHub Copilot to explain it to you or take you to the product documentation. Conclusion In this blog post, we discussed how to implement best practices for Azure App Service into your ARM/Bicep templates using GitHub Copilot, without ever needing to leave VS Code. No more fumbling between browser tabs and product documentation - everything is in one place, right where you need it. If you’re new to ARM/Bicep templates or App Service, or if you’re looking to improve your templates by implementing best practices, I hope this blog post has been helpful to you. We’ll be continuing to release new blogs and documentation as our AI tools and services continue to improve, expand, and make all of our lives easier. Be on the lookout and thanks for reading!
