企业官网建设流程全解析

很多人第一次接触容器化，脑子里想的都是"装个软件然后敲几条命令就完事了"，结果真正动手时，卡住的地方往往跟命令一点关系都没有：包管理器的源是旧的、内核版本差一截、装完之后拉取镜像拉了半天没动静、容器起来了却访问不到、日志里翻来覆去只有一行看不懂的报错。这篇内容就是把这些散落在各处的门槛一次性摊开讲清楚，从概念关系、环境准备、镜像构建、数据与网络，到日常排错和单机编排，完整走一遍一个后端服务从零到跑起来的过程。适合完全没碰过容器的人，也适合已经能背出几条常用命令、但一遇到"容器退出了""数据没了""端口不通"就抓瞎的人。我尽量不写成命令手册，而是把每一步"为什么这么干"讲透，让你看完能自己判断，而不是照着抄。

1. 第一道坎从来不是命令，而是环境本身

我见过太多人对着教程敲完安装命令，看到一串输出就以为成功了，接着敲下第一条验证命令，返回一个"命令未找到"或者"无法连接到守护进程"，然后就卡在原地。容器这套东西本质上是依赖内核能力的，它不是一个纯粹的应用程序，装上去就能跑。理解这一点，后面的很多怪现象就都能解释了。

1.1 内核能力决定了容器能不能跑起来

容器隔离依赖的是内核提供的命名空间（Namespace）和控制组（Cgroup）这两套机制。命名空间负责"看不见别人"——进程号、网络栈、挂载点、主机名都是独立的；控制组负责"用不了太多"——CPU、内存、IO 的配额限制。这两个东西必须由内核提供，容器运行时只是去调用它们。

所以如果你的机器内核版本太老，比如某些长期没更新的系统还停留在很早期的 3.x 分支上，安装过程可能看起来一切正常，但一启动容器就报错。判断方法很直接，敲uname -r看输出，主流发行版近几年的版本基本都没问题。更精确的判断可以看两个路径是否存在：/proc/self/ns/下面应该有 cgroup、ipc、mnt、net、pid、user、uts 这一串条目，/sys/fs/cgroup/目录也应该存在并且可读。这两个位置只要有一个缺失，就说明内核编译时没有开启对应选项，这种情况下换内核或者换系统比死磕配置要省事得多。

另一个容易被忽略的点是存储驱动。容器的镜像分层需要文件系统支持，主流的 overlay2 驱动要求底层文件系统是 ext4 或 xfs，并且 xfs 在格式化时必须带上特定的参数。有些人把数据目录放在了一块特殊格式化的盘上，结果就是镜像能拉下来、容器能创建，但一写文件就出问题。

1.2 权限这件事，绕不过去但可以讲明白

守护进程默认监听的是一个本地套接字，这个套接字文件属于特定用户组。普通用户不加组就直接敲命令，得到的就是"权限被拒绝"。标准做法是把当前用户加进那个组，然后重新登录一次——注意，是重新登录整个会话，不是开个新终端窗口，因为组成员关系是在会话建立时读取的，很多人在这一步以为是命令没生效，其实是没重新登录。

组权限一旦加上，等于给了这个用户接近最高权限的能力，因为容器可以挂载宿主机目录。生产机器上要不要这么干，得自己权衡，个人开发机图省事没问题，多人共用的机器上最好还是保持默认，需要时再切换。

还有一种情况是系统启用了更严格的访问控制策略，某些发行版默认会拦截一部分系统调用，导致容器内的程序行为异常。表现通常是容器能起来，但里面的进程莫名其妙退出，或者报一些看起来毫无道理的错。这种时候可以临时放宽策略做验证，确认是这个问题之后再针对性地加规则，而不是一上来就把策略全关掉——那是给自己埋雷。

1.3 拉取镜像慢，先分清是网络还是配置

镜像拉不动的现象太常见了，但原因往往被混淆。有的人以为是自己网络差，反复重试，实际上是没有配置镜像仓库地址，所有请求都在往默认的境外地址打。正确做法是在守护进程的配置文件里加上可用的镜像加速地址，然后重启服务。

配置文件通常在那个统一的位置，格式是一段 JSON。写完之后必须重启守护进程才会生效，重启之后用docker info看输出里有没有把加速地址列出来，这是最直接的验证方式。如果docker info里看不到，说明配置文件的位置不对或者 JSON 格式写错了（比如多了一个逗号），守护进程会静默忽略掉整个文件，这一点非常坑。

如果配置正确但依然很慢，那就要考虑另一层原因：磁盘空间。镜像层是压缩存储再解压的，拉取过程中会占用额外的临时空间。磁盘快满的时候，表现就是拉到一半卡住、最后报一个跟"空间不足"有关的错误，但错误信息可能被网络层的提示掩盖，让人误判成网络问题。动手之前先看一眼磁盘剩余空间，这个习惯能省掉很多冤枉路。

2. 把镜像、容器、仓库这三者的关系捋顺

概念不清是新手最大的障碍，很多人能背出"镜像是模板、容器是实例"，但一遇到具体操作就含糊。我用一个更贴近生活的说法：镜像像是一份完整的、密封好的模具加原料包，容器是照着这份包做出来的一个成品，仓库是存放这些包的货架。模具可以反复用，做出来的每个成品都互相独立，改一个不影响另一个。

2.1 镜像为什么是分层的

这是理解容器化的关键。一个镜像不是一整块，而是由若干层叠起来的，每一层对应构建过程中的一条指令。底层可能是基础操作系统的一部分，中间层是运行环境，上层是你的应用代码。每一层都是只读的，层与层之间通过联合挂载在逻辑上合并成一个完整的文件系统。

这么设计的好处很实在：多个镜像如果共用同一个基础层，磁盘上只存一份。你本地有十个基于同一个基础镜像构建的应用，那部分基础层只占一份空间。拉取也是同理，本地已有的层会被跳过，只下载缺的那部分，这就是为什么第二次拉取相似的镜像会明显快很多。

容器启动时，会在只读层之上再加一个薄薄的可写层，所有运行时的改动都写在这一层里。读文件的时候如果可写层没有，就往下面的只读层去找；要修改一个只读层里的文件，会先把它复制到可写层再改，这个机制叫写时复制。这解释了一个常见困惑：为什么容器里删了一个文件，镜像体积一点没变小。因为删除只是在上层做了一个标记，底下的只读层原封不动。

2.2 容器和虚拟机根本不是一回事

这两个东西经常被放在一起比，但它们的隔离级别完全不同。虚拟机是靠虚拟化软件模拟出一整套硬件，然后在上面装一个完整的操作系统，每个虚拟机里都跑着自己的内核。容器是共享宿主机内核的，隔离发生在进程层面。

理解这个区别的实际意义在于：你不需要在容器里装一个完整的操作系统，也不需要给容器分配"虚拟硬盘"。很多人第一次用容器，习惯性地想"我该怎么进这个系统的桌面""我该怎么给它配网络"，这就是拿虚拟机的思路套容器，方向就偏了。

2.3 别在容器里保存任何需要留存的东西

这是新手最容易踩的一个坑，值得单独强调。容器里的可写层是临时的，容器一旦被删除，这层跟着一起消失。你在容器里装了个软件、改了个配置文件、往某个目录里写了一堆数据，容器一删，全没了。

正确的姿势是：镜像负责"不变的部分"，运行时的数据通过挂载的方式放在容器外面。需要持久化的数据、需要修改的配置、需要保留的日志，一律挂出来。反过来说，如果某个东西必须写进镜像，那它就应该在构建阶段完成，而不是在运行的容器里手动改。

这个原则还有个衍生用法：把容器当成"一次性用品"来用。需要调试的时候，起一个临时容器进去折腾，折腾完直接删掉，环境永远是干净的。这比在一台机器上反复安装卸载软件要清爽得多，也不会有残留的依赖冲突。

3. Dockerfile 怎么写才不会反复返工

写 Dockerfile 这件事，语法半小时就能学完，但写好需要踩过几次坑。我见过太多人写出来的文件能跑，但构建一次要十几分钟，或者改一行代码就触发全量重建，或者构建出来的镜像有几个 G。这些问题都不是语法错误，而是没理解构建机制。

3.1 从最小可用的文件开始

先说一个能跑的最小例子，假设是一个基于某脚本语言的小服务，依赖清单在一个文本文件里，入口脚本叫主程序。

FROM python:3.11-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . EXPOSE 8000 CMD ["python", "main.py"]

逐条解释一下。FROM指定基础镜像，这里选的是精简版，比完整版小很多，代价是某些工具没预装，需要自己补。WORKDIR设定后续指令的工作目录，如果目录不存在会自动创建，它比在每条RUN里写cd要规范得多。COPY把文件复制进镜像。EXPOSE是文档性质的声明，告诉别人这个镜像打算用哪个端口，它不会真的把端口暴露到宿主机上。CMD是容器启动时的默认命令。

这里有个非常常见的误区：很多人以为写了EXPOSE就能直接访问了，实际访问不到，然后在网络上找半天原因。端口映射必须在启动容器时用参数显式指定，两者是分开的两件事。

3.2 指令顺序直接决定构建速度

上面那个例子里，我把依赖清单的复制放在了复制全部代码之前，这不是随手写的。构建时每条指令都会生成一层，如果某一层的输入内容和缓存里的一致，就直接复用缓存，不再执行。而一旦某一层的缓存失效，它后面的所有层都会重新执行。

假设你写成先COPY . .再装依赖，那意味着你改一行代码，代码层就变了，后面的依赖安装层缓存全部失效，每次构建都要重新下载安装一遍依赖。反过来，先复制依赖清单、装依赖、再复制代码，只要依赖清单没变，改代码就只影响最后几层，构建时间能从几分钟降到几秒。

这个思路可以推广成一个原则：变化频率低的放前面，变化频率高的放后面。系统包安装、语言运行环境、第三方依赖，这些都不常变；业务代码天天变。顺序对了，日常迭代就很快。

顺便提一个配套动作：一定要写忽略文件。构建时会把当前目录作为上下文发送给守护进程，如果你的目录里有个几百兆的日志目录、或者有一个装满依赖的本地缓存目录，它们会被一起打包发送，构建时间全耗在传输上了。把不需要打进镜像的路径写进忽略文件，这一步不花任何成本，收益却很直接。

3.3 多阶段构建把体积压下来

编译型语言的场景尤其需要这个。典型的做法是：第一个阶段用带完整编译工具链的镜像去编译，产出可执行文件；第二个阶段只用一个很小的运行时镜像，把编译产物复制过去。最终镜像里不包含编译器和源码，体积能小一个数量级。

FROM golang:1.22 AS builder WORKDIR /src COPY go.mod go.sum ./ RUN go mod download COPY . . RUN CGO_ENABLED=0 go build -o /out/app . FROM alpine:3.19 RUN apk add --no-cache ca-certificates tzdata WORKDIR /app COPY --from=builder /out/app . CMD ["/app/app"]

第二阶段的COPY --from=builder是关键，它只复制指定阶段的指定文件，前面那几百兆的编译环境完全不会进入最终镜像。这里我顺手装了时区数据和根证书，前者是因为很多日志时间会跑偏，后者是因为发起网络请求时如果缺证书会直接失败——这两个东西在精简镜像里默认是没有的，属于那种"不报错则已，一报错就让人找半天"的隐性依赖。

体积小的实际价值不只是省磁盘。镜像小意味着拉取快，意味着扩容时新实例起来的等待时间短，意味着出问题时迁移和回滚的成本低。有人的镜像做到 2G，每次发布都要等好久，这种情况下优化构建往往是收益最高的一件事。

3.4 几个反复出现的写法问题

关于最后一条，补充一点：写进镜像的东西是删不掉的。哪怕你在下一条指令里把它删了，它依然存在于历史层里，通过查看构建历史就能翻出来。所以密钥类的内容绝对不能进构建流程。

关于信号那条也值得展开。如果你写成CMD python main.py这种字符串形式，实际执行时会套一层 shell，进程号 1 是 shell 而不是你的程序，信号发给 shell 之后不会传递下去，结果就是停止容器要等超时被强杀，应用来不及做优雅退出，正在处理的请求直接断掉。写成数组形式，你的程序就是进程号 1，能正常接收停止信号。这个差别在开发时几乎看不出来，上线之后才暴露。

4. 端口、数据、网络，跑通之后真正要操心的事

容器能起来只是开始。真正让一个服务可用，需要解决三个问题：外面怎么访问进来、数据怎么留住、多个容器之间怎么互相找到。这三件事没理顺，容器就只能当个玩具。

4.1 端口映射的两种写法和取舍

启动时用-p参数指定映射，格式是"宿主机端口:容器端口"。前面那个是外部访问用的，后面那个是容器内部程序实际监听的。这两个数字不一定相同，也经常被搞混。

第二种写法很值得养成习惯。如果你的服务只是本机开发调试用，或者是给同机上的反向代理转发用，绑定到回环地址能避免它被外部直接扫到。我见过有人把数据库容器直接-p 3306:3306映射出去，端口还开着弱密码，这属于把门直接拆了。

还有一种情况是端口被占用。启动时报"地址已被使用"，先别急着换端口，用ss -lntp看一眼到底是谁占着，很可能是一个忘了删的旧容器。这种情况下换端口只是把问题藏起来，容器越积越多，最后自己都搞不清哪个在用哪个端口。

4.2 数据挂载：绑定目录和命名卷怎么选

挂载分两种。一种是直接把宿主机的一个目录挂进容器，路径写得明明白白；另一种是让容器运行时管理一个卷，你只给卷起个名字。

绑定目录的优点是你随时能直接在宿主机上看到和编辑这些文件，调试配置文件的时候特别方便。缺点是它把容器和宿主机路径绑死了，换台机器路径可能不一样，可移植性差。

命名卷的优点是由运行时统一管理，位置固定、备份方便、跨平台一致。缺点是你不能随手用编辑器改里面的内容，得进容器或者用专门的命令。

我的习惯是：配置文件用绑定目录，因为要经常改；数据文件用命名卷，因为不需要手动碰。这个划分用起来比较顺。

这里有个特别经典的坑：容器里的进程以某个用户身份运行，写文件时用的就是这个用户的 ID。如果这个 ID 和宿主机上目录的所有者不一致，写文件就会报权限不足。表现是应用启动时报"无法写入某某目录"，但你在宿主机上ls -l看目录权限明明是满的。

解决办法有几种：构建镜像时把容器内用户的 ID 调整成和宿主机一致；或者启动时用参数指定以宿主机当前用户的身份运行；或者干脆在宿主机上把目录权限放开。第一种最规范但需要重新构建，第二种最省事但要注意某些镜像不支持，第三种最快但有安全风险。我在开发环境一般用第二种，生产环境老老实实对齐 ID。

另一个高频问题是时区。容器默认通常是 UTC，写出来的日志时间比本地时间差几个小时，排查问题时容易看错时间线。解决办法是在构建时装好时区数据并设置环境变量，或者在启动时把宿主机的时区文件挂载进去。前者更规范，不用依赖宿主机环境。

4.3 容器之间怎么互相访问

默认情况下，容器之间是不能通过名字互相解析的。这一点让很多人困惑：我起了两个容器，一个应用一个数据库，应用里连数据库该写什么地址。答案是先建一个自定义网络，把两个容器都接进去。

docker network create app-net docker run -d --name db --network app-net some-db-image docker run -d --name app --network app-net -p 8080:8000 my-app

接进同一个自定义网络之后，应用容器里直接写db这个名字就能解析到数据库容器的地址，端口用容器内部监听的端口，跟宿主机的映射完全无关。这个机制是自定义网络自带的 DNS 解析，默认的桥接网络没有这个能力，这也是为什么推荐自己建网络而不是用默认的。

注意区分两套端口：容器之间互相访问，用的是容器内部端口；从宿主机或者外部访问，用的是映射后的宿主机端口。这两者在配置里混用是最常见的连接失败原因。

还有个细节是启动顺序。应用容器启动时如果数据库还没准备好，连接会失败。容器运行时本身只保证"先启动先运行"，不保证"先启动的先就绪"。所以应用需要有重试机制，或者配置健康检查配合编排工具的依赖控制。指望容器一启动就能连上，在稍微复杂一点的环境里基本都会翻车。

5. 容器起不来的时候，按这个顺序查

排错能力是区分"会用"和"用得好"的分水岭。新手遇到容器退出，第一反应是删了重来，或者到处搜报错。有经验的会按固定顺序看几个地方，几分钟就能定位。

5.1 先看状态，再看日志，最后才进容器

第一步永远是看状态。容器是"已退出"还是"一直在重启"，这是两条完全不同的排查路径。用docker ps -a看全部容器，注意状态列和退出码。

第二步看日志。docker logs 容器名打印的是容器内主进程输出到标准输出的内容。如果应用本身把日志写进了文件，那日志命令里会是空的，这时候需要进容器去看文件，或者查看挂载出来的日志目录。这一点经常被忽略——日志为空不代表没报错，可能只是输出路径不同。

第三步才是进容器。docker exec -it 容器名 sh进去看看文件在不在、环境变量对不对、能不能连通外部。注意如果容器已经退出了，是进不去的，得先用别的办法让它保持运行，比如临时把入口命令换成sh或者sleep，进去排查完再改回来。

顺序很重要。我见过有人一上来就进容器折腾，结果容器本身就是启动失败退出的，根本进不去，白白浪费半小时。

5.2 退出码是最直接的线索

容器的状态里会带一个退出码，这个数字信息量很大。

137 这个最需要留意。如果你的服务无缘无故消失，退出码是 137，八成是内存超了被系统干掉。这时候要去看宿主机的系统日志，里面会有明确记录。解决办法要么是调高内存限制，要么是排查应用的内存泄漏。给容器设了内存上限就相当于画了一条线，超过就杀，不会有任何警告。

5.3 一个我自己排查时的小习惯

我会在第一次跑一个陌生镜像时，先不接任何业务参数，直接启动一个交互式 shell 进去转一圈：看看工作目录在哪、环境变量有哪些、装了哪些工具、有没有 curl 或者 wget 可以用来测网络。这几分钟的投资，能在后面省掉大量猜测。

docker run --rm -it --entrypoint sh 镜像名

--rm表示退出后自动删除容器，避免留下一堆临时容器。--entrypoint sh是临时覆盖入口命令，绕过原本的启动逻辑直接拿到一个 shell。这两个参数组合起来，是我用得最多的调试起手式之一。

还有一种情况是容器能起来但访问不到。这时候按链路倒着查：在宿主机上先curl本机端口，不通说明映射有问题；通了再查容器的地址，看程序是不是只监听了回环地址——很多框架默认只监听 127.0.0.1，这种情况下容器外的任何访问都进不来，必须改成监听全部地址。这个问题在新手配置里出现的频率极高，表现就是"容器明明在跑，日志也正常，就是连不上"。

6. 从单机命令到编排：什么时候该换个方式

一开始用命令起容器很爽，一条一条敲，看得清楚。但当容器数量到三五个，并且彼此有依赖关系时，你就会开始频繁地翻历史命令、手动维护启动顺序、记不清哪个容器用了哪个参数。这时候就该上编排工具了。

6.1 用声明式配置替掉一长串命令

编排工具的核心思路是：你把"想要的状态"写进一个配置文件，工具负责让它变成现实。对单机来说，一个 YAML 文件就能描述整个应用栈。

services: app: build: . ports: - "8080:8000" environment: - DB_HOST=db - TZ=Asia/Shanghai depends_on: db: condition: service_healthy db: image: postgres:16-alpine environment: - POSTGRES_PASSWORD=change_me volumes: - dbdata:/var/lib/postgresql/data healthcheck: test: ["CMD-SHELL", "pg_isready -U postgres"] interval: 5s retries: 5 volumes: dbdata:

这个文件把之前散落在各条命令里的东西都收敛起来了：镜像构建方式、端口映射、环境变量、数据卷、启动依赖。文件放在项目根目录，同事拉下来直接一条命令就能起整套环境，不用再对着文档一步步配。

注意这里depends_on带了一个条件，表示要等数据库健康检查通过再启动应用。这是对前面说的"启动顺序"问题的正解。单纯的依赖只是保证启动先后，加上健康检查条件才是真正的"就绪后再启动"。这是编排相对手敲命令最有价值的能力之一。

6.2 编排层里踩过的坑

第一个是数据卷的命名。编排工具会自动给卷加上项目前缀，这是为了避免不同项目的同名卷冲突。但这个机制会导致一个困扰：你换了个目录跑同样的配置，看起来挂载了同名卷，实际是两个不同的卷，数据"不见了"。查清楚卷的完整名字，就能理解为什么。

第二个是构建缓存。build: .用的是本地缓存，改了依赖清单之后有时候需要显式要求重新构建。生产环境发布时一般会加上不缓存参数，保证每次都是干净构建。

第三个是环境变量文件。把敏感配置写进编排文件里然后提交到代码仓库，是很常见的疏忽。正确做法是用单独的环境变量文件，并且把它加进忽略列表。

6.3 边界在哪：单机编排不够用的信号

单机编排足够应付大部分中小规模场景，包括个人项目、内部工具、测试环境。但出现下面这些情况时，就该考虑更重的东西了：

• 需要多台机器分担负载，单机扛不住
• 需要滚动更新，服务不中断
• 需要对容器做自动扩缩容
• 需要统一的日志和监控采集
• 一台机器挂了，服务能自动在别处拉起来

这些需求指向的是集群层面的调度，抽象层级更高，学习曲线也更陡，配套的概念一大堆。我的建议是别过早引入。单机能跑通、能排错、能稳定运行，这个基础打牢了再去碰集群，否则你会在两个复杂系统叠加的时候彻底迷失方向。我见过不少团队，服务其实只有两三台机器，硬上集群，结果运维成本翻了好几倍，出了问题没人能定位。

回过头看，容器化真正带来的改变不是"装了什么东西"，而是交付方式的转变。开发环境、测试环境、生产环境跑的是同一个镜像，环境差异带来的问题被大幅压缩；服务以镜像为单位分发，不再需要一份长长的部署文档；回滚只需要切换到上一个镜像版本，几秒钟的事。这些东西在没用容器之前，都是要靠流程和纪律去保证的，而流程和纪律是最不可靠的东西。

如果让我给刚上手的人一句建议，那就是：先在本地把一个小服务完整地跑通一遍，包括构建、启动、挂载数据、修改配置、停掉重来，把每一步的感觉建立起来。遇到报错别急着搜答案，先按状态、日志、进容器这个顺序自己看一遍，多数问题看一眼日志就明白了。这个过程比看十篇教程都管用。