はじめに
この記事は 『PERSOL PROCESS & TECHNOLOGY Advent Calendar 2020』 の23日目の記事です。
今年もこの時期がやってきましたね。
現在 AWS re:Invent がオンラインで開催中ですね。最近は影響の大きい変更がサービスに入った際にはTwitterのトレンドに載るなど、クラウドインフラに興味を持たれている方が増えてきて嬉しい限りです。
さて、今回はそんなre:Inventの内容ではなく、タイトルにもあるんですが今から1ヶ月前にリリースされたAWS Fargate(ECS)のアップデートの中で個人的に嬉しかったものの紹介とその実現方法を解説しようと思います。
目次
- さくっと
- なにが良くなったのか
- 技術検証時に困ったこと
- 終わりに
本編
さくっと紹介
s3にアップロードしたenvファイルをECS on Fargateで引いてくることができるようになりました。
envファイルの形式は至って単純で、以下の形式で記述するだけです。
# コメントもかけて可読性up
VARIABLE=VALUE
ENVIRONMENT=develop
これをs3バケットにアップロードし、アップロードしたファイルのArnをコンテナの Environment Files にコピペします。
envファイルの設定は以上で、タスクを更新すると次回からs３の環境変数ファイルを参照しにいってくれます。非常に簡単ですね。
なにが良くなったのか
今までECS on Fargateで環境変数をアプリケーションの外部で設定する基本的な方法は、コンテナの環境変数として設定することが主流だったかと思います。
最初のうちはかわいいもんですが、開発を続けていると気がつけばこのような形で環境変数がすごいことになります。(途中から面倒になりました)
またこちら運用時のタスク定義が1つなら良いんですが、5個10個と増えていくと環境変数の追加や修正に割とばかばかしい時間がかかります。
もし本番環境で新バージョンをデプロイしました、でも環境変数の更新を忘れました。なんてことになったら障害が起きちゃうんですよね。
今回のアップデートで上記の問題は解消されたと言えます。
環境変数の追加・修正が大変
envファイルの更新だけで済みます(※もちろんタスクの更新は必要ですよ。)
たくさんあるタスクの環境変数の更新が大変
一つのファイルで複数のタスクが参照できるので、ひとまとめに書いてしまえばenvファイル一個の更新で済みます。
注意して欲しいのがこちらのドキュメントにもあるのですが
コンテナ定義に environment パラメータを使用して環境変数が指定されている場合は、環境ファイルに含まれる変数よりも優先されます。
なので、すでにコンテナの環境変数を使用されている場合は、envファイル利用に切り替える際には今まで使っていたコンテナの環境変数を消してあげる必要があります。同じ環境変数を使い続ける場合でも古い変数を参照してしまうことがないように整理はしてあげた方が良さそうですね。
技術検証時に困ったこと
自分で検証を行った時2回程軽く詰ったので共有しておきます。
s3アクセスを許可するIAM policyはタスクロールではなくタスク実行ロールに追加する。
今回のファイルアクセスには以下の二つのポリシーが必要です。
- s3:GetObject
- s3:GetBucketLocation
またこちらはECSのサービス作成時(だったかな？)に設定するタスクロールではなく、タスクの実行ロールというものに付与する必要があります。
デフォルトでは ecsTaskExecutionRole という名前で生成されていると思うので、ドキュメントの内容に沿ってIAM policyをセットしてやるとアクセスに必要な権限を付与することができます。
ルーティングを通す。
当たり前のことですが、ルーティングのエラーなんて出ないもんで10分くらい首を傾げてました。
つまりはタスクに設定したsubnetからs3バケットへアクセスするためのVPCエンドポイントへのルーティングを通そうねということです。簡単なことですが見事に足下をすくわれましたね！！
終わりに
今回のアップデートは環境変数ファイルの他にも ポジティブなToriさんがTwitterで詳しく説明をしてくれています。
環境変数の詳しい内容については 『環境変数の指定』 に載ってあります、是非ご参照ください。
急ぎ足で説明させていただきましたが、今回の記事は以上になります。
それでは よきコンテナライフを。