【衝撃に備えろ】Fargate PV1.4のVPCエンドポイント変更点について

こんばんわ、札幌のヨシエです。(亜人大好きです、よつばと！と同じぐらい好きです)

コンテナ業界盛り上がってますね、中でもFargateのプラットフォームがアップデートされ様々な新機能が追加されてます。
挙げるとキリがないですがFargate PV1.4からコンテナエンジンがDockerからcontainerdに切り替わり、様々な変更が加えられております。
詳しくは↓をご確認ください。

その中でFargate(PV1.4)の発表があった時は「あーはいはい、中身が変わるんですね。わかりました。まぁコンテナホストのバージョンが上がってもコンテナが起動することだけ確認すれば良さそうっすね」と考えておりましたが、 AWSドキュメントに以下の記載を確認しました。

• Fargate 起動タイプおよびプラットフォームバージョン 1.3.0 以前を使用する Amazon ECS タスクでは、この機能を活用するために必要なのは com.amazonaws.region.ecr.dkr Amazon ECR VPC エンドポイントおよび Amazon S3 ゲートウェイエンドポイントのみです。

• Fargate 起動タイプとプラットフォームバージョン 1.4.0 以降を使用する Amazon ECS タスクでこの機能を使用するには、com.amazonaws.region.ecr.dkr と com.amazonaws.region.ecr.api Amazon ECR VPC エンドポイントの両方、および Amazon S3 ゲートウェイエンドポイントが必要です。

Amazon ECR VPC エンドポイントに関する考慮事項

以前にFargateのVPCエンドポイントを整理した時、ecr.apiは設定せずに使えておりましたが、Fargate(PV1.4)からはecr.apiが必要とのことでした。

ここで「もし、ECSのサービス設定でFargateプラットフォームバージョンがLatestとなっている環境で、VPCエンドポイントを利用したコンテナ環境が1.4に上がるとどうなるのだろう？」という懸念が出てきましたので試してみました。

※本日時点でLatestを確認したところ、Fargate(PV1.3)で起動しました。

まずは以前と同じようにプライベートサブネットでFargate(PV1.3)を使ってコンテナを起動します。 VPCエンドポイントは以前に紹介した3つのエンドポイントのみを指定します。

ちゃんと以下のようにコンテナが起動しました。

それでは次にVPCエンドポイントを変更せず、「サービスの更新」からFargate(PV1.4)に変更、強制デプロイを実施してみます。

ステータスが「PENDING」になりますが... 「STOPPED」になってしまいました。

要因を見てみると、レジストリ認証を取得できない旨のメッセージが表示されます。

それでは今回気になった、ecr.apiエンドポイントを追加してみます。

無事、Fargate(PV1.4)でも起動することが出来ました。

最後に

今回のFargate PVバージョンアップはおそらくは内部のアーキテクチャが変わったこともあってこのような変更が出ているものと考えられます。 個人的にはEC2と同様のVPCエンドポイントが必要になったことで、トラブルシュートなどでVPC変更を行わずにFargate→EC2にホストを切り替えて、docker execによる調査が出来るようになるので 対応しやすい構成になるのではと思いました。

また、ECSで管理されているコンテナ環境はログの外だしなどのアーキテクチャを取られているハズなのでデプロイやコンテナの起動停止が容易に行えることからLatestバージョンが切り替わることで
今回確認したようなVPCエンドポイントが足りないことでコンテナが起動しない可能性が高くなります。

バージョンが上がることで飛躍的に我々がやりたいことを実現させてくれるFargateなので、こういったところで躓かないように注意しましょう。