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. # Plateformes personnalisées Elastic Beanstalk (retirées) **Note** [Le 18 juillet 2022,](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2022-07-18-linux-al1-retire.html) **Elastic Beanstalk a défini le statut de toutes les branches de la plateforme sur la base de l'AMI AL1 Amazon Linux () comme étant supprimées.** Cela inclut les plateformes personnalisées. Elastic Beanstalk ne prend pas en charge les plateformes personnalisées. Pour en savoir plus sur le processus de retrait d'Amazon Linux AMI par Elastic Beanstalk, consultez [FAQ sur le retrait de la plateforme](using-features.migration-al.FAQ.md). Cette rubrique reste dans ce document comme référence pour tout client ayant utilisé la fonctionnalité de plateforme personnalisée d'Elastic Beanstalk avant son retrait. Dans le passé, les plateformes personnalisées Elastic Beanstalk permettaient de créer une AMI à partir de l'AMI Amazon Linux, RHEL 7, RHEL 6 ou Ubuntu 16.04 base. AMIs Ces systèmes d'exploitation ne sont plus pris en charge par Elastic Beanstalk. Pour en savoir plus sur la fonctionnalité des plateformes personnalisées, qui n'est plus prise en charge, consultez la rubrique suivante. ## Plateformes personnalisées Une plateforme personnalisée est à plusieurs titres une personnalisation plus avancée qu'une [image personnalisée](using-features.customenv.md). Une plateforme personnalisée vous permet de développer une plateforme entièrement nouvelle avec un système d'exploitation personnalisé, des logiciels supplémentaires et des scripts exécutés par Elastic Beanstalk sur les instances de la plateforme. Cette souplesse vous permet de construire une plateforme pour une application qui utilise un langage ou d'autres logiciels d'infrastructure pour lesquels Elastic Beanstalk ne fournit pas de plateforme gérée. Cela peut se comparer aux images personnalisées où une Amazon Machine Image (AMI) est modifiée pour être utilisée avec une plateforme Elastic Beanstalk existante, et Elastic Beanstalk fournit toujours les scripts de plateforme et contrôle la pile logicielle de la plateforme. Par ailleurs, avec les plateformes personnalisées, vous créez et tenez à jour vos personnalisations de façon automatisée et scriptée, alors qu'avec les images personnalisées, vous apportez les modifications manuellement sur une instance en cours d'exécution. Pour créer une plateforme personnalisée, vous devez générer une AMI à partir de l'un des systèmes d'exploitation pris en charge, Ubuntu, RHEL ou Amazon Linux (consultez l'entrée `flavor` dans [Format de fichier platform.yaml](#platform-yaml-format) pour connaître les numéros de version exacts), puis ajouter d'autres personnalisations. Vous créez votre propre [plateforme](https://www.packer.io/) Elastic Beanstalk à l'aide de Packer, un outil open source permettant de créer des images de machine pour de nombreuses plateformes, AMIs notamment pour Amazon Elastic Compute Cloud (Amazon). EC2 Une plateforme Elastic Beanstalk comprend une AMI configurée pour exécuter un ensemble de logiciels prenant en charge une application, et des métadonnées qui peuvent inclure des options de configuration personnalisées et des paramètres d'option de configuration par défaut. Elastic Beanstalk gère Packer comme une plateforme intégrée distincte. Autrement dit, vous n'avez pas besoin de vous soucier de la configuration et des versions de Packer. Vous créez une plateforme en fournissant un modèle Packer à Elastic Beanstalk, ainsi que les scripts et les fichiers que le modèle appelle pour créer une AMI. Ces composants sont fournis avec un [fichier de définition de plateforme](#custom-platform-creating), qui spécifie le modèle et les métadonnées, dans une archive ZIP appelée [archive de définition de plateforme](#custom-platforms-pda). Lorsque vous créez une plateforme personnalisée, vous lancez un environnement d'instance unique sans aucune adresse IP élastique pour exécuter Packer. Packer lance alors une autre instance pour générer une image. Vous pouvez réutiliser cet environnement pour plusieurs plateformes et plusieurs versions de chaque plateforme. **Note** Les plateformes personnalisées sont spécifiques à chaque AWS région. Si vous utilisez Elastic Beanstalk dans plusieurs régions, vous devez créer vos plateformes séparément dans chaque région. Dans certaines circonstances, les instances lancées par Packer ne sont pas nettoyées et doivent être mises hors service manuellement. Pour savoir comment nettoyer manuellement ces instances, consultez [Nettoyage des instances Packer](#custom-platforms-packercleanup). Les utilisateurs de votre compte peuvent utiliser vos plateformes personnalisées en spécifiant un [ARN de plateforme](AWSHowTo.iam.policies.arn.md) lors de la création de l'environnement. Ils ARNs sont renvoyés par la **eb platform create** commande que vous avez utilisée pour créer la plateforme personnalisée. Chaque fois que vous créez votre plateforme personnalisée, Elastic Beanstalk crée une nouvelle version de la plateforme. Les utilisateurs peuvent spécifier une plateforme par son nom pour obtenir uniquement la dernière version de la plateforme, ou inclure un numéro de version pour obtenir une version spécifique. Par exemple, pour déployer la dernière version de la plateforme personnalisée ayant l'ARN **MyCustomPlatformARN**, qui peut être la version 3.0, la ligne de commande de votre interface de ligne de commande EB se présente comme suit : ``` eb create -p MyCustomPlatformARN ``` Pour déployer la version 2.1, la ligne de commande de votre interface de ligne de commande EB se présente comme suit : ``` eb create -p MyCustomPlatformARN --version 2.1 ``` Vous pouvez appliquer des balises à une version de plateforme personnalisée lorsque vous la créez, et modifier des balises de versions de plateforme personnalisée existantes. Pour en savoir plus, consultez [Étiquette des versions de plateforme personnalisée](#custom-platforms-tagging). ### Création d'une plateforme personnalisée Pour créer une plateforme personnalisée, la racine de votre application doit inclure un fichier de définition de plateforme `platform.yaml`, qui définit le type de générateur utilisé pour la création de la plateforme personnalisée. Le format de ce fichier est décrit dans [Format de fichier platform.yaml](#platform-yaml-format). Vous pouvez créer une plateforme personnalisée entièrement nouvelle ou reposant sur l'un des [exemples de plateforme personnalisée](#custom-platforms-sample). ### Utilisation d'un exemple de plateforme personnalisée Une alternative à la création de votre propre plateforme personnalisée consiste à utiliser l'un des exemples d'archive de définition de plateforme pour amorcer votre plateforme personnalisée. Une AMI source et une région constituent les seuls éléments que vous devez configurer dans les exemples avant de pouvoir les utiliser. **Note** N'utilisez pas d'exemple de plateforme personnalisée non modifié en production. L'objectif des exemples vise à illustrer certaines des fonctionnalités disponibles pour une plateforme personnalisée, mais qui n'ont pas été renforcées à des fins de production. [NodePlatform\$1Ubuntu.zip](https://github.com/awslabs/eb-custom-platforms-samples/releases/download/v1.0.4/NodePlatform_Ubuntu.zip) Cette plateforme personnalisée est basée sur **Ubuntu 16.04** et prend en charge **Node.js 4.4.4**. Nous allons utiliser cette plateforme personnalisée pour les exemples de cette section. [NodePlatform\$1RHEL.zip](https://github.com/awslabs/eb-custom-platforms-samples/releases/download/v1.0.4/NodePlatform_RHEL.zip) Cette plateforme personnalisée est basée sur **RHEL 7.2** et prend en charge **Node.js 4.4.4**. [NodePlatform\$1 AmazonLinux .zip](https://github.com/awslabs/eb-custom-platforms-samples/releases/download/v1.0.4/NodePlatform_AmazonLinux.zip) Cette plateforme personnalisée est basée sur **Amazon Linux 2016.09.1** et prend en charge **Node.js 4.4.4**. [TomcatPlatform\$1Ubuntu.zip](https://github.com/awslabs/eb-custom-platforms-samples/releases/download/v1.0.4/TomcatPlatform_Ubuntu.zip) Cette plateforme personnalisée est basée sur **Ubuntu 16.04** et prend en charge **Tomcat 7/Java 8**. [CustomPlatform\$1 NodeSampleApp .zip](https://github.com/awslabs/eb-custom-platforms-samples/releases/download/v1.0.4/CustomPlatform_NodeSampleApp.zip) Exemple Node.js qui utilise **express** et **ejs** pour afficher une page web statique. [CustomPlatform\$1 TomcatSampleApp .zip](https://github.com/awslabs/eb-custom-platforms-samples/releases/download/v1.0.4/CustomPlatform_TomcatSampleApp.zip) Exemple Tomcat qui affiche une page web statique lors de son déploiement. Téléchargez l'exemple d'archive de définition de plateforme : `NodePlatform_Ubuntu.zip`. Ce fichier contient un fichier de définition de plateforme, un modèle Packer, des scripts exécutés par Packer lors de la création de l'image, et des scripts et des fichiers de configuration que Packer copie sur l'instance de générateur lors de la création de la plateforme. **Example NodePlatform\$1Ubuntu.zip** ``` |-- builder Contains files used by Packer to create the custom platform |-- custom_platform.json Packer template |-- platform.yaml Platform definition file |-- ReadMe.txt Briefly describes the sample ``` Le fichier de définition de plateforme, `platform.yaml`, indique à Elastic Beanstalk le nom du modèle Packer, `custom_platform.json`. ``` version: "1.0" provisioner: type: packer template: custom_platform.json flavor: ubuntu1604 ``` Le modèle Packer indique à Packer comment créer le AMIs pour la plate-forme, en utilisant une [AMI](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) Ubuntu comme base pour l'image de plate-forme pour les types d'instances HVM. La section `provisioners` demande à Packer de copier tous les fichiers dans le dossier `builder` au sein de l'archive vers l'instance et d'exécute le script `builder.sh` sur l'instance. Lorsque les scripts sont terminés, Packer crée une image à partir de l'instance modifiée. Elastic Beanstalk crée trois variables d'environnement qui peuvent être utilisées pour baliser dans Packer : AMIs AWS\$1EB\$1PLATFORM\$1ARN L'ARN de la plateforme personnalisée. AWS\$1EB\$1NOM\$1PLATEFORME Le nom de la plateforme personnalisée. AWS\$1EB\$1VERSION\$1DE PLATEFORME La version de la plateforme personnalisée. L'exemple de fichier `custom_platform.json` utilise ces variables pour définir les valeurs suivantes qu'il utilise dans les scripts : + `platform_name`, qui est définie par `platform.yaml` + `platform_version`, qui est définie par `platform.yaml` + `platform_arn`, qui est définie par le script de génération principal, `builder.sh`, qui s'affiche à la fin de l'exemple de fichier `custom_platform.json`. Le fichier `custom_platform.json` contient deux propriétés pour lesquelles vous devez préciser une valeur : `source_ami` et `region`. Pour plus de détails sur le choix des bonnes valeurs d'AMI et de région, consultez la section [Mise à jour du modèle Packer](https://github.com/aws-samples/eb-custom-platforms-samples#updating-packer-template) dans le *eb-custom-platforms-samples* GitHub référentiel. **Example custom\$1platform.json** ``` { "variables": { "platform_name": "{{env `AWS_EB_PLATFORM_NAME`}}", "platform_version": "{{env `AWS_EB_PLATFORM_VERSION`}}", "platform_arn": "{{env `AWS_EB_PLATFORM_ARN`}}" }, "builders": [ { ... "region": "", "source_ami": "", ... } ], "provisioners": [ {...}, { "type": "shell", "execute_command": "chmod +x {{ .Path }}; {{ .Vars }} sudo {{ .Path }}", "scripts": [ "builder/builder.sh" ] } ] } ``` Les scripts et les autres fichiers que vous incluez dans votre archive de définition de plateforme varient considérablement selon les modifications que vous souhaitez apporter à l'instance. L'exemple de plateforme inclut les scripts suivants : + `00-sync-apt.sh` – Mis en commentaire : `apt -y update`. Nous avons mis la commande en commentaire parce qu'elle demande à l'utilisateur une entrée, ce qui rompt la mise à jour automatique du package. Cela peut être un problème Ubuntu. Cependant, l'exécution d'`apt -y update` est toujours recommandée comme bonne pratique. Pour cette raison, nous avons laissé la commande dans l'exemple de script à titre de référence. + `01-install-nginx.sh` – Installe nginx. + `02-setup-platform.sh` – Installe `wget`, `tree` et `git`. Copie les hooks et les [configurations de journalisation](using-features.logging.md) sur l'instance, et crée les répertoires suivants : + `/etc/SampleNodePlatform` – Emplacement de chargement du fichier de configuration de conteneur pendant le déploiement. + `/opt/elasticbeanstalk/deploy/appsource/` – Emplacement où le script `00-unzip.sh` charge le code source de l'application pendant le déploiement (pour plus d'informations sur ce script, consultez la section [Outils de script de plateforme pour vos environnements Elastic Beanstalk](custom-platforms-scripts.md)). + `/var/app/staging/` – Emplacement de traitement du code source de l'application pendant le déploiement. + `/var/app/current/` – Emplacement d'exécution du code source de l'application après le traitement. + `/var/log/nginx/healthd/` – Emplacement où l'[agent amélioré de vérification de l'état](health-enhanced.md#health-enhanced-agent) écrit les journaux. + `/var/nodejs` – Emplacement de chargement des fichiers Node.js pendant le déploiement. Utilisez l'interface de ligne de commande EB pour créer votre première plateforme personnalisée avec l'exemple d'archive de définition de plateforme. **Pour créer une plateforme personnalisée** 1. [Installez l'interface de ligne de commande EB](eb-cli3.md#eb-cli3-install). 1. Créez un répertoire dans lequel l'exemple de plateforme personnalisée sera extrait. ``` ~$ mkdir ~/custom-platform ``` 1. Extrayez `NodePlatform_Ubuntu.zip` dans le répertoire, puis modifiez le répertoire extrait. ``` ~$ cd ~/custom-platform ~/custom-platform$ unzip ~/NodePlatform_Ubuntu.zip ~/custom-platform$ cd NodePlatform_Ubuntu ``` 1. Modifiez le fichier `custom_platform.json` et fournissez les valeurs des propriétés `source_ami` et `region`. Pour plus d'informations, consultez [Updating Packer template](https://github.com/aws-samples/eb-custom-platforms-samples#updating-packer-template) (Mise à jour du modèle Packer). 1. Exécutez [**eb platform init**](eb3-platform.md#eb3-platform-init) et suivez les instructions pour initialiser un référentiel de plateforme. Vous pouvez raccourcir **eb platform** en **ebp**. **Note** Windows PowerShell l'utilise **ebp** comme alias de commande. Si vous exécutez l'interface de ligne de commande EB sous Windows PowerShell, utilisez la forme longue de cette commande :**eb platform**. ``` ~/custom-platform$ eb platform init ``` Cette commande crée également le répertoire `.elasticbeanstalk` dans le répertoire actuel et ajoute le fichier de configuration `config.yml` au répertoire. Ne modifiez ou ne supprimez pas ce fichier, car Elastic Beanstalk l'utilise pour créer la plateforme personnalisée. Par défaut, **eb platform init** utilise le nom du dossier actuel comme nom de plateforme personnalisée, `custom-platform` dans cet exemple. 1. Exécutez la commande [**eb platform create**](eb3-platform.md#eb3-platform-create) pour lancer un environnement Packer et obtenir l'ARN de la plateforme personnalisée. Vous aurez besoin de cette valeur plus tard lorsque vous créerez un environnement en utilisant la plateforme personnalisée. ``` ~/custom-platform$ eb platform create ... ``` Par défaut, Elastic Beanstalk crée le profil d'instance `aws-elasticbeanstalk-custom-platform-ec2-role` pour les plateformes personnalisées. Si vous préférez utiliser un profil d'instance existant, ajoutez l'option `-ip INSTANCE_PROFILE` à la commande [**eb platform create**](eb3-platform.md#eb3-platform-create). **Note** Packer ne parvient pas à créer de plateforme personnalisée si vous utilisez le profil d'instance Elastic Beanstalk par défaut, `aws-elasticbeanstalk-ec2-role`. L'interface de ligne de commande EB affiche l'événement généré par l'environnement Packer jusqu'à ce que la génération soit terminée. Vous pouvez quitter la vue des événements en appuyant sur **Ctrl\$1C**. 1. Vous pouvez consulter les erreurs d'utilisation de la commande [**eb platform logs**](eb3-platform.md#eb3-platform-logs) dans les journaux. ``` ~/custom-platform$ eb platform logs ... ``` 1. Vous pouvez vérifier le processus ultérieurement avec [**eb platform events**](eb3-platform.md#eb3-platform-events). ``` ~/custom-platform$ eb platform events ... ``` 1. Vérifiez l'état de votre plateforme avec [**eb platform status**](eb3-platform.md#eb3-platform-status). ``` ~/custom-platform$ eb platform status ... ``` Lorsque l'opération est terminée, vous disposez d'une plateforme que vous pouvez utiliser pour lancer un environnement Elastic Beanstalk. Vous pouvez utiliser la plateforme personnalisée lors de la création d'un nouvel environnement à partir de la console. Consultez [Assistant de création d'un environnement](environments-create-wizard.md). **Pour lancer un environnement sur votre plateforme personnalisée** 1. Créez un nouveau répertoire pour votre application. ``` ~$ mkdir custom-platform-app ~$ cd ~/custom-platform-app ``` 1. Initialisez un référentiel d'application. ``` ~/custom-platform-app$ eb init ... ``` 1. Téléchargez l'exemple d'application [NodeSampleApp.zip.](samples/NodeSampleApp.zip) 1. Procédez à l'extraction de l'exemple d'application. ``` ~/custom-platform-app$ unzip ~/NodeSampleApp.zip ``` 1. Exécutez**eb create -p *CUSTOM-PLATFORM-ARN***, où *CUSTOM-PLATFORM-ARN* est l'ARN renvoyé par une **eb platform create** commande, pour lancer un environnement exécutant votre plateforme personnalisée. ``` ~/custom-platform-app$ eb create -p CUSTOM-PLATFORM-ARN ... ``` ### Contenu de l'archive de définition de plateforme Une archive de définition de plateforme est l'équivalent plateforme d'un [bundle de fichiers source d'application](applications-sourcebundle.md). L'archive de définition de plateforme est un fichier ZIP qui contient un fichier de définition de plateforme, un modèle Packer, ainsi que les scripts et les fichiers utilisés par le modèle Packer pour créer votre plateforme. **Note** Lorsque vous utilisez l'interface de ligne de commande EB pour créer une plateforme personnalisée, une archive de définition de plateforme est créée à partir des fichiers et des dossiers de votre référentiel de plateforme. Vous n'avez donc pas besoin de créer l'archive manuellement. Le fichier de définition de plateforme est un fichier au format YAML qui doit être nommé `platform.yaml` et se trouver à la racine de votre archive de définition de plateforme. Pour obtenir la liste des clés obligatoires et facultatives prises en charge dans un fichier de définition de plateforme, consultez [Création d'une plateforme personnalisée](#custom-platform-creating). Vous n'avez pas besoin d'attribuer un nom spécifique au modèle Packer, mais le nom du fichier doit correspondre au modèle de fournisseur spécifié dans le fichier de définition de plateforme. Consultez la [documentation Packer](https://www.packer.io/docs/templates/introduction.html) officielle pour plus d'informations sur la création de modèles Packer. Les autres fichiers que contient votre archive de définition de plateforme sont des scripts et des fichiers utilisés par le modèle pour personnaliser une instance avant de créer une AMI. ### Hooks de plateforme personnalisée Elastic Beanstalk utilise une structure de répertoires normalisée pour les hooks sur les plateformes personnalisées. Il s'agit de scripts exécutés au cours d'événements du cycle de vie et en réponse à des opérations de gestion : lorsque des instances dans votre environnement sont lancées, ou lorsqu'un utilisateur initie un déploiement ou utilise la fonctionnalité de redémarrage de serveur d'application. Placez les scripts que vous souhaitez voir déclenchés par les hooks dans l'un des sous-dossiers du dossier `/opt/elasticbeanstalk/hooks/`. **Avertissement** *L'utilisation de hooks de plateforme personnalisée sur des plateformes gérées n'est pas prise en charge.* Les hooks de plateforme personnalisée sont conçus pour les plateformes personnalisées. Sur les plateformes Elastic Beanstalk gérées, ils peuvent fonctionner différemment ou présenter quelques problèmes, et le comportement peut varier d'une plateforme à l'autre. Sur les plateformes de l'AMI Amazon Linux (anciennement Amazon Linux 2), ils peuvent toujours s'avérer utiles dans certains cas ; utilisez-les avec prudence. Les hooks de plateforme personnalisés sont une fonctionnalité héritée qui existe sur les plateformes de l'AMI Amazon Linux. Sur les plateformes Amazon Linux 2, les hooks de plateforme personnalisés qui figurent dans le dossier `/opt/elasticbeanstalk/hooks/` sont complètement obsolètes. Elastic Beanstalk ne les lit ou ne les exécute pas. Les plateformes Amazon Linux 2 prennent en charge un nouveau type de hook de plateforme, spécialement conçu pour étendre les plateformes Elastic Beanstalk gérées. Vous pouvez ajouter des scripts et des programmes personnalisés directement dans un répertoire hooks de votre bundle de fichiers source d'application. Elastic Beanstalk les exécute au cours des différentes étapes de provisionnement d'instance. Pour plus d'informations, développez la section *Platform Hooks* dans [Extension des plateformes Linux Elastic Beanstalk](platforms-linux-extend.md). Les hooks sont organisés dans les dossiers suivants : + `appdeploy` &endash; Scripts exécutés lors d'un déploiement d'application. Elastic Beanstalk effectue un déploiement d'application lorsque de nouvelles instances sont lancées et quand un client initie un déploiement de nouvelle version. + `configdeploy` — Scripts exécutés lorsqu'un client effectue une mise à jour de configuration qui affecte la configuration logicielle sur l'instance, par exemple, en définissant des propriétés d'environnement ou en activant la rotation des journaux sur Amazon S3. + `restartappserver` &endash; Scripts exécutés lorsqu'un client effectue une opération de redémarrage de serveur d'application. + `preinit` &endash; Scripts exécutés lors de l'amorçage d'une instance. + `postinit` &endash; Scripts exécutés après l'amorçage d'une instance. Les dossiers `appdeploy`, `configdeploy` et `restartappserver` contiennent les sous-dossiers `pre`, `enact` et `post`. Lors de chaque phase d'une opération, tous les scripts du dossier `pre` sont exécutés par ordre alphabétique, puis viennent ceux du dossier `enact`, puis ceux du dossier `post`. Lorsqu'une instance est démarrée, Elastic Beanstalk exécute `preinit`, `appdeploy` et `postinit`. Sur les déploiements suivants sur des instances en cours d'exécution, Elastic Beanstalk exécute les hooks `appdeploy`. Les hooks `configdeploy` sont exécutés lorsqu'un utilisateur met à jour des paramètres de configuration de logiciel d'instance. Les hooks `restartappserver` sont exécutés uniquement lorsque l'utilisateur lance un redémarrage de serveur d'application. Lorsque vos scripts détectent des erreurs, ils peuvent quitter avec un état différent de zéro et écrire sur `stderr` pour faire échouer l'opération. Le message que vous écrivez dans `stderr` apparaîtra dans l'événement qui est généré lorsque l'opération échoue. Elastic Beanstalk capture également ces informations dans le fichier journal `/var/log/eb-activity.log`. Si vous ne voulez pas que l'opération échoue, renvoyez 0 (zéro). Les messages que vous écrivez dans `stderr` ou `stdout` apparaissent dans les [journaux de déploiement](using-features.logging.md), mais pas dans le flux d'événements, sauf si l'opération échoue. ### Nettoyage des instances Packer Dans certaines conditions, par exemple la suppression du processus du générateur Packer avant sa fin, les instances lancées par Packer ne sont pas nettoyées. Ces instances ne font pas partie de l'environnement Elastic Beanstalk et ne peuvent être consultées et résiliées qu'en utilisant le service Amazon. EC2 **Pour nettoyer manuellement ces instances** 1. Ouvrez la [ EC2 console Amazon](https://console.aws.amazon.com/ec2/). 1. Assurez-vous que vous vous trouvez dans la même AWS région que celle dans laquelle vous avez créé l'instance avec Packer. 1. Sous **Ressources**, choisissez *N * **Running Instances**, où *N* indique le nombre d'instances en cours d'exécution. 1. Dans la zone de texte de la requête. 1. Sélectionnez la balise **Name**. 1. Saisissez **packer**. La requête doit se présenter comme suit : **tag:Name: packer** 1. Sélectionnez les instances qui correspondent à la requête. 1. Si **État de l'instance** est **en cours d'exécution**, sélectionnez **Actions**, **État de l'instance**, **Arrêter**, puis **Actions**, **État de l'instance**, **Résilier**. ### Format de fichier platform.yaml Le fichier `platform.yaml` a le format suivant : ``` version: "version-number" provisioner: type: provisioner-type template: provisioner-template flavor: provisioner-flavor metadata: maintainer: metadata-maintainer description: metadata-description operating_system_name: metadata-operating_system_name operating_system_version: metadata-operating_system_version programming_language_name: metadata-programming_language_name programming_language_version: metadata-programming_language_version framework_name: metadata-framework_name framework_version: metadata-framework_version option_definitions: - namespace: option-def-namespace option_name: option-def-option_name description: option-def-description default_value: option-def-default_value option_settings: - namespace: "option-setting-namespace" option_name: "option-setting-option_name" value: "option-setting-value" ``` Remplacez les espaces réservés par les valeurs suivantes : *version-number* Obligatoire. La version de la définition YAML. Doit indiquer **1.0**. *provisioner-type* Obligatoire. Le type de générateur utilisé pour créer la plateforme personnalisée. Doit indiquer **packer**. *provisioner-template* Obligatoire. Le fichier JSON contenant les paramètres pour*provisioner-type*. *provisioner-flavor* Facultatif. Le système d'exploitation de base utilisé pour l'AMI. L'un des éléments suivants : amazon (valeur par défaut) Amazon Linux. Si la version n'est pas spécifiée, il s'agit de la dernière version d'Amazon Linux disponible au moment de la création de la plateforme. Amazon Linux 2 n'est pas une version de système d'exploitation prise en charge. ubuntu1604 Ubuntu 16.04 LTS rhel7 RHEL 7 rhel6 RHEL 6 *metadata-maintainer* Facultatif. Informations de contact pour la personne qui possède la plateforme (100 caractères). *metadata-description* Facultatif. Description de la plateforme (2 000 caractères). *metadata-operating\$1system\$1name* Facultatif. Nom du système d'exploitation de la plateforme (50 caractères). Cette valeur est disponible lors du filtrage de la sortie pour l'[ListPlatformVersions](https://docs.aws.amazon.com/elasticbeanstalk/latest/api/API_ListPlatformVersions.html)API. *metadata-operating\$1system\$1version* Facultatif. Version du système d'exploitation de la plateforme (20 caractères). *metadata-programming\$1language\$1name* Facultatif. Langage de programmation pris en charge par la plateforme (50 caractères). *metadata-programming\$1language\$1version* Facultatif. Langue de la version de la plateforme (20 caractères). *metadata-framework\$1name* Facultatif. Nom de l'infrastructure web utilisée par la plateforme (50 caractères). *metadata-framework\$1version* Facultatif. Version de l'infrastructure web de la plateforme (20 caractères). *option-def-namespace* Facultatif. Un espace de noms sous `aws:elasticbeanstalk:container:custom` (100 caractères) *option-def-option\$1name* Facultatif. Nom de l'option (100 caractères). Vous pouvez définir jusqu'à 50 options de configuration personnalisées que la plateforme fournit aux utilisateurs. *option-def-description* Facultatif. Description de l'option (1 024 caractères). *option-def-default\$1value* Facultatif. Valeur par défaut utilisée lorsque l'utilisateur n'en spécifie pas. L'exemple suivant crée l'option **NPM\$1START**. ``` options_definitions: - namespace: "aws:elasticbeanstalk:container:custom:application" option_name: "NPM_START" description: "Default application startup command" default_value: "node application.js" ``` *option-setting-namespace* Facultatif. Espace de noms de l'option. *option-setting-option\$1name* Facultatif. Nom de l'option. Vous pouvez spécifier jusqu'à 50 [options fournies par Elastic Beanstalk](command-options-general.md). *option-setting-value* Facultatif. Valeur utilisée lorsque l'utilisateur n'en spécifie pas. L'exemple suivant crée l'option **TEST**. ``` option_settings: - namespace: "aws:elasticbeanstalk:application:environment" option_name: "TEST" value: "This is a test" ``` ### Étiquette des versions de plateforme personnalisée Vous pouvez appliquer des balises aux versions AWS Elastic Beanstalk personnalisées de votre plateforme. Les balises sont des paires clé-valeur associées à des AWS ressources. Pour plus d'informations sur l'étiquette des ressources Elastic Beanstalk, les cas d'utilisation, les contraintes de clé et de valeur d'identification, et les types de ressources pris en charge, consultez [Étiquette des ressources d'application Elastic Beanstalk](applications-tagging-resources.md). Vous pouvez spécifier des identifications lorsque vous créez une version de plateforme personnalisée. Dans une version de plateforme personnalisée, vous pouvez ajouter ou supprimer des identifications, ainsi que mettre à jour les valeurs des identifications existantes. Vous pouvez ajouter jusqu'à 50 identifications à chaque version de plateforme personnalisée. #### Ajout d'identifications lors de la création de versions de plateforme personnalisée Si vous utilisez l'interface de ligne de commande EB pour créer votre version de plateforme personnalisée, utilisez l'option `--tags` avec **[eb platform create](eb3-platform.md#eb3-platform-create)** pour ajouter des identifications. ``` ~/workspace/my-app$ eb platform create --tags mytag1=value1,mytag2=value2 ``` Avec le AWS CLI ou d'autres clients basés sur une API, ajoutez des balises en utilisant le `--tags` paramètre de la commande. **[create-platform-version](https://docs.aws.amazon.com/cli/latest/reference/elasticbeanstalk/create-platform-version.html)** ``` $ aws elasticbeanstalk create-platform-version \ --tags Key=mytag1,Value=value1 Key=mytag2,Value=value2 \ --platform-name my-platform --platform-version 1.0.0 --platform-definition-bundle S3Bucket=amzn-s3-demo-bucket,S3Key=sample.zip ``` #### Gestion des identifications d'une version de plateforme personnalisée existante Vous pouvez ajouter, mettre à jour et supprimer des identifications dans une version existante de la plateforme personnalisée Elastic Beanstalk. Si vous utilisez l'interface de ligne de commande EB pour mettre à jour votre version de plateforme personnalisée, utilisez **[eb tags](eb3-tags.md)** pour ajouter, mettre à jour, supprimer ou répertorier des identifications. Par exemple, la commande suivante répertorie les identifications dans une version de plateforme personnalisée. ``` ~/workspace/my-app$ eb tags --list --resource "arn:aws:elasticbeanstalk:us-east-2:my-account-id:platform/my-platform/1.0.0" ``` La commande suivante met à jour l'identification `mytag1` et supprime l'identification `mytag2`. ``` ~/workspace/my-app$ eb tags --update mytag1=newvalue --delete mytag2 \ --resource "arn:aws:elasticbeanstalk:us-east-2:my-account-id:platform/my-platform/1.0.0" ``` Pour obtenir une liste complète des options et d'autres exemples, consultez `eb tags`. Avec le AWS CLI ou d'autres clients basés sur une API, utilisez la **[list-tags-for-resource](https://docs.aws.amazon.com/cli/latest/reference/elasticbeanstalk/list-tags-for-resource.html)** commande pour répertorier les balises d'une version de plate-forme personnalisée. ``` $ aws elasticbeanstalk list-tags-for-resource --resource-arn "arn:aws:elasticbeanstalk:us-east-2:my-account-id:platform/my-platform/1.0.0" ``` Utilisez la commande **[update-tags-for-resource](https://docs.aws.amazon.com/cli/latest/reference/elasticbeanstalk/update-tags-for-resource.html)** pour ajouter, mettre à jour ou supprimer des identifications dans une version de plateforme personnalisée. ``` $ aws elasticbeanstalk update-tags-for-resource \ --tags-to-add Key=mytag1,Value=newvalue --tags-to-remove mytag2 \ --resource-arn "arn:aws:elasticbeanstalk:us-east-2:my-account-id:platform/my-platform/1.0.0" ``` Spécifiez les identifications à ajouter et les identifications à mettre à jour dans le paramètre `--tags-to-add` de **update-tags-for-resource**. Une identification inexistante est ajoutée et la valeur d'une identification existante est mise à jour. **Note** Pour utiliser certaines AWS CLI commandes et certaines de l'interface de ligne de commande EB avec une version de plateforme personnalisée d'Elastic Beanstalk, vous avez besoin de l'ARN de cette version personnalisée. Vous pouvez extraire l'ARN à l'aide de la commande suivante. ``` $ aws elasticbeanstalk list-platform-versions ``` Utilisez l'option `--filters` pour filtrer la sortie vers le nom de votre plateforme personnalisée.