Vagrant Archive

http://shin1x1.hatenablog.com/entry/ansible_local-provisioner-in-vagrant

2014 年も残すは、あと 1 週間になりました。今年も様々なイベントで登壇しましたので、発表したセッションと資料をまとめてみます。

写真提供：久岡写真事務所

登壇イベント

2014/04/04 「わかってるフレームワーク Laravel」Laravel勉強会福岡

「わかってるフレームワーク Laravel」とうタイトルで発表しました。

Laravel で、とあるプロジェクトの開発が終わった後だったので、Laravel への良さを主観たっぷりでお話しました。

翌日の Laravel Meetup Tokyo と合わせて、一人 Laravel Japan ツアーでした:D

2014/04/05 「知っておくべき Auth オートログイン」 Laravel Meetup Tokyo vol.3

Laravel 4.1.25 以前にあった Auth フィルタ利用時のオートログインの問題点についてお話しました。

いくつかの前提条件は必要ですが、影響度が大きいので、「これはやばい」というのが伝わっていました。

なお、この問題は、4.1.26 にて修正されたので、現在は問題ありません。

Laravel ユーザなら知っておくべきAuthオートログインのこと

2014/04/12 「Vagrant ユーザのための Docker 入門」 第３回コンテナ型仮想化の情報交換会@大阪

Docker が盛り上がってきた時だったので、Vagrant ユーザを対象に Docker 入門をお話しました。

セッション途中でも活発に質問が飛び込んできたり、デモでコンテナ起動の速さに驚きの声があがったりで、盛り上がったのを覚えています。

「VagrantユーザのためのDocker入門」を発表してきました

2014/04/19 「最近なんだか、はてブがおかしい」俺聞け8 in Tokyo

資料未公開

当初は「Webエンジンアとしてご飯を食べていく」という内容を考えていたのですが、事前に、主催の @msng さんから「ブログに関する発表が多くて嬉しい」というコメントがあったので、ブロブに寄せようと内容を変えました:)

会場には、著名なブロガーの方が多く、みなさん同じようなことを感じているようで、発表後の情報交換が捗りました。

2014/04/24 「Vagrant 体験入門」DevLove関西

これから Vagrant を学ぶ方向けに、Vagrant 概要についての発表と体験ハンズオンを行いました。

Vagrant ハンズオンでは、みんなで同一拠点から一斉にプロビジョンを行うので、遅延やエラーが起こったり、環境の違い（Vagrant + VirtualBox が起動するまでの）でトラブルが発生したりで、毎回発見があります。

ハンズオンの資料は Qiita に公開しています。

Vagrant体験入門ハンズオン手順 – 2014/04/24 DevLove関西

Vagrant体験入門ハンズオンの資料を公開します

2014/06/19 「Heroku で作るスケーラブルな PHP アプリケーション」第16回関西PHP勉強会

Heroku で PHP が正式サポートされたので、スケーラブルな構成をどう組むかという内容でお話しました。

その後、いくつかのプロジェクトで Heroku + PHP を使っているのですが、やはり PaaS として良くできていますね。まだ掴みきれていない部分もあるので、引き続き追いかけていきます。

Heroku で作るスケーラブルな PHP アプリケーション

2014/06/28 「PHPコードではなく PHPコードの「書き方」を知る」PHPカンファレンス関西2014

PHPカンファレンス関西の初心者向けセッションということで、FizzBuzz を題材に、関数化、クラス化、そして自動テストを書くという流れをお話しました。

「PHPコードではなくPHPコードの「書き方」を知る」を発表してきました

2014/07/05 「開発現場で活用する Vagrant」夏の JAWS-UG 三都物語 2014

関西での JAWS-UG イベント、三都物語でのセッションでした。JAWS-UG では久しぶりの発表になりました。

Vagrant を実際に使う例として、デモで実演しながらセッションを進めました。

会場がフランクな雰囲気で、話しやすかったのが印象的でした。あと Yo を使って、バーチャル拍手というかうなずきを送ってもらったりもしましたね。

「開発現場で活用するVagrant」を発表しました

2014/08/23 「Vagrant 心得 5 ヶ条」DevLove 甲子園 2014 西日本大会

資料未公開

DevLove 甲子園にて、Vagrant についてお話しました。ここでは、Vagrant を活用する上で、気をつけておくと良いことを 5 つにまとめました。

内容は、いずれ blog に書きたいと思います。

2014/10/11 「Ansible ではじめるサーバ作業の自動化」PHPカンファレンス 2014

PHP カンファレンスで、Ansible についてお話しました。発表を聴いた方からは、好意的なフィードバックが多く、「Chef を使っていましたが、Ansible 使ってみます！」という意見もあり、良かったです。

準備している時は、話したいことをどう上手くおさめるかを苦心したので、普段スピーカーをしているコミュニティの仲間から「うまくまとまっていましたね」と言ってもらえ、やはり見ている人には分かるんだなあと感じたりもしました。

このセッションを見た方から、別のイベントでの登壇についてお誘いがあったり、次につながったセッションでもありました。

「Ansibleではじめるサーバ作業の自動化」を発表してきました

2014/12/19 「ビルドサーバで使う Docker」DevLove 関西

年内最後の発表は、やはり Docker でした。今年は、ほんと Docker が躍進した一年でしたね。

Jenkins サーバでの活用例から、導入のポイントや設定方法などをお話しました。

「Jenkinsサーバで使う Docker」を発表してきました

ロクナナワークショップ 「Laravel で学ぶモダン PHP 開発講座」

11 月から、ロクナナワークショップさんにて「Laravel で学ぶモダン PHP 開発講座」という講座を行っています。

みっちり 1 日で、Vagrant や Composer の使い方、Laravel を使った REST API の実装、そして、その自動テストを書くという内容です。

すでに 2 回開催しているのですが、参加された方は熱心に課題に取り組まれていて、講師としても勉強になることが多いです。まとまった時間でじっくり課題をこなしていくので、これから学んでいこうという方にはおすすめです。

次回は 2015/02/17 に開催予定ですので、もし興味がある方は、ご参加下さい。

新原雅司のLaravel で学ぶモダン PHP 開発講座

さいごに

今年を振り返ってみると、自分で名乗り出るよりも、お声がけ頂いて、登壇するという機会が増えました。お声がけ頂けるのは嬉しく、スケジュールやタイミングが許せば、できるだけお引き受けしたいです。

人前で話すというのは、準備も大変ですし、いつも緊張しますが、毎回色々な発見があり、また、終わった後は何ともいえない解放感というか充実感を感じることができます。聴いて頂いた方からのフィードバックも嬉しいものです。

今年も、セッションに参加して頂いた方、イベントにお声がけ頂いた方、本当にありがとうございました。

2015 年は、年始の 1/16 に GoAzure 2015 で登壇する予定です。Websites でスケーラブルな PHP アプリケーションを作るという内容ですので、ご参加お待ちしています！

Vagrant でプロビジョンを行う際に時間がかかるのが、yum などを使ったパッケージのインストールです。ネットワーク環境が悪い場合、ダウンロード自体に時間がかかるため、大きな待ち時間が発生します。

vagrant-cachier プラグインを使うことで、このダウンロード時間を削減することができます。

vagrant-cachier プラグイン

vagrant-cachier プラグインは、プロビジョンなどでダウンロードしたパッケージをキャッシュしておくことで、次回以降のダウンロード時間を削減しようというプラグインです。

https://github.com/fgrehm/vagrant-cachier

vagrant-cachier プラグインの効果

これは効果を見たほうが早いと思うで、vagrant-cachier プラグインを導入した場合の効果についてです。

vagrant destroy で VM を破棄した後に、vagrant up を実行して、その実行時間を time コマンドで計測しています。

$ vagrant destroy -f
$ time vagrant up

今回、計測に利用した Vagrantfile は、ある PHP プロジェクトで利用しているものです。Ansible によるプロビジョン（VM内で実行）を行っており、Composer の実行や PHPUnit による自動テストも行っています。これらは本プラグインとは無関係なのですが、実際に使う場面で効果があるか見たかったので、この環境で計測しています。

• プラグインなし

比較のために vagrant-cachier プラグインを入れていない状態で、vagrant up を実行した結果です。

vagrant up  4.64s user 2.19s system 0% cpu 11:36.15 total

• プラグインインストール済み（初回）

vagrant-cachier インストールして、初回（キャッシュが無い状態）の実行時間です。

vagrant up  6.18s user 2.69s system 1% cpu 12:33.26 total

• プラグインインストール済み（2回目）

vagrant-cachier インストール後、キャッシュがある状態での実行時間です。

vagrant up  6.26s user 2.68s system 2% cpu 6:42.31 total

• 結果

結果を表にまとめたのが以下です。実行時間を比較してみると、プラグインをインストールして、キャッシュがある状態なら、実行時間が約半分になりました。これは大きな効果ですね。

	実行時間
プラグイン無し	11.36.15
プラグイン有り（キャッシュ無し）	12.33.26
プラグイン有り（キャッシュ有り）	6.42.31

インストール

vagrant-cachier プラグインをインストールするには、vagrant plugin install コマンドを実行するだけです。

$ vagrant plugin install vagrant-cachier

Vagrantfile への記述

vagrant-cachier プラグインを有効にするには、Vagrantfile に下記の設定を行います。config.cache.scope では、キャッシュスコープを設定します。

下記では、:boxを指定しており、これは、プロビジョンでインストールしたパッケージを Box 単位でキャシュします。同一 Box を使う Vagrantfile であれば、別の VM でもキャッシュを共有することができます。

私の用途であれば、この設定が使いやすそうです。

あとは、通常どおり、vagrant up を行うとプラグインが有効となり、キャッシュを行うようになります。

Vagrant.configure("2") do |config|
  # (snip)

  if Vagrant.has_plugin?("vagrant-cachier")
    config.cache.scope = :box  
  end

  # (snip)
end

その他のキャッシュスコープやオプションついては、vagrant-cachier のサイトを参照にして下さい。

http://fgrehm.viewdocs.io/vagrant-cachier/usage

何をキャッシュしているのか

プロビジョンで追加したパッケージをどうやってキャッシュしているのか気になったので、仕組みを見てみました。

コードを見たところ、CentOS の場合は、ゲストの /var/cache/yum が /tmp/vagrant-cache/yum へのシンボリックリンクになっています。そして、この /tmp/vagrant-cache/ は、ホスト側との synced_folder となっており、~/.vagrant.d/cache/BOX_NAME/ がマウントされています。

つまり、ゲストで yum install コマンドでインストールすると、/var/cache/yum にパッケージのキャッシュファイルが保存されます。これは、ホストの ~/.vagrant.d/cache/BOX_NAME/yum と synced_folder で同期しているので、結果としてホストにこのキャッシュファイルが保存されます。

これは、なかなか面白い仕組みですね。

さいごに

vagrant-cachier プラグインを使うことで、プロビジョンの実行速度が大きく改善されます。プロビジョンコードを書くと、検証のために何度もプロビジョンを実行することになり、その度に待たされていました。このプラグインを使うことで、その時間が削減できるので、プロビジョンが捗ります。

ちなみに、このプラグインは、CakePHPで学ぶ継続的インテグレーション を読んで、知りました。

いま読み進めているところですが、PHP で CI したい人には嬉しい内容になっています。書評は、また別エントリで書きますね。

PhpStorm 8 が、リリースされましたね！

PHP 5.6 や Laraevel の blade 対応など気になる新機能があるのですが、その中でも、注目なのが、PHPUnit by Remote Interpreter です。

この機能を使うことで、Vagrant VM にインストールされている phpunit をホストの PhpStorm から直接実行することができます。Vagrant による開発が普及してきた今では必須の機能といえるでしょう。

利用するには、いくつか設定が必要となるので、その手順を書いてみます。

対象の PHP アプリケーション

このエントリでは、以下の環境で PHP アプリケーション開発しているという想定で進めていきます。

• Vagrant VM で PHP アプリケーションを実行
• PHPUnit は、Composer でインストール
• PHPUnit の設定は、phpunit.xml に記述

PHP Interpreter の設定

はじめに PHP Interpreter に Vagrant VM の php を指定します。

Preferences – PHP を開いて、Interpreter プルダウンメニュー横にある ... をクリックします。

クリックすると Interpreters ダイアログが表示されます。まず、左上にある ＋ をクリックして、Remote...を選択します。

Configure Remote PHP Interpreter ダイアログが表示されるので、Vagrant を選択します。選択すると、Vagrant 用の入力フォームに表示が変わり、各フォームに自動で値が入ります。ここでは編集せずに進みます。もし必要があれば変更して下さい。

OKを押すと、Vagrant VM と通信して、設定項目が妥当か検証が行われます。問題無ければ、ダイアログが閉じます。

Interpreter ダイアログの左側ツリーには、追加したRemote PHP 5.5が表示されます。右側フォームの General には、Vagrant VM にインストールされている PHP と Xdebug のバージョンが表示されるので、念のため確認しておくと良いでしょう。

OKを押して、ダイアログを閉じます。

PHP に戻ると、設定した Interpreter が選択されています。OKをクリックして、PHP Interpreter の設定は完了です。

PHPUnit By Remote Interpreter の設定

次に PHPUnit の設定を行ないます。Preferences – Project Settings – PHP – PHPUnit を開きます。

PHPUnit ダイアログの左上に ＋ があるので、これをクリックして、By Remote interpreterを選択します。

PHPUnit By Remote Interpreter ダイアログが開きます。Interpreter に先ほど登録したRemote PHP 5.5を選択して、OK をクリックします。

ダイアログが閉じると、右側に PHPUnit の設定項目が表示されます。

PHPUnit 関連のファイルは、Composer のオートローダーから読み込むので、PHPUnit library には、Use custom autoloader を選択します。Path to script が表示されるので、Composer の autoload.php のパスを設定します。なお、この設定は VM 内でのパスを指定する必要があるので注意して下さい。（テキストボックス横の ... をクリックすると、VM 内のパスを GUI で指定することができます。）

次に、Test Runner の Default configuration file にチェックを入れて、phpunit.xml のパスを指定します。（phpunit.xml を利用していない場合、これは不要です。）ここのパスも VM 上のパスになります。

設定が完了したら、Apply もしくは OK をクリックします。これで、PHPUnit By Remote Interpreter の設定は完了です。

Run/Debug Condigurations での PHPUnit 設定

最後に、IDE からテストを実行するために、Run/Debug Configurations にて PHPUnit の設定を行ないます。

画面左上にある ＋ をクリックして、PHPUnitを選択します。（PHPUnit on Server ではないので、注意して下さい。）

Name には、それと分かる名称を記述します。ここでは PHPUnit on Vagrantとします。

次に、Test Runner の Test scope を選択します。ここでは、前項で phpunit.xml へのパスを指定しているので、Defined in the configuraion fileを指定します。（テストディレクトリを指定したい場合は、Directoryを選択して、対象のディレクトリを記述して下さい。）

OKをクリックして、設定は完了です。

PHPUnit の実行

いま設定した PHPUnit を実行してみます。ウィンドウメニューバー右上にて、下記のように設定したPHPUnit on Vagrantを選択した状態で、右側の矢印をクリックするとテストが実行されます。（ Run を実行すれば良いので、メニューから選択しても、CTRL + R でも良いです。）

テストが実行できました！

IDE から Vagrant VM の PHPUnit を実行する良さ

実際に使ってみて良かった点です。

1. 操作が楽

これまでテストを実行する時は、ターミナルアプリケーション に遷移して、phpunit コマンドを実行していました。それが、PhpStorm 内で CTRL + R だけで実行できるようになりました。ちょっとした手間ですが、同じウィンドウで済ませられるので楽です。

2. diff が見やすい

アサーションでテストが失敗した時に、期待した値と実際の値と差分を表示することができます。この差分表示は、コードの変更差分と同じ形式で、左に期待した値、右に実際の値を表示してくれます。これは phpunit コマンドの実行結果に比べて、分かりやすいです。

3. 各テストの実行時間が分かる

テスト全体の実行時間だけでなく、各テストケースの実行時間も記録されているので、一覧で確認することができます。もちろん、実行時間で並べ替えもできるので、遅いテストの確認なども簡単です。

さいごに

PHPStorm 8 の PHPUnit By Remote Interpreter を使って、PhpStorm から Vagrant VM にある PHPUnit を実行してみました。

上でも書きましたが、設定して、開発サイクルでテストを実行すると、想像していた以上に楽です。テストの実行が気軽にできますし、結果も分かりやすいです。

Vagrant を使って、PHP アプリケーションを開発しているなら、ぜひ設定してみて下さい。

参考

http://confluence.jetbrains.com/display/PhpStorm/Running+PHPUnit+tests+over+SSH+on+a+remote+server+with+PhpStorm

PhpStorm から Vagrant で構築した VM の PHP アプリケーションをリモートデバッグする方法です。Web アプリケーションだけでなく、CLI アプリケーションでもリモートデバッグできるように設定していきます。

VM スペック

• 192.168.33.41 を private network で設定
• PHP + Xdebug がインストール済み
• ホストと VM は、synced folder でディレクトリを共有（/path/to/src -> /share）

0. Xdebug によるリモートデバッグの仕組み

リモートデバッグを設定する前に PhpStorm と Xdebug がどのように通信するかを見ておきます。これを理解しておくと設定がスムーズです。

下記は、Xdebug の公式サイトに掲載されている図です。ここでは、左の「IDE」が PhpStormが起動しているホスト、右の「PHP/Xdebug」が Vagrant で構築した VM と考えて下さい。

VM に HTTP リクエストが来て、PHP スクリプトの実行がはじまると、PHP/Xdebug が IDE（xdebug.remote_hostで設定したホスト）に DBGP connect の通信を行います。PhpStorm ではこの通信を受け取り、以後は DBGP で相互に通信してリモートデバッグを実現します。

ここで大切なのは、PHP/Xdebug（VM）から、PhpStorm へ DBGP connect の通信が来るという点です。これは Web でも CLI でも同じで、PHP スクリプトが VM で実行されると PhpStorm へ DBGP connect が送られてきて、リモートデバッグを開始することができます。（xdebug.remote_autostart= Onを設定した場合）

もし、うまく動かない場合などは、この点を意識して調査すると良いです。

では、実際に設定を行っていきましょう。

1. VM での設定

まず、VM にインストールされている PHP にリモートデバッグ用の設定を行います。通常は、VM を構築する際に実行するプロビジョニングに以下を含めておきます。

Xdebug が必要になるので、下記のコマンドなどで、インストールしておいて下さい。

$ yum -y install php-pecl-xdebug

1-1. php.ini(xdebug.ini)

Xdebug の設定を php.ini 等で以下のように設定します。

xdebug.remote_enable = On
xdebug.remote_autostart = On
xdebug.remote_host = 192.168.33.1

• xdebug.remote_enableで、リモートデバッグを有効にします。
• xdebug.remote_autostartを On にすることで、リモートデバッグが常に開始されるように設定します。任意のタイミングだけ開始することもできるのですが、開発環境なので、VM側では常に開始されるようにしておき、実際にデバッグを行うかどうかは PhpStorm 側で操作します。
• xdebug.remote_hostで、デバッグクライアントの IP を指定します。Vagrant の private network で 192.168.33.xxxを設定しているので、ホスト側の IP として192.168.33.1を設定しています。

1-2. 環境変数

CLI アプリケーション（phpunitコマンドでのテストを含む）でのデバッグを行うために、環境変数PHP_IDE_CONFIGを設定します。

CLI アプリケーションを実行するユーザでPHP_IDE_CONFIG環境変数を定義したいので、ここでは、vagrant ユーザの ~/.bashrc に設定しておきます。

192.168.33.41の部分には、VM の IP を指定しておきます。

export PHP_IDE_CONFIG="serverName=192.168.33.41"

もし、apache ユーザで CLI アプリケーションを実行するなら、httpd.conf 等の SetEnv などで設定すると良いでしょう。

2. PhpStorm での設定

PhpStorm でリモートデバッグクライアントの設定を行いましょう。

2-1. PHP Remote Debug

まず、メニューの [Run] – [Edit Configurations…] をクリックして、[Run/Debug Configurations] ダイアログを開きます。

次にダイアログ左上にある [+] をクリックして、[PHP Remote Debug] を選択します。すると、下記のように PHP Remote Debug の設定フォームが表示されます。ここでリモートデバッグの設定を入力していきます。

Name には、この設定の名称を指定します。ここではVagrantとしています。

Servers には、PHP サーバをプルダウンで選択するのですが、まだ設定が無いので、後ほど設定します。

Ide key は、今回は設定不要なのですが、何かしら値が必要なので、ダミー値を入力します。

2-2. Servers

Servers にサーバを追加するために、Servers のプルダウンメニュー横にある「…」ボタンをクリックします。クリックすると、[Servers] ダイアログが開きます。

[Servers] ダイアログでは、PHP アプリケーションが動作しているサーバの情報（ここでは Vagrant VM）を設定します。

ダイアログ左上にある [+] をクリックして、新規サーバを入力します。

Name には、名称を入力します。名称は何でも良いのですが、ここでは VM の IP を入力します。この値は、VM で設定した環境変数PHP_IDE_CONFIGの中で記述するserverName=の値と同じ内容にする必要があります。

Host には、VM の IP を入力します。

Use path mappings にチェックを入れます。ここでは、ローカルのファイルパスと VM でのファイルパスをマッピングを設定します。

この Vagrantfile では、ローカルの /path/to/src を VM 上では /share というディレクトリにマウントしているので、File/Directoryで /path/to/src を選択し、その右にある Absolute path on serverに /share と入力しておきます。

設定例は下記になります。

[OK] をクリックすると Servers ダイアログが閉じます。この時に [Run/Debug Configurations] では、Servers には、現在設定したサーバが選択されています。

最後に [OK] をクリックすると、設定が保存され、ダイアログが閉じます。これで設定は完了です。

3. 動作確認

では、実際にリモートデバッグを試してみましょう。

PhpStorm でリモートデバッグを有効にするには、[Run] – [Start Listen for PHP Debug Connections] をクリックします。クリックすると [Stop Listen for PHP Debug Connections] という表示に切り替わります。この状態で、再度クリックするとリモートデバッグが停止します。

今回の設定では、VM 側は常にリモートデバッグ可能な状態になっているので、PhpStorm でのこの操作でリモートデバッグを行うかどうかを切り替えることができます。

リモートデバッグが動作しているか確認するのに、[Break at first line in PHP scripts] にもチェックを入れておきます。

3-1. Web アプリケーション

では、ブラウザから、VM にある PHP スクリプトにアクセスしてみましょう。（ここでは、Laravel アプリケーションを動かします。）

http://localhost/ にアクセスすると、処理が停止して、PhpStorm のデバッガが起動しました。

これは [Break at first line in PHP scripts] にチェックが入っているためで、一番はじめの行で処理が停止するようになっています。[Step Over] や [Step into] で、順にコードを実行して、PhpStorm 上で実行されている行が正しく遷移するか確認すると良いでしょう。

確認が終わったら、[Run…] でコードを実行する、もしくは [Stop] で停止させましょう。

3-2. CLI アプリケーション

CLI アプリケーションについてもリモートデバッグができるか確認しましょう。

vagrant ssh で、VM にログインして、何か PHP アプリケーションをコマンドラインで起動します。ここでは php artisanコマンドを実行します。

$ php artisan

すると、Web アプリケーションと同じく、はじめに実行される行で処理が停止し、PhpStorm のデバッガに制御が移ります。

PHPUnit なども実行して、同様になるか確認しておくと良いでしょう。

これで、Web でも CLI でも PHP アプリケーションでリモートデバッグができるようになりました。あとは順に実行するなり、任意のコードにブレイクポイントを仕掛けるなり、デバッグを行うことができます。

なお、動作確認用にチェックしておいた [Break at first line in PHP scripts] ですが、アプリケーション実行の度に停止するのは面倒なので、普段はチェックは外しておきましょう。

4. トラブルシューティング

4-1. デバッガが起動しない

おそらく基本的な設定ミスなので、手順を再確認します。

• xdebug 関連の設定変更後に Apache/php-fpm の再起動を行う
• PhpStorm で[Start Listen for PHP Debug Connections]を行う

4-2. デバッガは起動するのに、ステップ実行できない

PhpStorm の [Servers] 設定のパスマッピングの設定を見直します。

4-3. Cannot accept external Xdebug connection: Cannot parse the value of ‘$_SERVER[‘PHP_IDE_CONFIG’]’

CLI アプリケーションでリモートデバッグを行う際に発生しました。
環境変数PHP_IDE_CONFIGが正しくセットされていなかったので、VM 側の設定を見直します。

さいごに

PhpStorm から Vagrant で構築した VM へのリモートデバッグ設定について見てきました。

はじめは面倒に見えますが、慣れてくればかなり楽に設定できます。VM 側の設定は、プロビジョニングに記述しておくと良いでしょう。

やはり、処理の流れはデバッガを使った方が掴みやすいので、ぜひ活用してみてください。

参考

http://www.jetbrains.com/phpstorm/webhelp/run-debug-configuration-php-remote-debug.html
http://www.karakaram.com/phpstorm-vagrant-remote-debug
http://blog.jetbrains.com/webide/2012/03/new-in-4-0-easier-debugging-of-remote-php-command-line-scripts/

JAWS-UG三都物語 2014 にて「開発現場で活用するVagrant」という発表を行いました。

Photo By Yuko Oshima

5 つトラックがあるなか、テクニカルトラックでの発表でした。開放感を感じる会場で、快適にセッションを行うことができました。

発表内容

Vagrant を現場で活用していく上で参考になる情報を、と考えたところ、やはり実際に動くデモが良いと思い、デモを中心にセッションを行いました。

発表資料は、以下です。

デモで利用した Varantfile などは、下記で公開しています。

https://github.com/shin1x1/vagrant-demo-20140705

デモでは、同じ PHP アプリケーションについて仮想環境やプロビジョニングツールを変えて構築を行いました。（実際に一からコードを書く時間が無かったので、できあがったものをお見せする形でした。）

Vagrant と連携ツールの整理

Vagrant の話になると、VirtualBox や Chef など多くのツールが一緒に登場してきます。

こららを頭の中で整理できていないと、カスタマイズしたり、トラブルが発生した際にどれを見れば良いかが分からない、という状況になりがちです。

セッションでは、連携ツールを「仮想環境」と「プロビジョニング」に分けて整理してみました。

vagrant up だけ、にこだわる

セッションでもお話したのですが、Vagrant で開発環境を構築する際に大事なのは、「vagrant upコマンドだけで環境を作る」ということです。

デモでは、Ansible でプロビジョニングを行う箇所もあったのですが、Ansible はホスト側にはインストールせず、ゲスト側（仮想マシン）にシェルスクリプトでインストールして、仮想マシン内でローカルコネクションでプロビジョニングを行うようにしました。

provision = <<-EOT
    rpm -ivh http://ftp.riken.jp/Linux/fedora/epel/6/i386/epel-release-6-8.noarch.rpm
    yum -y install ansible libselinux-python
    ansible-playbook /vagrant/provision/vagrant.yml --connection=local
EOT

config.vm.provision :shell, :inline => provision

Vagrant で開発環境を作れば、チーム内で誰の環境でも同じ環境を持つことができます。

それなのに、Vagrant や VirtualBox など最低限なツール以外のものをホストに要求すると、それらをインストールする手間も発生しますし、ホストの差異による挙動の違いやバージョンにも気を払う必要が出てきます。

仮想マシン内に閉じ込めておけば、インストールは自動で行うことができ、考慮すべきプラットフォームも一つ（仮想マシンのみ）で済みます。

せっかく、Vagrant で開発環境の構築が自動化されているのに、それを動かすためのツールで手間がかかるというのはもったいない気がします。

これはコマンドについても同じです。環境構築ではvagrant upのみを実行するようにします。それ以外のコマンドはプロビジョニングに含めて、仮想マシン内で実行します。

Vagrant で開発環境を作るのであれば、ホストには、必要最低限（Vagrant と VirtualBox）のツールだけをインストールして、vagrant upコマンドだけで構築ができるようにプロビジョニングの内容を組み立てるようにしましょう。

発表中に Yo をもらう

セッション開始前に、Yo のアカウントを公開して、発表中に少しでも「いいね！」と思う箇所があれば、Yo を送って下さいと呼びかけてみました。

会場では、そもそも Yo をインストールしている方が数人だけだったのですが、デモの際に何度も Yo を送ってもらいました。

ポケットの中で、iPhone が震える度に、「あー伝わってるなあ」と安心することができ、楽しくセッションを進めることができました 😀

これ、意外に嬉しいので、発表される方は、試してみると良いですよ。

Yo を送って下さったみなさん、ありがとうございましたm(_ _)m

さいごに

おかげさまで Vagrant に関する発表を、とお声がけ頂く機会が何度もあるので、色々と手を変え品を変えといった感じで試行錯誤しながらやっているところです。

このあたりは変化も早く、色々と新しい内容が出てくるので、毎回資料を作りながら発見もあり、面白いですね。

やはり今後は Docker との絡みが面白くなりそうなので、また機会があれば話してみたいと思います。

セッション中に頂いた tweet

ありがとうございました！

新原さん待ち #jawsug #santo

— mollifier (忍者) (@mollifier) July 5, 2014

Yoの使い方が分からん #jawsug

— 片山 暁雄 (@c9katayama) July 5, 2014

あの議員さんはVagrantがわからなくて会見でうわあああああああってなったのか………！ #jawsug #santo

— yamadoo (@MadaYama) July 5, 2014

VargrantDocker入門はこちらで。 http://t.co/PTqQrAcv5d #jawsug #santo

— s.hiruta (@web_se) July 5, 2014

YOインストールしてみたけど、使い方がわからなくてググってる #jawsug #santo \

— あみだく (@amidaku) July 5, 2014

デモが素晴らしい！Vagrant、帰ったらすぐ使える勢い #jawsug #santo #track2

— yamadoo (@MadaYama) July 5, 2014

きゃー、新原さーんがVagrantデモ中。あれ？社員がw #jawsug #santo http://t.co/6joHeG6tyV

— Kazutaka Goto ☁ 後藤和貴 (@kaz_goto) July 5, 2014

とてもわかりやすいセッションだけぢ、YO!の使い方がわからないくて送れない件 #jawsug #santo

— ばしし (@rada_bashishi) July 5, 2014

Vagrantの基本が詰まったいいお話。 #jawsug #santo

— f_prg (@f_prg) July 5, 2014

vagrant upのみにこだわるが大切 #jawsug #santo

— kunihiro morita (@morita92hiro) July 5, 2014

2014/04/24 DevLove関西にて、Vagrant体験入門を行いました。

これからVagrantを使ってみようという方向けに、Vagrantを触ってみようというイベントです。

前半にVagrantの概要を話すセッションを行ない、その後ハンズオンで実際にVagrantに触れてみるという構成でした。

発表資料

前半で、Vagrantの概要を話した際の資料です。

ハンズオンをはじめるにあたって、下地となる内容を話しました。

Vagrant に関する発表は何度か行っていますし、本やblogを書く際にも何度と無く調べていますが、Vagrant自体の進化が速いので、見直すたびに発見があって面白いです。

ハンズオン資料

ハンズオンの手順は Gist にまとめることが多いのですが、今回は Qiita に書きました。Kobito があるとサクサク書けるのが良いですね。

http://qiita.com/shin1x1/items/3288d9de7f04192b6ad8

ハンズオンでは、メモリスティックで、Vagrant、VirtualBox、Box を配布しました。Boxは下記を利用したので、参加されていない方もこれをダウンロードすれば、Qiitaの手順でハンズオンが試せるようになっています。

• 64bit 環境
  http://opscode-vm-bento.s3.amazonaws.com/vagrant/virtualbox/opscode_centos-6.5_chef-provisionerless.box

• 32bit 環境
  http://opscode-vm-bento.s3.amazonaws.com/vagrant/virtualbox/opscode_centos-6.5-i386_chef-provisionerless.box

今回は、「Vagrantを体験する」内容となっていますが、もう少し踏み込んで、プロビジョニングを書き進めたり、Vagrant Shareで公開、AWS or DigitalOceanで公開なども面白そうです。

ハンズオンの内容が良かったよ、とお褒めの言葉を頂いたので、別のイベントや研修などで活用してやって下さい。

さいごに

ハンズオンは、見学のみ（自分では作業しないけど見るだけ）もありということになっていたのですが、全員がノートPC持参で真剣に取り組んでいました。準備した甲斐がありました:D

すでに現場でVagrantを活用されている方も数名おられて、ハンズオンの合間などでお話できて楽しかったです。

これからさらにVagrantを活用する人が増えていくと思うので、そういった人たちで情報交換できるようなイベントもやってみたいですね。

第3回 コンテナ型仮想化の情報交換会＠大阪 で行った発表です。

コンテナ超人みたいな人ばかりで、この内容で発表して良いものやらと思ったのですが、アプリケーションを書く側からの視点で話してきました。

Vagrant ユーザのための Docker 入門

Docker を知った時は、速くなった Vagrant のようなものだと思っていたのですが、色々と見る内にそもそも別のもので、ユースケースとして重なるところはあれど、別のツールだと認識した方が良いです。

Docker の入り口としては、デモを見てもらうのが、手っ取り早いので、そのあたりが伝わったなら良かったです。

Introduction to Docker

発表で引用した「Introduction to Docker」は下記です。公式の資料なので、色々ググる前に、まずはこれを読むのがおすすめです:D

CentOS で Docker を動かす Vagrantfile

デモで使った Docker が動く CentOS を作る Vagrantfile です。

https://github.com/shin1x1/vagrant-centos-docker.git

# -*- mode: ruby -*-
# vi: set ft=ruby :

# Vagrantfile API/syntax version. Don't touch unless you know what you're doing!
VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  config.vm.box = "opscode-centos65"
  config.vm.box_url = "http://opscode-vm-bento.s3.amazonaws.com/vagrant/virtualbox/opscode_centos-6.5_chef-provisionerless.box"

  config.vm.provider :virtualbox do |vb|
    vb.name = "docker"
    vb.customize ["modifyvm", :id, "--memory", 1024]
  end

  config.vm.network :private_network, ip: "192.168.33.10"
  config.vm.network :forwarded_port, guest: 4243, host: 4243

  config.vm.provision :shell, :inline => <<-EOT
    #
    # iptables off
    #
    /sbin/iptables -F
    /sbin/service iptables stop
    /sbin/chkconfig iptables off
    #
    # yum repository
    #
    rpm -ivh http://ftp.riken.jp/Linux/fedora/epel/6/i386/epel-release-6-8.noarch.rpm
    yum install -y vim-enhanced telnet
    #
    # docker
    #
    yum install -y docker-io
    sed -i 's,^other_args="",other_args="-H tcp://0.0.0.0:4243 -H unix:// -dns 8.8.8.8",g' /etc/sysconfig/docker
    chkconfig docker on
    service docker restart
  EOT
end

さいごに

Docker 盛り上がっていますね。

今後、本番環境としての Docker 活用例や、Docker コンテナをそのまま deploy できる DaaS（Docker as a Service）が増えてくると、面白くなりそうです。

なお、Docker が出たから、Vagrant は終わりとかそういう話では無いので、今後も Vagrant も活用していきたいですね。

Vagrant 1.5 がリリースされました。1.1 以来の big change ということで、目新しい機能が追加されています。

目玉はやはり Vagrant Share だと思うのですが、その他にも Web システムの開発に Vagrant を使っている人には嬉しい機能が追加されています。

その一つが Rsync Synced Folder です。

Rsync Synced Folder

Vagrant には、ホストマシンとゲストマシンとでファイルを共有、同期する機能があります。

これにより、開発はホストマシンで行い、実行は LA(MP)P 環境であるゲストマシンで行うという、いいとこ取りができました。

この機能を実現する方法として、shared folder（VirtualBox の機能）や NFS を利用することができたのですが、これに rsync による同期が追加されました。

ホストマシンからゲストマシンへ rsync で同期を行います。

嬉しいこと

Rsync Synced Folder は、rsyncで同期を行うだけなので、ゲストマシン側はネイティブなファイルシステムが利用できます。つまり、synced folder の仕様に影響されなくなります。

パフォーマンス

分かりやすいメリットとしては、VirtualBox の shared folder に比べると、パフォーマンスが向上します。手元にある PHP アプリケーションでは、shared folder で 90 秒程度かかっていたユニットテストが、60 秒程度に短縮しました。

また、NFS と違って、ホスト側でデーモンを起動しておく必要が無いのも大きなメリットです。

パーミッション

shared folder では、パーミッションをディレクトリやファイルごとに設定することができなかったのですが、rsync を利用すれば、ゲストマシンからは通常のファイルシステムなので何も支障がありません。

ただ、現状の Rsync Synced Folder では、同期時にファイルオーナーを強制的に書き換える仕様になっているので、この点については留意しておく必要があります。（後述）

自動更新機能

この rsync は、基本的にはvagrant up, vagrant reload, vagrant provision、そして今回新設されたvagrant rsyncコマンド実行時に行われます。

これだとファイルを変更する度にコマンドを実行するのが面倒になるのですが、vagrant rsync-autoコマンドを実行することで、自動で同期を行うことができます。設定で同期対象となったディレクトリに変更があれば、自動で同期処理を行います。

どのようなプロバイダでも同期可能

AWS や DigitalOcean のようなクラウドサービスをプロバイダとして使っている場合も、rsync-auto による自動同期が可能です。

コードを変更すると、クラウド上のサーバに自動で同期されます。

要件

この機能を利用するには、ホストとゲストの双方にrsyncコマンドが必要になります。

ホストについては、OSX であればデフォルトでインストールされています。

ゲストについては、もしインストールされていなくても、主要な OS については、Vagrant が自動でインストールしてくれます。例えば、RedHat 系であれば yum -y install rsyncが実行されます。

これは気が効いてますね。

設定

Vagrantfile の synced folder の設定で、type=rsyncを指定します。

config.vm.synced_folder "src", "/share", type: "rsync"

設定には下記のようなオプションがあります。

• rsync__args
  rsync コマンドに渡す引数です。デフォルトでは["--verbose", "--archive", "--delete", "-z"]が指定されています。

• rsync__auto
  rsync-auto による自動同期の対象にするかどうかです。デフォルトは、trueです。

• rsync__exclude
  同期の対象外にするファイルやディレクトリを指定します。デフォルトでは[".vagrant/"]が指定されています。

例えば、.git ディレクトリは同期対象から外すなら、下記のようにrsync__excludeを指定します。

config.vm.synced_folder "src", "/share", type: "rsync", rsync__exclude: [".git/"]

手動で同期する

vagrant up、vagrant reload、vagrant provision、vagrant rsyncを実行すると、Vagrantfile の synced_folder で指定したディレクトリについて、rsync による同期を行います。

ファイルを同期したいだけなら、vagrant rsyncを実行します。

$ vagran rsync
==> default: Rsyncing folder: /path/to/src/ => /share

自動で同期する

自動で同期するには、vagrant rsync-autoコマンドを実行します。コマンドを実行すると、synced_folder で指定した同期対象のディレクトリを監視します。

$ vagrant rsync-auto
==> default: Watching: /path/to/src/

同期対象のディレクトリに変更があると、自動でrsyncが実行され、同期されます。

$ vagrant rsync-auto
==> default: Watching: /path/to/src/
==> default: Rsyncing folder: /path/to/src/ => /share

ホストで開発して、ゲストで実行するというスタイルなら、常に rsync-auto を実行しておくと良いでしょう。

注意点

ホストからゲストの同期のみ

現在のところ、同期はホストからゲストの一方向のみです。

ゲストからホストへファイルを転送するvagrant rsync --pullというのが、issue で提案されているので、いずれ実装されるかもしれません。

https://github.com/mitchellh/vagrant/issues/3062

rsync 実行でファイルオーナーが変更される

rsync-auto を使っている時に気づいたのですが、rsyncの実行前にゲスト側の同期ディレクトリに対してchown -R vagrant /pathを実行して、ファイルオーナーを変更しています。

同期対象ディレクトリを丸ごとホスト側と同期するなら特に問題無いのですが、ゲストでアプリケーションが実行時に生成するファイル（ログファイル等）をrsync__excludeオプションで同期対象外にしている時に問題が発生します。

例えば、アプリケーションがapp/storage/log/以下にログファイルを出力する場合、このディレクトリを同期対象外とします。

config.vm.synced_folder "src", "/share", type: "rsync", rsync__exclude: [".git/", "app/storage/log/*"]

この時、アプリケーションを実行するとゲストでは、下記のようにアプリケーションの実行ユーザである apache ユーザによってログファイル（laravel.log）が生成されます。

[vagrant@localhost /share]$ ls -la app/storage/log/
drwxrwxrwx. 2 vagrant vagrant     4096  3月 13 05:51 2014 .
drwxrwxrwx. 7 vagrant vagrant     4096  2月 13 07:50 2014 ..
-rw-rw-rw-. 1 vagrant vagrant       13  2月 13 07:50 2014 .gitignore
-rw-r--r--. 1 apache  apache      5394  3月 13 05:51 2014 laravel.log

次にホスト側で vagrant rsyncで同期します。

$ vagrant rsync
==> default: Rsyncing folder: /path/to/src/ => /share

ゲスト側では laravel.log は、同期対象外となっているのでファイルはそのまま残っています。しかし、ファイルオーナーが vagrant に変更されています。

[vagrant@localhost /share]$ ls -la app/storage/log/
drwxrwxrwx. 2 vagrant vagrant     4096  3月 13 05:51 2014 .
drwxrwxrwx. 7 vagrant vagrant     4096  2月 13 07:50 2014 ..
-rw-rw-rw-. 1 vagrant vagrant       13  2月 13 07:50 2014 .gitignore
-rw-r--r--. 1 vagrant apache      5394  3月 13 05:51 2014 laravel.log

この状態でアプリケーションを実行すると、ログファイルへの書き込み権限が無いためにエラーが発生します。

Vagrant のソースを見ると、plugins/guests/linux/cap/rsync.rb で、rsync 前に実行する処理が定義されているのですが、たしかにsudo chown -Rが実行されています。

        def self.rsync_pre(machine, folder_opts)
          username = machine.ssh_info[:username]

          machine.communicate.tap do |comm|
            comm.sudo("mkdir -p '#{folder_opts[:guestpath]}'")
            comm.sudo("chown -R #{username} '#{folder_opts[:guestpath]}'")
          end
        end

おそらく、vagrant rsync を実行する際に、Permission Denied が出ないように、一括でchownしているのだと思うのですが、ここは注意しておく必要があります。

rsync-auto を忘れる

これはケアレスミスなのですが、VirtualBox の shared folder や NFS であれば、自動で同期するので、ホストでコードを変更したのに、ゲストに反映されずに「あれ？」となったことが何度かありました。

vagrant rsync-autoを実行しないと、自動で同期されないので、忘れずに。

さいごに

Rsync Synced Folder を使うことで、shared folder で気になっていた点が解決しそうです。なんといっても、ユニットテストが速くなるのはありがたいですね。

Shin x blog Advent Calendar 2013 の最終日です。

12/1 から毎日書いてきた Shin x blog Advent Calendar 2013 ですが、いよいよ今日が最終日です。

今日は、クリスマスということで、ささやかながらちょっとしたプレゼントを用意してみました:D

VagrantX

GUI で Vagrant が利用できる VagrantX というツールをリリースしました。

http://shin1x1.github.io/vagrantx/

Vagrant は、とても良いツールなのですが、いかんせんターミナル（黒い画面）で操作するものなので、それに慣れていない人にとっては、少し敬遠されている面があります。Vagrantfile を自分で書くような人はターミナルでどんどん使うべきなのですが、用意された Vagrantfile をただ使うだけであれば、vagrant up や vagrant halt など基本的な操作しか行わないので、そのためだけに慣れないターミナルを使うのもどうかなという疑問がありました。

そこで、GUI アプリケーションから、基本的な vagrant コマンドが実行できるよう、このアプリケーションを作りました。

VagrantX は、Mac OS X 向けのアプリケーションで、現在は、10.8 (Mountain Lion)、10.9 (Mavericks) で動作するようになっています。

インストール

VagrantX は、Vagrant を GUI から操作するアプリケーションなので、Vagrant 本体や VirtualBox など Vagrantを通常利用するために必要なアプリケーションは別途インストールする必要があります。

Vagrant も VirtualBox もパッケージで配布されているので、ダウンロードして、インストールするだけです。

• Download Vagrant – Vagrant
• Downloads – Oracle VM VirtualBox

VagrantX は、ZIP ファイルとして GitHub に公開しています。公式サイトにある「.zip」リンクをクリックするとダウンロードがはじまります。

ダウンロードした ZIP ファイルを展開します。VagrantX.app がアプリケーション本体になります。このまま起動して試すこともできますし、必要であれば /Applications フォルダへコピーして下さい。

操作

VagrantX を起動すると下記のような画面が表示されます。

まずは仮想マシンを操作する対象の Vagrantfile を画面右上にある Read ボタンで選択します。選択が完了すると、vagrant status が実行され、現在の仮想マシンの状態が表示されます。

あとは、仮想マシンの起動、停止、破棄などをボタンで実行するだけです。

仮想マシンを起動する際は Up ボタン、停止する際は halt ボタン、破棄する際は destory ボタンをクリックして下さい。それぞれのボタンは、仮想マシンの状態により有効になったり、無効になったりします。（仮想マシンが実行中であれば、Up ボタンは無効など）

現在サポートしている Vagrant コマンドは以下です。

• vagrant up
• vagrant halt
• vagrant destory
• vagrant provision
• vagrant ssh

アンインストール

ダウンロードしてきた VagrantX.app を削除するだけです。

開発の話

VagrantX は、RubyMotion で書いています。RubyMotion といえば、iOS アプリケーションの情報はわりと見つかるのですが、OSX アプリケーションの情報はほとんどなく、結局は、MacRuby の情報や Objective-C の情報を参考にして、開発を進めました。幸い、RubyMotion は、Ruby シンタックスの Objective-C と言っても良いくらい層が薄いので、ずばり RubyMotion ではない情報でも転用しやすいのは良かったです。

アイデアは、夏前頃からあったのですが、開発は、9 月に参加した開発合宿から開始しました。開発合宿は、2 泊 3 日だったのですが、1 日半で、仮想マシンの起動などベースのところは動くところまでいきました。OSX アプリケーションを作るのが初めてだったので、紆余曲折はあったのですが、これまで Windows や Java で GUI アプリケーションを作った経験があり、概念自体は理解していたので、OSX(Cocoa) 固有の問題点を一つづつ潰していきました。

それから隙間時間に序々に改良を進めていき、ようやくリリースすることができました。

と、言えば、聞こえは良いのですが、実は塩漬けになっている期間も長く、このままだと HDD の肥やしになって終わる可能性もあったので、まずは公開してみようと思い、今回リリースしました。（ Chef ゆく年くる年で背中を押されたのもありますね:D ）

基本機能は動いているのですが、まだ不具合や不足機能などがあるので、現在はプレリリースという形にしています。

さいごに

Vagrant は、優れたコマンドラインツールなので、GUI が必要なのか？という疑問も当初ありました。

ただ、Vagrant による開発環境の共有、そしてユーザの広がりを見ると、ターミナルを使わない人にこそ、Vagrant が便利なのではと思うようになりました。

まずは公開してみて、反応を見つつ、今後の開発を進めていきたいと思います。興味がある方は、一度ダウンロードして使ってみて下さい。

http://shin1x1.github.io/vagrantx/

なお不具合や改善点などあれば、GitHub の issue へ投稿をお願いします。

Merry Christmas!

お願い

喫緊の課題として、ロゴデザインがあります。

自分で作ってみたのですが、絶望的に残念な感じなので、もし書いても良いよという奇特な方がいれば、お手伝い頂ければとっても嬉しいです。やってみようかなという方は、GitHub の issue にてコメントをお願いしますm(_ _)m