ELB の背後にアプリケーションの新しいバージョンをデプロイする場合、AWS にメンテナンス ページをどのように配置しますか? 新しい自動スケーリングされたインスタンスが起動している間、ELB がトラフィックをメンテナンス インスタンスにルーティングし、完全に起動したときにのみ新しいインスタンスに「切り替え」たいと考えています。自動スケーリングを使用して、既存のインスタンスを停止し、新しいコードを持つ新しいインスタンスを起動します。
私たちが回避しようとしているシナリオは、ELB が新しい EC2 インスタンスへの両方のトラフィックを処理すると同時に、メンテナンス ページも処理することです。スティッキー セッションを有効にしていないため、ユーザーがメンテナンス モードのページと EC2 インスタンスにデプロイされたアプリケーションの間を行き来するのを防ぎたいと考えています。また、コードの変更にはデータベースの変更が含まれる可能性があるため、新しいインスタンスを導入するために単純にスケールアップ (2 から 4 のインスタンスから 2 に戻すなど) することはできません。
I realise this is an old question but after facing the same problem today (December 2018), it looks like there is another way to solve this problem.
Earlier this year, AWS introduced support for redirects and fixed responses to Application Load Balancers. In a nutshell:
text/plain or text/html response (i.e. your maintenance page HTML).Once the rule propagates to the ELB (took ~30 seconds for me), when you try to visit your host in your browser, you'll be shown the 503 maintenance page.
When your deployment completes, simply remove the rule you added.
AWS で最も簡単な方法は、DNS サービスであるRoute 53を使用することです。
Weighted Round Robinの機能を使用できます。
「WRR を使用して、サーバーを運用環境に導入したり、A/B テストを実行したり、さまざまなサイズの地域やデータ センター間でトラフィックのバランスを取ったりすることができます。」
編集: Route 53 は最近、S3 への DNS フェイルオーバーを可能にする新しい機能を追加しました。詳細については、ドキュメントを確認してください: http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover.html
Route53 は、この問題の適切な解決策ではありません。DNS エントリの有効期限が切れてからメンテナンス ページが表示されるまでには、かなりの時間がかかります (メンテナンスの完了後に更新されるまでには、同じ時間がかかります)。この質問がされた時点では Lambda および CodeDeploy トリガーが存在しなかったことは認識していますが、Lambda を使用してこのための比較的クリーンなソリューションを作成できることを他の人に知らせたいと思いました。これについては、ブログ投稿 http: //blog.ajhodges.com/2016/04/aws-lambda-setting-temporary.html
解決策の要点は、Lambda 関数を CodeDeploy イベントにサブスクライブすることです。これにより、ASG が、デプロイ中にロード バランサーの静的ページを提供するマイクロ インスタンスに置き換えられます。