场景 1：上线发布（创建+启动合并，后台运行）

要求：

• 容器名：web-prod-01

• 端口映射：宿主机 43000 映射容器 80

• 后台运行：必须使用 -d

提交证据：

• docker ps 输出（能看到端口映射）

• 浏览器访问 http://宿主机IP:43000 的截图（或 curl 输出

• 

场景 2：基础操作（创建、启动、停止、查看）

任务 2.1：使用 docker create 创建容器（默认停止）

要求：

• 使用 docker create -it nginx:latest /bin/bash（或按你环境可用镜像）

• 证明容器状态是 Created

任务 2.2：启动该容器并查看状态

任务 2.3：停止容器

场景 3：排障进入容器（容器交互）

任务 3.1：进入 web-prod-01 容器执行命令

要求进入容器执行：

• ls

• cat /etc/os-release（若镜像无该文件，可换 uname -a）

场景 4：文件复制（主机↔容器）

任务 4.1：把宿主机文件复制到容器

要求：

1. 在宿主机创建文件 ~/test.txt，内容为学号+姓名（例：2025xxx 张三）

2. 复制到容器 /opt/ 目录

提交证据：

• 宿主机：cat ~/test.txt

• docker cp ~/test.txt web-prod-01:/opt/

• 容器内验证：cat /opt/test.txt（用 exec 进入或直接 exec 执行）

任务 4.2：从容器复制回宿主机

要求：

• 从容器复制 /opt/test.txt 到宿主机 ~/abc123.txt

场景 5：容器迁移（导出与导入）

任务 5.1：导出容器为 tar 包

要求：

• 导出 web-prod-01 为 web-prod-01.tar

任务 5.2：导入 tar 包生成新镜像

要求：

• 镜像名：web-import:test

save/load 操作镜像，export/import操作容器

场景 6：下线与清理（删除与批量删除）

任务 6.1：删除指定容器

要求：

• 停止并删除 web-prod-01

任务 6.2：批量停止所有容器（两种方式任选其一）

docker stop $(docker ps -q)

任务 6.3：删除所有容器

docker rm -f $(docker ps -aq)

任务 6.4：批量删除镜像（两种方式任选其一）

删除所有镜像：docker rmi -f $(docker images -q)

为什么生产环境不建议直接执行“删除所有容器/镜像”：1.会导致数据的丢失，2.在实际工作中会导致前后端的业务停掉。

三、网络部分

Docker 网络模式场景化作业

场景一：bridge 模式（默认模式）——Web 服务对外发布

学生任务

任务 1.1：使用 bridge 模式运行 nginx

任务 1.2：查看容器 IP

任务 1.3：访问服务

• 浏览器访问：http://宿主机IP:8080

验证要求

• docker ps` 中能看到端口映射

• 能通过宿主机端口访问容器服务

• 容器拥有独立 IP

1.为什么外部不能直接访问容器 IP？

  容器 IP 是 Docker 默认桥接网络（docker0）的内网 IP，仅宿主机可直接访问；外部主机与容器不在同一网络段。

2.bridge 模式下端口映射的作用是什么？

   实现外部访问：将宿主机端口与容器端口绑定，外部可通过「宿主机 IP + 映射端口」访问容器服务；② 端口隔离：多个容器可映射不同宿主机端口（如 8080/8081），避免端口冲突；③ 网络隔离：容器仍保持独立网络命名空间，仅开放映射端口对外，降低安全风险。

场景二：host 模式——高性能服务部署

场景背景（生产化）

公司部署一个高性能 Web 服务/监控服务：

• 对网络性能敏感

• 不希望端口映射带来额外开销

因此直接让容器使用宿主机网络。

学生任务

任务 2.1：使用 host 网络模式启动 nginx

任务 2.2：查看网络信息

验证要求

• 访问方式：http://宿主机IP:80

• 不需要 -p 参数

• 容器内看到的 IP 信息与宿主机一致

1.host 模式下，容器有没有独立 IP？

没有。host 模式下容器共享宿主机的网络命名空间，不创建独立的网络栈，直接使用宿主机的 IP 和端口，因此无独立 IP。

2.host 模式适合什么类型的应用？

适合对网络性能要求极高、低延迟的应用（如监控采集器、高吞吐 API 服务、网络抓包工具），或需要直接访问宿主机本地网络资源的场景。

3.host 模式的安全风险是什么？

① 无网络隔离：容器可直接访问宿主机所有网络接口和端口，易突破容器隔离边界；② 端口冲突：容器端口与宿主机端口直接共用，易引发端口占用问题；③ 权限过高：容器内进程的网络权限等同于宿主机进程，若容器被入侵，攻击者可直接渗透宿主机网络。

场景三：container 模式——紧密耦合服务（Sidecar）

场景背景（生产化）

某系统由两个组件组成：

• 主服务（Service）

• 辅助服务（日志/监控/代理）

要求：

• 两个容器共享网络

• 使用 localhost 通信

---

学生任务

任务 3.1：启动主容器

任务 3.2：查看主容器网络命名空间

任务 3.3：启动共享网络的辅助容器

任务 3.4：对比两个容器的网络

验证要求

• 两个容器 IP 完全一致

• 网络命名空间相同

• 可通过 localhost 通信

     

 

     

1. container 模式与 host 模式的区别？container 模式共享「指定容器」的网络命名空间，仅与该容器共用网络；host 模式共享「宿主机」的网络命名空间，与宿主机所有进程共用网络。
2. 为什么称这种模式为 Sidecar（边车模式）？辅助容器像摩托车的 “边车” 一样依附主容器，共享主容器的网络（及资源），不独立对外提供服务，仅为核心主容器提供辅助能力（如日志收集、流量监控、代理转发），因此得名 Sidecar 模式。  

场景四：自定义 bridge 网络——多容器系统与固定 IP

场景背景（生产化）

公司部署一个多服务系统：

• Web + App + DB

• 需要：

  • 容器间直连

  • 可指定 IP

  • 网络与其他项目隔离 

学生任务

任务 4.1：创建自定义网络

任务 4.2：在自定义网络中启动容器

任务 4.3：容器间通信测试

验证要求

• 自定义网络出现在 docker network ls

• 容器 IP 为指定值

• 容器间可直接通信

1. 为什么默认 bridge 不能指定 IP？默认 bridge 网络（docker0）是 Docker 自动创建的，仅提供动态 IP 分配（内置 DHCP），未开放手动指定 IP 的配置入口；设计上侧重 “开箱即用” 的通用性，而非定制化，且无子网 / IP 段自定义能力，无法固定 IP。
2. 自定义网络适合什么场景？适合多服务组成的业务系统（如 Web+App+DB）、需要容器间固定 IP 直连、不同项目网络隔离（避免 IP / 端口冲突）、对网络定制化要求高的场景（如指定子网、网关、IP 范围）。
3. Docker 如何实现容器间二层通信？Docker 通过「虚拟网桥（bridge）+ veth pair（虚拟网卡对）」实现二层通信：① 每个容器创建时生成一对 veth 网卡，一端（vethxxx）挂载到 Docker 网桥（如自定义 bridge），另一端（eth0）放入容器网络命名空间；② 网桥作为二层交换机，维护 MAC 地址转发表，转发容器间的以太网帧；③ 容器的 MAC 地址由 Docker 分配，网桥通过 MAC 地址学习实现容器间数据链路层的直接通信，无需路由转发。