Which Ports need to be open in Docker ?

[Kos-M]

Hello , a question more than an issue .
Does anyone runs bugout inside Docker container?

Which ports (or port ranges ) needs to be open for effective communication to trackers?

[draeder]

Trackers listen on ports 80 and 443 in the context of Bugout/Webtorrent. For inbound back to the container, it is a dynamic range of ports.

[Kos-M]

Thanks for the input @draeder , so basically isn't possible to have an isolated and working container with bugout ?

Tried to open a big range of ports mapped to host , but my host pc was about to catch up fire till i restart docker service.. lol

[draeder]

When an outbound connection is created over an open port, the return traffic's inbound dynamic port for that connection should be allowed back to the container by default. However, because Bugout depends on WebRTC which requires NAT hole-punching, that could be where the problem is.

Depending on your OS, you could try starting your container with --network host, this exposes all ports the host machine has open. If your OS running the Docker container is MacOS or Windows, that argument may not work though.

[Kos-M]

Normaly i would go with --network host option , but besides that the container will be exposed completely to host (network prespective) , seems with that mode cant be used any other docker custom networks.And that leads to several refactorings for my app.

Maybe the most viable solution to me is to create something like a reverse proxy for bugout.

A small instance of bugout running at host with an additional webosokcet connection to target container which needs to use bugout.
And replay messages and events to my app.

[draeder]

I'm curious about your use-case. Bugout, among other p2p technologies, is built -- at least in part -- to overcome centralization, but it seems you want to centralize Bugout. What are you trying to build? There might be other p2p stacks that will work for you.

[Kos-M]

No in fact i want do a vertical scaling of my app by offloading some heavy resource demanding and long running processes to separate instances on different vps.
I could do it without p2p , with more standard approaches , but wanted to be a fast procedure , depending the traffic and business needs .Maybe later in an automated way..

So as load increases i would be able to add more instances to balance the load.Main app should see new nodes and make sure not direct new requests to over crowded servers.

I've done something similar for distributing cpu demanding tasks in Queue-Xec .
But that was supposed for quick small tasks not for distributing bigger and more complex apps.

[draeder]

@Kos-M I'm working on another project called Easypeers-signal that is confirmed working in Docker (tested between the US and a Docker container in Germany -- apparently doesn't work right with docker swarm, however; and host network is needed...). It has a stand-alone signaling server that connects WebRTC peers together. I intend to integrate it with my other project Easypeers, which is similar to and greatly inspired by Bugout. You may be interested in one or both of these.. Note that they are works in progress.

[Kos-M]

Using host network is not an option for me because i use custom networking for other containers and want to have control of my app's network.Using host network cant have any other network connected.
I have tested bugout also with host network and is working , is like running it without docker.
I have created a small Websocket server which im planning to run it in host , to listen for new messages with bugout , and forward data to docker in a predifined connection , exposed to host.

I liked easypeers ,maybe i ll use it in my next projects , do you have any plans to support typescript in feature ?

[draeder]

No plans for typescript at the moment, but considering it for the future.

[Kos-M]

Nice , i' ll keep an eye on this project anyway ;)

[draeder]

I've been talking to others about this issue and here's a response I got that might be helpful:

"I can say with certainty that host networking does not break container networking for every other container on a host. I'm running a mixed network as we speak. The only thing it does is disable container networking for that particular stack/network you've configured that way."

[Kos-M]

Indeed using host network in a container doesn't break all existing networking in that host , just doesn't respect any other network configuration for that specific container since is using host network.

My concern on this was that when i do that , that container (with host network) cant talk with other containers connected to custom and private networks.

At least i tried to reference other containers by name and didn't work , maybe if i found the IPs , it is possible to talk to those containers.