ECS のローリング アップデートを DAEMON モードでテストしてきましたが、時折発生する「502 Bad Gateway」応答を回避できません。これは、排水戦略プロセスのバグを指しているように見えるこれをテストするために行ったことです。
まず、curl GET ( source ) に応答する最小限の hello-world プログラムを Kotlin/Jersey で作成しました。300 ミリ秒ごとにループでエンドポイントにヒットします。
while [ 1 ]; do curl -s http://...us-east-2.elb.amazonaws.com/helloWorld | ts '[%Y-%m-%d %H:%M:%S]'; echo ""; sleep 0.3; done
次に、ロールアウトの進行状況を観察できるように、わずかに異なる応答 (110 と 1010) を生成する新しいコンテナー イメージを (同じタグを使用して) プッシュします。最後に、次のコマンドでサービスの更新を強制します。
aws ecs update-service --service service-helloworld-jersey --cluster cluster-helloworld-jersey --force-new-deployment
サービスには 2 つのタスクがあり、Minimum health percentには 50% があります。Bash ループは、ローリング更新中に次の出力を生成します。ある時点で、「110」(古いコード) と「1010」(新しいコード) の 2 つの出力があります。これは、コンテナーの 1 つが更新され、もう一方はまだ更新されていません:
Bash コンソールのイベントを AWS コンソールのイベント (どちらも NTP 時刻同期) と関連付けると、9:04:39 頃に「ドレイン」にもかかわらず、古いコード/コンテナーにヒットしていることがわかります。 9:04:28 以降に発生したと思われるイベントを、以下で赤くハイライトしました。9:04:39 に、ループ内の「502 Bad Gateway」応答と相関するタスクが最終的に停止されます。
私の結論は、ELB が最後のターゲットを正しく排出していないため、表示されるエラーが発生するということです。
これをさらに診断する方法や別の方法で構成する方法について誰かが考えている場合は、お知らせください。
ELB の登録解除の遅延を 10 秒から 30 秒に増やすことで、サービスの中断を回避することができました。
