An alternative to statically assigned IP of Postgres using gluetun ?

[kuolemaaa]

From my understanding bitmagnet+gluetun works by using gluetun as a broker for every connection started by bitmagnet (or other containers) both for internet and local communication.
The other thing is that bitmagnet needs postgres to save the DHT data, but since bitmagnet is completely fagocitated by gluetun it cannot reach postegres so gluetun needs to be the broker for such communications.

Now: I really like the hostname solution adopted by docker because I do not need to care about the IP assignments and discovery of the containers but the docker-compose.yml example for bitmagnet+postegres+gluetun makes use of a statically assigned IP for postgres.

Maybe the only problem with the proposed setup is that it is not configuration-agnostic.
eg: i'm not using 192.168.55.0/16 like in the docker-compose file, but I know about my configuration!

Is there a way to avoid this? An alternative setup?

Isnt there a way to set bitmagnet's stuff to use something else?

gluetun exposes HTTP proxy, TCP & UDP proxy via shadowsocks. Couldn't they be useful for bitmagnet?

[mgdigital]

I agree that a simpler way would be nicer, but this is really a limitation of docker compose when using network_mode. Assigning a static IP using extra_hosts seems the simplest way for the purposes of the docker compose example - I'm sure there are more "exotic" solutions - if there's a better way I've missed then the examples could be updated but this is the simplest solution I'm aware of.

[alphasierracharly]

Binhex put the postgres db inside the same container.
You can check it out here: https://github.com/binhex/arch-bitmagnet
Maybe the official project can adopt this approach

[mgdigital]

The Docker Compose example is just that - an example. Users can set it up however they please but I feel the example is best kept with the containers separate, which is simpler and adheres to Docker best practices. I'm not sure what problem it is we're trying to solve here, or that specifying the IP in docker-compose.yml is very inconvenient for most users...

[leofidus]

I like how the binhex version is a single container unless you want a proxy (and even that could likely be integrated in the container). But on the other hand with larger databases the postgres installation isn't entirely hands-off, and configuration changes and maintenance is slightly easier with a separate container.

I think it's good both approaches have their merits, and it's good that both are available. And I really don't mind specifying the IP