前回記事

Laravel勉強 その1 サーバのセットアップ、DockerでのLaravel環境構築

目的

• 勉強のため、Laravel 7.xの公式ドキュメントを読み解いていく。
• 今回は、公式ドキュメントの「インストール」の章を扱う。

参考

Laravel 7.x インストール

サーバ要件

Laravelのインストール

この辺りについては、Dockerのコンテナ上でLaravel 7.xが動いていることも確認できているので、飛ばします。

設定

Publicディレクトリ

Laravelをインストールできたら、Webサーバのドキュメント／Webルートがpublicディレクトリになるように設定してください。
このディレクトリのindex.phpは、アプリケーションへ送信された、全HTTPリクエストを始めに処理するフロントコントローラとして動作します。

Webサーバ（nginx）の設定ファイルを確認してみる。

nginxコンテナ内で操作

rootの設定値がpublicに設定されていることを確認
# grep "root " /etc/nginx/conf.d/default.conf
  root  /var/www/public;

publicって本当にここなのかな？
とも思ったので、ちょっと試してみる。

# echo aaa > /var/www/public/aaa.txt
# cat /var/www/public/aaa.txt
aaa

http:///aaa.txtにリクエストしてみたところ、「aaa」が表示されたのでここでよさそう。
というか、docker-compose.ymlを作った時にvolumesで指定しているのね。

php:
（略）
    volumes:
      - ./server:/var/www

（略）

      nginx:
      （略）
        volumes:
          - ./server:/var/www
          - ./docker/nginx/default.conf:/etc/nginx/conf.d/default.conf

設定ファイル

フレームワークで使用する設定ファイルは、すべてconfigディレクトリ下に設置しています。
それぞれのオプションにコメントがついていますので、使用可能なオプションを理解するため、ファイル全体に目を通しておくのが良いでしょう。

# ll server/config
合計 72
-rw-rw-r-- 1 root root 9239  5月 21 20:33 app.php
-rw-rw-r-- 1 root root 3796  5月 21 20:33 auth.php
-rw-rw-r-- 1 root root 1601  5月 21 20:33 broadcasting.php
-rw-rw-r-- 1 root root 3100  5月 21 20:33 cache.php
-rw-rw-r-- 1 root root  823  5月 21 20:33 cors.php
-rw-rw-r-- 1 root root 5054  5月 21 20:33 database.php
-rw-rw-r-- 1 root root 2688  5月 21 20:33 filesystems.php
-rw-rw-r-- 1 root root 1571  5月 21 20:33 hashing.php
-rw-rw-r-- 1 root root 2896  5月 21 20:33 logging.php
-rw-rw-r-- 1 root root 3372  5月 21 20:33 mail.php
-rw-rw-r-- 1 root root 2760  5月 21 20:33 queue.php
-rw-rw-r-- 1 root root  950  5月 21 20:33 services.php
-rw-rw-r-- 1 root root 7041  5月 21 20:33 session.php
-rw-rw-r-- 1 root root 1053  5月 21 20:33 view.php

あ、こんなにあるの…？
ちょっと面倒k…時間がかかりそうなので、必要に応じて見ていくことにしよう。決めた。

ディレクトリパーミッション

Laravelをインストールした後に、多少のパーミッションの設定が必要です。
storage下とbootstrap/cacheディレクトリをWebサーバから書き込み可能にしてください。設定しないとLaravelは正しく実行されません。

これも前回設定してある。（セキュリティ的な面は度外視したけど）
```

sudo chmod -R 777 /var/project/server/storage/

sudo chmod -R 777 /var/project/server/bootstrap/cache

### アプリケーションキー
>次にインストール後に行うべきなのは、アプリケーションキーにランダムな文字列を設定することです。
>ComposerかLaravelインストーラを使ってインストールしていれば、php artisan key:generateコマンドが、あらかじめ設定しています。
>
>通常、この文字列は３２文字にすべきです。キーは.env環境ファイルに設定されます。
>もし、.env.exampleファイルをまだ.envへコピーしていなければ、今すぐ行ってください。
>**アプリケーションキーが設定されていなければ、ユーザーセッションや他の暗号化済みデーターは安全でありません！**

要は暗号化のための鍵ってことで、大事そうだけどいまいちよくわからない。
調べてたらこれが一番わかりやすいかも？（バージョンは古いけど）
[[Laravel5.5] APP_KEY の行方を追う](https://qiita.com/yk2220s/items/dcbf54c6d1f33a0cb06f)

```:phpコンテナで実行
# php artisan key:generate
Application key set successfully.

APP_KEYの値を確認
# grep ^APP_KEY /var/project/server/.env
APP_KEY=****************************　←実際にはKEYが記載されている

その他の設定

Laravelのその他の設定は、最初に指定する必要がありません。すぐに開発を開始しても大丈夫です！
しかし、config/app.phpファイルと、その中の記述を確認しておいたほうが良いでしょう。
アプリケーションに合わせ変更したい、timezoneやlocalのような多くのオプションが含まれています。

app.phpだけ見てみようかと思う。

設定項目	説明	デフォルト値	変更後の値
name	アプリケーション名	env('APP_NAME', 'Laravel')	-
env	環境名	env('APP_ENV', 'production')	-
debug	デバッグモード	(bool) env('APP_DEBUG', false)	-
url	コンソールで使用するURL	env('APP_URL', 'http://localhost')	-
asset_url	ここに設定したurlを元に、asset()でurl生成できる	env('ASSET_URL', null)	-
timezone	date系の関数で使用されるタイムゾーン	'UTC'	'Asia/Tokyo'
locale	ロケール	'en'	'ja'
fallback_locale	指定ロケールが存在しない時に使用されるロケール	'en'	'ja'
faker_locale	Faker（フェイクデータ作成）で使用される言語	'en_US'	'ja_JP'
key	暗号化キー	env('APP_KEY')	-
cipher	暗号化のサイファー	'AES-256-CBC'	-
providers	自動読み込みサービスプロバイダー	（略）	-
aliases	クラスのエイリアス	（略）	-

動作確認のため、設定を変える前に時刻を確認。

phpコンテナで実行

# php artisan tinker
Psy Shell v0.10.4 (PHP 7.3.18 ― cli) by Justin Hileman
>>> echo Carbon\Carbon::now();
2020-05-22 08:34:47?

確かに、日本時間ではない。
app.phpを編集してみる。

# diff app.php{_bk,}
70c70
<     'timezone' => 'UTC',
---
>     'timezone' => 'Asia/Tokyo',
83c83
<     'locale' => 'en',
---
>     'locale' => 'ja',
96c96
<     'fallback_locale' => 'en',
---
>     'fallback_locale' => 'ja',
109c109
<     'faker_locale' => 'en_US',
---
>     'faker_locale' => 'ja_JP',

もう一度、時刻を確認する。

phpコンテナで実行

# php artisan tinker
Psy Shell v0.10.4 (PHP 7.3.18 ― cli) by Justin Hileman
>>> echo Carbon\Carbon::now();
2020-05-22 17:38:30?

確かに変わっている。

Webサーバ設定

ディレクトリ設定

Laravelは常にWebサーバで設定した「Webディレクトリ」のルートから提供する必要があります。
「Webディレクトリ」のサブディレクトリでLaravelアプリケーションを提供しようと試みてはいけません。
そうした試みはアプリケーションの中に存在するセンシティブなファイルを曝してしまう可能性があります。

特にいじる必要はなさそう。
というか具体例がないとよくわからない。

きれいなURL

Apache

URLパスにフロントコントローラのindex.phpを付けなくても良いように、Laravelはpublic/.htaccessファイルを用意しています。
LaravelをApache上で動作させるときは、確実にmod_rewriteモジュールを有効に設定し、そのサーバで.htaccessファイルを動作させます。

今回はNginxを使用しているので、直接は関係ない。
デフォルトで.htaccessファイルが用意されているが、動作しない場合はmod_rewriteの設定を入れろとのこと。

Nginx

Nginxを使用する場合は、すべてのリクエストがindex.phpフロントコントローラへ集まるように、サイト設定に以下のディレクティブを使用します。

location / {
    try_files $uri $uri/ /index.php?$query_string;
}

Dockerの時点で作成したdefault.confに、上記設定は入っている。

2回目はここまで。

laravel new アプリ名

とすると、

dyld: Library not loaded: /usr/local/opt/icu4c/lib/libicui18n.61.dylib
  Referenced from: /usr/local/bin/php
  Reason: image not found
Abort trap: 6

とエラーが表示されました。

homebrewのバージョンが原因のようです。

brew update && brew upgrade

するとエラーになりました。権限なないことが原因のようです。

Error: Running Homebrew as root is extremely dangerous and no longer supported.
As Homebrew does not drop privileges on installation you would be giving all

下記のコマンドで権限を付与します。

sudo chown -R  /usr/local

usage: chown [-fhnv] [-R [-H | -L | -P]] owner[:group] file ...
       chown [-fhnv] [-R [-H | -L | -P]] :group file ...

再度homebrewのバージョンアップします。

brew update && brew upgrade

今度は成功しました。

そして、

homebrewをバージョンアップしたので、Laravelアプリを作成します。

laravel new アプリ名

Package manifest generated successfully.
Application ready! Build something amazing.

今度は成功しました?

目的

• APIについて勉強中であるが、知識として溜まってきて整理が必要なのでまとめる
• ※APIは難しいものではないので気楽に読んでいただけたら幸いである

実施環境

• ハードウェア環境(下記の二つの環境で確認)

項目	情報
OS	macOS Catalina(10.15.3)
ハードウェア	MacBook Pro (16-inch ,2019)
プロセッサ	2.6 GHz 6コアIntel Core i7
メモリ	16 GB 2667 MHz DDR4
グラフィックス	AMD Radeon Pro 5300M 4 GB Intel UHD Graphics 630 1536 MB

• ソフトウェア環境

項目	情報	備考
PHP バージョン	7.4.3	Homwbrewを用いて導入
Laravel バージョン	7.0.8	commposerを用いて導入
MySQLバージョン	8.0.19 for osx10.13 on x86_64	Homwbrewを用いて導入

そもそもLaravelAPI(APIサーバ)って？？

• 指定のURLなどのリクエストをAPIサーバに送るとURLに紐づけられた情報がレスポンスとして得られるサーバの事である。
• 主に自分の様な初学者のみなさんの勉強しているLaravelはそのLaravelアプリ内でブラウザ表示まで完結しているものがほとんどである。
• 初学者のみなさんが勉強するLaravelアプリはリクエストに対してビューなどの「綺麗に見せるためのデータ」も含めてレスポンスとして返却している。
• APIとはリクエストに対してその「綺麗に見せるためのデータ」を省き、DBに格納された文字列や数値、ステータスコードのみを返却するものである。
• 「リクエストをもらう」 → 「Laravelフレームワーク内で処理する」 → 「レスポンスを返す」という流れはAPIも一緒である。(この記事で最悪これさえ理解できていればOK!)

• 下記にLaravelアプリ(初学者のみなさんが最初に勉強するもの)の処理の簡易図を記載する。

  

• 下記にLaravelAPIの処理の簡易図を記載する。

  

LaravelをAPIとして使用した際のレスポンスのデータ

• レスポンスとして得られるデータはJSONというデータフォーマットを用いる。
• ビューなどのデータが含まれないデータだけがLaravelのAPIから返却される。

• 下記に今の段階での情報でのLaravelAPIの処理の簡易図を記載する。

  

APIのレスポンスを確認できるアプリ

• 「スマホアプリなどがないとLaravelAPIの勉強できないんじゃない？」と感じたと思う。
• 「スマホアプリなど」の役割をしてくれるPC用アプリケーションがある。
• 下記のPostmanというアプリを使用することにより、LaravelAPIにリクエストを送ることができる。
  • https://www.postman.com/

背景

最近、「ServiceProviderとは？使い方や使い道など」に関する質問を頂いた。
これに対して説明されているページを紹介して終了、がベストなのだが、Laravel初心者にも使い方が伝わるような簡潔な説明が見当たらないため、ここに私が出来る可能な限り簡潔な説明を記しておく。

説明

これがあると何が出来るか

あるサービスインスタンスに予め初期設定パラメータをセットしておき、アプリケーションのどの処理でもセット済のサービスインスタンスを使用することができる。

例

DBのホスト,ポート番号,ユーザー名,パスワード,DB名
※以下は実際とは異なるが、説明を分かりやすくするために敢えてこうしている

ServiceProvider.php

public function register()
{
    // ここでサービスコンテナに「db」という名前でインスタンスを格納しておく
    // ※「サービスコンテナ」については後述
    $this->app->singleton('db', function ($app) {
        // ここで初期設定パラメータをセットする
        return new DatabaseManager(
            config('database.host'),
            config('database.port'),
            config('database.username'),
            config('database.password'),
            config('database.database')
        );
    });
}

$users = resolve('db') // ServiceProviderで予め「db」という名前でコンテナに格納したインスタンスを取得する
    ->table('users')
    ->all();

サービスコンテナ

あるサービスインスタンスを設定パラメータのセットが済んだ状態で格納しておくところ。

おさらい

ServiceProviderは主に外部サービスを利用するためのサービスインスタンスを、設定パラメータのセットをしてサービスコンテナに登録しておくものである。