Reputation: 221
I am running my home wifi controller (TP-Link Omada) from a docker image in a local linux server. Unfortunately, the image was updated and the new controller version does not appear to recognize my exiting "site" / devices. The wireless access points and switch are all still working in stand-alone mode with their settings, but I can't touch/change anything until I re-adopt them into a new site I generate with the "new" controller.
I would like to prevent images from updating in the future or at the very least having a way to revert if they break like this again. What would be a good way to prevent this from happening? Here is a snippet from my docker-compose
# Omada Controller for TP-Link switches and APs
omada-controller:
container_name: omada-controller
image: mbentley/omada-controller
restart: unless-stopped
environment:
- TZ=$TZ
volumes:
- $DOCKERDIR/apps/omada/data:/opt/tplink/EAPController/data'
- $DOCKERDIR/apps/omada/work:/opt/tplink/EAPController/work'
- $DOCKERDIR/apps/omada/logs:/opt/tplink/EAPController/logs'
networks:
- t2_proxy
security_opt:
- no-new-privileges:true
ports:
- '8088:8088'
- '$OMADA_PORT:8043'
- '27001:27001/udp'
- '27002:27002'
- '27017:27017'
- '29810:29810/udp'
- '29811:29811'
- '29812:29812'
- '29813:29813'
Upvotes: 0
Views: 1452
Reputation: 541
If you dont use a tag for the image, than docker uses the latest
tag. Almost always this refers to to newest version. Just use a defined tagged version of the image. You can find the available tags for mbentley/omada-controller
here.
So if you want to use the 4.1 version, than that part in the compose file should be:
image: mbentley/omada-controller:4.1
That said, normally it shouldn't magically update the image itself. It only gets updated if you start your container and the tagged image isn't available locally. Or you run docker-compose pull
to force a pull of the images specified in the compose file.
Upvotes: 2