search

docker / roadmap

Welcome to the Public Roadmap for All Things Docker! We welcome your ideas.
https://github.com/orgs/docker/projects/51
Creative Commons Zero v1.0 Universal
1.79k stars 265 forks source link

VRRP/virtual IP inside docker networks/containers #389

Open Folas1337 opened 2 years ago

Folas1337 commented 2 years ago

Tell us about your request There should be some way of setting a virtual IP and assigning it to several Docker containers which then decide upon other factors (such as status and priority) which container currently gets that virtual IP and which doesn't. This should also work within a swarm network! It doesn't have to be VRRP but rather some way of using a virtual IP within a Docker network to declare the current master container. The best way I could come up with to fix that was VRRP but there may be another solution. It needs to be a virtual IP that is assigned to a container as I want to connect within a docker network to those containers!

Which service(s) is this request for? Docker CLI (and Compose) I suppose?

Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?

  1. Let’s say I have 3 standalone client containers that all want to sync some data through Redis (as an example).
  2. I now set up 2 masters with 1 replica each, and let’s also say I set up the replicas in read-only mode. The masters get the IP 192.168.0.100 and 192.168.0.101 and the replicas get 192.168.0.110 and 192.168.0.111. They are all set up under the service name “redis1”
  3. Now I tell my client container to connect to redis1 which has two issues already.
    • Issue no. 1: It could still pick a replica cause DNS would still resolve redis1 to all 4 IP addresses and pick one at random. It might then try and reconnect but this behavior shouldn’t even occur in my opinion.
    • Issue no. 2: If client container 1 and 2 picked 192.168.0.100 and container 3 picked 192.168.0.101, they still wouldn’t be able to sync up the data cause they are connected to different servers that do not replicate data to each other!

Issue no. 1 could be resolved by giving the masters the service name redis1master and the replicas would be redis1replica and I set up my client containers to connect to redis1master but Issue no. 2 is still unresolved in this scenario.

Docker network VRRP would solve this issue by having a virtual IP (= VIP). Let’s say we pick 192.168.0.102 as a VIP and assign it to both master containers. Now I’d be able to tell all 3 client containers to connect to 192.168.0.102 and they would always connect to the same master with replica (though for my use case I don’t even need replicas and only masters as it’s literal messages that are being redistributed but that is besides the point here).

Are you currently working around the issue? Yes, by having only one instance of the database as there's no way to have redundancy as I need it (as explained above).

Folas1337 commented 2 years ago

I might also want to add that for my use case (Redis) I was able to use KeyDB as a drop-in solution but I am still facing one issue which is the fault of the client software I'm using though. It doesn't try and reconnect on connection loss because it was obviously not programmed for high availability/redundancy. But this problem would also be solved with VRRP cause the client application would then not have to worry about any of this, it would still connect to the same IP as before, only that this IP is a VIP and will have moved by then, acting as if it's still the same connection.

So what I'm trying to say is that VRRP would still be greatly appreciated as it fixes some issues that could still be faced but for now I found a workaround that works well enough, even if not perfectly.