🐳

ALB + ECSの動的ポートマッピングでローリングアップデートをする

2022/12/04に公開

ローリングアップデート

ECSでローリングアップデートを行う場合
Desired countと、Minimum percent、Maximum percentを
設定する必要がある。

最低50％まで減少し、最大100％まで増加する。
一気に新しくなるのではなく、50％まで縮小し、徐々に入れ替わっていく。

最低でも100%は維持し、最高200%まで増加する。
一気に新しいコンテナをデプロイすることができるが、
その分のリソースが必要となる。

ALBを作成するときに

ターゲットの登録でEC2インスタンスの登録は行わない。

あとでコンテナを起動した際に、ALBが自動で登録してくれる。

ECSのホストポートを0に指定する。

(今回コンテナポートは3000を使用している)

そうすることでホストポートは
コンテナインスタンスの一時ポート範囲から動的に選択される。
(最新のAmazon ECS-optimized AMIでは32768-61000)

Desired count:4 min:50% max:100%で設定する。

ECSのサービス登録時に、作成したALBを設定する。

動的に付与されたポートが、ターゲットグループに登録されている。

初めはホストポートを明示的に80としていた。

codepipelineでタスク定義を更新してデプロイすると
既に80が使用されている というエラーとなってしまい
ローリングアップデートができなかった。

だが、80ポートでローリングアップデートする方法があった。

ECSのMinimum percentを0％、Maximum percentを100％に設定する。

そうすれば80ポートで稼働するコンテナが存在しても、
デプロイ時に0％となるのでローリングアップデートは可能となった。

だが、これだとダウンタイムが発生してしまう。
コンテナがデプロイされるまでの間にアクセスされた場合
503となるので、この方法は現実的に不可能である。

複数コンテナを起動することができたが
ALBのヘルスチェックがunhealthyとなってしまう。

EC2のパブリックIPに該当ポートでアクセスすると表示できるのに、
ALB経由(ドメイン)でアクセスすると503となる。

直前にベーシック認証を設定したため、
ALBが200を返していないのかと思ったが
ベーシック認証を外してもunhealthyとなってしまう。

単純に、ホストポート(32768-61000)を
セキュリティグループのインバウンドに設定し忘れていた。

くだらないミス。