Compose now deploying on internal network 192.168.xxx.0 while it was previously on 172.xxx.0.0

Open Source Projects Compose
1

Hi all!

I’m using a few networks in the 192.168.xxx.0 range, and I now discover that my docker also deploys in this range, which means that it will sooner or later, it will collide with my networks.
For example, if I deploy a MariaDB like in this compose below, I now have for example 192.168.192.2 IP with 192.168.192.1 gateway. Same compose previously created 172.xxx.0.0 and 172.xxx.0.1 gateway.

Have I messed with some config somewhere?
Do you know how I can correct this?

version: "3.7"

services:
  mariadb2:
    image: mariadb:latest
    restart: unless-stopped
    volumes:
      - mariadb-data:/var/lib/mysql
      - mariadb-conf:/etc/mysql
    environment:
      MYSQL_ROOT_PASSWORD: test
    ports:
      - "3307:3306"

volumes:
  mariadb-data:
  mariadb-conf:
2

Chekck if you have unused docker networks.

docker network ls

Even if you don’t have many unused networks, sometimes, when you create and delete containers regurarly Docker cannot reuse IP ranges used in already deleted networks. I couldn’t find other solution then restarting the docker daemon when I had the same issue. Fortunately it didn’t happen very often.

Oh and I recommend you to check the live-restore feature. It could be useful if you have to restart the docker daemon without stopping services: Keep containers alive during daemon downtime | Docker Documentation

3

Thanks a lot rimelek :grinning:. I restarted the server and now it restarted using correct internal network. :+1:
Yes, I’ve played quite a bit, creating and destroying many dozen containers and networks as I try to assign fixed external IP address but can’t get it to work.
Here is my problem if you know how I can solve it:
I’m using 192.168.1.0/24 as my main network. My firewall/gateway is at 192.168.1.1. I have a few IP addresses available in this range (let’s say 192.168.1.50 to 60 for the example) and I’d like my containers use these IP (manually fixed) instead of just using docker server IP+port. This way, I can have multiple servers using port 443, because they all have different IP addresses. I’m already doing this with VM and FreeNAS jails, but cant get it to work with docker-compose. (It worked with kubernetes, but I found it to complex for my usage)
Every time I force address to be in 192.168.1.0/24 range, my docker “steals” the 192.168.1.1 IP, and as it’s already my firewall/gateway IP it causes some network troubles…
Do you know if it’s possible?

4

The keyword is “macvlan”. If you use the forum search, you should find plenty of examples and problems that are related to using macvlan and explainations as of why some problems exist and how to solve others.

5

OK thanks, I’ll search this and let you know if I need more help.

6

Thanks a lot meyay, it worked with the following file:

version: "3.7"

services:
  mariadb6:
    image: mariadb:latest
    restart: unless-stopped
    networks:
      test_net:
        ipv4_address: 192.168.1.71
    volumes:
      - mariadb-data:/var/lib/mysql
      - mariadb-conf:/etc/mysql
    environment:
      MYSQL_ROOT_PASSWORD: test
    ports:
      - "3306:3306"

volumes:
  mariadb-data:
  mariadb-conf:

networks:
  test_net:
    driver: macvlan
    driver_opts:
      parent: enp0s4
    ipam:
      config:
        - subnet: "192.168.1.0/24"
          ip_range: "192.168.1.71/32"
          gateway: "192.168.1.1"
7

This was actually a different question which should have been asked in another topic I think. This way it looks like macvlan helped you reset the IP ranges in the Docker daemon :slight_smile: It can be misleading for others. It’s OK for me, just try to focus on one question in a topic in the future so people can search for their probems more easily before asking the same.

MacVLAN could have solved your problem and sometimes it is the only real solution, but try to search for “reverse proxy” too, since that approach is older and you don’t have to reserve a number of IP addresses for a limited number of containers. In your case, if MacVLAN works perfectly and easier for you, then use that of course :slight_smile:

8

Fully, agree the OP question was solved by the first response of @rimelek.
The scenario that made macvlan a solution was introduced later.

I personaly been working with docker for 7 years, and I don’t use macvlan as I have no use case that depends on mutlicast/broadcast traffic amongst my lan machines and container.

Instead I use a reverse proxy, as Akos suggested in his last post, and use subdomain based reverse proxy rules. I have a *.domain resolving to my WAN interface (I am running my own dyndns service to keep it updated), forward port 80/443 traffic to a failover-ip:80/443 where my reverse proxy replicas is reachable. The reverse proxy takes care of keeping two letsencrypt wildcard certificates updated/available using dns-challenge and forward the traffic based on the domain name to the target container.

Additionaly I manage internal domains with unbound (I used pihole for that mater before) and let those domains resolve to the reverse proxy as well.

This way I neither have to care about registering subdomains to my dns or create letsencrypt certifcates for them. To make a container reachable by a new subdomain, I simply have to create the reverse proxy rule for it and the container is directly available from the internet.

9

yes, sorry, I should have opened another topic on this question.
I just did it with a question regarding Traefic :grinning: