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.
# Développer des AWS IoT Greengrass composants
Vous pouvez développer et tester des composants sur votre appareil principal Greengrass. Par conséquent, vous pouvez créer et itérer votre AWS IoT Greengrass logiciel sans interagir avec le AWS Cloud. Lorsque vous avez terminé une version de votre composant, vous pouvez la télécharger AWS IoT Greengrass dans le cloud, afin que vous et votre équipe puissiez déployer le composant sur d'autres appareils de votre flotte. Pour plus d'informations sur le déploiement des composants, consultez[Déployer AWS IoT Greengrass des composants sur des appareils](manage-deployments.md).
Chaque composant est composé d'une *recette* et d'*artefacts*.
+ **Recettes**
Chaque composant contient un fichier de recette qui définit ses métadonnées. La recette spécifie également les paramètres de configuration, les dépendances des composants, le cycle de vie et la compatibilité de la plate-forme du composant. Le cycle de vie du composant définit les commandes qui installent, exécutent et arrêtent le composant. Pour de plus amples informations, veuillez consulter [AWS IoT Greengrass référence de recette de composant](component-recipe-reference.md).
Vous pouvez définir des recettes au format [JSON](https://en.wikipedia.org/wiki/JSON) ou [YAML.](https://en.wikipedia.org/wiki/YAML)
+ **Artefacts**
Les composants peuvent avoir un nombre illimité d'artefacts, qui sont des binaires de composants. Les artefacts peuvent inclure des scripts, du code compilé, des ressources statiques et tout autre fichier consommé par un composant. Les composants peuvent également consommer des artefacts issus de leurs dépendances.
AWS IoT Greengrass fournit des composants prédéfinis que vous pouvez utiliser dans vos applications et déployer sur vos appareils. Par exemple, vous pouvez utiliser le composant Stream Manager pour télécharger des données vers différents AWS services, ou vous pouvez utiliser le composant CloudWatch Metrics pour publier des métriques personnalisées sur Amazon CloudWatch. Pour de plus amples informations, veuillez consulter [AWS-composants fournis](public-components.md).
AWS IoT Greengrass organise un index des composants de Greengrass, appelé Greengrass Software Catalog. Ce catalogue suit les composants de Greengrass développés par la communauté Greengrass. À partir de ce catalogue, vous pouvez télécharger, modifier et déployer des composants pour créer vos applications Greengrass. Pour de plus amples informations, veuillez consulter [Composantes communautaires](greengrass-software-catalog.md).
Le logiciel AWS IoT Greengrass Core exécute les composants en tant qu'utilisateur et groupe du système, tels que `ggc_user` et`ggc_group`, que vous configurez sur le périphérique principal. Cela signifie que les composants disposent des autorisations de cet utilisateur du système. Si vous utilisez un utilisateur système sans répertoire de base, les composants ne peuvent pas utiliser de commandes d'exécution ou de code utilisant un répertoire de base. Cela signifie que vous ne pouvez pas utiliser la `pip install some-library --user` commande pour installer des packages Python par exemple. Si vous avez suivi le [didacticiel de démarrage](getting-started.md) pour configurer votre appareil principal, cela signifie que l'utilisateur de votre système n'a pas de répertoire personnel. Pour plus d'informations sur la configuration de l'utilisateur et du groupe qui exécutent les composants, consultez[Configurer l'utilisateur qui exécute les composants](configure-greengrass-core-v2.md#configure-component-user).
**Note**
AWS IoT Greengrass utilise des versions sémantiques pour les composants. Les versions sémantiques suivent une *majeure*. *mineur*. système de numéro de *patch*. Par exemple, la version `1.0.0` représente la première version majeure d'un composant. Pour plus d'informations, consultez la [spécification de version sémantique](https://semver.org/).
**Topics**
+ [Cycle de vie des composants](#component-lifecycle)
+ [Types de composants](#component-types)
+ [Création de AWS IoT Greengrass composants](create-components.md)
+ [Testez AWS IoT Greengrass les composants avec des déploiements locaux](test-components.md)
+ [Publiez des composants à déployer sur vos appareils principaux](publish-components.md)
+ [Interagissez avec les AWS services](interact-with-aws-services.md)
+ [Exécuter un conteneur Docker](run-docker-container.md)
+ [AWS IoT Greengrass référence de recette de composant](component-recipe-reference.md)
+ [Référence à la variable d'environnement du composant](component-environment-variables.md)
## Cycle de vie des composants
Le *cycle de vie des composants* définit les étapes que le logiciel AWS IoT Greengrass Core utilise pour installer et exécuter les composants. Chaque étape définit un script et d'autres informations qui indiquent le comportement du composant. Par exemple, lorsque vous installez un composant, le logiciel AWS IoT Greengrass Core exécute le script de `install` cycle de vie de ce composant. Les composants des équipements principaux présentent les états de cycle de vie suivants :
+ `NEW`— La recette et les artefacts du composant sont chargés sur le périphérique principal, mais le composant n'est pas installé. Une fois qu'un composant a atteint cet état, il exécute son [script d'installation](component-recipe-reference.md#install-lifecycle-definition).
+ `INSTALLED`— Le composant est installé sur le périphérique principal. Le composant passe dans cet état après avoir exécuté son [script d'installation](component-recipe-reference.md#install-lifecycle-definition).
+ `STARTING`— Le composant démarre sur le périphérique principal. Le composant entre dans cet état lorsqu'il exécute son [script de démarrage](component-recipe-reference.md#startup-lifecycle-definition). Si le démarrage réussit, le composant passe à l'`RUNNING`état.
+ `RUNNING`— Le composant est en cours d'exécution sur le périphérique principal. Le composant entre dans cet état lorsqu'il exécute son [script d'exécution](component-recipe-reference.md#run-lifecycle-definition) ou lorsque des processus en arrière-plan sont actifs depuis son script de démarrage.
+ `FINISHED`— Le composant s'est exécuté correctement et a terminé son exécution.
+ `STOPPING`— Le composant est en train de s'arrêter. Le composant entre dans cet état lorsqu'il exécute son [script d'arrêt](component-recipe-reference.md#shutdown-lifecycle-definition).
+ `ERRORED`— Le composant a rencontré une erreur. Lorsque le composant entre dans cet état, il exécute son [script de restauration](component-recipe-reference.md#recover-lifecycle-definition). Ensuite, le composant redémarre pour essayer de revenir à une utilisation normale. Si le composant entre trois fois dans `ERRORED` cet état sans succès, le composant devient`BROKEN`.
+ `BROKEN`— Le composant a rencontré des erreurs à plusieurs reprises et ne peut pas être rétabli. Vous devez déployer à nouveau le composant pour le réparer.
## Types de composants
Le *type de composant* indique comment le logiciel AWS IoT Greengrass Core exécute le composant. Les types de composants peuvent être les suivants :
+ **Noyau** (`aws.greengrass.nucleus`)
Le noyau Greengrass est le composant qui fournit les fonctionnalités minimales du logiciel AWS IoT Greengrass Core. Pour de plus amples informations, veuillez consulter [Noyau de Greengrass](greengrass-nucleus-component.md).
+ **Plug-in** (`aws.greengrass.plugin`)
Le noyau Greengrass exécute un composant de plug-in dans la même machine virtuelle Java (JVM) que le noyau. Le noyau redémarre lorsque vous modifiez la version d'un composant du plugin sur un périphérique principal. Pour installer et exécuter les composants du plugin, vous devez configurer le noyau Greengrass pour qu'il s'exécute en tant que service système. Pour de plus amples informations, veuillez consulter [Configurer le noyau Greengrass en tant que service système](configure-greengrass-core-v2.md#configure-system-service).
Plusieurs composants fournis par AWS sont des composants de plug-in, ce qui leur permet de s'interfacer directement avec le noyau de Greengrass. Les composants du plugin utilisent le même fichier journal que le noyau Greengrass. Pour de plus amples informations, veuillez consulter [AWS IoT Greengrass Journaux de surveillance](monitor-logs.md).
+ **Générique** (`aws.greengrass.generic`)
Le noyau Greengrass exécute les scripts de cycle de vie d'un composant générique, si le composant définit un cycle de vie.
Ce type est le type par défaut pour les composants personnalisés.
+ **Lambda** () `aws.greengrass.lambda`
[Le noyau Greengrass exécute un composant de fonction Lambda à l'aide du composant de lancement Lambda.](lambda-launcher-component.md)
Lorsque vous créez un composant à partir d'une fonction Lambda, le composant est de ce type. Pour de plus amples informations, veuillez consulter [Exécuter AWS Lambda des fonctions](run-lambda-functions.md).
**Note**
Il est déconseillé de spécifier le type de composant dans une recette. AWS IoT Greengrass définit le type pour vous lorsque vous créez un composant.
# Création de AWS IoT Greengrass composants
Vous pouvez développer des AWS IoT Greengrass composants personnalisés sur un ordinateur de développement local ou un appareil principal de Greengrass. AWS IoT Greengrass fournit l'[interface de ligne de commande du kit de AWS IoT Greengrass développement (CLI GDK](greengrass-development-kit-cli.md)) pour vous aider à créer, créer et publier des composants à partir de modèles de composants prédéfinis [et](greengrass-software-catalog.md) de composants communautaires. Vous pouvez également exécuter des commandes shell intégrées pour créer, créer et publier des composants. Choisissez l'une des options suivantes pour créer des composants Greengrass personnalisés :
+ **Utiliser la CLI du kit de développement Greengrass**
Utilisez la CLI GDK pour développer des composants sur un ordinateur de développement local. La CLI GDK crée et empaquète le code source des composants dans une recette et des artefacts que vous pouvez publier en tant que composant privé du AWS IoT Greengrass service. Vous pouvez configurer la CLI GDK pour mettre à jour automatiquement la version et l'artefact du composant URIs lorsque vous publiez le composant, de sorte que vous n'avez pas besoin de mettre à jour la recette à chaque fois. Pour développer un composant à l'aide de la CLI GDK, vous pouvez partir d'un modèle ou d'un composant communautaire du catalogue de logiciels [Greengrass](greengrass-software-catalog.md). Pour de plus amples informations, veuillez consulter [AWS IoT Greengrass Interface de ligne de commande du kit de développement](greengrass-development-kit-cli.md).
+ **Exécuter des commandes shell intégrées**
Vous pouvez exécuter des commandes shell intégrées pour développer des composants sur un ordinateur de développement local ou sur un périphérique principal Greengrass. Vous utilisez des commandes shell pour copier ou intégrer le code source des composants dans des artefacts. Chaque fois que vous créez une nouvelle version d'un composant, vous devez créer ou mettre à jour la recette avec la nouvelle version du composant. Lorsque vous publiez le composant sur le AWS IoT Greengrass service, vous devez mettre à jour l'URI de chaque artefact de composant de la recette.
**Topics**
+ [Création d'un composant (CLI GDK)](#create-component-gdk-cli)
+ [Création d'un composant (commandes shell)](#create-component-shell-commands)
## Création d'un composant (CLI GDK)
Suivez les instructions de cette section pour créer et créer un composant à l'aide de la CLI GDK.
**Pour développer un composant Greengrass (GDK CLI)**
1. Si ce n'est pas déjà fait, installez la CLI GDK sur votre ordinateur de développement. Pour de plus amples informations, veuillez consulter [Installation ou mise à jour de l'interface de ligne de commande AWS IoT Greengrass du kit de développement](install-greengrass-development-kit-cli.md).
1. Accédez au dossier dans lequel vous souhaitez créer des dossiers de composants.
------
#### [ Linux or Unix ]
```
mkdir ~/greengrassv2
cd ~/greengrassv2
```
------
#### [ Windows Command Prompt (CMD) ]
```
mkdir %USERPROFILE%\greengrassv2
cd %USERPROFILE%\greengrassv2
```
------
#### [ PowerShell ]
```
mkdir ~/greengrassv2
cd ~/greengrassv2
```
------
1. Choisissez un modèle de composant ou un composant de communauté à télécharger. La CLI GDK télécharge le modèle ou le composant communautaire, afin que vous puissiez partir d'un exemple fonctionnel. Utilisez la commande [component list](greengrass-development-kit-cli-component.md#greengrass-development-kit-cli-component-list) pour récupérer la liste des modèles ou des composants communautaires disponibles.
+ Pour répertorier les modèles de composants, exécutez la commande suivante. Chaque ligne de la réponse inclut le nom du modèle et le langage de programmation.
```
gdk component list --template
```
+ Pour répertorier les composants de la communauté, exécutez la commande suivante.
```
gdk component list --repository
```
1. Créez et modifiez un dossier de composants dans lequel la CLI GDK télécharge le modèle ou le composant communautaire. *HelloWorld*Remplacez-le par le nom du composant ou par un autre nom permettant d'identifier ce dossier de composants.
------
#### [ Linux or Unix ]
```
mkdir HelloWorld
cd HelloWorld
```
------
#### [ Windows Command Prompt (CMD) ]
```
mkdir HelloWorld
cd HelloWorld
```
------
#### [ PowerShell ]
```
mkdir HelloWorld
cd HelloWorld
```
------
1. Téléchargez le modèle ou le composant communautaire dans le dossier actuel. Utilisez la commande [component init](greengrass-development-kit-cli-component.md#greengrass-development-kit-cli-component-init).
+ Pour créer un dossier de composants à partir d'un modèle, exécutez la commande suivante. Remplacez *HelloWorld* par le nom du modèle et remplacez *python* par le nom du langage de programmation.
```
gdk component init --template HelloWorld --language python
```
+ Pour créer un dossier de composants à partir d'un composant communautaire, exécutez la commande suivante. Remplacez *ComponentName* par le nom du composant communautaire.
```
gdk component init --repository ComponentName
```
**Note**
Si vous utilisez GDK CLI v1.0.0, vous devez exécuter cette commande dans un dossier vide. La CLI GDK télécharge le modèle ou le composant communautaire dans le dossier actuel.
Si vous utilisez la CLI GDK v1.1.0 ou une version ultérieure, vous pouvez spécifier l'`--name`argument pour spécifier le dossier dans lequel la CLI GDK télécharge le modèle ou le composant communautaire. Si vous utilisez cet argument, spécifiez un dossier qui n'existe pas. La CLI GDK crée le dossier pour vous. Si vous ne spécifiez pas cet argument, la CLI GDK utilise le dossier actuel, qui doit être vide.
1. La CLI GDK lit le [fichier de configuration de la CLI GDK](gdk-cli-configuration-file.md), nommé`gdk-config.json`, pour créer et publier des composants. Ce fichier de configuration se trouve à la racine du dossier du composant. L'étape précédente crée ce fichier pour vous. Au cours de cette étape, vous effectuez `gdk-config.json` une mise à jour avec les informations relatives à votre composant. Procédez comme suit :
1. Ouvrez `gdk-config.json` dans un éditeur de texte.
1. (Facultatif) Modifiez le nom du composant. Le nom du composant est la clé de l'`component`objet.
1. Changez l'auteur du composant.
1. (Facultatif) Modifiez la version du composant. Spécifiez l’un des éléments suivants :
+ `NEXT_PATCH`— Lorsque vous choisissez cette option, la CLI GDK définit la version lorsque vous publiez le composant. La CLI GDK interroge le AWS IoT Greengrass service pour identifier la dernière version publiée du composant. Ensuite, il définit la version sur la version de correctif suivante après cette version. Si vous n'avez jamais publié le composant auparavant, la CLI GDK utilise la version`1.0.0`.
Si vous choisissez cette option, vous ne pouvez pas utiliser la [CLI Greengrass](greengrass-cli-component.md) pour déployer et tester localement le composant sur votre ordinateur de développement local qui exécute le logiciel AWS IoT Greengrass Core. Pour activer les déploiements locaux, vous devez plutôt spécifier une version sémantique.
+ Une version sémantique, telle que**1.0.0**. Les versions sémantiques utilisent une *majeure*. *mineur*. système de numérotation des *patchs*. Pour plus d'informations, consultez la [spécification de version sémantique](https://semver.org/).
Si vous développez des composants sur un appareil principal Greengrass sur lequel vous souhaitez les déployer et les tester, choisissez cette option. Vous devez créer le composant avec une version spécifique pour créer des déploiements locaux avec la CLI [Greengrass](greengrass-cli-component.md).
1. (Facultatif) Modifiez la configuration de construction du composant. La configuration de construction définit la manière dont la CLI GDK construit la source du composant en artefacts. Choisissez l'une des options suivantes pour `build_system` :
+ `zip`— Regroupe le dossier du composant dans un fichier ZIP à définir comme seul artefact du composant. Choisissez cette option pour les types de composants suivants :
+ Composants utilisant des langages de programmation interprétés, tels que Python ou JavaScript.
+ Composants qui empaquetent des fichiers autres que du code, tels que des modèles d'apprentissage automatique ou d'autres ressources.
La CLI GDK compresse le dossier du composant dans un fichier zip portant le même nom que le dossier du composant. Par exemple, si le nom du dossier du composant est`HelloWorld`, la CLI GDK crée un fichier zip nommé`HelloWorld.zip`.
**Note**
Si vous utilisez la version 1.0.0 de la CLI GDK sur un appareil Windows, les noms des dossiers de composants et des fichiers zip ne doivent contenir que des lettres minuscules.
Lorsque la CLI GDK comprime le dossier du composant dans un fichier zip, elle ignore les fichiers suivants :
+ le fichier `gdk-config.json` ;
+ Le fichier de recette (`recipe.json`ou`recipe.yaml`)
+ Créez des dossiers, tels que `greengrass-build`
+ `maven`— Exécute la `mvn clean package` commande pour intégrer la source du composant en artefacts. Choisissez cette option pour les composants qui utilisent [Maven](https://maven.apache.org/), tels que les composants Java.
Sur les appareils Windows, cette fonctionnalité est disponible pour GDK CLI v1.1.0 et versions ultérieures.
+ `gradle`— Exécute la `gradle build` commande pour intégrer la source du composant en artefacts. Choisissez cette option pour les composants qui utilisent [Gradle](https://gradle.org/). Cette fonctionnalité est disponible pour GDK CLI v1.1.0 et versions ultérieures.
Le système de `gradle` construction prend en charge Kotlin DSL en tant que fichier de construction. Cette fonctionnalité est disponible pour GDK CLI v1.2.0 et versions ultérieures.
+ `gradlew`— Exécute la `gradlew` commande pour intégrer la source du composant en artefacts. Choisissez cette option pour les composants qui utilisent le [Gradle Wrapper](https://docs.gradle.org/current/userguide/gradle_wrapper.html).
Cette fonctionnalité est disponible pour GDK CLI v1.2.0 et versions ultérieures.
+ `custom`— Exécute une commande personnalisée pour intégrer la source du composant dans une recette et des artefacts. Spécifiez la commande personnalisée dans le `custom_build_command` paramètre.
1. Si vous spécifiez `custom` pour`build_system`, ajoutez-le `custom_build_command` à l'`build`objet. Dans`custom_build_command`, spécifiez une chaîne unique ou une liste de chaînes, chaque chaîne étant un mot dans la commande. Par exemple, pour exécuter une commande de génération personnalisée pour un composant C\$1\$1, vous pouvez spécifier**["cmake", "--build", "build", "--config", "Release"]**.
1. Si vous utilisez la CLI GDK v1.1.0 ou une version ultérieure, vous pouvez spécifier l'`--bucket`argument pour spécifier le compartiment S3 dans lequel la CLI GDK télécharge les artefacts du composant. Si vous ne spécifiez pas cet argument, la CLI GDK télécharge vers le compartiment S3 dont le nom est`bucket-region-accountId`, où *bucket* et *region* sont les valeurs que vous spécifiez`gdk-config.json`, ainsi que votre *accountId* Compte AWS identifiant. La CLI GDK crée le bucket s'il n'existe pas.
Modifiez la configuration de publication du composant. Procédez comme suit :
1. Spécifiez le nom du compartiment S3 à utiliser pour héberger les artefacts des composants.
1. Spécifiez l' Région AWS endroit où la CLI GDK publie le composant.
Lorsque vous avez terminé cette étape, le `gdk-config.json` fichier peut ressembler à l'exemple suivant.
```
{
"component": {
"com.example.PythonHelloWorld": {
"author": "Amazon",
"version": "NEXT_PATCH",
"build": {
"build_system" : "zip"
},
"publish": {
"bucket": "greengrass-component-artifacts",
"region": "us-west-2"
}
}
},
"gdk_version": "1.0.0"
}
```
1. Mettez à jour le fichier de recette du composant, nommé `recipe.yaml` ou`recipe.json`. Procédez comme suit :
1. Si vous avez téléchargé un modèle ou un composant communautaire qui utilise le système de `zip` compilation, vérifiez que le nom de l'artefact zip correspond au nom du dossier du composant. La CLI GDK compresse le dossier des composants dans un fichier zip portant le même nom que le dossier des composants. La recette contient le nom de l'artefact zip dans la liste des artefacts du composant et dans les scripts de cycle de vie qui utilisent les fichiers de l'artefact zip. Mettez à jour les `Lifecycle` définitions `Artifacts` et de manière à ce que le nom du fichier zip corresponde au nom du dossier du composant. Les exemples de recettes partiels suivants mettent en évidence le nom du fichier zip dans les `Lifecycle` définitions `Artifacts` et.
------
#### [ JSON ]
```
{
...
"Manifests": [
{
"Platform": {
"os": "all"
},
"Artifacts": [
{
"URI": "s3://{COMPONENT_NAME}/{COMPONENT_VERSION}/HelloWorld.zip",
"Unarchive": "ZIP"
}
],
"Lifecycle": {
"Run": "python3 -u {artifacts:decompressedPath}/HelloWorld/main.py {configuration:/Message}"
}
}
]
}
```
------
#### [ YAML ]
```
---
...
Manifests:
- Platform:
os: all
Artifacts:
- URI: "s3://BUCKET_NAME/COMPONENT_NAME/COMPONENT_VERSION/HelloWorld.zip"
Unarchive: ZIP
Lifecycle:
Run: "python3 -u {artifacts:decompressedPath}/HelloWorld/main.py {configuration:/Message}"
```
------
1. (Facultatif) Mettez à jour la description du composant, la configuration par défaut, les artefacts, les scripts de cycle de vie et le support de la plate-forme. Pour de plus amples informations, veuillez consulter [AWS IoT Greengrass référence de recette de composant](component-recipe-reference.md).
Lorsque vous avez terminé cette étape, le fichier de recette peut ressembler aux exemples suivants.
------
#### [ JSON ]
```
{
"RecipeFormatVersion": "2020-01-25",
"ComponentName": "{COMPONENT_NAME}",
"ComponentVersion": "{COMPONENT_VERSION}",
"ComponentDescription": "This is a simple Hello World component written in Python.",
"ComponentPublisher": "{COMPONENT_AUTHOR}",
"ComponentConfiguration": {
"DefaultConfiguration": {
"Message": "World"
}
},
"Manifests": [
{
"Platform": {
"os": "all"
},
"Artifacts": [
{
"URI": "s3://{COMPONENT_NAME}/{COMPONENT_VERSION}/HelloWorld.zip",
"Unarchive": "ZIP"
}
],
"Lifecycle": {
"Run": "python3 -u {artifacts:decompressedPath}/HelloWorld/main.py {configuration:/Message}"
}
}
]
}
```
------
#### [ YAML ]
```
---
RecipeFormatVersion: "2020-01-25"
ComponentName: "{COMPONENT_NAME}"
ComponentVersion: "{COMPONENT_VERSION}"
ComponentDescription: "This is a simple Hello World component written in Python."
ComponentPublisher: "{COMPONENT_AUTHOR}"
ComponentConfiguration:
DefaultConfiguration:
Message: "World"
Manifests:
- Platform:
os: all
Artifacts:
- URI: "s3://BUCKET_NAME/COMPONENT_NAME/COMPONENT_VERSION/HelloWorld.zip"
Unarchive: ZIP
Lifecycle:
Run: "python3 -u {artifacts:decompressedPath}/HelloWorld/main.py {configuration:/Message}"
```
------
1. Développez et construisez le composant Greengrass. La commande [component build](greengrass-development-kit-cli-component.md#greengrass-development-kit-cli-component-build) produit une recette et des artefacts dans le `greengrass-build` dossier du dossier des composants. Exécutez la commande suivante.
```
gdk component build
```
Lorsque vous êtes prêt à tester votre composant, utilisez la CLI GDK pour le publier sur le AWS IoT Greengrass service. Vous pouvez ensuite déployer le composant sur les appareils principaux de Greengrass. Pour de plus amples informations, veuillez consulter [Publiez des composants à déployer sur vos appareils principaux](publish-components.md).
## Création d'un composant (commandes shell)
Suivez les instructions de cette section pour créer des dossiers de recettes et d'artefacts contenant du code source et des artefacts pour plusieurs composants.
**Pour développer un composant Greengrass (commandes shell)**
1. Créez un dossier pour vos composants avec des sous-dossiers pour les recettes et les artefacts. Exécutez les commandes suivantes sur votre appareil principal Greengrass pour créer ces dossiers et accéder au dossier des composants. Remplacez *\$1/greengrassv2* ou *%USERPROFILE%\$1greengrassv2* par le chemin d'accès au dossier à utiliser pour le développement local.
------
#### [ Linux or Unix ]
```
mkdir -p ~/greengrassv2/{recipes,artifacts}
cd ~/greengrassv2
```
------
#### [ Windows Command Prompt (CMD) ]
```
mkdir %USERPROFILE%\greengrassv2\\recipes, %USERPROFILE%\greengrassv2\\artifacts
cd %USERPROFILE%\greengrassv2
```
------
#### [ PowerShell ]
```
mkdir ~/greengrassv2/recipes, ~/greengrassv2/artifacts
cd ~/greengrassv2
```
------
1. Utilisez un éditeur de texte pour créer un fichier de recette qui définit les métadonnées, les paramètres, les dépendances, le cycle de vie et les capacités de la plateforme de votre composant. Incluez la version du composant dans le nom du fichier de recette afin de pouvoir identifier quelle recette reflète quelle version de composant. Vous pouvez choisir le format YAML ou JSON pour votre recette.
Par exemple, sur un système basé sur Linux, vous pouvez exécuter la commande suivante pour utiliser GNU nano pour créer le fichier.
------
#### [ JSON ]
```
nano recipes/com.example.HelloWorld-1.0.0.json
```
------
#### [ YAML ]
```
nano recipes/com.example.HelloWorld-1.0.0.yaml
```
------
**Note**
AWS IoT Greengrass utilise des versions sémantiques pour les composants. Les versions sémantiques suivent une *majeure*. *mineur*. système de numéro de *patch*. Par exemple, la version `1.0.0` représente la première version majeure d'un composant. Pour plus d'informations, consultez la [spécification de version sémantique](https://semver.org/).
1. Définissez la recette de votre composant. Pour de plus amples informations, veuillez consulter [AWS IoT Greengrass référence de recette de composant](component-recipe-reference.md).
Votre recette peut ressembler à l'exemple de recette Hello World suivant.
------
#### [ JSON ]
```
{
"RecipeFormatVersion": "2020-01-25",
"ComponentName": "com.example.HelloWorld",
"ComponentVersion": "1.0.0",
"ComponentDescription": "My first AWS IoT Greengrass component.",
"ComponentPublisher": "Amazon",
"ComponentConfiguration": {
"DefaultConfiguration": {
"Message": "world"
}
},
"Manifests": [
{
"Platform": {
"os": "linux"
},
"Lifecycle": {
"run": "python3 -u {artifacts:path}/hello_world.py {configuration:/Message}"
}
},
{
"Platform": {
"os": "windows"
},
"Lifecycle": {
"run": "py -3 -u {artifacts:path}/hello_world.py {configuration:/Message}"
}
}
]
}
```
------
#### [ YAML ]
```
---
RecipeFormatVersion: '2020-01-25'
ComponentName: com.example.HelloWorld
ComponentVersion: '1.0.0'
ComponentDescription: My first AWS IoT Greengrass component.
ComponentPublisher: Amazon
ComponentConfiguration:
DefaultConfiguration:
Message: world
Manifests:
- Platform:
os: linux
Lifecycle:
run: |
python3 -u {artifacts:path}/hello_world.py "{configuration:/Message}"
- Platform:
os: windows
Lifecycle:
run: |
py -3 -u {artifacts:path}/hello_world.py "{configuration:/Message}"
```
------
Cette recette exécute un script Python Hello World, qui peut ressembler à l'exemple de script suivant.
```
import sys
message = "Hello, %s!" % sys.argv[1]
# Print the message to stdout, which Greengrass saves in a log file.
print(message)
```
1. Créez un dossier pour la version du composant à développer. Nous vous recommandons d'utiliser un dossier distinct pour les artefacts de chaque version de composant afin de pouvoir identifier les artefacts correspondant à chaque version de composant. Exécutez la commande suivante.
------
#### [ Linux or Unix ]
```
mkdir -p artifacts/com.example.HelloWorld/1.0.0
```
------
#### [ Windows Command Prompt (CMD) ]
```
mkdir artifacts/com.example.HelloWorld/1.0.0
```
------
#### [ PowerShell ]
```
mkdir artifacts/com.example.HelloWorld/1.0.0
```
------
**Important**
Vous devez utiliser le format suivant pour le chemin du dossier d'artefacts. Incluez le nom et la version du composant que vous spécifiez dans la recette.
```
artifacts/componentName/componentVersion/
```
1. Créez les artefacts de votre composant dans le dossier que vous avez créé à l'étape précédente. Les artefacts peuvent inclure des logiciels, des images et tout autre fichier binaire utilisé par votre composant.
Lorsque votre composant est prêt, [testez-le](test-components.md).
# Testez AWS IoT Greengrass les composants avec des déploiements locaux
Si vous développez un composant Greengrass sur un appareil principal, vous pouvez créer un déploiement local pour l'installer et le tester. Suivez les étapes décrites dans cette section pour créer un déploiement local.
Si vous développez le composant sur un autre ordinateur, tel qu'un ordinateur de développement local, vous ne pouvez pas créer de déploiement local. Publiez plutôt le composant sur le AWS IoT Greengrass service afin de pouvoir le déployer sur les appareils principaux de Greengrass pour le tester. Pour plus d’informations, consultez [Publiez des composants à déployer sur vos appareils principaux](publish-components.md) et [Déployer AWS IoT Greengrass des composants sur des appareils](manage-deployments.md).
**Pour tester un composant sur un appareil principal Greengrass**
1. Le périphérique principal enregistre les événements tels que les mises à jour des composants. Vous pouvez consulter ce fichier journal pour détecter et résoudre les erreurs liées à votre composant, telles qu'une recette non valide. Ce fichier journal affiche également les messages que votre composant imprime en sortie standard (stdout). Nous vous recommandons d'ouvrir une session de terminal supplémentaire sur votre appareil principal pour observer les nouveaux messages du journal en temps réel. Ouvrez une nouvelle session de terminal, par exemple via SSH, et exécutez la commande suivante pour afficher les journaux. Remplacez `/greengrass/v2` par le chemin d'accès au dossier AWS IoT Greengrass racine.
------
#### [ Linux or Unix ]
```
sudo tail -f /greengrass/v2/logs/greengrass.log
```
------
#### [ PowerShell ]
```
gc C:\greengrass\v2\logs\greengrass.log -Tail 10 -Wait
```
------
Vous pouvez également consulter le fichier journal de votre composant.
------
#### [ Linux or Unix ]
```
sudo tail -f /greengrass/v2/logs/com.example.HelloWorld.log
```
------
#### [ PowerShell ]
```
gc C:\greengrass\v2\logs\com.example.HelloWorld.log -Tail 10 -Wait
```
------
1. Dans votre session de terminal d'origine, exécutez la commande suivante pour mettre à jour le périphérique principal avec votre composant. `/greengrass/v2`Remplacez-le par le chemin d'accès au dossier AWS IoT Greengrass racine et remplacez-le *\$1/greengrassv2* par le chemin d'accès à votre dossier de développement local.
------
#### [ Linux or Unix ]
```
sudo /greengrass/v2/bin/greengrass-cli deployment create \
--recipeDir ~/greengrassv2/recipes \
--artifactDir ~/greengrassv2/artifacts \
--merge "com.example.HelloWorld=1.0.0"
```
------
#### [ Windows Command Prompt (CMD) ]
```
C:\greengrass\v2\bin\greengrass-cli deployment create ^
--recipeDir %USERPROFILE%\greengrassv2\recipes ^
--artifactDir %USERPROFILE%\greengrassv2\artifacts ^
--merge "com.example.HelloWorld=1.0.0"
```
------
#### [ PowerShell ]
```
C:\greengrass\v2\bin\greengrass-cli deployment create `
--recipeDir ~/greengrassv2/recipes `
--artifactDir ~/greengrassv2/artifacts `
--merge "com.example.HelloWorld=1.0.0"
```
------
**Note**
Vous pouvez également utiliser la `greengrass-cli deployment create` commande pour définir la valeur des paramètres de configuration de votre composant. Pour de plus amples informations, veuillez consulter [créer](gg-cli-deployment.md#deployment-create).
1. Utilisez la `greengrass-cli deployment status` commande pour suivre la progression du déploiement de votre composant.
------
#### [ Unix or Linux ]
```
sudo /greengrass/v2/bin/greengrass-cli deployment status \
-i deployment-id
```
------
#### [ Windows Command Prompt (CMD) ]
```
C:\greengrass\v2\bin\greengrass-cli deployment status ^
-i deployment-id
```
------
#### [ PowerShell ]
```
C:\greengrass\v2\bin\greengrass-cli deployment status `
-i deployment-id
```
------
1. Testez votre composant lorsqu'il s'exécute sur l'appareil principal de Greengrass. Lorsque vous aurez terminé cette version de votre composant, vous pourrez le télécharger sur le AWS IoT Greengrass service. Ensuite, vous pouvez déployer le composant sur d'autres périphériques principaux. Pour de plus amples informations, veuillez consulter [Publiez des composants à déployer sur vos appareils principaux](publish-components.md).
# Publiez des composants à déployer sur vos appareils principaux
Après avoir créé ou terminé une version d'un composant, vous pouvez le publier sur le AWS IoT Greengrass service. Ensuite, vous pouvez le déployer sur les appareils principaux de Greengrass.
Si vous utilisez la CLI du kit de [développement Greengrass (CLI GDK](greengrass-development-kit-cli.md)) [pour développer et créer un](create-components.md) composant, vous [pouvez utiliser la CLI GDK](#publish-component-gdk-cli) pour publier le composant sur le. AWS Cloud Sinon, [utilisez les commandes shell intégrées et le AWS CLI](#publish-component-shell-commands) pour publier le composant.
Vous pouvez également l'utiliser AWS CloudFormation pour créer des composants et d'autres AWS ressources à partir de modèles. Pour plus d'informations, voir [Qu'est-ce que c'est AWS CloudFormation ?](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) et [https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-greengrassv2-componentversion.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-greengrassv2-componentversion.html) dans le *guide de l'utilisateur AWS CloudFormation *.
**Topics**
+ [Publier un composant (GDK CLI)](#publish-component-gdk-cli)
+ [Publier un composant (commandes shell)](#publish-component-shell-commands)
## Publier un composant (GDK CLI)
Suivez les instructions de cette section pour publier un composant à l'aide de la CLI GDK. La CLI GDK télécharge les artefacts de construction dans un compartiment S3, met à jour l'artefact URIs dans la recette et crée le composant à partir de la recette. Vous spécifiez le compartiment S3 et la région à utiliser dans le [fichier de configuration de la CLI GDK](gdk-cli-configuration-file.md).
Si vous utilisez la CLI GDK v1.1.0 ou une version ultérieure, vous pouvez spécifier l'`--bucket`argument pour spécifier le compartiment S3 dans lequel la CLI GDK télécharge les artefacts du composant. Si vous ne spécifiez pas cet argument, la CLI GDK télécharge vers le compartiment S3 dont le nom est`bucket-region-accountId`, où *bucket* et *region* sont les valeurs que vous spécifiez`gdk-config.json`, ainsi que votre *accountId* Compte AWS identifiant. La CLI GDK crée le bucket s'il n'existe pas.
**Important**
Les rôles principaux des appareils n'autorisent pas l'accès aux compartiments S3 par défaut. Si c'est la première fois que vous utilisez ce compartiment S3, vous devez ajouter des autorisations au rôle pour permettre aux appareils principaux de récupérer les artefacts des composants de ce compartiment S3. Pour de plus amples informations, veuillez consulter [Autoriser l'accès aux compartiments S3 pour les artefacts des composants](device-service-role.md#device-service-role-access-s3-bucket).
**Pour publier un composant Greengrass (GDK CLI)**
1. Ouvrez le dossier du composant dans une invite de commande ou dans un terminal.
1. Si ce n'est pas déjà fait, créez le composant Greengrass. La commande [component build](greengrass-development-kit-cli-component.md#greengrass-development-kit-cli-component-build) produit une recette et des artefacts dans le `greengrass-build` dossier du dossier des composants. Exécutez la commande suivante.
```
gdk component build
```
1. Publiez le composant dans le AWS Cloud. La commande de [publication du composant](greengrass-development-kit-cli-component.md#greengrass-development-kit-cli-component-publish) télécharge les artefacts du composant sur Amazon S3 et met à jour la recette du composant avec l'URI de chaque artefact. Ensuite, il crée le composant dans le AWS IoT Greengrass service.
**Note**
AWS IoT Greengrass calcule le condensé de chaque artefact lorsque vous créez le composant. Cela signifie que vous ne pouvez pas modifier les fichiers d'artefacts de votre compartiment S3 après avoir créé un composant. Dans ce cas, les déploiements incluant ce composant échoueront, car le résumé du fichier ne correspond pas. Si vous modifiez un fichier d'artefact, vous devez créer une nouvelle version du composant.
Si vous spécifiez `NEXT_PATCH` la version du composant dans le fichier de configuration de la CLI GDK, la CLI GDK utilise la version de correctif suivante qui n'existe pas encore dans le AWS IoT Greengrass service.
Exécutez la commande suivante.
```
gdk component publish
```
La sortie indique la version du composant créée par la CLI GDK.
Après avoir publié le composant, vous pouvez le déployer sur les appareils principaux. Pour de plus amples informations, veuillez consulter [Déployer AWS IoT Greengrass des composants sur des appareils](manage-deployments.md).
## Publier un composant (commandes shell)
Utilisez la procédure suivante pour publier un composant à l'aide des commandes shell et du AWS Command Line Interface (AWS CLI). Lorsque vous publiez un composant, vous devez effectuer les opérations suivantes :
1. Publiez les artefacts des composants dans un compartiment S3.
1. Ajoutez l'URI Amazon S3 de chaque artefact à la recette du composant.
1. Créez une version de composant à AWS IoT Greengrass partir de la recette du composant.
**Note**
Chaque version de composant que vous chargez doit être unique. Assurez-vous de télécharger la bonne version du composant, car vous ne pourrez pas la modifier après l'avoir chargée.
Vous pouvez suivre ces étapes pour publier un composant depuis votre ordinateur de développement ou votre appareil principal Greengrass.
**Pour publier un composant (commandes shell)**
1. Si le composant utilise une version qui existe dans le AWS IoT Greengrass service, vous devez modifier la version du composant. Ouvrez la recette dans un éditeur de texte, incrémentez la version et enregistrez le fichier. Choisissez une nouvelle version qui reflète les modifications que vous avez apportées au composant.
**Note**
AWS IoT Greengrass utilise des versions sémantiques pour les composants. Les versions sémantiques suivent une *majeure*. *mineur*. système de numéro de *patch*. Par exemple, la version `1.0.0` représente la première version majeure d'un composant. Pour plus d'informations, consultez la [spécification de version sémantique](https://semver.org/).
1. Si votre composant contient des artefacts, procédez comme suit :
1. Publiez les artefacts du composant dans un compartiment S3 de votre Compte AWS.
**Astuce**
Nous vous recommandons d'inclure le nom et la version du composant dans le chemin d'accès à l'artefact dans le compartiment S3. Ce schéma de dénomination peut vous aider à conserver les artefacts utilisés par les versions précédentes du composant, afin que vous puissiez continuer à prendre en charge les versions précédentes du composant.
Exécutez la commande suivante pour publier un fichier d'artefact dans un compartiment S3. Remplacez amzn-s3-demo-bucket par le nom du bucket, puis par *artifacts/com.example.HelloWorld/1.0.0/artifact.py* le chemin d'accès au fichier d'artefact.
```
aws s3 cp artifacts/com.example.HelloWorld/1.0.0/artifact.py s3://amzn-s3-demo-bucket/artifacts/com.example.HelloWorld/1.0.0/artifact.py
```
**Important**
Les rôles principaux des appareils n'autorisent pas l'accès aux compartiments S3 par défaut. Si c'est la première fois que vous utilisez ce compartiment S3, vous devez ajouter des autorisations au rôle pour permettre aux appareils principaux de récupérer les artefacts des composants de ce compartiment S3. Pour de plus amples informations, veuillez consulter [Autoriser l'accès aux compartiments S3 pour les artefacts des composants](device-service-role.md#device-service-role-access-s3-bucket).
1. Ajoutez une liste nommée `Artifacts` à la recette du composant si elle n'est pas présente. La `Artifacts` liste apparaît dans chaque manifeste, qui définit les exigences du composant sur chaque plate-forme qu'il prend en charge (ou les exigences par défaut du composant pour toutes les plateformes).
1. Ajoutez chaque artefact à la liste des artefacts ou mettez à jour l'URI des artefacts existants. L'URI Amazon S3 est composé du nom du compartiment et du chemin d'accès à l'objet artefact contenu dans le compartiment. L'Amazon S3 de vos artefacts URIs doit ressembler à l'exemple suivant.
```
s3://amzn-s3-demo-bucket/artifacts/com.example.HelloWorld/1.0.0/artifact.py
```
Une fois ces étapes terminées, votre recette devrait avoir une `Artifacts` liste semblable à la suivante.
------
#### [ JSON ]
```
{
...
"Manifests": [
{
"Lifecycle": {
...
},
"Artifacts": [
{
"URI": "s3://amzn-s3-demo-bucket/artifacts/MyGreengrassComponent/1.0.0/artifact.py",
"Unarchive": "NONE"
}
]
}
]
}
```
**Note**
Vous pouvez ajouter l'`"Unarchive": "ZIP"`option pour un artefact ZIP afin de configurer le logiciel AWS IoT Greengrass principal afin de décompresser l'artefact lors du déploiement du composant.
------
#### [ YAML ]
```
...
Manifests:
- Lifecycle:
...
Artifacts:
- URI: s3://amzn-s3-demo-bucket/artifacts/MyGreengrassComponent/1.0.0/artifact.py
Unarchive: NONE
```
**Note**
Vous pouvez utiliser `Unarchive: ZIP` cette option pour configurer le logiciel AWS IoT Greengrass Core afin de décompresser un artefact ZIP lors du déploiement du composant. Pour plus d'informations sur l'utilisation des artefacts ZIP dans un composant, consultez la variable de recette [artifacts:DecompressedPath](component-recipe-reference.md#component-recipe-artifacts-decompressed-path).
------
Pour plus d'informations sur les recettes, consultez [AWS IoT Greengrass référence de recette de composant](component-recipe-reference.md).
1. Utilisez la AWS IoT Greengrass console pour créer un composant à partir du fichier de recette.
Exécutez la commande suivante pour créer le composant à partir d'un fichier de recette. Cette commande crée le composant et le publie en tant que AWS IoT Greengrass composant privé dans votre Compte AWS. Remplacez *path/to/recipeFile* par le chemin du fichier de recette.
```
aws greengrassv2 create-component-version --inline-recipe fileb://path/to/recipeFile
```
Copiez le contenu `arn` de la réponse pour vérifier l'état du composant à l'étape suivante.
**Note**
AWS IoT Greengrass calcule le condensé de chaque artefact lorsque vous créez le composant. Cela signifie que vous ne pouvez pas modifier les fichiers d'artefacts de votre compartiment S3 après avoir créé un composant. Dans ce cas, les déploiements incluant ce composant échoueront, car le résumé du fichier ne correspond pas. Si vous modifiez un fichier d'artefact, vous devez créer une nouvelle version du composant.
1. Chaque composant du AWS IoT Greengrass service possède un état. Exécutez la commande suivante pour confirmer l'état de la version du composant que vous publiez dans cette procédure. Remplacez *com.example.HelloWorld* et *1.0.0* par la version du composant à interroger. Remplacez le `arn` par l'ARN de l'étape précédente.
```
aws greengrassv2 describe-component --arn "arn:aws:greengrass:region:account-id:components:com.example.HelloWorld:versions:1.0.0"
```
L'opération renvoie une réponse contenant les métadonnées du composant. Les métadonnées contiennent un `status` objet qui contient l'état du composant et les éventuelles erreurs, le cas échéant.
Lorsque l'état du composant est `DEPLOYABLE` défini, vous pouvez le déployer sur des appareils. Pour de plus amples informations, veuillez consulter [Déployer AWS IoT Greengrass des composants sur des appareils](manage-deployments.md).
# Interagissez avec les AWS services
Les appareils principaux de Greengrass utilisent des certificats X.509 pour se connecter à l' AWS IoT Core aide des protocoles d'authentification mutuelle TLS. Ces certificats permettent aux appareils d'interagir AWS IoT sans AWS informations d'identification, qui comprennent généralement un identifiant de clé d'accès et une clé d'accès secrète. D'autres AWS services nécessitent des AWS informations d'identification au lieu de certificats X.509 pour appeler les opérations d'API aux points de terminaison du service. AWS IoT Core dispose d'un fournisseur d'informations d'identification qui permet aux appareils d'utiliser leur certificat X.509 pour AWS authentifier les demandes. Le fournisseur AWS IoT d'informations d'identification authentifie les appareils à l'aide d'un certificat X.509 et émet des AWS informations d'identification sous la forme d'un jeton de sécurité temporaire à privilèges limités. Les appareils peuvent utiliser ce jeton pour signer et authentifier toute AWS demande. Cela élimine le besoin de stocker les AWS informations d'identification sur les appareils principaux de Greengrass. Pour plus d'informations, consultez la section [Autorisation des appels directs vers AWS des services](https://docs.aws.amazon.com/iot/latest/developerguide/authorizing-direct-aws.html) dans le *Guide du AWS IoT Core développeur*.
Pour récupérer les informations d'identification auprès de Greengrass AWS IoT, les appareils principaux utilisent AWS IoT un alias de rôle qui pointe vers un rôle IAM. Ce rôle IAM est appelé rôle d'*échange de jetons*. Vous créez l'alias de rôle et le rôle d'échange de jetons lorsque vous installez le logiciel AWS IoT Greengrass Core. Pour spécifier l'alias de rôle utilisé par un périphérique principal, configurez le `iotRoleAlias` paramètre du[Noyau de Greengrass](greengrass-nucleus-component.md).
Le fournisseur AWS IoT d'informations d'identification assume le rôle d'échange de jetons en votre nom pour fournir des AWS informations d'identification aux appareils principaux. Vous pouvez associer des politiques IAM appropriées à ce rôle pour permettre à vos appareils principaux d'accéder à vos AWS ressources, telles que les artefacts des composants dans les compartiments S3. Pour plus d'informations sur la configuration du rôle d'échange de jetons, consultez[Autoriser les appareils principaux à interagir avec les AWS services](device-service-role.md).
Les appareils Greengrass Core stockent les AWS informations d'identification en mémoire, qui expirent au bout d'une heure par défaut. Si le logiciel AWS IoT Greengrass Core redémarre, il doit à nouveau récupérer les informations d'identification. Vous pouvez utiliser cette [UpdateRoleAlias](https://docs.aws.amazon.com/iot/latest/apireference/API_UpdateRoleAlias.html)opération pour configurer la durée de validité des informations d'identification.
AWS IoT Greengrass fournit un composant public, le composant du service d'échange de jetons, que vous pouvez définir comme une dépendance dans votre composant personnalisé pour interagir avec les AWS services. Le service d'échange de jetons fournit à votre composant une variable d'environnement qui définit l'URI d'un serveur local fournissant des AWS informations d'identification. `AWS_CONTAINER_CREDENTIALS_FULL_URI` Lorsque vous créez un client AWS SDK, le client vérifie la présence de cette variable d'environnement et se connecte au serveur local pour récupérer les AWS informations d'identification et les utilise pour signer les demandes d'API. Cela vous permet d'utiliser AWS SDKs d'autres outils pour appeler AWS des services dans vos composants. Pour de plus amples informations, veuillez consulter [Service d'échange de jetons](token-exchange-service-component.md).
**Important**
Support pour acquérir des AWS informations d'identification de cette manière a été ajouté AWS SDKs le 13 juillet 2016. Votre composant doit utiliser une version du AWS SDK créée à cette date ou après cette date. Pour plus d'informations, consultez la section [Utilisation d'un AWS SDK compatible](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html#task-iam-roles-minimum-sdk) dans le manuel *Amazon Elastic Container Service Developer Guide*.
Pour obtenir des AWS informations d'identification dans votre composant personnalisé, `aws.greengrass.TokenExchangeService` définissez-le en tant que dépendance dans la recette du composant. L'exemple de recette suivant définit un composant qui installe [boto3](https://boto3.amazonaws.com/v1/documentation/api/latest/index.html) et exécute un script Python qui utilise les informations d' AWS identification du service d'échange de jetons pour répertorier les buckets Amazon S3.
**Note**
Pour exécuter cet exemple de composant, votre appareil doit disposer de l'`s3:ListAllMyBuckets`autorisation. Pour de plus amples informations, veuillez consulter [Autoriser les appareils principaux à interagir avec les AWS services](device-service-role.md).
------
#### [ JSON ]
```
{
"RecipeFormatVersion": "2020-01-25",
"ComponentName": "com.example.ListS3Buckets",
"ComponentVersion": "1.0.0",
"ComponentDescription": "A component that uses the token exchange service to list S3 buckets.",
"ComponentPublisher": "Amazon",
"ComponentDependencies": {
"aws.greengrass.TokenExchangeService": {
"VersionRequirement": "^2.0.0",
"DependencyType": "HARD"
}
},
"Manifests": [
{
"Platform": {
"os": "linux"
},
"Lifecycle": {
"install": "pip3 install --user boto3",
"Run": "python3 -u {artifacts:path}/list_s3_buckets.py"
}
},
{
"Platform": {
"os": "windows"
},
"Lifecycle": {
"install": "pip3 install --user boto3",
"Run": "py -3 -u {artifacts:path}/list_s3_buckets.py"
}
}
]
}
```
------
#### [ YAML ]
```
---
RecipeFormatVersion: '2020-01-25'
ComponentName: com.example.ListS3Buckets
ComponentVersion: '1.0.0'
ComponentDescription: A component that uses the token exchange service to list S3 buckets.
ComponentPublisher: Amazon
ComponentDependencies:
aws.greengrass.TokenExchangeService:
VersionRequirement: '^2.0.0'
DependencyType: HARD
Manifests:
- Platform:
os: linux
Lifecycle:
install:
pip3 install --user boto3
Run: |-
python3 -u {artifacts:path}/list_s3_buckets.py
- Platform:
os: windows
Lifecycle:
install:
pip3 install --user boto3
Run: |-
py -3 -u {artifacts:path}/list_s3_buckets.py
```
------
Cet exemple de composant exécute le script Python suivant, `list_s3_buckets.py` qui répertorie les compartiments Amazon S3.
```
import boto3
import os
try:
print("Creating boto3 S3 client...")
s3 = boto3.client('s3')
print("Successfully created boto3 S3 client")
except Exception as e:
print("Failed to create boto3 s3 client. Error: " + str(e))
exit(1)
try:
print("Listing S3 buckets...")
response = s3.list_buckets()
for bucket in response['Buckets']:
print(f'\t{bucket["Name"]}')
print("Successfully listed S3 buckets")
except Exception as e:
print("Failed to list S3 buckets. Error: " + str(e))
exit(1)
```
# Exécuter un conteneur Docker
Vous pouvez configurer AWS IoT Greengrass des composants pour exécuter un conteneur [Docker](https://www.docker.com/) à partir d'images stockées aux emplacements suivants :
+ Référentiels d'images publics et privés dans Amazon Elastic Container Registry (Amazon ECR)
+ Référentiel Docker Hub public
+ Registre public de confiance Docker
+ compartiment S3
Dans votre composant personnalisé, incluez l'URI de l'image Docker en tant qu'artefact pour récupérer l'image et l'exécuter sur le périphérique principal. Pour les images Amazon ECR et Docker Hub, vous pouvez utiliser le composant du [gestionnaire d'applications Docker](docker-application-manager-component.md) pour télécharger les images et gérer les informations d'identification des référentiels Amazon ECR privés.
**Topics**
+ [Exigences](#run-docker-container-requirements)
+ [Exécuter un conteneur Docker à partir d'une image publique dans Amazon ECR ou Docker Hub](#run-docker-container-public-ecr-dockerhub)
+ [Exécuter un conteneur Docker à partir d'une image privée dans Amazon ECR](#run-docker-container-private-ecr)
+ [Exécuter un conteneur Docker à partir d'une image dans Amazon S3](#run-docker-container-s3)
+ [Utiliser la communication interprocessus dans les composants du conteneur Docker](#docker-container-ipc)
+ [Utiliser les AWS informations d'identification dans les composants du conteneur Docker (Linux)](#docker-container-token-exchange-service)
+ [Utiliser le gestionnaire de flux dans les composants du conteneur Docker (Linux)](#docker-container-stream-manager)
## Exigences
Pour exécuter un conteneur Docker dans un composant, vous avez besoin des éléments suivants :
+ Un appareil Greengrass Core. Si vous n'en avez pas, veuillez consulter [Tutoriel : Débuter avec AWS IoT Greengrass V2](getting-started.md).
+ [Docker Engine](https://docs.docker.com/engine/) 1.9.1 ou version ultérieure installé sur le périphérique principal de Greengrass. La version 20.10 est la dernière version vérifiée pour fonctionner avec le logiciel AWS IoT Greengrass Core. Vous devez installer Docker directement sur le périphérique principal avant de déployer des composants qui exécutent des conteneurs Docker.
**Astuce**
Vous pouvez également configurer le périphérique principal pour installer Docker Engine lors de l'installation du composant. Par exemple, le script d'installation suivant installe Docker Engine avant de charger l'image Docker. Ce script d'installation fonctionne sur les distributions Linux basées sur Debian, telles qu'Ubuntu. Si vous configurez le composant pour installer Docker Engine à l'aide de cette commande, vous devrez peut-être le `RequiresPrivilege` définir `true` dans le script de cycle de vie pour exécuter l'installation et `docker` les commandes. Pour de plus amples informations, veuillez consulter [AWS IoT Greengrass référence de recette de composant](component-recipe-reference.md).
```
apt-get install docker-ce docker-ce-cli containerd.io && docker load -i {artifacts:path}/hello-world.tar
```
+ L'utilisateur du système qui exécute un composant de conteneur Docker doit disposer des autorisations root ou administrateur, ou vous devez configurer Docker pour l'exécuter en tant qu'utilisateur non root ou non administrateur.
+ Sur les appareils Linux, vous pouvez ajouter un utilisateur au `docker` groupe sans lequel vous pouvez appeler `docker` des commandes`sudo`.
+ Sur les appareils Windows, vous pouvez ajouter un utilisateur au `docker-users` groupe pour appeler des `docker` commandes sans privilèges d'administrateur.
------
#### [ Linux or Unix ]
Pour ajouter `ggc_user` au `docker` groupe l'utilisateur non root que vous utilisez pour exécuter les composants du conteneur Docker, exécutez la commande suivante.
```
sudo usermod -aG docker ggc_user
```
Pour plus d'informations, consultez [Gérer Docker en tant qu'utilisateur non root](https://docs.docker.com/engine/install/linux-postinstall/#manage-docker-as-a-non-root-user).
------
#### [ Windows Command Prompt (CMD) ]
Pour ajouter `ggc_user` au `docker-users` groupe l'utilisateur que vous utilisez pour exécuter les composants du conteneur Docker, exécutez la commande suivante en tant qu'administrateur.
```
net localgroup docker-users ggc_user /add
```
------
#### [ Windows PowerShell ]
Pour ajouter `ggc_user` au `docker-users` groupe l'utilisateur que vous utilisez pour exécuter les composants du conteneur Docker, exécutez la commande suivante en tant qu'administrateur.
```
Add-LocalGroupMember -Group docker-users -Member ggc_user
```
------
+ Fichiers accessibles par le composant de conteneur Docker [montés sous forme de volume](https://docs.docker.com/storage/volumes/) dans le conteneur Docker.
+ Si vous [configurez le logiciel AWS IoT Greengrass Core pour utiliser un proxy réseau](configure-greengrass-core-v2.md#configure-alpn-network-proxy), vous devez [configurer Docker pour qu'il utilise le même serveur proxy](https://docs.docker.com/network/proxy/).
Outre ces exigences, vous devez également satisfaire aux exigences suivantes si elles s'appliquent à votre environnement :
+ Pour utiliser [Docker Compose](https://docs.docker.com/compose/) pour créer et démarrer vos conteneurs Docker, installez Docker Compose sur votre appareil principal Greengrass et téléchargez votre fichier Docker Compose dans un compartiment S3. Vous devez stocker votre fichier Compose dans un compartiment S3 au même Compte AWS endroit Région AWS que le composant. Pour un exemple d'utilisation de la `docker-compose up` commande dans un composant personnalisé, consultez[Exécuter un conteneur Docker à partir d'une image publique dans Amazon ECR ou Docker Hub](#run-docker-container-public-ecr-dockerhub).
+ Si vous utilisez un AWS IoT Greengrass proxy réseau, configurez le daemon Docker pour qu'il utilise un [serveur proxy](https://docs.docker.com/network/proxy/).
+ Si vos images Docker sont stockées dans Amazon ECR ou Docker Hub, incluez le [composant du gestionnaire de composants Docker](docker-application-manager-component.md) en tant que dépendance dans votre composant conteneur Docker. Vous devez démarrer le démon Docker sur l'appareil principal avant de déployer votre composant.
Incluez également l'image URIs en tant qu'artefacts de composant. L'image URIs doit être au format `docker:registry/image[:tag|@digest]` indiqué dans les exemples suivants :
+ Image Amazon ECR privée : `docker:account-id.dkr.ecr.region.amazonaws.com/repository/image[:tag|@digest]`
+ Image Amazon ECR publique : `docker:public.ecr.aws/repository/image[:tag|@digest]`
+ Image publique du Docker Hub : `docker:name[:tag|@digest]`
Pour plus d'informations sur l'exécution de conteneurs Docker à partir d'images stockées dans des référentiels publics, consultez. [Exécuter un conteneur Docker à partir d'une image publique dans Amazon ECR ou Docker Hub](#run-docker-container-public-ecr-dockerhub)
+ Si vos images Docker sont stockées dans un référentiel privé Amazon ECR, vous devez inclure le composant du service d'échange de jetons en tant que dépendance dans le composant conteneur Docker. En outre, le [rôle d'appareil Greengrass](device-service-role.md) doit autoriser les `ecr:GetDownloadUrlForLayer` actions `ecr:GetAuthorizationToken``ecr:BatchGetImage`, et, comme indiqué dans l'exemple de politique IAM suivant.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ecr:GetAuthorizationToken",
"ecr:BatchGetImage",
"ecr:GetDownloadUrlForLayer"
],
"Resource": [
"*"
],
"Effect": "Allow"
}
]
}
```
------
Pour plus d'informations sur l'exécution de conteneurs Docker à partir d'images stockées dans un référentiel privé Amazon ECR, consultez. [Exécuter un conteneur Docker à partir d'une image privée dans Amazon ECR](#run-docker-container-private-ecr)
+ Pour utiliser des images Docker stockées dans un référentiel privé Amazon ECR, celui-ci doit se trouver dans le même emplacement Région AWS que le périphérique principal.
+ Si vos images Docker ou vos fichiers Compose sont stockés dans un compartiment S3, le rôle d'[appareil Greengrass](device-service-role.md) doit autoriser `s3:GetObject` les appareils principaux à télécharger les images en tant qu'artefacts de composants, comme illustré dans l'exemple de politique IAM suivant.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"s3:GetObject"
],
"Resource": [
"*"
],
"Effect": "Allow"
}
]
}
```
------
Pour plus d'informations sur l'exécution de conteneurs Docker à partir d'images stockées dans Amazon S3, consultez[Exécuter un conteneur Docker à partir d'une image dans Amazon S3](#run-docker-container-s3).
+ Pour utiliser la communication interprocessus (IPC), les AWS informations d'identification ou le gestionnaire de flux dans votre composant de conteneur Docker, vous devez spécifier des options supplémentaires lorsque vous exécutez le conteneur Docker. Pour plus d’informations, consultez les ressources suivantes :
+ [Utiliser la communication interprocessus dans les composants du conteneur Docker](#docker-container-ipc)
+ [Utiliser les AWS informations d'identification dans les composants du conteneur Docker (Linux)](#docker-container-token-exchange-service)
+ [Utiliser le gestionnaire de flux dans les composants du conteneur Docker (Linux)](#docker-container-stream-manager)
## Exécuter un conteneur Docker à partir d'une image publique dans Amazon ECR ou Docker Hub
Cette section décrit comment créer un composant personnalisé qui utilise Docker Compose pour exécuter un conteneur Docker à partir d'images Docker stockées sur Amazon ECR et Docker Hub.
**Pour exécuter un conteneur Docker à l'aide de Docker Compose**
1. Créez et chargez un fichier Docker Compose dans un compartiment Amazon S3. Assurez-vous que le [rôle d'appareil Greengrass](device-service-role.md) `s3:GetObject` autorise l'appareil à accéder au fichier Compose. L'exemple de fichier Compose présenté dans l'exemple suivant inclut l'image Amazon CloudWatch Agent d'Amazon ECR et l'image MySQL de Docker Hub.
```
version: "3"
services:
cloudwatchagent:
image: "public.ecr.aws/cloudwatch-agent/cloudwatch-agent:latest"
mysql:
image: "mysql:8.0"
```
1. [Créez un composant personnalisé](create-components.md) sur votre appareil AWS IoT Greengrass principal. L'exemple de recette présenté dans l'exemple suivant possède les propriétés suivantes :
+ Le composant du gestionnaire d'applications Docker en tant que dépendance. Ce composant permet AWS IoT Greengrass de télécharger des images depuis les référentiels publics Amazon ECR et Docker Hub.
+ Artefact de composant qui spécifie une image Docker dans un référentiel Amazon ECR public.
+ Artefact de composant qui spécifie une image Docker dans un référentiel Docker Hub public.
+ Artefact de composant qui spécifie le fichier Docker Compose qui inclut les conteneurs pour les images Docker que vous souhaitez exécuter.
+ Script d'exécution du cycle de vie qui utilise [docker-compose up](https://docs.docker.com/compose/reference/up/) pour créer et démarrer un conteneur à partir des images spécifiées.
------
#### [ JSON ]
```
{
"RecipeFormatVersion": "2020-01-25",
"ComponentName": "com.example.MyDockerComposeComponent",
"ComponentVersion": "1.0.0",
"ComponentDescription": "A component that uses Docker Compose to run images from public Amazon ECR and Docker Hub.",
"ComponentPublisher": "Amazon",
"ComponentDependencies": {
"aws.greengrass.DockerApplicationManager": {
"VersionRequirement": "~2.0.0"
}
},
"Manifests": [
{
"Platform": {
"os": "all"
},
"Lifecycle": {
"Run": "docker-compose -f {artifacts:path}/docker-compose.yaml up"
},
"Artifacts": [
{
"URI": "docker:public.ecr.aws/cloudwatch-agent/cloudwatch-agent:latest"
},
{
"URI": "docker:mysql:8.0"
},
{
"URI": "s3://amzn-s3-demo-bucket/folder/docker-compose.yaml"
}
]
}
]
}
```
------
#### [ YAML ]
```
---
RecipeFormatVersion: '2020-01-25'
ComponentName: com.example.MyDockerComposeComponent
ComponentVersion: '1.0.0'
ComponentDescription: 'A component that uses Docker Compose to run images from public Amazon ECR and Docker Hub.'
ComponentPublisher: Amazon
ComponentDependencies:
aws.greengrass.DockerApplicationManager:
VersionRequirement: ~2.0.0
Manifests:
- Platform:
os: all
Lifecycle:
Run: docker-compose -f {artifacts:path}/docker-compose.yaml up
Artifacts:
- URI: "docker:public.ecr.aws/cloudwatch-agent/cloudwatch-agent:latest"
- URI: "docker:mysql:8.0"
- URI: "s3://amzn-s3-demo-bucket/folder/docker-compose.yaml"
```
------
**Note**
Pour utiliser la communication interprocessus (IPC), les AWS informations d'identification ou le gestionnaire de flux dans votre composant de conteneur Docker, vous devez spécifier des options supplémentaires lorsque vous exécutez le conteneur Docker. Pour plus d’informations, consultez les ressources suivantes :
[Utiliser la communication interprocessus dans les composants du conteneur Docker](#docker-container-ipc)
[Utiliser les AWS informations d'identification dans les composants du conteneur Docker (Linux)](#docker-container-token-exchange-service)
[Utiliser le gestionnaire de flux dans les composants du conteneur Docker (Linux)](#docker-container-stream-manager)
1. [Testez le composant](test-components.md) pour vérifier qu'il fonctionne comme prévu.
**Important**
Vous devez installer et démarrer le démon Docker avant de déployer le composant.
Après avoir déployé le composant localement, vous pouvez exécuter la commande [docker container ls](https://docs.docker.com/engine/reference/commandline/container_ls/) pour vérifier que votre conteneur fonctionne.
```
docker container ls
```
1. Lorsque le composant est prêt, téléchargez-le AWS IoT Greengrass vers pour le déployer sur d'autres appareils principaux. Pour de plus amples informations, veuillez consulter [Publiez des composants à déployer sur vos appareils principaux](publish-components.md).
## Exécuter un conteneur Docker à partir d'une image privée dans Amazon ECR
Cette section décrit comment créer un composant personnalisé qui exécute un conteneur Docker à partir d'une image Docker stockée dans un référentiel privé sur Amazon ECR.
**Pour exécuter un conteneur Docker**
1. [Créez un composant personnalisé](create-components.md) sur votre appareil AWS IoT Greengrass principal. Utilisez l'exemple de recette suivant, qui possède les propriétés suivantes :
+ Le composant du gestionnaire d'applications Docker en tant que dépendance. Ce composant permet AWS IoT Greengrass de gérer les informations d'identification pour télécharger des images depuis des référentiels privés.
+ Le composant du service d'échange de jetons en tant que dépendance. Ce composant permet de AWS IoT Greengrass récupérer les AWS informations d'identification pour interagir avec Amazon ECR.
+ Artefact de composant qui spécifie une image Docker dans un référentiel Amazon ECR privé.
+ Script d'exécution du cycle de vie qui utilise [docker run](https://docs.docker.com/engine/reference/commandline/run/) pour créer et démarrer un conteneur à partir de l'image.
------
#### [ JSON ]
```
{
"RecipeFormatVersion": "2020-01-25",
"ComponentName": "com.example.MyPrivateDockerComponent",
"ComponentVersion": "1.0.0",
"ComponentDescription": "A component that runs a Docker container from a private Amazon ECR image.",
"ComponentPublisher": "Amazon",
"ComponentDependencies": {
"aws.greengrass.DockerApplicationManager": {
"VersionRequirement": "~2.0.0"
},
"aws.greengrass.TokenExchangeService": {
"VersionRequirement": "~2.0.0"
}
},
"Manifests": [
{
"Platform": {
"os": "all"
},
"Lifecycle": {
"Run": "docker run account-id.dkr.ecr.region.amazonaws.com/repository[:tag|@digest]"
},
"Artifacts": [
{
"URI": "docker:account-id.dkr.ecr.region.amazonaws.com/repository[:tag|@digest]"
}
]
}
]
}
```
------
#### [ YAML ]
```
---
RecipeFormatVersion: '2020-01-25'
ComponentName: com.example.MyPrivateDockerComponent
ComponentVersion: '1.0.0'
ComponentDescription: 'A component that runs a Docker container from a private Amazon ECR image.'
ComponentPublisher: Amazon
ComponentDependencies:
aws.greengrass.DockerApplicationManager:
VersionRequirement: ~2.0.0
aws.greengrass.TokenExchangeService:
VersionRequirement: ~2.0.0
Manifests:
- Platform:
os: all
Lifecycle:
Run: docker run account-id.dkr.ecr.region.amazonaws.com/repository[:tag|@digest]
Artifacts:
- URI: "docker:account-id.dkr.ecr.region.amazonaws.com/repository[:tag|@digest]"
```
------
**Note**
Pour utiliser la communication interprocessus (IPC), les AWS informations d'identification ou le gestionnaire de flux dans votre composant de conteneur Docker, vous devez spécifier des options supplémentaires lorsque vous exécutez le conteneur Docker. Pour plus d’informations, consultez les ressources suivantes :
[Utiliser la communication interprocessus dans les composants du conteneur Docker](#docker-container-ipc)
[Utiliser les AWS informations d'identification dans les composants du conteneur Docker (Linux)](#docker-container-token-exchange-service)
[Utiliser le gestionnaire de flux dans les composants du conteneur Docker (Linux)](#docker-container-stream-manager)
1. [Testez le composant](test-components.md) pour vérifier qu'il fonctionne comme prévu.
**Important**
Vous devez installer et démarrer le démon Docker avant de déployer le composant.
Après avoir déployé le composant localement, vous pouvez exécuter la commande [docker container ls](https://docs.docker.com/engine/reference/commandline/container_ls/) pour vérifier que votre conteneur fonctionne.
```
docker container ls
```
1. Téléchargez le composant AWS IoT Greengrass vers pour le déployer sur d'autres appareils principaux. Pour de plus amples informations, veuillez consulter [Publiez des composants à déployer sur vos appareils principaux](publish-components.md).
## Exécuter un conteneur Docker à partir d'une image dans Amazon S3
Cette section décrit comment exécuter un conteneur Docker dans un composant à partir d'une image Docker stockée dans Amazon S3.
**Pour exécuter un conteneur Docker dans un composant à partir d'une image dans Amazon S3**
1. Exécutez la commande [docker save](https://docs.docker.com/engine/reference/commandline/save/) pour créer une sauvegarde d'un conteneur Docker. Vous fournissez cette sauvegarde en tant qu'artefact de composant sur AWS IoT Greengrass lequel exécuter le conteneur. Remplacez *hello-world* par le nom de l'image, puis *hello-world.tar* par le nom du fichier d'archive à créer.
```
docker save hello-world > artifacts/com.example.MyDockerComponent/1.0.0/hello-world.tar
```
1. [Créez un composant personnalisé](create-components.md) sur votre appareil AWS IoT Greengrass principal. Utilisez l'exemple de recette suivant, qui possède les propriétés suivantes :
+ Script d'installation du cycle de vie qui utilise le chargement de [docker pour charger](https://docs.docker.com/engine/reference/commandline/load/) une image Docker à partir d'une archive.
+ Script d'exécution du cycle de vie qui utilise [docker run](https://docs.docker.com/engine/reference/commandline/run/) pour créer et démarrer un conteneur à partir de l'image. L'`--rm`option nettoie le conteneur à sa sortie.
------
#### [ JSON ]
```
{
"RecipeFormatVersion": "2020-01-25",
"ComponentName": "com.example.MyS3DockerComponent",
"ComponentVersion": "1.0.0",
"ComponentDescription": "A component that runs a Docker container from an image in an S3 bucket.",
"ComponentPublisher": "Amazon",
"Manifests": [
{
"Platform": {
"os": "linux"
},
"Lifecycle": {
"install": {
"Script": "docker load -i {artifacts:path}/hello-world.tar"
},
"Run": {
"Script": "docker run --rm hello-world"
}
}
}
]
}
```
------
#### [ YAML ]
```
---
RecipeFormatVersion: '2020-01-25'
ComponentName: com.example.MyS3DockerComponent
ComponentVersion: '1.0.0'
ComponentDescription: 'A component that runs a Docker container from an image in an S3 bucket.'
ComponentPublisher: Amazon
Manifests:
- Platform:
os: linux
Lifecycle:
install:
Script: docker load -i {artifacts:path}/hello-world.tar
Run:
Script: docker run --rm hello-world
```
------
**Note**
Pour utiliser la communication interprocessus (IPC), les AWS informations d'identification ou le gestionnaire de flux dans votre composant de conteneur Docker, vous devez spécifier des options supplémentaires lorsque vous exécutez le conteneur Docker. Pour plus d’informations, consultez les ressources suivantes :
[Utiliser la communication interprocessus dans les composants du conteneur Docker](#docker-container-ipc)
[Utiliser les AWS informations d'identification dans les composants du conteneur Docker (Linux)](#docker-container-token-exchange-service)
[Utiliser le gestionnaire de flux dans les composants du conteneur Docker (Linux)](#docker-container-stream-manager)
1. [Testez le composant](test-components.md) pour vérifier qu'il fonctionne comme prévu.
Après avoir déployé le composant localement, vous pouvez exécuter la commande [docker container ls](https://docs.docker.com/engine/reference/commandline/container_ls/) pour vérifier que votre conteneur fonctionne.
```
docker container ls
```
1. Lorsque le composant est prêt, téléchargez l'archive d'images Docker dans un compartiment S3 et ajoutez son URI à la recette du composant. Vous pouvez ensuite télécharger le composant pour le AWS IoT Greengrass déployer sur d'autres appareils principaux. Pour de plus amples informations, veuillez consulter [Publiez des composants à déployer sur vos appareils principaux](publish-components.md).
Lorsque vous avez terminé, la recette du composant doit ressembler à l'exemple suivant.
------
#### [ JSON ]
```
{
"RecipeFormatVersion": "2020-01-25",
"ComponentName": "com.example.MyS3DockerComponent",
"ComponentVersion": "1.0.0",
"ComponentDescription": "A component that runs a Docker container from an image in an S3 bucket.",
"ComponentPublisher": "Amazon",
"Manifests": [
{
"Platform": {
"os": "linux"
},
"Lifecycle": {
"install": {
"Script": "docker load -i {artifacts:path}/hello-world.tar"
},
"Run": {
"Script": "docker run --rm hello-world"
}
},
"Artifacts": [
{
"URI": "s3://amzn-s3-demo-bucket/artifacts/com.example.MyDockerComponent/1.0.0/hello-world.tar"
}
]
}
]
}
```
------
#### [ YAML ]
```
---
RecipeFormatVersion: '2020-01-25'
ComponentName: com.example.MyS3DockerComponent
ComponentVersion: '1.0.0'
ComponentDescription: 'A component that runs a Docker container from an image in an S3 bucket.'
ComponentPublisher: Amazon
Manifests:
- Platform:
os: linux
Lifecycle:
install:
Script: docker load -i {artifacts:path}/hello-world.tar
Run:
Script: docker run --rm hello-world
Artifacts:
- URI: s3://amzn-s3-demo-bucket/artifacts/com.example.MyDockerComponent/1.0.0/hello-world.tar
```
------
## Utiliser la communication interprocessus dans les composants du conteneur Docker
Vous pouvez utiliser la bibliothèque de communication interprocessus (IPC) Greengrass dans le Kit SDK des appareils AWS IoT pour communiquer avec le noyau de Greengrass, les autres composants de Greengrass et. AWS IoT Core Pour de plus amples informations, veuillez consulter [Utilisez le Kit SDK des appareils AWS IoT pour communiquer avec le noyau de Greengrass, les autres composants et AWS IoT CoreCommuniquez avec le noyau de Greengrass, les autres composants et AWS IoT Core](interprocess-communication.md).
Pour utiliser IPC dans un composant de conteneur Docker, vous devez exécuter le conteneur Docker avec les paramètres suivants :
+ Montez le socket IPC dans le conteneur. Le noyau Greengrass fournit le chemin du fichier du socket IPC dans la `AWS_GG_NUCLEUS_DOMAIN_SOCKET_FILEPATH_FOR_COMPONENT` variable d'environnement.
+ Définissez les variables d'`AWS_GG_NUCLEUS_DOMAIN_SOCKET_FILEPATH_FOR_COMPONENT`environnement `SVCUID` et sur les valeurs que le noyau Greengrass fournit aux composants. Votre composant utilise ces variables d'environnement pour authentifier les connexions au noyau Greengrass.
**Example Exemple de recette : publier un message MQTT sur AWS IoT Core (Python)**
La recette suivante définit un exemple de composant de conteneur Docker qui publie un message MQTT sur. AWS IoT Core Cette recette possède les propriétés suivantes :
+ Une politique d'autorisation (`accessControl`) qui permet au composant de publier des messages MQTT AWS IoT Core sur tous les sujets. Pour plus d'informations, consultez [Autoriser les composants à effectuer des opérations IPC](interprocess-communication.md#ipc-authorization-policies) et autorisation [AWS IoT Core MQTT IPC](ipc-iot-core-mqtt.md#ipc-iot-core-mqtt-authorization).
+ Artefact de composant qui spécifie une image Docker en tant qu'archive TAR dans Amazon S3.
+ Script d'installation du cycle de vie qui charge l'image Docker depuis l'archive TAR.
+ Script d'exécution du cycle de vie qui exécute un conteneur Docker à partir de l'image. La commande [Docker run](https://docs.docker.com/engine/reference/run/) comporte les arguments suivants :
+ L'`-v`argument monte le socket IPC Greengrass dans le conteneur.
+ Les deux premiers `-e` arguments définissent les variables d'environnement requises dans le conteneur Docker.
+ Les `-e` arguments supplémentaires définissent les variables d'environnement utilisées dans cet exemple.
+ L'`--rm`argument nettoie le conteneur à sa sortie.
```
{
"RecipeFormatVersion": "2020-01-25",
"ComponentName": "com.example.python.docker.PublishToIoTCore",
"ComponentVersion": "1.0.0",
"ComponentDescription": "Uses interprocess communication to publish an MQTT message to IoT Core.",
"ComponentPublisher": "Amazon",
"ComponentConfiguration": {
"DefaultConfiguration": {
"topic": "test/topic/java",
"message": "Hello, World!",
"qos": "1",
"accessControl": {
"aws.greengrass.ipc.mqttproxy": {
"com.example.python.docker.PublishToIoTCore:pubsub:1": {
"policyDescription": "Allows access to publish to IoT Core on all topics.",
"operations": [
"aws.greengrass#PublishToIoTCore"
],
"resources": [
"*"
]
}
}
}
}
},
"Manifests": [
{
"Platform": {
"os": "all"
},
"Lifecycle": {
"install": "docker load -i {artifacts:path}/publish-to-iot-core.tar",
"Run": "docker run -v $AWS_GG_NUCLEUS_DOMAIN_SOCKET_FILEPATH_FOR_COMPONENT:$AWS_GG_NUCLEUS_DOMAIN_SOCKET_FILEPATH_FOR_COMPONENT -e SVCUID -e AWS_GG_NUCLEUS_DOMAIN_SOCKET_FILEPATH_FOR_COMPONENT -e MQTT_TOPIC=\"{configuration:/topic}\" -e MQTT_MESSAGE=\"{configuration:/message}\" -e MQTT_QOS=\"{configuration:/qos}\" --rm publish-to-iot-core"
},
"Artifacts": [
{
"URI": "s3://amzn-s3-demo-bucket/artifacts/com.example.python.docker.PublishToIoTCore/1.0.0/publish-to-iot-core.tar"
}
]
}
]
}
```
```
RecipeFormatVersion: '2020-01-25'
ComponentName: com.example.python.docker.PublishToIoTCore
ComponentVersion: 1.0.0
ComponentDescription: Uses interprocess communication to publish an MQTT message to IoT Core.
ComponentPublisher: Amazon
ComponentConfiguration:
DefaultConfiguration:
topic: 'test/topic/java'
message: 'Hello, World!'
qos: '1'
accessControl:
aws.greengrass.ipc.mqttproxy:
'com.example.python.docker.PublishToIoTCore:pubsub:1':
policyDescription: Allows access to publish to IoT Core on all topics.
operations:
- 'aws.greengrass#PublishToIoTCore'
resources:
- '*'
Manifests:
- Platform:
os: all
Lifecycle:
install: 'docker load -i {artifacts:path}/publish-to-iot-core.tar'
Run: |
docker run \
-v $AWS_GG_NUCLEUS_DOMAIN_SOCKET_FILEPATH_FOR_COMPONENT:$AWS_GG_NUCLEUS_DOMAIN_SOCKET_FILEPATH_FOR_COMPONENT \
-e SVCUID \
-e AWS_GG_NUCLEUS_DOMAIN_SOCKET_FILEPATH_FOR_COMPONENT \
-e MQTT_TOPIC="{configuration:/topic}" \
-e MQTT_MESSAGE="{configuration:/message}" \
-e MQTT_QOS="{configuration:/qos}" \
--rm publish-to-iot-core
Artifacts:
- URI: s3://amzn-s3-demo-bucket/artifacts/com.example.python.docker.PublishToIoTCore/1.0.0/publish-to-iot-core.tar
```
## Utiliser les AWS informations d'identification dans les composants du conteneur Docker (Linux)
Vous pouvez utiliser le [composant de service d'échange de jetons](token-exchange-service-component.md) pour interagir avec les AWS services des composants Greengrass. Ce composant fournit des AWS informations d'identification provenant du [rôle d'échange de jetons](device-service-role.md) du périphérique principal à l'aide d'un serveur de conteneurs local. Pour de plus amples informations, veuillez consulter [Interagissez avec les AWS services](interact-with-aws-services.md).
**Note**
L'exemple présenté dans cette section ne fonctionne que sur les appareils principaux de Linux.
Pour utiliser les AWS informations d'identification du service d'échange de jetons dans un composant de conteneur Docker, vous devez exécuter le conteneur Docker avec les paramètres suivants :
+ Fournissez l'accès au réseau hôte à l'aide de l'`--network=host`argument. Cette option permet au conteneur Docker de se connecter au service d'échange de jetons local pour récupérer les AWS informations d'identification. Cet argument ne fonctionne que sur Docker pour Linux.
**Avertissement**
Cette option permet au conteneur d'accéder à toutes les interfaces réseau locales de l'hôte. Elle est donc moins sécurisée que si vous exécutez des conteneurs Docker sans cet accès au réseau hôte. Tenez-en compte lorsque vous développez et exécutez des composants de conteneur Docker qui utilisent cette option. Pour plus d'informations, consultez [Network : host](https://docs.docker.com/engine/reference/run/#network-host) dans la *documentation Docker*.
+ Définissez les variables d'`AWS_CONTAINER_AUTHORIZATION_TOKEN`environnement `AWS_CONTAINER_CREDENTIALS_FULL_URI` et sur les valeurs que le noyau Greengrass fournit aux composants. AWS SDKs utilisez ces variables d'environnement pour récupérer les AWS informations d'identification.
**Example Exemple de recette : répertorier les compartiments S3 dans un composant de conteneur Docker (Python)**
La recette suivante définit un exemple de composant de conteneur Docker qui répertorie les compartiments S3 de votre. Compte AWS Cette recette possède les propriétés suivantes :
+ Le composant du service d'échange de jetons en tant que dépendance. Cette dépendance permet au composant de récupérer des AWS informations d'identification pour interagir avec d'autres AWS services.
+ Artefact de composant qui spécifie une image Docker sous forme d'archive tar dans Amazon S3.
+ Script d'installation du cycle de vie qui charge l'image Docker depuis l'archive TAR.
+ Script d'exécution du cycle de vie qui exécute un conteneur Docker à partir de l'image. La commande [Docker run](https://docs.docker.com/engine/reference/run/) comporte les arguments suivants :
+ L'`--network=host`argument fournit au conteneur l'accès au réseau hôte, afin que le conteneur puisse se connecter au service d'échange de jetons.
+ L'`-e`argument définit les variables d'environnement requises dans le conteneur Docker.
+ L'`--rm`argument nettoie le conteneur à sa sortie.
```
{
"RecipeFormatVersion": "2020-01-25",
"ComponentName": "com.example.python.docker.ListS3Buckets",
"ComponentVersion": "1.0.0",
"ComponentDescription": "Uses the token exchange service to lists your S3 buckets.",
"ComponentPublisher": "Amazon",
"ComponentDependencies": {
"aws.greengrass.TokenExchangeService": {
"VersionRequirement": "^2.0.0",
"DependencyType": "HARD"
}
},
"Manifests": [
{
"Platform": {
"os": "linux"
},
"Lifecycle": {
"install": "docker load -i {artifacts:path}/list-s3-buckets.tar",
"Run": "docker run --network=host -e AWS_CONTAINER_AUTHORIZATION_TOKEN -e AWS_CONTAINER_CREDENTIALS_FULL_URI --rm list-s3-buckets"
},
"Artifacts": [
{
"URI": "s3://amzn-s3-demo-bucket/artifacts/com.example.python.docker.ListS3Buckets/1.0.0/list-s3-buckets.tar"
}
]
}
]
}
```
```
RecipeFormatVersion: '2020-01-25'
ComponentName: com.example.python.docker.ListS3Buckets
ComponentVersion: 1.0.0
ComponentDescription: Uses the token exchange service to lists your S3 buckets.
ComponentPublisher: Amazon
ComponentDependencies:
aws.greengrass.TokenExchangeService:
VersionRequirement: ^2.0.0
DependencyType: HARD
Manifests:
- Platform:
os: linux
Lifecycle:
install: 'docker load -i {artifacts:path}/list-s3-buckets.tar'
Run: |
docker run \
--network=host \
-e AWS_CONTAINER_AUTHORIZATION_TOKEN \
-e AWS_CONTAINER_CREDENTIALS_FULL_URI \
--rm list-s3-buckets
Artifacts:
- URI: s3://amzn-s3-demo-bucket/artifacts/com.example.python.docker.ListS3Buckets/1.0.0/list-s3-buckets.tar
```
## Utiliser le gestionnaire de flux dans les composants du conteneur Docker (Linux)
Vous pouvez utiliser le [composant gestionnaire de flux](stream-manager-component.md) pour gérer les flux de données dans les composants Greengrass. Ce composant vous permet de traiter des flux de données et de transférer de gros volumes de données IoT vers le AWS Cloud. AWS IoT Greengrass fournit un SDK de gestion de flux que vous utilisez pour interagir avec le composant de gestionnaire de flux. Pour de plus amples informations, veuillez consulter [Gérez les flux de données sur les appareils principaux de Greengrass](manage-data-streams.md).
**Note**
L'exemple présenté dans cette section ne fonctionne que sur les appareils principaux de Linux.
Pour utiliser le SDK du gestionnaire de flux dans un composant de conteneur Docker, vous devez exécuter le conteneur Docker avec les paramètres suivants :
+ Fournissez l'accès au réseau hôte à l'aide de l'`--network=host`argument. Cette option permet au conteneur Docker d'interagir avec le composant du gestionnaire de flux via une connexion TLS locale. Cet argument ne fonctionne que sur Docker pour Linux
**Avertissement**
Cette option permet au conteneur d'accéder à toutes les interfaces réseau locales de l'hôte. Elle est donc moins sécurisée que si vous exécutez des conteneurs Docker sans cet accès au réseau hôte. Tenez-en compte lorsque vous développez et exécutez des composants de conteneur Docker qui utilisent cette option. Pour plus d'informations, consultez [Network : host](https://docs.docker.com/engine/reference/run/#network-host) dans la *documentation Docker*.
+ Si vous configurez le composant du gestionnaire de flux pour exiger une authentification, qui est le comportement par défaut, définissez la variable d'`AWS_CONTAINER_CREDENTIALS_FULL_URI`environnement sur la valeur que le noyau Greengrass fournit aux composants. Pour plus d'informations, consultez la section [Configuration du gestionnaire de flux](stream-manager-component.md#stream-manager-component-configuration).
+ Si vous configurez le composant du gestionnaire de flux pour utiliser un port autre que celui par défaut, utilisez la [communication interprocessus (IPC)](interprocess-communication.md) pour obtenir le port à partir de la configuration du composant du gestionnaire de flux. Vous devez exécuter le conteneur Docker avec des options supplémentaires pour utiliser IPC. Pour plus d’informations, consultez les ressources suivantes :
+ [Connectez-vous au gestionnaire de flux dans le code de l'application](use-stream-manager-in-custom-components.md#connect-to-stream-manager)
+ [Utiliser la communication interprocessus dans les composants du conteneur Docker](#docker-container-ipc)
**Example Exemple de recette : Diffuser un fichier vers un compartiment S3 dans un composant de conteneur Docker (Python)**
La recette suivante définit un exemple de composant de conteneur Docker qui crée un fichier et le diffuse vers un compartiment S3. Cette recette possède les propriétés suivantes :
+ Le composant du gestionnaire de flux en tant que dépendance. Cette dépendance permet au composant d'utiliser le SDK du gestionnaire de flux pour interagir avec le composant du gestionnaire de flux.
+ Artefact de composant qui spécifie une image Docker en tant qu'archive TAR dans Amazon S3.
+ Script d'installation du cycle de vie qui charge l'image Docker depuis l'archive TAR.
+ Script d'exécution du cycle de vie qui exécute un conteneur Docker à partir de l'image. La commande [Docker run](https://docs.docker.com/engine/reference/run/) comporte les arguments suivants :
+ L'`--network=host`argument fournit au conteneur l'accès au réseau hôte, afin que le conteneur puisse se connecter au composant du gestionnaire de flux.
+ Le premier `-e` argument définit la variable d'`AWS_CONTAINER_AUTHORIZATION_TOKEN`environnement requise dans le conteneur Docker.
+ Les `-e` arguments supplémentaires définissent les variables d'environnement utilisées dans cet exemple.
+ L'`-v`argument monte le [dossier de travail](component-recipe-reference.md#component-recipe-work-path) du composant dans le conteneur. Cet exemple crée un fichier dans le dossier de travail pour le télécharger sur Amazon S3 à l'aide du gestionnaire de flux.
+ L'`--rm`argument nettoie le conteneur à sa sortie.
```
{
"RecipeFormatVersion": "2020-01-25",
"ComponentName": "com.example.python.docker.StreamFileToS3",
"ComponentVersion": "1.0.0",
"ComponentDescription": "Creates a text file and uses stream manager to stream the file to S3.",
"ComponentPublisher": "Amazon",
"ComponentDependencies": {
"aws.greengrass.StreamManager": {
"VersionRequirement": "^2.0.0",
"DependencyType": "HARD"
}
},
"ComponentConfiguration": {
"DefaultConfiguration": {
"bucketName": ""
}
},
"Manifests": [
{
"Platform": {
"os": "linux"
},
"Lifecycle": {
"install": "docker load -i {artifacts:path}/stream-file-to-s3.tar",
"Run": "docker run --network=host -e AWS_CONTAINER_AUTHORIZATION_TOKEN -e BUCKET_NAME=\"{configuration:/bucketName}\" -e WORK_PATH=\"{work:path}\" -v {work:path}:{work:path} --rm stream-file-to-s3"
},
"Artifacts": [
{
"URI": "s3://amzn-s3-demo-bucket/artifacts/com.example.python.docker.StreamFileToS3/1.0.0/stream-file-to-s3.tar"
}
]
}
]
}
```
```
RecipeFormatVersion: '2020-01-25'
ComponentName: com.example.python.docker.StreamFileToS3
ComponentVersion: 1.0.0
ComponentDescription: Creates a text file and uses stream manager to stream the file to S3.
ComponentPublisher: Amazon
ComponentDependencies:
aws.greengrass.StreamManager:
VersionRequirement: ^2.0.0
DependencyType: HARD
ComponentConfiguration:
DefaultConfiguration:
bucketName: ''
Manifests:
- Platform:
os: linux
Lifecycle:
install: 'docker load -i {artifacts:path}/stream-file-to-s3.tar'
Run: |
docker run \
--network=host \
-e AWS_CONTAINER_AUTHORIZATION_TOKEN \
-e BUCKET_NAME="{configuration:/bucketName}" \
-e WORK_PATH="{work:path}" \
-v {work:path}:{work:path} \
--rm stream-file-to-s3
Artifacts:
- URI: s3://amzn-s3-demo-bucket/artifacts/com.example.python.docker.StreamFileToS3/1.0.0/stream-file-to-s3.tar
```
# AWS IoT Greengrass référence de recette de composant
La recette du composant est un fichier qui définit les détails, les dépendances, les artefacts et les cycles de vie d'un composant. Le *cycle* de vie du composant indique les commandes à exécuter pour installer, exécuter et arrêter le composant, par exemple. Le AWS IoT Greengrass noyau utilise les cycles de vie que vous définissez dans la recette pour installer et exécuter les composants. Le AWS IoT Greengrass service utilise la recette pour identifier les dépendances et les artefacts à déployer sur vos appareils principaux lorsque vous déployez le composant.
Dans la recette, vous pouvez définir des dépendances et des cycles de vie uniques pour chaque plate-forme prise en charge par un composant. Vous pouvez utiliser cette fonctionnalité pour déployer un composant sur des appareils dotés de plusieurs plateformes ayant des exigences différentes. Vous pouvez également l'utiliser pour AWS IoT Greengrass empêcher l'installation d'un composant sur des appareils qui ne le prennent pas en charge.
Chaque recette contient une liste de *manifestes*. Chaque manifeste spécifie un ensemble d'exigences relatives à la plate-forme, ainsi que le cycle de vie et les artefacts à utiliser pour les principaux appareils dont la plate-forme répond à ces exigences. Le périphérique principal utilise le premier manifeste avec les exigences de plate-forme auxquelles le périphérique répond. Spécifiez un manifeste sans aucune exigence de plate-forme pour correspondre à un périphérique principal.
Vous pouvez également spécifier un cycle de vie global qui ne figure pas dans un manifeste. Dans le cycle de vie global, vous pouvez utiliser des *clés de sélection* qui identifient les sous-sections du cycle de vie. Vous pouvez ensuite spécifier ces clés de sélection dans un manifeste afin d'utiliser ces sections du cycle de vie global en plus du cycle de vie du manifeste. Le périphérique principal utilise les clés de sélection du manifeste uniquement si le manifeste ne définit pas de cycle de vie. Vous pouvez utiliser la `all` sélection dans un manifeste pour faire correspondre des sections du cycle de vie global sans clé de sélection.
Une fois que le logiciel AWS IoT Greengrass Core a sélectionné un manifeste correspondant au périphérique principal, il procède comme suit pour identifier les étapes du cycle de vie à utiliser :
+ Si le manifeste sélectionné définit un cycle de vie, le périphérique principal utilise ce cycle de vie.
+ Si le manifeste sélectionné ne définit pas de cycle de vie, le périphérique principal utilise le cycle de vie global. Le dispositif principal effectue les opérations suivantes pour identifier les sections du cycle de vie global à utiliser :
+ Si le manifeste définit des clés de sélection, le périphérique principal utilise les sections du cycle de vie global qui contiennent les clés de sélection du manifeste.
+ Si le manifeste ne définit pas de clés de sélection, le périphérique principal utilise les sections du cycle de vie global qui ne comportent pas de clés de sélection. Ce comportement est équivalent à un manifeste qui définit la `all` sélection.
**Important**
Un périphérique principal doit répondre aux exigences de plate-forme d'au moins un manifeste pour installer le composant. Si aucun manifeste ne correspond au périphérique principal, le logiciel AWS IoT Greengrass Core n'installe pas le composant et le déploiement échoue.
Vous pouvez définir des recettes au format [JSON](https://en.wikipedia.org/wiki/JSON) ou [YAML.](https://en.wikipedia.org/wiki/YAML) La section des exemples de recettes inclut des recettes dans chaque format.
**Topics**
+ [Validation des recettes](#recipe-validation)
+ [Format de recette](#recipe-format)
+ [Variables de recette](#recipe-variables)
+ [Exemples de recettes](#recipe-examples)
## Validation des recettes
Greengrass valide une recette de composant JSON ou YAML lors de la création d'une version de composant. Cette validation de recette vérifie la présence d'erreurs courantes dans la recette de votre composant JSON ou YAML afin d'éviter d'éventuels problèmes de déploiement. La validation vérifie la recette pour détecter les erreurs courantes (par exemple, les virgules, les accolades et les champs manquants) et pour s'assurer que la recette est bien formée.
Si vous recevez un message d'erreur de validation de recette, vérifiez qu'il n'y a pas de virgules, d'accolades ou de champs manquants dans votre recette. Vérifiez qu'aucun champ ne vous manque en examinant le [format de la recette](#recipe-format).
## Format de recette
Lorsque vous définissez une recette pour un composant, vous spécifiez les informations suivantes dans le document de recette. La même structure s'applique aux recettes aux formats YAML et JSON.
`RecipeFormatVersion`
Version du modèle pour la recette. Choisissez l'option suivante :
+ `2020-01-25`
`ComponentName`
Nom du composant défini par cette recette. Le nom du composant doit être unique Compte AWS dans votre région.
**Conseils**
+ Utilisez le format de nom de domaine inverse pour éviter les collisions de noms au sein de votre entreprise. Par exemple, si votre entreprise possède un projet d'énergie solaire `example.com` et que vous y travaillez, vous pouvez donner un nom à votre composant Hello World`com.example.solar.HelloWorld`. Cela permet d'éviter les collisions de noms de composants au sein de votre entreprise.
+ Évitez le `aws.greengrass` préfixe dans les noms de vos composants. AWS IoT Greengrass utilise ce préfixe pour les [composants publics](public-components.md) qu'il fournit. Si vous choisissez le même nom qu'un composant public, celui-ci le remplace. AWS IoT Greengrass Fournit ensuite votre composant au lieu du composant public lorsqu'il déploie des composants dépendants de ce composant public. Cette fonctionnalité vous permet de modifier le comportement des composants publics, mais elle peut également endommager d'autres composants si vous n'avez pas l'intention de remplacer un composant public.
`ComponentVersion`
Version du composant. La valeur maximale pour les valeurs majeures, mineures et patchs est de 999999.
AWS IoT Greengrass utilise des versions sémantiques pour les composants. Les versions sémantiques suivent une *majeure*. *mineur*. système de numéro de *patch*. Par exemple, la version `1.0.0` représente la première version majeure d'un composant. Pour plus d'informations, consultez la [spécification de version sémantique](https://semver.org/).
`ComponentDescription`
(Facultatif) Description du composant.
`ComponentPublisher`
L'éditeur ou l'auteur du composant.
`ComponentConfiguration`
(Facultatif) Objet qui définit la configuration ou les paramètres du composant. Vous définissez la configuration par défaut, puis lorsque vous déployez le composant, vous pouvez spécifier l'objet de configuration à fournir au composant. La configuration des composants prend en charge les paramètres et les structures imbriqués. Cet objet contient les informations suivantes :
`DefaultConfiguration`
Objet qui définit la configuration par défaut du composant. Vous définissez la structure de cet objet.
AWS IoT Greengrass utilise JSON pour les valeurs de configuration. Le JSON spécifie un type de nombre mais ne fait pas la différence entre les nombres entiers et les nombres flottants. Par conséquent, les valeurs de configuration peuvent être converties en valeurs flottantes. AWS IoT Greengrass Pour garantir que votre composant utilise le type de données approprié, nous vous recommandons de définir les valeurs de configuration numériques sous forme de chaînes. Ensuite, demandez à votre composant de les analyser sous forme de nombres entiers ou de nombres flottants. Cela garantit que vos valeurs de configuration sont du même type dans la configuration et sur votre appareil principal.
`ComponentDependencies`
(Facultatif) Un dictionnaire d'objets qui définissent chacun une dépendance de composant pour le composant. La clé de chaque objet identifie le nom de la dépendance du composant. AWS IoT Greengrass installe les dépendances des composants lors de l'installation du composant. AWS IoT Greengrass attend le début des dépendances avant de démarrer le composant. Chaque objet contient les informations suivantes :
`VersionRequirement`
La contrainte de version sémantique de style npm qui définit les versions de composants compatibles pour cette dépendance. Vous pouvez spécifier une version ou une plage de versions. Pour plus d'informations, consultez le calculateur de [version sémantique npm](https://semver.npmjs.com/).
`DependencyType`
(Facultatif) Type de cette dépendance. Choisissez parmi les options suivantes.
+ `SOFT` – Le composant ne redémarre pas si la dépendance change d'état.
+ `HARD` – Le composant redémarre si la dépendance change d'état.
La valeur par défaut est `HARD` .
`ComponentType`
(Facultatif) Type de composant.
Il est déconseillé de spécifier le type de composant dans une recette. AWS IoT Greengrass définit le type pour vous lorsque vous créez un composant.
Il peut s'agir de l'un des types suivants :
+ `aws.greengrass.generic`— Le composant exécute des commandes ou fournit des artefacts.
+ `aws.greengrass.lambda`— Le composant exécute une fonction Lambda à l'aide du composant [Lambda](lambda-launcher-component.md) Launcher. Le `ComponentSource` paramètre spécifie l'ARN de la fonction Lambda exécutée par ce composant.
Nous vous déconseillons d'utiliser cette option, car elle est définie AWS IoT Greengrass lorsque vous créez un composant à partir d'une fonction Lambda. Pour de plus amples informations, veuillez consulter [Exécuter AWS Lambda des fonctions](run-lambda-functions.md).
+ `aws.greengrass.plugin`— Le composant s'exécute dans la même machine virtuelle Java (JVM) que le noyau Greengrass. Si vous déployez ou redémarrez un composant du plugin, le noyau Greengrass redémarre.
Les composants du plugin utilisent le même fichier journal que le noyau Greengrass. Pour de plus amples informations, veuillez consulter [AWS IoT Greengrass Journaux de surveillance](monitor-logs.md).
Nous vous déconseillons d'utiliser cette option dans les recettes de composants, car elle est destinée aux composants AWS fournis écrits en Java qui s'interfacent directement avec le noyau de Greengrass. Pour plus d'informations sur les composants publics qui sont des plug-ins, consultez[AWS-composants fournis](public-components.md).
+ `aws.greengrass.nucleus`— Le composant du noyau. Pour de plus amples informations, veuillez consulter [Noyau de Greengrass](greengrass-nucleus-component.md).
Nous vous déconseillons d'utiliser cette option dans les recettes de composants. Il est destiné au composant Greengrass nucleus, qui fournit les fonctionnalités minimales du logiciel AWS IoT Greengrass Core.
La valeur par défaut `aws.greengrass.generic` est lorsque vous créez un composant à partir d'une recette ou `aws.greengrass.lambda` lorsque vous créez un composant à partir d'une fonction Lambda.
Pour de plus amples informations, veuillez consulter [Types de composants](develop-greengrass-components.md#component-types).
`ComponentSource`
(Facultatif) L'ARN de la fonction Lambda exécutée par un composant.
Il est déconseillé de spécifier la source du composant dans une recette. AWS IoT Greengrass définit ce paramètre pour vous lorsque vous créez un composant à partir d'une fonction Lambda. Pour de plus amples informations, veuillez consulter [Exécuter AWS Lambda des fonctions](run-lambda-functions.md).
`Manifests`
Liste d'objets qui définissent chacun le cycle de vie, les paramètres et les exigences d'un composant pour une plate-forme. Si un périphérique principal répond aux exigences de plate-forme de plusieurs manifestes, AWS IoT Greengrass utilise le premier manifeste correspondant au périphérique principal. Pour garantir que les appareils principaux utilisent le bon manifeste, définissez d'abord les manifestes avec des exigences de plate-forme plus strictes. Un manifeste qui s'applique à toutes les plateformes doit être le dernier manifeste de la liste.
Un périphérique principal doit répondre aux exigences de plate-forme d'au moins un manifeste pour installer le composant. Si aucun manifeste ne correspond au périphérique principal, le logiciel AWS IoT Greengrass Core n'installe pas le composant et le déploiement échoue.
Chaque objet contient les informations suivantes :
`Name`
(Facultatif) Nom convivial pour la plate-forme définie dans ce manifeste.
Si vous omettez ce paramètre, AWS IoT Greengrass crée un nom à partir de la plateforme `os` et`architecture`.
`Platform`
(Facultatif) Objet qui définit la plate-forme à laquelle s'applique ce manifeste. Omettez ce paramètre pour définir un manifeste qui s'applique à toutes les plateformes.
Cet objet spécifie les paires clé-valeur relatives à la plate-forme sur laquelle un périphérique principal s'exécute. Lorsque vous déployez ce composant, le logiciel AWS IoT Greengrass Core compare ces paires clé-valeur avec les attributs de plate-forme du périphérique principal. Le logiciel de AWS IoT Greengrass base définit toujours `os` et`architecture`, et il peut définir des attributs supplémentaires. Vous pouvez spécifier des attributs de plate-forme personnalisés pour un appareil principal lorsque vous déployez le composant Greengrass nucleus. Pour plus d'informations, consultez le [paramètre Platform overrides](greengrass-nucleus-component.md#greengrass-nucleus-component-configuration-platform-overrides) du composant [Greengrass nucleus](greengrass-nucleus-component.md).
Pour chaque paire clé-valeur, vous pouvez spécifier l'une des valeurs suivantes :
+ Une valeur exacte, telle que `linux` ou`windows`. Les valeurs exactes doivent commencer par une lettre ou un chiffre.
+ `*`, qui correspond à n'importe quelle valeur. Cela correspond également lorsqu'une valeur n'est pas présente.
+ Une expression régulière de style Java, telle que. `/windows|linux/` L'expression régulière doit commencer et se terminer par une barre oblique (`/`). Par exemple, l'expression régulière `/.+/` correspond à toute valeur non vide.
Cet objet contient les informations suivantes :
`runtime`
Le [runtime Greengrass Nucleus](https://docs.aws.amazon.com/greengrass/v2/developerguide/how-it-works.html#concept-overview) pour la plate-forme prise en charge par ce manifeste. Lors de la définition de plusieurs manifestes avec la plateforme`runtime`, les valeurs d'exécution prises en charge dans une recette sont `aws_nucleus_lite` et `*` uniquement. Pour cibler un appareil classique, le champ d'exécution NE DOIT PAS être spécifié dans la recette. Les environnements d'exécution Greengrass Nucleus pris en charge incluent les valeurs suivantes :
+ `*`
+ `aws_nucleus_lite`
`os`
(Facultatif) Nom du système d'exploitation de la plate-forme prise en charge par ce manifeste. Les plateformes courantes incluent les valeurs suivantes :
+ `linux`
+ `windows`
+ `darwin` (macOS)
`architecture`
(Facultatif) Architecture du processeur de la plate-forme prise en charge par ce manifeste. Les architectures courantes incluent les valeurs suivantes :
+ `amd64`
+ `arm`
+ `aarch64`
+ `x86`
`architecture.detail`
(Facultatif) Détail de l'architecture du processeur pour la plate-forme prise en charge par ce manifeste. Les détails courants de l'architecture incluent les valeurs suivantes :
+ `arm61`
+ `arm71`
+ `arm81`
`key`
(Facultatif) Attribut de plateforme que vous définissez pour ce manifeste. Remplacez *Key* par le nom de l'attribut de plateforme. Le logiciel AWS IoT Greengrass Core associe cet attribut de plate-forme aux paires clé-valeur que vous spécifiez dans la configuration des composants du noyau Greengrass. Pour plus d'informations, consultez le [paramètre Platform overrides](greengrass-nucleus-component.md#greengrass-nucleus-component-configuration-platform-overrides) du composant [Greengrass nucleus](greengrass-nucleus-component.md).
Utilisez le format de nom de domaine inverse pour éviter les collisions de noms au sein de votre entreprise. Par exemple, si votre entreprise possède un projet radio `example.com` et que vous y travaillez, vous pouvez nommer un attribut de plateforme personnalisé`com.example.radio.RadioModule`. Cela permet d'éviter les collisions entre les noms d'attributs de plateforme au sein de votre entreprise.
Par exemple, vous pouvez définir un attribut de plate-forme pour spécifier un manifeste différent en fonction du module radio disponible sur un périphérique principal. `com.example.radio.RadioModule` Chaque manifeste peut inclure différents artefacts qui s'appliquent à différentes configurations matérielles, afin que vous puissiez déployer l'ensemble minimal de logiciels sur le périphérique principal.
`Lifecycle`
Objet ou chaîne qui définit comment installer et exécuter le composant sur la plate-forme définie par ce manifeste. Vous pouvez également définir un [cycle de vie global](#global-lifecycle-definition) qui s'applique à toutes les plateformes. Le périphérique principal utilise le cycle de vie global uniquement si le manifeste à utiliser ne spécifie pas de cycle de vie.
Vous définissez ce cycle de vie dans un manifeste. Les étapes du cycle de vie que vous spécifiez ici s'appliquent uniquement à la plate-forme définie par ce manifeste. Vous pouvez également définir un [cycle de vie global](#global-lifecycle-definition) qui s'applique à toutes les plateformes.
Cet objet ou cette chaîne contient les informations suivantes :
`Setenv`
(Facultatif) Un dictionnaire de variables d'environnement à fournir à tous les scripts de cycle de vie. Vous pouvez remplacer ces variables d'environnement `Setenv` dans chaque script de cycle de vie.
`install`
(Facultatif) Objet ou chaîne qui définit le script à exécuter lors de l'installation du composant. Le logiciel de AWS IoT Greengrass base exécute également cette étape du cycle de vie à chaque lancement du logiciel.
Si le `install` script se termine avec un code de réussite, le composant passe à l'`INSTALLED`état.
Cet objet ou cette chaîne contient les informations suivantes :
`Script`
Le script à exécuter.
`RequiresPrivilege`
(Facultatif) Vous pouvez exécuter le script avec les privilèges root. Si vous définissez cette option sur`true`, le logiciel AWS IoT Greengrass Core exécute ce script de cycle de vie en tant qu'utilisateur root plutôt qu'en tant qu'utilisateur système que vous configurez pour exécuter ce composant. La valeur par défaut est `false` .
`Skipif`
(Facultatif) Vérification visant à déterminer s'il faut exécuter le script ou non. Vous pouvez définir pour vérifier si un exécutable se trouve sur le chemin ou si un fichier existe. Si le résultat est vrai, le logiciel AWS IoT Greengrass Core ignore l'étape. Choisissez l'une des vérifications suivantes :
+ `onpath runnable`— Vérifie si un exécutable se trouve sur le chemin du système. Par exemple, utilisez cette option **onpath python3** pour ignorer cette étape du cycle de vie si Python 3 est disponible.
+ `exists file`— Vérifie si un fichier existe. Par exemple, utilisez-le **exists /tmp/my-configuration.db** pour ignorer cette étape du cycle de vie si elle `/tmp/my-configuration.db` est présente.
`Timeout`
(Facultatif) Durée maximale en secondes pendant laquelle le script peut être exécuté avant que le logiciel AWS IoT Greengrass Core n'arrête le processus.
Par défaut : 120 secondes
`Setenv`
(Facultatif) Le dictionnaire des variables d'environnement à fournir au script. Ces variables d'environnement remplacent les variables que vous fournissez. `Lifecycle.Setenv`
`run`
(Facultatif) Objet ou chaîne qui définit le script à exécuter au démarrage du composant.
Le composant entre dans cet `RUNNING` état lors de l'exécution de cette étape du cycle de vie. Si le `run` script se termine avec un code de réussite, le composant passe à l'`STOPPING`état. Si un `shutdown` script est spécifié, il s'exécute ; dans le cas contraire, le composant passe à l'`FINISHED`état.
Les composants qui dépendent de ce composant démarrent lors de l'exécution de cette étape du cycle de vie. Pour exécuter un processus en arrière-plan, tel qu'un service utilisé par des composants dépendants, utilisez plutôt l'étape `startup` du cycle de vie.
Lorsque vous déployez des composants dotés d'un `run` cycle de vie, le périphérique principal peut signaler que le déploiement est terminé dès que ce script de cycle de vie s'exécute. Par conséquent, le déploiement peut être complet et réussi même si le script de `run` cycle de vie échoue peu après son exécution. Si vous souhaitez que l'état du déploiement dépende du résultat du script de démarrage du composant, utilisez plutôt l'étape `startup` du cycle de vie.
Vous ne pouvez en définir qu'un `startup` ou un `run` cycle de vie.
Cet objet ou cette chaîne contient les informations suivantes :
`Script`
Le script à exécuter.
`RequiresPrivilege`
(Facultatif) Vous pouvez exécuter le script avec les privilèges root. Si vous définissez cette option sur`true`, le logiciel AWS IoT Greengrass Core exécute ce script de cycle de vie en tant qu'utilisateur root plutôt qu'en tant qu'utilisateur système que vous configurez pour exécuter ce composant. La valeur par défaut est `false` .
`Skipif`
(Facultatif) Vérification visant à déterminer s'il faut exécuter le script ou non. Vous pouvez définir pour vérifier si un exécutable se trouve sur le chemin ou si un fichier existe. Si le résultat est vrai, le logiciel AWS IoT Greengrass Core ignore l'étape. Choisissez l'une des vérifications suivantes :
+ `onpath runnable`— Vérifie si un exécutable se trouve sur le chemin du système. Par exemple, utilisez cette option **onpath python3** pour ignorer cette étape du cycle de vie si Python 3 est disponible.
+ `exists file`— Vérifie si un fichier existe. Par exemple, utilisez-le **exists /tmp/my-configuration.db** pour ignorer cette étape du cycle de vie si elle `/tmp/my-configuration.db` est présente.
`Timeout`
(Facultatif) Durée maximale en secondes pendant laquelle le script peut être exécuté avant que le logiciel AWS IoT Greengrass Core n'arrête le processus.
Cette étape du cycle de vie n'expire pas par défaut. Si vous omettez ce délai, le `run` script s'exécute jusqu'à sa fin.
`Setenv`
(Facultatif) Le dictionnaire des variables d'environnement à fournir au script. Ces variables d'environnement remplacent les variables que vous fournissez. `Lifecycle.Setenv`
`startup`
(Facultatif) Objet ou chaîne qui définit le processus d'arrière-plan à exécuter au démarrage du composant.
`startup`À utiliser pour exécuter une commande qui doit se terminer correctement ou mettre à jour l'état du composant pour `RUNNING` que les composants dépendants puissent démarrer. Utilisez l'opération [UpdateState](ipc-component-lifecycle.md#ipc-operation-updatestate)IPC pour définir l'état du composant sur `RUNNING` ou `ERRORED` quand le composant lance un script qui ne se ferme pas. Par exemple, vous pouvez définir une `startup` étape qui lance le processus MySQL par`/etc/init.d/mysqld start`.
Le composant entre dans cet `STARTING` état lors de l'exécution de cette étape du cycle de vie. Si le `startup` script se termine avec un code de réussite, le composant passe à l'`RUNNING`état. Les composants dépendants peuvent alors démarrer.
Lorsque vous déployez des composants dotés d'un `startup` cycle de vie, le périphérique principal peut signaler que le déploiement est terminé une fois que ce script de cycle de vie se termine ou indique son état. En d'autres termes, le déploiement se poursuit `IN_PROGRESS` jusqu'à ce que les scripts de démarrage de tous les composants quittent ou signalent un état.
Vous ne pouvez en définir qu'un `startup` ou un `run` cycle de vie.
Cet objet ou cette chaîne contient les informations suivantes :
`Script`
Le script à exécuter.
`RequiresPrivilege`
(Facultatif) Vous pouvez exécuter le script avec les privilèges root. Si vous définissez cette option sur`true`, le logiciel AWS IoT Greengrass Core exécute ce script de cycle de vie en tant qu'utilisateur root plutôt qu'en tant qu'utilisateur système que vous configurez pour exécuter ce composant. La valeur par défaut est `false` .
`Skipif`
(Facultatif) Vérification visant à déterminer s'il faut exécuter le script ou non. Vous pouvez définir pour vérifier si un exécutable se trouve sur le chemin ou si un fichier existe. Si le résultat est vrai, le logiciel AWS IoT Greengrass Core ignore l'étape. Choisissez l'une des vérifications suivantes :
+ `onpath runnable`— Vérifie si un exécutable se trouve sur le chemin du système. Par exemple, utilisez cette option **onpath python3** pour ignorer cette étape du cycle de vie si Python 3 est disponible.
+ `exists file`— Vérifie si un fichier existe. Par exemple, utilisez-le **exists /tmp/my-configuration.db** pour ignorer cette étape du cycle de vie si elle `/tmp/my-configuration.db` est présente.
`Timeout`
(Facultatif) Durée maximale en secondes pendant laquelle le script peut être exécuté avant que le logiciel AWS IoT Greengrass Core n'arrête le processus.
Par défaut : 120 secondes
`Setenv`
(Facultatif) Le dictionnaire des variables d'environnement à fournir au script. Ces variables d'environnement remplacent les variables que vous fournissez. `Lifecycle.Setenv`
`shutdown`
(Facultatif) Objet ou chaîne qui définit le script à exécuter lorsque le composant s'arrête. Utilisez le cycle de vie d'arrêt pour exécuter le code que vous souhaitez exécuter lorsque le composant est dans `STOPPING` cet état. Le cycle de vie d'arrêt peut être utilisé pour arrêter un processus lancé par les `run` scripts `startup` or.
Si vous lancez un processus en arrière-plan dans`startup`, utilisez l'`shutdown`étape pour arrêter ce processus lorsque le composant s'arrête. Par exemple, vous pouvez définir une `shutdown` étape qui arrête le processus MySQL avec`/etc/init.d/mysqld stop`.
Le `shutdown` script s'exécute une fois que le composant est entré dans l'`STOPPING`état. Si le script s'exécute correctement, le composant passe à l'`FINISHED`état.
Cet objet ou cette chaîne contient les informations suivantes :
`Script`
Le script à exécuter.
`RequiresPrivilege`
(Facultatif) Vous pouvez exécuter le script avec les privilèges root. Si vous définissez cette option sur`true`, le logiciel AWS IoT Greengrass Core exécute ce script de cycle de vie en tant qu'utilisateur root plutôt qu'en tant qu'utilisateur système que vous configurez pour exécuter ce composant. La valeur par défaut est `false` .
`Skipif`
(Facultatif) Vérification visant à déterminer s'il faut exécuter le script ou non. Vous pouvez définir pour vérifier si un exécutable se trouve sur le chemin ou si un fichier existe. Si le résultat est vrai, le logiciel AWS IoT Greengrass Core ignore l'étape. Choisissez l'une des vérifications suivantes :
+ `onpath runnable`— Vérifie si un exécutable se trouve sur le chemin du système. Par exemple, utilisez cette option **onpath python3** pour ignorer cette étape du cycle de vie si Python 3 est disponible.
+ `exists file`— Vérifie si un fichier existe. Par exemple, utilisez-le **exists /tmp/my-configuration.db** pour ignorer cette étape du cycle de vie si elle `/tmp/my-configuration.db` est présente.
`Timeout`
(Facultatif) Durée maximale en secondes pendant laquelle le script peut être exécuté avant que le logiciel AWS IoT Greengrass Core n'arrête le processus.
Par défaut : 15 secondes.
`Setenv`
(Facultatif) Le dictionnaire des variables d'environnement à fournir au script. Ces variables d'environnement remplacent les variables que vous fournissez. `Lifecycle.Setenv`
`recover`
(Facultatif) Objet ou chaîne qui définit le script à exécuter lorsque le composant rencontre une erreur.
Cette étape s'exécute lorsqu'un composant entre dans `ERRORED` cet état. Si le composant devient `ERRORED` trois fois sans restauration réussie, le composant passe à l'`BROKEN`état actuel. Pour réparer un `BROKEN` composant, vous devez le déployer à nouveau.
Cet objet ou cette chaîne contient les informations suivantes :
`Script`
Le script à exécuter.
`RequiresPrivilege`
(Facultatif) Vous pouvez exécuter le script avec les privilèges root. Si vous définissez cette option sur`true`, le logiciel AWS IoT Greengrass Core exécute ce script de cycle de vie en tant qu'utilisateur root plutôt qu'en tant qu'utilisateur système que vous configurez pour exécuter ce composant. La valeur par défaut est `false` .
`Skipif`
(Facultatif) Vérification visant à déterminer s'il faut exécuter le script ou non. Vous pouvez définir pour vérifier si un exécutable se trouve sur le chemin ou si un fichier existe. Si le résultat est vrai, le logiciel AWS IoT Greengrass Core ignore l'étape. Choisissez l'une des vérifications suivantes :
+ `onpath runnable`— Vérifie si un exécutable se trouve sur le chemin du système. Par exemple, utilisez cette option **onpath python3** pour ignorer cette étape du cycle de vie si Python 3 est disponible.
+ `exists file`— Vérifie si un fichier existe. Par exemple, utilisez-le **exists /tmp/my-configuration.db** pour ignorer cette étape du cycle de vie si elle `/tmp/my-configuration.db` est présente.
`Timeout`
(Facultatif) Durée maximale en secondes pendant laquelle le script peut être exécuté avant que le logiciel AWS IoT Greengrass Core n'arrête le processus.
Par défaut : 60 secondes.
`Setenv`
(Facultatif) Le dictionnaire des variables d'environnement à fournir au script. Ces variables d'environnement remplacent les variables que vous fournissez. `Lifecycle.Setenv`
`bootstrap`
(Facultatif) Objet ou chaîne qui définit un script nécessitant le AWS IoT Greengrass redémarrage du logiciel ou du périphérique principal. Cela vous permet de développer un composant qui redémarre après avoir installé des mises à jour du système d'exploitation ou des mises à jour d'exécution, par exemple.
Pour installer des mises à jour ou des dépendances qui ne nécessitent pas le redémarrage du logiciel ou de l'appareil AWS IoT Greengrass Core, utilisez le [cycle de vie d'installation](#install-lifecycle-definition).
Cette étape du cycle de vie s'exécute avant l'étape du cycle de vie d'installation dans les cas suivants lorsque le logiciel AWS IoT Greengrass Core déploie le composant :
+ Le composant est déployé sur le périphérique principal pour la première fois.
+ La version du composant change.
+ Le script bootstrap change à la suite d'une mise à jour de la configuration d'un composant.
Une fois que le logiciel AWS IoT Greengrass Core a terminé l'étape d'amorçage pour tous les composants dotés d'une étape d'amorçage lors d'un déploiement, le logiciel redémarre.
Vous devez configurer le logiciel AWS IoT Greengrass Core en tant que service système pour redémarrer le logiciel AWS IoT Greengrass Core ou le périphérique principal. Si vous ne configurez pas le logiciel AWS IoT Greengrass Core en tant que service système, le logiciel ne redémarrera pas. Pour de plus amples informations, veuillez consulter [Configurer le noyau Greengrass en tant que service système](configure-greengrass-core-v2.md#configure-system-service).
Cet objet ou cette chaîne contient les informations suivantes :
`BootstrapOnRollback`
Lorsque cette fonctionnalité est activée, elle ne `BootstrapOnRollback` s'exécute que pour les composants qui ont terminé ou tenté d'exécuter les étapes du cycle de vie du bootstrap dans le cadre d'un déploiement cible ayant échoué. Cette fonctionnalité est disponible pour les versions 2.12.0 et ultérieures de Greengrass nucleus.
(Facultatif) Vous pouvez exécuter les étapes du cycle de vie du bootstrap dans le cadre d'un déploiement rétroactif. Si vous définissez cette option sur`true`, les étapes du cycle de vie du bootstrap définies dans le cadre d'un déploiement de restauration seront exécutées. En cas d'échec d'un déploiement, la version précédente du cycle de vie d'amorçage du composant s'exécute à nouveau lors d'un déploiement rétroactif.
La valeur par défaut est `false` .
`Script`
Le script à exécuter. Le code de sortie de ce script définit l'instruction de redémarrage. Utilisez les codes de sortie suivants :
+ `0`— Ne redémarrez pas le logiciel AWS IoT Greengrass principal ou le périphérique principal. Le logiciel AWS IoT Greengrass Core redémarre toujours après le démarrage de tous les composants.
+ `100`— Demande de redémarrage du logiciel AWS IoT Greengrass Core.
+ `101`— Demande de redémarrage de l'appareil principal.
Les codes de sortie 100 à 199 sont réservés à un comportement spécial. Les autres codes de sortie représentent des erreurs de script.
`RequiresPrivilege`
(Facultatif) Vous pouvez exécuter le script avec les privilèges root. Si vous définissez cette option sur`true`, le logiciel AWS IoT Greengrass Core exécute ce script de cycle de vie en tant qu'utilisateur root plutôt qu'en tant qu'utilisateur système que vous configurez pour exécuter ce composant. La valeur par défaut est `false` .
`Timeout`
(Facultatif) Durée maximale en secondes pendant laquelle le script peut être exécuté avant que le logiciel AWS IoT Greengrass Core n'arrête le processus.
Par défaut : 120 secondes
`Setenv`
(Facultatif) Le dictionnaire des variables d'environnement à fournir au script. Ces variables d'environnement remplacent les variables que vous fournissez. `Lifecycle.Setenv`
`Selections`
(Facultatif) Liste de clés de sélection qui spécifient les sections du [cycle de vie global](#global-lifecycle-definition) à exécuter pour ce manifeste. Dans le cycle de vie global, vous pouvez définir les étapes du cycle de vie à l'aide de clés de sélection à n'importe quel niveau pour sélectionner des sous-sections du cycle de vie. Ensuite, le périphérique principal utilise les sections qui correspondent aux clés de sélection de ce manifeste. Pour plus d'informations, consultez les [exemples de cycle de vie global](#global-lifecycle-definition).
Le périphérique principal utilise les sélections du cycle de vie global uniquement si ce manifeste ne définit pas de cycle de vie.
Vous pouvez spécifier la clé `all` de sélection pour exécuter les sections du cycle de vie global dépourvues de clés de sélection.
`Artifacts`
(Facultatif) Liste d'objets qui définissent chacun un artefact binaire pour le composant de la plate-forme défini par ce manifeste. Par exemple, vous pouvez définir du code ou des images comme des artefacts.
Lorsque le composant est déployé, le logiciel AWS IoT Greengrass Core télécharge l'artefact dans un dossier du périphérique principal. Vous pouvez également définir les artefacts comme des fichiers d'archive que le logiciel extrait après les avoir téléchargés.
Vous pouvez utiliser [des variables de recette](#recipe-variables) pour obtenir les chemins d'accès aux dossiers dans lesquels les artefacts sont installés sur le périphérique principal.
+ Fichiers normaux — Utilisez la [variable de recette artifacts:path](#component-recipe-artifacts-path) pour obtenir le chemin d'accès au dossier contenant les artefacts. Par exemple, spécifiez `{artifacts:path}/my_script.py` dans une recette le chemin d'accès à un artefact contenant l'URI`s3://amzn-s3-demo-bucket/path/to/my_script.py`.
+ Archives extraites — Utilisez la [variable de recette Artifacts:DecompressedPath pour obtenir le chemin](#component-recipe-artifacts-decompressed-path) d'accès au dossier contenant les artefacts d'archive extraits. Le logiciel AWS IoT Greengrass Core extrait chaque archive dans un dossier portant le même nom que l'archive. Par exemple, spécifiez `{artifacts:decompressedPath}/my_archive/my_script.py` dans une recette le chemin d'accès `my_script.py` à l'artefact d'archive contenant l'URI`s3://amzn-s3-demo-bucket/path/to/my_archive.zip`.
Lorsque vous développez un composant avec un artefact d'archive sur un périphérique principal local, il se peut que vous ne disposiez pas d'URI pour cet artefact. Pour tester votre composant avec une `Unarchive` option qui extrait l'artefact, spécifiez une URI dans laquelle le nom du fichier correspond au nom de votre fichier d'artefact d'archive. Vous pouvez spécifier l'URI dans lequel vous comptez télécharger l'artefact d'archive, ou vous pouvez spécifier un nouvel URI réservé. Par exemple, pour extraire l'`my_archive.zip`artefact lors d'un déploiement local, vous pouvez spécifier`s3://amzn-s3-demo-bucket/my_archive.zip`.
Chaque objet contient les informations suivantes :
`Uri`
L'URI d'un artefact dans un compartiment S3. Le logiciel AWS IoT Greengrass Core extrait l'artefact à partir de cet URI lors de l'installation du composant, sauf si l'artefact existe déjà sur le périphérique. Chaque artefact doit avoir un nom de fichier unique dans chaque manifeste.
`Unarchive`
(Facultatif) Type d'archive à décompresser. Sélectionnez l’une des options suivantes :
+ `NONE`— Le fichier n'est pas une archive à décompresser. Le logiciel AWS IoT Greengrass Core installe l'artefact dans un dossier du périphérique principal. Vous pouvez utiliser la [variable de recette artifacts:path](#component-recipe-artifacts-path) pour obtenir le chemin d'accès à ce dossier.
+ `ZIP`— Le fichier est une archive ZIP. Le logiciel AWS IoT Greengrass Core extrait l'archive dans un dossier portant le même nom que l'archive. Vous pouvez utiliser la [variable de recette Artifacts:DecompressedPath pour obtenir le chemin](#component-recipe-artifacts-decompressed-path) d'accès au dossier qui contient ce dossier.
La valeur par défaut est `NONE` .
`Permission`
(Facultatif) Objet qui définit les autorisations d'accès à définir pour ce fichier d'artefact. Vous pouvez définir l'autorisation de lecture et l'autorisation d'exécution.
Vous ne pouvez pas définir l'autorisation d'écriture, car le logiciel AWS IoT Greengrass Core n'autorise pas les composants à modifier les fichiers d'artefacts dans le dossier d'artefacts. Pour modifier un fichier d'artefact dans un composant, copiez-le dans un autre emplacement ou publiez et déployez un nouveau fichier d'artefact.
Si vous définissez un artefact comme une archive à décompresser, le logiciel AWS IoT Greengrass Core définit ces autorisations d'accès sur les fichiers qu'il décompresse de l'archive. Le logiciel AWS IoT Greengrass Core définit les autorisations d'accès au dossier sur `ALL` for `Read` et`Execute`. Cela permet aux composants de visualiser les fichiers décompressés dans le dossier. Pour définir des autorisations sur des fichiers individuels de l'archive, vous pouvez définir les autorisations dans le [script du cycle de vie d'installation](#install-lifecycle-definition).
Cet objet contient les informations suivantes :
`Read`
(Facultatif) L'autorisation de lecture à définir pour ce fichier d'artefact. Pour autoriser d'autres composants à accéder à cet artefact, tels que les composants qui dépendent de ce composant, spécifiez`ALL`. Sélectionnez l’une des options suivantes :
+ `NONE`— Le fichier n'est pas lisible.
+ `OWNER`— Le fichier est lisible par l'utilisateur du système que vous configurez pour exécuter ce composant.
+ `ALL`— Le fichier est lisible par tous les utilisateurs.
La valeur par défaut est `OWNER` .
`Execute`
(Facultatif) L'autorisation d'exécution à définir pour ce fichier d'artefact. L'`Execute`autorisation implique l'`Read`autorisation. Par exemple, si vous spécifiez `ALL` pour`Execute`, tous les utilisateurs peuvent lire et exécuter ce fichier d'artefact.
Sélectionnez l’une des options suivantes :
+ `NONE`— Le fichier n'est pas exécutable.
+ `OWNER`— Le fichier peut être exécuté par l'utilisateur du système que vous configurez pour exécuter le composant.
+ `ALL`— Le fichier est exécutable par tous les utilisateurs.
La valeur par défaut est `NONE` .
`Digest`
(Lecture seule) Le hachage du condensé cryptographique de l'artefact. Lorsque vous créez un composant, il AWS IoT Greengrass utilise un algorithme de hachage pour calculer le hachage du fichier d'artefact. Ensuite, lorsque vous déployez le composant, le noyau Greengrass calcule le hachage de l'artefact téléchargé et compare le hachage avec ce condensé pour vérifier l'artefact avant l'installation. Si le hachage ne correspond pas au résumé, le déploiement échoue.
Si vous définissez ce paramètre, il AWS IoT Greengrass remplace la valeur que vous avez définie lors de la création du composant.
`Algorithm`
(Lecture seule) Algorithme de hachage AWS IoT Greengrass utilisé pour calculer le hachage condensé de l'artefact.
Si vous définissez ce paramètre, il AWS IoT Greengrass remplace la valeur que vous avez définie lors de la création du composant.
`Lifecycle`
Objet qui définit le mode d'installation et d'exécution du composant. Le périphérique principal utilise le cycle de vie global uniquement si le [manifeste](#manifest-definition) à utiliser ne spécifie pas de cycle de vie.
Vous définissez ce cycle de vie en dehors d'un manifeste. Vous pouvez également définir un [cycle de vie du manifeste](#manifest-lifecycle-definition) qui s'applique aux plateformes correspondant à ce manifeste.
Dans le cycle de vie global, vous pouvez spécifier les cycles de vie qui s'exécutent pour certaines [clés de sélection](#manifest-selections-definition) que vous spécifiez dans chaque manifeste. Les clés de sélection sont des chaînes qui identifient les sections du cycle de vie global à exécuter pour chaque manifeste.
La clé `all` de sélection est la valeur par défaut pour toutes les sections sans clé de sélection. Cela signifie que vous pouvez spécifier la clé de `all` sélection dans un manifeste pour exécuter les sections du cycle de vie global sans clés de sélection. Il n'est pas nécessaire de spécifier la clé `all` de sélection dans le cycle de vie global.
Si un manifeste ne définit pas de cycle de vie ou de clés de sélection, le périphérique principal utilise par défaut la `all` sélection. Cela signifie que dans ce cas, le périphérique principal utilise les sections du cycle de vie global qui n'utilisent pas de touches de sélection.
Cet objet contient les mêmes informations que le [cycle de vie du manifeste](#manifest-lifecycle-definition), mais vous pouvez spécifier des clés de sélection à n'importe quel niveau pour sélectionner des sous-sections du cycle de vie.
Nous vous recommandons de n'utiliser que des lettres minuscules pour chaque clé de sélection afin d'éviter les conflits entre les clés de sélection et les clés de cycle de vie. Les clés du cycle de vie commencent par une majuscule.
**Example Exemple de cycle de vie global avec des clés de sélection de haut niveau**
```
Lifecycle:
key1:
install:
SkipIf: either onpath executable or exists file
Script: command1
key2:
install:
Script: command2
all:
install:
Script: command3
```
**Example Exemple de cycle de vie global avec des clés de sélection de bas niveau**
```
Lifecycle:
install:
Script:
key1: command1
key2: command2
all: command3
```
**Example Exemple de cycle de vie global avec plusieurs niveaux de clés de sélection**
```
Lifecycle:
key1:
install:
SkipIf: either onpath executable or exists file
Script: command1
key2:
install:
Script: command2
all:
install:
Script:
key3: command3
key4: command4
all: command5
```
## Variables de recette
Les variables de recette exposent les informations du composant et du noyau actuels que vous pouvez utiliser dans vos recettes. Par exemple, vous pouvez utiliser une variable de recette pour transmettre les paramètres de configuration des composants à une application que vous exécutez dans un script de cycle de vie.
Vous pouvez utiliser des variables de recette dans les sections suivantes des recettes de composants :
+ Définitions du cycle de vie.
+ Définitions de configuration des composants, si vous utilisez [Greengrass nucleus](greengrass-nucleus-component.md) v2.6.0 ou version ultérieure et que vous définissez l'[interpolateComponentConfiguration](greengrass-nucleus-component.md#greengrass-nucleus-component-configuration-interpolate-component-configuration)option de configuration sur. `true` Vous pouvez également utiliser des variables de recettes lorsque vous [déployez des mises à jour de configuration de composants](update-component-configurations.md#merge-configuration-update-recipe-variables).
Les variables de recette utilisent `{recipe_variable}` la syntaxe. Les bretelles frisées indiquent une variable de recette.
AWS IoT Greengrass prend en charge les variables de recette suivantes :
`component_dependency_name:configuration:json_pointer`
La valeur d'un paramètre de configuration pour le composant défini par cette recette ou pour un composant dont dépend ce composant.
Vous pouvez utiliser cette variable pour fournir un paramètre à un script que vous exécutez pendant le cycle de vie du composant.
AWS IoT Greengrass prend en charge cette variable de recette uniquement dans les définitions du cycle de vie des composants.
Cette variable de recette contient les entrées suivantes :
+ `component_dependency_name`— (Facultatif) Nom de la dépendance du composant à interroger. Omettez ce segment pour interroger le composant défini par cette recette. Vous ne pouvez spécifier que des dépendances directes.
+ `json_pointer`— Le pointeur JSON vers la valeur de configuration à évaluer. Les pointeurs JSON commencent par une barre oblique`/`. Pour identifier une valeur dans une configuration de composants imbriqués, utilisez des barres obliques (`/`) pour séparer les clés de chaque niveau de la configuration. Vous pouvez utiliser un nombre comme clé pour spécifier un index dans une liste. Pour plus d'informations, consultez la [spécification du pointeur JSON](https://tools.ietf.org/html/rfc6901).
AWS IoT Greengrass Core utilise des pointeurs JSON pour les recettes au format YAML.
Le pointeur JSON peut faire référence aux types de nœuds suivants :
+ Un nœud de valeur. AWS IoT Greengrass Core remplace la variable de recette par la représentation sous forme de chaîne de la valeur. Les valeurs nulles sont converties `null` en chaîne.
+ Un nœud d'objet. AWS IoT Greengrass Core remplace la variable de recette par la représentation sous forme de chaîne JSON sérialisée de cet objet.
+ Pas de nœud. AWS IoT Greengrass Core ne remplace pas la variable de recette.
Par exemple, la variable de `{configuration:/Message}` recette récupère la valeur de la `Message` clé dans la configuration du composant. La variable de `{com.example.MyComponentDependency:configuration:/server/port}` recette récupère la valeur de `port` dans l'objet de `server` configuration d'une dépendance de composant.
`component_dependency_name:artifacts:path`
Le chemin racine des artefacts pour le composant défini par cette recette ou pour un composant dont dépend ce composant.
Lors de l'installation d'un composant, AWS IoT Greengrass copie les artefacts du composant dans le dossier exposé par cette variable. Vous pouvez utiliser cette variable pour identifier l'emplacement d'un script à exécuter dans le cycle de vie du composant, par exemple.
Le dossier situé sur ce chemin est en lecture seule. Pour modifier les fichiers d'artefacts, copiez-les vers un autre emplacement, tel que le répertoire de travail actuel (`$PWD`ou`.`). Modifiez ensuite les fichiers qui s'y trouvent.
Pour lire ou exécuter un artefact à partir d'une dépendance à un composant, l'artefact `Read` ou l'`Execute`autorisation de cet artefact doivent être. `ALL` Pour plus d'informations, consultez les [autorisations d'artefact](#component-artifact-permission) que vous définissez dans la recette du composant.
Cette variable de recette contient les entrées suivantes :
+ `component_dependency_name`— (Facultatif) Nom de la dépendance du composant à interroger. Omettez ce segment pour interroger le composant défini par cette recette. Vous ne pouvez spécifier que des dépendances directes.
`component_dependency_name:artifacts:decompressedPath`
Le chemin racine des artefacts d'archive décompressés pour le composant défini par cette recette ou pour un composant dont dépend ce composant.
Lors de l'installation d'un composant, il AWS IoT Greengrass décompresse les artefacts d'archive du composant dans le dossier exposé par cette variable. Vous pouvez utiliser cette variable pour identifier l'emplacement d'un script à exécuter dans le cycle de vie du composant, par exemple.
Chaque artefact est décompressé dans un dossier situé dans le chemin décompressé, dans lequel le dossier porte le même nom que l'artefact, sauf son extension. Par exemple, un artefact ZIP nommé est `models.zip` décompressé dans le `{artifacts:decompressedPath}/models` dossier.
Le dossier situé sur ce chemin est en lecture seule. Pour modifier les fichiers d'artefacts, copiez-les vers un autre emplacement, tel que le répertoire de travail actuel (`$PWD`ou`.`). Modifiez ensuite les fichiers qui s'y trouvent.
Pour lire ou exécuter un artefact à partir d'une dépendance à un composant, l'artefact `Read` ou l'`Execute`autorisation de cet artefact doivent être. `ALL` Pour plus d'informations, consultez les [autorisations d'artefact](#component-artifact-permission) que vous définissez dans la recette du composant.
Cette variable de recette contient les entrées suivantes :
+ `component_dependency_name`— (Facultatif) Nom de la dépendance du composant à interroger. Omettez ce segment pour interroger le composant défini par cette recette. Vous ne pouvez spécifier que des dépendances directes.
`component_dependency_name:work:path`
Cette fonctionnalité est disponible pour les versions 2.0.4 et ultérieures du composant [Greengrass](greengrass-nucleus-component.md) nucleus.
Le chemin de travail pour le composant défini par cette recette ou pour un composant dont dépend ce composant. La valeur de cette variable de recette est équivalente à la sortie de la variable d'`$PWD`environnement et de la commande [pwd](https://en.wikipedia.org/wiki/Pwd) lorsqu'elle est exécutée depuis le contexte du composant.
Vous pouvez utiliser cette variable de recette pour partager des fichiers entre un composant et une dépendance.
Le dossier situé sur ce chemin est lisible et inscriptible par le composant défini par cette recette et par d'autres composants exécutés sous le même nom d'utilisateur et de même groupe.
Cette variable de recette contient les entrées suivantes :
+ `component_dependency_name`— (Facultatif) Nom de la dépendance du composant à interroger. Omettez ce segment pour interroger le composant défini par cette recette. Vous ne pouvez spécifier que des dépendances directes.
`kernel:rootPath`
Le chemin racine AWS IoT Greengrass principal.
`iot:thingName`
Cette fonctionnalité est disponible pour les versions 2.3.0 et ultérieures du composant [Greengrass](greengrass-nucleus-component.md) nucleus.
Le nom de l'appareil AWS IoT principal.
## Exemples de recettes
Vous pouvez consulter les exemples de recettes suivants pour vous aider à créer des recettes pour vos composants.
AWS IoT Greengrass organise un index des composants de Greengrass, appelé Greengrass Software Catalog. Ce catalogue suit les composants de Greengrass développés par la communauté Greengrass. À partir de ce catalogue, vous pouvez télécharger, modifier et déployer des composants pour créer vos applications Greengrass. Pour de plus amples informations, veuillez consulter [Composantes communautaires](greengrass-software-catalog.md).
**Topics**
+ [Recette du composant Hello World](#recipe-example-hello-world)
+ [Exemple de composant d'exécution Python](#recipe-example-python-runtime)
+ [Recette de composant qui spécifie plusieurs champs](#recipe-example-all-fields)
### Recette du composant Hello World
La recette suivante décrit un composant Hello World qui exécute un script Python. Ce composant prend en charge toutes les plateformes et accepte un `Message` paramètre AWS IoT Greengrass qui est transmis en tant qu'argument au script Python. Voici la recette du composant Hello World du [didacticiel de démarrage](getting-started.md).
------
#### [ JSON ]
```
{
"RecipeFormatVersion": "2020-01-25",
"ComponentName": "com.example.HelloWorld",
"ComponentVersion": "1.0.0",
"ComponentDescription": "My first AWS IoT Greengrass component.",
"ComponentPublisher": "Amazon",
"ComponentConfiguration": {
"DefaultConfiguration": {
"Message": "world"
}
},
"Manifests": [
{
"Platform": {
"os": "linux"
},
"Lifecycle": {
"run": "python3 -u {artifacts:path}/hello_world.py {configuration:/Message}"
}
},
{
"Platform": {
"os": "windows"
},
"Lifecycle": {
"run": "py -3 -u {artifacts:path}/hello_world.py {configuration:/Message}"
}
}
]
}
```
------
#### [ YAML ]
```
---
RecipeFormatVersion: '2020-01-25'
ComponentName: com.example.HelloWorld
ComponentVersion: '1.0.0'
ComponentDescription: My first AWS IoT Greengrass component.
ComponentPublisher: Amazon
ComponentConfiguration:
DefaultConfiguration:
Message: world
Manifests:
- Platform:
os: linux
Lifecycle:
run: |
python3 -u {artifacts:path}/hello_world.py "{configuration:/Message}"
- Platform:
os: windows
Lifecycle:
run: |
py -3 -u {artifacts:path}/hello_world.py "{configuration:/Message}"
```
------
### Exemple de composant d'exécution Python
La recette suivante décrit un composant qui installe Python. Ce composant prend en charge les appareils Linux 64 bits.
------
#### [ JSON ]
```
{
"RecipeFormatVersion": "2020-01-25",
"ComponentName": "com.example.PythonRuntime",
"ComponentDescription": "Installs Python 3.7",
"ComponentPublisher": "Amazon",
"ComponentVersion": "3.7.0",
"Manifests": [
{
"Platform": {
"os": "linux",
"architecture": "amd64"
},
"Lifecycle": {
"install": "apt-get update\napt-get install python3.7"
}
}
]
}
```
------
#### [ YAML ]
```
---
RecipeFormatVersion: '2020-01-25'
ComponentName: com.example.PythonRuntime
ComponentDescription: Installs Python 3.7
ComponentPublisher: Amazon
ComponentVersion: '3.7.0'
Manifests:
- Platform:
os: linux
architecture: amd64
Lifecycle:
install: |
apt-get update
apt-get install python3.7
```
------
### Recette de composant qui spécifie plusieurs champs
La recette de composant suivante utilise plusieurs champs de recette.
------
#### [ JSON ]
```
{
"RecipeFormatVersion": "2020-01-25",
"ComponentName": "com.example.FooService",
"ComponentDescription": "Complete recipe for AWS IoT Greengrass components",
"ComponentPublisher": "Amazon",
"ComponentVersion": "1.0.0",
"ComponentConfiguration": {
"DefaultConfiguration": {
"TestParam": "TestValue"
}
},
"ComponentDependencies": {
"BarService": {
"VersionRequirement": "^1.1.0",
"DependencyType": "SOFT"
},
"BazService": {
"VersionRequirement": "^2.0.0"
}
},
"Manifests": [
{
"Platform": {
"os": "linux",
"architecture": "amd64"
},
"Lifecycle": {
"install": {
"Skipif": "onpath git",
"Script": "sudo apt-get install git"
},
"Setenv": {
"environment_variable1": "variable_value1",
"environment_variable2": "variable_value2"
}
},
"Artifacts": [
{
"Uri": "s3://amzn-s3-demo-bucket/hello_world.zip",
"Unarchive": "ZIP"
},
{
"Uri": "s3://amzn-s3-demo-bucket/hello_world_linux.py"
}
]
},
{
"Lifecycle": {
"install": {
"Skipif": "onpath git",
"Script": "sudo apt-get install git",
"RequiresPrivilege": "true"
}
},
"Artifacts": [
{
"Uri": "s3://amzn-s3-demo-bucket/hello_world.py"
}
]
}
]
}
```
------
#### [ YAML ]
```
---
RecipeFormatVersion: '2020-01-25'
ComponentName: com.example.FooService
ComponentDescription: Complete recipe for AWS IoT Greengrass components
ComponentPublisher: Amazon
ComponentVersion: 1.0.0
ComponentConfiguration:
DefaultConfiguration:
TestParam: TestValue
ComponentDependencies:
BarService:
VersionRequirement: ^1.1.0
DependencyType: SOFT
BazService:
VersionRequirement: ^2.0.0
Manifests:
- Platform:
os: linux
architecture: amd64
Lifecycle:
install:
SkipIf: onpath git
Script: sudo apt-get install git
SetEnv:
environment_variable1: variable_value1
environment_variable2: variable_value2
Artifacts:
- Uri: 's3://amzn-s3-demo-bucket/hello_world.zip'
Unarchive: ZIP
- Uri: 's3://amzn-s3-demo-bucket/hello_world_linux.py'
- Lifecycle:
install:
SkipIf: onpath git
Script: sudo apt-get install git
RequiresPrivilege: 'true'
Artifacts:
- Uri: 's3://amzn-s3-demo-bucket/hello_world.py'
```
------
# Référence à la variable d'environnement du composant
Le logiciel AWS IoT Greengrass Core définit les variables d'environnement lorsqu'il exécute des scripts de cycle de vie pour les composants. Vous pouvez obtenir ces variables d'environnement dans vos composants pour obtenir le nom de l'objet et la Région AWS version du noyau de Greengrass. Le logiciel définit également les variables d'environnement dont votre composant a besoin pour utiliser [le SDK de communication interprocessus](interprocess-communication.md) et pour [interagir avec AWS les services](interact-with-aws-services.md).
Vous pouvez également définir des variables d'environnement personnalisées pour les scripts de cycle de vie de vos composants. Pour plus d'informations, consultez [Setenv](component-recipe-reference.md#lifecycle-setenv-definition).
Le logiciel AWS IoT Greengrass Core définit les variables d'environnement suivantes :
`AWS_IOT_THING_NAME`
Le nom de l' AWS IoT objet qui représente cet appareil central de Greengrass.
`AWS_REGION`
L' Région AWS endroit où fonctionne cet appareil principal Greengrass.
AWS SDKs Utilisez cette variable d'environnement pour identifier la région par défaut à utiliser. Cette variable est équivalente à`AWS_DEFAULT_REGION`.
`AWS_DEFAULT_REGION`
L' Région AWS endroit où fonctionne cet appareil principal Greengrass.
AWS CLI Utilise cette variable d'environnement pour identifier la région par défaut à utiliser. Cette variable est équivalente à`AWS_REGION`.
`GGC_VERSION`
Version du [composant Greengrass nucleus](greengrass-nucleus-component.md) qui s'exécute sur cet appareil principal de Greengrass.
`GG_ROOT_CA_PATH`
Cette fonctionnalité est disponible pour les versions 2.5.5 et ultérieures du composant [Greengrass](greengrass-nucleus-component.md) nucleus.
Le chemin d'accès au certificat de l'autorité de certification (CA) racine utilisé par le noyau Greengrass.
`AWS_GG_NUCLEUS_DOMAIN_SOCKET_FILEPATH_FOR_COMPONENT`
Le chemin d'accès au socket IPC que les composants utilisent pour communiquer avec le logiciel AWS IoT Greengrass Core. Pour de plus amples informations, veuillez consulter [Utilisez le Kit SDK des appareils AWS IoT pour communiquer avec le noyau de Greengrass, les autres composants et AWS IoT CoreCommuniquez avec le noyau de Greengrass, les autres composants et AWS IoT Core](interprocess-communication.md).
`SVCUID`
Le jeton secret que les composants utilisent pour se connecter au socket IPC et communiquer avec le logiciel AWS IoT Greengrass Core. Pour de plus amples informations, veuillez consulter [Utilisez le Kit SDK des appareils AWS IoT pour communiquer avec le noyau de Greengrass, les autres composants et AWS IoT CoreCommuniquez avec le noyau de Greengrass, les autres composants et AWS IoT Core](interprocess-communication.md).
`AWS_CONTAINER_AUTHORIZATION_TOKEN`
Le jeton secret que les composants utilisent pour récupérer les informations d'identification du [composant du service d'échange de jetons](token-exchange-service-component.md).
`AWS_CONTAINER_CREDENTIALS_FULL_URI`
L'URI demandé par les composants pour récupérer les informations d'identification auprès du [composant du service d'échange de jetons](token-exchange-service-component.md).