StarRocks Docker 开发环境搭建指南

因为 StarRocks 源自于 Apache Doris，故 Apache Doris 也可以参考此方案。

StarRocks 分为 FE 和 BE，其中 FE 使用 Java 编写，凭借 JVM，环境其实还算好搭，我个人在 M1 的 MacBook 上也能成功跑起来，具体可以参考 StarRocks FE 在 IDEA 上开发环境设置 这篇文章。但是 BE 就很难了，毕竟 C++ 写的，估计光是那个 thirdparty 的编译，就没几个人能搞定。

故这里我使用 Docker 统一开发环境，然后通过 IDE 的远程开发进行开发。

特性

开始介绍之前，我说说这一个月我 Docker 开发的利弊，给大家作为一个参考。

优势：

• 借助官方提供的 Docker 镜像，无需手动编译 thirdparty，开箱即用。
• 使用 mold 进行链接，让 BE 的编译速度更上一层楼。
• 支持 ssh 远程开发，目前各大 IDE 都已支持。
• 内置 GDB，GDB Server 模块，支持 Debug 操作。
• 内置 tmux，mysql-client 辅助开发。
• 无视端口冲突，省了改配置的功夫。

缺点

• 暂时只支持 x86 的机器，如果将来 StarRocks 提供的镜像支持 Arm 环境，那么在 Mac M1 上也能进行开发。
• 镜像体积较大，差不多 8G。
• 编译和后续的开发至少需要 8G 内存，否则大概率你连 Docker 的镜像都 build 不出来。

Dockerfile

你可以自己编译 Dockerfile，也可以用现成的镜像。我把镜像部署在 GitHub 上，并且做了 CI 自动编译，确保镜像的时效性。

GitHub 仓库：https://github.com/Smith-Cruise/StarRocks-Docker-Dev

镜像的默认 ssh 用户名为 root，密码为 xxx，默认端口为 2222。

Dockerfile 中可以修改的地方已在注释中声明，其它地方请不要动。能动的地方分别是 ssh 密码，ssh 端口和 gcc-mold 的 clone 地址。

使用

在本地新建一个 ~/.m2 目录和 StarRocks 的源码目录。其中 .m2 目录用于持久化 Maven 下载的 jar 包，源码目录则用来存源码。否则你 Docker 没了，你写的代码和辛辛苦苦缓存的 jar 包都没了。

拉取镜像：sudo docker pull d87904488/starrocks-docker-dev:main 。

使用如下的启动命令：

sudo docker run -it -p 2222:2222 \
  --privileged \
  --cap-add SYS_PTRACE \
  -v ~/.m2:/root/.m2 \
  -v /home/smith/starrocks:/root/starrocks \
  --name smith-dev \
  -d d87904488/starrocks-docker-dev:main

下面我会对命令进行解释，这样你可以自己发挥。

• -p 2222:2222：开 ssh 端口。你也可以使用 --net=host 命令直接和宿主机共享网络，这样你可以不用手动一个一个开端口，但是容易端口冲突。
• --privileged --cap-add SYS_PTRACE：不加这个你用不了 GDB。
• -v ~/.m2:/root/.m2 -v /home/smith/starrocks:/root/starrocks：和容器中相应目录进行映射，对代码进行持久化。
• --name smith-dev：自定义的容器名称。
• -d：后台运行。

注意映射到容器中的位置不要动，就是 /root/starrocks 和 /root/.m2 这两个不能动，因为镜像中的环境变量已经映射好了。

远程开发方案的选择

1. 使用 VIM 开发，🐮。
2. 使用 VS Code 远程开发，简单，ssh 连进去就可以开干，就是没 Jetbrains 全家桶牛。因为比较简单后面不做阐述。
3. 使用 Jetbrains 的 Gateway 开发，相当于在 Docker 里面内嵌了一个 IDE，然后你通过远程控制进行开发。优点是和 VS Code 一样开箱即用，缺点就是比较卡，有些小 BUG，体验没有本机的好。
4. 使用 Jetbrains 的代码同步实现远程开发，我目前使用的就是这种方法（推荐）。即用 IDEA 打开 FE，CLion 打开 BE，然后映射远程的代码。

Debug 方法

关于 DEBUG 你需要修改启动脚本 start_be.sh 和 start_fe.sh 脚本。方法有很多，我只介绍我自己使用的方法。

FE

把 start_fe.sh 脚本中的：

if [ ${RUN_DAEMON} -eq 1 ]; then
    nohup $LIMIT $JAVA $final_java_opt com.starrocks.StarRocksFE ${HELPER} "$@" >> $LOG_DIR/fe.out 2>&1 </dev/null &
else
    $LIMIT $JAVA $final_java_opt com.starrocks.StarRocksFE ${HELPER} "$@" >> $LOG_DIR/fe.out 2>&1 </dev/null
fi

替换为：

if [ ${RUN_DAEMON} -eq 1 ]; then
    nohup $LIMIT $JAVA $final_java_opt com.starrocks.StarRocksFE ${HELPER} "$@" >> $LOG_DIR/fe.out 2>&1 </dev/null &
else
    $LIMIT $JAVA $final_java_opt -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=8001 com.starrocks.StarRocksFE ${HELPER} "$@" >> $LOG_DIR/fe.out
fi

即可。

之后使用 sh start_fe.sh 命令启动，然后就可以通过 IDEA 的 Remote Debug 进行远程 Debug，这里的端口号是 8001。

BE

把 start_be.sh 脚本中的

if [ ${RUN_DAEMON} -eq 1 ]; then
    nohup ${STARROCKS_HOME}/lib/starrocks_be "$@" >> $LOG_DIR/be.out 2>&1 </dev/null &
else
    ${STARROCKS_HOME}/lib/starrocks_be "$@" >> $LOG_DIR/be.out 2>&1 </dev/null
fi

替换为

if [ ${RUN_DAEMON} -eq 1 ]; then
    nohup ${STARROCKS_HOME}/lib/starrocks_be "$@" >> $LOG_DIR/be.out 2>&1 </dev/null &
else
    gdb -tui ${STARROCKS_HOME}/lib/starrocks_be
fi

即可。

使用 sh start_be.sh 命令开启 tui 模式的 gdb。

当然你可以把前缀 gdb -tui 换成 gdbserver 0.0.0.0:5555 开启 gdbserver，然后使用 Clion 的 Remote GDB 接入调试。

TIPS

• 第一次同步代码建议在容器里面 git clone 一份代码，这样可以节省首次 IDE 代码同步的时间。
• IDEA 和 CLion 首次启动可能会报文件缺失，这是因为 gensrc 中文件没有生成，里面主要是一些 Thrift 和 Protobuf 文件。你可以先在容器中的 /root/starrocks 目录中执行 sh build.sh 命令一次，然后将容器中 root/starrocks/gensrc/build 生成的代码拷贝到本地相同目录。（当然你也可以不这么做，自己本地生成，参考 StarRocks FE 在 IDEA 上开发环境设置 这篇文章）。
• 因为我们只开放了 2222 端口，一些内部组件可能无法访问（比如远程 JVM DEBUG 端口），这时可以使用 VS Code 自带的端口映射功能，很方便。当然你也可以通过命令行建立端口转发。
• FE 的远程调试还好用，IDEA 可以直接 Remote Debug。但是 BE 我建议还是直接用 GDB 本地调试吧，CLion 远程开发太卡了，亲测。
• BE 的 GDB 符号表首次加载很慢，毕竟二进制文件太大了，目前还没有什么好的解决办法。

总结

如果 Docker 镜像出现问题或你有什么好的意见，请反馈。