dotnet / aspire

Tools, templates, and packages to accelerate building observable, production-ready apps
https://learn.microsoft.com/dotnet/aspire
MIT License
3.83k stars 457 forks source link

Using WithEnvironment after dapr doesn't work #1553

Closed bit365 closed 10 months ago

bit365 commented 10 months ago

I need to reference an environment variable in Dapr's component configuration file, but after using the following code, I cannot get the variable in the dapr sidecar.

var apiServiceSidecar = builder.AddProject<Projects.AspireApp_ApiService>("apiservice")
    .WithDaprSidecar(new DaprSidecarOptions
    {
        AppId = "apiservice",
        DaprGrpcPort = 50001,
        DaprHttpPort = 3500,
        ResourcesPaths = ["./components"],
    }).WithEnvironment("testtesttesttesttesttesttest", "testvalue");

For example, the secretstores.local.env component in dapr obtains values ​​from environment variables.

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: env-secret-store
spec:
  type: secretstores.local.env
  version: v1
apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: mqtt-pubsub
spec:
  type: pubsub.mqtt3
  version: v1
  metadata:
    - name: url
      secretKeyRef:
        name: testtesttesttesttesttesttest
auth:
  secretStore: env-secret-store

Unable to extract value from testtesttesttesttesttesttest

philliphoff commented 10 months ago

The WithEnvironment() applies to the project resource and not the sidecar. That is, WithEnvironment() returns the original project resource builder; the sidecar is not a resource in its own right. My first thought is that the DaprSidecarOptions should have an Environment property on which to set sidecar-specific variables. This would be similar to how Dapr run files work.

An argument could be made that the sidecar should itself be a resource that is simply referenced by the project resource, in which case it could then use common resource annotations (such as WithEnvironment()). It wasn't modeled that way originally because of the tight 1:1 relationship between a sidecar and a project. If it were a resource, the sidecar could end up referenced by multiple resources, which would be semantically invalid.

GFlisch commented 10 months ago

We need to have this functionality and I agree having the SideCar has a resource will be more consistent. The reason why environment must be supported is to support the https://docs.dapr.io/reference/components-reference/supported-secret-stores/envvar-secret-store/ scenario.