IoT Edge ソリューションを運用環境にデプロイするための準備を行う

適用対象: IoT Edge 1.5 IoT Edge 1.4

重要

サポートされているリリースは、IoT Edge 1.5 LTS と IoT Edge 1.4 LTS です。 IoT Edge 1.4 LTS は、2024 年 11 月 12 日にサポートが終了します。 以前のリリースの場合は、「IoT Edge を更新する」を参照してください。

IoT Edge ソリューションを開発環境から運用環境に移行する準備ができたら、それが継続的なパフォーマンスのために構成されていることを確認します。

この記事で提供される情報はすべて同等であるとは限りません。 優先順位を付けやすくするために、各セクションの始めに、作業を重要 (運用環境に移行する前に完了すること) および有用 (知っておくと便利なこと) という 2 つのセクションに分けたリストが示されています。

デバイス構成

IoT Edge デバイスとして、Raspberry Pi から、ノート PC、サーバー上で実行されている仮想マシンまで、任意のものを指定できます。 デバイスには物理的に、または仮想接続を介してアクセスできる場合があります。また、デバイスは長時間分離される場合もあります。 いずれにせよ、適切に動作するように構成されていることを確認する必要があります。

• 重要

  • 運用環境の証明書をインストールする
  • デバイスの管理を計画する
  • コンテナー エンジンとして Moby を使用する。 Ubuntu Core スナップを使用している場合、Docker スナップは Canonical によって処理され、運用シナリオでサポートされます。

• 有用

  • アップストリーム プロトコルを選ぶ

運用環境の証明書をインストールする

運用環境内のすべての IoT Edge デバイスには、デバイス証明機関 (CA) の証明書をインストールする必要があります。 その CA 証明書は、その後、config ファイルの IoT Edge ランタイムに宣言されます。 開発とテストのシナリオ用に、IoT Edge ランタイムでは、config ファイルで証明書が宣言されていない場合に一時証明書が作成されます。 しかし、これらの一時証明書は 3 か月後に有効期限が切れるため、運用環境シナリオでは安全ではありません。 運用環境のシナリオでは、自己署名の証明機関、または商用認証局から購入した自分独自の Edge CA 証明書を指定する必要があります。

Edge CA 証明書のロールの詳細については、Azure IoT Edge での証明書の使用方法に関するページを参照してください。

IoT Edge デバイスに証明書をインストールし、config ファイルからそれらを参照する方法の詳細については、「IoT Edge デバイスで証明書を管理する」を参照してください。

デバイスの管理を計画する

運用環境に任意のデバイスを配置する前に、今後の更新をどのように管理するかを知っておく必要があります。 IoT Edge デバイスでは、更新するコンポーネントのリストに以下のものが含まれる可能性があります。

• デバイス ファームウェア
• オペレーティング システム ライブラリ
• コンテナー エンジン (Moby など)
• IoT Edge
• CA 証明書

Device Update for IoT Hub は、IoT Edge デバイスの無線での (OTA) 更新をデプロイできるようにするサービスです。

IoT Edge を更新するための別の方法では、IoT Edge デバイスへの物理的アクセスまたは SSH アクセスが必要になります。 詳細については、IoT Edge ランタイムの更新に関する記事を参照してください。 複数のデバイスを更新するには、スクリプトに更新手順を追加することを検討するか、Ansible などの自動化ツールを使用します。

コンテナー エンジン

コンテナー エンジンは、すべての IoT Edge デバイスの前提条件となります。 運用環境では moby-engine がサポートされます。 Ubuntu Core スナップを使用している場合、Docker スナップは Canonical によって処理され、運用シナリオでサポートされます。 Docker などのその他のコンテナー エンジンは IoT Edge で動作します。開発用にこれらのエンジンを使用してもかまいません。 Azure IoT Edge で使用する場合は moby-engine を再配布でき、Microsoft ではこのエンジンのサービスを提供しています。

アップストリーム プロトコルを選ぶ

(使用するポートが決定される) IoT Hub へのアップストリーム通信用のプロトコルを、IoT Edge エージェントと IoT Edge ハブの両方に対して構成することができます。 既定のプロトコルは AMQP ですが、ネットワーク設定に応じてそれを変更できます。

2 つのランタイム モジュールの両方に UpstreamProtocol 環境変数があります。 変数の有効な値は次のとおりです。

• MQTT
• AMQP
• MQTTWS
• AMQPWS

デバイス自体の config ファイルで、IoT Edge エージェント用に UpstreamProtocol 変数を構成します。 たとえば、IoT Edge デバイスが、AMQP ポートをブロックするプロキシ サーバーの背後にある場合、IoT Hub への初期接続を確立するために WebSocket (AMQPWS) 経由で AMQP を使用するように IoT Edge エージェントを構成する必要があることがあります。

IoT Edge デバイスが接続されたら、必ず、以降のデプロイでも引き続き両方のランタイム モジュールに対して UpstreamProtocol 変数を構成してください。 このプロセスの例については、「IoT Edge デバイスを構成してプロキシ サーバー経由で通信する」を参照してください。

展開

• 有用
  • アップストリーム プロトコルに合わせる
  • システム モジュール用にホスト ストレージを設定する
  • IoT Edge ハブで使用されるメモリ領域を減らす
  • デプロイ マニフェストで正しいモジュール イメージを使用する
  • カスタム モジュールを使用する場合はツイン サイズの制限に注意する
  • モジュールへの更新プログラムの適用方法を構成する

アップストリーム プロトコルに合わせる

既定の AMQP とは異なるプロトコルを使用するように IoT Edge デバイス上の IoT Edge エージェントを構成した場合は、今後のすべてのデプロイで同じプロトコルを宣言する必要があります。 たとえば、IoT Edge デバイスが、AMQP ポートをブロックするプロキシ サーバーの背後にある場合、WebSocket (AMQPWS) 経由の AMQP で接続するようにデバイスを構成したと考えられます。 デバイスにモジュールをデプロイするときは、IoT Edge エージェントと IoT Edge ハブに対して同じ AMQPWS プロトコルを構成します。そうしない場合、既定の AMQP で設定がオーバーライドされ、再度接続することはできません。

IoT Edge エージェントおよび IoT Edge ハブ モジュールには、UpstreamProtocol 環境変数のみを構成する必要があります。 追加モジュールではすべて、ランタイム モジュールに設定されている任意のプロトコルが採用されます。

このプロセスの例については、「IoT Edge デバイスを構成してプロキシ サーバー経由で通信する」を参照してください。

システム モジュール用にホスト ストレージを設定する

IoT Edge ハブおよびエージェント モジュールでは、ローカル ストレージの使用により状態が維持され、モジュール、デバイス、およびクラウド間のメッセージングが有効となります。 信頼性とパフォーマンスを向上させるために、ホスト ファイルシステム上のストレージを使用するようにシステム モジュールを構成します。

詳細については、「システム モジュール用のホスト ストレージ」を参照してください。

IoT Edge ハブで使用されるメモリ領域を減らす

使用可能なメモリが限られている制約付きデバイスをデプロイする場合は、より効率的な容量で実行し、より少ないディスク領域を使用するように IoT Edge ハブを構成できます。 しかし、これらの構成では IoT Edge ハブのパフォーマンスが制限されるため、ソリューションに適したバランスを見つけてください。

制限付きデバイスのパフォーマンスを最適化しない

IoT Edge ハブは既定でパフォーマンスが最適化されているため、大きなメモリ チャンクの割り当てが試行されます。 この構成によって、Raspberry Pi などのより小さなデバイスで安定性の問題が発生する場合があります。 リソースに制約があるデバイスをデプロイする場合は、IoT Edge ハブで OptimizeForPerformance 環境変数を false に設定することができます。

OptimizeForPerformance が true に設定されている場合、MQTT プロトコル ヘッドで PooledByteBufferAllocator が使用されます。この場合、パフォーマンスは向上しますが、より多くのメモリが割り当てられます。 アロケーターは、32 ビット オペレーティング システムまたはメモリが不足しているデバイスでは適切に機能しません。 また、パフォーマンスを最適化する場合、RocksDb は、そのローカル ストレージ プロバイダーとしての役割に、より多くのメモリを割り当てます。

詳細については、「小型のデバイスでの安定性の問題」を参照してください。

未使用のプロトコルを無効にする

IoT Edge ハブのパフォーマンスを最適化し、そのメモリ使用量を減らす別の方法は、ソリューションで使用していないすべてのプロトコルのプロトコル ヘッドを無効にすることです。

プロトコル ヘッドは、デプロイ マニフェストで IoT Edge ハブ モジュールに対してブール型の環境変数を設定することで構成されます。 変数には以下の 3 つがあります。

• amqpSettings__enabled
• mqttSettings__enabled
• httpSettings__enabled

3 つの変数にはすべて 2 つのアンダースコア があり、true または false に設定できます。

メッセージのストレージ時間を短縮する

何らかの理由でメッセージを IoT Hub に配信できない場合、そのメッセージは一時的に IoT Edge ハブ モジュールに格納されます。 配信されなかったメッセージの有効期限が切れるまで IoT Edge ハブで保持する期間を構成することができます。 デバイス上のメモリが心配な場合は、IoT Edge ハブ モジュール ツインで timeToLiveSecs の値を下げることができます。

timeToLiveSecs パラメーターの既定値は 7,200 秒 (2 時間) です。

デプロイ マニフェストで正しいモジュール イメージを使用する

空のモジュール イメージか正しくないモジュール イメージが使用されている場合、Edge エージェントではイメージの読み込みが再試行され、余計なトラフィックが生成されます。 不要なトラフィック生成を避けるため、配置マニフェストには正しいイメージを追加してください。

デバッグ バージョンのモジュール イメージを使用しない

テスト シナリオから運用環境シナリオに移行する場合は、必ず、デプロイ マニフェストからデバッグ構成を削除してください。 デプロイ マニフェストのモジュール イメージのいずれにも .debug サフィックスがないことを確認します。 デバッグ用のモジュールでポートを公開するための作成オプションを追加した場合は、その作成オプションも削除します。

カスタム モジュールを使用する場合はツイン サイズの制限に注意する

カスタム モジュールを含む配置マニフェストは、EdgeAgent ツインの一部です。 モジュール ツインのサイズに関する制限を確認します。

多数のモジュールを配置する場合、このツイン サイズの制限を使い果たす可能性があります。 このハード制限に対する次の一般的な軽減策を検討してください。

• 独自の制限があるカスタム モジュール ツインに構成を保存する。
• スペース制限のない場所 (つまり BLOB ストア) をポイントするいくつかの構成を保存する。

モジュールへの更新プログラムの適用方法を構成する

デプロイが更新されると、Edge エージェントはツインの更新として新しい構成を受け取ります。 新しい構成に新規または更新されたモジュール イメージがある場合、既定では、Edge エージェントは次のように各モジュールを順番に処理します。

1. 更新されたイメージがダウンロードされます
2. 実行中のモジュールが停止されます
3. 新しいモジュール インスタンスが開始されます
4. 次のモジュールの更新が処理されます

たとえば、モジュール間に依存関係が存在する場合は、実行中のモジュールを再起動する前に、更新されたすべてのモジュール イメージを最初にダウンロードすることが望ましい場合があります。 このモジュールの更新動作は、IoT Edge エージェントの環境変数 ModuleUpdateMode を文字列値 WaitForAllPulls に設定することで構成できます。 詳細については、IoT Edge の環境変数に関する記事を参照してください。

"modulesContent": {
    "$edgeAgent": {
        "properties.desired": {
            ...
            "systemModules": {
                "edgeAgent": {
                    "env": {
                        "ModuleUpdateMode": {
                            "value": "WaitForAllPulls"
                        }
                    ...

コンテナー管理

• 重要
  • タグを使用してバージョンを管理する
  • ボリュームを管理する
• 有用
  • プライベート レジストリにランタイム コンテナーを格納する
  • イメージ ガベージ コレクションを構成する

タグを使用してバージョンを管理する

タグは、Docker コンテナーのバージョンを区別するために使用できる Docker 概念です。 タグは、コンテナー リポジトリの末尾に付加される 1.5 などのサフィックスです。 たとえば、mcr.microsoft.com/azureiotedge-agent:1.5 のようになります。 タグは可変であり、別のコンテナーを指すようにいつでも変更できます。したがって、チームは、今後モジュール イメージを更新する際に従う規則に同意する必要があります。

また、タグは、IoT Edge デバイスに更新プログラムを適用するのに役立ちます。 更新バージョンのモジュールをコンテナー レジストリにプッシュするときに、タグを増分します。 次に、増分されたタグでデバイスに新しいデプロイをプッシュします。 コンテナー エンジンでは、増分されたタグが新しいバージョンとして認識され、最新バージョンのモジュールがご利用のデバイスにプルダウンされます。

IoT Edge ランタイムのタグ

IoT Edge エージェントおよび IoT Edge ハブ イメージには、関連付けられている IoT Edge のバージョンでタグ付けされます。 ランタイム イメージでタグを使用する方法は 2 つあります。

• ローリング タグ - バージョン番号の先頭の 2 つの値のみを使用して、これらの数字に一致する最新のイメージを取得します。 たとえば、最新の 1.5.x バージョンを指す新しいリリースが存在するたびに、1.5 が更新されます。 IoT Edge デバイス上のコンテナー ランタイムによって、再度イメージが取得されると、ランタイム モジュールが最新バージョンに更新されます。 Azure portal からのデプロイでは、既定でローリング タグに設定されます。 開発目的では、このアプローチが推奨されます。

• 特定のタグ - バージョン番号の 3 つすべての値を使用して、イメージのバージョンを明示的に設定します。 たとえば、1.5.0 はその最初のリリース後に変更されることはありません。 更新する準備ができたら、配置マニフェストに新しいバージョン番号を宣言できます。 運用環境目的では、このアプローチが推奨されます。

ボリュームを管理する

IoT Edge では、モジュール コンテナーにアタッチされているボリュームは削除されません。 これは、アップグレード シナリオなど、コンテナー インスタンス間でデータを保持できるようにするための仕様上の動作です。 ただし、これらのボリュームが未使用のまま放置されるとディスク領域が不足し、それに伴うシステム エラーが発生する可能性があります。 シナリオで docker ボリュームを使う場合、特に運用環境のシナリオでは、docker volume prune や docker volume rm などの docker ツールを使って、未使用ボリュームを削除することをお勧めします。

プライベート レジストリにランタイム コンテナーを格納する

カスタム コード モジュールのコンテナー イメージをプライベート Azure レジストリに格納する方法は知られていますが、これを使用して、edgeAgent や edgeHub ランタイム モジュールなどのパブリック コンテナー イメージを格納することもできます。 このような処理が必要になるのは、これらのランタイム コンテナーが Microsoft Container Registry (MCR) に格納されているため、ファイアウォールの制限が厳しい場合です。

次の手順は、edgeAgent と edgeHub の Docker イメージをローカル コンピューターにプルし、タグを付け直し、プライベート レジストリにプッシュした後、イメージをプライベート レジストリからプルすることがデバイスで認識されるように構成ファイルを更新する方法を示します。

1. Microsoft レジストリから edgeAgent Docker イメージをプルします。 必要に応じて、バージョン番号を更新します。

   # Pull edgeAgent image
   docker pull mcr.microsoft.com/azureiotedge-agent:1.5
   
   # Pull edgeHub image
   docker pull mcr.microsoft.com/azureiotedge-hub:1.5
   

2. すべての Docker イメージを一覧表示し、edgeAgent および edgeHub のイメージを見つけて、それらのイメージ ID をコピーします。

   docker images
   

3. edgeAgent および edgeHub のイメージのタグを付け直します。 角かっこ内の値を実際の値に置き換えます。

   # Retag your edgeAgent image
   docker tag <my-image-id> <registry-name/server>/azureiotedge-agent:1.5
   
   # Retag your edgeHub image
   docker tag <my-image-id> <registry-name/server>/azureiotedge-hub:1.5
   

4. edgeAgent および edgeHub のイメージをプライベート レジストリにプッシュします。 角かっこ内の値を実際の値に置き換えます。

   # Push your edgeAgent image to your private registry
   docker push <registry-name/server>/azureiotedge-agent:1.5
   
   # Push your edgeHub image to your private registry
   docker push <registry-name/server>/azureiotedge-hub:1.5
   

5. mcr.microsoft.com を edgeAgent および edgeHub システム モジュールの実際の "レジストリ名またはサーバー" に置き換えて、両方のモジュールの deployment.template.json ファイル内のイメージ参照を更新します。

6. IoT Edge デバイスでテキスト エディターを開いて、プライベート レジストリ イメージがデバイスで認識されるように構成ファイルを変更します。

   sudo nano /etc/aziot/config.toml
   

7. テキスト エディターで、[agent.config] の下にあるイメージの値を変更します。 角かっこ内の値を実際の値に置き換えます。

   [agent.config]
   image = "<registry-name/server>/azureiotedge-agent:1.5"
   

8. プライベート レジストリで認証が必要な場合、[agent.config.auth] で認証パラメーターを設定します。

   [agent.config.auth]
   serveraddress = "<login-server>" # Almost always equivalent to <registry-name/server>
   username = "<username>"
   password = "<password>"
   

9. 変更を保存し、テキスト エディターを終了します。

10. IoT Edge 構成の変更を適用します。

    sudo iotedge config apply
    

    IoT Edge ランタイムを再起動します。

詳細については、以下を参照してください:

• IoT Edge エージェントを構成する
• Azure IoT Edge エージェント
• Azure IoT Edge ハブ

イメージ ガベージ コレクションを構成する

イメージ ガベージ コレクションは、IoT Edge v1.4 以降の機能であり、IoT Edge モジュールで使用されなくなった Docker イメージを自動的にクリーンアップします。 デプロイの一部として IoT Edge ランタイムによってプルされた Docker イメージのみが削除されます。 未使用の Docker イメージを削除することで、ディスク領域を節約できます。

この機能は、IoT Edge のホスト コンポーネントである aziot-edged サービスに実装されており、既定で有効になっています。 クリーンアップは毎日午前 0 時 (デバイスのローカル時刻) に行われ、7 日前に最後に使用された未使用の Docker イメージが削除されます。 クリーンアップ動作を制御するパラメーターは config.toml に設定します (このセクションの後半で説明します)。 構成ファイルでパラメーターが指定されていない場合は、既定値が適用されます。

たとえば、既定値を使用した config.toml イメージ ガベージ コレクション セクションを次に示します。

[image_garbage_collection]
enabled = true
cleanup_recurrence = "1d"
image_age_cleanup_threshold = "7d" 
cleanup_time = "00:00"

次の表は、イメージ ガベージ コレクションのパラメーターを説明するものです。 すべてのパラメーターは省略可能であり、個別に設定して既定の設定を変更することができます。

パラメーター	Description	必須	規定値
enabled	イメージ ガベージ コレクションを有効にします。 この設定を false に変更して、機能を無効にすることもできます。	省略可能	true
cleanup_recurrence	クリーンアップ タスクの繰り返し頻度を制御します。 日数として指定する必要があり、1 日未満にすることはできません。 たとえば、1d、2d、6d などです。	省略可能	1d
image_age_cleanup_threshold	クリーンアップを検討する前に未使用のイメージの最小期間のしきい値を定義し、日数で指定する必要があります。 0d と指定すると、デプロイから削除されると同時にイメージがクリーンアップされます。 イメージは、デプロイから削除された後、未使用と見なされます。	省略可能	7d
cleanup_time	クリーンアップ タスクが実行される時刻 (デバイスのローカル時刻)。 24 時間 HH:MM 形式である必要があります。	省略可能	00:00

ネットワーク

• 有用
  • アウトバウンド/インバウンド構成を確認する
  • IoT Edge デバイスからの接続を許可する
  • プロキシを介した通信を構成する
  • コンテナー エンジンの設定で DNS サーバーを設定します

アウトバウンド/インバウンド構成を確認する

Azure IoT Hub および IoT Edge の間の通信チャネルは、常にアウトバウンドに構成されます。 ほとんどの IoT Edge シナリオでは、3 つの接続のみが必要になります。 コンテナー エンジンは、モジュール イメージを保持するコンテナー レジストリと接続する必要があります。 IoT Edge ランタイムは、デバイス構成情報を取得する場合、またメッセージとテレメトリを送信する場合に IoT Hub と接続する必要があります。 また、自動プロビジョニングを使用する場合、IoT Edge はデバイス プロビジョニング サービスに接続する必要があります。 詳細については、ファイアウォールとポート構成ルールに関する記述を参照してください。

IoT Edge デバイスからの接続を許可する

ネットワーク設定で、IoT Edge デバイスから行われた接続を明示的に許可する必要がある場合、次の IoT Edge コンポーネントのリストを確認します。

• IoT Edge エージェント: 場合によっては WebSockets 経由で、IoT Hub への永続的な AMQP/MQTT 接続が開かれます。
• IoT Edge ハブ: 場合によっては WebSockets 経由で、IoT Hub への 1 つの永続的な AMQP 接続または複数の MQTT 接続が開かれます。
• IoT Edge サービス: IoT Hub の間欠的な HTTPS 呼び出しが行われます。

3 つのケースすべてにおいて、完全修飾ドメイン名 (FQDN) はパターン \*.azure-devices.net と一致します。

コンテナー レジストリ

コンテナー エンジンでは、HTTPS 経由でコンテナー レジストリを呼び出します。 IoT Edge ランタイムのコンテナー イメージを取得するには、FQDN は mcr.microsoft.com です。 コンテナー エンジンは、デプロイで構成されているその他のレジストリに接続されます。

このチェックリストを使用して、ファイアウォール規則を開始できます。

FQDN (* = ワイルドカード)	送信 TCP ポート	使用方法
mcr.microsoft.com	443	Microsoft Container Registry
*.data.mcr.microsoft.com	443	コンテンツ デリバリーを提供するデータ エンドポイント
*.cdn.azcr.io	443	マーケットプレースからデバイスにモジュールをデプロイする
global.azure-devices-provisioning.net	443	デバイス プロビジョニング サービスへのアクセス (オプション)
*.azurecr.io	443	個人やサード パーティのコンテナー レジストリ
*.blob.core.windows.net	443	BLOB ストレージから Azure Container Registry イメージの差分をダウンロードする
*.azure-devices.net	5671、8883、4431	IoT Hub でのアクセス
*.docker.io	443	Docker Hub でのアクセス (任意指定)

¹ セキュリティで保護された MQTT の場合はポート 8883、セキュリティで保護された AMQP の場合はポート 5671 を開きます。 接続を確立できるのがポート 443 経由のみの場合は、これらのプロトコルのいずれも WebSocket トンネル経由で実行できます。

IoT ハブの IP アドレスは予告なしに変更される可能性があるため、必ず FQDN を使用して許可リストを構成します。 詳しくは、「IoT ハブの IP アドレスについて」をご覧ください。

これらのファイアウォール規則の一部は Azure Container Registry から継承されます。 詳細については、「ファイアウォールの内側から Azure コンテナー レジストリにアクセスする規則を構成する」を参照してください。

Azure Container レジストリで専用データ エンドポイントを有効にすると、 *.blob.core.windows.net FQDN のワイルドカード許可リストを回避できます。 詳細については、「専用データ エンドポイントを有効にする」を参照してください。

Note

REST エンドポイントとデータ エンドポイント間に一貫性のある FQDN を提供するために、2020 年 6 月 15 日以降、Microsoft Container Registry データ エンドポイントは *.cdn.mscr.io から *.data.mcr.microsoft.com に変更されます
詳細については、Microsoft Container Registry クライアント ファイアウォール規則の構成に関する記事を参照してください

パブリック コンテナー レジストリへのアクセスを許可するようにファイアウォールを構成しない場合は、「プライベート レジストリにランタイム コンテナーを格納する」で説明されているように、イメージをプライベート コンテナー レジストリに格納することができます。

Azure IoT ID サービス

IoT ID サービスは、Azure IoT デバイスのプロビジョニングと暗号化のサービスを提供します。 この ID サービスは、インストールされているバージョンが最新バージョンであるかどうかを確認します。 このチェックでは、次の FQDN を使用してバージョンを確認します。

FQDN	送信 TCP ポート	使用方法
aka.ms	443	バージョン ファイルへのリダイレクトを提供するバニティ URL
raw.githubusercontent.com	443	GitHub でホストされている ID サービスのバージョン ファイル

プロキシを介した通信を構成する

プロキシ サーバーを使用するネットワークにデバイスをデプロイする予定の場合は、そのデバイスでプロキシを介して通信を行い、IoT Hub およびコンテナー レジストリに到達できる必要があります。 詳細については、「IoT Edge デバイスを構成してプロキシ サーバー経由で通信する」を参照してください。

コンテナー エンジンの設定で DNS サーバーを設定します

コンテナー エンジンの設定で、環境の DNS サーバーを指定します。 DNS サーバーの設定は、エンジンによって起動されるすべてのコンテナー モジュールに適用されます。

1. デバイスの /etc/docker ディレクトリ内にある daemon.json ファイルを編集します。 このファイルが存在しない場合は作成します。

2. dns キーを追加し、DNS サーバーのアドレスを、パブリックにアクセス可能な DNS サービスに設定します。 エッジ デバイスがパブリック DNS サーバーにアクセスできない場合は、ネットワーク内のアクセス可能な DNS サーバーのアドレスを使用します。 次に例を示します。

   {
       "dns": ["1.1.1.1"]
   }
   

ソリューション管理

• 有用
  • ログと診断を設定する
  • 既定のログ ドライバーを設定する
  • テストおよび CI/CD パイプラインを検討する

ログと診断を設定する

Linux では、IoT Edge デーモンで既定のログ ドライバーとしてジャーナルが使用されます。 コマンドライン ツール journalctl を使用して、デーモン ログのクエリを実行することができます。

バージョン 1.2 以降、IoT Edge は複数のデーモンに依存します。 各デーモンのログには journalctl で個別にクエリを実行できますが、iotedge system コマンドは、結合されたログにクエリを実行する便利な方法です。

• 統合された iotedge コマンド:

  sudo iotedge system logs
  

• 同等の journalctl コマンド:

  journalctl -u aziot-edge -u aziot-identityd -u aziot-keyd -u aziot-certd -u aziot-tpmd
  

IoT Edge のデプロイをテストする場合、通常はデバイスにアクセスしてログを取得し、トラブルシューティングを行うことができます。 デプロイ シナリオでは、そのオプションがない場合があります。 運用環境でデバイスに関する情報をどのように収集するかを検討してください。 1 つのオプションとして、他のモジュールから情報を収集し、クラウドに送信するログ モジュールを使用する方法があります。 ログ モジュールの一例として logspout loganalytics があります。独自のものを設計することもできます。

既定のログ ドライバーを設定する

既定では、Moby コンテナー エンジンでは、コンテナー ログ サイズの制限が設定されません。 これにより、時間の経過と共に、デバイスがログでいっぱいになり、ディスク容量が不足する可能性があります。 local ログ ドライバーをログ記録メカニズムとして使用するようコンテナー エンジンを構成します。 Local ログ ドライバーは既定のログ サイズ制限を提供し、ログローテーションを既定で実行し、ディスク領域の枯渇を防ぐのに役立つより効率的なファイル形式を使用します。 また、さまざまな ログ ドライバー を使用し、さまざまなサイズ制限をニーズに基づいて設定することもできます。

オプション: すべてのコンテナー モジュールの既定のログ ドライバーを構成する

特定のログ ドライバーを使用するようにコンテナー エンジンを構成するには、log driver の値を daemon.json のログ ドライバーの名前に設定します。 次の例では、既定のログ ドライバーをlocal ログ ドライバーに設定します (推奨)。

{
    "log-driver": "local"
}

log-opts キーが daemon.json ファイル内の適切な値を使用するよう構成することもできます。 次の例では、ログ ドライバーを local に設定し、max-size および max-file オプションを設定します。

{
    "log-driver": "local",
    "log-opts": {
        "max-size": "10m",
        "max-file": "3"
    }
}

この情報を daemon.json という名前のファイルに追加 (またはアペンド) して、次の場所に配置します。

• /etc/docker/

変更を有効にするには、コンテナー エンジンを再起動する必要があります。

オプション: 各コンテナー モジュールのログ設定を調整する

これは、各モジュールの createOptions で行うことができます。 次に例を示します。

"createOptions": {
    "HostConfig": {
        "LogConfig": {
            "Type": "local",
            "Config": {
                "max-size": "10m",
                "max-file": "3"
            }
        }
    }
}

Linux システムにおけるその他のオプション

• コンテナーエンジンを構成して、既定のログ ドライバーとして journald を設定することによって、systemdジャーナル にログを送信します。

• logrotate ツールをインストールすることで、デバイスから古いログを定期的に削除します。 次のファイルの指定を使用します。

  /var/lib/docker/containers/*/*-json.log{
       copytruncate
       daily
       rotate7
       delaycompress
       compress
       notifempty
       missingok
  }
  

テストおよび CI/CD パイプラインを検討する

最も効率的な IoT Edge のデプロイ シナリオの場合は、運用環境のデプロイをテストおよび CI/CD パイプラインに統合することを検討してください。 Azure IoT Edge では、Azure DevOps を含む、複数の CI/CD プラットフォームがサポートされます。 詳細については、「Azure IoT Edge に対する継続的インテグレーションと継続的配置」を参照してください。

セキュリティに関する考慮事項

• 重要
  • コンテナー レジストリへのアクセスを管理する
  • ホスト リソースへのコンテナー アクセスを制限する

コンテナー レジストリへのアクセスを管理する

運用環境の IoT Edge デバイスにモジュールをデプロイする前に、部外者がコンテナー イメージにアクセスしたり、変更を加えたりできないように、コンテナー レジストリへのアクセスを制御していることを確認してください。 コンテナー イメージを管理するには、プライベート コンテナー レジストリを使用します。

チュートリアルやその他のドキュメントでは、開発コンピューターで使用するものと同じコンテナー レジストリの資格情報を IoT Edge デバイスでも使用するように指示しています。 これらの指示は、単にテストおよび開発環境をより簡単に設定できるようにするためのものです。運用環境シナリオではこれらの指示に従わないでください。

レジストリへのセキュリティで保護されたアクセスのために、認証オプションを選択できます。 一般的で推奨される認証は、Active Directory サービス プリンシパルを使用することです。これは、IoT Edge デバイスと同様に、自動的にまたは無人方式でコンテナー イメージをプルするアプリケーションやサービスによく適しています。 もう 1 つのオプションは、リポジトリをスコープとしたトークンの使用です。これにより、それらが作成された Azure Container Registry にのみ存在する長期または短期の ID を作成し、リポジトリ レベルへのアクセスのスコープを設定することができます。

サービス プリンシパルを作成するには、「サービス プリンシパルの作成」の説明に従って、2 つのスクリプトを実行します。 これらのスクリプトは次のタスクを実行します。

• 最初のスクリプトでは、サービス プリンシパルが作成されます。 ここでは、サービス プリンシパル ID とサービス プリンシパル パスワードが出力されます。 これらの値は、安全に書き留めておきます。

• 2 番目のスクリプトは、サービス プリンシパルに付与するロールの割り当てを作成します。これは、必要に応じて後で実行できます。 role パラメーターに acrPull ユーザー ロールを適用することをお勧めします。 ロールの一覧については、「Azure Container Registry のロールとアクセス許可」をご覧ください。

サービス プリンシパルを使用して認証するには、最初のスクリプトで取得したサービス プリンシパル ID とパスワードを指定します。 デプロイ マニフェストにこれらの資格情報を指定します。

• ユーザー名またはクライアント ID には、サービス プリンシパル ID を指定します。

• パスワードまたはクライアント シークレットには、サービス プリンシパルのパスワードを指定します。

リポジトリをスコープとしたトークンを作成するには、リポジトリをスコープとしたトークンの作成に関するページに従ってください。

リポジトリをスコープとしたトークンを使用して認証するには、リポジトリをスコープとしたトークンを作成した後に取得したトークン名とパスワードを指定します。 デプロイ マニフェストにこれらの資格情報を指定します。

• ユーザー名には、トークンのユーザー名を指定します。

• パスワードには、トークンのパスワードのいずれかを指定します。

Note

強化されたセキュリティ認証を実装した後、管理者ユーザー 設定を無効にして、既定のユーザー名とパスワードにアクセスできないようにします。 Azure portal のコンテナー レジストリで、左側のウィンドウ メニューの [設定] の下にある [アクセスキー] を選択します。

ホスト リソースへのコンテナー アクセスを制限する

モジュール間で共有ホスト リソースのバランスを取るには、モジュールごとのリソース消費量に制限を設けることをお勧めします。 この制限は、1 つのモジュールが大量のメモリまたは CPU を消費できないようにして、そのデバイスで他のプロセスが実行できなくなるのを防ぐのに役立ちます。 特定のモジュールの最適な実行に必要なリソースの量を知るにはテストが必要になるため、IoT Edge プラットフォームでは、モジュールのリソースは既定では制限されません。

Docker によって提供されるいくつかの制約を使用して、メモリや CPU などのリソースの使用量を制限できます。 詳細については、「Runtime options with memory, CPUs, and GPUs (メモリ、CPU、GPU に関する実行時オプション)」を参照してください。

これらの制約は、配置マニフェストの作成オプションを使用して、個々のモジュールに適用できます。 詳細については、「IoT Edge モジュールのコンテナー作成オプションを構成する方法」を参照してください。

次のステップ

• 詳細については、IoT Edge の自動デプロイに関するページをご覧ください。
• IoT Edge で継続的インテグレーションと継続的配置がどのようにサポートされるのかを確認します。