[分かってるつもり回避]ECSを関連サービス含め基礎からおさらいしてみた

はじめに

ECSやFargate、k8s等、今をときめくコンテナサービスを積極的に利用されている方は多いと思われます。

特にECSには業務で触れることが多くなり、仕様作成等でも構成図を書く契機が出てきたりしますが、

「AWSでのコンテナのあの辺りはどうやってどう動いてるんだっけ？」

と自身で咀嚼しきれていないことに気が付きました。「この状態は不味い」と思い、ECSの基礎及びメリットを一つ一つおさらいしてみました。

AWS上でコンテナを使うメリット

コンテナイメージは利用する上で様々なデメリットにぶつかりやすいですが、AWSではこれらを効率よく解消できるサービスが存在しています。

• コンテナイメージの管理でストレージサイズに悩まされない
• コンテナの本番運用で操作用UI作成に悩まされない
• テストや本番展開時の負担に悩まされない
• コンテナイメージのビルド時間に悩まされない

コンテナイメージの管理でストレージサイズに悩まされない

実際にコンテナイメージを作成した場合に、運用を考えると先ず立ちはだかるのはイメージの管理スペースです。

Amazon ECR (Elastic Container Registry)はイメージの管理とデプロイに関する不安を払拭することが出来ます。

実際に使う

名前を指定の上でECR上にリポジトリを作成する必要があります。

なお、リポジトリにプッシュする際の操作については、リポジトリを選択することでクリック可能になる「プッシュコマンドの表示」から確認できます。

コンテナの本番運用で操作用UI作成に悩まされない

Amazon ECSはコンテナを本番サーバで運用する際の起動・終了操作、及びスケーリングを手軽に実施できます。

尚、AWS Fargateを併用してコンテナを起動させる場合はサーバリソースの管理やスケーリング操作を行う必要もなくなります。

実際に使う

お試しの場合は「sample-app」にします。タスク定義は特に変更の必要もありません。

「サービスを定義する」「クラスターの設定」においても弄らずそのまま進めます。「確認」まで来たら「作成」をクリックすることで自動的にコンテナが生成されます。

テストや本番展開時の負担に悩まされない

長期的な運用を見越した場合、所謂CI/CDに掛かる負担を減らすことは避けられない課題となってきます。

AWS CodePipelineを利用すると、CI/CDをマネージドで可能になります。並列実行や手動実行も可能です。

コンテナイメージのビルド時間に悩まされない

Dockerイメージを毎回ローカル環境でビルドする場合、とにかくマシンスペックに引っ張られて頭を抱えやすいと思います。

AWS CodeBuildではGithubで管理しているDockerfileを利用してイメージをビルドすることが可能です。

ECSで構成管理を行う場合

より踏み込んで、Ansible等の構成管理をECSで行う場合はFargateからタスクとしてAnsibleを実行する方法もあります。

上記リンク先にて入力されている画像内パラメータが見辛い場合は、下表の記述を参考にしてください。

設定項目	値
イメージパス	g40244/fargate-ansible:latest
コマンド	s3.bucket.path,ansible-playbook,-i,inventory.ini.playbook.yml
作業ディレクトリ	/home/ansible

まとめ

ECSについてはサービス名と概略のみの理解でしたが、実際に触ってみてようやく実感がわいてきました。また、SAAの認定試験対策も兼ねて実際の操作にも触れてみました。

k8sも含めたECSに関する詳細は下のBlackBeltも参照してみてください。