次の方法で共有

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

対象:IoT Edge 1.5 チェックマーク IoT Edge 1.5

Important

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

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

この記事のすべての情報が同じように重要であるとは言えない。 優先順位を付けやすくするために、各セクションは作業を「運用環境に進む前に完了することが重要」のグループと、「知っておくと役立つ」のグループに分けたリストで始まります。

デバイス構成

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

  • Important

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

  • Helpful

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

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

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

Edge CA 証明書の役割を理解するには、「証明書 Azure IoT Edgeの使用方法を参照してください。

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

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

デバイスを運用環境に配置する前に、今後の更新プログラムを管理する方法を検討してください。 IoT Edge デバイスの場合、更新するコンポーネントの一覧には次のものが含まれます。

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

Device Update for IoT Hub は、IoT Edge デバイスの OVER-the-air 更新プログラム (OTA) を展開できるサービスです。

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

コンテナー エンジン

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

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

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

どちらのランタイム モジュールにも、 UpstreamProtocol 環境変数があります。 この変数の有効な値は次のとおりです。

  • MQTT
  • AMQP
  • MQTTWS
  • AMQPWS

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

IoT Edge デバイスが接続したら、将来のデプロイで両方のランタイム モジュールの UpstreamProtocol 変数を構成し続けます。 たとえば、「プロキシ サーバー経由で通信するIoT Edge デバイスを構成するを参照してください。

Deployment

  • Helpful
    • アップストリーム プロトコルと一貫性を保つ。
    • システム モジュールのホスト ストレージを設定します。
    • IoT Edge ハブで使用されるメモリ領域を減らします。
    • 配置マニフェストで正しいモジュール イメージを使用します。
    • カスタム モジュールを使用する場合は、ツイン サイズの制限に注意してください。
    • モジュールに対する更新プログラムの適用方法を構成します。

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

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

UpstreamProtocol 環境変数は、IoT Edge エージェントモジュールとIoT Edgeハブ モジュールに対してのみ構成する必要があります。 追加のモジュールは、ランタイム モジュールで設定されているプロトコルを継承します。

このプロセスの例は、プロキシ サーバーを介して通信する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 ハブのパフォーマンスを最適化し、メモリ使用量を減らすもう 1 つの方法は、ソリューションで使用していないプロトコルのプロトコル ヘッドをオフにすることです。

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

  • amqpSettings__enabled
  • mqttSettings__enabled
  • httpSettings__enabled

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

場合によっては、モジュール間に依存関係が存在する場合など、実行中のモジュールを再起動する前に、更新されたすべてのモジュール イメージを最初にダウンロードすることをお勧めします。 このモジュールの更新動作を構成するには、IoT Edge Agent 環境変数 ModuleUpdateMode を文字列値 WaitForAllPulls に設定します。 詳細については、「IoT Edge 環境変数を参照してください。

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

コンテナー管理

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

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

タグは、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 ポータルからのデプロイは、既定でローリング タグに設定されます。 開発目的では、このアプローチが推奨されます。

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

ボリュームを管理する

IoT Edgeでは、モジュール コンテナーにアタッチされているボリュームは削除されません。 これは、アップグレード シナリオなど、コンテナー インスタンス間でデータを保持できるようにするための仕様上の動作です。 ただし、これらのボリュームが未使用の場合は、ディスク領域が不足し、その後のシステム エラーが発生する可能性があります。 シナリオで Docker ボリュームを使用する場合は、 Docker ボリュームの排除 や Docker ボリューム 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. を edgeAgent および edgeHub システム モジュールの実際の "レジストリ名またはサーバー" に置き換えて、両方のモジュールの mcr.microsoft.com ファイル内のイメージ参照を更新します。

  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 v1.4以降で導入された機能で、モジュールで使用されなくなった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"

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

Parameter Description Required 既定値
enabled イメージ・ガベージ・コレクションを有効にします。 この機能を無効にするには、この値を false に設定します。 Optional true
cleanup_recurrence クリーンアップ タスクを実行する頻度を制御します。 この値を日数として指定します。1 日未満にすることはできません。

たとえば、1d、2d、6d などです。		 Optional 1d
image_age_cleanup_threshold クリーンアップを検討する前に、未使用のイメージの最小有効期間のしきい値を定義します。 この値を日数で指定します。 イメージがデプロイから削除されたらすぐにクリーンアップする 0d を指定できます。

イメージは、デプロイから削除された後、未使用と見なされます。		 Optional 7d
cleanup_time クリーンアップ タスクが実行される時刻 (デバイスのローカル時刻)。 24 時間 HH:MM 形式である必要があります。 デバイスがオンラインでない場合、クリーンアップ タスクは実行されません。 その時点でデバイスがオンラインの場合、タスクは次のスケジュールされた cleanup_time で実行されます。 Optional 00:00

ネットワーク

  • Helpful
    • 送信と受信の構成を確認する
    • 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 エージェントは、WebSocketを介して、IoT Hubへの永続的な AMQP または MQTT 接続を確立します。
  • IoT Edge hub は、1 つの永続的な AMQP 接続または WebSocket 経由でIoT Hubへの複数の MQTT 接続を開きます。
  • IoT Edge service は、IoT Hubに対して断続的な HTTPS 呼び出しを行います。

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

コンテナー レジストリ

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

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

FQDN (* = ワイルドカード) 送信 TCP ポート Usage
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 アクセス (省略可能)

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

ヒント

セキュリティを強化するために、ワイルドカード FQDN を可能な限り特定のエンドポイントに置き換えます。 たとえば、 *.azure-devices.net を <your-hub-name>.azure-devices.netに置き換えます。 *.azurecr.io を <your-registry-name>.azurecr.ioに置き換えます。 エンタープライズ セキュリティ チームは、多くの場合、ワイルドカード規則を拒否するため、運用環境で特定の FQDN を計画します。

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

これらのファイアウォール規則の一部は、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 Identity Service

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

FQDN 送信 TCP ポート Usage
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"]
}

    外部 DNS をブロックする企業またはプライベート ネットワークの場合は、代わりに内部 DNS サーバーを使用します。

    {
    "dns": ["10.0.0.53"]
}

ソリューション管理

  • Helpful
    • ログと診断を設定する
    • 既定のログ ドライバーを設定する
    • テストおよび 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 システムにおけるその他のオプション

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

  • 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への継続的インテグレーションと継続的デプロイメント」を参照してください。

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

  • Important
    • コンテナー レジストリへのアクセスを管理します。
    • ホスト リソースへのコンテナー アクセスを制限します。

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

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

チュートリアルやその他のドキュメントでは、開発用コンピューターと同じコンテナー レジストリ資格情報をIoT Edgeデバイスで使用します。 これらの手順は、テスト環境と開発環境をより簡単に設定するのに役立ち、運用環境では使用できません。

レジストリへのより安全なアクセスを得るために、いくつかの 認証オプションから選択します。 Active Directory サービス プリンシパルの使用は、アプリやサービスがコンテナー イメージを自動的かつ無人でプルするための一般的で推奨される方法です (IoT Edge デバイスと同様)。 リポジトリ スコープのトークンを使用することもできます。このトークンを使用すると、作成したAzure Container Registryにのみ存在し、リポジトリ レベルへのアクセスのスコープを設定できる、有効期間の長い ID または有効期間の短い ID を作成できます。

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

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

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

サービス プリンシパルを使用して認証するには、配置マニフェストの最初のスクリプトからサービス プリンシパル ID とパスワード資格情報を指定します。

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

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

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

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

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

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

Note

セキュリティ強化認証を実装した後、既定のユーザー名とパスワードのアクセスが使用できないように、 管理者ユーザー 設定を無効にします。 コンテナー レジストリの設定は、Azure ポータルの Settings で、Access キー を選択します。

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

モジュール間で共有ホスト リソースのバランスを取るために、各モジュールのリソース使用に制限を設定します。 これらの制限により、1 つのモジュールで過剰なメモリまたは CPU を使用できず、デバイス上で他のプロセスが実行されないようにします。 既定では、IoT Edge プラットフォームではモジュールのリソースは制限されません。モジュールの実行に必要なリソースの量をテストして把握する必要があるためです。

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

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

たとえば、モジュールを 256 MB のメモリと 1 つの CPU コアに制限するには、次のようにします。

"createOptions": {
    "HostConfig": {
        "Memory": 268435456,
        "NanoCPUs": 1000000000
    }
}

次のステップ

  • Last updated on