1年運用して気づいたLaravel環境（WSL + Docker）のメモ
概要
1年ほど前にDevContainerを使ったLaravel環境構築記事を書きました。
実際に運用して、明らかこれ間違ってたなってところが出てきたりしたのでメモという名の共有です。
Laravelと銘打ってはいますがPHP環境だったりもします。
なお詳細についてはとりあげず、何をしてどう解決したかを大味に書く記事になります。
対象の読者
- LaravelをWindowsで動かしたい人
- コンテナを使ってローカル環境を汚染したくない人
運用方針&PC環境
- OS:Windows11 Pro
- CPU:Core i7-11390H
- メモリ:16GB
アプリケーションの規模で言えば中〜大規模ぐらいのアプリケーションをLaravelで運用。
変更その1. Docker Desktopを捨てた
WindowsやMacでDocker環境を構築する際の定番アプリケーションはDockerDesktopだと思います。
実際便利かつマネージドされている部分が多く手軽に使えるのは魅力でした。ただアプリケーションの相性か単純に重いかは分かりませんがコンテナを起動したらPCファンが爆音になり続けたり、時折フリーズするといった問題がありました。
そこで、Docker DesktopをアンインストールしWSL（Ubuntu)に直接Docker Engineをインストールし運用したところ上記の問題はかなり解消されました。
それと今までdocker-desktop-dataに貯まっていたイメージやコンテナ等が全部消えて、100GBぐらい容量が空いたのはありがたかったです。（これは私の管理が甘いだけなんですが・・・）
変更その2. Windows直下ではなくLinux直下にプロジェクトを置く
Linux直下という表現は誤っている気がしますが、要するにmnt直下じゃない場所にプロジェクトを置こうねって話です。なんで？っていうのは上記の記事にある通りファイルI/Oのオーバーヘッド時間がバカみたいにでかいからです。
私はUbuntuのルートディレクトリに「/project」という感じに配置してそこにプロジェクトを配置しています。調べたらみんなやっていることなので基本かもしれないですが、当初は知らなかったです。
変更その3. ライブラリやキャッシュはできる限り同期しない
変更その2でI/Oの説明をしましたが、無駄なI/Oはその分動作を重くする原因になります。
ローカル/コンテナ間で頻繁にI/Oするが、特に必要性のないファイルは同期しない方が良いです。
代表的なのは「vendor」でしょうか。Nodeを使うコンテナ環境でも同じように「node_modules」を同期させず運用した方が良いですね。
vendor以外でいうと「storage/framework」「bootstrap/cache」も同期しないように設定しています。logディレクトリも書き込みが多いので非同期にしてもいいんですが、開発でのlog確認の煩わしさとそこまで処理速度も変わらないので同期させています。
変更その4. wslconfigを使った設定
処理を軽量にするため少しだけですが設定を加えています。
[wsl2]
memory=8GB
processors=2
[experimental]
autoMemoryReclaim=gradual
最後の行の設定はメモリ解放のオプションです。検証していないので本当に解放してくれているかは知りませんが、WSLはメモリをバカみたいに食うので解放してくれてたら嬉しいなぁ・・・って感じ。
微妙なところ
ファイル権限周り
Ubuntuやコンテナを使うと登場人物（ユーザー）がたくさん出てくるので、稀に権限がないよ（いつものdeniedエラー）が発生します。
sudoコマンドでゴリ押したりchmod/chownを乱用すればいいんですが（ローカルだし）UnixOSに精通していない開発者に勧めてこういった事象が発生した際のトラブルシューティングが若干面倒だなという感じ。
後コンテナ構築でマウントの際も登場人物が複数いるので権限エラーが出ることもあります。
稀にPHPStormが固まる
私だけかもしれないですが、PHPStormを立ち上げた時にプロジェクトを読み込んでくれないことがあります。特に始業直後が多いので何かしらの順序でWSLを落としてあげないといけないんだろうなと思いつつ、まぁクリティカルじゃないし面倒だからいいや・・・って感じだったりですが。
こうなった時は「wsl --shutdown」で再起動して、タスクマネージャーから強制終了して立ち上げたら直るんですが地味にストレスです。
A5SQLのカレントスキーマが変わる
私はA5SQLでDBのレコードを見るんですが、カレントスキーマが対象のスキーマからmysqlに変わってそんなテーブルねーぞ！ってよく怒られます。理不尽。
まぁDocker Desktopの時はコンテナとの接続がしょっちゅう切れていたので全然マシですが。
まとめ
実は元々VagrantでLaravel環境を構築していたのですが、重いし使いづらい（というか私がDockerにちょっと精通してただけ）のでDockerに乗り換えた経緯があります。
個人でNode環境をDockerで運用してて感触が良かったので推し進めたのですが、初めは不具合の方が多くて微妙だなぁ・・・って感じでした。
とはいえ運用していくうちに問題点も分かってきて、現状は乗り換えて良かったなぁって感じです。
ちなみに良い点は「軽い（動作）」「早い（立ち上げ）」「速い（zip等のコマンド速度）」「手軽」です。
顛末を最後に持ってくるスタイルで申し訳ありませんが、LaravelのDocker環境の開発はアリだと思います。ただある程度不具合も出てくるので、Vagrant等の開発環境で安定しているなら無理して移行しなくていい気もします。
ちなみに弊社ではPHPのバージョンを上げる際に私から勧めようと思っています。やはりイメージを変えるだけで簡単に移行できるのは最高。
Discussion