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 entwickeln
Sie können Komponenten auf Ihrem Greengrass-Core-Gerät entwickeln und testen. Dadurch können Sie Ihre AWS IoT Greengrass Software erstellen und iterieren, ohne mit dem zu interagieren. AWS Cloud Wenn Sie eine Version Ihrer Komponente fertiggestellt haben, können Sie sie AWS IoT Greengrass in die Cloud hochladen, sodass Sie und Ihr Team die Komponente auf anderen Geräten in Ihrer Flotte bereitstellen können. Weitere Informationen zur Bereitstellung von Komponenten finden Sie unter[AWS IoT Greengrass Komponenten auf Geräten bereitstellen](manage-deployments.md).
Jede Komponente besteht aus einem *Rezept* und *Artefakten*.
+ **Rezepte**
Jede Komponente enthält eine Rezeptdatei, die ihre Metadaten definiert. Das Rezept spezifiziert auch die Konfigurationsparameter, die Komponentenabhängigkeiten, den Lebenszyklus und die Plattformkompatibilität der Komponente. Der Komponentenlebenszyklus definiert die Befehle, mit denen die Komponente installiert, ausgeführt und heruntergefahren wird. Weitere Informationen finden Sie unter [AWS IoT Greengrass Referenz zum Komponenten-Rezept](component-recipe-reference.md).
Sie können Rezepte im [JSON](https://en.wikipedia.org/wiki/JSON) - oder [YAML-Format](https://en.wikipedia.org/wiki/YAML) definieren.
+ **Artefakte**
Komponenten können eine beliebige Anzahl von Artefakten haben, bei denen es sich um Komponenten-Binärdateien handelt. Artefakte können Skripts, kompilierten Code, statische Ressourcen und alle anderen Dateien umfassen, die eine Komponente verwendet. Komponenten können auch Artefakte aus Komponentenabhängigkeiten verwenden.
AWS IoT Greengrass stellt vorgefertigte Komponenten bereit, die Sie in Ihren Anwendungen verwenden und auf Ihren Geräten bereitstellen können. Sie können beispielsweise die Stream-Manager-Komponente verwenden, um Daten in verschiedene AWS Dienste hochzuladen, oder Sie können die CloudWatch Metrik-Komponente verwenden, um benutzerdefinierte Metriken auf Amazon zu veröffentlichen CloudWatch. Weitere Informationen finden Sie unter [AWS-mitgelieferte Komponenten](public-components.md).
AWS IoT Greengrass kuratiert einen Index von Greengrass-Komponenten, den sogenannten Greengrass Software Catalog. Dieser Katalog verfolgt Greengrass-Komponenten, die von der Greengrass-Community entwickelt wurden. Aus diesem Katalog können Sie Komponenten herunterladen, ändern und bereitstellen, um Ihre Greengrass-Anwendungen zu erstellen. Weitere Informationen finden Sie unter [Komponenten der Gemeinschaft](greengrass-software-catalog.md).
Die AWS IoT Greengrass Core-Software führt Komponenten, die Sie auf dem Core-Gerät konfigurieren, als Systembenutzer `ggc_user` und als Gruppe aus`ggc_group`, z. B. und. Das bedeutet, dass die Komponenten über die Berechtigungen dieses Systembenutzers verfügen. Wenn Sie einen Systembenutzer ohne Basisverzeichnis verwenden, können Komponenten keine Ausführungsbefehle oder Code verwenden, die ein Basisverzeichnis verwenden. Das bedeutet, dass Sie den `pip install some-library --user` Befehl beispielsweise nicht verwenden können, um Python-Pakete zu installieren. Wenn Sie das [Tutorial „Erste Schritte](getting-started.md)“ befolgt haben, um Ihr Kerngerät einzurichten, hat Ihr Systembenutzer kein Home-Verzeichnis. Weitere Informationen zur Konfiguration des Benutzers und der Gruppe, die Komponenten ausführen, finden Sie unter[Konfigurieren Sie den Benutzer, der die Komponenten ausführt](configure-greengrass-core-v2.md#configure-component-user).
**Anmerkung**
AWS IoT Greengrass verwendet semantische Versionen für Komponenten. *Semantische Versionen folgen einem Hauptteil.* *geringfügig*. *Patch-Nummernsystem*. Version `1.0.0` steht beispielsweise für die erste Hauptversion einer Komponente. Weitere Informationen finden Sie in der [semantischen Versionsspezifikation](https://semver.org/).
**Topics**
+ [Lebenszyklus der Komponenten](#component-lifecycle)
+ [Komponententypen](#component-types)
+ [AWS IoT Greengrass Komponenten erstellen](create-components.md)
+ [Testen Sie AWS IoT Greengrass Komponenten mit lokalen Bereitstellungen](test-components.md)
+ [Veröffentlichen Sie Komponenten zur Bereitstellung auf Ihren Kerngeräten](publish-components.md)
+ [Interagieren Sie mit AWS Diensten](interact-with-aws-services.md)
+ [Führen Sie einen Docker-Container aus](run-docker-container.md)
+ [AWS IoT Greengrass Referenz zum Komponenten-Rezept](component-recipe-reference.md)
+ [Referenz zur Umgebungsvariablen der Komponente](component-environment-variables.md)
## Lebenszyklus der Komponenten
Der *Komponentenlebenszyklus* definiert die Phasen, in denen die AWS IoT Greengrass Core-Software Komponenten installiert und ausführt. Jede Phase definiert ein Skript und andere Informationen, die das Verhalten der Komponente spezifizieren. Wenn Sie beispielsweise eine Komponente installieren, führt die AWS IoT Greengrass Core-Software das `install` Lifecycle-Skript für diese Komponente aus. Komponenten auf Kerngeräten haben die folgenden Lebenszyklusstatus:
+ `NEW`— Das Rezept und die Artefakte der Komponente sind auf das Kerngerät geladen, aber die Komponente ist nicht installiert. Nachdem eine Komponente diesen Status erreicht hat, führt sie ihr [Installationsskript](component-recipe-reference.md#install-lifecycle-definition) aus.
+ `INSTALLED`— Die Komponente ist auf dem Kerngerät installiert. Die Komponente wechselt in diesen Status, nachdem sie ihr [Installationsskript](component-recipe-reference.md#install-lifecycle-definition) ausgeführt hat.
+ `STARTING`— Die Komponente wird auf dem Kerngerät gestartet. Die Komponente wechselt in diesen Zustand, wenn sie ihr [Startskript](component-recipe-reference.md#startup-lifecycle-definition) ausführt. Wenn der Start erfolgreich ist, wechselt die Komponente in den `RUNNING` Status.
+ `RUNNING`— Die Komponente läuft auf dem Kerngerät. Die Komponente wechselt in diesen Zustand, wenn sie ihr [Run-Skript](component-recipe-reference.md#run-lifecycle-definition) ausführt oder wenn sie aktive Hintergrundprozesse in ihrem Startskript ausführt.
+ `FINISHED`— Die Komponente wurde erfolgreich ausgeführt und ihre Ausführung wurde abgeschlossen.
+ `STOPPING`— Die Komponente wird angehalten. Die Komponente wechselt in diesen Zustand, wenn sie ihr [Shutdown-Skript](component-recipe-reference.md#shutdown-lifecycle-definition) ausführt.
+ `ERRORED`— Bei der Komponente ist ein Fehler aufgetreten. Wenn die Komponente in diesen Zustand übergeht, führt sie ihr [Wiederherstellungsskript](component-recipe-reference.md#recover-lifecycle-definition) aus. Anschließend wird die Komponente neu gestartet, um zu versuchen, zur normalen Verwendung zurückzukehren. Wenn die Komponente dreimal in den `ERRORED` Status wechselt, ohne dass sie erfolgreich ausgeführt wurde, wird `BROKEN` die Komponente.
+ `BROKEN`— Die Komponente ist mehrfach auf Fehler gestoßen und kann nicht wiederhergestellt werden. Sie müssen die Komponente erneut bereitstellen, um das Problem zu beheben.
## Komponententypen
Der *Komponententyp* gibt an, wie die AWS IoT Greengrass Core-Software die Komponente ausführt. Komponenten können die folgenden Typen haben:
+ **Kern** (`aws.greengrass.nucleus`)
Der Greengrass-Kern ist die Komponente, die die Mindestfunktionalität der AWS IoT Greengrass Core-Software bietet. Weitere Informationen finden Sie unter [Grüngraskern](greengrass-nucleus-component.md).
+ **Plug-in** () `aws.greengrass.plugin`
Der Greengrass-Nucleus führt eine Plugin-Komponente in derselben Java Virtual Machine (JVM) wie der Nucleus aus. Der Nucleus wird neu gestartet, wenn Sie die Version einer Plugin-Komponente auf einem Core-Gerät ändern. Um Plugin-Komponenten zu installieren und auszuführen, müssen Sie den Greengrass-Nucleus so konfigurieren, dass er als Systemdienst ausgeführt wird. Weitere Informationen finden Sie unter [Den Greengrass Nucleus als Systemdienst konfigurieren](configure-greengrass-core-v2.md#configure-system-service).
Einige Komponenten, die von bereitgestellt werden, AWS sind Plugin-Komponenten, sodass sie direkt mit dem Greengrass-Nucleus verbunden werden können. Plugin-Komponenten verwenden dieselbe Protokolldatei wie der Greengrass-Kern. Weitere Informationen finden Sie unter [AWS IoT Greengrass Protokolle überwachen](monitor-logs.md).
+ **Generisch** () `aws.greengrass.generic`
Der Greengrass-Kern führt die Lebenszyklusskripte einer generischen Komponente aus, wenn die Komponente einen Lebenszyklus definiert.
Dieser Typ ist der Standardtyp für benutzerdefinierte Komponenten.
+ **Lambda** () `aws.greengrass.lambda`
Der Greengrass-Kern führt mithilfe der Lambda-Launcher-Komponente eine [Lambda-Funktionskomponente](lambda-launcher-component.md) aus.
Wenn Sie eine Komponente aus einer Lambda-Funktion erstellen, hat die Komponente diesen Typ. Weitere Informationen finden Sie unter [AWS Lambda Funktionen ausführen](run-lambda-functions.md).
**Anmerkung**
Es wird nicht empfohlen, den Komponententyp in einem Rezept anzugeben. AWS IoT Greengrass legt den Typ für Sie fest, wenn Sie eine Komponente erstellen.
# AWS IoT Greengrass Komponenten erstellen
Sie können benutzerdefinierte AWS IoT Greengrass Komponenten auf einem lokalen Entwicklungscomputer oder einem Greengrass-Core-Gerät entwickeln. AWS IoT Greengrass [bietet das [AWS IoT Greengrass Development Kit Command-Line Interface (GDK CLI)](greengrass-development-kit-cli.md), mit dem Sie Komponenten aus vordefinierten Komponentenvorlagen und Community-Komponenten erstellen, erstellen und veröffentlichen können.](greengrass-software-catalog.md) Sie können auch integrierte Shell-Befehle ausführen, um Komponenten zu erstellen, zu erstellen und zu veröffentlichen. Wählen Sie aus den folgenden Optionen, um benutzerdefinierte Greengrass-Komponenten zu erstellen:
+ **Verwenden Sie das Greengrass Development Kit CLI**
Verwenden Sie die GDK-CLI, um Komponenten auf einem lokalen Entwicklungscomputer zu entwickeln. Die GDK-CLI erstellt und verpackt den Quellcode von Komponenten in ein Rezept und Artefakte, die Sie als private Komponente für den AWS IoT Greengrass Service veröffentlichen können. Sie können die GDK-CLI so konfigurieren, dass die Version und das Artefakt der Komponente automatisch aktualisiert werden, URIs wenn Sie die Komponente veröffentlichen, sodass Sie das Rezept nicht jedes Mal aktualisieren müssen. Um eine Komponente mit der GDK CLI zu entwickeln, können Sie mit einer Vorlage oder einer Community-Komponente aus dem [Greengrass Software](greengrass-software-catalog.md) Catalog beginnen. Weitere Informationen finden Sie unter [AWS IoT Greengrass Befehlszeilenschnittstelle für das Entwicklungskit](greengrass-development-kit-cli.md).
+ **Führen Sie die integrierten Shell-Befehle aus**
Sie können integrierte Shell-Befehle ausführen, um Komponenten auf einem lokalen Entwicklungscomputer oder auf einem Greengrass-Core-Gerät zu entwickeln. Sie verwenden Shell-Befehle, um den Quellcode von Komponenten zu kopieren oder in Artefakte umzuwandeln. Jedes Mal, wenn Sie eine neue Version einer Komponente erstellen, müssen Sie das Rezept mit der neuen Komponentenversion erstellen oder aktualisieren. Wenn Sie die Komponente im AWS IoT Greengrass Service veröffentlichen, müssen Sie den URI für jedes Komponentenartefakt im Rezept aktualisieren.
**Topics**
+ [Eine Komponente erstellen (GDK CLI)](#create-component-gdk-cli)
+ [Erstellen Sie eine Komponente (Shell-Befehle)](#create-component-shell-commands)
## Eine Komponente erstellen (GDK CLI)
Folgen Sie den Anweisungen in diesem Abschnitt, um eine Komponente mit der GDK-CLI zu erstellen und zu erstellen.
**Um eine Greengrass-Komponente (GDK CLI) zu entwickeln**
1. Falls Sie es noch nicht getan haben, installieren Sie die GDK-CLI auf Ihrem Entwicklungscomputer. Weitere Informationen finden Sie unter [Installieren oder aktualisieren Sie die AWS IoT Greengrass Development-Kit-Befehlszeilenschnittstelle](install-greengrass-development-kit-cli.md).
1. Wechseln Sie zu dem Ordner, in dem Sie Komponentenordner erstellen möchten.
------
#### [ Linux or Unix ]
```
mkdir ~/greengrassv2
cd ~/greengrassv2
```
------
#### [ Windows Command Prompt (CMD) ]
```
mkdir %USERPROFILE%\greengrassv2
cd %USERPROFILE%\greengrassv2
```
------
#### [ PowerShell ]
```
mkdir ~/greengrassv2
cd ~/greengrassv2
```
------
1. Wählen Sie eine Komponentenvorlage oder Community-Komponente zum Herunterladen aus. Die GDK-CLI lädt die Vorlage oder Community-Komponente herunter, sodass Sie mit einem Funktionsbeispiel beginnen können. Verwenden Sie den Befehl [component list](greengrass-development-kit-cli-component.md#greengrass-development-kit-cli-component-list), um die Liste der verfügbaren Vorlagen oder Community-Komponenten abzurufen.
+ Führen Sie den folgenden Befehl aus, um Komponentenvorlagen aufzulisten. Jede Zeile in der Antwort enthält den Namen und die Programmiersprache einer Vorlage.
```
gdk component list --template
```
+ Führen Sie den folgenden Befehl aus, um die Community-Komponenten aufzulisten.
```
gdk component list --repository
```
1. Erstellen Sie einen Komponentenordner, in den die GDK-CLI die Vorlage oder Community-Komponente herunterlädt, und wechseln Sie zu diesem. *HelloWorld*Ersetzen Sie ihn durch den Namen der Komponente oder einen anderen Namen, der Ihnen hilft, diesen Komponentenordner zu identifizieren.
------
#### [ Linux or Unix ]
```
mkdir HelloWorld
cd HelloWorld
```
------
#### [ Windows Command Prompt (CMD) ]
```
mkdir HelloWorld
cd HelloWorld
```
------
#### [ PowerShell ]
```
mkdir HelloWorld
cd HelloWorld
```
------
1. Laden Sie die Vorlage oder Community-Komponente in den aktuellen Ordner herunter. Verwenden Sie den Befehl [component init](greengrass-development-kit-cli-component.md#greengrass-development-kit-cli-component-init).
+ Führen Sie den folgenden Befehl aus, um einen Komponentenordner aus einer Vorlage zu erstellen. *HelloWorld*Ersetzen Sie ihn durch den Namen der Vorlage und *python* durch den Namen der Programmiersprache.
```
gdk component init --template HelloWorld --language python
```
+ Führen Sie den folgenden Befehl aus, um einen Komponentenordner aus einer Community-Komponente zu erstellen. *ComponentName*Ersetzen Sie ihn durch den Namen der Community-Komponente.
```
gdk component init --repository ComponentName
```
**Anmerkung**
Wenn Sie GDK CLI v1.0.0 verwenden, müssen Sie diesen Befehl in einem leeren Ordner ausführen. Die GDK-CLI lädt die Vorlage oder Community-Komponente in den aktuellen Ordner herunter.
Wenn Sie GDK CLI v1.1.0 oder höher verwenden, können Sie das `--name` Argument angeben, um den Ordner anzugeben, in den die GDK-CLI die Vorlage oder Community-Komponente herunterlädt. Wenn Sie dieses Argument verwenden, geben Sie einen Ordner an, der nicht existiert. Die GDK-CLI erstellt den Ordner für Sie. Wenn Sie dieses Argument nicht angeben, verwendet die GDK-CLI den aktuellen Ordner, der leer sein muss.
1. Die GDK-CLI liest aus der benannten [GDK-CLI-Konfigurationsdatei](gdk-cli-configuration-file.md), um `gdk-config.json` Komponenten zu erstellen und zu veröffentlichen. Diese Konfigurationsdatei befindet sich im Stammverzeichnis des Komponentenordners. Im vorherigen Schritt wurde diese Datei für Sie erstellt. In diesem Schritt aktualisieren Sie `gdk-config.json` mit Informationen zu Ihrer Komponente. Gehen Sie wie folgt vor:
1. Öffnen Sie `gdk-config.json` in einem Texteditor.
1. (Optional) Ändern Sie den Namen der Komponente. Der Komponentenname ist der Schlüssel im `component` Objekt.
1. Ändern Sie den Autor der Komponente.
1. (Optional) Ändern Sie die Version der Komponente. Geben Sie eines der folgenden Elemente an:
+ `NEXT_PATCH`— Wenn Sie diese Option wählen, legt die GDK-CLI die Version fest, wenn Sie die Komponente veröffentlichen. Die GDK-CLI fragt den AWS IoT Greengrass Dienst ab, um die neueste veröffentlichte Version der Komponente zu identifizieren. Anschließend wird die Version auf die nächste Patch-Version nach dieser Version gesetzt. Wenn Sie die Komponente noch nicht veröffentlicht haben, verwendet die GDK-CLI Version`1.0.0`.
Wenn Sie diese Option wählen, können Sie die [Greengrass-CLI](greengrass-cli-component.md) nicht verwenden, um die Komponente lokal auf Ihrem lokalen Entwicklungscomputer bereitzustellen und zu testen, auf dem die AWS IoT Greengrass Core-Software ausgeführt wird. Um lokale Bereitstellungen zu ermöglichen, müssen Sie stattdessen eine semantische Version angeben.
+ Eine semantische Version, wie z. **1.0.0** *Semantische Versionen verwenden eine Hauptversion.* *unbedeutend*. *Patch-Nummerierungssystem*. Weitere Informationen finden Sie in der [semantischen Versionsspezifikation](https://semver.org/).
Wenn Sie Komponenten auf einem Greengrass-Core-Gerät entwickeln, auf dem Sie die Komponente bereitstellen und testen möchten, wählen Sie diese Option. Sie müssen die Komponente mit einer bestimmten Version erstellen, um lokale Bereitstellungen mit der [Greengrass-CLI](greengrass-cli-component.md) zu erstellen.
1. (Optional) Ändern Sie die Build-Konfiguration für die Komponente. Die Build-Konfiguration definiert, wie die GDK-CLI die Quelle der Komponente in Artefakte aufbaut. Wählen Sie aus den folgenden Optionen für`build_system`:
+ `zip`— Packt den Ordner der Komponente in eine ZIP-Datei, um ihn als einziges Artefakt der Komponente zu definieren. Wählen Sie diese Option für die folgenden Komponententypen:
+ Komponenten, die interpretierte Programmiersprachen verwenden, wie Python oder JavaScript.
+ Komponenten, die andere Dateien als Code verpacken, z. B. Modelle für maschinelles Lernen oder andere Ressourcen.
Die GDK-CLI komprimiert den Ordner der Komponente in eine Zip-Datei mit demselben Namen wie der Komponentenordner. Wenn der Name des Komponentenordners beispielsweise lautet`HelloWorld`, erstellt die GDK-CLI eine ZIP-Datei mit dem Namen`HelloWorld.zip`.
**Anmerkung**
Wenn Sie GDK CLI Version 1.0.0 auf einem Windows-Gerät verwenden, dürfen die Namen des Komponentenordners und der ZIP-Dateien nur Kleinbuchstaben enthalten.
Wenn die GDK-CLI den Ordner der Komponente in eine Zip-Datei komprimiert, überspringt sie die folgenden Dateien:
+ Die Datei `gdk-config.json`
+ Die Rezeptdatei (oder) `recipe.json` `recipe.yaml`
+ Erstellen Sie Ordner, wie `greengrass-build`
+ `maven`— Führt den `mvn clean package` Befehl aus, um den Quellcode der Komponente in Artefakte umzuwandeln. Wählen Sie diese Option für Komponenten, die [Maven](https://maven.apache.org/) verwenden, wie z. B. Java-Komponenten.
Auf Windows-Geräten ist diese Funktion für GDK CLI v1.1.0 und höher verfügbar.
+ `gradle`— Führt den `gradle build` Befehl aus, um den Quellcode der Komponente in Artefakte umzuwandeln. Wählen Sie diese Option für Komponenten, die [Gradle](https://gradle.org/) verwenden. Diese Funktion ist für GDK CLI v1.1.0 und höher verfügbar.
Das `gradle` Build-System unterstützt Kotlin DSL als Build-Datei. Diese Funktion ist für GDK CLI v1.2.0 und höher verfügbar.
+ `gradlew`— Führt den `gradlew` Befehl aus, um den Quellcode der Komponente in Artefakte umzuwandeln. Wählen Sie diese Option für Komponenten, die den [Gradle Wrapper](https://docs.gradle.org/current/userguide/gradle_wrapper.html) verwenden.
Diese Funktion ist für GDK CLI v1.2.0 und höher verfügbar.
+ `custom`— Führt einen benutzerdefinierten Befehl aus, um den Quellcode der Komponente in ein Rezept und Artefakte umzuwandeln. Geben Sie den benutzerdefinierten Befehl im `custom_build_command` Parameter an.
1. Wenn Sie `custom` für angeben`build_system`, fügen Sie `custom_build_command` dem `build` Objekt das hinzu. Geben Sie in `custom_build_command` eine einzelne Zeichenfolge oder eine Liste von Zeichenfolgen an, wobei jede Zeichenfolge ein Wort im Befehl ist. Um beispielsweise einen benutzerdefinierten Build-Befehl für eine C\$1\$1-Komponente auszuführen, können Sie Folgendes **["cmake", "--build", "build", "--config", "Release"]** angeben:
1. Wenn Sie GDK CLI v1.1.0 oder höher verwenden, können Sie das `--bucket` Argument angeben, um den S3-Bucket anzugeben, in den die GDK-CLI die Artefakte der Komponente hochlädt. Wenn Sie dieses Argument nicht angeben, lädt die GDK-CLI in den S3-Bucket hoch, dessen Name`bucket-region-accountId`, wo *bucket* und *region* sind die Werte, in denen Sie angeben`gdk-config.json`, *accountId* ist und der Ihre AWS-Konto ID ist. Die GDK-CLI erstellt den Bucket, falls er nicht existiert.
Ändern Sie die Veröffentlichungskonfiguration für die Komponente. Gehen Sie wie folgt vor:
1. Geben Sie den Namen des S3-Buckets an, der zum Hosten von Komponentenartefakten verwendet werden soll.
1. Geben Sie an AWS-Region , wo die GDK-CLI die Komponente veröffentlicht.
Wenn Sie mit diesem Schritt fertig sind, sieht die `gdk-config.json` Datei möglicherweise dem folgenden Beispiel ähnlich.
```
{
"component": {
"com.example.PythonHelloWorld": {
"author": "Amazon",
"version": "NEXT_PATCH",
"build": {
"build_system" : "zip"
},
"publish": {
"bucket": "greengrass-component-artifacts",
"region": "us-west-2"
}
}
},
"gdk_version": "1.0.0"
}
```
1. Aktualisieren Sie die Rezeptdatei der Komponente mit dem Namen `recipe.yaml` oder`recipe.json`. Gehen Sie wie folgt vor:
1. Wenn Sie eine Vorlage oder Community-Komponente heruntergeladen haben, die das `zip` Build-System verwendet, überprüfen Sie, ob der Name des ZIP-Artefakts mit dem Namen des Komponentenordners übereinstimmt. Die GDK-CLI komprimiert den Komponentenordner in eine Zip-Datei mit demselben Namen wie der Komponentenordner. Das Rezept enthält den Namen des ZIP-Artefakts in der Liste der Komponentenartefakte und in Lebenszyklusskripten, die Dateien im ZIP-Artefakt verwenden. Aktualisieren Sie die `Lifecycle` Definitionen `Artifacts` und so, dass der Name der Zip-Datei mit dem Namen des Komponentenordners übereinstimmt. In den folgenden unvollständigen Rezeptbeispielen wird der Name der Zip-Datei in den `Lifecycle` Definitionen `Artifacts` und hervorgehoben.
------
#### [ JSON ]
```
{
...
"Manifests": [
{
"Platform": {
"os": "all"
},
"Artifacts": [
{
"URI": "s3://{COMPONENT_NAME}/{COMPONENT_VERSION}/HelloWorld.zip",
"Unarchive": "ZIP"
}
],
"Lifecycle": {
"Run": "python3 -u {artifacts:decompressedPath}/HelloWorld/main.py {configuration:/Message}"
}
}
]
}
```
------
#### [ YAML ]
```
---
...
Manifests:
- Platform:
os: all
Artifacts:
- URI: "s3://BUCKET_NAME/COMPONENT_NAME/COMPONENT_VERSION/HelloWorld.zip"
Unarchive: ZIP
Lifecycle:
Run: "python3 -u {artifacts:decompressedPath}/HelloWorld/main.py {configuration:/Message}"
```
------
1. (Optional) Aktualisieren Sie die Komponentenbeschreibung, die Standardkonfiguration, die Artefakte, Lebenszyklusskripts und die Plattformunterstützung. Weitere Informationen finden Sie unter [AWS IoT Greengrass Referenz zum Komponenten-Rezept](component-recipe-reference.md).
Wenn Sie mit diesem Schritt fertig sind, könnte die Rezeptdatei den folgenden Beispielen ähneln.
------
#### [ JSON ]
```
{
"RecipeFormatVersion": "2020-01-25",
"ComponentName": "{COMPONENT_NAME}",
"ComponentVersion": "{COMPONENT_VERSION}",
"ComponentDescription": "This is a simple Hello World component written in Python.",
"ComponentPublisher": "{COMPONENT_AUTHOR}",
"ComponentConfiguration": {
"DefaultConfiguration": {
"Message": "World"
}
},
"Manifests": [
{
"Platform": {
"os": "all"
},
"Artifacts": [
{
"URI": "s3://{COMPONENT_NAME}/{COMPONENT_VERSION}/HelloWorld.zip",
"Unarchive": "ZIP"
}
],
"Lifecycle": {
"Run": "python3 -u {artifacts:decompressedPath}/HelloWorld/main.py {configuration:/Message}"
}
}
]
}
```
------
#### [ YAML ]
```
---
RecipeFormatVersion: "2020-01-25"
ComponentName: "{COMPONENT_NAME}"
ComponentVersion: "{COMPONENT_VERSION}"
ComponentDescription: "This is a simple Hello World component written in Python."
ComponentPublisher: "{COMPONENT_AUTHOR}"
ComponentConfiguration:
DefaultConfiguration:
Message: "World"
Manifests:
- Platform:
os: all
Artifacts:
- URI: "s3://BUCKET_NAME/COMPONENT_NAME/COMPONENT_VERSION/HelloWorld.zip"
Unarchive: ZIP
Lifecycle:
Run: "python3 -u {artifacts:decompressedPath}/HelloWorld/main.py {configuration:/Message}"
```
------
1. Entwickeln und bauen Sie die Greengrass-Komponente. Der Befehl zum [Erstellen von Komponenten](greengrass-development-kit-cli-component.md#greengrass-development-kit-cli-component-build) erzeugt ein Rezept und Artefakte in dem `greengrass-build` Ordner im Komponentenordner. Führen Sie den folgenden Befehl aus.
```
gdk component build
```
Wenn Sie bereit sind, Ihre Komponente zu testen, verwenden Sie die GDK-CLI, um sie im AWS IoT Greengrass Service zu veröffentlichen. Anschließend können Sie die Komponente auf Greengrass-Kerngeräten bereitstellen. Weitere Informationen finden Sie unter [Veröffentlichen Sie Komponenten zur Bereitstellung auf Ihren Kerngeräten](publish-components.md).
## Erstellen Sie eine Komponente (Shell-Befehle)
Folgen Sie den Anweisungen in diesem Abschnitt, um Rezept- und Artefaktordner zu erstellen, die Quellcode und Artefakte für mehrere Komponenten enthalten.
**Um eine Greengrass-Komponente zu entwickeln (Shell-Befehle)**
1. Erstellen Sie einen Ordner für Ihre Komponenten mit Unterordnern für Rezepte und Artefakte. Führen Sie die folgenden Befehle auf Ihrem Greengrass-Core-Gerät aus, um diese Ordner zu erstellen und zum Komponentenordner zu wechseln. Ersetzen Sie *\$1/greengrassv2* oder *%USERPROFILE%\$1greengrassv2* durch den Pfad zu dem Ordner, der für die lokale Entwicklung verwendet werden soll.
------
#### [ Linux or Unix ]
```
mkdir -p ~/greengrassv2/{recipes,artifacts}
cd ~/greengrassv2
```
------
#### [ Windows Command Prompt (CMD) ]
```
mkdir %USERPROFILE%\greengrassv2\\recipes, %USERPROFILE%\greengrassv2\\artifacts
cd %USERPROFILE%\greengrassv2
```
------
#### [ PowerShell ]
```
mkdir ~/greengrassv2/recipes, ~/greengrassv2/artifacts
cd ~/greengrassv2
```
------
1. Verwenden Sie einen Texteditor, um eine Rezeptdatei zu erstellen, die die Metadaten, Parameter, Abhängigkeiten, den Lebenszyklus und die Plattformfähigkeit Ihrer Komponente definiert. Nehmen Sie die Komponentenversion in den Namen der Rezeptdatei auf, damit Sie erkennen können, welches Rezept welche Komponentenversion widerspiegelt. Sie können das YAML- oder das JSON-Format für Ihr Rezept wählen.
Auf einem Linux-basierten System können Sie beispielsweise den folgenden Befehl ausführen, um die Datei mit GNU Nano zu erstellen.
------
#### [ JSON ]
```
nano recipes/com.example.HelloWorld-1.0.0.json
```
------
#### [ YAML ]
```
nano recipes/com.example.HelloWorld-1.0.0.yaml
```
------
**Anmerkung**
AWS IoT Greengrass verwendet semantische Versionen für Komponenten. *Semantische Versionen folgen einem Hauptteil.* *unbedeutend*. *Patch-Nummernsystem*. Version `1.0.0` steht beispielsweise für die erste Hauptversion einer Komponente. Weitere Informationen finden Sie in der [semantischen Versionsspezifikation](https://semver.org/).
1. Definieren Sie das Rezept für Ihre Komponente. Weitere Informationen finden Sie unter [AWS IoT Greengrass Referenz zum Komponenten-Rezept](component-recipe-reference.md).
Ihr Rezept könnte dem folgenden Hello World-Beispielrezept ähneln.
------
#### [ JSON ]
```
{
"RecipeFormatVersion": "2020-01-25",
"ComponentName": "com.example.HelloWorld",
"ComponentVersion": "1.0.0",
"ComponentDescription": "My first AWS IoT Greengrass component.",
"ComponentPublisher": "Amazon",
"ComponentConfiguration": {
"DefaultConfiguration": {
"Message": "world"
}
},
"Manifests": [
{
"Platform": {
"os": "linux"
},
"Lifecycle": {
"run": "python3 -u {artifacts:path}/hello_world.py {configuration:/Message}"
}
},
{
"Platform": {
"os": "windows"
},
"Lifecycle": {
"run": "py -3 -u {artifacts:path}/hello_world.py {configuration:/Message}"
}
}
]
}
```
------
#### [ YAML ]
```
---
RecipeFormatVersion: '2020-01-25'
ComponentName: com.example.HelloWorld
ComponentVersion: '1.0.0'
ComponentDescription: My first AWS IoT Greengrass component.
ComponentPublisher: Amazon
ComponentConfiguration:
DefaultConfiguration:
Message: world
Manifests:
- Platform:
os: linux
Lifecycle:
run: |
python3 -u {artifacts:path}/hello_world.py "{configuration:/Message}"
- Platform:
os: windows
Lifecycle:
run: |
py -3 -u {artifacts:path}/hello_world.py "{configuration:/Message}"
```
------
Dieses Rezept führt ein Hello World Python-Skript aus, das dem folgenden Beispielskript ähneln könnte.
```
import sys
message = "Hello, %s!" % sys.argv[1]
# Print the message to stdout, which Greengrass saves in a log file.
print(message)
```
1. Erstellen Sie einen Ordner für die zu entwickelnde Komponentenversion. Es wird empfohlen, für die Artefakte jeder Komponentenversion einen eigenen Ordner zu verwenden, damit Sie feststellen können, welche Artefakte für jede Komponentenversion bestimmt sind. Führen Sie den folgenden Befehl aus.
------
#### [ Linux or Unix ]
```
mkdir -p artifacts/com.example.HelloWorld/1.0.0
```
------
#### [ Windows Command Prompt (CMD) ]
```
mkdir artifacts/com.example.HelloWorld/1.0.0
```
------
#### [ PowerShell ]
```
mkdir artifacts/com.example.HelloWorld/1.0.0
```
------
**Wichtig**
Sie müssen das folgende Format für den Artefaktordnerpfad verwenden. Geben Sie den Komponentennamen und die Version an, die Sie im Rezept angeben.
```
artifacts/componentName/componentVersion/
```
1. Erstellen Sie die Artefakte für Ihre Komponente in dem Ordner, den Sie im vorherigen Schritt erstellt haben. Artefakte können Software, Bilder und alle anderen Binärdateien umfassen, die Ihre Komponente verwendet.
Wenn Ihre Komponente bereit ist, [testen Sie Ihre Komponente](test-components.md).
# Testen Sie AWS IoT Greengrass Komponenten mit lokalen Bereitstellungen
Wenn Sie eine Greengrass-Komponente auf einem Kerngerät entwickeln, können Sie eine lokale Bereitstellung erstellen, um sie zu installieren und zu testen. Folgen Sie den Schritten in diesem Abschnitt, um eine lokale Bereitstellung zu erstellen.
Wenn Sie die Komponente auf einem anderen Computer entwickeln, z. B. auf einem lokalen Entwicklungscomputer, können Sie keine lokale Bereitstellung erstellen. Veröffentlichen Sie die Komponente stattdessen im AWS IoT Greengrass Service, sodass Sie sie auf Greengrass-Core-Geräten bereitstellen können, um sie zu testen. Weitere Informationen erhalten Sie unter [Veröffentlichen Sie Komponenten zur Bereitstellung auf Ihren Kerngeräten](publish-components.md) und [AWS IoT Greengrass Komponenten auf Geräten bereitstellen](manage-deployments.md).
**Um eine Komponente auf einem Greengrass-Core-Gerät zu testen**
1. Das Kerngerät protokolliert Ereignisse wie Komponenten-Updates. Sie können diese Protokolldatei einsehen, um Fehler an Ihrer Komponente zu erkennen und zu beheben, z. B. ein ungültiges Rezept. In dieser Protokolldatei werden auch Meldungen angezeigt, die Ihre Komponente als Standardausgabe (stdout) ausgibt. Wir empfehlen Ihnen, eine zusätzliche Terminalsitzung auf Ihrem Kerngerät zu eröffnen, um neue Protokollnachrichten in Echtzeit zu beobachten. Öffnen Sie eine neue Terminalsitzung, z. B. über SSH, und führen Sie den folgenden Befehl aus, um die Protokolle anzuzeigen. `/greengrass/v2`Ersetzen Sie es durch den Pfad zum AWS IoT Greengrass Stammordner.
------
#### [ Linux or Unix ]
```
sudo tail -f /greengrass/v2/logs/greengrass.log
```
------
#### [ PowerShell ]
```
gc C:\greengrass\v2\logs\greengrass.log -Tail 10 -Wait
```
------
Sie können auch die Protokolldatei für Ihre Komponente einsehen.
------
#### [ Linux or Unix ]
```
sudo tail -f /greengrass/v2/logs/com.example.HelloWorld.log
```
------
#### [ PowerShell ]
```
gc C:\greengrass\v2\logs\com.example.HelloWorld.log -Tail 10 -Wait
```
------
1. Führen Sie in Ihrer ursprünglichen Terminalsitzung den folgenden Befehl aus, um das Kerngerät mit Ihrer Komponente zu aktualisieren. `/greengrass/v2`Ersetzen Sie durch den Pfad zum AWS IoT Greengrass Stammordner und *\$1/greengrassv2* ersetzen Sie ihn durch den Pfad zu Ihrem lokalen Entwicklungsordner.
------
#### [ Linux or Unix ]
```
sudo /greengrass/v2/bin/greengrass-cli deployment create \
--recipeDir ~/greengrassv2/recipes \
--artifactDir ~/greengrassv2/artifacts \
--merge "com.example.HelloWorld=1.0.0"
```
------
#### [ Windows Command Prompt (CMD) ]
```
C:\greengrass\v2\bin\greengrass-cli deployment create ^
--recipeDir %USERPROFILE%\greengrassv2\recipes ^
--artifactDir %USERPROFILE%\greengrassv2\artifacts ^
--merge "com.example.HelloWorld=1.0.0"
```
------
#### [ PowerShell ]
```
C:\greengrass\v2\bin\greengrass-cli deployment create `
--recipeDir ~/greengrassv2/recipes `
--artifactDir ~/greengrassv2/artifacts `
--merge "com.example.HelloWorld=1.0.0"
```
------
**Anmerkung**
Sie können den `greengrass-cli deployment create` Befehl auch verwenden, um den Wert der Konfigurationsparameter Ihrer Komponente festzulegen. Weitere Informationen finden Sie unter [create](gg-cli-deployment.md#deployment-create).
1. Verwenden Sie den `greengrass-cli deployment status` Befehl, um den Fortschritt der Bereitstellung Ihrer Komponente zu überwachen.
------
#### [ Unix or Linux ]
```
sudo /greengrass/v2/bin/greengrass-cli deployment status \
-i deployment-id
```
------
#### [ Windows Command Prompt (CMD) ]
```
C:\greengrass\v2\bin\greengrass-cli deployment status ^
-i deployment-id
```
------
#### [ PowerShell ]
```
C:\greengrass\v2\bin\greengrass-cli deployment status `
-i deployment-id
```
------
1. Testen Sie Ihre Komponente, während sie auf dem Greengrass-Core-Gerät läuft. Wenn Sie diese Version Ihrer Komponente fertiggestellt haben, können Sie sie in den AWS IoT Greengrass Dienst hochladen. Anschließend können Sie die Komponente auf anderen Core-Geräten bereitstellen. Weitere Informationen finden Sie unter [Veröffentlichen Sie Komponenten zur Bereitstellung auf Ihren Kerngeräten](publish-components.md).
# Veröffentlichen Sie Komponenten zur Bereitstellung auf Ihren Kerngeräten
Nachdem Sie eine Version einer Komponente erstellt oder fertiggestellt haben, können Sie sie im AWS IoT Greengrass Service veröffentlichen. Anschließend können Sie es auf Greengrass-Kerngeräten bereitstellen.
Wenn Sie die [Greengrass Development Kit CLI (GDK CLI)](greengrass-development-kit-cli.md) verwenden, um [eine Komponente zu entwickeln und zu erstellen](create-components.md), können Sie die [GDK-CLI verwenden, um die](#publish-component-gdk-cli) Komponente auf der zu veröffentlichen. AWS Cloud[Verwenden Sie andernfalls die integrierten Shell-Befehle und die, AWS CLI um die Komponente](#publish-component-shell-commands) zu veröffentlichen.
Sie können es auch verwenden AWS CloudFormation , um Komponenten und andere AWS Ressourcen aus Vorlagen zu erstellen. Weitere Informationen finden Sie unter [Was ist AWS CloudFormation?](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) und [https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-greengrassv2-componentversion.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-greengrassv2-componentversion.html) im *AWS CloudFormation -Benutzerhandbuch*.
**Topics**
+ [Eine Komponente veröffentlichen (GDK CLI)](#publish-component-gdk-cli)
+ [Veröffentlichen Sie eine Komponente (Shell-Befehle)](#publish-component-shell-commands)
## Eine Komponente veröffentlichen (GDK CLI)
Folgen Sie den Anweisungen in diesem Abschnitt, um eine Komponente mit der GDK-CLI zu veröffentlichen. Die GDK-CLI lädt Build-Artefakte in einen S3-Bucket hoch, aktualisiert das Artefakt URIs im Rezept und erstellt die Komponente aus dem Rezept. Sie geben den S3-Bucket und die Region an, die in der [GDK-CLI-Konfigurationsdatei](gdk-cli-configuration-file.md) verwendet werden sollen.
Wenn Sie GDK CLI v1.1.0 oder höher verwenden, können Sie das `--bucket` Argument angeben, um den S3-Bucket anzugeben, in den die GDK-CLI die Artefakte der Komponente hochlädt. Wenn Sie dieses Argument nicht angeben, lädt die GDK-CLI in den S3-Bucket hoch, dessen Name`bucket-region-accountId`, wo *bucket* und *region* sind die Werte, in denen Sie angeben`gdk-config.json`, *accountId* ist und der Ihre AWS-Konto ID ist. Die GDK-CLI erstellt den Bucket, falls er nicht existiert.
**Wichtig**
Core-Geräterollen erlauben standardmäßig keinen Zugriff auf S3-Buckets. Wenn Sie diesen S3-Bucket zum ersten Mal verwenden, müssen Sie der Rolle Berechtigungen hinzufügen, damit Kerngeräte Komponentenartefakte aus diesem S3-Bucket abrufen können. 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).
**Um eine Greengrass-Komponente zu veröffentlichen (GDK CLI)**
1. Öffnen Sie den Komponentenordner in einer Befehlszeile oder einem Terminal.
1. Falls Sie es noch nicht getan haben, erstellen Sie die Greengrass-Komponente. Der Befehl zum [Erstellen von Komponenten](greengrass-development-kit-cli-component.md#greengrass-development-kit-cli-component-build) erzeugt ein Rezept und Artefakte in dem `greengrass-build` Ordner im Komponentenordner. Führen Sie den folgenden Befehl aus.
```
gdk component build
```
1. Publizieren Sie die Komponente im AWS Cloud. Der Befehl zum [Veröffentlichen](greengrass-development-kit-cli-component.md#greengrass-development-kit-cli-component-publish) von Komponenten lädt die Artefakte der Komponente auf Amazon S3 hoch und aktualisiert das Rezept der Komponente mit der URI jedes Artefakts. Anschließend wird die Komponente im Service erstellt. AWS IoT Greengrass
**Anmerkung**
AWS IoT Greengrass berechnet den Digest jedes Artefakts, wenn Sie die Komponente erstellen. Das bedeutet, dass Sie die Artefaktdateien in Ihrem S3-Bucket nicht ändern können, nachdem Sie eine Komponente erstellt haben. Wenn Sie dies tun, schlagen Bereitstellungen fehl, die diese Komponente enthalten, da der Datei-Digest nicht übereinstimmt. Wenn Sie eine Artefaktdatei ändern, müssen Sie eine neue Version der Komponente erstellen.
Wenn Sie in der GDK-CLI-Konfigurationsdatei `NEXT_PATCH` für die Komponentenversion angeben, verwendet die GDK-CLI die nächste Patch-Version, die noch nicht im Dienst vorhanden ist. AWS IoT Greengrass
Führen Sie den folgenden Befehl aus.
```
gdk component publish
```
Die Ausgabe gibt Ihnen die Version der Komponente an, die die GDK-CLI erstellt hat.
Nachdem Sie die Komponente veröffentlicht haben, können Sie die Komponente auf Kerngeräten bereitstellen. Weitere Informationen finden Sie unter [AWS IoT Greengrass Komponenten auf Geräten bereitstellen](manage-deployments.md).
## Veröffentlichen Sie eine Komponente (Shell-Befehle)
Gehen Sie wie folgt vor, um eine Komponente mithilfe von Shell-Befehlen und AWS Command Line Interface (AWS CLI) zu veröffentlichen. Wenn Sie eine Komponente veröffentlichen, gehen Sie wie folgt vor:
1. Veröffentlichen Sie Komponentenartefakte in einem S3-Bucket.
1. Fügen Sie die Amazon S3 S3-URI jedes Artefakts zum Komponentenrezept hinzu.
1. Erstellen Sie eine Komponentenversion AWS IoT Greengrass aus dem Komponentenrezept.
**Anmerkung**
Jede Komponentenversion, die Sie hochladen, muss eindeutig sein. Stellen Sie sicher, dass Sie die richtige Komponentenversion hochladen, da Sie sie nach dem Hochladen nicht mehr bearbeiten können.
Sie können diesen Schritten folgen, um eine Komponente von Ihrem Entwicklungscomputer oder Ihrem Greengrass-Core-Gerät aus zu veröffentlichen.
**Um eine Komponente zu veröffentlichen (Shell-Befehle)**
1. Wenn die Komponente eine Version verwendet, die im AWS IoT Greengrass Service vorhanden ist, müssen Sie die Version der Komponente ändern. Öffnen Sie das Rezept in einem Texteditor, erhöhen Sie die Version und speichern Sie die Datei. Wählen Sie eine neue Version, die die Änderungen widerspiegelt, die Sie an der Komponente vorgenommen haben.
**Anmerkung**
AWS IoT Greengrass verwendet semantische Versionen für Komponenten. *Semantische Versionen folgen einem Hauptteil.* *unbedeutend*. *Patch-Nummernsystem*. Version `1.0.0` steht beispielsweise für die erste Hauptversion einer Komponente. Weitere Informationen finden Sie in der [semantischen Versionsspezifikation](https://semver.org/).
1. Wenn Ihre Komponente Artefakte enthält, gehen Sie wie folgt vor:
1. Veröffentlichen Sie die Artefakte der Komponente in einem S3-Bucket in Ihrem AWS-Konto.
**Tipp**
Wir empfehlen, dass Sie den Namen und die Version der Komponente in den Pfad zum Artefakt im S3-Bucket aufnehmen. Dieses Benennungsschema kann Ihnen helfen, die Artefakte beizubehalten, die in früheren Versionen der Komponente verwendet wurden, sodass Sie frühere Komponentenversionen weiterhin unterstützen können.
Führen Sie den folgenden Befehl aus, um eine Artefaktdatei in einem S3-Bucket zu veröffentlichen. Ersetzen Sie amzn-s3-demo-bucket durch den Namen des Buckets und durch *artifacts/com.example.HelloWorld/1.0.0/artifact.py* den Pfad zur Artefaktdatei.
```
aws s3 cp artifacts/com.example.HelloWorld/1.0.0/artifact.py s3://amzn-s3-demo-bucket/artifacts/com.example.HelloWorld/1.0.0/artifact.py
```
**Wichtig**
Core-Geräterollen ermöglichen standardmäßig keinen Zugriff auf S3-Buckets. Wenn Sie diesen S3-Bucket zum ersten Mal verwenden, müssen Sie der Rolle Berechtigungen hinzufügen, damit Kerngeräte Komponentenartefakte aus diesem S3-Bucket abrufen können. 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).
1. Fügen Sie dem Komponentenrezept eine Liste mit einem Namen `Artifacts` hinzu, falls diese nicht vorhanden ist. Die `Artifacts` Liste erscheint in jedem Manifest, das die Anforderungen der Komponente auf jeder Plattform definiert, die sie unterstützt (oder die Standardanforderungen der Komponente für alle Plattformen).
1. Fügen Sie jedes Artefakt zur Liste der Artefakte hinzu, oder aktualisieren Sie die URI vorhandener Artefakte. Die Amazon S3 S3-URI besteht aus dem Bucket-Namen und dem Pfad zum Artefaktobjekt im Bucket. Der Amazon S3 Ihrer Artefakte URIs sollte dem folgenden Beispiel ähneln.
```
s3://amzn-s3-demo-bucket/artifacts/com.example.HelloWorld/1.0.0/artifact.py
```
Nachdem Sie diese Schritte abgeschlossen haben, sollte Ihr Rezept eine `Artifacts` Liste enthalten, die wie die folgende aussieht.
------
#### [ JSON ]
```
{
...
"Manifests": [
{
"Lifecycle": {
...
},
"Artifacts": [
{
"URI": "s3://amzn-s3-demo-bucket/artifacts/MyGreengrassComponent/1.0.0/artifact.py",
"Unarchive": "NONE"
}
]
}
]
}
```
**Anmerkung**
Sie können die `"Unarchive": "ZIP"` Option für ein ZIP-Artefakt hinzufügen, um die AWS IoT Greengrass Core-Software so zu konfigurieren, dass das Artefakt bei der Bereitstellung der Komponente entpackt wird.
------
#### [ YAML ]
```
...
Manifests:
- Lifecycle:
...
Artifacts:
- URI: s3://amzn-s3-demo-bucket/artifacts/MyGreengrassComponent/1.0.0/artifact.py
Unarchive: NONE
```
**Anmerkung**
Sie können die `Unarchive: ZIP` Option verwenden, um die AWS IoT Greengrass Core-Software so zu konfigurieren, dass ein ZIP-Artefakt entpackt wird, wenn die Komponente bereitgestellt wird. Weitere Informationen zur Verwendung von ZIP-Artefakten in einer Komponente finden Sie in der Rezeptvariablen [artifacts:decompressedPath](component-recipe-reference.md#component-recipe-artifacts-decompressed-path).
------
Weitere Informationen zu Rezepten finden Sie unter [AWS IoT Greengrass Referenz zum Komponenten-Rezept](component-recipe-reference.md).
1. Verwenden Sie die AWS IoT Greengrass Konsole, um eine Komponente aus der Rezeptdatei zu erstellen.
Führen Sie den folgenden Befehl aus, um die Komponente aus einer Rezeptdatei zu erstellen. Dieser Befehl erstellt die Komponente und veröffentlicht sie als private AWS IoT Greengrass Komponente in Ihrem AWS-Konto. *path/to/recipeFile*Ersetzen Sie es durch den Pfad zur Rezeptdatei.
```
aws greengrassv2 create-component-version --inline-recipe fileb://path/to/recipeFile
```
Kopieren Sie das `arn` aus der Antwort, um im nächsten Schritt den Status der Komponente zu überprüfen.
**Anmerkung**
AWS IoT Greengrass berechnet den Digest jedes Artefakts, wenn Sie die Komponente erstellen. Das bedeutet, dass Sie die Artefaktdateien in Ihrem S3-Bucket nicht ändern können, nachdem Sie eine Komponente erstellt haben. Wenn Sie dies tun, schlagen Bereitstellungen fehl, die diese Komponente enthalten, da der Datei-Digest nicht übereinstimmt. Wenn Sie eine Artefaktdatei ändern, müssen Sie eine neue Version der Komponente erstellen.
1. Jede Komponente im AWS IoT Greengrass Service hat einen Status. Führen Sie den folgenden Befehl aus, um den Status der Komponentenversion zu überprüfen, die Sie in diesem Verfahren veröffentlichen. Ersetzen Sie *com.example.HelloWorld* und *1.0.0* durch die abzufragende Komponentenversion. Ersetzen Sie das `arn` durch den ARN aus dem vorherigen Schritt.
```
aws greengrassv2 describe-component --arn "arn:aws:greengrass:region:account-id:components:com.example.HelloWorld:versions:1.0.0"
```
Der Vorgang gibt eine Antwort zurück, die die Metadaten der Komponente enthält. Die Metadaten enthalten ein `status` Objekt, das den Status der Komponente und etwaige Fehler enthält.
Wenn der Komponentenstatus lautet`DEPLOYABLE`, können Sie die Komponente auf Geräten bereitstellen. Weitere Informationen finden Sie unter [AWS IoT Greengrass Komponenten auf Geräten bereitstellen](manage-deployments.md).
# Interagieren Sie mit AWS Diensten
Greengrass-Core-Geräte verwenden X.509-Zertifikate, um AWS IoT Core mithilfe von TLS-Protokollen für die gegenseitige Authentifizierung eine Verbindung herzustellen. Mit diesen Zertifikaten können Geräte AWS IoT ohne AWS Anmeldeinformationen interagieren, die in der Regel aus einer Zugriffsschlüssel-ID und einem geheimen Zugriffsschlüssel bestehen. Andere AWS Dienste benötigen AWS Anmeldeinformationen anstelle von X.509-Zertifikaten, um API-Operationen an Dienstendpunkten aufzurufen. AWS IoT Core hat einen Anbieter für Anmeldeinformationen, der es Geräten ermöglicht, ihr X.509-Zertifikat zur Authentifizierung von Anfragen zu verwenden. AWS Der Anbieter AWS IoT für Anmeldeinformationen authentifiziert Geräte mithilfe eines X.509-Zertifikats und gibt AWS Anmeldeinformationen in Form eines temporären Sicherheitstokens mit eingeschränkten Rechten aus. Geräte können dieses Token verwenden, um jede Anfrage zu signieren und zu authentifizieren. AWS Dadurch entfällt die Notwendigkeit, AWS Anmeldeinformationen auf Greengrass-Core-Geräten zu speichern. Weitere Informationen finden Sie unter [Autorisieren von direkten Aufrufen von AWS Diensten](https://docs.aws.amazon.com/iot/latest/developerguide/authorizing-direct-aws.html) im *AWS IoT Core Entwicklerhandbuch*.
Um Anmeldeinformationen von Greengrass abzurufen AWS IoT, verwenden Kerngeräte einen AWS IoT Rollenalias, der auf eine IAM-Rolle verweist. *Diese IAM-Rolle wird Token-Exchange-Rolle genannt.* Sie erstellen den Rollenalias und die Token-Austauschrolle, wenn Sie die AWS IoT Greengrass Core-Software installieren. Um den Rollenalias anzugeben, den ein Core-Gerät verwendet, konfigurieren Sie den `iotRoleAlias` Parameter von[Grüngraskern](greengrass-nucleus-component.md).
Der Anbieter AWS IoT für Anmeldeinformationen übernimmt in Ihrem Namen die Rolle des Tokenaustauschs, um AWS Anmeldeinformationen für Kerngeräte bereitzustellen. Sie können dieser Rolle entsprechende IAM-Richtlinien zuordnen, um Ihren Kerngeräten den Zugriff auf Ihre AWS Ressourcen zu ermöglichen, z. B. auf Komponentenartefakte in S3-Buckets. Weitere Informationen zur Konfiguration der Token-Austauschrolle finden Sie unter. [Autorisieren Sie Kerngeräte für die Interaktion mit Diensten AWS](device-service-role.md)
Greengrass-Core-Geräte speichern AWS Anmeldeinformationen im Speicher, und die Anmeldeinformationen laufen standardmäßig nach einer Stunde ab. Wenn die AWS IoT Greengrass Core-Software neu gestartet wird, muss sie die Anmeldeinformationen erneut abrufen. Sie können den [UpdateRoleAlias](https://docs.aws.amazon.com/iot/latest/apireference/API_UpdateRoleAlias.html)Vorgang verwenden, um die Gültigkeitsdauer der Anmeldeinformationen zu konfigurieren.
AWS IoT Greengrass stellt eine öffentliche Komponente bereit, die Token-Exchange-Dienstkomponente, die Sie als Abhängigkeit in Ihrer benutzerdefinierten Komponente definieren können, um mit AWS Diensten zu interagieren. Der Token-Exchange-Dienst stellt Ihrer Komponente eine Umgebungsvariable zur Verfügung`AWS_CONTAINER_CREDENTIALS_FULL_URI`, die den URI für einen lokalen Server definiert, der AWS Anmeldeinformationen bereitstellt. Wenn Sie einen AWS SDK-Client erstellen, sucht der Client nach dieser Umgebungsvariablen und stellt eine Verbindung zum lokalen Server her, um AWS Anmeldeinformationen abzurufen, und verwendet sie zum Signieren von API-Anfragen. Auf diese Weise können Sie andere Tools verwenden AWS SDKs , um AWS Dienste in Ihren Komponenten aufzurufen. Weitere Informationen finden Sie unter [Token-Austauschdienst](token-exchange-service-component.md).
**Wichtig**
Die Support für den Erwerb von AWS Anmeldeinformationen auf diese Weise wurde AWS SDKs am 13. Juli 2016 hinzugefügt. Ihre Komponente muss eine AWS SDK-Version verwenden, die an oder nach diesem Datum erstellt wurde. Weitere Informationen finden Sie unter [Verwenden eines unterstützten AWS SDK](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html#task-iam-roles-minimum-sdk) im *Amazon Elastic Container Service Developer Guide*.
Um AWS Anmeldeinformationen in Ihrer benutzerdefinierten Komponente abzurufen, definieren Sie `aws.greengrass.TokenExchangeService` sie als Abhängigkeit im Komponentenrezept. Das folgende Beispielrezept definiert eine Komponente, die [boto3](https://boto3.amazonaws.com/v1/documentation/api/latest/index.html) installiert und ein Python-Skript ausführt, das AWS Anmeldeinformationen vom Token-Exchange-Service verwendet, um Amazon S3 S3-Buckets aufzulisten.
**Anmerkung**
Um diese Beispielkomponente ausführen zu können, muss Ihr Gerät über die entsprechende Berechtigung verfügen. `s3:ListAllMyBuckets` Weitere Informationen finden Sie unter [Autorisieren Sie Kerngeräte für die Interaktion mit Diensten AWS](device-service-role.md).
------
#### [ JSON ]
```
{
"RecipeFormatVersion": "2020-01-25",
"ComponentName": "com.example.ListS3Buckets",
"ComponentVersion": "1.0.0",
"ComponentDescription": "A component that uses the token exchange service to list S3 buckets.",
"ComponentPublisher": "Amazon",
"ComponentDependencies": {
"aws.greengrass.TokenExchangeService": {
"VersionRequirement": "^2.0.0",
"DependencyType": "HARD"
}
},
"Manifests": [
{
"Platform": {
"os": "linux"
},
"Lifecycle": {
"install": "pip3 install --user boto3",
"Run": "python3 -u {artifacts:path}/list_s3_buckets.py"
}
},
{
"Platform": {
"os": "windows"
},
"Lifecycle": {
"install": "pip3 install --user boto3",
"Run": "py -3 -u {artifacts:path}/list_s3_buckets.py"
}
}
]
}
```
------
#### [ YAML ]
```
---
RecipeFormatVersion: '2020-01-25'
ComponentName: com.example.ListS3Buckets
ComponentVersion: '1.0.0'
ComponentDescription: A component that uses the token exchange service to list S3 buckets.
ComponentPublisher: Amazon
ComponentDependencies:
aws.greengrass.TokenExchangeService:
VersionRequirement: '^2.0.0'
DependencyType: HARD
Manifests:
- Platform:
os: linux
Lifecycle:
install:
pip3 install --user boto3
Run: |-
python3 -u {artifacts:path}/list_s3_buckets.py
- Platform:
os: windows
Lifecycle:
install:
pip3 install --user boto3
Run: |-
py -3 -u {artifacts:path}/list_s3_buckets.py
```
------
Diese Beispielkomponente führt das folgende Python-Skript aus, `list_s3_buckets.py` das Amazon S3 S3-Buckets auflistet.
```
import boto3
import os
try:
print("Creating boto3 S3 client...")
s3 = boto3.client('s3')
print("Successfully created boto3 S3 client")
except Exception as e:
print("Failed to create boto3 s3 client. Error: " + str(e))
exit(1)
try:
print("Listing S3 buckets...")
response = s3.list_buckets()
for bucket in response['Buckets']:
print(f'\t{bucket["Name"]}')
print("Successfully listed S3 buckets")
except Exception as e:
print("Failed to list S3 buckets. Error: " + str(e))
exit(1)
```
# Führen Sie einen Docker-Container aus
Sie können AWS IoT Greengrass Komponenten so konfigurieren, dass sie einen [Docker-Container](https://www.docker.com/) aus Images ausführen, die an den folgenden Speicherorten gespeichert sind:
+ Öffentliche und private Image-Repositorys in Amazon Elastic Container Registry (Amazon ECR)
+ Öffentliches Docker Hub-Repository
+ Vertrauenswürdiges öffentliches Docker-Register
+ S3-Bucket
Fügen Sie in Ihrer benutzerdefinierten Komponente den Docker-Image-URI als Artefakt ein, um das Image abzurufen und auf dem Kerngerät auszuführen. Für Amazon ECR- und Docker Hub-Images können Sie die [Docker Application Manager-Komponente](docker-application-manager-component.md) verwenden, um die Images herunterzuladen und Anmeldeinformationen für private Amazon ECR-Repositorys zu verwalten.
**Topics**
+ [Voraussetzungen](#run-docker-container-requirements)
+ [Führen Sie einen Docker-Container von einem öffentlichen Image in Amazon ECR oder Docker Hub aus](#run-docker-container-public-ecr-dockerhub)
+ [Führen Sie einen Docker-Container von einem privaten Image in Amazon ECR aus](#run-docker-container-private-ecr)
+ [Führen Sie einen Docker-Container von einem Image in Amazon S3 aus](#run-docker-container-s3)
+ [Verwenden Sie die Interprozesskommunikation in Docker-Container-Komponenten](#docker-container-ipc)
+ [Verwenden Sie AWS Anmeldeinformationen in Docker-Container-Komponenten (Linux)](#docker-container-token-exchange-service)
+ [Verwenden Sie den Stream-Manager in Docker-Container-Komponenten (Linux)](#docker-container-stream-manager)
## Voraussetzungen
Um einen Docker-Container in einer Komponente auszuführen, benötigen Sie Folgendes:
+ Ein Greengrass-Core-Gerät. Falls Sie noch keines haben, beachten Sie die Informationen unter [Tutorial: Erste Schritte mit AWS IoT Greengrass V2](getting-started.md).
+ [Docker Engine](https://docs.docker.com/engine/) 1.9.1 oder höher ist auf dem Greengrass-Core-Gerät installiert. Version 20.10 ist die neueste Version, für die verifiziert wurde, dass sie mit der Core-Software funktioniert. AWS IoT Greengrass Sie müssen Docker direkt auf dem Kerngerät installieren, bevor Sie Komponenten bereitstellen, auf denen Docker-Container ausgeführt werden.
**Tipp**
Sie können das Kerngerät auch so konfigurieren, dass die Docker Engine bei der Installation der Komponente installiert wird. Das folgende Installationsskript installiert beispielsweise die Docker Engine, bevor das Docker-Image geladen wird. Dieses Installationsskript funktioniert auf Debian-basierten Linux-Distributionen wie Ubuntu. Wenn Sie die Komponente für die Installation von Docker Engine mit diesem Befehl konfigurieren, müssen Sie möglicherweise `true` im Lifecycle-Skript auf einstellen, `RequiresPrivilege` um die Installation und die Befehle auszuführen. `docker` Weitere Informationen finden Sie unter [AWS IoT Greengrass Referenz zum Komponenten-Rezept](component-recipe-reference.md).
```
apt-get install docker-ce docker-ce-cli containerd.io && docker load -i {artifacts:path}/hello-world.tar
```
+ Der Systembenutzer, der eine Docker-Container-Komponente ausführt, muss über Root- oder Administratorrechte verfügen, oder Sie müssen Docker so konfigurieren, dass es als Benutzer ohne Root- oder Administratorrechte ausgeführt wird.
+ Auf Linux-Geräten können Sie der Gruppe einen Benutzer hinzufügen, um Befehle ohne Befehle `docker` aufzurufen. `docker` `sudo`
+ Auf Windows-Geräten können Sie der `docker-users` Gruppe einen Benutzer hinzufügen, um `docker` Befehle ohne Administratorrechte aufzurufen.
------
#### [ Linux or Unix ]
Führen Sie den folgenden Befehl aus`ggc_user`, um der `docker` Gruppe einen Nicht-Root-Benutzer, den Sie zum Ausführen von Docker-Container-Komponenten verwenden, hinzuzufügen.
```
sudo usermod -aG docker ggc_user
```
Weitere Informationen finden Sie unter [Docker als Nicht-Root-Benutzer verwalten](https://docs.docker.com/engine/install/linux-postinstall/#manage-docker-as-a-non-root-user).
------
#### [ Windows Command Prompt (CMD) ]
Um der `docker-users` Gruppe den Benutzer`ggc_user`, den Sie zum Ausführen von Docker-Container-Komponenten verwenden, hinzuzufügen, führen Sie den folgenden Befehl als Administrator aus.
```
net localgroup docker-users ggc_user /add
```
------
#### [ Windows PowerShell ]
Um der `docker-users` Gruppe den Benutzer`ggc_user`, den Sie zum Ausführen von Docker-Container-Komponenten verwenden, hinzuzufügen, führen Sie den folgenden Befehl als Administrator aus.
```
Add-LocalGroupMember -Group docker-users -Member ggc_user
```
------
+ Dateien, auf die die Docker-Container-Komponente zugreift, die [als Volume im Docker-Container gemountet](https://docs.docker.com/storage/volumes/) ist.
+ Wenn Sie [die AWS IoT Greengrass Core-Software für die Verwendung eines Netzwerk-Proxys [konfigurieren, müssen Sie Docker für die Verwendung desselben](https://docs.docker.com/network/proxy/) Proxyservers](configure-greengrass-core-v2.md#configure-alpn-network-proxy) konfigurieren.
Zusätzlich zu diesen Anforderungen müssen Sie auch die folgenden Anforderungen erfüllen, wenn sie für Ihre Umgebung gelten:
+ Um [Docker Compose](https://docs.docker.com/compose/) zum Erstellen und Starten Ihrer Docker-Container zu verwenden, installieren Sie Docker Compose auf Ihrem Greengrass-Core-Gerät und laden Sie Ihre Docker Compose-Datei in einen S3-Bucket hoch. Sie müssen Ihre Compose-Datei in einem S3-Bucket im selben und wie AWS-Konto die Komponente speichern. AWS-Region Ein Beispiel, das den `docker-compose up` Befehl in einer benutzerdefinierten Komponente verwendet, finden Sie unter[Führen Sie einen Docker-Container von einem öffentlichen Image in Amazon ECR oder Docker Hub aus](#run-docker-container-public-ecr-dockerhub).
+ Wenn Sie AWS IoT Greengrass hinter einem Netzwerk-Proxy laufen, konfigurieren Sie den Docker-Daemon für die Verwendung eines [Proxyservers](https://docs.docker.com/network/proxy/).
+ Wenn Ihre Docker-Images in Amazon ECR oder Docker Hub gespeichert sind, fügen Sie die [Komponente Docker Component Manager](docker-application-manager-component.md) als Abhängigkeit in Ihre Docker-Container-Komponente ein. Sie müssen den Docker-Daemon auf dem Kerngerät starten, bevor Sie Ihre Komponente bereitstellen.
Fügen Sie das Bild auch URIs als Komponentenartefakte hinzu. Das Bild URIs muss das Format haben, `docker:registry/image[:tag|@digest]` das in den folgenden Beispielen gezeigt wird:
+ Privates Amazon ECR-Bild: `docker:account-id.dkr.ecr.region.amazonaws.com/repository/image[:tag|@digest]`
+ Öffentliches Amazon ECR-Bild: `docker:public.ecr.aws/repository/image[:tag|@digest]`
+ Öffentliches Docker Hub-Bild: `docker:name[:tag|@digest]`
Weitere Informationen zum Ausführen von Docker-Containern aus Images, die in öffentlichen Repositorys gespeichert sind, finden Sie unter. [Führen Sie einen Docker-Container von einem öffentlichen Image in Amazon ECR oder Docker Hub aus](#run-docker-container-public-ecr-dockerhub)
+ Wenn Ihre Docker-Images in einem privaten Amazon ECR-Repository gespeichert sind, müssen Sie die Token-Exchange-Servicekomponente als Abhängigkeit in die Docker-Container-Komponente aufnehmen. Außerdem muss die [Greengrass-Geräterolle](device-service-role.md) die `ecr:GetDownloadUrlForLayer` Aktionen `ecr:GetAuthorizationToken``ecr:BatchGetImage`, und zulassen, wie in der folgenden IAM-Beispielrichtlinie gezeigt.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ecr:GetAuthorizationToken",
"ecr:BatchGetImage",
"ecr:GetDownloadUrlForLayer"
],
"Resource": [
"*"
],
"Effect": "Allow"
}
]
}
```
------
Informationen zum Ausführen von Docker-Containern aus Images, die in einem privaten Amazon ECR-Repository gespeichert sind, finden Sie unter. [Führen Sie einen Docker-Container von einem privaten Image in Amazon ECR aus](#run-docker-container-private-ecr)
+ Um Docker-Images zu verwenden, die in einem privaten Amazon ECR-Repository gespeichert sind, muss sich das private Repository auf demselben Gerät befinden AWS-Region wie das Kerngerät.
+ Wenn Ihre Docker-Images oder Compose-Dateien in einem S3-Bucket gespeichert sind, muss die [Greengrass-Geräterolle](device-service-role.md) die `s3:GetObject` Berechtigung gewähren, Kerngeräten das Herunterladen der Images als Komponentenartefakte zu gestatten, wie in der folgenden IAM-Beispielrichtlinie gezeigt.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"s3:GetObject"
],
"Resource": [
"*"
],
"Effect": "Allow"
}
]
}
```
------
Informationen zum Ausführen von Docker-Containern aus in Amazon S3 gespeicherten Bildern finden Sie unter[Führen Sie einen Docker-Container von einem Image in Amazon S3 aus](#run-docker-container-s3).
+ Um Interprozesskommunikation (IPC), AWS Anmeldeinformationen oder Stream Manager in Ihrer Docker-Container-Komponente zu verwenden, müssen Sie bei der Ausführung des Docker-Containers zusätzliche Optionen angeben. Weitere Informationen finden Sie hier:
+ [Verwenden Sie die Interprozesskommunikation in Docker-Container-Komponenten](#docker-container-ipc)
+ [Verwenden Sie AWS Anmeldeinformationen in Docker-Container-Komponenten (Linux)](#docker-container-token-exchange-service)
+ [Verwenden Sie den Stream-Manager in Docker-Container-Komponenten (Linux)](#docker-container-stream-manager)
## Führen Sie einen Docker-Container von einem öffentlichen Image in Amazon ECR oder Docker Hub aus
In diesem Abschnitt wird beschrieben, wie Sie eine benutzerdefinierte Komponente erstellen können, die Docker Compose verwendet, um einen Docker-Container aus Docker-Images auszuführen, die in Amazon ECR und Docker Hub gespeichert sind.
**Um einen Docker-Container mit Docker Compose auszuführen**
1. Erstellen Sie eine Docker Compose-Datei und laden Sie sie in einen Amazon S3 S3-Bucket hoch. Stellen Sie sicher, dass die [Greengrass-Geräterolle](device-service-role.md) die `s3:GetObject` Erlaubnis erteilt, dem Gerät den Zugriff auf die Compose-Datei zu ermöglichen. Die im folgenden Beispiel gezeigte Compose-Beispieldatei enthält das Amazon CloudWatch Agent-Image von Amazon ECR und das MySQL-Image von Docker Hub.
```
version: "3"
services:
cloudwatchagent:
image: "public.ecr.aws/cloudwatch-agent/cloudwatch-agent:latest"
mysql:
image: "mysql:8.0"
```
1. [Erstellen Sie eine benutzerdefinierte Komponente](create-components.md) auf Ihrem AWS IoT Greengrass Kerngerät. Das im folgenden Beispiel gezeigte Beispielrezept hat die folgenden Eigenschaften:
+ Die Docker-Anwendungsmanager-Komponente als Abhängigkeit. Diese Komponente ermöglicht AWS IoT Greengrass das Herunterladen von Bildern aus öffentlichen Amazon ECR- und Docker Hub-Repositorys.
+ Ein Komponentenartefakt, das ein Docker-Image in einem öffentlichen Amazon ECR-Repository spezifiziert.
+ Ein Komponentenartefakt, das ein Docker-Image in einem öffentlichen Docker Hub-Repository spezifiziert.
+ Ein Komponentenartefakt, das die Docker Compose-Datei spezifiziert, die Container für die Docker-Images enthält, die Sie ausführen möchten.
+ Ein Lifecycle-Run-Skript, das [Docker-Compose verwendet, um](https://docs.docker.com/compose/reference/up/) einen Container aus den angegebenen Images zu erstellen und zu starten.
------
#### [ JSON ]
```
{
"RecipeFormatVersion": "2020-01-25",
"ComponentName": "com.example.MyDockerComposeComponent",
"ComponentVersion": "1.0.0",
"ComponentDescription": "A component that uses Docker Compose to run images from public Amazon ECR and Docker Hub.",
"ComponentPublisher": "Amazon",
"ComponentDependencies": {
"aws.greengrass.DockerApplicationManager": {
"VersionRequirement": "~2.0.0"
}
},
"Manifests": [
{
"Platform": {
"os": "all"
},
"Lifecycle": {
"Run": "docker-compose -f {artifacts:path}/docker-compose.yaml up"
},
"Artifacts": [
{
"URI": "docker:public.ecr.aws/cloudwatch-agent/cloudwatch-agent:latest"
},
{
"URI": "docker:mysql:8.0"
},
{
"URI": "s3://amzn-s3-demo-bucket/folder/docker-compose.yaml"
}
]
}
]
}
```
------
#### [ YAML ]
```
---
RecipeFormatVersion: '2020-01-25'
ComponentName: com.example.MyDockerComposeComponent
ComponentVersion: '1.0.0'
ComponentDescription: 'A component that uses Docker Compose to run images from public Amazon ECR and Docker Hub.'
ComponentPublisher: Amazon
ComponentDependencies:
aws.greengrass.DockerApplicationManager:
VersionRequirement: ~2.0.0
Manifests:
- Platform:
os: all
Lifecycle:
Run: docker-compose -f {artifacts:path}/docker-compose.yaml up
Artifacts:
- URI: "docker:public.ecr.aws/cloudwatch-agent/cloudwatch-agent:latest"
- URI: "docker:mysql:8.0"
- URI: "s3://amzn-s3-demo-bucket/folder/docker-compose.yaml"
```
------
**Anmerkung**
Um Interprozesskommunikation (IPC), AWS Anmeldeinformationen oder Stream Manager in Ihrer Docker-Container-Komponente zu verwenden, müssen Sie bei der Ausführung des Docker-Containers zusätzliche Optionen angeben. Weitere Informationen finden Sie hier:
[Verwenden Sie die Interprozesskommunikation in Docker-Container-Komponenten](#docker-container-ipc)
[Verwenden Sie AWS Anmeldeinformationen in Docker-Container-Komponenten (Linux)](#docker-container-token-exchange-service)
[Verwenden Sie den Stream-Manager in Docker-Container-Komponenten (Linux)](#docker-container-stream-manager)
1. [Testen Sie die Komponente](test-components.md), um sicherzustellen, dass sie wie erwartet funktioniert.
**Wichtig**
Sie müssen den Docker-Daemon installieren und starten, bevor Sie die Komponente bereitstellen.
Nachdem Sie die Komponente lokal bereitgestellt haben, können Sie den Befehl [docker container ls](https://docs.docker.com/engine/reference/commandline/container_ls/) ausführen, um zu überprüfen, ob Ihr Container ausgeführt wird.
```
docker container ls
```
1. Wenn die Komponente bereit ist, laden Sie die Komponente hoch, AWS IoT Greengrass um sie auf anderen Kerngeräten bereitzustellen. Weitere Informationen finden Sie unter [Veröffentlichen Sie Komponenten zur Bereitstellung auf Ihren Kerngeräten](publish-components.md).
## Führen Sie einen Docker-Container von einem privaten Image in Amazon ECR aus
In diesem Abschnitt wird beschrieben, wie Sie eine benutzerdefinierte Komponente erstellen können, die einen Docker-Container aus einem Docker-Image ausführt, das in einem privaten Repository in Amazon ECR gespeichert ist.
**Um einen Docker-Container auszuführen**
1. [Erstellen Sie eine benutzerdefinierte Komponente](create-components.md) auf Ihrem AWS IoT Greengrass Kerngerät. Verwenden Sie das folgende Beispielrezept mit den folgenden Eigenschaften:
+ Die Docker-Anwendungsmanager-Komponente als Abhängigkeit. Diese Komponente ermöglicht die Verwaltung von Anmeldeinformationen AWS IoT Greengrass zum Herunterladen von Bildern aus privaten Repositorys.
+ Die Token-Exchange-Dienstkomponente als Abhängigkeit. Diese Komponente ermöglicht AWS IoT Greengrass das Abrufen von AWS Anmeldeinformationen für die Interaktion mit Amazon ECR.
+ Ein Komponentenartefakt, das ein Docker-Image in einem privaten Amazon ECR-Repository spezifiziert.
+ Ein Lifecycle-Run-Skript, das [Docker Run](https://docs.docker.com/engine/reference/commandline/run/) verwendet, um einen Container aus dem Image zu erstellen und zu starten.
------
#### [ JSON ]
```
{
"RecipeFormatVersion": "2020-01-25",
"ComponentName": "com.example.MyPrivateDockerComponent",
"ComponentVersion": "1.0.0",
"ComponentDescription": "A component that runs a Docker container from a private Amazon ECR image.",
"ComponentPublisher": "Amazon",
"ComponentDependencies": {
"aws.greengrass.DockerApplicationManager": {
"VersionRequirement": "~2.0.0"
},
"aws.greengrass.TokenExchangeService": {
"VersionRequirement": "~2.0.0"
}
},
"Manifests": [
{
"Platform": {
"os": "all"
},
"Lifecycle": {
"Run": "docker run account-id.dkr.ecr.region.amazonaws.com/repository[:tag|@digest]"
},
"Artifacts": [
{
"URI": "docker:account-id.dkr.ecr.region.amazonaws.com/repository[:tag|@digest]"
}
]
}
]
}
```
------
#### [ YAML ]
```
---
RecipeFormatVersion: '2020-01-25'
ComponentName: com.example.MyPrivateDockerComponent
ComponentVersion: '1.0.0'
ComponentDescription: 'A component that runs a Docker container from a private Amazon ECR image.'
ComponentPublisher: Amazon
ComponentDependencies:
aws.greengrass.DockerApplicationManager:
VersionRequirement: ~2.0.0
aws.greengrass.TokenExchangeService:
VersionRequirement: ~2.0.0
Manifests:
- Platform:
os: all
Lifecycle:
Run: docker run account-id.dkr.ecr.region.amazonaws.com/repository[:tag|@digest]
Artifacts:
- URI: "docker:account-id.dkr.ecr.region.amazonaws.com/repository[:tag|@digest]"
```
------
**Anmerkung**
Um Interprozesskommunikation (IPC), AWS Anmeldeinformationen oder Stream Manager in Ihrer Docker-Container-Komponente zu verwenden, müssen Sie bei der Ausführung des Docker-Containers zusätzliche Optionen angeben. Weitere Informationen finden Sie hier:
[Verwenden Sie die Interprozesskommunikation in Docker-Container-Komponenten](#docker-container-ipc)
[Verwenden Sie AWS Anmeldeinformationen in Docker-Container-Komponenten (Linux)](#docker-container-token-exchange-service)
[Verwenden Sie den Stream-Manager in Docker-Container-Komponenten (Linux)](#docker-container-stream-manager)
1. [Testen Sie die Komponente](test-components.md), um sicherzustellen, dass sie wie erwartet funktioniert.
**Wichtig**
Sie müssen den Docker-Daemon installieren und starten, bevor Sie die Komponente bereitstellen.
Nachdem Sie die Komponente lokal bereitgestellt haben, können Sie den Befehl [docker container ls](https://docs.docker.com/engine/reference/commandline/container_ls/) ausführen, um zu überprüfen, ob Ihr Container ausgeführt wird.
```
docker container ls
```
1. Laden Sie die Komponente hoch, AWS IoT Greengrass um sie auf anderen Kerngeräten bereitzustellen. Weitere Informationen finden Sie unter [Veröffentlichen Sie Komponenten zur Bereitstellung auf Ihren Kerngeräten](publish-components.md).
## Führen Sie einen Docker-Container von einem Image in Amazon S3 aus
In diesem Abschnitt wird beschrieben, wie Sie einen Docker-Container in einer Komponente von einem Docker-Image aus ausführen können, das in Amazon S3 gespeichert ist.
**So führen Sie einen Docker-Container in einer Komponente aus einem Image in Amazon S3 aus**
1. Führen Sie den Befehl [docker save](https://docs.docker.com/engine/reference/commandline/save/) aus, um ein Backup eines Docker-Containers zu erstellen. Sie stellen dieses Backup als Komponentenartefakt bereit, auf dem der Container ausgeführt werden kann. AWS IoT Greengrass*hello-world*Ersetzen Sie es durch den Namen des Images und *hello-world.tar* durch den Namen der zu erstellenden Archivdatei.
```
docker save hello-world > artifacts/com.example.MyDockerComponent/1.0.0/hello-world.tar
```
1. [Erstellen Sie eine benutzerdefinierte Komponente](create-components.md) auf Ihrem AWS IoT Greengrass Core-Gerät. Verwenden Sie das folgende Beispielrezept mit den folgenden Eigenschaften:
+ Ein Lifecycle-Installationsskript, das [Docker Load](https://docs.docker.com/engine/reference/commandline/load/) verwendet, um ein Docker-Image aus einem Archiv zu laden.
+ Ein Lifecycle-Run-Skript, das [Docker Run](https://docs.docker.com/engine/reference/commandline/run/) verwendet, um einen Container aus dem Image zu erstellen und zu starten. Die `--rm` Option bereinigt den Container, wenn er beendet wird.
------
#### [ JSON ]
```
{
"RecipeFormatVersion": "2020-01-25",
"ComponentName": "com.example.MyS3DockerComponent",
"ComponentVersion": "1.0.0",
"ComponentDescription": "A component that runs a Docker container from an image in an S3 bucket.",
"ComponentPublisher": "Amazon",
"Manifests": [
{
"Platform": {
"os": "linux"
},
"Lifecycle": {
"install": {
"Script": "docker load -i {artifacts:path}/hello-world.tar"
},
"Run": {
"Script": "docker run --rm hello-world"
}
}
}
]
}
```
------
#### [ YAML ]
```
---
RecipeFormatVersion: '2020-01-25'
ComponentName: com.example.MyS3DockerComponent
ComponentVersion: '1.0.0'
ComponentDescription: 'A component that runs a Docker container from an image in an S3 bucket.'
ComponentPublisher: Amazon
Manifests:
- Platform:
os: linux
Lifecycle:
install:
Script: docker load -i {artifacts:path}/hello-world.tar
Run:
Script: docker run --rm hello-world
```
------
**Anmerkung**
Um Interprozesskommunikation (IPC), AWS Anmeldeinformationen oder Stream Manager in Ihrer Docker-Container-Komponente zu verwenden, müssen Sie bei der Ausführung des Docker-Containers zusätzliche Optionen angeben. Weitere Informationen finden Sie hier:
[Verwenden Sie die Interprozesskommunikation in Docker-Container-Komponenten](#docker-container-ipc)
[Verwenden Sie AWS Anmeldeinformationen in Docker-Container-Komponenten (Linux)](#docker-container-token-exchange-service)
[Verwenden Sie den Stream-Manager in Docker-Container-Komponenten (Linux)](#docker-container-stream-manager)
1. [Testen Sie die Komponente](test-components.md), um sicherzustellen, dass sie wie erwartet funktioniert.
Nachdem Sie die Komponente lokal bereitgestellt haben, können Sie den Befehl [docker container ls](https://docs.docker.com/engine/reference/commandline/container_ls/) ausführen, um zu überprüfen, ob Ihr Container ausgeführt wird.
```
docker container ls
```
1. Wenn die Komponente bereit ist, laden Sie das Docker-Image-Archiv in einen S3-Bucket hoch und fügen Sie dessen URI dem Komponentenrezept hinzu. Anschließend können Sie die Komponente hochladen, AWS IoT Greengrass um sie auf anderen Kerngeräten bereitzustellen. Weitere Informationen finden Sie unter [Veröffentlichen Sie Komponenten zur Bereitstellung auf Ihren Kerngeräten](publish-components.md).
Wenn Sie fertig sind, sollte das Komponentenrezept wie im folgenden Beispiel aussehen.
------
#### [ JSON ]
```
{
"RecipeFormatVersion": "2020-01-25",
"ComponentName": "com.example.MyS3DockerComponent",
"ComponentVersion": "1.0.0",
"ComponentDescription": "A component that runs a Docker container from an image in an S3 bucket.",
"ComponentPublisher": "Amazon",
"Manifests": [
{
"Platform": {
"os": "linux"
},
"Lifecycle": {
"install": {
"Script": "docker load -i {artifacts:path}/hello-world.tar"
},
"Run": {
"Script": "docker run --rm hello-world"
}
},
"Artifacts": [
{
"URI": "s3://amzn-s3-demo-bucket/artifacts/com.example.MyDockerComponent/1.0.0/hello-world.tar"
}
]
}
]
}
```
------
#### [ YAML ]
```
---
RecipeFormatVersion: '2020-01-25'
ComponentName: com.example.MyS3DockerComponent
ComponentVersion: '1.0.0'
ComponentDescription: 'A component that runs a Docker container from an image in an S3 bucket.'
ComponentPublisher: Amazon
Manifests:
- Platform:
os: linux
Lifecycle:
install:
Script: docker load -i {artifacts:path}/hello-world.tar
Run:
Script: docker run --rm hello-world
Artifacts:
- URI: s3://amzn-s3-demo-bucket/artifacts/com.example.MyDockerComponent/1.0.0/hello-world.tar
```
------
## Verwenden Sie die Interprozesskommunikation in Docker-Container-Komponenten
Sie können die Greengrass Interprocess Communication (IPC) -Bibliothek in der verwenden, AWS IoT Device SDK um mit dem Greengrass-Kern, anderen Greengrass-Komponenten und zu kommunizieren. AWS IoT Core Weitere Informationen finden Sie unter [Verwenden Sie den AWS IoT Device SDK , um mit dem Greengrass-Kern und anderen Komponenten zu kommunizieren und AWS IoT CoreKommunizieren Sie mit dem Greengrass-Kern, anderen Komponenten und AWS IoT Core](interprocess-communication.md).
Um IPC in einer Docker-Container-Komponente zu verwenden, müssen Sie den Docker-Container mit den folgenden Parametern ausführen:
+ Mounten Sie den IPC-Socket in den Container. Der Greengrass-Kern stellt den IPC-Socket-Dateipfad in der `AWS_GG_NUCLEUS_DOMAIN_SOCKET_FILEPATH_FOR_COMPONENT` Umgebungsvariablen bereit.
+ Stellen Sie die `AWS_GG_NUCLEUS_DOMAIN_SOCKET_FILEPATH_FOR_COMPONENT` Umgebungsvariablen `SVCUID` und auf die Werte ein, die der Greengrass-Kern für Komponenten bereitstellt. Ihre Komponente verwendet diese Umgebungsvariablen, um Verbindungen zum Greengrass-Nucleus zu authentifizieren.
**Example Beispielrezept: Eine MQTT-Nachricht veröffentlichen in AWS IoT Core (Python)**
Das folgende Rezept definiert ein Beispiel für eine Docker-Container-Komponente, die eine MQTT-Nachricht veröffentlicht. AWS IoT Core Das Rezept hat die folgenden Eigenschaften:
+ Eine Autorisierungsrichtlinie (`accessControl`), die es der Komponente ermöglicht, MQTT-Nachrichten zu allen AWS IoT Core Themen zu veröffentlichen. Weitere Informationen finden Sie unter [Autorisieren Sie Komponenten zur Ausführung von IPC-Vorgängen](interprocess-communication.md#ipc-authorization-policies) und [AWS IoT Core MQTT IPC-Autorisierung](ipc-iot-core-mqtt.md#ipc-iot-core-mqtt-authorization).
+ Ein Komponentenartefakt, das ein Docker-Image als TAR-Archiv in Amazon S3 spezifiziert.
+ Ein Lifecycle-Installationsskript, das das Docker-Image aus dem TAR-Archiv lädt.
+ Ein Lifecycle-Run-Skript, das einen Docker-Container vom Image aus ausführt. Der Befehl [Docker run](https://docs.docker.com/engine/reference/run/) hat die folgenden Argumente:
+ Das `-v` Argument mountet den Greengrass-IPC-Socket in den Container.
+ Die ersten beiden `-e` Argumente legen die erforderlichen Umgebungsvariablen im Docker-Container fest.
+ Die zusätzlichen `-e` Argumente legen die in diesem Beispiel verwendeten Umgebungsvariablen fest.
+ Das `--rm` Argument bereinigt den Container, wenn er beendet wird.
```
{
"RecipeFormatVersion": "2020-01-25",
"ComponentName": "com.example.python.docker.PublishToIoTCore",
"ComponentVersion": "1.0.0",
"ComponentDescription": "Uses interprocess communication to publish an MQTT message to IoT Core.",
"ComponentPublisher": "Amazon",
"ComponentConfiguration": {
"DefaultConfiguration": {
"topic": "test/topic/java",
"message": "Hello, World!",
"qos": "1",
"accessControl": {
"aws.greengrass.ipc.mqttproxy": {
"com.example.python.docker.PublishToIoTCore:pubsub:1": {
"policyDescription": "Allows access to publish to IoT Core on all topics.",
"operations": [
"aws.greengrass#PublishToIoTCore"
],
"resources": [
"*"
]
}
}
}
}
},
"Manifests": [
{
"Platform": {
"os": "all"
},
"Lifecycle": {
"install": "docker load -i {artifacts:path}/publish-to-iot-core.tar",
"Run": "docker run -v $AWS_GG_NUCLEUS_DOMAIN_SOCKET_FILEPATH_FOR_COMPONENT:$AWS_GG_NUCLEUS_DOMAIN_SOCKET_FILEPATH_FOR_COMPONENT -e SVCUID -e AWS_GG_NUCLEUS_DOMAIN_SOCKET_FILEPATH_FOR_COMPONENT -e MQTT_TOPIC=\"{configuration:/topic}\" -e MQTT_MESSAGE=\"{configuration:/message}\" -e MQTT_QOS=\"{configuration:/qos}\" --rm publish-to-iot-core"
},
"Artifacts": [
{
"URI": "s3://amzn-s3-demo-bucket/artifacts/com.example.python.docker.PublishToIoTCore/1.0.0/publish-to-iot-core.tar"
}
]
}
]
}
```
```
RecipeFormatVersion: '2020-01-25'
ComponentName: com.example.python.docker.PublishToIoTCore
ComponentVersion: 1.0.0
ComponentDescription: Uses interprocess communication to publish an MQTT message to IoT Core.
ComponentPublisher: Amazon
ComponentConfiguration:
DefaultConfiguration:
topic: 'test/topic/java'
message: 'Hello, World!'
qos: '1'
accessControl:
aws.greengrass.ipc.mqttproxy:
'com.example.python.docker.PublishToIoTCore:pubsub:1':
policyDescription: Allows access to publish to IoT Core on all topics.
operations:
- 'aws.greengrass#PublishToIoTCore'
resources:
- '*'
Manifests:
- Platform:
os: all
Lifecycle:
install: 'docker load -i {artifacts:path}/publish-to-iot-core.tar'
Run: |
docker run \
-v $AWS_GG_NUCLEUS_DOMAIN_SOCKET_FILEPATH_FOR_COMPONENT:$AWS_GG_NUCLEUS_DOMAIN_SOCKET_FILEPATH_FOR_COMPONENT \
-e SVCUID \
-e AWS_GG_NUCLEUS_DOMAIN_SOCKET_FILEPATH_FOR_COMPONENT \
-e MQTT_TOPIC="{configuration:/topic}" \
-e MQTT_MESSAGE="{configuration:/message}" \
-e MQTT_QOS="{configuration:/qos}" \
--rm publish-to-iot-core
Artifacts:
- URI: s3://amzn-s3-demo-bucket/artifacts/com.example.python.docker.PublishToIoTCore/1.0.0/publish-to-iot-core.tar
```
## Verwenden Sie AWS Anmeldeinformationen in Docker-Container-Komponenten (Linux)
Sie können die [Token-Exchange-Dienstkomponente](token-exchange-service-component.md) verwenden, um mit AWS Diensten in Greengrass-Komponenten zu interagieren. Diese Komponente stellt AWS Anmeldeinformationen aus der [Token-Austauschrolle](device-service-role.md) des Kerngeräts mithilfe eines lokalen Containerservers bereit. Weitere Informationen finden Sie unter [Interagieren Sie mit AWS Diensten](interact-with-aws-services.md).
**Anmerkung**
Das Beispiel in diesem Abschnitt funktioniert nur auf Linux-Core-Geräten.
Um AWS Anmeldeinformationen aus dem Token-Exchange-Dienst in einer Docker-Container-Komponente zu verwenden, müssen Sie den Docker-Container mit den folgenden Parametern ausführen:
+ Stellen Sie mithilfe des Arguments Zugriff auf das Host-Netzwerk bereit. `--network=host` Diese Option ermöglicht es dem Docker-Container, eine Verbindung zum lokalen Token-Austauschdienst herzustellen, um AWS Anmeldeinformationen abzurufen. Dieses Argument funktioniert nur auf Docker für Linux.
**Warnung**
Diese Option gewährt dem Container Zugriff auf alle lokalen Netzwerkschnittstellen auf dem Host, sodass diese Option weniger sicher ist, als wenn Sie Docker-Container ohne diesen Zugriff auf das Host-Netzwerk ausführen. Berücksichtigen Sie dies, wenn Sie Docker-Container-Komponenten entwickeln und ausführen, die diese Option verwenden. Weitere Informationen finden Sie unter [Network: host](https://docs.docker.com/engine/reference/run/#network-host) in der *Docker-Dokumentation*.
+ Stellen Sie die `AWS_CONTAINER_AUTHORIZATION_TOKEN` Umgebungsvariablen `AWS_CONTAINER_CREDENTIALS_FULL_URI` und auf die Werte ein, die der Greengrass-Kern für Komponenten bereitstellt. AWS SDKs verwenden Sie diese Umgebungsvariablen, um AWS Anmeldeinformationen abzurufen.
**Example Beispielrezept: S3-Buckets in einer Docker-Container-Komponente auflisten (Python)**
Das folgende Rezept definiert ein Beispiel für eine Docker-Container-Komponente, die die S3-Buckets in Ihrem auflistet. AWS-Konto Das Rezept hat die folgenden Eigenschaften:
+ Die Token-Exchange-Dienstkomponente als Abhängigkeit. Diese Abhängigkeit ermöglicht es der Komponente, AWS Anmeldeinformationen für die Interaktion mit anderen AWS Diensten abzurufen.
+ Ein Komponentenartefakt, das ein Docker-Image als Tar-Archiv in Amazon S3 spezifiziert.
+ Ein Lifecycle-Installationsskript, das das Docker-Image aus dem TAR-Archiv lädt.
+ Ein Lifecycle-Run-Skript, das einen Docker-Container vom Image aus ausführt. Der Befehl [Docker run](https://docs.docker.com/engine/reference/run/) hat die folgenden Argumente:
+ Das `--network=host` Argument gewährt dem Container Zugriff auf das Host-Netzwerk, sodass der Container eine Verbindung zum Token-Austauschdienst herstellen kann.
+ Das `-e` Argument legt die erforderlichen Umgebungsvariablen im Docker-Container fest.
+ Das `--rm` Argument bereinigt den Container, wenn er beendet wird.
```
{
"RecipeFormatVersion": "2020-01-25",
"ComponentName": "com.example.python.docker.ListS3Buckets",
"ComponentVersion": "1.0.0",
"ComponentDescription": "Uses the token exchange service to lists your S3 buckets.",
"ComponentPublisher": "Amazon",
"ComponentDependencies": {
"aws.greengrass.TokenExchangeService": {
"VersionRequirement": "^2.0.0",
"DependencyType": "HARD"
}
},
"Manifests": [
{
"Platform": {
"os": "linux"
},
"Lifecycle": {
"install": "docker load -i {artifacts:path}/list-s3-buckets.tar",
"Run": "docker run --network=host -e AWS_CONTAINER_AUTHORIZATION_TOKEN -e AWS_CONTAINER_CREDENTIALS_FULL_URI --rm list-s3-buckets"
},
"Artifacts": [
{
"URI": "s3://amzn-s3-demo-bucket/artifacts/com.example.python.docker.ListS3Buckets/1.0.0/list-s3-buckets.tar"
}
]
}
]
}
```
```
RecipeFormatVersion: '2020-01-25'
ComponentName: com.example.python.docker.ListS3Buckets
ComponentVersion: 1.0.0
ComponentDescription: Uses the token exchange service to lists your S3 buckets.
ComponentPublisher: Amazon
ComponentDependencies:
aws.greengrass.TokenExchangeService:
VersionRequirement: ^2.0.0
DependencyType: HARD
Manifests:
- Platform:
os: linux
Lifecycle:
install: 'docker load -i {artifacts:path}/list-s3-buckets.tar'
Run: |
docker run \
--network=host \
-e AWS_CONTAINER_AUTHORIZATION_TOKEN \
-e AWS_CONTAINER_CREDENTIALS_FULL_URI \
--rm list-s3-buckets
Artifacts:
- URI: s3://amzn-s3-demo-bucket/artifacts/com.example.python.docker.ListS3Buckets/1.0.0/list-s3-buckets.tar
```
## Verwenden Sie den Stream-Manager in Docker-Container-Komponenten (Linux)
Sie können die [Stream-Manager-Komponente](stream-manager-component.md) verwenden, um Datenströme in Greengrass-Komponenten zu verwalten. Mit dieser Komponente können Sie Datenströme verarbeiten und umfangreiche IoT-Daten an die AWS Cloudübertragen. AWS IoT Greengrass stellt ein Stream-Manager-SDK bereit, das Sie für die Interaktion mit der Stream Manager-Komponente verwenden. Weitere Informationen finden Sie unter [Datenströme auf Greengrass-Kerngeräten verwalten](manage-data-streams.md).
**Anmerkung**
Das Beispiel in diesem Abschnitt funktioniert nur auf Linux-Core-Geräten.
Um das Stream Manager SDK in einer Docker-Container-Komponente zu verwenden, müssen Sie den Docker-Container mit den folgenden Parametern ausführen:
+ Stellen Sie mithilfe des Arguments Zugriff auf das Host-Netzwerk bereit. `--network=host` Diese Option ermöglicht es dem Docker-Container, über eine lokale TLS-Verbindung mit der Stream Manager-Komponente zu interagieren. Dieses Argument funktioniert nur auf Docker für Linux
**Warnung**
Diese Option gewährt dem Container Zugriff auf alle lokalen Netzwerkschnittstellen auf dem Host, sodass diese Option weniger sicher ist, als wenn Sie Docker-Container ohne diesen Zugriff auf das Host-Netzwerk ausführen. Berücksichtigen Sie dies, wenn Sie Docker-Container-Komponenten entwickeln und ausführen, die diese Option verwenden. Weitere Informationen finden Sie unter [Network: host](https://docs.docker.com/engine/reference/run/#network-host) in der *Docker-Dokumentation*.
+ Wenn Sie die Stream-Manager-Komponente so konfigurieren, dass eine Authentifizierung erforderlich ist, was das Standardverhalten ist, setzen Sie die `AWS_CONTAINER_CREDENTIALS_FULL_URI` Umgebungsvariable auf den Wert, den der Greengrass-Nucleus den Komponenten zur Verfügung stellt. Weitere Informationen finden Sie unter [Stream Manager-Konfiguration](stream-manager-component.md#stream-manager-component-configuration).
+ Wenn Sie die Stream Manager-Komponente so konfigurieren, dass sie einen nicht standardmäßigen Port verwendet, verwenden Sie [Interprocess Communication (IPC)](interprocess-communication.md), um den Port aus der Stream Manager-Komponentenkonfiguration abzurufen. Sie müssen den Docker-Container mit zusätzlichen Optionen ausführen, um IPC verwenden zu können. Weitere Informationen finden Sie hier:
+ [Stellen Sie im Anwendungscode eine Connect zum Stream Manager her](use-stream-manager-in-custom-components.md#connect-to-stream-manager)
+ [Verwenden Sie die Interprozesskommunikation in Docker-Container-Komponenten](#docker-container-ipc)
**Example Beispielrezept: Streamen Sie eine Datei in einen S3-Bucket in einer Docker-Container-Komponente (Python)**
Das folgende Rezept definiert ein Beispiel für eine Docker-Container-Komponente, die eine Datei erstellt und sie in einen S3-Bucket streamt. Das Rezept hat die folgenden Eigenschaften:
+ Die Stream-Manager-Komponente als Abhängigkeit. Diese Abhängigkeit ermöglicht es der Komponente, das Stream-Manager-SDK für die Interaktion mit der Stream-Manager-Komponente zu verwenden.
+ Ein Komponentenartefakt, das ein Docker-Image als TAR-Archiv in Amazon S3 spezifiziert.
+ Ein Lifecycle-Installationsskript, das das Docker-Image aus dem TAR-Archiv lädt.
+ Ein Lifecycle-Run-Skript, das einen Docker-Container vom Image aus ausführt. Der Befehl [Docker run](https://docs.docker.com/engine/reference/run/) hat die folgenden Argumente:
+ Das `--network=host` Argument ermöglicht dem Container den Zugriff auf das Host-Netzwerk, sodass der Container eine Verbindung zur Stream Manager-Komponente herstellen kann.
+ Das erste `-e` Argument legt die erforderliche `AWS_CONTAINER_AUTHORIZATION_TOKEN` Umgebungsvariable im Docker-Container fest.
+ Die zusätzlichen `-e` Argumente legen die in diesem Beispiel verwendeten Umgebungsvariablen fest.
+ Das `-v` Argument hängt den [Arbeitsordner](component-recipe-reference.md#component-recipe-work-path) der Komponente im Container ein. In diesem Beispiel wird eine Datei im Arbeitsordner erstellt, um diese Datei mithilfe des Stream-Managers auf Amazon S3 hochzuladen.
+ Das `--rm` Argument bereinigt den Container, wenn er beendet wird.
```
{
"RecipeFormatVersion": "2020-01-25",
"ComponentName": "com.example.python.docker.StreamFileToS3",
"ComponentVersion": "1.0.0",
"ComponentDescription": "Creates a text file and uses stream manager to stream the file to S3.",
"ComponentPublisher": "Amazon",
"ComponentDependencies": {
"aws.greengrass.StreamManager": {
"VersionRequirement": "^2.0.0",
"DependencyType": "HARD"
}
},
"ComponentConfiguration": {
"DefaultConfiguration": {
"bucketName": ""
}
},
"Manifests": [
{
"Platform": {
"os": "linux"
},
"Lifecycle": {
"install": "docker load -i {artifacts:path}/stream-file-to-s3.tar",
"Run": "docker run --network=host -e AWS_CONTAINER_AUTHORIZATION_TOKEN -e BUCKET_NAME=\"{configuration:/bucketName}\" -e WORK_PATH=\"{work:path}\" -v {work:path}:{work:path} --rm stream-file-to-s3"
},
"Artifacts": [
{
"URI": "s3://amzn-s3-demo-bucket/artifacts/com.example.python.docker.StreamFileToS3/1.0.0/stream-file-to-s3.tar"
}
]
}
]
}
```
```
RecipeFormatVersion: '2020-01-25'
ComponentName: com.example.python.docker.StreamFileToS3
ComponentVersion: 1.0.0
ComponentDescription: Creates a text file and uses stream manager to stream the file to S3.
ComponentPublisher: Amazon
ComponentDependencies:
aws.greengrass.StreamManager:
VersionRequirement: ^2.0.0
DependencyType: HARD
ComponentConfiguration:
DefaultConfiguration:
bucketName: ''
Manifests:
- Platform:
os: linux
Lifecycle:
install: 'docker load -i {artifacts:path}/stream-file-to-s3.tar'
Run: |
docker run \
--network=host \
-e AWS_CONTAINER_AUTHORIZATION_TOKEN \
-e BUCKET_NAME="{configuration:/bucketName}" \
-e WORK_PATH="{work:path}" \
-v {work:path}:{work:path} \
--rm stream-file-to-s3
Artifacts:
- URI: s3://amzn-s3-demo-bucket/artifacts/com.example.python.docker.StreamFileToS3/1.0.0/stream-file-to-s3.tar
```
# AWS IoT Greengrass Referenz zum Komponenten-Rezept
Das Komponentenrezept ist eine Datei, die die Details, Abhängigkeiten, Artefakte und Lebenszyklen einer Komponente definiert. Der *Komponentenlebenszyklus* spezifiziert die Befehle, die ausgeführt werden müssen, um beispielsweise die Komponente zu installieren, auszuführen und herunterzufahren. Der AWS IoT Greengrass Kern verwendet die Lebenszyklen, die Sie im Rezept definieren, um Komponenten zu installieren und auszuführen. Der AWS IoT Greengrass Service verwendet das Rezept, um die Abhängigkeiten und Artefakte zu identifizieren, die bei der Bereitstellung der Komponente auf Ihren Kerngeräten bereitgestellt werden sollen.
Im Rezept können Sie eindeutige Abhängigkeiten und Lebenszyklen für jede Plattform definieren, die eine Komponente unterstützt. Sie können diese Funktion verwenden, um eine Komponente auf Geräten mit mehreren Plattformen mit unterschiedlichen Anforderungen bereitzustellen. Sie können damit auch AWS IoT Greengrass verhindern, dass eine Komponente auf Geräten installiert wird, die sie nicht unterstützen.
Jedes Rezept enthält eine Liste von *Manifesten*. Jedes Manifest spezifiziert eine Reihe von Plattformanforderungen sowie den Lebenszyklus und die Artefakte, die für Kerngeräte verwendet werden sollen, deren Plattform diese Anforderungen erfüllt. Das Kerngerät verwendet das erste Manifest mit den Plattformanforderungen, die das Gerät erfüllt. Geben Sie ein Manifest ohne Plattformanforderungen an, das einem beliebigen Kerngerät entspricht.
Sie können auch einen globalen Lebenszyklus angeben, der nicht in einem Manifest enthalten ist. Im globalen Lebenszyklus können Sie *Auswahlschlüssel* verwenden, die Unterabschnitte des Lebenszyklus identifizieren. Anschließend können Sie diese Auswahlschlüssel innerhalb eines Manifests angeben, um diese Abschnitte des globalen Lebenszyklus zusätzlich zum Lebenszyklus des Manifests zu verwenden. Das Kerngerät verwendet die Auswahltasten des Manifests nur, wenn das Manifest keinen Lebenszyklus definiert. Sie können die `all` Auswahl in einem Manifest verwenden, um Abschnitte des globalen Lebenszyklus ohne Auswahlschlüssel zuzuordnen.
Nachdem die AWS IoT Greengrass Core-Software ein Manifest ausgewählt hat, das dem Kerngerät entspricht, geht sie wie folgt vor, um die zu verwendenden Lebenszyklusschritte zu identifizieren:
+ Wenn das ausgewählte Manifest einen Lebenszyklus definiert, verwendet das Kerngerät diesen Lebenszyklus.
+ Wenn das ausgewählte Manifest keinen Lebenszyklus definiert, verwendet das Kerngerät den globalen Lebenszyklus. Das Kerngerät geht wie folgt vor, um zu ermitteln, welche Abschnitte des globalen Lebenszyklus verwendet werden sollen:
+ Wenn das Manifest Auswahlschlüssel definiert, verwendet das Kerngerät die Abschnitte des globalen Lebenszyklus, die die Auswahlschlüssel des Manifests enthalten.
+ Wenn das Manifest keine Auswahltasten definiert, verwendet das Kerngerät die Abschnitte des globalen Lebenszyklus, die keine Auswahltasten haben. Dieses Verhalten entspricht einem Manifest, das die `all` Auswahl definiert.
**Wichtig**
Ein Kerngerät muss die Plattformanforderungen mindestens eines Manifests erfüllen, um die Komponente installieren zu können. Wenn kein Manifest mit dem Kerngerät übereinstimmt, installiert die AWS IoT Greengrass Core-Software die Komponente nicht und die Bereitstellung schlägt fehl.
Sie können Rezepte im [JSON](https://en.wikipedia.org/wiki/JSON) - oder [YAML-Format](https://en.wikipedia.org/wiki/YAML) definieren. Der Abschnitt mit den Rezeptbeispielen enthält Rezepte in jedem Format.
**Topics**
+ [Validierung von Rezepturen](#recipe-validation)
+ [Rezeptformat](#recipe-format)
+ [Rezeptvariablen](#recipe-variables)
+ [Beispiele für Rezepte](#recipe-examples)
## Validierung von Rezepturen
Greengrass validiert ein JSON- oder YAML-Komponentenrezept, wenn eine Komponentenversion erstellt wird. Bei dieser Rezeptvalidierung wird Ihr JSON- oder YAML-Komponentenrezept auf häufig auftretende Fehler überprüft, um mögliche Probleme bei der Bereitstellung zu vermeiden. Bei der Validierung wird das Rezept auf häufige Fehler (z. B. fehlende Kommas, geschweifte Klammern und Felder) überprüft und sichergestellt, dass das Rezept korrekt formuliert ist.
Wenn Sie eine Fehlermeldung bei der Rezeptvalidierung erhalten, überprüfen Sie Ihr Rezept auf fehlende Kommas, Klammern oder Felder. Vergewissern Sie sich anhand des [Rezeptformats](#recipe-format), dass Ihnen keine Felder fehlen.
## Rezeptformat
Wenn Sie ein Rezept für eine Komponente definieren, geben Sie die folgenden Informationen im Rezeptdokument an. Dieselbe Struktur gilt für Rezepte in den Formaten YAML und JSON.
`RecipeFormatVersion`
Die Vorlagenversion für das Rezept. Wählen Sie die folgende Option:
+ `2020-01-25`
`ComponentName`
Der Name der Komponente, die dieses Rezept definiert. Der Komponentenname muss für Sie AWS-Konto in jeder Region einzigartig sein.
**Tipps**
+ Verwenden Sie das umgekehrte Domainnamenformat, um Namenskonflikte innerhalb Ihres Unternehmens zu vermeiden. Wenn Ihr Unternehmen beispielsweise Eigentümer eines Solarenergieprojekts ist `example.com` und Sie daran arbeiten, können Sie Ihrer Komponente `com.example.solar.HelloWorld` den Namen Hello World geben. Auf diese Weise können Kollisionen bei Komponentennamen innerhalb Ihres Unternehmens vermieden werden.
+ Vermeiden Sie das `aws.greengrass` Präfix in Ihren Komponentennamen. AWS IoT Greengrass verwendet dieses Präfix für die [öffentlichen Komponenten](public-components.md), die es bereitstellt. Wenn Sie denselben Namen wie eine öffentliche Komponente wählen, ersetzt Ihre Komponente diese Komponente. AWS IoT Greengrass Stellt dann Ihre Komponente anstelle der öffentlichen Komponente bereit, wenn Komponenten bereitgestellt werden, die von dieser öffentlichen Komponente abhängig sind. Mit dieser Funktion können Sie das Verhalten öffentlicher Komponenten außer Kraft setzen, aber sie kann auch andere Komponenten beschädigen, wenn Sie nicht beabsichtigen, eine öffentliche Komponente zu überschreiben.
`ComponentVersion`
Die Version der Komponente. Der Höchstwert für die Werte „Major“, „Minor“ und „Patch“ ist 999999.
AWS IoT Greengrass verwendet semantische Versionen für Komponenten. *Semantische Versionen folgen einem Hauptteil.* *unbedeutend*. *Patch-Nummernsystem*. Version `1.0.0` steht beispielsweise für die erste Hauptversion einer Komponente. Weitere Informationen finden Sie in der [semantischen Versionsspezifikation](https://semver.org/).
`ComponentDescription`
(Optional) Die Beschreibung der Komponente.
`ComponentPublisher`
Der Herausgeber oder Autor der Komponente.
`ComponentConfiguration`
(Optional) Ein Objekt, das die Konfiguration oder die Parameter für die Komponente definiert. Sie definieren die Standardkonfiguration, und wenn Sie dann die Komponente bereitstellen, können Sie das Konfigurationsobjekt angeben, das für die Komponente bereitgestellt werden soll. Die Komponentenkonfiguration unterstützt verschachtelte Parameter und Strukturen. Dieses Objekt enthält die folgenden Informationen:
`DefaultConfiguration`
Ein Objekt, das die Standardkonfiguration für die Komponente definiert. Sie definieren die Struktur dieses Objekts.
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.
`ComponentDependencies`
(Optional) Ein Wörterbuch mit Objekten, die jeweils eine Komponentenabhängigkeit für die Komponente definieren. Der Schlüssel für jedes Objekt identifiziert den Namen der Komponentenabhängigkeit. AWS IoT Greengrass installiert Komponentenabhängigkeiten, wenn die Komponente installiert wird. AWS IoT Greengrass wartet darauf, dass Abhängigkeiten beginnen, bevor die Komponente gestartet wird. Jedes Objekt enthält die folgenden Informationen:
`VersionRequirement`
Die semantische Versionsbeschränkung im NPM-Stil, die die kompatiblen Komponentenversionen für diese Abhängigkeit definiert. Sie können eine Version oder einen Versionsbereich angeben. Weitere Informationen finden Sie im [npm Semantic Version](https://semver.npmjs.com/) Calculator.
`DependencyType`
(Optional) Der Typ dieser Abhängigkeit. Wählen Sie aus den folgenden Optionen aus.
+ `SOFT` — Die Komponente startet nicht neu, wenn die Abhängigkeit den Status ändert.
+ `HARD` — Die Komponente wird neu gestartet, wenn die Abhängigkeit den Status ändert.
Standardeinstellung: `HARD`.
`ComponentType`
(Optional) Der Typ der Komponente.
Es wird nicht empfohlen, den Komponententyp in einer Rezeptur anzugeben. AWS IoT Greengrass legt den Typ für Sie fest, wenn Sie eine Komponente erstellen.
Bei dem Typ kann es sich um einen der folgenden Typen handeln:
+ `aws.greengrass.generic`— Die Komponente führt Befehle aus oder stellt Artefakte bereit.
+ `aws.greengrass.lambda`— Die Komponente führt mithilfe der [Lambda-Launcher-Komponente eine Lambda-Funktion](lambda-launcher-component.md) aus. Der `ComponentSource` Parameter gibt den ARN der Lambda-Funktion an, die diese Komponente ausführt.
Es wird nicht empfohlen, diese Option zu verwenden, da sie festgelegt wird, AWS IoT Greengrass wenn Sie eine Komponente aus einer Lambda-Funktion erstellen. Weitere Informationen finden Sie unter [AWS Lambda Funktionen ausführen](run-lambda-functions.md).
+ `aws.greengrass.plugin`— Die Komponente läuft auf derselben Java Virtual Machine (JVM) wie der Greengrass-Kern. Wenn Sie eine Plugin-Komponente bereitstellen oder neu starten, wird der Greengrass-Nucleus neu gestartet.
Plugin-Komponenten verwenden dieselbe Protokolldatei wie der Greengrass-Kern. Weitere Informationen finden Sie unter [AWS IoT Greengrass Protokolle überwachen](monitor-logs.md).
Wir empfehlen nicht, diese Option in Komponentenrezepten zu verwenden, da sie für in Java geschriebene Komponenten AWS vorgesehen ist, die direkt mit dem Greengrass-Kern verbunden sind. Weitere Hinweise darüber, welche öffentlichen Komponenten Plugins sind, finden Sie unter. [AWS-mitgelieferte Komponenten](public-components.md)
+ `aws.greengrass.nucleus`— Die Nukleus-Komponente. Weitere Informationen finden Sie unter [Grüngraskern](greengrass-nucleus-component.md).
Wir empfehlen nicht, diese Option in Rezepturen für Komponenten zu verwenden. Es ist für die Greengrass Nucleus-Komponente vorgesehen, die die Mindestfunktionalität der AWS IoT Greengrass Core-Software bietet.
Standardmäßig, `aws.greengrass.generic` wenn Sie eine Komponente aus einem Rezept erstellen oder `aws.greengrass.lambda` wenn Sie eine Komponente aus einer Lambda-Funktion erstellen.
Weitere Informationen finden Sie unter [Komponententypen](develop-greengrass-components.md#component-types).
`ComponentSource`
(Optional) Der ARN der Lambda-Funktion, die eine Komponente ausführt.
Es wird nicht empfohlen, die Komponentenquelle in einem Rezept anzugeben. AWS IoT Greengrass legt diesen Parameter für Sie fest, wenn Sie eine Komponente aus einer Lambda-Funktion erstellen. Weitere Informationen finden Sie unter [AWS Lambda Funktionen ausführen](run-lambda-functions.md).
`Manifests`
Eine Liste von Objekten, die jeweils den Lebenszyklus, die Parameter und Anforderungen der Komponente für eine Plattform definieren. Wenn ein Core-Gerät die Plattformanforderungen mehrerer Manifeste erfüllt, AWS IoT Greengrass wird das erste Manifest verwendet, dem das Core-Gerät entspricht. Um sicherzustellen, dass die Kerngeräte das richtige Manifest verwenden, definieren Sie zunächst die Manifeste mit strengeren Plattformanforderungen. Ein Manifest, das für alle Plattformen gilt, muss das letzte Manifest in der Liste sein.
Ein Kerngerät muss die Plattformanforderungen mindestens eines Manifests erfüllen, um die Komponente installieren zu können. Wenn kein Manifest mit dem Kerngerät übereinstimmt, installiert die AWS IoT Greengrass Core-Software die Komponente nicht und die Bereitstellung schlägt fehl.
Jedes Objekt enthält die folgenden Informationen:
`Name`
(Optional) Ein benutzerfreundlicher Name für die Plattform, die dieses Manifest definiert.
Wenn Sie diesen Parameter weglassen, AWS IoT Greengrass wird ein Name aus der Plattform `os` und `architecture` erstellt.
`Platform`
(Optional) Ein Objekt, das die Plattform definiert, für die dieses Manifest gilt. Lassen Sie diesen Parameter weg, um ein Manifest zu definieren, das für alle Plattformen gilt.
Dieses Objekt spezifiziert Schlüssel-Wert-Paare für die Plattform, auf der ein Core-Gerät läuft. Wenn Sie diese Komponente bereitstellen, vergleicht die AWS IoT Greengrass Core-Software diese Schlüssel-Wert-Paare mit den Plattformattributen auf dem Core-Gerät. Die AWS IoT Greengrass Core-Software definiert immer `os` `architecture` und kann zusätzliche Attribute definieren. Sie können benutzerdefinierte Plattformattribute für ein Kerngerät angeben, wenn Sie die Greengrass Nucleus-Komponente bereitstellen. Weitere Informationen finden Sie unter dem [Parameter Platform Overrides](greengrass-nucleus-component.md#greengrass-nucleus-component-configuration-platform-overrides) der [Greengrass Nucleus-Komponente](greengrass-nucleus-component.md).
Für jedes Schlüssel-Wert-Paar können Sie einen der folgenden Werte angeben:
+ Ein exakter Wert, z. B. `linux` oder. `windows` Exakte Werte müssen mit einem Buchstaben oder einer Zahl beginnen.
+ `*`, was einem beliebigen Wert entspricht. Dies gilt auch, wenn kein Wert vorhanden ist.
+ Ein regulärer Ausdruck im Java-Stil, wie z. `/windows|linux/` Der reguläre Ausdruck muss mit einem Schrägstrich () beginnen und enden. `/` Der reguläre Ausdruck `/.+/` entspricht beispielsweise jedem Wert, der nicht leer ist.
Dieses Objekt enthält die folgenden Informationen:
`runtime`
Die [Greengrass Nucleus-Laufzeit](https://docs.aws.amazon.com/greengrass/v2/developerguide/how-it-works.html#concept-overview) für die Plattform, die dieses Manifest unterstützt. Wenn mehrere Manifeste mit der Plattform definiert werden`runtime`, sind die unterstützten Laufzeitwerte in einem Rezept `aws_nucleus_lite` und `*` nur. Um auf ein klassisches Gerät abzuzielen, DARF das Laufzeitfeld NICHT im Rezept angegeben werden. Zu den unterstützten Greengrass Nucleus-Laufzeiten gehören die folgenden Werte:
+ `*`
+ `aws_nucleus_lite`
`os`
(Optional) Der Name des Betriebssystems für die Plattform, die dieses Manifest unterstützt. Zu den gängigen Plattformen gehören die folgenden Werte:
+ `linux`
+ `windows`
+ `darwin` (macOS)
`architecture`
(Optional) Die Prozessorarchitektur für die Plattform, die dieses Manifest unterstützt. Zu den gängigen Architekturen gehören die folgenden Werte:
+ `amd64`
+ `arm`
+ `aarch64`
+ `x86`
`architecture.detail`
(Optional) Die Details zur Prozessorarchitektur für die Plattform, die dieses Manifest unterstützt. Zu den allgemeinen Architekturdetails gehören die folgenden Werte:
+ `arm61`
+ `arm71`
+ `arm81`
`key`
(Optional) Ein Plattformattribut, das Sie für dieses Manifest definieren. *Key*Ersetzen Sie es durch den Namen des Plattformattributs. Die AWS IoT Greengrass Core-Software ordnet dieses Plattformattribut den Schlüssel-Wert-Paaren zu, die Sie in der Greengrass Nucleus-Komponentenkonfiguration angeben. Weitere Informationen finden Sie unter dem [Parameter Platform Overrides](greengrass-nucleus-component.md#greengrass-nucleus-component-configuration-platform-overrides) der [Greengrass Nucleus-Komponente](greengrass-nucleus-component.md).
Verwenden Sie das umgekehrte Domainnamenformat, um Namenskonflikte innerhalb Ihres Unternehmens zu vermeiden. Wenn Ihr Unternehmen beispielsweise Eigentümer eines Radioprojekts ist `example.com` und Sie daran arbeiten, können Sie ein benutzerdefiniertes Plattformattribut `com.example.radio.RadioModule` benennen. Auf diese Weise können Konflikte mit den Namen von Plattformattributen innerhalb Ihres Unternehmens vermieden werden.
Sie können beispielsweise ein Plattformattribut definieren`com.example.radio.RadioModule`, um ein anderes Manifest zu spezifizieren, das darauf basiert, welches Funkmodul auf einem Kerngerät verfügbar ist. Jedes Manifest kann unterschiedliche Artefakte enthalten, die für unterschiedliche Hardwarekonfigurationen gelten, sodass Sie die minimale Menge an Software auf dem Kerngerät bereitstellen.
`Lifecycle`
Ein Objekt oder eine Zeichenfolge, die definiert, wie die Komponente auf der Plattform installiert und ausgeführt wird, die dieses Manifest definiert. Sie können auch einen [globalen Lebenszyklus](#global-lifecycle-definition) definieren, der für alle Plattformen gilt. Das Kerngerät verwendet den globalen Lebenszyklus nur, wenn das zu verwendende Manifest keinen Lebenszyklus spezifiziert.
Sie definieren diesen Lebenszyklus in einem Manifest. Die Lebenszyklusschritte, die Sie hier angeben, gelten nur für die Plattform, die dieses Manifest definiert. Sie können auch einen [globalen Lebenszyklus](#global-lifecycle-definition) definieren, der für alle Plattformen gilt.
Dieses Objekt oder diese Zeichenfolge enthält die folgenden Informationen:
`Setenv`
(Optional) Ein Wörterbuch mit Umgebungsvariablen, das allen Lebenszyklusskripten zur Verfügung gestellt wird. Sie können diese Umgebungsvariablen `Setenv` in jedem Lebenszyklusskript überschreiben.
`install`
(Optional) Ein Objekt oder eine Zeichenfolge, die das Skript definiert, das bei der Installation der Komponente ausgeführt werden soll. Die AWS IoT Greengrass Core-Software führt diesen Lebenszyklusschritt auch bei jedem Start der Software aus.
Wenn das `install` Skript mit einem Erfolgscode beendet wird, wechselt die Komponente in den `INSTALLED` Status.
Dieses Objekt oder diese Zeichenfolge enthält die folgenden Informationen:
`Script`
Das auszuführende Skript.
`RequiresPrivilege`
(Optional) Sie können das Skript mit Root-Rechten ausführen. Wenn Sie diese Option auf setzen`true`, führt die AWS IoT Greengrass Core-Software dieses Lifecycle-Skript als Root aus und nicht als Systembenutzer, den Sie für die Ausführung dieser Komponente konfigurieren. Standardeinstellung: `false`.
`Skipif`
(Optional) Die Prüfung, um festzustellen, ob das Skript ausgeführt werden soll oder nicht. Sie können festlegen, dass geprüft wird, ob sich eine ausführbare Datei im Pfad befindet oder ob eine Datei existiert. Wenn die Ausgabe wahr ist, überspringt die AWS IoT Greengrass Core-Software den Schritt. Wählen Sie eine der folgenden Prüfungen:
+ `onpath runnable`— Prüft, ob sich ein Runnable im Systempfad befindet. Verwenden Sie dies beispielsweise, **onpath python3** um diesen Lebenszyklusschritt zu überspringen, wenn Python 3 verfügbar ist.
+ `exists file`— Prüft, ob eine Datei existiert. Verwenden Sie zum Beispiel, **exists /tmp/my-configuration.db** um diesen Lebenszyklusschritt zu überspringen, falls `/tmp/my-configuration.db` vorhanden.
`Timeout`
(Optional) Die maximale Zeit in Sekunden, die das Skript ausführen kann, bevor die AWS IoT Greengrass Core-Software den Prozess beendet.
Standard: 120 Sekunden
`Setenv`
(Optional) Das Wörterbuch der Umgebungsvariablen, die dem Skript zur Verfügung gestellt werden sollen. Diese Umgebungsvariablen überschreiben die Variablen, die Sie in angeben`Lifecycle.Setenv`.
`run`
(Optional) Ein Objekt oder eine Zeichenfolge, die das Skript definiert, das beim Start der Komponente ausgeführt werden soll.
Die Komponente wechselt in den `RUNNING` Status, wenn dieser Lebenszyklusschritt ausgeführt wird. Wenn das `run` Skript mit einem Erfolgscode beendet wird, wechselt die Komponente in den `STOPPING` Status. Wenn ein `shutdown` Skript angegeben ist, wird es ausgeführt; andernfalls wechselt die Komponente in den `FINISHED` Status.
Komponenten, die von dieser Komponente abhängen, werden gestartet, wenn dieser Lebenszyklusschritt ausgeführt wird. Um einen Hintergrundprozess auszuführen, z. B. einen Dienst, den abhängige Komponenten verwenden, verwenden Sie stattdessen den `startup` Lebenszyklusschritt.
Wenn Sie Komponenten mit einem `run` Lebenszyklus bereitstellen, kann das Kerngerät die Bereitstellung als abgeschlossen melden, sobald dieses Lifecycle-Skript ausgeführt wird. Dadurch kann die Bereitstellung abgeschlossen und erfolgreich sein, auch wenn das `run` Lifecycle-Skript kurz nach der Ausführung fehlschlägt. Wenn der Bereitstellungsstatus vom Ergebnis des Startskripts der Komponente abhängen soll, verwenden Sie stattdessen den `startup` Lebenszyklusschritt.
Sie können nur einen `startup` oder einen `run` Lebenszyklus definieren.
Dieses Objekt oder diese Zeichenfolge enthält die folgenden Informationen:
`Script`
Das auszuführende Skript.
`RequiresPrivilege`
(Optional) Sie können das Skript mit Root-Rechten ausführen. Wenn Sie diese Option auf setzen`true`, führt die AWS IoT Greengrass Core-Software dieses Lifecycle-Skript als Root aus und nicht als Systembenutzer, den Sie für die Ausführung dieser Komponente konfigurieren. Standardeinstellung: `false`.
`Skipif`
(Optional) Die Prüfung, um festzustellen, ob das Skript ausgeführt werden soll oder nicht. Sie können festlegen, dass geprüft wird, ob sich eine ausführbare Datei im Pfad befindet oder ob eine Datei existiert. Wenn die Ausgabe wahr ist, überspringt die AWS IoT Greengrass Core-Software den Schritt. Wählen Sie eine der folgenden Prüfungen:
+ `onpath runnable`— Prüft, ob sich ein Runnable im Systempfad befindet. Verwenden Sie dies beispielsweise, **onpath python3** um diesen Lebenszyklusschritt zu überspringen, wenn Python 3 verfügbar ist.
+ `exists file`— Prüft, ob eine Datei existiert. Verwenden Sie zum Beispiel, **exists /tmp/my-configuration.db** um diesen Lebenszyklusschritt zu überspringen, falls `/tmp/my-configuration.db` vorhanden.
`Timeout`
(Optional) Die maximale Zeit in Sekunden, die das Skript ausführen kann, bevor die AWS IoT Greengrass Core-Software den Prozess beendet.
Für diesen Lebenszyklusschritt gibt es standardmäßig kein Timeout. Wenn Sie dieses Timeout weglassen, wird das `run` Skript ausgeführt, bis es beendet wird.
`Setenv`
(Optional) Das Wörterbuch der Umgebungsvariablen, die dem Skript zur Verfügung gestellt werden sollen. Diese Umgebungsvariablen überschreiben die Variablen, die Sie in angeben`Lifecycle.Setenv`.
`startup`
(Optional) Ein Objekt oder eine Zeichenfolge, die den Hintergrundprozess definiert, der ausgeführt werden soll, wenn die Komponente gestartet wird.
Wird verwendet`startup`, um einen Befehl auszuführen, der erfolgreich beendet oder der Status der Komponente aktualisiert werden muss, `RUNNING` bevor abhängige Komponenten gestartet werden können. Verwenden Sie den [UpdateState](ipc-component-lifecycle.md#ipc-operation-updatestate)IPC-Vorgang, um den Status der Komponente auf `RUNNING` oder zu setzen, `ERRORED` wenn die Komponente ein Skript startet, das nicht beendet wird. Sie könnten beispielsweise einen `startup` Schritt definieren, mit dem der MySQL-Prozess gestartet wird`/etc/init.d/mysqld start`.
Die Komponente wechselt in den `STARTING` Status, wenn dieser Lebenszyklusschritt ausgeführt wird. Wenn das `startup` Skript mit einem Erfolgscode beendet wird, wechselt die Komponente in den `RUNNING` Status. Dann können abhängige Komponenten gestartet werden.
Wenn Sie Komponenten mit einem `startup` Lebenszyklus bereitstellen, kann das Kerngerät die Bereitstellung als abgeschlossen melden, nachdem dieses Lifecycle-Skript beendet wurde oder seinen Status gemeldet hat. Mit anderen Worten, der Status der Bereitstellung ist so lange gültig, `IN_PROGRESS` bis die Startskripts aller Komponenten beendet werden oder einen Status melden.
Sie können nur einen `startup` oder einen `run` Lebenszyklus definieren.
Dieses Objekt oder diese Zeichenfolge enthält die folgenden Informationen:
`Script`
Das auszuführende Skript.
`RequiresPrivilege`
(Optional) Sie können das Skript mit Root-Rechten ausführen. Wenn Sie diese Option auf setzen`true`, führt die AWS IoT Greengrass Core-Software dieses Lifecycle-Skript als Root aus und nicht als Systembenutzer, den Sie für die Ausführung dieser Komponente konfigurieren. Standardeinstellung: `false`.
`Skipif`
(Optional) Die Prüfung, um festzustellen, ob das Skript ausgeführt werden soll oder nicht. Sie können festlegen, dass geprüft wird, ob sich eine ausführbare Datei im Pfad befindet oder ob eine Datei existiert. Wenn die Ausgabe wahr ist, überspringt die AWS IoT Greengrass Core-Software den Schritt. Wählen Sie eine der folgenden Prüfungen:
+ `onpath runnable`— Prüft, ob sich ein Runnable im Systempfad befindet. Verwenden Sie dies beispielsweise, **onpath python3** um diesen Lebenszyklusschritt zu überspringen, wenn Python 3 verfügbar ist.
+ `exists file`— Prüft, ob eine Datei existiert. Verwenden Sie zum Beispiel, **exists /tmp/my-configuration.db** um diesen Lebenszyklusschritt zu überspringen, falls `/tmp/my-configuration.db` vorhanden.
`Timeout`
(Optional) Die maximale Zeit in Sekunden, die das Skript ausführen kann, bevor die AWS IoT Greengrass Core-Software den Prozess beendet.
Standard: 120 Sekunden
`Setenv`
(Optional) Das Wörterbuch der Umgebungsvariablen, die dem Skript zur Verfügung gestellt werden sollen. Diese Umgebungsvariablen überschreiben die Variablen, die Sie in angeben`Lifecycle.Setenv`.
`shutdown`
(Optional) Ein Objekt oder eine Zeichenfolge, die das Skript definiert, das ausgeführt werden soll, wenn die Komponente heruntergefahren wird. Verwenden Sie den Shutdown-Lebenszyklus, um Code auszuführen, den Sie ausführen möchten, wenn sich die Komponente im `STOPPING` Status befindet. Der Shutdown-Lebenszyklus kann verwendet werden, um einen Prozess zu stoppen, der von den `run` Skripten `startup` oder gestartet wurde.
Wenn Sie einen Hintergrundprozess in starten`startup`, verwenden Sie diesen `shutdown` Schritt, um diesen Prozess zu beenden, wenn die Komponente heruntergefahren wird. Sie könnten beispielsweise einen `shutdown` Schritt definieren, mit dem der MySQL-Prozess gestoppt wird`/etc/init.d/mysqld stop`.
Das `shutdown` Skript wird ausgeführt, nachdem die Komponente den `STOPPING` Status erreicht hat. Wenn das Skript erfolgreich abgeschlossen wurde, wechselt die Komponente in den `FINISHED` Status.
Dieses Objekt oder diese Zeichenfolge enthält die folgenden Informationen:
`Script`
Das auszuführende Skript.
`RequiresPrivilege`
(Optional) Sie können das Skript mit Root-Rechten ausführen. Wenn Sie diese Option auf setzen`true`, führt die AWS IoT Greengrass Core-Software dieses Lifecycle-Skript als Root aus und nicht als Systembenutzer, den Sie für die Ausführung dieser Komponente konfigurieren. Standardeinstellung: `false`.
`Skipif`
(Optional) Die Prüfung, um festzustellen, ob das Skript ausgeführt werden soll oder nicht. Sie können festlegen, dass geprüft wird, ob sich eine ausführbare Datei im Pfad befindet oder ob eine Datei existiert. Wenn die Ausgabe wahr ist, überspringt die AWS IoT Greengrass Core-Software den Schritt. Wählen Sie eine der folgenden Prüfungen:
+ `onpath runnable`— Prüft, ob sich ein Runnable im Systempfad befindet. Verwenden Sie dies beispielsweise, **onpath python3** um diesen Lebenszyklusschritt zu überspringen, wenn Python 3 verfügbar ist.
+ `exists file`— Prüft, ob eine Datei existiert. Verwenden Sie zum Beispiel, **exists /tmp/my-configuration.db** um diesen Lebenszyklusschritt zu überspringen, falls `/tmp/my-configuration.db` vorhanden.
`Timeout`
(Optional) Die maximale Zeit in Sekunden, die das Skript ausführen kann, bevor die AWS IoT Greengrass Core-Software den Prozess beendet.
Standard: 15 Sekunden.
`Setenv`
(Optional) Das Wörterbuch der Umgebungsvariablen, die dem Skript zur Verfügung gestellt werden sollen. Diese Umgebungsvariablen überschreiben die Variablen, die Sie in angeben`Lifecycle.Setenv`.
`recover`
(Optional) Ein Objekt oder eine Zeichenfolge, die das Skript definiert, das ausgeführt werden soll, wenn die Komponente auf einen Fehler stößt.
Dieser Schritt wird ausgeführt, wenn eine Komponente in den `ERRORED` Status wechselt. Wenn die Komponente `ERRORED` dreimal in den Status wechselt, ohne dass sie erfolgreich wiederhergestellt werden konnte, wechselt die Komponente in den `BROKEN` Status. Um eine `BROKEN` Komponente zu reparieren, müssen Sie sie erneut bereitstellen.
Dieses Objekt oder diese Zeichenfolge enthält die folgenden Informationen:
`Script`
Das auszuführende Skript.
`RequiresPrivilege`
(Optional) Sie können das Skript mit Root-Rechten ausführen. Wenn Sie diese Option auf setzen`true`, führt die AWS IoT Greengrass Core-Software dieses Lifecycle-Skript als Root aus und nicht als Systembenutzer, den Sie für die Ausführung dieser Komponente konfigurieren. Standardeinstellung: `false`.
`Skipif`
(Optional) Die Prüfung, um festzustellen, ob das Skript ausgeführt werden soll oder nicht. Sie können festlegen, dass geprüft wird, ob sich eine ausführbare Datei im Pfad befindet oder ob eine Datei existiert. Wenn die Ausgabe wahr ist, überspringt die AWS IoT Greengrass Core-Software den Schritt. Wählen Sie eine der folgenden Prüfungen:
+ `onpath runnable`— Prüft, ob sich ein Runnable im Systempfad befindet. Verwenden Sie dies beispielsweise, **onpath python3** um diesen Lebenszyklusschritt zu überspringen, wenn Python 3 verfügbar ist.
+ `exists file`— Prüft, ob eine Datei existiert. Verwenden Sie zum Beispiel, **exists /tmp/my-configuration.db** um diesen Lebenszyklusschritt zu überspringen, falls `/tmp/my-configuration.db` vorhanden.
`Timeout`
(Optional) Die maximale Zeit in Sekunden, die das Skript ausführen kann, bevor die AWS IoT Greengrass Core-Software den Prozess beendet.
Standard: 60 Sekunden.
`Setenv`
(Optional) Das Wörterbuch der Umgebungsvariablen, die dem Skript zur Verfügung gestellt werden sollen. Diese Umgebungsvariablen überschreiben die Variablen, die Sie in angeben`Lifecycle.Setenv`.
`bootstrap`
(Optional) Ein Objekt oder eine Zeichenfolge, die ein Skript definiert, für das die AWS IoT Greengrass Core-Software oder das Core-Gerät neu gestartet werden muss. Auf diese Weise können Sie eine Komponente entwickeln, die beispielsweise nach der Installation von Betriebssystem- oder Runtime-Updates einen Neustart durchführt.
Verwenden Sie den [Installationslebenszyklus](#install-lifecycle-definition), um Updates oder Abhängigkeiten zu installieren, für die kein Neustart der AWS IoT Greengrass Core-Software oder des Core-Geräts erforderlich ist.
Dieser Lebenszyklusschritt wird in den folgenden Fällen, wenn die AWS IoT Greengrass Core-Software die Komponente bereitstellt, vor dem Schritt des Installationszyklus ausgeführt:
+ Die Komponente wird zum ersten Mal auf dem Kerngerät bereitgestellt.
+ Die Version der Komponente ändert sich.
+ Das Bootstrap-Skript ändert sich als Ergebnis eines Updates der Komponentenkonfiguration.
Nachdem die AWS IoT Greengrass Core-Software den Bootstrap-Schritt für alle Komponenten abgeschlossen hat, die in einer Bereitstellung über einen Bootstrap-Schritt verfügen, wird die Software neu gestartet.
Sie müssen die AWS IoT Greengrass Core-Software als Systemdienst konfigurieren, um die AWS IoT Greengrass Core-Software oder das Core-Gerät neu zu starten. Wenn Sie die AWS IoT Greengrass Core-Software nicht als Systemdienst konfigurieren, wird die Software nicht neu gestartet. Weitere Informationen finden Sie unter [Den Greengrass Nucleus als Systemdienst konfigurieren](configure-greengrass-core-v2.md#configure-system-service).
Dieses Objekt oder diese Zeichenfolge enthält die folgenden Informationen:
`BootstrapOnRollback`
Wenn diese Funktion aktiviert ist, `BootstrapOnRollback` wird sie nur für Komponenten ausgeführt, die die Bootstrap-Lebenszyklusschritte im Rahmen einer fehlgeschlagenen Zielbereitstellung entweder abgeschlossen haben oder versucht haben, sie auszuführen. Diese Funktion ist für Greengrass Nucleus-Versionen 2.12.0 und höher verfügbar.
(Optional) Sie können die Bootstrap-Lebenszyklusschritte als Teil einer Rollback-Bereitstellung ausführen. Wenn Sie diese Option auf setzen`true`, werden die in einer Rollback-Bereitstellung definierten Bootstrap-Lebenszyklusschritte ausgeführt. Wenn eine Bereitstellung fehlschlägt, wird die vorherige Version des Komponenten-Bootstrap-Lebenszyklus während einer Rollback-Bereitstellung erneut ausgeführt.
Standardeinstellung: `false`.
`Script`
Das auszuführende Skript. Der Exit-Code dieses Skripts definiert die Neustart-Anweisung. Verwenden Sie die folgenden Exit-Codes:
+ `0`— Starten Sie die AWS IoT Greengrass Core-Software oder das Core-Gerät nicht neu. Die AWS IoT Greengrass Core-Software wird nach dem Bootstrap aller Komponenten immer noch neu gestartet.
+ `100`— Aufforderung zum Neustart der AWS IoT Greengrass Core-Software.
+ `101`— Anfrage zum Neustart des Core-Geräts.
Die Exit-Codes 100 bis 199 sind für besonderes Verhalten reserviert. Andere Exit-Codes stehen für Skriptfehler.
`RequiresPrivilege`
(Optional) Sie können das Skript mit Root-Rechten ausführen. Wenn Sie diese Option auf setzen`true`, führt die AWS IoT Greengrass Core-Software dieses Lifecycle-Skript als Root aus und nicht als Systembenutzer, den Sie für die Ausführung dieser Komponente konfigurieren. Standardeinstellung: `false`.
`Timeout`
(Optional) Die maximale Zeit in Sekunden, die das Skript ausführen kann, bevor die AWS IoT Greengrass Core-Software den Prozess beendet.
Standard: 120 Sekunden
`Setenv`
(Optional) Das Wörterbuch der Umgebungsvariablen, die dem Skript zur Verfügung gestellt werden sollen. Diese Umgebungsvariablen überschreiben die Variablen, die Sie in angeben`Lifecycle.Setenv`.
`Selections`
(Optional) Eine Liste von Auswahlschlüsseln, die Abschnitte des [globalen Lebenszyklus](#global-lifecycle-definition) angeben, die für dieses Manifest ausgeführt werden sollen. Im globalen Lebenszyklus können Sie Lebenszyklusschritte mit Auswahlschlüsseln auf jeder Ebene definieren, um Unterabschnitte des Lebenszyklus auszuwählen. Anschließend verwendet das Kerngerät die Abschnitte, die den Auswahltasten in diesem Manifest entsprechen. Weitere Informationen finden Sie in den [globalen Lebenszyklus-Beispielen](#global-lifecycle-definition).
Das Kerngerät verwendet die Auswahlen aus dem globalen Lebenszyklus nur, wenn dieses Manifest keinen Lebenszyklus definiert.
Sie können den `all` Auswahlschlüssel angeben, um Abschnitte des globalen Lebenszyklus auszuführen, für die es keine Auswahltasten gibt.
`Artifacts`
(Optional) Eine Liste von Objekten, die jeweils ein binäres Artefakt für die Komponente auf der Plattform definieren, die dieses Manifest definiert. Sie können beispielsweise Code oder Bilder als Artefakte definieren.
Wenn die Komponente bereitgestellt wird, lädt die AWS IoT Greengrass Core-Software das Artefakt in einen Ordner auf dem Core-Gerät herunter. Sie können Artefakte auch als Archivdateien definieren, die die Software nach dem Herunterladen extrahiert.
Sie können [Rezeptvariablen](#recipe-variables) verwenden, um die Pfade zu den Ordnern abzurufen, in denen die Artefakte auf dem Kerngerät installiert werden.
+ Normale Dateien — Verwenden Sie die [Rezeptvariable artifacts:path](#component-recipe-artifacts-path), um den Pfad zu dem Ordner zu ermitteln, der die Artefakte enthält. Geben Sie beispielsweise `{artifacts:path}/my_script.py` in einem Rezept an, dass der Pfad zu einem Artefakt abgerufen werden soll, das den URI hat. `s3://amzn-s3-demo-bucket/path/to/my_script.py`
+ Extrahierte Archive — Verwenden Sie die [Rezeptvariable artifacts:decompressedPath, um den Pfad](#component-recipe-artifacts-decompressed-path) zu dem Ordner abzurufen, der die extrahierten Archivartefakte enthält. Die AWS IoT Greengrass Core-Software extrahiert jedes Archiv in einen Ordner mit demselben Namen wie das Archiv. Geben Sie beispielsweise `{artifacts:decompressedPath}/my_archive/my_script.py` in einem Rezept an, dass der Pfad zu `my_script.py` dem Archivartefakt abgerufen werden soll, das den URI `s3://amzn-s3-demo-bucket/path/to/my_archive.zip` enthält.
Wenn Sie eine Komponente mit einem Archivartefakt auf einem lokalen Kerngerät entwickeln, haben Sie möglicherweise keinen URI für dieses Artefakt. Um Ihre Komponente mit einer `Unarchive` Option zu testen, die das Artefakt extrahiert, geben Sie eine URI an, deren Dateiname mit dem Namen Ihrer Archivartefaktdatei übereinstimmt. Sie können den URI angeben, an den Sie das Archivartefakt hochladen möchten, oder Sie können einen neuen Platzhalter-URI angeben. Um das `my_archive.zip` Artefakt beispielsweise während einer lokalen Bereitstellung zu extrahieren, können Sie Folgendes angeben. `s3://amzn-s3-demo-bucket/my_archive.zip`
Jedes Objekt enthält die folgenden Informationen:
`Uri`
Die URI eines Artefakts in einem S3-Bucket. Die AWS IoT Greengrass Core-Software ruft das Artefakt bei der Installation der Komponente von diesem URI ab, sofern das Artefakt nicht bereits auf dem Gerät vorhanden ist. Jedes Artefakt muss in jedem Manifest einen eindeutigen Dateinamen haben.
`Unarchive`
(Optional) Der Typ des zu entpackenden Archivs. Wählen Sie aus den folgenden Optionen aus:
+ `NONE`— Die Datei ist kein Archiv zum Entpacken. Die AWS IoT Greengrass Core-Software installiert das Artefakt in einem Ordner auf dem Core-Gerät. Sie können die [Rezeptvariable artifacts:path verwenden, um den Pfad zu diesem](#component-recipe-artifacts-path) Ordner zu ermitteln.
+ `ZIP`— Die Datei ist ein ZIP-Archiv. Die AWS IoT Greengrass Core-Software extrahiert das Archiv in einen Ordner mit demselben Namen wie das Archiv. Sie können die [Rezeptvariable artifacts:decompressedPath verwenden, um den Pfad zu dem Ordner zu ermitteln](#component-recipe-artifacts-decompressed-path), der diesen Ordner enthält.
Standardeinstellung: `NONE`.
`Permission`
(Optional) Ein Objekt, das die Zugriffsberechtigungen definiert, die für diese Artefaktdatei festgelegt werden sollen. Sie können die Leseberechtigung und die Ausführungsberechtigung festlegen.
Sie können die Schreibberechtigung nicht festlegen, da die AWS IoT Greengrass Core-Software es Komponenten nicht erlaubt, Artefaktdateien im Artefaktordner zu bearbeiten. Um eine Artefaktdatei in einer Komponente zu bearbeiten, kopieren Sie sie an einen anderen Speicherort oder veröffentlichen Sie eine neue Artefaktdatei und stellen Sie sie bereit.
Wenn Sie ein Artefakt als ein zu entpackendes Archiv definieren, legt die AWS IoT Greengrass Core-Software diese Zugriffsberechtigungen für die Dateien fest, die sie aus dem Archiv entpackt. Die AWS IoT Greengrass Core-Software legt die Zugriffsberechtigungen für den Ordner auf `ALL` für `Read` und fest. `Execute` Dadurch können Komponenten die entpackten Dateien im Ordner anzeigen. Um Berechtigungen für einzelne Dateien aus dem Archiv festzulegen, können Sie die Berechtigungen im [Install-Lifecycle-Skript](#install-lifecycle-definition) festlegen.
Dieses Objekt enthält die folgenden Informationen:
`Read`
(Optional) Die Leseberechtigung, die für diese Artefaktdatei festgelegt werden soll. Geben Sie Folgendes an, damit andere Komponenten auf dieses Artefakt zugreifen können, z. B. Komponenten, die von dieser Komponente abhängen. `ALL` Wählen Sie aus den folgenden Optionen aus:
+ `NONE`— Die Datei ist nicht lesbar.
+ `OWNER`— Die Datei ist für den Systembenutzer lesbar, den Sie für die Ausführung dieser Komponente konfigurieren.
+ `ALL`— Die Datei ist für alle Benutzer lesbar.
Standardeinstellung: `OWNER`.
`Execute`
(Optional) Die Ausführungsberechtigung, die für diese Artefaktdatei festgelegt werden soll. Die `Execute` Erlaubnis impliziert die `Read` Erlaubnis. Wenn Sie beispielsweise `ALL` for angeben`Execute`, können alle Benutzer diese Artefaktdatei lesen und ausführen.
Wählen Sie aus den folgenden Optionen aus:
+ `NONE`— Die Datei kann nicht ausgeführt werden.
+ `OWNER`— Die Datei kann von dem Systembenutzer ausgeführt werden, den Sie für die Ausführung der Komponente konfigurieren.
+ `ALL`— Die Datei kann von allen Benutzern ausgeführt werden.
Standardeinstellung: `NONE`.
`Digest`
(Schreibgeschützt) Der kryptografische Digest-Hash des Artefakts. Wenn Sie eine Komponente erstellen, AWS IoT Greengrass verwendet einen Hash-Algorithmus, um einen Hash der Artefaktdatei zu berechnen. Wenn Sie dann die Komponente bereitstellen, berechnet der Greengrass-Kern den Hash des heruntergeladenen Artefakts und vergleicht den Hash mit diesem Digest, um das Artefakt vor der Installation zu verifizieren. Wenn der Hash nicht mit dem Digest übereinstimmt, schlägt die Bereitstellung fehl.
Wenn Sie diesen Parameter festlegen, AWS IoT Greengrass ersetzt er den Wert, den Sie bei der Erstellung der Komponente festgelegt haben.
`Algorithm`
(Schreibgeschützt) Der AWS IoT Greengrass Hash-Algorithmus, mit dem der Digest-Hash des Artefakts berechnet wird.
Wenn Sie diesen Parameter festlegen, AWS IoT Greengrass ersetzt er den Wert, den Sie bei der Erstellung der Komponente festgelegt haben.
`Lifecycle`
Ein Objekt, das definiert, wie die Komponente installiert und ausgeführt wird. Das Kerngerät verwendet den globalen Lebenszyklus nur, wenn das zu verwendende [Manifest](#manifest-definition) keinen Lebenszyklus spezifiziert.
Sie definieren diesen Lebenszyklus außerhalb eines Manifests. Sie können auch einen [Manifest-Lebenszyklus](#manifest-lifecycle-definition) definieren, der für die Plattformen gilt, die diesem Manifest entsprechen.
Im globalen Lebenszyklus können Sie Lebenszyklen angeben, die für bestimmte [Auswahlschlüssel](#manifest-selections-definition) ausgeführt werden, die Sie in jedem Manifest angeben. Auswahlschlüssel sind Zeichenfolgen, die Abschnitte des globalen Lebenszyklus identifizieren, die für jedes Manifest ausgeführt werden sollen.
Die `all` Auswahltaste ist die Standardeinstellung für alle Abschnitte ohne Auswahltaste. Das bedeutet, dass Sie den `all` Auswahlschlüssel in einem Manifest angeben können, um die Abschnitte des globalen Lebenszyklus ohne Auswahlschlüssel auszuführen. Sie müssen den `all` Auswahlschlüssel im globalen Lebenszyklus nicht angeben.
Wenn ein Manifest keinen Lebenszyklus oder keine Auswahlschlüssel definiert, verwendet das Kerngerät standardmäßig die `all` Auswahl. Das bedeutet, dass das Kerngerät in diesem Fall die Abschnitte des globalen Lebenszyklus verwendet, die keine Auswahltasten verwenden.
Dieses Objekt enthält dieselben Informationen wie der [Manifest-Lebenszyklus](#manifest-lifecycle-definition), Sie können jedoch Auswahlschlüssel auf jeder Ebene angeben, um Unterabschnitte des Lebenszyklus auszuwählen.
Es wird empfohlen, für jede Auswahltaste nur Kleinbuchstaben zu verwenden, um Konflikte zwischen Auswahlschlüsseln und Lebenszyklusschlüsseln zu vermeiden. Lebenszyklusschlüssel beginnen mit einem Großbuchstaben.
**Example Beispiel für einen globalen Lebenszyklus mit Auswahlschlüsseln der obersten Ebene**
```
Lifecycle:
key1:
install:
SkipIf: either onpath executable or exists file
Script: command1
key2:
install:
Script: command2
all:
install:
Script: command3
```
**Example Beispiel für einen globalen Lebenszyklus mit Auswahltasten auf unterster Ebene**
```
Lifecycle:
install:
Script:
key1: command1
key2: command2
all: command3
```
**Example Beispiel für einen globalen Lebenszyklus mit mehreren Ebenen von Auswahlschlüsseln**
```
Lifecycle:
key1:
install:
SkipIf: either onpath executable or exists file
Script: command1
key2:
install:
Script: command2
all:
install:
Script:
key3: command3
key4: command4
all: command5
```
## Rezeptvariablen
Rezeptvariablen stellen Informationen aus der aktuellen Komponente und dem aktuellen Kern zur Verfügung, die Sie in Ihren Rezepten verwenden können. Sie können beispielsweise eine Rezeptvariable verwenden, um Komponentenkonfigurationsparameter an eine Anwendung zu übergeben, die Sie in einem Lifecycle-Skript ausführen.
Sie können Rezeptvariablen in den folgenden Abschnitten von Komponentenrezepten verwenden:
+ Lebenszyklusdefinitionen.
+ Definitionen der Komponentenkonfiguration, wenn Sie [Greengrass Nucleus](greengrass-nucleus-component.md) v2.6.0 oder höher verwenden und die [interpolateComponentConfiguration](greengrass-nucleus-component.md#greengrass-nucleus-component-configuration-interpolate-component-configuration)Konfigurationsoption auf setzen. `true` Sie können auch Rezeptvariablen verwenden, wenn Sie Updates für die [Komponentenkonfiguration bereitstellen](update-component-configurations.md#merge-configuration-update-recipe-variables).
Rezeptvariablen verwenden `{recipe_variable}` Syntax. Die geschweiften Klammern stehen für eine Rezeptvariable.
AWS IoT Greengrass unterstützt die folgenden Rezeptvariablen:
`component_dependency_name:configuration:json_pointer`
Der Wert eines Konfigurationsparameters für die Komponente, die dieses Rezept definiert, oder für eine Komponente, von der diese Komponente abhängt.
Sie können diese Variable verwenden, um einen Parameter für ein Skript bereitzustellen, das Sie im Lebenszyklus der Komponente ausführen.
AWS IoT Greengrass unterstützt diese Rezeptvariable nur in Definitionen des Komponentenlebenszyklus.
Diese Rezeptvariable hat die folgenden Eingaben:
+ `component_dependency_name`— (Optional) Der Name der Komponentenabhängigkeit, die abgefragt werden soll. Lassen Sie dieses Segment weg, um die Komponente abzufragen, die dieses Rezept definiert. Sie können nur direkte Abhängigkeiten angeben.
+ `json_pointer`— Der JSON-Zeiger auf den auszuwertenden Konfigurationswert. 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. Sie können eine Zahl als Schlüssel verwenden, um einen Index in einer Liste anzugeben. Weitere Informationen finden Sie in der [JSON-Zeigerspezifikation](https://tools.ietf.org/html/rfc6901).
AWS IoT Greengrass Core verwendet JSON-Zeiger für Rezepte im YAML-Format.
Der JSON-Pointer kann auf die folgenden Knotentypen verweisen:
+ Ein Wertknoten. AWS IoT Greengrass Core ersetzt die Rezeptvariable durch die Zeichenkettendarstellung des Werts. Nullwerte werden in `null` eine Zeichenfolge umgewandelt.
+ Ein Objektknoten. AWS IoT Greengrass Core ersetzt die Rezeptvariable durch die serialisierte JSON-Zeichenkettendarstellung dieses Objekts.
+ Kein Knoten. AWS IoT Greengrass Core ersetzt die Rezeptvariable nicht.
Beispielsweise ruft die `{configuration:/Message}` Rezeptvariable den Wert des `Message` Schlüssels in der Komponentenkonfiguration ab. Die `{com.example.MyComponentDependency:configuration:/server/port}` Rezeptvariable ruft den Wert von `port` im `server` Konfigurationsobjekt einer Komponentenabhängigkeit ab.
`component_dependency_name:artifacts:path`
Der Stammpfad der Artefakte für die Komponente, die dieses Rezept definiert, oder für eine Komponente, von der diese Komponente abhängt.
Wenn eine Komponente installiert wird, werden die Artefakte der Komponente in den Ordner AWS IoT Greengrass kopiert, den diese Variable verfügbar macht. Sie können diese Variable verwenden, um beispielsweise den Speicherort eines Skripts zu identifizieren, das im Lebenszyklus einer Komponente ausgeführt werden soll.
Der Ordner in diesem Pfad ist schreibgeschützt. Um Artefaktdateien zu ändern, kopieren Sie die Dateien an einen anderen Speicherort, z. B. in das aktuelle Arbeitsverzeichnis (`$PWD`oder). `.` Ändern Sie dann die Dateien dort.
Um ein Artefakt aus einer Komponentenabhängigkeit zu lesen oder auszuführen, müssen die entsprechenden `Execute` Rechte `Read` oder Rechte für das Artefakt vorliegen. `ALL` Weitere Informationen finden Sie in den [Artefaktberechtigungen](#component-artifact-permission), die Sie im Komponentenrezept definieren.
Diese Rezeptvariable hat die folgenden Eingaben:
+ `component_dependency_name`— (Optional) Der Name der Komponentenabhängigkeit, die abgefragt werden soll. Lassen Sie dieses Segment weg, um die Komponente abzufragen, die dieses Rezept definiert. Sie können nur direkte Abhängigkeiten angeben.
`component_dependency_name:artifacts:decompressedPath`
Der Stammpfad der dekomprimierten Archivartefakte für die Komponente, die dieses Rezept definiert, oder für eine Komponente, von der diese Komponente abhängt.
Wenn eine Komponente installiert wird, werden die Archivartefakte der Komponente in den Ordner AWS IoT Greengrass entpackt, den diese Variable verfügbar macht. Sie können diese Variable verwenden, um beispielsweise den Speicherort eines Skripts zu identifizieren, das im Lebenszyklus einer Komponente ausgeführt werden soll.
Jedes Artefakt wird in einen Ordner innerhalb des dekomprimierten Pfads entpackt, wobei der Ordner denselben Namen wie das Artefakt abzüglich seiner Erweiterung hat. Beispielsweise wird ein ZIP-Artefakt mit dem Namen in den Ordner entpackt. `models.zip` `{artifacts:decompressedPath}/models`
Der Ordner in diesem Pfad ist schreibgeschützt. Um Artefaktdateien zu ändern, kopieren Sie die Dateien an einen anderen Speicherort, z. B. in das aktuelle Arbeitsverzeichnis (`$PWD`oder). `.` Ändern Sie dann die Dateien dort.
Um ein Artefakt aus einer Komponentenabhängigkeit zu lesen oder auszuführen, müssen die entsprechenden `Execute` Rechte `Read` oder Rechte für das Artefakt vorliegen. `ALL` Weitere Informationen finden Sie in den [Artefaktberechtigungen](#component-artifact-permission), die Sie im Komponentenrezept definieren.
Diese Rezeptvariable hat die folgenden Eingaben:
+ `component_dependency_name`— (Optional) Der Name der Komponentenabhängigkeit, die abgefragt werden soll. Lassen Sie dieses Segment weg, um die Komponente abzufragen, die dieses Rezept definiert. Sie können nur direkte Abhängigkeiten angeben.
`component_dependency_name:work:path`
Diese Funktion ist für Version 2.0.4 und höher der [Greengrass](greengrass-nucleus-component.md) Nucleus-Komponente verfügbar.
Der Arbeitspfad für die Komponente, die dieses Rezept definiert, oder für eine Komponente, von der diese Komponente abhängt. Der Wert dieser Rezeptvariablen entspricht der Ausgabe der `$PWD` Umgebungsvariablen und des Befehls [pwd](https://en.wikipedia.org/wiki/Pwd), wenn sie im Kontext der Komponente ausgeführt wird.
Sie können diese Rezeptvariable verwenden, um Dateien zwischen einer Komponente und einer Abhängigkeit gemeinsam zu nutzen.
Der Ordner in diesem Pfad ist für die Komponente, die dieses Rezept definiert, und für andere Komponenten, die unter demselben Benutzer und derselben Gruppe ausgeführt werden, lesbar und beschreibbar.
Diese Rezeptvariable hat die folgenden Eingaben:
+ `component_dependency_name`— (Optional) Der Name der Komponentenabhängigkeit, die abgefragt werden soll. Lassen Sie dieses Segment weg, um die Komponente abzufragen, die dieses Rezept definiert. Sie können nur direkte Abhängigkeiten angeben.
`kernel:rootPath`
Der AWS IoT Greengrass Core-Stammpfad.
`iot:thingName`
Diese Funktion ist für Version 2.3.0 und höher der [Greengrass](greengrass-nucleus-component.md) Nucleus-Komponente verfügbar.
Der Name der Sache des Kerngeräts. AWS IoT
## Beispiele für Rezepte
Anhand der folgenden Rezeptbeispiele können Sie Rezepte für Ihre Komponenten erstellen.
AWS IoT Greengrass kuratiert einen Index von Greengrass-Komponenten, den sogenannten Greengrass Software Catalog. Dieser Katalog verfolgt Greengrass-Komponenten, die von der Greengrass-Community entwickelt wurden. Aus diesem Katalog können Sie Komponenten herunterladen, ändern und bereitstellen, um Ihre Greengrass-Anwendungen zu erstellen. Weitere Informationen finden Sie unter [Komponenten der Gemeinschaft](greengrass-software-catalog.md).
**Topics**
+ [Rezept für die Komponenten von Hello World](#recipe-example-hello-world)
+ [Beispiel für eine Python-Laufzeitkomponente](#recipe-example-python-runtime)
+ [Komponentenrezept, das mehrere Felder spezifiziert](#recipe-example-all-fields)
### Rezept für die Komponenten von Hello World
Das folgende Rezept beschreibt eine Hello World-Komponente, die ein Python-Skript ausführt. Diese Komponente unterstützt alle Plattformen und akzeptiert einen `Message` Parameter, der als Argument an das Python-Skript AWS IoT Greengrass übergeben wird. Dies ist das Rezept für die Hello World-Komponente im [Tutorial Erste Schritte](getting-started.md).
------
#### [ JSON ]
```
{
"RecipeFormatVersion": "2020-01-25",
"ComponentName": "com.example.HelloWorld",
"ComponentVersion": "1.0.0",
"ComponentDescription": "My first AWS IoT Greengrass component.",
"ComponentPublisher": "Amazon",
"ComponentConfiguration": {
"DefaultConfiguration": {
"Message": "world"
}
},
"Manifests": [
{
"Platform": {
"os": "linux"
},
"Lifecycle": {
"run": "python3 -u {artifacts:path}/hello_world.py {configuration:/Message}"
}
},
{
"Platform": {
"os": "windows"
},
"Lifecycle": {
"run": "py -3 -u {artifacts:path}/hello_world.py {configuration:/Message}"
}
}
]
}
```
------
#### [ YAML ]
```
---
RecipeFormatVersion: '2020-01-25'
ComponentName: com.example.HelloWorld
ComponentVersion: '1.0.0'
ComponentDescription: My first AWS IoT Greengrass component.
ComponentPublisher: Amazon
ComponentConfiguration:
DefaultConfiguration:
Message: world
Manifests:
- Platform:
os: linux
Lifecycle:
run: |
python3 -u {artifacts:path}/hello_world.py "{configuration:/Message}"
- Platform:
os: windows
Lifecycle:
run: |
py -3 -u {artifacts:path}/hello_world.py "{configuration:/Message}"
```
------
### Beispiel für eine Python-Laufzeitkomponente
Das folgende Rezept beschreibt eine Komponente, die Python installiert. Diese Komponente unterstützt 64-Bit-Linux-Geräte.
------
#### [ JSON ]
```
{
"RecipeFormatVersion": "2020-01-25",
"ComponentName": "com.example.PythonRuntime",
"ComponentDescription": "Installs Python 3.7",
"ComponentPublisher": "Amazon",
"ComponentVersion": "3.7.0",
"Manifests": [
{
"Platform": {
"os": "linux",
"architecture": "amd64"
},
"Lifecycle": {
"install": "apt-get update\napt-get install python3.7"
}
}
]
}
```
------
#### [ YAML ]
```
---
RecipeFormatVersion: '2020-01-25'
ComponentName: com.example.PythonRuntime
ComponentDescription: Installs Python 3.7
ComponentPublisher: Amazon
ComponentVersion: '3.7.0'
Manifests:
- Platform:
os: linux
architecture: amd64
Lifecycle:
install: |
apt-get update
apt-get install python3.7
```
------
### Komponentenrezept, das mehrere Felder spezifiziert
Das folgende Komponentenrezept verwendet mehrere Rezeptfelder.
------
#### [ JSON ]
```
{
"RecipeFormatVersion": "2020-01-25",
"ComponentName": "com.example.FooService",
"ComponentDescription": "Complete recipe for AWS IoT Greengrass components",
"ComponentPublisher": "Amazon",
"ComponentVersion": "1.0.0",
"ComponentConfiguration": {
"DefaultConfiguration": {
"TestParam": "TestValue"
}
},
"ComponentDependencies": {
"BarService": {
"VersionRequirement": "^1.1.0",
"DependencyType": "SOFT"
},
"BazService": {
"VersionRequirement": "^2.0.0"
}
},
"Manifests": [
{
"Platform": {
"os": "linux",
"architecture": "amd64"
},
"Lifecycle": {
"install": {
"Skipif": "onpath git",
"Script": "sudo apt-get install git"
},
"Setenv": {
"environment_variable1": "variable_value1",
"environment_variable2": "variable_value2"
}
},
"Artifacts": [
{
"Uri": "s3://amzn-s3-demo-bucket/hello_world.zip",
"Unarchive": "ZIP"
},
{
"Uri": "s3://amzn-s3-demo-bucket/hello_world_linux.py"
}
]
},
{
"Lifecycle": {
"install": {
"Skipif": "onpath git",
"Script": "sudo apt-get install git",
"RequiresPrivilege": "true"
}
},
"Artifacts": [
{
"Uri": "s3://amzn-s3-demo-bucket/hello_world.py"
}
]
}
]
}
```
------
#### [ YAML ]
```
---
RecipeFormatVersion: '2020-01-25'
ComponentName: com.example.FooService
ComponentDescription: Complete recipe for AWS IoT Greengrass components
ComponentPublisher: Amazon
ComponentVersion: 1.0.0
ComponentConfiguration:
DefaultConfiguration:
TestParam: TestValue
ComponentDependencies:
BarService:
VersionRequirement: ^1.1.0
DependencyType: SOFT
BazService:
VersionRequirement: ^2.0.0
Manifests:
- Platform:
os: linux
architecture: amd64
Lifecycle:
install:
SkipIf: onpath git
Script: sudo apt-get install git
SetEnv:
environment_variable1: variable_value1
environment_variable2: variable_value2
Artifacts:
- Uri: 's3://amzn-s3-demo-bucket/hello_world.zip'
Unarchive: ZIP
- Uri: 's3://amzn-s3-demo-bucket/hello_world_linux.py'
- Lifecycle:
install:
SkipIf: onpath git
Script: sudo apt-get install git
RequiresPrivilege: 'true'
Artifacts:
- Uri: 's3://amzn-s3-demo-bucket/hello_world.py'
```
------
# Referenz zur Umgebungsvariablen der Komponente
Die AWS IoT Greengrass Core-Software legt Umgebungsvariablen fest, wenn sie Lebenszyklusskripts für Komponenten ausführt. Sie können diese Umgebungsvariablen in Ihren Komponenten abrufen, AWS-Region um den Namen der Sache und die Greengrass Nucleus-Version zu erhalten. Die Software legt auch Umgebungsvariablen fest, die Ihre Komponente benötigt, um [das Interprozesskommunikations-SDK](interprocess-communication.md) zu verwenden und [mit AWS Diensten zu interagieren](interact-with-aws-services.md).
Sie können auch benutzerdefinierte Umgebungsvariablen für die Lebenszyklusskripts Ihrer Komponente festlegen. Weitere Informationen finden Sie unter [Setenv](component-recipe-reference.md#lifecycle-setenv-definition).
Die AWS IoT Greengrass Core-Software legt die folgenden Umgebungsvariablen fest:
`AWS_IOT_THING_NAME`
Der Name der AWS IoT Sache, die dieses Greengrass-Core-Gerät repräsentiert.
`AWS_REGION`
Der AWS-Region Ort, an dem dieses Greengrass-Core-Gerät arbeitet.
AWS SDKs Sie verwenden diese Umgebungsvariable, um die zu verwendende Standardregion zu identifizieren. Diese Variable ist äquivalent zu`AWS_DEFAULT_REGION`.
`AWS_DEFAULT_REGION`
Der AWS-Region Ort, an dem dieses Greengrass-Core-Gerät arbeitet.
Der AWS CLI verwendet diese Umgebungsvariable, um die zu verwendende Standardregion zu identifizieren. Diese Variable entspricht`AWS_REGION`.
`GGC_VERSION`
Die Version der [Greengrass Nucleus-Komponente](greengrass-nucleus-component.md), die auf diesem Greengrass-Core-Gerät läuft.
`GG_ROOT_CA_PATH`
Diese Funktion ist für Version 2.5.5 und höher der [Greengrass](greengrass-nucleus-component.md) Nucleus-Komponente verfügbar.
Der Pfad zum Root-Zertifikat der Zertifizierungsstelle (CA), das der Greengrass-Nucleus verwendet.
`AWS_GG_NUCLEUS_DOMAIN_SOCKET_FILEPATH_FOR_COMPONENT`
Der Pfad zum IPC-Socket, über den Komponenten mit der AWS IoT Greengrass Core-Software kommunizieren. Weitere Informationen finden Sie unter [Verwenden Sie den AWS IoT Device SDK , um mit dem Greengrass-Kern und anderen Komponenten zu kommunizieren und AWS IoT CoreKommunizieren Sie mit dem Greengrass-Kern, anderen Komponenten und AWS IoT Core](interprocess-communication.md).
`SVCUID`
Das geheime Token, das Komponenten verwenden, um eine Verbindung zum IPC-Socket herzustellen und mit der AWS IoT Greengrass Core-Software zu kommunizieren. Weitere Informationen finden Sie unter [Verwenden Sie den AWS IoT Device SDK , um mit dem Greengrass-Kern und anderen Komponenten zu kommunizieren und AWS IoT CoreKommunizieren Sie mit dem Greengrass-Kern, anderen Komponenten und AWS IoT Core](interprocess-communication.md).
`AWS_CONTAINER_AUTHORIZATION_TOKEN`
Das geheime Token, das Komponenten verwenden, um Anmeldeinformationen von der [Token-Exchange-Dienstkomponente](token-exchange-service-component.md) abzurufen.
`AWS_CONTAINER_CREDENTIALS_FULL_URI`
Der URI, den die Komponenten zum Abrufen von Anmeldeinformationen von der [Token-Exchange-Dienstkomponente](token-exchange-service-component.md) anfordern.