概要
- AWS におけるコンテナサービスの変化についてをサービス誕生の流れから迫っていき、昨年誕生した AWS App Runner のようなサービスが生まれたことで今ユーザに求められることってなんだろうに迫った記事となっています。
AWS におけるコンテナサービス
- AWS におけるコンテナ関連のサービスは多岐に渡ります。
- コンテナオーケストレーションサービスであれば、Amazon ECS や Amazon EKS が有名ですよね。
- Amazon ECS というのは、AWS が独自に開発したコンテナオーケストレータです。
- Amazon EKS というのは、k8s をマネージドで管理することができるサービスとなっています。
- ECS や EKS といったコンテナオーケストレーションサービスはあくまでコンテナオーケストレータとしてのサービスなので、コンテナが実際に実際に稼働する環境を選択しなければなりません。
- よく使われるサービスとして、Amazon EC2 や AWS Fargate があります。
- Docker イメージを保存しておくイメージレジストリとしては、Amazon ECR があげられます。
- また、関連サービスは様々で下記の図にあるもの以外にも存在します。
AWS におけるコンテナサービス周りの変化
- AWS におけるコンテナサービスは、凄まじい変化を遂げてきました。
- 2014、2015くらいに Amazon EC2 が登場し、この当時は実際にコンテナが稼働する環境としては Amazon EC2 しか選択することができませんでした。
- その後、Amazon ECR が発表され、2017年の re:Invent で AWS Fargate が発表されます。
- その後、Amazon EKS が登場し、2020年頃に AWS Copilot が生み出され、昨年の2021年に AWS App Runner や AWS Proton が誕生しました。
さてさて、各サービスを組み合わせると・・・
- これらのサービスを組み合わせてサービス構成を考えようと思うとどうなるでしょうか。
- 簡単な例を下記の図で表してみました。
- ユーザは、コンテナオーケストレータとして、Amazon ECS や Amazon EKS を選択します。
- コンテナ実行環境としては、AWS Fargate や Amazon EC2 を選択するでしょう。
- 稼働するためのコンテナイメージを保存する先として、Amazon ECR を組み合わせるとこんな感じですね。
Amazon ECS を使用したアーキテクチャ例
- ただ、実際にはこれ以外のコンポーネントを組み合わせないといけません。
- Amazon ECS をコンテナオーケストレーションとして選択した時のアーキテクチャ例を下記に示しております。
- 例えば、ネットワーク設定として Amazon VPC や ELB などを設定したりとか、Deploy までを自動化したいからその仕組みを考え、例えば AWS にある Code シリーズを使ったりなど考えなければならないことがたくさんあるでしょう。
正直なところ、めんどくさくないですか？？
- そこでオススメしたいのが、AWS App Runner と AWS Copilot になります。
AWS App Runner
- 先ほども述べたように、Amazon ECS 上に Web アプリを仕様に合わせデプロイするとでしょう。
- コンテナ管理とかVPC周り
- ALB、NLB
- scaling
- 自動化するなら codebuild とかを考えなければなりません。
** App Runnerは、これらをまとめて(隠蔽して) 提供してくれるようなサービスとなります。**
- AWS App Runner 上で アプリケーションをデプロイしようとすると下記の図のような導線となります。
- 導線としては 2つ存在します。
- 1: コンテナイメージを作成し、Amazon ECR にプッシュします。App Runner の設定でプッシュされたことを検知し自動でコンテナ実行環境上にデプロイしてくれます。
- ここで大事なことは、ECR を使うパターンですと Dockerfile を使用しコンテナイメージを作成しなければならないことです。自由度はありますが、Dockerfile を作成しなければいけないことは注意です。
- 2: もう一つの方法が、Github 上にソースコードをプッシュすることを検知し、デプロイしてくれる設定のパターンです。
- こちらで重要なことは Github 上に稼働させたいアプリのコードを載せ、App Runner 側でデプロイの設定を入れるだけなので、こちらは Dockerfile を書かなくても良い点です。
[詳細はこちらをご参照ください。]
https://qiita.com/yoshii0110/items/ec209712cafa7547c680
AWS Copilot
-
AWS Copilot とは、Amazon ECS CLI の後継にあたるものです。
-
ECS CLI は、Amazon ECS 環境に対するコンテナデプロイのためのツールですね。
-
AWS Copilot がなぜ登場したのかいうと、より ECS (App Runnerへのデプロイも対応)でコンテナを実行したいとなった時のワークフローをシンプルにするためというモチベーションがあると思っています。
-
実際に試すとこんな感じですね。
-
Dockerfile を用意しておけば、CLI から ECS や App Runner に対して簡単にデプロイすることができます。
- なお、AWS Copilot で作成した資源の見え方としては、既存のコンテナサービスへのデプロイのワークフローをシンプルにするだけなので、資源自体は存在します。
- 実際にマネコンからもその資源は確認することができます。
[詳細はこちらをご参照ください。]
https://qiita.com/yoshii0110/items/8a74cc0fc540ae3f2389
責任共有モデル
- さて、これら便利なコンテナ関連のサービスが登場したのはいいですが、便利な反面使う上で気をつけなければならないことってなんでしょうか。
- それを考える上で重要なものとして、責任共有モデルというものがあります。
- さてこれはなにかという話なのですが、一言で表すなら、AWS を利用するユーザと、AWS 側との境界。すなわちどこまでの領域を AWS が責任を持つのか、どこまでを利用ユーザが持つのかを表現しております。
さて、では先ほどお話ししていたコンテナサービスにおける責任共有モデルの違いはどうなるでしょうか。
- 下記を見ていただくと分かるように各サービスごとに責任共有モデルの境界が変わっていることがわかると思います。
- Fargate や AWS App Runner といったサービスでは、より AWS 側が持つ責任の領域が広いことがわかると思います。
- ただ、Fargate においては載せるコンテナにおけるセキュリティが、App Runner においては設定によって責任の領域が異なるのですが、ECR を使う場合であれば、稼働させるコンテナのコンテナイメージはユーザ側がセキュリティの責任を負いますし、Github を使う場合は、アプリ部分のセキュリティを追う感じになります。
ではこれらのサービスを使う中でユーザ責任を持他なければならないセキュリティの領域が分りました。そこでコンテナイメージに着目した時に我々はどうやってセキュリティをチェックすれば良いのでしょうか。
それらをチェックする OSS のツールがあるためそれらを紹介しようと思います。
コンテナイメージ作成の補助となる静的解析ツール①
コンテナイメージ作成の補助となる静的解析ツール②
コンテナイメージ作成の補助となる脆弱性スキャンツール ①
コンテナイメージ作成の補助となる脆弱性スキャンツール ②
まとめ
- AWS におけるコンテナサービスは年々変化しています。
- 最近でと、責任共有モデルの aws 側が責任を持つ領域が増えたサービスが生まれてきています。
- ただ、正直利用するときはユースケースに依存すると思っており、カスタマイズを細かくしたいなどの要件を満たせないといった場合がある気がします。
- ただ、より運用が楽になるサービスを使えるのであればぜひ検討いただけると良いと思います。
- ただ、その際にユーザ側に求められる責任範囲には注視することは注意です。