AWS EC2ホスト名が変更または増加したときにnginxアップストリームサーバーリストを自動的に更新する方法は？

AWSで自動スケーリングを設定したい。Elastic Load Balancerを使用したくありません。

Amazonの自動スケーリングは、パフォーマンスの維持のために需要の急増時にEC2インスタンスをシームレスに作成し、需要の停滞時には自動的に減少してコストを最小化します。

このEC2インスタンスは自動的に作成されるため、ホスト名はNGINXに認識されません。

10のEC2インスタンスへのnginxのアップストリームセットアップを知っています。

自動スケーリングがEC2インスタンスを追加/更新/削除するときに、上流のnginx構成にサーバー名を自動的に追加/更新/削除できるようにしたいと思います。

これは、SNS、EC2、およびAutoscalingサービスを利用して、Amazon SDKを使用して達成できます（ほぼ完成しました。githubに配置します）。

これを達成するために、次の手順を実行しました。

1. HTTP通知を有効にし、Webサーバーを購読します。
2. サーバーを終了するための自動スケーリンググループに、1分のハートビート（終了する前に1分間待つ）のライフサイクルフックを追加しました
3. メッセージを解析してそれがどのような種類のメッセージであるかを検出するためのインデックスファイルを作成しました（つまり、起動または終了）
4. イベントのタイプが決定したら、インスタンスのプライベートIPを取得するためにEC2を照会しました
5. 起動の場合、ヘッダー200が受信されるまで待機してから、nginx configにIPを追加してリロードします
6. Terminateの場合、構成からIPを削除し、nginxをリロードします

ここでスクリプトを見つけてくださいhttps://github.com/singhupendra/aws-autoscale

@talonxに感謝します。いくつかの調査を行いました。AmazonAutoscaleには、現在の自動スケーリンググループのステータスを照会し、そのメンバーを列挙するapiがあります。インスタンスID（http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/api_requests.html#query-example）を返します。その後、記述ツールを使用してサーバー名を取得できます（http：// docs .aws.amazon.com / AWSEC2 / latest / CommandLineReference / ApiReference-cmd-DescribeInstances.html）、最後にアップストリームインクルードファイルを再作成します。自動スケーリング通知を感知して、これらのタスクを実行するプロセスを起動できました。

私はまだそれを実装しませんでしたが、その方法です。

SNS http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/ASGettingNotifications.htmlで Autocalingを使用することもできます。

私はまだこれを実装していませんが、NGiNX Plusのオンザフライ再構成の使用を検討しています。AMI、またはAuto Scaling Groupインスタンスを設定する構成管理（Puppet、Saltなど）がNGiNX再構成APIに到達する可能性があると考えています（おそらく、内部Route53ドメイン名を介して、固定IPはありません）使用する必要があります）、リバースプロキシのアップストリームクラスタに自分自身を追加します。その後、NGiNXのビルトインヘルスチェックがその[追加された]インスタンスを引き継ぎ、利用できなくなった場合にドロップします。これは最もクリーンなソリューションと思われ、インスタンスの追加に遅延はありません。NGiNXPlusは帯域外ヘルスチェックを備えているため、インスタンスの削除に遅延はほとんどありません。

このアプローチにより、自動検出システム（Consul、Serfなど）をセットアップする必要がなくなります。これは、小規模なセットアップの場合、セットアップ/管理および必要なEC2インスタンスの両方で多くのオーバーヘッドのように思われます。たとえば、Consulは、安定するために最低3つのインスタンスを必要とします。SerfはおそらくASGインスタンス自体で実行できますが、それを維持するためのオーバーヘッドがまだあり、ASGが1つまたは2つのインスタンスに縮小すると、クォーラムが失われます。

最後に、これは、おそらくロードバランシングに使用されるNGiNXサーバーで、Auto Scaling Groupの変更の自動通知と組み合わせることができます。そのような通知（これはUpendraが参照することもあります）によってトリガーされたリスナーは、On-the-fly変更APIを介して新しいインスタンスをNGiNXに即座に追加できます。NGiNX Plusのコストに加えて、そもそもなぜ多くの問題があるElastic Load Balancerを使用するのか不思議に思われます。

編集2015-12-07：ngx_openrestyのバランサーバイルア（このGitHubスレッドを参照）は、NGiNXアップストリームグループからサーバーをホットアド/削除するための別の可能なオープンソースソリューションを提供します。私はまだこれを実験していませんが、この投稿に出くわした人のためにここに言及を追加したかったです。