Usage of an http/https proxy

[radenui]

Hi,

The host machines do not access the internet directly, but through an http/https proxy into my infrastructure: I'd like to be able to use it!
I tried to write :
HTTP_PROXY=http://proxyaddress:proxyport
HTTPS_PROXY=http://proxyaddress:proxyport
NO_PROXY=169.254.169.254
into /etc/ecs/ecs.config (as I believe it should work ?), but had no success so far.

Is is a feature you intend to implement ?

Thanks,

Arthur

[euank]

Currently it doesn’t work for two reasons:

1. The service client used does not use the default http client. This will be resolved when we migrate to using the official aws go sdk.
2. Our services relies on communicating over a websocket, and the library we use for that does not support http proxying. It’s also possible your proxy would not support websockets either.

You might be able to use other networking, such as a vpn, to accomplish this lower down the network stack.

We do not currently have plans to implement proxying for the websocket connection within our application in the short term.

I would like to hear a little more about your proxying setup though, such as if it would support a websocket connection or if a vpn could potentially work.

Best,
Euan

[radenui]

Thanks for your answer.

As a matter of fact, some of the services I intend to deploy will not be internet facing, and the instances will be in private subnets.
When they have to connect the internet (let's say for an AWS API Call), they use an http/https squid proxy into the environment. This one is made highly available by the use of an ELB and multiple instances running squid attached to this ELB.

As I understand it (I may be wrong), the ECS agent performs a call to an https AWS endpoint for ecs. The fact that it uses websocket is probably the must difficult point here.
Of course I'd like to leverage the same infrastructure I already have in place.

I've read in many websites that websockets works over an https connection on squid.

So should I do the same request (proxy support) on the gorilla/websocket project ?

Thanks,
Arthur

[euank]

If the Gorilla authors want to integrate proxy support I'd be happy to consume it.

However, even if they don't, it could probably be implemented within the agent's code by passing in a proxying dialer to the websocket connection.

I'll leave this issue open as a feature request and welcome any further information or questions.

[radenui]

Thanks Euan, this will be a great improvement!
FYI, I managed to configure docker itself so it can use a proxy by adding the export commands into the /etc/sysconfig/docker file.

[damnhandy]

@radenui were you able to get the ECS Agent to register with the cluster? I've been able to get everything running, but the agent simply can't register with the cluster due to our proxy.

[radenui]

@damnhandy Unfortunately no, I had to connect the internet directly or through a NAT instance, as far as I know proxy is not yet usable. I hope this will be soon available!

[sathiyas]

Hello Team, is this supported yet?

[euank]

Unfortunately, it's still not supported. The registration part should work now since the above-referenced sdk migration has been completed, but the websocket connection, required for running any tasks, does not respect proxy settings. As far as I know, the websocket connection's dial is the only part left that doesn't handle proxy settings.

I'll update this issue with any changes.

[sathiyas]

Folks, is this Proxy support available now?

[euank]

Still not available, but getting closer! We've got it merged into the dev branch, which means it should be in the next release. You're also welcome to build the dev branch and try it out.

Best,
Euan

[wolfeidau]

Proxy support is now supported in the upstream library, I was hoping this would save you doing work on this but it seems to have also been done in the agent itself.

If I can help with integration I am happy to pitch in.

[euank]

We've released agent version v1.6.0 which adds support for proxies via #211.

We appreciate that you added support upstream @wolfeidau, and I think it'd be awesome to switch since it makes more sense to be maintained there I think.

Since this issue is about the feature, not implementation, I've opened a separate issue, #239, to track that and am resolving this.
Best,
Euan