Automatically Update Docker Containers—Without Giving Up Control

Summary of the subtitles (technological concepts, features, and workflow)

This video walkthrough sets up Renovate to automatically manage Docker image updates for Docker Compose repositories hosted on Gitea, while still keeping human control over when changes are merged and deployed. It also integrates notifications via Matrix and automatic redeployment via Komodo.

---

Core automation flow (how updates happen)

1. Renovate scans Docker Compose repos

   • Renovate checks Docker Compose files in Gitea repos.
   • It compares current image tags against available tags.

2. Renovate opens a reviewable Pull Request (PR) in Gitea

   • The PR is opened on your behalf (Renovate bot user).
   • Users can review what the current config uses vs what’s proposed.

3. Matrix notifies you when a PR opens

   • A webhook posts a message into a specified Matrix room when a PR is opened.
   • The message includes a link so you can approve/deny directly.

4. User decides: merge / deny / ignore

   • Merge: Renovate merges its PR changes and updates the image tag.
   • Deny: implied as “don’t merge.”
   • Ignore: postpones the update until the next relevant release; Renovate will open another PR later.

5. Merge triggers redeploy via Komodo

   • After merge, Gitea triggers a redeploy webhook.
   • Komodo clones the repo and redeploys the Docker Compose stack with the updated image tag.

---

Key technical safeguards and options

• Problem addressed

  • “latest tags” are convenient but make automation harder to keep updates controllable and immutable.

• Two approaches mentioned

  1. Pin to a specific stable image version and test.
  2. Enable Renovate to pin the SHA digest for image tags so updates become effectively immutable.
     • The video states they chose SHA digest pinning and planned to refine versions later.

• Selective ignore capability

  • Renovate can be configured to ignore certain Docker Compose files/images, preventing PRs for those items.

---

Setup instructions covered (tools/config files/features)

1) Create/configure a Renovate bot in Gitea

• Creates a new Gitea user account (Renovate bot).
• Sets up a Gitea repository to host Renovate configuration (a separate “Renovate” repo is created).

2) Add GitHub Actions workflow config in Gitea

• Creates:
  • gitea/workflows/renovate.yaml
• Explains:
  • Renovate runs on a schedule (default mentioned: 1:00 AM), but can be adjusted.
  • Workflow can also be run manually (“run workflow” button).

3) Create a Gitea access token for Renovate workflow execution

• Generates a token for Renovate to run via the Actions runner deployed previously (Komodo + Gitea referenced from an earlier video).
• Token permissions set to mostly read, with some areas set to read/write (notably repository/issue write behavior).

4) Store Renovate secrets in the Renovate repo

• Adds a secret:
  • Renovate token (Gitea token)
• Optional enhancement:
  • Adds Renovate GitHub token to pull related changelog info from GitHub.
  • Requires generating a GitHub classic personal access token (custom expiration recommended).

5) Grant Renovate access to the Docker Compose repository

• Adds the Renovate bot as a collaborator to the target Docker Compose repo.

6) Configure Renovate behavior using renovate.json

• Adds a root file:
  • renovate.json
• Includes options such as:
  • Pin digest to true (turns tag updates into SHA-digest-pinned references)
  • Package rules to ignore specific images/packages
    • The example uses a rule that matches a package name pattern and sets it to be ignored (enabled/disabled logic shown).

---

Komodo redeploy automation (webhooks)

1) Create a Komodo procedure to redeploy when updates land

• Creates a Komodo procedure (example name: “Renovate redeploy”).
• Includes stages like:
  • clone repo
  • batch deploy stack if changed
• Uses a webhook URL copied into the Gitea webhook configuration.

2) Add a Gitea webhook that triggers redeploy on push events

• In Gitea: adds a webhook for the Docker Compose repo targeting the Komodo procedure.
• Configured for:
  • custom events → push
• Important caution:
  • If there was an older webhook that already triggers Komodo on repo updates, it should be removed to avoid conflicts (both webhooks cloning/redeploying).

---

Matrix notification integration (PR opened → message in chat)

• Sets up a Matrix webhook in Komodo for the “Matrix notify” container/terminal process:
  • Registers a new user (non-admin) in Matrix specifically for Gitea webhook posting.
• In Gitea:
  • Adds a Matrix webhook with:
    • home server URL (example: i.am.rehomelabs.com)
    • room ID (internal room ID retrieved from Matrix room settings)
    • access token (prefixed as Bearer <token>)
    • trigger event: when a pull request is opened
• Goal:
  • When Renovate opens a PR, you get a chat message with a link to act.

---

Demonstration / validation steps performed in the video

• Creates a test Docker Compose repo (example: Nginx), pinned to an older image version.
• Deploys it via Komodo to confirm it runs.
• Runs Renovate manually using the “run workflow” button on the main branch.

Observed results:

• Renovate may open multiple PRs, including:
  • PR to update/merge Renovate bot dependencies (first-run self-update behavior)
  • PR to update the Nginx Docker tag to a newer version
  • PR/details showing SHA digest pinning appended to the tag
• When a PR is merged:
  • webhook fires
  • Komodo clones and redeploys
  • image tag changes from the original pinned tag (example 1.25) to a newer pinned/digest-appended tag (example like 1.33... with digest included)

Troubleshooting note:

The creator mentioned they introduced some issues (e.g., extra information / workflow ordering / deleted config file) and notes viewers likely won’t hit the same problems.

---

Main speakers / sources

• Speaker: The single creator/host narrating the setup steps (unnamed in subtitles).
• Systems referenced as sources/tools: Renovate, Gitea, Komodo, and Matrix (Element/Matrix webhooks).