Go to Qiita Advent Calendar 2024 Top
LoginSignup
75
84

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

@takudo

【PHP】リモートマシンのデバッグを、「複数人で」やる【Xdebug×DBGpProxy】

Last updated at Posted at 2014-07-05

参考

やむにやまれない理由で、ローカル環境またはローカルの仮想マシン内に自分だけの開発環境を構築できない場合があります。

でもリモートデバッグはやりたい...ヨダレが出るほどに...var_dumpとか書きたくないし！

#想定環境

今回の想定は、↓の図のような感じで開発してるものとします。

legacy-dev-env.png

ポイントは、

  • 開発者のローカル端末でソースコード編集が行われず、開発サーバ内のソースコードをみんなで編集している
  • 開発サーバが、開発者ローカル端末と 同サブネットに存在しない。

##開発サーバが同サブネットに存在する場合は...

同サブネットに存在する場合は、そもそもxdebugの設定で解決する（はず）と思います。

xdebug.remote_connect_backの設定がそれです。
remote_connect_backは、$_SERVER['REMOTE_ADDR']によってデバッグ待機中のマシンを確認します。
同サブネット内の場合はこれでOKなのですが、ルータを挟んだりすると$_SERVER['REMOTE_ADDR']はルータのIPアドレスになってしまうので、開発者端末のIPアドレスがわからず、開発サーバから開発者端末への接続ができないのです。

#実験環境

AWS上のPHPサーバを、自宅からインターネット越しにデバッグします。

ex-env.png

##概要

xdebugが有効になっている場合、PHPの実行時には、xdebug.remote_hostで設定したIPのポート9000（デフォルト。xdebug.remote_portの設定を変更することで変更可能）へ接続してきます。

ですので、開発サーバが自身のローカルマシンである場合はxdebug.remote_hostにlocalhostを設定し、開発サーバとローカルマシンが１：１の関係である場合は、xdebug.remote_hostにローカルマシンのIPアドレスを指定します。

しかし開発サーバに対し複数マシンがあり、かつ開発サーバとの間にルータなどを介す場合、開発サーバが接続しに行くremote_hostが見つからないという事態になります。このような場合の解決策です。

まず、xdebug.remote_hostの設定はlocalhost、xdebug.remote_portの設定は9000にしておきます。
DBGpProxyは外部からの接続をポート9001ポートで待ち構えておき、ローカルホストのポート9000への接続をプロキシします。

端末Aでは、「cookieのXDEBUG_SESSIONがAcomputerだったら、自身への接続のポートは9002でお願いします」というふうにDBGpProxyへ登録し、さらにルータ側ではDBGpProxyから来たポート9002への接続を、端末Aのポート9002へフォワーディングすることで、道通する、という流れです。

端末Bの場合は、XDEBUG_SESSIONが端末B特有のものであることと、利用ポートが9003であることだけで、考え方は端末Aと同じです。

##開発サーバのセッティング

開発サーバ上でプロキシサーバを動かします。

AWS上の開発サーバにはGIPを付与し、自宅のGIPからのInBoundのTCP 9001番ポート（プロキシがListenするポート）を開けます。

PHPなど

以下、導入します。

$ sudo yum update #最初のyum update
$ sudo yum install php httpd php-pecl-xdebug git

xdebugの設定をいじります。

/etc/php.d/xdebug.ini

;下記記述を足します。
xdebug.remote_enable=1
xdebug.remote_autostart=1

リモートデバッグ対象のPHPのサンプルプロジェクトをgit cloneしてきます。

$ chmod 755 /home/ec2-user #きっと実行権限がないと思うので。
$ cd ~
$ git clone https://takudo@bitbucket.org/takudo/php-remote-dbg-test.git #ただのPHPスクリプト

中身はこんなのです。

index.php

<?php

echo 'step1';

$array = array(
    1,
    2,
    3,
    4,
    5
);


foreach($array as $partial) {
    echo $partial;
}

echo 'step2';

echo 'step3';

apacheのドキュメントルート変更しておきます。

/etc/httpd/conf/httpd.conf
DocumentRoot "/home/ec2-user/php-remote-dbg-test/" #変更

apacheを起動して、ブラウザで画面が表示されるか確認しましょう。

php-remote-dbg-test.jpg

プロキシサーバ

PHPサーバに、プロキシサーバを導入します。

pythonのdbgpモジュールが必要なので、いろいろ入れます。
このへんを参考にしつつ、まずはsetuptoolsを

$ mkdir ~/src
$ cd ~/src
$ wget https://bootstrap.pypa.io/ez_setup.py
$ sudo python ez_setup.py
$ sudo easy_install pip
$ sudo pip install dbgp

プロキシサーバの最新のパッケージは↓を参考にしてください。
http://code.activestate.com/komodo/remotedebugging/


$ cd ~/src
$ wget http://downloads.activestate.com/Komodo/releases/8.5.3/remotedebugging/Komodo-PythonRemoteDebugging-8.5.3-83298-linux-x86_64.tar.gz
$ tar -xvzf Komodo-PythonRemoteDebugging-8.5.3-83298-linux-x86_64.tar.gz
$ cd Komodo-PythonRemoteDebugging-8.5.3-83298-linux-x86_64
$

プロキシサーバを起動します。

$ ./pydbgpproxy -i 0.0.0.0:9001 -d 127.0.0.1:9000
INFO: dbgp.proxy: starting proxy listeners.  appid: 1632
INFO: dbgp.proxy:     dbgp listener on 127.0.0.1:9000
INFO: dbgp.proxy:     IDE listener on  0.0.0.0:9001

##ローカル環境・端末セッティング

ローカルルータ

AWSの開発サーバ（プロキシサーバ）から、ローカル（自宅）環境への接続が行われるので、アクセス制限を解除しないといけません。
また、ローカルのルータにポートフォワーディングを設定することで、プロキシサーバからの接続を、ローカル端末A・端末Bに振り分けます。

ルータを何使っているかで設定の詳細はいろいろだと思うのですが、
設定しなければならないのは、下記です。

  • 開発サーバのGIP（インターネット）からのローカルルータへの接続を許可する
  • ローカルルータへの外部からの接続をポートフォワーディングする。
    • 例：
      • ローカルルータGIP:9002への接続を、端末AのローカルIP:9002へ転送
      • ローカルルータGIP:9003への接続を、端末BのローカルIP:9003へ転送

IDE(IntelliJの場合)

※ローカル環境でも、開発サーバと共通のソースコードをgit cloneしておき、IntelliJでプロジェクトとして開いておいて下さい。

まずは端末Aを設定します（Bでも同様の手順で設定して下さい）

Tools > DBGp Proxy > Configuration を開いて、下記のように入力します。

DBGp_Proxy.jpg

つぎに、端末Aで待ち受けるポートの設定です。
Preference > PHP > Debug で、下記のように入力して保存します。

Preferences.jpg

DBGpProxyに、待ち受けるポートとIDE Keyの登録を行います。
Tools > DBGp Proxy > Register IDE で、↓のように表示されればOKです。

index_php_-php-remote-dbg-test-php-remote-dbg-test-__Development_PHP_php-remote-dbg-test-_IntelliJ_IDEA__Cardea__IU-135_1019.jpg

DBGpProxyが開発サーバで立ち上がっていなかったり、端末Aから開発サーバ:9001への接続が許可されていなければ、接続失敗します。

また、DBGpProxyのコンソールでは、下記のように表示されるはずです。

INFO: dbgp.proxy: Server:onConnect ('ローカルルータのGIP', ***) [proxyinit -p 9002 -k Acomputer -m 1]

端末Bでも同様の手順で環境設定をして下さい。

（すみません、EclipseとかNetbeansとかでは試してないのですが、Eclipseならここ、Netbeansならこことかを参考にするといいかもしれません。が、実際検証はしてないので、なんとも言えません）

これで準備完了！

#デバッグしてみる

##ブレークポイント

ブレークポイントを設定してみてください。

index_php.jpg

##デバッガ

次に、デバッガ起動します。

index_php.jpg

↓のように緑になります。

index_php.jpg

cookie(XDEBUG_SESSION)の設定

Preference > PHP > Debug の bookmarkletsなんちゃらというリンクをクリックします

Preferences.jpg

クリックすると、デフォルトブラウザでページが開くので、ブックマークレット登録を行います。

Xdebug___Zend_Debugger_bookmarklets_generator_for_PhpStorm.jpg

このブックマークレットは単に、「現在開いているドメインのトップパスに、XDEBUG_SESSIONのクッキーを登録するJavaScript」というだけです。

ブックマークレットを作成したら、端末Aのブラウザで、開発サーバに一度アクセスしてみます。
アクセスしたらブックマークレットをクリックして、cookie登録をします。
こんな感じでcookie登録されてればOKです。

chrome_devtool.jpg

##ブレークポイントで止めてみる

では、もう一度端末Aで画面をリロードしてみましょう。
出来ましたか？

index_php.jpg

端末Aと端末Bが混同されてないか確認

端末Bでも同様にセットアップしておき、端末Bでも動作確認ができたら、
端末Aでのアクセスによって、端末Bで設定しているブレークポイントで止まったりしないことを確認しましょう。
またその逆も確認しましょう。

#所感

やりたい場面はそこそことあるのかなと思うのに、設定の大変さときたら。
やはり皆さんローカルマシン内で開発していることが多いでしょうから、あまり複数人デバッグの情報、それもDBGpProxyを利用した場合の情報がなかなか出てこず苦労しました。

今回の実験はインターネット越しに行いましたが、LAN内でルータを介す場合の場合でも応用がきくと思います。

ただ、社内の環境が開発サーバまでにルータを介すような場合って、そのルータのフォワーディング設定をしてもらえるかどうか、それが一番難易度が高いところかなと思いました。

以上。

75
84
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
75
84

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?