この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
7月2日にライブ配信されたAWS主催の「Containers from the Couch Hello AWS App Runner!」についてレポートします。
一時間半でリラックスした雰囲気のなかガッツリApp Runnerを学ぶことができました。また質問を全て拾って回答してくださったのも良かったです。このブログ末尾に動画を貼っておきますので是非一度ご覧になってください。
Containers from the Couchとは
AWS コンテナサービスチームによるライブ配信シリーズです。YouTubeチャンネルはこちら。
基本英語でのライブ配信ですが、たまにAWSJの方が日本語配信をされています。今回はその日本語回で、App Runnerの紹介回です。
スピーカー
- spesnova (@spesnova)さん - Startup Solutions Architect at AWS
- トリ (@toricls)さん - Sr. Product Developer Advocate for Containers at AWS
レポート
App Runner概要説明
- AWS上で最も簡単かつ最速でコンテナ化されたウェブアプリをビルド、デプロイ、実行できるサービス
- ECRにコンテナイメージをプッシュするか、GitHubにコードをプッシュするかだけでOK
- アーキテクチャー
マネージドなロードバランサーと、その配下でトラフィックを分散するコンテナインスタンス群を提供する
デモ #1 コンテナイメージからデプロイ
hello-app-runnerというデモ用コンテナイメージをECRパブリックギャラリーからプルしてきてデプロイするデモです。
まずはAWSマネジメントコンソール上部の検索フォームで「App Runner」と検索します。(AppとRunnerの間にはスペースが必要です。「AppRunner」だとヒットしませんよ！)
App Runnerのサービス一覧画面に遷移するので、左上「サービスの作成」をクリック。（一度もサービス作ったことない場合だとこの一覧画面ではなくてサービス紹介ページが表示されますが、その場合でも「サービスの作成」をクリックです）
ソースのリポジトリタイプでコンテナレジストリを選び、プロバイダーでECRパブリックを選択。イメージURLは前述のhello-app-runnerECRパブリックギャラリーページからコピペしてきます。
デプロイ設定欄は、ECRパブリックの場合は手動のみです。(自動だと誰かがイメージプッシュしたら勝手にデプロイされちゃうので)
続いてサービス設定。サービス名は適当にいれて。ポートは、hello-app-runnerが8000を使うので8000と指定します。
これで5分くらい経つとデプロイ完了です。ステータスがRunningになってドメインが払い出されます。
そのドメインにアクセスすると、hello-app-runnerのコンテンツが返ってきます。
Running web apps with flexible infrastructure on AWS
ここでまた説明に戻ります。
これまでAWS上で(コンテナ化された)ウェブアプリケーションを動かそうとすると、ECSやFargateといったコンテナ基盤を使うだけでなく、VPCやLoad Balancer、Auto ScalingやCodeBuildなど様々なサービスを組み合わせる必要がありました。
App Runnerはこれらをまとめて管理してくれます。
具体的には以下のような部分を管理してくれます。ユーザー側が用意するのはアプリケーションのみ。ソースコードをGitHubに置くか、コンテナイメージを作ってECRにプッシュするか。
Q: VPCとか作るとこまでApp Runnerがやってくれるとすると、App RunnerでのデプロイでもVPC5個までみたいなQuota引っかかるんでしょうか。
引っかかりません。みなさんのAWSアカウントにVPC作られない。内部的にはApp Runnerサービス側にVPCが作られています。
デモ #2 ソースコードからデプロイ
先程コンテナイメージからデプロイしたhello-app-runner。ソースコードもGitHub上に公開されているので、今度はこちらからデプロイするデモを行ないます。
まず、上記リポジトリを自分のアカウントにforkします。
ソースリポジトリタイプでソースコードリポジトリを選びます。
次にGitHubに接続です。
GitHub側で以下のようなポップアップが開き、許可を求められるのでOKします。
App Runnerのコンソールにリダイレクトされます。AWS側がGitHubとのコネクションに使うリソースであるGithub connectionの名前を決めます。GitHubのユーザー名にしておくとわかりやすいです。
App Runnerが、コネクション許可したGitHubアカウント下の全リポジトリと連携できるようにするか、特定のリポジトリのみにするか選択します。
作成したコネクション、その中のリポジトリ、さらにその中のブランチを選択します。
デプロイ設定は自動を選択。
次はビルド設定です。コンソール上で設定する方法と設定ファイルを使用する方法があります。
コンソール上で設定する場合、ランタイム(現在はPython 3とNodejs 12のみ)選択とビルドコマンドと開始コマンドの入力、ポートの指定を行ないます。
設定ファイルを使用する方法の場合、ソースコードリポジトリ内にapprunner.yamlを置いて、そこに設定を書きます。hello-app-runnerのファイルはこんな感じです。
サービス名を入力します。ビルド設定をコンソールでやる場合、この画面で環境変数の設定もできます。apprunner.yamlでやる場合はここではできずapprunner.yaml内に書きます。
次にAuto Scalingについて。
EC2の場合、Auto Scalingを実現するためにはAuto Scaling Groupという別のコンポーネントを新たに作成する必要があります。が、App RunnerではAuto Scalingは組み込みの機能です。スケーリングのしきい値だけ設定すればあとは勝手にやってくれます。また、そのしきい値が、EC2の場合だとCPU使用率とかメモリ使用率とか色々選べましたが、App Runnerでは同時実行リクエスト数のみになります。
同時実行リクエスト数については、例えば100リクエストに設定したとして、101リクエスト来ればスケールする、という意味ではありません。リクエストを受けたけど捌ききれていない処理待ちのリクエスト数がこのしきい値を超えるとスケールする、と捉える方が良いです。
また、スケール最大サイズは25が現状の上限値です。これ以上上げたい場合はサポートチケットで上限緩和申請が必要です。
次にヘルスチェックです。先程設定したポートに対してヘルスチェックが行われます。
次にセキュリティ。インスタンスからS3など他のAWSリソースにアクセスしたい場合、インスタンスロールとしてIAM Roleを紐付けて、そこにアタッチするポリシーで許可設定をする必要があります。またKMSキーは、サービス作成時に作成する必要があります。変更不可です。
作成できました。
先ほどと同様ブラウザアクセスでデモ画面が確認できます。
ログについて。App Runnerには3種類のログがあります。すべてApp Runnerコンソールから見れます。
- イベントログ: App Runnerのログ。サービス作成完了、ヘルスチェック通ったなどのログが吐かれます。
- デプロイログ: App Runnerのログをデプロイに絞ったもの。ビルドで出力される内容など。
- アプリケーションログ: アプリのログ。実態はCloudWatch Logsなので、CloudWatchのコンソールからも見れます。CloudWatch Logsの機能で他のAWSサービス(Elasticsearch Serviceなど)や3rdパーティツールとの連携もできます。
メトリクスについて。App Runnerのコンソールから確認できますが、こちらも実態はCloudWatch メトリクスです。
-
Viewing App Runner service metrics reported to CloudWatch - AWS App Runner
カスタムドメインについて。任意のドメインを関連付けることができます。
ドメイン名を決めると以下のように登録すべきDNSレコードが表示されるので、お持ちのドメインに登録します。別にRoute53で管理しているドメインでなくても構いません。反映に1〜2日かかりますので注意です。
ポーズについて。ポーズ(一時停止)をクリックすると、そのサービスのコンテナがすべて止まります。ポーズ中は無課金です。
ポーズ中のサービスのエンドポイントにブラウザアクセス。
質問: Elastic Beanstalk(EB) に似ている雰囲気がありますがどういう住み分けになるんでしょう。
- EBはAWSアカウントに各リソースができる。App Runnerはサービス側にできる（隠蔽化される）
- 責任共有モデルの境界線が違う。お客様責任のリソースを簡単に作ってくれるのがEB。AWS責任のリソースを作るのがApp Runner
- EBの方が選べる言語が豊富。デプロイ方法もたくさん用意されている。本格的にやるならEB
VPCについて
- ユーザー側アカウントのVPC上のリソースにアクセスできない
- 例 VPC内のプライベートなRDSにアクセスできない -AWSも検討事項としてロードマップに挙げている
- Allow App Runner services to talk to AWS resources in a private Amazon VPC · Issue #1 · aws/apprunner-roadmap
質問: WAF対応を求めています！(そんなロードマップはありますか)
検討対象にあがっています。
質問: Lightsailとどう違うんですか
- Lightsailはあり物のパッケージをさっと作るイメージ。VPS
- LightsailはLightsail内に閉じる。DBもLightsail内で作るとか。App RunnerはAWSのエコシステムの一部として機能する。 ARはAWSのエコシステムと連携する前提 例: IAM Role LightSailにはコード渡してコンテナ化してくれる機能はない
質問: App Runnerで起動した複数のアプリケーションをApp Meshで繋ぐことはできますか？
現状はできません。
質問: 最小サイズ0（コールドスタート）でよければAPI Gateway+Lambda（コンテナ）でいい、という感じだったりするかな？
- 前述のポーズで事足りるのであればApp Runnerが使える。
- Lambdaはプロセスを実行する環境ではないので、お使いのアプリケーションフレームワークが対応していないかも。
質問: インスタンスは実態としてリージョンに属するいずれかのAZ上に起動される（実際、利用者側は意識しない）と思うのですが、AZ障害を考慮して可用性をすると、2台以上起動しておくことは有効なのでしょうか？また、その場合、裏でマルチAZにベストエフォートで分散される動きになるのでしょうか？
- App Runnerの抽象度、隠しているものを考えると、意識しないで使うので良い
質問: CDK ではまだ作れないですよね
- CDKもある。L1のみだけど。でもL1でもそんなに大変じゃない。
- CFnでもリソース一つだけで書ける
質問: ECS+Fargateをお手軽ラッパーしてくれてるイメージですかね
- ラッパーの定義次第だが、ラップじゃなくて隠蔽しているイメージ
- また、前述の通りECSやFargateだけじゃない部分もカバーしている。CI/CDとか。ECR Image Scanningとか。 カスタムドメインのSSL証明書自動設定も嬉しい
質問: 新たなサービスを開発する時、まずはサクッとApp Runnerで公開して、色々物足りなくなったらECSに移植して拡張する、という使い方がいいのかなと思いました。
- はい。 コントロールできる部分が意図的に隠蔽化されているのがApp Runnerなので、コントロールしたくなったら移行するのが良い。(規模の問題ではない)
10
