前回記事 Laravel勉強 その4 Laravelのディレクトリ構造 目的 勉強のため、Laravel 7.xの公式ドキュメントを読み解いていく。 今回は、公式ドキュメントの「デプロイ」の章を扱う。 ※Homestead、Valetの章は読み飛ばす。 参考 Laravel 7.x デプロイ イントロダクション Laravelアプリケーションをプロダクションとしてデプロイする準備ができたら、アプリケーションをできるだけ確実かつ、効率的な実行を行うには、いくつか重要な手順を行う必要があります。 このドキュメントでは、アプリケーションを確実にデプロイするため、重要なポイントを説明します。 はい。 サーバ設定 Nginx Nginxを実行しているサーバにアプリケーションをデプロイするには、Webサーバの設定として以下の設定ファイルが最初の参考となるでしょう。 ほとんどの設定と同様に、このファイルはサーバの設定に合わせてカスタマイズする必要が起きるでしょう。 server { listen 80; server_name example.com; root /srv/example.com/public; add_header X-Frame-Options "SAMEORIGIN"; add_header X-XSS-Protection "1; mode=block"; add_header X-Content-Type-Options "nosniff"; index index.php; charset utf-8; location / { try_files $uri $uri/ /index.php?$query_string; } location = /favicon.ico { access_log off; log_not_found off; } location = /robots.txt { access_log off; log_not_found off; } error_page 404 /index.php; location ~ \.php$ { fastcgi_pass unix:/var/run/php/php7.4-fpm.sock; fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name; include fastcgi_params; } location ~ /\.(?!well-known).* { deny all; } } せっかくなので、Nginxの勉強も兼ねて設定の内容を見ていく。 参考：nginxの基本設定を改めてちゃんと調べてみた listen 80; server_name example.com; root /srv/example.com/public; 受けるPORTは80。 ホスト名が「example.com」の場合に、serverブロック内の設定を適応する。 ルートディレクトリは/srv/example.com/publicとする。 add_header X-Frame-Options "SAMEORIGIN"; add_header X-XSS-Protection "1; mode=block"; add_header X-Content-Type-Options "nosniff"; この辺りは、セキュリティ面を考慮してヘッダーを追加している。 クリックジャッキング対応として、自身と生成元が同じフレーム内に限りページを表示する設定をする。 クロスサイトスクリプティング（XSS）に対するフィルタ機能を強制的に有効にする。 Internet Explorer が MIME Sniffing 機能で content-type 宣言を回避するのを防止する。 index index.php; charset utf-8; ディレクトリへのアクセスに対して、index.phpを呼び出す。 レスポンスヘッダのContent-Typeに、charset=utf-8を付与する。 location / { try_files $uri $uri/ /index.php?$query_string; } location = /favicon.ico { access_log off; log_not_found off; } location = /robots.txt { access_log off; log_not_found off; } error_page 404 /index.php; location ~ \.php$ { fastcgi_pass unix:/var/run/php/php7.4-fpm.sock; fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name; include fastcgi_params; } location ~ /\.(?!well-known).* { deny all; } 全リクエストに対して URLに記載されたファイルが存在しているかを確認。 URLに記載されたディレクトリが存在しているかを確認。 どちらもなければ、/index.php$query_string へ内部リダイレクトする。 「/favicon.ico」へのリクエストに対しては、アクセスログは記載せず、エラーログも捨てる。 「/robots.txt」へのリクエストに対しては、アクセスログは記載せず、エラーログも捨てる。 404の場合、index.phpを呼び出す。 「.php」で終わるリクエストに対して NginxがFastCGIプロトコルを使用してプロキシする実際のサーバーを定義。UNIXドメインソケットを使用して、php7.4-fpmと通信する。 FastCGIパラメーターの「SCRIPT_FILENAME」を指定する。 正直、理解しきれていないけど、php-fpmを経由してLaravelの開始スクリプトのindex.phpを実行しましょう、ということみたい。（違う？） 「/.well-known」以下以外へのリクエストに対しては、全て拒否する。 最適化 オートローダー最適化 プロダクションへデプロイする場合、Composerのクラスオートローダマップを最適し、Composerが素早く指定されたクラスのファイルを確実に見つけ、ロードできるようにします。 composer install --optimize-autoloader --no-dev Tip!! オートローダを最適化することに加え、プロジェクトのソースコントロールリポジトリへ、composer.lockファイルをいつも確実に含めましょう。 composer.lockファイルが存在すると、プロジェクトの依存パッケージのインストールが、より早くなります。 あんまりよくわからないけど、これを使用すると早くなるってことみたい。 設定ローディングの最適化 アプリケーションをプロダクションへデプロイする場合、デプロイプロセスの中で、確実にconfig:cache Artisanコマンドを実行してください。 php artisan config:cache このコマンドは、Laravelの全設定ファイルをキャッシュされる一つのファイルへまとめるため、設定値をロードする場合に、フレームワークがファイルシステムを数多くアクセスする手間を大いに減らします。 Note: 開発時にconfig:cacheコマンドを実行する場合は、設定ファイルの中だけで、env関数を呼び出していることを確認してください。 設定ファイルがキャッシュされてしまうと、.envファイルはロードされなくなり、env関数の呼び出し結果はすべてnullになります。 これは以前にも出てきた。 設定ファイルをいちいち読み込まないようにするやつ。 ルートロードの最適化 多くのルートを持つ大きなアプリケーションを構築した場合、デプロイプロセス中に、route:cache Artisanコマンドを確実に実行すべきでしょう。 php artisan route:cache このコマンドはキャッシュファイルの中の、一つのメソッド呼び出しへ全ルート登録をまとめるため、数百のルートを登録する場合、ルート登録のパフォーマンスを向上します。 Note: この機能はPHPのシリアライゼーション機能を使用するため、アプリケーションの全ルートをキャッシュするには、コントローラベースのルート定義だけを使用してください。PHPはクロージャをシリアライズできません。 ルートがたくさんある場合は、このコマンドを実行しておけば早くなりますよってことみたい。 ビューロードの最適化 実機環境へアプリケーションをデプロイする場合は、その手順の中でview:cache Artisanコマンドを実行すべきでしょう。 php artisan view:cache このコマンドは全Bladeビューを事前にコンパイルし、要求ごとにコンパイルしなくて済むため、ビューを返すリクエストすべてでパフォーマンスが向上します。 これを実行しておけば、パフォーマンスが向上するみたい。 Forgeによるデプロイ 自分のサーバ設定管理に準備不足であったり、堅牢なLaravelアプリケーション実行に必要な数多くのサービスすべての設定について慣れていなければ、Laravel Forgeは素晴らしい代替案です Laravel ForgeはDigitalOcean、Linode、AWSなど数多くのインフラプロバイダー上に、サーバを作成できます。 それに加え、ForgeはNginx、MySQL、Redis、Memcached、Beanstalkなどのような、堅牢なLaravelアプリケーションを構築するために必要なツールを全部インストールし、管理します。 何かと思ったら、Laravel LLCが提供している、環境の構築・管理をするサービスみたい。 今回は使わないけど、ちょっと便利そうかも。 最適化の部分はよくわからなかったけど、全部実行しておけばいいのかな？笑 第5回はここまで。
Laravel勉強 その4 Laravelのディレクトリ構造
Laravel 7.x デプロイ
Laravelアプリケーションをプロダクションとしてデプロイする準備ができたら、アプリケーションをできるだけ確実かつ、効率的な実行を行うには、いくつか重要な手順を行う必要があります。 このドキュメントでは、アプリケーションを確実にデプロイするため、重要なポイントを説明します。
はい。
Nginxを実行しているサーバにアプリケーションをデプロイするには、Webサーバの設定として以下の設定ファイルが最初の参考となるでしょう。 ほとんどの設定と同様に、このファイルはサーバの設定に合わせてカスタマイズする必要が起きるでしょう。
server { listen 80; server_name example.com; root /srv/example.com/public; add_header X-Frame-Options "SAMEORIGIN"; add_header X-XSS-Protection "1; mode=block"; add_header X-Content-Type-Options "nosniff"; index index.php; charset utf-8; location / { try_files $uri $uri/ /index.php?$query_string; } location = /favicon.ico { access_log off; log_not_found off; } location = /robots.txt { access_log off; log_not_found off; } error_page 404 /index.php; location ~ \.php$ { fastcgi_pass unix:/var/run/php/php7.4-fpm.sock; fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name; include fastcgi_params; } location ~ /\.(?!well-known).* { deny all; } }
せっかくなので、Nginxの勉強も兼ねて設定の内容を見ていく。 参考：nginxの基本設定を改めてちゃんと調べてみた
listen 80; server_name example.com; root /srv/example.com/public;
add_header X-Frame-Options "SAMEORIGIN"; add_header X-XSS-Protection "1; mode=block"; add_header X-Content-Type-Options "nosniff";
index index.php; charset utf-8;
location / { try_files $uri $uri/ /index.php?$query_string; } location = /favicon.ico { access_log off; log_not_found off; } location = /robots.txt { access_log off; log_not_found off; } error_page 404 /index.php; location ~ \.php$ { fastcgi_pass unix:/var/run/php/php7.4-fpm.sock; fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name; include fastcgi_params; } location ~ /\.(?!well-known).* { deny all; }
プロダクションへデプロイする場合、Composerのクラスオートローダマップを最適し、Composerが素早く指定されたクラスのファイルを確実に見つけ、ロードできるようにします。 composer install --optimize-autoloader --no-dev Tip!! オートローダを最適化することに加え、プロジェクトのソースコントロールリポジトリへ、composer.lockファイルをいつも確実に含めましょう。 composer.lockファイルが存在すると、プロジェクトの依存パッケージのインストールが、より早くなります。
プロダクションへデプロイする場合、Composerのクラスオートローダマップを最適し、Composerが素早く指定されたクラスのファイルを確実に見つけ、ロードできるようにします。 composer install --optimize-autoloader --no-dev
composer install --optimize-autoloader --no-dev
Tip!! オートローダを最適化することに加え、プロジェクトのソースコントロールリポジトリへ、composer.lockファイルをいつも確実に含めましょう。 composer.lockファイルが存在すると、プロジェクトの依存パッケージのインストールが、より早くなります。
あんまりよくわからないけど、これを使用すると早くなるってことみたい。
アプリケーションをプロダクションへデプロイする場合、デプロイプロセスの中で、確実にconfig:cache Artisanコマンドを実行してください。 php artisan config:cache このコマンドは、Laravelの全設定ファイルをキャッシュされる一つのファイルへまとめるため、設定値をロードする場合に、フレームワークがファイルシステムを数多くアクセスする手間を大いに減らします。 Note: 開発時にconfig:cacheコマンドを実行する場合は、設定ファイルの中だけで、env関数を呼び出していることを確認してください。 設定ファイルがキャッシュされてしまうと、.envファイルはロードされなくなり、env関数の呼び出し結果はすべてnullになります。
アプリケーションをプロダクションへデプロイする場合、デプロイプロセスの中で、確実にconfig:cache Artisanコマンドを実行してください。 php artisan config:cache このコマンドは、Laravelの全設定ファイルをキャッシュされる一つのファイルへまとめるため、設定値をロードする場合に、フレームワークがファイルシステムを数多くアクセスする手間を大いに減らします。
php artisan config:cache
Note: 開発時にconfig:cacheコマンドを実行する場合は、設定ファイルの中だけで、env関数を呼び出していることを確認してください。 設定ファイルがキャッシュされてしまうと、.envファイルはロードされなくなり、env関数の呼び出し結果はすべてnullになります。
これは以前にも出てきた。 設定ファイルをいちいち読み込まないようにするやつ。
多くのルートを持つ大きなアプリケーションを構築した場合、デプロイプロセス中に、route:cache Artisanコマンドを確実に実行すべきでしょう。 php artisan route:cache このコマンドはキャッシュファイルの中の、一つのメソッド呼び出しへ全ルート登録をまとめるため、数百のルートを登録する場合、ルート登録のパフォーマンスを向上します。 Note: この機能はPHPのシリアライゼーション機能を使用するため、アプリケーションの全ルートをキャッシュするには、コントローラベースのルート定義だけを使用してください。PHPはクロージャをシリアライズできません。
多くのルートを持つ大きなアプリケーションを構築した場合、デプロイプロセス中に、route:cache Artisanコマンドを確実に実行すべきでしょう。 php artisan route:cache このコマンドはキャッシュファイルの中の、一つのメソッド呼び出しへ全ルート登録をまとめるため、数百のルートを登録する場合、ルート登録のパフォーマンスを向上します。
php artisan route:cache
Note: この機能はPHPのシリアライゼーション機能を使用するため、アプリケーションの全ルートをキャッシュするには、コントローラベースのルート定義だけを使用してください。PHPはクロージャをシリアライズできません。
ルートがたくさんある場合は、このコマンドを実行しておけば早くなりますよってことみたい。
実機環境へアプリケーションをデプロイする場合は、その手順の中でview:cache Artisanコマンドを実行すべきでしょう。 php artisan view:cache このコマンドは全Bladeビューを事前にコンパイルし、要求ごとにコンパイルしなくて済むため、ビューを返すリクエストすべてでパフォーマンスが向上します。
php artisan view:cache
これを実行しておけば、パフォーマンスが向上するみたい。
自分のサーバ設定管理に準備不足であったり、堅牢なLaravelアプリケーション実行に必要な数多くのサービスすべての設定について慣れていなければ、Laravel Forgeは素晴らしい代替案です Laravel ForgeはDigitalOcean、Linode、AWSなど数多くのインフラプロバイダー上に、サーバを作成できます。 それに加え、ForgeはNginx、MySQL、Redis、Memcached、Beanstalkなどのような、堅牢なLaravelアプリケーションを構築するために必要なツールを全部インストールし、管理します。
何かと思ったら、Laravel LLCが提供している、環境の構築・管理をするサービスみたい。 今回は使わないけど、ちょっと便利そうかも。
最適化の部分はよくわからなかったけど、全部実行しておけばいいのかな？笑 第5回はここまで。
ComposerでさくらのレンタルサーバにLaravelをインストールしようとすると、途中でkill -9 でヌっころされてしまいます。 先人の知恵によると、容量が大きすぎるので中断をくらうらしい、一旦ローカルに作ってFTPで送ると動くとのこと（仰せの通りでした）。 じゃあ、何だったらインストールできるの？ということで幾つか試してみました。 ちなみにプランはスタンダードです。 方法 /home/xxxx/projの下にミドルウェアごとにディレクトリを作って、 そこで composer require foo/bar をやってみる。その後、容量をdu -sm */ | sort -nで調べる。 結果(2020/5/27現在,単位はMB) $ du -sm */ | sort -n 1 Codeigniter/ 2 slim/ 3 smarty/ 9 cake/ 9 laminas/(旧Zend Framework) 13 fuel/ 41 symfony/ 42 lumen/ (composer -> lumenインストーラ使用) 14 laravel/ インストール失敗、ローカルのvendorでは56M lumenまでは入るが、Laravelはアウトでした。 「lumen 軽いよ！」という印象だったのですが、容量的には結構ありますね。 Codeigniterは実際は1M以下で、あまりに小さくて二度見したんですが、/vendorを確認したところどうやらこれでいいらしいです。
ComposerでさくらのレンタルサーバにLaravelをインストールしようとすると、途中でkill -9 でヌっころされてしまいます。
先人の知恵によると、容量が大きすぎるので中断をくらうらしい、一旦ローカルに作ってFTPで送ると動くとのこと（仰せの通りでした）。
じゃあ、何だったらインストールできるの？ということで幾つか試してみました。 ちなみにプランはスタンダードです。
方法 /home/xxxx/projの下にミドルウェアごとにディレクトリを作って、 そこで composer require foo/bar をやってみる。その後、容量をdu -sm */ | sort -nで調べる。
結果(2020/5/27現在,単位はMB) $ du -sm */ | sort -n
1 Codeigniter/ 2 slim/ 3 smarty/ 9 cake/ 9 laminas/(旧Zend Framework) 13 fuel/ 41 symfony/ 42 lumen/ (composer -> lumenインストーラ使用) 14 laravel/ インストール失敗、ローカルのvendorでは56M
lumenまでは入るが、Laravelはアウトでした。
「lumen 軽いよ！」という印象だったのですが、容量的には結構ありますね。
Codeigniterは実際は1M以下で、あまりに小さくて二度見したんですが、/vendorを確認したところどうやらこれでいいらしいです。
ComposerでさくらのレンサバにLaravelをインストールしようとすると、途中でkill -9 で切られてしまいます。 先人の知恵によると、容量が大きすぎるので中断をくらうらしい、一旦ローカルに作ってFTPで送ると動くとのことでした。 たしかに動いたことは動いたのですが、gitで同期させる運用の場合、うっかり展開先でミドルウェアのアップデートをかけ失敗したらどうしよう？という不安が残ります。 じゃあ、何だったらインストールできるの？ということで幾つか試してみました。 方法 /home/xxxx/projの下にミドルウェアごとにディレクトリを作って、 そこで composer require foo/bar をやってみる。その後、容量をdu -sm */ | sort -nで調べる。 結果(単位はMB) $ du -sm */ | sort -n 1 Codeigniter/ 2 slim/ 3 smarty/ 9 cake/ 9 laminas/(旧Zend Framework) 13 fuel/ 41 symfony/ 42 lumen/ 14 laravel/ インストール失敗、ローカルのvendorでは56M lumenまでは入るが、Laravelはアウトでした。 「lumen 軽いよ！」という印象だったのですが、容量的には結構ありますね。 Codeigniterは実際は1M以下で、小さくて二度見したんですが、/vendorを確認したところどうやらこれでいいらしいです。
ComposerでさくらのレンサバにLaravelをインストールしようとすると、途中でkill -9 で切られてしまいます。
先人の知恵によると、容量が大きすぎるので中断をくらうらしい、一旦ローカルに作ってFTPで送ると動くとのことでした。
たしかに動いたことは動いたのですが、gitで同期させる運用の場合、うっかり展開先でミドルウェアのアップデートをかけ失敗したらどうしよう？という不安が残ります。
じゃあ、何だったらインストールできるの？ということで幾つか試してみました。
結果(単位はMB) $ du -sm */ | sort -n
1 Codeigniter/ 2 slim/ 3 smarty/ 9 cake/ 9 laminas/(旧Zend Framework) 13 fuel/ 41 symfony/ 42 lumen/ 14 laravel/ インストール失敗、ローカルのvendorでは56M
Codeigniterは実際は1M以下で、小さくて二度見したんですが、/vendorを確認したところどうやらこれでいいらしいです。
ComposerでさくらのレンサバにLaravelをインストールしようとすると、途中でkill -9 で切られてしまいます。 先人の知恵によると、容量が大きすぎるので中断をくらうらしい、一旦ローカルに作ってFTPで送ると動くとのことでした。 たしかに動いたことは動いたのですが、gitで同期させる運用の場合、うっかり展開先でミドルウェアのアップデートをかけ失敗したらどうしよう？という不安が残ります。 じゃあ、何だったらインストールできるの？ということで幾つか試してみました。 方法 /home/xxxx/projの下にミドルウェアごとにディレクトリを作って、 そこで composer require foo/bar をやってみる。その後、容量をdu -sm */ | sort -nで調べる。 結果(単位はMB) $ du -sm */ | sort -n 1 Codeigniter/ 2 slim/ 3 smarty/ 9 cake/ 9 laminas/(旧Zend Framework) 13 fuel/ 41 symfony/ 42 lumen/ 14 laravel/ インストール失敗、ローカルのvendorでは56M lumenまでは入るが、Laravelはアウトでした。 「lumen 軽いよ！」という印象だったのですが、容量的には結構ありますね。 Codeigniterは実際は1M以下で、あまりに小さくて二度見したんですが、/vendorを確認したところどうやらこれでいいらしいです。
ComposerでさくらのレンサバにLaravelをインストールしようとすると、途中でkill -9 でヌっころされてしまいます。 先人の知恵によると、容量が大きすぎるので中断をくらうらしい、一旦ローカルに作ってFTPで送ると動くとのことでした。 やってみると確かに動いたことは動いたのですが、gitで同期させる運用の場合、うっかり展開先でミドルウェアのアップデートをかけて中途半端に死んだりしたらどうしよう？という不安が残ります。 じゃあ、何だったらインストールできるの？ということで幾つか試してみました。 ちなみにプランはスタンダードです。 方法 /home/xxxx/projの下にミドルウェアごとにディレクトリを作って、 そこで composer require foo/bar をやってみる。その後、容量をdu -sm */ | sort -nで調べる。 結果(単位はMB) $ du -sm */ | sort -n 1 Codeigniter/ 2 slim/ 3 smarty/ 9 cake/ 9 laminas/(旧Zend Framework) 13 fuel/ 41 symfony/ 42 lumen/ 14 laravel/ インストール失敗、ローカルのvendorでは56M lumenまでは入るが、Laravelはアウトでした。 「lumen 軽いよ！」という印象だったのですが、容量的には結構ありますね。 Codeigniterは実際は1M以下で、あまりに小さくて二度見したんですが、/vendorを確認したところどうやらこれでいいらしいです。
ComposerでさくらのレンサバにLaravelをインストールしようとすると、途中でkill -9 でヌっころされてしまいます。
やってみると確かに動いたことは動いたのですが、gitで同期させる運用の場合、うっかり展開先でミドルウェアのアップデートをかけて中途半端に死んだりしたらどうしよう？という不安が残ります。
目的 rollback時の記載を毎回間違えるのでしっかりとまとめる 実施環境 ハードウェア環境(下記の二つの環境で確認) 項目 情報 備考 OS macOS Catalina(10.15.3) ハードウェア MacBook Air (11-inch ,2012) プロセッサ 1.7 GHz デュアルコアIntel Core i5 メモリ 8 GB 1600 MHz DDR3 グラフィックス Intel HD Graphics 4000 1536 MB 項目 情報 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 artisan make:migration add_追加カラム名_column_to_追加テーブル名_table --table=追加テーブル名 アプリ名ディレクトリで下記コマンドを実行して作成したマイグレーションファイルを開く $ vi database/migrations/yyyy_mm_dd_XXXXXX_add_追加カラム名_column_to_追加テーブル名_table.php 開いたマイグレーションファイルを下記の様に修正する。 アプリ名ディレクトリ/database/migrations/yyyy_mm_dd_XXXXXX_add_追加カラム名_column_to_追加テーブル名_table.php <?php use Illuminate\Database\Migrations\Migration; use Illuminate\Database\Schema\Blueprint; use Illuminate\Support\Facades\Schema; class Add追加カラム名ColumnTo追加テーブル名Table extends Migration { /** * Run the migrations. * * @return void */ public function up() { Schema::table('users', function (Blueprint $table) { //下記を追加する $table->データ型('カラム名'); }); } /** * Reverse the migrations. * * @return void */ public function down() { Schema::table('users', function (Blueprint $table) { //下記を追加する $table->dropColumn('カラム名'); }); } } アプリ名ディレクトリで下記コマンドを実行してマイグレーションファイルをマイグレートを行う。 php artisan migrate エラーが出ずにマイグレートできる事を確認する
アプリ名ディレクトリで下記コマンドを実行する。
$ php artisan make:migration add_追加カラム名_column_to_追加テーブル名_table --table=追加テーブル名
アプリ名ディレクトリで下記コマンドを実行して作成したマイグレーションファイルを開く
$ vi database/migrations/yyyy_mm_dd_XXXXXX_add_追加カラム名_column_to_追加テーブル名_table.php
開いたマイグレーションファイルを下記の様に修正する。
<?php use Illuminate\Database\Migrations\Migration; use Illuminate\Database\Schema\Blueprint; use Illuminate\Support\Facades\Schema; class Add追加カラム名ColumnTo追加テーブル名Table extends Migration { /** * Run the migrations. * * @return void */ public function up() { Schema::table('users', function (Blueprint $table) { //下記を追加する $table->データ型('カラム名'); }); } /** * Reverse the migrations. * * @return void */ public function down() { Schema::table('users', function (Blueprint $table) { //下記を追加する $table->dropColumn('カラム名'); }); } }
アプリ名ディレクトリで下記コマンドを実行してマイグレーションファイルをマイグレートを行う。
php artisan migrate
エラーが出ずにマイグレートできる事を確認する
Immutableとは プログラミングにおいてImmutable（イミュータブル）とは「不変」という意味で、オブジェクトの状態が変わらないことを指します。 逆に、元のデータが変更可能なオブジェクトの性質をMutable（ミュータブル）と言います。 ImmutableとMutableの違い Immutable（イミュータブル）とMutable（ミュータブル）の違いについて、実際にみていきましょう。 まずは、日付操作ライブラリ「Carbon」を使って現在日時を取得してみます。 sample.php $now = \Carbon\Carbon::now();//2020-05-26 06:57:02.027091 現在日時が取得できました。 次に、addDayメソッドで上記で取得した現在日時に1日加算してみます。 sample.php $tomorrow = $now->addDay();//2020-05-27 06:59:01.25073 1日加算されています。 ここで$nowの中身を再びみてみます。 sample.php var_dump($now);//2020-05-27 06:59:01.25073 なんと、\$nowまで1日加算され、\$nowと\$tomorrowが同じ結果となってしまいました。 これは、\$nowと\$tomorrowが同じオブジェクトであるために起こります。 元の状態の変化を防ぐにはcopyメソッドを使います。 copyメソッドで元の状態を保持 copyメソッドで元のオブジェクトを複製して、2つの変数の結果を見てみましょう。 sample.php $tomorrow = $now->copy->addDay(); var_dump($now);//2020-05-26 06:57:02.027091 var_dump($tomorrow);//2020-05-27 06:59:01.25073 元のオブジェクトはそのままで、$tomorrowだけ1日加算されました。 Carbonのバージョン2系では、このImmutable（イミュータブル）版が利用できるようになっています。
プログラミングにおいてImmutable（イミュータブル）とは「不変」という意味で、オブジェクトの状態が変わらないことを指します。
逆に、元のデータが変更可能なオブジェクトの性質をMutable（ミュータブル）と言います。
Immutable（イミュータブル）とMutable（ミュータブル）の違いについて、実際にみていきましょう。
まずは、日付操作ライブラリ「Carbon」を使って現在日時を取得してみます。
$now = \Carbon\Carbon::now();//2020-05-26 06:57:02.027091
現在日時が取得できました。 次に、addDayメソッドで上記で取得した現在日時に1日加算してみます。
$tomorrow = $now->addDay();//2020-05-27 06:59:01.25073
1日加算されています。
ここで$nowの中身を再びみてみます。
var_dump($now);//2020-05-27 06:59:01.25073
なんと、\$nowまで1日加算され、\$nowと\$tomorrowが同じ結果となってしまいました。 これは、\$nowと\$tomorrowが同じオブジェクトであるために起こります。 元の状態の変化を防ぐにはcopyメソッドを使います。
copyメソッドで元のオブジェクトを複製して、2つの変数の結果を見てみましょう。
$tomorrow = $now->copy->addDay(); var_dump($now);//2020-05-26 06:57:02.027091 var_dump($tomorrow);//2020-05-27 06:59:01.25073
元のオブジェクトはそのままで、$tomorrowだけ1日加算されました。
Carbonのバージョン2系では、このImmutable（イミュータブル）版が利用できるようになっています。
