Apache Druid 0.21.1版本发布说明与过程回顾

Apache Druid 0.21.1版本今天官宣正式发布了。该版本是一个BUG FIX版本,修复了如下4个BUG:

  • #11167 修复Docker镜像在全新的macOS环境上无法启动middle manager等节点的问题
  • #11207 修复Broker到Historical查询时间歇性失败的问题
  • #11228 修复Web Console页面上配置Kinesis摄入字段必填的问题
  • #11299 修复Docker镜像在AWS Fargate上不能正常启动和在Linux上不能摄入数据的问题

尽管issue列表上是4个问题,其中两个和Docker相关,但这个版本实际解决了3个Docker问题(#11167,#11278 , #11298),整个版本发布过程也是比较曲折,并且相比计划大约推迟了半个月。由于这几个Docker镜像问题都是我参与定位和修复,经历了0.21.0和0.21.1版本发布完整过程,我在此总结了一下过程、教训与用户建议。

过程

4月26日,我在0.21.0 RC1版本发布投票中,反馈Docker镜像在macOS上运行时无法启动middle manager等节点问题。但由于RC1版本投票中,该问题未在所有参与版本验证的PMC成员中暴露,0.21.0仍然原定计划在4月26日下午结束投票,并按计划如期发布。

4月27日,问题定位清楚后,我正式提交PR修复此问题。

4月29日,0.21.0版本发布后,果然在社区收到大量用户反馈。在项目开发邮件列表讨论之后,决定发布0.21.1来修复此问题。

4月30日,PR完成检视并合并到主干分支。此后社区建立0.21.1分支,合入修改进入0.21.1版本制作发布流程中。

5月15日,社区打包了0.21.1版本的第一个RC1版本,开始投票。

5月19日,该RC版本发布投票时,社区成员除了在macOS上运行Docker外,额外关注了Docker镜像在Linux系统运行情况,此时发现Docker镜像在Linux上仍然存在目录权限问题。但此目录权限问题与前述macOS上权限问题表现不同的是,该问题是在摄入任务运行完毕生成任务日志文件时暴露。问题出现之后,摄入任务意外退出,无法完成数据提交。

5月20日,我检查了该问题,原因在于docker-compose中使用的磁盘卷并没有在Dockerfile中创建对应的目录,同时Linux系统上HOST类型的磁盘权限默认是root,docker挂载该目录到实例后,实例中的目录权限仍然是root。而docker实例中的Druid进程以名称为druid的用户运行,自然无法创建目录和文件。

此后我又检查了github上的历史issue,发现早在Druid提供Docker镜像的第一个版本0.17.0上就有人反馈此问题。至于为何这个问题一直没有在社区开发之间重视,我判断有如下两方面原因:

  1. 社区开发绝大多数都是使用macOS进行开发而不是在Linux上开发(包括我),同时我们都认为Docker运行环境是标准的,即在macOS运行正常,在Linux上也应该理所当然运行正常
  2. Druid提供的docker-compose主要作用是quickstart,帮助用户快速启动和运行Druid,用户反馈问题可能没有得到足够的重视

由于0.21.1本身计划就是要修复一个Docker问题,但现在还是存在类似问题,尽管此问题有规避方法进行规避,我在邮件列表中对RC1版本的发布仍然提出了明确的反对意见:

  1. ingestion has no chance to succeed on linux
  2. users have experienced enough docker related problems, we had better resolve them all in a single release

但社区其他PMC成员认为该问题有规避手段,并不是阻塞性问题,应该如期发布。

5月21日,正当我在着手修复此问题时,社区收到了针对RC1版本反馈的新的Docker问题。从该用户反馈来看,问题在于Dockerfile中使用了符号链接,而符号链接在AWS Fargate中并不支持。此问题的出现,事实上导致了RC1版本投票无法按预期收到足够多的赞成票,并给解决上述Linux中的Docker目录权限问题留出了一定时间。

5月25日,我提交PR 11299正式修复前述两个Docker相关问题。针对前一个Docker镜像在Linux系统上无法创建子目录问题,经过社区成员讨论之后,我们决定在docker-compose中采用Named Volume来替代原来的Host Volume一劳永逸解决问题。

6月2日,PR经过其他项目成员在自己环境验证通过后,合入到主干和0.21.1版本分支。

6月3日,社区打包了RC2版本,开始进行投票。

6月4日,按照投票流程进行版本检查后,我第一个投下了赞成票
6月9日,社区收到了发布该版本的足够票数,版本发布进入最后的流程。
6月11日,版本正式发布

至此,经过1个多月的漫长的讨论、解决、验证,Docker相关问题全部解决,发布终于结束。

教训

  1. Docker虽然提供了标准的打包与运行环境,但是从0.21.1版本解决的三个Docker镜像问题来看,不同宿主机的Docker运行环境在文件系统,特别是文件系统权限管理上,仍然有差别。版本发行验证时,此前也没有标准化的方法。我在邮件讨论列表中给出了标准化的验证步骤,其中第一步就是使用docker volume prune清理掉历史的VOLUME,保证本地是一个干净的运行环境。

  2. Druid有自己基于Docker镜像的端到端测试自动化测试,但遗憾的是,该测试基于的镜像并非正式发行的镜像,而是测试用例中一套独立的Dockerfile和docker-compose文件。社区已经意识到此问题,希望后续能够有人解决。

建议

  1. 社区解决问题的周期、发行版本的周期相对而言都较漫长。如果希望问题快速解决,完全依赖社区是不行的。用户应该具备在开源版本基础上自己动手解决问题的能力,虽然这种能力的建设和具备同样也是一个漫长的过程。
    比如我参与到Druid中有一部分时间都是本质工作之外,通常很难给出一个具体完成时间,从前面也可以看到,从Linux上Docker无法摄入数据问题提出,到我最终提PR解决,中间大概有两个多星期时间。再比如比如在5月初的时候我判断我们预计5月15日左右就应该可以发布0.21.1,但后来新问题的发现、解决,发布时间推迟了。如果有解决问题的能力,完全可以自己制作Docker镜像,而不需要等社区修复。