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

[アーティクル]
04/11/2024

適用対象: IoT Edge 1.4

重要

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

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

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

デバイス構成

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

重要
- 運用環境の証明書をインストールする
- デバイスの管理を計画する
- コンテナーエンジンとして Moby を使用する
有用
- アップストリームプロトコルを選ぶ

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

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

デバイス 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 などの自動化ツールを使用します。

コンテナーエンジンとして Moby を使用する

コンテナーエンジンは、すべての IoT Edge デバイスの前提条件となります。運用環境では moby-engine のみがサポートされます。 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 エージェントは次のように各モジュールを順番に処理します。

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

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

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

コンテナー管理

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

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

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

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

IoT Edge ランタイムのタグ

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

ローリングタグ - バージョン番号の先頭の 2 つの値のみを使用して、これらの数字に一致する最新のイメージを取得します。たとえば、最新の 1.1.x バージョンを指す新しいリリースが存在するたびに、1.1 が更新されます。 IoT Edge デバイス上のコンテナーランタイムによって、再度イメージが取得されると、ランタイムモジュールが最新バージョンに更新されます。 Azure portal からのデプロイでは、既定でローリングタグに設定されます。 開発目的では、このアプローチが推奨されます。
特定のタグ - バージョン番号の 3 つすべての値を使用して、イメージのバージョンを明示的に設定します。たとえば、1.1.0 はその最初のリリース後に変更されることはありません。更新する準備ができたら、配置マニフェストに新しいバージョン番号を宣言できます。 運用環境目的では、このアプローチが推奨されます。

ボリュームを管理する

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

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

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

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

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

# Pull edgeAgent image
docker pull mcr.microsoft.com/azureiotedge-agent:1.4

# Pull edgeHub image
docker pull mcr.microsoft.com/azureiotedge-hub:1.4

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

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

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

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

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

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

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

mcr.microsoft.com を edgeAgent および edgeHub システムモジュールの実際の "レジストリ名またはサーバー" に置き換えて、両方のモジュールの deployment.template.json ファイル内のイメージ参照を更新します。
IoT Edge デバイスでテキストエディターを開いて、プライベートレジストリイメージがデバイスで認識されるように構成ファイルを変更します。
```
sudo nano /etc/aziot/config.toml
```
テキストエディターで、[agent.config] の下にあるイメージの値を変更します。角かっこ内の値を実際の値に置き換えます。
```
[agent.config]
image = "<registry-name/server>/azureiotedge-agent:1.4"
```

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

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

変更を保存し、テキストエディターを終了します。
IoT Edge 構成の変更を適用します。
```
sudo iotedge config apply
```
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、443¹	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 サーバーの設定は、エンジンによって起動されるすべてのコンテナーモジュールに適用されます。

デバイスの /etc/docker ディレクトリ内にある daemon.json ファイルを編集します。このファイルが存在しない場合は作成します。
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 で継続的インテグレーションと継続的配置がどのようにサポートされるのかを確認します。