Toranで更に便利なComposer

この記事はLaravel Advent Calendar 2015の2015年12月10日分です。

Laravelも乗っかっているComposerには、個人は無料で使用できる、PHPで組まれたローカルプロキシであるToran Proxyが存在しています。

Toranプロキシについては、このサイトで過去に「Composerのお手軽個人プロキシ、Toran+Proxy」でインストール方法と効果を紹介しています。簡単に言えば、個人のcomposerリポジトリをローカルに立てるプロキシです。基本Linux上に作成します。

ローカル環境にこのプロキシを立てると、プライベートリポジトリーと取得したパッケージのキャッシュが提供されます。

インストール後、使用したいプロジェクトのcomposer.jsonへ、次のようにリポジトリーの指定を加えると、使えるようになります。

"repositories": [
  {"type": "composer", "url": "http://toran.local/repo/private/"},
  {"type": "composer", "url": "http://toran.local/repo/packagist/"},
  {"packagist": false}
]

私の環境ではtoran.localでアクセスできるようにしてあります。Webブラウザでhttp://toran.localへアクセスすると、設定例として上記のコードを表示してくれます。もちろん、設定の変更やプライベートリポジトリーの登録もWebベースで可能です。

キャッシュプロキシとしての利用

Toranのインストール記事を書いた頃より、現在のほうがComposer自身のスピードが上がっています。この記事を書いた頃はComposer自身がローカルキャッシュをサポートした直後でした。

Toranのプロキシ動作は、一度取得したパッケージを設定により定期的にチェックし、必要に応じて新しいバージョンを予め取得し、キャッシュしてくれる機能です。設定によりプリフェッチしない、新しいバージョンのみプリフェッチする、全バージョンをいつも取得しておくという、３つの取得方法が選べます。

プロキシとして利用し、スピードアップに役立つかは、Toranをどう利用するかに関連しますので、一概には言えません。たとえば、私の開発環境では開発マシンにToranを載せています。以前はスピードアップに貢献していましたが、今は逆に遅くなります。理由の一つは既に述べたようにComposerの改善です。もう一つは開発環境のLinuxをバージョンアップしており、現在のバージョンではどうもToranを使用時に発生するhttpアクセスによる負荷の増大か、キャッシュをSSDではなくハードディスクに乗せているためそこがボトルネックになっているか、Apacheの設定が悪いのか、そうした理由で遅くなっている可能性があります。

もう少し正確に私の状況を書けば、Composerのキャッシュが働いていない状況、たとえばずっとlaravel/laravelをインストールしたり、updateをかけていなかったりし、キャッシュが古くなり、依存パッケージが全部取得される場合は、とても遅いです。Toran使用時より何倍も遅いです。逆にComposerのキャッシュが有効な場合は、３０秒かからずにインストールできますから、Toran使用時よりやや早いです。Composerのキャッシュが効いている場合でも、効いていなくても、Toranが有効なら４０秒程度になります。（今の状況であれば、新しくプロジェクトを作成するときは、laravel newコマンドを使い２０秒で構築し、updateやrequireを行うときはToranを通す使い方が良いようです。）

理想的にはToranを立てるマシンと開発マシンを２台ローカルに持てばよいのですが、そこまではやっていません。もちろん、みなさんの開発環境では問題なく動作し、Toranを利用した時のほうがComposerの実行は早くなるかもしれません。

Toranでは、Cronで定期的にパッケージの状態を監視して、設定に合わせて新しいバージョンを取得できます。Webでトップページヘアクセスし、SettingのページにあるArchive Settings項目を"New tags"か"All"に指定する場合は、新しいバージョンのパッケージが定期的に取り込まれます。これにより、依存パッケージがアップデートされている場合でもローカルから取得できるメリットがあります。

しかし、この項目を"Lazy"にするとプリフェッチはしませんので、Packagist Proxy項目のチェックを外してプロキシ動作を止め、Cronで"bin/cron"を定期的に起動するのはやめたほうが良いかもしれません。Composer自身のキャッシュハンドリングはかなり改善されています。Composerにまかせてしまいましょう。（プライベートリポジトリーとして利用する場合は、後記の通りCronプログラムの定期起動が必要です。）

残る利便性は、Packagistがダウンした時の、文字通り代替として動作してもらうことです。しかし、Packagistも最近はずっと安定しているようです。日本のミラーサーバーであるhttp://packagist.jp/もありますしね。

プライベートリポジトリーとしての利用

プライベートリポジトリのプロキシとして利用することもできます。まず以下の利点／欠点をご覧ください。

利点

数が増えてもcomposer.jsonに必要なプライベートリポジトリを全部指定する必要がなく、Toranが提供するリポジトリのみ１つ指定するだけでよい。

欠点

管理されるローカルリポジトリの変更が更新されるのは、Cron処理(bin/cron実行ファイルの実行）時のみ。即時反映されない。

ローカルリポジトリの反映がどの程度遅れるかは、Cron処理の実行頻度によります。１分間隔で起動しているなら、最長１分でしょうし、１０分間隔なら最長１０分です。

いずれにせよ遅延を避けるため、開発中でどんどん変わるようなローカルリポジトリーは直接composer.jsonに指定しておき、安定した後に社内やチームで共有できるようになったら、Toran経由で管理するのがよろしいかと思います。

kore1server