Our Favorite Tools for Monitoring Container Updates
An overview of select tools and services designed to help users monitor and update container images
Intro
It's container update week at selfh.st/ed and today we're sharing several tools we've deployed within our own self-hosted environments to monitor and notify users of container updates.
Before we begin, we recognize that the tools below certainly aren't the only ones for the job, and not all of them are even self-hosted. But we firmly believe that many common applications and containers should not be configured to automatically update, and so we're featuring a variety of tools with the hope that our readers are able to find one that fits their workflow.
A Quick Note on Image Tags
The decision to automate container updates vs manually manage them is almost entirely dependent upon image tags, and our recommendation not to automate updates is based on the assumption that most users build their stacks using the :latest tag (which was confirmed during this week's poll).
Automating updates with containers tagged as :latest becomes an issue when applications receive major release upgrades that contain breaking changes if users don't update certain parameters or settings before upgrading. For instance, upgrading your PostgreSQL database from v14 to v15 without properly dumping and restoring your databases will likely break the container.
This recommendation changes, however, if users tag their images with major release versions in lieu of :latest, as minor release updates are typically fine to automate given they don't usually contain the breaking changes you might expect from major releases.
For instance, automating the update of a PostgreSQL database that has been tagged with :14 should be fine given the minor releases for this version (14.1, 14.2, etc.) would continue to be compatible with the existing schema. The user would also be protected from unexpectedly updating to PostgreSQL 15 when it's released because the :14 image tag will force them to manually intervene before it can be upgraded.
With all of that being said, there are some containers that can be tagged as :latest and automatically updated given their stability and maturity. We don't recommend making this assumption about any application unless the developers or other members of the software's community have confirmed this is the case.
Featured Tools
Portainer: Business Edition
Portainer is a popular self-hosted application that is commonly deployed to manage the various aspects of container functionality. And while we're big fans of managing our stacks via docker-compose and the command line, it's hard to deny Portainer's usefulness when it comes to certain functionality – and more specifically, its image update notification icons found in the Business Edition (which Portainer offers free for everyone up to the first five nodes):
The image update notification icons (circled in the screenshot above) are a handy way to note which container images are ready to be updated. While I didn't have any images that required updating at the time of writing (thus the green icons), there are three potential icons that can appear:
- Green: The image is up-to-date
- Red: An update is available
- Grey: A local image is available but not deployed
If you're intimidated by the command line, Portainer also offers an easy way to recreate your stack with the latest image updates after clicking into a specific container's details:
The biggest drawback to using Portainer for image updates is that there isn't currently any way to configure external notifications when the software detects new images. Users will need to either rely on a subsequent tool mentioned below or set reminders to occasionally log in and check for updates on their own.
RSS via NewReleases.io
For those who tend to be more meticulous about their updates and also want to be notified of the changes accompanying image updates, we've found subscribing via RSS to GitHub release pages or company blogs the best way to accomplish this (although it depends on the user's ability to regularly check an RSS aggregator if they aren't already). And before this week, that's primarily how we subscribed to image updates...
Until a redditor introduced us to an online resource called new(releases), which can monitor release pages for a number of sites (GitHub, GitLab, Docker Hub, etc.) and send them to a number of notification channels. We've chosen to have our notifications sent to an e-mail address, where we leverage Kill the Newsletter (which can also be self-hosted) to forward the notification to an RSS feed instead.
The benefit of utilizing new(releases) to subscribe to GitHub release pages rather than subscribing directly via GitHub's own RSS feeds is that new(releases) can differentiate and filter between releases and pre-releases, decreasing the amount of notifications users receive (we rarely care about pre-releases for the software we deploy). new(releases) also provides RegEx filters for projects that don't utilize GitHub's pre-release definitions for beta/release candidates.
For example, we've subscribed to Jellyfin's Android TV release page to be notified of updates, but had to utilize RegEx to filter out beta releases that the Jellyfin team hasn't marked as a pre-release on GitHub:
Once the filter has been built, new(releases) will summarize the recent activity of the project to confirm what is and isn't being filtered for future notifications:
As of the time of writing, the following notification channels are supported:
- Slack
- Telegram
- Discord
- Hangouts Chat
- Microsoft Teams
- Mattermost
- Rocket.Chat
- Matrix
- Webhooks
Within our own workflow, we have a "Software Updates" RSS category that now notifies us of image updates (granted we've added them to our new(releases) account) where we can then follow a link to view the details of the update before pulling the new image and updating the container.
Watchtower ft. FILTER and MONITOR
Watchtower seems to have become the de facto tool for automating image updates. Despite our aversion to automatic updates for every container, it still has a number of configuration options for users who'd like to be more deliberate about image updates using a tool they've already deployed.
The first option that comes in handy is the ability to enable or disable Watchtower's automatic updates based on Docker labels. To implement it, simply set the following environment variable to true in Watchtower's compose configuration:
WATCHTOWER_LABEL_ENABLE='true'And add the following label to each container within the environment, setting it to either true or false based on whether you'd like Watchtower to automatically update the image or not:
adminer:
image: adminer
restart: unless-stopped
labels:
- com.centurylinklabs.watchtower.enable = "true"The second option is Watchtower's ability to monitor an environment without updating any containers while still sending notifications, accomplished by setting the following environment variable in Watchtower's compose configuration:
WATCHTOWER_MONITOR_ONLY = 'true'Users can run this in conjunction with nightly backup jobs to receive daily notifications of image updates or use it in coordination with Watchtower's run once functionality to only receive the update notifications when the time has been designated to manage updates.
dockcheck
dockcheck is a new tool to the self-hosted space that runs an interactive script allowing users to selectively monitor for and update container images. It doesn't require much to run – users can simply clone the git repo and run the script via the command line.
See it in action in the GIF below from the project's documentation.
Other Useful Resources
Further Discussion
Have a tool or service to share that you've deployed to replace something above? Feel free to reach out to our contributors with your suggestions to potentially have them featured on selfh.st/ed in the future.
Comments