適用対象:
IoT Edge 1.5
重要
IoT Edge 1.5 LTS は、サポートされているリリースです。 IoT Edge 1.4 LTS は、2024 年 11 月 12 日をもってサポートが終了しています。 以前のリリースの場合は、「IoT Edge を更新する」を参照してください。
階層レイヤーに編成されたネットワーク間で Azure IoT Edge ノードをデプロイします。 階層内の各レイヤーは、その下のレイヤーにあるデバイスからのメッセージと要求を処理するゲートウェイ デバイスです。 この構成は、入れ子になったエッジとも呼ばれます。
最上位レイヤーのみがクラウドに接続できるようにデバイスの階層を構成し、下位レイヤーは隣接するアップストリームレイヤーとダウンストリーム レイヤーとのみ通信できるようにします。 このネットワーク レイヤー化は、ほとんどの産業用ネットワークの基礎であり、ISA-95 標準に準拠しています。
このチュートリアルでは、IoT Edge デバイスの階層を作成し、IoT Edge ランタイム コンテナーをデバイスにデプロイし、デバイスをローカルで構成する方法について説明します。 このチュートリアルでは、次のタスクを実行します。
- IoT Edge デバイスの階層でリレーションシップを作成して定義します。
- 階層内のデバイスで IoT Edge ランタイムを構成します。
- デバイス階層全体で一貫した証明書をインストールします。
- 階層内のデバイスにワークロードを追加します。
- IoT Edge API プロキシ モジュールを使用して、下位レイヤー デバイスから単一のポートを介して HTTP トラフィックを安全にルーティングします。
ヒント
このチュートリアルには、IoT Edge の入れ子機能を紹介する手動の手順と自動の手順が混在しています。
IoT Edge デバイスの階層が完全に自動的に設定されるようすを確認したい場合は、スクリプト化された産業用 IoT 向け Azure IoT Edge サンプルに従ってください。 このスクリプト化されたシナリオでは、工場環境をシミュレートするための構成済みのデバイスとして Azure 仮想マシンがデプロイされます。
IoT Edge デバイスの階層を手動で作成および管理する手順の詳細を確認したい場合は、IoT Edge デバイス ゲートウェイ階層の使用法ガイドを参照してください。
このチュートリアルでは、以下のネットワーク レイヤーを定義します。
最上位レイヤー: このレイヤーの IoT Edge デバイスは、クラウドに直接接続できます。
下位レイヤー: 最上位レイヤーより下にあるレイヤーの IoT Edge デバイスは、クラウドに直接接続できません。 データを送受信するには、1 つまたは複数の中間 IoT Edge デバイスを経由する必要があります。
このチュートリアルでは、わかりやすくするために 2 つのデバイスから成る階層を採用しています。 最上位レイヤー デバイスは、階層の最上位レイヤーにあるデバイスを表します。これは、クラウドに直接接続できます。 このデバイスは 親デバイスと呼ばれます。 下位レイヤー デバイスは、階層の下位レイヤーにあるデバイスを表します。これは、クラウドに直接接続できません。 必要に応じて、運用環境を表すデバイスを追加します。 下位レイヤーのデバイスは 、子デバイスと呼ばれます。
Note
子デバイスには、入れ子になったトポロジ内のダウンストリーム デバイスまたはゲートウェイ デバイスを使用できます。
前提条件
IoT Edge デバイスの階層を作成するには、以下のものが必要です。
インターネットに接続できるコンピューター (Windows または Linux)。
有効なサブスクリプションがある Azure アカウント。 Azure サブスクリプションをお持ちでない場合は、開始する前に無料アカウントを作成してください。
Azure の Free レベルまたは Standard レベルの IoT Hub。
Azure CLI を使用した Azure Cloud Shell の Bash シェル (Azure IoT 拡張機能がインストール済み)。 このチュートリアルでは、Azure Cloud Shell を使用します。 Azure CLI モジュールと拡張機能の現在のバージョンを確認するには、az version を実行します。
階層を構成する 2 つの Linux デバイス。 使用できるデバイスがない場合は、IoT Edge Azure Resource Manager テンプレートを使用して、階層内の各デバイスに Azure 仮想マシンを作成できます。 IoT Edge のバージョン 1.5 は、この Resource Manager テンプレートにプレインストールされています。 IoT Edge を自分のデバイスにインストールする場合は、Azure IoT Edge for Linux のインストールに関するページまたは IoT Edge の更新に関するページを参照してください。
デバイス間のネットワーク通信を簡略化するには、仮想マシンが同じ仮想ネットワーク上にあるか、仮想ネットワーク ピアリングを使用する必要があります。
最下位レイヤー デバイスを除くすべてのデバイスで、443、5671、8883 の各ポートが受信用に開放されていることを確認します。
- 443: REST API の呼び出しと Docker コンテナー イメージのプルのために、親と子のエッジ ハブの間で使用されます。
- 5671、8883: AMQP と MQTT に使用されます。
詳細については、「Azure portal を使用して仮想マシンへのポートを開く方法」を参照してください。
ヒント
各仮想マシンの SSH ハンドルと FQDN (または IP アドレス) は、この後の手順の構成で使用するため、この情報を記録しておいてください。 IP アドレスと FQDN は、Azure portal で確認できます。 IP アドレスについては、仮想マシンの一覧に移動し、[パブリック IP アドレス] フィールドに注目します。 FQDN については、各仮想マシンの概要ページに移動し、[DNS 名] フィールドを探します。 SSH ハンドルについては、各仮想マシンの 接続ページに移動します。
IoT Edge デバイス階層を作成する
IoT Edge デバイスにより、階層のレイヤーが構成されます。 このチュートリアルでは、2 つの IoT Edge デバイス (最上位レイヤー デバイスと下位レイヤー デバイス) の階層を作成します。 必要に応じて、さらにダウンストリーム デバイスを作成できます。
IoT Edge デバイスの階層を作成して構成するには、az iot edge devices create Azure CLI コマンドを使用します。 このコマンドでは、さまざまな手順を自動化してまとめることで、階層の構成を簡素化します。
- IoT Hub にデバイスを作成する
- デバイス間の通信を承認するための親子関係を設定する
- 配置マニフェストを各デバイスに適用する
- 各デバイスが相互に安全な通信を確立するための証明書チェーンを生成する
- 各デバイスの構成ファイルを生成する
デバイス構成を作成する
1 つの子デバイスを持つ親デバイスを含む入れ子になったエッジ デバイスのグループを作成します。 このチュートリアルでは、基本的なサンプル配置マニフェストを使用します。 その他のシナリオの例については、構成例テンプレートを確認してください。
az iot edge devices create コマンドを使用する前に、最上位レイヤーと下位レイヤーのデバイスの配置マニフェストを定義します。 deploymentTopLayer.json サンプル ファイルをローカル コンピューターにダウンロードします。
最上位レイヤー デバイスの配置マニフェストは、IoT Edge API プロキシ モジュールを定義し、下位レイヤー デバイスから IoT Hub へのルートを宣言します。
deploymentLowerLayer.json サンプル ファイルをローカル コンピューターにダウンロードします。
下位レイヤー デバイスの配置マニフェストには、シミュレートされた温度センサー モジュールが含まれており、最上位レイヤー デバイスへのルートを宣言します。 systemModules セクションでは、ランタイム モジュールは、mcr.microsoft.com ではなく $upstream:443 からプルするように設定されます。 下位レイヤー デバイスは、クラウドからイメージを直接プルできないため、ポート 443 の IoT Edge API プロキシ モジュールに Docker イメージ要求を送信します。 下位レイヤー デバイスにデプロイされたもう 1 つのモジュール、Simulated Temperature Sensor モジュールも、そのイメージ要求を
$upstream:443に対して行います。下位レイヤー配置マニフェストの作成の詳細については、「 Azure IoT Edge デバイスを接続して階層を作成する」を参照してください。
Azure Cloud Shell で、az iot edge devices create Azure CLI コマンドを使用して、IoT Hub 内のデバイスと階層内の各デバイスの構成バンドルを作成します。 山かっこ内のプレースホルダー テキストを実際の値に置き換えます。
プレースホルダー 説明 <ハブ名> IoT Hub の名前。 <config-bundle-output-path> 構成バンドルを保存するフォルダー パス。 <親デバイス名> 最上位レイヤーの親デバイス ID 名。 <親展開マニフェスト> 親デバイスの配置マニフェスト ファイル。 <親-FQDNまたはIP> 親デバイスの完全修飾ドメイン名 (FQDN) または IP アドレス。 <子デバイス名> 下位レイヤーの子デバイス ID 名。 <child-deployment-manifest> 子デバイスの配置マニフェスト ファイル。 <child-fqdn-or-ip> 子デバイスの完全修飾ドメイン名 (FQDN) または IP アドレス。 az iot edge devices create \ --hub-name <hub-name> \ --output-path <config-bundle-output-path> \ --default-edge-agent "mcr.microsoft.com/azureiotedge-agent:1.5" \ --device id=<parent-device-name> \ deployment=<parent-deployment-manifest> \ hostname=<parent-fqdn-or-ip> \ --device id=child-1 \ parent=parent-1 \ deployment=<child-deployment-manifest> \ hostname=<child-fqdn-or-ip>たとえば、次のコマンドは、IoT Hub に 2 つの IoT Edge デバイスの階層を作成します。 parent-1 という名前の最上位レイヤー デバイスと、child-1* という名前の下位レイヤー デバイス。 このコマンドは、output ディレクトリに各デバイスの構成バンドルを保存します。 コマンドでは、自己署名テスト証明書も生成され、構成バンドルに含まれます。 構成バンドルは、インストール スクリプトを使用して各デバイスにインストールされます。
az iot edge devices create \ --hub-name my-iot-hub \ --output-path ./output \ --default-edge-agent "mcr.microsoft.com/azureiotedge-agent:1.5" \ --device id=parent-1 \ deployment=./deploymentTopLayer.json \ hostname=10.0.0.4 \ --device id=child-1 \ parent=parent-1 \ deployment=./deploymentLowerLayer.json \ hostname=10.1.0.4
コマンドを実行した後、出力ディレクトリでデバイス構成バンドルを見つけます。 次に例を示します。
PS C:\nested-edge\output> dir
Directory: C:\nested-edge\output
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 4/10/2023 4:12 PM 7192 child-1.tgz
-a--- 4/10/2023 4:12 PM 6851 parent-1.tgz
コマンドに引数として渡された独自の証明書とキーを使用するか、より複雑なデバイス階層を作成します。 az コマンドを使用した入れ子になったデバイスの作成の詳細については、az iot edge devices create に関するページを参照してください。 ゲートウェイのシナリオにおける証明書の使い方に詳しくない場合は、使用法ガイドの証明書に関するセクションを参照してください。
このチュートリアルでは、インライン引数を使用して、デバイスと構成バンドルを作成します。 YAML 形式または JSON 形式の構成ファイルを使用することもできます。 サンプル構成ファイルについては、sample_devices_config.yaml の例を参照してください。
IoT Edge ランタイムを構成する
構成手順では、デバイスのプロビジョニングに加えて、前に作成した証明書を使用して、階層内のデバイス間に信頼された通信を確立します。 この手順では、階層のネットワーク構造の確立も開始します。 最上位レイヤー デバイスはインターネットに接続することができ、クラウドからランタイム用のイメージをプルできます。一方、下位レイヤー デバイスは、最上位レイヤー デバイス経由でルーティングされて、これらのイメージにアクセスします。
IoT Edge ランタイムを構成するには、構成バンドルをデバイスに適用します。 最上位レイヤー デバイスと下位レイヤー デバイスの構成は異なります。そのため、デバイスごとに適切な構成ファイルを使用してください。
各構成バンドル アーカイブ ファイルを対応するデバイスにコピーします。 USB ドライブを使用したり、Azure Key Vault などのサービスを使用したり、セキュア ファイル コピーなどの機能を使用したりできます。 シナリオに最も適したいずれかの方法を選択してください。
たとえば、 parent-1 構成バンドルを parent-1 VM 上のホーム ディレクトリに送信するには、次の例のようなコマンドを使用できます。
scp ./output/parent-1.tgz admin@parent-1-vm.westus.cloudapp.azure.com:~各デバイスで、構成バンドル アーカイブを抽出します。 たとえば、tar コマンドを使用して parent-1 アーカイブ ファイルを抽出します。
tar -xzf ./parent-1.tgzインストール スクリプトの実行アクセス許可を設定します。
chmod +x install.sh各デバイスで、ルート アクセス許可を持つインストール スクリプトを実行して、構成バンドルを適用します。
sudo ./install.sh
デバイスの構成ファイルに対する変更の詳細については、「 Azure IoT Edge デバイスを接続して階層を作成する」を参照してください。
デバイスが正しく構成されていることを確認するには、デバイスで構成と接続チェックを実行します。
sudo iotedge check
admin@child-1-vm:~$ sudo iotedge check
Configuration checks (aziot-identity-service)
---------------------------------------------
√ keyd configuration is well-formed - OK
√ certd configuration is well-formed - OK
√ tpmd configuration is well-formed - OK
√ identityd configuration is well-formed - OK
√ daemon configurations up-to-date with config.toml - OK
√ identityd config toml file specifies a valid hostname - OK
√ host time is close to reference time - OK
√ preloaded certificates are valid - OK
√ keyd is running - OK
√ certd is running - OK
√ identityd is running - OK
√ read all preloaded certificates from the Certificates Service - OK
√ read all preloaded key pairs from the Keys Service - OK
√ check all EST server URLs utilize HTTPS - OK
√ ensure all preloaded certificates match preloaded private keys with the same ID - OK
Connectivity checks (aziot-identity-service)
--------------------------------------------
√ host can connect to and perform TLS handshake with iothub AMQP port - OK
√ host can connect to and perform TLS handshake with iothub HTTPS / WebSockets port - OK
√ host can connect to and perform TLS handshake with iothub MQTT port - OK
Configuration checks
--------------------
√ aziot-edged configuration is well-formed - OK
√ configuration up-to-date with config.toml - OK
√ container engine is installed and functional - OK
√ configuration has correct parent_hostname - OK
√ configuration has correct URIs for daemon mgmt endpoint - OK
√ container time is close to host time - OK
‼ DNS server - Warning
Container engine is not configured with DNS server setting, which may impact connectivity to IoT Hub.
Please see https://aka.ms/iotedge-prod-checklist-dns for best practices.
You can ignore this warning if you are setting DNS server per module in the Edge deployment.
‼ production readiness: logs policy - Warning
Container engine is not configured to rotate module logs which may cause it run out of disk space.
Please see https://aka.ms/iotedge-prod-checklist-logs for best practices.
You can ignore this warning if you are setting log policy per module in the Edge deployment.
‼ production readiness: Edge Agent's storage directory is persisted on the host filesystem - Warning
The edgeAgent module is not configured to persist its /tmp/edgeAgent directory on the host filesystem.
Data might be lost if the module is deleted or updated.
Please see https://aka.ms/iotedge-storage-host for best practices.
‼ production readiness: Edge Hub's storage directory is persisted on the host filesystem - Warning
The edgeHub module is not configured to persist its /tmp/edgeHub directory on the host filesystem.
Data might be lost if the module is deleted or updated.
Please see https://aka.ms/iotedge-storage-host for best practices.
√ Agent image is valid and can be pulled from upstream - OK
√ proxy settings are consistent in aziot-edged, aziot-identityd, moby daemon and config.toml - OK
Connectivity checks
-------------------
√ container on the default network can connect to upstream AMQP port - OK
√ container on the default network can connect to upstream HTTPS / WebSockets port - OK
√ container on the IoT Edge module network can connect to upstream AMQP port - OK
√ container on the IoT Edge module network can connect to upstream HTTPS / WebSockets port - OK
30 check(s) succeeded.
4 check(s) raised warnings. Re-run with --verbose for more details.
2 check(s) were skipped due to errors from other checks. Re-run with --verbose for more details.
最上位レイヤー デバイスに、いくつかの合格チェックを含む出力が表示されます。 ログ ポリシーと、ネットワークによっては DNS ポリシーに関するいくつかの警告が表示される場合があります。
デバイス モジュールのデプロイ
デバイスのモジュールデプロイは、IoT Hub でデバイスを作成するときに適用されます。 az iot edge devices create コマンドは、上位層と下位層のデバイスのデプロイ JSON ファイルを適用します。 デプロイが完了すると、 下位レイヤー デバイス は IoT Edge API プロキシ モジュールを使用してそのイメージをプルします。
ランタイム モジュール IoT Edge エージェント と IoT Edge ハブに加えて、 最上位レイヤー デバイス は Docker レジストリ モジュールと IoT Edge API プロキシ モジュールも取得します。
Docker レジストリ モジュールは、既存の Azure Container Registry を参照します。 この場合、REGISTRY_PROXY_REMOTEURL の参照先は Microsoft Container Registry です。 既定では、 Docker レジストリ モジュールはポート 5000 でリッスンします。
IoT Edge API プロキシ モジュールは、HTTP 要求を他のモジュールにルーティングするため、下位レイヤー のデバイスはコンテナー イメージをプルしたり、BLOB をストレージにプッシュしたりできます。 このチュートリアルでは、ポート 443 で通信し、Docker コンテナー イメージのプル要求をポート 5000 の Docker レジストリ モジュールに送信するように構成されています。 Blob Storage のアップロード要求は、ポート 11002 の AzureBlobStorageonIoTEdge モジュールに送信されます。 IoT Edge API プロキシ モジュールとその構成方法の詳細については、モジュールの使用法ガイドを参照してください。
Azure portal または Azure Cloud Shell でこのようなデプロイを作成する方法については、 ハウツー ガイドの最上位レイヤー デバイスのセクションを参照してください。
次のコマンドを使用して、モジュールの状態を表示します。
az iot hub module-twin show --device-id <edge-device-id> --module-id '$edgeAgent' --hub-name <iot-hub-name> --query "properties.reported.[systemModules, modules]"
このコマンドは、edgeAgent で報告されたすべてのプロパティを表示します。 デバイスの状態を監視するための便利なプロパティには、 ランタイムの状態、 ランタイムの開始時刻、 ランタイムの最後の終了時刻、 ランタイムの再起動回数などがあります。
Azure portal でモジュールの状態を確認することもできます。 IoT Hub の [デバイス ] セクションに移動して、デバイスとモジュールを確認します。
生成されたデータを表示する
シミュレートされた温度センサー モジュールは、サンプル環境データを生成します。 送信されるメッセージには、周囲の温度と湿度、機械の温度と圧力、タイムスタンプが含まれます。
Azure Cloud Shell を使用してこれらのメッセージを表示することもできます。
az iot hub monitor-events -n <iot-hub-name> -d <lower-layer-device-name>
次に例を示します。
az iot hub monitor-events -n my-iot-hub -d child-1
{
"event": {
"origin": "child-1",
"module": "simulatedTemperatureSensor",
"interface": "",
"component": "",
"payload": "{\"machine\":{\"temperature\":104.29281270901808,\"pressure\":10.48905461241978},\"ambient\":{\"temperature\":21.086561171611102,\"humidity\":24},\"timeCreated\":\"2023-04-17T21:50:30.1082487Z\"}"
}
}
トラブルシューティング
iotedge check コマンドを実行して構成を確認し、エラーのトラブルシューティングを行います。
ダウンストリーム コンピューターが直接インターネット にアクセスできない場合でも、入れ子になった階層で iotedge check を実行します。
下位レイヤーから iotedge check を実行すると、プログラムは親からポート 443 を介してイメージをプルします。
azureiotedge-diagnostics値は、レジストリ モジュールにリンクされているコンテナー レジストリから取得されます。 このチュートリアルでは、既定で https://mcr.microsoft.com に設定されます。
| 名前 | 値 |
|---|---|
REGISTRY_PROXY_REMOTEURL |
https://mcr.microsoft.com |
プライベート コンテナー レジストリを使用している場合は、すべてのイメージ (IoTEdgeAPIProxy、edgeAgent、edgeHub、Simulated Temperature Sensor、診断) がコンテナー レジストリに存在することを確認します。
ダウンストリーム デバイスが親デバイスとは異なるプロセッサ アーキテクチャを使用している場合は、適切なアーキテクチャ イメージを使用します。 接続されているレジストリを使用するか、ダウンストリーム デバイス config.toml ファイル内の edgeAgent モジュールと edgeHub モジュールの正しいイメージを指定します。 たとえば、親デバイスが ARM32v7 で実行され、ダウンストリーム デバイスが AMD64 で実行されている場合は、ダウンストリーム デバイス config.toml ファイルで一致するバージョンとアーキテクチャ イメージ タグを指定します。
[agent.config]
image = "$upstream:443/azureiotedge-agent:1.5.0-linux-amd64"
"systemModules": {
"edgeAgent": {
"settings": {
"image": "$upstream:443/azureiotedge-agent:1.5.0-linux-amd64"
},
},
"edgeHub": {
"settings": {
"image": "$upstream:443/azureiotedge-hub:1.5.0-linux-amd64",
}
}
}
リソースをクリーンアップする
課金されないようにするために、ローカル構成と、この記事で作成した Azure リソースを削除できます。
リソースを削除するには、次の手順に従います。
Azure portal にサインインし、[リソース グループ] を選択します。
IoT Edge のテスト リソースを含んだリソース グループの名前を選択します。
リソース グループに含まれるリソースの一覧を確認します。 それらすべてを削除する場合は、[リソース グループの削除] を選択します。 一部だけを削除する場合は、削除する各リソースを選択して個別に削除してください。
次のステップ
このチュートリアルでは、2 つの IoT Edge デバイスをゲートウェイとして構成し、一方をもう一方の親デバイスとして設定しました。 次に、IoT Edge API プロキシ モジュールを使用して、ゲートウェイ経由でコンテナー イメージをダウンストリーム デバイスにプルしました。 詳細については、プロキシ モジュールの使用に関する使用法ガイドを参照してください。
ゲートウェイを使用して IoT Edge デバイスの階層レイヤーを作成する方法の詳細については、次の記事を参照してください。