企业官网建设流程全解析

跑过一批 LXC 容器之后，你会发现真正的门槛不在lxc-create那一行命令上。第一次拉起一个容器、lxc-attach进去看到 shell 的那一刻，确实挺爽，但把它放进一个需要长期稳定运行的环境里，问题就全冒出来了：机器重启之后容器没起来、磁盘被日志写满、内存限制设了却没生效、容器里的服务时间和宿主机差了几分钟、交接给同事之后他一脸茫然不知道怎么排错。这一篇就接着前两篇的脉络，专门聊 LXC 从“能跑起来”到“能长期跑住”中间那段最容易翻车的路，涉及生命周期管理、存储后端取舍、cgroup v2 下的资源限制写法、网络配置、非特权容器加固以及常见故障定位。适合已经用 LXC 搭过一两个实验容器、准备把它推进到半生产甚至生产环境的读者，也适合带着旧版 LXC 经验、最近升级后配置突然不生效的人对照着看。

1. 第三篇的定位：从“能起来”到“跑得稳”

1.1 前两篇留下的三个待办

前两篇把 LXC 的底子摊开了讲：namespace 负责把视图隔开，cgroup 负责把资源拦住，chroot 加上 pivot_root 把根文件系统换掉，几套机制叠在一起才叫容器，而不是虚拟机。道理讲清楚之后，落地层面还留了三个尾巴。

第一个是生命周期。手工敲lxc-start谁都会，但机器一重启全没了，这在真实场景里是致命的。LXC 本身给了lxc-autostart和配置里的lxc.start.auto，怎么和 init 系统配合、怎么控制启动顺序、怎么在容器挂掉时收到通知，这些是需要设计的。

第二个是资源限制的可靠性。很多人写了lxc.cgroup.memory.limit_in_bytes就以为万事大吉，结果发现新版发行版默认挂的是 cgroup v2，这个键直接被忽略甚至报错，容器照样把宿主机内存吃光触发 OOM。旧配置在新系统上静默失效，是升级过程里最常见的一类事故。

第三个是故障可见性。容器起不来的时候，报错信息往往只有一行 “failed to spawn”，剩下的线索全在日志和内核消息里。没有一套固定的排查路径，新手能在同一个坑里耗掉半天。

1.2 存储和网络为什么必须第二篇之后立刻讲

资源隔离讲完，紧接着一定要落到存储和网络上，因为这两块直接决定了操作的手感和后续的恢复能力。存储后端选错了，后面做快照、克隆、备份统统别扭：用 dir 后端，一次快照就是把整个根文件系统拷一遍，几十 G 的容器能让你等十分钟；换成 btrfs 或 ZFS，快照是秒级的事，代价是多一层运维知识。

网络也是同理。默认的lxcbr0加上 DHCP 能满足实验需求，但一旦容器里跑的是需要固定地址的数据库或者需要对外暴露端口的服务，就必须改成静态配置加端口转发。这两件事都不难，难在配错了之后现象的迷惑性：容器里ping通外网但宿主机访问不了容器里的服务，八成是 iptables 的 FORWARD 链被默认策略挡了，而不是网卡没起来。

提醒：以下几节的命令和配置在不同发行版、不同 LXC 版本（3.x / 4.x / 5.x / 6.x）上细节略有差异。配置文件键名在 3.0 之后有过一次大改，lxc.network.*变成了lxc.net.0.*；cgroup 的写法在 v1 和 v2 之间几乎是两套东西。照着抄之前先lxc-info --version确认一下自己手里是什么版本，能省掉大量“为什么别人可以我不行”的困惑。

2. 容器生命周期管理：让容器跟着机器一起活

2.1 lxc-* 命令族的分层其实很清楚

LXC 提供了一堆以lxc-打头的命令，刚接触时容易糊成一团，实际上它们分层很清晰。第一层是容器级操作：lxc-create建、lxc-start起、lxc-stop停、lxc-destroy删，这四个是最基础的四则运算。第二层是状态查询：lxc-ls -f一次性列出所有容器的状态、IP、是否自启，lxc-info -n <名字>看单个容器的详细信息，包括 PID、内存占用、网络配置。第三层是进入与执行：lxc-attach进容器，lxc-console连串口控制台（容器带 getty 时才有用）。

这里有个容易踩的细节：lxc-attach默认会继承一部分宿主机的环境变量，进入容器后env一看，宿主机的工作路径、locale 全在里面。想看干净的容器环境，加--clear-env，需要保留TERM、PATH这类基础变量时再单独--set-var。这个行为在做自动化脚本时影响很大，我有一次写批量巡检脚本，容器里执行的结果跟手工执行不一致，查了半天是宿主机上的LD_PRELOAD被带进去了。

# 建一个 Ubuntu 22.04 容器，download 模板会自动拉取 rootfs lxc-create -n web01 -t download -- -d ubuntu -r jammy -a amd64 # 后台启动 lxc-start -n web01 -d # 看所有容器状态，-f 输出表格 lxc-ls -f # 用干净环境进入 lxc-attach -n web01 --clear-env -- /bin/bash

lxc-ls -f的输出里有一列AUTOSTART，显示的是YES还是NO。这一列直接对应配置文件里的lxc.start.auto，也是下一节的主角。

2.2 开机自启的配置与 lxc-autostart 的执行逻辑

让容器跟着宿主机开机启动，配置只有一行，写在容器的 config 里：

# /var/lib/lxc/web01/config lxc.start.auto = 1 lxc.start.delay = 5 lxc.start.order = 10

三个键的含义分别是：auto = 1表示开机启动，delay = 5表示这个容器启动后等 5 秒再启动下一个，order是启动顺序，数字小的先起。这套机制看起来简单，但有个关键点必须理解：LXC 本身不是守护进程，它不会自己盯着开机时机。真正触发启动的是lxc-autostart这个命令，需要由 init 系统在开机时调用一次。

大部分发行版的 LXC 包会带一个 systemd 单元lxc.service，里面执行的就是lxc-autostart -a。所以排查“容器没自启”的第一步，不是翻容器配置，而是确认这个单元的状态：

systemctl status lxc.service systemctl is-enabled lxc.service

如果lxc.service是 disabled 的，容器配了auto = 1也没用。这一条我在至少三个不同的环境里遇到过，共同点是系统用了精简镜像，或者安装 LXC 时用了--no-install-recommends，把服务单元漏掉了。

lxc-autostart还有几个实用的参数值得记住。-g <group>只启动属于某个组的容器，组名在容器配置里用lxc.group = prod声明，一台机器上同时跑测试容器和生产容器时特别好用，可以给两组配不同的 systemd 单元和不同的启动时机。-L只列出会启动哪些容器而不实际启动，做变更前的确认很合适。-r是先停再起，等于重启。

2.3 有序启动与依赖关系的手工编排

lxc.start.order只能表达“谁先谁后”，表达不了“谁依赖谁”。容器 10 启动了，但它里面的数据库要 30 秒才能真正接受连接，容器 20 里的应用这时候已经在重试连接了，重试 5 次失败之后就挂了。这种问题在order加delay的组合下只能靠调大 delay 硬扛，很不优雅。

更稳的做法是在容器内部管理服务，而不是在宿主机层面排队。容器里的 systemd 有自己的After=、Requires=语义，真正需要跨容器依赖的时候，可以在应用侧做重试退避，或者在宿主机上写一个小的启动脚本，用就绪探测代替固定等待：

#!/bin/bash # 简化的就绪等待：轮询容器的 3306 端口，最多等 120 秒 for i in $(seq 1 120); do if lxc-attach -n db01 --clear-env -- /bin/sh -c 'ss -lnt | grep -q :3306'; then echo "db01 ready after ${i}s" break fi sleep 1 done lxc-start -n app01 -d

心得：lxc.start.delay设得再大也只是赌一个固定时间，机器负载高的时候照样不够。凡是跨容器的启动依赖，宁可写 20 行就绪探测脚本，也别靠调大 delay 硬凑。这套脚本稳定运行半年之后，我把所有 delay 都改回了 1 秒，启动总耗时反而缩短了。

3. 存储后端：快照、克隆和磁盘打满的应对

3.1 四种后端的实测对比

LXC 支持的后端不少，常用的有 dir、btrfs、ZFS、LVM 四类。它们的差别不只是性能，更在于快照和克隆这两件事能不能做、做起来有多快。下面这张表是我在一台普通 SATA SSD 机器上实测整理出来的，容器根文件系统大小统一按 8G 算。

创建时用-B参数指定后端，具体参数通过--之后传给模板：

# btrfs 后端，需要宿主机的 /var/lib/lxc 位于 btrfs 分区上 lxc-create -n dev01 -B btrfs -t download -- -d ubuntu -r jammy -a amd64 # ZFS 后端，同时给容器根目录设个 5G 配额 lxc-create -n dev02 -B zfs -t download -- -d debian -r bookworm -a amd64 # LVM 后端，指定卷组和大小 lxc-create -n dev03 -B lvm --vgname vg0 --fssize 8G -t download -- -d alpine -r 3.19 -a amd64

选型上我的建议很直白：单机实验用 dir 就够了，别为了快照去折腾文件系统；容器数量上到十几个、需要频繁复制环境给同事用，btrfs 最省事，代价是 btrfs 本身在磁盘快满时的表现不太友好，需要留足冗余；ZFS 适合对配额和压缩有要求、又愿意花时间学一轮 ZFS 基本操作的场景；LVM 适合本来就在用 LVM 管磁盘的机房，好处是块设备层面的管理工具链已经很成熟。

3.2 快照与克隆的正确姿势

快照用lxc-snapshot，克隆用lxc-copy，两者容易混。快照是给同一个容器留时间点状态，回滚也回到自己身上；克隆是产出一个新容器，两个容器之后各走各的。

# 给 web01 打一个快照，名字叫 before-upgrade lxc-snapshot -n web01 -c before-upgrade # 列出快照 lxc-snapshot -n web01 -L # 回滚到某个快照（会先自动做一个当前状态的快照，防止误操作丢数据） lxc-snapshot -n web01 -r snap0 # 从 web01 克隆出一个新容器 web02，-s 表示用快照方式（后端支持时才是秒级） lxc-copy -n web01 -N web02 -s

lxc-copy -s在后端支持写时复制时非常快，但它有个副作用：新容器和原容器共享底层数据块，如果原容器之后被lxc-destroy，底层数据可能被回收，新容器就出问题了。想彻底独立，加-K（keep 数据但断开共享）或者干脆用-B指定全量复制。这一点在把测试环境克隆出去给同事用的时候尤其要注意，我吃过一次教训：同事拿着克隆出来的容器改了一周，我把源容器删了，他那边直接起不来。

注意：快照不是备份。快照和原容器在同一块盘上，盘挂了两个一起没。真要保命，还是得用lxc-copy -B dir导出到另一台机器，或者直接tar打包根文件系统目录（/var/lib/lxc/<name>/rootfs）传走，简单粗暴但可靠。

3.3 磁盘打满的三种典型情况和预防

容器把宿主机磁盘写满，是 LXC 用久了一定会遇到的事故，表现形式还很不一样。

第一种是日志打满。容器里某个服务的日志没做轮转，一天写几十 G，因为 dir 后端下容器根文件系统就是宿主机文件系统的一个普通目录，写满了直接影响到宿主机本身，连systemd-journald都可能写不进去，整机表现是各种莫名其妙的服务重启。防护手段是在容器配置里加磁盘配额——但这只对 btrfs/ZFS 有效，dir 后端没有配额能力，只能靠监控告警加日志轮转配置。

第二种是容器内的临时文件堆积。容器里跑构建任务、跑临时脚本，/tmp下的东西没人清，一个月下来几个 G。这种可以在容器内配 systemd-tmpfiles，或者在宿主机上写一个定期lxc-attach进去清理的任务。

第三种是镜像层重复。用 dir 后端克隆了十个容器，每个都占全量空间，宿主机 500G 的盘装十个 40G 的容器就见底了。这种本质上不是“打满”而是“浪费”，换成 btrfs/ZFS 的写时复制能立刻缓解。

# 快速定位哪个容器占空间最多（dir 后端） du -sh /var/lib/lxc/*/rootfs 2>/dev/null | sort -rh | head -10 # ZFS 后端看各数据集的配额和使用 zfs list -o name,used,quota,refer -r rpool/lxc

配额的具体配置在 ZFS 后端下最简单，建容器时加--fssize或者在数据集上用zfs set quota=20G，超了直接写失败，容器内的服务会报No space left on device但宿主机安然无恙。这就是配额的价值：把故障圈在容器里，别让它扩散。

4. 资源限制：cgroup v2 时代必须改的写法

4.1 为什么旧的 memory 限制键会静默失效

lxc.cgroup.memory.limit_in_bytes这个键在 cgroup v1 时代是标配，网上大量教程还在用它。但现代发行版（比如近几年的主流桌面与服务发行版）默认已经切到 cgroup v2 统一层级，此时 LXC 会去 cgroup v2 的文件系统里找对应控制器，发现键名对不上，结果就是——不报错，也不生效。容器照样启动，lxc-info看内存占用也正常，但限制形同虚设，直到某天内存被吃满触发宿主机 OOM Killer，随机杀掉几个进程，你才发现问题。

判断当前系统用的是哪套层级，一条命令就能确认：

# 看挂载类型，cgroup2 表示 v2，cgroup 表示 v1 stat -fc %T /sys/fs/cgroup

如果是cgroup2fs，配置就得换成lxc.cgroup2.*的写法。两套写法的对照关系如下：

4.2 内存和 CPU 参数怎么算出来

memory.max的语义是“超过就触发 OOM”，写1G就是 1G，这个直白。麻烦的是 swap 那一项，v2 里memory.swap.max的数值是单独的 swap 用量，不是内存加 swap 的合计。想做到“内存 1G、最多再借 512M swap”，就是memory.max = 1G配memory.swap.max = 512M，两个数各管各的。

cpu.max的格式是配额 周期，周期固定写 100000（微秒，即 100ms）。想让容器最多用满 2 个核，配额写 200000，即 200ms 的 CPU 时间要在 100ms 内跑完，等价于两个核并行。想限制到半个核，配额写 50000，这个计算不难，但在容器数量多、每个都要精打细算的场景里，建议先用表格列出来再统一写进配置，避免手抖。

# /var/lib/lxc/app01/config 片段 # 内存：硬限 1G，软限 768M，另给 512M swap lxc.cgroup2.memory.max = 1G lxc.cgroup2.memory.high = 768M lxc.cgroup2.memory.swap.max = 512M # CPU：最多两个核，权重 50（对应 v1 的约 512 shares） lxc.cgroup2.cpu.max = 200000 100000 lxc.cgroup2.cpu.weight = 50 # 只允许跑在 0-3 号核上，避开宿主机上跑关键任务的核 lxc.cgroup2.cpuset.cpus = 0-3

memory.high这个软限制挺有意思：内存超过它之后，内核不会立刻杀进程，而是把这个 cgroup 里的进程节流，让它们跑得慢一些，逼它们自己回收内存。对省内存有要求但又能容忍偶发变慢的场景很合适，比直接用memory.max一刀切要温和。

4.3 参数生效验证与常见误区

配完不等于生效，必须验证。最直接的验证方法是进容器跑一个吃内存的程序，同时在外面看lxc-info的内存占用是否能稳定停在限制值附近：

# 容器里尝试分配 2G 内存（容器限制是 1G） lxc-attach -n app01 --clear-env -- \ dd if=/dev/zero of=/dev/null bs=1M count=2048 # 另一个终端看内存和 OOM 计数 lxc-info -n app01 -s cat /sys/fs/cgroup/lxc.payload.app01/memory.events 2>/dev/null

memory.events里有个oom_kill计数器，数字涨了就说明限制确实在起作用。如果 dd 跑完内存占用冲到了 2G，说明限制没生效，回头检查上一条说的 v1/v2 写法问题。

常见的误区有三个。一是在容器内部再设限制，容器里的 systemd 也会创建自己的 cgroup 子树，但它是宿主机 cgroup 的子集，父级限制才是硬边界，在容器里设MemoryMax=只能更严格、不能更宽松。二是以为 CPU 限制能防止卡顿，cpu.max限制的是使用量，宿主机整体负载爆掉的时候，容器照样会变慢，那是调度和 IO 的问题，不是 CPU 配额能解的。三是cpuset 配了但没配cpuset.mems，部分内核版本下只配 cpus 会报错，稳妥起见两个一起写，mems 通常写0就行（单 NUMA 节点机器）。

提示：修改 cgroup 相关配置之后，必须lxc-stop再lxc-start才生效，热更新是不支持的。改完记得用lxc-info -s复核一遍实际值，别只看了眼配置文件就当完事。

5. 网络配置：从默认 NAT 到固定地址

5.1 默认 lxcbr0 的工作方式

安装 LXC 之后，系统里通常会自动出现一块lxcbr0网桥，地址段默认10.0.3.1/24，并且带一个 dnsmasq 负责给容器发 DHCP。新建容器的默认配置里就是lxc.net.0.link = lxcbr0，所以容器起来就能拿到一个10.0.3.x的地址，能访问外网，宿主机也能访问容器，但反过来容器不能直接被外部访问——因为出口走的是 NAT。

这套默认配置对实验特别友好，缺点是地址会变、也没有对外的可达性。容器里跑个 Web 服务，宿主机上用curl 10.0.3.x:8080能通，同一局域网的另一台机器就连不上，很多人第一次遇到时会以为是防火墙的问题，其实是 NAT 的单向性。

5.2 静态地址与端口转发

需要固定地址时，最省事的做法是在容器配置里直接指定，走 DHCP 保留地址或者干脆写静态：

# /var/lib/lxc/web01/config 网络部分 lxc.net.0.type = veth lxc.net.0.link = lxcbr0 lxc.net.0.flags = up lxc.net.0.hwaddr = 00:16:3e:aa:bb:cc lxc.net.0.ipv4.address = 10.0.3.50/24 lxc.net.0.ipv4.gateway = 10.0.3.1

hwaddr建议显式写死。默认情况下 LXC 会自动生成一个 MAC，容器重建的时候 MAC 变了，如果容器里配置了依赖 MAC 的服务（比如某些授权绑定），就会莫名其妙失效。手工指定一个00:16:3e开头的地址，这个前缀是 LXC 的惯例，跟虚拟机平台常用的地址段区分开，能避免生成时撞车。

要让局域网其他机器访问容器里的服务，就得做端口转发。宿主机上的 dnsmasq 或者 iptables 都能干，iptables 更通用：

# 把宿主机的 8080 转发到 web01 的 80 iptables -t nat -A PREROUTING -p tcp --dport 8080 \ -j DNAT --to-destination 10.0.3.50:80 iptables -A FORWARD -p tcp -d 10.0.3.50 --dport 80 -j ACCEPT

第二条FORWARD规则是很多人漏掉的。默认策略是 DROP 的时候，DNAT 改完目标地址，包在 FORWARD 链被拦下，表现出来就是“连接超时”而不是“拒绝连接”，非常迷惑。

5.3 桥接物理网卡与直通网络

如果容器需要像一台独立机器那样出现在局域网里，让上游路由器直接给它分地址，那就得做桥接。做法是把宿主机的一块物理网卡加入网桥，容器的 veth 挂到这个网桥上，而不是lxcbr0。

# 用 iproute2 建网桥并挂物理网卡（示例，操作前确认有带外访问手段，改错会断网） ip link add name br0 type bridge ip link set eth1 master br0 ip link set br0 up

# 容器侧改成挂 br0 lxc.net.0.type = veth lxc.net.0.link = br0 lxc.net.0.flags = up lxc.net.0.ipv4.address = 192.168.1.50/24 lxc.net.0.ipv4.gateway = 192.168.1.1

注意：桥接物理网卡是个有断网风险的操作，尤其是把宿主机的管理口挂进去的时候。远程操作前先确认有带外控制台或者别的访问路径，我见过不止一次“重启网络之后 SSH 再也连不上”的事故，最后只能去机房接显示器。稳妥顺序是先建好网桥、把物理口加进去、宿主机自己的地址迁到 br0 上，确认宿主机网络正常之后再动容器配置。

6. 安全加固：非特权容器与能力裁剪

6.1 特权容器到底特权在哪

默认创建的容器是特权容器，容器里的 root 就是宿主机上的 root（UID 0 映射到 UID 0）。namespace 确实把进程视图隔离了，但文件权限、某些设备访问、部分内核接口的检查是按 UID 走的，一个容器里的 root 如果拿到逃逸手法，后果直接是宿主机的 root。这也是容器安全讨论里绕不开的话题。

非特权容器把映射关系反过来：容器内的 UID 0 映射到宿主机上的一个普通用户（比如 100000），容器内的 root 在宿主机上只有普通权限，即使容器内出了提权，能碰到的范围也被压缩到一个普通用户的权限里。代价是需要配置 UID 映射，以及容器里某些需要真正 root 权限的操作会失败（比如挂载文件系统、操作某些设备）。

配置分两步。宿主机侧要在/etc/subuid和/etc/subgid里给这个用户分一段 UID 范围：

# /etc/subuid lxcuser:100000:65536 # /etc/subgid lxcuser:100000:65536

容器配置里写映射关系，最简单的是u 0 100000 65536，意思是容器内的 UID 0 到 65535 依次映射到宿主机的 100000 到 165535：

# /var/lib/lxc/safe01/config lxc.idmap = u 0 100000 65536 lxc.idmap = g 0 100000 65536

建容器时要指定以非特权方式创建，-t download后面加上用户参数，或者直接用带--的形式传给模板：

lxc-create -n safe01 -t download -- -d alpine -r 3.19 -a amd64 # 创建后用非特权用户身份运行，需要该用户对 /var/lib/lxc 下的目录有权限

实际操作中更常见的路径是让非特权用户在自己的家目录下建容器，lxc-create会自动把容器放到~/.local/share/lxc/（不同版本路径略有差异），权限问题就自然绕开了。

6.2 capability 裁剪：不是所有容器都需要全部能力

Linux 把 root 的特权拆成了几十个 capability，容器默认保留了一大批。绝大多数服务根本用不上，裁剪掉能显著缩小攻击面。常见的做法是在配置里 drop 掉一批高风险能力：

# 丢弃一批容器里基本用不上的能力 lxc.cap.drop = sys_module sys_rawio sys_admin \ mac_admin mac_override sys_time sys_boot \ sys_nice sys_resource sys_ptrace

sys_module能加载内核模块、sys_rawio能直接访问硬件、sys_admin涉及大量系统管理操作，这三个是最该优先丢掉的。sys_time涉及改系统时间，丢掉之后容器内date -s会失败，这反而是好事——容器改自己的时间视图会影响宿主机，是个经典的坑。

裁剪要考虑服务实际需求。跑 Nginx 的容器丢掉这些没什么影响；但如果容器里跑的是需要chroot或者挂载操作的服务，丢sys_admin就会挂。稳妥的流程是先在测试容器上做裁剪，跑一遍完整业务，观察有没有权限相关报错，再推广到生产。

6.3 seccomp 与 AppArmor 的叠加

seccomp 负责限制容器内能调用哪些系统调用，AppArmor 负责限制能访问哪些路径和资源，两者叠加才是完整的。LXC 自带一套默认的 seccomp 白名单，配置里默认就会启用：

lxc.seccomp.profile = /usr/share/lxc/config/common.seccomp lxc.apparmor.profile = lxc-container-default

想更严格的话，可以从默认策略出发做减法。我自己常用的一个做法是先把策略设为lxc-container-default-cgns（比默认更宽松一点，允许部分 cgroup 操作），跑一段时间看dmesg里的audit记录，看看哪些系统调用被拒了但业务确实需要，再决定是放开还是改业务。反过来直接上最严的策略，往往是一堆服务起不来，然后被迫整体放开，等于白折腾。

心得：安全加固最大的敌人是“一次改太多”。我习惯的做法是每轮只动一个维度——这轮只做 capability 裁剪，下轮只收紧 seccomp，每轮都跑一遍完整回归。这样出问题的时候能立刻定位到是哪一层的改动导致的，而不是面对一堆报错无从下手。

7. 故障排查实战：几类高频问题的定位路径

7.1 容器起不来：从日志和退出码入手

lxc-start返回非零但没有详细错误，是最常见的一类。把-l参数用起来，指定日志级别和输出位置：

# 前台启动并输出 DEBUG 日志到指定文件 lxc-start -n web01 -F -l DEBUG -o /tmp/lxc-web01.log

-F是前台运行，配上-l DEBUG，日志里会把每一步做了什么、卡在哪一步都打出来。常见的失败原因就这么几类：根文件系统路径不对（改了lxc.rootfs.path但路径不存在）、配置文件语法错（少个等号、值里有空格没引号）、网络配置里引用的网桥不存在、cgroup 键名在当前版本下不被识别。

如果是权限相关，日志里会出现Permission denied或者Operation not permitted，这时候要往两个方向查：是不是非特权容器但 UID 映射没配对，或者宿主机上 AppArmor 拦了。

# 看内核层面的拒绝记录 dmesg | tail -50 journalctl -k --since "10 min ago" | grep -i -E "apparmor|denied"

7.2 容器起来了但网络不通

网络问题的排查顺序建议固定下来：先看接口，再看地址，再看路由，最后看转发规则。

# 宿主机上看容器的 veth 对 ip link show | grep -A1 veth # 进容器看接口和地址 lxc-attach -n web01 --clear-env -- ip addr show eth0 # 容器内看默认路由 lxc-attach -n web01 --clear-env -- ip route show # 宿主机上确认 NAT 和转发 iptables -t nat -L POSTROUTING -n -v cat /proc/sys/net/ipv4/ip_forward

ip_forward是 0 的话，容器出不了网，一条sysctl -w net.ipv4.ip_forward=1解决，但记得写进/etc/sysctl.d/里做持久化，不然重启又回去了。

7.3 常见问题速查表

8. 迁移、备份与交接时该留什么

8.1 迁移的两种粒度

迁移容器有两个粒度：整体迁移和重建迁移。整体迁移是把/var/lib/lxc/<name>整个目录打走，拷到目标机器上，改一下配置里的网络和存储路径就能起来。这种方式简单粗暴，缺点是体积大、目标机器的存储后端可能和源机器不一样。

# 源机器上停止容器并打包 lxc-stop -n web01 tar -C /var/lib/lxc -czf web01-backup.tar.gz web01 # 目标机器上解压并检查配置 tar -C /var/lib/lxc -xzf web01-backup.tar.gz # 修改 lxc.rootfs.path、lxc.net.* 后再启动 lxc-start -n web01 -d

重建迁移更干净：把容器内的服务用配置管理工具重新部署到目标机器的新容器里，数据走单独的备份恢复通道。这套方式的可维护性高得多，代价是需要前期在配置管理上投入。容器数量超过十个之后，我基本只用第二种，因为整体迁移带来的配置漂移问题会越积越多，最后没人说得清每个容器的配置差异是从哪来的。

8.2 备份策略与恢复演练

备份的核心不是“备份了”，而是“能恢复”。常见的失败模式是备份跑了半年，真出事的时候发现备份文件是空的或者恢复不出来。所以配完备份任务之后，一定要做恢复演练，而且要在另一台机器上演练，避免在原机器上恢复把现场搞乱。

一个可执行的最小策略：每天的容器数据目录做一次增量备份（rsync 到另一台机器或者对象存储），每周做一次全量，保留四周。备份完成后校验一下包的可读性：

# 校验 tar 包完整性 gzip -t web01-backup.tar.gz && echo "archive ok" # 恢复演练：解到临时目录看目录结构是否完整 mkdir -p /tmp/restore-test tar -C /tmp/restore-test -xzf web01-backup.tar.gz ls /tmp/restore-test/web01/rootfs/etc/os-release

第二条检查看起来有点傻，但它能立刻暴露“备份包里根本没有 rootfs”这种致命问题——我就遇到过因为排除规则写错导致rootfs目录整个被跳过的情况，备份跑了两周才发现。

8.3 交接文档该写什么

容器的交接比虚拟机的交接更依赖文档，因为容器的状态散落在好几个地方：配置文件、存储后端、网络规则、宿主机上的 systemd 单元，任何一处没写清楚，接手的人都要重新摸一遍。

我的模板里固定包含这几项：容器名与用途的一句话说明、存储后端类型和路径、网络模式（NAT/桥接）与地址、资源限制参数、依赖的宿主机侧配置（iptables 规则、sysctl 项、systemd 单元）、备份任务的执行位置和恢复步骤。写下来大概一页纸，但能让接手的人省掉半天。

9. 我在这套东西上踩过的几个坑

说几个只有真跑过才会知道的细节。第一个是lxc-stop默认会等容器内进程自己退出，如果容器里有不响应信号的进程，它会一直等到超时，默认超时时间还不短。急着下线的时候加-k强制杀掉，或者先-t 5缩短等待。我见过一次批量下线脚本卡在一个容器上四个小时，就是因为容器里有个僵尸进程不响应。

第二个是配置文件的读取顺序。容器的实际配置是/etc/lxc/default.conf、/etc/lxc/lxc.conf（如果有）、/var/lib/lxc/<name>/config层层叠加的结果，后面的覆盖前面的。有一次改了default.conf里的网络配置，重启容器却发现没变化，查了半天是容器自己的 config 里显式写了网络段，把默认值顶掉了。排查这类问题最直接的办法是lxc-info -n <name>看实际生效值，别看配置文件猜。

第三个是时间。容器默认有独立的时间命名空间，容器里改时间不影响宿主机，但反过来容器里的时钟也不会跟着宿主机自动同步。机器休眠恢复之后，容器里的时间可能已经偏了几小时，跑 TLS 校验的服务会直接报证书过期。解决办法是在容器里也跑一个时间同步客户端，或者在容器配置里去掉time命名空间（lxc.namespace.keep = time，具体写法看版本），让容器直接用宿主机的时钟。这个选择取决于容器里的服务能不能容忍时间被外部改动，稳妥起见我倾向让容器内自己同步。

第四个是lxc-attach和lxc-console的差别。attach走的是 LXC 直接在容器命名空间里 fork 一个进程，不经过容器内的 getty，所以速度极快但没有登录流程；console连的是容器内的串口或者 tty，需要容器里跑了 getty，好处是可以看到容器启动过程中的输出，调试 init 系统的问题非它不可。容器起不来但没日志的时候，把配置里的lxc.tty.max调大、加上lxc.console.logfile，能把容器启动的全过程输出到文件里，这是排查早期启动问题最有效的手段。

最后一个不算坑，但值得说一句：LXC 这个东西的发展节奏这几年慢下来了，很多新项目直接奔着更高层的编排工具去了。但它在“单机、少量容器、想贴近传统系统管理习惯”这个场景里依然非常顺手——你拿到的是一个完整的 init 系统、一套正常的systemctl、一份和物理机几乎一样的文件布局，排查问题的思维方式和排查一台机器没有区别。真要说清楚它在哪些场景下不可替代，那就是当你需要一个容器，但不想为它引入一整套编排概念的时候。