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 Entwicklungstools
Verwenden Sie AWS IoT Greengrass Entwicklungstools, um benutzerdefinierte Greengrass-Komponenten zu erstellen, zu testen, zu erstellen, zu veröffentlichen und bereitzustellen.
+ **[Greengrass-Entwicklungskit CLI](greengrass-development-kit-cli.md)**
Verwenden Sie das AWS IoT Greengrass Development Kit Command-Line Interface (GDK CLI) in Ihrer lokalen Entwicklungsumgebung, um Komponenten aus Vorlagen und Community-Komponenten im [Greengrass](greengrass-software-catalog.md) Software Catalog zu erstellen. Sie können die GDK-CLI verwenden, um die Komponente zu erstellen und die Komponente als private Komponente in Ihrem AWS IoT Greengrass AWS-Konto Dienst zu veröffentlichen.
+ **[Greengrass-Befehlszeilenschnittstelle](gg-cli.md)**
Verwenden Sie das Greengrass Command Line Interface (Greengrass CLI) auf Greengrass-Kerngeräten, um Greengrass-Komponenten bereitzustellen und zu debuggen. Die Greengrass-CLI ist eine Komponente, die Sie auf Ihren Kerngeräten bereitstellen können, um lokale Bereitstellungen zu erstellen, Details zu installierten Komponenten anzuzeigen und Protokolldateien zu untersuchen.
+ **[Lokale Debug-Konsole](local-debug-console-component.md)**
Verwenden Sie die lokale Debug-Konsole auf Greengrass-Core-Geräten, um Greengrass-Komponenten mithilfe einer lokalen Dashboard-Weboberfläche bereitzustellen und zu debuggen. Die lokale Debug-Konsole ist eine Komponente, die Sie auf Ihren Kerngeräten bereitstellen können, um lokale Bereitstellungen zu erstellen und Details zu den installierten Komponenten anzuzeigen.
AWS IoT Greengrass bietet außerdem Folgendes SDKs , das Sie in benutzerdefinierten Greengrass-Komponenten verwenden können:
+ Das AWS IoT Device SDK, das die IPC-Bibliothek (Interprocess Communication) enthält. 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).
+ Das Stream Manager SDK, mit dem Sie Datenstreams an das übertragen können. AWS Cloud Weitere Informationen finden Sie unter [Datenströme auf Greengrass-Kerngeräten verwalten](manage-data-streams.md).
**Topics**
+ [AWS IoT Greengrass Befehlszeilenschnittstelle für das Entwicklungskit](greengrass-development-kit-cli.md)
+ [Greengrass-Befehlszeilenschnittstelle](gg-cli.md)
+ [Verwenden Sie AWS IoT Greengrass Testing Framework](gg-testing-framework.md)
# AWS IoT Greengrass Befehlszeilenschnittstelle für das Entwicklungskit
Das AWS IoT Greengrass Development Kit Command-Line Interface (GDK CLI) bietet Funktionen, mit denen Sie [benutzerdefinierte](develop-greengrass-components.md) Greengrass-Komponenten entwickeln können. Sie können die GDK-CLI verwenden, um benutzerdefinierte Komponenten zu erstellen, zu erstellen und zu veröffentlichen. Wenn Sie ein Komponenten-Repository mit der GDK-CLI erstellen, können Sie mit einer Vorlage oder einer Community-Komponente aus dem [Greengrass-Softwarekatalog](greengrass-software-catalog.md) beginnen. Anschließend können Sie ein Build-System wählen, das Dateien als ZIP-Archive verpackt, ein Maven- oder Gradle-Build-Skript verwendet oder einen benutzerdefinierten Build-Befehl ausführt. Nachdem Sie eine Komponente erstellt haben, können Sie sie mit der GDK-CLI im AWS IoT Greengrass Service veröffentlichen, sodass Sie die AWS IoT Greengrass Konsole oder API verwenden können, um die Komponente auf Ihren Greengrass-Kerngeräten bereitzustellen.
Wenn Sie Greengrass-Komponenten ohne die GDK-CLI entwickeln, müssen Sie die Version und das Artefakt URIs in der [Komponentenrezeptdatei](component-recipe-reference.md) jedes Mal aktualisieren, wenn Sie eine neue Version der Komponente erstellen. Wenn Sie die GDK-CLI verwenden, kann sie die Version und das Artefakt jedes Mal, wenn Sie eine neue Version der Komponente veröffentlichen, automatisch URIs für Sie aktualisieren.
Die GDK-CLI ist Open Source und verfügbar unter GitHub. Sie können die GDK-CLI an Ihre Anforderungen an die Komponentenentwicklung anpassen und erweitern. Wir laden Sie ein, Issues und Pull-Requests im GitHub Repository zu öffnen. Die GDK-CLI-Quelle finden Sie unter dem folgenden Link: [https://github.com/aws-greengrass/aws-greengrass-gdk-cli](https://github.com/aws-greengrass/aws-greengrass-gdk-cli).
## Voraussetzungen
Um das Greengrass Development Kit CLI zu installieren und zu verwenden, benötigen Sie Folgendes:
+ Ein AWS-Konto. Falls Sie noch keines haben, beachten Sie die Informationen unter [Richten Sie eine ein AWS-Konto](setting-up.md#set-up-aws-account).
+ Ein Windows-, macOS- oder UNIX-ähnlicher Entwicklungscomputer mit einer Internetverbindung.
+ Für GDK CLI Version 1.1.0 oder höher ist [Python](https://www.python.org/downloads/) 3.6 oder höher auf Ihrem Entwicklungscomputer installiert.
Für GDK CLI Version 1.0.0 ist [Python](https://www.python.org/downloads/) 3.8 oder höher auf Ihrem Entwicklungscomputer installiert.
+ [Git](https://git-scm.com/) ist auf Ihrem Entwicklungscomputer installiert.
+ AWS Command Line Interface (AWS CLI) wurde mit Anmeldeinformationen auf Ihrem Entwicklungscomputer installiert und konfiguriert. Weitere Informationen finden Sie unter [Installation, Aktualisierung und Deinstallation](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) [von AWS CLI und Konfiguration von AWS CLI im AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html) *Benutzerhandbuch*.
**Anmerkung**
Wenn Sie einen Raspberry Pi oder ein anderes 32-Bit-ARM-Gerät verwenden, installieren Sie AWS CLI V1. AWS CLI V2 ist für 32-Bit-ARM-Geräte nicht verfügbar. Weitere Informationen finden Sie unter [Installation, Aktualisierung und Deinstallation von AWS CLI Version 1.](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv1.html)
+ Um die GDK-CLI zum Veröffentlichen von Komponenten im AWS IoT Greengrass Service zu verwenden, benötigen Sie die folgenden Berechtigungen:
+ `s3:CreateBucket`
+ `s3:GetBucketLocation`
+ `s3:PutObject`
+ `greengrass:CreateComponentVersion`
+ `greengrass:ListComponentVersions`
+ Um mit der GDK-CLI eine Komponente zu erstellen, deren Artefakte in einem S3-Bucket und nicht im lokalen Dateisystem existieren, benötigen Sie die folgenden Berechtigungen:
+ `s3:ListBucket`
Diese Funktion ist für GDK CLI v1.1.0 und höher verfügbar.
## Änderungsprotokoll
In der folgenden Tabelle werden die Änderungen in den einzelnen Versionen der GDK-CLI beschrieben. Weitere Informationen finden Sie auf der [Seite GDK CLI Releases](https://github.com/aws-greengrass/aws-greengrass-gdk-cli/releases) unter GitHub.
| **Version** | **Änderungen** |
| --- | --- |
| 1.6.2 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/greengrass/v2/developerguide/greengrass-development-kit-cli.html) |
| 1.6.1 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/greengrass/v2/developerguide/greengrass-development-kit-cli.html) |
| 1.6.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/greengrass/v2/developerguide/greengrass-development-kit-cli.html) |
| 1.5.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/greengrass/v2/developerguide/greengrass-development-kit-cli.html) |
| 1.4.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/greengrass/v2/developerguide/greengrass-development-kit-cli.html) |
| 1.3.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/greengrass/v2/developerguide/greengrass-development-kit-cli.html) |
| 1.2.3 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/greengrass/v2/developerguide/greengrass-development-kit-cli.html) |
| 1.2.2 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/greengrass/v2/developerguide/greengrass-development-kit-cli.html) |
| 1.2.1 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/greengrass/v2/developerguide/greengrass-development-kit-cli.html) |
| 1.2.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/greengrass/v2/developerguide/greengrass-development-kit-cli.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/greengrass/v2/developerguide/greengrass-development-kit-cli.html) |
| 1.1.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/greengrass/v2/developerguide/greengrass-development-kit-cli.html) |
| 1.0.0 | Erste Version |
# Installieren oder aktualisieren Sie die AWS IoT Greengrass Development-Kit-Befehlszeilenschnittstelle
Das AWS IoT Greengrass Development Kit Command-Line Interface (GDK CLI) basiert auf Python, sodass Sie es auf Ihrem Entwicklungscomputer installieren können. `pip`
**Tipp**
Sie können die GDK-CLI auch in virtuellen Python-Umgebungen wie [venv](https://docs.python.org/3/library/venv.html#module-venv) installieren. Weitere Informationen finden Sie unter [Virtuelle Umgebungen und Pakete](https://docs.python.org/3/tutorial/venv.html) in der *Python 3-Dokumentation*.
**Um die GDK-CLI zu installieren oder zu aktualisieren**
1. Führen Sie den folgenden Befehl aus, um die neueste Version der GDK-CLI aus dem [GitHubRepository](https://github.com/aws-greengrass/aws-greengrass-gdk-cli) zu installieren.
```
python3 -m pip install -U git+https://github.com/aws-greengrass/aws-greengrass-gdk-cli.git@v1.6.2
```
**Anmerkung**
Um eine bestimmte Version der GDK-CLI zu installieren, *versionTag* ersetzen Sie sie durch das zu installierende Versions-Tag. Sie können Versionstags für die GDK-CLI in ihrem [GitHubRepository](https://github.com/aws-greengrass/aws-greengrass-gdk-cli/tags) anzeigen.
```
python3 -m pip install -U git+https://github.com/aws-greengrass/aws-greengrass-gdk-cli.git@versionTag
```
1. Führen Sie den folgenden Befehl aus, um zu überprüfen, ob die GDK-CLI erfolgreich installiert wurde.
```
gdk --help
```
Wenn der `gdk` Befehl nicht gefunden wird, fügen Sie seinen Ordner zu PATH hinzu.
+ Auf Linux-Geräten fügen Sie `/home/MyUser/.local/bin` es zu PATH hinzu und *MyUser* ersetzen Sie es durch den Namen Ihres Benutzers.
+ Fügen Sie auf Windows-Geräten PATH `PythonPath\\Scripts` hinzu und *PythonPath* ersetzen Sie es durch den Pfad zum Python-Ordner auf Ihrem Gerät.
Sie können jetzt die GDK-CLI verwenden, um Greengrass-Komponenten zu erstellen, zu erstellen und zu veröffentlichen. Weitere Informationen zur Verwendung der GDK-CLI finden Sie unter[AWS IoT Greengrass Befehle für die Befehlszeilenschnittstelle des Development Kits](greengrass-development-kit-cli-commands.md).
# AWS IoT Greengrass Befehle für die Befehlszeilenschnittstelle des Development Kits
Das AWS IoT Greengrass Development Kit Command-Line Interface (GDK CLI) bietet eine Befehlszeilenschnittstelle, mit der Sie Greengrass-Komponenten auf Ihrem Entwicklungscomputer erstellen, erstellen und veröffentlichen können. GDK-CLI-Befehle verwenden das folgende Format.
```
gdk [arguments]
```
Wenn Sie [die GDK-CLI installieren](install-greengrass-development-kit-cli.md), fügt das Installationsprogramm dem PATH `gdk` etwas hinzu, sodass Sie die GDK-CLI von der Befehlszeile aus ausführen können.
Sie können die folgenden Argumente mit jedem Befehl verwenden:
+ Verwenden Sie `-h` oder `--help` für Informationen zu einem GDK-CLI-Befehl.
+ Verwenden Sie `-v` oder`--version`, um zu sehen, welche Version von GDK CLI installiert ist.
+ Verwenden Sie `-d` oder`--debug`, um ausführliche Protokolle auszugeben, die Sie zum Debuggen der GDK-CLI verwenden können.
In diesem Abschnitt werden die GDK-CLI-Befehle beschrieben und Beispiele für jeden Befehl bereitgestellt. Die Zusammenfassung für jeden Befehl zeigt seine Argumente und ihre Verwendung. Optionale Argumente werden in eckigen Klammern angezeigt.
**Topics**
+ [Komponente](greengrass-development-kit-cli-component.md)
+ [config](greengrass-development-kit-cli-config.md)
+ [test-e2e](greengrass-development-kit-cli-test.md)
# Komponente
Verwenden Sie den `component` Befehl im AWS IoT Greengrass Development Kit Command-Line Interface (GDK CLI), um benutzerdefinierte Greengrass-Komponenten zu erstellen, zu erstellen und zu veröffentlichen.
**Topics**
+ [init](#greengrass-development-kit-cli-component-init)
+ [build](#greengrass-development-kit-cli-component-build)
+ [publish](#greengrass-development-kit-cli-component-publish)
+ [auflisten](#greengrass-development-kit-cli-component-list)
## init
Initialisieren Sie einen Greengrass-Komponentenordner aus einer Komponentenvorlage oder Community-Komponente.
Die GDK CLI ruft Community-Komponenten aus dem [Greengrass-Softwarekatalog](greengrass-software-catalog.md) und Komponentenvorlagen aus dem Component [AWS IoT Greengrass Templates-Repository](https://github.com/aws-greengrass/aws-greengrass-component-templates) ab. GitHub
**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.
Wenn die Komponente das [Zip-Build-System](gdk-cli-configuration-file.md#gdk-cli-configuration-file-build-system) verwendet, komprimiert die GDK-CLI bestimmte Dateien im 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`. Im Komponentenrezept muss der Name des ZIP-Artefakts mit dem Namen des Komponentenordners übereinstimmen. 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 Sie eine Vorlage oder Community-Komponente, die das ZIP-Build-System verwendet, für einen Ordner mit einem anderen Namen als die Vorlage oder Komponente initialisieren, müssen Sie den Namen des ZIP-Artefakts im Komponentenrezept ändern. Aktualisieren Sie die `Lifecycle` Definitionen `Artifacts` und so, dass der Name der Zip-Datei mit dem Namen des Komponentenordners übereinstimmt. Im folgenden Beispiel wird der Name der Zip-Datei in den `Lifecycle` Definitionen `Artifacts` und hervorgehoben.
```
{
...
"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}"
}
}
]
}
```
```
---
...
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}"
```
**Syntax**
```
$ gdk component init
[--language]
[--template]
[--repository]
[--name]
```
**Argumente (aus der Komponentenvorlage initialisieren)**
+ `-l`, `--language` — Die Programmiersprache, die für die von Ihnen angegebene Vorlage verwendet werden soll.
Sie müssen entweder `--repository` oder `--language` und angeben`--template`.
+ `-t`, `--template` — Die Komponentenvorlage, die für ein lokales Komponentenprojekt verwendet werden soll. Verwenden Sie den Befehl [list](#greengrass-development-kit-cli-component-list), um die verfügbaren Vorlagen anzuzeigen.
Sie müssen entweder `--repository` oder `--language` und angeben`--template`.
+ `-n`, `--name` — (Optional) Der Name des lokalen Ordners, in dem die GDK-CLI die Komponente initialisiert. Geben Sie einen Ordner an, der nicht existiert. Die GDK-CLI erstellt den Ordner für Sie.
Diese Funktion ist für GDK CLI v1.1.0 und höher verfügbar.
**Argumente (von der Community-Komponente aus initialisieren)**
+ `-r`, `--repository` — Die Community-Komponente, die in den lokalen Ordner ausgecheckt werden soll. Verwenden Sie den Befehl [list](#greengrass-development-kit-cli-component-list), um die verfügbaren Community-Komponenten anzuzeigen.
Sie müssen entweder `--repository` oder `--language` und angeben`--template`.
+ `-n`, `--name` — (Optional) Der Name des lokalen Ordners, in dem die GDK-CLI die Komponente initialisiert. Geben Sie einen Ordner an, der nicht existiert. Die GDK-CLI erstellt den Ordner für Sie.
Diese Funktion ist für GDK CLI v1.1.0 und höher verfügbar.
**Ausgabe**
Das folgende Beispiel zeigt die Ausgabe, die erzeugt wird, wenn Sie diesen Befehl ausführen, um einen Komponentenordner aus der Python-Vorlage Hello World zu initialisieren.
```
$ gdk component init -l python -t HelloWorld
[2021-11-29 12:51:40] INFO - Initializing the project directory with a python component template - 'HelloWorld'.
[2021-11-29 12:51:40] INFO - Fetching the component template 'HelloWorld-python' from Greengrass Software Catalog.
```
Das folgende Beispiel zeigt die Ausgabe, die erzeugt wird, wenn Sie diesen Befehl ausführen, um einen Komponentenordner aus einer Community-Komponente zu initialisieren.
```
$ gdk component init -r aws-greengrass-labs-database-influxdb
[2022-01-24 15:44:33] INFO - Initializing the project directory with a component from repository catalog - 'aws-greengrass-labs-database-influxdb'.
[2022-01-24 15:44:33] INFO - Fetching the component repository 'aws-greengrass-labs-database-influxdb' from Greengrass Software Catalog.
```
## build
Erstellen Sie aus der Quelle einer Komponente ein Rezept und Artefakte, die Sie im AWS IoT Greengrass Service veröffentlichen können. Die GDK-CLI führt das Build-System aus, das Sie in der [GDK-CLI-Konfigurationsdatei](gdk-cli-configuration-file.md) angeben,. `gdk-config.json` Sie müssen diesen Befehl in demselben Ordner ausführen, in dem sich die `gdk-config.json` Datei befindet.
Wenn Sie diesen Befehl ausführen, erstellt die GDK-CLI ein Rezept und Artefakte in dem `greengrass-build` Ordner im Komponentenordner. Die GDK-CLI speichert das Rezept im `greengrass-build/recipes` Ordner und speichert die Artefakte im `greengrass-build/artifacts/componentName/componentVersion` Ordner.
Wenn Sie GDK CLI v1.1.0 oder höher verwenden, kann das Komponentenrezept Artefakte angeben, die in einem S3-Bucket vorhanden sind, aber nicht im lokalen Komponenten-Build-Ordner. Sie können diese Funktion verwenden, um die Bandbreitennutzung zu reduzieren, wenn Sie Komponenten mit großen Artefakten entwickeln, z. B. Modelle für maschinelles Lernen.
Nachdem Sie eine Komponente erstellt haben, können Sie eine der folgenden Aktionen ausführen, um sie auf einem Greengrass-Core-Gerät zu testen:
+ Wenn Sie auf einem anderen Gerät entwickeln als auf dem, auf dem Sie die AWS IoT Greengrass Core-Software ausführen, müssen Sie die Komponente veröffentlichen, um sie auf einem Greengrass-Core-Gerät bereitzustellen. Veröffentlichen Sie die Komponente im AWS IoT Greengrass Service und stellen Sie sie auf dem Greengrass-Core-Gerät bereit. Weitere Informationen finden Sie unter dem Befehl [publish](#greengrass-development-kit-cli-component-build) und[Erstellen von Bereitstellungen](create-deployments.md).
+ Wenn Sie auf demselben Gerät entwickeln, auf dem Sie die AWS IoT Greengrass Core-Software ausführen, können Sie die Komponente im AWS IoT Greengrass Dienst veröffentlichen, um sie bereitzustellen, oder Sie können eine lokale Bereitstellung erstellen, um die Komponente zu installieren und auszuführen. Verwenden Sie die Greengrass-CLI, um eine lokale Bereitstellung zu erstellen. Weitere Informationen erhalten Sie unter [Greengrass-Befehlszeilenschnittstelle](gg-cli.md) und [Testen Sie AWS IoT Greengrass Komponenten mit lokalen Bereitstellungen](test-components.md). Wenn Sie das lokale Deployment erstellen, geben Sie `greengrass-build/recipes` als Ordner für Rezepte und `greengrass-build/artifacts` als Ordner für Artefakte an.
**Syntax**
```
$ gdk component build
```
**Argumente**
Keine
**Ausgabe**
Das folgende Beispiel zeigt die Ausgabe, die erzeugt wird, wenn Sie diesen Befehl ausführen.
```
$ gdk component build
[2021-11-29 13:18:49] INFO - Getting project configuration from gdk-config.json
[2021-11-29 13:18:49] INFO - Found component recipe file 'recipe.yaml' in the project directory.
[2021-11-29 13:18:49] INFO - Building the component 'com.example.PythonHelloWorld' with the given project configuration.
[2021-11-29 13:18:49] INFO - Using 'zip' build system to build the component.
[2021-11-29 13:18:49] WARNING - This component is identified as using 'zip' build system. If this is incorrect, please exit and specify custom build command in the 'gdk-config.json'.
[2021-11-29 13:18:49] INFO - Zipping source code files of the component.
[2021-11-29 13:18:49] INFO - Copying over the build artifacts to the greengrass component artifacts build folder.
[2021-11-29 13:18:49] INFO - Updating artifact URIs in the recipe.
[2021-11-29 13:18:49] INFO - Creating component recipe in 'C:\Users\MyUser\Documents\greengrass-components\python\HelloWorld\greengrass-build\recipes'.
```
## publish
Veröffentlichen Sie diese Komponente im AWS IoT Greengrass Service. Dieser Befehl lädt Build-Artefakte in einen S3-Bucket hoch, aktualisiert den Artefakt-URI im Rezept und erstellt anhand des Rezepts eine neue Version der Komponente. Die GDK-CLI verwendet den S3-Bucket und die AWS Region, die Sie in der [GDK-CLI-Konfigurationsdatei](gdk-cli-configuration-file.md) angeben. `gdk-config.json` Sie müssen diesen Befehl in demselben Ordner ausführen, in dem sich die `gdk-config.json` Datei befindet.
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.
Wenn Sie GDK CLI v1.2.0 oder höher verwenden, können Sie die in der GDK-CLI-Konfigurationsdatei AWS-Region angegebenen Werte mithilfe des Parameters überschreiben. `--region` Sie können mit dem Parameter auch zusätzliche Optionen angeben. `--options` Eine Liste der verfügbaren Optionen finden Sie unter[CLI-Konfigurationsdatei für das Greengrass Development Kit](gdk-cli-configuration-file.md).
Wenn Sie diesen Befehl ausführen, veröffentlicht die GDK-CLI die Komponente mit der Version, die Sie im Rezept angeben. Wenn Sie angeben`NEXT_PATCH`, verwendet die GDK-CLI die nächste Patch-Version, die noch nicht existiert. *Semantische Versionen verwenden eine Hauptversion.* *geringfügig*. *Patch-Nummerierungssystem*. Weitere Informationen finden Sie in der [semantischen Versionsspezifikation](https://semver.org/).
**Anmerkung**
Wenn Sie GDK CLI v1.1.0 oder höher verwenden und diesen Befehl ausführen, prüft die GDK-CLI, ob die Komponente erstellt wurde. Wenn die Komponente nicht erstellt wurde, erstellt die GDK-CLI [die Komponente](#greengrass-development-kit-cli-component-build), bevor sie die Komponente veröffentlicht.
**Syntax**
```
$ gdk component publish
[--bucket] [--region] [--options]
```
**Argumente**
+ `-b`, `--bucket` — (Optional) Geben Sie den Namen des S3-Buckets an, in dem die GDK-CLI Komponentenartefakte veröffentlicht.
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.
Die GDK-CLI erstellt den Bucket, falls er nicht existiert.
Diese Funktion ist für GDK CLI v1.1.0 und höher verfügbar.
+ `-r`, `--region` — (Optional) Geben Sie bei der Erstellung der Komponente AWS-Region den Namen des Ziels an. Dieses Argument überschreibt den Namen der Region in der GDK-CLI-Konfiguration.
Diese Funktion ist für GDK CLI v1.2.0 und höher verfügbar.
+ `-o`, `--options` (Optional) Geben Sie eine Liste mit Optionen für die Veröffentlichung einer Komponente an. Das Argument muss eine gültige JSON-Zeichenfolge oder ein Dateipfad zu einer JSON-Datei sein, die die Veröffentlichungsoptionen enthält. Dieses Argument überschreibt die Optionen in der GDK-CLI-Konfiguration.
Diese Funktion ist für GDK CLI v1.2.0 und höher verfügbar.
**Ausgabe**
Das folgende Beispiel zeigt die Ausgabe, die erzeugt wird, wenn Sie diesen Befehl ausführen.
```
$ gdk component publish
[2021-11-29 13:45:29] INFO - Getting project configuration from gdk-config.json
[2021-11-29 13:45:29] INFO - Found component recipe file 'recipe.yaml' in the project directory.
[2021-11-29 13:45:29] INFO - Found credentials in shared credentials file: ~/.aws/credentials
[2021-11-29 13:45:30] INFO - Publishing the component 'com.example.PythonHelloWorld' with the given project configuration.
[2021-11-29 13:45:30] INFO - No private version of the component 'com.example.PythonHelloWorld' exist in the account. Using '1.0.0' as the next version to create.
[2021-11-29 13:45:30] INFO - Uploading the component built artifacts to s3 bucket.
[2021-11-29 13:45:30] INFO - Uploading component artifacts to S3 bucket: {bucket}. If this is your first time using this bucket, add the 's3:GetObject' permission to each core device's token exchange role to allow it to download the component artifacts. For more information, see https://docs.aws.amazon.com/greengrass/v2/developerguide/device-service-role.html.
[2021-11-29 13:45:30] INFO - Not creating an artifacts bucket as it already exists.
[2021-11-29 13:45:30] INFO - Updating the component recipe com.example.PythonHelloWorld-1.0.0.
[2021-11-29 13:45:30] INFO - Creating a new greengrass component com.example.PythonHelloWorld-1.0.0
[2021-11-29 13:45:30] INFO - Created private version '1.0.0' of the component in the account.'com.example.PythonHelloWorld'.
```
## auflisten
Rufen Sie die Liste der verfügbaren Komponentenvorlagen und Community-Komponenten ab.
Die GDK CLI ruft Community-Komponenten aus dem [Greengrass-Softwarekatalog](greengrass-software-catalog.md) und Komponentenvorlagen aus dem Component [AWS IoT Greengrass Templates-Repository](https://github.com/aws-greengrass/aws-greengrass-component-templates) ab. GitHub
Sie können die Ausgabe dieses Befehls an den Befehl [init](#greengrass-development-kit-cli-component-init) übergeben, um Komponenten-Repositorys aus Vorlagen und Community-Komponenten zu initialisieren.
**Syntax**
```
$ gdk component list
[--template]
[--repository]
```
**Argumente**
+ `-t`, `--template` — (Optional) Geben Sie dieses Argument an, um die verfügbaren Komponentenvorlagen aufzulisten. Dieser Befehl gibt den Namen und die Sprache jeder Vorlage im Format aus`name-language`. Zum Beispiel ist in `HelloWorld-python` der Vorlagenname `HelloWorld` und die Sprache ist`python`.
+ `-r`, `--repository` — (Optional) Geben Sie dieses Argument an, um die verfügbaren Repositorys für Community-Komponenten aufzulisten.
**Ausgabe**
Das folgende Beispiel zeigt die Ausgabe, die erzeugt wird, wenn Sie diesen Befehl ausführen.
```
$ gdk component list --template
[2021-11-29 12:29:04] INFO - Listing all the available component templates from Greengrass Software Catalog.
[2021-11-29 12:29:04] INFO - Found '2' component templates to display.
1. HelloWorld-python
2. HelloWorld-java
```
# config
Verwenden Sie den `config` Befehl im AWS IoT Greengrass Development Kit Command-Line Interface (GDK CLI), um die Konfiguration für das GDK in der Konfigurationsdatei zu ändern. `gdk-config.json`
**Topics**
+ [update](#greengrass-development-kit-cli-config-update)
## update
Startet eine interaktive Eingabeaufforderung, um Felder in einer vorhandenen GDK-Konfigurationsdatei zu ändern.
**Syntax**
```
$ gdk config update
[--component]
```
**Argumente**
+ `-c`, `--component` — Um komponentenbezogene Felder in der Datei zu aktualisieren. `gdk-config.json` Dieses Argument ist erforderlich, da es die einzige Option ist.
**Ausgabe**
Das folgende Beispiel zeigt die Ausgabe, die erzeugt wird, wenn Sie diesen Befehl ausführen, um eine Komponente zu konfigurieren.
```
$ gdk config update --component
Current value of the REQUIRED component_name is (default: com.example.PythonHelloWorld):
Current value of the REQUIRED author is (default: author):
Current value of the REQUIRED version is (default: NEXT_PATCH):
Do you want to change the build configurations? (y/n)
Do you want to change the publish configurations? (y/n)
[2023-09-26 10:19:48] INFO - Config file has been updated. Exiting...
```
# test-e2e
Verwenden Sie den `test-e2e` Befehl im AWS IoT Greengrass Development Kit Command-Line Interface (GDK CLI), um end-to-end Testmodule im GDK-Projekt zu initialisieren, zu erstellen und auszuführen.
**Topics**
+ [init](#greengrass-development-kit-cli-test-init)
+ [build](#greengrass-development-kit-cli-test-build)
+ [run](#greengrass-development-kit-cli-test-run)
## init
Initialisieren Sie ein vorhandenes GDK-CLI-Projekt mit einem Testmodul, das Greengrass Testing Framework (GTF) verwendet.
Standardmäßig ruft GDK CLI die Maven-Modulvorlage aus dem [AWS IoT Greengrass Component Templates-Repository](https://github.com/aws-greengrass/aws-greengrass-component-templates) ab. GitHub Dieses Maven-Modul ist von der JAR-Datei abhängig. `aws-greengrass-testing-standalone`
Dieser Befehl erstellt ein neues Verzeichnis, das `gg-e2e-tests` innerhalb des GDK-Projekts aufgerufen wird. Wenn das Verzeichnis des Testmoduls bereits existiert und nicht leer ist, wird der Befehl beendet, ohne etwas zu tun. Dieser `gg-e2e-tests` Ordner enthält die Cucumber-Funktion und die Schrittdefinitionen, die in einem Maven-Projekt strukturiert sind.
Standardmäßig versucht dieser Befehl, die neueste Release-Version von GTF zu verwenden.
**Syntax**
```
$ gdk test-e2e init
[--gtf-version]
```
**Argumente**
+ `-ov`, `--gtf-version` — (Optional) Die Version der GTF, die mit dem end-to-end Testmodul im GDK-Projekt verwendet werden soll. [Dieser Wert muss eine der GTF-Versionen aus Releases sein.](https://github.com/aws-greengrass/aws-greengrass-testing/releases) Dieses Argument überschreibt die `gtf_version` in der GDK-CLI-Konfiguration.
**Ausgabe**
Das folgende Beispiel zeigt die Ausgabe, die erzeugt wird, wenn Sie diesen Befehl ausführen, um das GDK-Projekt mit dem Testmodul zu initialisieren.
```
$ gdk test-e2e init
[2023-12-06 12:20:28] INFO - Using the GTF version provided in the GDK test config 1.2.0
[2023-12-06 12:20:28] INFO - Downloading the E2E testing template from GitHub into gg-e2e-tests directory...
```
## build
**Anmerkung**
Sie müssen die Komponente erstellen, indem Sie sie ausführen, **gdk component build** bevor Sie das end-to-end Testmodul erstellen.
Erstellen Sie das end-to-end Testmodul. Die GDK-CLI erstellt das Testmodul mit dem Build-System, das Sie in der [GDK-CLI-Konfigurationsdatei](gdk-cli-configuration-file.md) unter der `gdk-config.json` `test-e2e` Eigenschaft angeben. Sie müssen diesen Befehl in demselben Ordner ausführen, in dem sich die `gdk-config.json` Datei befindet.
Standardmäßig verwendet GDK CLI das Maven-Build-System, um das Testmodul zu erstellen. [Maven](https://maven.apache.org/) ist erforderlich, um den Befehl auszuführen. `gdk test-e2e build`
Sie müssen die Komponente erstellen, indem Sie **gdk-component-build** sie vor dem Erstellen des Testmoduls ausführen, wenn die Testfunktionsdateien Variablen wie `GDK_COMPONENT_NAME` und `GDK_COMPONENT_RECIPE_FILE` zum Interpolieren enthalten.
Wenn Sie diesen Befehl ausführen, interpoliert die GDK-CLI alle Variablen aus der GDK-Projektkonfiguration und erstellt das `gg-e2e-tests` Modul, um die endgültige Test-JAR-Datei zu generieren.
**Syntax**
```
$ gdk test-e2e build
```
**Argumente**
Keine
**Ausgabe**
Das folgende Beispiel zeigt die Ausgabe, die erzeugt wird, wenn Sie diesen Befehl ausführen.
```
$ gdk test-e2e build
[2023-07-20 15:36:48] INFO - Updating feature file: file:///path/to//HelloWorld/greengrass-build/gg-e2e-tests/src/main/resources/greengrass/features/component.feature
[2023-07-20 15:36:48] INFO - Creating the E2E testing recipe file:///path/to/HelloWorld/greengrass-build/recipes/e2e_test_recipe.yaml
[2023-07-20 15:36:48] INFO - Building the E2E testing module
[2023-07-20 15:36:48] INFO - Running the build command 'mvn package'
.........
```
## run
Führen Sie das Testmodul mit den Testoptionen in der GDK-Konfigurationsdatei aus.
**Anmerkung**
Sie müssen das Testmodul erstellen, indem Sie es ausführen, **gdk test-e2e build** bevor Sie die end-to-end Tests ausführen.
**Syntax**
```
$ gdk test-e2e run
[--gtf-options]
```
**Argumente**
+ `-oo`, `--gtf-options` — (Optional) Geben Sie eine Liste von Optionen für die Ausführung der end-to-end Tests an. Das Argument muss eine gültige JSON-Zeichenfolge oder ein Dateipfad zu einer JSON-Datei sein, die die GTF-Optionen enthält. Die in der Konfigurationsdatei bereitgestellten Optionen werden mit den in den Befehlsargumenten bereitgestellten Optionen zusammengeführt. Wenn eine Option an beiden Stellen vorhanden ist, hat die Option im Argument Vorrang vor der Option aus der Konfigurationsdatei.
Wenn die `tags` Option in diesem Befehl nicht angegeben ist, verwendet `Sample` GDK die Tags for. Wenn nicht `ggc-archive` angegeben, lädt GDK die neueste Version des Greengrass Nucleus-Archivs herunter.
**Ausgabe**
Das folgende Beispiel zeigt die Ausgabe, die erzeugt wird, wenn Sie diesen Befehl ausführen.
```
$ gdk test-e2e run
[2023-07-20 16:35:53] INFO - Downloading latest nucleus archive from url https://d2s8p88vqu9w66.cloudfront.net/releases/greengrass-latest.zip
[2023-07-20 16:35:57] INFO - Running test jar with command java -jar /path/to/greengrass-build/gg-e2e-tests/target/uat-features-1.0.0.jar —ggc-archive=/path/to/aws-greengrass-gdk-cli/HelloWorld/greengrass-build/greengrass-nucleus-latest.zip —tags=Sample
16:35:59.693 [] [] [] [INFO] com.aws.greengrass.testing.modules.GreengrassContextModule - Extracting /path/to/workplace/aws-greengrass-gdk-cli/HelloWorld/greengrass-build/greengrass-nucleus-latest.zip into /var/folders/7g/ltzcb_3s77nbtmkzfb6brwv40000gr/T/gg-testing-7718418114158172636/greengrass
16:36:00.534 [gtf-1.1.0-SNAPSHOT] [] [] [INFO] com.aws.greengrass.testing.features.LoggerSteps - GTF Version is gtf-1.1.0-SNAPSHOT
.......
```
# CLI-Konfigurationsdatei für das Greengrass Development Kit
Das AWS IoT Greengrass Development Kit Command-Line Interface (GDK CLI) liest aus einer Konfigurationsdatei mit dem Namen Komponenten `gdk-config.json` erstellen und veröffentlichen. Diese Konfigurationsdatei muss im Stammverzeichnis des Komponenten-Repositorys vorhanden sein. Sie können den GDK [CLI-Befehl init](greengrass-development-kit-cli-component.md#greengrass-development-kit-cli-component-init) verwenden, um Komponenten-Repositorys mit dieser Konfigurationsdatei zu initialisieren.
**Topics**
+ [GDK CLI-Konfigurationsdateiformat](#gdk-config-format)
+ [Beispiele für GDK-CLI-Konfigurationsdateien](#gdk-config-examples)
## GDK CLI-Konfigurationsdateiformat
Wenn Sie eine GDK-CLI-Konfigurationsdatei für eine Komponente definieren, geben Sie die folgenden Informationen im JSON-Format an.
`gdk_version`
Die Mindestversion der GDK-CLI, die mit dieser Komponente kompatibel ist. Dieser Wert muss eine der GDK-CLI-Versionen aus [Releases](https://github.com/aws-greengrass/aws-greengrass-gdk-cli/releases) sein.
`component`
Die Konfiguration für diese Komponente.
`componentName`
`author`
Der Autor oder Herausgeber der Komponente.
`version`
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, z. B. **1.0.0** *Semantische Versionen verwenden eine Hauptversion.* *geringfügig*. *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.
`build`
Die Konfiguration, die verwendet werden soll, um den Quellcode dieser Komponente in Artefakte umzuwandeln. Dieses Objekt enthält die folgenden Informationen:
`build_system`
Das zu verwendende Build-System. Wählen Sie aus den folgenden Optionen aus:
+ `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.
`custom_build_command`
(Optional) Der benutzerdefinierte Build-Befehl, der für ein benutzerdefiniertes Build-System ausgeführt werden soll. Sie müssen diesen Parameter angeben, wenn Sie `custom` für angeben`build_system`.
Mit diesem Befehl müssen ein Rezept und Artefakte in den folgenden Ordnern innerhalb des Komponentenordners erstellt werden. Die GDK-CLI erstellt diese Ordner für Sie, wenn Sie den [Befehl component build](greengrass-development-kit-cli-component.md#greengrass-development-kit-cli-component-build) ausführen.
+ Rezeptordner: `greengrass-build/recipes`
+ Ordner „Artefakte“: `greengrass-build/artifacts/componentName/componentVersion`
*componentName*Ersetzen Sie durch den Komponentennamen und *componentVersion* ersetzen Sie durch die Komponentenversion oder`NEXT_PATCH`.
Sie können eine einzelne Zeichenfolge oder eine Liste von Zeichenfolgen angeben, 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 **cmake --build build --config Release** oder angeben**["cmake", "--build", "build", "--config", "Release"]**.
Ein Beispiel für ein benutzerdefiniertes Build-System finden Sie im [aws.greengrass.labs.LocalWebServer community component nein GitHub](https://github.com/awslabs/aws-greengrass-labs-local-web-server).
`options`
(Optional) Zusätzliche Konfigurationsoptionen, die während des Komponentenerstellungsprozesses verwendet werden.
Diese Funktion ist für GDK CLI v1.2.0 und höher verfügbar.
`excludes`
Eine Liste von Glob-Mustern, die definieren, welche Dateien beim Erstellen der ZIP-Datei aus dem Komponentenverzeichnis ausgeschlossen werden sollen. Nur gültig, wenn der `build_system` ist`zip`.
In den GDK CLI-Versionen 1.4.0 und früher wird jede Datei, die einem Eintrag in der Ausnahmeliste entspricht, aus allen Unterverzeichnissen der Komponente ausgeschlossen. Um dasselbe Verhalten in den GDK-CLI-Versionen 1.5.0 und höher `**/` zu erreichen, stellen Sie sie den vorhandenen Einträgen in der Ausschlussliste voran. Schließt beispielsweise `*.txt` Textdateien nur aus dem Verzeichnis aus; schließt Textdateien aus allen `**/*.txt` Verzeichnissen und Unterverzeichnissen aus.
In den GDK-CLI-Versionen 1.5.0 und höher wird möglicherweise während des Komponenten-Builds eine Warnung angezeigt, wenn dies in der GDK-Konfigurationsdatei definiert `excludes` ist. Um diese Warnung zu deaktivieren, setzen Sie die Umgebungsvariable auf. `GDK_EXCLUDES_WARN_IGNORE` `true`
Die GDK-CLI schließt immer die folgenden Dateien aus der Zip-Datei aus:
+ Die Datei `gdk-config.json`
+ Die Rezeptdatei (oder) `recipe.json` `recipe.yaml`
+ Erstellen Sie Ordner, wie `greengrass-build`
Die folgenden Dateien sind standardmäßig ausgeschlossen. Mit der `excludes` Option können Sie jedoch steuern, welche dieser Dateien ausgeschlossen werden.
+ Jeder Ordner, der mit dem Präfix „test“ (`test*`) beginnt
+ Alle versteckten Dateien
+ Den Ordner `node_modules`
Wenn Sie die `excludes` Option angeben, schließt die GDK-CLI nur die Dateien aus, die Sie mit der `excludes` Option festgelegt haben. Wenn Sie die `excludes` Option nicht angeben, schließt die GDK-CLI die zuvor angegebenen Standarddateien und -ordner aus.
`zip_name`
Der Name der Zip-Datei, die verwendet werden soll, wenn Sie während des Build-Prozesses ein ZIP-Artefakt erstellen. Nur gültig, wenn der `build_system` ist`zip`. Wenn das leer `build_system` ist, wird der Komponentenname für den Namen der Zip-Datei verwendet.
`publish`
Die Konfiguration, die verwendet werden soll, um diese Komponente im AWS IoT Greengrass Service zu veröffentlichen.
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.
Dieses Objekt enthält die folgenden Informationen:
`bucket`
Der S3-Bucket-Name, der zum Hosten von Komponentenartefakten verwendet werden soll.
`region`
Der AWS-Region Ort, an dem die GDK-CLI diese Komponente veröffentlicht.
Diese Eigenschaft ist optional, wenn Sie GDK CLI v1.3.0 oder höher verwenden.
`options`
(Optional) Zusätzliche Konfigurationsoptionen, die bei der Erstellung der Komponentenversion verwendet werden.
Diese Funktion ist für GDK CLI v1.2.0 und höher verfügbar.
`file_upload_args`
Eine JSON-Struktur mit Argumenten, die beim Hochladen von Dateien in einen Bucket an Amazon S3 gesendet werden, z. B. Metadaten und Verschlüsselungsmechanismen. Eine Liste der zulässigen Argumente finden Sie in der [https://boto3.amazonaws.com/v1/documentation/api/latest/reference/customizations/s3.html#boto3.s3.transfer.S3Transfer.ALLOWED_UPLOAD_ARGS](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/customizations/s3.html#boto3.s3.transfer.S3Transfer.ALLOWED_UPLOAD_ARGS)Klasse in der *Boto3-Dokumentation*. .
`test-e2e`
(Optional) Die Konfiguration, die beim end-to-end Testen der Komponente verwendet werden soll. Diese Funktion ist für GDK CLI v1.3.0 und höher verfügbar.
`build`
`build_system`— Das zu verwendende Build-System. Die Standardoption ist`maven`. Wählen Sie aus den folgenden Optionen aus:
+ `maven`— Führt den `mvn package` Befehl zum Erstellen des Testmoduls aus. Wählen Sie diese Option, um das Testmodul zu erstellen, das [Maven](https://maven.apache.org/) verwendet.
+ `gradle`— Führt den `gradle build` Befehl zum Erstellen des Testmoduls aus. Wählen Sie diese Option für das Testmodul, das [Gradle](https://gradle.org/) verwendet.
`gtf_version`
(Optional) Die Version des Greengrass Testing Framework (GTF), die als Abhängigkeit des end-to-end Testmoduls verwendet werden soll, wenn Sie das GDK-Projekt mit GTF initialisieren. [Bei diesem Wert muss es sich um eine der GTF-Versionen aus Releases handeln.](https://github.com/aws-greengrass/aws-greengrass-testing/releases) Die Standardeinstellung ist GTF-Version 1.1.0.
`gtf_options`
(Optional) Zusätzliche Konfigurationsoptionen, die beim end-to-end Testen der Komponente verwendet wurden.
Die folgende Liste enthält die Optionen, die Sie mit GTF Version 1.1.0 verwenden können.
+ `additional-plugins`— (Optional) Zusätzliche Cucumber-Plugins
+ `aws-region`— Zielt auf spezifische regionale Endpunkte für AWS Dienste ab. Standardmäßig wird das verwendet, was das AWS SDK entdeckt.
+ `credentials-path`— Optionaler Pfad für die AWS Profilanmeldedaten. Standardmäßig werden Anmeldeinformationen verwendet, die in der Host-Umgebung gefunden wurden.
+ `credentials-path-rotation`— Optionale Rotationsdauer für AWS Anmeldeinformationen. Der Standardwert ist 15 Minuten oder`PT15M`.
+ `csr-path`— Der Pfad für die CSR, mit der das Gerätezertifikat generiert wird.
+ `device-mode`— Das zu testende Zielgerät. Standardmäßig ist das lokale Gerät aktiviert.
+ `env-stage`— Zielt auf die Bereitstellungsumgebung von Greengrass ab. Standardmäßig auf Produktion eingestellt.
+ `existing-device-cert-arn`— Der ARN eines vorhandenen Zertifikats, das Sie als Gerätezertifikat für Greengrass verwenden möchten.
+ `feature-path`— Datei oder Verzeichnis mit zusätzlichen Funktionsdateien. Standardmäßig werden keine zusätzlichen Featuredateien verwendet.
+ `gg-cli-version`— Überschreibt die Version der Greengrass-CLI. Standardmäßig wird der Wert verwendet, der in gefunden wurde. `ggc.version`
+ `gg-component-bucket`— Der Name eines vorhandenen Amazon S3 S3-Buckets, der Greengrass-Komponenten enthält.
+ `gg-component-overrides`— Eine Liste von Greengrass-Komponenten-Overrides.
+ `gg-persist`— Eine Liste von Testelementen, die nach einem Testlauf beibehalten werden sollen. Das Standardverhalten besteht darin, nichts beizubehalten. Zulässige Werte sind: `aws.resources``installed.software`, und`generated.files`.
+ `gg-runtime`— Eine Liste von Werten, die beeinflussen sollen, wie der Test mit den Testressourcen interagiert. Diese Werte haben Vorrang vor dem Parameter. `gg.persist` Wenn der Standardwert leer ist, wird davon ausgegangen, dass alle Testressourcen nach Testfällen verwaltet werden, einschließlich der installierten Greengrass-Runtime. Zulässige Werte sind: `aws.resources``installed.software`, und. `generated.files`
+ `ggc-archive`— Der Pfad zur archivierten Greengrass-Kernkomponente.
+ `ggc-install-root`— Verzeichnis zur Installation der Greengrass Nucleus-Komponente. Standardmäßig ist dies der Ordner test.temp.path und der Testrun-Ordner.
+ `ggc-log-level`— Stellen Sie den Greengrass Nucleus Log Level für den Testlauf ein. Die Standardeinstellung ist „INFO“.
+ `ggc-tes-rolename`— Die IAM-Rolle, die AWS IoT Greengrass Core für den Zugriff auf AWS Dienste übernehmen wird. Wenn eine Rolle mit dem angegebenen Namen nicht existiert, wird eine erstellt und es wird eine Standardzugriffsrichtlinie festgelegt.
+ `ggc-trusted-plugins`— Die durch Kommas getrennte Liste der Pfade (auf dem Host) der vertrauenswürdigen Plugins, die zu Greengrass hinzugefügt werden müssen. Um den Pfad auf dem DUT selbst anzugeben, stellen Sie dem Pfad „dut:“ voran
+ `ggc-user-name`— Der posixUser-Wert user:group für den Greengrass-Kern. Standardmäßig wird der aktuelle Benutzername verwendet, der angemeldet ist.
+ `ggc-version`— Überschreibt die Version der laufenden Greengrass Nucleus-Komponente. Standardmäßig wird der in ggc.archive gefundene Wert verwendet.
+ `log-level`— Protokollebene des Testlaufs. Der Standardwert ist „INFO“.
+ `parallel-config`— Satz von Batch-Index und Anzahl der Batches als JSON-Zeichenfolge. Der Standardwert des Batch-Index ist 0 und die Anzahl der Batches ist 1.
+ `proxy-url`— Konfigurieren Sie alle Tests so, dass der Verkehr über diese URL weitergeleitet wird.
+ `tags`— Nur Feature-Tags ausführen. Kann mit '&' überschnitten werden
+ `test-id-prefix`— Ein gemeinsames Präfix, das auf alle testspezifischen Ressourcen angewendet wird, einschließlich AWS Ressourcennamen und Tags. Die Standardeinstellung ist ein „gg“ -Präfix.
+ `test-log-path`— Verzeichnis, das die Ergebnisse des gesamten Testlaufs enthalten wird. Der Standardwert ist „TestResults“.
+ `test-results-json`— Markierung, um festzustellen, ob ein resultierender Cucumber-JSON-Bericht generiert und auf die Festplatte geschrieben wird. Standardwert ist „true“.
+ `test-results-log`— Markierung, um festzustellen, ob die Konsolenausgabe generiert und auf die Festplatte geschrieben wird. Standardwert "false".
+ `test-results-xml`— Markierung, um festzustellen, ob ein JUnit resultierender XML-Bericht generiert und auf die Festplatte geschrieben wird. Standardwert ist „true“.
+ `test-temp-path`— Verzeichnis zum Generieren lokaler Testartefakte. Standardmäßig wird ein zufälliges temporäres Verzeichnis mit dem Präfix gg-testing verwendet.
+ `timeout-multiplier`— Für alle Test-Timeouts wird ein Multiplikator bereitgestellt. Standard = 1.0.
## Beispiele für GDK-CLI-Konfigurationsdateien
Sie können auf die folgenden Beispiele für GDK-CLI-Konfigurationsdateien verweisen, um Ihnen bei der Konfiguration von Greengrass-Komponentenumgebungen zu helfen.
### Hallo Welt (Python)
Die folgende GDK-CLI-Konfigurationsdatei unterstützt eine Hello World-Komponente, die ein Python-Skript ausführt. Diese Konfigurationsdatei verwendet das `zip` Build-System, um das Python-Skript der Komponente in eine ZIP-Datei zu packen, die die GDK-CLI als Artefakt hochlädt.
```
{
"component": {
"com.example.PythonHelloWorld": {
"author": "Amazon",
"version": "NEXT_PATCH",
"build": {
"build_system" : "zip",
"options": {
"excludes": [".*"]
}
},
"publish": {
"bucket": "greengrass-component-artifacts",
"region": "us-west-2",
"options": {
"file_upload_args": {
"Metadata": {
"some-key": "some-value"
}
}
}
}
},
"test-e2e":{
"build":{
"build_system": "maven"
},
"gtf_version": "1.1.0",
"gtf_options": {
"tags": "Sample"
}
},
"gdk_version": "1.6.1"
}
}
```
### Hallo Welt (Java)
Die folgende GDK-CLI-Konfigurationsdatei unterstützt eine Hello World-Komponente, die eine Java-Anwendung ausführt. Diese Konfigurationsdatei verwendet das `maven` Build-System, um den Java-Quellcode der Komponente in eine JAR-Datei zu packen, die die GDK-CLI als Artefakt hochlädt.
```
{
"component": {
"com.example.JavaHelloWorld": {
"author": "Amazon",
"version": "NEXT_PATCH",
"build": {
"build_system" : "maven"
},
"publish": {
"bucket": "greengrass-component-artifacts",
"region": "us-west-2",
"options": {
"file_upload_args": {
"Metadata": {
"some-key": "some-value"
}
}
}
}
},
"test-e2e":{
"build":{
"build_system": "maven"
},
"gtf_version": "1.1.0",
"gtf_options": {
"tags": "Sample"
}
},
"gdk_version": "1.6.1"
}
}
```
### Community-Komponenten
Mehrere Community-Komponenten im [Greengrass Software Catalog](greengrass-software-catalog.md) verwenden die GDK-CLI. Sie können die GDK-CLI-Konfigurationsdateien in den Repositorys dieser Komponenten durchsuchen.
**Um die GDK-CLI-Konfigurationsdateien von Community-Komponenten anzuzeigen**
1. Führen Sie den folgenden Befehl aus, um die Community-Komponenten aufzulisten, die die GDK-CLI verwenden.
```
gdk component list --repository
```
Die Antwort listet den Namen des GitHub Repositorys für jede Community-Komponente auf, die die GDK-CLI verwendet. Jedes Repository ist in der `awslabs` Organisation vorhanden.
```
[2022-02-22 17:27:31] INFO - Listing all the available component repositories from Greengrass Software Catalog.
[2022-02-22 17:27:31] INFO - Found '6' component repositories to display.
1. aws-greengrass-labs-database-influxdb
2. aws-greengrass-labs-telemetry-influxdbpublisher
3. aws-greengrass-labs-dashboard-grafana
4. aws-greengrass-labs-dashboard-influxdb-grafana
5. aws-greengrass-labs-local-web-server
6. aws-greengrass-labs-lookoutvision-gstreamer
```
1. Öffnen Sie das GitHub Repository einer Community-Komponente unter der folgenden URL. *community-component-name*Ersetzen Sie es durch den Namen einer Community-Komponente aus dem vorherigen Schritt.
```
https://github.com/awslabs/community-component-name
```
# Greengrass-Befehlszeilenschnittstelle
Mit der Greengrass-Befehlszeilenschnittstelle (CLI) können Sie mit AWS IoT Greengrass Core auf Ihrem Gerät interagieren, um Komponenten lokal zu entwickeln und Probleme zu debuggen. Sie können beispielsweise die Greengrass-CLI verwenden, um eine lokale Bereitstellung zu erstellen und eine Komponente auf dem Kerngerät neu zu starten.
Stellen Sie die [Greengrass-CLI-Komponente](greengrass-cli-component.md) (`aws.greengrass.Cli`) bereit, um die Greengrass-CLI auf Ihrem Kerngerät zu installieren.
**Wichtig**
Wir empfehlen, diese Komponente nur in Entwicklungsumgebungen zu verwenden, nicht in Produktionsumgebungen. Diese Komponente bietet Zugriff auf Informationen und Operationen, die Sie in einer Produktionsumgebung normalerweise nicht benötigen. Folgen Sie dem Prinzip der geringsten Rechte, indem Sie diese Komponente nur dort einsetzen, wo Sie sie benötigen.
**Topics**
+ [Installieren Sie die Greengrass-CLI](install-gg-cli.md)
+ [Greengrass-CLI-Befehle](gg-cli-reference.md)
# Installieren Sie die Greengrass-CLI
Sie können die Greengrass-CLI auf eine der folgenden Arten installieren:
+ Verwenden Sie das `--deploy-dev-tools` Argument, wenn Sie die AWS IoT Greengrass Core-Software zum ersten Mal auf Ihrem Gerät einrichten. Sie müssen auch angeben`--provision true`, ob dieses Argument angewendet werden soll.
+ Stellen Sie die Greengrass CLI-Komponente (`aws.greengrass.Cli`) auf Ihrem Gerät bereit.
In diesem Abschnitt werden die Schritte zur Bereitstellung der Greengrass-CLI-Komponente beschrieben. Hinweise zur Installation der Greengrass-CLI bei der Ersteinrichtung finden Sie unter[Tutorial: Erste Schritte mit AWS IoT Greengrass V2](getting-started.md).
## Voraussetzungen
Um die Greengrass CLI-Komponente bereitzustellen, müssen Sie die folgenden Anforderungen erfüllen:
+ AWS IoT Greengrass Kernsoftware, die auf Ihrem Kerngerät installiert und konfiguriert ist. Weitere Informationen finden Sie unter [Tutorial: Erste Schritte mit AWS IoT Greengrass V2](getting-started.md).
+ AWS CLI Um die Greengrass-CLI bereitzustellen, müssen Sie die AWS CLI installiert und konfiguriert haben. Weitere Informationen finden Sie unter [Konfigurieren der AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html) im *AWS Command Line Interface -Leitfaden*.
+ Sie müssen autorisiert sein, die Greengrass-CLI zu verwenden, um mit der AWS IoT Greengrass Core-Software zu interagieren. Führen Sie einen der folgenden Schritte aus, um die Greengrass-CLI zu verwenden:
+ Verwenden Sie den Systembenutzer, der die AWS IoT Greengrass Core-Software ausführt.
+ Verwenden Sie einen Benutzer mit Root- oder Administratorrechten. Auf Linux-Core-Geräten können Sie diese Option verwenden, um `sudo` Root-Rechte zu erhalten.
+ Verwenden Sie einen Systembenutzer, der zu einer Gruppe gehört, die Sie bei der Bereitstellung der Komponente in den `AuthorizedWindowsGroups` Konfigurationsparametern `AuthorizedPosixGroups` oder angeben. Weitere Informationen finden Sie unter [Konfiguration der Greengrass-CLI-Komponente](greengrass-cli-component.md#greengrass-cli-component-configuration).
## Stellen Sie die Greengrass-CLI-Komponente bereit
Gehen Sie wie folgt vor, um die Greengrass CLI-Komponente auf Ihrem Kerngerät bereitzustellen:
### Um die Greengrass CLI-Komponente (Konsole) bereitzustellen
1. Melden Sie sich bei der [AWS IoT Greengrass -Konsole](https://console.aws.amazon.com/greengrass) an.
1. Wählen Sie im Navigationsmenü **Komponenten**.
1. Wählen Sie auf der Seite **Komponenten** auf der Registerkarte **Öffentliche Komponenten** die Option `aws.greengrass.Cli` aus.
1. Wählen Sie auf der **aws.greengrass.Cli** Seite **Bereitstellen** aus.
1. Wählen **Sie unter Zur Bereitstellung hinzufügen** die Option **Neue Bereitstellung erstellen** aus.
1. Wählen Sie auf der Seite **Ziel angeben** unter **Bereitstellungsziele** in der Liste **Zielname** die Greengrass-Gruppe aus, für die Sie die Bereitstellung durchführen möchten, und klicken Sie auf **Weiter**.
1. Vergewissern **Sie sich auf der Seite „Komponenten auswählen**“, dass die **aws.greengrass.Cli**Komponente ausgewählt ist, und klicken Sie auf **Weiter**.
1. Behalten Sie auf der Seite **Komponenten konfigurieren** die Standardkonfigurationseinstellungen bei und wählen Sie **Weiter**.
1. Behalten Sie auf der Seite **Erweiterte Einstellungen konfigurieren** die Standardkonfigurationseinstellungen bei und wählen Sie **Weiter**.
1. Klicken Sie auf der Seite „**Überprüfen**“ auf **Bereitstellen**
### So stellen Sie die Greengrass-CLI-Komponente bereit ()AWS CLI
1. Erstellen Sie auf Ihrem Gerät eine `deployment.json` Datei, um die Bereitstellungskonfiguration für die Greengrass CLI-Komponente zu definieren. Diese Datei sollte wie folgt aussehen:
```
{
"targetArn":"targetArn",
"components": {
"aws.greengrass.Cli": {
"componentVersion": "2.16.1",
"configurationUpdate": {
"merge": "{\"AuthorizedPosixGroups\":\",,...,\",\"AuthorizedWindowsGroups\":\",,...,\"}"
}
}
}
}
```
+ Ersetzen Sie im `target` Feld `targetArn` durch den Amazon-Ressourcennamen (ARN) des Objekts oder der Objektgruppe, auf die die Bereitstellung ausgerichtet werden soll, und zwar im folgenden Format:
+ Objekt: `arn:aws:iot:region:account-id:thing/thingName`
+ Objektgruppe: `arn:aws:iot:region:account-id:thinggroup/thingGroupName`
+ Geben Sie im `aws.greengrass.Cli` Komponentenobjekt die Werte wie folgt an:
`version`
Die Version der Greengrass-CLI-Komponente.
`configurationUpdate.AuthorizedPosixGroups`
(Optional) Eine Zeichenfolge, die eine durch Kommas getrennte Liste von Systemgruppen enthält. Sie autorisieren diese Systemgruppen, die Greengrass-CLI für die Interaktion mit der AWS IoT Greengrass Core-Software zu verwenden. Sie können Gruppennamen oder Gruppen angeben. IDs `group1,1002,group3`Autorisiert beispielsweise drei Systemgruppen (`group1`, und`group3`)`1002`, die Greengrass-CLI zu verwenden.
Wenn Sie keine zu autorisierenden Gruppen angeben, können Sie die Greengrass-CLI als Root-Benutzer (`sudo`) oder als Systembenutzer verwenden, der die AWS IoT Greengrass Core-Software ausführt.
`configurationUpdate.AuthorizedWindowsGroups`
(Optional) Eine Zeichenfolge, die eine durch Kommas getrennte Liste von Systemgruppen enthält. Sie autorisieren diese Systemgruppen, die Greengrass-CLI für die Interaktion mit der AWS IoT Greengrass Core-Software zu verwenden. Sie können Gruppennamen oder Gruppen angeben. IDs `group1,1002,group3`Autorisiert beispielsweise drei Systemgruppen (`group1`, und`group3`)`1002`, die Greengrass-CLI zu verwenden.
Wenn Sie keine zu autorisierenden Gruppen angeben, können Sie die Greengrass-CLI als Administrator oder als Systembenutzer verwenden, der die AWS IoT Greengrass Core-Software ausführt.
1. Führen Sie den folgenden Befehl aus, um die Greengrass-CLI-Komponente auf dem Gerät bereitzustellen:
```
$ aws greengrassv2 create-deployment --cli-input-json file://path/to/deployment.json
```
Während der Installation fügt die Komponente einen symbolischen Link zu `greengrass-cli` dem `/greengrass/v2/bin` Ordner auf Ihrem Gerät hinzu, und Sie führen die Greengrass-CLI von diesem Pfad aus aus. Um die Greengrass-CLI ohne ihren absoluten Pfad auszuführen, fügen Sie Ihren `/greengrass/v2/bin` Ordner zu Ihrer PATH-Variablen hinzu. Führen Sie den folgenden Befehl aus, um die Greengrass CLI-Installation zu überprüfen:
------
#### [ Linux or Unix ]
```
/greengrass/v2/bin/greengrass-cli help
```
------
#### [ Windows ]
```
C:\greengrass\v2\bin\greengrass-cli help
```
------
Die Ausgabe sollte folgendermaßen aussehen:
```
Usage: greengrass-cli [-hV] [--ggcRootPath=] [COMMAND]
Greengrass command line interface
--ggcRootPath=
The AWS IoT Greengrass V2 root directory.
-h, --help Show this help message and exit.
-V, --version Print version information and exit.
Commands:
help Show help information for a command.
component Retrieve component information and stop or restart
components.
deployment Create local deployments and retrieve deployment status.
logs Analyze Greengrass logs.
get-debug-password Generate a password for use with the HTTP debug view
component.
```
Wenn das `greengrass-cli` nicht gefunden wird, konnte die Greengrass-CLI bei der Bereitstellung möglicherweise nicht installiert werden. Weitere Informationen finden Sie unter [Problembehebung AWS IoT Greengrass V2](troubleshooting.md).
# Greengrass-CLI-Befehle
Die Greengrass-CLI bietet eine Befehlszeilenschnittstelle für die lokale Interaktion mit Ihrem AWS IoT Greengrass Kerngerät. Greengrass-CLI-Befehle verwenden das folgende Format.
```
$ greengrass-cli [arguments]
```
Standardmäßig interagiert die `greengrass-cli` ausführbare Datei im `/greengrass/v2/bin/` Ordner mit der Version der AWS IoT Greengrass Core-Software, die `/greengrass/v2` im Ordner ausgeführt wird. Wenn Sie eine ausführbare Datei aufrufen, die sich nicht an diesem Speicherort befindet, oder wenn Sie mit der AWS IoT Greengrass Core-Software an einem anderen Speicherort interagieren möchten, müssen Sie eine der folgenden Methoden verwenden, um den Stammpfad der AWS IoT Greengrass Core-Software, mit der Sie interagieren möchten, explizit anzugeben:
+ Legen Sie die Umgebungsvariable `GGC_ROOT_PATH` auf `/greengrass/v2` fest.
+ Fügen Sie das `--ggcRootPath /greengrass/v2` Argument zu Ihrem Befehl hinzu, wie im folgenden Beispiel gezeigt.
```
greengrass-cli --ggcRootPath /greengrass/v2 [arguments]
```
Sie können die folgenden Argumente mit jedem Befehl verwenden:
+ Wird `--help` für Informationen über einen bestimmten Greengrass-CLI-Befehl verwendet.
+ Wird `--version` für Informationen über die Greengrass-CLI-Version verwendet.
In diesem Abschnitt werden die Greengrass-CLI-Befehle beschrieben und Beispiele für diese Befehle bereitgestellt. Die Zusammenfassung für jeden Befehl zeigt seine Argumente und ihre Verwendung. Optionale Argumente werden in eckigen Klammern angezeigt.
**Topics**
+ [Komponente](gg-cli-component.md)
+ [Bereitstellung](gg-cli-deployment.md)
+ [Protokolle](gg-cli-logs.md)
+ [get-debug-password](gg-cli-get-debug-password.md)
# Komponente
Verwenden Sie den `component` Befehl, um mit lokalen Komponenten auf Ihrem Kerngerät zu interagieren.
**Unterbefehle**
+ [Details](#component-details)
+ [auflisten](#component-list)
+ [Neustart](#component-restart)
+ [stop](#component-stop)
## Details
Rufen Sie die Version, den Status und die Konfiguration einer Komponente ab.
**Syntax**
```
greengrass-cli component details --name
```
**Argumente**
`--name`,`-n`. Der Name der Komponente.
**Ausgabe**
Das folgende Beispiel zeigt die Ausgabe, die erzeugt wird, wenn Sie diesen Befehl ausführen.
```
$ sudo greengrass-cli component details --name MyComponent
Component Name: MyComponent
Version: 1.0.0
State: RUNNING
Configuration: null
```
## auflisten
Rufen Sie den Namen, die Version, den Status und die Konfiguration aller auf dem Gerät installierten Komponenten ab.
**Syntax**
```
greengrass-cli component list
```
**Argumente**
Keine
**Ausgabe**
Das folgende Beispiel zeigt die Ausgabe, die erzeugt wird, wenn Sie diesen Befehl ausführen.
```
$ sudo greengrass-cli component list
Components currently running in Greengrass:
Component Name: FleetStatusService
Version: 0.0.0
State: RUNNING
Configuration: {"periodicUpdateIntervalSec":86400.0}
Component Name: UpdateSystemPolicyService
Version: 0.0.0
State: RUNNING
Configuration: null
Component Name: aws.greengrass.Nucleus
Version: 2.0.0
State: FINISHED
Configuration: {"awsRegion":"region","runWithDefault":{"posixUser":"ggc_user:ggc_group"},"telemetry":{}}
Component Name: DeploymentService
Version: 0.0.0
State: RUNNING
Configuration: null
Component Name: TelemetryAgent
Version: 0.0.0
State: RUNNING
Configuration: null
Component Name: aws.greengrass.Cli
Version: 2.0.0
State: RUNNING
Configuration: {"AuthorizedPosixGroups":"ggc_user"}
```
## Neustart
Starten Sie die Komponenten neu.
**Syntax**
```
greengrass-cli component restart --names ,...
```
**Argumente**
`--names`,`-n`. Der Name der Komponente. Es ist mindestens ein Komponentenname erforderlich. Sie können zusätzliche Komponentennamen angeben, indem Sie die einzelnen Namen durch ein Komma trennen.
**Ausgabe**
Keine
## stop
Beenden Sie die Ausführung von Komponenten.
**Syntax**
```
greengrass-cli component stop --names ,...
```
**Argumente**
`--names`,`-n`. Der Name der Komponente. Es ist mindestens ein Komponentenname erforderlich. Sie können bei Bedarf weitere Komponentennamen angeben, wobei Sie die einzelnen Namen durch ein Komma trennen.
**Ausgabe**
Keine
# Bereitstellung
Verwenden Sie den `deployment` Befehl, um mit lokalen Komponenten auf Ihrem Kerngerät zu interagieren.
Verwenden Sie den `status` Unterbefehl, um den Fortschritt einer lokalen Bereitstellung zu überwachen. Sie können den Fortschritt einer lokalen Bereitstellung nicht mit der Konsole überwachen.
**Unterbefehle**
+ [create](#deployment-create)
+ [abbrechen](#deployment-cancel)
+ [auflisten](#deployment-list)
+ [Status](#deployment-status)
## create
Erstellen oder aktualisieren Sie eine lokale Bereitstellung mithilfe bestimmter Komponentenrezepte, Artefakte und Laufzeitargumente.
**Syntax**
```
greengrass-cli deployment create
--recipeDir path/to/component/recipe
[--artifactDir path/to/artifact/folder ]
[--update-config {component-configuration}]
[--groupId ]
[--merge "="]...
[--runWith ":posixUser=[:]"]...
[--systemLimits "{component-system-resource-limits}]"]...
[--remove ,...]
[--failure-handling-policy ]
```
**Argumente**
+ `--recipeDir`,`-r`. Der vollständige Pfad zu dem Ordner, der die Rezeptdateien der Komponenten enthält.
+ `--artifactDir`,`-a`. Der vollständige Pfad zu dem Ordner, der die Artefaktdateien enthält, die Sie in Ihre Bereitstellung aufnehmen möchten. Der Ordner artefacts muss die folgende Verzeichnisstruktur enthalten:
```
/path/to/artifact/folder///
```
+ `--update-config`,`-c`. Die Konfigurationsargumente für die Bereitstellung, bereitgestellt als JSON-Zeichenfolge oder JSON-Datei. Die JSON-Zeichenfolge sollte das folgende Format haben:
```
{ \
"componentName": { \
"MERGE": {"config-key": "config-value"}, \
"RESET": ["path/to/reset/"] \
} \
}
```
`MERGE`und `RESET` unterscheiden zwischen Groß- und Kleinschreibung und müssen in Großbuchstaben geschrieben werden.
+ `--groupId`,`-g`. Die Zielgruppe für den Einsatz.
+ `--merge`,`-m`. Der Name und die Version der Zielkomponente, die Sie hinzufügen oder aktualisieren möchten. Sie müssen die Komponenteninformationen im folgenden Format angeben`=`. Verwenden Sie für jede weitere Komponente, die Sie angeben möchten, ein separates Argument. Verwenden Sie bei Bedarf das `--runWith` Argument, um die `posixUser``posixGroup`, und `windowsUser` Informationen zum Ausführen der Komponente bereitzustellen.
+ `--runWith`. Die `posixUser``posixGroup`, und `windowsUser` Informationen zum Ausführen einer generischen Komponente oder einer Lambda-Komponente. Sie müssen diese Informationen im Format `:{posixUser|windowsUser}=[:<=posixGroup>]` angeben. Sie könnten beispielsweise **HelloWorld:posixUser=ggc\$1user:ggc\$1group** oder angeben**HelloWorld:windowsUser=ggc\$1user**. Verwenden Sie für jede weitere zu spezifizierende Option ein separates Argument.
Weitere Informationen finden Sie unter [Konfigurieren Sie den Benutzer, der die Komponenten ausführt](configure-greengrass-core-v2.md#configure-component-user).
+ `--systemLimits`. Die Systemressourcenlimits, die für Prozesse generischer und nicht containerisierter Lambda-Komponenten auf dem Kerngerät gelten sollen. Sie können die maximale CPU- und RAM-Auslastung konfigurieren, die die Prozesse der einzelnen Komponenten verwenden können. Geben Sie ein serialisiertes JSON-Objekt oder einen Dateipfad zu einer JSON-Datei an. Das JSON-Objekt muss das folgende Format haben.
```
{ \
"componentName": { \
"cpus": cpuTimeLimit, \
"memory": memoryLimitInKb \
} \
}
```
Sie können die folgenden Systemressourcenlimits für jede Komponente konfigurieren:
+ `cpus`— Die maximale Menge an CPU-Zeit, die die Prozesse dieser Komponente auf dem Kerngerät verwenden können. Die gesamte CPU-Zeit eines Core-Geräts entspricht der Anzahl der CPU-Kerne des Geräts. Auf einem Core-Gerät mit 4 CPU-Kernen können Sie diesen Wert beispielsweise auf festlegen, `2` um die Prozesse dieser Komponente auf 50 Prozent der Auslastung jedes CPU-Kerns zu beschränken. Auf einem Gerät mit einem CPU-Kern können Sie diesen Wert auf festlegen, `0.25` um die Prozesse dieser Komponente auf 25 Prozent der CPU-Auslastung zu beschränken. Wenn Sie diesen Wert auf eine Zahl festlegen, die größer als die Anzahl der CPU-Kerne ist, begrenzt die AWS IoT Greengrass Core-Software die CPU-Auslastung der Komponente nicht.
+ `memory`— Die maximale Menge an RAM (in Kilobyte), die die Prozesse dieser Komponente auf dem Kerngerät verwenden können.
Weitere Informationen finden Sie unter [Konfigurieren Sie die Systemressourcenlimits für Komponenten](configure-greengrass-core-v2.md#configure-component-system-resource-limits).
Diese Funktion ist für Version 2.4.0 und höher der [Greengrass Nucleus-Komponente und Greengrass](greengrass-nucleus-component.md) CLI auf Linux-Core-Geräten verfügbar. AWS IoT Greengrass unterstützt diese Funktion derzeit nicht auf Windows Core-Geräten.
+ `--remove`. Der Name der Zielkomponente, die Sie aus einer lokalen Bereitstellung entfernen möchten. Um eine Komponente zu entfernen, die aus einer Cloud-Bereitstellung zusammengeführt wurde, müssen Sie die Gruppen-ID der Ziel-Dinggruppe im folgenden Format angeben:
------
#### [ Greengrass nucleus v2.4.0 and later ]
```
--remove --groupId
```
------
#### [ Earlier than v2.4.0 ]
```
--remove --groupId thinggroup/
```
------
+ `--failure-handling-policy`. Definiert die Aktion, die ergriffen wird, wenn eine Bereitstellung fehlschlägt. Es gibt zwei Aktionen, die Sie angeben können:
+ `ROLLBACK` –
+ `DO_NOTHING` –
Diese Funktion ist für Version 2.11.0 und höher von verfügbar. [Grüngraskern](greengrass-nucleus-component.md)
**Ausgabe**
Das folgende Beispiel zeigt die Ausgabe, die erzeugt wird, wenn Sie diesen Befehl ausführen.
```
$ sudo greengrass-cli deployment create \
--merge MyApp1=1.0.0 \
--merge MyApp2=1.0.0 --runWith MyApp2:posixUser=ggc_user \
--remove MyApp3 \
--recipeDir recipes/ \
--artifactDir artifacts/
Local deployment has been submitted! Deployment Id: 44d89f46-1a29-4044-ad89-5151213dfcbc
```
## abbrechen
Bricht die angegebene Bereitstellung ab.
Syntax
```
greengrass-cli deployment cancel
-i
```
Argumente
`-i`. Die eindeutige Kennung der Bereitstellung, die abgebrochen werden soll. Die Bereitstellungs-ID wird in der Ausgabe des `create` Befehls zurückgegeben.
Output
+ Keine
## auflisten
Ruft den Status der letzten 10 lokalen Bereitstellungen ab.
**Syntax**
```
greengrass-cli deployment list
```
**Argumente**
Keine
**Ausgabe**
Das folgende Beispiel zeigt die Ausgabe, die bei der Ausführung dieses Befehls erzeugt wird. Je nach Status Ihrer Bereitstellung zeigt die Ausgabe einen der folgenden Statuswerte an:`IN_PROGRESS`,`SUCCEEDED`, oder`FAILED`.
```
$ sudo greengrass-cli deployment list
44d89f46-1a29-4044-ad89-5151213dfcbc: SUCCEEDED
Created on: 6/27/23 11:05 AM
```
## Status
Rufen Sie den Status einer bestimmten Bereitstellung ab.
**Syntax**
```
greengrass-cli deployment status -i
```
**Argumente**
`-i`. Die ID der Bereitstellung.
**Ausgabe**
Das folgende Beispiel zeigt die Ausgabe, die erzeugt wird, wenn Sie diesen Befehl ausführen. Je nach Status Ihrer Bereitstellung zeigt die Ausgabe einen der folgenden Statuswerte an:`IN_PROGRESS`,`SUCCEEDED`, oder`FAILED`.
```
$ sudo greengrass-cli deployment status -i 44d89f46-1a29-4044-ad89-5151213dfcbc
44d89f46-1a29-4044-ad89-5151213dfcbc: FAILED
Created on: 6/27/23 11:05 AM
Detailed Status:
Deployment Error Stack: List of error codes
Deployment Error Types: List of error types
Failure Cause: Cause
```
# Protokolle
Verwenden Sie den `logs` Befehl, um Greengrass-Protokolle auf Ihrem Kerngerät zu analysieren.
**Unterbefehle**
+ [get](#logs-get)
+ [Stichwörter auflisten](#logs-list-keywords)
+ [list-log-files](#logs-list-log-files)
## get
Sammeln, filtern und visualisieren Sie Greengrass-Protokolldateien. Dieser Befehl unterstützt nur Protokolldateien im JSON-Format. Sie können das [Logging-Format in der Nucleus-Konfiguration](greengrass-nucleus-component.md#greengrass-nucleus-component-configuration-logging-format) angeben.
**Syntax**
```
greengrass-cli logs get
[--log-dir path/to/a/log/folder]
[--log-file path/to/a/log/file]
[--follow true | false ]
[--filter ]
[--time-window , ]
[--verbose ]
[--no-color ]
[--before ]
[--after ]
[--syslog ]
[--max-long-queue-size ]
```
**Argumente**
+ `--log-dir`,`-ld`. Der Pfad zu dem Verzeichnis, in dem nach Protokolldateien gesucht werden soll, z. **`/greengrass/v2`/logs** B. Nicht mit verwenden`--syslog`. Verwenden Sie für jedes weitere Verzeichnis, das Sie angeben möchten, ein separates Argument. Sie müssen mindestens einen von `--log-dir` oder verwenden`--log-file`. Sie können auch beide Argumente in einem einzigen Befehl verwenden.
+ `--log-file`,`-lf`. Die Pfade zu den Protokollverzeichnissen, die Sie verwenden möchten. Verwenden Sie für jedes weitere Verzeichnis, das Sie angeben möchten, ein separates Argument. Sie müssen mindestens einen von `--log-dir` oder verwenden`--log-file`. Sie können auch beide Argumente in einem einzigen Befehl verwenden.
+ `--follow`,`-fol`. Zeigt Protokollaktualisierungen an, sobald sie auftreten. Greengrass CLI läuft weiter und liest aus den angegebenen Protokollen. Wenn Sie ein Zeitfenster angeben, stoppt Greengrass CLI die Überwachung der Protokolle, nachdem alle Zeitfenster abgelaufen sind.
+ `--filter`,`-f`. Das Schlüsselwort, die regulären Ausdrücke oder das Schlüssel-Wert-Paar, das als Filter verwendet werden soll. Geben Sie diesen Wert als Zeichenfolge, als regulären Ausdruck oder als Schlüssel-Wert-Paar an. Verwenden Sie für jeden weiteren Filter, den Sie angeben möchten, ein separates Argument.
Bei der Auswertung werden mehrere Filter, die in einem einzigen Argument angegeben sind, durch OR-Operatoren getrennt, und in zusätzlichen Argumenten angegebene Filter werden mit AND-Operatoren kombiniert. Wenn Ihr Befehl beispielsweise beinhaltet`--filter "installed" --filter "name=alpha,name=beta"`, filtert und zeigt Greengrass CLI Protokollnachrichten an, die sowohl das Schlüsselwort `installed` als auch einen `name` Schlüssel mit den Werten `alpha` oder `beta` enthalten.
+ `--time-window`,`-t`. Das Zeitfenster, für das Protokollinformationen angezeigt werden sollen. Sie können sowohl exakte Zeitstempel als auch relative Offsets verwenden. Sie müssen diese Informationen im folgenden Format angeben. `,` Wenn Sie weder die Startzeit noch die Endzeit angeben, wird als Wert für diese Option standardmäßig das aktuelle Systemdatum und die aktuelle Systemzeit verwendet. Verwenden Sie für jedes weitere Zeitfenster, das Sie angeben möchten, ein separates Argument.
Greengrass CLI unterstützt die folgenden Formate für Zeitstempel:
+ `yyyy-MM-DD`, zum Beispiel. `2020-06-30` Die Uhrzeit ist standardmäßig 00:00:00, wenn Sie dieses Format verwenden.
`yyyyMMDD`, zum Beispiel. `20200630` Die Uhrzeit ist standardmäßig 00:00:00, wenn Sie dieses Format verwenden.
`HH:mm:ss`, zum Beispiel. `15:30:45` Wenn Sie dieses Format verwenden, entspricht das Datum standardmäßig dem aktuellen Systemdatum.
`HH:mm:ssSSS`, zum Beispiel. `15:30:45` Das Datum ist standardmäßig das aktuelle Systemdatum, wenn Sie dieses Format verwenden.
`YYYY-MM-DD'T'HH:mm:ss'Z'`, zum Beispiel. `2020-06-30T15:30:45Z`
`YYYY-MM-DD'T'HH:mm:ss`, zum Beispiel`2020-06-30T15:30:45`.
`yyyy-MM-dd'T'HH:mm:ss.SSS`, zum Beispiel`2020-06-30T15:30:45.250`.
Relative Offsets geben einen Zeitraum an, der von der aktuellen Systemzeit abweicht. Greengrass CLI unterstützt das folgende Format für relative Offsets:. `+|-[h|hr|hours][valuem|min|minutes][value]s|sec|seconds`
Zum Beispiel das folgende Argument zur Angabe eines Zeitfensters zwischen 1 Stunde und 2 Stunden 15 Minuten vor der aktuellen Uhrzeit. `--time-window -2h15min,-1hr`
+ `--verbose`. Zeigt alle Felder aus den Protokollnachrichten an. Nicht mit verwenden`--syslog`.
+ `--no-color`,`-nc`. Entfernen Sie die Farbcodierung. Die Standardfarbcodierung für Protokollnachrichten verwendet fett gedruckten roten Text. Unterstützt nur UNIX-ähnliche Terminals, da ANSI-Escape-Sequenzen verwendet werden.
+ `--before``-b`,. Die Anzahl der Zeilen, die vor einem übereinstimmenden Protokolleintrag angezeigt werden sollen. Standard = 0.
+ `--after`,`-a`. Die Anzahl der Zeilen, die nach einem übereinstimmenden Protokolleintrag angezeigt werden sollen. Standard = 0.
+ `--syslog`. Verarbeitet alle Protokolldateien mit dem Syslog-Protokoll, das von definiert ist. RFC3164 Nicht zusammen mit `--log-dir` und verwenden. `--verbose` Das Syslog-Protokoll verwendet das folgende Format:. `"<$Priority>$Timestamp $Host $Logger ($Class): $Message"` Wenn Sie keine Protokolldatei angeben, liest Greengrass CLI Protokollnachrichten von den folgenden Speicherorten:`/var/log/messages`,`/var/log/syslog`, oder der`/var/log/system.log`.
AWS IoT Greengrass unterstützt diese Funktion derzeit nicht auf Windows Core-Geräten.
+ `--max-log-queue-size`,`-m`. Die maximale Anzahl von Protokolleinträgen, die dem Speicher zugewiesen werden sollen. Verwenden Sie diese Option, um die Speichernutzung zu optimieren. Die Standardeinstellung ist 100.
**Ausgabe**
Das folgende Beispiel zeigt die Ausgabe, die erzeugt wird, wenn Sie diesen Befehl ausführen.
```
$ sudo greengrass-cli logs get --verbose \
--log-file /greengrass/v2/logs/greengrass.log \
--filter deployment,serviceName=DeploymentService \
--filter level=INFO \
--time-window 2020-12-08T01:11:17,2020-12-08T01:11:22
2020-12-08T01:11:17.615Z [INFO] (pool-2-thread-14) com.aws.greengrass.deployment.DeploymentService: Current deployment finished. {DeploymentId=44d89f46-1a29-4044-ad89-5151213dfcbc, serviceName=DeploymentService, currentState=RUNNING}
2020-12-08T01:11:17.675Z [INFO] (pool-2-thread-14) com.aws.greengrass.deployment.IotJobsHelper: Updating status of persisted deployment. {Status=SUCCEEDED, StatusDetails={detailed-deployment-status=SUCCESSFUL}, ThingName=MyThing, JobId=22d89f46-1a29-4044-ad89-5151213dfcbc
```
## Stichwörter auflisten
Zeigt vorgeschlagene Stichwörter an, die Sie zum Filtern von Protokolldateien verwenden können.
**Syntax**
```
greengrass-cli logs list-keywords [arguments]
```
**Argumente**
Keine
**Ausgabe**
Die folgenden Beispiele zeigen die Ausgabe, die bei der Ausführung dieses Befehls erzeugt wird.
```
$ sudo greengrass-cli logs list-keywords
Here is a list of suggested keywords for Greengrass log:
level=$str
thread=$str
loggerName=$str
eventType=$str
serviceName=$str
error=$str
```
```
$ sudo greengrass-cli logs list-keywords --syslog
Here is a list of suggested keywords for syslog:
priority=$int
host=$str
logger=$str
class=$str
```
## list-log-files
Zeigt Protokolldateien an, die sich in einem angegebenen Verzeichnis befinden.
**Syntax**
```
greengrass-cli logs list-log-files [arguments]
```
**Argumente**
`--log-dir`,`-ld`. Der Pfad zu dem Verzeichnis, in dem nach Protokolldateien gesucht werden soll.
**Ausgabe**
Das folgende Beispiel zeigt die Ausgabe, die bei der Ausführung dieses Befehls erzeugt wird.
```
$ sudo greengrass-cli logs list-log-files -ld /greengrass/v2/logs/
/greengrass/v2/logs/aws.greengrass.Nucleus.log
/greengrass/v2/logs/main.log
/greengrass/v2/logs/greengrass.log
Total 3 files found.
```
# get-debug-password
Verwenden Sie den `get-debug-password` Befehl, um ein zufällig generiertes Passwort für die [lokale Debug-Konsolenkomponente () `aws.greengrass.LocalDebugConsole` auszugeben](local-debug-console-component.md). Das Passwort läuft 8 Stunden nach seiner Generierung ab.
**Syntax**
```
greengrass-cli get-debug-password
```
**Argumente**
Keine
**Ausgabe**
Das folgende Beispiel zeigt die Ausgabe, die bei der Ausführung dieses Befehls erzeugt wird.
```
$ sudo greengrass-cli get-debug-password
Username: debug
Password: bEDp3MOHdj8ou2w5de_sCBI2XAaguy3a8XxREXAMPLE
Password expires at: 2021-04-01T17:01:43.921999931-07:00
The local debug console is configured to use TLS security. The certificate is self-signed so you will need to bypass your web browser's security warnings to open the console.
Before you bypass the security warning, verify that the certificate fingerprint matches the following fingerprints.
SHA-256: 15 0B 2C E2 54 8B 22 DE 08 46 54 8A B1 2B 25 DE FB 02 7D 01 4E 4A 56 67 96 DA A6 CC B1 D2 C4 1B
SHA-1: BC 3E 16 04 D3 80 70 DA E0 47 25 F9 90 FA D6 02 80 3E B5 C1
```
# Verwenden Sie AWS IoT Greengrass Testing Framework
Das Greengrass Testing Framework (GTF) ist eine Sammlung von Bausteinen, die die end-to-end Automatisierung aus Kundensicht unterstützen. GTF verwendet [Cucumber als Feature-Treiber](https://cucumber.io). AWS IoT Greengrass verwendet dieselben Bausteine, um Softwareänderungen auf verschiedenen Geräten zu qualifizieren. Weitere Informationen finden Sie unter [Greengrass Testing Framework auf Github](https://github.com/aws-greengrass/aws-greengrass-testing/tree/dev_v1).
GTF wird mithilfe von Cucumber implementiert, einem Tool zur Durchführung automatisierter Tests, um eine verhaltensgesteuerte Entwicklung (BDD) der Komponenten zu fördern. In Cucumber werden die Funktionen dieses Systems in einem speziellen Dateityp namens beschrieben. `feature` Jede Funktion wird in einem für Menschen lesbaren Format beschrieben, das als Szenarien bezeichnet wird. Dabei handelt es sich um Spezifikationen, die in automatisierte Tests umgewandelt werden können. Jedes Szenario besteht aus einer Reihe von Schritten, die die Interaktionen und Ergebnisse des zu testenden Systems mithilfe einer domänenspezifischen Sprache namens Gherkin definieren. Ein [Gherkin-Schritt](https://cucumber.io/docs/gherkin/reference/#steps) ist mit dem Programmiercode verknüpft. Dabei wird eine Methode verwendet, die als Schrittdefinition bezeichnet wird und die Spezifikation fest mit dem Testablauf verknüpft. Schrittdefinitionen in GTF werden mit Java implementiert.
**Topics**
+ [Funktionsweise](#gg-testing-framework-how-gtf-works)
+ [Änderungsprotokoll](#gtf-changelog)
+ [Konfigurationsoptionen für das Greengrass Testing Framework](configuration-options-gtf.md)
+ [Tutorial: Führen Sie end-to-end Tests mit dem Greengrass Testing Framework und dem Greengrass Development Kit durch](run-e2e-tests-tutorial.md)
+ [Tutorial: Verwenden Sie einen Konfidenztest aus der Konfidenztestsuite](confidence-tests-tutorial.md)
## Funktionsweise
AWS IoT Greengrass verteilt das GTF als eigenständiges JAR, das aus mehreren Java-Modulen besteht. Um GTF zum end-to-end Testen von Komponenten zu verwenden, müssen Sie die Tests in einem Java-Projekt implementieren. Wenn Sie das Test-Standable-JAR als Abhängigkeit in Ihrem Java-Projekt hinzufügen, können Sie die bestehende Funktionalität der GTF nutzen und sie erweitern, indem Sie Ihre eigenen benutzerdefinierten Testfälle schreiben. Um die benutzerdefinierten Testfälle auszuführen, können Sie Ihr Java-Projekt erstellen und das Ziel-JAR mit den unter beschriebenen Konfigurationsoptionen ausführen. [Konfigurationsoptionen für das Greengrass Testing Framework](configuration-options-gtf.md)
### Eigenständiges GTF-JAR
Greengrass verwendet Cloudfront als [Maven-Repository](https://maven.apache.org/), um verschiedene Versionen des GTF-Standalone-JAR zu hosten. [Eine vollständige Liste der GTF-Versionen finden Sie unter GTF-Versionen.](https://github.com/aws-greengrass/aws-greengrass-testing/releases)
GTF Standalone JAR umfasst die folgenden Module. Es ist nicht nur auf diese Module beschränkt. Sie können jede dieser Abhängigkeiten separat in Ihrem Projekt auswählen oder sie alle gleichzeitig in die [eigenständige JAR-Testdatei](https://github.com/aws-greengrass/aws-greengrass-testing/tree/dev_v1/aws-greengrass-testing-standalone) aufnehmen.
+ `aws-greengrass-testing-resources`: Dieses Modul bietet Abstraktion für die Verwaltung des Lebenszyklus einer AWS Ressource während eines Tests. Sie können dies verwenden, um Ihre benutzerdefinierten AWS Ressourcen mithilfe von `ResourceSpec` Abstraktion zu definieren, sodass GTF die Erstellung und Entfernung dieser Ressourcen für Sie übernehmen kann.
+ `aws-greengrass-testing-platform`: Dieses Modul bietet Abstraktion auf Plattformebene für das zu testende Gerät während des Testlebenszyklus. Es APIs dient zur plattformunabhängigen Interaktion mit dem Betriebssystem und kann zur Simulation der Befehle verwendet werden, die in der Geräte-Shell ausgeführt werden.
+ `aws-greengrass-testing-components`: Dieses Modul besteht aus Beispielkomponenten, die zum Testen der Greengrass-Kernfunktionen wie Bereitstellungen, IPC und anderen Funktionen verwendet werden.
+ `aws-greengrass-testing-features`: Dieses Modul besteht aus wiederverwendbaren gemeinsamen Schritten und ihren Definitionen, die für Tests in der Greengrass-Umgebung verwendet werden.
**Topics**
+ [Funktionsweise](#gg-testing-framework-how-gtf-works)
+ [Änderungsprotokoll](#gtf-changelog)
+ [Konfigurationsoptionen für das Greengrass Testing Framework](configuration-options-gtf.md)
+ [Tutorial: Führen Sie end-to-end Tests mit dem Greengrass Testing Framework und dem Greengrass Development Kit durch](run-e2e-tests-tutorial.md)
+ [Tutorial: Verwenden Sie einen Konfidenztest aus der Konfidenztestsuite](confidence-tests-tutorial.md)
## Änderungsprotokoll
In der folgenden Tabelle werden die Änderungen in den einzelnen Versionen des GTF beschrieben. Weitere Informationen finden Sie auf der [Seite GTF-Veröffentlichungen](https://github.com/aws-greengrass/aws-greengrass-testing/releases) unter. GitHub
| **Version** | **Änderungen** |
| --- | --- |
| 1.2.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/greengrass/v2/developerguide/gg-testing-framework.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/greengrass/v2/developerguide/gg-testing-framework.html) |
| 1.1.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/greengrass/v2/developerguide/gg-testing-framework.html) |
| 1.0.0 | Erste Version |
# Konfigurationsoptionen für das Greengrass Testing Framework
## GTF-Konfigurationsoptionen
Greengrass Testing Framework (GTF) ermöglicht es Ihnen, während des Starts des end-to-end Testprozesses bestimmte Parameter zu konfigurieren, um den Testablauf zu orchestrieren. Sie können diese Konfigurationsoptionen als CLI-Argumente für das eigenständige GTF-JAR angeben.
GTF Version 1.1.0 und höher bietet die folgenden Konfigurationsoptionen.
+ `additional-plugins`— (Optional) Zusätzliche Cucumber-Plugins
+ `aws-region`— Zielt auf spezifische regionale Endpunkte für AWS Dienste ab. Standardmäßig wird das verwendet, was das AWS SDK entdeckt.
+ `credentials-path`— Optionaler Pfad für die AWS Profilanmeldedaten. Standardmäßig werden Anmeldeinformationen verwendet, die in der Host-Umgebung gefunden wurden.
+ `credentials-path-rotation`— Optionale Rotationsdauer für AWS Anmeldeinformationen. Der Standardwert ist 15 Minuten oder`PT15M`.
+ `csr-path`— Der Pfad für die CSR, mit der das Gerätezertifikat generiert wird.
+ `device-mode`— Das zu testende Zielgerät. Standardmäßig ist das lokale Gerät aktiviert.
+ `env-stage`— Zielt auf die Bereitstellungsumgebung von Greengrass ab. Standardmäßig ist die Produktion eingestellt.
+ `existing-device-cert-arn`— Der ARN eines vorhandenen Zertifikats, das Sie als Gerätezertifikat für Greengrass verwenden möchten.
+ `feature-path`— Datei oder Verzeichnis mit zusätzlichen Funktionsdateien. Standardmäßig werden keine zusätzlichen Featuredateien verwendet.
+ `gg-cli-version`— Überschreibt die Version der Greengrass-CLI. Standardmäßig wird der Wert verwendet, der in gefunden wurde. `ggc.version`
+ `gg-component-bucket`— Der Name eines vorhandenen Amazon S3 S3-Buckets, der Greengrass-Komponenten enthält.
+ `gg-component-overrides`— Eine Liste von Greengrass-Komponenten-Overrides.
+ `gg-persist`— Eine Liste von Testelementen, die nach einem Testlauf beibehalten werden sollen. Das Standardverhalten besteht darin, nichts beizubehalten. Zulässige Werte sind: `aws.resources``installed.software`, und`generated.files`.
+ `gg-runtime`— Eine Liste von Werten, die beeinflussen sollen, wie der Test mit den Testressourcen interagiert. Diese Werte haben Vorrang vor dem Parameter. `gg.persist` Wenn der Standardwert leer ist, wird davon ausgegangen, dass alle Testressourcen nach Testfällen verwaltet werden, einschließlich der installierten Greengrass-Runtime. Zulässige Werte sind: `aws.resources``installed.software`, und. `generated.files`
+ `ggc-archive`— Der Pfad zur archivierten Greengrass-Kernkomponente.
+ `ggc-install-root`— Verzeichnis zur Installation der Greengrass Nucleus-Komponente. Standardmäßig ist dies der Ordner test.temp.path und der Testrun-Ordner.
+ `ggc-log-level`— Stellen Sie den Greengrass Nucleus Log Level für den Testlauf ein. Die Standardeinstellung ist „INFO“.
+ `ggc-tes-rolename`— Die IAM-Rolle, die AWS IoT Greengrass Core für den Zugriff auf AWS Dienste übernehmen wird. Wenn eine Rolle mit dem angegebenen Namen nicht existiert, wird eine erstellt und es wird eine Standardzugriffsrichtlinie festgelegt.
+ `ggc-trusted-plugins`— Die durch Kommas getrennte Liste der Pfade (auf dem Host) der vertrauenswürdigen Plugins, die zu Greengrass hinzugefügt werden müssen. Um den Pfad auf dem DUT selbst anzugeben, stellen Sie dem Pfad „dut:“ voran
+ `ggc-user-name`— Der posixUser-Wert user:group für den Greengrass-Kern. Standardmäßig wird der aktuelle Benutzername verwendet, der angemeldet ist.
+ `ggc-version`— Überschreibt die Version der laufenden Greengrass Nucleus-Komponente. Standardmäßig wird der in ggc.archive gefundene Wert verwendet.
+ `log-level`— Protokollebene des Testlaufs. Der Standardwert ist „INFO“.
+ `parallel-config`— Satz von Batch-Index und Anzahl der Batches als JSON-Zeichenfolge. Der Standardwert des Batch-Index ist 0 und die Anzahl der Batches ist 1.
+ `proxy-url`— Konfigurieren Sie alle Tests so, dass der Verkehr über diese URL weitergeleitet wird.
+ `tags`— Führt nur Feature-Tags aus. Kann mit '&' überschnitten werden
+ `test-id-prefix`— Ein gemeinsames Präfix, das auf alle testspezifischen Ressourcen angewendet wird, einschließlich AWS Ressourcennamen und Tags. Die Standardeinstellung ist ein „gg“ -Präfix.
+ `test-log-path`— Verzeichnis, das die Ergebnisse des gesamten Testlaufs enthalten wird. Der Standardwert ist „TestResults“.
+ `test-results-json`— Markierung, um festzustellen, ob ein resultierender Cucumber-JSON-Bericht generiert und auf die Festplatte geschrieben wird. Standardwert ist „true“.
+ `test-results-log`— Markierung, um festzustellen, ob die Konsolenausgabe generiert und auf die Festplatte geschrieben wird. Standardwert "false".
+ `test-results-xml`— Markierung, um festzustellen, ob ein JUnit resultierender XML-Bericht generiert und auf die Festplatte geschrieben wird. Standardwert ist „true“.
+ `test-temp-path`— Verzeichnis zum Generieren lokaler Testartefakte. Standardmäßig wird ein zufälliges temporäres Verzeichnis mit dem Präfix gg-testing verwendet.
+ `timeout-multiplier`— Für alle Test-Timeouts wird ein Multiplikator bereitgestellt. Standard = 1.0.
# Tutorial: Führen Sie end-to-end Tests mit dem Greengrass Testing Framework und dem Greengrass Development Kit durch
AWS IoT Greengrass Testing Framework (GTF) und Greengrass Development Kit (GDK) bieten Entwicklern Möglichkeiten, Tests durchzuführen. end-to-end Sie können dieses Tutorial abschließen, um ein GDK-Projekt mit einer Komponente zu initialisieren, ein GDK-Projekt mit einem end-to-end Testmodul zu initialisieren und einen benutzerdefinierten Testfall zu erstellen. Nachdem Sie Ihren benutzerdefinierten Testfall erstellt haben, können Sie den Test ausführen.
In diesem Tutorial führen Sie folgende Aufgaben aus:
1. Initialisieren Sie ein GDK-Projekt mit einer Komponente.
1. Initialisieren Sie ein GDK-Projekt mit einem Testmodul. end-to-end
1. Erstellen Sie einen benutzerdefinierten Testfall.
1. Fügen Sie dem neuen Testfall ein Tag hinzu.
1. Erstellen Sie das Test-JAR.
1. Führen Sie den Test aus.
**Topics**
+ [Voraussetzungen](#run-e2e-tests-tutorial-prerequisites)
+ [Schritt 1: Initialisieren Sie ein GDK-Projekt mit einer Komponente](#init-gdk-with-component)
+ [Schritt 2: Initialisieren Sie ein GDK-Projekt mit einem Testmodul end-to-end](#init-gdk-with-e2e-test)
+ [Schritt 3: Erstellen Sie einen benutzerdefinierten Testfall](#run-e2e-tests-tutorial-instructions)
+ [Schritt 4: Fügen Sie dem neuen Testfall ein Tag hinzu](#add-tag-to-test-case)
+ [Schritt 5: Erstellen Sie das Test-JAR](#build-test-jar)
+ [Schritt 6: Führen Sie den Test aus](#run-test-gtf)
+ [Beispiel: Erstellen Sie einen benutzerdefinierten Testfall](#build-test-case-example)
## Voraussetzungen
Zum Durcharbeiten dieses Tutorials ist Folgendes erforderlich:
+ GDK Version 1.3.0 oder höher
+ Java
+ Maven
+ Git
## Schritt 1: Initialisieren Sie ein GDK-Projekt mit einer Komponente
+ Initialisieren Sie einen leeren Ordner mit einem GDK-Projekt. Laden Sie die in Python implementierte `HelloWorld` Komponente herunter, indem Sie den folgenden Befehl ausführen.
```
gdk component init -t HelloWorld -l python -n HelloWorld
```
Dieser Befehl erstellt ein neues Verzeichnis mit dem Namen `HelloWorld` im aktuellen Verzeichnis.
## Schritt 2: Initialisieren Sie ein GDK-Projekt mit einem Testmodul end-to-end
+ Mit GDK können Sie die Vorlage für das Testmodul herunterladen, die aus einer Funktion und einer schrittweisen Implementierung besteht. Führen Sie den folgenden Befehl aus, um das `HelloWorld` Verzeichnis zu öffnen und das vorhandene GDK-Projekt mithilfe eines Testmoduls zu initialisieren.
```
cd HelloWorld
gdk test-e2e init
```
Dieser Befehl erstellt ein neues Verzeichnis mit dem Namen `gg-e2e-tests` innerhalb des `HelloWorld` Verzeichnisses. Dieses Testverzeichnis ist ein [Maven-Projekt](https://maven.apache.org/), das von der eigenständigen Greengrass-Testing-JAR abhängig ist.
## Schritt 3: Erstellen Sie einen benutzerdefinierten Testfall
Das Schreiben eines benutzerdefinierten Testfalls besteht im Großen und Ganzen aus zwei Schritten: Erstellen Sie eine Feature-Datei mit einem Testszenario und implementieren Sie die Schrittdefinitionen. Ein Beispiel für die Erstellung eines benutzerdefinierten Testfalls finden Sie unter[Beispiel: Erstellen Sie einen benutzerdefinierten Testfall](#build-test-case-example). Gehen Sie wie folgt vor, um Ihren benutzerdefinierten Testfall zu erstellen:
1. Erstellen Sie eine Feature-Datei mit einem Testszenario
Ein Feature beschreibt in der Regel eine bestimmte Funktionalität der Software, die getestet wird. In Cucumber wird jedes Feature als einzelne Feature-Datei mit einem Titel, einer detaillierten Beschreibung und einem oder mehreren Beispielen für bestimmte Fälle, die als Szenarien bezeichnet werden, spezifiziert. Jedes Szenario besteht aus einem Titel, einer detaillierten Beschreibung und einer Reihe von Schritten, die die Interaktionen und erwarteten Ergebnisse definieren. Szenarien werden in einem strukturierten Format mit den Schlüsselwörtern „gegeben“, „wann“ und „dann“ geschrieben.
1. Implementieren Sie Schrittdefinitionen
Eine Schrittdefinition verknüpft den [Gherkin-Schritt im](https://cucumber.io/docs/gherkin/reference/#steps) Klartext mit dem Programmcode. Wenn Cucumber in einem Szenario einen Gherkin-Schritt identifiziert, sucht es nach einer passenden Schrittdefinition, die ausgeführt werden kann.
## Schritt 4: Fügen Sie dem neuen Testfall ein Tag hinzu
+ Sie können den Funktionen und Szenarien Tags zuweisen, um den Testprozess zu organisieren. Sie können Tags verwenden, um die Teilmengen von Szenarien zu kategorisieren und Hooks auch unter bestimmten Bedingungen auszuführen. Features und Szenarien können mehrere durch ein Leerzeichen getrennte Tags haben.
In diesem Beispiel verwenden wir die `HelloWorld` Komponente.
Fügen Sie in der Feature-Datei ein neues Tag mit dem Namen `@HelloWorld` neben dem `@Sample` Tag hinzu.
```
@Sample @HelloWorld
Scenario: As a developer, I can create a component and deploy it on my device
....
```
## Schritt 5: Erstellen Sie das Test-JAR
1. Erstellen Sie die Komponente. Sie müssen die Komponente erstellen, bevor Sie das Testmodul erstellen.
```
gdk component build
```
1. Erstellen Sie das Testmodul mit dem folgenden Befehl. Dieser Befehl erstellt die Test-JAR im `greengrass-build` Ordner.
```
gdk test-e2e build
```
## Schritt 6: Führen Sie den Test aus
Wenn Sie einen benutzerdefinierten Testfall ausführen, automatisiert GTF den Lebenszyklus des Tests sowie die Verwaltung der Ressourcen, die während des Tests erstellt wurden. Es stellt zunächst ein zu testendes Gerät (DUT) als AWS IoT Ding bereit und installiert die Greengrass-Kernsoftware darauf. Anschließend wird eine neue Komponente erstellt, die nach dem in diesem Pfad angegebenen Rezept benannt `HelloWorld` wird. Die `HelloWorld` Komponente wird dann über eine Greengrass-Dingbereitstellung auf dem Kerngerät bereitgestellt. Anschließend wird überprüft, ob die Bereitstellung erfolgreich ist. Der Bereitstellungsstatus wird `COMPLETED` innerhalb von 3 Minuten auf einen Wert geändert, wenn die Bereitstellung erfolgreich ist.
1. Gehen Sie zu der `gdk-config.json` Datei im Projektverzeichnis, um die Tests mit dem `HelloWorld` Tag als Ziel festzulegen. Aktualisieren Sie den `test-e2e` Schlüssel mit dem folgenden Befehl.
```
"test-e2e":{
"gtf_options" : {
"tags":"HelloWorld"
}
}
```
1. Bevor Sie die Tests ausführen, müssen Sie AWS Anmeldeinformationen für das Hostgerät angeben. GTF verwendet diese Anmeldeinformationen, um die AWS Ressourcen während des Testprozesses zu verwalten. Stellen Sie sicher, dass die von Ihnen angegebene Rolle über die erforderlichen Berechtigungen verfügt, um die im Test enthaltenen erforderlichen Vorgänge zu automatisieren.
Führen Sie die folgenden Befehle aus, um die AWS Anmeldeinformationen bereitzustellen.
1.
------
#### [ Linux or Unix ]
```
export AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
```
------
#### [ Windows Command Prompt (CMD) ]
```
set AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
set AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
```
------
#### [ PowerShell ]
```
$env:AWS_ACCESS_KEY_ID="AKIAIOSFODNN7EXAMPLE"
$env:AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
```
------
1. Führen Sie den Test mit dem folgenden Befehl aus.
```
gdk test-e2e run
```
Mit diesem Befehl wird die neueste Version von Greengrass Nucleus in den `greengrass-build` Ordner heruntergeladen und Tests damit ausgeführt. Dieser Befehl zielt auch nur auf die Szenarien ab, die mit dem `HelloWorld` Tag gekennzeichnet sind, und generiert einen Bericht für diese Szenarien. Sie werden sehen, dass die AWS Ressourcen, die während dieses Tests erstellt wurden, am Ende des Tests verworfen werden.
## Beispiel: Erstellen Sie einen benutzerdefinierten Testfall
**Example**
Das heruntergeladene Testmodul im GDK-Projekt besteht aus einer Beispielfunktion und einer Datei zur schrittweisen Implementierung.
Im folgenden Beispiel erstellen wir eine Feature-Datei zum Testen der Ding-Deployment-Funktion der Greengrass-Software. Wir testen die Funktionalität dieser Funktion teilweise mit einem Szenario, das die Bereitstellung einer Komponente über Greengrass AWS Cloud durchführt. Dies ist eine Reihe von Schritten, die uns helfen, die Interaktionen und die erwarteten Ergebnisse dieses Anwendungsfalls zu verstehen.
1.
**Erstellen Sie eine Feature-Datei**
Navigieren Sie zu dem `gg-e2e-tests/src/main/resources/greengrass/features` Ordner im aktuellen Verzeichnis. Sie können das Beispiel finden`component.feature`, das wie das folgende Beispiel aussieht.
In dieser Feature-Datei können Sie die Thing-Bereitstellungsfunktion der Greengrass-Software testen. Sie können die Funktionalität dieser Funktion teilweise mit einem Szenario testen, das eine Bereitstellung einer Komponente über die Greengrass-Cloud durchführt. Das Szenario besteht aus einer Reihe von Schritten, die dazu beitragen, die Interaktionen und die erwarteten Ergebnisse dieses Anwendungsfalls zu verstehen.
```
Feature: Testing features of Greengrassv2 component
Background:
Given my device is registered as a Thing
And my device is running Greengrass
@Sample
Scenario: As a developer, I can create a component and deploy it on my device
When I create a Greengrass deployment with components
HelloWorld | /path/to/recipe/file
And I deploy the Greengrass deployment configuration
Then the Greengrass deployment is COMPLETED on the device after 180 seconds
And I call my custom step
```
GTF enthält die Schrittdefinitionen aller folgenden Schritte, mit Ausnahme des genannten Schritts:`And I call my custom step`.
1.
**Implementieren Sie Schrittdefinitionen**
GTF Standalone JAR enthält die Schrittdefinitionen aller Schritte mit Ausnahme eines Schritts:`And I call my custom step`. Sie können diesen Schritt im Testmodul implementieren.
Navigieren Sie zum Quellcode der Testdatei. Sie können Ihren benutzerdefinierten Schritt mithilfe einer Schrittdefinition verknüpfen, indem Sie den folgenden Befehl verwenden.
```
@And("I call my custom step")
public void customStep() {
System.out.println("My custom step was called ");
}
```
# Tutorial: Verwenden Sie einen Konfidenztest aus der Konfidenztestsuite
AWS IoT Greengrass Testing Framework (GTF) und Greengrass Development Kit (GDK) bieten Entwicklern Möglichkeiten, Tests durchzuführen. end-to-end Sie können dieses Tutorial abschließen, um ein GDK-Projekt mit einer Komponente zu initialisieren, ein GDK-Projekt mit einem end-to-end Testmodul zu initialisieren und einen Konfidenztest aus der Confidence Test Suite zu verwenden. Nachdem Sie Ihren benutzerdefinierten Testfall erstellt haben, können Sie den Test ausführen.
Ein Konfidenztest ist ein generischer Test von Greengrass, der das Verhalten grundlegender Komponenten validiert. Diese Tests können modifiziert oder erweitert werden, um spezifischeren Anforderungen der Komponenten gerecht zu werden.
Für dieses Tutorial werden wir eine HelloWorld Komponente verwenden. Wenn Sie eine andere Komponente verwenden, ersetzen Sie die HelloWorld Komponente durch Ihre Komponente.
In diesem Tutorial führen Sie folgende Aufgaben aus:
1. Initialisieren Sie ein GDK-Projekt mit einer Komponente.
1. Initialisieren Sie ein GDK-Projekt mit einem Testmodul. end-to-end
1. Verwenden Sie einen Test aus der Confidence Test Suite.
1. Fügen Sie dem neuen Testfall ein Tag hinzu.
1. Erstellen Sie das Test-JAR.
1. Führen Sie den Test aus.
**Topics**
+ [Voraussetzungen](#confidence-tests-tutorial-prerequisites)
+ [Schritt 1: Initialisieren Sie ein GDK-Projekt mit einer Komponente](#init-gdk-with-component)
+ [Schritt 2: Initialisieren Sie ein GDK-Projekt mit einem Testmodul end-to-end](#init-gdk-with-e2e-test)
+ [Schritt 3: Verwenden Sie einen Test aus der Confidence Test Suite](#confidence-tests-tutorial-instructions)
+ [Schritt 4: Fügen Sie dem neuen Testfall ein Tag hinzu](#add-tag-to-test-case)
+ [Schritt 5: Erstellen Sie das Test-JAR](#build-test-jar)
+ [Schritt 6: Führen Sie den Test aus](#run-test-gtf)
+ [Beispiel: Verwenden Sie einen Konfidenztest](#build-confidence-test-case-example)
## Voraussetzungen
Zum Durcharbeiten dieses Tutorials ist Folgendes erforderlich:
+ GDK Version 1.6.0 oder höher
+ Java
+ Maven
+ Git
## Schritt 1: Initialisieren Sie ein GDK-Projekt mit einer Komponente
+ Initialisieren Sie einen leeren Ordner mit einem GDK-Projekt. Laden Sie die in Python implementierte `HelloWorld` Komponente herunter, indem Sie den folgenden Befehl ausführen.
```
gdk component init -t HelloWorld -l python -n HelloWorld
```
Dieser Befehl erstellt ein neues Verzeichnis mit dem Namen `HelloWorld` im aktuellen Verzeichnis.
## Schritt 2: Initialisieren Sie ein GDK-Projekt mit einem Testmodul end-to-end
+ Mit GDK können Sie die Vorlage für das Testmodul herunterladen, die aus einer Funktion und einer schrittweisen Implementierung besteht. Führen Sie den folgenden Befehl aus, um das `HelloWorld` Verzeichnis zu öffnen und das vorhandene GDK-Projekt mithilfe eines Testmoduls zu initialisieren.
```
cd HelloWorld
gdk test-e2e init
```
Dieser Befehl erstellt ein neues Verzeichnis mit dem Namen `gg-e2e-tests` innerhalb des `HelloWorld` Verzeichnisses. Dieses Testverzeichnis ist ein [Maven-Projekt](https://maven.apache.org/), das von der eigenständigen Greengrass-Testing-JAR abhängig ist.
## Schritt 3: Verwenden Sie einen Test aus der Confidence Test Suite
Das Schreiben eines Konfidenztestfalls besteht darin, die bereitgestellte Feature-Datei zu verwenden und, falls erforderlich, die Szenarien zu ändern. Ein Beispiel für die Verwendung eines Konfidenztests finden Sie unter[Beispiel: Erstellen Sie einen benutzerdefinierten Testfall](run-e2e-tests-tutorial.md#build-test-case-example). Gehen Sie wie folgt vor, um einen Konfidenztest zu verwenden:
+ Verwenden Sie die bereitgestellte Feature-Datei.
Navigieren Sie zum `gg-e2e-tests/src/main/resources/greengrass/features` Ordner im aktuellen Verzeichnis. Öffnen Sie die `confidenceTest.feature` Beispieldatei, um den Konfidenztest zu verwenden.
## Schritt 4: Fügen Sie dem neuen Testfall ein Tag hinzu
+ Sie können den Funktionen und Szenarien Tags zuweisen, um den Testprozess zu organisieren. Sie können Tags verwenden, um die Teilmengen von Szenarien zu kategorisieren und Hooks auch unter bestimmten Bedingungen auszuführen. Features und Szenarien können mehrere durch ein Leerzeichen getrennte Tags haben.
In diesem Beispiel verwenden wir die `HelloWorld` Komponente.
Jedes Szenario ist mit gekennzeichnet`@ConfidenceTest`. Ändern oder fügen Sie Tags hinzu, wenn Sie nur einen Teil der Testsuite ausführen möchten. Jedes Testszenario wird oben in jedem Konfidenztest beschrieben. Das Szenario besteht aus einer Reihe von Schritten, die dazu beitragen, die Interaktionen und erwarteten Ergebnisse der einzelnen Testfälle zu verstehen. Sie können diese Tests erweitern, indem Sie Ihre eigenen Schritte hinzufügen oder die vorhandenen ändern.
```
@ConfidenceTest
Scenario: As a Developer, I can deploy GDK_COMPONENT_NAME to my device and see it is working as expected
....
```
## Schritt 5: Erstellen Sie das Test-JAR
1. Erstellen Sie die Komponente. Sie müssen die Komponente erstellen, bevor Sie das Testmodul erstellen.
```
gdk component build
```
1. Erstellen Sie das Testmodul mit dem folgenden Befehl. Mit diesem Befehl wird das Test-JAR im `greengrass-build` Ordner erstellt.
```
gdk test-e2e build
```
## Schritt 6: Führen Sie den Test aus
Wenn Sie einen Konfidenztest durchführen, automatisiert der GTF den Lebenszyklus des Tests sowie die Verwaltung der Ressourcen, die während des Tests erstellt wurden. Es stellt zunächst ein zu testendes Gerät (DUT) als AWS IoT Ding bereit und installiert die Greengrass-Kernsoftware darauf. Anschließend wird eine neue Komponente erstellt, die nach dem in diesem Pfad angegebenen Rezept benannt `HelloWorld` wird. Die `HelloWorld` Komponente wird dann über eine Greengrass-Dingbereitstellung auf dem Kerngerät bereitgestellt. Anschließend wird überprüft, ob die Bereitstellung erfolgreich ist. Der Bereitstellungsstatus wird `COMPLETED` innerhalb von 3 Minuten auf einen Wert geändert, wenn die Bereitstellung erfolgreich ist.
1. Gehen Sie zu der `gdk-config.json` Datei im Projektverzeichnis, um die Tests mit dem `ConfidenceTest` Tag oder dem in Schritt 4 angegebenen Tag als Ziel festzulegen. Aktualisieren Sie den `test-e2e` Schlüssel mit dem folgenden Befehl.
```
"test-e2e":{
"gtf_options" : {
"tags":"ConfidenceTest"
}
}
```
1. Bevor Sie die Tests ausführen, müssen Sie AWS Anmeldeinformationen für das Hostgerät angeben. GTF verwendet diese Anmeldeinformationen, um die AWS Ressourcen während des Testprozesses zu verwalten. Stellen Sie sicher, dass die von Ihnen angegebene Rolle über die erforderlichen Berechtigungen verfügt, um die im Test enthaltenen erforderlichen Vorgänge zu automatisieren.
Führen Sie die folgenden Befehle aus, um die AWS Anmeldeinformationen bereitzustellen.
1.
------
#### [ Linux or Unix ]
```
export AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
```
------
#### [ Windows Command Prompt (CMD) ]
```
set AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
set AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
```
------
#### [ PowerShell ]
```
$env:AWS_ACCESS_KEY_ID="AKIAIOSFODNN7EXAMPLE"
$env:AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
```
------
1. Führen Sie den Test mit dem folgenden Befehl aus.
```
gdk test-e2e run
```
Mit diesem Befehl wird die neueste Version von Greengrass Nucleus in den `greengrass-build` Ordner heruntergeladen und Tests damit ausgeführt. Dieser Befehl zielt auch nur auf die Szenarien ab, die mit dem `ConfidenceTest` Tag gekennzeichnet sind, und generiert einen Bericht für diese Szenarien. Sie werden sehen, dass die AWS Ressourcen, die während dieses Tests erstellt wurden, am Ende des Tests verworfen werden.
## Beispiel: Verwenden Sie einen Konfidenztest
**Example**
Das heruntergeladene Testmodul im GDK-Projekt besteht aus einer bereitgestellten Feature-Datei.
Im folgenden Beispiel verwenden wir eine Feature-Datei, um die Ding-Deployment-Funktion der Greengrass-Software zu testen. Wir testen die Funktionalität dieser Funktion teilweise mit einem Szenario, das die Bereitstellung einer Komponente über Greengrass AWS Cloud durchführt. Dies ist eine Reihe von Schritten, die uns helfen, die Interaktionen und die erwarteten Ergebnisse dieses Anwendungsfalls zu verstehen.
+
**Verwenden Sie die bereitgestellte Feature-Datei.**
Navigieren Sie zu dem `gg-e2e-tests/src/main/resources/greengrass/features` Ordner im aktuellen Verzeichnis. Sie können das Beispiel finden`confidenceTest.feature`, das wie das folgende Beispiel aussieht.
```
Feature: Confidence Test Suite
Background:
Given my device is registered as a Thing
And my device is running Greengrass
@ConfidenceTest
Scenario: As a Developer, I can deploy GDK_COMPONENT_NAME to my device and see it is working as expected
When I create a Greengrass deployment with components
| GDK_COMPONENT_NAME | GDK_COMPONENT_RECIPE_FILE |
| aws.greengrass.Cli | LATEST |
And I deploy the Greengrass deployment configuration
Then the Greengrass deployment is COMPLETED on the device after 180 seconds
# Update component state accordingly. Possible states: {RUNNING, FINISHED, BROKEN, STOPPING}
And I verify the GDK_COMPONENT_NAME component is RUNNING using the greengrass-cli
```
Jedes Testszenario wird oben in jedem Konfidenztest beschrieben. Das Szenario besteht aus einer Reihe von Schritten, die dazu beitragen, die Interaktionen und erwarteten Ergebnisse der einzelnen Testfälle zu verstehen. Sie können diese Tests erweitern, indem Sie Ihre eigenen Schritte hinzufügen oder die vorhandenen ändern. Jedes der Szenarien enthält Kommentare, die Ihnen helfen, diese Anpassungen vorzunehmen.