AWS Elastic Beanstalk を使用したアプリケーション ロード バランサー - 対象グループ

AWS Elastic Beanstalk を使用したアプリケーション ロード バランサー - 対象グループ

私はアプリケーション ロード バランサAWS エラスティック ビーンズトーク

AWS の自動サーバー更新後、503 Service Temporarily Unavailable ページが表示されました。(サーバー負荷がほぼゼロで、これだけです - 単一インスタンス)

[64 ビット Amazon Linux/2.9.2 で動作する PHP 7.3 (2.9.1 から自動的にアップグレード)]

環境自体は健全であることが示されました。

HTTPS と将来のスケーリングのために Application Load Balancer を使用しています。

AWS EB が新しい EC2 インスタンスを作成し、以前のインスタンスを終了したため、Application Load Balancer が誘導するターゲット グループにインスタンスが登録されていなかったことが判明しました。

代替のElastic Beanstalk EC2インスタンスをAWSに設定するにはどうすればいいですか?ターゲットグループに自動的に登録されますアプリケーション ロード バランサー用ですか?

答え1

これは少し前のことですが、Auto Scaling グループのターゲット グループ セクションに適切なターゲット グループを追加するとうまくいったようです。

EC2 コンソールに移動し、左側のメニューの一番下 (少なくとも現時点では) に Auto Scaling グループがあります。リストから Auto Scaling グループをクリックし、[詳細] タブで [編集] をクリックして、該当するターゲット グループを追加します。

これにより、インスタンスが変更されても同期が維持されるようです。

つまり、次のようになります。スクリーンショット

答え2

私もまったく同じ問題に直面しました。1 日 Google で検索してさまざまなアプローチを試した後、最終的に次のディレクティブを含むスクリプトを .ebextensions ディレクトリに追加しました。

container_commands:
   01_register_ALB_target:
    command: "aws elbv2 register-targets --region us-east-1 --target-group-arn arn:aws:elasticloadbalancing:us-east-1:xxxxxxxx:targetgroup/xxxxx/xxxxx
--targets Id=$(curl -s http://169.254.169.254/latest/meta-data/instance-id)"

正直に言うと、実際のクラッシュと再起動の状況でこれが完璧に機能するかどうかは 100% 確信していません。たとえば、以前のインスタンス ID をターゲット グループから削除する努力はしていません (少なくともしばらくすると自動的に削除されると思います)。ただし、コマンドはデプロイメント中に確実に実行され、インスタンスがすでにターゲットに登録されている場合は害はないようです。

見る:詳しくは、こちらを参照してください。

関連情報