What is the recommended way to run IBC in Docker? #67
Comments
|
Im currently working on this, but there are some problems with the |
|
FWIW I ran into this same dilemma, so I built my own image here: https://github.com/jspahrsummers/ib-gateway-docker It's paper-trading and read-only right now, but those are just config settings, so feel free to fork and reuse if it's useful. |
|
@jspahrsummers How did you solve the |
|
AIUI the use of |
|
Since posting this, I've also created my own image - this time optimised
for Google Cloud. It's publically available on docker hub - see here:
https://github.com/dvasdekis/ib-gateway-docker-gcp/
I'm happy to provide some support to others using it in GCP - it's a brave
new world!
…On Mon, Dec 9, 2019 at 12:14 AM Justin Spahr-Summers < ***@***.***> wrote:
AIUI the use of socat
<https://github.com/jspahrsummers/ib-gateway-docker/blob/29207c3cb4c6523274338970562e5a7d3bef599a/run.sh#L10>
will ensure that incoming connections look local to TWS.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#67?email_source=notifications&email_token=AETC4JPL55HOSIW6B3YXHFLQXTXLNA5CNFSM4JHCIU32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGG6IQA#issuecomment-562947136>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AETC4JIKT2EIVHOLYN5562LQXTXLNANCNFSM4JHCIU3Q>
.
|
|
As a note, after about six hours of usage, the Java process running IBGateway/AWSAPI uses more and more memory to the point where it falls over. Has anyone encountered this previously? |
|
@dvasdekis, sorry to resurrect an old thread. I just experienced similar issues with 978 gateway on GCP instance - the memory/CPU usage is growing linearly over time and eventually completely overloads the instance. It was with image I built. Did you manage to find the root of the issue? Do you experience anything like this with your image? |
Hey @omdv, yes, this was caused by my IB_Insync doing something dumb (in my case, re-subscribing to Market Data repeatedly) without cleaning up the connection (via cancelMktData(), followed by IB.close). This caused the relatively fragile gateway to memory leak and eventually collapse. Once that was fixed, it was stable. |
|
Any updates on dockerizing IBC? What's the recommended way in 2022? I'm just getting started with this and I'm wondering how to know which Dockerfile to use. I don't need the GCP version and it seems that @jspahrsummers has archived the linked repository. The one from mvberg hasn't been updated in 3 years. Has anyone suggested making an official image on Docker Hub? |
|
No, there is no recommended way of running IBC in Docker. Actually I began work on a Dockerfile based on @larroy's work (see #79) a couple of years back, with the intention of including it as a sample in the IBC repository (but with no implication that it was the 'right' or 'recommended' way to do it), but it got blown out of the water when I updated my Ubuntu VM to a later release and I could no longer build it. I didn't have the time, or really the inclination, to sort out the problems so I just shelved it (I still have the files though, in case I ever want to get back to it). To be honest, I don't really see much value in it. If one is just a private individual wanting to run a couple of TWS or Gateway instances, I see no real point in running it under Docker. If you are a commercial organisation wanting to run dozens or hundreds of Gateways, you can do the necessary work yourself and perhaps contribute it back. Anyone who wants to make an IBC image on Docker Hub is of course free to do so, as long as they don't try to claim that it's in any way 'official'. I would also be willing to consider including a sample Docker along the lines mentioned above if someone wants to do the work and offer it via a pull request, provided they take account of the points I raised in #79 (where relevant) and they're willing to commit to maintaining it going forward. |
|
For a private user, I think the the Docker value-add is mostly along the lines of "It Just Works". That is, the image pulls in all of the necessary dependencies, keeps them from interfering with other things that might be installed, and takes care of a lot of the grunt work. Oftentimes Docker (or Docker Compose, more likely) can be used to automate a lot of the boilerplate configuration and set up tasks, which makes life much easier for less technical users. It also makes life easier for those of us who are technical users, but long ago grew weary of manual configuration and set up. In my particular case, I use a Synology NAS for running lightweight applications, dashboards, etc. Containerization makes it easier for those various utilities to avoid stepping on each other, or the base system. Even though Synology is just Linux under the hood, and I could go in and install everything directly, I'd run the risk of interfering with the base system. Even if I did want to take that risk, I'd still have to worry about my customizations being blown away by the next firmware update, or the next time I update the hardware. Containerizing simply avoids an awful lot of pain points that don't need to exist. Even if I were to go back to running a "real" server, I think I'd probably keep using containers, just to avoid issues with various packages needing 10 different versions of 3 different dependencies (it happens). Or packages that want to install crazy things like It would actually be very helpful if there were a recommended way of running in a container. Even if there are multiple ways to do it, a default way that's good enough to work "out of the box" for most people would be very useful for people who are either non-developers, or just new to the project. As it stands now, a new user has to sort through a pile of equally unofficial options with no clear way to decide between them. Sorting through the mess adds a lot of unnecessary pain and confusion to the new user experience. I'm happy to contribute a Dockerfile to the project, and an example Docker Compose file, but only if the project is willing to push it to Docker Hub. Publishing an image from a personal account would only add to the confusion, which is the thing that I'd be trying to fix by contributing a Dockerfile. |
|
Ok, thanks, nice write-up. First let me say I have nothing at all against Docker: it's a wonderful technology, and you give a good summary of (some of) its many benefits. My position here is that IBC is such a tiny little program, trivial to set up, rarely needing any change to keep it operating smoothly, no dependencies (except Java, which is anyway installed with TWS/Gateway), that I don't see any 'pain points' that containerising would solve for IBC. That's not to say a Docker container isn't of value in some circumstances (and your Synology NAS is a good example, though you could alternatively run a Linux VM on the Synology Virtual Machine manager and run IBC in that). And as I alluded to in my previous post, a Dockerised IBC is probably essential for a commercial organisation serving many customers with an IBC instance for each, so they can take advantage of the management facilities provided by Kubernetes, etc. So in the case of IBC, installing, learning, and maintaining a Docker installation is much more complex than simply running IBC directly. Of course most people wanting to run IBC under Docker will already have been through this learning curve, so perhaps that's not a real issue, just an observation. And so, I repeat, I'm willing to consider a sample Docker implementation that can be used either 'out of the box' or for further customisation by users. But at this stage I'm nowhere near being in a position to agree to pushing it to Docker Hub. Part of the reason I'm a bit cagey about all this is the additional support load that such a thing would entail. As soon as there is a Docker image or Compose file in the repo, there will be a flood of new questions from users. For example:
There may be simple answers to all of these, and the many other questions that users will come up with, but nevertheless they all need to be responded to. Some may result in calls for IBC to be modified in some way to make it fit better into the Docker environment. To be frank, I don't want this extra hassle, which is why I say that if I am to accept a sample Docker file into the repo, the contributor must commit to documenting, maintaining and supporting it for the long haul. If you already have a Docker compose file that works well, I'd be very interested to see it and assess it myself. You don't need to make a pull request at this stage, just email the files or stick them somewhere accessible. I have to say, though, that I no longer have a Docker setup at the moment, so I'll have to start from scratch again, and I really don't have much time (ie none!) for this. |
|
As a total outsider who wants to now automate In fact, because there isn't one, it's actually greatly turned me off wanting to use this project for a while. But wait, why?
|
I did https://github.com/waytrade/ib-gateway-docker (has been arborted) and I can confirm it will bring additional support effort, however the type of question is different to what you assume. If you want to add it to this probject, feel free to have a look at https://github.com/waytrade/ib-gateway-docker/blob/master/Dockerfile to have something to start with. Think you should be able to simply strip out the build-automation stuff (checksums, donwloading gateway from gh releases) and change it so it copies a local IBC and Gateway. And maybe find a better soltuion to using socat, caused troube for some users (randomd hangs because of stall connection between socat and gateway, we never figured the actual reason for, either problem disapeared or users stopped trying and went plan b (run your app on same container and connect to gateway directly)).
I can name about 100 people on the other side that use it successfully. |
Woops, also linked to wrong issue (edited it), should have been waytrade/ib-gateway-docker#4
Fair enough, but either way there should be a test in CI to prove this all works with an automated client (bc why else are we automating all this if not to make API oriented trading work 😉). As an example though, why is Personally, i'd much rather collab here with the experts then do what I always end up having to do: writing this all from scratch myself, doing it correctly such that it's proven to work in CI, and then having to constantly worry about upstream changes which I don't have as much time for these days (i already am doing this for far too many projects 😂). I would highly recommend a coordinated effort here in this repo at the very least with a recipe or super basic container setup script with automation to show it all coming up and working with CI runs we can point to when stuff doesn't work or a user claims it doesn't. When you have this, and can link to the workflow runs, i find that "users problems" tend to disappear when they can see the execution that proves they're problem isn't ours. @rlktradewright doesn't even have to maintain the container part, that's what collabing with foss is all about; we can have certain people try to take care of certain things 🏄🏼 As an example of what my crew would be willing to contrib:
I'll restate again, as a total outsider to this "space" for ib app "integrations", it's looking difficult to navigate I'd much rather see and get involved in something more collaborative:
|
That is just the perfect example of what I was talking about in term of support.
Try it. It's there for a reason.
Than please go ahead, @rlktradewright seem to be open for PRs. |
I did, just run the network stack in "host" mode (
@rlktradewright if you are indeed open for this I would consider putting in the effort since the crew i'm with also have other "workarounds" that y'all don't seem to be implementing here. As I said it would be mostly python oriented. Either way happy to keep eyes on this thread and contribute what we can. |
Because I develop on windows (there is no host network driver for Windows or Mac) and live system run in a VM as VPS on the internet. Just running Gateway container on host network would make it free for everyone on internet to use. If you want to go the linux-only way using host network driver, make sure to put a big fat warning somewhere so ppl don't start to expose their IBGateways on public networks (you need a firewall additionally, or block the ports otherwise, I woudn't rely on the "ip filter" of gatway - you don't want leave localhost with IB API protocol, see https://github.com/waytrade/ib-gateway-docker#leaving-localhost) |
|
Sorry for the delay in getting involved in this issue again. Can we please stop discussing @mfrener's project here: the discussion raises important issues that will need to be taken care of in any new Docker work here, but the details of such discussions are irrelevant just now (pursue it on the relevant repository if need be). Yes, I am indeed open to PR submissions. There are two possibilities that interest me:
Let me try to explain what I see as the difference between these two things. A 'sample' Docker setup: S1. Does (at least) the minimum necessary to get IBC/Gateway running under Docker. A 'professional' docker setup: P1. Provides Docker capabilities for both Gateway and TWS (separate Docker images). As @mfrener pointed out above, his project might well be a suitable starting point for a sample DockerFile. I'll try to take a closer look at this some time, but I'd be happier if someone else did this and submitted either it or something similar as a PR, in line with the sample description given above. |
|
Just responding to some points you mentioned earlier. Regarding Python, I don't see what relevance Python has to creating a Docker image. Please clarify. Regarding ib_insync, Ewald has done a fantastic job with this and it has dramatically eased the Python developer's experience with the API. I haven't looked in detail at ib_insync recently, but I believe it invokes IBC if required to get TWS/Gateway running on the local machine. Clearly if we provide a Docker image for IBC, Ewald might want to make use of that and this would presumably require some re-engineering within ib_insync. But it's not clear to me that this would have any impact on our Docker capability (except perhaps in the special case of a Docker image containing the user application and the ib_insync API). At this stage, I don't think we need to concern ourselves with that - in any case, Ewald might prefer that such a Docker image be under his control in his repository. |
Mostly that the most popular API client (afaict, and of which I know you're well aware of) is the Further,
Definitely! There is both existing ibc module code and an ongoing "fyi" issue regarding a container solution, plus another container issue that got closed: erdewit/ib_insync#261.
I don't think that's true if you look at the above issues. I think erdewit is probably approaching this the way I would, Also note, I'm not suggesting we put any theoretical consensus container recipe inside any particular code base like I guess for me it'd be nice to have a unified place to start getting everyone working together to create a least a template of a solution for this whole thing. I much prefer all the minds making things better through PRs then disparate forks of slight But hey maybe that's an unpopular opinion 😂 |
|
I think we're not on the same page. What I'm looking to create is a simple Docker image that runs IBC to start Gateway or TWS. Nothing else at all. When using such an image, the API application (and hence the API itself) will be in a different process, which may be another Docker image, perhaps starting both using Docker Compose, or that process could be on another computer anywhere in the known universe (provided it has an internet service and a reasonable ping time). So who cares what API or application you use to test it? As long as the correct API messages arrive at the running Gateway, nothing else about the client matters. I'm not going to speculate about what Ewald is or isn't going to do regarding Docker. He's more than capable of doing whatever fits with his way of doing things, and if he wants to contribute to this effort here, he's very welcome. |
@rlktradewright how do you feel about I much prefer something that avoids as much package for the old project that i'd like to update here:
Right, and end-to-end system tests for all of these scenarios are not only super easy to write these days but also pretty commonplace especially with tools like
Or just a different process on the test suite host. the main thing I think is important is that you can't easily test client code/projects for the I'm not proposing that IBC build out any such integration tests, just saying if we had an official image, then those of us wishing to use and improve it could implement such tests in our repo image (fork) CIs and then report issues that much easier when things change in the official image. Anyway just an idea, nothing to do with |
|
Please can you just stick to the point. NixOS has no bearing whatever on this thread. We've already established the desire for an official Docker image. You said you wanted to contribute a pull request. Well then, contribute it instead of wasting time on peripheral matters. |
It does if i make the docker image based on a nixos image? I'm asking if we could do an image based on nix so that the image build/configuration can be almost entirely in nix's config language instead of having to hack to together shell scripts for everything and shipping them alongside the build. Most IBC docker images on github are based on unbuntu, which i personally try to avoid. Anyway, I'm not trying to be "off topic" i'm just trying to test the temperature for a "non-mainstream" distro as the basis for an image. |
|
Ok, I've spent quite a bit of time looking into Nix (which I wasn't aware of before you mentioned it), and it looks like a very sensible approach to creating packages. I don't have any objection to you using Nix to create an IBC package, and IF a sensible Docker image can be automatically generated/exported from the Nix package then you're killing two birds with one stone, since some might prefer to use the Nix package directly. Which is obviously a good thing. So if you want to follow that route then fair enough. However the thrust of this thread is to end up with a Docker image, because that's what people are asking for, so it would be a shame if you spent a lot of time on this approach and then found that it wasn't going to fly for some reason. But I'm encouraged to see that, for example, MySQL has a Nix image (and an impressively huge dependency tree!), which indicates that it should have no trouble coping with IBC which is trivial by comparison. It all hinges on the Docker export capability. |
🥳 i agree very much!
Slick! Yeah, this was one of the reasons I've started moving infra over to this "distro", package-manager, whatever 😂
Agreed. I haven't actually personally done any docker export stuff yet so will report back once of our crew (or myself) has a working POC. @rlktradewright again appreciate all the patience with this back and forth 😺 |
|
Bleh, ran into an additional "fun" issue with docker and the current modified waytrade image setup which is documented in this comment. I wonder has anyone tried to solve this problem before where a user would like to run a paper and live account simultaneously on the same host but one or the other in docker and the other as a native app? It seems as though the Further, some follow up questions (maybe for rlktradewright):
|
|
I don't think there's going to be a way around this (short of persuading IB to somehow make it possible). I run several virtual machines on the same host, and I have to run both live and paper sessions in the same virtual machine to avoid the problem - the fact that they share a common virtualisation host doesn't help. As far as I can see, if you want to run live and paper-trading at the same time, and either is in a Docker image, then it will be necessary to use two different logins and pay the price of the separate market data subscriptions. A completely bizarre idea that occurred to me is the possibility of running more than one instance of Gateway/TWS within the same JVM. It would be straightforward for IBC to call the Gateway/TWS entrypoint more than once, but I guess it would be very surprising if there were no shared data areas or whatever within the programs that would need to be separated between the different instances for them to work properly. And IBC would somehow have to know which instances any particular dialog was initiated by. There are just too many ways such a scheme could, and almost certainly would fail. But the idea is preying on my mind!... Regarding the ExistingSessionDetectedAction setting, here are two scenarios where you might appreciate its value:
I didn't quite understand your question about the command server settings. Please clarify. |
|
First sorry about the delay and thanks for the response!
I actually only need one data feed profile (since you can share live feeds with paper accounts) and the way we use it is by normally having the paper be the data feed and the live is only for order mgmt. This seems to actually work just fine except when trying to pull historical data oddly, which throws the "something something another client on another IP" (which it's not) error.
I'm more or less trying to figure out how to run 2 instances of IBC on the same host such that i can run both a paper and live gateway simultaneously. So I'm asking which settings do I need to make this possible? My theory is that if you run both gw blobs in the same container net env then this "different IP address" error might go away; figure it's a least worth a shot. |
|
Yeah so reading ExistingSessionDetectedAction more thoroughly I don't think I'm hitting this. Currently when i try to start 2 containers one of the internal IBC processes will always terminate; so i'm trying to not have that happen. |
|
I think maybe you're not fully understanding the restriction on sharing the data feed between paper and live instances on different hosts. You can certainly start them both and they'll run, and one of them (presumably the first one to make a request) will be able to use market data, historical data, etc, but as soon as you try to use any data-returning function on the other instance you'll get the "something something another client on another IP" message. I don't believe you'll be able to get round this, no matter what you do at the networking level. To illustrate this, I normally run both live and paper accounts under the same host username on a Windows server. If I need to look at the GUI, I use a remote desktop (RDP) session. Now Windows Server allows two simultaneous RDP sessions running under different users. But if I do this, with live and paper instances running under different host usernames, I get the data sharing problem. So these are two instances running in the same physical host, using exactly the same network adaptor, and yet it still gets caught out. I suspect that everything has to be the same for both instances: physical host, virtual host, IP address, MAC address, operating system username: in other words, effectively the same desktop: if you can't actually 'see' both instances on the same desktop, then you can't share the data. So I think you're wasting your time trying to defeat this restriction. By the way, you don't need to make any different settings to run two instances on the same host, except for the IB username and password, and of course setting the paper trading mode for one of them. Note in particular that ExistingSessionDetectedAction is nothing whatever to do with running different instances under different IB credentials: it's only relevant when you try to run multiple instances under the same user. |
I already am doing this, have been for more then a year and it works fine presuming I run one account as "native" and not under IBC and the other inside the container + IBC with the only caveat is that I have to use the live instance running native for the data feeds when running both, but I can still manage orders in the paper instance no problem. If I run both the gw instances native then there is no problem on which is used for the data feeds iirc (but maybe i'm wrong on this gotta double check). So that's not the issue. I'm trying to run 2 instances with IBC (containerzed) but can't seem to avoid one instance always terminating when I start the other in a 2nd container. I'm currently running containers in docker's "host networking mode" (not supported on windows and i link to it below) merely to avoid doing bridged networking config and only because it's no really for my purposes yet.
As I said, no this isn't required. I can run one of a paper or live in container + IBC and the other as native (aka I run
With docker's host mode this should be true minus the user.
I don't think so 😂
Gotcha, ok then maybe something else is up that needs diggin. Thanks again for the response 👍🏼 |
|
Andd don't worry it was all just me being an idiot with So might be closer to something useful 🏄🏼 Heh, yup got it workin both in containers but still needs the api client to talk to the live account one. Really not sure what that's all about since if you direct run the gws you can do the paper case which I just double checked. |
|
Just to contribute to this interesting debate: https://github.com/manhinhang/ib-gateway-docker |
|
After making it work on GCP I later generalized it to all docker
environments, so feel free to use mine for your needs. I think it works
well, and can be easily updated to new versions of IBC. Ymmv!
…On Tue, May 17, 2022, 10:55 Brandon Fosdick ***@***.***> wrote:
For a private user, I think the the Docker value-add is mostly along the
lines of "It Just Works". That is, the image pulls in all of the necessary
dependencies, keeps them from interfering with other things that might be
installed, and takes care of a lot of the grunt work. Oftentimes Docker (or
Docker Compose, more likely) can be used to automate a lot of the
boilerplate configuration and set up tasks, which makes life much easier
for less technical users. It also makes life easier for those of us who are
technical users, but long ago grew weary of manual configuration and set up.
In my particular case, I use a Synology NAS for running lightweight
applications, dashboards, etc. Containerization makes it easier for those
various utilities to avoid stepping on each other, or the base system. Even
though Synology is just Linux under the hood, and I could go in and install
everything directly, I'd run the risk of interfering with the base system.
Even if I did want to take that risk, I'd still have to worry about my
customizations being blown away by the next firmware update, or the next
time I update the hardware. Containerizing simply avoids an awful lot of
pain points that don't need to exist.
Even if I were to go back to running a "real" server, I think I'd probably
keep using containers, just to avoid issues with various packages needing
10 different versions of 3 different dependencies (it happens). Or packages
that want to install crazy things like x11vnc, or even Java. 😃
It would actually be very helpful if there were a recommended way of
running in a container. Even if there are multiple ways to do it, a default
way that's good enough to work "out of the box" for most people would be
very useful for people who are either non-developers, or just new to the
project. As it stands now, a new user has to sort through a pile of equally
unofficial options with no clear way to decide between them. Sorting
through the mess adds a lot of unnecessary pain and confusion to the new
user experience.
I'm happy to contribute a Dockerfile to the project, and an example Docker
Compose file, but only if the project is willing to push it to Docker Hub.
Publishing an image from a personal account would only add to the
confusion, which is the thing that I'd be trying to fix by contributing a
Dockerfile.
—
Reply to this email directly, view it on GitHub
<#67 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AETC4JLXAQZYI3OTPZUYMTDVKLVB5ANCNFSM4JHCIU3Q>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
This is cool but one of the benefits of using the VNC stuff is being able to hack historical query throttles. I might take a look at extending with some options for running with and without the VNC bit. |
|
Are you still progressing this? If so, how's it going? If not, please say so, so that other options can be pursued. |
|
https://github.com/extrange/ibkr-docker
|
|
@rlktradewright hey! sorry yes we are, but i don't yet have anything to publish unfortunately.. we will likely host the nixconfig in our org and i will link to it here to start. |
|
@goodboy Thanks for that. I'll look forward to seeing whatever you come up with. |
|
in case anybody finds it usefull, i'm maintaining a docker image with IB gateway and IBC ib-gateway-docker it includes IB gateway, IBC, socat to route IB gateway port and optionally VNC. The build is triggered by every new IB gateway release. And it pulls latest IBC as well. |
@rlktradewright yaahh super sorry I've let this slide again. literally stuck in one of them life-task mud puddles (spraying slop everywhere) the past month getting a buncha stuff out of the way that has been on the backburn wayy too long 😂 I'm still pushing on nixos stuff and will definitely be working on this at some point, ideally in the next month - literally right now i have no working container (which is frankly a nightmare) since IB just deprecated the last one supported by the (now abandoned) project that i mentioned using prior (i think in thread?). On the flip side i've been able to compile a list of of nix-ops related projects that I want to try and that will likely relate to the particular container rendering sys we decide on. @gnzsnz dope. literally gonna check this out tonight to see if i can get it workin 😎 thanks for linking it 👍🏼 |
|
All, As mentioned on my previous comment, I've been working on a docker image to run IB gateway & IBC. The image is a fork from UnusualAlpha/ib-gateway-docker, which in turn is based on waytrade/ib-gateway-docker. I have added my own sauce on top. This thread is really useful as it has allowed me to consolidate requirements for an ib gateway image. The current image version is covering most of the requirements. I understand that the objective of this thread is to have a "recommended" Dockerfile, but after working on the docker image I can say that a "Dockerfile" only is not going to work. You need a Dockerfile and a script to orchestrate the execution within the container. I'm not sure that this has been considered/discussed. Plus provide settings/config to the container, which is better suited for a tool like Please feel free to used the Dockerfile and scripts required to run the container, plus extra things like config files pre-tunned for a container, and a sample docker-compose.yml. I'm doing some heavy refactoring at the moment, so you might want to check the sshclient branch which has changes to support ssh tunnels. Based on the requirements described on this tread I have done a match with the image capabilities. I would love to get the community feedback. A sample Docker setup: S1. Does (at least) the minimum necessary to get IBC/Gateway running under Docker.
S2. With the relevant username and password.
S3. With API connections enabled to localhost.
S4. It should honor any settings specified in config.ini.
S5. It should include the ability for the user to view the Gateway UI via VNC Viewer (or similar).
S6. It would be acceptable that any configuration changes made to Gateway via the UI would be for the current session only and not persisted between sessions.
S7. It would be acceptable that the user's API client application needs to be built into the Docker image.
S8. To use such a setup, the user would have to customize the DockerFile to meet their requirements, and then build the Docker image. A 'professional' docker setup: In addition, one of my objectives is to keep the ib-gateway-docker image as small and lean as possible. Resources should go to the algos, not to the broker bridge. P2. Docker images are provided for different combinations of TWS/Gateway/IBC versions. Release of a new version of IBC, Gateway or TWS should require only that the the user run a different Docker image.
P3. A running Docker image behaves in all respects like a locally installed IBC/Gateway or IBC/TWS, to the maximum extent possible. An example of where this might not be possible is a change to the API port number in TWS/Gateways API settings: this might require restarting the Docker image with a different port mapping.
P4. No need for the user to modify the relevant Dockerfile in any way. Sorry for the wall of text. Hope you find this useful. |
|
@gnzsnz Have you looked at voyz/ibeam? They're already going down the path that you outlined above. |
|
@bfoz thanks for raising it. yes i did see it some time ago. The thing with ibeam is that it works with web api gateway, which at the moment does not have all the features than TWS/IB gateway. At some point i expect IBKR to unify their APIs. I hope that web api gateway is not going to remain in it's current form. I would prefer to avoid any gateway to be honest. A REST api would be great, but we are not there yet. |
🤞 |
Hi Richard and others, thanks for providing such great software for free.
I'm wondering what the recommended way to run IBC in Docker would be? There are a few repos, and I stumbled into using this one without understanding the background behind IBC/IBController/QuantConnect etc. It does work for me, albeit CPU usage is quite high for the operations I'm running on it.
In the pursuit of attempting to streamline this image, I've discovered that it's running some quite old software. Is there any up-to-date IB Gateway solution running in docker that I should be using?
Many thanks!
Dimitri
The text was updated successfully, but these errors were encountered: