For the lazier and automation-loving nerds (like myself), constantly updating Docker containers can be a tedious chore. Enter the Docker Container Auto-Update Script to save the day. It handles updates without relying on the "latest" tag or sticking to the current image tag, which might cause you to miss important updates. Instead, it plays by your rules!

• 🔄 Automated Container Updates: Effortlessly update all your Docker containers on your host under your own conditions.
• 🧠 Smart Update Detection: This script creates a regex filter based on the currently used image tag and scans Docker Hub for any available updates. It automatically analyzes the version numbers specified in the image tags and identifies major, minor, patch, and build updates. It also handles simple digest updates automatically.
• ⚙️ Customizable and Conditional Update Rules: Define highly precise update rules for each individual container.
• 🔁 Standard Update Sequence: Updates follow the standard sequence: first digest, build, patch, minor, and then major updates. No updates are skipped.
• 🛠️ Backup and Rollback: Backups of your containers are created before updates. If an update fails, the change is rolled back and the old container is restarted.
• 📧 Notifications: Stay informed with detailed email and telegram reports
• 📜 Pre- and Post-Scripts Integration: Integrate your own pre- and post-scripts to perform actions such as backing up configuration files or databases before any update and making adjustments to the container configuration after any update.

The default configuration has test mode enabled. Safety first 😉! After you've run your first test, checked for errors, and reviewed the generated Docker run commands, you can disable test mode in your configuration file (see below).

1. On your Docker host, navigate to the directory where the script should be downloaded to
2. Download this script to your Docker host and make it executable (you can do it manually, or just use the following command)

wget --header='Accept: application/vnd.github.v3.raw' -O container_update.sh https://api.github.com/repos/jansppenrade2/Docker-Container-Updater/contents/container_update.sh?ref=main && chmod +x ./container_update.sh

3. Execute it with root (the first run will be in test mode and also creates the default configuration file)
4. Customize the default config according to your specific requirements (see below)
5. Create a cron job for this script (after testing 🫠)

1. Clone this repo and go to folder.

   git clone https://github.com/jansppenrade2/Docker-Container-Updater.git
   cd Docker-Container-Updater/
   

2. Build container:

   docker build -t docker_container_updater:latest \
   -f ./DOCKERFILE .

   Build container behind corporate proxy:

   docker build -t docker_container_updater:latest \
   --build-arg http_proxy=http://172.17.0.1:3128 \ 
   --build-arg https_proxy=http://172.17.0.1:3128 \ 
   -f ./DOCKERFILE .

3. Rename docker-compose-example.yaml to docker-compose.yaml
4. Configure options via environment variables (update rules, test mode, crontab expression and etc.)
5. Type in shell docker compose up -d to start.
6. (Update) Type in shell

   docker compose down
   docker compose pull
   docker compose up -d

The Docker Container Auto-Update script uses a configuration file, which is located at /usr/local/etc/container_update/container_update.ini. This file contains all the settings and parameters necessary for the script to run. You can customize the configuration file according to your requirements.

• DCU_CRONTAB_EXECUTION_EXPRESSION - crontab expression when script. You can use this site to create expression.
• DCU_CONFIG_FILE - path to ini config file inside container. Do not save this as persistence!

The update_rules parameter allows you to define the update behavior for your containers. The default rule is *[0.1.1-1,true], which means:

• *: Applies to all containers.
• 0.1.1-1: Specifies the update policy, where each number represents:
  • 0: Major updates (0 means no major updates, 1 means allow major updates to the next available, 2 means always stay one version behind the latest major release, and so on)
  • 1: Minor updates (0 means no minor updates, 1 means allow minor updates to the next available, 2 means always stay one version behind the latest minor release, and so on)
  • 1: Patch updates (0 means no patch updates, 1 means allow patch updates to the next available, 2 means always stay one version behind the latest patch release, and so on)
  • 1: Build updates (0 means no build updates, 1 means allow build updates to the next available, 2 means always stay one version behind the latest build release, and so on)
• true: Indicates that digest updates are allowed.

You can customize these rules for each container by specifying different patterns and update policies separated by spaces.

update_rules=*[0.1.1-1,true] mycontainer[1.0.0-1,true] another[0.0.1-1,false] further[2.1.1-1,true]

This example configuration means:

• All containers are allowed to apply only minor, patch, build, and digest updates.
• The container named mycontainer is allowed to apply major, build, and digest updates.
• The container named another is allowed to apply only patch and build updates.
• The container named further is allowed to apply build updates only when the latest release is two versions higher (e.g., if Nextcloud releases version 29.0.0 and your Nextcloud is on version 27.0.0, an update to version 28.0.0 will be performed).

You can also create more specific rule sets that allow, for example, major updates for a container if at least one patch has been released for that major version. In the rules, 'M' stands for Major, 'm' for Minor, 'p' for Patch, and 'b' for Build.

mycontainer[1&(p>1).1.1-1,true]

This rule allows major updates for the container mycontainer if at least one patch version greater than 1 has been released for this major version.

mycontainer[0.1(b>2).1-1,true]

This rule allows minor updates for the container mycontainer if the build version is greater than 2.

These precise rules provide granular control over the update behavior of specific containers based on various conditions such as patch versions, build versions, and more.

Hint: These rules do not affect the order in which updates are installed! An update is never skipped.

To give you more control, you can integrate pre- and post-scripts. These are created by default in the directories /usr/local/etc/container_update/pre-scripts and /usr/local/etc/container_update/post-scripts, and they must be named after the container. These are standard shell scripts that you can create and customize as needed. For example, you can create backups of databases, configuration files, etc., before updating a container, and make adjustments such as customized branding or changes to file permissions after the update. Essentially, you can tailor these scripts to your specific needs. The output of these scripts is redirected to the log located in /var/log/container_update.log by default, so you have all logs in one place.

To receive e-mail notifications, you need to install and configure Sendmail (as only Sendmail is supported).

To receive Telegram notifications, you first need to obtain a Chat ID and a Bot Token, which you should enter in the configuration file.

If you encounter any issues while executing this script, please provide the following information:

• A full log in debug mode (ensure sensitive data is replaced)
• A docker container inspect of one or more affected containers (ensure sensitive data is replaced)
• A docker image inspect of one or more images (ensure sensitive data is replaced)