But not knowing precisely how the routing is handled in the provider’s network such that the traffic is appropriately routed to the host in the first place, it’s hard to know whether this is feasible or not. One might argue for configuring docker networks with subnets that include the respective /32 IP addresses and then starting the containers with the failover IP address. But this still doesn’t account for manually configuring the external IP addresses on the containers. Also, you’d want to make sure that this configuration is done via config files on the host so that a failure/reboot of the host doesn’t lose all of this custom setup. For example, one way would be to use a different docker network subnet, start the containers with different container ports, manually assign the “external” IP addresses to the desired containers and then set up routing rules to forward the external IP address to the container, and set up iptables rules to allow the traffic. The way around that is not straight forward. In that scenario, you would need to expose the different container ports to the outside world as there wouldn’t be a way to do 1:1 port mapping. Say for example that instead of creating separate networks for the containers, one wanted to use a single network and use different container ports for multiple instances of the same container type. It depends on how one launches the containers. Is that a problem? BTW this is also true for IPv6, unless you use a reverse proxy container or similar. This routing won’t translate port numbers which means the container has to start the services on the port that should be visible externally.
#255 255 255 255 network update#
It’s a good idea to use static IP addresses on the containers otherwise you need to update the static route after launching the container. Which means you won’t use port forwarding. This means the IP address is only assigned to a container and not the host. Possibly you might be able to do this with ip tables, but I’d worry that this solution might get overridden when using docker to make any further changes, as docker itself manipulates firewall rules when setting up port-forwarding of traffic to the containers.īy routing I mean adding a static route on the host. The issue being that you’ll need some process on the host machine which will listen on the specified port, and then route through the docker bridge to the container with the packet altered to communicate with the container on its internal port number. This will start the containers and bind there network interfaces with the correct IP addresses you configured above. The final bit is that you’ll want to start each container with at least the following two docker run options (plus others as needed): Then configure the failover IP addresses as secondary IP addresses on the server interface, following the instructions in the link you provided. These subnets should NOT overlap your failover IP addresses. What you really want to do is to create three new docker bridge networks, using IP subnets that are at least a /29 CIDR mask. With a macvlan network, your one IP address in the subnet will be consumed by the physical interface on your server, leaving no addresses for your containers. The point of creating docker networks is to have IP addresses available for containers to use.
#255 255 255 255 network driver#
I don’t think that using a macvlan driver for your docker network is going to work using an IP address with a /32 subnet CIDR.