“为什么我的电脑上能跑，换到服务器上就跑不了了？”

相信不少人都遇到过这个问题。

程序本身可能没问题，但换一台机器之后，Python 版本不一样、Node.js 版本不一样、缺少系统依赖，甚至连环境变量都不一样。

于是我们经常会看到这样的部署过程：

安装运行环境
↓
安装各种依赖
↓
修改配置
↓
上传代码
↓
启动程序
↓
发现报错
↓
继续补依赖

Docker 解决的，正是这类问题。

Docker 是什么？

简单来说，Docker 可以把应用程序以及它运行所需要的一部分环境打包起来，然后以容器的形式运行。

例如一个 Node.js 项目：

Node.js
npm 依赖
项目代码
配置
启动命令

都可以通过 Docker 统一管理。

这样换到另一台安装了 Docker 的服务器之后，就不需要重新手动搭建一遍环境。

Docker 和虚拟机有什么区别？

很多刚接触 Docker 的人都会把 Docker 和虚拟机放在一起比较。

虚拟机更像是：

物理服务器
└── 虚拟机
    └── 完整操作系统
        └── 应用

而容器通常是：

物理服务器
└── 操作系统
    └── Docker
        └── Container
            └── 应用

容器共享宿主机的 Linux 内核，因此通常比完整虚拟机更加轻量，启动速度也很快。

但需要注意：

Docker 容器并不是一个“更小的虚拟机”。

两者的隔离机制和底层实现并不一样。

三个概念先记住

Docker 里面最常见的三个概念：

Image

镜像。

可以把它理解成一个应用运行环境的模板。

Container

容器。

镜像启动之后，就产生了一个正在运行的容器。

可以简单理解：

Image
  ↓ docker run
Container

Registry

镜像仓库。

负责存储和分发 Docker 镜像。

最常见的就是 Docker Hub。

跑第一个容器

安装好 Docker 后，可以直接执行：

docker run hello-world

如果本地没有 hello-world 镜像，Docker 会先把它拉下来，然后创建并启动容器。

第一次看到这个流程时，可能会觉得：

“这不就是下载了个程序然后运行吗？”

其实这背后已经包含了 Docker 最核心的一套机制：

Registry
   ↓
Image
   ↓
Container
   ↓
Process

Docker 真正解决的问题

Docker 最有价值的地方，其实不是让命令少打几个。

它真正解决的是：

环境标准化。

以前部署一个应用可能需要：

服务器
├── Java
├── Node.js
├── Python
├── 系统依赖
├── 配置文件
└── 应用程序

Docker 化之后，可以变成：

服务器
└── Docker
    └── 应用容器

这也是为什么 Docker 会成为现代开发和部署环境中非常常见的一项技术。

下一篇，我们开始真正研究 Docker 的核心——镜像。