TP-Link Omada ControllerをCasaOSに永続的なDockerサービスとしてインストールし、data、work、logsディレクトリを保持します。 以前の2023年のチュートリアルは概念的には有用ですが、保守されているmbentley/omada-controllerイメージは進化しており、現在のデプロイでは検出、アダプション、管理、キャプティブポータル機能のために複数のTCPポートとUDPポートを公開する必要があります。
Omadaを単一ポートのWebアプリとして扱わないでください。UDPポートまたは管理ポートが不足していると、Web UIは正常に開いても、検出やデバイスのアダプションに失敗することがあります。
保守されているOmada Dockerイメージを使用する
最新の Omada Controller Dockerイメージ は現在も積極的に保守されており、最新のアップグレード手順が含まれています。
3つの主要なデータパスをすべて永続化する
イメージでは、次の永続ボリュームがドキュメント化されています。
/opt/tplink/EAPController/data/opt/tplink/EAPController/work/opt/tplink/EAPController/logs
これらをCasaOSのAppDataフォルダーにマッピングし、アップグレードでコントローラーの状態が消去されないようにします。
必要なポートを公開する
Omadaは管理UI以外にもポートを使用します。現在のコンテナドキュメントには、次のようなポートが記載されています。
- HTTPS管理用に8043/TCP。
- HTTP管理用に8088/TCP。
- HTTPSポータル用に8843/TCP。
- 検出用に27001/UDPおよび29810/UDP。
- 現在のリリースでは、デバイス管理用に29811–29817/TCP。
デプロイに必要なサービスのみを公開します。ただし、検出ポートとアダプションポートを省略してから、コントローラーが壊れていると判断しないでください。
通常はブリッジモードで動作します
Omadaデバイスは、公開されたホストポートを介してコンテナと通信できます。ホストネットワークや専用のmacvlanアドレスが自動的に必要になるわけではありません。
VLAN間でデバイス検出に失敗する場合、それはCasaOSのインストールではなく、ルーティングされた検出またはネットワーク設計の問題です。
CasaOSカスタムアプリとしてインストールする方法
- カスタムDockerアプリを作成します。
- 最新の
mbentley/omada-controllerイメージ/タグ。 - 永続化するdata/work/logディレクトリをマッピングします。
- 必要なTCPポートとUDPポートを公開します。
- 次のような再起動ポリシーを設定します
停止時以外は自動再起動. - コンテナを起動し、HTTPS管理ポートを開きます。
メジャーアップグレードの前にコントローラーをバックアップする
Omadaコントローラーのアップグレードには、データベースの変更が伴う場合があります。メジャーバージョンを変更する前に、特に移行手順が必要なリリースの前後では、コントローラーのバックアップをエクスポートしてください。
管理ポートを公開インターネットにさらさないでください。
コントローラーは信頼できるLANまたはプライベートVPN上に置いてください。同じコンテナ導入の原則については、Docker導入ガイドを使用してください。
安定したコントローラーアドレスを使用する
Omadaデバイスは再起動後もコントローラーを見つけ続ける必要があります。DHCP予約、または慎重に管理した静的IPによって、CasaOSサーバーに安定したLANアドレスを割り当ててください。ホストのアドレスが変わると、導入済みのデバイスが以前のコントローラーアドレスへの接続を試し続けることがあります。
VLAN間の検出には追加のネットワーク設計が必要になる場合があります
ローカルブロードキャストによる検出は、コントローラーと新しいOmadaデバイスが同じレイヤー2ネットワーク上にある場合に最も適切に機能します。アクセスポイントとコントローラーが異なるVLAN上にある場合、Dockerポートを公開するだけでは、ルーターを越えて検出ブロードキャストを通過させられないことがあります。
その場合は、TP-Linkがサポートするレイヤー3の導入／informプロセスを使用するか、ルーティング／ファイアウォールルールを意図的に設定してください。コンテナを繰り返し再インストールしてVLANのルーティング問題を解決しようとしないでください。
小規模なCasaOSホストでJavaメモリを確認する
OmadaはJavaアプリケーションであり、軽量なDNSコンテナやダッシュボードコンテナよりも大幅に多くのメモリを消費することがあります。メンテナンスされているイメージではメモリ関連の設定が公開されているため、リソースに制約のある環境ではCasaOS、Docker、その他のサービス用に十分なRAMを残してください。
負荷の高い状態でコンテナが再起動する場合は、データベースが破損していると決めつける前に、ログとメモリプレッシャーを調べてください。
アップグレードのたびにデバイスの導入を確認する
Omadaを大規模にアップデートした後は、コントローラーUIが開くこと、導入済みデバイスが接続されたままであること、ディスカバリー／導入用ポートが引き続き公開されていることを確認してください。コンテナが「実行中」であることだけでは、ネットワーク管理プレーンが正常である十分な証拠にはなりません。
よくある質問
Omadaにはアクセスできますが、デバイスが検出されないのはなぜですか？
Webポートが機能していても、UDPディスカバリー用ポートやTCP管理ポートが不足している場合があります。必要な公開ポートをすべて確認してください。
ホストモードは必要ですか？
いいえ。適切に公開ポートを設定したブリッジモードは、多くの環境で機能します。
何をバックアップすべきですか？
文書化されているデータ、構成、ログの各ディレクトリを永続化し、大規模なアップグレードの前にはOmada独自のコントローラーバックアップも使用してください。
Omadaをインターネットに直接公開してもよいですか？
そのようなことは避けてください。管理UIはLAN内、またはプライベートなリモートアクセス環境に限定してください。
