SSブログ

VSCodeでリモートでPHP Debugをブレークできないのをできるようにした。 [プログラミング]

Visual Studio Codeを使って、リモートでXdebugを使うというなんともうれしい機能があったけど、ブレークポイントで止まらずハマったという話。他のサイトでスクリーンショットを使ったりして手取り足取り教えてくれているのであえてここでは、自分のVirtualBoxにつなぐ環境でこうしたら上手くいったという報告のみで。


ステップ実行できるところまではわりとすぐにいったんだけど、ブレークポイントで止まらない止まらないw。実際ググるとブレークポイントで止まらない系の記事が結構あって、そこを見たけどみんな環境が違うから設定ファイルの書いてあることがかなり違うんですよね。PHPだけじゃなくPythonとかその他の言語でもブレークポイントで止まらないとの話があって、これはVSCodeの共通の問題点なんじゃないかと。


とりあえず環境を書いておきますね。

サーバ:VirtualBox上のCentOS7
webサーバ:Apache
クライアント・ホストOS:Windows10

あとの細かいバージョンやら状況は忘れた。特定のバージョンの記事を書いているつもりはないけど、新しくなったら設定方法とかすぐに変わるからなOSSは。


Xdebugを入れるのはPECLで入れました。仕事だとソースから入れて塩漬けできるようにした方がいいんだけど、面倒なので

sudo pecl install xdebug


で入れました。
peclが入っていないときはyumで入れる。

sudo yum install pecl


なんというか、Ubuntuはわりとsudoでやる文化があるのですが、RedHat系はsuでrootにならないといけないサンプルが多くて、複数行をコマンドをそのまま貼り付けて実行できないんすよね。#マークが行頭にくっついてきて、率直に面倒くさい。Debian系が好きなんだけども、yumがapt並みにはなっているので大体問題ない。


それとよくMacのローカルでMAMPとかでやっているのを見ましたけど、あれはリモートにつないでないので微妙に参考にならなかったりしました。LinuxとMacという違いもあることですし。とはいえ、最大公約数的な設定の重なりは見られたので良かったのかもなと思ったり。

あと先に言ったようにPHPに限らずブレークポイントで止まらないという記事が割とあったので、いろいろな問題だけど基本的な設定で不具合が出ているのかなと感じました。まぁIDEで提供されている機能をいちエディタがやろうとしているのだから無理が来ても仕方がないかも。


Xdebugを入れたので、まずサーバ側(/etc/php.ini)の設定。なんか入れるバージョンによって設定される文字列も違うのかな? なので自分が入れた時のデフォルトの設定は書いておく。ここに一部変更したり、挿入したりしている。

[xDebug]
zend_extension=/usr/lib64/php/modules/xdebug.so
xdebug.remote_enable=1
xdebug.remote_handler="dbgp"
xdebug.remote_host="127.0.0.1"
xdebug.remote_log="/tmp/xdebug.log"
xdebug.remote_port=9000
xdebug.trace_output_dir="/tmp/"


いろいろあるんだけど、恐らくミニマムな設定は元々あった行に、次の行を加えれば良いらしかった。多分、最低下の行を加えないとうんともすんとも言わなかった気がする。
xdebug.remote_autostart=1


ただ、いろいろなところで書かれていた設定がかなり違っていたので、他のものも保険に書いておく。
多分、元々書いてあったけど必要そうな設定の一つは
xdebug.remote_enable=1


それとデフォルトで指定している9000番ポートが使えないことが多いらしいので、VSCodeと同じように変える。たぶんここは予約されていないポートであれば、どちらも同じものに合わせればいいんじゃないかな。
xdebug.remote_port=9001


多分、9000番でも動くんだけど、何かと競合することがあるらしく、エラーが出て動かなくなることがある。OSを再起動してすぐに使い始めると、競合することなく使えるんだけど、そのためにリブートするのもバカらしいので9000番から変えておいた方が賢い選択かもしれない。


/etc/php.d/ に設定ファイルを入れないといけないとか思ってしまうが、/etc/php.ini に設定するのも同じようなので面倒なことはしない。というか、設定が重複してどちらかに要らない設定が残ってしまいがちなのでどちらかに決めて一元化したほうがいいような気がする。





そしてわりと鬼門となるVSCodeの設定ですが、これは特に環境によって違うみたいです。つなぎ先の違いもあるし、VSCodeを入れるOSもWindowsとMacがありますしね。とりあえずPHP DebugとRemote DevelopmentのExtensionを入れて、つなぐところの手順はほかのところで見てもらうとして(手抜きw)、設定ファイルの書き方ですね。

というかSSHでつないでやるところとかは、初回と次回からのやり方が違うし、ある程度試行錯誤でやってもらわないとどうやってやるか結局迷うし。とりあえずコマンドパレットの使い方を慣れないといけない感じです。

https://qiita.com/bitcoinjpnnet/items/dc94c79bd6a69925872d

とりあえずSSHでつないでデバッグするための、launch.jsonの設定を設定します。というか、SSHのおエペレーション以外はほとんどExtensionのインストールと設定ファイルの書き方でなんとかなるレベルではあります。

左側のデバッグボタンを押して、歯車ボタンを押すと、設定のためのlaunch.jsonが出てきます。

vscode.png

具体的な設定は下記のようにしました。

{
  "version": "0.2.0",
  "configurations": [
      {
          "name": Listen for XDebug
          "type": "php",
          "request": "launch",
          "port": 9001,
          "stopOnEntry": true,
          "pathMappings": {
              "${workspaceRoot}" : "${workspaceRoot}"
          }
    }
}


キモとなっているのはportとstopOnEntryとpathMappingsの設定ですね。portはXdebug側と同じにすれば良くて、stopOnEntryはデバッグが始まったら先頭行で止まるようになります。そこまでは普通にできて、ステップ実行などはできます。

でも、ブレークポイントで止まらない。ググってもブレークポイントで止まらない例はたくさんあって、そこまではみんなうまく行くっぽいですね。色々他の設定をしたけど全然びくともしなくて、結局

"pathMappings"を
"${workspaceRoot}" : "${workspaceRoot}"

に設定すれば動くようになりました。正直、細かい事はわからないんですが、ここは実際のパスを設定しないといけないところなので、リモートだとこういう設定にしないといけないみたいです。ここは正しく設定しないとブレークポイントが効かないので注意しましょう。

ステップ実行ができるところまでは簡単に行くんですけど、ブレークポイントの設定はここだけっぽいので環境によって設定しないといけないみたいです。Webにある多くの環境がリモートじゃなく、ローカルであったりすることが多いので、そこはきちんと読み替えないとダメみたいです。とりあえず、SSHで他のところに繋ぐ場合はこの設定を試してみてください。少なくともデフォルトの状態では動きません。


そんなこんなでブレークポイントで止まらないところだけで困っている方は、pathMappingsをいじってみてください。他のところは他の人がやり倒しているので、ここに書いてあることをやれば大体ミニマムな設定でできていると思いますよ。まぁ無駄なことが書いてあっても大体は無害なので大丈夫なはず。

他の言語から入ってきて、PHPはステップ実行もブレークも張れないと残念に思っていましたが、やろうと思えばやれることはあるんですね。それもタダでできるのだから自己で勉強する点においては問題がない。

タグ:PHP
コメント(1) 
共通テーマ:パソコン・インターネット

Twitterまとめ投稿 2020/01/24 [Twitter]


コメント(0) 

Youtubeが動画・音楽ダウンロード不可になったっぽい。 [web]

Youtubeからは貴重な音源とかがあるので、Firefoxのアドオンとかで音楽を落としていた。mp4の動画を落としていた時があったんだけど、結局音楽としてしか聴いていないことも多かったので、AACを落としてきてMacでMP4コンテナにフォーマットを変えてiTunesで聴いていた。

つい先日、どの音楽を落とそうとしてもツールが動かなくなっていた。それまでもYoutubeの改変で使えなくなっていたりはしたんだけど、そこまで問題が出ることはなくツールの方も追いついていた。

そしてそのうち、商業的にやっているビデオが落とせなくなっていた。まぁ普通は落とせないようにしちゃうよなと思うんですが、個人的に上げているものは今まで通り落とせていました。今回は全体に及ぶようで、動画も音楽だけも落とせなくなっていた。なんてこったい。

YouTube Video and Audio Downloader (Dev Edt.)というアドインも
Cannot detect url_encoded_fmt_stream_map or adaptive_fmts

と出ていて、システムの構造的に大改変があった模様。対応できればそれを待たねばなるまい。YoutubeだけならJavaScriptで相当面倒なことをやっていても、暗号化でもされない限りは対応できそうだけどね。


他のサイトでもWebブラウザの開発ツールで、mp4ファイルが落とせたり落とせなかったりしていたので、そこは技術的に取れなくしたりはできるのだろうなとは思っていた。しかし、今までYoutubeは大丈夫だと思っていたのだけれど、これではかなり厳しい。まぁ公共インフラ的な位置を占めたいなら仕方のないことなのかもしれないですがね。

これだとちょっとしたコミュニティ内で動画を配ろうとすると、Youtubeで配るという方法が使えなくなったってことですね。ただ、動画はでかいのでクラウドでファイル共有をかけようとするのは厳しい気はしますね。まぁGoogleDriveは容量も大きいので、そこからURLを引いてもらえばいいんだろうけど、不特定多数に向けてっていうのはもう終わりになってしまいそうですね。

mp4の動画だけでも落とせれば、そこからAACのデータを抜くことはできるだろうから、新しいFirefoxのツールが出てこないかなぁ。それができなくなったらFirefoxのいいところが半分くらいなくなってしまう。

コメント(1) 
共通テーマ:パソコン・インターネット

Twitterまとめ投稿 2020/01/23 [Twitter]


コメント(0) 

Twitterまとめ投稿 2020/01/22 [Twitter]


コメント(0) 

Docker for MacでなんでUbuntuが動くのか? [MacOSX]

以前にDocker for Macを入れた際に、Ubuntuが動くのはなぜかと疑問に思っていました。chrootの発展形がコンテナ仮想化とするなら、Macのコンテナ上でLinuxが動くのは妙な話なんじゃないかと。

https://qiita.com/kirikunix/items/33414240b4cacee362da

ここではLinux同士を使っている場合に、ABIという仕組みがあるからある程度は大丈夫なんだよ、という説明でした。しかし、それではMacの説明がつかない。


下のコメント欄にその言及がありました。

https://docs.docker.com/docker-for-mac/docker-toolbox/#the-docker-for-mac-environment HyperKit という仮想化ツールでdockerホストとなるVMを作り、 そいつと /var/run/docker.sock を通してやり取りをする、という仕組みのようです。 macOSにABIを被せているわけではなく、Linuxを別個に立てているのですね


これだったらコンテナ仮想化じゃなくて、ハイパーバイザー型と大して違わないやん。ただchroot的なディレクトリの利用はしているかもしれないけど。でも、Mac上のUbuntuは60GBの大きさしかなかった気がするなぁ。Dockerはコンテナ仮想化という認識は変えないといけないかもしれない。


ここを直接読む。
https://docs.docker.com/docker-for-mac/docker-toolbox/#the-docker-for-mac-environment
うわ。最初の最初にすごいこと書いてあったw。

It also installs VirtualBox.


VirtualBox入っとるやんw。というかDockerを上にかぶせる意味あるん?
あ~Docker Toolboxの方なのか。Docker Desktopの前にあったやつみたい。

Docker Desktop uses HyperKit instead of Virtual Box. Hyperkit is a lightweight macOS virtualization solution built on top of Hypervisor.framework in macOS 10.10 Yosemite and higher.


やっぱハイパーバイザー使っとるわ。他のDockerはコンテナ仮想化かもしれないけど、for Macは純粋なコンテナ仮想化じゃないな。はじめはVirtualBoxを使う気になっていたけれど、DockerがHypervisorであれば使う意味があまりないんじゃないかと思ってきた。というか、macのコンテナを作ろうとしていたから、Linuxを入れるのを前提にしているんじゃどっち使ってもあんまり変わんないかもな。というか、慣れているVirtualBoxの方がいいのかも。

というかMacで開発しようと思ったら、コンテナを使えないとしたら既存の環境を汚すしかないのかとちょっと落胆。それが嫌だからコンテナを使おうと思っていたのに、Dockerのバカぁ。って、DockerでMacのコンテナ使えるかどうか調べてないですが…。

コメント(0) 
共通テーマ:パソコン・インターネット

やっとmacOS Catalinaにした。 [MacOSX]

macOS 10.15.2になってからmacOSをアップデートしました。二回もマイナーアップデートしたんだから、あらかた問題は解決されているはず。というか、ずっと前の状態を保つ意味もあまりないので、TimeMachineでバックアップを取って入れてみました。

始めに15分で終わると出ていたんだけど、最終的に終わったのがちょうど一時間後くらいでした。ダウンロードにも時間がかかっているので、一時間強というところでしょうか。結構時間がかかる。最近のアップデートはSSDを使っているので、割と時間がかからなかった印象がありますが、やっぱりOSのアップグレードはそこそこ時間がかかる。まぁ使っているソフトウェアの環境ってのは人によって違いますしね。

LinuxだとかだとOSをクリーンインストールして入れ直しちゃうところですよね。コンテナとかの仮想化でもOSの構築を自動化でやっている場合も多いみたいだし。だけどクライアントOSはそういうわけにはいかないよね。色々データがシステムの中に散らばっちゃってるし。




それとは別に今、ちょっとDocker for Macを入れようかどうか気にしている。VirtualBoxでUbuntuを入れようかとも思ったんだけど、せっかくMacを使っているのだから、そのまま使った方がパフォーマンスも下がらないだろうなと。というか、わりとコンテナじゃない仮想化ってHDDの書き込みにパワーを使ったりしてますしね。それとHDDの容量を最初から規定しないといけないことも多いし。

そういう意味からしてコンテナ仮想化は他人丼的な使い方をしなければ、仮想化としてお手軽かと思うね。ハイパーバイザー型の仮想化も悪いとは思わないけど、完全に本番動作を仮定していない限りは別にmacOSでいいじゃないかと思う。曲がりなりにもUNIXなんだしね。

https://docs.docker.com/docker-for-mac/install/

Docker Desktopって書いてあるけど、Desktopって書いてあるのが気になる。特にGUIは必要ないんだけどなぁ。どうせコンテナの操作はCUIでやるんだし、そこいらの操作はVirtualBoxっぽくGUIでいいと思うんだけど、見た感じそうはなっていない。まぁ仮想環境のセッティングがホストOSに依存する部分が大きいので、そこまで設定に苦労しないからかもしれないけど、GUIはGUIでCUIはCUIで分けたい気もする。

$ docker run hello-world
Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
1b930d010525: Pull complete 
Digest: sha256:9572f7cdcee8591948c2963463447a53466950b3fc15a247fcad1917ca215a2f
Status: Downloaded newer image for hello-world:latest

Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
 1. The Docker client contacted the Docker daemon.
 2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
    (amd64)
 3. The Docker daemon created a new container from that image which runs the
    executable that produces the output you are currently reading.
 4. The Docker daemon streamed that output to the Docker client, which sent it
    to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
 $ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker ID:
 https://hub.docker.com/

For more examples and ideas, visit:
 https://docs.docker.com/get-started/


ん?ubuntuとか書いてあるけど、macOSでubuntuのコンテナを動かすってどういうことだ?
ただ単にどのOSでもみんな同じこと書かれてんのかな? そもそもhello-worldってのは環境ってことなのかな?

とりあえず、docker run -it ubuntu bash やってみよ。
uname -a で見たら
# uname -a
Linux b24ee05811f8 4.9.184-linuxkit #1 SMP Tue Jul 2 22:58:16 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux


macじゃなくLinuxが走っていることはわかる。Ununtuかどうかはわからんけど…。というか、コンテナ仮想化はこういうことできるの? なんかコンテナというプロダクトとしての趣向が違わない? コンテナ仮想化がchrootの発展系として考えるなら、違うOSのコンテナなんて使えないはずなんだけど…。

なんか色々気になるけど、Ubuntuが動くということはわかったわ。にしてもコンテナっていつもrootで始めに入るんだけど、普通のLiunxを使うものとしては気持ち悪すぎる。結局、普通のユーザー作るんやろし。まぁそのうち細かくやっていこうと思います。とりあえずはここまで。




Catalinaを入れてまず気づいたのが、Dockに何か無理矢理入れられている。PodcastとAppleTVが割り込んでいる。どっちも使わなそうだけど一応見てみよう。PodcastとかiTunesとかに入れられていて懐かしいけど、しばらく使っていなかったな。ただコンテンツが貧弱すぎて聞く気にならない。Youtube見てた方がいいなという話になっちゃいそうだな。

TVってアプリケーションは、映画とかの映像をレンタルか買い切りで見ることができるようだ。他の入ったら見放題のサービスよりも割高感はある。正直、これに飛びつく人はあまりいないだろう。とりあえず、TVもPodcastもDockから除いた。いらん、こんなもん。


iPadもあるのでSidecarができそうだけど、あんまり好評とは言えないみたいだしなぁ。後でやるけど、今はまだいいや。Catalina唯一の新機能と言われていたが、本当に他に何かないのかなぁ。

コメント(0) 
共通テーマ:パソコン・インターネット

Twitterまとめ投稿 2020/01/21 [Twitter]


コメント(0) 

Laravelは何でできているのか?調べようとした。 [プログラミング]

PHPのフレームワークとして超有名なLaravelですが、Laravel自体はPHPで出来てんのかとちょっと不審に思っていました。そもそもコマンドラインで打つようなツールをPHPで作れるのかとか、ファイルの生成とか正直、言語的に得意としているところなのかなと思ったりしていました。

Ruby on RailsやDjangoで自分の言語自信を生成するくらいは普通のプログラミング言語なので、RubyでRubyスクリプトを作るとか、PythonでPythonスクリプトを作るとかは普通に想像できるのですが、PHPは基本的にHTMLを動的に生成するスクリプトでしたので、PHPがPHPスクリプトを作るのってのがすんなり想像できなかったのもあります。


Laravelが何でできているのかというところだけども、そもそもそれを入れるComposerが何でできているのかを調べたほうが早い気がして、そちらを調べてみました。Laravelは本当に触りしか使っていないので、というか、Laravelを入れる段になって、Composerを入れるところでムムムとなったので、そこで調べてみたのでした。

Composerの実体はcomposer.pharというファイルなのだけれども、それ自体はPHPファイルとかリソースファイルを含んだアーカイブファイルらしい。圧縮もしていないみたいなのでtarみたいなもの?

https://qiita.com/rana_kualu/items/d868604a1f54c2f93a7c
https://laboradian.com/php-composer/

実際、composer.pherのファイルの先頭部分を見てみると#!があって、PHPのスクリプトとはいえ結局phpで実行されているだけでした。まぁLinuxだからそうだよなぁ…。


$ head /usr/local/bin/composer
#!/usr/bin/env php
<?php
/*
 * This file is part of Composer.
 *
 * (c) Nils Adermann 
 *     Jordi Boggiano 
 *
 * For the full copyright and license information, please view
 * the license that is located at the bottom of this file.



実行ファイルだから、ほかの言語とかで書かれているのかなと思っていましたが、そこはそれでPHPがPHPを作り出すという基本は守っているみたいです。というかPHPがshebangで実行されているというのはあまり気持ちの良いものではないなと思ってしまうのは私だけでしょうか。

とにかく同様にしてLaravelも動作しているかもしれません。というか、元のパッケージマネージャがPHPなんだから、LaravelもPHPでできているんじゃないでしょうかね。Laravelが生成するスクリプトはPHPですが、ここまで来てわざわざほかの言語でやる必要もないでしょうし。まだ調べてないけどlaravelコマンドもshebang付きのpharファイルなんじゃないかなと思っています。

調べてないのはlaravelが一つのコマンドだけじゃないからです。あと仕事場に環境はあるけど、手元に環境がないからですね。そのうち作るけど、作るの面倒くさい。laravelコマンドは名前からそうですけど、artisanとか、生成するcreate-projectに関しては作れるのはlaravelだけじゃないみたいですし。というか、正直、一つのコマンドにまとめて欲しい気はします。

タグ:PHP
コメント(0) 
共通テーマ:パソコン・インターネット

Twitterまとめ投稿 2020/01/20 [Twitter]


コメント(0)