DockerでWatchtowerを構築する方法：Telegram通知を活用したHomeLab向けの安全な自動アップデート

Table of Contents

メンテナンスの悪夢：なぜHomeLabの手動Docker更新は破綻するのか

2つや3つのDockerコンテナを管理するだけであれば簡単です。ホストにSSH接続し、サッとプルしてコンテナを再作成すれば、すぐに作業は完了します。しかし半年後を想像してみてください。たった1台のミニPCが、DNSフィルタリング用のPi-hole、Plex、Nginx Proxy Manager、paperless-ngx、さらには複数のデータベースなど、20個ものマイクロサービスを稼働させている状態になります。

その規模になると、手動パッチ適用はたちまち破綻します。コンテナが90日以上も放置されてパッチが当たらず、既知のCVE（脆弱性）がローカルネットワーク上に放置されることも珍しくありません。さらに悪いことに、日曜の深夜にログインして全Composeスタックの最新タグを一括プルした結果、月曜の朝7時には、上流のメンテナーが予告なしに破壊的なデータベーススキーマ移行をリリースしていたせいで、サービスの半数が502エラーを吐いている……といった事態にもなりかねません。

無計画な自動化はサービス停止を招きますが、すべてを手動で行うのも膨大な時間の浪費です。解決策はシンプルです。ステートレスで小さな更新は静かに自動化し、ステートfulなサービスには手を触れず、リアルタイムのステータス通知をスマートフォンに直接送信することです。

基本概念：Watchtowerの仕組み（スタックの破損を防ぐ方法）

Watchtowerは、Dockerデーモンのソケット（/var/run/docker.sock）経由でローカルエンジンを監視する軽量なDockerコンテナとして動作します。定期的なインターバルでDocker Hub、GitHub Container Registry（ghcr.io）、ローカルのHarborインスタンスなどのリモートレジストリをチェックし、実行中のイメージダイジェストと最新のリモートハッシュを比較します。

新しいダイジェストを検出すると、Watchtowerは次の4つのステップで移行処理を実行します：

新しいイメージダイジェストをホストストレージにプルします。
稼働中のコンテナに正常終了シグナル（SIGTERM）を送信し、クリーンなシャットダウンが行われるまで最大10秒間（デフォルト）待機します。
ポート、ボリューム、カスタムネットワーク、環境変数、再起動ポリシーなど、元の設定を完全に維持したままコンテナを再作成します。
不要になった古いdanglingイメージレイヤーを削除し、SSDの無駄な容量圧迫を防ぎます。

目的は「すべてを自動で更新すること」ではありません。真のポイントは、強固なガードレール（安全策）を設けることにあります。

Cloudflare Tunnels、Whoogle、Uptime Kumaのようなステートレスなツールは、トラブルなく自動更新できます。しかし、Nextcloud、Vaultwarden、本番用PostgreSQL 15インスタンスのようなステートフルなワークロードは、無人環境で自動更新すべきではありません。予期せぬメジャーバージョンの更新により、データディレクトリが一瞬で破損したり、パスワードコンテナから締め出されたりする危険性があるためです。

オプトイン型アーキテクチャ（ラベルフィルタリング）

デフォルト状態のWatchtowerは、Dockerデーモンに接続されているすべてのコンテナを監視・更新します。このデフォルト挙動は、トラブルを引き起こすリスクが非常に高い設定です。安全を確保するためには、WATCHTOWER_LABEL_ENABLE=true を設定してWatchtowerをオプトインモードで実行します。これにより、Watchtowerはデフォルトでサーバー上のすべてのサービスを無視し、ラベル com.centurylinklabs.watchtower.enable=true が明示的に付与されたコンテナのみを対象に処理を行います。

実践：Docker ComposeとTelegramを使用したWatchtowerのデプロイ

ステップ1：Telegram通知チャネルのセットアップ

Watchtowerを起動する前に、プライベートなTelegramボットを作成しておきます。ビルドダイジェスト、失敗の警告、更新サマリーがチャットに直接届くようになります。

Telegramを開き、@BotFather を検索して /newbot を送信します。
表示名と、末尾が bot で終わる一意のユーザー名を設定します。生成された HTTP API Token（例: 7123456789:AAEk9_exampleTokenStringXYZ123）をコピーします。
Telegramで作成したボットのプロフィールを開き、Start を押して会話を開始します。
自身の数値Telegram IDを確認します。@userinfobot にメッセージを送り、/start を送信します。返信された Id（例: 987654321）を控えておきます。

ステップ2：ディレクトリとDocker Composeファイルの準備

ホストシステム上にWatchtower専用のディレクトリを作成します：

mkdir -p ~/homelab/watchtower && cd ~/homelab/watchtower
nano docker-compose.yml

以下の本番向け設定を貼り付けます。Watchtowerがコンテナの停止・削除・再作成を行うには、docker.sock への書き込み権限が必要である点に注意してください。ここでは毎日午前4時に実行する6フィールドのCronスケジュールを設定し、古いイメージのクリーンアップを有効化し、Shoutrrr経由で通知をルーティングしています：

services:
  watchtower:
    image: containrrr/watchtower:latest
    container_name: watchtower
    restart: unless-stopped
    volumes:
      # コンテナの再起動および再作成には書き込み権限が必要です
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      - TZ=America/New_York
      # オプトインモード: watchtower.enable=true が設定されたコンテナのみ更新
      - WATCHTOWER_LABEL_ENABLE=true
      # ディスク容量を節約するため、更新完了後に古いイメージを削除
      - WATCHTOWER_CLEANUP=true
      # 新しいデプロイが失敗した場合、元のコンテナを再起動
      - WATCHTOWER_ROLLING_RESTART=true
      # 6フィールドのCron: 秒 分 時 日 月 曜日（毎日04:00:00に実行）
      - WATCHTOWER_SCHEDULE=0 0 4 * * *
      # Shoutrrrを使用した通知エンジンの設定
      - WATCHTOWER_NOTIFICATIONS=shoutrrr
      - WATCHTOWER_NOTIFICATION_URL=telegram://7123456789:AAEk9_exampleTokenStringXYZ123@telegram?channels=987654321
      - WATCHTOWER_NOTIFICATIONS_LEVEL=info
      - WATCHTOWER_NOTIFICATION_REPORT=true

ステップ3：対象コンテナでの自動更新の有効化

オプトインフィルタがどのようにアプリケーションを保護するかを示します。以下のサンプル docker-compose.yml では、Uptime Kuma監視ダッシュボードとMariaDBデータベースサーバーの2つのサービスを稼働させています。

services:
  uptime-kuma:
    image: louislam/uptime-kuma:1
    container_name: uptime-kuma
    restart: unless-stopped
    ports:
      - "3001:3001"
    volumes:
      - ./kuma-data:/app/data
    labels:
      # 自動更新の対象に設定（オプトイン）
      - "com.centurylinklabs.watchtower.enable=true"

  mariadb:
    image: mariadb:10.11
    container_name: production-db
    restart: unless-stopped
    environment:
      - MYSQL_ROOT_PASSWORD=SuperSecretPasswd
    volumes:
      - ./db-data:/var/lib/mysql
    labels:
      # 自動更新から除外（オプトインモードでは冗長ですが、明示しておくのがベストプラクティスです）
      - "com.centurylinklabs.watchtower.enable=false"

ラベルの設定に注目してください。Watchtowerは毎朝午前4時にUptime Kumaをスキャンし、バグ修正版を自動で適用します。一方で、MariaDBはバージョン10.11に固定されたままになります。WatchtowerはMariaDBを完全にスキップするため、予期せぬフォーマット更新から生InnoDBテーブルが保護されます。

ステップ4：通知パイプラインの起動とテスト

デタッチモードでWatchtowerスタックを起動します：

docker compose up -d

通知設定の検証のために午前4時まで待つ必要はありません。--run-once フラグを付けた使い捨てコンテナを実行し、ボットの動作を今すぐテストしましょう：

docker run --rm \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -e WATCHTOWER_NOTIFICATIONS=shoutrrr \
  -e WATCHTOWER_NOTIFICATION_URL="telegram://7123456789:AAEk9_exampleTokenStringXYZ123@telegram?channels=987654321" \
  -e WATCHTOWER_NOTIFICATION_REPORT=true \
  containrrr/watchtower:latest --run-once

スマートフォンを開いてTelegramを確認してください。5〜10秒以内に、スキャンされたコンテナとスキップされた対象をまとめた診断レポートがボットから届きます。更新が適用された場合、通知にはコンテナ名、古いイメージハッシュ、新しいSHA-256ダイジェストが含まれます。

まとめ：堅牢なアップデート戦略の構築

信頼性の高いHomeLabとは、手のかからない利便性と盤石な安定性のバランスが取れた環境です。Watchtowerのオプトインラベルと即座に届くTelegram通知を組み合わせることで、完全な制御性を維持しながら単調な手動更新作業をなくすことができます。

規模が拡大してもHomeLabを健全に保つための3つの基本原則は以下のとおりです：

永続化が必要なアプリケーションデータは専用のホストボリュームに保存する。
手動アップグレードを行う前には必ずComposeファイルとデータベースのバックアップを取る。
自動更新の適用は、軽量でステートレスなワークロードのみに限定する。

一度設定してしまえば、軽微なアップデートはWatchtowerに任せ、誰にも邪魔されない週末を過ごすことができます。