Scrapydというものがあるらしい
日本語の記事としてはググってみると”クローラーをデーモンとして動かす ― Scrapyd”などの記事が見つかった。
Scrapyをデーモンとして動かせるということだったので、これは”我が家のZaimデータを描画する基盤を作った”の記事の、airflowを使ったプラットフォームを、scrapy化してもっと軽い形で実現できるかもしれないと期待して試してみた。
何はともあれScrapydが動くdockerコンテナ作成
"scrapyd docker"とかでググってみると、幾つかscrapydのdockerコンテナが見つかる。
基本的に、pythonが入っていれば$ pip install scrapydでインストール可能のようなので、1からdockerイメージを作ってもよかったけど、今回はalpine linuxベースで作られたharrisbaird/scrapydのdockerイメージをベースに使わせてもらうことにした。
ここで、Scrapyを使って人工衛星の軌道情報をスクレイピングしてみたの記事で作ったspiderを動かすために、以下のようなdocker-compose用ファイル群を収めたgithubリポジトリを作成した。
Scrapydコンテナの設定
上記githubリポジトリのscrapyd.confにて、設定を行っているものは基本的には、公式ドキュメントにある設定を踏襲している。
異なる点は、bind_address = 0.0.0.0としている点のみ。これは、このScrapydへのアクセスを全てのネットワークから許可する設定になっている。そのため、インターネット上でアクセスできる場所などでコンテナを立ち上げると、あらゆるネットワークからアクセスできてしまうので、注意が必要。
上記の設定はdockerコンテナでport forwardしていると、bind_address = 127.0.0.1の設定では、ホストマシンのlocalhostからアクセスしていても接続できなかったため上記のように修正した。
Scrapydコンテナの立ち上げ
上記のリポジトリにもあるように
$ git clone https://github.com/inTheRye/docker-scrapyd.git
$ cd docker-scrapyd
$ docker-compose up -d
でコンテナを立ち上げる。
Scrapydコンテナへのアクセス
でアクセスすると以下のようなtop画面が表示される。
Scrapydへ自作Spiderの登録
公式ドキュメントにあるように、jsonのendpointにhttpアクセスするか、scrapyd-clientをインストールして、spiderをscrapyd上にデプロイするかどちらかの方法があるようだった。
（scrapyd-clientもおそらく上記、httpリクエストによるアクセスをラップしているだけと思われるがこちらの方が楽）
$ pip install git+https://github.com/scrapy/scrapyd-client
でscraped-clientをインストールする。
Scrapyを使って人工衛星の軌道情報をスクレイピングしてみたの記事にある、scrapy-sample-baseball/space_objectのディレクトリ直下にあるscrapy.cfgのdeploy先のurlのコメントアウトを解除する。
[deploy]
url = http://192.168.1.2:6800/
scrapy-sample-baseball/space_objectのディレクトリ直下で、以下のコマンドを実行。
$ scrapyd-deploy
これで、scrapydにspiderが登録できる。
登録されたSpiderの実行
scrapy-sample-baseball/space_objectのディレクトリ直下で、以下のコマンドを実行。
$ scrapyd-client schedule -p space_object tle
top画面から、"Jobs"のリンクをクリックすると
のような形でSpiderのスクレイピングジョブが走っていることが確認できる。
Spider実行時の注意事項
今回、scrapydでの実行にあたり、spiderクラスのコンストラクタを以下のような多引数を受け取れるようなものに修正した。
def __init__(self, *args, **kwargs):
Error with Spider arguments sent using Scrapydにあるように、scrapydでの実行では_jobのキーワード引数をspiderに送っているようで、上記のようにしておかないとエラーになる。
Scrapydを試してみて
良さそうな点
貧弱な計算リソースしか確保できない我が家では悪くないなと思った。ただし、scheduleと言っていながら、実際のスケジューリング機能などは無いようなので、スケジューリング自体はcronなどで自前で設定する必要がある。
ジョブ実行のログ取得は自前で考えるよりも楽ができる。
また、我が家ではあんまり関係無いが、複数のspiderを実行する時などはある程度Scrapydが、並列実行含めてよしなに実行してくれそうなので、その点も良さそうだ。（airflow[celery]での並列実行ほどのものは求めていないのでこの程度の軽さで良い）
なんとなく気持ち悪い点
良さそうな点はあるのだが、一番気持ち悪いのは上記を実行しようとするとScrapydのコンテナとScrapyプロジェクトを収めたコンテナを用意して、httpインタフェースを介してjob実行するために、Scrapyプロジェクトのコンテナでcronで定期スケジュールする必要がある。
これだと、双方のコンテナでほとんど同じpythonのモジュールをimportしておかなければならず役割分担としては重複が多く微妙になる。ではscrapydコンテナとscrapyプロジェクトのコンテナをまとめてしまってはどうかと言うと、同じコンテナ内でジョブ実行のためにhttpインタフェースを介して通信するというのはなんとなく気持ち悪いなと思ってしまった。