この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、崔です。
2020年10月20日〜22日に行われたAWS DevDay 2020 のセッション「第2回 AWS Fargate かんたんデプロイ選手権」を視聴しましたので、レポートをお届けします。
セッション情報
スピーカー
Tori Hara 様（アマゾン ウェブ サービス ジャパン株式会社）
概要
デプロイ ー それは秘められた開発を経た新たなソフトウェアが世に送り出される(ときどきロールバックされる)神秘の行為。
昨年日本中を感動の渦に巻き込んだあの伝説のブレイクアウトセッションが装いをあらたに帰ってきました。
常に最高のデプロイ体験を追い続けるあなたに贈る『第2回 AWS Fargate かんたんデプロイ選手権』。お楽しみください！
本セッションは Amazon Elastic Container Service (Amazon ECS) が対象です。
資料
アジェンダ
- AWS Fargate とは
- Quick start with "AWS Copilot CLI"
- AWS Fargate に対応したデプロイツール
- 各デプロイツールの守備範囲や背景を読み解く
- マッチしそうなツールはありましたか？
Amazon ECS と AWS Fargate を組み合わせて利用するときに、最も簡単にデプロイできるツールは何か？という、昨年、第1回と称して実施し大好評だったセッションの記念すべき第2回のセッションです。
本セッションは…
本セッションの想定聴講者は、
- これから、Amazon ECS を使って、AWS Fargate を利用していこうと検討されている方
- コンテナをAWS上でさっさと動かしたい方
- デプロイやCI/CDパイプラインについて考えるのが好き
そういった方をセッションの対象としています。
ゴールとしては、
- AWS Fargate の特徴を改めて復習する
- たくさんのデプロイツールのそれぞれの特徴を知ったうえで、デプロイへの探究心を高めていただく
- 自社・自チームでのデプロイ方法について、その方法が良いのかと、ディスカッションを始めていただくきっかけになれば
となっています。
AWS Fargate とは
コンテナオーケストレータの概要
AWS Fargate がどんなものかというと、Amazon ECS との組み合わせにより利用可能なフルマネージドなデータプレーンテクノロジという表現になります。
AWS FargateそのものはAPIを公開していません。
APIがないのに、ユーザはどうやってコンテナをデプロイするのか、それをクリアにするために、まずは簡単に AWS Fargate とは何なのかを振り返ります。
まず、コンテナを実行したいとなったとき、Amazon ECS もしくは Kubernetes の API を呼びます。
そうするとコンテナオーケストレータはいい感じにEC2インスタンス群の中にコンテナを立ち上げていきます。
オーケストレータのところはなぜ Kubernetes なの？ Amazon EKS ではないのか？
Amazon EKS はコンテナ関連サービスですが、オーケストレータではありません。
Amazon EKS は、ユーザからの API コールを受け取って、Kubernetes そのもを構築管理するためのサービスです。
なので、コンテナを実行したいときに呼ぶ API は、Amazon ECS もしくは Kubernetes の API になります。
非常にシンプルで、API を呼ぶとコンテナを立ち上げることができます。
実行環境 EC2インスタンスの運用業務
足まわりの EC2 インスタンスの中身を見ていきます。
EC2 インスタンスは仮想マシンですが、もちろん OS そのものが中にあります。
それから、コンテナオーケストレータがいい感じにコンテナを実行してくれますが、実態としては、中になんらかの Container の Agent と Runtime が入っていて、これらがオーケストレータと協調することでコンテナを動かしています。
つまり、コンテナを実行したいと思ったら、実行環境である足まわりの EC2 インスタンス群の運用業務が発生します。
一番わかり易いのは、OS とか Agent 類へのパッチ当て、更新といった作業です。
もうひとつ、忘れがちなのが、今、どれくらいのコンテナが動いているかというのにあわせて、足まわりの仮想マシンの量を増やしたり減らしたり、そもそものプランニングからやらなければいけないということです。
コンテナを実行したいだけなのに、コンテナの足まわりにある仮想マシンをたくさん面倒見ていかないといけない。本末転倒な感じがします。
AWS Fargate
そこで、AWS Fargate です。
AWS Fargate が何をしてくれるのかというと、仮想マシン、Agent、OS、コンテナだったり、その他もろもろ、全て、AWSマネージドで提供します。
ユーザは、仮想マシンのことを考えなくていい。コンテナを実行したいように実行すれば、仮想マシンについては、AWS 側が、コンテナの状況にあわせて用意してくれるというのが AWS Fargate です。
AWS Fargate を利用するとEC2インスタンスのプロビジョニング、スケーリング、そもそもの管理が一切不要になります。
EC2 インスタンスについて考える必要もなければ、EC2 インスタンス内部のコンポーネントに対するパッチ当てとかバージョンアップについても考える必要がありません。
スケーリングについても、コンテナがスケールイン／スケールアウトすれば、AWS Fargate がそのコンテナの状況に合わせて、足まわりの仮想マシンをスケールイン、スケールアウトしてくれます。
Quick start with "AWS Copilot CLI"
アプリを作ったら、AWS Fargate上でさっと動かしたい。
そんなときに使えるのが、AWS Copilot CLI です。
2020年7月に正式にリリースして、現在、Developer Previewです。
手元に、アプリがある。
Dockerfileも書きました。
あとは、これを AWS Fargate で動かしたい。
こうなったときに、AWS 上で動かすときによくあるブロッカーは何か？
まず、VPC 作る、Subnet を設計しましょう、SG、IAM ロールは、と色々必要になります。
AWS Copilotを使うと、次のコマンド1つでOKになります。
copilot init
コマンドを実行すると、Copilot は、インタラクティブに質問してきます。
アプリケーションの名前を何にしますか？
動かそうとしているサービスのアーキテクチャはどんなものですか？
アーキテクチャの選択肢は、今は2つあって、ロードバランスなサービスかバックエンドサービスか。
次に、サービスの名前を決めてと言われます。
また、Dockerfile は、どれ使いますか？
テスト環境をデプロイしたいですか？
これらに回答していくと、VPC、Subnet、ECSクラスター、ロードバランサー、諸々必要なものを作ってくれます。
出力されるALBのDNSにアクセスするとアプリが動いています。
アプリとDockerfileを用意してコマンドを実行して、質問に答えていくだけで簡単に構築できます。
AWS Fargate に対応したデプロイツール
AWS Fargateに対応したデプロイツールは先程の AWS Copilot だけではありません。
たくさんあります。
例えば、Awesome-ecs というリポジトリから抜粋してきただけでもこれだけあります。
なぜ、こんなにたくさんツールがあるのかというと、それぞれのツールで、想定している使われ方や守備範囲・強みが異なっているからです。
自身のニーズや各種ツールの守備範囲がマッチするかという観点で見ていただくと面白いと思います。
各デプロイツールの守備範囲や背景を読み解く
AWS Management Console
メリットは明白です。
GUI でタスクを作成できるので、初めての方でも Wizard に沿って進めていけば動かせます。
ECS 以外の AWS サービスもまとめて設定できます。
リソースを確認するときに大きなメリットがあるのは疑いがありません。
デメリットとしては、
デプロイが手作業になることが多いので、再現性がない。
手作業なのでミスオペレーションのリスクがある。
CI/CDパイプラインとの親和性はあまりない。
といったところになります。
したがって、継続的なデプロイに使うのは難しいです。
AWS CLI
AWS の新サービスリリース時や、サービスアップデートのタイミングで、AWS CLI も対応しています。
新機能がリリースされたときに、AWS CLI なら使えることがほとんどです。
ただ、CI/CD パイプラインが、シェル芸になりがちです。3ヶ月後に見たら、何をやっているのか分からないシェル芸になりがちです。
タスクをデプロイするだけならまだしも、デプロイの前処理、後処理などリソースの依存関係まで考えたデプロイをしようとすると、さらに高度なスクリプト技術が求められます。
ロールバックを想定すると本当に手間になります。
ecs-deploy
AWS CLIに対して、1つの解になるのが、ecs-deploy です。
単一のシェルスクリプトの中に全部の操作が書いてあって、全て AWS API を呼んでいるだけなので、中身を読んで理解しやすいです。
コミュニティで非常に揉まれているので、自分で AWS CLI を書くよりも、かなり堅牢にデプロイのオペレーションを回せます。
例えば、ロールバックなども考慮されています。
ネットワークやロードバランサー関係のリソースなどは、他のツールで作成済みであることを前提としています。
なので、一定程度の AWS の知識が求められます。
読みやすい、書きやすいので、つい魔改造したくなり、バグも生まれやすくなります。
AWS CloudFormation / Terraform
もう少し、CI/CDとかをやりやすくしていくと、何があるかというと CloudFormation と Terraform があります。
一般に Infrastructure as code と呼ばれるものです。
AWSリソースについて宣言し、リソースの宣言的なデプロイメントが可能になります。
メリットは、
単体で全てのAWSリソースを用意できるため、1つのツールで済みます。
Fargateタスクだけでなく、関連するAWSリソースがどのような状態にあるのかを定義ファイルから確認しやすいです。
Templateを見ればリソース全体がどうなっているか把握できます。
定義ファイルをバージョン管理システムの管理下に置くことで変更履歴や変更理由まで追えます。
変更差分をまず確認してから実行できたり、AWSリソースの依存関係も定義できます。
CI/CDパイプラインとの相性が良いです。
デメリットとして、何があるか。
パラメータが無数にある。
その意味が何なのか、考えないと、Templateを書けないので、人によっては、ペインポイントになります。
最新の機能に対応されるまで、時間がかかることがあります。
また、記述量が多くなりがちです。Terraform Modulesを利用すれば書く量は減らせるが、どのModulesを使うのか、悩みになります。
AWS CDK
書く量が多いことを解決しようとしているツールとして、AWS CDK があります。
コードから CloudFormation テンプレートを生成してくれます。
コードでインフラを記述できるので、デベロッパーと親和性が高いです。ユニットテストも書きやすいです。
他のツールを併用しなくても、AWS Fargate を含めたAWSリソースを一通り作成できます。
多くのパラメータを省略できるので、記述量が減らせます。
抽象度が高く、記述量が少ないので、意識していないと、なぜそういうリソースがそういうプロパティで作られたのかということを、説明しないといけないときにできなくなる可能性も0ではありません。
AWS Copilot
一連のタスクだけではなくて、ECSタスクの周りにあるリソースまで含めて作成していくことが可能です。
メリットは、
最低限求められるものが、アプリケーションと Dockerfile のみです。
抽象度が非常に高いので、AWS CDKよりも更に少ない記述量でアプリケーションをAWS上で動かすことができます。
簡単なだけでなく、複数のAWSアカウント、複数の環境にデプロイしていくパイプラインを作ることも可能です。
CloudFormation で定義した任意のリソース、その Template を Add-on することができます。
プロダクションレディな環境をCloudFormationで定義するときにどうすればいいかを学ぶ、勉強材料としてもいいのではないでしょうか。
デメリットとしては、
Developer Preview のため、細かい設定変更がまだできません。
ロードバランスサービスを作るが、特定のIPアドレスからのみ許可したい、などはまだできないです。
ecspresso
kayac さんが公開しているオープンソースのECSデプロイツールです。
非常に薄いレイヤーで作られています。
画面や別のツールで作られた ECS サービスを後から CI/CD に載せることができます。
それを、init コマンドで取り込めます。
環境変数を使って、定義ファイルを出力できます。
デメリットは、
意図的に狭い範囲をコントロールするようにデザインされているように思われます。
メリットになることもあるし、他のAWSリソースについて知らないとだめ、ってのがデメリットになることもあります。
Docker Compose ECS intergration (Beta)
Docker Compose を利用したローカル開発と非常に親和性が高いです。
ロードバランサーや CloudWatch ロググループなど Fargate タスクを実行する際に、最低限必要なものが一通り作成されます。
バックエンドが CloudFormation です。
デメリットとしては、
Beta であり、ECS サービスの更新は未サポートです。
VPC やサブネットなどのリソースは、事前に作成済みであることを前提としています。
Docker Compose が管理しない AWS リソースの作成・管理には別ツールの併用が必要となります。
マッチしそうなツールはありましたか？
とりあえず、動いているところをみたい。これから AWS をはじめるといった場合、
その場合は、AWS Copilotが一番Fitするのではないでしょうか。
運用も考えながら、CI/CDを意識してツールを選びたい。
まず、単一のツールで全てのリソースを記述したい場合、
AWS CLI や、CloudFormation、Terraform、AWS CDK が良いのではないでしょうか。
また、Fargate へのデプロイを頻繁に行うので、抽象化したものでスマートに実施したい場合、
ecs-deploy や、ecspresso、Docker Compose ECS integration のいずれかと、上記ツールの組み合わせは如何でしょうか。
または、AWS CDK + ECS extensions for CDK や、AWS Copilot、
これらも、運用を考えて利用できるツールかなと思います。
感想
基本的には、関連サービスも含めた形で、CloudFormation でデプロイすることが多く、軽く動かしたいときはマネコンから実施することが多いのですが、AWS Copilot や ecspresso、ecs-deploy あたりも試してみたいと思います！
3
