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

適用対象: IoT Edge 1.5

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

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

Device configuration

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

• Important

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

• Helpful

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

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

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

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

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

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

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

• Device firmware
• オペレーティング システム ライブラリ
• コンテナー エンジン (Moby など)
• IoT Edge
• CA certificates

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

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

Container engine

コンテナー エンジンは、任意の 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 デバイスを構成する」を参照してください。

Deployment

• Helpful
  • アップストリーム プロトコルに合わせる
  • システム モジュール用にホスト ストレージを設定する
  • 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"
                        }
                    ...

Container management

• Important
  • タグを使用してバージョンを管理する
  • Manage volumes
• 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 portal からのデプロイでは、既定でローリング タグに設定されます。 開発目的では、このアプローチが推奨されます。

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

Manage volumes

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. を 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 エージェントを構成する
• 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"

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

ネットワーク

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

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

Container registries

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

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

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

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

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

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

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

Azure IoT ID サービス

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

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

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

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

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

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

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

   {
       "dns": ["1.1.1.1"]
   }
   

Solution management

• 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 でこれらのオプションを設定します。 For example:

"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 に対する継続的インテグレーションと継続的配置」を参照してください。

Security considerations

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Next steps

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