ホームラボにおけるDocker Compose：構成、プロファイル、およびベストプラクティス

インフォマテックデジタル » Recursos » ホームラボにおけるDocker Compose：構成、プロファイル、およびベストプラクティス

輸送用コンテナを使って現代的なホームラボを構築することは、多くの技術者にとって人気の趣味となっている。 Docker Composeは、そのセットアップの中心となることがほとんどです。サービスをYAMLで定義し、Gitでバージョン管理すれば、たった1つのコマンドで環境全体を起動できます。

さて、成長し始めると、いろいろなことが起こります。コンテナが2つか3つから 数十のサービス、内部ネットワーク、リバースプロキシ、データベース、およびCIランナーそこで大きな疑問が生じます。巨大な単一のDocker Composeファイルを使うべきか、それとも多数の小さなファイルを使うべきか？プロファイル、ネットワーク、バックアップ、セキュリティをどのように整理し、さらに移行を容易にするにはどうすればよいのか？

ホームラボでDocker Composeをセットアップするための実践的なアプローチ

実際には、Homelabsをしばらく使用している人は、それぞれに長所と短所がある3つのCompose組織モデルのいずれかで運用していることが多い。 適切なアプローチを選択することで、マシンの拡張や移行時に発生する多くの問題を回避できます。.

片側には、 Docker Runは当初は自由な形で導入され、その後Portainerに移行し、最終的にDocker Composeへと移行した。これはよくあることです。Portainerは優れた視認性、ユーザーフレンドリーなインターフェース、テンプレートなどを提供しますが、最終的には、ファイルに何も保存されていない場合、複雑なパラメータの編集や構成の移行が面倒になります。

その反対の極端な例としては、 すべてを単一の「メガ」docker-compose.ymlに統合しました リバースプロキシ、メディア、ユーティリティ、モニタリング、LLM、データベースなど、ホームラボに必要なあらゆるサービスを単一のスタックで実行できます。

その中間で、多くのユーザーは混合アプローチを選択している。 コンテキストごとにグループ化された複数の小さな docker-compose.yml ファイル （例えば、メディア、インフラストラクチャ、生産性、モニタリングなど）すべてが同じリポジトリの下にあり、通常はグローバル環境変数を共有しています。

両方の世界をうまく融合させた、実に洗練された解決策がある。 他のファイルを含むルートのdocker-composeファイル （それぞれアプリやサービスのサブフォルダに格納されます）。こうすることで、ホームラボの全体像を把握しながら、読みにくい1000行ものYAMLファイルに悩まされることもありません。

プロファイル、機能別グループ化、大規模ホームラボ

ホームラボが 30、40、または50のサービス （データベース、キャッシュ、インデクサーなどのバックアップサービスを含む）これには秩序をもたらすことが不可欠です。 機能によるグループ化 の使用のように Docker Composeプロファイル.

よくあるパターンとしては、すべてを単一のCompose「プロジェクト」にまとめ、プロファイルごとに論理的に分割する方法があります。例えば、次のようになります。

• コアプロファイルホームラボの中核となる構成で、リバースプロキシとしてTraefikを使用し、同一ドメイン内のすべてのアプリをHTTPSで認証するためのIDプロバイダー（OAuthやAuthentikなど）を備えています。
• メディアプロフィールPlex、Sonarr、Radarr、Ombi、SABnzbd、qBittorrentなどのサービスは、マルチメディアコンテンツのキュレーション、ダウンロード、配信を担当します。
• 公益事業概要コンテナやアップデートの管理・監視には、Portainer、Watchtower（使用する場合）、Diun、dockcheckなどのツールを使用します。
• インフラストラクチャ/監視プロファイルTraefik、cAdvisor、Prometheus、Grafana、Uptime Kuma、Dozzle、および監視とログ記録に関連するすべてのもの。
• 実験プロファイルまたはLLM: LLM や興味深いアプリ (ChatGPT Next Web local、LibreOffice Online など) 用の特定のスタックで、通常はデフォルトで無効になっています。

プロフィールの素晴らしいところは、 インフラストラクチャの一部のみを起動できます ニーズに応じて選択できます。例えば、低消費電力のミニPCではコアとインフラストラクチャのプロファイルのみを実行し、ディスクやGPUを多く搭載した大型サーバーではメディアプロファイルのみを実行するといったことが可能です。

適切に設計されたリポジトリには、通常、 docker-compose.yml「master」は、apps/またはservices/フォルダ内の個々のファイルにインクルードをプルします。さらに、ほぼすべてのサービスは単一のファイルで設定できます。 .env グローバルファイルと、secrets/ ディレクトリ内のいくつかの秘密情報これにより、初期設定が大幅に簡素化されます。

このパターンに従うと、ホームラボの管理は基本的に .envファイルとシークレットを編集し、プロファイルを有効または無効にし、各ホストで起動するサービスを決定します。複数のコンピュータに同じアプリケーションセットを展開する場合に最適です。

巨大な単一のdocker-composeファイルと、複数の小さなファイル

これは永遠の議論である。 すべてを1つのdocker-compose.ymlファイルにまとめるのか、それともサービス/スタックごとに複数のファイルにするのか？ 本当の答えはたいてい「何を優先したいかによります。移行の簡便さか、サービスごとの明確さか。」ということになります。

誰が擁護するのか シングルマスターファイル 通常、いくつかの利点が強調されます。

• ホストの移行はとても簡単ですリポジトリをクローンし、.env ファイルとシークレットをコピーし、ボリュームをマウントして、`docker compose up -d` を実行します。ディレクトリごとに操作する必要はありません。
• 真実の規範としてのインフラストラクチャホームラボのトポロジー全体（サービス、ネットワーク、ボリューム、依存関係）が1か所にまとめられています。
• 集中更新イメージのバージョン、再起動ポリシー、ログ記録などを変更する場合、どこをいじればよいか正確にわかります。

しかし、明らかな欠点もあります。巨大なYAMLファイルはメンテナンスが難しく、 マージの競合が増加する 特定の問題をデバッグしようとすると、何百行にも及ぶ巨大なコードと格闘することになる。すべてが大きくなりすぎると、少し後悔の念に駆られるのはよくあることだ。

もう一つのアプローチは、 アプリケーションごと、または論理スタックごとに1つのdocker-compose.ymlファイル。次のような構造の中で：

docker/
├── bookstack/
│   └── docker-compose.yml
├── dashy/
│   └── docker-compose.yml
└── traefik/
    └── docker-compose.yml

これにより、各コンテナは次のような名前になります。 bookstack-app-1 o traefikリバースプロキシ-1これにより、問題を迅速に特定できます。例えば、bookstack-app-1 コンテナがクラッシュした場合、どのフォルダを調べればよいかが正確にわかります。

見た目ははるかにすっきりしていて これにより、各サービスを個別に管理できます。 （他の部分に影響を与えることなく、開始、停止、または更新できます。）さらに、Dozzleのようなアプリケーションでは、ログをより適切に整理するために、スタックを分離する機能を活用しています。

トレードオフは、 すべてをあまりにも細かく分離してしまうと、Traefikや共有ネットワークなどの共通サービス間の連携に、より一層の注意が必要になります。: 外部ネットワークは宣言する必要があり、特定の Traefik ラベルを使用する必要があり、他の docker-compose によって作成されたネットワークの命名規則を覚えておく必要があります。

.env、オーバーライド、バージョン管理に関するベストプラクティス

最も過小評価されているトリックの1つは 設定を.envファイルに一元化するdocker-compose.yml に環境変数を大量に記述する代わりに、次のように定義します。

DB_USERNAME=myuser
DB_PASSWORD=secretpassword

そしてYAMLでは次のように参照されます ${DB_USERNAME} o ${DB_PASSWORD}これにより、一目で内容が読みやすくなり、 複数のサービス間で変数を共有する そして何よりも、パスワードは別のファイルに保存してください（そのファイルはGitから除外できます）。

これは、さまざまな環境（本番環境、テスト環境、開発環境）で非常に役立ちます。 docker-compose.override.yml を活用する基本的なdocker-compose.ymlファイルを用意し、オーバーライドではポート、パス、デバッグフラグなど、変更が必要な部分のみを上書きするという考え方です。

例えば、開発環境ではオーバーライドをロードできます。 別のポートを公開し、デバッグモードを有効にして、ローカルのソースコードをマウントします。メインのYAMLファイルには手を加えず、起動する環境に合わせてスタックを調整します。

明らかに 本格的なホームラボを構築したいなら、Gitを使ってすべてのファイルをバージョン管理することが必須です。通常は次のようなものがあります。

homelab-docker/
├── docker-compose.yml
├── .env.example
├── services/
│   ├── media/
│   ├── infra/
│   └── ...
└── scripts/

そこからリポジトリを初期化し、インフラストラクチャの変更をコミットし、何かが壊れた場合は、 Composeの以前のバージョンに数秒で戻すことができます。少し野心的なホームラボにとって、これは単なる選択肢ではなく、気が狂いそうになるのを避ける唯一の方法だ。

ネットワーク、Traefik、およびセキュアサービスの露出

中級レベルのホームラボのほぼすべてに、同じ組み合わせが見られる。 Traefikをリバースプロキシおよび集中型IDプロバイダー（AuthまたはAuthentik）として使用するこれにより、HTTPSとSSOを使用して、サブドメインで多数のアプリを公開できます。

典型的なパターンとしては、専用のDockerネットワークをセットアップすることが挙げられます。 リバースプロキシ あるいは、Traefikと外部に提供するすべてのWebサービスが接続されている構成などです。残りのコンテナ（データベース、キャッシュなど）は、分離された内部ネットワーク上に残ります。

Traefikを使用し、サービスを異なるdocker-composeに分割する場合は、 共有外部ネットワークを定義するこんな感じです。

services:
  bookstack:
    image: lscr.io/linuxserver/bookstack
    networks:
      - traefik-net
    labels:
      - "traefik.docker.network=traefik_default"

networks:
  traefik-net:
    name: traefik_default
    external: true

ここでは、traefik_default ネットワークは Traefik スタックによって作成され、他のサービスは traefik-net と呼ばれる外部ネットワークを介して追加されます。タグは Traefik に指示します... トラフィックのルーティングにはどのネットワークを使用すべきか.

単一のスタックにバックエンドサービス（たとえば、Webコンテナとそのデータベース）が含まれる場合、 それらを共有のデフォルトネットワークに接続し、WebコンテナのみにTraefikネットワークへのアクセス権限を与えます。データベースには、Traefikが無視するように、traefik.enable=falseというラベルが付けられます。

このタイプの設定には、主に2つの利点があります。 サービス間の隔離と制御された曝露Traefikラベルでマークされ、かつプロキシネットワーク上にあるコンテナのみが、外部からアクセス可能になります。

データ永続性、ボリューム、およびディスク構造

永続的なデータがないホームラボはあまり役に立ちません。データベース、設定、メディア、ドキュメントなど、すべてがdocker composeがダウンしても存続する必要があります。 冊子と製本はあなたの生命保険です.

多くの人は、次のような構造で収納を整理しています。

/mnt/storage/
├── downloads/
│   ├── movies/
│   └── tv/
├── media/
│   ├── movies/
│   ├── tv/
│   └── music/
└── srv/
    └── 

アイデアは ダウンローダー（qBittorrent、SABnzbdなど）はダウンロードフォルダのみを参照しますRadarrやSonarrのようなマネージャーはダウンロードとメディアの両方にアクセスでき（ハードリンクの移動や作成が可能）、PlexやJellyfinのようなサーバーはメディアフォルダしか認識できません。

この方法で、 最低限の特権各コンテナは、実際に必要なものにのみアクセスします。また、この明確な分離は、クラウドや外部ドライブにバックアップするボリュームやパスを決定する際にも役立ちます。

srv ディレクトリは通常、アプリケーションの設定を保存するために使用されます (例: /srv/jellyfin/config、/srv/traefik、/srv/paperless など)。通常、このディレクトリには部分的にバージョン管理されたファイル (テンプレート、Caddyfile など) が格納され、重要度の高いファイルやリソースを大量に消費するファイルは除外されます。

場合によっては、 ハードリンク ダウンロードチェーンにおいて、RadarrやSonarrといったサービスは、ダウンロードしたファイルをリンクさせることで、ディスク容量を重複させることなくシード状態を維持できます。TRaSHGuidesなどのガイドで提案されているディレクトリ設計は、まさにこの原理に基づいています。

GitHub Actionsとローカルランナーを使用したデプロイメントの自動化

次のレベルに進みたい場合は、さらに一歩進んで CI/CDを使用してホームラボのアップデートを自動化する複数のユーザーが、Jenkinsや類似のツールを、GitHub Actionsと自身のホームラボにホストされたランナーを使用したワークフローに置き換えている。

仕組みはシンプルです。Homelabリポジトリのメインブランチにプッシュするたびに、 GitHub Actionsワークフローが起動され、テストやリンターが実行され、すべてがうまくいけば変更内容がサーバーにデプロイされます。.

一般的なワークフローには、次のような手順が含まれます。

• Gitleaksタイプの秘密スキャナー: 誤ってパスワードやトークンをリポジトリにアップロードしてしまった場合。
• リンティング YAMLやインフラストラクチャコードの読みやすく一貫性のある形式を維持するため。
• ホームラボ内のリポジトリを更新する: 対象サーバーでgit pullを実行します。
• コンテナの制御された再生成古いものを停止し、新しいものを起動して、ステータスを確認してください。

利点: セキュリティの向上 (秘密情報の漏洩を制御できます)、コードの品質の向上、 1回のプッシュで繰り返し展開可能ローカルランナーを使用しているため、イメージやボリュームはネットワークから外部に送信されません。GitHubインターフェースを使用してパイプラインを視覚化するだけです。

Docker Composeがホームラボでの作業を格段に楽にする理由

多くの人々は長年頼りにしてきた Docker RunとPortainer インシデントや移行の結果、そのアプローチを再評価せざるを得なくなるまで。ホストを失ったり、サービスを別のマシンに移行したりする必要がある場合、 Portainerで個別のコマンドや設定だけに頼るのは落とし穴です.

Composeに切り替えると、大きな違いは サービス定義全体がテキストになります。ボリューム、ポート、ネットワーク、ラベル、変数…すべてがYAMLファイルにまとめられており、コピー、共有、バージョン管理、再利用が可能です。

サービスの編集はもはや「コンテナを手動で再構築する」ことではなく、 ファイル内の行を変更し、保存して、docker compose up -d を実行します。元のコマンドを覚えておく必要も、Portainerの複数の画面をクリックしていく必要もありません。

さらに、複数のサーバー（ミニPC、NAS、デスクトップ）を扱う場合、 同じcomposeファイルを別のマシンにコピーし、4つのパスを調整して、異なるハードウェアで同じスタックを起動します。実際、多くの人が、データ損失や混乱した移行といった危機を経験した後、Composeのおかげでその後のトラブルで多くの時間を節約できたと認めている。

さらに、既存のサービスから新しいサービスを作成することも容易になります。たとえば、 JellyfinをマウントするためにPlexの設定を複製します YAMLブロックをコピーすれば、同じメディアパスとトランスコーディングデバイスを再利用するのにかかる時間はわずか数分です。

最適化: コンテキストの構築、マルチステージビルド、およびリソース

多くのホームラボコンテナは公開イメージから作成されますが、場合によっては独自のイメージをコンパイルする必要があるでしょう。そのような場合は、注意が必要です。 コンテキストを構築する: リポジトリ全体をフィルタリングせずに送信するのではなく、プロジェクトフォルダ（適切な .dockerignore を使用）に限定して送信することで、ビルドを高速かつ軽量化できます。

もう1つの非常に便利なテクニックは、 マルチステージビルド Dockerfileでは、最初のフェーズで依存関係をインストールしてコンパイルし、2番目のフェーズで必要なアーティファクトのみを小さなベースイメージにコピーします。結果：最終イメージ はるかに小さく、安全ですツールチェーンや追加ライブラリを引き継がないためです。

Compose側では、定義するオプションがあります CPUとRAMの制限 （特にSwarm環境やDockerがこれらのパラメータを尊重する場合）リソースを大量に消費するアプリケーションがリソースを独占するのを防ぐためです。Homelabsでは、これにより設定ミスのあるサービスがシステム全体に悪影響を及ぼすのを防ぐことができます。

忘れないでください 再起動ポリシー （再起動：常に、停止されない限り、障害発生時）：これらの設定により、重要なサービス（リバースプロキシ、VPN、キーデータベース）が再起動後または一時的な障害発生後に自動的に再起動されることが保証されます。

最後に、次のようなコマンドを使用して定期的な清掃タスクをスケジュールすることをお勧めします。 Dockerイメージの削除、Dockerコンテナの削除、およびDockerボリュームの削除 古いビルドの残骸、停止したコンテナ、または孤立したボリュームを削除して、ディスク容量を解放します。

医療サービス、記録および監視

ホームラボがブラックボックスにならないようにするためには、次の3つの重要な側面に取り組むことが重要です。 健康診断、管理されたログ記録と監視Docker Compose を使用すると、サービスごとにヘルスチェックを宣言できます (curl -f http://localhost のようなコマンドや特定のスクリプトを使用)。これにより、コンテナが正常であるとみなされるかどうかを判断できます。

これにより、 「健全な」コンテナのみがトラフィックを受け取る。 （例えば、Traefikを介して）応答しなくなった場合は、設定されたポリシーに従って再起動します。これにより、最小限の労力で耐障害性を大幅に向上させることができます。

ログに関しては、制限付きドライバ json ファイルを調整します。 最大サイズと最大ファイル数 これにより、ディスクが何ギガバイトものログファイルでいっぱいになるのを防ぎます。DozzleのようなWebツールを使えば、ブラウザからすべてのコンテナのログを閲覧できるため、特定のサービスのデバッグに非常に便利です。

指標と継続的なモニタリングに関して、古典的な組み合わせは cアドバイザー + プロメテウス + グラファナcAdvisorはコンテナごとにCPU、メモリ、ディスク、ネットワークの使用状況統計を公開します。Prometheusはそれらを定期的に収集し、Grafanaはそれらを魅力的なダッシュボードに表示し、異常値が急上昇した場合はアラートを発します。

きちんと整備されたホームラボには通常、以下のものも含まれます。 可用性チェックのためのKumaの稼働時間 （HTTP、ICMP、TCPなど）に加え、Duplicatiのような自動バックアップシステムを使って重要なデータを他のディスクやクラウドにコピーします。こうすることで、何が起こっているかを把握でき、万が一問題が発生した場合でも、大切なデータを失うことがありません。

ホームラボのセキュリティとリモートアクセス

どんなに手作りのセットアップであっても、安全はオプションではありません。多くの人が NASまたはそのサービスを外部に直接公開しないでください。VPNを介してリモートアクセスを制限する（WireGuardは、その性能とシンプルさから非常に人気のある選択肢です）。

このモデルでは、ルーターはゲートウェイとして機能します。VPNサーバーに対してはランダムなポートのみが開かれ、接続されると、 内部サービスへのすべてのリクエストは、暗号化されたトンネルを経由します。Traefikもアプリも、事前のフィルター処理なしにはインターネットに公開されません。

自分でVPNを管理したくない人は、 Cloudflare Tunnel または Tailscale ポートを開放せずにホームラボにアクセスする方法です。これらは便利な代替手段ですが、プライバシーを最優先事項とする場合は、これらの第三者がどのようなメタデータを収集する可能性があるかを考慮する必要があります。

もう XNUMX つの良い習慣は、 サーバーとNASのディスクを暗号化するパッチは定期的に適用し、自動更新は制限しましょう（多くのユーザーはWatchtowerを避け、手動で更新を管理しています）。確認していない更新によってHomelabの半分が壊れてしまうよりは、多少遅れていてもきちんと管理する方がはるかに良いでしょう。

ご覧のとおり、「エンタープライズ」レベルに到達する必要はありませんが、 はい、最低限の安全基準と規律基準を設けることは推奨されます。 そうすれば、あなたのホームラボは、まるでザルになったり、常に恐怖の源になったりすることはありません。

結局のところ、Docker Compose を使って本格的なホームラボを構築するには、組織力、常識、そして試行錯誤する意欲が不可欠です。サービスをグループ化し、ネットワークを適切に定義し、Git でドキュメントを作成し、ある程度自動化すれば、単一のコマンドで起動でき、別のマシンに簡単に移行でき、制御不能なジャングルになることなく少しずつ拡張できる環境が完成します。