企业官网建设流程全解析

从我们第一次用docker run把一个镜像跑起来开始，Docker 的很多术语就带着一股"搞基建"的味道：镜像、容器、仓库、挂载、编排。这套词搁在一块儿，其实特别像在描述一个房地产项目从拿地到交房的完整过程。Docker 就是房地产开发——Dockerfile是施工图纸，镜像是精装样板间，容器是业主最终住进去的那套房子，而 Docker Hub、Compose、数据卷这些周边工具，分别对应建材市场、物业公司和房屋的管线结构。

这篇文章我打算用"房地产开发"这条线，把 Docker 最核心的容器化概念、日常高频命令、Dockerfile 编写、数据持久化和 docker-compose 编排串起来，给刚入门或者用了一段时间但知识点比较散的朋友，补上一套完整的心智模型。内容覆盖从单机安装、镜像管理到多容器部署的完整闭环，看完你至少能自己写好一个能用的 Dockerfile，并且搞清楚容器网络、数据卷和 Compose 到底怎么配合才不掉链子。

1. 先把这个"房地产"模型搭起来：图纸、楼盘、房子和物业

很多人学 Docker 卡住，不是因为命令记不住，而是脑子里没有一个能把零散概念串起来的整体框架。"房地产开发"这个类比我用了很多年，带新人效果一直不错，核心对应关系如下。

1.1 为什么这套类比能帮你少走弯路

这套对应关系最值钱的地方在于，它帮你把"Docker 部署的到底是什么"这个问题彻底想明白了。很多人一开始接触 Docker，以为 Docker 就是个轻量虚拟机，其实不是。容器共享宿主机内核，镜像只是打包了应用和它的运行环境，这就好比所有户型都建在同一个小区地基上，水电燃气管道共用，但每户内部的家具软装完全独立。

理解了这层，你就能解释很多现象。比如为什么容器里跑的 Linux 和宿主机不是一个发行版通常也能正常运行？因为容器依赖的是宿主机内核，上面跑的只是各种应用层的库和二进制文件。又比如为什么容器删了以后数据会丢？因为默认情况下容器里的文件都写在容器自己的可写层上，容器一删这层就没了，相当于房子被拆了，里面家具自然灰飞烟灭。

这个模型还能帮你建立"交付"思维。用 Docker 部署项目的最终目的，不是让应用在你本机能跑，而是让它在任何一台装有 Docker 的机器上都能跑。这就像开发商把同一套户型图纸交付给不同城市的项目，盖出来的房子长得一模一样，业主的使用体验也完全一致。

1.2 镜像和容器，一阳一阴的关系是理解一切的前提

镜像（Image）和容器（Container）是 Docker 里最基础的两个概念，它们的关系我打个比方：镜像是"设计图 + 样板间"合在一起的静态产物，容器是"按这个样板间复制出来并且住着人的动态房子"。

镜像是一个只读文件系统，由一层一层的基础环境叠加而成。比如nginx:latest这个镜像，底层可能是debian系统，上面装好了 nginx 软件包和默认配置。每次修改镜像（比如在基础镜像上装了 MySQL），都会多出一层新的只读层。这一层层的设计带来的直接好处是：镜像可以被大量复用。你不需要每次部署都重新装一遍 Ubuntu，只需要基于官方ubuntu镜像，在上面叠加你的应用依赖层即可。

容器则是在镜像这个只读层之上，加了一个可写层。你对容器的所有修改（装包、改文件、写日志）都发生在这一层。镜像是"死的"，容器是"活的"。同一台机器上，你可以根据同一个mysql:8.0镜像跑出三个独立的 MySQL 容器，每个容器里的数据互不干扰，就像同一个户型盖了三栋楼，每户人家过着各自的日子。

当你理解了这层关系，就能明白一个常见操作：修改容器里的配置然后docker commit成新镜像——这是在把"某套房子的装修风格"重新做成"新的样板间"。这个操作做原型验证没问题，但正式环境不推荐，因为这种手工产生的镜像不可审计、不可重复构建，正确的做法永远是改 Dockerfile 重新 build。

2. 施工图纸现身：从零手写一个 Dockerfile

Dockerfile 是整个容器化交付中最重要的文件，它定义了你的应用从"什么都没有"到"能跑起来"的全过程。对开发同学来说，Dockerfile 就是你写给 Docker 看的一份自动化施工图纸，Docker 读取这份图纸后，按部就班地完成环境搭建。

2.1 Dockerfile 常用指令，对应图纸上的各类施工标注

图纸上得写清楚先砌墙还是先装窗，Dockerfile 也得按顺序写好每条指令。下面这些指令是我用得最多的一套。

FROM # 选择基础镜像，相当于选哪块地基 WORKDIR # 设定工作目录，相当于"施工队进入哪一层作业" COPY # 把本地文件复制进镜像，相当于把装修材料搬上楼 RUN # 构建镜像时执行的命令，比如安装依赖、编译项目 EXPOSE # 声明容器打算监听哪个端口，相当于在图纸上标出门窗位置 ENV # 设置容器内的环境变量，相当于预设房间的温控参数 CMD # 容器启动时默认执行的命令，相当于钥匙交房后业主入住时自动做的第一件事 ENTRYPOINT # 与 CMD 配合，固定启动入口，相当于物业规定的入住流程，业主无法随意更改

这其中的重点我要多说两句。CMD和ENTRYPOINT的区别经常让人犯迷糊。简单记忆：ENTRYPOINT定义的是"不可被覆盖的启动程序"，CMD定义的是"可以被覆盖的默认参数"。举例来说，一个镜像的CMD ["nginx", "-g", "daemon off;"]，你运行时追加参数就可以覆盖；但如果是ENTRYPOINT ["docker-entrypoint.sh"]，你覆盖启动程序就没戏了，只能追加参数。实际写 Dockerfile 时，ENTRYPOINT适合放启动脚本，CMD放默认参数，这是官方推荐的最佳实践。

WORKDIR这个指令看着不起眼，实际上非常容易埋坑。如果你不设WORKDIR，直接RUN mkdir /app再COPY，后续所有相对路径的操作都依赖当前目录的上下文，一旦你在宿主机不同目录构建，行为就可能不一致。设置WORKDIR /app后，后面所有RUN、CMD、COPY的相对路径都自动以/app为基准，这就是为什么几乎所有生产级 Dockerfile 上来第一件事就是WORKDIR。

2.2 拿一个真实例子开刀：Node.js 应用的 Dockerfile

这里我以一个常见的 Node.js Web 服务为例，给大家一份可以直接抄作业的 Dockerfile，并逐行解释原因。

# 第一阶段：编译构建 FROM node:20-alpine AS builder WORKDIR /app COPY package*.json ./ RUN npm ci --only=production COPY . . RUN npm run build # 第二阶段：精简运行环境 FROM node:20-alpine ENV NODE_ENV=production WORKDIR /app COPY --from=builder /app/node_modules ./node_modules COPY --from=builder /app/dist ./dist EXPOSE 3000 CMD ["node", "dist/main.js"]

这个文件里用了多阶段构建（AS builder和--from=builder），这是生产环境部署必须掌握的技巧。为什么把构建依赖和应用最终产物分开？因为构建阶段往往需要完整的编译器、开发依赖，这些加起来可能有几百兆甚至上 GB，但应用真正跑起来只需要编译好的产物和运行时依赖。多阶段构建的好处就是最终镜像只包含运行所需的最小文件集，镜像体积小了，拉取快了，被攻击面也跟着变小。

另外注意一个细节：我先COPY package*.json ./再RUN npm ci，最后才COPY . .。这是因为 Docker 构建有层缓存机制，只要package.json没变，npm ci这一层就不会重新执行。如果先把整个项目复制进去再装依赖，那每次代码一改，依赖就得全部重新下载，开发体验会非常痛苦。把变化频率低的文件放前面，变化频繁的放后面，是写 Dockerfile 必守的黄金法则。

2.3 构建镜像时的三个实战纪律

构建不是写完 Dockerfile 就完事，这三个纪律能帮你少踩很多坑。

第一，FROM尽量用官方镜像，并且指定版本号。用node:latest这种写法当时省事，几个月后基础镜像更新，可能导致不可预期的破坏。就像盖楼不能只看"今天用海沙没事"，标准化材料管理才能保证每一批楼质量一致。锁定小版本比如node:20.18.0-alpine更严谨，至少锁定大版本。

第二，.dockerignore必须要有。它相当于施工图纸上标注的"哪些区域不能动"：node_modules、.git、dist、*.log这些都不应该进入构建上下文。构建上下文越大，Docker 发送给守护进程的文件就越多，构建速度会明显变慢。更有甚者，如果把包含密钥的.env文件打进镜像，等于把保险柜密码贴在楼门口。

第三，构建时常用docker build -t myapp:v1.0 .给镜像打标签。那个末尾的点号是构建上下文路径，不是无关字符。用错了路径极有可能导致COPY找不到文件，这是新手最常见的报错之一。

3. 建材市场和仓库管理：镜像的拉取、保存与分发

图纸画好了，施工方按图建好了一套精装样板间。接下来这套样板间要投入批量生产，就得解决两个问题：仓库从哪来，怎么送到世界各地去。镜像是"静态"的，它需要被存储、标记、传输，这就是镜像仓库管理的活。

3.1 镜像先打标，再上传到目标仓库

构建出来的镜像默认会被标记成repository:tag的形式。比如刚才构建的myapp:v1.0，这里myapp是仓库名，v1.0是标签。要把镜像推到远程仓库，就得先给它打上完整的远程地址标签。

# 本地镜像打标签 docker tag myapp:v1.0 registry.example.com/team-a/myapp:v1.0 # 推送到远程仓库 docker push registry.example.com/team-a/myapp:v1.0

底层逻辑是：docker tag不复制镜像，只是给镜像 ID 增加了一个引用名。这很像房产证上变更户主名字——房子还是那套房子，但归属和标识变了。正式环境里，仓库地址通常是一家公司内部私有仓库的地址（比如 Harbor、Nexus 或云厂商的镜像仓库服务），而不是 Docker Hub。我强烈建议有正式发布需求的公司搭建私有仓库，原因很直接：公有仓库拉取速度不稳定、有被代理风险、也缺乏访问控制。

3.2 镜像下载慢？先检查镜像源，不用慌

在国内用 Docker 最头疼的就是docker pull ubuntu:20.04卡半天。这个问题本质上是默认镜像源docker.io的访问速度问题，解决办法是配置镜像加速器，给 Docker daemon 加 registry mirror。

Linux 上编辑/etc/docker/daemon.json，内容示例：

{ "registry-mirrors": [ "https://docker.m.daocloud.io", "https://dockerproxy.com" ] }

改完重启 Docker：systemctl restart docker。Windows/Mac 上则直接在 Docker Desktop 的 Settings -> Docker Engine 里改同样的 JSON 配置。需要注意一点：镜像源属于"尽力加速"，不一定所有源都一直稳定。如果某个源失效，换一个就行。另外，公共加速器对私有仓库拉取无效，私有仓库请通过合理的网络通道访问，这里不做展开。

3.3 镜像管理常用命令速查

docker save和docker load这组命令我以前不重视，直到有一次现场环境完全没有外网、也不允许搭私有仓库，才意识到把镜像打包成 tar 文件的威力。直接拷贝 tar 包再docker load，就能在离线机器上恢复镜像环境。实际做离线交付时，记得同时带上.env等配置文件清单，不然镜像有了也不会跑。

4. 批量施工与交付：容器的生命周期管理

图纸有了，样板间有了，接下来就是按同一份图纸批量施工、交付给住户。对应到 Docker 里，就是用同一个镜像启动多个容器，并对容器进行启停、监控、删除等生命周期管理。

4.1 一套docker run参数，覆盖容器的初始化配置

docker run是使用频率最高、参数也最繁多的命令，我用一个实际运行 Nginx 的例子拆开讲。

docker run -d \ --name web-1 \ -p 8080:80 \ -e TZ=Asia/Shanghai \ -v /opt/nginx/html:/usr/share/nginx/html:ro \ --restart=always \ nginx:1.27-alpine

这些参数背后的逻辑，我一个个说清楚。

-d让容器在后台运行，掉出日志到后台，这相当于交房后房子在无人看管的情况下自动持续运营。不加-d的话，容器会挂在前台，Ctrl+C 一按整个容器就退出了。

--name web-1给容器起名字。容器的 ID 是一串随机哈希，每次操作都敲那串字符不现实，所以显式命名相当于给每套房编了门牌号。

-p 8080:80是端口映射，保存外部 8080 端口访问到容器内部 80 端口。为什么要做端口映射？因为容器默认有一套隔离的、独立的网络栈，宿主机访问不到容器的 IP，必须通过映射端口这个"门禁"来放行。这里要提醒一句：左边的 8080 可以随便选，只要不跟宿主机已有端口冲突；右边 80 必须跟容器内应用实际监听的端口一致，否则映射了也访问不到。

-e TZ=Asia/Shanghai设置环境变量。很多应用（尤其是 Java、Node 应用）读不到正确时区会导致日志时间比北京时间慢 8 小时，这个参数能一次性解决。

-v /opt/nginx/html:/usr/share/nginx/html:ro是目录挂载，等会儿讲持久化时会细说，这里先记住它能让宿主机文件夹和容器内文件夹做实时共享。

--restart=always定义容器异常退出时的重启策略。生产环境部署基本上都建议加--restart=unless-stopped，它的意思是除了手动 stop 的容器，只要异常退出就自动重启，这是保证服务高可用的最基础一层。

4.2 容器常见操作和进入容器排查问题的正确姿势

容器跑起来以后，最常碰到的情况就是"怎么进去了看日志"。

# 查看运行中的容器 docker ps # 查看包括已退出在内的所有容器 docker ps -a # 查看容器日志（-f 持续输出） docker logs -f --tail=200 web-1 # 进入容器内部（web-1 是容器名） docker exec -it web-1 /bin/sh

要特别提醒的是：现代基础镜像很多是精简版（alpine），默认不带/bin/bash，只有/bin/sh。所以当你docker exec -it xxx /bin/bash报错说找不到bash时，不要绕着弯去找镜像问题，直接换/bin/sh尝试即可。

docker logs是我排障的第一选择，因为它最轻量，不需要进入容器就能看到 stdout 和 stderr。但别忘记一个前提：应用必须把日志输出到标准输出，而不是写进文件。如果应用习惯把日志写到/var/log/app.log文件里，docker logs就什么都看不到。这种情况下要么改应用日志配置，要么用docker exec进去查看文件，我更推荐前者，因为日志集中管理对后续接入日志平台更友好。

进入容器里排查问题时，docker inspect 容器名是个宝藏命令。它返回一大段 JSON，里面有容器的全部配置和状态：IP 地址、挂载目录、环境变量、健康检查状态等。经常排障的人一定要养成docker inspect的习惯，很多谜团（比如环境变量没生效、端口没映射对）都能在这一大段 JSON 里找到真相。

4.3 容器可以被反复折腾，但别把运行中的容器当数据源

容器最方便的一点是"随建随拆"。不需要了直接docker rm -f把它删了，再用同一镜像重新运行一个。但这里有个大坑：容器里写的文件默认在可写层，删了就没。

比如你docker exec进容器，手动创建了一个配置文件、写了几条测试数据，然后容器被误删，所有改动都化为乌有。也许你会说"那我提交成镜像不就能保存了吗"？可以，但docker commit产生的镜像往往臃肿且不可追溯，我不建议作为常规方案。

正确的姿势就一句话：任何要保存的数据，一开始就放到挂载卷或数据卷里。后面第五部分详细讲。总之记住一条铁律：容器是可以随时替换的无状态单元，数据必须活在外面。

5. 基础设施配套：数据卷、网络和 docker-compose 协同

当你要部署的不只是一个 Nginx，而是 MySQL + Redis + 后端服务 + 前端页面一整套系统时，单独操作容器就不够用了。你得管理它们之间的网络通信、数据保存、启动顺序，这时候"小区物业"就得上场了，对应到 Docker 就是网络、数据卷和 Compose。

5.1 数据持久化：把数据放在"房主手里"而不是"房子里"

任何数据库类的容器（MySQL、Redis、PostgreSQL）都必须做持久化，否则一删容器数据全丢。Docker 提供两种主流持久化方式，我分别说清楚适用场景。

Bind mount（绑定挂载）：就是把宿主机的某个目录直接映射到容器内目录。比如：

docker run -d --name mysql-8 \ -v /opt/mysql/data:/var/lib/mysql \ -e MYSQL_ROOT_PASSWORD=yourpassword \ mysql:8.0

这里的/opt/mysql/data是宿主机目录，容器内的/var/lib/mysql是 MySQL 的默认数据目录。挂载后 MySQL 往容器内写的数据，实际上都写到宿主机/opt/mysql/data里了。容器删除重建，数据依然还在。

Volume（命名数据卷）：Docker 自己创建和管理一个目录，比如：

docker volume create mysql-data docker run -d --name mysql-8 \ -v mysql-data:/var/lib/mysql \ -e MYSQL_ROOT_PASSWORD=yourpassword \ mysql:8.0

mysql-data这个卷由 Docker 统一管理，存放位置在/var/lib/docker/volumes/mysql-data/_data，你不必关心具体路径。相比 bind mount，Volume 的优势是跨平台（macOS/Windows 上路径差异很大）和适合容器间共享。

我的经验是：数据库这类基础设施，用 bind mount 更直观，因为我能直接到宿主机目录里用ls查看数据文件大小和备份。其他应用日志、配置文件，则优先用命名卷。

权限问题说三遍：挂载目录的属主和权限经常导致容器启动失败。常见例子是 MySQL 容器内使用mysql用户（UID 999）访问挂在宿主机的目录，如果宿主机目录属主是 root，容器内就会报权限错误。解决办法：chown 999:999 /opt/mysql/data，或者简单粗暴地在宿主机目录上chmod 777（不推荐正式环境用）。

5.2 容器网络：给不同容器之间修路、设卡

默认情况下，Docker 为每个容器分配一个独立 IP，但容器重启后 IP 可能会变。所以容器之间通信不要依赖 IP，而是用容器名做 DNS 解析。这个能力要在自定义网络里才开箱即用。

# 创建一个自定义 bridge 网络 docker network create app-net # 两个容器都加入同一网络 docker run -d --name mysql-8 --network app-net mysql:8.0 docker run -d --name backend --network app-net myapp:v1.0

这样backend容器里就能直接用mysql-8:3306访问数据库，Docker 内置 DNS 会解析到对应容器。为什么要自定义网络而不是用默认 bridge？因为默认 bridge 下，容器之间只能通过 IP 访问，无法用服务名解析；而且自定义网络支持将容器动态从网络里"踢出去"或"加回来"，网络隔离和安全性更好控制。

容器对外的端口映射则在真正的边缘容器上做。比如backend要对外提供服务，就在运行时加-p 8080:3000。在"内部网络"里的 MySQL 则不需要映射端口，因为它只需要被backend访问即可，没必要暴露到宿主机外部，这本身也是一种安全加固。

5.3 docker-compose：用一份 yml 管理整个"小区"

当容器数量超过两三个，命令行逐个启动就非常痛苦。docker compose 是官方提供的多容器编排工具，你用一份 YAML 定义服务、网络、数据卷，然后一条docker compose up -d全部启动。

这里给一份同时部署 MySQL 8.0 和 Redis 7 的docker-compose.yml示例，这套配置我经常用来快速搭建开发环境。

version: "3.8" services: mysql: image: mysql:8.0 container_name: dev-mysql restart: always environment: MYSQL_ROOT_PASSWORD: root123456 MYSQL_DATABASE: demo TZ: Asia/Shanghai ports: - "3306:3306" volumes: - mysql-data:/var/lib/mysql command: - --character-set-server=utf8mb4 - --collation-server=utf8mb4_unicode_ci healthcheck: test: ["CMD", "mysqladmin", "ping", "-h", "localhost"] interval: 10s timeout: 5s retries: 5 redis: image: redis:7-alpine container_name: dev-redis restart: always ports: - "6379:6379" volumes: - redis-data:/data command: ["redis-server", "--appendonly", "yes"] volumes: mysql-data: redis-data:

这个文件的几个细节值得展开说。

healthcheck是给容器加体检。compose 可以根据健康状态判断服务是否真正就绪，避免后续服务去连一个还没初始化好的 MySQL。加了这个，配合depends_on: condition: service_healthy，就能严格保证启动顺序，这是生产环境必备写法。

Redis 的--appendonly yes开启 AOF 持久化，数据会写到/data目录，而/data又挂载到了命名卷redis-data，这样 Redis 容器删了数据也不会丢。

MySQL 的command追加了character-set-server=utf8mb4，解决常见的中文乱码问题。这个不加的话，默认latin1字符集存中文基本必乱。这也是大家从 Docker 安装 MySQL 后最常见的一个坑。

启动命令：

docker compose up -d # 后台启动 docker compose ps # 查看服务状态 docker compose logs -f # 查看所有服务日志 docker compose down # 停止并删除服务（卷默认保留） docker compose down -v # 连卷一起删（慎用！数据会没）

docker compose down和docker compose down -v的差别极其重要。前者只是"退房不拆楼"，数据卷还留着；后者是"整栋楼推平重建"，所有数据直接消失。我见过不止一个同事在测试环境跑了下down -v，才意识到 Redis 缓存数据也没了，好在是测试环境。

生产环境部署 Dify、GitLab 这类“全家桶”应用时，厂商通常都会提供一个完整的docker-compose.yml，原理跟上面这套完全一致——它里面会定义 MySQL、Redis、Web 服务等一堆容器，用 internal 网络互相通信，用命名卷保存数据。学会看 compose 文件，比学会敲 Docker 命令更能帮你快速上手新的开源项目。

6. 装修验收与日常运维：常见报错的心跳记忆

Docker 的报错信息很多时候看着吓人，拆开来逐字读其实都能找到线索。下面这些是我被问过几百遍的经典问题，按场景分个类，直接给答案。

6.1 环境启动与安装类问题

报错：virtualization support not detected（Windows / Mac 上 Docker Desktop 启动失败）

这是 Docker Desktop 在 Windows 上最常见的启动失败原因。排查思路按顺序走：

1. 确认 BIOS/UEFI 里Intel VT-x或AMD-V处于 Enable 状态。
2. Windows 功能里确认Hyper-V、Windows Hypervisor Platform、适用于 Linux 的 Windows 子系统已经勾上。
3. 命令提示符（管理员）执行bcdedit /set hypervisorlaunchtype auto并重启。
4. 如果机器配置允许，优先升级到 Windows 11 专业版/企业版，新版 Docker Desktop 对 WSL 2 的支持比老版本好非常多。

报错：failed to connect to the docker api at npipe:////./pipe/dockerdesktoplinuxengine

这个报错在 Windows 上出现频率极高，本质是 Docker Desktop 的后台引擎没起来，但客户端连接不上。先打开 Docker Desktop 看鲸鱼图标是不是在转圈，手动等它变成绿色。如果一直是红的，多半是 WSL 2 内核版本过旧，运行wsl --update更新一下再重启 Docker Desktop。

报错：permission denied while trying to connect to the Docker daemon socket

Linux 上常见，原因是当前用户没有访问 docker 的 Unix socket 权限。两条路：要么sudo usermod -aG docker $USER然后将当前用户加入 docker 用户组并重新登录（生产环境谨慎，等价于把 root 权限授予用户）；要么简单点，部署脚本里命令都加sudo。实际演示或本机开发，我更推荐加用户组。

6.2 镜像下载与构建类问题

镜像下载慢：上面讲过的 registry mirror 就是首选。还有就是尽量选体积小的基础镜像，比如alpine镜像通常只有几 MB，而debian全量版可能几百 MB。有换镜像源需求时，不要一个个试，编个脚本把常见加速地址都测一遍通不通，哪个延迟低用哪个。

构建时COPY失败：九成是构建上下文路径搞错。检查你docker build命令末尾的点号位置，还有.dockerignore是不是把需要的目录给排除了。我曾经见过同事把node_modules写进.dockerignore，然后COPY . .之后容器里没有 node_modules，应用起不来，排查了一下午。

6.3 运行与数据类问题

容器启动几秒就退出：先docker logs 容器名看日志，这类问题几乎都能在应用日志里找到答案。常见原因包括：环境变量没设置导致应用启动报错、端口被占用、启动命令参数写错。不要反复docker run着看，一定要用docker logs定位原因，否则就是在瞎碰运气。

时区不对：容器默认 UTC 时间，国内服务日志全部差 8 小时。每个容器的-e TZ=Asia/Shanghai必须配上。如果是 docker compose，写在environment下面；如果是 Dockerfile 打包的镜像，可以通过ENV TZ=Asia/Shanghai全局设置。个别基础镜像不带 tzdata（时区数据库），还需要RUN apk add --no-cache tzdata先装上。

容器日志把磁盘写满：默认情况下 Docker 会无限收集容器日志，一个应用跑几个月，/var/lib/docker/containers下的日志文件可能膨胀到几十 GB。最好在 daemon.json 里加日志轮转配置：

{ "log-driver": "json-file", "log-opts": { "max-size": "10m", "max-file": "3" } }

这行配置的意思是单个日志文件超过 10MB 就滚动，最多保留 3 个文件。改完重启 Docker 生效，但注意只对新产生的容器生效，旧的容器日志还是需要手动清理。

容器内存占用过高被系统杀掉：如果服务在高峰期被 OOM Killer 干掉，最直接的解决办法是给容器设置内存上限。docker run --memory=1g或在 compose 里写mem_limit: 1g，让容器超出限制就报错而不是拖垮整个宿主机。

7. 这套"房地产"模型还能带到哪去

写到这儿，我相信你对"Docker 就是房地产开发"这个类比已经有了比较完整的感知：Dockerfile 画图纸，镜像建样板间，容器批量交付，数据卷做保险柜，Compose 当物业。这套思维模型一旦建立起来，往后看 Kubernetes、Docker Swarm 这些编排系统会轻松很多——它们本质上是"跨小区的物业集团"，管理的是多台机器上的大量容器，但核心逻辑依然是"用声明式的配置管理镜像和容器"。

我个人的体会是，学 Docker 最怕一开始就钻进网络、存储等底层细节里出不来，因为那些东西没有前面的整体图景时会显得非常抽象。优先把镜像、容器、数据卷、Compose 这四件事玩明白，能覆盖日常开发部署的九成需求。遇到不懂的再针对性去查docker inspect和官方文档，比从第一章读文档效率高得多。

最后再分享一个小技巧：本地开发时不要嫌docker compose启动慢就常年开着容器不关。我是习惯为每个项目单独建一套 compose 文件，用docker compose -p project-a up -d指定项目名前缀，这样多个环境的容器互不干扰，docker compose ps也能一眼看出哪套环境还在运行。反正容器起来很快，干净的环境比什么都能减少"在我电脑上明明是好的"这种惨剧。