全体として、これは欠けている機能であり、AWS は将来的にファーストクラスのサポートを提供する必要があるか、より明確で首尾一貫したファーストクラスのサポートを提供する必要があると思います—<a href="https://docs.aws.amazon.com/elasticbeanstalk /latest/dg/command-options.html" rel="nofollow noreferrer">保存された構成は、EB オプションの設定とリソース (追加のカスタム インフラストラクチャ) に役立ちますが、インスタンス上のコマンドとその区別を含めることができるとは思えません。また、優先度 from.ebextensions
は、チームが理解しなければならない厄介で紛らわしいものです (.ebextensions
ファイルまたは保存された構成のいずれかでリソースと設定を定義できます…)。EB は明らかに 1 つのアプリケーションが複数の環境を持つように設計されているため、その.ebextensions
認識の欠如が目立ちます。
@yacc のようなソリューションは、環境間のスクリプトの小さな違いに要約される状況で実行可能であり、OP の質問には十分かもしれません。ただし、煩雑になり、オンインスタンス コマンドの代わりにEB 構成とカスタム リソースにはまったく役に立ちません。たとえば、多数のカスタム CloudWatch メトリクスまたはマルチインスタンス ElastiCache クラスターを本番環境のみで有効にしたい場合などです。またはワーカー環境ですが、ステージングは対象外です。
そのために、保存された構成が役立ちます。
$ eb config save staging
$ cp .elasticbeanstalk/saved_configs/{staging,production}-sc.cfg.yml
# Add production-specific option settings, resources, etc.:
$ $EDITOR .elasticbeanstalk/saved_configs/production-sc.cfg.yml
# Save the config to S3:
$ eb config put production --cfg production-sc
# Apply the config to the environment:
$ eb config production --cfg production-sc
機密性の高い環境変数の値など、保存された構成から秘密をすべて削除.elasticbeanstalk/saved_configs
し、将来的に環境を再現できるようにソース管理をチェックします。(この [便利な] 記事は、ファイルを のルートに移動することが、CLI の慣例.elasticbeanstalk/
にとって好ましいことを示唆しています)。.gitignore
もちろん、ステージングのコピーから開始する代わりに、Web コンソールで初めて運用環境のセットアップを行い、それを保存して変更することもできます。
リソースのCloudFormation 条件関数.ebextensions
を使用して、ファイル内でこれの一部を達成することも可能かもしれません。まだ試していませんが、EB が CloudFormation に与える入力パラメーターを見つける機会があれば、回答を更新します(のように動作します)。 AWSEBEnvironmentName