Docker 入门：容器到底解决什么问题

很多同学第一次听到 Docker，会把它理解成“又一台虚拟机”。其实容器要解决的，是环境不一致和交付太慢这两件更具体的事。

同一份代码，在自己电脑上能跑，换到同事机器或云上的测试环境，就可能缺依赖、版本不对、路径不一样。传统做法是写一长串安装说明，靠人逐步执行，既慢又容易漏步骤。容器把应用和它依赖的运行时、系统库、启动配置打成一份镜像。换一台机器，只要装了容器引擎，启动命令几乎可以保持一致。这就是日常所说的“一次构建，到处运行”：减少环境差异，而不是把整台操作系统再搬一遍。

和虚拟机相比，容器共享宿主机内核，不必为每个应用再模拟一套完整系统，所以启动常常是秒级，资源占用也更小。放到云上，这个特点很实用。做弹性伸缩时，新实例可以很快拉起同一份服务；出了问题，把镜像切回上一版，往往比登录机器逐项改配置更可控。开发、测试和生产尽量使用同一份镜像，故障也更容易复现。

入门只要记住四个词。镜像是只读模板；容器是镜像运行起来的实例，有自己的进程、网络和一层可写空间；Dockerfile 用文本描述如何构建镜像，适合放进代码仓库一起评审；镜像仓库负责存放和分发，团队不用互相传压缩包。刚开始不必上编排，先把一个简单的 Web 服务打成镜像，在本地跑通，再考虑放到云上的容器服务里。

使用时也要守住边界。容器并不是全部的安全隔离，密钥和口令不要写进镜像层；业务数据应放在卷或外部存储，删除容器不等于做了备份。镜像标签尽量写明版本，少用含糊的 latest，避免一次自动更新把线上行为悄悄改掉。日志和健康检查尽早接上，出问题才知道该看哪一层。

先把“容器是在打包运行环境，而不是再造一台电脑”这件事想清楚，后面学网络、存储和编排会顺很多。今天用一个小服务练一遍构建和启动，比收藏十篇概念文更有用。

再补一个容易忽略的点：容器适合把“进程”当作交付单元。一个容器里尽量只跑一个主进程，日志打到标准输出，由平台收集，而不是在容器里再塞一套定时任务和监控代理。这样扩容时复制的是清晰的一份职责，排障时也不会在同一层里翻出三套互相影响的服务。云上的负载均衡、健康检查和滚动发布，都默认你的实例可以被随时替换，所以应用本身要能接受重启，会话和文件别只留在容器内部。想通这一点，容器就从“新奇的打包格式”变成日常发布流程的一部分。