はじめに
本記事は、2段階構成で執筆しています。
- コンテナをECS上で実行する手順
- ECSタスクの詳細解説
すぐにECSを動かしたい！ という方はステップ１(ECS上でコンテナを実行する手順)から読んで手を動かしていただき、動かしたことはあるけれど仕組みはよくわかっていない、という方はステップ２(解説編)を見ていただくといいでしょう。
Dockerコンテナグレートジャーニー（過去ログ）
本記事は、シリーズものの第7回の記事となります。単体としても見ていただけますし、コンテナ技術のもっと基礎的なところから知りたいという方は、最初の記事もぜひご覧ください。
本記事はAWSECSにフォーカスしていますが、他の記事ではDockerコンテナの基礎を解説しています。
旅路（インデックス）
- そもそも仮想化とは？ 仮想化ではないシステムとは？
- Dockerコマンド基礎（環境構築～ubuntu/httpdコンテナでのコマンド実行）
- Dockerのストレージについて
- Dockerのネットワークについて
- Docker-compose でコンテナをまとめる
- Docker image と Dockerfile
- AWS ECS で Dockerコンテナを走らせる 【⇦本記事】
ECS上でコンテナを実行する手順
今回は、Dockerfileをビルドできる環境が揃っている前提で話を進めます。
Dockerfileの仕組みがわからない方や、ビルドができないという方は、過去の記事や、別のDockerコンテナ記事を参照ください。
1. ECRにイメージをPUSHする
まずは、AWSクラウド上にDockerイメージをPushします。
最初はリポジトリ（イメージを保管する場所）がないので、作成しましょう。
1-1. サービス画面へ
- 「Elastic Container Registry」と検索してサービス画面に遷移
- Private registry -> Repositories をクリック
- 右上の「リポジトリを作成」をクリック
1-2. リポジトリに名前を付ける
1-3. それ以外に設定変更する項目はありません。「作成」を押してリポジトリを作成しましょう。以下のようにリポジトリができていればOKです
1-4. 次にローカルのDockerイメージをリモート側にPushします。先ほど作成したリポジトリをクリックすると、右上に「プッシュコマンドを表示」というボタンがあるので、それをクリックします
すると4つのコマンドが出てくるので、それを上から順に実行していきましょう
※ローカルのターミナルがAWSの認証情報を持っていないとエラーになります。権限エラーが出る場合は、別の記事で確認してみてください。
成功すれば、Pushが開始されます。ECRの画面を更新し、「latest」のイメージができていれば成功です
2. タスク定義を作成する
これでイメージのアップロードができたので、次はタスク定義を作成します。
まずは「Amazon Elastic Container Service」に移動して、左側のペインの「タスク定義」をクリック、新しいタスク定義を作成します。
2-1. タスク定義ファミリー
タスク定義ファミリーに、わかりやすい名前を付けます
起動タイプはFargateでいいでしょう。メモリ容量なども、テスト実行ならそのままで十分です。
2-2. IAMロールの設定
設定は2つあります。
「タスクロール」は、テスト実行では他のAWSリソースにアクセスしないのでひとまずいりません。
「タスク実行ロール」は必要になるので、IAMロールが存在しない場合は新しく作ります。
作成画面に遷移し、「AWSのサービス」⇒「Elastic...」で検索し、「Elastic Container Service」を選択しましょう。「ECS」と検索しても出てこないので注意。
ユースケースには「Elastic Container Service Task」にチェックを入れてください。
2-3. 許可ポリシー
AWS公式が出しているドキュメントを見ると、「AmazonECSTaskExecutionRolePolicy 」というポリシーを付けろと言われています。
検索して、チェックを付けて次へ行きます。
あとはRole名を入力して完了です。
今回は「qiita-practice-run-ecs-task-role」という名前にしました。
画面は戻ってタスク定義。
IAMRoleが作成されると、それが選択画面に現れるので選択します。
2-4. コンテナ設定
続いてコンテナ設定をします。
コンテナ名は任意の名前で大丈夫ですが、わかりやすい名前にしましょう。今回は「test-worker」とします。
イメージURIの枠も必須です。
この文字列は、先ほど作成したECRのlatestイメージ画面から取得できます。
必要なら環境変数も設定できます。
他に設定する項目はないので、「作成」を押して進みましょう。
3. ネットワークを整備する
（すでにVPCを作成済の場合はスキップしても大丈夫です）
ほかの多くのAWSサービスの例にもれず、ECSFargateもVPC内に設置する必要があります。
VPC画面に遷移し、「VPC」⇒「VPCを作成」をクリックしてください。
作成方法を「VPCなど」にすると、必要なリソースを一括作成できて楽です。
3-1. ネットワーク構成
今回はテスト用なのでAZは1つ、パブリックサブネット1つ、プライベートサブネットはなしの、小さな構成にします。
ネットワーク的なセキュリティを担保したい場合は、
- プライベートサブネット＋NATゲートウェイ作成
- プライベートサブネット＋ACL設定変更＋IPアドレス付与設定オン（ECSタスク起動時）
のような設定が必要になります。詳しくは解説編で話します。
4. タスクを実行する
4-1. クラスターの作成
「Elastic Container Service」⇒「クラスター」を選択します。
まだクラスターが存在しない場合、右上のボタンから新しく作成しましょう。
ECSタスク を実行するだけであれば、クラスター名だけ任意の名称にして、そのまま作成すればOKです。
私の環境では、前に作っていたものがあったのでそれをそのまま使います。
4-2. タスクの実行
クラスターが作成できたら、そのクラスターをクリックしてください。その後「タスク」⇒「新しいタスクの実行」をクリックします。
タスク定義ファミリーを設定できるので、先ほど作成した「qiita-practice」を選択します。
次に、「ネットワーク」⇒「VPC」から、任意の作成したVPCと付随するSubnetを指定します。セキュリティグループはDefaultで大丈夫です。
PublicIPの割り当てについてはどちらでもよいですが、少額ですが課金対象なのでOffにしています。
ここまでできれば、「作成」をクリックしてECSタスクの作成完了です。
タスク画面でログを確認できるので、正常に動作しているかチェックしましょう。
4-3. エラーが起きたとき
コンテナが立ち上がらない、特にログが出る前にエラー終了してしまっている場合、要因は幅広くデバッグが難しいこともあります。
自分で探してみて原因が全く分からない場合、AWS公式の診断ツールを使用するのも手です。
先日記事で投稿したので、こちらをご覧ください。
解説編
ECSを起動させるだけであれば、指示に従ってポチポチしていれば何とかなります。
ただその中身を知らなければ、エラーに対応できなかったり、細かいところで詰まってしまうことも多くなります。特にECS周りでは謎のエラーに悩まされることも多いので、エンジニアとしては知っておくに越したことはありません。
というわけで、本節ではECSタスクの設定にどんな意味があるのかを、図解付きで分かりやすく解説します。
タスクとはなにか？
そもそもECSタスクとはなんでしょうか。
まず前提として、ECSでコンテナを使用する場合に使える機能は「ECSサービス」と「ECSタスク」の２つになります。
それぞれについて軽く説明すると、ECSサービスはコンテナを起動させ続けるためのものです。エラーが起きてコンテナが停止してもすぐに代わりのコンテナが立ち上がったり、デプロイの際もローリングアップデートで機能を途切れさせずに更新することが可能です。ECSサービスは常駐サービスのサーバー等によく使われます。
対してECSタスクは、既定の処理を完了したら即座にコンテナを停止させるものです。実行時間や処理容量がカスタマイズできるLambda、といった感じでしょうか。バッチ処理などによく使われます。
タスク定義とはなにか？
タスク定義の設定画面を覗いてみると、設定項目は5つに分かれています。
ストレージやモニタリングはオプション色が強いので、実質的にタスク定義が管轄しているのは大きく分けて２つになります。
- インフラストラクチャの要件 ⇒ クラウドリソースの設定
- コンテナ ⇒ コンテナ設定
それぞれ見ていきます。
1 クラウドリソースの設定
前回までの記事では、ローカル環境でDockerfileやDokcercompose を docker runのようなコマンドで動かしてきました。
このときコンテナが動作するのは、『ローカルPCを対象にしてコンテナを立ち上げた』ためです。
ただAWS上ではローカルPCが存在しないので、コンピューティングリソースを用意する必要があります。
その時に使用できるサービスが、よく聞く2つです。
- EC2
- Fargate
Fargateは、EC2では自己管理する必要があったサーバー管理責任を、AWSが肩代わりしてくれるサーバーレスサービスです。特別な目的が無ければ、Fargateを使用するのが良いかと思います。
1.1 実際の設定画面
- 起動タイプの選択
- OSの設定
- 使用するメモリの設定
- IAM ROLE の設定
と、クラウドリソースに関する設定が続きます。コンテナコンピューティング環境の定義そのものです。
1.2 2つのIAMRole
IAMRoleの設定箇所が2つあるのはなぜでしょうか？
- タスクロール
- タスク実行ロール
タスクロールは、起動するコンテナ（ECSタスク）に対して付与するIAMRoleです。S3アクセスやログ出力権限を付与することで、コンテナが他のAWSサービスと連携できるようになります。これは他のAWSリソースと同じなので、想像しやすいかと思います。
タスク実行ロールは、ECSタスクを立ち上げる際に使われる権限です。
速い話が、EcsRunTaskの権限と、その他こまごまとした権限が付与されます。起動時しか使用されないので、このRoleにS3アクセス権限を付けてもECSタスクは何もできません。
ただ、ECRからイメージをpullしたり、SecretsManagerから環境変数としてシークレットを取得したりするときには必要です。
デバッグの際は、権限がコンテナ起動前と後のどちらのものかを切り分けるようにしましょう。
2. コンテナの設定とは？
タスク定義の設定を追っていくと、「コンテナ - 1」のような設定項目が出てきます。
これは立ち上がるコンテナの設定です。
ローカルでの実行に照らし合わせると、docker runやdocker compose実行時に設定できることを、ここで設定することになります。
例えば以下のような設定です。
-
docker rum --name ***や、docker compose内でコンテナに名前を付けたりしていたのと同様、コンテナに名前を付けられる -
docker runコマンド時に設定するポートマッピング - ビルド時に設定した環境変数の上書き
- docker-compose で設定していた、コンテナの立ち上がる順序の制御
さらに下の方に行くと、「コンテナを追加」という設定項目もあります。
docker compose では複数のコンテナを一括で管理していましたが、タスク定義ではここで複数のコンテナを定義します。
大雑把に言ってしまえば、タスク定義とは「docker compose」と同じようなものだと理解すればよさそうです。
3. ネットワーク設定
ネットワーク設定について大事なことは1つです。
コンテナが立ち上がるECSと、イメージを保存するECRは全く別のネットワーク上に存在する別のサービスである。
まずはこれを頭に入れましょう。
そして別のネットワークに存在するということは、
- VPC外へアクセスできる設定が必要
- ACLで通信の制御が必要
- ECRにアクセスするIAM権限が必要
など、そもそも通信が正常にできることと、別サービスであるECRにアクセスする権限（これはベーシックなタスク実行ロールを付与していれば問題ない）ことが必要になります。
よくあるミスとしては、
- サブネットがプライベートで、IGWに接続されていない
- ACLでアウトバウンドが拒否されている
- ACLでインバウンドの32768~65535 が拒否されている
などがあります。
特に、ECRからの戻り通信に対して動的ポートを解放していないと通信が成立しないようです。
もちろん必要なセキュリティに合わせてカスタマイズする必要はあるので、通信ができないからとバカバカ開けないように注意は必要です。
ネットワーク構成の例
検証用、とりあえず起動したい場合
この設定にしておけば、ひとまずコンテナを起動できます。
プライベートサブネットにコンテナを配置すると、デフォルトではIGWに接続できないので別途設定が必要になりますが、パブリックサブネットに配置しておけばその必要もありません。
また、コンテナ内部のプログラムが外部と通信をする際には、IPアドレスが必要になります。ECSTaskの起動時に「Enable IP」みたいな設定がありますが、その設定をONにしましょう。
（注）この構成では、外部からアクセスし放題になってしまうので、重要なデータをコンテナ内に保存したり、同一VPC内に対して踏み台サーバーとして利用できる場合などは、避けるべき構成です。
プライベートサブネット＋NATGW
よくある構成かと思います。
NATGWを使用することでコンテナを外部に露出させず、かつIP通信で外部ネットワークとも通信できます。
インバウンドも最低限必要に絞っています。80, 443はWeb通信で、32768~65535はLinuxにおける動的ポートです。動的ポートを開けておかないと、ECRとの通信における戻り通信が受信できないのだとか。
（注）NATGWは定額課金＋通信料課金なので、月々7000円~ の金額がかかります。
プライベートサブネット＋VPCEndpoint
外部ネットワークに接続しないのであれば、VPCEndpointを使用して直接ECRに接続するのが良さそうです。
この設定であれば、NATGWよりも安上がりで、かつ外部とは完全に隔絶されたネットワーク上で処理ができるのでセキュリティ上も堅牢です。
終わりに
だいぶ時間が空いてしまいましたが、Dockerコンテナグレートジャーニーと名付けて始めた本シリーズもひとまず完結です。最初から読んでくださった方は本当にお疲れ様でした。「Dockerコンテナとはなんぞや？」という疑問が解決し、根底からの理解が進み、さらに実際に運用できるレベルまで来られているのであれば幸いです。
筆者自身も勉強しながら記事を書いていたのですが、Dockerは各種開発環境のスタンダードとなっていることもあり、改めて学んでよかったと思っています。仮想化の技術はいろいろな場所に広がっており、応用範囲がとても広いです。
ですので他の記事をまだ読まれていない方は、是非ともご覧いただき、その概要を掴んでみてください。
それでは、よいコンテナライフを！