オプションのホームサーバーサービス用にDocker Composeプロファイルを設定する方法

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

How to Set Up Docker Compose Profiles for Optional Home Server Services - Zima Store Online

通常の動作に必要なサービスはプロファイルを付けず、監視、管理UI、デバッグ用シェル、バッチジョブ、実験的アプリケーションなどの任意ツールにだけプロファイルを割り当てて、Docker Composeのプロファイルを設定します。

プロファイルはサービスを選択する仕組みであり、セキュリティ境界でも依存関係の解決機能でもありません。安全なホームサーバー設計では、デフォルトのスタックを分かりやすくし、目的別にプロファイル名を付け、プロファイルまたは1つの明示的なサービスを対象にしたときに何が起動するかをテストします。

最小限の健全なスタックにはプロファイルを付けない

アプリケーションが動作するために常に必要なサービスを特定します。中核となるWebアプリ、データベース、キュー、認証サービス、または本当に必須のリバースプロキシなどです。通常の docker compose up -d でそれらが含まれるよう、これらのサービスにはプロファイルを付けません。

最近のプロファイルのないサービスはデフォルトで起動するという解説でも、まさにこの考え方が使われています。デフォルトのサービスは常に利用できる状態にし、デバッグや任意のツールは必要なときだけ有効化します。

開発中にフロントエンドだけを実行することがあるからといって、重要なデータベースにプロファイルを付けないでください。本番運用とトラブルシューティングの目的は異なります。ホームサーバーのデフォルトコマンドによって、半端なサービス構成が意図せず生成されるべきではありません。

任意のサービスを目的別にグループ化する

有用なプロファイル名は、サービスが任意である理由を示します。monitoring、debug、admin、batch、ai、experimentalなどです。コンテナごとにプロファイルを1つ作成するよりも、この方法のほうが規模を拡大しやすくなります。

2026年の目的別にグループ化したプロファイルの例では、監視、開発者向けツール、バッチ処理が自然なプロファイルグループとして示され、各プロファイルが追加するサービスを文書化することを推奨しています。

ZimaSpaceのホームサーバーで試す価値のある任意のアプリケーションの一覧は、この手法の適用範囲を考えるうえで役立ちます。1つのComposeプロジェクトに、常時実行したくないサービスが含まれている場合に、プロファイルが有効です。

プロファイルが依存関係を自動的に修復すると考えない

プロファイル付きのサービスが、プロファイルのない中核サービスに依存する構成は問題なく作れます。問題が発生するのは、任意のプロファイル付きサービスが、現在のモデルで有効化されていない別のプロファイルに属するサービスに依存している場合です。Composeは、「これらは一緒に扱うもの」という人間の意図だけから、すべてのプロファイル間の関係を推測することはできません。

プロファイルの割り当ては、実際のサービス依存関係とも一致していなければなりません。depends_onは実際の起動依存関係に限って明示的に使用し、サポートするすべてのプロファイルの組み合わせについて、解決後のComposeモデルを確認します。

サポートする各プロファイルの組み合わせについて、解決後のComposeモデルを生成または確認します。YAMLファイルを解析できるだけでは不十分です。1つのプロファイルを有効化した結果、無効または不完全な依存関係グラフが生成される可能性があるためです。

-15% OFF

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

Single board computer zimaboard2

明示的なサービス指定とプロファイルの有効化を分けてテストする

プロファイル付きサービスを直接指定する場合は特殊なケースです。現在のホームラボ向け解説でも、指定したサービスだけを意図的に起動する動作が確認されています。指定したサービスと宣言された依存サービスは起動しますが、同じプロファイルを共有する他のサービスまで自動的に起動するわけではありません。

2026年のプロファイルは慎重に使うというレビューでは、後から誰も理解できない隠れたデプロイ構成を作るのではなく、任意のツールに限定してプロファイルを使うことを推奨しています。

スタックを信頼して運用する前に、プロファイルなし、各プロファイル単体、サポートするプロファイルの組み合わせ、そして1つのプロファイル付きサービスを直接指定した場合の4つをテストします。それぞれの場合に、どのコンテナを実行し、どのコンテナを実行しないべきかを記録します。

セキュリティとデータ永続化の判断にプロファイルを使わない

デフォルトで停止しているサービスでも、有効化したときに安全になるわけではありません。管理ツールには、認証、ネットワーク制限、安全なポート公開、適切なファイルシステム権限が引き続き必要です。同様に、任意のサービスを停止しても、明示的に意図していない限り、永続データが削除されてはいけません。

ボリューム、ネットワーク、シークレット、バックアップの責任範囲は、プロファイル名とは別に文書化します。任意の監視サービスには使い捨てのメトリクスしかない場合もありますが、任意のデータベース管理UIに、トラブルシューティング中だけ起動するからという理由で広範な認証情報を与えてはいけません。

docker compose up -dで予測可能な健全な中核が起動し、名前付きの各プロファイルが、復旧モデルを変更することなく、文書化された任意のサービス群を追加できれば、プロファイルは成功です。どのプロファイルでデータベースが現れるのかを推測するために図が必要になるなら、ファイル構成を簡素化してください。