Dapr - Local Service Invocation agains Service in Azure Container App

[manic frigate]

Hello Dapr community!

We are trying to use Dapr to manage our microservices deployed as Azure Container Apps. On Azure , everything works fine, but we are wondering what is the preffered way to achieve local testing of a new service that will be calling all other services (ideally via Service Invocation), deployed in different Dapr environment, on Azure Cloud (Container App)?

What I have already tried (unsucessfully):

• I tried to create Dapr client connected to remote endpoint "DaprClientBuilder().UseHttpEndpoint(AzureContainerAppEndoint:3500)"
• I tried to create routing component middleware, but If I understand it correctly, the component works just in one way (non-dapr URL -> DAPR url) and I would need the exact opposite.

Right now, the only solution that comes to my mind is to override the DaprClient in C# and use normal HTTPClient and normal URLS when in local development enviroment. But this means writing custom C# code for local development...

Any suggestions would be greatly appreciated!

Thak you! 🙂

[amber marlin]

Instead, set up a Container App Test Environment where you deploy and test everything. Do not use local testing for this.

You can develop your app locally and use the same Dapr version (1.12.5) to do some development locally, but ultimately only Container Apps itself can be used to test and simulate container apps.

The Dapr sidecars in Container Apps cannot be exposed externally, so you cannot perform service invocation against sidecars in Container Apps.

[manic frigate]

Thank you for this explanation! I was suspecting the service invocation will not work in this scenario, but I wasn't sure. Thak you very much again! 🙂

Well we will try to setup the container development environment, but since you canno't do a remote debugging in Visual Studio to an Container App (no breakpointes etc) I think we will ultimatelly go the non-dapr http calls "httpclient-extension" for local development..

Thank you again, have a nice day! 🙂

[peak pasture]

It’s a real shame there isn’t an equivalent of “Bridge 2 Kubernetes” for ACA, as this offers a brilliant development experience.

Unless I’m just not aware of that solution existing?

[manic frigate]

Well yes 🙂 We spent like 60 hours already ,with my colleaguje to get dapr running + to achieve this local development scenario. And honestly - I found the documentation kinda confusing about this - there is loads of topics about local development, but none of them explains directly you cann't mix different dapr environments (this is NOT clear from the begining and its nowhere to be found and from the pictures everywhere it sometimes seems you actually can mix them) ..

Yes, good point with the Kubernetes cluster ... of course I have been thinking about using Kubernetes, but we would use Kubernetes only for the sole purpose of enabling local develpment with debugger 🙂 This is something that would bring more unnecessary complexity...

But I will just develop (team internal) nuget package that will solve this - override DaprClient, that you can initialie with key - value string pairs, the key will be DaprServiceName, value will be non-dapr full qualified http endpoint (of that service). I will then override all Invoke.. methods so they would use dapr client on azure (non development env.) and on local environment, if the invoked service is found in the input key, then normal HTTPClient will be constructed an used instead (inside DaprClient instance).

Anyway, I needed to reassure I am not missing something right under my nose before I go to implement this, which appareantly I am not 🙂

P.S.: This whole discussion will be obsolete in the moment dear Microsoft will finish remote debugging in ACA (https://github.com/microsoft/azure-container-apps/issues/632)

Thank you and ..
Have a nice day 🙂

[proven python]

I wonder if you could also just standup an extra Dapr sidecar on the local machine, but redirect it to your ACA-deployed application using the --app-channel-address argument? Your local application would then still talk to its local Dapr sidecar as normal, but service invocations will then flow through the ACA "proxy" sidecar and then onto the ACA application. (This assumes your ACA application exposes a public endpoint, of course, but that's assumed already with your option to swap DaprClient with HttpClient.)

[amber marlin]

Yes you could do that, although it wouldn't load ANY of the components configured / deployed in ACA.. and if those components are authenticated using managed identity and you don't have the credentials.. then you cannot use those particular components locally.
Ideally of course you use local replacements for the same components.

[proven python]

Right, I was looking at it strictly from a service invocation perspective.

[amber marlin]

And it's worth noting that the HTTPEndpoint resource type doesn't exist in ACA - so that will not come into play here.

[manic frigate]

Thank you, I will try the --app-channel-address parametr and let you know!!

(EDIT: We have already tried DaprClientBuilder().UseHttpEndpoint() during our research .. we were able to connect to second local virtual machine and use its remote dapr sidecar, but this did not work in ACA .. maybe there was some privacy / networking issue, but we kinda tried to lift all restricions, enable public access etc and still nothing. Isn't this --app-channel-address just commandline argument for the same functionality?)

Those components might not be a problem, because components work totaly fine on my local setup binded to azure portal (we are using azure keyvaults components mainly) - or are you suggesting when we use the remote sidecar then those components will be loaded from the remote DAPR environment as well ? (we definitely do not want this, we want to use local components)

[manic frigate]

Please can you clarify what this means? Does this, by any chance means, the DAPR App deployed in ACA does not expose the DAPR style rest http endpoint, aka "v1.0/invoke/xxx/method/yyy" ?

I was not able to get this DAPR rest endpoint to work for our ACA apps 🙂 At first I though the DAPR was not initialized correctly in ACA. That was also super confusing and not easy to learn this is just normal behavior in ACA.

P.S.: This is of course nothing crucial for us, just asking 🙂 Thank you!