You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Say I have a container built with hub.docker.com's nginx:1.22 image, which is 1.22.0 right now. After 1.22.1 is published, when watchtower runs, it'll recreate my container on top of the new 1.22.1 image.
But say I have a container created from a local image built from a local Dockerfile (say it's named my-webserver or something), FROM nginx:1.22 and with some changes on top of the upstream image (maybe it includes a certbot setup too or something, I don't know, this is just a made-up example). After 1.22.1 gets published, watchtower will check this container but won't be able to update it because it doesn't know to check for nginx:1.22 updates; this container was built from the local webserver image and watchtower doesn't know to check for new nginx:1.22 images and it doesn't know how to rebuild that my-webserver image that's FROM nginx:1.22.
Describe the solution you'd like
For those containers, is watchtower able to look one step further up the chain of images it's based on, to see the upstream image that the local image is built on top of, and rebuild the local image when it knows that the upstream image has been updated?
If not, maybe a label could be used: say com.centurylinklabs.watchtower.base-image-name, so I can label my my-webserver image with base-image-name nginx:1.22, to tell watchtower to rebuild my my-webserver image and recreate my container when nginx:1.22 has been updated.
I think either would require more tricky input than that, though; wouldn't I then need some way to tell watchtower how to rebuild the my-webserver image? Maybe it'd only need to be one more input: a path to the Dockerfile? (And maybe instead of com.centurylinklabs.watchtower.base-image-name, it's com.centurylinklabs.watchtower.dockerfile, and it gets the upstream image name from the FROM directive?
How feasible are either of these things?
Maybe, instead of support for rebuilding local images, watchtower just exposes a way to check for whether an arbitrary tag has an update to pull, instead of checking for images that currently running containers are based on, and just returns a boolean indicating whether I need to rebuild my downstream container or not. For example: I don't have any nginx:1.22 containers, only one created from a local image that was built on top of nginx:1.22, so I just ask watchtower "is there a new nginx:1.22?" in a script that then rebuilds the my-webserver image and recreates the container if watchtower's response is yes.
Describe alternatives you've considered
I could periodically rebuild my my-webserver container, say nightly, so that when a new nginx:1.22 is published it'll be applied, but this means a lot of unnecessary builds that watchtower would not cause, since watchtower only recreates containers when images have changed.
The text was updated successfully, but these errors were encountered:
This has been suggested before, but no one has implemented such a feature yet. It would probably be easier to do using #1231.
piksel
changed the title
Rebuilding local images, and recreating their containers, when the local image's upstream image has been updated
Rebuilding local images, and recreating their containers, when it's upstream image is updated
Sep 30, 2022
Is your feature request related to a problem? Please describe.
Say I have a container built with hub.docker.com's
nginx:1.22
image, which is1.22.0
right now. After1.22.1
is published, when watchtower runs, it'll recreate my container on top of the new1.22.1
image.But say I have a container created from a local image built from a local Dockerfile (say it's named
my-webserver
or something),FROM nginx:1.22
and with some changes on top of the upstream image (maybe it includes a certbot setup too or something, I don't know, this is just a made-up example). After1.22.1
gets published, watchtower will check this container but won't be able to update it because it doesn't know to check fornginx:1.22
updates; this container was built from the localwebserver
image and watchtower doesn't know to check for newnginx:1.22
images and it doesn't know how to rebuild thatmy-webserver
image that'sFROM nginx:1.22
.Describe the solution you'd like
For those containers, is watchtower able to look one step further up the chain of images it's based on, to see the upstream image that the local image is built on top of, and rebuild the local image when it knows that the upstream image has been updated?
If not, maybe a label could be used: say
com.centurylinklabs.watchtower.base-image-name
, so I can label mymy-webserver
image withbase-image-name nginx:1.22
, to tell watchtower to rebuild mymy-webserver
image and recreate my container whennginx:1.22
has been updated.I think either would require more tricky input than that, though; wouldn't I then need some way to tell watchtower how to rebuild the
my-webserver
image? Maybe it'd only need to be one more input: a path to the Dockerfile? (And maybe instead ofcom.centurylinklabs.watchtower.base-image-name
, it'scom.centurylinklabs.watchtower.dockerfile
, and it gets the upstream image name from theFROM
directive?How feasible are either of these things?
Maybe, instead of support for rebuilding local images, watchtower just exposes a way to check for whether an arbitrary tag has an update to pull, instead of checking for images that currently running containers are based on, and just returns a boolean indicating whether I need to rebuild my downstream container or not. For example: I don't have any
nginx:1.22
containers, only one created from a local image that was built on top ofnginx:1.22
, so I just ask watchtower "is there a newnginx:1.22
?" in a script that then rebuilds themy-webserver
image and recreates the container if watchtower's response is yes.Describe alternatives you've considered
I could periodically rebuild my
my-webserver
container, say nightly, so that when a newnginx:1.22
is published it'll be applied, but this means a lot of unnecessary builds that watchtower would not cause, since watchtower only recreates containers when images have changed.The text was updated successfully, but these errors were encountered: