Public IP mapping to internal shared virtual ip address in Docker

Question

I am using Docker on OSX and have created a host with a bridged network and a couple of containers that share a virtual IP (so 172.19.0.50 points to 172.19.0.1 and if that container goes down, 172.19.0.50 is pointed at 172.19.0.2 and so on). Other containers within this network can access 172.19.0.50 and see either of the boxes as planned, so great so far.

Where I am confused is quite how to point my public 192.168.99.100 IP such that it goes to 172.19.0.50 rather than a specific container IP.

This is an area I'm not too familiar with so any advice much appreciated.

Answer 1

After some research, it seems to me that there's no "docker solution", for the moment. I have the exact same problem : I have a galera cluster on 3 containers on 1 docker host. Let's say you need to access the port 3306 on your containers, like me. I manage a virtual IP on those galera nodes, and it works great. But I can't tell Docker to match the port's host (3306 in my case for mysql) to the virtual_ip:3306. The port from your host has to be mapped to a container and port. Not an IP address. If you run the container that have the virtual ip, with port mapping like this :

docker run -d -p 3306:3306 docker_image /bin/bash

The requests to the public host IP address on 3306 will be redirected to the port 3306 of your container network interface (which have in theory 2 addresses, one static and the virtual one). But if your virtual ip moves to another docker, it won't change anything to your port mapping. The requests from the outside will be redirected to the first container anyway. (and, by the way, you can't map multiple containers to the same docker host's port. Actually, it wouldn't help)

In my opinion, you could use a HAProxy or Nginx reverse proxy in a container : so you can map the 3306's host port to the HAProxy's 3306 port, and HAProxy can redirect your requests to the cluster (with or without loadbalancing). So now you don't even need virtual IP. BUT, now you have a nice single point of failure. It would be nice to add another reverse proxy as a backup, but then you would need a virtual IP for the failover, and you would be stuck with the problem of the beginning.

If somebody has a better solution to this...