[Question] Aspire - Deploy To Existing RG/Container Env

[bakes82]

• Make sure you've installed the latest version using instructions in the wiki

Output from azd version
Run azd version and copy and paste the output here:
azd version 1.9.3 (commit e162433)

Additional context
Is there a way to use azd deploy/etc to push an aspire app to an existing RG/ContainerE Eng/Reg? Our org has numerous policies so a direct azd up fails due to missing tags and what not. AZD Up works great to my VS Enterprise Subscription, I see there is azd package but that doesnt seem to output anything when I run it.

2024/06/20 22:32:31 hooks.go:143: service 'apiservice' does not require any command hooks.
2024/06/20 22:32:31 hooks.go:143: service 'imageresizerworker' does not require any command hooks.
2024/06/20 22:32:31 hooks.go:143: service 'webfrontend' does not require any command hooks.
2024/06/20 22:32:31 hooks.go:78: azd project is not available or does not contain any command hooks, skipping command hook registrations.

Packaging services (azd package)

2024/06/20 22:32:31 command_runner.go:307: Run exec: 'dotnet --version' , exit code: 0
Additional env:
   DOTNET_CLI_WORKLOAD_UPDATE_NOTIFY_DISABLE=<redacted>
-------------------------------------stdout-------------------------------------------
8.0.106
2024/06/20 22:32:31 dotnet.go:84: dotnet version: 8.0.106
2024/06/20 22:32:31 ensure.go:47: Skipping install check for '.NET CLI'. It was previously confirmed.

SUCCESS: Your application was packaged for Azure in less than a second.

[rajeshkamal5050]

@vhvb1989 @ellismg do we support deploying to existing rg/container for aspire?

[vhvb1989]

@bakes82 , in theory you can do it, but it is all a very manual process. Azd doesn't have an out-of-the-box feature to cover this scenario for you.

Here's what you can try:

• Run azd infra synth from your Aspire project (you might need to enable the infra synth alpha-feature if you haven't done it before with azd config set alpha.infra.synth on)
• Azd will generate all the infrastructure as code inside an infra folder. Find the main.parameters.json and update that file setting a value for the environmentName. Use a name which you would remember later, like

      "environmentName": {
        "value": "name-to-remember"
      },

• Now give the bicep files and parameters files to your IT team and ask them to deploy it. All the requirered components and tags are defined there the way azd will expected to be to find the resources.
• Once they have deploy it, run azd env new name-to-remember to create azd-environment with the name you choose before.
• Then run azd env refresh to sync azd with the infrastructure. azd will ask you about the Subscription and Location where your IT deployed the infrastructure. And then it will find the rg and expected outputs required for deployment.
• Now you can run azd deploy and it should in theory work :)

[bakes82]

/unresolve

Your response is to still generate a new RG and entities. My question is to deploy to existing infrastructure, why would I need to spin up another container registry, rg, and container environment for every aspire application I create? The org I'm in doesn't work like that nor does it really follow MS best practices. Why can't I tell aspire to use existing resources, as long as I have the permissions needed there should be 0 issues correct? The 1x per aspire application doesn't seem logical epically in larger organizations where we have numerous azure policies in place that require certain "standards" for resources, so your generated infra doesn't align with what "our" standard is. Now if you want to say aspire isn't geared toward production/enterprise use then make that known.

[vhvb1989]

Now if you want to say aspire isn't geared toward production/enterprise use then make that known.

I know Aspire is still bringing new features and better experiences for all scenarios, including production/enterprise. You can follow their latest work from https://github.com/dotnet/aspire.

For deploying Aspire projects with Azd, it is common to expect developers to run azd up to create the infrastructure defined by Aspire AppHost and then each service as an Azure Container App. You can then delete all the infrastructure if you don't need it anymore with azd down. But it is unlikely to think about using the same infrastructure (rg + all resources in there) to deploy a different Aspire project. A different Aspire project might be defining another set of resources and services, which would not be compatible with the existing infra. Let me know if this is what you are trying to do or if there's something else.

The manual instructions I shared before are meant for a world where a user is not allowed to create new resources in the Azure subscription, and they need to ask their company to create resources.

[bakes82]

But it is unlikely to think about using the same infrastructure (rg + all resources in there) to deploy a different Aspire project.

Really, you think people don't use shared key vaults, shared sql databases, storage accounts etc across multiple applications? (Note: some resources like Azure Open AI are also heavily limited so its not like I can just spin one up per aspire application) Who says I'm even using aspire to generate those resources? Aspire lets you use preexisting resources, I don't need 15 container registries to push dockers in to when I can have 1 per app team, nor do you need 15 AKS clusters/container environments. One key benefit to aspire is the centralized registration of services and the ability for the deployment to push out the variables required on deployments for each docker. I don't see any reason an AZD Environment cant be an existing RG/Registry and the azd up command would still work using a shared container registry and aks/container app. Clearly, we can do it manually. At the end of the day its still using basic dot net commands and the generated yaml file.

The issue seems to be on the AZD side and allowing for easy creation of environments that use existing resources, it seems like you just need to take in a RG/Container Registry/AKS/Container App/Managed Identity (optional?) based on what I see this sample yaml. In my aspire app, Im only using pre-existing resources so I just want it to do the image creation and container creation/deployment.

api-version: 2024-02-02-preview
location: {{ .Env.AZURE_LOCATION }}
identity:
  type: UserAssigned
  userAssignedIdentities:
    ? "{{ .Env.AZURE_CONTAINER_REGISTRY_MANAGED_IDENTITY_ID }}"
    : {}
properties:
  environmentId: {{ .Env.AZURE_CONTAINER_APPS_ENVIRONMENT_ID }}
  configuration:
    activeRevisionsMode: single
    runtime:
      dotnet:
        autoConfigureDataProtection: true
    ingress:
      external: true
      targetPort: {{ targetPortOrDefault 8080 }}
      transport: http
      allowInsecure: false
    registries:
      - server: {{ .Env.AZURE_CONTAINER_REGISTRY_ENDPOINT }}
        identity: {{ .Env.AZURE_CONTAINER_REGISTRY_MANAGED_IDENTITY_ID }}
    secrets:
      - name: connectionstrings--testsbconnectionstring
        value: '{{ securedParameter "TestSBConnectionString" }}'
      - name: connectionstrings--teststorageconnectionstring
        value: '{{ securedParameter "TestStorageConnectionString" }}'
      - name: connectionstrings--openaiconnectionname
        value: '{{ securedParameter "openAiConnectionName" }}'
  template:
    containers:
      - image: {{ .Image }}
        name: webfrontend
        env:
          - name: AZURE_CLIENT_ID
            value: {{ .Env.MANAGED_IDENTITY_CLIENT_ID }}
          - name: ASPNETCORE_FORWARDEDHEADERS_ENABLED
            value: "true"
          - name: AZURE_EXPERIMENTAL_ENABLE_ACTIVITY_SOURCE
            value: "true"
          - name: OTEL_DOTNET_EXPERIMENTAL_OTLP_EMIT_EVENT_LOG_ATTRIBUTES
            value: "true"
          - name: OTEL_DOTNET_EXPERIMENTAL_OTLP_EMIT_EXCEPTION_LOG_ATTRIBUTES
            value: "true"
          - name: OTEL_DOTNET_EXPERIMENTAL_OTLP_RETRY
            value: in_memory
          - name: services__apiservice__http__0
            value: http://apiservice.internal.{{ .Env.AZURE_CONTAINER_APPS_ENVIRONMENT_DEFAULT_DOMAIN }}
          - name: services__apiservice__https__0
            value: https://apiservice.internal.{{ .Env.AZURE_CONTAINER_APPS_ENVIRONMENT_DEFAULT_DOMAIN }}
          - name: ConnectionStrings__TestSBConnectionString
            secretRef: connectionstrings--testsbconnectionstring
          - name: ConnectionStrings__TestStorageConnectionString
            secretRef: connectionstrings--teststorageconnectionstring
          - name: ConnectionStrings__openAiConnectionName
            secretRef: connectionstrings--openaiconnectionname
    scale:
      minReplicas: 1
tags:
  azd-service-name: webfrontend
  aspire-resource-name: webfrontend

[vhvb1989]

Yeah, you can use builder.AddConnectionString("openai") (see this) . AddConnectionString lets you bring your existing resources into the AppHost. It is common to see SQL servers, OpenAI, key vaults, etc.

Another alternative for bringing your existing infrastructure is by using AddBicepTemplate. You can define your own bicep module which uses the existing keyword to reference and use existing resources.

However, from Aspire <= 8.0.2, you can't (yet) define/re-use existing hosting-components for your services (rg, managedIdentity, containerRegistry, container Environment). The current option for this advanced scenario is using infra synth and letting customer to take fully control on the infrastructure files (bicep).

You can manually update the resources.bicep created by azd to use existing hosting-components.

I am not sure if the current work-in-progress changes to allow customers configure the hosting-components from the appHost is considering allowing customer to reference existing resources instead of always-create. @mitchdenny @ellismg would know better there.

From my POV, it makes sense to think about a matching one-to-one relation between one Aspire AppHost and one set of hosting-components only. Specially on Production. I wouldn't expect one Aspire Project to have access to one container registry which has images for multiple projects; that might be seen as a security concern. The same way for the container environment, which provides the network and Aspire dashboard for your services. It's hard to think using one only Container Environment for multiple projects. But this 100% a question Aspire to answer

[bakes82]

Yeah, you can use builder.AddConnectionString("openai") (see this) . AddConnectionString lets you bring your existing resources into the AppHost. It is common to see SQL servers, OpenAI, key vaults, etc.

Yes Im aware..... this is my point I can create an aspire application w/out any need for new resources.

Specially on Production. I wouldn't expect one Aspire Project to have access to one container registry which has images for multiple projects; that might be seen as a security concern.

Im not seeing the security concern here, maybe we just split our code base into multiple solutions. There are also limits to the number of container registrations per subscription, while I know these can be increased dosent mean its logical. We tend to have sprawling applications. Last check I we had over 1200 function apps, so are you saying if they were aspire applications instead, we should have 1200 container registries ;) Some reusability tends to make sense to me.

[mitchdenny]

@bakes82 on the Aspire side we are looking at ways where we can shift more of the control of the auxiliary resources that Aspire relies on into the application model to allow for this kind of flexibility. The current behavior of azd is partially a side effect of the fact that we haven't completed that work yet.

In time we hope to deliver greater flexibility here, and when that happens azd won't need to create as many resources on our behalf and you can tweak it however you like.

Here is a PR were we've been doing some experimentation along these lines on the Aspire side:

dotnet/aspire#2965

We aren't there yet though. Here is a related issue on the azd side:

#3292