Docker環境での動作を爆速にする方法
目次
Dockerって便利ですよね
Dockerを利用して開発環境を作ることで様々な利点があります。
開発者間で環境の違いが出ない
こちらではエラーが発生するのに一方では出ないといったことはありません。
誰かに発生するバグはチーム内全員で発生します（データ問題は除く）。
環境構築が早い
docker-compose.ymlに定義済みなのでいちいち一つずつコマンドを実行する必要がありません。
新規に参画したメンバーもスムーズに環境を構築できます。
プロジェクトごとの環境の分離
言語やDBのバージョンが異なるプロジェクトが複数並行していてもコンテナを切り替えるのみで対応可能になります。
既存の開発環境に比べて高速
以前の仮想マシンと比べてメモリやCPUリソースも少なくてすむため高速です。
いにしえの頃にXAMPP環境で開発を行っていた頃を考えると隔世の感があります。
あのころはphpのバージョンが異なるプロジェクトの場合にローカルの対象phpのパスを無理矢理書き換えて対応していました。
便利だけどなんだか動作が遅くない？
立ち上がりは早い、軽い、便利！でもなんだか動作がもっさりする場合があります。
それはどうしてなんでしょうか？
Docker環境を重くする原因
Docker環境を重くする要因はマウントしているフォルダであることが多いです。
Laravelを例に紹介するとLaravelのルートフォルダ内でappフォルダ～testフォルダについては必ずマウントしないといけません。
マウントされているフォルダやファイルはコンテナ内に変更が即反映されるためです。
修正したコードが即反映されないと動作確認も大変になってしまいますよね。
では即反映される必要がないフォルダは何でしょうか？
それがvendorフォルダです。
基本的に初回のcomposer install、バージョン変更後のcomposer update以外では変更される可能性のないものです。
Docker環境でマウントされたフォルダは常に各ファイル、フォルダの変更を監視しており、それがすぐに反映されるようになっています。
例えばある程度大規模な、とあるプロジェクトの場合vendorフォルダ以外のファイル数は約7000で、vendorフォルダのファイル数は45000以上でした。ほぼ変更される可能性のないフォルダの大量のファイルを常に監視しているわけです。
npmパッケージを利用している場合はnode_modulesフォルダも同様の要因になります。
動作速度を改善する方法
不要なフォルダをマウント対象から外し、Dockerコンテナ内のボリュームとして定義することで改善可能になります。
volumes:
vendor-volume: #コンテナ内のvendorフォルダ用volume
services:
app:
build: ./php
volumes:
- php-fpm-socket:/var/run/php-fpm
- ../src:/work/backend
- vendor-volume:/work/backend/vendor #vendoerフォルダとしてvendorフォルダ用volumeをマウント
environment:
- DB_CONNECTION=mysql
- DB_HOST=mysql
- DB_PORT=3306
- DB_DATABASE=${DB_NAME:-laravel_local}
- DB_USERNAME=${DB_USER:-phper}
- DB_PASSWORD=${DB_PASS:-secret}node_modulesフォルダがある場合は同様に別volumeを定義して別途マウントするようにしてください。
唯一のデメリットとまとめ
フォルダをマウントしないということはdockerコンテナ内でcomposer install（update）してもIDEやエディタが参照するローカル側のvendorフォルダは空のままになってしまいます。
そのため、dockerコンテナ内でのcomposerとは別にローカルのコンソールからLaravelのルートに移動してcomposer install（update）を実行する必要があります。
ただ頻繁に発生する作業でもなく、毎日の開発作業が軽快であることの方がかなりのメリットになるでしょう！
Laravelを例にあげてみましたが、同様のフォルダを持つフレームワークは多いので応用することも可能です。是非不要なフォルダのマウントをやめることを検討してみてください。
