Elastic Beanstalk カスタムプラットフォーム - AWS Elastic Beanstalk

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

Elastic Beanstalk カスタムプラットフォーム

注記

2022 年 7 月 18 日、Elastic Beanstalk では Amazon Linux AMI (AL1) に基づくプラットフォームブランチのステータスがすべて廃止されます。これには、カスタムプラットフォームが含まれます。Elastic Beanstalk は、カスタムプラットフォームをサポートしていません。Elastic Beanstalk による Amazon Linux AMI の廃止に関する詳細については、「プラットフォームの廃止に関するよくある質問」を参照してください。

このトピックは、廃止前に Elastic Beanstalk カスタムプラットフォーム機能を使用したすべてのお客様の参照用として、このドキュメントに残ります。以前、Elastic Beanstalk カスタムプラットフォームでは、Amazon Linux AMI、RHEL 7、RHEL 6、または Ubuntu 16.04 ベース AMI からの AMI の構築をサポートしていました。これらのオペレーティングシステムは、Elastic Beanstalk によってサポートされなくなりました。サポートされなくなったカスタムプラットフォーム機能の詳細については、次のトピックを展開してください。

カスタムプラットフォームは、いくつかの点でカスタムイメージより高度なカスタマイズです。カスタムプラットフォームでは、ゼロから新しいプラットフォーム全体を開発し、プラットフォームインスタンスで Elastic Beanstalk が実行するオペレーティングシステム、その他のソフトウェア、およびスクリプトをカスタマイズできます。この柔軟性により、Elastic Beanstalk がマネージドプラットフォームを提供していない、言語やその他のインフラストラクチャソフトウェアを使用するアプリケーション用のプラットフォームを構築できます。既存の Elastic Beanstalk プラットフォームで使用する Amazon マシンイメージ (AMI) を変更するカスタムイメージと比べた場合、Elastic Beanstalk は依然としてプラットフォームスクリプトを提供してプラットフォームのソフトウェアスタックを制御します。さらに、カスタムプラットフォームでは、自動のスクリプト化された方法を使用してカスタマイズを作成して維持します。一方、カスタムイメージでは、実行中のインスタンスで変更を手動で行います。

カスタムプラットフォームを作成するには、サポートされているオペレーティングシステムである Ubuntu、RHEL、または Amazon Linux (正確なバージョン番号については「Platform.yaml ファイルの形式。」の flavor エントリを参照) のいずれかから Amazon マシンイメージ (AMI) を作成し、それをカスタマイズします。Packer を使用して独自の Elastic Beanstalk プラットフォームを作成します。これは、Amazon Elastic Compute Cloud (Amazon EC2) で使用する AMI を含む多くのプラットフォームのマシンイメージを作成するためのオープンソースツールです。Elastic Beanstalk プラットフォームは、アプリケーションをサポートする一連のソフトウェアを実行するよう設定された AMI と、カスタム設定オプションやデフォルトの設定オプションの設定を含むことができるメタデータで構成されます。

Elastic Beanstalk は Packer を個別の組み込みプラットフォームとして管理するため、Packer の設定とバージョンについて心配する必要はありません。

Packer テンプレートと、AMI を構築するにテンプレートが呼び出すスクリプトおよびファイルを Elastic Beanstalk に提供して、プラットフォームを作成します。これらのコンポーネントは、テンプレートとメタデータを指定するプラットフォーム定義ファイルにより、プラットフォーム定義ファイルと呼ばれる ZIP アーカイブにパッケージ化されます。

カスタムプラットフォームの作成時に、Packer を実行する Elastic IP を使用しないで単一インスタンス環境を起動します。こうすることで Packer は別のインスタンスを起動してイメージを作成します。この環境は、複数のプラットフォームや各プラットフォームの複数のバージョンで再利用できます。

注記

カスタムプラットフォームは AWS リージョン固有です。複数のリージョンで Elastic Beanstalk を使用する場合は、各リージョンでプラットフォームを個別に作成する必要があります。

特定の状況下では、Packer で起動したインスタンスはクリーンアップされないため、手動で終了させる必要があります。これらのインスタンスを手動でクリーンアップする方法については、「Packer インスタンスのクリーンアップ」を参照してください。

アカウントのユーザーは、環境の作成中にプラットフォーム ARN を指定してカスタムプラットフォームを使用できます。ARN は、カスタムプラットフォームの作成に使用した eb platform create コマンドによって返されます。

カスタムプラットフォームを構築するたびに、Elastic Beanstalk は新しいプラットフォームのバージョンを作成します。ユーザーは、プラットフォームを名前で指定して最新バージョンのプラットフォームのみを取得したり、バージョン番号を指定して特定のバージョンを取得したりできます。

たとえば、最新バージョンのカスタムプラットフォーム (バージョン 3.0 など) を、ARN MyCustomPlatformARN を使用してデプロイする場合、EB CLI のコマンドラインは次のようになります。

eb create -p MyCustomPlatformARN

バージョン 2.1 をデプロイする場合、EB CLI のコマンドラインは次のようになります。

eb create -p MyCustomPlatformARN --version 2.1

カスタムプラットフォームバージョンの作成時にタグを適用できます。また、既存のカスタムプラットフォームバージョンのタグを編集できます。詳細については、「custom プラットフォームバージョンのタグ付け」を参照してください。

カスタムプラットフォームの作成

カスタムプラットフォームを作成するには、アプリケーションの root に platform.yaml ファイルを含める必要があります。このファイルは、カスタムプラットフォームの作成に使用されるビルダーのタイプを定義します。このファイルの形式は、「Platform.yaml ファイルの形式。」で説明しています。カスタムプラットフォームを最初から作成することも、サンプルカスタムプラットフォームのいずれかを開始点として使用することもできます。

サンプル カスタム プラットフォームの使用

独自のカスタムプラットフォームを作成する別の方法として、プラットフォーム定義アーカイブサンプルの 1 つを使用してカスタムプラットフォームをブートストラップできます。ソース AMI とリージョンを設定するだけで、サンプルを使用できます。

注記

本番稼働で未変更のサンプルカスタムプラットフォームを使用しないでください。サンプルの目的は、プラットフォームで使用できる機能の一部を紹介することであり、本番稼働用としては強化されていません。

NodePlatform_Ubuntu.zip

このカスタムプラットフォームは、Ubuntu 16.04 に基づいており、Node.js 4.4.4 をサポートしています。このセクションの例では、このカスタムプラットフォームを使用しています。

NodePlatform_RHEL.zip

このカスタムプラットフォームは、RHEL 7.2 に基づいており、Node.js 4.4.4 をサポートしています。

NodePlatform_AmazonLinux.zip

このカスタムプラットフォームは、Amazon Linux 2016.09.1 に基づいており、Node.js 4.4.4 をサポートしています。

TomcatPlatform_Ubuntu.zip

このカスタムプラットフォームは、Ubuntu 16.04 に基づいており、Tomcat 7/Java 8 をサポートしています。

CustomPlatform_NodeSampleApp.zip

[express] と [ejs] を使用して静的なウェブページを表示する Node.js サンプル

CustomPlatform_TomcatSampleApp.zip

デプロイ時静的ウェブページを表示する Tomcat のサンプル

サンプルプラットフォーム定義アーカイブ NodePlatform_Ubuntu.zip をダウンロードします。このファイルには、プラットフォーム定義ファイル、Packer テンプレート、イメージの作成中に Packer が実行するスクリプト、およびプラットフォームの作成中に Packer がビルダーインスタンスにコピーするスクリプトと設定ファイルが含まれています。

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

プラットフォーム定義ファイル platform.yaml は、Elastic Beanstalk に Packer テンプレート (custom_platform.json) の名前を指定します。

version: "1.0"

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

Packer テンプレートは、HVM インスタンスタイプのプラットフォームイメージのベースとして Ubuntu AMI を使用して、プラットフォーム用の AMI を構築する方法を Packer に伝えます。provisioners セクションでは、アーカイブ内の builder フォルダのすべてのファイルをインスタンスにコピーし、インスタンスで builder.sh スクリプトを実行するよう Packer に伝えます。スクリプトが完了すると、Packer は変更したインスタンスからイメージを作成します。

Elastic Beanstalk は、Packer の AMI にタグを付けるために使用できる 3 つの環境変数を作成します。

AWS_EB_PLATFORM_ARN

カスタム プラットフォームの ARN。

AWS_EB_PLATFORM_NAME

カスタム プラットフォームの名前。

AWS_EB_PLATFORM_VERSION

カスタム プラットフォームのバージョン。

サンプル custom_platform.json ファイルは、これらの変数を使用して、スクリプトで使用する次の値を定義します。

  • platform_name で設定されている platform.yaml

  • platform_version で設定されている platform.yaml

  • platform_arn は、メインビルドスクリプトによって設定され、builder.sh は、サンプル custom_platform.json のファイルの最後に表示される。

この custom_platform.json ファイルには、値を指定する必要がある 2 つのプロパティとして source_ami と region があります。AMI とリージョンの適切な値を選択する方法の詳細については、eb-custom-platforms-samples GitHub リポジトリの「Updating Packer template」(Packer テンプレートの更新) を参照してください。

例 custom_platform.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"
      ]
    }
  ]
}

プラットフォーム定義アーカイブに含めるスクリプトとその他のファイルは、インスタンスに対して行う変更によって大きく異なります。サンプルプラットフォームには以下のスクリプトが含まれます。

  • 00-sync-apt.sh – コメントアウト: apt -y update。ユーザーに自動パッケージの更新を中断させるようプロンプトするため、このコマンドについてコメントアウトしました。これは、Ubuntu の問題の可能性があります。ただし、ベストプラクティスとして apt -y update を実行することを依然としてお勧めします。このため、このコマンドは参照用としてサンプルスクリプトに残してあります。

  • 01-install-nginx.sh – nginx をインストールします。

  • 02-setup-platform.sh – wget、tree、git をインストールします。フックとログ作成設定をインスタンスにコピーし、次のディレクトリを作成します。

    • /etc/SampleNodePlatform – ここに、デプロイ中にコンテナ設定ファイルがアップロードされます。

    • /opt/elasticbeanstalk/deploy/appsource/ – ここに、00-unzip.sh スクリプトは、デプロイ中にアプリケーションのソースコードをアップロードします (このスクリプトについては プラットフォームスクリプトツール セクションを参照)。

    • /var/app/staging/ – ここで、アプリケーションのソースコードがデプロイ中に処理されます。

    • /var/app/current/ – ここで、アプリケーションのソースコードが処理後に実行されます。

    • /var/log/nginx/healthd/ – ここに、拡張ヘルスエージェントがログを書き込みます。

    • /var/nodejs – ここに、デプロイ中に Node.js ファイルがアップロードされます。

EB CLI を使用して、サンプルプラットフォーム定義ファイルで最初のカスタムプラットフォームを作成します。

カスタムプラットフォームを作成するには

  1. EB CLI のインストール。

  2. サンプルカスタムプラットフォームを展開するディレクトリを作成します。

    ~$ mkdir ~/custom-platform

  3. NodePlatform_Ubuntu.zip をディレクトリに抽出し、展開されたディレクトリに移動します。

    ~$ cd ~/custom-platform
~/custom-platform$ unzip ~/NodePlatform_Ubuntu.zip
~/custom-platform$ cd NodePlatform_Ubuntu

  4. custom_platform.json ファイルを編集し、source_ami プロパティと region プロパティの値を指定します。詳細については、「Updating Packer template」を参照してください。

  5. eb platform init を実行し、プロンプトに従ってプラットフォームリポジトリを初期化します。

    eb platform を ebp に短縮することができます。

    注記

    Windows PowerShell では、コマンドエイリアスとして ebp を使用します。Windows PowerShell で EB CLI を実行している場合は、このコマンドの長い形式 eb platform を使用してください。

    ~/custom-platform$ eb platform init

    このコマンドは、ディレクトリ .elasticbeanstalk を現在のディレクトリに作成し、設定ファイル config.yml をディレクトリに追加します。Elastic Beanstalk がカスタムプラットフォームを作成するときにこのファイルを使用するため、このファイルを変更または削除しないでください。

    デフォルトでは、eb platform init は、現在のフォルダの名前をカスタムプラットフォームの名前として使用します。この例では、custom-platform です。

  6. eb platform create を実行して Packer 環境を起動し、カスタムプラットフォームの ARN を取得します。この値は、後でカスタムプラットフォームから環境を作成する際に必要になります。

    ~/custom-platform$ eb platform create
...

    デフォルトでは、Elastic Beanstalk はカスタムプラットフォームのインスタンスプロファイル aws-elasticbeanstalk-custom-platform-ec2-role を作成します。代わりに既存のインスタンスプロファイルを使用する場合は、eb platform create コマンドに -ip INSTANCE_PROFILE オプションを追加します。

    注記

    Elastic Beanstalk のデフォルトインスタンスプロファイル aws-elasticbeanstalk-ec2-role を使用すると、Packer によるカスタムプラットフォームの作成は失敗します。

    EB CLI には、ビルドを完了するまでは Packer 環境のイベント出力が表示されます。Ctrl+C キーを押すと、イベントの表示を終了できます。

  7. eb platform logs コマンドを使用してエラーがないか、ログを確認できます。

    ~/custom-platform$ eb platform logs
...

  8. 後で、eb platform events によりプロセスを確認できます。

    ~/custom-platform$ eb platform events
...

  9. eb platform status を使用してプラットフォームのステータスを確認します。

    ~/custom-platform$ eb platform status
...

オペレーションが完了すると、Elastic Beanstalk 環境の起動に使用できるプラットフォームが用意されます。

コンソールから環境を作成するときに、カスタムプラットフォームを使用できます。「新しい環境の作成ウィザード」を参照してください。

カスタムプラットフォームで環境を起動するには

  1. アプリケーション用の新しいディレクトリを作成します。

    ~$ mkdir custom-platform-app
~$ cd ~/custom-platform-app

  2. アプリケーションリポジトリを初期化します。

    ~/custom-platform-app$ eb init
...

  3. サンプルアプリケーション NodeSampleApp.zip をダウンロードしてください。

  4. サンプルアプリケーションの抽出

    ~/custom-platform-app$ unzip ~/NodeSampleApp.zip

  5. eb create -p CUSTOM-PLATFORM-ARN (CUSTOM-PLATFORM-ARN は eb platform create コマンドで返された ARN) を実行して、カスタムプラットフォームを実行する環境を起動します。

    ~/custom-platform-app$ eb create -p CUSTOM-PLATFORM-ARN
...

プラットフォーム定義アーカイブのコンテンツ

プラットフォーム定義アーカイブは、アプリケーションソースバンドルのプラットフォームに相当します。プラットフォーム定義アーカイブは、プラットフォーム定義アーカイブ、Packer テンプレート、およびプラットフォームを作成するために Packer テンプレートによって使用されるスクリプトとファイルを含む ZIP ファイルです。

注記

EB CLI を使用してカスタムプラットフォームを作成する場合、EB CLI はプラットフォームレポジトリのファイルとフォルダーからプラットフォーム定義アーカイブを作成するため、アーカイブを手動で作成する必要はありません。

プラットフォーム定義ファイルは YAML 形式のファイルで、platform.yaml という名前でプラットフォーム定義アーカイブの root になければなりません。プラットフォーム定義ファイルでサポートされる必須キーおよびオプションのキーのリストについては、カスタムプラットフォームの作成 を参照してください。

特定の方法で Packer テンプレートに名前を付けるせんが、ファイル名はプラットフォーム定義アーカイブで指定された provisioner テンプレートに一致する必要があります。Packer テンプレートを作成する手順については、公式の Packer ドキュメントを参照してください。

プラットフォーム定義アーカイブのその他のファイルには、AMI を作成する前にインスタンスをカスタマイズするためにテンプレートによって使用されるスクリプトとファイルがあります。

カスタムプラットフォームフック

Elastic Beanstalk は、カスタムプラットフォームで標準化されたディレクトリ構造をフックに使用します。これらはライフサイクルイベント中、および管理オペレーション (環境のインスタンスが起動された、ユーザーがデプロイを開始した、またはユーザーがアプリケーションサーバーの再起動機能を使用した) に応じて実行されるスクリプトです。

フックをトリガーするスクリプトを /opt/elasticbeanstalk/hooks/ フォルダのサブフォルダの 1 つに配置します。

警告

マネージド型プラットフォームでのカスタムプラットフォームフックの使用はサポートされていません。カスタムプラットフォームフックは、カスタムプラットフォーム用に設計されています。Elastic Beanstalk マネージド型プラットフォームでは、プラットフォームによって、動作が異なったり、問題が発生したりすることがあります。Amazon Linux AMI プラットフォーム (上記 Amazon Linux 2) は、場合によっては便利なため、注意した上で使用してください。

カスタムプラットフォームフックは、Amazon Linux AMI プラットフォームに存在するレガシー機能です。Amazon Linux 2 プラットフォームでは、/opt/elasticbeanstalk/hooks/ フォルダ内のカスタムプラットフォームフックは完全に終了しています。Elastic Beanstalk はそれらを読み込んだり実行したりしません。Amazon Linux 2 プラットフォームは、Elastic Beanstalk マネージドプラットフォームを拡張するために特別に設計された新しい種類のプラットフォームフックをサポートしています。カスタムスクリプトおよびプログラムは、アプリケーションソースバンドルのフックディレクトリに直接追加できます。Elastic Beanstalk は、さまざまなインスタンスプロビジョニング段階でそれらを実行します。詳細については、Elastic Beanstalk Linux プラットフォームの拡張 の「プラットフォームフック」セクションを参照してください。

フックは次のフォルダーに整理されます。

  • appdeploy — アプリケーションのデプロイ中に実行されるスクリプト。Elastic Beanstalk は、新しいインスタンスが起動されたときと、クライアントが新しいバージョンのデプロイを開始したときに、アプリケーションのデプロイを実行します。

  • configdeploy — クライアントがオンインスタンスのソフトウェア設定に影響する設定の更新 (たとえば、環境プロパティの設定や、Amazon S3 へのログローテーションの有効化など) を行ったときに実行されるスクリプト。

  • restartappserver — クライアントがアプリサーバーの再起動オペレーションを行ったときに実行されるスクリプト。

  • preinit — インスタンスのブートストラップ中に実行されるスクリプト。

  • postinit — インスタンスのブートストラップの後で実行されるスクリプト。

appdeploy、configdeploy、および restartappserver フォルダには pre、enact、および post サブフォルダがあります。オペレーションの各段階で、pre フォルダのすべてのスクリプトがアルファベット順に実行され、次に enact フォルダ、post フォルダの順に実行されます。

インスタンスを起動すると、Elastic Beanstalk は preinit、appdeploy、postinit の順序で実行します。実行中のインスタンスへのそれ以降のデプロイで、Elastic Beanstalk は appdeploy フックを実行します。ユーザーがインスタンスソフトウェアの設定を更新すると、configdeploy フックが実行されます。restartappserver フックは、ユーザーがアプリケーションサーバーの再起動を開始するときのみ実行されます。

スクリプトでエラーが発生した場合、ゼロ以外のステータスで終了し、stderr に書き込んでオペレーションを失敗させることができます。stderr に書き込むメッセージは、オペレーションが失敗した場合に出力されるイベントに表示されます。Elastic Beanstalk は、この情報をログファイル /var/log/eb-activity.log に取り込み、オペレーションを失敗させたくない場合は 0 (ゼロ) を返します。stderr または stdout に書き込むメッセージはデプロイログに表示されますが、オペレーションが失敗しない限り、イベントストリームには表示されません。

Packer インスタンスのクリーンアップ

Packer ビルダープロセスを完了前に停止するなど特定の状況では、Packer によって起動されたインスタンスはクリーンアップされません。これらのインスタンスは Elastic Beanstalk 環境の一部ではなく、Amazon EC2 サービスを使用してのみ表示および終了できます。

手動でこれらのインスタンスをクリーンアップするには

  1. Amazon EC2 コンソールを開きます。

  2. Packer を使用してインスタンスを作成したのと同じ AWS リージョンにいることを確認します。

  3. [Resources] (リソース) の下で N [Running Instances] (N 個の実行中のインスタンス) を選択します。N は実行中のインスタンスの数です。

  4. クエリテキストボックスをクリックします。

  5. [Name] タグを選択します。

  6. 「packer」と入力します。

    クエリは次のようになります。[tag:Name: packer]

  7. クエリに一致するインスタンスを選択します。

  8. [Instance State (インスタンスの状態)] が [実行中] の場合は、[アクション]、[Instance State (インスタンスの状態)]、[Stop (停止)] の順に選択し、次に [アクション]、[Instance State (インスタンスの状態)]、[終了] の順に選択します。

Platform.yaml ファイルの形式。

platform.yaml ファイルの形式は次のとおりです。

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"

プレースホルダーを該当する値に置き換えます。

version-number

必須。YAML 定義のバージョン。1.0 を指定してください。

provisioner-type

必須。カスタム プラットフォームを作成するのに使用されるビルダーのタイプ。packer を指定してください。

provisioner-template

必須。provisioner-type の設定を含む JSON ファイル。

provisioner-flavor

オプション。AMI に使用する基本オペレーティング システム。次のいずれかです。

amazon (デフォルト)

Amazon Linux。指定されていない場合は、プラットフォームが作成された時点の Amazon Linux の最新バージョンです。

Amazon Linux 2 はサポートされているオペレーティングシステムフレーバーではありません。

ubuntu1604

Ubuntu 16.04 LTS

rhel7

RHEL 7

rhel6

RHEL 6

metadata-maintainer

オプション。プラットフォーム所有者の連絡先情報 (100 文字)。

metadata-description

オプション。プラットフォームについての説明 (2000 文字)。

metadata-operating_system_name

オプション。プラットフォームのオペレーティングシステムの名前 (50 文字)。この値は、ListPlatformVersions API の出力をフィルタリングするときに使用できます。

metadata-operating_system_version

オプション。プラットフォームのオペレーティングシステム のバージョン (20 文字)。

metadata-programming_language_name

オプション。プラットフォームがサポートするプログラミング言語 (50 文字)

metadata-programming_language_version

オプション。プラットフォームの言語のバージョン (20 文字)。

metadata-framework_name

オプション。プラットフォームで使用されるウェブフレームワークの名前 (50 文字)。

metadata-framework_version

オプション。プラットフォームのウェブフレームワークのバージョン (20 文字)。

option-def-namespace

オプション。aws:elasticbeanstalk:container:custom 下の名前空間 (100 文字)

option-def-option_name

オプション。オプション名 (100 文字)。プラットフォームがユーザーに提供する最大 50 個のカスタム設定オプションを定義します。

option-def-description

オプション。オプションについての説明 (1024 文字)。

option-def-default_value

オプション。ユーザーが指定しなかった場合に使用されるデフォルト値。

次の例では、オプション NPM_START を作成します。

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

オプション。オプションの名前空間。

option-setting-option_name

オプション。オプションの名前。Elastic Beanstalk によって提供されるオプションを 50 個まで指定できます。

option-setting-value

オプション。ユーザーが 1 つを指定しない場合に使用されるデフォルト。

次の例では、オプション TEST を作成します。

option_settings:
 - namespace: "aws:elasticbeanstalk:application:environment"
   option_name: "TEST"
   value: "This is a test"

custom プラットフォームバージョンのタグ付け

AWS Elastic Beanstalk カスタムプラットフォームバージョンにタグを適用できます。タグは、AWS リソースに関連付けられているキーと値のペアです。Elastic Beanstalk リソースのタグ付け、ユースケース、タグのキーと値の制約、サポートされているリソースタイプの詳細については、「Elastic Beanstalk アプリケーションリソースのタグ付け」を参照してください。

カスタムプラットフォームバージョンの作成時にタグを指定できます。既存のカスタムプラットフォームバージョンでは、タグの追加や削除、既存タグの値の更新ができます。カスタムプラットフォームバージョンごとに最大 50 個のタグを追加できます。

カスタムプラットフォームバージョンの作成時にタグを追加する

EB CLI を使用してカスタムプラットフォームバージョンを作成する場合は。eb platform create の --tags オプションを使用してタグを追加します。

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

AWS CLI や他の API ベースのクライアントでは、create-platform-version コマンドで --tags パラメータを使用してタグを追加します。

$ 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=DOC-EXAMPLE-BUCKET,S3Key=sample.zip

既存のカスタムプラットフォームバージョンのタグを管理する

既存の Elastic Beanstalk カスタムプラットフォームバージョンのタグを追加、更新、削除できます。

EB CLI を使用してカスタムプラットフォームバージョンを更新する場合は、 eb tags を使用してタグを追加、更新、削除、一覧表示します。

たとえば、次のコマンドでは、カスタムプラットフォームバージョンのタグを一覧表示します。

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

次のコマンドでは、mytag1 タグを更新して 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"

オプションの完全なリストおよび詳細な例については、「eb tags」を参照してください。

AWS CLI や他の API ベースのクライアントでは、list-tags-for-resource コマンドを使用してカスタムプラットフォームバージョンのタグを一覧表示します。

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

カスタムプラットフォームバージョンのタグを追加、更新、または削除するには、 update-tags-for-resource コマンドを使用します。

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

追加するタグと更新するタグを update-tags-for-resource の --tags-to-add パラメータで指定します。存在していないタグが追加され、既存のタグの値が更新されます。

注記

一部の EB CLI と AWS CLI のコマンドを Elastic Beanstalk カスタムプラットフォームバージョンで使用するには、アプリケーションバージョンの ARN が必要です。ARN を取得するには、次のコマンドを使用します。

$ aws elasticbeanstalk list-platform-versions

出力をフィルタリングしてカスタムプラットフォームの名前に絞り込むには、 --filters オプションを使用します。