LoginSignup
0
3

More than 1 year has passed since last update.

【Laravel 】専用サーバにデプロイした時のメモ

Last updated at Posted at 2022-07-01

会社で契約してる専用サーバにLaravel × Vue のプロジェクトをデプロイした時のメモ。今までは共用のレンタルサーバにしかデプロイしたことがなく(!)、いくつか躓いた点があった。

環境 : Laravel8 MySQL CentOS

ざっくり手順

前提:PHPやapacheやMySQLは既に入っている状態。

SSHログイン

まだ入ってなければgitとcomposerとnvm(等のnodeバージョン管理ツール)とnode.js・npmをインストール

秘密鍵と公開鍵を作成

公開鍵をGitHub(もしくはBitBucket等)に登録

リモートリポジトリからgit clone

シンボリックリンクの設定

$ composer install コマンド

$ npm install コマンド

$ npm run prod コマンド

まだしてなければenvファイルの設定

DB作成

$ php artisan migrate コマンド

諸々の確認

公開

シンボリックリンクの設定で躓く

ドメイン名直下の階層にhtdocs(環境によってはhtdocsではなくpublic_htmlやwwwというフォルダ名かもしれない)があるが、Laravelのソースファイルはセキュリティ的に公開領域には置かないほうがいいので、非公開領域(htdocsと同じ階層)にプロジェクト名のディレクトリを作成し、そこでgit clone実行。

当然このままでは公開領域であるhtdocs以下に何もファイルがないのでブラウザで当該ドメインにアクセスしても何も表示できない。Laravelプロジェクトのドキュメントルートはプロジェクトフォルダ直下のpublicフォルダなので、上記のhtdocsからこのpublicへ飛ぶようにシンボリックリンクを設定する必要がある。

具体的には、「もともとあったhtdocsディレクトリを削除して、新たにhtdocsという名前でシンボリックリンクを作成する」という対応で問題ない。しかし、"htdocsは触ってはならないもの"という感覚があり削除するという発想が浮かばず、どうすればいいのか気付くまでに時間がかかってしまった。

なお、上記以外に「もともとあるhtdocsの中に、シンボリックリンクと、そのシンボリックリンクへ転送させるためのhtaccessを作成する」というやり方を紹介しているサイトもある。権限などの関係でhtdocsを削除できない場合等はこちらの方法をとる必要があるかもしれない。

DB接続で躓く

DBの接続でも躓いてしまった。DBは作成済でenvファイルの設定も済ませてあるのに、migrateを実行すると下記エラーが出てしまう。
No such file or directory (SQL: select * from information_schema.tables where table_schema ~~~~

結論としては、ローカル開発環境や共用レンタルサーバへのデプロイ時には必要なかった「DB_SOCKET」という項目とその値をenvに追記することでDBと接続できるようになった。以下がその際のDB設定(説明に必要な箇所以外は伏字にしてあります)

DB_CONNECTION=mysql
DB_HOST=localhost
DB_PORT=3306
DB_DATABASE=*******
DB_USERNAME=*******
DB_PASSWORD=*******
DB_SOCKET=/usr/local/mysql/var/mysql.sock

なぜ今回はDB_SOCKETが必要だったのか気になり調べてみたところ、以下の内容が確認できた。

■ DBへの接続には「TCP接続」と「UNIXドメインソケットを使用した接続」がある。
■「UNIXドメインソケットを使用した接続」は、WebサーバとDBサーバが同じOS(ホスト)上で動作している場合に使用可能で、TCP接続よりもパフォーマンスが良いとされている。
■ DB_HOSTにlocalhostと入力した場合は、自動的にUNIXドメインソケットを使用した接続を行おうとする。
■ DB_HOSTに127.0.0.1と入力した場合は、TCP接続を行おうとする。

なるほど確かにDBホストは共用のレンタルサーバの時は指定の別ホストにしていたし、ローカル開発の際は127.0.0.1にしていた。なお、それぞれの接続の詳しい仕組みも検索してみたが、なんか深そうだったので一旦見なかったことにした。

以下、参考にさせて頂いた記事様です。

ログのパーミッションで躓く

migrateも無事完了したのでブラウザでサイトにアクセスしてみたところ、以下のPermissionエラーが出た。

The stream or file "~~~/laravel/storage/logs/laravel.log" could not be opened in append mode: failed to open stream: Permission denied

通常、laravel.logファイルはappach(今回の場合は)によって自動更新されるが、logファイルへの書き込み権限がappachに無いためエラーが出てしまっている。もともと社内の限られた人間しかアクセスできない部分なので、単純にパーミッションを666とかに変更するだけで良いかもしれないとも思ったが、今後どうなるかはわからないので念のため新規のユーザグループを作り、そこにappachやrootや自分のアカウントを追加し、当該箇所の所有グループを変更 & パーミッションを664に変更するという対応をとった。

なお、laravel.logファイルには、「日付ごとに別ファイルを出力する」という設定と、「すべてのログをまとめて1つのファイルに出力する」という設定がある(slackへの出力や複数同時も可。configのlogging.php内で設定)。後者の設定であれば、特に追加での対応は必要ないが、もし前者の設定を行っている場合は、当然だが毎日新しいファイルが生成されることになるので、その生成時のパーミッションも追加で設定してやらないと、「当日は問題なかったのに翌日になったらまたパーミッションエラーが出た」といったことが起こってしまう。

以下記事様がそのあたり含めて解説してくださってます。

0
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
3