Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# AWS IoT Greengrass strumenti di sviluppo
Usa gli strumenti di AWS IoT Greengrass sviluppo per creare, testare, creare, pubblicare e distribuire componenti Greengrass personalizzati.
+ **[CLI del kit di sviluppo Greengrass](greengrass-development-kit-cli.md)**
[Utilizzate l'interfaccia a riga di comando del AWS IoT Greengrass Development Kit (GDK CLI) nel vostro ambiente di sviluppo locale per creare componenti da modelli e componenti della community nel Greengrass Software Catalog.](greengrass-software-catalog.md) Puoi usare la CLI GDK per creare il componente e pubblicarlo nel servizio come componente privato AWS IoT Greengrass del tuo. Account AWS
+ **[Interfaccia a riga di comando Greengrass](gg-cli.md)**
Utilizza l'interfaccia a riga di comando Greengrass (Greengrass CLI) sui dispositivi principali Greengrass per distribuire ed eseguire il debug dei componenti Greengrass. La CLI di Greengrass è un componente che puoi distribuire sui tuoi dispositivi principali per creare distribuzioni locali, visualizzare dettagli sui componenti installati ed esplorare i file di registro.
+ **[Console di debug locale](local-debug-console-component.md)**
Utilizza la console di debug locale sui dispositivi principali Greengrass per distribuire ed eseguire il debug dei componenti Greengrass utilizzando un'interfaccia web del dashboard locale. La console di debug locale è un componente che puoi distribuire sui tuoi dispositivi principali per creare distribuzioni locali e visualizzare i dettagli sui componenti installati.
AWS IoT Greengrass fornisce anche quanto segue SDKs che è possibile utilizzare nei componenti Greengrass personalizzati:
+ Il SDK per dispositivi AWS IoT, che contiene la libreria di comunicazione tra processi (IPC). Per ulteriori informazioni, consulta [Usa il SDK per dispositivi AWS IoT per comunicare con il nucleo Greengrass, altri componenti e AWS IoT CoreComunica con il nucleo Greengrass, altri componenti e AWS IoT Core](interprocess-communication.md).
+ L'SDK Stream Manager, che è possibile utilizzare per trasferire flussi di dati verso. Cloud AWS Per ulteriori informazioni, consulta [Gestisci i flussi di dati sui dispositivi core Greengrass](manage-data-streams.md).
**Topics**
+ [AWS IoT Greengrass Interfaccia a riga di comando del Development Kit](greengrass-development-kit-cli.md)
+ [Interfaccia a riga di comando Greengrass](gg-cli.md)
+ [Usa AWS IoT Greengrass Testing Framework](gg-testing-framework.md)
# AWS IoT Greengrass Interfaccia a riga di comando del Development Kit
[L'interfaccia a riga di comando del AWS IoT Greengrass Development Kit (GDK CLI) fornisce funzionalità che aiutano a sviluppare componenti Greengrass personalizzati.](develop-greengrass-components.md) Puoi usare la CLI GDK per creare, creare e pubblicare componenti personalizzati. [Quando crei un repository di componenti con la CLI GDK, puoi iniziare da un modello o da un componente della community dal Greengrass Software Catalog.](greengrass-software-catalog.md) Quindi, puoi scegliere un sistema di compilazione che impacchetti i file come archivi ZIP, utilizzi uno script di compilazione Maven o Gradle o esegua un comando di compilazione personalizzato. Dopo aver creato un componente, puoi utilizzare la CLI di GDK per pubblicarlo sul servizio, in modo da poter utilizzare AWS IoT Greengrass la console o AWS IoT Greengrass l'API per distribuire il componente sui tuoi dispositivi principali Greengrass.
Quando sviluppate componenti Greengrass senza la CLI GDK, dovete aggiornare la versione e l' URIs artefatto nel file di [ricetta del componente](component-recipe-reference.md) ogni volta che create una nuova versione del componente. Quando usi la CLI di GDK, può aggiornare automaticamente la versione e l' URIs artefatto ogni volta che pubblichi una nuova versione del componente.
La CLI GDK è open source e disponibile su. GitHub Puoi personalizzare ed estendere la CLI GDK per soddisfare le tue esigenze di sviluppo dei componenti. Ti invitiamo ad aprire problemi e scaricare richieste dal repository. GitHub Puoi trovare il sorgente della CLI GDK al seguente link:. [https://github.com/aws-greengrass/aws-greengrass-gdk-cli](https://github.com/aws-greengrass/aws-greengrass-gdk-cli)
## Prerequisiti
Per installare e utilizzare la CLI del Greengrass Development Kit, è necessario quanto segue:
+ Un. Account AWS Se non lo hai, consultare [Configura un Account AWS](setting-up.md#set-up-aws-account).
+ Un computer di sviluppo simile a Windows, macOS o UNIX con una connessione Internet.
+ Per la versione 1.1.0 o successiva della CLI di GDK, [Python](https://www.python.org/downloads/) 3.6 o successiva installato sul computer di sviluppo.
Per la versione 1.0.0 della CLI di GDK[,](https://www.python.org/downloads/) Python 3.8 o successiva installata sul computer di sviluppo.
+ [Git](https://git-scm.com/) installato sul tuo computer di sviluppo.
+ AWS Command Line Interface (AWS CLI) installato e configurato con credenziali sul computer di sviluppo. *Per ulteriori informazioni, vedere [Installazione, aggiornamento e disinstallazione AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) e [configurazione di AWS CLI nella Guida per l'](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html)utente.AWS Command Line Interface *
**Nota**
Se utilizzi un Raspberry Pi o un altro dispositivo ARM a 32 bit, installa V1. AWS CLI AWS CLI La V2 non è disponibile per i dispositivi ARM a 32 bit. Per ulteriori informazioni, vedere [Installazione, aggiornamento e disinstallazione della AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv1.html) versione 1.
+ Per utilizzare la CLI GDK per pubblicare componenti sul servizio, AWS IoT Greengrass è necessario disporre delle seguenti autorizzazioni:
+ `s3:CreateBucket`
+ `s3:GetBucketLocation`
+ `s3:PutObject`
+ `greengrass:CreateComponentVersion`
+ `greengrass:ListComponentVersions`
+ Per utilizzare la CLI GDK per creare un componente i cui artefatti esistono in un bucket S3 e non nel file system locale, è necessario disporre delle seguenti autorizzazioni:
+ `s3:ListBucket`
Questa funzionalità è disponibile per GDK CLI v1.1.0 e versioni successive.
## Changelog
La tabella seguente descrive le modifiche in ogni versione della CLI GDK. Per ulteriori informazioni, consulta la pagina dei [rilasci della CLI di GDK](https://github.com/aws-greengrass/aws-greengrass-gdk-cli/releases) su. GitHub
| **Versione** | **Modifiche** |
| --- | --- |
| 1.6.2 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/greengrass/v2/developerguide/greengrass-development-kit-cli.html) |
| 1.6.1 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/greengrass/v2/developerguide/greengrass-development-kit-cli.html) |
| 1.6.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/greengrass/v2/developerguide/greengrass-development-kit-cli.html) |
| 1.5.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/greengrass/v2/developerguide/greengrass-development-kit-cli.html) |
| 1.4.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/greengrass/v2/developerguide/greengrass-development-kit-cli.html) |
| 1.3.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/greengrass/v2/developerguide/greengrass-development-kit-cli.html) |
| 1.2.3 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/greengrass/v2/developerguide/greengrass-development-kit-cli.html) |
| 1.2.2 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/greengrass/v2/developerguide/greengrass-development-kit-cli.html) |
| 1.2.1 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/greengrass/v2/developerguide/greengrass-development-kit-cli.html) |
| 1.2.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/greengrass/v2/developerguide/greengrass-development-kit-cli.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/greengrass/v2/developerguide/greengrass-development-kit-cli.html) |
| 1.1.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/greengrass/v2/developerguide/greengrass-development-kit-cli.html) |
| 1.0.0 | Versione iniziale. |
# Installare o aggiornare l'interfaccia a riga di comando del AWS IoT Greengrass Development Kit
L'interfaccia a riga di comando del AWS IoT Greengrass Development Kit (GDK CLI) è costruita su Python, quindi puoi `pip` usarla per installarla sul tuo computer di sviluppo.
**Suggerimento**
[Puoi anche installare la CLI GDK in ambienti virtuali Python come venv.](https://docs.python.org/3/library/venv.html#module-venv) Per ulteriori informazioni, consulta [Ambienti e pacchetti virtuali](https://docs.python.org/3/tutorial/venv.html) nella documentazione di *Python 3*.
**Per installare o aggiornare la CLI GDK**
1. [Esegui il comando seguente per installare l'ultima versione della CLI GDK dal GitHub suo repository.](https://github.com/aws-greengrass/aws-greengrass-gdk-cli)
```
python3 -m pip install -U git+https://github.com/aws-greengrass/aws-greengrass-gdk-cli.git@v1.6.2
```
**Nota**
Per installare una versione specifica della CLI GDK, *versionTag* sostituiscila con il tag di versione da installare. [Puoi visualizzare i tag di versione per la CLI di GDK nel GitHub suo repository.](https://github.com/aws-greengrass/aws-greengrass-gdk-cli/tags)
```
python3 -m pip install -U git+https://github.com/aws-greengrass/aws-greengrass-gdk-cli.git@versionTag
```
1. Esegui il comando seguente per verificare che la CLI GDK sia stata installata correttamente.
```
gdk --help
```
Se il `gdk` comando non viene trovato, aggiungi la sua cartella a PATH.
+ Sui dispositivi Linux, aggiungilo `/home/MyUser/.local/bin` a PATH e sostituiscilo *MyUser* con il nome dell'utente.
+ Sui dispositivi Windows, aggiungi `PythonPath\\Scripts` a PATH e sostituisci *PythonPath* con il percorso della cartella Python sul tuo dispositivo.
Ora puoi usare la CLI di GDK per creare, creare e pubblicare componenti Greengrass. Per ulteriori informazioni su come utilizzare la CLI di GDK, vedere. [AWS IoT Greengrass Comandi dell'interfaccia a riga di comando del Development Kit](greengrass-development-kit-cli-commands.md)
# AWS IoT Greengrass Comandi dell'interfaccia a riga di comando del Development Kit
L'interfaccia a riga di comando del AWS IoT Greengrass Development Kit (GDK CLI) fornisce un'interfaccia a riga di comando che puoi usare per creare, creare e pubblicare componenti Greengrass sul tuo computer di sviluppo. I comandi GDK CLI utilizzano il seguente formato.
```
gdk [arguments]
```
Quando [installi la CLI GDK](install-greengrass-development-kit-cli.md), il programma di installazione si `gdk` aggiunge al PATH in modo da poter eseguire la CLI GDK dalla riga di comando.
È possibile utilizzare i seguenti argomenti con qualsiasi comando:
+ Usa `-h` o `--help` per informazioni su un comando GDK CLI.
+ Usa `-v` o `--version` per vedere quale versione di GDK CLI è installata.
+ Usa `-d` o `--debug` per generare log dettagliati che puoi usare per eseguire il debug della CLI di GDK.
Questa sezione descrive i comandi GDK CLI e fornisce esempi per ogni comando. La sinossi di ogni comando mostra i relativi argomenti e il loro utilizzo. Gli argomenti opzionali sono indicati tra parentesi quadre.
**Topics**
+ [componente](greengrass-development-kit-cli-component.md)
+ [config](greengrass-development-kit-cli-config.md)
+ [test-e2e](greengrass-development-kit-cli-test.md)
# componente
Usa il `component` comando nell'interfaccia a riga di comando del AWS IoT Greengrass Development Kit (GDK CLI) per creare, creare e pubblicare componenti Greengrass personalizzati.
**Topics**
+ [init](#greengrass-development-kit-cli-component-init)
+ [build](#greengrass-development-kit-cli-component-build)
+ [pubblicazione](#greengrass-development-kit-cli-component-publish)
+ [elenco](#greengrass-development-kit-cli-component-list)
## init
Inizializza una cartella di componenti Greengrass da un modello di componente o da un componente della community.
[La CLI GDK recupera i componenti della community dal [Greengrass Software](greengrass-software-catalog.md) Catalog e i modelli di componenti dal AWS IoT Greengrass repository Component Templates in poi. GitHub](https://github.com/aws-greengrass/aws-greengrass-component-templates)
**Nota**
Se usi GDK CLI v1.0.0, devi eseguire questo comando in una cartella vuota. La CLI GDK scarica il modello o il componente della community nella cartella corrente.
Se utilizzi GDK CLI v1.1.0 o versione successiva, puoi specificare `--name` l'argomento per specificare la cartella in cui la CLI di GDK scarica il modello o il componente della community. Se usi questo argomento, specifica una cartella che non esiste. La CLI GDK crea la cartella per te. Se non specificate questo argomento, la CLI di GDK utilizza la cartella corrente, che deve essere vuota.
Se il componente utilizza il [sistema di compilazione zip](gdk-cli-configuration-file.md#gdk-cli-configuration-file-build-system), la CLI di GDK comprime determinati file nella cartella del componente in un file zip con lo stesso nome della cartella del componente. Ad esempio, se il nome della cartella del componente è`HelloWorld`, la CLI GDK crea un file zip denominato. `HelloWorld.zip` Nella ricetta del componente, il nome dell'artefatto zip deve corrispondere al nome della cartella del componente. Se si utilizza la versione 1.0.0 della CLI di GDK su un dispositivo Windows, i nomi delle cartelle dei componenti e dei file zip devono contenere solo lettere minuscole.
Se inizializzi un modello o un componente della community che utilizza il sistema di compilazione zip in una cartella con un nome diverso dal modello o dal componente, devi modificare il nome dell'artefatto zip nella ricetta del componente. Aggiorna le `Lifecycle` definizioni `Artifacts` and in modo che il nome del file zip corrisponda al nome della cartella del componente. L'esempio seguente evidenzia il nome del file zip nelle `Lifecycle` definizioni `Artifacts` and.
```
{
...
"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}"
```
**Riepilogo**
```
$ gdk component init
[--language]
[--template]
[--repository]
[--name]
```
**Argomenti (inizializzati dal modello del componente)**
+ `-l`, `--language` — Il linguaggio di programmazione da utilizzare per il modello specificato.
È necessario specificare `--repository` o `--language` e`--template`.
+ `-t`, `--template` — Il modello di componente da utilizzare per un progetto di componente locale. Per visualizzare i modelli disponibili, utilizzate il comando [list](#greengrass-development-kit-cli-component-list).
È necessario specificare `--repository` o `--language` e`--template`.
+ `-n`, `--name` — (Facoltativo) Il nome della cartella locale in cui la CLI di GDK inizializza il componente. Specificate una cartella che non esiste. La CLI GDK crea la cartella per te.
Questa funzionalità è disponibile per GDK CLI v1.1.0 e versioni successive.
**Argomenti (inizializzati dal componente della community)**
+ `-r`, `--repository` — Il componente della community da archiviare nella cartella locale. Per visualizzare i componenti della community disponibili, utilizzate il comando [list](#greengrass-development-kit-cli-component-list).
È necessario specificare `--repository` o `--language` e`--template`.
+ `-n`, `--name` — (Facoltativo) Il nome della cartella locale in cui la CLI di GDK inizializza il componente. Specificate una cartella che non esiste. La CLI GDK crea la cartella per te.
Questa funzionalità è disponibile per GDK CLI v1.1.0 e versioni successive.
**Output**
L'esempio seguente mostra l'output prodotto quando si esegue questo comando per inizializzare una cartella di componenti dal modello Python Hello World.
```
$ 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.
```
L'esempio seguente mostra l'output prodotto quando si esegue questo comando per inizializzare una cartella di componenti da un componente della comunità.
```
$ 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
Crea il codice sorgente di un componente in una ricetta e in artefatti da pubblicare sul servizio. AWS IoT Greengrass La CLI GDK esegue il sistema di compilazione specificato nel file di configurazione della [CLI di GDK](gdk-cli-configuration-file.md),. `gdk-config.json` È necessario eseguire questo comando nella stessa cartella in cui si trova il file. `gdk-config.json`
Quando esegui questo comando, la CLI GDK crea una ricetta e degli artefatti nella cartella `greengrass-build` della cartella dei componenti. La CLI GDK salva la ricetta nella cartella e salva `greengrass-build/recipes` gli artefatti nella cartella. `greengrass-build/artifacts/componentName/componentVersion`
Se utilizzi GDK CLI v1.1.0 o versione successiva, la ricetta del componente può specificare artefatti che esistono in un bucket S3 ma non nella cartella di build del componente locale. È possibile utilizzare questa funzionalità per ridurre l'utilizzo della larghezza di banda quando si sviluppano componenti con artefatti di grandi dimensioni, come i modelli di machine learning.
Dopo aver creato un componente, puoi eseguire una delle seguenti operazioni per testarlo su un dispositivo centrale Greengrass:
+ Se sviluppi su un dispositivo diverso da quello su cui esegui il software AWS IoT Greengrass Core, devi pubblicare il componente per distribuirlo su un dispositivo principale Greengrass. Pubblica il componente sul AWS IoT Greengrass servizio e distribuiscilo sul dispositivo principale Greengrass. Per ulteriori informazioni, vedete il comando [publish](#greengrass-development-kit-cli-component-build) e. [Creare distribuzione](create-deployments.md)
+ Se sviluppate sullo stesso dispositivo su cui eseguite il software AWS IoT Greengrass Core, potete pubblicare il componente sul AWS IoT Greengrass servizio da distribuire oppure potete creare una distribuzione locale per installare ed eseguire il componente. Per creare una distribuzione locale, usa la CLI di Greengrass. Per ulteriori informazioni, consulta [Interfaccia a riga di comando Greengrass](gg-cli.md) e [Testare AWS IoT Greengrass i componenti con distribuzioni locali](test-components.md). Quando crei la distribuzione locale, specifica `greengrass-build/recipes` come cartella recipes e `greengrass-build/artifacts` come cartella artifacts.
**Riepilogo**
```
$ gdk component build
```
**Arguments (Argomenti)**
Nessuno
**Output**
L'esempio seguente mostra l'output prodotto quando si esegue questo comando.
```
$ 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'.
```
## pubblicazione
Pubblica questo componente nel AWS IoT Greengrass servizio. Questo comando carica gli elementi della build in un bucket S3, aggiorna l'URI degli artefatti nella ricetta e crea una nuova versione del componente dalla ricetta. L'interfaccia a riga di comando di GDK utilizza il bucket S3 AWS e la regione specificati nel file di configurazione della CLI di [GDK](gdk-cli-configuration-file.md),. `gdk-config.json` È necessario eseguire questo comando nella stessa cartella in cui si trova il file. `gdk-config.json`
Se utilizzi GDK CLI v1.1.0 o versione successiva, puoi specificare `--bucket` l'argomento per specificare il bucket S3 in cui la CLI di GDK carica gli artefatti del componente. Se non specifichi questo argomento, la CLI di GDK viene caricata nel bucket S3 il cui nome `bucket-region-accountId` è, *bucket* dove *region* e sono i valori `gdk-config.json` in cui specifichi e rappresenta il tuo ID. *accountId* Account AWS La CLI GDK crea il bucket se non esiste.
Se si utilizza GDK CLI v1.2.0 o versione successiva, è possibile sovrascrivere Regione AWS quanto specificato nel file di configurazione della CLI di GDK utilizzando il parametro. `--region` È inoltre possibile specificare opzioni aggiuntive utilizzando il parametro. `--options` Per un elenco delle opzioni disponibili, vedere[File di configurazione CLI del Greengrass Development Kit](gdk-cli-configuration-file.md).
Quando esegui questo comando, la CLI di GDK pubblica il componente con la versione specificata nella ricetta. Se lo specifichi`NEXT_PATCH`, la CLI di GDK utilizza la versione della patch successiva che non esiste già. *Le versioni semantiche utilizzano una major.* *minore*. sistema di numerazione delle *patch*. Per ulteriori informazioni, consulta la specifica della [versione semantica](https://semver.org/).
**Nota**
Se usi GDK CLI v1.1.0 o versione successiva, quando esegui questo comando, la CLI di GDK verifica se il componente è stato creato. Se il componente non è stato creato, la [CLI di GDK crea il](#greengrass-development-kit-cli-component-build) componente prima di pubblicarlo.
**Riepilogo**
```
$ gdk component publish
[--bucket] [--region] [--options]
```
**Arguments (Argomenti)**
+ `-b`, `--bucket` — (Facoltativo) Specificate il nome del bucket S3 in cui la CLI di GDK pubblica gli artefatti dei componenti.
Se non specifichi questo argomento, la CLI di GDK viene caricata nel bucket S3 il cui nome `bucket-region-accountId` è, *bucket* dove *region* e sono i valori `gdk-config.json` in cui specifichi e rappresenta il tuo ID. *accountId* Account AWS La CLI GDK crea il bucket se non esiste.
La CLI GDK crea il bucket se non esiste.
Questa funzionalità è disponibile per GDK CLI v1.1.0 e versioni successive.
+ `-r`, `--region` — (Facoltativo) Specificate il nome del Regione AWS to al momento della creazione del componente. Questo argomento sovrascrive il nome della regione nella configurazione della CLI di GDK.
Questa funzionalità è disponibile per GDK CLI v1.2.0 e versioni successive.
+ `-o`, `--options` (Facoltativo) Specificate un elenco di opzioni per la pubblicazione di un componente. L'argomento deve essere una stringa JSON valida o un percorso di file a un file JSON contenente le opzioni di pubblicazione. Questo argomento sovrascrive le opzioni nella configurazione della CLI di GDK.
Questa funzionalità è disponibile per GDK CLI v1.2.0 e versioni successive.
**Output**
L'esempio seguente mostra l'output prodotto quando si esegue questo comando.
```
$ 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'.
```
## elenco
Recupera l'elenco dei modelli di componenti e dei componenti della community disponibili.
[La CLI GDK recupera i componenti della community dal [Greengrass Software](greengrass-software-catalog.md) Catalog e i modelli di componenti dal AWS IoT Greengrass repository Component Templates in poi. GitHub](https://github.com/aws-greengrass/aws-greengrass-component-templates)
È possibile passare l'output di questo comando al comando [init per inizializzare i repository](#greengrass-development-kit-cli-component-init) di componenti dai modelli e dai componenti della community.
**Riepilogo**
```
$ gdk component list
[--template]
[--repository]
```
**Arguments (Argomenti)**
+ `-t`, `--template` — (Facoltativo) Specificate questo argomento per elencare i modelli di componenti disponibili. Questo comando restituisce il nome e la lingua di ogni modello nel formato`name-language`. Ad esempio, in`HelloWorld-python`, il nome del modello è `HelloWorld` e la lingua è`python`.
+ `-r`, `--repository` — (Facoltativo) Specificate questo argomento per elencare gli archivi di componenti della community disponibili.
**Output**
L'esempio seguente mostra l'output prodotto quando si esegue questo comando.
```
$ 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
Usa il `config` comando nell'interfaccia a riga di comando del AWS IoT Greengrass Development Kit (GDK CLI) per modificare la configurazione per il GDK nel file di configurazione,. `gdk-config.json`
**Topics**
+ [aggiorna](#greengrass-development-kit-cli-config-update)
## aggiorna
Avvia un prompt interattivo per modificare i campi all'interno di un file di configurazione GDK esistente.
**Riepilogo**
```
$ gdk config update
[--component]
```
**Arguments (Argomenti)**
+ `-c`, `--component` — Per aggiornare i campi relativi ai componenti nel file. `gdk-config.json` Questo argomento è obbligatorio in quanto è l'unica opzione.
**Output**
L'esempio seguente mostra l'output prodotto quando si esegue questo comando per configurare un componente.
```
$ 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
Usa il `test-e2e` comando nell'interfaccia a riga di comando del AWS IoT Greengrass Development Kit (GDK CLI) per inizializzare, creare ed end-to-end eseguire moduli di test nel progetto GDK.
**Topics**
+ [init](#greengrass-development-kit-cli-test-init)
+ [build](#greengrass-development-kit-cli-test-build)
+ [run](#greengrass-development-kit-cli-test-run)
## init
Inizializza un progetto GDK CLI esistente con un modulo di test che utilizza Greengrass Testing Framework (GTF).
[Per impostazione predefinita, la CLI GDK recupera il modello del modulo Maven dal AWS IoT Greengrass repository Component Templates in poi. GitHub](https://github.com/aws-greengrass/aws-greengrass-component-templates) Questo modulo Maven ha una dipendenza dal file JAR. `aws-greengrass-testing-standalone`
Questo comando crea una nuova directory chiamata `gg-e2e-tests` all'interno del progetto GDK. Se la directory del modulo di test esiste già e non è vuota, il comando esce senza fare nulla. Questa `gg-e2e-tests` cartella contiene la funzionalità Cucumber e le definizioni dei passaggi strutturate in un progetto Maven.
Per impostazione predefinita, questo comando proverà a utilizzare l'ultima versione di GTF.
**Riepilogo**
```
$ gdk test-e2e init
[--gtf-version]
```
**Arguments (Argomenti)**
+ `-ov`, `--gtf-version` — (Facoltativo) La versione di GTF da usare con il modulo di end-to-end test nel progetto GDK. [Questo valore deve essere una delle versioni GTF delle release.](https://github.com/aws-greengrass/aws-greengrass-testing/releases) Questo argomento ha la precedenza sulla configurazione della `gtf_version` CLI di GDK.
**Output**
L'esempio seguente mostra l'output prodotto quando si esegue questo comando per inizializzare il progetto GDK con il modulo di test.
```
$ 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
**Nota**
È necessario creare il componente eseguendolo **gdk component build** prima di creare il modulo di end-to-end test.
Crea il modulo end-to-end di test. La CLI GDK crea il modulo di test utilizzando il sistema di compilazione specificato nel file di [configurazione della CLI GDK](gdk-cli-configuration-file.md), sotto la proprietà. `gdk-config.json` `test-e2e` È necessario eseguire questo comando nella stessa cartella in cui si trova il file. `gdk-config.json`
Per impostazione predefinita, la CLI GDK utilizza il sistema di compilazione maven per creare il modulo di test. [Maven](https://maven.apache.org/) è necessario per eseguire il comando. `gdk test-e2e build`
È necessario creare il componente eseguendolo **gdk-component-build** prima di creare il modulo di test, se i file delle funzionalità di test hanno variabili simili `GDK_COMPONENT_RECIPE_FILE` a `GDK_COMPONENT_NAME` e da interpolare.
Quando esegui questo comando, la CLI GDK interpola tutte le variabili dalla configurazione del progetto GDK e crea il modulo per generare il file JAR di `gg-e2e-tests` test finale.
**Riepilogo**
```
$ gdk test-e2e build
```
**Arguments (Argomenti)**
Nessuno
**Output**
L'esempio seguente mostra l'output prodotto quando si esegue questo comando.
```
$ 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
Esegui il modulo di test con le opzioni di test nel file di configurazione GDK.
**Nota**
È necessario creare il modulo di test eseguendolo **gdk test-e2e build** prima di eseguire i end-to-end test.
**Riepilogo**
```
$ gdk test-e2e run
[--gtf-options]
```
**Arguments (Argomenti)**
+ `-oo`, `--gtf-options` — (Facoltativo) Specificate un elenco di opzioni per l'esecuzione end-to-end dei test. L'argomento deve essere una stringa JSON valida o un percorso di file a un file JSON contenente le opzioni GTF. Le opzioni fornite nel file di configurazione vengono unite a quelle fornite negli argomenti del comando. Se un'opzione è presente in entrambi i posti, quella contenuta nell'argomento ha la precedenza su quella del file di configurazione.
Se l'`tags`opzione non è specificata in questo comando, GDK la usa per i tag. `Sample` Se non `ggc-archive` è specificato, GDK scarica l'ultima versione dell'archivio Greengrass nucleus.
**Output**
L'esempio seguente mostra l'output prodotto quando si esegue questo comando.
```
$ 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
.......
```
# File di configurazione CLI del Greengrass Development Kit
L'interfaccia a riga di comando del AWS IoT Greengrass Development Kit (GDK CLI) legge da un file di configurazione `gdk-config.json` denominato per creare e pubblicare componenti. Questo file di configurazione deve essere presente nella radice del repository dei componenti. Puoi usare il comando [init della CLI GDK per inizializzare i](greengrass-development-kit-cli-component.md#greengrass-development-kit-cli-component-init) repository dei componenti con questo file di configurazione.
**Topics**
+ [Formato del file di configurazione GDK CLI](#gdk-config-format)
+ [Esempi di file di configurazione della CLI GDK](#gdk-config-examples)
## Formato del file di configurazione GDK CLI
Quando definisci un file di configurazione GDK CLI per un componente, specifichi le seguenti informazioni in formato JSON.
`gdk_version`
La versione minima della CLI GDK compatibile con questo componente. [Questo valore deve essere una delle versioni della CLI di GDK delle release.](https://github.com/aws-greengrass/aws-greengrass-gdk-cli/releases)
`component`
La configurazione per questo componente.
`componentName`
`author`
L'autore o l'editore del componente.
`version`
La versione del componente. Specifica una delle seguenti proprietà:
+ `NEXT_PATCH`— Quando scegliete questa opzione, la CLI di GDK imposta la versione quando pubblicate il componente. La CLI GDK interroga AWS IoT Greengrass il servizio per identificare l'ultima versione pubblicata del componente. Quindi, imposta la versione alla versione della patch successiva a quella versione. Se non hai mai pubblicato il componente prima, la CLI di GDK utilizza la versione. `1.0.0`
Se scegli questa opzione, non puoi utilizzare la [CLI di Greengrass](greengrass-cli-component.md) per distribuire e testare localmente il componente sul tuo computer di sviluppo locale che esegue il software Core. AWS IoT Greengrass Per abilitare le distribuzioni locali, devi invece specificare una versione semantica.
+ Una versione semantica, ad esempio. **1.0.0** *Le versioni semantiche utilizzano un major.* *minore*. sistema di numerazione delle *patch*. Per ulteriori informazioni, consulta la specifica della [versione semantica](https://semver.org/).
Se sviluppate componenti su un dispositivo Greengrass core su cui desiderate distribuire e testare il componente, scegliete questa opzione. [È necessario creare il componente con una versione specifica per creare distribuzioni locali con la Greengrass CLI.](greengrass-cli-component.md)
`build`
La configurazione da utilizzare per creare il codice sorgente di questo componente in artefatti. Questo oggetto contiene le seguenti informazioni:
`build_system`
Il sistema di compilazione da utilizzare. Seleziona una delle opzioni seguenti:
+ `zip`— Impacchetta la cartella del componente in un file ZIP da definire come unico elemento del componente. Scegliete questa opzione per i seguenti tipi di componenti:
+ Componenti che utilizzano linguaggi di programmazione interpretati, come Python o. JavaScript
+ Componenti che impacchettano file diversi dal codice, come modelli di apprendimento automatico o altre risorse.
La CLI GDK comprime la cartella del componente in un file zip con lo stesso nome della cartella del componente. Ad esempio, se il nome della cartella del componente è`HelloWorld`, la CLI GDK crea un file zip denominato. `HelloWorld.zip`
**Nota**
Se si utilizza la versione 1.0.0 della CLI di GDK su un dispositivo Windows, i nomi delle cartelle dei componenti e dei file zip devono contenere solo lettere minuscole.
Quando la CLI di GDK comprime la cartella del componente in un file zip, salta i seguenti file:
+ Il file `gdk-config.json`
+ Il file della ricetta (o) `recipe.json` `recipe.yaml`
+ Crea cartelle, ad esempio `greengrass-build`
+ `maven`— Esegue il `mvn clean package` comando per creare il codice sorgente del componente in artefatti. Scegli questa opzione per i componenti che utilizzano [Maven](https://maven.apache.org/), come i componenti Java.
Sui dispositivi Windows, questa funzionalità è disponibile per GDK CLI v1.1.0 e versioni successive.
+ `gradle`— Esegue il `gradle build` comando per creare il codice sorgente del componente in artefatti. [Scegliete questa opzione per i componenti che utilizzano Gradle.](https://gradle.org/) Questa funzionalità è disponibile per GDK CLI v1.1.0 e versioni successive.
Il sistema di `gradle` build supporta Kotlin DSL come file di build. Questa funzionalità è disponibile per GDK CLI v1.2.0 e versioni successive.
+ `gradlew`— Esegue il `gradlew` comando per creare il codice sorgente del componente in artefatti. Scegliete questa opzione per i componenti che utilizzano il [Gradle](https://docs.gradle.org/current/userguide/gradle_wrapper.html) Wrapper.
Questa funzionalità è disponibile per GDK CLI v1.2.0 e versioni successive.
+ `custom`— Esegue un comando personalizzato per creare il codice sorgente del componente in una ricetta e in artefatti. Specificate il comando personalizzato nel `custom_build_command` parametro.
`custom_build_command`
(Facoltativo) Il comando custom build da eseguire per un sistema di build personalizzato. È necessario specificare questo parametro se si specifica `custom` per`build_system`.
Questo comando deve creare una ricetta e degli artefatti nelle seguenti cartelle all'interno della cartella del componente. La CLI GDK crea queste cartelle per te quando esegui [il comando component build](greengrass-development-kit-cli-component.md#greengrass-development-kit-cli-component-build).
+ Cartella delle ricette: `greengrass-build/recipes`
+ Cartella Artifacts: `greengrass-build/artifacts/componentName/componentVersion`
Sostituisci *componentName* con il nome del componente e sostituisci *componentVersion* con la versione del componente o. `NEXT_PATCH`
È possibile specificare una singola stringa o un elenco di stringhe, in cui ogni stringa è una parola del comando. Ad esempio, per eseguire un comando di compilazione personalizzato per un componente C\$1\$1, puoi specificare **cmake --build build --config Release** o. **["cmake", "--build", "build", "--config", "Release"]**
Per visualizzare un esempio di sistema di compilazione personalizzato, consulta il [aws.greengrass.labs.LocalWebServer community component su GitHub](https://github.com/awslabs/aws-greengrass-labs-local-web-server).
`options`
(Facoltativo) Opzioni di configurazione aggiuntive utilizzate durante il processo di creazione del componente.
Questa funzionalità è disponibile per GDK CLI v1.2.0 e versioni successive.
`excludes`
Un elenco di pattern a glob che definiscono quali file escludere dalla directory dei componenti durante la creazione del file zip. Valido solo quando `build_system` è`zip`.
Nelle versioni 1.4.0 e precedenti della CLI di GDK, qualsiasi file che corrisponde a una voce nell'elenco delle esclusioni viene escluso da tutte le sottodirectory del componente. Per ottenere lo stesso comportamento nelle versioni 1.5.0 e successive della CLI di GDK, `**/` anteponi le voci esistenti nell'elenco delle esclusioni. Ad esempio, `*.txt` escluderà i file di testo solo dalla directory; `**/*.txt` escluderà i file di testo da tutte le directory e sottodirectory.
Nelle versioni 1.5.0 e successive della CLI di GDK, potresti visualizzare un avviso durante la compilazione del componente `excludes` quando è definito nel file di configurazione GDK. Per disabilitare questo avviso, imposta la variabile di ambiente su. `GDK_EXCLUDES_WARN_IGNORE` `true`
La CLI GDK esclude sempre i seguenti file dal file zip:
+ Il file `gdk-config.json`
+ Il file della ricetta (o) `recipe.json` `recipe.yaml`
+ Crea cartelle, ad esempio `greengrass-build`
I seguenti file sono esclusi per impostazione predefinita. Tuttavia, puoi controllare quali di questi file sono esclusi con l'`excludes`opzione.
+ Qualsiasi cartella che inizia con il prefisso «test» () `test*`
+ Tutti i file nascosti
+ La cartella `node_modules`
Se specificate l'`excludes`opzione, la CLI di GDK esclude solo i file impostati con l'opzione. `excludes` Se non specificate l'`excludes`opzione, la CLI di GDK esclude i file e le cartelle predefiniti precedentemente indicati.
`zip_name`
Il nome del file zip da usare quando si crea un elemento zip durante il processo di compilazione. Valido solo quando è. `build_system` `zip` Se `build_system` è vuoto, il nome del componente viene utilizzato per il nome del file zip.
`publish`
La configurazione da utilizzare per pubblicare questo componente nel AWS IoT Greengrass servizio.
Se utilizzi GDK CLI v1.1.0 o versione successiva, puoi specificare `--bucket` l'argomento per specificare il bucket S3 in cui la CLI di GDK carica gli artefatti del componente. Se non specifichi questo argomento, la CLI di GDK viene caricata nel bucket S3 il cui nome `bucket-region-accountId` è, *bucket* dove *region* e sono i valori `gdk-config.json` in cui specifichi e rappresenta il tuo ID. *accountId* Account AWS La CLI GDK crea il bucket se non esiste.
Questo oggetto contiene le seguenti informazioni:
`bucket`
Il nome del bucket S3 da usare per ospitare gli artefatti dei componenti.
`region`
Il Regione AWS punto in cui la CLI di GDK pubblica questo componente.
Questa proprietà è facoltativa se si utilizza GDK CLI v1.3.0 o versione successiva.
`options`
(Facoltativo) Opzioni di configurazione aggiuntive utilizzate durante la creazione della versione del componente.
Questa funzionalità è disponibile per GDK CLI v1.2.0 e versioni successive.
`file_upload_args`
Una struttura JSON contenente argomenti inviati ad Amazon S3 durante il caricamento di file in un bucket, come metadati e meccanismi di crittografia. *Per un elenco degli argomenti consentiti, consulta la [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)classe nella documentazione di Boto3.* .
`test-e2e`
(Facoltativo) La configurazione da utilizzare durante il end-to-end test del componente. Questa funzionalità è disponibile per GDK CLI v1.3.0 e versioni successive.
`build`
`build_system`— Il sistema di compilazione da utilizzare. L'opzione predefinita è`maven`. Seleziona una delle opzioni seguenti:
+ `maven`— Esegue il `mvn package` comando per creare il modulo di test. Scegli questa opzione per creare il modulo di test che utilizza [Maven](https://maven.apache.org/).
+ `gradle`— Esegue il `gradle build` comando per creare il modulo di test. Scegliete questa opzione per il modulo di test che utilizza [Gradle.](https://gradle.org/)
`gtf_version`
(Facoltativo) La versione del Greengrass Testing Framework (GTF) da usare come dipendenza del modulo di end-to-end test quando inizializzi il progetto GDK con GTF. [Questo valore deve essere una delle versioni GTF delle release.](https://github.com/aws-greengrass/aws-greengrass-testing/releases) L'impostazione predefinita è GTF versione 1.1.0.
`gtf_options`
(Facoltativo) Opzioni di configurazione aggiuntive utilizzate durante il end-to-end test del componente.
L'elenco seguente include le opzioni che è possibile utilizzare con la versione 1.1.0 di GTF.
+ `additional-plugins`— (Opzionale) Plugin aggiuntivi per Cucumber
+ `aws-region`— Si rivolge a endpoint regionali specifici per i servizi. AWS L'impostazione predefinita è ciò che rileva l' AWS SDK.
+ `credentials-path`— Percorso opzionale AWS delle credenziali del profilo. L'impostazione predefinita sono le credenziali rilevate nell'ambiente host.
+ `credentials-path-rotation`— Durata di rotazione opzionale per le credenziali. AWS Il valore predefinito è 15 minuti o. `PT15M`
+ `csr-path`— Il percorso della CSR con cui verrà generato il certificato del dispositivo.
+ `device-mode`— Il dispositivo bersaglio sottoposto a test. L'impostazione predefinita è il dispositivo locale.
+ `env-stage`— Si rivolge all'ambiente di implementazione di Greengrass. L'impostazione predefinita è la produzione.
+ `existing-device-cert-arn`— L'arn di un certificato esistente che desideri utilizzare come certificato del dispositivo per Greengrass.
+ `feature-path`— File o directory contenente file di funzionalità aggiuntivi. L'impostazione predefinita è che non vengono utilizzati file di feature aggiuntivi.
+ `gg-cli-version`— Sostituisce la versione della CLI di Greengrass. Il valore predefinito è il valore trovato in. `ggc.version`
+ `gg-component-bucket`— Il nome di un bucket Amazon S3 esistente che contiene componenti Greengrass.
+ `gg-component-overrides`— Un elenco di componenti sostituiti da Greengrass.
+ `gg-persist`— Un elenco di elementi di test che devono persistere dopo l'esecuzione di un test. Il comportamento predefinito consiste nel non rendere persistente nulla. I valori accettati sono: `aws.resources``installed.software`, e`generated.files`.
+ `gg-runtime`— Un elenco di valori per influenzare il modo in cui il test interagisce con le risorse di test. Questi valori sostituiscono il parametro. `gg.persist` Se l'impostazione predefinita è vuota, presuppone che tutte le risorse di test siano gestite per test case, incluso il runtime Greengrass installato. I valori accettati sono:`aws.resources`, e`installed.software`. `generated.files`
+ `ggc-archive`— Il percorso verso il componente Greengrass nucleus archiviato.
+ `ggc-install-root`— Directory per installare il componente Greengrass nucleus. I valori predefiniti sono test.temp.path e test run.
+ `ggc-log-level`— Imposta il livello di registro del nucleo di Greengrass per l'esecuzione del test. L'impostazione predefinita è «INFO».
+ `ggc-tes-rolename`— Il ruolo IAM che AWS IoT Greengrass Core assumerà per accedere ai AWS servizi. Se non esiste un ruolo con un nome specifico, ne verrà creato uno e una politica di accesso predefinita.
+ `ggc-trusted-plugins`— L'elenco separato da virgole dei percorsi (sull'host) dei plugin affidabili che devono essere aggiunti a Greengrass. Per fornire il percorso sul DUT stesso, inserisci il prefisso 'dut: '
+ `ggc-user-name`— Il valore PosixUser user:group per il nucleo Greengrass. Il valore predefinito è il nome utente corrente a cui è stato effettuato l'accesso.
+ `ggc-version`— Sostituisce la versione del componente Greengrass nucleus in esecuzione. Il valore predefinito è il valore trovato in ggc.archive.
+ `log-level`— Livello di registro dell'esecuzione del test. Il valore predefinito è «INFO».
+ `parallel-config`— Set di indice di batch e numero di batch come stringa JSON. Il valore predefinito dell'indice batch è 0 e il numero di batch è 1.
+ `proxy-url`— Configura tutti i test per indirizzare il traffico attraverso questo URL.
+ `tags`— Esegui solo tag di funzionalità. Può essere intersecato con '&'
+ `test-id-prefix`— Un prefisso comune applicato a tutte le risorse specifiche del test, inclusi i nomi e i tag AWS delle risorse. L'impostazione predefinita è il prefisso «gg».
+ `test-log-path`— Directory che conterrà i risultati dell'intera esecuzione del test. Il valore predefinito è «testResults».
+ `test-results-json`— Contrassegno per determinare se viene generato un report Cucumber JSON risultante scritto su disco. Il valore predefinito è true.
+ `test-results-log`— Contrassegno per determinare se l'output della console viene generato scritto su disco. Il valore predefinito è false (falso).
+ `test-results-xml`— Contrassegno per determinare se viene generato un report JUnit XML risultante scritto su disco. Il valore predefinito è true.
+ `test-temp-path`— Directory per generare artefatti di test locali. Il valore predefinito è una directory temporanea casuale con il prefisso gg-testing.
+ `timeout-multiplier`— Moltiplicatore fornito a tutti i timeout dei test. Il valore predefinito è 1.0.
## Esempi di file di configurazione della CLI GDK
Puoi fare riferimento ai seguenti esempi di file di configurazione della CLI GDK per aiutarti a configurare gli ambienti dei componenti Greengrass.
### Ciao mondo (Python)
Il seguente file di configurazione GDK CLI supporta un componente Hello World che esegue uno script Python. Questo file di configurazione utilizza il sistema di `zip` compilazione per impacchettare lo script Python del componente in un file ZIP che la CLI di GDK carica come artefatto.
```
{
"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"
}
}
```
### Hello World (Java)
Il seguente file di configurazione GDK CLI supporta un componente Hello World che esegue un'applicazione Java. Questo file di configurazione utilizza il sistema di `maven` compilazione per impacchettare il codice sorgente Java del componente in un file JAR che la CLI GDK carica come artefatto.
```
{
"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"
}
}
```
### Componenti della community
Diversi componenti della community nel [Greengrass Software Catalog](greengrass-software-catalog.md) utilizzano la CLI GDK. Puoi esplorare i file di configurazione della CLI di GDK nei repository di questi componenti.
**Per visualizzare i file di configurazione della CLI GDK dei componenti della community**
1. Esegui il comando seguente per elencare i componenti della community che utilizzano la CLI GDK.
```
gdk component list --repository
```
La risposta elenca il nome del GitHub repository per ogni componente della comunità che utilizza la CLI GDK. Ogni repository esiste nell'organizzazione. `awslabs`
```
[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. Apri l' GitHub archivio di un componente della community al seguente URL. Sostituiscilo *community-component-name* con il nome di un componente della community del passaggio precedente.
```
https://github.com/awslabs/community-component-name
```
# Interfaccia a riga di comando Greengrass
L'interfaccia a riga di comando (CLI) di Greengrass consente di interagire con AWS IoT Greengrass Core sul dispositivo per sviluppare componenti ed eseguire il debug a livello locale. Ad esempio, è possibile utilizzare la CLI Greengrass per creare una distribuzione locale e riavviare un componente sul dispositivo principale.
Implementa il `aws.greengrass.Cli` componente [Greengrass CLI](greengrass-cli-component.md) () per installare la Greengrass CLI sul tuo dispositivo principale.
**Importante**
Si consiglia di utilizzare questo componente solo in ambienti di sviluppo, non in ambienti di produzione. Questo componente fornisce l'accesso a informazioni e operazioni che in genere non sono necessarie in un ambiente di produzione. Segui il principio del privilegio minimo distribuendo questo componente solo sui dispositivi principali dove ne hai bisogno.
**Topics**
+ [Installazione della CLI di Greengrass](install-gg-cli.md)
+ [Comandi della CLI di Greengrass](gg-cli-reference.md)
# Installazione della CLI di Greengrass
È possibile installare la Greengrass CLI in uno dei seguenti modi:
+ Usa l'`--deploy-dev-tools`argomento quando configuri per la prima volta il software AWS IoT Greengrass Core sul tuo dispositivo. È inoltre necessario specificare `--provision true` di applicare questo argomento.
+ Implementa il `aws.greengrass.Cli` componente Greengrass CLI () sul tuo dispositivo.
Questa sezione descrive i passaggi per distribuire il componente Greengrass CLI. Per informazioni sull'installazione della Greengrass CLI durante la configurazione iniziale, vedere. [Tutorial: Guida introduttiva a AWS IoT Greengrass V2](getting-started.md)
## Prerequisiti
Per distribuire il componente Greengrass CLI, è necessario soddisfare i seguenti requisiti:
+ AWS IoT Greengrass Software di base installato e configurato sul dispositivo principale. Per ulteriori informazioni, consulta [Tutorial: Guida introduttiva a AWS IoT Greengrass V2](getting-started.md).
+ Per utilizzare AWS CLI per distribuire la CLI Greengrass, è necessario aver installato e configurato il. AWS CLI Per ulteriori informazioni, consulta [Configurazione della AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html) nella *Guida per l'utente di AWS Command Line Interface *.
+ È necessario essere autorizzati a utilizzare la CLI Greengrass per interagire con il software Core. AWS IoT Greengrass Effettuate una delle seguenti operazioni per utilizzare la Greengrass CLI:
+ Utilizzate l'utente di sistema che esegue il software AWS IoT Greengrass Core.
+ Usa un utente con autorizzazioni root o amministrative. Sui dispositivi principali di Linux, puoi utilizzarlo per ottenere i permessi `sudo` di root.
+ Usa un utente di sistema che fa parte di un gruppo specificato nei parametri di `AuthorizedWindowsGroups` configurazione `AuthorizedPosixGroups` o quando distribuisci il componente. Per ulteriori informazioni, consulta Configurazione dei componenti della [CLI di Greengrass](greengrass-cli-component.md#greengrass-cli-component-configuration).
## Implementa il componente Greengrass CLI
Completa i seguenti passaggi per distribuire il componente Greengrass CLI sul tuo dispositivo principale:
### Per distribuire il componente Greengrass CLI (console)
1. Accedi alla [console AWS IoT Greengrass](https://console.aws.amazon.com/greengrass).
1. **Nel menu di navigazione, scegli Componenti.**
1. Nella pagina **Componenti**, nella scheda **Componenti pubblici**, scegli `aws.greengrass.Cli`.
1. Nella pagina **aws.greengrass.Cli**, scegli **(Distribuisci)**.
1. Da **Aggiungi alla distribuzione**, scegli **Crea nuova distribuzione**.
1. **Nella pagina **Specificare la destinazione**, in **Destinazioni di distribuzione**, nell'elenco **Nome destinazione**, scegli il gruppo Greengrass in cui desideri eseguire la distribuzione e scegli Avanti.**
1. **Nella pagina **Seleziona componenti**, verifica che il **aws.greengrass.Cli**componente sia selezionato e scegli Avanti.**
1. Nella pagina **Configura componenti**, mantieni le impostazioni di configurazione predefinite e scegli **Avanti**.
1. Nella pagina **Configura impostazioni avanzate**, mantieni le impostazioni di configurazione predefinite e scegli **Avanti**.
1. Nella pagina di **revisione**, fai clic su **Distribuisci**
### Per distribuire il componente Greengrass CLI ()AWS CLI
1. Sul tuo dispositivo, crea un `deployment.json` file per definire la configurazione di distribuzione per il componente Greengrass CLI. Questo file dovrebbe avere il seguente aspetto:
```
{
"targetArn":"targetArn",
"components": {
"aws.greengrass.Cli": {
"componentVersion": "2.16.1",
"configurationUpdate": {
"merge": "{\"AuthorizedPosixGroups\":\",,...,\",\"AuthorizedWindowsGroups\":\",,...,\"}"
}
}
}
}
```
+ Nel campo `target`, sostituisci `targetArn` con il nome della risorsa Amazon (ARN) dell'oggetto o del gruppo di oggetti a cui destinare la distribuzione, nel seguente formato:
+ Oggetto: `arn:aws:iot:region:account-id:thing/thingName`
+ Gruppo di oggetti: `arn:aws:iot:region:account-id:thinggroup/thingGroupName`
+ Nell'oggetto `aws.greengrass.Cli` componente, specificate i valori come segue:
`version`
La versione del componente Greengrass CLI.
`configurationUpdate.AuthorizedPosixGroups`
(Facoltativo) Una stringa che contiene un elenco di gruppi di sistema separati da virgole. Autorizzi questi gruppi di sistema a utilizzare la CLI Greengrass per interagire con AWS IoT Greengrass il software Core. È possibile specificare nomi o gruppi di gruppi. IDs Ad esempio, `group1,1002,group3` autorizza tre gruppi di sistema (`group1``1002`, e`group3`) a utilizzare la CLI Greengrass.
Se non specifichi alcun gruppo da autorizzare, puoi utilizzare la CLI Greengrass come `sudo` utente root () o come utente di sistema che AWS IoT Greengrass esegue il software Core.
`configurationUpdate.AuthorizedWindowsGroups`
(Facoltativo) Una stringa che contiene un elenco separato da virgole di gruppi di sistema. Autorizzi questi gruppi di sistema a utilizzare la CLI Greengrass per interagire con AWS IoT Greengrass il software Core. È possibile specificare nomi o gruppi di gruppi. IDs Ad esempio, `group1,1002,group3` autorizza tre gruppi di sistema (`group1``1002`, e`group3`) a utilizzare la CLI Greengrass.
Se non specifichi alcun gruppo da autorizzare, puoi utilizzare la CLI Greengrass come amministratore o come utente di sistema che AWS IoT Greengrass esegue il software Core.
1. Esegui il comando seguente per distribuire il componente Greengrass CLI sul dispositivo:
```
$ aws greengrassv2 create-deployment --cli-input-json file://path/to/deployment.json
```
Durante l'installazione, il componente aggiunge un collegamento simbolico `/greengrass/v2/bin` nella cartella del dispositivo e da questo percorso si esegue la Greengrass CLI. `greengrass-cli` Per eseguire la CLI di Greengrass senza il percorso assoluto, aggiungi la `/greengrass/v2/bin` cartella alla variabile PATH. Per verificare l'installazione della CLI di Greengrass, esegui il seguente comando:
------
#### [ Linux or Unix ]
```
/greengrass/v2/bin/greengrass-cli help
```
------
#### [ Windows ]
```
C:\greengrass\v2\bin\greengrass-cli help
```
------
Verrà visualizzato l’output seguente:
```
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.
```
Se `greengrass-cli` non viene trovato, la distribuzione potrebbe non essere riuscita a installare la CLI di Greengrass. Per ulteriori informazioni, consulta [Risoluzione dei problemi AWS IoT Greengrass V2](troubleshooting.md).
# Comandi della CLI di Greengrass
La CLI di Greengrass fornisce un'interfaccia a riga di comando per interagire localmente con il dispositivo principale. AWS IoT Greengrass I comandi della CLI di Greengrass utilizzano il seguente formato.
```
$ greengrass-cli [arguments]
```
Per impostazione predefinita, il file `greengrass-cli` eseguibile contenuto nella `/greengrass/v2/bin/` cartella interagisce con la versione del software AWS IoT Greengrass Core in esecuzione nella cartella. `/greengrass/v2` Se chiamate un file eseguibile che non si trova in questa posizione o se desiderate interagire con il software AWS IoT Greengrass Core in una posizione diversa, dovete utilizzare uno dei seguenti metodi per specificare in modo esplicito il percorso principale del software AWS IoT Greengrass Core con cui desiderate interagire:
+ Impostare la variabile di ambiente `GGC_ROOT_PATH` su `/greengrass/v2`.
+ Aggiungete l'`--ggcRootPath /greengrass/v2`argomento al comando come illustrato nell'esempio seguente.
```
greengrass-cli --ggcRootPath /greengrass/v2 [arguments]
```
È possibile utilizzare i seguenti argomenti con qualsiasi comando:
+ Utilizzare `--help` per informazioni su uno specifico comando della CLI di Greengrass.
+ Utilizzare `--version` per informazioni sulla versione della CLI di Greengrass.
Questa sezione descrive i comandi della CLI di Greengrass e fornisce esempi per questi comandi. La sinossi di ogni comando mostra i relativi argomenti e il loro utilizzo. Gli argomenti opzionali sono indicati tra parentesi quadre.
**Topics**
+ [componente](gg-cli-component.md)
+ [implementazione](gg-cli-deployment.md)
+ [log](gg-cli-logs.md)
+ [get-debug-password](gg-cli-get-debug-password.md)
# componente
Utilizzate il `component` comando per interagire con i componenti locali del dispositivo principale.
**Sottocomandi**
+ [details](#component-details)
+ [elenco](#component-list)
+ [riavviare](#component-restart)
+ [arresta](#component-stop)
## details
Recupera la versione, lo stato e la configurazione di un componente.
**Riepilogo**
```
greengrass-cli component details --name
```
**Arguments (Argomenti)**
`--name`,`-n`. Il nome del componente.
**Output**
L'esempio seguente mostra l'output prodotto quando si esegue questo comando.
```
$ sudo greengrass-cli component details --name MyComponent
Component Name: MyComponent
Version: 1.0.0
State: RUNNING
Configuration: null
```
## elenco
Recupera il nome, la versione, lo stato e la configurazione di ogni componente installato sul dispositivo.
**Riepilogo**
```
greengrass-cli component list
```
**Arguments (Argomenti)**
Nessuno
**Output**
L'esempio seguente mostra l'output prodotto quando si esegue questo comando.
```
$ 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"}
```
## riavviare
Riavviare i componenti.
**Riepilogo**
```
greengrass-cli component restart --names ,...
```
**Arguments (Argomenti)**
`--names`,`-n`. Il nome del componente. È richiesto almeno il nome di un componente. È possibile specificare nomi di componenti aggiuntivi, separando ogni nome con una virgola.
**Output**
Nessuno
## arresta
Smettete di far funzionare i componenti.
**Riepilogo**
```
greengrass-cli component stop --names ,...
```
**Arguments (Argomenti)**
`--names`,`-n`. Il nome del componente. È richiesto almeno il nome di un componente. È possibile specificare nomi di componenti aggiuntivi, se necessario, separando ogni nome con una virgola.
**Output**
Nessuno
# implementazione
Utilizzate il `deployment` comando per interagire con i componenti locali del dispositivo principale.
Per monitorare l'avanzamento di una distribuzione locale, usa il `status` sottocomando. Non è possibile monitorare l'avanzamento di una distribuzione locale utilizzando la console.
**Sottocomandi**
+ [Crea](#deployment-create)
+ [annullare](#deployment-cancel)
+ [elenco](#deployment-list)
+ [status](#deployment-status)
## Crea
Crea o aggiorna una distribuzione locale utilizzando ricette di componenti, artefatti e argomenti di runtime specifici.
**Riepilogo**
```
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 ]
```
**Arguments (Argomenti)**
+ `--recipeDir`,. `-r` Il percorso completo della cartella che contiene i file di ricette dei componenti.
+ `--artifactDir`,`-a`. Il percorso completo della cartella che contiene i file degli artefatti da includere nella distribuzione. La cartella artifacts deve contenere la seguente struttura di directory:
```
/path/to/artifact/folder///
```
+ `--update-config`,. `-c` Gli argomenti di configurazione per la distribuzione, forniti come stringa JSON o file JSON. La stringa JSON deve avere il seguente formato:
```
{ \
"componentName": { \
"MERGE": {"config-key": "config-value"}, \
"RESET": ["path/to/reset/"] \
} \
}
```
`MERGE`e `RESET` fanno distinzione tra maiuscole e minuscole e devono essere scritte in maiuscolo.
+ `--groupId`,. `-g` Il gruppo di oggetti bersaglio per la distribuzione.
+ `--merge`,`-m`. Il nome e la versione del componente di destinazione che desideri aggiungere o aggiornare. È necessario fornire le informazioni sul componente nel formato`=`. Utilizzate un argomento separato per ogni componente aggiuntivo da specificare. Se necessario, utilizzate l'`--runWith`argomento per fornire le `windowsUser` informazioni `posixUser``posixGroup`, e per l'esecuzione del componente.
+ `--runWith`. `posixUser``posixGroup`, e `windowsUser` informazioni per l'esecuzione di un componente generico o Lambda. È necessario fornire queste informazioni nel formato`:{posixUser|windowsUser}=[:<=posixGroup>]`. Ad esempio, è possibile specificare **HelloWorld:posixUser=ggc\$1user:ggc\$1group** o**HelloWorld:windowsUser=ggc\$1user**. Utilizzate un argomento separato per ogni opzione aggiuntiva da specificare.
Per ulteriori informazioni, consulta [Configurare l'utente che esegue i componenti](configure-greengrass-core-v2.md#configure-component-user).
+ `--systemLimits`. I limiti delle risorse di sistema da applicare ai processi dei componenti Lambda generici e non containerizzati sul dispositivo principale. È possibile configurare la quantità massima di utilizzo di CPU e RAM utilizzabile dai processi di ciascun componente. Specificate un oggetto JSON serializzato o il percorso di un file JSON. L'oggetto JSON deve avere il seguente formato.
```
{ \
"componentName": { \
"cpus": cpuTimeLimit, \
"memory": memoryLimitInKb \
} \
}
```
È possibile configurare i seguenti limiti di risorse di sistema per ogni componente:
+ `cpus`— La quantità massima di tempo di CPU che i processi di questo componente possono utilizzare sul dispositivo principale. Il tempo totale della CPU di un dispositivo principale è equivalente al numero di core CPU del dispositivo. Ad esempio, su un dispositivo principale con 4 core CPU, è possibile impostare questo valore in modo da `2` limitare i processi di questo componente al 50% di utilizzo di ciascun core della CPU. Su un dispositivo con 1 core di CPU, puoi impostare questo valore `0.25` per limitare i processi di questo componente al 25 percento di utilizzo della CPU. Se imposti questo valore su un numero maggiore del numero di core della CPU, il software AWS IoT Greengrass Core non limita l'utilizzo della CPU del componente.
+ `memory`— La quantità massima di RAM (in kilobyte) che i processi di questo componente possono utilizzare sul dispositivo principale.
Per ulteriori informazioni, consulta [Configura i limiti delle risorse di sistema per i componenti](configure-greengrass-core-v2.md#configure-component-system-resource-limits).
Questa funzionalità è disponibile per la versione 2.4.0 e successive del componente Greengrass [nucleus e della Greengrass CLI](greengrass-nucleus-component.md) sui dispositivi core Linux. AWS IoT Greengrass attualmente non supporta questa funzionalità sui dispositivi Windows core.
+ `--remove`. Il nome del componente di destinazione che si desidera rimuovere da una distribuzione locale. Per rimuovere un componente che è stato unito da una distribuzione cloud, è necessario fornire l'ID di gruppo del thing group di destinazione nel seguente formato:
------
#### [ Greengrass nucleus v2.4.0 and later ]
```
--remove --groupId
```
------
#### [ Earlier than v2.4.0 ]
```
--remove --groupId thinggroup/
```
------
+ `--failure-handling-policy`. Definisce l'azione intrapresa in caso di errore di una distribuzione. È possibile specificare due azioni:
+ `ROLLBACK` –
+ `DO_NOTHING` –
Questa funzionalità è disponibile per la versione 2.11.0 e successive di. [Nucleo Greengrass](greengrass-nucleus-component.md)
**Output**
L'esempio seguente mostra l'output prodotto quando si esegue questo comando.
```
$ 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
```
## annullare
Annulla la distribuzione specificata.
Riepilogo
```
greengrass-cli deployment cancel
-i
```
Argomenti
`-i`. L'identificatore univoco della distribuzione da annullare. L'ID di distribuzione viene restituito nell'output del `create` comando.
Output
+ Nessuno
## elenco
Recupera lo stato delle ultime 10 distribuzioni locali.
**Riepilogo**
```
greengrass-cli deployment list
```
**Arguments (Argomenti)**
Nessuno
**Output**
L'esempio seguente mostra l'output prodotto quando si esegue questo comando. A seconda dello stato della distribuzione, l'output mostra uno dei seguenti valori di stato: `IN_PROGRESS``SUCCEEDED`, o`FAILED`.
```
$ sudo greengrass-cli deployment list
44d89f46-1a29-4044-ad89-5151213dfcbc: SUCCEEDED
Created on: 6/27/23 11:05 AM
```
## status
Recupera lo stato di una distribuzione specifica.
**Riepilogo**
```
greengrass-cli deployment status -i
```
**Arguments (Argomenti)**
`-i`. L'ID della distribuzione.
**Output**
L'esempio seguente mostra l'output prodotto quando si esegue questo comando. A seconda dello stato della distribuzione, l'output mostra uno dei seguenti valori di stato: `IN_PROGRESS``SUCCEEDED`, o`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
```
# log
Usa il `logs` comando per analizzare i log di Greengrass sul tuo dispositivo principale.
**Sottocomandi**
+ [get](#logs-get)
+ [elenca-parole chiave](#logs-list-keywords)
+ [list-log-files](#logs-list-log-files)
## get
Raccogli, filtra e visualizza i file di registro Greengrass. Questo comando supporta solo file di registro in formato JSON. È possibile specificare il [formato di registrazione nella configurazione del nucleo](greengrass-nucleus-component.md#greengrass-nucleus-component-configuration-logging-format).
**Riepilogo**
```
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 ]
```
**Arguments (Argomenti)**
+ `--log-dir`,. `-ld` Il percorso della directory in cui verificare la presenza di file di registro, ad esempio**`/greengrass/v2`/logs**. Non utilizzare con`--syslog`. Utilizzate un argomento separato per ogni directory aggiuntiva da specificare. È necessario utilizzare almeno uno degli `--log-dir` o`--log-file`. È inoltre possibile utilizzare entrambi gli argomenti in un unico comando.
+ `--log-file`,`-lf`. I percorsi delle directory di registro che desideri utilizzare. Utilizzate un argomento separato per ogni directory aggiuntiva da specificare. È necessario utilizzare almeno uno degli `--log-dir` o`--log-file`. È inoltre possibile utilizzare entrambi gli argomenti in un unico comando.
+ `--follow`,`-fol`. Mostra gli aggiornamenti del registro man mano che si verificano. La CLI di Greengrass continua a funzionare e legge i log specificati. Se si specifica una finestra temporale, la CLI di Greengrass interrompe il monitoraggio dei log al termine di tutte le finestre temporali.
+ `--filter`,. `-f` La parola chiave, le espressioni regolari o la coppia chiave-valore da usare come filtro. Fornite questo valore come stringa, espressione regolare o coppia chiave-valore. Utilizzate un argomento separato per ogni filtro aggiuntivo da specificare.
Quando vengono valutati, più filtri specificati in un singolo argomento vengono separati da operatori OR e i filtri specificati negli argomenti aggiuntivi vengono combinati con gli operatori AND. Ad esempio, se il comando include`--filter "installed" --filter "name=alpha,name=beta"`, Greengrass CLI filtrerà e visualizzerà i messaggi di registro che contengono sia la parola chiave che una `name` chiave con `installed` i valori o. `alpha` `beta`
+ `--time-window`,. `-t` La finestra temporale per la quale mostrare le informazioni del registro. È possibile utilizzare sia i timestamp esatti che gli offset relativi. È necessario fornire queste informazioni nel formato. `,` Se non si specifica né l'ora di inizio né l'ora di fine, il valore predefinito di tale opzione è la data e l'ora correnti del sistema. Utilizzate un argomento separato per ogni finestra temporale aggiuntiva da specificare.
La CLI di Greengrass supporta i seguenti formati per i timestamp:
+ `yyyy-MM-DD`, ad esempio,. `2020-06-30` L'ora predefinita è 00:00:00 quando si utilizza questo formato.
`yyyyMMDD`, ad esempio,. `20200630` L'ora predefinita è 00:00:00 quando si utilizza questo formato.
`HH:mm:ss`, ad esempio,. `15:30:45` La data predefinita è la data di sistema corrente quando si utilizza questo formato.
`HH:mm:ssSSS`, ad esempio,. `15:30:45` La data predefinita è la data corrente del sistema quando si utilizza questo formato.
`YYYY-MM-DD'T'HH:mm:ss'Z'`, ad esempio,. `2020-06-30T15:30:45Z`
`YYYY-MM-DD'T'HH:mm:ss`, ad esempio,`2020-06-30T15:30:45`.
`yyyy-MM-dd'T'HH:mm:ss.SSS`, ad esempio,`2020-06-30T15:30:45.250`.
Gli offset relativi specificano uno scostamento del periodo di tempo dall'ora corrente del sistema. La CLI di Greengrass supporta il seguente formato per gli offset relativi:. `+|-[h|hr|hours][valuem|min|minutes][value]s|sec|seconds`
Ad esempio, il seguente argomento per specificare una finestra temporale compresa tra 1 ora e 2 ore 15 minuti prima dell'ora corrente è. `--time-window -2h15min,-1hr`
+ `--verbose`. Mostra tutti i campi dei messaggi di registro. Non utilizzare con`--syslog`.
+ `--no-color`,`-nc`. Rimuovi la codifica a colori. La codifica a colori predefinita per i messaggi di registro utilizza il testo in grassetto rosso. Supporta solo terminali simili a Unix perché utilizza sequenze di escape ANSI.
+ `--before`,`-b`. Il numero di righe da mostrare prima di una voce di registro corrispondente. Il valore predefinito è 0.
+ `--after`,. `-a` Il numero di righe da mostrare dopo una voce di registro corrispondente. Il valore predefinito è 0.
+ `--syslog`. Elabora tutti i file di registro utilizzando il protocollo syslog definito da. RFC3164 Non utilizzare con `--log-dir` and. `--verbose` Il protocollo syslog utilizza il seguente formato:. `"<$Priority>$Timestamp $Host $Logger ($Class): $Message"` Se non si specifica un file di registro, la CLI di Greengrass legge i messaggi di registro dalle seguenti posizioni:`/var/log/messages`, o il. `/var/log/syslog` `/var/log/system.log`
AWS IoT Greengrass attualmente non supporta questa funzionalità sui dispositivi Windows core.
+ `--max-log-queue-size`,`-m`. Il numero massimo di voci di registro da allocare alla memoria. Utilizzate questa opzione per ottimizzare l'utilizzo della memoria. L'impostazione predefinita è 100.
**Output**
L'esempio seguente mostra l'output prodotto quando si esegue questo comando.
```
$ 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
```
## elenca-parole chiave
Mostra le parole chiave suggerite che è possibile utilizzare per filtrare i file di registro.
**Riepilogo**
```
greengrass-cli logs list-keywords [arguments]
```
**Arguments (Argomenti)**
Nessuno
**Output**
Gli esempi seguenti mostrano l'output prodotto quando si esegue questo comando.
```
$ 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
Mostra i file di registro che si trovano in una directory specificata.
**Riepilogo**
```
greengrass-cli logs list-log-files [arguments]
```
**Arguments (Argomenti)**
`--log-dir`,`-ld`. Il percorso della directory in cui verificare la presenza di file di registro.
**Output**
L'esempio seguente mostra l'output prodotto quando si esegue questo comando.
```
$ 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
Utilizzate il `get-debug-password` comando per stampare una password generata casualmente per il componente della console di [debug locale](local-debug-console-component.md) (). `aws.greengrass.LocalDebugConsole` La password scade 8 ore dopo la generazione.
**Riepilogo**
```
greengrass-cli get-debug-password
```
**Arguments (Argomenti)**
Nessuno
**Output**
L'esempio seguente mostra l'output prodotto quando si esegue questo comando.
```
$ 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
```
# Usa AWS IoT Greengrass Testing Framework
Greengrass Testing Framework (GTF) è una raccolta di elementi costitutivi che supporta end-to-end l'automazione dal punto di vista del cliente. GTF utilizza [Cucumber](https://cucumber.io) come driver di funzionalità. AWS IoT Greengrass utilizza gli stessi elementi costitutivi per qualificare le modifiche al software su vari dispositivi. Per ulteriori informazioni, consulta [Greengrass Testing Framework su](https://github.com/aws-greengrass/aws-greengrass-testing/tree/dev_v1) Github.
GTF è implementato utilizzando Cucumber, uno strumento utilizzato per eseguire test automatici, per incoraggiare uno sviluppo basato sul comportamento (BDD) dei componenti. In Cucumber, le caratteristiche di questo sistema sono descritte in un tipo speciale di file chiamato. `feature` Ogni funzionalità è descritta in un formato leggibile dall'uomo chiamato scenari, che sono specifiche che possono essere convertite in test automatici. Ogni scenario è delineato come una serie di passaggi che definiscono le interazioni e i risultati del sistema in esame utilizzando un linguaggio specifico del dominio chiamato Gherkin. Una [fase Gherkin](https://cucumber.io/docs/gherkin/reference/#steps) è collegata al codice di programmazione utilizzando un metodo chiamato step definition che collega le specifiche al flusso di test. Le definizioni dei passaggi in GTF sono implementate con Java.
**Topics**
+ [Come funziona](#gg-testing-framework-how-gtf-works)
+ [Changelog](#gtf-changelog)
+ [Opzioni di configurazione di Greengrass Testing Framework](configuration-options-gtf.md)
+ [Tutorial: Esegui end-to-end i test utilizzando Greengrass Testing Framework e Greengrass Development Kit](run-e2e-tests-tutorial.md)
+ [Tutorial: usa un test di confidenza dalla suite di test di fiducia](confidence-tests-tutorial.md)
## Come funziona
AWS IoT Greengrass distribuisce GTF come JAR autonomo composto da diversi moduli Java. Per utilizzare GTF per end-to-end testare i componenti, è necessario implementare i test all'interno di un progetto Java. L'aggiunta del JAR standable di test come dipendenza nel progetto Java consente di utilizzare le funzionalità esistenti del GTF ed estenderle scrivendo casi di test personalizzati. Per eseguire i test case personalizzati, puoi creare il tuo progetto Java ed eseguire il JAR di destinazione con le opzioni di configurazione descritte in. [Opzioni di configurazione di Greengrass Testing Framework](configuration-options-gtf.md)
### JAR standalone GTF
Greengrass utilizza Cloudfront come repository [Maven](https://maven.apache.org/) per ospitare diverse versioni del JAR standalone GTF. [Per un elenco completo delle versioni GTF, consulta le versioni GTF.](https://github.com/aws-greengrass/aws-greengrass-testing/releases)
Il JAR standalone GTF include i seguenti moduli. Non è limitato solo a questi moduli. Puoi scegliere ciascuna di queste dipendenze separatamente nel tuo progetto o includerle tutte contemporaneamente nel file [JAR standalone di test](https://github.com/aws-greengrass/aws-greengrass-testing/tree/dev_v1/aws-greengrass-testing-standalone).
+ `aws-greengrass-testing-resources`: Questo modulo fornisce l'astrazione per la gestione del ciclo di vita di una AWS risorsa nel corso di un test. Puoi usarlo per definire le tue AWS risorse personalizzate usando l'`ResourceSpec`astrazione in modo che GTF possa occuparsi della creazione e della rimozione di tali risorse per te.
+ `aws-greengrass-testing-platform`: Questo modulo fornisce l'astrazione a livello di piattaforma per il dispositivo sottoposto a test durante il ciclo di vita del test. Contiene dati APIs utilizzati per interagire con il sistema operativo indipendentemente dalla piattaforma e può essere utilizzato per simulare i comandi in esecuzione nella shell del dispositivo.
+ `aws-greengrass-testing-components`: Questo modulo è costituito da componenti di esempio utilizzati per testare le funzionalità principali di Greengrass come implementazioni, IPC e altre funzionalità.
+ `aws-greengrass-testing-features`: Questo modulo è composto da passaggi comuni riutilizzabili e relative definizioni che vengono utilizzati per i test nell'ambiente Greengrass.
**Topics**
+ [Come funziona](#gg-testing-framework-how-gtf-works)
+ [Changelog](#gtf-changelog)
+ [Opzioni di configurazione di Greengrass Testing Framework](configuration-options-gtf.md)
+ [Tutorial: Esegui end-to-end i test utilizzando Greengrass Testing Framework e Greengrass Development Kit](run-e2e-tests-tutorial.md)
+ [Tutorial: usa un test di confidenza dalla suite di test di fiducia](confidence-tests-tutorial.md)
## Changelog
La tabella seguente descrive le modifiche in ogni versione del GTF. Per ulteriori informazioni, consulta la [pagina GTF Releases](https://github.com/aws-greengrass/aws-greengrass-testing/releases) su. GitHub
| **Versione** | **Modifiche** |
| --- | --- |
| 1.2.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/greengrass/v2/developerguide/gg-testing-framework.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/greengrass/v2/developerguide/gg-testing-framework.html) |
| 1.1.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/greengrass/v2/developerguide/gg-testing-framework.html) |
| 1.0.0 | Versione iniziale. |
# Opzioni di configurazione di Greengrass Testing Framework
## Opzioni di configurazione GTF
Greengrass Testing Framework (GTF) consente di configurare determinati parametri durante l'avvio del processo di end-to-end test per orchestrare il flusso di test. È possibile specificare queste opzioni di configurazione come argomenti CLI per il JAR standalone GTF.
La versione 1.1.0 e successive di GTF fornisce le seguenti opzioni di configurazione.
+ `additional-plugins`— (Opzionale) Plugin aggiuntivi per Cucumber
+ `aws-region`— Si rivolge a endpoint regionali specifici per i servizi. AWS L'impostazione predefinita è ciò che rileva l' AWS SDK.
+ `credentials-path`— Percorso opzionale AWS delle credenziali del profilo. L'impostazione predefinita sono le credenziali rilevate nell'ambiente host.
+ `credentials-path-rotation`— Durata di rotazione opzionale per le credenziali. AWS Il valore predefinito è 15 minuti o. `PT15M`
+ `csr-path`— Il percorso della CSR con cui verrà generato il certificato del dispositivo.
+ `device-mode`— Il dispositivo bersaglio sottoposto a test. L'impostazione predefinita è il dispositivo locale.
+ `env-stage`— Si rivolge all'ambiente di implementazione di Greengrass. L'impostazione predefinita è la produzione.
+ `existing-device-cert-arn`— L'arn di un certificato esistente che desideri utilizzare come certificato del dispositivo per Greengrass.
+ `feature-path`— File o directory contenente file di funzionalità aggiuntivi. L'impostazione predefinita è che non vengono utilizzati file di feature aggiuntivi.
+ `gg-cli-version`— Sostituisce la versione della CLI di Greengrass. Il valore predefinito è il valore trovato in. `ggc.version`
+ `gg-component-bucket`— Il nome di un bucket Amazon S3 esistente che contiene componenti Greengrass.
+ `gg-component-overrides`— Un elenco di componenti sostituiti da Greengrass.
+ `gg-persist`— Un elenco di elementi di test che devono persistere dopo l'esecuzione di un test. Il comportamento predefinito consiste nel non rendere persistente nulla. I valori accettati sono: `aws.resources``installed.software`, e`generated.files`.
+ `gg-runtime`— Un elenco di valori per influenzare il modo in cui il test interagisce con le risorse di test. Questi valori sostituiscono il parametro. `gg.persist` Se l'impostazione predefinita è vuota, presuppone che tutte le risorse di test siano gestite per test case, incluso il runtime Greengrass installato. I valori accettati sono:`aws.resources`, e`installed.software`. `generated.files`
+ `ggc-archive`— Il percorso verso il componente Greengrass nucleus archiviato.
+ `ggc-install-root`— Directory per installare il componente Greengrass nucleus. I valori predefiniti sono test.temp.path e test run.
+ `ggc-log-level`— Imposta il livello di registro del nucleo di Greengrass per l'esecuzione del test. L'impostazione predefinita è «INFO».
+ `ggc-tes-rolename`— Il ruolo IAM che AWS IoT Greengrass Core assumerà per accedere ai AWS servizi. Se non esiste un ruolo con un nome specifico, ne verrà creato uno e una politica di accesso predefinita.
+ `ggc-trusted-plugins`— L'elenco separato da virgole dei percorsi (sull'host) dei plugin affidabili che devono essere aggiunti a Greengrass. Per fornire il percorso sul DUT stesso, inserisci il prefisso 'dut: '
+ `ggc-user-name`— Il valore PosixUser user:group per il nucleo Greengrass. Il valore predefinito è il nome utente corrente a cui è stato effettuato l'accesso.
+ `ggc-version`— Sostituisce la versione del componente Greengrass nucleus in esecuzione. Il valore predefinito è il valore trovato in ggc.archive.
+ `log-level`— Livello di registro dell'esecuzione del test. Il valore predefinito è «INFO».
+ `parallel-config`— Set di indice di batch e numero di batch come stringa JSON. Il valore predefinito dell'indice batch è 0 e il numero di batch è 1.
+ `proxy-url`— Configura tutti i test per indirizzare il traffico attraverso questo URL.
+ `tags`— Esegui solo tag di funzionalità. Può essere intersecato con '&'
+ `test-id-prefix`— Un prefisso comune applicato a tutte le risorse specifiche del test, inclusi i nomi e i tag AWS delle risorse. L'impostazione predefinita è il prefisso «gg».
+ `test-log-path`— Directory che conterrà i risultati dell'intera esecuzione del test. Il valore predefinito è «testResults».
+ `test-results-json`— Contrassegno per determinare se viene generato un report Cucumber JSON risultante scritto su disco. Il valore predefinito è true.
+ `test-results-log`— Contrassegno per determinare se l'output della console viene generato scritto su disco. Il valore predefinito è false (falso).
+ `test-results-xml`— Contrassegno per determinare se viene generato un report JUnit XML risultante scritto su disco. Il valore predefinito è true.
+ `test-temp-path`— Directory per generare artefatti di test locali. Il valore predefinito è una directory temporanea casuale con il prefisso gg-testing.
+ `timeout-multiplier`— Moltiplicatore fornito a tutti i timeout dei test. Il valore predefinito è 1.0.
# Tutorial: Esegui end-to-end i test utilizzando Greengrass Testing Framework e Greengrass Development Kit
AWS IoT Greengrass Testing Framework (GTF) e Greengrass Development Kit (GDK) offrono agli sviluppatori modi per eseguire i test. end-to-end Puoi completare questo tutorial per inizializzare un progetto GDK con un componente, inizializzare un progetto GDK con un modulo di test e creare un end-to-end test case personalizzato. Dopo aver creato il tuo test case personalizzato, puoi eseguire il test.
In questo tutorial, esegui quanto indicato di seguito:
1. Inizializza un progetto GDK con un componente.
1. Inizializza un progetto GDK con un modulo di test. end-to-end
1. Crea un test case personalizzato.
1. Aggiungi un tag al nuovo test case.
1. Crea il JAR di test.
1. Eseguire il test .
**Topics**
+ [Prerequisiti](#run-e2e-tests-tutorial-prerequisites)
+ [Fase 1: Inizializza un progetto GDK con un componente](#init-gdk-with-component)
+ [Fase 2: Inizializza un progetto GDK con un end-to-end modulo di test](#init-gdk-with-e2e-test)
+ [Passaggio 3: crea un test case personalizzato](#run-e2e-tests-tutorial-instructions)
+ [Passaggio 4: aggiungere un tag al nuovo test case](#add-tag-to-test-case)
+ [Fase 5: Creare il JAR di test](#build-test-jar)
+ [Passaggio 6: eseguire il test](#run-test-gtf)
+ [Esempio: crea un test case personalizzato](#build-test-case-example)
## Prerequisiti
Per completare questo tutorial, è necessario quanto segue:
+ GDK versione 1.3.0 o successiva
+ Java
+ Maven
+ Git
## Fase 1: Inizializza un progetto GDK con un componente
+ Inizializza una cartella vuota con un progetto GDK. Scarica il `HelloWorld` componente implementato in Python eseguendo il seguente comando.
```
gdk component init -t HelloWorld -l python -n HelloWorld
```
Questo comando crea una nuova directory denominata `HelloWorld` nella directory corrente.
## Fase 2: Inizializza un progetto GDK con un end-to-end modulo di test
+ GDK consente di scaricare il modello del modulo di test costituito da un'implementazione di funzionalità e fasi. Esegui il comando seguente per aprire la `HelloWorld` directory e inizializzare il progetto GDK esistente utilizzando un modulo di test.
```
cd HelloWorld
gdk test-e2e init
```
Questo comando crea una nuova directory denominata `gg-e2e-tests` all'interno della `HelloWorld` directory. Questa directory di test è un progetto [Maven](https://maven.apache.org/) che dipende dal JAR standalone di test Greengrass.
## Passaggio 3: crea un test case personalizzato
La scrittura di un test case personalizzato consiste sostanzialmente in due passaggi: creare un file di funzionalità con uno scenario di test e implementare le definizioni dei passaggi. Per un esempio di creazione di un test case personalizzato, vedi[Esempio: crea un test case personalizzato](#build-test-case-example). Utilizza i seguenti passaggi per creare il tuo test case personalizzato:
1. Crea un file di funzionalità con uno scenario di test
Una funzionalità descrive in genere una funzionalità specifica del software che viene testato. In Cucumber, ogni funzionalità è specificata come un singolo file di funzionalità con un titolo, una descrizione dettagliata e uno o più esempi di casi specifici chiamati scenari. Ogni scenario è composto da un titolo, una descrizione dettagliata e una serie di passaggi che definiscono le interazioni e i risultati attesi. Gli scenari sono scritti in un formato strutturato utilizzando le parole chiave «given», «when» e «then».
1. Implementa le definizioni dei
Una definizione di fase collega la [fase Gherkin](https://cucumber.io/docs/gherkin/reference/#steps) in un linguaggio semplice al codice programmatico. Quando Cucumber identifica un passaggio Gherkin in uno scenario, cercherà una definizione di fase corrispondente da eseguire.
## Passaggio 4: aggiungere un tag al nuovo test case
+ È possibile assegnare tag alle funzionalità e agli scenari per organizzare il processo di test. È possibile utilizzare i tag per classificare i sottoinsiemi di scenari e anche selezionare gli hook in modo condizionale da eseguire. Le funzionalità e gli scenari possono avere più tag separati da uno spazio.
In questo esempio, stiamo usando il `HelloWorld` componente.
Nel file delle funzionalità, aggiungete un nuovo tag denominato `@HelloWorld` accanto al `@Sample` tag.
```
@Sample @HelloWorld
Scenario: As a developer, I can create a component and deploy it on my device
....
```
## Fase 5: Creare il JAR di test
1. Costruisci il componente. È necessario creare il componente prima di creare il modulo di test.
```
gdk component build
```
1. Costruite il modulo di test utilizzando il seguente comando. Questo comando creerà il JAR di test nella `greengrass-build` cartella.
```
gdk test-e2e build
```
## Passaggio 6: eseguire il test
Quando esegui un test case personalizzato, GTF automatizza il ciclo di vita del test oltre alla gestione delle risorse create durante il test. Innanzitutto esegue il provisioning di un dispositivo in fase di test (DUT) come dispositivo e installa su di esso il software di base Greengrass. AWS IoT Creerà quindi un nuovo componente denominato `HelloWorld` utilizzando la ricetta specificata in quel percorso. Il `HelloWorld` componente viene quindi distribuito sul dispositivo principale tramite una distribuzione di oggetti Greengrass. Verrà quindi verificato se l'implementazione è riuscita. Lo stato di distribuzione verrà modificato `COMPLETED` entro 3 minuti se la distribuzione ha esito positivo.
1. Vai al `gdk-config.json` file nella directory del progetto per indirizzare i test con il `HelloWorld` tag. Aggiorna la `test-e2e` chiave usando il seguente comando.
```
"test-e2e":{
"gtf_options" : {
"tags":"HelloWorld"
}
}
```
1. Prima di eseguire i test, è necessario fornire AWS le credenziali al dispositivo host. GTF utilizza queste credenziali per gestire le AWS risorse durante il processo di test. Assicurati che il ruolo che fornisci disponga delle autorizzazioni per automatizzare le operazioni necessarie incluse nel test.
Esegui i seguenti comandi per fornire le credenziali. AWS
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. Eseguite il test utilizzando il seguente comando.
```
gdk test-e2e run
```
Questo comando scarica l'ultima versione del nucleo Greengrass nella `greengrass-build` cartella ed esegue i test utilizzandola. Questo comando si rivolge inoltre solo agli scenari con il `HelloWorld` tag e genera un report per tali scenari. Vedrai che le AWS risorse create durante questo test vengono scartate alla fine del test.
## Esempio: crea un test case personalizzato
**Example**
Il modulo di test scaricato nel progetto GDK è costituito da una funzionalità di esempio e da un file di implementazione delle fasi.
Nell'esempio seguente, creiamo un file di funzionalità per testare la funzionalità di distribuzione degli oggetti del software Greengrass. Testiamo parzialmente la funzionalità di questa funzionalità con uno scenario che esegue l'implementazione di un componente tramite Greengrass Cloud AWS. Questa è una serie di passaggi che ci aiutano a comprendere le interazioni e i risultati attesi di questo caso d'uso.
1.
**Create un file di feature**
Passate alla `gg-e2e-tests/src/main/resources/greengrass/features` cartella nella directory corrente. È possibile trovare l'esempio `component.feature` simile all'esempio seguente.
In questo file di funzionalità, puoi testare la funzionalità di distribuzione degli oggetti del software Greengrass. È possibile testare parzialmente la funzionalità di questa funzionalità con uno scenario che esegue una distribuzione di un componente tramite il cloud Greengrass. Lo scenario è una serie di passaggi che aiutano a comprendere le interazioni e i risultati attesi di questo caso d'uso.
```
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 contiene le definizioni dei passaggi di tutti i passaggi seguenti, ad eccezione del passaggio denominato:. `And I call my custom step`
1.
**Implementa le definizioni dei**
Il JAR standalone GTF contiene le definizioni di tutti i passaggi tranne uno:. `And I call my custom step` Puoi implementare questo passaggio nel modulo di test.
Vai al codice sorgente del file di test. È possibile collegare il passaggio personalizzato utilizzando una definizione di passaggio utilizzando il comando seguente.
```
@And("I call my custom step")
public void customStep() {
System.out.println("My custom step was called ");
}
```
# Tutorial: usa un test di confidenza dalla suite di test di fiducia
AWS IoT Greengrass Testing Framework (GTF) e Greengrass Development Kit (GDK) offrono agli sviluppatori modi per eseguire i test. end-to-end Puoi completare questo tutorial per inizializzare un progetto GDK con un componente, inizializzare un progetto GDK con un modulo di test e utilizzare un end-to-end test di confidenza della suite di test di confidenza. Dopo aver creato il tuo test case personalizzato, puoi eseguire il test.
Un test di confidenza è un test generico fornito da Greengrass che convalida i comportamenti fondamentali dei componenti. Questi test possono essere modificati o estesi per soddisfare esigenze più specifiche dei componenti.
Per questo tutorial useremo un HelloWorld componente. Se stai usando un altro componente, sostituisci il HelloWorld componente con il tuo componente.
In questo tutorial, esegui quanto indicato di seguito:
1. Inizializza un progetto GDK con un componente.
1. Inizializza un progetto GDK con un modulo di test. end-to-end
1. Usa un test della suite di test di fiducia.
1. Aggiungi un tag al nuovo test case.
1. Crea il JAR di test.
1. Eseguire il test .
**Topics**
+ [Prerequisiti](#confidence-tests-tutorial-prerequisites)
+ [Fase 1: Inizializza un progetto GDK con un componente](#init-gdk-with-component)
+ [Fase 2: Inizializza un progetto GDK con un end-to-end modulo di test](#init-gdk-with-e2e-test)
+ [Passaggio 3: utilizzare un test della suite di test di fiducia](#confidence-tests-tutorial-instructions)
+ [Fase 4: Aggiungere un tag al nuovo test case](#add-tag-to-test-case)
+ [Passaggio 5: crea il JAR di test](#build-test-jar)
+ [Passaggio 6: eseguire il test](#run-test-gtf)
+ [Esempio: utilizza un test di fiducia](#build-confidence-test-case-example)
## Prerequisiti
Per completare questo tutorial, è necessario quanto segue:
+ GDK versione 1.6.0 o successiva
+ Java
+ Maven
+ Git
## Fase 1: Inizializza un progetto GDK con un componente
+ Inizializza una cartella vuota con un progetto GDK. Scarica il `HelloWorld` componente implementato in Python eseguendo il seguente comando.
```
gdk component init -t HelloWorld -l python -n HelloWorld
```
Questo comando crea una nuova directory denominata `HelloWorld` nella directory corrente.
## Fase 2: Inizializza un progetto GDK con un end-to-end modulo di test
+ GDK consente di scaricare il modello del modulo di test costituito da un'implementazione di funzionalità e fasi. Esegui il comando seguente per aprire la `HelloWorld` directory e inizializzare il progetto GDK esistente utilizzando un modulo di test.
```
cd HelloWorld
gdk test-e2e init
```
Questo comando crea una nuova directory denominata `gg-e2e-tests` all'interno della `HelloWorld` directory. Questa directory di test è un progetto [Maven](https://maven.apache.org/) che dipende dal JAR standalone di test Greengrass.
## Passaggio 3: utilizzare un test della suite di test di fiducia
La scrittura di un test case di fiducia consiste nell'utilizzare il file di funzionalità fornito e, se necessario, nella modifica degli scenari. Per un esempio di utilizzo di un test di confidenza, vedere[Esempio: crea un test case personalizzato](run-e2e-tests-tutorial.md#build-test-case-example). Per utilizzare un test di confidenza, attenersi alla seguente procedura:
+ Utilizzate il file di funzionalità fornito.
Passate alla `gg-e2e-tests/src/main/resources/greengrass/features` cartella nella directory corrente. Apri il `confidenceTest.feature` file di esempio per utilizzare il test di fiducia.
## Fase 4: Aggiungere un tag al nuovo test case
+ È possibile assegnare tag alle funzionalità e agli scenari per organizzare il processo di test. È possibile utilizzare i tag per classificare i sottoinsiemi di scenari e anche selezionare gli hook in modo condizionale da eseguire. Le funzionalità e gli scenari possono avere più tag separati da uno spazio.
In questo esempio, stiamo usando il `HelloWorld` componente.
Ogni scenario è contrassegnato con`@ConfidenceTest`. Modifica o aggiungi tag se desideri eseguire solo un sottoinsieme della suite di test. Ogni scenario di test è descritto all'inizio di ogni test di confidenza. Lo scenario è una serie di passaggi che aiutano a comprendere le interazioni e i risultati attesi di ogni caso di test. È possibile estendere questi test aggiungendo passaggi personalizzati o modificando quelli esistenti.
```
@ConfidenceTest
Scenario: As a Developer, I can deploy GDK_COMPONENT_NAME to my device and see it is working as expected
....
```
## Passaggio 5: crea il JAR di test
1. Costruisci il componente. È necessario creare il componente prima di creare il modulo di test.
```
gdk component build
```
1. Costruite il modulo di test utilizzando il seguente comando. Questo comando creerà il JAR di test nella `greengrass-build` cartella.
```
gdk test-e2e build
```
## Passaggio 6: eseguire il test
Quando si esegue un test di confidenza, il GTF automatizza il ciclo di vita del test oltre alla gestione delle risorse create durante il test. Innanzitutto esegue il provisioning di un dispositivo in fase di test (DUT) come dispositivo e installa su di esso il software di base Greengrass. AWS IoT Creerà quindi un nuovo componente denominato `HelloWorld` utilizzando la ricetta specificata in quel percorso. Il `HelloWorld` componente viene quindi distribuito sul dispositivo principale tramite una distribuzione di oggetti Greengrass. Verrà quindi verificato se l'implementazione è riuscita. Lo stato di distribuzione verrà modificato `COMPLETED` entro 3 minuti se la distribuzione ha esito positivo.
1. Vai al `gdk-config.json` file nella directory del progetto per indirizzare i test con il `ConfidenceTest` tag o il tag yo8u specificato nel passaggio 4. Aggiorna la `test-e2e` chiave usando il seguente comando.
```
"test-e2e":{
"gtf_options" : {
"tags":"ConfidenceTest"
}
}
```
1. Prima di eseguire i test, è necessario fornire AWS le credenziali al dispositivo host. GTF utilizza queste credenziali per gestire le AWS risorse durante il processo di test. Assicurati che il ruolo che fornisci disponga delle autorizzazioni necessarie per automatizzare le operazioni necessarie incluse nel test.
Esegui i seguenti comandi per fornire le credenziali. AWS
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. Eseguite il test utilizzando il seguente comando.
```
gdk test-e2e run
```
Questo comando scarica l'ultima versione del nucleo Greengrass nella `greengrass-build` cartella ed esegue i test utilizzandola. Questo comando si rivolge inoltre solo agli scenari con il `ConfidenceTest` tag e genera un report per tali scenari. Vedrai che le AWS risorse create durante questo test vengono scartate alla fine del test.
## Esempio: utilizza un test di fiducia
**Example**
Il modulo di test scaricato nel progetto GDK è costituito da un file di funzionalità fornito.
Nell'esempio seguente, utilizziamo un file di funzionalità per testare la funzionalità di distribuzione degli oggetti del software Greengrass. Testiamo parzialmente la funzionalità di questa funzionalità con uno scenario che esegue l'implementazione di un componente tramite Greengrass Cloud AWS. Questa è una serie di passaggi che ci aiutano a comprendere le interazioni e i risultati attesi di questo caso d'uso.
+
**Utilizza il file di funzionalità fornito.**
Passate alla `gg-e2e-tests/src/main/resources/greengrass/features` cartella nella directory corrente. È possibile trovare l'esempio `confidenceTest.feature` simile all'esempio seguente.
```
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
```
Ogni scenario di test è descritto all'inizio di ogni test di confidenza. Lo scenario è una serie di passaggi che aiutano a comprendere le interazioni e i risultati attesi di ogni caso di test. È possibile estendere questi test aggiungendo passaggi personalizzati o modificando quelli esistenti. Ciascuno degli scenari include commenti che consentono di apportare queste modifiche.