【2022年3月最新】RDSを用いたDjangoアプリをAWS App Runnerにデプロイする方法
そもそもAWS App Runnerとは何か？
AWS App Runner は、Webアプリを簡単かつ迅速にデプロイできるフルマネージド型サービスです。
App Runnerは、Webアプリのソースコードリポジトリまたはコンテナレジストリが変更された際に、自動で再デプロイしてくれます。さらに、リクエストの数に応じて自動でスケールし、SSL/TLSを付したロードバランサーを作成してくれます。
このような利点から、開発者はほとんどWebアプリの開発のみに集中できるのです。
App RunnerのVPC内通信への対応🎉 (2022.02.08)
そんなApp Runnerですが、最近まで重大な課題を抱えていました。それは、VPC内のリソースへのアクセスが行えないということです。例えばApp Runnerと共にRDSを用いるには、RDSをパブリックサブネットに配置し、外部からアクセスできる状態にしなければなりませんでした。セキュリティの観点からこのような構成は避けるべきであり、実用上は使用するのが難しかったのです。
しかし2022年2月8日、待望の機能拡張が告知されました。App RunnerでVPC内のリソースへのアクセスが可能となったのです🎉 これはつまり、RDSを用いるWebアプリを、App Runnerを使って運用可能になったということです！（しかし注意点もあり、これは最後に述べようと思います）
そこでこの記事では、DjangoアプリをApp Runnerにデプロイし、RDSとの接続を行うための方法をご紹介します。DjangoアプリをApp Runnerにデプロイする方法は大きく分けて2つあります。1つは、Webアプリのソースコードレポジトリをデプロイする方法です。もう1つは、Dockerを用いてWebアプリをコンテナ化したものをデプロイする方法です。今回は、ソースコードレポジトリをデプロイする方法について解説します。
STEP 1: VPCの設定を行う
STEP1では、RDSインスタンスを配置するためのVPCを作成し、設定を行います。
STEP 1-1: VPCを作成する
まずはVPCのページに移動し、以下のような設定で、VPCの作成を行います。
STEP 1-2: VPCサブネットを作成する
続いて、以下の4つのVPCサブネットを作成します。
- DjangoRunnerPublicSubnet1a (AZ: ap-northeast-1a, IPv4 CIDR ブロック: 45.45.0.0/24)
- DjangoRunnerPrivateSubnet1a (AZ: ap-northeast-1a, IPv4 CIDR ブロック: 45.45.1.0/24)
- DjangoRunnerPublicSubnet1c (AZ: ap-northeast-1c, IPv4 CIDR ブロック: 45.45.2.0/24)
- DjangoRunnerPrivateSubnet1c (AZ: ap-northeast-1c, IPv4 CIDR ブロック: 45.45.3.0/24)
STEP 1-3: IGWをVPCにアタッチする
VPCがインターネットと接続できるように、IGW(インターネットゲートウェイ)を作成し、先ほど作成したVPCにアタッチしましょう。
STEP 1-4: ルートテーブルを作成する
VPCとしてDjangoRunnerVPCを選択し、ルートテーブルを作成します。
この時、VPC内部のルーティングは自動で完成しています。ですから、ルートテーブルに関してここで行うべきことは、VPC外部との通信のための設定です。すなわち、パブリックサブネットのルーティングをIGWに向けてやります。
以下のように、先ほど作成したルートテーブルを選択し、「ルートを編集」ボタンを押します。
遷移先の画面で「ルートを追加」ボタンを押し、0.0.0.0/0 の送信先を、先ほど作成したIGWに向けます。
STEP 1-5: ルートテーブルをサブネットに関連付ける
VPCに関する設定は最後になります！
先ほど設定したルートテーブルを、パブリックサブネットに関連付けます。というのも、インターネットとの接続を許可するのは、パブリックサブネットのみにしたいからです。
ルートテーブルの画面で「アクション」ボタンを押し、「サブネットの関連付けを編集」を押します。
そして、STEP 1-2の1番と3番に該当するパブリックサブネットを選択し、関連付けを保存します。
以上で、VPCの設定は終了となります🎉
STEP 2: RDSインスタンスを配置する
STEP2では、プライベートサブネットにRDSインスタンスを配置していきます。
このようなインフラ構成でもApp Runnerを使用できるようになったことが、今回のApp Runnerのアップデートの一番の重要なポイントと言っても過言ではないのでしたね！🏃♂️
STEP 2-1: DBサブネットグループを作成する
まずはRDSのページに移動し、DBサブネットグループの作成します。DBサブネットグループとは、RDSインスタンスを配置するためのサブネット群です。
VPCとしてDjangoRunnerVPC、AZとしてap-northeast-1aとap-northeast-1c、サブネットとしてSTEP 1-2の2番と4番に該当するプライベートサブネットを選択します。
STEP 2-2: RDSインスタンスをDBサブネットグループ内に配置する
続いて、実際にRDSを先ほど作成したDBサブネットグループに配置します。設定する箇所はいくつもありますが、基本的に以下のようにしてみてください。
なお、PostgreSQLのマスターユーザ名とマスターパスワードは、ご自身のお好きなように設定してください。ただし、それらを覚えておいてください。
作成ボタンを押してからしばらく待つと、上記の設定でRDSインスタンスが作成されるはずです。
STEP 2-3: RDSインスタンスのエンドポイントを控えておく
無事にRDSインスタンスが作成されたら、そのエンドポイントを控えておいてください。
これでRDSインスタンスをVPCプライベートサブネットに配置することができました🎉
STEP 3: セキュリティグループの設定を行う
STEP3では、特定のリクエストによるリソースアクセスのみを許可することでセキュリティを強くするために、セキュリティグループを設定します。
具体的には、App Runner用のセキュリティグループを新たに作成し、RDSインスタンス作成時に自動で作成されるRDS用のセキュリティグループに関しては改変を行います。
STEP 3-1: App Runner用のセキュリティグループを作成する
App Runnerインスタンスを作成する前に、App Runner用のセキュリティグループを作成します。
セキュリティグループのページに移動し、「セキュリティグループの作成」ボタンを押します。
遷移先の画面で、VPCとしてDjangoRunnerVPCを選択し、DjangoRunnerSGという名前のセキュリティグループを作成します。
STEP 3-2: RDSインスタンス用のセキュリティグループを改変する
続いて、STEP2でRDSインスタンス作成時に自動で作成されるセキュリティグループを改変します。
具体的には、STEP3-1で作成したApp Runner用のセキュリティグループからのインバウンド通信を許可します。
まず、STEP2で作成したRDSインスタンスのページに移動し、セキュリティグループのDjangoRunnerDBSecurityGroupを押します。(以下の画像の最下部)
そして、以下の画面に遷移したら、再びセキュリティグループを選択します。
すると、「インバウンドルールの編集」ボタンがあると思いますので、それを押します。(以下の画像の右下)
ここでインバウンドルール、すなわちRDSインスタンスにアクセスできる通信のフィルタリング設定をします。
今回は DjangoRunnerSG をソースとし、PostgreSQLタイプの通信をルールに追加しましょう。
これで、セキュリティグループの設定は完了です🎉
STEP 4: App Runnerにデプロイする
ついに最後のSTEPです！
STEP4では、App Runnerインスタンスを作成し、実際にDjangoアプリをデプロイします！
STEP 4-1: サンプルアプリケーションのソースコードレポジトリをForkする
App Runnerインスタンスを作成する前に、今回デプロイするサンプルアプリケーションのソースコードレポジトリをForkしましょう。
ソースコードはこちら( → https://github.com/Hibagon1go/apprunner_django ) にあります！
STEP 4-2: App Runner作成ページに移動する
ついにApp Runnerインスタンスを作成していきます！
App Runnerページに移動し、「App Runnerサービスを作成」ボタンを押します。
STEP 4-3: ソースおよびデプロイの設定をする
ソースおよびデプロイの設定をします。
今回は、ソースコードレポジトリをデプロイするのですが、その際GitHubに接続を行う必要があります。
「新規追加」ボタンからあなたのGitHubアカウントおよび今回デプロイするアプリケーションのソースコードレポジトリ(STEP4-1でForkしてもらったもの)を選択します。
STEP4-4: ビルドの設定をする
続いて、ビルド時の設定を行います。すなわち、App Ruunerインスタンスが立ち上がる時に行うコマンドなどをここで設定します。
今回は、ランタイムとしてPython3を利用し、環境構築コマンドとして pip install -r requirements.txt を、開始コマンドとして bash start.sh を設定します。
STEP4-5: サービスの設定をする
ついに最後のSTEPです！！
ここでは、インスタンスのスペック、環境変数、スケーリング、VPC接続の設定などを行います。
今回、環境変数としては、DB_HOSTとして「STEP2-3で控えたRDSインスタンスのエンドポイント」を、DB_PASSWORDとして「STEP2-2においてあなたが設定したパスワード」を入れてください。
環境変数を設定したら、ネットワーキングという項目に行ってください。
以下のようにカスタムVPCを選択し、「新規追加」ボタンを押します。
ここで、VPCコネクタというものを追加します。
VPCとしてSTEP1-1で作成したDjangoRunnerVPCを、サブネットとしてSTEP1-2で作成したプライベートサブネット達(2番と4番)を、セキュリティグループとしてSTEP4-1で作成したDjangoRunnerSGを選択します。
ネットワーキングで、作成したVPCコネクターを選択し、「作成とデプロイ」ボタンを押しましょう！！
しばらく待ち、App Runnerのサービスが正常に作成されたら、デフォルトドメインのURLにアクセスしてみましょう！
これで無事にDjangoアプリケーションをApp Runnerにデプロイできましたね🎉
GitHubの指定したブランチに変更をpushすると、その変更も自動で再デプロイされていることもぜひ確認してみましょう！
また、Route53にドメインをお持ちの方は、カスタムドメインタブから簡単にリンクすることもできます！
AWS App Runnerの注意点
最初に申し上げましたAWS App Runnerの注意点をここで述べておきます。
AWS公式サイトによると、App Runnerからインターネット通信を行う際には、NATゲートウェイが必要となるという点です。
これは、App RunnerをVPCプライベートサブネット内のRDSに接続する形で使う際、App RunnerはVPCプライベートサブネットに配置されるのと等しいため、App Runnerからのアウトバウンド通信はそのままではインターネットに出られないのです。
ちなみに、インターネットに出る必要はなく、S3やSQSを使いたい場合は、VPCエンドポイントを使えば良いそうです！
おわりに
今回のアップデートで断然便利になったApp Runner、みなさんも是非使ってみてくださいね！
じゃんけん、ぽん！✊ｳﾌﾌﾌﾌﾌ