メインコンテンツまでスキップ

Amazon ECS (Elastic Container Service)

コンテナー化されたアプリケーションのデプロイメント・管理・およびスケールアップを行うためのフルマネージドサービス。
aws上でいい感じにdocker pull（ECRから）して、docker runしてくれる感じ。

特徴​

  • Dockerと互換性があります。
  • タスクとサービスの概念を提供して、アプリケーションのコンポーネントを管理します。
  • タスク定義を使用して、コンテナーのセットを指定します。
  • サービスを使って、タスクのセットを維持・スケーリングできます。
  • Fargateというサーバレスコンピューティングエンジンを提供しています。これを使用すると、インフラストラクチャの管理を気にすることなく、コンテナーを直接実行できます。

ECSがない場合の運用docker​

今まではEC2上にdocker engineをインストールして、その上でコンテナーを管理するという方法だった。
この場合、コンテナーごとにポート変えないといけなかったり、コンテナーで何かしら不具合起きたら ssh でログインして原因特定して治して、起動し直さないといけなかったりしないといけなかった。
また、アクセス集中してサーバー台数増やす時にまた環境構築しないといけなかったり、何かと監視が必要になってくる。

そこでECSの出番となる。
ECSでは上記のような問題をすべて解決してくれる。ポートマッピング、コンテナーの状態の監視、自動復旧などをおこなってくれる。

ECS関連の単語​

Cluster(クラスター)​

タスクやサービスを使う論理的なグループ。
コンテナーを動かすEC2やfargateの集合体のことをいう。
クラスターはリージョン固有の存在で跨ぐことはできない。

Service​

Taskをまとめて管理するもの。同じサービス内で起動しているTaskは同じTask Definitionからできている。
サービスはタスクの集まりを表し、タスクの数や更新方法、配置戦略などを定義する。
タスク定義とサービス定義を関連付けることにより、コンテナーを実行する。

Task Definitionとは​

ECSでコンテナーを起動するための情報を記載したもの。

  • どのimageでコンテナー起動するのか
  • cpuとメモリはどうするのか
  • portはどうするかとか
  • コンテナーが終了したり失敗した時に起動し直すのかどうかとか設定する。
    ※docker-compose.yml的な立ち位置でdocker-compose.ymlファイルでタスク定義ができる。

Taskとは​

Task Definitionを元に起動した各コンテナー（またはコンテナーの集まり）のこと。 Railsでよくあるコンテナーの構成で例えるなら、appで1タスク、nginxで1タスク、dbで1タスクみたいなイメージ。

Fargateとは​

Fargateはサーバーの管理が不要なコンテナー向けのサーバーレスコンピューティングエンジン。EC2を利用した場合、自分でサーバーを起動してecs起動してと言うことをしていたが、Fargateを利用した場合は、ECSのServiceの状態によってTaskを自動的に起動したり終了したり、設定によってTask数を増やしたり減らしたりといったことを自動でしてくれる。EC2では起動していた分だけ課金されるが、Fargateの場合はリソースに対しての従量課金となっているため、コスパがいい。

環境変数の渡し方​

参考URL

ECSコンテナーには3つの方法で環境変数を渡すことができる

  1. ベタ書き
  2. S3からインポート
  3. パラメーターストア/Secrets Managerからインポート

2について
S3からインポートする方法は、S3バケット中のオブジェクトのパスを指定してenvファイルから変数を設定する方法。
ファイル中に複数の変数名と値を指定して一括でECSに読み込むことが可能

3について
パラメータストア/Secrets Managerからインポートする方法は、SSMパラメータストアもしくは、Secrets Managerに値を設定しておき、環境変数名に対応したパスやARNをECSに設定することで値を取得します。 パスワードなどの直接書き込むべきでない変数をセキュアに渡す際に活用できます。

パラメーターストア​

パラメータストアの値に関しては同じリージョンならパスかARNで、異なるリージョンならARNで取得可能。

Secrets Manager​

Secrets Managerの値はARNで取得が可能。

ecspresso(エスプレッソ)​

参考URL

AWS CDKを使用してリソースをプロビジョニングすると、ecspresso のようなCLIツールは必須ではありません。
しかし、ecspresso を使用すると、開発者はより簡単にデプロイ、ロールバック、スケーリング、ログの取得などの作業を行うことができます。
とくに、以下のような場合に ecspresso が役立ちます：

  1. デプロイの簡略化: CDKスクリプトをデプロイするために、毎回 cdk deploy を使用する代わりに、ecspresso を使って既存のECSサービスを簡単に更新できます。
  2. 運用とトラブルシューティング: ECSタスクのログを取得したり、サービスの状態を確認したりする作業を ecspresso を使って簡単に行えます。
  3. 設定管理の簡略化: ecspresso は設定ファイルを使用するため、多くの設定を事前に定義できます。これにより、コマンドラインでのオプション指定の手間が省けます。
  4. 環境間での設定の共有: 環境間での設定の共有が簡単になります。これは、設定ファイルをソースコントロールに入れることで達成できます。
  5. 迅速なフィードバック: ecspresso を使うと、ECSの状態やデプロイの進行状況に関するフィードバックを迅速に得ることができます。

ただし、CDK自体もCLIで操作できるため、開発時や初期のセットアップ時にCDKを使用し、ecspresso を運用フェーズで利用するという方法もあります。
また、CDKで作成したスタックを ecspresso で管理することは技術的に可能です。最終的には、どちらのツールを使用するかはチームの好みや既存のワークフローに依存します。

に最終更新