Docker on 吾爱主机

Docker 桥接网络与嵌入式 DNS：原理、连通性与工程实践

Tue, 21 Jul 2026 00:00:00 +0800

本地 docker run 能通、Compose 里服务名却解析失败；两个容器“看起来在同一台机器”却互 ping 不通；或者明明没 -p，却发现同网段容器已经能访问全部端口——这些日常问题，大多不是“Docker 坏了”，而是 bridge 网络模型 + DNS 解析路径 理解不到位。

本文基于 Docker 官方 Networking overview、Bridge network driver、Packet filtering and firewalls、Networking in Compose 与 Legacy container links，把 默认 bridge 与用户自定义 bridge 的差异、嵌入式 DNS（127.0.0.11）、端口可达性、防火墙/iptables 协作，以及可复现的连通性实验 讲清楚，方便你在排障时按机制定位。

一、问题背景：容器眼里只有网卡，没有“魔法互联”

从容器视角看，网络很朴素：一张网卡、一个 IP、默认网关、路由表和 DNS。容器并不知道对端是不是另一个 Docker 容器，也不知道自己挂在 default bridge 还是自定义网络上。

因此，工程里真正要掌握的是 Docker 如何在宿主机上拼出这张网：

用哪种 network driver 创建隔离域；
容器如何获得 IP，以及如何访问外网（masquerading）；
同网/跨网时，哪些端口天然可达，哪些必须 publish；
名字解析走 宿主 /etc/resolv.conf 拷贝，还是 Docker 嵌入式 DNS。

把这四条对齐后，再看 docker network inspect 和 cat /etc/resolv.conf，排障会快很多。

二、核心机制：bridge 网络在做什么

2.1 软件桥与隔离边界

Bridge 驱动在 Linux 上使用软件网桥：

同一 bridge 网络内的容器可互通；
默认阻止来自其他 bridge 网络、以及 Docker 宿主机之外的直接访问；
通过 masquerading（源地址伪装） 让容器出网时，外部只看到宿主机 IP；
支持 port publishing，把容器端口映射到宿主机地址，供外部或其他网络访问。

官方明确：bridge 面向 同一 Docker daemon 主机 上的容器；跨主机通信需要 OS 级路由或 overlay 等方案。

2.2 内置驱动速览（选型锚点）

Driver	典型用途
`bridge`	默认驱动；同机容器互联（本文重点）
`host`	去掉网络隔离，直接用宿主机网络栈
`none`	完全隔离，无网络
`overlay`	多 daemon / Swarm 跨节点
`macvlan` / `ipvlan`	让容器更像“物理网”上的设备 / VLAN 集成

没有特殊需求时，应用栈优先用 用户自定义 bridge，而不是长期堆在 default bridge 上。

2.3 默认 bridge vs 用户自定义 bridge（必须分清）

Docker 首次启动会自动创建名为 bridge 的 default bridge。未指定 --network 的容器会连上它。

官方对用户自定义 bridge 的结论很直接：User-defined bridge networks are superior to the default bridge network. 关键差异如下。

维度	default bridge	用户自定义 bridge
名字解析	默认只能靠 IP；`--link` 为 legacy	自动 DNS：可用容器名/别名互访
隔离	未指定网络的容器都挤在一起，无关栈可能互通	只有加入该网络的容器互通，作用域清晰
热插拔	要从 default bridge 换走，通常需停容器重建	运行中可用 `docker network connect/disconnect`
配置粒度	全局一份（常需改 daemon 并重启）	每个网络可独立 `docker network create` 配置
生产建议	官方视为 legacy 细节，不建议生产依赖	推荐作为同机服务互联默认选择

同一用户自定义 bridge 内的容器，彼此相当于暴露全部端口；若要对其他网络或宿主机外访问，才需要 -p/--publish。

2.4 嵌入式 DNS：`127.0.0.11`

DNS 是 default bridge 与自定义网络最容易踩坑的分界线：

default bridge：容器通常拿到宿主 /etc/resolv.conf 的拷贝，按宿主配置解析公网名；默认不能靠容器名互访。
自定义网络（含 Compose 默认项目网络）：使用 Docker embedded DNS。
- 地址固定为 127.0.0.11；
- 没有 IPv6 等价地址，IPv6-only 容器仍用该 IPv4 地址；
- 容器名/别名解析在嵌入式 DNS 完成；
- 外部域名查询会转发到宿主上配置的 DNS。

若应用硬编码了 DNS 服务器地址，官方建议写 127.0.0.11（在自定义网络场景下），而不是宿主上的 8.8.8.8 之类——后者会绕过容器名解析。

可用标志（docker run / docker create）：

标志	作用
`--dns`	指定 DNS 服务器；注意解析发生在容器网络命名空间，`--dns=127.0.0.1` 指容器自己的 loopback
`--dns-search`	搜索域
`--dns-opt`	`resolv.conf` 选项
`--hostname`	容器主机名（默认多为容器 ID）

宿主 /etc/hosts 的自定义条目不会自动继承进容器；额外主机名用 --add-host / Compose extra_hosts。

2.5 端口可达性与防火墙协作

同 bridge 网络：容器端口对宿主及同网其他容器可达；
默认配置下，其他 bridge 网络或宿主机外访问需要 publish；
Linux 上 Docker 会创建防火墙规则以实现隔离、端口发布与 NAT；不要随意改 Docker 生成的规则；
默认后端多为 iptables，也支持 nftables；bridge 上两者功能等价；
对 ipvlan / macvlan / host，Docker 不创建这套 bridge 规则；
Docker 常会打开 IP 转发，并可能把转发默认策略设为 drop（防止宿主机无意变成路由器）；
Docker 与 ufw 不兼容的常见根因：Docker 在 nat 表改写流量，可能在 ufw 的 INPUT/OUTPUT 之前分流，导致“ufw 规则像没生效”。

常用网络级选项（docker network create --opt）：

Option	默认	含义
`com.docker.network.bridge.enable_ip_masquerade`	`true`	出网伪装
`com.docker.network.bridge.enable_icc`	`true`	同网容器互通；可关以强制“只经代理/发布口访问”
`com.docker.network.bridge.host_binding_ipv4`	全部地址	未写主机 IP 时的默认绑定地址
`com.docker.network.driver.mtu`	`0`（不限制）	MTU

2.6 Compose 如何落地同一套模型

docker compose up 默认会创建名为 <project-name>_default 的 bridge 网络，服务全部加入，并向内部 DNS 注册服务名。因此 Compose 里写 http://api:8080 往往能通，而“裸 default bridge 起两个容器却写容器名”会失败——这不是 Compose 魔法，而是 自定义网络 + 嵌入式 DNS。

还可声明 internal: true 的网络（无默认出网网关），把数据库等后端放在“只能被同项目服务访问”的网段上。

三、实践：可复现的连通性与 DNS 实验

下面命令假定本机已安装 Docker Engine。若无 alpine 镜像，会自动拉取。

3.1 观察 default bridge：能通 IP，不能靠名字

# 两个容器都挂在 default bridge（未指定 --network）
docker run -d --name dns-a alpine sleep 3600
docker run -d --name dns-b alpine sleep 3600

# 看 IP
docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' dns-a
IP_A=$(docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' dns-a)

# IP 互通通常成功
docker exec dns-b ping -c1 "$IP_A"

# 名字解析：在 default bridge 上通常失败（无嵌入式 DNS 的容器名互访）
docker exec dns-b ping -c1 dns-a || echo "name resolve failed as expected on default bridge"

# 看 resolv.conf：往往是宿主 DNS 拷贝，而不是 127.0.0.11
docker exec dns-b cat /etc/resolv.conf

清理：

docker rm -f dns-a dns-b

3.2 用户自定义 bridge：容器名解析 + `127.0.0.11`

docker network create demo-net

docker run -d --name web --network demo-net alpine sleep 3600
docker run -d --name db --network demo-net alpine sleep 3600

# 名字应可解析
docker exec web ping -c1 db
docker exec db ping -c1 web

# 嵌入式 DNS
docker exec web cat /etc/resolv.conf
# 期望 nameserver 为 127.0.0.11

# 同网端口：无需 -p，另一容器即可访问（这里用 nc 示意）
docker exec -d db sh -c 'echo hi | nc -l -p 9000'
docker exec web sh -c 'nc -w 2 db 9000'

运行中热挂网络：

docker run -d --name side alpine sleep 3600 # 先在 default bridge
docker network connect demo-net side
docker exec side ping -c1 web
docker network disconnect demo-net side

清理：

docker rm -f web db side
docker network rm demo-net

3.3 “前后端分离网络”拓扑（多网卡容器）

docker network create frontend
docker network create --internal backend # 无默认出网，适合数据库平面

docker run -d --name api --network frontend alpine sleep 3600
docker network connect backend api

docker run -d --name pg --network backend alpine sleep 3600

# api 能访问 pg（同 backend）；pg 默认不应依赖出网
docker exec api ping -c1 pg

# 可选：限制默认绑定，仅本机可访问已发布端口
docker network create \
 --opt com.docker.network.bridge.host_binding_ipv4=127.0.0.1 \
 local-only

3.4 Compose 最小可运行示意

# compose.yaml
services:
 web:
 image: alpine
 command: sleep 3600
 depends_on: [api]
 api:
 image: alpine
 command: sleep 3600
 networks: [default, backend]
 db:
 image: alpine
 command: sleep 3600
 networks: [backend]

networks:
 backend:
 internal: true

docker compose up -d
docker compose exec web ping -c1 api # 服务名 DNS
docker compose exec api ping -c1 db
docker compose down

3.5 关闭 ICC（强制“不能随意横穿”）

docker network create \
 --opt com.docker.network.bridge.enable_icc=false \
 no-icc-net

# 同网容器在 ICC 关闭后，默认相互连通会被限制
# 常用于强制流量只经反向代理或显式发布路径（结合具体策略验证）
docker network rm no-icc-net

四、常见坑与排查清单

症状	优先检查
容器名 ping 不通	是否挂在 default bridge？自定义网络里 `cat /etc/resolv.conf` 是否为 `127.0.0.11`？
Compose 服务名不通	是否在同一 project 网络？服务是否显式挂到不同 network 且未共享？`docker network inspect <project>_default`
外网不能访问容器	是否 `-p/--publish`？安全组/云防火墙？绑定是否被 `host_binding_ipv4=127.0.0.1` 限制在本机？
容器不能出网	`enable_ip_masquerade`？宿主 IP 转发？DNS 是否异常？`iptables=false` 是否误关 Docker 防火墙规则？
ufw “放行了仍异常”	已知 Docker 与 ufw 规则路径冲突，publish 流量可能绕过 ufw 链
`--link` 老项目	官方标为 legacy，推荐迁移到 user-defined networks；环境变量共享改用 env/volume/Compose
单网容器极多不稳定	内核限制：单 bridge 约 1000+ 容器时可能不稳定（见 moby#44973）
多网卡默认路由怪	多网络时默认网关可能变化；可用 `gw-priority` 指定优先网关
宿主 hosts 改了容器不生效	宿主 `/etc/hosts` 不继承；用 `--add-host` / `extra_hosts`

推荐排查命令：

docker network ls
docker network inspect <net>
docker inspect -f '{{json .NetworkSettings.Networks}}' <ctr> | jq .
docker exec <ctr> cat /etc/resolv.conf
docker exec <ctr> ip route
docker exec <ctr> getent hosts <peer-name>
# 宿主侧（Linux）
ip link show type bridge
# 注意：不要随手 flush Docker 管理的 iptables 链

五、工程建议（可直接落到规范）

新项目默认创建用户自定义 bridge（或直接用 Compose 项目网络），避免依赖 default bridge 与 --link。
服务发现用名字，不写死容器 IP；IP 会随重建变化，DNS 是稳定契约。
前后端分层网络：对外服务进可出网网络，数据库进 internal 网络；需要两边都通的 BFF/API 同时 attach。
只 publish 必要端口，生产优先绑定具体主机地址，避免 0.0.0.0 无脑暴露。
不要手改 Docker 生成的防火墙规则；若必须对接企业防火墙，走官方允许的集成方式，而不是 iptables=false 一刀切。
应用若强制配置 DNS，自定义网络场景优先 127.0.0.11，以免丢掉容器名解析。
跨主机通信升级到 overlay / 服务网格 / 云网络，不要指望单机 bridge “自动跨机”。

六、总结

Docker 单机互联的主干是 bridge：软件桥提供 L2 邻接与隔离，masquerade 解决出网，publish 解决入站，嵌入式 DNS（127.0.0.11） 解决自定义网络上的名字发现。default bridge 适合“随手跑个容器”，但缺少容器名 DNS、隔离弱、配置粗，官方更推荐 user-defined bridge；Compose 的服务名互通，本质上就是把这套模型产品化了。

记住一条排障主线：

先看容器挂在哪张网 → 再看 /etc/resolv.conf 是不是 127.0.0.11 → 再判断该不该有 publish → 最后才怀疑防火墙/宿主路由。

按这条线做，大部分“容器网络玄学”都会变成可验证的配置问题。

参考资料

Docker Docs — Networking overview（官方；DNS / default bridge / drivers）
Docker Docs — Bridge network driver（官方；default vs user-defined、选项表、ICC/masquerade）
Docker Docs — Network drivers（官方；bridge/host/overlay/macvlan 等选型）
Docker Docs — Packet filtering and firewalls（官方；iptables/nftables、ufw 注意点）
Docker Docs — Networking in Compose（官方；项目默认网络与服务名 DNS）
Docker Docs — Legacy container links（官方；--link legacy 与迁移建议）
源码文档镜像（核验用）：docker/docs content/manuals/engine/network/

OceanBase 多平台搭建教程：Linux / Windows / macOS / Docker 从零到可连接

Fri, 17 Jul 2026 00:00:00 +0800

OceanBase 是蚂蚁集团开源的分布式关系型数据库，兼容 MySQL 协议，适合本地体验、开发联调与集群试验。很多人第一次上手时最困惑的不是“它强在哪”，而是：

我在 Linux / Windows / macOS 上，到底该用哪一种方式装？

本文按官方社区推荐路径，整理一套可复用的多平台搭建方法：优先讲最快跑起来，再讲更接近生产部署的方式，并给出连接验证与常见排错。

说明：本文以 OceanBase 社区版（CE） 的官方开源安装路径为主，面向学习与开发环境。官方 Docker 镜像明确标注仅供测试，不建议直接用于生产。

一、先选对安装路径

平台	最推荐方式	备选方式	说明
Linux	`all-in-one` + `obd demo`	Docker / OBD 自定义集群	官方 all-in-one 仅支持 Linux
macOS	Docker Desktop + `oceanbase-ce`	远程 Linux 开发机	本机不建议硬编译 observer 当第一选择
Windows	Docker Desktop	WSL2 + Linux 方案	原生 Windows 不适合当主路径
任意平台（快速体验）	Docker `oceanbase/oceanbase-ce`	quay.io / ghcr.io 镜像源	单实例、端口 `2881`
Kubernetes	`ob-operator`	—	容器化生产/类生产集群请走 operator

资源底线（很重要）

不同路径对资源要求不同，至少记住两档：

Docker 官方镜像（测试）
- 主机建议至少 2 物理核 + 8GB 内存
obd demo 本地单节点
- 至少 2 CPU、6GB 可用内存、54GB 可用磁盘
- 端口 2881 / 2882 未被占用

机器太小会导致 bootstrap 卡住、容器反复重启，看起来像“命令写错了”，其实是资源不足。

二、通用概念：端口、租户、客户端

搭好后，通常这样连接：

项目	常见值
协议	MySQL 兼容
SQL 端口	`2881`
系统租户	`sys`
示例业务租户	`test`（Docker 镜像常见）
客户端	`obclient` 或标准 `mysql` 客户端

常用连接示例：

# 系统租户 root
mysql -h127.0.0.1 -P2881 -uroot

# 普通租户 root（Docker 文档示例）
mysql -h127.0.0.1 -P2881 -uroot@test

如果你本机没有 mysql 客户端，可用容器内置客户端：

docker exec -it oceanbase-ce obclient -h127.0.0.1 -P2881 -uroot

三、最快路径：Docker（Linux / Windows / macOS 通用）

这是跨平台体验 OceanBase 最省事的方式。
官方提供镜像：

Docker Hub：oceanbase/oceanbase-ce
备选：quay.io/oceanbase/oceanbase-ce
备选：ghcr.io/oceanbase/oceanbase-ce

官方说明：该镜像用于快速搭建测试环境，只支持单实例；若在 Kubernetes 中运行，请改用 ob-operator。

1. 前置条件

已安装并可运行 Docker（Linux Docker Engine / Docker Desktop）
主机资源满足：约 2 核 + 8GB 内存
本机 2881 端口空闲

2. 启动实例

# mini 模式：适合快速体验（官方 README 推荐写法）
docker run -p 2881:2881 --name oceanbase-ce -e MODE=mini -d oceanbase/oceanbase-ce

Docker Hub 文档还给出了其他模式：

# 使用容器更多资源
docker run -p 2881:2881 --name oceanbase-ce -e MODE=normal -d oceanbase/oceanbase-ce

# slim / fastboot 模式
docker run -p 2881:2881 --name oceanbase-ce -e MODE=slim -d oceanbase/oceanbase-ce

若 Docker Hub 拉取慢，可切换镜像源：

docker run -p 2881:2881 --name oceanbase-ce -e MODE=mini -d quay.io/oceanbase/oceanbase-ce
# 或
docker run -p 2881:2881 --name oceanbase-ce -e MODE=mini -d ghcr.io/oceanbase/oceanbase-ce

3. 等待 bootstrap 完成

首次启动可能需要几分钟。查看日志末尾：

docker logs oceanbase-ce | tail -1

期望看到：

boot success!

4. 连接验证

# 方式 A：容器内客户端
docker exec -it oceanbase-ce obclient -h127.0.0.1 -P2881 -uroot

# 方式 B：宿主机 mysql 客户端
mysql -h127.0.0.1 -P2881 -uroot
mysql -h127.0.0.1 -P2881 -uroot@test

进入后可执行：

SHOW DATABASES;
SELECT version();

5. 常用运维命令

docker ps -a | grep oceanbase-ce
docker logs -f oceanbase-ce
docker restart oceanbase-ce
docker stop oceanbase-ce
docker rm -f oceanbase-ce

6. 初始化 SQL（可选）

官方镜像支持挂载初始化脚本目录：

docker run -p 2881:2881 --name oceanbase-ce \
 -v /path/to/init-sql:/root/boot/init.d \
 -d oceanbase/oceanbase-ce

注意：官方文档提醒，初始化脚本中不要直接改 root 密码；若要改密码，应使用镜像提供的环境变量（如 OB_TENANT_PASSWORD，以当前镜像说明为准）。

四、Linux 原生：all-in-one + OBD（官方推荐体验路径）

如果你有一台 Linux 服务器或虚拟机，想更接近“真集群工具链”，优先用官方 all-in-one。

1. 一键安装 all-in-one

官方 README 明确：仅 Linux。

# 需要能访问外网
bash -c "$(curl -s https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/download-center/opensource/oceanbase-all-in-one/installer.sh)"
source ~/.oceanbase-all-in-one/bin/env.sh

2. 一键拉起演示实例

obd demo

obd demo 会在本机部署并启动一个 OceanBase 实例。部署完成后：

obclient -h127.0.0.1 -uroot -P2881

3. 单独安装 OBD（CentOS/RHEL 系）

如果你不走 all-in-one，也可以单独装 OceanBase Deployer：

sudo yum install -y yum-utils
sudo yum-config-manager --add-repo https://mirrors.aliyun.com/oceanbase/OceanBase.repo
sudo yum install -y ob-deploy
source /etc/profile.d/obd.sh

然后同样可用：

obd demo

4. `obd demo` 前自检清单

端口 2881、2882 空闲
可用内存 ≥ 6GB
CPU ≥ 2
可用磁盘 ≥ 54GB
系统时间正常、主机名可解析

资源不够时，OBD 往往会在预检阶段失败；先把机器规格补齐再重试，比反复改 YAML 更有效。

五、Windows 搭建

Windows 原生不适合作为 OceanBase observer 主部署平台。实操建议两条路：

方案 A：Docker Desktop（最简单）

安装 Docker Desktop for Windows
确保 WSL2 后端已启用（Docker Desktop 默认推荐）
在 PowerShell / Windows Terminal 执行：

docker run -p 2881:2881 --name oceanbase-ce -e MODE=mini -d oceanbase/oceanbase-ce
docker logs oceanbase-ce

看到 boot success! 后连接：

docker exec -it oceanbase-ce obclient -h127.0.0.1 -P2881 -uroot

Windows 上若本机没有 mysql 客户端，优先用容器内 obclient。

方案 B：WSL2 + Linux 路径

适合希望练习 obd / all-in-one 的同学：

安装 WSL2 与 Ubuntu（或其他受支持发行版）
给 WSL 分配足够内存（建议在 .wslconfig 中提高 memory）
在 WSL 内按上文 Linux all-in-one / Docker 步骤执行

注意：WSL 的磁盘 I/O 与内存限制会影响 bootstrap 时间，尽量把数据放在 Linux 文件系统内，不要跨挂载到很慢的 Windows 目录。

六、macOS 搭建

macOS 上同样优先 Docker：

1. 安装 Docker Desktop for Mac

Intel / Apple Silicon 都可使用 Docker Desktop
在 Docker Desktop → Settings → Resources 中给足 CPU/内存（建议 ≥ 2 CPU、8GB）

2. 启动 OceanBase

docker run -p 2881:2881 --name oceanbase-ce -e MODE=mini -d oceanbase/oceanbase-ce

拉取慢时可换：

docker run -p 2881:2881 --name oceanbase-ce -e MODE=mini -d ghcr.io/oceanbase/oceanbase-ce

3. 连接

docker exec -it oceanbase-ce obclient -h127.0.0.1 -P2881 -uroot

4. macOS 特别提醒

官方 all-in-one 标注 Linux Only，不要在 macOS 上硬套那条 installer 当主路径
Apple Silicon 上若镜像/依赖偶发兼容问题，优先换官方备用镜像源，或使用远程 Linux 机器做部署练习
开发联调可把应用跑在 macOS，数据库跑在 Docker 容器；应用连接 127.0.0.1:2881

七、进阶：Kubernetes 与多节点

当你已经不满足“本机单实例体验”，可以往这两类走：

1. Kubernetes：`ob-operator`

官方 README 推荐使用 ob-operator 在 K8s 中部署管理 OceanBase。
适合：

想练容器化运维
需要更接近云原生的生命周期管理
本地 kind/k3s/自建集群实验

快速入口见：https://oceanbase.github.io/ob-operator

2. OBD 自定义集群

obd demo 只是快速单机演示。真正做多副本/多节点时，应使用 OBD 的集群配置与命令组（镜像仓库、集群启停、升级等）。
这已经超出“第一次搭起来”的范围，但方向应是：

先用 Docker / obd demo 跑通连接
再学 OBD 配置文件与集群拓扑
最后再上 K8s operator

八、连接后的最小验收清单

不管你用哪种平台，搭完后建议做同一套验收：

-- 1. 能登录
SELECT 1;

-- 2. 看版本信息
SELECT version();

-- 3. 建库建表
CREATE DATABASE demo;
USE demo;
CREATE TABLE t1(id INT PRIMARY KEY, name VARCHAR(64));
INSERT INTO t1 VALUES (1, 'oceanbase');
SELECT * FROM t1;

宿主机侧再确认：

# 端口监听
# Linux
ss -lntp | grep 2881
# macOS
lsof -iTCP:2881 -sTCP:LISTEN

九、常见问题排查

1. 容器一直起不来 / 没有 `boot success!`

优先检查：

内存是否低于 8GB（Docker 场景）
磁盘是否紧张
docker logs oceanbase-ce 是否有 OOM / 权限 / 存储错误
是否重复占用容器名 oceanbase-ce

处理：

docker rm -f oceanbase-ce
docker run -p 2881:2881 --name oceanbase-ce -e MODE=mini -d oceanbase/oceanbase-ce

2. `2881` 端口冲突

# 换宿主机端口映射，例如 12881 -> 2881
docker run -p 12881:2881 --name oceanbase-ce -e MODE=mini -d oceanbase/oceanbase-ce
mysql -h127.0.0.1 -P12881 -uroot

3. Docker Hub 拉取失败

依次尝试：

quay.io/oceanbase/oceanbase-ce
ghcr.io/oceanbase/oceanbase-ce
配置可用的镜像加速 / 代理

4. 能进容器但不能从宿主机连接

确认 -p 2881:2881 已映射
Windows/macOS 确认 Docker Desktop 正在运行
云服务器还要放行安全组/防火墙入站规则

5. `obd demo` 预检失败

对照官方条件逐项查：

内存、CPU、磁盘是否达标
2881/2882 是否被占用
是否在非 Linux 环境误跑 all-in-one

十、平台选型建议（实战版）

你的目标	建议
30 分钟内先连上跑 SQL	Docker `MODE=mini`
在 Linux 服务器练官方部署工具	all-in-one + `obd demo`
Windows 笔记本本地体验	Docker Desktop
macOS 开发机联调	Docker Desktop
学习 K8s 运维	ob-operator
准备生产环境	不要直接用体验镜像；按正式部署/高可用架构与官方生产文档规划

一句话总结：

跨平台先 Docker；Linux 深造用 OBD；生产上集群/K8s，不要拿体验镜像硬上。

十一、精简命令速查

Docker（全平台）

docker run -p 2881:2881 --name oceanbase-ce -e MODE=mini -d oceanbase/oceanbase-ce
docker logs oceanbase-ce | tail -1
docker exec -it oceanbase-ce obclient -h127.0.0.1 -P2881 -uroot

Linux all-in-one

bash -c "$(curl -s https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/download-center/opensource/oceanbase-all-in-one/installer.sh)"
source ~/.oceanbase-all-in-one/bin/env.sh
obd demo
obclient -h127.0.0.1 -uroot -P2881

OBD RPM（CentOS/RHEL）

sudo yum install -y yum-utils
sudo yum-config-manager --add-repo https://mirrors.aliyun.com/oceanbase/OceanBase.repo
sudo yum install -y ob-deploy
source /etc/profile.d/obd.sh
obd demo

总结

OceanBase 的“多平台搭建”并不要求你在每个 OS 上都原生编译一套数据库：

Docker 是 Linux / Windows / macOS 的最大公约数，适合快速体验与开发联调。
Linux all-in-one + OBD 更接近官方部署工具体验，适合服务器环境。
Windows / macOS 应把精力放在 Docker Desktop（或 WSL2）而不是强行原生部署。
需要容器编排时，转向 ob-operator，而不是把 oceanbase-ce 体验镜像直接当生产方案。

先保证“能启动、能连接、能建表”，再进入租户管理、资源规格、多副本和高可用，路径会清晰很多。

参考资料

OceanBase 官方仓库 README（中英文 Quick Start / Docker / all-in-one）：https://github.com/oceanbase/oceanbase
OceanBase Docker 镜像说明（Docker Hub oceanbase/oceanbase-ce）：https://hub.docker.com/r/oceanbase/oceanbase-ce
OceanBase Docker 镜像仓库文档：https://github.com/oceanbase/docker-images
OceanBase Deployer（OBD）中文 README：https://github.com/oceanbase/obdeploy
ob-operator 文档：https://oceanbase.github.io/ob-operator
OceanBase 中文文档中心：https://www.oceanbase.com/docs/oceanbase-database-cn
快速体验入口：https://open.oceanbase.com/quickStart

Linux cgroup v2 内存控制与 OOM Killer：原理、观测与容器化实践

Thu, 16 Jul 2026 00:00:00 +0800

线上最棘手的一类故障，往往不是“服务报了明确业务错误”，而是进程突然消失：容器退出码 137、Pod 状态里出现 OOMKilled，或者主机 dmesg 里留下一行 Out of memory: Killed process。表象是“内存不够”，根因通常落在 内存如何被记账、如何被限制、以及内核如何选择牺牲者。

本文以 Linux cgroup v2 memory 控制器 与 OOM Killer 为主线，结合 Docker / Kubernetes 的常见映射，把“限多少、什么时候开始回收、什么时候杀进程、怎么排”讲清楚。

一、先建立两层模型：全局 OOM vs cgroup OOM

Linux 里至少要区分两种“内存不够”：

场景	典型触发	影响范围
全局内存压力	整机可用内存 + 可回收页不够，分配失败	OOM killer 在系统范围内按启发式选进程
cgroup 内存上限	某 cgroup 的 `memory.max` 触顶且回收失败	OOM 只发生在该 cgroup 内（不会跨出该 cgroup 去杀别人）

这解释了一个常见错觉：给容器设了 -m 512m，为什么还会拖垮宿主机？
因为：

没设硬限制时，容器与宿主机共享整机内存；
即使设了 limit，仍可能有内核开销、page cache 统计差异、swap 配置、以及 宿主级其他进程 的压力；
Docker 默认会尽量保护 daemon 自身，但不会自动把所有容器都“隔离成绝对安全沙箱”。

因此工程上要同时看：

进程/容器是否撞到了 自己的 limit；
节点是否发生了 系统级 OOM / kubelet 驱逐。

二、cgroup v2 的内存阶梯：min / low / high / max

cgroup v2 memory 控制器把控制面拆成“保护、限速、硬顶”几层。官方接口里最核心的是这些文件（单位均为字节）：

接口	角色	关键语义
`memory.current`	观测	当前 cgroup 及其后代已用内存
`memory.min`	硬保护	在 effective min 内，内存不会被回收；若系统没有其他可回收内存，可能直接触发 OOM
`memory.low`	尽力保护	在 effective low 内，尽量不被回收；只有无保护可回收内存时才可能被碰
`memory.high`	节流线	超高后进程被 throttling，并承受很重的 direct reclaim；不会因此调用 OOM killer
`memory.max`	硬上限	用量到顶且无法压回时，在该 cgroup 内调用 OOM killer
`memory.oom.group`	策略	设为 `1` 时，把 cgroup 当不可分割工作负载：要么一起杀，要么都不杀（`oom_score_adj=-1000` 的任务例外）
`memory.events`	事件计数	`high` / `max` / `oom` / `oom_kill` 等，是最好的“快撞墙”信号
`memory.peak`	峰值	自创建或重置以来的最大用量

可以把它理解成一条阶梯：

usage
 │
 │ memory.min ── 硬保护（尽量不回收；保护过猛可能反噬）
 │ memory.low ── 软保护（有余量时优先回收别人）
 │ memory.high ── 开始重压回收 + 节流（通常还不杀）
 │ memory.max ── 硬顶；回收失败 → cgroup OOM
 ▼

1. 为什么要有 `high`，而不是只设 `max`？

memory.max 是“悬崖”：到顶就可能杀进程。
memory.high 是“缓坡”：先让工作负载变慢、开始回收，给外部控制器（或人）反应时间。内核文档明确：high 越界 never invokes the OOM killer，极端情况下甚至可能被短暂突破。

生产里更健康的模式往往是：

high 设在“可接受抖动”的水位；
max 设在“绝对不可越过”的水位；
用 memory.events 的 high/max 做告警，而不是等进程死了再看。

2. `min`/`low` 保护不是免费的

memory.min 是硬保护：保护区内页面在“任何条件下”都不应被回收；如果系统已经没有未保护可回收内存，就可能 直接 OOM。
memory.low 是 best-effort：优先保护，但仍可能在全局极端压力下被回收。

因此：

保护值叠加超过父 cgroup/整机能力时，会发生 overcommit of protection；
effective 边界还会受祖先 cgroup 限制；
把所有关键服务都设成很高的 min，等于在内存不够时更容易触发“保谁都保不住”的 OOM。

三、OOM Killer：它到底怎么选人

1. 评分：`oom_score` 与 `oom_score_adj`

当内核决定必须杀进程腾内存时，会给候选任务打 badness 分。man-pages 对 /proc/<pid>/oom_score / oom_score_adj 的说明可概括为：

分数大致落在 0（几乎不杀）到 1000（优先杀）；
主要依据是任务相对其 allowed memory 的用量比例（RSS/swap 等估计）；
用满允许内存 ≈ 1000，用一半 ≈ 500；
root 进程额外获得约 3% 的“更宽容”额度；
oom_score_adj 范围 -1000 ~ +1000，在启发式结果上再加减；
oom_score_adj = -1000 表示 OOM 保护（基本不会被选中）。

“allowed memory”取决于 OOM 上下文：

系统全局 OOM → 整机可分配资源；
cgroup/limit 触顶 → 该 limit 本身；
cpuset / mempolicy 节点耗尽 → 对应节点集合。

2. 系统级可调旋钮（`/proc/sys/vm/*`）

参数	默认（文档）	作用
`oom_dump_tasks`	`1`	OOM 杀进程时是否打印系统任务摘要（pid/rss/oom_score_adj 等），便于事后定位
`oom_kill_allocating_task`	`0`	`0`：扫描任务列表按启发式选“更该杀”的；`1`：直接杀触发分配失败的那个任务（省扫描）
`panic_on_oom`	`0`	`0` 杀进程求生；`1` 全局 OOM 可 panic（节点局部耗尽未必）；`2` 连 memory cgroup OOM 也整机 panic
`overcommit_memory`	`0`	`0` 启发式拒绝明显 overcommit；`1` 几乎总是允许，直到真正用完；`2` never overcommit 策略

大多数业务机保持默认即可；集群 failover / 取证 场景才会认真考虑 panic_on_oom + kdump。
不要把 oom_kill_allocating_task=1 当成“优化”随手打开：它可能杀掉“刚好申请最后一页”的 innocuous 任务，而放过真正的内存黑洞。

3. cgroup 内 OOM 的边界

cgroup v2 文档强调两点：

触达 memory.max 且无法回收时，OOM killer 在该 cgroup 内被调用；
一旦在某个 cgroup 触发 OOM，不会去杀该 cgroup 外的任务（与祖先 memory.oom.group 取值无关）。

memory.oom.group=1 适合“多进程必须同生共死”的工作负载（例如某个多 worker 服务希望要么整组重启，要么都不半残）。
但要注意：被 -1000 保护的任务仍是例外。

四、工程映射：Docker 与 Kubernetes

1. Docker：把 limit 落到 cgroup

Docker 官方资源限制文档给出了与内存相关的关键选项：

# 硬上限（最小允许约 6m）
docker run -d --name demo -m 512m your-image

# 内存 + swap 总预算（细节依赖 --memory-swap 语义）
docker run -d -m 512m --memory-swap 1g your-image

# 软预留（争用时更“敏感”，不保证不越界）
docker run -d -m 1g --memory-reservation 512m your-image

# 一般不要关 OOM killer；若关闭，必须同时设置 -m
docker run -d -m 512m --oom-kill-disable your-image

要点：

-m/--memory：容器可用内存上限；
--memory-reservation：软限制，需小于 --memory，争用时生效，不保证永不越界；
--oom-kill-disable：禁用容器内 OOM killer；文档要求 仅在同时设置了 -m 时使用，否则可能把压力转嫁给宿主机，拖垮整机；
Docker daemon 会调整自身 OOM 优先级，降低“杀 daemon 导致全盘崩溃”的概率；容器进程默认没有这种优待。

2. Kubernetes：request / limit / QoS / 驱逐

Kubernetes 文档把资源语义拆成两层：

调度与预留：requests 供 kube-scheduler 选型，kubelet 也会为容器预留至少 request 量；
运行时强制：limits 由 kubelet/容器运行时落到 cgroup；memory limit 由内核通过 OOM kill 强制。

与 CPU 不同：CPU 超限通常是节流；内存超限更可能直接被内核杀掉。文档也提醒：OOM 是 反应式 的——容器可能短暂超过 limit，但在内核感知到压力后才被终止。

QoS 类（Guaranteed / Burstable / BestEffort）主要影响 节点资源压力下的驱逐优先级：

节点资源不足时，通常先考虑驱逐 BestEffort，再 Burstable，最后 Guaranteed；
因资源压力驱逐时，候选对象通常是 超过 request 的 Pod；
Guaranteed（各容器 request=limit 且都 >0 的经典条件）最不容易被驱逐，但 不等于永远不被 OOM：一旦超过自己的 memory limit，仍可能 OOMKilled。

一个可复现的排查入口：

kubectl describe pod <pod> | sed -n '/Last State/,/Events/p'
# 常见：Reason: OOMKilled, Exit Code: 137

五、可复现观测：别等 dmesg 再救火

1. 先确认 cgroup v2 与容器路径

# 多数现代发行版默认 cgroup v2 统一层级
mount | grep cgroup
stat -fc %T /sys/fs/cgroup

# 看某个进程属于哪个 cgroup
pidof java | head -n1 | xargs -I{} cat /proc/{}/cgroup

2. 读 memory 接口（容器内或宿主机 cgroup 路径）

CG=/sys/fs/cgroup # 或容器对应的子路径，如 /sys/fs/cgroup/system.slice/docker-<id>.scope

cat $CG/memory.current
cat $CG/memory.max
cat $CG/memory.high
cat $CG/memory.peak
cat $CG/memory.events
# 关注：high / max / oom / oom_kill 是否持续上涨

解释事件：

`memory.events` 字段	含义（工程视角）
`high`	触碰 high 边界，被节流/强制回收的次数
`max`	用量几乎要越过 max；若 direct reclaim 失败，将进入 OOM 状态
`oom`	已到 limit，分配即将失败
`oom_kill`	实际发生了 OOM kill

3. 看谁更容易被杀

# 分数越高越危险
ps -eo pid,user,comm,rss,oom_score,oom_score_adj --sort=-oom_score | head

# 某个关键守护进程是否被错误保护/错误牺牲
cat /proc/$(pidof dockerd)/oom_score_adj

4. 对照内核日志

dmesg -T | egrep -i 'out of memory|killed process|oom'
journalctl -k -b --no-pager | egrep -i 'out of memory|killed process'

若 oom_dump_tasks=1（默认），日志里通常能看到候选任务的 rss、oom_score_adj 等信息，用来回答“为什么杀的是 A 不是 B”。

六、常见坑与排查清单

坑 1：只设 request，不设 limit

调度时“看起来能放下”，运行时可以吃爆节点；最终变成 节点级压力 + 驱逐/全局 OOM，故障面比单容器 OOM 更大。

坑 2：limit 设太紧，没有 `high` 缓冲与观测

应用启动峰值、JVM 堆外、page cache、临时解压都可能把 current 顶到 max。
结果是频繁 OOMKilled 重启，而不是平滑降速。优先补：

真实峰值观测（memory.peak、容器监控）；
合理 limit；
能用 high 水位告警就不要只用死亡事件告警。

坑 3：把 `oom_score_adj=-1000` 到处贴

保护数据库/核心 agent 合理；若把内存泄漏服务也保护起来，OOM killer 只能去杀更无辜的进程，整机稳定性更差。

坑 4：`--oom-kill-disable` 却没有硬上限

Docker 文档明确警告：关 OOM killer 时必须配合 -m。否则容器可把宿主内存吃穿。

坑 5：混淆“kubelet 驱逐”与“cgroup OOM”

现象	更像
Pod 事件里有 eviction、磁盘/内存 pressure	kubelet 驱逐
Container `Last State: OOMKilled` / exit 137	cgroup/内核 OOM
宿主 `dmesg` 出现 Killed process，且受害进程不一定是容器	全局 OOM 或选中了别的任务

坑 6：用错“内存用量”口径

RSS、cgroup memory.current、容器运行时 working set、JVM heap used 不是同一个数。
排 OOM 时以 cgroup 记账 + kernel 日志 为准，再用进程级工具交叉验证。

七、一套可执行的生产建议

每个有状态/高风险服务都要有 memory limit，并基于压测峰值留 20%–40% 余量（按语言运行时特性调整）。
优先监控 memory.events 与 working set 趋势，把 high/max 当预警，把 oom_kill 当事故。
K8s 上让关键链路尽量 Guaranteed 或至少 request≈实际稳态；limit 不要拍脑袋抄 CPU 倍数。
保护面要窄：-1000 只给真正的系统关键路径；业务进程靠 limit 与弹性，而不是全局免死金牌。
复盘时固定三件套：memory.current/max/events + oom_score(_adj) + dmesg/journal。
不要默认改 panic_on_oom / oom_kill_allocating_task，除非你清楚故障域与取证目标。

八、总结

cgroup v2 用 min/low/high/max 把内存控制从“一刀切 hard cap”扩展成“保护 + 节流 + 硬顶”。
high 负责让系统先变慢并回收；max 才是 OOM 悬崖。
OOM killer 按 badness/oom_score_adj 选人；cgroup OOM 默认 杀在组内，memory.oom.group 可改变是否整组同生共死。
Docker 的 -m、K8s 的 limits.memory 最终都落到内核 cgroup；CPU 超限多半被节流，内存超限更可能被杀。
可观测性的关键不是“死了没有”，而是 memory.events 是否在反复逼近上限。

把内存限制当成“开关”只会得到随机的 137；把它当成“阶梯 + 评分 + 事件流”，才能在容器化环境里稳定控风险。

参考资料

Linux Kernel Docs — Control Group v2（memory.current / min / low / high / max / oom.group / events）: https://docs.kernel.org/admin-guide/cgroup-v2.html
Linux Kernel Docs — Documentation for /proc/sys/vm/（oom_dump_tasks、oom_kill_allocating_task、panic_on_oom、overcommit_memory、swappiness）: https://docs.kernel.org/admin-guide/sysctl/vm.html
man-pages — proc_pid_oom_score(5): https://man7.org/linux/man-pages/man5/proc_pid_oom_score.5.html
man-pages — proc_pid_oom_score_adj(5): https://man7.org/linux/man-pages/man5/proc_pid_oom_score_adj.5.html
Docker Docs — Resource constraints（memory options、OOME、--oom-kill-disable）: https://docs.docker.com/engine/containers/resource_constraints/
Kubernetes Docs — Resource Management for Pods and Containers: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
Kubernetes Docs — Pod Quality of Service Classes: https://kubernetes.io/docs/concepts/workloads/pods/pod-qos/

Docker 常用命令与实战：从入门到精通

Thu, 25 Jun 2026 15:30:00 +0000

前言

Docker 已经成为现代开发运维的基础设施。无论是本地开发环境搭建、微服务部署，还是 CI/CD 流水线，Docker 都扮演着核心角色。本文整理了 Docker 最常用的命令和实战技巧。

当前版本：Docker Engine v29.6.0（2026 年 6 月）。containerd 镜像存储已成为默认，Docker Scout 用于供应链安全扫描。

1. 镜像管理

1.1 拉取与查看

# 拉取镜像
docker pull nginx
docker pull nginx:1.25 # 指定版本
docker pull mysql:8.0
docker pull registry.cn-hangzhou.aliyuncs.com/library/nginx # 阿里云镜像

# 查看本地镜像
docker images
docker images -a # 包含中间层镜像
docker images --digests # 显示摘要
docker images -q # 只显示 ID

# 搜索镜像
docker search nginx
docker search --filter=stars=100 nginx # 按星数过滤

1.2 构建与删除

# 构建镜像
docker build -t myapp:1.0 .
docker build -t myapp:1.0 -f Dockerfile.prod .
docker build -t myapp:1.0 --no-cache . # 不使用缓存
docker build -t myapp:1.0 --build-arg ENV=prod . # 传入构建参数

# 删除镜像
docker rmi nginx
docker rmi $(docker images -q) # 删除所有镜像
docker image prune # 删除悬空镜像
docker image prune -a # 删除未使用的镜像

# 镜像打标签
docker tag myapp:1.0 myregistry.com/myapp:1.0
docker tag myapp:1.0 myregistry.com/myapp:latest

# 推送镜像
docker push myregistry.com/myapp:1.0

# 导出/导入镜像
docker save -o nginx.tar nginx:latest
docker load -i nginx.tar

2. 容器管理

2.1 创建与运行

# 基本运行
docker run nginx
docker run -d nginx # 后台运行
docker run --name my-nginx -d nginx # 指定名称
docker run -d -p 80:80 nginx # 端口映射
docker run -d -p 8080:80 nginx # 外部8080 → 容器80
docker run -d -p 127.0.0.1:3306:3306 mysql # 仅本地访问

# 带环境变量
docker run -d -e MYSQL_ROOT_PASSWORD=123456 mysql
docker run -d --env-file .env myapp # 从文件读取环境变量

# 挂载卷
docker run -d -v /host/path:/container/path nginx
docker run -d -v /data/mysql:/var/lib/mysql mysql
docker run -d -v mydata:/data nginx # 命名卷
docker run -d -v /host/path:/container/path:ro nginx # 只读挂载

# 限制资源
docker run -d --memory=512m --cpus=1.5 myapp
docker run -d --memory=1g --cpus=2 myapp

# 重启策略
docker run -d --restart=always nginx # 总是重启
docker run -d --restart=unless-stopped nginx # 除非手动停止
docker run -d --restart=on-failure:3 myapp # 失败最多重启3次

# 网络
docker run -d --network=host nginx # 使用宿主机网络
docker run -d --network=mynet myapp # 使用自定义网络

# 交互式运行
docker run -it ubuntu /bin/bash # 进入容器
docker run -it --rm ubuntu /bin/bash # 退出后自动删除

2.2 查看与操作

# 查看容器
docker ps # 运行中的容器
docker ps -a # 所有容器（含已停止）
docker ps -q # 只显示 ID
docker ps --format "table {{.ID}}\t{{.Names}}\t{{.Status}}\t{{.Ports}}"

# 查看容器详情
docker inspect my-nginx
docker inspect --format '{{.NetworkSettings.IPAddress}}' my-nginx

# 查看日志
docker logs my-nginx
docker logs -f my-nginx # 实时追踪
docker logs --tail 100 my-nginx # 最后100行
docker logs --since 1h my-nginx # 最近1小时
docker logs -f --tail 50 my-nginx # 实时追踪最后50行

# 进入运行中的容器
docker exec -it my-nginx /bin/bash
docker exec -it my-nginx /bin/sh # Alpine 镜像用 sh
docker exec my-nginx cat /etc/nginx/nginx.conf # 不进入执行命令

# 复制文件
docker cp file.txt my-nginx:/path/ # 容器 → 宿主机
docker cp my-nginx:/path/file.txt ./ # 宿主机 → 容器

# 停止/启动/重启
docker stop my-nginx
docker stop $(docker ps -q) # 停止所有容器
docker start my-nginx
docker restart my-nginx

# 删除容器
docker rm my-nginx
docker rm -f my-nginx # 强制删除运行中的容器
docker rm $(docker ps -aq) # 删除所有容器
docker container prune # 删除已停止的容器

# 查看容器资源使用
docker stats
docker stats --no-stream # 只显示一次
docker stats --format "table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}"

# 查看容器进程
docker top my-nginx

# 查看端口映射
docker port my-nginx

3. Dockerfile 编写

3.1 常用指令

# 基础镜像
FROM openjdk:17-jdk-slim
FROM node:18-alpine
FROM python:3.11-slim

# 维护者信息
LABEL maintainer="your@email.com"

# 工作目录
WORKDIR /app

# 复制文件
COPY package.json ./
COPY src/ ./src/
COPY --from=builder /app/dist ./dist # 多阶段构建

# 添加文件（支持 URL 和自动解压）
ADD app.tar.gz /app/
ADD https://example.com/file /app/

# 执行命令
RUN apt-get update && apt-get install -y \
 curl \
 vim \
 && rm -rf /var/lib/apt/lists/*

RUN npm install

# 环境变量
ENV NODE_ENV=production
ENV JAVA_OPTS="-Xmx512m"

# 暴露端口
EXPOSE 8080
EXPOSE 3306 6379

# 启动命令
CMD ["node", "server.js"]
CMD ["java", "-jar", "app.jar"]

# 入口点（不会被 docker run 的参数覆盖）
ENTRYPOINT ["java", "-jar"]
CMD ["app.jar"] # 默认参数，可被覆盖

# 健康检查
HEALTHCHECK --interval=30s --timeout=3s \
 CMD curl -f http://localhost:8080/health || exit 1

# 卷
VOLUME ["/data"]

# 用户
RUN useradd -r -s /bin/false appuser
USER appuser

3.2 多阶段构建

# 阶段一：构建
FROM maven:3.9-eclipse-temurin-17 AS builder
WORKDIR /app
COPY pom.xml .
RUN mvn dependency:go-offline
COPY src/ ./src/
RUN mvn package -DskipTests

# 阶段二：运行
FROM eclipse-temurin:17-jre-alpine
WORKDIR /app
COPY --from=builder /app/target/*.jar app.jar
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]

3.3 最佳实践

# ✅ 合并 RUN 指令减少层数
RUN apt-get update && apt-get install -y \
 curl \
 && rm -rf /var/lib/apt/lists/*

# ✅ 使用 .dockerignore
# .git, node_modules, *.log, .env

# ✅ 把变化频率低的指令放前面（利用缓存）
COPY package.json . # 先复制依赖文件
RUN npm install # 安装依赖
COPY . . # 最后复制源码

# ✅ 使用非 root 用户
RUN addgroup -S app && adduser -S app -G app
USER app

# ✅ 使用 Alpine 镜像减小体积
FROM node:18-alpine

4. 网络管理

# 创建网络
docker network create mynet
docker network create --driver bridge mynet
docker network create --subnet 172.20.0.0/16 mynet

# 查看网络
docker network ls
docker network inspect mynet

# 连接/断开网络
docker network connect mynet my-nginx
docker network disconnect mynet my-nginx

# 删除网络
docker network rm mynet
docker network prune # 删除未使用的网络

# 容器间通信（同一网络内可通过容器名访问）
docker run -d --name mysql --network=mynet mysql
docker run -d --name app --network=mynet myapp
# app 容器中可以直接用 mysql:3306 访问数据库

5. 数据卷管理

# 创建卷
docker volume create mydata

# 查看卷
docker volume ls
docker volume inspect mydata

# 删除卷
docker volume rm mydata
docker volume prune # 删除未使用的卷

# 使用命名卷
docker run -d -v mydata:/var/lib/mysql mysql

# 绑定挂载（目录映射）
docker run -d -v /host/path:/container/path nginx

# tmpfs 挂载（内存中）
docker run -d --tmpfs /app/cache myapp

6. Docker Compose

6.1 基本语法

# docker-compose.yml
version: '3.8'

services:
 web:
 build: .
 ports:
 - "8080:80"
 environment:
 - NODE_ENV=production
 volumes:
 - ./src:/app/src
 depends_on:
 - db
 - redis
 restart: unless-stopped
 networks:
 - app-net

 db:
 image: mysql:8.0
 environment:
 MYSQL_ROOT_PASSWORD: ${DB_PASSWORD}
 MYSQL_DATABASE: myapp
 volumes:
 - mysql-data:/var/lib/mysql
 - ./init.sql:/docker-entrypoint-initdb.d/init.sql
 ports:
 - "3306:3306"
 networks:
 - app-net

 redis:
 image: redis:7-alpine
 ports:
 - "6379:6379"
 networks:
 - app-net

volumes:
 mysql-data:

networks:
 app-net:
 driver: bridge

Docker Compose V1（docker-compose）已完全弃用，请使用 V2（docker compose，无连字符）。

6.2 常用命令

# 启动
docker compose up -d # 后台启动所有服务
docker compose up -d --build # 重新构建并启动
docker compose up -d web # 只启动指定服务

# 停止
docker compose down # 停止并删除容器
docker compose down -v # 同时删除卷
docker compose down --rmi all # 同时删除镜像

# 查看
docker compose ps # 查看服务状态
docker compose logs # 查看日志
docker compose logs -f web # 实时追踪指定服务日志

# 其他操作
docker compose exec web /bin/bash # 进入容器
docker compose restart web # 重启服务
docker compose pull # 拉取最新镜像
docker compose config # 验证配置文件
docker compose top # 查看进程

7. 实战场景

7.1 快速搭建 MySQL

docker run -d \
 --name mysql8 \
 -p 3306:3306 \
 -e MYSQL_ROOT_PASSWORD=123456 \
 -e MYSQL_DATABASE=mydb \
 -e MYSQL_USER=app \
 -e MYSQL_PASSWORD=apppwd \
 -v /data/mysql:/var/lib/mysql \
 --restart=unless-stopped \
 mysql:8.0 \
 --character-set-server=utf8mb4 \
 --collation-server=utf8mb4_unicode_ci

7.2 快速搭建 Redis

docker run -d \
 --name redis \
 -p 6379:6379 \
 -v /data/redis:/data \
 --restart=unless-stopped \
 redis:7-alpine \
 redis-server --appendonly yes --requirepass "mypassword"

7.3 快速搭建 Nginx

docker run -d \
 --name nginx \
 -p 80:80 \
 -p 443:443 \
 -v /data/nginx/conf.d:/etc/nginx/conf.d \
 -v /data/nginx/html:/usr/share/nginx/html \
 -v /data/nginx/ssl:/etc/nginx/ssl \
 --restart=unless-stopped \
 nginx:alpine

7.4 Java 应用部署

docker run -d \
 --name myapp \
 -p 8080:8080 \
 -e JAVA_OPTS="-Xmx512m -Xms256m" \
 -v /data/app/logs:/app/logs \
 -v /data/app/config:/app/config \
 --restart=unless-stopped \
 myapp:1.0

8. 常用技巧

# 清理所有未使用的资源（镜像、容器、网络、卷）
docker system prune -a --volumes
docker system df # 查看资源占用

# 批量操作
docker stop $(docker ps -q) # 停止所有容器
docker rm $(docker ps -aq) # 删除所有容器
docker rmi $(docker images -q) # 删除所有镜像

# 查看容器 IP
docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' my-nginx

# 导出/导入容器
docker export my-nginx > nginx.tar
docker import nginx.tar my-nginx:backup

# 查看镜像构建历史
docker history myapp:1.0

# 实时查看容器资源
docker stats --format "table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}\t{{.NetIO}}\t{{.BlockIO}}"

# 修改运行中容器的重启策略
docker update --restart=unless-stopped my-nginx

# 查看容器内文件系统变化
docker diff my-nginx

总结

Docker 核心知识点：

镜像管理 — pull/build/tag/push/save/load
容器管理 — run/exec/logs/stop/rm/stats
网络管理 — network create/connect/inspect
数据卷 — volume create/bind mount/tmpfs
Dockerfile — 多阶段构建、最佳实践
Docker Compose — 多服务编排、依赖管理

掌握这些命令，就能应对 90% 以上的日常 Docker 操作。

Docker 安装达梦 DM8

Tue, 28 Apr 2026 10:00:00 +0000

背景

近期开源项目 SmartAdmin 的很多用户反馈需要支持达梦数据库，现在将 docker 安装达梦数据库记录下来，以便让更多有需要的技术人员看到，节省时间。

1、提前准备

环境为：Linux 系统 CentOS 8，达梦数据库为达梦 DM8 版本，单机版。

2、下载达梦镜像

达梦官方下载地址为：eco.dameng.com/download/，可能已经不提供 Docker 镜像下载。

所以请从笔者百度网盘下载：

链接: pan.baidu.com/s/1SsQK7mlJ
提取码: d83h
下载文件：dm8_20240715_x86_rh6_rq_single.tar.zip

3、上传并解压

1）将 dm8_20240715_x86_rh6_rq_single.tar.zip 上传到 Linux 服务器 CentOS 中

2）将其解压：

unzip dm8_20240715_x86_rh6_rq_single.tar.zip

4、加载 DM8 镜像到 Docker 中

1）进入镜像 dm8_20240715_x86_rh6_rq_single.tar 文件所在目录

2）执行加载命令：

docker load -i dm8_20240715_x86_rh6_rq_single.tar

3）检查是否成功加载 DM8 镜像：

docker images

5、明确启动容器参数

端口 15236
容器名字 dm8
不开启大小写敏感 -e CASE_SENSITIVE=0
数据映射目录：/home/database/dm8/data
字符集 UTF-8 -e UNICODE_FLAG=1
实例名称 -e INSTANCE_NAME=dm8_smartadmin

最终明确启动参数如下：

docker run -dit \
-p 15236:5236 \
--restart=always \
--name dm8 \
--privileged=true \
-e PAGE_SIZE=16 \
-e LD_LIBRARY_PATH=/opt/dmdbms/bin \
-e EXTENT_SIZE=32 \
-e BLANK_PAD_MODE=1 \
-e LOG_SIZE=1024 \
-e UNICODE_FLAG=1 \
-e LENGTH_IN_CHAR=1 \
-e CASE_SENSITIVE=0 \
-e INSTANCE_NAME=dm8_smartadmin \
-v /home/database/dm8/data:/opt/dmdbms/data \
dm8_single:dm8_20240715_rev232765_x86_rh6_64

6、启动容器

将上面的启动参数命令进行执行，查看是否启动成功：

docker ps

7、启动/停止/重启

docker stop dm8
docker start dm8
docker restart dm8

8、进入容器

进入容器命令为：

docker exec -it dm8 bash

9、其他注意事项

Docker 镜像中数据库默认用户名/密码为 SYSDBA/SYSDBA001

基于Cloud-Init的Proxmox VE虚拟机模板创建与Docker部署指南

Sun, 27 Apr 2025 14:55:08 +0800

基于Cloud-Init的Proxmox VE虚拟机模板创建与Docker部署指南

一、准备工作

下载Cloud Image镜像
Cloud Images是预装Cloud-Init的轻量级系统镜像，支持快速初始化配置（如网络、用户、SSH密钥等）。以Debian 12为例：
```
wget https://cloud.debian.org/images/cloud/bookworm/latest/debian-12-generic-amd64.qcow2
```
创建虚拟机
- 在PVE中新建虚拟机（VM ID自选，例如900），不创建硬盘，操作系统类型选择Linux，机型选择i440fx或q35均可。
- 添加Cloud-Init设备：在虚拟机硬件设置中点击“添加”→“Cloud-Init设备”，选择存储位置（如local-lvm）。
导入磁盘镜像
将下载的Cloud Image导入虚拟机：
```
qm importdisk 900 debian-12-generic-amd64.qcow2 local-lvm --format=qcow2
```
完成后在虚拟机硬件中挂载该磁盘，总线类型选择SCSI，并设置为首选启动项。

二、配置Cloud-Init

基础设置
在PVE的Cloud-Init配置界面填写以下信息：
- 用户：默认用户（Debian为debian，Ubuntu为ubuntu），可自定义用户名（如admin）。
- 密码：设置用户密码（建议设置，否则无法通过控制台登录）。
- SSH公钥：粘贴本地~/.ssh/id_rsa.pub公钥内容，启用密钥登录。
- IP配置：选择DHCP自动获取或静态IP（示例：ip=192.168.1.100/24,gw=192.168.1.1）。
- DNS：设置域名服务器（如8.8.8.8）。

防止配置重置
修改Cloud-Init默认行为，避免重启后/etc/hosts和/etc/resolv.conf被重置：

sudo sed -i 's/^update_etc_hosts/#update_etc_hosts/' /etc/cloud/cloud.cfg
sudo rm /etc/resolv.conf && sudo ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf

三、系统初始化

更新系统与工具安装

sudo apt update && sudo apt upgrade -y
sudo apt install -y curl vim net-tools qemu-guest-agent
sudo systemctl enable --now qemu-guest-agent

配置时区与语言

sudo timedatectl set-timezone Asia/Shanghai
sudo localectl set-locale LANG=en_US.UTF-8 # 避免中文乱码

四、安装最新版Docker

使用官方脚本安装

curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh

配置Docker服务与用户组

sudo systemctl enable docker
sudo usermod -aG docker &#36;USER # 当前用户加入docker组
newgrp docker # 立即生效（或重启）

安装Docker Compose
下载最新稳定版（以v2.27.0为例）：

DOCKER_COMPOSE_VERSION="v2.27.0"
sudo curl -L "https://github.com/docker/compose/releases/download/&#36;{DOCKER_COMPOSE_VERSION}/docker-compose-&#36;(uname -s)-&#36;(uname -m)" -o /usr/local/bin/docker-compose
sudo chmod +x /usr/local/bin/docker-compose

验证安装

docker --version # 输出Docker版本
docker-compose --version # 输出Compose版本
docker run hello-world # 运行测试容器

五、模板化与克隆

清理临时文件
```
sudo apt clean
sudo cloud-init clean
```
关闭虚拟机并转换为模板
- 在PVE界面中关闭虚拟机。
- 右键虚拟机选择“转换为模板”。
基于模板克隆新虚拟机
- 右键模板选择“克隆”，设置新VM ID及名称。
- 启动克隆的虚拟机时，Cloud-Init会自动应用新配置（如新IP、主机名）。

六、常见问题

网络配置失效：检查Cloud-Init的IP设置或手动修改/etc/network/interfaces。
Docker权限问题：确保用户已加入docker组，执行newgrp docker或重启系统。
镜像扩容：若需扩展磁盘，在PVE中调整磁盘大小后，在虚拟机内执行sudo growpart /dev/sda 1 && sudo resize2fs /dev/sda1。

Debian12 安装Docker及Docker-compose

Sun, 17 Dec 2023 18:10:00 +0800

在 Debian 12 上安装最新版的 Docker 和 Docker Compose 可以按照以下步骤进行。以下指南将带您通过安装 Docker Engine、配置 Docker 官方仓库以及安装 Docker Compose 的最新版本。

一、更新系统

首先，确保您的系统包索引是最新的，并安装必要的依赖包。

sudo apt update
sudo apt upgrade -y
sudo apt install -y ca-certificates curl gnupg lsb-release

二、添加 Docker 官方的 GPG 密钥

为了确保下载的软件包的安全性，需要添加 Docker 的官方 GPG 密钥。

sudo mkdir -p /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/debian/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

三、设置 Docker 仓库

将 Docker 的官方仓库添加到 APT 源中。

echo "deb [arch=&#36;(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/debian &#36;(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

四、安装 Docker Engine、Docker CLI 和 containerd

首先，更新包索引，然后安装 Docker Engine 及其组件。

sudo apt update

sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

注意：docker-compose-plugin 是 Docker 官方提供的 Compose 插件，可以作为 Docker CLI 的一部分使用。如果您需要独立的 Docker Compose，可参考后续步骤。

五、启动并启用 Docker 服务

确保 Docker 服务已启动并设置为开机自启。

sudo systemctl start docker

sudo systemctl enable docker

六、验证 Docker 安装

通过运行一个测试容器来验证 Docker 是否正确安装。

sudo docker run hello-world

如果看到类似 “Hello from Docker!” 的输出，说明 Docker 已成功安装。

七、安装 Docker Compose 最新版

虽然前面的步骤已经安装了 docker-compose-plugin，您可能仍然希望安装独立的 Docker Compose，以便使用 docker-compose 命令。以下是安装最新版 Docker Compose 的步骤：

获取最新的 Docker Compose 版本号

访问 Docker Compose 的 GitHub 发布页面获取最新版本号。例如，假设最新版本是 v2.20.2。

下载 Docker Compose 二进制文件

使用 curl 下载适用于 Linux 的 Docker Compose 二进制文件，并将其移动到 /usr/local/bin 目录。

DOCKER_COMPOSE_VERSION=&#36;(curl -s https://api.github.com/repos/docker/compose/releases/latest | grep tag_name | cut -d '"' -f 4)

sudo curl -L "https://github.com/docker/compose/releases/download/&#36;{DOCKER_COMPOSE_VERSION}/docker-compose-&#36;(uname -s)-&#36;(uname -m)" -o /usr/local/bin/docker-compose

赋予可执行权限

sudo chmod +x /usr/local/bin/docker-compose

创建符号链接（可选）

为了便于使用 docker-compose 命令，可以创建一个符号链接到 /usr/bin。

sudo ln -s /usr/local/bin/docker-compose /usr/bin/docker-compose

验证 Docker Compose 安装

docker-compose --version

您应该会看到类似 docker-compose version 2.20.2, build … 的输出，确认安装成功。

八、配置当前用户使用 Docker（可选）

为了避免每次运行 Docker 命令时都需要使用 sudo，可以将当前用户添加到 docker 组中。

sudo usermod -aG docker &#36;USER

注意：执行上述命令后，您需要重新登录才能使组更改生效。

九、测试无 sudo 的 Docker 命令

重新登录后，运行以下命令以确认是否可以不使用 sudo 运行 Docker 命令：

docker run hello-world

如果看到 “Hello from Docker!” 的输出，说明配置成功。

Docker on 吾爱主机

Docker 桥接网络与嵌入式 DNS：原理、连通性与工程实践

一、问题背景：容器眼里只有网卡，没有“魔法互联”

二、核心机制：bridge 网络在做什么

2.1 软件桥与隔离边界

2.2 内置驱动速览（选型锚点）

2.3 默认 bridge vs 用户自定义 bridge（必须分清）

2.4 嵌入式 DNS：127.0.0.11

2.5 端口可达性与防火墙协作

2.6 Compose 如何落地同一套模型

三、实践：可复现的连通性与 DNS 实验

3.1 观察 default bridge：能通 IP，不能靠名字

3.2 用户自定义 bridge：容器名解析 + 127.0.0.11

3.3 “前后端分离网络”拓扑（多网卡容器）

3.4 Compose 最小可运行示意

3.5 关闭 ICC（强制“不能随意横穿”）

四、常见坑与排查清单

五、工程建议（可直接落到规范）

六、总结

参考资料

OceanBase 多平台搭建教程：Linux / Windows / macOS / Docker 从零到可连接

一、先选对安装路径

资源底线（很重要）

二、通用概念：端口、租户、客户端

三、最快路径：Docker（Linux / Windows / macOS 通用）

1. 前置条件

2. 启动实例

3. 等待 bootstrap 完成

4. 连接验证

5. 常用运维命令

6. 初始化 SQL（可选）

四、Linux 原生：all-in-one + OBD（官方推荐体验路径）

1. 一键安装 all-in-one

2. 一键拉起演示实例

3. 单独安装 OBD（CentOS/RHEL 系）

4. obd demo 前自检清单

五、Windows 搭建

方案 A：Docker Desktop（最简单）

方案 B：WSL2 + Linux 路径

六、macOS 搭建

1. 安装 Docker Desktop for Mac

2. 启动 OceanBase

3. 连接

4. macOS 特别提醒

七、进阶：Kubernetes 与多节点

1. Kubernetes：ob-operator

2. OBD 自定义集群

八、连接后的最小验收清单

九、常见问题排查

1. 容器一直起不来 / 没有 boot success!

2. 2881 端口冲突

3. Docker Hub 拉取失败

4. 能进容器但不能从宿主机连接

5. obd demo 预检失败

十、平台选型建议（实战版）

十一、精简命令速查

Docker（全平台）

Linux all-in-one

OBD RPM（CentOS/RHEL）

总结

参考资料

Linux cgroup v2 内存控制与 OOM Killer：原理、观测与容器化实践

一、先建立两层模型：全局 OOM vs cgroup OOM

二、cgroup v2 的内存阶梯：min / low / high / max

1. 为什么要有 high，而不是只设 max？

2. min/low 保护不是免费的

三、OOM Killer：它到底怎么选人

1. 评分：oom_score 与 oom_score_adj

2. 系统级可调旋钮（/proc/sys/vm/*）

3. cgroup 内 OOM 的边界

四、工程映射：Docker 与 Kubernetes

1. Docker：把 limit 落到 cgroup

2. Kubernetes：request / limit / QoS / 驱逐

五、可复现观测：别等 dmesg 再救火

1. 先确认 cgroup v2 与容器路径

2. 读 memory 接口（容器内或宿主机 cgroup 路径）

3. 看谁更容易被杀

4. 对照内核日志

六、常见坑与排查清单

坑 1：只设 request，不设 limit

2.4 嵌入式 DNS：`127.0.0.11`

3.2 用户自定义 bridge：容器名解析 + `127.0.0.11`

4. `obd demo` 前自检清单

1. Kubernetes：`ob-operator`

1. 容器一直起不来 / 没有 `boot success!`

2. `2881` 端口冲突

5. `obd demo` 预检失败

1. 为什么要有 `high`，而不是只设 `max`？

2. `min`/`low` 保护不是免费的

1. 评分：`oom_score` 与 `oom_score_adj`

2. 系统级可调旋钮（`/proc/sys/vm/*`）

坑 2：limit 设太紧，没有 `high` 缓冲与观测

坑 3：把 `oom_score_adj=-1000` 到处贴

坑 4：`--oom-kill-disable` 却没有硬上限