翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# AWS IoT Greengrass コンポーネントをデバイスにデプロイする
を使用して AWS IoT Greengrass 、デバイスまたはデバイスのグループにコンポーネントをデプロイできます。*デプロイ*を使用して、デバイスに送信するコンポーネントと設定を定義します。 は、Greengrass コアデバイスを表す*ターゲット*、 AWS IoT モノ、またはモノのグループに AWS IoT Greengrass デプロイします。 は[AWS IoT Core ジョブ](https://docs.aws.amazon.com/iot/latest/developerguide/iot-jobs.html) AWS IoT Greengrass を使用してコアデバイスにデプロイします。ジョブのデバイスへの展開方法を設定することができます。
## コアデバイスのデプロイ
各コアデバイスは、そのデバイスのためのデプロイのコンポーネントを実行します。同じターゲットへの新しいデプロイは、ターゲットへの以前のデプロイ置を上書きします。デプロイを作成するとき、コアデバイスの既存のソフトウェアに適用するコンポーネントと設定を定義します。
ターゲットのデプロイを改訂するとき、前の改訂のコンポーネントを新しい改訂のコンポーネントに置き換えます。例えば、コンポーネント [ログマネージャー](log-manager-component.md) と [シークレットマネージャー](secret-manager-component.md) をモノグループ `TestGroup` にデプロイします。次に、シークレットマネージャーのコンポーネントのみを指定する `TestGroup` 別のデプロイを作成します。その結果、そのグループのコアデバイスは、ログマネージャーを実行しなくなりました。
## プラットフォーム依存の解決
コアデバイスはデプロイを受け取ると、そのコンポーネントがコアデバイスと互換性があるかどうかを確認します。例えば、Windows のターゲットに [Firehose](kinesis-firehose-component.md) をデプロイした場合、デプロイは失敗します。
## コンポーネント依存の解決
コンポーネントのデプロイ中、コアデバイスはモノグループ全体のすべてのコンポーネントの依存関係とバージョン要件の互換性を検証します。この検証により、デプロイに進む前に、すべてのコンポーネントとその依存関係についてバージョンの制約が満たされます。
依存関係解決プロセスは、レシピに依存関係がないターゲットコンポーネントを特定することから始まります。次に、システムは幅優先検索 (BFS) を使用して依存関係ツリーを構築します。BFS は、各ターゲットノードを体系的に探索し、最初にその依存関係を見つけてから次のノードに進みます。各ノードには、キーとしてターゲットコンポーネントが含まれ、値としてバージョン要件が含まれます。
バージョン要件は、以下の 3 つの制約セットを組み合わせたものです。
+ 既存のモノグループで既に確立されているバージョン要件。
+ デプロイに必要なコンポーネントバージョン。デプロイを作成または更新するときに、コンポーネントバージョンを選択する必要があります。
+ レシピの依存関係セクション内で定義されているコンポーネントバージョンの制約。
### コンポーネントの依存関係を解決する
デプロイ中、Greengrass nucleus はまず、要件を満たすデバイスで現在実行されているローカル候補を見つけようとします。実行中のコンポーネントが要件を満たしている場合、nucleus はレシピフォルダから保存されたレシピパスを取得し、ローカルストアで最新のローカルバージョンを見つけます。
AWS クラウド デプロイの場合、nucleus は [ResolveComponentCandidates API](https://docs.aws.amazon.com/greengrass/v2/APIReference/API_ResolveComponentCandidates.html) を呼び出します。この API は、利用可能な最新バージョンから開始し、依存関係と要件を満たしているかどうかを確認します。Nucleus は API からレスポンスを取得すると、その最新バージョンを選択します。要件を満たすバージョン AWS クラウド が から見つからない場合、デプロイは失敗します。デバイスがオフラインの場合、見つかった元のローカル候補にフォールバックします。要件を満たすローカル候補が見つからない場合、デプロイは失敗します。
ローカルデプロイの場合、nucleus はローカル候補が存在し、交渉せずに要件を満たしている場合のみ、ローカル候補を使用します AWS クラウド。このような候補がない場合、デプロイは失敗します。
**注記**
解決されたレシピはすべて、後で参照できるようにローカルに保存されます。
詳細については、GitHub の「[Dependency resolution](https://github.com/aws-greengrass/aws-greengrass-nucleus/wiki/Deployment#dependency-resolution)」セクションを参照してください。
Greengrass nucleus がすべてのコンポーネントを正常に解決できる場合、nucleus ログには以下の行が含まれます。
```
resolve-all-group-dependencies-finish. Finish resolving all groups dependencies.
```
**Example**
以下は、nucleus がコンポーネント要件を解決する方法の例です。
+ ComponentC バージョン 1.0.0-1.9.0 に依存する ComponentC ComponentA をデプロイします。
+ また、ComponentC バージョン 1.4.0-1.9.5 に依存する ComponentB もデプロイします。
コンポーネントの依存関係の解決により、nucleus は ComponentA と ComponentB の要件を満たすために ComponentC バージョンの最新バージョンをデプロイします。ComponentC の最新バージョンはバージョン 1.9.0 です。
#### 一般的なコンポーネントの依存関係解決の失敗
コンポーネントの依存関係解決は、ターゲットバージョン要件の競合またはコンポーネントの依存関係要件の競合の 2 つの主な理由で失敗することがあります。
##### シナリオ 1: ターゲットバージョン要件の競合
+ モノは 1 つのモノグループに存在し、そのモノを新しいモノグループに追加する必要もあります。新しいモノグループで別のモノのバージョンが必要な場合、デプロイは失敗します。
+ モノがモノグループに属していて、モノのデプロイを通じてコンポーネントバージョンを更新する場合も、デプロイが失敗することがあります。
![\[デプロイが失敗する原因となるコンポーネントの依存関係。\]](http://docs.aws.amazon.com/ja_jp/greengrass/v2/developerguide/images/dependency-4.png)
*失敗ログのサンプル:*
```
2025-04-11T06:16:03.315Z [ERROR] (pool-3-thread-27) com.aws.greengrass.componentmanager.ComponentManager: Failed to negotiate version with cloud and no local version to fall back to. {componentName=ComponentC, versionRequirement={thing/ABC==2.0.0, thinggroup/ThingGroupA==1.0.0}}
2025-04-11T06:16:03.316Z [ERROR] (pool-3-thread-26) com.aws.greengrass.deployment.DeploymentService: Error occurred while processing deployment. {deploymentId=fbac24de-4ef9-44b0-a685-fdc63b0f02b8, serviceName=DeploymentService, currentState=RUNNING}
java.util.concurrent.ExecutionException: com.aws.greengrass.componentmanager.exceptions.NoAvailableComponentVersionException: No local or cloud component version satisfies the requirements Check whether the version constraints conflict and that the component exists in your AWS account with a version that matches the version constraints. If the version constraints conflict, revise deployments to resolve the conflict. Component ComponentC version constraints: thing/ABC requires =2.0.0, thinggroup/ThingGroupA requires =1.0.0.
at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
at com.aws.greengrass.deployment.DefaultDeploymentTask.call(DefaultDeploymentTask.java:127)
at com.aws.greengrass.deployment.DefaultDeploymentTask.call(DefaultDeploymentTask.java:50)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: com.aws.greengrass.componentmanager.exceptions.NoAvailableComponentVersionException: No local or cloud component version satisfies the requirements Check whether the version constraints conflict and that the component exists in your AWS account with a version that matches the version constraints. If the version constraints conflict, revise deployments to resolve the conflict. Component ComponentC version constraints: thing/ABC requires =2.0.0, thinggroup/ThingGroupA requires =1.0.0.
at com.aws.greengrass.componentmanager.ComponentManager.negotiateVersionWithCloud(ComponentManager.java:232)
at com.aws.greengrass.componentmanager.ComponentManager.resolveComponentVersion(ComponentManager.java:167)
at com.aws.greengrass.componentmanager.DependencyResolver.lambda$resolveDependencies$0(DependencyResolver.java:134)
at com.aws.greengrass.componentmanager.DependencyResolver.resolveComponentDependencies(DependencyResolver.java:231)
at com.aws.greengrass.componentmanager.DependencyResolver.resolveDependencies(DependencyResolver.java:131)
at com.aws.greengrass.deployment.DefaultDeploymentTask.lambda$call$2(DefaultDeploymentTask.java:125)
... 4 more
```
Nucleus が 2 つの競合する要件を同時に満たすコンポーネントバージョンを見つけることができないため、ログはバージョン競合エラーを示します。
##### 解決方法
+ コンポーネントを各モノグループに保持する場合は、各モノグループでそのコンポーネントの同じバージョンを選択します。
+ デプロイ要件を満たすコンポーネントバージョンを選択します。
+ 両方のモノグループ要件を満たさないコンポーネントバージョンを使用する場合は、モノグループのバージョン要件を満たすコンポーネントバージョンを選択し、そのコンポーネントをそのモノグループでのみ使用します。
##### シナリオ 2: コンポーネント依存関係のバージョン要件の競合
コンポーネントが異なるコンポーネントの依存関係であり、そのコンポーネントの異なるバージョンまたは異なるバージョン範囲を必要とする場合、すべてのバージョン要件を満たす利用可能なバージョンがない可能性があります。このシナリオでは、デプロイは失敗します。
**Example**
ComponentA (v2.5.0)、ComponentB (v1.3.0)、ComponentC (v1.0.0) のデプロイ
+ ComponentA には ComponentB バージョン >=1.0.0 が必要です。
```
---
...
ComponentName: ComponentA
ComponentVersion: "2.5.0"
ComponentDependencies:
ComponentB:
VersionRequirement: ">=1.0.0"
DependencyType: "HARD"
...
```
+ ComponentC には ComponentA バージョン <2.0.0 が必要です。
```
---
...
ComponentName: ComponentC
ComponentVersion: "1.0.0"
ComponentDependencies:
ComponentA:
VersionRequirement: "<2.0.0"
DependencyType: "HARD"
...
```
ComponentA の 2 つの要件の間にバージョン競合があります。
+ ComponentA では、このデプロイにバージョン 2.5.0 が必要です
+ ComponentC には 2.0.0 より前の ComponentA バージョンが必要です
これらの 2 つの要件は相互に矛盾するため、nucleus は両方の要件を満たす ComponentA バージョンを見つけることができません。したがって、依存関係の解決は失敗します。
![\[デプロイが失敗する原因となるコンポーネントの依存関係。\]](http://docs.aws.amazon.com/ja_jp/greengrass/v2/developerguide/images/dependency-3.png)
*失敗ログのサンプル:*
```
2025-04-11T06:07:18.291Z [ERROR] (pool-3-thread-25) com.aws.greengrass.componentmanager.ComponentManager: Failed to negotiate version with cloud and no local version to fall back to. {componentName=ComponentA, versionRequirement={ComponentC=<2.0.0, thinggroup/ThingGroupA==2.5.0}}
2025-04-11T06:07:18.292Z [ERROR] (pool-3-thread-24) com.aws.greengrass.deployment.DeploymentService: Error occurred while processing deployment. {deploymentId=2ffac4df-1ac9-405c-8c11-28494a1b4382, serviceName=DeploymentService, currentState=RUNNING}
java.util.concurrent.ExecutionException: com.aws.greengrass.componentmanager.exceptions.NoAvailableComponentVersionException: No local or cloud component version satisfies the requirements Check whether the version constraints conflict and that the component exists in your AWS account with a version that matches the version constraints. If the version constraints conflict, revise deployments to resolve the conflict. Component ComponentA version constraints: ComponentC requires <2.0.0, thinggroup/ThingGroupA requires =2.5.0.
at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
at com.aws.greengrass.deployment.DefaultDeploymentTask.call(DefaultDeploymentTask.java:127)
at com.aws.greengrass.deployment.DefaultDeploymentTask.call(DefaultDeploymentTask.java:50)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: com.aws.greengrass.componentmanager.exceptions.NoAvailableComponentVersionException: No local or cloud component version satisfies the requirements Check whether the version constraints conflict and that the component exists in your AWS account with a version that matches the version constraints. If the version constraints conflict, revise deployments to resolve the conflict. Component ComponentA version constraints: ComponentC requires <2.0.0, thinggroup/ThingGroupA requires =2.5.0.
at com.aws.greengrass.componentmanager.ComponentManager.negotiateVersionWithCloud(ComponentManager.java:232)
at com.aws.greengrass.componentmanager.ComponentManager.resolveComponentVersion(ComponentManager.java:167)
at com.aws.greengrass.componentmanager.DependencyResolver.lambda$resolveDependencies$0(DependencyResolver.java:134)
at com.aws.greengrass.componentmanager.DependencyResolver.resolveComponentDependencies(DependencyResolver.java:231)
at com.aws.greengrass.componentmanager.DependencyResolver.resolveDependencies(DependencyResolver.java:131)
at com.aws.greengrass.deployment.DefaultDeploymentTask.lambda$call$2(DefaultDeploymentTask.java:125)
... 4 more
```
ログは、nucleus が以下の要件を満たす ComponentA のバージョンを見つけられないことを示しています。
+ ComponentA がちょうどバージョン 2.5.0 であるという (ThingGroupA の) 要件。
+ 2.0.0 より前の ComponentC バージョンと連携するという要件。
##### 解決方法
+ コンポーネントを各モノグループに保持する場合は、各モノグループでそのコンポーネントの同じバージョンを選択します。
+ デプロイ要件を満たすコンポーネントバージョンを選択します。
+ 両方のモノグループ要件を満たさないコンポーネントバージョンを使用する場合は、モノグループのバージョン要件を満たすコンポーネントバージョンを選択し、そのコンポーネントをそのモノグループでのみ使用します。
**ヒント**
AWS 提供されたコンポーネントにこのエラーが表示された場合は、競合しているコンポーネントを最新バージョンに更新することで解決できます。
## モノのグループからデバイスを削除する
モノグループからコアデバイスを削除するとき、コンポーネントのデプロイ動作は、コアデバイスが実行する [Greengrass nucleus](greengrass-nucleus-component.md) のバージョンによって異なります。
------
#### [ 2.5.1 and later ]
モノのグループからコアデバイスを削除する場合の動作は、 AWS IoT ポリシーが`greengrass:ListThingGroupsForCoreDevice`アクセス許可を付与するかどうかによって異なります。このコアデバイスのアクセス許可と AWS IoT ポリシーの詳細については、「」を参照してください[AWS IoT Greengrassのデバイス認証と認可](device-auth.md)。
+ ** AWS IoT ポリシーがこのアクセス許可を付与する場合**
モノのグループからコアデバイスを削除すると、 は次にデバイスにデプロイするときにモノのグループのコンポーネント AWS IoT Greengrass を削除します。デバイス上のコンポーネントが次のデプロイに含まれる場合、そのコンポーネントはデバイスから削除されません。
+ ** AWS IoT ポリシーがこのアクセス許可を付与しない場合**
モノのグループからコアデバイスを削除しても、そのモノのグループのコンポーネントはデバイスから削除 AWS IoT Greengrass されません。
デバイスからコンポーネントを削除するには、Greengrass CLI の [[デプロイ作成](gg-cli-deployment.md#deployment-create)] コマンドを使用します。削除するコンポーネントを `--remove` 引数で指定し、`--groupId` 引数でモノグループを指定します。
------
#### [ 2.5.0 ]
モノのグループからコアデバイスを削除すると、 は次にデバイスにデプロイするときにモノのグループのコンポーネント AWS IoT Greengrass を削除します。デバイス上のコンポーネントが次のデプロイに含まれる場合、そのコンポーネントはデバイスから削除されません。
この動作では、コアデバイスの AWS IoT ポリシーが アクセス`greengrass:ListThingGroupsForCoreDevice`許可を付与する必要があります。コアデバイスにこの許可がない場合、コアデバイスはデプロイの適用に失敗します。詳細については、「[AWS IoT Greengrassのデバイス認証と認可](device-auth.md)」を参照してください。
------
#### [ 2.0.x - 2.4.x ]
モノのグループからコアデバイスを削除しても、そのモノのグループのコンポーネントはデバイスから削除 AWS IoT Greengrass されません。
デバイスからコンポーネントを削除するには、Greengrass CLI の [[デプロイ作成](gg-cli-deployment.md#deployment-create)] コマンドを使用します。削除するコンポーネントを `--remove` 引数で指定し、`--groupId` 引数でモノグループを指定します。
------
## デプロイ
デプロイは継続的です。デプロイを作成すると、 はオンラインのターゲットデバイスにデプロイを AWS IoT Greengrass ロールアウトします。ターゲットデバイスがオンラインではない場合、次回接続するときにデプロイを受け取ります AWS IoT Greengrass。コアデバイスをターゲットモノグループに追加すると、 はそのモノグループの最新のデプロイをデバイス AWS IoT Greengrass に送信します。
コアデバイスがコンポーネントをデプロイする前に、デフォルトではデバイス上の各コンポーネントに通知します。Greengrass コンポーネントは、通知に応答してデプロイを延期できます。デバイスのバッテリ残量が少ない場合や、中断できないプロセスを実行している場合などに、デプロイを延期できます。詳細については、「[チュートリアル: コンポーネントの更新を延期する Greengrass コンポーネントを開発する](defer-component-updates-tutorial.md)」を参照してください。デプロイを作成するときに、コンポーネントに通知せずにデプロイするように設定することができます。
各ターゲットのモノまたはモノグループは、一度に 1 件のデプロイを持つことができます。つまり、ターゲットのデプロイを作成すると、 はそのターゲットのデプロイの以前のリビジョンをデプロイ AWS IoT Greengrass しなくなります。
## デプロイオプション
デプロイは、更新を受信するデバイスと更新のデプロイ方法の制御を可能にするいくつかのオプションを提供します。デプロイを作成するとき、次のオプションを設定できます。
+ **AWS IoT Greengrass コンポーネント**
ターゲットデバイスにインストールして実行するコンポーネントを定義します。 AWS IoT Greengrass コンポーネントは、Greengrass コアデバイスにデプロイして実行するソフトウェアモジュールです。コンポーネントがデバイスのプラットフォームをサポートしている場合のみ、デバイスがコンポーネントを受信します。これにより、ターゲットデバイスが複数のプラットフォームで実行されている場合でも、デバイスのグループにデプロイできます。コンポーネントがデバイスのプラットフォームをサポートしていない場合、コンポーネントはデバイスにデプロイしません。
カスタムコンポーネントと AWS提供コンポーネントをデバイスにデプロイできます。コンポーネントをデプロイすると、 はコンポーネントの依存関係 AWS IoT Greengrass を識別し、それらもデプロイします。詳細については、「[AWS IoT Greengrass コンポーネントの開発](develop-greengrass-components.md)」および「[AWSが提供したコンポーネント](public-components.md)」を参照してください。
各コンポーネントにデプロイするバージョンと設定の更新を定義します。*設定更新*では、コアデバイスのコンポーネントの既存設定を変更する方法、またはコンポーネントがコアデバイスに存在しない場合はコンポーネントのデフォルト設定を変更する方法を指定します。デフォルト値にリセットする設定値と、コアデバイスにマージする新しい設定値を指定することができます。コアデバイスが異なるターゲット用のデプロイを受信し、かつ各デプロイが互換性のあるコンポーネントバージョンを指定するとき、コアデバイスは、デプロイを作成したときのタイムスタンプに基づいて、設定更新を順序に従って適用します。詳細については、「[コンポーネント設定の更新](update-component-configurations.md)」を参照してください。
**重要**
コンポーネントをデプロイすると、 はそのコンポーネントのすべての依存関係のサポートされている最新バージョン AWS IoT Greengrass をインストールします。このため、モノのグループに新しいデバイスを追加するか、それらのデバイスをターゲットとするデプロイを更新すると、 AWSが提供するパブリックコンポーネントの新しいパッチバージョンがコアデバイスに自動的にデプロイされる可能性があります。nucleus の更新など、一部の自動更新により、デバイスに予期せぬ再起動が発生することがあります。
デバイスで実行されているコンポーネントに不要に更新されることを防ぐには、[デプロイを作成する](create-deployments.md)際、そのコンポーネントの優先バージョンを直接含めることをお勧めします。 AWS IoT Greengrass Core ソフトウェアの更新動作の詳細については、「」を参照してください[AWS IoT Greengrass Core ソフトウェア (OTA) の更新](update-greengrass-core-v2.md)。
+ **デプロイポリシー**
設定を安全にデプロイできるタイミングと、デプロイが失敗した場合の対処方法を定義します。コンポーネントが更新できることを報告することを待機するかどうか指定できます。失敗するデプロイを適用した場合、デバイスを以の設定にロールバックするかどうか指定することもできます。
+ **設定を停止**
デプロイを停止するタイミングと方法を定義します。定義した基準が満たされると、デプロイは停止して失敗します。例えば、最小数のデバイスがデプロイを受信した後、そのデプロイの適用に失敗したデバイスがある割合に達した場合、デプロイを停止するように設定できます。
+ **ロールアウト設定**
デプロイがターゲットデバイスにロールアウトされるレートを定義します。最小レートと最大レートの閾値で指数関数的レート増加を設定できます。
+ **タイムアウト設定**
各デバイスがデプロイに適用する必要がある最大時間を定義します。デバイスが指定した時間を超えると、デバイスはデプロイの適用に失敗します。
**重要**
カスタムコンポーネントは S3 バケットにアーティファクトを定義できます。 AWS IoT Greengrass Core ソフトウェアがコンポーネントをデプロイすると、コンポーネントのアーティファクトが からダウンロードされます AWS クラウド。コアデバイスのロールは、デフォルトで S3 バケットへのアクセスを許可しません。S3 バケットのアーティファクトを定義するカスタムコンポーネントをデプロイするには、コアデバイスロールはそのバケットからアーティファクトをダウンロードする許可を付与する必要があります。詳細については、「[コンポーネントのアーティファクトの S3 バケットへのアクセスを許可する](device-service-role.md#device-service-role-access-s3-bucket)」を参照してください。
**Topics**
+ [コアデバイスのデプロイ](#core-device-deployments)
+ [プラットフォーム依存の解決](#platform-dependency-resolution)
+ [コンポーネント依存の解決](#component-dependency-resolution)
+ [モノのグループからデバイスを削除する](#thing-group-removal-behavior)
+ [デプロイ](#deployments)
+ [デプロイオプション](#deployment-options)
+ [デプロイの作成](create-deployments.md)
+ [サブデプロイを作成する](create-subdeployments.md)
+ [展開の改訂](revise-deployments.md)
+ [デプロイをキャンセルする](cancel-deployments.md)
+ [デプロイのステータスを確認する](check-deployment-status.md)
# デプロイの作成
モノまたはモノグループをターゲットとするデプロイを作成できます。
デプロイを作成するときは、デプロイするソフトウェアコンポーネントと、デプロイジョブをターゲットデバイスにロールアウトする方法を設定します。デプロイは、AWS CLI に提供する JSON ファイルで定義できます。
デプロイターゲットによって、コンポーネントを実行するデバイスが決まります。1 つのコアデバイスにデプロイするには、モノを指定します。複数のコアデバイスにデプロイするには、これらのデバイスが含まれるモノグループを指定します。モノのグループを設定する方法についての詳細は、「AWS IoT デベロッパーガイド」の「[静的モノグループ](https://docs.aws.amazon.com/iot/latest/developerguide/thing-groups.html)」と「[動的モノグループ](https://docs.aws.amazon.com/iot/latest/developerguide/dynamic-thing-groups.html)」を参照してください。
このセクションのステップに従って、ターゲットへのデプロイを作成します。デプロイがあるターゲット上で、ソフトウェアコンポーネントを更新する方法についての詳細は、「[展開の改訂](revise-deployments.md)」を参照してください。
**警告**
[CreateDeployment](https://docs.aws.amazon.com/greengrass/v2/APIReference/API_CreateDeployment.html) 動作では、コアデバイスからコンポーネントをアンインストールできます。コンポーネントが新しいデプロイではなく以前のデプロイに存在する場合、コアデバイスはそのコンポーネントをアンインストールします。コンポーネントのアンインストールを回避するには、まず [ListDeployments](https://docs.aws.amazon.com/greengrass/v2/APIReference/API_ListDeployments.html) 動作を使用して、デプロイのターゲットに既存のデプロイがすでにあるかどうかを確認します。次に、[GetDeployment](https://docs.aws.amazon.com/greengrass/v2/APIReference/API_GetDeployment.html) 動作を使用して、新しいデプロイを作成するときに、その既存のデプロイから開始するようにします。
**デプロイを作成するには (AWS CLI)**
1. `deployment.json` という名前のファイルを作成して、次の JSON オブジェクトをファイルにコピーします。*targetArn* をデプロイがターゲットとする AWS IoT モノまたはモノグループの ARN に置き換えます。モノおよびモノグループの ARN の形式は、次のとおりです。
+ モノ: `arn:aws:iot:region:account-id:thing/thingName`
+ モノのグループ: `arn:aws:iot:region:account-id:thinggroup/thingGroupName`
```
{
"targetArn": "targetArn"
}
```
1. デプロイメント対象に、修正が必要な既存のデプロイメントがあるかどうかをチェックします。以下を行います:
1. 次のコマンドを実行して、デプロイターゲットのデプロイを一覧表示します。*targetArn* をターゲット AWS IoT モノまたはモノグループの ARN に置き換えます。
```
aws greengrassv2 list-deployments --target-arn targetArn
```
レスポンスには、ターゲットの最新デプロイのリストが含まれています。レスポンスが空の場合は、ターゲットに既存のデプロイがありません。[Step 3](#create-deployment-define-name-step) はスキップできます。そうでない場合は、次のステップで使用するため、レスポンスから `deploymentId` をコピーします。
**注記**
ターゲットの最新リビジョン以外のデプロイを修正することもできます。`--history-filter ALL` 引数を指定して、ターゲットのすべてのデプロイを一覧表示します。次に、修正するデプロイの ID をコピーします。
1. 次のコマンドを実行して、デプロイの詳細を取得します。これらの詳細には、メタデータ、コンポーネント、ジョブ設定が含まれます。*deploymentId* を前のステップの ID に置き換えます。
```
aws greengrassv2 get-deployment --deployment-id deploymentId
```
レスポンスには、デプロイの詳細が含まれています。
1. 前のコマンドのレスポンスにある次のキーと値のペアを `deployment.json` にコピーします。これらの値を、新しいデプロイに変更することができます。
+ `deploymentName` - デプロイの名前。
+ `components` - デプロイのコンポーネント。コンポーネントをアンインストールする場合は、このオブジェクトから削除してください。
+ `deploymentPolicies` - デプロイのポリシー。
+ `iotJobConfiguration` - デプロイのジョブ設定。
+ `tags` - デプロイのタグ。
1. (オプション) デプロイの名前を定義します。*deploymentName* をデプロイの名前で置き換えます。
```
{
"targetArn": "targetArn",
"deploymentName": "deploymentName"
}
```
1. 各コンポーネントを追加して、ターゲットデバイスをデプロイします。そのためには、キーと値のペアを `components` オブジェクトに追加します。ここでのキーはコンポーネント名、値はそのコンポーネントの詳細が含まれるオブジェクトになります。追加する各コンポーネントに対して、次の詳細を指定します。
+ `version` - デプロイするコンポーネントのバージョン。
+ `configurationUpdate` - デプロイする[設定の更新](update-component-configurations.md)。更新とは、各ターゲットデバイス上のコンポーネントにある既存の設定、またはターゲットデバイス上に既存の設定がない場合はコンポーネントのデフォルト設定を変更するパッチ操作のことを指します。次の設定更新を指定できます。
+ 更新のリセット (`reset`) - (オプション) ターゲットデバイスのデフォルト値にリセットする設定値を定義する JSON ポインターのリスト。AWS IoT Greengrass Core ソフトウェアは、マージ更新を適用する前にリセット更新を適用します。詳細については、「[更新のリセット](update-component-configurations.md#reset-configuration-update)」を参照してください。
+ マージ更新 (`merge`) - (オプション) ターゲットデバイスにマージする設定値を定義する JSON ドキュメント。JSON ドキュメントは文字列としてシリアル化する必要があります。詳細については、「[マージの更新](update-component-configurations.md#merge-configuration-update)」を参照してください。
+ `runWith` - (オプション) AWS IoT Greengrass Core ソフトウェアが、コアデバイス上でこのコンポーネントのプロセスを実行するために使用するシステムプロセスオプション。`runWith` オブジェクト内のパラメータを省略した場合、AWS IoT Greengrass Core ソフトウェアは [Greengrass nucleus コンポーネント](greengrass-nucleus-component.md)で設定したデフォルト値を使用します。
以下のいずれかのオプションを指定できます。
+ `posixUser` - Linux コアデバイスでこのコンポーネントを実行する際に使用する POSIX システムユーザーおよびオプションでグループ。ユーザーまたはグループを指定する場合は、各 Linux コアデバイス上に存在している必要があります。ユーザーとグループを `user:group` の形式に従ってコロン (`:`) で区切って指定します。グループはオプションです。グループを指定しなかった場合、AWS IoT Greengrass Core ソフトウェアは、ユーザーのプライマリグループを使用します。詳細については、「[コンポーネントを実行するユーザーを設定する](configure-greengrass-core-v2.md#configure-component-user)」を参照してください。
+ `windowsUser` – Windows コアデバイスでこのコンポーネントを実行する際に使用する Windows ユーザー。ユーザーは各 Windows コアデバイスに存在し、その名前とパスワードが LocalSystem アカウントの認証情報マネージャーインスタンスに格納されている必要があります。詳細については、「[コンポーネントを実行するユーザーを設定する](configure-greengrass-core-v2.md#configure-component-user)」を参照してください。
この機能は、[Greengrass nucleus コンポーネント](greengrass-nucleus-component.md)の v2.5.0 以降に利用できます。
+ `systemResourceLimits` - このコンポーネントのプロセスに適用されるシステムリソースの制限。システムリソースの制限を、ジェネリックおよびコンテナ化されていない Lambda コンポーネントプロセスに適用することができます。詳細については、「[コンポーネントのシステムリソース制限を設定する](configure-greengrass-core-v2.md#configure-component-system-resource-limits)」を参照してください。
以下のいずれかのオプションを指定できます。
+ `cpus` – このコンポーネントのプロセスがコアデバイスで使用できる CPU 時間の最大量。コアデバイスの合計 CPU 時間は、デバイスの CPU コア数と同じです。例えば、4 つの CPU コアを持つコアデバイスの場合は、この値を `2` に設定することで、このコンポーネントのプロセスを各 CPU コアの 50% の使用率に制限することができます。CPU コアが 1 つのデバイスの場合は、この値を `0.25` に設定することで、このコンポーネントのプロセスを CPU の 25% の使用率に制限することができます。この値を CPU コア数よりも大きい値に設定すると、AWS IoT Greengrass Core ソフトウェアは、コンポーネントの CPU 使用率に制限をかけません。
+ `memory` – このコンポーネントのプロセスがコアデバイスで使用できる RAM の最大量 (キロバイト単位)。
この機能は、[Greengrass nucleus コンポーネント](greengrass-nucleus-component.md)の v2.4.0 以降に利用できます。AWS IoT Greengrass は、現在 Windows コアデバイスにこの機能をサポートしていません。
**Example 基本設定更新の例**
次の `components` オブジェクト例は、`pythonVersion` という名前の設定パラメータを必要とするコンポーネントである `com.example.PythonRuntime` をデプロイするように指定しています。
```
{
"targetArn": "targetArn",
"deploymentName": "deploymentName",
"components": {
"com.example.PythonRuntime": {
"componentVersion": "1.0.0",
"configurationUpdate": {
"merge": "{\"pythonVersion\":\"3.7\"}"
}
}
}
}
```
**Example リセット更新とマージ更新による設定更新の例**
`com.example.IndustrialDashboard` は産業用ダッシュボードコンポーネントの一例です。次のデフォルト設定が設定されています。
```
{
"name": null,
"mode": "REQUEST",
"network": {
"useHttps": true,
"port": {
"http": 80,
"https": 443
},
},
"tags": []
}
```
次の設定更新では、次の手順が指定されています。
1. HTTPS 設定をデフォルト値 (`true`) にリセットする。
1. 産業タグのリストを空のリストにリセットする。
1. 2 つのボイラーの温度と圧力のデータストリームを識別する産業用タグのリストをマージする。
```
{
"reset": [
"/network/useHttps",
"/tags"
],
"merge": {
"tags": [
"/boiler/1/temperature",
"/boiler/1/pressure",
"/boiler/2/temperature",
"/boiler/2/pressure"
]
}
}
```
以下の `components` オブジェクト例では、この産業用ダッシュボードコンポーネントと設定更新をデプロイするように指定しています。
```
{
"targetArn": "targetArn",
"deploymentName": "deploymentName",
"components": {
"com.example.IndustrialDashboard": {
"componentVersion": "1.0.0",
"configurationUpdate": {
"reset": [
"/network/useHttps",
"/tags"
],
"merge": "{\"tags\":[\"/boiler/1/temperature\",\"/boiler/1/pressure\",\"/boiler/2/temperature\",\"/boiler/2/pressure\"]}"
}
}
}
}
```
1. (オプション) デプロイのデプロイポリシーを定義します。コアデバイスがデプロイを安全に適用できるタイミングや、コアデバイスがデプロイの適用に失敗した場合の対処方法を設定できます。そのためには、`deploymentPolicies` オブジェクトを `deployment.json` に追加し、以下のいずれかを実行します。
1. (オプション) コンポーネント更新ポリシー (`componentUpdatePolicy`) を指定します。このポリシーは、コンポーネントをデプロイする準備が整うまで、コンポーネントの更新を延期できるかどうかを定義します。例えば、再起動して更新を適用する前に、リソースをクリーンアップしたり、重要なアクションを完了する必要がある場合などです。このポリシーは、コンポーネントが更新通知に対してレスポンスする必要がある時間枠も定義します。
このポリシーは、以下のパラメータを使用するオブジェクトです。
+ `action` - (オプション) コンポーネントに通知し、更新の準備が整ったときに報告されるまで待機するかどうかを示します。次のオプションから選択します。
+ `NOTIFY_COMPONENTS` - デプロイは、コンポーネントを停止して更新する前に、各コンポーネントに通知します。コンポーネントは [SubscribeToComponentUpdates](ipc-component-lifecycle.md#ipc-operation-subscribetocomponentupdates) IPC 操作を使用して、これらの通知を受信することができます。
+ `SKIP_NOTIFY_COMPONENTS` - デプロイは、コンポーネントに通知せず、安全に更新できるまで待機しません。
デフォルトは `NOTIFY_COMPONENTS` です。
+ `timeoutInSeconds` 各コンポーネントが [DeferComponentUpdate](ipc-component-lifecycle.md#ipc-operation-defercomponentupdate) IPC 操作による更新通知に応答する必要がある時間枠 (秒単位)。コンポーネントがこの時間内に応答しなかった場合、コアデバイスでデプロイが実行されます。
デフォルトは 60 秒です。
1. (オプション) 設定検証ポリシー (`configurationValidationPolicy`) を指定します。このポリシーは、各コンポーネントがデプロイからの設定更新を検証する必要がある期間を定義します。コンポーネントは [SubscribeToValidateConfigurationUpdates](ipc-component-configuration.md#ipc-operation-subscribetovalidateconfigurationupdates) IPC 操作を使用して、自身に対する設定更新の通知にサブスクライブすることができます。これにより、コンポーネントが [SendConfigurationValidityReport](ipc-component-configuration.md#ipc-operation-sendconfigurationvalidityreport) IPC 操作を使用して、設定更新が有効なものかどうかを AWS IoT Greengrass Core ソフトウェアに伝えられるようになります。設定更新が有効でない場合、デプロイは失敗します。
のポリシーは、次のパラメータを使用するオブジェクトです。
+ `timeoutInSeconds` (オプション) 各コンポーネントが設定更新を検証する必要がある時間 (秒単位)。コンポーネントがこの時間内に応答しなかった場合、コアデバイスでデプロイが実行されます。
デフォルトは 30 秒です。
1. (オプション) 障害処理ポリシー (`failureHandlingPolicy`) を指定します。このポリシーは、デプロイが失敗した場合にデバイスをロールバックするかどうかを定義する文字列です。次のオプションから選択します。
+ `ROLLBACK` - コアデバイスでデプロイが失敗した場合、AWS IoT Greengrass Core ソフトウェアは、そのコアデバイスを以前の設定にロールバックします。
+ `DO_NOTHING` - コアデバイスでデプロイが失敗した場合、AWS IoT Greengrass Core ソフトウェアは、新しい設定を維持します。この場合、新しい設定が有効でない場合には、コンポーネントが壊れる可能性があります。
デフォルトは `ROLLBACK` です。
`deployment.json` でのデプロイは次の例のようになります。
```
{
"targetArn": "targetArn",
"deploymentName": "deploymentName",
"components": {
"com.example.IndustrialDashboard": {
"componentVersion": "1.0.0",
"configurationUpdate": {
"reset": [
"/network/useHttps",
"/tags"
],
"merge": "{\"tags\":[\"/boiler/1/temperature\",\"/boiler/1/pressure\",\"/boiler/2/temperature\",\"/boiler/2/pressure\"]}"
}
}
},
"deploymentPolicies": {
"componentUpdatePolicy": {
"action": "NOTIFY_COMPONENTS",
"timeoutInSeconds": 30
},
"configurationValidationPolicy": {
"timeoutInSeconds": 60
},
"failureHandlingPolicy": "ROLLBACK"
}
}
```
1. (オプション) デプロイの停止、ロールアウト、タイムアウトの方法を定義します。AWS IoT Greengrass は AWS IoT Core ジョブを使用してコアデバイスにデプロイを送信するため、これらのオプションは AWS IoT Core ジョブ用の設定オプションと同じになります。詳細については、「AWS IoT デベロッパーガイド」の「[ジョブのロールアウトと中止設定](https://docs.aws.amazon.com/iot/latest/developerguide/job-rollout-abort.html)」を参照してください。
ジョブオプションを定義するには、`iotJobConfiguration` オブジェクトを `deployment.json` に追加します。次に、設定するオプションを定義します。
`deployment.json` でのデプロイは次の例のようになります。
```
{
"targetArn": "targetArn",
"deploymentName": "deploymentName",
"components": {
"com.example.IndustrialDashboard": {
"componentVersion": "1.0.0",
"configurationUpdate": {
"reset": [
"/network/useHttps",
"/tags"
],
"merge": "{\"tags\":[\"/boiler/1/temperature\",\"/boiler/1/pressure\",\"/boiler/2/temperature\",\"/boiler/2/pressure\"]}"
}
}
},
"deploymentPolicies": {
"componentUpdatePolicy": {
"action": "NOTIFY_COMPONENTS",
"timeoutInSeconds": 30
},
"configurationValidationPolicy": {
"timeoutInSeconds": 60
},
"failureHandlingPolicy": "ROLLBACK"
},
"iotJobConfiguration": {
"abortConfig": {
"criteriaList": [
{
"action": "CANCEL",
"failureType": "ALL",
"minNumberOfExecutedThings": 100,
"thresholdPercentage": 5
}
]
},
"jobExecutionsRolloutConfig": {
"exponentialRate": {
"baseRatePerMinute": 5,
"incrementFactor": 2,
"rateIncreaseCriteria": {
"numberOfNotifiedThings": 10,
"numberOfSucceededThings": 5
}
},
"maximumPerMinute": 50
},
"timeoutConfig": {
"inProgressTimeoutInMinutes": 5
}
}
}
```
1. (オプション) タグ (`tags`) をデプロイに追加します。詳細については、「[AWS IoT Greengrass Version 2 リソースにタグを付ける](tag-resources.md)」を参照してください。
1. 以下のコマンドを実行して、`deployment.json` からデプロイを作成します。
```
aws greengrassv2 create-deployment --cli-input-json file://deployment.json
```
レスポンスには、このデプロイを識別する `deploymentId` が含まれます。デプロイ ID を使用して、デプロイのステータスを確認できます。詳細については、「[デプロイのステータスを確認する](check-deployment-status.md#check-cloud-deployment-status)」を参照してください。
# コンポーネント設定の更新
コンポーネント設定は、各コンポーネントのパラメータを定義する JSON オブジェクトです。各コンポーネントの recipe は、コアデバイスにコンポーネントをデプロイするときに変更するデフォルト設定を定義します。
デプロイを作成するとき、各コンポーネントに適用する設定の更新を指定できます。設定の更新はパッチ操作であり、更新がコアデバイスに存在するコンポーネント設定を修正することを意味します。コアデバイスにコンポーネントがない場合、設定更新がそのデプロイのデフォルト設定を修正して適用します。
設定更新は、リセット更新とマージ更新を定義します。リセット更新は、デフォルトにリセットまたは削除する設定値を定義します。マージ更新は、コンポーネントに設定する新しい設定値を定義します。設定更新をデプロイすると、 AWS IoT Greengrass Core ソフトウェアはマージ更新の前にリセット更新を実行します。
コンポーネントは、デプロイする設定更新を検証できます。コンポーネントは、デプロイが設定を変更した際に通知を受信するようにサブスクライブして、サポートしていない設定を拒否できます。詳細については、「[コンポーネント設定とやり取り](ipc-component-configuration.md)」を参照してください。
**Topics**
+ [更新のリセット](#reset-configuration-update)
+ [マージの更新](#merge-configuration-update)
+ [例](#configuration-update-example)
## 更新のリセット
リセット更新は、コアデバイスでデフォルトにリセットする設定値を定義します。設定値にデフォルト値がない場合、リセット更新がコンポーネントの設定からその値を削除します。これにより、無効な設定によって破損するコンポーネントを修正するうえで役立ちます。
JSON ポインタのリストを使用して、リセットする設定値を定義します。JSON ポインタはフォワードスラッシュ (`/`) で始まります。ネストされたコンポーネント設定の値を識別するには、フォワードスラッシュ (`/`) を使用して、設定の各レベルのキーを区切ります。詳細については、「[JSON ポインタの仕様](https://tools.ietf.org/html/rfc6901)」を参照してください。
**注記**
リスト全体のみをデフォルト値にリセットできます。更新リセットを使用して、リストの個々の要素をリセットすることはできません。
コンポーネントの設定を全体的にデフォルト値にリセットするには、リセット更新として空の文字列を 1 つ指定します。
```
"reset": [""]
```
## マージの更新
マージ更新は、コアのコンポーネント設定に挿入する設定値を定義します。マージ更新は、リセット更新で指定したパスの値をリセットした後に AWS IoT Greengrass Core ソフトウェアがマージする JSON オブジェクトです。 AWS CLI または AWS SDKs を使用する場合は、この JSON オブジェクトを文字列としてシリアル化する必要があります。
コンポーネントのデフォルト設定に存在しないキー値のペアをマージできます。同じキーの値とは異なるタイプのキー値のペアをマージすることもできます。古い値は新しい値により上書きされます。つまり、設定オブジェクトの構造を変更できます。
Null 値を空の文字列、リスト、オブジェクトとマージできます。
**注記**
マージ更新は、リストに要素の挿入または追加する目的として使用することはできません。リスト全体を置き換え、あるいは各要素に一意のキーを持つオブジェクトを定義できます。
AWS IoT Greengrass は設定値に JSON を使用します。JSON は数値タイプを指定しますが、整数と浮動小数点数を区別しません。その結果、 AWS IoT Greengrassで設定値が浮動小数点数に変換されることがあります。コンポーネントが正しいデータタイプを使用することを確認するには、数値の設定値を文字列として定義することをお勧めします。次に、整数または浮動小数点としてコンポーネントでパースします。これにより、設定値が設定とコアデバイスに対して同じタイプであることを保証します。
### マージ更新で recipe 変数を使用する
この機能は、[Greengrass nucleus コンポーネント](greengrass-nucleus-component.md)の v2.6.0 以降で利用できます。
Greengrass nucleus の [interpolateComponentConfiguration](greengrass-nucleus-component.md#greengrass-nucleus-component-configuration-interpolate-component-configuration) 設定オプションを `true` に設定したら、マージ更新で `component_dependency_name:configuration:json_pointer` recipe 変数以外の recipe 変数を使用できます。たとえば、マージ更新で `{iot:thingName}` recipe 変数を使用して、[プロセス間通信 (IPC) 認可ポリシー](interprocess-communication.md#ipc-authorization-policies)などのコンポーネント設定値にコアデバイスの AWS IoT モノの名前を含めることができます。
## 例
次の例では、次のデフォルト設定を持つダッシュボードコンポーネントの設定更新を示しています。このコンポーネントの例は、産業機器に関する情報を表示します。
```
{
"name": null,
"mode": "REQUEST",
"network": {
"useHttps": true,
"port": {
"http": 80,
"https": 443
},
},
"tags": []
}
```
### 産業用ダッシュボード コンポーネント recipe
------
#### [ JSON ]
```
{
"RecipeFormatVersion": "2020-01-25",
"ComponentName": "com.example.IndustrialDashboard",
"ComponentVersion": "1.0.0",
"ComponentDescription": "Displays information about industrial equipment.",
"ComponentPublisher": "Amazon",
"ComponentConfiguration": {
"DefaultConfiguration": {
"name": null,
"mode": "REQUEST",
"network": {
"useHttps": true,
"port": {
"http": 80,
"https": 443
},
},
"tags": []
}
},
"Manifests": [
{
"Platform": {
"os": "linux"
},
"Lifecycle": {
"Run": "python3 -u {artifacts:path}/industrial_dashboard.py"
}
},
{
"Platform": {
"os": "windows"
},
"Lifecycle": {
"Run": "py -3 -u {artifacts:path}/industrial_dashboard.py"
}
}
]
}
```
------
#### [ YAML ]
```
---
RecipeFormatVersion: '2020-01-25'
ComponentName: com.example.IndustrialDashboard
ComponentVersion: '1.0.0'
ComponentDescription: Displays information about industrial equipment.
ComponentPublisher: Amazon
ComponentConfiguration:
DefaultConfiguration:
name: null
mode: REQUEST
network:
useHttps: true
port:
http: 80
https: 443
tags: []
Manifests:
- Platform:
os: linux
Lifecycle:
Run: |
python3 -u {artifacts:path}/industrial_dashboard.py
- Platform:
os: windows
Lifecycle:
Run: |
py -3 -u {artifacts:path}/industrial_dashboard.py
```
------
**Example 例 1: マージ更新**
次の設定更新を適用するデプロイを作成します。この更新は、マージ更新を指定しますが、リセット更新は指定しません。この設定更新は、2 基のボイラーのデータで HTTP ポート 8080 にダッシュボードを表示するように、コンポーネントに指示します。
**マージする設定**
```
{
"name": "Factory 2A",
"network": {
"useHttps": false,
"port": {
"http": 8080
}
},
"tags": [
"/boiler/1/temperature",
"/boiler/1/pressure",
"/boiler/2/temperature",
"/boiler/2/pressure"
]
}
```
次のコマンドは、コアデバイスにデプロイを作成します。
```
aws greengrassv2 create-deployment --cli-input-json file://dashboard-deployment.json
```
`dashboard-deployment.json` ファイルには、次の JSON ドキュメントが含まれています。
```
{
"targetArn": "arn:aws:iot:us-west-2:123456789012:thing/MyGreengrassCore",
"deploymentName": "Deployment for MyGreengrassCore",
"components": {
"com.example.IndustrialDashboard": {
"componentVersion": "1.0.0",
"configurationUpdate": {
"merge": "{\"name\":\"Factory 2A\",\"network\":{\"useHttps\":false,\"port\":{\"http\":8080}},\"tags\":[\"/boiler/1/temperature\",\"/boiler/1/pressure\",\"/boiler/2/temperature\",\"/boiler/2/pressure\"]}"
}
}
}
}
```
次の [Greengrass CLI](greengrass-cli-component.md) コマンドは、コアデバイスにローカルデプロイを作成します。
```
sudo greengrass-cli deployment create \
--recipeDir recipes \
--artifactDir artifacts \
--merge "com.example.IndustrialDashboard=1.0.0" \
--update-config dashboard-configuration.json
```
`dashboard-configuration.json` ファイルには、次の JSON ドキュメントが含まれています。
```
{
"com.example.IndustrialDashboard": {
"MERGE": {
"name": "Factory 2A",
"network": {
"useHttps": false,
"port": {
"http": 8080
}
},
"tags": [
"/boiler/1/temperature",
"/boiler/1/pressure",
"/boiler/2/temperature",
"/boiler/2/pressure"
]
}
}
}
```
この更新の後、ダッシュボードコンポーネントは次の設定になります:
```
{
"name": "Factory 2A",
"mode": "REQUEST",
"network": {
"useHttps": false,
"port": {
"http": 8080,
"https": 443
}
},
"tags": [
"/boiler/1/temperature",
"/boiler/1/pressure",
"/boiler/2/temperature",
"/boiler/2/pressure"
]
}
```
**Example 例 2: 更新のリセットとマージ**
次に、次の設定更新を適用するデプロイを作成します。この更新は、リセット更新とマージ更新を指定します。これらの更新は、デフォルトの HTTPS ポートに異なるボイラーのデータでダッシュボードを表示するように指定します。これらの更新は、前の例で示されている設定更新の結果となる設定を変更します。
**パスのリセット**
```
[
"/network/useHttps",
"/tags"
]
```
**マージする設定**
```
{
"tags": [
"/boiler/3/temperature",
"/boiler/3/pressure",
"/boiler/4/temperature",
"/boiler/4/pressure"
]
}
```
次のコマンドは、コアデバイスにデプロイを作成します。
```
aws greengrassv2 create-deployment --cli-input-json file://dashboard-deployment2.json
```
`dashboard-deployment2.json` ファイルには、次の JSON ドキュメントが含まれています。
```
{
"targetArn": "arn:aws:iot:us-west-2:123456789012:thing/MyGreengrassCore",
"deploymentName": "Deployment for MyGreengrassCore",
"components": {
"com.example.IndustrialDashboard": {
"componentVersion": "1.0.0",
"configurationUpdate": {
"reset": [
"/network/useHttps",
"/tags"
],
"merge": "{\"tags\":[\"/boiler/3/temperature\",\"/boiler/3/pressure\",\"/boiler/4/temperature\",\"/boiler/4/pressure\"]}"
}
}
}
}
```
次の [Greengrass CLI](greengrass-cli-component.md) コマンドは、コアデバイスにローカルデプロイを作成します。
```
sudo greengrass-cli deployment create \
--recipeDir recipes \
--artifactDir artifacts \
--merge "com.example.IndustrialDashboard=1.0.0" \
--update-config dashboard-configuration2.json
```
`dashboard-configuration2.json` ファイルには、次の JSON ドキュメントが含まれています。
```
{
"com.example.IndustrialDashboard": {
"RESET": [
"/network/useHttps",
"/tags"
],
"MERGE": {
"tags": [
"/boiler/3/temperature",
"/boiler/3/pressure",
"/boiler/4/temperature",
"/boiler/4/pressure"
]
}
}
}
```
この更新の後、ダッシュボードコンポーネントは次の設定になります:
```
{
"name": "Factory 2A",
"mode": "REQUEST",
"network": {
"useHttps": true,
"port": {
"http": 8080,
"https": 443
}
},
"tags": [
"/boiler/3/temperature",
"/boiler/3/pressure",
"/boiler/4/temperature",
"/boiler/4/pressure",
]
}
```
# サブデプロイを作成する
**注記**
サブデプロイ機能は、Greengrass nucleus バージョン 2.9.0 以降で使用できます。Greengrass nucleus の旧コンポーネントバージョンでは、設定をサブデプロイにデプロイすることはできません。
サブデプロイは、親デプロイ内のデバイスのより小さなサブセットをターゲットとするデプロイです。サブデプロイを使用して、デバイスのより小さなサブセットに設定をデプロイできます。サブデプロイを作成して、親デプロイ内の 1 つ以上のデバイスで失敗した場合に、失敗した親デプロイを再試行することもできます。この機能を使用すると、その親デプロイで失敗したデバイスを選択し、サブデプロイを作成して、そのサブデプロイが成功するまで設定をテストできます。サブデプロイが成功したら、その設定を親デプロイに再デプロイできます。
サブデプロイを作成し、そのステータスを確認するには、このセクションのステップに従います。デプロイを作成する方法の詳細については、「[デプロイの作成](https://docs.aws.amazon.com/greengrass/v2/developerguide/create-deployments.html)」を参照してください。
**サブデプロイを作成するには (AWS CLI)**
1. 次のコマンドを実行して、モノのグループの最新のデプロイを取得します。コマンド内の ARN を、クエリするモノグループの ARN に置き換えます。`--history-filter` を **LATEST\$1ONLY** に設定すると、そのモノのグループの最新のデプロイが表示されます。
```
aws greengrassv2 list-deployments --target-arn arn:aws:iot:region:account-id:thinggroup/thingGroupName --history-filter LATEST_ONLY
```
1. 次のステップで使用する **list-deployments** コマンドに対するレスポンスから `deploymentId` をコピーします。
1. 次のコマンドを実行し、デプロイのステータスを取得します。`deploymentId` をクエリするデプロイの ID に置き換えます。
```
aws greengrassv2 get-deployment --deployment-id deploymentId
```
1. 次のステップで使用する **get-deployment** コマンドに対するレスポンスから `iotJobId` をコピーします。
1. 次のコマンドを実行して、指定されたジョブの実行リストを取得します。*jobID* を前のステップの `iotJobId` に置き換えます。*status* を、フィルタリングするステータスに置き換えます。次のステータスで結果をフィルタリングできます。
+ `QUEUED`
+ `IN_PROGRESS`
+ `SUCCEEDED`
+ `FAILED`
+ `TIMED_OUT`
+ `REJECTED`
+ `REMOVED`
+ `CANCELED`
```
aws iot list-job-executions-for-job --job-id jobID --status status
```
1. サブデプロイ用に新しい AWS IoT モノのグループを作成するか、既存のモノのグループを使用します。次に、この AWS IoT モノのグループにモノを追加します。モノグループを使用して Greengrass コアデバイスのフリートを管理します。ソフトウェアコンポーネントをデバイスにデプロイするとき、個々のデバイスまたはデバイスのグループのいずれかを対象にできます。アクティブな Greengrass デプロイを備えたモノのグループにデバイスを追加できます。追加すると、そのモノのグループのソフトウェアコンポーネントをそのデバイスにデプロイできるようになります。
新しいモノのグループを作成して、それにデバイスを追加するには、次を実行します。
1. AWS IoT モノのグループを作成します。*MyGreengrassCoreGroup* を新しいモノグループの名前に置き換えます。モノのグループ名にコロン (:) は使用できません。
**注記**
サブデプロイのモノのグループが 1 つの `parentTargetArn` で使用されている場合、それを別の親フリートで再利用することはできません。あるモノのグループが別のフリートのサブデプロイを作成するために既に使用されている場合、API はエラーを返します。
```
aws iot create-thing-group --thing-group-name MyGreengrassCoreGroup
```
リクエストが正常に処理された場合、レスポンスは次の例のようになります。
```
{
"thingGroupName": "MyGreengrassCoreGroup",
"thingGroupArn": "arn:aws:iot:us-west-2:123456789012:thinggroup/MyGreengrassCoreGroup",
"thingGroupId": "4df721e1-ff9f-4f97-92dd-02db4e3f03aa"
}
```
1. プロビジョンド Greengrass コアをモノのグループに追加します。次のパラメータを使用して次のコマンドを実行します。
+ *MyGreengrassCore* を、プロビジョンド Greengrass コアの名前に置き換えます。
+ *MyGreengrassCoreGroup* をモノグループの名前に置き換えます。
```
aws iot add-thing-to-thing-group --thing-name MyGreengrassCore --thing-group-name MyGreengrassCoreGroup
```
要求が正常に処理された場合、コマンドは出力されません。
1. `deployment.json` という名前のファイルを作成して、次の JSON オブジェクトをファイルにコピーします。*targetArn* をサブデプロイがターゲットとする AWS IoT モノのグループの ARN に置き換えます。サブデプロイのターゲットにできるのは、モノのグループのみです。モノのグループの ARN の形式は、次のとおりです。
+ **モノのグループ** – `arn:aws:iot:region:account-id:thinggroup/thingGroupName`
```
{
"targetArn": "targetArn"
}
```
1. 次のコマンドを再度実行して、元のデプロイの詳細を取得します。これらの詳細には、メタデータ、コンポーネント、ジョブ構成が含まれます。*deploymentId* を [Step 1](#create-subdeployments-step1) の ID に置き換えます。このデプロイ設定を使用してサブデプロイを設定し、必要に応じて変更できます。
```
aws greengrassv2 get-deployment --deployment-id deploymentId
```
レスポンスには、デプロイの詳細が含まれています。**get-deployment** コマンドのレスポンスにある次のキーと値のペアを `deployment.json` にコピーします。これらの値を、サブデプロイ向けに変更することができます。このコマンドの詳細については、「[GetDeployment](https://docs.aws.amazon.com/greengrass/v2/APIReference/API_GetDeployment.html)」を参照してください。
+ `components` - デプロイのコンポーネント。コンポーネントをアンインストールする場合は、このオブジェクトから削除してください。コンポーネントが[アンインストールライフサイクル](component-recipe-reference.md#uninstall-lifecycle-definition)ステップを定義する場合、 AWS IoT Greengrass Core ソフトウェアはアンインストールスクリプトを実行してから、デバイスからコンポーネントを削除します。
+ `deploymentName` - デプロイの名前。
+ `deploymentPolicies` - デプロイのポリシー。
+ `iotJobConfiguration` - デプロイのジョブ設定。
+ `parentTargetArn` – 親デプロイのターゲット。
+ `tags` - デプロイのタグ。
1. 次のコマンドを実行して、`deployment.json` からサブデプロイを作成します。*subdeploymentName* をサブデプロイの名前に置き換えます。
```
aws greengrassv2 create-deployment --deployment-name subdeploymentName --cli-input-json file://deployment.json
```
レスポンスには、このサブデプロイを識別する `deploymentId` が含まれます。デプロイ ID を使用して、デプロイのステータスを確認できます。詳細については、「[デプロイのステータスを確認する](https://docs.aws.amazon.com/greengrass/v2/developerguide/check-deployment-status.html#check-cloud-deployment-status)」を参照してください。
1. サブデプロイが成功した場合は、その設定を使用して親デプロイを修正できます。前のステップで使用した `deployment.json` をコピーします。JSON ファイルの `targetArn` を親デプロイの ARN に置き換え、次のコマンドを実行してこの新しい設定で親デプロイを作成します。
**注記**
親フリートの新しいデプロイリビジョンを作成すると、その親デプロイのすべてのデプロイリビジョンとサブデプロイが置き換えられます。詳細については、「[デプロイの変更](https://docs.aws.amazon.com/greengrass/v2/developerguide/revise-deployments.html)」を参照してください。
```
aws greengrassv2 create-deployment --cli-input-json file://deployment.json
```
レスポンスには、このデプロイを識別する `deploymentId` が含まれます。デプロイ ID を使用して、デプロイのステータスを確認できます。詳細については、「[デプロイのステータスを確認する](check-deployment-status.md#check-cloud-deployment-status)」を参照してください。
# 展開の改訂
各ターゲットのモノまたはモノグループは、一度に 1 つのアクティブなデプロイを持つことができます。既にデプロイがあるターゲットのデプロイを作成するとき、新しいデプロイのソフトウェアコンポーネントが、以前のデプロイのソフトウェアコンポーネントを置き換えます。新しいデプロイが、以前のデプロイが定義するコンポーネントを定義しない場合、AWS IoT Greengrass Core ソフトウェアはターゲットコアデバイスからそのコンポーネントを削除します。既存のデプロイを改訂して、ターゲットに対する以前のデプロイのコアデバイスで実行されるコンポーネントを削除しないようにできます。
デプロイを改訂するには、以前のデプロイに存在する同じコンポーネントと設定から開始するデプロイを作成します。[CreateDeployment](https://docs.aws.amazon.com/greengrass/v2/APIReference/API_CreateDeployment.html) の操作を使用しますが、これは[デプロイ作成](create-deployments.md)の操作と同じです。
**デプロイ (AWS CLI) を改訂するには**
1. 次のコマンドを実行して、デプロイターゲットのデプロイを一覧表示します。*targetArn* をターゲット AWS IoT モノまたはモノグループの ARN に置き換えます。
```
aws greengrassv2 list-deployments --target-arn targetArn
```
レスポンスには、ターゲットの最新デプロイのリストが含まれています。`deploymentId` を次のステップで使用するレスポンスからコピーします。
**注記**
ターゲットの最新リビジョン以外のデプロイを修正することもできます。`--history-filter ALL` 引数を指定して、ターゲットのすべてのデプロイを一覧表示します。次に、修正するデプロイの ID をコピーします。
1. 次のコマンドを実行して、デプロイの詳細を取得します。これらの詳細には、メタデータ、コンポーネント、ジョブ設定が含まれます。*deploymentId* を前のステップの ID に置き換えます。
```
aws greengrassv2 get-deployment --deployment-id deploymentId
```
レスポンスには、デプロイの詳細が含まれています。
1. `deployment.json` という名前のファイルを作成し、前のコマンドのレスポンスをファイルにコピーします。
1. `deployment.json` の JSON オブジェクトから次のキーと値のペアを削除します。
+ `deploymentId`
+ `revisionId`
+ `iotJobId`
+ `iotJobArn`
+ `creationTimestamp`
+ `isLatestForTarget`
+ `deploymentStatus`
[CreateDeployment](https://docs.aws.amazon.com/greengrass/v2/APIReference/API_CreateDeployment.html) オペレーションでは、次の構造を持つペイロードが必要です。
```
{
"targetArn": "String",
"components": Map of components,
"deploymentPolicies": DeploymentPolicies,
"iotJobConfiguration": DeploymentIoTJobConfiguration,
"tags": Map of tags
}
```
1. `deployment.json` で、次のいずれかを行ってください。
+ デプロイの名前 (`deploymentName`) を変更します。
+ デプロイのコンポーネント (`components`) を変更します。
+ デプロイのポリシー (`deploymentPolicies`) を変更します。
+ デプロイのジョブ設定 (`iotJobConfiguration`) を変更します。
+ デプロイのタグ (`tags`) を変更します。
これらのデプロイを定義する方法の詳細については、「[デプロイの作成](create-deployments.md)」を参照してください。
1. 以下のコマンドを実行して、`deployment.json` からデプロイを作成します。
```
aws greengrassv2 create-deployment --cli-input-json file://deployment.json
```
レスポンスには、このデプロイを識別する `deploymentId` が含まれます。デプロイ ID を使用して、デプロイのステータスを確認できます。詳細については、「[デプロイのステータスを確認する](check-deployment-status.md#check-cloud-deployment-status)」を参照してください。
# デプロイをキャンセルする
アクティブなデプロイをキャンセルして、AWS IoT Greengrass コアデバイスにソフトウェアコンポーネントがインストールされるのを防ぐことができます。モノグループをターゲットとするデプロイをキャンセルすると、グループに追加したコアデバイスが、その継続的デプロイを受信しなくなります。コアデバイスで既にデプロイが実行されている場合、デプロイをキャンセルしても、そのデバイスのコンポーネントは変更されません。キャンセルされたデプロイを受信したコアデバイス上で実行されるコンポーネントを修正するには、[新しいデプロイを作成する](create-deployments.md)か、[デプロイを修正する](revise-deployments.md)必要があります。
**デプロイをキャンセルするには (AWS CLI)**
1. 次のコマンドを実行し、ターゲットの最新のデプロイリビジョンの ID を検索します。新しいリビジョンの作成時に以前のデプロイはキャンセルされるため、最新のリビジョンが、ターゲットに対してアクティブにできる唯一のデプロイとなります。*targetArn* をターゲット AWS IoT モノまたはモノグループの ARN に置き換えます。
```
aws greengrassv2 list-deployments --target-arn targetArn
```
レスポンスには、ターゲットの最新デプロイのリストが含まれています。`deploymentId` を次のステップで使用するレスポンスからコピーします。
1. 以下のコマンドを実行して、デプロイをキャンセルします。*deploymentId* を前のステップの ID に置き換えます。
```
aws greengrassv2 cancel-deployment --deployment-id deploymentId
```
操作が成功すると、デプロイのステータスが `CANCELED` に変わります。
# デプロイのステータスを確認する
AWS IoT Greengrass で作成したデプロイのステータスを確認できます。また、各コアデバイスにデプロイをロールアウトする AWS IoT ジョブのステータスも確認できます。デプロイがアクティブな間は、AWS IoT ジョブのステータスは `IN_PROGRESS` になります。デプロイの新しいリビジョンを作成すると、前のリビジョンの AWS IoT ジョブのステータスが `CANCELLED` に変わります。
**Topics**
+ [デプロイのステータスを確認する](#check-cloud-deployment-status)
+ [デバイスへのデプロイのステータスを確認する](#check-device-deployment-status)
## デプロイのステータスを確認する
ターゲットまたはその ID で識別したデプロイのステータスを確認できます。
**ターゲットでデプロイステータスを確認するには (AWS CLI)**
+ 次のコマンドを実行し、ターゲットの最新のデプロイの ID を検索します。*targetArn* は、デプロイがターゲットとする AWS IoT のモノまたはモノグループの Amazon リソースネーム (ARN) に置き換えます。
```
aws greengrassv2 list-deployments --target-arn targetArn
```
レスポンスには、ターゲットの最新デプロイのリストが含まれています。このデプロイオブジェクトには、デプロイのステータスが含まれます。
**ID でデプロイステータスを確認するには (AWS CLI)**
+ 次のコマンドを実行し、デプロイのステータスを取得します。*deploymentId* をクエリするデプロイの ID に置き換えます。
```
aws greengrassv2 get-deployment --deployment-id deploymentId
```
レスポンスには、デプロイのステータスが含まれます。
## デバイスへのデプロイのステータスを確認する
個々のコアデバイスに適用されるデプロイジョブのステータスを確認できます。また、モノのグループのデプロイで、デプロイジョブのステータスを確認することもできます。
**コアデバイスへのデプロイジョブのステータスを確認するには (AWS CLI)**
+ 次のコマンドを実行し、コアデバイスに対するすべてのデプロイジョブのステータスを取得します。*coreDeviceName* をクエリするコアデバイスの名前に置き換えます。
```
aws greengrassv2 list-effective-deployments --core-device-thing-name coreDeviceName
```
レスポンスには、コアデバイスのデプロイジョブのリストが含まれます。デプロイのジョブは、ジョブの `deploymentId` または `targetArn` により識別できます。各デプロイジョブには、コアデバイス上のジョブのステータスが含まれます。
**モノのグループのデプロイステータスを確認するには (AWS CLI)**
1. 次のコマンドを実行し、既存のデプロイの ID を取得します。*targetArn* は、ターゲットであるモノのグループの ARN に置き換えます。
```
aws greengrassv2 list-deployments --target-arn targetArn
```
レスポンスには、対象の最新デプロイメントのリストが含まれています。`deploymentId` を次のステップで使用するレスポンスからコピーします。
**注記**
ターゲットの最新デプロイ以外のデプロイを一覧表示することもできます。`--history-filter ALL` 引数を指定して、ターゲットのすべてのデプロイを一覧表示します。次に、ステータスを確認するデプロイの ID をコピーします。
1. 次のコマンドを実行して、デプロイメントの詳細を取得します。*deploymentID* を前のステップで取得した ID に置き換えます。
```
aws greengrassv2 get-deployment --deployment-id deploymentId
```
このレスポンスには、デプロイに関する情報が含まれています。次のステップで使用するために、レスポンスから `iotJobId` をコピーします。
1. 次のコマンドを実行し、デプロイにおけるコアデバイスのジョブ実行について詳細を表示します。*iotJobId* と *coreDeviceThingName* は、前のステップで取得したジョブ ID 、およびステータスを確認するコアデバイスに置き換えます。
```
aws iot describe-job-execution --job-id iotJobId --thing-name coreDeviceThingName
```
このレスポンスには、コアデバイスにおけるデプロイジョブの実行ステータスと、ステータスに関する詳細情報が含まれます。`detailsMap` には、以下の情報が含まれています。
+ `detailed-deployment-status` – デプロイ結果のステータスで、以下のいずれかの値を取ります。
+ `SUCCESSFUL` – デプロイは成功しました。
+ `FAILED_NO_STATE_CHANGE` – コアデバイスがデプロイの適用を準備をしている間に、そのデプロイが失敗しました。
+ `FAILED_ROLLBACK_NOT_REQUESTED` – デプロイは失敗しました。このデプロイでは、以前の動作構成にロールバックするための指定が行われていないため、コアデバイスが正しく機能していない可能性があります。
+ `FAILED_ROLLBACK_COMPLETE` – デプロイは失敗しましたが、コアデバイスは以前の動作設定に正常にロールバックされました。
+ `FAILED_UNABLE_TO_ROLLBACK` – デプロイが失敗しました。コアデバイスは、以前の動作設定にロールバックできなかったため、正しく機能していない可能性があります。
デプロイが失敗した場合は、`deployment-failure-cause` 値、およびコアデバイスのログファイルにより問題を特定します。コアデバイスのログファイルへのアクセス方法については、「[AWS IoT Greengrass ログのモニタリング](monitor-logs.md)」を参照してください。
+ `deployment-failure-cause` – ジョブの実行が失敗した理由について、追加的な情報を提供するエラーメッセージです。
このレスポンスは、次の例のようになります。
```
{
"execution": {
"jobId": "2cc2698a-5175-48bb-adf2-1dd345606ebd",
"status": "FAILED",
"statusDetails": {
"detailsMap": {
"deployment-failure-cause": "No local or cloud component version satisfies the requirements. Check whether the version constraints conflict and that the component exists in your AWS アカウント with a version that matches the version constraints. If the version constraints conflict, revise deployments to resolve the conflict. Component com.example.HelloWorld version constraints: LOCAL_DEPLOYMENT requires =1.0.0, thinggroup/MyGreengrassCoreGroup requires =1.0.1.",
"detailed-deployment-status": "FAILED_NO_STATE_CHANGE"
}
},
"thingArn": "arn:aws:iot:us-west-2:123456789012:thing/MyGreengrassCore",
"queuedAt": "2022-02-15T14:45:53.098000-08:00",
"startedAt": "2022-02-15T14:46:05.670000-08:00",
"lastUpdatedAt": "2022-02-15T14:46:20.892000-08:00",
"executionNumber": 1,
"versionNumber": 3
}
}
```