Laravel、デモ画面までに行き着かなかったら

タグ： Laravel5.1LTS   Laravel  

月一で見かける投稿に、「デモ画面を表示しようとしたら、真っ白なページが表示された」というものです。まあ、誰も引っかかる場所は似たような箇所です。

Laravel初心者、というよりもPHPをサーバーで動かす初心者の方が引っかかるポイントを確認しておきましょう。

PHPと拡張

ドキュメントのインストールに書かれています。まず、PHPですがフレームワークに限らずシステムには動作の保証範囲、つまりそのシステムが動作する条件があります。

LaravelはPHPフレームワークですから、PHP言語上で動作します。PHPもバージョンにより機能や仕様が追加、削除されているため、適合するバージョンの範囲でなければ動作しません。

ドキュメントには、"PHP >= 5.5.9"と書かれています。しかし、Laravelを動作させるために必要で、Laravelと一緒にインストールされるComposerパッケージの中には、PHP5.5.9のバグを踏むものもありますので、可能であれば5.6以上がよいでしょう。Laravelは新しいバージョンには、早めに適合しますので、PHP7でも動作します。（特にLaravelユーザーは新しもの好きが多いので、実行速度も早いLaravel7.0を積極的に使う人も、多いようです。）

PHPには必要な機能を追加できるようになっています。そうしたPHP拡張パッケージも用意する必要があります。

  1. PDO PHP拡張
  2. Tokenizer PHP拡張
  3. OpenSSL PHP拡張
  4. Mbstring PHP拡張

デフォルトでどのPHP拡張がインストール済みで、どれが有効になっているかは、OSやLinuxであればディストリビューション、LAMPのインストールパッケージなどごとに異なっています。自分の環境で、どれが有効になっているかを調べる必要があります。もしくは、Laravelを動かして、エラーメッセージが表示されないか、確認します。

Linuxの場合、たいてい最初の２つはPHPをインストールするとデフォルトでインストールされるか、PHPに組み込まれて有効になっています。（もちろん、なっていないものもあるでしょう。）

また、Ubuntuの場合、インストールするだけで有効にならない拡張もあります。php5enmodを使い、有効にする必要があります。（バージョンごとに異なるようです。）

上の４つは実働環境、つまり"composer update --no-dev"のように、開発環境で利用するPHPUnitのようなテストツールを動かさない場合に必要なパッケージです。こうしたテストツールを動作させる場合、必要なPHP拡張はもう少し増えます。

また、Artisan tinkerを利用する場合は、環境によりReadline PHP拡張、もしくはlibedit拡張が必要です。（参照：PsySH）

ステータスコードがドーン

Laravelをインストールしたとしましょう。その直後、つまり設定を何もいじっていなければ、デバッグモードになっています。

デバッグモードで不具合が起きると、Webページには発生した例外とスタックトレースが表示されます。

そうではなく、ステータスコードがドーンと表示されるエラーページの場合、それはたいていWebサーバーが出しているエラーです。つまり、Laravelまで制御が行き着いていません。大抵の場合、Webサーバーの設定ミスです。

ApacheをWebサーバーに使用している場合、設定によってはFollowSymLinks系を指定しないと動かない場合があります。Laravelがシンボリックリンクを含んでいるわけではありませんが、もともとの設定がリンクを利用していたり、デブロイのバージョン切り替えにリンクを使ったりしている場合に、必要になることがあります。

もしくは、こうした設定を正しく行った後で、Webサーバーを再起動したり、設定を読み込ませたりし忘れていることが多いようです。

もうひとつ、Laravelプロジェクトのファイルパーミッションを正しく設定していない場合も、Webサーバーのエラーページが返されることがあります。

ホワイトアウト

サーバーの設定が正しいのにページが真っ白で表示されたり、403エラーページが表示される場合、Laravelプロジェクトの指定ディレクトリーをWebサーバーの実行ユーザーからアクセス可能にしていない可能性が大きいです。

言葉が難しいですね。詳しく説明しましょう。

Webサーバーはプログラムです。プログラムは通常、それを起動した人を覚えています。それを「プログラムの実行ユーザー」と言います。

ファイルシステムには、誰、どのグループがどんなことをやれるのかという指定が行われています。「パーミッション」とか「許可」とか言います。これにより、第三者が別のユーザーのファイルの中身を閲覧したり、改変したりすることを防いでいます。

WebサーバーはOSやLinuxディストリビューションにより決められた、「Webサーバー」用のユーザーが実行ユーザーです。たとえば、Laravelと仲良しのUbuntuではwww-dataが使われています。

Webサーバーを「なんでもできる」最強のユーザー、"root"として動かしましょう。Webサーバーの設定が甘かったり、サーバー上で動かしているプログラムに穴があり、悪意のあるユーザーが操作可能になったとしましょう。その場合、実行ユーザーがrootであると、「なんでもできる」ため被害が大きくなります。実際、ファイルシステム全部を消すことも可能でしょう。

そこで、WebサーバーはWebサーバーを動かす専用のユーザーが用意され、そのユーザーとして動作させています。

ところが、皆さんがそのマシン上ではtanakaやkawaguchiとかいうユーザーとして利用しています。もしくは、rootとして使っているかもしれません。その状態でLaravelをインストールしたり、外部からデプロイすれば、それはあなたのユーザーの所有物です。そのままでは、別人扱いのWebサーバーの実行ユーザーからは操作できません。

Laravalがフレームワークとしてファイルを操作する必要がある場所は限定されています。storage下に存在するディレクトリーとbootstrap/cacheディレクトリーに「Webサーバーのユーザーから書き込みOK」というパーミッションを与える必要があります。storage下には通常、app、framework、logsの３つのディレクトリーがあります。これらのディレクトリーをWebサーバーの実行ユーザーから書き込み可能にしてください。

Unix/Linux系の場合、chmod a+w ファイルパスで、全てのユーザーの書き込みを許可できます。これは開発環境では便利な設定でしょう。ただし、セキュリティ的に弱いため、実働環境では使用しないでください。

一般に、共有サーバーではPHPが動作するときの動作ユーザーをあなたのユーザーに切り替えますので、ホワイトアウトすることはないでしょう。

面倒ですよね。まず、動作するかどうかを調べる場合は、Webサーバーの設定などに悩まずに、PHP組み込みのWebサーバーを使用しましょう。ターミナルで"php artisan serve"とプロジェクトルートで実行したら、Webブラウザで"http://localhost:8000"へアクセスするだけです。Webサーバーの起動は「あなた」ですから、実行ユーザーもあなたです。ファイルパーミッションにかかわらずにデモページが表示できます。

切り分け

storageとbootstrapのパーミッションを正しく設定したにもかかわらず、ホワイトアウトしたり、ステータスコードのエラーページが表示される場合、storage/logs下にログファイルが存在していないか確認します。

もし、存在していたらその中身を確認します。例外とトレースが書き込まれていたら、原因はあなたのLaravelプロジェクトにある可能性が大きいでしょう。たとえば、composer updateをし忘れていて、必要なコンポーネントをインストールし忘れていたりする場合です。

次に、Webサーバーのログファイルを調べます。Linux系の場合は/var/logs/apache2や/var/logs/nginxへ、errorなんとかというファイルができているでしょう。こうしたログファイルを確認するにはrootユーザーとして調べる必要があります。エラーが出ている場合は、Webサーバーの設定が原因です。（前記のパーミッションの問題でもログに書き込まれます）

次に、同じディレクトリーのaccessなんとかファイルでアクセス状況を調べましょう。accessなんとかファイルができていない場合、HTTPエラーも表示されていないはずです。ブラウザが「正常に接続できませんでした」とか「このサイトのURLを間違えていないか」とか表示していませんか。もしそうであれば、サーバーが起動していない可能性が大きいでしょう。

ルートURI以外にアクセスできない

デモページは表示できたのに、チュートリアルに挑戦し、先頭のページ以外、全ページで「ページが見つからない」とかエラーで返されるのであれば、サーバーに何を使っているかを思い出してください。

Apacheを使っている場合は、Apacheのrewriteが有効になっていないか、インストールされていません。

Nginxの場合、この状況になるのは、たいていドキュメントに提示されている以外の仮想ホスト設定にチャレンジしている場合です。まずは、ドキュメントに提示されているコードそのままにして、サイト名の部分だけを変更してみてください。

Nginxでサブディレクトリーへアクセスさせる場合、たとえばhttp://localhost/subのように「ドメイン」部分＋「ディレクトリー」という形でドキュメントルートであるpublicディレクトリーへアクセスさせる場合、ドキュメント記載のコードのままでは動きません。まず素直に、「ドメイン」だけでアクセスさせるか、以下の記事を参照してください。最適解ではないでしょうが、どうにか動いた設定です。

最初をどう踏み出すか

すでにVagrantをバリバリ活用されている方は、Homesteadを利用するのがよいでしょう。

そうでなくても、PHPの環境が整っていれば、最初の一歩はシンプルにPHPの組み込みサーバーで試してみるのが簡単です。

php artisan serve

-hオプションをつければ、ポート変更のオプションなどが確認できます。

一番簡単で、手間要らずです。ちょっとしたチュートリアルであれば、これで十分です。一番簡単なところから踏み出しましょう。