0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

AWS ECSでコンテナアプリを動かす:ECSを作成しアプリ公開まで

0
Posted at

目次

  1. 前回の記事
  2. ECSについて
  3. 本記事での前提
  4. クラスター作成
  5. タスク定義作成
  6. サービス作成
  7. ECSタスクへアクセス
  8. オートスケーリング設定
  9. 注意:セッション管理で発生した問題

1. 前回の記事

前回の続きからECSを構築していく

2. ECSについて

本記事では、ECRで管理されているイメージをECSで動かすための手順について記載する。

Q. ECSとは?

Elastic Container Service
コンテナを動かすためのサービス
4つの要素があり、階層的に管理されている
image.png

なお、類似するサービスでEKSが存在するが、今回は動かすシステムの規模を考慮して触れない

Q. KubernetesとEKS(Elastic Kubernetes Service)とは

Kubernetesは複数のコンテナを管理・連携させて動作させるためのツール
大規模なシステム向けとなり、EKSはKubernetesを使うためのサービス

3. 本記事での前提

今回は以下を例として、ECS以外の構築はすべて完了している前提で進める
image.png
(詳細はこの記事を参照:【計画】AWS ECS(CaaS)構成でWebアプリを構築する

それでは次章から具体的な構築を進める

4.クラスター作成

以下の画面でクラスターの作成を始める
image.png

基本はデフォルト通り入力し、インフラストラクチャがFargateになってることだけ注意する
image.png

Q. Fargateとは?

コンテナをサーバーレスで実行する環境
ほかの実行環境ではEC2(サーバー有)が存在するが、今回はサーバー管理をする理由はないためFargateにする

作成ボタン押下後、クラスターが作られている
image.png

5. タスク定義作成

クラスターの次にタスクを定義する
ロールを指定する必要があるため、事前にロールを作成する

ロール作成

ECSのタスク用に"タスクロール"と"タスク実行ロール"を作成する

Q.タスクロールとタスク実行ロールの違い

タスク実行ロール:コンテナを「起動するための権限」
タスクロール:コンテナ内の「アプリが使う権限」

それぞれでユースケースとポリシーを設定する

Q. ユースケースとポリシーとは

ユースケース:誰がこのロールを使うか
ポリシー:何をしていいのか(権限)

●タスク実行ロール作成

IAMでロールを開き、作成ボタンを押す
image.png

タスク用の権限のため、信頼されたエンティティのユースケースでECSのTaskを指定する

image.png

許可の追加では、以下を指定する

  • AmazonECSTaskExecutionRolePolicy
    ECSがコンテナを起動するために必要な最低限の権限セット
  • AWSSecretsManagerClientReadOnlyAccess
    SecretsManagerを参照する用の権限

image.png

最後にロール名を指定し、完成
image.png

●タスクロール作成

タスクロールでも信頼されたエンティティではECSのTaskをユースケースに指定する

許可は以下二つ

  • AmazonSSMManagedInstanceCore
    Systems Manager(SSM)を利用するための権限
  • SecretsManagerReadWrite
    Secrets Manager内のシークレットを参照・更新するための権限

許可を設定後名前を記入し完了
image.png

タスク定義作成

新しいタスク定義の作成を押下する
image.png

今回は以下の設定で作成した
image.png
image.png

image.png
image.png

特筆事項

  • 起動タイプはAWS Fargate

  • 条件付きタスクロールに、先ほどのロールを付与する

  • コンテナのイメージURIには、前回作成したECRイメージを選ぶ
    image.png

  • 環境変数には、SecretsManagerで指定したキーと値を指定する
    image.png

  • ログ収集はデフォルト設定にする

設定を完了し作成する
image.png

これでタスク定義の作成が終わり、コンテナ設定も作成される
次はサービスを作成していく

6.サービス作成

ECSのクラスターを開き、サービスを作成する
image.png

次の設定で進める
image.png
image.png
image.png
image.png

特筆事項

  • 冗長化するため、必要なタスクは2にする
  • ネットワーキングでは、別のAZに存在するPrivateサブネットを2つ指定する
  • インターネットに公開しないのでパブリックIPはオフ
  • ロードバランシングでターゲットグループを指定すると、その中にタスク用のIPアドレスが登録され、リスナーによってHTTP通信が転送されるようになる(別途、ALB等の設定は必要)

ヘルスチェックについて

サービスを作成すると、ターゲットグループのヘルスチェックが始まる
詳細はターゲットグループのページから見れる
image.png

内容について
30秒間隔で/loginパスにHTTPアクセスし、200コードが返るか確認する

  • 5連続成功:正常と判断
  • 2連続失敗:非正常と判断

Q. なぜ/loginを指定するのか

アクセスするのにセッション情報を必要とする場合、成功コードを取得できない
そのため初期ページを指定した

動作確認

ここまでのECSの設定で、実際にWeb公開まで可能になる
image.png

※HTTPS・ドメイン付与はほかの設定が必要(以下参考記事)

ここから先はWeb公開の手順以外で、別途対応・確認した内容になる

7. ECSタスクへアクセス

Cloud Shell(ECS Exec+SSM経由)でECSタスクへアクセスできるようにする
まずは、ECSサービスを更新し、ECS Execを有効化し、再デプロイする
image.png

その後、ECSタスクからコンテナを選択し、接続ボタンを押下する
image.png

これでCloud Shellが開きアクセスできるようになった
image.png

RDSへのアクセスなどの場面で利用する

8. オートスケーリング設定

CPU使用率に応じて、タスク数を自動で増減できる設定を追加する

サービス画面の"サービスの自動スケーリング"を見て、"タスクの数を設定"を押す
image.png

開いたページで、タスク数の最小と最大を設定する
image.png

次に、スケーリングポリシーを設定する
image.png

今回は以下の内容で作成し、CPUの使用率70%をしきい値としてタスク数を増減させる
image.png

作成後CloudWatchを見ると、スケーリングログが確認できる
image.png

9. 注意:セッション管理で発生した問題

タスク数を2にしたら、セッション情報の保持で次のような問題が出た

タスクAでログインしセッション情報が保存される
↓
別ページへの遷移時、タスクBが割り当てられる
↓
タスクBにはログインセッションがないからログインページに戻される

対策として、ターゲットグループで維持設定を有効にしたところ、問題は解決した
image.png

Q. 解決した理由は?

同一ユーザーを同一タスクへ振り分け続けるようになったため
・セッション:ログイン情報等を保持し、タスク側で管理
・Cookie:セッションIDを保持、ブラウザで管理
ログイン時、ブラウザはCookie内のセッションIDを用いてセッション情報を参照する。しかし今回は、タスクごとにセッション情報が分かれていたため、別タスクへ通信されるとログイン情報を参照できなくなっていた。先ほどのチェックを有効化したことで、同一ユーザーが同一タスクへ継続して振り分けられるようになる。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?