Blogaomu

WEBアプリケーション開発とその周辺のメモをゆるふわに書いていきます。

JAWS-UG金沢 #94 & Kanazawa.rb 『Ruby on Rails on App Runner ハンズオン』に参加しました

2023-11-18に開催されたJAWS-UG金沢 #94 & Kanazawa.rb 『Ruby on Rails on App Runner ハンズオン』に参加しました。久しぶりの参加記というかメモみたいなものを書き残しておきます。

jawsug-kanazawa.doorkeeper.jp

フルマネージド型のコンテナアプリケーションサービスであるApp RunnerでRuby on Rails製のWebアプリケーションを動かすという内容です。App Runnerについては以下のリンクでどのようなものかが説明されています。

aws.amazon.com

内容を掻い摘むとこんなところでしょうか。

  • インフラに関してそれほど経験なくても良い感じの基盤で動かしてくれる
  • オートスケーリングも良い感じにやってくれる
  • なのでアプリ開発に集中できるよ
  • 他のAWSサービスとも組み合わせられる

ハンズオンは、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ソースコードをデプロイして動かしました。題材は以下のリポジトリです。

github.com

App Runnerはコンテナアプリケーションサービスですが、ソースコードを基にしても動かすことができます(内部でDockerイメージにビルドしてそれをデプロイしているようです)。App Runnerはいくつかのプログラム言語に対応するランタイムを提供しており、その上でアプリケーションが稼動する形になります。ランタイムにはRubyも対応しているためこちらを利用します。デプロイしたいソースコードリポジトリにはapprunner.yamlというファイルを配置しておきます。このファイルの構成は以下ドキュメントを参照してください。

docs.aws.amazon.com

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_KEYSECRET_KEY_BASE環境変数で設定することがあります。apprunner.yamlでも環境変数を設定できますが、先ほどの環境変数リポジトリに公開すべきではないものなので別の方法で設定するのが良いでしょう。

guides.rubyonrails.org

App RunnerではSecrets ManagerやSystems Manager Parameter Storeに保管されたシークレット値を参照できます。なので、先ほどの値をSecrets Managerに保管しておけば安全にApp Runnerで利用できます。

docs.aws.amazon.com

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はまだ発展途上のサービスだと思いますが、こちらにロードマップが公開されていて今後実装される予定の機能を追うことができます。興味のある方はウォッチしておくと良さげですね。

github.com

*1:https://github.com/aws/apprunner-roadmap/issues/48 でbuildセクションでもシークレットを注入できるようにというリクエストがあり、今後導入されるかもしれません。