基本的に、セットアップでは、AMI と一連の EC2 開始パラメーター (起動構成 (インスタンス サイズ、ユーザーデータ、セキュリティ グループ、リージョン、アベイラビリティ ゾーンなど)) を登録します。また、スケーリング ポリシーもセットアップします。
- スケーリング トリガーが起動します
- ポリシーを調べて、どの起動構成が適用されるかを判断します
- ec2 run インスタンスは、登録された AMI と起動設定パラメーターを使用して呼び出されます。
この時点で、AMI と起動設定の組み合わせであるインスタンスが開始されます。それ自体を IP アドレスで AWS 環境に登録します。
最初の起動 (ec2config または ec2run によって実行 - ここではメモリから) の一部として、新しく起動するインスタンスはインスタンスのメタデータに接続し、「userdata」に保存されているスクリプトを実行できます。このスクリプトは、ソフトウェアのインストール、オペレーティング システムの構成、設定など、スクリプトで実行できるすべてのことをブートストラップできます。
完了すると、新しく作成されたインスタンスが得られます。
ここで、このプロセスが auto-scale と Elastic-load-balancing によって開始された場合、インスタンスが「Windows の準備ができている」(ec2config.log を確認) の時点で、ロード バランサーはインスタンスをそれ自体に追加します。リクエストに応答すると、正常とマークされ、ELB がトラフィックのルーティングを開始します。
ゴールド スタンダードは、汎用 AMI を用意し、ブートストラップ スクリプトを使用して、すべてのパッケージ / msi / gem または必要なものをサーバーにインストールすることです。しかし、よくあることは、人々がゴールデン イメージを構築し、その AMI をスケーリング用に登録することです。
後者の方法の欠点は、すべてのリリースで新しい AMI を作成し、起動構成を更新する必要があることです。
もう少し情報が得られることを願っています。