louislam
Mac Address Parameter Ignored in Compose File
⚠️ Please verify that this bug has NOT been reported before.
- [X] I checked and didn't find similar issue
🛡️ Security Policy
- [X] I agree to have read this project Security Policy
Description
I am deploying a number of containers all of which have a static mac address assigned so that i can create firewall rules and allow access to various devices and internet.
The compose i am using is detailed as below
version: "3.8"
services:
pihole0:
container_name: pihole0
build:
context: /share/docker/build/pihole/
dockerfile: /share/docker/build/pihole/Dockerfile
image: mypihole/pihole-unbound:latest
hostname: pihole0
domainname: lan.prcomputers.co.uk
mac_address: 02:42:df:bb:cf:e1
ports:
- 443:443/tcp
- 53:53/tcp
- 53:53/udp
- 80:80/tcp
- 2222:2222/tcp
- 9167:9167/tcp
environment:
.....
networks:
qnet-static-eth4:
ipv4_address:
volumes:
- /share/docker/volumes/pihole0/config/pihole:/etc/pihole/
- /share/docker/volumes/pihole0/config/dnsmasq.d:/etc/dnsmasq.d/
- /share/docker/volumes/pihole0/config/gravity-sync/:/config/gravity-sync/
restart: unless-stopped
networks:
qnet-static-eth4:
external: true
When i run an inspect on the container the mac address is different from that in the compose file
"NetworkID": "a4b2f965df64726ab956f048f258593f6561eb465030e441c6201df7c767dae7",
"EndpointID": "ecb2a0603762b97355671c7057712020b1c9a4685199df5aa3cea5f393761610",
"Gateway": "XXXXXXXXXX",
"IPAddress": "XXXXXXXXXX",
"IPPrefixLen": 24,
"IPv6Gateway": "",
"GlobalIPv6Address": "",
"GlobalIPv6PrefixLen": 0,
"MacAddress": "02:42:a5:12:6b:d8",
"DriverOpts": null
If i restart the container the mac address changes but should remain static to what is set in compose file
"NetworkID": "a4b2f965df64726ab956f048f258593f6561eb465030e441c6201df7c767dae7",
"EndpointID": "32e43880c270bbd62eb09cf9c91dc77490f59846c388a70c3dada6019246c3d7",
"Gateway": "192.168.10.1",
"IPAddress": "192.168.10.200",
"IPPrefixLen": 24,
"IPv6Gateway": "",
"GlobalIPv6Address": "",
"GlobalIPv6PrefixLen": 0,
"MacAddress": "02:42:4f:e1:3a:97",
"DriverOpts": null
This code was lifted from an existing deployment which worked without issue and kept the same mac address when i deployed directly with docker compose
👟 Reproduction steps
Created compose file with mac_address parameter Deployed container Checked mac_address with docker inspect pihole0
👀 Expected behavior
The mac address should remain static when specified in compose file and between docker restarts
😓 Actual Behavior
The mac address changes each time contain is restarted
Dockge Version
1.2.0
💻 Operating System and Arch
Linux qnap 5.10.60-qnap #1 SMP Tue Sep 26 01:46:28 CST 2023 x86_64 GNU/Linux
🌐 Browser
N/A
🐋 Docker Version
Docker version 20.10.22-qnap7, build 57ed8b8
🟩 NodeJS Version
Unknown
📝 Relevant log output
No errors given when deployed
Realised i was not on latest version of Dockge v1.3.3
Deployed latest version of dockge from v1.2.0 and issue is no longer present and container keeps static mac address as per parameter.
Tried again this morning and redeployed same container from Dockge and it was given a new mac address.
Deployed with compose directly from OS and it was given the correct mac address so something is still not right
I think you should reconfirm this, because Dockge is just running a command "docker compose up -d" for you. Nothing special.
It could be a bug of docker compose v2.
I have just created a new grafana container in Dockge and deployed using the following compose
version: "3.5"
services:
grafana:
image: grafana/grafana:latest
container_name: grafana
mac_address: 02:42:19:19:c3:c8
ports:
- 3000:3000
networks:
qnet-static-eth4:
ipv4_address: XXXXXXXXXXXXXXXXXXX
environment:
- GF_SECURITY_ADMIN_USER=admin
- GF_SECURITY_ADMIN_PASSWORD=XXXXXXXXXXXXX
volumes:
- data:/var/lib/grafana
- config:/etc/grafana
restart: unless-stopped
labels:
- com.centurylinklabs.watchtower.enable=true
networks:
qnet-static-eth4:
external: true
volumes:
data:
driver: local
driver_opts:
o: bind
type: none
device: /share/docker/volumes/grafana/data
config:
driver: local
driver_opts:
o: bind
type: none
device: /share/docker/volumes/grafana/config
When i run a docker inspect the mac address is not the same as the parameter specified
],
"NetworkID": "a4b2f965df64726ab956f048f258593f6561eb465030e441c6201df7c767dae7",
"EndpointID": "6ab18cf070c5cf0ae7c255d570b09bf19f4d3f2df293a5b261ee48bac27b2a0d",
"Gateway": "192.168.10.1",
"IPAddress": "192.168.10.205",
"IPPrefixLen": 24,
"IPv6Gateway": "",
"GlobalIPv6Address": "",
"GlobalIPv6PrefixLen": 0,
**"MacAddress": "02:42:ff:4b:ea:8c",**
"DriverOpts": null
}
}
If i then delete and recreate the container from the OS using the compose file generated by dockge i have no issues
[admin@qnap ~]# docker stop grafana
[admin@qnap ~]# docker rm grafana
[admin@qnap ~]# cd /share/docker/stacks/grafana
[admin@qnap grafana]# docker compose -f compose.yaml up -d
[+] Running 1/1
⠿ Container grafana Started
[admin@qnap grafana]# docker inspect grafana
"NetworkID": "a4b2f965df64726ab956f048f258593f6561eb465030e441c6201df7c767dae7",
"EndpointID": "5aaec3e574af14fe06792b439b11e3a3c4df47139dbd1f806ee2ed115382fcd9",
"Gateway": "192.168.10.1",
"IPAddress": "192.168.10.205",
"IPPrefixLen": 24,
"IPv6Gateway": "",
"GlobalIPv6Address": "",
"GlobalIPv6PrefixLen": 0,
**"MacAddress": "02:42:19:19:c3:c8",**
"DriverOpts": null
}
}
}
}
]
So something is not right for me when i deploy using Dockge as the mac_address is not being configured to what i use in compose file. I can deploy from OS and everything works correctly but it kind of defeats the object of me using Dockge
Should be an upstream bug: https://github.com/docker/compose/issues/11041
What is your docker compose version on your host?
docker compose version
Edit: They said it has been fixed, but haven't release it yet. I will update it once they released the fixed.
At this moment, you should keep using your host's docker-compose and don't update it.
[admin@qnap grafana]# docker compose version Docker Compose version v2.14.1-qnap1
Yes, your version is older.
Dockge is using the newer version 2.21.0 which contains this bug.
We should wait until they released the bug fix.