Skip to content

Commit

Permalink
Merge pull request containers#19695 from vrothberg/auto-update-docs
Browse files Browse the repository at this point in the history 
[CI:DOCS] update auto-update docs
  • Loading branch information
@openshift-merge-robot
openshift-merge-robot authored Aug 22, 2023
2 parents f38668e + 75ce473 commit 260adf5
Showing 1 changed file with 50 additions and 82 deletions.
132 changes: 50 additions & 82 deletions docs/source/markdown/podman-auto-update.1.md.in
View file
Original file line number Diff line number Diff line change
Expand Up @@ -7,50 +7,47 @@ podman\-auto-update - Auto update containers according to their auto-update poli
**podman auto-update** [*options*]

## DESCRIPTION
**podman auto-update** looks up containers with a specified `io.containers.autoupdate` label (i.e., the auto-update policy).
**podman auto-update** pulls down new container images and restarts containers configured for auto updates.
To make use of auto updates, the container or Kubernetes workloads must run inside a systemd unit.
After a successful update of an image, the containers using the image get updated by restarting the systemd units they run in.
Please refer to `quadlet(5)` on how to run Podman under systemd.

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.
To configure a container for auto updates, it must be created with the `io.containers.autoupdate` label or the `AutoUpdate` field in `quadlet(5)` with one of the following two values:

* `registry`: 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 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 does not know which image to check/pull anymore.

Alternatively, if the autoupdate label is set to `local`, Podman compares the image a container is using to the image with its 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 the corresponding authfile when pulling images.
If an image ID was used, Podman would not know which image to check/pull anymore.

At container-creation time, Podman looks up the `PODMAN_SYSTEMD_UNIT` environment variable and stores it verbatim in the container's label.
This variable is now set by all systemd units generated by **[podman-generate-systemd](podman-generate-systemd.1.md)** 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.

If a container configured for auto updates is part of a pod, the pod's systemd unit is restarted and hence the entire pod and all containers inside the pod. Container updates are batched, such that a pod gets restarted at most once.

Note that **podman auto-update** relies on systemd. The systemd units are expected to be generated with **[podman-generate-systemd --new](podman-generate-systemd.1.md#--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.
* `local`: If the autoupdate label is set to `local`, Podman compares the image digest of the container to the one in the local container storage.
If they differ, the local image is considered to be newer and the systemd unit gets restarted.

### Auto Updates and Kubernetes YAML

Podman supports auto updates for Kubernetes workloads. As mentioned above, `podman auto-update` requires the containers to be running systemd. Podman ships with a systemd template that can be instantiated with a Kubernetes YAML file, see podman-generate-systemd(1).
Podman supports auto updates for Kubernetes workloads. The auto-update policy can be configured directly via `quadlet(5)` or inside the Kubernetes YAML with the Podman-specific annotations mentioned below:

To enable auto updates for containers running in a Kubernetes workload, set the following Podman-specific annotations in the YAML:
* `io.containers.autoupdate: "registry|local"` to apply the auto-update policy to all containers
* `io.containers.autoupdate/$container: "registry|local"` to apply the auto-update policy to `$container` only
* `io.containers.sdnotify: "conmon|container"` to apply the sdnotify policy to all containers
* `io.containers.sdnotify/$container: "conmon|container"` to apply the sdnotify policy to `$container` only
* `io.containers.autoupdate`: "registry|local" to apply the auto-update policy to all containers
* `io.containers.autoupdate/$container`: "registry|local" to apply the auto-update policy to `$container` only
* `io.containers.sdnotify`: "conmon|container" to apply the sdnotify policy to all containers
* `io.containers.sdnotify/$container`: "conmon|container" to apply the sdnotify policy to `$container` only

By default, the autoupdate policy is set to "disabled", the sdnotify policy is set to "conmon".

### Systemd Unit and Timer

Podman ships with a `podman-auto-update.service` systemd unit. This unit is triggered daily at midnight by the `podman-auto-update.timer` systemd timer. The timer can be altered for custom time-based updates if desired. The unit can further be invoked by other systemd units (e.g., via the dependency tree) or manually via **systemctl start podman-auto-update.service**.
Podman ships with a `podman-auto-update.service` systemd unit. This unit is triggered daily at midnight by the `podman-auto-update.timer` systemd timer.
The timer can be altered for custom time-based updates if desired.
The unit can further be invoked by other systemd units (e.g., via the dependency tree) or manually via **systemctl start podman-auto-update.service**.

## OPTIONS

@@option authfile

Alternatively, the `io.containers.autoupdate.authfile` container label can be configured. In that case, Podman will use the specified label's value instead.

#### **--dry-run**

Check for the availability of new images but do not perform any pull operation or restart any service or container.
Expand All @@ -75,80 +72,51 @@ Valid placeholders for the Go template are listed below:

If restarting a systemd unit after updating the image has failed, rollback to using the previous image and restart the unit another time. Default is true.

Note that detecting if a systemd unit has failed is best done by the container sending the READY message via SDNOTIFY. This way, restarting the unit waits until having received the message or a timeout kicked in. Without that, restarting the systemd unit may succeed even if the container has failed shortly after.
Note that detecting if a systemd unit has failed is best done by the container sending the READY message via SDNOTIFY.
This way, restarting the unit waits until having received the message or a timeout kicked in.
Without that, restarting the systemd unit may succeed even if the container has failed shortly after.

For a container to send the READY message via SDNOTIFY it must be created with the `--sdnotify=container` option (see podman-run(1)). The application running inside the container can then execute `systemd-notify --ready` when ready or use the sdnotify bindings of the specific programming language (e.g., sd_notify(3)).
For a container to send the READY message via SDNOTIFY it must be created with the `--sdnotify=container` option (see podman-run(1)).
The application running inside the container can then execute `systemd-notify --ready` when ready or use the sdnotify bindings of the specific programming language (e.g., sd_notify(3)).

@@option tls-verify

## EXAMPLES
Autoupdate with registry policy

Create a Quadlet file configured for auto updates:
```
### Start a container
$ podman run --label "io.containers.autoupdate=registry" \
--label "io.containers.autoupdate.authfile=/some/authfile.json" \
-d --name=test registry.fedoraproject.org/fedora:latest sleep infinity
bc219740a210455fa27deacc96d50a9e20516492f1417507c13ce1533dbdcd9d

### Generate a systemd unit for this container
$ podman generate systemd --new --files bc219740a210455fa27deacc96d50a9e20516492f1417507c13ce1533dbdcd9d
/home/user/container-bc219740a210455fa27deacc96d50a9e20516492f1417507c13ce1533dbdcd9d.service

### Load the new systemd unit and start it
$ mv ./container-bc219740a210455fa27deacc96d50a9e20516492f1417507c13ce1533dbdcd9d.service ~/.config/systemd/user/container-test.service
$ 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 bc219740a210455fa27deacc96d50a9e20516492f1417507c13ce1533dbdcd9d
$ podman rm bc219740a210455fa27deacc96d50a9e20516492f1417507c13ce1533dbdcd9d

$ systemctl --user start container-test.service

### Check if a newer image is available
$ podman auto-update --dry-run --format "{{.Image}} {{.Updated}}"
registry.fedoraproject.org/fedora:latest pending

### Autoupdate the services
$ podman auto-update
UNIT CONTAINER IMAGE POLICY UPDATED
container-test.service 08fd34e533fd (test) registry.fedoraproject.org/fedora:latest registry false
$ cat ~/.config/containers/systemd/sleep.container
[Container]
Image=registry.fedoraproject.org/fedora:latest
Exec=sleep infinity
AutoUpdate=registry
```

Autoupdate with local policy

Generate a systemd service from the Quadlet file by reloading the systemd user daemon:
```
### 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/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
Start the systemd service and make sure the container is running
```
$ systemctl --user start sleep.service
$ podman ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
01f5c8113e84 docker.io/library/busybox:latest top 2 seconds ago Up 3 seconds inspiring_galileo
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
f8e4759798d4 registry.fedoraproject.org/fedora:latest sleep infinity 2 seconds ago Up 2 seconds systemd-sleep
```

### Modify the image
$ podman commit --change CMD=/bin/bash inspiring_galileo busybox:latest
Check if a new image is available via `--dry-run`:
```
$ podman auto-update --dry-run --format "{{.Image}} {{.Updated}}"
registry.fedoraproject.org/fedora:latest pending
```

### Auto-update the container
Update the service:
```
$ podman auto-update
[...]
UNIT CONTAINER IMAGE POLICY UPDATED
sleep.service f8e4759798d4 (systemd-sleep) registry.fedoraproject.org/fedora:latest registry true
```

## SEE ALSO
**[podman(1)](podman.1.md)**, **[podman-generate-systemd(1)](podman-generate-systemd.1.md)**, **[podman-run(1)](podman-run.1.md)**, **sd_notify(3)**, **[systemd.unit(5)](https://www.freedesktop.org/software/systemd/man/systemd.unit.html)**
**[podman(1)](podman.1.md)**, **[podman-generate-systemd(1)](podman-generate-systemd.1.md)**, **[podman-run(1)](podman-run.1.md)**, **[podman-systemd.unit(5)](podman-systemd.unit.5.md)**, **sd_notify(3)**, **[systemd.unit(5)](https://www.freedesktop.org/software/systemd/man/systemd.unit.html)**

0 comments on commit 260adf5

Please sign in to comment.