search

ib-api-reloaded / ib_async

Python sync/async framework for Interactive Brokers API (replaces ib_insync)
BSD 2-Clause "Simplified" License
453 stars 72 forks source link

[enhancement] Support socks5/http proxy for cloud deployment #9

Open rayli09 opened 6 months ago

rayli09 commented 6 months ago

Context

I'm trying to figure out deploying the gateway and my app logic to the cloud using container runtimes, yet it has this annoying problem of not having /dev/net/tun devices by nature. I explored a bit and decided to go with tailscale to setup a private network to connect my services.

Next, when I tested the connectivity, I realized that ib_async does not support socks5/http proxy, which is a blocker in my deployment setup.

Proposed solutions

1/ am I on the right approach? I figured we need the proxy in order to work with the container runtime instead of dealing with VMs directly. This leads to several options aiosocks The whole motivation of me dealing with all these is to have a separate production environment for live trading and without the hustle of managing complex infrastructure involving k8s or bare metal VMs. I could focus on strategy development, and has CI/CD pipeline that continuously ships it and deploys the algorithm.

Would love to get some insights and advices from the experts :)

gnzsnz commented 6 months ago

@rl3250 what's your rationale to integrate this on ib_async.

if you need it you can integrate it on your code base. why this should be part of ib_async?

mattsta commented 6 months ago

I realized that ib_async does not support socks5/http proxy,

Yeah, it expects to connect to a TWS or gateway instance directly on an open TCP gateway port.

If you are already using tailscale, you have a VPN setup, so you should be able to connect to the remote IBKR gateway directly inside the VPN itself? You would just need to reconfigure the gateway settings to listen on a VPN network IP instead of localhost. No extra proxies or ssh tunnels should be needed.

Also worth remembering: the IBKR gateway program isn't written to be a "set it and forget it" background service. It often hangs or has mid-week crashes or requires manual restarts for various reason.

It's usually safer to run the gateway on the same localhost server as your actual API code itself so you have more access to restart things all in one place when problems happen.