

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

# AWS IoT Greengrass Komponenten auf Geräten bereitstellen
<a name="manage-deployments"></a>

Sie können AWS IoT Greengrass es verwenden, um Komponenten auf Geräten oder Gerätegruppen bereitzustellen. Mithilfe von *Bereitstellungen* definieren Sie die Komponenten und Konfigurationen, die an die Geräte gesendet werden. AWS IoT Greengrass wird für *Ziele*, AWS IoT Dinge oder Dinggruppen bereitgestellt, die Greengrass-Kerngeräte repräsentieren. AWS IoT Greengrass verwendet [AWS IoT Core Jobs](https://docs.aws.amazon.com/iot/latest/developerguide/iot-jobs.html) zur Bereitstellung auf Ihren Kerngeräten. Sie können konfigurieren, wie der Job auf Ihren Geräten ausgeführt wird.

## Bereitstellungen von Kerngeräten
<a name="core-device-deployments"></a>

Auf jedem Kerngerät werden die Komponenten der Bereitstellungen für dieses Gerät ausgeführt. Eine neue Bereitstellung auf demselben Ziel überschreibt die vorherige Bereitstellung auf dem Ziel. Wenn Sie eine Bereitstellung erstellen, definieren Sie die Komponenten und Konfigurationen, die auf die vorhandene Software des Kerngeräts angewendet werden sollen.

Wenn Sie eine Bereitstellung für ein Ziel überarbeiten, ersetzen Sie die Komponenten der vorherigen Version durch die Komponenten in der neuen Version. Beispielsweise stellen Sie die [Geheimer Manager](secret-manager-component.md) Komponenten [Protokollmanager](log-manager-component.md) und für die Dinggruppe `TestGroup` bereit. Dann erstellen Sie eine weitere Bereitstellung`TestGroup`, für die nur die Secret Manager-Komponente angegeben ist. Das hat zur Folge, dass auf den Kerngeräten in dieser Gruppe der Log Manager nicht mehr ausgeführt wird.

## Auflösung der Plattformabhängigkeit
<a name="platform-dependency-resolution"></a>

Wenn ein Kerngerät bereitgestellt wird, überprüft es, ob die Komponenten mit dem Kerngerät kompatibel sind. Wenn Sie das beispielsweise [Firehose](kinesis-firehose-component.md) auf einem Windows-Ziel bereitstellen, schlägt die Bereitstellung fehl.

## Auflösung der Abhängigkeit von Komponenten
<a name="component-dependency-resolution"></a>

Während einer Komponentenbereitstellung überprüft das Kerngerät die Kompatibilität der Abhängigkeiten und Versionsanforderungen aller Komponenten in einer Dinggruppe. Diese Überprüfung stellt sicher, dass die Versionsbeschränkungen für alle Komponenten und ihre Abhängigkeiten erfüllt sind, bevor mit der Bereitstellung fortgefahren wird.

Der Prozess zur Auflösung von Abhängigkeiten beginnt mit der Identifizierung von Zielkomponenten, deren Rezepturen keine Abhängigkeiten enthalten. Anschließend erstellt das System mithilfe der Breadth-First-Suche (BFS) einen Abhängigkeitsbaum, der jeden Zielknoten systematisch untersucht und zuerst seine Abhängigkeiten findet, bevor zum nächsten Knoten übergegangen wird. Jeder Knoten enthält die Zielkomponente als Schlüssel und die Versionsanforderungen als Wert.

Die Versionsanforderungen kombinieren drei Gruppen von Einschränkungen:
+ Die Versionsanforderungen, die bereits in der vorhandenen Dinggruppe festgelegt sind.
+ Die für die Bereitstellung erforderliche Komponentenversion. Sie müssen eine Komponentenversion auswählen, wenn Sie eine Bereitstellung erstellen oder aktualisieren.
+ Alle Einschränkungen der Komponentenversion, die im Abhängigkeitsabschnitt des Rezepts definiert sind.

### Löst Abhängigkeiten zwischen Komponenten auf
<a name="resolving-dependencies"></a>

Während einer Bereitstellung versucht der Greengrass-Nucleus zunächst, den lokalen Kandidaten zu finden, der derzeit auf dem Gerät läuft, das die Anforderungen erfüllt. Wenn die laufende Komponente die Anforderungen erfüllt, ruft der Nucleus den gespeicherten Rezeptpfad aus dem Rezeptordner ab und sucht im lokalen Speicher nach der neuesten lokalen Version.

[Bei AWS Cloud Bereitstellungen ruft der Nucleus dann die ResolveComponentCandidates API auf.](https://docs.aws.amazon.com/greengrass/v2/APIReference/API_ResolveComponentCandidates.html) Diese API beginnt mit der neuesten verfügbaren Version und prüft, ob sie die Abhängigkeiten und Anforderungen erfüllt. Wenn der Nucleus die Antwort von der API erhält, wählt er die neueste Version aus. Wenn von der keine Version gefunden wird AWS Cloud , die die Anforderungen erfüllt, schlägt die Bereitstellung fehl. Wenn das Gerät offline ist, wird auf den ursprünglich gefundenen lokalen Kandidaten zurückgegriffen. Wenn kein lokaler Kandidat gefunden wird, der die Anforderungen erfüllt, schlägt die Bereitstellung fehl.

Bei lokalen Einsätzen setzt der Nukleus ausschließlich lokale Kandidaten ein, sofern diese vorhanden sind und die Anforderungen erfüllen, ohne mit ihnen zu verhandeln. AWS Cloud Wenn es keinen solchen Kandidaten gibt, schlägt der Einsatz fehl.

**Anmerkung**  
Alle aufgelösten Rezepte werden lokal gespeichert, um später darauf future zu können.

Weitere Informationen finden Sie im Abschnitt zur [Auflösung von Abhängigkeiten](https://github.com/aws-greengrass/aws-greengrass-nucleus/wiki/Deployment#dependency-resolution) unter GitHub.

Wenn der Greengrass-Kern in der Lage ist, alle Komponenten erfolgreich aufzulösen, enthält das Nukleus-Logbuch die folgende Zeile.

```
resolve-all-group-dependencies-finish. Finish resolving all groups dependencies.
```

**Example**  
Im Folgenden finden Sie ein Beispiel dafür, wie der Nucleus die Anforderungen an die Komponenten lösen kann.  
+ Sie stellen ComponentA bereit, das von den ComponentC-Versionen 1.0.0-1.9.0 abhängt.
+ Sie stellen auch Komponente B bereit, die von den ComponentC-Versionen 1.4.0-1.9.5 abhängt.
Bei der Auflösung der Komponentenabhängigkeiten stellt der Nucleus die neueste Version der ComponentC-Version bereit, um die Anforderungen von ComponentA und ComponentB zu erfüllen. Diese neueste Version von ComponentC ist Version 1.9.0.

#### Häufige Fehler bei der Auflösung von Komponentenabhängigkeiten
<a name="w2ab1c24c25b9c11c19"></a>

Die Auflösung von Komponentenabhängigkeiten kann aus zwei Hauptgründen fehlschlagen: Konflikt mit Zielversionsanforderungen oder Konflikt mit Komponentenabhängigkeitsanforderungen.

##### Szenario 1: Konflikt mit den Anforderungen der Zielversion
<a name="w2ab1c24c25b9c11c19b5"></a>
+ Ein Ding ist in einer Dinggruppe vorhanden und Sie möchten dieses Ding auch zu einer neuen Dinggruppe hinzufügen. Die Bereitstellung schlägt fehl, wenn für die neue Dinggruppe eine andere Dingversion erforderlich ist.
+ Eine Bereitstellung kann auch fehlschlagen, wenn ein Ding zu einer Dinggruppe gehört und die Komponentenversion durch eine Dingbereitstellung aktualisiert werden soll.

![\[Abhängigkeiten von Komponenten, die zu einer fehlgeschlagenen Bereitstellung führen.\]](http://docs.aws.amazon.com/de_de/greengrass/v2/developerguide/images/dependency-4.png)


*Beispiel für ein Fehlerprotokoll:*

```
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
```

Die Protokolle deuten auf einen Versionskonfliktfehler hin, da der Nucleus keine Komponentenversion finden kann, die gleichzeitig zwei widersprüchliche Anforderungen erfüllt.

##### Wie kann das Problem gelöst werden
<a name="w2ab1c24c25b9c11c19b5c13"></a>
+ Wenn Sie die Komponente in jeder Dinggruppe behalten möchten, wählen Sie in jeder Dinggruppe dieselbe Version dieser Komponente aus.
+ Wählen Sie eine Komponentenversion aus, die den Bereitstellungsanforderungen entspricht.
+ Wenn Sie eine Komponentenversion verwenden möchten, die nicht beide Dinggruppenanforderungen erfüllt, wählen Sie die Komponentenversion aus, die die Anforderungen an die Dinggruppenversion erfüllt, und verwenden Sie diese Komponente nur in dieser Dinggruppe.

##### Szenario 2: Konflikt zwischen den Versionsanforderungen der Komponentenabhängigkeit
<a name="w2ab1c24c25b9c11c19b7"></a>

Wenn eine Komponente von verschiedenen Komponenten abhängig ist und die Komponenten unterschiedliche Versionen oder unterschiedliche Versionsbereiche dieser Komponente erfordern, besteht die Möglichkeit, dass keine Versionen verfügbar sind, die alle Versionsanforderungen erfüllen. In diesem Szenario schlägt die Bereitstellung fehl.

**Example**  
Bereitstellung von ComponentA (v2.5.0), ComponentB (v1.3.0) und ComponentC (v1.0.0)  
+ ComponentA erfordert ComponentB-Version >=1.0.0.

  ```
  ---
  ...
  ComponentName: ComponentA
  ComponentVersion: "2.5.0"
  ComponentDependencies:
      ComponentB:
          VersionRequirement: ">=1.0.0"
          DependencyType: "HARD"
  ...
  ```
+ ComponentC benötigt ComponentA-Version <2.0.0.

  ```
  ---
  ...
  ComponentName: ComponentC
  ComponentVersion: "1.0.0"
  ComponentDependencies:
      ComponentA:
          VersionRequirement: "<2.0.0"
          DependencyType: "HARD"
  ...
  ```
Es besteht ein Versionskonflikt zwischen zwei Anforderungen für ComponentA:  
+ ComponentA benötigt Version 2.5.0 in dieser Bereitstellung
+ ComponentC benötigt ComponentA-Versionen unter 2.0.0
Diese beiden Anforderungen widersprechen sich gegenseitig und machen es dem Nucleus unmöglich, eine ComponentA-Version zu finden, die beide Anforderungen erfüllt. Daher schlägt die Abhängigkeitsauflösung fehl.

![\[Komponentenabhängigkeiten, die zu einer fehlgeschlagenen Bereitstellung führen.\]](http://docs.aws.amazon.com/de_de/greengrass/v2/developerguide/images/dependency-3.png)


*Beispiel für ein Fehlerprotokoll:*

```
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
```

Aus den Protokollen geht hervor, dass der Nucleus keine Version von ComponentA finden kann, die die folgenden Anforderungen erfüllt.
+ Die Anforderungen für ComponentA müssen exakt Version 2.5.0 (von A) sein. ThingGroup
+ Die Anforderung, mit ComponentC-Versionen unter 2.0.0 zu arbeiten.

##### Wie löst man das
<a name="w2ab1c24c25b9c11c19b7c17"></a>
+ Wenn Sie die Komponente in jeder Dinggruppe behalten möchten, wählen Sie in jeder Dinggruppe dieselbe Version dieser Komponente aus.
+ Wählen Sie eine Komponentenversion aus, die den Bereitstellungsanforderungen entspricht.
+ Wenn Sie eine Komponentenversion verwenden möchten, die nicht beide Dinggruppenanforderungen erfüllt, wählen Sie die Komponentenversion aus, die die Anforderungen an die Dinggruppenversion erfüllt, und verwenden Sie diese Komponente nur in dieser Dinggruppe.

**Tipp**  
Wenn Sie diesen Fehler bei einer der AWS bereitgestellten Komponenten sehen, können Sie ihn beheben, indem Sie die in Konflikt stehenden Komponenten auf die neueste Version aktualisieren.

## Ein Gerät aus einer Dinggruppe entfernen
<a name="thing-group-removal-behavior"></a>

Wenn Sie ein Kerngerät aus einer Dinggruppe entfernen, hängt das Verhalten der Komponentenbereitstellung von der Version des [Greengrass-Nukleus](greengrass-nucleus-component.md) ab, die auf dem Kerngerät ausgeführt wird.

------
#### [ 2.5.1 and later ]

Wenn Sie ein Kerngerät aus einer Dinggruppe entfernen, hängt das Verhalten davon ab, ob die AWS IoT Richtlinie die `greengrass:ListThingGroupsForCoreDevice` Erlaubnis erteilt. Weitere Informationen zu dieser Berechtigung und zu AWS IoT Richtlinien für Kerngeräte finden Sie unter[Geräteauthentifizierung und Autorisierung für AWS IoT Greengrass](device-auth.md).
+ **Wenn die AWS IoT Richtlinie diese Berechtigung gewährt**

  <a name="thing-group-removal-behavior-remove-components"></a>Wenn Sie ein Kerngerät aus einer Dinggruppe entfernen, werden bei der nächsten Bereitstellung auf dem Gerät die Komponenten der Dinggruppe AWS IoT Greengrass entfernt. Wenn eine Komponente auf dem Gerät in der nächsten Bereitstellung enthalten ist, wird diese Komponente nicht vom Gerät entfernt.
+ **Wenn die AWS IoT Richtlinie diese Berechtigung nicht gewährt**

  <a name="thing-group-removal-behavior-no-remove-components"></a>Wenn Sie ein Kerngerät aus einer Dinggruppe entfernen, werden die Komponenten dieser Dinggruppe AWS IoT Greengrass nicht vom Gerät gelöscht.

  <a name="thing-group-removal-behavior-no-remove-components-how-to-remove"></a>Um eine Komponente von einem Gerät zu entfernen, verwenden Sie den Befehl [deployment create](gg-cli-deployment.md#deployment-create) der Greengrass-CLI. Geben Sie die zu entfernende Komponente mit dem `--remove` Argument an und geben Sie die Dinggruppe mit dem `--groupId` Argument an.

------
#### [ 2.5.0 ]

<a name="thing-group-removal-behavior-remove-components"></a>Wenn Sie ein Kerngerät aus einer Dinggruppe entfernen, werden bei der nächsten Bereitstellung auf dem Gerät die Komponenten der Dinggruppe AWS IoT Greengrass entfernt. Wenn eine Komponente auf dem Gerät in der nächsten Bereitstellung enthalten ist, wird diese Komponente nicht vom Gerät entfernt.

Dieses Verhalten setzt voraus, dass die AWS IoT Richtlinie des Kerngeräts die `greengrass:ListThingGroupsForCoreDevice` Genehmigung erteilt. Wenn ein Core-Gerät nicht über diese Berechtigung verfügt, kann das Core-Gerät keine Bereitstellungen anwenden. Weitere Informationen finden Sie unter [Geräteauthentifizierung und Autorisierung für AWS IoT Greengrass](device-auth.md).

------
#### [ 2.0.x - 2.4.x ]

<a name="thing-group-removal-behavior-no-remove-components"></a>Wenn Sie ein Kerngerät aus einer Dinggruppe entfernen, werden die Komponenten dieser Dinggruppe AWS IoT Greengrass nicht vom Gerät gelöscht.

<a name="thing-group-removal-behavior-no-remove-components-how-to-remove"></a>Um eine Komponente von einem Gerät zu entfernen, verwenden Sie den Befehl [deployment create](gg-cli-deployment.md#deployment-create) der Greengrass-CLI. Geben Sie die zu entfernende Komponente mit dem `--remove` Argument an und geben Sie die Dinggruppe mit dem `--groupId` Argument an.

------

## Bereitstellungen
<a name="deployments"></a>

Die Bereitstellungen erfolgen kontinuierlich. Wenn Sie eine Bereitstellung erstellen, wird AWS IoT Greengrass die Bereitstellung auf Zielgeräten bereitgestellt, die online sind. Wenn ein Zielgerät nicht online ist, empfängt es die Bereitstellung, wenn es das nächste Mal eine Verbindung herstellt AWS IoT Greengrass. Wenn Sie einer Ziel-Dinggruppe ein Kerngerät hinzufügen, AWS IoT Greengrass sendet das Gerät die neueste Bereitstellung für diese Dinggruppe.

Bevor ein Kerngerät eine Komponente bereitstellt, benachrichtigt es standardmäßig jede Komponente auf dem Gerät. Greengrass-Komponenten können auf die Benachrichtigung reagieren, um die Bereitstellung zu verzögern. Möglicherweise möchten Sie die Bereitstellung verschieben, wenn der Akkuladestand des Geräts niedrig ist oder ein Prozess läuft, der nicht unterbrochen werden kann. Weitere Informationen finden Sie unter [Tutorial: Entwickeln Sie eine Greengrass-Komponente, die Komponenten-Updates verzögert](defer-component-updates-tutorial.md). Wenn Sie eine Einrichtung erstellen, können Sie sie so konfigurieren, dass sie ohne Benachrichtigung der Komponenten bereitgestellt wird.

Jede Zielsache oder Dinggruppe kann jeweils nur eine Bereitstellung haben. Das heißt, wenn Sie eine Bereitstellung für ein Ziel erstellen, wird die vorherige Version der Bereitstellung dieses Ziels nicht AWS IoT Greengrass mehr bereitgestellt.

## Optionen für die Bereitstellung
<a name="deployment-options"></a>

Bereitstellungen bieten mehrere Optionen, mit denen Sie steuern können, welche Geräte ein Update erhalten und wie das Update bereitgestellt wird. Wenn Sie eine Bereitstellung erstellen, können Sie die folgenden Optionen konfigurieren:
+ **AWS IoT Greengrass Komponenten**

  Definieren Sie die Komponenten, die auf den Zielgeräten installiert und ausgeführt werden sollen. AWS IoT Greengrass Komponenten sind Softwaremodule, die Sie auf Greengrass-Kerngeräten bereitstellen und ausführen. Geräte erhalten Komponenten nur, wenn die Komponente die Plattform des Geräts unterstützt. Auf diese Weise können Sie die Bereitstellung für Gerätegruppen durchführen, auch wenn die Zielgeräte auf mehreren Plattformen ausgeführt werden. Wenn eine Komponente die Plattform des Geräts nicht unterstützt, wird die Komponente nicht auf dem Gerät bereitgestellt.

  Sie können benutzerdefinierte Komponenten und AWS bereitgestellte Komponenten auf Ihren Geräten bereitstellen. Wenn Sie eine Komponente bereitstellen, AWS IoT Greengrass identifiziert es alle Abhängigkeiten der Komponenten und stellt sie ebenfalls bereit. Weitere Informationen erhalten Sie unter [AWS IoT Greengrass Komponenten entwickeln](develop-greengrass-components.md) und [AWS-mitgelieferte Komponenten](public-components.md).

  Sie definieren die Version und das Konfigurationsupdate, das für jede Komponente bereitgestellt werden soll. Das *Konfigurationsupdate* gibt an, wie die bestehende Konfiguration der Komponente auf dem Kerngerät oder die Standardkonfiguration der Komponente geändert werden soll, falls die Komponente auf dem Kerngerät nicht vorhanden ist. Sie können angeben, welche Konfigurationswerte auf die Standardwerte zurückgesetzt werden sollen und welche neuen Konfigurationswerte auf dem Kerngerät zusammengeführt werden sollen. Wenn ein Kerngerät Bereitstellungen für verschiedene Ziele empfängt und in jeder Bereitstellung kompatible Komponentenversionen angegeben sind, wendet das Kerngerät die Konfigurationsupdates in der Reihenfolge an, die auf dem Zeitstempel basiert, zu dem Sie die Bereitstellung erstellt haben. Weitere Informationen finden Sie unter [Komponentenkonfigurationen aktualisieren](update-component-configurations.md).
**Wichtig**  <a name="component-patch-update-note"></a>
<a name="component-patch-update"></a>Wenn Sie eine Komponente bereitstellen, werden die neuesten unterstützten Versionen aller Abhängigkeiten dieser Komponente AWS IoT Greengrass installiert. Aus diesem Grund werden neue Patch-Versionen von AWS bereitgestellten öffentlichen Komponenten möglicherweise automatisch auf Ihren Kerngeräten bereitgestellt, wenn Sie einer Dinggruppe neue Geräte hinzufügen oder wenn Sie die Bereitstellung aktualisieren, die auf diese Geräte abzielt. Einige automatische Updates, wie z. B. ein Nucleus-Update, können dazu führen, dass Ihre Geräte unerwartet neu gestartet werden.   
<a name="component-version-pinning"></a>Um unbeabsichtigte Updates für eine Komponente zu verhindern, die auf Ihrem Gerät ausgeführt wird, empfehlen wir, dass Sie Ihre bevorzugte Version dieser Komponente direkt angeben, wenn Sie [eine Bereitstellung erstellen](create-deployments.md). Weitere Informationen zum Aktualisierungsverhalten der AWS IoT Greengrass Core-Software finden Sie unter[Aktualisieren Sie die AWS IoT Greengrass Core-Software (OTA)](update-greengrass-core-v2.md).
+ **Richtlinien für die Bereitstellung**

  Definieren Sie, wann die Bereitstellung einer Konfiguration sicher ist und was zu tun ist, wenn die Bereitstellung fehlschlägt. Sie können angeben, ob Sie warten möchten, bis die Komponenten melden, dass sie aktualisiert werden können. Sie können auch angeben, ob Geräte auf ihre vorherige Konfiguration zurückgesetzt werden sollen oder nicht, wenn sie eine fehlgeschlagene Bereitstellung anwenden.
+ **Konfiguration beenden**

  Definieren Sie, wann und wie eine Bereitstellung beendet werden soll. Die Bereitstellung wird beendet und schlägt fehl, wenn die von Ihnen definierten Kriterien erfüllt sind. Sie können beispielsweise eine Bereitstellung so konfigurieren, dass sie beendet wird, wenn ein Prozentsatz der Geräte diese Bereitstellung nicht anwendet, nachdem eine Mindestanzahl von Geräten sie erhalten hat.
+ **Rollout-Konfiguration**

  Definieren Sie die Geschwindigkeit, mit der eine Bereitstellung auf den Zielgeräten eingeführt wird. Sie können eine exponentielle Ratenerhöhung mit Mindest- und Höchstratengrenzen konfigurieren.
+ **Timeout-Konfiguration**

  Definieren Sie die maximale Zeit, die jedem Gerät zur Verfügung steht, um eine Bereitstellung anzuwenden. Wenn ein Gerät die von Ihnen angegebene Dauer überschreitet, kann das Gerät die Bereitstellung nicht anwenden.

**Wichtig**  
Benutzerdefinierte Komponenten können Artefakte in S3-Buckets definieren. Wenn die AWS IoT Greengrass Core-Software eine Komponente bereitstellt, lädt sie die Artefakte der Komponente von herunter. AWS Cloud Core-Geräterollen ermöglichen standardmäßig keinen Zugriff auf S3-Buckets. Um benutzerdefinierte Komponenten bereitzustellen, die Artefakte in einem S3-Bucket definieren, muss die Core-Geräterolle Berechtigungen zum Herunterladen von Artefakten aus diesem Bucket gewähren. Weitere Informationen finden Sie unter [Erlauben Sie den Zugriff auf S3-Buckets für Komponentenartefakte](device-service-role.md#device-service-role-access-s3-bucket).

**Topics**
+ [Bereitstellungen von Kerngeräten](#core-device-deployments)
+ [Auflösung der Plattformabhängigkeit](#platform-dependency-resolution)
+ [Auflösung der Abhängigkeit von Komponenten](#component-dependency-resolution)
+ [Ein Gerät aus einer Dinggruppe entfernen](#thing-group-removal-behavior)
+ [Bereitstellungen](#deployments)
+ [Optionen für die Bereitstellung](#deployment-options)
+ [Erstellen von Bereitstellungen](create-deployments.md)
+ [Unterbereitstellungen erstellen](create-subdeployments.md)
+ [Bereitstellungen überarbeiten](revise-deployments.md)
+ [Bereitstellungen stornieren](cancel-deployments.md)
+ [Überprüfen Sie den Bereitstellungsstatus](check-deployment-status.md)

# Erstellen von Bereitstellungen
<a name="create-deployments"></a>

Sie können eine Bereitstellung erstellen, die auf ein Ding oder eine Dinggruppe abzielt.

Wenn Sie eine Bereitstellung erstellen, konfigurieren Sie die Softwarekomponenten, die bereitgestellt werden sollen, und die Art und Weise, wie der Bereitstellungsauftrag auf den Zielgeräten ausgeführt wird. Sie können die Bereitstellung in der JSON-Datei definieren, die Sie dem zur Verfügung stellen AWS CLI.

Das Bereitstellungsziel bestimmt die Geräte, auf denen Sie Ihre Komponenten ausführen möchten. Um die Bereitstellung auf einem Kerngerät durchzuführen, geben Sie eine Sache an. Um die Bereitstellung auf mehreren Kerngeräten durchzuführen, geben Sie eine Dinggruppe an, die diese Geräte umfasst. Weitere Informationen zur Konfiguration von Dinggruppen finden Sie unter [Statische Dinggruppen](https://docs.aws.amazon.com/iot/latest/developerguide/thing-groups.html) und [Dynamische Dinggruppen](https://docs.aws.amazon.com/iot/latest/developerguide/dynamic-thing-groups.html) im *AWS IoT Entwicklerhandbuch*.

Folgen Sie den Schritten in diesem Abschnitt, um eine Bereitstellung für ein Ziel zu erstellen. Weitere Informationen zum Aktualisieren der Softwarekomponenten auf einem Ziel, das über eine Bereitstellung verfügt, finden Sie unter[Bereitstellungen überarbeiten](revise-deployments.md).

**Warnung**  
Bei [CreateDeployment](https://docs.aws.amazon.com/greengrass/v2/APIReference/API_CreateDeployment.html)diesem Vorgang können Komponenten von Kerngeräten deinstalliert werden. Wenn eine Komponente in der vorherigen Bereitstellung und nicht in der neuen Bereitstellung vorhanden ist, deinstalliert das Kerngerät diese Komponente. Um die Deinstallation von Komponenten zu vermeiden, überprüfen Sie anhand des [ListDeployments](https://docs.aws.amazon.com/greengrass/v2/APIReference/API_ListDeployments.html)Vorgangs zunächst, ob das Ziel für die Bereitstellung bereits über eine vorhandene Bereitstellung verfügt. Verwenden Sie dann den [GetDeployment](https://docs.aws.amazon.com/greengrass/v2/APIReference/API_GetDeployment.html)Vorgang, um mit dieser vorhandenen Bereitstellung zu beginnen, wenn Sie eine neue Bereitstellung erstellen.

**Um eine Bereitstellung zu erstellen (AWS CLI)**

1. Erstellen Sie eine Datei mit dem Namen `deployment.json` und kopieren Sie dann das folgende JSON-Objekt in die Datei. *targetArn*Ersetzen Sie es durch den ARN des Dings AWS IoT oder der Dinggruppe, auf die die Bereitstellung ausgerichtet werden soll. Ding und Dinggruppe ARNs haben das folgende Format:
   + Objekt: `arn:aws:iot:region:account-id:thing/thingName`
   + Objektgruppe: `arn:aws:iot:region:account-id:thinggroup/thingGroupName`

   ```
   {
     "targetArn": "targetArn"
   }
   ```

1. Prüfen Sie, ob das Bereitstellungsziel über eine bestehende Bereitstellung verfügt, die Sie überarbeiten möchten. Gehen Sie wie folgt vor:

   1. <a name="revise-deployment-list-deployments-intro"></a>Führen Sie den folgenden Befehl aus, um die Bereitstellungen für das Bereitstellungsziel aufzulisten. Ersetze es *targetArn* durch den ARN der AWS IoT Zielsache oder der Ziel-Dinggruppe.

      ```
      aws greengrassv2 list-deployments --target-arn targetArn
      ```

      Die Antwort enthält eine Liste mit der neuesten Bereitstellung für das Ziel. Wenn die Antwort leer ist, verfügt das Ziel nicht über eine bestehende Bereitstellung, und Sie können zu wechseln[Step 3](#create-deployment-define-name-step). Andernfalls kopieren Sie die `deploymentId` aus der Antwort, um sie im nächsten Schritt zu verwenden.
**Anmerkung**  <a name="revise-deployment-list-deployments-revision-note"></a>
Sie können auch eine andere Bereitstellung als die neueste Version für das Ziel überarbeiten. Geben Sie das `--history-filter ALL` Argument an, um alle Bereitstellungen für das Ziel aufzulisten. Kopieren Sie dann die ID der Bereitstellung, die Sie überarbeiten möchten.

   1. <a name="revise-deployment-get-deployment"></a>Führen Sie den folgenden Befehl aus, um die Details der Bereitstellung abzurufen. Zu diesen Details gehören Metadaten, Komponenten und Auftragskonfiguration. *deploymentId*Ersetzen Sie es durch die ID aus dem vorherigen Schritt.

      ```
      aws greengrassv2 get-deployment --deployment-id deploymentId
      ```

      Die Antwort enthält die Details der Bereitstellung.

   1. Kopieren Sie eines der folgenden Schlüssel-Wert-Paare aus der Antwort des vorherigen Befehls in. `deployment.json` Sie können diese Werte für die neue Bereitstellung ändern.
      + `deploymentName`— Der Name der Bereitstellung.
      + `components`— Die Komponenten der Bereitstellung. Um eine Komponente zu deinstallieren, entfernen Sie sie aus diesem Objekt.
      + `deploymentPolicies`— Die Richtlinien der Bereitstellung.
      + `iotJobConfiguration`— Die Jobkonfiguration der Bereitstellung.
      + `tags`— Die Tags der Bereitstellung.

1. <a name="create-deployment-define-name-step"></a>(Optional) Definieren Sie einen Namen für die Bereitstellung. *deploymentName*Ersetzen Sie ihn durch den Namen der Bereitstellung.

   ```
   {
     "targetArn": "targetArn",
     "deploymentName": "deploymentName"
   }
   ```

1. Fügen Sie jede Komponente hinzu, um die Zielgeräte bereitzustellen. Fügen Sie dazu dem `components` Objekt Schlüssel-Wert-Paare hinzu, wobei der Schlüssel der Komponentenname und der Wert ein Objekt ist, das die Details für diese Komponente enthält. Geben Sie für jede Komponente, die Sie hinzufügen, die folgenden Details an:
   + `version`— Die bereitzustellende Komponentenversion.
   + `configurationUpdate`— Das [bereitzustellende Konfigurationsupdate](update-component-configurations.md). Das Update ist ein Patch-Vorgang, der die bestehende Konfiguration der Komponente auf jedem Zielgerät oder die Standardkonfiguration der Komponente ändert, falls sie auf dem Zielgerät nicht vorhanden ist. Sie können die folgenden Konfigurationsupdates angeben:
     + Updates zurücksetzen (`reset`) — (Optional) Eine Liste von JSON-Zeigern, die die Konfigurationswerte definieren, die auf dem Zielgerät auf ihre Standardwerte zurückgesetzt werden sollen. Die AWS IoT Greengrass Core-Software wendet Reset-Updates an, bevor sie Merge-Updates anwendet. Weitere Informationen finden Sie unter [Updates zurücksetzen](update-component-configurations.md#reset-configuration-update).
     + Updates zusammenführen (`merge`) — (Optional) Ein JSON-Dokument, das die Konfigurationswerte definiert, die auf dem Zielgerät zusammengeführt werden sollen. Sie müssen das JSON-Dokument als Zeichenfolge serialisieren. Weitere Informationen finden Sie unter [Updates zusammenführen](update-component-configurations.md#merge-configuration-update).
   + <a name="component-run-with-config"></a>`runWith`— (Optional) Die Systemprozessoptionen, die die AWS IoT Greengrass Core-Software verwendet, um die Prozesse dieser Komponente auf dem Core-Gerät auszuführen. Wenn Sie einen Parameter im `runWith` Objekt weglassen, verwendet die AWS IoT Greengrass Core-Software die Standardwerte, die Sie für die [Greengrass Nucleus-Komponente](greengrass-nucleus-component.md) konfigurieren.

     Sie können eine der folgenden Optionen angeben:
     + `posixUser`— Der POSIX-Systembenutzer und optional die Gruppe, die verwendet werden sollen, um diese Komponente auf Linux-Kerngeräten auszuführen. Der Benutzer und die Gruppe, falls angegeben, müssen auf jedem Linux-Core-Gerät vorhanden sein. Geben Sie den Benutzer und die Gruppe durch einen Doppelpunkt (`:`) getrennt im folgenden Format an: `user:group`. Die Gruppe ist optional. Wenn Sie keine Gruppe angeben, verwendet die AWS IoT Greengrass Core-Software die primäre Gruppe für den Benutzer. Weitere Informationen finden Sie unter [Konfigurieren Sie den Benutzer, der die Komponenten ausführt](configure-greengrass-core-v2.md#configure-component-user).
     + `windowsUser`— Der Windows-Benutzer, der für die Ausführung dieser Komponente auf Windows Core-Geräten verwendet werden soll. Der Benutzer muss auf jedem Windows Core-Gerät vorhanden sein, und sein Name und Passwort müssen in der Credentials Manager-Instanz des LocalSystem Kontos gespeichert sein. Weitere Informationen finden Sie unter [Konfigurieren Sie den Benutzer, der die Komponenten ausführt](configure-greengrass-core-v2.md#configure-component-user).

       Diese Funktion ist für Version 2.5.0 und höher der [Greengrass](greengrass-nucleus-component.md) Nucleus-Komponente verfügbar.
     + `systemResourceLimits`— Die Systemressourcenlimits, die für die Prozesse dieser Komponente gelten sollen. Sie können Systemressourcenlimits auf generische und nicht containerisierte Lambda-Komponenten anwenden. Weitere Informationen finden Sie unter [Konfigurieren Sie die Systemressourcenlimits für Komponenten](configure-greengrass-core-v2.md#configure-component-system-resource-limits).

       Sie können eine der folgenden Optionen angeben:
       + `cpus`— <a name="system-resource-limits-cpu-definition-this"></a>Die maximale Menge an CPU-Zeit, die die Prozesse dieser Komponente auf dem Kerngerät verwenden können. Die gesamte CPU-Zeit eines Core-Geräts entspricht der Anzahl der CPU-Kerne des Geräts. Auf einem Core-Gerät mit 4 CPU-Kernen können Sie diesen Wert beispielsweise auf festlegen, `2` um die Prozesse dieser Komponente auf 50 Prozent der Auslastung jedes CPU-Kerns zu beschränken. Auf einem Gerät mit einem CPU-Kern können Sie diesen Wert auf festlegen, `0.25` um die Prozesse dieser Komponente auf 25 Prozent der CPU-Auslastung zu beschränken. Wenn Sie diesen Wert auf eine Zahl festlegen, die größer als die Anzahl der CPU-Kerne ist, begrenzt die AWS IoT Greengrass Core-Software die CPU-Auslastung der Komponente nicht. 
       + `memory`— <a name="system-resource-limits-memory-definition-this"></a>Die maximale Menge an RAM (in Kilobyte), die die Prozesse dieser Komponente auf dem Kerngerät verwenden können. 

       Diese Funktion ist für Version 2.4.0 und höher der [Greengrass](greengrass-nucleus-component.md) Nucleus-Komponente verfügbar. AWS IoT Greengrass unterstützt diese Funktion derzeit nicht auf Windows Core-Geräten. 

      
**Example Beispiel für ein Update der Grundkonfiguration**  

   Das folgende `components` Beispielobjekt gibt an, dass eine Komponente bereitgestellt werden soll`com.example.PythonRuntime`, die einen Konfigurationsparameter mit dem Namen erwartet`pythonVersion`.

   ```
   {
     "targetArn": "targetArn",
     "deploymentName": "deploymentName",
     "components": {
       "com.example.PythonRuntime": {
         "componentVersion": "1.0.0",
         "configurationUpdate": {
           "merge": "{\"pythonVersion\":\"3.7\"}"
         }
       }
     }
   }
   ```  
**Example Beispiel für ein Konfigurationsupdate mit Updates zum Zurücksetzen und Zusammenführen**  

   Stellen Sie sich ein Beispiel für eine industrielle Dashboard-Komponente vor`com.example.IndustrialDashboard`, die die folgende Standardkonfiguration hat.

   ```
   {
     "name": null,
     "mode": "REQUEST",
     "network": {
       "useHttps": true,
       "port": {
         "http": 80,
         "https": 443
       },
     },
     "tags": []
   }
   ```

   Das folgende Konfigurationsupdate spezifiziert die folgenden Anweisungen:

   1. Setzen Sie die HTTPS-Einstellung auf ihren Standardwert zurück (`true`).

   1. Setzt die Liste der Industrietags auf eine leere Liste zurück.

   1. Führen Sie eine Liste von Industriekennzeichnungen zusammen, die Temperatur- und Druckdatenströme für zwei Kessel identifizieren.

   ```
   {
     "reset": [
       "/network/useHttps",
       "/tags"
     ],
     "merge": {
       "tags": [
         "/boiler/1/temperature",
         "/boiler/1/pressure",
         "/boiler/2/temperature",
         "/boiler/2/pressure"
       ]
     }
   }
   ```

   Das folgende `components` Beispielobjekt gibt an, dass diese industrielle Dashboard-Komponente und das Konfigurationsupdate bereitgestellt werden sollen.

   ```
   {
     "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. (Optional) Definieren Sie Bereitstellungsrichtlinien für die Bereitstellung. Sie können konfigurieren, wann Kerngeräte eine Bereitstellung sicher anwenden können oder was zu tun ist, wenn ein Kerngerät die Bereitstellung nicht anwendet. Fügen Sie dazu ein `deploymentPolicies` Objekt hinzu `deployment.json` und führen Sie dann einen der folgenden Schritte aus:

   1. (Optional) Geben Sie die Richtlinie für das Komponenten-Update an (`componentUpdatePolicy`). Diese Richtlinie definiert, ob die Bereitstellung es Komponenten ermöglicht, ein Update aufzuschieben, bis sie zur Aktualisierung bereit sind. Beispielsweise müssen Komponenten möglicherweise Ressourcen bereinigen oder wichtige Aktionen abschließen, bevor sie neu gestartet werden können, um ein Update zu installieren. Diese Richtlinie legt auch fest, wie lange Komponenten Zeit haben, um auf eine Aktualisierungsbenachrichtigung zu reagieren.

      Diese Richtlinie ist ein Objekt mit den folgenden Parametern:
      + `action`— (Optional) Ob Komponenten benachrichtigt und darauf gewartet werden sollen, dass sie melden, wenn sie zur Aktualisierung bereit sind. Wählen Sie aus den folgenden Optionen aus:
        + `NOTIFY_COMPONENTS` – Die Bereitstellung benachrichtigt jede Komponente, bevor diese Komponente gestoppt und aktualisiert wird. Komponenten können den [SubscribeToComponentUpdates](ipc-component-lifecycle.md#ipc-operation-subscribetocomponentupdates) IPC-Vorgang verwenden, um diese Benachrichtigungen zu empfangen.
        + `SKIP_NOTIFY_COMPONENTS` – Die Bereitstellung benachrichtigt die Komponenten nicht und wartet nicht darauf, dass sie sicher aktualisiert werden können.

        Standardeinstellung: `NOTIFY_COMPONENTS`.
      + `timeoutInSeconds`Die Zeit in Sekunden, die jede Komponente benötigt, um auf eine Aktualisierungsbenachrichtigung mit dem [DeferComponentUpdate](ipc-component-lifecycle.md#ipc-operation-defercomponentupdate) IPC-Vorgang zu reagieren. Wenn die Komponente innerhalb dieser Zeit nicht reagiert, wird die Bereitstellung auf dem Kerngerät fortgesetzt.

        Die Standardeinstellung ist 60 Sekunden.

   1. (Optional) Geben Sie die Richtlinie zur Konfigurationsvalidierung an (`configurationValidationPolicy`). Diese Richtlinie definiert, wie lange jede Komponente Zeit hat, um ein Konfigurationsupdate aus einer Bereitstellung zu validieren. Komponenten können den [SubscribeToValidateConfigurationUpdates](ipc-component-configuration.md#ipc-operation-subscribetovalidateconfigurationupdates) IPC-Vorgang verwenden, um Benachrichtigungen für ihre eigenen Konfigurationsupdates zu abonnieren. Anschließend können die Komponenten den [SendConfigurationValidityReport](ipc-component-configuration.md#ipc-operation-sendconfigurationvalidityreport) IPC-Vorgang verwenden, um der AWS IoT Greengrass Core-Software mitzuteilen, ob das Konfigurationsupdate gültig ist. Wenn das Konfigurationsupdate nicht gültig ist, schlägt die Bereitstellung fehl.

      Diese Richtlinie ist ein Objekt mit dem folgenden Parameter:
      + `timeoutInSeconds`(Optional) Die Zeit in Sekunden, die jeder Komponente zur Verfügung steht, um ein Konfigurationsupdate zu validieren. Wenn die Komponente innerhalb dieser Zeit nicht reagiert, wird die Bereitstellung auf dem Kerngerät fortgesetzt.

        Die Standardeinstellung ist 30 Sekunden.

   1. (Optional) Geben Sie die Richtlinie zur Fehlerbehandlung an (`failureHandlingPolicy`). Diese Richtlinie ist eine Zeichenfolge, die definiert, ob Geräte zurückgesetzt werden sollen, falls die Bereitstellung fehlschlägt. Wählen Sie aus den folgenden Optionen aus:
      + `ROLLBACK`— Wenn die Bereitstellung auf einem Kerngerät fehlschlägt, setzt die AWS IoT Greengrass Core-Software dieses Kerngerät auf die vorherige Konfiguration zurück.
      + `DO_NOTHING`— Wenn die Bereitstellung auf einem Kerngerät fehlschlägt, behält die AWS IoT Greengrass Core-Software die neue Konfiguration bei. Dies kann zu defekten Komponenten führen, wenn die neue Konfiguration nicht gültig ist.

      Standardeinstellung: `ROLLBACK`.

   Ihre Bereitstellung in `deployment.json` könnte dem folgenden Beispiel ähneln:

   ```
   {
     "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. (Optional) Definieren Sie, wie die Bereitstellung beendet, eingeführt oder wie das Timeout abläuft. AWS IoT Greengrass verwendet AWS IoT Core Jobs, um Bereitstellungen an Kerngeräte zu senden, sodass diese Optionen mit den Konfigurationsoptionen für AWS IoT Core Jobs identisch sind. Weitere Informationen finden Sie unter [Job-Rollout und Konfiguration abbrechen](https://docs.aws.amazon.com/iot/latest/developerguide/job-rollout-abort.html) im *AWS IoT Developer* Guide.

   Um die Joboptionen zu definieren, fügen Sie ein `iotJobConfiguration` Objekt hinzu. `deployment.json` Definieren Sie dann die zu konfigurierenden Optionen.

   Ihre Bereitstellung in `deployment.json` könnte dem folgenden Beispiel ähneln:

   ```
   {
     "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. (Optional) Fügen Sie Tags (`tags`) für die Bereitstellung hinzu. Weitere Informationen finden Sie unter [Kennzeichnen Sie Ihre AWS IoT Greengrass Version 2 Ressourcen](tag-resources.md).

1. Führen Sie den folgenden Befehl aus, um die Bereitstellung von zu erstellen`deployment.json`.

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

   <a name="check-new-deployment-status"></a>Die Antwort enthält eine`deploymentId`, die diese Bereitstellung identifiziert. Sie können die Bereitstellungs-ID verwenden, um den Status der Bereitstellung zu überprüfen. Weitere Informationen finden Sie unter [Überprüfen Sie den Bereitstellungsstatus](check-deployment-status.md#check-cloud-deployment-status).

# Komponentenkonfigurationen aktualisieren
<a name="update-component-configurations"></a>

Komponentenkonfigurationen sind JSON-Objekte, die die Parameter für jede Komponente definieren. Das Rezept jeder Komponente definiert ihre Standardkonfiguration, die Sie ändern, wenn Sie Komponenten auf Kerngeräten bereitstellen.

Wenn Sie eine Bereitstellung erstellen, können Sie das *Konfigurationsupdate* angeben, das für jede Komponente angewendet werden soll. Konfigurationsupdates sind Patch-Operationen, was bedeutet, dass das Update die Komponentenkonfiguration ändert, die auf dem Kerngerät vorhanden ist. Wenn das Kerngerät nicht über die Komponente verfügt, ändert das Konfigurationsupdate die Standardkonfiguration für diese Bereitstellung und wendet sie an.

Das Konfigurationsupdate definiert das *Zurücksetzen* von Updates und das *Zusammenführen* von Updates. Beim Zurücksetzen von Updates wird definiert, welche Konfigurationswerte auf ihre Standardwerte zurückgesetzt oder entfernt werden sollen. Merge-Updates definieren die neuen Konfigurationswerte, die für die Komponente festgelegt werden sollen. Wenn Sie ein Konfigurationsupdate bereitstellen, führt die AWS IoT Greengrass Core-Software das Reset-Update vor dem Merge-Update aus.

Komponenten können die von Ihnen bereitgestellten Konfigurationsupdates validieren. Die Komponente abonniert den Empfang einer Benachrichtigung, wenn eine Bereitstellung ihre Konfiguration ändert, und sie kann eine Konfiguration ablehnen, die sie nicht unterstützt. Weitere Informationen finden Sie unter [Interagieren Sie mit der Komponentenkonfiguration](ipc-component-configuration.md).

**Topics**
+ [Updates zurücksetzen](#reset-configuration-update)
+ [Updates zusammenführen](#merge-configuration-update)
+ [Beispiele](#configuration-update-example)

## Updates zurücksetzen
<a name="reset-configuration-update"></a>

Beim Zurücksetzen von Updates wird definiert, welche Konfigurationswerte auf dem Kerngerät auf ihre Standardwerte zurückgesetzt werden sollen. Wenn ein Konfigurationswert keinen Standardwert hat, entfernt das Reset-Update diesen Wert aus der Konfiguration der Komponente. Dies kann Ihnen helfen, eine Komponente zu reparieren, die aufgrund einer ungültigen Konfiguration kaputt geht.

Verwenden Sie eine Liste von JSON-Zeigern, um zu definieren, welche Konfigurationswerte zurückgesetzt werden sollen. JSON-Zeiger beginnen mit einem Schrägstrich. `/` Um einen Wert in einer verschachtelten Komponentenkonfiguration zu identifizieren, verwenden Sie Schrägstriche (`/`), um die Schlüssel für jede Ebene in der Konfiguration voneinander zu trennen. Weitere Informationen finden Sie in der [JSON-Zeigerspezifikation](https://tools.ietf.org/html/rfc6901).

**Anmerkung**  
Sie können nur eine gesamte Liste auf ihre Standardwerte zurücksetzen. Sie können das Zurücksetzen von Aktualisierungen nicht verwenden, um ein einzelnes Element in einer Liste zurückzusetzen. 

Um die gesamte Konfiguration einer Komponente auf ihre Standardwerte zurückzusetzen, geben Sie eine einzelne leere Zeichenfolge als Reset-Update an.

```
"reset": [""]
```

## Updates zusammenführen
<a name="merge-configuration-update"></a>

Merge-Updates definieren die Konfigurationswerte, die in die Komponentenkonfiguration auf dem Core eingefügt werden sollen. Das Merge-Update ist ein JSON-Objekt, das die AWS IoT Greengrass Core-Software zusammenführt, nachdem sie die Werte in den Pfaden zurückgesetzt hat, die Sie im Reset-Update angegeben haben. Wenn Sie das AWS CLI oder verwenden AWS SDKs, müssen Sie dieses JSON-Objekt als Zeichenfolge serialisieren.

Sie können ein Schlüssel-Wert-Paar zusammenführen, das in der Standardkonfiguration der Komponente nicht vorhanden ist. Sie können auch ein Schlüssel-Wert-Paar zusammenführen, das einen anderen Typ hat als der Wert mit demselben Schlüssel. Der neue Wert ersetzt den alten Wert. Das bedeutet, dass Sie die Struktur des Konfigurationsobjekts ändern können.

Sie können Nullwerte und leere Zeichenketten, Listen und Objekte zusammenführen.

**Anmerkung**  
Sie können das Zusammenführen von Aktualisierungen nicht dazu verwenden, ein Element in eine Liste einzufügen oder an sie anzuhängen. Sie können eine gesamte Liste ersetzen oder ein Objekt definieren, bei dem jedes Element einen eindeutigen Schlüssel hat.  
<a name="configuration-value-type-note"></a>AWS IoT Greengrass verwendet JSON für Konfigurationswerte. JSON spezifiziert einen Zahlentyp, unterscheidet aber nicht zwischen Ganzzahlen und Gleitkommazahlen. Aus diesem Grund können Konfigurationswerte in Fließkommazahlen umgewandelt werden. AWS IoT Greengrass Um sicherzustellen, dass Ihre Komponente den richtigen Datentyp verwendet, empfehlen wir, numerische Konfigurationswerte als Zeichenfolgen zu definieren. Lassen Sie Ihre Komponente sie dann als Ganzzahlen oder Gleitkommazahlen analysieren. Dadurch wird sichergestellt, dass Ihre Konfigurationswerte in der Konfiguration und auf Ihrem Kerngerät denselben Typ haben.

### Verwenden Sie Rezeptvariablen bei Merge-Updates
<a name="merge-configuration-update-recipe-variables"></a>

Diese Funktion ist für Version 2.6.0 und höher der [Greengrass](greengrass-nucleus-component.md) Nucleus-Komponente verfügbar.

Wenn Sie die [interpolateComponentConfiguration](greengrass-nucleus-component.md#greengrass-nucleus-component-configuration-interpolate-component-configuration)Konfigurationsoption von Greengrass Nucleus auf setzen`true`, können Sie in Merge-Updates andere Rezeptvariablen als die `component_dependency_name:configuration:json_pointer` Rezeptvariable verwenden. Beispielsweise können Sie die `{iot:thingName}` Rezeptvariable in einem Merge-Update verwenden, um den Ding-Namen des AWS IoT Kerngeräts in einen Komponentenkonfigurationswert aufzunehmen, z. B. in eine [IPC-Autorisierungsrichtlinie (Interprocess Communication)](interprocess-communication.md#ipc-authorization-policies).

## Beispiele
<a name="configuration-update-example"></a>

Das folgende Beispiel zeigt Konfigurationsupdates für eine Dashboard-Komponente mit der folgenden Standardkonfiguration. Diese Beispielkomponente zeigt Informationen über Industrieanlagen an.

```
{
  "name": null,
  "mode": "REQUEST",
  "network": {
    "useHttps": true,
    "port": {
      "http": 80,
      "https": 443
    },
  },
  "tags": []
}
```

### Rezept für industrielle Armaturenbrettkomponenten
<a name="w2ab1c24c25c22c16c17b7b1"></a>

------
#### [ 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 Beispiel 1: Update zusammenführen**  
Sie erstellen eine Einrichtung, die das folgende Konfigurationsupdate anwendet, das ein Merge-Update, aber kein Reset-Update spezifiziert. Dieses Konfigurationsupdate weist die Komponente an, das Dashboard auf dem HTTP-Port 8080 mit Daten von zwei Boilern anzuzeigen.    
**Konfiguration zum Zusammenführen**  

```
{
  "name": "Factory 2A",
  "network": {
    "useHttps": false,
    "port": {
      "http": 8080
    }
  },
  "tags": [
    "/boiler/1/temperature",
    "/boiler/1/pressure",
    "/boiler/2/temperature",
    "/boiler/2/pressure"
  ]
}
```
Der folgende Befehl erstellt eine Bereitstellung auf einem Kerngerät.  

```
aws greengrassv2 create-deployment --cli-input-json file://dashboard-deployment.json
```
Die `dashboard-deployment.json` Datei enthält das folgende JSON-Dokument.  

```
{
  "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\"]}"
      }
    }
  }
}
```
Der folgende [Greengrass-CLI-Befehl](greengrass-cli-component.md) erstellt eine lokale Bereitstellung auf einem Core-Gerät.  

```
sudo greengrass-cli deployment create \
  --recipeDir recipes \
  --artifactDir artifacts \
  --merge "com.example.IndustrialDashboard=1.0.0" \
  --update-config dashboard-configuration.json
```
Die `dashboard-configuration.json` Datei enthält das folgende JSON-Dokument.  

```
{
  "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"
      ]
    }
  }
}
```
Nach diesem Update hat die Dashboard-Komponente die folgende Konfiguration.  

```
{
  "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 Beispiel 2: Updates zurücksetzen und zusammenführen**  
Anschließend erstellen Sie eine Einrichtung, die das folgende Konfigurationsupdate anwendet, das ein Reset-Update und ein Merge-Update spezifiziert. Diese Updates spezifizieren, dass das Dashboard auf dem Standard-HTTPS-Port mit Daten von verschiedenen Kesseln angezeigt wird. Diese Updates ändern die Konfiguration, die sich aus den Konfigurationsupdates im vorherigen Beispiel ergibt.    
**Pfade zurücksetzen**  

```
[
  "/network/useHttps",
  "/tags"
]
```  
**Konfiguration zum Zusammenführen**  

```
{
  "tags": [
    "/boiler/3/temperature",
    "/boiler/3/pressure",
    "/boiler/4/temperature",
    "/boiler/4/pressure"
  ]
}
```
Der folgende Befehl erstellt eine Bereitstellung auf einem Kerngerät.  

```
aws greengrassv2 create-deployment --cli-input-json file://dashboard-deployment2.json
```
Die `dashboard-deployment2.json` Datei enthält das folgende JSON-Dokument.  

```
{
  "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\"]}"
      }
    }
  }
}
```
Der folgende [Greengrass-CLI-Befehl](greengrass-cli-component.md) erstellt eine lokale Bereitstellung auf einem Core-Gerät.  

```
sudo greengrass-cli deployment create \
  --recipeDir recipes \
  --artifactDir artifacts \
  --merge "com.example.IndustrialDashboard=1.0.0" \
  --update-config dashboard-configuration2.json
```
Die `dashboard-configuration2.json` Datei enthält das folgende JSON-Dokument.  

```
{
  "com.example.IndustrialDashboard": {
    "RESET": [
      "/network/useHttps",
      "/tags"
    ],
    "MERGE": {
      "tags": [
        "/boiler/3/temperature",
        "/boiler/3/pressure",
        "/boiler/4/temperature",
        "/boiler/4/pressure"
      ]
    }
  }
}
```
Nach diesem Update hat die Dashboard-Komponente die folgende Konfiguration.  

```
{
  "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",
  ]
}
```

# Unterbereitstellungen erstellen
<a name="create-subdeployments"></a>

**Anmerkung**  
Die Subdeployment-Funktion ist in Greengrass Nucleus Version 2.9.0 und höher verfügbar. Es ist nicht möglich, eine Konfiguration für eine Unterbereitstellung mit früheren Komponentenversionen von Greengrass Nucleus bereitzustellen.

Eine Unterbereitstellung ist eine Bereitstellung, die auf eine kleinere Teilmenge von Geräten innerhalb einer übergeordneten Bereitstellung abzielt. Sie können Unterbereitstellungen verwenden, um eine Konfiguration für eine kleinere Teilmenge von Geräten bereitzustellen. Sie können auch Unterbereitstellungen erstellen, um eine fehlgeschlagene übergeordnete Bereitstellung erneut zu versuchen, wenn ein oder mehrere Geräte in dieser übergeordneten Bereitstellung ausfallen. Mit dieser Funktion können Sie Geräte auswählen, die in dieser übergeordneten Bereitstellung ausgefallen sind, und eine Unterbereitstellung erstellen, um Konfigurationen zu testen, bis die Unterbereitstellung erfolgreich ist. Sobald die Unterbereitstellung erfolgreich ist, können Sie diese Konfiguration erneut für die übergeordnete Bereitstellung bereitstellen.

Folgen Sie den Schritten in diesem Abschnitt, um eine Unterbereitstellung zu erstellen und ihren Status zu überprüfen. Weitere Informationen zum Erstellen von Bereitstellungen finden Sie unter Bereitstellungen [erstellen](https://docs.aws.amazon.com/greengrass/v2/developerguide/create-deployments.html).

**So erstellen Sie eine Unterbereitstellung ()AWS CLI**

1. <a name="create-subdeployments-step1"></a>Führen Sie den folgenden Befehl aus, um die neuesten Bereitstellungen für eine Dinggruppe abzurufen. Ersetzen Sie den ARN im Befehl durch den ARN der abzufragenden Dinggruppe. Stellen Sie `--history-filter` auf **LATEST\$1ONLY** ein, um die neueste Bereitstellung dieser Dinggruppe zu sehen.

   ```
   aws greengrassv2 list-deployments --target-arn arn:aws:iot:region:account-id:thinggroup/thingGroupName --history-filter LATEST_ONLY
   ```

1. Kopieren Sie den `deploymentId` aus der Antwort in den **list-deployments** Befehl, um ihn im nächsten Schritt zu verwenden.

1. Führen Sie den folgenden Befehl aus, um den Status einer Bereitstellung abzurufen. `deploymentId`Ersetzen Sie ihn durch die ID der Bereitstellung, die abgefragt werden soll.

   ```
   aws greengrassv2 get-deployment --deployment-id deploymentId
   ```

1. Kopieren Sie den `iotJobId` aus der Antwort in den **get-deployment** Befehl, der im folgenden Schritt verwendet werden soll.

1. Führen Sie den folgenden Befehl aus, um die Liste der Auftragsausführungen für den angegebenen Job abzurufen. *jobID*Ersetzen Sie durch den `iotJobId` aus dem vorherigen Schritt. *status*Ersetzen Sie durch den Status, nach dem Sie filtern möchten. Sie können Ergebnisse mit den folgenden Status filtern:
   + `QUEUED`
   + `IN_PROGRESS`
   + `SUCCEEDED`
   + `FAILED`
   + `TIMED_OUT`
   + `REJECTED`
   + `REMOVED`
   + `CANCELED`

   ```
   aws iot list-job-executions-for-job --job-id jobID --status status
   ```

1. Erstellen Sie eine neue AWS IoT Dinggruppe oder verwenden Sie eine vorhandene Dinggruppe für Ihre Unterbereitstellung. Fügen Sie dann dieser Dinggruppe ein AWS IoT Ding hinzu. Sie verwenden Dinggruppen, um Flotten von Greengrass-Kerngeräten zu verwalten. Wenn Sie Softwarekomponenten auf Ihren Geräten bereitstellen, können Sie entweder einzelne Geräte oder Gerätegruppen als Ziel auswählen. Sie können ein Gerät zu einer Dinggruppe mit einer aktiven Greengrass-Bereitstellung hinzufügen. Nach dem Hinzufügen können Sie dann die Softwarekomponenten dieser Dinggruppe auf diesem Gerät bereitstellen.

   Gehen Sie wie folgt vor, um eine neue Dinggruppe zu erstellen und ihr Ihre Geräte hinzuzufügen:

   1. Erstelle eine AWS IoT Dinggruppe. *MyGreengrassCoreGroup*Ersetzen Sie durch den Namen für die neue Dinggruppe. Sie können keinen Doppelpunkt (:) in einem Dinggruppennamen verwenden.
**Anmerkung**  
Wenn eine Dinggruppe für eine Unterbereitstellung zusammen mit einer anderen Gruppe verwendet wird`parentTargetArn`, kann sie nicht mit einer anderen übergeordneten Flotte wiederverwendet werden. Wenn eine Dinggruppe bereits verwendet wurde, um eine Unterbereitstellung für eine andere Flotte zu erstellen, gibt die API einen Fehler zurück.

      ```
      aws iot create-thing-group --thing-group-name MyGreengrassCoreGroup
      ```

      Wenn die Anfrage erfolgreich ist, sieht die Antwort dem folgenden Beispiel ähnlich:

      ```
      {
        "thingGroupName": "MyGreengrassCoreGroup",
        "thingGroupArn": "arn:aws:iot:us-west-2:123456789012:thinggroup/MyGreengrassCoreGroup",
        "thingGroupId": "4df721e1-ff9f-4f97-92dd-02db4e3f03aa"
      }
      ```

   1. Fügen Sie Ihrer Dinggruppe einen bereitgestellten Greengrass-Kern hinzu. Führen Sie den folgenden Befehl mit diesen Parametern aus:
      + *MyGreengrassCore*Ersetzen Sie es durch den Namen Ihres bereitgestellten Greengrass-Kerns.
      + *MyGreengrassCoreGroup*Ersetzen Sie es durch den Namen Ihrer Dinggruppe.

      ```
      aws iot add-thing-to-thing-group --thing-name MyGreengrassCore --thing-group-name MyGreengrassCoreGroup
      ```

      Der Befehl hat keine Ausgabe, wenn die Anfrage erfolgreich ist.

1. Erstellen Sie eine Datei mit dem Namen `deployment.json` und kopieren Sie dann das folgende JSON-Objekt in die Datei. *targetArn*Ersetzen Sie es durch den ARN der Dinggruppe AWS IoT , die als Ziel für die Unterbereitstellung verwendet werden soll. Bei einem Unterbereitstellungsziel kann es sich nur um eine Dinggruppe handeln. Dinggruppen ARNs haben das folgende Format:
   + **Dinggruppe** — `arn:aws:iot:region:account-id:thinggroup/thingGroupName`

   ```
   {
     "targetArn": "targetArn"
   }
   ```

1. Führen Sie den folgenden Befehl erneut aus, um die Details der ursprünglichen Bereitstellung abzurufen. Zu diesen Details gehören Metadaten, Komponenten und die Auftragskonfiguration. *deploymentId*Ersetzen Sie durch die ID von[Step 1](#create-subdeployments-step1). Sie können diese Bereitstellungskonfiguration verwenden, um Ihre Unterbereitstellung zu konfigurieren und bei Bedarf Änderungen vorzunehmen.

   ```
   aws greengrassv2 get-deployment --deployment-id deploymentId
   ```

   Die Antwort enthält die Details der Bereitstellung. Kopieren Sie eines der folgenden Schlüssel-Wert-Paare aus der Antwort des **get-deployment** Befehls in. `deployment.json` Sie können diese Werte für die Unterbereitstellung ändern. Weitere Hinweise zu den Einzelheiten dieses Befehls finden Sie unter [GetDeployment](https://docs.aws.amazon.com/greengrass/v2/APIReference/API_GetDeployment.html).
   + `components`— Die Komponenten der Bereitstellung. Um eine Komponente zu deinstallieren, entfernen Sie sie aus diesem Objekt. Wenn die Komponente einen Schritt zum [Deinstallationszyklus](component-recipe-reference.md#uninstall-lifecycle-definition) definiert, führt die AWS IoT Greengrass Core-Software das Deinstallationsskript aus, bevor die Komponente vom Gerät entfernt wird.
   + `deploymentName`— Der Name der Bereitstellung.
   + `deploymentPolicies`— Die Richtlinien des Einsatzes.
   + `iotJobConfiguration`— Die Jobkonfiguration der Bereitstellung.
   + `parentTargetArn`— Das Ziel der übergeordneten Bereitstellung.
   + `tags`— Die Tags der Bereitstellung.

1. Führen Sie den folgenden Befehl aus, um die Unterbereitstellung aus `deployment.json` zu erstellen. Ersetzen Sie es *subdeploymentName* durch einen Namen für die Unterbereitstellung.

   ```
   aws greengrassv2 create-deployment --deployment-name subdeploymentName --cli-input-json file://deployment.json
   ```

   Die Antwort enthält eine`deploymentId`, die diese Unterbereitstellung identifiziert. Sie können die Bereitstellungs-ID verwenden, um den Status der Bereitstellung zu überprüfen. Weitere Informationen finden [Sie unter Überprüfen des Bereitstellungsstatus](https://docs.aws.amazon.com/greengrass/v2/developerguide/check-deployment-status.html#check-cloud-deployment-status).

1. Wenn die Unterbereitstellung erfolgreich ist, können Sie ihre Konfiguration verwenden, um die übergeordnete Bereitstellung zu überarbeiten. Kopieren Sie die`deployment.json`, die Sie im vorherigen Schritt verwendet haben. Ersetzen Sie das `targetArn` in der JSON-Datei durch den ARN der übergeordneten Bereitstellung und führen Sie den folgenden Befehl aus, um die übergeordnete Bereitstellung mit dieser neuen Konfiguration zu erstellen.
**Anmerkung**  
Wenn Sie eine neue Bereitstellungsrevision der übergeordneten Flotte erstellen, ersetzt diese alle Bereitstellungsrevisionen und Unterbereitstellungen für diese übergeordnete Bereitstellung. [Weitere Informationen finden Sie unter Bereitstellungen überarbeiten.](https://docs.aws.amazon.com/greengrass/v2/developerguide/revise-deployments.html)

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

   <a name="check-new-deployment-status"></a>Die Antwort enthält ein`deploymentId`, das diese Bereitstellung identifiziert. Sie können die Bereitstellungs-ID verwenden, um den Status der Bereitstellung zu überprüfen. Weitere Informationen finden Sie unter [Überprüfen Sie den Bereitstellungsstatus](check-deployment-status.md#check-cloud-deployment-status).

# Bereitstellungen überarbeiten
<a name="revise-deployments"></a>

Jedes Zielobjekt oder jede Zielgruppe kann jeweils nur eine aktive Bereitstellung haben. Wenn Sie eine Bereitstellung für ein Ziel erstellen, für das bereits eine Bereitstellung vorhanden ist, ersetzen die Softwarekomponenten in der neuen Bereitstellung die Softwarekomponenten der vorherigen Bereitstellung. Wenn die neue Bereitstellung keine Komponente definiert, die in der vorherigen Bereitstellung definiert wurde, entfernt die AWS IoT Greengrass Core-Software diese Komponente von den Core-Zielgeräten. Sie können eine bestehende Bereitstellung überarbeiten, sodass Sie die Komponenten, die auf Kerngeräten ausgeführt werden, nicht aus einer früheren Bereitstellung auf ein Ziel entfernen.

Um eine Bereitstellung zu überarbeiten, erstellen Sie eine Bereitstellung, die von denselben Komponenten und Konfigurationen ausgeht, die in einer früheren Bereitstellung vorhanden waren. Sie verwenden den [CreateDeployment](https://docs.aws.amazon.com/greengrass/v2/APIReference/API_CreateDeployment.html)Vorgang, bei dem es sich um denselben Vorgang handelt, den Sie zum [Erstellen von Bereitstellungen](create-deployments.md) verwenden.

**Um eine Bereitstellung zu überarbeiten ()AWS CLI**

1. <a name="revise-deployment-list-deployments-intro"></a>Führen Sie den folgenden Befehl aus, um die Bereitstellungen für das Bereitstellungsziel aufzulisten. Ersetze es *targetArn* durch den ARN der AWS IoT Zielsache oder der Ziel-Dinggruppe.

   ```
   aws greengrassv2 list-deployments --target-arn targetArn
   ```

   Die Antwort enthält eine Liste mit der neuesten Bereitstellung für das Ziel. Kopieren Sie die `deploymentId` aus der Antwort, um sie im nächsten Schritt zu verwenden.
**Anmerkung**  <a name="revise-deployment-list-deployments-revision-note"></a>
Sie können auch eine andere Bereitstellung als die neueste Version für das Ziel überarbeiten. Geben Sie das `--history-filter ALL` Argument an, um alle Bereitstellungen für das Ziel aufzulisten. Kopieren Sie dann die ID der Bereitstellung, die Sie überarbeiten möchten.

1. <a name="revise-deployment-get-deployment"></a>Führen Sie den folgenden Befehl aus, um die Details der Bereitstellung abzurufen. Zu diesen Details gehören Metadaten, Komponenten und die Auftragskonfiguration. *deploymentId*Ersetzen Sie es durch die ID aus dem vorherigen Schritt.

   ```
   aws greengrassv2 get-deployment --deployment-id deploymentId
   ```

   Die Antwort enthält die Details der Bereitstellung.

1. Erstellen Sie eine Datei namens `deployment.json` und kopieren Sie die Antwort des vorherigen Befehls in die Datei.

1. Entfernen Sie die folgenden Schlüssel-Wert-Paare aus dem JSON-Objekt in `deployment.json`:
   + `deploymentId`
   + `revisionId`
   + `iotJobId`
   + `iotJobArn`
   + `creationTimestamp`
   + `isLatestForTarget`
   + `deploymentStatus`

   Für den [CreateDeployment](https://docs.aws.amazon.com/greengrass/v2/APIReference/API_CreateDeployment.html)Vorgang wird eine Nutzlast mit der folgenden Struktur erwartet.

   ```
   {
     "targetArn": "String",
     "components": Map of components,
     "deploymentPolicies": DeploymentPolicies,
     "iotJobConfiguration": DeploymentIoTJobConfiguration,
     "tags": Map of tags
   }
   ```

1. Führen Sie in `deployment.json` eine der folgenden Aufgaben durch:
   + Ändern Sie den Namen der Bereitstellung (`deploymentName`).
   + Ändern Sie die Komponenten der Bereitstellung (`components`).
   + Ändern Sie die Richtlinien der Bereitstellung (`deploymentPolicies`).
   + Ändern Sie die Jobkonfiguration der Bereitstellung (`iotJobConfiguration`).
   + Ändern Sie die Tags der Bereitstellung (`tags`).

   Weitere Informationen zur Definition dieser Bereitstellungsdetails finden Sie unter[Erstellen von Bereitstellungen](create-deployments.md).

1. Führen Sie den folgenden Befehl aus, um die Bereitstellung von zu erstellen`deployment.json`.

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

   <a name="check-new-deployment-status"></a>Die Antwort enthält eine`deploymentId`, die diese Bereitstellung identifiziert. Sie können die Bereitstellungs-ID verwenden, um den Status der Bereitstellung zu überprüfen. Weitere Informationen finden Sie unter [Überprüfen Sie den Bereitstellungsstatus](check-deployment-status.md#check-cloud-deployment-status).

# Bereitstellungen stornieren
<a name="cancel-deployments"></a>

Sie können eine aktive Bereitstellung abbrechen, um zu verhindern, dass die zugehörigen Softwarekomponenten auf AWS IoT Greengrass Kerngeräten installiert werden. Wenn Sie eine Bereitstellung stornieren, die auf eine Dinggruppe abzielt, erhalten Kerngeräte, die Sie der Gruppe hinzufügen, diese kontinuierliche Bereitstellung nicht. Wenn die Bereitstellung bereits auf einem Kerngerät ausgeführt wird, ändern Sie die Komponenten auf diesem Gerät nicht, wenn Sie die Bereitstellung stornieren. Sie müssen [eine neue Bereitstellung erstellen oder die Bereitstellung](create-deployments.md) [überarbeiten, um die](revise-deployments.md) Komponenten zu ändern, die auf den Kerngeräten ausgeführt werden, die die stornierte Bereitstellung erhalten haben.

**Um eine Bereitstellung abzubrechen ()AWS CLI**

1. Führen Sie den folgenden Befehl aus, um die ID der neuesten Bereitstellungsversion für ein Ziel zu ermitteln. Die neueste Version ist die einzige Bereitstellung, die für ein Ziel aktiv sein kann, da frühere Bereitstellungen abgebrochen werden, wenn Sie eine neue Revision erstellen. Ersetze es *targetArn* durch den ARN der AWS IoT Zielsache oder der Ziel-Dinggruppe.

   ```
   aws greengrassv2 list-deployments --target-arn targetArn
   ```

   Die Antwort enthält eine Liste mit der neuesten Bereitstellung für das Ziel. Kopieren Sie die `deploymentId` aus der Antwort, um sie im nächsten Schritt zu verwenden.

1. Führen Sie den folgenden Befehl aus, um die Bereitstellung abzubrechen. *deploymentId*Ersetzen Sie es durch die ID aus dem vorherigen Schritt.

   ```
   aws greengrassv2 cancel-deployment --deployment-id deploymentId
   ```

   Wenn der Vorgang erfolgreich ist, ändert sich der Bereitstellungsstatus auf`CANCELED`.

# Überprüfen Sie den Bereitstellungsstatus
<a name="check-deployment-status"></a>

Sie können den Status einer Bereitstellung überprüfen, die Sie in erstellen AWS IoT Greengrass. Sie können auch den Status der AWS IoT Jobs überprüfen, mit denen die Bereitstellung auf jedem Kerngerät bereitgestellt wird. Solange eine Bereitstellung aktiv ist, lautet der Status des AWS IoT Jobs`IN_PROGRESS`. Nachdem Sie eine neue Version einer Bereitstellung erstellt haben, ändert sich der Status des AWS IoT Jobs der vorherigen Revision in`CANCELLED`.

**Topics**
+ [Überprüfen Sie den Bereitstellungsstatus](#check-cloud-deployment-status)
+ [Überprüfen Sie den Bereitstellungsstatus des Geräts](#check-device-deployment-status)

## Überprüfen Sie den Bereitstellungsstatus
<a name="check-cloud-deployment-status"></a>

Sie können den Status einer Bereitstellung überprüfen, die Sie anhand ihres Ziels oder ihrer ID identifizieren.

**Um den Bereitstellungsstatus nach Ziel (AWS CLI) zu überprüfen**
+ Führen Sie den folgenden Befehl aus, um den Status der letzten Bereitstellung für ein Ziel abzurufen. *targetArn*Ersetzen Sie es durch den Amazon-Ressourcennamen (ARN) der AWS IoT Sache oder der Dinggruppe, auf die die Bereitstellung abzielt.

  ```
  aws greengrassv2 list-deployments --target-arn targetArn
  ```

  Die Antwort enthält eine Liste mit der neuesten Bereitstellung für das Ziel. Dieses Bereitstellungsobjekt enthält den Status der Bereitstellung.

**Um den Bereitstellungsstatus anhand der ID (AWS CLI) zu überprüfen**
+ Führen Sie den folgenden Befehl aus, um den Status einer Bereitstellung abzurufen. *deploymentId*Ersetzen Sie ihn durch die ID der Bereitstellung, die abgefragt werden soll.

  ```
  aws greengrassv2 get-deployment --deployment-id deploymentId
  ```

  Die Antwort enthält den Status der Bereitstellung.

## Überprüfen Sie den Bereitstellungsstatus des Geräts
<a name="check-device-deployment-status"></a>

Sie können den Status eines Bereitstellungsauftrags überprüfen, der für ein einzelnes Core-Gerät gilt. Sie können auch den Status eines Bereitstellungsauftrags für eine Dinggruppen-Bereitstellung überprüfen.

**Um den Status eines Bereitstellungsauftrags für ein Kerngerät zu überprüfen ()AWS CLI**
+ Führen Sie den folgenden Befehl aus, um den Status aller Bereitstellungsaufträge für ein Kerngerät abzurufen. *coreDeviceName*Ersetzen Sie ihn durch den Namen des abzufragenden Kerngeräts.

  ```
  aws greengrassv2 list-effective-deployments --core-device-thing-name coreDeviceName
  ```

  Die Antwort enthält die Liste der Bereitstellungsaufträge für das Kerngerät. Sie können den Job für eine Bereitstellung anhand des Auftrags `deploymentId` oder identifizieren`targetArn`. Jeder Bereitstellungsauftrag enthält den Status des Auftrags auf dem Kerngerät.

**Um den Bereitstellungsstatus für eine Dinggruppe zu überprüfen ()AWS CLI**

1. Führen Sie den folgenden Befehl aus, um die ID einer vorhandenen Bereitstellung abzurufen. Ersetze es *targetArn* durch den ARN der Ziel-Dinggruppe.

   ```
   aws greengrassv2 list-deployments --target-arn targetArn
   ```

   Die Antwort enthält eine Liste mit der neuesten Bereitstellung für das Ziel. Kopieren Sie die `deploymentId` aus der Antwort, um sie im nächsten Schritt zu verwenden.
**Anmerkung**  
Sie können auch eine andere Bereitstellung als die neueste Bereitstellung für das Ziel auflisten. Geben Sie das `--history-filter ALL` Argument an, um alle Bereitstellungen für das Ziel aufzulisten. Kopieren Sie dann die ID der Bereitstellung, deren Status Sie überprüfen möchten.

1. Führen Sie den folgenden Befehl aus, um die Details der Bereitstellung abzurufen. *deploymentID*Ersetzen Sie es durch die ID aus dem vorherigen Schritt.

   ```
   aws greengrassv2 get-deployment --deployment-id deploymentId
   ```

   Die Antwort enthält Informationen über die Bereitstellung. Kopieren Sie die `iotJobId` aus der Antwort, um sie im folgenden Schritt zu verwenden.

1. Führen Sie den folgenden Befehl aus, um die Auftragsausführung eines Kerngeräts für die Bereitstellung zu beschreiben. Ersetzen Sie *iotJobId* und *coreDeviceThingName* durch die Job-ID aus dem vorherigen Schritt und das Kerngerät, dessen Status Sie überprüfen möchten.

   ```
   aws iot describe-job-execution --job-id iotJobId --thing-name coreDeviceThingName
   ```

   Die Antwort enthält den Status der Ausführung des Bereitstellungsauftrags auf dem Kerngerät sowie Einzelheiten zum Status. Die `detailsMap` enthält die folgenden Informationen:
   + `detailed-deployment-status`— Der Status des Bereitstellungsergebnisses, der einer der folgenden Werte sein kann:
     + `SUCCESSFUL`— Die Bereitstellung war erfolgreich.
     + `FAILED_NO_STATE_CHANGE`— Die Bereitstellung schlug fehl, während das Kerngerät sich darauf vorbereitete, die Bereitstellung anzuwenden.
     + `FAILED_ROLLBACK_NOT_REQUESTED`— Die Bereitstellung schlug fehl, und bei der Bereitstellung wurde nicht angegeben, zu einer früheren funktionierenden Konfiguration zurückzukehren, sodass das Kerngerät möglicherweise nicht ordnungsgemäß funktioniert.
     + `FAILED_ROLLBACK_COMPLETE`— Die Bereitstellung ist fehlgeschlagen, und das Kerngerät wurde erfolgreich auf eine frühere funktionierende Konfiguration zurückgesetzt.
     + `FAILED_UNABLE_TO_ROLLBACK`— Die Bereitstellung ist fehlgeschlagen, und das Kerngerät konnte nicht zu einer früheren funktionierenden Konfiguration zurückgesetzt werden, sodass das Kerngerät möglicherweise nicht ordnungsgemäß funktioniert.

     Wenn die Bereitstellung fehlgeschlagen ist, überprüfen Sie den `deployment-failure-cause` Wert und die Protokolldateien des Kerngeräts, um das Problem zu identifizieren. Weitere Informationen zum Zugriff auf die Protokolldateien des Kerngeräts finden Sie unter[AWS IoT Greengrass Protokolle überwachen](monitor-logs.md).
   + `deployment-failure-cause`— Eine Fehlermeldung, die zusätzliche Informationen darüber enthält, warum die Auftragsausführung fehlgeschlagen ist.

   Die Antwort sieht dem folgenden Beispiel ähnlich.

   ```
   {
     "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-Konto 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
     }
   }
   ```