容器切换实战：从Docker生命周期到Spring IOC与主备切换

1. 容器切换，先分清你要切的是哪种容器

先说个扎心的现实：很多人在第一次处理"容器切换"时，往往不是卡在命令上，而是卡在概念上。因为"容器"这个词在技术圈里早就被用烂了：搞运维的说到容器，脑子里是 Docker；写 Java 的说到容器，脑子里是 Spring IOC 容器或者 Servlet 容器；做嵌入式的还会跟你说 LVGL 里的容器控件。所以"实现容器切换"这件事，必须先分清楚你面对的是哪一种容器，否则后面所有操作都是南辕北辙。

1.1 运行态切换：Docker容器生命周期管理

最常说的容器切换，其实就是 Docker 运维场景里，让运行环境从一个容器换到另一个容器。比如你有一个 nginx 容器在跑业务，现在想换成另一个版本，或者想进入容器内部看看日志、改配置，这些都属于运行态切换。本质上是围绕容器生命周期做操作：创建、启动、停止、重启、进入，以及容器与宿主机之间的文件交互。

这就像你在电脑上开了好几个虚拟机软件，你想从正在运行的 Ubuntu 虚拟机切换到 Windows 虚拟机，你得先挂起或者保持后台运行，然后打开另一个。Docker 里也一样，多个容器同时在线是很正常的，切换意味着你要么创建新的容器并启动，要么进入一个已经存在的容器去操作。

1.2 开发态切换：IOC容器里的Bean与环境切换

如果你是个写 Java 的开发者，那你说的"容器切换"大概率不是 Docker，而是 Spring IOC 容器。Spring 把对象的创建和依赖关系托管到容器里，你只需要从容器里获取 Bean。切换的意思是：同样的代码，在不改源码的情况下，从 dev 环境切到 prod 环境、切换不同的 Bean 实现、甚至把基础的 Tomcat 容器换成 Jetty 或 Undertow。

很多新手在百度搜"容器切换"时，看到一堆 Spring 相关的内容直接懵了，其实是搜索词撞上了两个完全不同的知识体系。这一篇我会把这两种场景都讲清楚，你根据自己的身份对号入座就行。

1.3 架构级切换：主备切换与拓扑切换是怎么回事

再往上走一步，"切换"这个词在架构领域还有两个高频概念：主备切换和拓扑切换。主备切换是指当主节点挂了，系统自动把流量切到备用节点；拓扑切换则是改变整个集群的网络或服务拓扑，比如从单节点切到多节点，或者某个服务的调度规则重新编排。

在容器化部署之后，这两种"切换"的落地方式跟传统物理机时代已经完全不同了。原来可能要人工改 DNS、改负载均衡配置，现在可以靠容器编排系统配合健康检查自动完成。这也是后文要重点展开的内容。

2. Docker容器切换实操：从启动到进入的完整姿势

明确了你要切的是 Docker 容器，那下面这些命令就是最基本的功。我在实际维护中发现，很多人其实连 docker run 和 docker start 的区别都没搞清楚，结果容器明明创建了却"起不来"，其实不是起不来，是你用了错误的命令。

2.1 容器的生命周期：create、start、run到底怎么用

Docker 容器的生命周期可以拆成几个阶段：镜像存在、容器创建、容器启动、容器运行、容器停止、容器删除。很多新手第一次用的时候，看到 docker run 能创建并启动容器，就以为 docker create 没用，其实两者分工完全不同。

• docker create：只创建容器，不启动。相当于你买了一台电脑，组装好了，但没通电。
• docker start：启动一个已经创建但处于停止状态的容器。按一下开机键。
• docker run：create 和 start 的合集，一条命令直接创建并启动。这也是日常用得最多的。

举个例子，你要部署一个 Nginx：

bash复制docker run -d --name web-server -p 8080:80 nginx:1.25

这条命令会拉取 nginx:1.25 镜像（如果本地没有），创建容器并后台启动。容器名字叫 web-server，把宿主机的 8080 端口映射到容器里的 80 端口。

如果你想"切换"到另一个版本的 nginx，比如从 1.25 切到 1.26，不是直接改，而是先停掉旧容器，再用新镜像跑一个新容器：

bash复制docker stop web-server
docker rm web-server
docker run -d --name web-server -p 8080:80 nginx:1.26

这里要特别注意：docker stop 只是停止，容器还在；docker rm 才是把容器删除。如果你不想删掉旧容器，想保留现场做对比，可以换一个名字：

bash复制docker stop web-server
docker run -d --name web-server-126 -p 8081:80 nginx:1.26

这样旧容器和新容器都保留着，端口错开，随时能在两者之间来回切换。这种"保留现场"的方式在生产环境排查问题时非常有用，我后面还会细说。

2.2 进入运行中容器的首选：docker exec深度解读

容器起来了，怎么进去？Docker 官方提供的命令是 docker exec。这个命令的核心作用是：在运行中的容器里执行一个命令。最常见的用法是进入一个容器的交互式 shell：

bash复制docker exec -it web-server /bin/bash

• -i 表示保持标准输入打开，也就是允许你输入命令
• -t 表示分配一个终端，这样你才能看到命令行提示符
• web-server 是容器名
• /bin/bash 是启动的 shell 程序

如果容器是精简版镜像，比如很多基于 Alpine Linux 的镜像没有 bash，那就用 sh：

bash复制docker exec -it web-server /bin/sh

这里有个非常实用的技巧：docker exec 可以指定用户。如果你想以 root 身份进入容器，但容器默认用户不是 root，可以加 -u 参数：

bash复制docker exec -it -u root web-server /bin/bash

还有一个参数 -w 可以指定工作目录。比如你想进入容器后直接到 /var/log：

bash复制docker exec -it -w /var/log web-server /bin/bash

实测下来，docker exec 是进入容器最安全、最不影响业务的方式，因为它只负责在容器里新起一个进程，不会干扰容器的主进程（PID 1）。

提示：docker exec 进去以后，你所做的修改只在当前容器层生效。如果你想保存这些改动，要么在容器里改完再 docker commit 生成新镜像，要么提前挂载数据卷。否则容器一删，里面所有手工操作全部消失。

2.3 attach和nsenter：什么场景才值得用这两种姿势

说完了最推荐的 docker exec，再说两个我踩过坑的姿势：docker attach 和 nsenter。

先看 docker attach。它的作用是把标准输入输出直接连接到容器的主进程上。听起来跟 exec 差不多，但实际体验天差地别。如果你用一个跑着 nginx 的容器，执行：

bash复制docker attach web-server

你会发现窗口里一直在刷 nginx 的访问日志，而且会因为无法交互而手足无措。更坑的是，如果你在这个状态下按了 Ctrl+C，会直接给容器主进程发送中断信号，容器可能就停了。虽然可以加 --sig-proxy=false 避免信号传递，但总之，我强烈不建议用它来做日常"进入容器"的操作。

再看 nsenter。这招是在容器里连 bash 都没有的情况下用的。它的原理是直接通过 Linux 内核的 namespace 进入容器视角。操作分两步：

bash复制# 第一步：查到容器的主进程 PID
docker inspect -f {{.State.Pid}} web-server

# 第二步：用 nsenter 进入这个 PID 对应的命名空间
nsenter -t 12345 -n -u -i -p -m

其中 -n 是网络命名空间，-u 是 UTS，-i 是 IPC，-p 是 PID，-m 是挂载点。实测下来，这个方法在宿主机上需要安装 util-linux，而且你进入的是一个"半初始化"的环境，环境变量、shell 配置都不完整。除非容器里连 shell 都起不来，否则我不会优先用这招。

2.4 切换容器时保留现场的两个土办法

我在实际运维中经常遇到一种需求：容器出问题了，但我得保留现场给开发看，同时要让业务先跑起来。这时候有两个土办法很管用。

第一个是 docker commit。把出问题的容器直接固化成镜像：

bash复制docker commit web-server web-server-debug-backup

这样即使你删掉原容器，这个带现场状态的镜像还在，后面随时可以 docker run 这个镜像来复现问题。

第二个是把整个容器导出成 tar 包：

bash复制docker export web-server -o web-server.tar

docker export 导出的是容器文件系统，不包含镜像历史层。跟 docker save（保存镜像）不同，export 更适合现场保留和快速迁移。比如你发现一个容器里的配置被调乱了，但说不清到底改了哪里，直接 export 出来归档，之后用 tar 包在另一台机器上导入成容器：

bash复制docker import web-server.tar web-server-debug:v1

这个在新容器里原样还原现场，排查完问题再扔掉。

对于很多人喜欢部署的青龙面板这类应用，我用同样思路处理升级：先 docker inspect 看挂载了哪些 volume，确认数据和配置目录都挂载出来后再换镜像重建容器。只要挂载路径不丢，删除容器重建是安全的，数据不会丢。最怕的是第一次部署时图省事没挂 volume，升级时一删容器，数据库和配置全没了，那真是叫天天不应。

3. 容器间的文件、权限与设备映射

容器切换过程中，最让人头疼的往往不是容器怎么启动，而是文件权限和设备访问的问题。这一节把我在生产环境里踩过的坑集中说一遍，这些问题你在官方文档里能看到，但没人告诉你它们组合起来有多坑。

3.1 挂载目录时读写权限到底怎么给才不发愁

Docker 挂载目录用的是 -v 参数，基本格式是 宿主机目录:容器目录。默认情况下挂载进去的目录是读写（rw）权限，也就是说容器里的进程可以随便改宿主机目录下的文件。

bash复制docker run -d -v /data/web:/usr/share/nginx/html:rw --name web web-server:v1

如果你想给容器只读权限，防止容器里程序误改宿主机文件，就把 rw 改成 ro：

bash复制docker run -d -v /data/web:/usr/share/nginx/html:ro --name web web-server:v1

但真正让新手崩溃的不是 rw 和 ro，而是权限不一致导致的"文件写不进去"。典型场景：宿主机上 /data/web 目录属主是 UID 1000 的用户，而容器内运行进程的用户是 root（UID 0），或者反过来，容器内进程是普通用户（UID 999），宿主机目录需要它写入。结果就是明明挂载了，容器里却报 Permission denied。

解决方案有三个思路。第一个最简单：宿主机目录给够权限，直接 chmod 777（仅适合自己测试环境，别在生产这么干）。第二个是让容器里的用户 UID 跟宿主机一致，比如用 -u $(id -u):$(id -g) 启动容器：

bash复制docker run -d -u $(id -u):$(id -g) -v /data/web:/usr/share/nginx/html web

第三个是使用用户命名空间（userns-remap），把容器内的 root 映射到宿主机非 root 用户，这个配置在 Docker daemon 的 daemon.json 里：

json复制{
  "userns-remap": "default"
}

开启后容器内 UID 0 会映射到宿主机一个普通用户，权限管理就安全很多，但副作用是容器内某些需要特权能力的操作会受影响。建议先在测试环境验证再上生产。

补充一个 Windows 和 Mac 上的 Docker Desktop 特有问题：由于桌面版 Docker 是通过虚拟机运行 Linux 容器，挂载目录的权限映射机制跟 Linux 原生环境不一样，经常出现明明目录是共享的，但容器里看到属主全是 root。这个大多是 Docker Desktop 的文件共享方式（gRPC-FUSE 或 VirtioFS）导致的，暂时没有完美的统一解法，只能尽量用 Linux 服务器做复杂文件操作。

3.2 容器内外交换文件：docker cp与volume的取舍

容器切换时经常要在容器和宿主机之间拷贝文件。最直接的方式是 docker cp：

bash复制# 从容器拷贝到宿主机
docker cp web-server:/var/log/nginx/access.log ./access.log

# 从宿主机拷贝到容器
docker cp ./app.jar web-server:/opt/app.jar

docker cp 有个特点：不管容器是否在运行，都能拷贝。对于临时往容器里丢个文件或者捞日志，非常好用。但它不适合频繁双向往来的场景，那种情况还是老老实实挂 volume，宿主机和容器共享一个目录，改哪边都一样。

如果是批量迁移多个容器之间的文件，我更推荐用数据卷。新建一个 volume，挂到两个容器上：

bash复制docker volume create shared-data
docker run -d --name app1 -v shared-data:/data app:v1
docker run -d --name app2 -v shared-data:/data app:v2

这样 app1 和 app2 的 /data 目录是同一块存储，任何一边写入，另一边立刻可见。在容器切换（比如旧版本容器往共享目录写数据，新版本容器读数据）时非常方便，不用在容器之间单独搞文件传输。

注意：docker cp 拷贝大量小文件会很慢，而且没有断点续传。如果你需要处理几百兆甚至几 G 的文件，建议直接用 mount 或者先打包再拷贝。docker cp 更像是个快照工具，而不是同步工具。

3.3 USB转串口与容器：设备映射的实操记录

有一个很常见的问题，尤其做嵌入式、物联网开发的朋友会问：Docker 容器跟虚拟 USB 串口有关系吗？答案是：容器默认情况下是看不到宿主机的 USB 设备的，你必须在启动容器时显式地把设备映射进去。

比如宿主机上有一个 USB 转串口设备 /dev/ttyUSB0，你想让容器里的 Python 程序通过它跟单片机通信：

bash复制docker run -it --device=/dev/ttyUSB0:/dev/ttyUSB0 --name serial-test ubuntu:20.04 /bin/bash

--device 参数就是把宿主机设备挂进容器，格式是 宿主机设备:容器设备。进入容器后再查 /dev，你就能看到 ttyUSB0 了。

还有个偷懒但极度危险的用法：加 --privileged 参数让容器获得所有宿主机设备的访问权。这个参数一加，容器就跟宿主机共享所有设备，串口、USB、磁盘全都能看到。我强烈反对在生产环境这么干，安全隐患非常大。正确的做法是精确映射需要的设备。

如果串口在容器启动后才插入宿主机，也可以通过 udev 规则自动绑定，但那个复杂度太高，我一般建议直接重启容器，启动时把设备带上，简单粗暴最省心。

4. 容器资源排查与自我定位

容器切换往往不是无缘无故发生的。很多时候是因为出问题的容器占用资源太高，或者你连自己是不是在容器里跑着都不知道，切换不切换就成了糊涂账。这一节从两个最经典的问题切入。

4.1 Java容器内存飙升的排查思路和实测案例

先说一个我真实处理过的案例。一个 Java 微服务部署在 Docker 容器里，平时占用 400M 左右内存，某天突然飙升到 1.2G，而且持续不降。很多人的第一反应是看 docker stats，但 docker stats 只告诉你容器整体内存用了多少，不会告诉你里面是哪块在涨。

排查的第一步确实是 docker stats，确认容器确实是内存大户：

bash复制docker stats --no-stream

第二步是进容器看进程的详细内存分布：

bash复制docker exec -it app-container /bin/bash
ps aux

如果是 Java 进程，ps aux 的 RSS 列只能看到整体内存，还需要用 JDK 自带工具深入分析。先看堆内存配置和实际堆使用：

bash复制# 先看 JVM 参数，确认堆大小设置
jcmd 1 VM.flags | grep -E "HeapSize|MaxHeapSize"

# 再看当前堆和 GC 情况
jstat -gcutil 1 1000

但真正的坑往往不在堆里。我那次排查到最后，发现飙升的其实是线程数：业务代码在异常情况下疯狂创建新线程，每个线程默认栈大小 1MB，几百个线程叠加，内存自然暴涨。查线程用：

bash复制jstack 1 > thread-dump.txt

然后用 grep 数一下有名线程的数量：

bash复制grep "java.lang.Thread.State" thread-dump.txt | wc -l

这里有一个所有 Java 容器使用者都该知道的现代 JVM 参数：-XX:+UseContainerSupport。这是 JDK 8u191 及之后版本默认启用的。它的作用是让 JVM 感知容器内存限制（Cgroup），而不是去看宿主机物理内存。如果你用旧版 JDK 8，没有这个参数，JVM 默认按宿主机内存的 1/4 设置堆上限。如果宿主机是 64G 内存，容器里 Java 进程的堆上限就有 16G。容器虽然限了 1G，JVM 可能直接起手就分配大块内存，最终 OOM 被系统杀掉还一脸迷茫。

排查 Java 容器内存问题的思路可以归纳为一张速查表：

4.2 如何确定当前进程是不是跑在容器里

这个问题在公司环境里特别常见。你去排查一个线上问题，登上一台机器，结果发现这台机器本身是个容器，再往里套一层容器。如果不先搞清楚当前环境，后面所有操作都可能定位错目标。

最经典的方法有三个。第一个，检查根目录下有没有 /.dockerenv 文件：

bash复制ls -la /.dockerenv

如果看到了这个文件，基本可以确定是在 Docker 容器里。Kubernetes 里的 Pod 运行的本质也是容器，一般也有这个文件。

第二个，查看 /proc/1/cgroup 的内容：

bash复制cat /proc/1/cgroup

如果输出里包含 docker、kubepods、containerd 之类的关键字，说明你就在容器或 Kubernetes Pod 中：

code复制12:perf_event:/docker/23f0b1c...
11:memory:/docker/23f0b1c...

第三个，看根目录的挂载信息：

bash复制cat /proc/self/mountinfo | head -1

容器里的根挂载通常是 overlay，宿主机一般是 ext4/xfs 之类。这套方法同样适用于 Shell 脚本里做环境判断，比如写一个启动脚本，让它在容器环境和非容器环境下走不同的逻辑分支：

bash复制if [ -f /.dockerenv ]; then
  echo "Inside Docker container"
else
  echo "Running on host"
fi

看清楚自己在哪里，再决定切换操作怎么做，这个习惯能省掉大量排查时间。

5. 框架与应用层面的容器切换

如果说前几节是运维视角的容器切换，这一节就是把镜头拉回到应用开发者天天打交道的地方。"容器切换"在 Spring 和 Java 服务端领域有两个非常实际的子场景：一个是 IOC 容器里如何切换 Bean 和运行环境，一个是底层 Servlet 容器怎么换。

5.1 Spring IOC容器中动态切换Bean与运行环境

Spring 的核心是 IOC 容器，对象全交给容器管。日常开发中我们搞"切换"，多半是为了让同一套代码在不同环境（开发、测试、生产）里跑出不同效果。

最常用的手段是 Profile。在配置文件里定义多套环境：

yaml复制# application-dev.yml
server:
  port: 8081
debug: true

# application-prod.yml
server:
  port: 8080
debug: false

启动时通过参数切换：

bash复制java -jar app.jar --spring.profiles.active=dev

或者用环境变量切换：

bash复制SPRING_PROFILES_ACTIVE=prod java -jar app.jar

在容器化部署时，推荐用环境变量方式，因为 Docker Compose 和 Kubernetes 都天然支持环境变量注入，比传 JVM 参数更灵活。

如果需要在同一个环境中切换不同 Bean 实现，比如同一个接口有两个实现类，一个是本地模拟版，一个是远程调用版，可以用 @ConditionalOnProperty 做条件装配：

java复制@Service
@ConditionalOnProperty(name = "service.mode", havingValue = "mock")
public class MockUserService implements UserService {
    // mock 实现
}

@Service
@ConditionalOnProperty(name = "service.mode", havingValue = "remote")
public class RemoteUserService implements UserService {
    // 远程实现
}

切换时只要改配置文件里的 service.mode：

yaml复制service:
  mode: mock

改完重启应用就完成了 Bean 的切换。如果想不重启就切换，那就需要引入配置中心（Nacos、Apollo），配合 @RefreshScope 动态刷新，这个属于更高级的话题，但原理仍然是控制条件判断的开关值。

5.2 换Servlet容器：从Tomcat到Jetty/Undertow

Spring Boot 3 默认内置 Tomcat，但并不是说只能用 Tomcat。有些团队为了内存占用更低、启动更快，会把底层容器从 Tomcat 换成 Jetty 或 Undertow。

以 Maven 为例，切换成 Jetty 只要改 pom.xml：

xml复制<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
    <exclusions>
        <exclusion>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-tomcat</artifactId>
        </exclusion>
    </exclusions>
</dependency>

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-jetty</artifactId>
</dependency>

换成 Undertow 就是引入 spring-boot-starter-undertow，同样是先排除 Tomcat 再引入新依赖。

切换之后要验证几个点：一是你的代码里是否直接用到了 Tomcat 特有的 API（比如 org.apache.catalina），如果有，必须做兼容处理；二是文件上传、WebSocket 等能力在不同 Servlet 容器下的行为有差异；三是生产环境要重新压测，不能只看官方说"性能好"就无脑切。我实测下来，Undertow 在某些高并发场景下内存和响应表现确实不错，但部署到低版本操作系统上偶尔有兼容问题，切换前三思。

5.3 多容器编排与网络切换：bridge和host怎么选

开发框架切完了，回到部署层面，多容器协同部署的切换又是一个大话题。用 Docker Compose 编排多个容器时，最常见的切换是网络模式的切换。

默认是 bridge 网络。Docker 会创建一个虚拟网桥，每个容器分配一个内网 IP，容器之间通过 IP 或服务名互通。比如一个最简单的 docker-compose.yml：

yaml复制services:
  app:
    image: my-app:v1
    ports:
      - "8080:8080"
    networks:
      - my-net
  db:
    image: mysql:8.0
    networks:
      - my-net

networks:
  my-net:
    driver: bridge

在这种模式下，app 容器内部访问 db，可以直接用服务名：

bash复制jdbc:mysql://db:3306/mydb

切换到 host 网络模式，容器直接复用宿主机的网络栈，不经过 NAT 转换，性能损耗低，但隔离性也低，端口没法再映射，直接占用宿主机端口。

yaml复制services:
  app:
    image: my-app:v1
    network_mode: host

什么场景选 host？对网络性能极其敏感的服务（比如某些实时音视频网关）。什么场景不选？多服务需要端口隔离、需要同时存在多个相同端口的容器时，坚决用 bridge。这个取舍在容器切换时可别忘了。

6. 容器化部署中的主备与拓扑切换

现在聊聊架构层面的"切换"。容器化之后，主备切换和拓扑切换的玩法跟以前不一样了，但目标是没变的：让服务在故障时依然可用，让升级时用户无感知。

6.1 版本升级时如何做到平滑切换不中断

以前没有容器化的时候，升级一个应用通常要停服、替换、重启。容器化之后，最典型的切换方式是滚动升级：集群里同时有新旧两个版本的容器实例，逐个替换，保证始终有实例在提供服务。

如果你用的是 Kubernetes，这几乎是内置能力。只需要更新镜像版本，Deployment 会按策略滚动替换：

yaml复制spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1

这意味着升级过程中，最多同时有 1 个旧版本 Pod 不可用，最多额外创建 1 个新版本 Pod。整个切换过程流量不中断，等新的 Pod 健康检查通过后，流量自动切过去，旧的 Pod 才被摘掉。

如果是纯 Docker 环境，没有编排系统，那就只有自己写脚本或者借助 Nginx 反向代理做蓝绿切换。先启动新容器，验证没问题，再改 Nginx 上游把流量切到新容器，最后停旧容器。这也就是最常见的"蓝绿部署"，本质上就是 A 容器到 B 容器的流量切换。

6.2 健康检查与主备切换的落地配置

主备切换的核心不只是"备机起来了"，而是怎么判断主机到底还活着。容器编排里的健康检查就是这个判断器。

以 Docker Compose 为例，可以给服务配置 healthcheck：

yaml复制services:
  app:
    image: my-app:v1
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8080/health"]
      interval: 30s
      timeout: 5s
      retries: 3

这样容器会在启动后每 30 秒探测一次 /health 接口，连续 3 次失败视为不健康。在 Kubernetes 中还有 livenessProbe 和 readinessProbe 两种探针：liveness 管"容器要不要重启"，readiness 管"流量要不要切进来"。

主备切换落地时，我会把"备"这个角色交给另一个资源池的容器，配合负载均衡做双活。严格意义上，容器编排里的"主备"往往不是一台机器停机再唤醒另一台，而是负载均衡发现后端实例不健康，自动把流量切到健康实例上。这个思路下，"切换"不再是一个命令，而是一个连续的自愈闭环。

提示：不要迷信容器化之后的"自动切换"就没问题。我处理过不少容器健康检查误报导致的流量反复切换故障。健康检查的阈值设得太敏感，一个短暂 GC 停顿就能让探针失败，然后流量切走，切走后 GC 恢复，流量又切回来，整个过程用户感受到的就是不停的超时。设置健康检查前，先结合应用的自身延迟分布评估合理阈值。

7. 容器安全与高频问题速查

最后这块，我想重点说说安全。因为容器切换越频繁，安全风险就越容易被暴露出来。很多团队对切换得心应手，但对镜像和容器的安全防护完全没有概念，一旦出事就是大面积事故。

7.1 镜像安全与容器安全的基本功

镜像安全的核心是两条：一是基础镜像漏洞要少，二是镜像内容要"干净"。基础镜像我推荐用 alpine 或者 distroless，体积小、攻击面小。同时要养成定期扫描镜像的习惯，像 Trivy 这样的工具可以直接扫描本地镜像：

bash复制trivy image nginx:1.25

扫出来高危漏洞，就要重新打标签和替换。现在很多镜像仓库都有自动扫描能力，一定要把扫描集成到发布流程里，而不是靠人肉记忆。

容器安全的核心是最小权限原则。启动容器时，默认是 root 的，一旦容器被入侵，攻击者拿到的就是 root 权限。至少要做到三点：第一，镜像里用 USER 指令切换到非 root 用户运行；第二，运行容器时尽可能 drop 掉不必要的 Linux capabilities：

bash复制docker run --cap-drop=ALL --cap-add=NET_BIND_SERVICE my-app:v1

第三，不要给容器挂载 docker.sock。这个文件是 Docker 的"管理入口"，挂给容器等于把管理员权限直接交给容器里的进程，很多容器逃逸攻击就是打这个主意。

安全防护方向的容器化部署也在大量落地。比如蜜罐 HFish 就提供 Docker 镜像，蜜罐节点需要快速上下线、随时切换，容器天然的隔离和可移植性刚好匹配。把蜜罐部署成容器，一方面隔离攻击流量，另一方面可以快速复制多个蜜罐节点形成拓扑诱捕。

7.2 高频问题速查表

把前面几节涉及的典型问题整理成速查表，方便你直接照着排查：

最后再分享一个我在实际切换容器时养成的小习惯：每次切换前先 docker inspect 看一眼容器的挂载、网络、环境变量，把这些关键信息记录下来，切换完再对比一次。容器这个东西太容易"看似一样、实则不同"了，两个容器表面跑的是同一个镜像，但挂载的目录、注入的环境变量差一点点，行为就能差出十万八千里。把"切换前检查清单"写在笔记里，后面能省下大量脑细胞。