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

Showing content from https://learn.microsoft.com/en-us/azure/azure-functions/container-concepts below:

Linux container support in Azure Functions

When you plan and develop your individual functions to run in Azure Functions, you're typically focused on the code itself. Azure Functions makes it easy to deploy just your code project to a function app in Azure. When you deploy your project to a Linux function app, your code runs in a container that is created for you automatically and seamlessly integrates with Functions management tools.

Functions also supports containerized function app deployments. In a containerized deployment, you create your own function app instance in a local Docker container from a supported based image. You can then deploy this containerized function app to a hosting environment in Azure. Creating your own function app container lets you customize or otherwise control the immediate runtime environment of your function code.

Important

When you create your own containers, you're required to keep the base image of your container updated to the latest supported base image. Supported base images for Azure Functions are language-specific. See the Azure Functions base image repos.

The Functions team is committed to publishing monthly updates for these base images. Regular updates include the latest minor version updates and security fixes for both the Functions runtime and languages. You should regularly update your container from the latest base image and redeploy the updated version of your container. For more information, see Maintaining custom containers.

There are several options for hosting your containerized function apps in Azure:

The degree to which various features and behaviors of Azure Functions are supported when running your function app in a container depends on the container hosting option you choose.

1. On Container Apps, the default is 10 instances, but you can set the maximum number of replicas, which has an overall maximum of 1000. This setting is honored as long as there's enough cores quota available. When you create your function app from the Azure portal, you're limited to 300 instances.
2. In some regions, Linux apps on a Premium plan can scale to 100 instances. For more information, see the Premium plan article.
   
3. For specific limits for the various App Service plan options, see the App Service plan limits.
4. Requires KEDA; supported by most triggers. To learn which triggers support event-driven scaling, see Considerations for Container Apps hosting.
5. When the minimum number of replicas is set to zero, the default timeout depends on the specific triggers used in the app.
6. There's no maximum execution timeout duration enforced. However, the grace period given to a function execution is 60 minutes during scale in, and a grace period of 10 minutes is given during platform updates.
7. Requires the App Service plan be set to Always On. A grace period of 10 minutes is given during platform updates.

When creating your own containers, you're required to keep the base image of your container updated to the latest supported base image. Supported base images for Azure Functions are language-specific and are found in the Azure Functions base image repos.

The Functions team is committed to publishing monthly updates for these base images. Regular updates include the latest minor version updates and security fixes for both the Functions runtime and languages. You should regularly update your container from the latest base image and redeploy the updated version of your container.

Choose your base image based on the language stack you're using in your function app. The following table provides examples for each stack. In general, the tag should start with 4- to indicate the V4 Functions runtime. When new minor versions are released, this tag will be updated to point to the new version. As you periodically rebuild your custom image, you will pull the new versions through that same tag, allowing your app to have the same updates. You shouldn't use tags that specify minor runtime versions, as these will not receive updates, and your app will potentially remain on an unpatched version, no matter how often you rebuild your custom image.

(These examples target .NET 8. Select the appropriate image for the .NET version you need.)

(Support will end for the in-process model on November 10, 2026. You should migrate to the isolated worker model as soon as possible.)

(These examples target Java 21. Select the appropriate image for the Java version you need.)

(These examples target Node.js 22. Select the appropriate image for the Node.js version you need.)

(These examples target PowerShell 7.4. Select the appropriate image for the PowerShell version you need.)

(These examples target Python 3.12. Select the appropriate image for the Python version you need.)

Base images ending in -appservice enable SSH and remote debugging from the platform. Unless you need these capabilities, you can use the base images without the -appservice suffix.

Important

It isn't sufficient to just have one of the above tags in your Dockerfile. You need to regularly pull the latest image from that tag so that your custom image can be rebuilt to include the latest updates. If you don't pull the latest image and rebuild, your app will continue to run on the old base image.

When you create or deploy your own containerized app using a custom image, you're responsible for making sure that your custom image staying up-to-date with our released base images. In addition to new features and improvements, these base image updates can also include security updates that are critical for your app. To ensure your app is protected, make sure you're staying up to date. You should regularly pull the latest version of the base image, rebuild your custom container image, and redeploy your app to use it.

In some cases, we're required to make platform-level changes that could mean that an app in a custom container using an old base image might stop working properly. For such major changes, we roll out updated images well in advance so that apps that take regular updates aren't negatively impacted. To avoid potential problems with your apps running in custom containers, make sure you don't fall too far behind the latest minor version released. During a support case, should we determine that your app is experiencing problems because it's on an older or unsupported version, we do request that you update your container to the latest base image version before continuing with support.

Use these links to get started working with Azure Functions in Linux containers:

• Working with containers and Azure Functions

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

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

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