Plateformes personnalisées Elastic Beanstalk (retirées)

Une plateforme personnalisée est à plusieurs titres une personnalisation plus avancée qu'une image personnalisée. 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. Comparez cela aux images personnalisées, dans lesquelles vous modifiez une image Amazon Machine (AMI) pour l'utiliser avec une plateforme Elastic Beanstalk existante, et Elastic Beanstalk fournit toujours les scripts de la 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 plate-forme personnalisée, vous devez en créer une AMI à partir de l'un des systèmes d'exploitation pris en chargeRHEL, Ubuntu ou Amazon Linux (voir l'flavorentrée Format de fichier platform.yaml pour les numéros de version exacts), puis ajouter des personnalisations supplémentaires. Vous créez votre propre plateforme 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 AMI comprend un ensemble configuré pour exécuter un ensemble de logiciels prenant en charge une application, et des métadonnées pouvant inclure des options de configuration personnalisées et des paramètres d'options 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 plate-forme en fournissant à Elastic Beanstalk un modèle Packer, ainsi que les scripts et les fichiers que le modèle invoque pour créer un. AMI Ces composants sont fournis avec un fichier de définition de plate-forme, qui spécifie le modèle et les métadonnées, dans une ZIP archive, connue sous le nom d'archive de définition de plate-forme.

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.

Les utilisateurs de votre compte peuvent utiliser vos plateformes personnalisées en spécifiant une plate-forme ARN 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 plate-forme personnalisée avec, par exemple ARNMyCustomPlatformARN, la version 3.0, votre ligne de CLI commande EB devrait ressembler à ceci :

eb create -p MyCustomPlatformARN

Pour déployer la version 2.1, votre ligne de CLI commande EB ressemblera à ceci :

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 plus de détails, consultez Étiquette des versions de plateforme personnalisée.

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. Vous pouvez créer une plateforme personnalisée entièrement nouvelle ou reposant sur l'un des exemples de plateforme personnalisée.

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. Les seuls éléments que vous devez configurer dans les exemples avant de pouvoir les utiliser sont une source AMI et une région.

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.

|-- 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 un Ubuntu AMI comme base pour l'image de la plate-forme pour les types d'HVMinstances. 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

L'exemple de fichier custom_platform.json utilise ces variables pour définir les valeurs suivantes qu'il utilise dans les scripts :

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 AMI et des bonnes valeurs de région, voir Mettre à jour le modèle Packer dans le eb-custom-platforms-samples GitHub référentiel.

{
  "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 :

Utilisez l'EB CLI pour créer votre première plate-forme personnalisée à l'aide de l'exemple d'archive de définitions de plate-forme.

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.

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. L'archive de définition de plate-forme est un ZIP fichier qui contient un fichier de définition de plate-forme, un modèle Packer, ainsi que les scripts et fichiers utilisés par le modèle Packer pour créer votre plate-forme.

Le fichier de définition de plate-forme est un fichier YAML au format -formaté qui doit être nommé platform.yaml et se trouver à la racine de votre archive de définition de plate-forme. 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.

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 officielle pour plus d'informations sur la création de modèles Packer.

Les autres fichiers de votre archive de définition de plate-forme sont des scripts et des fichiers utilisés par le modèle pour personnaliser une instance avant d'en créer uneAMI.

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/.

Les hooks sont organisés dans les dossiers suivants :

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, 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

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 :

É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.

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'EB CLI pour créer la version personnalisée de votre plateforme, utilisez l'--tagsoption avec eb platform create pour ajouter des balises.

~/workspace/my-app$ eb platform create --tags mytag1=value1,mytag2=value2

Avec les clients API basés sur le AWS CLI ou d'autres, ajoutez des balises à l'aide du --tags paramètre de la create-platform-version commande.

$ 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'EB CLI pour mettre à jour la version personnalisée de votre plateforme, eb tags utilisez-le pour ajouter, mettre à jour, supprimer ou répertorier des balises.

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 les clients API basés sur le AWS CLI ou d'autres, utilisez la list-tags-for-resource 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 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.

$ aws elasticbeanstalk list-platform-versions