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.

Enabling Auto-Updates

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:latest reference shown above is intentional, as nginx:latest is 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 auto-update command:

$ 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

The 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 systemd-notify --ready.

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 auto-update command.

Most Podman distributions include a systemd timer for this purpose. You can activate the timer using systemctl:

$ 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 OnCalendar field:

$ 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 cron.

Summary

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.