AWS IoT Greengrass Version 1 est entré dans la phase de durée de vie prolongée le 30 juin 2023. Pour plus d'informations, consultez la politique de AWS IoT Greengrass V1 maintenance. Après cette date, AWS IoT Greengrass V1 ne publiera pas de mises à jour fournissant des fonctionnalités, des améliorations, des corrections de bogues ou des correctifs de sécurité. Les appareils qui fonctionnent AWS IoT Greengrass V1 sous tension ne seront pas perturbés et continueront à fonctionner et à se connecter au cloud. Nous vous recommandons vivement de migrer vers AWS IoT Greengrass Version 2, qui ajoute de nouvelles fonctionnalités importantes et prend en charge des plateformes supplémentaires.
Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Configuration de AWS IoT Greengrass Core
Un AWS IoT Greengrass cœur est un AWS IoT objet (appareil) qui agit comme un hub ou une passerelle dans les environnements périphériques. Comme les autres appareils AWS IoT, un noyau existe dans le registre, possède un shadow d'appareil et utilise un certificat d'appareil pour s'authentifier auprès d'AWS IoT Core et de AWS IoT Greengrass. L'appareil principal exécute le logiciel AWS IoT Greengrass Core, ce qui lui permet de gérer les processus locaux pour les groupes Greengrass, tels que la communication, la synchronisation de shadows et l'échange de jetons.
Le logiciel AWS IoT Greengrass Core fournit les fonctionnalités suivantes :
-
Déploiement et exécution locale de connecteurs et de fonctions Lambda.
-
Traitez les flux de données localement avec des exportations automatiques vers leAWS Cloud.
-
Messagerie MQTT sur le réseau local entre les appareils, les connecteurs et les fonctions Lambda à l'aide d'abonnements gérés.
-
Messagerie MQTT entre appareils, connecteurs AWS IoT et fonctions Lambda à l'aide d'abonnements gérés.
-
Connexions sécurisées entre les appareils et AWS Cloud utilisation de l'authentification et de l'autorisation des appareils.
-
Synchronisation cachée locale des appareils. Les ombres peuvent être configurées pour être synchronisées avecAWS Cloud.
-
Accès contrôlé à l'appareil local et aux ressources de volume.
-
Déploiement de modèles d'apprentissage automatique formés dans le cloud pour exécution de l'inférence locale.
-
Détection automatique d'adresse IP qui permet aux appareils de détecter votre appareil Greengrass principal.
-
Déploiement central de nouvelles configurations de groupe ou mises à jour. Une fois les données de configuration téléchargée, l'appareil principal redémarre automatiquement.
-
Mises à jour logicielles sécurisées over-the-air (OTA) des fonctions Lambda définies par l'utilisateur.
-
Stockage sécurisé et crypté des secrets locaux et accès contrôlé par des connecteurs et des fonctions Lambda.
Fichier de configuration de AWS IoT Greengrass Core
Le fichier de configuration du logiciel AWS IoT Greengrass Core est config.json. Il est placé dans le répertoire /.greengrass-root/config
Note
greengrass-root indique le chemin d'installation du logiciel AWS IoT Greengrass Core sur votre appareil. Généralement, il s'agit du répertoire /greengrass.
Si vous utilisez l'option de création de groupe par défaut depuis la AWS IoT Greengrass console, le config.json fichier est déployé sur le périphérique principal dans un état de fonctionnement.
Vous pouvez vérifier le contenu de ce fichier en exécutant la commande suivante :
cat /greengrass-root/config/config.json
Voici un exemple de fichier config.json. Il s'agit de la version générée lorsque vous créez le noyau depuis la AWS IoT Greengrass console.
Les points de terminaison du service doivent correspondre au type de certificat de l'autorité de certification racine
Vos points de terminaison AWS IoT Core et AWS IoT Greengrass doivent correspondre au type de certificat du certificat d'autorité de certification racine sur votre appareil. Si les points de terminaison et le type de certificat ne correspondent pas, les tentatives d'authentification entre le périphérique et AWS IoT Core ou AWS IoT Greengrass échouent. Pour plus d'informations, consultez la section Authentification du serveur dans le guide du AWS IoT développeur.
Si votre appareil utilise un certificat CA racine Amazon Trust Services (ATS), qui est la méthode préférée, il doit également utiliser les points de terminaison ATS pour la gestion des appareils et les opérations du plan de données de découverte. Les points de terminaison ATS incluent le segment ats, comme illustré dans la syntaxe suivante pour le point de terminaison AWS IoT Core.
prefix-ats.iot.region.amazonaws.com
Note
Pour des raisons de rétrocompatibilité, prend AWS IoT Greengrass actuellement en charge les anciens certificats et points de terminaison de l'autorité de certification VeriSign racine dans certains Région AWS s. Si vous utilisez un ancien certificat d'autorité de certification VeriSign racine, nous vous recommandons de créer un point de terminaison ATS et d'utiliser plutôt un certificat d'autorité de certification racine ATS. Sinon, assurez-vous d'utiliser les points de terminaison hérités correspondants. Pour de plus amples informations, veuillez consulter Points de terminaison hérités pris en charge dans le Référence générale d'Amazon Web Services.
Points de terminaison dans config.json
Sur un appareil noyau Greengrass, les points de terminaison sont spécifiés dans l'objet coreThing du fichier config.json. La propriété iotHost représente le point de terminaison AWS IoT Core. La propriété ggHost représente le point de terminaison AWS IoT Greengrass. Dans l'exemple d'extrait suivant, ces propriétés spécifient des points de terminaison ATS.
{ "coreThing" : { ... "iotHost" : "abcde1234uwxyz-ats.iot.us-west-2.amazonaws.com", "ggHost" : "greengrass-ats.iot.us-west-2.amazonaws.com", ... },
- Point de terminaison AWS IoT Core
-
Vous pouvez obtenir votre point de terminaison AWS IoT Core en exécutant la commande de l'interface de ligne de commande aws iot describe-endpoint avec le paramètre
--endpoint-typequi convient.-
Pour renvoyer un point de terminaison signé ATS, exécutez :
aws iot describe-endpoint --endpoint-type iot:Data-ATS -
Pour renvoyer un ancien point de terminaison VeriSign signé, exécutez :
aws iot describe-endpoint --endpoint-type iot:Data
-
- Point de terminaison AWS IoT Greengrass
-
Le point de terminaison AWS IoT Greengrass correspond au point de terminaison
iotHostavec le préfixe de l'hôte remplacé par greengrass. Par exemple, le point de terminaison signé ATS estgreengrass-ats.iot.. La même région que pour le point de terminaison AWS IoT Core est utilisée.region.amazonaws.com
Connexion au port 443 ou via un proxy réseau
Cette fonctionnalité est disponible pour AWS IoT Greengrass Core v1.7 et versions ultérieures.
Les noyaux Greengrass communiquent avec AWS IoT Core à l'aide du protocole de messagerie MQTT avec l'authentification client TLS. Par convention, MQTT via TLS utilise le port 8883. Toutefois, par mesure de sécurité, les environnements restrictifs peuvent limiter le trafic entrant et sortant à une petite plage de ports TCP. Par exemple, un pare-feu d'entreprise peut ouvrir le port 443 pour le trafic HTTPS, mais fermer les autres ports qui sont utilisés pour des protocoles moins courants, tels que le port 8883 pour le trafic MQTT. D'autres environnements restrictifs peuvent nécessiter que l'ensemble du trafic passe par un proxy HTTP avant de vous connecter à Internet.
Pour activer la communication dans ces scénarios, AWS IoT Greengrass autorise les configurations suivantes :
-
MQTT avec l'authentification client TLS via le port 443. Si votre réseau autorise les connexions au port 443, vous pouvez configurer le noyau pour utiliser ce port pour le trafic MQTT au lieu du port 8883 par défaut. Il peut s'agir d'une connexion directe au port 443 ou d'une connexion via un serveur réseau proxy.
AWS IoT Greengrass utilise l'extension TLS Application Layer Protocol Network
(ALPN) pour permettre cette connexion. Comme avec la configuration par défaut, MQTT via TLS sur le port 443 utilise l'authentification client basée sur le certificat. Lorsqu'il est configuré pour utiliser une connexion directe au port 443, le cœur prend en charge les mises à jour AWS IoT Greengrass logicielles over-the-air (OTA). Cette prise en charge nécessite AWS IoT Greengrass Core v1.9.3 ou version ultérieure.
-
Communication HTTPS via le port 443. Par défaut, AWS IoT Greengrass achemine le trafic HTTPS via le port 8443, mais vous pouvez le configurer afin qu'il utilise le port 443.
-
Connexion via un proxy réseau. Vous pouvez configurer un serveur réseau proxy comme intermédiaire pour la connexion au noyau Greengrass. Seule l'authentification de base et les proxys HTTP et HTTPS sont pris en charge.
La configuration du proxy est transmise aux fonctions Lambda définies par l'utilisateur via
http_proxyles variables d'https_proxyenvironnement,no_proxyet. Les fonctions Lambda définies par l'utilisateur doivent utiliser ces paramètres transmis pour se connecter via le proxy. Les bibliothèques courantes utilisées par les fonctions Lambda pour établir des connexions (telles que les packages boto3 ou cURL etrequestspython) utilisent généralement ces variables d'environnement par défaut. Si une fonction Lambda spécifie également ces mêmes variables d'environnement, AWS IoT Greengrass elle ne les remplace pas.Important
Les noyaux Greengrass qui sont configurés pour utiliser un proxy réseau ne prennent pas en charge les mises à jour OTA.
Pour configurer MQTT via le port 443
Cette fonctionnalité nécessite AWS IoT Greengrass Core v1.7 ou version ultérieure.
Cette procédure permet au noyau Greengrass d'utiliser le port 443 pour la messagerie MQTT avec AWS IoT Core.
-
Exécutez la commande suivante pour arrêter le daemon Greengrass :
cd /greengrass-root/ggc/core/ sudo ./greengrassd stop -
Ouvrez
greengrass-root/config/config.json -
Dans l'objet
coreThing, ajoutez la propriétéiotMqttPortet définissez la valeur sur443, comme illustré dans l'exemple suivant.{ "coreThing" : { "caPath" : "root.ca.pem", "certPath" : "12345abcde.cert.pem", "keyPath" : "12345abcde.private.key", "thingArn" : "arn:aws:iot:us-west-2:123456789012:thing/core-thing-name", "iotHost" : "abcd123456wxyz-ats.iot.us-west-2.amazonaws.com","iotMqttPort" : 443,"ggHost" : "greengrass-ats.iot.us-west-2.amazonaws.com", "keepAlive" : 600 }, ... } -
Lancez le démon.
cd /greengrass-root/ggc/core/ sudo ./greengrassd start
Pour configurer HTTPS via le port 443
Cette fonctionnalité nécessite AWS IoT Greengrass Core v1.8 ou version ultérieure.
Cette procédure configure le noyau afin qu'il utilise le port 443 pour la communication HTTPS.
-
Exécutez la commande suivante pour arrêter le daemon Greengrass :
cd /greengrass-root/ggc/core/ sudo ./greengrassd stop -
Ouvrez
greengrass-root/config/config.json -
Dans l'objet
coreThing, ajoutez les propriétésiotHttpPortetggHttpPort, comme indiqué dans l'exemple suivant.{ "coreThing" : { "caPath" : "root.ca.pem", "certPath" : "12345abcde.cert.pem", "keyPath" : "12345abcde.private.key", "thingArn" : "arn:aws:iot:us-west-2:123456789012:thing/core-thing-name", "iotHost" : "abcd123456wxyz-ats.iot.us-west-2.amazonaws.com","iotHttpPort" : 443,"ggHost" : "greengrass-ats.iot.us-west-2.amazonaws.com","ggHttpPort" : 443,"keepAlive" : 600 }, ... } -
Lancez le démon.
cd /greengrass-root/ggc/core/ sudo ./greengrassd start
Pour configurer un proxy réseau
Cette fonctionnalité nécessite AWS IoT Greengrass Core v1.7 ou version ultérieure.
Cette procédure permet à AWS IoT Greengrass de se connecter à Internet via un proxy réseau HTTP ou HTTPS.
-
Exécutez la commande suivante pour arrêter le daemon Greengrass :
cd /greengrass-root/ggc/core/ sudo ./greengrassd stop -
Ouvrez
greengrass-root/config/config.json -
Dans l'
coreThingobjet, ajoutez l'objet NetworkProxy, comme indiqué dans l'exemple suivant.{ "coreThing" : { "caPath" : "root.ca.pem", "certPath" : "12345abcde.cert.pem", "keyPath" : "12345abcde.private.key", "thingArn" : "arn:aws:iot:us-west-2:123456789012:thing/core-thing-name", "iotHost" : "abcd123456wxyz-ats.iot.us-west-2.amazonaws.com", "ggHost" : "greengrass-ats.iot.us-west-2.amazonaws.com", "keepAlive" : 600,"networkProxy": { "noProxyAddresses" : "http://128.12.34.56,www.mywebsite.com", "proxy" : { "url" : "https://my-proxy-server:1100", "username" : "Mary_Major", "password" : "pass@word1357" } }}, ... } -
Lancez le démon.
cd /greengrass-root/ggc/core/ sudo ./greengrassd start
Objet networkProxy
Utilisez l'objet networkProxy pour spécifier les informations sur le proxy réseau. Cet objet a les propriétés suivantes.
| Champ | Description |
|---|---|
noProxyAddresses |
Facultatif. Liste séparée par des virgules d'adresses IP ou de noms d'hôte qui sont dispensés par le proxy. |
proxy |
Proxy auquel se connecter. Un proxy a les propriétés suivantes.
|
Autoriser les points de terminaison
La communication entre les appareils Greengrass et AWS IoT Core ou AWS IoT Greengrass doit être authentifiée. Cette authentification est basée sur les certificats d'appareils X.509 enregistrés et sur des clés de chiffrement. Pour autoriser les demandes authentifiées à passer par des proxys sans chiffrement supplémentaire, autorisez les points de terminaison suivants.
| Point de terminaison | Port | Description |
|---|---|---|
greengrass. |
443 |
Utilisé pour les opérations de plan de contrôle pour la gestion des groupes. |
or
|
MQTT : 8883 ou 443 HTTPS : 8443 ou 443 |
Utilisé pour les opérations de plan de contrôle pour la gestion des appareils, par exemple la synchronisation shadow. Autorisez l'utilisation d'un ou des deux points de terminaison, selon que vos appareils principaux et clients utilisent des certificats d'autorité de certification racine (préférés) d'Amazon Trust Services, des certificats d'autorité de certification racine existants ou les deux. Pour plus d’informations, consultez Les points de terminaison du service doivent correspondre au type de certificat de l'autorité de certification racine. |
or
|
8443 ou 443 |
Utilisé pour les opérations de détection d'appareils. Autorisez l'utilisation d'un ou des deux points de terminaison, selon que vos appareils principaux et clients utilisent des certificats d'autorité de certification racine (préférés) d'Amazon Trust Services, des certificats d'autorité de certification racine existants ou les deux. Pour plus d’informations, consultez Les points de terminaison du service doivent correspondre au type de certificat de l'autorité de certification racine. NoteLes clients qui se connectent sur le port 443 doivent implémenter l'extension TLS ALPN (Application Layer Protocol Negotiation) |
*.s3.amazonaws.com |
443 |
Utilisé pour les opérations de déploiement et les over-the-air mises à jour. Ce format comprend le caractère |
logs. |
443 |
Requis si le groupe Greengrass est configuré pour écrire des journaux dans CloudWatch. |
Configuration d'un répertoire en écriture pour AWS IoT Greengrass
Cette fonctionnalité est disponible pour AWS IoT Greengrass Core v1.6 et versions ultérieures.
Par défaut, le logiciel AWS IoT Greengrass Core est déployé dans un répertoire racine unique où AWS IoT Greengrass effectue toutes les opérations de lecture et d'écriture. Cependant, vous pouvez configurer AWS IoT Greengrass pour qu'il utilise un répertoire distinct pour toutes les opérations d'écriture, y compris la création de répertoires et de fichiers. Dans ce cas, AWS IoT Greengrass utilise deux répertoires de niveau supérieur :
-
Le répertoire
greengrass-root, que vous pouvez conserver accessible en lecture et en écriture ou, si vous le souhaitez, rendre accessible en lecture seule. Celui-ci contient le logiciel AWS IoT Greengrass et d'autres composants critiques qui doivent rester immuables lors de l'exécution (par exemple, les certificats etconfig.json). -
Le répertoire en écriture spécifié. Il contient du contenu inscriptible, tel que des journaux, des informations d'état et des fonctions Lambda définies par l'utilisateur déployées.
Cette configuration entraîne la structure de répertoires suivante.
- Répertoire racine Greengrass
-
greengrass-root/ |-- certs/ | |-- root.ca.pem | |--hash.cert.pem | |--hash.private.key | |--hash.public.key |-- config/ | |-- config.json |-- ggc/ | |-- packages/ | |--package-version/ | |-- bin/ | |-- daemon | |-- greengrassd | |-- lambda/ | |-- LICENSE/ | |-- release_notes_package-version.html | |-- runtime/ | |-- java8/ | |-- nodejs8.10/ | |-- python3.8/ | |-- core/ - Répertoire en écriture
-
write-directory/ |-- packages/ | |--package-version/ | |-- ggc_root/ | |-- rootfs_nosys/ | |-- rootfs_sys/ | |-- var/ |-- deployment/ | |-- group/ | |-- group.json | |-- lambda/ | |-- mlmodel/ |-- var/ | |-- log/ | |-- state/
Pour configurer un répertoire en écriture
-
Exécutez la commande suivante pour arrêter le démon AWS IoT Greengrass :
cd /greengrass-root/ggc/core/ sudo ./greengrassd stop -
Ouvrez
greengrass-root/config/config.json -
Ajoutez
writeDirectoryen tant que paramètre et spécifiez le chemin d'accès au répertoire cible, comme illustré dans l'exemple suivant.{ "coreThing": { "caPath": "root-CA.pem", "certPath": "hash.pem.crt", ... }, ... "writeDirectory" : "/write-directory" }Note
Vous pouvez mettre à jour le paramètre
writeDirectoryaussi souvent que vous le souhaitez. Une fois que le paramètre est mis à jour, AWS IoT Greengrass utilise le répertoire d'écriture nouvellement spécifié lors du démarrage suivant, mais ne migre pas le contenu du répertoire en écriture précédent. -
Maintenant que votre répertoire en écriture est configuré, vous pouvez, si vous le souhaitez, rendre le répertoire
greengrass-rootaccessible en lecture seule. Pour en savoir plus, consultez Pour rendre le répertoire racine Greengrass accessible en lecture seule.Sinon, démarrez le démon AWS IoT Greengrass :
cd /greengrass-root/ggc/core/ sudo ./greengrassd start
Pour rendre le répertoire racine Greengrass accessible en lecture seule
Cette étape est nécessaire uniquement si vous souhaitez que le répertoire racine Greengrass soit accessible en lecture seule. Le répertoire en écriture doit être configuré avant de commencer cette procédure.
-
Accorder des autorisations d'accès aux répertoires requis :
-
Accordez les autorisations en lecture et en écriture au propriétaire de
config.json.sudo chmod 0600 /greengrass-root/config/config.json -
Définissez ggc_user en tant que propriétaire des répertoires certs et Lambda système.
sudo chown -R ggc_user:ggc_group /greengrass-root/certs/ sudo chown -R ggc_user:ggc_group /greengrass-root/ggc/packages/1.11.6/lambda/Note
Les comptes ggc_user et ggc_group sont utilisés par défaut pour exécuter les fonctions Lambda du système. Si vous avez configuré l'identité d'accès par défaut au niveau du groupe de façon à utiliser différents comptes, vous devez octroyer des autorisations à cet utilisateur (UID) et à ce groupe (GID) à la place.
-
-
Rendez le répertoire
greengrass-rootaccessible en lecture seule en utilisant la méthode de votre choix.Note
Une des méthodes pour rendre le répertoire
greengrass-rootaccessible en lecture seule consiste à monter le répertoire en lecture seule. Toutefois, pour appliquer des mises à jour over-the-air (OTA) au logiciel AWS IoT Greengrass Core dans un répertoire monté, le répertoire doit d'abord être démonté, puis remonté après la mise à jour. Vous pouvez ajouter ces opérationsumountetmountaux scriptsota_pre_updateetota_post_update. Pour plus d'informations sur les mises à jour OTA, consultez Agent de mise à jour OTA Greengrass et Commande managedRespawn avec mises à jour OTA. -
Lancez le démon.
cd /greengrass-root/ggc/core/ sudo ./greengrassd startSi les autorisations de l'étape 1 ne sont pas correctement définies, le démon ne démarre pas.
Configuration des paramètres MQTT
Dans l'AWS IoT Greengrassenvironnement, les appareils clients locaux, les fonctions Lambda, les connecteurs et les composants du système peuvent communiquer entre eux et avec. AWS IoT Core Toutes les communications passent par le noyau, qui gère les abonnements autorisant la communication MQTT entre les entités.
Pour de plus amples informations sur les paramètres MQTT que vous pouvez configurer pour AWS IoT Greengrass, consultez les sections suivantes :
Note
OPC-UA est une norme d'échange d'informations pour la communication industrielle. Pour implémenter la prise en charge de l'OPC-UA sur le cœur de Greengrass, vous pouvez utiliser le connecteur IoT. SiteWise Le connecteur envoie les données d'appareil industrielles provenant de serveurs OPC-UA aux propriétés des ressources dans AWS IoT SiteWise.
Message de qualité de service
AWS IoT Greengrass prend en charge les niveaux de qualité de service (QoS) 0 ou 1, en fonction de votre configuration, ainsi que de la cible et de la direction de la communication. Le noyau Greengrass agit comme un client pour la communication avec AWS IoT Core et comme un courtier de messages pour la communication sur le réseau local.
Pour plus d'informations sur MQTT et QoS, consultez Getting
- Communication avec le AWS Cloud
-
-
Les messages sortants utilisent QoS 1
Le noyau envoie des messages destinés aux AWS Cloud cibles à l'aide de QoS 1. AWS IoT Greengrassutilise une file de messages MQTT pour traiter ces messages. Si la livraison du message n'est pas confirmée parAWS IoT, le message est mis en attente pour être réessayé ultérieurement. Le message ne peut pas être réessayé si la file d'attente est pleine. La confirmation de remise du message peut aider à minimiser les pertes de données dues à une connectivité intermittente.
Comme les messages sortants doivent AWS IoT utiliser QoS 1, le débit maximal auquel le cœur de Greengrass peut envoyer des messages dépend de la latence entre le cœur et. AWS IoT Chaque fois que le noyau envoie un message, il attend d'AWS IoTavoir accusé réception du message avant d'envoyer le message suivant. Par exemple, si le temps d'aller-retour entre le cœur et le sien Région AWS est de 50 millisecondes, le cœur peut envoyer jusqu'à 20 messages par seconde. Tenez compte de ce comportement lorsque vous choisissez l'Région AWSendroit où votre cœur se connecte. Pour ingérer de gros volumes de données IoT dans leAWS Cloud, vous pouvez utiliser le gestionnaire de flux.
Pour plus d'informations sur la file d'attente de messages MQTT, notamment sur la façon de configurer un cache de stockage local capable de conserver les messages destinés aux AWS Cloud cibles, consultezFile d'attente de messages MQTT pour les cibles cloud.
-
Les messages entrants utilisent le niveau de qualité QoS 0 (par défaut) ou QoS 1
Par défaut, le noyau s'abonne avec QoS 0 aux messages AWS Cloud provenant des sources. Si vous activez les sessions persistantes, le noyau s'abonne avec le niveau QoS 1. Cela peut permettre de réduire les pertes de données dues à l'intermittence de la connexion. Pour gérer le niveau de qualité QoS pour ces abonnements, vous configurez les paramètres de persistance sur le composant système spouleur local.
Pour plus d'informations, notamment sur la manière de permettre au noyau d'établir une session persistante avec AWS Cloud des cibles, consultezSessions persistantes MQTT avec AWS IoT Core.
-
- Communication avec les cibles locales
-
Toutes les communications locales utilisent le niveau QoS 0. Le noyau tente d'envoyer un message à une cible locale, qui peut être une fonction Greengrass Lambda, un connecteur ou un appareil client. Le noyau ne stocke pas de messages et ne confirme pas la livraison. Les messages peuvent être supprimés n'importe où entre les composants.
Note
Bien que la communication directe entre les fonctions Lambda n'utilise pas la messagerie MQTT, le comportement est le même.
File d'attente de messages MQTT pour les cibles cloud
Les messages MQTT destinés aux AWS Cloud cibles sont mis en file d'attente en attente de traitement. Les messages en attente sont traités selon l'ordre FIFO (premier entré, premier sorti). Lorsqu'un message est traité et publié dans AWS IoT Core, il est supprimé de la file d'attente.
Par défaut, le cœur de Greengrass stocke en mémoire les messages non traités destinés aux cibles. AWS Cloud Si vous le souhaitez, vous pouvez configurer le noyau pour stocker les messages non traités dans une mémoire cache locale. Contrairement au stockage en mémoire, le cache de stockage local peut être conservé malgré les redémarrages du noyau (par exemple, après le déploiement d'un groupe ou un redémarrage de l'appareil), ce qui permet à AWS IoT Greengrass de continuer à traiter les messages. Vous pouvez également configurer la taille du stockage.
Avertissement
Le noyau de Greengrass peut mettre en file d'attente des messages MQTT dupliqués lorsqu'il perd la connexion, car il tente à nouveau une opération de publication avant que le client MQTT ne détecte qu'il est hors ligne. Pour éviter les messages MQTT dupliqués pour les cibles du cloud, configurez la keepAlive valeur du noyau à moins de la moitié de sa mqttOperationTimeout valeur. Pour plus d’informations, consultez Fichier de configuration de AWS IoT Greengrass Core.
AWS IoT Greengrassutilise le composant du système de spouleur (fonction GGCloudSpooler Lambda) pour gérer la file d'attente de messages. Vous pouvez utiliser les variables d'environnement GGCloudSpooler suivantes pour configurer les paramètres de stockage.
-
GG_CONFIG_STORAGE_TYPE. Emplacement de la file d'attente de messages. Les valeurs suivantes sont valides :
-
FileSystem. Stockez les messages non traités dans le cache de stockage local sur le disque du périphérique principal physique. Lorsque le noyau redémarre, les messages mis en file d'attente sont conservés en vue de leur traitement. Les messages sont supprimés une fois qu'ils sont traités. -
Memory(default). Les messages non traités sont stockés en mémoire. Lorsque le noyau redémarre, les messages mis en file d'attente sont perdus.Cette option est optimisée pour les périphériques avec des capacités matérielles restreintes. Lorsque vous utilisez cette configuration, nous vous recommandons de déployer des groupes ou de redémarrer l'appareil lorsque l'interruption de service est la moins importante.
-
-
GG_CONFIG_MAX_SIZE_BYTES. Taille du stockage, en octets. Cette valeur peut être n'importe quel nombre entier non négatif supérieur ou égal à 262144 (256 Ko) ; une taille plus petite empêche le logiciel AWS IoT Greengrass Core de démarrer. La taille par défaut est de 2.5 Mo. Lorsque la taille limite est atteinte, les messages les plus anciens de la file d'attente sont remplacés par de nouveaux messages.
Note
Cette fonctionnalité est disponible pour AWS IoT Greengrass Core v1.6 et versions ultérieures. Les versions antérieures utilisent le stockage en mémoire avec une taille de file d'attente de 2,5 Mo. Vous ne pouvez pas configurer les paramètres de stockage pour les versions antérieures.
Pour mettre en cache des messages dans le stockage local
Vous pouvez configurer AWS IoT Greengrass pour mettre en cache des messages dans le système de fichiers, afin qu'ils soient conservés lors des redémarrages du noyau. Pour ce faire, vous déployez une version de définition de fonction dans laquelle la fonction GGCloudSpooler définit le type de stockage sur FileSystem. Vous devez utiliser l'API AWS IoT Greengrass pour configurer le cache de stockage local. Vous ne pouvez pas réaliser cette opération dans la console.
La procédure suivante utilise la commande create-function-definition-versionCLI pour configurer le spouleur afin d'enregistrer les messages en file d'attente dans le système de fichiers. Elle configure également une file d'attente d'une taille de 2,6 Mo.
-
Obtenez les ID du groupe et de la version de groupe Greengrass cible. Cette procédure suppose qu'il s'agit de la dernière version du groupe et du groupe. La requête suivante renvoie le dernier groupe créé.
aws greengrass list-groups --query "reverse(sort_by(Groups, &CreationTimestamp))[0]"Vous pouvez également procéder à une interrogation par nom. Les noms de groupe ne devant pas nécessairement être uniques, plusieurs groupes peuvent être renvoyés.
aws greengrass list-groups --query "Groups[?Name=='MyGroup']"Note
Vous pouvez également trouver ces valeurs dans la AWS IoT console. L'ID du groupe s'affiche sur la page Paramètres du groupe. Les identifiants de version du groupe sont affichés dans l'onglet Déploiements du groupe.
-
Copiez les valeurs
LatestVersionetIddu groupe cible dans la sortie. -
Obtenez la version de groupe la plus récente.
-
Remplacez
group-idpar la propriétéIdque vous avez copiée. -
Remplacez
latest-group-version-idpar l’LatestVersionque vous avez copié.
aws greengrass get-group-version \ --group-idgroup-id\ --group-version-idlatest-group-version-id -
-
À partir de l'objet
Definitionde la sortie, copiez leCoreDefinitionVersionArnet les ARN de tous les autres composants de groupe à l'exception deFunctionDefinitionVersionArn. Vous utilisez ces valeurs lorsque vous créez une nouvelle version de groupe. -
Depuis
FunctionDefinitionVersionArndans la sortie, copiez l'ID de la définition de fonction. L'ID est le GUID qui suit le segmentfunctionsdans l'ARN, comme illustré dans l'exemple suivant.arn:aws:greengrass:us-west-2:123456789012:/greengrass/definition/functions/bcfc6b49-beb0-4396-b703-6dEXAMPLEcu5/versions/0f7337b4-922b-45c5-856f-1aEXAMPLEsf6Note
Vous pouvez également créer une définition de fonction en exécutant la
create-function-definitioncommande, puis en copiant l'ID depuis la sortie. -
Ajoutez une version de définition de fonction à la définition de fonction.
-
function-definition-idRemplacez-le par celuiIdque vous avez copié pour la définition de la fonction. -
arbitrary-function-idRemplacez-le par un nom pour la fonction, tel quespooler-function. -
Ajoutez au tableau toutes les fonctions Lambda que vous souhaitez inclure dans cette version.
functionsVous pouvez utiliser laget-function-definition-versioncommande pour obtenir les fonctions Greengrass Lambda à partir d'une version de définition de fonction existante.
Avertissement
Assurez-vous de spécifier une valeur pour
GG_CONFIG_MAX_SIZE_BYTESqui soit supérieure ou égale à 262 144. Une taille plus petite empêche le logiciel AWS IoT Greengrass Core de démarrer.aws greengrass create-function-definition-version \ --function-definition-idfunction-definition-id\ --functions '[{"FunctionArn": "arn:aws:lambda:::function:GGCloudSpooler:1","FunctionConfiguration": {"Environment": {"Variables":{"GG_CONFIG_MAX_SIZE_BYTES":"2621440","GG_CONFIG_STORAGE_TYPE":"FileSystem"}},"Executable": "spooler","MemorySize": 32768,"Pinned": true,"Timeout": 3},"Id": "arbitrary-function-id"}]'Note
Si vous avez précédemment défini la variable d'environnement
GG_CONFIG_SUBSCRIPTION_QUALITYpour prendre en charge les sessions persistantes avec AWS IoT Core, incluez-la dans cette instance de fonction. -
-
Copiez l'
Arnde la version de définition de fonction à partir de la sortie. -
Créez une version de groupe contenant la fonction Lambda du système.
-
Remplacez
group-idpar l'Iddu groupe. -
core-definition-version-arnRemplacez-le par celuiCoreDefinitionVersionArnque vous avez copié à partir de la dernière version du groupe. -
function-definition-version-arnRemplacez-le par celuiArnque vous avez copié pour la nouvelle version de définition de fonction. -
Remplacez les ARN des autres composants de groupe (par exemple
SubscriptionDefinitionVersionArnouDeviceDefinitionVersionArn) que vous avez copiés de la version de groupe la plus récente. -
Supprimez tous les paramètres inutilisés. Par exemple, supprimez
--resource-definition-version-arnsi votre version de groupe ne contient aucune ressource.
aws greengrass create-group-version \ --group-idgroup-id\ --core-definition-version-arncore-definition-version-arn\ --function-definition-version-arnfunction-definition-version-arn\ --device-definition-version-arndevice-definition-version-arn\ --logger-definition-version-arnlogger-definition-version-arn\ --resource-definition-version-arnresource-definition-version-arn\ --subscription-definition-version-arnsubscription-definition-version-arn -
-
Copiez la
Versionà partir de la sortie. Il s'agit de l'ID de la nouvelle version de groupe. -
Déployez le groupe avec la nouvelle version de groupe.
-
Remplacez
group-idpar l'Idque vous avez copié pour le groupe. -
group-version-idRemplacez-le par celuiVersionque vous avez copié pour la nouvelle version du groupe.
aws greengrass create-deployment \ --group-idgroup-id\ --group-version-idgroup-version-id\ --deployment-type NewDeployment -
Pour mettre à jour les paramètres de stockage, utilisez l'API AWS IoT Greengrass pour créer une nouvelle version de définition de fonction qui contient la fonction GGCloudSpooler avec la configuration mise à jour. Ensuite, ajoutez la version de définition de fonction à une nouvelle version de groupe (avec vos autres composants de groupe) et déployez la version de groupe. Si vous souhaitez restaurer la configuration par défaut, vous pouvez déployer une version de définition de fonction qui n'inclut pas la fonction GGCloudSpooler.
Cette fonction Lambda du système n'est pas visible dans la console. Toutefois, lorsque la fonction est ajoutée à la version de groupe la plus récente, elle est incluse dans les déploiements que vous effectuez à partir de la console (sauf si vous utilisez l'API pour la remplacer ou la supprimer).
Sessions persistantes MQTT avec AWS IoT Core
Cette fonction est disponible pour AWS IoT Greengrass Core v1.10 et versions ultérieures.
Un noyau Greengrass peut établir une session persistante avec le courtier de messages AWS IoT. Une session persistante est une connexion continue qui permet au noyau de recevoir les messages envoyés pendant qu'il est hors connexion. Le noyau est le client dans la connexion.
Dans une session persistante, le courtier de messages AWS IoT enregistre tous les abonnements souscrits par le noyau pendant la connexion. Si le cœur se déconnecte, le courtier de AWS IoT messages stocke les messages non reconnus et les nouveaux messages publiés sous QoS 1 et destinés à des cibles locales, telles que les fonctions Lambda et les appareils clients. Lorsque le noyau se reconnecte, la session persistante reprend son exécution et le courtier de messages AWS IoT envoie les messages stockés au noyau à un rythme maximum de 10 messages par seconde. Les sessions persistantes ont une période d'expiration par défaut de 1 heure, qui commence lorsque le courtier de messages détecte la déconnexion du noyau. Pour plus d'informations, consultez la section Sessions persistantes MQTT dans le manuel du AWS IoT développeur.
AWS IoT Greengrassutilise le composant du système de spouleur (fonction GGCloudSpooler Lambda) pour créer des abonnements ayant AWS IoT pour source. Vous pouvez utiliser la variable d'environnement GGCloudSpooler suivante pour configurer des sessions persistantes.
-
GG_CONFIG_SUBSCRIPTION_QUALITY. La qualité des abonnements qui ont AWS IoT comme source. Les valeurs suivantes sont valides :
-
AtMostOnce(default). Désactive les sessions persistantes. Les abonnements utilisent le niveau QoS 0. -
AtLeastOncePersistent. Active les sessions persistantes. Définit l'indicateurcleanSessionsur0dans les messagesCONNECTet s'abonne au niveau QoS 1.Les messages publiés avec le niveau QoS 1 et qui sont reçus par le noyau atteignent obligatoirement la file d'attente de travail en mémoire du démon Greengrass. Le noyau accuse réception du message après son ajout à la file d'attente. Les communications ultérieures entre la file d'attente et la cible locale (par exemple, la fonction, le connecteur ou le périphérique Greengrass Lambda) sont envoyées sous la forme de QoS 0. AWS IoT Greengrassne garantit pas la livraison aux cibles locales.
Note
Vous pouvez utiliser la propriété de configuration maxWorkItemCount pour contrôler la taille de la file d'attente des éléments de travail. Par exemple, vous pouvez augmenter la taille de la file d'attente si votre charge de travail nécessite un trafic MQTT élevé.
Lorsque les sessions persistantes sont activées, le noyau ouvre au moins une connexion supplémentaire pour l'échange de messages MQTT avec AWS IoT. Pour plus d’informations, consultez ID client pour les connexions MQTT avec AWS IoT.
-
Pour configurer des sessions permanentes MQTT
Vous pouvez configurer AWS IoT Greengrass pour utiliser les sessions persistantes avec AWS IoT Core. Pour ce faire, vous déployez une version de définition de fonction dans laquelle la fonction GGCloudSpooler définit la qualité d'abonnement sur AtLeastOncePersistent. Ce paramètre s'applique à tous vos abonnements ayant AWS IoT Core (cloud) comme source. Vous devez utiliser l'API AWS IoT Greengrass pour configurer les sessions persistantes. Vous ne pouvez pas réaliser cette opération dans la console.
La procédure suivante utilise la commande create-function-definition-versionCLI pour configurer le spouleur afin qu'il utilise des sessions persistantes. Dans cette procédure, on suppose que vous mettez à jour la configuration de la version de groupe la plus récente d'un groupe existant.
-
Obtenez les ID du groupe et de la version de groupe Greengrass cible. Cette procédure suppose qu'il s'agit de la dernière version du groupe et du groupe. La requête suivante renvoie le dernier groupe créé.
aws greengrass list-groups --query "reverse(sort_by(Groups, &CreationTimestamp))[0]"Vous pouvez également procéder à une interrogation par nom. Les noms de groupe ne devant pas nécessairement être uniques, plusieurs groupes peuvent être renvoyés.
aws greengrass list-groups --query "Groups[?Name=='MyGroup']"Note
Vous pouvez également trouver ces valeurs dans la AWS IoT console. L'ID du groupe s'affiche sur la page Paramètres du groupe. Les identifiants de version du groupe sont affichés dans l'onglet Déploiements du groupe.
-
Copiez les valeurs
LatestVersionetIddu groupe cible dans la sortie. -
Obtenez la version de groupe la plus récente.
-
Remplacez
group-idpar la propriétéIdque vous avez copiée. -
Remplacez
latest-group-version-idpar l’LatestVersionque vous avez copié.
aws greengrass get-group-version \ --group-idgroup-id\ --group-version-idlatest-group-version-id -
-
À partir de l'objet
Definitionde la sortie, copiez leCoreDefinitionVersionArnet les ARN de tous les autres composants de groupe à l'exception deFunctionDefinitionVersionArn. Vous utilisez ces valeurs lorsque vous créez une nouvelle version de groupe. -
Depuis
FunctionDefinitionVersionArndans la sortie, copiez l'ID de la définition de fonction. L'ID est le GUID qui suit le segmentfunctionsdans l'ARN, comme illustré dans l'exemple suivant.arn:aws:greengrass:us-west-2:123456789012:/greengrass/definition/functions/bcfc6b49-beb0-4396-b703-6dEXAMPLEcu5/versions/0f7337b4-922b-45c5-856f-1aEXAMPLEsf6Note
Vous pouvez également créer une définition de fonction en exécutant la
create-function-definitioncommande, puis en copiant l'ID depuis la sortie. -
Ajoutez une version de définition de fonction à la définition de fonction.
-
function-definition-idRemplacez-le par celuiIdque vous avez copié pour la définition de la fonction. -
arbitrary-function-idRemplacez-le par un nom pour la fonction, tel quespooler-function. -
Ajoutez au tableau toutes les fonctions Lambda que vous souhaitez inclure dans cette version.
functionsVous pouvez utiliser laget-function-definition-versioncommande pour obtenir les fonctions Greengrass Lambda à partir d'une version de définition de fonction existante.
aws greengrass create-function-definition-version \ --function-definition-idfunction-definition-id\ --functions '[{"FunctionArn": "arn:aws:lambda:::function:GGCloudSpooler:1","FunctionConfiguration": {"Environment": {"Variables":{"GG_CONFIG_SUBSCRIPTION_QUALITY":"AtLeastOncePersistent"}},"Executable": "spooler","MemorySize": 32768,"Pinned": true,"Timeout": 3},"Id": "arbitrary-function-id"}]'Note
Si vous avez précédemment défini les variables d'environnement
GG_CONFIG_STORAGE_TYPEouGG_CONFIG_MAX_SIZE_BYTESafin de définir les paramètres de stockage, incluez-les dans cette instance de fonction. -
-
Copiez l'
Arnde la version de définition de fonction à partir de la sortie. -
Créez une version de groupe contenant la fonction Lambda du système.
-
Remplacez
group-idpar l'Iddu groupe. -
core-definition-version-arnRemplacez-le par celuiCoreDefinitionVersionArnque vous avez copié à partir de la dernière version du groupe. -
function-definition-version-arnRemplacez-le par celuiArnque vous avez copié pour la nouvelle version de définition de fonction. -
Remplacez les ARN des autres composants de groupe (par exemple
SubscriptionDefinitionVersionArnouDeviceDefinitionVersionArn) que vous avez copiés de la version de groupe la plus récente. -
Supprimez tous les paramètres inutilisés. Par exemple, supprimez
--resource-definition-version-arnsi votre version de groupe ne contient aucune ressource.
aws greengrass create-group-version \ --group-idgroup-id\ --core-definition-version-arncore-definition-version-arn\ --function-definition-version-arnfunction-definition-version-arn\ --device-definition-version-arndevice-definition-version-arn\ --logger-definition-version-arnlogger-definition-version-arn\ --resource-definition-version-arnresource-definition-version-arn\ --subscription-definition-version-arnsubscription-definition-version-arn -
-
Copiez la
Versionà partir de la sortie. Il s'agit de l'ID de la nouvelle version de groupe. -
Déployez le groupe avec la nouvelle version de groupe.
-
Remplacez
group-idpar l'Idque vous avez copié pour le groupe. -
group-version-idRemplacez-le par celuiVersionque vous avez copié pour la nouvelle version du groupe.
aws greengrass create-deployment \ --group-idgroup-id\ --group-version-idgroup-version-id\ --deployment-type NewDeployment -
-
(Facultatif) Augmentez la propriété maxWorkItemCount dans le fichier de configuration principal. Cela peut aider le noyau à gérer l'augmentation du trafic MQTT et la communication avec les cibles locales.
Pour mettre à jour le noyau en fonction de ces modifications de configuration, utilisez l'API AWS IoT Greengrass pour créer une nouvelle version de définition de fonction contenant la fonction GGCloudSpooler avec la configuration mise à jour. Ensuite, ajoutez la version de définition de fonction à une nouvelle version de groupe (avec vos autres composants de groupe) et déployez la version de groupe. Si vous souhaitez restaurer la configuration par défaut, vous pouvez créer une version de définition de fonction qui n'inclut pas la fonction GGCloudSpooler.
Cette fonction Lambda du système n'est pas visible dans la console. Toutefois, lorsque la fonction est ajoutée à la version de groupe la plus récente, elle est incluse dans les déploiements que vous effectuez à partir de la console (sauf si vous utilisez l'API pour la remplacer ou la supprimer).
ID client pour les connexions MQTT avec AWS IoT
Cette fonctionnalité est disponible pour AWS IoT Greengrass Core v1.8 et versions ultérieures.
Le noyau Greengrass ouvre les connexions MQTT avec AWS IoT Core pour des opérations telles que la synchronisation shadow et la gestion de certificats. Pour ces connexions, les ID client prévisibles sont basés sur le nom de l'élément principal. Les identifiants clients prévisibles peuvent être utilisés avec les fonctionnalités de surveillance, d'audit et de tarification, y compris les événements AWS IoT Device Defender liés au AWS IoT cycle de vie. Vous pouvez aussi créer des ID client prévisibles logiques (par exemple, les modèles de stratégie d'abonnement basés sur les attributs de certificat).
Note
Dupliquer les ID client utilisés dans les connexions simultanées peut entraîner une boucle connexion-déconnexion infinie. Cela peut se produire si un autre périphérique est codé de manière irréversible pour utiliser le nom du périphérique principal comme ID client dans les connexions. Pour plus d'informations, consultez cette étape de dépannage.
Les appareils Greengrass sont également entièrement intégrés au service d'indexation de flotte d'AWS IoT Device Management. Cela vous permet d'indexer et de rechercher des appareils en fonction de leurs attributs, de leur état shadow et de leur état de connexion dans le cloud. Par exemple, les appareils Greengrass établissent au moins une connexion qui utilise le nom d'objet comme ID client, afin que vous puissiez utiliser l'indexation de connectivité des appareils pour détecter quels appareils Greengrass sont actuellement connectés à AWS IoT Core ou déconnectés de celui-ci. Pour plus d'informations, consultez la section Service d'indexation de flotte dans le Guide du AWS IoT développeur.
Configuration du port MQTT pour la messagerie locale
Cette fonctionnalité nécessite AWS IoT Greengrass Core v1.10 ou version ultérieure.
Le noyau de Greengrass agit en tant que courtier de messages local pour la messagerie MQTT entre les fonctions Lambda locales, les connecteurs et les appareils clients. Par défaut, le noyau utilise le port 8883 pour le trafic MQTT sur le réseau local. Vous pouvez modifier le port pour éviter un conflit avec d'autres logiciels s'exécutant sur le port 8883.
Pour configurer le numéro de port utilisé par le noyau pour le trafic MQTT local
-
Exécutez la commande suivante pour arrêter le daemon Greengrass :
cd /greengrass-root/ggc/core/ sudo ./greengrassd stop -
Ouvrez
greengrass-root/config/config.json -
Dans l'objet
coreThing, ajoutez la propriétéggMqttPortet définissez la valeur sur le numéro de port que vous souhaitez utiliser. Les valeurs valides vont de 1 024 à 65 535. L'exemple suivant définit le numéro de port sur9000.{ "coreThing" : { "caPath" : "root.ca.pem", "certPath" : "12345abcde.cert.pem", "keyPath" : "12345abcde.private.key", "thingArn" : "arn:aws:iot:us-west-2:123456789012:thing/core-thing-name", "iotHost" : "abcd123456wxyz-ats.iot.us-west-2.amazonaws.com", "ggHost" : "greengrass-ats.iot.us-west-2.amazonaws.com","ggMqttPort" : 9000,"keepAlive" : 600 }, ... } -
Lancez le démon.
cd /greengrass-root/ggc/core/ sudo ./greengrassd start -
Si la détection IP automatique est activée pour le noyau, la configuration est terminée.
Si la détection IP automatique n'est pas activée, vous devez mettre à jour les informations de connectivité du noyau. Cela permet aux appareils clients de recevoir le numéro de port correct lors des opérations de découverte afin d'acquérir des informations de connectivité de base. Vous pouvez utiliser la AWS IoT console ou l'AWS IoT GreengrassAPI pour mettre à jour les informations de connectivité de base. Pour cette procédure, vous mettez uniquement à jour le numéro de port. L'adresse IP locale du noyau reste la même.
- Pour mettre à jour les informations de connectivité du noyau (console)
-
-
Sur la page de configuration du groupe, choisissez le noyau Greengrass.
-
Sur la page des détails de base, choisissez l'onglet Points de terminaison du broker MQTT.
-
Choisissez Gérer les points de terminaison, puis choisissez Ajouter un point de terminaison
-
Entrez votre adresse IP locale actuelle et le nouveau numéro de port. L'exemple suivant définit le numéro de port
9000pour l'adresse IP192.168.1.8. -
Supprimez le point de terminaison obsolète, puis choisissez Mettre à jour
-
- Pour mettre à jour les informations de connectivité du noyau (API)
-
-
Utilisez l'action UpdateConnectivityInfo. L'exemple suivant utilise
update-connectivity-infodans l'AWS CLI pour définir le numéro de port9000de l'adresse IP192.168.1.8.aws greengrass update-connectivity-info \ --thing-name "MyGroup_Core" \ --connectivity-info "[{\"Metadata\":\"\",\"PortNumber\":9000,\"HostAddress\":\"192.168.1.8\",\"Id\":\"localIP_192.168.1.8\"},{\"Metadata\":\"\",\"PortNumber\":8883,\"HostAddress\":\"127.0.0.1\",\"Id\":\"localhost_127.0.0.1_0\"}]"
-
Note
Vous pouvez également configurer le port utilisé par le noyau pour la messagerie MQTT avec AWS IoT Core. Pour plus d’informations, consultez Connexion au port 443 ou via un proxy réseau.
Délai d'expiration pour les opérations de publication, d'abonnement et de désinscription dans le cadre des connexions MQTT avec AWS Cloud
Cette fonctionnalité est disponible dans AWS IoT Greengrass version 1.10.2 ou ultérieure.
Vous pouvez configurer le temps (en secondes) alloué au noyau Greengrass pour terminer une opération de publication, d'abonnement ou de désabonnement dans des connexions MQTT vers AWS IoT Core. Vous pouvez modifier ce paramètre si les opérations dépassent le délai d'attente en raison de contraintes de bande passante ou d'une latence élevée. Pour configurer ce paramètre dans le fichier config.json, ajoutez ou modifiez la propriété mqttOperationTimeout dans l'objet coreThing. Par exemple :
{ "coreThing": { "mqttOperationTimeout": 10, "caPath": "root-ca.pem", "certPath": "hash.cert.pem", "keyPath": "hash.private.key", ... }, ... }
Le délai d’attente par défaut est de 5 secondes. Le délai d'attente minimum est de 5 secondes.
Activation de la la détection IP automatique
Vous pouvez configurer AWS IoT Greengrass pour permettre aux appareils clients d'un groupe Greengrass de découvrir automatiquement le noyau de Greengrass. Lorsque cette option est activée, le cœur surveille les modifications apportées à ses adresses IP. Si une adresse change, le noyau publie une liste d'adresses mise à jour. Ces adresses sont mises à la disposition des appareils clients appartenant au même groupe Greengrass que le noyau.
Note
La AWS IoT politique relative aux appareils clients doit greengrass:Discover autoriser les appareils à récupérer des informations de connectivité pour le cœur. Pour de plus amples informations sur cette instruction de stratégie, veuillez consulter Acvery Service Service Service.
Pour activer cette fonctionnalité depuis la AWS IoT Greengrass console, choisissez Détection automatique lorsque vous déployez votre groupe Greengrass pour la première fois. Vous pouvez également activer ou désactiver cette fonctionnalité sur la page de configuration du groupe en choisissant l'onglet Fonctions Lambda et en sélectionnant le détecteur IP. La détection automatique des adresses IP est activée si l'option Détecter et remplacer automatiquement les points de terminaison du broker MQTT est sélectionnée.
Pour gérer la découverte automatique avec l'AWS IoT GreengrassAPI, vous devez configurer la fonction Lambda IPDetector du système. La procédure suivante montre comment utiliser la commande create-function-definition-versionCLI pour configurer la découverte automatique du noyau de Greengrass.
-
Obtenez les ID du groupe et de la version de groupe Greengrass cible. Cette procédure suppose qu'il s'agit de la dernière version du groupe et du groupe. La requête suivante renvoie le dernier groupe créé.
aws greengrass list-groups --query "reverse(sort_by(Groups, &CreationTimestamp))[0]"Vous pouvez également procéder à une interrogation par nom. Les noms de groupe ne devant pas nécessairement être uniques, plusieurs groupes peuvent être renvoyés.
aws greengrass list-groups --query "Groups[?Name=='MyGroup']"Note
Vous pouvez également trouver ces valeurs dans la AWS IoT console. L'ID du groupe s'affiche sur la page Paramètres du groupe. Les identifiants de version du groupe sont affichés dans l'onglet Déploiements du groupe.
-
Copiez les valeurs
LatestVersionetIddu groupe cible dans la sortie. -
Obtenez la version de groupe la plus récente.
-
Remplacez
group-idpar la propriétéIdque vous avez copiée. -
Remplacez
latest-group-version-idpar l’LatestVersionque vous avez copié.
aws greengrass get-group-version \ --group-idgroup-id\ --group-version-idlatest-group-version-id -
-
À partir de l'objet
Definitionde la sortie, copiez leCoreDefinitionVersionArnet les ARN de tous les autres composants de groupe à l'exception deFunctionDefinitionVersionArn. Vous utilisez ces valeurs lorsque vous créez une nouvelle version de groupe. -
Depuis
FunctionDefinitionVersionArndans la sortie, copiez l'ID de la définition de fonction et la version de la définition de fonction :arn:aws:greengrass:region:account-id:/greengrass/groups/function-definition-id/versions/function-definition-version-idNote
Si vous le souhaitez, vous pouvez créer une définition de fonction en exécutant la commande
create-function-definition, puis copier l'ID à partir de la sortie. -
Utilisez la commande
get-function-definition-versionpour obtenir l'état de la définition actuelle. Utilisez celuifunction-definition-idque vous avez copié pour définir la fonction. Par exemple,4d941bc7-92a1-4f45-8d64 EXAMPLEf76c3.aws greengrass get-function-definition-version --function-definition-idfunction-definition-id--function-definition-version-idfunction-definition-version-idNotez les configurations de la fonction répertoriée. Vous devez inclure ces valeurs lorsque vous créez une nouvelle version de la définition de fonction. Vous évitez ainsi de perdre les paramètres de votre définition actuelle.
-
Ajoutez une version de définition de fonction à la définition de fonction.
-
function-definition-idRemplacez-le par celuiIdque vous avez copié pour la définition de la fonction. Par exemple,4d941bc7-92a1-4f45-8d64 EXAMPLEf76c3. -
arbitrary-function-idRemplacez-le par un nom pour la fonction, tel queauto-detection-function. -
Ajoutez au
functionstableau toutes les fonctions Lambda que vous souhaitez inclure dans cette version, telles que celles répertoriées à l'étape précédente.
aws greengrass create-function-definition-version \ --function-definition-idfunction-definition-id\ --functions '[{"FunctionArn":"arn:aws:lambda:::function:GGIPDetector:1","Id":"arbitrary-function-id","FunctionConfiguration":{"Pinned":true,"MemorySize":32768,"Timeout":3}}]'\ --region us-west-2 -
-
Copiez l'
Arnde la version de définition de fonction à partir de la sortie. -
Créez une version de groupe contenant la fonction Lambda du système.
-
Remplacez
group-idpar l'Iddu groupe. -
core-definition-version-arnRemplacez-le par celuiCoreDefinitionVersionArnque vous avez copié à partir de la dernière version du groupe. -
function-definition-version-arnRemplacez-le par celuiArnque vous avez copié pour la nouvelle version de définition de fonction. -
Remplacez les ARN des autres composants de groupe (par exemple
SubscriptionDefinitionVersionArnouDeviceDefinitionVersionArn) que vous avez copiés de la version de groupe la plus récente. -
Supprimez tous les paramètres inutilisés. Par exemple, supprimez
--resource-definition-version-arnsi votre version de groupe ne contient aucune ressource.
aws greengrass create-group-version \ --group-idgroup-id\ --core-definition-version-arncore-definition-version-arn\ --function-definition-version-arnfunction-definition-version-arn\ --device-definition-version-arndevice-definition-version-arn\ --logger-definition-version-arnlogger-definition-version-arn\ --resource-definition-version-arnresource-definition-version-arn\ --subscription-definition-version-arnsubscription-definition-version-arn -
-
Copiez la
Versionà partir de la sortie. Il s'agit de l'ID de la nouvelle version de groupe. -
Déployez le groupe avec la nouvelle version de groupe.
-
Remplacez
group-idpar l'Idque vous avez copié pour le groupe. -
group-version-idRemplacez-le par celuiVersionque vous avez copié pour la nouvelle version du groupe.
aws greengrass create-deployment \ --group-idgroup-id\ --group-version-idgroup-version-id\ --deployment-type NewDeployment -
Si vous souhaitez entrer manuellement l'adresse IP de votre noyau Greengrass, vous pouvez effectuer ce didacticiel avec une autre définition de fonction, qui n'inclut pas la fonction IPDetector. Cela empêchera la fonction de détection de localiser et de saisir automatiquement votre adresse IP principale de Greengrass.
Cette fonction Lambda du système n'est pas visible dans la console Lambda. Lorsque la fonction est ajoutée à la version de groupe la plus récente, elle est incluse dans les déploiements que vous effectuez à partir de la console, sauf si vous utilisez l'API pour la remplacer ou la supprimer.
Configuration du système d'initialisation pour le lancement du démon Greengrass
Il est recommandé de configurer votre système d'initialisation de manière à lancer le démon Greengrass au démarrage système, en particulier lorsque vous gérez d'importantes flottes d'appareils.
Note
Si vous avez utilisé apt pour installer le logiciel AWS IoT Greengrass Core, vous pouvez utiliser les scripts systemd pour activer le lancement au démarrage. Pour plus d’informations, consultez Utiliser des scripts systemd pour gérer le cycle de vie du démon Greengrass.
Il existe différents types de système d'initialisation, par exemple initd, systemd et SystemV, qui utilisent des paramètres de configuration similaires. L'exemple suivant est un fichier de service pour systemd. Le paramètre Type est défini sur forking, car greengrassd (utilisé pour lancer Greengrass) duplique le processus du démon Greengrass, et le paramètre Restart est défini sur on-failure pour demander à systemd de relancer Greengrass si celui-ci entre dans un état d'échec.
Note
Pour voir si votre appareil utilise systemd, exécutez le script check_ggc_dependencies comme décrit dans Module 1. Ensuite, pour utiliser systemd, assurez-vous que le paramètre useSystemd dans config.json est défini sur yes.
[Unit] Description=Greengrass Daemon [Service] Type=forking PIDFile=/var/run/greengrassd.pid Restart=on-failure ExecStart=/greengrass/ggc/core/greengrassd start ExecReload=/greengrass/ggc/core/greengrassd restart ExecStop=/greengrass/ggc/core/greengrassd stop [Install] WantedBy=multi-user.target
Consultez aussi
