The password could be encrypted through some IB command line tool, but the exact details needs to be figured out.
https://www1.interactivebrokers.com/en/index.php?f=en/software/systemStatus.php
SERVER RESET TIMES NORTH AMERICA Saturday - Thursday 23:45 - 00:45 ET Friday 23:00 - 03:00 ET
During the Friday evening reset period, all services will be unavailable in all regions for the duration of the reset.
1) Clone repo: git clone
2) Edit docker-compose.yml
3) Build & run docker:
> cd ib-gateway-docker
> docker build .
> docker-compose up
Creating ibgatewaydocker_tws_1 ...
Creating ibgatewaydocker_tws_1 ... done
Attaching to ibgatewaydocker_tws_1
tws_1 | Starting virtual X frame buffer: Xvfb.
tws_1 | find: '/opt/IBController/Logs': No such file or directory
tws_1 | stored passwd in file: /.vnc/passwd
tws_1 | Starting x11vnc.
tws_1 |
tws_1 | +==============================================================================
tws_1 | +
tws_1 | + IBController version 3.2.0
tws_1 | +
tws_1 | + Running GATEWAY 960
tws_1 | +
tws_1 | + Diagnostic information is logged in:
tws_1 | +
tws_1 | + /opt/IBController/Logs/ibc-3.2.0_GATEWAY-960_Tuesday.txt
tws_1 | +
tws_1 | +
tws_1 | Forking :::4001 onto 0.0.0.0:4003\n
You will now have the IB Gateway app running on port 4003 and VNC on 5901.
See docker-compose.yml for configuring VNC password, accounts and trading mode.
Please do not open your box to the internet.
It seems that all of the demo
accounts are dead for good:
Sometimes, when running in non-daemon mode, you will see this:
Exception in thread "main" java.awt.AWTError: Can't connect to X11 window server using ':0' as the value of the DISPLAY variable.
You will have to remove the container docker rm container_id
and run docker-compose up
again.
1) Clone repo: git clone
2) Edit deployment.yaml
3) Edit cloudbuild.yaml
4) Manual Deployment (for testing):
5) Auto Deployment on GCP:
kubectl get services
Expected output on a new cluster:
>kubectl get services
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
ib-gateway-service ClusterIP 10.4.15.215 <none> 4003/TCP,5901/TCP 2d18h
kubernetes ClusterIP 10.4.0.1 <none> 443/TCP 5d18h
kubectl port-forward service/ib-gateway-service 4003
Expected output:
Forwarding from 127.0.0.1:4003 -> 4003
Forwarding from [::1]:4003 -> 4003
Thereafter, any connection to 127.0.0.1:4003 gets routed through SSL to the cluster service. Kubernetes resolves the DNS name automatically and routes from the virtual service name to the matching pod in the cluster.
Programming the IB gateway on Kubernetes:
The only applicable rule is:
"Always connect to the service name"
ib-gateway-service:4003
Kubernetes assigns IP addresses dynamically, therefore any hard coded IP addresses almost certainly will be invalidated after a new deployment leading to connection timout errors. At the same time, kubernetes updates the internal DNS system dynamically so whenever a pod got replaced, the new IP already is in the DNS resolver at the moment the pod comes online. Therefore, always connect to the service name