CLI-Konfigurationsdatei des Greengrass Development Kit - AWS IoT Greengrass
Format der GDK-CLI-KonfigurationsdateiBeispiele für GDK-CLI-Konfigurationsdateien

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

CLI-Konfigurationsdatei des Greengrass Development Kit

Das AWS IoT Greengrass Development Kit Command-Line Interface (GDK CLI) liest aus einer Konfigurationsdatei mit dem Namen gdk-config.json, um Komponenten zu erstellen und zu veröffentlichen. Diese Konfigurationsdatei muss im Stammverzeichnis des Komponenten-Repositorys vorhanden sein. Sie können den Befehl GDK CLI init verwenden, um Komponenten-Repositorys mit dieser Konfigurationsdatei zu initialisieren.

Format der GDK-CLI-Konfigurationsdatei

Wenn Sie eine GDK-CLI-Konfigurationsdatei für eine Komponente definieren, geben Sie die folgenden Informationen im JSON-Format an.

gdk_version

Die Mindestversion der GDK-CLI, die mit dieser Komponente kompatibel ist. Dieser Wert muss eine der GDK-CLI-Versionen aus Versionen sein.

component

Die Konfiguration für diese Komponente.

componentName
author

Der Autor oder Herausgeber der Komponente.

version

Die Version der Komponente. Geben Sie eines der folgenden Elemente an:

  • NEXT_PATCH – Wenn Sie diese Option wählen, legt die GDK-CLI die Version fest, wenn Sie die Komponente veröffentlichen. Die GDK-CLI fragt den AWS IoT Greengrass Service ab, um die neueste veröffentlichte Version der Komponente zu identifizieren. Anschließend wird die Version auf die nächste Patch-Version nach dieser Version festgelegt. Wenn Sie die Komponente noch nicht veröffentlicht haben, verwendet die GDK-CLI Version 1.0.0.

    Wenn Sie diese Option wählen, können Sie die Greengrass-CLI nicht verwenden, um die Komponente lokal auf Ihrem lokalen Entwicklungscomputer bereitzustellen und zu testen, auf dem die AWS IoT Greengrass Core-Software ausgeführt wird. Um lokale Bereitstellungen zu aktivieren, müssen Sie stattdessen eine semantische Version angeben.

  • Eine semantische Version, z. B. 1.0.0. Semantische Versionen verwenden ein Hauptversions-.Nebenversions-.Patch-Nummerierungssystem. Weitere Informationen finden Sie in der semantischen Versionsspezifikation .

    Wenn Sie Komponenten auf einem Greengrass-Core-Gerät entwickeln, auf dem Sie die Komponente bereitstellen und testen möchten, wählen Sie diese Option. Sie müssen die Komponente mit einer bestimmten Version erstellen, um lokale Bereitstellungen mit der Greengrass-CLI zu erstellen.

build

Die Konfiguration, die verwendet werden soll, um die Quelle dieser Komponente in Artefakte zu integrieren. Dieses Objekt enthält die folgenden Informationen:

build_system

Das zu verwendende Build-System. Wählen Sie aus den folgenden Optionen aus:

  • zip – Verpackt den Ordner der Komponente in eine ZIP-Datei, um als einziges Artefakt der Komponente zu definieren. Wählen Sie diese Option für die folgenden Komponententypen aus:

    • Komponenten, die interpretierte Programmiersprachen wie Python oder verwenden JavaScript.

    • Komponenten, die andere Dateien als Code verpacken, z. B. Modelle für maschinelles Lernen oder andere Ressourcen.

    Die GDK-CLI komprimiert den Ordner der Komponente in eine ZIP-Datei mit demselben Namen wie der Komponentenordner. Wenn der Name des Komponentenordners beispielsweise lautetHelloWorld, erstellt die GDK-CLI eine ZIP-Datei mit dem Namen HelloWorld.zip.

    Anmerkung

    Wenn Sie GDK CLI Version 1.0.0 auf einem Windows-Gerät verwenden, dürfen der Komponentenordner und die ZIP-Dateinamen nur Kleinbuchstaben enthalten.

    Wenn die GDK-CLI den Ordner der Komponente in eine ZIP-Datei komprimiert, überspringt sie die folgenden Dateien:

    • Die Datei gdk-config.json

    • Die Rezeptdatei (recipe.json oder recipe.yaml)

    • Erstellen von Ordnern, z. B. greengrass-build

  • maven – Führt den mvn clean package Befehl aus, um die Quelle der Komponente in Artefakte zu erstellen. Wählen Sie diese Option für Komponenten aus, die Maven verwenden, z. B. Java-Komponenten.

    Auf Windows-Geräten ist diese Funktion für GDK CLI v1.1.0 und höher verfügbar.

  • gradle – Führt den gradle build Befehl aus, um die Quelle der Komponente in Artefakte zu erstellen. Wählen Sie diese Option für Komponenten aus, die Gradle verwenden. Diese Funktion ist für GDK CLI v1.1.0 und höher verfügbar.

    Das gradle Build-System unterstützt Kotlin DSL als Build-Datei. Diese Funktion ist für GDK CLI v1.2.0 und höher verfügbar.

  • gradlew – Führt den gradlew Befehl aus, um die Quelle der Komponente in Artefakte zu erstellen. Wählen Sie diese Option für Komponenten aus, die den Gradle Wrapper verwenden.

    Diese Funktion ist für GDK CLI v1.2.0 und höher verfügbar.

  • custom – Führt einen benutzerdefinierten Befehl aus, um die Quelle der Komponente in ein Rezept und Artefakte zu integrieren. Geben Sie den benutzerdefinierten Befehl im custom_build_command Parameter an.

custom_build_command

(Optional) Der benutzerdefinierte Build-Befehl, der für ein benutzerdefiniertes Build-System ausgeführt werden soll. Sie müssen diesen Parameter angeben, wenn Sie custom für angebenbuild_system.

Wichtig

Dieser Befehl muss ein Rezept und Artefakte in den folgenden Ordnern im Komponentenordner erstellen. Die GDK-CLI erstellt diese Ordner für Sie, wenn Sie den Komponentenerstellungsbefehl ausführen.

  • Rezeptordner: greengrass-build/recipes

  • Artefakte-Ordner: greengrass-build/artifacts/componentName/componentVersion

    Ersetzen Sie componentName durch den Komponentennamen und componentVersion durch die Komponentenversion oder NEXT_PATCH.

Sie können eine einzelne Zeichenfolge oder eine Liste von Zeichenfolgen angeben, wobei jede Zeichenfolge ein Wort im Befehl ist. Um beispielsweise einen benutzerdefinierten Build-Befehl für eine C++-Komponente auszuführen, können Sie cmake --build build --config Release oder angeben["cmake", "--build", "build", "--config", "Release"].

Ein Beispiel für ein benutzerdefiniertes Build-System finden Sie unter aws.greengrass.labs.LocalWebServer community component auf GitHub.

options

(Optional) Zusätzliche Konfigurationsoptionen, die während des Komponentenerstellungsprozesses verwendet werden.

Diese Funktion ist für GDK CLI v1.2.0 und höher verfügbar.

excludes

Eine Liste von globalen Mustern, die definieren, welche Dateien beim Erstellen der ZIP-Datei aus dem Komponentenverzeichnis ausgeschlossen werden sollen. Nur gültig, wenn build_system istzip.

Anmerkung

In den GDK-CLI-Versionen 1.4.0 und früher wird jede Datei, die mit einem Eintrag in der Ausschlussliste übereinstimmt, aus allen Unterverzeichnissen der Komponente ausgeschlossen. Um dasselbe Verhalten in GDK-CLI-Versionen 1.5.0 und höher **/ zu erreichen, stellen Sie den vorhandenen Einträgen in der Ausschlussliste voran. Beispielsweise *.txt schließt Textdateien nur aus dem Verzeichnis aus; **/*.txt schließt Textdateien aus allen Verzeichnissen und Unterverzeichnissen aus.

In GDK-CLI-Versionen 1.5.0 und höher wird möglicherweise eine Warnung während des Komponentenaufbaus angezeigt, wenn in der GDK-Konfigurationsdatei definiert excludes ist. Um diese Warnung zu deaktivieren, setzen Sie die Umgebungsvariable GDK_EXCLUDES_WARN_IGNORE auf true.

Die GDK-CLI schließt immer die folgenden Dateien aus der ZIP-Datei aus:

  • Die Datei gdk-config.json

  • Die Rezeptdatei (recipe.json oder recipe.yaml)

  • Erstellen von Ordnern, z. B. greengrass-build

Die folgenden Dateien sind standardmäßig ausgeschlossen. Mit der excludes Option können Sie jedoch steuern, welche dieser Dateien ausgeschlossen werden.

  • Jeder Ordner, der mit dem Präfix „test“ (test*) beginnt

  • Alle ausgeblendeten Dateien

  • Den Ordner node_modules

Wenn Sie die excludes Option angeben, schließt die GDK-CLI nur die Dateien aus, die Sie mit der excludes Option festgelegt haben. Wenn Sie die excludes Option nicht angeben, schließt die GDK-CLI die zuvor genannten Standarddateien und Ordner aus.

zip_name

Der ZIP-Dateiname, der beim Erstellen eines ZIP-Artefakts während des Erstellungsprozesses verwendet werden soll. Nur gültig, wenn build_system istzip. Wenn leer build_system ist, wird der Komponentenname für den ZIP-Dateinamen verwendet.

publish

Die Konfiguration, die zum Veröffentlichen dieser Komponente im AWS IoT Greengrass Service verwendet werden soll.

Wenn Sie GDK CLI v1.1.0 oder höher verwenden, können Sie das Argument angeben, um den S3--bucket-Bucket anzugeben, in den die GDK CLI die Artefakte der Komponente hochlädt. Wenn Sie dieses Argument nicht angeben, lädt die GDK-CLI in den S3-Bucket hoch, dessen Name lautetbucket-region-accountId, wobei Bucket und Region die Werte sind, die Sie in angebengdk-config.json, und accountId Ihre AWS-Konto -ID ist. Die GDK-CLI erstellt den Bucket, wenn er nicht vorhanden ist.

Dieses Objekt enthält die folgenden Informationen:

bucket

Der S3-Bucket-Name, der zum Hosten von Komponentenartefakten verwendet werden soll.

region

Die AWS-Region, in der die GDK-CLI diese Komponente veröffentlicht.

Diese Eigenschaft ist optional, wenn Sie GDK CLI v1.3.0 oder höher verwenden.

options

(Optional) Zusätzliche Konfigurationsoptionen, die bei der Erstellung der Komponentenversion verwendet werden.

Diese Funktion ist für GDK CLI v1.2.0 und höher verfügbar.

file_upload_args

Eine JSON-Struktur, die Argumente enthält, die beim Hochladen von Dateien in einen Bucket an Amazon S3 gesendet werden, z. B. Metadaten und Verschlüsselungsmechanismen. Eine Liste der zulässigen Argumente finden Sie in der -S3TransferKlasse in der Boto3-Dokumentation.

test-e2e

(Optional) Die Konfiguration, die beim end-to-end Testen der Komponente verwendet werden soll. Diese Funktion ist für GDK CLI v1.3.0 und höher verfügbar.

build

build_system – Das zu verwendende Build-System. Die Standardoption ist maven. Wählen Sie aus den folgenden Optionen aus:

  • maven – Führt den mvn package Befehl aus, um das Testmodul zu erstellen. Wählen Sie diese Option zum Erstellen des Testmoduls, das Maven verwendet.

  • gradle – Führt den gradle build Befehl aus, um das Testmodul zu erstellen. Wählen Sie diese Option für das Testmodul aus, das Gradle verwendet.

gtf_version

(Optional) Die Version des Greengrass Testing Framework (GTF), die als Abhängigkeit des end-to-end Testmoduls verwendet werden soll, wenn Sie das GDK-Projekt mit GTF initialisieren. Dieser Wert muss eine der GTF-Versionen aus Versionen sein. Der Standardwert ist GTF Version 1.1.0.

gtf_options

(Optional) Zusätzliche Konfigurationsoptionen, die beim end-to-end Testen der Komponente verwendet werden.

Die folgende Liste enthält die Optionen, die Sie mit GTF Version 1.1.0 verwenden können.

  • additional-plugins – (Optional) Zusätzliche Cucumber-Plugins

  • aws-region – Zielt auf bestimmte regionale Endpunkte für -AWSServices ab. Standardmäßig ist das, was das AWS SDK erkennt.

  • credentials-path – Optionaler Pfad für AWS Profilanmeldeinformationen. Standardmäßig werden Anmeldeinformationen verwendet, die in der Hostumgebung erkannt wurden.

  • credentials-path-rotation – Optionale Rotationsdauer für AWS Anmeldeinformationen. Der Standardwert ist 15 Minuten oder PT15M.

  • csr-path – Der Pfad für die CSR, mit der das Gerätezertifikat generiert wird.

  • device-mode – Das zu testende Zielgerät. Standardmäßig ist das lokale Gerät.

  • env-stage – Zielt auf die Bereitstellungsumgebung von Greengrass ab. Der Standardwert ist Produktion.

  • existing-device-cert-arn – Der ARN eines vorhandenen Zertifikats, das Sie als Gerätezertifikat für Greengrass verwenden möchten.

  • feature-path – Datei oder Verzeichnis, das zusätzliche Feature-Dateien enthält. Standardmäßig werden keine zusätzlichen Feature-Dateien verwendet.

  • gg-cli-version – Überschreibt die Version der Greengrass-CLI. Der Standardwert ist der Wert in ggc.version.

  • gg-component-bucket – Der Name eines vorhandenen Amazon S3-Buckets, der Greengrass-Komponenten enthält.

  • gg-component-overrides – Eine Liste von Greengrass-Komponentenüberschreibungen.

  • gg-persist – Eine Liste von Testelementen, die nach einem Testlauf bestehen bleiben sollen. Das Standardverhalten besteht darin, nichts beizubehalten. Zulässige Werte sind: aws.resourcesinstalled.software, und generated.files.

  • gg-runtime – Eine Liste von Werten, die beeinflussen, wie der Test mit Testressourcen interagiert. Diese Werte ersetzen den gg.persist Parameter . Wenn der Standardwert leer ist, wird davon ausgegangen, dass alle Testressourcen von Testfällen verwaltet werden, einschließlich der installierten Greengrass-Laufzeit. Akzeptierte Werte sind: aws.resourcesinstalled.software, und generated.files.

  • ggc-archive – Der Pfad zur archivierten Greengrass-Kernkomponente.

  • ggc-install-root – Verzeichnis zur Installation der Greengrass-Kernkomponente. Standardmäßig sind test.temp.path und test run folder.

  • ggc-log-level – Legen Sie die Greengrass-Kernprotokollebene für den Testlauf fest. Der Standardwert ist „INFO“.

  • ggc-tes-rolename – Die IAM-Rolle, die AWS IoT Greengrass Core für den Zugriff auf -AWSServices übernimmt. Wenn keine Rolle mit dem angegebenen Namen vorhanden ist, wird eine erstellt und es wird eine Standardzugriffsrichtlinie verwendet.

  • ggc-trusted-plugins – Die durch Komma getrennte Liste der Pfade (auf dem Host) der vertrauenswürdigen Plugins, die Greengrass hinzugefügt werden müssen. Um den Pfad auf dem DUT selbst bereitzustellen, stellen Sie dem Pfad „dut:“ voran.

  • ggc-user-name – Der Wert user:group posixUser für den Greengrass-Kern. Standardmäßig wird der aktuelle Benutzername verwendet, der angemeldet ist.

  • ggc-version – Überschreibt die Version der ausgeführten Greengrass-Kernkomponente. Standardmäßig ist der Wert in ggc.archive angegeben.

  • log-level – Protokollebene des Testlaufs. Der Standardwert ist „INFO“.

  • parallel-config – Satz von Batch-Index und Anzahl der Batches als JSON-Zeichenfolge. Der Standardwert des Batch-Index ist 0 und die Anzahl der Batches ist 1.

  • proxy-url – Konfigurieren Sie alle Tests so, dass der Datenverkehr über diese URL geleitet wird.

  • tags – Führen Sie nur Feature-Tags aus. Kann mit „&“ überlappen

  • test-id-prefix – Ein gemeinsames Präfix, das auf alle testspezifischen Ressourcen angewendet wird, einschließlich AWS Ressourcennamen und Tags. Der Standardwert ist ein „gg“-Präfix.

  • test-log-path – Verzeichnis, das die Ergebnisse des gesamten Testlaufs enthält. Standardmäßig ist „testResults“.

  • test-results-json – Flag, um festzustellen, ob ein resultierender Cucumber-JSON-Bericht generiert wird, der auf die Festplatte geschrieben wird. Standardwert ist „true“.

  • test-results-log – Flag, um festzustellen, ob die Konsolenausgabe generiert und auf die Festplatte geschrieben wird. Standardwert "false".

  • test-results-xml – Flag, um festzustellen, ob ein resultierender JUnit-XML-Bericht generiert wird, der auf die Festplatte geschrieben wird. Standardwert ist „true“.

  • test-temp-path – Verzeichnis zum Generieren lokaler Testartefakte. Standardmäßig ist ein zufälliges temporäres Verzeichnis mit dem Präfix gg-testing.

  • timeout-multiplier – Multiplikator für alle Test-Timeouts bereitgestellt. Standard = 1.0.

Beispiele für GDK-CLI-Konfigurationsdateien

Sie können auf die folgenden Beispiele für GDK-CLI-Konfigurationsdateien verweisen, um Sie bei der Konfiguration von Greengrass-Komponentenumgebungen zu unterstützen.

Hallo Welt (Python)

Die folgende GDK-CLI-Konfigurationsdatei unterstützt eine Hello World-Komponente, die ein Python-Skript ausführt. Diese Konfigurationsdatei verwendet das zip Build-System, um das Python-Skript der Komponente in eine ZIP-Datei zu verpacken, die die GDK-CLI als Artefakt hochlädt.

{
  "component": {
    "com.example.PythonHelloWorld": {
      "author": "Amazon",
      "version": "NEXT_PATCH",
      "build": {
        "build_system" : "zip",
        "options": {
           "excludes": [".*"]
        }
      },
      "publish": {
        "bucket": "greengrass-component-artifacts",
        "region": "us-west-2",
        "options": {
           "file_upload_args": {
              "Metadata": {
                 "some-key": "some-value"
              }
           }
        }
      }
    },
  "test-e2e":{
    "build":{
        "build_system": "maven"
    },
    "gtf_version": "1.1.0",
    "gtf_options": { 
         "tags": "Sample"
     }
  },
  "gdk_version": "1.6.1"
  }
}

Hallo Welt (Java)

Die folgende GDK-CLI-Konfigurationsdatei unterstützt eine Hello World-Komponente, die eine Java-Anwendung ausführt. Diese Konfigurationsdatei verwendet das maven Build-System, um den Java-Quellcode der Komponente in eine JAR-Datei zu verpacken, die die GDK-CLI als Artefakt hochlädt.

{
  "component": {
    "com.example.JavaHelloWorld": {
      "author": "Amazon",
      "version": "NEXT_PATCH",
      "build": {
        "build_system" : "maven"
      },
      "publish": {
        "bucket": "greengrass-component-artifacts",
        "region": "us-west-2",
        "options": {
           "file_upload_args": {
              "Metadata": {
                 "some-key": "some-value"
              }
           }
        }
      }
  },
  "test-e2e":{
    "build":{
        "build_system": "maven"
    },
    "gtf_version": "1.1.0",
    "gtf_options": { 
         "tags": "Sample"
     }
  },
  "gdk_version": "1.6.1"
  }
}

Community-Komponenten

Mehrere Community-Komponenten im Greengrass Software Catalog verwenden die GDK-CLI. Sie können die GDK-CLI-Konfigurationsdateien in den Repositorys dieser Komponenten untersuchen.

So zeigen Sie die GDK-CLI-Konfigurationsdateien der Community-Komponenten an

  1. Führen Sie den folgenden Befehl aus, um die Community-Komponenten aufzulisten, die die GDK-CLI verwenden.

    gdk component list --repository

    Die Antwort listet den Namen des GitHub Repositorys für jede Community-Komponente auf, die die GDK-CLI verwendet. Jedes Repository ist in der awslabs Organisation vorhanden.

    [2022-02-22 17:27:31] INFO - Listing all the available component repositories from Greengrass Software Catalog.
[2022-02-22 17:27:31] INFO - Found '6' component repositories to display.
1. aws-greengrass-labs-database-influxdb
2. aws-greengrass-labs-telemetry-influxdbpublisher
3. aws-greengrass-labs-dashboard-grafana
4. aws-greengrass-labs-dashboard-influxdb-grafana
5. aws-greengrass-labs-local-web-server
6. aws-greengrass-labs-lookoutvision-gstreamer

  2. Öffnen Sie das GitHub Repository einer Community-Komponente unter der folgenden URL. Ersetzen Sie durch community-component-name den Namen einer Community-Komponente aus dem vorherigen Schritt.

    https://github.com/awslabs/community-component-name