NASやホームサーバーでのホームラボにおけるDockerの使い方

Dockerは各サービス、ポート、ネットワーク、永続データパスを展開前に定義することで、ホームラボを再現可能なアプリケーションプラットフォームとして利用できるようにします。

NASやホームサーバーでは、DNSフィルタリング、監視、メディア、ファイル同期、ダッシュボード、その他のセルフホストアプリをホストに直接すべての依存関係をインストールせずに実行できます。実用的な目標は単にコンテナを一度起動することではなく、再起動に耐え、アップデートでデータを保持し、意図した場所でのみアクセス可能で、問題が起きたときに復元できるスタックを構築することです。

ホームラボでDockerがすること

Dockerはアプリケーションとその実行時依存関係をイメージにパッケージ化し、そのイメージをコンテナとして起動します。ホストはCPU、メモリ、ストレージ、ネットワークを提供しますが、各サービスは手動インストール手順の長いリストよりも再現しやすい定義済み環境を得ます。

ホームラボで使うDocker設定のほとんどは5つの概念で説明できます：

コンテナは交換可能なものとして扱うべきです。サービスを復元可能にするのはComposeファイル、環境設定、永続データの部分です。

Dockerをインストールする前に必要なもの

まずDockerをどこで実行するか決めます。NASのOSはビジュアルなアプリマネージャーを提供することがあり、標準的なLinuxホームサーバーは通常コマンドラインからDocker EngineとComposeプラグインを使用します。ベースのハイパーバイザーからDockerを分離したい場合は仮想マシンも有効です。

• ホストがamd64かarm64のどちらを使用しているかを確認し、互換性のあるイメージを選択してください。
• DHCP予約または静的IPで安定したLANアドレスを確保してください。
• 大容量のメディア共有とは別に、コンテナ設定とデータベース用の永続的な場所を1つ作成してください。
• 未文書の方法を混ぜるのではなく、Composeプロジェクトかビジュアルマネージャーのいずれかを主要なワークフローとして選択してください。
• どのサービスをLAN内限定にし、どのサービスが将来的にリモートアクセスを必要とするかを決めてください。
• Composeファイルと永続データのバックアップ用に別のストレージ先を選択してください。

ホスト自体がまだ計画中の場合は、自分のホームサーバーの構築と設定方法のガイドが、Dockerを追加する前にストレージ、ネットワーク、OSの基盤を確立するのに役立ちます。

Dockerをインストールしてホストを検証する

インストール方法はOSによって異なりますが、検証手順は一貫しているべきです。いくつかのNASプラットフォームはアプリインターフェースの背後にDockerをバンドルしています。Linuxホストは通常Docker EngineとComposeプラグインが必要で、WindowsやmacOSは恒久的なNASサービスよりも学習やテストに適しています。

初心者向けのDockerホームラボセットアップでは、Dockerのインストール、最初のコンテナの実行、プロジェクトフォルダの整理、繰り返し使うサービスをComposeに移行する有用な手順が示されています。その手順をフレームワークとして使用し、ご自身のNASやLinuxディストリビューションに必要なインストール方法に従ってください。

DockerとComposeを確認する

インストール後、ホスト上でターミナルを開き、DockerとComposeの両方が応答することを確認します：

docker --version
docker compose version

どちらかのコマンドがない場合はここで停止し、アプリケーションフォルダを作成する前にインストールを修正してください。Linuxでは、Dockerサービスが自動的に起動し、管理に使用するアカウントが保護されていることも確認してください。Dockerデーモンへのアクセスは実質的にホストの管理者アクセスです。

使い捨て検証コンテナを実行する

一時的なコンテナを使って、デーモンがイメージをダウンロードして起動できることを確認します：

docker run --rm hello-world

成功した結果は、コマンドラインクライアントからDockerデーモンおよびイメージレジストリへの基本的な経路が確認できたことを示します。 --rm このオプションはテスト用コンテナが終了後に削除されるため、恒久的なスタックの一部になりません。

基本的な管理コマンドを確認する

docker ps
docker ps -a
docker images

docker ps 実行中のコンテナを表示します、 docker ps -a 停止したコンテナも含まれ、 docker images ホストに保存されているイメージを表示します。これらの3つのビューは、停止したコンテナ、ダウンロードされていないイメージ、または作成されていないサービスのいずれが問題の原因かを判断するのに十分なことが多いです。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

最初のDocker Composeスタックを展開する

一時的 docker run コマンドはテストに便利ですが、Composeは繰り返しやすく、レビューやバックアップ、移行も簡単です。各プロジェクトは独自のディレクトリと compose.yaml イメージ、ポート、ストレージ、再起動動作、ネットワークを記録するファイル。

プロジェクトディレクトリを作成する

以下の例は小さなNginxのスタートページを作成します。意図的にシンプルですが、ダッシュボード、メディアサーバー、監視ツール、またはパーソナルクラウドで使用する同じワークフローをテストします：

mkdir -p ~/docker/start-page/site
cd ~/docker/start-page
printf '<h1>Docker homelab is running</h1>\n' > site/index.html

すべてのサービスを別々のフォルダに保持すると、そのComposeファイル、環境変数、永続データを特定しやすくなります。大きなNASでは次のようなパスを使用できます /docker/start-page ホームディレクトリの代わりに専用の共有フォルダを使用することもできます。

Composeファイルを作成する

という名前のファイルを作成する compose.yaml プロジェクトディレクトリ内で：

サービス:
  start-page:
    イメージ: nginx:alpine
    コンテナ名: homelab-start-page
    ポート:
      - "8080:80"
    ボリューム:
      - ./site:/usr/share/nginx/html:ro
    再起動: unless-stopped
    ネットワーク:
      - homelab

ネットワーク:
homelab:
ドライバー: bridge

ポートマッピングはポートからのリクエストを送信します 8080 NAS上のポートから 80 コンテナ内。バインドマウントはローカルの サイト Nginx内で読み取り専用コンテンツとして利用可能なディレクトリ。再起動ポリシーは、意図的に停止しない限り通常の再起動後にサービスを復帰させます。

この例ではホストのポート8080を公開しています。テスト中はルーターのポートフォワーディングを無効にしておいてください。サービスがDockerホスト自身からのみアクセス可能であるべき場合は、ループバックにバインドします。 127.0.0.1:8080:80 代わりに。

サービスを開始して確認する

docker compose up -d
docker compose ps
docker compose logs --tail=100

開く http://NAS-IP:8080 同じネットワーク上のデバイスから。ページには「Docker homelab is running.」と表示されるはずです。その後、ホストを一度再起動し、コンテナが自動的に戻ることを確認してください。

最も頻繁に使用するコマンドは次のとおりです：

追加しないでください -v へ docker compose down Compose管理のボリュームを意図的に削除したい場合を除きます。コンテナの削除は日常的ですが、永続データの削除はそうではありません。

NASのオペレーティングシステムが視覚的なDockerアプリマネージャーを提供している場合でも、同じ項目が重要です。インターフェースはイメージ、ホストポート、コンテナポート、マウントされたパス、環境変数、再起動動作を表示する必要があります。このNASオペレーティングシステムのワークフローは、GUIを好みつつも予測可能なアプリパスを望む場合に役立ちます。

NASにDockerデータを安全に保存する方法

コンテナは使い捨てですが、サービスデータはそうではありません。アップデート後のホームラボの多くの障害は、コンテナ層内だけに保存されたデータベース、アカウントファイル、アプリ設定に起因します。そのコンテナを再作成すると元のサービスを復元せずクリーンインストールになります。

バインドマウントは既知のホストファイルやディレクトリをコンテナにマッピングします。ボリュームはDockerが管理するストレージ領域内にあります。どちらもデータを保持できますが、可視性やバックアップの流れが異なります。

アプリケーションデータを大容量メディアから分離

設定、データベース、サムネイル、インデックス、その他の小さなファイルのワークロードは専用の docker-data 頻繁にバックアップされる場所。大きな映画、写真、録音、ダウンロードは通常のメディア共有に置けます。この分離によりバックアップ範囲が明確になり、アプリケーションのメタデータが大容量の連続ストレージ作業と競合するのを防げます。

実際のアプリケーションを展開する前に、Composeファイルで使用されているすべてのホストパスを書き留めてください。シンプルなレイアウトは次のようになります：

/docker
  /app-name
    compose.yaml
    .env
    /config
    /data

サービスを再作成するものをバックアップ

Composeファイルと任意の .env ファイル、証明書、カスタム設定、永続的なコンテナデータ。イメージは通常再ダウンロード可能なのでバックアップ不要です。環境ファイルはパスワード、トークン、データベース認証情報を含む可能性があるため慎重に保護してください。

3-2-1バックアップルールは有用な計画モデルを提供しますが、Dockerのバックアップはスタックを再作成しデータを復元できて初めて完了します。ホームラボがサービスに依存する前に、非重要な復元を一度テストしてください。

ビジュアルNASインターフェースを使用する際は、その永続的なコンテナデータがどこに保存されているかを確認し、インターフェースが自動的に保護していると仮定しないでください。

ホームラボでのDockerネットワーキングの仕組み

Dockerネットワーキングは2つの異なる経路を制御します：コンテナ間の通信とDocker外のデバイスからのアクセス。これらの経路を分けることで不要なポート公開を減らし、複数サービスのスタックを理解しやすくします。

ポートマッピングは左から右へ読む

において 8080:80、ポート8080はDockerホストに属し、ポート80はコンテナに属します。LAN上のデバイスはNASのアドレスとホストポートに接続し、Dockerはリクエストをアプリケーションの内部ポートに転送します。

ブラウザ、電話、テレビ、または他の非Dockerデバイスが直接アクセスする必要がある場合にのみホストポートを公開します。別のコンテナだけが使うデータベースは通常、公開ポートを必要としません。

関連サービスにはカスタムネットワークを使う

Composeは各スタックにユーザー定義のブリッジネットワークを作成できます。そのネットワーク上のコンテナはサービス名で互いにアクセスできるため、ウェブアプリケーションは データベース 変動するコンテナIPアドレスに依存せずに。

カスタムDockerネットワークとコンテナの分離の実践例では、コンテナが別々のブリッジネットワークに配置されたり複数のネットワークに接続された場合に名前解決と接続性がどのように変わるかを示しています。

本当に通信が必要なサービスをグループ化しましょう。関連しないスタックは別のネットワークに分け、コンテナ同士が見えるようにするためだけに内部データベース、キャッシュ、メッセージキューを公開しないでください。

LANアクセスとインターネットアクセスを分けて管理する

アクセス可能なサービス NAS-IP:8080 ホームネットワーク上のサービスは自動的にインターネットから利用可能になるわけではありません。公開には通常、ルーターの転送ルール、トンネル、VPN、または他のリモートアクセス経路が必要です。その追加のステップは、すべての展開の一部ではなく、別個のセキュリティ判断として扱いましょう。

Dockerサービスを安全に公開する

リモートアクセスは便利なホームラボが本当のセキュリティリスクになる場所です。安全なデフォルトは、アプリケーションインターフェースをLAN内に限定し、リモート使用が必要な場合にのみ制御されたアクセス層を公開することです。

プライベートリモートアクセスにはVPNを使いましょう

プライベートVPNまたはオーバーレイネットワークは、承認されたデバイスが各アプリケーションを直接公開することなくホームサービスにアクセスできるようにします。これは、個人用ダッシュボード、管理パネル、ファイルアクセス、そして限られた信頼できる人だけが使うサービスにとって最も簡単な方法であることが多いです。安全なリモートアクセスのガイドでは、VPNベースのアクセスと公開ウェブ公開の間のホームサーバーに関するより広範な判断について説明しています。

リバースプロキシを公開入口として使う

ウェブサービスを公開する場合、リバースプロキシはホスト名、証明書、ルーティングルール、アクセス制御を一元管理します。各アプリケーションに個別のルーター転送ポートを設定する代わりにプロキシを公開してください。データベース、管理インターフェース、内部サービスのポートは可能な限りプライベートなDockerネットワークに置きましょう。

HTTPSと慎重なポートルールを使う

ホームネットワーク外からアクセス可能なログインやセッションは必ずHTTPSを使用してください。ルーターの転送ルールは定期的に見直し、不要なエントリは削除しましょう。証明書の自動化は役立ちますが、強力な認証、適時の更新、公開サービスの厳格な管理に代わるものではありません。

スタックの更新、監視、復元

Dockerホームラボはメンテナンスを繰り返し可能な手順で行うと管理しやすくなります。すべてのサービスを一斉に更新しないでください。バックアップを取り、1つのスタックを更新し、重要な経路を検証してから次のアプリケーションに進みます。

制御された更新手順を使う

cd ~/docker/start-page
docker compose pull
docker compose up -d
docker compose ps
docker compose logs --tail=100

重要なサービスはアップデート前に動作中のイメージタグを控え、ロールバック用の参照とします。再展開後はログイン、マウントされたストレージ、データベース接続、LANアクセス、リバースプロキシ経路をテストしてください。「Up」状態はプロセスが動いていることを示すだけで、アプリケーションが正常とは限りません。

静かに変化する兆候を見逃さない

• 古いイメージ、書き込み可能レイヤー、ログ、放置されたデータによるシステムドライブの使用状況
• コンテナの再起動回数やアプリケーションログの繰り返しエラー
• 予期しないルーターの転送や不要になったホストポート
• バックアップの古さ、サイズ、最新アーカイブが開けるかどうか
• 小型NASに追加サービスを増やした際のメモリ圧迫

クリーンアップコマンドは削除対象をよく確認してから使用してください。未使用のイメージはスペースを消費しますが、過度なプルーニングはキャッシュされたレイヤーや回復計画に必要な未使用ボリュームも削除する可能性があります。

復元のリハーサルを行う

重要でないサービスを選び、停止して永続データを別の場所に移動し、Composeファイルから再構築します。その後データを復元し、アカウント、設定、アプリケーションの状態が戻ることを確認してください。復元が成功することは、バックアップジョブが正常に完了したことよりも強い証拠です。

よくあるDockerホームラボの問題と対処法

ホームラボの次のコンテナを選ぶ

最初のComposeスタックが再起動と小さな更新を乗り越えた後、実際の家庭のニーズを解決する1つのサービスを追加します。各カテゴリは異なる運用上の教訓を紹介します：

家全体が1つのネットワークサービスの恩恵を受ける場合、DNSレベルのフィルターが有用です。ストレージワークフローでは、プライベートファイル同期が、設定やデータベースが使い捨てコンテナ層の外にあるべき理由を示しています。Plexメディアサーバーは、メディアの権限、メタデータの配置、可能なトランスコーディング要件を追加します。

複数の重要なサービスを一度に追加しないでください。ドキュメント化されたパス、限定された露出、テスト済みのバックアップを備えた小さなスタックは、誰も確実に再構築できない混雑したダッシュボードよりも役立ちます。

よくある質問（FAQs）

ARMベースのNASでDockerを使えますか？

多くの場合、はい。イメージはNASのアーキテクチャ用にビルドされている必要があります。特にamd64はサポートしてもarm64はサポートしない小規模プロジェクトでは、展開前にイメージのプラットフォームを確認してください。アーキテクチャの不一致は、Composeファイルが正しくてもコンテナの起動を妨げることがあります。

DockerホームラボにはどのくらいのRAMが必要ですか？

一概には言えません。DNSフィルター、メディアサーバー、データベース、AIサービスはそれぞれメモリ使用量が大きく異なります。実行予定のサービスをリストアップし、小さなスタックから始めて数日間のピーク使用量を測定し、OS、ファイルシステムキャッシュ、アップデート、一時的なスパイクのための余裕を持たせましょう。

NASにGUIがある場合でもDocker Composeは必要ですか？

いいえ。よく設計されたGUIは、すべてのパス、ポート、変数、再起動設定を公開することでシンプルなホームラボを管理できます。Composeは、バージョン管理された設定、より簡単な移行、再現可能な復旧、または複数の関連サービスを1つのスタックで扱いたい場合により価値があります。

すべてのコンテナに独自のネットワークが必要ですか？

必ずしもそうではありません。すべてのコンテナに個別のネットワークを割り当てるのではなく、アプリケーションの境界ごとにネットワークを作成しましょう。ウェブアプリとそのデータベースは1つのプライベートネットワークを共有し、無関係なメディアサーバーは別のネットワークを使うことがあります。非Dockerデバイスが必要とするポートだけを公開してください。

Dockerサービスにリモートで安全にアクセスする最も安全な方法は何ですか？

個人利用の場合、自宅で運用する個人VPNを使うことで、複数のアプリケーションポートを公開する必要を減らせます。公開サービスには通常、リバースプロキシ、HTTPS、強力な認証、適時のアップデート、そして何を非公開にするかの明確な判断が必要です。

Dockerのバックアップが完全かどうかはどう判断すればいいですか？

Composeファイルからコンテナを再作成し、保存された永続データからアプリケーションの状態を復元できることが理想です。イメージだけのバックアップや、データベースや設定ディレクトリを含まないComposeファイルは、多くの状態を持つサービスには不十分です。

再現可能なホームラボを構築する

ホームラボでDockerを使いこなすことは、コンテナを集めることよりも、各サービスを再現可能にすることが重要です。まずDockerを検証し、アプリケーションごとに1つのComposeプロジェクトを維持し、状態はコンテナ外に保存し、必要なポートだけを公開し、サービスが重要になる前に復元テストを行いましょう。

最初のスタックが再起動、アップデート、リカバリ演習を乗り越えたら、同じ手順で次のアプリケーションを追加します。その順序により、コンテナがたまたま動作する場所だったNASが、理解しやすく、維持管理でき、再構築可能なホームサーバーに変わります。