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

適用対象:IoT Edge 1.4 checkmark IoT Edge 1.4

重要

IoT Edge 1.4 がサポートされているリリースです。 以前のリリースの場合は、「IoT Edge を更新する」を参照してください。

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

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

デバイス単位のデプロイと自動デプロイを組み合わせることはできません。 自動デプロイを使って IoT Edge デバイスのターゲット設定を始めると (階層型デプロイの有無にかかわらず)、デバイス単位のデプロイはサポートされなくなります。

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

基本的なデプロイ手順は次のとおりです。

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

この記事では、デプロイの構成と監視に関係する各コンポーネントについて説明します。 デプロイの作成と更新に関するチュートリアルについては、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 に対する任意のブール条件を使います。 タグで条件を使う場合は、デバイス ツインのプロパティと同じレベルに "tags":{} セクションを追加する必要があります。 デバイス ツインのタグの詳細については、「IoT Hub のデバイス ツインの理解と使用」を参照してください。 クエリ操作の詳細については、IoT Hub クエリ言語演算子と IS_DEFINED 関数に関する記事を参照してください。

ターゲット条件の例:

  • 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'
  • IS_DEFINED(tags.remote)
  • NOT IS_DEFINED(tags.location.building)
  • tags.environment != null
  • [none]

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

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

Priority

優先順位では、デプロイをターゲット デバイスに適用する際、他のデプロイとの関係を考慮するかどうかを定義します。 デプロイの優先順位は、0 から 2,147,483,647 までの範囲内の正の整数です。 数字が大きくなるほど、優先度は高くなります。 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 つすべてのモジュールを使用できるわけではありません。 標準の自動デプロイの場合、その会社は、自社の建物に必要なすべてのモジュールの組み合わせに対して個別のデプロイを作成する必要があります。

Screenshot of showing that standard automatic deployments need to accommodate every module combination.

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

Screenshot that shows how layered automatic deployments simplify scenarios where the same modules are combined in different ways.

モジュール ツイン構成

多層デプロイを使用する場合、意図的かどうかにかかわらず、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 フィールドを設定した場合、properties.desired は優先順位の低いデプロイでそのモジュールの必要なプロパティを上書きします。

フェーズ ロールアウト

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

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

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

ロールバック

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

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

しかし、複数階デプロイの場合、そのデプロイを削除すると、ターゲットのデバイスからモジュールが削除される可能性があります。 複数層デプロイでは、基本となるデプロイが更新され、その際にモジュールが追加される可能性があります。 複数層デプロイを削除すると、基本となるデプロイへの更新が削除されるので、モジュールが削除される可能性があります。

たとえば、デバイスに基本デプロイ A があり、複数層デプロイ O および M が適用されているとします (つまりデプロイ A、O、M がこのデバイスにデプロイされています)。 複数層デプロイ M を削除すると、A と O がこのデバイスに適用され、デプロイ M に固有のモジュールは削除されます。

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

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

次のステップ