2023-11-18に開催されたJAWS-UG金沢 #94 & Kanazawa.rb 『Ruby on Rails on App Runner ハンズオン』に参加しました。久しぶりの参加記というかメモみたいなものを書き残しておきます。
フルマネージド型のコンテナアプリケーションサービスであるApp RunnerでRuby on Rails製のWebアプリケーションを動かすという内容です。App Runnerについては以下のリンクでどのようなものかが説明されています。
内容を掻い摘むとこんなところでしょうか。
ハンズオンは、App Runnerの概要、パブリックなDockerイメージになっているアプリケーションをデプロイして動かす、Ruby on Railsのソースコードをデプロイして動かす、という流れで進みました。まずは、Dockerイメージになったアプリケーションとして mermaid-live-editor をデプロイしました。こちらのリポジトリにアクセスするとghcr.ioにプッシュされたイメージが存在すると記載されていますが、残念ながらApp RunnerではECR（プライベート）かECRパブリックにプッシュされたイメージしか利用できません。このため、ECRパブリックにプッシュしてもらったmermaid-live-editorイメージを利用しました。
App Runnerではまず「サービス」を作ります。App Runnerのコンソール（Web UI）で必要な項目を入力し、ポチポチボタンをクリックしていけば簡単に作れます。サービスが作成されると、ドメインが自動生成されてそこにアクセスできます。めちゃくちゃ簡単です。VPCを作って、サブネットを作って、ALB作って、みたいな操作は私は一切していません。
次に、Ruby on Railsのソースコードをデプロイして動かしました。題材は以下のリポジトリです。
App Runnerはコンテナアプリケーションサービスですが、ソースコードを基にしても動かすことができます（内部でDockerイメージにビルドしてそれをデプロイしているようです）。App Runnerはいくつかのプログラム言語に対応するランタイムを提供しており、その上でアプリケーションが稼動する形になります。ランタイムにはRubyも対応しているためこちらを利用します。デプロイしたいソースコードのリポジトリにはapprunner.yamlというファイルを配置しておきます。このファイルの構成は以下ドキュメントを参照してください。
apprunner.yamlはtopセクション、buildセクション、runセクションの主な3つのセクションに分かれています。特にbuildセクションとrunセクションが大事なところで、前者はアプリケーションのビルド方法を宣言し、後者はアプリケーションの実行方法を宣言します。先ほどのハンズオンアプリケーションのapprunner.yamlを例にするとイメージしやすいかと思います。
version: 1.0 runtime: ruby31 build: commands: build: - sudo yum install -y libyaml-devel postgresql-devel - bundle install - bundle exec rails db:migrate - bundle exec rails assets:precompile env: - name: RAILS_ENV value: production - name: RACK_ENV value: production # ... run: runtime-version: 3.1.4 command: bundle exec rails server --binding=0.0.0.0 network: port: 3000 env: - name: RAILS_ENV value: production - name: RACK_ENV value: production # ...
このようなファイルを作成し、リポジトリをApp Runnerと連携しサービスを作成すれば、こちらも自動生成されたドメインからアクセスできるようになります。Dockerfileを作る代わりにapprunner.yamlを作ればコンテナアプリケーションとして動くのは良くできているなあと思います。
RAILS_MASTER_KEYどう扱うか問題
ここから少し細かい話題になりますが、Ruby on Railsアプリケーションを本番環境として動かすには RAILS_MASTER_KEY や SECRET_KEY_BASE を環境変数で設定することがあります。apprunner.yamlでも環境変数を設定できますが、先ほどの環境変数はリポジトリに公開すべきではないものなので別の方法で設定するのが良いでしょう。
App RunnerではSecrets ManagerやSystems Manager Parameter Storeに保管されたシークレット値を参照できます。なので、先ほどの値をSecrets Managerに保管しておけば安全にApp Runnerで利用できます。
apprunner.yamlでは例えば以下のように設定することでSecrets Managerに保管されたシークレットを環境変数として参照できます。現時点（2023年11月）だとrunセクションのみでsecretsの指定が有効でした。*1
run: # ... secrets: - name: RAILS_MASTER_KEY value-from: 'arn:aws:secretsmanager:<region>:<aws_account_id>:secret:XXXXXXXXXXXX'
感想
今回初めてApp Runnerを触ってみました。手っ取り早くアプリケーションを動かす環境を用意できる印象を持ちました。ハンズオンではApp Runnerのサービスを作成しアプリケーションをデプロイすればOKでした。ただ、より現実に近いパターンとしてはWebアプリケーションサーバーからDB（not in-memory）や他のAWSサービスに接続することが多いので、こうなると開発者がAWSのサービスを組み合わせて環境を作る必要があり多少の難しさは出てくると思います。今のところ、AWSのアカウントがある状態で開発初期にモックサーバーを動かす用途（Web APIとして開発する想定）だと使い勝手が良さそうと個人的には考えています。
App Runnerはまだ発展途上のサービスだと思いますが、こちらにロードマップが公開されていて今後実装される予定の機能を追うことができます。興味のある方はウォッチしておくと良さげですね。
*1:https://github.com/aws/apprunner-roadmap/issues/48 でbuildセクションでもシークレットを注入できるようにというリクエストがあり、今後導入されるかもしれません。
