前言

最近一年多以来，我开展了一些与鸿蒙相关的开发工作。

在开发过程中，我做了一些自用的效率工具，其中一个就是容器化的鸿蒙环境。

现在我把这个自用的工具开源了：https://github.com/hqzing/dockerharmony

这个鸿蒙容器使我们能够使用 Linux 服务器来运行和测试我们的命令行程序，而不用依赖 OpenHarmony 物理设备。

环境准备

要使用这个鸿蒙容器，你首先要有一个 Docker 运行环境，最好是 arm64 的硬件，例如 arm64 服务器或者 mac 电脑。

推荐使用 arm64 服务器，并且买在香港或国外的区域（阿里云、华为云等云厂商有卖）。因为后续你可能会需要从 GitHub 下载各种开源软件，如果你的服务器中国大陆区域，可能很多软件会下载不下来。

如果实在难以获取 arm64 设备，可以按照 DockerHarmony 的 README 文档里面的指导，去注册 QEMU 解释器，以支持在 x64 硬件上运行 arm64 容器。但此种做法有极大的性能损失，对于编译构建类型的任务，它能发挥出的性能通常只有原生 arm64 硬件的 5% ~ 10%。

基础用法

这个镜像同时上传到了 Docker Hub 和 GitHub Container Registry，你可以任选其一，从上面下载这个镜像使用。

从 Docker Hub 拉取镜像并运行

docker pull hqzing/dockerharmony:latest
docker run -itd --name=ohos hqzing/dockerharmony:latest
docker exec -it ohos sh

从 GitHub Container Registry 拉取镜像并运行

docker pull ghcr.io/hqzing/dockerharmony:latest
docker run -itd --name=ohos ghcr.io/hqzing/dockerharmony:latest
docker exec -it ohos sh

工具获取

这个容器里面只是一个最小系统，除了 toybox 提供的少量命令和我内置进去的 curl 以外，里面什么工具都没有。这是无法支撑开发工作的，所以我们要根据自己的实际需求，往里面装一些工具。

至于工具从哪来？你可以根据 README 文档的操作去 Alpine Linux 的软件仓库获取；也可以用我移植好的工具；或者去找别人移植好的工具。

这是我移植好的一批工具，使用方式已经写在各项目的 README 文档里面了

工具	项目地址
coreutils	https://github.com/Harmonybrew/ohos-coreutils
busybox	https://github.com/Harmonybrew/ohos-busybox
grep	https://github.com/Harmonybrew/ohos-grep
gawk	https://github.com/Harmonybrew/ohos-gawk
make	https://github.com/Harmonybrew/ohos-make
tar	https://github.com/Harmonybrew/ohos-tar
gzip	https://github.com/Harmonybrew/ohos-gzip
patch	https://github.com/Harmonybrew/ohos-patch
diffutils	https://github.com/Harmonybrew/ohos-diffutils
perl	https://github.com/Harmonybrew/ohos-perl
m4	https://github.com/Harmonybrew/ohos-m4
autoconf	https://github.com/Harmonybrew/ohos-autoconf
texinfo	https://github.com/Harmonybrew/ohos-texinfo
git	https://github.com/Harmonybrew/ohos-git
ruby	https://github.com/Harmonybrew/ohos-ruby
zsh	https://github.com/Harmonybrew/ohos-zsh
bash	https://github.com/Harmonybrew/ohos-bash
vim	https://github.com/Harmonybrew/ohos-vim
openssh	https://github.com/Harmonybrew/ohos-openssh
python	https://github.com/Harmonybrew/ohos-python

实践案例

这个鸿蒙容器，搭配上面给出的这些工具一起使用，再加上 ohos-sdk，就可以胜任很多开发工作了。

上面贴出来的 20 个工具里面，除了前 5 个是在 Ubuntu 上面交叉编译出来以外，剩下的都是在鸿蒙容器中编译出来的。你可以尝试模仿里面的做法，把鸿蒙容器作为编译环境或测试环境使用。

迭代过程

这个鸿蒙容器截止到现在已经经历了 3 个版本迭代，现在开源出来的是最后一个最成熟的版本。

第 1 个版本：早期最简版本

最开始做的时候，OpenHarmony 还是 4.0 版本。当时只要编一份 arm64 架构的 rk3568 镜像，把里面的 ramdisk.img 解压、打成 tar 包、导入到 Docker 中就能直接用。

因为当时我找到的官方 rk3568 镜像只有 32 位的，而我编的软件要在 64 位系统上进行测试，所以需要自己编 64 位的系统。

第 2 个版本：事情逐渐变得复杂

到了 OpenHarmony 5.1 版本的时候，我对环境进行了一次升级。这时候发现 OpenHarmony 官方社区的日构建流水线里面就有提供 dayu200-arm64_5.1.0-Release 的产物，不用我自己去编 64 位系统了。

但是这个新版本带来了一个新问题：单把 ramdisk.img 里面的内容导到 Docker 里面是跑不起来的，因为这里面的 toybox 被改造了，它依赖了一个 system.img 里面的 so。我不得不分别从两个镜像各取一部分内容，放在一起，导入到 Docker 中。

第 3 个版本：需要改造系统源码

升级完版本之后，发现它时不时会在各进程的 stderr 里面输出一些类似于 HiLogAdapter: Can't connect to server. 这样的报错。

定位之后发现是 OpenHarmony 社区把 musl libc 进行了改造，做了很多日志输出，而且日志是对接到 HiLog 里面的。我在容器里面没有启动 init 进程，也没把 HiLog 相关的东西带进来，容器中自然就不会有 HiLog 服务，于是 musl libc 没法通过 socket 跟 HiLog 服务进行通信，因此就时不时会有错误日志从各个进程的 stderr 里面冒出来，这会在一些情况下会导致业务异常。

为了处理这个问题，我只好放弃使用 OpenHarmony 官方编好的包，又换回了自己编包的方案。只有这样做，我才能通过改源码的方式去处理这个 musl libc 对 HiLog 的依赖问题。

演进计划

这个鸿蒙容器和 Harmonybrew 组织下面的那些 ohos-xxx 项目，它们以后都会变成 Harmonybrew 项目的基建的一部分。Harmonybrew 项目是一个把 Homebrew 移植到 OpenHarmony 平台的项目，我正在为了实现这个目标而开展一些工作。

鸿蒙容器在 Harmonybrew 项目中主要会用于流水线业务，用来把用户贡献的 formula 构建成 bottles。现在 OpenHarmony 官方并没有提供云化的环境，也没有第三方厂商提供这方面的解决方案，我们没法像 Windows、Linux、MacOS 那样很方便地在流水线上面进行本地编译和自动化测试。在这种情况下，除了用这个鸿蒙容器以外没有其他选择。

至于那些 ohos-xxx 的软件包，它们要么是 Homebrew 所需的依赖，要么是编其他软件的时候需要用到的构建工具。

有了 git、curl、zsh、ruby，Homebrew 就能在 OpenHarmony 上运行了。在这基础上，把 grep、gawk 等工具预置在 Harmonybrew 的流水线环境上，将它们作为外置工具链，有了这一批外置工具链，我们就能很轻易地构建出其他的 formula 了，久而久之就能“长”出一套完整的生态了。

Harmonybrew 相关的坑已经占好了（GitCode 链接、GitHub 链接），正在施工中，大家敬请期待，到时候做好了欢迎大家过来贡献 formula。