Ubuntu 22.04 安装 Havenask 1.2.0 指南

Ubuntu 22.04 按官方 create_container.sh + hape 形态从零部署 Havenask v1.2.0 单机集群：建表/写入/查询全链路实测、重启持久化、ZooKeeper 堆限制与排障实录。

Havenask搜索引擎Docker2026/10/23

Ubuntu 22.04 安装 Havenask 1.2.0 指南

目标：在一台 Ubuntu 22.04 服务器上，按官方唯一分发形态（Docker 镜像 + hape 编排工具）从零部署 Havenask v1.2.0 单机检索集群，完成建表、写入、查询全链路验证与重启持久化验证，并沉淀完整排障实录。全文命令与回显均在 Ubuntu 22.04 + Havenask v1.2.0 环境实测通过（实测日期 2026-10-23）。

一、环境信息

  • 操作系统：Ubuntu 22.04（x86_64）
  • Havenask 版本：v1.2.0（官方最新稳定版，2024-04-10 发布；版本实查日期 2026-10-23）
  • 运行镜像：registry.cn-hangzhou.aliyuncs.com/havenask/ha3_runtime:1.2.0（解压后 8.11GB）
  • Docker 版本（实测）：Docker version 29.8.1, build 4a63305
  • 硬件基线：4 核 CPU / 8GB 内存 / 60GB 磁盘（官方最低要求见 2.1）
  • 部署形态：官方 create_container.sh 脚本创建 --net=host 运行环境，hape 在其内拉起单机伪集群（admin ×3 + searcher + qrs + swift broker + ZooKeeper）
  • 关键目录：/ha3_install（引擎与 hape 安装根）、/root/havenask/havenask_data_store（索引与元数据存储根）
  • 端口规划（实测监听，--net=host 直接占用宿主端口）：
端口进程/角色用途
2181ZooKeeper（hape 测试实例）集群协调
45700suez_admin_worker（havenask admin）管理面 HTTP（catalog/调度）
45800ha_sql（QRS）SQL 查询入口（HTTP）
45801ha_sql（QRS）QRS arpc
45898ha_sql（searcher）searcher arpc
45899ha_sql（searcher）searcher HTTP
45900ha_sql（searcher）searcher 心跳端口（健康检查路径 /HeartbeatService/heartbeat）
45901ha_sql（searcher）searcher 写入通道（gig grpc）

二、前置条件

2.1 系统要求（官方口径）

官方 README 对 v1.2.0 的环境要求（来源：GitHub README，查询日期 2026-10-23）：

镜像CPU内存磁盘
ha3_runtime（运行）>2 核>4G>20G
ha3_dev（开发编译）>2 核>10G>50G

另外官方要求：使用前确保设备已安装并启动 Docker 服务；单机模式需确保本机能免密 ssh 登录自己（见 2.3）。

2.2 安装并确认 Docker

Ubuntu 22.04 上若尚未安装 Docker，使用 Ubuntu 官方仓库标准命令安装：

# Ubuntu 22.04 标准安装命令（已装可跳过）
apt update && apt install -y docker.io
systemctl enable --now docker

⚠️ 本篇实测环境的 Docker 版本为 29.8.1（docker --version 实测回显 Docker version 29.8.1, build 4a63305）。 Havenask 官方脚本只要求存在可用的 docker 命令，对版本无硬性约束。

确认 Docker 服务可用：

docker --version

实测回显：

Docker version 29.8.1, build 4a63305

2.3 配置本机免密 ssh 自登录（官方单机模式要求）

官方要求单机模式能免密 ssh 登录自己。生成密钥对并把公钥写入本机 authorized_keys：

# 生成密钥对（无口令）
ssh-keygen -t rsa -N "" -f ~/.ssh/id_rsa -q
# 追加公钥到本机授权列表
cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
# 验证免密自登录
ssh -o StrictHostKeyChecking=no -o BatchMode=yes root@127.0.0.1 "echo ssh-ok && hostname"

实测回显（验证命令）：

Warning: Permanently added '127.0.0.1' (ECDSA) to the list of known hosts.
ssh-ok
ops

自登录成功输出 ssh-ok 即满足前置。

2.4 检查端口占用

hape 单机模式以 --net=host 运行，第一节表格中的端口将直接占用宿主机。部署前确认未被占用：

ss -ltn | grep -E ':(2181|45700|45800|45801|4589[89]|45900|45901)\b'

实测回显（部署前，无占用则无输出，命令静默返回；部署后同一命令的回显见 5.5）。

三、版本选型说明

3.1 官方 Release 与镜像 tag

官方 Release 时间线（来源：GitHub releases.atom，查询日期 2026-10-23）：

版本发布时间说明
v0.12022-11-08首次开源
v0.2.22023-01-04早期迭代
v0.3.02023-03-23早期迭代
1.0.02023-12-11首个 1.x
1.1.02024-03-081.x 迭代
v1.2.02024-04-10当前最新稳定版，本篇实测版本

镜像仓库为阿里云杭州 registry：registry.cn-hangzhou.aliyuncs.com/havenask/ha3_runtime:<tag>，latest 与 1.2.0 当前指向同一版本。v1.2.0 发布件 create_container.sh 内默认锁定 IMAGE_VERSION="1.2.0"，因此按官方脚本部署即为 v1.2.0。

3.2 ha3_runtime 与 ha3_dev 如何选

镜像用途资源要求适用人群
ha3_runtime直接运行问天引擎可执行文件，无需编译内存>4G、磁盘>20G部署/运维，本篇主线
ha3_dev含编译依赖库与头文件，用于编译问天引擎内存>10G、磁盘>50G二次开发/源码定制

关键差异：只想搭建可用的检索服务选 ha3_runtime；要改引擎源码、编译自定义版本才需要 ha3_dev。

四、方案 A：官方镜像部署（推荐主线，实测）

4.1 下载官方部署脚本

官方唯一推荐入口是随 v1.2.0 Release 发布的 create_container.sh：

cd /root
wget https://github.com/alibaba/havenask/releases/download/v1.2.0/create_container.sh
chmod +x create_container.sh

脚本来自 GitHub 官方 Release 发布件（v1.2.0），默认镜像锁定为 registry.cn-hangzhou.aliyuncs.com/havenask/ha3_runtime:1.2.0。

4.2 运行官方脚本创建运行环境

./create_container.sh havenask-120-runtime

实测回显：

Start to run scrip
Info: Repo locatation: /opt/data/quzuo/tmp
Info: Container entry: /opt/data/quzuo/tmp/havenask/havenask-120-runtime
Begin pull image: registry.cn-hangzhou.aliyuncs.com/havenask/ha3_runtime:1.2.0
1.2.0: Pulling from havenask/ha3_runtime
Digest: sha256:a4fd0269ac54593c894510df783d7aa6e33169cecf9731f7d1a6f08bbec51734
Status: Image is up to date for registry.cn-hangzhou.aliyuncs.com/havenask/ha3_runtime:1.2.0
registry.cn-hangzhou.aliyuncs.com/havenask/ha3_runtime:1.2.0
Begin initialize container:
useradd: user 'root' already exists
usermod: no changes
INFO start container success

⚠️ useradd: user 'root' already exists 与 usermod: no changes 是脚本初始化的预期回显：脚本按当前登录用户的 UID 在镜像内重建同名用户，当以 root 身份（UID 0）执行时 root 已存在，提示可忽略，不影响后续流程（初始化以最后一行 INFO start container success 收尾即成功）。

脚本做了四件事（对应脚本源码行为，来源：v1.2.0 发布件 create_container.sh）：

动作说明
拉取镜像docker pull registry.cn-hangzhou.aliyuncs.com/havenask/ha3_runtime:1.2.0
启动运行环境以 --net=host --privileged、--ulimit nofile=655350、--ulimit memlock=-1 等参数启动，并挂载 $HOME 与初始化脚本
执行初始化在环境内创建同 UID 用户、写入 sudo 免密、设置 PS1，并在 /mnt/ram 挂载 20g ramfs（供索引构建临时加速，按需占用内存）
生成入口脚本在脚本目录生成 havenask-120-runtime/sshme（进入环境）与 havenask-120-runtime/stopContainer.sh（停止并删除环境）

4.3 进入运行环境

./havenask-120-runtime/sshme

sshme 内部等价于以部署用户身份进入 Havenask 运行环境（脚本内容实测为 docker exec --user <用户> -it havenask-120-runtime sh -c 'cd ~ && /bin/bash'）。进入后提示符形如 [root@havenask ~]#，引擎安装在 /ha3_install。

4.4 启动单机集群

/ha3_install/hape start havenask

实测回显（节选，全流程约 25 秒；组件按 zk → swift → havenask admin → bs 顺序逐个就绪）：

[2026-10-23 18:25:18,611] [INFO] [domain_config.py:__init__:23]: Hape conf directory: /ha3_install/hape_conf/default
[2026-10-23 18:25:18,663] [INFO] [infra_manager.py:start_zookeeper:36]: If you don't want to use test zookeeper or hape starts test zookeeper timeout, please start zookeeper by hand and fill domainZkRoot in global.conf
[2026-10-23 18:25:21,147] [INFO] [infra_manager.py:start_zookeeper:43]: Succeed to start test zookeeper
[2026-10-23 18:25:21,170] [INFO] [cluster_base.py:start:93]: Begin to start swift admin
[2026-10-23 18:25:28,703] [INFO] [retry.py:retry:13]: Check [Swift admin is ready] succeed
[2026-10-23 18:25:28,703] [INFO] [cluster_base.py:start:93]: Begin to start havenask admin
[2026-10-23 18:25:35,933] [INFO] [retry.py:retry:13]: Check [Havenask admin is ready] succeed
[2026-10-23 18:25:35,947] [INFO] [catalog_manager.py:create_default_catalog:34]: Succeed to create default catalog
[2026-10-23 18:25:35,951] [INFO] [catalog_manager.py:_create_default_database:53]: Succeed to create default database
[2026-10-23 18:25:35,963] [INFO] [domain.py:keep_bs_master:70]: Bs admin is not ready, begin to start default bs cluster
[2026-10-23 18:25:43,199] [INFO] [retry.py:retry:13]: Check [Bs admin is ready] succeed

启动完成后，hape 会以独立工作进程形态拉起 QRS、searcher 与 swift broker。用状态命令确认：

/ha3_install/hape gs havenask

实测回显（建表前）：

{
    "hint": "Group database Role database_partition_0 has unready containers, or mabye lack of candidate nodes",
    "leaderAddress": "http://127.0.1.1:45700",
    "serviceZk": "zfs://127.0.1.1:2181/havenask/havenask-sql-local/appmaster",
    "hippoZk": "zfs://127.0.1.1:2181/havenask/havenask-sql-local/hippo",
    "clusterStatus": "NOT_READY",
    "sqlClusterInfo": {
        "admin": [...],
        "qrs": {...},
        "database": {...}
    }
}

⚠️ 此时的 NOT_READY 是正常中间态：searcher 尚未加载任何表（used_tables 为空），集群要等第一张表创建后才会转为 READY。不要在此反复重启，直接进入第五章建表即可。

五、建表与读写冒烟验证

5.1 创建示例表

官方示例 schema 位于 /ha3_install/example/cases/normal/in0_schema.json（含 TEXT/PRIMARY_KEY64/ATTRIBUTE/PACK/SUMMARY 索引定义，全文见本专栏配置参数详解篇）。建表命令：

/ha3_install/hape create table -t in0 -s /ha3_install/example/cases/normal/in0_schema.json -p 1

实测回显（节选）：

[2026-10-23 18:40:00,105] [INFO] [retry.py:retry:8]: Begin to check [qrs achieve target replicas]
[2026-10-23 18:40:02,444] [INFO] [domain.py:check_table_ready:134]: Table not ready in all qrs or searchers by now
[2026-10-23 18:40:02,444] [INFO] [domain.py:check_table_ready:135]: If it takes long, you can execute `gs havenask` to find the reason
[2026-10-23 18:40:09,666] [INFO] [retry.py:retry:13]: Check [Table in0 ready] succeed
[2026-10-23 18:40:09,666] [INFO] [domain.py:create_table:142]: Table in0 is ready
[2026-10-23 18:40:09,667] [INFO] [domain.py:create_table:143]: Before read & write table in0, please confirm havenask cluster ready by using gs havenask subcommand

确认集群转 READY：

/ha3_install/hape gs havenask
/ha3_install/hape gs table -t in0

实测回显（关键字段）：

"clusterStatus": "READY"

{
    "in0": {
        "status": "READY"
    }
}

5.2 写入数据

/ha3_install/sql_query.py --query "insert into in0 (createtime,hits,id,title,subject)values(1,2,4,'test', 'test')"

实测回显：

Request address:[http://127.0.0.1:45800/QrsService/searchSql] query:[insert into in0 (createtime,hits,id,title,subject)values(1,2,4,'test', 'test')&&kvpair=databaseName:database;formatType:string]
USE_TIME: 725.511ms, ROW_COUNT: 1, HAS_SOFT_FAILURE: 0, SOFT_FAILURE_CODES: [], COVERAGE: 1
BUILD_WATERMARK: in0:1792752017792668;

------------------------------- TABLE INFO ---------------------------
total:1, rows:[0, 1), cols:1
            ROWCOUNT (int64) |
                           1 |

ROW_COUNT: 1 表示写入成功。

5.3 查询数据

/ha3_install/sql_query.py --query "select * from in0"

实测回显：

Request address:[http://127.0.0.1:45800/QrsService/searchSql] query:[select * from in0&&kvpair=databaseName:database;formatType:string]
USE_TIME: 31.161ms, ROW_COUNT: 1, HAS_SOFT_FAILURE: 0, SOFT_FAILURE_CODES: [], COVERAGE: 1

------------------------------- TABLE INFO ---------------------------
total:1, rows:[0, 1), cols:5
          title (multi_char) |        subject (multi_char) |                 id (uint32) |               hits (uint32) |         createtime (uint64) |
                        null |                        null |                           4 |                           2 |                           1 |

💡 说明：实测中 TEXT 类型列（title/subject）在 SQL 字符串结果里显示为 null，ATTRIBUTE 列（id/hits/createtime）正常返回。这是该版本 SQL 结果展示层的行为，全文命中判断不受影响（where query('default','test') 可正常命中该行，见常见问题 9.4）。

5.4 端口监听核验

ss -ltn | grep -E ':(2181|45700|45800|45801|4589[89]|45900|45901)\b'

实测回显（部署完成后）：

LISTEN 0      256          0.0.0.0:45700      0.0.0.0:*
LISTEN 0      256          0.0.0.0:45800      0.0.0.0:*
LISTEN 0      256          0.0.0.0:45798      0.0.0.0:*
LISTEN 0      256          0.0.0.0:45900      0.0.0.0:*
LISTEN 0      256          0.0.0.0:45898      0.0.0.0:*
LISTEN 0      50                 *:2181             *:*
LISTEN 0      4096               *:45801            *:*
LISTEN 0      4096               *:45901            *:*

（45801/45901 各有多行监听，为 qrs 与 searcher 的多协议监听，属正常现象；45798 为 admin 内部端口。）

六、方案 B：ha3_dev 开发镜像与源码编译（备选）

当需要修改问天引擎源码并编译自定义版本时，使用官方 ha3_dev 镜像。官方定位：开发测试镜像，包含编译所需依赖库与头文件，编译方法见官方 QuickStart（https://havenask.net/#/doc/sql/guide/quickstart）。

创建 dev 环境与 runtime 完全同构，仅第二参数换成 dev 镜像（create_container.sh 支持显式指定镜像）：

cd /root
wget https://github.com/alibaba/havenask/releases/download/v1.2.0/create_container.sh
chmod +x create_container.sh
./create_container.sh havenask-120-dev registry.cn-hangzhou.aliyuncs.com/havenask/ha3_dev:1.2.0
./havenask-120-dev/sshme

⚠️ dev 镜像要求内存>10G、磁盘>50G；从源码编译问天引擎耗时以小时计，且需熟悉官方 QuickStart 的编译链路。仅部署检索服务时无需进入本方案。

七、方案对比与选择建议

维度方案 A：ha3_runtime 镜像方案 B：ha3_dev 镜像
用途部署运行检索服务编译定制引擎源码
资源门槛内存>4G、磁盘>20G内存>10G、磁盘>50G
上手耗时分钟级（实测从下载到查询约 15 分钟）小时级（含编译）
升级方式更换镜像 tag重新拉源码编译
适用对象绝大多数部署场景引擎二次开发团队

选择建议：无源码定制需求一律选方案 A；方案 B 仅在需要改引擎内部行为（分词插件、打分逻辑等）时启用。

八、日常启停、JVM 与数据持久化

8.1 集群启停与重启

hape 提供三组生命周期命令（--help 实测回显）：

$ /ha3_install/hape stop --help
Usage: hape stop [OPTIONS] COMMAND [ARGS]...

Options:
  -h, --help  Show this message and exit.

Commands:
  build
  container
  havenask
  swift
  • hape stop havenask：只停检索集群进程，不清理 ZooKeeper 与数据文件；
  • hape start havenask：再次拉起；
  • hape restart havenask：重启并从 ZooKeeper 恢复服务（实测有效）。

重启验证（实测）：

/ha3_install/hape restart havenask

实测回显（节选）：

[2026-10-23 18:44:29,561] [INFO] [retry.py:retry:13]: Check [Havenask admin is ready] succeed
[2026-10-23 18:44:29,568] [INFO] [catalog_manager.py:create_default_catalog:34]: Succeed to create default catalog
[2026-10-23 18:44:29,576] [INFO] [suez_cluster_manager.py:create_or_update_default_clusters:23]: Create default cluster

重启后复查状态与数据：

$ /ha3_install/hape gs havenask
    "clusterStatus": "READY",
$ /ha3_install/sql_query.py --query "select id,hits from in0 where id>0"
USE_TIME: 619.925ms, ROW_COUNT: 1, ...

结论：表结构（schema）与集群拓扑在重启后自动恢复；实时写入且尚未触发全量构建的文档会随 searcher 进程重启丢失（实测 id=4 一行在重启后查不到，重新插入即恢复），生产数据持久化必须依赖索引构建链路（见 8.3 与常见问题 9.5）。

8.2 数据与配置目录

路径内容
/ha3_install/hape_conf/default/global.confhape 全局配置（服务名/镜像/dataStoreRoot/资源默认值）
/ha3_install/hape_conf/default/cluster_templates/searcher/qrs/bs/swift 的 hippo 进程模板（资源配额、端口、健康检查）
/root/havenask/havenask_data_store/数据存储根：database_store/（索引数据）、suez_cluster_store/（部署配置）、templates/（表模板）
/ha3_install/example/cases/官方示例（normal/vector/custom_analyzer/llm）

8.3 内置 Java 进程（ZooKeeper）的堆内存限制

hape 测试用 ZooKeeper 是整个部署里唯一的 Java 进程，启动脚本为 /ha3_install/usr/local/share/zookeeper/start.sh，其中第 34 行的 java 命令未显式设置堆参数，JVM 默认取宿主内存的 1/4，在大内存机器上会放大占用。建议显式限制为 512MB——把第 34 行行首的 nohup java 改为 nohup java -Xms256m -Xmx512m ：

cd /ha3_install/usr/local/share/zookeeper
cp start.sh start.sh.bak
sed -i '34s/nohup java /nohup java -Xms256m -Xmx512m /' start.sh
sed -n '34p' start.sh | cut -c1-80

实测回显：

nohup java -Xms256m -Xmx512m -Dzookeeper.log.dir=. -Dzookeeper.root.logger=INFO,

修改后重启 ZooKeeper 进程使其生效，并用 ps 验证实际生效值：

kill $(ps aux | grep QuorumPeerMain | grep -v grep | awk '{print $2}')
sleep 3 && ./start.sh 2181 2181
ps aux | grep QuorumPeerMain | grep -v grep | grep -oE '\-Xms[0-9]+m -Xmx[0-9]+m'

实测回显：

-Xms256m -Xmx512m

⚠️ 重启 ZooKeeper 后各组件需要重新注册（约 1 分钟内 hape gs havenask 回到 READY）。若 swift admin 停留在 NOT_READY 导致写入报 async writer timeout，按常见问题 9.3 执行 hape restart swift 恢复。

8.4 宿主机重启后的恢复

运行环境随宿主重启而停止。恢复步骤：先执行 havenask-120-runtime/stopContainer.sh 清掉残留（内容实测为 docker stop havenask-120-runtime;docker rm -fv havenask-120-runtime），再按 4.2 重新运行 create_container.sh（镜像已本地缓存，秒级完成），进入后执行 hape start havenask，最后 hape create table 校验表是否存在（表 schema 持久化在 /root/havenask/havenask_data_store，重启宿主不丢）。

九、常见问题（排障实录）

9.1 脚本报 useradd: user 'root' already exists

现象：运行 create_container.sh 时输出 useradd: user 'root' already exists、usermod: no changes。 定位：脚本会以当前登录用户 UID 在镜像内重建同名用户；root（UID 0）必然已存在。 解决：预期回显，无需处理；以末行 INFO start container success 判断成败。

9.2 启动后长时间 NOT_READY

现象：hape gs havenask 显示 clusterStatus: NOT_READY，hint 为 Group database Role database_partition_0 has unready containers...。 定位：searcher 未加载任何表（建表前的正常态）；hape start 日志里 swift/havenask/bs admin 均已 ready。 解决：直接执行建表命令（5.1），建表后自动转 READY，实测从建表到 READY 约 10 秒。

9.3 写入报 async writer timeout，hape gs swift 报 Swift admin not ready

现象：insert 返回 write message failed, table [in0], ec[gig has error, ... async writer timeout, timeoutInUs 10000000, checkpoint 1]，同时 hape gs swift 报 [ERROR] Swift admin not ready；swift admin 日志出现 write slot_launched_metas failed.。 定位：ZooKeeper 进程被强杀（如手工 kill）后，swift 的 hippo master 的 zk 会话失效且无法重写调度状态，broker 写入链路断裂；此时检索集群 gs 仍为 READY，但写入必超时。 解决：重启 swift 集群恢复：

/ha3_install/hape restart swift

实测回显（节选）：

[2026-10-23 18:48:38,679] [INFO] [docker_util.py:start_process:103]: Succeed to start process swift_admin
[2026-10-23 18:48:38,691] [INFO] [retry.py:retry:13]: Check [Swift admin is ready] succeed

恢复后复测写入：USE_TIME: 3726.947ms, ROW_COUNT: 1，查询 ROW_COUNT: 2（此前两条均已写入成功）。经验：永远不要手工 kill ZooKeeper 进程；确需重启 zk 时，重启后立即 hape restart swift + hape restart havenask。

9.4 TEXT 列查询显示 null

现象：select * from in0 中 title/subject 显示 null，但 id/hits/createtime 正常。 定位：TEXT 字段走全文索引与摘要链路，不在 ATTRIBUTE 投影里返回；该版本 SQL 字符串结果对 TEXT 列展示为 null。 解决：属展示层行为，不影响检索命中。全文检索用 query() 函数验证：

/ha3_install/sql_query.py --query "select id,hits from in0 where query('default','test')"

实测回显（命中此前写入的行）：

USE_TIME: 12.271ms, ROW_COUNT: 1, HAS_SOFT_FAILURE: 0, SOFT_FAILURE_CODES: [], COVERAGE: 1

另注意：match() 不是本 SQL 方言的合法函数，实测报 SqlParseException: Encountered "match"，全文条件一律用 query('索引名','词')。

9.5 实时写入的数据重启后消失

现象：hape restart havenask 后 select 行数变 0，重新 insert 后恢复。 定位：SQL insert 走实时写链路（swift → searcher 内存索引），未触发全量构建时数据不落盘。 解决：生产场景必须配置离线/全量数据源（hape create table -f <全量数据路径> 支持 offline table），或依赖集群周期性全量构建；测试场景重启后重新写入即可。

9.6 端口被占用

现象：hape start havenask 启动组件时失败或健康检查不通过。 定位：ss -ltnp 检查 2181/45700/45800/45801/45898-45901 是否被其他进程占用（--net=host 形态下冲突即失败）。 解决：释放端口，或修改 /ha3_install/hape_conf/default/global.conf（qrsHttpPort 等端口类参数由模板 cluster_templates/hippo/*.json 与全局变量共同决定，改动后删除集群重新 hape start）。

十、卸载与清理

按需逐级删除（--help 实测回显）：

# 删除单张表
/ha3_install/hape delete table -t in0
# 删除检索集群（停进程并清理 zk 与数据文件）
/ha3_install/hape delete havenask
# 删除 swift 集群
/ha3_install/hape delete swift
# 一次性删除全部（等价于上述合集，含 bs）
/ha3_install/hape delete all

$ /ha3_install/hape delete all --help
Usage: hape delete all [OPTIONS]

Options:
  -c, --config TEXT  Path of hape config. Will use default if not specified
  -v, --verbose      Enable debug level logging
  -h, --help         Show this message and exit.

最后删除运行环境本体（脚本目录自动生成的停止脚本）：

./havenask-120-runtime/stopContainer.sh

如需彻底清理本地镜像：docker rmi registry.cn-hangzhou.aliyuncs.com/havenask/ha3_runtime:1.2.0。

十一、参考链接

  1. 官方仓库 README（Get Started）：https://github.com/alibaba/havenask（查询日期 2026-10-23）
  2. v1.2.0 Release 发布件 create_container.sh：https://github.com/alibaba/havenask/releases/download/v1.2.0/create_container.sh
  3. GitHub Releases 页：https://github.com/alibaba/havenask/releases
  4. 官方文档站：https://havenask.net（快速开始与单机模式说明）
  5. 站内同类部署文档：《Elasticsearch 9.5.4 Docker Compose 部署指南》、《OpenSearch 2.x Docker Compose 部署指南》

站内相关：《Havenask 介绍与选型指南》、《Ubuntu 22.04 安装 Havenask 1.2.0 指南》、《Havenask 1.2.0 配置参数详解》、《Havenask 1.2.0 常用 CLI 命令详解》