Azure Container Apps is the Microsoft solution for PaaS Kubernetes, abstracting away the Kubernetes layer to allow the user to focus on delivering their container-based applications. It’s a relatively new service, released last year, and has a few missing features or areas where things could be added. Over the last couple of months, there have been several announcements and updates for ACA that fix some of these, culminating in last week’s Build conference where we saw quite a few announcements. In this article, I wanted to bring all these new features together in one place so you can see how ACA has improved and whether any of your issues or concerns have been fixed.
This might be a small addition, but it makes using ACA significantly easier. Up till now, if you wanted a custom HTTPS domain for your containers you needed to upload your certificate, you couldn’t reference one from Key Vault or have MS create one for you. Now ACA supports managed certificates, so you can get a certificate from Microsoft, for free, automatically when you create a publicly accessible ingress in ACA.
ACA supports providing secrets to your containers, but up until now these needed to be added in the ACA configuration and they were only available as environment variables in the container. Recent changes mean that:
- You can now reference secrets directly from Azure Key Vault, they don’t need to be stored in your ACA config
- You can now attach secrets to your containers as volume mounts, as well as environment variables
More Details: Manage secrets in Azure Container Apps | Microsoft Learn
When ACA launched it only supported HTTP/S ingress types, so your non-HTTP applications were not supported. This is no longer the case, with the introduction of TCP support. This does require your ACA to be joined to a vNet to implement, but if you do that you can create an external, or internal, ingress that supports TCP traffic.
More Details: Ingress in Azure Container Apps | Microsoft Learn
At launch, ACA supported only long-running workloads, containers that you started and expected to stay running until you stopped the service, or if scaled them down. These are referred to as “Apps” in the ACA world. ACA jobs add support for containers running with a finite timespan and with some sort of schedule or trigger. Jobs can be triggered in 3 ways:
- Manually by creating a job and starting it through the UI, CLI etc.
- Scheduled - starting a job at a particular time, based on a CRON-like system
- Event Driven - use KEDA to have jobs triggered by events such as a message arriving on a queue
Jobs brings another facet of the Kubernetes world into ACA and should open up the use of ACA for more workloads.
About a month ago we saw the announcement of additional pricing plans for ACA and the introduction of a dedicated SKU. These new plans add a lot more flexibility around resource sizing and should allow a lot more workloads to move to ACA.
- The consumption plan is very similar to the existing plan type, but increases resources up to 4 vCPU’s and 8 GiB of memory
- The dedicated plan provides customer isolation and increases the resources up to 16 vCPU’s and 128 GiB of memory
Smaller Network Requirements
Alongside the release of the new plans, we also saw the network requirements reduced, when you want to attach ACA to a vNet. ACA now only requires a /27 subnet. ACA also now supports locked-down subnets, user-defined routes and Azure Firewall.
At Build we saw another new feature for ACA, addons. Addons allow you to deploy some common container-based applications as Microsoft curated and configured for scale to zero and with storage attached. At the initial release, there are addons for Redis and PostgreSQL. These add-ons are being aimed at development workloads, so shouldn’t be used for production.
Support for Functions and Spring Applications
ACA now supports running Azure Functions and Azure Spring Apps on ACA. If you don’t want to use the serverless approach, or perhaps your function doesn’t fit inside the constraints of the functions service, then you can run these as containers on ACA. This has full support for all the ACA features like auto-scaling and ingress.
More Details: Azure Functions for Cloud-native Microservices: Public Preview Launch - Microsoft Community Hub and and Unleash Spring apps in a flex environment with Azure Spring Apps Consumption and Dedicated plans - Microsoft Community Hub
Support for Init Containers
ACA now supports init containers, allowing you to run a workload before the launch of your main container. This can allow you to do some initialization work such as downloading files or preparing your environment.
More Details: Containers in Azure Container Apps | Microsoft Learn