ZimaOSではリバースプロキシを利用できます。この情報源における本当の制限は、Dockerネットワーク自体ではなく、GUIからインストールしたアプリを取り巻く利便性レイヤーです。Traefikは、各サービスに適切なラベルが設定され、予測可能なComposeサービス名が付けられ、共有Dockerネットワークが用意されている場合に最も効果を発揮します。これらを制御するのは、簡略化されたGUIフォームでアプリをインストールする場合よりも、Composeでスタックを作成する場合のほうがはるかに簡単です。
そのため、元の回答では、GUI中心のZimaOSユーザーの多くにはNginx Proxy Managerを、Composeを使って対象アプリをデプロイする意思があるユーザーにはTraefikを推奨しています。これはコミュニティの案内であり、IceWhale公式のリバースプロキシ構成ではありません。
GUIからインストールしたアプリでTraefikが扱いにくい理由
Traefikが最も得意とするのは、ルーター、サービス、エントリーポイント、TLSルールなどのラベルを使ったDockerの自動検出です。アプリのUIで任意のラベルを設定できない場合、またはコンテナ名が自動生成されて扱いにくい場合、Traefikの自動化機能の多くが失われます。
Composeで完全な制御を取り戻す
現在のZimaOS 1.7 App Store 2.0はネイティブYAMLに対応しており、ZimaOSの開発者向けドキュメントでは、標準のDocker Composeがランタイム構成モデルとして扱われています。Composeを使えば、次の項目を定義できます。
- 安定したサービス名
- カスタムネットワーク
- Traefikラベル
- ホストポートとコンテナポートの明示的な指定
- ボリュームと再起動ポリシー
現在のZimaOS Composeモデルを使用してください。
Nginx Proxy Managerが簡単な理由
Nginx Proxy Managerでは、すべてのバックエンドアプリに検出用ラベルを付ける必要がありません。プロキシホストを手動で作成し、安定したコンテナ名/IP、またはZimaOSホストとアプリケーションが公開しているポートを指定できます。
この手動設定は大規模環境では洗練されていませんが、App StoreアプリとカスタムComposeスタックが混在する環境では扱いやすくなります。
プロキシを開始する前にポート80と443を計画する
ZimaOS自体のWebUIとHTTPS設定が、標準のWebポートを使用している場合があります。別のプロセスがすでに使用している同じホストIP/ポートに、リバースプロキシをバインドすることはできません。
ZimaOS WebUIを別のポートに移動する、別のインターフェース/IPを使用する、またはプロキシを異なる外部ポートで意図的に公開する、といった方法を取ってください。
共有Dockerネットワークで不要なホスト経由のヘアピン接続を回避する
プロキシと対象アプリがユーザー定義のDockerネットワークを共有している場合は、サービス名またはコンテナ名と内部ポートを直接指定してプロキシします。これにより、通信をDocker内部に留め、公開されたホストポートに依存せずに済みます。
ネットワークを適切に制御できないGUIアプリでは、ホストIPと公開ポートを使ったプロキシでも動作します。
ZimaOSダッシュボードをプロキシするかどうかは別途判断する
すべてのプロキシホストを初期設定のままZimaOSのIPに向けないでください。ZimaOS WebUI自体を意図的にプロキシしたい場合に限り、そのアップストリームを使用します。
リバースプロキシを使っても、アプリが自動的に安全に公開されるわけではない
公開HTTPS証明書が暗号化するのは通信経路だけです。機密性の高いアプリでは、認証、多要素認証、アクセス制御ミドルウェア、IP制限、またはVPN経由のみの公開が必要になる場合があります。
ZimaOSリバースプロキシに関するよくある質問
ZimaOSではリバースプロキシを利用できないのですか？
いいえ。情報源のコミュニティ回答では、利用可能だと説明されています。主な問題は、GUIアプリのメタデータ、ネットワーク、使用中のポートに関するものです。
GUIアプリが混在する環境では、どの選択肢が簡単ですか？
通常はNginx Proxy Managerのほうが簡単です。アプリごとにTraefikラベルを設定しなくても、手動で構成できるためです。
Traefikはどのような場合に最も適していますか？
アプリスタックをComposeでデプロイし、ラベル、サービス名、ネットワークを自分で管理できる場合です。
