search

containrrr / watchtower

A process for automating Docker container base image updates.
https://containrrr.dev/watchtower/
Apache License 2.0
19.4k stars 855 forks source link

Not properly applying container.networks.mac_address gives random MAC #1941

Open NonaSuomy opened 8 months ago

NonaSuomy commented 8 months ago

Describe the bug

I have 30 dockers that obtain their IP address by static set MAC addresses that get DHCP dished out by dnsmasq that are set in the dnsmasq config.

dnsmasq.conf

# Portainer Docker Container
dhcp-host=de:ad:be:ef:ca:fe,10.0.10.42

Watchtower is deployed like this:

version: "3.9"
services:
  watchtower:
    container_name: "watchtower"
    hostname: "watchtower"
    image: "containrrr/watchtower:latest-dev"
    labels:
      - "com.centurylinklabs.watchtower.enable=true"
    restart: "no"  
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - /etc/localtime:/etc/localtime:ro
    networks:
      dhcp:
        mac_address: "de:ad:be:ef:fa:ce"
    #'0 0 15 ? * FRI' At 04:00 AM, only on Friday (Currently Check everyday at 4AM)  
    environment:
      WATCHTOWER_LABEL_ENABLE: "true"
      WATCHTOWER_MONITOR_ONLY: "false"
      WATCHTOWER_DEBUG: "true"
      WATCHTOWER_TRACE: "false"
      WATCHTOWER_CLEANUP: "true"
      WATCHTOWER_SCHEDULE: "0 0 16 * * *"
      WATCHTOWER_NOTIFICATION_REPORT: "true"
      WATCHTOWER_NOTIFICATION_URL: >
        discord://####@########
      WATCHTOWER_NOTIFICATION_TEMPLATE: |
        {{- if .Report -}}
          {{- with .Report -}}
        {{len .Scanned}} Scanned, {{len .Updated}} Updated, {{len .Failed}} Failed
              {{- range .Updated}}
        - {{.Name}} ({{.ImageName}}): {{.CurrentImageID.ShortID}} updated to {{.LatestImageID.ShortID}}
              {{- end -}}
              {{- range .Fresh}}
        - {{.Name}} ({{.ImageName}}): {{.State}}
            {{- end -}}
            {{- range .Skipped}}
        - {{.Name}} ({{.ImageName}}): {{.State}}: {{.Error}}
            {{- end -}}
            {{- range .Failed}}
        - {{.Name}} ({{.ImageName}}): {{.State}}: {{.Error}}
            {{- end -}}
          {{- end -}}
        {{- else -}}
          {{range .Entries -}}{{.Message}}{{"\n"}}{{- end -}}
        {{- end -}}
      WATCHTOWER_NOTIFICATION_TITLE_TAG: "HQ"
      WATCHTOWER_NOTIFICATIONS_HOSTNAME: "HQ001"
      WATCHTOWER_NOTIFICATIONS: "email"
      WATCHTOWER_NOTIFICATION_EMAIL_FROM: "#########@####.###"
      WATCHTOWER_NOTIFICATION_EMAIL_TO: "#########@####.###"
      WATCHTOWER_NOTIFICATION_EMAIL_SUBJECTTAG: "HQ"
      WATCHTOWER_NOTIFICATION_EMAIL_SERVER: "smtp.####.###"
      WATCHTOWER_NOTIFICATION_EMAIL_SERVER_PORT: ###
      WATCHTOWER_NOTIFICATION_EMAIL_SERVER_USER: "#########@####.###"
      WATCHTOWER_NOTIFICATION_EMAIL_SERVER_PASSWORD: "##########"
      WATCHTOWER_NOTIFICATION_EMAIL_DELAY: 2

networks:
  dhcp:
    name: "dbrv700"
    external: true

They have recently changed where you put mac_address: in docker engine v25 to under the network section:

https://docs.docker.com/compose/compose-file/05-services/#mac_address-1

mac_address
Available with Docker Compose version 2.24.0 and later.

mac_address sets a MAC address for the service container.

Note Container runtimes might reject this value (ie. Docker Engine >= v25.0). In that case, you should use networks.mac_address instead.

Here is an example of the old mac_address usage: Name: testmac

version: '3.8' 
services:
  nginx:
    image: nginx:latest
    mac_address: de:ad:be:ef:00:02
    networks:
      - dnsmasq
networks:
  dhcp:
    name: dbrv100
    external: true

The new way example:

version: '3.8' 
services:
  nginx:
    image: nginx:latest
    networks:
      dnsmasq:
        mac_address: de:ad:be:ef:00:02
networks:
  dnsmasq:
    name: dbrv100
    external: true

Steps to reproduce

My containers get deployed from portainer which after upgrading their internal usage of docker-compose to the latest version solved this problem of not accepting mac_address at all and giving you a random MAC address.

After that, I was like yay problems are gone. Then I got an email from watchtower that the containers were updated... which then gave them all random MAC addresses again which then gave random IPs instead of their static set ones.

I jumped back in portainer and redeployed the stacks and boom MAC Address set to their proper static address again. Rinse and repeat watchtower runs, random MACs again.

Expected behavior

Static set MAC addresses getting properly set.

Screenshots

No response

Environment

Server: Engine: Version: 25.0.3 API version: 1.44 (minimum version 1.24) Go version: go1.22.0 Git commit: f417435e5f Built: Thu Feb 29 20:50:13 2024 OS/Arch: linux/amd64 Experimental: false containerd: Version: v1.7.13 GitCommit: 7c3aca7a610df76212171d200ca3811ff6096eb8.m runc: Version: 1.1.12 GitCommit: docker-init: Version: 0.19.0 GitCommit: de40ad0

github-actions[bot] commented 8 months ago

Hi there! 👋🏼 As you're new to this repo, we'd like to suggest that you read our code of conduct as well as our contribution guidelines. Thanks a bunch for opening your first issue! 🙏

moltke69 commented 8 months ago

Same behavior with me. After watchtower updates a container, which has a static MAC address (from compose.yaml in networks section), the updated container changes its MAC address based on the IP-address (02:42:....) and not the defined one.

But if I manually update by "docker compose down; docker compose up" I get the static MAC address again.

NonaSuomy commented 7 months ago

Any news if there will be a fix for this?

TheUntouchable commented 5 months ago

I have the same problem. I have some stacks with fixed MAC addresses for the containers, but every time Watchtower recreates them, this MAC is not used. When I update the stack afterwards, the containers get the correct MAC.

0nnyx commented 4 weeks ago

Found this issue with a web search as am facing the same problem with macvlan containers getting new random mac addresses when watchtower updates them. Also need to recreate them manually with the right mac, which kind of defeats the purpose of watchtower for the macvlan ones. No complain for bridge containers since mac address changes are irrelevant in that context.