アラートの悩み：なぜntfyが選ばれるのか
サーバーがクラッシュした翌朝に目覚め、それが12時間も前だったと気づくことほど最悪なことはありません。長年、私はHomeLabの監視をメールアラートに頼ってきました。しかし、メールは根本的に遅いのです。SMTPハンドシェイクや厳しいスパムフィルターの間で、重要な「ディスク容量不足」の警告が届くまでに5分かかることもあれば、そもそも届かないこともあります。TelegramやDiscordのボットはマシですが、クラウドのエコシステムに縛られ、ローカルのアラートを送るためだけに常時外部インターネット接続が必要になります。
ntfy（「notify」と発音）に出会ってから、APIキーとの格闘はやめました。これはHTTPベースの非常にシンプルなパブサブ（出版・購読型）サービスで、「スマホにテキストを送る」という一点を完璧にこなします。アカウントも複雑なSDKも不要です。curlコマンドが書ければ、通知を送れます。今では、ヘッドレススクリプトと私のポケットをつなぐ最も信頼できる架け橋となっています。
通知方法の比較
適切なツールの選択は、遅延と複雑さをどれだけ許容できるかによります。ntfyと従来の方法を比較してみましょう。
- メール (SMTP): ログには信頼性がありますが、緊急事態には不向きです。遅延は通常30秒から数分に及びます。
- Telegram/Discord ボット: 多機能で無料です。しかし、WANがダウンすると、ローカルスクリプトはAPIにアクセスできないため、インターネットが切断されたことを通知できません。
- Gotify: 素晴らしいセルフホストの選択肢です。私がntfyに切り替えた主な理由は、iOSアプリの完成度が高く、「トピックベース」のシステムにより送信側の設定が一切不要だからです。
- ntfy: 軽量で、シンプルなPUT/POSTリクエストで動作します。配信はほぼ瞬時で、通常200ミリ秒以内にスマホに届きます。
セルフホストのメリットとデメリット
メリット
- プライバシー: データがサードパーティのサーバーに触れることはありません。通知履歴は自身のSSD内に保持されます。
- 摩擦ゼロ: 新しい「トピック」を作成するには、モバイルアプリでそれを購読するだけです。ちょっとしたスクリプトごとに新しいボットを登録する必要はありません。
- 省リソース: Dockerコンテナは非常に効率的です。私の環境では、アイドル時のRAM使用量は20MB未満で、CPU負荷も無視できるレベルです。
- 高い汎用性: Bash、Python、Node.js、さらにはESP32のようなシンプルなマイコンでも動作します。
課題
- リモートアクセス: 外出先でアラートを受け取るには、リバースプロキシやTailscaleのようなVPN経由でサービスを公開する必要があります。
- セキュリティ: シンプルさは諸刃の剣です。アクセス制御を有効にしないと、トピック名を推測した誰もがアラートを読めてしまいます。
推奨アーキテクチャ
HomeLabを本番環境レベルにするなら、SSL証明書を備えたリバースプロキシの背後でntfyを実行してください。これにより、通信中のメッセージが暗号化されます。私はDocker Composeを使用してサービスを管理し、再起動やコンテナの更新後もメッセージ履歴やユーザー設定が保持されるようにしています。
ステップバイステップの導入手順
1. ファイルの整理
まずはntfy専用のディレクトリを作成します。これにより、設定やメッセージデータベースが整理され、バックアップが容易になります。
mkdir -p ~/docker/ntfy/config
mkdir -p ~/docker/ntfy/cache
cd ~/docker/ntfy2. サーバーの設定
ntfyはデフォルトでも動作しますが、セキュリティと永続性のためにserver.ymlファイルが必要です。config/server.ymlに以下のファイルを作成します。
# ntfy サーバー設定
base-url: "https://ntfy.yourdomain.com"
cache-file: "/var/cache/ntfy/cache.db"
attachment-cache-dir: "/var/cache/ntfy/attachments"
auth-file: "/var/lib/ntfy/user.db"
auth-default-access: "deny-all"ヒント：テストの最初の10分間は auth-default-access
