Docker ：生产环境容器操作实训【docker （三）】
目录
任务 1.1：用 nginx 镜像创建并启动容器（后台运行）
任务 2.1：使用 docker create 创建容器（默认停止）
1：误删运行中的核心业务容器，导致服务不可用且可能丢失未持久化数据
2：镜像被全量删除，导致服务无法快速重建 / 回滚，恢复成本极高
场景一：bridge 模式（默认模式）——Web 服务对外发布
场景三：container 模式——紧密耦合服务（Sidecar）
场景四：自定义 bridge 网络——多容器系统与固定 IP
作业背景（场景）
你是某公司运维/DevOps 实习生。现在需要在一台 Linux 服务器上完成Web 服务上线、巡检、排障、数据传递、迁移备份、下线清理等生产常见流程。要求你使用 Docker 完成对应操作并提交证据。
统一要求：实验过程全程使用命令行完成（浏览器验证可作为补充截图）。
一、作业目标
要求：
-
容器操作：创建 / 启动 / 停止 / 查看
-
docker run 创建+启动合并，并且后台持续运行
-
容器交互：
docker exec -it -
文件复制：
docker cp（主机→容器、容器→主机） -
容器迁移：
docker export/docker import -
下线清理：删除容器、批量停止、删除所有容器、批量删除镜像
-
（加分）网络：bridge/host/container/none、自定义网络、端口映射
二、任务清单（按场景完成）
场景 1：上线发布（创建+启动合并，后台运行）
任务 1.1：用 nginx 镜像创建并启动容器（后台运行）
要求：
-
容器名：
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
提交证据：
-
docker ps -a输出（状态为 Created）
任务 2.2：启动该容器并查看状态
提交证据：
-
docker start <容器ID或名称>命令
-
docker ps -a输出（状态为 Up 或 Exited 需解释原因）
原因
答：
Docker容器的生命周期完全依赖于其内部的主进程（PID 1）：
-
当主进程持续运行时，容器状态为UP
-
当主进程终止（正常/异常退出）时，Docker会立即将容器状态标记为Exited，并记录退出码（Exited（N） N为退出码）
任务 2.3：停止容器
提交证据：
-
docker stop <容器ID或名称> -
docker ps -a输出（状态为 Exited）
提示：如果 nginx 容器用 /bin/bash 作为 PID1，有时会退出，要写明原因：PID=1 进程退出 → 容器退出。
答：
-
/bin/bash 的运行特性：
/bin/bash是交互式 Shell，它的默认行为是：-
如果没有关联终端（
-it参数）、也没有前台任务需要执行，/bin/bash会在启动后立即退出（因为没有持续运行的 “理由”）； -
即使加了
-it关联终端，只要你手动退出 bash（输入exit或关闭终端），这个 PID 1 的 bash 进程就会终止，容器也会随之退出。
-
-
对比正常 nginx 容器的 PID 1：官方 nginx 镜像的 PID 1 进程是
nginx -g "daemon off;"（强制 nginx 前台运行），这个进程会持续监听端口、处理请求，不会主动退出，因此容器能稳定保持UP状态；
场景 3：排障进入容器（容器交互）
任务 3.1：进入 web-prod-01 容器执行命令
要求进入容器执行：
-
ls -
cat /etc/os-release（若镜像无该文件，可换uname -a）
提交证据：
-
docker exec -it web-prod-01 /bin/sh或/bin/bash过程截图（含命令与输出）
说明：退出容器后容器仍在运行（给出 docker ps）
场景 4：文件复制（主机↔容器）
任务 4.1：把宿主机文件复制到容器
要求：
-
在宿主机创建文件
~/test.txt，内容为号码+姓名（例：2025xxx 张三） -
复制到容器
/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
提交证据：
-
docker cp web-prod-01:/opt/test.txt ~/abc123.txt -
cat ~/abc123.txt
场景 5：容器迁移（导出与导入）
任务 5.1：导出容器为 tar 包
要求：
-
导出
web-prod-01为web-prod-01.tar
提交证据：
-
docker export web-prod-01 > web-prod-01.tar -
ls -lh web-prod-01.tar
任务 5.2：导入 tar 包生成新镜像
要求：
-
镜像名：
web-import:test
提交证据：
-
cat web-prod-01.tar | docker import - web-import:test -
docker images | grep web-import
说明题（必答）：
export/import和save/load有什么区别？（写 3 句话以内）
save/load 操作镜像（含历史层、可打包多镜像）
export/import 操作容器快照（无历史层、仅单容器）；
import 会丢失镜像元数据，load 则完整保留。
场景 6：下线与清理（删除与批量删除）
任务 6.1：删除指定容器
要求：
-
停止并删除
web-prod-01
提交证据：
-
docker stop web-prod-01 -
docker rm web-prod-01 -
docker ps -a | grep web-prod-01（无输出或说明不存在）
任务 6.2：批量停止所有容器（两种方式任选其一）
任选提交一种：
-
docker stop $(docker ps -q) -
docker ps -a | awk ... | xargs docker stop
提交证据：命令 + 执行后 docker ps
任务 6.3：删除所有容器
任选提交一种：
-
docker rm -f $(docker ps -aq) -
docker ps -a | awk ... | xargs docker rm
提交证据：命令 + docker ps -a（结果为空）
任务 6.4：批量删除镜像（两种方式任选其一）
任选提交一种：
-
删除所有镜像：
docker rmi -f $(docker images -q) -
只删除 none 镜像：
docker images | grep none | ...
提交证据：命令 + docker images（展示删除结果）
安全说明（必答）： 为什么生产环境不建议直接执行“删除所有容器/镜像”？写出 2 点原因。
1：误删运行中的核心业务容器，导致服务不可用且可能丢失未持久化数据
生产环境中，容器承载着核心业务（如订单系统、支付服务、用户中台）、中间件（如 Redis、Kafka、MySQL）等关键组件，直接执行 “删除所有容器” 会：
-
无差别终止 / 删除容器：不管容器是否在运行、是否承载核心业务，都会被强制停止并删除，导致业务服务瞬间中断，引发生产事故（如用户无法下单、支付失败）；
-
丢失未持久化数据：容器是 “无状态” 的，但实际运行中可能存在未及时持久化到外部存储的临时数据（如容器内的业务日志、缓存数据、临时计算结果），容器被删除后这些数据会永久丢失，甚至可能导致数据一致性问题（如交易记录缺失）。
2：镜像被全量删除，导致服务无法快速重建 / 回滚，恢复成本极高
生产环境的镜像包含不同版本的业务程序（如线上稳定版本、灰度测试版本、应急回滚版本），直接删除所有镜像会：
-
服务重建无镜像可用：当节点故障、业务需要扩缩容，或容器意外退出需要重启时，因缺失镜像无法快速重建容器，导致服务长时间不可用；
-
不可逆的镜像丢失风险：部分自定义镜像（如基于基础镜像封装了业务配置、依赖的镜像）若未同步到私有镜像仓库，本地全量删除后无法找回；即使有仓库，重新拉取镜像也会消耗大量网络资源、延长恢复时间，进一步扩大故障影响范围。
三、网络部分
Docker 网络模式场景化作业
-
环境：单台 Linux 主机（物理机/虚拟机均可）
-
镜像建议：
nginx、centos:7 -
禁止使用
--network none -
每个场景必须执行命令并给出验证结果
场景一：bridge 模式（默认模式）——Web 服务对外发布
场景背景（生产化）
公司在一台服务器上部署多个 Web 服务，需要：
-
容器之间相互隔离
-
对外通过端口映射提供服务
这是最常见的生产 Docker 网络模式。
任务
任务 1.1：使用 bridge 模式运行 nginx
任务 1.2：查看容器 IP
任务 1.3：访问服务
-
浏览器访问：
http://宿主机IP:8080 -
或命令：
验证要求
-
docker ps中能看到端口映射 -
能通过宿主机端口访问容器服务
-
容器拥有独立 IP
思考题（必答）
1️⃣ 为什么外部不能直接访问容器 IP？
容器 IP 是宿主机内的 “私有内网地址”，外部网络无路由可达，且存在严格的网络隔离：
容器 IP 的网段属性：仅宿主机本地可见
网络隔离机制：虚拟网桥的隔离性
2️⃣ bridge 模式下端口映射的作用是什么？
通宿主机外网端口与容器内网端口的转发通道
场景二：host 模式——高性能服务部署
场景背景（生产化）
公司部署一个高性能 Web 服务/监控服务：
-
对网络性能敏感
-
不希望端口映射带来额外开销
因此直接让容器使用宿主机网络。
任务
任务 2.1：使用 host 网络模式启动 nginx
任务 2.2：查看网络信息
验证要求
-
访问方式：
http://宿主机IP:80 -
不需要
-p参数 -
容器内看到的 IP 信息与宿主机一致
1️⃣ host 模式下，容器有没有独立 IP？
容器与宿主机共享网络环境，不具备独立的IP和网卡 ，而是使用宿主机的IP和端口
2️⃣ host 模式适合什么类型的应用？
对网络性能要求极致（低延迟、高并发）的应用
需要使用大量端口 / 动态端口的应用
依赖宿主机网络配置 / 需直接访问宿主机网络资源的应用
3️⃣ host 模式的安全风险是什么？
容易把宿主机IP地址给暴露，容易有被攻击的风险
场景三：container 模式——紧密耦合服务（Sidecar）
场景背景（生产化）
某系统由两个组件组成：
-
主服务（Service）
-
辅助服务（日志/监控/代理）
要求：
-
两个容器共享网络
-
使用
localhost通信
任务
任务 3.1：启动主容器
任务 3.2：查看主容器网络命名空间
任务 3.3：启动共享网络的辅助容器
任务 3.4：对比两个容器的网络
验证要求
-
两个容器 IP 完全一致
-
网络命名空间相同
-
可通过
localhost通信
相互IP ping通
思考题（必答）
1️⃣ container 模式与 host 模式的区别？
host模式是容器直接借用宿主机的IP，container模式则与指定的容器共享network命令空间
2️⃣ 为什么称这种模式为 Sidecar（边车模式）？
辅助容器与主容器绑定、共享资源、提供辅助功能
场景四：自定义 bridge 网络——多容器系统与固定 IP
场景背景（生产化）
公司部署一个多服务系统：
-
Web + App + DB
-
需要：
-
容器间直连
-
可指定 IP
-
网络与其他项目隔离
-
任务
任务 4.1：创建自定义网络
任务 4.2：在自定义网络中启动容器
任务 4.3：容器间通信测试
验证要求
-
自定义网络出现在
docker network ls -
容器 IP 为指定值
-
容器间可直接通信
思考题（必答）
1️⃣ 为什么默认 bridge 不能指定 IP？
Docker 对默认 bridge 网络的定位是 “快速测试、易用优先”，刻意简化了配置逻辑，限制了 “固定 IP” 等高级功能
2️⃣ 自定义网络适合什么场景？
1. 多业务网络隔离（核心场景）
2. 需要固定 IP 的场景
3. 适配企业网络规划
4. 安全隔离需求
3️⃣ Docker 如何实现容器间二层通信？
更多推荐
46
0- 0
已为社区贡献11条内容
所有评论(0)