1. 为什么是 OtterWiki 华为开发者空间——轻量知识库的“云上最小可行系统”我第一次在团队内部推动知识沉淀时踩过太多坑用 Confluence光装 Java 环境和调 JVM 参数就耗掉两天搭 WikiMediaPHP 扩展依赖像俄罗斯套娃改个皮肤都能让整个站点 500甚至试过 Notion 共享工作区结果权限颗粒度太粗敏感文档一不小心就发给了实习生。直到去年在华为开发者空间里用不到 12 分钟从零跑起一个带 Git 版本、Markdown 编辑、用户登录、附件上传的完整 Wiki我才真正理解什么叫“知识管理的最小可行系统”——它不追求功能堆砌而是在可维护性、安全性、协作效率之间找到那个精准的平衡点。OtterWiki 就是这个平衡点的具象化。它不是另一个臃肿的 CMS而是一个“以 Git 为硬盘、以 Markdown 为纸笔、以 Flask 为墨水”的极简写作引擎。它的核心逻辑非常干净你编辑的每一页都是一份.md文件每一次保存都是一次git commit每一次回滚就是一次git revert。这意味着你不需要额外学一套后台管理系统你的终端、VS Code、甚至手机上的 Git 客户端都是它的管理界面。而华为开发者空间则是这套逻辑最理想的承载平台——它不卖服务器它卖的是“开箱即用的开发状态”。你不需要关心 Ubuntu 是 22.04 还是 24.04不用纠结内核是否支持 overlay2更不必为 Docker Desktop 在 Windows 上的 WSL2 兼容性抓狂。你点一下“进入远程终端”一个预装好 git、curl、vim、基础 Python 的干净 Ubuntu 环境就摆在你面前就像把一台物理开发机直接搬上了云端。这背后的技术选型全是经过现实项目反复验证的。Docker Compose 不是为炫技而是因为它用一份docker-compose.yaml就锁定了整个应用栈的版本、端口、挂载路径和重启策略避免了“在我机器上能跑”的经典困境。restart: unless-stopped这个策略比always更务实——它意味着容器只在你主动停掉时才不重启而不会在系统升级后因依赖变化而陷入无限崩溃循环。至于 Markdown它早已不是“一种语法”而是一种协作契约前端工程师写接口文档用表格定义请求参数产品经理写需求 PRD用脚注标注决策依据运维同学写故障复盘用 Mermaid 画出时间线。当所有人默认用同一种“文字协议”沟通知识流转的成本就降到了最低。所以当你看到标题里并列出现“华为开发者空间”、“OtterWiki”、“Docker Compose”和“Markdown”这不是关键词堆砌而是一条被无数人走通的、从零到知识库上线的最短路径。2. 深度拆解部署架构为什么必须用 Docker Compose 而非单容器运行2.1 OtterWiki 的容器化本质与设计哲学OtterWiki 的官方镜像redimp/otterwiki:2并不是一个“全能型”单体镜像。它刻意剥离了所有与运行环境强耦合的组件只保留最核心的三样东西Python 3.9 运行时、Flask Web 框架、以及一个精简版的 Git 二进制文件。它不内置数据库如 SQLite 或 PostgreSQL也不自带 Web 服务器如 Nginx 或 Apache更不负责用户认证的持久化存储。这种“瘦容器”设计是 OtterWiki 团队对云原生时代运维范式的深刻理解容器不该是虚拟机的替代品而应是单一职责的执行单元。它的唯一使命就是接收 HTTP 请求读取/app-data目录下的 Markdown 文件和 Git 仓库然后渲染成 HTML 页面返回。这就引出了一个关键问题如果容器本身不存数据那用户的页面、历史记录、账号信息存在哪儿答案是——必须通过volumes挂载宿主机目录。但这里有个极易被忽略的陷阱OtterWiki 镜像内部的代码硬编码了数据目录为/app-data。如果你在docker run命令里写docker run -v /data/otterwiki:/data redimp/otterwiki:2容器启动后会发现/app-data是空的而/data里虽然有你的文件但程序根本不去读它。这就是为什么docker-compose.yaml中volumes的写法必须是- /data/otterwiki/data:/app-data左边是宿主机绝对路径右边是容器内绝对路径二者必须严格匹配。我第一次部署失败就是卡在这个映射上日志里反复报OSError: [Errno 2] No such file or directory: /app-data/wiki查了半小时才发现是路径写反了。2.2 Docker Compose 的不可替代性超越docker run的工程价值很多人会问既然docker run也能跑为什么非要多此一举写docker-compose.yaml答案藏在三个被低估的细节里。第一是端口映射的确定性。docker run -p 5600:80看似简单但一旦你后续想加一个监控侧车sidecar容器比如 Prometheus Exporter或者想给 OtterWiki 加个反向代理做 HTTPSdocker run的命令就会迅速膨胀成一行无法维护的“面条代码”。而docker-compose.yaml把端口、网络、依赖关系全部声明化。你只需在services.otterwiki.ports下加一行- 443:443再配个nginx服务整个 HTTPS 化就完成了无需动任何一行run命令。第二是重启策略的语义清晰度。docker run --restartalways听起来很可靠但它有个致命缺陷当宿主机重启而 Docker daemon 还没完全就绪时容器会尝试启动并失败然后进入指数退避重试可能卡在“starting”状态长达数分钟。restart: unless-stopped则完全不同——它告诉 Docker“只要我没被docker stop过你就一直拉起来”。这在华为开发者空间这种按小时计费的环境中至关重要你申请的 15 小时云主机绝不能因为一次意外断连就让 Wiki 服务离线半小时。第三是配置即代码的可追溯性。docker-compose.yaml是一个纯文本文件它可以被git add、git commit、git push。这意味着你对 Wiki 的每一次架构调整——比如把端口从5600改成8080或者把数据卷从/data换成/mnt/nas——都留下了完整的审计线索。而docker run命令一旦执行完就消失在 shell 历史里下次你想还原环境只能靠记忆或翻聊天记录。在团队协作中这种可追溯性就是知识管理系统的基石。提示docker-compose.yaml中restart: unless-stopped是生产环境的黄金标准它比always更可控比on-failure更鲁棒。切勿在学习阶段就盲目追求“always”那往往是线上事故的温床。2.3 华为开发者空间的底层优势为什么它比自建云服务器更省心华为开发者空间的“开箱即用”远不止于预装 Docker。它的底层是基于鲲鹏处理器的 ARM64 架构云主机而redimp/otterwiki:2镜像恰好提供了linux/arm64的多平台构建版本。这意味着你docker pull时Docker 会自动选择最适合当前 CPU 的镜像层无需手动指定--platform linux/arm64。我对比过在 x86_64 的阿里云 ECS 上部署同样的镜像由于需要 QEMU 模拟层启动时间慢了 40%内存占用高了 15%。更关键的是它的资源隔离机制。开发者空间的每个云主机实例都运行在一个轻量级的 Firecracker 微虚拟机中。这带来了两个隐形红利一是进程级隔离你的 OtterWiki 容器即使被恶意脚本打满 CPU也不会影响同一台物理服务器上其他用户的开发环境二是秒级快照你可以在部署前一键创建快照部署失败后 3 秒内回滚到之前状态。这在传统 VPS 上需要你手动dd整个磁盘耗时以分钟计。最后是网络模型的简洁性。开发者空间的云主机默认开启localhost的全端口访问。你docker compose up后直接在浏览器里打开http://localhost:5600就能访问无需像在公有云 ECS 上那样去安全组里放行 5600 端口再去 NACL 里检查入站规则。这种“本地即线上”的体验极大降低了新手的认知负荷。我带过的 7 个实习生有 5 个第一次部署就成功剩下的 2 个失败原因全是自己手误敲错了docker-compose.yaml的缩进——而不是被复杂的网络配置绕晕。3. 实操全流程详解从零开始的每一步意图与避坑指南3.1 环境初始化为什么apt install docker.io是最优解在华为开发者空间的 Ubuntu 环境中安装 Docker 有两个主流方案一是用官方脚本curl https://get.docker.com | sh二是用系统包管理器apt install docker.io。我强烈推荐后者理由有三。第一是兼容性保障。华为开发者空间的 Ubuntu 镜像是深度定制的内核版本5.15.0-107-generic和 systemd 版本249都经过华为云团队的长期测试。docker.io包是 Ubuntu 官方仓库为该特定内核版本编译的而官方 Docker 脚本默认安装的是最新版docker-ce它可能依赖更新的libseccomp库导致dockerd启动时报failed to start daemon: error initializing graphdriver: driver not supported。我亲身经历过一次脚本安装后systemctl status docker显示active (exited)但docker ps报错折腾了 40 分钟才发现是库版本冲突。第二是镜像加速的无缝集成。docker.io包安装后/etc/docker/daemon.json文件是空的你可以放心写入华为云 SWR软件仓库的镜像地址。但如果你用官方脚本安装它可能会在/etc/docker/daemon.json里预先写入https://registry-1.docker.io而这个地址在华为云内网并不优化会导致docker pull速度慢如蜗牛。更糟的是有些旧版docker-ce会把镜像加速配置写在/etc/default/docker里和daemon.json冲突最终docker info里显示的Registry Mirrors是空的。第三是权限模型的清晰性。apt install docker.io会自动创建docker用户组并把dockerd服务加入systemd。而官方脚本有时会跳过这步你需要手动sudo usermod -aG docker $USER然后newgrp docker。但newgrp命令有个坑它会启动一个全新的子 shell你在当前终端里执行newgrp docker后docker ps可能还是报permission denied因为你还在原来的 shell 里。正确做法是退出终端重新登录或者直接exec su -l $USER切换会话。这个细节90% 的教程都不会提但它是新手卡住的最高发原因。注意执行sudo usermod -aG docker $USER后务必关闭当前终端窗口重新打开一个新的远程终端窗口。不要试图在同一个窗口里用newgrp docker那只会让你陷入“以为生效了其实没生效”的幻觉。3.2 Docker Compose 的 ARM64 适配为什么必须下载linux-aarch64版本华为开发者空间的云主机是 ARM64 架构这是它和普通 x86_64 云服务器的根本区别。Docker Compose 作为一个 Go 语言编译的二进制文件必须与 CPU 架构严格匹配。如果你错误地下载了linux-x86_64版本执行docker compose version时会得到一个极其隐晦的错误bash: /home/developer/.docker/cli-plugins/docker-compose: cannot execute binary file: Exec format error。这个错误不会告诉你“架构不匹配”只会说“不能执行二进制文件”新手很容易误以为是权限问题反复chmod x徒劳无功。正确的下载地址必须是 GitHub Releases 页面上明确标注aarch64的版本。截至本文撰写时最新稳定版是v2.40.3其 ARM64 下载链接为https://github.com/docker/compose/releases/download/v2.40.3/docker-compose-linux-aarch64。注意 URL 末尾是aarch64不是arm64也不是amd64。这个命名规范是 Docker 官方定的aarch64是 Linux 社区对 ARM64 的标准称呼。下载后必须将二进制文件放到~/.docker/cli-plugins/目录下并命名为docker-compose不带.exe或其他后缀。Docker CLI 会自动扫描这个目录把里面的可执行文件识别为子命令。如果你把它放在/usr/local/bin下docker compose命令会失效因为 Docker CLI 只认cli-plugins目录。我第一次部署时就因为图省事sudo cp到了/usr/local/bin结果docker compose version一直报command not found查了 Docker 官方文档才明白这个插件机制的约定。实操心得下载完成后务必执行file ~/.docker/cli-plugins/docker-compose命令。正常输出应该是ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), statically linked, Go BuildID..., stripped。如果看到x86-64字样说明你下错了版本立刻删掉重下。3.3docker-compose.yaml的魔鬼细节缩进、引号与路径的生死线YAML 是一门优雅的语言但也是一门对空格极其苛刻的语言。docker-compose.yaml文件里一个空格的错误就能让整个部署失败。我整理了新手最容易栽跟头的三个细节第一缩进必须用空格严禁 Tab 键。YAML 规范明确规定缩进只能用空格Tab 字符会被解析器视为非法。Vim 默认会把 Tab 转为空格但如果你用的是 Nano 或其他编辑器按 Tab 键插入的可能是真正的\t字符。docker compose config命令会帮你校验但它的错误提示非常不友好yaml.scanner.ScannerError: while scanning for the next token found character \t that cannot start any token。这个错误信息里“\t” 就是罪魁祸首。解决方案很简单在编辑器里开启“显示不可见字符”模式确保所有缩进都是空格。第二字符串值是否加引号有严格语义。看这两行ports: - 5600:80 - 5600:80它们看起来一样但含义不同。不加引号的5600:80YAML 解析器会把它当作一个整数对而加了引号的5600:80则被当作字符串。在大多数情况下Docker Compose 两者都能处理。但如果你的端口映射里包含变量比如${PORT}:80就必须加引号否则 YAML 会把$当作特殊字符报错。所以养成习惯所有ports、environment、volumes的值一律用双引号包裹一劳永逸。第三路径必须是绝对路径且宿主机路径要提前创建。volumes的写法- /data/otterwiki/data:/app-data左边/data/otterwiki/data必须是宿主机上真实存在的目录。如果你只写了- /data/otterwiki:/app-data而/data/otterwiki目录不存在Docker Compose 会静默地为你创建一个空目录但这个目录的属主是root而 OtterWiki 容器内的进程是以www-data用户身份运行的它没有权限往root目录里写文件结果就是容器启动后立即崩溃日志里全是Permission denied。正确流程是先sudo mkdir -p /data/otterwiki/data再sudo chown -R $USER:$USER /data/otterwiki最后再docker compose up。常见问题速查表现象可能原因排查命令docker compose up后ps显示Exit 1volumes 路径不存在或权限不足ls -ld /data/otterwiki/data浏览器打不开localhost:5600容器没启动或端口映射错误docker compose psnetstat -tuln | grep 5600页面加载后空白控制台报 404/app-data目录为空OtterWiki 没初始化docker exec -it otterwiki-otterwiki-1 ls -l /app-data3.4 首次启动与初始化OtterWiki 的“冷启动”仪式感docker compose up -d命令执行后你以为就结束了不OtterWiki 有一个关键的“冷启动”过程它需要你主动触发第一次访问才能完成内部初始化。当你第一次在浏览器里打开http://localhost:5600OtterWiki 容器会做三件事第一检查/app-data目录下是否存在wiki子目录如果不存在就创建一个空的 Git 仓库第二生成一个初始的index.md页面内容是 “Welcome to OtterWiki!”第三把这次操作作为一个git commit提交到仓库。这个过程大约需要 3-5 秒期间浏览器会显示一个空白页或加载动画。如果你在这几秒内刷新页面或者关掉浏览器初始化就会中断/app-data/wiki目录会残留一个不完整的 Git 仓库导致后续所有操作都失败。我遇到过最诡异的一次是初始化中途断网/app-data/wiki里只剩一个.git/index.lock文件。docker exec进容器里rm .git/index.lock也无效因为 Git 认为仓库处于损坏状态。最终解决方案是docker compose down停掉容器sudo rm -rf /data/otterwiki/data/*彻底清空数据目录再docker compose up -d重来。所以首次访问请保持耐心不要刷新不要关闭让它安静地完成自己的“加冕礼”。初始化完成后首页右上角会出现 “Login” 按钮。点击它你会进入注册页面。这里有个重要提示OtterWiki 的初始管理员账号不是在docker-compose.yaml里配置的而是你在注册时自己填写的。用户名、邮箱、密码全部由你决定。注册成功后你自动成为拥有全部权限的管理员。这个设计很人性化——它避免了把密码明文写在配置文件里的安全风险也符合“最小权限原则”。4. 核心功能实战与深度技巧让 OtterWiki 真正成为你的知识中枢4.1 Markdown 的进阶玩法超越基础语法的生产力组合OtterWiki 对 Markdown 的支持远不止于加粗、列表和链接。它集成了多个扩展把这些零散的语法糖变成了结构化知识的构建模块。Mermaid 图表是最常被低估的功能。在 OtterWiki 里你不需要安装任何插件只需在 Markdown 正文中输入 mermaid graph TD A[需求分析] -- B[原型设计] B -- C[开发实现] C -- D[测试验收] D -- E[上线发布] 保存后页面就会自动渲染成一张矢量流程图。这比截图粘贴的优势在于图表是纯文本可以被 Git 追踪、被diff比较、被grep搜索。当产品需求变更时你只需要修改这几行文本整个流程图就同步更新再也不用打开 Visio 或 draw.io 重新导出图片。脚注Footnotes则是学术写作和严谨文档的利器。在页面底部添加[^1]: 这是第一个脚注的详细解释可以很长包含链接 [参考文献](https://example.com)。 [^2]: 这是第二个脚注用于标注数据来源。然后在正文任意位置引用[^1]和[^2]。OtterWiki 会自动把脚注收集到页面底部并生成对应的上标数字和跳转链接。这让你的文档既有可读性又有可验证性。警告框Admonitions是团队协作的润滑剂。OtterWiki 支持 [!NOTE]、 [!WARNING]、 [!TIP]三种类型。例如[!WARNING] 此 API 接口将于 2025 年 12 月 31 日下线请所有调用方在截止日期前完成迁移。这种格式会被渲染成一个带图标的醒目色块比单纯的**WARNING:**文字更能抓住读者注意力。我在团队的接口文档里大量使用它把“已知问题”、“临时方案”、“紧急通知”都用不同颜色的警告框区分新人入职三天就能快速识别风险点。实操心得所有这些扩展语法都依赖于 OtterWiki 内置的markdown-it解析器。它默认启用无需额外配置。但要注意Mermaid 图表的语法必须用\mermaid开头不能用\否则会被当作普通代码块。4.2 Git 版本控制的日常实践如何像管理代码一样管理知识OtterWiki 的灵魂在于它把 Wiki 页面当作了 Git 仓库里的文件。这意味着你日常的每一个知识操作都可以对应到一个 Git 命令。查看历史在任意页面右上角点击 “History” 按钮你会看到一个按时间倒序排列的提交列表。每一项都显示了提交者、提交时间、提交信息即你保存时填写的摘要和一个 “Diff” 链接。点击 “Diff”就能看到这次修改前后的内容差异精确到每一行。这比 Confluence 的“版本对比”直观得多因为它是真正的git diff输出。回滚到旧版本找到你想恢复的那次提交点击右侧的 “Revert” 按钮。OtterWiki 会执行git revert commit-hash生成一个新的提交把页面内容恢复到那个时间点的状态。这个操作是安全的因为它不会删除任何历史只是增加了一个“反向操作”的新提交。批量操作与终端直连这才是 Git 的真正威力所在。cd /data/otterwiki/data然后git status你会发现这里就是一个标准的 Git 仓库。你可以git log --oneline -10查看最近 10 次提交git branch查看分支默认只有main甚至git checkout commit-hash临时切换到某个历史状态用 VS Code 打开整个wiki目录进行跨页面的全局搜索和替换。我曾用这个方法一次性把团队文档里所有过时的 API 地址替换成新的域名整个过程不到 2 分钟。注意直接在宿主机上用git命令操作/data/otterwiki/data目录是安全的OtterWiki 会自动检测到文件变化并刷新缓存。但切记不要在容器内执行git命令因为容器内的git是精简版缺少git gc等维护命令长期运行可能导致仓库性能下降。4.3 权限与安全的务实配置小团队的最小权限模型OtterWiki 的权限系统设计得非常务实。它没有 RBAC基于角色的访问控制那么复杂而是采用了“用户组 页面级权限”的两级模型。用户组Groups是权限的容器。默认有admin和user两个组。admin组成员可以创建用户、管理组、编辑所有页面user组成员只能编辑自己创建的页面或被授权的页面。创建新用户时你必须为其指定一个组。这个设计的好处是权限是继承的你不需要为每个用户单独设置只需要把他们加入合适的组。页面级权限Page Permissions是精细化控制的关键。在任意页面的右上角点击 “Settings” “Permissions”你可以为这个页面设置Read谁可以查看all、logged-in users、group:adminEdit谁可以编辑同上Delete谁可以删除同上我给团队设定的最小权限模型是所有公共文档如技术规范、API 文档的Read设为allEdit设为group:admin所有个人笔记如会议纪要、学习笔记的Read和Edit都设为user:username即只有创建者本人能看能改。这样既保证了知识的开放共享又保护了个人的隐私边界。提示OtterWiki 的登录系统是基于 Session 的它不依赖外部数据库。所有用户信息都存储在/app-data/users.json文件里这个文件同样受 Git 版本控制。所以如果你误删了一个用户只要git log还在就能从历史提交里找回users.json的旧版本完美恢复。5. 常见问题排查与独家避坑经验实录5.1 容器健康状态异常healthy状态背后的真相docker compose ps的输出里STATUS 列显示Up 10 minutes (healthy)这通常是个好消息。但有时候你会看到Up 10 minutes (unhealthy)或者干脆没有(healthy)字样。这背后的原因往往不是 OtterWiki 本身的问题而是 Docker 的健康检查机制在“吹毛求疵”。OtterWiki 镜像的Dockerfile里定义了一个健康检查命令HEALTHCHECK --interval30s --timeout3s --start-period5s --retries3 CMD curl -f http://localhost:80/health || exit 1。这个命令的意思是每 30 秒用curl访问容器内部的/health端点如果 3 秒内没返回 HTTP 200就重试 3 次3 次都失败就标记为unhealthy。问题来了OtterWiki 的官方镜像并没有实现/health这个端点它的 Flask 应用根路径/是首页/login是登录页但就是没有/health。所以这个健康检查命令永远会失败。这不是 Bug而是镜像作者的一个“留白”——他假设用户会自己覆盖这个检查。解决方案有两个方案一推荐在docker-compose.yaml里显式覆盖健康检查services: otterwiki: # ... 其他配置 healthcheck: test: [CMD, curl, -f, http://localhost:80/] interval: 30s timeout: 10s retries: 3 start_period: 40s这里把测试目标从/health改成了/也就是首页。只要首页能返回 200就认为服务健康。方案二极简直接禁用健康检查services: otterwiki: # ... 其他配置 healthcheck: disable: true我选择方案一因为/端点的可用性确实能反映 OtterWiki 的核心服务能力。而方案二虽然简单但失去了一个有用的监控信号。5.2 数据持久化的终极验证如何确认你的知识真的“活”在 Git 里很多新手会有一个挥之不去的疑虑“我的页面真的存到 Git 里了吗万一容器删了数据会不会丢” 这个疑虑非常合理验证方法也很直接。第一步docker exec -it otterwiki-otterwiki-1 bash进入容器内部。 第二步cd /app-data然后ls -la。你应该能看到wiki/、users.json、config.py等文件和目录。 第三步cd wiki然后git status。如果一切正常输出应该是On branch main nothing to commit, working tree clean。 第四步git log --oneline -5。你应该能看到最近几次页面编辑的提交记录每一条都对应着你在 Web 界面上的一次“Save”。但最关键的验证是在宿主机上操作。退出容器回到宿主机终端cd /data/otterwiki/data然后重复git status和git log。你会发现输出和容器内一模一样。这证明了volumes挂载是双向实时的容器内对 Git 仓库的任何操作都会 100% 同步到宿主机目录。我曾经做过一个破坏性实验在容器内git reset --hard HEAD~1把最新一次提交回滚掉。然后刷新网页发现刚刚编辑的页面真的变回了上一个版本。这让我彻底相信OtterWiki 不是“把 Git 当备份”而是“把 Git 当数据库”。独家避坑技巧定期在宿主机上执行git gc。/data/otterwiki/data/wiki目录下的 Git 仓库随着页面增多会产生大量松散对象loose objects。git gc会把这些对象打包成 pack 文件大幅减小仓库体积提升git log和git diff的速度。我设置了一个 cron 任务每天凌晨 2 点执行cd /data/otterwiki/data/wiki git gc --prunenow。5.3 华为开发者空间的时长管理如何让 180 小时用得更久华为开发者空间的 180 小时免费资源是按“云主机实例”的运行时间计算的而不是按“Docker 容器”的运行时间。这意味着只要你云主机开着无论里面跑一个容器还是十个容器都在消耗时长。所以最高效的用法是把云主机当成你的“个人云工作站”而不是“单次部署服务器”。我给自己定的规则是每次进入开发者空间先docker compose up -d启动 OtterWiki以及其他常用服务如 VS Code Server。工作期间所有知识编辑、文档查阅、Git 操作都在localhost:5600上完成。工作结束不关机而是docker compose stop停掉所有容器。云主机仍在运行但不再消耗算力CPU 和内存归零只消耗极低的“待机”费用几乎为零。下次需要时docker compose start一键唤醒几秒钟就回到工作状态。这个模式让我把 180 小时用出了 300 小时的效果。因为docker compose stop/start的开销远小于shutdown/startup云主机的开销。后者需要重新加载内核、初始化网络、启动 systemd 服务平均耗时 90 秒而前者只是发送一个SIGTERM信号容器进程瞬间响应。最后一个小技巧在华为开发者空间控制台点击云主机右侧的 “更多” “延时”可以手动延长当前会话。但这个功能有次数限制。更聪明的做法是在~/.bashrc里加一行alias keepalivecurl -s https://developer.huaweicloud.com/keepalive /dev/null 21然后每隔 55 分钟执行一次keepalive。这个心跳请求能有效阻止系统因闲置而自动释放资源。这是我从华为云工程师那里偷师来的“民间秘籍”。
1. 为什么是 OtterWiki 华为开发者空间——轻量知识库的“云上最小可行系统”我第一次在团队内部推动知识沉淀时踩过太多坑用 Confluence光装 Java 环境和调 JVM 参数就耗掉两天搭 WikiMediaPHP 扩展依赖像俄罗斯套娃改个皮肤都能让整个站点 500甚至试过 Notion 共享工作区结果权限颗粒度太粗敏感文档一不小心就发给了实习生。直到去年在华为开发者空间里用不到 12 分钟从零跑起一个带 Git 版本、Markdown 编辑、用户登录、附件上传的完整 Wiki我才真正理解什么叫“知识管理的最小可行系统”——它不追求功能堆砌而是在可维护性、安全性、协作效率之间找到那个精准的平衡点。OtterWiki 就是这个平衡点的具象化。它不是另一个臃肿的 CMS而是一个“以 Git 为硬盘、以 Markdown 为纸笔、以 Flask 为墨水”的极简写作引擎。它的核心逻辑非常干净你编辑的每一页都是一份.md文件每一次保存都是一次git commit每一次回滚就是一次git revert。这意味着你不需要额外学一套后台管理系统你的终端、VS Code、甚至手机上的 Git 客户端都是它的管理界面。而华为开发者空间则是这套逻辑最理想的承载平台——它不卖服务器它卖的是“开箱即用的开发状态”。你不需要关心 Ubuntu 是 22.04 还是 24.04不用纠结内核是否支持 overlay2更不必为 Docker Desktop 在 Windows 上的 WSL2 兼容性抓狂。你点一下“进入远程终端”一个预装好 git、curl、vim、基础 Python 的干净 Ubuntu 环境就摆在你面前就像把一台物理开发机直接搬上了云端。这背后的技术选型全是经过现实项目反复验证的。Docker Compose 不是为炫技而是因为它用一份docker-compose.yaml就锁定了整个应用栈的版本、端口、挂载路径和重启策略避免了“在我机器上能跑”的经典困境。restart: unless-stopped这个策略比always更务实——它意味着容器只在你主动停掉时才不重启而不会在系统升级后因依赖变化而陷入无限崩溃循环。至于 Markdown它早已不是“一种语法”而是一种协作契约前端工程师写接口文档用表格定义请求参数产品经理写需求 PRD用脚注标注决策依据运维同学写故障复盘用 Mermaid 画出时间线。当所有人默认用同一种“文字协议”沟通知识流转的成本就降到了最低。所以当你看到标题里并列出现“华为开发者空间”、“OtterWiki”、“Docker Compose”和“Markdown”这不是关键词堆砌而是一条被无数人走通的、从零到知识库上线的最短路径。2. 深度拆解部署架构为什么必须用 Docker Compose 而非单容器运行2.1 OtterWiki 的容器化本质与设计哲学OtterWiki 的官方镜像redimp/otterwiki:2并不是一个“全能型”单体镜像。它刻意剥离了所有与运行环境强耦合的组件只保留最核心的三样东西Python 3.9 运行时、Flask Web 框架、以及一个精简版的 Git 二进制文件。它不内置数据库如 SQLite 或 PostgreSQL也不自带 Web 服务器如 Nginx 或 Apache更不负责用户认证的持久化存储。这种“瘦容器”设计是 OtterWiki 团队对云原生时代运维范式的深刻理解容器不该是虚拟机的替代品而应是单一职责的执行单元。它的唯一使命就是接收 HTTP 请求读取/app-data目录下的 Markdown 文件和 Git 仓库然后渲染成 HTML 页面返回。这就引出了一个关键问题如果容器本身不存数据那用户的页面、历史记录、账号信息存在哪儿答案是——必须通过volumes挂载宿主机目录。但这里有个极易被忽略的陷阱OtterWiki 镜像内部的代码硬编码了数据目录为/app-data。如果你在docker run命令里写docker run -v /data/otterwiki:/data redimp/otterwiki:2容器启动后会发现/app-data是空的而/data里虽然有你的文件但程序根本不去读它。这就是为什么docker-compose.yaml中volumes的写法必须是- /data/otterwiki/data:/app-data左边是宿主机绝对路径右边是容器内绝对路径二者必须严格匹配。我第一次部署失败就是卡在这个映射上日志里反复报OSError: [Errno 2] No such file or directory: /app-data/wiki查了半小时才发现是路径写反了。2.2 Docker Compose 的不可替代性超越docker run的工程价值很多人会问既然docker run也能跑为什么非要多此一举写docker-compose.yaml答案藏在三个被低估的细节里。第一是端口映射的确定性。docker run -p 5600:80看似简单但一旦你后续想加一个监控侧车sidecar容器比如 Prometheus Exporter或者想给 OtterWiki 加个反向代理做 HTTPSdocker run的命令就会迅速膨胀成一行无法维护的“面条代码”。而docker-compose.yaml把端口、网络、依赖关系全部声明化。你只需在services.otterwiki.ports下加一行- 443:443再配个nginx服务整个 HTTPS 化就完成了无需动任何一行run命令。第二是重启策略的语义清晰度。docker run --restartalways听起来很可靠但它有个致命缺陷当宿主机重启而 Docker daemon 还没完全就绪时容器会尝试启动并失败然后进入指数退避重试可能卡在“starting”状态长达数分钟。restart: unless-stopped则完全不同——它告诉 Docker“只要我没被docker stop过你就一直拉起来”。这在华为开发者空间这种按小时计费的环境中至关重要你申请的 15 小时云主机绝不能因为一次意外断连就让 Wiki 服务离线半小时。第三是配置即代码的可追溯性。docker-compose.yaml是一个纯文本文件它可以被git add、git commit、git push。这意味着你对 Wiki 的每一次架构调整——比如把端口从5600改成8080或者把数据卷从/data换成/mnt/nas——都留下了完整的审计线索。而docker run命令一旦执行完就消失在 shell 历史里下次你想还原环境只能靠记忆或翻聊天记录。在团队协作中这种可追溯性就是知识管理系统的基石。提示docker-compose.yaml中restart: unless-stopped是生产环境的黄金标准它比always更可控比on-failure更鲁棒。切勿在学习阶段就盲目追求“always”那往往是线上事故的温床。2.3 华为开发者空间的底层优势为什么它比自建云服务器更省心华为开发者空间的“开箱即用”远不止于预装 Docker。它的底层是基于鲲鹏处理器的 ARM64 架构云主机而redimp/otterwiki:2镜像恰好提供了linux/arm64的多平台构建版本。这意味着你docker pull时Docker 会自动选择最适合当前 CPU 的镜像层无需手动指定--platform linux/arm64。我对比过在 x86_64 的阿里云 ECS 上部署同样的镜像由于需要 QEMU 模拟层启动时间慢了 40%内存占用高了 15%。更关键的是它的资源隔离机制。开发者空间的每个云主机实例都运行在一个轻量级的 Firecracker 微虚拟机中。这带来了两个隐形红利一是进程级隔离你的 OtterWiki 容器即使被恶意脚本打满 CPU也不会影响同一台物理服务器上其他用户的开发环境二是秒级快照你可以在部署前一键创建快照部署失败后 3 秒内回滚到之前状态。这在传统 VPS 上需要你手动dd整个磁盘耗时以分钟计。最后是网络模型的简洁性。开发者空间的云主机默认开启localhost的全端口访问。你docker compose up后直接在浏览器里打开http://localhost:5600就能访问无需像在公有云 ECS 上那样去安全组里放行 5600 端口再去 NACL 里检查入站规则。这种“本地即线上”的体验极大降低了新手的认知负荷。我带过的 7 个实习生有 5 个第一次部署就成功剩下的 2 个失败原因全是自己手误敲错了docker-compose.yaml的缩进——而不是被复杂的网络配置绕晕。3. 实操全流程详解从零开始的每一步意图与避坑指南3.1 环境初始化为什么apt install docker.io是最优解在华为开发者空间的 Ubuntu 环境中安装 Docker 有两个主流方案一是用官方脚本curl https://get.docker.com | sh二是用系统包管理器apt install docker.io。我强烈推荐后者理由有三。第一是兼容性保障。华为开发者空间的 Ubuntu 镜像是深度定制的内核版本5.15.0-107-generic和 systemd 版本249都经过华为云团队的长期测试。docker.io包是 Ubuntu 官方仓库为该特定内核版本编译的而官方 Docker 脚本默认安装的是最新版docker-ce它可能依赖更新的libseccomp库导致dockerd启动时报failed to start daemon: error initializing graphdriver: driver not supported。我亲身经历过一次脚本安装后systemctl status docker显示active (exited)但docker ps报错折腾了 40 分钟才发现是库版本冲突。第二是镜像加速的无缝集成。docker.io包安装后/etc/docker/daemon.json文件是空的你可以放心写入华为云 SWR软件仓库的镜像地址。但如果你用官方脚本安装它可能会在/etc/docker/daemon.json里预先写入https://registry-1.docker.io而这个地址在华为云内网并不优化会导致docker pull速度慢如蜗牛。更糟的是有些旧版docker-ce会把镜像加速配置写在/etc/default/docker里和daemon.json冲突最终docker info里显示的Registry Mirrors是空的。第三是权限模型的清晰性。apt install docker.io会自动创建docker用户组并把dockerd服务加入systemd。而官方脚本有时会跳过这步你需要手动sudo usermod -aG docker $USER然后newgrp docker。但newgrp命令有个坑它会启动一个全新的子 shell你在当前终端里执行newgrp docker后docker ps可能还是报permission denied因为你还在原来的 shell 里。正确做法是退出终端重新登录或者直接exec su -l $USER切换会话。这个细节90% 的教程都不会提但它是新手卡住的最高发原因。注意执行sudo usermod -aG docker $USER后务必关闭当前终端窗口重新打开一个新的远程终端窗口。不要试图在同一个窗口里用newgrp docker那只会让你陷入“以为生效了其实没生效”的幻觉。3.2 Docker Compose 的 ARM64 适配为什么必须下载linux-aarch64版本华为开发者空间的云主机是 ARM64 架构这是它和普通 x86_64 云服务器的根本区别。Docker Compose 作为一个 Go 语言编译的二进制文件必须与 CPU 架构严格匹配。如果你错误地下载了linux-x86_64版本执行docker compose version时会得到一个极其隐晦的错误bash: /home/developer/.docker/cli-plugins/docker-compose: cannot execute binary file: Exec format error。这个错误不会告诉你“架构不匹配”只会说“不能执行二进制文件”新手很容易误以为是权限问题反复chmod x徒劳无功。正确的下载地址必须是 GitHub Releases 页面上明确标注aarch64的版本。截至本文撰写时最新稳定版是v2.40.3其 ARM64 下载链接为https://github.com/docker/compose/releases/download/v2.40.3/docker-compose-linux-aarch64。注意 URL 末尾是aarch64不是arm64也不是amd64。这个命名规范是 Docker 官方定的aarch64是 Linux 社区对 ARM64 的标准称呼。下载后必须将二进制文件放到~/.docker/cli-plugins/目录下并命名为docker-compose不带.exe或其他后缀。Docker CLI 会自动扫描这个目录把里面的可执行文件识别为子命令。如果你把它放在/usr/local/bin下docker compose命令会失效因为 Docker CLI 只认cli-plugins目录。我第一次部署时就因为图省事sudo cp到了/usr/local/bin结果docker compose version一直报command not found查了 Docker 官方文档才明白这个插件机制的约定。实操心得下载完成后务必执行file ~/.docker/cli-plugins/docker-compose命令。正常输出应该是ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), statically linked, Go BuildID..., stripped。如果看到x86-64字样说明你下错了版本立刻删掉重下。3.3docker-compose.yaml的魔鬼细节缩进、引号与路径的生死线YAML 是一门优雅的语言但也是一门对空格极其苛刻的语言。docker-compose.yaml文件里一个空格的错误就能让整个部署失败。我整理了新手最容易栽跟头的三个细节第一缩进必须用空格严禁 Tab 键。YAML 规范明确规定缩进只能用空格Tab 字符会被解析器视为非法。Vim 默认会把 Tab 转为空格但如果你用的是 Nano 或其他编辑器按 Tab 键插入的可能是真正的\t字符。docker compose config命令会帮你校验但它的错误提示非常不友好yaml.scanner.ScannerError: while scanning for the next token found character \t that cannot start any token。这个错误信息里“\t” 就是罪魁祸首。解决方案很简单在编辑器里开启“显示不可见字符”模式确保所有缩进都是空格。第二字符串值是否加引号有严格语义。看这两行ports: - 5600:80 - 5600:80它们看起来一样但含义不同。不加引号的5600:80YAML 解析器会把它当作一个整数对而加了引号的5600:80则被当作字符串。在大多数情况下Docker Compose 两者都能处理。但如果你的端口映射里包含变量比如${PORT}:80就必须加引号否则 YAML 会把$当作特殊字符报错。所以养成习惯所有ports、environment、volumes的值一律用双引号包裹一劳永逸。第三路径必须是绝对路径且宿主机路径要提前创建。volumes的写法- /data/otterwiki/data:/app-data左边/data/otterwiki/data必须是宿主机上真实存在的目录。如果你只写了- /data/otterwiki:/app-data而/data/otterwiki目录不存在Docker Compose 会静默地为你创建一个空目录但这个目录的属主是root而 OtterWiki 容器内的进程是以www-data用户身份运行的它没有权限往root目录里写文件结果就是容器启动后立即崩溃日志里全是Permission denied。正确流程是先sudo mkdir -p /data/otterwiki/data再sudo chown -R $USER:$USER /data/otterwiki最后再docker compose up。常见问题速查表现象可能原因排查命令docker compose up后ps显示Exit 1volumes 路径不存在或权限不足ls -ld /data/otterwiki/data浏览器打不开localhost:5600容器没启动或端口映射错误docker compose psnetstat -tuln | grep 5600页面加载后空白控制台报 404/app-data目录为空OtterWiki 没初始化docker exec -it otterwiki-otterwiki-1 ls -l /app-data3.4 首次启动与初始化OtterWiki 的“冷启动”仪式感docker compose up -d命令执行后你以为就结束了不OtterWiki 有一个关键的“冷启动”过程它需要你主动触发第一次访问才能完成内部初始化。当你第一次在浏览器里打开http://localhost:5600OtterWiki 容器会做三件事第一检查/app-data目录下是否存在wiki子目录如果不存在就创建一个空的 Git 仓库第二生成一个初始的index.md页面内容是 “Welcome to OtterWiki!”第三把这次操作作为一个git commit提交到仓库。这个过程大约需要 3-5 秒期间浏览器会显示一个空白页或加载动画。如果你在这几秒内刷新页面或者关掉浏览器初始化就会中断/app-data/wiki目录会残留一个不完整的 Git 仓库导致后续所有操作都失败。我遇到过最诡异的一次是初始化中途断网/app-data/wiki里只剩一个.git/index.lock文件。docker exec进容器里rm .git/index.lock也无效因为 Git 认为仓库处于损坏状态。最终解决方案是docker compose down停掉容器sudo rm -rf /data/otterwiki/data/*彻底清空数据目录再docker compose up -d重来。所以首次访问请保持耐心不要刷新不要关闭让它安静地完成自己的“加冕礼”。初始化完成后首页右上角会出现 “Login” 按钮。点击它你会进入注册页面。这里有个重要提示OtterWiki 的初始管理员账号不是在docker-compose.yaml里配置的而是你在注册时自己填写的。用户名、邮箱、密码全部由你决定。注册成功后你自动成为拥有全部权限的管理员。这个设计很人性化——它避免了把密码明文写在配置文件里的安全风险也符合“最小权限原则”。4. 核心功能实战与深度技巧让 OtterWiki 真正成为你的知识中枢4.1 Markdown 的进阶玩法超越基础语法的生产力组合OtterWiki 对 Markdown 的支持远不止于加粗、列表和链接。它集成了多个扩展把这些零散的语法糖变成了结构化知识的构建模块。Mermaid 图表是最常被低估的功能。在 OtterWiki 里你不需要安装任何插件只需在 Markdown 正文中输入 mermaid graph TD A[需求分析] -- B[原型设计] B -- C[开发实现] C -- D[测试验收] D -- E[上线发布] 保存后页面就会自动渲染成一张矢量流程图。这比截图粘贴的优势在于图表是纯文本可以被 Git 追踪、被diff比较、被grep搜索。当产品需求变更时你只需要修改这几行文本整个流程图就同步更新再也不用打开 Visio 或 draw.io 重新导出图片。脚注Footnotes则是学术写作和严谨文档的利器。在页面底部添加[^1]: 这是第一个脚注的详细解释可以很长包含链接 [参考文献](https://example.com)。 [^2]: 这是第二个脚注用于标注数据来源。然后在正文任意位置引用[^1]和[^2]。OtterWiki 会自动把脚注收集到页面底部并生成对应的上标数字和跳转链接。这让你的文档既有可读性又有可验证性。警告框Admonitions是团队协作的润滑剂。OtterWiki 支持 [!NOTE]、 [!WARNING]、 [!TIP]三种类型。例如[!WARNING] 此 API 接口将于 2025 年 12 月 31 日下线请所有调用方在截止日期前完成迁移。这种格式会被渲染成一个带图标的醒目色块比单纯的**WARNING:**文字更能抓住读者注意力。我在团队的接口文档里大量使用它把“已知问题”、“临时方案”、“紧急通知”都用不同颜色的警告框区分新人入职三天就能快速识别风险点。实操心得所有这些扩展语法都依赖于 OtterWiki 内置的markdown-it解析器。它默认启用无需额外配置。但要注意Mermaid 图表的语法必须用\mermaid开头不能用\否则会被当作普通代码块。4.2 Git 版本控制的日常实践如何像管理代码一样管理知识OtterWiki 的灵魂在于它把 Wiki 页面当作了 Git 仓库里的文件。这意味着你日常的每一个知识操作都可以对应到一个 Git 命令。查看历史在任意页面右上角点击 “History” 按钮你会看到一个按时间倒序排列的提交列表。每一项都显示了提交者、提交时间、提交信息即你保存时填写的摘要和一个 “Diff” 链接。点击 “Diff”就能看到这次修改前后的内容差异精确到每一行。这比 Confluence 的“版本对比”直观得多因为它是真正的git diff输出。回滚到旧版本找到你想恢复的那次提交点击右侧的 “Revert” 按钮。OtterWiki 会执行git revert commit-hash生成一个新的提交把页面内容恢复到那个时间点的状态。这个操作是安全的因为它不会删除任何历史只是增加了一个“反向操作”的新提交。批量操作与终端直连这才是 Git 的真正威力所在。cd /data/otterwiki/data然后git status你会发现这里就是一个标准的 Git 仓库。你可以git log --oneline -10查看最近 10 次提交git branch查看分支默认只有main甚至git checkout commit-hash临时切换到某个历史状态用 VS Code 打开整个wiki目录进行跨页面的全局搜索和替换。我曾用这个方法一次性把团队文档里所有过时的 API 地址替换成新的域名整个过程不到 2 分钟。注意直接在宿主机上用git命令操作/data/otterwiki/data目录是安全的OtterWiki 会自动检测到文件变化并刷新缓存。但切记不要在容器内执行git命令因为容器内的git是精简版缺少git gc等维护命令长期运行可能导致仓库性能下降。4.3 权限与安全的务实配置小团队的最小权限模型OtterWiki 的权限系统设计得非常务实。它没有 RBAC基于角色的访问控制那么复杂而是采用了“用户组 页面级权限”的两级模型。用户组Groups是权限的容器。默认有admin和user两个组。admin组成员可以创建用户、管理组、编辑所有页面user组成员只能编辑自己创建的页面或被授权的页面。创建新用户时你必须为其指定一个组。这个设计的好处是权限是继承的你不需要为每个用户单独设置只需要把他们加入合适的组。页面级权限Page Permissions是精细化控制的关键。在任意页面的右上角点击 “Settings” “Permissions”你可以为这个页面设置Read谁可以查看all、logged-in users、group:adminEdit谁可以编辑同上Delete谁可以删除同上我给团队设定的最小权限模型是所有公共文档如技术规范、API 文档的Read设为allEdit设为group:admin所有个人笔记如会议纪要、学习笔记的Read和Edit都设为user:username即只有创建者本人能看能改。这样既保证了知识的开放共享又保护了个人的隐私边界。提示OtterWiki 的登录系统是基于 Session 的它不依赖外部数据库。所有用户信息都存储在/app-data/users.json文件里这个文件同样受 Git 版本控制。所以如果你误删了一个用户只要git log还在就能从历史提交里找回users.json的旧版本完美恢复。5. 常见问题排查与独家避坑经验实录5.1 容器健康状态异常healthy状态背后的真相docker compose ps的输出里STATUS 列显示Up 10 minutes (healthy)这通常是个好消息。但有时候你会看到Up 10 minutes (unhealthy)或者干脆没有(healthy)字样。这背后的原因往往不是 OtterWiki 本身的问题而是 Docker 的健康检查机制在“吹毛求疵”。OtterWiki 镜像的Dockerfile里定义了一个健康检查命令HEALTHCHECK --interval30s --timeout3s --start-period5s --retries3 CMD curl -f http://localhost:80/health || exit 1。这个命令的意思是每 30 秒用curl访问容器内部的/health端点如果 3 秒内没返回 HTTP 200就重试 3 次3 次都失败就标记为unhealthy。问题来了OtterWiki 的官方镜像并没有实现/health这个端点它的 Flask 应用根路径/是首页/login是登录页但就是没有/health。所以这个健康检查命令永远会失败。这不是 Bug而是镜像作者的一个“留白”——他假设用户会自己覆盖这个检查。解决方案有两个方案一推荐在docker-compose.yaml里显式覆盖健康检查services: otterwiki: # ... 其他配置 healthcheck: test: [CMD, curl, -f, http://localhost:80/] interval: 30s timeout: 10s retries: 3 start_period: 40s这里把测试目标从/health改成了/也就是首页。只要首页能返回 200就认为服务健康。方案二极简直接禁用健康检查services: otterwiki: # ... 其他配置 healthcheck: disable: true我选择方案一因为/端点的可用性确实能反映 OtterWiki 的核心服务能力。而方案二虽然简单但失去了一个有用的监控信号。5.2 数据持久化的终极验证如何确认你的知识真的“活”在 Git 里很多新手会有一个挥之不去的疑虑“我的页面真的存到 Git 里了吗万一容器删了数据会不会丢” 这个疑虑非常合理验证方法也很直接。第一步docker exec -it otterwiki-otterwiki-1 bash进入容器内部。 第二步cd /app-data然后ls -la。你应该能看到wiki/、users.json、config.py等文件和目录。 第三步cd wiki然后git status。如果一切正常输出应该是On branch main nothing to commit, working tree clean。 第四步git log --oneline -5。你应该能看到最近几次页面编辑的提交记录每一条都对应着你在 Web 界面上的一次“Save”。但最关键的验证是在宿主机上操作。退出容器回到宿主机终端cd /data/otterwiki/data然后重复git status和git log。你会发现输出和容器内一模一样。这证明了volumes挂载是双向实时的容器内对 Git 仓库的任何操作都会 100% 同步到宿主机目录。我曾经做过一个破坏性实验在容器内git reset --hard HEAD~1把最新一次提交回滚掉。然后刷新网页发现刚刚编辑的页面真的变回了上一个版本。这让我彻底相信OtterWiki 不是“把 Git 当备份”而是“把 Git 当数据库”。独家避坑技巧定期在宿主机上执行git gc。/data/otterwiki/data/wiki目录下的 Git 仓库随着页面增多会产生大量松散对象loose objects。git gc会把这些对象打包成 pack 文件大幅减小仓库体积提升git log和git diff的速度。我设置了一个 cron 任务每天凌晨 2 点执行cd /data/otterwiki/data/wiki git gc --prunenow。5.3 华为开发者空间的时长管理如何让 180 小时用得更久华为开发者空间的 180 小时免费资源是按“云主机实例”的运行时间计算的而不是按“Docker 容器”的运行时间。这意味着只要你云主机开着无论里面跑一个容器还是十个容器都在消耗时长。所以最高效的用法是把云主机当成你的“个人云工作站”而不是“单次部署服务器”。我给自己定的规则是每次进入开发者空间先docker compose up -d启动 OtterWiki以及其他常用服务如 VS Code Server。工作期间所有知识编辑、文档查阅、Git 操作都在localhost:5600上完成。工作结束不关机而是docker compose stop停掉所有容器。云主机仍在运行但不再消耗算力CPU 和内存归零只消耗极低的“待机”费用几乎为零。下次需要时docker compose start一键唤醒几秒钟就回到工作状态。这个模式让我把 180 小时用出了 300 小时的效果。因为docker compose stop/start的开销远小于shutdown/startup云主机的开销。后者需要重新加载内核、初始化网络、启动 systemd 服务平均耗时 90 秒而前者只是发送一个SIGTERM信号容器进程瞬间响应。最后一个小技巧在华为开发者空间控制台点击云主机右侧的 “更多” “延时”可以手动延长当前会话。但这个功能有次数限制。更聪明的做法是在~/.bashrc里加一行alias keepalivecurl -s https://developer.huaweicloud.com/keepalive /dev/null 21然后每隔 55 分钟执行一次keepalive。这个心跳请求能有效阻止系统因闲置而自动释放资源。这是我从华为云工程师那里偷师来的“民间秘籍”。
![[C++]内存管理：串顺序存储的内存回收](http://pic.xiahunao.cn/yaotu/[C++]内存管理：串顺序存储的内存回收)
