Amazon Web Services ブログ

AWS IoT Greengrass v2 コンポーネントを構築するための 5 つのヒント

このブログは、5 tips to build AWS IoT Greengrass v2 Componentsを翻訳したものです。

2020 年 12 月に発表された AWS IoT Greengrass v2 は、構築、デプロイ、管理、およびインテリジェント IoT デバイスがキャプチャするデータをローカルで処理するために使用できるオープンソースのエッジランタイムサービスです。たとえば、データ予測の機械学習モデルを実行し、必要に応じてデバイスデータをフィルタリングおよび集約し、構築済みのソフトウェアコンポーネント、機能、およびツールを使用して、デバイスフリートを大規模に効果的に管理できます。

アプリケーションライブラリとランタイムライブラリで構成される AWS IoT Greengrass コンポーネントを使用すると、カスタムアプリケーションコードを開発し、テストを実行して、AWS IoT Greengrass コアデバイスにデプロイできます。そしてそれは、AWS IoT Greengrass v1よりも柔軟性があります。さらに、コンポーネントはコンテナの外部で実行できるため（ 2.0 の新機能）、コアデバイス上のローカルリソースを直接操作できます。また、AWS IoT Greengrass v1 では、AWS Lambda 関数がコアデバイスで実行されるソフトウェアを定義しますが、AWS IoT Greengrass v2 では、コンポーネントは、定義した任意のソフトウェアアプリケーションで構成できます。

すべてのコンポーネントは、レシピとアーティファクトで構成されています。レシピファイルは、コンポーネントのメタデータを定義します。これには、コンポーネントの構成パラメータ、コンポーネントの依存関係、ライフスタイル、およびプラットフォームの互換性が含まれます。ライフサイクルは、コンポーネントをインストール、実行、およびシャットダウンするためのコマンドを定義します。 YAML および JSON 形式で定義できます。アーティファクトはオプションであり、コンポーネントバイナリで構成され、スクリプト、コンパイル済みコード、静的リソース、およびコンポーネントが消費するその他のファイルが含まれる場合があります。

このブログ記事では、AWS IoT Greengrass v2 コンポーネントを開発する際に考慮すべき 5 つのヒントを共有しています。これらのヒントと洞察は、AWS IoT Greengrass コンポーネントを構造化するためのメカニズムを定義するのに役立つかもしれません。また、このプロセスは、開発ワークフローを加速および改善し、コンポーネント開発をより迅速に開始するのに役立ちます。

この投稿に沿って進めるための前提条件は次のとおりです。

  1. 完全に機能する AWS ユーザーアカウントがあります。セットアップ手順については、ドキュメントを参照してください。
  2. AWS IoT Greengrass がインストールされ、完全に機能しているマシンがあります。まだこれを行っていない場合は、インストール手順に従ってください。

さあ、始めましょう。

1) コマンドラインインターフェイス（CLI）コマンドを使用する

コンポーネントの開発中に、AWS IoT Greengrass Core ソフトウェアとコンポーネントの現在のステータスをすばやく簡単に把握できる CLI コマンドがいくつかあります。このブログ投稿のすべてのコマンドは、Linux または Unix ベースのシステム用です。別のオペレーティングシステムを使用している場合は、それに応じて調整してください。

デフォルトでは、AWS IoT Greengrass Core ソフトウェアはローカルファイルシステムにのみログを書き込みます。ファイルシステムログをリアルタイムで表示して、AWS IoT Greengrass コンポーネントをデバッグできます。特に重要なログの種類は 2 つあります。

1. AWS IoT Greengrass Core ソフトウェアのログファイル。コンポーネントとデプロイ展開に関するリアルタイムの情報が含まれています。これは、デプロイを開始し、何が起こっているのかを知りたいときに最初に確認する場所です。ログファイルのエラーは、トラブルシューティングに役立つ場合があります。ログファイルのディレクトリは root が所有しているため、 sudo を使用してこれらのファイルにアクセスします。

$ sudo tail -F /greengrass/v2/logs/greengrass.log

2. AWS IoT Greengrass コンポーネントのログファイル。これらのファイルには、デバイスで実行されている対応するコンポーネントに関するリアルタイムの情報が含まれています。Generic コンポーネントと Lambda コンポーネントは、これらのログファイルに標準の stdout と stderr を書き込みます。独自のコンポーネントを使用すると、必要に応じてこれらの機能を使用できます。

$ sudo tail -F /greengrass/v2/logs/<component-name>.log
# Concrete example: Your component is named ggv2.custom-comp.logging
$ sudo tail -F /greengrass/v2/logs/ggv2.custom-comp.logging.log

コンポーネントとそのステータスをより深く理解するために、コンポーネントを一覧表示して再起動するための非常に便利なAWS IoT Greengrass CLI コマンドがいくつかあります。コマンドを使用する前に、まず AWS IoT Greengrass CLI をインストールする必要があります。このリストには、コンポーネントの名前、バージョン、および現在の状態が出力されます。

$ sudo /greengrass/v2/bin/greengrass-cli component list 
Components currently running in Greengrass: 
Component Name: FleetStatusService 
Version: 0.0.0 
State: RUNNING 
Configuration: {"periodicUpdateIntervalSec":86400.0} 
Component Name: UpdateSystemPolicyService 
Version: 0.0.0 
State: RUNNING 
Configuration: null 
Component Name: aws.greengrass.Nucleus 
Version: 2.0.0 
State: FINISHED 
Configuration: {"awsRegion":"region","runWithDefault":{"posixUser":"ggc_user:ggc_group"},"telemetry":{}} 
Component Name: DeploymentService 
Version: 0.0.0 
State: RUNNING 
Configuration: null 
Component Name: TelemetryAgent 
Version: 0.0.0 
State: RUNNING 
Configuration: null 
Component Name: aws.greengrass.Cli 
Version: 2.0.0 
State: RUNNING 
Configuration: {"AuthorizedPosixGroups":"ggc_user"}

コンポーネントを再起動すると、コアデバイスは最新の変更を使用します。

$ sudo /greengrass/v2/bin/greengrass-cli component restart \ 
--names "<component-name>"
# Concrete example: Your component is named ggv2.custom-comp.logging-1.0.1 
$ sudo /greengrass/v2/bin/greengrass-cli component restart \ 
--names "ggv2.custom-comp.logging-1.0.1"

AWS IoT Greengrass ログのモニタリング、Amazon CloudWatch へのログ記録を有効にする方法、および便利な AWS IoT Greengrass CLI コマンドに関するより多くの洞察を得ることができます。

2) コンポーネントをローカルで開発する

コンポーネントを開発する際の優れたエクスペリエンスのために、コンポーネントをローカルで開発してから、クラウドでコンポーネントを作成して AWS IoT Greengrass Core デバイスにデプロイすることをお勧めします。サンプルコンポーネント ggv2.custom-comp.logging の簡略化された開発プロセスを見てみましょう。この開発されたコンポーネントを後で使用して、クラウドに送信し、コアデバイスにデプロイできます。

A/ フォルダ構造

サンプルコンポーネントについて、このブログ投稿全体で使用されているサンプルフォルダ構造を見てみましょう。

ggv2.custom-comp.logging :

~                                           <-- Your environment
├── GreengrassDev/
│   ├── deployment.json
│   └── components
│       └── ggv2.custom-comp.logging
│           └── recipes
│              └── ggv2.custom-comp.logging.yaml
│           └── artifacts
│              └── ggv2.custom-comp.logging
│                 └── 1.0.0
│                    └── src
│                       └── script.py
│                    └── main.py
├── GreengrassCore                          <-- GreengrassCore installation
└── README.md

AWS IoT Greengrass Core ソフトウェアのインストール中に作成される GreengrassCore ディレクトリの横に、GreengrassDev ディレクトリを作成します。これには recipes と artifacts フォルダを含むサブディレクトリ component が含まれます。構造が artifacts/<componentName>/<componentVersion> に準拠していることが重要です。

B / AWS IoT Greengrass CLI を含む最初のデプロイ

AWS IoT Greengrass CLI を利用するには、次のコンテンツを含む deployment.json ファイルを作成する必要があります。

{
   "targetArn": "arn:aws:iot:<region>:<account-id>:thing/<thing-name>",
   "deploymentName": "gg-iot-ggv2-bp-deployment",
   "components": {
      "aws.greengrass.Nucleus": {
         "componentVersion": "2.5.3"
      },
      "aws.greengrass.Cli": {
         "componentVersion": "2.5.3"
      }
   }
}

リージョン、アカウント、モノの名前のプレースホルダを実際の値に置き換えてください。次の例では、リージョン が eu-central-1 、アカウント ID が 123456789 、コアデバイスの名前が aws-iot-ggv2-bp-core であると想定しています。また、デプロイ内のコアデバイスのグループをターゲットにする可能性もあります。これにより、複数のデバイス上のソフトウェアを簡単に最新の状態に保つことができます。これは、カスタマーエクスペリエンスを向上させるために AWS IoT Greengrass v2 でリリースされた機能の 1 つです。そのため、deployment.json ファイルで、targetArn はモノまたはグループの Amazon リソース名（ARN）を指定することができます。

クラウドへのデプロイを作成するには、AWS CLI を使用してデプロイを作成します。

$ aws greengrassv2 create-deployment --cli-input-json file://deployment.json

コンソール（またはログ）をチェックして、デプロイが成功したかどうかを確認します。

C / 開発ヘルパー：環境変数と関数

コンポーネント、そのバージョン、およびフォルダ構造に関するすべての重要な値を定義しましょう。

$ export COMPONENT_NAME="ggv2.custom-comp.logging"
$ export COMPONENT_VERSION="1.0.0"
$ export RECIPE_DIR="~/GreengrassDev/components/${COMPONENT_NAME}/recipes"
$ export ARTIFACT_DIR="~/GreengrassDev/components/${COMPONENT_NAME}/artifacts"

ローカル開発プロセスを簡素化するために、2 つのヘルパー関数を作成します。ヘルパー関数 gg_deploy は、エクスポートされた変数を取得し、指定された COMPONENT_VERSION のデプロイメントを作成します。2 番目のヘルパー関数 gg_delete は、以前にデプロイされたコンポーネントバージョンを削除します。新しいデプロイごとにバージョンを更新する代わりに、この関数を使用して以前にデプロイされたコンポーネントバージョンを削除します。これにより、今後同じ指定の COMPONENT_VERSION を使用して新しいバージョンをデプロイできます。どちらの機能でも、AWS IoT Greengrass CLI の deployment create コマンドをさまざまなパラメータで使用します。

#Deploy-Helper-Function
$ gg_deploy(){
sudo /greengrass/v2/bin/greengrass-cli deployment create \
--recipeDir $RECIPE_DIR --artifactDir $ARTIFACT_DIR \
--merge "$COMPONENT_NAME=$COMPONENT_VERSION";
}
#Remove-Helper-Function
$ gg_delete(){
sudo /greengrass/v2/bin/greengrass-cli --ggcRootPath /greengrass/v2 deployment create \
--remove "$COMPONENT_NAME";
}

アーティファクトのファイルを見てみましょう artifacts (~/GreengrassDev/components/artifacts/ggv2.custom-comp.logging/1.0.0)フォルダに main.py があります。そして、src フォルダに script.py があります。script.py のコードはこのようになっています。(これは簡略化された例です)

import datetime
import time

def loopfunction():
    while True:
        message = f"Hello! Current time: {str(datetime.datetime.now())}."
    
        # Print the message to stdout.
        print(message)
        
        time.sleep(1)

メインの関数である main.py も同様に作成します。

import sys
import src.script as helloworld

def main():
    helloworld.loopfunction()

if __name__ == "__main__":
    main()

また、レシピファイル ggv2.custom-comp.logging.yaml の内容は

---
RecipeFormatVersion: "2020-01-25"
ComponentName: "{COMPONENT_NAME}"
ComponentVersion: "{COMPONENT_VERSION}"
ComponentDescription: "Sample Component"
ComponentPublisher: "Me"
Manifests:
  - Platform:
      os: linux
    Lifecycle:
      Run: "python3 -u {artifacts:path}/main.py"

コンポーネントのプロセス例は、2 つの変更が段階的に行われるため、次のようになります。

# Substitute the right component name and version into the recipe file 
$ sed -i 's/{COMPONENT_NAME}/'"$COMPONENT_NAME"'/g' $RECIPE_DIR/$COMPONENT_NAME.yaml 
$ sed -i 's/{COMPONENT_VERSION}/'"$COMPONENT_VERSION"'/g' $RECIPE_DIR/$COMPONENT_NAME.yaml 
# Deploy-Helper-Function 
$ gg_deploy 
# Do changes to the script.py 
$ gg_delete 
$ gg_deploy 
# Do changes to the script.py and the recipe file 
$ gg_delete $ gg_deploy 
# Once we are done and happy with our developed version, we can deploy using the cloud
# I recommend using a last gg_delete to avoid a mismatch in versions 
$ gg_delete

これで、ローカル開発に関するセグメントは終了です。クラウドでコンポーネントを作成し、コアデバイスにデプロイします。

3）クラウドでコンポーネントを作成し、AWS IoT Greengrass Development Kit（GDK）を使用してコアデバイスにデプロイします

カスタムコンポーネントの開発プロセスを容易にするために、AWS は AWS IoT Greengrass Development Kit（GDK）CLI を公開しました。これは、Apache-2.0 ライセンスの下でオープンソースで利用できます。カスタムコンポーネントの作成、構築、公開に役立ちます。AWS GDK CLI を使用する際の前提条件と、インストール手順については、リンクを参照してください。

ここで開発手順を見てみましょう。開始するには、テンプレートまたはコミュニティコンポーネントを使用します。この例では、ヘルパー関数と環境変数を使用して、以前に作成したローカルコンポーネントを、GDK でコンポーネントを構築および公開するための基礎として使用します。AWS IoT GDK CLI は、コンポーネントの新しいバージョンを公開するたびに、バージョンとアーティファクトの URI を更新します。

#Prepare-GDK-Helper-Function 
$ gg_gdk_prepare(){
mkdir -p $RECIPE_DIR/../greengrass-gdk-prepare/$COMPONENT_NAME && cd "$_"
cp -a $ARTIFACT_DIR/$COMPONENT_NAME/$COMPONENT_VERSION/. .

cp -a $RECIPE_DIR/$COMPONENT_NAME.yaml ./recipe.yaml 
sed -i 's/'"$COMPONENT_VERSION"'/{COMPONENT_VERSION}/g' recipe.yaml 
sed -i 's/{artifacts:path}/{artifacts:decompressedPath}\/'"$COMPONENT_NAME"'/g' recipe.yaml 

touch gdk-config.json 
}
# Execute the function 
$ gg_gdk_prepare

コンポーネントを作成する前に、recipe.yaml の一部分の Manifest に Artifacts セクションを追加して、Amazon S3 バケットを指すようにレシピファイルを更新する必要があります。

---
RecipeFormatVersion: "2020-01-25"
ComponentName: "ggv2.custom-comp.logging"
ComponentVersion: "{COMPONENT_VERSION}"
ComponentDescription: "Sample Component"
ComponentPublisher: "Me"
Manifests:
  - Platform:
      os: linux
    Artifacts:
      - URI: "s3://BUCKET_NAME/COMPONENT_NAME/COMPONENT_VERSION/ggv2.custom-comp.logging.zip"
        Unarchive: ZIP
    Lifecycle:
      Run: "python3 -u {artifacts:decompressedPath}/ggv2.custom-comp.logging/main.py"

最後に、次のコードを gdk-config.json ファイルにコピーしましょう。すべての PLACEHOLDER を実際の値に置き換えます。

{
  "component": {
    "<PLACEHOLDER_COMPONENT_NAME>": {
      "author": "Me",
      "version": "NEXT_PATCH",
      "build": {
        "build_system": "zip"
      },
      "publish": {
        "bucket": "<PLACEHOLDER_BUCKET>",
        "region": "<PLACEHOLDER_REGION>"
      }
    }
  },
  "gdk_version": "1.0.0"
}

または、リージョンとバケットを環境変数にエクスポートしてから、gg_gdk_substitute 関数を使用します。

#Existing S3 bucket that GDK uploads the artifacts to
$ export BUCKET_NAME="ggv2-blogpost-XXXXXXXXXX"
$ export REGION="eu-central-1"

#Prepare-GDK-Helper-Function
$ gg_gdk_substitute(){
sed -i 's/<PLACEHOLDER_COMPONENT_NAME>/'"$COMPONENT_NAME"'/g' gdk-config.json
sed -i 's/<PLACEHOLDER_BUCKET>/'"$BUCKET_NAME"'/g' gdk-config.json
sed -i 's/<PLACEHOLDER_REGION>/'"$REGION"'/g' gdk-config.json
}

#Run the function 
$ gg_gdk_substitute

次のステップは、build（gdk component build）および publish（gdk component publish）コマンドを実行することです。これにより、コンポーネントがカスタムコンポーネントとして自身の AWS アカウントに公開されます。詳細な手順と説明については、ドキュメントページにアクセスしてください。最後のステップは、コンポーネントをコアにデプロイすることです。コアには、deployment.json ファイルと AWS CLI を使用します。

{
    "targetArn": "arn:aws:iot:eu-central-1:123456789:thing/aws-iot-ggv2-bp-core",
    "deploymentName": "gg-iot-ggv2-bp-deployment",
    "components": {
        "aws.greengrass.Nucleus": {
            "componentVersion": "2.5.3"
        },
        "aws.greengrass.Cli": {
            "componentVersion": "2.5.3"
        },
        "ggv2.custom-comp.logging": {
            "componentVersion": "1.0.0"
        }
    }
}
$ aws greengrassv2 create-deployment --cli-input-json file://~/GreengrassDev/deployment.json

ログファイルを追跡し、実行中のすべてのコンポーネントを一覧表示して、デプロイのステータスを自由に監視してください。

Failed to head artifact object from S3 という理由で PackageDownloadException が発生した場合は、ロールエイリアスのパーミッションを調整する必要があります（ロールエイリアスには、アーティファクトファイルを保存する S3 バケットの読み取りパーミッションが必要です）。詳細については、このブログ投稿のセクション 4 を参照してください。

4）AWS IoT Greengrass v2 内の権限を理解する

パーミッションに関して、知っておく必要のある 3 つの重要な側面があります。

  1. AWS IoT ロールエイリアス：AWS IoT Greengrass Core とデプロイされたコンポーネントが AWS IoT の外部のサービスと相互作用するときに使用されます。
  2. コンポーネントが nucleus および他の AWS IoT Greengrass コンポーネントと対話する場合のプロセス間通信（IPC）の許可
  3. AWS IoT Greengrass Core デバイスの Thing とアタッチされた証明書：AWS IoT Greengrass Core Thing が AWS IoT 内で実行できることを指定するために使用されます。これには、AWS IoT ロールエイリアスを引き受ける権限も含まれます。 AWS IoT Core ポリシーを確認するには、ドキュメントにアクセスしてください。
    最初の 2 つの概念は AWS IoT Greengrass v2 に固有であるため、次の 2 つのサブチャプターについて詳しく説明します。

最初の 2 つの概念は AWS IoT Greengrass v2 に固有であるため、次の 2 つのサブチャプターについて詳しく説明します。

A / AWS IoT ロールエイリアス

デバイスは X.509 証明書を使用して、クレデンシャルプロバイダーサービスを呼び出すことで一時的な AWS クレデンシャルを取得します。これにより、AWS アクセスキー ID とシークレットアクセスキー ID を AWS IoT Greengrass コアデバイスに保存する必要がなくなります。AWS IoT Core 内の AWS IoT ロールエイリアスは、AWS IoT Greengrass が AWS IoT 外のサービスと通信できるようにする AWS Identity and Access Management（IAM）ロールを指します（デフォルトのロールエイリアス：GreengrassV2TokenExchangeRoleAlias ）。 詳細については、 AWS IoT Core ディベロッパーガイド の AWS サービスへの直接呼び出しの承認を参照してください。

通常、権限が必要になる最初のポイントは、アーティファクトを S3 にアップロードし、クラウド内のコンポーネントの 1 つをデバイスにデプロイする場合です。デバイスが S3 アーティファクトをダウンロードするには、IAM ロールで、アーティファクトがアップロードされたバケットに対する s3:GetObject 権限を許可する必要があります。アクセス許可とデフォルトで許可されている操作の詳細については、デバイスサービスロールに関するドキュメントを確認してください。docker を使用する場合は、Amazon Elastic Container Registry（ECR）へのアクセスを追加で許可する必要があります。

B/プロセス間通信のアクセス許可

コンポーネントが他のコンポーネント、Greengrass nucleus、または AWS IoT Core と相互作用できるようにする場合は、プロセス間通信を使用する必要があります。そのためには、その通信の許可がレシピファイル内のコンポーネントレベルで行われる必要があります。

次に、レシピ内の accessControl セクションは、異なる IPC サービス識別子に関するブロックによって拡張される場合があります。

{
  "accessControl": {
    "<IPC service identifier>": {
      "<unique identifier>": {
        "policyDescription": "Allows access to [...]",
        "operations": [
          "<operation 1>",
          "<operation 2>"
        ],
        "resources": [
          "*"
        ]
      }
    }
  }
}

さまざまな IPC サービス識別子と操作については、ドキュメントを参照してください。コンポーネント ggv2.custom-comp.logging を見てみましょう。コンポーネントが dt/SensorA/temperature という名前の AWS IoT Core クラウドトピックにパブリッシュし、ローカルトピック dt/SensorB/buttonvalue にサブスクライブしたいとします。
次に、以前から更新されたレシピファイルは次のようになります。

---
RecipeFormatVersion: "2020-01-25"
ComponentName: "ggv2.custom-comp.logging"
ComponentVersion: "1.0.0"
ComponentDescription: "Sample Component"
ComponentPublisher: "Me"
ComponentConfiguration:
  DefaultConfiguration:
    accessControl:
      aws.greengrass.ipc.pubsub:
        'ggv2.custom-comp.logging:pubsub:1':
          policyDescription: Allows access to publish to local topic dt/sensorB/buttonvalue.
          operations:
            - 'aws.greengrass#SubscribeToTopic'
          resources:
            - 'dt/sensorB/buttonvalue'
      aws.greengrass.ipc.mqttproxy:
        'ggv2.custom-comp.logging:mqttproxy:1':
          policyDescription: Allows access to publish to cloud topic.
          operations:
            - 'aws.greengrass#PublishToIoTCore
          resources:
            - 'dt/sensorA/temperature'
Manifests:
  - Platform:
      os: linux
    Artifacts:
      - URI: "s3://BUCKET_NAME/COMPONENT_NAME/COMPONENT_VERSION/ggv2.custom-comp.logging.zip"
        Unarchive: ZIP
    Lifecycle:
      Run: "python3 -u {artifacts:decompressedPath}/ggv2.custom-comp.logging/main.py"

accessControl セクションでワイルドカードを使用できます。指定された IPC サービス ID 内で、操作セクションで * ワイルドカードを使用することは、その IPC サービス ID 内のすべての操作が許可されることを意味します。リソースについても同じことが言えます。そのセクションでワイルドカードを使用すると、すべてのトピックに対して指定された操作が可能になります。各 IPC サービスの詳細については、ドキュメントを参照してください。

5）コンポーネント構成を更新するプロセスを理解する

コンポーネント構成の更新がどのように機能するかを見てみましょう。一般的な構成の更新により、古い構成が新しい構成とマージされます。これは、次のいずれかを意味する場合があります。

  1. 新しい値で新しいキーを追加しています。次に、このキーと値が既存のフィールドを使用して既存の構成に追加されます。
  2. 文字列または数値の値を持つ既存のキーがあります。その値を変更すると、新しい構成にはその古いキーとその新しい値が含まれます。
  3. JSON サブ要素を含む既存のキーがあり、ここで 1 つの新しい値を指定します。次に、古いキーは、新しい値である新しい追加フィールドを持つ古い JSON を指します。
  4. 構成からキーを削除するには、リセット機能を使用する必要があります。

コンポーネントをマージするための簡単な例を見てみましょう。

既存の構成 構成の更新 更新後の構成 
{
"key1":{
"subkey_1a":"value1a",
"subkey_1b":"value1b"
},
"key2":"value2"
}

{
"key1":{
"subkey_1b":"new_value1b"
}
}

{
"key1":{
"subkey_1a":"value1a",
"subkey_1b":"new_value1b"
},
"key2":"value2"
}

別の例を見てみましょう：

既存の構成 構成の更新 更新後の構成 
{
"key1":{
"subkey_1a":"value1a",
"subkey_1b":"value1b"
},
"key2":"value2"
}

{
"key1":"new_string1"
}

{
"key1":"new_string1",
"key2":"value2"
}

コンポーネント構成またはサブフィールドを削除する場合は、リセット機能を使用する必要があります。また、JSON ポインターを使用して、デフォルト値にリセットまたは削除するフィールドをアドレス指定する必要があります。

既存の構成 構成の更新 更新後の構成 
{
"key1":{
"subkey_1a":"value1a",
"subkey_1b":"value1b"
},
"key2":"value2"
}

"configurationUpdate": {
"reset": ["/key2"]
}

{
"key1":{
"subkey_1a":"value1a",
"subkey_1b":"value1b"
}
}

次の例では、これをすべてまとめてみましょう。これは、マージとリセットを 1 つの configurationUpdate に組み合わせたものです。

既存の構成 構成の更新 更新後の構成 
{
"key1":{
"subkey_1a":"value1a",
"subkey_1b":"value1b"
},
"key2":"value2"
}

"configurationUpdate": {
"reset": ["/key1/subkey_1a"],
"merge": "{\"key3\":\"value3\"}
}

{
"key1":{
"subkey_1b":"value1b"
},
"key2":"value2",
"key3":"value3"
}

構成全体を完全にリセットする場合は、リセット更新として1つの空の文字列を指定する必要があります。

既存の構成 構成の更新 更新後の構成 
{
"key1":{
"subkey_1a":"value1a",
"subkey_1b":"value1b"
},
"key2":"value2"
}

"configurationUpdate": {
"reset": [""]
}

{}

これについて詳しく知りたい場合は、マージの更新に関するデベロッパーガイドを参照してください。

クリーンアップ

AWS IoT Greengrass Core ソフトウェアをアンインストールし、AWS IoT Greengrass サービスからコアデバイスを削除するには、ドキュメントの手順に従ってください。

まとめ

このブログ投稿では、AWS IoT Greengrass v2 コンポーネントを開発するための 5 つのヒントを紹介しました。これらのヒントと洞察は、AWS IoT Greengrass コンポーネントを構造化するためのメカニズムを開発し、開発ワークフローを加速および改善するのに役立ちます。

これらのヒントには、いくつかの役立つ CLI コマンド、最初にローカルでコンポーネントを開発し、次に AWS GDK CLI を使用してそれらを公開する方法が含まれています。また、権限管理とコンポーネント構成の更新プロセスについても説明しました。

AWS IoT Greengrass v2 の詳細については、ドキュメントとデベロッパーガイドをご覧ください。

この記事はソリューションアーキテクトの戸塚智哉が翻訳しました。