Podman is a great tool for managing your containers, but it can be difficult to keep up with the latest updates. If you’re not using Podman, you may want to consider automating your updates. Here are some tips on how to do this:
- Install Podman on your system. This will help you manage your containers and podman updates.
- Configure Podman to automatically update containers and pods. This will require some configuration, but it’s worth it for convenience and peace of mind.
- Use a cron job to update containers and pods automatically. This will run every day or every week, and will update all of your containers and pods in the background.
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.
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:
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:
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:
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.
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:
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:
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:
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:
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:
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.
