- Docker Swarm は、ネイティブ クラスタリング、メッシュ ルーティング、オーバーレイ ネットワークを提供し、サービスを公開し、複数のノードにわたってコンテナを接続します。
- Portainer Edge Agent (標準または非同期) を使用すると、Docker API を公開したり不要なポートを開いたりすることなく、リモート Swarm 環境を管理できます。
- エッジ コンピューティングでは、Docker と WebAssembly のメリットを活用して、限られたハードウェア上で軽量かつ安全で移植可能なワークロードを実行します。
- Swarm、Portainer、Wasm を組み合わせることで、分散型、フォールト トレラント、管理しやすいエッジ アーキテクチャを作成できます。
Docker Swarm、Portainer、エッジデプロイメントを使い始めると、エージェント、エッジエージェント、メッシュルーティング、オーバーレイネットワーク、異なる都市にあるVPS間のレイテンシなど、混乱しやすいものです。どれも素晴らしいように聞こえますが、実際に設定するとなると、明確で安定していて、ファイアウォールの半分を開放する必要のないものが欲しくなります。
以下の説明では、これらすべてがどのように連携するのかを、分かりやすいスペイン語で詳しく解説します。Docker Swarmがもたらすもの、メッシュルーティングの仕組み、Portainer AgentとEdge Agentの役割（標準モードと非同期モード）、分散環境（例えば、ニューヨークのVPSとシアトルのVPS）の管理方法、そしてWebAssembly（Wasm）を使用したより制限のあるデバイスでもエッジでDockerを活用する方法などについて説明します。
基本概念: Docker Swarm、エッジコンピューティング、Portainer
コマンドをいじり始める前に、Docker Swarmのエッジアーキテクチャに共通するいくつかの基本的な概念を理解しておくことが重要です。具体的には、オーケストレーターとしてのSwarm、エッジコンピューティングの役割、そしてPortainerがなぜ作業を非常に容易にするのか、といった点です。
Docker Swarmは、Dockerのネイティブなクラスタリングモードであり、複数のDocker Engine（例えば、複数のVMやVPS）をグループ化し、あたかも単一の仮想ホストであるかのように管理できます。具体的には、複製されたサービスを簡単にデプロイしたり、ノード間でオーバーレイネットワークを使用したり、負荷分散を行ったり、高可用性を活用したりすることが可能になります。
一方、エッジコンピューティングでは、データ処理をデータ生成場所（センサー、IoTデバイス、小型工場機械、ルーター、ゲートウェイなど）に近づけます。これにより、レイテンシが削減され、クラウドへの帯域幅が節約され、接続が制限されているか断続的であっても動作が可能になります。Dockerは中程度の性能のデバイスではうまく動作しますが、非常に限られたハードウェアでは苦労します。たとえば、不変のLinuxディストリビューションを使用する場合などです。
そこで登場するのがPortainerです。Portainerは、Docker、Swarm、Kubernetes、ACI環境を管理するためのWebインターフェースとAPIを提供する軽量プラットフォームです。Portainerを使えば、単一ホスト上でも、数十のリモートノードにまたがる場合でも、コンテナ、イメージ、ネットワーク、ボリューム、その他のリソースを簡単に管理できます。
これらのリモート環境をPortainerサーバーに接続するには、いくつかの方法があります。従来のPortainerエージェント、Docker API/ソケットへの直接接続、標準モードまたは非同期モードのPortainer Edgeエージェントなどです。適切なオプションを選択することで、クリーンなセットアップと、セキュリティ上の脆弱性やポートが開いたままの状態になるかの大きな違いが生じます。
Docker Swarm: ポート、メッシュルーティング、サービス公開
DockerでSwarmモードを有効にすると、クラスタ内のすべてのノードがイングレスルーティングメッシュと呼ばれる仕組みに参加します。簡単に言うと、クラスタ内のどのノードでも、そのサービスでタスクを実行していなくても、サービスの公開ポートでトラフィックを受信できます。
これらすべてが機能するためには、Swarmノード間で特定のポートを開放する必要があります。具体的には、Swarmネットワークプレーンは以下を使用します。
- ポート 7946 TCP/UDP コンテナネットワーク検出用。
- ポート4789 UDP (構成可能) VXLAN ベースの入力ネットワーク トラフィック用。
さらに、サービス用に公開するポートは、外部ロードバランサー、他のシステム、エンドユーザーなど、サービスを利用する外部リソースからアクセス可能である必要があります。このトラフィックはどのノードからも流入し、メッシュルーティングによってアクティブなサービスコンテナにリダイレクトされます。
Swarm でポートを公開するには、オプションを使用します。 -公開 サービスを作成または更新する場合。パラメータ target コンテナの内部ポートを示し、 published ルーティングメッシュで公開するポートを定義します。公開ポートを指定しない場合、Dockerは各タスクにランダムに高いポート番号を割り当てます。そのため、どのポートが使用されたかを確認するには、タスクを検査する必要があります。
公開されたポート（<PUBLISHED-PORT>）は、 Swarmはサービスを外部に公開します、コンテナ港（<CONTAINER-PORT>コンテナ内でプロセスがリッスンする場所です。例えば、外部ポート8080をNginxサーバーの内部ポート80にアドバタイズした場合、ポート8080の任意のノードにリクエストを送信すると、Swarmはリクエストをアクティブなコンテナの1つにルーティングします。そのため、コンテナが実際にどこで実行されているかを気にする必要はありません。
メッシュルーティングは、ノードのIPアドレスとアドバタイズされたポートをリッスンします。IPアドレスが外部ルーティング可能な場合、サービスはホストの外部からアクセス可能になります。IPアドレスが内部専用の場合、アクセスはホスト自体またはそのプライベートネットワークに制限されます。 dockerサービスの検査 いつでもターゲットポート間の関係を確認することができます（TargetPort）および公開されたもの（PublishedPort).
TCPおよび/またはUDPポートを公開し、ホストモードを使用する
デフォルトでは、Swarmでポートを公開すると、 TCPプロトコルUDPポートを公開したり、TCPとUDPを組み合わせたりする場合は、次の長い構文を使用する必要があります。 --publish キーを調整する protocol a tcp o udp両方を公開し、プロトコルを省略すると、TCP として公開されます。
あなたがすることもできます メッシュルーティングをスキップ いわゆる ホストモードこのモードでは、ノード上のポートにアクセスすると、 のみ そのノードで実行されているサービスインスタンス（存在する場合）に通知します。これを実現するには、長い構文を使用します。 --publish そしてあなたは確立する mode=host何も指定しない場合、または mode=ingressメッシュが使用されます。
ホストモードを使用する場合、予期せぬ事態を避けるために注意すべき点がいくつかあります。サービスタスクが実行されていないノードにアクセスすると、そのポートがアイドル状態であるか、別のアプリケーションによって使用されている可能性があります。また、ノードごとに複数のレプリカを実行する予定がある場合、Dockerにランダムなポートを割り当てさせるか、グローバルサービスまたは制約を使用してノードごとに1つのレプリカに制限しない限り、静的ポートを競合なく使用することはできません。
大規模なアーキテクチャでは、SwarmをHAProxyなどの外部ロードバランサーと組み合わせるのが一般的です。トラフィックと可観測性のニーズに最適な方法に応じて、メッシュルーティングを活用するか、DNSRR（VIPなし）を使用してタスクのIPアドレスに直接負荷分散を行うことで、これを実現できます。
Portainer によるリモート管理: エージェントとエッジエージェント
Portainerは、リモートのDockerまたはSwarm環境をPortainerサーバーに接続するための複数の方法を提供しており、多くの人がここで混乱します。主なオプションは、Portainerエージェントを使用する方法、Docker API/ソケットに直接接続する方法、またはPortainer Edgeエージェント（標準モードまたは非同期モード）をデプロイする方法の3つです。
従来のPortainerエージェントは、 Portainerサーバーと管理対象ホストが同じネットワーク上にあるか、少なくとも直接通信できる環境向けに設計されています。このシナリオでは、サーバーがエージェントに接続するため、サーバーからエージェントを実行しているノードへのポートを開放する必要があります。これは、複数のデータセンターに分散されたVPSやNATの背後にあるホームネットワークを扱う場合には必ずしも望ましいとは限りません。
分散環境において最も安全かつ柔軟な代替手段は、Portainer Edge Agentです。ここでは処理の流れが逆になります。リモートホスト上のEdge AgentがPortainer Serverへの接続を確立します。Edge Agentは受信接続を常時維持するのではなく、定期的にサーバーをポーリングして保留中のジョブを確認し、それに応じて処理を実行します。
Edge Agent が機能するには、Portainer Server が少なくともWeb インターフェイス (UI) ポート(通常は 9443) または Kubernetes の 30779 などの NodePort) を公開する必要があります。さらに、標準モードでは、トンネル ポート(Kubernetes の 8000 または 30776、NodePort あり) も必要です。このトンネルにより、Edge Agent とサーバー間の安全な TLS 接続が確立され、リモート環境とのリアルタイムのやり取りが可能になります。
Portainerの公式インストールガイドでは、サーバーが両方のポートをリッスンするように設定されていますが、お使いの環境のファイアウォールでこれらのポートが公開されていることを確認する必要があります。Portainerは、一定の最小システム要件を満たしていることを前提としています。これらの要件から大きく逸脱している場合は、追加の調整が必要になるか、一部の機能が制限される可能性があります。
Docker Swarm クラスター上の標準モードの Edge エージェント
標準のエッジエージェントを使用してリモートの Docker Swarm 環境を管理する場合、Portainer でのワークフローは通常次のようになります。Portainer メニューから [環境] セクション (環境関連 → 環境) を開き、[環境の追加] をクリックします。そこで「Docker Swarm」を選択し、ウィザードを開始します (ウィザードの開始)。
ウィザード内で、[ Edge Agent Standard]オプションを選択し、環境の詳細（説明的な名前、エージェントが接続する URL、グループ オプションまたはタグなど）を入力します。[その他の設定] セクションでは、ポーリング頻度を調整できます。これは、Edge Agent が新しいタスクや変更をチェックする頻度を決定します。デフォルトでは通常 5 秒ごとですが、トラフィックを削減したり応答性を向上させたい場合は変更できます。
基本項目を入力したら、「作成」をクリックします。環境に事前にラベルを付けたり、自動化スクリプトを準備したりする場合は、この時点で参加トークンを取得して、デプロイメントで再利用できます。その後、Portainerはインストールコマンドを生成するために必要な追加項目を表示します。
次のステップは、リモートホストプラットフォーム（LinuxまたはWindows）を選択し、Portainerによって生成されたコマンドをコピーして、Edge環境で実行することです。このコマンドはEdge Agentイメージをダウンロードし、正しいトークンとURLで構成します。起動すると、新しい環境がPortainerのメイン画面に別のノードとして表示されます。
同様の標準Edge環境を別途デプロイする必要がある場合は、「別の環境を追加」を使用してこのプロセスを繰り返します。すべてのEdge環境の設定が完了したら、「続行」をクリックして他の環境の設定に進むか、「閉じる」をクリックしてメインリストに戻ります。
非同期モードで接続品質が低い Edge エージェント
Portainer Edge Agentの非同期モードは、接続が制限されている、高価である、または非常に不安定なシナリオ（モバイルリンク（5G M2M接続）、地方の接続、断続的にしか接続しないデバイスなど）向けに設計されています。このモードでは、リアルタイムの対話型トンネルは確立されず、代わりにEdge Agentは設定可能な間隔でステータススナップショットをPortainer Serverに送信します。
非同期処理では、リモート環境との対話型セッションを開くことはできませんが、最新のクラスタ状態を表示し、そのスナップショットに基づいてアクションを実行することは可能です。データ消費量が大幅に削減されるため、1メガバイト単位の容量が重要なエッジ環境への導入に最適です。
非同期モードでは、Edge Agentに必要なのは、サーバーがUIポート（9443番ポートまたは同等のNodePort）を開いていることだけです。トンネルポート8000番ポートは不要となり、パブリックポートの公開がさらに簡素化されます。Portainerでの環境設定は標準モードとほぼ同じで、Docker Swarm環境ウィザードで「Edge Agent Async」を選択するだけです。
Edge Async を追加するには、[環境] → [環境の追加] に移動し、[Docker Swarm] を選択してウィザードを起動し、[Edge Agent Async] を選択して基本情報を入力します。[その他の設定] には、Ping、Snapshot、Command という3 つの重要な間隔があり、それぞれハートビートの頻度、環境スナップショットの更新、新しいコマンドの確認を制御します。デフォルトではすべて 1 分に設定されていますが、必要に応じて調整できます。
標準モードと同様に、グループとタグを使用してEdge環境を分類し、環境を作成し、参加トークンを取得し、プラットフォーム（LinuxまたはWindows）用のコマンドが生成されたら、リモートホストで実行できます。各非同期エージェントが登録され、Portainerは受信した最新のスナップショットに基づいてそのステータスを表示できるようになります。
典型的なシナリオ: 異なるリージョンにある2つのVPSとPortainerの使用
よくあるケースとしては、異なる場所に2つのVPS（例えば、1つはニューヨーク、もう1つはシアトル）を所有していて、Portainerを使ってそれらを管理したい場合が挙げられます。Docker Swarmを使うかどうかは別として、Prometheus、cAdvisor、Node Exporterなどのツールを設定し、ノード間でプライベートな内部トラフィックを確立したいというケースです。
このような状況では、Swarm だけを使用するだけで十分なのか、それとも各 VPS に Portainer Agent や Edge Agent も必要なのか疑問に思うかもしれません。Docker Swarm はそれ自体でノード間のオーケストレーションとオーバーレイ ネットワークを提供し、たとえば、ニューヨークの VPS 上の Prometheus インスタンスが暗号化されたオーバーレイ ネットワークを介してシアトルのコンテナからメトリクスを収集することを可能にします。
この文脈において、Portainerは必須ではありませんが、サービス、スタック、ボリューム、ネットワークの管理を一元化するために強く推奨されます。例えばニューヨークのVPSにPortainerサーバーをセットアップすれば、シアトルのVPSをエッジエージェントに接続できます。こうすることで、従来のエージェントのためにDocker APIを開放したり、外部からアクセス可能なポートを維持したりする必要がなくなります。
異なる都市にあるSwarmノード間のレイテンシは通常数十ミリ秒程度であり、Prometheus、Node Exporter、cAdvisorなど、定期的にデータスクレイピングを行うサービスにとっては、ほとんどの場合深刻な問題にはなりません。ただし、レイテンシやノード間の整合性に極めて敏感なサービスを実行する場合は、この点を考慮する必要があります。
要約すると、このタイプの構成で最も一般的で実用的な設定は、Docker Swarmをクラスタとして使用し、 VPS間でオーバーレイネットワークを構築し、Portainer Edge Agent（標準のエージェントよりも優れている）を使用して不要なポートを開放することなくリモートVPSを安全に管理することです。従来のエージェントは、すべてが同じネットワーク上にある場合や、非常に直接的な接続性がある場合に適していますが、地理的に分散した環境では、Edge Agentが論理的な選択肢となります。
Docker Swarm上のPortainerのエッジジョブ
PortainerとSwarm環境を扱う際に役立つもう一つの強力な機能は、エッジジョブです。これらのジョブを使用すると、Portainerで管理されているエッジ環境で実行するタスクを定義できます。これは、メンテナンス、再構成、または定期的なデプロイに非常に便利です。
よくある質問の一つに、Swarmクラスタ内の特定のノードでエッジジョブを強制的に実行できるかどうかというものがあります。多くの場合、ジョブは常にいずれかのノードで実行されるようで、どのノードで実行されるかを明確に制御することはできません。そのため、バランスの取れた動作を期待する場合や、特定のノードをターゲットにしたい場合は、混乱を招く可能性があります。
これを制御する鍵は、Portainerがジョブをどのように分散し、Swarmがジョブの配置をどのように管理するかを理解することにあります。ジョブがEdge Agentによって管理されるノード上のスタンドアロンコンテナとして起動されるか、Swarmクラスタ内のサービスとして起動されるかによって、制約やEdge Jobの設定を通じて制御できる範囲が異なります。
初期設定ではノードがランダムに選択されているように見えるかもしれませんが、ノードのラベル、グループ、割り当てルールなどを調整することで、各ジョブの実行場所をより適切に決定できます。そのため、Portainerのドキュメントを注意深く確認し、スケジューリングパターンを明確に理解できるまで、制御されたテストを実施することをお勧めします。
自宅でのPortainer: Raspberry Piなどのデバイスを制御するEdge Agent
Portainerを使用して家庭用デバイスやRaspberry Piのような小型ホストを管理する場合、アプローチは少し変わります。このような場合、Dockerホストは多くの場合、NATの背後、家庭用ネットワーク上にあり、直接のパブリックIPアドレスを持たないため、Docker APIや従来のエージェントをインターネットに公開するのは不便でリスクが高くなります。
このような状況において、多くのユーザーはRaspberry Piなどのデバイスを制御するために、Portainer Edge Agentを標準モードで使用しています。この方法であれば、TCP APIを有効にしたり、公開ソケットを開いたりするためにDockerの設定を変更する必要はありません。Edge Agentは、ポートフォワーディングの設定をすることなく、NATを介してサーバーへの接続を確立します。さらに、これらのデバイスは、 OpenMVなどのエッジアプリケーションを用いた組み込みビジョンプロジェクトで広く利用されています。
従来のPortainerエージェントでは、Portainerサーバーがエージェントに直接接続できる必要がありますが、CG-NATやISP提供のルーターを使用しているホームネットワークでは、必ずしもそれが可能とは限りません。さらに、ホームネットワーク外部からポートを開放する必要があるため、堅牢なセキュリティ対策が講じられていない場合は、セキュリティの観点から必ずしも推奨される方法ではありません。
一方、Edge Agentを使用する場合は、サーバー側でUIポート（および標準モードではトンネルポート）がインターネットまたはデバイスが配置されているネットワークからアクセス可能であることだけが必要です。Edge Agentが接続されると、Portainerのメインビュー（「ホーム」）で各デバイスが独立した環境として表示され、グループやタグを使用して、数十台のRaspberry Piやエッジデバイスを混乱することなく整理できます。
エッジ環境における非同期モードと標準モード
Portainer Edge Agentを選択する際に重要な決定事項の一つは、標準モードと非同期モードのどちらを使用するかです。標準モードでは、ホストが「ほぼローカル」であるかのように操作できます。コンテナ内でコンソールセッションを開いたり、ライブログを表示したり、スタックを対話的にデプロイしたりすることができます。
一方、非同期モードでは、双方向性を犠牲にして帯域幅の消費を最小限に抑え、不安定な接続にもより柔軟に対応できます。ステータスを時々確認したり、特定のジョブを起動したり、データを節約したい環境では、非同期モードが賢明な選択です。どちらの場合も、Portainerではグループやタグを使って環境を分類・管理できます。
オープンポートに関して言えば、標準モードではUIポートとトンネルポートの両方が必要ですが、非同期モードではUIポートのみが必要です。セキュリティを厳しく管理したい場合や、外部に露出する範囲を最小限に抑えたい場合は、非同期モードを使用するとセットアップが大幅に簡素化されますが、対話型のTLSトンネルは利用できなくなります。
エッジワークロード向けの Docker と WebAssembly (Wasm)
非常に限られたデバイス（小型ARMプロセッサ、RAM容量の少ないゲートウェイなど）上でのエッジコンピューティングの領域になると、従来のコンテナでさえもやや扱いにくくなることがあります。そこで登場するのがWebAssembly（Wasm）です。WasmEdgeやWasmtimeといったランタイムを通じて、既にDockerとネイティブに統合されています。
エッジコンピューティングにおけるWasmの利点は明らかです。バイナリサイズが非常に小さく、起動がほぼ瞬時で、機能ベースの分離が強力です。さらに、Wasmバイナリはオペレーティングシステム上ではなくランタイム上で動作するため、アーキテクチャ（x86、ARM、RISC-Vなど）間の移植性が非常に高いという利点もあります。
WasmをエッジのDockerで使用するには、以下のバージョンのDockerが必要です。 WasmランタイムサポートDocker Desktopバージョン4.15以降、またはcontainerd 1.7以降を搭載したDocker Engineでは通常動作します。 daemon.json containerd イメージストアを作成し、対応する Wasm ランタイムを宣言します (例: io.containerd.wasmedge.v1 o io.containerd.wasmtime.v1）を実行してから、Docker デーモンを再起動します。
典型的な例としては、 センサーデータ処理 Rustで書かれ、Wasmにコンパイルされる（ターゲット） wasm32-wasiこのプログラムは、JSON データを 1 行ずつ読み取り、特定の温度または湿度のしきい値を超える読み取り値をフィルタリングし、JSON でアラートを発行することができ、そのリソース消費量はすべて驚くほど少なくなります。
WebAssemblyにコンパイルしたら、 ミニマリスト、スクラッチベースの Dockerfileバイナリのみをコピーする .wasm ENTRYPOINTとして宣言します。 docker buildx プラットフォーム用 wasi/wasm そして、それをローカルにロードすると、簡単にギガバイトに達する Python または Node イメージと比較して、結果のサイズがわずか数メガバイトであることがわかります。
Docker と Compose を使用してエッジに Wasm をデプロイする
実際のエッジアーキテクチャでは、通常、デバイスごとに複数のサービスが存在します。例えば、 WASMのセンサープロセッサ、通信用のMQTTブローカー、時系列データベース、軽量リバースプロキシなどです。Docker Composeは、これらすべてを単一のファイルにまとめるのに最適です。
エッジノードの例としては、読み取り値を処理するWasmサービス（対応するWasmランタイムを使用）、センサーデータを受信するEclipse Mosquittoブローカー、時系列データを保存するTimescaleDB/PostgreSQLデータベース、APIやダッシュボードを公開するリバースプロキシとしてのCaddyなどが挙げられます。各サービスには、ポート、ボリューム、常時起動再起動ポリシーが設定されます。
配布を容易にするために、 Edge Gateway自体のローカルDocker登録通常はポート5000です。Wasmイメージをパッケージ化すると、ラベルは localhost:5000/... そして、それをレジストリにプッシュします。近くの他のエッジノードからは、そのローカルレジストリからプルできるため、リモートレジストリへのレイテンシとリソース消費を削減できます。
非常に限られたシステムでは、 Wasm自体が消費するリソースが少ないことは承知の上で、最大メモリ容量（例えば32MB）やCPUコア数（0.5コアなど）といった厳格なリソース制限を設定することをお勧めします。これにより、バグや負荷の急増によってデバイスがフリーズし、手動で再起動せざるを得なくなる事態を防ぐことができます。
ネットワーク、群集、そしてエッジにおける切断耐性
エッジにおけるネットワークは、データセンターに比べて信頼性が低いのが一般的です。頻繁な障害、IPアドレスの変更、モバイル回線の不安定さなどが挙げられます。そのため、各ノードに専用のブリッジネットワークを構築し、カスタムサブネットを設定したり、VPNやセキュアトンネルを介して接続された複数拠点からなるネットワーク群を構築したりすることがよく行われます。
Dockerを使用すると、ホスト上に独自のブリッジ名を持つ分離されたブリッジネットワークを作成できます（たとえば、 edge-br0）を作成し、そのネットワークにサービスを関連付けることで、他のトラフィックとの分離をさらに強化できます。さらに一歩進んで、エッジゲートウェイにDocker Swarmを設定すると、オーバーレイネットワークを使用して 複数のノード間でコンテナを接続する cluster-store および cluster-advertise メカニズム (通常は Consul または別のバックエンド上) を使用します。
Swarm を使用したマルチホスト環境においては、OpenNebulaを用いたいくつかのデプロイメント例が示すように、Docker Machine は依然として有用なツールです。この場合、docker-machine と OpenNebula ドライバーを使用して boot2docker で VM を起動し、検出用の Consul を設定し、Swarm マスターとノードを作成し、最後にオーバーレイネットワークですべてを接続することができます。
基本的な考え方はシンプルです。まず、Consul 用の VM を作成し、対応するコンテナをポート 8500 で起動して、その IP アドレスを取得します。次に、その IP アドレスを`docker-machine create` コマンドで `--swarm` および `--swarm-discovery` オプションとともに使用します。`cluster-store` と `cluster-advertise` を設定すると、オーバーレイ ネットワークを作成し、サービス名を使用して相互に通信できるサービス (たとえば、1 つのノードで Nginx を起動し、別のノードで BusyBox を起動するなど) を起動できます。
頻繁に接続が切断されるエッジ環境では、ボリュームやバインドマウントを使用してローカル永続性を有効にし、接続が失われた際にデータをディスクに保存することをお勧めします（データサイバーレジリエンス）。これにより、コンテナはデータ（センサーの読み取り値など）を蓄積し、接続が復旧した際に「ストアアンドフォワード」方式で一括送信することができます。
監視レベルでは、Dockerは次のような簡単なコマンドを提供します。 docker stats 基本的なCPU、メモリ、ネットワークトラフィックのメトリクスを取得するには、以下のエージェントを使用します。より本格的な導入では、次のような軽量エージェントを使用するのが一般的です。 ノードエクスポーター Prometheus とともに、「監視」用の別の docker-compose でも定義されており、ホスト メトリックを中央の可観測性エコシステムに公開します。
Dockerを使えば、エッジデプロイメントの更新も簡単になります。新しいイメージをプルし、古いコンテナを停止して削除し、新しいバージョンでサービスを再起動するだけです。さらに、Wasmコンテナは数ミリ秒で起動するため、ダウンタイムは最小限に抑えられます。これは、エッジでリアルタイムデータを収集する際に非常に役立ちます。
この概要を理解すれば、各要素がどのように連携しているかがより明確になります。Docker Swarmはオーケストレーションとオーバーレイネットワークを提供し、Portainer Edge Agentはリスクの高いポートを開放することなくリモート管理を簡素化し、Wasmは低スペックのハードウェア上でアプリケーションを実行するコストを削減します。ポート、ネットワーク、およびエージェントモード（標準または非同期）を適切に計画することで、日々の管理上の煩雑さを気にすることなく、複数の場所にまたがる堅牢な分散型エッジアーキテクチャを構築し、拡張性を確保できます。
