Skip to content
This repository has been archived by the owner on Nov 27, 2023. It is now read-only.

docker compose up does not allocate static IP properly #1582

Closed
LaendaEagle opened this issue Apr 22, 2021 · 8 comments · Fixed by #1633
Closed

docker compose up does not allocate static IP properly #1582

LaendaEagle opened this issue Apr 22, 2021 · 8 comments · Fixed by #1633
Labels
compatibility Compatibility with docker-compose

Comments

@LaendaEagle
Copy link


BUG REPORT INFORMATION

Description

I have multiple applications managed in multiple projects. For some technical reason I need those applications to run on the same network with fixed IPs (as the IP is stored in some places).
For that I have a docker-compose.yml setting the network up with appropriate driver and range. Then I refer to this network from my other docker-compose.yml file where I assign the IP address to my application.
All this work fine with docker-compose up but the fixed IP is not allocated with docker compose up instead the next free IP of my named network is used.
Just to be clear I restate it: this is working with docker-compose, not with the docker compose new flavour available with Docker Desktop 3.3.1 (Mac).

Steps to reproduce the issue:

  1. cd network
  2. docker compose up -d
  3. cd ../application
  4. docker compose up -d
  5. docker inspect

Describe the results you received:
The IP of my application's container is 172.22.0.3

Describe the results you expected:
The IP of my application's container is 172.22.0.18

Additional information you deem important (e.g. issue happens only occasionally):
file: network/docker-compose.yml

version: "3.5"
services:
  web:
    image: nginx:latest
    networks:
        default:
            ipv4_address: 172.22.0.2

networks:
  default:
    name: testnetwork
    driver: bridge
    ipam:
      config:
        - subnet: 172.22.0.0/24

file: application/docker-compose.yml

version: "3.5"
services:
  application:
    image: nginx:latest
    networks:
        default:
            ipv4_address: 172.22.0.18
networks:
  default:
    name: testnetwork

Output of docker version:

Client: Docker Engine - Community
 Cloud integration: 1.0.12
 Version:           20.10.5
 API version:       1.41
 Go version:        go1.13.15
 Git commit:        55c4c88
 Built:             Tue Mar  2 20:13:00 2021
 OS/Arch:           darwin/amd64
 Context:           default
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          20.10.5
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.13.15
  Git commit:       363e9a8
  Built:            Tue Mar  2 20:15:47 2021
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.4.4
  GitCommit:        05f951a3781f4f2c1911b05e61c160e9c30eaa8e
 runc:
  Version:          1.0.0-rc93
  GitCommit:        12644e614e25b05da6fd08a38ffa0cfe1903fdec
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0
@LaendaEagle
Copy link
Author

Hello,

I got the Docker Desktop 3.5.1 on MacOS and now docker-compose and docker compose are running the same binary and the issue exposed here is present.
That means I don't have a fallback any more to docker-compose to avoid the issue and all my developer environment is stuck because the expected IP for each container is not the correct one.

Do I have to change something in the docker-compose.yml file to have the new implementation work?

Here is my current docker version:

Client:
Cloud integration: 1.0.17
Version: 20.10.7
API version: 1.41
Go version: go1.16.4
Git commit: f0df350
Built: Wed Jun 2 11:56:22 2021
OS/Arch: darwin/amd64
Context: desktop-linux
Experimental: true

Server: Docker Engine - Community
Engine:
Version: 20.10.7
API version: 1.41 (minimum version 1.12)
Go version: go1.13.15
Git commit: b0f5bc3
Built: Wed Jun 2 11:54:58 2021
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.4.6
GitCommit: d71fcd7d8303cbf684402823e425e9dd2e99285d
runc:
Version: 1.0.0-rc95
GitCommit: b9ee9c6314599f1b4a7f497e1f1f856fe433d3b7
docker-init:
Version: 0.19.0
GitCommit: de40ad0

@mat007
Copy link
Contributor

mat007 commented Jun 30, 2021

@LaendaEagle there is a switch in the Desktop settings in the Experimental section to go back to Compose V1.

@mat007
Copy link
Contributor

mat007 commented Jun 30, 2021

But it looks like this should have been fixed almost two months ago and should have been shipped with Desktop 3.5.1.
Do you still experience this issue?

@ndeloof
Copy link
Collaborator

ndeloof commented Jun 30, 2021

@mat007 there was a remaining issue with network configuration, fixed by #1827

@LaendaEagle
Copy link
Author

OK, I unchecked the usage of compose v2. I don't know why it got checked (perhaps a mistake I did), thank you for your quick answer :)

And yeah, I am testing docker compose with my setup every new release of Docker Desktop and the issue is still there.

@mat007
Copy link
Contributor

mat007 commented Jun 30, 2021

I don't know why it got checked

Because we are including some users randomly selected into the Compose V2 canary rollout, see «Compose V2 beta» in the release notes.
Sorry for the inconvenience.

@LaendaEagle
Copy link
Author

No problem, I found good to have the possibility to access beta in one click so we can test new stuff easily. And for a dev environment it is good to be on the latest release possible for the need we have.

@LaendaEagle
Copy link
Author

Just to give you a feedback, Docker Desktop 3.5.2 contains the correction and it is working like a charm :)
Thank you for your great support.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
compatibility Compatibility with docker-compose
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants