最近有个功能的某些数据特别适合图数据库, 一开始使用的是 MySQL 数据库, 但是在业务开发的过程中, 愈发觉得图数据库才是它的最终归宿, 于是先期先用 MySQL 做了一版, 顺利上线, 然后第二步准备迁移到图数据库.
之前小组内部有人用过 Neo4j, 用的还挺不错, 准备使用, 但是后来听说这个对于大企业要收费, 并且公司有个部门已经做好了一个基于 Janusgraph 的数据库, 统一管理, 保证稳定运行, 所以最后放弃 Neo4j, 转而准备上公司已经搭好并且有部门维护的这个图数据库. 但是一番打听下来, 要使用这个数据库, 有个复杂的流程, 关键的关键是: 如果你改任何一个图的schema(顶点, 边及其任何属性, 都要提ticket, 然后走review流程. 对于我们这种一开始还不确定到底有多少类型的顶点, 多少边, 时不时随时可以加边的实验性的项目, 这种流程简直就是灾难.
所以, 最可行的方案是: 我们先自己在开发, 测试, 生产环境搭一套基于 Janusgraph 的图数据库, 等我们的 schema 都稳定之后, 再考虑迁移到有稳定保障的, 有部门支持的图数据库.
首先, 在开发环境基于 Janusgraph 的 docker image 做了一个server, 并且搭了一个 graphexp 的 UI server. 脚本如下:
mkdir -p /home/supra/work/data/janusgraph/{data,index}
sudo chown -R 999:999 /home/supra/work/data/janusgraph
docker run --name janusgraph -p 8182:8182 --restart always -d --platform linux/amd64 -v /home/supra/work/data/janusgraph/data:/var/lib/janusgraph/data -v /home/supra/work/data/janusgraph/index:/var/lib/janusgraph/index janusgraph/janusgraph
docker run --name graphexp -p 8183:80 --restart always -d --platform linux/amd64 ghcr.io/armandleopold/graphexp:0.8.3
大家注意到, 这里我们给 Janusgraph 的server 挂载了一个 volume, 还把这个挂载的文件夹的owner 改成了用户和组都是999的用户, 这里确实是偷懒. 这一切都是因为 Janusgraph 的 docker 文件里面新起了一个 janusgraph 的用户, 它的uid和gid都是 999. 在 Janusgraph server 里面, 都是以这个用户运行的. 都是因为这个用户和组, 导致我最后必须写下这篇记录.
本地环境这么起起来, 往里面灌入数据, 在用 graphexp 的UI 去访问, 一切顺利. 于是准备轰轰烈烈的去搞一个prod Janusgraph server 集群, 目标是1个小时搞定.
首先, prod 环境不能访问外网的 docker image, 于是拉下最新的外网image, 然后重新打一个 tag, 搞成内网的 image, 然后在生产环境的 k8s 环境做一个新的app, 然后一番乱搞, docker image 开始启动了.
但是呢, 总是启动不起来, 为啥, 因为:
chown: changing ownership of '/var/lib/janusgraph': Operation not permitted
chown: changing ownership of '/etc/opt/janusgraph': Operation not permitted
chmod: changing permissions of '/var/lib/janusgraph': Operation not permitted
chmod: changing permissions of '/etc/opt/janusgraph': Operation not permitted
仔细分析下来, 主要是:
- 生产环境都是 rootless 的, 所以运行 container 的 uid 都不是 root, 是一个根据 namespace 预先定义好的用户.
- 生产环境默认所有image 里面的文件都是read only, 所以对于日志, 数据文件必须通过 volume 挂载使用.
- 给 Janusgraph server 用的 data 和 index 文件夹都是挂载的 volume, 而这些 volume 的owner 都是上面预先定义好的 rootless 用户;
- 而一旦进入 Janusgraph, 它却以 Dockerfile 中自己新加的 janusgraph(999:999) 这个用户运行.
所以, 就造成了这种困境: 因为 image 里面的文件都是 read only, 和必须保存这些数据, 数据必须以 volume 的方式挂载, 然而挂载的文件夹的主人是预先定义好的非 root 账号, Janusgraph 的启动脚步里面却要改变这些数据文件夹的属主, 但是它使用的自己创建的账号janusgraph(999:999), 而这个账号有没有权限更改owner. 于是死了.
想解决这个问题, 有2种可能的方案:
- 生产环境其实可以改变这个预先定义好的非root 账号, 我们的生产环境可以针对某个namespace 创建一个新的用户, 而这个用户必须绑定生产环境的 LDAP. 所以, 要先定义一个生产环境的 LDAP 账号, 规定它的uid/gid, 然后绑定某个 k8s 下面的namespace, 然后在运行这个 container 的 spec 里面的 SecurityContext 里面设置 fsgroup, runAsUser 等.
- hack Janusgraph 的 Docker 文件, 去掉这个自己创建的用户, 像其它 image 一样, 用默认用户不香吗?
首先想去试试第一种方案. 去找了公司内部k8s的文档, 说是有这么一个创建posixuser 的流程, 可能是因为很少有人用, 搜了半个多小时, 没有找一个完整的文档, 能教会我怎么去做的. 更多的文档是说查看有了这么一个账号, 然后就可以以它运行container 了. 再加上更改任何生产环境的东西, 要走审批流程, 1个小时后, 我彻底放弃了.
第二种方案, 就是要大改看懂 Janusgraph 的Dockerfile 和 docker-entrypoint.sh 两个文件. 花了半个小时, 大改看到它就是想以一个service acount (janusgraph) 来运行这个服务, 然后启动前, 把相关的文件都给这个用户设置好, 然后就启动. 于是改了上述2个文件里面的关于这个用户的行, 然后加了一些日志, 然后本地做一个新的image, 然后push 到内部 image 仓库, 然后启动等好消息.
然而, 有没起来, 还以为是关于这个用户的错误, 又加调试代码, 做新image, 发布的流程再走一遍, 仍然起不来. 后来竟然发现是 刚起来, 就被 OOM kill 了. 哎, 命运多舛. 为啥 OOM 呢, 本地好好的. 因为 OOM 很快被 kill, 所以只有很短的时间, 能进入 container 去查看日志, 但是进入发现, 日志文件都是空.
于是进入本地启动好的 container 里面, 去查看它的启动参数(container 里面啥工具都没有, cat /proc/1/cmdline 才看到), 发现它启动的时候, 竟然就要求 heap 是4G, 那么再加点其它的 metaspace , 还有些辅助进程等, 岂不是5G打不住? 然而一开始我觉的它需要的内存很小, 只给了它1G的空间, 所以 OOM 也就很好理解了. 于是我就想问了, 为啥官方文档不告诉你最少需要5G呢???, 另外启动日志不能把这么重要的参数打印出来吗?
虽然心有不忿, 还是立马改了内存限制, 立马给他8个G, 然后再启动, 发现起来了, 可是有错:
Disk usage is not within je.maxDisk or je.freeDisk limits and write operations are prohibited
对了, 就是这个还在 open 的issue, 必将以后还要open: https://github.com/internetarchive/heritrix3/issues/340. 因为他们改变不了. 原来这个内存数据库, 需要至少5个G的磁盘空间, 否则, 它就生气. 而我给所有的 volume 的大小总共才2个G, 所以出这个错, 也就不难理解了.
于是, 我有给 volume 加到12个G. 于是重新部署, 大家都开心了, 你好, 我也好. 终于成功了. 至此, 本来打算要1个小时完成的工作, 终于通过12个小时(早上9点到晚上9点, 当然中间包括2顿饭的时间和1个多小时的开会)的努力, 画上句号了.
