Bicep/ARM: container apps, managed identities and templates

[basilfx]

Situation

We're investigating the use of Azure Container Apps.

Using Azure Pipelines, our current deployment flow looks something like this:

1. A Bicep/ARM template (incrementally) deploys to a resource group. This creates/updates the service plan, function app (slot), web apps, databases and so forth.
2. Additional scripts perform database migrations, set-up secrets, create service bus subscriptions and so forth.
3. The actual code is deployed, e.g using a ZIP deploy.

Step 2 is necessary before code actually runs. Step 1 does not have any consequences, for incremental deployments without any changes.

This is how we deploy Azure Function Apps and Azure Web Apps.

Updating containers

With Azure Container Apps, we run into the issue that we have to provide a template section (in the deployment template). This implies that we have to specify an image to run. That is something we want to do in step 3.

When I leave out the template section, I run into an error like 'Must specify at least one container to create a container app.' When I specify a (default) container, the running app gets replaced during step 1. That is something I don't want.

A work-around is to use a separate resource deployment to deploy the container app. This makes such simple use-cases unnecessarily complex and splits the deployment into multiple steps, and foces us to use a user-assigned identity (see below).

This seems to be somewhat related to this issue.

Managed identities

I want to use a system-assigned identity to pull the image from an Azure Container Registry. The creation of the Azure Container App fails, if the image cannot be pulled from a container registry during creation. The role assignment for 'AcrPull' (in the same template) depends on the system-assigned identity, so we run in a chicken-egg situation.

Again, this would not be an issue if I could deploy without a container.

A work-around is to create a user-assigned identity first, but that seems to defeat the purpose of the system-assigned identity and makes such simple use-cases unnecessarily complex.

This problem is also described here.

Question

Given the above situation, are there any ways to improve our (intended) deployment flow of Azure Container Apps?

To me, the above scenarios are common, and especially for Azure Function Apps and Azure Web Apps. Teams using these will definitely encounter similar issues, when investigating Azure Container Apps.