- 2014-03-06 (木) 11:00
- PHP
最近の PHPer が集まれば、一度は話題に上がるのが、この composer install をどこで実行するのか問題。
これまで聞いた話をまとめると、大きく分けて、以下の2パターンになります。どちらの方法を取っているか教えて下さい 😀
0. 前提
前提ですが、以下のような方法で、Composer 関連のファイルは管理しているとします。おそらく多くはこのような形になっていると思います。
- PHP コードは、Git などの VCS で管理する。
- composer.json, composer.lock は、VCS で管理する。
- composer.phar, vendor/ は、VCS で管理しない。
また、今回対象としているのはアプリケーションで、Packagist に登録して、配布するようなフレームワークやライブラリは対象外です。
1. 本番サーバで実行
本番PHPサーバ上で composer install を実行するパターンです。
本番PHPサーバに何かしらの方法で、PHP コードと共にcomposer.json
、composer.lock
を設置し、composer install
を実行します。
複数台サーバがある場合、それぞれのサーバで実行します。
コマンドの実行は、SSH でログインして手でする人もいるでしょうし、CapistranoやFabricなどで、自動化している人もいます。
順番としては、PHPコードをデプロイしてから、依存解決(composer install)になります。
2. 別サーバで実行して、実行結果を本番サーバに設置
本番PHPサーバ以外の場所で、composer install
を実行して、生成されたvendor/
を本番サーバに設置する方法です。
composer install
を実行する場所は、ビルドサーバの場合もありますし、開発者の PC の場合もあります。
本番サーバではcomposer install
を実行しないのがポイントです。
こちらは、依存解決してからデプロイの順になります。
私の場合
私自身は、本番環境については、2. の方法で行っています。
依存解決は、デプロイの前に行っておき、すでに依存解決されたものを本番環境にデプロイします。
The Twelve-Factor App で言うところのビルドステージで行うものという認識です。
ビルドステージ は、コードリポジトリを ビルド と呼ばれる実行可能な塊へと変える変換である。デプロイプロセスで指定したコミットのコードで指定されたバージョンを使って、ビルドステージは依存関係を取得してローカル環境に配置し、バイナリやアセットファイルをコンパイルする。
ビルドステージで可変部分は全て処理しておき、本番環境には、イミュータブルなパッケージとしてデプロイします。(実際は、パーミッションの設定など多少の操作は必要ですが)
複数台の場合、あちこちでcomposer install
を実行するのが単純に無駄というのもありますし、大きな可変部分を各サーバで実行するより、1箇所で生成して、全く同じものを各サーバに配布した方が安全かと。
ただ、1. の方が手軽なので、こちらを採用しているという意見も良く聞きますね。
さいごに
Composer が普及してきたからこそ出てくる議論だと思うので、すっかり利用するのが当たり前になりましたね。今後は、こうした運用面に関するノウハウも共有していきたいです。
上記案に限らず、こうしてるよ、などあれば教えて下さい。