Customizing ContainerApp name with dotnet aspire and alpha.aspire.useBicepForContainerApps

[IoBebe]

My Context

I'm exploring dotnet aspire and azd. My current focus is applying a specific naming conventions.
I'm stuck at customizing the Name of the Microsoft.App/containerApps resource.

Problem

Digging around I've found the alpha.aspire.useBicepForContainerApps (AZD side) and the .PublishAsAzureContainerApp (aspire side).
I've figured out how it generally works, I've customized the bicep template for the Microsoft.App/containerApps resources, I've hooked it up to AZD and managed to provision the resources correctly.

However, I can't azd deploy properly because azd is still looking for the Microsoft.App/containerApps resource based on the friendly "service name" from the dotnet aspire orchestration and the manifest.json file.

Question

@ellismg
Assuming I'm doing the following on the Dotnet Aspire side:

.PublishAsAzureContainerApp((infra, containerApp) =>
{
    containerApp.Name = "phb-backend-euw-dev-ca-01";
})

Shouldn't the azd side use targetResource.Name be used instead of serviceConfig.Name in this segment here:

	containerAppTarget := environment.NewTargetResource(
		targetResource.SubscriptionId(),
		targetResource.ResourceGroupName(),
		serviceConfig.Name,
		string(azapi.AzureResourceTypeContainerApp))

from: https://github.com/Azure/azure-dev/blob/c5afa7de6b263e9a5992e85d0940294c611bd70a/cli/azd/pkg/project/service_target_dotnet_containerapp.go#L419

Repro

Aspire version: <Sdk Name="Aspire.AppHost.Sdk" Version="9.0.0-rc.1.24511.1" />
Azd version: azd version 1.10.3 (commit 0595f33fe948ee6df3da492567e3e7943cb9a733)

I've ran: azd deploy phone-book-api --debug

** The Deployment Result in Azure:

The Error I'm getting: azd deploy output.txt

(I've included the pooling for the deployment result of the Container App. You can see that the deployment names match

[vhvb1989]

Hello @IoBebe , you don't actually need alpha.aspire.useBicepForContainerApps. This alpha feature should not exist anymore in azd (you should not see it if you run azd config list-alpha)

All you need is dotnet9, which I think you already have.

After that, you are actually facing a bug in azd. I've started a fix for it. Thank you for starting the conversation. I've created this issue: #4489

[IoBebe]

Does that mean that the values of the ENV VARS used by the ASPIRE middleware (services__[serviceName]__https__0) get computed by string concatenation at AZD deploy time not taking in the AZD provision output ?

Come to think of it the current bicep templates used to create the Container Apps have no output parameters, so I don't see how those values could be used further by AZD.

Wouldn't a postdeploy hook in azd to change the ENV VARS of the Contaienr App fix it ? (az containerapp update ... --set-env-vars)

[davidfowl]

Does that mean that the values of the ENV VARS used by the ASPIRE middleware (services__[serviceName]__https__0) get computed by string concatenation at AZD deploy time not taking in the AZD provision output ?

That's correct (ish). There's no provisioning dependency between individual service deployments today. Each service depends on the provisioning phase but not each other's deployment phase.

Come to think of it the current bicep templates used to create the Container Apps have no output parameters, so I don't see how those values could be used further by AZD.

Wouldn't a postdeploy hook in azd to change the ENV VARS of the Contaienr App fix it ? (az containerapp update ... --set-env-vars)

Are you asking if you can fix it in your own deployment? You could also update all of the references to the hardcoded resource references in the bicep.

[IoBebe]

Thanks for confirming. I really appreciate it.

Are you asking if you can fix it in your own deployment? You could also update all of the references to the hardcoded resource references in the bicep.

More or less. Seems as though it should be possible to just update the ENV VARS of the Container Apps through the deployment. Seems more reasonable, because Resource names in Azure is a deployment aspect and friendly names in the Aspire orchestration is a design/readability aspect. I'll have to try it, when the PR comes through.
I could change the friendly resource name too. But given the fact that there will be multiple envs (DTAP) and I have the environment name in the damned naming convention, it will turn into a mess.

OR, I could just tell IT: NO. And not respect their naming conventions for the Container Apps.. Since it seems I'm straying further and further away from the desired Aspire + AZD path.

Which begs the following question: is there an intention/desire to allow full customization of the Container App deployment while using the Aspire "opinionated" framework ? @davidfowl

[davidfowl]

OR, I could just tell IT: NO. And not respect their naming conventions for the Container Apps.. Since it seems I'm straying further and further away from the desired Aspire + AZD path.

👍🏾. This is the way 😉. We can potentially handle this situation with an extensibility point if it becomes a pattern. It bleeds into the infrastructure, DevOps, SRE domain so anything we can do to smooth that over we'll look into.

Which begs the following question: is there an intention/desire to allow full customization of the Container App deployment while using the Aspire "opinionated" framework ?

Yes, that's why we're enabling customizing the container app from c#.

[IoBebe]

this is the way !