Podman is an OCI-compliant containerization platform that’s often used instead of Docker. Its daemonless model and extensive featureset makes it a good contender for use in development and production alike.
In this article we’ll show how to use Podman’s auto-update system to restart your containers when new images are released. Podman can be configured periodically check for updates, pull the latest image, and recreate affected containers using their current settings.
Why Auto-Update Containers?
Containers are often short-lived but they still need to be regularly maintained. A critical vulnerability inside an image could give attackers a foothold into your application that’s exploited within hours of its discovery.
Most popular container technologies require you to manually update your containers. This places a burden on operations teams to subscribe to release announcements and create tooling that rolls out new changes.
Podman’s built-in container update system addresses this challenge and keeps workloads fresh. Containers can be promptly updated after you push new image versions, providing peace of mind that your deployments are running the latest patches and bug fixes.
Auto-updates are activated for a container by setting the
io.containers.autoupdate label when you create it.
$ podman run -d -p 8080:80 --name nginx-container --label io.containers.autoupdate=registry docker.io/library/nginx:latest
The label can have two possible values:
registry– During update checks, Podman will contact the image registry to check whether the tag used by your container has a new version available. The image will be pulled and your container restarted when this is the case. Registry updates only work when you’re using a fully qualified registry path – the
docker.io/library/nginx:latestreference shown above is intentional, as
nginx:latestis too vague.
local– This update method restricts Podman to looking at container images that already exist on your host’s filesystem. The container will be restarted if the local version of the image tag differs from the version that the container’s running. This can be useful when rebuilding images during development.
The presence of the label makes this sample NGINX container eligible for auto-updates. However more work is required before updates can actually be applied.
Creating a Systemd Service
Podman’s update mechanism requires your containers to run inside systemd services. Because Podman is daemonless, it lacks a central controller that can start and stop your containers. Wrapping them in a systemd service provides lifecycle management capabilities and the option of restarts in response to specific events.
Podman’s CLI includes a command that creates a systemd unit definition from a container:
$ podman generate systemd --name nginx-container > /etc/systemd/system/nginx-container.service
The commands above create a new NGINX container with a systemd service in the correct location.
Next reload systemd to register the service definition, then enable and start the service:
$ systemctl daemon-reload $ systemctl enable nginx-container.service $ systemctl start nginx-container.service
Your NGINX container is now a systemd service which will start automatically when your host boots. You can use
systemctl commands to start and stop the container, instead of Podman’s CLI:
$ systemctl start nginx-container.service $ systemctl stop nginx-container.service
To remove the container in the future, you should stop, disable, and delete the service’s unit file. Restart systemd afterwards to fully apply the change.
$ systemctl stop nginx-container.service $ systemctl disable nginx-container.service $ rm /etc/systemd/system/nginx-container.service $ systemctl daemon-reload
Performing an Update
Now everything’s set up to successfully auto-update your NGINX container. You can run an update check on-demand using Podman’s
$ podman auto-update Trying to pull docker.io/library/nginx:latest... Getting image source signatures ... UNIT CONTAINER IMAGE POLICY UPDATED nginx-container.service 2de4ba96b09 docker.io/library/nginx:latest registry true
This updates the containers within systemd services that are accessible to the user running the command. You have may needed to use
sudo to follow the example above; if so, run the
auto-update command as root too:
$ sudo podman auto-update
registry update strategy was used in this example so Podman connects to the image registry, checks for changes, and then pulls the new image if applicable. The command’s output indicates whether each service’s container has been updated.
Because containers are managed by systemd, Podman’s able to detect whether the new container’s started successfully. Podman will automatically rollback to the previous version of an image if an update failure is detected. For this to work reliably the application inside the container should notify systemd when it’s started successfully. It can do this by running
Checking for Updates
Sometimes you might need to check whether your container fleet has updates available without immediately applying them. Use the
auto-update command with the
--dry-run flag to get a list of services where an updated image has been published:
$ podman auto-update --dry-run ... UNIT CONTAINER IMAGE POLICY UPDATED nginx-container.service 2de4ba96b09 docker.io/library/nginx:latest registry pending
Services shown as
pending have an update available.
Applying Updates on a Schedule
Now we’ve successfully set up on-demand container updates. You don’t need to manually pull new images or restart your containers. The final step is setting up a schedule so Podman applies updates periodically, without you running the
Most Podman distributions include a systemd timer for this purpose. You can activate the timer using
$ systemctl enable podman-auto-update.timer
The timer’s configured to check for updates every day. You can customize the schedule by opening the timer file using
systemctl edit and changing the value of the
$ systemctl edit podman-auto-update.timer [Timer] OnCalendar=Fri *-*-* 18:00
The time expression shown above will run the update check every Friday at 6pm. The syntax is documented within systemd’s manual.
Now the timer’s enabled, you can start deploying your containers with the
io.containers.autoupdate label. They’ll be updated and restarted periodically, automating your maintenance procedures.
You don’t have to use Podman’s systemd timer to create an update schedule. You could run
podman auto-update inside your existing tooling or another job scheduler such as
Podman’s auto-updates let you move containers to new image versions without manually restarting them or using external tools. This can help you maintain your container fleet as images release bug fixes and security patches.
While automatic updates are a useful tool, they shouldn’t be used without due consideration. Allowing automatic updates can introduce its own issues if a broken image is accidentally released. Containers that restart by themselves could also cause downtime or disrupt dependent services.
Consequently you should assess your own application’s suitability before implementing this solution. One intermediate approach is to run
auto-update --dry-run periodically and send the results to a monitoring service. This keeps you informed of available updates without incurring the risks of applying them without approval.