1 台のデバイスまたは多数のデバイスを対象とした IoT Edge 自動デプロイについて

適用対象: [はい] アイコン IoT Edge 1.1 [はい] アイコン IoT Edge 1.2

自動デプロイと多層デプロイを使用すると、多数の IoT Edge デバイスでのモジュールの管理と構成が容易になります。

Azure IoT Edge には、IoT Edge デバイスで実行するようにモジュールを構成する方法が 2 つあります。 最初の方法では、デバイスごとにモジュールをデプロイします。 配置マニフェストを作成してから、それを特定のデバイスに名前で適用します。 2 つ目の方法では、定義された一連の条件を満たす登録済みデバイスにモジュールを自動的にデプロイします。 配置マニフェストを作成してから、デバイス ツインのタグに基づいて、適用対象のデバイスを定義します。

この記事では、多数のデバイスの構成と監視 (全体を指して IoT Edge の自動デプロイ と呼ばれます) に重点を置いて説明をします。  基本的なデプロイ手順は次のとおりです。

  1. オペレーターが、一連のモジュールとターゲット デバイスを指定したデプロイを定義します。  各デプロイには、この情報を反映した配置マニフェストが指定されます。
  2. IoT Hub サービスは、すべての対象デバイスと通信し、宣言されたモジュールを使用して構成します。
  3. IoT Hub サービスでは、IoT Edge デバイスからステータスを取得し、オペレーターが利用可能になるようにします。   たとえば、オペレーターは Edge デバイスが正常に構成されているかどうかや、実行時にモジュールでエラーが発生していないかかどうかを確認することができます。
  4. ターゲット条件を満たしている新しい IoT Edge デバイスは、随時デプロイ用に構成されます。

この記事では、デプロイの構成と監視に関係する各コンポーネントについて説明します。 デプロイの作成と更新に関するチュートリアルについては、IoT Edge モジュールの大規模なデプロイと監視に関するページを参照してください。

デプロイ

IoT Edge の自動デプロイでは、実行する IoT Edge モジュール イメージが、一連のターゲット IoT Edge デバイス上のインスタンスとして割り当てられます。 これは、IoT Edge 配置マニフェストを構成し、モジュールのリストと対応する初期化パラメーターを指定することで機能します。  デプロイは、1 つのデバイスに割り当てる (通常、デバイス ID に基づく) こともできますし、デバイスのグループに割り当てる (タグに基づく) こともできます。  IoT Edge デバイスは、配置マニフェストを取得すると各コンテナー レポジトリからコンテナー イメージをダウンロードしてインストールし、それらを適切に構成します。  デプロイが作成されたら、オペレーターはデプロイ ステータスを監視して、ターゲット デバイスが正しく構成されているかどうかを確認できます。

デプロイとともに構成を行えるのは、IoT Edge デバイスのみです。 デプロイを受け取るには、デバイスが以下の前提条件を満たしている必要があります。

  • ベース オペレーティング システム
  • Moby または Docker のようなコンテナー管理システム
  • IoT Edge ランタイムのプロビジョニング

配置マニフェスト

配置マニフェストは、ターゲットの IoT Edge デバイス上で構成されるモジュールを記述した、JSON ドキュメントです。 デプロイ マニフェストには、必要なシステム モジュール (具体的には、IoT Edge エージェントと IoT Edge ハブ) など、すべてのモジュールの構成メタデータが含まれます。

各モジュールの構成メタデータには、次のものが含まれます。

  • Version
  • Type
  • 状態 (実行中または停止など)
  • 再起動ポリシー
  • イメージおよびコンテナー レジストリ
  • データ入出力のルート

モジュール イメージがプライベート コンテナー レジストリに格納されている場合、IoT Edge エージェントはレジストリの資格情報を保持します。

ターゲット条件

ターゲット条件は、デプロイの有効期間を通じて継続的に評価されます。 要件を満たす新たなあらゆるデバイスが含まれ、要件を満たさない既存のあらゆるデバイスは削除されます。 サービスがターゲット条件の変化を検出した場合、デプロイが再アクティブ化されます。

たとえば、ターゲット条件が tags.environment = 'prod' であるデプロイがあるとします。 デプロイの開始時には、10 個の運用環境デバイスが存在します。 モジュールは、これら 10 個のデバイスに正常にインストールされます。 IoT Edge エージェントの状態には、合計デバイス数 10、正常応答数 10、異常応答数 0、保留中応答数 0 と表示されます。 次に、tags.environment = 'prod' を設定したデバイスを 5 個追加します。 サービスは変更を検出し、5 個の新しいデバイスをデプロイすると、IoT Edge エージェントの状態は、合計デバイス数 15、正常応答数 10、異常応答数 0、保留中応答数 5 と表示されます。

ターゲット デバイスを選ぶには、デバイス ツイン タグ、デバイス ツインの報告されるプロパティまたはデバイス ID に対する任意のブール条件を使います。 タグで条件を使う場合は、デバイス ツインのプロパティと同じレベルに "タグ":{} セクションを追加する必要があります。 デバイス ツインのタグに関する詳細

ターゲット条件の例:

  • deviceId ='linuxprod1'
  • tags.environment ='prod'
  • tags.environment = 'prod' AND tags.location = 'westus'
  • tags.environment = 'prod' OR tags.location = 'westus'
  • tags.operator = 'John' AND tags.environment = 'prod' AND NOT deviceId = 'linuxprod1'
  • properties.reported.devicemodel = '4000x'

ターゲット条件を作成するときは、次のような制約を検討します。

  • デバイス ツインでは、ターゲット条件を作成するときに使うことができるのはタグ、報告されるプロパティ、またはデバイス ID だけです。
  • ターゲット条件のどの部分でも、二重引用符を使うことはできません。 単一引用符を使ってください。
  • 単一引用符は、ターゲット条件の値を表します。 そのため、デバイス名に単一引用符が含まれる場合は、別の単一引用符でエスケープする必要があります。 たとえば、operator'sDevice というデバイスをターゲットとするには、deviceId='operator''sDevice' と書き込みます。
  • ターゲット条件の値 -:.+%_#*?!(),=@;$ には、数字、文字、および 次の文字を使用することができます。

Priority

優先順位では、デプロイをターゲット デバイスに適用する際、他のデプロイとの関係を考慮するかどうかを定義します。 デプロイ優先順位は正の整数で指定され、数が大きいほど優先順位が高いことを示します。 IoT Edge デバイスが複数のデプロイのターゲットになっている場合は、優先順位の最も高いデプロイが適用されます。   優先順位の低いデプロイは適用されず、マージもされません。   デバイスが複数のデプロイのターゲットになっていて、それらの優先順位が同じである場合は、直近に作成されたデプロイが適用されます (作成日時のタイムスタンプによって決定されます)。

ラベル

ラベルは、デプロイをフィルター処理してグループ化するために使用できる、文字列のキー/値ペアです。  デプロイには複数のラベルを指定することもできます。 ラベルは省略可能であり、IoT Edge デバイスの実際の構成には影響しません。

メトリック

既定では、すべてのデプロイで次の 4 つのメトリックについて報告されます。

  • ターゲット: デプロイのターゲット条件に一致している IoT Edge デバイスを示します。
  • 適用: より優先順位の高い別のデプロイのターゲットになっていないターゲット IoT Edge デバイスを示します。
  • 成功の報告: モジュールが正常にデプロイされたことを報告した IoT Edge デバイスを示します。
  • 失敗の報告: 1 つ以上のモジュールが正常にデプロイされなかったことを報告した IoT Edge デバイスを示します。 エラーについて詳しく調べるには、それらのデバイスにリモートで接続し、ログ ファイルを参照します。

また、独自のカスタム メトリックを定義して、デプロイの監視と管理に役立てることもできます。

メトリックは、デプロイの構成を適用した結果としてデバイスから報告される、各種の状態の集計カウントを示すものです。 メトリックでは、lastDesiredStatuslastConnectTime など、edgeHub モジュール ツインの報告されるプロパティを照会できます。 次に例を示します。

SELECT deviceId FROM devices
  WHERE properties.reported.lastDesiredStatus.code = 200

独自のメトリックの追加は省略可能であり、IoT Edge デバイスの実際の構成には影響しません。

多層デプロイ

多層デプロイは、組み合わせることで、作成する必要がある一意のデプロイの数を減らすことができる自動デプロイです。 多層デプロイは、多くの自動デプロイで同じモジュールを異なる組み合わせで再利用するシナリオで役立ちます。

多層デプロイには、自動デプロイと同じ基本コンポーネントが含まれています。 これらは、デバイス ツインのタグに基づいてデバイスをターゲットに設定し、ラベル、メトリック、および状態レポートに関して同じ機能を提供します。 多層デプロイにも優先順位が割り当てられますが、優先順位を使用してどのデプロイをデバイスに適用するかを決定するのではなく、優先順位によって、1 つのデバイスに対する複数のデプロイのランク付けが決定されます。 たとえば、2 つの多層デプロイに同じ名前のモジュールまたはルートがある場合、優先順位の高い多層デプロイが適用され、優先順位の低いものは上書きされます。

システムのランタイム モジュールである edgeAgent と edgeHub は、多層デプロイの一部として構成されません。 多層デプロイのターゲットとなる任意の IoT Edge デバイスでは、最初に標準の自動デプロイを適用する必要があります。 自動デプロイでは、多層デプロイを追加できるベースが提供されます。

IoT Edge デバイスで適用できる標準の自動デプロイは 1 つだけですが、多層の自動デプロイは複数適用できます。 デバイスをターゲットとする多層デプロイには、そのデバイスに対する自動デプロイより高い優先順位が設定されている必要があります。

たとえば、建物を管理する会社の次のようなシナリオを考えてみます。 そこでは、セキュリティ カメラ、モーション センサー、およびエレベーターからデータを収集する IoT Edge モジュールが開発されました。 ただし、すべての建物で 3 つすべてのモジュールを使用できるわけではありません。 標準の自動デプロイの場合、その会社は、自社の建物に必要なすべてのモジュールの組み合わせに対して個別のデプロイを作成する必要があります。

標準の自動デプロイでは、すべてのモジュールの組み合わせに対応する必要があります

しかしその会社は、多層の自動デプロイに切り替えると、管理対象のデプロイを減らして、自社の建物用に同じモジュールの組み合わせを作成できることが判明します。 各モジュールには独自の多層デプロイがあり、デバイス タグによって、各建物に追加されるモジュールが識別されます。

多層の自動デプロイでは、同じモジュールがさまざまな方法で組み合わされるシナリオが単純化されます

モジュール ツイン構成

多層デプロイを使用する場合、意図的かどうかにかかわらず、2 つのデプロイで、1 つのデバイスをターゲットとした同じモジュールが使用されることがあります。 このような場合、そのモジュール ツインに対して、優先順位の高いデプロイで上書きを行うか、それを追加するかを決定できます。 たとえば、同じモジュールを 100 台の異なるデバイスに適用するデプロイがあるとします。 ただし、これらのデバイスのうち 10 台はセキュリティで保護された施設にあり、プロキシ サーバー経由で通信するために追加の構成が必要です。 多層デプロイを使用すると、基本デプロイの既存のモジュール ツイン情報を上書きすることなく、これらの 10 台のデバイスが安全に通信できるようにするモジュール ツイン プロパティを追加できます。

配置マニフェストにモジュール ツインの必要なプロパティを追加できます。 標準のデプロイでは、プロパティをモジュール ツインの properties.desired セクションに追加しますが、多層デプロイでは、必要なプロパティの新しいサブセットを宣言できます。

たとえば、標準デプロイで、シミュレートされた温度センサー モジュールを、5 秒間隔でデータを送信するように指示する次の必要なプロパティとともに追加するとします。

"SimulatedTemperatureSensor": {
  "properties.desired": {
    "SendData": true,
    "SendInterval": 5
  }
}

同じデバイスの一部または全部をターゲットとする多層デプロイで、1000 件のメッセージを送信してから停止するように、シミュレートされたセンサーに指示するプロパティを追加できます。 既存のプロパティを上書きしたくないため、新しいプロパティを含む layeredProperties という必要なプロパティの中に新しいセクションを作成します。

"SimulatedTemperatureSensor": {
  "properties.desired.layeredProperties": {
    "StopAfterCount": 1000
  }
}

両方のデプロイが適用されたデバイスでは、シミュレートされた温度センサーのモジュール ツインに次のプロパティが反映されます。

"properties": {
  "desired": {
    "SendData": true,
    "SendInterval": 5,
    "layeredProperties": {
      "StopAfterCount": 1000
    }
  }
}

多層デプロイでモジュール ツインの properties.desired フィールドを設定した場合、優先順位の低いデプロイでそのモジュールの必要なプロパティが上書きされます。

フェーズ ロールアウト

フェーズ ロールアウトとは、IoT Edge デバイスの幅広いセットに対してオペレーターが変更をデプロイする、全体的なプロセスのことです。 その目的は、変更を段階的に適用することで、広範囲な変更によるリスクを減らすことです。 自動デプロイは、IoT Edge デバイス グループ全体でフェーズ ロールアウトを管理するのに役立ちます。

フェーズ ロールアウトは、次のフェーズと手順に従って実行されます。

  1. IoT Edge デバイスをプロビジョニングし、tag.environment='test' などのデバイス ツイン タグを設定することで、IoT Edge デバイスのテスト環境を作成します。  テスト環境では、実際にデプロイのターゲットとなる本番環境を厳密に再現する必要があります。
  2. デプロイを作成します (目的のモジュールや構成など)。 ターゲット条件では、IoT Edge デバイスのテスト環境をターゲットにする必要があります。
  3. テスト環境で新しいモジュール構成を検証します。
  4. ターゲット条件に新しいタグを追加してデプロイを更新し、本番用の IoT Edge デバイスのサブセットを含めます。 また、デプロイの優先順位が、現在それらのデバイスをターゲットにしている他のデプロイよりも高いことを確認します
  5. デプロイ ステータスを参照して、ターゲット IoT デバイスについてデプロイが成功したことを確認します。
  6. デプロイを更新して、残っているすべての本番用 IoT Edge デバイスをターゲットにします。

ロールバック

エラーや構成ミスを受け取った場合、デプロイをロールバックすることができます。  デプロイでは IoT Edge デバイスの固定的なモジュール構成が定義されるため、追加のデプロイでも、同じデバイスをより低い優先順位でターゲットにする必要があります。このことは、目的が全モジュールの削除である場合も同様です。

デプロイを削除しても、ターゲットのデバイスからモジュールは削除されません。 デバイスの新しい構成を定義する別のデプロイが必要であり、それが空のデプロイであっても同様です。

ロールバックは次の順序で実行します。

  1. 2 番目のデプロイでも同じデバイスセットがターゲットになっていることを確認します。 ロールバックの目的が全モジュールの削除である場合、2 番目のデプロイにはモジュールを含めません。
  2. ロールバックするデプロイのターゲット条件式を変更または削除して、デバイスがターゲット条件に一致しなくなるようにします。
  3. デプロイ ステータスを参照して、ロールバックが成功したことを確認します。
    • ロールバックされたデプロイでは、ロールバックされたデバイスのステータスが表示されなくなります。
    • 2 番目のデプロイに、ロールバックされたデバイスのデプロイ ステータスが表示されるようになります。

次のステップ