Docker简介：从“我机器上能跑”到“哪儿都能跑”
大家好，我是这门课的老工程讲师。今天咱们聊聊Docker。
说白了，Docker就是一个打包、分发、运行应用的“集装箱”。它解决了软件工程里一个老大难问题——“在我机器上能跑啊！”但换个环境，就崩了。
我刚开始带团队时，最怕听到这句话。环境不一致、依赖冲突、配置丢失…每次部署都像开盲盒。后来我遇到了Docker，嗯，这感觉就像从手工打包杂货摊，升级到了标准化的物流中心。
一句话总结：Docker把应用和它需要的所有环境（代码、运行时、系统工具、库、配置）打包成一个标准化的单元——容器。这个容器能在任何安装了Docker引擎的机器上运行。
Docker发展史：一个少年天才的崛起
我习惯把Docker的发展史分成三个阶段来看，这样脉络更清晰。
2013年，Docker项目刚开源时，我第一时间就关注了。当时我正被一个Java项目的部署折磨得死去活来——测试环境跑得好好的，一到生产环境就报ClassNotFoundException。我记得那时候虚拟机（VM）还是主流，但太重了，启动慢得像蜗牛。Docker的轻量级容器概念，简直是一股清流。
| 年份 | 关键事件 | 我的感受 |
|---|---|---|
| 2013 | Docker开源，基于LXC | 眼前一亮，但社区太小 |
| 2014 | 发布Docker 1.0，开始支持Windows | 开始用到生产环境，踩了不少坑 |
| 2015 | OCI（开放容器倡议）成立 | 标准化是好事，但江湖开始分裂 |
| 2017 | Moby项目拆分，Docker Enterprise发布 | 企业版确实稳，但社区版更灵活 |
| 2019至今 | Docker Desktop、Compose V2、生态成熟 | 开发与部署彻底统一，已成标配 |
为什么Docker能火？我常跟团队说：因为它抓住了“环境一致”这个核心痛点。你想想看，以前部署一个Web应用，要手动安装JDK、Tomcat、配置数据库…现在一个Dockerfile就搞定所有。这难道不是工程师的终极梦想吗？
Docker应用场景：它到底能帮我们干什么？
在实际项目中，Docker的应用场景非常广。我根据自己的经验，总结了几个最常见的方向：
- 开发环境标准化：团队新成员加入，以前要花半天装环境。现在跑个
docker compose up -d，三分钟就拉起全套开发环境。我曾在两个项目组之间迁移，靠一个Docker Compose文件，半天就搞定了所有成员的开发环境切换。 - 持续集成/持续部署（CI/CD）：这是Docker最核心的生产力场景。代码提交后，自动构建镜像，自动测试，自动部署。我之前带的一个AI团队，就是靠Docker把模型训练、测试、部署流程完全自动化，省去了大量人工干预。
- 微服务架构：每个服务一个容器，独立部署、独立扩展。我最近重构的一个电商系统，把原本块状应用拆成了十几个微服务容器，哪个服务压力大，就单独扩容哪个，资源利用率直接翻倍。
- 混合云/多云部署：镜像可以在任何Kubernetes或Docker Swarm集群上跑。我有个客户，白天把计算密集型任务放在本地私有云，晚上流量低了，自动迁移到公有云跑批处理。这种弹性，没有容器的话，几乎不可能实现。
- 大数据与AI：Jupyter Notebook、TensorFlow、PyTorch这些，用Docker打包后，省去了复杂的CUDA和Python环境配置。我自己就经常用
nvidia-docker跑GPU训练，环境隔离做得非常好。
我的一个小建议：如果你刚开始接触Docker，先从开发环境标准化场景入手。用Docker Compose把你的本地开发环境（比如一个Nginx+PHP+MySQL的组合）打包起来。能跑通了，再考虑CI/CD和微服务。
Docker核心架构与组件：拆开看看里面长什么样
Docker不是单块软件，它是个精巧的架构。我习惯用“客户端-服务器模型”来理解它。你看下面这张图，很直观。
看这张图，Docker的核心组件就四个：客户端、守护进程、镜像仓库、容器。它们的关系非常清晰——客户端就是命令终端，守护进程是真正的“干活的”，镜像仓库是“仓库”，容器就是最终的产物。
核心组件详解：别光记概念，要理解它们怎么协作
1. Docker客户端（Docker CLI）
这是我用得最多的工具。你我在终端里敲的 docker pull 、 docker run，都是发往守护进程的命令。嗯，这里要注意：客户端在哪不重要，只要能通过网络访问到守护进程的Socket就行。
一个实用技巧：你可以通过设置 DOCKER_HOST 环境变量，让本地客户端直接操作远程服务器的Docker守护进程，这在排障时非常好用。
export DOCKER_HOST=tcp://192.168.1.100:2375
docker ps # 这个命令会列出远程服务器的容器2. Docker守护进程（dockerd）
这是Docker的心脏。它一直在后台跑，监听REST API请求。我个人习惯用 systemctl status docker 检查它的状态。我记得有一次生产环境容器启动慢，排查下来发现是守护进程的日志级别调到了debug，产生了海量I/O，改了配置后立刻恢复。
3. Docker镜像仓库（Registry）
你可以把镜像仓库想象成GitHub，不过它存的是容器镜像。Docker Hub是最常用的公共仓库，但企业内部一般用Harbor或Nexus搭建私有仓库。我之前在某金融公司，就强制要求所有镜像必须从私有仓库拉取，杜绝了“来历不明”的镜像风险。
避坑指南：千万不要在生产环境直接用Docker Hub的 latest 标签！我遇到过太多次了——昨天的 nginx:latest 能跑，今天换了个基础镜像版本，应用直接挂了。请始终使用精确版本标签，比如 nginx:1.25.3 。
4. Docker容器
这就是你最终想要的东西——一个运行中的实例。它是轻量级的，共享宿主机内核，所以启动几乎是瞬间的。我曾经做过一个对比测试：启动一个Ubuntu容器只需要0.3秒，而启动一个Ubuntu虚拟机需要40秒。这就是为什么容器在微服务和CI/CD场景中如此受欢迎的原因。
一次完整的Docker操作流程：从拉取到运行
讲再多理论，不如看个实际例子。下面是一个标准的Docker操作流程，大家跟着感受一下：
- 搜索镜像
docker search nginx- 拉取镜像
docker pull nginx:1.25.3- 查看本地镜像
docker images- 运行一个容器
docker run -d --name my-nginx -p 8080:80 nginx:1.25.3- 查看运行中的容器
docker ps- 访问测试
curl localhost:8080- 停止并删除容器
docker stop my-nginx
docker rm my-nginx看到没？就这么简单。一个Nginx服务从拉取到运行，只花了不到10秒。这在没有Docker的世界里，你得手动配置、编译、启动进程…至少得几分钟。
讲到这里，第一章的核心内容就差不多了。记住这三个关键词：镜像（只读模板）、容器（可写实例）、仓库（存储分发）。下次当你听到Docker，脑子里先浮现出这张架构图，心里默念这三个概念。别小看它，这是后面所有高级操作（Docker Compose、Swarm、Kubernetes）的基石。