[KUSANAGI×Laravel]サーバーリプレイス作業メモ

はじめに

ConoHaの「Laravelアプリケーション」環境で情報サイトを公開しているのですが、どうしてもSSL化ができなくてサーバーを再構築することで解決しようと決断しました。2年前、とにかく楽をしようと思って「Laravelアプリケーション」環境を選択してVPSを立ち上げたのですが私のインフラ関連の技術力では、逆に大変な思いをすることになり、最初からいつも使っているKUSANAGIを選んでおけばよかったと後悔しています。ゆえに今回KUSANAGIを使ったサーバーに、Laravelで開発したWebアプリをデプロイしてからSSL化してしまおうという目論見です。以下、作業手順を記録します。

【バージョンについて】

開発済みのLaravelアプリはLaravel Framework 5.7.29で構築されたものです。

リプレイス先のKUSANAGIはKUSANAGI Version 9.2.6-2.el8です。
KUSANAGI9です。

OSはCentOS Stream release 8 になります。

バックアップファイル(DB)をダウンロード

1日毎にDBをバックアップする処理をバッチで動かしています。1ファイルで20GBオーバーになっていました。ダウンロードに1時間弱かかりました。

検証環境を立ち上げる

いきなりサーバーを消して、新しくサーバーを立ち上げてアプリをデプロイするという手順は復帰できなくなるリスクが高すぎてできません。ので、まずは検証環境を立ち上げ、そこにデプロイして一度本番環境と同様に動作する環境を構築します。

KUSANAGIを選択してVPSを新規契約する

ドメインの設定をする

KUSANAGIでSSL設定をする場合、プロビジョニングの段階でドメイン設定が完了している必要があるので、先にDNSレコード設定しておきます。反映に時間がかかるので。

検証環境にSSH接続をしてinit

dnf update -y

reboot

kusanagi init --tz Asia/Tokyo --lang ja --keyboard ja --passwd ******** --nophrase --dbrootpass ******** --nginx121 --php80 --mariadb10.5 --ruby26

40分ぐらいかかりました。

LAMPをプロビジョニング

まず、コマンドプロンプトを立ち上げてドメインに対してpingが通るか確認します。

ping test.tuberan.jp

無事IPが返却されたのでドメインの設定が完了していることを確認できました。
プロビジョニングを実施します。

kusanagi provision --lamp --fqdn test.tuberan.jp --email ******** --dbname ******** --dbuser ******** --dbpass ******** tuberan

プロビジョニングはすぐ終わりました。

リダイレクト設定をしておきます。

kusanagi ssl --https redirect tuberan

GitHubからアプリをデプロイ

サーバーの構成を確認します。/home/kusanagi/tuberan の配下は以下のようになっています。

DocumentRoot と log があるのみ。

この階層でアプリをクローンします。

git clone https://github.com/********

Nginxのconf.dのルートディレクトリを変更する

Nginxのルートディレクトリについて、初期状態だとDocumentRoot配下が指定されているのでクローンしたアプリのpublicディレクトリを指定するように変更します。

/etc/opt/kusanagi/nginx/conf.d/tuberan.conf

root /home/kusanagi/tuberan/tuberan/tuberan-app/public;

~~※既にsslリダイレクト設定をしているので、443のみ変更。~~

~~NGINX再起動~~

systemctl restart nginx

※後日追記

この手順だと3か月後にSSL証明書自動更新で失敗します。代替の手順については以下をご確認ください。

.env ファイルを作成する

cp .env.example .env

中身を修正する(ここでは省略)

composer

composer install を実施したいが以下のエラー。composer update が必要。

Warning: The lock file is not up to date with the latest changes in composer.json. You may be getting outdated dependencies. It is recommended that you run `composer update` or `composer update `.
Your lock file does not contain a compatible set of packages. Please run composer update.

composer update 実施。以下のエラー。phpのバージョンがLaravelのバージョンに対応していない。php8からphp7にダウングレードする必要がある。

Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Root composer.json requires doctrine/common 2.7.3 -> satisfiable by doctrine/common[v2.7.3].
    - doctrine/common v2.7.3 requires php ~5.6|~7.0 -> your php version (8.0.22) does not satisfy that requirement.
  Problem 2
    - laravel/framework[v5.7.0, ..., v5.7.29] require php ^7.1.3 -> your php version (8.0.22) does not satisfy that requirement.
    - Root composer.json requires laravel/framework 5.7.* -> satisfiable by laravel/framework[v5.7.0, ..., v5.7.29].

Use the option --with-all-dependencies (-W) to allow upgrades, downgrades and removals for packages currently locked to specific versions.

便利なことにKUSANAGIではphpのバージョンを簡単に変更できる。

kusanagi php --use php74

ダウングレード完了。再度composer install からの composer update を実施。

無事完了したらキージェネレートを実施。

php artisan key:generate

アプリの使用準備が整いました。

.env ファイルを何度も書き換えたい場合があると思います。書き換えた直後は反映されないようなので以下を実施する必要があります。

php artisan config:cache
php artisan config:clear
php artisan cache:clear

migrate実施

php artisan migrate

テーブルが作成されました。

ダウンロードしたDBバックアップファイルをimport

DBクライアントツールを使ってバックアップを検証環境に復元しました。(HeidiSQLを使用しています。)

※所要時間2時間半と表示されましたが実質1時間ぐらいで終わった。

検証環境の構築が完了！

表示時に権限周りでエラーが出たので以下の対応を実施。

storage

chmod -R 777 framework
chmod -R 777 logs

bootstrap

chmod -R 777 cache

無事表示されました。本番環境と同様に動作します。

ここでやっと半分ぐらいです。

本番環境のバックアップファイルを削除しイメージを保存

念には念を。旧(現本番)環境のイメージを保存しました。(バックアップファイルを削除するのは、20GBあるファイルを削除しないと無料枠の範囲内でイメージを保存することができないため)

保存の際に少し詰まったので、以下の記事もぜひ参照くださいませ。

ConoHaVPSでイメージの保存ができなかった際にやったこと

バッチが動作するか確認

コマンド実行から確認

まずは独自のartisanコマンド(今回はDBバックアップ処理)をコンソールから実行。

# php artisan bkup
bkupコマンド開始します。
bkupコマンド完了しました。

怖いぐらい何も問題なく完了、実際にバックアップファイルも生成されていることを確認しました。

cronの確認

念のため設定時刻通りにバッチが実行されるかどうかも確認(目玉機能であるため)。

案の定、うまく実行できずでした。原因と対策は以下にまとめました。

KUSANAGIのLAMPに構築したLaravelアプリのcronバッチが実行されない

cronが正常に動くようになったことを確認できました。

いよいよ本番サーバーの再構築作業です。

本番サーバーのリセット＋再構築

まずはサーバーをシャットダウンします。いよいよ再構築作業。

イメージを保存しているし検証環境でサービスの複製は完了しているので、思い切って立て直します！

再構築押しました。上記、「検証環境を立ち上げる」の手順を繰り返します。

完了・まとめ

検証環境構築時にたくさん失敗したので、再構築作業はあっという間に完了しました。特に行き詰まることもなくスムーズにおわったので、当記事もここまでとさせていただきます。

あとは明日バッチが問題なく時間通りに動作してくれることを祈るばかりです。

以上になります。