Greengrassのリソース構造が少し複雑だったため、CLIを叩きながらそのリソースの全体的な構造を把握し、それぞれの役割を整理します。全体像いきなりですが全体像です。IoTのThingを作成します。出力結果は後々必要になるので、変数に入れて取っておきます。".thingName")次に、作成したThingに証明書・ポリシーをアタッチします。ARNは変数に保持しておき、ファイル名に使います。jqを使いたい所なのですが、Keyの改行のせい?か、パース出来なかったためCLIのqueryを使いました。${CERT_ID:0:10}.public.key証明書にポリシーをアタッチします。ポリシーの作成は省略します。${CERT_ARN}Thingに証明書をアタッチします。Coreを作成します。}'このコマンドによって、CoreDefinitionとCoreDefinitionVersionが1つずつ作成されます。Cores[].Idのところではuuidgenを使って生成したUUIDを入れています。これはCoreを一意に識別するIDとなりますが、システム側で自動で生成される訳ではなく、自前で128bitのUUIDv4文字列を生成する必要があります。この後のFunctionやSubscriptionでもこのUUIDが必要となります。CoreDefinitionの内容は以下の様の形です。"GreengrassTest_Core_Definition"}CoreDefinitionVersionは以下のような形です。実際の機能的?な部分は、CoreDefinitionVersionに記載されています。Coresの部分は配列になっていますが、1つしか指定出来ません。次に、LambdaFunctionをGreengrassに紐づけるFunctionDefinitionを作成します。ここでは一旦空の(何れのLambdaFunctionも紐付けない)状態で空の定義を作成します。}'リファレンスhttps://docs.aws.amazon.com/cli/latest/reference/greengrass/create-function-definition.htmlこれで、CoreDefinitionと同様にFunctionDefinitionとFunctionDefinitionVersionが作成されます。Subscription、Resource、Loggerの作成Functionと同様の手順で、Subscription、Resource、LoggerのDefinitionを作成していきます。Subscription、MQTTトピックのルーティングのようなことが行なえます。リファレンスはこちら。}'次にResource。ローカルのファイルシステムやデバイスにアクセスする場合、ここに設定を記述します。リファレンスはこちら。}'そしてLogger。Cloudwatchへログを流したり、ファイルシステムにログを保存する設定となります。リファレンスはこちら。Groupに必要な各要素が揃ったので、ついにGroupを作成していきます。Groupが出来たことが、Webからも確認出来るかと思います。FunctionDefinitionなどはまだ空です。作成したFunctionDefinitionVersionのARNを指定し、新しいGroupVersionを作成まずはFunctionDefinitionVersionの基となるjsonファイルを作成。FUNC_IDはUUIDv4で、新しいFunctionを追加するときは新規に生成します。FUNC_DEF_IDは、最初のGroup作成時に作成したものです。]}これを使って新しいFunctionDefinitionVersionを作成します。"{FUNC_DEF_VER_ID}"}次にGroupVersionを更新します。ここまでやって初めてGroupに変更が反映されます。"{GROUP_ID}"}最後に、新しいGroupVersionを作成します。GroupVersionは自動的に最新のものが使用されます。file://new_group_ver.jsonこれでGroupにLambdaFunctionが追加されました。同様の手順でGroupを更新することが出来ます。とっつきにくいリソース構造はしていましたが、CLIでいじってみると結構わかりやすい構造でした。upLoginユーザーは見つかりませんでした。