在我的 GitHub 页面里,Bangumi Spider 这个基于 scrapy 的爬虫恐怕是维护时间最久的东西了。从 2015 年为了写 Chi (Bangumi 的好友同步率——推荐系统)开始,这个东西就一直维护到今天。顾名思义,它的主要作用就是爬取所有的用户、所有的条目和用户标记条目的记录。今天,Bangumi Spider 的主要作用是服务于 https://ranking.ikely.me,每月爬取所有标记记录并计算动画排名。动画排名应该每个月第 1 + n 天会更新,n 取决于爬虫爬取速度。

Overall technical background of ranking.ikely.me

在此图中,左边是理想中的爬虫部分。定时任务首先每月向爬虫服务器 scrapyd 发送爬取请求,爬取后的数据以文本形式放在 Azure Blob 里。然而这时候还是 raw data,需要一个 postprocessing job 对爬取后的数据进行处理形成最后可以直接被 ranking.ikely.me serve 的数据。看上去很简单,是不是?然而在多年的技术发展中,该项目背负了沉重的技术债。

首先,在很久以前,这套东西为了能运行,爬虫服务和应用服务是在同一台虚拟机上的。第一版应用服务用的还是 flask + jinja 一套 SSR。postprocessing job 在 2016 年的时候还是我线下手动生成的,于是在之后的三年里 ranking.ikely.me 一直都没有更新是因为我忘记了线下生成数据的格式。终于在 2018 年,这一套应用用 dotnet core 重写了一遍,并封装成 docker image。scrapyd 被移出虚拟机封装成 docker image。于是该虚拟机就成了 ranking web application docker container instance + reverse proxy。同时为了能自动化生成排名数据,postprocessing job 被移到了该虚拟机里面。postprocessing job 运行时所需要的内存巨大,在去年大约要 10 GB 内存(在今年涨到了 14 GB)。crontab job 也被写在了该虚拟机里面。这一套系统运行了六个月,然后又不能自动更新排名了,因为 Bangumi 页面样式更新使得某些数据无法爬取。这里面存在的问题有:

  1. Azure 虚拟机高配置而长时间空转,浪费 budget;
  2. scrapyd container instance 在爬取数据过后还会重启,丢失已部署的爬虫,经调查有不法人士黑入该 instance;
  3. ranking web application 并非 continuously deployed,需要手动更新;

在理想的状况下,每一个部件应该自动化运行并充分利用现有 budget。而 GitHub Actions 的出现,为实现这种理想提供了便利(当然,需要指出的是,GitHub Actions 并未唯一实现这种自动化的手段)。在图的每一个被标记的部分都应该有自动化:

  1. crontab job 自动化
  2. 自动按需启动 scrapyd server 并在运行结束关闭
  3. 自动按需启动 postprocessing job 并在运行结束关闭
  4. 随着爬虫的更新,postprocessing job 也应该更新

即使不能做到 100% 自动化,能大幅降低服务空置率也是对宝贵 budget 的一种有效利用。此外,我希望将 ranking web application 移出虚拟机,用 Azure web service (Linux) + container 的技术去 serve,以降低成本。

GitHub Actions

GitHub Actions ,据官方描述,能够极大简化你的 CI/CD 流程。但实际上它能做的事情不仅局限于 CI/CD。在这篇文章中,我将介绍 Bangumi Spider 新添加的 GitHub Actions 如何实现自动化部署和排名自动化更新。

在 Bangumi Spider 里面,有一个叫做 scrapyd 的 folder 存放了 Bangumi Spider 专属 scrapyd dockerfile,其和普通的 scrapyd 不同之处在于使用 nginx 在访问前进行一次验证。在这个 workflow 里面,GitHub Actions 先 build docker image,再 publish 到 Docker Hub,最后更新 Azure container image。

正如上文所述,我不希望 scrapyd 在不执行爬虫任务的时候运行,所以我在最后关闭了它。在另一个定时 workflow 里面,我启动相应的 Azure container service,在线部署爬虫并运行爬取用户记录番组的数据和番组数据的 jobs。

另一个叫 postprocess 的 folder 存放了对已爬取进行后处理的 Dockerfile。其执行任务净是一堆脚本文件,以单机有限资源处理百万行数据。这是一个有艺术性的话题,但是我不想讲。针对这个 Docker image 的构建 workflow 被描述在这个文件里。相应地,我在另一个 workflow 定时启动相应的 Azure container service,运行完成就结束。

需要指出的是,在这里我发现了 GitHub Actions 是可以支持每次 commit 所触动的文件而出发 Actions 的——倒不如说我发现 Travis CI 不支持这项功能。这样我每次提交的时候我就可以通过检查修改的文件是否涉及 scrapyd 和 postprocess 两个 folder 而 conditionally update docker images。就这项功能而言,我觉得 Travis CI 已经完全落伍了。

Azure Web App Service

Azure 提供 App Service 的服务,并附带一个 Azure 的证书,而且也可以绑定到自己的域名。关键是这个服务的价格比自己 host 虚拟机要便宜(如果用 Basic plan 的话)。App Service 最好的地方在于支持 docker image 和 docker-composed images,于是我把 dotnet core 的服务也使用 docker image 部署在其上。https://ranking.ikely.me 使用 CloudFlare 做 CDN 并由其提供证书,关于如何把 CloudFlare 的证书导入到 Azure App Service 的操作参见这篇文章

Achievements

通过这么一番操作,我们已经:

  • 100% 实现了全自动无人干预更新排名(除非 Sai 老板再次更新 Bangumi 页面导致爬虫需要连带更改)
  • Conditionally update docker image
  • 大幅削减预算:从每月七十多刀的虚拟机削减到十四刀左右。
  • 增强了 scrapyd 的安全性。

留言

2020-01-03