opensource/podman
1
0
Fork 0
mirror of https://github.com/containers/podman.git synced 2025-10-16 18:53:19 +08:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #10063 from ParkerVR/autoupdate-local

Browse Source 
Autoupdate Local
This commit is contained in:
OpenShift Merge Robot
2021-04-29 13:37:50 -04:00
committed by GitHub
parent c01b1cbfcd caf19efdab
commit 4d2ba323f2
3 changed files with 205 additions and 58 deletions
Download Patch File Download Diff File Expand all files Collapse all files

55
docs/source/markdown/podman-auto-update.1.md
View File

@ -9,21 +9,25 @@ podman-auto-update - Auto update containers according to their auto-update polic
## DESCRIPTION
`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.
If the label is present and set to "registry", Podman reaches out to the corresponding registry to check if the image has been updated.
The label "image" is an alternative to "registry" maintained for backwards compatibility.
An image is considered 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 systemd unit executing the container.
The registry policy requires a requires a fully-qualified image reference (e.g., quay.io/podman/stable:latest) to be used to create the container.
This enforcement is necessary to know which image to actually check and pull.
If an image ID was used, Podman would not know which image to check/pull anymore.
Alternatively, if the autoupdate label is set to "local", Podman will compare the image a container is using to the image with it's raw name in local storage.
If an image is updated locally, Podman simply restarts the systemd unit executing the container.
If "io.containers.autoupdate.authfile" label is present, Podman reaches out to corresponding authfile when pulling images.
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 `podman auto-update` relies on systemd and requires a fully-qualified image reference (e.g., quay.io/podman/stable:latest) to be used to create the container.
This enforcement is necessary to know which image to actually check and pull.
If an image ID was used, Podman would not know which image to check/pull anymore.
Moreover, the systemd units are expected to be generated with `podman-generate-systemd --new`, or similar units that create new containers in order to run the updated images.
Note that`podman auto-update` relies on systemd. The systemd units are expected to be generated with `podman-generate-systemd --new`, or similar units that create new containers in order to run the updated images.
Systemd units that start and stop a container cannot run a new image.
@ -44,9 +48,11 @@ environment variable. `export REGISTRY_AUTH_FILE=path`
## EXAMPLES
Autoupdate with registry policy
```
# Start a container
$ podman run --label "io.containers.autoupdate=image" \
$ podman run --label "io.containers.autoupdate=registry" \
--label "io.containers.autoupdate.authfile=/some/authfile.json" \
-d busybox:latest top
bc219740a210455fa27deacc96d50a9e20516492f1417507c13ce1533dbdcd9d
@ -70,5 +76,40 @@ $ podman auto-update
container-bc219740a210455fa27deacc96d50a9e20516492f1417507c13ce1533dbdcd9d.service
```
Autoupdate with local policy
```
# Start a container
$ podman run --label "io.containers.autoupdate=local" \
-d busybox:latest top
be0889fd06f252a2e5141b37072c6bada68563026cb2b2649f53394d87ccc338
# Generate a systemd unit for this container
$ podman generate systemd --new --files be0889fd06f252a2e5141b37072c6bada68563026cb2b2649f53394d87ccc338
/home/user/containers/libpod/container-be0889fd06f252a2e5141b37072c6bada68563026cb2b2649f53394d87ccc338.service
# Load the new systemd unit and start it
$ mv ./container-be0889fd06f252a2e5141b37072c6bada68563026cb2b2649f53394d87ccc338.service ~/.config/systemd/user
$ systemctl --user daemon-reload
# If the previously created containers or pods are using shared resources, such as ports, make sure to remove them before starting the generated systemd units.
$ podman stop be0889fd06f252a2e5141b37072c6bada68563026cb2b2649f53394d87ccc338
$ podman rm be0889fd06f252a2e5141b37072c6bada68563026cb2b2649f53394d87ccc338
$ systemctl --user start container-be0889fd06f252a2e5141b37072c6bada68563026cb2b2649f53394d87ccc338.service
# Get the name of the container
$ podman ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
01f5c8113e84 docker.io/library/busybox:latest top 2 seconds ago Up 3 seconds ago inspiring_galileo
# Modify the image
$ podman commit --change CMD=/bin/bash inspiring_galileo busybox:latest
# Auto-update the container
$ podman auto-update
container-be0889fd06f252a2e5141b37072c6bada68563026cb2b2649f53394d87ccc338.service
```
## SEE ALSO
podman(1), podman-generate-systemd(1), podman-run(1), systemd.unit(5)