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

第一次部署应用的人，大多都踩过同一个坑：在自己的电脑上跑得好好的程序，到了测试服务器或者生产服务器上，却怎么都跑不起来。少一个依赖库、配置文件路径不对、操作系统版本不同、运行环境的版本不一致……这类问题统称为“环境不一致”。开发、测试、运维每个人手里的环境都不一样，出了问题常常要花几个小时甚至几天去排查，最后发现只是某个小版本差了一位。

部署麻烦是另一个痛点。传统方式上线一个新服务，要先准备服务器、装系统、装运行环境、装依赖、改配置、启动服务，换一台机器就要重来一遍，服务一多就越来越难管。

容器要解决的，正是这两个问题：把应用和它运行所需的环境打包在一起，让它在哪里跑都是一样的，并且让部署变成一个可重复、可回滚的简单动作。

一、容器与虚拟机有什么区别

虚拟机和容器都会做“隔离”，但隔离的层次不同。虚拟机是在宿主机上用 Hypervisor 虚拟出一整台计算机，包括虚拟的 CPU、内存、硬盘和完整的操作系统，每个虚拟机都要跑一个自己的内核，启动慢、占资源多。

容器则共享宿主机的操作系统内核，只隔离应用运行所需的进程、文件系统和网络。容器里没有完整的操作系统，只装应用和依赖，所以启动只需要几秒，占用资源也少得多。

可以这样理解：虚拟机是“一台机器里再装几台电脑”，容器是“一台电脑上用隔间把应用分开”。两者不是谁取代谁，而是用在不同的地方。

二、镜像、容器、仓库：三个核心概念

理解容器，先搞清三个词。

镜像（Image）是容器的“模板”，是一个只读的文件包，里面装着应用代码、运行环境和依赖。镜像分层存储，每一层记录一次修改。

容器（Container）是镜像运行起来的实例。启动一个镜像，就得到一个容器。和镜像不同，容器是可读写的，程序在容器里运行时产生的变化都写在容器层里。

仓库（Registry）是存放镜像的地方，类似代码仓库。镜像推送到仓库后，别的机器拉取同一个镜像，跑出来的环境就完全一致。

三者关系是一条线：写好 Dockerfile 构建出镜像，把镜像推到仓库，需要时从仓库拉取镜像、启动成容器。

三、一条 docker run 的完整流程

以运行一个 Nginx 为例：

docker run -d -p 8080:80 --name my-nginx nginx

这条命令背后发生了这些事：Docker 先检查本地有没有 nginx 镜像，没有就去仓库拉取；再根据镜像创建容器实例，分配文件系统和网络；-d 让容器后台运行，-p 8080:80 把容器内的 80 端口映射到宿主机 8080 端口，--name 给容器起个名字；最后启动 Nginx，访问 http://localhost:8080 就能看到欢迎页。

一条命令就完成了拉镜像、建容器、配端口、启动服务，这就是容器让部署变简单的原因。

四、新手三个注意事项

第一，分清镜像和容器的生命周期。删除容器不会删除镜像，删除镜像前要先停掉并删除依赖它的容器。容器里的数据默认随容器删除而消失，重要数据要用数据卷挂载到宿主机上持久化。

第二，别在容器里手工改配置当成习惯。需要改环境就改 Dockerfile 重新构建镜像，保持“镜像即环境”的一致性，不然时间一长又回到了环境不一致的老问题。

第三，注意端口和资源。-p 映射的宿主机端口不能冲突，生产上要给容器设置好内存和 CPU 限制，避免某个容器把整台机器的资源吃光。

容器不是什么魔法，它只是把“环境”做得更确定、更可重复。理解了镜像、容器和仓库，亲手跑通一条 docker run，容器的大门就算真正推开了。