Dapr: Support for http proxy for local development

[javageek79]

In what area(s)?

/area runtime
/area placement

/area operator
/area docs
/area test-and-release

Ask your question here

On our local dev environment, we are working behind a corporate proxy. For accessing internet resources all traffic need to get passed through this proxy.
If we need to connect azure service bus for example, we have an outgoing connection to the internet where we need the proxy set.

When using reactor.netty.http.client.HttpClient for example, we need to configure a proxy like this

String host = System.getProperty("http.proxyHost");
String port = System.getProperty("http.proxyPort");

HttpClient
  .create()
  .tcpConfiguration(tcpClient ->tcpClient.proxy(proxy -> {
      proxy.type(ProxyProvider.Proxy.HTTP).address(new InetSocketAddress(host, Integer.valueOf(port)));
  })
  .option(ChannelOption.CONNECT_TIMEOUT_MILLIS, TIMEOUT));

Is it possible with dapr to also configure local env to also use that proxy?

What we tried was passing the proxy as an env variable to both local running dapr container.

That did not seem to work.

[RicardoNiepel]

One of Dapr’s value propositions is, that the Dapr components unterneath can change between different environments without any application changes.

This is a good example on how Dapr can help have the dev environment to work even when connectivity to the cloud is restricted, e.g. by a required corporate proxy.
Using a corporate proxy is also not possible if you are using a component which does not operate over HTTP, e.q. SQL Server.

For local development Dapr installs Redis for Pub/Sub and as State store.
Using Dapr allows you to target a local dev environment locally and then bind it to other components in the cloud, e.g. Azure Service Bus in your situation.

[artursouza]

Is this issue still applicable? The idea is for Dapr to abstract the underlying component being used - the fact that there is connectivity restriction is a good example of when developer can user dapr to develop using local components only (Redis, for example).

[jjcollinge]

I think this a fairly common restriction people are going hit. Having a documented way to work with external HTTPS proxies would be valuable. Using the local components (redis etc.) is a valid workaround but won’t help somebody who is trying to locally debug dapr itself or when someone uses a standalone deployment (i.e the dapr workload is deployed on a corporate network) with external integrations and its not just their dev environment.

[msfussell]

This is out of scope for Dapr.