piker icon indicating copy to clipboard operation
piker copied to clipboard

Roll a `pikerized` `ib-gw` container, probably on `nixos`

Open goodboy opened this issue 3 years ago • 2 comments
trafficstars

Initial draft / POC was in #322 but more or less we need our own image likely built as:

  • nixOS so as to (mostly) avoid stupid dockerfile DSL syntax (in exchange for stupid nixos DSL syntax)
  • way more minimal deps set then the original ubuntu image
  • probably not docker-compose and just spin up the container via our ._ahab.py super
  • better image support for windows (see below)
  • sshd for distributed deployments and rsyscall support
  • use these nixpkgs for ib shite instead of installing from source as in the orig image: https://github.com/NixOS/nixpkgs/tree/master/pkgs/applications/office/ib

TODO: container config

  • ip rule add not unicast iif lo to 0.0.0.0/0 dport 4002 to filter public ip TCP connects at the OS layer (stateless firewall approach)
  • [ ] figure out why the vnc auth still doesn't seem to be working?!?
  • [ ] automate the equivalent docker-compose steps using our .data._ahab supervisor system
    • [ ] allow for API socket mapping to just be pulled direct from a user's brokers.toml and we'll just pass that direct to IBC's config and do the same for any other embedded services (sshd, ib-gw, x11vnc, etc.)

TODO: windows support (maybe?)

For extra lolz, you can't use --net=host on windows as per:

  • https://docs.docker.com/network/host/

    The host networking driver only works on Linux hosts, and is not supported on Docker Desktop for Mac, Docker Desktop for Windows, or Docker EE for Windows Server.

So that means we'll need to:

  • [ ] either go back to the socat stuff from the original container from waytrade
  • [ ] use a bridge network inside the container namespace and do sensible routing table to map the necessary vnc and gw ports

goodboy avatar Jun 05 '22 00:06 goodboy

Further discussion with IBC peeps over in https://github.com/IbcAlpha/IBC/issues/67

goodboy avatar Jun 16 '22 20:06 goodboy

Bleh, just ran into this issue oddly (though i swear this was working before?!?)

More or less summarized best in this forum issue: https://groups.io/g/insync/topic/7424102?20,0,0,0::,,,0,0,0,7424102

Basically if you have a local app of the ib-gw running and a dockerized version (a least in its current form) you'll always hit a Trading TWS session is connected from a different IP address error when the backend calls into proxy.bars()..

and these are further duplicate/alternatives surrounding the same limitation:

  • https://groups.io/g/insync/topic/31835165
  • https://groups.io/g/twsapi/topic/24929715#40540
  • https://groups.io/g/twsapi/message/40551
  • https://www.quantrocket.com/installation/linux/
  • https://groups.io/g/twsapi/topic/27821868?p=,,,20,0,0,0::,,,0,0,0,27821868

Analysis:

What's super odd is that this isn't supposed to be a limitation if you have both a paper and live (which share a data sub) running on the same host and, in this case they obviously do have the same IP - so it would appear ib-gw's code is doing something else to profile what is considered the same host bit..

oh, and if you run the gateways native you don't have this issue, so it's clearly something read / set by the sw that is different in the containerized env vs. when run as a native app.


Things to try:

  • [ ] run live and paper gws in container setup and see if we can avoid this
  • [ ] run container on same jts.ini / config dir and see if that changes anything
  • [ ] do a small dive into checking outbound tcp connections when live vs. paper instances are spawned in both envs (native host and docker --net=host)

goodboy avatar Jun 21 '22 15:06 goodboy