容器 on Liangweidong's blog

Docker 安装与基础：从 docker-ce/ee 拆分到多场景落地的完整路径

Mon, 15 Aug 2022 00:00:00 +0800

容器化已经是后端服务的标配，而 Docker 几乎是入门的"必经之地"。从 2013 年 Docker 公开，到 2017 年 Docker 公司宣布拆分社区版（docker-ce）和企业版（docker-ee），再到 2019 年底 Mirantis 接手 Docker Enterprise 业务、2020 年 Docker 把 buildx 收为官方 CLI 插件、2022 年 Kubernetes 1.24 移除 dockershim 引入 cri-dockerd——九年间，Docker 生态的"安装"二字已经远不止 apt install docker.io 那么简单。

这篇文章把零散的安装笔记、版本对比、配置细节整理成一条"从选型到可用"的完整路径，适合刚接触 Docker、或在新机器上做标准化的同学。

阅读对象：需要在 Linux 服务器上从零部署 Docker 的开发者、运维同学
覆盖范围：docker-ce / docker-ee / docker.io 三种发行版差异 + Debian/Ubuntu/Kali/CentOS 主流安装方式 + 离线部署（含 cri-dockerd、buildx、docker-compose v2）+ daemon.json 关键配置 + 清理卸载 + 常见排障

一、为什么需要 Docker

容器不是"更轻的虚拟机"那么简单。在引入 Docker 之前，团队通常被这些痛点反复折磨：

环境漂移：开发用 macOS、测试用 CentOS、生产用 Ubuntu，works on my machine 反复出现
资源浪费：一台物理机只跑两三个 Java 应用，资源利用率不足 20%
交付链条长：应用 + 运行时 + 依赖 + 配置，要运维一台台机器"对版本"
扩缩容难：业务流量上来后，手动扩容几台机器要写一堆脚本
与 K8s 集成难：容器运行时直接对接 kubelet 的 dockershim 接口一改，整个集群要重新适配

Docker 把应用 + 运行时 + 依赖打包成"镜像"，在装有 Docker 引擎的任意机器上一键运行，保证开发、测试、生产环境的一致性。这正是它被广泛接受的根本原因。

When to use：单体应用拆成多服务时、新人 onboard 需要快速搭建环境时、CI/CD 需要稳定可复现的构建产物时，Docker 几乎是首选解。从 LXC 时代走过来，Docker 通过标准化的镜像格式（OCI 规范）、BuildKit 构建系统和 Compose 编排，把"环境一致性"变成了开箱即用的能力。

二、版本选型：docker-ce / docker-ee / docker.io 的真实差异

2017 年 3 月 Docker 公司宣布将 Docker 拆分为两条产品线：开源的 Docker Community Edition（CE） 和商业的 Docker Enterprise Edition（EE）。这次拆分不是营销行为，而是把"包结构"和"维护承诺"做了明确切割——CE 由 Docker Inc. 维护源码、每月发布一次社区版；EE 在 CE 基础上叠加企业级功能，按"基本/标准/高级"三级订阅。

发行版	来源	特点	适用场景
`docker.io`	Debian / Ubuntu / Kali 官方仓库	由发行版包管理器接管依赖，升级时主程序与系统库同步更新；有时版本比 docker-ce 还新	服务器首选 Debian / Ubuntu 系列，追求"系统包管一切"
`docker-ce`	`download.docker.com` 官方源	Docker Inc. 维护源码，用 Go 把依赖尽量静态封装在一个包里，跨发行版一致	CentOS / RHEL / 任何需要"同一版本跑所有机器"的场景
`docker-ee`	Mirantis 客户专用仓库	在 CE 之上叠加 LDAP/AD 集成、RBAC、镜像安全扫描、连续漏洞监控等企业级能力	大型企业、需要 Docker Inc. / Mirantis 商业支持的客户

历史注脚：2019 年 11 月，Mirantis 收购了 Docker 的企业业务（包括 docker-ee 品牌）。所以现在严格意义上"docker-ee"是 Mirantis 商业产品线，而非 Docker Inc. 的产品。如果用 docker-ee 走商业支持，签合同的对象是 Mirantis。

docker-ce 的"致命缺陷"——依赖管理：

docker-ce 把 Docker 引擎依赖的成百上千个第三方库（glibc、openssl、libseccomp、containerd、runc 等）尽量静态或动态链接到自己的包里。这意味着理论上只要其中一个依赖出 CVE，整套 docker-ce 都得重新打补丁、重建二进制、再分发。反观 docker.io，依赖托管给系统包管理器，只需要升级 docker 主程序、系统的 libseccomp 等库跟随 Debian Security Advisory / USN 自动推补丁。

结论：

Debian / Ubuntu / Kali 服务器：直接 apt install docker.io，让系统接管一切
其他发行版（CentOS / RHEL / Amazon Linux / SUSE）：走 docker-ce 官方源或 get-docker.sh 脚本
商业场景：评估 docker-ee / Mirantis Container Cloud 的 SLA 与支持响应

三、Debian / Ubuntu / Kali 系安装

3.1 路线 A：apt 安装 docker.io（推荐）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# 推荐安装
apt install -y docker.io

# 更新
apt update
apt upgrade -y docker.io

# 验证
docker --version
docker run --rm hello-world

docker.io 包是 Debian / Ubuntu 官方基于 Docker 社区源码封装的版本，特点是把 Docker 的依赖直接转接到主系统。换句话说，系统的 glibc / openssl / libseccomp 升级时，docker.io 自动跟随，不需要 Docker Inc. 单独发版。

3.2 路线 B：apt 安装 docker-ce

如果团队要求"全机器统一 Docker 版本"（比如某条线 CI 必须用 20.10.x），或者 Debian stable 仓库里的 docker.io 太老，就走 docker-ce 源：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


# 1. 卸载旧版本（如果存在）
for pkg in docker.io docker-doc docker-compose podman-docker containerd runc; do
 apt-get remove -y $pkg
done

# 2. 加 Docker 官方 GPG key
apt-get update
apt-get install -y ca-certificates curl gnupg
install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/$(. /etc/os-release && echo "$ID")/gpg | gpg --dearmor -o /etc/apt/keyrings/docker.gpg
chmod a+r /etc/apt/keyrings/docker.gpg

# 3. 加 docker-ce 源
echo \
 "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/$(. /etc/os-release && echo "$ID") \
 $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
 tee /etc/apt/sources.list.d/docker.list > /dev/null

apt-get update

# 4. 装最新 docker-ce
apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

注意：从 20.10 起，官方推荐把 buildx 和 docker-compose 作为插件（plugin）安装，文件落在 /usr/libexec/docker/cli-plugins/。这是为了和 Docker CLI 解耦，buildx 可以独立升级。

3.3 卸载 Debian/Ubuntu 系

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


# 1. 删主程序（含 docker-ce / docker-ee / docker.io / containerd / runc）
apt-get autoremove docker docker-ce docker-ee docker.io containerd runc

# 2. 查残留
dpkg -l | grep docker

# 3. 清理无用的相关配置文件（^rc 表示已删但留配置）
dpkg -l | grep ^rc | awk '{print $2}' | sudo xargs dpkg -P

# 4. 删 docker-ce-* 子包
apt-get autoremove docker-ce-*

# 5. 删残留目录（关键！apt remove 不会动这些）
rm -rf /etc/systemd/system/docker.service.d
rm -rf /var/lib/docker # 镜像、卷、网络元数据全在这
rm -rf /etc/docker # daemon.json 在这
rm -rf /var/run/docker.sock

# 6. 删 docker 用户组
groupdel docker

# 7. 验证
docker --version # 应该报 command not found

Why 这样卸载：apt remove 只会删主程序二进制，/var/lib/docker 下的镜像、卷、网络、自定义配置都还在；不删干净的话，新装 docker 时旧配置会"莫名生效"，排查很痛苦。

四、CentOS / RHEL 系安装

4.1 加 docker-ce 源

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


# 安装 yum-utils
sudo yum install -y yum-utils

# Docker 官方源
sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo

# 国内源（阿里云）
sudo yum-config-manager --add-repo https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo

# 或者直接 wget
wget https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo \
 -O /etc/yum.repos.d/docker-ce.repo

# 查看可装版本
yum list docker-ce --showduplicates | sort -r
# 输出类似：
# docker-ce.x86_64 20.10.21-3.el8 docker-ce-stable
# docker-ce.x86_64 18.03.1.ce-1.el7.centos docker-ce-stable

4.2 安装

1
2
3
4
5
6


# 推荐：装 docker-ce + CLI + containerd + buildx + compose 插件
sudo yum install -y docker-ce docker-ce-cli containerd.io \
 docker-buildx-plugin docker-compose-plugin

# 装指定版本
yum -y install docker-ce-20.10.21-3.el8

4.3 卸载 CentOS/RHEL

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


# 查看已装包
rpm -qa | grep docker

# 典型输出（旧版本可能含 python36-docker-*）：
# python36-docker-2.6.1-3.el7.noarch
# docker-client-1.13.1-209.git7d71120.el7.centos.x86_64
# docker-1.13.1-209.git7d71120.el7.centos.x86_64
# docker-compose-1.18.0-4.el7.noarch
# docker-common-1.13.1-209.git7d71120.el7.centos.x86_64

# 一次性卸载
yum remove -y python36-docker-* docker-client-* docker-* \
 docker-compose-* docker-common-*

# 残留目录处理同 Debian
rm -rf /var/lib/docker /etc/docker /var/run/docker.sock

五、官方脚本通用安装

适合任何 Linux 发行版（CentOS、Ubuntu、Debian、Amazon Linux 等），是 Docker 官方最推荐的安装方式之一。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


# 方式 1：直接管道执行
curl -fLsS https://get.docker.com/ | sh

# 方式 2：下载脚本本地执行（推荐，便于审计）
curl -fsSL https://get.docker.com -o get-docker.sh
DRY_RUN=1 sh ./get-docker.sh # 可选：dry-run 看看会装什么
sudo sh get-docker.sh

# 方式 3：阿里云镜像
curl -fsSL https://get.docker.com | bash -s docker --mirror Aliyun

# 方式 4：DaoCloud 镜像
curl -sSL https://get.daocloud.io/docker | sh

get-docker.sh 会自动检测发行版、加源、装最新稳定版 docker-ce。CentOS 7 系列会自动停用旧版 docker 包，升级到 docker-ce。

六、离线安装

内网 / 无外网环境的标准做法。原理就是先在外网打包好 Docker 的静态二进制 + 依赖 + 配套工具（buildx / docker-compose / cri-dockerd），再传到内网机器解包、注册 systemd unit。

6.1 下载离线包

组件	下载地址
Docker 静态二进制	https://download.docker.com/linux/static/stable/x86_64/
阿里云镜像加速	https://cr.console.aliyun.com/cn-hangzhou/instances/mirrors
第三方整合脚本	https://gist.github.com/y0ngb1n/7e8f16af3242c7815e7ca2f0833d3ea6

以 Docker 24.0.7 为例，下载后是一组独立二进制：docker、docker-init、dockerd、runc、ctr、containerd-shim-runc-v2、containerd、docker-proxy。

6.2 解包并安装

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


# 解压
tar xvf docker-24.0.7.tgz

# 拷贝二进制到 PATH 目录
cp docker/* /usr/bin

# 准备 containerd 配置（containerd.io 默认配置）
mkdir -p /etc/containerd
containerd config default | tee /etc/containerd/config.toml

# 创建 / 启用 docker systemd unit
systemctl daemon-reload
systemctl enable --now containerd.service
systemctl enable --now docker.service
systemctl enable --now docker.socket

# 验证
docker info
docker run --rm hello-world

2018 时代差异：早期 Docker 还是用 vim /etc/init.d/docker + service docker start + chkconfig docker on 三件套。现在统一走 systemd：写 /etc/systemd/system/docker.service.d/*.conf 覆盖、systemctl daemon-reload、systemctl restart docker。

6.3 配套组件：cri-dockerd（K8s 1.24+ 必装）

Kubernetes 1.24（2022 年 5 月 GA）移除了内置的 dockershim，CRI 改由 containerd / CRI-O 直接对接。如果还想用 Docker 作为 K8s 容器运行时，必须装 cri-dockerd——它把 Docker Engine 重新"翻译"成 CRI 接口给 kubelet 用。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


# 下载 cri-dockerd（与 docker 版本匹配）
curl -fL https://github.com/Mirantis/cri-dockerd/releases/download/v0.3.9/cri-dockerd-0.3.9.amd64.tgz \
 -o /tools/cri-dockerd-0.3.9.amd64.tgz

# 解压
tar xf /tools/cri-dockerd-*.amd64.tgz -C /tools
cp /tools/cri-dockerd/cri-dockerd /usr/local/bin

# 注册 systemd unit
systemctl daemon-reload
systemctl enable --now cri-docker.socket
systemctl enable --now cri-docker.service

# 在 kubeadm init 时指定：
# kubeadm init --cri-socket=unix:///var/run/cri-dockerd.sock

Mirantis 出品：cri-dockerd 是 Mirantis（2019 年接手 Docker Enterprise 的公司）维护的开源项目，所以 Mirantis/cri-dockerd 这个 GitHub 路径是规范来源。

6.4 配套组件：buildx（多架构构建）

buildx 是 Docker 公司在 2020 年 9 月推出的 BuildKit CLI 插件，用来取代老的 docker build。它支持：

多架构构建：一条命令同时打 linux/amd64 和 linux/arm64 镜像
缓存导出：把构建缓存 push 到 registry，下次 docker build 直接命中
BuildKit 高级特性：并发构建、secrets 挂载、SSH 转发

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


# 安装（在 docker-ce 20.10+ 已经是默认插件）
apt install -y docker-buildx-plugin # Debian/Ubuntu
yum install -y docker-buildx-plugin # CentOS

# 或者从 release 二进制
mkdir -p ~/.docker/cli-plugins
curl -fsSL https://github.com/docker/buildx/releases/download/v0.10.4/buildx-v0.10.4.linux-amd64 \
 -o ~/.docker/cli-plugins/docker-buildx
chmod +x ~/.docker/cli-plugins/docker-buildx

# 创建多架构 builder
docker buildx create --name multiarch --driver docker-container --use
docker buildx inspect --bootstrap

# 跨架构构建示例
docker buildx build \
 --platform linux/amd64,linux/arm64 \
 --tag your-registry.com/your-app:v1.0 \
 --push .

6.5 配套组件：docker-compose v1 / v2 选择

版本	发布时间	形态	现状
Compose v1	2014-07	独立二进制 `docker-compose`（Python 写）	已弃用，2023 年起 Docker Desktop 不再预装
Compose v2	2020-08	Docker CLI 插件 `docker compose`（空格，无连字符）	当前推荐，统一走 Go 重写

离线安装 Compose v1（如果有遗留项目依赖 v1）：

1
2
3


cp /tools/docker_compose /usr/local/bin
chmod +x /usr/local/bin/docker-compose
docker-compose --version

离线安装 Compose v2（推荐）：

1
2
3
4
5


mkdir -p /usr/local/lib/docker/cli-plugins
curl -fsSL https://github.com/docker/compose/releases/download/v2.21.0/docker-compose-linux-x86_64 \
 -o /usr/local/lib/docker/cli-plugins/docker-compose
chmod +x /usr/local/lib/docker/cli-plugins/docker-compose
docker compose version # 注意：v2 是空格

七、验证安装

任何安装方式，最后都要做这几步验证：

1
2
3
4
5
6


systemctl status docker # 状态是否 active
systemctl start docker # 没起就启动
systemctl enable docker # 开机自启
docker info # 引擎详细信息（看 Storage Driver / Cgroup Driver / Registry Mirrors）
docker version # 客户端/服务端版本
docker run --rm hello-world # 跑一个最小测试容器

hello-world 能正常打印 “Hello from Docker!” 就算通了。

八、关键配置：daemon.json

/etc/docker/daemon.json 是 Docker Daemon 的主配置文件。90% 的日常配置都在这里。

8.1 推荐模板

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


{
 "exec-opts": ["native.cgroupdriver=systemd"],
 "log-driver": "json-file",
 "log-opts": { "max-size": "50m", "max-file": "3" },
 "registry-mirrors": [
 "https://docker.m.daocloud.io",
 "https://hub-mirror.c.163.com",
 "https://mirror.baidubce.com",
 "https://docker.nju.edu.cn",
 "https://docker.mirrors.sjtug.sjtu.edu.cn"
 ],
 "insecure-registries": [],
 "live-restore": true,
 "storage-driver": "overlay2"
}

8.2 关键字段说明

字段	作用	建议值
`exec-opts.cgroupdriver`	cgroup 驱动	K8s 节点推荐 `systemd`（与 kubelet 保持一致）
`log-driver`	日志驱动	生产环境 `json-file` 或 `journald`
`log-opts.max-size`	单个日志文件大小	`50m` 避免撑爆磁盘
`log-opts.max-file`	保留日志文件数	`3`~`5`，轮转策略
`registry-mirrors`	镜像加速器	国内服务器必加，否则 `docker pull` 慢到怀疑人生
`insecure-registries`	信任的 HTTP 私有仓库	内网 registry 才需要，格式 `IP:PORT`
`live-restore`	Daemon 重启时容器不中断	K8s 节点必须开，否则 kubelet 升级 Docker 就会重启所有 Pod
`storage-driver`	镜像 / 容器分层存储	`overlay2`（CentOS 7.4+ / Ubuntu 18.04+ / Debian 10+ 默认）

8.3 应用配置

1
2
3
4
5
6
7
8


systemctl daemon-reload
systemctl restart docker

# 验证镜像加速生效
docker info | grep -A 10 "Registry Mirrors"

# 验证 live-restore
docker info | grep -i live

进一步可以用 time docker pull nginx:latest 测速，能从几十秒压到几秒就算 mirror 生效。

九、live-restore：K8s 节点的隐藏必修项

Live Restore 是 Docker Daemon 的一项"升级 / 重启不打断容器"的特性。对 K8s 节点来说这是必修项——kubelet 升级、操作系统补丁、daemon 自身重启时，节点上的 Pod 不能因此被重启。

开启方式：

1
2
3
4


// /etc/docker/daemon.json
{
 "live-restore": true
}

1
2
3
4
5
6


systemctl daemon-reload
sudo systemctl reload docker.service # 注意是 reload，不是 restart

# 验证
docker info | grep -i live
# 应输出：Live Restore Enabled: true

集群环境下，daemon.json 改完用 scp + ssh 推送到所有 master / worker 节点：

1
2
3
4
5


for NODE in master2 master3 worker1 worker3 worker4; do
 echo $NODE
 scp /etc/docker/daemon.json $NODE:/etc/docker/
 ssh root@$NODE "systemctl daemon-reload && systemctl reload docker"
done

十、存储卷（Volume）基础

容器文件系统是分层的、临时的，docker rm 之后容器内的数据就没了。生产数据（数据库、用户上传、配置）必须挂到 volume 上。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# 创建
docker volume create my-data

# 查看
docker volume ls

# 查看详细信息（包含 mount point）
docker volume inspect my-data

# 删除单个
docker volume rm my-data

# 删除所有未被引用的卷
docker volume prune

-v 挂载用法：

1
2
3
4


docker run -d --name mysql \
 -v mysql_data:/var/lib/mysql \
 -e MYSQL_ROOT_PASSWORD=xxx \
 mysql:8.0

关键警告：docker volume prune 会永久删除未被任何容器引用的卷，里面如果有数据库 / 业务数据，删了就没了——生产环境慎用。删之前先 docker volume ls + docker volume inspect 逐个确认。

十一、网络模式与网桥清理

11.1 docker0 网桥

Docker 进程启动时，会在主机上创建一个名为 docker0 的虚拟网桥，默认地址 172.17.0.0/16。所有以 Bridge 模式启动的容器都"插"到这个虚拟交换机上，通过 docker0 ↔ 物理网卡 eth0 ↔ 外部网络。

如果想彻底关掉默认网桥（自定义网络场景）：

1
2
3
4
5


// /etc/docker/daemon.json
{
 "iptables": false,
 "bridge": ""
}

1
2


systemctl daemon-reload
systemctl restart docker

注意：删 docker0 是一次性的——下次 daemon 启动没指定 -b 参数又会自动重建。一般用 daemon.json 里的 bridge: "" 永久关闭更稳妥。

11.2 容器从网桥上摘除

1
2


# 把某个容器从默认 bridge 网络上摘除
docker network disconnect -f bridge container-name

十二、基础清理

跑完一轮测试容器之后，会留下不少"垃圾"。下面是分级清理命令：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# 删除所有未使用的对象（停掉的容器、dangling 镜像、未用网络）
docker system prune -f

# 包括未使用的卷（危险：会丢数据）
docker system prune -f --volumes

# 只删未使用的网络
docker network prune -f

# 只删 12 小时前创建的网络
docker network prune -a --filter "until=12h"

# 只删 24 小时前没用的镜像
docker image prune -a --filter "until=24h"

核心要点 / 常见坑：

docker system prune --volumes 会删未挂载的卷，里面如果残留数据库数据，删了就没了——生产慎用
dangling 镜像指的是无 tag 的中间层镜像（<none>:<none>），安全可删
想看"能删多少"先用 docker system df 看磁盘占用
docker system df -v 还能看到每个 volume / image 占多少空间，方便定位"硬盘杀手"

十三、镜像代理（应对国内拉镜像慢）

拉 Docker Hub / ghcr / gcr / k8s.gcr.io / quay.io 镜像在国内慢到超时是常态。常见做法是用镜像代理做反代。

原始 registry	代理写法（以 `dockerproxy.com` 为例）
Docker Hub	`docker pull dockerproxy.com/library/nginx:latest`
GHCR	`docker pull ghcr.dockerproxy.com/username/image:tag`
GCR	`docker pull gcr.dockerproxy.com/username/image:tag`
k8s.gcr.io / registry.k8s.io	`docker pull k8s.dockerproxy.com/coredns:1.6.5`
Quay.io	`docker pull quay.dockerproxy.com/username/image:tag`

南京大学 GHCR 镜像：ghcr.nju.edu.cn 是国内 GHCR 加速的另一个选择，直接把 ghcr.io/xxx 替换为 ghcr.nju.edu.cn/xxx 即可。

如果嫌每个镜像都改前缀麻烦，直接配 daemon.json 的 registry-mirrors（见第八节）就能让所有 docker pull 走代理。

十四、常见问题速查

报错	原因	解决
`permission denied` 访问 `/var/run/docker.sock`	当前用户不在 docker 组	`sudo usermod -aG docker $USER`，重新登录
`Cannot connect to the Docker daemon`	daemon 没起	`systemctl start docker`
`WARNING: IPv4 forwarding is disabled`	宿主机没开 ip_forward	`echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf`，`sysctl -p`
`unknown or invalid runtime name: docker-runc`	老 docker 升级后 runtime 名变了	`grep -rl 'docker-runc' /var/lib/docker/containers/ \| xargs sed -i 's/docker-runc/runc/g'`，重启 daemon
K8s 1.24+ 报 `failed to create sandbox: cri-dockerd not found`	用了 docker 但没装 cri-dockerd shim	装 cri-dockerd（见 6.3 节），kubelet 加 `--cri-socket=unix:///var/run/cri-dockerd.sock`
`kubelet cgroup driver: "cgroupfs" is different from docker: "systemd"`	kubelet / docker cgroup driver 不一致	双方都改成 `systemd`：daemon.json 加 `"exec-opts": ["native.cgroupdriver=systemd"]`，kubelet 加 `--cgroup-driver=systemd`
`image pull failed: toomanyrequests`	Docker Hub 匿名拉取限流	配 `registry-mirrors` 走国内 mirror，或登录 Docker Hub 账号

十五、小结

把这一篇的要点压缩成 7 条：

版本选型：Debian/Ubuntu 优先 docker.io（系统接管依赖），其他发行版走 docker-ce 官方源，商业场景评估 docker-ee / Mirantis 商业支持
离线部署：静态二进制 + systemd unit + daemon.json，三件套即可；K8s 1.24+ 别忘了 cri-dockerd
buildx：2020 年后推荐用 docker buildx，多架构 + 缓存导出 + BuildKit 特性完胜老 docker build
Compose v2：用空格 docker compose，v1 已弃用
关键配置：daemon.json 的 log-driver / log-opts 一定要限制大小，否则生产会撑爆磁盘；K8s 节点必须开 live-restore
国内镜像：必须配 registry-mirrors，否则 docker pull 慢到怀疑人生
卸载干净：apt/yum remove 删不干净 /var/lib/docker，重装前手动清掉避免配置残留

下一步：装好 Docker 之后，最常被问到的就是"容器之间怎么通信"、“数据怎么持久化”——这正是下一篇《Docker 进阶与运维：网络模式、存储卷与镜像加速》要展开的内容。

参考资料

Watchtower 容器自动更新：定时检测、选择性更新与远程主机

Mon, 15 Mar 2021 00:00:00 +0800

容器跑起来之后，“镜像更新"是个让人纠结的事——不更新吧，安全漏洞累积；更新吧，业务容器一重启服务就断。Watchtower 解决了"无痛更新”：定时拉取镜像、检测到更新就停掉旧容器、用新镜像起一个新容器、把端口/网络/卷全部恢复。这篇文章讲清楚 Watchtower 容器化部署、清理旧镜像、选择性更新、监控频率、远程主机对接。

阅读对象：在多容器环境里希望"装完不用管"、或者要给客户做无人值守部署的运维同学
覆盖范围：Watchtower 容器化部署、cleanup 选项、容器名过滤、标签选择、interval/schedule 频率、远程 Docker Host、Harbor 私有仓库凭据

一、为什么是 Watchtower

容器自动更新工具里，Watchtower 是事实标准：

零侵入：跑一个 sidecar 容器，监控 Docker daemon，不动现有 docker-compose
可选择性：可以只更新部分容器（按名字/标签过滤）
可灰度：--run-once 手动触发、--label-enable 白名单模式
可远程：能监控远程 Docker Host 上的容器
开源活跃：containrrr 组织维护，GitHub 1w+ stars

When to use：业务容器是"无状态"、“镜像无破坏性变更”、“出问题可快速回滚"的场景，Watchtower 几乎是首选。如果是数据库这种"有状态升级"或"必须停机升级"的场景，Watchtower 不合适。

二、容器化部署

2.1 最简启动

1
2
3
4
5
6


docker run -d \
 --name watchtower \
 --restart always \
 -v /var/run/docker.sock:/var/run/docker.sock \
 containrrr/watchtower \
 -c

挂载 /var/run/docker.sock：Watchtower 通过 Docker API 拉镜像、停旧容器、起新容器，没有这个挂载就什么也做不了。 -c (--cleanup)：每次更新后清理旧镜像，否则磁盘会被旧镜像塞满。

2.2 选择性自动更新（按容器名）

1
2
3
4
5
6
7


docker run -d \
 --name watchtower \
 --restart always \
 -v /var/run/docker.sock:/var/run/docker.sock \
 containrrr/watchtower \
 -c \
 nginx redis

nginx redis 是被监控的容器名（不是镜像名）。docker ps 看到的 NAMES 列填进去即可。Watchtower 会只监控这俩容器，其它不管。

2.3 配置文件方式（容器多了之后）

容器列表写在文件里：

1
2
3
4


cat ~/.watchtower.list
aria2-pro
unlockmusic
mtg

1
2
3
4
5
6
7


docker run -d \
 --name watchtower \
 --restart always \
 -v /var/run/docker.sock:/var/run/docker.sock \
 containrrr/watchtower \
 -c \
 $(cat ~/.watchtower.list)

注意空格：$(cat ...) 会把换行替换成空格，正好是 Watchtower 的命令行格式。

三、排除与白名单

3.1 排除特定容器（label 模式）

给容器加 label com.centurylinklabs.watchtower.enable=false：

1
2
3
4
5
6
7
8


docker run -d \
 --name openwrt-mini \
 --restart always \
 --network openwrt \
 --privileged \
 --label com.centurylinklabs.watchtower.enable=false \
 p3terx/openwrt-mini \
 /sbin/init

Watchtower 看到这个 label 就跳过。

3.2 白名单模式（只更新带 label 的）

启动时加 --label-enable（简写 -e）：

1
2
3
4
5
6


docker run -d \
 --name watchtower \
 --restart unless-stopped \
 -v /var/run/docker.sock:/var/run/docker.sock \
 containrrr/watchtower -c \
 --label-enable

关键：要把 --label-enable 加在 Watchtower 自己的启动参数上，被监控容器加 label com.centurylinklabs.watchtower.enable=true，Watchtower 只更新这种容器。

四、更新频率控制

4.1 默认行为

Watchtower 默认每 5 分钟轮询一次。

4.2 interval（秒）

1
2
3
4
5
6


docker run -d \
 --name watchtower \
 --restart unless-stopped \
 -v /var/run/docker.sock:/var/run/docker.sock \
 containrrr/watchtower -c \
 --interval 3600

--interval 3600：每 3600 秒（1 小时）检查一次。

4.3 schedule（6 字段 Cron）

1
2
3
4
5
6


docker run -d \
 --name watchtower \
 --restart unless-stopped \
 -v /var/run/docker.sock:/var/run/docker.sock \
 containrrr/watchtower -c \
 --schedule "0 0 2 * * *"

6 字段 Cron：第一位是秒（0 0 2 * * * 表示"每天 02:00:00”），与 Linux crontab 的 5 字段格式不一样。推荐：0 0 3 * * *（凌晨 3 点）——业务低峰期，重启容器对用户影响最小。

4.4 手动更新（–run-once）

Watchtower 默认常驻后台；--run-once 让它跑一次就退出，适合“白天手动触发更新”：

1
2
3


docker run --rm \
 -v /var/run/docker.sock:/var/run/docker.sock \
 containrrr/watchtower -cR aria2-pro

-R = --run-once：跑一次就退出。容器被 docker run --rm 自动清理。

五、远程 Docker Host

Watchtower 能监控远程主机上的容器（前提：远程 Docker daemon 监听 TCP 端口，且能认证）：

1
2
3
4
5
6
7
8
9


docker run -d \
 --name watchtower \
 --restart always \
 -e REPO_USER=admin \
 -e REPO_PASS={{REDACTED}} \
 -e DOCKER_HOST="tcp://{{REMOTE_DOCKER_HOST}}:2375" \
 containrrr/watchtower \
 -c \
 base

远程 Docker 监听 TCP 2375（明文） 有安全风险，生产环境必须用 TLS（2376）。配置方式：DOCKER_HOST=tcp://host:2376 + -e DOCKER_TLS_VERIFY=1 + -v /path/to/certs:/certs。

DOCKER_HOST 与 -v 冲突：Watchtower 用 -e DOCKER_HOST 时不需要挂载 /var/run/docker.sock，否则两个 Docker daemon 都会跑（本地和远程同时管），按需取舍。

六、私有仓库（Harbor / 自建 registry）

如果镜像在私有仓库，Watchtower 拉镜像需要凭据：

1
2
3
4
5
6
7
8
9


docker run -d \
 --name watchtower \
 --restart always \
 -e REPO_USER=admin \
 -e REPO_PASS={{REDACTED}} \
 -v /var/run/docker.sock:/var/run/docker.sock \
 containrrr/watchtower \
 -c \
 base

base 是镜像名（不是容器名）：Harbor 仓库里项目叫 base，Watchtower 就会拉 {{REGISTRY}}/base/* 下的所有镜像。

七、踩坑清单

磁盘吃光——忘了 -c/--cleanup，旧镜像累积几个 G
数据库被自动升级——Postgres / MySQL 这种"有状态"服务，Watchtower 升级可能直接破坏数据，强烈建议加 label 排除
配置/数据卷没挂出来——Watchtower 升级只会保留"挂载进容器的卷"，容器内 /etc/nginx/conf.d 这种直接放容器内的文件会丢
Watchtower 把自己升级挂了——--restart=always 不一定能救回，因为新版可能改了 entrypoint；建议固定 tag 不追 latest
频繁重启影响业务——--interval 设太短（如 60s），凌晨业务被意外重启。生产用 --schedule 凌晨低峰
远程 Docker Host 防火墙——DOCKER_HOST=tcp://... 远程 daemon 端口（2375/2376）没在远程主机防火墙开放

八、参考资料

Watchtower 官方仓库：https://github.com/containrrr/watchtower
文档：https://containrrr.dev/watchtower/
Docker daemon TLS 配置：https://docs.docker.com/engine/remote-access/

下一步

想做安全镜像仓库？→ 看 Harbor 相关文章（0.4 批次已收录）
想用 K8s 部署？→ 看 K8s 集群流量入口 Ingress-nginx 一文
一站式监控告警？→ HertzBeat 轻量监控告警一文

代理工具技术原理与海外业务场景：V2Ray / v2fly 内核 + Docker 部署 + 系统代理配置

Tue, 15 Sep 2020 00:00:00 +0800

合规提示（必读）：本文仅讨论 V2Ray 等网络代理工具的技术原理与海外业务部署，这些是公开的网络技术。部署、使用代理服务务必遵守所在国家/地区法律法规：

中国大陆境内严格遵循《计算机信息网络国际联网管理暂行规定》《网络安全法》，未经批准擅自建立、使用其他信道进行国际联网属违法行为。

合法用途：跨境企业内部网络互通、海外业务数据回传、学术研究、协议分析、网络安全演练、海外差旅访问公司资源。

本文不评价、不推荐任何"绕过监管"的服务，不提供节点订阅、节点分享、节点购买链接。

V2Ray（Project V）是一个"网络代理工具平台"，支持 VMess / VLESS / Trojan / Shadowsocks 等多种协议，跨平台、性能好、对抗检测能力优于早期 SS/SSR。V2Ray 核心原项目（V2Ray Core）在 2020 年左右原作者退出社区，后续由 v2fly 社区继续维护 fork（v2fly/v2ray-core），版本号沿用 v4.x。这篇文章基于 v2fly 内核 + Docker，讲清楚服务端/客户端的部署、配置、系统代理接入，仅供企业内网 / 海外业务 / 学术研究场景参考。

阅读对象：需要为企业跨境网络、海外业务、学术研究自建代理服务的同学
覆盖范围：v2fly/v2ray-core v4.45.2 容器化部署、config.json 客户端配置、系统代理环境变量

一、背景与版本选择

项目	状态	维护方
`v2ray/v2ray-core`	已停止	原 V2Ray 团队（2020 退出）
`v2fly/v2ray-core`	活跃	v2fly 社区 fork
`xtls/Xray-core`	活跃	XTLS 项目（VLESS + XTLS 性能更强）
`shadowsocks/shadowsocks-libev`	活跃	经典 SS，仍在维护
`trojan-gfw/trojan`	活跃	伪装成 HTTPS

本文选型：用 v2fly/v2ray-core，跨平台、社区稳定、文档齐全。如果追求极致性能/抗检测，可考虑 Xray-core（VLESS + XTLS 组合），但配置复杂度更高。

再次提醒：本节技术细节用于海外业务、跨境企业内网、学术研究、协议原理学习等合法场景。请勿用于违反所在国法律法规的用途。

二、平台要求

V2Ray 跨 Linux 主流发行版：

Linux 内核 ≥ 2.6.23（Debian 7+、Ubuntu 12.04+、CentOS 7+、Arch 都 OK）
查看内核：uname -r，比如 3.10.0-1127.13.1.el7.x86_64

架构支持：x86 / amd64 / arm / arm64 / mips64 / mips / riscv64。

三、容器化部署

3.1 拉镜像

1

docker pull v2fly/v2fly-core:v4.45.2

离线包（无 Docker 环境的兜底）：从 https://github.com/v2fly/v2ray-core/releases 下载 v2ray-linux-64.zip，解压即可运行。

3.2 配置文件

V2Ray 配置文件默认在 /etc/v2ray/config.json，主要字段：

服务器监听端口
协议（VMess / VLESS / Shadowsocks / Trojan / SOCKS）
客户端 UUID（VMess）/ 密码（SS/Trojan）
传输层（TCP / WebSocket / HTTP/2 / gRPC / QUIC）
TLS（证书 + 域名）

完整 config.json 示例（VMess + WebSocket + TLS）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36


{
 "log": {
 "loglevel": "warning"
 },
 "inbounds": [{
 "port": 443,
 "protocol": "vmess",
 "settings": {
 "clients": [
 {
 "id": "{{UUID}}",
 "alterId": 0
 }
 ]
 },
 "streamSettings": {
 "network": "ws",
 "wsSettings": {
 "path": "/{{WS_PATH}}"
 },
 "security": "tls",
 "tlsSettings": {
 "certificates": [
 {
 "certificateFile": "/etc/v2ray/tls/fullchain.pem",
 "keyFile": "/etc/v2ray/tls/privkey.pem"
 }
 ]
 }
 }
 }],
 "outbounds": [{
 "protocol": "freedom",
 "tag": "direct"
 }]
}

UUID 生成：cat /proc/sys/kernel/random/uuid 或用 v2ctl 工具生成。 alterId 0：VMess AEAD 模式，老版本 alterId > 0 已被废弃。 WebSocket path：必须以 / 开头，Nginx 反代时匹配同一路径。

3.3 启动

1
2
3
4
5
6


# 把 config.json 挂进去
docker run -d \
 --name v2ray \
 --network host \
 -v /home/v2ray/config.json:/etc/v2ray/config.json \
 v2fly/v2fly-core:v4.45.2

或者用 --restart=always + 日志驱动：

1
2
3
4
5
6


docker run -d \
 --name v2ray \
 --network host \
 --restart=always \
 -v /home/v2ray/config.json:/etc/v2ray/config.json \
 v2fly/v2fly-core:v4.45.2

3.4 文件结构

容器内关键路径：

/etc/v2ray/config.json：主配置文件
/usr/bin/v2ray：V2Ray 主程序
/usr/bin/v2ctl：V2Ray 辅助工具（生成 UUID、查看配置等）
/usr/local/share/v2ray/geoip.dat：IP 数据文件（按国家分流用）
/usr/local/share/v2ray/geosite.dat：域名数据文件（按域名分流用）

四、客户端接入

4.1 桌面客户端

Windows / macOS / Linux：Qv2ray（Qt 写的跨平台 GUI，已停更但仍可用）、V2RayN（Windows 经典）、V2RayU（macOS）、V2RayA（带 WebUI）
iOS：Shadowrocket（小火箭，付费）、Quantumult X、Stash
Android：v2rayNG（开源）、SagerNet

4.2 客户端配置

客户端和服务端是"协议对协议"——服务端 VMess+WS+TLS，客户端必须配相同参数。客户端 config.json：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33


{
 "log": { "loglevel": "warning" },
 "inbounds": [{
 "port": 1080,
 "listen": "127.0.0.1",
 "protocol": "socks",
 "settings": { "udp": true }
 }, {
 "port": 1081,
 "listen": "127.0.0.1",
 "protocol": "http"
 }],
 "outbounds": [{
 "protocol": "vmess",
 "settings": {
 "vnext": [{
 "address": "{{SERVER_IP}}",
 "port": 443,
 "users": [{
 "id": "{{UUID}}",
 "alterId": 0,
 "security": "auto"
 }]
 }]
 },
 "streamSettings": {
 "network": "ws",
 "wsSettings": { "path": "/{{WS_PATH}}" },
 "security": "tls",
 "tlsSettings": { "serverName": "{{DOMAIN}}" }
 }
 }]
}

五、系统代理配置

V2Ray 客户端启动后，监听本地 1080（SOCKS5）/ 1081（HTTP）端口。Linux 上让命令行流量走代理：

1
2
3
4
5
6
7


vim /etc/profile

export ALL_PROXY=socks5://127.0.0.1:1080
export http_proxy="socks5://127.0.0.1:1080"
export https_proxy="socks5://127.0.0.1:1080"

source /etc/profile

验证：

1

curl -x socks5://127.0.0.1:1080 https://www.google.com

图形界面代理：Linux 桌面一般在系统设置 → 网络 → 代理，填 SOCKS5 127.0.0.1:1080。 Windows：Qv2ray / V2RayN 启动后会自动设置系统代理（或按 Win+R 输入 inetcpl.cpl 手动配）。 macOS：Qv2ray / V2RayU 默认开启"系统代理"开关。

六、Nginx 反代 V2Ray（域名 + 443 共用）

很多场景下不想专门为 V2Ray 开 443 端口，而是和现有 Web 服务共用 443（WebSocket path 区分）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


server {
 listen 443 ssl;
 server_name v2.example.com;

 ssl_certificate /www/.../fullchain.pem;
 ssl_certificate_key /www/.../privkey.pem;

 # 正常 Web 流量
 location / {
 root /var/www/html;
 }

 # V2Ray 流量
 location /{{WS_PATH}} {
 proxy_redirect off;
 proxy_pass http://127.0.0.1:10000;
 proxy_http_version 1.1;
 proxy_set_header Upgrade $http_upgrade;
 proxy_set_header Connection "upgrade";
 proxy_set_header Host $host;
 proxy_set_header X-Real-IP $remote_addr;
 }
}

此时 V2Ray 容器监听 127.0.0.1:10000（--network=host 模式下用 127.0.0.1 暴露给 Nginx）。

七、踩坑清单

UUID 写错——UUID 格式 xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx，客户端服务端必须完全一致
alterId 不一致——服务端 0，客户端也必须 0（VMess AEAD 强制）
TLS 证书路径错——容器内路径用 /etc/v2ray/...，挂载到宿主机的实际路径
防火墙没开 443——国内云厂商对 443 有备案要求，备案后才能用
Docker 网络模式——--network=host 和端口映射二选一，混用导致监听不到
客户端系统代理没开——V2Ray 起来了但流量没走，桌面端检查"系统代理"开关
DNS 污染——开启 V2Ray 后仍访问不了某些网站，是 DNS 污染。客户端要配 dns: { "servers": ["8.8.8.8"] }，或在 V2Ray 启用 dns 段

八、参考资料

v2fly 官方仓库：https://github.com/v2fly/v2ray-core
v2fly 文档：https://www.v2fly.org/
V2Ray 配置生成器：https://www.v2fly.org/config/tools.html
Xray 项目（VMess/VLESS 性能更优）：https://github.com/XTLS/Xray-core
V2Ray 客户端列表：https://www.v2fly.org/awesome/tools.html

下一步

自建企业 VPN？→ OpenVPN 自建 VPN 服务一文
反向代理网关？→ Nginx 反向代理实战一文
实时视频流？→ 流媒体与 WebRTC 实时视频一文

WordPress 博客快速部署：官方镜像 + 数据持久化 + 反向代理

Fri, 15 Mar 2019 00:00:00 +0800

WordPress 是全球最流行的内容管理系统，官方市场份额常年第一（全球网站 40%+ 跑 WordPress）。虽然静态博客（Hugo/Jekyll）现在很火，但 WordPress 的"开箱即用 + 插件生态 + 后台可视化编辑"对新人和企业站仍是首选。这篇文章讲清楚 WordPress 官方镜像容器化部署、数据持久化、Nginx 反代、备份策略。

阅读对象：想用 WordPress 快速搭博客/企业站、又不想 LAMP 手工搭环境的同学
覆盖范围：WordPress 容器化部署、数据卷持久化、Nginx 反代、HTTPS、备份

一、为什么是 WordPress（容器化）

传统 LAMP 部署 WordPress：

装 Apache/Nginx + PHP + MySQL
配置 PHP-FPM / 虚拟主机
改 wp-config.php 数据库连接
装主题、插件、调权限

每台新机器都要重新走一遍。容器化的好处：

一致性：开发、测试、生产用同一镜像
可移植：服务器迁移只需打包数据卷
升级简单：docker pull wordpress:latest 一行就升级
隔离：和宿主机其他服务不冲突

When to use：需要"内容运营"团队（不熟技术）自己发文章、装插件，WordPress 是首选。如果只是写技术博客，Hugo / Jekyll 等静态博客更省心。

二、容器化部署

2.1 最简启动（SQLite 数据）

1
2
3


docker run -d --restart=always --name wordpress -p 8864:80 \
 -v /home/project/wordpress/data:/var/www/html \
 wordpress

数据卷 /var/www/html：WordPress 全部文件（核心代码 + 上传的媒体 + 主题插件）。挂出来才能持久化。

访问 http://{{HOST}}:8864 进入 WordPress 安装向导。

2.2 配合 MySQL 部署（推荐生产）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32


version: "3"
services:
 mysql:
 image: mysql:8.0
 restart: always
 environment:
 MYSQL_ROOT_PASSWORD: {{REDACTED}}
 MYSQL_DATABASE: wordpress
 MYSQL_USER: wordpress
 MYSQL_PASSWORD: {{REDACTED}}
 volumes:
 - mysql_data:/var/lib/mysql
 command: --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci

 wordpress:
 image: wordpress:latest
 restart: always
 depends_on:
 - mysql
 ports:
 - 8864:80
 environment:
 WORDPRESS_DB_HOST: mysql:3306
 WORDPRESS_DB_USER: wordpress
 WORDPRESS_DB_PASSWORD: {{REDACTED}}
 WORDPRESS_DB_NAME: wordpress
 volumes:
 - wp_data:/var/www/html

volumes:
 mysql_data:
 wp_data:

utf8mb4：MySQL 5.7+ / 8.0 必须用 utf8mb4 字符集，emoji 和中文才不乱码。 depends_on：等 MySQL 起来再启 WordPress（但只保证容器启动顺序，不等 MySQL 完全就绪——WordPress 启动时会重试连接）。

2.3 初始账号

WordPress 安装向导里设置：

站点标题
管理员用户名 / 密码（不要用 admin）
管理员邮箱

生产环境必改：

用户名不要用 admin（机器人会暴力破解）

密码 16+ 位，大小写+数字+符号

邮箱用企业域名（找回密码用）

三、Nginx 反代 + HTTPS

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37


server {
 listen 80;
 server_name blog.example.com;

 # HTTP 跳 HTTPS
 return 301 https://$host$request_uri;
}

server {
 listen 443 ssl;
 server_name blog.example.com;

 ssl_certificate /www/cert/blog.example.com/fullchain.pem;
 ssl_certificate_key /www/cert/blog.example.com/privkey.pem;
 ssl_protocols TLSv1.2 TLSv1.3;

 # WordPress 上传文件可能很大
 client_max_body_size 100m;

 location / {
 proxy_pass http://127.0.0.1:8864;
 proxy_set_header Host $http_host;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header X-Forwarded-Proto $scheme;

 # WordPress 永久链接（pretty permalinks）需要
 try_files $uri $uri/ /index.php?$args;
 }

 # 静态资源直接走 Nginx（性能优化）
 location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff|woff2|ttf|eot)$ {
 proxy_pass http://127.0.0.1:8864;
 proxy_cache_valid 200 30d;
 expires 30d;
 }
}

try_files 关键：WordPress 用"文章名"做 URL（如 /2019/03/hello-world/），Nginx 必须 fallback 到 index.php，否则 404。 client_max_body_size：WordPress 上传主题/插件可能 50MB+，默认 1M 会 413。

四、WordPress 后台必备设置

4.1 永久链接

Settings → Permalinks → Post name（/%postname%/）。别用默认的 ?p=123，SEO 友好需要路径式 URL。

4.2 媒体上传大小

Nginx：client_max_body_size 100m（如上）

PHP：容器内 php.ini 或 wp-config.php 加：

1
2


@ini_set('upload_max_size', '100M');
@ini_set('post_max_size', '100M');

4.3 安全加固

改默认管理员用户名（不要 admin）
强密码 + 二次验证（Google Authenticator 插件）
限制登录失败次数（Limit Login Attempts Reloaded 插件）
关闭文件编辑（wp-config.php 加 define('DISALLOW_FILE_EDIT', true);）
隐藏 WordPress 版本号（很多 security 插件有这个功能）

4.4 推荐插件

类别	插件	用途
SEO	Yoast SEO / Rank Math	元信息、sitemap、社交分享
缓存	WP Super Cache / W3 Total Cache	静态化提速
安全	Wordfence / Sucuri	WAF、登录保护、扫描
备份	UpdraftPlus / BackWPup	自动备份到 OSS/S3
主题	Astra / GeneratePress	轻量、快、自定义强
编辑器	Classic Editor / Gutenberg	编辑器选择

五、备份策略

5.1 备份什么

数据库（mysqldump）：所有文章、用户、配置
数据卷（wp_data）：主题、插件、上传的媒体
wp-config.php：数据库连接等关键配置

5.2 备份脚本

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


#!/bin/bash
# backup-wordpress.sh
BACKUP_DIR=/backup/wordpress/$(date +%Y%m%d)
mkdir -p $BACKUP_DIR

# 数据库
docker exec mysql_container mysqldump -u wordpress -p{{REDACTED}} wordpress \
 | gzip > $BACKUP_DIR/db.sql.gz

# 数据卷
docker run --rm \
 -v wp_data:/data:ro \
 -v $BACKUP_DIR:/backup \
 alpine tar czf /backup/wp_data.tar.gz /data

echo "Backup done: $BACKUP_DIR"

生产环境：备份同步到 OSS / S3 / 异地机房，本地磁盘挂了不能恢复等于没备份。

六、踩坑清单

上传 413——client_max_body_size 没调，或 PHP upload_max_filesize 太小
固定链接 404——Nginx try_files 没配，或者 .htaccess 没生效
中文乱码——MySQL 没用 utf8mb4 字符集，老库是 latin1
主题/插件升级失败——wp_data 没挂出来，容器升级后回到默认状态
wp-admin 卡顿——没接 CDN/缓存，每次请求都打 WordPress
被刷登录——没装限流插件，admin 用户名太简单被暴力破解

七、2024+ 视角补充

本文写于 2019-03，2024-2026 这几年 WordPress 生态有显著变化：

WordPress 6.x 核心更新：

6.0-6.6（2022-2024）逐步把经典编辑器过渡到全站编辑（Full Site Editing, FSE）+ 块主题（Block Theme），传统 PHP 主题（如 Twenty 系列）模式正在被"块"取代
6.5+ 引入站点字体加载 API（Site Fonts API），前端字体管理不再靠主题 hack
6.6（2024-07）性能大幅提升：首屏 LCP 优化、字体切换不闪屏、插件加载顺序调优

PHP 版本要求：WordPress 6.5+ 最低要求 PHP 7.4，强烈推荐 8.2+（性能提升 30%+）。wordpress:6-php8.3-apache 是 2024+ 生产推荐 tag。

容器化最佳实践更新：

官方镜像 wordpress 2024 年起改用 PHP 8.x + Apache 默认 tag，wordpress:latest 实际跑的是 6.6.x + PHP 8.3。旧的 wordpress:5-apache 还可拉但不收安全补丁
多阶段构建：2024 年生产推荐用 FROM wordpress:6-php8.3-apache + 自定义 wp-content 主题/插件做多阶段，把不可变基础设施原则贯彻
持久化命名约定：从 2019 年的 wp_data 卷，到 2024 年推荐 wp-content、wp-uploads 拆成独立卷——主题/插件更新不影响上传文件

Headless WordPress / WPGraphQL： 2023+ 越来越多团队把 WordPress 当 CMS-only 用（只走 WPGraphQL / REST API 输出 JSON），前端用 Next.js / Nuxt 渲染。好处：复用 WordPress 的后台编辑体验，前端享受现代 SPA/SSG 性能。WPGraphQL 插件 1.16+ 稳定。

反代 / HTTPS 实践变化：

2023 年起 certbot 推荐用 snap 或 docker 化部署（不再 apt install）
Caddy 替代 Nginx 越来越流行：自动 HTTPS（Let’s Encrypt 自动续期）、Caddyfile 配置比 nginx.conf 简洁 50%
WordPress 6.5+ 自带 application passwords 替代传统 API token，更安全

现代化插件栈（2024 推荐）：

类别	旧推荐	2024+ 推荐
缓存	WP Super Cache	WP Rocket（付费）或 LiteSpeed Cache（免费且强）
安全	Wordfence	Solid Security（原 iThemes）
SEO	Yoast SEO	Rank Math（免费 + 高级功能）
静态化	W3 Total Cache	Simply Static（生成纯静态站点）
表单	Contact Form 7	WPForms / Fluent Forms

经验法则更新：内容运营团队 + 简单站点 → WordPress 6.6 + PHP 8.3 + MariaDB 11 + LiteSpeed Cache；纯写技术博客 → Hugo / Astro 仍是更省心选择；API 化集成业务 → Headless WordPress + Next.js。

八、参考资料

WordPress 官方文档：https://wordpress.org/support/
WordPress 6.6 发布说明：https://wordpress.org/news/2024/07/
Docker Hub WordPress：https://hub.docker.com/_/wordpress
WordPress 永久链接：https://wordpress.org/support/article/using-permalinks/
WPGraphQL：https://www.wpgraphql.com/
安全白皮书：https://wordpress.org/about/security/

下一步

想做静态博客？→ 看 Hugo / Hexo 等（本站用的就是 Hugo）
想做密码管理？→ Vaultwarden 自托管密码一文
想做反代网关？→ Nginx 反向代理实战一文

OpenVPN 自建 VPN 服务：证书签发、客户端配置与多用户管理

Sat, 15 Sep 2018 00:00:00 +0800

企业内网里要远程办公、要让外网访问内部系统，传统方案是"公网 IP + 端口映射 + 防火墙白名单"，但任意端口都暴露风险大。VPN（Virtual Private Network）是更安全的方案——所有流量走加密隧道，访问内网像在内网一样。OpenVPN 是开源 VPN 里的"老牌选手"，协议成熟、客户端齐全、跨平台。这篇文章讲清楚容器化部署、CA 证书签发、客户端 .ovpn 配置、多用户管理。

阅读对象：要给团队搭企业 VPN、给客户搭远程访问通道的运维同学
覆盖范围：kylemanna/openvpn 容器化部署、CA 签发、客户端 .ovpn 生成、duplicate-cn 多人共用、多用户管理脚本

〇、本文与"VPN 与代理自托管"一文的关系

本篇侧重 OpenVPN 单协议的深度——性能调优、跨平台客户端、协议变体、与企业网络设备对接。如果想看 OpenVPN + V2Ray 两条路线的选型对比，请参考姐妹篇 VPN 与代理自托管：OpenVPN 与 V2Ray 部署实战。

合规提示（必读）：本文仅讨论 OpenVPN 用于企业远程办公、跨地域内网访问、出差员工接入公司内网等合法场景。部署、使用 VPN 服务务必遵守所在国家/地区法律法规。未经电信主管部门批准擅自建立、使用其他信道进行国际联网在中国大陆境内属违法行为。请勿用于违反所在国法律法规的用途。

一、为什么是 OpenVPN

VPN 协议不止一种，主流对比：

协议	特点	适用
OpenVPN	SSL/TLS 加密，UDP/TCP 都行，跨平台	企业内网 VPN，老牌稳定
WireGuard	新一代，Linux 内核态，配置极简	追求性能与简洁
IPSec / IKEv2	移动端友好，原生支持 iOS/macOS	移动办公
Shadowsocks / V2Ray	代理协议，不是真 VPN	翻墙 / 流量伪装

When to use：要给企业员工/客户提供"访问内网"能力，OpenVPN 是最稳的方案——企业级防火墙一般不会拦 OpenVPN 流量（看是 TCP 443 还是 UDP 1194），客户端覆盖 Windows / macOS / Linux / iOS / Android。

二、容器化部署

2.1 拉镜像

1

docker pull kylemanna/openvpn

2.2 初始化配置

1
2
3
4
5
6
7
8


# 创建配置卷
OVPN_DATA="ovpn-data"
docker volume create --name $OVPN_DATA

# 生成 OpenVPN 服务端配置（UDP 协议，公网 IP 替换成实际 IP）
docker run -v $OVPN_DATA:/etc/openvpn --log-driver=none --rm \
 kylemanna/openvpn \
 ovpn_genconfig -u udp://{{PUBLIC_IP}}

协议选择：

UDP 1194：性能好，主流选择

TCP 443：能穿透企业代理/防火墙，但性能略差

2.3 签发 CA 证书

1
2
3
4
5
6
7
8
9


docker run -v $OVPN_DATA:/etc/openvpn --rm -it \
 kylemanna/openvpn ovpn_initpki

# 交互式输入：
# Confirm removal: yes
# Enter PEM pass phrase: {{CA_PASSWORD}} # CA 私钥密码
# Verifying - Enter PEM pass phrase: {{CA_PASSWORD}}
# Common Name (eg: your user,host,or server name) [Easy-RSA CA]: 直接回车
# Enter pass phrase for /etc/openvpn/pki/private/ca.key: {{CA_PASSWORD}}

CA 密码保管：这个密码是 CA 私钥的"二次锁"，必须记录下来备份——后面签发/吊销客户端证书时都要用到。

2.4 启动服务端

1
2
3
4
5
6


docker run -d --name openvpn --restart=always \
 -v $OVPN_DATA:/etc/openvpn \
 -p 1194:1194/udp \
 --cap-add=NET_ADMIN \
 --restart=always \
 kylemanna/openvpn

–cap-add=NET_ADMIN：让容器获得 NET_ADMIN 能力，能创建 tun 设备、改路由表。

2.5 验证

服务端启动后，查看日志：

1

docker logs -f openvpn

看到 Initialization Sequence Completed 说明成功。

三、签发客户端证书

3.1 单个客户端

1
2
3
4
5
6
7


# 签发 client 证书
docker run -v $OVPN_DATA:/etc/openvpn --rm -it \
 kylemanna/openvpn easyrsa build-client-full {{USERNAME}} nopass

# 导出 .ovpn 配置文件
docker run -v $OVPN_DATA:/etc/openvpn --rm \
 kylemanna/openvpn ovpn_getclient {{USERNAME}} > {{USERNAME}}.ovpn

nopass：客户端证书不设密码。nopass 适合自动化/移动端，有密码更安全（每次连接输密码），按业务取舍。

3.2 .ovpn 文件内容

导出的 .ovpn 文件包含：

CA 证书
客户端证书
客户端私钥
服务端配置（IP、端口、协议、压缩方式）

直接发给用户用 OpenVPN 客户端导入即可：

Windows / macOS：OpenVPN Connect 客户端
Linux：openvpn --config xxx.ovpn
iOS / Android：OpenVPN Connect APP

不要通过微信/邮件明文传 .ovpn——里面是私钥。建议企业内 IM（如企业微信）传或加密压缩。

3.3 客户端连接

1
2
3


# Linux
sudo apt install openvpn
sudo openvpn --config /path/to/{{USERNAME}}.ovpn

连接成功后，客户端会拿到 10.8.x.x 的 VPN IP，访问内网（如 192.168.0.0/16）就自动走 VPN 隧道。

四、关键配置

/var/lib/docker/volumes/ovpn-data/_data/openvpn.conf（核心）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


server 10.8.0.0 255.255.255.0
verb 3
key /etc/openvpn/pki/private/{{SERVER_NAME}}.key
ca /etc/openvpn/pki/ca.crt
cert /etc/openvpn/pki/issued/{{SERVER_NAME}}.crt
dh /etc/openvpn/pki/dh.pem
tls-auth /etc/openvpn/pki/ta.key
key-direction 0
keepalive 10 60
persist-key
persist-tun
proto udp
port 1194
dev tun0
status /tmp/openvpn-status.log
user nobody
group nogroup
comp-lzo no

# 路由推送（让客户端能访问内网）
route 192.168.0.0 255.255.0.0

# DNS 推送
push "block-outside-dns"
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
push "comp-lzo no"

五、多用户管理

5.1 duplicate-cn（多人共用证书）

默认 OpenVPN 一个证书只允许一个连接。多人用同一个 .ovpn：

1
2
3
4
5


# 在 openvpn.conf 末尾加
echo "duplicate-cn" >> /var/lib/docker/volumes/ovpn-data/_data/openvpn.conf

# 重启
docker restart openvpn

不推荐生产用：所有用户用同一个证书，审计不到具体人，吊销就是"全部吊销"。建议每个用户独立签发证书。

5.2 批量添加用户脚本

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


#!/bin/bash
# vim add_user.sh
OVPN_DATA="ovpn-data"
read -p "please your username: " NAME

docker run -v $OVPN_DATA:/etc/openvpn --rm -it \
 kylemanna/openvpn easyrsa build-client-full $NAME nopass

docker run -v $OVPN_DATA:/etc/openvpn --rm \
 kylemanna/openvpn ovpn_getclient $NAME > /root/"$NAME".ovpn

docker restart openvpn

5.3 删除用户脚本

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


#!/bin/bash
# vim del_user.sh
OVPN_DATA="ovpn-data"
read -p "Delete username: " DNAME

docker run -v $OVPN_DATA:/etc/openvpn --rm -it \
 kylemanna/openvpn easyrsa revoke $DNAME

docker run -v $OVPN_DATA:/etc/openvpn --rm -it \
 kylemanna/openvpn easyrsa gen-crl

docker run -v $OVPN_DATA:/etc/openvpn --rm \
 kylemanna/openvpn rm -f /etc/openvpn/pki/reqs/"$DNAME".req

docker run -v $OVPN_DATA:/etc/openvpn --rm \
 kylemanna/openvpn rm -f /etc/openvpn/pki/private/"$DNAME".key

docker run -v $OVPN_DATA:/etc/openvpn --rm \
 kylemanna/openvpn rm -f /etc/openvpn/pki/issued/"$DNAME".crt

docker restart openvpn

六、踩坑清单

UDP 1194 被防火墙拦——换 TCP 443，重启 ovpn_genconfig -u tcp://{{IP}}
客户端连上但访问不了内网——服务端没 push "route 192.168.x.x 255.255.x.x"，或者内网机器防火墙拦截了 VPN 客户端 IP（10.8.0.0/24）
DNS 解析失败——客户端拿到了 VPN IP 但解析不到内网域名，添加 push "dhcp-option DNS 10.0.0.2"
证书过期——Easy-RSA 默认 825 天，吊销旧证书、签发新证书
.ovpn 文件被截断——> 重定向可能被 shell 解释，证书里的 --- 等特殊字符要用 <<EOF 或 tee 输出
多人共用证书审计不到——生产用 duplicate-cn 是"省事但危险"，强烈建议一证一人

七、OpenVPN 性能优化（独有）

性能调优是与 VPN 与代理自托管姐妹篇不重叠的部分。

7.1 协议层

协议	性能	兼容	适用
UDP	最高	大多数客户端	默认推荐
TCP	略低	所有环境	穿透强约束网络
TCP 443	低	全部	跨公网 NAT / 严格防火墙

proto udp 默认选；只有 UDP 被防火墙挡才换 TCP。

7.2 加密层

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 高性能（默认）
cipher AES-256-CBC
auth SHA256
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384

# 极致性能（牺牲一些安全性）
cipher AES-128-GCM # 128 vs 256 性能差 30%
auth SHA1

# 强制 TLS 1.2+（强烈推荐）
tls-version-min 1.2

2024+ 推荐：CPU 支持 AES-NI 硬件加速（所有现代 Intel/AMD CPU 都支持），AESGCM 比 CBC 快 2-3 倍。改用 cipher AES-256-GCM。

7.3 压缩（注意历史教训）

1
2
3
4
5


# 禁用 comp-lzo（VORACLE 攻击）
comp-lzo no
push "comp-lzo no"

# 不用 compress（如果用了 LZ4 也建议禁）

7.4 keepalive 与 MTU

1
2
3
4
5
6


# 客户端断线 60s 内重连，服务端 120s 释放
keepalive 10 60

# 关键 MTU 调优（避免分片）
tun-mtu 1400
mssfix 1360

7.5 大规模并发（千人级）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 服务端配置
max-clients 1000
max-routes-per-client 50
duplicate-cn # 仅审计可放弃时使用
tcp-nodelay

# /etc/sysctl.conf（宿主）
net.core.somaxconn = 4096
net.ipv4.tcp_max_syn_backlog = 4096
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216

7.6 性能基准（参考）

配置	单客户端带宽	CPU 占用（单核）
AES-256-CBC + UDP	~800 Mbps	60%
AES-256-GCM + UDP	~2 Gbps	30%
AES-128-GCM + UDP	~3 Gbps	20%
TCP 443	~500 Mbps	70%

实际值取决于 CPU、MTU、网络环境。1 Gbps 客户端+ AES-NI 可跑到 1.5+ Gbps 隧道吞吐。

八、跨平台客户端实战（独有）

8.1 Windows

OpenVPN Connect 官方客户端
OpenVPN GUI（2018 起停更，但仍是事实标准）
Tunnelblick（仅 macOS）→ Windows 对应 OpenVPN Connect

8.2 macOS

Tunnelblick 开源 GUI（事实标准）
OpenVPN Connect 官方
Viscosity 商业（订阅制，UI 友好）

8.3 Linux

1
2
3
4
5
6
7


# 命令行
sudo apt install openvpn
sudo openvpn --config client.ovpn

# NetworkManager 图形
sudo apt install network-manager-openvpn network-manager-openvpn-gnome
# 系统设置 → 网络 → + → VPN → OpenVPN → 选 .ovpn 文件

8.4 iOS / Android

OpenVPN Connect（官方）
导入 .ovpn 后会自动保存，连接时输入证书密码（如果签发时设了）

8.5 路由器（OpenWrt / iKuaiOS）

1
2
3
4
5
6
7
8
9


# OpenWrt 安装
opkg install openvpn-openssl

# 复制 .ovpn 到 /etc/openvpn/
# 启动
/etc/init.d/openvpn enable
/etc/init.d/openvpn start

# 路由器下所有设备都走 VPN（"硬路由级" VPN）

进阶：把 OpenVPN 装到企业网关（pfSense / OPNsense），整个网段接入 VPN。

九、协议变体与互操作（独有）

9.1 OpenVPN Access Server（商业版）

官方商业版，免证书签发
提供 Web 管理后台、用户自助注册
适合中小企业（< 200 用户）不想自己维护 CA
授权 10 用户起售

9.2 OpenVPN Cloud

2020+ 推出的 SaaS 版
全球 Anycast 节点
适合跨国企业、远程办公团队
按用户订阅

9.3 WireGuard 替代？

维度	OpenVPN	WireGuard
内核态	否（用户态）	是（Linux 5.6+）
性能	中	极高（UDP 单线程 ~1 Gbps）
配置	中（CA + 证书）	极简（公私钥对）
抗检测	中	低（流量特征明显）
跨平台	全平台	全平台（2019+）
适用	企业内网、远程办公	高性能场景、移动端

2024 选型：传统企业 → OpenVPN（稳定、审计、客户端全）；新项目 / 高性能 → WireGuard（配置极简、性能强）。

十、参考资料

kylemanna/openvpn：https://github.com/kylemanna/docker-openvpn
OpenVPN 官方文档：https://openvpn.net/community-resources/
OpenVPN Connect 客户端下载：https://openvpn.net/client/

下一步

想做代理？→ V2Ray 代理服务搭建一文
想做 WebRTC 内网穿透？→ 流媒体与 WebRTC 实时视频一文
想做 Web 网关？→ Nginx 反向代理实战一文

Docker 容器固定 IP 实战：自定义网络与运行时指定

Fri, 15 Jun 2018 00:00:00 +0800

默认 bridge 模式下，容器每次启动 IP 都会变——docker-compose restart 后连接配置失效、监控告警的 IP 列表刷新不了。生产环境要"容器 IP 稳定"，必须用自定义网络 + --ip 指定。

这一篇把"容器固定 IP"这件事的最短路径写清楚。

阅读对象：需要容器 IP 在重启后保持不变、要把 IP 写进监控 / DNS / Nginx upstream 的同学 覆盖范围：默认 bridge 模式的局限 + 自定义网络 + –ip 指定 + 多容器共享子网

一、为什么默认 bridge 模式 IP 会变

Docker 启动时按顺序从子网 172.17.0.0/16 分配 IP 给容器。容器重启 / 删除后，IP 池会重新分配——172.17.0.2 这次给 nginx，下次可能给 mysql。

1
2
3
4
5
6
7
8


$ docker run -d --name nginx1 nginx
$ docker inspect nginx1 | grep IPAddress
"IPAddress": "172.17.0.2"

$ docker stop nginx1 && docker rm nginx1
$ docker run -d --name nginx2 nginx
$ docker inspect nginx2 | grep IPAddress
"IPAddress": "172.17.0.2" # 同一个 IP 给新容器了

直接用默认 bridge 模式指定 IP 会报错：

1
2
3


$ docker run -itd --name test --network bridge --ip 172.17.0.5 centos:7 /bin/bash
Error response from daemon: User specified IP address is supported only when
connecting to networks with user configured subnets.

结论：要让容器 IP 稳定，必须先 docker network create 自定义网络。

二、自定义网络：三步搞定

2.1 创建自定义网络

1

docker network create --subnet=172.18.0.0/16 mynetwork

参数说明：

--subnet=172.18.0.0/16：定义子网范围
mynetwork：网络名

Why 自定义子网：

避开默认 172.17.0.0/16 防止和宿主机其他网络冲突

显式规划 IP 段，方便和监控 / DNS 同步

可选参数：

1
2
3
4
5


# 指定网桥名（让 ifconfig 看到的是 docker1，不是 br-xxx）
docker network create \
 --subnet=172.18.0.0/16 \
 --opt "com.docker.network.bridge.name"="docker1" \
 mynetwork

2.2 验证网络

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33


$ docker network ls
NETWORK ID NAME DRIVER SCOPE
xxxx bridge bridge local
xxxx host host local
xxxx none null local
xxxx mynetwork bridge local

$ docker network inspect mynetwork
[
 {
 "Name": "mynetwork",
 "Id": "abc123...",
 "Created": "...",
 "Scope": "local",
 "Driver": "bridge",
 "EnableIPv6": false,
 "IPAM": {
 "Driver": "default",
 "Options": null,
 "Config": [
 {
 "Subnet": "172.18.0.0/16",
 "Gateway": "172.18.0.1"
 }
 ]
 },
 "Internal": false,
 "Containers": {},
 "Options": {
 "com.docker.network.bridge.name": "docker1"
 }
 }
]

2.3 启动容器 + 指定 IP

1
2
3
4
5


docker run -itd \
 --name test \
 --net mynetwork \
 --ip 172.18.0.10 \
 centos:7 /bin/bash

关键参数：

--net mynetwork：加入自定义网络
--ip 172.18.0.10：固定 IP

2.4 验证

1
2


$ docker inspect test | grep IPAddress
"IPAddress": "172.18.0.10"

重启后 IP 不变：

1
2
3


$ docker restart test
$ docker inspect test | grep IPAddress
"IPAddress": "172.18.0.10" # 还是这个 IP

三、实战场景

3.1 场景 1：MySQL 容器固定 IP，方便其他容器配置

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


# 创建网络
docker network create --subnet=172.18.0.0/16 backend

# 启动 MySQL，固定 IP
docker run -d \
 --name mysql-server \
 --net backend \
 --ip 172.18.0.5 \
 -e MYSQL_ROOT_PASSWORD=secret \
 mysql:8.0

# 启动应用，配置连 172.18.0.5
docker run -d \
 --name myapp \
 --net backend \
 -e DB_HOST=172.18.0.5 \
 -e DB_PORT=3306 \
 myapp:latest

优势：

应用容器可以不挂 mysql:3306 的端口映射——直接用内网 IP 通信

MySQL 不暴露给宿主机外网，减少攻击面

3.2 场景 2：Nginx 反向代理到后端固定 IP

1
2
3
4
5
6
7
8
9


# 后端 web 固定 IP
docker run -d --name web1 --net mynetwork --ip 172.18.0.10 nginx
docker run -d --name web2 --net mynetwork --ip 172.18.0.11 nginx

# Nginx 反代配置
# upstream backend {
# server 172.18.0.10:80;
# server 172.18.0.11:80;
# }

Why 固定 IP：upstream 写死的 IP 重启后不失效——不用每次重启都重新查 IP 改配置。

3.3 场景 3：多容器共享子网 + DNS 解析

1
2
3
4


docker network create --subnet=172.18.0.0/16 mynetwork

docker run -d --name app1 --net mynetwork --ip 172.18.0.10 myapp
docker run -d --name db1 --net mynetwork --ip 172.18.0.20 mysql:8

在 app1 容器内：

1
2
3
4
5
6
7


$ docker exec -it app1 bash
# ping db1
PING db1 (172.18.0.20): 56 data bytes
64 bytes from 172.18.0.20: icmp_seq=0 ttl=64 time=0.045 ms

# 也支持直接 ping IP
$ ping 172.18.0.20

关键能力：自定义网络默认开启容器名 DNS 解析——app1 容器内 ping db1 直接解析成 172.18.0.20。默认 bridge 模式没有这个能力。

四、host 网络模式的"另类固定 IP"

如果不在意隔离，host 模式下容器直接用宿主机 IP——变相"固定"了：

1

docker run -d --name nginx --net host nginx

容器内看到的 hostname -I = 宿主机 IP。

优劣：

简单粗暴

性能最佳（无 NAT）

端口冲突会直接报错——多个容器想用 80 端口就崩

五、清理自定义网络

1
2
3
4
5
6
7
8


# 列出
docker network ls

# 删指定网络
docker network rm mynetwork

# 删所有未使用的网络
docker network prune

注意：有容器正在使用的网络不能删——必须先停 / 删容器。

六、常见问题

6.1 `address already in use`

启动容器时 IP 冲突：

1
2


$ docker run -d --name test --net mynetwork --ip 172.18.0.10 centos
Error response from daemon: Address already in use

解决：

换 IP（172.18.0.11）
看哪个容器占着：docker network inspect mynetwork

6.2 不同网络之间容器无法直接通信

1
2
3
4
5
6
7
8


$ docker run -d --name web1 --net mynetwork --ip 172.18.0.10 nginx
$ docker run -d --name app1 --net othernet --ip 172.19.0.5 myapp

# 在 app1 内 ping web1
$ docker exec app1 ping web1
ping: bad address 'web1' # 解析不到
$ docker exec app1 ping 172.18.0.10
# 也不通——不同 network

解决：用 docker network connect 把容器加到另一个网络：

1

docker network connect mynetwork app1

app1 现在有两个网络接口，能直接 ping web1。

6.3 容器已经启动，想改 IP

容器运行中不能改 IP。必须：

1
2


docker rm -f <container>
docker run --ip <new-ip> ...

K8s 里这个操作对应 kubectl edit pod 改 podIP——同样需要删 Pod 重建。

七、要点回顾

默认 bridge 模式不能指定 IP——必须 docker network create 自定义网络
--net mynetwork --ip 172.18.0.10 启动容器，重启后 IP 不变
自定义网络自带 DNS 解析——容器名能直接 ping 通
跨网络通信用 docker network connect
host 网络模式“IP 等于宿主机 IP”——性能最佳但端口冲突
运行中的容器不能改 IP——必须删了重建

八、小结

固定 IP 是 docker 网络的"基础款"——理解了 docker network create + --net + --ip 三个参数，90% 的"IP 不稳定"问题就解决了。

下一步：理解了单机 Docker 固定 IP，下一步是 K8s 的 Service / StatefulSet / Headless Service——K8s 用 Service 抽象"一组稳定 IP 的 Pod"（哪怕 Pod IP 变了），StatefulSet 给每个 Pod 分配稳定 DNS 名字（pod-0.svc.namespace.svc.cluster.local），Headless Service 直接暴露 Pod IP 给 DNS。是云原生的"稳定标识"模式。

参考资料

Docker 镜像与容器导入导出：save/load/export/import 实战

Wed, 15 Jun 2016 00:00:00 +0800

“我要把 A 服务器上跑得好好的容器，搬到 B 服务器上去”——这种需求在生产环境很常见，但很多人会卡在 save / export 该用哪个。这一篇把镜像 / 容器的导入导出分清楚，再给出几个常见场景的实战方案。

阅读对象：需要在不同环境之间迁移容器 / 镜像、要做离线备份的运维 / 开发者 覆盖范围：save vs export + load vs import + 容器打包成新镜像 + 批量备份脚本

一、四种命令的差异

命令	对象	保留历史	保留元数据	典型用途
`docker save`	镜像	是（所有层）	是	镜像备份、离线迁移
`docker load`	镜像	加载 save 产物	是	镜像恢复
`docker export`	容器	否（扁平化）	否	容器快照
`docker import`	容器 export 产物	加载成新镜像	否	从容器快照恢复

核心区别：

save / load 操作的是镜像，保留完整历史（每一层构建步骤、tag、标签）

export / import 操作的是容器当前文件系统快照，扁平化成单层，丢失历史

export 出来的 import 后默认无 tag，需要手动 docker tag

二、save / load：镜像备份与离线迁移

1
2
3
4
5
6
7
8


# 导出镜像（保留原名称和 tag）
docker save <IMAGE_NAME>:<IMAGE TAG> > save.tar

# 实际例子
docker save nginx:1.19.9-alpine > nginx1.19.9-alpine.tar
docker save mysql:8.0.23 > mysql8.0.23.tar
docker save influxdb:2.0.4-alpine > influxdb2.0.4-alpine.tar
docker save anapsix/alpine-java:8_server-jre_unlimited > alpine-java8.tar

保留：

镜像名、tag

所有构建历史（docker history 能看到每一层）

标签 / env / 入口点等元数据

1
2
3


# 导入镜像
docker load < nginx1.19.9-alpine.tar
docker load < mysql8.0.23.tar

注意：save 默认输出到 stdout（用 > 重定向），load 默认从 stdin 读取（用 < 喂入）。

三、export / import：容器快照

1
2
3
4
5


# 导出容器当前文件系统
docker export <container-id> > snapshot.tar

# 实际例子
docker export 2acd22312bbe > tomcat80824.tar

1
2
3
4
5


# 从快照导入成新镜像（**默认无 tag**）
docker import snapshot.tar

# 命名（推荐）
docker import snapshot.tar myimage:v1

丢弃：

所有构建历史——扁平化为单层

容器名 / 标签 / 启动参数——只是个文件系统快照

环境变量 / 入口点——可以 import 后用 docker run 重新指定

典型场景：容器 A 上有手动修改的文件（不写在 Dockerfile 里），想"原样"搬走。export 拿到的就是 A 当前文件系统。

四、把运行中的容器打包成新镜像

需求：服务器 A 上一个容器跑得好好的，有大量数据 + 手工修改，直接迁移到 B 上。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


# 1. 在 A 上：把容器 commit 成新镜像
docker commit <container-id> <new-image-name>:<tag>

# 实际例子
docker commit 135a0d19f757 jenkins:1.0

# 2. 镜像存到 tar
docker save jenkins:1.0 > jenkins1.0.tar

# 3. 拷到 B（scp / u盘 / 内网）
scp jenkins1.0.tar root@<B-host>:/tmp/

# 4. 在 B 上：加载镜像
docker load < /tmp/jenkins1.0.tar

# 5. 在 B 上：用同样的参数启动
docker run -d --name jenkins jenkins:1.0

Why 用 commit 而不是 export：commit 把容器当前的差异化层（基于原镜像的修改）保留下来，新镜像的"基础层"还是原镜像——体积小、有历史、FROM 关系清晰。export 是纯文件系统，体积大且无继承。

五、批量备份所有镜像

1
2
3
4
5
6
7
8
9


# 备份所有镜像到一个目录
mkdir -p /backup/docker-images
for IMAGE in $(docker images --format '{{.Repository}}:{{.Tag}}' | grep -v '<none>'); do
 SAFE_NAME=$(echo $IMAGE | tr '/:' '_')
 docker save $IMAGE > /backup/docker-images/${SAFE_NAME}.tar
done

# 验证
ls -lh /backup/docker-images/

六、常见问题

6.1 `docker load` 之后镜像名变长 hash

save 没指定镜像名时，load 后镜像名是 hash：

1
2
3
4
5


$ docker load < nginx.tar
Loaded image ID: sha256:7d0a4dc9b...
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
<none> <none> 7d0a4dc9b... 2 weeks ago 187MB

解决：手动 tag。

1

docker tag 7d0a4dc9b... nginx:1.19.9-alpine

6.2 跨大版本 Docker 不兼容

docker save 产物在跨大版本 Docker 之间可能不能 load：

Docker 1.10+ 改了镜像 schema，老 daemon 可能不认新镜像
新 daemon 一般能 load 老镜像（向后兼容）

如果跨大版本不兼容：

1
2
3
4
5


# 在老 daemon 上导出
docker save -o old.tar image:tag

# 在新 daemon 上导入
docker load -i old.tar

如果还不行，升级老 daemon 或用 docker pull + 私有 registry 中转。

6.3 `save` 文件很大，传输慢

镜像层是去重的，多个镜像可以合并成一个 save 文件：

1

docker save -o multi.tar nginx:1.19 mysql:8.0 redis:6.0

load 后所有镜像都会出现。

七、save / export 的取舍速查

场景	推荐
离线环境装镜像	`save` / `load`
容器整体迁移到另一台机器	`commit` + `save` + `load`
容器当前状态备份（含手工修改）	`export` / `import`
镜像要保留构建历史	`save` / `load`
大镜像分发	私有 registry + `docker push` / `pull`（更高效）
跨大版本 Docker	升级老 daemon 或走 registry 中转

八、生产最佳实践

优先用私有 registry——docker push / pull 内部仓库比 save / load 更快、支持增量、可以做权限控制
save 文件作为离线备份、应急恢复用——不要作为日常分发方式
写 Dockerfile + rebuild——比 commit 容器更可追溯、更可复现
CI 流水线用 commit / tag 标识版本，避免"无 tag 镜像"堆积

九、要点回顾

save / load 保留历史，export / import 扁平化
commit + save + load 是"运行中容器迁移"的标准三件套
跨大版本 Docker save / load 可能不兼容——优先升级 daemon
多镜像可以合并到一个 save 文件（-o flag）
load 后无 tag 要手动 docker tag 命名

十、小结

把镜像 / 容器的导入导出搞清楚，离线环境、内部 Harbor / Registry 没起来的应急场景都能 hold 住。但生产环境强烈建议走私有 registry——save / load 是"应急"工具，不是"日常"工具。

下一步：理解了单镜像的导入导出，下一步是 Harbor / Docker Registry / Distribution 私有仓库的搭建、镜像签名、漏洞扫描——save / load 解决"单文件"问题，registry 解决"仓库级"问题。