在我电脑上是好的
软件行业有一句最古老的话：在我电脑上是好的。
以前的部署很简单。把自己电脑上做好的文件原样传到服务器，别人就能看到了。但这种做法有一个沉默的前提：自己的机器和服务器是同一个环境。
实际上并不同。操作系统不同，或者系统相同但版本不同，或者已装工具的版本不同。第一次上传时对齐过，时间一长也会走偏。代码一样而地基不同，于是这边行那边不行。
而且难修，因为怎么盯着代码看都没用，问题根本不在代码里。
所以把地基一起搬走
想法很简单。既然是环境不同造成的问题，那就把环境一起搬过去。
不只搬程序，而是把它运行所在的地基一并取下来，封成一个包。在什么操作系统上、和哪些工具的哪个版本一起跑着，全都装进这个包里。
这个包叫镜像，把镜像跑起来的状态叫容器。这一整套做法就是 Docker。
这样部署就变了。不再一个个上传文件去覆盖，而是整个换掉容器。起新包，撤旧包。出问题就把旧包再起回来。
从前 我的代码 ──────────────────▶ 服务器
（服务器的环境是服务器的事）
现在 我的代码 + 它运行的环境 ──▶ 镜像 ──▶ 在服务器上以容器运行
（地基一样，这边行那边就行）不只是搬运时才用
有人会发现氛围编程做着做着，电脑上某天就多了个鲸鱼图标。多半就是这个用途。
因为可以把别人做好的镜像拿来，在自己电脑上原样跑起来。以数据库为例，不必把上一篇讲的 PostgreSQL 直接装到自己机器上，而是取镜像、以容器跑。安装过程中可能出的所有问题，整个跳过。
用完把容器撤掉就行，自己电脑上几乎不留痕迹。多个项目要求不同版本时，也不会互相打架。
所以 Docker 既是部署工具，也是开发环境工具。前面说过自己的电脑也能当服务器，这也是把好几台这样的服务器并排跑起来的办法。
Kubernetes，以及打开一次 Dockerfile
只有一个包时没什么好管的。包一多情况就不同了。哪个跑几份、死了什么时候拉起、请求涌上来时扩到几份，都要定。
干这活儿的是 Kubernetes。名字太长，把 K 和 s 之间的八个字母缩掉，写成 K8s。这是服务做大之后用的工具，并非一开始就需要。
把部署自动化的事也挂在这里。代码推到仓库后，可以让它自己构建、检查、换成新容器。这条自动流程叫 CI/CD。
有一件现在就能做的事：看看项目最上层有没有一个叫 Dockerfile 的文件，有就打开看看。安装、构建、打包的顺序写着十来行。按下部署键后等的那几分钟里发生了什么，全在那里。
FROM node:22 ← 从什么地基开始
WORKDIR /app ← 在哪个文件夹里干活
COPY package.json . ← 什么要放进包里
RUN npm install ← 要装什么
COPY . .
RUN npm run build ← 要构建什么
CMD ["npm", "start"] ← 起来之后跑什么
部署花的那几分钟，就是这些行按顺序执行的时间九篇连成一条线
我们从一条线出发：浏览器向服务器发出请求，收到文件，画出画面。
浏览器读的是三个文件。请求靠 IP 和端口确定目的地，域名把它改写成名字。到达的请求该回什么由 Web 服务器决定；画出来的是前端，造出来的是后端。值堆在数据库里，文件堆在存储和 CDN 里。而把这一整套搬到另一台电脑上，用的是容器。
知道了这个顺序，下次遇到陌生的名字，就能先问它挂在哪里。这正是这九篇的目的。