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. 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 pour connaître les numéros de version exacts), puis ajouter d'autres personnalisations. 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 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, qui spécifie le modèle et les métadonnées, dans une archive ZIP appelée archive de définition de plateforme.

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

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 une AMI 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

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 d'AMI et de région, consultez la section Mise à jour du 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'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.

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

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.

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

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 AWS aux 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'interface de ligne de commande EB pour créer votre version de plateforme personnalisée, utilisez l'option --tags avec eb 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

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

eb create -p MyCustomPlatformARN

eb create -p MyCustomPlatformARN --version 2.1

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

version: "1.0"

provisioner:
  type: packer
  template: custom_platform.json
  flavor: ubuntu1604

{
  "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"
      ]
    }
  ]
}

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"

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

$ 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

~/workspace/my-app$ eb tags --list --resource "arn:aws:elasticbeanstalk:us-east-2:my-account-id:platform/my-platform/1.0.0"

~/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"

$ aws elasticbeanstalk list-tags-for-resource --resource-arn "arn:aws:elasticbeanstalk:us-east-2:my-account-id:platform/my-platform/1.0.0"

$ 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"

$ aws elasticbeanstalk list-platform-versions