Increase Docker network

I only have extremely basic experience with Docker networking as well, but three things come to mind:

1) I don't think you want to manually modify daemon.json to configure networking -- there is a series of commands via docker network  that you should probably execute from shell instead.

2) All of your running Docker containers are already assigned addresses & subnets -- I don't think manual/forced changes to the network while they're running will end well! In a "best case scenario" they might re-connect to a new network scope after a restart... but if they don't you'll lose IP connectivity to your existing containers.

3) In what network do you suspect you've expended all available IP leases?(!) For example "bridge" or "host"? By default Docker networks are Class B ranges, which in theory can accommodate 65,534 hosts per network! How many containers are you running? haha

read about docker network create.

you can create one new network on omv-compose webGUI too. ( 255 IP)

Zitat von Copaxy

I have around 30 containers and I get the message that there are no available IP addresses left for new containers.

That does sound very strange indeed -- I can't say I've run more than 30 containers on any single host but no doubt it should be capable of much more.

Question:

How are you deploying your containers? Compose plug-in, portainer, cli?

If using the plug-in or portainer stacks, you can use the network commands in the compose files to easily create and attach to different networks. Containers will automatically create and attach to a network on launch. If the network were to get pruned, the network gets re-created on launch.

I have 30+ containers running but I like to group them on different docker networks based on purpose, using a combination of the network commands and multi container compose files (I use portainer) ie. web accessible stuff is on a “web” network, admin related stuff on an “admin” network, central database related stuff on a “database” network, etc. I don’t do this for ip limits, but more for organization and a little increased isolation of web accessible containers.

I should also note that the subnet mask on a network dictates the the number of available up addresses. A /24 network can handle 256 ip addresses (first and last are usually reserved so 254 usable) a /16 network can handle 65534 addresses, so I highly doubt you are running out of ip addresses unless you have been messing with something that has broken the networking.

Zitat von Copaxy

But obviously it gets reset after a restart of the host machine

if you want to use custom /etc/docker/daemon.json

Zitat

The reason why I think reconfiguring their network makes sense is because some containers will never use so many IP like in a /16 network, but they block the IP range for other containers. So I think I will create a small network for containers who do not use so many IPs. Previously I was a bit wasting IP range because I never assumed I will have so many containers. Turns out I was wrong and I need them. 😅

You are getting too focused on the whole ip address thing. There is no need to go carving up the docker networks into smaller ranges. A container will not block another container from using available Ip addresses on a given network.

There are really only two things you have to worry about with docker networks:

1) What is the network name and what containers do you have on it

2) Does a container require a LAN ip instead of a docker ip (Things like a pihole container require this and as such need to be attached to a macvlan)

Zitat

One question related to docker network prune. You said if I prune a network, by accident it gets recreated after restart. Will the configuration also be recreated, or is the container done, and I have to reconfigure it. Because once I have accidentally pruned my nextcloud network and everything was messed up. I had to reconfigure it.

When networks are declared in a compose file, they get created when the compose file is run by docker. This will download what the container needs if is isn't already on your system and then create and deploy the container and in this case the network too. The container will always have the same name and always be created as long as the container is running.

Pruning will not remove anything that is in use by a container, but it can remove things that are left behind after a container is shut down because the down command removes the container's dynamic data. (docker containers are made in layers there is the container image itself that gets downloaded, then there is the dynamic data that the container image may generate, then there is the user data, which is usually in a docker volume or a bind mount. All these layers combine to make the application)

Here is an example of a simple multi-container stack with a defined network at the bottom. This deploys both of these sample containers onto the same network it is creating (edit the required storage paths to match your system or anything else that needs to be modified) There has been nothing done to change the subnets on this network. The network allows for 65534 ip addresses, which equates to 65534 containers. If I make a stack using a different network that network also allows for 65534 containers because the network is a different ip range.

version: "3.7"

services:

  docker-autocompose:
    container_name: docker-autocompose
    environment:
      - PYTHON_GET_PIP_SHA256=5aefe6ade911d997af080b315ebcb7f882212d070465df544e1175ac2be519b4
      - PYTHON_GET_PIP_URL=https://github.com/pypa/get-pip/raw/5eaac1050023df1f5c98b173b248c260023f2278/public/get-pip.py
      - PYTHON_PIP_VERSION=22.2.2
      - PYTHON_SETUPTOOLS_VERSION=63.2.0
      - PYTHON_VERSION=3.10.7
      - PATH=/usr/local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
      - LANG=C.UTF-8
      - GPG_KEY=A035C8C19219BA821ECEA86B64E628F8D684696D
    image: ghcr.io/red5d/docker-autocompose:latest

  mediainfo:
    container_name: mediainfo
    restart: always
    ports:
      - 5810:5800
    volumes:
      - /path/to/config:/config
      - /path/to/media:/storage:ro
    image: jlesage/mediainfo

networks:
  default:
    name: network_name
    driver: bridge
    #external: true #-uncomment/remove the # before "external" if the network has already been created by another stack or manually created and you just want to attach to it

This is the "blueprint" for the build. If you remove a container and deploy with this blueprint, it will all get created the same. The things that will not be the same is the dynamic and user data if those are also removed since they are not part of the image declared for use in the compose file.

Zitat von Copaxy

Okey understand.

Ah, okay so the dynamic data gets removed.

Thanks a lot of the useful information. I think this will solve a lot of network issues in the future. 😊

Alles anzeigen

Dynamic data that is bound to a directory does not get removed. but when a container is taken down the build layers are removed. If it stores data in a docker volume instead of a bind mount, a volume prune will then remove that data because it is not in use by a container.