複数の作業をやっているときに、マルチタスクが出来る派でしょうか?たとえば、iOSアプリのビルドをしながら、画像作成をGimpでやる...などできる?方の私です。シングルタスクの方がかえって効率的なのかな... とか妙なところで悩みます。

そんな今日この頃ですが、Hackerの皆様はいかがお過ごしでございましょうか。

以前の連載ポストは以下から

Laravel Vaporを立ち上げてみる連載となりますが、すでに

を書かせていただきました。よろしければこちらも併せてご覧ください。

本記事のゴール

VaporをつかってLaravelをサーバレス環境にデプロイし、インフラの運用コストの低減を試みる

第3回の今回は、立ち上げ済みのVaporに、データベース(Mysql) を追加し、接続するまでを解説します。

DBの作成

データベースを画面から立ち上げる

早速進めてまいります。

サイドバーからプロジェクト名をクリックし、Environments => production をクリックします。

vp302.png

Create database をクリックします。

vp303.png

出てきた画面で「CREATE DATABASE」を再度クリック(少々わかりにくい)

vp304.png

MySQLとPostgresqlから選べるみたいですが、今回はMySQLにします。

Free Tier(無料枠)があるdb.t2.microを選びます。(※後ほど検証したので下記注意点!の項をご覧ください)後で試してみますが、複数プロジェクトで併用できるとこちらにも書いてありますが、中身がAWS RDSなので、やはり 趣味のプロジェクトなどではかなり割高 になってしまいますね。これはしょうがないかと思います。

vp305.png

以下のように設定します。

注意点!

仮に、最小の「db.t2.micro」を選択したとしても、状況により請求はされることがあります のでご注意ください。Free Tier Eligible という表記があったので、無料枠に収まるかなと思っていたのですが...

下記のようにきっちり請求されています(おそらく2000円台/月くらいは請求されます)

月の途中の実績のため、月単位では2000円台の請求となりそう

月の途中の実績のため、月単位では2000円台の請求となりそう

これは、私の場合 AWSのアカウントを開設してから1年以上経過しているため、無料の対象から出てしまったことによる ものと思います。

RDSの無料利用枠説明のページでも

AWS 無料利用枠には、Amazon Relational Database Service (RDS) での、1 年間毎月 750 時間の db.t2.micro インスタンス、20 GB のストレージ、20 GB のバックアップ用ストレージが含まれます。

1年間限定である旨が書かれています。

そういう意味では、Vapor上の「Free Tier Eligble」という表記は間違ってはないのですが、ちょっとわかりにくいです。(Free Tier適用可能、という感じでしょうか)特にAWSの料金体系に慣れていない方はDBの利用にあたってはご注意ください。

Vaporに戻って立ち上げを続ける

さて、話を戻します。Vaporの作成画面に戻ると

vp306.png

AWS RDSを背後のアーキテクチャとしてそのまま利用していて、ラッパーするような形になっていますね。公式ドキュメントにも

Laravel Vapor is an auto-scaling, serverless deployment platform for Laravel, powered by AWS Lambda.

Laravel Vaporは、AWS Lambdaを利用したLaravelの自動スケーリング、サーバーレスデプロイメントプラットフォームです。

書かれています。

UserとPasswordが出来上がるので保存しておきましょう (このパスワードは事後的に管理ツールから確認できるみたいではありますが)

立ち上がりました。

vp307.png

こちらのUserとPasswordを、使っていきます

プロジェクトをgitでローカルにチェックアウトする

githubにアクセスし、当該プロジェクトページを開きます。

以下のコマンドでローカルに、ここまでの手順で立ち上げ済みのlaravelVaporプロジェクトをクローンしてきます。(プロジェクト名などは各自の環境に併せて読み替えてください。)

git clone git@github.com:yutav/laravelVapor.git

このLaravelはVaporのための機能がすでに組み込まれている状態 になっています。

ローカルで必要な設定を実施

以下はMacでの実行を前提とします。順番に実行していきます。

# ライブラリをインストール
composer install

# 設定ファイルを準備
cp -i .env.example .env
php artisan key:generate

# 秘密鍵を生成
php artisan key:generate

# 開発用の簡易Webサーバを立ち上げ
php artisan serve

ブラウザから確認

この状態で

http://localhost:8000/

にアクセスを行います

閲覧できました

閲覧できました

この状態で、databaseに接続する設定を行います。

.envを書き換え

先ほど画面から作成したdatabaseのUserとPasswordをここで使います。

.envを開き以下のように書き換えます。

DB_CONNECTION=mysql
DB_HOST=laravelvapordb.xxxxxxx.us-east-1.rds.amazonaws.com // Databasesの当該データベースのホストを入力
DB_PORT=3306
DB_DATABASE=vapor // データベース名は「vapor」
DB_USERNAME=vapor // ユーザー名は「vapor」
DB_PASSWORD=xxxxxxxxxxx // 発行済みのパスワード

ちょっと通常のAWS RDSインスタンスや、Laravel SailでMySQLサーバを立ち上げた時と違うところがあるのでご注意ください。

なお、Laravel Sailについては以下の記事でも紹介しています。ご興味がございましたら併せてご覧ください。

参考記事: 【開発環境】Laravel+Filamentでらくらく管理画面を構築する方法。 第1回 ベース構築編

.envの変更を取り込む

php artisan config:cache

そして、この状態でマイグレーションを実行し、vaporのデータベースとの疎通を確認します。

php artisan migrate
マイグレーションを実行

マイグレーションを実行

マイグレーションファイルに沿った新しいテーブルができ、無事ローカル => vaporのDBとの接続ができました。

ただ、めちゃくちゃ実行が遅いですね。。 おそらく、無料DBということで複数のプロジェクトと共有のインスタンスになっているのでしょう。このまま利用するのは実用面では厳しいと思うので、その点は注意が必要です。

Vapor上のプロジェクトとVaporのDBとの接続を行う

プロジェクトルート直下のvapor.ymlを以下のように書き換えます。

// 基本的には以下以外は書き換えないでください。
id: xxxx // 初期値のままでOK
name: laravelVapor // Vaporプロジェクトの名称
environments:
    production:
        database: laravelVaporDB // 立ち上げたVaporDBの名称

この状態でgitにコミットします。なお、初期設定で.envは除外されていると思いますが、コミットはしないようにしてください。パスワードが書かれていますので、不正利用されるリスクもゼロとはいえないため(githubのレポジトリをpublicにしなければ晒されることはないですが この点は注意です)

gitにプロジェクトの変更を反映

git add *
git commit -m 'changed vapor.yml'
git push

Gitにプッシュを行うとデプロイが行われるので少々待ちます。

プロジェクトには、あらかじめLaravel Vaporに「production」ブランチをプッシュするたび 変更を反映する設定が組み込まれています。

よって、githubの**「Actions」**からデプロイ状況の確認が可能です。

vp301.png

URLは私の作成した「laravelVapor」レポジトリでは以下でした。

https://github.com/yutav/laravelVapor/actions

特に問題なければ、グリーンのチェックがつく と思います。赤枠のURLを閲覧して問題がなければ接続設定は完了です。

vp312.png

次回から、Localで動作確認できたDBの参照設定はVapor上でも動くと思います。Localからと、Vaporからで接続するDBが同じになりますからね。

まとめ

Databaseについては無料ではPublicが基本で、外部からの接続ができてしまうということでセキュリティ面に問題がありそうだったり、 (といっても、そこまで厳格なセキュリティを求められないプロジェクトならば、ID/PWの接続は許容される範囲か)

共有インスタンスでは実用面で厳しいということで色々ウィークポイントも見えてきたところはあります。

LaravelはバックエンドフレームワークなのでDBとの連携は必須となってくる場合がほとんどでしょうから、その辺りは将来に向けて改善が図られるといいなと思いました。個人的にはもう少し安い有料のミニマムプランがあると商用でも 使いやすいかな と思います!

次回は、ストレージの追加について解説してまいります。


この記事が何かのお役に立てれば幸いです。
最後までお読みいただきありがとうございました!

前回の連載 は下記のリンクからどうぞ!