Avis de fin de support : le 7 octobre 2026, AWS le support de. AWS IoT Greengrass Version 1 Après le 7 octobre 2026, vous ne pourrez plus accéder aux AWS IoT Greengrass V1 ressources. Pour plus d'informations, rendez-vous sur [Migrer depuis AWS IoT Greengrass Version 1](https://docs.aws.amazon.com/greengrass/v2/developerguide/migrate-from-v1.html).
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.
# Exécuter les fonctions Lambda sur le noyau AWS IoT Greengrass
AWS IoT Greengrass fournit un environnement d'exécution Lambda conteneurisé pour le code défini par l'utilisateur dans lequel vous créez. AWS Lambda Les fonctions Lambda déployées sur un AWS IoT Greengrass cœur s'exécutent dans le runtime Lambda local du cœur. Les fonctions Lambda locales peuvent être déclenchées par des événements locaux, des messages provenant du cloud et d'autres sources, ce qui apporte des fonctionnalités de calcul locales aux appareils clients. Par exemple, vous pouvez utiliser les fonctions Lambda de Greengrass pour filtrer les données des appareils avant de les transmettre au cloud.
Pour déployer une fonction Lambda sur un noyau, vous ajoutez la fonction à un groupe Greengrass (en référençant la fonction Lambda existante), vous configurez les paramètres spécifiques au groupe pour la fonction, puis vous déployez le groupe. Si la fonction accède AWS aux services, vous devez également ajouter les autorisations requises au rôle de groupe [Greengrass](group-role.md).
Vous pouvez configurer les paramètres qui déterminent le mode d'exécution des fonctions Lambda, notamment les autorisations, l'isolation, les limites de mémoire, etc. Pour de plus amples informations, veuillez consulter [Contrôle de l'exécution des fonctions Greengrass Lambda à l'aide d'une configuration spécifique au groupe](lambda-group-config.md).
**Note**
Ces paramètres permettent également de l'exécuter AWS IoT Greengrass dans un conteneur Docker. Pour de plus amples informations, veuillez consulter [Exécution AWS IoT Greengrass dans un conteneur Docker](run-gg-in-docker-container.md).
Le tableau suivant répertorie les environnements d'[AWS Lambda exécution pris](https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html) en charge et les versions du logiciel AWS IoT Greengrass Core sur lesquelles ils peuvent être exécutés.
****
| Langage ou plateforme | Version de GGC |
| --- | --- |
| Python 3.8 | 1.11 |
| Python 3.7 | 1.9 ou version ultérieure |
| Python 2.7 \$1 | 1.0 ou version ultérieure |
| Java 8 | 1.1 ou version ultérieure |
| Node.js 12,x \$1 | 1.10 ou version ultérieure |
| Node.js 8.10 \$1 | 1.9 ou version ultérieure |
| Node.js 6.10 \$1 | 1.1 ou version ultérieure |
| C, C\$1\$1 | 1.6 ou version ultérieure |
\$1 Vous pouvez exécuter des fonctions Lambda qui utilisent ces environnements d'exécution sur les versions prises en charge de AWS IoT Greengrass, mais vous ne pouvez pas les créer dans. AWS Lambda Si le runtime de votre appareil est différent du runtime AWS Lambda spécifié pour cette fonction, vous pouvez choisir votre propre environnement d'exécution en utilisant `FunctionRuntimeOverride` in. `FunctionDefintionVersion` Pour de plus amples informations, veuillez consulter [CreateFunctionDefinition](https://docs.aws.amazon.com/greengrass/v1/apireference/createfunctiondefinition-post.html). Pour plus d'informations sur les environnements d'exécution pris en charge, consultez la [politique de support des environnements d'exécution](https://docs.aws.amazon.com/lambda/latest/dg/runtime-support-policy.html) dans le *manuel du AWS Lambda développeur*.
## SDKs pour les fonctions Greengrass Lambda
AWS en fournit trois SDKs qui peuvent être utilisées par les fonctions Lambda de Greengrass exécutées sur un noyau. AWS IoT Greengrass Ils SDKs sont contenus dans différents packages, de sorte que les fonctions peuvent les utiliser simultanément. Pour utiliser un SDK dans une fonction Lambda Greengrass, incluez-le dans le package de déploiement de la fonction Lambda vers lequel vous le téléchargez. AWS Lambda
**AWS IoT Greengrass SDK de base**
Permet aux fonctions Lambda locales d'interagir avec le cœur pour :
+ Échangez des messages MQTT avec AWS IoT Core.
+ Échangez des messages MQTT avec des connecteurs, des appareils clients et d'autres fonctions Lambda du groupe Greengrass.
+ Interagissez avec le service shadow local.
+ Appelez d'autres fonctions Lambda locales.
+ Accédez aux [ressources de secret](secrets.md).
+ Interagissez avec le [gestionnaire de flux](stream-manager.md).
AWS IoT Greengrass fournit le SDK de AWS IoT Greengrass base dans les langues et plateformes suivantes sur GitHub.
+ [AWS IoT Greengrass SDK de base pour Java](https://github.com/aws/aws-greengrass-core-sdk-java/)
+ [AWS IoT Greengrass SDK de base pour Node.js](https://github.com/aws/aws-greengrass-core-sdk-js/)
+ [AWS IoT Greengrass SDK de base pour Python](https://github.com/aws/aws-greengrass-core-sdk-python/)
+ [AWS IoT Greengrass SDK de base pour C](https://github.com/aws/aws-greengrass-core-sdk-c/)
Pour inclure la dépendance du SDK AWS IoT Greengrass principal dans le package de déploiement de la fonction Lambda :
1. Téléchargez la langue ou la plate-forme du package AWS IoT Greengrass Core SDK correspondant au temps d'exécution de votre fonction Lambda.
1. Décompressez le package téléchargé pour obtenir le kit SDK. Le kit SDK est représenté par le dossier `greengrasssdk`.
1. Incluez-le `greengrasssdk` dans le package de déploiement de la fonction Lambda qui contient votre code de fonction. Il s'agit du package dans lequel vous téléchargez la fonction Lambda AWS Lambda lorsque vous créez la fonction Lambda.
**StreamManagerClient**
Seul le AWS IoT Greengrass Core suivant SDKs peut être utilisé pour les opérations [du gestionnaire de flux](stream-manager.md) :
+ SDK Java (v1.4.0 ou version ultérieure)
+ SDK Python (v1.5.0 ou version ultérieure)
+ SDK Node.js (v1.6.0 ou version ultérieure)
Pour utiliser le SDK AWS IoT Greengrass Core pour Python afin d'interagir avec le gestionnaire de flux, vous devez installer Python 3.7 ou version ultérieure. Vous devez également installer les dépendances à inclure dans vos packages de déploiement de fonctions Python Lambda :
1. Accédez au répertoire SDK qui contient le fichier `requirements.txt`. Ce fichier répertorie les dépendances.
1. Installez les dépendances du kit SDK. Par exemple, exécutez la commande `pip` suivante pour les installer dans le répertoire en cours :
```
pip install --target . -r requirements.txt
```
**Installez le SDK AWS IoT Greengrass Core pour Python sur l'appareil principal**
Si vous exécutez des fonctions Lambda en Python, vous pouvez également les utiliser [https://pypi.org/project/pip/](https://pypi.org/project/pip/)pour installer le SDK AWS IoT Greengrass Core pour Python sur le périphérique principal. Vous pouvez ensuite déployer vos fonctions sans inclure le SDK dans le package de déploiement des fonctions Lambda. Pour plus d'informations, consultez [greengrasssdk](https://pypi.org/project/greengrasssdk/).
Cette prise en charge est destinée aux noyaux avec des contraintes de taille. Nous vous recommandons d'inclure le SDK dans vos packages de déploiement de fonctions Lambda lorsque cela est possible.
**AWS IoT Greengrass Kit de développement logiciel pour le Machine Learning**
Permet aux fonctions Lambda locales d'utiliser des modèles d'apprentissage automatique (ML) déployés sur le cœur de Greengrass sous forme de ressources ML. Les fonctions Lambda peuvent utiliser le SDK pour appeler et interagir avec un service d'inférence local déployé au cœur en tant que connecteur. Les fonctions Lambda et les connecteurs ML peuvent également utiliser le SDK pour envoyer des données au connecteur ML Feedback à des fins de téléchargement et de publication. Pour plus d'informations, y compris des exemples de code qui utilisent le kit SDK, consultez [Connecteur de classification d'images ML](image-classification-connector.md), [Connecteur de détection d'objets ML](obj-detection-connector.md) et [Connecteur ML Feedback](ml-feedback-connector.md).
Le tableau suivant répertorie les langages ou plateformes pris en charge pour les versions du SDK et les versions du logiciel AWS IoT Greengrass Core sur lesquelles elles peuvent être exécutées.
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/greengrass/v1/developerguide/lambda-functions.html)
Pour obtenir des informations sur le téléchargement, consultez [AWS IoT Greengrass Logiciel ML SDK](what-is-gg.md#gg-ml-sdk-download).
**AWS SDKs**
Permet aux fonctions Lambda locales d'effectuer des appels directs vers AWS des services tels qu'Amazon S3, DynamoDB et. AWS IoT AWS IoT Greengrass Pour utiliser un AWS SDK dans une fonction Greengrass Lambda, vous devez l'inclure dans votre package de déploiement. Lorsque vous utilisez le AWS SDK dans le même package que le SDK AWS IoT Greengrass principal, assurez-vous que vos fonctions Lambda utilisent les espaces de noms corrects. Les fonctions Greengrass Lambda ne peuvent pas communiquer avec les services cloud lorsque le cœur est hors ligne.
Téléchargez-le AWS SDKs depuis le [centre de ressources pour la mise en route](https://aws.amazon.com/getting-started/tools-sdks/).
Pour plus d'informations sur la création d'un package de déploiement, reportez-vous [Création et empaquetage d'une fonction Lambda](create-lambda.md) au didacticiel de démarrage ou à la [création d'un package de déploiement](https://docs.aws.amazon.com/lambda/latest/dg/deployment-package-v2.html) dans le *guide du AWS Lambda développeur*.
### Migration de fonctions Lambda basées sur le cloud
Le SDK AWS IoT Greengrass principal suit le modèle de programmation du AWS SDK, qui facilite le portage des fonctions Lambda développées pour le cloud vers des fonctions Lambda exécutées sur un cœur. AWS IoT Greengrass
Par exemple, la fonction Lambda Python suivante utilise le AWS SDK pour Python (Boto3) pour publier un message sur le sujet `some/topic` dans le cloud :
```
import boto3
iot_client = boto3.client("iot-data")
response = iot_client.publish(
topic="some/topic", qos=0, payload="Some payload".encode()
)
```
Pour porter la fonction pour un AWS IoT Greengrass noyau, dans l'`import`instruction et l'`client`initialisation, remplacez le nom du `boto3` module par`greengrasssdk`, comme indiqué dans l'exemple suivant :
```
import greengrasssdk
iot_client = greengrasssdk.client("iot-data")
iot_client.publish(topic="some/topic", qos=0, payload="Some payload".encode())
```
**Note**
Le SDK AWS IoT Greengrass principal prend en charge l'envoi de messages MQTT avec QoS = 0 uniquement. Pour de plus amples informations, veuillez consulter [Message de qualité de service](gg-core.md#message-quality-of-service).
La similitude entre les modèles de programmation vous permet également de développer vos fonctions Lambda dans le cloud, puis de les migrer vers celles-ci AWS IoT Greengrass avec un minimum d'effort. [Les exécutables Lambda](#lambda-executables) ne s'exécutent pas dans le cloud. Vous ne pouvez donc pas utiliser le AWS SDK pour les développer dans le cloud avant le déploiement.
## Référencer les fonctions Lambda par alias ou par version
Les groupes Greengrass peuvent référencer une fonction Lambda par alias (recommandé) ou par version. L'utilisation d'un alias facilite la gestion des mises à jour du code, car vous n'avez pas à modifier votre table d'abonnement ou la définition de groupe lorsque le code de fonction est mis à jour. Au lieu de cela, il vous suffit de pointer l'alias vers la nouvelle version de la fonction. Les alias sont convertis en numéros de version lors du déploiement en groupe. Lorsque vous utilisez des alias, la version résolue est mise à jour dans la version vers laquelle l'alias pointe au moment de déploiement.
AWS IoT Greengrass **ne prend pas en charge les alias Lambda pour les versions \$1LATEST.** Les versions **\$1LATEST** ne sont pas liées à des versions de fonctions immuables publiées et peuvent être modifiées à tout moment, ce qui va à l'encontre du AWS IoT Greengrass principe d'immuabilité des versions.
Une pratique courante pour maintenir vos fonctions Greengrass Lambda à jour en cas de modification du code consiste à utiliser un alias nommé dans votre groupe Greengrass et dans **PRODUCTION** vos abonnements. Lorsque vous mettez en production de nouvelles versions de votre fonction Lambda, pointez l'alias vers la dernière version stable, puis redéployez le groupe. Vous pouvez également utiliser cette méthode pour restaurer une version précédente.
# Contrôle de l'exécution des fonctions Greengrass Lambda à l'aide d'une configuration spécifique au groupe
AWS IoT Greengrass fournit une gestion basée sur le cloud des fonctions de Greengrass Lambda. Bien que le code et les dépendances d'une fonction Lambda soient gérés à l'aide de cette méthode AWS Lambda, vous pouvez configurer le comportement de la fonction Lambda lorsqu'elle s'exécute dans un groupe Greengrass.
## Paramètre de configuration spécifiques au groupe
AWS IoT Greengrass fournit les paramètres de configuration spécifiques au groupe suivants pour les fonctions Greengrass Lambda.
**Utilisateur et groupe du système**
Identité d'accès utilisée pour exécuter une fonction Lambda. Par défaut, les fonctions Lambda s'exécutent en tant qu'identité d'[accès par défaut](#lambda-access-identity-groupsettings) du groupe. En général, il s'agit des comptes AWS IoT Greengrass standard (ggc\$1user et ggc\$1group). Vous pouvez modifier le paramètre et choisir l'ID utilisateur et l'ID de groupe disposant des autorisations requises pour exécuter la fonction Lambda. Vous pouvez remplacer les deux champs UID et GID ou un seul des deux si vous laissez l'autre champ vide. Ce paramètre vous donne un contrôle plus précis sur l'accès aux ressources de l'appareil. Nous vous recommandons de configurer votre matériel Greengrass avec des limites de ressources, des autorisations de fichiers et des quotas de disque appropriés pour les utilisateurs et les groupes dont les autorisations sont utilisées pour exécuter les fonctions Lambda.
Cette fonctionnalité est disponible pour AWS IoT Greengrass Core v1.7 et versions ultérieures.
Nous vous recommandons d'éviter d'exécuter des fonctions Lambda en tant qu'utilisateur root, sauf en cas de nécessité absolue. Le fait de s'exécuter en tant que root augmente les risques suivants :
+ Le risque de modifications involontaires, telles que la suppression accidentelle d'un fichier critique.
+ Le risque que des personnes mal intentionnées représentent pour vos données et votre appareil.
+ Le risque lié au conteneur disparaît lorsque les conteneurs Docker fonctionnent avec `--net=host` et. `UID=EUID=0`
Si vous devez exécuter en tant que root, vous devez mettre à jour la AWS IoT Greengrass configuration pour l'activer. Pour de plus amples informations, veuillez consulter [Exécution d'une fonction Lambda en tant que root](#lambda-running-as-root).
**ID utilisateur du système (numéro)**
ID utilisateur de l'utilisateur disposant des autorisations requises pour exécuter la fonction Lambda. Ce paramètre n'est disponible que si vous choisissez de l'exécuter en tant qu'**autre ID utilisateur/ID de groupe**. Vous pouvez utiliser la **getent passwd** commande sur votre appareil AWS IoT Greengrass principal pour rechercher l'ID utilisateur que vous souhaitez utiliser pour exécuter la fonction Lambda.
Si vous utilisez le même UID pour exécuter des processus et la fonction Lambda sur un appareil principal de Greengrass, votre rôle de groupe Greengrass peut accorder des informations d'identification temporaires aux processus. Les processus peuvent utiliser les informations d'identification temporaires dans les déploiements principaux de Greengrass.
**ID du groupe de systèmes (numéro)**
ID de groupe du groupe disposant des autorisations requises pour exécuter la fonction Lambda. Ce paramètre n'est disponible que si vous choisissez de l'exécuter en tant qu'**autre nom d' ID/group utilisateur**. Vous pouvez utiliser la **getent group** commande sur votre appareil AWS IoT Greengrass principal pour rechercher l'ID de groupe que vous souhaitez utiliser pour exécuter la fonction Lambda.
**Conteneurisation de la fonction Lambda**
Choisissez si la fonction Lambda s'exécute avec la conteneurisation par défaut pour le groupe ou spécifiez la conteneurisation qui doit toujours être utilisée pour cette fonction Lambda.
Le mode de conteneurisation d'une fonction Lambda détermine son niveau d'isolation.
+ **Les fonctions Lambda conteneurisées s'exécutent en mode conteneur Greengrass.** La fonction Lambda s'exécute dans un environnement d'exécution (ou espace de noms) isolé à l'intérieur du conteneur. AWS IoT Greengrass
+ **Les fonctions Lambda non conteneurisées s'exécutent en mode Sans conteneur.** Les fonctions Lambda s'exécutent comme un processus Linux normal sans aucune isolation.
Cette fonctionnalité est disponible pour AWS IoT Greengrass Core v1.7 et versions ultérieures.
Nous vous recommandons d'exécuter les fonctions Lambda dans un conteneur Greengrass, sauf si votre cas d'utilisation exige qu'elles s'exécutent sans conteneurisation. Lorsque vos fonctions Lambda s'exécutent dans un conteneur Greengrass, vous pouvez utiliser les ressources locales et périphériques associées et bénéficier des avantages de l'isolation et d'une sécurité accrue. Avant de modifier la conteneurisation, consultez [Considérations à prendre en compte lors du choix de la conteneurisation des fonctions Lambda](#lambda-containerization-considerations).
Pour s'exécuter sans activer l'espace de noms et le groupe de noms du noyau de votre appareil, toutes vos fonctions Lambda doivent s'exécuter sans conteneurisation. Vous pouvez effectuer cette opération facilement en définissant la conteneurisation par défaut pour le groupe. Pour plus d'informations, consultez [Configuration de la conteneurisation par défaut pour les fonctions Lambda dans un groupe](#lambda-containerization-groupsettings).
**Limite de mémoire**
L'allocation de mémoire pour la fonction. La valeur par défaut est 16 Mo.
Le paramètre de limite de mémoire devient indisponible lorsque vous modifiez la fonction Lambda pour qu'elle s'exécute sans conteneurisation. Les fonctions Lambda qui s'exécutent sans conteneurisation n'ont aucune limite de mémoire. Le paramètre de limite de mémoire est supprimé lorsque vous modifiez le paramètre de conteneurisation par défaut de la fonction Lambda ou du groupe pour qu'il s'exécute sans conteneurisation.
**Expiration**
La durée avant laquelle la fonction ou la demande est mise hors service. Le durée par défaut est de 3 secondes.
**Épinglé**
*Le cycle de vie d'une fonction Lambda peut être *à la demande* ou de longue durée.* La valeur par défaut est à la demande.
Une fonction Lambda à la demande démarre dans un conteneur neuf ou réutilisé lorsqu'elle est invoquée. Les demandes envoyées à la fonction peuvent être traitées par n'importe quel conteneur disponible. Une fonction Lambda de longue durée (ou *épinglée*) démarre automatiquement après le démarrage et continue de s'exécuter dans son AWS IoT Greengrass propre conteneur (ou bac à sable). Toutes les demandes envoyées à la fonction sont traitées par le même conteneur. Pour de plus amples informations, veuillez consulter [Configuration du cycle de vie pour les fonctions Greengrass Lambda](lambda-functions.md#lambda-lifecycle).
**Accès en lecture au répertoire /sys**
Indique si la fonction peut accéder au dossier /sys de l'hôte. Utilisez cette option lorsque la fonction doit lire les informations sur les appareils depuis le répertoire /sys. La valeur par défaut est false.
Ce paramètre n'est pas disponible lorsque vous exécutez une fonction Lambda sans conteneurisation. La valeur de ce paramètre est supprimée lorsque vous modifiez la fonction Lambda pour qu'elle s'exécute sans conteneurisation.
**Type d'encodage**
Le type d'encodage attendu de charge utile d'entrée pour la fonction, JSON ou binaire. La valeur par défaut est JSON.
Support pour le type de codage binaire est disponible à partir de AWS IoT Greengrass Core Software v1.5.0 et AWS IoT Greengrass Core SDK v1.1.0. L'acception des données d'entrée binaires peut être utile pour les fonctions qui interagissent avec les données de l'appareil ; en effet, à cause des capacités matérielles restreintes des appareils, il est souvent difficile, voire impossible, pour eux de construire un type de données JSON.
Les [exécutables Lambda](lambda-functions.md#lambda-executables) ne prennent en charge que le type de codage binaire, et non le JSON.
**Arguments du processus**
Les arguments de la ligne de commande sont transmis à la fonction Lambda lors de son exécution.
**Variables d'environnement**
Paires clé-valeur qui peuvent transférer dynamiquement des paramètres au code de fonction et aux bibliothèques. Les variables d'environnement locales fonctionnent de la même manière que les [variables d'environnement de fonction AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/env_variables.html), mais sont disponibles dans l'environnement principal.
**Stratégies d'accès aux ressources**
Liste d'un maximum de 10 [ressources locales](access-local-resources.md), de [ressources secrètes](secrets.md) et de [ressources d'apprentissage automatique](ml-inference.md) auxquelles la fonction Lambda est autorisée à accéder, ainsi que l'autorisation correspondante`read-only`. `read-write` Dans la console, ces ressources *affiliées* sont répertoriées sur la page de configuration du groupe dans l'onglet **Ressources**.
Le [mode de conteneurisation](#lambda-function-containerization) affecte la manière dont les fonctions Lambda peuvent accéder aux ressources locales des appareils et des volumes ainsi qu'aux ressources d'apprentissage automatique.
+ Les fonctions Lambda non conteneurisées doivent accéder aux ressources locales du périphérique et du volume directement via le système de fichiers du périphérique principal.
+ Pour permettre aux fonctions Lambda non conteneurisées d'accéder aux ressources d'apprentissage automatique du groupe Greengrass, vous devez définir le propriétaire de la ressource et les propriétés des autorisations d'accès sur la ressource d'apprentissage automatique. Pour de plus amples informations, veuillez consulter [Accédez aux ressources d'apprentissage automatique à partir des fonctions Lambda](access-ml-resources.md).
*Pour plus d'informations sur l'utilisation de l' AWS IoT Greengrass API pour définir des paramètres de configuration spécifiques au groupe pour les fonctions Lambda définies par l'utilisateur, [CreateFunctionDefinition](https://docs.aws.amazon.com/greengrass/v1/apireference/createfunctiondefinition-post.html)reportez-vous à *AWS IoT Greengrass Version 1 la référence de l'API [create-function-definition](https://docs.aws.amazon.com/cli/latest/reference/greengrass/create-function-definition.html)ou à la* référence des commandes.AWS CLI * [Pour déployer des fonctions Lambda sur un noyau Greengrass, créez une version de définition de fonction contenant vos fonctions, créez une version de groupe qui fait référence à la version de définition de fonction et à d'autres composants du groupe, puis déployez le groupe.](deployments.md)
## Exécution d'une fonction Lambda en tant que root
Cette fonctionnalité est disponible pour AWS IoT Greengrass Core v1.7 et versions ultérieures.
Avant de pouvoir exécuter une ou plusieurs fonctions Lambda en tant qu'utilisateur root, vous devez d'abord mettre à jour la AWS IoT Greengrass configuration pour activer le support. Support pour l'exécution des fonctions Lambda en tant que root est désactivé par défaut. Le déploiement échoue si vous essayez de déployer une fonction Lambda et de l'exécuter en tant que root (UID et GID de 0) et que vous n'avez pas mis à jour la configuration. AWS IoT Greengrass Une erreur comme celle-ci apparaît dans le journal d'exécution (*greengrass\$1root*/ggc/var/log/system/runtime.log) :
```
lambda(s)
[list of function arns] are configured to run as root while Greengrass is not configured to run lambdas with root permissions
```
**Important**
Nous vous recommandons d'éviter d'exécuter des fonctions Lambda en tant qu'utilisateur root, sauf en cas de nécessité absolue. Le fait de s'exécuter en tant que root augmente les risques suivants :
Le risque de modifications involontaires, telles que la suppression accidentelle d'un fichier critique.
Le risque que des personnes mal intentionnées représentent pour vos données et votre appareil.
Le risque lié au conteneur disparaît lorsque les conteneurs Docker fonctionnent avec `--net=host` et. `UID=EUID=0`
**Pour autoriser les fonctions Lambda à s'exécuter en tant qu'utilisateur root**
1. Sur votre AWS IoT Greengrass appareil, accédez au dossier *greengrass-root* /config.
**Note**
Par défaut, *greengrass-root* c'est le répertoire /greengrass.
1. Modifiez le fichier config.json pour ajouter `"allowFunctionsToRunAsRoot" : "yes"` au champ `runtime`. Par exemple :
```
{
"coreThing" : {
...
},
"runtime" : {
...
"allowFunctionsToRunAsRoot" : "yes"
},
...
}
```
1. Utilisez les commandes suivantes pour redémarrer AWS IoT Greengrass :
```
cd /greengrass/ggc/core
sudo ./greengrassd restart
```
Vous pouvez désormais définir l'ID utilisateur et l'ID de groupe (UID/GID) des fonctions Lambda sur 0 pour exécuter cette fonction Lambda en tant qu'utilisateur root.
Vous pouvez modifier la valeur de `"allowFunctionsToRunAsRoot"` to `"no"` et restart AWS IoT Greengrass si vous souhaitez interdire aux fonctions Lambda de s'exécuter en tant qu'utilisateur root.
## Considérations à prendre en compte lors du choix de la conteneurisation des fonctions Lambda
Cette fonctionnalité est disponible pour AWS IoT Greengrass Core v1.7 et versions ultérieures.
Par défaut, les fonctions Lambda s'exécutent dans un AWS IoT Greengrass conteneur. Ce conteneur assure l'isolement entre vos fonctions et l'hôte, ce qui vous offre davantage de sécurité à la fois pour l'hôte et les fonctions dans le conteneur.
Nous vous recommandons d'exécuter les fonctions Lambda dans un conteneur Greengrass, sauf si votre cas d'utilisation exige qu'elles s'exécutent sans conteneurisation. En exécutant vos fonctions Lambda dans un conteneur Greengrass, vous pouvez mieux contrôler la restriction de l'accès aux ressources.
Voici quelques exemples de cas d'exécution sans conteneurisation :
+ Vous souhaitez exécuter AWS IoT Greengrass sur un appareil qui ne supporte pas le mode conteneur (par exemple, parce que vous utilisez une distribution Linux spéciale ou que vous avez une version du noyau trop ancienne).
+ Vous souhaitez exécuter votre fonction Lambda dans un autre environnement de conteneurs avec son propre OverlayFS, mais vous rencontrez des conflits OverlayFS lorsque vous l'exécutez dans un conteneur Greengrass.
+ Vous devez avoir accès aux ressources locales avec des chemins qui ne peuvent pas être déterminés lors du déploiement ou dont le chemin peut changer après le déploiement, notamment avec certains appareils enfichables.
+ Vous avez une ancienne application écrite en tant que processus et vous avez rencontré des problèmes lors de son exécution en tant que fonction Lambda conteneurisée.
**Différences de conteneurisation**
| Conteneurisation | Remarques |
| --- | --- |
| Conteneur Greengrass | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/greengrass/v1/developerguide/lambda-group-config.html) |
| Aucun conteneur | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/greengrass/v1/developerguide/lambda-group-config.html) |
**Note**
Le paramètre de conteneurisation par défaut pour le groupe Greengrass ne s'applique pas aux [connecteurs](connectors.md).
La modification de la conteneurisation d'une fonction Lambda peut entraîner des problèmes lors de son déploiement. Si vous avez affecté à votre fonction Lambda des ressources locales qui ne sont plus disponibles avec vos nouveaux paramètres de conteneurisation, le déploiement échoue.
+ Lorsque vous remplacez l'exécution d'une fonction Lambda dans un conteneur Greengrass par une fonction sans conteneurisation, les limites de mémoire de la fonction sont supprimées. Vous devez accéder au système de fichiers directement au lieu d'utiliser les ressources locales attachées. Vous devez supprimer les ressources attachées avant le déploiement.
+ Lorsque vous passez d'une fonction Lambda exécutée sans conteneurisation à une fonction Lambda exécutée dans un conteneur, votre fonction Lambda perd l'accès direct au système de fichiers. Vous devez définir une limite de mémoire pour chaque fonction ou accepter la valeur par défaut de 16 Mo. Vous pouvez configurer ces paramètres pour chaque fonction Lambda avant le déploiement.
**Pour modifier les paramètres de conteneurisation d'une fonction Lambda**
1. Dans le volet de navigation de la AWS IoT console, sous **Gérer**, développez les **appareils Greengrass**, puis choisissez **Groups (V1)**.
1. Choisissez le groupe contenant la fonction Lambda dont vous souhaitez modifier les paramètres.
1. Choisissez l'onglet **Fonctions Lambda.**
1. **Sur la fonction Lambda que vous souhaitez modifier, choisissez les points de suspension (**...**), puis choisissez Modifier la configuration.**
1. Modifiez les paramètres de conteneurisation. Si vous configurez la fonction Lambda pour qu'elle s'exécute dans un conteneur Greengrass, vous devez également définir une **limite de mémoire** et un **accès en lecture au** répertoire /sys.
1. Choisissez **Enregistrer** puis **Confirmer** pour enregistrer les modifications apportées à votre fonction Lambda.
Les modifications prennent effet lorsque le groupe est déployé.
Vous pouvez également utiliser le [CreateFunctionDefinition](https://docs.aws.amazon.com/greengrass/v1/apireference/createfunctiondefinition-post.html)et [CreateFunctionDefinitionVersion](https://docs.aws.amazon.com/greengrass/v1/apireference/createfunctiondefinitionversion-post.html)dans la *référence AWS IoT Greengrass d'API*. Si vous modifiez le paramètre conteneurisation, veillez également à mettre à jour les autres paramètres. Par exemple, si vous passez de l'exécution d'une fonction Lambda dans un conteneur Greengrass à une exécution sans conteneurisation, veillez à effacer le paramètre. `MemorySize`
### Déterminer les modes d'isolement pris en charge par votre appareil Greengrass
Vous pouvez utiliser le vérificateur de AWS IoT Greengrass dépendance pour déterminer quels modes d'isolation (conteneur container/no Greengrass) sont pris en charge par votre appareil Greengrass.
**Pour exécuter le vérificateur AWS IoT Greengrass de dépendance**
1. Téléchargez et exécutez le vérificateur de AWS IoT Greengrass dépendance depuis le [GitHubréférentiel](https://github.com/aws-samples/aws-greengrass-samples).
```
wget https://github.com/aws-samples/aws-greengrass-samples/raw/master/greengrass-dependency-checker-GGCv1.11.x.zip
unzip greengrass-dependency-checker-GGCv1.11.x.zip
cd greengrass-dependency-checker-GGCv1.11.x
sudo modprobe configs
sudo ./check_ggc_dependencies | more
```
1. Là où `more` s'affiche, appuyez sur la touche Spacebar pour afficher une autre page de texte.
Pour en savoir plus sur la commande **modprobe**, exécutez **man modprobe** dans le terminal.
## Définition de l'identité d'accès par défaut pour les fonctions Lambda dans un groupe
Cette fonctionnalité est disponible pour AWS IoT Greengrass Core v1.8 et versions ultérieures.
Pour mieux contrôler l'accès aux ressources de l'appareil, vous pouvez configurer l'identité d'accès par défaut utilisée pour exécuter les fonctions Lambda dans le groupe. Ce paramètre détermine les autorisations par défaut accordées à vos fonctions Lambda lorsqu'elles s'exécutent sur le périphérique principal. Pour remplacer la configuration pour des fonctions individuelles dans le groupe, vous pouvez utiliser la propriété **Run as (Exécuter en tant que)** de la fonction. Pour plus d'informations, consultez [Run as (Exécuter en tant que)](#lambda-access-identity).
Ce paramètre au niveau du groupe est également utilisé pour exécuter le logiciel AWS IoT Greengrass Core sous-jacent. Il s'agit de fonctions Lambda du système qui gèrent les opérations, telles que le routage des messages, la synchronisation instantanée locale et la détection automatique des adresses IP.
L'identité d'accès par défaut peut être configurée pour fonctionner en tant que comptes AWS IoT Greengrass système standard (ggc\$1user et ggc\$1group) ou pour utiliser les autorisations d'un autre utilisateur ou groupe. Nous vous recommandons de configurer votre matériel Greengrass avec des limites de ressources, des autorisations de fichiers et des quotas de disque appropriés pour tous les utilisateurs et groupes dont les autorisations sont utilisées pour exécuter des fonctions Lambda définies par l'utilisateur ou du système.
**Pour modifier l'identité d'accès par défaut de votre AWS IoT Greengrass groupe**
1. Dans le volet de navigation de la AWS IoT console, sous **Gérer**, développez les **appareils Greengrass**, puis choisissez **Groups (V1)**.
1. Choisissez le groupe dont vous voulez modifier les paramètres.
1. **Choisissez l'onglet **Fonctions Lambda** et, dans la section **Environnement d'exécution des fonctions Lambda par défaut**, sélectionnez Modifier.**
1. Sur la page **Modifier l'environnement d'exécution de la fonction Lambda par défaut**, sous **Utilisateur et groupe du système par défaut**, sélectionnez **Autre ID utilisateur/ID** de groupe.
Lorsque vous choisissez cette option, les champs **ID utilisateur du système (numéro)** et **ID de groupe système (numéro)** s'affichent.
1. Saisissez un ID d'utilisateur, un ID de groupe, ou les deux. Si vous ne remplissez pas l'un des champs, le numéro correspondant du compte système Greengrass (ggc\$1user ou ggc\$1group) est utilisé.
+ Dans **le champ ID utilisateur du système (numéro)**, entrez l'ID utilisateur de l'utilisateur qui dispose des autorisations que vous souhaitez utiliser par défaut pour exécuter les fonctions Lambda dans le groupe. Vous pouvez utiliser la commande **getent passwd** sur votre appareil AWS IoT Greengrass pour rechercher l'ID d'utilisateur.
+ Dans **le champ ID du groupe système (numéro)**, entrez l'ID du groupe qui dispose des autorisations que vous souhaitez utiliser par défaut pour exécuter les fonctions Lambda dans le groupe. Vous pouvez utiliser la commande **getent group** sur votre appareil AWS IoT Greengrass pour rechercher l'ID de groupe.
**Important**
Une exécution en tant qu'utilisateur racine fait peser plus de risques sur vos données et appareils. Ne procédez pas à une exécution en tant qu'utilisateur racine (UID/GID=0), sauf si cela s'avère nécessaire pour votre scénario. Pour de plus amples informations, veuillez consulter [Exécution d'une fonction Lambda en tant que root](#lambda-running-as-root).
Les modifications prennent effet lorsque le groupe est déployé.
## Configuration de la conteneurisation par défaut pour les fonctions Lambda dans un groupe
Cette fonctionnalité est disponible pour AWS IoT Greengrass Core v1.7 et versions ultérieures.
Le paramètre de conteneurisation d'un groupe Greengrass détermine la conteneurisation par défaut pour les fonctions Lambda du groupe.
+ En mode **conteneur Greengrass**, les fonctions Lambda s'exécutent par défaut dans un environnement d'exécution isolé à l'intérieur du AWS IoT Greengrass conteneur.
+ En mode **sans conteneur**, les fonctions Lambda s'exécutent par défaut comme des processus Linux classiques.
Vous pouvez modifier les paramètres du groupe pour spécifier la conteneurisation par défaut pour les fonctions Lambda du groupe. Vous pouvez remplacer ce paramètre pour une ou plusieurs fonctions Lambda du groupe si vous souhaitez que les fonctions Lambda s'exécutent avec une conteneurisation différente de la valeur par défaut du groupe. Avant de modifier les paramètres de conteneurisation, consultez [Considérations à prendre en compte lors du choix de la conteneurisation des fonctions Lambda](#lambda-containerization-considerations).
**Important**
Si vous souhaitez modifier la conteneurisation par défaut du groupe, mais qu'une ou plusieurs fonctions utilisent une conteneurisation différente, modifiez les paramètres des fonctions Lambda avant de modifier les paramètres du groupe. Si vous modifiez le paramètre de conteneurisation du groupe en premier, les valeurs des paramètres **Limite de mémoire** et **Accès en lecture au répertoire /sys** sont ignorées.
**Pour modifier les paramètres de conteneurisation de votre groupe AWS IoT Greengrass**
1. Dans le volet de navigation de la AWS IoT console, sous **Gérer**, développez les **appareils Greengrass**, puis choisissez **Groups (V1)**.
1. Choisissez le groupe dont vous voulez modifier les paramètres.
1. Choisissez l'onglet **Fonctions Lambda.**
1. **Dans **Environnement d'exécution de la fonction Lambda par défaut**, sélectionnez Modifier.**
1. Dans la page **Modifier l'environnement d'exécution de la fonction Lambda par défaut**, sous Conteneurisation de la **fonction Lambda par défaut, modifiez le paramètre de conteneurisation**.
1. Choisissez **Enregistrer**.
Les modifications prennent effet lorsque le groupe est déployé.
## Flux de communication pour les fonctions Greengrass Lambda
Les fonctions Greengrass Lambda prennent en charge plusieurs méthodes de communication avec les autres membres du AWS IoT Greengrass groupe, les services locaux et les services cloud (y compris les services). AWS
### Communication à l'aide de messages MQTT
Les fonctions Lambda peuvent envoyer et recevoir des messages MQTT en utilisant un modèle de publication et d'abonnement contrôlé par les abonnements.
Ce flux de communication permet aux fonctions Lambda d'échanger des messages avec les entités suivantes :
+ Appareils clients du groupe.
+ Connecteurs dans le groupe.
+ Autres fonctions Lambda du groupe.
+ AWS IoT.
+ Le service Device Shadow local.
Un abonnement définit la source d'un message, la cible d'un message et une rubrique (ou sujet) qui est utilisée pour acheminer des messages de la source vers la cible. Les messages publiés dans une fonction Lambda sont transmis au gestionnaire enregistré de la fonction. Les abonnements permettent une sécurité accrue et des interactions prévisibles. Pour de plus amples informations, veuillez consulter [Abonnements gérés dans le flux de travail de messagerie MQTT](gg-sec.md#gg-msg-workflow).
**Note**
Lorsque le noyau est hors ligne, les fonctions Greengrass Lambda peuvent échanger des messages avec des appareils clients, des connecteurs, d'autres fonctions et des ombres locales, mais les messages à destination sont mis en file d'attente. AWS IoT Pour de plus amples informations, veuillez consulter [File d'attente de messages MQTT pour les cibles cloud](gg-core.md#mqtt-message-queue).
### Autres flux de communication
+ Pour interagir avec les ressources locales des appareils et des volumes et les modèles d'apprentissage automatique sur un appareil principal, les fonctions Greengrass Lambda utilisent des interfaces de système d'exploitation spécifiques à la plate-forme. Par exemple, vous pouvez utiliser la méthode `open` dans le module [os](https://docs.python.org/2/library/os.html) pour les fonctions Python. Pour qu'une fonction ait l'autorisation d'accéder à une ressource, elle doit être *affiliée* à la ressource et disposer de l'autorisation `read-only` ou `read-write`. Pour plus d'informations, notamment sur la disponibilité des versions AWS IoT Greengrass principales, consultez [Accédez aux ressources locales grâce aux fonctions et connecteurs Lambda](access-local-resources.md) et[Accès aux ressources d'apprentissage automatique à partir du code de fonction Lambda](access-ml-resources.md#access-resource-function-code).
**Note**
Si vous exécutez votre fonction Lambda sans conteneurisation, vous ne pouvez pas utiliser les ressources de périphérique et de volume locales connectées et vous devez accéder directement à ces ressources.
+ Les fonctions Lambda peuvent utiliser le `Lambda` client du SDK AWS IoT Greengrass principal pour appeler d'autres fonctions Lambda du groupe Greengrass.
+ Les fonctions Lambda peuvent utiliser le AWS SDK pour communiquer avec les services. AWS Pour plus d'informations, consultez la section [AWS SDK.](#aws-sdk)
+ Les fonctions Lambda peuvent utiliser des interfaces tierces pour communiquer avec des services cloud externes, comme les fonctions Lambda basées sur le cloud.
**Note**
Les fonctions Lambda de Greengrass ne peuvent pas communiquer avec AWS d'autres services cloud lorsque le cœur est hors ligne.
## Récupération de la rubrique (ou sujet) MQTT en entrée
AWS IoT Greengrass utilise des abonnements pour contrôler l'échange de messages MQTT entre les appareils clients, les fonctions Lambda et les connecteurs d'un groupe, ainsi qu' AWS IoT avec ou avec le service fantôme local. Les abonnements définissent la source d'un message, la cible d'un message ainsi qu'une rubrique MQTT utilisée pour acheminer les messages. Lorsque la cible est une fonction Lambda, le gestionnaire de la fonction est invoqué lorsque la source publie un message. Pour de plus amples informations, veuillez consulter [Communication à l'aide de messages MQTT](#lambda-messages).
L'exemple suivant montre comment une fonction Lambda peut obtenir le sujet d'entrée à partir du `context` sujet transmis au gestionnaire. Pour cela, la fonction accède à la clé `subject` à partir de la hiérarchie de contexte (`context.client_context.custom['subject']`). L'exemple convertit également le message JSON entrant, puis publie la rubrique et le message analysés.
**Note**
Dans l' AWS IoT Greengrass API, le sujet d'un [abonnement](https://docs.aws.amazon.com/greengrass/v1/apireference/definitions-subscription.html) est représenté par la `subject` propriété.
```
import greengrasssdk
import logging
client = greengrasssdk.client('iot-data')
OUTPUT_TOPIC = 'test/topic_results'
def get_input_topic(context):
try:
topic = context.client_context.custom['subject']
except Exception as e:
logging.error('Topic could not be parsed. ' + repr(e))
return topic
def get_input_message(event):
try:
message = event['test-key']
except Exception as e:
logging.error('Message could not be parsed. ' + repr(e))
return message
def function_handler(event, context):
try:
input_topic = get_input_topic(context)
input_message = get_input_message(event)
response = 'Invoked on topic "%s" with message "%s"' % (input_topic, input_message)
logging.info(response)
except Exception as e:
logging.error(e)
client.publish(topic=OUTPUT_TOPIC, payload=response)
return
```
Pour tester la fonction, ajoutez-la à votre groupe à l'aide des paramètres de configuration par défaut. Ajoutez ensuite les abonnements suivants et déployez le groupe. Pour obtenir des instructions, veuillez consulter [Module 3 (partie 1) : Fonctions Lambda sur AWS IoT Greengrass](module3-I.md).
****
| Source | Cible | Filtre de rubriques |
| --- | --- | --- |
| Cloud IoT | Cette fonction | test/input\$1message |
| Cette fonction | Cloud IoT | test/topic\$1results |
Une fois le déploiement terminé, appelez la fonction.
1. Dans la AWS IoT console, ouvrez la page du **client de test MQTT**.
1. Abonnez-vous au `test/topic_results` sujet en sélectionnant l'onglet **S'abonner à un sujet**.
1. Publiez un message dans le `test/input_message` sujet en sélectionnant l'onglet **Publier dans un sujet**. Dans le cadre de cet exemple, vous devez inclure la propriété `test-key` dans le message JSON.
```
{
"test-key": "Some string value"
}
```
En cas de réussite, la fonction publie la rubrique en entrée et la chaîne de message dans la rubrique `test/topic_results`.
## Configuration du cycle de vie pour les fonctions Greengrass Lambda
Le cycle de vie de la fonction Greengrass Lambda détermine le moment où une fonction démarre et la manière dont elle crée et utilise les conteneurs. Le cycle de vie détermine également comment les variables et la logique de prétraitement se trouvant à l'extérieur du gestionnaire de fonctions sont conservées.
AWS IoT Greengrass prend en charge les cycles de vie à la demande (par défaut) ou de longue durée :
+ Les fonctions **à la demande** démarrent lorsqu'elles sont appelées et s'arrêtent lorsqu'il n'y a plus de tâche à exécuter. Un appel de la fonction crée un conteneur séparé (ou sandbox) pour traiter les appels, sauf si un conteneur existant peut être réutilisé. Les données qui sont envoyées à la fonction peuvent être extraites par n'importe quel conteneur.
Plusieurs appels d'une fonction à la demande peuvent être exécutés en parallèle.
Les variables et la logique de prétraitement définies à l'extérieur du gestionnaire de fonctions ne sont pas conservées quand de nouveaux conteneurs sont créés.
+ Les fonctions **à longue durée de vie** (ou *épinglées*) démarrent automatiquement lorsque le AWS IoT Greengrass noyau démarre et s'exécutent dans un seul conteneur. Toutes les données qui sont envoyées à la fonction sont extraites par le même conteneur.
Les appels sont mis en file d'attente jusqu'à ce que les appels précédents soient exécutées.
Les variables et la logique de prétraitement définies à l'extérieur du gestionnaire de fonctions sont conservées pour chaque appel du gestionnaire.
Les fonctions Lambda à longue durée de vie sont utiles lorsque vous devez commencer à travailler sans aucune intervention initiale. Par exemple, une fonction à longue durée de vie peut se charger et commencer à traiter un modèle ML pour qu'il soit prêt lorsque la fonction commencera à recevoir des données des appareils.
**Note**
N'oubliez pas que les fonctions à longue durée de vie ont des délais d'attente associés aux appels de leur gestionnaire. Si vous souhaitez exécuter indéfiniment du code d'exécution, vous devez démarrer celui-ci à l'extérieur du gestionnaire. Assurez-vous qu'il n'y a pas de code de blocage à l'extérieur du gestionnaire qui peut empêcher la fonction de terminer son initialisation.
Ces fonctions s'exécutent à moins que le cœur ne s'arrête (par exemple, lors d'un déploiement de groupe ou du redémarrage d'un appareil) ou que la fonction n'entre dans un état d'erreur (tel qu'un délai d'expiration du gestionnaire, une exception non détectée ou lorsqu'elle dépasse ses limites de mémoire).
Pour plus d'informations sur la réutilisation des conteneurs, consultez [la section Comprendre la réutilisation des conteneurs AWS Lambda dans](https://aws.amazon.com/blogs/compute/container-reuse-in-lambda/) le blog AWS Compute.
## Exécutables Lambda
Cette fonctionnalité est disponible pour AWS IoT Greengrass Core v1.6 et versions ultérieures.
Un exécutable Lambda est un type de fonction Greengrass Lambda que vous pouvez utiliser pour exécuter du code binaire dans l'environnement principal. Il vous permet d'exécuter des fonctionnalités spécifiques à l'appareil de manière native et de bénéficier de l'encombrement réduit du code compilé. Les exécutables Lambda peuvent être invoqués par des événements, invoquer d'autres fonctions et accéder aux ressources locales.
Les exécutables Lambda supportent uniquement le type d'encodage binaire (pas JSON), mais sinon vous pouvez les gérer dans votre groupe Greengrass et les déployer comme les autres fonctions Lambda de Greengrass. Cependant, le processus de création d'exécutables Lambda est différent de celui de création de fonctions Lambda Python, Java et Node.js :
+ Vous ne pouvez pas utiliser la AWS Lambda console pour créer (ou gérer) un exécutable Lambda. Vous pouvez créer un exécutable Lambda uniquement à l'aide de l' AWS Lambda API.
+ Vous téléchargez le code de fonction AWS Lambda sous forme d'exécutable compilé qui inclut le [SDK AWS IoT Greengrass Core pour C.](https://github.com/aws/aws-greengrass-core-sdk-c)
+ Vous spécifiez le nom de l'exécutable en tant que gestionnaire de fonctions.
Les exécutables Lambda doivent implémenter certains appels et modèles de programmation dans leur code de fonction. Par exemple, la méthode `main` doit :
+ Appeler `gg_global_init` pour initialiser des variables globales internes Greengrass. Cette fonction doit être appelée avant de créer des threads et avant d'appeler toute autre fonction AWS IoT Greengrass du Core SDK.
+ Appelez `gg_runtime_start` pour enregistrer le gestionnaire de fonctions auprès du moteur d'exécution Greengrass Lambda. Cette fonction doit être appelée lors de l'initialisation. L'appel à cette fonction entraîne l'utilisation du thread actuel par l'environnement d'exécution. Le paramètre facultatif `GG_RT_OPT_ASYNC` indique à cette fonction de ne pas se bloquer, mais de créer un nouveau thread pour l'environnement d'exécution. Cette fonction utilise un gestionnaire `SIGTERM`.
L'extrait de code suivant est la `main` méthode tirée de l'exemple de code [simple\$1handler.c](https://github.com/aws/aws-greengrass-core-sdk-c/blob/master/aws-greengrass-core-sdk-c-example/simple_handler.c) sur. GitHub
```
int main() {
gg_error err = GGE_SUCCESS;
err = gg_global_init(0);
if(err) {
gg_log(GG_LOG_ERROR, "gg_global_init failed %d", err);
goto cleanup;
}
gg_runtime_start(handler, 0);
cleanup:
return -1;
}
```
Pour plus d'informations sur les exigences, les contraintes et les autres détails de mise en œuvre, consultez le [SDK AWS IoT Greengrass Core pour C.](https://github.com/aws/aws-greengrass-core-sdk-c)
### Création d'un exécutable Lambda
Après avoir compilé votre code avec le SDK, utilisez l' AWS Lambda API pour créer une fonction Lambda et téléchargez votre exécutable compilé.
**Note**
Votre fonction doit être compilée avec un compilateur compatible avec C89.
L'exemple suivant utilise la commande [create-function CLI](https://docs.aws.amazon.com/cli/latest/reference/lambda/create-function.html) pour créer un exécutable Lambda. La commande spécifie :
+ Le nom de l'exécutable pour le gestionnaire. Il doit s'agir du nom exact de votre exécutable compilé.
+ Le chemin d'accès au fichier `.zip` qui contient l'exécutable compilé.
+ `arn:aws:greengrass:::runtime/function/executable` pour l'environnement d'exécution. Il s'agit de l'environnement d'exécution de tous les exécutables Lambda.
**Note**
En effet`role`, vous pouvez spécifier l'ARN de n'importe quel rôle d'exécution Lambda. AWS IoT Greengrass n'utilise pas ce rôle, mais le paramètre est obligatoire pour créer la fonction. Pour plus d'informations sur les rôles d'exécution Lambda, consultez le [modèle AWS Lambda d'autorisations](https://docs.aws.amazon.com/lambda/latest/dg/intro-permission-model.html) dans le Guide du *AWS Lambda développeur*.
```
aws lambda create-function \
--region aws-region \
--function-name function-name \
--handler executable-name \
--role role-arn \
--zip-file fileb://file-name.zip \
--runtime arn:aws:greengrass:::runtime/function/executable
```
Utilisez ensuite l' AWS Lambda API pour publier une version et créer un alias.
+ Utilisez [publish-version](https://docs.aws.amazon.com/cli/latest/reference/lambda/publish-version.html) pour publier une version de fonction.
```
aws lambda publish-version \
--function-name function-name \
--region aws-region
```
+ Utilisez [create-alias](https://docs.aws.amazon.com/cli/latest/reference/lambda/create-alias.html) pour créer un alias pointant vers la version que vous venez de publier. Nous vous recommandons de référencer les fonctions Lambda par alias lorsque vous les ajoutez à un groupe Greengrass.
```
aws lambda create-alias \
--function-name function-name \
--name alias-name \
--function-version version-number \
--region aws-region
```
**Note**
La AWS Lambda console n'affiche pas les exécutables Lambda. Pour mettre à jour le code de fonction, vous devez utiliser l' AWS Lambda API.
Ajoutez ensuite l'exécutable Lambda à un groupe Greengrass, configurez-le pour accepter les données d'entrée binaires dans ses paramètres spécifiques au groupe, puis déployez le groupe. Vous pouvez le faire dans la AWS IoT Greengrass console ou à l'aide de l' AWS IoT Greengrass API.
# Exécution AWS IoT Greengrass dans un conteneur Docker
AWS IoT Greengrass peut être configuré pour fonctionner dans un conteneur [Docker](https://www.docker.com/).
Vous pouvez télécharger un Dockerfile via [Amazon sur CloudFront lequel](what-is-gg.md#gg-docker-download) le logiciel AWS IoT Greengrass Core et ses dépendances sont installés. Pour modifier l'image Docker afin qu'elle s'exécute sur différentes architectures de plateforme ou pour réduire la taille de l'image Docker, consultez le fichier `README` dans le package de téléchargement Docker.
Pour vous aider à commencer à expérimenter AWS IoT Greengrass, fournit AWS également des images Docker prédéfinies sur lesquelles le logiciel AWS IoT Greengrass Core et ses dépendances sont installés. Vous pouvez télécharger une image depuis [Docker Hub](https://hub.docker.com/r/amazon/aws-iot-greengrass) ou [Amazon Elastic Container Registry](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html) (Amazon ECR). Ces images prédéfinies utilisent les images de base Amazon Linux 2 (x86\$164) et Alpine Linux (x86\$164, ARMv7L ou). AArch64
**Important**
Le 30 juin 2022, AWS IoT Greengrass fin de la maintenance des images Docker du logiciel AWS IoT Greengrass Core v1.x publiées sur Amazon Elastic Container Registry (Amazon ECR) et Docker Hub. Vous pouvez continuer à télécharger ces images Docker depuis Amazon ECR et Docker Hub jusqu'au 30 juin 2023, soit un an après la fin de la maintenance. Cependant, les images Docker du logiciel AWS IoT Greengrass Core v1.x ne reçoivent plus de correctifs de sécurité ni de corrections de bogues après la fin de la maintenance le 30 juin 2022. Si vous exécutez une charge de travail de production qui dépend de ces images Docker, nous vous recommandons de créer vos propres images Docker à l'aide des Dockerfiles fournis. AWS IoT Greengrass Pour de plus amples informations, veuillez consulter [AWS IoT Greengrass Logiciel Docker](what-is-gg.md#gg-docker-download).
Cette rubrique explique comment télécharger l'image AWS IoT Greengrass Docker depuis Amazon ECR et l'exécuter sur une plateforme Windows, macOS ou Linux (x86\$164). Cette rubrique comporte les étapes suivantes :
1. [Obtenez l'image du AWS IoT Greengrass conteneur sur Amazon ECR](#docker-pull-image)
1. [Créer et configurer le groupe et le noyau Greengrass](#docker-config-gg)
1. [Exécuter AWS IoT Greengrass localement](#docker-run-gg)
1. [Configurer la conteneurisation « Aucun conteneur » pour le groupe](#docker-no-container)
1. [Déployer des fonctions Lambda dans le conteneur Docker](#docker-add-lambdas)
1. [(Facultatif) Déployez des appareils clients qui interagissent avec Greengrass dans le conteneur Docker](#docker-add-devices)
Les fonctionnalités suivantes ne sont pas prises en charge lorsque vous exécutez AWS IoT Greengrass dans un conteneur Docker :
+ [Connecteurs](connectors.md) qui s'exécutent en mode **Greengrass container (Conteneur Greengrass)**. Pour exécuter un connecteur dans un conteneur Docker, le connecteur doit s'exécuter en mode **No container (Aucun conteneur)**. Pour rechercher des connecteurs prenant en charge le mode **No container (Aucun conteneur)** veuillez consulter [AWS- connecteurs Greengrass fournis](connectors-list.md). Certains de ces connecteurs ont un paramètre de mode d'isolement que vous devez définir sur **Aucun conteneur**.
+ [Ressources de volumes et d'appareils locales](access-local-resources.md). Vos fonctions Lambda définies par l'utilisateur qui s'exécutent dans le conteneur Docker doivent accéder directement aux appareils et aux volumes du cœur.
Ces fonctionnalités ne sont pas prises en charge lorsque l'environnement d'exécution Lambda du groupe Greengrass est défini sur [Aucun conteneur](lambda-group-config.md#no-container-mode), ce qui est nécessaire pour fonctionner AWS IoT Greengrass dans un conteneur Docker.
## Conditions préalables
Avant de commencer ce didacticiel, vous devez effectuer les opérations suivantes.
+ Vous devez installer les logiciels et versions suivants sur votre ordinateur hôte en fonction de la version AWS Command Line Interface (AWS CLI) que vous avez choisie.
------
#### [ AWS CLI version 2 ]
+ [Docker](https://docs.docker.com/install/) version 18.09 ou ultérieure. Les versions antérieures peuvent également fonctionner, mais nous recommandons la version 18.09 ou ultérieure.
+ AWS CLI version 2.0.0 ou ultérieure.
+ Pour installer la AWS CLI version 2, voir [Installation de la AWS CLI version 2](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html).
+ Pour configurer le AWS CLI, reportez-vous à [la section Configuration du AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html).
**Note**
Pour effectuer une mise à niveau vers une AWS CLI version 2 ultérieure sur un ordinateur Windows, vous devez répéter le processus [d'installation de MSI](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2-windows.html).
------
#### [ AWS CLI version 1 ]
+ [Docker](https://docs.docker.com/install/) version 18.09 ou ultérieure. Les versions antérieures peuvent également fonctionner, mais nous recommandons la version 18.09 ou ultérieure.
+ [Python](https://www.python.org/downloads/) version 3.6 ou ultérieure.
+ [pip](https://pip.pypa.io/en/stable/installing) version 18.1 ou suivante.
+ AWS CLI version 1.17.10 ou ultérieure
+ Pour installer la AWS CLI version 1, voir [Installation de la AWS CLI version 1](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv1.html).
+ Pour configurer le AWS CLI, reportez-vous à [la section Configuration du AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html).
+ Pour effectuer une mise à niveau vers la dernière AWS CLI version de la version 1, exécutez la commande suivante.
```
pip install awscli --upgrade --user
```
**Note**
Si vous utilisez l'[installation MSI](https://docs.aws.amazon.com/cli/latest/userguide/install-windows.html#msi-on-windows) de la AWS CLI version 1 sous Windows, tenez compte des points suivants :
Si l'installation de la AWS CLI version 1 ne parvient pas à installer botocore, essayez d'utiliser l'installation [Python et pip](https://docs.aws.amazon.com/cli/latest/userguide/awscli-install-windows.html#awscli-install-windows-pip).
Pour effectuer une mise à niveau vers une AWS CLI version 1 ultérieure, vous devez répéter le processus d'installation de MSI.
------
+ Pour accéder aux ressources d'Amazon Elastic Container Registry (Amazon ECR), vous devez accorder l'autorisation suivante.
+ Amazon ECR demande aux utilisateurs d'accorder l'`ecr:GetAuthorizationToken`autorisation par le biais d'une politique Gestion des identités et des accès AWS (IAM) avant de pouvoir s'authentifier auprès d'un registre et envoyer ou extraire des images d'un référentiel Amazon ECR. Pour plus d'informations, consultez les [exemples de politiques relatives aux référentiels Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-policy-examples.html) et [l'accès à un référentiel Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/security_iam_id-based-policy-examples.html#security_iam_id-based-policy-examples-access-one-bucket) dans le guide de l'*utilisateur d'Amazon Elastic Container Registry*.
## Étape 1 : obtenir l'image du AWS IoT Greengrass conteneur depuis Amazon ECR
AWS fournit des images Docker sur lesquelles le logiciel AWS IoT Greengrass Core est installé.
**Avertissement**
À partir de la version v1.11.6 du logiciel AWS IoT Greengrass Core, les images Greengrass Docker n'incluent plus Python 2.7, car Python 2.7 est arrivé end-of-life en 2020 et ne reçoit plus de mises à jour de sécurité. Si vous choisissez de mettre à jour ces images Docker, nous vous recommandons de vérifier que vos applications fonctionnent avec les nouvelles images Docker avant de déployer les mises à jour sur les appareils de production. Si vous avez besoin de Python 2.7 pour votre application qui utilise une image Greengrass Docker, vous pouvez modifier le Dockerfile Greengrass pour inclure Python 2.7 pour votre application.
Pour savoir comment extraire l'`latest`image depuis Amazon ECR, choisissez votre système d'exploitation :
### Extraire l'image de conteneur (Linux)
Exécutez les commandes suivantes dans le terminal de votre ordinateur.
1. Connectez-vous au AWS IoT Greengrass registre dans Amazon ECR.
```
aws ecr get-login-password --region us-west-2 | docker login --username AWS --password-stdin https://216483018798.dkr.ecr.us-west-2.amazonaws.com
```
En cas de succès, la sortie imprime `Login Succeeded`.
1. Récupérez l'image du AWS IoT Greengrass conteneur.
```
docker pull 216483018798.dkr.ecr.us-west-2.amazonaws.com/aws-iot-greengrass:latest
```
**Note**
L'`latest`image contient la dernière version stable du logiciel AWS IoT Greengrass Core installée sur une image de base Amazon Linux 2. Vous pouvez également extraire d'autres images du référentiel. Pour trouver toutes les images disponibles, consultez la page **Tags (Balises)** sur [Docker Hub](https://hub.docker.com/r/amazon/aws-iot-greengrass) ou utilisez la commande **aws ecr list-images**. Par exemple :
```
aws ecr list-images --region us-west-2 --registry-id 216483018798 --repository-name aws-iot-greengrass
```
1. Activez les protections symlink and hardlink. Si vous essayez de l'exécuter AWS IoT Greengrass dans un conteneur, vous pouvez activer les paramètres pour le démarrage en cours uniquement.
**Note**
Vous devrez peut-être utiliser **sudo** pour exécuter ces commandes.
+ Pour activer les paramètres pour le démarrage en cours uniquement :
```
echo 1 > /proc/sys/fs/protected_hardlinks
echo 1 > /proc/sys/fs/protected_symlinks
```
+ Pour activer les paramètres afin qu'ils persistent entre les redémarrages :
```
echo '# AWS IoT Greengrass' >> /etc/sysctl.conf
echo 'fs.protected_hardlinks = 1' >> /etc/sysctl.conf
echo 'fs.protected_symlinks = 1' >> /etc/sysctl.conf
sysctl -p
```
1. Activez le transfert IPv4 réseau, nécessaire au déploiement AWS IoT Greengrass dans le cloud et aux communications MQTT pour fonctionner sous Linux. Dans le fichier`/etc/sysctl.conf`, définissez `net.ipv4.ip_forward` sur 1, puis rechargez `sysctls`.
```
sudo nano /etc/sysctl.conf
# set this net.ipv4.ip_forward = 1
sudo sysctl -p
```
**Note**
Vous pouvez utiliser l'éditeur de votre choix à la place de nano.
### Extraire l'image de conteneur (macOS)
Exécutez les commandes suivantes dans le terminal de votre ordinateur.
1. Connectez-vous au AWS IoT Greengrass registre dans Amazon ECR.
```
aws ecr get-login-password --region us-west-2 | docker login --username AWS --password-stdin https://216483018798.dkr.ecr.us-west-2.amazonaws.com
```
En cas de succès, la sortie imprime `Login Succeeded`.
1. Récupérez l'image du AWS IoT Greengrass conteneur.
```
docker pull 216483018798.dkr.ecr.us-west-2.amazonaws.com/aws-iot-greengrass:latest
```
**Note**
L'`latest`image contient la dernière version stable du logiciel AWS IoT Greengrass Core installée sur une image de base Amazon Linux 2. Vous pouvez également extraire d'autres images du référentiel. Pour trouver toutes les images disponibles, consultez la page **Tags (Balises)** sur [Docker Hub](https://hub.docker.com/r/amazon/aws-iot-greengrass) ou utilisez la commande **aws ecr list-images**. Par exemple :
```
aws ecr list-images --region us-west-2 --registry-id 216483018798 --repository-name aws-iot-greengrass
```
### Extraire l'image de conteneur (Windows)
Dans une invite de commande, exécutez les commandes suivantes. Pour pouvoir utiliser des commandes Docker sur Windows, Docker Desktop doit être en cours d'exécution.
1. Connectez-vous au AWS IoT Greengrass registre dans Amazon ECR.
```
aws ecr get-login-password --region us-west-2 | docker login --username AWS --password-stdin https://216483018798.dkr.ecr.us-west-2.amazonaws.com
```
En cas de succès, la sortie imprime `Login Succeeded`.
1. Récupérez l'image du AWS IoT Greengrass conteneur.
```
docker pull 216483018798.dkr.ecr.us-west-2.amazonaws.com/aws-iot-greengrass:latest
```
**Note**
L'`latest`image contient la dernière version stable du logiciel AWS IoT Greengrass Core installée sur une image de base Amazon Linux 2. Vous pouvez également extraire d'autres images du référentiel. Pour trouver toutes les images disponibles, consultez la page **Tags (Balises)** sur [Docker Hub](https://hub.docker.com/r/amazon/aws-iot-greengrass) ou utilisez la commande **aws ecr list-images**. Par exemple :
```
aws ecr list-images --region us-west-2 --registry-id 216483018798 --repository-name aws-iot-greengrass
```
## Étape 2 : Créer et configurer le groupe et le noyau Greengrass
Le logiciel AWS IoT Greengrass Core est installé sur l'image Docker, mais vous devez créer un groupe et un noyau Greengrass. Cela inclut le téléchargement des certificats et du fichier de configuration du noyau.
+ Suivez les étapes de [Module 2 : Installation du logiciel AWS IoT Greengrass de base](module2.md). Ignorez les étapes de téléchargement et d'exécution du logiciel AWS IoT Greengrass Core. Le logiciel et ses dépendances d'exécution sont déjà configurées dans l'image Docker.
## Étape 3 : Exécuter AWS IoT Greengrass localement
Une votre groupe configuré, vous êtes prêt à configurer et démarrer le noyau. Pour les étapes qui montrent comment procéder, choisissez votre système d'exploitation :
### Exécuter Greengrass localement (Linux)
Exécutez les commandes suivantes dans le terminal de votre ordinateur.
1. Créez un dossier pour les ressources de sécurité de l'appareil, puis déplacez le certificat et les clés dans ce dossier. Exécutez les commandes suivantes. Remplacez *path-to-security-files* par le chemin d'accès aux ressources de sécurité et remplacez *certificateId* par l'ID du certificat dans les noms de fichiers.
```
mkdir /tmp/certs
mv path-to-security-files/certificateId-certificate.pem.crt /tmp/certs
mv path-to-security-files/certificateId-public.pem.key /tmp/certs
mv path-to-security-files/certificateId-private.pem.key /tmp/certs
mv path-to-security-files/AmazonRootCA1.pem /tmp/certs
```
1. Créez un dossier pour la configuration de l'appareil et déplacez le fichier de configuration AWS IoT Greengrass Core dans ce dossier. Exécutez les commandes suivantes. Remplacez *path-to-config-file* par le chemin d'accès au fichier de configuration.
```
mkdir /tmp/config
mv path-to-config-file/config.json /tmp/config
```
1. Démarrez AWS IoT Greengrass et montez les certificats et le fichier de configuration dans le conteneur Docker.
Remplacez `/tmp` par le chemin d'accès où vous avez décompressé vos certificats et le fichier de configuration.
```
docker run --rm --init -it --name aws-iot-greengrass \
--entrypoint /greengrass-entrypoint.sh \
-v /tmp/certs:/greengrass/certs \
-v /tmp/config:/greengrass/config \
-p 8883:8883 \
216483018798.dkr.ecr.us-west-2.amazonaws.com/aws-iot-greengrass:latest
```
La sortie doit se présenter comme cet exemple :
```
Setting up greengrass daemon
Validating hardlink/softlink protection
Waiting for up to 30s for Daemon to start
Greengrass successfully started with PID: 10
```
### Exécuter Greengrass localement (macOS)
Exécutez les commandes suivantes dans le terminal de votre ordinateur.
1. Créez un dossier pour les ressources de sécurité de l'appareil, puis déplacez le certificat et les clés dans ce dossier. Exécutez les commandes suivantes. Remplacez *path-to-security-files* par le chemin d'accès aux ressources de sécurité et remplacez *certificateId* par l'ID du certificat dans les noms de fichiers.
```
mkdir /tmp/certs
mv path-to-security-files/certificateId-certificate.pem.crt /tmp/certs
mv path-to-security-files/certificateId-public.pem.key /tmp/certs
mv path-to-security-files/certificateId-private.pem.key /tmp/certs
mv path-to-security-files/AmazonRootCA1.pem /tmp/certs
```
1. Créez un dossier pour la configuration de l'appareil et déplacez le fichier de configuration AWS IoT Greengrass Core dans ce dossier. Exécutez les commandes suivantes. Remplacez *path-to-config-file* par le chemin d'accès au fichier de configuration.
```
mkdir /tmp/config
mv path-to-config-file/config.json /tmp/config
```
1. Démarrez AWS IoT Greengrass et montez les certificats et le fichier de configuration dans le conteneur Docker.
Remplacez `/tmp` par le chemin d'accès où vous avez décompressé vos certificats et le fichier de configuration.
```
docker run --rm --init -it --name aws-iot-greengrass \
--entrypoint /greengrass-entrypoint.sh \
-v /tmp/certs:/greengrass/certs \
-v /tmp/config:/greengrass/config \
-p 8883:8883 \
216483018798.dkr.ecr.us-west-2.amazonaws.com/aws-iot-greengrass:latest
```
La sortie doit se présenter comme cet exemple :
```
Setting up greengrass daemon
Validating hardlink/softlink protection
Waiting for up to 30s for Daemon to start
Greengrass successfully started with PID: 10
```
### Exécuter Greengrass localement (Windows)
1. Créez un dossier pour les ressources de sécurité de l'appareil, puis déplacez le certificat et les clés dans ce dossier. Dans une invite de commande, exécutez les commandes suivantes. Remplacez *path-to-security-files* par le chemin d'accès aux ressources de sécurité et remplacez *certificateId* par l'ID du certificat dans les noms de fichiers.
```
mkdir C:\Users\%USERNAME%\Downloads\certs
move path-to-security-files\certificateId-certificate.pem.crt C:\Users\%USERNAME%\Downloads\certs
move path-to-security-files\certificateId-public.pem.key C:\Users\%USERNAME%\Downloads\certs
move path-to-security-files\certificateId-private.pem.key C:\Users\%USERNAME%\Downloads\certs
move path-to-security-files\AmazonRootCA1.pem C:\Users\%USERNAME%\Downloads\certs
```
1. Créez un dossier pour la configuration de l'appareil et déplacez le fichier de configuration AWS IoT Greengrass Core dans ce dossier. Dans une invite de commande, exécutez les commandes suivantes. Remplacez *path-to-config-file* par le chemin d'accès au fichier de configuration.
```
mkdir C:\Users\%USERNAME%\Downloads\config
move path-to-config-file\config.json C:\Users\%USERNAME%\Downloads\config
```
1. Démarrez AWS IoT Greengrass et montez les certificats et le fichier de configuration dans le conteneur Docker. Dans votre invite de commande, exécutez les commandes suivantes.
```
docker run --rm --init -it --name aws-iot-greengrass --entrypoint /greengrass-entrypoint.sh -v c:/Users/%USERNAME%/Downloads/certs:/greengrass/certs -v c:/Users/%USERNAME%/Downloads/config:/greengrass/config -p 8883:8883 216483018798.dkr.ecr.us-west-2.amazonaws.com/aws-iot-greengrass:latest
```
Lorsque Docker vous invite à partager votre lecteur `C:\` avec le démon Docker, laissez-le créer un montage lié du répertoire `C:\` dans le conteneur Docker. Pour plus d'informations, consultez la section [Disques partagés](https://docs.docker.com/docker-for-windows/#shared-drives) dans la documentation Docker.
La sortie doit se présenter comme cet exemple :
```
Setting up greengrass daemon
Validating hardlink/softlink protection
Waiting for up to 30s for Daemon to start
Greengrass successfully started with PID: 10
```
**Note**
Si le conteneur n'ouvre pas le shell et se ferme immédiatement, vous pouvez résoudre le problème en procédant à un montage lié des journaux du runtime Greengrass lorsque vous démarrez l'image. Pour de plus amples informations, veuillez consulter [Pour conserver les journaux d'exécution Greengrass en dehors du conteneur Docker](#debugging-docker-persist-logs).
## Étape 4 : Configurer la conteneurisation « Aucun conteneur » pour le groupe Greengrass
Lorsque vous les exécutez AWS IoT Greengrass dans un conteneur Docker, toutes les fonctions Lambda doivent s'exécuter sans conteneurisation. Dans cet étape, vous définissez la conteneurisation par défaut du groupe sur **Aucun conteneur**. Vous devez effectuer cette opération avant le premier déploiement du groupe.
1. Dans le volet de navigation de la AWS IoT console, sous **Gérer**, développez les **appareils Greengrass**, puis choisissez **Groups (V1)**.
1. Choisissez le groupe dont vous voulez modifier les paramètres.
1. Choisissez l'onglet **Fonctions Lambda.**
1. **Dans **Environnement d'exécution de la fonction Lambda par défaut**, sélectionnez Modifier.**
1. Dans l'**environnement d'exécution Modifier la fonction Lambda par défaut**, sous Conteneurisation de la fonction **Lambda par défaut, modifiez les paramètres de conteneurisation**.
1. Choisissez **Enregistrer**.
Les modifications prennent effet lorsque le groupe est déployé.
Pour de plus amples informations, veuillez consulter [Configuration de la conteneurisation par défaut pour les fonctions Lambda dans un groupe](lambda-group-config.md#lambda-containerization-groupsettings).
**Note**
Par défaut, les fonctions Lambda utilisent le paramètre de conteneurisation des groupes. Si vous remplacez le paramètre **Aucun conteneur** pour une fonction Lambda AWS IoT Greengrass lorsqu'elle est exécutée dans un conteneur Docker, le déploiement échoue.
## Étape 5 : Déployer les fonctions Lambda dans le conteneur Docker AWS IoT Greengrass
Vous pouvez déployer des fonctions Lambda de longue durée sur le conteneur Greengrass Docker.
+ Suivez les étapes décrites [Module 3 (partie 1) : Fonctions Lambda sur AWS IoT Greengrass](module3-I.md) pour déployer une fonction Lambda Hello World de longue durée sur le conteneur.
## Étape 6 : (Facultatif) Déployez des appareils clients qui interagissent avec Greengrass exécuté dans le conteneur Docker
Vous pouvez également déployer des appareils clients qui interagissent avec eux AWS IoT Greengrass lorsqu'ils sont exécutés dans un conteneur Docker.
+ Suivez les étapes décrites [Module 4 : Interaction avec les appareils clients dans un AWS IoT Greengrass groupe](module4.md) pour déployer des appareils clients qui se connectent au cœur et envoient des messages MQTT.
## Arrêter le AWS IoT Greengrass conteneur Docker
Pour arrêter le conteneur AWS IoT Greengrass Docker, appuyez sur Ctrl\$1C dans votre terminal ou sur votre invite de commande. Cette action envoie `SIGTERM` le processus du démon Greengrass pour détruire le processus du démon Greengrass et tous les processus Lambda qui ont été lancés par le processus du démon. Le conteneur Docker est initialisé avec le processus `/dev/init` défini comme PID 1, qui permet d'éliminer tous les processus zombies restants. Pour plus d'informations, consultez le [guide de référence d'exécution Docker](https://docs.docker.com/engine/reference/commandline/run/#options).
## Résolution des problèmes AWS IoT Greengrass dans un conteneur Docker
Utilisez les informations suivantes pour résoudre les problèmes liés à l'exécution AWS IoT Greengrass dans un conteneur Docker.
### Erreur : Impossible d'effectuer une connexion interactive à partir d'un appareil autre que TTY.
**Solution :** cette erreur peut se produire lorsque vous exécutez la commande `aws ecr get-login-password`. Assurez-vous d'avoir installé la dernière AWS CLI version 2 ou version 1. Nous vous recommandons d'utiliser la AWS CLI version 2. Pour plus d’informations, consultez [Installation d’ AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) dans le *Guide de l’utilisateur AWS Command Line Interface *.
### Erreur : options inconnues : -no-include-email.
**Solution :** cette erreur peut se produire lorsque vous exécutez la commande `aws ecr get-login`. Assurez-vous que la dernière AWS CLI version est installée (par exemple, exécutez :`pip install awscli --upgrade --user`). Si vous utilisez Windows et avez installé l'interface de ligne de commande à l'aide du programme d'installation MSI, vous devez répéter le processus d'installation. Pour plus d'informations, consultez la section [Installation du AWS Command Line Interface sous Microsoft Windows](https://docs.aws.amazon.com/cli/latest/userguide/awscli-install-windows.html) dans le *Guide de AWS Command Line Interface l'utilisateur*.
### Avertissement : IPv4 est désactivé. La mise en réseau ne fonctionnera pas.
**Solution :** vous pouvez recevoir cet avertissement ou un message similaire lors de l'exécution AWS IoT Greengrass sur un ordinateur Linux. Activez le transfert IPv4 réseau comme décrit dans cette [étape](#docker-linux-enable-ipv4). AWS IoT Greengrass le déploiement dans le cloud et les communications MQTT ne fonctionnent pas lorsque le IPv4 transfert n'est pas activé. Pour plus d'informations, consultez [Configurer les paramètres du noyau dans un espace de noms (sysctls) lors de l'exécution](https://docs.docker.com/engine/reference/commandline/run/#configure-namespaced-kernel-parameters-sysctls-at-runtime) dans la documentation Docker.
### Erreur : Un pare-feu bloque le partage de fichiers entre les fenêtres et les conteneurs.
**Solution :** vous pouvez recevoir cette erreur ou un message `Firewall Detected` lors de l'exécution de Docker sur un ordinateur Windows. Ce problème peut également survenir si vous êtes connecté à un réseau privé virtuel (VPN) et que vos paramètres réseau empêchent le montage du lecteur partagé. Dans ce cas, désactivez le VPN et réexécutez le conteneur Docker.
### Erreur : une erreur s'est produite (AccessDeniedException) lors de l'appel de l' GetAuthorizationToken opération : L'utilisateur : arn:aws:iam : ::user/ n'est pas autorisé à effectuer : ecr : on resource : \$1 GetAuthorizationToken
Vous pouvez recevoir cette erreur lors de l'exécution de la `aws ecr get-login-password` commande si vous ne disposez pas des autorisations suffisantes pour accéder à un référentiel Amazon ECR. Pour plus d'informations, consultez les [exemples de politiques relatives aux référentiels Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-policy-examples.html) et [l'accès à un référentiel Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/security_iam_id-based-policy-examples.html) dans le guide de l'utilisateur *Amazon ECR.*
Pour obtenir de l'aide générale en matière de AWS IoT Greengrass résolution des problèmes, consultez[Résolution des problèmes AWS IoT Greengrass](gg-troubleshooting.md).
### Débogage AWS IoT Greengrass dans un conteneur Docker
Pour déboguer les problèmes avec un conteneur Docker, vous pouvez conserver les journaux d'exécution Greengrass ou attacher un shell interactif au conteneur Docker.
#### Pour conserver les journaux d'exécution Greengrass en dehors du conteneur Docker
Vous pouvez exécuter le conteneur AWS IoT Greengrass Docker après avoir monté le répertoire par liaison. `/greengrass/ggc/var/log` Les journaux sont conservés après la fermeture ou la suppression du conteneur.
**Sur Linux ou macOS**
[Arrêtez les conteneurs Docker Greengrass](#docker-stop) en cours d'exécution sur l'hôte, puis exécutez la commande suivante dans un terminal. Elle procède au montage lié du répertoire `log` Greengrass et démarre l'image Docker.
Remplacez `/tmp` par le chemin d'accès où vous avez décompressé vos certificats et le fichier de configuration.
```
docker run --rm --init -it --name aws-iot-greengrass \
--entrypoint /greengrass-entrypoint.sh \
-v /tmp/certs:/greengrass/certs \
-v /tmp/config:/greengrass/config \
-v /tmp/log:/greengrass/ggc/var/log \
-p 8883:8883 \
216483018798.dkr.ecr.us-west-2.amazonaws.com/aws-iot-greengrass:latest
```
Vous pouvez alors vérifier vos journaux à l'emplacement `/tmp/log` sur votre hôte afin de voir ce qui s'est passé lors de l'exécution de Greengrass dans le conteneur Docker.
**Sous Windows**
[Arrêtez les conteneurs Docker Greengrass](#docker-stop) en cours d'exécution sur l'hôte, puis exécutez la commande suivante dans une invite de commande. Elle procède au montage lié du répertoire `log` Greengrass et démarre l'image Docker.
```
cd C:\Users\%USERNAME%\Downloads
mkdir log
docker run --rm --init -it --name aws-iot-greengrass --entrypoint /greengrass-entrypoint.sh -v c:/Users/%USERNAME%/Downloads/certs:/greengrass/certs -v c:/Users/%USERNAME%/Downloads/config:/greengrass/config -v c:/Users/%USERNAME%/Downloads/log:/greengrass/ggc/var/log -p 8883:8883 216483018798.dkr.ecr.us-west-2.amazonaws.com/aws-iot-greengrass:latest
```
Vous pouvez alors vérifier vos journaux à l'emplacement `C:/Users/%USERNAME%/Downloads/log` sur votre hôte afin de voir ce qui s'est passé lors de l'exécution de Greengrass dans le conteneur Docker.
#### Pour attacher un shell interactif au conteneur Docker
Vous pouvez associer un shell interactif à un conteneur AWS IoT Greengrass Docker en cours d'exécution. Cela peut vous aider à étudier l'état du conteneur Docker Greengrass.
**Sur Linux ou macOS**
Pendant que le conteneur Docker Greengrass est en cours d'exécution, exécutez la commande suivante dans un autre terminal.
```
docker exec -it $(docker ps -a -q -f "name=aws-iot-greengrass") /bin/bash
```
**Sous Windows**
Pendant que le conteneur Docker Greengrass est en cours d'exécution, exécutez les commandes suivantes dans une invite de commande distincte.
```
docker ps -a -q -f "name=aws-iot-greengrass"
```
Remplacez *gg-container-id* par le `container_id` résultat de la commande précédente.
```
docker exec -it gg-container-id /bin/bash
```