Docker compose ignoring ipv4_address in container

Viewed 1199

I have following docker-compose.yaml file

version: "3.9"
services: 
  box1:
    hostname: box1
    build:
      context: .
      dockerfile: box.Dockerfile
    networks:
      testing: 
        ipv4_address: 172.28.1.10
    command: |
      /bin/sh -c 'while true; do sleep 1; done'
  box2:
    hostname: box2
    build:
      context: .
      dockerfile: box.Dockerfile
    networks:
      testing: 
        ipv4_address: 172.28.1.20
    command: |
      /bin/sh -c 'while true; do sleep 1; done'
  box3:
    hostname: box3
    build:
      context: .
      dockerfile: box.Dockerfile
    networks:
      testing: 
        ipv4_address: 172.28.1.30
    command: |
      /bin/sh -c 'while true; do sleep 1; done'
networks:
  testing:
    driver: macvlan
    driver_opts:
      parent: eth0
    ipam:
      driver: default
      config:
        - subnet: 172.28.1.0/24
          gateway: 172.28.1.1/
          aux_addresses: 
            box1: 172.28.1.10
            box2: 172.28.1.20
            box3: 172.28.1.30

I tried every combination and hint on internet, but no matter what I try, docker compose is assigning another IP addresses to containers then those I am using in specification.

When I try docker exec box_1 /bin/sh -c 'ifconfig' or dig for dns of another container, I am getting random IP addresses instead of those that are set for every container.

I am running docker desktop for mac 3.3.1 (63152)

2 Answers

I had a similar problem when using docker compose up on macOS. Using docker-compose up (note the - sign) resolved it.

Confirmed that with macOS and the latest 3.3.3 release of Docker Desktop, the docker-compose version is still 1.0-alpha and exhibits this behavior of assigned an IP address and the beginning of the network range, starting with .2

As Yannick correctly mentioned, using the external docker-compose command does assign the correct ipv4_address. Note: didn't comment on Yannick's answer as I don't the reputation yet (but I did upvote it :)).

When using docker-compose version 1.29.1, this worked correctly. In my case where I'm focused on ECS container agents, the result of docker network inspect returns the following:

[
    {
        "Name": "ggv2_dev_docker_greengrass_tes",
        "Id": "ede0aff6f7680aba4eb4a905904b1613d0d653f58cce856ff44e2b817a1f0218",
        "Created": "2021-05-14T16:15:25.974565062Z",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {
                    "Subnet": "169.254.0.0/16"
                }
            ]
        },
        "Internal": false,
        "Attachable": true,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {
            "9ab191ea02ef7b567e9883ec3a74e89eae455e843924bdd27f5a6e219d11dca2": {
                "Name": "aws-iot-greengrass-dev",
                "EndpointID": "5238d4dadeaeaa57af306859a2f3ff8ec619c9f7ebe43b632ba1caa4c2b4d2b1",
                "MacAddress": "02:42:a9:fe:aa:02",
                "IPv4Address": "169.254.170.2/16",
                "IPv6Address": ""
            }
        },
        "Options": {},
        "Labels": {
            "com.docker.compose.network": "greengrass_tes",
            "com.docker.compose.project": "ggv2_dev_docker",
            "com.docker.compose.version": "1.29.1"
        }
    }
]

where the target 169.254.170.2 is being properly assigned.

Related