So this is my use case:
I have bought a server at SoYouStart, where I’ve acquired several failover ip addresses.
On the server i host minecraft server, which each are running in their own docker container.
All the minecraft servers have to have their own IP address so they all are able to start at the same port.
If I have 3 different servers called Server1 (public ip address: 145.1.1.1), Server2 (public ip address: 100.2.2.2) and Server3 (public ip address: 235.3.3.3), then Server1 should ONLY be accessible when using the address 145.1.1.1 and the same for the servers.
I tried creating a network for each of the servers, but as all of the IP addresses have a subnet of 255.255.255.255 I get the following error:
$ docker network create --driver macvlan server1Lan --subnet 145.1.1.1/32
Error response from daemon: failed to allocate gateway (): No available addresses on this pool
And if I give it a gateway the same error comes when i start the container on that network.
Are the ips you listed the failover ips? Or are those the public ip adresses of the host? You can not assign the hosts ip to a container in a macvlan as well. Macvlan is merly a virtual interface on top of your nic, having its own mac address and ip.
You might want to tell us more about the problem you are trying to solve and why this approach seem to solve it?
With the details provided so far, it is impossible to give an answer to that question.
We don’t know anything about:
– the subnet, the nodes are operated in
– the ip of the nodes
– the ip of the gateway
– wether the subnet is in full controll or shared
– the type of deployment? Standalone Docker Containers? Swarm Deployment?
I see you are creating a /32 subnet, which seems a bit odd. Subnets are typically just that: subsets of a larger network. But, a /32 implies a single IP, which isn’t really a subnet, it’s a host address. I believe that’s why you are seeing the error message about allocating a gateway and no available addresses on this pool.
Note that in allocating subnets, at least two addresses are already taken: the broadcast address, and subnet address itself. I believe you’ll need to allocate at least a /30, which would allow for two hosts. You’ll need at least one host address for the network gateway.
Check your favorite search engine for more information on what is a subnet and how to allocate them.
Thanks for the answers, I’m sorry for the confusion.
The failover IP-addresses that I’ve acquired from SoYouStart uses the subnet /32, which is the reason why I try to create a docker network with that single IP-address. (https://docs.ovh.com/gb/en/public-cloud/configure_a_failover_ip/). Note that those IP’s are public addresses.
I now that subnetting is for creating networks with a range of ip-addresses, but as I only have one IP address in that range the subnet is /32.
Maybe I have miss understood that docker networks is not for public addresses but for creating a virtual private network on the host. Is that correct understood?
I am afraid, it is like bryceryan wrote: a 32bit CIDR subnet is not possible.
If you don’t specify an existing gateway, docker will create one for you. Either the problem is that docker tries to create a gateway and has no free ip available, or less likely that you didn’t specify a gateway while creating the network.
You could solve the floating ip problem on the host directly, as the engine will listen on all interfaces. You could use --network=host to directly use the hosts network interfaces. Wouldn’t that solve your problem?
When I did that and used the --ip argument it gives me this error.
$ docker run --rm --network host --ip 147.135.x.x byrnedo/alpine-curl https://ifconfig.me/
docker: Error response from daemon: user specified IP address is supported on user defined networks only.
As mentioned in the start, I do not want the container to listen to all interfaces, but only a single one.
So if Server1 starts a service on port 25565, then Server2 should also be able to start a service on port 25565, and that is not possible if the containers are listening on all interfaces
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. The point of creating docker networks is to have IP addresses available for containers to use. 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.
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. These subnets should NOT overlap your failover IP addresses.
Then configure the failover IP addresses as secondary IP addresses on the server interface, following the instructions in the link you provided.
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):
--network <one of the created docker bridge networks for each container>
-p=<one of your failover IP addresses for each container>:<host port>:<container port>
This will start the containers and bind there network interfaces with the correct IP addresses you configured above.
This is actually close to what I need. But the problem with this solution is that only some specific ports is published, and I need all ports on the container to be public on the failover ip address.
Certainly though the number of ports is some smallish finite amount. You can repeat this pattern for each of the ports you need to expose to the outside world. If it happens to be a consecutive range of ports, you can use the shortcut:
-p <failover IP address >:<starting external port number>-<ending external port number>:<starting container port number>-<ending container port number>
Otherwise, just repeat the -p <ip>:<ext port>:<container port> pattern for each container port you need to expose on the ip address(es) externally.
You could use a normal Docker bridge and then route the /32 subnet to the IP address of a container. (You might be able to use proxy ARP if the /32 isn’t routable.)
You can add the second IP address to the container using docker exec --privileged <command to configure IP address>. Or give the container net_admin capability, which allows it to configure the IP address itself.
Maybe I’m missing something, but routing is only part of the problem, and then you’re outside the realm of using docker tools to solve the issue.
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. 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.
By routing I mean adding a static route on the host. This means the IP address is only assigned to a container and not the host. Which means you won’t use port forwarding.
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.
This routing won’t translate port numbers which means the container has to start the services on the port that should be visible externally. Is that a problem? BTW this is also true for IPv6, unless you use a reverse proxy container or similar.
It depends on how one launches the containers. 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. 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.
The way around that is not straight forward. 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. 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. But this still doesn’t account for manually configuring the external IP addresses on the containers.
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 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. The directions that the provider gives only refers to adding the failover IP address as an “alias” address on the host’s interface. Who knows if that falls apart when you rather put that IP address on the container and then add custom routing/iptables rules.
All the while, configuring the external IPs as an alias IP address on the host’s interfaces is supported by the provider already and adding port mappings (including the desired IP addresses) is a configuration supported by Docker. I don’t know how many ports the containers must make externally available, but my money would be to bite the bullet and configure as many port mappings as is needed for the application rather than having to explain to the provider and/or Docker support person what I’ve done to achieve the same thing differently when something goes astray.
That’s the reason I mentioned proxy ARP which is needed as a work-around if the provider expects the failover address to be assigned to the external interface instead via another IPv4 address.