Env on ララジャパン

Laravel10.xからLaravel 11.xへの更新で注意すること

Sun, 22 Dec 2024 12:30:19 +0900

Laravel 11.xがリリースされてから暫く経過していますが、やっと手持ちのLaravel 10.xのプロジェクトの更新作業に取り掛かっています。今回もLaravel Shiftのサービスを使用していますが、Laravel 10.xからLaravel11.xへの更新をすべて自動で行ってくれるわけではないです。

しかし、Laravelのサイトで説明されている更新のステップのドキュメンテーションを読むよりは、具体的な更新の変更がヒントとなり役に立ちます。もちろんShiftの変更はそれだけ十分というレベルからは遠く、とりわけ今回の更新では構造的に大きなLaravelの変更があるので、Shiftの変更後は確認とともに手動の編集作業が必須となります。

ここではお客さんのプロジェクトでの更新で私が苦労した部分をいくつか説明しますが、過去の記事にLaravel 11.xのインストールについても説明があるので合わせてお読みください。

configのファイルたちの復元

Laravel Shiftを使用した後に、config/ディレクトリ下のいくつかのファイルが削除あるいは編集されてることに気づきます。

実際、Laravel 10.xとLaravel 11.xの両方で新規のプロジェクト作成して比較してみると、以下のファイルがLaravel 11.xでは削除されています。フレームワークのスリム化の一環だそうです。

config/broadcasting.php
config/cors.php
config/hashing.php
config/sanctum.php
config/view.php

最初は、config/以下のすべてのファイルを削除するという案もあったそうですが、Laravelの作者のTaylor氏は夜寝れないほど悩んで、使用される頻度が少ない上のファイルの削除となったそうです。確かに小さいプロジェクトではそれらは使用することはなさそうです。

また、tinkerで上で削除されているconfig/view.phpの設定を見ると、

> config('view')
= [
    "paths" => [
      "/var/www/repos/laravel-11x/resources/views",
    ],
    "compiled" => "/var/www/repos/laravel-11x/storage/framework/views",
  ]

と設定ファイルがないのに裏ではしっかりデフォルトが設定されています。

さて、私のお客さんのプロジェクトでShiftを使用してLaravel 11.xに更新後では、以下のファイルが削除されていました。

config/broadcasting.php
config/cache.php
config/cors.php
config/hashing.php
config/queue.php
config/session.php
config/view.php

先のLaravel 11.xのデフォルトのプロジェクトと違って、cache.phpやqueue.phpやsession.phpも削除されています。さらに、残ったconfig/app.phpとかでは今まで存在したコメントを含めてほとんどの中身が削除されています。

基本的に、ShiftはLaravel10.xのデフォルトと同じ中身なら削除、差分があるなら差分だけと残すという方針なのでしょう。先に説明したように、設定ファイルがないからと言ってその設定が存在しなわけではないのです。.envの値もチェックしてLaravelでは以前と同様に実行時には設定値の値をメモリーに設定します。

しかし、プロジェクトを管理する上で、裏で隠されているのは理解しにくいです。ということで私は手動でShiftで削除や編集されたファイルを復元することに決めました。

戻す作業は簡単。

$ php artisan config:publish

と実行すると、以下のようなメニューが表示されます。

そこで戻したいファイルを選択して戻すことができます。

しかし、すでに存在するファイルを戻したいなら、

$ php artisan config:publish --force

として実行するとすでに存在ファイルが上書きされます。

ベストは、Laravel 11.xの新規プロジェクトを他のディレクトリで作成して、そこでconfig:publishを実行してデフォルトのファイルを書き出し、それとあなたのプロジェクトのLaravel 11.x更新前のファイルと比較しながら変更することをお勧めします。

そのためには、

$ php artisan config:publish --all --force

を実行するのが良いです。

せっかくスリムになったのに設定ファイルを戻すのはプログラムのパフォーマンスに影響を与えるのでは？と思うかもしれません。しかし、本番環境では、以下の実行して最適化のキャッシュファイルを作成すればそのような心配の必要ないです。

$ php artisan config:cache

.envを変更する必要がある

config/のファイルを復元して、じみちに以前のファイルと比較して、以前に編集したconfigファイルを戻したりするのですが、そこで気づくのは、Laravel 11.xでは、環境変数の名前が変わっている、設定ファイルの環境変数のデフォルト値が変わっている、そして、以前は.envで設定できなかった環境変数が設定できるようになっていることです。

お客さんのプロジェクトでは、以下の値の.envへの追加あるいは編集となりました（＋は追加、ーは削除）。大半は以前.envで編集では設定できずにconfig/のファイルを編集していたので、良い変更かもしれません。

# config/app.phpでの変更により以前.envで設定できない環境変数ができるようになった
+APP_TIMEZONE=Asia/Tokyo
+APP_LOCALE=ja
+APP_FAKER_LOCALE=ja_JP

# config/auth.phpでの変更により.envで設定できない環境変数ができるようになった
+AUTH_GUARD=admin
+AUTH_PASSWORD_BROKER=admin

# config/cache.phpでの変更により環境変数名が変わった
-CACHE_DRIVER=file
+CACHE_STORE=file

# config/database.phpでの変更により環境変数のデフォルト値が変わった、また.envで設定できない環境変数ができるようになった
+DB_CONNECTION=mysql
+DB_CHARSET=utf8mb3
+DB_COLLATION=utf8mb3_general_ci
+REDIS_CLIENT=predis

# config/logging.phpでの変更により.envで設定できない環境変数ができるようになった
+LOG_STACK=single

# config/session.phppでの変更により.envで設定できない環境変数ができるようになった
+SESSION_EXPIRE_ON_CLOSE=false

削除されたEventServiceProviderの中身の行方

フレームワークのスリム化として、app/Providers/のファイルの統合化があります。その結果削除されたProviderの１つにEventServiceProvider.phpがあります。

私のお客さんのプロジェクトでは以前は、EventServiceProvider.phpにおいて、以下のようなイベントとリスナーのマップが設定されていました。

app/Providers/EventServiceProvider.php

...
class EventServiceProvider extends ServiceProvider
{
namespace App\Providers;

use App\Events\SanctumUnauthenticated;
use App\Listeners\CommandFinishedListener;
use App\Listeners\CommandStartingListener;
use App\Listeners\LoginListener;
use App\Listeners\LogoutListener;
use Illuminate\Auth\Events\Login;
use Illuminate\Auth\Events\Logout;
use Illuminate\Console\Events\CommandFinished;
use Illuminate\Console\Events\CommandStarting;

class EventServiceProvider extends ServiceProvider
{
    /**
     * The event listener mappings for the application.
     *
     * @var array
     */

    protected $listen = [
        SanctumUnauthenticated::class  => [
            SecureLogging::class,
        ],
        Login::class  => [
            LoginListener::class,
        ],
        Logout::class  => [
            LogoutListener::class,
        ],
        CommandStarting::class => [
            CommandStartingListener::class,
        ],
        CommandFinished::class => [
            CommandFinishedListener::class,
        ],
    ];"
...

Laravel 11.xの更新でEventServiceProvider.phpが削除された後には、上のマップを以下のように、AppServiceProviderにおいてEvent::listenのクロージャで設定可能となります。しかし、Shiftのサービスではこの自動変換は行われずに、PRでの説明だけとなっておりこの部分はとても頼りにならず、手動の編集が必要となります。

app/Providers/AppServiceProvider.php

namespace App\Providers;

use App\Events\SanctumUnauthenticated;
use App\Listeners\CommandFinishedListener;
use App\Listeners\CommandStartingListener;
use App\Listeners\LoginListener;
use App\Listeners\LogoutListener;

use Illuminate\Support\ServiceProvider;

class AppServiceProvider extends ServiceProvider
{
    /**
     * Bootstrap any application services.
     *
     * @return void
     */
    public function boot()
    {
        Event::listen(
            SanctumUnauthenticated::class,
            CommandFinishedListener::class,
            CommandStartingListener::class,
            LoginListener::class,
            LogoutListener::class,
        );
    }
...

しかし、app/Events/やapp/Listeners/で定義したイベントやリスナーをいちいちリストするのは面倒です。

もっと簡単なのは、bootstrap/app.phpにおいて、Laravelに見つけてもらうことです。

bootsrap/app.php

...
return Application::configure(basePath: dirname(__DIR__))
    ->withProviders()
...
   ->withEvents(discover: [
        __DIR__.'/../app/Events',
        __DIR__.'/../app/Listeners',
        __DIR__.'/../app/Modules/Pmaster/Listeners',
    ])
...

このように、withEvents()で必要なディレクトリーを指定するだけです。将来に追加や削除しても自動でdiscoverされます。

正しくdiscoverされているかを確認するには、以下のコマンドを実行します。

$ php artisan event:list

そして、本番環境では、以下を実行して先のcacheと同様に必要データをキャッシュします。

$ php artisan event:cache

最後に

Laravel 11.xへの更新作業は、Shiftのサービスとその後の手動確認と編集のハイブリッドになりました。Shiftで変更の対象を学び更新を理解しそれを適用という感じです。もちろんShiftの作業は後者の手動の作業に比べて非常に安い（２９ドル）のですが、一度理解できたら、他のプロジェクトでの同様な更新にShiftの利用は必要ないかもしれません。多分に将来はLaravelの更新作業は、AIですべて完璧に行ってくれるかもしれないですね。現在はまさに過渡期です。

Laravelはどの環境で実行されている？

Mon, 09 May 2022 02:45:59 +0900

Laravelの.envは、ご存知のように実行する環境により中身が違ってきます。その環境の種類を設定するのがAPP_ENVの環境変数です。今回はそのお話です。

設定値

Laravel以下のように.envファイル内でいろいろな環境変数の設定ができます。

.env

APP_NAME=Laravel
APP_ENV=local　# これが今回の主人公
APP_KEY=
APP_DEBUG=true
..

その中で、APP_ENVの値はどの環境であるかを設定します。既存値としては、local あるいは production の２つあります。ローカルの開発環境あるいはライブの環境です。しかし、必要ならば自分で好きな値で設定しています。私らのステージングサーバでは、stagingの値を使用しています。

また、.envでは指定しないですが、ユニットテスト実行のときに自動的に testing という値が設定されます。これは、phpunit.xmlの以下で設定しています。

phpunit.xml

...
  <php>
    <env name="APP_ENV" value="testing"/>
    <env name="APP_URL" value="https://localhost"/>
...

どの環境か判断

さて、プログラムの中でどの環境で現在実行されているかを、どのように判断するかというと、これ意外とバリエーションあります。

最近まで私が使用していたのは、

if (config('app.env') === 'production') {
    //
}

config()のヘルバーは他の環境変数でも使えるので重宝します。

しかし、マニュアルを見ると、以下のようにAppのファサードのメソッドを使っています。

if (App::environment('production')) {
    //
}

これ知らなかったなあ。しかも、複数の環境のテストも可能です。stagingあるいはproductionなら、

if (App::environment(['staging', 'production'])) {
    //
}

さらに、こんなのもありです。

if (App::isProduction()) {
    //
}

このバリエーションには、ローカル環境のチェックもあります。

if (App::isLocal()) {
    //
}

さて、テスト環境はなんだと思いますか？

if (App::runningUnitTests()) {
    //
}

残念、App::isTesting()ではなかったですね。

それから、Appのファサードを使用しなくても、app()のヘルパーを使用しても同様です。例えば、

if (app()->isProduction()) {
    //
}

最後に

環境変数と関係ないですが、コマンドラインでLaravelを実行しているときは、以下でチェックできます。

if (App::runningInConsole()) {
    //
}

tinkerで実行したら、

>>> App::runningInConsole()
=> true

phpdotenv

Sun, 21 Jun 2020 01:14:36 +0900

Laravelのプロジェクトでは、環境変数の設定は.envのファイルで行います。インストールするプロジェクトの環境（開発、ステージング、プロダクション）ごとで内容を変更できるし、.gitignoreに入れておけばバージョン管理のレポジトリでプライベートなデータ（パスワードやapiのトークンなど）を共有する必要もなく安全です。この機能、私の昔のphpのプロジェクト、つまりLaravel生誕以前の時代でのプロジェクトで現在もお客さんに使用されているプロジェクトでも取り入れたいです。

まず、この機能を提供するのは、phpdotenvというパッケージです。

https://github.com/vlucas/phpdotenv

Laravelのプロジェクトでは、以下のコマンドを実行すると、

$ composer show | grep dotenv
vlucas/phpdotenv                      v3.6.4   Loads environment variables from `.env` to `getenv()`, `$_ENV` and `$_SERVER` automagically.

とパッケージが使用されていることが確認されます。

さて、Laravelでないphpのプロジェクトでこのパッケージを使うには、以下のように、プロジェクトのディレクトリを作成してから、パッケージをインストールします。

$ mkdir dotenv
$ composer require vlucas/phpdotenv

チェックのためにテストのプログラムを作成します。

test.php

<?php
require_once 'vendor/autoload.php';
$dotenv = Dotenv\Dotenv::createImmutable(__DIR__);
$dotenv->load();                                                                                                                                                                                                   

echo $_ENV['BASE_DIR']."\n";

.envのファイルも作成します。

.env

BASE_DIR=/var/www/example

この時点で、このプロジェクトのディレクトリ構造は、以下のようになります。

.
├── composer.json
├── composer.lock
├── .env
├── test.php
└── vendor
    ├── autoload.php
    ├── composer
    ├── graham-campbell
    ├── phpoption
    ├── symfony
    └── vlucas

テストを実行してみます。

$ php test.php
/var/www/example

.envから値を取得できましたね。以下のような設定も可能です。

.env

BASE_DIR=/var/www/example
IMAGE_DIR=${BASE_DIR}/images

すでに設定した環境変数を.envの中で変数として使用できます。つまり、Laravelでも同様なことができるのですね、

ステージングサイトとアナリティクス

Mon, 15 Jul 2019 07:26:08 +0900

もちろんのことなのですが、私のお客さんのプロジェクトは皆パブリックでアクセスできる開発サイトがあります。そこで開発をするわけでなく、あくまでも本サイトにインストールする前に変更をお客さんに見てもらい使ってもらい、フィードバックをもらうためのサイトです。その意味では、ステージングサイトと言った方が正しいですね（お客さんとの間では開発サイトと呼んでいます）。

本サイトと違う部分

本サイトとステージングサイトの環境はシステムレベルではまったく同じで、OSもPHPもMySqlのバージョンなどすべて同じです。違うのは使用しているAWSのEC2のスケールで、ステージングにはもちろん安いインスタンスを使用しています。

プログラムレベルでは、Laravelの.envの中身。データベースの接続情報やメールの宛先とか、その他たくさん。しかし、この.envのおかげでステージングの設定は非常に簡単になりました。

それ以外にも、ずっと昔にどういうわけか間違ってステージングサイトで買い物をする本物のお客さんが出てきたので、サイトには必ず、ベーシック認証、そうあのポップアップの認証、をかけて保護しています。以下はサンプルですが、Laravelのための.htaccessを編集しています。

.htaccess

<IfModule mod_rewrite.c>
	# 以下4行はベーシック認証。ステージングのみ。パスワードは/etc/httpd/.htpasswdに保存。
	AuthType Basic
	AuthName "Password Protected Area"
	AuthUserFile .htpasswd
	Require valid-user

	<IfModule mod_negotiation.c>
		Options -MultiViews
	</IfModule>

	RewriteEngine On

	# Redirect Trailing Slashes...
	RewriteRule ^(.*)/$ /$1 [L,R=301]

	# Handle Front Controller...
	RewriteCond %{REQUEST_FILENAME} !/assets
	RewriteCond %{REQUEST_FILENAME} !/server-status
	RewriteCond %{REQUEST_FILENAME} !-f
	RewriteRule ^ index.php [L]

</IfModule>

アナリティクス

ステージングではもう１つ重要な違いがあります。ブレードに埋め込んでいるアナリティクスの情報です。

最近までは、以下のように、.envのAPP_ENV=productionの時だけレンダーするように、ブレードには @if (config(‘app.env’) == ‘production’)の条件文を使用していました。

...
@if (config('app.env') == 'production') 
<!-- Global site tag (gtag.js) - Google Analytics -->
<script async src="https://www.googletagmanager.com/gtag/js?id=UA-123456-1"></script>
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}
  gtag('js', new Date());

  gtag('config', 'UA-123456-1');
</script>
@endif
...

しかし、アナリティクスも複雑になってきて、グーグルタグマネージャも使用し始めたので、アナリティクスも開発のために本サイトとは違うアカウントあるいはプロパティを作成して本サイトと分ける必要が出てきました。となると、トラッキングID（上では、UA-123456-1）が本サイトとステージングサイトでは異なることになります。

トラッキングIDの値は、以下のように.envで簡単に設定することにします。

.env

...
GA=UA-123456-1
GTM=GTM-XYZ

GAはアナリティクスのトラッキングIDで、GTMはタグマネージャのコンテナIDです。

さらに、config/local.phpを作成します。

config/local.php

<?php

return [
    'ga'                        => env('GA'),
    'gtm'                       => env('GTM'),
];

そして、ブレードでは、

...
<!-- Global site tag (gtag.js) - Google Analytics -->
<script async src="https://www.googletagmanager.com/gtag/js?id={{ config('local.ga') }}"></script>
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}
  gtag('js', new Date());

  gtag('config', '{{ config('local.ga') }}');
</script>
...

とします。もう、@ifの条件文はもう必要でないので削除されていることに注意してください。

これで、本サイトであろうとステージングサイトであろうと、.envによりアナリティクスのIDを変更することができます。