Docker Compose は私の脆弱な Pi-hole セットアップを強固な DNS 要塞に変えました

Pi-hole は、一度機能するとすぐに考えるのをやめてしまうホーム ラボ サービスの 1 つです。広告とトラッカーをブロックし、DNS クエリを処理し、バックグラウンドで静かに仕事を行います。その後、何かが壊れ、ホーム ネットワークのかなりの部分が、ほとんど考えていなかったサービスに依存していることに気づきます。 DNS が機能しなくなると、インターネット接続自体に問題がない場合でも、Web サイトがオフラインのように表示されることがあります。

Pi-hole セットアップをより簡単に回復できるように、構成を失わずに再作成できるようにしたいと考えていました。 Docker Compose に移行したことで、デプロイメントと永続ストレージを管理する一貫した方法が得られ、バックアップにより、コンテナーの障害が完全な Pi ホールの再構築にならないようにすることができました。

Docker Compose は私の Pi-hole セットアップに信頼できる基盤を与えてくれました

DNS サーバーには動作するコンテナ以上のものが必要でした

脆弱なセットアップの問題は、何かを変更する必要がある瞬間まで、すべてが正常に見える可能性があることです。コンテナーの更新、ホストの再起動、または誤った削除により、サービスの構成方法の弱点が露呈する可能性があります。 Docker Compose は、Pi-hole がどのように実行されるか、Pi-hole が使用するポート、およびその構成が存在する場所を記述した 1 つのファイルを提供します。サービスを再作成するときに、メモリからこれらの詳細を再構築する必要がなくなりました。

Pi-hole は TCP および UDP ポート 53 経由で DNS を処理しますが、私はポート 8080 を介して Web インターフェイスにアクセスします。 Compose 構成は、その外部ポートをコンテナ内のポート 80 にマップし、Pi-hole v6 の組み込み Web サーバーがデフォルトでリッスンします。デプロイの基礎として使用する構成は次のとおりです。

---
services:
  pihole:
    image: $関連情報は以下のリンクからご確認いただけます
    container_name: pihole
    hostname: pihole
    restart: unless-stopped
    init: true
    ports:
      - 192.168.1.4:53:53/tcp
      - 192.168.1.4:53:53/udp
      - 192.168.1.4:8080:80/tcp
    environment:
      FTLCONF_webserver_api_password: $完全ガイドはこちら
      FTLCONF_dns_listeningMode: ALL
    volumes:
      - /opt/pihole/etc-pihole:/etc/pihole

画像とパスワードは、 .env Compose ファイルの横にあるファイル。ただし、私にとって重要なのは永続的なバインド マウントです。 Pi-hole の設定は次の場所にあります。 /opt/pihole/etc-pihole これにより、サービスを再作成する必要があるときにデータを見つけるための予測可能な場所が得られます。

また、Unbound を Pi-hole コンテナーにバンドルするのではなく、別のサービスとして実行します。 Pi-hole は DNS フィルタリングを処理しますが、Unbound は再帰リゾルバーとして機能し、従来の上流の DNS プロバイダーに依存するのではなく、答えを直接検索します。 2 つのサービスを分離しておくことで、ライフサイクルを同じコンテナーに結び付けることなく、個別に管理、更新、トラブルシューティングを行うことができます。

永続ストレージにより障害の処理方法が変わりました

コンテナーを再作成することは、最初から開始することを意味しなくなりました

の restart: unless-stopped ポリシーは問題の別の部分を処理します。ホストの再起動後に Docker が起動すると、Pi-hole が自動的にバックアップされます。同じポリシーにより、明示的に停止していない限り、予期しない終了後に Docker がコンテナを再起動することができます。

Docker のシステム サービスを有効にして、起動時に開始されるようにしました。

sudo systemctl enable --now docker

バインド マウントと再起動ポリシーにより、さまざまな問題が解決されます。コンテナーを再起動すると、プロセスが予期せず終了した場合に役立ちます。ホスト上で構成を維持するということは、Pi-hole の保存された設定を意図的に削除せずに、コンテナーを削除して再作成できることを意味します。

まだ問題があります…永続ストレージはホストから削除されたデータを保存できず、再起動ポリシーは破損した構成を修復できません。そのため、バックアップはセットアップの一部として残ります。 Compose ファイル、環境設定、Pi-hole データを以下にまとめて保存します。 /opt/pihole。これらを別のデバイスにバックアップすると、ホスト ディスクに障害が発生した場合や構成が誤って削除された場合に回復パスが得られます。

sudo tar -czf "/mnt/backup/pihole-$(date +%F-%H%M%S).tar.gz" \
  -C /opt/pihole compose.yaml .env etc-pihole

ローカルの DNS レコードもテストします。 canary.lab.test、これは次のように解決されるはずです 10.9.8.7。解決に失敗した場合、コンテナのログは何が問題だったのかを調査するのに役立ちます。

sudo docker logs --tail 100 pihole

Pi-hole に大きく依存するネットワークの場合、プライマリ ホスト ハードウェアに障害が発生した場合にコンテナ再起動ポリシーでは DNS を復元できないため、別の Mini PC で 2 番目のリゾルバーも実行します。また、同じホスト、ストレージ デバイス、または Docker インストールに依存せずにリカバリをテストする機会も得られます。

ホームネットワークにフォールバックを提供する

信頼性とは、主要なサービスが利用できない場合に何が起こるかを決定することにも関わることを学びました。リゾルバーに障害が発生すると、正常なインターネット接続が完全に切断されたように感じられる可能性があるため、DNS は特に重要です。私は Docker Compose ファイルをバージョン管理下に置いているので、構成の変更を追跡し、更新によって問題が発生した場合に以前のバージョンを復元できます。必ず除外してください .env リポジトリからファイルまたは認証情報を取得します。

Docker Compose により、Pi-hole を別のホストに移動することもはるかに簡単になります。 Compose ファイルにはサービスの実行方法が記述されており、永続的な構成と環境変数は個別に復元できます。元のマシンに障害が発生した場合でも、セットアップ全体を最初から再構築することなく、互換性のあるハードウェアに Pi-hole を展開できます。構成を復元し、必要に応じてホストの IP アドレスとネットワーク設定を調整し、交換用マシンで DNS 解決が機能することを確認する必要があります。