これまでスクレイピングのため、VPS上で selenium + headless chrome をDockerコンテナ内で動かしていたが、色々と課題があった。
今回、無駄に忌避していた headfullなブラウザを使ってみたら、思ったより不便なかったのでまとめておく。
- headless なのはいいが、開発時には画面が見えない状態での試行錯誤が必要であり、ログインが必要なサイトだと大変お行儀が悪い。
- chrome のバージョンと、selenium などの driver類のバージョンが合わないと簡単にエラーになる。
2.に関してはDockerfileも悪いのかも。
|
|
こんな感じで、google-chrome-stable を aptパッケージが取ってきてきている一方で、pythonモジュールは requirements.txt に記載したものを取ってきている。
そしてとうとう普段アクセスしているサイトでJavascriptが動かなくなってしまった。headlessだと動かないのかもしれない。
|
|
こんな感じでchrome driverに引数を渡してもどうしてもJavascriptが動かない。こりゃだめだ。
しょうがないので、色々とDockerベースで調べてみると、 https://github.com/SeleniumHQ/docker-selenium で Standalone版があるらしい。 画面ありで動くらしいのだが、VPS上で動かすし、「はて・・・」となっていたが、どうやらこういう風に使えば良いっぽい。
- selenium/standalone-chrome を起動すると、Chromeがサーバとして立ち上がる
- :4444 で接続することで、Selenium から操作できる。
python だとこうすると、headless chromeと同様に起動することができる
|
|
で、:9999 にブラウザでアクセスすると、noVNC が起動してブラウザが動かされている様子が確認できる。
だから
- :9999 でブラウザアクセスしながら、意図する挙動がするように手元PCでデバッグする。
- そのまま動作させるVPSなどのホストに乗せればOK
問題としては、見もしない画面が展開されているところだけど、そこらへんはリソースをじゃぶじゃぶすれば楽をできる、ということで解決したことにする。
結果として、standalone-chrome を使うことで、
- 動作確認のデバッグが楽になる
- Chrome部分はパッケージングされているので、バージョン不整合が起きにくい
- headfull相当として動くので、実ブラウザで見たときと同じ挙動をしてくれることが期待できる
が出来た。