5 Tipps zum Entwickeln von AWS IoT Greengrass v2-Komponenten

AWS IoT Greengrass v2, angekündigt im Dezember 2020, ist eine Open Source Laufzeitumgebung, mit der Sie Edge Software erstellen, bereitstellen und verwalten, sowie lokal auf die Daten reagieren können, die Ihre intelligenten IoT-Geräte erfassen. Sie können beispielsweise Modelle für maschinelles Lernen zur Datenvorhersage ausführen, Gerätedaten nach Belieben filtern und aggregieren oder vorgefertigte Softwarekomponenten, Funktionen und Tools verwenden, um Ihre Geräteflotten effektiv und in großem Maßstab zu verwalten.

Mit den AWS IoT Greengrass-Komponenten, die aus Anwendungs- und Laufzeitbibliotheken bestehen, können Sie benutzerdefinierte Anwendungen entwickeln, sie testen und auf Ihrem AWS IoT Greengrass-Core-Gerät bereitstellen, was Ihnen mehr Flexibilität gegenüber AWS IoT Greengrass v1 bietet. Darüber hinaus können Komponenten außerhalb von Containern ausgeführt werden (neu in 2.0), sodass Sie direkt mit lokalen Ressourcen auf Ihren Core-Geräten arbeiten können. In AWS IoT Greengrass v1 definieren AWS Lambda Funktionen außerdem die Software, die auf Core-Geräten ausgeführt wird, während in AWS IoT Greengrass v2 die Komponenten aus jeder von Ihnen definierten Softwareanwendung bestehen können.

Jede Komponente besteht aus einem Rezept und Artefakten. Die Rezeptdatei definiert die Metadaten der Komponente. Dazu gehören die Konfigurationsparameter, Komponentenabhängigkeiten, der Lebenszyklus und die Plattformkompatibilität der Komponente. Der Lebenszyklus definiert die Befehle zum Installieren, Ausführen und Herunterfahren der Komponente. Das Rezept kann im YAML- und JSON-Format definiert werden. Artefakte sind optional und bestehen aus Komponentenbinärdateien. Sie können Skripts, kompilierten Code, statische Ressourcen und alle anderen Dateien enthalten, die eine Komponente verwendet.

In diesem Beitrag teilen wir 5 Tipps, die Sie bei der Entwicklung von AWS IoT Greengrass v2-Komponenten berücksichtigen sollten. Diese Tipps und Erkenntnisse können Ihnen helfen, Mechanismen für die Strukturierung der AWS IoT Greengrass-Komponenten zu definieren. Außerdem hilft Ihnen dieser Prozess, Ihren Entwicklungsablauf zu beschleunigen und zu verbessern und schneller mit der Komponentenentwicklung zu beginnen.

Die Voraussetzungen zum Folgen dieses Beitrags sind:

Sie haben ein voll funktionsfähiges AWS-Benutzerkonto. Anweisungen zur Einrichtung finden Sie in unserer Dokumentation.
Sie haben eine Maschine, auf der AWS IoT Greengrass installiert und voll funktionsfähig ist. Wenn Sie dies noch nicht getan haben, folgen Sie den Installationsanweisungen.

Lassen Sie uns anfangen.

1) Verwenden Sie die Befehle des Command Line Interfaces (CLI)

Während der Komponentenentwicklung gibt es einige CLI-Befehle, die Ihnen schnelle und einfache Einblicke in den aktuellen Status der AWS IoT Greengrass Core-Software und Ihrer Komponenten geben. Alle Befehle in diesem Blogbeitrag beziehen sich auf Linux- oder Unix-basierte Systeme. Wenn Sie ein anderes Betriebssystem verwenden, passen Sie diese entsprechend an.

Standardmäßig schreibt die AWS IoT Greengrass Core-Software Protokolle nur auf das lokale Dateisystem. Sie können Dateisystemprotokolle in Echtzeit einsehen, um Ihre AWS IoT Greengrass-Komponenten zu debuggen. Es gibt zwei Protokolltypen, die besonders wichtig sind:

Die Logdatei der AWS IoT Greengrass Core-Software. Sie enthält Echtzeitinformationen über Komponenten und Bereitstellungen. Dies ist der erste Ort, an dem Sie nachschauen sollten, wenn Sie eine Bereitstellung starten und wissen möchten, was vor sich geht. Die Fehlermeldungen in der Protokolldatei könnten Ihnen dann bei der Behebung helfen. Da das Verzeichnis der Logfiles root gehört, verwenden wir sudo, um auf diese Dateien zuzugreifen.
```
$ sudo tail -F /greengrass/v2/logs/greengrass.log
```
Protokolldateien der AWS IoT Greengrass-Komponenten. Diese Dateien enthalten Echtzeitinformationen über die entsprechende Komponente, die auf dem Gerät ausgeführt wird. Generische Komponenten und Lambda-Komponenten schreiben Standard-Stdout und -Stderr in diese Protokolldateien. Mit Ihren eigenen Komponenten können Sie diese Funktionen nach Ihren Bedürfnissen verwenden.
```
$ sudo tail -F /greengrass/v2/logs/<Name der Komponente>.log
# Konkretes Beispiel: Ihre Komponente heißt ggv2.custom-comp.logging
$ sudo tail -F /greengrass/v2/logs/ggv2.custom-comp.logging.log
```

Um bessere Einblicke in Komponenten und ihren Status zu erhalten, gibt es einige sehr nützliche AWS IoT Greengrass CLI-Befehle zum Auflisten und Neustarten von Komponenten. Bevor Sie die Befehle verwenden können, müssen Sie zuerst die AWS IoT Greengrass CLI installieren (folgen Sie dazu den Anweisungen weiter unten in diesem Blog). Der list Befehl gibt den Namen der Komponente, ihre Version und ihren aktuellen Status aus.

$ sudo /greengrass/v2/bin/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

Wenn Sie eine Komponente neu starten, verwendet das Core-Gerät die neuesten Änderungen.

$ sudo /greengrass/v2/bin/greengrass-cli component restart \
--names "<Name der Komponente>"
# Konkretes Beispiel: Ihre Komponente heißt ggv2.custom-comp.logging-1.0.1
$ sudo /greengrass/v2/bin/greengrass-cli component restart \
--names "ggv2.custom-comp.logging-1.0.1"

In diesen Links erhalten Sie weitere Informationen zur Aktivierung der Protokollierung in Amazon CloudWatch sowie zu nützlichen AWS IoT Greengrass-CLI-Befehlen.

2) Komponenten lokal entwickeln

Für eine optimale Erfahrung bei der Entwicklung von Komponenten empfehlen wir, dies lokal zu tun und die Komponente dann in der Cloud zu erstellen, um sie auf Ihren AWS IoT Greengrass Core-Geräten bereitzustellen. Lassen Sie uns einen vereinfachten Entwicklungsprozess für unsere Beispielkomponente ggv2.custom-comp.logging durchführen. Wir können diese entwickelte Komponente später verwenden, um sie in der Cloud zu veröffentlichen und auf Core-Geräten bereitzustellen.

A/ Ordnerstruktur

Schauen wir uns die Ordnerstruktur an, die in diesem Blogbeitrag für unsere Beispielkomponente ggv2.custom-comp.logging verwendet wurde:

~                                           <-- Ihre Umgebung
├── GreengrassDev/
│   ├── deployment.json
│   └── components
│       └── ggv2.custom-comp.logging
│           └── recipes
│              └── ggv2.custom-comp.logging.yaml
│           └── artifacts
│              └── ggv2.custom-comp.logging
│                 └── 1.0.0
│                    └── src
│                       └── script.py
│                    └── main.py
├── GreengrassCore                          <-- GreengrassCore Installation
└── README.md

Neben dem GreengrassCore-Verzeichnis, das bei der Installation der AWS IoT Greengrass Core-Software erstellt wird, erstellen wir ein GreenrassDev-Verzeichnis mit der Unterverzeichnis components, das die Ordner recipes und artifacts enthält. Für unsere Artefakte ist es wichtig, dass die Struktur artifacts/<Name der Komponente>/<Version der Komponente> eingehalten wird.

B/ Erste Bereitstellung einschließlich AWS IoT Greengrass CLI

Um die AWS IoT Greengrass CLI nutzen zu können, müssen wir eine Datei deployment.json mit dem folgenden Inhalt erstellen:

{
   "targetArn": "arn:aws:iot:<region>:<account-id>:thing/<thing-name>",
   "deploymentName": "gg-iot-ggv2-bp-deployment",
   "components": {
      "aws.greengrass.Nucleus": {
         "componentVersion": "2.5.3"
      },
      "aws.greengrass.Cli": {
         "componentVersion": "2.5.3"
      }
   }
}

Ersetzen Sie die Platzhalter für Ihre Region, Ihr Konto und Ihren Namen durch Ihre tatsächlichen Werte. In den folgenden Beispielen gehen wir davon aus, dass die Region eu-central-1, die Konto-ID 123456789 und der Name des Core-Geräts aws-iot-ggv2-bp-core lauten. Sie haben auch die Möglichkeit, Gruppen von Core-Geräten in Ihrer Bereitstellung anzusprechen, wodurch es einfach ist, Software auf mehreren Geräten auf dem neuesten Stand zu halten. Dies ist eine der Funktionen, die mit AWS IoT Greengrass v2 eingeführt wurden, um das Kundenerlebnis zu verbessern. In der Datei deployment.json kann der targetArn also auf den Amazon-Ressourcennamen (ARN) einer Sache oder einer Gruppe verweisen.

Wir verwenden wir die AWS-CLI um eine Bereitstellung in der Cloud zu erstellen:

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

Prüfen Sie in der Konsole (oder in den Protokollen), ob die Bereitstellung erfolgreich war.

C/ Entwicklungshelfer: Umgebungsvariablen und Funktionen

Lassen Sie uns alle wichtigen Aspekte rund um unsere Komponente, ihre Version und Ordnerstruktur definieren:

$ export COMPONENT_NAME="ggv2.custom-comp.logging"
$ export COMPONENT_VERSION="1.0.0"
$ export RECIPE_DIR="~/GreengrassDev/components/${COMPONENT_NAME}/recipes"
$ export ARTIFACT_DIR="~/GreengrassDev/components/${COMPONENT_NAME}/artifacts"

Um unseren lokalen Entwicklungsprozess zu vereinfachen, erstellen wir zwei Hilfsfunktionen. Die Hilfsfunktion gg_deploy verwendet die exportierten Variablen und erstellt eine Bereitstellung für unsere angegebene COMPONENT_VERSION. Die zweite Hilfsfunktion gg_delete löscht alle zuvor erstellten Komponentenversionen. Anstatt die Versionen bei jeder neuen Bereitstellung zu aktualisieren, löschen wir mit dieser Funktion die zuvor erstellte Komponentenversion, sodass wir die neue Version anschließend mit derselben spezifizierten COMPONENT_VERSION bereitstellen können. In beiden Funktionen verwenden wir die AWS IoT Greengrass CLI deployment create-Befehle mit unterschiedlichen Parametern.

#Deploy Hilfsfunktion
$ gg_deploy(){
sudo /greengrass/v2/bin/greengrass-cli deployment create \
--recipeDir $RECIPE_DIR --artifactDir $ARTIFACT_DIR \
--merge "$COMPONENT_NAME=$COMPONENT_VERSION";
}

#Remove Hilfsfunktion
$ gg_delete(){
sudo /greengrass/v2/bin/greengrass-cli --ggcRootPath /greengrass/v2 deployment create \
--remove "$COMPONENT_NAME";
}

Schauen wir uns die Dateien in unserem Ordner artifacts (~/GreengrassDev/components/artifacts/ggv2.custom-comp.logging/1.0.0) an, das sind unsere main.py und die script.py, die sich in unserem src-Ordner befinden. Der Code in script.py sieht so aus (dies ist ein vereinfachtes Beispiel):

import datetime
import time

def loopfunction():
    while True:
        message = f"Hallo! Aktuelle Zeit: {str(datetime.datetime.now())}."
    
        # Ausgeben der Nachricht nach stdout.
        print(message)
        
        time.sleep(1)

Sowie unsere Hauptfunktion in main.py:

import sys
import src.script as helloworld

def main():
    helloworld.loopfunction()

if __name__ == "__main__":
    main()

Außerdem lautet der Inhalt Ihrer Rezeptdatei ggv2.custom-comp.logging.yaml:

---
RecipeFormatVersion: "2020-01-25"
ComponentName: "{COMPONENT_NAME}"
ComponentVersion: "{COMPONENT_VERSION}"
ComponentDescription: "Beispielkomponente"
ComponentPublisher: "Ich"
Manifests:
  - Platform:
      os: linux
    Lifecycle:
      Run: "python3 -u {artifacts:path}/main.py"

Ein Beispielprozess für unsere Komponente mit zwei Änderungen, die schrittweise erfolgen, könnte wie folgt aussehen:

# Ersetzen Sie den korrekten Komponentennamen und die Version in der Rezeptdatei
$ sed -i 's/{COMPONENT_NAME}/'"$COMPONENT_NAME"'/g' $RECIPE_DIR/$COMPONENT_NAME.yaml
$ sed -i 's/{COMPONENT_VERSION}/'"$COMPONENT_VERSION"'/g' $RECIPE_DIR/$COMPONENT_NAME.yaml
# Deploy Hilfsfunktion
$ gg_deploy
# Führen Sie Änderungen in script.py durch
$ gg_delete
$ gg_deploy
# Führen Sie Änderungen in script.py und der Rezeptdatei durch
$ gg_delete
$ gg_deploy
# Sobald wir fertig und glücklich mit unserer entwickelten Version sind, können wir in die Cloud bereitstellen
# Ich empfehle, ein letztes Mal gg_delete durchzuführen, um eine Diskrepanz in den Versionen zu vermeiden
$ gg_delete

Damit ist das Segment zur lokalen Entwicklung abgeschlossen. Wir erstellen die Komponente in der Cloud und stellen sie auf den Core-Geräten bereit.

3) Erstellen Sie die Komponente in der Cloud und stellen Sie sie mithilfe des AWS IoT Greengrass Development Kit (GDK) auf Core-Geräten bereit

Um den Entwicklungsprozess für benutzerdefinierte Komponenten zu vereinfachen, hat AWS die AWS IoT Greengrass Development Kit (GDK) -CLI veröffentlicht, die unter der Apache-2.0-Lizenz als Open Source verfügbar ist. Sie hilft Ihnen, benutzerdefinierte Komponenten zu entwickeln, zu erstellen und zu veröffentlichen. Unter den Links finden Sie die Voraussetzungen für die Verwendung der AWS GDK CLI sowie den Installationsvorgang.

Schauen wir uns hier den Entwicklungsprozess an. Verwenden Sie zunächst entweder eine Vorlage oder eine Community-Komponente. In unserem Fall verwenden wir Hilfsfunktionen und Umgebungsvariablen, um unsere zuvor entwickelte, lokale Komponente als Grundlage für die Erstellung und Veröffentlichung mit dem GDK zu verwenden. Die AWS IoT GDK CLI aktualisiert die Version und die Artefakt-URIs jedes Mal für Sie, wenn Sie eine neue Version der Komponente veröffentlichen.

#GDK Hilfsfunktion vorbereiten
$ gg_gdk_prepare(){
mkdir -p $RECIPE_DIR/../greengrass-gdk-prepare/$COMPONENT_NAME && cd "$_"
cp -a $ARTIFACT_DIR/$COMPONENT_NAME/$COMPONENT_VERSION/. .

cp -a $RECIPE_DIR/$COMPONENT_NAME.yaml ./recipe.yaml
sed -i 's/'"$COMPONENT_VERSION"'/{COMPONENT_VERSION}/g' recipe.yaml
sed -i 's/{artifacts:path}/{artifacts:decompressedPath}\/'"$COMPONENT_NAME"'/g' recipe.yaml

touch gdk-config.json
}
# Funktion ausführen
$ gg_gdk_prepare

Bevor wir die Komponente erstellen, müssen wir nun die Rezeptdatei aktualisieren, sodass sie auf den Amazon S3-Bucket verweist, indem wir den Abschnitt Artifacts zum Manifest-Teil der Datei recipe.yaml hinzufügen:

---
RecipeFormatVersion: "2020-01-25"
ComponentName: "ggv2.custom-comp.logging"
ComponentVersion: "{COMPONENT_VERSION}"
ComponentDescription: "Beispielkomponente"
ComponentPublisher: "Ich"
Manifests:
  - Platform:
      os: linux
    Artifacts:
      - URI: "s3://BUCKET_NAME/COMPONENT_NAME/COMPONENT_VERSION/ggv2.custom-comp.logging.zip"
        Unarchive: ZIP
    Lifecycle:
      Run: "python3 -u {artifacts:decompressedPath}/ggv2.custom-comp.logging/main.py"

Lassen Sie uns abschließend den folgenden Code in die Datei gdk-config.json kopieren. Ersetzen Sie alle PLATZHALTER durch die tatsächlichen Werte:

{
  "component": {
    "<PLATZHALTER_KOMPONENTENNAME>": {
      "author": "Ich",
      "version": "NEXT_PATCH",
      "build": {
        "build_system": "zip"
      },
      "publish": {
        "bucket": "<PLATZHALTER_BUCKET>",
        "region": "<PLATZHALTER_REGION>"
      }
    }
  },
  "gdk_version": "1.0.0"
}

Alternativ können Sie die Region und den Bucket in Umgebungsvariablen exportieren und dann die Funktion gg_gdk_substitute verwenden:

#Bestehender S3 Bucket, in den GDK die Artefakte hochlädt
$ export BUCKET_NAME="ggv2-blogpost-XXXXXXXXXX"
$ export REGION="eu-central-1"

#GDK Hilfsfunktion vorbereiten
$ gg_gdk_substitute(){
sed -i 's/<PLATZHALTER_KOMPONENTENNAME>/'"$COMPONENT_NAME"'/g' gdk-config.json
sed -i 's/<PLATZHALTER_BUCKET>/'"$BUCKET_NAME"'/g' gdk-config.json
sed -i 's/<PLATZHALTER_REGION>/'"$REGION"'/g' gdk-config.json
}

#Funktion ausführen
$ gg_gdk_substitute

Der nächste Schritt besteht darin, die Befehle build (gdk component build) und publish (gdk component publish) auszuführen, was dazu führt, dass die Komponente als benutzerdefinierte Komponente in Ihrem eigenen AWS-Konto veröffentlicht wird. Ausführlichere Anweisungen und Erklärungen finden Sie auf der Dokumentationsseite. Der letzte Schritt ist, die Komponente in unserem Core bereitzustellen, wofür wir die Datei deployment.json und die AWS-CLI verwenden.

{
    "targetArn": "arn:aws:iot:eu-central-1:123456789:thing/aws-iot-ggv2-bp-core",
    "deploymentName": "gg-iot-ggv2-bp-deployment",
    "components": {
        "aws.greengrass.Nucleus": {
            "componentVersion": "2.9.2"
        },
        "aws.greengrass.Cli": {
            "componentVersion": "2.9.2"
        },
        "ggv2.custom-comp.logging": {
            "componentVersion": "1.0.0"
        }
    }
}

$ aws greengrassv2 create-deployment --cli-input-json file://~/GreengrassDev/deployment.json

Sie können den Status Ihrer Bereitstellung jederzeit überwachen, indem Sie die Protokolldateien verfolgen und alle laufenden Komponenten auflisten.

Wenn Sie eine PackageDownloadException mit dem Grund Failed to head artifact object from S3 erhalten, müssen Sie die Berechtigung Ihres Rollenalias anpassen (Der Rollenalias benötigt Leserechte für Ihren S3-Bucket, der die Artefakt-Dateien speichert). Weitere Informationen finden Sie in Abschnitt 4 dieses Blogbeitrags.

4) Verstehen Sie die Berechtigungen in AWS IoT Greengrass v2

Es gibt drei wichtige Aspekte in Bezug auf Berechtigungen, die Sie beachten müssen:

Der AWS IoT-Rollenalias: Wird verwendet, wenn der AWS IoT Greengrass Core und die bereitgestellten Komponenten mit Diensten außerhalb von AWS IoT interagieren.
Interprocess Communication (IPC) -Autorisierung für Komponenten, wenn diese mit dem Nucleus und anderen AWS IoT Greengrass-Komponenten interagieren möchten.
Das Objekt und das beigefügte Zertifikat des AWS IoT Greengrass Core-Geräts: Wird verwendet, um anzugeben, was das AWS IoT Greengrass Core Thing innerhalb von AWS IoT tun darf. Dazu gehört auch die Erlaubnis, den AWS IoT Role Alias anzunehmen. Weitere Informationen zu den AWS IoT Core-Richtlinien finden Sie in unserer Dokumentation.

Da die ersten beiden Konzepte spezifisch für AWS IoT Greengrass v2 sind, gehen wir in den nächsten beiden Unterkapiteln näher darauf ein.

A/ AWS IoT-Rollenalias

Geräte verwenden ihre X.509-Zertifikate, um temporäre AWS-Anmeldeinformationen zu erhalten, indem sie die Dienste des Credential Providers aufrufen. Dadurch entfällt die Notwendigkeit, die AWS-Zugriffsschlüssel-ID und die geheime Zugriffsschlüssel-ID auf dem AWS IoT Greengrass Core-Gerät zu speichern. Der AWS IoT-Rollenalias innerhalb von AWS IoT Core verweist auf die AWS Identity and Access Management (IAM)-Rolle, die es AWS IoT Greengrass ermöglicht, mit Diensten außerhalb von AWS IoT zu kommunizieren (Standard-Rollenalias: GreengrassV2TokenExchangeRoleAlias). Weitere Informationen finden Sie unter Autorisieren von Direktanrufen zu AWS-Services im AWS IoT Core Developer Guide.

Das Hochladen von Artefakten auf S3 und das Bereitstellen Ihrer Komponente auf Ihrem Gerät von der Cloud aus ist normalerweise der erste Punkt, an dem sie Berechtigungen benötigen. Damit Ihr Gerät die S3-Artefakte herunterladen kann, muss die IAM-Rolle s3:GetObject-Berechtigungen für den Bucket gewähren, in den Ihre Artefakte hochgeladen wurden. Ausführlichere Informationen zu Berechtigungen sowie zu den standardmäßig zulässigen Vorgängen finden Sie in der Dokumentation zur Geräterolle. Wenn Docker verwendet wird, müssen Sie zusätzlich Zugriff auf Amazon Elastic Container Registry (ECR) gewähren.

B/ Kommunikationsberechtigungen zwischen Prozessen

Wenn Sie Ihren Komponenten die Interaktion mit anderen Komponenten, dem Greengrass-Nucleus oder AWS IoT Core ermöglichen möchten, müssen sie Interprocess Communication (IPC) verwenden. Dazu muss die Genehmigung für diese Kommunikation auf Komponentenebene innerhalb der Rezeptdatei erfolgen.

Der AccessControl-Abschnitt innerhalb des Rezepts kann dann um Blöcke erweitert werden, die die verschiedenen IPC-Dienstkennungen betreffen:

{
  "accessControl": {
    "<IPC Dienstbezeichner>": {
      "<eindeutiger Bezeichner>": {
        "policyDescription": "Erlaube Zugriff auf [...]",
        "operations": [
          "<Vorgang 1>",
          "<Vorgang 2>"
        ],
        "resources": [
          "*"
        ]
      }
    }
  }
}

Informationen zu den verschiedenen IPC-Dienstbezeichnern sowie zu den Vorgängen finden Sie in der Dokumentation. Schauen wir uns unsere Komponente ggv2.custom-comp.logging an. Nehmen wir an, dass die Komponente in einem AWS IoT Core-Cloud-Thema namens dt/sensorA/temperature veröffentlichen und das lokale Thema dt/sensorB/buttonvalue abonnieren möchte. Dann würde unsere aktualisierte Rezeptdatei von zuvor so aussehen:

---
RecipeFormatVersion: "2020-01-25"
ComponentName: "ggv2.custom-comp.logging"
ComponentVersion: "1.0.0"
ComponentDescription: " Beispielkomponente"
ComponentPublisher: "Ich"
ComponentConfiguration:
  DefaultConfiguration:
    accessControl:
      aws.greengrass.ipc.pubsub:
        'ggv2.custom-comp.logging:pubsub:1':
          policyDescription: Erlaubt Zugriff zum Abonnieren des lokalen Themas dt/sensorB/buttonvalue.
          operations:
            - 'aws.greengrass#SubscribeToTopic'
          resources:
            - 'dt/sensorB/buttonvalue'
      aws.greengrass.ipc.mqttproxy:
        'ggv2.custom-comp.logging:mqttproxy:1':
          policyDescription: Erlaubt Zugriff zum Veröffentlichen im Cloud Thema dt/sensorA/temperature.
          operations:
            - 'aws.greengrass#PublishToIoTCore
          resources:
            - 'dt/sensorA/temperature'
Manifests:
  - Platform:
      os: linux
    Artifacts:
      - URI: "s3://BUCKET_NAME/COMPONENT_NAME/COMPONENT_VERSION/ggv2.custom-comp.logging.zip"
        Unarchive: ZIP
    Lifecycle:
      Run: "python3 -u {artifacts:decompressedPath}/ggv2.custom-comp.logging/main.py"

In Ihrem accessControl-Bereich können Sie Platzhalter verwenden. Innerhalb eines bestimmten IPC-Dienstbezeichners bedeutet die Verwendung eines *-Platzhalters im Operationsabschnitt, dass alle Operationen innerhalb dieser IPC-Dienst-ID zulässig sind. Das Gleiche gilt für Ressourcen: Die Verwendung eines Platzhalters in diesem Abschnitt ermöglicht die angegebenen Operationen für alle Themen. Weitere Informationen zu den einzelnen IPC-Diensten finden Sie in der Dokumentation.

5) Verstehen Sie den Prozess der Aktualisierung der Komponentenkonfiguration

Schauen wir uns an, wie Aktualisierungen der Komponentenkonfiguration funktionieren. Die allgemeinen Konfigurationsupdates führen die alte Konfiguration mit den neuen zusammen, was eine dieser Folgen haben kann:

Sie fügen einen neuen Schlüssel mit einem neuen Wert hinzu. Dieser Schlüssel und Wert werden dann der vorhandenen Konfiguration mit den vorhandenen Feldern hinzugefügt.
Sie haben einen vorhandenen Schlüssel, der einen Zeichenfolgen- oder Zahlenwert hat. Wenn Sie diesen Wert ändern, enthält die neue Konfiguration den alten Schlüssel mit seinem neuen Wert.
Sie haben einen vorhandenen Schlüssel, der ein JSON-Unterelement enthält, in dem Sie einen neuen Wert angeben. Dann verweist der alte Schlüssel auf das alte JSON, zu dem ein neues Feld hinzugefügt wurde, das Ihr neuer Wert ist.
Um einen Schlüssel aus der Konfiguration zu entfernen, müssen Sie die Reset-Funktion verwenden.

Nehmen wir ein vereinfachtes Beispiel für das Zusammenführen von Komponenten:

Bestehende Konfiguration Aktualisierung der Konfiguration Effektive Konfiguration

{
"Schlüssel1":{
"Unterschlüssel_1a":"Wert1a",
"Unterschlüssel_1b":"Wert1b"
},
"Schlüssel2":"Wert2"
}

{
"Schlüssel1":{
"Unterschlüssel_1b":"neuer_Wert1b"
}
}

{
"Schlüssel1":{
"Unterschlüssel_1a":"Wert1a",
"Unterschlüssel_1b":"neuer_Wert1b"
},
"Schlüssel2":"Wert2"
}

Schauen wir uns ein anderes Beispiel an:

Bestehende Konfiguration Aktualisierung der Konfiguration Effektive Konfiguration

{
"Schlüssel1":{
"Unterschlüssel_1a":"Wert1a",
"Unterschlüssel_1b":"Wert1b"
},
"Schlüssel2":"Wert2"
}

{
"Schlüssel1":"neue_Zeichenfolge1"
}

{
"Schlüssel1":"neue_Zeichenfolge1",
"Schlüssel2":"Wert2"
}

Wenn Sie eine Komponentenkonfiguration oder ein Unterfeld löschen möchten, müssen Sie die reset-Funktion verwenden. Sie müssen auch einen JSON-Zeiger verwenden, um die Felder zu adressieren, die Sie auf den Standardwert zurücksetzen oder löschen möchten.

Bestehende Konfiguration Aktualisierung der Konfiguration Effektive Konfiguration

{
"Schlüssel1":{
"Unterschlüssel_1a":"Wert1a",
"Unterschlüssel_1b":"Wert1b"
},
"Schlüssel2":"Wert2"
}

"configurationUpdate": {
"reset": ["/Schlüssel2"]
}

{
"Schlüssel1":{
"Unterschlüssel_1a":"Wert1a",
"Unterschlüssel_1b":"Wert1b"
}
}

Lassen Sie uns das alles im nächsten Beispiel zusammenfassen, das Zusammenführen und Zurücksetzen in einem configurationUpdate kombiniert:

Bestehende Konfiguration Aktualisierung der Konfiguration Effektive Konfiguration

{
"Schlüssel1":{
"Unterschlüssel_1a":"Wert1a",
"Unterschlüssel_1b":"Wert1b"
},
"Schlüssel2":"Wert2"
}

"configurationUpdate": {
"reset": ["/Schlüssel1/Unterschlüssel_1a"],
"merge": "{\"Schlüssel3\":\"Wert3\"}
}

{
"Schlüssel1":{
"Unterschlüssel_1b":"Wert1b"
},
"Schlüssel2":"Wert2",
"Schlüssel3":"Wert3"
}

Wenn wir die gesamte Konfiguration vollständig zurücksetzen möchten, müssen wir eine einzelne leere Zeichenfolge als Reset-Update angeben:

Bestehende Konfiguration	Aktualisierung der Konfiguration	Effektive Konfiguration
`{ "Schlüssel1":{ "Unterschlüssel_1a":"Wert1a", "Unterschlüssel_1b":"Wert1b" }, "Schlüssel2":"Wert2" }`	`"configurationUpdate": { "reset": [""] }`	`{}`

Wenn Sie mehr darüber erfahren möchten, lesen Sie den Entwicklerleitfaden zu Merge-Updates.

Aufräumen

Folgen Sie den Anweisungen in der Dokumentation, um die AWS IoT Greengrass Core-Software zu deinstallieren und das Core-Gerät aus dem AWS IoT Greengrass-Service zu löschen.

Fazit

In diesem Blogbeitrag haben wir fünf Tipps zur Entwicklung von AWS IoT Greengrass v2-Komponenten vorgestellt. Diese Tipps und Erkenntnisse können Ihnen helfen, Mechanismen zur Strukturierung von AWS IoT Greengrass-Komponenten zu entwickeln und Ihren Entwicklungsablauf zu beschleunigen und zu verbessern.

Zu diesen Tipps gehören einige hilfreiche CLI-Befehle, wie Sie Komponenten zuerst lokal entwickeln und dann die AWS GDK CLI für deren Veröffentlichung verwenden. Wir haben auch die Rechteverwaltung und den Prozess der Aktualisierung der Komponentenkonfiguration besprochen.

Weitere Informationen zu AWS IoT Greengrass v2 finden Sie in der Dokumentation und im Entwicklerhandbuch.

AWS Germany – Amazon Web Services in Deutschland

5 Tipps zum Entwickeln von AWS IoT Greengrass v2-Komponenten

1) Verwenden Sie die Befehle des Command Line Interfaces (CLI)

2) Komponenten lokal entwickeln

A/ Ordnerstruktur

B/ Erste Bereitstellung einschließlich AWS IoT Greengrass CLI

C/ Entwicklungshelfer: Umgebungsvariablen und Funktionen

3) Erstellen Sie die Komponente in der Cloud und stellen Sie sie mithilfe des AWS IoT Greengrass Development Kit (GDK) auf Core-Geräten bereit

4) Verstehen Sie die Berechtigungen in AWS IoT Greengrass v2

A/ AWS IoT-Rollenalias

B/ Kommunikationsberechtigungen zwischen Prozessen

5) Verstehen Sie den Prozess der Aktualisierung der Komponentenkonfiguration

Aufräumen

Fazit