Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Auto update containers with podman #3575

Closed
viggy96 opened this issue Jul 14, 2019 · 21 comments · Fixed by #5480
Closed

Auto update containers with podman #3575

viggy96 opened this issue Jul 14, 2019 · 21 comments · Fixed by #5480
Assignees
@vrothberg @QiWang19
Labels
kind/feature Categorizes issue or PR as related to a new feature. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. stale-issue

Comments

@viggy96
Copy link

viggy96 commented Jul 14, 2019

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind feature

Description
Is there a method of automatically updating containers when a new version is available in the repository? I use watchtower to achieve this currently with docker, and that container requires mounting the docker unix socket to work, which of course, won't work for podman. Is there another method of achieving this, or is this feature on the roadmap?
@openshift-ci-robot openshift-ci-robot added the kind/feature Categorizes issue or PR as related to a new feature. label Jul 14, 2019
@rhatdan
Copy link
Member

rhatdan commented Jul 14, 2019

Would a cron job/systemd timer work for this? Not sure what watchtower is, but it seems line it must be just checking periodically and pulling new images.

@rhatdan
Copy link
Member

rhatdan commented Jul 14, 2019

After reading https://hub.docker.com/r/v2tec/watchtower/ it looks like this would be fairly easy to implement via a systemd timer.

The issue would be if you wanted to make this general purpose. Launch a watcher on an existing container. Being able to get the command line executed, and gernate the CLI command based on it.

@viggy96
Copy link
Author

viggy96 commented Jul 15, 2019

Yeah, I want this to be general purpose for all my containers. Which is why I like that watchtower container so much, its a very simple solution to auto update all my containerised applications.

@abitrolly
Copy link
Contributor

Docker added --pull=... option to run recently. Will that help docker/cli#1498 ?

@rhatdan
Copy link
Member

rhatdan commented Jul 17, 2019

I don't think this will help, although it is something we should add to Podman. @QiWang19 Could you add --pull for podman run and create.

@rhatdan
Copy link
Member

rhatdan commented Jul 17, 2019

Or @abitrolly If you wanted to add the support that would be great also.

@mheon
Copy link
Member

mheon commented Jul 18, 2019

This is being worked on.

@QiWang19 QiWang19 mentioned this issue Jul 22, 2019
Merged
QiWang19 added a commit to QiWang19/podman that referenced this issue Aug 9, 2019
@QiWang19
add --pull flag for podman create&run
decfea6 
Requirement from containers#3575 (comment)

Added --pull for podman create and pull to match the newly added flag in docker CLI.
`missing`: default value, podman will pull the image if it does not exist in the local.
`always`: podman will always pull the image.
`never`: podman will never pull the image.

Signed-off-by: Qi Wang <[email protected]>
@github-actions
Copy link

github-actions bot commented Nov 3, 2019

This issue had no activity for 30 days. In the absence of activity or the "do-not-close" label, the issue will be automatically closed within 7 days.

@github-actions
Copy link

A friendly reminder that this issue had no activity for 30 days.

@vrothberg vrothberg self-assigned this Jan 21, 2020
@delight
Copy link

delight commented Jan 23, 2020

Yeah, I want this to be general purpose for all my containers. Which is why I like that watchtower container so much, its a very simple solution to auto update all my containerised applications.

In watchtower the behavior configureable over labels:

https://containrrr.github.io/watchtower/container-selection/

@viggy96
Copy link
Author

viggy96 commented Jan 23, 2020

@delight That's not what I want though. I want to have podman update all my containers just like watchtower does by default.

@delight
Copy link

delight commented Jan 24, 2020

@viggy96 anyways I think you are addressing your request to the wrong project though. IMO it's rather an implementation detail of watchtower. Right now watchtower is accessing the docker api via go. It's rather up to watchtower to support podman additionally.

@viggy96
Copy link
Author

viggy96 commented Jan 24, 2020

@delight I was just using watchtower as an example. I'm not expecting podman guys to support watchtower. I was asking for a similar solution that would work for podman. @vrothberg has already taken up this issue, so I'd say its very relevant to this project.

@mrguitar
Copy link

+1 to having a mechanism to generate timers for this. That would be great.

@rhatdan
Copy link
Member

rhatdan commented Feb 17, 2020

@vrothberg any progress on this?

@vrothberg
Copy link
Member

No. The v2 API has a higher priority. I will tackle it after my PTO along with the open systemd issues.

@vrothberg vrothberg mentioned this issue Mar 12, 2020
Merged
@vrothberg
Copy link
Member

I opened #5480 to support auto-updating containers. Feel free to play with it and provide feedback.

vrothberg added a commit to vrothberg/libpod that referenced this issue Mar 16, 2020
@vrothberg
auto updates
606e43e 
Add support to auto-update containers running in systemd units as
generated with `podman generate systemd --new`.

`podman auto-update` looks up containers with a specified
"io.containers.autoupdate" label (i.e., the auto-update policy).

If the label is present and set to "image", Podman reaches out to the
corresponding registry to check if the image has been updated.  We
consider an image to be updated if the digest in the local storage is
different than the one of the remote image.  If an image must be
updated, Podman pulls it down and restarts the container.  Note that the
restarting sequence relies on systemd.

At container-creation time, Podman looks up the "PODMAN_SYSTEMD_UNIT"
environment variables and stores it verbatim in the container's label.
This variable is now set by all systemd units generated by
`podman-generate-systemd` and is set to `%n` (i.e., the name of systemd
unit starting the container).  This data is then being used in the
auto-update sequence to instruct systemd (via DBUS) to restart the unit
and hence to restart the container.

Note that this implementation of auto-updates relies on systemd and
requires a fully-qualified image reference to be used to create the
container.  This enforcement is necessary to know which image to
actually check and pull.  If we used an image ID, we would not know
which image to check/pull anymore.

Fixes: containers#3575
Signed-off-by: Valentin Rothberg <[email protected]>
vrothberg added a commit to vrothberg/libpod that referenced this issue Mar 17, 2020
@vrothberg
auto updates
f4e873c 
Add support to auto-update containers running in systemd units as
generated with `podman generate systemd --new`.

`podman auto-update` looks up containers with a specified
"io.containers.autoupdate" label (i.e., the auto-update policy).

If the label is present and set to "image", Podman reaches out to the
corresponding registry to check if the image has been updated.  We
consider an image to be updated if the digest in the local storage is
different than the one of the remote image.  If an image must be
updated, Podman pulls it down and restarts the container.  Note that the
restarting sequence relies on systemd.

At container-creation time, Podman looks up the "PODMAN_SYSTEMD_UNIT"
environment variables and stores it verbatim in the container's label.
This variable is now set by all systemd units generated by
`podman-generate-systemd` and is set to `%n` (i.e., the name of systemd
unit starting the container).  This data is then being used in the
auto-update sequence to instruct systemd (via DBUS) to restart the unit
and hence to restart the container.

Note that this implementation of auto-updates relies on systemd and
requires a fully-qualified image reference to be used to create the
container.  This enforcement is necessary to know which image to
actually check and pull.  If we used an image ID, we would not know
which image to check/pull anymore.

Fixes: containers#3575
Signed-off-by: Valentin Rothberg <[email protected]>
snj33v pushed a commit to snj33v/libpod that referenced this issue May 31, 2020
@vrothberg @snj33v
auto updates
a67be1d 
Add support to auto-update containers running in systemd units as
generated with `podman generate systemd --new`.

`podman auto-update` looks up containers with a specified
"io.containers.autoupdate" label (i.e., the auto-update policy).

If the label is present and set to "image", Podman reaches out to the
corresponding registry to check if the image has been updated.  We
consider an image to be updated if the digest in the local storage is
different than the one of the remote image.  If an image must be
updated, Podman pulls it down and restarts the container.  Note that the
restarting sequence relies on systemd.

At container-creation time, Podman looks up the "PODMAN_SYSTEMD_UNIT"
environment variables and stores it verbatim in the container's label.
This variable is now set by all systemd units generated by
`podman-generate-systemd` and is set to `%n` (i.e., the name of systemd
unit starting the container).  This data is then being used in the
auto-update sequence to instruct systemd (via DBUS) to restart the unit
and hence to restart the container.

Note that this implementation of auto-updates relies on systemd and
requires a fully-qualified image reference to be used to create the
container.  This enforcement is necessary to know which image to
actually check and pull.  If we used an image ID, we would not know
which image to check/pull anymore.

Fixes: containers#3575
Signed-off-by: Valentin Rothberg <[email protected]>
@github-actions github-actions bot added the locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. label Sep 23, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 23, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@vrothberg vrothberg

@QiWang19 QiWang19

Labels
kind/feature Categorizes issue or PR as related to a new feature. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. stale-issue
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

auto update containers in systemd units vrothberg/libpod
9 participants
@delight @mrguitar @rhatdan @mheon @abitrolly @viggy96 @vrothberg @QiWang19 @openshift-ci-robot